#ubuntu-devel 2004-11-01
<lamont_r> bbl
<amu> lamont_r: do you plan another iso ? 
<amu> .. just took -16 ;) 
<lamont_r> yes.  Plan to burn one with (hopefully) new artwork for grub screen, and definitely WinFOSS 0.4, in about 6 hours.
<chrisa> I'm currently installing ubuntu's gnome 2.8 on my sid system in an attempt to see what explodes. This should prove interesting
<lamont_r> right now, must run.
<lamont_r> chrisa: you're sick, you know.
<lamont_r> good luck
<amu> lamont_r: cu
<chrisa> wow, it worked
<amu> try with woody ;) 
<chrisa> heh
<chrisa> I should probably pin this correctly
<amu> if it runs <1 Week, you win a Beer and become the master of moving bits.
* chrisa looks at the spare hardware in the office and grins
<amu> upgrading from sarge, that manages even my 3 year old daughter:)
<amu> .. or sid ;)
<__daniel> amu, that's what my dog did last night :-)
<amu> Ahh, I think you know also storry with the chicken ;) 
<__daniel> amu, erm... no i dont :-)
<amu> which debian installed....
<__daniel> amu, not really, but i hope there's someone who tells it to me as a good night tale :-)
<amu> no tale, you should ask joey about it ;) 
<amu> there are much more interessting things, like sending tcp packages with pigeon ;)  
<__daniel> amu, hehe... yesterday they talked about the good old times in 1903 were the internet was still cool and they had to carry packages up- and downhill even in the snow - that reminded me of those pigeons :-)
<__daniel> amu, haha, found the chickens on http://www.linuxjournal.com/article.php?sid=0172 :-)
<amu> live is interesting ;)
<mdz> Ng: if you're certain that you are correct about it being a duplicate, then it is very helpful for you to mark it
<Ng> mdz: ok, I'll make sure I check it thoroughly
<Ng> thanks
<mdz> Ng: if you are unsure, then feel free to comment
<mdz> and someone will review and confirm
<Ng> ok, cool :)
<Ng> is there policy yet about modifying things to use gksudo/sudo? e.g. gnome-system-tools uses su, but appears to be easily modifyable to use sudo su as a quick hack. would that be frowned upon?
<jdub> Ng: our g-s-t uses gksudo
<mdz> Ng: things which use su in the Ubuntu desktop are bugs
<Ng> jdub: the desktop entries do, but you can make it use internal routines that call su, e.g. the "Configure" button in Applications->System->Network Tool
<mdz> Ng: that bug is already reported (twice)
<jdub> oh, that's a different module
<jdub> and it is bad that it wasn't fixed
<jdub> but i don't think anyone realised that was in the new version
<Ng> mdz: I know, fessing up, I didn't actually wait for your answer before marking the duplicate ;)
<Ng> and I'm part way to a patch for it
<mdz> if it's a simple and safe fix, that'd be a good candidate for warty-updates
<jdub> mdz: would we consider it 'high-impact', 'dataloss' or 'security'?
<Ng> it is looking like it'll be pretty simple, I'm just tying what is mostly a one liner into autoconf. the only snag I have hit is that there is a string that says "root password" that could use rewording and thus translation :/
<jdub> it uses it's own su foo?
<mdz> jdub: given that two people have run into it already, apparently it's functionality in the desktop that people use, it's broken, and there's a trivial fix
<Ng> jdub: it spawns a pty, runs su and the module with it, feeding it the pw
<mdz> ok, maybe not so trivial :-)
<Ng> src/common/gst-auth.c (last function)
<jdub> i *hate* that
* jdub is reminded to add permissions elevation to HH
<Ng> it seems to work just making the su_args array one larger by putting sudo as arg[0]  :)
<gma> I'm curious about the development model. Do all developers work for canonical, or are you globally distributed?
<jdub> gma: all the developers on warty work for canonical, *and* are globally distributed :-)
<Ng> I'm currently arguing with dpkg-buildpackage though ;)
<jdub> gma: but now there are heaps of community members helping out
<gma> cool.
<jdub> Ng: hrm, might want to check if they copied code from gnome-system-monitor
<gma> are canonical open to applications?
<jdub> Ng: daniels fixed that
<Ng> jdub: ooh, cool
<mdz> jdub: HH?
<jdub> mdz: hoary page
<mdz> ah
<mdz> jdub: what about permissions elevation?
<jdub> attempting to standardise on something
<Ng> jdub: it looks similar, but not close enough to just yoink the code over :(
<Ng> I'd say they have a common origin, but the g-s-t one is split up more so it can do ssh auth too
<doogie> btopenworld?  does that mean they use opensource?  :)
<Ng> probably not ;)
<jdub> morning elmo_ 
<Ng> BT like things that are slow and bad and expensive ;)
<Ng> argh
<elmo_> hey jdub
<Ng> the gnome-system-tools configure script is telling me I need intltool 0.29 or later, but I just installed ubuntu's, which is 0.31 or something. any ideas?
<Ng> if I can just make the thing compile I think my patch is done and trivial enough to be safe
<Ng> aha, the source package was missing a file or I didn't run enough auto* stuff
<__daniel> Ng, what version of g-s-t did you try to ./configure ?
<Ng> __daniel: 1.0.0-0ubuntu7
<Ng> I just apt-get source'd it, changed configure.in and a .c file and dpkg-buildpackage'd it
<__daniel> Ng, that's strange: "apt-get source gnome-system-tools; cd gnome-system*; ./configure" ran fine at my place
<Ng> I did change a string in a glade file too, so that and/or the configure.in change probably needed auto* to run more things
<Ng> I had to copy intltool-update.in from intltool's install directory to the "backends" directory in g-s-t
<Ng> it could easily be my mistake though, it's probably a couple of years since I last did any of this ;)
<__daniel> i don't get why they don't have a proper  autogen.sh 
<Ng> *shrug* :)
* Ng sticks his patch in bugzilla, hopefully the first of many :)
<Ng> g-s-t isn't going to work doing remote module without further patching though
<Ng> well, if the target machine is ubuntu at least
<Ng> since it ssh's as root :/
<__daniel> Ng, ssh-as-root should never really be an option in a program
<Ng> well it isn't a great idea to spawn a pty and use it to run su to get root, but they do ;)
<jdub> ugh
<jdub> ok
<jdub> totally have to figure otu sound on this machine
<sabdfl> lamont: live cd -16 seems to have solved the "see-through desktop" issue on the tosh
<mjg59> Oh, wow
<mjg59> lamont's been flamed on Advogato
<kylem> it's a valid point.
<jdub> so what are some of our "all the drivers work but there's no audio output" solutions?
<jdub> parallel port is disabled in bios, and modules are not loaded
<jdub> audio definitely worked with early ubuntu kernels
<mjg59> Is the hardware unmuted?
<jdub> yes
<jdub> done by ubuntu by default
<mjg59> On all channels?
<mjg59> Is there a hardware mixer?
<jdub> no
<mjg59> If you try to play something, does the interrupt number in /proc/interrupts increase?
<jdub> yes
<mjg59> Any messages in dmesg?
<jdub> 130 -> 248 that time ;)
<mjg59> Sounds like it's either a mixer issue or you've managed to get two sound drivers loaded...
<jdub> there's only the first device's stuff under /dev/snd
<mjg59> Hrm.
<mjg59> And lsmod only shows one snd-something driver loaded?
<jdub> one module in /proc/asound/modules
<jdub> no, there's heaps
<jdub> but actual drivers could include snd_bt87x
<jdub> removed, still the same
<mjg59> Uh. bt87x sounds a touch worrying.
<jdub> (this machine has a dvb card in it)
<mjg59> Yeah
<Ng> I've had problems with hotplug loading snd_bt87x before snd_emu10k1 and breaking sound
<mjg59> I'd worry that that might have presented a mixer device, and then the wrong stuff may have been loaded
<lupus_> what idem Ng
<lupus_> idem
<lupus_> I mean :)
<jdub> i'll try loading snd_intel8x0 in /etc/modules
<mjg59> If you remove and then reinsert the correct module and then check the mixer, what does it look like?
<mjg59> Ok, that works too :)
<Ng> lupus_: eh? ;)
* jdub did not realise that distrowatch was seen as a big deal
<lupus_> ng I mean bttv also broke my sound because it is loaded before the soundcard
<Ng> ah :)
<Ng> I only had that with debian, for some reason ubuntu gets it right
<Ng> I thought it was dependant on PCI ordering because it's hotplug doing it and it works in bus order
<lupus_> A friend of my was complaining the other day that he couldn't switch between his 2 soundcards for sound
<lupus_> a tool that could do this would also fix this issue :)
<jdub> yeah
<lupus_> and should be possible on the fly without rebooting :)
<jdub> hrmph
<__daniel> good night guys
<lupus_> are there plans to let hald use fstab-sync to add all the partitions in /etc/fstab  (vfat,ntfs etc) ?
<mdz> mjg59: lamont's been flamed on Advogato?
<vorlon> for a documentation-impaired changelog entry.
<vorlon> ... by Mathieu Roy.
<doogie> ... and the middle-of-the-road "testing" release seems to offer the worst of both "stable" and "unstable."
<doogie> (from lwn)
<doogie> re: ubuntu and debian
<vorlon> that's a curious characterization.  I wonder what they think the best parts of unstable are that testing doesn't have -- the RC-buggy packages that will never make it in? ;)
<chrisa> Indeed
<chrisa> Both hotplug and discover shouldn't need run at the same time, right?
<mdz> chrisa: indeed, they _must not_ both run
<tseng> 'lo
<chrisa> mdz: So which is preferred for a laptop type system?
<mdz> chrisa: hotplug is preferred in all cases, and is the Ubuntu default
<jdub> morning tseng
<jdub> Keybuk: so if we have out of control evolution processes guzzling RAM like nobody's business, what's the most useful tool i can ask a user to run to get some idea of where the problem lies?
<lamont> mjg59: url for the flamage?
<jamesh> lamont: http://www.advogato.org/person/yeupou/diary.html?start=63
<lamont> jamesh: you mean people actually read changelogs.?
* tseng does.
<kylem> apt-listchanges...
<jamesh> apparently.
<vorlon> lamont: it's all mdz's fault for that fancy apt-listchanges hoowah.
<tseng> but im hardly offended by someone refering to a bug #, as a gentoo dev we did that all the time
<lamont> heh
<lamont> that one was basically one of me going, "well, that one's definitely fixed by now."  And there are probably others
<tseng> make a keybinding that pipes xclip -out, containing the bug number to the end of a bugzilla search query, and send it to the brower
<tseng> "5 minutes" becomes a fraction of a second
<jamesh> maybe he expected you to paste the bind release notes into the changelog.
<lamont> better yet, I built it with the wrong email address....
<tseng> reading on, this guy is a complete tool
<tseng> id ignore it
<daniels> isn't yeupou mathie roy?
<daniels> mathieu, even
<vorlon> yep.
<daniels> interesting.  only 2 peers on BT for i386, and I haven't served a single powerpc or amd64 torrent; contrast with pushing 1.5MB/s (bytes, not bits) for the preview
<vorlon> everybody who downloaded the preview died of shock when they found out how good it was? :P
<jdub> all the upgraders ;)
<daniels> <Culus> my goal is to have people see the download progress meter and
<daniels>         kill themselves because they know they will never see
<daniels> 	something more eleet than that
<daniels> i think that's a pretty good model to be aiming for
<mdz> the download progress meter is pretty 31337
<jdub> in bittorrent?
<daniels> jdub: in apt
<daniels> jdub: (culus being the apt maintainer or something, as well as an admin; in true debian style, he is, of course, almost entirely invisible)
<jdub> oh, the experimental versions of apt?
<daniels> dunno, don't think there's really been a new major apt for quite some time
<mdz> jdub: apt's current download progress meter
* jdub furrows brow, makes dubious glancing looks around the room.
<mdz> jdub: dude, it's rad
<daniels> it's ill
<daniels> how about 'Ill Network Management' as a Hoary goal?
<daniels> or 'Ill Link Beat Detection To Make Your Computer Start Up Like Twenty Minutes Quicker When You're Not Plugged In To A Network'
<jdub> we'd start saying things like 'network beat box' and confusing the crap out of everyone
<kylem> how about 'Ill 802.1X and WPA Integration'
<daniels> network beat box! i love it!
<daniels> can we please have that?
<jdub> fight the power man, all those wireless security protocols are crackrock
<tseng> yay for ssh
<kylem> it's not about security, it's about authentication. :)
<jdub> yeah, and i want to know who you are before i give you any cookies
<daniels> jd	not *those* cookies.
<daniels> oh man. bong.
<daniels> daniels@catsby:~/video% ping 192.168.1.1
<daniels> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
<daniels> From 210.8.1.21 icmp_seq=1 Packet filtered
<daniels> From 210.8.1.21 icmp_seq=2 Packet filtered
<daniels> maybe ifplugd wasn't quite as phat as I'd hoped.
<bob2> apt should use GL to produce a rendered pie graph for completion
<daniels> bob2: and it should use COMPOSITE
<daniels> or something.
<bob2> hahaha
* daniels decides to research stuff like ifplugd.
<tseng> NetworkManager will be cool in about 2 years
<daniels> i just want /etc/init.d/networking to say 'hey! no cable! ill!' and go along its merry way and not bother me.
<jdub> tseng: two years? no way, it's getting lots of attention
<tseng> daniels: iirc redhat does that with mii-tool
<tseng> checking for cable.
<lamont> daniels: that would be rad
<jdub> daniels: (what about localhost?)
<daniels> jdub: hm?
<daniels> jdub: well, just not spend an hour trying to bring up DHCP and NTP
<tseng> ctrl plus c, works for me
<tseng> but doing it right would be cool.
<daniels> yeah, but I usually restart after X crashes, which means I go off to get another glass of water/cup of tea
<lamont> daniels: I imagine there's no binary driver bits for ATI rage mobility, true?
<daniels> not at all
<daniels> were you after a specific feature, or just wondering?
<lamont> wondreing
<bob2> can't we just let ifplugd do the whole thing?
<lamont> trying to figure out how to maximize my radeon 7500 on the desktop as well.
<bob2> or does it not notice when something is already plugged in?
<lamont> guess I should read the howto.
<fabbione> morning guys
<jdub> NM > ifplugd (and friends)
<bob2> ah
<chrisa> hrm, is there a sane way to completely upgrade a sid system to ubuntu?
<bob2> you can use pinning.
<lamont> chrisa: apt doesn't consider it a true upgrade
<bob2> but it's kinda dodgy.
<justdave> back up the important stuff, wipe it out, and install from a CD?  sid has newer versions than a lot of what's in Ubuntu.  It'll be messy.
<lamont> since some packages are newer (higher version) in sid than in warty, and vice versa
<chrisa> lamont: Right, I've noticed (due to various epochs and version numbers)
<justdave> if you want to go that route, it might be safer to wait until Hoary opens for development, and update from the development repository.
<justdave> (it'll be a more-recent snapshot of sid, and not frozen yet)
<lamont> chrisa: sadly, it's completey unsupportable.  woody->warty, no problem.  sarge/sid from before 2004-06-28, should be no problem.  sarge/sid from after that, install, or go the masochistic route first, and eventually probably do the install anyway
<lamont> or wait for hoary to open
<chrisa> lamont: I realize that, I'm just experimenting on a sid box I'm not concerned with for fun really
<kylem> heh, force downgrade to <2004-06-28 via snapshot.d.n, and upgrade? ;=)
<chrisa> I wouldn't do this on a serious system
<lamont> ah, well, there is on sane way to cross grade from current sid to warty.
<chrisa> kylem: You're nuts!
<kylem> thank you.
* lamont ^5s kylem
<lamont> hrm.. still have about 600MB of free space in my dvd tree.  what to add....
<chrisa> lamont: what is this supposed sane way?
<lamont> s/on/no/
<chrisa> ah
<chrisa> I think this box needs ruining, I'll try kyle's method
* lamont hands chrisa some rubber gloves
* chrisa chuckles as he watches this take place
<fabbione> lamont: any more testing for the live?
<lamont> fabbione: waiting for artwork from jeff
<tseng> artwork..
<lamont> planned changes from rc to rc2 are: (1) grub screen, (2) new WinFOSS.
* tseng yawns
<lamont> fabbione: if you grab -16 and want to play with a firmware-needing card to see if that works, that'd be way cool
<vorlon> daniels: hum, ifplugd always seems to work for me.  ... "Packet filtered"?
<elmo_> lamont: have you got a firmware for these aironet pcmcia cards you're fond of?  the cisco website wants some username/password and doesn't accept the one it gave me
<fabbione> lamont: i don't have any firmware based card.. sorry
<fabbione> elmo_: already up?
<fabbione> or you didn't go to sleep yet?
<lamont> elmo_: not sure - I can poke someone tomorrow to see what version they have
<jdub> lamont: do you have the grub.conf for the livecd?
<lamont> jdub: I expect so.. let me go look
<jdub> lamont: or know if it grub itself is modified in any way?
* vorlon was actually wondering why Warty didn't use ifplugd, and I guess breaking things would be a good reason. ;)
<jdub> lamont: oh
<jdub> lamont: hold on, it's using gfxboot fork
<elmo_> fabbione: not slept yet
<elmo_> lamont: cool thanks
<lamont> jdub: yes - gfxboot-grub
<lamont> elmo_: what version firmware do you have?
<lamont> and 350, I assume?
<elmo_> Firmware Version: 5.02.19
<lamont> jdub: I have the complete gfxboot-grub tree that built the package, if that helps...
<elmo_> yeah, 360
<elmo_> err 350
<lamont> 360?
<lamont> ok
<daniels> vorlon: yeah, it bonged up my interface
<lamont> jdub: http://people.ubuntulinux.org/~lamont/LiveCD/morphix/source/morphix-iso-grubtheme_0.1-3ubuntu4.dsc
<lamont> and tar.gz
<lamont> jdub: work for you if I go to bed at this point, and plan to build in about 8 hours?
<jdub> ok
<lamont> jdub: anything else you need before I crash?
<jdub> nup, should be ok :)
<jdub> thanks
<lamont> thanks.  artwork hacking isn't my forte and all that...
<jdub> hrm, do you stil lhave a copy of the current pcx?
* lamont decides to start his warty-release DVD burn before he sleeps
<lamont> the current pcx is in that source package
<lamont> (that _is_ the source package that built the current world...)
<lamont> o
<jdub> rock, ta
<lamont> or did you mean the morphix thing?
<KeyserSoze> hello
<jdub> ha, the morphix one
<fabbione> hey KeyserSoze !
<KeyserSoze> hey man
<fabbione> guys...
<fabbione> KeyserSoze has a problem on ubuntu on amd64
<fabbione> perhaps someone here can help him?
<KeyserSoze> yeah please
<KeyserSoze> trying to get an oracle install going
<jdub> there's your problem
<jdub> oh
<lamont> jdub: if you do wnat the morphix one, it's scp-able from chinstrap:~lamont/morphix.pcx
<jdub> ;)
<KeyserSoze> but we get this error from the jre:
<KeyserSoze> current locale is not supported in X11, locale is set to CX locale modifiers are not supported, using defaultException in thread "main" java.lang.InternalError: Current locale is not supported
<fabbione> we already checked the locale
<KeyserSoze> and no matter what I try it still thinks its on locale CX
<fabbione> and it is set properlyu
<fabbione> can it be an amd64 glitch?
<mdz> what is the locale set to?
<mdz> let's take this to #ubuntu, it's not development-related
<fabbione> mdz: i told him to join here
<mdz> fabbione: why?
<KeyserSoze> ok I'll go to ubuntu I don't care
<lamont> jdub: you're done with artwork for me already>
<lamont> ?
<jdub> i hope so
<jdub> might look like poo
<jdub> aren't you in bed yet? :)
<lamont> feh. Now I have to stay up for a while
<jdub> heh
<lamont> should I care that you sent it twice?
<jdub> geez
<jdub> that'd be evo
<jdub> stupid thing
<lamont> hrm... actually, -4 was my screwing around, I think,.
<lamont> -3ubuntu3 was really what we're using
<lamont> anyway, building -3ubuntu5 now
* lamont will test the home edition first, in about an hour or so.
* lamont passes the time by burning his 3.7GB warty install dvd
<jdub> heh, nice
<lamont> all of main, and a little bit of universe.  binary and source
<lamont> basically, my full mirror + the udebs
<lamont> must kill d-i for not dealing well with having Packages.gz instead of Packages....
<lamont> this'll be interesting... burning a dvd+rw and a cd-rw at the same time...  cdrw drive is slave on the bus with the DVD...
<lamont> burning home edition
<jdub> have we disabled uploads yet?
<lamont> pretty sure
<jdub> should probably do it soon
<jdub> cool
<lamont> was talk of allowing uploads to fix previously-ftbfs packages in universe/multiverse, and I need to upload a new mplayer to multiverse once I'm done with livecd..
<jdub> yeah
<lamont> right now, it works for anyone with a Xeon, and no one else.:-(
<jdub> ouch
<lamont> I gave it about 2 minutes today, but that attempt was FTBFS
<lamont> basically, it built customized for the buildd hardware, instead of runtime cpu detection
<lamont> dvd write went from 2.4x to 0.6x :-(
<lamont> otoh, pio-based cdrw write is chunking along quite happily
* lamont discovered macadamia toffee this week
<lamont> cdrw fixating
<lamont> dvd getting squat
<lamont> jdub: did you touchup the logo at all on the grub screen?
<lamont> btw, timer working perfectly.
<lamont> not as cute, but definitely working. :)
<jdub> lamont: kinda
<lamont> ok
<jdub> lamont: not as cute as...? how can i make it better?
<lamont> jdub: I had officially declared the double bar thing to be "cute".
<jdub> ahr
<jdub> so now it's just white bars on a brown background?
<lamont> http://people.ubuntulinux.org/~lamont/testing/LiveCD/20041021-06/warty-live-i386-20041021-06.iso
<jdub> thaytan put release dates on the generated release names :)
<lamont> white _bar_ (full width), instead of 2 partially white bars at 1/3 width
<lamont> jdub: too much time, I tell ya
<lamont> jdub: you have enough bandwidth to test that image?
<jdub> no :|
<lamont> I'm going to bed, mind you.
* ..[topic/#ubuntu-devel:lamont] : Ubuntu development -- general discussion on #ubuntu | Happy Warty Day! | 13 (count 'em) major bugs | BE THE SIGNAL | Warty release is DONE | please test http://people.ubuntulinux.org/~lamont/testing/LiveCD/20041021-06/warty-live-i386-20041021-06.iso so it can be warty-rc2-live-i386.iso
<jdub> ahr
<jdub> okay, will chat to you about making it sexier in the morning
<jdub> ooh - could i get a photo? :)
<lamont> camera is in the car.
<lamont> must I ?
<KeyserSoze> can anyone confirm for me that they can run a java app under ubuntu on amd64 using either blackdown or sun jre please?
* lamont goes to the car
<jdub> lamont: nah, don't worry
<lamont> ew. bad burn
<lamont> have camera, rebooting now
<Mitario> wohoo, all trashapplet boogs are fixed
<lamont> http://people.u.c/~lamont/dscn1379.jpg
<lamont> and the arrows are even where they belong. :-)
<jdub> heh
<jdub> ok, so, gotta do something with the top left
<lamont> "resistance is futile"
<lamont> anyway, send me more artwork.  night.
<jdub> thanks!
<jdub> night
<Mitario> hmm, it's getting light already :) time to go to bed
<pitti> Morning
<pitti> mdz_: still here?
<thom> ello
* fabbione kicks X straight in the balls
<fabbione> hey thom
<fabbione> thom: how was the party yesterday?
<thom> it was cool
<thom> good bunch turned up
<fabbione> nice
<pitti> Hi thom
<pitti> hi fabbione
<fabbione> hey pitti
<pitti> fabbione: been at a release party as well? In some LUG?
<pitti> Gosh, this thing gets longer and longer
<fabbione> pitti: no.. at home sandpapering walls and taking away 20 huge plastic bags of trash from the works
<pitti> I mean the channel subject :-)
<pitti> fabbione: oh, sounds like exactly the right thing to do after an exhausting release day :-)
<fabbione> pitti: of course 
<pitti> thom: since elmo is not yet here, do you happen to know how and whether the security upload queues work?
<thom> fraid not dude
<pitti> I just saw that DSA 570-1 and 571-1 are unapplied in Warty
<fabbione> pitti: elmo was working on it
<fabbione> pitti: i have the packages read for these 2 already
<fabbione> pitti: so don't worry
<pitti> fabbione: oh fine, I already wanted to prepare some :-)
<fabbione> pitti: mdz and I coordinated a while ago
<fabbione> before the sec team election
<pitti> okay, fine
<pitti> then I can throttle my nerves again
<fabbione> eheh
<pitti> and let my head continue to ache :-/
<fabbione> i need to go back to X.org
<fabbione> THIS SOURCE IS SO FUCKING INCONSISTENT!
* pitti does not like to get up at 6 o'clock
<pitti> fabbione: oh, speaking of headaches... :-)
<pitti> sometimes I already thought that rewriting X from scratch might be faster :-)
<pitti> writing some nice drivers to speed up the framebuffer and basically use this :-) </dream>
<pitti> fabbione: anyway, I cross my fingers that you and daniel tame the beast
<fabbione> pitti: the problem is not the beast itself
<fabbione> it's splitting the beast
<fabbione> and forward-porting the patches we have
<fabbione> to get it to build
<pitti> fabbione: I'm curious. Didn't the fd.o version already split components?
<fabbione> next step is manage to put everything into nice little tiny debian pacakges
<pitti> or was that X.org?
<fabbione> pitti: no
<fabbione> that's only daniels 
<fabbione> X.org is still monolitich
<pitti> I thought there wer already efforts in this direction
<fabbione> and i am going to CRACK IT
* pitti gives fabbione a huge hammer
<fabbione> 'C0Z I 4M 4 L33T H4CK35
<pitti> so "crack of the day" has a completely different meaning to you :-)
<jamesh> fabbione: would an X display problem that disappears when I boot with acpi=no likely be an X problem, or a hardware problem?
<jamesh> (this is on an athlon64)
<fabbione> jamesh: yes.. everything can be when it goes to amd64 and X
<fabbione> and it can be easily an X problem
<fabbione> Xfree86 didn't get much love on amd64 as X.org did
<jamesh> fabbione: okay.  With ACPI enabled, it displays random garbage, except for the mouse cursor
<jamesh> with acpi=no, it works perfectly.
<fabbione> jamesh: ok. please open a bug with all the info
<fabbione> such as videocard and so on
<jamesh> okay.
<fabbione> exact models of the laptop, logfiles with both working and nonworking X
<fabbione> jamesh: make it a normal severity
<fabbione> there is really nothing i can do to make it working at the moment
<fabbione> we will have to see with X.org
<jamesh> is there an easy way to get the log file from a previous run of the X server?
<fabbione> jamesh: try checking /var/log
<jamesh> I had to restart the machine when X screwed up
<fabbione> afaik there is a backup of the log
<fabbione> well please send both
<fabbione> i need them to check
<jamesh> yes there is.
<jamesh> fabbione: interesting.  the .old log file says it finds an AGP card, while the current one says it found a PCI card ...
<jamesh> I'll restart to make sure I've got the right logs though.
<pitti> sjoerd: here?
<thom> pitti: so that firefox javascript crasher? is apparently much harder to trigger if your LOCALE is en_US *sigh*
<seb128> morning
<pitti> thom: what, is it still in 0.9.3? Never occurred for me any more since we downgraded
<pitti> Hi seb128
<thom> no, not in 0.9.3
<pitti> thom: or do you prepare packages for 1.0?
<thom> just explaining why mdz/lamont couldn't trigger it
<thom> (this is from upstream)
<pitti> thom: ah, nice idea
<pitti> thom: I use de_DE.UTF-8
<thom> yeah
<seb128> hello pitti 
<thom> and i'm on en_GB
<pitti> they don't like non-Americans :-)
<pitti> jdub: can we still add feature goals for Hoary to the Wiki?
<pitti> jdub: we sort them out later anyway, but I'd like to drop some ideas there
<Sledge> morning
<thom> hey sledge. get back ok last night?
<Sledge> not too bad
<Sledge> only got to 2.20am... :-/
<Sledge> so I'm feeling really bright and with it this morning
<Sledge> :-)
<thom> heh
<sivang> morning all
<sabdfl> morning all
<dyn> morning :)
<seb128> hello sabdfl 
<tuo2> god morgan, sabdfl 
<fabbione> hey sabdfl 
<sabdfl> fabbione! 
<fabbione> sabdfl: how was the party?
<fabbione> sabdfl: i have a good news and a bad news.. which one first?
<sabdfl> good news today!
<fabbione> sabdfl: the work on X.org is progressing pretty good
* sabdfl normally prefers the beef before the ice cream
<sabdfl> ok
<sabdfl> when's daniels due in cph?
<fabbione> the bad news is that is much more than what I expected.
<fabbione> sabdfl: 1st nov.
<sabdfl> ok
<fabbione> manly because they reorganized a good portion of the tree
<sabdfl> do we have x.org in arch yet?
<fabbione> that makes some stuff more complex
<fabbione> sabdfl: nope
<fabbione> we need xfree86 and x.org in arch
<fabbione> for the patch forwarding
<fabbione> that's what is actually taking more time than expected
<lupus_> not debrix? :)
<sjoerd> pitti: pong
<pitti> Hi!
<pitti> sjoerd: back from class?
<pitti> sjoerd: bad news! modifying g-v-m as I thought yesterday does not work
<pitti> sjoerd: gnome exports an interface for unmounting a device, but not for mounting it
<sjoerd> pitti: just arrived at the uni..
<pitti> sjoerd: it has a function for listing all connected drives, but new USB devices don't appear there
<pitti> sjoerd: this might get better if g-vfs is compiled with hal support, but until then g-v-m has to call mount on its own
<sjoerd> pitti: we'll see
<sjoerd> pitti: donno if gvfs with the new hal patches shows all volumes or only the ones in fstab
<pitti> sjoerd: BTW, I'm currently ubuntu-fying your hal package; you still conflict to g-v-m << 0.9.10, but it should be << 1.0.2
<pitti> sjoerd: will you change that for Debian
<pitti> sjoerd: the older g-v-m expected a different storage semantics, which don't work with the newer hal
<sjoerd> pitti: for debian 0.9.10 is good enough.. that's why it's still that way
<pitti> sjoerd: oh, okay
<sjoerd> pitti: debian's 0.9.10 was a cvs, that's why it worked
<pitti> sjoerd: you cheated :-)
<pitti> sjoerd: no, just kidding
<sjoerd> pitti: i'll probably do << 1.0.2 for the new packages then.. people should be using that anyway
<__daniel> hai
<kOoLiNuS> hi to everyone!
<__daniel> hi kOoLiNuS
<pitti> Hi kOoLiNuS
<kOoLiNuS> one quick question, can I ?
<pitti> you can do everything, kOoLiNuS :-)
<pitti> EMISSINGFULLVERB
<thom> if you have a question please just ask it
<pitti> thom: btw, you hacked on hal a bit, right?
<thom> a bit
<kOoLiNuS> yes
<pitti> thom: does "libselinux-dev build dependency" ring any bell?
<kOoLiNuS> i've tried the very first relase of Warty
<pitti> thom: I don't know what it was good for and hal builds fine without
<kOoLiNuS> and i was disappointed by the "crippled" Gnome-System-Tools
<pitti> thom: the Debian package does not have it either
<thom> pitti: the reason for the build-dep was to work around a bug in the selinux packages at the time, iirc
<pitti> kOoLiNuS: what's missing?
<mjg59> kOoLiNuS: That's an upstream decision
<mjg59> The tools that aren't supplied are no longer supported
<pitti> thom: what has hal to do with these packages?
<thom> pitti: (they shipped the .so in the main package, so configure would pick it up and enable selinux support, which would then blow up cos of the lack of headers)
<kOoLiNuS> I'm still in the devel ml, so I was wondering if I can "force" the installation of the "complete" package from the testing repos
<pitti> thom: darn
<mjg59> kOoLiNuS: If you download the source, you can (I /think/) change the configure options in debian/rules and the rebuild the package
<mjg59> That's assuming that you can still force the build of the unsupported tools - I'm not sure about that
<kOoLiNuS> mjg59: too far difficoult for me :-/
<pitti> thom: my hald is not linked against libselinux, so I guess I can safely drop the dependency
<thom> pitti: yeah
<fabbione> elmo_: are you already awake?
<pitti> daniels: here?
<seb128> kOoLiNuS: apt-get source gnome-system-tools && apt-get build-dep gnome-system-tools && cd gnome-system-tools-1.0.0, add --enable-boot --enable-services --enable-disks in configure options debian/rules and then dpkg-buildpackage to build the package ...
<kOoLiNuS> seb128: ok, note taken :-D thanks
<seb128> kOoLiNuS: but these modules are not supported and bugged so probably not a good idea
<kOoLiNuS> on SID the've worked
<seb128> they have been removed
<seb128> there is a reason :)
<seb128> what are you trying to do ?
<kOoLiNuS> seb128: yeah ? didn't know
<kOoLiNuS> modify the services started at boot time graphically
<kOoLiNuS> or
<seb128> kOoLiNuS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271859
<kOoLiNuS> if I install (L)AMP for toying around with my blog I do not want them to start everytime, I am on a Laptop
<elmo_> fabbione: yeah
<__daniel> kOoLiNuS, i only have a non-graphic variant for you:    cd /etc/init.d; update-rc.d <name-of-service> remove     but listen to suggestions of the others, too :-)
<kOoLiNuS> seb128: perfect .... some fedora testing friend of mine did tell me something (not accurate as your link) on this 
<kOoLiNuS> __daniel: if I had the competence to do that I would not miss it :-D
* kOoLiNuS is going to have lunch
<fabbione> elmo_: will you ping me when ready for the upload? or do you want me to ping you?
* pitti enjoys his shiny new hal_0.4.0-1ubuntu1
<carlos> is hoary repository open already?
<carlos> could I move to it?
<elmo_> fabbione: oh, right, meh, working on it - I'll ping you in a bit
<thom> no and no
<elmo_> carlos: no, no
<elmo_> thom: copycat
<carlos> ok
<carlos> :-)
<fabbione> elmo_: ok :-)
<jamesh> how's this look? http://www.gnome.org/~jamesh/images/drive-mount-applet.png
<pitti> jamesh: nice!
<pitti> jamesh: you finally made an applet?
<jamesh> pitti: yeah.  It was a bit fiddly to get the sizing right.
<jamesh> but it works pretty well now.
<pitti> jamesh: any upload plans already?
<jamesh> I still need to do a bit more testing
<pitti> jamesh: okay, nice. Will you upload this to experimental/sid as well?
<jamesh> pitti: I'm planning on getting it merged into gnome-applets (since it is meant to replace one of the existing applets).  I haven't considered packaging it separately
<pitti> jamesh: oh right, even better
<fabbione> daniels: you around?
<carlos> so, finally we are not going to have our final release in the main page of slashdot?
<lamont> jdub?
<thom> carlos: no
<carlos> :-(
<thom> *shrug*, they have given us like 4 stories in the last month
<sabdfl> carlos: no, they said the main page had had enough ubuntu coverage
<carlos> :-?
<carlos> so a final release cannot be there but a Xandros betatesting process can
<carlos> funny
<chrisa> Why isn't trashapplet in gnome-applets?
<sabdfl> chrisa: we picked it up before it had yet gone mainstream
<sabdfl> but expect it to become part of the main gnome release
<chrisa> ah
<seb128> it's already in gnome-applets cvs head
<fabbione> guys is very familiar with libraries that can help me 2 minutes?
<amu> Kamion: btw. lolo synced it :) 
<Kamion> amu: cool
<__daniel> just wrote a mail to heise.de to make them cover the ubuntu release :-)
<amu> http://source.rfc822.org/pub/mirror/releases.ubuntu.com/warty/
<fabbione> well.. i meant who is very familiar...
<seb128> fabbione: you should just ask ...
<seb128> usually the "who is very .. with ..." kind of questions don't get a lot of replies
<fabbione> seb128: well i need to understand how to split a lib in general
<fabbione> `-- lib
<fabbione>     |-- libFS.a
<fabbione>     |-- libFS.so -> libFS.so.6.0
<fabbione>     |-- libFS.so.6 -> libFS.so.6.0
<fabbione>     `-- libFS.so.6.0
<fabbione> libFS.a -> libfs-dev
<fabbione> libFS.so.6.0 -> libfs6 ?
<fabbione> and the other 2?
<Kamion> yes; libFS.so -> libfs-dev, libFS.so.6 -> libfs6
<fabbione> ok thanks!
<fabbione> that makes it simple
<fabbione> :-)
<fabbione> i already have enough headackes splitting X to dig into each single piece
* fabbione does really appreciate
<seb128> .a / .la / .so -> -dev
<seb128> .so.x and .so.x.y.z -> lib
<fabbione> thanks seb :-)
<seb128> you're welcome :)
<fabbione> now the big question is.. which directory should i start polluting if i kill /usr/include/X11 and /usr/X11R6 ?
<pitti> fabbione: you kill /usr/X11R6?
* pitti praises fabbione
<pitti> fabbione: why not just put the stuff in /usr/lib/X11 and the executables in /usr/bin?
<pitti> fabbione: IMHO /usr/bin can't be made worse, pollute-wise
<Kamion> I thought that was roughly the plan
<fabbione> pitti: i need somewhere where to store the includes
<fabbione> and nothing is allowed to stick <whatever>/X11
<pitti> fabbione: but why do you want to kill /usr/include/X11?
<pitti> fabbione: it seems fairly "canonical" to me :-)
<fabbione> pitti: it's a synlink to ../X11R6/inlucde
<fabbione> pitti: see also policy
<Kamion> you can't kill /usr/include/X11 as such; people do #include <X11/foo.h>
<pitti> fabbione: right, I mean why not put the includes in /usr/include/X11 directly?
* lamont takes kids to school. bbiab
<fabbione> Kamion: i know that
<Kamion> but you're going to run into dpkg hell trying to replace a directory with a symlink
<fabbione> Kamion: i need an alternate location
<Kamion> er, vice versa
<fabbione> Kamion: it is already a symnlink
<Kamion> 13:44 < Kamion> er, vice versa
<fabbione> http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.7
<fabbione> Packages must not provide or install files into the directories /usr/bin/X11/, /usr/include/X11/ or /usr/lib/X11/.
<Kamion> yes, I know
<Kamion> I was involved in that policy discussion :P
<fabbione> and i don't want to go against policy
<fabbione> but neither i can pollute *
<Kamion> that bit of policy was taken in order to smooth the path for a future move of XFree86 to /usr
<Kamion> s/taken/created/
<fabbione> Kamion: correct
<Kamion> I do not think that you should regard it as constraining X.org packages
<fabbione> but now that i am moving X to /usr
<fabbione> Xfree86 or X.org.. still the same stuff
<fabbione> it's an Xserver
<Kamion> the other alternative is /usr/X.org and keep the symlinks, would be simpler, but you don't get to lose the old hack
<fabbione> or X Windows System
<Kamion> I *know* :)
<Kamion> ok, "I do not think that you should regard it as constraining XFree86 or X.org packages"
<fabbione> ahh sorry
<fabbione> i misread
<fabbione> but neither i want to start another mess creating /usr/x.org
<fabbione> makes no sence to me
<fabbione> at that point i could just keep /usr/X11R6
<fabbione> without messing around
* fabbione needs to see 2 minutes of sunshine in the hope that God will kiss his forehead
<fabbione> i will have to discuss it with Branden
<fabbione> i don't see a clean solution to this
<Ubuntu-Linux> i reported another bug
<Ubuntu-Linux> https://bugzilla.ubuntu.com/show_bug.cgi?id=2601
<Ubuntu-Linux> is the person who email addy cjwatson@canonical.com here?
<Kamion> yes
<Ubuntu-Linux> who is it?
<Kamion> me
* Ubuntu-Linux want  to poke that person
* Ubuntu-Linux pokes Kamion
<tseng> Ubuntu-Linux: poking on bugs works, bugzilla sends out an email with changes
<Kamion> if you're objecting to the severity change, I downgraded it as a routine bug management issue because problems on a single piece of hardware don't justify the 'blocker' severity.
<Ubuntu-Linux> Kamion: tree.. had to help me when you where the one in charges shess
<Kamion> I can't help everybody individually.
<Kamion> there's this small matter of "time"
<Ubuntu-Linux> i know
<Kamion> I also don't know what your problem is, and I was put off helping you by statements like "Ubuntu messed with d-i".
<Ubuntu-Linux> but you where there at the same time that i ask and where active
<Ubuntu-Linux> they did
<Ubuntu-Linux> it now says ubuntu when you boot up
<Ubuntu-Linux> that even called messing
<azeem> Ubuntu-Linux: crap, Ubuntu writes 'ubuntu' instead of 'debian' when it boots up?
<Ubuntu-Linux> i change the aphla d-i i used to say my name
<Ubuntu-Linux> i even messed with d-i
<Ubuntu-Linux> 0_0
<Ubuntu-Linux> who hasnt?
<bob2> people with a job and/or hobby.
<azeem> I don't understand your problem (but then, I didn't read the bug-report either)
<Ubuntu-Linux> what a geek which doesnt mess with his installer to say his name?
* tseng doesnt
* chrisa doesn't
<Kamion> please take the chatter off #ubuntu-devel, thanks.
* __daniel shakes his head in disbelief
<Ubuntu-Linux> azeem: read it
<tseng> Ubuntu-Linux: hey bud
<tseng> Ubuntu-Linux: the developers have a nice, prioritized list of bug reports. so if you could just hang in patiently, someone will get around to yours
<tseng> it doesnt help your case much by pestering people directly
<Ubuntu-Linux> i have d-i BUG
<tseng> i have a kernel BUG
<Kamion> so far the pestering means it's at the bottom of my priority list
* Ubuntu-Linux want to install ubuntu
<chrisa> Ubuntu-Linux: You're not listening
* Ubuntu-Linux doesnt want to d/l d-i and do a net install
<Ubuntu-Linux> i know
<Ubuntu-Linux> but Kamion is in charge of d-i and person x is in chage of x
<azeem> Ubuntu-Linux: send a patch, like everybody else does
<Kamion> Ubuntu-Linux: guess how many bugs that means I have
<Ubuntu-Linux> Kamion which is in charge of y doesnt do x
<chrisa> On a sidenote, I really hope "ubuntu-linux" is a default irc name for the clients and that he didn't actively choose that nick
<chrisa> But that's just me...
<Ubuntu-Linux> Kamion: 2601?
<Kamion> chrisa: it's not, as far as I know
<bob2> chrisa: it's not
* Ubuntu-Linux own ubuntu-linux
<bob2> chrisa: he was in #debian as GNU-Debian and shimon for a while, too
<chrisa> bob2: sigh
* tseng sighs and goes to class
<tseng> g'day boys and girls
<thom> cya tseng
<Ubuntu-Linux> ok so how long till i can get ubuntu installed?
<__daniel> Ubuntu-Linux, TRY to be patient - you won't achieve anything by pestering people
<Ubuntu-Linux> or should i just d/l d-i and upgrade to ubuntu?
<Ubuntu-Linux> __daniel: i know
<Ubuntu-Linux> i am waiting
<Ubuntu-Linux> i just want to know if i should goto sleep tonight and forget about it till sunday
<azeem> Ubuntu-Linux: no, you are pestering. Waiting is without the 'how long till...?' part
<chrisa> Yes, do that
<chrisa> If you really cared, you'd just install woody and upgrade
<Ubuntu-Linux> i cant install woody
<Ubuntu-Linux> i need to install from 2.4.26 or later
<chrisa> Then go to sleep
<Ubuntu-Linux> because of drivers
<Ubuntu-Linux> so should i d/l d-i net install?
<pitti> Ubuntu-Linux: why you can't download the ISO?
<Ubuntu-Linux> and add the ubuntu sources and upgrade?
<__daniel> Ubuntu-Linux, try to
<chrisa> Do what you want to do, staying here and pestering Kamion will get you nowhere
<Kamion> Ubuntu-Linux: please do not upgrade the severity of that bug report again.
<Ubuntu-Linux> which one pitti
<pitti> Ubuntu-Linux: recently I installed a CD-ROM less laptop with the netboot images, that went fine
<Ubuntu-Linux> Kamion: i didnt
<pitti> Ubuntu-Linux: which one? the release ones?
<Ubuntu-Linux> i just repily 
<Ubuntu-Linux> i got no network
<Ubuntu-Linux> but i can do debian d-i netinst
<pitti> Ubuntu-Linux: then go ahead with that
<Ubuntu-Linux> ok will there be any problem if i install from debian sarge d-i
<Kamion> shimen@gmail.com changed:
<Kamion>            What    |Removed                     |Added
<Kamion> ----------------------------------------------------------------------------
<Kamion>            Severity|normal                      |blocker
<Ubuntu-Linux> pitti: i am froced to use manbrake
<bob2> you're not forced to do anything
<bob2> if you can install sarge, you can move to ubuntu
<pitti> Ubuntu-Linux: you can't download the ISO from anywhere?
<Ubuntu-Linux> Kamion: what setting should it be on my side
<Kamion> Ubuntu-Linux: I changed it to normal. Please leave it there.
<Ubuntu-Linux> pitti: my hdd died and it was the only cd i had i d/l and burned ubuntu
<pitti> Ubuntu-Linux: so you _have_ an Ubuntu CD?
<Ubuntu-Linux> Kamion: yea but on my side its still blocker and p5
<Ubuntu-Linux> yes
<pitti> Ubuntu-Linux: an older one perhaps?
<Ubuntu-Linux> the final
<Ubuntu-Linux> no latest
<pitti> Ubuntu-Linux: ah, and this doesn't boot for you?
<pitti> Ubuntu-Linux: you are the G5 guy?
<Ubuntu-Linux> it a fscking driver problem
<Ubuntu-Linux> it does boot for me
<Kamion> Ubuntu-Linux: reload.
<Ubuntu-Linux> ptti MIND reading my bug
<Kamion> 00:1f.2 IDE interface: Intel Corp. 82801EB Ultra ATA Storage Controller (rev 02)
<Kamion> that's strange, I can't see that in /usr/share/misc/pci.ids
<Ubuntu-Linux> ohh
<Ubuntu-Linux> wait
<Ubuntu-Linux> i enabled emation of sata as pata
<Ubuntu-Linux> does that matter?
* Ubuntu-Linux reboots goes from bios and see if it helps
<Kamion> hm, maybe it's 808624db
<Kamion> which is ide/piix in discover
<Ubuntu-Linux> *because i was using a 2.4 kernel and no FULL sata support
<Ubuntu-Linux> Kamion: so should i disable emalation
<Kamion> worth a try
<Ubuntu-Linux> ok
<Ubuntu-Linux> brb
<Kamion> also check that the piix and ata_piix modules are loaded
<Ubuntu-Linux> if i am not back in 4min then its working
<Ubuntu-Linux> ok
<dyn> please.. dont..
<__daniel> Kamion, i admire your patience :-)
<Kamion> I don't have much of it left
<__daniel> Kamion, i think you did quite well
* Sledge applauds Kamion for restraint
<fabbione> i think we will live with X11R6 until there is a better solution
<fabbione> killing it now isn't an option without polluting *
<azeem> better solution than X11R6 or better solution than what you thought up till now?
<fabbione> azeem: read above :-)
<fabbione> by policy we can't install into */X11
<azeem> oh, missed that, sorry
<fabbione> azeem: if you have better ideas, please say so
<azeem> then change policy :)
<fabbione> it's not like i am closed mind
<fabbione> azeem: that will take too long :-)))
<azeem> well, I don't know about the dpkg limitation for using /usr/include/X11 directly, but that would be the cleanest IMHO
<fabbione> and few flames all over
<azeem> /usr/bin for binaries and perhaps a subdir for /usr/lib, whatever the name
<fabbione> azeem: there are no limitations in using X11 in general
<fabbione> but if i start creating subdirs around..
<azeem> well, the part about replacing a symlink
<fabbione> i can just live with X11R6
<fabbione> see.. either we integrate everything inside the FHS (considering X11R6 not fHS compliant)
<fabbione> or otherwise it's not worth the mess to just rename 2 directories/symlinks
<azeem> having subdirs in /usr/{include,lib} is common practise for libraries
<fabbione> (considering the amount of packages that use then)
<azeem> having subdire in /usr is not
<fabbione> true.. i don't disagree on this
<azeem> perhaps you could swap it around and live compatiblity symlinks in /usr/X11R6 (pointing to /usr/{include,lib}/X11 for a while?
<azeem> and then kill them off eventually
<azeem> (like /usr/doc, hahaha)
<fabbione> azeem: eventually = undetermined amount of time.
<fabbione> no i am not that nice with other maintainers :-P
<azeem> one release 
<azeem> which means, half a year for ubuntu and an undetermined amount of time for Debian
<fabbione> azeem: another release = 6 months here and something between 4 to 10 years in debian
<fabbione> exactly :P
* azeem ^5s fabbione 
<fabbione> no i think i will leave X11R6 for now
<fabbione> the changes are too deep to be done by a single/two persons
<fabbione> we need a team working on it.
<fabbione> (without considering the amount of changes that the code requires)
<azeem> what's wrong with swapping the symlinks around? Is there a technical problem with that?
<fabbione> this definetly has to be done upstream
<azeem> at least, that would set a signal that X11R6 is deprecated
<fabbione> azeem: probably swapping them no.
<Kamion> swapping the symlinks around requires some very hairy preinst code and probably has undetermined compatibility implications ...
<fabbione> but i wonder when X12R1 will be out...
<fabbione> and a big API change will take place
<fabbione> it's going to be the hell storing includes all in /usr/include/X11
<fabbione> we need to be able to differenciate them
<fabbione> at least...
<azeem> well, X12R1 will have /usr/include/X12, no?
<Kamion> X11 and X12 will *have* to be co-installable
<Kamion> at least the libraries and preferably development packages
<azeem> yeah
<azeem> if you want the static libs to be parallel installable, but them in a subdir of /lib
<azeem> eh, /usr/lib
<bob2> X12 is on the cards?
<azeem> how do the other distributions handle this? Most of them have switched to x.org by now, havent' they?
<fabbione> uh true :)
<fabbione> azeem: yes. but i doubt they have remove X11R6
<azeem> we're at X11R8 or so right now?
<fabbione> 6.8.1
<azeem> eh, aren't we at X11R8 or so right now?
<azeem> ah
<fabbione> X11R6
<azeem> sorry
<azeem> so, X12 on the radar, or X11R7?
<fabbione> nothing on the radar atm
<fabbione> i am just pondering for the future
<azeem> what compatibility promises have the X guys taken?
<azeem> will they break binary compatibility with X11R7?
<fabbione> they shouldn't...
<fabbione> afaik
<azeem> godd
<azeem> eh, good
<fabbione> i can't remember if RX was for the binary compatibility and X11 the version of the protocol
<fabbione> so new version of the protocol breaks world
<fabbione> and binary compatibility kinda
<bob2> when was the last time X broke compatibility?
<bob2> er, ABI.
<fabbione> can't remember
<fabbione> probably 3.3 -> 4.0
<bob2> fabbione: did you have much to do with X before joining the XSF?
<azeem> fabbione: what about you ask keithp for his opinion? Isn't he a DD now?
<fabbione> bob2: no
<fabbione> anyway removing /usr/include/X11 is not an option
<bob2> hah, wow, you got sucked in quick :-)
<fabbione> some x packages build-deps on packages that pulls in other x packages
<fabbione> including stuff in /usr/include/X11
<fabbione> azeem: i am still thinking... and more i think, more i am convinced that upstream is the first one that should do it
<azeem> I don't see a need to remove /include/X11. Would you just dump everything in /include?
<fabbione> azeem: if i dump everything in /usr/include it will be a mess
<Kamion> azeem: you'd have to change every X program
<fabbione> i still need a X11 symlink
<Kamion> getting rid of /usr/include/X11/ would be broken
<fabbione> #include <X11/foo.h> 0wns you
<fabbione> and switching it from a symlink to a dir will make X or X.org unbuildable
<fabbione> wow
<pitti> fabbione: right, so what exactly is wrong with /usr/include/X11? Just because it's a symlink?
<fabbione> i guess we will live with X11R6 :-)
<fabbione> pitti: no
<pitti> fabbione: okay, you just answered.
<azeem> fabbione: at least mandrake still uses X11R6, I just asked
<azeem> probably the others as well. So I guess it's the right way for now
<fabbione> yeps
* fabbione reverts the changes
<azeem> fabbione: anyway, why would switching /usr/include/X11 from a symlink to a dir make X or X.org unbuildable?
<fabbione> azeem: because almost all the documentation requires groff
<fabbione> and groff pulls in several X stuff
<fabbione> including things in /usr/X11R6/include
<azeem> oh, circular Build-Depends?
<fabbione> yeps
<azeem> suck
<fabbione> if we fuck up one upload nobody will build anything for a long while
<Kamion> uh, the groff source package has documentation of how to avoid the X build-dependency
<Kamion> but yes, groff is just one example of the zillion programs that want /usr/include/X11/
<fabbione> Kamion: than i will need a xgroff to build x
<Kamion> ?
<fabbione> groff simply depends on these packages
<Kamion> no you don't, you build groff with DEB_BUILD_OPTIONS=groff-no-x11, then you build X, then you build groff properly
<fabbione> Kamion: so you need a temporary groff around
<Kamion> yes, welcome to bootstrapping
<Kamion> it's only gxditview that needs X11
<fabbione> Kamion: it would be easier for me to create a anti-x-groff and upload it :-)
<Kamion> and die shortly afterwards :)
<Kamion> tetex is no different
<Kamion> you need it for some of the docs too AIUI, but it build-deps on X
<fabbione> yeah i also build-dep on tetex
<fabbione> and X build-deps on it
<azeem> well, I believe this circular Build-Dep is not a very good reason to keep X11R6 alive, in case we agree it should in principle die
<fabbione> cool, isn't it?
<Kamion> groff doesn't pull stuff in from /usr/X11R6/include/ directly though, it uses the symlink
<elmo_> fabbione: okay, the security stuff is in theory done - if you don't mind, I'd like to wait for mdz to ack it before you start using it
<fabbione> elmo_: sure i don't mind
<kylem> wow. that installation went well. good work guys.
<fabbione> elmo_: i am not sure for how long i can stay around
<fabbione> elmo_: in the worst case we will do tomorrow
<elmo_> fabbione: well, can you put your upload somewhere so matt could upload, it and try the new mechanism out?
<fabbione> elmo_: otherwise i can just handover the packages to pitti since he will take care of security
<fabbione> elmo_: sure
<fabbione> azeem: anyway i have a very limited amount of time
<fabbione> azeem: i need a decision asap
<fabbione> and i think that for the next 6 months we can live with X11R6
<fabbione> we had it around for ages
<fabbione> 6 months more or 6 months less won't kill anybody
<fabbione> and etch will not be released by that
<azeem> fabbione: well, I'd talk to keithp and the rest of the x.org maintainers whether they ponder changing that general X11R6 prefix
<fabbione> azeem: i know daniels did all these changes in his tree
<fabbione> azeem: but the problem is i dunno how robusts they are
<fabbione> and he only built xc/lib/
<fabbione> not xc/*
<azeem> maybe it really is the best to wait for the modular X before killing X11R6
<fabbione> yeah
<fabbione> i agree
<mdz_> elmo_: what kind of ack do you need?
<elmo_> mdz: err, see your mail?  just that your happy with it?  also, per your instructions, you're the only one who can run amber atm
<mdz_> elmo_: no, just got up, haven't read it yet
<elmo_> ok
(daniels/#ubuntu-devel) the problem with Debian is that they're not progressive enough.  if they opened it up to, say, hip-hop artists and dnb producers ...
(Kamion/#ubuntu-devel) hence, also, the sounder@ mailing list
(daniels/#ubuntu-devel) doogie: but humour nevertheless, and it's what we have.
(doogie/#ubuntu-devel) daniels: *the* problem with debian?
<azeem> everything else would be solved instantly if we s/etch/rakim/
<bob2> mix master etch
<lamont> Kamion: apparently d-i doesn't like empty Packages files either...
<Kamion> lamont: empty Packages files where?
<lamont> my mirror
<Kamion> d'oh
<doogie> bob2: don't start
<doogie> maybe there should be theme music with each release?
<lamont> I didn't tell it to mirror anything from multiverse, but did tell it about the component. --> 0 length Packages file.  And a coaster. :-(
<daniels> doogie: we ship an ubuntu-sounds package with default sounds
* lamont lunches
<doogie> daniels: not what I meant.
<bob2> doogie: it would combine the best features of Debian and OpenBSD
<doogie> I mean each release has a custom mix track, or some such
<Kamion> lamont: cdimage doesn't mirror universe or multiverse at all ...
<mdz_> lamont: is 1021-06 the latest live CD candidate?
<amu> mdz_: yes
<T-Bone> hi
<mdz_> downloading it to test
<T-Bone> Kamion: ping?
<Kamion> T-Bone: yep?
<T-Bone> Kamion: do you want to do the "setup" now or tomorrow?
<Kamion> T-Bone: now's fine, just going to grab a bite to eat
<T-Bone>  ok
<T-Bone> i'll wait ;)
<Kamion> but tell me what you need and I'll catch up
<T-Bone> Kamion: actually i need _you_ to tell me what you need ;)
<Kamion> hm, ok
<T-Bone> that includes material and tasks you'd like me to work on ;)
<Kamion> well, the other day I think I said that I'd like to be able to drop in a new netboot kernel and initrd, reboot remotely from that image, and have remote access to its console.
<T-Bone> so you need dhcp server
<Kamion> right
<T-Bone> ok
<T-Bone> i have a server already setup, i'll give you access to it
<T-Bone> so if you just need that and the ia64 box, i need a ssh2 public key, and a login
<Kamion> the other things we need to put together for d-i are: linux-kernel-di-ia64-2.6 package based on the Ubuntu kernel, ports of all the bootloader installer and partitioner component packages from Debian, and probably additions of ia64 to a few lists
<Kamion> login name cjwatson, where can I mail the key?
<T-Bone> varenet@debian.org
<Kamion> it'll be a while before I can actually start using this for testing of course, so the buildd work is higher-priority
<T-Bone> yeah i got that
<T-Bone> unfortunately i need lamont's skills now, cause i hit something strange that _shouldn't_ have happened. We are waiting for him to complete stage1 as well and see if he has the same problem
<hornbeck> hey plovs
<Kamion> mailed
<T-Bone> thx
<Kamion> will need to figure out what needs to change in debian-installer to port the ia64 initrds to Ubuntu
<Kamion> I only did the changes for the arches we support
<T-Bone> k
<Kamion> think it should all be fairly easy, anyway, amd64 wasn't hard
<Kamion> i386 and powerpc were hard because they were the first ones. :)
<T-Bone> hehe
<Kamion> partman-efi, efi-reader, and elilo-installer are clean of possible debconf-priority damage, too; good
<T-Bone> yeap
<Kamion> but elilo-installer will need to be Ubuntu-branded.
<T-Bone> right
<mdz_> justdave: ping?
<Kamion> hm, and partman-efi needs branding too
<Kamion> joy and rapture
<T-Bone> hehe
<hornbeck> plovs: I agree that Mulligan is doing good doc work
<mdz_> lamont, amu: 1021-06 looks good to me
<justdave> mdz_: pong
<plovs> yeah, we might ask hi to join, join the wiki-team page in a how-to use the wiki and wiki notespage
<mdz> justdave: is it possible to change the default on the "find a specific bug" page to search all bugs, open and closed?
<mdz> justdave: and just have it sort open bugs ahead of closed ones?
<hornbeck> plovs: I agree, if we go and split a small team like doc already we are in for trouble
<justdave> changing the default on the open/closed state to all is easy.  changing the default sort can probably be done, but isn't so easy
<sivang> So, a wiki team under doc team? :)
<hornbeck> sivang: I am suggesting we just try to get him to work with us, and that the wiki maintanance should just go along with with docs
<plovs> under sounds bad, let's say the wiki-team will spearhead the doc-team
<hornbeck> I say no wikiteam
<hornbeck> there is a doc team
<hornbeck> we do docs
<hornbeck> wiki is a doc
<sivang> hornbeck : who is he?
<plovs> agreed
<sivang> who are we talking about? :)
<hornbeck> sivang: KevinMulligan
<plovs> http://wiki.ubuntulinux.org/KevinMulligan
<hornbeck> if he is here please speak up
<plovs> there was a thread on the mailinglist also let me find it ... brb
<hornbeck> ok
<plovs> ask in #ubuntu
<hornbeck> I will search real quick
<mdz> justdave: can you change the open/closed default, and look into the sort?
<mdz> justdave: let me know if you'd prefer I filed a bug about this request
<sivang> ok, I read his page
<hornbeck> plovs: his mail must have come when I changed to my new computer
<hornbeck> I have a reply but that is it
* sivang is way lagged after the list. checking now.
<seb128> mdz: have you tested the current liveCD ? The localisation is fine ? I've downloaded it yesterday and the french localisation is broken ...
<plovs> i love gmail, found it in 3 seconds
<mdz> seb128: I did not test French localisation
<mdz> but it works for me in the default english locale
<seb128> could you test ?
<seb128> but I get such messages "locale: Cannot set LC_MESSAGES to default locale: No such file or directory" 
<seb128> and the apps (panel, evo, ...) are not in french
<plovs> DOC it seems it is only one guy, we might just send him a mail
<plovs> or we can write on his page, maybe i'll do that if you guys agree
<hornbeck> plovs: do you want to mail him?
<seb128> and LANG=fr_FR@euro according to "locale"
<hornbeck> plovs: that might be good
<mdz> seb128: /usr/lib/locale is empty
<mdz> seb128: no locales are generated
<plovs> sure i'll mail him and ask to add himself to the doc-team
<hornbeck> plovs: tell him also that we think it might be bad to make multiple teams when it comes to docs
<justdave> ok, turns out the sort order was trivial to fix, after all.
<justdave> all done
<mdz> thanks
<hornbeck> man beagle is rocking
<justdave> it was specified in the form, not in the cgi :)
<mdz> seb128: I get the same errors
<seb128> ok
* justdave tweaks it to sort on resolution instead of status
<mdz> seb128: it gets EACCES opening /usr/lib/locale/locale-archive
<justdave> so all open bugs will still be sorted by relevance
<mdz> seb128: after I've run locale-gen
<justdave> regardless of status
<seb128> hum, weird
<mdz> seb128: it is mode 600
<mdz> seb128: so I changed it to 644
<mdz> seb128: and now evolution is in French
<seb128> ok
<hornbeck> sivang: is the gnome-guide mainly what you are working on?
<mdz> seb128: what procedure did you use to set your locale on the live CD?
<mdz> seb128: dpkg-reconfigure locales?
<seb128> mdz: no, I've just picked Submenu -> Supported languages in the boot screen
<sivang> hornbeck : currently yes, I Have also pending works on the wiki, would appriciate if you could continue with it a bit
<seb128> and then french
<mdz> or is there something at the morphix boot prompt which sets it?
<mdz> ah
<mdz> I'll check if that has the same problem
<hornbeck> sivang: continue with the guide?
<seb128> I'm restarting the liveCD on a box right now
<sivang> hornbeck : yes, if you could I'd appriciate it.
<seb128> mdz: in fact a french user pinged me about this. According to him it was working fine with the version is download some days ago
<hornbeck> sivang: just resend to me and I will see what I can do
<sivang> hornbeck : ok, do you want diffs also, or do you want to wait for 2.8.1 docs altogether maybe?
<hornbeck> sivang: just send me your diffs
<hornbeck> or the whole folder
<hornbeck> does not matter
<sivang> ok
<plovs> hornbeck: sivang what do you guys think about the kind of layout for wiki-pages?
<hornbeck> plovs: are you talking about a standard?
<sivang> the current layout is not good enough?
<hornbeck> plovs,sivang: I think we need to standardize all the pages, to use same formats
<plovs> pages look all a little different and we just began, it is now or never
<sivang> plovs : gemme some examples
<plovs> when we have 2000+ pages it might be a little late
<hornbeck> plovs: they all need to look the same
<plovs> sivang: just a sec
<mdz> seb128: confirmed, I get English if I boot with the French option
<mdz> err
<mdz> never mind
<mdz> seb128: it works
<seb128> oh ?
<mdz> it's just that the computer menu is not localised
<hornbeck> plovs: it will be impossable to make them identical, but we can at least make the standards the same
<mdz> nor is "applications" or "computer"
<mdz> but the menu items under applications are localised
<seb128> mdz: yes, these are .desktop files
<seb128> not po files
<seb128> nothing to do with the locales
<mdz> ah
<mdz> and evolution is not localised
<seb128> yes
<mdz> and it has given me a French keyboard layout it seems :-)
<plovs> sivang: compare http://wiki.ubuntulinux.org/BasicCommands with http://wiki.ubuntulinux.org/BeagleInstallHowto
<mdz> seb128: it is the same bug
<plovs> different styles
<plovs> not big differences but stil...
<hornbeck> plovs: both are my pages :)
<mdz> seb128: /usr/lib/locale/locale-archive is -rw-------
<hornbeck> plovs: I have not changed the basiccommands page yet
<mdz> seb128: please file it in bugzilla
<plovs> hornbeck: :) i know
<plovs> hornbeck: i like the beaglepage
<hornbeck> plovs: I have been working on the beaglepage nonstop because new stuff keeps happening
<seb128> mdz: ok, thanks
<hornbeck> plovs: I need to remake the whole BasicCommands page
<plovs> it rocks, i want to do it all the time, but have no time
<hornbeck> plovs: I know how that is
<plovs> sivang: what if we make the beaglepage layout the basic layout?
<sivang> plovs : I like it better, yes.
<hornbeck> plovs: I think that would work
<plovs> we can make an empty howto page called DocumentationHowto and point to it
<sivang> well, have a look at /HowDoc
<sivang> hornbeck : If I recall right your comments about the laytout, you want everything that needs be typed to be in a "code" box right?
<hornbeck> sivang: yes
<plovs> sivang: it is easier to copy and paste from there
<hornbeck> sivang, plovs: it makes it easier to copy and paste sections
<plovs> and it looks nice :)
<hornbeck> :)
<plovs> sivang: but whatever we do it looks best if it is the same
<sivang> ok, I suggest we streamline it as so. I will modify HowDoc accordingly
<hornbeck> plovs, sivang: is someone going to note all this stuff?
<sivang> hornbeck : I am , see the line before :)
<hornbeck> sivang: I read right as I was hitting enter
<plovs> sivang: nice, will you make DocumentationHowto?
<plovs> or should I do it?
<hornbeck> HowDoc is basicly a DocumentationHowto
<hornbeck> http://wiki.ubuntulinux.org/HowDoc
<hornbeck> maybe needs a name change?
<hornbeck> since we are mainly going with Howto at the end of howto's
<plovs> what we can do is making DocumentationHowto and use [[IncludePage()] ]  to put it inside HowDoc
<hornbeck> plovs: good idea
<hornbeck> plovs: is there a good wiki howto out there/
<hornbeck> ?
<hornbeck> I am learning wiki markup as we go
<plovs> hornbeck: brb
<hornbeck> ok
<plovs> hornbeck: http://wiki.ubuntulinux.org/HelpIndex 
<plovs> hornbeck: especially HelpOnMacros
<plovs> hornbeck: and HelpOnMacros
<hornbeck> plovs: thanks
<plovs> hornbeck: the include is a little broken you can only include whole pages
<plovs> hornbeck: moin 1.3 will/should solve that
<hornbeck> ok
<hornbeck> should we just rename that page?
<hornbeck> than just add new stuff to it
<hornbeck> have a '''wiki howto''' '''docbook howto''' all on the same page?
<hornbeck> a stop shop
<plovs> look at CategoryCategory , you can just make an automatic list
<hornbeck> you lost me
<hornbeck> link
<plovs> if you look at the page-source you'll see it's just two lines
<plovs> so you can make a HowtoPage with an automatic links to all howto's
<plovs> something like that
<hornbeck> ahh
<hornbeck> ok
<hornbeck> but the main question is, should we just be HowDoc into DocumentationHowto
<hornbeck> sivang?
<hornbeck> I think it makes more since
<sivang> yes, I think of HowDoc to be both for offline stuff we do, and wiki content guidline. have 2 sections on that.
<hornbeck> sivang: a rename though?
<sivang> oh, you want it to have HowTo at the end
<sivang> yes
<sivang> :)
<plovs> hornbeck: a howto is usually short and to the point (kernel howto is too long)
<sivang> for the catrgorization to work.
<plovs> hornbeck: a document is long and detailed
<plovs> hornbeck: i *think*
<hornbeck> plovs: DocDoc than?
<hornbeck> :)
<hornbeck> plovs: kernel howto is long no matter what
<plovs> what about ending doc-stuff in Doc or Document?
<plovs> hornbeck: there are three kernel-pages already, that needs cleaning up
<hornbeck> DocumentationDoc?
<hornbeck> plovs: I noticed today
<plovs> WritingGuidelinesDoc ?
<hornbeck> plovs: the one I made was made real nice
<hornbeck> plovs: that works
<hornbeck> shoudl the kernelhowto be made KernelInstallDoc?
<plovs> yes that's better i think
<hornbeck> make it so
<sivang> btw, I think the wiki team falls nicely under the "documentation sounder team" accoridng to the outlined tasks it carries
<plovs> sivang: what do you think Howto pages and Doc pages?
<sivang> plovs : well, actually I think that big docs should be shorty incorporated into PLone CMS, and the wiki should be acting more of a bleeding edge corner and docdevel works
<hornbeck> sivang: we are not at that area yet, but what do you think for right now
<sivang> hornbeck : yes it's good, then we should have 2 indexes for Guides / Howtos. Like on http://www.debian.org/doc/
<hornbeck> sivang: I agree
<plovs> sivang: i agree, but in wiki, they can be worked on.
<plovs> what about something like: http://wiki.ubuntulinux.org/AlexanderPoslavsky_2fPlayGround
<plovs> and then one for the docs
<plovs> feel free to mess up that page
<plovs> hornbeck: how good are you at python?
<hornbeck> plovs: decent
<hornbeck> I do alot of it for my jobs
<hornbeck> plovs: why you ask?
<plovs> hornbeck: i played around with a moin2docbook.py thingie but i'm just starting with python
<hornbeck> plovs: did you write it?
<plovs> hornbeck: i wrote open file, close file check parameters ... so no, not yet
<plovs> hornbeck: i am trying to understand classes
<hornbeck> plovs: if that is something you would like to work on together, send me what you have and we can work on it
<hornbeck> brb have to order books for my classes
<plovs> sivang: yes, like the debian guys
<sivang> plovs : actually the python classes are the nicest and most straightforward I've seen compared to Java, C++ etc
<plovs> sivang: that says something about my programming :(
<sivang> plovs : no, you might no thave any other introduction to OOP langs, so that might explain it :)
<plovs> sivang: it is the first time, and i need more time to read it
<plovs> sivang: how difficult is it to make yelp docs?
<sivang> sivang : but you'll catch on fast, if you programmed before - take "Dive into python" by Mark Pilgream , very good 
<sivang> plovs : actually, you just learn the DTD and that's it. You're writing XML
<plovs> sivang: i have it installed :)
<hornbeck> ok, I am back
<plovs> sivang: if we could write this converter then we could just convert wiki pages (they are really basic) to XML
<sivang> plovs : you can do some work on the manual, it teaches you about the dtd as you see al those tags for representing menu choises, items.
<plovs> sivang: *the* manual?
<sivang> plovs : Yes, I have talked with Enrico about that - We might have the Plone CMS team to do this for us maybe
<sivang> :)
<plovs> sivang: duh, what manual?
<hornbeck> plovs: we can work on it, if someone else does it, it will at least give you some experiance with python
<sivang> plovs : yes, the gnome official needs some adjustments and modification to nicely follow Ubuntu's desktop looks and actions.
<hornbeck> plovs: also Docbook is easy
<hornbeck> just follow what is already there, for most manuals
<plovs> sivang: i am trying to concentrate on two things, my wife is explaining diets and recipes to me from the second computer
<hornbeck> plovs: I understand that :)
<plovs> hornbeck: how would you go about converting a file from moin to docbook? i have a look for line in file with lot of re.match
<hornbeck> I have wife and two kids, who talk to me while I do all this
<hornbeck> plovs: I would have to start hacking on it honestly, I am not a good enough programmer to explain it off the top of my head
<hornbeck> I am more of a hit or miss guy, learn as I go
<plovs> hornbeck: well, i'll write some more and thn send it, it would be nice to get a converter
<hornbeck> plovs: cool
<hornbeck> plovs: if you want to learn docbook work on the gnome-guide with sivang
<hornbeck> its a good starting place
<plovs> sivang: can yelp use non-local =internet files?
<hornbeck> yelp just reads DTD as far as I know
<sivang> plovs : lemme ask it's developer for a sec :)
<plovs> sivang: do you hve some simple task?
<sivang> plovs : no it can't, and won't.
<plovs> sivang: less is more, i should have guessed, this is not kde
<hornbeck> sivang: are you in #docs?
<sivang> hornbeck : yes
<plovs> sivang: i could take HowDoc from common approach, and put it in DocHowto, and the 
<plovs> n link it back
<sivang> plovs : ok
<plovs> hornbeck: sivang what page do we use for suggestions to the documentation team?
<hornbeck> hmm
<hornbeck> DocSuggestions
<hornbeck> hows that sound?
<mdz> does anyone here have a copy of vmware?
<hornbeck> plovs: sivang: are we renameing HowDoc and the KernelHowto?
<hornbeck> I have 4.5 for linux somewhere mdz
<mdz> hornbeck: if it is the eval version, is it possible for me to get a copy?
<mdz> I'm trying to track down this bug: https://bugzilla.ubuntu.com/show_bug.cgi?id=2492
<hornbeck> mdz: you can download the eval version
<mdz> not without registering on their website, getting an evaluation key, etc.
<mdz> I just want to look at some of the files
<mdz> and see if it is doing what I suspect it may be
<hornbeck> I don't have a eval version
<hornbeck> I can get the eval version for you if you want
<mdz> can you look and see if it changes the samba startup links?
<hornbeck> I will have to install, I have it on disk right now
<hornbeck> I got it along time ago, when I still used windows some
<sivang> hornbeck : what's the software ?
<hornbeck> vmware
<sivang> mdz : I am running samba on this machine, should I try and upgrade and test it?
<hornbeck> mdz: I can send to you with reg code if you would like
<hornbeck> I just started download and got registered
<pitti> elmo_, mdz: can I put the security packages somewhere, so that either of you can upload them? I'm going to bed soon
<sivang> I have upgraded samba while it was still running, wasn't able to reproduce.
<hornbeck> mdz: I now have the eval copy with reg code. Do you want me to send to you?
<hornbeck> I am not running samba so I would not be able to test
<hornbeck> plovs: you still around?
<hornbeck> sivang?
<sivang> hornbeck : yes
<hornbeck> ok, no one was answering so I was wondering if I was still connected
<hornbeck> :)
<hornbeck> well I am off to work
<hornbeck> night
<sivang> night hornbeck
<mxpxpod> chrisa: ping
<ploum> I just want to thanks all developpers and Mark for the wonderful Warty release. Good job guys, it's really great !
<plovs> hornbeck: sorry, yes
<hornbeck> plovs: I wanted to say keep up the good work :)
<plovs> hornbeck: goodnight :) !
<hornbeck> night
<plovs> sivang: good night!
<sivang> plovs : night
<mdz> ploum: thanks :-)
<hornbeck> mdz: you want the vmware?
<mdz> hornbeck: sure, thanks
<mdz> sivang: if you have vmware installed, yes, that would be a good test
<sivang> mdz : installing in the background
<mdz> hornbeck: dcc won't work; I'm behind a firewall here
<hornbeck> how can I get it to you?
<mdz> hornbeck: I just finished drafting a short howto on how to use the community support resources, in the wiki
<mdz> HowToGetHelp
<mdz> hornbeck: I'd be interested in your feedback
<hornbeck> ok
<sivang> mdz : I'll give it a look also :)
<hornbeck> mdz: you get my pm?
<hornbeck> mdz: nice use of eric raymond site
<hornbeck> mdz: adding a link to the doc howto at the bottom would help when saying "or how about a howto article" and have the link to the dochowto
<mdz> hornbeck: by all means
<hornbeck> mdz: added
<mdz> thanks
<hornbeck> well all, I really have to go now
<hornbeck> goodnight
<mdz> I've tried the vmware eval download about 20 times and it's no good
<mdz> I'll keep fiddling :-)
<mdz> night
<hornbeck> hmmm
<hornbeck> keep working at it :)
<theantix> any idea why there is no php4-common in Ubuntu like there is in Debian Sid?  some universe packages depend on it... any developer I can talk to about the reasons for that or any workaround?
<mako> hornbeck|away: great stuff
<sivang> mdz : you tried the tarball?
<mdz> sivang: no, I'm trying to download it
<mdz> I was hoping to find someone who already had a copy and could poke around and see if it does anything nasty to /etc/rc?.d
<sivang> mdz : I suppose it does. It always added stuff to bootup scripts when I Used it on sarge,sid and RH
<mdz> sivang: ls -l /etc/rc?.d/K09samba
<mdz> if that file exists, that's a good clue
<sivang> mdz : after I install it :) I will
<mdz> ah
<lamont_r> seb128 around?
<sivang> mdz : "read the FAQ"  is broken on Plone, I opened a bug on it on bugzilla but till isn't corrected
<sivang> mdz : the link you pointed from the wikie
<seb128> lamont_r: yes
<lamont_r> how does /usr/lib/locale/fr get populated?
<mdz> sivang: fixed the link, thanks
<lamont_r> and btw, the french keyboard is just plain screwed up.
<sivang> mdz : no prob. this is also referenced from _within_  the plone somewhere.
<lamont_r> I mean layout-wise, that is
<seb128> lamont_r: /usr/lib/locale/locale-archive you mean ?
<lamont_r> the errors from strace indicate that it's tryting to open /usr/lib/locale/fr/LC_*
<seb128> lamont_r: have you read your mails (#2292) ?
<seb128> oups
<seb128> 2614 I mean
<lamont_r> not yet
<seb128> the problem is /usr/lib/locale/locale-archive being 600
<seb128> (thanks mdz for finding this)
<seb128> chmod 644 it and that works fine
<lamont_r> on the liveCD?
<seb128> yes
* lamont_r adds a 'umask 0' to the build process, and pushes things to the top of the hill
* mdz gapes
<mdz> lamont_r: that file is created dynamically during boot
<mdz> must be
<lamont_r> ah, ok.
<mdz> not that umask 0 would be a good idea _anyway_...:-)
<lamont_r> means I'll have to go find that.
<seb128> it is, depending of the locale selected in the menu
<lamont_r> just knew that i have 022 , which still wouldn't explain it...
<amu> lamont_r: problem ( warning )  with booting, umount: /.dev not found ; rmdir: invalid option --f; can't create /var/lib/dhcp3/dhclient.leases: Read-only file system; alsactl: load_state:1134: No soundcards found ...  
<lamont_r> is anything getting 077 as a umask?
<lamont_r> amu: we're ignoring the leases file issue
<lamont_r> but rmdir -f could use some staring at
<mdz> that file wouldn't be there after a reboot anyway :-)
<amu> lamont_r: i took screenshots
<lamont_r> right - that's because we switched from pump to dhclient3...
<lamont_r> amu: cool
* lamont_r is sitting at the mechanics and using dialup.
<mdz> something must be calling localedef or locale-gen somewhere in the boot process
<lamont_r> hence testing is gonna be a bitch
<mdz> based on the lang= boot parameter
<lamont_r> mdz: yes.
<amu> grubsplash you should wait min. 60sec. instead of 5  
<lamont_r> right before it starts pcmcia
<lamont_r> amu: hell no
<lamont_r> use case is enduser, not technical people.
<lamont_r> end user doesn't want the 1 min wasted time
<amu> lamont_r: process bar is ok now ;) 
<lamont_r> this was discussed wrt the installed box quite a whileback
<lamont_r> amu: jdub fixed that last night
<lamont_r> mdz: do we care that gnome takes forever to come up under some situation involving  no link?
<lamont_r> link beat, that is.
<amu> lamont_r: ok, we should note that in a part of the faq bootoptions *ducks* 
<mdz> lamont_r: depends on how long forever is
<lamont_r> < 5 minutes
<lamont_r> just long enough to go WTF and reboot.
<amu> uploading screenshot 
<mdz> lamont_r: do you realize that sources.list on the CD contains people.ubuntu.com/~lamont entries?
* lamont_r notices that elmo used a large club in locking down warty
<lamont_r> mdz: yes
<lamont_r> but that's ok, because apt-get update exits immediateluy
<lamont_r> :-)
<lamont_r> http method is busted, alex blames part of the kernel hacks
<mdz> SIGSEGV
<lamont_r> yeah - in select on a socket
<lamont_r> "I was suspicious of that socket code"
<lamont_r> --Alex
<mdz> what socket code?
* lamont_r looks
* lamont_r forgpt the package name
<lamont_r> mdz: minifo
<lamont_r> or rather, probably minifo-2.6.7
<mdz> isn't that the filesystem overlay thing?
<mdz> I do not see what that has to do with TCP sockets, which are what that program is using
<lamont_r> sockets are fd's, which go through the filesystem...
<amu> http://amu.debian.net/tmp/l5.png
<lamont_r> and alex really thought the socket handling was, um, suspect
<lamont_r> mdz: think unix domain sockets
<mdz> I agree, it probably is
<mdz> but apt doesn't use unix domain sockets
<lamont_r> but the sockets code gets involved anyway
<mdz> you're saying that mini_fo mangles generic socket code?
* mdz runs away
<mdz> no wonder that thing will never go near upstream
<mdz> where can I get a copy of that patch?
<lamont_r> mdz: nfc - I didn't even look at it, other than 'http method dies with segv, and strace, pick on alex'.  see p.u.c/~lamont/LiveCD/morphix/source
* amu detects a bugs bombarding 
<mdz> I didn't realize you had noticed that major things were broken and weren't filing bugs about them
<lamont_r> 1) didn't see apt not working as major - it's a livecd.  2) the last bug I asked someone to file I got told "please dont"
<lamont_r> the localization bug was mentioned last night - investingating today.
<mdz> lamont_r: that was regarding "the live CD has fundamentally different hardware detection" which is a design issue
<lamont_r> true
<lamont_r> but still a WONTFIX bug.
<lamont_r> or at least NOTWARTY
<lamont_r> because we've already declared it to be RC for hoary
<mdz> doesn't apt work on morphix?
<lamont_r> not recent disks, apparently
<mdz> if it doesn't, I really don't see the point of tolerating all this mini_fo madness
<mdz> that seems like the only reason
* lamont_r adds a chmod to the morphix startup scripts
<lamont_r> mdz: looks like minifo might be trivial to fix - want me to see what I can do?
<mdz> lamont_r: what's the story?
<lamont_r> well, if it's just a null pointer deref issue (like the oops says), it could just be a matter of a check, dunno until I look
<lamont_r> fear any code that contains the comment: XXX ... this is wrong?
<T-Bone> lol
<T-Bone> lamont_r: dude, I write that kind of code!
* T-Bone ducks
<mdz> lamont_r: before the oops, there is an assertion failure down in the mini_fo code
<mdz> so I don't know what the root cause is
<mdz> it shouldn't be passing a NULL up the stack
<lamont_r> mdz: I'll dig into it some
<lamont_r> car done at the mechanics, heading back home in a few
<mdz> lamont_r: ok, the localisation stuff is higher-priority though
<mdz> I imagine it's more fixable, too
<lamont_r> trivially.
<lamont_r> and I'll fix the rmdir -f issue, since it's in the same package, and equally trivial
<lamont_r> (I fixed the locale issue by adding a chmod 644 after the locale-gen call
<lamont_r> in theory, wifi drivers are in anything newer than the RC bits, but I have no hardware to verify
* lamont_r finishes up with the mechanic and heads homeward.
<lamont_r> mdz: anything else before I flee?
<mdz> lamont_r: new build with locales fixed later this afternoon?
<mdz> if so, nothing else at the moment
#ubuntu-devel 2004-11-02
<lamont_r> mdz: will build as soon as I get home, test, and then push the fix and build in the DC.  eta ~ 2 hours
* lamont_r heads out
<sivang> vmware's perl installer sucks badly
<mdz> sivang: yes, but does it break samba? :-)
<sivang> mdz : It needs kernel headers before, it wants to compile the kernel module 
<sivang> mdz : this will take me some time, but I will not go to sleep before being able to tell you if it does.
<sivang> mdz : it first broke up on me and I had to clean files by hand..:-|
<sivang> mdz : compiling now
<sivang> mdz : almost finished install
<sivang> mdz : what file am I supposed to look for?
<sivang> /etc/rc6.d/K19samba
<sivang> /etc/rc1.d/K19samba
<sivang> /etc/rc0.d/K19samba
<mdz> sivang: that looks normal
<mdz> i.e., not mangled
<sivang> mdz : I can remove my samba and reinstall it just to see if it makes through it, what do you say?
<sivang> (without purgin conf files ofcourse :)
<mdz> sivang: apparently, vmware has some integration with samba
<mdz> sivang: are you sure that you enabled this and it was activated?
<sivang> it uses samba to give access to the host's filesystem
<sivang> mdz : everything that just had samba in the name, I said yes.
<sivang> mdz : especially bridge networking thingies, and configure access to the host file system through samba
<mdz> it could be a different version of vmware which has the bug...it's just a guess, really
<mdz> I don't think it's a package in Ubuntu which causes this
<sivang> mdz : I can runleve 1 and back see if anything breaks
<mdz> sivang: the bug is that something deletes the /etc/rc?.d/K19samba links
<mdz> and creates broken /etc/rc?.d/K09samba links
<antonio_> hi!
<lamont> moo
<antonio_> i've just installed ubuntu...
<antonio_> ... it's cool!
<antonio_> anyone knows how to install mono on it?
<lamont> antonio_: I think it's just a matter of adding universe (see /etc/apt/sources.list), and running synaptic
<antonio_> ok, thanx!
<antonio_> i'm so interested in configure grub ui, anyone knows where to touch in?
<sivang> mdz : you have a sn for vmware?
<antonio_> me?
<antonio_> i don't have it
<azeem> antonio_: gnome-systems-tools can configure grub AFAIK, though I believe that part of it is not shipped by ubuntu
<sivang> no I was asking mdz, as we are trying to reproduce a bug related to vmware and ubuntu
<antonio_> oks
<sivang> antonio_ : you might want to ask on #ubuntu, this is rather a development general discussion channel
<antonio_> ok, thanx!
<mdz> sivang: no, I do not
<sivang> mdz : ok, I'll register there
<amu> lamont: ping
<lamont> ack
<amu> guess i got it, i think pentium 233mmx is a 386, livecd kernel has only support for >486   
<lamont> huh?  I thought mmx > 486, no?
<elmo_> anything with pentium in the CPU name is >= 586
<amu> compared both, installkernel is 386 with emu, live is 486 no C[C[C[C[C[C[C[C[Cemu 
<pitti> mdz: so shall I do the security uploads tomorrow?
<mdz> elmo_: what's the status of the security queue?
<mdz> pitti: they should be peer reviewed first
<pitti> mdz: I took the patches from Debian, but I will just upload the packages to chinstrap
<pitti> mdz: http://chinstrap/~pitti/
<pitti> mdz: sorry, https of course
<pitti> night everybody
<sivang> night pitti 
* kylem wonders if lamont fixed mplayer
<mdz> amu: the live CD kernel is 2.6.7 + morphix stuff, the instal kernel is 2.6.8.1 + ubuntu stuff.  they are entirely different kernels
<Kamion> mdz: what, we haven't updated the live kernel? boggle
<mdz> Kamion: it uses this very sketchy kernel module which was suspected to break under 2.6.8.1
<Kamion> oh, that overlay thing
<amu> mdz: is it possible to find it out with which command the kernel was build, make-kpkg ....  
<lamont> kylem: after livecd ships
<kylem> lamont, lol, ok. :)
<mdz> I just had vim segfault on me on the live CD
<mdz> in mini_fo_rename
<amu> -rw-r--r--  1 root root 12672488 Oct  3 13:32 kernel-image-2.6.7_10.00.Custom_i386.deb is builded with scsci_multi_lun=y
<amu> #1995
<mdz> thanks
<chrisa> /sbin/init: 429: cannot open dev/console: No such file
<chrisa> fun
<amu> mdz: what was the problem with #1995 ?     
<mdz> amu: perhaps alex fixed it and forgot to close the bug?
<mdz> amu: I opened it almost 3 weeks ago
<chrisa> ah, bug in the image
<amu> ok, should i diff it with the ubuntu kernel ? or closing the bug ?       
<amu> mdz: guess the problem was with nvidia-modules, why not running the same kernel ? right ? 
<mdz> amu: diff it
<mdz> see if there are any other significant differences
<mdz> amu: as I said to Kamion above, the reason it isn't the same kernel is because of this mini_fo nastiness
<lamont> where is the '-' on a french keyboard?
<mdz> lamont: it's under computer->desktop preferences->(thing that looks like a keyboard)
<mdz> clavier or something
<amu> ^k, diff comes tomorrow   
<lamont> was actually trying to type in a tty,
* lamont screams, finding empirical evidence (maybe) of why boot takes forever sometimes...  have to double check
<doogie> lamont: it takes forever sometimes because someone told grub to boot windows?
<lamont> mdz: wrt the sources.list - do we want to move the mirrors off of p.u.o?
<mdz> lamont: I was thinking more that those entries could be removed from the installed system. what's there?
<lamont> which entries?
<sivang> just tried to boot cd, loops back at the grub menu.
<sivang> (livecd)
<lamont> two sound devices (??) --> two esd's (definite) --> hang for a while.
<lamont> sivang: which CD?
<lamont> version
<sivang> warty-live-i386-20041021-06
<sivang> could I have again a bad burn?
<lamont> could be
<lamont> I believe that others have booted it successfully
<sivang> I guess nobody reported that ha?
<sivang> ok
<sivang> I'll give it another burn
<lamont> killing the ESD that's hanging out there during the "hang" (really a stall) gets us past that...
<lamont> mdz: so why doesn't locale-gen fix the perms itself?
<chrisa> Does linux-source-2.6.8.1 contain the .config used to generate the kernel images?
<lupus_> when will hoary repository open up?
<mdz> lamont: dunno. why does it end up with wrong permissions in morphix?
<lamont> still arguing with that, I fear
<amu> chrisa: nope, you get it from the image 
<mdz> lamont: re: which entries, the sources.list entries
<lamont> yes
<mdz> lamont: I'm afraid uploading glibc is out of the question at this stage, so the permission thing will need to be fixed in the morphix side of things
<lamont> the ones that all point to p.u.o/~lamont/LiveCD
<lamont> could probably move to something more official-esque, eh?
<lamont> mdz: that was a granted assumption.  Just grousing
<mdz> lamont: what packages are they expected to retrieve from ~lamont/LiveCD?
<lamont> none, unless you're building a liveCD
<mdz> I assume that only contains the morphix-specific packages, which aren't even installed in the mainmodule, are they?
<mdz> so they don't need to be present in the file on the live CD
<lamont> there are also 2? packagees from universe that are on the livecd, and present in LiveCD/warthog on the mirror
<lamont> but I got rid of pump...
<mdz> lamont: what's the other one?
* amu moves to bed; n8 -R *
<lamont> dialog :-(
<lamont> libpci1 is there for aumix
<lamont> (pump was #3.)
<mdz> fabbione: your gpg emails are full of CR/LFs still
<mdz> lamont: aumix is in universe too
<mdz> shouldn't need it, either. we have alsamixer
* lamont will build without it this pass
<elmo_> mm, neat, xmms still has that "playing at 1.5x speed" bug  on my laptop.  I rock at reporting bugs on time.
<lamont> dialog is also universe
<lamont> mdz: aumix is in base, not mainmod.
<lamont> which means it's there for hw detection crap, probably
<mdz> that also means it's fine if it's missing from /etc/apt/sources.list in mainmod
<lamont> yes.
<lamont> now I just have to figure out how to deal with that.
<mdz> lamont: if it's non-trivial, I don't care if it stays there
<mdz> there are certainly worse bugs at this point
<lamont> mdz: it's a mod to morphix-mmaker
<lamont> ==> no
<lamont> seb128 around?
<lamont> or jdub?
<lamont> or anyone who knows how esd gets launched?
* lamont glares at the '&' character, pushes the localization bug to the top of the hill again
<elmo_> yeah
<elmo_> meh.  window focus is for lamers.
<lamont> follow the bouncing focus.
<lamont> in other unrelated news, my install DVD boots now.
* lamont consdiers a bug against d-i asking it to take Packages.gz when Packages doesn't exist.
<lamont> and, if the Packages file isn't mentioned in Release, to just bitch loudly and ask before using, rather than loop forever.
<sivang> mdz : it works no problem so far, however I didn't try to remove and reinstall samba
<sivang> night all
<tseng> will there be security advisories on the main page?
<mdz> justdave: around?
<mdz> tseng: there's an 'errata' section under documentation; I imagine we'll put them there
<tseng> sure
* lamont burns another live cd, colorado edition
<lamont> no esd takers, eh?
<mdz> lamont: hmm?
<lamont> under conditions unknown, I find that the liveCD stalls with the X background, and a cursor.
<lamont> killing the running ESD at that point causes the system to finish coming up into gnome.
<lamont> (with esd running)
<lamont> there are errors/warnings in the main (f1) screen about another esd process already running
<tseng> i realize that bluefoxicy is a complete tool, but are any of you folks interested in hardening daemons
<tseng> ssp/pie
<tseng> http://www.trl.ibm.com/projects/security/ssp/
<mdz> lamont: I have seen no such behaviour
<lamont> maybe it's a vaio special, or something unique to the colorado edition
<lamont> brb
<mdz> tseng: there is some proactive security stuff on the list of proposed hoary feature goals
<tseng> mdz: yeah, bluefoxicy put it together
<tseng> if you mean the wiki page
<tseng> he is one of our user/trolls at hardened gentoo
<mdz> tseng: I mean the HoaryHedgehog page
* tseng sees SELinux on the list
<mdz> yes
<justdave> mdz: pong
<mdz> justdave: filed a bug (the live CD thing)
<justdave> ok, just saw that and replied
<daniels> mdz: #277699
<daniels> mdz: we don't care about PAE, yeah?
<jdub> ahr
<jdub> morning
<jdub> lamont: topic has the latest build?
<lamont> latest dc build, yes.
<lamont> I'm fixing localization right now, burning what I think is the last CD for that.
<lamont> then I need artwork from you, dude.  Or we're gonna ship
<lamont> :0)
<lamont> mdz: anything besides localization that we want to get in before we ship?
<daniels> jdub: morning
<lamont> will work on understanding minifo as well tonight, but I think that's opportunistic dependiing on how bad it is
<benh> bob2: like this ? :)
<bob2> hehehe
<jdub> lamont: you want a final grub-gfxboot image?
<benh> so as I was saying on the other channel, it would be useful for you guys to send your old crappy outdated overpatches glibc down the gutter
<benh> and get something decent :)
<benh> ppc had NPTL/TLS support for a looong time now, but the debian glibc is just too old
<jdub> hey benh 
<jdub> benh: i put your glibc request on the HoaryHedgehog feature goals list :-)
<lamont> jdub: if I don't get one, then the one I have is final... :-)
<benh> good :)
<jdub> lamont: it's fine, but it doesn't have anything up the top left
* jdub is not too concerned
<lamont> right.  this is your chance, taken or not.
<lamont> just wanted to give our RELEASE MANAGER a chance to slip in one more change before release, and all that... 
<jdub> how many minutes? :)
<jdub> haha
<tseng> thom: ping
<lamont> oh, I'd like to burn the final sometime within the next 3 hours or so.
<lamont> which means you have < 2 hours.
<jdub> tops
<benh> the main reason debian glibc is outdated is to support exotic archs
<tseng> thom: your NetworkManager initscript checks for /usr/bin/NetworkManager || exit 0
<tseng> thom: NetworkManager is in sbin
<benh> amd64, x86 and ppc all benefit from a more recent drop, and especially ppc & ppc64
<benh> the main problem with glibc however is that there are no more releases afaik
<daniels> yeah, I was going to say
<benh> just a cvs and the "bugs of the day"
<daniels> we don't have mipsel to support
<benh> so you sort-of need to track your own tree, bringing in things from the cvs with caution
<jdub> boo hoo
<jdub> i want ubuntu on my qube
<jdub> it is my firewall ;)
<bob2> hehehe
<bob2> HoaryGoals - Support jdub's firewall.
<jdub> :-)
<jdub> and the linksys is mipsel
<jdub> though you probably wouldn't use glibc on it
<lamont> if we're supporting jdub's firewall, I want mine supported too!
<bob2> haha
<lamont> (hppa)
<daniels> WRTbuntu
<kylem> i heard someone speaking about an embedded ubuntu.
<bob2> and my alpha.
<lamont> jdub: what starts esd?
<daniels> ebuntu
<daniels> i love it
<jdub> lamont: gnome-session, i believe
<kylem> support my itanic. ;-)
<jdub> kylem: mdz has done something, dunno what though
<jdub> kylem: there are plans for something reasonably official, too, though
<jdub> lamont: my hppa is horribly hot and loud
<lamont> kylem: ia64 support is actually in the works
<kylem> lamont, i heard tbone speaking of it.
<lamont> jdub: mine's in the utility room
<jdub> haha, from mbp:
<jdub> "xdiskusage is a great little tool to show what is using up space on a disk.
<jdub> There is also Filelight which has a bit more eye-candy, but depends on KDE and so may be a bit counter-productive in freeing up disk space."
<lamont> jdub: so here's the thing with my vaio...
<lamont> esd sometimes gets launched twice (based on the complaints that it'salready running)... and gnome-splash gets delayed until either something like 3-5 minutes go by, or you jump into a vt and kill the esd that's in ps output...
<lamont> what needs to get h0rked?
<lamont> only one esd in the ps output: /usr/bin/esd -terminate -nobeeps -as 2 -spawnfd 17
<lamont> l10n happiness!
<jdub> lamont: what's in ~/.gnome2/session ?
<lamont> jdub: well, the whole directory gets nuked each boot, so I'd say the default...
<lamont> liveCD
<jdub> oh
<jdub> um
<lamont> there is an ac97 modem there as well as the sound device
<jdub> it's not a crazy morphix initscript, is it?
<lamont> don't think so...
<lamont> didn't see 'esd' anywhere in the scripts when I looked... what else should I grep for?
<jdub> so this is a general livecd problem, or just your vaio?
<lamont> mdz hasn't seen it, he has 2 sound devices.
<jdub> nothing, i don't htink
<lamont> it may even be specific to the colorado edition
* lamont waits for his japanese boot to finish, then he'll reboot to check some things
<lamont> jdub: funny thing is, it doesn't do it every time.  only some times.
<lamont> yep. that's japanese, alright.
<lamont> "Computer" didn't get translated, though.
<lamont> nor did a bunch of other stuff. feh
<jdub> we don't have an ubuntu alternate dimension yet
<jdub> so no japanese translations
<tseng> is there anything in debian initscripts to tell one service to start before another?
<jdub> no
<tseng> or just by the #'s in rc.d
<jdub> Sxx <-
<jdub> :)
<tseng> :) fair nuff
<jdub> don't go all gentoo on us ;)
<tseng> networkmanager wants to start before dbus
<lamont> jdub: _I_ can translate to japanese, so can jane.
<tseng> jdub, i was a gentoo devel for ~1 year
<jdub> lamont: we need to foster an alternate dimension though
<jdub> tseng: (i know)
<tseng> :P
<lamont> yeah
<lamont> gimp in japanese is interesting..
<bob2> tseng: we forgive you :-p
<tseng> heh.
<tseng> i found my way back to debian, thanks to the Mad Phat startup
<jdub> haha
<bob2> you should star in a community service announcement
<tseng> i converted a few people
<bob2> "I was once a Debian user, then I fell into the wrong crowd...started using gentoo, compiling things from source, using -O99 and -fomit-instructions...then I found Ubuntu.  They helped me go back to actually using my machine, not just building stuff over and over.  Thanks, Mad Phat Startup!"
<tseng> haha, yeah
<tseng> the gentoo user base is pretty heinous, that extends to some of the development community as well these days
<tseng> brb, added NetworkManager at S25
<jdub> bob2: "this has been a community service announcement (*cough* sponsored by canonical)"
* lamont isn't familiar with -fomit-instructions
<bob2> bwahaha
<tseng> the straw that broke my back was
<tseng> someone thought it was a good idea to add gcc 3.4 to the "unstable" distro
<daniels> to be fair, when we put in gcc 3.2, it broke Xau at -O2
<daniels> so you couldn't actually start any X apps, unless you started with access control disabled
<daniels> this was on i386 and powerpc, where the build actually succeeded
<daniels> it failed on arm, mips, mipsel and m68k with an ICE, but that's not even the thrust of my argument here :P
<bob2> oh yeah, fun times
<jdub> wow, lots of comments on the LWN article
* lamont makes a new DC cd
<kylem> one thing that would be a nice 'enterprise' feature from ubuntu, is the ability to configure nis/ldap during firstboot...
<bob2> "From what I hear Europe is about 5 to 7 years ahead of us in depravity"
<lamont> jdub: and they're largely scary replies...
<bob2> tjc is massively anti-ubuntu, whoever that is
<lamont> kylem: there's plenty of room on the install CD to add a package or 3 to do just that...
<lamont> and point at the corporate mirror, and configure the corporate DNS/MTA/... config, etc.
* kylem nods.
<jdub> yeah, though we probably wouldn't ask the questions by default
<lamont> but then, that's customizing the CD, which is work for many
<jdub> you'd have to use kickstart or pre-seeding
<jdub> which would be reasonably appropriate anyway
<lamont> jdub: instead of expert, just boot 'corporate'
<jdub> we probably shouldn't have too many of those :)
<kylem> kickstart would be cool, heh.
<bob2> jdub: "the best thing verisign ever did..."
<jdub> bob2: loved that one :)
<Keybuk> Does anyone else find it amusing we're DistroWatch #3 now ?
<Keybuk> (though I expect that's an artificial release-induced high, but still... <g>)
<jdub> for this month?
<Keybuk> yeah
<jdub> wow
<jdub> 12th on 3 months
<jamesh> It's probably because all the developers keep checking the distrowatch page to find the rank
<jamesh> (given the ranking is just based on page hits)
* jdub just looks at the ranking list, not the ubuntu page :)
<Keybuk> jamesh: the rank isn't given on the distrowatch page that gets counted
<lamont> Mandrake clearly has bots at work.. :-)
<jdub> X many million french people can't be wrong!
<lamont> http://people.ubuntulinux.org/~lamont/testing/LiveCD/20041022-04/warty-live--i386-20041022-04.iso
<daniels> 404
<lamont> doh.
<daniels> ah
<lamont> http://people.ubuntulinux.org/~lamont/testing/LiveCD/20041022-04/warty-live-i386-20041022-04.iso
<daniels> http://people.ubuntulinux.org/~lamont/testing/LiveCD/20041022-04/warty-live-i386-20041022-04.iso
<lamont> bad paste
<daniels> yeah
<daniels> GET OUT OF ARCH
<daniels> IT'S NOT TOO LATE
<lamont> daniels: I pasted that last little bit, picked up a spare -
<fabbione> morning
<daniels> fabbione: morning dude
<daniels> fabbione: see /msg
<fabbione> ah paste again
<fabbione> daniels: it's out of my buffer
<fabbione> mdz: i am using thunderbird
<fabbione> almost default settings
<fabbione> let me check them again
<fabbione> daniels: ^
<daniels> you want a repaste?
<fabbione> no
<daniels> ok ...
<fabbione> phoenix is far
<lamont> phoenix in the summer is nice.
<daniels> Mandrake: because 174 million French people can't be wrong!
<daniels> fabb	ok
<lamont> s/summer/winter/
<fabbione> daniels: go for the palace. it's very close to the main train station
<daniels> ok
<daniels> hold one, which one's the palace?
<fabbione> Palace Hotel
<fabbione> Palace Hotel
<fabbione> Historic hotel in Copenhagens city square
<fabbione> Guests can book a range of treatments with the hotels masseuse, including deep tissue massage, cranio sacral massage, and healing; in-room treatments are ...
<fabbione> More hotel info
<bob2> wow
<bob2> can I come to the X sprint, too?
<fabbione> bob2: did you import X.org and xfrer86 into arch?
<daniels> palace is unavailable for part of it, plus $$ for some days
<daniels> like GBP167/night for the weekends :P
* lamont finds himself tempted to add a morphix-lamont package to the colorado edition of the livecd, with a gnome config that he can stand, etc, etc.
<bob2> fabbione: how many days until the sprint? ;)
<fabbione> daniels: the marmaid hotel is also ok in terms of distance
<daniels> bob2: starts on the 1st.  get moving.
<fabbione> bob2: one week
* bob2 hurrys
<fabbione> daniels: 2604 is your
<bob2> copenhagen sounds like fun!
<daniels> fabbione: reassign it to me
<fabbione> daniels: we will look at bugs later on
<fabbione> useless to do it now
<daniels> ok
<daniels> fabbione: i'd say xserver-xfree86 tho ... just sanitise it right before you actually write it
<fabbione> daniels: well that info comes from xresprobe
<fabbione> i don't write anywhere the size of the monitor
<fabbione> but yeah
<fabbione> it's on the border
<daniels> ok, i'll put it on my xresprobe todo
<daniels> we can be doubly careful -- put it in two places :)
<fabbione> heheh
<jdub> hrm
<jdub> i have a difficult choice to make
<jdub> do i use hoary on my laptop, even though i really need it to be a stable machine, and will probably be using it for demonstrations
<daniels> jdub: seafood platter
<lamont> jdub: dual boot?
<daniels> oh, you're not deciding what to have for lunch.
<jdub> or do i use warty on my laptop, and test hoary on my desktop (which i rarely turn on these days)
<bob2> no, steak sandwich with the lot, hold the pineapple
<daniels> bob2: i find the seafood basket hard to fault
<lamont> jdub: you know that within 2 months you're gonna want to demo bleeding-edge hoary
<bob2> daniels: seafood sticks--
<daniels> jdub: i agree, dual-boot also
<daniels> jdub: MAD PHAT STARTUP
<jdub> i don't go for dual-boot
<jdub> i like those lines defined very strongly
<lamont> jdub: just keep the warty LiveCD around for demos, and run hoary????
<bob2> hoary, because you know lamont is right
<lamont> jdub: "warty is, like, _so_ 2004."
<jdub> lamont: hrrrrrm, that's amazingly tempting
<daniels> bob2: sounds like a commercial
<daniels> we need lamont fronting up to the cameras like 'hoary is the only tree i trust for *my* family.'
<bob2> espcially if we ever get X.ORG PACKAGES.
<bob2> hahaha
* lamont wonders if grumpy is a prognostication of mdz's mood by then?
<jdub> means i'll be dogfooding the development release all the time, which is half what i really want but a little bit what i don't want
<lamont> jdub: you can mount /home from the hard drive, you know...
<bob2> ho, hoary opened
<lamont> bob2???
<lamont> you mean the apt repositories?
<bob2> oh, no, it's just empty Packages files
<lamont> yeah - about 2 months ago, or so.
<lamont> elmo had some time one day, you see...
<lamont> I think it was oxford-conf timeframe
<bob2> ah
<lamont> there are hoary chroots on the buildd's that say 'aug 11', but I don't remember if they were real and happy then, or if my script was just leaving junk around in my optimism
<bob2> hehe
<bob2> will the hoary buildd's just start up with warty, and install newer stuff as things build-dep on it?
<lamont> I hate these: APIC error on CPU0: 40(40)
<lamont> but only because there are soo damn many of them.
<jdub> bob2: no, there's a few ways we could do it, not sure if we've decided yet
<jdub> - import all of sid, forgetting our patches
<jdub> - import sid, except for the stuff we've patched
<jdub> - wait until hct can merge our patches with sid
<jdub> etc.
<jdub> 1 and 2 are "distro team can keep working until hct is ready" solutions
<bob2> ah
* bob2 heads back to work, coincidentally
<jdub> hhe
<jdub> heh
<SuperLag> The default install of Ubuntu installs a very modular kernel and I get a LOT of module errors when I boot.  How can I clean that up? hw_random, pciehp, i82365, yenta are some examples... Gentoo will read /etc/modules.autoload.d/kernel-2.6 for a list of modules to be loaded (assuming you don't have hotplug enabled/installed).... does Ubuntu read a file also?  I'm just wanting to clean that up some.
<fabbione> SuperLag: it makes no difference other than for estetich
<SuperLag> wartylog: estetich?
<SuperLag> oops
<SuperLag> that was for you fabbione 
<fabbione> "to look nicer at boot"
<SuperLag> are you meaning to say aesthetics? :)
<fabbione> yeah sorry
<fabbione> en_IT ;)
<SuperLag> well, sure
<fabbione> but this is #ubuntu discussion
<SuperLag> I know that... but I'd still like to clean it up.
<chrisa> If you disable hotplug then just use /etc/modules
<jdub> daniels: what goodies does your x40 package include?
<mdz> daniels: hell yes we care about PAE
<mdz> daniels: but not particularly for X
<jdub> morning mdz
<mdz> morning
<lamont> mdz: fired mail at alex wrt apt-get.
<daniels> mdz: cool
<mdz> lamont: thanks
<lamont> if we can get that working, would be nice to include
<daniels> jdub: just a bunch of /etc/acpi scripts and a dependency on i855-crt
<mdz> lamont: localisation is the big one
<lamont> otherwise, I'm asserting that 20041022-04 is final
<mdz> that's necessary for proper demo goodness
<lamont> closing 2614
<mdz> lamont: it would also be nice if firmware loading could be made to work
<mdz> but that  may or may not be doable
<mdz> I'd like amu's opinion on it
<mdz> alex did the work of integrating the drivers, but they're useless without firmware
<lamont> yeah.  the package is there, but doesn't seem to be linked in well.
<mdz> the files are there
<mdz> they just aren't loaded correctly
<mdz> I filed a bug
<lamont> number?
* lamont searches
<lamont> 2633
<lamont> hw detection is initially done in the basemod
* lamont suspects that mdz is correct
<mdz> lamont: even after everything is up and running, if I unload it and load it again, it fails
<mdz> lamont: does it use chroot or pivot_root?
<mdz> I think pivot_root would work, and chroot not
<lamont> I think it uses chroot, claims to at least
<lamont> cool.  bootpraam 'debugmorphix' gets you a shell early on
<lamont> jdub: am I expecting new artwork from you?
<lamont> mdz: btw, Henrik indicated WinFOSS is 'go'
<fabbione> hey mdz
<fabbione> mdz: do you which setting in thunderbird can make that CR/LF mess?
<fabbione> i really can't find any
<fabbione> and i have set to compose in text mode
<jdub> lamont: hrm, don't have it already?
<lamont> mdz: were any of the other livecd bugs filed in the RC category?
<lamont> jdub: I have what you gave me yesterday
<jdub> hrm
<jdub> sent another one a while back
<lamont> while ==?
<fabbione> mdz: how is going with amber?
<mdz> fabbione: she's being difficult
<aj> don't diss amber!
<mdz> elmo said his piece was done
<lamont> my piece done
<mdz> then everything should be done
<jdub> lamont: hour or two
<mdz> and yet there are still no binaries in queue/accepted
<mdz> I wonder if it needs a nudge
<lamont> jdub: resend?
<fabbione> mdz: i didn't see any message going out..is that correct?
<mdz> fabbione: what kind of message?
<lamont> mdz: w-b access is currently blocked, I believe
<fabbione> mdz: a security-announce
<mdz> fabbione: the packages are not installed yet
<mdz> they are not even built
<fabbione> ok
<mdz> they need to be built, then tested, then an advisory sent out
<mdz> did you write one already?
<fabbione> nope
<fabbione> i tought that it is some kind of templates that needs to be filled
<fabbione> but do we have the template somewhere?
<fabbione> aj: definetely not :)
<mdz> fabbione: the template should have been mailed to you
<mdz> or perhaps to me
<mdz> but I don't think I received it
<fabbione> mdz: i didn't see anything here
<jdub> lamont: hrm, go without, it was naff anyway
<jdub> lamont: can you expand the menu across the screen?
<lamont> jdub: no clue.
<fabbione> mdz: do you know from which address should have come?
<lamont> and not really all that awake either.
<mdz> fabbione: no
<mdz> katie@somewhere I presume
<jdub> mdz: suggestion to make /initrd immutable by default. thoughts? :)
<mdz> jdub: *boggle*
<jdub> One beer says you deleted /initrd, the empty directory which pivot_root
<jdub> uses.
<jdub> People always do this. Distro's should make it immutable by default.
<mdz> I have never heard of anyone doing that before
<mdz> people who remove random directories without understanding them deserve what they get :-P
* lamont did remove the kernel once, very early in his experience with unix...
<jdub> "what a mess, let's tidy this up..."
<jdub> ;)
<lamont> jdub: actually, _I_ was just very desparate for disk space, and the 3MB file was just the trick.
<lamont> until the next reboot,that is..
<fabbione> mdz: i got twice the message from katie about libpng_ being ACCEPTED
<lamont> mdz: any objections to me just putting livecd status in my activity report?
<fabbione> mdz: that was the last one
* lamont is fading
<mdz> lamont: none
<lamont> alex and amu looking at firmware blobs?
<mdz> lamont: I gave amu the bug; he'll look at it when he's awake
<lamont> ok
<lamont> jdub: go ahead and toss me the new image and if we do another build, I'll stick it in
* lamont falls into bed.  Back in about 6 hours or so
<mdz> lamont: this latest live CD image is suddenly much bigger
<mdz> this is not good
<mdz> or perhaps I'm just hallucinating
<daniels> mdz: are we still processing univer syncs?
<mdz> daniels: not unless they're FTBFS
<mdz> or baby jesus speaks through Mark and asks for something
<fabbione> daniels: libXau doesn't create shared libs, right?
<daniels> mdz: ok, so saying 'can we get latest scummvm in, and I'll deal with it if need be' is unlikely to gain much traction? ;)
<daniels> fabbione: in the monolithic tree, no.  in the modular tree, yes.
<fabbione> ok
<fabbione> i guess that's just s imple modification to the Imake
<fabbione> simple even
<daniels> yeah
<fabbione> #define DoSharedLib SharedLibXau
<fabbione> it is defined
<mdz> daniels: correct
<fabbione> daniels: that was easy :-))
<fabbione> daniels: the templates seems to work pretty fine
<fabbione> daniels: now it's only question of finding the properr build order
<daniels> cool
<fabbione> my actual process is to pick a project
<fabbione> create the structure from the template
<fabbione> build
<fabbione> define dependency
<fabbione> import patches
<fabbione> rebuils
<fabbione> complete the usual stuff (like lintian, and other checks)
<fabbione> done
<fabbione> pretty fast
<fabbione> if one package is stalled by another it gives immediatly the next package name
<jdub> 258 in #u... yeesh
<bob2> the #u GMAIL stats are even weirder than the list ones ;)
<jdub> haha
<jdub>   ubuntu-announce:1378
<jdub>   ubuntu-devel:334
<jdub>   ubuntu-users:1020
<bob2> #ubuntu     : 95% annoying
<mdz> jdub: those are totals, or gmail?
<jdub> totals
<jdub> hrm, can we kill all the other kernel packages?
<mdz> not trivially
<mdz> universe is an incestuous mess; stuff build-depends on those things
<jdub> ouch
<mdz> we just need to train people to read the FAQ
<mdz> and train them that the name of the kernel is 'linux'
<jdub> daniels: if hoary opened tomorrow, how long would xorg be? :)
<daniels> jdub: into the tree? probably mid-to-late nov
<jdub> ta
<daniels> this is a completely hypothetical question, I take it
<jdub> no
<jdub> but if hoary didn't open tomorrow, i gather it would be around the same time
<jdub> how much earlier could it be?
<daniels> the earliest we could do it would be the second week, I'd imagine
<daniels> this is i386/powerpc/amd64
<jdub> so you wouldn't want to do it pre-X-summit?
<daniels> not until I've got together with Fabio and we've beaten all the bugs out of the migration path, not really
<jdub> ahr, yeah, that's the bigger issue
<daniels> i don't really want #ubuntu full of 'hi i ran smart upgrade and um my x isbroken' ;)
<jdub> heh
<bob2> "hi i run smart upgrade and enabled transparency and now my x is slow"
<daniels> oh my god.  don't even joke about that.
<fabbione> jdub: we will get the packages into the archive when at least the upgrade path is known to work
<fabbione> jdub: in the meanwhile we will use some temporary location
<fabbione> so that expert users can test them
<fabbione> but get ready for a big fight with bugs and stuff
<fabbione> that is going to be frustrating
<fabbione> mainly because you install X.org removing Xfree86 completely
<fabbione> that also mean that 99.9999% of the cases upgrades withing X will be highly discouraged
<fabbione> and there is really NOTHING we can do about it
<bob2> "withing" = "while running"?
<srbaker> heya everyone
<srbaker> i ordered a rather significant number of cds in the shipit system.  doesn't someone want me to justify 35 cds?  (25 x86, 5 ppc, 5 amd64?) or are there enough to go around?
<jdub> srbaker: justification only required for large orders ;)
<srbaker> jdub, that's not a large order?
<srbaker> because i was trying to keep my numbers low. :P
<srbaker> heh.  actually, that was exactly what i needed, i think.
<jdub> :-)
<srbaker> i'm handing them out to folks in my LUG, and whatever's left over, i'll be handing out at the Dal CS building.
<jdub> srbaker: put it this way... we got an order from FOSDEM.
<srbaker> Oh.
<srbaker> understood
<jdub> if a big order seems worthwhile, we'll fill it
<srbaker> where can i expect the dpkg work to be taking place?  i'm *very* interested in working on that.
<jdub> srbaker: in Keybuk's brain
<srbaker> oh.  i'm interested in working on it.  especially triggers.
<jdub> yeah, triggers sound neat-o
<srbaker> i had a problem with some elisp packages.  python-mode, actually.
<jdub> Keybuk: pingitypong
<Keybuk> heh, good timing :)
<srbaker> installed emacs, then python-mode, and then xemacs.  xemacs didn't byte compile python-mode, because it was done in python-mode's postinst
<srbaker> i think.  i could be confusing packages here.
<srbaker> and i remember thinking at the time "hey, it'd be nice to be able to notify the system that this package was just installed"
<srbaker> Keybuk, ahh, well, please include me in your dpkg work.  i'm *very* interested.
<srbaker> i was included in the ML when wiggy was talking with some folks for "dpkgv2" but it faded into nonexistence
<srbaker> Keybuk, also, i thought it might be worthwhile to investigate xdelta for source packages.
<Keybuk> xdelta is ok for binaries, never really got happy with it for patches
<srbaker> Keybuk, but a .src.deb would be a binary.
<Keybuk> ah, I see what you mean ... upload a changes and xdelta rather than the .src.deb ?
<srbaker> right.
<Keybuk> there's still the mirror-push problem though
<srbaker> push the xdelta
<jdub> rdiff :)
<srbaker> rdiff?
* bob2 likes being able to poke at .diff.gz's in the pool from his browser
<jdub> rsync diff
<Keybuk> then to get a source package you have to download a src.deb and a set of xdeltas ?
<srbaker> bob2, same.  but a browser plugin can fix that :P
<srbaker> Keybuk, sure, why not?
<bob2> hahahaha
<srbaker> Keybuk, dpkg-source -x can apply all .xdelta files.
<srbaker> jdub, doesn't rsync's diff use xdelta?
<srbaker> Keybuk, i'm not entirely sure it'd be a working idea.  i'm just throwing out ideas.
<srbaker> Keybuk, i definitely want to be included in the discussion, tho, as i said.
<jdub> nah
<srbaker> Keybuk, i'm capable and happy to write code.  i'm hesitant to just go and write code without discussing it first on something liek dpkg, though.
<Keybuk> the first hurdle isn't writing code, it's understanding the existing code and getting to a point where it can be refactored
<jdub> you need the netbeans refactoring system!
<jdub> and javur!
<srbaker> Keybuk, i was very familiar with the dpkg code at one point in my life.  it won't take long to get it back.
<Keybuk> iwj-c melts people's brains :)
<bob2> Keybuk: is your python re-write public yet?
* bob2 runs
<srbaker> Keybuk, i didn't find iwj's code to be that bad.  i actually found benc's hacking of it to be a little worse.
<jdub> you could pyrex/python it
<srbaker> oh, who's in charge of hooking up planet debian syndicators?
<Keybuk> yeah, dpkg really suffers from being a good piece of software that's been hacked on, rather than improved
<bob2> srbaker: you edit the cvs module yourself
<srbaker> oh.
<srbaker> bob2, is there a doc?
<Keybuk> srbaker: /org/planet.debian.org/README on gluck
<srbaker> thanks
<srbaker> i've been *way* too debian-idle for too long.
<srbaker> i'm about to do a debut release, too (Debian Upload Tool)
<srbaker> since shorty's being a cock
<srbaker> and the dput code didn't like my hacking too well
<Keybuk> srbaker: how's your arch voodoo?
<srbaker> Keybuk, i read the docs and have a basic understanding.
<srbaker> Keybuk, i use monotone
<srbaker> but i'm happy to work with arch, it does everything i need
<srbaker> Keybuk, why do you ask?  what have you got?
<Keybuk> I've been maintaining dpkg in arch for quite a while now, the cvs.d.o repository just gets sync'd whenever I do a dump or release at the moment
<srbaker> oh
<srbaker> cool
<Keybuk> scott@netsplit.com--2004/dpkg--devo--1.10 is the current released code; the archive's at http://people.ubuntu.com/~scott/arch/personal/
<srbaker> Keybuk, cool.  i'll grab it
<srbaker> installing ubuntu on my lappy now that i figured out what was wrong with it before
<srbaker> acpi=force, by the way
<srbaker> for those of you unfortunate enough to have toshiba lappies
<thom> tseng: oh, ber
<Keybuk> morning thombot
<thom> marnin'
<fabbione> hey thom
<Keybuk> thom: apache2 trips a pyarch bug ... be proud :p
<thom> Keybuk: ROCK!
<srbaker> pyarch?
<srbaker> wtf is that?
<Keybuk> srbaker: python API to arch
<srbaker> nice
<srbaker> the thing that pissed me off about arch was the weird directories it dumped everywhere, and it's insistence on weird directory naming
<srbaker> it's a little imposing
<Keybuk> heh, yeah, that pisses us off too :p
<srbaker> oh, good.
<srbaker> monotone just integrates with what i have :)
<srbaker> non imposing
<srbaker> :)
<Keybuk> but nothing comes close to arch wrt merging and sharing branches
<srbaker> Keybuk, ahh.  monotone uses xdelta, too
<srbaker> that's actually where i learned about it
<Keybuk> arch is oddly oxymoronic ... it has an awesome fundamental simplicity with an incredibly complicated and obtuse UI on top
<srbaker> does someone want to make a "broken toshiba lappy use acpi=force" note?  is there a forum or something that i should dump that in?
<srbaker> Keybuk, heh.  same with monotone
<srbaker> i'm currently writing a web interface to monotone.  it sucks currently, but it's coming along.
<srbaker> that's my other project, in addition to debut.
<srbaker> i keep hitting dput bugs, and short's a prick, so i'm doing the right thing
<bob2> Keybuk: you're full of arch gripes!
<Keybuk> bob2: heh, it was a bad day I wrote that <g>
<Keybuk> I'd hit all of them in about an hour
<bob2> Keybuk: that said, I want a copy of your book
<srbaker> what book?
<srbaker> and what writing?
<srbaker> i feel out of the loop
<bob2> I'm just troll Keybuk because I'm bored.\
<Keybuk> heh, "Arch Is Easy, and other Lies The Developers May Have Told You"
<Keybuk> bob2: this explains your lack of progress with hct :p
<bob2> ah, erm, eh :-)
* bob2 returns to work
* Keybuk wins \o/
<Keybuk> You attack the troll--more--
<Keybuk> The troll dies
<pitti> Hi mvo_
<mvo_> hi pitti 
<srbaker> hct?
<daniels> Keybuk: of course there's no progress, it's hypothetical
<srbaker> oh, where do i get the dvdcss library for ubuntu?
<daniels> http://wiki.ubuntu.com/BinaryDriverHowto
<daniels> or maybe RestrictedFormats
<daniels> but it's on there, quite plainly
<Keybuk> bah, I wish arch could do multiple inheritence
<bob2> of?
<Keybuk> tags which are continuations of two different branches <g>
<pitti> Does anybody know when the Hoary feature goals meeting will be?
<bob2> Keybuk: hah
<thom> monday afternoon was the last i heard
<Keybuk> to shut star-merge up and it's "trees are not related"
<bob2> Keybuk: you can merge the trees to one, but the branch can only inhereit from one of them
<bob2> ah, right
<pitti> thom: ah, I heard sth about today (from previous meeting). Thanks
<Keybuk> base-0, continuation of X; patch-1, sync-tree of Y
<Keybuk> is just sucky
<daniels> thom: monday afternoon utc?
<Kamion> huh, I'd thought the Hoary meeting was today too
<Kamion> obviously a shared hallucination or something
<pitti> Kamion: no, that was proposed on Tuesday's meeting
<pitti> but I did not ready any announcement on the lists
<pitti> BTW, #u-meeting still claims that "today" is a TB meeting
<pitti> I'm going to clear this
<Kamion> mdz: can I move this proactivesecurity stuff into the TB agenda, or at the very least off the CC agenda?
<srbaker> well, i think 5:30a is about a good time for bed
<pitti> Morning seb128
<seb128> hello pitti 
<elmo_> Kamion: am I okay to clear out old instances of d-i and/or the daily images?
<thom> Kamion: hm, i thought that we were "off" until monday
<srbaker> Hey!
<srbaker> There's no Ubuntu porn on my login screen.
<srbaker> the screen shot on the website promised me ubuntu porn
<pitti> thom: although we are "off", could you take a look at https://chinstrap.warthogs.hbd.com/~pitti/
<pitti> thom: it contains security updates for xpdf and cupsys
<pitti> thom: the patches are taken from the Debian packages, but mdz wants a review nevertheless
<pitti> anybody else would be fine as well, of course :-)
<pitti> interdiffs are available, too
<srbaker> okay, huge problem
<srbaker> i just installed warty.  logged in via gdm
<srbaker> and it sits there.
<srbaker> i don't get the startup splash screen
<Kamion> elmo_: daily images yes
<srbaker> is this a known problem i'm having?
<Kamion> elmo_: and yes, might as well clear out 20040801ubuntu{13,18,19}
<Kamion> thom: I could easily be on crack :)
<shlomil> srbaker: try to choose session 
<srbaker> shlomil, i chose "gnome" and same thing
<srbaker> i'll try failsafe gnome
<shlomil> check your disk quota 
<bob2> pitti: I'm almost certain suspend isn't meant to work on ibook g4s
<thom> Kamion: 
<thom> 17:47 < Kamion> mdz: Thursday for sleep, Friday for meetings? :)
<thom> 17:47 < Keybuk> elmo: rookery doesn't have much on it though (like tla :p)
<thom> 17:47 < mdz> Kamion: thursday-sunday sleep, monday meeting?
<pitti> bob2: I had tried this in Sid, there it worked, somehow
<pitti> bob2: but I'm not so sure about it
<bob2> pitti: hm, not just turning the backlight off?
<pitti> bob2: I'm not sure
<bob2> pitti: closing the lid on mine just turns that off and eventually hard-shuts-down if I don't open it again
<pitti> bob2: it took a while until it woke up again
<pitti> bob2: unlike Ubuntu, which immediately wakes up again
<bob2> pitti: hm
<pitti> bob2: but there was another problem, if I left it to sleep long enough, it completely went down
<pitti> anyway, breakfast
<pitti> brb
<srbaker> shlomil, with failsafe, i get the splash screen, but no icons or anything
<srbaker> it seems to hang there
<srbaker> shlomil, and i don't have quotas configured
<shlomil> no icons on desktop ? 
<shlomil> ... thats normal in Ubuntu .. ;)
<bob2> pitti: yeah, same here
<bob2> pitti: and not a polite shutdown, more like a powercut
<bob2> pitti: btw, do you have gtkpbbuttons working in warty?
<srbaker> shlomil, uh, what?
<srbaker> shlomil, gnome-session is hanging
<shlomil> i don't know man 
<shlomil> srbaker: when i asked about quotas, i ment also free space
<shlomil> srbaker: sometimes this happens when there's no space left on the device 
<srbaker> no.
<srbaker> there's lots of space
<srbaker> so, not only do i not get my porn, it's broken
<srbaker> how nice.
<shlomil> srbaker: try to login in text mode , shutdown gdm and run startx 
<srbaker> k
<pitti> bob2: I tried gtkpbbuttons, it worked
<srbaker> should i empty my homedir of gnome files first?
<pitti> bob2: but I don't really use them
<pitti> srbaker: you can try
<srbaker> i already did tha ,and added "gnome-session" to ~/.xsession
<srbaker> same thing
<pitti> srbaker: but before you can just try to login as another user
<shlomil> srbaker: you can create a new user maybe 
<srbaker> under "failsafe" gnome, i got the splash screen, but it hung there
<srbaker> gah.
<srbaker> running startx as a new user starts up
<srbaker> but it's *S L O W*
<srbaker> my lappy may still be fucked up
<srbaker> anyways, bed time
<srbaker> it's 6am
<shlomil> heh
<shlomil> might be not enough memory .... (?)
<shlomil> gnight 
<amu> moinD
<Kamion> lamont: do you want a new version of the live CD dropped onto releases.ubuntu.com?
<Kamion> hm, not entirely convinced by InstallFromKnoppixHowto ...
* Kamion downloads Knoppix in order to test out better methods
<pitti> elmo_: Hi! Any news regarding warty-security?
<Kamion> 03:00 < joeyh> less than 8 hours from UPS to a fully automated debian install, and that included the time to write the interface to the remote management interface
<Kamion> THAT'S where I want to be with ia64
<elmo_> pitti: you can make uploads if you like - they'll be in limbo till mdz gets up and we can finish testing the actual release mechanism
<thom> elmo_: any sign of the itanic^Hums?
<elmo_> (they'll get accepted and built tho, so  it's probably worthwhile)
<elmo_> thom: dude, why do you bother logging on to jabber, if you don't read msgs there? :P
<elmo_> (i.e. see jabber)
<thom> heh
<thom> i guess i need to make gaim make alarming noises
<elmo_> have it pop  up in your face - then you too can type your passphrase/word at random jabber-buddies
<pitti> elmo_: okay, then I'll upload the stuff to get it built and send mdz the interdiffs for approval
<elmo_> free  for a limited time offer
<pitti> elmo_: thanks
<elmo_> pitti: hmm, don't upload unapproved stuff
<daniels> elmo_: 'your account disabled -- only $1.95 with any large value meal'
<elmo_> pitti: like a normal upload, once it's uploaded, it's final
<pitti> elmo_: okay; I asked mdz yesterday to approve, but maybe he has some more time today
<thom> free rm -f with every upload!
<amu> Kamion: morphix installer is nice. But needs some work. Knoppix installer inst such flexible, _and_ unmaintained 
<pitti> elmo_: then I'll send him a link to the packages and he can upload himself
<Kamion> amu: don't really care, I'm only using it to install Ubuntu *from*
<mjg59> ARGH.
<mjg59> An NTL man is outside.
<Kamion> amu: p.s. read the doc, it's not actually the Knoppix-install-to-hard-disk thing
<amu> Kamion: the live ?
<mjg59> He's on the phone to NTL.
<mjg59> He's on hold.
<mjg59> On a hands-free kit.
<Kamion> amu: read http://wiki.ubuntu.com/InstallFromKnoppixHowto :-)
<mjg59> I'm being forced to listen to NTL hold music without the joy of knowing that I'll get to scream at NTL afterwards.
<thom> mjg59: *giggle*
<Kamion> I suppose I should log into jabber like once a lifetime or so
<amu> Kamion: Ah got it. 
<pitti> Hi silbs!
<rburton> congrats on warty by the way
<rburton> didn't get to say it yesterday
<seb128> hey rburton, thanks :)
<thom> hey ross
<rburton> hey hey
<daniels> rburton: hey dude
<rburton> hi daniels 
<daniels> wie gehts?
<amu> Kamion: hehe, nice idea, maybe debtakeover is also a option ;)       
<Mitario> lo everyone!
<daniels> heh, one of the negotiators on the negotiator looks like taggart
<pitti> sjoerd: hum, you install the gthumb wrapper into /usr/bin; we do it to /usr/share/g-v-m/
<pitti> sjoerd: any way I could convince you to do the same? :-)
<pitti> sjoerd: in the long run we should get rid of this hack anyway, but...
<sjoerd> pitti: if you have a good rationale why to do it in /usr/share :)
<pitti> sjoerd: it's a temporary hack and should not clutter up /usr/bin
<pitti> sjoerd: when people start to write scripts which rely on this hack, it's difficult to get rid of it
<sjoerd> pitti: with the last reason you've got a point
* sjoerd wonders if there is some kind of policy about helper scripts
<pitti> sjoerd: I plan to rewrite this part anyway
<pitti> sjoerd: but right now I'm synchronizing to your version, I want to clean up first
<sjoerd> pitti: rewrite as in let g-v-m have seperated cases ?
<sjoerd> sounds sane
<pitti> sjoerd: the funny thing is that g-v-m already has separate cases
<pitti> sjoerd: these are merged at some point to call the wrapper script
<pitti> sjoerd: which has to sort them apart again
<pitti> sjoerd: could you help me with the UI part?
<sjoerd> yeah it's just one property 
<pitti> sjoerd: we should have two properties
<pitti> sjoerd: and probably they should both be configurable in the prefs dialog
<pitti> sjoerd: you already hacked at this, can you do this again?
<sjoerd> pitti: sure
<sjoerd> no right now though :), probably somewhere during the weekend
<rburton> gar
<rburton> does anyone have a decent svg of the ubuntu logo without a weird bounding box?
<rburton> right, i've done one
<rburton> can i edit attachments in the wiki?
<Kamion> ai
<Kamion> can people please be sure not to misspell "Ubuntu" when writing documentation?
<lamont> Kamion: my normal issue is spelling it ubunut
<lamont> mdz: -rw-r--r--    1 lamont   buildd   673589248 Oct 20 07:50 20041020-07/warty-live-i386-20041020-07.iso
<lamont> -rw-r--r--    1 lamont   buildd   674152448 Oct 22 04:24 20041022-04/warty-live-i386-20041022-04.iso
<lamont> 600KB bigger is not "a lot bigger"
<mjg59> Why the christ are people suggesting GRs about changing release policy?
<lamont> mjg59: because we can force those techincal bastards to release _NOW_ that way, whether it's ready or not, dammit.
<lamont> :-(
<mjg59> lamont: Actually, I think they want to propose freezing unstable
<mjg59> I'm increasingly of the opinion that there's about 10-15 people that should be culled from Debian
<mjg59> Some day I'll get around to actually writing this list down
<lamont> mjg59: that violates the 6-shooter principle, though
<mjg59> lamont: We line them all up first
<lamont> but it's been violated before by other organizations
<rburton> mjg59, our office admin guy would probably make a good hired goon
<lamont> amu: about?
<Keybuk> how odd ... I've not received any mails from debian-vote since August 20th
<Keybuk> in fact, it's more likely since July 27th
<Kamion> mjg59: I have a ~/debian/morons file
<mjg59> Kamion: Hurrah!
<Kamion> although it's too short currently
<daniels> heh!
<elmo_> kamion: clearly that should be gluck:public_html/morons.txt file ;-)
<mjg59> We should all pool our morons databases and then figure out the best way to neutralise these people
<Kamion> elmo_: arguably :)
<lamont> Kamion: I think I want to wait and hear from amu and get an ACK from mdz, but 20041022-04 looks to be rc2
<Kamion> mjg59: Mr. "I Think It's Sensible To Set Release Policy By GR" is inexplicably not among them; let me rectify this
<|trey|> Kamion: I better not be in there  ;P
<Kamion> |trey|: I don't even know your name
<daniels> |trey|: you're not a debian developer, either.
<|trey|> Kamion: k good  ;)
<|trey|> daniels: ^
<lamont> Kamion: I bet his name is 'trey'. :-)
<|trey|> I want to learn, but haven't the time for programming... brains fed too much infomation tend to explode  :(
<lamont> mjg59: "shiny bright"
<lamont> well, that only gets some of them
<Mitario> seb128, here?
<hornbeck> is the only mono packs in universe now, are they out of tsengs repository?
<pitti> Hi carlos, howdy
<carlos> pitti: hi!
<amu> lamont: ?
<amu> lamont: 22-04 still dl'ing
<Mitario> rburton, hiya
<rburton> hey Mitario 
<Mitario> have some time? :)
<rburton> give me two
<rburton> (minutes)
<Mitario> heh, ok :)
<T-Bone> hi
<Mitario> hi tbone
<rburton> Mitario, right, i've got coffee and music. let's talk
<Mitario> heh, ok
<Mitario> about the update stuff, dunno if you've read my proposal?
<rburton> yeah, i saw it
<rburton> its ruby at the moment, right?
<Mitario> yes, but we want to change that
<Mitario> to either c++, with libapt, or python if python-apt evolves
<rburton> http://www.burtonini.com/computing/screenshots/app-install.png is a work-in-progress of my app-install program
<Mitario> and we wanted some of your opinions on what language and such
<Mitario> ok, wow, that looks cool
<rburton> i'm using python and am currently hacking code to call synaptic --set-selections
<rburton> but the goal is to extend python-apt
<rburton> (i'll put this is cvs somewhere at some point)
<Mitario> hm, then it would come in handy if the update list app is also written in python
<rburton> i thought extending python-apt would be best as if i used c++ i'd have to write exactly the same code
<rburton> so i may as well go the mile and write it as python bindings
<rburton> all i need is someone who knows python bindings and libapt-pkg to do the work for me ;)
<Mitario> heh :)
* Mitario doesn't know python at all
<Mitario> so i'll have to learn that first, but shouldn't be hard
<rburton> if you know ruby, not at all
<Mitario> oh, and nother little thingy: what is your idea on calling everything 'updates' or 'upgrades'?
<rburton> hm
<rburton> i see your app as updates
<rburton> the main use will be security updates
<rburton> when a new release comes out, its probably best to use synaptic anyway
<Mitario> guess to yes
<Mitario> hmm, i don't know about that, because we don't have any distinction between security updates and for example new upstream releases
<Mitario> although I could parse the version string of the package
<rburton> true. when a new release comes out it your app will offer them all
<Mitario> yep
<rburton> but the dist-upgrade logic is different to the upgrade logic
<Mitario> how michael and I currently thought if it that the update list app just calls synaptic --set-selections
<Mitario> and handles all dependencies and such
<rburton> should do the job
<mvo_> we could use the origin or the package to find out if it's a security update
<Mitario> good idea
<rburton> synaptic in svn has an option now to hide the main window, i poked michael about that earlier
<mvo_> or the label
<mvo_> Keybuk is no longer around? 
<Mitario> so, current procedure is update notification -> list updates -> call synaptic with --set-selections
<Mitario> where list updates could make a distinction between security updates or just regular updates
<mvo_> and depending on the preferences of the user: "--non-interactive --hide-main-window"
<rburton> show top of the list, a cute emblem, etc
<pitti> bob2: okay, I updated g-v-m and built the whole lot for powerpc
<Mitario> rburton, just like your add/remove app would be nice
<pitti> bob2: have fun ;-)
<pitti> Hi mvo_
<Mitario> mvo_, yes
<mvo_> hi pitti !
<Mitario> although the --upgrade-mode of synaptic could also be somewhat nicer
<pitti> mvo_: still with your old nick?
<rburton> hm, the python docs lie
<rburton> ah, no they don't
<mvo_> pitti: yes. no idea for a better one yet. maybe I sould start a poll ;) vomi is possible but it sounds a bit like vomit I think ...
<Mitario> mvo_, can't we build in some kind of mode that all the windows will be replaced by something like http://geeklog.eyesopened.nl/ubdates/updatedialog.png?
<Mitario> so, the user doesn't know about refreshing the package list, setting the selection, downloading the stuff and etc.
<Mitario> but just knows 'oh, my computer is updating the packages'
<rburton> i would like an abridged progress dialog
<pitti> mvo_: my proposal was voimi :-)
<rburton> but as mvo_ said to me earlier, once apt starts you can't get progress
<Mitario> hmm, bummer
<mvo_> dpkg is the problem actually :)
<mvo_> dpkg --status-fd may help, keybuk pointed me to it
<rburton> rock
<mvo_> but we still need to solve conf-file handling
<rburton> urgh, yeah
<mvo_> and apparently it does not give progress information about the unpacking :/
<Mitario> what about the debgconf gtk frontend thingy?
<rburton> enforce "N" and tell the user?
<mvo_> so it's not quite there yet, but it's a start :)
<Mitario> rburton, or only show up a dialog if debconf asks for it
<rburton> yeah
<Mitario> hmm, will there be much debconf question if the package has a small package/security update?
<Kamion> unlikely just for security updates
<Kamion> although it's possible
<Mitario> hmm, yea
<bob2> pitti: yay, thanks a lot :-)
<rburton> it is quite likely there could be conffiles changes
<elmo_> Kamion: can you imagine a powerpc machine with i8042?
<Mitario> ok, and what about configuration?
<Kamion> elmo_: yes
<elmo_> kamion: which ones?
<Kamion> elmo_: CHRPish boxes have them
<elmo_> do CHRP do power4?
<Kamion> elmo_: basically anything IBM
<Mitario> i think we just need some kind of dialog to pop up when gconf asks a question
<Kamion> elmo_: yes
<elmo_> meh, ok
<Mitario> whether that's a gtk frontend, or a terminal widget, doesn't matter much IMO
<Kamion> newish RS/6000 boxen
<mvo_> yes, I think we need to solve the conffile problem if we want to hide the dpkg output 
<Mitario> euhm, s/gconf/debconf
<elmo_> hmm, but hangon, CHRP needs something other htan PPC_MULTIPLATFORM, right?
<Kamion> mvo_: or do an expect-like trick
<Kamion> elmo_: don't think so?
<Kamion> <cjwatson@riva ~/src/ubuntu/linux-source-2.6.8.1/linux-source-2.6.8.1-2.6.8.1/ar
<Kamion> ch/ppc/configs>$ grep PPC_MULTIPLATFORM ibmchrp_defconfig
<Kamion> CONFIG_PPC_MULTIPLATFORM=y
<mvo_> Kamion: probably. if status-fd tells about the problem, we could do something like this
<elmo_> gar, sux2be an Xserve then
<Kamion> elmo_: and we have CONFIG_PPC_CHRP=y in our kernels
<mvo_> I'll just pester keybuk with it :)
<Mitario> mvo_, is there 
<Mitario> woops
<elmo_> kamion: I was just thinking if there was some way we could exclude i8042 as Y based on config variables is all
<elmo_> kamion: (#2605 for ref)
<Mitario> yea, debconf needs to notify the package manager that it needs user interaction
<Kamion> elmo_: it happens that we don't support CHRP right now, but we've had about as many queries about RS/6000 support as we've had about Xserve G5 support by my reckoning
<Kamion> so it'd be nice, and CHRP is *relatively* non-evil since it basically uses yaboot
<Kamion> elmo_: yeah, saw that. not sure why i8042 can't be modular though
<elmo_> Kamion: sorry, don't get me wrong, wasn't suggesting we drop/not support chrp or anything
<Kamion> elmo_: d-i already has support for modprobing i8042 ...
<elmo_> kamion: can and is, that's why it's minor.. it's to try and help  freaks who compile their own kernel
<Kamion> elmo_: yeah, I know, it's an awkward problem
<Kamion> elmo_: ah
<Kamion> elmo_: well, how about making I8042 depend on PPC_CHRP, or something?
<Kamion> (whatever needs it, maybe PPC_CHRP | PPC_PREP)
<mvo_> rburton: will the app-installer only work with applications in main? or will it support universe as well?
<rburton> mvo_, just main
<Kamion> elmo_: then presumably you'll not compile CHRP support into your custom kernel and you'll get a warning if you try to turn on i8042
<rburton> mvo_, latest versions have an "Advanced" button which spawns synaptic
<mvo_> so you use a config file that white-lists what apps are we allow to install?
<rburton> far more cunning than that
<mvo_> tell me :)
<rburton> mvo_, jdub originally had the idea to embed the data in .desktop files
<mvo_> please
<mvo_> yes, that was my original idea as well
<elmo_> kamion: yeah... but i guess there might be other ppc embedded stuff with i8042's.. I should probably just give it up.. after all, it's not rocket science to figure out the culprit when it panics :)
<rburton> mvo_, i'm hacking it with local .desktop files at the moment, but this afternoon i'm going to try and write a script to scan a deb archive and extract the .desktop files and the icons
<Mitario> wow
<Mitario> sweet :)
<Kamion> elmo_: well, suggested it to Herbert anyway, will see what he thinks
<rburton> thus you get names, descriptions and icons
<Mitario> rburton, doing all this with python-apt?
<mvo_> rburton: I can send you a prototype for such a script. i hacked it to find out about how many dekstop files are in the archive. it's a bit messy though :)
<rburton> mvo_, that would be great
<rburton> Mitario, hopefully
<rburton> hm, can i spawn a new process in python which is detached from the parent?
<tseng> thom: noticed a few other things as well
<Mitario> so, any place where we can host all stuff? (svn/cvs repo's)
<rburton> Mitario, i was going to abuse my gnome cvs commit access
<Mitario> heh, euhm, well, can do that too :/
<Mitario> don't we have to ask permission for it?
<rburton> not now the server has huuuge amounts of disk space i believe
<Mitario> really? so I won't get ass-kicked if I import a module?
<Mitario> rburton, btw, that screenshot you just showed, is it a mockup? or actually code?
<rburton> Mitario, code
<Mitario> hmm, I would love to know how you have made that lovely treeview in python :)
<rburton> GtkTreeView is a black art
<rburton> every time i use it i learn something new
<rburton> i was going to write a big blog entry about it
<Mitario> heh :)
<rburton> Mitario, summary: renderer.set_cell_data_func() can do a lot.
* Mitario wonders if making ruby-apt bindings is hard
<mvo_> rburton: mail with the desktop file scaner is on the way
<rburton> cool
<rburton> mvo_, i *think* there is an easier way
<mvo_> tell me
<rburton> i may be wrong, give me a minute :)
* Mitario reads diveintopython
<lamont> amu: cool.
<lamont> amu: wondering about the firmware loading stuff that you were looking at.
* rburton on phone
<fabbione> re
<fabbione> mdz: ping
<daniels> wow, workrave is awesome
* daniels disables gnome-typing-monitor.
<fabbione> daniels: damn.. i can't link xlibi18n properly
<daniels> the monolithic tree's libx11 is horiffic
<daniels> horrific, even
<fabbione> daniels: well.. there a simple solution
<fabbione> it's a subsplit :-)
<fabbione> X11 builds and links fine
<fabbione> i can't manage to tell the xlibi18n where to find the .so for linking
<daniels> erk
<daniels> you hvae to build i18n with libx11
<daniels> there's not much way around that, i'm afraid
<amu> lamont: firmware, hmm 3 points, depends our policy, the driver itself, there are problems with acpi/suspend and of course a licenses   
<lamont> amu: the firmware we think we can ship is on the CD, not getting installed correctly.
<lamont> at the very least, a note for the errata saying how to install the firmware post-boot...
<lamont> mdz said that even if he installed the firmware post boot, removing/reinserting didn't dothe right thing either.
<amu> lamont: the driver itself it's fine ? most of drivers arnt designed for 2.6 and acpi   
<lamont> amu: dunno
<lamont> apparently works on installed kernel, not on liveCD, or I'd expect mdz to have said it differently
<amu> lamont: a clean driver with kernel 2.6 support should be no problem, me points to the wifi, those sucks without end  
<lamont> right.
<amu> lamont: i do not know, we should add those firmware step by step, each release on more, and wait for a bugreport 
<fabbione> daniels: no no.. i18n is built after X11
<lamont> amu: the firmware is on the CD.
<lamont> for warty
<fabbione> daniels: but i think i found the option to use
<daniels> fabbione: i think the trees are codependent though
<lamont> it's just not downloaded to the card correctly.
* lamont bbiab
<amu> pciid's / usbid's are known ? 
<fabbione> daniels: the i18n has it's own set of configfiles. It ignores most of the top level Imakefiles entries
<mvo_> rburton, Mitario: I just looked over python-apt and it looks like the complette pkgDepCache interface is missing
<fabbione> daniels: basically a retarted mess
<daniels> fabbione: and this surprises you? :)
<Mitario> mvo_, enlighten me, what's that precisely (i'm not too familiar with apt internals)
<fabbione> daniels: considering you are upstream? no :P
<mvo_> Mitario: it is need to mark packages for install and removal and stuff
<Mitario> ah
<Mitario> well, do we need that?
<Mitario> i mean, we call synaptic --set-selections
<Mitario> don't we?
<mvo_> sure :) I was just thinking about the long-term needs
<mvo_> if we want to be 100% python in the future
<Mitario> ok :)
<Mitario> hmm, yeah
<daniels> fabbione: hey man, I'm not upstream for that monolithic POS :) i'm upstream for the working modular stuff
<fabbione> daniels: same POS :P
* fabbione hides
<rburton> mvo_, huge amounts of apt-pkg are missing
<mvo_> rburton: yes. fetcher, and installprogress too
<daniels> fabbione: hey man, modular == love
* fabbione kicks Library.tmpl
<fabbione> that's why it was not linking
<daniels> see?
<fabbione> in my imakefile
<fabbione> EXTRA_LDLIB = -L../../..
<fabbione> that is loaded before Library.tmpl
<fabbione> that of course has:
<fabbione> EXTRA_LDLIB =
<fabbione> ok changes the xi18 template
<fabbione> and that's it
<fabbione> that call isn't used anywhere else
<Mitario> mvo_, rburton, btw if we use synaptic as default, we need to let the packages depend on it (which is ok by me)
<rburton> yeah
<daniels> fabbione: this is why you need to use the modular tree, dude
<fabbione> daniels: dude.. it's not like i don't want to use it
<fabbione> daniels: we need to figure stuff out first anyway
<daniels> which stuff?
<fabbione> daniels: well I need to figure stuff out first
<fabbione> i am getting to know each single bit of the tree
<daniels> yeah
<fabbione> i am definetly tired
<fabbione> it was such a simple solution that i couldn't even see it
<lamont> amu: same card works on installed system, etc, etc.  it's simply that the downloading of the firmware is b0rked
<daniels> jamping
<daniels> er
<amu> lamont: looks like, the other thing is driver itself, what happen after a suspend. If it comes up again, i suggest driver is acceped
<lamont> the other thing?
* amu sends ipw2100 to hell  
<amu> lamont: loading a driver is a criteria, the sys should load them. But what we win, if the driver is loaded but under working conditions it crash all time ?
<lamont> true
<amu> best example ipw 
<Mitario> rburton, mvo_ have an idea for the name of what is now called my 'update-center'?
<rburton> Mitario, erm...  Available Upgrades?
<Mitario> yeah, i mean package and binary name
<Mitario> update-center is a little too 'big' for it
<Mitario> i mean, it just shows you the available updates, lets you select them and install them
* fabbione starts the X variant of the Ubuntu dance
<rburton> ah
<Mitario> hmm, 'update-manager'?
<rburton> Mitario, deb-updater?
<Mitario> hmm, good idea
<Mitario> rburton, update-manager gets more votes here :)
<rburton> update-manager works for me
<mdz> fabbione: pong
<mdz> Kamion: proactive security stuff sounds like ->TB, or even ->HoaryKickoff
<Kamion> yeah, doesn't seem like a board issue until there's actually something for the board to decide on
<Kamion> -> HoaryHedgehog maybe?
<mdz> elmo_: libpng looks good as far as binaries and stuff; are we clear to amber?
<mdz> Kamion: I think so, yes
<mdz> at the kickoff meeting, we'll review all of the proposed featured and decide what we can do
<Kamion> I stuck a bunch of stuff in InstallerTeam
<Kamion> although maybe it fits better in HoaryHedgehog, I'll review
<Kamion> daniels: is it seen as a problem that Xcb's name clashes with that of a cut buffer library?
<Mitario> rburton, oh, about the configuration, like if the user even wants an automatic updates check, shall we put those in gconf?
<Mitario> or do we need a more general config something
<rburton> probably a good idea, with a check box in the UI somewhere
<Mitario> yeah ok, but which config back-end do we use?
<Mitario> best thing would be some kind of Computer -> System Configuration -> Automatic Updates configure app
<lamont> Kamion: am I correct in believing that d-i needs Packages, not Packages.gz?
<Mitario> and I like to use gconf for that
<Kamion> lamont: I thought it could cope with either
<Kamion>             for ext in '' '.gz'; do
<Kamion>                 pkgfile="$comp/debian-installer/binary-$ARCH/Packages$ext"
<Kamion> lamont: WHICH Packages? :-)
* lamont will try it that way.
<Kamion> lamont: debian-installer/binary-$ARCH, or just binary-$ARCH?
<Mitario> but enabling the update-notifier could be better arranged at distro-level
<lamont> well, turns out that not having main/debian-installer/binary-i386/Packages* was kinda fatal. :)
<Kamion> certainly you need one or the other
<Kamion> what are you trying to do?
<lamont> and the error message was a bit less than helpful for a while...
<lamont> install DVD
<Keybuk> it'd be better having a "Software" system configuration dialog, from which you could edit sources.list etc.
<mvo_> Mitario: apt has it's own config system
<Kamion> lamont: you know, I could probably just build one on little with considerably less faff ...
<Mitario> mvo_, ok, but the user should be able to configure if the update-notifier is started at for example login
<lamont> Kamion: so I started with our install release CD, and dropped in a new pool and dists. kinda nuked a couple things..
<Kamion> what extra stuff are you trying to include?
<mvo_> agreed
<lamont> all of main, restricted, and little bits of universe (gotta have frozen bubble, dammit)
<lamont> then I dropped the open CD in to flesh out the 4.x GB
<Mitario> mvo_, what kind of mechanism can we use for that..
<Kamion> lamont: mmmkay
<Kamion> I think we should start building DVDs for Hoary, personally
<Kamion> although maybe weekly rather than daily
<lamont> Kamion: it gave my dvd burner something to do while the livecd images were building yesterday
<Kamion> bit uncomfortable with chewing 12GB a day :)
<lamont> Kamion: if you built me 4GB, I could download it in somewhere around 14 days
<mvo_> Mitario: we could use the apt conf file mechanism for this, it's pretty flexible and generic. but then we will have to link against it :/
<daniels> Kamion: not really, we've dealt with this sort of thing before; library vs binary
<lamont> or pay through the nose
<Kamion> lamont: jigdo, dude :)
<Kamion> might not even put the DVDs up for download most of the time
<lamont> gonna have to learn that sometime, eh?
<lamont> fwiw, my solution was to add main/debian-installer/binary-i386 to my mirror, and then things are "just dealt with"
<lamont> although the mirror only has .gz for Packages and Sources, hence the question
<Kamion> lamont: I'd've thought just Packages.gz would be fine; if not, there's a bug. Make sure it shows up in dists/warty/Release ...
* Kamion does 'cvs -nq up' in his debian-cd checkout, and fears
<lamont> that's all there - It was an early victim of the "d-i missing, but error not clear to this moron" thinking
<lamont> freshening a few depends into my archive, and then I'll burn another
<Kamion> there are a number of things which can easily go wrong; you get used to them fairly quickly and learn to automatically avoid them ...
<lamont> md5sums.txt is just for warm fuzzies, yes?
<Kamion> one gotcha is: you cannot have more than one debian-installer Packages file (i.e. multiple components).
<Kamion> lamont: no, cdrom-checker looks at it
<lamont> ok.
<Kamion> technically optional, in that cdrom-checker is optional
<fabbione> mdz: elmo said that he was waiting for you to "amber"
<Kamion> you'll run into the multiple-d-i-Packages problem with restricted firmware udebs; the standard workaround is to just cat the two Packages files together
<Mitario> mvo_, another then, when are you going to check when/if the upgrade-notification daemon should be started?
<Kamion> (so you end up with dists/warty/main/debian-installer/binary-*/Packages* mentioning stuff in pool/restricted/, but, well, can't be helped ...)
* fabbione just found a way to simply xorg build dep and patches of one level... just because he opened his eyes
<lamont> Kamion: trivial to generate though
<Kamion> lamont: yep
<mdz> fabbione: do you have advisory text written?
<Kamion> eventually, I hope to make it that you can install debian-cd from hoary and build Hoary CDs ...
<Kamion> but that's a ways away
<fabbione> mdz: i was going to copy the one from joey
<fabbione> mdz: i don't have anything better than that
<Mitario> mvo_, we can put the daemon in the default session
<mdz> fabbione: ok, I will write it
<fabbione> mdz: ok
<mvo_> Mitario: yes
<Mitario> and let the daemon check for a gconf/configuration key
<Mitario> gconf would be the nicest
<lamont> Kamion: thanks
<Mitario> mvo_, good ideas (tm) sjoerd simons
<Mitario> :p
<sjoerd> Mitario: hehe
<Mitario> ^^
<aj> warty includes some debs straight from experimental?
<daniels> aj: specific example?
<aj> gnome-terminal
<elmo_> mdz: yes
<daniels> er, all our GNOME stuff was done in-house and later contributed back to Debian by way of an upload to experimental, IIRC
<elmo_> mdz: sorry, I sent you mail, but it didn't work, cos of  where I am
<Kamion> gnome-terminal may be an exception
<Kamion> it doesn't seem to have been updated in warty since June
<Kamion> presumably we just took a convenient package of whatever was the latest version
<Kamion> (upstream)
<Kamion> I remember seb128 mentioning that there hadn't been a new upstream release of gnome-terminal for 2.8
<Mitario> reminds me
<Mitario> seb128, here?
<seb128> they release 2.8.0 last week
<seb128> released
<Mitario> seb128, if you want to create a new trashapplet package, just diff against trashapplet in gnome-applets
<seb128> I don't
<Mitario> ok :)
<seb128> warty has been released, no new version
<seb128> and hoary will have gnome-applets 2.10 ...
<Mitario> ok
<seb128> what about gnome-terminal ?
<aj> does kill -HUP $NVI_PID  make nvi write a save file, or is it something else?
<seb128> for gnome-terminal, 2.7.3 has been released the 30th of june and 2.8.0 the 16th of october
<seb128> that's why it has not changed in warty
<Keybuk> Mitario, rburton: http://people.ubuntu.com/~scott/software.png
<Mitario> Keybuk, cool, a friendly sources.list editor?
<Kamion>        SIGHUP
<Kamion>        SIGTERM
<Kamion>               If the current buffer has changed since it was last  written  in
<Kamion>               its  entirety,  the editor attempts to save the modified file so
<Kamion>               it can be later recovered.  See the vi/ex Reference manual  sec
<Kamion>               tion entitled Recovery for more information.
<Keybuk> *shrug* just done a UI mock-up to inspire your discussion :p
<Kamion> (apologies for UTF-8)
<Mitario> Keybuk, aah, well this looks great really :)
<Mitario> I would like to see something like this in the menu :)
<Mitario> and as soon as you check the 'internet update' checkbox, the notification daemon is loaded, and a gconf property is set
<Keybuk> would be good, wouldn't it
<Mitario> yeah :)
* Mitario is hacking on update-notification atm
<Mitario> upgrade*
<Mitario> still have to come to a consistancy on those update/upgrade terms :)
<Keybuk> I'd use "update" to refer to changes in individual package versions and "upgrade" to indicate a new release
<Mitario> i like to see it like this: there are updates for packages available, as soon as you install those updates, you upgrade the package, but of course, i can be totally wrong :)
<Keybuk> Kamion: interesting that it uses  and  instead of just  and 
<Kamion> Keybuk: that's what happens when you write ``foo'' in groff source
<Keybuk> yeah, but why double single-quotes and not just a double-quote ?
<Kamion> because that's what the manual page says to do :)
<Kamion> `` can't count as a single output glyph in groff
<Keybuk> heh
<Kamion> there are other ways to get an open double quote, by not using such silly markup
<mvo_> Keybuk: interessting mock-up
<Mitario> indeed
<aj> err, does warty contain m/any reversions? ("eww, the version in sarge has crappy new features, let's go back to version X") ?
<Kamion> none that spring to mind; the only thing we had to seriously back out from was mozilla-firefox 1.0pr1
<Mitario> mvo_, still around btw? :)
<Kamion> which isn't in sarge or sid
<Kamion> mdz might remember things I don't
<aj> of the 989 packages updated in ubuntu (ie, ones with "ubuntu" version strings), 613 are older than the version now in sarge, 294 are still newer than the version in unstable
<Kamion> yeah, we stopped automatically syncing newer versions back in June ...
<aj> (older == lower version)
<mvo_> Mitario: I'm about to leave
<mvo_> :)
<aj> know the date off hand?
<Kamion> 28th I think
<Mitario> mvo_, hehe :) have fun!
<aj> so four months
<mdz> 28th June, yes
<mvo_> thanks! bye everyone
<Mitario> byebye
<mdz> most of the ones which are newer are likely actually the same Debian revision, with an ubuntu revision or two attached
<Kamion> aj: might be worth looking at bugs we resolved as NOTWARTY
<mdz> there are very few places where we've taken new upstream versions ahead of Debian, GNOME being the primary one
<aj> hrm, upstream version...
<Kamion> we'll probably have a better idea once we've merged hoary
<Kamion> (re-branch sid, apply warty diffs - or implement it the other way round if that happens to be a pain)
* Mitario can't wait for x.org :)
<fabbione> Mitario: you will have to wait a few weeks
<Mitario> ah, well, still can't wait for it :-)
<Mitario> but it's worth the waiting
<aj> hrm, 165 still have newer upstream than debian; 30 have newer upstream than testing, but not unstable, 2 have been removed from unstable
<fabbione> Mitario: i am afraid you will be disappointed
<Mitario> fabbione, really?
<Mitario> wel, i've heard it's not really stable and such
<Mitario> but we have daniel ;)
<fabbione> Mitario: a lot of people believe X.org is "soooooooooooooooooooooooooooooo" much better than Xfree86
<Mitario> nah, i just like the compmanager + eye-candy :)
<fabbione> the code base is the same
<fabbione> with another name
<fabbione> a bunch of updated drivers
<fabbione> and the "translucency" thing or how they call it
<aj> ugh, two many options, my brain is exploding
<Mitario> only thing I would add to my current graphical environment are the shadows
<fabbione> it's not going to make your computer running any faster or any better
<lamont> Kamion: please push 20041022-04 as rc2
<Kamion> lamont: URL, for the weak of mind?
<lamont> people.ubuntulinux.org/~lamont/testing/LiveCD/20041022-04/warty-live-i386-20041022-04.iso I think
<Kamion> ok
<lamont> and torrents and all that?
<Kamion> lamont: yup. all syncing now.
<lamont> way kewl
<lamont> hrmpf.  still have 300MB of free space on the install dvd... what to add,... what to add.
* amu bruns 22-04 
<amu> lamont: kde *duck* 
<lamont> amu: no.  that way lies terror
<lamont> and pain
<lamont> and insufficient space
<lamont> :-)
<amu> lamont: better idea doom3-demo ;)
<lamont> I don't want to encourage people who get my personal selection thinking about kde..
* lamont doesn't do many first-person-shooter games
<mdz> lamont: only 300M? what did you stuff it with?
<lamont> mdz: all of main and restricted, bunch of games from universe, all of my (maintained) packages, source and binary
<lamont> + theopencd that I brought back from Oxford
<lamont> that source thing kinda fills up the disk faster. :)
<lamont> hoary feature goal: frozen-bubble and kobodeluxe in main!!!
<amu> lamont: kphone,skype :)  
<lamont> the local mirror has: 3945396 /org/ubuntu/tree/pool for a du -s output
<lamont> skype isn't in the archive, and kphone is kde
<lamont> amu: you're just being silly. :-P
<amu> scientists may have right, irc hebetated ;) 
<Kamion> elmo_: meh
<Kamion> elmo_: so, you know I was complaining about dists/warty/Release saying Preview ...
<Kamion> elmo_: guess what I just found in debian-cd
<Kamion> ./CONF.sh:export OFFICIAL="Preview"
<Kamion> d'oh!
<Kamion> let's just retcon and say that warty is a Technology Preview :-)
<Kamion> sabdfl: where was that release checklist thing?
* Kamion sets OFFICIAL back to Alpha
<sabdfl> Kamion: http://wiki.ubuntulinux.org/ReleaseChecklist
<sabdfl> cunningly unlinked-to
<Kamion> aha, perfect
<Kamion>  check the volume labels on ISO's for all architectures
<Kamion> heh, obviously we didn't follow it :)
<sabdfl> youre welcome :-)
<sabdfl> i was writing it as things unfolded, sort of a blow by blow account
<sabdfl> i'm sure there will be more to add the night before hoary ;-)
<sabdfl> 90 days before: find 3 bourkha's
* Kamion fleshes out that comment a bit in case he gets hit by the proverbial bus
<mdz>            Summary: It goes straight over without any "visible" problem...
<mdz>                     but i hate errors mostly at boot/sex time
* mdz scratches his head
<lamont> Kamion: I've tried 25000kg trucks, they're no fun...  but a hell of a ride when they bounce you down the road...
<mdz> I'm not sure if that's a bug report or a complaint of a personal problem
<Kamion> mdz: I did wonder about that
<Kamion> lamont: ouch!
<Kamion> lamont: we should rechristen you "Man of Steel"
<lamont> Kamion: Jan 1996, really quite an interesting experience...
<lamont> looking out the windshield of your full-size Ford Bronco as you spin backwards down the interstate at ~25MPH, at the grill of the Freightliner doing 50MPH.  ISTR he had quite the interesting look on his face...
<lamont> getting dropped off at work by the nice state trooper was kinda fun too
<lamont> although one coworker told me he quit asking "what if LaMont gets hit by a truck" that day...
<mdz> hmm
<mdz> we never did come to a good conclusion on naming for the security advisories
<sabdfl> USN?
* lamont can't think of anything better than USN
<lamont> Kamion: and for the record, d-i doesn't care if a Packages file is 0 length... Just ignores that one.
<lamont> (in the yet-another-non-bug-lamont-thought-he-found-for-a-while category)
<bob2> USA!
<lamont> could do WSA, HSA, GSA, PSA and be release specifc....
<lamont> but that would be silly
<lamont> mdz: how long do we want to leave rc2-live as rc2 before we bless it and throw it out the door?  I'm thinking Sat eve US time at the latest
<mdz> lamont: please send out a call for testing
<mdz> maybe best to follow up to my previous one, and point to the new URL
<lamont> u-d@?
<lamont> your previous one, or mine?
<Mitario> um, wtf?
<Mitario> /usr/include/bits/sigset.h:103: error: two or more data types in declaration of `__sigismember'
<thom> tseng: please send me mail about NetMan,if you would
<mdz> > I've just installed Ubuntu 1.0, and most things have gone well
<mdz> :-)
<maskie> mdz, did not know year 2001 had a month 0 :)
<mdz> hornbeck|away: ping?
<doko_> hmm, I'm unable to find the eps logos. anyone knows where to look?
<Mitario> hmm, lets see wether my gnome-session + upgrade-notification packages work :)
<Mitario> brb
<Mitario> yay! works
<hornbeck> mdz: yes?
<mdz> hornbeck: sent email
<hornbeck> ok
<hornbeck> mdz: I will moderate if you want
<mdz> hornbeck: ok, please reply to the message and let jdub know
<mdz> hornbeck: and thanks
<hornbeck> no prob
<hornbeck> plovs: ping!
<Mitario> anyone knows stuff about the auto cdbs macro's for building a deb?
<Mitario> like debhelper.mk and gnome.mk
<hornbeck> plovs: did you get the mail from mark?
<Mitario> hmm, anyone knows a place where I could host some packages?
* lamont runs off for a little bit
#ubuntu-devel 2004-11-03
<plovs> hornbeck: yes just logged in
<hornbeck> ok, can you send me the copy?
<plovs> hornbeck: of marks mail?
<mjg59> My collection of people to shoot is getting larger.
<hornbeck> nice
<plovs> hornbeck: kind of slowish
<hornbeck> plovs: You are?
<plovs> hornbeck: that plone thingie
<hornbeck> plovs: can you send me the mail though so I can know what to do
<hornbeck> I have not seen it
<plovs> hornbeck: ok
<hornbeck> thanks
<plovs> hornbeck: on its way
<hornbeck> thanks
<mdz> gah, old forum messages flooding the list
<tseng> thom: sure thing
<mdz> mjg59: reading debian-devel again?
<plovs> hornbeck: did you login its a little tricky
<mjg59> Rock.
<mjg59> I can get video back after resume without needing to fuck about with acpi_sleep paramaters now
<tseng> thom: sent
<tseng> thom: actually no its not.. anyone have thoms email handy?
<hornbeck> plovs was not really that tricky
<plovs> are you in the right place *not* www.etc
<tseng> hornbeck: you were correct, i removed mono core from my repo
<tseng> hornbeck: it should be in universe now
<hornbeck> ok
<hornbeck> I will add that part to the beagleinstall page
<tseng> cool
<hornbeck> I get mail all day about that page
<hornbeck> I did not relize that many people wanted to use beagle right now
<tseng> sorry if i caused you trouble
<plovs> hornbeck: it's not even close to as easy as moin, but it looks better
<hornbeck> no trouble at all
<tseng> it should just work
<tseng> from warty
<hornbeck> ok it is updated now
<hornbeck> going to eat
<hornbeck> mdz: is enrico the documentation team leader?
<mdz> hornbeck: I don't think a leader has been appointed yet
<hornbeck> ahhh
<hornbeck> so I can still fight for power
<hornbeck> hahahahahhahahha
<hornbeck> ops
<mdz> you guys are operating on pure adrenaline :-)
<hornbeck> yes we are
<hornbeck> ops should have been opps
<hornbeck> I am off to work on some more stuff
<mdz> opps should be oops :-)
<hornbeck> opps :-)
<jdub> morning boys and girls
<lifeless> what about hermaphrodites? You  sexist you
<jdub> they're boys and girls
* lifeless winces
<Mitario> hehe, lol
<Mitario> hi jdub
<amu> hey jdub 
<tseng> hi
<tseng> jdub: you have an email addy for thom on hand?
<Mitario> anyone knows of a cool rocking python complient build-system? :)
<tseng> Mitario: um.. was that a troll?
<Mitario> not really :)
<Mitario> just a question :)
<Mitario> damn i have to learn to use less smilies
<Mitario> i'm writing a gnome python app here, and I want to have a nice build system
<Mitario> or should I just write it myself
<jdub> tseng: thom@canonical.com
<lifeless> tseng: any old addy for thom? thom@planetarytramp.net should reach him
<lifeless> garh, race conditions
<tseng> i mustve fat fingered canonical
<tseng> since i got it back
<tseng> ah sorry, i typed two N's
<jdub> haw haw
<tseng> there we go.
<hornbeck> thanks jdub, for the list
<lamont> moo
<Mitario> *yawns*
<Mitario> hmm, should go to bed soon
<hornbeck> yep
<Mitario> it's 5:42 AM over here
<hornbeck> nice
<hornbeck> it is 10:43pm here
<Mitario> but i don't wanna, i'm too busy hacking python
<hornbeck> its amazing how people come after you when a doc is wrong in alittle spot
<hornbeck> "why does this not work like you said it would!!!!!"
<tuo2> hornbeck: c'est la vie
<hornbeck> exactly
<hornbeck> well I am off to shower
<bob2> hornbeck: if they even read it, you're ahead of the game ;0
<hornbeck> bob2: very true
<fabbione> morning guys
<mdz> morning
<mdz> fabbione: would it be enough notice if I scheduled the hoary kickoff meeting for monday?
<fabbione> mdz: monday is perfect
<mdz> gerat
<mdz> great
<fabbione> my gf is busy with friends :-)))
<mdz> heh
<fabbione> and i scheduled all X day
<mdz> wouldn't want to get anyone into trouble :-)
<fabbione> so a meeting to break from X is cool
<mdz> working on the X.org merge?
<mdz> or other stuff?
<fabbione> mdz: i already have a bunch of packages with path forwarded from xfree86
<fabbione> s/path/pacthes
<fabbione> i have been working almost 15 hours a day last week
<fabbione> ah i need to send the activity reports :-)
<mdz> it was a long week
<fabbione> yeah
<fabbione> but full of good results
<mdz> perhaps not as long as the preview week
<mdz> but long :-)
<fabbione> mdz: www.fabbione.net/Packages.gz
<fabbione> and i have another lib pending
<fabbione> i plan to finish it this morning
<fabbione> while my gf and her mother are still sleeping
<mdz> what are all those -source- packages?
<fabbione> mdz: X.org -> split
<fabbione> similar to the kernel
<mdz> Package: xorg-source-programs-xplsprinters
<mdz> I mean, what is in that binary package^ ?
<fabbione> it contains a tar of xc/programs/xplsprinters
<fabbione> at the moment it's just a script that creates them
<mdz> this is starting to sound scary :-)
<fabbione> some of them are bogus
<mdz> are you implying that the various source tarballs can't build by themselves?
<fabbione> no i imply that for example xorg-source-lib-xtrans doesn't generate any binary package
<fabbione> but it is required to build other libraries
<fabbione> it is used in a very weird way
<fabbione> but it's needed
<fabbione> even if it doesn't generate binaries directly
<fabbione> libxdmcp and libx11 build-deps on it
<fabbione> if you are curious to see how it builds i can put the stuff up somewhere
<fabbione> but it must be highly hidden
<fabbione> i don't want any of the orig to leak anywhere
<fabbione> until we are not ready for distribution
* fabbione is happy to see that amber did her job
* lamont looks at the topic, gags
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | Happy Warty Day! | 13 (count 'em) major bugs | BE THE SIGNAL | please test http://people.ubuntulinux.org/~lamont/testing/LiveCD/20041021-06/warty-live-i386-20041021-06.iso so it can be warty-rc2-live-i386.iso
<mdz> warty day is officially over. onward to hoary day!
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu development -- general discussion on #ubuntu | Happy Warty Day! | | BE THE SIGNAL | please test http://people.ubuntulinux.org/~lamont/testing/LiveCD/20041021-06/warty-live-i386-20041021-06.iso so it can be warty-rc2-live-i386.iso
<fabbione> we have slightly more than 13 bugs now
<mdz> I deleted the wrong item
* ..[topic/#ubuntu-devel:lamont] : Ubuntu development -- general discussion on #ubuntu | Happy Hoary Trail! | BE THE SIGNAL | Warty release is DONE | please test http://releases.ubuntu.com/warty/warty-rc2-live-i386.iso
<fabbione> ehhehe
* mdz hums "happy trails"
* lamont looks forward to changing that last item again in about 16 hours
<fabbione> mdz: does that Package list looks scary?
* lamont sleeps
<fabbione> night lamont
<lamont> fabbione: night
<fabbione> mdz: with the split we will need to pull in a couple of packages from universe
<fabbione> mdz: at least these are the numbers i have until now
<mdz> fabbione: which ones?
<mdz> fabbione: will it always need to be packaged this way, or will it eventually be split up in a more traditional way?
<mdz> like -dev packages
<fabbione> mdz: rman and another one.. i can't remember
<mdz> rman??
<fabbione> it's required for documentation
<fabbione> mdz: the packaging system IS traditional
<fabbione> check libfs6 for example
<fabbione> source package is xorg-libfs -> libfs6 and libfs-dev
<mdz> fabbione: I am talking about the "-source-" packages
<mdz> which are build-depended on
<fabbione> mdz: they will die slowly
<mdz> and contain source code
<fabbione> mdz: you need to see to understand
<mdz> I am glad :-)
<fabbione> wait a few secs
<mdz> I understand; it is like the apache madness
<mdz> jakarta
<hornbeck> man how do you guys deal with people who just don't get it
<fabbione> mdz: i dunno jakarta
<fabbione> mdz: no no.. this is much better :-)
<mdz> hornbeck: in what context?
<hornbeck> mdz: just venting from getting questions about stuff that I think is just common since
<hornbeck> it will make me a better doc writer
<hornbeck> :-)
<mdz> hornbeck: treat their high expectations as an indication of their confidence in you
<hornbeck> mdz: That is a good way to look at it
<hornbeck> thanks
* hornbeck goes to bed
<hornbeck> good night
<mdz> night
<fabbione> mdz: check in the usual place
<fabbione> :)
<fabbione> basically the concept is that as soon as each X.org components gains independency
<fabbione> it will be killed from xorg_6.8.x
<fabbione> and it will not produce the -source- package
<fabbione> and source will move to the appropriate orig.tar.gz
<fabbione> it's very simple and efficent
<fabbione> since it requires a one time blessing from ftpmasters
<fabbione> the first upload of the -source- will be done once basically
<fabbione> and not touched anymore
<fabbione> this will save a lot of bw
<fabbione> of course.. it will be redone on major upstream releases
<fabbione> but all the patches and small things live in the splitted packages
<fabbione> so an upload is like a very few hunderd kb
<fabbione> it's pure crack
<fabbione> but it's working for me now
<mdz> I guess I am wondering why it makes sense to split up the source packages already when the upstream source is not truly split yet
<fabbione> mdz: preparation
<fabbione> it will save us a lot of time later on
<fabbione> + it is giving us an amazing overview of how the build system interacts
<mdz> how will it save time?
<fabbione> and how stuff build-dep on each other
<fabbione> several points:
<fabbione> each component is already splitted = less time to maintain it
<daniels> the build-dep stuff has been interesting.  i've been working on making x totally bootstrappable (an own-time effort) upstream, which has been interesting.
<fabbione> example: fonts and docx
<fabbione> docs
<daniels> going to set up sbuild, possibly with w-b, to rampage through and see how broken my xlibs b-ds are
<fabbione> i upload them once and i can forget about them
<daniels> they should be pretty good
<mdz> yes, fonts and docs seem fine
<mdz> nothing build-depends on those
<fabbione> instead if i have them in the same source i still need to spend time to check that they didn't break anything
<daniels> mdz: last i saw, there were a couple of font b-ds
* mdz runs away
<daniels> mdz: but they appear to have largely died in the arse now.  mercifully.
<fabbione> mdz: a fix in libfoo bar that doesn't change the API/ABI
<fabbione> i can upload libfoo without having to upload 100MB of updates for everybody
<fabbione> a security fix in the server will not require to upload fonts
<fabbione> see.. there are a lot of good things behind it
<fabbione> daniels: btw.. i got libX11 to compile fine
<Mitario> wow, security updates!
<Mitario> ^^
<mdz> I understand the benefits of having the packages split, but it seems to be costing you a lot of complexity to do it now, rather than later
<fabbione> mdz: not at all and not anymore
<fabbione> mdz: it was difficul to create the first 2/3 packages
<daniels> fabbione: congrats
<mdz> fabbione: ok, I believe you :-)
<fabbione> mdz: now it's almost a copy of a template and that's it
<daniels> fabbione: i'm still beating you though :P
<daniels> unfortunately that system still has a /usr/X11R6
<daniels> s/that/this/
<fabbione> daniels: yes. we have been discussing this problem a lot on irc yesterday and the day before
<fabbione> the issue is where we go and store stuff like include files
<fabbione> there are more issues than benefits doing a rename
<fabbione> mdz: and take into account that i am also forward-porting patches from xfree86 at the same time.
<fabbione> mdz: that is time consuming
<fabbione> mdz: but i already "killed" the server that had tons of them
<mdz> I assume it will be easier to get patches upstream in x.org than xfree86?
<fabbione> mdz: and other big bits here and there
<fabbione> mdz: daniels' problem :P
<fabbione> mdz: for example most of changes to the build system are confined into the DebianMaintainer section of the Imake file
<fabbione> that is safe for upstream to merge
<fabbione> instead of spreading changes all over the place
<fabbione> mdz: i also ported most of the sanity checks from Xfree86 into X.org
<fabbione> like the patch-audit and MANIFEST checks
<fabbione> so that makes the development a bit slower but much much more clean
<daniels> fabbione: thing is, we'll need to do this migration anyway
<daniels> fabbione: there will be no x11r6.9
<fabbione> daniels: yes i understand that.
<fabbione> daniels: i have one big concern at the moment
<cc> hmm, maybe i should ask here... on PPC, where does warty enable sysctl calls for mouse button emulation? i.e. write something sane in /etc/sysctl.conf
<fabbione> is that we are switching tree and reorganizing the layout
<fabbione> daniels: imho it's a bit too much in one shot
<fabbione> daniels: we can plan that for grumpy
<daniels> it's a big shot, but it's going to be just as much pain for two things in two stages
<fabbione> daniels: i have been checking a few things
<fabbione> and killing X11R6 is very very danegerous
<fabbione> specially because X.org doesn't have full control on these directories yet
<fabbione> the only way out is to create transitional packages for a bunch of things like groff, tetex-bin and others
<fabbione> that will decuplicate our work load
<fabbione> dpkg-deb: building package `libx11-6' in `../libx11-6_6.8.1-0+SVN_i386.deb'.
<fabbione> dpkg-deb: building package `libx11-dev' in `../libx11-dev_6.8.1-0+SVN_i386.deb'.
<fabbione> YUMMY
<fabbione> daniels: btw... all my packages are lintian clean too :-)
<fabbione> they all miss one thing only
<fabbione> called copyright file
<fabbione> that will be strictly depends on what we decide for point 6 of the debian clause for Xprint
<fabbione> + fonts
<fabbione> daniels: you can check -r19 commit and following thread
<fabbione> but both Overfiend and I agree in killing Xprint out of X.org, since Drew agreed in maintaing on his own
<fabbione> bbl
<daniels> errr ...
<daniels> roland is using xorg as his main xprint development tree
<daniels> as much as I'd prefer xprint to just crawl into a hole and die in general, apparently x.org is the most up-to-date X tree there is
<daniels> fabbione: btw, last time I checked, the only real significant package using X11R6 was gsfonts-x11
<daniels> fabbione: i think it needs to be done ... by the time hoary is released, upstream will already be into r7, basically
<fabbione> daniels: you miss the point.. one thing is using X11R6..
<fabbione> another thing are all the packages like groff that depends on stuff that stores thing in X11R6
<daniels> those can be reasonably trivially fixed
<fabbione> we build-dep on groff and tetex-bin that pulls in x stuff
<fabbione> daniels: as i said above...
<daniels> we only build-dep on those for documentation building
<fabbione> we need a bunch of transitional packages
<daniels> why?  if we do right we nuke that b-d altogether
<fabbione> daniels: do right what? not building the documentation?
<daniels> so if we have a separate source package that provides docs, right
<daniels> and this is built independently from the radeon driver, or whatever
<daniels> we can pull the transition off nciely
<daniels> this is what modularity's about :) the docs are just another random package
<fabbione> daniels: it is another random package till a certain point
<daniels> (personally I'd just prefer to see them on a website somewhere, but there you go)
<daniels> yeah ...
<fabbione> daniels: we have to ship documentation
<fabbione> daniels: if upstream switches to R7 the problem is "solved"
<fabbione> daniels: they change -> we kill
<daniels> upstream is already changing
<fabbione> right now we have the same name schema and doesn't make it easier
<daniels> unless something goes horribly wrong, april we'll have r7, and it will be all modular
<fabbione> daniels: april is not now
<daniels> yeah ... but if we change, then when upstream changes, it's less pain then
<daniels> yes, but the upstream development is already moving that way
<fabbione> daniels: it's the other way around this time :P
<daniels> and it's already moving to modularity
<daniels> if we keep going like this, we end up in another 4.2/4.3 situation where it's horribly painful to catch up
<fabbione> see this
<daniels> if we get ourselves slightly ahead of the eight-ball now, we don't have to worry so much
<fabbione> now:
<fabbione> upstream: X11R6 us: X11R6
<fabbione> upstream rename to: R7 or whatever
<fabbione> justdave: we kill it
<fabbione> ehm
<fabbione> us ^
<daniels> what's dave got to do with it? :)
<fabbione> completition
<daniels> yeah, I see bthat
<daniels> but we'll be ahead of upstream in this case
<fabbione> right now there is too much collision
<daniels> that means less pain later ... come hoary release time we can just release hoary and that's fine
<fabbione> daniels: i understand that
<daniels> i don't see too much collision at all
<daniels> i just think we have a golden opportunity spending two weeks hacking together, and we can do a lot of stuff in that time
<fabbione> daniels: ok.. we kill X11R6.. where do we store include files?
<daniels> /usr/include/X11
<fabbione> daniels: wrong. See policy
<daniels> all the includes are <X11/Xutil.h>, et al
<daniels> it doesn
<daniels> er
<daniels> it doesn't actually violate policy
<fabbione> yes it does
<daniels> i've been down that road and checked it out
<daniels> thoroughly.  and asked other people.  and been assured it's ok. :)
<fabbione> http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.7
<daniels> yeah
<fabbione> Packages must not provide or install files into the directories /usr/bin/X11/, /usr/include/X11/ or /usr/lib/X11/.
<daniels> iirc i asked mdz this in about june, and he said it was fine for warty
<fabbione> see.. there is a NOT
<fabbione> daniels: that will make our packages not importable into debian for a long while
<fabbione> and i seriously don't want that
<daniels> oh sorry, I was thinking of FHS.  but anyway, it's been cleared with mdz.  we can not worry about it for hoary, and we can get policy changed in debian.
<daniels> ok, hm, reading policy either the authors are on drugs or can't write clearly
<fabbione> daniels: you can ask Kamion 
<daniels> my interpretation -- look at the first paragraph, where it says that packages are encouraged to transition out of /usr/X11R6 -- is that it's ok for base X to use it
<daniels> but not for other stuff to use /usr/include/X11
<fabbione> he was deeply involved in that discussion
<daniels> because everyone uses <X11/Xutil.h> or whatever, so there's not much other
<daniels> way
<daniels> yeah, and also the last train to where I'm going for the weekend leaves soon.  no more trains tonight or tomorrow, so alas I must fly.
<daniels> email me if there's anything else
<daniels> Kamion: comments on the discussion above?
<daniels> seeya
<fabbione> nahh i am going to work on the house today
<fabbione> cya
<fabbione> gotta fix the bathroom
<paulproteus> Psst, is support for NIS or Kerberos planned?  I want to deploy Ubuntu in the JHU ACM computing club, but we need it to work with our central login system.
<bob2> ubuntu includes kerberos and nis support.
<paulproteus> bob2: I can't seem to find it in the documentation.  Where is it talked about, and how would I enable it?
<bob2> it's the same as in Debian.
<paulproteus> Ah, okay.  Maybe I'll install it on a cluster machine tomorrow and just poke at it, then. (-:
<doko> lamont: the live CD does work in safe mode only, in the default mode X cannot find any valid screens, and the OS starts to shut down/restart immediately.
<fabbione> isn't debhelper supposed to install a postinst file if there is none by default and it creates a .postinst.debhelper one?
<doko> it creates the posinst in the DEBIAN dir only, not in debian
<fabbione> doko: the problem is that there is no postinst at the end of the process in the installed package
<doko> dh_installdeb is called for this package?
<fabbione>         dh_installdeb -a
<fabbione> yes
<doko> dh_installdeb -a -v ?
<fabbione> dh_installdeb -a -v
<fabbione>         install -o 0 -g 0 -d debian/libfs6/DEBIAN
<fabbione>         install -o 0 -g 0 -d debian/libfs-dev/DEBIAN
<fabbione> it simply doesn't install them...
<fabbione> well i will have to create a default postinst
<doko> strange, but dh_listpackages -a -v shows the packages?
<fabbione> yes
<fabbione> if i stick a fake postinst it works
<fabbione> no it doesn't
<fabbione> HMMMM
<fabbione> it install the postinst but there is no #DEBHELPER# replacement
<fabbione> this is so weird
<fabbione> #!/bin/sh
<fabbione> #DEBHELPER#
<fabbione> exit 0
<fabbione> i don't see anything wrong in this
<fabbione> the result is a file like that one with no #DEBHELPER#
<fabbione> and nothing inside from the .postinst.debhelper
<fabbione> doko: do you have any idea?
<fabbione> i am in compat 4
<fabbione> but that should only help
<fabbione> 3 is the minimum required to generate the .debhelper for libs
<fabbione> and yes i call dh_makeshlibs and all that nice stuff :-)
<doko> you use postinst, or <package>.postinst? and <package>.postinst.debehelper is created?
<fabbione> i use <package>.postinst
<fabbione> yes <package>.postinst.debehelper is always created
<fabbione> according to doc if i remove <package>.postinst
<fabbione> <package>.postinst.debehelper should be installed automatically 
<fabbione> but it's not
<fabbione> it's like debhelper is fux0red
<fabbione> anyway..
<fabbione> i need to go now
<fabbione> and start to work on the house
<doko> put the package somewhere, although I leave for the Berlinux now.
<fabbione> thanks dude
<fabbione> doko: monday stuff :P
<doko> see you
<Kamion> cc: /etc/sysctl.conf is a conffile, so it's just done at build-time in the package that owns it (procps, I think)
<Kamion> daniels,fabbione: I think it's fine for X to use /usr/include/X11 directly, if that's what turns out to be convenient; that part of policy is there to serve X, not the other way round
<Kamion> daniels,fabbione: however, given the historical fact of the /usr/include/X11 symlink, I feel you might be in for less dpkg-related pain if you just left it as a symlink forever
<cc> Kamion: thanks. i need to perform an installation and take a look at procps then. we didn't know if we should get it in the installer or the kernel, so were looking for ideas :)
<Kamion> well, the installer doesn't have mouse support (yet ...)
<cc> its a case of in the installer, you'll never need mouse support. was wondering how it was done afterward...
<sabdfl> mornin'
<Kamion> cc: oh, we will
<Kamion> but I'll hack that whatever way's most expedient when the time comes ...
<cc> Kamion: oh, cool. i was asking mainly for ideas on how we're going to handle it on fedora/ppc
<Kamion> ifneq (,$(wildcard debian/sysctl.conf.$(DEB_HOST_ARCH)))
<Kamion>         cat debian/sysctl.conf.$(DEB_HOST_ARCH) >> $(CURDIR)/debian/procps/etc/sysctl.conf
<Kamion> endif
<Kamion> and debian/sysctl.conf.powerpc has the obvious fragment
<cenerentola> hello
<cenerentola> sorry but if i "modprobe toshiba_acpi" and it doesnt say anything... what's it trying to tell me?
<paulproteus> Are there plans to support automatically noticing existing NTFS and/or FAT32 partitions and mounting them automatically?
<jc-denton> is "please test" the live cd?
<paulproteus> Yup.
<Kamion> paulproteus: at some point probably yes
<jc-denton> thx
<paulproteus> Kamion: Okay.  I'm thinking of features for my http://wiki.ubuntulinux.org/TeachingUbuntu mini-course.
<paulproteus> Okay, off to bed for me now.
<plovs> anybody in the plone wiki?
<bob2> plovs: what do you mean?
<plovs> i am playing around with the wiki on the plone site, some other devs probably are as well, i have some questions
<plovs> hornbeck, awake?
<fabbione> sabdfl: morning :-)
<sabdfl> hey fabbione
<fabbione> Kamion: yes, i understand that really.. but i don't feel like it's a good idea to do it right now
<plovs> sabdfl, does lu do irc?
<sabdfl> plovs: yes, lulu
<plovs> sabdfl, is she the best person to bug about zwiki?
<mjg59> Hmm. Little progress with the craptop.
<fabbione> doko: that problem seems to be strictly related to X. Branden did a workaround in Xfree86 too.
<fabbione> doko: so clearly it is either debhelper that is broken or joeyh/branden decided that way. i will have to dig into it
<mjg59> I'm confused. It points the wakeup vector at the wakeup code, but never actually executes any of it
<nasdaq4088> sorry, but I was wondering what type of internet connection you guys have? at what speed do you download the ubuntu cd? how many kb/s ?
<amu> nasdaq4088: 100Mbit; downloadspeed 3MB/sec. download takes, 2,30 min. ; @home 3Mbit, 350kb/sec download takes 30-45min.  
<nasdaq4088> phew!
<nasdaq4088> you must be working for british telecom
<amu> nope :)   
<Keybuk> 350Kbpss is suspiciously 2500Mebps ... <g>
<Keybuk> gah
* Keybuk mops the coffee out of his keyboard
<amu> Keybuk: hehe 
<fabbione> YESSS!!
<fabbione> finally
<nasdaq4088> amu: that means it takes 1sec to download an mp3
<fabbione> ok.. now i need to focus on the house
<fabbione> later guys!
<amu> nasdaq4088: downloading ? no way it waste diskspace, i listen "online" 
<fabbione> have a nice weekend!
<amu> fabbione: greetings to GF ;) 
<nasdaq4088> bye fabbione
<nasdaq4088> you mean you download wow amu that is awesome
<mjg59> Keybuk: I'm tracking down some of the things that the ACPI problem /isn't/
<jdub> acpi=force fixes pipka's toshiba kernel problem (making it inordinately slow)
<mjg59> jdub: Yeah. We're going to have to work through more of that stuff.
<mjg59> On the bright side, I now have working ACPI on the X40 without having to use any kernel arguments
<Keybuk> mjg59: *nods*, it feels like the hardware wakes up but the software doesn't
<jdub> mjg59: is any of that b0rkness usefully detectable?
<mjg59> jdub: Not very, at the moment
<mjg59> Keybuk: I think it's probably much the same problem that I have here - the hardware doesn't start executing the code that's supposed to be sitting at the wakeup vector
<mjg59> I have one idea left, but it's going to be a bitch to implement
<Keybuk> is there any particular reason it wouldn't?
<mjg59> Keybuk: Well, three main possibilities:
<mjg59> 1) The suspend sequence hasn't set the hardware up properly
<mjg59> 2) The hardware loses the wakeup vector
<mjg59> 3) The hardware overwrites the memory that the wakeup code is in
<mjg59> Currently, Linux tends to put the wakeup code in the first few K of physical RAM
<mjg59> I'd prefer it to be a few hundred further up
<Keybuk> yeah, I tried back at Debconf to persuade bdale to get me a dialogue with the guy at HP who actually wrote the ACPI support in the thing to see whether he could help -- but didn't have any joy.  Is odd, because the ACPI support of the laptop is otherwise flawless.
<mjg59> I'm in touch with someone at Intel at the moment
<mjg59> We're working through the obvious stuff
<mjg59> I've got a handy board with LEDs on that plugs into the parallel port, which makes life easier
<Keybuk> heh, not got one of them
<mjg59> A parallel port?
<mjg59> Or a board?
<mjg59> It's kind of cool - there's no way to attach a POST card to laptops, so they do their POST numbers over the parallel port
<mjg59> It flashes all over the place whenever you reboot
<Keybuk> either :p
<play> #linux
<play> sorry :)
<play> i'm testing IRC :)
<play> bye
<hornbeck> plovs: ping!
<plovs> hornbeck, pong!
<hornbeck> plovs: whats up
<plovs> hornbeck, reading up on Quick reStructuredText 
<hornbeck> cool, I planed on doing that today also
<hornbeck> planned
<plovs> hornbeck, more difficult then moin but more powerfull as well
<plovs> hornbeck, looking forward to use it
<hornbeck> plovs: I can't wait
<plovs> hornbeck, it is not really a wiki though, it is a cms with a wiki plugin, but who cars :)
<hornbeck> plovs: I have not even got to really look through it, but from what I saw I liked
<plovs> hornbeck, read: http://docutils.sourceforge.net/docs/user/rst/quickref.html
<hornbeck> nice
<Keybuk> I wish python on rockery wouldn't keep segfaulting
<plovs> hornbeck, adding pages is simple, folders as well, pictures i do not yet get (look in howtos how i don't get it)
<plovs> hornbeck, if you find out how to make a home-page let me know
<hornbeck> plovs: Are you going to start reformatting pages from the wiki to put over on the new site, next week
<hornbeck> I did not understand that part of the emails
* mjg59 hacks the memory allocation to raise the wakeup address
<Keybuk> (though I suspect this is really a result of shutil.rmtree being on total crack and eating GB of memory to work out what to remove, *sigh* )
<hornbeck> plovs: brb getting food
<plovs> hornbeck, i don't know will this playground be the real wiki, next week? then we can move some stuff lthough all the moin stuff will be incorperated automatically
<hornbeck> plovs: It will be incorperated automatically?
<plovs> hornbeck, yes
<hornbeck> plovs: That is great
<hornbeck> plovs: I was not sure if we where going to have to redo it all :-)
<sabdfl> hornbeck, plovs: hi guys
<hornbeck> sabdfl: hello
<sabdfl> shouldn't have to redo anything
<sabdfl> maybe work on structure a little bit
<hornbeck> that will be great
<sabdfl> the new wiki has more organisational features
<sabdfl> just Moin tables are a problem
<hornbeck> it should be no problem just working on formatting it
<sabdfl> are the two of you the ones playing in that area on the site at the moment?
<jdub> sabdfl: can we standardise on a certain format?
<plovs> sabdfl, it looks really nice, after you get the hang of it
<sabdfl> jdub: will make a strong recommendation
<sabdfl> plovs: sure does :-)
<jdub> sabdfl: i'm going to cry if we have ReST, moin, html, etc... ;)
<sabdfl> jdub: i *think* we will recommend (a) ReST, (b) html
<hornbeck> jdub: so would I
<plovs> jdub, i vote for ReST it rules, no html, the site will look a mess
<sabdfl> we can probably automatically convert moin to ReST
<plovs> can we export rest to docbook?
<hornbeck> Rest is looking good
<sabdfl> plovs: some things you can only do in html
<sabdfl> and I *think* you can embed html in ReST
<jdub> can you-- ah
<sabdfl> <div class="portalMessage"> is fun
<hornbeck> html, is always needed alittle in webpages
<sabdfl> see the home page for the banner i put on there this morning
<plovs> sabdfl, where is documentation for this stuff? <div class="portalMessage">
<sabdfl> plovs: plone
<sabdfl> i think we should be *very* strict with html embedded
<sabdfl> as plovs says, it can become a mess
* plovs must read plone
<plovs> can you make an admin group with the 'rights' to do html the rest uses ReST?
<Keybuk> "After reading about Ubuntu I have decided to include it into DesktopOS.com as one of the Linux Operating Systems we follow.
<Keybuk> The review by JL helped, and some other news I read.
<Keybuk> This is the first GNOME distro on DesktopOS.com"
<Keybuk> heh
<jdub> haha
<jdub> rawk
<mjg59> I see oGo is back in #gnome-hackers, too
<jdub> mjg59: turned up the other day
<Keybuk> mjg59: register backme.org ? :)
<jdub> must've been inspired by the nokia work
<jdub> he's already imported atlantis
<mjg59> Yeah, he seems keen on webcore
<sabdfl> Keybuk: naaaaiiice
<plovs> hornbeck, i have to go, i'll be back tonight
<hornbeck> plovs: I am leaving for work in a sec also
<hornbeck> talk later
<plovs> hornbeck, see ya!
<hornbeck> bye
<mjg59> Arse. Right, that makes no difference
<Keybuk> no difference to?
<srbaker> okay, i'm trying an ubuntu install again on my lapto
<srbaker> p
<srbaker> it'd better work this time!
<srbaker> where is the ubuntu porn?
<Keybuk> elmo's getting oiled up as we speak
<jdub> srbaker: apt-get install ubuntu-calendar
* jdub goes for dinner
<Keybuk> jdub: s/apt-get/aptitude/
<jdub> Keybuk: i don't do aptitude yet
<mjg59> Keybuk: Resume
<Keybuk> aptitude will install recommends as well, and does dep tracking
<Keybuk> mjg59: doesn't it work for you already?
<mjg59> Putting the waking vector at 256K rather than 4K
<mjg59> Not on the craptop
<Keybuk> or did you just break it completely? :p
<Keybuk> craptop?
<mjg59> The C3 PoS
<Keybuk> ah, heh
<Keybuk> may I test?
<mjg59> I've got one more thing to try here, then I'd be interested if you could test my test kernel
<mjg59> It'll probably make no difference, but...
<Keybuk> okies
<srbaker> does that install the porno login screen?
<Keybuk> that login screen is available, just select the HumanCircle theme
<__daniel> hai
<srbaker> ahh
<srbaker> it should be the default.
<srbaker> hopefully ubuntu doesn't break on my lappy this tiem
<Keybuk> for various reasons the community felt it shouldn't be the default
<srbaker> well the community was wrong.
<srbaker> :)
<mjg59> Keybuk: http://www.codon.org.uk/~mjg59/tmp/acpikernel
<sabdfl> glad to see the :-) in there
<srbaker> mjg59, what's that kernel for?  i'm having acpi trouble with my lappy
<sabdfl> mjg59: looks crap in a browser, wheres the penguin?
<sabdfl> ;-)
<mjg59> srbaker: Attempts to deal with complete failure to resume
<Keybuk> sabdfl: apt-get install uml ... that should associate application/x-linux-kernel and boot with it
<Keybuk> ps. I'm kidding ... I hope
<srbaker> mjg59, ahh.  the problem i'm having is i have to do acpi=force
<srbaker> has anyone else heard of gnome starting, but the splash screen not showing? 
<srbaker> it seems that gnome-session was hanging on me
<mjg59> srbaker: acpi=force depends on the date of your BIOS
<srbaker> mjg59, right.  my bios is pre-1999
<srbaker> it's a toshiba lappy that i hate
<mjg59> The safe thing to do is use apm instead
<srbaker> mjg59, but if acpi is off, I/O slows down so badly that it takes about 3 minutes to boot
<srbaker> and usability is basically nill
<srbaker> nil even
<srbaker> i said: toshiba lappy.  that means "suck"
<mjg59> That's likely to be indicative of something else that's wrong
<Keybuk> mjg59: nope, unsurprisingly that didn't help
<srbaker> mjg59, figured.  but acpi=force fixes it
<srbaker> mjg59, what woudl you suggest looking at ?
<lamont> doko: hardware specks for the liveCD-X-issue machine?
<srbaker> oh, and i tried to boot warty RC2 live cd on an HP Digital Entertainment Center, and it wouldn't because the DEC sucks balls.
<srbaker> and i almost got myself writ up for it, too.
<mjg59> srbaker: Not sure
<mjg59> Probably interrupt related
<Keybuk> if it's a Tosh, defenestration seems a good plan <g>
<mjg59> Keybuk: Yeah, thought not. Same behaviour as before?
<Keybuk> mjg59: yup
<srbaker> mjg59, oh, i notice that it sometimes disables irq 11
<srbaker> Keybuk, defenestration?
<mjg59> Heh. Well, I'm running out of ideas.
<mjg59> srbaker: Throw through a window. Opening the window is optional.
<Keybuk> mjg59: it printed some stuff on sleep about addresses, I guess that was your debugging?
<srbaker> mjg59, well, perhaps when i get a new lappy.  right now, this Toshiba is all i can afford
<srbaker> and that's mostly because it was almost free.
<srbaker> i have kids and their welfare bum mother to support.
<mjg59> Keybuk: Yeah
<srbaker> anyways.  the install process goes well.
<mjg59> The second and third should be the same
<srbaker> it's starting gnome that gave me problems
<Keybuk> they were
<mjg59> Cool
<mjg59> So the contents of the wakeup vector are set and still correct immediately before suspend
<srbaker> what did you guys use to build the arty live cd?  i need to build debian-based live cds, are there good tools available?
<Keybuk> srbaker: morphix
<Keybuk> mjg59: heh, that sounds sane :)
<lamont> morning
<lamont> srbaker: writing the 'what we did for a livecd' page on the wiki is on my todo list for next week
<Keybuk> there's a few notable things I've noticed
<Keybuk> 1) the screen remains "off", not just black
<srbaker> lamont, thank you
<Keybuk> 2) after a short while not resuming, the fans increase in power as it gets warm (even with a kernel with no fan control, so this is hardware doing it I guess)
<Keybuk> 3) the caps lock key works with acpi_sleep=s3_mode, but nothing else
<srbaker> lamont, i have a medium-sized contract to put my kiosk software on my livecd
<srbaker> erm, a livecd.
<srbaker> that's actually how i got the toshiba lappy.
<lamont> ah/
<mjg59> Keybuk: ?
<lamont> note that the liveCD should work on a subset of the hardware that the install CD does (different hw detection missese some stuff - will be merged in hoary
<mjg59> If you pass acpi_sleep=s3_mode, you get working caps lock?
<Keybuk> well, the key turns the light on and off
<mjg59> That's interesting
<mjg59> Because that's under software control
<Keybuk> isn't it under hardware control for a small period?
<mjg59> BIOS control
<amu> hey lamont 
<mjg59> That's weird. And only under acpi_sleep=s3_mode ?
<Keybuk> well, I've noticed it twice, the second was under s3_mode
<Keybuk> and I've tried it under other times, and it didn't help
* Keybuk shall try now, hold on
<mjg59> Hmm. Very strange.
<sabdfl> Keybuk: nice idea
<srbaker> lamont, my current kiosk software installs to harddrive using mondo. :P
<sabdfl> is there a uml firefox plugin?
<srbaker> lamont, the hardware for the kiosks are all identical.  hw detection isn't important
<sabdfl> <duck>
<mjg59> The only thing the acpi_sleep things do is twiddle what the kernel does to the video hardware
<Keybuk> sabdfl: ask mdz, it's one of his fetishes
<Keybuk> mjg59: that's what I thought
<Keybuk> it's a radeon, so it's known fucking iritating
<lamont> srbaker: bootcd might do the trick for a fixed config...
<lamont> although I've never used that
* lamont wanders off to meet the day, bbl
<mjg59> Keybuk: In general, using vgacon makes life massively easier
<Keybuk> I understood the new thought on this was to vgapost in the radeon init sequence and use radeonfb
<srbaker> lamont, well, fixed config is the "main" usage, but i want it to be demonstrable on random hw
<Keybuk> mjg59: nope, can't replicate that now
<mjg59> Keybuk: Weird
<sid77> hi, all :)
<mjg59> Keybuk: Yeah, you /can/ do it that way. But that's not a very generic solution.
<amu> srbaker: easy way, cdbackup + installed discover. 
<Keybuk> does the video init happen before or after where you put the beeping ?
<mjg59> Getting this working with vesafb is going to be a real nightmare
<mjg59> Keybuk: After
<mjg59> But I've taken the beeping out now
<Keybuk> ok, was wondering whether that was hard-crashing it or something
<Keybuk> if I suspend with caps lock on, the light doesn't light up again on wake-up
<srbaker> geh.  time to job hunt today.
<srbaker> ttyl
<mjg59> Hmm. vesafb-ng might be a better bet.
<Keybuk> and suspended with all fans on, and non of them spin up on wakeup
<ctalkep> hi there?
<ctalkep> any chance that daf is here?
<carlos> ctalkep: perhaps later
<ctalkep> carlos, thanks. can't find him for so l ong:)
<carlos> but I'm not sure if he will enter into this channel
<carlos> hmm, he's here
<carlos> :-P
<carlos> but away
<ctalkep> well
<carlos> so as soon as he wakes up...
<ctalkep> sleepy guy:)
<ctalkep> wanted to get info on translation contribution
<ctalkep> if anyne here can help, i won't stalk him so hard:)
<carlos> ctalkep: which kind of info do you need?
<ctalkep> as basic as possible, i wanted to start the bulgarian translation, and need to know where do i start
<__daniel> carlos, ctalkep: good starting point would be the debian bulgarian l10n status, wouldnt it?
<carlos> __daniel: yes
<carlos> ctalkep: We don't have (yet) ready the translation tools to handle translations directly
<__daniel> ctalkep, bg is the code for bulgaria?
<ctalkep> yep
<carlos> but as __daniel suggest, you could start now contributing to Debian, GNOME and other projects directly because we will get also those translations back
<__daniel> http://www.debian.org/international/l10n/po/bg_BG
<ctalkep> oh, did not know that
<carlos> ctalkep: as soon as we have our l10n infrastructure in place we will announce it in our mailing list and website
<ctalkep> oh, this info is pretty enough for me
<ctalkep> so i'll just start with the debian then
<__daniel> ctalkep, cool you'd like to contribute! :-)
<ctalkep> yes:)
<ctalkep> btw
<ctalkep> i manage several sites and i would like to put on some banners etc. where do i get, like, website ki?
<ctalkep> i mean website kit
<__daniel> bye everyone
<ctalkep> bye
<srbaker> okay, this is *fucked* up
<srbaker> i logged into my ubuntu laptop for the first time 15 minutes ago
<srbaker> it *just* loaded the trash can and workspace switcher
<srbaker> something's not right
<srbaker> when i click the computer menu, it takes about 30 seconds for it to show up
<srbaker> anyone else having these problems?
<sid77> afaik ubuntu desktop isn't so rich of icon, isn't it right to just load the trash and the switcher?
<sid77> (in the lower menu)
<Keybuk> srbaker: try booting with noapic and pci=noacpi
<mjg59> srbaker: It would help if you could check whether this is happening with all processes
<srbaker> mjg59, yeah, after rebooting, it appears that everything is slowed down
<srbaker> Keybuk, i have acpi=force on
<srbaker> just a second
<Keybuk> srbaker: that's nice ... that's not what I asked :o)
<Keybuk> noapic  turns off APIC support, APIC != ACPI
<Keybuk> pci=noacpi  turns off ACPI for IRQ routeing ... on a laptop as old as yours, that might be bust
<mjg59> 2.6.9 has the useful feature that it doesn't enable the APIC if the BIOS disabled it
<mjg59> Which is the sane behaviour
<Keybuk> heh, Linux in "ignoring BIOS" shocker
<mjg59> <2.6.9 will force enable the APIC by default. Which is, uh, stupid.
<Keybuk> though strangely my desktop's APIC isn't disabled by BIOS and needs noapic
<Keybuk> whereas my laptop's is disabled by BIOS, but enabling it isn't harmful
<kylem> have there been any reports of lockups during the postinstall run of apt?
<Keybuk> kylem: you sure it's locking up, and not just thinking?
<srbaker> okay, i lied.  the rest of the system was fine, the gnome was busted
<kylem> Keybuk, numlock no longer works.
<srbaker> with noapic and pci=noacpi, the whole system slows down
<kylem> it seems to die at "Preconfiguring" just after "Extracting templates" but before making any package-specific output.
<srbaker> Keybuk, still no change.
<srbaker> Keybuk, i tried with noapic and nolapic, ntohing better.
<srbaker> Keybuk, sarge seems to work fine, if i use acpi=force and nothing else
<sabdfl> hornbeck, plovs: we're updated the wiki software
<sabdfl> also, removed the ability to add non-wiki pages to /wiki/
<sabdfl> and i'm moving some of the non-wiki stuff that was in /wiki/ to /support/documentation/
<srbaker> okay, this is going to have to wait
<sid77> bye averyone
<robertj> hey all. Is there a problem with SDL's configuration? Battle for Wesnoth does not give sound unless you elevate your permissions
<robertj> a sudo true && wesnoth is enough to get the job done
<tseng> search/file @ bugzilla for that
<plovs> sabdfl, are you updating or did you finish it and where did my pages go? (i don't care i was just playing,but they're gone)
<sabdfl> plovs: not gone
<sabdfl> i wrote ^^^ that i was moving them
<sabdfl> we only want wiki pages in the /wiki/ directory, thanks for finding that bug :-)
<sabdfl> so we've fixed it now you can only create wiki pages in there
<sabdfl> and i've moved your folders to /support/ and /support/documentation/
<plovs> sabdfl, ok
<sabdfl> plovs: please take care with what you write on the site, it can get published immediately
<sabdfl> did you have a cold?
<sabdfl> "Workig with video on your Ububtu Desktop" >:-)
<plovs> sabdfl, yes, this is eastern europe it's already cold here :)
<sabdfl> ;-)
<sabdfl> this is london it's always wet here
<plovs> sabdfl, where should we work, in support or in wiki, or both?
<sabdfl> plovs: i think it's best to develop new stuff in the wiki
<sabdfl> because every member can edit content there
<sabdfl> more open
<sabdfl> then when the content is stable, move it into the doc area
<plovs> sabdfl, ok, can we have a toplink to the wiki then?
<sabdfl> toplink?
<plovs> sabdfl, at the top of the page it says: ubuntu community support planet <EMPTY>
<plovs> sabdfl, <EMPTY> could be wiki
<sabdfl> which page?
<sabdfl> plovs: ^?
<plovs> on:site-edit press:home, now i can't get to the wiki
<sabdfl> plovs: yes, i took it out of the "published" state
<sabdfl> until monday when we have moved the content across successfully
<sabdfl> you can still get there with site-edit.../wiki/
<plovs> sabdfl, sure, thanks
<sabdfl> enjoy
<plovs> sabdfl, one last bug, there is edit, preview but no cancel???
<plovs> sabdfl, on the wiki that is
<sabdfl> plovs: hmmm.... i don't think it saves it if you don't click save
<sabdfl> but you're right, there should be a cancel button
<plovs> sabdfl, where do i send these kind of questions ubuntu-devel ubuntu-doc, irc?
<plovs> sabdfl, hmmm and I can no longer create folders in wiki, but i can in support?
<sabdfl> plovs: hmm... not sure what the situation is with the wiki and folders
<plovs> sabdfl, i have add page but not like i used to have add folder, etc. I made a page private, then I could no longer access it ???
<plovs> sabdfl, permissions seem messed up
<sabdfl> plovs: this is all new, we'll have to work out the permissions
<sabdfl> first, which page, i'll restore it
<plovs> in the root of the wiki, called page.2004 i hadn't named it, i tried not saving as a way to cancel...doesn't work :) anyway i go have dinner
<sabdfl> plovs: can't see it, i think it was never saved
<mdz> sabdfl: the plone wiki doesn't seem to support the hierarchical moin structure properly
<mdz> I can't seem to link to the parent of a page, or another page relative to it
<mdz> it just reverts my change
<sabdfl> mdz: https://site-edit.ubuntulinux.org/wiki/NewWikiAnnouncement/
<sabdfl> we have a limited number of options
<sabdfl> for the moment i think it best just to shorten and rename
<sabdfl> WartyWarthog/ReleaseSchedule -> WartyReleaseSchedule
<__daniel> re
<sabdfl> good news though, we got moin table support unexpectedly soon
<mdz> I'd gladly give up tables for hierarchies
<sabdfl> we can sort of get them
<sabdfl> we can add new wikis inside old ones possibly
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | Happy Hoary Trail! | BE THE SIGNAL | Warty release is DONE | Hoary kickoff meeting Monday, 2004-10-25 1600UTC
<sabdfl> but the namespaces are then b0rked
<sabdfl> so, inside a subsidiary wiki you would not be able to refer to pages in the parent folder
<sabdfl> mdz: maybe we can use interwiki links for the hierarchies
<sabdfl> but it would mean that every link in a subsidiary directory to a page in the top dir would need to be like MainWiki:PageName
<sabdfl> unless we did some funky acquisition voodoo
<sabdfl> also, this new wiki has the concept of wiki structure separate from namespace
<sabdfl> try clicking on "wiki contents"
<sabdfl> you can reparent a page by going to the page, putting the new parent page name in the field at the bottom and selecting "reparent"
<mdz> sabdfl: sounds scary
<sabdfl> mdz: not really
<mdz> sabdfl: where is the documentation for ReStructuredText?
<sabdfl> try it
<mdz> ah, I see it
<sabdfl> links are a little funky
<plovs> sabdfl, what about folders?
<sabdfl> plovs: no go for the moment
<mdz> it uses all of the same markup as moinmoin, but with _entirely different meanings_ :-)
<sabdfl> stevea is workiing on a python script to suck 'n blow :-)
<sabdfl> mdz: but of course
<sabdfl> so we may have the stuff automatically transferred
<sabdfl> how deep are the hardware folders?
<mdz> just 2 levels, I think
<sabdfl> need to flatten the namespace graciously
<sabdfl> mdz: the reparenting thing is entirely independent of content
<plovs> sabdfl, could i get the python script from stevea, when he is ready?
<mdz> sabdfl: yeah, it's just that someone just spent a lot of volunteer time to break it down and make a hierarchy out of it :-/
<sabdfl> mdz: not really anything we can do about it, except break the wiki spec in a different way to moin's
<sabdfl> plovs: to run it? it will only need to be run once
<plovs> sabdfl, i would like to make a script to export stuff from to wiki to docbook, i could use his code as foundation
<sabdfl> plovs ok ping him directly
<sabdfl> but i don't think he will be parsing the content, except for the namespace issue
<sabdfl> mainly it will just be "fetch from here, post to there"
<plovs> sabdfl, ok
<mdz> sabdfl: how should we go about publishing USNs on the website?  Should we use the Errata facility?
<sabdfl> mdz: yes, let's create a dedicated folder for them, which we can also publish as rss
<mdz> sabdfl: how do I do that?
<sabdfl> no idea :-)
<mdz> I see how to create errata, but not a new folder
<sabdfl> https://site-edit.ubuntulinux.org/search_rss?sort_on=modified&sort_order=descending&path=/ubuntu/support/documentation&portal_type=HelpCenterFAQFolder&portal_type=HelpCenterHowToFolder&portal_type=HelpCenterTutorialFolder&portal_type=HelpCenterLinkFolder&portal_type=HelpCenterErrorReferenceFolder&portal_type=HelpCenterGlossary
<sabdfl> fiddle with that to do the rss
<sabdfl> where do you want the folder?
<mdz> dunno. support?
<mdz> or maybe even at top level
<sabdfl> hmm... security feels like it deserves its own top level folder, but that way lies madness
<sabdfl> stop DOING that! :-)
<mdz> many projects have security as a top-level item because it's important to be able to find it quickly
<mdz> though, it's under a 'support' heading
<sabdfl> ok, let's create it in support
<mdz> e.g., www.debian.org and www.freebsd.org both have a hyperlink from the top level, but it's nested under 'support'
<mdz> redhat has a shortcut from the top
<plovs> sabdfl, 1) do we have homepages 2) pages are signed with a number not a name
<mdz> sabdfl: I think we've found The Wart, by the way
<sabdfl> plovs: (1) maybe, (2) bug :-)
<mdz> a patch was inadvertently dropped in the last kernel rev
<sabdfl> i'd like the answer to be (1) yes and (2) fixed, will know this week
<mdz> a trivial one which fixed a bunch of apic/IRQ/etc. problems
<sabdfl> plovs: ping lulu monday?
<sabdfl> mdz: The Wart?
<sabdfl> kernel?
<mdz> sabdfl: the one that would make me wish I could go back in time and fix it
<plovs> sabdfl, ok
<sabdfl> so let's fix it for the cd's
<mdz> eek
<mdz> I think it's madness at this point to change what "Ubuntu 4.10" means
<sabdfl> wait a week, it can be 4.11 
* sabdfl ducks
* mdz digs around for his "sabdfl says no point releases" quote
<sabdfl> out of curiousity what's the bug, what's the fix, where did we introduce it?
<sabdfl> no point releases, but there's no point in printing the cd's with a known fixable Wart
<sabdfl> we'll find a way
<sabdfl> is the install cd maxed out in size?
<mdz> sabdfl: we were building the kernel with a particular option enabled
<mdz> which was flaky
<sabdfl> which one?
<mdz> CONFIG_PCI_MSI
<mdz> it is =y and should be =n
<sabdfl> doh
<sabdfl> is the install cd full?
<mdz> it was disabled in 2.6.8.1-9, with good results
<mdz> and apparently it was inadvertently re-enabled in -16
<mdz> the install cd is not full
<sabdfl> bad day down under?
<mdz> dunno
<sabdfl> i'm thinking one way out would be to put the updated kernel package on the install cd in a separate dir
<sabdfl> but i guess there's no hook to find and install it other tha an erratum sheet
<sabdfl> and that would be a usability mess
<mdz> better to put it in warty-updates, in my opinion
<plovs> sabdfl, my last wiki-question, then i'll leave it for monday but quick restructured text doesn't work on my side?
<sabdfl> doesn't work how?
<sabdfl> mdz: your call, but i'm not at all averse to rev'ing the shipit cd with warty-updates content
<plovs> sabdfl, look at: https://site-edit.ubuntulinux.org/wiki/EditingWikiPages
<mdz> sabdfl: https://bugzilla.ubuntu.com/show_bug.cgi?id=2662
<mdz> has some details
<sabdfl> plovs: check the format list at the bottom of the page
<sabdfl> you have selected StructuredText
<sabdfl> which is not the same as ReStructured Text
<mdz> sabdfl: herbert proposed sneaking it into a security update, but I consider that evil in the extreme
* sabdfl blinks and stares
<sabdfl> so we have warty-updates and warty-security?
<sabdfl> which appears in the sources.list file?
<mdz> warty-security is in sources.list by default, warty-updates is not
<mdz> changing behaviour in a security update would be a serious breach of trust, especially this early
<sabdfl> warty-updates makes sense to me for a more long-lived release
<sabdfl> or, a release of a sort that will have rare releases
<sabdfl> like if we did an "enterprise grade"
<sabdfl> but, the flip side is that maybe this is the basis of that effort
<sabdfl> the -updates archive becomes the place where warty matures to become warty-enterprise
<mdz> right
<sabdfl> there's no rule that says that the CD we ship has to be exactly the same as the download
<sabdfl> our options w.r.t. the cd and iso are as follows:
<sabdfl> do nothing, continue to ship iso and cd as they were on 20/10
<sabdfl> ship the cd with a fixed kernel
<sabdfl> update both
<cenerentola> does anybody here know what fnfx are?
<sabdfl> is it very importnt that the through-the-mail cd be the same as the download one?
<mdz> sabdfl: I feel that it is, yes
<sabdfl> mdz: ok, the errata content type is special
<plovs> sabdfl, i should leave it for monday but search as i may i don not see format at the bottom of any of my pages not edit, not contents, not view, monday->lulu?
<mdz> we cause a lot of confusion if we don't have a single blob that we call Warty
<sabdfl> plovs: edit the page
<sabdfl> at the bottom, near the save button, are some radio buttons
<sabdfl> with the format
<mdz> of course we could do point releases :-)
<sabdfl> you currently have it on structured text
<sabdfl> so, about errata, it at the moment only shows up inside the help center errata thing
<sabdfl> which is support/documentation/errata
<mdz> well, we should have a page for security info
<mdz> which would link to errata
<plovs> sabdfl, sorry no buttons here, you are probably admin or something
<sabdfl>   mdz: yes
<plovs> sabdfl, i'll log out and back in
<sabdfl> do you want to be able to categories the USNs?
<mdz> sabdfl: not really
<mdz> just enumerate them
<mdz> sabdfl: should we have one group of errata for security, and another for warty-updates stuff?
<sabdfl> mdz: yes, that sounds good
<sabdfl> and just one stream for all releases
<mdz> ok, let me know when there is a place for me to put the USNs
<mdz> sabdfl: we should have a feed which has only security
<plovs> sabdfl, no, no buttons under edit, next to save, only a void, emptyness
<mdz> I hope plone lets us do that
<sabdfl> plovs: weird
<plovs> sabdfl, something with permissions probably, you want my login?
<sabdfl> mdz: shiny
<sabdfl> plovs: could be
<sabdfl> mdz: what's the first USN number?
<sabdfl> or a url?
<mdz> sabdfl: I was creating it just now, should I not?
<mdz> the first is USN-1-1
<sabdfl> mdz: creating it in the documentation/usn folder?
<mdz> sabdfl: correct
<sabdfl> you're too fast :-)
<sabdfl> go ahead
<sabdfl> shiny that it asks you the product versions
<sabdfl> regarding the streams: yes, one for security, one for updates
<sabdfl> each stream covers all releases
<mdz> sabdfl: the 'upload a file' bit for the body doesn't seem to work
<mdz> I end up with an empty body
<mdz> (sounds uncomfortable)
<sabdfl> as opposed to an empty mind
<sabdfl> how on earth you survive in LA i don't know
<sabdfl> maybe i'm just always there with the wrong crowd
<plovs> sabdfl, in /support/ it all works... including quick restructured text, but /wiki/ is broken
<sabdfl> hey! next time i go i can have a pony tail too!
<mdz> sabdfl: entirely possible
<sabdfl> plovs: ok, please work with bradb and lulu on monday
<mdz> there are many social strata, and most of them are unsavory
* sabdfl feels all warm as a result
<mdz> I find that's true of most places anyway
<sabdfl> you don't have to look very far
<sabdfl> but LA has something extra in that regard
<sabdfl> shiver
<plovs> sabdfl, ok
<sabdfl> plovs: sorry i can't solve the problem, just don't know plone that well
<sabdfl> if at all
<plovs> sabdfl, that makes two, then ;)
<mdz> published usn-1-1 and usn-2-1
<sabdfl> plovs: would you like me to fix that specific page for you?
<__daniel> is there an announcement on warty-security?
<amu> 2 :)
<mdz> __daniel: the mailing list is ubuntu-security-announce, and they were sent ~12 hours ago
<sabdfl> mdz: somehow usn1 is in usn2
<mdz> i'm just putting them on the website now
<mdz> sabdfl: yeah, cut and paste error, already fixed
<mdz> sabdfl: you're too fast :-)
<__daniel> mdz, ok, thanks
<sabdfl> just tryin' to keep up
<plovs> sabdfl, maybe clean up the mess of empty pages, leave only good content, i'll work in support until monday
<plovs> sabdfl, thanks 
<sabdfl> plovs: hell don't thank me, i must thank you for your work
<sabdfl> docs are a great contribution
<mdz> sabdfl: I wrote an overview "how to get help" doc in the wiki
<mdz> sabdfl: I think it should have a prominent place on the website, as a starting point for support
<mdz> perhaps as a how-to, with a quick link from somewhere high up
<sabdfl> mdz: go ahead and add it to the home page
<mdz> restructuredtext MUST be joking
<mdz> System Message: WARNING/2 (<string>, line 2)
<mdz> Title underline too short.
<mdz> I can't seriously be required to match the length of the underline to the length of the text
<mdz> it's displayed in a proportionally spaced font, even!
<mdz> sabdfl: should we really recommend this as the format for new pages?
<mdz> the restructuredtext guys have been hanging out with the arch guys
<Keybuk> rofl, them's fighting words?!
<sabdfl> mdz: we've now got moin too
<mdz> I was just following the instructions, which say that restructured is the way to go
<mdz> but I beg to differ
<sabdfl> written before we go moin tables
<mdz> HTML is easier than this
<sabdfl> yes, restructured felt like a pain at first to me too
<sabdfl> but it has a certain inflexibility that appeals to my inner fascist
<sabdfl> still, that's no reason to foist it on the masses
<sabdfl> in this case
<sabdfl> so let's hammer that out with the experts on monday
<mdz> what should I do with this howto for now?
<Keybuk> is there any particular reason we're using a new wiki, and didn't just get jeff to do a moin theme to make it look like the rest of the site?
<mdz> Keybuk: this way it can be searched, etc. with the rest of the site
<sabdfl> keybuk: *much* better integrated
<sabdfl> mdz: html if you prefer
<sabdfl> h1/2/3 and p 
<mdz> the wiki seems mostly OK
<Keybuk> but we've lost all the changes information; which was the bit I used to read
<sabdfl> keybuk, you can still read it
<mdz> my understanding is that it will come back
<sabdfl> turns out the new one has it already
<sabdfl> um... you may have to be a manager to see it
<sabdfl> nup
<mdz> I'll just leave it as-is and unpublished until we have a standard high-level markup
<sabdfl> history tab 
<sabdfl> default to just showing the last diff in pretty colours but you can get more
<Keybuk> ah ok, that's not too bad then
<sabdfl> and we get backlinks
<sabdfl> and renaming
<mdz> one thing I could live without, is white text on a red background
<sabdfl> and much better search
<plovs> kupu is nice but it creates html
<sabdfl> white text on red background?
<sabdfl> try the black text on red background :-)
<mdz> sabdfl: the active tab, the headings on navigation and recent items
<sabdfl> the theme is all temporary
<mdz> the currently highlighted navigation item
<mdz> ok
<sabdfl> i want to get te content and function right first
<Keybuk> the login stuff never seems to work right :(
<sabdfl> then we can get a design done and implemented quickly
<sabdfl> Keybuk: use the magic url
<Keybuk> well, I click login, put in the details, and get an error page back
<sabdfl> there are cacheing issues with just loggin straight in
<Keybuk> then some pages I visit thing I'm logged in, then some don't
* mdz -> lunch
<sabdfl> does adobe have a recent acrobat for linux?
<plovs> sabdfl, define decent
<__daniel> sabdfl, isnt it the one marillat has packaged? (you mean the reader)
<sabdfl> recent
<sabdfl> the reader, yes
<plovs> sabdfl, it works, but the windows one is way better
<sabdfl> ok
<amu> cooooool forrest gump runs on tv, i love this film
<Mitario> hello everyone
<Mitario> damn, ubuntu livecd is awsome :)
<__daniel> hai Mitario
<amu> Mitario: *g* 
<__daniel> oh... no glademm-package? :-(
<__daniel> who should i adress with my "wish"? :-)
<__daniel> ubuntu-users?
<cenerentola> sorry what are the main characteristic of the live thing?
<cenerentola> you could at leat pretend to listen
<cenerentola> sorry the stupid question but how can i contribute with the installer translation?
<cenerentola> kamion: got time for an humble question?
<Keybuk> it's Saturday night, I doubt he's anywhere near a computer
<cenerentola> keybuk: you are... so who/where should i ask/look to for the installer translation
<Keybuk> http://people.debian.org/~seppy/d-i/translation-status.html
<Keybuk> http://svn.debian.org/viewcvs/*checkout*/d-i/trunk/installer/doc/i18n/i18n.html
<Keybuk> http://www.debian.org/devel/debian-installer/translation-hints
<Keybuk> those three links look good
<srbaker> can someone here help me go through my lappy problems and troubleshoot them?
<sivang> srbaker : you might try and ask this on #ubuntu
<Keybuk> indeed, #ubuntu and ubuntu-users is the right place for tech-support and problems
<Keybuk> much busier with more people likely to be able to help
<sivang> hi keybuk, what's up?
<Keybuk> price of beetroot
<sivang> what?
<Keybuk> it's up
<sivang> what is beetroot?
<Keybuk> purple
<Keybuk> you have it in salads
<sivang> oh
<sivang> :)
<sivang> so all RC stuff are done (if to judge by the channel's topic) ? :)
<Keybuk> yes, any RC bugs now open are open against hoary
<sivang> I see. well, good :)
<sivang> Have you had a nice doze of beers post release?
<Keybuk> yeah, a few of us had a bit of a party in London
<sivang> ah that's great, shame I am way far on the middle east :))
<sivang> Kamion : around?
<jdub> hrm
<srbaker_> jdub, seems to be working now.
<srbaker_> jdub, who's fault is the Human theme for Gnome?
<jdub> whichwhat?
<srbaker_> jdub, my lappy
<jdub> which part of the theme?
<srbaker_> oh, the theem is fine except for the window border colour
<srbaker_> diarrhea brown.
<srbaker_> i had to switch to Glider
<srbaker_> yaye.  i found the ubuntu porjhn
<srbaker_> now, isn't there ubuntu porn for the splash screen as well?
<jdub> /usr/share/pixmaps/splash/
<srbaker_> how do i change my splash screen?
<__daniel> srbaker_, with gtweakui :-)
<jdub> in gconf, /apps/gnome-session/
<__daniel> oh.. not packaged in ubuntu
<srbaker_> oh
<__daniel> (i was referring to gtweakui)
<chrisa> Add sid sources, pin and install from sid ;)
<__daniel> chrisa, that's a good idea - would that be a general "course of action" if i'd like to contribute packages (if someone was interested in that at all)
<chrisa> I'm the last person to ask
<__daniel> :-)
<srbaker_> god damn.
<srbaker_> if i wanted sid sources, i'd use sid :P
<__daniel> well... first i wanted to reply to you and then i changed my mind and wanted to ask the rest of the channel too
<__daniel> chrisa, thanks for the clue :-)
<srbaker_> is it considered a bug that emacs isn't anywhere to be found in the app menu?
#ubuntu-devel 2004-11-04
<chrisa> Last I heard, that was to keep the menu simple
<chrisa> Same with gvim
<srbaker_> ahh
<srbaker_> suck
<srbaker_> hey, i saw vim-gnome for the first time the other day.
<srbaker_> almost made an emacs convert out of me.
<chrisa> Does vim-gnome offer anything vim-gtk doesn't?
<srbaker_> chrisa, i think dnd
<srbaker_> and it must, it's a separate package
<mdz> ok
<mdz> sabdfl: ^ :-)
<sabdfl> ah
<jdub> mdz: re vim-* or menus?
<mdz> jdub: distutils
<jdub> oh
<jdub> hey, had a fucked up dream
<jdub> wanted to fact check it
<sabdfl> since i want python to be a first class citizen on ubuntu it seems bizarre to be in a scrap with the pythonistas
<mdz> the specifics of its function seem less important than the fact that they're part of the standard Python library
<jdub> how do you stop a user doing LD_PRELOAD?
<mdz> upstream made an explicit decision on that, and started shipping distutils with the python croe
<mdz> core
<sabdfl> mdz: we can't be beholden to someone else in that regard
<mdz> jdub: stab them in the face?
<mdz> err
* mdz whistles innocently
<sabdfl> o.m.g.
<Kamion> jdub: set-id executable?
<jdub> ok, what if you don't have anything sharp handy?
<sabdfl> they build distutils because most platforms don't have python as a central feature
<mdz> sabdfl: I don't see it that way; it's a matter of compatibility?
<Kamion> jdub: otherwise, you don't
<mdz> s/\?//
<sabdfl> i'm not saying we should not support the distutils interface
<jdub> Kamion: hrm.
<sabdfl> but i think we should do so in a way that is integrated with dpkg
<sabdfl> we have an excellent pkg management framework in dpkg
<mdz> that's a very complex, long-term sort of project
* Kamion thinks it's a bad idea to have dpkg installing stuff that doesn't come from a well-maintained archive, personally
<mdz> whereas including distutils is simple, straghtforward, standard, compatible and useful today
<sabdfl> where does distutils stuff its files
<jdub> Kamion: i'm thinking LD_PRELOAD=ha-ha-gconf.so <locked-down-application>
<Kamion> jdub: ayup
<mdz> /usr/local/lib/python-<ver>/site-python
<sabdfl> jdub: you dreamt this?
<Kamion> jdub: making stuff setgid <something-random> has been known
<jdub> or worse, LD_PRELOAD=... gconfd
<mdz> jdub: what's the use case exactly?
<jdub> sabdfl: stfu!
<jdub> mdz: getting around gconf lockdown.
<sabdfl> between mdz's knee-jerk knifing and your dreams i think we all need a little time away from the keybd
<mdz> jdub: what's gconf lockdown?
<jdub> if lockdown was done in the backends, it probably wouldn't be an issue
<jdub> mdz: you can set mandatory settings and so on with gconf
<sabdfl> mdz: preventing users from changing settings
<jdub> mdz: see /etc/gconf/2/path
<Kamion> bad idea> the worst corner case that comes to mind is file conflicts; we can't realistically ensure that all packages we ship properly conflict with all packages a hypothetical distutils-dpkg might make up on the fly when they share filenames
<Kamion> jdub: is that actually used for security-critical purposes?
<sabdfl> kamion I'm not suggesting that distutils should make up a pkg on the fly
<jdub> Kamion: depends on how you'd define security critical, but i'd probably say no
<sabdfl> but rather that it should try to find the correct .deb
<Kamion> jdub: if it is, and if it runs entirely in a user's security boundary, whoever made it up was dreaming
<jdub> Kamion: it's just a barrier to doofusness
<mdz> jdub: ok, looked at that
<Kamion> sabdfl: ah, that would be a bit more palatable
<mdz> jdub: but what is gconf lockdown? :-)
<sabdfl> Kamion: slightly
<sabdfl> :-)
<Kamion> sabdfl: although it obviously only works as root, and I'm betting most real distutils use cases don't happen as root
<jdub> mdz: keys can be locked to administrator provided-values
<mdz> jdub: to what end?
<jdub> mdz: so they become read-only and users can't change them
<sabdfl> how can you write to  /usr/local/lib/python-<ver>/site-python unless you are root?
<Kamion> sabdfl: (although it could say "alternatively, you could ask your administrator to install python-<foo>", I suppose)
<mdz> jdub: to what higher purpose?
<Kamion> sabdfl: surely distutils can write to somewhere in $HOME too?
<Kamion> sabdfl: CPAN.pm can
<mdz> sabdfl: you can't; installing software is a rootish sort of thing at present
<sabdfl> exactly
<mdz> distutils and dpkg are not a very good match
<Kamion> any sensible system like that allows users to install their own libraries
<jdub> mdz: to "lock" "down" parts of the desktop so that users can't change them.
<mdz> distutils says "take this python module I wrote and put it into the system python catalog"
<jdub> mdz: readonly configuration values means that the user can't make changes.
<mdz> jdub: unless they really try hard
* Kamion -> party again
<jdub> such as LD_PRELOADing
<sabdfl> i think we can make a credible effort to ensure that every serious python lib is available as a deb
<mdz> sure
<mdz> but that isn't the same thing as distutils
<sabdfl> i'm willing to put the resources behind that
<Kamion> jdub: or ptrace(3), or any number of other things
<mdz> and I don't think it's a reason to make distutils a second-class citizen
<sabdfl> well, our distutils should at least TRY to find the right deb
<Kamion> jdub: non-set-id lockdown is just a dream
<mdz> jdub: or any number of things
<mdz> you can't realistically prevent a user from changing a program
<sivang> can't distutils be packages and then used on will ?
<Kamion> mmm, ptrace(2) rather
<jdub> fwiw, python fascists love debian as their python-crack CPAN
<sivang> *packaged
<sabdfl> because it's much better for support for us to install a deb than something in /usr/local
<sabdfl> jdub: and we install a lot of those into desktop by default
<Kamion> sabdfl: you only get that among people with total, utter Debian/Ubuntu buy-in
<mdz> sabdfl: this seems like a separate issue to me
<mdz> sabdfl: "should we split distutils from python proper" vs. "should we make distutils smarter"
<Kamion> sabdfl: anybody in a heterogeneous environment, or even anyone who's ever administered machines in a heterogeneous environment, will I suspect end up with stuff in /usr/local
<sabdfl> true
<sivang> after all, linux is about control. If someone is doing some funky /usr/local stuff, we might want to only warn him. BUt let him go with the changes.
<mdz> I think "no" and "yes"
<sabdfl> so we could do both: ship distutils, and make it more ubuntu-aware
<mdz> jdub: I can see that being useful for a site admin, to prevent users from accidentally shooting themselves in the foot
<Kamion> sabdfl: that seems like the best of both worlds, yeah
<mdz> but it can't be realistic as a security feature
<sabdfl> ok, so that's what we should do for hoary
<jdub> mdz: not hard security, no
<sabdfl> i'll update the bug
<mdz> not any kind of security
<sabdfl> does anyone else see a heisenbug with firefox refusing to take keyboard input?
<jdub> (depends on your definition, and your audience)
<mdz> sabdfl: the "smarter distutils" project would be a big one
<jdub> in the mean time, i'm going to hassle havoc
<sabdfl> mdz: would it be particularly tricky?
<mdz> sabdfl: distutils works from a tree of python stuffs
<mdz> sabdfl: there would need to be an external mapping from that to debs
<mdz> it can't realistically find the .deb given the information in the source tree
<mdz> s/given/given only/
<sabdfl> right, there needs to be a db of debs that's part of the same package as distutils
<sabdfl> just like the "install an app"
<sabdfl> mdz: why not?
<sabdfl> md5sums
<sivang> basically, the wish is for every modules to have a seperate package?
<mdz> sabdfl: ok, so I unpack the python 'foo' module version 1.23 and run 'make install' which invokes distutils routines to install the stuff
<jdub> mdz: (can we do this with the package post-processing foo we need for translations, embedded and installer?)
<mdz> jdub: yes, it requires that sort of infrastructure
<mdz> which is what makes it complex
<sabdfl> thing is, we want to promote python as an app language
<mdz> also, even with all of that, I think the best we can do (and remain sensible) is tell the user "hey, did you know you can get that as a .deb?" before doing what they asked
<mdz> we can't substitute a .deb behind their backs
<sabdfl> but we dont want to end up in a situation where instlaling a big app results in tons of stuff in /usr/local which is *perfectly* packaged for ubuntu
<jdub> (there are also version considerations and so on, we might have too-new or too-old versions)
<mdz> sabdfl: distutils is the sort of thing which is used in automated build systems
<sabdfl> jdub: md5sums
<mdz> if the user has a python module, and they say "install this", and we sneak about and give them something else, that's evil
<sabdfl> how does distutils handle conflicts, depends
<mdz> it doesn't, afaik
<sabdfl> but dpkg does
<mdz> it's not a package management system
<mdz> it's more like debhelper than dpkg
<mdz> you write a description of your project for it, and it puts everything in the right places for you
<sabdfl> mdz: agreed, not behind their back or silently, it should give them the option to install the deb
<mdz> so when you have a Debian package of a python module, it uses distutils to do the real work
<mdz> "make install" uses distutils
<sabdfl>  really? deb's of python libs use distutils?
<mdz> yes
<mdz> that's what it's for
<sabdfl> then why is it not installed?
<mdz> it's used at build time
<sabdfl> we have a lot of debs of python libs installed
<mdz> not at install time
<sabdfl> so the deb doesn't the deb0src does
<sivang> mdz : does it unpack the source and run distutils against it?
<mdz> correct
<hazmat> there are a few python gnome apps which use distutils for deployment
<hazmat> although i'm not really clear how robust that is outside of default install locations
<hazmat> like revelation
<hazmat> since gnome apps tend to need lots of registration files in the proper location.. http://oss.codepoet.no/revelation/
<sivang> hazmat : this is already used in ubuntu's current gnome installation?
<hazmat> not afaik
<hazmat> no
<hazmat> most of the python gnome apps tend to use the autoconf setups, which still reads like greek to me.. there are a few of those in ubuntu (like blog-applet, meld)
<sivang> hazmat : if they were using distutils, they would have used a .py setup file for python foo.py install ?
<hazmat> sivang, yes.. and you can pass in different installation roots to the install.. but its fairly aribtrary code in terms of how the actual install is performed, the degree of customization for distutils varies greatly from systems like 4suite and scipy which are basically running their own distutils.. but the toplevel commands are typically the same. ie python setup.py install 
<sivang> hazmat : so when you install scipy from source, it would use the "standard" distutils format, and as a side effect mangle with /usr/local etc?
<jdub> ls
<jdub> heh
<jdub> bong
<srbaker_> grr.  is there a graphical tool for editing runlevels?
<srbaker_> i want to stop raid, evms, lvm, etc.
<__daniel> srbaker_, i'm not quite sure, if i told _you_, but there's  update-rc.d  you could use on them
<srbaker_> i know about update-rc.d.  i wanted a gnome app to recommend to a friend.
<srbaker_> so i'm trying to figure out gui ways to do things
<srbaker_> there.  boot time should be short now
<srbaker_> is there a place to register ubuntu repositories?
<srbaker_> like apt-get.org, only for ubuntu?
<srbaker_> i'm going to be packaging ifolder, simias, addressbook, spamtrainer, and tomboy
<srbaker_> yo
<srbaker_> whoops.
<ctalkep> what is tomboy?
<srbaker_> uh "Wiki for your Panel"
<ctalkep> huh?
<srbaker_> it's a sticky note app with linking capabilities, basically
<ctalkep> sounds nice
<ctalkep> where do i get it?
<jdub> srbaker_: tomboy is already done, ifolder and friends are on their way
<srbaker_> see edd dumbill's log
<srbaker_> jdub, oh.  nice.  where will i be able to find those?
<jdub> tseng's repo for tomboy
<jdub> mine will have ifolder and friends
<ctalkep> and what are ifolder and friends?
<srbaker_> ahh
<srbaker_> are you doing for debian, too?
<jdub> yeah
<srbaker_> oh, excellent
<srbaker_> :)
<jdub> someone else has itp'ed it though
<srbaker_> ahh
<__daniel> Kamion, still around - booshi in #ubuntu also experienced #1566 - if you need more input on the bug...
<sgtshatta> anyone here?
<Keybuk> nope
<sid77> hi
<sid77> lol
<sgtshatta> i have a simple question?
<sid77> don't know, have you? ;)
<Keybuk> sgtshatta: is it development related?
<sgtshatta> actually no!
<sgtshatta> i am a new user to ubuntu 
<Keybuk> ah, you may find #ubuntu a far better place to ask it -- there's more people there with a much wider experience and you're more likely to get a useful answer
<sgtshatta> thank you much
<Keybuk> this is where we talk about what patches are going in the libc6 of the next release, etc.
<Keybuk> it's also best to simply ask your question, and wait for the answer; rather than asking to ask a question :)
<sgtshatta> quite tru
<sgtshatta> true
<sgtshatta> i change my $PATH in /etc/profile system wide after reboot it did not change
<Keybuk> didn't change for what?
<sgtshatta> well I am trying to compile a piece of software from source and it requires some libraries from /usr/lib
<sgtshatta> and i made some changes to my $PATH to point to it but it did not locate /usr/lib/pkgconfig
<Keybuk> it wouldn't
<Keybuk> /usr/lib/pkgconfig is a directory
<Keybuk> it's looking for /usr/bin/pkg-config
<sgtshatta> I know its a directory but why did my environmental path not change
<Keybuk> and that will definitely be in your $PATH, unless your system is insane and dribbling out of the ears
<sgtshatta> LOL
<Keybuk> about a thousand reasons
<Keybuk> mostly boiling down to most things don't read /etc/profile
<sid77> what about playib with configure options?
<sid77> playibg
<sid77> urgh
<sgtshatta> get it right
<sgtshatta> lol
<sid77> p l a y i n g
<sgtshatta> LOL
<sid77> yatta!
<sgtshatta> keybuk: but from what this software is i wont need to mess with the config options
<sid77> maybe using something like "./configure --pkg-path=..."
<Keybuk> /etc/profile is only read for interactive login bourne-compatible shells
<Keybuk> or, in english, it's only read if you login on the text-mode console
<sid77> (option invented right now)
<Keybuk> (and I really expect you're not doing that, and are just opening a graphical Terminal)
<sgtshatta> you're right but i did all that 
<Keybuk> what's not getting located?
<sgtshatta> libxine.so
<sgtshatta> I am trying to install my favorite video player
<mojo_> hi there
<sid77> oh, wait
<Keybuk> do you have the libxine-dev package installed?
<sid77> I've had same problem loong ago
<mojo_> Anyone here reponsible for FireFox build?
<sgtshatta> no i dont have libxine-dev installed
<sgtshatta> i dloaded the source from the site
<Keybuk> sgtshatta: install libxine-dev :o)
<mojo_> I want the Ubuntu mozconfig for some experimental tweak
<sgtshatta> can i use apt-get to do that?
<Keybuk> mojo_: apt-get source mozilla-firefox
<sid77> sgtshatta, and remember ldconfig after that!
<sgtshatta> yea i know ldconfig
<Keybuk> sgtshatta: aptitude install libxine-dev  will give you the xine development library
<sgtshatta> keybuk: give me that syntax again??
<mojo_> does the src pkg from our repository contain mozconfig (for Unbuntu build)???
<sgtshatta> keybuk: that worked kool 
<Keybuk> mojo_: if mozconfig is important to build mozilla-firefox, I would expect so
<mojo_> Keybuk, you've seen pitti, bob2 around?
<Keybuk> I expect they're both doing Saturday things
<Keybuk> bob2, Sunday morning things
<mojo_> maybe, damm too tired for whole months, now I can relax a bit
<Mitario> hi
<mojo_> watsup?
<__daniel> good night
<fabbione> morning guys
<tseng> hi
<hornbeck> tseng: what is the chance of a gecko-sharp-0.6 package soon?
<tseng> erm
<tseng> what for?
<hornbeck> so I can try the new blam
<hornbeck> it uses gecko for rendering
<hornbeck> I guess I could just learn to package it myself huh :-)
<tseng> hm
<tseng> maybe later
<tseng> not today mater
<tseng> mate*
<hornbeck> I am working on it
<hornbeck> it is not something that everyone would need right now, so I might as well learn
<hornbeck> goodnight guys
<srbaker_> totem in ubuntu is totem-gstreamer?
<mdz> srbaker_: yes
<tuo2> Gah. Why do people insist on saying that Firefox is "more secure"? It's a tenuous claim, at best.... 
* tuo2 shakes his head
<sivang> morning all
<fabbione> morning sivang 
<sivang> hey fabbione, how's xorg going?
<fabbione> sivang: it's going :-)
<fabbione> i am breaking the libraries right now
<fabbione> the real problem is not building it
<fabbione> it's do in such a way that you can actually upgrade from Xfree86 to X.org
<sivang> hmmm..interesting. Can't a way be found to do something like (in the upgrade process) to remove xfree's file and install xorg's ones?
<fabbione> sivang: that what needs to be done :-)
<fabbione> there is one way only
<fabbione> but it needs to be done very carefully
<fabbione> and that requires a lot of upgrade tests
<sivang> fabbione : well, just let me know what you need :)
<fabbione> sivang: as soon as there is something more concrete to work on.. be sure i will call you
<fabbione> you are the first name in my list of bitches^Wpeople that can help ;)
<lamont> moo
<fabbione> hey lamont 
<lamont> yo
* lamont falls into bed
<fabbione> good night :)
<sivang> fabbione : Well, that way I'll buy myself some treats in this jail :)
<fabbione> ehhe
<sivang> night lamont
<sivang> it's been a rough one I guess?
<mdz> tuo2: because they compare it to IE :-)
<tuo2> mdz: I just see people seeing themselves up for a fall, that's all. I mean, it's the fanboys who worry me...
<tuo2> making claims that they have no understanding of.
* tuo2 mehs.
<tuo2> mdz: any news on the security team yet?
* tuo2 still hasn't seen any movement on the website...
<mdz> tuo2: you mean, apart from the two advisories posted on the website today? ;-)
<tuo2> mdz: ?
<mdz> http://www.ubuntulinux.org/support/documentation/usn/errorreferencefolder_view
<tuo2> ah, sweet.
<tuo2> mdz: I was more talking about this...http://www.ubuntulinux.org/community/teams/security
* sivang is also interested on info about security team
<sivang> *in
<mdz> I didn't even know that page existed until now
<mdz> so obviously I haven't been updating it :-)
<tuo2> mdz: heh.
<fabbione> hey mdz
<mdz> fabbione: morning
<tuo2> that might explain things.. I asked about this a couple of weeks ago (was in volunteering mood) and was told to watch that space..
<fabbione> mdz: i didn't see any announcment about the new wiki
<mdz> fabbione: I think it went to -doc
<fabbione> do we have a -doc mailing list?
<sivang> no
<sivang> we are currently using -devel with [doc]  tag
<mdz> fabbione: yes we do
<mdz> sivang: no, please use the -doc list now
* fabbione sighs
<sivang> ha?
<sivang> when that did happen? :)
* mdz mails -devel
<fabbione> guys we need to post this stuff in like -announce or -news
<mdz> sivang: yesterday
<fabbione> otherwise it gets lost in the noise
<mdz> -devel is fine for this
<sivang> ah
* sivang feels lagged
<sivang> Funny, I checked the mailing lists yesterday, wiki etc. Didn't see no evidence to it
<sivang> mdz : you set it up? Enrico?
<sivang> I'll rush up alos to update the wiki page of DocTeam
<sivang> mdz : it started getting high traffic ? :)
<fabbione> mdz: did we get automatically subscribed?
<mdz> fabbione: no one was automatically subscribed
<fabbione> ok
<sivang> was this discussed over the weekend?
<mdz> not really; it was just time for a new list
<fabbione> uff it's time to start to work in the house
<fabbione> bbl
<fabbione> ah mdz: is the old wiki completely imported into the new one?
* fabbione goes away
<mdz> fabbione: not entirely
<mdz> yet
<jdub> mdz: warty-updates + warty-security -> we're keeping with that split?
<mdz> jdub: yes, unless there's a compelling reason to do it differently
<mdz> jdub: practically _everyone_ wants security fixes, but some folks are conservative enough not to want non-security fixes
<mdz> for example, we're likely to put a kernel into warty-updates with some bugfixes
<jdub> yeah
<jdub> cool
<mdz> jdub: the merging aspect will suck (package in -updates + new package in -security requires a merge for a new -updates package)
<mdz> but hct will ease that when it comes
<jdub> mmm
<mdz> we probably won't put very much into -updates in the near future
<mdz> so far the only candidate is #1814
<jdub> there's an evolution-exchange bug i'd like to see fixed in -updates, though
<jdub> hrm, don't think it's in our bugtracker
<mdz> we should have a representation for that in bugzilla
<jdub> yeah
<mdz> i.e., which items should be considered for -updates
<mdz> bedtime now, though
<mdz> night
<jdub> night
<jdub> perhaps target wartywarthog, severity critical
<sivang> when pages are going to be migrated to the new wiki?
<__daniel> good morning
<sivang> morning __daniel
<__daniel> hai sivang :-)
<__daniel> *grmbl* what do i do on "Language ar_EG.UTF-8 doesn't exist, using system default."?
<sivang> __daniel : this should be asked on #ubuntu, but you'd probably do "sudo dpkg-reconfigure locales"
<sivang> check the local you want to have, and let it be generated.
<__daniel> sivang, that's what i did before
<sivang> __daniel : you also chose it to be the system default?
<__daniel> sivang, no, that's not needed
<__daniel> sivang, other locales like nl_NL.UTF-8 worked nice without being the system default
<sivang> __daniel : were you getting some sort of an error?
<__daniel> "Language ar_EG.UTF-8 doesn't exist, using system default." when i chose it in gdm and logged in
<__daniel> the guys in #arabeyes are clueless too (but they told me ar_EG was the arabic "best guess")
<sivang> maybe it's just missing
<__daniel> sivang, that would be very strange, because i got it with *all* ar_* locales
<sivang> lemme check myself 
<sivang> __daniel : here?
<__daniel> sivang, yes
<sivang> __daniel : It works perefectly. Arab letters had never seen so beautiful before :)
<__daniel> do i have to modify /etc/gdm/local.alias or something to make it map "ar_EG.utf8"?
<__daniel> *DAMN* i want to have that too
<__daniel> *cry*
<sivang> Arabic(Egypt)   ar_EG
<sivang> Arabic(Egypt)   ar_EG.UTF-8
<sivang> this what I Have on  /etc/gdm/local.alias
<sivang> that is UTF8 , caps
<sivang> UTF-8 that is, sorry
<__daniel> sivang, i have that one too
<__daniel> very very strange
<sivang> __daniel : that might be a bug, but could you try again the dpkg magic thingy? :)
<__daniel> sivang, dpkg magic thingie?
<sivang> __daniel : I asked it to create egyptian UTF8 arabic, and didn't set it to default
<sivang> __daniel : sudo dpkg-reconfigure locales
<__daniel> sivang i tried it a dozen times :-)
<__daniel> and restarted gdm and everything
<__daniel> hmmm, don't know how i could have screwed this up
<sivang> __daniel : hmm, I didn't even do a restart. let's move this to #ubuntu, shall we?
<__daniel> right
<azeem> so I installed warty on my parent's computer two weeks ago.
<azeem> My dad used to bitch around how I should install Windows again on their computer all the time
<azeem> yesterday, he asked me to install Ubuntu next to Windows on his new notebook :)
<jdub> heh
<jdub> rock!
<amu> moinD
<azeem> amu: who of you credativ guys is coming to LWE?
<bob2> hm, how come tomboy includes a .so?
<bob2> isn't it written in C#?
<magnon> there's some c code in there as well
<bob2> erk
<bob2> tseng: your romboy packages are missing build-deps on gdk-2.0 and atk-2.0
<bob2> er, just atk
<azeem> gah, stupid irssi tab-completion for /leave
<azeem> I was in #ubuntu, typed /leave #ubun<tab><return> and it completed to #ubuntu-devel for some weird reason
<amu> hehe SUSE-Linux-9.2-LiveCD-Gnome.iso 
<amu> someone run a sip phone?
<bob2> tseng: and libgtkspell-dev 
<hornbeck> mdz: you around?
<Micksa> am I allowed on here? :)
<hornbeck> sure
<hornbeck> why not?
<Micksa> well I'm not an ubuntu developer
<Micksa> I like to lurk :)
<bob2> just remember it's a development channel, nota user support one
<Micksa> yeah, I know the drill :)
<Micksa> bob2: did you used to hang out in #debian-devel?
<bob2> still do
<Micksa> ah.
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu development -- general discussion and support on #ubuntu | Happy Hoary Trail! | BE THE SIGNAL | Warty release is DONE | Hoary kickoff meeting Monday, 2004-10-25 1600UTC
<plovs> hornbeck, sivang, hi!
<sivang> hey plovs, what's up?
<hornbeck> hey plovs
<hornbeck> another day huh?
<asw> hornbeck, plovs, sivang -- hi all! 
<hornbeck> hello asw
<sivang> hey asw
<plovs> sivang, hornbeck, asw, spare time! time for wiki!
<sivang> plovs : you mean the new wiki?
<hornbeck> plovs: do we start adding things before it get migrated?
<hornbeck> reStructuredText is sexy
<asw> I've been reading the new list, watching the move to the Plone Wiki but I also shipped my PHD thesis proposal last night (the "official" draft goes out tomorrow).  Sorry I've been out of touch... 
<hornbeck> asw: congrats
* hornbeck still has no bachlors
<plovs> hornbeck, yes, maybe start with DocTeam stuff, i want to write a reStructuredText, document
<asw> so, please, explain.  reStructuredText is not docBook? right?  So what formats can we export to from plone?
<plovs> asw, congrats as well
<sivang> why don't we start discussions on the new list? so not to leave things off to IRC and get lost, as it already did? I only missed 2 days and already I feel the world has turned over
<sivang> THis is not benefitting us
<hornbeck> asw: I am not sure what we can export to
<asw> hornbeck. I dropped out of school at 20. (admittedly ten+ years later) I have a bsc and (very soon?) will have an msc in CS and phd in biophysics (eventually.) 
<hornbeck> asw: nice
<hornbeck> how are you now?
<hornbeck> old
<hornbeck> :-)
<asw> 31
<hornbeck> nice, I still have hope
<asw> sivang: i agree we don't want to write too much in here. 
* hornbeck is 24
<asw> I've asked before about logs. I think there are some logs floating around that we can probably get access to. 
<asw> Now that I've started using IRC I guess it isn't so bad.  
<sivang> asw : it was very odd finding out we *already* have a doc list, we're *moving* to antoher wiki system , the doc team is starting it's *own* distro.. :)
<hornbeck> the problem with irc is people have to sleep and most of us are in different parts of the world
<plovs> sivang, agreed, maybe drop more logs on the wiki as well?
<asw> sivang: we have our *own* distro.  OK that's news to me. 
<plovs> sivang, although the rest was  for me surprise as well
<hornbeck> asw: I hope he was joking on that
<hornbeck> :-)
<sivang> asw : I was joking.
<sivang> :)
<hornbeck> it was suprise for all of us
<bob2> if you guys want to get serious discussion going, you have to do it on the lists
<sivang> asw : just to stress out the problematic aspect of doing stuff that way.
<asw> plovs (thanks for the congrats btw.)  sivang: laughing
<bob2> even if you just post summaries of stuff you come up with on IRC, you need list discussion
<asw> silly question but how do I make an "aside" as I see people doing.
* bob2 makes an aside
<plovs> asw, /me aside
<bob2> asw: like that?
<sivang> yeah, just like the devels doing it. You would never spot here one of them discussion anything but late minute important stuff mostly :)
<hornbeck> bob2: that seems like a problem with us right now
<sivang> summeries would be just as bed
<sivang> bad
<hornbeck> asw: use slash action
<sivang> people need time to think things, comment and respond properly etc
<hornbeck> /action
<sivang> we *must* move to the list.
<bob2> hornbeck: plus IRC is more ephemeral, and doesn't get archived. and people tend to not think things through so much.
<hornbeck> bob2: but its so much more fun in here :-)
<plovs> let's agree on putting important stuff to the list, but irc is *nicer*
<sivang> I just can't bare in mind that I will work on something  off the road, won't be on IRC for a day or 2 
<sivang> and then it would be decided that this work altogether is redundent
<sivang> which could happen,
<hornbeck> sivang: not on irc for a day or two 
* asw asw makes an aside
<sivang> as things are currently managed.
* plovs congretulates asw
<hornbeck> asw it puts your name right away
<hornbeck> so //action makes an aside
<hornbeck> with one /
* asw light shines over sasha's head 
<hornbeck> yes
<hornbeck> congrats
<hornbeck> irc elite
<hornbeck> :-)
<hornbeck> so how about as we talk, we write ideas in mails than mail them, than we tell each other that we mailed than we can go and remail each other,
<sivang> I do not intend to scare anybody off from doing work, this is not the intent. I'd just like to see things discussed on the list before hand, documentation should be of no difference from development.
<sivang> given they are slightly more than cosmetic changes.
<plovs> sivang, although we should the wiki as well, just have a docteam page for *current* discussions
<bob2> discussion *on* the wiki?
* bob2 ew ew ew ews
<asw> sivang (others) I use gmail and let it help me search the ubuntu traffic.  I've left XChat open so I can load the logs in emacs and search.  I have most IRC logs since our doc-meeting and I expect somebody at Canonical has full logs we could access if it helps. (In addition do doing more list discussion, naturally)
<sivang> asw : well, has has (mako) however when dicussing things on a mailing list, one does care to make things more readable and understandable, making it more easy to catch up by other people who weren't online on IRC or were not into the mindset that a specific conversation was in.
* asw sasha wants to keep using IRC now that he is e - l - i - t - e  (This just reminds me too much of being 17 and I really liked that age actually.) 
<Gmail> do any of the devel want so of the port from debian .debs i will be working on?
<Gmail> like i will port the latest gaim, xchat, firefox.... internet programs
<sivang> asw : I think it's no wonder most of the real development stuff is discussed on mailing lists, take for example, GNOME, KDE, Debian etc
<asw> sivang: yeah, I totally agree that people should not hav eto wade through IRC logs to get essential details of what's going on! 
<bob2> Gmail: hoary will have them soon enough
<Gmail> i am talking about porting them to warty
<sivang> asw : keeping current with stuff should be easy, not a pain in the arse :) (my idea about searching through 3 days, few megs irc logs)
<plovs> sivang, asw, *essential* stuff should be on the list (esp. now we have a real one) 
<bob2> Gmail: you can do whatever you want, but they will not go into warty
<asw> sivang: agreed re. *essential* stuff.  It is interesting, however, "meeting" you guys in IRC. 
<Gmail> bob2: not *offical*
* asw Sasha goes to read [doc]  and the new list...
<Gmail> bob2: not *offically*
<bob2> Gmail: then host them in your own web space
<Gmail> but i want to know if i should backport from hoary or port them from debian
<sivang> asw : Ofcourse it is, and I persoanlly really like it, but it's more suitable for stuff like "do you remembner the docbook tag for header" then "Let's decide to open a new mailing list" , do you get my point?
<bob2> Gmail: hoary doesn't exist.
<bob2> sivang: that is the dynamic a lot of projects end up with...little reminders, questions, etc happen on IRC, but the big discussion ahappens on the list so everyon can contribute.
<plovs> sivang, i don't think that was a docteam decision, was it?
<sivang> plovs : I was using it as an example. yes, I think not :)
<sivang> bob2 : agreed
<Gmail> bob2: yet i am talking about when it comes out
<sivang> we cannot expect each and every interested doc contributor to be online, some of them maybe expecting the list to be just as informative in the essential matters as IRC might be.
<sivang> (*online all the time)
<asw> bob2: actually, I follow lists extremely carefully and have done so for ten+ years.  Until I found IRC I never really felt "part of the process".  It's quite a dramatic difference actually.   
<bob2> Gmail: when it comes out those packages will already exist in hoary, and backporting will be trivial...regardless, it's a discussion that can wait until hoary exists.
<bob2> asw: oh, yes, it's very good for team building
<sivang> what about the proposed doc sounder team? we could use the mailing list also to announce new documentation for testing etc..
<plovs> hornbeck, good mail, who is on the docteam etc... but ubuntu moves so fast it is hard on everybody, and the new wiki was a surprise for everybody i suppose, although it was expected
<bob2> asw: and to get to know people outside the strict technical forum of a list
<bob2> asw: they're definitely complimentary
<asw> So who has seen http://www.pastebin.com
<Gmail> bob2: so i should just port from debian
<Gmail> ok thanks
<bob2> Gmail: hoary doesn't exist, so where else would do it from?
<hornbeck> plovs: write that to the list
<sivang> I agree with bob2, these are very good for getting to know each other and etc, and also if we are to decided things using this wonderful medium, we ought to make it a meeting , and announce it as wide as we can to maximize participation
<hornbeck> plovs: thanks though, I thought it was a good mail
<hornbeck> sivang: read your mail
<hornbeck> :-)
<Gmail> bob2: i am talking about in a few weeks whn hoary work will start
<sivang> sure thing :)
<hornbeck> gmail: do it if you want
<bob2> Gmail: then practice your backporting skills and make a decision later
<hornbeck> gmail: no one will tell you not to but it will not be included in warty, you will have to dipench them yourself
<hornbeck> *dispench
<hornbeck> nevermind
* hornbeck 's ability to spell does not exist
<plovs> hornbeck, that's what spellcheckers are for :)
<Gmail> hornbeck: but my package will *work* with warty that what i am tring to say
<sivang> if we are going to put irc logs, they need to be summrized to include the essentials, so to ease finding the really important stuff
<plovs> the only thing i think we should do is make a new docteam page on the new wiki, and a new intro to the wiki
<sivang> not just put them there :)
<sivang> plovs : I think we should wait with this until we are appointed a leader
<plovs> sivang, agreed, under docteam a page called CurrentIssues or something, with notes from the logs. If st is important enough for that page it should also be in te mailinglist
<sivang> Has anyone has anything to say about the documentation proposal by Enrico? I think it's very good, has anyone else seen it on -devel?
<Gmail> just an idea for ubuntu: make in the boot up thing you are doing alt+f-lock's f1 == alt+f1, i was on a friends computer which he had a m$ kerboard and it was hell because his power went out every 5min and i had some console work to do
* sivang was wondering why nobody commented on that.
<plovs> sivang, so who appints, mark?
<sivang> plovs : I believe so.
<plovs> sivang, i humbly disagree, let's get writing, later when we have a formal team-leader, he can sort it out, we need pages, not politics, the politics will follow, they always do.
<hornbeck> gmail: it will not be included because new things like that are for hoary not warty, but you are free to host them yourself and distibute them
<hornbeck> sivang: I just resent all of enrico's writeups to -doc
<Gmail> is it possible to tern on f-lock if its off by default because you are using a fscked up keyboard
<hornbeck> plovs: I agree to the lets write.
<Gmail> hornbeck: I SAID: it will work *with* warty and not be part of offically
<hornbeck> plovs: I however and being careful because I don't want to step in and start writing knowing that the wiki will start merging soon
<plovs> hornbeck, off course i partly agree with sivang as well, i just don't like sitting around
<hornbeck> gmail: please don't yell
<bob2> Gmail: chill out.
<bob2> Gmail: if you want to get an answer about your backports, ask on the list.
<hornbeck> plovs: I hate sitting and it makes me think of working with other stuff than I get interested in them and lose site
<sivang> plovs : I agree to leave behind the politics, however without the even most basic preparation and planning, we would end up with a bunch of pages, each one understandable only to the author , without an apparent way to sort out, to index, something that could cause an immesne turn of on a user trying to just get help
* hornbeck has add
<hornbeck> ADD
<sivang> plovs : I think we are already at this point :(
<plovs> hornbeck, some pages will need to change like restrucyredtexthowto
<asw> plovs: it's certainly true about the politics.  All, sorry if I've talked too much about my PHD etc but it's rather pressing on my mind since if all goes well on Nov. 1st when I present my proposal I can have a year of full-time paid work that, in part, can go into ubuntu.   Personally, as one of the people that was interested in the moin->docbook gateway. I'm now intersted in ReStructuredText since we seem to have switched away from Doc
<asw> Book to that. (I'm actually all for the idea in principle I just don't have any clude about ReStructuredText in practice.)  Anyway, this is a long message. I should go prepare for my proposal.  I'm following the lists. It's -really- nice meeting you all online.
<Gmail> sorry i terned on caps lock by mistake as caps is under caps and saw and terned it off and wasnt bother to retype it all
<hornbeck> plovs: I know, but there is no reason to cause more work for myself, so I am going to wait a day
<bob2> Gmail: just chill in general.
<sivang> I think waiting until next CC meeting is fine
* Gmail 9is chilly
* Gmail 's blood temp is 36c
<plovs> hornbeck, ok, i continue with https://site-edit.ubuntulinux.org/wiki/QuickreStructuredText, feel free to comment on it, this page we will need anyway
<sivang> has anyone decided to drop docbook for us?
<hornbeck> plovs: feel free to do what ever
<hornbeck> sivang: no docbook has not been dropped
<hornbeck> reStructuredText is for the new wiki
* sivang just feared another important decision has been yet *already* made :)
<hornbeck> docbook is how we write offline docs
<plovs> hornbeck, i thought you were team leader?
* plovs reading the mail again
<hornbeck> plovs: no, I am not the teamleader
<sivang> so investigations were made and we cannot have a docbook eating Plone?
* hornbeck hopes he did not write that wrong in the mailing
<hornbeck> sivang: I am not sure
<sivang> hornbeck : do you know who's the contact for that matter?
<hornbeck> sivang: right now no.
<bob2> sivang: restructuredtext to docbook?
<bob2> that can't happen automatically, docbook is a lot richer
<sivang> bob2 : I was more thinking of the other way around
<bob2> sivang: hm......sounds like an interesting project
<plovs> sivang, bradb and lulu are doing plone stuff
<sivang> write once, publish anywhere ? :)
<sivang> I see. Well, are they on IRC?
<hornbeck> sparkes hello
<sparkes> hi again hornbeck 
<plovs> sivang, they should be on irc monday
<hornbeck> sparkes: meet plovs, and sivang
<hornbeck> two other doc guys
<sivang> plovs : where do you know all this from?
<hornbeck> sivang: plovs, spends alot of time in here :-)
<plovs> sivang, they got tired of me yesterday, asking plone questions
<sivang> I see
<asw> bob2: reStructuredText->docbook is in progress according to: http://docutils.sourceforge.net/index.html
<sivang> :)
<plovs> reStructuredText->docbook would be *very* nice
<hornbeck> yes it would
<hornbeck> cut down on alot of work
<hornbeck> brb, wife just woke up
<plovs> how is it going with the yelp stuff?
<hornbeck> babies eating so I have a few
<sivang> hey sparkes 
<sparkes> hey sivang, everyone else
<sivang> so what else has been going on? I'd like to get myself current on latest affairs
<sivang> (docteam wise)
<plovs> sparkes, hi, nice to see you, and i agree with your mail
<hornbeck> sivang: there is not really much else
<sivang> ok then.
<plovs> sivang, 1) surprised by plone-wiki 2) surprised by mailinglist
<sparkes> plovs, which mail?
<sparkes> the nomination? ;-)
<plovs> sparkes, yes, if hornbeck is the ad hoc leader well, so be it until further notice, later we can vote or have sb appointed, but that is just my opinion
<sparkes> plovs, so that's a second
<sparkes> hornbeck, you're it ;-)
<hornbeck> plovs, sparkes: I will wait for sabdfl/mdz/jdub to do the appointing.  I don't want to step on any toes.
<sivang> guys, havn't we just dicussed that such important decision should be made in the mailing list or in a CC meeting?
<bob2> do you guys have plone accounts yet?
<hornbeck> Thanks though, I am honered
<hornbeck> bob2: For the new wiki, yes
<bob2> ah, cool
<sivang> besides, I think it's on Ubuntu Governence RUles that team leader get appointed only by CC meetings
<hornbeck> at least some of us do
<sparkes> bob2, nope
<hornbeck> sparkes: in due time you will
<tseng> bob2: you are wrong about libgtkspell-dev
<sivang> http://www.ubuntulinux.org/community/governance/document_view
<hornbeck> sivang, plovs, sparkes: I think this should all be discussed at the CC meeting so could someone add something to the Agenda for it
<bob2> tseng: it wouldn't build until I installed it
<plovs> sivang, agree,agree, just voicing opinion, not making policy
<tseng> bob2:  libgtkspell-dev (>= 2.0.5),
<sparkes> hornbeck, true
<sivang> And I hope hornbeck won't resent me in the future just for making those observations..:)
<bob2> tseng: hmmm
<plovs> sivang, balance of power is always healthy
<bob2> tseng: ok, sorryy; I see it in the control file, but debuild didn't complain
<sivang> hornbeck : I just want things to be done properly. Or else we would end up on an isolated island, doing everything on our own, without noticing we're missing the point :)
<tseng> bob2: did you apt-get build-dep tomboy?
<bob2> tseng: no, but debuild should complain about missing build-deps
<tseng> then i blame debuild
<tseng> i dont see a syntax error
* sid77 saluta
<sid77> ops
<sid77> sotty 'bout that
<tseng> lintian doesnt mind it either
<bob2> how odd
<bob2> dpkg-checkbuilddeps doesn't complain when I remove libgtkspell-dev
<azeem> is there a way to display the devices during the installer? lspci does not seem to be around
<hornbeck> sivang: I agree completely
<hornbeck> sivang, plovs, asw, sparkes: I am going to spend some time with the family right now so I will be away for awhile.
<sivang> hornbeck : why thank you. feew, I feared for you silenting suddenly :)
<sparkes> hornbeck, see you later
<sivang> hornbeck : c'ya laterz then
<bob2> tseng: was I right about the other two?
<sparkes> I am about to head off out with my son as well
<hornbeck> well I guess I am not leaving afterall
<hornbeck> my little girl is going back to bed :-)
<hornbeck> sivang: I was silent because I was talking with the wife
<sivang> hornbeck : ok cool ;)
<hornbeck> sivang: I don't want anyone appointing anyone with out CC approval or at least a higher up saying so
<sivang> ofcourse. I am adding to the CC agenda as we speak
<plovs> sivang, link?
<sivang> plovs : sec, still revising it
<hornbeck> if random letters start appearing from me sorry, I have a six month old on my lap
<plovs> hornbeck, we'l think it's haiku wisdom
<hornbeck> yes, please do
<hornbeck> :-)
<sivang> done.
<sivang> http://wiki.ubuntulinux.org/CommunityCouncilAgenda?action=show
<hornbeck> sivang: looks great
<sivang> hornbeck : thanks :) I'm glad you're ok with that.
<hornbeck> sivang: why would I not be?
* plovs forwarded it to the list
<sivang> hornbeck : Just my paranoic, "I hope everyone is ok with what I'm doing"  self :))
<hornbeck> plovs: good thinking
<tseng> hornbeck: have you done any beagle packaging, or just a howto?
<hornbeck> tseng: I am still not to sure on packaging
<sivang> anyway guys, I have to go now, I'll see you tonight or tommorow maybe..
<hornbeck> tseng: so just the howto
<hornbeck> I would love to learn to package
<tseng> oh sure
<tseng> google debian new maint guide
<hornbeck> sivang: later
<hornbeck> tseng: I have it bookmarked, just have not really had the time to read all of it
<tseng> ok
<hornbeck> kinda long
<tseng> i suppose.
<hornbeck> I did make a inotify kernel package :-)
<plovs> we need debian packaging in three easy steps, that would be nice
<tseng> hehe make-kpkg
<hornbeck> a couple people said it worked
<hornbeck> tseng: I was proud
<tseng> hm yeah.. i think a simple template will just work for many autotooled apps?
<hornbeck> tseng: as I move along I would like to move more into the developer stage of things
<tseng> i think thom already has dbus-cvs
<hornbeck> nice, I need to get ahold of a copy than
<tseng> http://people.ubuntu.com/~thom/
<hornbeck> I have mine all rigged up
<hornbeck> heh, I already have that in my sources
<tseng> inotify will hopefully make 2.6.10
<hornbeck> I am hoping
<tseng> and just happen in Hoary
<hornbeck> beagle is nice
<hornbeck> I use best to find all the stuff I look for now
<tseng> is there a workable beagle release tarball
<tseng> or just cvs?
<hornbeck> I think just cvs
<tseng> hm that sucks a bit
<hornbeck> cvs has all the new stuff, the only tarball I know of is way outdated
<hornbeck> I could tar the cvs for ya :-)
<tseng> well just trying to figure out a way around autogen.sh
<hornbeck> how come?
* hornbeck might learn something here so he opens tomboy for notes
<tseng> well, ive been using cdbs templates for pkgs
<tseng> and they call ./configure
<hornbeck> well I could send you a already ./autogen'ed package or would that not work?
<tseng> and iirc overriding a cdbs function adds your stuff to the end
<tseng> possibly, i guess if its already autogen'd you can just run a clean configure again
<tseng> i can checkout cvs and do that myself.
<bob2> beagle requires dbus cvs, too
<tseng> we've been over that
<tseng> ~thom
<bob2> ah, right
<tseng> hah
<tseng> "let's build us some beagle shall we?"
<hornbeck> tseng: let me know how it goes
<hornbeck> cause beagle is just so sexy
<tseng> hm so what is the cvs naming scheme
<hornbeck> beagle
<tseng> im looking at dbus+cvs and i dont grok the string
<tseng> no, for packages.
<hornbeck> oh
<hornbeck> I found no dbus-cvs
<hornbeck> it is just dbus
<tseng> _0.22+cvs.$datestamp
<hornbeck> ahh
<hornbeck> well I am going to make some food, be back in a few
<daniels> Kamion: alright, thanks for the insights
<tseng> morn daniels 
<tseng> could anyone point me to a debian cvs snapshot policy
<tseng> hm found.
<bob2> "don't do it (except in experimental)"
<bob2> oh, version
<tseng> well that goes without saying
<bob2> hm, tomboy built fine on ppc
<bob2> do you want the .deb to put in your repository?
<Kamion> the policy manual's bit about version numbers would be the obvious place
<tseng> bob2: sure
<Kamion> section 3.2.1
<tseng> bob2: mxpxpod already sent me muine and something else
<bob2> for ppc/
<tseng> Kamion: ya just found, thanks.
<tseng> yes for ppc
<bob2> hm, didn't see them in your archive
<tseng> ah i have tomboy
<tseng> bob2: didnt upload yet
<bob2> ah, ok
<tseng> i can throw ppc in the same dir, right?
<tseng> bob2: try an update for muine + tomboy
<bob2> they can go in the same dir, just remember to rerun your Package-generation tool
<bob2> cool, thanks!
<tseng> nps
<tseng> bbiab
<tseng> so those dbus+cvs are either not recent enough, or just dont have dbus# bindings
<hornbeck> that is what I ran into I think
<hornbeck> so I just build dbus from cvs
<tseng> ok i will start with that
<hornbeck> good deal
<hornbeck> man it sucks to have to use windows for stuff, I had not installed windows on one of my computers in three years
<hornbeck> and last night had to for school
<mainlylinux> hi azeem
<mainlylinux> I'll move my questions here
<azeem> hi
<mainlylinux> can we make ntpupdate go into the background once it's called?
<mainlylinux> oops ntpdate
<mainlylinux> and call S99gpm sooner in the boot process?
<mainlylinux> am I right that there is no fat32 support in the default kernel?
<Kamion> I don't think you're right there, no
<mainlylinux> I tried to mount -t fat32 and got an error - should I just be using mount -t fat?
<chrisa> vfat
<Kamion> fat32 isn't listed in mount(8) as far as I can see
<mainlylinux> ah
<mainlylinux> gotcha thanks
<mainlylinux> as far as my previous questions about the boot process, is anyone here from the ubuntu-dev team to hear them?
<chrisa> File a wishlist bug perhaps?
<mainlylinux> ok sounds good
<mainlylinux> how about the wiki, anyone here have admin access there?  I want to edit a page that's marked immutable
<Kamion> mainlylinux: you're not logged in
<Kamion> mainlylinux: I think the things you've mentioned are covered in http://wiki.ubuntulinux.org/HoaryHedgehog
<Kamion> " Start gdm earlier
<Kamion> #
<Kamion> Don't try DHCP if we don't have a link beat.
<Kamion>     *
<Kamion>       Double-whammy improvement: you don't get DHCP timing out and trying an old lease when you're not plugged in, and you don't get NTP timing out thus.
<Kamion> "
<kylem> is that really pronounced as 'whorey'?
<mainlylinux> is hoary the next version?
<Kamion> mainlylinux: yes
<Kamion> kylem: that would depend on your accent, I guess :-)
<Kamion> (it's not in mine)
<kylem> hmm.
<sivang> Kamion : have you gotten a rather, vauge email from me lately? :)
<sivang> Kamion : I forgot to state what I was referring there, but it was the gui installer :)
* chrisa chuckles at the part of the hoary wiki that has "Gui installer" listed as a to-do
<Kamion> sivang: yes; have you done any d-i work?
<Kamion> sivang: I'd suggest that Debian would be a better place to learn that than Ubuntu, really; you can be surrounded by far more people who are expert in the installer there
<Kamion> chrisa: ayup
<Kamion> chrisa: may not make it for Hoary, but it's something I've already done some work on
<hornbeck> Kamion: lame question, does d-i stand for debian installer?
<Kamion> hornbeck: yes
<hornbeck> ok thought so
<Kamion> particular implementation rather than just generically "whatever software happens to be responsible for installing Debian", though
<Kamion> the successor to boot-floppies
<srbaker> wonder if dpkg-repackage could be used to do a warty install from livecd
<Kamion> the procedure documented in the installation manual for installing from another Unix system is probably a better idea
<tseng> hm
<tseng> has anyone made a stab at a libdbus-cil ?
<sivang> Kamion : ok, but *you* are one of the known experts as well :)
<Kamion> sivang: I am only one overworked person :-)
<Kamion> I'd much rather have help from people who've already gained experience in the Debian hothouse, because one person is not enough to both teach others and do the work
<Kamion> if we had several installer people already, things might be different
<sivang> Kamion : ok, no prob.
<Kamion> the #debian-boot crew are a nice bunch though
<sivang> Kamion : yes I know :) you once was one of them ;-)
<sivang> Kamion : sorry, that went like something else, I meant you are still one of them hehe
<sivang> basically as I'm coming to understand, Ubuntu is not the place for the less experienced, faint of heart, uninitiated d-i person :)
<Kamion> that's not necessarily true, but right now the gtk frontend is one of the hardest possible places to dive in
<Kamion> my bug list may provide less intimidating introductions :-)
<pitti> mdz: here?
<mdz> pitti: yes
<pitti> mdz: my network was down today, I will deal with gaim now
<mdz> ok
<pitti> mdz: why do the recent security updates appear in the sources list, but not in Packages?
<mdz> pitti: ?
<pitti> mdz: cups/xpdf are compiled and at the mirror, but my apt packages file is still 0 bytes
<mdz> pitti: powerpc?
<pitti> mdz: hmm, odd, the packages file on the mirror has the files..
<pitti> mdz: no, i386
<pitti> mdz: I apt-get updated several times now
<pitti> mdz: does it work for you?
<mdz> pitti: they are there on archive.ubuntu.com
<pitti> mdz: /var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_warty-security_main_binary-i386_Packages is 0 bytes
<pitti> mdz: yes, that's the odd thing
<mdz> pitti: hmm, security.ubuntu.com has two IPs
<mdz> elmo: ?
<pitti> mdz: http://archive.ubuntu.com/ubuntu/dists/warty-security/Contents-i386.gz is empty
<pitti> mdz: is that on purpose?
<mdz> pitti: it probably just hasn't been generated yet; Contents is not very important
<mdz> I think it happens once per week or something?
<pitti> mdz: hmm, still this is quite odd... apt-get update should update the package index
<pitti> mdz: well, if it works for you, I will investigate this on my side
<elmo> -rw-rw-r--    1 archvsync archvsync     3648 2004-10-23 03:08 /srv/ftp.root/ubuntu/dists/warty-security/main/binary-i386/Packages.gz
<elmo> -rw-rw-r--    1 archvsync archvsync     3648 Oct 23 03:08 /srv/ftp.root/ubuntu/dists/warty-security/main/binary-i386/Packages.gz
<mdz> elmo: wondering why security.ubuntu.com points to both .138 and .155
<elmo> look fine to me
<mdz> and what .155 is
<carlos> it works also here (ppc), I think I got them yesterday
<elmo> mdz: we round-robined stuff in preparation for the release.  we had to undo archive.ubuntu.com 'cos people we're using it to reach cdimages which we don't have the space for on mirnyy
<mdz> yes, it is certainly working in general
<elmo> 155 is mirnyy
<elmo> aka releases.u.c
<mdz> elmo: and the security mirror on mirnyy is up to date?
<elmo> yes
<elmo> that's the two lines I pasted above
<mdz> ok
<elmo> auckland and mirnyy
<mdz> pitti: no idea what your problem is
<T-Bone> mako: ping?
<pitti> mdz: okay, thanks; I'll investigate further
<mako> T-Bone: hey there
<T-Bone> hey mako
<tseng> hm, should dbus-sharp be called libdbus-cil ?
<hornbeck> tseng: it would fit the other's than
<tseng> yesm
<mako> T-Bone: whats up
<pitti> mdz: https://chinstrap.warthogs.hbd.com/~pitti/ has an updated gaim package and an interdiff (with a very verbose changelog)
<pitti> mdz: Debian already has 1.0.2, so it does not need a patch 
<pitti> mdz: is there any more formal staging area for such updates for you to approve?
<mdz> pitti: I am happy for you to upload them to the security queue immediately
<mdz> pitti: I prefer to test the official binaries anyway
<mdz> they are not published until amber is run
<pitti> mdz: okay, here we go; uploaded
<pitti> mdz: can you just remove the upload from the queue if there was sth wrong?
<mdz> pitti: no, but we can supersede it trivially with a new upload
<pitti> mdz: ah, okay
<pitti> mdz: it would be nice to have a staging area that is already autobuilt while waiting for approval
<mdz> pitti: that is essentially what it is
<mdz> they are autobuilt as soon as you upload them
<pitti> mdz: elmo said that I should not upload unapproved updates
<Keybuk> mdz: btw, what's the warty-updates distribution for?
<mdz> Keybuk: non-security bugfixes for stable
<Keybuk> but we've not documented that anywhere, and warty hasn't been shipped with any mention of it in /etc/apt/sources.list
<mdz> pitti: as long as you get the version numbering right, pretty much anything else can be fixed trivially
<mdz> Keybuk: it's also empty
<Keybuk> in fact, the comment in sources.list specifically seems to say that the ordinary warty archive is going to get the updates
<mdz> Keybuk: it does?
<Keybuk> it does how I read it
<mdz> Keybuk: if you think it needs clarification, file a bug against base-config with suggested text
<Keybuk> the way we've set it up now, I don't think we *can* use warty-updates
<Keybuk> if we were going to do that, we should've shipped warty with it in sources.list
<mdz> Keybuk: it's no different than proposed-updates
<mdz> it's opt-in
<Keybuk> do the updates end up in warty when approved?
<mdz> no
<Keybuk> so warty isn't getting any bug fixes?
<mdz> "warty" / Ubuntu 4.10 is static
<mdz> according to sabdfl there shall be no point releases
<Keybuk> right, I misunderstood that then :)
<Keybuk> I assumed we were still going to do occasional major-bug fixes to it
<mdz> we will, but they'll be kept separate
<Keybuk> fair enough I guess; would've still been nice to document this somewhere for users :o)
<__daniel> re
<sabdfl> Keybuk: yes, we should have mentioned warty-updates in sources.list, i didn't realise the distinction myself until after release
<sabdfl> but mdz is right: security-updates only will generate better trust with sysadmins
<sabdfl> and with our regular release schedule a point release of warty seems silly unless it's a disastrous bug we have to fix
<sabdfl> what we might do, if warty-updates keeps making warty better, is release warty again when hoary goes out, as "enterprise grade", but we've not really put any thought into the work required to keep fixing bugs in warty, and no clear idea how to fund that sustainably
<Kamion> enterprise-grade> the five-year thing?
<pitti> sjoerd: Hey, pmount already made it through NEW. That was quick...
<pitti> sjoerd: it should go into the archive with tomorrow's katie run
<sjoerd> pitti: saw it.. hal 0.4.0 made it too 
<pitti> sjoerd: oh, nice
<pitti> sjoerd: let the future begin :-)
<Kamion> #2698 is kind of d'oh; fortunately not critical ...
<sjoerd> pitti: g-v-m 1.0.2 is going to sarge tonight too 
#ubuntu-devel 2004-11-05
<mdz> Kamion: warty has bigger warts than that :-)
<lucas_> Hi, is there some info somewhere on the wiki about how to build custom distribs based on ubuntu ?
<tseng> lucas_: i think thats a goal of hoary
<Kamion> mdz: oh yeah
<lucas_> tseng: arg, not before hoary ? I would have liked to build a warty-derivate ...
<mdz> lucas_: you can certainly derive from warty if you would like
<mdz> there is no step-by-step howto
<lucas_> mdz: who could give me an overview of how to build a derivate that only adds a dozen of packages ?
* Kamion wonders vaguely if such a person exists yet. :-)
<mdz> lucas_: it would be very nearly the same process as building a Debian derivative
<lucas_> if I knew how to build a debian derivate, I wouldn't be there asking :)
<Kamion> the archives of the debian-custom mailing list may have useful information
<Kamion> I think there's a "debian-cdd" howto (or some such name)
<jdub> pants off dudes
<tseng> zi[
<tseng> *p
* Kamion squirts a water pistol at jdub
<lucas_> ok, thanks for the pointer
<jdub> ow! morning! cold!
<mdz> I think I am learning about this "cold"
<mdz> it was only ~16C yesterday
<Kamion> wuss
<mdz> I had to wear sleeves!
* mdz gathers firewood frantically
<jdub> rock, the dude who ITPed ifolder has passed it over :)
<Mitario> lo everyone
<mjg59> jdub: Make ifolder non-sucky
<jdub> tberman is helping with that
<jdub> hey Mitario 
<tseng> or use epittance instead
<jdub> it performs a different function
* jdub will look at it more after someone like alexl gets his mitts on it
<tseng> 1
<tseng> i think beagle cvs is broken atm, make in the top dir does nothing.
<tseng> so much for packaging
<pitti> Night
<mdz> Kamion: which d-i bit creates /sbin/unconfigured.sh?
<lucas_> mdz: which d-i bit copies all .deb from the cdrom to the HD ?
<elmo_> archive-copier
<lucas_> I thought it was archive-copier, but I read its code
<lucas_> from the code and apt-cdrom's manpage, it only adds the cdrom entry in /etc/apt/sources.list
<lucas_> was apt-cdrom hacked to change that ?
<tseng> bob2: i see the syntax error in tomboy now
<lucas_> elmo: I read the apt-cdrom source code and still can't find a place where it copies the .deb to the HD.
<tseng> hornbeck: finishing up libdbus-cil pkg now
<tseng> hornbeck: care to test on a clean box?
<mdz> lucas_: apt-cdrom does not do any copying. archive-copier does
<lucas_> oh, got it
<lucas_> I was only reading the "prebaseconfig" script
<lucas_> postinst makes more sense :)
<hornbeck> tseng: yes I would like to try it
<hornbeck> is it in your repos?
<tseng> one moment
<tseng> and not on the box you already installed dbus from cvs on
<tseng> since we wont easily know if the dep is filled by the package, or something you installed already
<tseng> eg, do we need anything more than the dll's
<hornbeck> tseng: I do not think so, I could be wrong though
<hornbeck> its rare but it has been known to happen :)
<tseng> hm i guess it needs the .pc also
<tseng> oops
<tseng> daniels: ping
<lucas_> mdz: which bit of d-i installs the packages in ubuntu-desktop but not in base after the reboot ?
<mdz> lucas_: base-config
<lucas_> oh ok
<tseng> hornbeck: libdbus-cil is in my repo, with all the +cvs dbus stuff
<tseng> hornbeck: i took it from thom so im not sure if it is new enough for beagle.. dated 10/7
<hornbeck> tseng: I will check in alittle while
<hornbeck> I am doing school work right now
<hornbeck> any clue why blam resets to defaults everytime it launches?
<lucas_> ok, I now have a much clearer view of how d-i works. I'll write a nice howto if I succeed in building an Ubuntu-derivate =) thanks for answering my questions ; good night.
<tseng> oh hornbeck 
<tseng> could you send me that tarball after all, my cvs checkout seems b0rk
<tseng> when you have a chance that is
<__daniel> sleep tight
<hornbeck> yeah tseng
<hornbeck> can I get a mail for you
<tseng> brandon@smarterits.com
<hornbeck> on its way
<hornbeck> evolution is crapping out on sending attachments
<hornbeck> will try to send from other account
<hornbeck> tseng: now it is on its way
<tseng> hornbeck: er dude
<tseng> i meant beagle
<tseng> did i say dbus?
<hornbeck> haha, yeah
<hornbeck> ok I will send beagle
<tseng> thanks
<hornbeck> tseng: now that one is on its way
<tseng> great
<hornbeck> tseng: you should shoot for a gecko-sharp-0.6 also :-)
<tseng> perhaps
<hornbeck> nice
<srbaker_> okay, after a full day of ubuntu on my laptop, i'm even more impressed than before.  great work, guys
<mdz> thanks
<jdub> "
<jdub> i've done with install snd_via82xx /bin/true"
<jdub> ^ eeeeeek!
<lamont> jdub/mdz: I think rc2 == release.  thoughts?
<hornbeck> kinda neat how when you move around the website you are logged in one page than not another, good way to keep people from being able to do anything
<hornbeck> hmmm
<mdz> hornbeck: you can use https://site-edit.ubuntulinux.org/ until that's fixed
<hornbeck> mdz: thanks
<hornbeck> man that is way to complicated
<srbaker_> anyone know how i can find out when to expect ubuntu cds?  i'm planning our LUG meeting, and i want to know which one my "introduction to ubuntu" talk (with cds) will take place
<mdz> hornbeck: it's a bug
<mdz> lamont: I think we have no choice :-)
<mdz> srbaker_: http://lists.ubuntu.com/archives/ubuntu-users/2004-October/007832.html
* mdz gleefully closes an FTBFS-on-m68k bug
<mdz> aw, daniels beat me to it
<lamont> mdz: true, I think there are bugs that would be nice to have fixed, but I think they mostly come back to hwdetection diffs and minifo :-(
<daniels> mdz: quick draw, yo
<fabbione> morning guys
<daniels> morning papa fabbione
<hornbeck> good morning
<hornbeck> night here :-)
<fabbione> hey kid
<fabbione> daniels: we will probably have a kitchen the first week you will be here :-)))
<daniels> awesome!
<fabbione> and hopefully the bigger office during the second one
<daniels> your timezone shift is bad, dude
<fabbione> i know
<fabbione> it's not like i am having fun waking up at 5 am every day
<amu> ;) 
<fabbione> amu: you are not supposed to be awake either ;)
<amu> fabbione: correct, i lie straight on a slopematte in the southseas, 2 pretty girls make breakfast for me, wow i dream stilD[D[D[D[Dl 
<fabbione> amu: eheheh
<doko> morning fabbione, did you get the debhelper things working?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion and support on #ubuntu | Happy Hoary Trail! | BE THE SIGNAL | Warty release is DONE | Hoary kickoff meeting Monday, 2004-10-25 1600UTC in #ubuntu-meeting
<fabbione> xmlconfig.c:912: error: `program_invocation_short_name' undeclared (first use in this function)
<fabbione> and errno.h is included
<fabbione> what am I missing here?
<Keybuk> #define __USE_GNU ?
<daniels> Keybuk: er, _GNU_SOURCE?
<Keybuk> Redhat found a vulnerability in fileutils (ls and mkdir), that could allow a remote attacker to execute arbitrary code with root privileges.
<Keybuk> ^ ouch
<Keybuk> though highly odd *how* you'd do that without making ls or mkdir setuid root
<Keybuk> Received: from 2ens11.uta.edu (2ens11.uta.edu [129.107.2.122] ) by
<Keybuk>         menubar.gnome.org (Postfix) with ESMTP id 951303B0D8A for
<Keybuk>         <gnome-announce-list@gnome.org>; Sun, 24 Oct 2004 18:00:13 -0400 (EDT)
* Keybuk decides that mail is highly suspicious
<daniels> Keybuk: also, Red Hat know how to spell their company name
<Keybuk> also the instructions are to untar, build and install a random tar file
<Keybuk> RH ship security updates as RPM
<daniels> interestingly, they ship 'fileutils-patch.bin' in that tarfile
<daniels> which is an RPM
<Keybuk> ah yes, bit red notice on RH.com
<fabbione> daniels, Keybuk: thanks...
<fabbione> i wonder more why it wasn't set automatically
<Keybuk> fabbione: you have to set it to say you're happy that your code is no longer C99/POSIX/blah and you're happy about that
<daniels> also, _BSD_SOURCE, _POSIX_SOURCE, and _XOPEN_SOURCE
<daniels> the latter two accept numbers as to your level of posix/x/openness
<fabbione> hmm
<fabbione> the only lib complaining about it is libgl
<fabbione> i wonder if others are affected too
<fabbione> Keybuk: this is dri (black magic wodoo) stuff
<fabbione> very difficult to say
<daniels> ehm
<fabbione> daniels: what do you think about confining the -D_GNU_SOURCE to libgl ?
<daniels> you know how I worked out which flags most modular libs used?
<daniels> buildd.d.o
<daniels> if you can do per-file cflags in imake, even better
<daniels> maybe even just a #define _GNU_SOURCE rather than -D
<fabbione> daniels: yes i can do that
<fabbione> daniels: btw.. all these little changes are just because of -DUseInstalled
<fabbione> a real pain in the butt
<fabbione> and it needs to be done at Imake level
<fabbione> but i can still confine it to that specific dir
<fabbione> there is no need to force it on the entire lib
<daniels> fabbione: building mesa/glx and the server separately is a huge pain in the arse
<daniels> right now you can't do it and keep dri
<daniels> that's why my monolithic tree still contains lib/GL and extras/Mesa
<daniels> (also, Xfont is really bizzaro, but that's another story)
<fabbione> daniels: yes i know they circular build-dep
<fabbione> i already have the xserver source tree as dependency
<daniels> hm
<fabbione> right now libgl is the worst crap i have seen in terms of Imakefile
<jdub> i'm glad you guys can bond over X horrors
<daniels> fabbione: isn't it great?
<daniels> jdub: sort of like old war stories
<fabbione> jdub: all this stuff is coming out because we are splitting the tree
<jdub> YAY!
<daniels> 'and then there was the time I realised half of the XKB code was probably exploitable if someone tried hard enough'
<fabbione> daniels: yes, but that doesn't scare me too much
<fabbione> jdub: as i already told Mark, the amount of work is much higher than what i planned in the beginning
<fabbione> jdub: unfortunatly i realized it later
<fabbione> but we will do our best
<sladen> daniels: ''But I just typed "2*&)$}{;')(*!" at the keyboard..''
<vorlon> daniels: so how did you happen upon the Boeing glider story?
* vorlon had never heard that the mechanics ran out of gas on the way there, though, that's hilarious. :)
<Keybuk> yeah was reading that, is a good telling of it :o)
<Keybuk> I first heard about it reading some racetrack trivia stuff
<daniels> vorlon: chris blizzard linked to it on his blog
<vorlon> ah. :)
<Keybuk> there's several examples of races being interrupted by planes doing emergency landings (lots of race tracks are old airfields), but that's the only one which was a commerical liner
* vorlon had heard about it because his dad is a glider pilot; the story was occasionally brought up as an "and that's why all commercial airline pilots should have to learn to fly gliders", when in reality it's a "and that's why airlines should ground planes that are suffering computer failures" ;)
<jdub> although, knowing your pilot can glide the plane in if there's a problem is kinda nice
<lifeless> depends on the plane really :)
<vorlon> sure, though they showed that the glide ratio on those things really is lousy, and there aren't all that many airline pilots who do know how to fly gliders. :)
<jdub> dude, if it's a 747-400, i still want to know the guy can glide it
<Keybuk> indeed; the natural state for an out-of-fuel jetliner is "crater"
<Keybuk> Silverstone is pretty fantastic for that; it's still an in-use airfield as well as a F1 Grand Prix race track -- on race day a fleet of helicopters arrives and lands in the middle of the track as all the rich kids get around the parking problems
<fabbione> Keybuk: how was the race yesterday?
<fabbione> i don't have a TV yet :)
<Keybuk> fabbione: got a bit wet, but no major casualties
<fabbione> who won?
<Keybuk> Montoya
<fabbione> argh
<Keybuk> Kimi 2, Barichello 3
<fabbione> schummy?
<Keybuk> somewhere a little way back, he toasted his car in the wall during practice so had to take an engine change
<daniels> montoya!
<Keybuk> fabbione: you seen the rule changes for 2005 yet?
<fabbione> Keybuk: nope.. i only read the one you posted here
<fabbione> about no tyres change during the race
<fabbione> that is going to be sooooo boring
<Keybuk> front wing height and rear wing size reduced; so will be interesting whether we'll see 1980-era wings-fixed-to-noses again
<fabbione> i hope there is at least the exception in case of rain/dry weather
<jdub> Keybuk: you'd land a plane on alicia silverstone? bastardo!
<Keybuk> no tyre changes during race (except for environmental conditions)
<Keybuk> in fact, same tyres have to last for both Qualy *and* the race
<fabbione> amen
<fabbione> we will see more cars out with falt tyres than anything else
<Keybuk> which is interesting that they didn't forbid refuelling as well; because the pit boys won't have much to do now
<Keybuk> engines have to last for two race weekends, not just one
<fabbione> so if one engine blows up
<Keybuk> 9/10 teams want to eliminate tyre testing entirely, so effectively use standardised tyres for all teams
<fabbione> you are out for 2 races
<Keybuk> fabbione: no, just have to take a 10-position penalty
<fabbione> bah that sucks
<Keybuk> 9/10 teams want to reduce testing to just 10 days throughout the entire season
<fabbione> it's getting to complicate
<Keybuk> Qualy is going to be Saturday afternoon for a first low-fuel run in previous race finishing order
<Keybuk> then on Sunday morning, they'll run again with race fuel in reverse order of previous finishing
<Keybuk> Position will be based on an aggregate of both times
<fabbione> why don't they just use /dev/urandom?
<fabbione> it will save them tons of headackes
<Keybuk> heh, I still think they should go back to the *original* Qualy format, but with the addition that you have to run laps in 15 minute windows (to prevent everyone going out with 10 minutes left on the clock)
<sivang> morning all
<Keybuk> next year's going to be kinda interesting
<fabbione> Keybuk: i think they should go back to the original. that's it.. same as it was at Prost and Senna time
<fabbione> hi sivang 
<Keybuk> Minardi are probably safe, they have their own engines they can run
<Keybuk> Jordan are probably safe, they are rumoured to be running Toyota engines next year
<sivang> fabbione : morning, how are you? :)
<Keybuk> Jaguar are still in the shit though, no buyer yet
<fabbione> sivang: fine thank and you?
<fabbione> Keybuk: too bad...
<Keybuk> fabbione: will be amusing, because Ferrari will have to run a third car if they drop out
<fabbione> i wonder when they will allow more than 2 cars x team
<fabbione> Keybuk: uh why?
<Keybuk> it's not a matter of "allow", it'll be a requirement for the top teams
<Keybuk> F1 rules state a minimum of 20 cars must run
<fabbione> ahhh
<Keybuk> the third car won't be a points-scorer
<Keybuk> so if you happen to be in the third Ferrari, you don't count
<fabbione> and what's the point of having a third car than?
<fabbione> just to fill up the grid?
<sivang> fabbione : not bad at all, I see it's race car discussion day? :)
<lifeless> thaytan: you shrink you
<Keybuk> it counts for the driver, not the teeam
<lifeless> bah. sorry
<fabbione> sivang: well yeah.. i don't have a tv yet in the new house
<fabbione> and Keybuk is updating me
<Keybuk> though I think it'd be sweet if they let Jordan and Minardi have the third cars, and be points-scorers :)
<fabbione> Keybuk: understandable... will the team decide which cars will bring points to the team or they will pick the 2 highest score for each race?
<Keybuk> 2 highest runners, I believe
<sivang> fabbione : don't major sports channels broadcast on the internet as well?
<Keybuk> though Brundle was being cynical and suggesting that a Ferrari 1, 2, 3 is the last thing the sport needs next year :o)
<Keybuk> sivang: no, F1 isn't net-broadcast
<sivang> Keybuk : this is an european exlusive sport channel I suppose? (I know Eurosport, ESPN for the states etc)
<Keybuk> sivang: F1 = FIA Formula 1
<sivang> Keybuk : Ah so that's the famous formula 1 races , those are better watched from within the audience ;)
<fabbione> Keybuk: ahahah that would own the F1.. Ferrari 1 2 3 :P
<Keybuk> actually, I tend to disagree there ... they are fantastic to attend; but you get a better race if you watch at home
<fabbione> yeah
<fabbione> you don't see anything at the race
<fabbione> it gets too messy
<daniels> it's way too much to go here
<daniels> prices start at about $au450 or so
<Keybuk> fabbione: not really likely though, Ferrari are notably mid-field at the moment -- all the other teams have caught up; even Schumy is notably off-pace
<Keybuk> it's almost as if he's bored, he's made silly mistakes in the last several races
<fabbione> Keybuk: yeah well... he is demotivated after winning the championship
<Keybuk> which is odd for Michael, he's normally even more motivated afterwards and just driving for fun
<Keybuk> he is the "oldest man in F1" now ... though I give him a few more years yet, I expect we're starting to see the peak of his career
<fabbione> yeah i agree
<Keybuk> still waiting to see who'll be in the 2nd Williams
<Keybuk> and, if they have to, 3rd Ferrari and BAR
<Keybuk> (I guess the latter will be Anthony Davidson)
<fabbione> probably Fittipaldi?
<fabbione> isn't he the test driver for Ferrari?
<Keybuk> no idea
<daniels> yay Webber
<fabbione> make[1] : Leaving directory `/usr/src/xorg/xorg-lib-gl-6.8.1/build-tree/xc/lib/GL'
<fabbione> touch stampdir/build
<fabbione> YES
<fabbione> finally
<fabbione> daniels: isn't about time to sign my gpg keys?
<jdub> fabbione: last time i asked daniels about signing your key, he said he wasn't sure that you really were 'Fabio, The Most Beautiful Man In The World'
* vorlon vouches for fabbione's beauty
<fabbione> jdub: you didn't even want to exchange id's with me :(
<fabbione> vorlon: eheh
<jdub> fabbione: we've already exchanged, haven't we? at the original uk meeting
<fabbione> jdub: only for one of my key
<fabbione> i am searching sigs for my new shiny 4096RSA key and the canonical key ;)
<fabbione> gpg --list-sigs fabbione@fabbione.net |grep Jeff
<fabbione> $
<fabbione> so that means that even if we exachanged... you didn't sign
<fabbione> ;)
<jdub> i didn't ;)
<fabbione> you suck :P
<pitti> Morning
<daniels> heh
<daniels> yeah, i should probably sign keys from oxford ... and akademy ... and ols ... and lca ...
<aj> heh, i should probably sign keys from lca ... 2001
<fabbione> aj: and debconf4 :-)
<fabbione> or was it 3?
<fabbione> the one in Olso..
<fabbione> olso
<fabbione> OSLO
<fabbione> ok
<daniels> 3 was oslo, 4 was brazil
<fabbione> daniels: is there actually any reason why we build libgl1.2 when 1.4 is available in debian?
<fabbione> usr/lib/libGL.so.1.4.500                                    libs/mesag3,libs/mesag3-glide2,libs/mesag3+ggi
<daniels> fabbione: yeah -- mesa built independently from X is incapable of direct rendering
<daniels> only software
<daniels> working on using debian's mesa on a branch was what got me kicked out of the XSF the first time :P
<Gmail> in how many hr is the meeting?
<Gmail> i want to getready
<Gmail> but i think its in 8hrs
<fabbione> daniels: ok... and do you happen to remember why there is a /usr/lib/libGL link to /usr/X11R6/lib/libGL ?
<daniels> probably because people suck and hardcoded the path
* fabbione is extremely tempted to kill it
<daniels> fabbione: just like the rest of /usr/X11R6 :)
<fabbione> daniels: eh the libgl1 stuff is complex
<daniels> hm?
<fabbione> because libgl1 is a virtual package provided by several other packages
<fabbione> there is all a rationale behind it
<fabbione> it's in debian/changelog
<daniels> yeah
<fabbione> that also means that i cannot call the package libgl1
<daniels> oh, right
<fabbione> and that seriously SUCKS HARD
<daniels> so you're saying there's a /usr/lib/libGL->/usr/X11R6/lib/libgl link?
<fabbione> daniels: there is a link because that link is handled by different packages as far as i can see
<fabbione> so yes.. it needs to stay as symlink
<daniels> /usr/lib/X11/libGL.so
<daniels> hey, wait ...
* fabbione is seriously disappointed by this GL mess
<daniels> mmm
<daniels> they're trying to fix that upstream, so mesa will be capable of direct rendering when built separately
<fabbione> daniels: i think i will keep the same name schema we have in Debian now.. even if i think it sucks
<fabbione> xlibmesa-* has nothing to do with libgl
<fabbione> but that's the easiest i think
<daniels> i don't really like xlibmesa
<daniels> i would personally prefer libgl1-xorg
<fabbione> or xorg-libgl1
<fabbione> that is slightly more coherent with all the other packages
<fabbione> like 171 xorg-source-*
<fabbione> ;)
<fabbione> Package: xorg-libgl1
<fabbione> Package: xorg-libgl-dev
<fabbione> Package: xorg-libgl-dri
<fabbione> ehm
<fabbione> libgl1-dri
<daniels> mmm, but libgl1-* is far more compliant with standard naming scheme's
<daniels> x's is total bong
<daniels> (the xlib* mess being a bad hangover)
<daniels> s/scheme's/schemes/
<daniels> also, libgl1-dri is bad because we're not actually dri
<daniels> that's dri.sf.net
<daniels> so i propose libgl1-xorg, but your call
<fabbione> let's keep it as xorg-libgl*
<fabbione> we can easily change it later
<daniels> fabbione: hm
<fabbione> there is the same mess with xorg-libosmesa
<daniels> fabbione: as i said, your call
<fabbione> daniels: as i said.. it's a detail right now
<daniels> but in my packages, it's libgl1-xorg, libosmesa4-xorg, et al
<daniels> yeah
<fabbione> we can change later ;)
<daniels> we can fight it out in denmark :)
<fabbione> daniels: the ring is ready.. time for the cage :P
<daniels> heh
<__daniel> hai
<Keybuk> 1,320 changesets for warty
<fabbione> daniels: can you gice me the output of objdump --all-headers libGL.so.1.2 | grep TEXTREL on your libGL ?
<fabbione> s/gice/give
<fabbione> and on libosmesa4
<fabbione> hey sabdfl 
<daniels> fabbione: there should be no TEXTREL -- see my make libGL PIC-compliant patch
<fabbione> daniels: that's what i was searching for
<daniels> i have no TEXTREL here
<daniels> but yeah, I wrote a patch to make GL PIC-compliant
<daniels> anyway, dinnertime
<fabbione> yeah it didn't apply clean.. i will check it again
<fabbione> i remember the first time i didn't do it deeply
<daniels> jakub jelinek did a better one, might be applied now
<daniels> that will make gl *significantly* *quicker*
<daniels> anyway, dinner
<sabdfl> hiya fabbione
<Kamion> mdz: d-i doesn't create /sbin/unconfigured.sh; that's a boot-floppies thing
<Kamion> mdz: instead, /etc/inittab is just set to run base-config until base-config rewrites it not to do that
* fabbione starts to wonder if do we really have to support GL
<daniels> fabbione: that's the unfortunate reality
<fabbione> daniels: i rediffed your patch and now libGL is PIC compliant
<daniels> cool
<fabbione> but libosmesa4 isn't
<daniels> yeah, that probably still needs doing
<fabbione> and probably your version isn't linked properly either
<fabbione> the Imake is missing a REQUIREDLIBS = MathLibrary
<fabbione> i start to eat Imakefiles for breakfast
<daniels> yeah, that's a patch from Gentoo I never got to integrating
<daniels> their BTS has a few patches to practically eliminate all weak references
<daniels> i was working on debrix at that stage, and couldn't be arsed dealing with Branden to get it into the Debian tree
<fabbione> the debian patch applie on xfree86 but not x.org
<daniels> which debian patch?
<fabbione> ok fixed
<fabbione> the 062_
<fabbione> is the same you geve to me
<daniels> the libGL PIC one?
<fabbione> gave to me
<fabbione> yes
<daniels> right
<fabbione> that one doesn't apply to x.org
<fabbione> and i rediffed
<daniels> hmm
<fabbione> now it is ok
<fabbione> also
<daniels> rad
<fabbione> libosmesa was ranting about TEXTREL because it was not properly linked with MathLibrary
<fabbione> so that is fixed too
<daniels> cool
<fabbione> hmm no hold on
<fabbione> i used the wrong the script for the PIC
* fabbione sighs
<fabbione> at least it is linked properly
<daniels> http://dev.gentoo.org/~spyderous/xfree/patchsets/4.3.0/patch-2.1.17/0192_all_4.3.0-missing-lib-sharedreqs.patch
<daniels> that's a small part of the patch
<daniels> http://dev.gentoo.org/~spyderous/xorg-x11/patchsets/6.8.0/patch/0130_all_4.2.1-fix-shared-libXau-link.v2.patch
<daniels> you'll want that if you want a shared Xau lib (I want a shared Xau lib)
<fabbione> we already have a share libXau
<fabbione> the last patch is only partially true
<fabbione> s/true/correct
<fabbione> anyway
<fabbione> the pic problem is still there
<fabbione> and it's not a link issue
<fabbione> these are easy to fix
<daniels> yeah
<daniels> gl pic is a bitch
<daniels> and when you do get it right, you lose arseloads of performance
<fabbione> GL is PIC now
<fabbione> we only miss libosmesa4
<daniels> mmm
<aj> yo, keybuk!
<Keybuk> aj: hey
<aj> l33t
<fabbione> is there a generic way to find code that makes a lib non-pic?
<aj> hrm, now i should find that bugnumber
<Keybuk> fabbione: not easily
<Keybuk> grepping the resulting assembler *shrug*
<aj> Keybuk: Bug 62529 -- what're the chances of getting something done about it?
<fabbione> Keybuk: ok....
<fabbione> well... almost
<Keybuk> aj: reasonably high, I think that's one I read over the weekend
<aj> yeah, you did
<aj> or someone pretending to be you set it to wishlist, anyway
<Keybuk> I favour the "does the -revision contain .0.x" trick
<Keybuk> it's one lamont and elmo keep poking me about :)  so expect it to be one of the first bugs fixed once sarge has its translation update release
<aj> goodo
<aj> i'll see if i can get kamion to poke you about it too
<Kamion> Keybuk: (consider yourself poked)
* daniels pokes Keybuk, for the hell of it.
<daniels> (all the cool kids are doing it)
* Keybuk pokes daniels back
<Kamion> Keybuk: might be worth going over queue/done to check whether any sourceful uploads in the last <whatever> have been versioned .0.x
<Kamion> oh, .0.x doesn't work, binNMUs of sourceful NMUs are .1.x etc.
<Keybuk> Kamion: there are a few upstream examples (usually bpb) but seeing as policy says .0.x in the revision is a bin-nmu, I think anyone who does it is silly
<Kamion> doesn't work on its own, anyway
<Keybuk> Kamion: elaborate?
<Kamion> MU 1.0-2, sourceful NMU 1.0-2.1, binNMU 1.0-2.1.1
<Keybuk> why 1.1 ?
<Kamion> because -2.0.1 would be less than -2.1 and -2.1.0.1 would be excessively long?
<daniels> Keybuk: rebuild of 2.1
<daniels> hence, 2.1.1
<Kamion> I think the idea is third level of Debian revision = recompile
<Kamion> dunno, just know it's historical fact :)
<Keybuk> I get worried about not making it *look* magic
<Keybuk> .0.x is pretty rare
<Keybuk> .1.x is common for general usage
<Kamion> I'm just observing what people have historically done
<Kamion> also, katie supports .<whatever>.<whatever>
<Kamion> re_bin_only_nmu_of_mu = re.compile("\.\d+\.\d+$");
<Kamion> re_bin_only_nmu_of_nmu = re.compile("\.\d+$");
<Kamion> all I'm saying is it'd be worth checking queue/done, since people do all sorts of weird shit and it might be worth choosing something with maximal weird-shit deflection potential :-)
<daniels> heh :)
<daniels> the software design metric of the future!
<aj> Keybuk: feel free to make up your own magic, like .recN, or .0.N$ or something different
<aj> Keybuk: we can always just REJECT anything that doesn't match the magic
* Keybuk hunts for a spare character on the keyboard <g>
<aj> new characters would be bad, though; cf ~...
<Keybuk> at least ~ actually makes sense
<Keybuk> cf. patch, diff -ru foo-1.0~ foo-1.0
<aj> yeah, but it's a nuisance trying to get it to actually work
<Keybuk> hrm, ".." could be cute foo_1.0-1..1
<aj> eww! that so gross!
<Keybuk> <g>
<aj> eww, only [0-9A-z+.]  to play with
<aj> .0+1?
<Keybuk> + tends to get used for what ~ is intended for
<Keybuk> 1.0-1+but.really+0.99.1
<Keybuk> * Not changed: geda-gschem  ... (ugh, that's a horrible package name)
<aj> ajt@newraff:~/queue/done$ find | grep -- '-.*\.0+1_' | wc -l
<aj>       0
<Keybuk> aj: that's certainly a useful idea then
<aj> foo_1.0-1.0+1 would work
<aj> *shrug* i'm happy if you break things though, REJECTing is easy :)
<aj> anything that actually gets implemented gets my vote
<Keybuk> are there any in queue/done that end in "+\d*" ?
<Keybuk> upstream included
<aj> ./2002/11/28/openoffice.org-debian-files_1.0.1-6+1_i386.changes
<aj> ./2002/03/05/cfdisk-utf8_2.11n-5+1_powerpc.changes
<aj> ./2002/04/07/alsa-modules-2.4.18-i386_0.9+0beta12+3+2.4.18+4+1_i386.changes
<aj> ./mutt_1.5.6-20040907+1_powerpc.changes
<aj> ./vim_6.3-025+1_arm.changes
<sivang> mantis will be used by ubuntu after bugzilla?
<aj> ./2002/03/04/tetex-bin_1.0.7+20011202-5_i386.changes
<Keybuk> *nods* I'll bounce off lamont when he wakes up and see if he has any opinions
<aj> "rc+\d" doesn't match anything, so foo_1.0-1.rc+1 would work too
<Keybuk> "rc" ?
<aj> +rc1 matches release candidates otoh
<aj> ReCompile
<Keybuk> yeah I read "rc" as "Release Candidate"
<aj> rb+1 for rebuild, maybe
<aj> +rb\d works too
<Keybuk> I like the +<something>\d+ form ... foo_1.0-1.1+rebuild3 ... kinda reads as "and 3 rebuilds"
<azeem> 'rebuild' is relatively short so it could be spelt out, IMHO
<azeem> doesn't make people like me wonder what it means, as e.g. with 'ds'
<Keybuk> it doesn't really matter too much, as it's not important for anyone but buildd freaks :)
<Keybuk> aj: is +b\d used?
<aj> no +b\d
<Keybuk> cool, that's reasonably short
<mvo_> hi seb128 
<sid77> hi all
* sid77 is away: Far from here (close to you)
<fabbione> daniels: ping
<daniels> pong
<daniels> fabbione: 2676 is yours
<fabbione> daniels: i was talking with Overfiend right now
<fabbione> he wrote that section of policy about */X11
<fabbione> and he said that we can go as we like
<daniels> awesome
<fabbione> that means no X11R6
<daniels> right
<daniels> remember you're the maintainer, ultimately -- /usr and /usr/X11R6 is your call
<daniels> you know my opinion by now, I'm sure :)
<fabbione> daniels: yes i know your opinion
<fabbione> right now i want to get libgl out of my way
<fabbione> but the problem is still that TEXTREL
<fabbione> and i can't find the piece of code generating it
<fabbione> osmesa.c includes 3 tons of crap
<daniels> crap
<daniels> yeah
<fabbione>  * \file imports.h
<fabbione> it seems to be the one at fault
<fabbione> ./extras/Mesa/src/mesa/main/glheader.h
<fabbione> ./extras/Mesa/src/mesa/main/imports.h
* sid77 is back (gone 00:21:16)
<daniels> sid77: please turn off public away
<lamont> moo
<lamont> Keybuk: what version number?
<Keybuk> lamont: we were discussing bin-nmus
<Keybuk> the idea that dpkg could recognise a certain form of version number, and generate the changes so it's missing the bit at the end in the Source: header
<fabbione> daniels: i think i found a solution to the TEXTREL
<daniels> fabbione: wassat?
<fabbione> but it's going to impact performance. there is no other way around
<fabbione> check imports.g
<fabbione> ehm .h
<daniels> all our PIC changes have killed performance
<daniels> i'm not sitting at a computer with an unpacked tree right now
<fabbione> it has several specific asm definition
<daniels> right
<fabbione> and also a generic portable C one
<fabbione> so it's question of do in such a way that it will compile the generic one
<fabbione> always
<daniels> hm
<daniels> personally I'd be shooting to make the ASM PIC-compliant
<lamont> Keybuk: .0.N is kinda defacto, you know.
<Keybuk> lamont: except Kamion was saying it wasn't, and that when a source-NMU has been done, you do .N; and it's not safe when applied to upstream
<fabbione> daniels: well.. if you know enough about asm.. patches are welcome :-)
<lamont> and no real standard exists for native packages.
<Keybuk> lamont: so we were discussing going with something else entirely ... I personally like +b1, +b2 etc.
<Kamion> I think that's why I ended up liking aj's DEB_RECOMPILE suggestion after thinking about it, but some convention that nobody's used yet would work too
<Kamion> Keybuk: you know some smartarse will use it for beta versions though - why abbreviate?
<lamont> the code I've seen basically says "if there are 3 more components in the debian version number, and there is source excluding either the last 1 or 2 components (which must be numeric), then that's it...'
<lamont> +binNMU<n>
<lamont> of course, anything that is not '.x.y' will require changes in katie and sbuild, to name just a few.
<daniels> fabbione: look at the way I did libGL :P
<lamont> Keybuk: the goal here is for dpkg to know that it's building an NMU?
<lamont> er, binNMU?
<elmo> more that the archive can know reliably, I suspect
<lamont> note also that a binNMU of a package in ubuntu is newer than the ubuntu version...  (1-1.0.1 > 1.1ubuntu1)
<daniels> lamont: er, is it really?
<lamont> elmo: ah, right.
<lamont> daniels: yep.
<daniels> i would've thought that 1ubuntu1 > 1.0
<lamont> dpkg --compare-versions 1.0.1 gt 1ubuntu1 && echo y
<lamont> y
<lamont> daniels: thanks for playing, though.
<lamont> :-)
<daniels> heh
<Keybuk> daniels: "." > "u"
<elmo> lamont: (ITYM, 'kthxbye' :P)
<lamont> fortunately, the only binNMU in warty has a newer version in sid
<lamont> elmo: lol
<lamont> sablevm, for those with scorecard
<lamont> s
<Keybuk> lamont: yeah, basically it's so dpkg-genchanges can go "ah, a recompile, I'll stick 'Source: foo (1.0-1)' in then"
<daniels> elmo: the ubuntuforums folk are find of 'k thnx.
<daniels> '
<fabbione> bah
<fabbione> that asm isolation killed my ccache
<lamont> Keybuk: then it's probably just a matter of getting all the principals in one place an picking a format,eh?
<Keybuk> yup
<lamont> personally, I don't really care, so long as the next sourceful upload has a higher version
<lamont> for extra credit, pick something < 'u' :-)
<Keybuk> that's kinda tricky
<Keybuk> you'd actually have to pick a new character for that, and put it < 'a'
<lamont> yeah - that's why it's _extra_ credit
<Keybuk> all punctuation is > 'z' right now
<lamont> or choose a-t to be the character. :-)
* lamont ducks
<Keybuk> see, if you used "x.ubuntu.y"  instead of "xubuntuy" you could use '+', + < '.' ;o)
* jdub is still wondering wtf derivatives are going to do
<lamont> Keybuk: yeah, the issue was that we wanted 1ubuntu1 < 1.1
<Kamion> jdub: 1ubuntu1myderivative1
<lamont> heh
<Keybuk> foo_1.0-1ubuntu5skole3guade2_i386.deb :p
* lamont must run
<lamont> back in about 90 minutes or so, actually closer to 2 hours now that I think about it,
<elmo> 326, 326, 350, 22 <-- need-update, up-to-date, ubuntu-modified, ubuntu-specific
<elmo> s/22/20/
<lamont> Keybuk: truthfully, I don't really mind what it is, so much as I want there to be an official standard for it.
<lamont> and buyin from all concerned, of course..
<lamont> bbl
<Keybuk> elmo: I have 438 ubuntu-modified
<elmo> keybuk: I'm only doing main
<elmo> right now
<Keybuk> ahh ok
<jdub> Kamion: that so doesn't scale :)
<Keybuk> I did main+universe I think
<elmo> hmm, I'd kind of forgotten about universe, meh
<daniels> elmo: ubuntu-specific soon to be += ~80
<Keybuk> elmo: you're doing the sync of the need-update ones, right?
<elmo> Keybuk: getting ready to, yeah
<Keybuk> cool
<elmo> and mailing folks about stuff that would like to be updated, but are ubuntu modified
<Keybuk> I really wish abiword wasn't first on ubuntu-modified :o)
<elmo> it'd help if there were proper hoary seeds
<Keybuk> most of my rejects seem to be autofuck updates so far
<Keybuk> which is encouraging
<Keybuk> oh, and po/* hell
<Keybuk> I swear, the guys who invented ".po" sat down and designed a file format deliberately intended to be totally unpatchable
<thom> it's a feature (TM)
* fabbione kicks libgl straight in the core
<Keybuk> thom: did apache2 steal dpkg-style sorting for filenames ?!
<daniels> while we're speaking of httpds, what's up with the indexing on auckland?
<Keybuk> * kdemultimedia trying 3.2.2-1ubuntu2 + 3.3.0-1
<Keybuk> 1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej
<Keybuk> 1 out of 4 hunks FAILED -- saving rejects to file debian/control.rej
<Keybuk> lamont is teh suck
<thom> Keybuk: hrm?
<Keybuk> thom: I just noticed that the files are sorted correctly
<Keybuk> rather than 1 10 11 2
<thom> ah, heh
<thom> doubt it's dpkg stealage :-)
<Keybuk> it's not quite right actually, but is close :p
<Keybuk> [   ]  aiksaurus_1.0.1+cvs.2004.03.15+dev-0.12-0ubuntu1.patch 25-Oct-2004 07:02   91M  
<Keybuk> [   ]  aiksaurus_1.0.1+cvs.2004.03.15-1ubuntu1.patch          25-Oct-2004 07:02  9.8K  
<Keybuk> those two should be the other way around :p
<lifeless> http://sourcefrog.net/projects/natsort/
<jdub> so how do i distribute the op love?
<daniels> /m chanserv access #ubuntu add nickname 20
<jdub> aha
<jdub> done for daniels and Keybuk 
<jdub> and thom
<jdub> anyone else?
<daniels> thanks dude
<daniels> i think bob2 wants it, too
<jdub> done for lamont
<fabbione> bah add me too
<daniels> he was mentioning it a while ago, and is #debian
<fabbione> just in case
<HauntedUnix> Hello all.
<jdub> done
<seb128> why not :)
<jdub> done :)
<seb128> thanks :)
<Keybuk> * opencv trying 0.9.5-4ubuntu1 + 0.9.5-10
<Keybuk> 1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej
<Keybuk> 2 out of 2 hunks FAILED -- saving rejects to file debian/control.rej
<Keybuk> o/~ oh, lamont
<fabbione> daniels: getting an wireless AP for the sprint :-)
<daniels> good thing, too
* fabbione gives up on Mesa
<daniels> this house is now pretty reliant on my wrt54g :\
<fabbione> i have tried everything i could to kill that TEXTREL
<fabbione> it's gonna be 11Mb
<Keybuk> rookery scott% grep -c "to file po/" failed.txt
<Keybuk> 1277
<Keybuk> ugh
<Keybuk> in fact
<Keybuk> rookery scott% egrep -c "to file (debian/)?po/" failed.txt
<Keybuk> 1987
<Keybuk> rookery scott% egrep -c "to file debian/(changelog|control)" failed.txt
<Keybuk> 582
<Mitario> lo everyone
<T-Bone> mako: ping
<lamont> Keybuk: how bad are the conflicts, I wonder.
<mjg59> I'm not able to make the Hoary meeting
<mjg59> Is there anyone else who would like to raise laptop stuff?
<nmf> Hi all
<nmf> I have a question I already made on the devel ml but got no (usefull) response, so...
<pitti> mjg59: can you dump your "stuff" that you want to raise on a wiki page?
<nmf> Are there any plans to make packages like tomcat available?
<pitti> Guys, does anybody have a PCMCIA card which provides an IDE interface?
* lamont does somewhere
<mjg59> pitti: Yeah
<Micksa> well, some/most CF cards do that
<mjg59> pitti: Well, PCMCIA->CF adapter
<mjg59> Presents as IDE
<Micksa> and you can get "dumb" CF -> PCMCIA adapters
<Micksa> dammit :)
<Micksa> what mjg said
<thom> mjg59: quite happy to, yeah
<pitti> mjg59: I'm currently debugging #2265, and I need people with such cards to execute two commands
<pitti> the problem is how to reliably tell PCMCIA and "normal" IDE adapters apart; hal's current method is broken
<mjg59> Oh, and I have a PCMCIA CD drive, too
<mjg59> I don't have a laptop with PCMCIA running Ubuntu, though :)
<pitti> I need the output of 'cat /var/lib/pcmcia/stab' and 'cardctl ident'
<pitti> mjg59: I don't think that Ubuntu matters, Debian or another Linux is probably okay, too
<pitti> mjg59: but it should be kernel 2.6, though
<daniels> mjg59: what sort of laptop stuff do you want me to represent?
<pitti> hal upstream wants to collect the output of these commands to find a better way
<pitti> lamont: can you please send me the output of these commands for your card as well?
<pitti> nmf: we will soon develop a policy for adding user contributed packages to our Universe
<pitti> nmf: by now you can try to get packages from Debian unstable, or if unstable does not have it, from www.apt-get.org
<pitti> nmf: (that is, most unstable packages shoudl already be in our universe)
<mjg59> daniels: We need to figure out what sort of suspend work to concentrate on - StD is easier but less satisfying, StR is going to need more effort but /ought/ to be possible. We'd need lots of hardware testing, though.
<daniels> mjg59: *craploads*
<mjg59> pitti: I have no /var/lib/pcmcia/stab
<mjg59> (Or, indeed, a /var/lib/pcmcia)
<pitti> mjg59: hmm, and cardctl ident?
<mjg59> Socket 0:
<mjg59>   product info: SAMSUNG, Rev 1.18.4, 
<mjg59>   manfid: 0x00ce, 0x0000
<mjg59>   function: 4 (fixed disk)
<pitti> mjg59: thanks!
<nmf> pitti: yeahh, I know I can get them from debian, I'm using them now
<pitti> nmf: the package is most likely not in universe because we don't have Java at the moment; but we will find a solution for this
<nmf> pitti: the problem is packages like tomcat depend on not-free packages (sun JDK) to build
<thom> yes, although we should try and work out a way to build them with gcj and see if they work
<thom> this needs a test suite, and tomcat didn't have one last i looked
<daniels> cocoon would be phat to have
<nmf> pitti: ok, if there's anyway I can help to speed up the process, let me know
<daniels> thom: (nor last I looked, short of 'it does stuff and works' or 'it crashes')
<daniels> rburton: hey dude
<thom> daniels: aye
<rburton> hi daniels 
<thom> afternoon ross
<nmf> thom: I think most packages in debian that can work with free JVMs/JDKs already have the correct dependencies
<rburton> thom: afternoon
<fabbione> hey ross
<rburton> hey fabbione 
<rburton> good afternoon all
<rburton> mvo_, synaptic --set-selections isn't doing the right thing for me
<rburton> i clearly tell it "gaim\tremove" and it doesn't do it
* mvo_ is having a look
<rburton> aaah
<rburton> ignore me
* rburton fixes stupid bug
<mvo_> rburton: gaim delete ...
* mvo_ blushes
<tseng> hey thom, any idea how to solve this one.. dbus-1 starts networkmanager before hald
<lamont> nmf: wrt tomcat:
<lamont> multiverse/web/tomcat4_4.1.30-6: Dep-Wait by buildd+mcmurdo [optional:uncompiled] 
<lamont>   Dependencies: j2sdk1.4
<lamont> so warty only has source. :-(
<lamont> pitti: booting now
<mvo_> rburton: it's either "delete" or "uninstall"
<rburton> mvo_, aah. that would stop the run i was about to do. whats the difference?
<lamont> pitti: 4MB pcmcia card, and CF-adapter, fwiw
<pitti> lamont: does /var/lib/pcmcia exist on your box?
<mvo_> rburton: there is none. it's just for conenience
<tseng> thom: should /etc/dbus/event.d have numbered scripts perhaps?
<rburton> mvo_, k
<mvo_> rburton: I can add "purge" if you need it
<rburton> mvo_, could be useful, but i may just use remove
<lamont> pitti: no
<rburton> uninstall even
<pitti> lamont: hm; /var/cache/pcmcia maybe?
<pitti> lamont: find /var -name stab  ?
<lamont>  /var/run/stab...
* lamont upgrades
<rburton> wohoo
<pitti> mjg59: does /var/run/stab exist? Does it look as if it has sth to do with PCMCIA?
<lamont> anyone want to tell me why apt wants to upgrade gnome-cpufreq-applet over and over...
<rburton> mvo_, is therea way to force the terminal window to close when it is finished?
<lamont> Preparing to replace gnome-cpufreq-applet 0.1.3-1 (using .../gnome-cpufreq-applet_0.1.3-1_i386.deb) ...
<lamont> le huh?
<pitti> lamont: can you please /msg me this file and the output of 'cardctl ident'?
<mvo_> rburton: it's a bug if it does not close with "--non-interactive". I'll fix this 
<pitti> lamont: maybe version +0.0001 and dpkg rounds to two digits? :-)
<mjg59> pitti: Nope
<mjg59> pitti: (As in, it doesn't exist)
<rburton> mvo_, but app-install just removed and installed gaim for me. synaptic's cli stuff is useful, thanks
<pitti> mjg59: hmm, thanks anyway
<mjg59> Hmm. That's odd - I plug the card in, hal-device-manager briefly shows two partitions, and then they go away again
* mvo_ would love to try rburtons app-install
<mjg59> pitti: Oh, hang on - it's suddenly appeared
<mjg59> Socket 0: ATA/IDE Fixed Disk
<mjg59> 0       ide     ide-cs  0       hde     33      0
<nmf> lamont: that's the problem I was talking about, it depends on Sun JDK so it never gets built.
<lamont> nmf: right
<nmf> Anyone knows how contrib packages build is handled on debian?
<thom> tseng: yes
<mjg59> nmf: It's not autobuilt
<lamont> nmf: buildd's try, if the non-free stuff is there, then maybe it works.
<pitti> mjg59: thanks
<lamont> otherwise, some random d-d uploads the binaries
<thom> just spoke to (one of) the maintainers about it
<tseng> wonderful.
<daniels> networkmanager, or dbus?
<thom> daniels: dbus-1
<lamont> mjg59: hppa has 88 contrib/ entries in w-b... contrib is autobuilt
<lamont> just not with great success...
<mjg59> Oh, it is? Ha.
<daniels> thom: the other maintainer sucks
<lamont> non-free, OTOH, is definitely not in w-b
<thom> heh.
<lamont> hrm... SMC card seems to "just work".  Linksys card not so fortunate.
<tseng> new linksys cards tend to be broadcom chips
<tseng> while smc goes with prismX
<lamont> netgear card happy too
<lamont> tseng: WPC11 ver 4 802-11B wireless
<lamont> not exactly "new" :-)
<tseng> hmm thats an 11b even
<tseng> survey says prism2, *should* work
<lamont> yeah - I need to actually get my AP working, you see...
<lamont> tseng: btw, url?
<tseng> http://www.kismetwireless.net/cards.shtml
* Kamion fixes up wiki/InstallFromKnoppixHowto lots
<Kamion> still recommends base-config in a chroot, which is kinda suboptimal, but it'll do for now
<Mitario> hello everyone!
<mvo_> hi Mitario 
<Mitario> mvo_, seen my updates on upgrade-notifier?
<mvo_> Mitario: yes. I checked in a small fix also :)
<Mitario> cool :)
<mvo_> is the upgrade-center available for download somewhere?
* Mitario svn ups
<Mitario> mvo_, umm, well I did the rewrite in python
<Mitario> with python-apt
<mvo_> I wonder if it is worth the efford to put the build-in window back
<Mitario> but I have not yet made a package or buildsystem for it
<Mitario> true
<Mitario> IMO it isn't nescesairy
<mvo_> ok
<Mitario> does anyone here know a neet buildsystem for python apps?
<Mitario> mvo_, i can send you the source I have now though
<mvo_> Mitario: yes, please do :)
* Mitario makes a tarball
<Mitario> oh, I was a bit stuck on setting selections in synaptic though, but i'll ask that later
<Mitario> mvo_, see http://luon.net/~michiels/ubuntu/update-manager.tar.gz
<mvo_> Mitario: looks very nice!
<Mitario> :)
<rburton> i best refactor app-install and make a tarball for people to poke at too
<Mitario> app-install was that neet app you showed us some days ago?
<rburton> aye
<Mitario> nice :)
<rburton> it just removed and installed gaim
<rburton> (via synaptic)
<Mitario> cool :)
<Mitario> oh, can you show me your synaptic --set-selection method?
* mvo_ is very happy about all that progress
* Mitario played with it a bit, couldn't get it to work
<rburton> Mitario, okay to /query?
<Mitario> sure
<Mitario> mvo_, anyways, seen the --with-package-manager option?
<mvo_> Mitario: yes!
<Mitario> ok, i did that so distributions/maintainers can use the package manager of choice
<Mitario> so for ubuntu (or at least my packages :) I would use --with-pkg-manager=/usr/bin/update-manager or something
<elmo> oh, of the 326, only 248 actually have newer versions
<fabbione> elmo: don't count xfree86. we are not going to merge it from sid
<fabbione> elmo: we will kill it as soon as we have x.org
<doko> elmo: and many can be just re-synced.
<mako> T-Bone: hey there.. give me a couple minutes
<T-Bone> mako: ok sure! just wanted to make sure you were alive ;)
<daniels> fabbione: http://bugs.gentoo.org/show_bug.cgi?id=49038
<fabbione> daniels: i didn't build Xx86rush yet
<fabbione> i can test it on the fly
<fabbione> i was just searching for a simple lib to trash before the meeting :-)
<fabbione> daniels: if it doesn't contain *gl* anywhere in the name it's ok :)
<daniels> heh
<daniels> fabbione: anyway, that bug and the attached fd.o one are pretty much the canonical fixes
<daniels> look like they're fixed upstream anyway
<daniels> oh yeah, dlloader works out of the box
<daniels> if you want to go for a triple-whammy we can KILL ELFLOADER with EXTREME PREJUDICE
<tseng> dlloader rocks
<daniels> it sure does
<daniels> even better than dlloader is the loader in debrix
<daniels> daniels@nanasawa:~/x/debrix/debrix/hw/xorg/loader% wc -l *.[ch]  | tail -1
<daniels>   897 total
<daniels> daniels@nanasawa:~/x/xorg/xc/programs/Xserver/hw/xfree86/loader% wc -l *.[ch]  | tail -1
<daniels>  13417 total
<fabbione> daniels: one thing at a time
<fabbione> let's get X.org out of my harddisks first
<daniels> heh
<tseng> oh daniels, do you know anything about tv out on ati?
<fabbione> daniels: Xx86rush compiles perfectly here
<fabbione> they are on crack
<daniels> fabbione: merged into xorg, then
<fabbione> daniels: could be
<daniels> tseng: 'don't'
<daniels> tseng: how recent?
<tseng> i have an radeon mobility, few months old and a radeon aiw 9200
<daniels> should be fine with the mobility, likely sol with the 9200
<tseng> just wondering if xorg will do anything for me, ati-drivers are the suck
<daniels> for the mobility, google for atitvout
<__daniel> hai
<Mitario> heya
<__daniel> brb
<lamont> Kamion/Thom: please rename warty-rc2-live-i386.iso to warty-release-live-i386.iso.  Ditto for .torrent
<elmo> kamion/thom/whoever: and please let me know, when it's done so I can upload it to the CD pressers
<thom> not me, this is all kamio	
<Kamion> thom: you need to do torrents :)
<Kamion> I'll look, may not be done until the meeting's over
<daniels> thom: isn't it great how much time tab completion saves you? :P
<Kamion> lamont: (mdz's confirmed?)
<mdz> elmo: confirm the md5sum with lamont
<mdz> his latest bits are the ones which should go out
* lamont md5sums
<elmo> dac84a3abf5a1a104d768d569a62579e  warty-rc2-live-i386.iso
<lamont> dac84a3abf5a1a104d768d569a62579e  warty-live-i386-20041022-04.iso
<lamont> that should match rookery
<lamont> should match releases.u.c
<ctalkep> hi guys
<ctalkep> is daf here?
<daniels> ctalkep: he's on the channel
<ctalkep> well...
<daf> ctalkep: hi
<ctalkep> daf, , hi
<ctalkep> daf, been looking for you for several days
<daf> I'm not always around on weekends
<ctalkep> daf, wanted to contact you about the translation project, since you are in charge
<ctalkep> i read at the list that the installer is about to be the most important part to be translated, so is that where we need to start?
<daf> I recommend you choose something you would personally like to see better translated
<daf> also, it's a good idea to take into account what experience you have when you start translating
<daf> some programs are easier to translate than others
<daf> and you have an advantage if you're translating a piece of software you're familiar with
<ctalkep> i see
<ctalkep> daf, so there is no structured schedule ?
<daf> no
<daf> it's a free-for-all
<ctalkep> daf, sorry, got to leave for a while, be right back, wanted to ask you and on the web site translation
<daf> ok, see you later
<lucas_> hi
<Kamion> thom: updated live CDs, please check torrents
<thom> Kamion: 'k
<aj> how are you making your live cds?
<aj> manually, or fai, or other automation?
<daniels> manual, aiui
<jdub> well
<jdub> morphix-manual
<thom> lamont/kamion: torrents torrentified
<lamont> aj: morphix-mmaker
<lamont> invoked manually atm
<Kamion> lamont: I assume you or somebody will figure out who's sending the release announcement
<Kamion> canonical URL is http://releases.ubuntu.com/warty/warty-release-live-i386.iso BTW
<lamont> Kamion: yes, once the meeting is over, I'll work with mdz/jdub/whoever and make it happen
<ctalkep> daf, you still here?
<daf> yep
<ctalkep> daf, so, do i take the files for translation from the debian repository?
<daf> that depends on what you want to translate
<ctalkep> daf, i was hoping there was someone out there to tell me what should be done,:), but since i'm on my own i don't generally care
<ctalkep> daf, and i am so impressed with ubuntu, that i wanted to begin with it's translation
<daf> well, it's really up to you
<daf> find something you like using which needs work and work on it
<daf> have you already managed to get Ubuntu working in your language?
<ctalkep> haven't started yet
<ctalkep> wanted to first get a grip of the situation
<ctalkep> i guess i'll just start with that
<ctalkep> then what about the web site translation?
<ctalkep> there are a lot of people here working with linux, yet few of them are comfortable with english
<daf> web site translation is not possible at the moment
<ctalkep> i think it would bea great advantage, since there are only few online sources of information on linux/unix now
<daf> we're working on that
<ctalkep> i see
<daf> I'll make an announcement as soon as it's ready
<daf> running Ubuntu in your language would be a good start
<ctalkep> i will begin with that then
<dany> to beshe na purvata vuzmojna opcia be
<pitti> So we can now upload our stuff into Hoary? Or shall we wait for the sync first?
<hornbeck> is there anyway to find out what was said in the meeting today?
<hornbeck> like a log or something
<mdz> pitti: if you have packages to upload which do not interefere with the sync, I think it is fine. elmo can confirm
<mdz> hornbeck: there will be a transcript and summary posted to the list
<mdz> hornbeck: if you want something now, I can send you a copy of my scrollback
<pitti> mdz: I already synced some packages (hal and gvm), so it would actually ease the merge
<pitti> hornbeck: I have a copy here
<Mitario> hmm, I'm wonderwing if it'd be usefull for ubuntu/me if i'd sign up for wannebe maintainer :)
<pitti> hornbeck: http://www.piware.de/ubuntu-meeting-20041025.txt
<pitti> mdz: but if there is already an automated merging process, I can defer uploading
<mdz> pitti: should be fine, send mail to Keybuk to notify him that you have done it
<pitti> mdz: okay, I will CC elmo as well
<elmo> eh, I think we should try and sync where possible?
<elmo> rather than do uploads?
<hornbeck> pitti, mdz: thanks I am reading pitti's copy
<pitti> elmo: I packaged a completely new hal version which just arrived at experimental
<pitti> elmo: I just don't know what is easier: let you finish the automatic merging and upload afterwards, or upload immediately
<hornbeck> mdz: a bounty for a python port of yelp?
<pitti> elmo: but we changed so many things in hal and gvm that even manual merge was a PITA; I think it isn't possible automatically
<elmo> pitti: what am I saying is, if ubuntu-version will == debian-version, I think we should sync
<pitti> elmo: not really
<pitti> elmo: I took the new Debian version, and redid the Ubuntu modifications as clean patches
<pitti> elmo: same with g-v-m
<pitti> elmo: I will need to upload anyway, but I want to do it at a time when it does not interfere with merging
<elmo> then go ahead and upload
<elmo> tho the cron jobs are disabled right now
<elmo> only 800 or so more packages to sync in universe
<pitti> elmo: okay, if now is a good time
<hornbeck> mdz: I would like to do the Ubuntu in a Nutshell, if there are no other takers
<jdub> hornbeck: that'll be a more-than-one-man project, probably involving some canonical contracts too
<hornbeck> jdub: I would really like to work on it if I can
<hornbeck> I really want to put something out that is not just internet based
<hornbeck> well I am off to work again
<sabdfl> hornbeck: i like the idea, who is the publisher of the "in a nutshell" series?
<tseng> oreilly and associates
<sabdfl> tseng: thanks
<hornbeck> sabdfl oreilly
<tseng> we could say
<tseng> "ubuntu in a clamshell" :D
<hornbeck> "ubuntu in a akorn"
<sabdfl> hornbeck: go ahead and approach them if you like, with my support
<hornbeck> sabdfl: I will try :-)
<hornbeck> If I go about this, I don't think I will get much real docs done
<tseng> there are several other publishers with an eye towards open source as well
<hornbeck> but it will be a major doc in and of itself
<tseng> if that is the route you are going
<hornbeck> well it would be nice to get a Ubuntu Book out there
<hornbeck> I like books
<tseng> newriders, no starch press
* hornbeck works in a library
<hornbeck> no starch is through orielly is it not?
<tseng> there is some sort of partnership i believe
<hornbeck> yeah that is what I thought
<tseng> but no starch is at least externally its own company
<hornbeck> sabdfl: the nutshell series is more just facts
<hornbeck> I could approach no starch about doing a "Ubuntu book"
<hornbeck> or even Oreilly
<tseng> http://www.nostarch.com/about.htm
<tseng> oreilly is a distributer for no starch
<hornbeck> what do you guys think?
* tseng cares less about who prints it than the content
<pitti> night
<tseng> bye pitti 
<hornbeck> well, lets discuss later I have to be at work in 10 minutes
<tseng> ok
<tseng> content = #1
<hornbeck> sabdfl, tseng: I think I would want to work with all the dev's on this
<hornbeck> to make it very good
<tseng> yes.
<hornbeck> but discussion later
<tseng> bye
<sabdfl> hornbeck: to get it done for hoary it may be better to start with a tighter format
<Kamion> so, I can upload merges to hoary now?
* Kamion cracks his knuckles
<hornbeck> sabdfl: I will put together a outline and mail to you
<elmo> yeah, if you want
<elmo> they won't be built/mirrored out for a bit tho
<sabdfl> hornbeck: i'm already a bottleneck, can you figure this out within the doc team? ping me on irc if you need any specific commitment
<hornbeck> sabdfl: I will work something out and let you guys know
<sabdfl> elmo: if we can avoid mirroring for a while, it might be worthwhile
* hornbeck is off to work
<sabdfl> maybe publish hoary somewhere where it can break
<sabdfl> especially if we are going to be uploading new gcc etc
<sabdfl> once the toolchain is in, we can rebuild
<sabdfl> or is that toenail-smoking?
<Kamion> sounds like a plan to me
<Kamion> or maybe just publish source only
<elmo> err, I thought we discussed this?
<elmo> +in the meeting
<elmo> this is why, I'd held off on hoary so long, because people keep telling me to do entirely conflicting things with hoary :-/
<mdz> if we were going to update the toolchain, we should have done that _before_ importing new versions of everything
<elmo> I can't not mirror hoary, without essentially forking the archive infrastructure.  I can do that, if you want but I need to know now.
<elmo> The only other thing we could do is restrict access to the Packages/Sources files but that certainly won't allow us to en-masse rebuild
<elmo> or option c) we just put hoary out there, which is what I thought was the plan, and what I had started on doing
<elmo> by "update the toolchain" you mean switch to gcc3.4/4.0 by default?
<Kamion> that sounds like bong ...
#ubuntu-devel 2004-11-06
<__daniel> is "bong" something good? :-)
<Kamion> __daniel: no
<Kamion> mdz: hoary's seeds are starting out at warty, right? so copying warty->hoary in debootstrap is safe?
<mdz> Kamion: yes
<mdz> I don't think base has any changes proposed for hoary anyway, does it?
<elmo> there's nothing on the wiki
<Kamion> I'm sure some will happen :)
<elmo> actually, yeah, I'm going to propose ethtool, for base, tho I may not succeed
<Kamion> mdz: at minimum one is necessary: libc6.1/ia64
<elmo> kamion: efi, etc. too
<Kamion> elmo: d-i can probably install those
<elmo> ah, yeah
<elmo> tho, the world will pull in libc6.1 too :)
<elmo> christ, even expensive AMD64 servers can't keep time right - I thought it was just cheap shitty motherboards that were the problem
* Kamion throws debootstrap_0.2.45ubuntu1 hoary's way to see what happens
<elmo> so, anyone, final call, on options, a), b) or c) above ?
<Kamion> elmo: (any opinions from me withdrawn, I'd rather it worked)
<Kamion> is somebody setting up a hoary-changes list?
* jdub uploaded to hoary :-)
<jdub> elmo: who was first? :)
<jdub> Kamion: hrm
<jdub> Kamion: should we have a general -changes list, or a new one for each release?
<elmo> won't we eventually be in parallel with two distros?
<jdub> mdz: benh could really only raise PPC NPTL wrt glibc
<jdub> elmo: more than two ;)
<elmo> well, ubuntu distros then :P
<elmo> I mean, like when hoary is frozen, but grumpy is syncing with sid
<jdub> surely updates and embargoed security go to warty-changes too?
<elmo> not to mention warty-updates uploads, so, yeah I think we should have per-distro lists
<elmo> security uploads go to u-s-a
<elmo> (err @lists.u.c)
<jdub> mmm, true, people won't care about warty once we're on perky, but we will
* jdub goes to create hoary-changes
<mdz> elmo: it's not just cheap servers; Sun machines are notorious for keeping shitty time
<elmo> what's hoary's version number again?
<jdub> 5.4
<mdz> or is it 5.04?
<jdub> ugh
<jdub> has to be 5.04 i guess
<mdz> not as bad as "4.1" for 4.10
<jdub> hrm, doesn't *have* to be 5.04
<mdz> no, it doesn't
<mdz> I just didn't remember what was decided
<jdub> elmo: do syncs go to hoary-changes?
<elmo> they, err, will 
<elmo> not the mass flood i just did tho
<elmo> and do we want sync notification for universe?  I assume not?
<jdub> http://lists.ubuntu.com/mailman/listinfo/hoary-changes
<mako> hornbeck: you around?
<lamont> moo
<T-Bone> moo
<mako> T-Bone: hey dude
<T-Bone> howdy buddy!
<lamont> mdz: main/universe/multiverse separation all mine, yes.
<jdub> yo T-Bone 
<mako> T-Bone: i thought you were off for the day
<T-Bone> mako: nah, waiting for you ;)
<T-Bone> jdub: ola!
<T-Bone> lamont: btw, any news on the IA64 side?
<lamont> t-bone: later tonight, I promise
* lamont goes to get the can of air
<T-Bone> lamont: ok, that'll be tomorrow then ;)
<lamont> yeah
<T-Bone> ok
<T-Bone> i'll promise to find more time on my side too ;)
<T-Bone> got a bit swamped with the end of my scholarship getting closer ;)
<mjg59> Is Openoffice on the CDs?
<jdub> yes
<lamont> mjg59: it's part of desktop, so yes
<mjg59> Rock
<mako> T-Bone: ok, sent
<T-Bone> mako: thx _alot_ !
<mako> T-Bone: np
<mdz> sabdfl: has the new wiki announcement gone out yet?  I haven't seen it
<sabdfl> no, i'm waiting for news from stevea about the wikiwikibangbang
<sabdfl> mdz: ^
<mdz> sabdfl: wikiwikibangbang = moving the old content over?
<sabdfl> yes, automated
* T-Bone calls it a night, past 1AM, see yall
* lamont returns, coughing from months of accumulated dust.
<elmo_> dh_installpam --name ssh # TODO: breaks woody backports
<elmo_> Unknown option: name
* elmo_ whines at kamion
<mjg59> sabdfl: How would you like to move forward with the laptop stuff?
<mdz> mjg59: feeling any better?
<sabdfl> mjg59: speedily, happily, with a little song?
<mjg59> mdz: A bit - hot whisky and a large bowl of stew
<sabdfl> hmm.. whiskey and lemon
<sabdfl> mjg59: can you map out for me how you'd like to handle it?
<sabdfl> i'm pretty much open to your lead on it
<mjg59> sabdfl: Suspend to disk is a matter of me getting the code to do swsusp off initrd together, building some test kernels and letting people go to town
<sabdfl> ok
<sabdfl> are there other things that we can do to really make it rock, that parallelise?
<mjg59> S3 is a bit trickier. The only test hardware I have is the C3 thing, and it's not playing ball yet
<sabdfl> id like to build a volunteer team around you
<sabdfl> you are welcome to my tosh test laptop for a month or two
<mjg59> That might well be useful
<mjg59> It pretty much worked
<mdz> mjg59: I got the impression from Herbert that swsusp was ready to go once we got v2 in
<mdz> mjg59: and that is on his list for hoary already
<mjg59> v2 of swsusp?
<mjg59> Eww.
<mjg59> Really, it's bad crack.
<mjg59> Pretty, though.
<mdz> mjg59: I was under the impression that we had no choice
<mjg59> For which?
<mdz> mjg59: because earlier versions can't handle, e.g., IDE drivers being loaded as modules
<mdz> swsusp
<mdz> mjg59: mind creating a bugzilla account so I can CC you on this stuff? :-)
<mjg59> http://perso.wanadoo.fr/pascal.brisset/initrd-swsusp/ for instance
<mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=2003
<mjg59> I'm pretty sure there's more recent versions of this code floating about
<mdz> if there's a better way, Herbert needs to know about it now
<mjg59> SuSE certainly won't be shipping swsusp2, given that they've got Pavel
<bob2> does the swsusp merge in 2.6.9 mean it's supposed to work outside i386 now?
<mjg59> bob2: Not quite as yet
<mjg59> Benh had code for PPC. I'm not sure if it's done yet.
<bob2> most of the ppc effort seems to have been on pmdisk.
<mjg59> pmdisk and swsusp have been merged now
* mjg59 waits for his Bugzilla account confirm mail...
<__daniel> sleep tight guys
<bob2> ah, awesome
<sabdfl> daniels: will our x.org have composite?
* lifeless wishes swsup worked for him
<lupus_> composite disabled by default I hope :p
<lupus_> euhm http://wiki.ubuntu.com/WartyWarthog_2fImages shouldn't this be moved to hoary?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion and support on #ubuntu | Happy Hoary Trail! | BE THE SIGNAL | Warty release is DONE, long live Hoary
<daniels> sabdfl: yeah
<Clint> what's the top-s3krit security contact address for ubuntu?
<hornbeck> mako: you looking for me?
<hornbeck> well I will be eating and back in about 30
<mdz> Clint: I'm not sure whether security@ubuntu is set up yet
<mdz> Clint: but mdz@canonical.com works
<hornbeck> back
<hornbeck> plovs: ?
<mako> hornbeck: yeah
<mako> hornbeck: perfect timing
<mako> hornbeck: i wanted to know if there was any summary of the documentation meeting?
<asw> hornbeck: what do you think about http://www.phptr.com/title/0130327654 It's part of Bruce Perens' Open Source series.  http://www.phptr.com/series/series.asp?ser=335494
<asw> hornbeck: It would be very cool to have an Ubuntu book in that series.  What do other people think? (I'm replying to your message in ubuntu-doc) 
<hornbeck> mako: what doc meeting?
<hornbeck> asw: that loooks pretty good
<hornbeck> mako: nevermind, I remember now :-)
<hornbeck> I think so let me check
<hornbeck> mako: are you on the -devel list?
<hornbeck> mako: enrico, did a write up of the meeting
<hornbeck> I can forward to you if you like
<mako> hornbeck: i must have missed it
<mako> ooh.. it was probably sent late
<mako> alright. it must have not made my 2004-10-15 traffic cutoff
<hornbeck> yeah, the mail was on the 15th at 2:46pm
<asw> hornbeck: I'd love to help (in whatever way I can) on any ubuntu book under a libre license.  As usual my interest is "ubuntu for scientists" but scientists just want thing ordinary users want like openoffice/evolution/mozilla also gimp/latex/texmacs 
<hornbeck> asw: I am thinking more of a beginning type book
<mako> i found it quite good to build up to a book length piece
<asw> hornbeck: yeah that's what i figured but surely openoffice/evolution/mozilla are beginner apps? 
<hornbeck> asw: I have started a outline, and will be posting it to the mailing list when I have that done.  It will hopefully be under a decent license, but this being my first attempt at a book, I think just getting to chapter one will be good for right now
<hornbeck> asw: I was thinking, 1. Intro to Linux, 2. Installing Ubuntu, 3. The Gnome Desktop, 4. Useful apps, 5. package management, 6. the command line
<hornbeck> something along that
<hornbeck> command line before package management
<asw> hornbeck: sure... I guess licenses are something that people can really fight about after the fact (don't start a company without a share-holder agreement) so it's nice to make sure about it in advance.   Yeah I admin some boxes for my room-mates and I'd love to give them a copy. =^)  Also my parents. 
<asw> ps. My thesis proposal went out today. This time next week this part will be all done.  I'm a little terrified really.  Everybody on that committee is about a billion times smarter than me. 
<hornbeck> asw: you will do fine
<hornbeck> asw: I don't know how much to demand right from the get go, considering I have to go through a whole proposal first
<asw> hornbeck: i was trolling so thanks for indulging me! 
<hornbeck> no prob
<asw> hornbeck: if you plan to publish the book I think it's a good idea to have a "target" publisher and then some "alternates"... 
<hornbeck> asw: My first choice is Oreilly, than I would consider no starch and a few others
<asw> hornbeck: and I would venture a guess that if you promise to use a libre license from beginning you'll get more help with proof-reading, and maybe some direct contributions of text.  
<hornbeck> but Oreilly is the one people look to for good books
<hornbeck> asw: yeah, I would guess so
<asw> hornbeck: looks to me that "no starch" is distributed by Oreilly so they might as well be the same company. (That's just from a glance at the web-pages...) 
<hornbeck> asw: no starch is distributed by oreilly but is not the same company
<hornbeck> well, I am off for the night to watch some ER and shower.  I will be at the CC meeting tomorrow so see you all there
<asw> gnite!
<fabbione> morning
* lamont heads to bed
<fabbione> night lamont 
<mdz> morning, fabio
<fabbione> hey mdz
<fabbione> is there any more outcome from the meeting that i should be aware of?
<fabbione> btw we could have called the new mailing list ubuntu-changes directly ;)
<mdz> fabbione: not really, I am still processing the notes to update the wiki
<fabbione> ok
<mdz> fabbione: there was a short discussion about it in this channel between (I think) jdub and elmo
<mdz> and they decided on hoary-changes
<fabbione> ok
<fabbione> we also need to be sure that python is fully installed before X.org
<fabbione> we will have to change base-config for that
<fabbione> and i will have to pre-depends on it
<fabbione> does a python debconf interface exists?
<mdz> fabbione: I do not think so
<mdz> but it would be simple to write one
<fabbione> if it doesn't exist it will kinda difficult for me to switch the scripts
<fabbione> i don't have the knowledge to write an interface at that level
<mdz> it may be simpler than you think; look at /usr/share/debconf/confmodule sometime
<mdz> but someone else could do it also
<mdz> do you need it today?
<asw> mdz: I'm sasha (I don't remember if I introduced myself previously.) Curious, are you the M. Zimmerman of EFF (staff attorney?)  That just seems odd... 
<mdz> asw: no
<fabbione> mdz: no but asap
<fabbione> python2.3-configlet - alternative debconf configuration interface: core API
<fabbione> i don't think it's the same
<mdz> fabbione: ah, there is one
<mdz> it's included in the debconf package even
<mdz> just import debconf
<fabbione> ok
<skvidal> 'lo all
<skvidal> a short while back I read in I think an ubuntu or debian developer's blog about potential python-dpkg bindings
<skvidal> I was wondering if 1. anyone else could remember where I might have read that and 2. if there is any movement in that direction
<mdz> skvidal: it's not on the schedule for the next 6 months, but that doesn't mean it won't happen
<mdz> I think wichert akkerman is working on something like that
<skvidal> mdz: hmm, okay, I'm just kinda curious in the prospect of that
<mdz> or was
<mdz> skvidal: I think it depends on having libdpkg, which doesn't itself exist yet
<srbaker_> grrr.  i need a new job.
<skvidal> srbaker_: join the club, we have jackets :)
<aj> srbaker_: "<hinthint>" ? :)
<srbaker_> aj, ?
<aj> srbaker_: ...for Canonical HR?
<srbaker_> aj, just me generally grumbling, but if you know anywhere that's hiring, let me know.
<srbaker_> aj, i thought canonical was full
<aj> *shrug*, no idea
<srbaker_> and besides, if you want debian developers, there are probably 600 that are smarter than me that you haven't hired yet.
<srbaker_> or they, i don't remember if you're at canonical or not
<hornbeck|sleep> I need a job to
<skvidal> mdz: yah I did some searching and found the blog entry I had read before
<skvidal> mdz: I see what you mean about needing libdpkg first :)
<srbaker_> oh.  is there planning on being a parisc port of ubuntu, because i have a D-9000 to send to the first person that pays the shipping
<mdz> srbaker_: no one has expressed interest as yet
<mdz> besides lamont, of course :-)
<srbaker_> mdz, heh.  well, i have a large d-class here that's taking up room
<srbaker_> keep it in mind
<srbaker_> :P
<mako> hmm
<mdz> hmm
<mdz> I am receiving old mail via ubuntu lists
<mdz> jdub: are you moderating or something?
<fabbione> so did i
* mako raises his hand
<mako> i moderated
<mako> i thought it was mostly from the last couple days
<mako> but devel had some slightly older stuff
<mako> nobody has sent out a reminder for the CC meeting tomorrow, right?
<mako> (i haven't seen one)
<mdz> mako: no, good idea
<mako> looks like we have a full agneda
<mdz> do we?
* mdz hopes it doesn't last quite as long as the hoary kickoff meeting
<mako> http://wiki.ubuntu.com/CommunityCouncilAgenda
<mdz> pshaw
<mdz> 4 items :-)
<fabbione> too many meetings :(((
<mako> well, full compared to last one :)
<mako> which was empty :)
<mdz> fabbione: you don't need to attend the CC meeting if you don't want to
<mako> mdz: i didn't get to the kick off summary today.. i did 3 of them and thought it was about enough for the day :)
<fabbione> mdz: the problem is the time
<fabbione> 16:00 UTC is really bad for me
<fabbione> and now it seems to be a standard
<mdz> that's because when I asked everyone for times, that was the middle ground
<fabbione> yeah and that's ok when there is a meeting once in a while
<mdz> if you would like to ask everyone again, and find a time which works better for you, we could discuss changing it
<fabbione> now we are up to 2 meetings per week every 2 weeks
<mako> fabbione: well, you can pretty safely ignore the CC meetings unless you're bringing up an issue there
<fabbione>  Mentoring new developers
* mako shrugs
<fabbione> that something important :)
<mako> yeah 
<fabbione> i didn't put it there
<fabbione> but i am kinda a mentor for debian too
<mako> i suppose there is a pretty high chance you'll have something you're interested on any given agenda
<fabbione> mako: right
<mdz> mako: the hoary kickoff summary will be to the CC summary as this month's traffic is to July's traffic
<mako> mdz: i cut out like 600 lines and moved into a linked summary
<mako> the art summary was larger than the first 3 traffics combined, at least :)
<mako> WTs, not UTs
<mako> well, actually, maybe UTs too
<mako> fabbione: well, these conversations can happen before and after the meetings
<mako> fabbione: i guess we don't really have a procedure for participating in a meeting before a meeting short of making notes or adding thigns to the wiki
<mako> but i think that's a nice thought since clearly we've got people in places for which that time is convinient
<mako> and peoples in places where it's fine but their schedules don't fit :)
<fabbione> mako: yes i know that
<fabbione> i guess i will have to deal with it
<skvidal> mdz: thanks for the info, have a nice night
<fabbione> and deal with my gf bitching
<mako> fabbione: :-/
<fabbione> well.. i am used to people bitching about X...
<fabbione> i can handle my gf
<fabbione> ;)
<mako> have people called ubuntu-people 'ubuntites' yet?
<lifeless> ubuntean ?
<mako> because if not, i'd like to coin that phrase
<mako> lifeless: ubunteans is nice too
<mako> ubuntonians
<mako> ubuntunians
<lifeless> redundant
<mako> ubunters
<pasc> ubuntuses?
<mako> the ubuntish
<lifeless> ubunts
<mako> ubuntush would be nice if it didn't have "tush" on the end
<lifeless> haha, you said 'tush'
<mako> imho, ubuntites wins
<mako> ubuntettes!
<mako> coming to a record store near you: Mark Shuttleworth and the Ubuntettes!
<asw> this ubuntite should go to sleep.  Gnite mako! 
<pasc> the tutus?
<pasc> ;-)
<mako> asw: i'm joining you.. (in sleep, not in person)
* asw laughs
<mako> asw: the doc meeting stuff was great
<mako> asw: i read through the log today.. awesome stuff, good ideas
* mako goes to sleep
<asw> mako: yeah I just submitted my PHD thesis proposal today (i'm nervous as hell) but by next week I should have a year to work on free software projects as time permits. 
<mako> asw: what dept?
<mako> asw: school?
<asw> biophysics (harvard) but its a cs-physics-biology project.  See http://groups-beta.google.com/group/coreworld-announce
<mako> asw: ah, you're in cambridge, cool! we should have coffee at cafe algiers next time i come up :)
<mako> organize a boston ubuntu meeting :)
<asw> next announcement after the committee meeting next week.  I've read a few of your pages.  Actually Gerry Sussman wanted me to talk to SPI folks about an idea I have. I very very briefly talked about it with Mark (sbdfl) already.
<asw> yes. I'd love that. (re algiers) 
<asw> actually are you in washington?
<mako> asw: i'm in new york now but lived in boston a few years ago
<mako> lived in seattle and italy and western mass (amherst) in between 
<asw> oh. in that case maybe sooner... I'll be in new york fairly soon.  
<mako> asw: http://mako.yukidoke.org/contact.html
<mako> asw: let me know when you're coming down.. give me some advance warning and i can get you a place to crash probably :)
<asw> Googling people doesn't work.  (I swear I saw what looked like a current page that said you live near Seattle.) 
<mako> asw: i moved like 3 weeks ago :)
<mako> asw: didn't have to be that out of date
<mako> asw: but yeah, we can talk spi stuff too. i'm here and our lawyer is too
<mako> (who is a debian maintainer now as of last week)
<asw> mako: careful I might take you up on that.  (re crash space.)   The last time I stayed in NYC I found a dorm style room with a bunch of underwear models at the Gershwin hotel.  I think I debated Creationism versus darwinian evolution with a girl who ended up bunking with the fifteen year old.  Ah well. =^)
<vorlon> hum?  Greg is a maintainer now?
<mako> vorlon: yeah, took over xkbsel
<mako> vorlon: and is getting ready to an upload of an new package of galax (xml query language)
<vorlon> nice.
<mako> greg is a real hacker.. reads his email in nmh and write his printed documents in troff
<asw> mako, vorlon: until tomorrow!  mako one last question.  Do you know Brad Fitz (in person)? 
<mako> asw: not yet i don't believe
<mako> asw: yeah, let me know. we have lots of guests :)
<jdub> oh man
<jdub> meeting tonight too
<jdub> eeeeeuuuggh ;)
<mako> jdub: tuns of meetings
<asw> mako: thanks. I'll definitely take you up on it... Re docs. I'm going to suggest we look at http://www.oreilly.com/catalog/debian/chapter/book/index.html that's what I'd like to see for Ubuntu. (Maybe a different license but personally, I'd really like to keep the GNU in the title.) 
<mako> asw: me too :) 
<asw> really? (is that re. keeping "GNU" in the title?) 
<mako> yep :)
<mako> all of it actually
<plovs_work> any of the zwiki people awake?
<srbaker_> okay, one thing i don't understand about arch is why do they like to have such weird names for directories?  it's really imposing
<jdub> http://netatalk.sourceforge.net/2.0/ReleaseNotes.html
<jdub> ^ sweet
<asw> srbaker_ : it's taken me a really long time to get used to the idea of "small clean changesets" and I'm still not sure I'm used to it.  the other parts of arch are ultimately less of an issue imho than wrapping your head around the idea of a growing "frontier" of releases at each arch archive rather than a central repository.
<srbaker> asw, bah, all of that stuff i can get used to.  the long path names drive me fucking batty
<srbaker> esp. when it makes my prompt three lines long
<aj> srbaker: yay darcs! :)
<srbaker> aj, heh, i really like darcs.
<srbaker> but i've been using monotone
<srbaker> i think i'm going to be using darcs on my web server for the php code i have to maintain (ugh)
<srbaker> it's mostly drupal modules.
<srbaker> anyways, bed time.  it's 3:40a here
<asw> srbaker: you are probably right. Yeah it's 2:40a here.  
<asw> srbaker: re. Arch "rough spots"... 
<pitti> mdz: Morning! Say, what shall we do with bugs that are fixed in Hoary, but still present in Warty? Bz does not support version tracking, so shall we just close them?
<bigbrother0074> anybody think i might have any luck getting a logitech quickcam to work?
<pasc> pitti: last time I asked someone that for debian, I was told the answer was shorter release cycles ;-)
<pitti> pasc: we have fixed release cycles :-)
<pitti> pasc: our future bug tracking system will be able to track versions, but bugzilla is not
<pasc> pitti: that's why I stuck the smiley face on the end
<pitti> pasc: ah :-)
<pasc> pitti: living in sydney, it's hard to avoid ubuntu devels
<pitti> pasc: It's really amazing that the smallest continent brings the largest share of Canonical employees
<pasc> pitti: ah! but we're the largest island
<pasc> ;-)
<tfheen> fabbione? 
<pitti> mdz, jdub: Can I upload #2744 (tempfile vulnerability in gs-common)?
* tfheen waves from Venice
<pitti> tfheen: Hi!
<pitti> tfheen: What's up in Italy?
<pitti> tfheen: ops, that's Austria, right?
<fabbione> hey tfheen !
<tfheen> no, Italy
<pitti> tfheen: no, that was Vienna. Damn English city name translations...
<pitti> tfheen: vacation or job?
<tfheen> vacation
<pitti> tfheen: nice! I've never been there, but all these canals and the city must be beautiful
<tfheen> yeah, they are
<tfheen> going home today, though
<pitti> :-(
<pitti> send some photos :-)
<tfheen> willdo
<tfheen> nah, it will be nice to get home.. I am tired now.. hopelessly behind on mail I guess as well
<bigbrother0074> i'm new to linux...what should i do if i do an apt-get install of a package and it seems to be successful...i don't need to restart, do i?
<bigbrother0074> i supposedly installed the utils for the logitech's quickcam...but i don't know how to use these utils
<pitti> bigbrother0074: in all but very rare cases (like new kernels) you don't need to reboot
<fabbione> bigbrother0074: that should be ok, but please take these topic to #ubuntu
<pitti> bigbrother0074: packages should usally "just work"
<jdub> pitti: approved
<pitti> jdub: thx
<bigbrother0074> oh, what channel is this?
<fabbione> #ubuntu-devel
<pitti> bigbrother0074: this is the development channel, #ubuntu is user
<bigbrother0074> oh, my bad
<fabbione> bigbrother0074: no problem :-)
<bigbrother0074> that would be what devel means
<bigbrother0074> have a good night (or morning)
<sparkes> plovs, was that message CC'd to the list before I reply onlist ;-)
<sabdfl> morning all
<seb128> morning
<asw> sabdfl: gmorning. My phd thesis proposal went out today. I hold my breath for a week and then ... I'll see, I guess.  
<asw> I think I've said good-night in various channels for the last five hours.
<sparkes> asw, is this the ubuntu for scientists thing?
<asw> sparkes: my phd thesis is the quantum coreworld.  See http://groups-beta.google.com/group/coreworld-announce   One way or another there will be another announcement next week. 
<plovs_work> sparkes, hi yeah, i suppose so
<asw> but my interest in Ubuntu is a little broader in scope.  I must say this project makes me very happy.  (Or at least everyone I've met/chatted with associated with the project.)
<sparkes> plovs_work, I replied off list, you can CC the list if you want
* sparkes wouldn't say it if it wasn't for public consumtion
<sparkes> ;-)
<plovs_work> sparkes, ok, i am still getting used to gmail, it's hard to see what goes where, it is all nicely grouped
<sparkes> plovs_work, np
<sabdfl> asw: good luck with the thesis!
<asw> sabdfl: you are going to help me with it.  The Quantum Coreworld should be a standard part of Ubuntu (this is only half a joke.)  but this time I really am going to sleep.  I've heard from a few people about the "warthog" meetings?  When/where is the next one? 
<sabdfl> next one is in barcelona, visitors welcome
<asw> when?
<sabdfl> mid december
<asw> possible. 
<asw> exact dates? 
<pitti> sabdfl: oh, the city is now determined, too? Nice
<sabdfl> december 5 to 18
<asw> [I'm too tired to be polite, I'm sorry.]  
<asw> Woah that's a long time... 
<sabdfl> yes it's more of a workshop / sprint than a conference
<sabdfl> two weeks of intense hacking
<sabdfl> guests usually only come for two or three days
<asw> if I could convince my boss it was essential to my project I could probably get funding (not to mention the permission to go...) I'll email you ... now ...
<pitti> jdub, mdz: again, permission to upload #2745?
<fabbione> pitti: i am afraid it will have to go trough the warty-proposed updates procedure
<fabbione> ah no
<pitti> fabbione: what do you mean?
<fabbione> wrong bug sorry
<pitti> fabbione: oh, okay. I already uploaded several security updates this way... you scared me a bit :-)
<pitti> jdub, mdz: I used version number -2ubuntu0.1 (previous one was just -2); is that okay?
<Kinnison> Hey guys :-)
<Kinnison> I just thought I'd share the notes from my father's Ubuntu install at the weekend if you're interested.
<Kinnison> http://wiki.digital-scurf.org/UbuntuForElders
<fabbione> Kinnison: :-)
<Kinnison> fabbione: my dad was very impressed with the "zero questions and the display ended up just how I wanted it" X configuration :-)
* Kinnison chalks another one up in fabbione and daniels' b33r columns for spain
<fabbione> eheh
<robtaylor> hey all.. i've just been playing with building the ubuntu livecd...
<robtaylor> Kinnison: fabbione: hey! long time no see :)
<Kinnison> Hey rob
<robtaylor> i've just been testing out removable media stuff - who's most upto date on that?
<Kinnison> Not me :-)
* Kinnison just popped in to let everyone have that URL
* Kinnison waves
<pitti> robtaylor: I'm kind of responsible for handling removable stuff
<pitti> robtaylor: but for me it does not work with the live cd
<robtaylor> pitti: oh cool :)
<robtaylor> pitti: ah. well 1st off its a fdifferent kernel, isnt it?
* robtaylor notes that /proc/version tell me it was built by alextreme
<pitti> robtaylor: yes, IIRC the live CD uses 2.6.7, install uses 2.6.8.1
<pitti> robtaylor: does the hotplug stuff work for you?
<robtaylor> pitti: ok, and are there many ubuntu-specific patches?
<pitti> robtaylor: a shipload
<robtaylor> pitti: usb keys are recognised, but onlu work if partioned
<robtaylor> pitti: pcmcia drives dont get picked up
<pitti> robtaylor: hmm, at least something :-)
<pitti> robtaylor: does it work in an installed version?
<robtaylor> pitti: and even strangely, my ext3-formatted pccard drive was mounted vfat!
<robtaylor> pitti: unfortuanltly i dont have a machine i can install ubuntu on to test that :/
<pitti> robtaylor: really? that should not work, the kernel should reject that...
<pitti> robtaylor: sure that it is ext3?
<pitti> robtaylor: the kernel cannot mount an ext3 drive as vfat
<robtaylor> pitti: yep, mount -t ext3 workd
<pitti> robtaylor: and mount -t vfat works as well?
<robtaylor> but unforced mount mounts it as vfat.. very very broken
<robtaylor> havn't tried mount -t vfat
<pitti> robtaylor: can you please summarize that in a bug report? and give all infos you have about this?
<robtaylor> pitti: sure, where's the bug database?
<pitti> robtaylor: I currently have 5 security bugs to deal with, not really time for hotplug stuff now...
<robtaylor> pitti: i can work on this myself, btw
<pitti> robtaylor: bugzilla.ubuntulinux.org
<pitti> robtaylor: thanks!
<robtaylor> pitti: i guess i'll start witch makeing sure the kernels are as similar as possible..
<pitti> robtaylor: neither of these errors should depend on the particular kernel versin
<pitti> robtaylor: version, even
<robtaylor> well the vfat thing is definitly kernel-bound
<pitti> robtaylor: it is
<pitti> robtaylor: of course it is possible that this bug was fixed in 2.6.8
<pitti> robtaylor: I've never tried that :-)
<robtaylor> but yeah the other two are user space
<robtaylor> what do you use to manage user-space mounting?
<pitti> robtaylor: pmount
<pitti> robtaylor: pmount allows normal users to mount drives which are not in fstab
<robtaylor> right
<robtaylor> and what manages the appearance of drives in the 'Disks' window?
<pitti> robtaylor: hal is the database which knows about hotpluggable devices
<pitti> robtaylor: and gnome-volume-manager connects these two: receives hotplug events from hal, calls pmount to mount
<robtaylor> right, sounds sane
<pitti> robtaylor: nautilus is responsible for actually showing the drive icons and windows
<pitti> robtaylor: the advantage is that only the relatively small pmount program needs to run as root
<pitti> rabidbt: and only for a short time (as opposed to the g-v-m and hal daemons)
<robtaylor> hanfg on, but on my test, sda1 was only attempetd to be mounted when i clicked on it in the Disks window...
<robtaylor> so gvm is doing something to make it appear for nautilus, but isnt actually mounting it
<pitti> robtaylor: it really was not mounted?
<pitti> robtaylor: if it appears in the discs window, it should be mounted
<robtaylor> pitti: hmm
<pitti> robtaylor: may it be possible that just no nautilus window popped up?
<robtaylor> pitti: sda1 appears in the Disks window when i insert an unpartioned usb key
<pitti> robtaylor: this can be configured in Computer -> Desktop settings -> removable devices
<pitti> robtaylor: can you check with 'mount' if it is mounted?
<robtaylor> pitti: sda1 doesnt exist
<pitti> robtaylor: ugh, that's ugly
<pitti> robtaylor: so actually there is only /dev/sda
<robtaylor> yeah. 
<pitti> robtaylor: dpkg -s hal
<robtaylor> hnag on
<pitti> robtaylor: this prints hal's version number
<pitti> robtaylor: I only need the version, not the complete output
<robtaylor> pitti: i just need to boot it up again :)
<pitti> no hurry...
<robtaylor> :)
<robtaylor> pitti: ok its 0.2.98=1ubuntu9
<robtaylor> 0.2.98-1ubuntu9 even
<pitti> robtaylor: hmm, should be fine
<pitti> robtaylor: does /dev/sda1 exist?
<robtaylor> pitti: ah. hang on the problematic usb key is a bootable one made with syslinux - hence its unpartioned
<robtaylor> when i insert it i still see an sda1 in my Disks window, but mount /dev/sda1 gives invalid block device
<robtaylor> and mount /dev/sda works finw
<pitti> robtaylor: hmm, that's probably a difficult memory stick...
<pitti> Hi carlos!
<carlos> hi
<robtaylor> hi carlos !
<carlos> robtaylor: hey!!, are you moving to ubuntu?
<robtaylor> pitti: yeah. i could do with getting this working tho .. what can i use to see what hal's doing?
<pitti> robtaylor: lshal is a nice text utility, the Device Manager a nice GUI frontend
<robtaylor> carlos: well i'm going to be basing a product off the livecd :)
<carlos> robtaylor: cool
<pitti> robtaylor: (in Computer -> System configuration)
<robtaylor> carlos: one day we should do our authd =)
<carlos> robtaylor: yes, my plan was try it for hoary time, but I'm not sure if that will be possible O:-)
<robtaylor> carlos: well i'm back in europe now, so maybe we could meet up in spain sometime and have a couple of days hacking :)
<carlos> robtaylor: where are you living now?
<robtaylor> carlos: cambridge, uk
<carlos> ohh, that's close
<robtaylor> carlos: yep, cheap flight with ryanair =)
<rburton> jdub, ping?
<carlos> also I my cousin lives there and I was planning to do a trip there in the near future :-)
<robtaylor> carlos: brilliant :)
<carlos> so I will tell you it if I go ther (but I doubt it will be before January
<robtaylor> pitti: hmm, curious, this key doesnt appear in the device manager
<pitti> robtaylor: hmm, but still it appears in "Disks"?
<robtaylor> carlos: i was thinking i might pop down to the the canonical meeting in december..
<pitti> robtaylor: this is really odd
<carlos> robtaylor: that could be really good
<robtaylor> pitti: yep, sda1 is in Disks, hal claims that the only usb devices it knows about are hubs
<robtaylor> pitti: and the key is definitly plugged in, and manually mountable
<pitti> robtaylor: I never really dealt with the live CD (just tried whether it boots), but something seems to be _severely_ broken on it
<pitti> robtaylor: you mean the stick is contained in /etc/fstab?
<robtaylor> carlos:yep :) i'll try and save up a spair couple of days holiday :)
<robtaylor> pitti: no, yes, maybe=).. fstab has /dev/sda1. 
<pitti> robtaylor: THAT is the error
<pitti> robtaylor: it shouldn't be there for our tools to work
<robtaylor> pitti: ahhhhh
<pitti> robtaylor: of course, if /dev/sda1 is in fstab, you can "mount" it
<robtaylor> its morphix's auto fstab stuff clashing with your pmount stuff
<pitti> rabidbt: I suppose
<pitti> robtaylor: I suppose
<pitti> rabidbt: sorry, wrong address, should be robtaylor
<robtaylor> pitti: nono. when i say i can mount the usbkey i mean uif i sudo mount /dev/sda /mnt/bla it workd
<pitti> robtaylor: in an installed Ubuntu system, "mount /dev/sda1" will fail since it is not in fstab
<robtaylor> mount /dev/sda1 faile here anyway as that device doesnt exist
<pitti> robtaylor: does it work with "pmount /dev/sda" (without sudo)?
<sivang> Morning all!
<robtaylor> pitti: what should be in fstab?
<pitti> robtaylor: so /dev/sda is not in fstab?
<pitti> robtaylor: actually no usb devices should be in fstab
* sivang hugs pitti
<robtaylor> pitti: no, /dev/sda1 is
<pitti> Hi sivang
<pitti> robtaylor: okay, but this should not interfere with automounting of /dev/sda
<pitti> robtaylor: it could just be that the partition table of the stick is somehow brokeb
<pitti> robtaylor: broken
<robtaylor> pitti: there's quite a lot in fstab, generated by morphix
<robtaylor> pitti: i tod you, its unpartiond.. partioned keys work fine
<pitti> robtaylor: hmm, so if "pmount /dev/sda" works, then it's a hal fault
<robtaylor> pitti: pmount /dev/sda is fine
<robtaylor> so its hal
<robtaylor> can i get any messages out of hal easily?
<robtaylor> (livecd - no syslog...)
<pitti> robtaylor: you can
<Mitario_> lo everyone
<pitti> robtaylor: sudo killall hald
<pitti> robtaylor: unplug your stick
<pitti> robtaylor: sudo hald --drop-privileges --verbose=yes --daemon=no
<pitti> robtaylor: then stick your USB thingy and watch the messages
<seb128_> hi Mitario_
<robtaylor> pitti: hmm, absolutly nothing
<robtaylor> i thin kthis is a kernel->hotplug issue
<pitti> robtaylor: but at least you see some messages at hal startup?
<robtaylor> pitti: yeah, lots at hal startup as it finds everything else
<robtaylor> pitti: just abosolutly nothing when i insert this key :/
<pitti> robtaylor: then I think it is a kernel bug
<pitti> robtaylor: what does 'dmesg | tail' say after plugin?
<robtaylor> pitti: ok, this is somewhat odd.. 1) two drives (sda ans sdb) are attached
<robtaylor> pitti: hmm ah, only the 1st time.. hmm
<robtaylor> pitti: anyway  ldm_validate_privheads(): Cannot find PRIVHEAD 1. unable to read partition table
<robtaylor> which i'd expect =)
<pitti> robtaylor: can you stick all this into the bug report?
<robtaylor> pitti: yeah, sure
<pitti> robtaylor: thanks!
<robtaylor> pitti: it seems kernel bound too.. i'm going to spend a bit of time building a morphix kernel with from the stock ububtuy kenerl
<robtaylor> pitti: should i assign the bug to you?
<pitti> robtaylor: sounds like a kernel bug, please assign it to a linux package
<pitti> robtaylor: leave the assignee field empty
* Kamion dives deep into the choose-mirror merge for hoary
* Kamion whacks fabbione for editing generated files but not editing the source :)
<fabbione> uh?
<fabbione> which generated file?
<Kamion> fabbione: debian/choose-mirror.templates
<Kamion> (generated from debian/templates-in)
<Kamion> I've nearly finished the merge now, looking good so far
* fabbione evily removes the macintosh gb fix from x.org
<fabbione> strange...
<fabbione> but than.. it's not generated at build time
<fabbione> otherwise i would have noticed
<Kamion> it's generated by make, so will depend on timestamps etc.
<Kamion> it's possible you disabled the generation as part of the Mirrors.masterlist stuff too, I guess
<Kamion> I only noticed because the set of patch hunks that didn't apply were inconsistent
<fabbione> i see
<fabbione> i didn't notice... but anyway it shouldn't be a difficult merge
<fabbione> i don't remember changing that much into choose-mirror
<fabbione> and i also think joeyh did merge some of the proxy detection thingy
<fabbione> at least i gave him the code and the patches
<Kamion> yeah, he did
<fabbione> nice :-)
<Kamion> uh, no, he just merged some of the fixes actually
<Kamion> not the tcp_syn_retries stuff
<fabbione> there was only one real fix about a call to free a string iirc
<Kamion> the merge is mostly just painful because of .po files; I'm beginning to learn how to semi-automate that
<fabbione> Kamion: the tcp_syn_retries thing is still questionable.
<fabbione> i consider it a hack
<fabbione> but without it, the tcp stack takes ages to go in timeout
<Kamion> *nod*
<fabbione> if there is connectivity to archive, but it is let say unstable
<fabbione> than the syn won't help at all
<Kamion> bleh, I do effectively have to re-brand .po files though
<Kamion> I can automate the msgid changes but not the msgstrs
<lamont> moo
<robtaylor> lamont: moo
<robtaylor> lamont: umm, i'm seeing some oddness with the kernel that gets used on the livecd..
<robtaylor> lamont: and that umount proc problem just went away the second time i built. i managed to analyse the 1st one though, as the cause was /usr/sbin/acpid-c/etc/acpi/events-s/var/run/acpid.socket staying running and holding open a file on proc
<robtaylor> la
<robtaylor> lamont: quite whty it didnt die the 1st time, but worked the 2nd time is beyone me tho =)
<lamont> interesting
<robtaylor> lamont: where does the kernel used for livecd boot come from?
<lamont> morphix
<lamont> well, morphix derived
<lamont> delivered by the morphix dude
<robtaylor> lamont: should it have all the ubuntu patches installed?
<lamont> robtaylor: that was a design decision that will be fixed in hoary
<lamont> which is to say, 'no'
<lamont> is spain 120 or 240V power?
<Keybuk> 120
<pitti> Keybuk: sure?
<pitti> Keybuk: it's Europe, we should have sane voltages
<Keybuk> actually
<Keybuk> no
<Keybuk> sorry
<Keybuk> 230V 50Hz
<pitti> right
<Keybuk> stuck that on the Wiki
<fabbione> try to find a picture of the plugs
<Keybuk> fabbione: already done
<lamont> twin straight round prongs, I expect...
<Keybuk> http://kropla.com/!c.htm
<lamont> anyone need a netgear wall-wart?
<Keybuk> same as Denmark/Italy
<thom> which of the 375 thousand wikis have you added it to?
<Keybuk> thom: canonical
<daniels> 230V!
<daniels> spain is love.
<lamont> then again, maybe I'll keep my european-wall-wart for the netgear, and just bring that with me.
<robtaylor> lamont: what was the reason for that design decision? (i ask as I'm planning on making a kenel with the morphix patches and the ubuntu patches..)
<Keybuk> I still like the World Electric Guide's snide comment about UK power
<Keybuk> "Although /officially/ 230V ..."
<daniels> Keybuk: yeah, we're officially 230, but it's often stated as 240
<elmo> aren't we 240 ?
<daniels> either is within tolerance
<Keybuk> elmo: mostly 240V
<Keybuk> but the officialdom says 230 to "be inline with Europe"
<robtaylor> ahh
<jdub> rburton: ping
<Keybuk> 240V is in allowed tolerances, so the fact that UK power isn't really 230 isn't *that* important
<lamont> robtaylor: livecd uses a funky overlay technique to do some things - patches available for 2.6.7, but not 2.6.8*, being worked on for 2.6.9
<Keybuk> though 250V (which it can spike to) isn't <g>  but we don't talk about that
<robtaylor> lamont: ahh, umm, stiinky
<lamont> so liveCD is 2.6.7+morphix patches, install CD is 2.6.8.1 + ubuntu patches.  Hoary will be 2.6.x + morphix/ubuntu patches
<lamont> robtaylor: very Steeeeeenkyyyyyy
<robtaylor> lamont: mini_fo, i presume :)
<lamont> that's the bastard
* robtaylor strokes chin thoughtfully
<jdub> lamont: so i was wondering
<lamont> btw, select on tcp sockets results in a segv from the kernel. :-(
<rburton> jdub: pong!
<jdub> lamont: and when i was wondering
<jdub> lamont: i wondered if cachefs could fill the role of morphix's overlay crack
<robtaylor> lamont: morphix kernel?! gah!
<jdub> rburton: you on jabber?
<rburton> jdub: aye
<lamont> robtaylor: and that looks like it's all mini_fo derefing a null pointer..
* robtaylor shudders
<lamont> jdub: dunno yet, but we need something more designed and less crackful
<robtaylor> jdub: the basic idea isnt too crackful, i dont think
<jdub> lamont: i have the sneaking suspicion that cachefs will help here
<jdub> rburton: (you're not listed as online - did you get those messages?)
<rburton> hm, nope
<lamont> jdub: cool - we'll have to look at that for the merge
<robtaylor> jdub: is that the same as the solaris cachefs?
<rburton> jdub: aha: server connect failed when i try to chat to you
<jdub> robtaylor: dunno
<robtaylor> jdub: (reading  lkml) yep seems like it could do the same job
<robtaylor> generic union mounts are the true solution though
<robtaylor> which is what mini_fo is trying to do... :S
<Kamion> msgmerge -C choose-mirror-0.045ubuntu8/debian/po/de.po choose-mirror-1.06/debian/po/de.po choose-mirror-1.06ubuntu1/debian/po/de.po
<Kamion> that seems to work not too badly (provided you've already done debconf-updatepo in choose-mirror-1.06ubuntu1
<Kamion> )
<Kamion> you need the -C <po-from-warty> otherwise it assumes that all the warty-branded translations are obsolete
<hornbeck|sleep> oh, people love to take things out of context
* lamont takes kids to school.  bbiab
<Kamion> hmph, msgmerge seems to have trouble with .po files in different encodings
<pitti> jdub, mdz: can I please get approval for #2745 and #2753?
<jdub> one sec
<jdub> pitti: both approved
<pitti> jdub: thx
<pitti> jdub: is the version number okay?
<pitti> jdub: it's a bit odd, by now we only have an non-approved standard to version security uploads
<pitti> jdub: 0.14.1-2ubuntu0.1
<azeem> the url to the patches on http://www.ubuntulinux.org/support/patches is broken
<jdub> pitti: hrm, seems fine to me, but mdz may have other opinions
<azeem> on a related matter, 'When Ubuntu developers fix bugs that are also present in external packages - from other distributions or from upstream - we make that patch available on our web site' does not apply to enhancements, only bugs, right?
<jdub> pitti: more of a q for mdz :)
<pitti> jdub: okay; he must approve the uploads anyway, once they are uploaded to the queue
<jdub> azeem: should generally be both, but it's been pretty hectic during the release
<jdub> azeem: a lot of those will fall out during our big merge
<jdub> azeem: also, some features are just not upstreamable
<azeem> sure, okie
<pitti> elmo: are uploads to warty-security automatically synced to hoary if hoary's version is lower? If so, I could close the relevant bugs, otherwise I must leave them open
<elmo> pitti: no, they're not
<pitti> elmo: okay thanks. It really gets time for a proper bug tracking system which tracks versions...
<robtaylor> where can i find the ubuntu kernel patches?
<robtaylor> is anyone working on 2.6.9 yet?
<Kamion> Keybuk: merged debootstrap and choose-mirror, you can take those off your list
<Kamion> Keybuk: am I OK to go through and start merging d-i packages with .po file updates? I think I've got the hang of doing that now
<Keybuk> sure
<Kamion> cool
<Kamion> I'm trying to gradually automate as I grow to understand it
<Keybuk> as you understand how to automate, let me know :)
<Keybuk> ChangeLog I'm doing by basically stripping the context and turning them into 0,0 +1,x patches (stick this at the top)
<fabbione> seb128: you around?
<seb128> yes
<fabbione> seb128: see #d-d
<fabbione> seb128: thanks :-)
<Kamion> debian/po/ is roughly: merge everything else; debconf-updatepo; copy warty, debian, hoary (so far) to separate directories; for each .po file in hoary do msgmerge -C warty/$x.po debian/$x.po hoary/$x.po > new/$x.po; fiddle about lots with corner cases
<Keybuk> ouch
<Kamion> it's better than rebranding from scratch :)
<Keybuk> oh yes
<Keybuk> what's the debconf-updatedo bit do?
<Kamion> updates debian/po/templates.pot with new source references and then updates debian/po/*.po with new source references, fuzzy markers, etc.
<Kamion> it confuses msgmerge much less if you do this first
* daniels stares at #2759.
<Kamion> debconf-updatepo is a command to run frequently on anything with debian/po/
<Keybuk> right
<robtaylor> anyone.. whats the name of the kernel image in ubuntu? act-cache show kernel-source-2.6.8 just gives me debian sources... ~(i have warty main pinned at 1 ;))
<seb128> uploads to hoary are open ?
<robtaylor> s/image/source
<tseng> linux-source
<Kamion> robtaylor: linux-source-2.6.8.1
<robtaylor> Kamion: thanks :)
<Kamion> Keybuk: of course, for packages where we haven't changed debian/po/ it's not worth bothering ...
<robtaylor> lamont: when you get back..  on sunday Oliver released mini_fo patches for kernel>=2.6.8.1
<Keybuk> Kamion: I guess for ordinary po/ that msgmerge might work too?
<Keybuk> any particular reason you use warty as the compendium?
<Keybuk> and not latest-debian ?
<Kamion> Keybuk: should do
<Kamion> Keybuk: well, the primary source of new translations is latest-debian; warty is a backup
<Kamion> the goal is really to get us into sync with the latest translations in d-i, which are going to be superior to whatever we have
<Keybuk> right
<Kamion> I think I've understood def.po and the compendium the right way round
<Kamion> Keybuk: are you going to be doing a mass upload of merges, or what?
<Keybuk> Kamion: I think the basic idea is to do the merges as automatic as possible
<Keybuk> for any that it works, I'll upload
<Keybuk> any left will have a source package and a "lost hunks" patch file alongside
<Kamion> ok
<Keybuk> where the source package will be merged as automatic as possible, with anything conflicting to be resolved
<pooh_> hi again all
<sivang> oops, changed nicks
* netjoined: irc.freenode.net -> sendak.freenode.net
<lucas_> hi
<lucas_> Kamion: when you generate CDs using debian-cd, are you using build.sh or build_all.sh ?
<lamont> robtaylor: cool
<robtaylor> lamont: i'm looking at building a 2.6.8.1 morphix kernel... though its not obvious what should go in or not..
<robtaylor> anyway, so it'll be based off the warty realease kernel, which hopefully will make some things less broken
<lamont> yeah - no clues here either, but there is a source drop on www.morphix.org/debian
<robtaylor> (though not the device node/pipe/ problems)
<robtaylor> lamont: good point, that'd be a good place top start
<pitti> mdz, jdub: can one of you please approve #2743?
<Keybuk> - Skipping control-center (warty > debian)
<Keybuk> ... that's a bit better <g>
<Kamion> lucas_: build.sh as it happens, but you can use either
<Kamion> lucas_: (as long as you change build_sll.sh to have the right list of architectures)
<Keybuk> heh, a few packages are bogus errors ... we actually reverted to debian
* Keybuk adds a "if warty_s.version < base_s.version: continue"
<rburton> jdub: there?
<sid77> hi
* lamont pitys anyone foolish enough to have changed sources.list to point to hoary this early
<rburton> what broke so quickly?
<lamont> rburton: we sync'ed all the unmodified packages from sid, and they're building now.
<rburton> oh fun
<lamont> which basically means that large parts of things will quite likely be uninstallable, etc.
<lamont> because none of the need-to-be-merged packages are included in that...
<lamont> rburton: the key thing to remember is that hoary will be _REALLY_ unstable/broken for a while.
* Kamion flies blind trying to merge main-menu
<Kamion> pretty much no possible way to test these changes until they've all been made
<elmo> Kamion: sorry, just to confirm, I can trash everything but latest installer-$arch and daily-installer-* ?
<elmo> [I asked that earlier, right before a netsplit, if you already answered, I missed it, sorry] 
<Kamion> elmo: didn't see it, but yes, and you can trash daily-installer-* in warty if that's still possible
<Kamion> (or advisable)
<elmo> k, th
<elmo> x
<thom> ...bye
<Kamion> thom: I was resisting manfully
<thom> i couldn't help myself
<thom> arrgh. i really struggle to type "myself". if i'm not concentrating my fingers go for "mysql"
<thom> damn sys admin jobs anyway
<sid77> lol
<Kamion> Keybuk: more fun; if the encoding of a .po file has changed then you have to iconv the one from warty before running msgmerge
<Keybuk> Kamion: I think we should make daf write some python to deal with this for us :o)
<Keybuk> "here's three po files, make me a fourth"
<daf> if the PO files declare their encodings properly, it probably would be fairly easy to automate
<Kamion> they pretty much always do in d-i at least; too much stuff breaks obviously if the encoding is wrong
<robtaylor> Kamion: just looking over hoary goals... whats 'kickstart' ?
<sivang> robtaylor : a system that manages mass installs
<sivang> robtaylor : or allows for
<thom> the redhat automated install system
<robtaylor> ah.
<robtaylor> groovey
* sid77 bye
<Kamion> Keybuk: P.S. it'd be nice to have it flagged somehow when the msgstr upon which a branded msgstr is based changes ...
<Kamion> Keybuk: unfortunately I don't think there's enough metadata in the .po file for that :-(
<daf> Kamion: no, the PO format doesn't support that directly
<daf> Kamion: I wonder if we could emulate it but putting data in comments or something and writing a tool that compares them
<pitti> mdz: Morning! If the meeting is finished and you have some time, can you please approve #2743 (libc6 security bug)? TIA
<pitti> mdz: s/If/When/
<mdz> pitti: the meeting is not finished yet
<mdz> pitti: but feel free to join us :-)
<pitti> mdz: I'll do, up to now I was buried in work
<fabbione> new X.org build logs are scary
<mdz> pitti: yes, you inherited a number of bugs during the night :-)
<fabbione> they look much worst than xfree86
<pitti> mdz: what happened to Nathaniel BTW?
<mdz> pitti: nathaniel will not be on the team for Hoary
<fabbione> mdz: it seems amazing.. compiling the X.org monolitch tree i am getting hundreds of extra warnings i wasn't getting before
<mdz> fabbione: what kind of warnings?
<fabbione> duplicate declarations mostly and function without prototypes
<lamont> are some of the auto-merges getting uploaded?
<fabbione> all stuff i wasn't getting before
<fabbione> ../../exports/include/X11/extensions/xtrapdi.h:86: warning: function declaration isn't a prototype
<fabbione> stuff like this one
<fabbione> i did compile libxext and never got this stuff
<mdz> fabbione: this is the same code organized differently, or different code?
<fabbione> same code
<fabbione> from modular (simulated) back to monolitich
<fabbione> (or how the hell monolitich is spelled)
<lamont> monolithic
<elmo> does anyone have a machine where snmpd randomly flakes out under even marginal load?
* lamont feels _helpful_...
<fabbione> lamont: thanks :-)
<elmo> I've even tried nicing the stupid thing up
<fabbione> elmo: ask Jochen (the maintainer)
<fabbione> he is really cool at debugging stuff
<fabbione> i can guarantee for him :-)
<elmo> fabbione: hmm,k, will do, thanks
<fabbione> no problem
* Keybuk decides that the 50-odd packages for which we never uploaded the original debian version will be funny
<Keybuk> lots of "ignored" in the patch output
<Keybuk> evolution  <base: 1.4.6-3>  <warty: 2.0.2-0ubuntu2>  <debian: 2.0.2-3>
<lamont> Keybuk: I wonder if that's because we sync'ed, and immediately uploaded ubuntu1...
<lamont> actually -0ubuntu* means probably not
<lamont> Keybuk: I think we uploaded evo 2.0 before debian did...
<mdz> pitti: the masters of the universe discussion is happening; you seem to have some ideas, so it would be great to have your input
<mdz> elmo: flakes out how?
<pitti> mdz: I'm already reading
<mdz> pitti: ok :-)
<mdz> pitti: what time do you need to leave today?
<pitti> mdz: in about 30 minutes
<mdz> I know you normally leave around this time, but we need to get together and review pending security issues
<elmo> [26-Oct-2004 10:55:02 ]  Retrieved data for icmp (0): 30740,310,4904,4,0,0,0,25288,544,0,0,0,0,27285,0,1997,0,0,0,0,0,25288,0,0,0,0
<elmo> [26-Oct-2004 10:55:02 ]  Retrieved data for tcp (0): 35117,23001,45,27467107,25816883,83454
<elmo> [26-Oct-2004 10:55:12*]  No response from "chinstrap" [82.211.81.135] .161
<elmo> mdz: i.e. the cricket collector just timesout
<pitti> mdz: I will return about 2100 UTC, will that be enough?
<mdz> pitti: oh yes, that's fine
<elmo> it's not everytime, but it's several times a day
<pitti> mdz: of course I can stay here and skip sport another time...
<mdz> I will be around for another 12+ hours
<pitti> mdz: okay,then I would really like to have some physical training again :-)
<Mitario> hi everyone
<nasdaq4088> hi mitario
<mdz> elmo: I have seen that, yes
<mdz> dunno which bit is doing the sucking in that equation
<elmo> IM (previous) E, it's a box under heavy load
<bluefoxicy> o.o
<elmo> but it seems to happen even when chinstrap _isn't_ loaded
* bluefoxicy snickers at the mention of 'chinstrap'
* tseng wishes for ops to +q bluefoxicy in yet another channel
<bluefoxicy> tseng
<bluefoxicy> what the heck, are you in every channel or waht
<tseng> indeed.
<bluefoxicy> how much bandwidth does xchat use over there?
<tseng> irssi
<bluefoxicy> how much bandwidth does irssi use over there?
<tseng> it runs on one of the oftc nodes
<tseng> so im localhost to a lot of things
<bluefoxicy> yeah yeah, I bet I could DCC you full .ogm anime collections of .hack//sign and still be dwarfed for BW usage by the sheer volume of text coming down your pipe.
<bluefoxicy> anyway.
<bluefoxicy> I was told to discus stuff here, just waiting for the CC meeting to end so that people aren't busy (plus I need to organize my thoughts)
<tseng> i think what you want to do should happen in a seperate branch or something
<tseng> and get merged back in the next cycle
<fabbione> humpf..
<fabbione> we need a newer version of xrender
<bluefoxicy> tseng:  yes
<bluefoxicy> tseng:  I don't expect people to just start hacking on the stable system; getting it working in the lab (a separate branch to be merged is a lab) first is a no brainer.
<bluefoxicy> tseng:  but I do want these things in mainline.
* bluefoxicy wants to avoid a fork though; we don't need yet another distro floating around, esp. not the 10,000,000th Debian based fork.
<tseng> did you even install ubuntu yet?
<bluefoxicy> yeah
<bluefoxicy> on a 1.4 gig partition
<thom> uh, one of ubuntu's aims is to encourage derivatives
<bluefoxicy> it looks like someone kicked my hard drive  :)
<bluefoxicy> thom:  The effect I'm aiming at is nuclear; I'm trying to incite revolutionary change across all distributions and even potentially across the entire computer industry.
<bluefoxicy> everything starts somewher.
<elmo> crap, we need to do the gnutls11 migration for hoary
<bluefoxicy> tseng:  i need a filesystem that can compress individual files transparantly
<bluefoxicy> I have 1.4G but ubuntu-desktop wants 1.8
<mdz> bluefoxicy: you don't need a compressed filesystem, but rather a larger partition :-)
<elmo> http://people.ubuntu.com/~james/packages_to_merge.txt
<elmo> btw
<thom> are we going to ignore the gcc3.4/4.0 transition too? :-)
<elmo> thom: there hasn't been one in sid?
<bob2> bluefoxicy: boot with the archive-copier disabled and you can install with 1.4GB
<bluefoxicy> bob2:  what's final space usage
<mdz> elmo: that's the list of stuff that Keybuk said would be done by this afternoon, right?
<mdz> ;-)
<thom> sorry, that's what i mean. how are we going to deal with gcc3.4?
<doogie> does ubuntu do their own security, or do they reuse debian security releases?
<bluefoxicy> bob2: and would it be possible to download/install/wipe cycle one at a time?
<thom> leave it in 3.3 abi mode?
<bob2> bluefoxicy: ~1.4GB or so for the final install
<thom> doogie: our own
<bob2> bluefoxicy: install one paclage at a time? no.
<bluefoxicy> bob2: actually, I can use a tmpfs to store the archives on too (I do that to build crap)
<elmo> mdz: indeed... IIRC, he even said, "y'all can beat me senseless if it isn't"
<elmo> tho maybe I made that up
<bluefoxicy> bob2:  it needs to be <1.4G
<thom> ...maybe
<bluefoxicy> /dev/hda3             1.4G  881M  514M  64% 
<bluefoxicy> bob2:  where do archives get downloaded to by apt
<bluefoxicy> I would like to mount a tmpfs there.
<bob2> bluefoxicy: /var/cache/apt/archives/
<bluefoxicy> hmm.  Apt will bitch if partial/ isn't in there (no, it won't make it itself, sarge gave me that problem)
<Kamion> yes, that's kind of annoying
<bluefoxicy> it should be fix so that a ram based filesystem can be mounted there; I usually have 2G swap and mount 2G tmpfs (I have 768M ram)
<bluefoxicy> fixed
<bluefoxicy> wtf, do I speak english or not
<Kamion> don't see why you couldn't mount a ramdisk there provided you did mkdir partial in the script that mounts it
<Kamion> seems fairly trivial
<bluefoxicy> yeah
<bluefoxicy> except that you can't make scripts in fstab :)
<bluefoxicy> heh
<bluefoxicy> options:
<Kamion> plenty of options
<bluefoxicy>  -o `/sbin/mount_tmpfs`
<bluefoxicy> you could hack up a script to do that :P
<lamont> mdz: you want ftbfs bugs for hoary build failures yet, or wait until we get more of it there?
<mdz> lamont: if the package is up to date (synched or merged), a bug should be filed
<bluefoxicy> Need to get 230MB of archives.
<bluefoxicy> After unpacking 679MB of additional disk space will be used.
<bluefoxicy> does the 679 include the archives?
<Kamion> don't think so
<Kamion> could be wrong, but I don't think so. check the apt source if you want to be sure
<thom> pretty sure it doesn't
<lamont> mdz: was more of a priority question.
* lamont needs to spend some time on the ogre buildd model... (Ogre's are like onions...)
<tseng> mmm, layers
* lamont thought donkey had some better reasons, though..
<amu> lamont: ? 
<lamont> amu: Shrek references
<lamont> (movie)
<amu> hehe i didnt saw it 
<lamont> amu: specifically, the current ubuntu buildd infrastructure has the neat little bug that main packages are sometimes built with universe packages satisfying the build-depends, instead of main packages.
<lamont> amu: Shrek (an ogre) waxes philosophical about onions and their similarities to ogres at one point
<amu> lamont: local or home editon ? 
<lamont> amu: we're talking buildd here, not liveCD
<lamont> packages in the repo
<elmo> mdz: do you want me to continue doing seed syncage via you and jeff?
<mdz> elmo: yes
<bluefoxicy> /dev/hda3             1.4G  1.3G  127M  91% /mnt/ubuntu  :D
<Keybuk> elmo: can you install dpkg-dev on rookery?
<elmo> done
<Keybuk> thanks dude
<Keybuk> * Considering acpid
<Keybuk> * Building acpid_1.0.3-21ubuntu1.dsc
<Keybuk> \o/
<Keybuk> that seems to be working then
<Keybuk> Stargate and dinner time, me thinks
* lamont goes to lunch, finally
<mdz> KeyserSoze: HEY
<mdz> er
<mdz> that was meant for keybuk
<Kamion> elmo: what's the procedure in cases where all the Ubuntu changes have been merged into Debian, so we just need to throw away our changes and resync?
<marga> Kamion: I was just looking at the Installer Team page and you are the only one listed there... Are you working alone on ubuntu installer or are the others just not listed?
<Kamion> marga: mostly alone right now, occasional help from some of the other core team guys like Fabio
<Kamion> marga: although of course so much of it comes from d-i that it's not a total disaster that way :-)
<marga> Kamion: yeah, I guess... :)
<Kamion> but all the same more hackers to distribute bugs among would be a good thing
<hornbeck> mako: you around?
<mako> hornbeck: yes, a little distracted right now.. finishing lunch, give me a couple minutes
<mjg59> PXEBooting the craptop reveals it has a GUID of 22222222-2222-2222-2222-22222222222
<elmo> Kamion: just let me know
<Kamion> elmo: mail to @canonical.com?
<elmo> Kamion: yeah, why not
<Kamion> ok
<plovs> hornbeck, the wiki has been moved
<plovs> hornbeck, but is still beta
<doogie> er, it has?
<doogie> I thought ubuntu was supposed to be more stable.
<doogie> but you guys have moved the wiki.
* doogie hides
<daniels> what is it with insecure tempfile creation every other day?
* plovs kicks doogie anyway :)
* hornbeck is out for a few
<asw> mako: drop me a line re NYC... 
<azeem> sabdfl: I heard you're delivering a speech tomorrow in Frankfurt?
<sabdfl> azeem: yes, keynote "taking linux to the desktop"
<sabdfl> any suggestions on the topic?
<amu> LinuxDesktops in Governments ;)  
<tseng> erotica and productivity
<tseng> er
<azeem> sabdfl: something involving 'pants off', but I'm not sure about details
<azeem> sabdfl: it's at 11:30, right? I'll need to getup early then :-/
<sabdfl> tseng: you just helped me make my mind up about the desktop i'll be showing :-)
<tseng> haha.
<bluefoxicy> heh
<bluefoxicy> why do I suddenly think of half my friends, who all have catgirls on their desktop wallpapers, with either barely anything or just the right angle to prevent exposure
* bluefoxicy has a nekkid catboi for his background, but his leg's in the way :o  cute though.
<tseng> we were thinking along the lines of soft porn for straight folks
<bluefoxicy> heh
<bluefoxicy> wasn't the recent theme centered around some naked guy
<tseng> but i guess its your desktop
<bluefoxicy> Ubuntu Linux:  Bodies are Beautiful
<tseng> well, a guy with his top off is less suggestive than a chick with her top iff
<tseng> off.
<bluefoxicy> heh.
<bluefoxicy> Yeah, he was cute though
<tseng> er, look at him smiling on the splash screen, he looks silly
<bluefoxicy> yeah, but cute
<tseng> i cant say what he looks like on the gdm theme
<tseng> because all us straight guys get sucked in the the "NIPPLES OF DOOM"
<tseng> on the blonde chick
<bluefoxicy> lol
<bluefoxicy> what
<bluefoxicy> I didn't even notice nipples
<bluefoxicy> what are they poking through her top or something?
<tseng> they are sticking out
<bluefoxicy> o_O
<tseng> hey im off to work
<bluefoxicy> exposure?
<bluefoxicy> later
<tseng> no
<bluefoxicy> ok
<bluefoxicy> that'd be kinda bad PR
<bluefoxicy> Ubuntu Linux:  Next release, softcore penguin porn
<bluefoxicy> . . . omg hello.jpg XD
<amu> sooo my buildenv looks fine, at least i got a fat ISO ;) *burning*   
<pitti> mdz: Hi, I'm back. Have you got a minute?
<mdz> pitti: yes
<mdz> my network was hosed, but I've just fixed it
<pitti> mdz: can you please approve #2743?
<pitti> mdz: in addition, I wanted to ask you whether I should prepare some USNs and which list to send them to
<mdz> pitti: yes, you should
<mdz> pitti: use the format that I used for the first two
<mdz> send them to ubuntu-security-announce, Bcc'd to bugtraq and full-disclosure
<pitti> mdz: Oh, I need to subscribe to this list
<mdz> pitti: that would be good, yes :-)
<mdz> pitti: do you have a login to edit the website?
<Kamion> mdz: if, hypothetically, I wanted to make a security fix to warty/universe, I take it you want backports there too?
<mdz> we also have a security errata section on the website now
<mdz> Kamion: yes
<pitti> mdz: I got a password, never tried it though; should be possible
<mdz> Kamion: my current feeling is that we can be liberal with universe things which FTBFS
<mdz> and for other things, we should have criteria very similar to main
<Kamion> fair enough, I'll try to pick out the relevant changeset
<Kamion> are we sending USNs for universe in the event that we do security updates?
<Kamion> (this is off the clock - I'm doing the upload to Debian anyway)
<elmo> mdz: we do?
<mdz> elmo: we do what?
<mdz> Kamion: good question, hadn't thought about it
<pitti> mdz: is there a tool which generates these pacakge lists with md5sums automatically?
<elmo> have a security errata section
<elmo> 'cos /security/ still seems to go to the silly team page
<mdz> elmo: it's hidden under 'documentation' at the moment
<elmo> I think we should do USN's for universe just with the usual "this is not the component you want to use </hand-wave>" disclaimer
<mdz> http://www.ubuntulinux.org/support/documentation/usn/errorreferencefolder_view
<mdz> pitti: yes
<mdz> pitti: amber generates them
<elmo> that is.. well hidden :)
<pitti> mdz: hmm, can I download it from somewhere? 
<elmo> mmph, we don't even have prettified HTML versions :(
<mdz> elmo: where does amber send that stuff yet?
<mdz> elmo: cut me some slack, I did it by hand :-)
<elmo> mdz: katie@security.u.c -> team@security.u.c -> you
<mdz> elmo: by the way, does security@ubuntu.* go to the right place?
<elmo> hmm, no, probably not, I'll fix
<mdz> elmo: please add pitti to team@
<elmo> k
<mdz> so that he gets the amber mails
<pitti> mdz: ah, this amber stuff comes by mail whenever something is uploaded to *-security?
<mdz> pitti: no, it comes when amber is run
<elmo> security@canonical too, you think?
<elmo> pitti: amber is what actually releases the security uploads into the archive
<mdz> elmo: security@canonical.com = your website has been defaced, dude
<mdz> in which case, I think that's all you :-P
<mdz> pitti: I need a 10 minute workrave break and then we can go over this stuff
<elmo> 10 minute?? that's workrave on the "slackers'r'us" setting ;-P
<pitti> elmo: nice; since the stuff that I uploaded today is not yet installed, I should get the amber mails now, too, right?
<pitti> mdz: no problem, I'm fixing imagemagick in the meantime
<elmo> yeah
<sabdfl> night all
<elmo> night sabdfl
<Kamion> mdz: erk, we have putty 0.54 even, and I never noticed :(
<Kamion> so I'll need to work out two changesets, since both 0.55 and 0.56 were security releases
<amu> mdz: did you got my mail from Indonesia InfoLINUX magazine?
<mdz> amu: yes
<amu> mdz: to whom i should forward those messages, i got many of them :) 
<mdz> amu: I am not sure that I understand the question in the email
<mdz> amu: is it asking whether there will be a gnoppix release in 2005?
<amu> mdz: good question :) i've no idea what they want from me, i ignored such requests in past :) well my short answer would be look to the web, thats probably not such polite, they expect :)   
<mdz> pitti: are you maintaining a list of pending security issues and their status?
<pitti> mdz: yes
<pitti> more or less in bz, and in a personal txt file
<pitti> mdz: those bugs who are pending need to be approved by you (currently 2743 and 2769)
<pitti> mdz: the bugs for which I uploaded packages to the security queue are open again with normal priority
<mdz> pitti: what about the ones I forwarded to you without filing bugs? are any of those still pending?  I don't remember how many there were
<elmo> what's the USN-<n>-<n> notation?  advisory number, and version of that advisory num ?
<pitti> mdz: so far that were only xpdf and cups
<pitti> mdz: but these should be settled
<Kamion> night all
<mdz> elmo: yes, same as Debian essentially
<mdz> Kamion: night
<pitti> Night Kamion
<pitti> mdz: the libpng stuff is also already dealt with
<mdz> pitti: we should add a security keyword or something to bugzilla
<mdz> pitti: can you give me a list of bug #s?
<amu> someone has a tip with #2697
<pitti> mdz: today I processed: 2743, 2744, 2745, 2762, 2769
<pitti> mdz: 2771 and 2748 are not yet processed by me
<mdz> pitti: have you uploaded them to the security queue?
<pitti> mdz: I uploaded 2744, 2745 ad 2762
<mdz> ok, leaving 2743 and 2769
<pitti> mdz: 2743 and 2769 need to be approved by you
<pitti> yes
<mdz> pitti: I am happy for you to upload to the security queue without waiting for approval
<mdz> pitti: just be careful with the version number
<pitti> mdz: okay, thanks. That eases the process a lot
<pitti> are the current version numbers okay?
<mdz> pitti: that way the packages can be built immediately, and we can base review on what is in the security queue
<pitti> i. g. if the last version was -2, the update would be -2ubuntu0.1
<mdz> there is less potential for error tat way
<mdz> s/tat/that/
<pitti> new: this was a new case today
#ubuntu-devel 2004-11-07
<pitti> mdz: ^
<pitti> mdz: but I think since we don't have NMUs in Ubuntu, this scheme should not clash with regular uploads
<mdz> pitti: this is not an easy question
<mdz> -2ubuntu0 << -2woody1, for example
<mdz> which is what the Debian security team would use
<pitti> mdz: right, but we don't use woody version numbers, do we?
<pitti> mdz: well, _if_ we update a woody version, then we need to think about a different scheme
<pitti> -2woody1ubuntu0.1
* pitti shakes
<pitti> would be consistent, but ugly
<pitti> but I think that won't happen very often
<pitti> mdz: okay, I uploaded glibc (#2743) and imagemagick (#2769)
<pitti> mdz: gee, we urgently need version (or at least distribution) tracking in our bts
<mdz> pitti: you are learning the pain of security :-)
* lamont_r chuckles
<pitti> mdz: I left the bug open for now (normal/target Hoary) until I upload them to hoary
<pitti> mdz: but I think I deal with Hoary when I fixed all other security bugs
<pitti> mdz: that okay for you?
<mdz> pitti: yes
<mdz> pitti: I highly recommend keeping your own todo list
<mdz> separate from bugzilla
<pitti> mdz: in any case
<mdz> pitti: fortunately sarge sorts below ubuntu :-)
<pitti> mdz: and etch, too :-)
<mdz> it should become part of our automated upgrade testing to ensure that this doesn't occur
<pitti> mdz: and at the time etch is actually released, I'm grandfather
* pitti hides
<pitti> mdz: you mean it does not occur that our updates sort below the current Debian stable?
<mdz> pitti: not only the current Debian stable, but anything that we support upgrades from
<mdz> woody->warty is a supported upgrade path
<mdz> so warty must be > woody
<lamont_r> mdz: I thought sarge would do 1.sarge...
<mdz> I believe we checked at one point
<mdz> and all of the packages in warty/main had higher version numbers than woody
<mdz> which is fortunate
<lamont_r> mdz: that won't always be true, you know...
<mdz> lamont_r: right, but we should ensure that it is true at release time
<mdz> until we fix this awful version number problem once and for all
<pitti> mdz: oh, gaim was missing
<pitti> mdz: according to my log, I already uploaded gaim to the security queue, but it is not yet in the security packages file
<lamont_r> mdz: Just thinking of the case where sarge happens to release just before the grumpy upstream version freeze, or some such.. :-(
<pitti> mdz: I just checked all my logs, gaim is the only security upload I forgot about in above list
<mdz> pitti: the security queue is different from the normal upload queue
<mdz> pitti: packages do not automatically go into the archive via security
<mdz> they must be processed by hand
<pitti> mdz: yes, that's why I'm asking whether it is still present
<mdz> gaim                        | 1:1.0.0-1ubuntu1.1    | source amd64 i386 powerpc     | 2 days old
<pitti> mdz: or whether I somehow forgot to actually upload
<pitti> ah, okay
<pitti> mdz: I prepared the first USN for gs-common, of course the package list is still missing.
<pitti> mdz: http://www.piware.de/usn-gs-common.txt , could you please have a short look? 
<mdz> pitti: great
<mdz> certainly
<mdz> pitti: the date should be right-justified
<mdz> but I think amber should do that for you now
<pitti> mdz: oh, amber also creates this template?
<pitti> mdz: I just copied the template from the website, where it is not justified at all
<pitti> mdz: fixed
<mdz> pitti: yes, amber will give you a template to be filled in
<pitti> very nice
<mdz> the website stuff is cut-and-waste from the emails I sent
<pitti> I prepare the stuff for the other packages and send them out as soon as I get the amber mail
<pitti> Probably not today any more, I'm exhausted and it's late
<pitti> and libc6 will take a while to build (took 4 hours on my machine)
<elmo> pitti: 30 mins in the DC :)
<pitti> elmo: okay, okay, you have better machines to play with :-)
<jbailey> pitti: How many passes is that?
<elmo> hmm, actually, it's 30 i386, 43 powerpc, 48 amd64
<pitti> jbailey: pardon?
<elmo> pitti: how many different versions of glibc do you build for giggles
<jbailey> pitti: processor/thread combinations.  In Debian on ia32, we usually have 3 (386-linuxthreads, 386-nptl, 686-nptl)
<pitti> I just tried it on my desktop (686)
<pitti> but I thought debuild would build them all?
<jbailey> 4 hours just seems awful high.
<pitti> I remember seeing much of the build log parts more than once
<elmo> jbailey: it's stock Debian source, so it'll be whatever debian does for 386
<elmo> s/stock/pretty-much \1/
<pitti> jbailey: I don't have the fastest machine, though :_)
* azeem once compiled glibc on 400 MHz notebook for Debian GNU/Hurd. It sucked.
<mdz> pitti: since we only upload source, it is important to test the binaries which are built by the buildds
<mdz> at least one arch
<jbailey> azeem: Debian GNU/Hurd takes about 4 times as long in my experience.  I usually leave 3 hours on my 1.8ghz p4.
<pitti> mdz: that's why I compiled the stuff and tested it, and why it took so long until I actually asked for approval :-)
<jbailey> (for linux)
<mdz> pitti: hm?
<jdub> yo jbailey 
<mdz> pitti: the binaries built by the buildds
<azeem> jbailey: it definetely wasn't 12 hours on my 1.8ghz p4
<azeem> (on Hurd)
<jbailey> g'morning Jeff. =)
<pitti> mdz: ah, I see
<azeem> more like 5 or 6
<pitti> mdz: sorry, confused
<jbailey> azeem: We do 3 passes on i386, though.  On the Hurd we only do one.
<azeem> ah :)
<jdub> mdz: how'd the meeting go? i fell asleep late last night putting pipka to bed
<seb128> hello jdub 
<jdub> pants off seb128 
<seb128> :)
<mdz> jdub: which one? CC?
<jdub> yeah
<mdz> it went pretty well, I was in and out a bit at the end
<mdz> jdub: mako has transcript and is preparing a summary
<jdub> cool
<mako> jdub, mdz: am planning on finishing that one tonight
<pitti> mdz: I have all USNs ready. I need some sleep, I will send them out tomorrow (when the amber mails hopefully arrived)
<pitti> Good night everybody!
<mdz> pitti: wait
<pitti> mdz: still here
<mdz> pitti: the amber mails will not arrive until I run amber
<mdz> and the advisories should go out immediately after that
<mdz> glibc does not seem to be built yet
<jdub> daniels: around?
<pitti> hmm, is there an approximate ETA?
<pitti> mdz: I can stay up for another hour, if necessary
<mdz> pitti: elmo is making some adjustments to amber
<mdz> pitti: which ones are you ready to send out?
<pitti> mdz: all but gaim
<pitti> mdz: I'm currently typing gaim
<mdz> pitti: ok. I have tested gaim and it works fine; I can't test MSN but I see no regressions in AIM/jabber
<mdz> pitti: which ones are the simple temporary file stuff?
<mdz> gs-common, glibc, gettext....?
<pitti> mdz: gettext, glibc, gs-common, postgresql
<pitti> mdz: do you have the two CC'ed mailing list adresses at hand?
<mdz> pitti: gaim, gettext, gs-common, postgresql are built and ready
<pitti> mdz: please give me some more minutes
<mdz> glibc and imagemagick are not built yet
<pitti> mdz: I need to change my subscription to bugtraq
<pitti> mdz: I subscribed as martin@piware.de, but I need my canonical address
<Kamion> mdz: I'm producing the required groff patch now, FYI
<mdz> Kamion: thanks, keep pitti informed
<mdz> pitti: bugtraq@securityfocus.com, full-disclosure@lists.netsys.com
<pitti> mdz: do I need to subscribe full-disclosure to post to it?
<mdz> pitti: I am not sure
<mdz> pitti: you need to be subscribed anyway
<pitti> mdz: okay
<daniels> jdub: sup?
<jdub> daniels: do you think composite-on-by-default is likely for hoary?
<daniels> jdub: we can try it, but I'm uncomfortable doing it without a fair bit of testing
<daniels> but if we test it in the hoary tree and it's not too bad, we can keep it on for main
<jdub> tempting
<jdub> though it's going to be different for different video cards, right?
<daniels> yeah
<daniels> due to render accel
<daniels> i think radeon's is pretty solid, and that in the nvidia binary driver can be a bit odd sometimes
<lifeless> is it easy to turn on/off ? I.e. a control panel ?
<daniels> lifeless: Section "Extensions"\n\tOption\t"Composite"\t"Enabled"\nEndSection
<daniels> it's not configurable on-the-fly
<lifeless> ah. perhaps that should be a goal - an option for folk to switch, but htey have to log out and in
<mdz> pitti: are you ready to publish?
<mdz> pitti: elmo is finished and I am ready to amber
<pitti> mdz: I don't get a confirmation email from netsys
<pitti> mdz: I subscribed several minutes ago...
<daniels> lifeless: mmm
<pitti> mdz: otherwise, bugtraq subscription is okay, all USNs are ready
<mdz> pitti: the important thing is that it goes to ubuntu-security-announce and the webiste
<daniels> lifeless: i'll see how it holds up in hoary; if it's stable enough for what we're doing, great, enabled per default.  if not, it'll be disabled per default, and I'm not so sure I don't want a shiny-things button.
<pitti> mdz: I can send the full-disclosure mail later if it has member-only posting 
<daniels> s/don't want/want/
<mdz> pitti: have you read the advisory guidelines I put in the wiki?
<pitti> mdz: not yet
<mdz> pitti: http://wiki.ubuntu.com/SecurityNotification
<pitti> mdz: ah, I read this
<mdz> pitti: for the temporary file vulnerabilities, the advisory should indicate with what privileges the overwriting takes place
<mdz> if it is the privileges of a user invoking a program, or a system process, etc.
<mdz> because this makes a big difference in the impact
<elmo> hmm, lamont has the buildds set to take too much
<pitti> mdz: hmm, I have to add this
<elmo> well, maybe.. might not matter too much, even 10 packages isn't going take too long on average, and worst case will screw us even if we have less
<mdz> pitti: let me know when you are ready for me to review the text
<mdz> elmo: what are we going to do about getting new packages from sid into hoary/universe?
<mdz> (rather than new versions)
<mdz> or are you already doing that?
<elmo> I'm going to deal with that in a bit.. also have to deal with removed packages, which is alittle more fun
<elmo> since we have no record of where non-Debian stuff in universe came from (whee)
<mdz> indeed
<elmo> can someone prioitize merging/clearing-for-sync libldap2 and any other gnutls using libraries?
<elmo> without that hoary's going to be severely broken dep-wise
<elmo> mdz: btw, I assume I'm okay that people don't need to bother you/jeff for clear-to-sync mails?
<Kamion> mdz: ok, uploaded to Debian, cced pitti on my mail to upstream
<mdz> elmo: correct
<mdz> elmo: dude, the merges are done
<mdz> Keybuk said they were finished this afternoon
* elmo hails keybuk's turing complete merge-meister
<Kamion> I guess that would explain why I still have the majority of uploads to hoary :P
<pitti> mdz: ready: http://www.piware.de/usn/
<pitti> mdz: I hope my English is not too bad at this time
<pitti> mdz: could you do some proofreading, please? For helping a USN author newbie? :-)
<elmo> Recently, Trustix Secure Linux discussed a vulnerabily in the
<elmo> discovered
<elmo> vulnerability
<elmo> (postgres)
* daniels stares at elmo.
<elmo>  way, which allowed a symlink attack for overwriting
<pitti> elmo: thanks, fixed
<elmo> I'd say: way which allowed a symlink attack to overwrite
<elmo> personally, but that's possibly just me
<Kamion> agreed
<pitti> elmo: I take the word of a native speaker
<elmo> same for gs-common then
<pitti> elmo: fixed both errors in all USNs
<pitti> and uploaded again
<elmo> A buffer overflow and two remote crashes were recently discovered in
<elmo> the MSN protocol handler.
<elmo> I'd say "gaim's MSN protocol handler"
<elmo> otherwise it sounds like MSN is buggy, IYSWIM
<pitti> fixed
<mdz> elmo: which is not altogether inaccurate, but irrelevant :-)
<mdz> pitti: reading now
<elmo> pitti: still misspelling vulnerability in postgres
<mdz> pitti: have you verified the CVE names against the CVE website?
<pitti> mdz: yes
<pitti> elmo: spell fixed
<elmo> "Since imagemagick might be used in custom printing systems," <- s/might/can/ is more idiomatic and solves the duplication in the next sentence
<pitti> done
<mdz> pitti: it is a good idea to run an aspell check on all of the text
<pitti> will do next time
<tseng> hiya
<mdz> pitti: s/files of/files with the privileges of/
<mdz> pitti: in at least gettext
<mdz> the files would not need to belong to that user, only be writable by them
<mdz> pitti: also s/overwrite/create or overwrite/
<pitti> mdz: fixed
<tseng> cool, jimmac is using ubuntu
<mdz> pitti: looks good
<mdz> pitti: ready to release?
<pitti> thumbs up! I even got my f-d subscription
<elmo> hey, that's a point
<elmo> we need a "who uses ubuntu" section on the website
<jdub> oh dudes
<jdub> http://primates.ximian.com/~jimmac/blog/Misc/Ubuntu
<jdub> ^ jimmac likes Ubuntu on his Mac
<tseng> oh dudes, i just said that !
<tseng> :P
<jdub> heh
<mdz> who is jimmac?
<daniels> elmo: that'd be easy
<mdz> I assume he works for ximian
<daniels> elmo: 'all the cool kids'
<jdub> mdz: jakub steiner, gnome icons man
<daniels> mdz: yeah, he's one of their crazy art guys
<mdz> doh
<mdz> elmo: amber blew up
<jdub> and ximian/novell art biatch
<elmo> sweet
<mdz> elmo: jabbered you the output
<elmo> no you haven't?
<mdz> like hell I haven't
<elmo> have NOT
<mdz> sent again?
<mdz> perhaps you are not logged into jabber :-P
<elmo> I so am dude
<mdz> ooh, jabber is broken
<elmo> geez.. first he insists he's sent me mail.. then he insists he's sent me jabbers..
<elmo> ;-)
<mdz> I disconnected from jabber and tried to reconnect, and it hangs
<jdub> haha
<jdub> http://davyd.ucc.asn.au/images/battstat-preferences-cleaner.png
<jdub> davyd's latest sshot has 'sudo suspend' ;)
<jdub> mdz: btw, why did we go for "add a user line to sudoers" instead of a wheel-group equivalent set up?
<mdz> jdub: no one even mentioned the possibility, including you :-P
<mdz> could very well be simpler to do it that way
<tseng> %wheel  ALL=(ALL)   ALL
<jdub> mdz: btw, http://cipherfunk.org/diary/archives/monthly/2004-10.html#e2004-10-26T18_44_02.htm
<jdub> mdz: i thought of it a few times, but stupidly didn't mention it, because i thought it had been passed over.
<jdub> mdz: fwiw, that's how OS X does it
<jdub> mdz: would it be a PITA to transition to it?
<mdz> jdub: not for new installs
<tseng> http://ronald.bitfreak.net/images/g-v-a.png <- whats different in this shot?
<jdub> i guess it wouldn't for upgrades either; you'd only have to add one line
<jdub> and existing users already have sudo love
<jdub> tseng: dunno
<tseng> looks the same old to me =/
<jdub> tseng: although it has been rewritten
<tseng> yes.
* mjg59 fails to get ACPI on the craptop working under FreeBSD
<jdub> mdz: interesting patches
<jdub> (paul is 'ultrafunk' aroudn irc)
<jdub> you know
<jdub> i was thinking last night
<mdz> jdub: what did he have on the laptop before?
<jdub> probably fedora
<Kamion> mdz: I saw it mentioned a number of times, actually
<jdub> we make a lot of decisions on irc
<jdub> and talk about interesting stuff here
<Kamion> mdz: always when more important stuff was happening, though ...
<jdub> while some people may only be able to track ubuntu-devel
<mdz> Kamion: I remember it was mentioned late in the release cycle
<jdub> i want to make more of an effort to use that list
<mdz> but not back in Oxford when we made the change
<Kamion> mdz: *nod*
<Kamion> mdz: I think it'd be good for new installs, but I was a bit scared to use "wheel"; that group has a lot of baggage
<mdz> Kamion: agree
<Kamion> people rather expect it to be gid 0, too
<elmo> god damn it, I suck.
<mdz> pitti: still with us?
<pitti> mdz: yes
<Kamion> adding the initial user to gid 0 would suck :-)
<mdz> pitti: minor train wreck in generating the advisory template
<Kamion> anyway, this alleged going-to-bed thing ...
<jdub> adduser jdub sudo ;)
<daniels> Kamion: ... is for the weak!
<pitti> mdz: in the meantime I created all mails and put them into my outgoing queue; so I just need to add the package lists
* daniels heads out of range of WiFi.
<Kamion> I'll be out for a fair bit of tomorrow; picking up the girlfriend from visiting family an hour or so's drive away
<mdz> Kamion: ok, enjoy
<daniels> enjoy :)
<Kamion> will catch up as per usual :)
<elmo> lol
<elmo> katie@jackass:/srv/ftp.no-name-yet.com/queue/accepted $ amber 3-1 gs-common_0.3.6ubuntu1.1*.changes -n | less
<elmo> amber is only useful for members of the security team, you tramp.
<Kamion> :-)
<Kamion> you can smell elmo-written scripts a mile away
<daniels> heh
<jdub> they smell like schhhnnaaaakke
<pitti> Hi sjoerd! nightshift, too?
<mdz> pitti: you should have an email with the gs-common template now
<pitti> mdz: not yet
<elmo> Oct 27 01:34:10 fiordland postfix/smtp[10351] : D3041B68002: to=<mdz@alcor.net>, orig_to=<security@ubuntulinux.org>, relay=redir-mail-telehouse1.gandi.net
<elmo> [217.70.180.1] , delay=2, status=sent (250 Ok: queued as ED36E445C1D)
<elmo> Oct 27 01:34:39 fiordland postfix/smtp[10352] : D3041B68002: to=<martin@piware.de>, orig_to=<security@ubuntulinux.org>, relay=mail.piware.de[213.9.79.162] 
<elmo> , delay=31, status=sent (250 OK id=1CMblu-0004Rv-VO)
<mdz> it liked me better
<pitti> mdz: now it's there
<pitti> probably took a while to get though SA, procmail, and the like
<mdz> pitti: gettext inbound
<mdz> and postgresql
<mdz> imagemagick
<mdz> and gaim
<elmo> hmm, glibc's taking too long, lemme check on it
<pitti> mdz: the template shows all generated debs; shall I cut that down to the really affected ones?
<elmo> ok, we need lamont for glibc
<mdz> hmm, he was just here
<elmo> the buildd mail config is broken for the powerpc and amd64 buildds it built on
<mdz> GAH
<mdz> can we retry it and hope it gets a different one?
<elmo> lol
<mdz> sorry, channeling lamont there
<mdz> I think I am going to need to go buy some sandbags and build a dike
<mdz> before I drown
<pitti> mdz: ready to fire the first USN (gs-common)
<mdz> pitti: whenever you are ready, or if you want me to look at it first, let me kno
<mdz> know
<pitti> mdz: it's just the known notice with the package list appended
<pitti> to: u-s-a, cc: full disclosure, bugtraq, signed
<mdz> pitti: go ahead
<pitti> mdz: for gettext, only the really affected "gettext" or shall I include all other packages (gettext-base etc.) as well?
<mdz> pitti: if you know that the bug is only in one binary package, you can list only that one
<pitti> mdz: as I already did, okay
<pitti> mdz: so I can also remove the other packages/md5sums/etc?
<mdz> pitti: leavae the md5sums
<mdz> leave
<pitti> okay
<pitti> gettext is away
<pitti> I think I should wait for the arrival of gs-common before sending further mails...
<mdz> I approved the list messages
<pitti> argh, why does my post to u-s-a await moderator approval???
<mdz> pitti: every post is moderated
<pitti> ah, okay. So no error on my side
<mdz> pitti: trying to reach lamont
<mdz> he is enroute
<pitti> ah, the first two mails came through :-)
* pitti is excited
<mdz> pitti: :-)
<pitti> mdz: I sent the three other USNs (all except libc)
<mdz> pitti: do you have privileges to add them to the website?
<pitti> mdz: time to try out my password :-)
<elmo> you guys don't need me for anything else do you?
<pitti> elmo: thanks a lot for your help!
<pitti> mdz: it seems as if I could edit the page
<mdz> elmo: all the ambering has worked fine, so I don't anticipate a problem with glibc, thanks
<elmo> well, mobile's on anyway, if something comes up.. 
<elmo> night all
<jdub> night elmo
<lamont_r> elmo
<lamont_r> still here?
<pitti> mdz: when I click on "add error reference" on http://www.ubuntulinux.org/support/documentation/usn/, I get a permission denied
<pitti> mdz: is that the right way to add another USN?
<elmo> lamont: wha?
<lamont_r> mdz said I needed to poke a couple buildd's... wondering which machines...
<elmo> whatever built glibc
<elmo> adare and ..
<lamont_r> right
<lamont_r> ah, yes
<elmo> yellow
<elmo> the glibc build log bounced, AFAICT
<lamont_r> yes
* lamont_r goes to deal with it
<elmo> do I want to know why, or will it make me cry?
<elmo> the size limit seems to be set to 0..
<lamont_r> message_size_limit, iirc
<mdz> pitti: yes, that's right
<mdz> pitti: you must not have permission
<lamont_r> dunno - I'll get 'em signed/uploaded, and triage/fix/email you when I get home
<pitti> mdz: can I get it?
<elmo> lamont: k
<mdz> pitti: I don't know how to do that, but I'll look
<mdz> website....so....slomw
<mdz> slow
<mdz> pitti: I don't see a way to do it; I may not have permission
<pitti> mdz: hmm; Alexander Limi and Jane should know how?
<pitti> mdz: maybe we can sort that out tomorrow and you copy the USNs to the page?
<mdz> pitti: yes, I will need to do that
<pitti> mdz: sorry :-/ I will ask somebody tomorrow to give me permissions
<lamont_r> pitti: glibc failed on amd64
<pitti> damn
<lamont_r> amd64 not in arch list. :-(
<lamont_r> missed it by that much...
<pitti> lamont_r: I only changed a script, after all...
<elmo> so, err, yeah, how did it build last time?
<pitti> lamont_r: does the Debian version fail as well?
<lamont_r> could, dunno
<lamont_r> elmo: glibc does absolutely insane and stupid things with it's control file, then patches both versions, so it doesn't patch it during build.
<lamont_r> istr adding a touch to debian/rules for warty...
<lamont_r> pitti: bbiab
<mdz> wait, what?
<mdz> does someone have the failed logs in hand?
<mdz> and is that same someone working to fix the problem?
<elmo> http://people.ubuntu.com/~james/glibc_2.3.2.ds1-13ubuntu2.1_20041026-2338.gz
<elmo> I'm not working on it tho
<mdz> pitti: all USNs should be published on the website now
<pitti> mdz: nice, thanks
<pitti> mdz: you did not include the pacakge md5sum lists, as you did for your first two USNs?
<mdz> pitti: yes, I will remove them from the first two as well
<jdub> mdz: btw, you don't have to turn emergency moderation on, or list yourself as admin and moderator
<pitti> mdz: probably nicer
<mdz> jdub: the other half of that sentence would have told me the alternative method to get what I want :-)
<jdub> mdz: it was already set up correctly
<mdz> jdub: it was set up for every message to be moderated?
<jdub> yes
<jdub> new members are moderated by default
<jdub> on that list
<mdz> new members?
<jdub> subscribers
<jdub> "By default, should new list member postings be moderated?" -> YES
<mdz> where is that set?
<jdub> sender filters page under privacy
<mdz> first place I would have looked
<mdz> NOT
<mdz> what's a "new list member"?
<mdz> ah, I see
<mdz> so when new users subscribe, they get their individual moderator flag checked
<mdz> I think I feel better with it being globally locked down
<pitti> mdz: interesting post on u-users: sb asked how to verify GPG keys on the u-s-a list
<pitti> mdz: shall we put the fingerprints on the website?
<mdz> pitti: the same way to verify any other GPG key
<mdz> through the web of trust
<pitti> mdz: still it might be a good idea to have the fingerprint on a website
<mdz> it only encourages bad habits, really
<mdz> but we can do that
<pitti> lamont_r: already back?
* pitti nearly falls to sleep
<pitti> mdz: do you think the glibc issue will resolve in the next minutes? Or can we continue tomorrow, or can you send the announcement?
<mdz> lamont_r: ?
<pitti> lamont_r: ah, welcome back :-)
* lamont_r screams at the laptop
<lamont_r> so, how do I get X to not go to sleep, never to return, every time I forget and close the lid on the laptop, huh?
<mdz> lamont_r: purge acpid?
<lamont_r> done
<lamont_r> thanks
<lamont_r> did I miss anything worth reading the log file for ?
<pitti> lamont_r: not really
<lamont_r> ok - I'll see it when I get home
<mdz> lamont_r: you missed me losing my mind over how we managed to release warty with a glibc that FTBFS
<lamont_r> which'll be relatively soon
<lamont_r> mdz: I swear I didn't cheat on that one.
<pitti> lamont_r: any ETA? it's 3:34am and I can hardly keep my eyes open
<mdz> lamont_r: so you think it's a timing thing?
<mdz> pitti: go ahead and sleep, I will take care of it
<mdz> or it can wait until tomorrow
<mdz> pitti: thanks for staying up
<pitti> mdz: okay, I send you the announcement
<pitti> mdz: thanks a lot for mentoring me!
<lamont_r> mdz: glibc has traditionally been victim to that.
<mdz> lamont_r: we need for warty-security build failures to go to security@
<lamont_r> note: never patch both the source and target in the diff.gz, unless you deal with it somehow in rules...
<pitti> mdz: USN sent to you
<pitti> thanks everybody and good night!
<mdz> pitti: night
<mdz> lamont_r: can you fix it up with an upload to warty-security?
<lamont_r> mdz: meaning fix and re-upload source, I assume?
<mdz> lamont_r: correct
<lamont_r> wilco
<mdz> thanks
<lamont_r> np.  car about done here, then will be home relatively soon and deal with it.
<hornbeck> I am liking the new wiki :-)
<jdub> mdz!!!
<mdz> jdub???
<jdub> there is an optimisation that we MUST HAVE in hoary!!!
<mdz> oh really???
<jdub> yes!
<jdub> !!
<jdub> it is crucial for enterprise adoption!!
<jdub> http://tech9.net/rml/log/2004102601
<mdz> ...
<tseng> yeah, meh
<mdz> jdub: we should add a shutdown script which executes sync(1) in a shell loop 100,000 times
<mdz> then replace our sync(1) with this one and claim a performance benefit
<hornbeck> jdub: that is nice
<mdz> d00d3rz 1 r3c0mpi1e/> w1th -p1p3 4n/> 1t /2u/\/z 50kx f4st3r!!!11
<jdub> mdz: that MSI bug seems to suggest that it was on and off during warty devel
<mdz> jdub: yeah, it was supposed to end in the 'off' state
* jdub is tempted to rebuild to try, but... ugh...
<jdub> i don't want to build kernels anymore :-)
<mdz> jdub: if you have a -15 or lower .deb around, you can try that
<jdub> hrm
<mdz> maybe a preview CD
<mdz> the regression happened oct 12
<mdz> snapshot.ubuntu.com? :-)
<jdub> heh
<mdz> fuck, raining again
* lamont is hime
<lamont> home, even
<lamont> Rejected: gtk2-engines-smooth_0.5.8-1_powerpc.deb: old version (2.8.1-0ubuntu1) in hoary >= new version (0.5.8-1) targeted at hoary.
* lamont giggles
<mdz> lamont: what's the word on glibc?
<lamont> mdz: the word is that I'm home and ignoring irc while I fix it. :-)
<mdz> thanks
<hornbeck> how would you make a code block in reStructuredText?
<hornbeck> nevermind
<mdz> hornbeck: you are actually using it?
<mdz> I found it unusable
<hornbeck> what reStructuredText
<hornbeck> it is great
<hornbeck> like butter on your breakfast toast
<mdz> the first thing I tried to write, it blew up because the header markup wasn't exactly the same number of characters as the heading text
<hornbeck> yeah, I have some problems with little lame things
<hornbeck> like not having returns in the right places
<hornbeck> man building beagle is a pain in the ass sometimes
<jdub> mdz: sabdfl reckons we'll standardise on moin-style markup
<mdz> jdub: me too
<hornbeck> really
<hornbeck> so I am learning this for nothing :-(
<hornbeck> oh well
<mdz> I can't believe you don't hate it :-)
<hornbeck> I don't hate many things
<hornbeck> I can find fun in pooping outside
<lamont> mdz: have me remind you to beat up the person who added amd64 support 99% of the way, eh?
* lamont does a test build first
<lamont> source upload should happen in about 45 minutes, give or take
<hornbeck> is the universe repos down right now
<hornbeck> my apt-get just died
<lamont> hornbeck: new day begins. :-)
<lamont> "days" are 30 minutes long...
<lamont> so the odds of catching a Packages.gz update or mirror pulse are greater.
<hornbeck> damn
<hornbeck> I am trying to write a evolution-sharp doc, and I need all the deps to make sure I get them all
<lamont> day begins at :03 and :33, pulse shortly thereafter
<hornbeck> guess it will wait till tomorrow
<hornbeck> oh so it will be back in a few?
<hornbeck> ok, I can get somethings from universe but alot of xml files are gone?
<hornbeck> did some stuff get taken out?
<hornbeck> Err http://archive.ubuntu.com warty/universe libxml-namespacesupport-perl 1.08-3  404 Not Found
<hornbeck> any ideas?
<hornbeck> mdz?
<mdz> hornbeck: hmmm!
<hornbeck> that package and libxml-sax-perl
<hornbeck> both used to be there
<mdz> it was moved, but not intentionally
<mdz> I think I see what happened
<mdz> elmo: ^^^^
<mdz> (when he wakes up)
<hornbeck> they will be back correct?
<hornbeck> cause evolution-sharp depends on them
<hornbeck> :-)
<mdz> hornbeck: as I said, it looks like it was unintentional
<hornbeck> ok cool
<mdz> I'm writing an email to elmo
<hornbeck> thank you
<mdz> if you notice anyone else encountering that, let them know that we're aware of it and working on the problem
<hornbeck> mdz: ok, I am off to bed anyway but was working on one more doc before bed
<lamont> mdz: if it helps, I have a never-break-my-archive (albeit crufty) script for mirroring
<lamont> snags Packages.gz/Sources.gz, parses them. fetches files, installs Packages.gz Sources.gz, fills the morgue (since bandwidth hurts me.)
<lamont> mdz: so does squirrelmail make baby jesus cry?
<jdub> yes
<jdub> plus it uses baby-jesus-baiting php4-imap
<lamont> any sane alternatives?
<jdub> i haven't really found one that made me comfortable
<jdub> atm i'm using sqwebmail at home, which has its own faults
<lamont> that was what led me to installing squirrelmail on a non-i386 box
<lamont> glibc (if/when it decided to rebuild debian/control) lacked amd64 mention in control.in/libc6 :-(
<lamont> not sure where I got the amd64 patch when I applied
<lamont> it
* lamont notes that killing the infinite-loop helps speed things up.  5MB of log to go
* lamont wishes that Packages files were broken up into more bite-sized pieces
<fabbione> morning guys
* lamont identifies the email issue, sends elmo the info
<lamont> morning fabbione
<fabbione> lamont: how busy are adaire and yellow?
<fabbione> i guess all the buildd are pumping 100% after the sync
<lamont> fabbione: building hoary, basically
<fabbione> ok
<fabbione> i will soon need to start building X.org
* lamont currently has crested offline, so yellow is holding down the fort
<fabbione> it compiles on i386 already
<lamont> ah, ok.  happy, happy, joy, joy
<fabbione> lamont: i won't be that happy
<fabbione> it is still monolithic
<lamont> yeah - but the breakup of the source can largely happen in parallel with people abusing the monolithic beast.
<lamont> you're going to break it up so that it doesn't have circular build-deps, right?
* lamont grumbles at hoary
<lamont> my mirror is now out-of-date: 1353 files missing. :(
<lamont> well, 1249 when I snap debian sources over.
<fabbione> lamont: i already did basically :-)
<jdub> morning Keybuk 
<fabbione> and i also have much less compiler warnings
<lamont> fabbione: yeah
<jdub> lamont: i386 packages.gz for hoary looks fat! :)
<fabbione> than in the monolithic
<fabbione> lamont: but it won't be uploaded until hoary release date + 1
<Keybuk> jdub: morning
<fabbione> so everybody will live with monolithic for another release cycle
<jdub> lots of ubuntu packages in hoary ;)
<lamont> jdub: scary thing is that universe in hoary got bigger than warty
<lamont> ditto main
<lamont> and multiverse
<jdub> doesn't that make sense?
<Keybuk> jdub: I have 77 to upload at the moment, another 277-odd remaining :)
<jdub> Keybuk: rad!
<jdub> lamont: given that building the livecd is 'hard', and rsyncing is not entirely useful, what do you think is the best way of pulling regular livecds for testing?
<jdub> maybe we should have a jigdo equivalent for livecds
<jdub> that'd be rad
<jdub> oh
<jdub> no it wouldn't
<jdub> it'd be pretty much the same as doing a livecd build anyway
* jdub should sleep more
* jdub is totally tempted to upgrade to hoary on his test box
<fabbione> lamont: i will quite soon (a couple of weeks from now) need the tools to build the livecd
<lamont> jdub: that'll be scary
<lamont> fabbione: np
<fabbione> lamont: to sync the X autoconfig stuff on both live and install
<lamont> I should have the doc done by then, esp if someone picks on me
<fabbione> lamont
<fabbione> otherwise we can find something else.. hmmmm
<fabbione> actually
<fabbione> there is something more cool we can do...
* fabbione needs to think a bit about it
<fabbione> lamont: is there any simple way i can detect we are running on a LiveCD?
<fabbione> like a specific installed file?
<fabbione> that it will be there for sure 100%
<fabbione> since people have been asking for autoreconfig in case of a video card change
<fabbione> that can be done in a init script
<lamont>  /MorphixCD/  iirc
<fabbione> the same init script can check if we are running on a LiveCD
<fabbione> and instead of prompting it could reconfigure X
<fabbione> that will save me the time to build liveCD's
<lamont> we may have to actually schedule said script to run, btw.
<fabbione> good
<fabbione> if it needs to be done maually even better
<lamont> yeah - telling that you're LiveCD isn't all that hard.  If it is, we'll make it not-hard. :-)
<fabbione> i can stick it in /usr/share/xorg/reconfigure_for_live_cd
<fabbione> or something
<fabbione> and than you can force it manually
<lamont> elmo/thom aroudn?
* lamont just screwed up, I fear
* Keybuk feigns shock
<lamont> pitti around
<lamont> ?
<jdub> 184 upgraded, 4 newly installed, 6 to remove and 0 not upgraded.
<jdub> Need to get 69.6MB of archives.
<jdub> After unpacking 7676kB disk space will be freed.
<jdub> heh
<jdub> The following packages will be REMOVED:
<jdub>   alsa-base alsa-utils gdm python2.3-genetic ubuntu-base ubuntu-desktop
<jdub> d'oh
<Keybuk> jdub: what you upgrading to?
* lamont bets hoary
<Keybuk> lamont: that would be a totally insane thing to do right now, surely? :o)
<lamont> Keybuk: beyond doubt
* lamont hopes to hell elmo's scripts do what he hopes they do...
<Keybuk> some stuff is old, from warty; some stuff is building from unstable; and other stuff is sitting on rookery waiting for me to get my key in the keyring
<Keybuk> lamont: what do you hope they do?
<lamont> put the files I just uploaded in the right place.
<jdub> yeah, just seeing the state of the archive
<lamont> 75 seconds, and we'll know... :-(
<Keybuk> jdub: there will be a few problems where stuff sync'd from unstable depends on a package not sync'd because we modified it
* lamont bows at elmo's feet.
<jdub> i imagine gdm is waiting in your queue
<Keybuk> rookery scott% grep -c "^diff " results/gdm_2.6.0.4-1ubuntu1.dropped
<Keybuk> 11
<Keybuk> that'll need manual review
<fabbione> Keybuk: if it's only question of signing and upload i can do that for you
<fabbione> if you think that will speed up stuff around
<Keybuk> thanks, but by the time I've gone through the ones with po-dropped I'll hopefully have over a hundred or more to play with and elmo will be awake ;p
<lamont> jdub: as for status:
<lamont> hoary.all.amd64:Total 1599 package(s) in state Needs-Build.
<lamont> hoary.all.i386:Total 1047 package(s) in state Needs-Build.
<lamont> hoary.all.powerpc:Total 1354 package(s) in state Needs-Build.
<jdub> cool
<fabbione> Keybuk: ok
<Keybuk> http://primates.ximian.com/~jimmac/blog/Misc/Ubuntu
<Keybuk> \o/
<Keybuk> Ximian employee in "If somebody asks me what linux distro he should try on his mac, I'm resolutely recommending Ubuntu." shock.
<jdub> innit great? :)
<lamont> cool
<lamont> now we just need to make hoary suck less than warty, eh?
* lamont ducks
<mdz> Keybuk: morning
<hornbeck> is there a bootstrap to use to setup a ubuntu chroot?
<lamont> mdz: mcmurdo, royal, yellow.
<lamont> hornbeck: start with debootstrap from warty
<Keybuk> mdz: morning
<lamont> debootstrap ... warty
<hornbeck> great thanks
<mdz> Keybuk: what's the status of your merge project?
<lamont> Keybuk: did we ever decide on a binNMU standard?
<lamont> version number, that is.
<Keybuk> mdz: 77 done with nothing dropped, working on automating .po now so hopefully that'll give us a bunch more, then there will be a hundred or so with patches to manually review
<mdz> Keybuk: done == uploaded?
<Keybuk> lamont: no, need to get you, elmo, neuro, aj, kamion, etc. together and let you fight it out
<Keybuk> mdz: not uploaded yet
<mdz> Keybuk: do you have a list of those which will definitely require manual review?
<Keybuk> mdz: not yet, because I hope to get the number down; it's at 251 at the moment
<mdz> Keybuk: are you certain your key is not already in the keyring?
<mdz> I was under the impression that it was
<Keybuk> well, I did an upload the other day and it vanished into thin air
<mdz> Keybuk: what package?
<Keybuk> ubuntu-artwork, just before warty release
<mdz> Keybuk: do you recall the version number?
<Keybuk> 0.2.12-1
<mdz> there's only one 0.2.12-1 in the log, and it was accepted
<Keybuk> yes, but Colin signed that
<Keybuk> he had to get me out of bed because mine didn't go through
<Burgundavia> Who would I talk to about the expired cert on bugzilla?
<mdz> Burgundavia: no one; it's already filed in bugzilla
<Burgundavia> mdz: so I assume the powers that be are going to fix it?
<mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=1278
<mdz> Burgundavia: it's not a particularly high priority
<Burgundavia> ok, just wondering
<mdz> being able to spoof our bugzilla wouldn't be particularly rewarding :-)
<Burgundavia> sort of ironic though
<fabbione> GOOOOOOOOOOOOOOOOOOOOOOOODY
<fabbione> patch forwarding is basically completed
<fabbione> mdz: ^^^
<fabbione> mdz: + we build on i386
<lamont> Starting proxy server: 2004/10/26 23:32:36| WARNING cache_mem is larger than total disk cache space!
<lamont> hrm...wonder how to bump the disk cache size..
* mdz high-fives fabbione
<mdz> lamont: cache_dir
<fabbione> mdz: now we need to fix all the packaging part :-)))
<fabbione> that it's going to be... hmm evil
<fabbione> mdz: since we switched to monolithic i will NOT neeed root on amd64 or ppc
<fabbione> mdz: all the build-deps should be there already
<mdz> fabbione: what about for testing?
<fabbione> mdz: even if i have root on our boxes, there is nobody in front of them to see what's happening on the screen
<fabbione> i will need people with amd64 and ppc boxes to test
<fabbione> there is really nothing i can automate myself there
<Keybuk> zsh: command not found: msgmerge
<Keybuk> gah!
<Keybuk> anyone !elmo have root on rookery? :)
<mdz> hom
<mdz> thom
<lamont> g'night all
<doko> morning lamont
<jdub> night lamont 
<Keybuk> gah, I really cannot work this frickin' po file stuff out
<Burgundavia> cya all
<Keybuk> I really don't think msgmerge is going to work for this stuff
<sid77> hi all
* maswan hopes that a mirror admin isn't unwelcome here
<maswan> because:
<maswan> elmo: @ERROR: max connections (25) reached - try again later
<maswan> (this night)
<fabbione> pitti: where is USN-4-1 ?
<fabbione> ehm
<fabbione> mdz: ^^
<Keybuk> not released yet, I'd guess
<Keybuk> I suspect they're doing the same as Debian and assigning the number at the start of the security procedure, not the actual release of the notice
<fabbione> yeah
<fabbione> doh!
* Keybuk cackles with pure evil
<fabbione> it was on ubuntu-users
<Keybuk> so I've actually "fixed" the .po issue
<Keybuk> I have some Python that strips all the context from a patch and rejiggles the line numbers
<Keybuk> so it actually works
<Keybuk> muahahahaha
<Keybuk> screw you hippy po comments
<Keybuk>         if line.startswith(" ") or \                 (line.startswith("-#") and not line.startswith("-#,")) or \                 (line.startswith("+#") and not line.startswith("+#,")):
<Keybuk> those po file people are as magic-punctuation happy as tom lord!
<Keybuk> -#, and +#, are a change to the bit of the .po file that says "fuzzy" or "c-comment", etc.
<Keybuk> I got the impression people would be upset with me if I dropped those
<fabbione> hey tfheen 
<fabbione> welcome back
<tfheen> hiya
<fabbione> JEEEEEEEEEEEE
* tfheen grumbles over vawad being ill
<Keybuk> tfheen: vawad's *always* ill :D
<fabbione> x.org is taking a long time to build
<fabbione> even with ccache
<tfheen> Keybuk: she's started to eat networking cards now.
<Keybuk> nice
<tfheen> so, anything fun happened while I was away?
<fabbione> the build log for the normal part is at least 2MB bigger than Xfree86
<tfheen> apart from Warty releasing, obviously.
* fabbione cries out loud and ask for 4GB of ram
<sid77> lol
<tfheen> fabbione: get an amd64 with 4G of RAM and crosscompile? ;)
* tfheen hides
<fabbione> tfheen: welcome to send me one :)
<tfheen> fabbione :)
<fabbione> model name      : Intel(R) Pentium(R) 4 CPU 2.00GHz
<fabbione> it's not like i have a slow machine
<fabbione> with 1 GB of ram
<Keybuk> dude, it's a P-4 ... that's about 200Mhz in *real* CPU terms <g>
<fabbione> model name      : AMD Athlon(tm) XP 2100+
<fabbione> i also have this one with 1 GB of RAM
<fabbione> it still takes hell of a lot to compile compared to XF86
<fabbione> 7684 -rw-r--r--    1 fabbione fabbione  7852788 Oct 21 12:12 make_world.build.log
<fabbione> 9940 -rw-r--r--    1 fabbione fabbione 10161505 Oct 27 06:56 make_world.build.log
* fabbione sighs even more
<fabbione> 3020 -rw-r--r--    1 fabbione fabbione  3087544 Oct 21 12:19 make_world_dbg.build.log
<fabbione> 4600 -rw-r--r--    1 fabbione fabbione  4694731 Oct 27 07:24 make_world_dbg.build.log
* fabbione screams and runs away
<tfheen> fabbione: you're supposed to _like_ multi-MB build logs.
<Keybuk> @@ -81,1 +72,1 @@
<Keybuk> -msgstr "Debian installatieprogramma-modules worden geladen"
<Keybuk> +msgstr "Debian installatiemodules worden geladen"
<Keybuk> -- 
<Keybuk> cute
<Keybuk> seems to be working (that's a dropped Debian patch, for obvious reasons)
<tfheen> Keybuk: you're merging d-i branding?
<Keybuk> tfheen: merging debian and warty to make hoary
<fabbione> tfheen: oh yeah
<fabbione> and for last:
<fabbione>  868 -rw-r--r--    1 fabbione fabbione   880853 Oct 21 12:22 make_install.log
<fabbione> 1224 -rw-r--r--    1 fabbione fabbione  1245422 Oct 27 07:43 make_install.log
<fabbione> more than 50% BIGGER!
<fabbione> OH YEAH
<Keybuk> is that X.org, or just daniels? :o)
<fabbione> X.org :-)
<fabbione> i think i need a bigger machine
<fabbione> i am sure debian buildd will NOT like this
<Keybuk> * Creating copy of base-files
<Keybuk> * Considering base-files
<Keybuk> ! 2 patch hunks dropped
<Keybuk> * Building base-files_3.1ubuntu1.dsc
<Keybuk> -- cool, most the drops are easy (that's our issue & issue.net change)
* sid77 bye
<maswan> fabbione: how about an 8-way opteron with 32 gigs of ram?
<maswan> fabbione: a bit too expensive to get donated though, even if I probably could borrow one for a couple of weeks. :)
<fabbione> maswan: useless
<fabbione> X build doesn't fork across processors
<maswan> fabbione: single-cpu speed more relevant?
<maswan> ah
<fabbione> 32GB would be still good :-)
<maswan> Well, you could start by fixing that then. :)
<fabbione> maswan: send me 2x16GB stick for a Dell Optiplex GX260 :-)
<fabbione> i won't mind that kind of donation ;)
<maswan> fabbione: heh. well, sticking within reality, you could get an hp dl585 with 32 gigs of ram too, with only 4 cpus. :)
<maswan> fabbione: but then, those aren't usually free either
<fabbione> ENOMONEY
<fabbione> maswan: i recently bought a house and will get soon the second boss (formely called wife)
<Keybuk> "Dear Mark, For Christmas I would like..." :o)
<fabbione> Keybuk: "Dear Santa^WMark" ;)
<maswan> fabbione: see, Keybuk has the general idea of it :)
<fabbione> the first step will be to get my bigger office up and running
<fabbione> second step one 19" rack
<fabbione> than i will ask Santa to fill it up :P
<Keybuk> now's the time to decide between air mailing xmas cards, or just e-mailing; isn't it :p
<maswan> fabbione: a 2.4GHz or so opteron should be among the faster cpus for gcc grunting too, I think.
<jamesh> the new Athlon 64 4000+'s look nice too
<jamesh> if you just want a single processor machine
<maswan> well, yeah, but those only fits a few gigs of ram
<maswan> of course, they are lots cheaper though
<jamesh> how much ram do you want?
<maswan> fabbione thought 32 gigs would be nice :)
<fabbione> with 32GB i can mount /usr/src in ram
<jamesh> you'd need 4 processors for that, right?
<fabbione> and compile in it :-)
<fabbione> nope
<fabbione> one processor or 2 are more than enough
<maswan> well, yeah, I don't know of any board with more than 8 slots/cpu
<jamesh> what's the largest DIMM you can get?
* fabbione does
<jamesh> given that each CPU can handle 4 sticks of memory
<maswan> 1GB in practice, 2GB in theory
<fabbione> maswan: get a few e10k cpu boards :P
<maswan> jamesh: I've seen 8
<maswan> fabbione: ah, but those do not have very fast single-cpu performance. :)
<jamesh> maswan: for a single CPU AMD64?
<fabbione> maswan: i know :-)
<fabbione> they are still sweet tho
<maswan> jamesh: well, yeah, you could just run a dl585 with one cpu. :)
<jamesh> maswan: I've seen 8 slot dual processor AMD64 boards
<jamesh> maswan: but the second 4 slots could only be used if you plugged in two CPUs
<maswan> jamesh: well, are those 8 slots in total or 8 slots per cpu?
<maswan> ah, yeah.
<jamesh> since the memory controllers are on the CPUs
<maswan> that's the thing, the dl585 has 8 slots per cpu
<maswan> hmm.. you should be able to get a p4/xeon board with 8 or perhaps even 16 slots and just populate that with 1 cpu.
<maswan> I think. I haven't looked much at that though.
<jamesh> either way, you're looking at a lot of money
<maswan> yeah
<jamesh> it might be more economical to buy a bunch of Raptor hard drives and set up a RAID array
* maswan waves and heads off
<seb128> morning
<fabbione> +usr/X11R6/lib/libXaw.so.8.0
* fabbione cries
<seb128> that's ok to start working/uploading in hoarty now ?
<fabbione> dpkg-buildpackage -rfakeroot -uc -us -b
<fabbione> dpkg-buildpackage: source package is xorg
<fabbione> dpkg-buildpackage: source version is 6.8.1-0.0
<fabbione> dpkg-buildpackage: source maintainer is Fabio M. Di Nitto <fabbione@fabbione.net>
<fabbione> dpkg-buildpackage: host architecture is i386
<pitti> Morning!
<pitti> mdz: still awake?
<seb128> hello pitti 
<pitti> Hi seb128!
<seb128> ok, so nobody knows if we can start working/uploading in hoary if we should better wait a bit ?
<pitti> seb128: I already uploaded some stuff and was told that it was okay
<seb128> yeah, I've seen the mails on hoary-changes, but I was not sure with the syncs
<seb128> thanks pitti 
<pitti> seb128: I still remember elmo saying that the syncs are finished (the automatic ones, that is)
<seb128> cool, thanks
<pitti> elmo: Morning! Since mdz is already sleeping, can you do the libc unleashing, too?
<Keybuk> sorta
<Keybuk> basically there are three sets of things to sync
<Keybuk> 1. things that haven't changed in warty or debian -- easy, nothing to do (so done)
<Keybuk> 2. things that changed in debian, but not warty -- pull from debian, and build (elmo's set this running, it may be done, it may not)
<Keybuk> 3. things that changed in both debian and warty -- need to merge, I'm working on this at the moment
<enrico> Hello.  Is someone around that is involved in the Wiki migration?
<enrico> justdave: around?
* enrico listens to the sound of one hand clapping
<robtaylor> pitti: what do reckon to mdz's chroot idea for #2758?
<robtaylor> pitti: i tried restarting hotplug, and running the same hald test, but didnt seem to change anything
<pitti> robtaylor: well, I thought hotplug was not the problem
<pitti> robtaylor: you'd need to run hal not in a chroot, but in the normal file namespace
<robtaylor> pitti: you think it's kernel level?
<pitti> robtaylor: I did not extensively deal with the live cd, though
<pitti> robtaylor: no idea, sorry; please ask amu, he should know much better about the live cd
<robtaylor> pitti: yeah, it a bit weird, i'm testing now with a more normal usb key and seeing exatly the same symtoms :/
<robtaylor> pitti: cool. what timezone is amu?
<pitti> robtaylor: mine, i. e. UTC+2
<robtaylor> pitti: ah cool
* enrico tries again
<enrico> Who's involved in the wiki migration?  I'd need to get in contatct with them
<seb128> why not saying here what you want ? perhaps somebody can help you ?
<fabbione> ciao enrico 
<enrico> fabbione: ciao!
<fabbione> seb128: that sounds familiar :-)
<seb128> :)
<enrico> fine
<sid77> ciao! (i'm italian too ;)
<enrico> Appearently the pages were migrated
<enrico> sid77: ciao!
<sid77> lol
<enrico> However, the old wiki has not been locked
<enrico> I had been assured by mark (and consequently I reassured the ubuntu-doc list) that the old wiki would have been locked before transition, so that no modifications would have been lost
<enrico> So, I'd like to ask what is the migration path.  People in the list are puzzled
<Kamion> Keybuk: hm, msgmerge was working absolutely fine for me, seemed to be perfectly automatable in principle
<migus> hi
<enrico> Thing is, wiki is the way people in ubuntu-doc are making all the work now, and it's been changing without notices for a while
<enrico> Someone starts being annoyed of having something different or unclear every time they want to do some work
<Kamion> SteveA has been doing most of the migration I think; he was looking around last night for somebody with suitable admin privileges to lock the old wiki.
<fabbione> hi sid
* sid77 is away: Far from here (close to you)
<fabbione> sid77: please no public away messages
<__daniel> hai
<fabbione> hmm intersting :-)
<fabbione> pciutils wants to kill ubuntu-base
<pitti> sjoerd: did you ever try to build hal-0.4.0 in a pbuilder? My initial upload to Hoary FTBFS, I have to build-dep on libxml-parser-perl
<fabbione> (bootstrapping hoary)
<pitti> fabbione: I just tried to switch my apt sources to Hoary, but the package files are still empty. Do I sth. wrong?
<Keybuk> Kamion: I just couldn't get it to do the right thing, ever
<fabbione> pitti: they aren't here...
<Keybuk> given "warty.po" and "debian.po", I couldn't get one that had the best of both
<fabbione> pitti: debootstrap warty and then change apt lines
<pitti> fabbione: you mean they are not empty for you? Then it must be a problem of my provider...
<Kamion> Keybuk: really did work fine for me
<pitti> fabbione: my provider has a transparent proxy, maybe this still offers me the empty files
<pitti> fabbione: thanks
<Keybuk> Kamion: when I did msgmerge warty.po debian.po; I got the new debian strings, but the warty translations
<Kamion> Keybuk: like I say, you need to produce hoary.po first using debconf-updatepo or whatever
<fabbione> pitti: i am using a local mirror
<Kamion> Keybuk: I wouldn't do it that way ...
<Keybuk> when I did msgmerge debian.po warty.po I got the debian translations, but not the new strnigs
<Kamion> Keybuk: both those approaches are wrong
<Keybuk> Kamion: doesn't work for ordinary .po
<Kamion> can you leave everything with d-i branding to me then? I don't want to have to redo it all
<Keybuk> you won't have to :)  I had a lot more luck with mutating the patch
<elmo> GAR. stupid moin.
* jdub chuckles.
<Kamion> ordinary .po there's usually some kind of Makefile target to do it
<Kamion> Keybuk: uh
<elmo> does anyone know how to get this stupid thing to read it's updated config file?
<Keybuk> I wrote some code to write patches that could apply to .po files, without the # bits getting in the way :p
<Kamion> Keybuk: anything I can review before upload, please?
<Keybuk> Kamion: is cooking now
<Kamion> those comments are often needed for actual real live translators
<Keybuk> Kamion: sure, but you can favour one set over the other
<Kamion> true ...
<Keybuk> it keeps the #, one
<Keybuk> because that's important
<Kamion> there are others too
<Keybuk> but #: doesn't even need to be in the patch
<Kamion> #: should be handled by debconf-updatepo in the debian/po/ case
<fabbione> ok guys.. good news
* sid77 is back (gone 00:20:04)
<sid77> sorry
<Keybuk> *shrug* this way works :)
<fabbione> X.org compiles both on AMD64 and ppc
<Kamion> Keybuk: like I say, can I please just have a look at one of them before upload?
<fabbione> now it's only question of fixing a few tons of packaging problems
<Keybuk> Kamion: dude, someone's going to look at *all* of them before upload
<Keybuk> you get a source package, debian->hoary diff and "I dropped these" file
<Kamion> Keybuk: you said you were mass-uploading, I believed you :-)
<elmo> jdub: ?
<Keybuk> Kamion: yeah, for the ones with no "dropped" I can interdiff debian->hoary and base->warty quickly <g>
<Kamion> 14:37 < Kamion> Keybuk: are you going to be doing a mass upload of merges, or what?
<Kamion> 14:38 < Keybuk> Kamion: I think the basic idea is to do the merges as automatic as possible
<Kamion> 14:38 < Keybuk> for any that it works, I'll upload
<Keybuk> note "works" :)
<jdub> elmo: here
<elmo> jdub: do you know how to get moin to reload it's config?
<elmo> and/or where you involved in setting our moins up?
<pitti> Is Hoary automatically synced to sid now every day?
<jdub> elmo: i set up the original one on rince -> it should just take on the configuration when a new cgi is run
<elmo> pitti: yeah, where it can be
<elmo> jdub: that's what I thought, it doesn't appear to be, tho :/
<pitti> elmo: nice, thanks
<fabbione> ccachetop is cool :-)
<enrico> elmo: restarting apache?
<elmo> enrico: done that
<Kamion> Keybuk: fair enough
<enrico> elmo: still modifiable, though
<Keybuk> Kamion: if there really is some msgmerge magic, that'd be cool -- but I really couldn't get it to produce sane output
<Keybuk> it tended to favour one set of translations over another, completely
<Kamion> Keybuk: note I've done main-menu, cdrom-checker, cdrom-detect, yaboot-installer since I last talked to you
<Keybuk> and dropped others, with no way of actually telling it dropped them without resorting to diff
<enrico> elmo: sure that the new config is correct?
<Kamion> Keybuk: I used msgmerge successfully on five packages with complex merges
<Kamion> the output was exactly what I wanted
<sjoerd> pitti: no i didn't 
<elmo> aha.  STUPID moin.
<elmo> right, it's done
<pitti> sjoerd: it is very likely that it FTBFS for Debian, too
<Kamion> I gave you the procedure; it would have to be adapted for simple po/ as opposed to debian/po/, but almost all our branding is in debian/po/
<Keybuk> Kamion: yeah, and I followed that, and got crap out of the other end
<sjoerd> pitti: yeah probably.. will check 
<enrico> elmo: works, cool, thanks!
<Keybuk> entirely commented-out blocks and most of the warty changes dropped
<Kamion> Keybuk: what you told me you tried just above was totally different, though?
<Kamion> Keybuk: entirely commented-out blocks are expected and useful, they act as notes of the unbranded translations
<sjoerd> pitti: i'm currently checking out pmount, are you planning to create a group in later debian packages or something like that
<Kamion> Keybuk: sounds like you did it the wrong way round
<Keybuk> Kamion: I'm applying the debian changes to warty, not the warty changes to debian
<Kamion> Keybuk: me too
<pitti> sjoerd: If Debian agrees to one, it'll be my pleasure :-)
<pitti> sjoerd: plugdev would make Ubuntu and Debian totally compatible...
<Kamion> 11:42 < Keybuk> Kamion: when I did msgmerge warty.po debian.po; I got the new debian strings, but the warty translations
<Kamion> 11:42 < Keybuk> when I did msgmerge debian.po warty.po I got the debian translations, but not the new strnigs
<Kamion> you *have* to do the update against new source lines before attempting to msgmerge
<Keybuk> yeah, warty.po there has had debconf-updatepo run over it
<Kamion> after patching the rest?
<Keybuk> yup
<Kamion> also, you need to use a compendium with pre-updatepo-warty.po
<Kamion> the compendium is essential
<Kamion> as far as I can tell
<Keybuk> I couldn't get that to make any difference
<Keybuk> with/without -C produced the same file
<sjoerd> pitti: who should agree with that :)
<Kamion> all I can say is "worked for me" :)
<Keybuk> yeah, I'll beat daf up to find some better way later
<Kamion> I had to do some additional branding, but i expected that
<pitti> sjoerd: well, before introducing a new group, it should at least be discussed on d-devel, or not?
<Keybuk> applying po-tailored patch hunks seems to work too
<sjoerd> pitti: for something like that, yeah probably
<pitti> sjoerd: because it has wider use; e. g. libgphoto2 could use it, too
<Keybuk> (after all, it has the ultimate same effect, "replace this msgstr with this one")
<sjoerd> pitti: be my guest too propose it then 
<sjoerd> pitti: libgphoto2 uses camera currently....
<pitti> sjoerd: okay; I can explain the whole mechanism in Ubuntu and ask for opinions
<sjoerd> pitti: yeah would be nice
<pitti> sjoerd: camera is certainly okay, but does Debian really want camera, usbdrive, pcmciadrive, etc.
<pitti> sjoerd: adding to my TODO list
<sjoerd> pitti: dunno, i was also wondering about that
<Kamion> lamont: is somebody sorting out a live CD release announcement? question on ubuntu-devel@ ...
<T-Bone> lamont: ping?
<Keybuk> * Considering evolution
<Keybuk> ! 3 patch hunks dropped
<Keybuk> * Building evolution_2.0.2-3ubuntu1.dsc
<Keybuk> that's quite impressive, seeing as it's doing 1.4 -> 2.0 on both sides
<lamont> Kamion: mako said he would put something together yesterday...
<T-Bone> lamont: i'm facing a lot of "unmet dependencies" errors on stage2...
<mako> Kamion: ergh, yes.. got sucked into cc stuff.. will do
<Kamion> ta
<lamont> Keybuk: impressive, or scary? :-)
<lamont> T-Bone: so, um, build them.. :-)
<lamont> T-Bone: example missing build-dep?
<T-Bone> lamont: heh, i'm scared that if they are missing, it's because they didn't build in the first place ;)
<lamont> probably
<T-Bone> lamont: i have also stuff much more scary:
<T-Bone> cpp-3.3: installed (negative dependency)(but version ok 1:3.3.4-9ubuntu5 << 1:3.3.3-0pre1)
<T-Bone> look at "<<"
<T-Bone> that's the build log for xfree86. You can take a look at it, it's rather small (3k)
<lamont> T-Bone: url?
<lamont> or hostname?
<Keybuk> lamont: well, it means either my hunk-at-a-time patcher works ... or there's a major bug in it noticing patch failures :p
<lamont> Keybuk: yeah.  cool.
<T-Bone> lamont: http://envy.esiee.fr/~varenet/logs/xfree86_4.3.0.dfsg.1-6ubuntu25_20041027-1248
<lamont> t-bone: the neg dep is fine
<lamont> it's the lack of libglide3-dev that's fatal.
<T-Bone> ok
<T-Bone> yep
<T-Bone> but isn't it scary that it says "1:3.3.4 << 1:3.3.3" ?
<lamont> it's a build-conflicts
<Keybuk> lamont: what's cool is that it spins rookery's pid counter about 6 times on a run <g>
<lamont> it could be that dpkg could use a better message, but keybuk is working on the merge, so lets leave him alone right now. :-)
<lamont> Keybuk: lol
<lamont> T-Bone: how did the stage1 glide build go?
<Keybuk> that's an sbuild message, isn't it?
<thom> Keybuk: you're a bad man
<Keybuk> thom: I am?
<T-Bone> lamont: do you know the package name? I can't find a stage1 log for "*glide*" :-/
<lamont> t-bone: apt-cache show libglide3-dev | grep ource
<lamont> Source: glide
<T-Bone> lamont: then i assume it didn't go
<T-Bone> [varenet@envy ~] $ grep glide build_list
<T-Bone> [varenet@envy ~] $ 
<T-Bone> looks like it wasn't kept by quinn-diff
<lamont> try explicitly building it against stage1?
<T-Bone> will do
<pitti> lamont: Hi, howdy!
<pitti> lamont: Has the glibc issue been resolved?
<fabbione> hey T-Bone 
<lamont> pitti: yeah.
<pitti> lamont: mdz is sleeping, can you unleash the package to the security archive, too? (and call amber)
<lamont> pitti: in debian/control.in/libc6, g/Architecture:/s/:/: amd64/
* lamont can't, but I bet elmo can.
* lamont wonders how mark is doing on getting those elmo-clones in.
<T-Bone> fabbione: howdy!
<pitti> lamont: now it builds also on amd64? Must I upload a package with this change or did you already do this?
<lamont> ubuntu2.2 is in the archive
<lamont> well, source and binary are sitting there waiting to enter the archive when amber gets goosed
<Kamion> U := $(CURDIR)/debian/udev-udeb
<Kamion> I just KNOW this is going to confuse me
<pitti> lamont: argh, I have to wait for mdz anyway because only he can actually approve the mail to u-s-a
<lamont> hoary.all.amd64:Total 1130 package(s) in state Needs-Build.
<lamont> hoary.all.i386:Total 472 package(s) in state Needs-Build.
<lamont> hoary.all.powerpc:Total 674 package(s) in state Needs-Build.
<Kamion> what's stuck with amd64?
<lamont> Kamion: me.  only 2 buildds atm, while the other 2 both have 3
<Kamion> ah
<lamont> that and I had one of the 2 offline for a bit over an hour last night
<lamont> Kamion: I need to resurrect king now that it's happy again.
<fabbione> T-Bone: how is going the ia64 port?
<T-Bone> fabbione: it's going ;^)
<T-Bone> i'm experiencing build failures that have to be solved on a case-by-case basis, so that takes time
<T-Bone> fabbione: i'm currently progressing in "stage2", aka "warty built against warty"
<Kamion> hm ... I bet d-i doesn't have /bin/mountpoint
<fabbione> T-Bone: cool. please let me know when you have a working pure warty chroot :-)
<T-Bone> fabbione: heh. Don't worry, when that happens, i'll let people know!
<fabbione> ehehe
<thom> lamont: what's the deal with gnutls?
<lamont> thom: ftbfs?
<lamont> doesn't seem to be...
<thom> lamont: no, no. gnutls11 v gnutls10
<sivang> morning folks
<thom> are we standardising on 11 for hoary?
<lamont> oh that... /me needs to request a sync of gnutls11 from debian (new package and all that...)
<elmo> thom: yes
<elmo> lamont: no, you don't
<elmo> it's there
<lamont> thom: metric boatload of changes if we don't, and no reason not to...
<lamont> elmo: even better.
<elmo> people just need to start merging packages that are being held back
<robtaylor> amu: alive yet?
* lamont didn't see it..
<elmo> like libldap2
<lamont> DOH!
<robtaylor> lamont: hal doesnt seem to work on the livecd...
<robtaylor> :(
<fabbione> daniels: please nuke Xprint out of X.org
<fabbione> daniels: even upstream
<fabbione> they don't deserve to live
<fabbione> THEY MUST DIE NOW
<Micksa> geez
<Micksa> you don't like them?
<thom> xprint is the stupidest idea in the world. EVAH.
<Micksa> what's wrong with the idea?
<daniels> fabbione: i'm working on killing it upstream, so is everyone else
<fabbione> daniels: thanks
<daniels> fabbione: remember how I asked you not to ship it? :)
<fabbione> daniels: THEY SHOULD BE BANNED FROM EARTH just for the fact that they use their own site.def and another set of Imake Defines.
<lamont> robtaylor: wonder if it's just that hal doesn't get started...
<daniels> fabbione: xprint is total bong
<lamont> try sudo /etc/init.d/hal start (or whatever it is...)
* enrico bans the xprint people from earth
* fabbione opens the "black bag" with the european nuclear sodomotron control
<lamont> enrico: does that mean they'll be the first to get to mars?
<enrico> lamont: probably.  So they are the one that have to build the toilets
<robtaylor> lamont: nope worse than that... see http://bugzilla.ubuntu.com/show_bug.cgi?id=2758
<robtaylor> lamont: basically there seems to be a fundamental disconnect somwhere between the kernel and hald
<lamont> robtaylor: like that livecd uses a completely different hw detection mechanism?  would that explain it?
<fabbione> lamont: no... they won't be the first anyway
<fabbione> lamont: http://www.fabbione.net/bla/marte.jpg
<fabbione> marte = mars
<lamont> the mars expedition folks here in the states are headquartered in Boulder, CO.
<lamont> fabbione: cool pic
<Mithrandir> fabbione: sheez, put ut some decent pizza place at least. ;)
<robtaylor> lamont: i dont know.. bascially what happens is if you plug in a usb device , hal doesnt even get told of its existance - might be a dbus problem? if the devcie is plugged in at startup, then hal knows about it just fine...
<fabbione> ehhehe
<lamont> robtaylor: could be.  is dbus et al even running on a booted livecd?
<robtaylor> lamont: you mentioned that mini_fo has problems with fs mapped usix sockets? maybe its this?
<lamont> tcp sockets
<lamont> specifically, polling on same with select
<lamont> ==> apt http repositories fail
<robtaylor> lamont: yep, dbus is running
<robtaylor> lamont: oh, thats very odd
* robtaylor wonders why something in VFS land would effect berkeley sockets...
* Kamion builds a test d-i image with hotplug and udev. Wonder how well it'll work ...
<Kamion> oh, shit, I need to be gone. Back in a few hours.
<lamont> robtaylor: because dereferencing a null pointer in the fs layer before you _get_ to berkeley sockets is still fatal
<robtaylor> Kamion: laters
<robtaylor> lamont: sounds pretty scary, one way or another =)
<lamont> yeah - still working out the right anagram expansion for minifo
<lamont> (NFS == Not a File System"
<robtaylor> Might interact nastily in filesystem operations?
<lamont> s/interact/interfere/
<robtaylor> yeah
<robtaylor> =D
<robtaylor> i think we got it ;)
<lamont> heh.  that's the clean version
<justdave> enrico: pong
<enrico> justdave: hey! :)
<enrico> justdave: solved, thanks
<robtaylor> lamont: it just seems that the kernel isnt running hotplug ..
<robtaylor> lamont: if i make hotplug.fuctions write stuff to a file whenever its invoked, nothing ever gets written to that file..
<robtaylor> unless somewhow the kernel is invoking hotplug in a different root ... is that even possible?
<lamont> very
<lamont> there's the real root, the basemod root, and the mainmod root.
<lamont> pick one. :-(
<robtaylor> but surely forat a given point the kernel should be invoking whatevers in /proc/sys/kernel/hotplug in whatever is currently mounted as root?
<robtaylor> s/forat/at
<lamont> hence mdz's comment about chroot vs pivotroot
<robtaylor> hmm. anyway i just tried touching /proc/sys/kernel/hotplug to see if it was a cached inode problem, but that didnt seem to fix it?
<robtaylor> s/?/.
* lamont decides to go catch a nap, or finish last night's sleep, or whatever you want to call it...
<robtaylor> ok, laters lamont
<lamont> this up at 0530 crap is really annoying this night person. :-)
<lamont> :-(
<lamont> back in an hour or two
<robtaylor> heh. slerep tight
<fabbione> lamont: are you trying to turn into me, waking up at 5am each day?
<lamont> fabbione: alarm clock goes off at 0530 every school day.  kids leave for school 0645.  If I drive, then I'm usually back at 0800, if I don't (like today), then I sometimes fall back into bed.
<fabbione> oh yeah...
<fabbione> forgot about the kids going to school
<lamont> otoh, my split up day does make it easier for me to catch the non-US crowd(s).
<lamont> anyway,  bbl
<fabbione> later
<thom> *sigh*; firefox has 24 bugs
<Mithrandir> only 24?
<thom> Mithrandir: most of them are upstream or weird crashers with flash or java
<Mithrandir> probably "if you feed it this invalid bytecode, the JVM will do funny things and crash FF"
<fabbione> AHHHHHHHH
<fabbione> IT DOESN'T EVEN RESPECT THE OPTION TO NOT BUILD ITSELF!
* fabbione kills XPrint from the Imakefiles EVERYWHERE
* Mithrandir gives fabbione some beer
<fabbione> Mithrandir: thanks :-)
<fabbione> root access at fd.org is enough
<Mithrandir> we could just sit on daniels next time we meet him, until he gives us?
<fabbione> rm -rf /var/lib/cvs/xorg/xc/programs/Xserver/XpConfig would be enough
<fabbione> Mithrandir: eheheh
<thom> ok. firefox in warty is 0.99+1.0PR.1+revertedto0.9.3-0ubuntu3
* daniels stares at thom.
<elmo> seb128: ?
<seb128> elmo: ?
<thom> is 1.0~0.10.1-0ubuntu1 a reasonable version for hoary? (can we use ~ yet?)
<elmo> seb128: you're only doing ubuntu uploads were the are ubuntu changes, right ?
<mdz> gah, did pitti leave?
<elmo> thom: I don't know if we want to, but if the consensus is that you do, let me know, because I'll have to unblock it in katie
<seb128> elmo: hum ? I've uploaded new versions that are not and debian, and merged warty changes for the *gksu*
<daniels> thom: hmm, since really < reverted, you could have 0.99+1.0PR.1+seriously+1.0PR.1-0ubuntu1
<elmo> seb128: ok, I couldn't tell from your changelog, if there still warty changes or not.. just wanted to double check
<seb128> elmo: ok, that's fine, thanks for checking :)
* thom smites daniels with great and terrible wrath
<daniels> or 'totally+1.0PR.1'
<thom> i really don't want to go down the 0.999 road
<sid77> 0.999 is evil (almost)
<daniels> sid77: as opposed to 0.99+1.0PR.1+seriously+1.0PR.1?
<aj> elmo: does dak logging/etc deal with ~ okay now?
<sid77> daniels, that is evil (completely)
<thom> so the quick answer was "no, you can't use ~. KTHXBYE"
<thom> ;-)
<elmo> aj: no, that was implicit in "unblock", i.e. use something other than tilde-seperated-value for logging :)
<aj> elmo: heh
<elmo> thom: no, the katie thing can and should be fixed - the answer to your question is independent to that
<aj> thom: "1.0~0.10.1-0ubuntu1" is hella complicated; the 0.10.1 can't be just pre1?
<thom> aj: probably, yes
<thom> mdz: ^ ?
<mdz> thom: ?
<thom> mdz: thoughts on firefox versioning?
<mdz> thom: for going back to 1.0PR?
<thom> yeah
<Keybuk> 1.0~PR ?
<thom> (with appropriate patches)
<thom> Keybuk: my suggestion was close to that, yes
<jdub> tilde?
<Keybuk> jdub: sorts less than null, so 1.0~ < 1.0
<Mithrandir> jdub: tilde mean "less than" in newage debian versioning speak.
<jdub> heh
* Mithrandir ducks
<Mithrandir> or less than zero
<Mithrandir> minus epsilon
<Mithrandir> or something
<Keybuk> it's a bugger to explain, isn't it <g>
<aj> "actually, immediately prior to what i just said" kinda works
<aj> "it's version 1.0 -- actually just before 1.0 -- sub version pre1"
* Keybuk calls them pre-versions
<jdub> perhaps "... but i'm bullshitting you" works
<aj> nah, better to reserve that for the 0.999-but-really-1.0pre1 versions out there
<mdz> thom: '~' gives me the fright
<Keybuk> mdz: any particular reason?
<aj> mdz: ooo, costume ideas for halloween
<mdz> Keybuk: because nobody has used it for anything particularly important yet
<Keybuk> that's because the Debian archive won't accept them until dpkg 1.10 is in a stable release
<mdz> but of course, now is the time to break it if it 's going to break...
* Mithrandir tries to imagine aj dressed up as a tilde.
<mdz> it needs an elmo signoff
<Keybuk> I was kinda nervous, then I read the code and it was a "woah! that's actually really elegant" when I saw how it was implemented
<aj> /msg elmo quick: type /quit ~ is okay by me!
<aj> Keybuk: (of /course/ it was really elegant...)
<fabbione> hey mdz
<aj> (i mean, really -- code getting into dpkg without being elegant? the very thought!)
<Keybuk> aj: yeah, I mean, it's so great that I could merge the bzip2 stuff in and being totally sure it would just work
<Keybuk> the fact it didn't even *compile* because someone typo'd the #ifdef so never actually ever ran it was a figment of my imagination
<aj> Keybuk: i guess you take drugs for that now though?
<Keybuk> aj: I must be, for agreeing to maintain the fucking thing :p
<Mithrandir> Keybuk: did you ever agree to it?
<aj> Keybuk: oh dear, never a good sign when you don't know what drugs you're taking
<Mithrandir> I thought we just made you?
<elmo> mdz: I'll need to unbreak katie - but I thought you had concerns about back compat or so?
<mdz> elmo: depends on whether sarge releases before hoary
<mdz> well
<mdz> mozilla-firefox isn't even in woody, is it?
<Keybuk> no
<Keybuk> it didn't *exist* when woody was released
<jdub> (haw haw)
<aj> i don't see how it matters even if hoary releases before sarge?
<mdz> aj: if hoary releases before sarge, we will support upgrades from woody to hoary
<aj> you've got 1.0.1 in woody, 1.1 in warty, 1.2~1 in hoary, 1.2 in sarge
<aj> your only bug is if someone uses woody's dpkg, and installs the package from hoary or sarge, then tries pointing apt and the other, without ever upgrading dpkg/apt
<Keybuk> mdz: but we don't support upgrades from woody to warty ?
<mdz> Keybuk: of course we do
<Micksa> lifeless: I'm still undecided on whether to come on on friday.
<Micksa> oops.
<Micksa> grah
<mdz> thom: why don't we stick with what Debian is doing?  they seem to have 0.10.1+1.0PR
<mdz> that's newer than 0.99+1.0PR.1+revertedto0.9.3-0ubuntu3
* Keybuk covers his eyes!
<Mithrandir> 0.100.1+1.0PR ?
<Keybuk> it really isn't dude
<Keybuk> 0.10 < 0.99
<mdz> oh, missed the 0.99
<thom> 0.10.1 so isn't hiugher
<mdz> wtf is 0.99?
<mdz> I read it as 0.9
<Keybuk> mdz: nearly but not quite
<sid77> what about a 0.9.3-<current version>?
<Keybuk> sid77: 9 < 99
<thom> 0.99 was my screwup early on
<mdz> thom: if elmo is ok with ~, I'm ok with ~
<mdz> elmo: you need to unbreak katie, or you need to remove the fascist check that forbids ~?
<mdz> I thought katie used apt's version comparison code
<sid77> Keybuk, right, but doesn't it start from 0.9.3?
<elmo> mdz: it does - I thought apt supported ~ ?
<mdz> elmo: it does
<mdz> elmo: so what unbreaking is required?
<thom> mdz: 16:20 < elmo> aj: no, that was implicit in "unblock", i.e. use something other than tilde-seperated-value for logging :)
<Keybuk> sid77: 0.9 is less than 0.99 because 9 is less than 99
<elmo> mdz: I use ~ as a separator in log files.   go me.
<mdz> elmo: oh, rad
<elmo> and also there's a regex which checks for "validity" which needs updated, but that's trivial
<thom> yay for intra debian communication
<thom> ;-)
* Keybuk looks at that "*please* implement Enhances" bug
<mdz> "implement"?
<elmo> thom: it's nothing to do with intra debian communication, tilde-seperated log files are something I picked up from work, and at the time I wrote the katie stuff, ~ wasn't even being discussed for versions
<elmo> err, previous work, obviously
<Keybuk> we're fast running out of silly characters to use for things
<sparkes> yay, utf
<mdz> \000
<sid77> Keybuk, maybe we should introduce a new number space where 99 < 9 :)
<Keybuk> thom: does firefox use libtool anywhere?
<lifeless> sid77: aleph-1 ?
<lifeless> (as opposed to aleph1)
<thom> Keybuk: oh christ
<sid77> lifeless, geeee...
<mdz> elmo: is it realistic to change that in order to allow for thom's firefox upload? or do we need to do something else for the short term?
<elmo> mdz: I can probably fix it tonight - shouldn't take long
<mdz> Keybuk: will libtool require un-breaking as well?
<Keybuk> yes
<mdz> hell
* Keybuk considers what other silly character to use as $IFS <g>
<mdz> Keybuk: how bad is it?
<elmo> why would libtool care about the Debian version ?
<Keybuk> mdz: you know Libtool just flatly falls on its face and flops about when you have spaces in file or directory names?
<thom> elmo: the ~ is in the upstream version?
<Keybuk> elmo: mozilla-firefox-1.0~1/debian/...
<elmo> this is going in the filename??
<Keybuk> elmo: goes in the directory name, doesn't it
* elmo runs away screaming
<mdz> Keybuk: sure, but we're not giving it spacess, we're giving it tildes :-)
<thom> ok, so maybe i'll work on some other stuff for a while :-)
<Keybuk> mdz: libtool uses IFS="~" internally for some things
<mdz> err
<Keybuk> (multi-command link lines)
<mdz> it's starting to sound like it would be easier to fix dpkg and apt :-P
<seb128> jdub: 
<seb128> <CIA-1> cneumair * gnome-panel/gnome-panel/ (10 files): (log message trimmed)
<seb128> <CIA-1> Fix bug #143963 [http://bugzilla.gnome.org/show_bug.cgi?id=143963] : "Remove Distro Menu".
<seb128> jdub: finally :p
<jdub> hooray! :)
<Keybuk> thom: http://people.ubuntu.com/~scott/keybuk-tilde-beep.patch is the libtool patch
<daniels> Keybuk: dude, BEL?  seek professional help.  like, three weeks ago.
<Keybuk> daniels: well, it's unlikely to appear in filenames <g>
<Keybuk> (well, unless your cat walks across your keyboard while in vi)
<daniels> libtool has destroyed your brain
<thom> holy mother of god save us.
<Keybuk> it was ^M, but some editors "helpfully" strip that
* daniels stares at Keybuk.
<aj> Keybuk: it'd be possible to have "1:1.0~pre1" be translated to "1.0pre1" for user visible stuff, like filenames, directory names, dselect, etc. that'd make things like 1.0~1 suck, of course.
<Keybuk> aj: that's the other solution, yes.  fix dpkg-source
<Keybuk> that's actually less sick than it sounds, because we already don't put the epoch and ':' in filenames
<aj> apt does, but url escapes them
<Keybuk> tar gets somewhat upset when asked to do 'tar czf blah_1:1.0.orig.tar.gz blah-1:1.0'
<aj> really?
<Keybuk> sure
<aj> why?
<Keybuk> it thinks blah-1 is a hostname to rcp 1.0 from
<aj> really??
<Keybuk> yup
<Keybuk> you've never encountered this before?! :p
<aj> i don't use colons in filenames :)
<aj> nor do i use rsh :)
<Keybuk> this is the reason dpkg hides the epoch from the filenames
<Keybuk> it breaks things :p
<thom> that sounds like a much saner approach for ~ too
<aj> wow, tar sucks
<elmo> Keybuk: WTF dude, neither had you till a week ago - I told you about it in London :-P
<Keybuk> elmo: true :o)
<aj> geez, elmo's such a spoil sport
<Keybuk> that was the first time I'd encountered it <g>
<Keybuk> and, admittedly, probably the first time I'd ever tried to use ':' in a filename
<aj> tar czvf - foo:bar > foo:bar.tgz works though :-/
<aj> ahh, gnu tools. gotta love 'em.
* Keybuk ponders which of s/~// and s/~/%7f/ is the least sick
<robtaylor> Keybuk: s/~/LESSTHANONOTREALLYMAYBE/ ;~)
<robtaylor> lets keep that clear semantic information intact ;-) 
<jdub> night all
<robtaylor> night jdub 
* sid77 bye
<Keybuk> %7F is ugly
* Keybuk squirms
<Keybuk> dpkg-source.pl: extracting build-essential in build-essential-11%7F
<Keybuk> much cuter without it
<thom> yes
<thom> that is quite nasty
<Keybuk> dpkg-source.pl: extracting build-essential in build-essential-11_
<Keybuk> a little nicer
<Keybuk> bleh
<robtaylor> heh. more mathematicallys s/~/)/
<robtaylor> ;)
<robtaylor> (out of interest.. whats the problem with just using ~ in the filename?)
<Keybuk> robtaylor: libtool go boom
<robtaylor> Keybuk: ah . boh
<Keybuk> though I actually can't make it fail now, amusingly
<robtaylor> Keybuk: is there a particular reason it might choke on ~?
<Keybuk> robtaylor: yeah, uses IFS=~ internally
<robtaylor> ahhh
<robtaylor> ugh
<Keybuk> though it's now working on places it should fail
<Keybuk> ar cru .libs/libtest.a  /home/scott/tmp/tilde~test/test2.o
<Keybuk> ranlib .libs/libtest.a
<Keybuk> -- 
<Keybuk> that should fail, theoretically
<Keybuk> maybe it's just 1.4 which breaks, in which case I don't care
<Keybuk> (you can see I really tested this, can't you :p)
<robtaylor> heheh
<robtaylor> isnt that waht users are for? ;)
<Keybuk> thom: can you try building firefox in a dir with ~ in it ... I have a hunch it'll work
<Keybuk> my libtool test suite *cough*gnome*cough* builds ok
<thom> heh
<Keybuk> 1.4 does fail
<Keybuk> but 1.5 actually doesn't eval the variables until inside the loop (at which point the IFS=~ doesn't matter)
<Keybuk>     save_ifs="$IFS"; IFS='~'
<Keybuk>     for cmd in $cmds; do
<Keybuk>       IFS="$save_ifs"
<Keybuk>       eval cmd=\"$cmd\"
<Keybuk> so the variable with the directory name in it doesn't get expanded inside $cmd until afterwards
<Keybuk> cool
<bluefoxicy> o.o
<bluefoxicy> Where would i go to discuss proactive security (http://wiki.ubuntu.com/ProactiveSecurity) and the development of Ubuntu (and Debian by upwards inheritance) to include enhancements not detrimental to the user experience or to binary compatibility?
<Keybuk> gah, pretty initscripts make merging hurt
<Keybuk> zsh: segmentation fault (core dumped)  ls -bFh --color=auto -d ../sources/*/results
<Keybuk> gee... thanks
<thom> Keybuk: it's still running, but it's not blown up
* Kamion returns
<Keybuk> elmo: do you want a list of things we can actually just sync from Debian again?
<Keybuk> most of lamont's libtiff4-fest for example
<Kamion> hm, I do like the way my random test Ubuntu installs are set up with a random language
<Kamion> and keyboard layout; makes for extra fun when typing passwords
<Keybuk> heh
<thom> heh
<Kamion> hooray, my udev-ised test CD ... totally blows up
<thom> rock on
<mdz> Keybuk: do you have a merged alsa-utils?
<Keybuk> yup, want it?
<mdz> yup
<thom>  < Tybstar> it would be cool if CUPS had a reasonable default paper size depending on the location you picked at install
<mdz> thom: yes, it would
<thom> (he works for specifix, who do conary)
<thom> oh dear:
<thom> 18:15 < sri> fer: just think how awsome the porn would be, various actions related to each stage woo..
<thom> 18:15 < fer> sri: wops
<thom> (on graphical boot)
* bluefoxicy pokes people
<thom> 18:16  * sri can imagine hww delicious fscking would be :)
<thom> 18:16 < fer> linux-2.6.9-p0rn1
<thom> 18:16 < fer> and mount!
<Keybuk> mdz: http://people.ubuntu.com/~scott/alsa-utils/
<Keybuk> there's an oddness there, it looks like Debian dropped 90_debian_alsaconf.dpatch
<Kamion> ah, busybox mount doesn't support --bind, hmm
<Keybuk> and there's a few Debian changes to control in .dropped that didn't apply
<mdz> thom: CRACK
<thom> mdz: *g*
<mdz> Keybuk: if debian dropped that patch, why is it still in debian/patches in the output?
<Keybuk> mdz: because we changed it
<mdz> we what?
<Keybuk> we changed 90_debian_alsaconf.patch
<Keybuk> -+  cfgfile="/etc/alsa/modutils/1.0"
<Keybuk> ++  cfgfile="/etc/modutils/alsa-base"
<Keybuk> specifically
<mdz> ok, that's not important, since we later dropped alsaconf entirely
<Keybuk> bit trivial really :)  should be easy to resolve, find which of the tree split files that's in, fix it, and kill the warty file 
<mdz> I wonder if it's fixed in 1.0.6
<Keybuk> _warty.patch is the base->warty patch, _debian.patch is base->debian, _hoary.patch is debian->merge
<Keybuk> so you pretty much side-by-side compare _warty.patch and _hoary.patch to see whether anything went wrong
<mdz> where did all these control file changes come from?
<mdz> they're not in the changelog
* mdz looks at fabbione
<Keybuk> "fabbione" :)
<Keybuk> the ones in .dropped are *Debian* changes
<Kamion> mmmkay, I wonder if d-i trunk is hosed at the moment
<Keybuk> the ones in _warty.patch were our changes
<mdz> where is .dropped?
<Kamion> there's some very suspicious pissing about with /proc/self/fd/0 and /dev/console
<Keybuk> same directory
<Keybuk> http://people.ubuntu.com/~scott/alsa-utils/alsa-utils-1.0.6.dropped
<mdz> ah, my 'get *' didn't get it
<mdz> oh, yes it did
<Keybuk> that basically logs the IKEA "I put it together, what's this bit for?" hunks
<mdz> I thought you meant literally ".dropped"
<Kamion> #6
<Kamion> (oops)
<bluefoxicy> o_o
<bluefoxicy> hmm.
<bluefoxicy> Noo ne?
<mdz> Keybuk: the reason that one fell out is because fabio changed the Maintainer: field in the ubuntu branch for some reason
<Keybuk> yup
<Keybuk> not sure why the description fell out, I suspect just because it was a bit too close
<thom> bluefoxicy: the ubuntu devel mailing list would seem to be appropriate
<mdz> Keybuk: resolved, uploaded
<Keybuk> cool, I'm just finishing off the last of the packages without a .dropped (basically checking things are sane)
<mdz> Keybuk: did you get official word from elmo about your key?
<Keybuk> then I'll stick them all somewhere
<Keybuk> mdz: not yet
<mdz> mdz@jackass:~ $ gpg --keyring /srv/keyring.no-name-yet.com/keyrings/ubuntu-keyring.gpg --list-keys remnant
<mdz> pub  1024D/84AD676C 1999-12-30 Scott James Remnant <scott@netsplit.com>
<mdz> looks to me like it's there, as it should be
<Keybuk> that's the wrong one
<bluefoxicy> thom:  oy now I have to find those-
<Keybuk> C978C8AE  is my canonical key
* bluefoxicy is subscribed to something like 36 MLs
<bluefoxicy> thom:  no better suggestions?
<mdz> Keybuk: does there exist a copy of that key with useful signatures on it?
<mdz> I seem to have one in my keyring, but it has zero signatures
<seb128> hum. Any way to get a sync for librsvg2 2.8.1-1 ? The warty changes are in the new debian version too 
<mdz> seb128: sure, just email elmo
<Keybuk> mdz: should be signed by daniels, fabbione, lalo and debonzi
<mdz> Keybuk: but where?
<mdz> it's not on pgp.net or keyring.d.o
<mdz> Keybuk: if you only keep the signatures locally, it doesn't count :-)
<Keybuk> subkeys.pgp.net has them
<seb128> elmo: any way to get a sync from debian for librsvg2 2.8.1-1 ? The warty changes are in the new debian version
<elmo> seb128: done
<seb128> thanks !
<bob2>  hm, why is "apache-common" in main, while the rest of apache 1 is in universe?
<elmo> it's not
<elmo> apache-dev is in main too
<elmo> for php4
<elmo> (b-d)
<bob2> hrm, ok
<bob2> well, the apache 1 daemon is in universe at least
<bob2> oh, ew, some of apache 1 is in main so libapache2-mod-php4 can build?
<Kamion> hm, current grub seems to build-dep on type-handling too ...
<mdz> that type-handing crack needs to go
<mdz> grub.maintainer == type-handling.maintainer, I think
<Kamion> mdz: yes
<Kamion> mdz: you misspelt "dealer"
* mdz nods
<mdz> lamont: ping?
<mdz> Kamion: are you running britney or anything like that over hoary yet?
<mdz> do we have some idea what the dependency breakage is like?
<Kamion> mdz: elmo runs it now, I just mirror it
<Keybuk> -Maintainer: Tommi Virtanen <tv@debian.org>
<Keybuk> +Maintainer: Fabio M. Di Nitto <fabbione@fabbione.net>
<Keybuk> heh
<elmo> mdz: yeah, it's bad, 'cos of gnutls mostly AFAICS from a quick glance
<elmo> which should be building now
<__daniel> britney?
<Kamion> mdz: but it's in the same place, yes
<Kamion> http://people.ubuntulinux.org/~cjwatson/testing/
<mdz> Keybuk: which package is that?
<mdz> Kamion: found it, thanks
<Kamion> __daniel: script that manages Debian's testing distribution; we run it in a very cut-down form to check for dependency breakage
<mdz> elmo: gnutls caused binary deps to break?  or build-deps?
<elmo> mdz: binary, gnutls10 -> 11 transition
<Keybuk> mdz: uh, python-osd I think
<elmo> e.g. libldap2 is uninstallable
<Keybuk> I went past it pretty quickly with a giggle
<__daniel> Kamion: wow - that sounds cool - every time i hear about debian / ubuntu infrastructure i'm absolutely impressed
<mdz> ah, right, all the libgnutls10 deps on our existing binaries
<mdz> that sort of sucks
<Kamion> __daniel: was kind of a necessity when we were putting things together, otherwise the only way to tell whether warty was hosed was to build a CD, rsync it down, burn it, boot/install it, and see if it worked
<Kamion> __daniel: I got bored of doing that very quickly :)
<__daniel> kamion: that's what mvo_ told me (he lives just some km s away from me): "after some time, you just see, what the infrastructure DOESN'T do for you"
<__daniel> i'm still very perplexed by it all :-)
<mdz> elmo: so once gnutls is built, we need to rebuild pretty much everything?
<lamont> mdz: ack
<mdz> lamont: what does the hoary buildd picture look like?
<lamont> hoary.all.amd64:Total 894 package(s) in state Needs-Build.
<lamont> hoary.all.i386:Total 1 package(s) in state Needs-Build.
<lamont> hoary.all.powerpc:Total 181 package(s) in state Needs-Build.
<lamont> working on that amd64 thing now
<lamont> which is part of why it's behind - took one buildd offline to clone the 4 chroots
<mdz> lamont: thanks
<mdz> lamont: also, how many packages will we need to rebuild to fix the gnutls situation?
<lamont> gnutls11 is in the archive, with stuff depwaitng on it - you're after that count?
<lamont> hoary.all.amd64 18
<lamont> hoary.all.i386 21
<lamont> hoary.all.powerpc 20
<lamont> packages dep-wait libgnutls11-dev
<mdz> lamont: I mean, we have a bunch of pakcages which depend: libgnutls10
<mdz> do all of those have new versions which build-dep on the new gnutls?
<mdz> or will we need to build some of them explicitly?
<lamont> ah, will check.
<mdz> thanks
<lamont> fwiw, gnutls10 is there, but I gather we want it to go away.
<lamont> 70+packages with the depends...  I'm going to let the dust settle on the buildd and then figure out where we are, I think.
<lamont> meanwhile, fixing amd64
<mdz> lamont: gnutls10 binaries will vanish once gnutls11 binaries appear, no?
<mdz> lamont: from the numbers you gave above, it looks like i386 dust is quite settled already
<elmo> mdz: no
<elmo> it's two separate source packages
<mdz> oh
<T-Bone> lamont: i'm currently under 50% packages successfully built on stage2
<mdz> so we don't actually have a problem, then, do we?
<mdz> the stuff which depends on gnutls10 will be satisfied
<elmo> mdz: e.g. libldap2 is uninstallable
<elmo> because although both are there, they aren't co-installable
<elmo> so we need to get our libraries transitioned over ASAP
<mdz> oh
<mdz> I thought Debian did this transition for sarge
<mdz> is it blocked by packages which need merging?
<Kamion> there were a few transitions involved, I believe
<mdz> ah, openldap2 is branched
<elmo> right
<elmo> I mentioned this last night - probably should filed a bug, sorry
<mdz> Keybuk: openldap2?
<elmo> btw - does anyone have any clever ideas on how to fix the problem that we have two suites and the same arch/version of a package wants to be in different components in each suite?
<Kamion> anyone know what's responsible for starting udevd?
<Kamion> I'm booting a d-i CD here with init=/bin/sh, and udevd is started right at the very beginning of the initrd; I can't figure out what's doing it
<lamont> elmo: python? :-)
<mdz> openldap2 -2ubuntu1 and -2ubuntu2 seem to be present in Debian
<Kamion> component overrides? :-)
<lamont> sounds like the component tuple needs to grow by suite-name...
<lamont> mdz: do I want to know who the uploader was?
<elmo> nono
<elmo> remember the pool is split by component
<mdz> lamont: no, I mean the changes
<mdz> -2ubuntu1 and -2ubuntu2 were ubuutu backports from Debian
<Kamion> elmo: oh, toss
<elmo> so say we have dpkg_1.9.21 in warty/main, if it's demoted to universe in hoary/, it has to physically move from pool/main, to pool/universe
<Kamion> elmo: hardlinks?
<elmo> oh, hmm, then again.. why does it? :>
<mdz> Kamion: weird, re: udevd
<Kamion> elmo: mirrors would probably kind of like it to
<mdz> Kamion: I didn't think anything other than S04udev started udevd
<Kamion> at least people who don't mirror pool/universe/ (in the vice-versa situation)
<lamont> mdz: ah, that helps
<Kamion> elmo: such as, hm, just for example, cdimage :-)
<Keybuk> mdz: yeah, there's a openldap2 -- am going to re-run these though with the new .po handling Kamion's just helped me with
<mdz> Keybuk: openldap2 doesn't have any .po file changes
<Keybuk> ok, hang on then
<Kamion> mdz: yeah, I'm stumped
<Keybuk> http://people.ubuntu.com/~scott/openldap2/
<mdz> Kamion: maybe the udev hotplug hook starts udevd if it isn't running?
<mdz> Keybuk: fetching, thanks
<Keybuk> note that the stuff in .dropped *isn't* identically present in Debian
<Keybuk> (though if you're lucky it's a silly whitespace change or something)
<Kamion> mdz: the string "udevd" doesn't appear anywhere in the initrd
<mdz> Kamion: er, so udevd isn't actually present?
<Kamion> /sbin/udevd is there
<mdz> that counts as a string :-)
<Kamion> no other occurrence of udevd in filenames though
<Kamion> er, files
<mdz> Kamion: what's in /etc/hotplug.d?
<Kamion> chandev default dock ieee1394 input net pci scsi usb
<Kamion> ah, default/10-udev.hotplug is a symlink to udevsend
<Kamion> that probably explains it
<mdz> Kamion: that's what I meant by: <mdz> Kamion: maybe the udev hotplug hook starts udevd if it isn't running?
<Kamion> right, I missed it 'cos it was a symlink
<mdz>        If udevd isnt already running, udevsend will start it.
<mdz> (udevsend(8))
<Kamion> is there a way to tell it to queue events instead?
<mdz> Kamion: kill -STOP udevd? :-)
<Kamion> no, I have to make it go away
<mdz> Kamion: you could disable hotplug
<Kamion> it's stopping me umounting /initrd
<Kamion> from where? :)
<mdz> sysctl
<Kamion> run from where?
<Kamion> this is *before /sbin/init*
<mdz> seb128: here?
<mdz> Kamion: *blink*
<seb128> mdz: yes
<Kamion> mdz: or, at least, before I can guaranteeably do anything; umount /initrd is the second command in /sbin/init, and it's failing because udevd is running
<mdz> seb128: gnome-settings-daemon segfaults in hoary
<mdz> seb128: is this expected?
<seb128> mdz: no
<seb128> let me upgrade my test box 
<Kamion> maybe I could install hotplug somewhere different and move it into place after pivot_root or something
<mdz> seb128: /msg'd you the backtrace
<Kamion> I can't wait until anna
<seb128> mdz: ok, thanks
<mdz> Kamion: is there a way to set a sysctl from the kernel command line?
<Kamion> mdz: hm, the kernel command line is already running badly out of space for preseeders, don't want to stress it any more
<mdz> Kamion: you could just fuser -mk before unmounting it
<Kamion> no fuser, and not sure I want to risk killing udevd in the middle of handling an event
<mdz> if it's running in something that isn't the real root anymore, should be fairly harmless
<Kamion> yeah, but it might mean some bit of hardware doesn't get recognised
<Kamion> or?
<Kamion> I always thought boot events were queued
<mdz> Kamion: later on in the boot process, the udev init script tells it to create nodes for everything it already knows about
<Kamion> I think it's probably going to be more predictable to ensure hotplug is not run in the initrd
<mdz> I imagine that in a normal system, the events are just ignored in the initrd, since it doesn't have hotplug
<Kamion> yeah
<seb128> mdz: control-center crash fixed in 2.8.1-0ubuntu2 just uploaded
<mdz> thanks
<Kamion> mdz: lucky you backed out that perl-in-hotplug thing actually, otherwise trying to use it in d-i would be a total bust
<seb128> np
<elmo> kamion: ah, yeah, damn, fair point
<Kamion> I suspect there'll be problems anyway, /etc/hotplug/*.rc uses a load of stuff that I bet isn't available in busybox
<Kamion> elmo: since it needs to be available in both places, hardlinks/copies are probably the only option :(
<elmo> yeah, but the whole point of pools was to avoid managing hardlink farms.  gar, sucks.
<Kamion> yeah, I know :(
<Kamion> mdz: hm, bright spark here has just realised that it might be kind of useful to have modules.pcimap available; hotplug does need that even in 2.6, right?
<Kamion> modules.*map I guess
<mdz> yes
<Kamion> arrrr, this sucks, they're huge
<mdz> crap
<mdz> I didn't type that fast enough to evade workrave
<Kamion> although only 63K compressed, I guess
<mdz> I haven't figured out its algorithm yet, but it has a certain small tolerance built into it
<Kamion> maybe I can figure out a reduction algorithm; like, only include the lines that actually match modules available in d-i :-)
<Kamion> there is a problem with amd64: the boot messages are visible for about a tenth of a second :P
<mdz> Kamion: gzipping them wouldn't be a half bad idea, except that hotplug reads them about 80 BILLION TIMES
<Kamion> mdz: don't care so much about uncompressed size for now, although the lowmem people will care
<mdz> I'm surprised they don't compress better than that
<mdz> mdz@potpal:/lib/modules/2.6.8.1-3-386 $ cat *map |wc -c
<mdz> 324028
<mdz> mdz@potpal:/lib/modules/2.6.8.1-3-386 $ cat *map |gzip -9 |wc -c
<mdz> 15500
<Kamion> oh, I was using modules.*
<mdz> not entirely sure whether modules.alias is used still
<mdz> modules.dep you need anyway, of course
<Kamion> I think it
<Kamion> 's reduced, though
<mdz> elmo: gnutls11 is built, but its binaries are in universe (though depended upon by packages in main)
<elmo> mdz: yeah
<seb128> mdz: libxml++2.6 is new in deb and not in universe ... what should be done to get it, just ask a sync ?
<elmo> libgcrypt11 would be another one to merge
<elmo> seb128: we're missing new packages ATM, I'll hopefully fix that tonight
<seb128> ok, thanks
<mdz> elmo: libgcrypt11 is safe to overwrite with the version from Debian, please sync it
<elmo> cool, done
<elmo> then I can move it to main ;-)
<Keybuk> \_ patch -stuN -z .magic-orig -r /home/scott/magic.patch-reject -p1
<Keybuk> I love that command
<Keybuk> "set patchers to stun"
<mdz> Keybuk: you so added the -u just to make a word :-P
* Keybuk whistles and examines the ceiling
<graham> tseng, are you the tseng of mono repository fame?
<tseng> sure
<graham> would you be interested another package? I've recently packaged Spam Trainer.
<tseng> its not very useful to me
<tseng> but if it works, you can email it to me and ill upload it eventually
<graham> fair enough
<elmo> WTF is with bugzilla and firefox?
<graham> incidentally, I had an error trying to build tomboy myself from the source package and I think it might be missing a build dep.
<elmo> Kamion: ?
<tseng> graham: there is a syntax error
<tseng> missing )
<graham> I think it was the perl XML libs, but I've not got my laptop running right now and might be wrong. I'll check for the ) though.
<graham> do you use pbuilder?
<tseng> i use dpkg-buildpkg
<graham> okay. I'll check it out when I get my laptop out as I need to run spam trainer through pbuilder anyway.
<tseng> you can fix the package by fixing the ) in debian/control
<graham> ok, thanks.
<tseng> nps
<amu> re
* amu is back from the LWE 
<amu> mark#s talk was nice, and ubuntu get into the final for an award  
<mdz_> elmo: which bugzilla/firefox bit in particular?
<amu> sabdfl: wb 
<mdz_> elmo: you can file those bugs in bugzilla, some of them are already there and some have been fixed
<elmo> mdz: it keeps hanging when I scroll down with the wheely mouse button
<sabdfl> hey all
<mdz_> elmo: ah, that one
* lamont is happy to announce that king is back in the rotation
<sabdfl> hey amu, long time no see :-)
<mdz_> elmo: happens with some other sites, too
<sabdfl> lamont: long live the...?
<sabdfl> amd64
<lamont> and we have buildd/sbuild for amd64 architectures now.
<mdz_> elmo: https://bugzilla.ubuntu.com/show_bug.cgi?id=1962
<amu> sabdfl: i joined the social event, ubuntu was was one of the final getting an award   
<sabdfl> cool!
<lamont> hoary.all.amd64:Total 858 package(s) in state Needs-Build.
<lamont> hoary.all.i386:Total 1 package(s) in state Needs-Build.
<lamont> hoary.all.powerpc:Total 123 package(s) in state Needs-Build.
<sabdfl> who was issuing th awards?
<lamont> amu: cool!
<sabdfl> "best nekkid people"?
<amu> sabdfl: LWE for best distros's best database ..... 
<mdz> who was _receiving_ the award? :-)
<amu> skole :) 
<Keybuk> elmo: where do you want a list of packages we can sync from Debian?
<Keybuk> (because they took all our changes)
<sabdfl> *cough*
<sabdfl> que?
<mdz> Keybuk: yes, he does :-)
<mdz> amu: surely you're joking, Mr. Mueller
<elmo> keybuk: mail or url link - whatever
<sabdfl> skole won an award, over ubuntu?
<amu> mdz: it's like this 
<Keybuk> elmo: http://people.ubuntu.com/~scott/revert
<Keybuk> that's the first chunk
<amu> guess they should add new new award, for the best debian distro
<mdz> amu: confused
<mdz> who gave an award to which distribution, and who accepted it?
<amu> mdz: ... the last years all time debian won 
<elmo> Keybuk: you're 100% sure about this?  i can't undo once I start
<elmo> (sanely anyway)
<amu> LWE gives some awards to the projects.  
<lamont> elmo: and insanity takes is _soo_ painful.
<dante_> pardon ... could someone point me to the correct 'registration' page in the official ubuntu site? I see the 'log in' button but can not find an initial 'registration' area.
<amu> the distro award goes to skole this year 
<Keybuk> elmo: yeah, they all resulted in a zero debian->hoary diff
<Keybuk> (well, just changelog mogs)
<mdz> amu: bu tyou said ubuntu received an award?
<mdz> s/bu ty/but y/
<mdz> Keybuk: did you eyeball them?
<Keybuk> mdz: yup
<Kamion> elmo: yep?
<amu> mdz: one of the final canditates ... but skole won at least 
<mdz> amu: ah, ok. so ubuntu was a finalist
<amu> mdz: yap 
<mdz> but did not receive an award
<amu> yap 
<elmo> Keybuk: ok, doing now
<graham> it appears as though "skjermbilder" means "screenshot" in norwegian. neat. I've never heard of skoke before; what did they win for?
<__daniel> graham: good question :-)
<graham> I'm thinking it must be amazing...
<Kamion> skolelinux are a Norwegian Debian derivative; they do mass rollouts of preconfigured systems with automatic LDAP setup etc. in schools.
<Kamion> quite specialised
<Kamion> any udev experts in the house?
<graham> thanks
<Kamion> how do I make it create /dev/fb/0?
<Kamion> I'm using devfs.rules and compat-full.rules
<Keybuk> what's it creating currently?
<__daniel> Kamion: this is what i got in devfs.rules:  KERNEL="fb[0-9] *",  NAME="fb/%n",
<Kamion> __daniel: yes, likewise
<Kamion> Keybuk: nothing for the framebuffer device that I can find
<Keybuk> Kamion: do you have the appropriate module for it loaded?
<Kamion> Keybuk: yes
<Kamion> vga16fb and fbcon
<Keybuk> and you're not getting either /dev/fb0 or /dev/fb/0 ?
<Kamion> I can make everything work if I create the device node by hand
<Kamion> Keybuk: nope
<elmo> Keybuk: k, imported
<Kamion> it's possible hotplug was hosed actually, I'll try again
* elmo goes to eat dinner - bbiab
<Kamion> minor detail of having the wrong thing in /proc/sys/kernel/hotplug ...
<Keybuk> elmo: imported what where?
* Kamion suspects he means your key
<__daniel> Kamion: works at my place... ah ok
<Kamion> __daniel: this is in the installer FWIW, it's a very minimal system and entirely possible I've left bits out :)
<Kamion> trying to figure out the chain of code involved
<__daniel> Kamion: oh... i see
<Keybuk> 98819394 bytes transferred in 2 seconds (62.16M/s)
<Keybuk> Total 203 files transferred
<Keybuk> whee
<Keybuk> let's see if I get any messages
* lamont wanders off for a few minutes
<Keybuk> Kamion: I don't think he did import my key
<Keybuk> no response yet
<elmo> no, not that
<elmo> the all-merged-up stuff is imported from sid
<Kamion> ah
<Kamion> sorry, misinterpreted
<Kamion> grr. There's a delay between a module being loaded and the device node being visible, isn't there?
<Keybuk> elmo: see, now you have 203 files in the queue to get rid of as well as import my key <g>
<Keybuk> Kamion: yeah, but usually not a huge one
<Kamion> Keybuk: is it predictable in any way?
<Keybuk> no more than a second or two
<Kamion> I don't want to insert random sleeps, that sucks
<Keybuk> Kamion: no, it's basically just how long it takes for the stuff in /sys to appear
<Kamion> is there any way to say "wait until everything's synced"?
<Keybuk> hotplug is full of "wait for file to appear" checks
<Kamion> that's really crap
<Keybuk> for which?
<Keybuk> if you're doing a hotplug event, things will be synced at that point
<Keybuk> (aiui)
<Kamion> modprobe fbcon -> wait for /dev/fb/0 to show up
<Kamion> in a sane world you can expect it to be there from the point modprobe exits
<Kamion> it's not good for the installer to sit around thinking for ages, especially since depending on the system (e.g. serial consoles) /dev/fb/0 might never appear
<Keybuk> that'd mean it'd all have to happen in kernel space
<Kamion> I don't care how it's implemented :)
<Kamion> I just want a supposed upgrade not to be a regression
<Keybuk> wouldn't doing the modprobe populate something under /sys ?
<Kamion> immediately?
<Keybuk> no :p
<Kamion> also, sleeps are a totally obvious race condition
<Kamion> d-i runs on some very slow hardware
<Keybuk> the trouble is you're doing it backwards, really
<Kamion> oh?
<Keybuk> you're not supposed to load a module to find out if the hardware exists
<Keybuk> you're supposed to load the module once you know the hardware exists
<Kamion> is there a way to test for available framebuffer hardware, then?
<Kamion> reliably?
<Keybuk> (this obviously isn't quite finished yet, as things like ppp_generic/loop go phooey)
<Keybuk> well, the graphics card's pci id will map to the appropriate frame buffer
<Kamion> all I want, really, is a wait_for_everything_to_sync call
<Keybuk> radeonfb             0x00001002 0x00005961 ...
<Keybuk> for example
<Kamion> sounds a bit challenging to parse at this stage, but I guess
<Kamion> ah well, that will come later, sleep it is for now
<Kamion> thanks for guidance :)
<Keybuk> nite :)
<__daniel> sleep tight, kamion
<Kamion> sleep> i.e. /bin/sleep not bed
<Keybuk> oh, lol
<Keybuk> my brain saw "sleep" and thought "mmm... bed"
<__daniel> ;-)
<__daniel> me too
<Keybuk> dunno why, but I've been up at 5am every morning this week
* amu mv /dev/bed n8 
* Keybuk thinks he'll do the same in a minute
<Kamion> ROCK
<Kamion> udev/hotplug d-i works
<Kamion> though I haven't tried to strip out discover yet
<jdub> arh, no keybuk
<jdub> what's the best way for me to upload a modified/updated gdm?
<jdub> just grab the new release, apply changes and go?
<seb128> good luck
<seb128> I've tried once
<seb128> neuro has all his changes mixed in the diff.gz without any documentation
<jdub> yeah
<jdub> sucks
* jdub will attempt :)
<seb128> Np237 took a whole week to repackage it with cdbs last year
<jdub> i'm tempted to fork it ;)
<seb128> use Np237's work if you do this
<seb128> he made a good package using cdbs with all the patches splitted in debian/patches
<seb128> jdub: hum, we want glib/gtk 2.5 in hoary now, right ?
<jdub> sure!
<seb128> ok, that's a bit late now to start packaging them, but that's on my todo list for tomorrow :)
<seb128> jdub: if you want the gdm package made by Josselin you can find it in the pkg-gnome SVN (/packages/gdm)
#ubuntu-devel 2005-11-07
<schweeb> fabbione: that's what I figured
<bob2> haha
<schweeb> I'll just set up an unofficial repository
<schweeb> if I can figure out a good way to pkg it
<fabbione> schweeb: the problem is xen upstream. their stable release moves to slow
<fabbione> and it goes too fast out of sync with our kernels
<schweeb> yea
<Kamion> Akatemik: glad to hear it. what was the problem?
<Akatemik> Kamion: Some messup with initrd. Copied it over again from the release and it worked.
<Akatemik> Now I tried to make a minimalistic system beginning from just debootstrap instead of stripping the released livecd. Unfortunately the "installer" didn't like it and aborted.
<Akatemik> Also with an informative message like "filesystem isn't correct", quite hard to know what exactly it wants from it.
<Kamion> I think I need the exact message there in order to be able to help; paraphrased errors are hard to work with
<Kamion> IIRC it needs to be an ext2 filesystem compressed using create_compressed_fs from cloop-utils
<Akatemik> Kamion: I'll boot and check. And yes, it needs that. That's how I've been repacking the premade cloops.
<Akatemik> (This time I'll use english installer...)
<Akatemik> Kamion: "Enter preinstalled session: Installation step failed"
<Kamion> Akatemik: there should be more information in /var/log/syslog and/or /var/log/messages, hopefully
<mdke> is it possible for someone to stick up a notice at ubuntu.com explaining the problem and saying "we are working to resolve", or something?
<carstenh> hi
<carstenh> ajmitch: ping
<carstenh> ajmitch: unping ;) i did not see "Still Editing UDU spec.."
<ajmitch> carstenh: :)
<ajmitch> carstenh:I'm in a bug BOF at the moment
<ajmitch> will get back to writing
<mae> is selinux support expected to be in dapper -- and what about NetworkManager
<mae> :)
<carstenh> ajmitch: it does not hurry, i just wondered why there is i.e. still a laptop mode before i read that you are still working on it :)
<schweeb> mae: NetworkManager is already in Breezy... just not in main
<schweeb> and it works... I'm using it now
<mae> oh - it works well then?
<ajmitch> mae: selinux support will hopefully get in
<mae> nice
<ajmitch> but that support will be limited if it does get in
<ajmitch> not likely to have policies turned on by default :)
<mae> well i wanted it rather so i could lock down an apache installation easily
<mae> :)
<tseng> not likely to have policies installed or built
<mae> aww.
<tseng> rather in universe
<tseng> but hopefully not too many apt-gets and kernel command lines away
<YokoZar> There are still links to ubuntu.com/wiki
<ajmitch> yes, universe would be the most likely place to pland policy & probably admin tools, unless they're all in shape by feature freeze & can be supported in main for 5 years..
<mdke> YokoZar, where?
<ajmitch> s/pland/land/
<YokoZar> mdke: in the forums
<YokoZar> At the top
<mdke> YokoZar, ubuntu.com/wiki was never a valid address, afaicr
<mae> ajmitch: well selinux _would_ make sense to get in for the 5 year supported product :P
<mdke> ah ubuntulinux.org/wiki
<mdke> that is valid afaik
<mae> as security is fairly important if we want to compete as a server os
<mae> RHEL already has it.
<ajmitch> certainly, however it means getting everything in a known, supportable state
<mdke> YokoZar, the main website server is down right now so that is probably why the link doesn't work. But you can contact the forums if you want to give them the direct address (https://wiki.u.c)
<ajmitch> it's not something that can be quickly added to a distribution
<mdke> you've upset him ajmitch 
<mdke> <g>
<mae> did i miss the response? :P
<Riddell> no
<YokoZar> mdke: ahh ok
<ajmitch> heh
<mdke> corey_, ping?
<corey_> mdke, pong
<mdke> busy?
<corey_> nope
<mdke> quick chat about that wiki thing?
<sabdfl> jdub: https://wiki.ubuntu.com/CommunityCouncilAgenda could you link to that from the Fridge please?
<jdub> sabdfl: is there a story?
<jdub> WHAT'S MY MOTIVATION? i am a unique snowflake, serving coffee in hollywood.
<bob2> you are not a beautiful snowflake
<lifeless> hah!
<lifeless> he is most definately unique
<YokoZar> What do I do if I lost my password for the wiki?  It says to enter in email and then click a button that's not there...
<YokoZar> oh wait, I guess I have to do that at launchpad, not at the wiki
<sabdfl> jdub: doh
<sabdfl> https://wiki.ubuntu.com/GrantingMembership
<bob2> erk
<mdke> wasn't the point of having the CC do it ensuring that the CC and the wider community gets to know more about cool work being done around the place?
<bob2> membership is orthogonal to things like upload rights, yeah?
<lifeless> yah
<Loevborg> orthogonal in this context means impertinent?
<bob2> I'm hoping "unrelated"
<Loevborg> ok. I always wondered about that.
<YokoZar> orthogonal means at a 90 degree angle, duh
<YokoZar> ;)
<Loevborg> maybe this is compsci jargon, never heard it anywhere else with this meaning.
<bob2> geeks seem to use orthogonal in that sense
<jdong> totally out of curiousity, what's Ubuntu's status as far as LSB compliancy is concerned?
<bob2> I believe it's been tested with all 3 proprietary lsb-requiring applications
<Loevborg> but, I guess, this is completely orthogonal to #ubuntu-devel.
<jdub> pretty good, talk to jbailey 
<jdong> bob2: cool :). So our lsb-* packages provide a fairly LSB-compliant environment?
<jdong> minus the RPM alienage? ;)
<bob2> oh, I have no idea, I'm just joking because I've never seen anything care about lsb
<jdong> lol
<jdong> true enough; most commerical Linux apps are statically linked anyway, requiring ridiculously low common denominators :)
<tseng> apt-get install libstdc++5
<bob2> in your pants
<tseng> the irony, i just sent a mail to jeff about my pants
<jdong> also, are there any ready-in-a-box frontends to monitoring a router box?
<jdong> like the interface that IPCop/Smoothwall provides
<tseng> cacti
<tseng> or mrtg for a single host
<jdong> so that monitors traffic and load.... what about active connections? Any cool table parser?
<tseng> cacti can do nearly anything
<tseng> mrtg wants to do traffic in and out
<jdong> IPCop can show a color-coded table of connections... can cacti do something similar?
<tseng> you have to fight it to do more
<tseng> this is getting off the mark, though
<tseng> msg me
<jdong> I know, sorry... abusing the room....
<tseng> i happen to write this kind of software for a living :)
<tseng> i know whats around
<YokoZar> Is it possible to remove a package from breezy universe?
<Riddell> YokoZar: yes
<YokoZar> I mean, from the repository
<bob2> what's the reason?
<Riddell> YokoZar: https://wiki.ubuntu.com/MorgueCandidates
<YokoZar> Riddell: added it there already :)
<LaserJock> Riddell: is MorgueCandidates even being used?
<YokoZar> bob2: It does literally nothing and conflicts with the package that it's supposed to help.
<bob2> I wouldn't think that was a good enough reason
<YokoZar> Specifically, I'm talking about winesetuptk and xwine and libwine-cil, which are used by nothing and don't work with the wine package in universe
<Riddell> LaserJock: no idea
<YokoZar> We talked about removing them on the mailing list a couple of months ago, but that slipped by release time :(
<LaserJock> Riddell: http://morgue.ubuntu.com/ hasn't been updated since July
<YokoZar> And those july folders are empty
<LaserJock> That's my point
<LaserJock> I don't know if anything is being done there
<YokoZar> Is morguecandidates the procedure for removing packages?
<YokoZar> More importantly, the packages confuse users trying to install Wine
<YokoZar> I don't see what good keeping them around does
<LaserJock> YokoZar: I see that but I guess the question is how do we get rid of them and when
<LaserJock> I don't think that morgue.ubuntu.com is the way to go but maybe I'm wrong
<YokoZar> Perhaps I'll write an email to the list
<LaserJock> And I doubt that it would be taken out of Breezy
<YokoZar> Get Matt's opinion on it
<Riddell> YokoZar: elmo is incharge of removing stuff, he will take requests from trusted MOTUs
<YokoZar> Riddell: can he do it from Breezy?
<Riddell> YokoZar: no, breezy is released
<YokoZar> ok then, I'll talk to him
<Alinux> #ubuntu-devel
<Alinux> hello, I'm interested to translate,ubuntu text installer...what's templates or packages exact name ?
<tseng> Alinux: debian-installer should be
<Alinux> is it the same for ubuntu?
<Alinux> I see there is no georgian version...so I'd like to translate it.
<Kamion> LaserJock: morgue.ubuntu.com is dead for (AIUI) disk space reasons; but if people didn't insist on using the word "morgue" instead of what they actually mean, i.e. "remove", this would be less of a problem ;)
<LaserJock> Kamion: makes sense, what is the current procedure for getting a package removed then, email elmo?
<Kamion> LaserJock: right, but if it's not going to be necessarily obvious to somebody unfamiliar with the package in question then discuss it in a wider forum first
<LaserJock> Kamion: Ok, that's cool. I just wondered what we wanted to tell people. I hate having to say "Sorry, can't help. Go bug somebody else." ;-)
<YokoZar> Thanks
<YokoZar> I'll send a mail to the list then
<zakame> hi all
<Kinnison> corey_: come downstairs once you've voided your bowels
<corey_> Kinnison, coming
<Kinnison> corey_: eww
<Kinnison> corey_: that's cream for your number 2
<bob2> who designed the default xscreensaver/planet ubuntu user icon?
<bob2> it's like an evil little lego dude
<daniels> i blame jwz
<tritium> that goatee is surely not a unix beard
<LaserJock> tritium: he does look a little too groomed doesn't he ;-)
<infinity> He kinda looks like me.
<bob2> oops, I meant planet \sh
<bob2> \sh_away: also, I get random bright white dots scattered over my xterms
<tritium> LaserJock, heh
<YokoZar> Is there a way for an application invoked with sudo to know the user that invoked it?
<YokoZar> Other than root, that is - the sudoer?
<shawarma> YokoZar: Not really the right channel, but yes, the SUDO_USER environment variable.
<YokoZar> I was just wondering because I was wanted to know if there was a way for the browse button in the system->administration->disks program to NOT open nautilus windows with root permissions
<YokoZar> In fact, that might be a pretty serious bug
<shawarma> I'm quite sure it's been discussed before. I don't remember the outcome of the discussion, though.
<robitaille> http://bugzilla.ubuntu.com/show_bug.cgi?id=17049
<robitaille> i.e, the bug is still open
<YokoZar> indeed.  Wiki entry added to Usability wishlist.
<poningru> can someone tell me about some docs on the opencd?
<pef> hello
* zyga says morning
<LaserJock> exit
<lbm> just took a peak on the ubz galleries around the web, those ubuntu laptop stickers look really neat!
<lbm> are these for sale somewhere? :)
<highvoltage> hi, is it safe to dist-upgrade from warty to breezy? or should i dist-upgrade warty -> hoary -> breezy?
<dooglus> negative press: http://software.newsforge.com/article.pl?sid=05/11/01/157225
<crimsun> frankly off-topic, but it's not negative so much as "Guest" is misinformed
<dooglus> he is?  i'm just uninformed, me.
<zyga> dooglus: launchpad will be FOSS once it's good enough
<kent> highvoltage, this is not the supportchannel. Try #ubuntu for that.
<zyga> anyone around hacks gdm?
<nailbiter> Is there an Ubuntu developer mentoring program? I'd like to sign up as a mentee. :)
<crimsun> no, we don't mentor per se. See #ubuntu-motu
<nailbiter> crimsun: Thanks. :)
<LaschW> is there a roadmap for ubuntu server, precisely out of the box services like ldap as RH and SUSE already have?
<dholbach> mcpp wil have to be promoted to main for xrdb (build-depends)
<pef> elmo: hello, can you confirm I'm whitelisted for uploads ?
<jordi> little daniel has a little laptop
<daniels> yes, but mine's in english, not spanish
<Lathiat> daniels: did i mention that mesa update fixed all my problems?
<HiddenWolf> Lathiat, /all/ your problems? ;)
<Lathiat> all my mesa related problems ;)
<daniels> Lathiat: which mesa problems were you having?
<Lathiat> nvidia gl not workign on my laptop, and a missing symbol while tryign to compile some screensaver
<Lathiat> i mean my glxgears fps is higher, that means its fixed right? ;)
<daniels> Keybuk: so what's going on with mom?
<Lathiat> hrm jus tupgraded to dapper and nothing broke
<Lathiat> boring :)
<slomo_> is there a reason why ubuntu.com shows the bazaar page and www.ubuntu.com shows the correct ubuntu page? ;)
<mdke> slomo_, they're still working on the website afaik
<Burgundavia> slomo_, a bug due to the ubuntu website going down
<mdke> <g>
<slomo_> ok, thanks
<tseng> pitti: can you please review xsp inclusion report?
<tseng> pitti: it is blocking progress for the time being
<pitti> tseng: no main inclusion reports in this week, sorry; we are at UBZ
<tseng> ok, thanks pitti 
<HiddenWolf> jdub, ping
<jdub> HiddenWolf: wong
<jdub> HiddenWolf: pong
<HiddenWolf> jdub, who is the leader of the accessibility team?
<jdub> HiddenWolf: of which project?
<HiddenWolf> jdub, https://wiki.ubuntu.com/AccessibilityTeam
<jdub> HiddenWolf: ostensibly henrik
<HiddenWolf> jdub, hmm
<HiddenWolf> jdub, cool, thanks.
<zyga> hello dapper lovers
<zyga> sshd does not bind to any port after default install
<zyga> the process just sits there doing nothing usefull
<zyga> I'm using default config
<Kamion> zyga: anything in /var/log/auth.log?
<Kamion> I must admit I didn't test the most recent openssh/dapper upload much, I just merged it with Debian
<Kamion> it works fine in Debian, but there's that openssl transition in progress ...
<zyga> Kamion: checking
<zyga> nothing, I'll rotate logs and install from scratch to be sure 
<zyga> one sec
<Kamion> check /var/log/syslog and maybe /var/log/daemon.log too
<zyga> syslog didn't have anything speciall 
<Kamion> default sshd_config?
<zyga> actually it did but not related to the issue
<zyga> yes, default
<zyga> checking daemon
<zyga> nothing 
<Kamion> failing that you probably have to 'strace -f' sshd startup to see what it's doing
<zyga> right
<Kamion> could be there's a stray process bound to port 22 (or one that was bound to port 22 less than whatever the timeout was ago) and it's getting confused
<zyga> Kamion: according to netstat nothing is bound to :22
<Kamion> anyway, we're off-topic for #ubuntu-devel, file a bug if you can't track it down
<zyga> right
<zyga> if I find the issue I'll tell about it anyway
* dredg wonders if there are any docs for setting up your own popularity-contest on a local server
<zyga> root@falcon:/var/log# sshd
<zyga> sshd re-exec requires execution with an absolute path
<zyga> any clue on how to run this manually?
<ompaul> zyga, that is what #ubuntu will help you with
<zyga> ompaul: true, solved already anyway
<Amaranth> all those people dying the same way in a matter of 5 minutes
<Amaranth> did the net connection drop in their part of montreal? :P
<\sh> Amaranth: if you leave the hotspot of the ubuntu wlan..u lose the connection..which is quite normal
<\sh> Amaranth: and the ubuntu wlan is in S1 and most of the guys are now on level 2 to have lunch
<Amaranth> ah
<Amaranth> they should /quit first
<\sh> Amaranth: why?
<Amaranth> \sh: it makes it look like something bad happened having them all just drop like that :)
<\sh> Amaranth: don't worry...
<zyga> wow
<zyga> ubuntu gnu/solaris?!? :-))
<HiddenWolf> zyga, no, debian/gnusolaris. :)
<Mithrandir> it's probably not redistributable, though
<zyga> ./ story claims ubuntu is participating
<zyga> which is great BTW :-)
<tseng> yes
<tseng> because they sent us an email
<zyga> what about gnu/hurd ;-)
<tseng> we probably got an email from then too
<Amaranth> some /.er saw the email on ubuntu-devel and submitted the story thinking it came from someone official
<zyga> awww :)
<Amaranth> i should send an email to ubuntu-devel saying Microsoft plans to work on an Ubuntu derivitive called Windotu
<tseng> "Special thanks to the Ubuntu developers! Ubuntu is a state-of-the-art distribution!"
<HiddenWolf> s/distribution/rippable product
<HiddenWolf> :P
<tseng> anyway, nothing to see here
<zyga> hmm
* HiddenWolf grins
<tseng> back to your reguarly schedule #ubuntu-devel
<HiddenWolf> windotu. ;)
<zyga> there are some syntax errors in default server breezy install?
<zyga> prep-menu has a syntax error 
<Kamion> zyga: because obviously we never test any installations at all :P
<Mithrandir> tests are for wussies
<zyga> Kamion: very funny
<ompaul> sudo apt-get install new_ethos_if_it_was_hard_to_write_it_should_be_hard_to_run
<Mithrandir> ompaul: if that was the case, it'd be impossible to run.
<ompaul> Mithrandir, :)
<daniels> Keybuk: mergeomatic for dbus plskthxx
<Keybuk> daniels: do it yourself
<daniels> Keybuk: doing it by hand is a pain in the arse.  what happened to mom?
<Amaranth> she died
<daniels> :'(
<Keybuk> daniels: nothing, if the package in ongoing-merge isn't what you were expecting, you need to do it yourself?
* Keybuk is confused
<daniels> Keybuk: hasn't been updated since april
<Keybuk> daniels: that most likely means it's a snapshot-fuck package
<Amaranth> wtf does that mean?
<daniels> i second that
<Keybuk> snapshot.debian.net melted its disk array
<daniels> ah
<daniels> yeah
<daniels> fuck
<Keybuk> either that, or it's not "needs merged" in katie
<Keybuk> hmm
<Keybuk>  * Processing dbus
<Keybuk>    - unstable: 0.23.4-1
<Keybuk>    - main: 0.23.4-0ubuntu3
<Keybuk>  * Downloading http://snapshot.debian.net/archive/pool/d/dbus/source/Sources.gz
<Keybuk>    - base: 0.23.2-3
<Keybuk> W: Not changed since last run: dbus
<tseng> hm that is an ass old version
<daniels> oh
<daniels> sync from experimental? :)
<dooglus> hi guys.  I have a question...  shortly before breezy was released there was a development breezy kernel which booted to a black screen until gdm started up if I used "vga=773" in my lilo stanza.  the official breezy kernel fixed this.  but now, if I build my own kernel from breezy kernel sources, the problem comes back.  why?
<Keybuk> it doesn't sync from experimental
<dooglus> I'm wanting to build a 'win4lin' patched breezy kernel
<daniels> hence my question
<dooglus> I guess if I could find out what changed in the kernel just before breezy was released, I could find the answer I'm looking for.
<tseng> dooglus: you want #ubuntu, there is unfortunately no support here
<dooglus> tseng: oh dear.  there's no support there either for this kind of thing :(
<Keybuk> http://snapshot.debian.net/2005/03/02/debian/pool/main/d/dbus
<mdke> dooglus, there must be some support somewhere!
<Keybuk> ^ 404
<dooglus> mdke: that's what I was hoping
<Keybuk> so it's both no newer version in Debian AND snapshot doesn't have the base
<daniels> Keybuk: right, but right now we're working against experimental's 0.50-1, and breezy's 0.36.2-0ubuntu8
<Keybuk> do it by hand
<Keybuk> mom only reacts to a change in Debian, I can't remember why now though
<daniels> hrm
<Keybuk> oh, no, I did fix that
<Keybuk> I think
<Keybuk> yes, I did
<Keybuk>  * Processing dbus
<Keybuk>    - unstable: 0.23.4-7
<Keybuk>    - main: 0.36.2-0ubuntu7
<Keybuk>  * Downloading http://snapshot.debian.net/archive/pool/d/dbus/source/Sources.gz
<Keybuk>    - base: 0.36.1-1
<Keybuk> W: Debian behind our base version, skipping: dbus (0.36.1-1 > 0.23.4-7)
* daniels stares at Mez.
<Mez> what have i done now ?
<daniels> why on earth were you merging discover?
<Mez> I was jst looking through the things that are there in bugzilla
<daniels> ah, okay
<ogra> highvoltage, ping ?
* dilinger installs breezy on his brand new x40
<daniels> dilinger: woo!
<dilinger> daniels: how's UBZ going?
<daniels> tired
<dilinger> of course
<dilinger> it's an ubuntu conference :)
<daniels> indeed
<wasabi_> Small gdb question, got a break point set, and it tells me it hits it, but the program keeps running.
<wasabi_> I want it to stop.
<dilinger> neat, suspend even works
<BenC> dilinger: be bold, use one of my 2.6.14 kernels :)
<daniels> dilinger: *everything* works, except the sd card reader
<dilinger> daniels: hibernate doesn't appear to be working
<dilinger> or ,if it is, it's *really* slow
<daniels> dilinger: wfm
<bob2> wfm, and 5 jillion times faster than on hoary
<dilinger> BenC: heh, i just installed it, don't want to break it just yet *g*
<dilinger> BenC: you didn't bychance disable these awful looking timestamps in kernel logs, did'ja? :)
<BenC> those are actually useful, for me atleast
<BenC> helps me when I'm reading dmesg from bug reports
<dilinger> yea, i figured
<dilinger> but for users and for console output, they're awful
<dilinger> i think this is stuck
<dilinger> meh
<BenC> it's probably doing the hibernate, but not shutting off the system
<Mez> dillinger - I et the same thing
<dilinger> BenC: it's when it's coming back up that it was hanging
<dilinger> it gave a "swsusp: copying X pages ..." line andn then stopped
<dilinger> i just rebooted it forcefullly
<dilinger> i'll play around w/ 2.6.14 later
<bob2> ipw2200?
<dilinger> BenC: it'll work w/ breezy, right?  or will i need to run dapper?
<dilinger> bob2: ipw2200 was active
<dilinger> and associated
<bob2> did you run /etc/acpi/hibernate.sh?
<dilinger> actually, i should probably work on sx8.c before i go and break my laptop :)
<dilinger> bob2: i clicked on "hibernate" in the gnome shutdown menu
<tsume> *shrug*
* tsume has a NVIDIA and ipw2200
<bob2> dilinger: hm
* tsume never uses hibernate. Grub also doesn't work on this laptop :P
<dilinger> i can't tell you how nice it is to install linux on a laptop and have everything (right down to X and wireless) Just Work
<tsume> dilinger: its wonderful sure.. except hibernate :)
<dilinger> that has never happened to me before.  most of the time i have to fight for ages to get some aspect of the thing working
#ubuntu-devel 2005-11-08
<tsume> dilinger: netbsd gained centrino support.. I had it installed.. you wouldn't believe what I ran in to..
<tsume> dilinger: I ran in to the centrino keyboard/touchpad ps rate problem :
<tsume> )
<zyga> hello
<tsume> dilinger: ubuntu is really magicaly :) it senses the stupid toshiba based touchpad and fixes the psrate though :)
<zyga> what to do with packages that have totally broken .po and .pot files?
<zyga> like totally out-of-date and broken/inexisting .po/pot build system
<Erlang> ah...
<Erlang> Seems like a more suitable place for my question.
<Erlang> Is there a way to create a pbuilder-chroot to build ubuntu packages on Debian?  I can't seem to find that anywhere despite reading that it is possible.
<zyga> Erlang: check the wiki PbuilderHowto (case might vary)
<mdke> Erlang, did you try https://wiki.ubuntu.com/DeveloperResources
<mdke> not sure if it will help
<zyga> carlos_: hello
<Erlang> The only page I found on the wiki for that tells how to make a pbuilder-chroot for Ubuntu on Ubuntu.
<carlos> zyga, hi
<Erlang> The thing is that the Debian pbuilder doesn't support 'breezy' as a distribution, for example...
<zyga> carlos: what to do when a package has totally broken build system and outdated .pot and .po files?
<zyga> Erlang: read that wiki
<mdke> zyga, file a bug? submit a patch?
<carlos> zyga, what to do about what?
<carlos> zyga, I mean, I need more context
<Erlang> zyga: I've read PbuilderHowto.  It explains well the Ubuntu-pbuilder on Ubuntu case, but doesn't solve the "on Debian" part of my problem.
<zyga> carlos: contact upstream/fix whatever?
<zyga> Erlang: ah
<carlos> zyga, usually, fix it for Ubuntu and also contact upstream
<carlos> as soon as it's fixed for ubuntu, Rosetta will get the fixed data
<zyga> carlos: I'm not sure how to fix it though, that's a 100% python app, it uses some automagic and has a strange directory layout
<zyga> carlos: it has unusual makefiles too
<carlos> zyga, then ask for help to other Ubuntu developer or talk directly with upstream
<zyga> okay
<zyga> I'll ask mvo as soon as he's around, he seems to know python packaging well
<zyga> the package in question is gramps, really nice software
<Kamion> Erlang: very current debootstrap in Debian handles breezy, so it should be at most a trivial pbuilder hack to support breezy
<Kamion> like a pbuilder.conf change or something, and point it at http://archive.ubuntu.com/ubuntu/
<Erlang> Kamion: I was noticing the exact same thing just as you wrote this.  I saw the only diff between Ubuntu pbuilder and Debian pbuilder is that the former defaults to debootstrap...
<Kamion> yeah, you want to use debootstrap for Ubuntu, cdebootstrap doesn't support Ubuntu even *in* Ubuntu
<Erlang> yay!
<Erlang> Thank you.  I just upgraded my debootstrap and it works.
<Kamion> cool, good stuff
<Erlang> building breezy chroot right as we speak.  Thank you.
<mdke> i'm still getting errors downloading security universe, http://pastebin.com/415472
<mdke> any ideas? occasionally it goes away, but the general rule is that it doesn't work :/
<pitti> jordi: can you please update the spec status? we don't need any discussion any more (PendingReview)
<pitti> seb128: ping
<seb128> pitti: pong
<pitti> seb128: " If totem-gstreamer (built against 0.9) does not satisfy the requirements above, we will switch to totem-xine"
<pitti> seb128: surely that is 0.10?
<seb128> pitti: yeah 0.9 atm will be 0.10 in decembre
<pitti> seb128: or do you specifically want to test it with the current version?
<seb128> no, I used 0.9/0.10 for the same thing
<pitti> seb128: what are "the requirements above"?
<seb128> good question
<seb128> pitti: I can update that to "doesn't work well enough" if you want
<pitti> that sounds better, yes
<pitti> please also s/0.9/0.10/
<pitti> otherwise you would not need this condition
<seb128> pitti: updated
<pitti> seb128: "not well enough" is pretty handwavy...
<seb128> pitti: do you have an idea of less handwavy criterious?
<pitti> seb128: a list of supported formats would be nice
<pitti> seb128: like "encrypted DVDs, MPEG-2, MPEG-4, ogg, etc."
<seb128> "This topic is not related to support for particular codecs, but to the general infrastructure needed to support all kinds of video playback."
<pitti> right
<seb128> from Introduction
<pitti> but if a spec contains a conditions, it must be clearly defined
<seb128> the issue we have a like a/v sync issue
<pitti> seb128: what about this:
<pitti> seb128: "if t-g does not support the same features/codes like -xine..."
<seb128> the issue is not the feature, it does
<seb128> that's how laggy it is, how good the a/v sync is
<seb128> pretty handwavy stuff :)
<seb128> that pretty the feeling you have while playing some files rather than some fixed points imho
<pitti> ok
<pitti> is there a separate spec about codecs then?
<seb128> no, should we?
<pitti> I think it's the lack of codeds that matters a lot
<seb128> jdub: thoughs?
<pitti> I was never able to playback the majority of my videos with gstreamer so far
<seb128> yeah, thanks patents
<seb128> ffmpeg, quicktime, ...
<jdub> no, the point of the spec is to have good playback of theora/vorbis at a minimum
<jdub> the codec issue would be another spec
<pitti> ok
<pitti> seb128: "well enough in terms of a/v synchronisation"
<seb128> pitti: let me change it again and ping you back
<pitti> seb128: or just "does not have a reasonable a/v sync"
<pitti> if that's what you actually care about
<seb128> pitti: what about
<seb128>  * If totem-gstreamer (built against 0.10) doesn't plays vorbis/theora files correctly (with no lag and good a/v sync) we will switch to totem-xine
<seb128> s/good/a good/
<jdub> seb128: "at least vorbis/theora"
<seb128> jdub: right
<seb128> pitti: updated
<pitti> seb128: doesn't s/plays/play/ :-) 
<pitti> seb128: but it sounds much better now, thanks
<pitti> seb128: same issue on the next line?
<pitti> seb128: i. e. if a/v sync in 0.10 is unreasonable, switch back to 0.8?
<seb128> pitti: no, I should drop the other line in fact
<seb128> pitti: updated
<ogra> mdz, https://launchpad.net/distros/ubuntu/+spec/thin-client-memory-usage
<seb128> pitti: the second line didn't make sense, the spec if for the video player, not the desktop. And GNOME 2.14 is going to use gstreamer0.10 anyway, so we are not going to patch all the desktop to use and outdated version
<pitti> seb128: makes sense
<mdz> ogra: don't forget to add new specs to UBZ (I did it for you on that one)
<pitti> seb128: approved, congrats :-)
<seb128> pitti: thanks!
<ogra> mdz, thanks...
<seb128> jdub: should I ask to have https://launchpad.net/distros/ubuntu/+spec/extra-desktop-planning pushed so we get a slot on the schedule for it?
<jdub> seb128: mark's doing that
<seb128> fine with me :)
<seb128> jdub: maybe you should subscribe to https://launchpad.net/distros/ubuntu/+spec/gdm-roadmap so if it gets scheduled again they will put you on the slot
<jdub> seb128: ok
<Lord_Maynoth> anyone home?
<mpt> Lord_Maynoth, usual IRC rules apply: Ask meaningful questions, and don't ask to ask :-)
<Lord_Maynoth> it just seemed dead
<Lord_Maynoth> I was wondering
<mpt> Many of the developers are at UBZ and have gone out for dinner right now
<Lord_Maynoth> does anyone here know if dapper will autodetect your windows partitions and name them something meaningful like C:, D: etc?
<Lord_Maynoth> (yes I am aware there is a script)
<Lord_Maynoth> I am just curious
<sladen> Lord_Maynoth: detect, yes.  autoname, no
<Lord_Maynoth> so dapper will detect my drives without me having to run a script?
<sladen> Lord_Maynoth: during the installer, you can decide where to mount them.  Eg.  /media/c
<sladen> Lord_Maynoth: the answer to the question I think you might be trying to ask is probably "no"
<Lord_Maynoth> so after i install dapper I will have to download that script and run it like I do in breezy in order to autodetect my drives?
<Lord_Maynoth> or will that be done in the install process without me having to download and run the script?
<predius_> hey, anyone here who was involved in the live-cd creation?
<Riddell> mako: are you coming to the conference?
<MicahC> I have a difficult question concerning ubuntu, I have an idea of how to make win32 codecs easier to install.
<MicahC> I built a little python script to copy the correct from the Windows CD that the user owns.
<MicahC> My thought is that for people who aren't very computer literate it would be easier for them to get the codecs using a 'Wizard'.
<MicahC> It would download updated version of the codecs from the MS website in a 20MB download.
<MicahC> I really just have one question, is me doing this worth the effort?
<MicahC> I think it could make the distribution of media codecs a little less nefarious that it is today.
<mako> Riddell: nope, i'm not going ot make it this time
<mako> i
<MicahC> Where would be the best place to ask this question, if not here?
<mako> Riddell: i really wanted to come for the most recent weekend but could not
<mako> and i don't feel like i'd have a lot to contribute to the LP stuff
<predius_> MicahC: wait for an answer.
<predius_> people will check back later, probably.
<Lord_Maynoth_> anyone here know if dapper drake will automatically detect and set up your windows partitions without having to download a script of the internet?
<predius_> Lord_Maynoth_: What do you mean?
<Lord_Maynoth_> well in breezy you can have your drives autodetected and set up
<Lord_Maynoth_> but you have to download and run a script to do it
<predius_> ah, in the fstab?
<predius_> automounte?
<predius_> *mounted
<LaserJock> azeem: ping?
<Lord_Maynoth_> I think you should just install and your windows partitions are allready set up and accessable without having to download and run a script
<Lord_Maynoth_> etc
<tepsipakki> kamion: pxelinux 3.20 (-pre3 now) includes support for menus and password authentication.. maybe that will be used for dapper?-)
<tepsipakki> when 3.20final is released
<tepsipakki> I just tested it and works fine, installing breezy atm
<mantiena> Kamion_, hi
<zakame> hi all\
<mantiena> hi zakame 
<zakame> what's up?
<mantiena> zakame, hehe, lots up ;)
<zakame> hehe
<mantiena> whats down ? :)
<zakame> nothing much
<mantiena> why OOo 2.0 final is not in dapper ?
<zakame> prolly still in experimental
<mantiena> zakame, could you tell em URL ?
<green-mouse> hi were i can report about broken dependence?
<hunger> green-mouse: The bugtracker.
<hunger> green-mouse: Hi;-)
<green-mouse> hunger: :) bugzilla.ubuntu.com ?
<hunger> green-mouse: IIRC that is the one for breezy. Dapper bugs should go into launchpad.ubuntu.com I think.
<hunger> green-mouse: I am no developer though, so I hope I am not wrong.
<green-mouse> hunger: thank you
<maswan> 10 minute outage on se.{releases,archive} tonight, emergency security upgrade to campus routers
<Znarl> maswan : Noted
<pef> elmo: ping
<Kamion_> tepsipakki: I expect we'll be using syslinux 3.*, yes; exactly what version remains to be seen
* Mithrandir ruffles Simira 
<zyga> any glibc devels/maintainers around?
<Robot101> Diziet|ubz: why is libadns gpl and not lgpl? :(
<\sh> infinity: can u give back python-kde3 again? looks like that it was too fast somehow...compiles on my dapper pbuilder quite fine
<Diziet|ubz> robot101: GPL> You've read http://www.gnu.org/licenses/why-not-lgpl.html, right ?
<Keybuk> jbailey: http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=commit;h=c895fd002763d6ae808e820020dc54e74c347fc2
<Amaranth> GPLing library is just asking people to not take you seriously
<Amaranth> err, libraries
<Diziet|ubz> amaranth: ???
<Diziet|ubz> Anyway, I don't care if they take me seriously :-).
<Robot101> Diziet|ubz: it prevents us from using it in code which is also LGPL but is being funded by Nokia
<Diziet|ubz> LGPL and GPL are compatible.  What's the problem ?
<Diziet|ubz> Or is the problem that Nokia want to use the code they're funding also in their proprietary products ?
<Robot101> they can't extend the resulting thing with proprietary code
<Diziet|ubz> So Nokia can't take my code and freeload with it.  I don't see the problem.
<tseng> the second.
<Kamion_> Amaranth: that's demonstrably untrue; see libreadline
<Diziet|ubz> If you're serious about wanting to do this, have someone from Nokia contact me with a _serious_ offer.
<Robot101> that's not really their motivation, they want the whole thing to be free, but parts are patented and they would not be able to make any free software
<Diziet|ubz> Patented by Nokia ?
<Robot101> not necessarily, but some stuff is
<Diziet|ubz> So Nokia could solve this patent problem by using their muscle, if they cared.
<Amaranth> Kamion: Exactly, no closed-source app can use libreadline.
<Kamion> Amaranth: that's the desired effect
<Robot101> whether or not it's their patent that the legal department refuses to allow to be used in gpl code, or someone else's patent they can't be seen to use in free code, or must license
<Robot101> it's the same outcome - in order to have the functionality, they need a bit of closed code
<Robot101> they'd rather this was an add-on to an application that was otherwise free
<Diziet|ubz> `The legal department refuses' is a way of saying `we don't want to'.
<Kamion> Amaranth: the point of GPLing libreadline is to arrange that free software has better command-line completion than non-free software - which is visibly generally the case
<jbailey> Keybuk: Err.  This means all the rules *have* to move into the initramfs?
<Robot101> the people we're dealing with do, but it's a large company and the ~200 people who understand free software are outnumbered by the legal team I'm sure
<Keybuk> jbailey: I'm not sure, I'm just reviewing the implications of it
<Diziet|ubz> Anyway, I'm very serious.  If Nokia actually want to negotiate then I could be paid off.
<Kamion> jbailey: looks like we could udevcontrol reload_rules after mounting the real root?
<Diziet|ubz> If they don't want to pay, _and_ they don't want to share, then they're just freeloading.
<Robot101> the specific instance we're looking at is the best free SIP library in existence, which has been LGPL'd by Nokia already
<Keybuk> there's some inotify glue in there too ... not sure what that's holding
<Robot101> it contains their own implementation of asynchronous DNS resolution
<jbailey> Kamion: Right, but I'm wondering what that will mean during the transition to userspace.  We may need to have another "settle down" time after we chain to the real root where we stop listening to events, reload the ruls and continue.
<jbailey> A bit annoying.
<Kamion> mm
<Robot101> it'd be better if it didn't have to, but if we make it use libadns it's no longer usable inside a process that contains proprietary code
<Diziet|ubz> robot101: So they already reimplemented ?  A bit late for this conversation isn't it ?
<Diziet|ubz> robot101: Indeed so.
<Kamion> jbailey: will inotify notice the change in rules.d if that change is caused by overmounting the new root? I'm guessing not
<Robot101> the decision to release this code came after it was written
<Diziet|ubz> (Is their reimplementation bad enough that they want rid of it?)
<Keybuk> Robot101: this to me seems to be a feature; Nokia don't want to give us some of their code, why should we go out of our way to give them ours?
<Robot101> it wasn't written for Linux in the first place either
<pitti> Kamion: I'd just upload a version bump of openssl now, unless you want to merge the package today?
<Diziet|ubz> robot101: I think my licence is doing what it's supposed to :-).
<Kamion> pitti: please go ahead if you've got it handy
<pitti> Kamion: yes, I'm on it
<Kamion> thanks
<Kamion> I should go round and do the rest
<Robot101> Diziet|ubz: I don't. Nokia have given us a large amount of useful code (sofia-sip) which it would be better for us (the free software community) if it would make better use of the stuff we have (libadns) but that would make it less useful for Nokia because of the libadns license.
<Diziet|ubz> robot101: You could arrange for it to be able to use adns instead.
<Diziet|ubz> I assume the adns interface and the Nokia homegrown thing aren't so different in style that you can't do that sensibly.
<pitti> Mez: just uploaded an openssl quickfix; sorry for the delay
<Robot101> we don't have time, but NRC realise the importance of integrating with existing code, but they won't spend time on it if it's a seperate codepath they can't necessarily use later in their own stuff.
<Robot101> if libadns was LGPL, they would likely do the work and all the free users of sofia would benefit. and there should be a lot of them, because it's a very good library...
<Keybuk> make sofia GPL
<Keybuk> easy
<Robot101> no, nokia still need to be able to use it for themselves.
<Keybuk> *shrug*
<Keybuk> sounds like they're not playing ball then
<Keybuk> so no point getting dressed for the game
<Keybuk> free software ain't a one-way street
<Robot101> how? they've given the community the most complete SIP implementation in existence, and the only good one that's sensibly licensed (versus stuff like the vovida license or whatever it is)
<daniels> holy shit is this ever offtopic for #ubuntu-devel
* daniels smacks Robot101, Diziet, and Keybuk.
<Robot101> complete free SIP implementation, rather
<Keybuk> users can use their LGPL library with the GPL adns?
<Keybuk> they're compatible licences
<Keybuk> so free software benefit
<Keybuk> it just means Nokia can't use adns internally with the stuff they refuse to give us
<Keybuk> which seems fine to me
<Robot101> s/refuse/aren't able/, nokia's own patents don't cover the internals of the SIP protocol
<Mez> pitti: ty
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* Robot101 runs off
<Diziet|ubz> robot101: daniels is right.  If you want to talk to me about money, or even want to try to convince me more, talk to me somewhere else.
* mode/#ubuntu-devel [-o daniels]  by ChanServ
<Amaranth> Beware the daniels
<Robot101> given we don't have the time to make this change, and NRC aren't likely to either, it's totally academic at the moment. 
<Keybuk> oh, good
<Yagisan> Does Ubuntu have any marketing material I can use to show customers that Ubuntu can be an alternative to Windows ?
<HiddenWolf> Yagisan, ask #ubuntu, and check the wiki, there are some presentations and there are doc and marketing teams.
<Burgundavia> Yagisan, probably the most developed on the features and benefits is the quicktour
<Yagisan> HiddenWolf: Was checking the ubuntu.com site and didn't see obvious marketing material
<HiddenWolf> Yagisan, https://wiki.ubuntu.com/RecentChanges?action=fullsearch&context=180&value=marketing&titlesearch=Titles
<Yagisan> HiddenWolf, Burgundavia: Thank you, I was looking in the wrong place it seems
<pitti> Riddell: what was the name of the "I need root privs" field in .desktop again?
<Riddell> pitti: X-KDE-SubstituteUID=true
<Riddell> X-KDE-RootOnly=true
<pitti> Riddell: so which one?
<pitti> Riddell: having two fields does not make too much sense
<Riddell> pitti: use the first
<ivoks> pitti: ping :)
<pitti> Hi ivoks 
<ivoks> pitti: i have some errors with ubuntu-devel
<ivoks> pitti: but it's MTA related
<ivoks> pitti: i allways get two copies of same mail
<Riddell> pitti: also X-KDE-Username=foo to set the user id (root is default)
<ivoks> pitti: it looks like one mail server doubles it... and sends on same email address
<pitti> ivoks: no idea - can you please mail ubuntu-devel-owner?
<pitti> ivoks: please check that you aren't subscribed twice
<ivoks> pitti: i did, but that's not he's fault
<ivoks> pitti: i'm not...
<ivoks> pitti: sec, i'll give you more details
<pitti> EBUSY
<ivoks> ok
<ivoks> ups... it was my fault :) sorry for noise
<pitti> carstenh: ping
<carstenh> pitti: pong
<pitti> carstenh: there are some questions in the firewall wiki now (marked with 'XXX')
<pitti> carstenh: could you please take a look at them?
<carstenh> pitti: sure, not now but in about two hours. i hope that is ok
<pitti> yes, that's fine
<pitti> thanks
<carstenh> you're welcome :)
<ajmitch> pitti: have you saved that wiki page?
<pitti> ajmitch: "saved"?
<carstenh> it is still online
<ajmitch> saved changes, since I don't see any changes made?
<pitti> hmm?
<carstenh> XXX: adi: implies that each pa... that were the last changes
<ajmitch> or were you looking at SoC-Firewall?
<carstenh> yes
<jsgotangco> later
<Kinnison> Kamion: ping?
<hyperactivecrond> i've got an idea... we should create a version of ubuntu (probably just a livecd) geared for the teen generation... most teens in developed countries either use ms or apple products... 
<magnon> what, naked people on the desktop isn't enough?
<hyperactivecrond> :P magnon
<magnon> and teen girls love gaim
<hyperactivecrond> we could possibly by default include gtkpod or amarok *both have ipod support*
<dieman> wow
<magnon> we could possibly just continue having rhythmbox which also has ipod support :)
<dieman> the launchpad login service is sllooooow today
<hyperactivecrond> whoops :)
<dieman> mdz: for networkwideupdates if you want someone to look over ideas or even perhaps code some stuff let me know
<dieman> mdz: what youve got up for a spec now is much closer to what i imagine :)
<mdz> dieman: cool, mvo is the point person to talk to on that one
<dieman> ahh
<dieman> wrong nick :)
<dieman> yeah, mis-nicked there.
<dieman> sorry about that :)
<dieman> ahh, saw your name under registrant
<Kamion> Kinnison: yep?
<mvo> dieman: in a meeting right now, but I would love to hear more
<dieman> ok
<dieman> i just thought about 'shoot, i should have gone to ubz' last week
<dieman> perhaps next time
<dieman> around
<dieman> but yes, i'll be around
<highvoltage> ogra: (ping timeout) pong
<tseng> spayne: how goes the flaiming
<spayne> tseng: huh?
<spayne> tseng: you mean Flaim?
<tseng> yes, I do
<spayne> tseng: let me find out
<spayne> tseng: apparntly, it had been in the works for a considerable time but it needed this push
<spayne> tseng: i doubt anything has happened yet though as they said it could take months
<spayne> tseng: but it WILL be done in time for Dapper
<tseng> you could port it to sqlite in "months"
<spayne> but there is no point now - Flaim works wel
<spayne> *well
<slomo> what is flaim?
<tseng> ok, thanks for the update
<spayne> and they were planning on porting it to BDB IRRC
<spayne> no bother
<spayne> slomo: it is the backend used by most of Novell's products, including iFolder and GroupWise
<Mithrandir> berkeleydb is such a pile of shit.
<slomo> ah that closed-source thingie
<tseng> Mithrandir: good afternoon sunshine
<spayne> slomo: not any longer :-)
<tseng> spayne: saying it alot doesnt make it true.
<spayne> tseng: saying what a lot?
<tseng> spayne: i am less then thrilled by the middle man approach
<tseng> no one has said anything publically about open sourcing flaim except through you
<tseng> who, no offense to yourself, are an easily discredible source
<mdke> lol
<spayne> it's good to be appricated
<Mithrandir> hiya tseng. :-)
<tseng> i understand that its not solely their choice to make, but the MiM stuff is tiresome
<spayne> tseng: if your tired of the middle man, go into #ifolder on gimpnet and ask yourself
<Mithrandir> tseng: we're hopefully going to get rid of bdb anyway, so.  At least most of the dependencies on it.
<Simira> tseng: have I met you yet?
<tseng> I think I did ask, on the mailing list
<tseng> Simira: unfortunately no
<tseng> Simira: i met your stuffed firefox
<tseng> :D
<Simira> tseng?
<spayne> tseng: you can not blame me if they do not answer - they are busy guys
<tseng> he stowed away with tollef to sydney
<spayne> tseng: they rewriting Simias and then Flaim stuff is a hell of a lot
* Simira is getting confused about which conversation she is a part of
<tseng> spayne: i will remain "optimisitcally cautious"
<spayne> tseng: sure, what ever
<tseng> thanks for keeping the ball rolling
<spayne> od
<spayne> *nod
<Keybuk> seb128: iz gtk bug
<Keybuk> metacity needs killing to see new fonts
<seb128> Keybuk: iz daniels bog
<daniels> q
<daniels> seb128: how on earth is it my bug?
<daniels> seb128: it's a fontconfig problem
<daniels> seb128: that's on your side of the stack.  hth, hand. :)
<seb128> daniels: my side of the stack starts by "g", fontconfig does
<seb128> doesn't
<daniels> mine starts with an X
<seb128> who wants the f ?
<seb128> let's say it's Keybuk's
<daniels> that sounds like a euphemism
<tseng> its closer to g than x
<daniels> and yes, that fits perfectly
* tseng votes seb
<daniels> VOTE [1]  SEB128
<seb128> VOTE [2]  KEYBUK
<Keybuk> I always want the f
<daniels> VOTE [0]  JDUB
<Keybuk> and the b
<Keybuk> GIVE ME A B
<Keybuk> GIVE ME AN O
<Mithrandir> b
<Mithrandir> o
* tseng gives you an N
<daniels> GIVE ME A B
<daniels> GIVE ME A 2
<daniels> booooooooooooooooooooooooooooob2!
<dilinger> boob?
<Keybuk> yes, give me a bob2
<Keybuk> AND A SPADE!
<Kinnison> kabooom!
<Keybuk> ssssh
<Keybuk> he's here
<desrt> >:|
<Keybuk> :@)
<daniels> what the christ is that?
<daniels> an emoticon to express your nose being a concentric circle?
<tseng> someone hit in te face with a pastry
<daniels> MY NOSE TURNED INTO A PORTAL TO THE VOID
<daniels> PLS HELP
<Mithrandir> ...
<desrt> only if a danish is also a portal into the void
<daniels> breakfast BRUSH WITH DEATH
<Keybuk> desrt: clearly you haven't been to Denmark
<desrt> quite.
<daniels> denmark is perfectly cromulent
<desrt> cromBulent
<daniels> except that they drive on the wrong side of the road
<daniels> fascists
<daniels> KEEP LEFT UNLESS OVERTAKING
<desrt> that appears to be a ridiculous statement
<cevizoglu>  I wish my highway said that, except keep right, of course
<Keybuk> except you drive on the wrong side of the rode
<Keybuk> err... that would be the start of a very funny joke
<Keybuk> if I could spell
<Keybuk> but I can't
<Keybuk> so am gonna stop now
<Keybuk> and leave you all guessing to what the punch line was
<Mithrandir> you spelt it "gonna" as well.  I get being so close to the US is finally getting at you.  Jelly.
<madsen> Kamion: Hey! Was it you with the trick for the volito tablet? (Sorry, I forgot all about it.)
<Kamion> madsen: volito tablet?
<elmo> subscriptions on wiki.ubuntu.com are back (thanks to spiv)
<madsen> Kamion: hehe, apparently not then. :)
<madsen> Kamion: Wait, my bad, it was khakionion. :) (Just recalled that the name started with 'ka'.)
<madsen> lol! Muse crashed and now there's a beat stuck! It just keeps playing even though I got "[3] +  Segmentation fault      sudo muse". (Probably jackd.)
<madsen> Hehe, it was jackd - when killed all stopped and got nice and quiet. :) Kinda weird feeling though... Usually it's the other way around - the program is open, but the sound doesn't work. Hehe.
<Keybuk> distrotic ?
<madsen> que?
<Keybuk> what would be the term for "patriotic", but referring to one's choice of distro
<madsen> rofl!
<Keybuk> I think we've decided on "distria", ergo "distriotic"
<madsen> distriotic sounds nice to me (and I study linguistics, so I'm always right :-p).
<Kamion> (dulce et decorum est / pro distria mori.)
<daniels> spot the cantabridgian
<madsen> Ok, I'm a linguist, but I don't know latin.
<Kamion> daniels: I read Wilfred Owen well before university
<the--dud> 99% of all latin is wrong anyhow... so I've heard
<Kamion> good grief, Ubuntu has corrupted me. I typed 'universeity'.
<the--dud> little spelling and grammar stuff
<daniels> Kamion: multiverseity?
<Keybuk> restrictedity
<madsen> the--dud: Ah, I think that's a bit over the top. Much of it has been reconstructed, but much of the grammar comes from sanskrit and is definitely close to the "original", so to speak.
<the--dud> yeah, probably
<the--dud> I'll stick to Norwegian and English I think
<madsen> the--dud: But yeah, I'd find it hard to imagine that Latin had a word for "computer" before 1900. ;)
<the--dud> hehe
<madsen> the--dud: Latin sucks anyway, pretty much and non-Indo-European language is more fun.
<Keybuk> madsen: yeah, those Latinish people stole the word from English!
<Keybuk> that mu
<Keybuk> that myth about "compute" being latin first is just wrong
<madsen> Keybuk: I don't know, they might have had a word for "calculate" or "figure out" - but it definitely didn't apply to the computers of today.
* netjoined: irc.freenode.net -> brown.freenode.net
<LaserJock> hi azeem
<azeem> hi
<Mithrandir> well, "computer" isn't the word used in a lot of other languages, like it being "data machine" in norwegian.
<LaserJock> azeem: did you see my post to ghemical-devel?
<sivang> Mithrandir: in hebrew as well 
<madsen> Mithrandir: True, same goes for Finnish "tietokone". Danish uses "computer", but had the word "datamat" back in the late 70'es.
<Mithrandir> swedish uses "dator"
<madsen> The word "compute" basically means "figure out", so "a computer" is just a nominalization of the verb "compute". It's very common.
<madsen> Just like "a farmer" is someone who farms.
<azeem> LaserJock: yeah, though for some reason I did not connect your name to your nick until five minutes ago
<LaserJock> azeem: Sorry, I should have said something
* madsen sneaks off to the kitchen for a snack. Laters! :)
<lamont> cc1: error: invalid option 'tune=hppa'
<lamont> wth??
<pitti> mdz: do we care about hoary->dapper upgrades?
<pitti> mdz: I'm just cleaning up the postgresql seeds a bit, and I wonder whether I should keep the transitional postgresql pakcage
<tfheen> pitti: not really.
<ompaul> pitti, if you don't your users will love you - in particular those who think that once a year is enough for upgrading their web server 
<pitti> ompaul, mdz: it's just that this transitional package keeps postgresql 7.4 in main, which we don't want for dapper
<ompaul> pitti, I am going to love you with dapper then :-) 
<pitti> ompaul: we only need this transitional package once ever - all further deprecations will be handled much more gracefully
<ompaul> pitti, in that case I would say kill it early if you leave it around too long it will be expected in by some future generation, but hey your the man
<pitti> ompaul: right, that's why I'm asking - on UBZ we agreed to a major cleanup of main to be able to support dapper
<ompaul> pitti, from that perspective people the person with the one year attitude or longer would be happier to have longer term future proofing 
<ompaul> s/people//
<pitti> ompaul: the current architecture copes with all that, but at some point we just have to deprecate the old packages
<ompaul> yeap
<pitti> ompaul: and I doubt that 7.4 will be supported from upstream for 5 years
<ompaul> I would agree with that
<pitti> support for 7.1 has ceased a while ago
<ompaul> they are on 8.1rc
<ompaul> with 8.0 stable
<pitti> right, and I will put 8.1 into dapper probably
<pitti> 8.1 will likely be released next week
<ompaul> thats nice
<zyga> hello
<robertj^> are the priorities on launchpad priorities for review or actual assigned prioriteis
<jdong> so guys, any plans of FF 1.5rc1 in Dapper?
<jdong> [NO, I'm not gonna backport unstable packages.... just want to run it personally] 
<Kamion> robertj^: both
<Kamion> jdong: yes, I believe Diziet's been working on the huge merge job for some time
<jdong> Kamion: thanks... I imagine it's a huge merge job
<Kamion> yes, and there wasn't all that much time between breezy release and the start of UBZ
* Kamion hasn't finished the routine installer merge yet either
#ubuntu-devel 2005-11-09
<robertj^> what's the story on Breezy Backports?
<mdke> it's in sources.list and the documentation but the archive hasn't been created afaik
<robertj^> come to think of it, where is the official backports info?
<mdke> https://wiki.ubuntu.com/UbuntuBackports ?
<mdke> that's a bit old
<mdz> ogra: thin-client-memory-usage reviewed
* robertj^ hits up RecentChanges for his daily fill of daily news, gossip, and tales of celebrity-developer dating
<HWolf> I thought all proper geeks where neuters. 
* HWolf ducks
<zyga> HWolf: maybe you should have said Hwolfs dappers
<mpt> HWolf, http://bbspot.com/News/2000/9/linux_laid.html
<HWolf> mpt, LMAO
<HWolf> Nobody got nothing. that's a double negative.
<HWolf> That means everybody got some. ;)
<Lord_Maynoth> I know you can autodetect your windows partitions in breezy by downloading a script, but will dapper drake automatically do this without the need to download a script?
<ogra> mdz, thanks, will fix
<Lord_Maynoth> just curious
<robertj^> Does anyone else here hate the map method of selecting location?
<cevizoglu> robertj^, no, I much prefer it to anything else out there, like the crappy drop-down menus with 200 items
<cevizoglu> robertj^, actually, I take that back.  having it autodetect is nicer
<robertj^> Select your country followed by timezone if nececerry would be nice
<robertj^> or if the map highlighted based on country/timezone
<robertj^> but I'm not anywhere near NY
<cevizoglu> I'm not anywhere near los angeles, but I know it's the same time zone  :)
<robertj^> I am however near the city that hosted the Olympics in '96, so it's not entirely in the middle of nowhere
<robertj^> OS X is the only oS that actually seems to have Atlanta listed but it's nearly impossible to click on
<robertj^> btw, Wikipedia says Atlanta is the 41st largest city in the world
<robertj^> of course you could be overly clever and set timezone after boot...
<LaserJock> robertj^: for what it's worth I agree. I don't see why you can't pick a timezone
<robertj^> err after install
<cevizoglu> robertj^, well, San Diego used to be fifth but I haven't seen **any** installers list it
<robertj^> cev, laserjock: hehe, will you undersign if I put a note on the wiki ;)
<LaserJock> yeah, it's kinda funny but I hate having to click on LA every time I want to set the timezone
<robertj^> https://wiki.ubuntu.com/UbuntuExpress/GnomeUserInterface#preview
* robertj^ pencils in a suggestion
<mvo> dieman: still around?
<mvo> dieman: sorry, I was too busy until now
<Kamion> cevizoglu: installers generally don't offer cities that don't have a distinct timezone; it just confuses
<Kamion> robertj^: ubuntu[macaddress]  is a really dreadful hostname I think; ubuntu would be just fine on desktops if we can't do better
<Kamion> if the hostname doesn't matter much (which it doesn't if it isn't in sync with DNS), no reason to pick something ugly :)
<Kamion> robertj^: country boundaries aren't an option because you can get put in jail for that :) I think evolution's timezone widget is fairly tolerant of clicking nearby
<Kamion> unfortunately clocks aren't reliable enough to do the NTP server thing, really; I have a bug open about that, but it's just too sucky in practice :(
<robertj^> Kamion: does the location actually get stored anywhere?
<robertj^> Kamion: problem for me is that nearby is near a timezone border
<cevizoglu> oh, why did I waste time asking about firefox 1.5 on here?  I downloaded it on breezy, it runs fine
<Kamion> robertj^: yeah, but the one I've seen highlights the city that you'd be clicking on
<robertj^> Kamion: does the city name get stored anywhere?
<Kamion> robertj^: yes, it goes in /etc/timezone
<Kamion> glibc timezones for some countries are named after cities
<Kamion> depends on the country
<robertj^> mine just says US/Eastern
<robertj^> Could we just highlight the whole timezone on the map?
<Kamion> there's also America/<blah>
<Kamion> no idea, that's up to the GNOME UI guys :)
<Kamion> I'm sure it's possible to select and offer only the "most recommended" timezones; tzsetup post-breezy has logic for that
<robertj^> Kamion: does anyone not know a standard name for their timezone
<Kamion> robertj^: er, yeah, most naive users won't
<robertj^> Is that a cultural thing?
<Kamion> no
<robertj^> Just a stupid thing eh?
<cevizoglu> robertj^, no, it's an unedumucation thing
<Kamion> no, it's not stupid either
<dredg> or you're on a laptop and you go to another country and don't know the standard name for the timezone
<robertj^> Kamion: I say its up there with forgetting your zipcode (which I did once)
<tfheen> robertj^: I'd guess most car owners don't care about the number of cylinders in their car either.
<Kamion> why should ordinary people care that their timezone name is "US/Eastern"? Some people might say "Eastern", some "New York", some "EST" - I doubt anyone will answer "US/Eastern"
<Kamion> robertj^: well I'm afraid you're being very US-centric
<robertj^> Kamion: well its an important piece of information
<robertj^> like not knowing what country your from
<Kamion> the US timezone names in glibc are more closely related to what people know than the ones for other countries
<HrdwrBoB> robertj^: not really
<dredg> or not knowing the difference between "your" and "you're"
<Kamion> robertj^: there's a difference between knowing what timezone you're in, and knowing what the glibc name for it is
<HrdwrBoB> timezones are a high level concept most people don't understand 
<mjg59> Given network connectivity, it's trivial to work out the timezone based on what the user claims local time is
<HrdwrBoB> most people aren't aware of things more than 1m away from them
<HrdwrBoB> let alone the rest of the world
<Kamion> mjg59: I think it's easier to ask the user to point at a map than to get them to enter local time
<Kamion> this is not about stupidity or provinciality
<Kamion> this is about timezone names not always being obviously related to what people know
<robertj^> if they aren't on the network, and their local time is right, does it really matter if their timezone is set...
<dredg> robertj^: in Ireland, summertime is called IST. guess 1) how many people in Ireland know that it's called IST and 2)how many other places on the planet use the abbreviation 'IST'
<robertj^> I just thought everyone used GTM +/-
<HrdwrBoB> dredg: australia has 'EST' same as the US
<tfheen> dredg: Iceland Standard Time, Indian Standard Time? .-)
<dredg> tfheen: you win... a lollipop
<mjg59> robertj^: Uhm. No.
<dredg> tfheen: there could be more for all i know (or care) though
<tfheen> yup
<daniels> HrdwrBoB: though it totally should be AEST
<HrdwrBoB> daniels: yeah
<HrdwrBoB> I'm with you on that one
<daniels> it's just glibc being obstinate and stupid
<tfheen> American East Standard Time?
<HrdwrBoB> tfheen: that's 'EST'
<daniels> princess: AEST -> Australian Eastern Standard Time
<HrdwrBoB> because apparently america is the center of the universe
<HrdwrBoB> ;)
<cevizoglu> HrdwrBoB, really?  amazing  :)
<robertj^> err not GMT but UTC btw
<dredg> looks like a sentence made entirely of TLAs
<cevizoglu> HrdwrBoB, but the greenwich meridian isn't in the US  :)
<cevizoglu> HrdwrBoB, so UK shares part of center-of-the-universism
<robertj^> Ok, but suppose average Joe doesn't know his timezone.  Does avarage Joe know what major city is also in his timezone?
<dredg> no, but they know roughly where they are on a map.
<cevizoglu> after running enough operating system installs, eventually it dawns on them  :)
<robertj^> dredg: do they?
<Kamion> I think you need to do user testing on this rather than making assertions
<cevizoglu> unless they're right on the border of two times zones, in which case they are more likely to know they are on the border...
<Kamion> make mockups with alternatives, experiment
<cevizoglu> but also more likely to choose the wrong timezone
<robertj^> Kamion: the problem with that is that flying out to the middle of nowhere and giving people who have never seen a computer before maps is rather expensive
<dredg> hmm. i ponder a mail to everyone in the company asking if they know off the top of their head where they are and what timezone they are in
<robertj^> and I'm not saying that should be your target
<cevizoglu> dredg, that would make for good water-cooler conversation
<Kamion> robertj^: it doesn't have to be the middle of nowhere, and having prepared the test you can ask others on the net to help you
<robertj^> cervizoglu: take a map, center it on South Africa and give it to non college-prep kids in the US
<robertj^> cervizoglu: I think you would be 50/50 amused/dismayed
<robertj^> There are people here who will identify the middle-east as being in Central America
<cevizoglu> robertj^, in high-school US I think the curriculum is for capitals of the US, but not of the world.. I could be wrong
<robertj^> cevizoglu: most certainly not, I went to a good high-school and was in the better classes
<dredg> cevizoglu: it could get some interesting results, and would help establish whether several thousand people know where they are in the world
<robertj^> but curriculum is state-by-state and county-by-county for the most part
<Kamion> dholbach: FYI I'm going to skip approving inclusion-of-docs until we've had the dapper release schedule BOF
<cevizoglu> robertj^, I don't remember anymore, it's been so long  :)
<robertj^> but there is a popular show here that takes people off the street and asks them what we should do with the middle east and then asks them to place points on the map where the bombs should go
<robertj^> cev: noone cares about state capitals in the US, I don't know most of them probably
<robertj^> they don't mean much unless you live in that state because they often are not that important
<cevizoglu> robertj^, depends on what career you go into and how much traveling you do
<robertj^> cev: yes, if you go into geography you better know them!
<robertj^> but seriously, it's really not that important for the smaller states like South Dakota
<dholbach> Kamion: right
* bob2 digs a shallow hole for Keybuk 
<dieman> mpt: np
<dieman> ack
<dieman> mpt: misfire
<dieman> mvo: around now
<dieman> will just be messing with my mythtv box for a bit
<bytee_> so, anyone about, that does ppc goodness?
<radix> anyone know what's going on with the zope and plone packages in breezy? a lot of the plone-related ones are installing stuff like "CMFCore:1.5", which doesn't seem to work at all
<tsume> eww :(
<bob2> yay for firefox losing all my history again
<Lord_Maynoth> Will Dapper automatically configure and mount your windows partitions without having to download and run a script (like in breezy)???
<LaserJock> Lord_Maynoth: have you tried the mailing list? or looked at the wiki? a lot of stuff is being worked out at UBZ right now
<Lord_Maynoth> I haven't seen anything about it yet
<minghua> I remember seeing something about this in UBZ proposal page
<Lord_Maynoth> where can i find that
<zyga> morning
<micampe> hello
<micampe> where can I find the mount options for usb devices? I want to remove the 'noexec' flag
<zyga> micampe: this question should be asked in #ubuntu
<micampe> hm sorry
<hunger> When will UBZ be over again?
<pef> hello
<highvoltage> hi pef 
<HiddenWolf> why is libasound installed on a server, or even alsa? :)
<pef> elmo: hello, can I just know if my email address is whitelisted for upload to archive ? (universe)
<pef> (loic at dev dot erodia dot net)
<slomo_> pef: do you want something uploaded? i can do it for you until you can do it yourself
<mindwarp> .
<Kamion> pef_aw: yes, you're on the whitelist
<zakame> hello all
<enrico> Hello.  Who's the GCC guy now?
<Mithrandir> enrico: doko
<enrico> Mithrandir: thanks
<Simira> enrico :)
<enrico> Simira: hi!
<jordi> Keybuk: ping
<jordi> mvo: do you know if, having bind installed (with conffiles in /etc) and doing apt-get install bind9, do you get the etc files replaced, or are they preserved?
<jordi> if they have the same name
<mvo> jordi: are they modified by you?
<jordi> yeah. Some, at least.
<jordi> what I'm asking basically if it'll replace my named.conf silently without asking me :)
<mvo> jordi: than the you will probably get some conffile changed questions and end with ".dpkg-old" files in /etc
<Mithrandir> jordi: they shouldn't be replaced without you confirming to have them replaced.
<mvo> jordi: no, it really shouldn't. unless it's not a conffile (but I strongly doubt that)
<jordi> ok
<Lathiat> heh someone just commented on bug 1 as "Bill Gates" "As far as I am concerned this bug works as expected, it should be considered a feature"
<zakame> Lathiat: on malone?
<Lathiat> zakame: yeh
<Lathiat> http://launchpad.net/malone/+bug/1 i think
<Lathiat> nope
<zakame> https://launchpad.net/distros/ubuntu/+bug/1
<Lathiat> Launchpad will be going offline for maintenance in five minutes. duh dah
<Keybuk> jordi: 'sup?
<HiddenWolf> got it, ik geef je half 8 ofzo wel een belletje om te zien of je nog in de buurt bent. :)
<seb128> HiddenWolf: ELANGUAGE
<HiddenWolf> whoops
<HiddenWolf> seb128, was supposed to be a /msg
* HiddenWolf hides
<Lathiat> seb128: wheres your -
<seb128> hehe
<HiddenWolf> Seveas, ^^
<seb128> Lathiat: my "-"?
<Lathiat> so whos pimpppinnn avahi :)
<Lathiat> seb128: -ELANGUAGE :)
<seb128> oh
<seb128> Lathiat: dunno, the assignee is not here :p
<Wo|f> clear
<Wo|f> whoops
<Wo|f> heh
<Lathiat> "honey, whats that weird #ubuntu channel.. what are you talking about in there.."
<Wo|f> Just wanted to thank the Ubuntu developers. Someone in #ubuntu said this would be the place.
<Wo|f> It's working so well on this laptop. Even the Winmodem works! ^_^
<Wo|f> So nicely done, you guys rock
<Wo|f> Have a good one!
<Lathiat> heh sdf.lonestar.org
<ogra> Lathiat, hopefuly nobody actively today, zeroconf shuts down the whole wlan if you start it, it seems
<Lathiat> ogra: zeroconf has nothign to do with avahi :)
<Lathiat> mumble :)
<Lathiat> i poked anand about that
<Lathiat> apparently network-manager assigns ipv4-ll addresses now
<Lathiat> altho i havent seen it
<seb128> Lathiat: so what is this zeroconf bof about?
<Lathiat> seb128: zeroconf (the program) assigns 169.254.0.0/16 ipv4 link local addresses
<Lathiat> seb128: designed to be used when you dont have a real ip via dhcp ro static config
<Lathiat> to allow communication
<Lathiat> 'zeroconf' as a whole encompasses many things, including this, and avahi, and others
<Lathiat> obviously if zeroconf the program is to be included it needs to be looked at :)
<seb128> I don't think it's going to be shipped
<Burgundavia> seb128, are you talking about the prorgram or the idea?
<seb128> the program
<mjg59> When I installed zeroconf, I got a *lot* of DNS lookups coming from my zeroconfed address
<Lathiat> weird
<Lathiat> zeroconf only does ARP
<Lathiat> it has the potential to do lots of arps
<Lathiat> if it has a bug
<Lathiat> which lookign at the code it doesnt try hard to prevent
<Lathiat> seems to rely on the poll() timeout to co-ordinate everything
<mjg59> I'm guessing that it was something else that was causing it
<Lathiat> as far as i can see
<mjg59> Possibly networkmanager getting confused
* Lathiat shrugs
<Lathiat> i'll have to fiddle
<Lathiat> i havent seen it myself yet
<seb128> Lathiat: do you want to join the gobby session for Zeroconf?
<Lathiat> seb128: hrm
<Lathiat> seb128: how do i do that?
<seb128> Lathiat: apt-get install gooby
<Burgundavia> gobby
<seb128> yeah
<seb128> Lathiat: 10.208.231.160 
* Lathiat installs
<Lathiat> seb128: yeh that ip is entirely un-routable :)
<seb128> Lathiat: ups, we should use the wrong network for that, sorry
<Lathiat> seb128: give me remote port forward love? :)
<seb128> Lathiat: sorry, but we have like 40 min for the BOF, I don't want to spend 10 min to get gobby working now
<Lathiat> heh ok
<Lathiat> have fun :P)
<Lathiat> err, s/P//
<hub> Lathiat: what are your plans for CUPS?
<hub> Lathiat: because I had done that for my job, so I can redo it the right way
<Lathiat> hub: well i have none yet
<Lathiat> hub: someone...
<Lathiat> hub: you? :)
<Lathiat> hub: mentioned you wanted to do that
<hub> Lathiat: including the mdns: backend
<hub> and the notification
<hub> I looked at the Apple coude
<hub> s/coude/code/
<hub> I haven't started but I have the design
<hub> in mind
* Lathiat nods
<Lathiat> hub: go for it :)
<zyga> jbailey: ping
<jbailey> zyga: Pong.
<zyga> jbailey: do you maintain glibc?
<jbailey> zyga: For some values of maintain, for some values of glibc. =)
<jordi> zyga: DUDE
<jordi> zyga: we're talking about you man
<zyga> jbailey: I need to talk to someone who could help me with replacing current malloc with my experimental stuff 
<zyga> jordi: hi :)
<pitti> Hi zyga 
<jordi> zyga: have you tested how big the performance hit is for your gettext-based desktop solution?
<zyga> pitti: hi
<jbailey> zyga: Just define malloc in a private library and use it.  ELF will take care of everything else for you.
<zyga> jordi: not yet (I was busy writing grad projecT)
<zyga> but I've got a solution
<zyga> jbailey: and LD_PRELOAD it?
<jordi> zyga: we're discussing the issue right now at ubz and if the performance isn't horrible, it's the way to go
<pitti> zyga: I saw your patch, that looks pretty nice
<jordi> (without caching daemon or whatever)
<zyga> jordi, pitti: the solution in a few words: 
<pitti> I already saw the g-d changes
<zyga> on boot unpack a .tar.gz with .desktop files to some /var/cache mounted as ramdisk/tmpfs
<zyga> do the same with default locale .mo files 
* jordi boggles.
<pitti> zyga: erm
<pitti> zyga: our backup solution is to create a language-packs-desktop package
<pitti> zyga: which ships all desktop/server/etc. files with updated translations
<pitti> zyga: sth like that?
<zyga> pitti: will they overwrite existing .desktop files?
<pitti> no
<pitti> it will ship them in a parallel hierarchy
<jordi> zyga: I don't understand what that would do. Can you explain more?
<jbailey> zyga: You can LD_PRELOAD it or just link it in.
<zyga> okay, so another preference system
<pitti> /usr/share/applicatinons-langpakcs
<zyga> jordi: the issue is: stating/opening lots of files
<jordi> zyga: yup-
<pitti> we are aware of that
<zyga> well stat and open are expansive only on real fs, not on ram fs
<jbailey> zyga: A linked in malloc should override the weak symbols in the library.
<zyga> if we can just open and extract one .tar.gz to a ramdisk that will remove the issue?
<jordi> jbailey: zyga is ours, go away. :)
<zyga> jbailey: any way to know for sure which symbols apart the obvious I need to provide
<zyga> jbailey: and how to do init fini properly?
<zyga> jordi, pitti: another way to solve the issue is to pack all the translations into special domain
<pitti> zyga: AFAICS this would not be entirely different to shipping a package with all desktop files
<zyga> that will just make one .mo file, slighlty harder to build
<pitti> but with less hacking
<pitti> zyga: ok, let's do some actual benchmarking first
<jordi> zyga: I had thought of that. You mean, to have tiny .mo files with just two or 3 strings?
<Kinnison> ciao all
<pitti> maybe we discuss about improvements we don#t even need
<pitti> bye Kinnison 
<zyga> jordi: no, big .mo file with all the strings for all .desktop files
<carlos> zyga, zyga that will not work there are msgid that have more than one translation
<carlos> zyga, and I guess the same would happen with .desktop files
<jordi> oh. can you havea mofile with many translations?
<pitti> and besides, you need to update that whenever *any* app desktop file changes
<zyga> carlos: we can build a prefix system that will resolve that I guess
<pitti> CRAAACK
<zyga> jordi: no, one .mo file per language, just pack all the strings together to solve fs inefficency
<carlos> zyga, dude, let your brain rest a bit, first we should check how bad is the performance
<zyga> carlos: right
<carlos> and then look for a good solution
<zyga> I'll test that tomorrow morning
<pitti> that'll be great
<zyga> right now there is the kubuntu issue, someone needs to patch that too
<jordi> zyga: still don't see how, but anyway
<jordi> zyga: yup. jr knows
<zyga> jordi: take about 3 strings from each .desktop file (per language) and put them into one .mo file
<koke> atm, which is the winner solution?
<zyga> guys
<zyga> one more idea
<zyga> since upstream was worried about a gettext dependency
<jordi> how do you put multiple msgstrs for a single msgid in a mo file? never tried to do that
<zyga> we could make a semi-gettext system with similar api but one that is optimized for our case
<jordi> zyga: woa dude
<zyga> jordi: prefix them
<jordi> in Spain we say that's how you kill a fly with cannons
<jordi> zyga: ah, with prefixes, ok.
<zyga> anyway that's all from me
<zyga> jbailey: .
<zyga> jbailey: you did not answer the last question, how to check which symbols are malloc essential (apart from the obvious ones)
<jordi> zyga: ok. We need to find out how bad it's ust reading the normal mo files.
<jordi> Unfortunately I expect the performance hit to be noticeable.
<Kamion> jordi: "using a sledgehammer to crack a nut" is one of the similar English idioms
<jordi> Kamion: aha :)
<zyga> jordi: I'll exploit the preload bit in the boot stage
<zyga> cat'ing various files should help
<zyga> can anyone give me a hint on how to patch multiple .desktop files to add a good domain name easily?
<jordi> hmm, sed?
<seb128> Lathiat, ajmitch, desrt, Burgundavia: I've dropped my notes to https://wiki.ubuntu.com/ZeroConfSpec, there is probably some cleanup, points to details and stuff. Feel free to comment, fix stuff, etc .. thanks :)
<jordi> SEB
<spayne|laptop> evenging all
<Riddell> seb128: usefull -> useful
<Riddell> seb128: "SebastienBacher has already made a wiki page about this" should link to the wiki page
<jordi> Riddell: aaply them yourself :)
<Riddell> busy, lazy, don't want to conflic with others, etc
<seb128> Riddell: thanks
<jordi> seb128: see, the K guys slack mor ethan me
<seb128> yeah
<sebest_> seb128: about this: #
<sebest_> Ask Trent to add option to avahi to start/stop listening on a particular interface (so that we don't have to start/kill the daemon whenever we change the option or bring an interface up/down).
<sebest_> #
<seb128> which is not easy to do
<jordi> ha
<sebest_> you don't need to restart the deamon when an iface appear or disappear
<sebest_> avahi-daemon use netlink to detect this on the fly
<seb128> I didn't wrote this
<seb128> but as said, feel free to fix the wiki
<seb128> I don't know a lot about avahi, I just got assigned as a drafter
<sebest_> i'd like to have the opinion of the writer before modifying it
<jdub> sebest_: that was mostly about turning it on or off, rather than reacting to interface changes
<hunger> How do I write a spec in the first place? Or better: what do I do once I have written up something on my box. Put it in the wiki? What then?
<Riddell> hunger: your box?
<Riddell> hunger: https://launchpad.net/distros/ubuntu/+addspec
<hunger> Riddell: I copied the template to my computer and edited it here.
<hunger> Riddell: No net at work:-(
<Riddell> hunger: ah.  add it thourgh launchpad there and put it on a wiki page
<sebest_> jdub: what about controlling the MULTICAST flag on the iface?
<sebest_> if the iface doesn't this flag avahi-daemon will start but do nothing, and it will start working as soon as you add this flag to the iface
<jordi> oh man
<jordi> I'm late for my break
<carlos> jordi, you don't have anything for the next session...
<jordi> which probably means drafting an advocacy proposal.
<jbailey> zyga: I'm working at the moment, so replying quite slowly.
<carstenh> hi jeff :)
<carstenh> pitti: ping
<pitti> Hi carstenh 
<pef> when a package may need a lot of external dev packages to be fully fonctionnal (like music softwares, rosegarden, ardour, ressound, ...) how can I know what to put in Build-Depends and what not put in ? make a package foo with minimal deps, and others like foo-alsa, foo-featureX, etc ?
<slomo> pef: you decide ;) make the package usable for most users and if the package allows it split of binary packages for additional features
<pef> slomo: because a friend of mine complaine he has to rebuild packages from source to have all features he wants
<pef> s/complaine/complains/
<slomo> pef: the he should tell the maintainer about it and maybe this features can be added or provided by additional packages (what is the package you are talking about and which features?)
<pef> slomo: haven't the list here, but I remember rosegarden with DSSI support
<slomo> pef: hmm... whatever DSSI is... can this be added easily? ;)
<pef> slomo: haven't investigate yet, just curious how to handle problems like that, so multiples binary packages is a solution ?
<slomo> pef: yes... or in the same package when it doesn't pull in too many/too big dependencies or is wanted by almost all users ;)
<pef> slomo: ok I see, thank you :) 
<Mez> hmm
<slomo> pef: but that's only my oppinion... don't take it as a general rule ;)
<pef> slomo: I though similar :)
<zyga> jbailey: sure, just reply on priv so it does not get lost
<pef> slomo: my friend's job is working on music, so I think he can help me with any music related package. If foo-1.2 is in the archive, I build for him (to test with all features enable for example) foo-1.2+1, when foo-1.3 will be available in the archive, does the upgrade will be done cleanly ? 
<mpt> Kamion, when Ubuntu Express is running not on x86, what language does it default to, and why?
<Kamion> mpt: if the user has selected a language in the language selector, then we use that
<Kamion> mpt: otherwise, if we have no better default, our general fallback is English
<mpt> thanks Kamion 
<pef> bye !
<dholbach> UBU
<Pygi> Hello people :)
<Pygi> Anyone actually here? :)
<Mez> we're all busy
<Mez> leave us alone
<Pygi> ok, sorry =P
<Simira> Pygi: we're all hard working, yes :)
<Pygi> ah, I just wanted to show you one project
<Pygi> but nevermind :P
<Simira> Pygi: what about?
<Pygi> Ubuntu installer
<Pygi> graphical one :)
<lazyilmaz> hi all
<Simira> Pygi: have you looked at the latest specs? ping Kamion about that project, we've just been revewing the cd bootloader, actually.
<Pygi> ah, I am working on a separate project...
<Simira> for what?
<Pygi> www.sourceforge.net/projects/crowly
<Simira> a new installer?
<Pygi> yup
<minghua> Pygi: a project with no code, no documentation, not even a home page?
<Pygi> actually it has code, but it's not released :)
<Mithrandir> Pygi: you might want to look at ubuntuexpress, which is the project to make a graphical installer
<Simira> Pygi: so, what do you want us to look at, then?
<Pygi> ah, nothing, I was just saying that I am making it, anyway :/
<chmj> eheh 
<Pygi> I know mithrandir, I looked at current specs, and don't like them :/
<Simira> oh, that's why you gave us the link ;)
<Pygi> what a conclusion :P
<Pygi> good one :)
<Simira> Pygi: would be nice to have a look at it, though. Not that I could do anything with it... translate it, maybe, but thats not really first thing up.
<Pygi> ah :P
<Kamion> Pygi: one of the major focuses of ubuntu-express is reusing as much code as possible from d-i
<Pygi> kamion: yes, I know...
<Kamion> so I'm afraid a new from-scratch installer is only of interest for UI ideas that we might be able to reuse
<Pygi> Several people tried to convince me to join the UbuntuExpress project but...
<Kamion> we will likely be basing our work on the Guadalinex installer, which has got a substantial distance and has roughly the right structure, even though a lot of bits need to be changed
<Pygi> ah :/
<Kamion> what don't you like about the current specs?
<Kamion> (I'm the drafter of most of them and have had a lot of input)
<SEJeff> Since upgrading to dapper, my ipod stopped being recognized by gnome or rhythmbox. What information do I need to file a useful bug report?
<Pygi> I don't say that UbuntuExpress is bad, it'll be a good thing :)
<Pygi> Just not something I like :P
<Pygi> I got really a quite good designer to work along me...
<Pygi> so it should look nice too :P
<HiddenWolf> SEJeff, #ubuntu, and https://wiki.ubuntu.com/DebuggingRemovableDevice
#ubuntu-devel 2005-11-10
<SEJeff> https://wiki.ubuntu.com/DebuggingRemovableDevice This page does not yet exist
<SEJeff> And I thought #ubuntu was for breezy aka ubuntu stable
<HiddenWolf> +s
<HiddenWolf> SEJeff, /topic
<HiddenWolf> https://wiki.ubuntu.com/DebuggingRemovableDevices
<SEJeff> ok, thanks
<HiddenWolf> SEJeff, this channel is for development, bug reporting and user support for any version are in #ubuntu
<HiddenWolf> or #ubuntu-motu, for universe.
<robertj> I like the menu spec... #
<robertj> Bluetooth manager
<robertj>     *
<robertj>       - hide due to being crap
* Burgundavia takes pride in having wrote that
<HiddenWolf> heh
<HiddenWolf> now to make sure that all that crap doesn't start on startup, and we'll all be happy. :)
<zyga> re
* zyga had a nice part
* zyga had a nice party
<HiddenWolf> btw, I don't have it on my menu, and I haven't edited it either.
<robertj> " The entire Evolution development team (mostly based in India) seems to be dissolved, with only one maintainer left to keep the product breathing (after all, there are existing Novell customers); Hula development is said to be cut completely; Mono development is also seriously affected; what the future holds for the NLD product remains to be seen."
<robertj> ouchie...
<mjr> urgh
<corey_> robertj, where is that from?
<SEJeff> robertj: What are you talking about?
<robertj> http://linuxtoday.com/news_story.php3?ltsn=2005-11-04-018-26-OP-SS-NV
<hunger> https://wiki.ubuntu.com/Xen looks like a spec, is approved and a BreezyGoal. Why isen't it listed in launchpad's spec area?
<Kamion> hunger: breezy goals weren't registered in launchpad
<Kamion> the specification tracker was only written a few weeks ago
<robertj> I wonder if that scrawny Mexican is a free agent now ;)
* robertj guesses no
<hunger> Kamion: So is this spec still valid? Should it get registered for dapper?
<SEJeff> robertj: Only 1 hula dev got cut
<Kamion> hunger: I don't think there's a need; having discussed it, it's more of a kernel wishlist report :-)
<SEJeff> robertj: And they added a full time hula qa
<SEJeff> robertj: /j #hula and ask if you don't beleive me
<robertj> I'll take your word for it
<hunger> Kamion: So there are no current plans of supporting xen?
<robertj> but thanks for the info
<hunger> Kamion: It is definitly more than a kernel wishlist!
<robertj> Know if the Evolution part is true?
<Kamion> hunger: it's a feature request and therefore a wishlist
<Kamion> they're synonymous
<SEJeff> robertj: There is a term for that.... it's called FUD
<hunger> Kamion: Glibc needs patching, grub-update needs work, the stuff must get packaged.
<Kamion> hunger: not all plans are registered as specifications; we've been talking about Xen support, but to some extent I believe it depends on upstream activity
<Kamion> hunger: requirements for glibc patches are serious problems for the rigid and boring dapper release cycle
<hunger> Kamion: Xen is basically another arch that would need to get supported.
<hunger> Kamion: Yeap... that is why I think there should be a spec:-)
<Kamion> it's not currently scheduled for core development time, and I don't think we have the resources to devote any to it (mdz might correct me there); but if somebody would like to step up to do the required packaging work very early in the cycle (i.e. real soon now), it could be considered
<SEJeff> robertj: From one of the lead hula devs: campd: hula is alive and well
<HiddenWolf> SEJeff, yeah, they won't kill off something that cool. ;)
<HiddenWolf> besides, it's netmail+1, quite essential to novell, one should imagine.
<hunger> Kamion: There are some xen debs for ubuntu. They are terribly outdated though.
<Kamion> somebody will need to step up to update those
<SEJeff> HiddenWolf: The article is a lie. It's ashame that many other people believe all the media they read
<hunger> Kamion: I might brush them up a little...
<Kamion> as I say, we have a lot of resource constraints, and at the moment stabilisation generally takes precedence over feature development (with a few carefully-selected high-impact exceptions)
<hunger> Kamion: I do understand that.
<HiddenWolf> SEJeff, anyone with half a brain can think up that a company just doesn't kill one of it's main product lines when it's been cutting down on it's alternatives for the better part of a year, and spent a hell of a lot of money on it, AND just launched a handful of projects in the last few months to make it rule.
<hunger> Kamion: I am wondering what the status of xen in ubuntu is at the moment.
<hunger> Kamion: So it is "didn't happen for breezy, will probably not happen in dapper, but is something still considered""?
<HiddenWolf> hunger, read carefully, "can be considered ... if someone steps up ... real soon"
<Kamion> hunger: will not receive core development resource (again, as far as I know) != will probably not happen
<hunger> HiddenWolf: Well, patching glibc is very intrusive, I wouldn't do that ;-)
<Kamion> encouraging community development == good
<hunger> HiddenWolf: Not in dapper.
<HiddenWolf> hunger, so do what you can, and beg off the rest. :)
<carl> is blackdown what should be "tested" as the sun java replacement?
<Kamion> glibc patches are certainly scary, core dev or no
<Kamion> carl: for the most part we're using gcj/gij
<Kamion> blackdown shares some licensing problems with Sun
<ogra_> use blackdown if you urgently need the browser plugin
<Kamion> classpath for the class library
<ogra_> thats why we have it in multiverse
<hunger> Kamion: Yes, I understood that. I'll try to free up some time to package the stuff. The hypervisor and tools are pretty straight forward, dunno about the kernels thought.
<carl> so there is currently no java in main?
<Kamion> carl: gcj/gij are in main and are used for openoffice.org
<Lathiat> whats with all the insecure tempoary file bugs lately
<Lathiat> i guess someoen suddenly reliased the issue
<Lathiat> and went mad in every single product
<Lathiat> or something
<Kamion> Lathiat: joeyh does a pass through everything he can find in Debian every so often; it's not the first time
<Lathiat> ah
<HiddenWolf> and be glad he does. :)
<dholbach> desrt: ping
<dholbach> desrt: where are you guy hanging out?
<rob^> is anyone who works on gnome-app-install here?
<zakame> morning
<mhz> hi there
<mhz> excuse me i still know very little about UbuntuExpress but, does that mean users with thin or less powerful boxes will have real hard time trying to install ubuntu form GUI environment?
<mhz> what will happen with boxes than only install from network?
<mhz> or from floppy booting?
<mhz> Does anyone know about this issues?
<mhz> is this the proper channel to discuss about this?
<jsgotangco> rob^: its best to ask mvo about it
<Riddell> mhz: debian-installer will still be there as an option
<rob^> I'm going to email the devel- list
<jsgotangco> rob^: about?
<rob^> gai
<jsgotangco> on?
<rob^> installing packages without .desktop
<mdke> mhz, see the spec in "outstanding issues": Specialized for the common case desktop installation
<mhz> Riddell: hmmm, I can't quite picture it, then. How would a machine that can't run LiveCd or boot from CD install ? 
<jsgotangco> ahhh
<Riddell> mhz: same as it does now
<jsgotangco> it'll reduce our cd to 1
<mhz> Riddell: ahhh, what a relief
<Riddell> do we even have floppy boot still as an option?
<zakame> hmmm, 2.6 doesn't fit in a floppy imho
<mhz> Riddell: many old pcs on schools boot from floppy if I want to install a distro that is an .ISO on the HD
<mhz> or I usually used netboot
<HrdwrBoB> mhz: install from network is easy
<HrdwrBoB> floppy install is not supported
<mhz> last and only time i tried netboot from a LiveCD it was a total failure
<mhz> (i couldn't do it)
<HrdwrBoB> ?
<mhz> it just did not boot
<HrdwrBoB> you netboot using PXE 
<HrdwrBoB> and the netboot images
<mhz> yes
<HrdwrBoB> so what does liveCD have to do with it?
<mhz> actually, I am running Edubuntu on this thin laptop because I could only netboot it to install it
<mhz> but from a liveCD... that couldn't do it
<mhz> HrdwrBoB: oh, i see your question. Simple. I wanted to use the LiveCD on the CD drive to be gotten via Tftpboot
<mhz> hwever, I could do it if instead of a LiveCd i Used a Ubuntu Install CD
<mhz> HrdwrBoB: will that tftpbooting work for Dapper?
<mhz> Riddell: so please let me get this straight and forgive if i sound so ignorant, but you're saying that I can place the CD onto the Cd drive and:   a) press enter and start LiveCd,     b) pass an option and start installing from normal current debian-installer     c) start debian installer and choose a hdX to get the ISO from it    d) set up a boot server so thin clients can fetch either the ISO or start netbooting ?
<Riddell> mhz: there will be two CDs, one live one install, only change is the live CD will have an installer and so most people won't need the install
<mhz> ahhhhhhh
<mhz> hehehe, i thought that was gonna be too much mugic on just one cd :D
<mhz> mugic = magic
<infinity> mhz : It's not too much magic (the DVDs do it), it's too much space.
<mhz> infinity: indeed (i meant magic considering space too)
<infinity> mhz : So, yeah, you can't really do a "normal d-i install" and a "livecd / live install" on the same CD, without the base system being tiny. :)
<mhz> indeed
<mhz> lot tiny, i gues
<mhz> infinity: any idea how DamnSmallLinux does it?
<infinity> I'm all for tiny CDs, personally, but users kinda like software being available without hitting the internet. :)
<mhz> or is it a morphix related feature
<infinity> Erm, The "DamnSmall" may be an indication of how they do it.
<minghua> hi infinity :-)  got my Email about the SCIM wiki page?
<mhz> ihehehe
<infinity> We WANT as much software as we can fit on the CDs, so people have a bunch of stuff available.
<infinity> minghua : Yeah, we've not really had a chance to schedule anything here about IM stuff, so you can I will probably have to discuss it out-of-band, which is fine.
<minghua> infinity: I thought so when I saw your (all of you) busy schedule for UBZ :-)
<minghua> infinity: I didn't really expect very easy IM switching on desktop for dapper anyway
<mhz> infinity: IMHO, we should have a basic 'flavoured' Live/Install CD. So, users can see Gnome, Kde, XFCE4, WindowMaker and Fluxbox, plus some defaults generic applications we all use on daily basis (Firefox, XChat, some xOffice, XMMS, etc.) Then, we all can get the rest either from web or specific drive CD (Kubuntu, Ubuntu, etc)
<minghua> infinity: since dapper is projected as a long-supported release
<minghua> infinity: I just want to make sure SCIM is in good shape for dapper
<jsgotangco> mhz: what a fragmented release that would be, no consitency
<mhz> infinity: also that same CD should be usefull for people that simply can't afford to run LiveCd mod but wants to install
<mhz> jsgotangco: why fragmented?
<minghua> jsgotangco: agreed, and I don't think one CD can fit them all anyway
<jsgotangco> mhz: your basic/flavoured live/install cd won't fit on 650MB media
<mhz> jsgotangco: why? Knoppix does provide LiveCD to try many desktops
<mhz> plus try many apps
<minghua> mhz: knoppix don't have any gtk stuff
<jsgotangco> yes
<jsgotangco> that's why amu developed gnoppix
<mhz> oh, well, good point
* mhz forgot last time he used Gnome :)
<jsgotangco> so that's why :)
<mhz> jsgotangco: yes, now i see
<mhz> thx for reminding me about GTK
<jsgotangco> now if we had resources like novell and redhat it would be an entirely different story
<mhz> jsgotangco: a university has asked me to make a live CD based on Edubuntu but my problem is exactly that GTK thing. I need users to try as much as they can. Last time I demoed edubuntu they were very amazed in front of diff desktops (I showed KDE, GNOME, Fluxbox, XFCE4 and WindowMaker -my default one)
<mhz> jsgotangco: why?
<mhz> re demo/ but then I had all already installed
<jsgotangco> mhz: well lp will have the infrastructure to make derived distros easy for everyone to build
<Riddell> mhz: there is not space on one CD for more than one desktop
<Riddell> jsgotangco: novell has resources still?
<jsgotangco> Riddell: or rather, dwindling :)
<mhz> Riddell: but then how knoppix can do it?
<mhz> (i know they do not use GNOME)
<jsgotangco> mhz: vodoo compression
<mhz> hehehehehhe
<mhz> voodopix
<mhz> many students here in chile have old pcs
<jsgotangco> mhz: kde+fluxbox or wm, sure but not kde+gnome in 1 cd
<mhz> so, XFCE4 is probably the most expensive desktop they could run
<mhz> jsgotangco: i agree and understand, I am not thinking of GNOME
<jsgotangco> Riddell: where can i grab the standard KHelpCenter css?
<Riddell> jsgotangco:  /usr/share/doc/kde/HTML/en/common/kde-default.css
<Riddell> /usr/share/apps/ksgmltools2/customization/kde-chunk.xsl
<Riddell> but the web one isn't available
<jsgotangco> ahhh
<jsgotangco> ok this is new territory, i'll check them up thanks
<minghua> Riddell: I heard that Kubuntu is will to add the Qt IM module patch to Qt 3, is that correct?
<minghua> s/will/willing/
<Riddell> minghua: certainly am willing
<wasabi> d-i could really use evms support.
<minghua> Riddell: that would be really cool.  I've recently got messages from the (potential) skim maintainer that his skim package is almost ready
<freeflying> Riddell:who is working on pathing QT IM module to qt 3.3.5
<freeflying> Riddell:who is working on pathing QT IM module to qt 3.3.5
<wasabi> oh hey
<wasabi> http://64.233.161.104/search?q=cache:y3yyON54BFUJ:packages.debian.org/testing/debian-installer/evms-udeb+debian+installer+evms&hl=en
<wasabi> oops
<wasabi> wrong window
<mhz> heheh
<pef> hello
<zyga> morning
<ploum> Hello
<ploum> Where can I find help to fix this bug : https://launchpad.net/distros/ubuntu/+source/flashplugin-nonfree/+bug/3204
<ploum> it seems more widespread than I tought first
<zyga> ploum: hi
<ploum> And I've heard several people that reinstall windows only for this bug :-(
<ploum> Hello zyga 
<ploum> So my goal today is to fix it :-)
<zyga> ploum: works for me ;)
<zyga> ploum: I've checked those urls 
<ploum> zyga, it works for 90% of people
<zyga> ploum: maybe I've got some fonts that you dont
<ploum> zyga, I don't think 
<ploum> Most people solved the problem by installing gsfonts-X11 and mstcorefonts
<ploum> So the fonts used are in those packages
<zyga> ploum: actually that's not a bug (about mstcorefonts)
<zyga> many sites use ms-specific fonts explicitly
<ploum> zyga, yes
<ploum> but for 10% of people, it doesn't work, even with those packages installed !!!
<zyga> ploum: strange
<ploum> And this is a bug
<zyga> did you install breezy from scratch?
<ploum> No, I dist-upgrade from Hoary
<zyga> same here
<zyga> strange really
<zyga> I'm not familiar with the font paths so I don't know where to look
<ploum> zyga, indeed, this is not easy. I'm a bit loss ;-)
<minghua> any possibility this is related to the fontconfig setting override that got implemented at the end of breezy cycle?
<ploum> minghua, I don't know what this fontconfig setting is
<minghua> the one that got rid of aliases of "Times" etc.
<ploum> minghua, hmmm... it smells like you are in the good way
<minghua> ploum: I think let the people run "fc-match <fontname>" in terminal may help
<ploum> can you tell me more or point me to a link ?
<minghua> if you can recognize the font in the flash
<minghua> ploum: it's a very long thread in ubuntu-devel
<minghua> September I believe, search for my name (Ming Hua)
<ploum> fc-match Arial
<ploum> arial.ttf: "Arial" "Regular
<ploum> (on one of the incriminated computer)
<minghua> ploum: and I also have a wild guess here, is it possible to be related to locale?
<minghua> since ms fonts have localized names
<ploum> Hmm... all my computers are under a FR_be locale
<minghua> I said it's a wild guess :-)
<minghua> oh, and mscorefonts had better call fc-cache in postinst
<ploum> minghua, is this the thread about default font in firefox ?
<minghua> ploum: yes, but a big part of it is irrelevant
<minghua> start with my post :-)
<minghua> ploum: I don't know if flash plugin uses fontconfig or core X fonts
<minghua> ploum: but if it uses fontconfig, have the users run "sudo fc-cache -f -v" may help
<minghua> ploum: that's probably all I can help
<ploum> minghua, I will investigate this
<ploum> Thanks a lot :-)
<ploum> flash recommand gsfonts-X11
<ploum> I don't know if this is related
<minghua> ploum: I believe it's *very* related
<ploum> fc-cache: "/home/tamarico/.fonts": skipping, no such director
<ploum> hmm.. this command doesn't change anything
<ploum> It's like a missing symlink somewhere, I'm going mad about it !
<minghua> ploum: did you run fc-cache in sudo?
<ploum> minghua, yes. I just pasted you the last line ;-)
<minghua> ploum: okay, then nevermind
<minghua> ploum: do you have gsfonts-x11 installed?
<ploum> minghua, of course ;-)
<ploum> But in fact, it was installed before the upgrade to breezy
<ploum> hey, someone from my sister university, good morning kuleuven ;-)
<minghua> ploum: well, I'm out of ideas.  good luck :-)
<Chipzz> hi :)
<ploum> minghua, the strangest thing is that only flash seems affected
<ploum> thank for your time :-)
<ploum> minghua, do you think I can bother the mailing list about this bug ?
<minghua> ploum: ubuntu@ ? sure
<minghua> ploum: altough I don't read that list :-P
<ploum> I speak about ubuntu-devel (it's the only one I'm subscribed to)
<minghua> ploum: If I were you I won't do that, but it's your call after all
<ploum> but I ask for advice, so... ;-)
<schweeb> if there's a bug submitted, leave it at that
<schweeb> ubuntu-users is the correct forum for questions regarding how to fix it
<schweeb> if you don't think the bug is enough to suffice
<ploum> hmm.. I found something
<ploum> minghua, I found that a fc-cache $something always return me
<ploum> fc-match Comics
<ploum> Vera.ttf: "Bitstream Vera Sans" "Roman"
<ploum> Vera.ttf
<ploum> except for Arial
<minghua> ploum: oh.  where is your ms fonts installed?
<ploum> minghua, I don't know. I just installed mstcorefonts
<minghua> ploum: did your "sudo fc-cache -f -v" show anything about ms fonts?
<minghua> something like /usr/share/fonts/truetype/msttcorefonts/ maybe
<ploum> fc-cache: "/usr/share/fonts/truetype/msttcorefonts": caching, 60 fonts, 0 dirs
<minghua> then fc-cache should show ms fonts for things like "Courier", "Verdana", etc., no?
* minghua hasn't used ms fonts for quite some time
<minghua> or, and "Times"
<minghua> s/or/oh/
<ploum> ouh !
<ploum> I think I've something weird here !
<ploum> it works in the terminal where I did the fc-cache -f -v
<ploum> but not in others
<ploum> Verdana.ttf: "Verdana" "Regular"
<ploum> 10:51 tamarico@ocean ~% fc-match Courier
<ploum> cour.pfa: "Courier" "Regular"
<ploum> 10:51 tamarico@ocean ~% fc-match Times  
<ploum> VeraSe.ttf: "Bitstream Vera Serif" "Roman"
<ploum> in the good terminal
<ploum> nothing in the others !
<minghua> log out and log in again?
<ploum> (forget it. it was a typo)
<ploum> so fc-match seems correct
<ploum> minghua, I did it with another xterm with xnest. No more success
<ploum> Anyway, thanks a lot for advices 
<minghua> ploum: you are welcome
<mloskot> I'd like to ask someone who could do small review of my first Featue Specification. Simply, have I put it (feature request) to the right place, etc.
<mloskot> Here it is https://launchpad.net/products/gnome-panel/+spec/gnome-panel-menu-browsable-with-keys
<vuntz> mloskot: it was possible to do this some times ago, but something in GTK+ changed and broke the feature
<vuntz> mloskot: http://bugzilla.gnome.org/show_bug.cgi?id=300730
<mloskot> vuntz: that's a crap ;-(
<mloskot> vuntz: But, in general Launchpad usage, is Specification the right place to submit such request as I did?
<vuntz> I'd say "no" since it's a feature request
<vuntz> but I might be wrong
<vuntz> :-)
<vuntz> I think spec should have a bigger scope (although not too big either)
<mloskot> That's right, I asked on #ubuntu-motu and I was told Launchpad is the right place for Feature Request.
<mloskot> You know what I mean, just as Feature Request on SourceForge.net projects.
<mloskot> So, where is the righ place?
<vuntz> well
<vuntz> since there's already a bug upstream, there's nothing to do
<vuntz> just add yourself to the cc bug upstream
<vuntz> and maybe try to fix the bug (it's a bug, in fact)
<vuntz> (since it should work)
<vuntz> if you have some time, you can try to see what's wrong
<mloskot> yes, I will get around it and try to find what is going on, the lack of browse-by-key is annoying for me :-)
<vuntz> btw, I'm one of the upstream guy for this, so if you can find what's wrong, you're welcome :-)
<mloskot> What about this http://bugzilla.gnome.org/show_bug.cgi?id=101309
<mloskot> ?
<vuntz> it's older than the bug I linked, isn't it?
<mloskot> I don't understand this patch (link above). Seems it just caused the menu & keys problem ;-
<mloskot> :-)
<mloskot> Yes, you're right.
<mloskot> vuntz: for now I put there my comment-question about state of this bug, just as a reminder to other involved developers, may be someone will replay. next I try to find a few hours to get in this.
<alessio> sorry, who is an ubuntu member?
<alessio> i have a problem to import my fingerprint on launchpad
<zyga> alessio: what is the problem?
<alessio> Launchpad does not currently support validation of sign-only GPG keys. If you add an encryption subkey (using gpg --edit-key) and upload your key again, you should be able to import the key.
<alessio> bu i have done a subkey
<alessio> and i have resend he key
<alessio> a subkey of this type  (6) RSA (encrypt only)
<zyga> alessio: try asking on #launchpad
<Tuxist> hi
<Tuxist> i have a problem with ubuntu and kernel 2.6.14
<tseng> See topic, unfortunately no support here
<tseng> esp. for software that we dont ship :)
<Tuxist> i cant mount my second harddisk in the #ubuntu channel have linkrd me to this channel 
<Tuxist> my problem is i cant mount my second harddisk
<tseng> their mistake. please stop typing in bold
<tseng> you could also try the forums or ubuntu-users mailing lists
<Tuxist> :'(
<Tuxist> have anybody allready kernel 2.6.14 ?
<siretart> please stop writing in bold
<lifeless> /w/win 41
<mdke> wiki.kubuntu.org is not found, anyone know why?
<Riddell> mdke: that domain name doesn't exist (yet), where did you find that link?
<mdke> Riddell, most recent news item
<mdke> Riddell, so what is the kubuntu wiki address?
<mdke> there isn't one?
<Riddell> silly me, fixed now
<Riddell> wiki.ubuntu.com
<jsgotangco> wiki.ubuntu.com/Kubuntu
<mdke> i thought wiki.kubuntu.com should point to the same place as wiki.ubuntu.com
<zakame> hi all
<mdke> as with udu.wiki and wiki.edubuntu.org
<Riddell> mdke: not yet, soon
<mdke> rockin
<jsgotangco> wiki.edubuntu.org does that thoujgh
<mdke> wiki.edubuntu.org is really nice the way it points to the main wiki but has its own theme
<jsgotangco> only if you're not logged it
<jsgotangco> for some reason if you're logged in automatically the ubuntu css is shown
<mdke> jsgotangco, if you log in, it uses the theme you select in your userpreferences
<jsgotangco> oh wait
<mdke> but if you're logged into wiki.ubuntu.com, the same cookies isn't carried over to wiki.edubuntu.org
<jsgotangco> it's now fixed
<jsgotangco> (i think)
<jsgotangco> when we moved that, we had a problem with the theme
<jsgotangco> the frontpage is locked?
<mdke> jsgotangco, no, just that you're not logged in
<jsgotangco> ahhh oh well it only shows my wiki ignorance :)
<pitti> elmo: can you please sync phpmyadmin from sid? ubuntu override ok
<desrt> dholbach; pong
<dholbach> desrt: we should have another brief conversation with martin
<Keybuk> ... for those not in Montral, mdz is sick ...
<Kamion> ... and then there's the illness
* mdz coughs all over Kamion
<wasabi> SARS?
<mdz> bird flu
<mdke> get better soon mdz 
<mdz> I am in self-imposed quarantine in my hotel room
<mdke> :(
<Mithrandir> mdz: what kind of illness?
<mdz> Mithrandir: just nasal/sinus congestion at the moment
<Mithrandir> mdz: ok. :-/ get well.
<mdz> perhaps a slight fever
<mdz> nothing serious
<Simira> the normal "air condition and strange climate"-illness...?
<Mithrandir> conference syndrome
<Simira> and overworking, yes, right.
<Simira> how are you today, Mithrandir?
<Mithrandir> Simira: doing fine, dear.
<Simira> good
<Simira> want/need anything at the store? I consider going there before the next bof.
<mdz> Simira: in my case it's generally insufficient-sleep syndrome
<Simira> mdz: right. Can I get you anything from the supermarket?
<mdz> Simira: I have medicine already, and that should be enough. thanks for the offer
<mdz> Simira: oh, actually, a box of reasonably soft facial tissues would be grand
<mdz> the ones in the hotel room are like sandpaper
<fabbione> mdz: see the positive side of being able to smooth your face once in a while
<Simira> mdz: sure, they should have that.
<Keybuk> probably too much time spent down here in the hotel dungeons
<magnon> all too much
<zyga> pitti: ping :)
<pitti> hi zyga 
<zyga> pitti: hello
<zyga> pitti: I did not test the performance yet as I have problems with adding correct domain identifiers to .desktop files, check out http://ubuntu.suxx.pl/gettext-support-for-desktop-files/
<zyga> hmm?
<pitti> zyga: did you happen to do do some benchmarking?
<zyga> pitti: yes
<zyga> pitti: I just re-logged in
<zyga> pitti: but I have bad news
<zyga> pitti: gnome-panel has two implementations, one from gnome-desktop and another, internal
<zyga> pitti: it is not slower in nautilus but I cannot make the 'real' test
<zyga> pitti: check out http://ubuntu.suxx.pl/gettext-support-for-desktop-files
<zyga> pitti: I need to track the internal implementation
<zyga> it is really ackward, when I drag a (untranslated) icon from the menu to the desktop it becomes translated
<zyga> (nautilus uses gnome-desktop)
<zyga> when I drag that icon back to the panel it is still translated
<pitti> zyga: hm, I took a look into the dir, but I can't make sense of it
<zyga> pitti: okay it contains some tools
<zyga> check out the readme 
<zyga> you can fetch patched desktop files (generated with those tools)
<zyga> the don't have any localizations and usually contian the correct gettext domain
<zyga> (not alwasy due to problems with rosetta)
<zyga> pitti: if you patch gnome-desktop with the file in patches/ and rebuild you can check out the result :)
<zyga> pitti: it pretty much works and I didn't see any slowdown
<pitti> zyga: right, but I can't do that right now
<carlos> zyga, that's a good feature ! 'Do you want the .desktop file translated? just paste it to the desktop and copy it back to the panel and get the translation for free!'
<carlos> :-P
<zyga> carlos: no ;-)
<zyga> carlos: it is not gaining any translations 
<pitti> zyga: cool, so the slowdown is negligible?
<zyga> carlos: it only proves that the menu is using another implementation 
<zyga> pitti: yes but I'll repeat that after a coold boot that really works 
<zyga> pitti: so ATM it's a <small>yes</small>
<carlos> zyga, we could port it to use the new library instead of patch that one
<pitti> zyga: sounds promising, man!"
<zyga> carlos: I'll check it out but I fully agree
<jordi> zyga: what hw are you using to test, btw?
<zyga> jordi: old amd laptop, 1,6Ghz, 512, 5400 RMP disk with ext3 
<carlos> zyga, anyway, we should check with seb because I suppose GNOME will do that for next release
<jordi> zyga: that's not so bad hw :)
<zyga> carlos: right!
* zyga wants an ibook
<zyga> this crap is falling apart and is hot as hell
<zyga> okay I'll fetch gnome panel and check out where this stuff could lurk
<Kinnison> If I have a string in python which in perl would match "\S+\s+\S+\s+\S+" how can I get the three non-space sequences out
<zyga> seb128: ping
<carlos> (I thought they did already for 2.12
<karlheg> How can I compile a 32 bit binary on amd64?
<karlheg> I tried 'gcc -m32' but it fails in linking.
<Burgundavia> karlheg, that is more a question for #ubuntu
<karlheg> Ok.
<Burgundavia> karlheg, thanks
<karlheg> Actually, it pertains to ia32-libs-gtk.  It is built incorrectly for amd64 32 bit environment.  See: https://bugzilla.ubuntu.com/show_bug.cgi?id=18819
<karlheg> The reason I want to learn to build 32 bit is to try and fix that.
<karlheg> (Saturday project)
<karlheg> Hmmm...?  #ubuntu-toolchain?
* zyga has found the stuff in gnome-panel
<zyga> pitti: it will be working in 5 minutes
<dilinger> heh
<dilinger> nice, sx8.ko makes parted_devices give a FP exception
<vuntz> zyga: I can help with the panel (I'm upstream ;-))
<zyga> vuntz: I see how it works now
<zyga> vuntz: it is using GKeyFile
<zyga> vuntz: for the sake of consistency I'll patch it to support X-Gettext-Domain
<zyga> vuntz: unless there are some reasons why I should not do that 
<zyga> panel-menu-items.c:171
<vuntz> do you plan to move this upstream?
<vuntz> or is it just for ubuntu?
<zyga> it is using g_key_file_get_locale_string
<zyga> vuntz: for upstream when it is good enough
<vuntz> you might want to consider patching the .desktop specification, then :-)
<zyga> vuntz: ah but it is patched
<vuntz> and talk a bit about it on xdg-list
<zyga> vuntz: or rather...
<zyga> this idea was proposed a long time agob
<zyga> but there were multiple concerns
<zyga> (efficiency, dependancy on gettext)
<zyga> I just don't care about the latter and will worry about the former when it strikes
<zyga> so far it works and works fine
<vuntz> brb
<zul> ls
<vuntz> it won't  get upstream if it's not accepted on xdg, though
<magnon> pitti: when do you think you have the jack merge? or, could you perhaps send me a package before you upload?
<zyga> vuntz: once it works I'll bring the issue to xgd mainling list again
<zyga> vuntz: after reading carlos' attempts I've decided that it's not worth it 
<zyga> we need that stuff here and now, upstream is secondary to working implementation :)
<carlos> vuntz, we need some real examples before trying again to push this to upstream
<zyga> carlos: exactly!
* zyga is amazed by the amount of duplication in something as important as gnome-panel :)
<zyga> (amazed by the proabable duplication)
<vuntz> duplication? where? :-)
<carlos> zyga, i suppose they were not able to port to the new implementation on time
<zyga> vuntz: gnome-desktop vs gkeyfile
<vuntz> zyga: well, we try to not use gnome-desktop anymore
<zyga> gnome-panel uses both to read .desktop files
<zyga> vuntz: ah I see
<zyga> so it's a transition
<vuntz> zyga: in fact, it uses gnome-desktop only for the launchers on the panel
<vuntz> not for the menu
<vuntz> but there's one useful function in gnome-desktop, used to launched the applications
* zyga is 30% done patching gkeyfile
<vuntz> hrm
<carlos> vuntz, I thought gnome-desktop was the new implementation ....
<vuntz> carlos: no :-)
<vuntz> zyga: are you patching the panel using GKeyFile or glib?
<vuntz> carlos: we didn't have GKeyFile at first
<carlos> vuntz, where is that new implementation now?
<vuntz> now, with GKeyFile, it's easy to parse the .desktop files
<carlos> I suppose it should be a library
<vuntz> carlos: GKeyFile, in glib
<carlos> ok
<vuntz> brb
<zyga> vuntz: glib
<carlos> vuntz, then, if you want to read .desktop files you use GKeyFile that is not specific to .desktop files, right?
<zyga> vuntz: I think that someone should port gnome-destkop to use gkeyfile
<carlos> hmm, that means we need to patch all applications that use .desktop files instead of just one common library
<zyga> and that gnome-panel should use gnome-destktop but I'm just an outsider
<zyga> carlos: it's not that bad, I'm patching the gkeyfile so it should just work
<carlos> zyga, but does gkeyfile supports i18n?
<zyga> carlos: yes
<carlos> ok, then it's not so bad
<carlos> then we need to patch glib, right?
<zyga> yes, I'm doing that
<carlos> ok
* zyga hates constant strdups in g* stuff
<zyga> vuntz: did you guys ever concider using a string class everywhere?
* zyga builds glib :)
<vuntz> zyga: a string class? something like GString?
<vuntz> zyga: the goal is to get rid of gnome-desktop
<vuntz> kill a library
<zyga> vuntz: why?
<zyga> vuntz: and, yes, in reverse order
<vuntz> zyga: we don't need to have so many libraries
<vuntz> zyga: gnome-desktop was useful because we didn't have GKeyFile
<zyga> vuntz: don't you think it's useful to have something that can read .desktop files even if that is a thin wrapper around gkeyfile?
<zyga> vuntz: hmm
<zyga> vuntz: do you know the internals of gstring well?
<vuntz> zyga: gkeyfile can read .desktop files
<vuntz> and I don't know the internals
<zyga> vuntz: yes but it can read them as key-value-group tripples, not as desktop files
<zyga> if the format ever changes it would be difficult to modify everything that uses gkeyfile
<vuntz> ideally, this should be in glib, then
<zyga> vuntz: well the exact place is not relevant, semantics is
<vuntz> right
<ompaul> is launchpad the correct place for kernel bugs?
<Mithrandir> no, use bugzilla
* Keybuk considers changing his nickname
<robertj> hrmm, ubuntulog needs a !tail option ;)
<highvoltage> and !grep
<robertj> high: I've often been tempted t write a /nickgrep command
<robertj> in fact, it would be even better if you go that by hovernig over a user's name
<highvoltage> hovernig?
<highvoltage> hovering?
<zyga> yay
<robertj> typo/lazyness
<zyga> novel to standardize on gnome :-)
<Mithrandir> zyga: novell, even. :-P
<zyga> kde even ;-)
<Riddell> zyga: offtopic
<highvoltage> Riddell: ah, finally, i catch you on IRC.
<Riddell> highvoltage: have you been trying to?
<highvoltage> admittingly, not to hard.
<highvoltage> we should start a http://wiki.clug.org.za/index.php/JOCUAMAOE for Ubuntu.
<highvoltage> there's lots of Jonathan's in Ubuntu.
<Riddell> highvoltage: :)
<robertj> I'm surprised to hear about SUSE's decision
<Keybuk> which one?
<robertj> Keybug: standardizing on Gnome
<robertj> I thought they were a KDE house
<robertj> I guess Ximian had a greater effect on them than I supposed
<fabbione> robertj: this is offtopic here
<robertj> sorry
<darklinux> hi
<darklinux> how can i make a packet of kicker only
<darklinux> in the src of ubuntu is not a debian directory
<Riddell> darklinux: KDE kicker?  we have a kicker package
<darklinux> not with kbfx hack ;-)
<darklinux> http://www.kde-look.org/content/show.php?content=26681
<Riddell> darklinux: kbfx is a separate applet, it would be packaged separately
<Riddell> it's also a good diea very badly done
<Riddell> darklinux: but feel free to package it and post it on revu
<darklinux> ok
<Riddell> darklinux: search for existing debian/ubuntu packages first, don't want to duplicate work
<darklinux> the problem the kbfx have no setting to setup the menu
<darklinux> when you follow the link you know what i mean
<darklinux> i have make kernel 2.6.14 packages for amd64 how can i upload them
<spayne> darklinux: the Kernel maintainer will do that
<darklinux> ok
<Mithrandir> mdz: I'll be interested in getting vbetool to work correctly on amd64 for dapper; do you want a spec for it or can I just hack on it?
<mdz> Mithrandir: hack away
<Mithrandir> mdz: coolie, thanks.
<zyga> pitti: it works :-)
<spayne> Riddell, ping
<pitti> zyga: yay
<zyga> 5 minutes seemed like 5 hours :)
<zyga> but it works okay :>
<Riddell> spayne: hi
<zakame> zyga: hihi :D
<zyga> I'll remove debug, check, and restart :)
<spayne> Riddell, is sabdfl using KDE now?>
<crimsun> spayne: from the announcement on kubuntu.org, I'd so yes
<crimsun> s/so/say/
<zyga> pitti: next langpack upgrade on my dapper box will upgrade desktop files, FINALLY!
<zyga> err?
<spayne> crimsun, is he trying it out or actually using it?
<zyga> ubuntu is not going to shift to kde is it?
* Riddell wonders which part of this is unclear
<crimsun> zyga: I highly doubt it will shift
<spayne> Novell is shifting to GNOME
<zyga> pitti: do you know why Icon can be localized?
<Riddell> OFFTOPIC
<zyga> is there any actual locale dependend icon?
<pitti> zyga: in theory probably
<zyga> okay
<zyga> pitti: sample log: http://ubuntu.suxx.pl/gettext-support-for-desktop-files/gnome-panel-startup-log
<zyga> just for the record
<zyga> I really feel bad about multiple implementations
<zyga> so far we have three patches :/
<zyga> pitti: should I file a bug report against glib and attach this patch?
<pitti> zyga: that would be nice
<pitti> zyga: eventually, gnome upstream will completely migrate to the glib function anyway, and drop the stuff in libgnome-desktop
<zyga> pitti: so I've heard
<zyga> pitti: I'm building the package again and I'll test after cold boot
<zyga> pitti: done
<zyga> pitti: https://wiki.ubuntu.com/LangpacksDesktopfiles
<zyga> wiki updated, bug created, patch attached
* zyga goes to check startup time :)
<zyga> okay, performance is good
<zyga> carlos: ping :-)
<zyga> carlos: performance is pretty good so we'd better find a way to build a better mapping.txt :>
<carlos> zyga, coool
<slomo> lamont, infinity: please give-back banshee... was missing a dep which is in now :)
<lamont> slomo: if it was depwaited for a missing depend, then those get cleared once the depwait is installed.
<lamont> iz automatic
<zyga> pitti: it works fine :)
<slomo> lamont: ok, thanks :)
<zyga> pitti: after cold boot everything was up and running in 38 seconds since login
<pitti> zyga: without noticeable performance regressions?
<zyga> I had some stuff in gnome-session so I'll retest
<zyga> pitti: some
<pitti> zyga: two seconds at login don't matter
<zyga> pitti: my .desktop files don't have the original translations (to be sure)
<pitti> zyga: I'm more concerned about delays when opening and scrolling through the menu
<zyga> pitti: no delay there
<pitti> coool
<zyga> pitti: gnome-panel reads everything at startup so there is no change there
<pitti> so the panel indeed seems to generate all translations at startup
<pitti> ah
<zyga> yes
<pitti> that's so great
<pitti> carlos, jordi: life is good.
<zyga> anyway the only regression is that not everything was translated due to the method of automatic .desktop patching I've used
<zyga> pitti: once we got perfect mapping.txt we are done :)
<pitti> zyga: mapping.txt?
<zyga> pitti: it is generated by rosetta's export
<zyga> it maps from package to domain :)
<pitti> zyga: ah, don't worry
<zyga> that is not a 100% good solution but we can fix remaining stuff from main easily
<pitti> zyga: https://wiki.ubuntu.com/LangpacksDesktopfiles
<pitti> zyga: we will fix the .desktop files itself
<zyga> pitti: that's what I did but I went for automatic update
<zyga> pitti: I can easily patch existing .desktop files that I know
<zyga> anyway, I'll revert and time again
<zyga> then (without any session noise) upgrade and time the new stuff
<zyga> so we have a clear ida
<zyga> idea
<zyga> pitti: hmm what will we do with something like firefox?
<zyga> it is not using gettext at all so no .potfile and no domain
<seb128> pitti: panel behaves poorly is not a reason to do the same with other pieces of code instead of fixing it :)
<zyga> seb128: ?
<seb128> <pitti> so the panel indeed seems to generate all translations at startup
<seb128> that's one of the reason why it's slow to start
<seb128> that should be fixed
<zyga> seb128: yeah but it's hard to avoid that 
<seb128> cache
<zyga> seb128: ah
<zyga> seb128: true :)
<pitti> mmm caching 
<pitti> but this is pretty orthogonal to our problem, isn't it?
<seb128> pitti: was random comment, I don't know what your problem is exactly on this discussion
<seb128> I just point that the panel/menus are slow to start and we want to address that one day
<pitti> ah, cool
<sabdfl> fabbione: clusters is +1
<fabbione> sabdfl: rocking!
<sabdfl> fabbione: :-)
<sabdfl> very nicely done
<sabdfl> please thank ivan
<sabdfl> and youself
<fabbione> sabdfl: i will..
<fabbione> thanks
<sabdfl> seb128: MenusRevisited is +1
<seb128> sabdfl: rock, thanks
<sabdfl> seb128: and very classy, very crisp. appreciate it
<seb128> sabdfl: nice, thanks again :)
<sabdfl> fabbione: server-candy is +1
<sabdfl> again, hugely improved. thanks for the clean-up
<jordi> pitti, zyga: that's just great
<zyga> jordi: yeah :-)
<zyga> jordi: I'm patching .destkop files manually just to have realistic tests in the next run but I didn't see any difference really
<fabbione> sabdfl: cool! 
<fabbione> sabdfl: let's get out now and get drunk to death :)
* zyga waits for reiser4 to read 500-byte-files fast
<zakame> hihi
<sabdfl> Riddell: SimplifyKDE is +1
<Keybuk> Kamion: udev-roadmap me up
<Riddell> sabdfl: awooga, thanks
<whiprush> Riddell: mind if I lift your Kubuntu announcement for the Fridge?
<Riddell> whiprush: please do
<elmo> <jdub> whiprush: inappropriate, dude
<whiprush> ?
<whiprush> heh
<Mithrandir> my eyes.
<Mithrandir> jdub is merging into random people here.
<Simira> ouch!
<Simira> jdub: stay off Tollef!
<Mithrandir> Simira: I shall smite him with my laptop if he tries to merge with me.
<Simira> *sigh*
<sabdfl> mvo around?
<Riddell> sabdfl: is Kamion anywhere with you?
<sabdfl> he's on his way to DapperReleaseProcess
<whiprush> Riddell: publish. (also, don't be afraid to send Kubuntu stuff you want run my way)
#ubuntu-devel 2005-11-11
<Riddell> whiprush: I'm not afraid I just can't be bothered to dig out the e-mail addres so far, you need a web form toot sweet
<whiprush> Riddell: jdub is the guy with that access.
<whiprush> also, you can click "contribute" on the left and there's a submission thing
<whiprush> where you can preview, edit, etc. etc.
<Riddell> whiprush: I see no contribute link
<whiprush> hmm
<whiprush> Riddell: I think jdub needs to add you or something. 
<Riddell> jdub: add me!
<Riddell> how do I log in?
<sabdfl> mpt: ping
<sabdfl> seb128: ping
<robitaille> Riddell,  jdub needs to create an account for you.  Then you go to http://fridge.ubuntu.com/user
<Riddell> jdub: poke poke
<Keybuk> whiprush: jdub is looking for you and is somewhat angry
<whiprush> Keybuk: about?
<mvo> sabdfl: you was looking for me earlier?
<Riddell> mvo: kubuntu-package-manager changed implemented
<mvo> Riddell: looking at it now
<sabdfl> mvo: yes, i just wanted to close the loop on the UI for turning on the commercial channel in Add Applications
<seb128> sabdfl: pong
<mvo> sabdfl: ok, would you like to be more specific in the spec (or change anything)? or change something in it?
<sabdfl> seb128: DapperDesktopPlan is approved, with one outstanding issue
<seb128> sabdfl: I'll have a look, thanks
<sabdfl> mpt's comment regarding the clickability of the [x]  on the updates notifier alert panel
<sabdfl> we should consider that, and get mockups
<sabdfl> i'd like it to look classy
* zyga goes to bed
<Keybuk> Kinniwinnibums: approved
<Kinnison> Keybuk: wuv yoo
<Keybuk> *ELBOW SEX*
<Kinnison> yay
<mpt> sabdfl, where should such mockups be posted?
<mpt> on a separate wiki page?
<slomo> lamont, infinity: please remove banshee from dep-wait for amd64... the missing build-dep is no longer needed
<lamont> slomo: that's one that _does_ require us.  thanks
<slomo> lamont: hehe np :) you will make Nafallo_away very happy ;)
<mpt> They're dropping like flies!
<Aegir> :o
<siimo> hi does ubuntu's nautilus / metacity use some sort of patch that speed up nautilus desktop icon behaviour?
<siimo> i'd like to know how to access the cvs to find this out myself.. 
<tseng> there is no cvs
<tseng> the source packages are right on the mirrors with everything els
<siimo> oh ok thanks
<tseng> packages.ubuntu.com
<tseng> this will give you links to the diff.gz for every package
<siimo> thanks i found it :)
<Nafallo> infinity: ping
<Mez> Nafallo, it's 2:23 am here :D
<zakame> hi all
<Nafallo> Mez: baah. you're still online so... ;-)
<Nafallo> morning zakame 
<Mez> Nafallo, for the simple reason I've been in the bar drinking with Daniel Silverstone
<zakame> afternoone Nafallo :)
<Mez> everyone had already gone to bed
<Nafallo> Mez: hehe, ETA till infinity/lamont wakes up? :-)
<Mez> 6-7 hours
<Mez> most ppl are meeting for breakfast in about 6
<Mez> so give it an hour and ahalf after that
<Mez> and bingo
<Mez> bobs your uncle
<Mez> anyways,
<Mez> night all
<Nafallo> oki, so that makes it 15-16 sometime local ;-)
<Nafallo> Mez: gnight dude, and thanks :-)
<zakame> night Mez :)
<SuperLag> tseng: you around?
<zyga> morning
<zyga> has anyone seen ogra?
<shutdownrunner> I'm looking for sb, who could devote 2 minutes to me and help me make a deb package of screem. I mean I have problem with the last stage namely dpkg-buildpackage.
<HiddenWolf> shutdownrunner, your best bet is #ubuntu-motu. this is for main development.
<shutdownrunner> cze marcin
<shutdownrunner> aha. thanks HiddenWolf
<marcin> shutdownrunner: hej.. niestety zaraz znikam - chcialem posiedziec na ircu ale rodzina nie pozwala :|
<marcin> shutdownrunner: I hope that you understand Polish - more than 'cze' ;)
<shutdownrunner> jestem z Wawy:)
<marcin> shutdownrunner: aaa no to wiele wyjania ;)
<marcin> shutdownrunner: see you
<HiddenWolf> shutdownrunner, please keep it in english, thanks.
<pef> hello
<N6REJ> how do I find out how to package and submit a widget for possible inclussion?
<N6REJ> anyone?
<mdke> https://wiki.ubuntu.com/DeveloperResources is a good start
<N6REJ> ok, ty!
<N6REJ> its nothing fancy but someone besides me might like it.
<dunkelgeist> any translator in here?
<melodie> hello :)
<dunkelgeist> hi
<dunkelgeist> i'm trying to find some help to make a translation of ubuntu
<dunkelgeist> i want to translate it to a language that doesn't appear in the rosetta list
<dunkelgeist> and don't know how to add it to start doing something
<melodie> does someone know how come the 2.6.12-9-k7 kernel in my system, and no kernel-source related on the repositories ? does the 2.6.11_2.6.11-7 stand for it  please ?
<Lathiat> dunkelgeist: you could file a bug against rosetta
<dunkelgeist> eeem...
<dunkelgeist> sorry i don't understand you
<dunkelgeist> my english is a little poor...
<Lathiat> melodie: thats a #ubuntu question, thsi channel is for development, but fyi the package is linux-source not kernel-source
<Lathiat> dunkelgeist: hold a second
<dunkelgeist> ok, thx
<melodie> ok Lathiat thank you
<Lathiat> dunkelgeist: im not sur if it sthe right thing to do, but if you goto https://launchpad.net/products/rosetta/+bugs you can report a bug on rosetta that it should let you translate in your language
<dunkelgeist> hmmm
<dunkelgeist> so in that list there are meant to be all the languages that exist?
<Lathiat> dunkelgeist: i dont know, probably not
<Lathiat> dunkelgeist: what language?
<dunkelgeist> tamazigh
<dunkelgeist> its the language that people from the riff (north africa) used to speak
<dunkelgeist> now it's prohibited by the moroccan king
<dunkelgeist> but it exists
<dunkelgeist> and a lot of people speaks it
<melodie> Lathiat, excuse me, on the forums no-one seems to know the difference within linux-sources and kernel-sources: is there a difference that can be observed ? :)
<dunkelgeist> in rosetta there is tamashek, that is the language of the tuareg people, very similar but not the same
<Lathiat> melodie: just a different name thats more specific
<Lathiat> dunkelgeist: well, only thing I can say is file a bug and someone who knows what to do shoudl be able to help
<dunkelgeist> thx Lathiat
<melodie> Lathiat, this gui on #ubuntu says : " i suppose linux-sources are the sources for the whole distro, while kernel-sources are the sources just for the kernel"
<dunkelgeist> i'll do it right now
<Lathiat> melodie: can we move this to #ubuntu please, i will join there
<melodie> Lathiat, with pleasure, thanks :)
<dunkelgeist> ok, that's it, now i just have to wait i suppose
<Lathiat> dunkelgeist: yep, you should get email when the bug is changed
<jsgotangco> hey zakame 
<zakame> heya
<HiddenWolf> jbailey, ping
<tseng> SuperLag: yes
<jsgotangco> heya tseng 
<tseng> hi jerome
<jsgotangco> nice weekend to you :)
<Lathiat> hrm, since breezy-backports is listed in the default sources.list , can w eat least get a blank archive created or something  
<mdke> heh
<mdke> so many people have been saying that for so long, my hope is gone
<mdke> it's a pretty large bug though
<Lathiat> elmo: about?
<Lathiat> mm i'll email
<jbailey> HiddenWolf: pong, but only here for 2 or 3 minutes.
<HiddenWolf> jbailey, what's up with that lsb compliance spec
<HiddenWolf> "we won't comply?"
<HiddenWolf> or "let's comply, it's easy, but useless save for PR"
<Mez> If I see elmo at breakfast I'll poke him
<Lathiat> okw
<Lathiat> ell i emailed him
<jbailey> HiddenWolf: Mostly a cross between the two.
<HiddenWolf> jbailey, so why is it even a spec? :)
<jbailey> HiddenWolf: It ought to be easy to comply.  It looks like we might be compliant, but we shouldn't care enough to fix it if we're not.
<jbailey> HiddenWolf: Ask whoever created it.  I was merely assigned to it, and that spec is the result of the bof.
<jbailey> Sometimes the answer to a bof is "don't do this"
<jbailey> Here's the basic problem I had:
<jbailey> The testsuite is horribly broken.
<jbailey> There are a pile of errata against it.
<jbailey> But the fact that the testsuite is that broken implies a few things:
<jbailey> 1) They didn't actually *test* the testsuite.
<jbailey> 2) Some people have probably certified against the broken testsuite.
<jbailey> So therefore certification against it is probably meaningless anyway.
<Lathiat> lsb testsuite?
<jbailey> Yeah.
<Lathiat> righto
<Lathiat> just try to comply with LSB as best as possible wthout using the crappy test suite? :)
<Lathiat> seems silly to have a crap test suite
<jbailey> Lathiat: We likely already *do* comply with what they intend, given the versions of software we have on the system.
<Lathiat> me nods
<Lathiat> with a / in there
<jbailey> Lathiat: So compliance becomes a side effect.  Certification would be interesting, but not worth committing resources to right now.
<jsgotangco> wow
<jsgotangco> i like 1) then
* Lathiat nods
<jbailey> Anything else before I go?
<jsgotangco> spread love to the world
<jbailey> Always! =)  Peace, friends.
<tseng> infinity: lamont-away please clear dep-wait for galago-sharp
<tseng> infinity: lamont-away and banshee
<Treenaks> tseng: good morning
<tseng> morning Treenaks 
<Treenaks> tseng: I _think_ most people are trying to cope with their hangovers 
<tseng> clever
<Mithrandir> tseng, treenaks.  :-)
<Treenaks> Mithrandir: GOOD MORNING
* Treenaks actually has a lot of pics on hit laptop atm
<Treenaks> his
<Treenaks> but only 14kb/s up
<Treenaks> so no go for my UBZ-gallery yet
<ajmitch> hi
<Mithrandir> anybody know if (and if so, how) I can get python to not save the byte-compiled file on disk?
<Treenaks> Mithrandir: it only does that for included files by default right?
<Mithrandir> yes
<Mithrandir> well, imported.
<Treenaks> yeah.. I'm using C-sp33k
<Mithrandir> I could possibly work around it by copying the file to a memfile and run execfile on that.
<Treenaks> I've seen people do all kinds of tricks for this
<Treenaks> but there must be a simple command line option or something similar
<Mithrandir> you would think so
<Treenaks> Mithrandir: make the directory non-writable ;)
<Mithrandir> Treenaks: not an option, really.
<Mithrandir> I'm pondering just looking at the python source
<HiddenWolf> Some weekly bug summary info for bugzilla.gnome.org. Last updated: Sun Nov 6 15:00:22 UTC 2005.
<HiddenWolf> Total Reports: 18620 (605 reports opened and 395 reports closed in the last 7 days.
<HiddenWolf> youch
<Treenaks> tijd voor werk ;)
<HiddenWolf> Treenaks, LANGUAGE. ;)
<kikidonk> is dapper drake going to break severly during the devel stage, like breezy did, or is it "safe" to use dapper ?
<Lathiat> it will probably break to varyign degrees during the cycle, its by no means safe
<kikidonk> well i understand the risks
<kikidonk> but breezy did some nasty things with Xserver for example
<kikidonk> Lathiat: are you running dapper drake for example :)
<tseng> I am
<kikidonk> and ?
<Lathiat> kikidonk: yes and it broke my kde, so yeh :)
<kikidonk> lol
<tseng> Lathiat: oh man. i tried kde, it was so broken that it broke gnome
<tseng> it did some crazy evil stuff to my gnome theme settings
<kikidonk> ok, so it's generally broken :)
<Lathiat> tseng: heh
<tseng> no.. just kde :)
<Lathiat> it does have some gtk compat thing
<kikidonk> oh !
<Lathiat> to make the theme the same
<Lathiat> no idea what it does exactl
<kikidonk> kde is broken anyway :P
<tseng> yeah it went nuts
<Lathiat> woo kde
* Lathiat waves a flag
<kikidonk> i'm really wanting to give it a try
<kikidonk> but i'm afraid :)
<tseng> kikidonk: gnome stuff works great
<kikidonk> there is no easy way back, i suppose
<tseng> hm
<tseng> Places -> Search for Files should be beagle --no-tray in dapper+1
<tseng> s/beagle/best
<zyga> carlos: hello
<zyga> carlos: I had some good results and some bad experiences with .desktop files 
<pitti> zyga: looking forward to hear about them :-)
* zyga is really displeased with the amount of crappy .destkop files around, and with pachages totally neglecting i18n
<zyga> pitti: short we can give it a go :)
<zyga> I've patched most of default install to include correct domains
<zyga> s/pachages/packages/
<zyga> pitti: if you see ogra around bash him for hwdb-client without i18n ;-)
<zyga> tseng: do you know beagle well?
<hile> FYI, first somehow working version of initramfs-cryptsetup for dapper (additional hook package to support cryptsetup encrypted root filesystem on dapper) http://ner.dy.fi/deb/
<hile> just a tiny script ... WorksForMe(tm) ;)
<dilinger> hile: i'll give you a cookie if you can get it to allow filesystems to not automatically be mounted, but instead have mount prompt for a password when manually mounting it
<dilinger> one of my pet peeves wrt the cryptsetup stuff that's in sarge
<hile> well, that's completely different thing, this is only for root filesystem ....
<dilinger> ah, ok
<hile> but yeah, I'd like to have at least LUKS detection and passphrase questions directly in mount/umount (detach the dm-crypt volume when umounted as well)
<hile> so, with LUKS-partition, you could just say mount /dev/hda9 /foobar and it would detect encryption etc.
<hile> someone is working on a patch, no idea about the status of these patches
<infinity> hile : Please file bugs in either the Debian BTS, the Ubuntu bugzilla, or both, so I can track the patches.
<johannes> does anyone know if the alsa-driver/libs in the repos. were compiled with pcm.jack support? im trying to get alsa apps to use jackd by default by configuring /etc/asound.conf, according to: http://gentoo-wiki.com/HOWTO_Jack#Configuring_software_to_use_JACK
<hile> infinity: it's not a patch, it's new package
<hile> there are already a couple of bugs for this in ubuntu bts
<slomo_> is someone with a G3 here?
<vuntz> carlos: ping?
<hile> ubuntu bugzilla #15662 at leest was one of the bugs ...
<carlos> vuntz, pong
<vuntz> carlos: I'm looking for your instructions to vote in the referendum. Do not leave :-)
<carlos> vuntz, cool, thank you!
* zyga is really angry and starts looking for a breezy dvd
<vuntz> carlos: see /query
<tseng> zyga: yes i "know" beagle
<zyga> tseng: is it possible that beagle deletes something in $HOME ?
<tseng> zyga: anythings possible, but i doubt that
<zyga> tseng: I've installed beagle and all of a sudden I've lost all evolution emails and epiphany bookmarks 
<zyga> and yes, both directories have been purged
<tseng> i dont even recall it doing anything with epiphany bookmarks
<tseng> above and beyond parsing plain text
<tseng> it does everything with evolution via libevolution-cil
<zyga> I was playing with varios command line beagle stuff to find configuration
<tseng> and im not sure it even *looks* at any dotfiles
<zyga> then I'm out of ideas
<msg43> Hi
<dtf> Is dapper ready for firefox 1.5rc1? I've been hacking on the debian package in exp this weekend.
<msg43> I was wondering how you guys hacked the gnome shutdown menu.
<pitti> dtf: Diziet|ubz did a fair amount of hacking on it already
<dtf> pitti: is there a package any where?
<pitti> not a public one yet
<dtf> I've got a working .deb and I am add branding and patches now
<Kamion> JTE rocks; I just built a full breezy install CD set with source CDs and jigdo files in 15 minutes, as opposed to the hour or so it used to take
<pitti> wow
<pitti> dholbach!
<msg43> I was wondering how you guys hacked the gnome shutdown menu?
<seb128> with emacs
<pitti> VIM RULEZ
<carlos> seb128, you don't have enough fingers to use emacs!
<pitti> msg43: (just don't expect serious answers after a long party night after a long work week at UBZ :-) )
<msg43> pitti, I'd really like to know
<pitti> msg43: we added a patch to support powermanagement-interface
<seb128> msg43: the question is not clear enough
<msg43> pitti, were can I find this patch? I use another distro than ubuntu
<highvoltage> seb128: good answer (emacs) ;)
<seb128> msg43: basically gdm is patched to use pmi and gnome-session to speak to gdmflexiserver to get the capability from pmi
<msg43> oh
<seb128> msg43: that's quite ubuntu specific
<msg43> so its not easy
<msg43> dam
<seb128> msg43: pmi is an ubuntu hack for power management
<msg43> I got a script to suspend my system
<seb128> msg43: no, not trivial
<pitti> pmi isn't particularly scary
<pitti> just a shallow shell script for different arches
<msg43> oh I see
<msg43> I really like ubuntu because it a great easy linux system
<msg43> I would use it if there was no such thing as archlinux
<seb128> msg43: is that a "build from source" distro,
<seb128> ?
<msg43> seb128, no I hate build from source distros. Archlinux is a bit like slackware and a bit like gentoo. It uses a package management system called pacman which as similarites to apt-get.
<msg43> When you install arch it install the basics, then you have to configure your fstab and that stuff
<seb128> yeah, but like slackware and gentoo you need to build your packages
<msg43> then you just do pacman -S package
<msg43> seb128, yeah thats true
<msg43> with arch you don't
<msg43> and arch uses what is called "rolling updates"
<msg43> thus you never had to reinstall to upgrade your system
<seb128> k
<seb128> anyway I've to go for now
<seb128> bbl
<opi> Hi there, any Ruby/Ubuntu hacker around? I just noticed that standard Ruby build on Breezy is missing mkmf.rb, and thus I can't configure/gem any new packages
<opi> OK, fixed it ;)
<gordo> ho
<gordo> hi*
<pitti> Hi sabdfl! Alive again? :-)
<zyga> just for the record, I don't know what has happened in the last 5 hours but after installing beagle I've lost: my mail, my contacts *AND* my gpg personality... 
<johannes> does somebody know if the alsa-drivers/libs in the repos. were compiled with jack pcm support? i'm trying to configure asound to use jack by default, so that all alsa apps can use jack. or is this possible? it seems to be in Gentoo at least: http://gentoo-wiki.com/HOWTO_Jack#Configuring_software_to_use_JACK
<kent> johannes: Since you are a swede - you are more than welcome to join us in #ubuntu.se  - we cant help you but we take pride in huge idle-time and OT-talks.  :)
<kikidonk> tseng: jumping in dapper right now, hoping that everything keeps working :)
<tseng> nice
<kikidonk> fear, fear
* Treenaks gets the "sightseeing in Montreal" photos from his camera
<Treenaks> (day 1)
<Treenaks> over the next few weeks, I'll do videos as well :)
#ubuntu-devel 2005-11-12
<tseng> awesome
<daniels> jbailey: will you be terribly annoyed with me if I upload glibc?
<daniels> Unpacking libc6-dev-amd64 (from .../libc6-dev-amd64_2.3.5-1ubuntu12_i386.deb) ...
<daniels> i'm rather scared now
<kikidonk> tseng: do you still have your evolution contacts with evo 2.6 ?
<kikidonk> or is there some manipulation to get them bakc
* lamont-away finally arrives homne
<daniels> lamont-away: 'finally'?
<lamont-away> well, 'twas a long-ish day
<lamont-away> not as long as, say ours.
<lamont-away> er, yours
<daniels> well, just one day makes it not long at all ;) i arrived two days after I left
<daniels> tseng: so what is it you said that monodoc was waiting on?
<daniels> tseng: dbus 0.50-1ubuntu1 is failing everywhere due to monodoc stuff; I forgot that before I uploaded
<bmonty> anyone here use gnat?
<daniels> pitti: 'morning
<pitti> Hi daniels! Had a safe trip home?
<daniels> yeah, fine thanks.  how was dinner?
<pitti> daniels: funny. We had a good time figuring out who was who, given a small story/fact about everyone
<pitti> daniels: and before we wandered through the city for two hours solving questions in teams
<daniels> pitti: heh, cool
* desrt home!
<tseng> daniels: new monodoc uploaded a few days ago
<tseng> daniels: hm ill look at that tonight
<daniels> ts	ta
<justnulli> what happend to libapache2-request-perl in breezy?
<HiddenWolf> daniels, what's that supposed to mean?
<daniels> tseng: ta
<daniels> HiddenWolf: that irssi's paste detection semantics still bite
<HiddenWolf> daniels, you're the xorg guy, use something graphical and flashy. :)
<HrdwrBoB> HiddenWolf: as opposed to say, functional
<HiddenWolf> HrdwrBoB, of course! ;)
<daniels> HiddenWolf: gnome-terminal?
<HiddenWolf> daniels, =)
<daniels> reminds me of bero, who used to be the red hat kde maintainer
<daniels> never really used X much.  had something ludicrous like 17 VTs.
<HiddenWolf> bug report "konqueror is broke" -> him: "what's konqueror?"
<HiddenWolf> Right, i'm off, selling ubuntu. :)
<highvoltage> HiddenWolf: good luck
<HiddenWolf> highvoltage, thanks. :)
* HiddenWolf off
<dtf> I am trying to wrap my head around dpatch. What is a good example package the uses dpatch well?
<poningru> can someone update this
<poningru> http://www.ubuntulinux.org/community/bounties/
<poningru> its really really old
<lucas> hi
<HiddenWolf> jdub, ping
<lucas> how do ubuntu works wrt to translations ? for example, the french translation is far from being usable by non-english-speaking people.
<lucas> Are the packages going to be updated during the breezy lifetime ?
<HiddenWolf> lucas, language packs are imported from Rosetta. https://launchpad.net/rosetta
<HiddenWolf> lucas, yes
<lucas> yeah, but how often ?
<HiddenWolf> lucas, when there's a significant change
<janimo> HiddenWolf so breezy-updates can contain translations too not just security/dataloss fixes?
<lucas> ok
<HiddenWolf> janimo, that's the plan. But they won't be updated for a couple of strings.
<lucas> thanks HiddenWolf 
<HiddenWolf> lucas, so your best bet is to poke #ubuntu-fr to translate ubuntu on rosetta, and then badger someone here to update the language packs
<maswan> Whee, the breezy release made front page of the newsletter of SUNET (our NREN)
<lucas> HiddenWolf: ok
<Nafallo> lol
<maswan> in swedish: http://basun.sunet.se/sunetten/Nr-2005-5.pdf
<Nafallo> maswan: *asg*, hacker-attack? maybe you should tell them about dapper already ;-)
<maswan> Nafallo: Just a communication issue, I told my netmasters, they didn't tell their upstream. :)
<Nafallo> :-)
<Nafallo> so when the real hacker-attack comes they will think Ubuntu is released and ignore it *evil grin*
<lucas> what's the template name for the translation of the "system" menu in gnome ?
<lucas> it seems it's not gnome-panel
<HiddenWolf> ask #ubuntu
<Nafallo> lucas: should be control-center AFAIK
<lucas> doesn't seem so
<lucas> do you know if it's possible to search for a string, like "Log out" ?
<HiddenWolf> that's definatly control center
<WaterSevenUb> lucas, #ubuntu-translators
<Nafallo> not that I'm aware of, you might wanna talk to #launchpad though
<lucas> ok
<Nafallo> or rather what WaterSevenUb said :-)
<lucas> yup, I'll try that
<slomo> lamont-away, infinity: please remove banshee (for amd64) and galago-sharp (for every arch) from dep-wait
<zakame> heya
<Keybuk> \o/ dapper
<zakame> what's up?
<HiddenWolf> sabdfl, ping
<HiddenWolf> jdub, ping
<sabdfl> HiddenWolf: pong
<sabdfl> jdub is on the road
<HiddenWolf> sabdfl, remember we talked a few weeks back?
<HiddenWolf> mind if I query you?
<sabdfl> HiddenWolf: you'll need to remind me
<janimo> sabdfl, do you think it's too late to make a xubuntu install CD from breezy packages now?
<Nafallo> *buntu 5.10 and xubuntu 5.11? :-)
<janimo> ;)
<Nafallo> people will upgrade like crazy ;-)
<janimo> I didn't think of that
<wasabi> W: GPG error: http://us.archive.ubuntu.com breezy-security Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<wasabi> That's unexpected.
<sabdfl> janimo: it may be possible to craft an unofficial cd, if the xfce packages are all rocking
<sabdfl> but i would recommend rather doing a minimal ubuntu install, then pulling in the xubuntu-desktop
<sabdfl> and focusing attention on dapper, where we can do it properly
<janimo> sabdfl, that's how people currently install
<janimo> and I wondered if they'd be better off with all the stuff on CD
<sabdfl> janimo: can you craft unofficial cd's?
<sabdfl> i would be happy to point at them from the web site
<janimo> especially since people with poorer hw could have lower bandwidth too
<janimo> sabdfl, I could try to do it, several people already tried I was asking if it can be done with canonical buildd
<janimo> if not we'll try unoficially on xubuntu-devel
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with dapper) | #ubz for UbuntuBelowZero | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | yes, dapper | MOM's awake
<ogra> sabayon (2.12.1-0ubuntu1) dapper; urgency=low
<ogra>  .
<ogra>      - Work with remote X displays
* ogra hugs seb128 
<seb128> erf
* HiddenWolf chuckles
<janimo> I get warning with BADSIG 40976EAF437D05B5 after apt-get update
<janimo> even though apt-key lists that ket as the ubuntu ftp key 
<janimo> any suggestions?
<Kinnison> might be catching an archive mid-update
<Kinnison> apt-get update again
<janimo> ok, thanks
<ernstp> was playing around with GDebi
<janimo> just curious hmm how long does an archive update take? same warning after a minute 
<Kinnison> which archive are you using?
<janimo> ubuntu dapper including universe
<Kinnison> odd
<Kinnison> elmo: any idea ^^^ ?
<janimo> this used to happen to me from time to time but I ignired them
<janimo> but I became curious
<janimo> isn't this supposed to be an atomic change on the servers?
<Kinnison> I don't believe the mirror syncs are atomic, no
<hunger> janimo: I guess it should be an atomic change... but is not as it would lock the server for too long.
<janimo> the warning message is misleading though, as the key does not change
<janimo> oh well it's not that important but as I said it made me curious as it;'s not the first time it happens
<hunger> janimo: Happens to me too occasionally. Goes away after a while. I guess you can try to ask the server admins for ideas if you can find them;-)
<janimo> it's the default us.ubuntu server :)
<janimo> so I don't know if it's a mirroring problem
<janimo> anyway thanks
<tvo> fabbione: ping (about ubuntulog)
<fabbione> tvo: pong...
<tvo> fabbione: is it possible to add ubuntulog to #katapult, the development channel of katapult (kubuntu katapult team)
<mpt> smurf, ping
<fabbione> tvo: no sorry. i only take main channels. i can't handle to log per apps channel
<fabbione> tvo: you can smurf.. i think he has another log bot around
<tvo> fabbione: ok, thanks
<fabbione> no problem
<Keybuk> jbailey: do you have any particular preference for the /etc/modules file, or the new /lib/modules/boot directory-o-symlinks ?
<smurf> mpt: ?
<mpt> smurf, w.r.t. your comment about how the keyboard layout detector will change
<smurf> tvo: I'd recommend that you run your own logging bot someplace -- it's just a standard supybot setup
<mpt> smurf, have you come up with the wording of what you'll ask people to do?
<smurf> mpt: No -- feel free to think of something
<mpt> heh, that's what I was trying to do :-)
<mpt> mental block
<smurf> heh
<tvo> smurf: ok, thanks.  I don't have a server myself, but I'll tell some other guy who has about supybot..
<jbailey> Keybuk: What sort of preferences do you want?
<mpt> "Type the first of the characters on the list that is present on your keyboard"
<mpt> </awkward>
<smurf> mpt:  .. the first character that ...
<smurf> mpt:  .. the first character (starting from the left) that ...
<smurf> <UpArrow> Type the first character that ...
<mpt> smurf, how many will there be at once?
<smurf> (where the arrow points to the left-most character)
<ptlo> smurf, mpt: couldn't the detection be arranged so that user can type *any* character from the list? and if this doesn't narrow the types enough, create another list, and ask user to type another char (just my 2c, and i'm nobody in ubuntu dev universe :)
<smurf> mpt: the first string will have one of every script we know of
<smurf> ptlo: no
<smurf> the problem is that you have keyboards which are supersets of one another
<mpt> i.e. turn the decision tree into a decision sieve
<smurf> so the alternative is to ask repeatedly "do you have the "" key". On a US keyboard that's ten stupid questions, far too many
<ptlo> i see
<smurf> we have that now. It's awkward, and I want to produce an extended tree that's error-tolerant
<the--dud> the way I've always thought, is that people know which language they type
<smurf> i.e. if you miss the first letter that *may* be OK if I find another way to distinguish the keymaps..
<the--dud> they know what sort of keyboard they have?
<smurf> the--dud: no
<smurf> the--dud: many people don't, or they have surplus keyboards, or they are in a mixed-language region
<the--dud> hrm
<smurf> I've seen some rather strange bugs along these lines
<smurf> the--dud: ever wondered why we decided to build the keymap guesser in the first place?  ;-)
* smurf is off for food now
<the--dud> I figured it was a case of over-friendliness lol
<mpt> thanks smurf 
<jcole> hi guys, i ordered some ubuntu cds and it seems like it's taking quite a while (shipit.ubuntu.com 2005-10-13: 140 CDs sent to shipping company)... i'm in california... does it usually take this long? do the cds come from outside the us?
<mdke> I'm afriad you'll have to be a bit patient
<mdke> they take a while to send out and they come from Europe
<jcole> i want them NOW, lol
<mdke> have you got a deadline for them?
<mdke> if so, you should be able to apply for priority, if you have a look at shipit it will tell you how iirc
<jcole> no, but i've promised quite a few people
<mdke> jcole, the general rule is 4-6 weeks
<jcole> mdke: ok
<slomo> mine arrived today :)
<mdke> lucky ;)
<Keybuk> gnargh
<Kinnison> Keybuk: ?
<Keybuk> Kinnison: s/unstable/dapper/
<Kinnison> Keybuk: *snigger*
<tseng> daniels: ping
<daniels> tseng: good morning freedom and/or lovers
<tseng> daniels: yeah.. dbus
<daniels> yeah ...
<tseng> upstream is jacked, they call a hardcoded "monodoc" a zillion times
<daniels> what should they be doing?
<tseng> autotools
<slomo> and they have broken configure which looks for "monodoc" in PATH
<tseng> make a variable that we can pass/patch
<tseng> for the monodoc binary
<slomo> or do it right and don't look/use "monodoc" but mdassembler/monodocer
<tseng> because "monodoc" was a terrible wrapper to everything, it was never very correct
<daniels> hrm
<daniels> so what should it be on an ubuntu system?
<tseng> mdassembler is the latest crack
<daniels> i just made it variable-tastic, but what should I override it to?
<slomo> daniels: you either need to patch autofoo stuff, disable it for now until upstream fixes it or wait for mono-tools to get into universe and after that into main and build-depend on monodoc-browser
<tseng> slomo: eh it shouldnt use that stupid wrapper in any case
<daniels> is mdassembler a drop-in replacement for monodoc, or do I need to change arguments?
<slomo> no... for monodoc --get-sourcesdir use "pkg-config monodoc --variable=sourcesdir"
* tseng looks for package using md
<slomo> for monodoc --assemble use mdassembler
<slomo> for monodoc --update use monodocer
<slomo> and in configure just disable the check if "monodoc" is in path... the pkg-config one is sufficient
<daniels> i assume i need 1.19 or above for this, not .16?
<slomo> daniels: it's broken too in debian/experimental btw... it will FTBFS now
<slomo> yes
<carl> I think apt-get install linux-686 put ^M's in /boot/grub/menu.lst - anyone want this in bugzilla?
<Keybuk> did jdub's 770 ever arrive?
<jdub> Keybuk: no
<jdub> don't think they sent it, never got a confirmation email
<daniels> tseng, slomo: thanks
<tseng> daniels: no.. thank you oh wizard of autocrack
<slomo> daniels: np :) how did you fix it? patching generated autofoo stuff and sources or rebuilding autofoo stuff while building the package?
<daniels> mdz: does mcpp need a main inclusion report or can we just seed it?
<mdz> new source package, needs a report
<daniels> slomo: patched configure.in and Makefile.am to be sane, re-ran autoreconf -v --reinstall
<daniels> mdz: hrm, okay
<slomo> daniels: ok, thanks :)
<daniels> slomo: np
<daniels> elmo: could you please promote mesa-common-dev to main?
<elmo> daniels: you know mesa is trying to pull in lesstif aTM?
<elmo> done m-c-d in any event
<daniels> elmo: i fixed that in 0ubuntu2?
<elmo> ah, ok, I haven't rerun cron.sync  in a while
<daniels> argh, no I didn't
<Treenaks> daniels: did the X thing actually build in dapper yet?
<daniels> thanks for the catch; -swrast-dev still had it, but much of a muchness
<daniels> Treenaks: nope
<Treenaks> daniels: (or, could you send me a 'how to build a register extracter')
<daniels> heh
<daniels> so, what you need to do, is open /dev/mem, seek to your card's base memory address
<Treenaks> daniels: the one lspci -v gives me?
<daniels> then read out the bits of RADEON_FP_GEN_CNTL (offset 0x0284)
<daniels> compare between fglrx and radeon
<daniels> that'll do for a start
<daniels> Treenaks: yeah
<Treenaks> daniels: the 64k memory bit, or the 128M bit?
* Treenaks guesses the small one
<daniels> elmo: (libgl1-mesa-swrast-dev still had it as a install-time depends, but that's in universe anyway, so)
<daniels> Treenaks: i think the 64k one, yeah
<daniels> the 128MB one should just be your framebuffer
<Treenaks> daniels: ok, I'll hack around a bit on the plane tomorrow :)
<daniels> cool
<daniels> try not to hang your machine
<elmo> NO PRESSURE
<daniels> i'm pretty sure fp_gen_cntl is 4 bytes wide
<daniels> elmo: MAXIMUM PRESSURE
<Treenaks> daniels: sync; sync; try
<Treenaks> daniels: rebooting is easy
<Treenaks> (and if I stay with read()s, it should be hard to break stuff, I guess)
<HiddenWolf> Treenaks, BOOM!
<Treenaks> HiddenWolf: ?!
<HiddenWolf> Treenaks, it just broke. ;)
<elmo> daniels: anastacia/germinate doesn't see the distinction, they want to promote, l-m-s-d to main, so they want to promote lesstif too)
<elmo> (fyi)
<daniels> Treenaks: also 0x0250, 0x0254
<daniels> Treenaks: 0x0350 and 0x0354 maybe as well, but that's less probable
<daniels> elmo: oh.  why do they want to promote l-m-s-d?
<elmo> oh, they don't, it's already in main
<elmo> no, it's not, argh, I'm going INSANE
<elmo>  o libgl1-mesa-swrast libgl1-mesa-swrast-dev mesa-common-dev            {mesa}
<elmo>    [Reverse-Depends: libgl1-mesa-dev, libgl1-mesa-swrast-dev, libosmesa6-dev] 
<elmo> ^-- someone with more sleep than me, pls decode that, kthxbye
<Pygi> bye
<daniels> elmo: that looks like one of aj's scripts
<daniels> elmo: understandable output is for SUCKERS
<Treenaks> daniels: those are byte offsets?
<daniels> oh, I see
<daniels> Treenaks: yeah
<Treenaks> daniels: ok
<daniels> elmo: can we demote libosmesa6-dev?
<elmo> daniels: according to melanie, yes - it must be explicitly seeded; if you (/can convince someone to) fix that, I can demote it
<Kamion> hey, good opportunity to test bzr seed commits
<Kamion> I'll do that
<Kamion> testing before it's important is for LOSERS
<tseng> Kamion++
<daniels> heh
<daniels> elmo, Kamion: thanks
<Pygi> Hey Kamion
<daniels> hrngh
<daniels> the python module we need for bzr sftp access doesn't appear to be packaged
<daniels> also, its source is maintained in tla
<tseng> daniels: jbailey packages it
<tseng> daniels: in his nightlies
<daniels> ah
<tseng> bzrtools has sftp stuffs
<Kamion> ... as SeedManagement says
<daniels> Kamion: (actually, Seedmanagement doesn't mention paramiko; i just grabbed the bzr source and installed)
<daniels> actually, it does mention it, I'm just shit.
<Kamion> revno: 469
<Kamion> committer: cjwatson@flatline.org.uk
<Kamion> go me. anyway.
<Kinnison> Kamion: *g*
* Kamion documents how to set a bzr user id in SeedManagement, just because
<Keybuk> which one of the dozen ways are you going to document?
<Kinnison> [DEFAULT] 
<Kinnison> email=blar
<Kinnison> I imagine
<Kamion> right
<Kamion> pitti: http://bazaar.canonical.com/IntroductionToBzr has documentation of per-branch userids
<lamont-away> jbailey: any chance that the new klibc is what we need for initramfs on hppa?
<lamont-away> or is that still pending?
<jbailey> lamont-away: No chance.
<lamont-away> right
<lamont-away> just curious, mind you. :-)
* lamont-away wanders back away
#ubuntu-devel 2005-11-13
<Keybuk> http://packages.debian.org/unstable/sound/polypaudio
<Keybuk> ... note Suggests :p
<mdke> gah
<mdke> Keybuk, do you remember once resolving a bug with console-data along the lines of "Can't call method choices on an undefined value at /usr/share/perl5/Debconf/Question.pm"?
<Keybuk> no, did I?
<Keybuk> I don't remember ever touching console-data
<pitti> Keybuk: known bug
<pitti> Keybuk: guess what the fix is
<mdke> yeah, i haven't got a browser right now, so I can't call up bugzilla
<mdke> you fixed it for breezy
<pitti> Keybuk: I'll ask for removing the package from Debian :-)
<mdke> i'm just dist-upgrading to dapper and I see it again :D
<mdke> Keybuk, i'll just reopen once I get a browser installed
<sabdfl> infinity: ping
<jdub> hrm, seb's travelling
<pitti> without saying goodbye???
<Keybuk> mdke: bet I didn't
<mdke> Keybuk, k
<mdke> 20 squid?
<Keybuk> sure
* Keybuk offers his hand to shake
* mdke shakes
* mdke reboots to stable system
<Keybuk> mdke: ok, btw; I'm not Colin Watson... it was Kamion that fixed that
<Keybuk> now, want me to /msg you my paypal details? :P
<mdke> erm
<mdke> it was no way him
<infinity> sabdfl : pong.
<sabdfl> infinity: https://wiki.ubuntu.com/UsplashInitramfs?action=info
<mdke> Keybuk, ah bugger
<mdke> Keybuk, anyhow you cheated by looking the bug up first
<Keybuk> no, I just read the changelog :)
<Kamion> IIRC that bug was due to a corrupted debconf db; you might try /usr/share/debconf/fix_db.pl or whatever it is
<Kamion> but I haven't actually refreshed my memory on that bug so I could be wrong, shrug
<daniels> mdke: scott doesn't fix bugs in existing code, he gets bored and rewrites it in java :P
<Keybuk> ...and that was a party-political broadcast by the bendigo party
<daniels> don't go knocking bendigo
<mdke> i was having it confused with another bug
<mdke> that one he fixed
<elmo> wagga wagga
<mdke> Kamion, yeah that is right, strange that i keep getting it though, maybe a dud cd or something
<Kamion> mdke: if it's reproducible then it might well be something else; console-data is an insane heap of loosely-organised shit
<daniels> elmo: wooloomooloo
<mdke> Kamion, i'll see if that database rebuild command fixes it
<mdke> Kamion, yeah that did it
<mdke> now to install a desktop
* pitti grumbles at bzr pull/get not working with sftp:// with the seeds
<tseng> pitti: bzrtools
<pitti> tseng: I already have the latest crack
<pitti> tseng: pull returns with a weird exception, and get hangs indefinitely
<tseng> =/
<tseng> i guess ill run into that tommorow, i need it.
<dtf> I wondering why ubuntu doesn't ship Xprint? I was just told it was a showstopper.
<tseng> dtf: 
<tseng> xprint - Xprint - the X11 print system (binary)
<tseng>  ?
<slomo> dtf: it's deprecated and broken iirc
<dtf> ok, thanks.  I've never used it before and don't know much about.
<daniels> dtf: yeah, I told you it was a showstopper because Xprint is complete crack and we avoid it like the bplague
<pitti> Kamion: is it ok to commit to the seeds, or shall I wait for you to finish the germinate hacking?
<dtf> daniels: thanks
<Kamion> pitti: give me a sec, I'm munging
<Kamion> pitti: pull/get works just fine with sftp for me
<pitti> Kamion: pull actually works now, it threw an exception before (dunno what changed)
<pitti> Kamion: get just hangs 
<pitti> *shrug*
<Kamion> pitti: or, well, do what you want as long as it doesn't touch language packs :)
<pitti> get http:// and then pull works fine
<Kamion> pitti: it's not hanging, it's just REALLY SLOW
<Kamion> leave it for a while and it'll work
<pitti> ok, might be that, too 
<pitti> I lost my patience after 3 minutes without any screen change
<Kamion> bzr's sftp transport is, er, a bit suboptimal right now
<pitti> Kamion: I just want to drop some old postgresql stuff
<Kamion> that's fine, I need to learn how to merge anyway ...
* pitti creates a test case for Kamion :)
<pitti> Kamion: btw, how often is the mirror at rookery updated from chinstrap?
<Kamion> pitti: under 20 minutes
<daniels> Kamion: how often does the list of uninstallables get generated? daily?
<Kamion> daniels: cron.daily frequency
<Kamion> i.e. 30 minutes
<pitti> Kamion: wow, my first sftp:// push; it seems to have worked
<daniels> ah, cool, mesa is now installable, which means qt is now installable
<Treenaks> daniels: but, is it _buildable_ ?
<daniels> Treenaks: er, yeah
<daniels> it's hard to produce binaries to be installable or otherwise when you can't build it :P
<mdke> are bug reports for broken dependencies in dapper actually useful at this stage?
<mdke> or just wait
<mdke> ?
<Treenaks> daniels: Gentubuntu#
<mdke_> damn, did someone answer my question up there after I got disconnected?
<pitti> mdke: please don't, we can see an automatic report about broken deps already
<mdke_> pitti, thanks
<mdz> daniels: dpkg: error processing /var/cache/apt/archives/dbus_0.50-1ubuntu2_i386.deb (--unpack):
<mdz>  trying to overwrite `/usr/share/man/man1/dbus-launch.1.gz', which is also in package dbus-1-utils
<daniels> mdz: hrm, there should be a Replaces there
<daniels> mdz: what version is dbus-1-utlis?
<mdz> Preparing to replace dbus-1-utils 0.36.2-0ubuntu8 (using .../dbus-1-utils_0.50-1ubuntu2_i386.deb) ...
<Robot101> oh I pushed some of the dbus patches upstream
<Robot101> dbus-monitor and dbus-something-yada-libtool
<daniels> Robot101: oh, cool
<daniels> mdz: and ubuntu8 still had dbus-launch in it?
<mdz> presumably
<daniels> dbus (0.36.2-0ubuntu5) breezy; urgency=low
<daniels>   * Move dbus-launch from dbus-1-utils to dbus. This allows KDE to use
<daniels>     dbus-launch without pulling in all Gnome dependencies through -utils.
<mdz> dpkg certainly seems to think so
* Kamion goes round sealing the baz seed branches
<mdz> I can no longer verify this
<daniels> *shrug*, fixed now
<Kamion> all baz seed branches now sealed (kthxbye)
<daniels> Kamion: o, sealing actually works now?
<daniels> Kamion: last I looked, you could still actually commit to sealed archives
<shadeofgrey> hey has anybody seen Hidde?
<shadeofgrey> ...pardon me, i know this is the d3evel channel but does anybody here happen to be on the accessibility team for ubuntu?
<shadeofgrey> i need to talk to someone from that group asap if possible.
<daniels> if you're looking for specific people, try email
<shadeofgrey> okay... please forgive me for my intrusion.
<zakame> morning all :)
<dilinger> Kamion: so, uh, what actually works w/ breezy wrt root on lvm/md?
<dredg> IME, root on lvm/md works just fine as long as /boot is a regular grub-supported partition
<dilinger> oh, really?
<dilinger> that would be greate
<dilinger> great
<dilinger> well, let's see if a normal install works fine, given how unsupported sx8 itself is
<dredg> i've used that setup a number of times
<dredg> bunch of servers in my old job were all root on lvm+raid
<dredg> where a bunch = 40 or 50
<dredg> (running debian sarge, but i've used identical setup with hoary and breezy)
<dilinger> Mithrandir: damn, i should taken access to that amd64 box when you offered
<dilinger> Mithrandir: is the offer still open?   i need to recompile libparted16-udeb for amd64
<dilinger> (w/ a few patches
<dilinger> meh, grub doesn't install
* desrt makes a face at launchpad
<desrt> i -so- refuse to sign the code of conduct in the way that it is demanding that i do so
<crimsun> at least you can
<crimsun> sign-only keys are still unusable for that last I checked
<desrt> it's basically handing me a 160bit string and saying "please sign this"
<desrt> _ya right_
<desrt> no thanks
* desrt files a bug
<zul> evening
<bddebian> Hello
<desrt> aw crap
<desrt> my first ever launchpad bug and it has a spelling mistake in it
<desrt> i hate that
<mpt> desrt, that's what "Edit Description" is for
<desrt> mpt; ya.. but it includes my original report still :p
<mpt> That should be fixed over the next month or two, desrt 
<desrt> my original report still existing or the bug itself?
<mpt> The original won't be removed, but it will be hidden by default
<desrt> https://launchpad.net/products/launchpad/+bug/3996 <- and this one? :)
<desrt> it's preventing me from becoming an ubuntu member :)
<mpt> interesting
<desrt> indeed
<mpt> checking that the differences were only cosmetic would be rather hard to automate...
<Burgundavia> bon soir mpt, desrt 
<mpt> boa noite, Burgundavia 
<desrt> at the very least you should allow the user to insert some random string at the bottom
<desrt> alternatively you should pass both documents through a regexp that turn any amount of whitespace into a single space
<Burgundavia> desrt, do we need to do any more work on power-management-config before I present the idea to the gnome-power list?
<desrt> then hash them
<desrt> and make sure they're still the same
<desrt> Burgundavia; i was planning on talking to richard personally on irc next time i caught him
<desrt> Burgundavia; but, really... the parts at the bottom are all that matter
<desrt> and they're just about right
<Burgundavia> desrt, excellent, I will let you do that
<minghua> desrt: if we also have the size of the clear text, then such a birthday attack is much much harder, is that correct?
<wasabi_> Man. I have so many friends who use Windows who have switched to Ubuntu.
<wasabi_> 6 so far.
<wasabi_> Pretty nuts.
<mpt> hmmmmm
<mpt> desrt, Burgundavia, I think that design needs a bit of work
<Burgundavia> mpt, in what way?
<mpt> for example
<mpt> "Remaining percentage" doesn't really make sense when the battery is *charging*
<mpt> "Preferences" should probably have a "..." since the implied action is "change my preferences"
<mpt> There should not be a single alert that has six buttons along the bottom, that's just scary :-)
<mpt> DapperDesktopPlan talks about a Log Out / Switch alert that is (apparently) separate from the shutdown one
<mpt> There's no preferences for automatic sleep/shutdown when running on mains power (e.g. I went away on holiday and forgot to turn off the computer)
<mpt> There's a checkbox for "Suspend on lid close", and it's not obvious what the alternative is
<mpt> If a password is required when waking the computer, should it automatically be required when unlocking the screensaver? If not, does it matter?
<mpt> "Issue warning:" what?
<mpt> Why have "one tab"?
<Burgundavia> mpt, the plan is to move the menu item to a first class menu item
<Burgundavia> first class panel item, that is
<mpt> yes, I read that
<mpt> Those are all the points I can think of right now
<mpt> oh, should there be a slider for turning off the screen separately from hibernation? (XP and OS X have that)
<Burgundavia> mpt, can you drop your comments on the spec itself?
<mpt> sure
<mpt> oh wow
<mpt> I just found where gnome-power-manager's panel icon comes from
<mpt> http://www.homepage-link.to/solutions/images/power-options.jpg
<mpt> it's just recolored :-/
<wasabi> oh wow.
<Burgundavia> hmm
<Burgundavia> you certain?
<wasabi> I think it's traced.
<wasabi> but not recolored.
<wasabi> no, n/m
<wasabi> it's not.
<wasabi> look at the bottom of hte battery.
<wasabi> gpm the plug and battery bottoms line up
<wasabi> sure similar though. ;0
<mpt> "inspired by"
<wasabi> most definatly.
<desrt> minghua; i'm confused by your question
<desrt> minghua; birthday attack is possible either way
<minghua> desrt: what I'm asking is: you said that it's possible to do a birthday attack by construct another text file which have the same SHA1 hash as the social contract people signed
<desrt> yes... but not in that order
<desrt> given a document it's very difficult to generate a new document with the same hash
<desrt> but if you get to generate the document for yourself it's substantially easier to generate a pair of docs with the same hash
<minghua> desrt: but if there is someway to specify the size of the file I signed, it's much harder to get two files with the same hash, is that correct?
<desrt> no.
<desrt> not correct
<desrt> generally speaking, imagine a document in which 128 different things can be changed
<desrt> this is easy to do
<desrt> say replace a word with an equivilent word
<desrt> or wrap a line one way or another
<minghua> desrt: okay, I see
<desrt> or insert an extra space here and remove one there
<desrt> all in a way that keeps the filesize...
<desrt> then you can generate 2^128 equivilent documents with different hash values...
<desrt> the expected number required to do a birthday attack on sha1 is much much smaller
<minghua> desrt: not necessarily 2^128 _different_ ones, but I'm not arguing here :-)
<desrt> well.. you've just underlined the argument right there
<desrt> chances are that you would generate two variants of the document with the same hash value :)
<desrt> and by "chances are..." i mean  like 99.999999999[etc] %
<minghua> desrt: my understanding is that it's relatively easy to make two file with the same hash, but harder to generate a new file to match a certain hash and size, since you only have one file to modify, is this correct?
* minghua hopes it is 
<desrt> yes.
<desrt> exactly.
<desrt> you can even remove the "and size" constraint
<desrt> and say "it's relatively easy to make two file with the same hash, but harder to generate a new file to match a certain hash, since you only have one file to modify"
<desrt> the size constraint is wholy uninteresting since i could pad "i agree to give all of my money to alice" with a bunch of legal mumbojumbo
<desrt> until it was the same size as the code of conduct
* minghua is then going to assume ubuntu is "not evil" and happily sign the code of conduct :-)
<desrt> plus, i'm not even sure that pgp includes the document size in the signature
<desrt> that's a dangerous assumption :)
<desrt> all of this being said, of course, i'm using a copy of PGP as packed by ubuntu :)
<minghua> desrt: yeah, I just had the wrong impression that size matters
<minghua> :-D
<desrt> so i guess i can just assume that it's been programmed to send my private key to the launchpad servers :)
<minghua> or even you are compiling gnupg yourself, you are using the GCC provided by ubuntu ;-)
<desrt> vicious circle
<desrt> i also have to read every single line of the source code of gcc and pgp and libc and linux and (etc) to make sure they're all free of backdoors.....
<desrt> i should also take an electron microscope to my CPU and make sure intel hasn't installed any backdoors in the hardware..... [this gets ridiculous] 
<Keybuk> oops ... it appears that iwj has left the key to his suitcase in the room
<Burgundavia> oops
<Burgundavia> Keybuk, are you planning to do more "approved specs" emails?
<Burgundavia> Keybuk, if not, do you want me to do them?
<Keybuk> Burgundavia: yeah, I should do one tomorrow to clean up the last of them
<Keybuk> but if you want to instead, go for it
<Burgundavia> ok
<Burgundavia> if you were planning to do it, then go ahead
<Keybuk> I think we did the last of the approvals today
<Keybuk> is nice, a much more sedate pace
<Burgundavia> [OT]  does anybody remember a transparent logo from somewhere?
<mpt> yes, here's one -->
<mpt> *cough*
<mpt> What do you mean by "a transparent logo", Burgundavia?
<Burgundavia> mpt, like the big one of the back of the cd cases
<Kamion> god, bzr push / sftp is insanely slow
<Kamion> and I think contains a race condition you could drive a truck through
* mpt doesn't have a CD case handy
<mpt> Burgundavia, could you just tweak the SVG in Inkscape?
<Burgundavia> mpt, yes, I di
<dilinger> meh, i'm about to give up.   grub is just utterly broken w/ the sx8 driver
<poningru> do it
<poningru> its easier than trying
<pef> hello
* freeflying is away: Away at the moment
<zyga> hello
<crimsun> janimo: xterminal should removed from the archive since we have xfce4-terminal
<janimo> crimsun, I agree
<crimsun> k, I'm off to grab a few hours of shut-eye :-)
<janimo> :)
<janimo> although xfce4-terminal has Replaces xterminal
<shawarma> Can someone tell me where the format of the Release file in a Debian repository is described?
<shawarma> Never mind.
* freeflying is away: Away at the moment
<Mithrandir> dilinger: yes, offer is still open.
<Nafallo> morning Mithrandir :-)
<Mithrandir> hiya Nafallo 
<Mithrandir> fsvo morning, I guess.
<Nafallo> hehe, I've been up since 7 so... ;-)
<Mithrandir> I've been up since four or so, five possibly.  (CET)
<Nafallo> ehm
<Nafallo> WHY? :-P
<Mithrandir> because I was on a plane.
<Nafallo> ah
<Mithrandir> the plane ride from .ca to .nl is too short.
<Nafallo> that explain things :-)
<Diziet> Hello people.  I have the same problem - I'm walking about, but asleep.
<Nafallo> morning Diziet :-)
<dtf> Diziet: I've been working on a ff 1.5rc1 build
<dtf> Diziet: have you started hacking on it yet?
<Mithrandir> Diziet: you might want to insert caffeine into bloodstream.
<Diziet> dtf: Yes.
<Diziet> I have a working port of Debian's to breezy, but I'm still halfway through merging the patches between Breezy and 1.0.7 upstream.
<Diziet> caffeine> Of course.  But I should avoid hacking on code when I'm s/sleep/caffeine/.
<dtf> Diziet: I have a working port of Debian's to dapper.  Is there some where I can download your source from?
<Diziet> No, it's just floating about here.  I imagine yours is similar to mine.
<Diziet> I can give you a copy if you really want it but it's just something I made for testing purposes or I would have uploaded it.
<dtf> Are you intrested in setting up a baz repository so we can combine our efforts?  I just join ubuntu so im not really sure of how thing work here.
<Nafallo> s/baz/bzr/ :-)
<dtf> s/join/joined/ :)
<Diziet> I'm partway through and I've been doing it file-by-file and with much messing about; I don't think it'll commit well into an rcs until I'm done.
<Diziet> FVO done = have done the merge, but still not of course the finished dapper Firefox.
<Diziet> After that I'll definitely upload it and perhaps bzr would be a good thing to apply to the problem.
<dtf> Do you have a time frame in mind?  This is my first Ubuntu effort so I'll continue to working locally getting the feel for the "Ubunu way" then start contribuiting patches to you.
<Diziet> Well, I'm walking-asleep today but I was going to work on Firefox tomorrow.  I'm not sure how long it'll take but a small number of days (2 maybe).
<Diziet> patches> Sure.
<Diziet> To be perfectly honest with you I haven't yet used bzr ...
<dtf> Cool -- I'll keep lurking and learning and doing bug triage
<Diziet> Oh, you're dfarning !
<Diziet> I should say thank you for your work on the bugs.  Well done; it's very helpful.
<dtf> Yes.  I'm trying to earn my chops here.
<Diziet> JOOI, did you find the patch to make sid's build on dapper at all difficult ?  The one I made for breezy was trivial.
<Diziet> (I've been at UBZ so haven't been touching any of this for a week and a half.)
* freeflying is back.
<Pygi> we freeflying
<Pygi> wb*
<freeflying> Pygi:hi
<Pygi> Hi
<Nafallo> seb128: ping/hi! :-)
<seb128> Nafallo: pong
<Nafallo> seb128: I've took debians screem and uupdated to 0.16.0. something we should put in dapper?
<Nafallo> they are at http://www.magicalforest.se/~nafallo/packages/
<seb128> do we need to create some diff? what about syncing?
<Nafallo> debian haven't updated yet
<Nafallo> and I had to change the dbus-depend
<seb128> yeah, and but we can wait on them, no? :)
<seb128> I'm busy enough without working on screem to be honest
<seb128> I'm just back from UBZ and need to catch up with 2 weeks of mails/bugs/packaging/etc
<\sh> seb128: back at home? :)
<seb128> yeah, good old France
<Nafallo> hehe, ofcourse we can. but we have had 0.12 since hoary completly skipping 0.14 so... ;-)
<seb128> yeah
<seb128> Debian has 0.15.1 than we can sync
<seb128> if you find somebody to sponsor your 0.16 feel free too
<Nafallo> I've just that one for a while :-)
<\sh> seb128: how is the situation in france? I read this morning the newspapers...and it doesn't look good in toulouse...
<Nafallo> oki, thanx (/me goes to hunt down Mithrandir) ;-)
<seb128> \sh: dunno, I've not read a lot of news this week
<seb128> Nafallo: good
<seb128> Nafallo: he just travelled back from UBZ at well, so I guess he will catch with sleep and some other stuff too today
<Nafallo> seb128: yea, but now I atleast have your permission to bug him :-)
* \sh had a nice jetlag...and this morning i reclaimed my lost luggage...and had a nice meeting with one of the people at our county gourt
<Nafallo> \sh: oh? switched bank yet? :-)
<\sh> Nafallo: not now...I had much more serious to deal with :( 
<\sh> but i'll do it during this week...
<\sh> seb128: and u should sleep 
<sivang> seb128: ah, you've just arrived?
<seb128> like 2 hours ago
<seb128> Nafallo: no, I said that we can probably wait to get the new version with a sync :)
<seb128> Nafallo: but you are free to bother somebody for it, just don't blame me
* mvo waves at \sh 
<Nafallo> seb128: we could ofcourse, or we upload 0ubuntu1 tomorrow (already talked to Tollef :-)) waiting for debian to catch up. I'm willing to care a little extra for screem as you've probably already figured out :-).
<sivang> seb128: then really, you need to go to sleep :-)
* \sh waves at mvo :)
<seb128> no
<Nafallo> everyone * ubz should probably sleep :-P
<seb128> sleeping now is using a wrong tz
<slomo_> seb128: why didn't you just sync gst-ffmpeg from debian?
<\sh> mvo: when did u arrive?
<seb128> slomo_: because I don't want to work on the diff of what they cripple from it now
<\sh> seb128: i just slept more then 16 hours to catch up
<slomo_> seb128: the debian version contains a fix for non-altivec powerpcs... it isn't completly fixed upstream... i worked with lool on it
<mvo> \sh: about 1h ago, I'm using my shinny new wlan!
<seb128> slomo_: I don't really care right now to be honest, you could as well have done it, nobody touched it for weeks I've updated it
<\sh> mvo: wooo...it works? :)
<seb128> slomo_: next time ask for a sync or update it
<slomo_> seb128: i already requested a sync from elmo a week ago ;)
<seb128> slomo_: instead of waiting than somebody does something to complain
<seb128> slomo_: k, so no problem I guess, that doesn't block the sync
<mvo> \sh: yep, perfectly. my gf loves you for it, because it makes a cable go away that she hated :)
<seb128> and at least we get the new version
<slomo_> seb128: sorry, i didn't want to complain... i only wanted to know if you had a specific reason for this ;)
<seb128> slomo_: no, but do we want to turn off everything than Debian turn off?
<\sh> mvo: good to hear...
<seb128> mvo: doh, you forgot to get blue hairs
<mvo> seb128: yeah, didn't managed to get up in time :/
<slomo_> seb128: they turn of all encoders and it's probably wise to do so... with encoders turned on it should be in multiverse as users can get into trouble when using them
<slomo_> seb128: at least lool told me that he disabled the encoders for that reason
<\sh> seb128: mvo and blue hairs?
<seb128> yeah
<mvo> \sh: I wanted the same stuff as jbailey 
<seb128> slomo_: stop trying to move the world to multiverse
<seb128> first vlc
<seb128> now that :p
<seb128> anyway, lunch time
<seb128> bbl
<Nafallo> hehe
<slomo_> seb128: yes, that was a mistake ;) but some stuff has to be removed from vlc anyway to leave it in universe... and gst-ffmpeg will stay in universe, just with decoders turned off like in debian
<\sh> mvirkkil: jeff had blue hairs? i didn't see it yesterday
<\sh> mvo that is...
<\sh> not mvirkkil 
<slomo_> seb128: and ffmpeg will stay in universe too... just to clarify :P
<mvo> \sh: not all of his hair, just hanks(?) of it
<\sh> mvo: ah :) well...my glasses just filtered that out :)
<mvo> haha, true :)
<\sh> anyway...i'm just waiting for my good old pizza cab...
<\sh> yeah...
<\sh> merges
* mvo goes for lunch too
<zakame> hi all
<pef> zakame: hello !
<zakame> hi pef ! :)
<slomo_> seb128: and exactly for that reasons i asked on the list... if it is a mistake or isn't... anyway... doesn't matter anymore... if you want to talk with me about it just write me a mail (slomo@ubuntu.com) or talk to me this evening when i'm back ;)
<zakame> wb all
* Diziet goes to organise lunch.
<Keybuk> Diziet: you left some kind of key in the room
<Seveas> Kamion, elmo, mako, awake?
<Seveas> CC meeting in 5 minute
<Seveas> s
<tsume> its mdz :)
<tsume> mdz: so what if a lab monkey feels insulted about ubuntu? :P
<jsgotangco> hello fang :)
<tsume> kiba == fang
<Diziet> keybuk: Oh, one of those round ones ?  That'll be the one for my laptop lock.  I have two, so it can come back to me by pigeon post.
<pitti> infinity: ping
<tsume> jsgotangco: tsume is claw, nail, talon, hoof
<jsgotangco> tsume: yes, i was wrong....
<tsume> jsgotangco: perfectly okay :)
<tsume> jsgotangco: its better than saying "hey you"
<jdub> hey jsgotangco 
<jdub> i'm sitting next to sascha
<jsgotangco> jdub: hey!
<jsgotangco> yeah sacha emailed me a few hours ago, say my regards
<jsgotangco> jdub: i got email from sonia, she seems pretty upset at you :)
<infinity> pitti : pong
<zakame> jsgotangco: sacha chua?
<jdub> jsgotangco: ugh, yeah :(
<jdub> zakame: yes :)
<zakame> jdub: wow
<jsgotangco> jdub: you might get sucked into signging keys with her
<jdub> jsgotangco: i think we made quite the wrong decision for a korean event :(
<jdub> jsgotangco: haha, not this time, had to revoke mine :)
<jsgotangco> jdub: i just emailed sonia, will wait for her reply tommorow who knows maybe it'll push through its only a 2 day event anyways
<jdub> jsgotangco: we're talking to mako about going too, so maybe that will settle her
<jdub> i feel really bad :(
<zakame> jdub: aww
<infinity> pitti : pong
<pitti> infinity: hi
<pitti> infinity: I added some remarks to the splashdown wiki page
<infinity> pitti : Ahh, cool.  I'll fix it up first thing.  Thanks.
<sabdfl> Riddell: ping
<Riddell> sabdfl: gu
<Riddell> hi
<trulux> morning
<zakame> evening
<pef> elmo: ping ?
<Burgundavia> seb128, is there supposed to be an O (as in the letter) in the package number of gnome-media?
<Riddell> is there an ubuntu gpg key server?
<Kinnison> yes
<Kinnison> keyserver.ubuntu.com
<zakame> Riddell: keyserver.ubuntu.com
<Riddell> cool, thanks
<pitti> dholbach!
<dholbach> hey pitti
<dholbach> hi everybody else
<Keybuk> heyheyhey
* Keybuk questions the wisdom of writing package descriptions while listening to Weird Al Yankovich
<Diziet> If we had localised package descriptions we could have a special locale for randomness.
<infinity> Keybuk : Sounds perfectly reasonable to me.
<Diziet> A friend of mine made a `guru' locale which translates EFOO and SIGFOO as EFOO and SIGFOO FAVO FOO except for PIPE.
<Keybuk> . o O { where do SuSE put their source RPMS ? }
* pitti always needs half an hour to find the srpm he looks for
<Keybuk> hmm, SL-OSS-edge only has udev 072-2
* Keybuk sends ARE WE THERE YET? vibes to BenC
<dieman> arugh, start talking on the support chan like you know something and people start msging you directly :|
<Diziet> keybuk: Did you see my comment earlier about the mystery key ?
<Keybuk> Diziet: no, I missed that
<Keybuk> what is it?
* Kinnison watches XFS enjoying itself
<Keybuk> 0.75user 0.81system 0:13.42elapsed 11%CPU (0avgtext+0avgdata 0maxresident)k
<Keybuk> 0inputs+0outputs (1752major+5979minor)pagefaults 0swaps
<Keybuk> 13.42s
<Keybuk> it's the --quick that makes ALL THE DIFFERENCE
<Kinnison> Keybuk: quick?
<Keybuk> Kinnison: depmod
<Kinnison> Keybuk: You're kidding?
<Kinnison> dear gods
<Kinnison> What does --quick turn off?
<Diziet> <Diziet> keybuk: Oh, one of those round ones ?  That'll be the one for my laptop lock.  I have two, so it can come back to me by pigeon post.
<Keybuk> quick makes it stat before it reads the module
<Kinnison> so quick turns something *ON* ?
<Kinnison> that should *so* be the default
<Keybuk> usually you run depmod to deliberately regenerate the modules
<Keybuk> we so shouldn't be running it on every boot
<Kamion> Keybuk: give Diziet's key to me when we're going home and I'll pass it on
<Kinnison> jbailey: I get an I/O error on this disc :-(
<Riddell> anyone have ubuntu breezy CDs to have and able to tell me the front cover text
<Riddell> ?
<Diziet> riddell: Just a mo ...
<Diziet> riddell: The text on the front of the cardboard pouch, or on the front of the CD ?
<Diziet> IBM++
<Diziet> No hassle service on my laptop's display fault (just acquired).
<Riddell> Diziet: front of the cardboard
<jbailey> Kinnison: *pout*
<Diziet> `ubuntu' with in smaller letters below `linux for human beings' and then in the corner `Version 5.10 for your PC'.
<Diziet> The main `ubuntu' and subtitle is in a white inset with an ubuntu logo at the left.
<Riddell> nothing about intel/amd/x86/32-bit ?
<Diziet> My capitalisation is as found on the cardboard.
<Diziet> There's a lot of text on the back.
<Diziet> Including `This PC Edition will run on Intel x86-based system (including Intel Pentium and AMD Athlon).'
<Diziet> No mention of 64-bit or 32-bit.
<Diziet> The spine (which tends to end up folded flat slightly because it's much wider than the thickness of the whole package) says  `Ubuntu [spot]  linux for human beings       Version 5.10 for your PC'.
<Diziet> [spot]  is a greenish dot about the size of an `o'.
<Diziet> Why do you ask ?
<Riddell> Diziet: I'm making the kubuntu CD cover
<Riddell> and my bag with breezy CDs is somewhere between heathrow terminal 4 and here
<jsgotangco> oohhhh
<Diziet> riddell: Urgh, you left your bag behind ?
<Diziet> You should get Claire or someone to give you a copy of the Ubuntu artwork, surely ?
<Riddell> Diziet: BA left the bag behind, rather than making it follow me
<Diziet> That's clever of them.
<Diziet> You flew on from LHR to Edinburgh, then ?
<Riddell> yes
<Diziet> If it would help I could scan it.
<Riddell> Diziet: that would be quiet useful actually if you could
<jordi> I need seb.
<seb128> jordi: what is that about?
<jordi> oh
<jordi> you're here already
<seb128> elmo: please sync gnome-doc-utils
<jordi> seb128: so, SMEG isn't translatable at all.
<seb128> jordi: it's fixed with the new version
<jordi> seb128: that's crap. Do you know if their official CVS repo is cvs.gnome.org? If so, there's njo activity in a while.
<jordi> which new version?
<seb128> smeg 0.6
<slomo> seb128: sorry if i was a bit harsh to you earlier today... for gst-ffmpeg i would suggest to use debian's version and just re-enable the encoders... that way we won't lose functionality and as nobody complained before let's do it this way until someone complains or until we get someone with legal knowledge to look at it... ok with you?
<seb128> Amaranth changed the name too
<seb128> slomo: np don't worry. Sure, that's universe package feel free to do this :)
<seb128> jordi: I got pinged about that during first week at UBZ but I was quite busy, I'll have a look on it again
<slomo> seb128: i want to ask anyway as you care for the whole gnome stack and this is a outer part of it ;) i'll do it then...
<seb128> thanks for asking :)
<jordi> seb128: good
<Diziet> riddell: uploading now.
<jordi> if everything is good, smeg will get imported utomatically in dapper
<jordi> let me check if it is now, actually
<jordi> apparently not yet
<jordi> seb128: was your flight good?
<jordi> seb128: Do you still have a car
<jordi> seb128: or is your neighbourhood in flames?
<seb128> jordi: flight was nice, dinner, movies, breakfast and some sleep and we were arrived
<seb128> no riot around here, I live in a small quiet town ;)
<jordi> seb128: heh, I just found this
<jordi> in my favourite daily strip in Spain
<jordi> http://www.elpais.es/vineta.html?d_date=20051108&xref=20051108elpepivin_1&type=Tes&anchor=elpporopi
<jordi> I think you'll understand the text
<jordi> if not, tell me
<seb128> jordi: "condenado"?
<jordi> sentenced
<Diziet> Riddell: right, the first file is pretty much there.
<Diziet> Look at http://www.chiark.greenend.org.uk/~ijackson/d/share009.tif and share010.tif (still on its way).
<jordi> so "do you have something to say before being sentenced to be the French Minister of Internal affairs?"
<seb128> jordi: k, thanks ;)
<Diziet> I unfolded the card and took the cds out.  009 is the outside and 010 (uploading now) is the inside.
<Diziet> 16Mb TIFF each :-).
<Diziet> Riddell: Anyway, I hope that's helpful.  I'm going to go and eat now so I can fall over.
<Riddell> Diziet: very helpful, thanks
<Diziet> NP
<Diziet> Goodnight everyone.
<seb128> 'night Diziet
<seb128> elmo: glib2.0 sync please
<seb128> mdke_: this kind of rent (totem/mozilla) is usually not really useful ...
<mdke_> seb128, what's wrong?
<seb128> mdke_: just reading your rent about totem package on bugzilla
<mdke_> i would hardly call it a rant
<seb128> "I know that multimedia is hard but implementing bad solutions
<seb128> will give Ubuntu a bad name."
<seb128> the solution has nothing Ubuntu specific
<seb128> and I don't think totem gives a bad name to Ubuntu
<mdke_> seb128, i simply bumped the bug up to major because, as specified in the HelpingWithBugs page, it affects a lot of people
<seb128> I've nothing against that
<seb128> but against the comment
<mdke_> ok
<mdke_> seb128, you're misunderstanding my comment
<seb128> you are basically say "slacker your work make Ubuntu bad"
<mdke_> seb128, i don't mean Ubuntu has introduced the bug, I think however that Ubuntu shouldn't ship a plugin by default if it crashes when playing ogg files
<seb128> for something which is nothing Ubuntu specific
<seb128> it doesn't crash for me
<seb128> what about beeing useful and giving details on your arch, what you do exactly, a backtrace, etc
<mdke_> seb128, lemme know what you need and I'll attach it
<mdke_> but there are several backtraces already on the bug iirc
<seb128> do you use amd64?
<mdke_> i386
<seb128> hum, k
<seb128> I thought the issue might be amd64 specific
<seb128> I've no crash on my i386
<mdke_> what can i do to help?
<seb128> do you use totem-gstreamer or totem-xine?
<mdke_> gstreamer
<mdke_> everything is default
<seb128> no gst-ffmpeg so?
<mdke_> yes, I've installed that, shall i remove it and try?
<seb128> yep please
<elmo> seb128: mais non, je suis desoler
<elmo>  [dpkg-source output:]  dpkg-source: error: file glib2.0_2.8.3.orig.tar.gz has size 3387973 instead of expected 3387955
<mdke_> seb128, shall i remove anything else? I also have the plugins and plugins-multiverse
<seb128> elmo: grrr, merci quand mme :) Et "gnome-doc-utils"?
<pitti> seb128: can you please do a small gst change for me?
<seb128> pitti: sure
<pitti> seb128: I'll upload a new jack to dapper
<seb128> mdke_: that doesn't hurt, so we know if that comes from some other package
<mdke_> seb128, i'll do my best
<seb128> pitti: the Debian maintainer has dropped the jack sink
<pitti> seb128: the build-dep of gst-plugins0.8 has to change s/libjack0.80.0-0/libjack0.100.0-0/
<pitti> seb128: that's even better
<seb128> pitti: I think I'll just drop it as well
<seb128> cool
<pitti> seb128: yes, pleeeeeease!
<pitti> seb128: I love you for that, you know?
<seb128> mdke_: does it crash when opening the file? Or when moving back to an another page?
<pitti> seb128: it was the only thing that keeps jack in main
<seb128> rock
<elmo> seb128: tout fait
<seb128> elmo: merci bien
<mdke_> seb128, the file doesn't play, then firefox crashes when moving to another page
<pitti> seb128: do you have a roadmap for that?
<seb128> pitti: for what? gst-plugins0.8? I'll do it now
<pitti> seb128: rock
<pitti> seb128: k, I unseed gstreamer-jack now
<seb128> cool
<seb128> dpkg -L libgl1-mesa-dev | grep gl.h
<seb128> grumpf
<mdke_> seb128, would you know by any chance, what package provides that plugin? I need to reinstall it
<seb128> where is gl.h hidding
<seb128> mdke_: what plugin? the totem one? totem
<seb128> totem-<variant> rather
<mdke_> yes that one, thanks
<mdke_> seb128, fwiw, this is the info I have in about:plugins http://pastebin.com/421932
<mdke_> seb128, i'll test the plugin when I get home, I'm blocked by a content-filter here, so i'll post to the bug if you're not around
<seb128> k, thanks
<seb128> it refuses to crash here
<seb128> with epiphany or firefox
<mdke_> odd
<mdke_> ok revert later, bye!
<mirak> seb128: hi, can I ask you some question about amd64 ?
<seb128> sure, but I'm probably not at the best place to reply I use an i386 installation
<pitti> mirak: don't stop him merging gst-plugins :-)
<mirak> seb128: I was wondering why is there a amd64-generic kernel amd64-k8
<mirak> ok
<mirak> Ioups
<mirak> I mean seems there is a distinction
<mirak> I am also wondering if amd64 ubuntu is compiled with SSE and such
<Amaranth> amd64 is amd and intel 64-bit processors
<Amaranth> so i don't think k8 would be right for the intel ones
<Kamion> -generic is used by the installer
<Kamion> -k8 and -xeon are optimised for real-amd64 and Intel EM64T respectively
<mirak> Kamion: so what exactly do they use ?
<mirak> in plus
<mirak> SSE ?
<fabbione> mirak: a more specific kernel usually enables the features that are available only on that CPU
<fabbione> and the kernel is compiled with more specific flags to make better use of some CPU resources
<fabbione> a generic one is always required to identify the minimum common denominator, and be sure to be able to boot/install
<fabbione> (sort of a safe approach)
<fabbione> it doesn't mean that the generic kernel sucks
<fabbione> it means that in some specific situation it might be slower
<fabbione> that's it
<mirak> ah
<mirak> apt-build is broken
<mirak> it's possible to recompile stuffs with it
<Keybuk> jbailey: can I borrow you for a moment
<Kamion> elmo: please sync mdcfg, binfmt-support
<elmo> Kamion: done
<janimo> Kamion, with ubuntu express will thee seed categories be simplified? I.e live goes away?
<Kamion> janimo: no
<janimo> will there be separate live/install CDs too as now?
<Kamion> the install CD will still be supported, it just (hopefully) won't be sent out in shipit any more
<seb128> pitti: should I switch the default sink to alsa?
<Kamion> elmo: please sync floppy-retriever
<elmo> Kamion: done
<Kamion> elmo: please sync baseconfig-udeb (sorry for the one-by-ones, I keep thinking "this one's the last")
<elmo> Kamion: done
<janimo> Kamion, what's the diff between debootstrap and cdebootstrap?
<Kamion> janimo: debootstrap works
<Kamion> cdebootstrap is a reimplementation for reasons that are now obsolete, and it's never been updated to work with Ubuntu
<janimo> thanks
<mdke_> seb128, still around?
<seb128> mdke_: yep
<mdke_> seb128, still reproducing the bug, after removing gstreamer0.8-ffmpeg
<seb128> k, definitively weird bug
<mdke> seb128, i removed gstreamer0.8-plugins then did a debfoster and removed everything beginning with gstreamer, but I'm not 100% sure I've got nothing more than the default packages, I might have the occasionally plugin i guess
<mdke> seb128, the videos I'm using to test it are those at http://foodfight.org/movies/Ubuntu%20Fanpeople/
<seb128> yeah, I've tried on those as well
<seb128> it starts playing some frames
<seb128> then stop
<seb128> but doesn't crash
<seb128> I can go back, go to google or whatever
<seb128> try another video, etc
<mdke> seb128, strange. with me when I navigate away, it crashes
<mdke> seb128, can i provide any more help?
<seb128> mdke: debug backtrace if you get better ones than the bug one. Does it happen with epiphany-browser ?
<mdke> checking
<mdke> seb128, no, works fine
<seb128> oh, interesting
<seb128> I blame firefox so :)
* mdke goes for a backtrace
<mdke> seb128, what packages should I be building with debug support for a backtrace? do I need to rebuild ff?
<seb128> yep
<mdke> gah, ok
<Kamion> elmo: please sync console-common
<slomo> elmo: will we get NEW packages from debian/unstable automatically?
<pitti> interesting question - I wait for postgresql-8.1
<pitti> elmo: please sync jack-audio-connection-kit
<pitti> elmo: (Ubuntu override ok)
<lifeless> fabbione: ping
<pitti> seb128: thanks for gst
<fabbione> lifeless: pong?
<spstarr_work> whats happening in Toronto?
<spstarr_work> some event w/ ubuntu?
<\sh> hmmm....is there any official announcement for this IBM DB2 thingie?
<lifeless> fabbione: are you still doing our kernel ?
<lifeless> I have a request ...
<fabbione> lifeless: -> BenC
<fabbione> lifeless: and bugzilla please
<lifeless> fabbione: thanks.
<lifeless> fabbione: not malone ?
<fabbione> lifeless: did we officially switch to malone?
<fabbione> if not -> bugzilla
<lifeless> fabbione: I thought so
<fabbione> i didn't see any mail to -devel or -announce
<fabbione> so i doubt there have been a switch
<lifeless> just asked
<lifeless> no, not yet
<fabbione> :)
<lifeless> :}-
<lifeless> I wonder if kinnison has integration planned? deriving is easy :)
<sivang> \sh: will go off tomorrow
<lifeless> modprobe snd_bt_sco
<lifeless> FATAL: Module snd_bt_sco not found.
<lifeless> fabbione: ^^
<\sh> sivang: hmm...now it's not a surprise anymore :*
<sivang> \sh: hrm oops, well, nobody watched this channel besides developers no? :)
<\sh> sivang: u wrote it on -devel...
<sivang> \sh: I know :) it was intended, just kidding
<\sh> sivang: well....I wonder if heise.de will catch it
<sivang> \sh: they are scraping our mls ?
<\sh> sivang: many of the heise.de gang are reading MLs, IRC logs, rss feeds...they are geeks not only journalists :)
<lifeless> fabbione: ah, we rename the module. bah
<sivang> \sh: cool :)
<sivang> \sh: anyway, too bad I need to reboot to install windows just to flash my BIOS , couldn't find a non windows needing BIOS flashing way
<sivang> \sh: (for the T43)
<fabbione> lifeless: meh actually we don't.. that's how it comes out of the kernel
<lifeless> fabbione: hmm, not according to their documentation
<lifeless> fabbione: ah well.
<lifeless> fabbione: how often do we update from their sourcec ?
<lifeless> fabbione: and, if I start maintaining the userspace, how do I get the kernel driver updated most easily ?
<fabbione> lifeless: we do update drivers on request
<fabbione> lifeless: i got the first request from chmj and he was supposed to do userland
<fabbione> lifeless: i am pretty sure the driver has been already updated in .14 for dapper
<HiddenWolf> sivang, ping
<Keybuk> fabbione: do you really want gcc-3.4, jbailey thinks that won't build on sparc
<fabbione> Keybuk: i can test it... if you are not in a hurry to do it right now
<fabbione> i can wait
<lifeless> daniels: any idea of the cuase of this ? ...
<lifeless> bluepin 
<lifeless> Xlib: connection to ":0.0" refused by server
<lifeless> Xlib: No protocol specified
<fabbione> Keybuk: i am firing up a test now
<CarlFK> when the bios is probing for boot devices, does it load/run anything?  like if I boot from a LiveCD, could something from the HD be run first?
<Keybuk> fabbione: ok
<mdke> seb128, ping
<dilinger> does anyone have an amd64 machine running hoary, or w/ a hoary chroot that i can use temporarily for building on?
<seb128> mdke: pong
<mdke> seb128, i've rebuilt totem and firefox, and I can't get firefox to run in gdb, any ideas? the error is This GDB was configured as "i486-linux-gnu"..."/usr/bin/mozilla-firefox": not in executable format: File format not recognized
<seb128> run firefox
<seb128> get the pid
<seb128> gdb -p <pid>
<kikidonk> mdke: it's because mozilla-firefox is not an executable but a script
<fabbione> Keybuk: gcc-3.4 is good.. it builds at least
<Keybuk> fabbione: where do the sparc build logs go?
<Keybuk> what was the failure on 4?
<fabbione> Keybuk: they go to ... hmm.. hold on.. lamont server
<fabbione> i can forward it to you
<fabbione> but the failure with 4 is gcc-4.0 problem
<fabbione> we did check that during breezy
<Keybuk> yeah, jeff's convinced that it also failed on gcc 3.4 with the same problem
<fabbione> nope
<mdke> kikidonk, so what should I do?
<fabbione> Keybuk: that was gcc-4
<fabbione> he just told him that he was confused
<kikidonk> mdke: as seb said
<kikidonk> or
<kikidonk> gdb sh
<Keybuk> ok, if you promise it won't fail again ... :o)  on its way to the archiev
<kikidonk> > r /usr/bin/mozilla-firefox
<kikidonk> in the shell
<mdke> if I do gdb -p # then firefox crashes
<mdke> or freezes, or whatever
<mdke> seb128 ^
<seb128> (gdb) run
<seb128> no
<seb128> (gdb) continue
<mdke> thanks
<seb128> np
<mdke> seb128, got something, but I'm not convinced it adds anything to the bug report. lemme know if I should post it http://pastebin.com/422237
<seb128> mdke: not really useful, all the strace start with ???
<mdke> yeah
<mdke> seb128, anything else I can do?
<jbailey> Keybuk: Still need me? =)
<seb128> mdke: not really, this bug is annoying :/
<mdke> seb128, can't you deactivate the plugin with firefox until it is fixed?
<seb128> maybe
<seb128> need some discussion
* mdke nods
<Keybuk> jbailey: depends what for
<jbailey> Keybuk: Your message earlier in this channel didn't say what for.
<jbailey> 13:17 < Keybuk> jbailey: can I borrow you for a moment
<mdke> silbs, mail to sounder and devel missing attachment
<Keybuk> I'm sure I must have talked to you about that when you were in here last
<jbailey> It's possible.  I'm feeling a bit stateless at the moment.
<janimo> pitti, will libao2 be switched to alsa as default soon?
<pitti> janimo: it's on the spec, yes
<mdke> silbs, :)
<infinity> elmo : ping.
<lamont-away> Keybuk: http://buildd.mmjgroup.com/buildLogs
<infinity> elmo : I suspect python-libxml2 wants to be promoted to main (It's in the build-dep chain for gnome stuff)
<Keybuk> lamont-away: I didn't find sparc on there
<Keybuk> oh, maybe I looked at the REAL one
<dtf> I just set up a prototype ubuntu specific firefox search engines page at http://www.rtklib.org/
<dtf> just click a engine link from within firefox and it will install that engine in your search bar
<lamont-away> Keybuk: buildd.mmjgroup.com is hppa/sparc, the rest are people.u.c/~lamont/buildLogs
<Keybuk> right
<Keybuk> I didn't look at the URL :)
<Keybuk> I just read that as "lamont's build logs"
<dtf> Does this look like something that would be useful to Ubuntu?
<dholbach> good night, everybody
<daniels> lifeless: ~/.Xauthority doesn't match the server keys
<lifeless> daniels: interesting
<lifeless> daniels: there is a set_display in bluepin that seems rather confused
<lifeless> but as its called by hcid, I can understand that
<daniels> if it's called by hcid, then it won't be using your Xauthority
<lifeless> right, so set_display is meant to figure out what mine is
<lifeless> has the location or anything like that moved ?
<daniels> lifeless: no, it's still in $HOME
<lifeless> ok
<lifeless> I shall fiddle later, thanks
<daniels> np
<lifeless> jordi: are you using voip ?
#ubuntu-devel 2006-11-06
<Riddell> does blueprint still have the "needs discussion" tickbox?
<tfheen> no
<cjwatson> Riddell: use the discussion/drafting states to distinguish
<Riddell> thanks
<Lathiat> pitti: ping?
<pitti> Lathiat: pong
<Burgundavia> evand: ping
<evand> Burgundavia: pong
<Burgundavia> pm
<lastnode> imbrandon, ping?
<_Enchained> hi
<_Enchained> anyone can help me in packaging for ubuntu ?
<Burgundavia> _Enchained: #ubuntu-motu
<_Enchained> ok thx
<jdong> is Ubuntu siding with Debian on the whole BitTorrent 4/5 licensing issue?
<jdong> or would it be eventually possible for Ubuntu to get a newer version of the mainline bittorrent client?
<psusi> what licensing issue?
<Burgundavia> jdong: I think so, we don't accept the cddl either
<Burgundavia> psusi: choice of venue makes it non-free
<psusi> huh?
<Burgundavia> read teh debian-legal summary
<psusi> where can I find that?
<Burgundavia> google it, I don't hvea the url off the top of my head
<psusi> google for what?  debian-legal + bittorrent?
<Burgundavia> yep
<jdong> psusi: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298814
<psusi> ok
<Ubugtu> Debian bug 298814 in bittorrent "bittorrent: New upstream version available" [Wishlist,Open]  
<jdong> read the first few comments
<jdong> and the linked links
<jdong> Burgundavia: what about for restricted or multiverse?
<jdong> mainline 3.x is starting to get next to useless in comparison to other clients
<Burgundavia> why not look at other implementations?
<jdong> Burgundavia: I am pretty involved with ktorrent, so I am looking at other implementations
<jdong> Burgundavia: but we currently install mainline 3.xx as the default torrent client
<Burgundavia> I think there is a C, a C++ and a C# library out there
<jdong> and IMO that's not a good choice
<jdong> Burgundavia: there is basically no other decent GTK+/GNOME client
<jdong> you have BitTornado, which is almost as suckish anything but an ultra ideal swarm
<Burgundavia> yep
<jdong> and Azureus, which (1) still doesn't work *cough* and (2) eats RAM and CPU for lunch
<jdong> and (3) continues to be a bit quirkish due to GCJ instead of Sun JVM
<Burgundavia> yes
<jdong> Burgundavia: people are starting to run uTorrent inside WINE :D
<Burgundavia> plus it is massiively overkill
<HrdwrBoB> jdong: it's the best solution
<HrdwrBoB> unfortunately 
<jdub> we need a nice, simple downloader style client that can tell its own running process to kick off multiple downloads
<jdong> HrdwrBoB: ktorrent's almost in a position to overtake that :D
* jdong biased? NAW!
<psusi> why does the released edgy versio of grip tell you that it is a development version when you start it up?  did someone slip up?
<jdong> HrdwrBoB: we are missing peer exchange support, and that's about it
<HrdwrBoB> psusi: it's a universe package
<HrdwrBoB> sound juicer is ubuntu default CD ripper
<jdong> psusi: the version in Edgy was indeed a development version of grip?
<psusi> that is what it claims
<psusi> get a big fat popup the first time you start it saying this is a development version, if you have truoble, revert to stable
<jdong> psusi: well, it's true... :)
<jdong> it is a development version of grip
<psusi> shouldn't we not be releaseing development versions in the stable release of ubuntu? ;)
<Hobbsee> psusi: not necessarily
<Hobbsee> psusi: seems it was a sync from debian anyway, with a couple of rebuilds
* mpt would be interested to know the proportion of packages in Ubuntu that have a version number < 1 :-)
<jdong> psusi: the MOTU team must've thought it was a better choice than the stable version of grip
<Hobbsee> mpt: indeed
<psusi> ok.. but shouldn't they have disabled the obnoxious warning at least? ;)
<jdong> psusi: perhaps, yes
<jdong> psusi: guess nobody bothered to complain before edgy's release
<Burgundavia> psusi: if you care about an app, watch it through the dev cycle and make certain ti gets to where you need it to be
<psusi> didn't realize it was universe... just installed it from the add programs applet
<psusi> because sound juicder can't correctly rip this cd I got today
<psusi> hrm... is this with just the main bittorrent client, or derived ones as well?   like bit tornado?
<zOrK> where can I begin developing? is there some webpage?
<crimsun> https://wiki.ubuntu.com/UbuntuDevelopers
<cge> What is the process for requesting that something be removed from main?
<crimsun> removed from Ubuntu or demoted to universe?
<cge> reportbug - demoted to universe, probably. 
<crimsun> any way it can be fixed?
<cge> The only people I've spoken to about it seemed to think that it would be easier to rewrite it.
<cge> It currently sends bug reports to ubuntu-users, since it is based on Debian's reporting system.
<cge> So some users, who see it in main and assume that it is supported by Ubuntu, install it and use it, resulting in them being admonished for spamming ubuntu-users.
<asabil> hi all
<asabil> https://features.launchpad.net/distros/ubuntu/+spec/usb-adsl-modems
<asabil> don't you think that this is important enough to require a higher priority ?
<LaserJock> it was discussed today
<asabil> and ?
<LaserJock> it has been marked as read for review
<asabil> hmm okey
<LaserJock> *ready
<asabil> because this is one reason why people in my country don't use ubuntu :/
<asabil> given that the eagle-usb drivers are broken :D and ueagle-atm is not in dapper nor edgy
<LaserJock> yeah
<LaserJock> so it was proposed, discussed, drafted, and up for review
<LaserJock> that's pretty good for the first day of the summit :-)
<asabil> let me just hope that it will get accepted
<asabil> cool then ;)
<sivang> morning
<PecisDarbs> hi devs, question to Ubuntu packagers - how frequently happens translations updates packages release and how to initialise one, if there is need to fix faulty translations. For example, there is lot of buggy translations in particular lanugage and it would be nice to issue new translation update. Is that possible?
<pygi> PecisDarbs: there will be translations build somewhere in the future I think
<pygi> PecisDarbs: pitti is your man
<PecisDarbs> thanks for info :)
<PecisDarbs> pygi: he is frequent guest here?
<PecisDarbs> :)
<pygi> PecisDarbs: I doubt you'll find most of folks here right now, since they are at conference
<crimsun> it's 1:31 AM where they're at.
<PecisDarbs> ahhh
<PecisDarbs> I don't need it ASAP, just a little info :)
<PecisDarbs> it/him/s
<pygi> PecisDarbs: I think every first monday in month or something like that is update
<PecisDarbs> I see
<PecisDarbs> good
<PecisDarbs> thanks for info :)
<pygi> yw ^_^
<Administrator__> I want to build my own recovery dvd. If I could get the source of the ubuntu installer cd, or if there was a way of adjusting the init scripts that would be great. The init script is going to do the following, restore partition table, mbr, mkfs, mount, restore biggbackup tarball, grub install. reboot. If there is a way to use the current ubuntu cd that would be great.
<Hobbsee> Administrator__: the people who know are mostly in mountain view at the moment, and still asleep
<rigidus> hi all
<rigidus> could anybody help me guys, how to give -i option to postgresql's postmaster process? Thanks :-)
<Hobbsee> rigidus: try #ubuntu for support
<rigidus> thanks I tried
<cge> rigidus: Try on the mailing list, or the forums, if you don't get an answer in #ubuntu.
<rigidus> I tried the forum but there was no answer
<rigidus> I guess the startup script is not completed
<cge> unfortunately, #ubuntu and the forums are declining in usefulness for people with more technical or nontrivial problems because of the huge number of users that flood them with obvious questions. The mailing list is probably best. But please don't bring them here.
<rigidus> ok, thanks
<Hobbsee> rigidus: likely the people who know are mostly in mountain view at the moment, and still asleep - try ubuntu-users mailing list for support
<rigidus> thanks Hobbsee
<JohnFlux_> Hey all
<Hobbsee> heya
<JohnFlux_> is there a channel for the summit
<Hobbsee> JohnFlux_: yeah, #udsmtv
<Hobbsee> JohnFlux_: but it's still very early morning in MV
<Hobbsee> hence you probably wont find people awake
<JohnFlux_> Hobbsee: i know
<JohnFlux_> Hobbsee: i cant sleep ;)
<Hobbsee> JohnFlux_: heh.  jetlag?
<JohnFlux_> yeah heh
* Hobbsee wonders what you're involved in
<tepsipakki> is security-repos from archive.u.c now obsolete?
<tepsipakki> are ^
<JohnFlux_> Hobbsee: i wonder too heh.  im a kde coder
<Hobbsee> JohnFlux_: ahh :)
<Hobbsee> JohnFlux_: yet you're in everywhere but #kubuntu-devel it seems.  (which is also silent, due to everyone being asleep)
<JohnFlux_> Hobbsee: its really good though - im having fun
<Hobbsee> what are you coding?
<Hobbsee> :)
<JohnFlux_> ah there we go
<JohnFlux_> Hobbsee: im the maintainer of ksysguard
<JohnFlux_> and one of the coders of konversation
<JohnFlux_> and miscillanous kde stuff
<Hobbsee> ahhh....so that's where i recognise the name from
<JohnFlux_> ;)
<bddebian> Heya
<LTjake> hello. I was wondering, as a core developer for Catalyst (perl MVC framework) and an ubuntu user (server and desktop), I'd like to see these packages as up-to-date as possible; is there any way i can help?
<sivang> LTjake: first check if they are in universe,
<sivang> LTjake: if they are, then you can work on them and upload your packages to REVU
<sivang> LTjake: after prooving your skills and after working with folks in the MOTU team, you can get approved for uploads and then you could take care of them yourself
<LTjake> okay. checking...
<LTjake> do things get sync'ed from debian packages at all? the latest catalyst seems to be in debian unstable...
<LTjake> the packages in universe are out-of-date, btw.
<grndslm> this might not be the place to ask, but i have been asking in the lvm && ubuntu channels with no help....
<grndslm> why on earth would pvscan list my device as an unknown device??
<Chipzz> grndslm: not getting an answer elsewhere is not an excuse to ask here ;)
<Chipzz> but this may be a valid question :P
<Chipzz> just pointing out in general
<grndslm> Chipzz, somebody in the lvm channel tells me that lvm version 2.02.06 is buggy...but this is obviously version *-2ubuntu3
<grndslm> so i dunno if this would be the same bug(s) or what
<Chipzz> apt-get source and look at what's patched
<_ion> Wow, looks like you get to write twice the amount of code in order to achieve the same thing with Catalyst, compared to Rails.
<pygi> hey sabdfl 
<sladen> iwj: what exactly is /var/lib/dpkg/updates/ for?  The Changelog says it was added in 0.93.18 (12 years ago), but I can't find a reference to it actually being used 
<sladen> iwj: for stackable file-systems, dpkg/available needs updating somehow
<ianm_> has there been any discussion regarding prevention of swap-deathin ubuntu?
<ianm_> it seems that any app can kill or at least DoS a linux desktop just by allocating lots of memory
<psusi> don't run such apps.... and if you run a multiuser server, then there is ulimit
<simira> heh... problems in google hq?
<ivoks> ?
<ianm_> psusi: do you think normal users don't deserve such protection?  how do you know ahead of time which programs are bad (and in which situations)?
<psusi> no... normal users are going to be the only person on the system and they aren't going to intentionally write and run a fork bomb
<ianm_> I'm not talking about fork bombs, just memory exhaustion
<psusi> same thing
<ianm_> normal users aren't going to run apps that ask for lots of memory? 
<psusi> intentionally hogging all resources to cripple the system.... it's not a concern to single user systems
<psusi> they aren't goign to run apps that intentionally ask for more and more memory until it is all used up
<ianm_> again not talking about malicious behavior
<psusi> if they try to open a 3 gig image in gimp with only 128 megs of ram, then they can put up with the lag
<ianm_> it's not lag though, it's endless HD churning until they hard-reboot.  maybe not technically a crash, but effectively it is
<ianm_> memory exhaustion is the only problem I've seen, and I see it several times from normal programs under normal conditions.  sometimes firefox, other times evolution
<psusi> hard reboot?
<psusi> sounds like a hardware bug
<psusi> it should just get real swappy until memory demand goes down
<ianm_> what if it doesn't go down?
<psusi> then the system stays swappy
<psusi> until you get fed up with it and start killing stuff ;)
<grndslm> how can i find out if a certain patch was applied in an ubuntu release version, specifically lvm?
<ianm_> how do you kill stuff when the GUI is unresponsive?  (yeah, terminal, kill -9, but this is linux for normal people right?)
<grndslm> killall <packagename>
<grndslm> that works well enough for me
<ianm_> psusi: or did you mean, like, your cat and your girlfriend? :)
<psusi> lol
<psusi> yea, it would be nice if gnome-system-monitor locked itself into ram
<psusi> so you could stil bring that up and kill stuff
<Keybuk> ianm_: click the [X]  button in the corner
<Keybuk> metacity will notice that the app is unresponsive to the request, and offer to force quit it (ie send KILL)
<grndslm> what's wrong with the kill applet?
<ianm_> Keybuk: how do they even know which program is misbehaving?
<Keybuk> ianm_: the one that's unresponsive
<grndslm> or "force quit" actually
<ianm_> all are unresponsive when your system is swap-dying
<ianm_> using 'top' is the only way I've figured out which is to blame
<Keybuk> yes, and when your system is doing that, killing things won't help
<Keybuk> System -> Administration -> System Monitor
<Keybuk> the one at the top is using all the CPU
<Keybuk> click "End Process"
<ianm_> but you understand that navigating menus / GUIs during a swap-death is next to impossible..?
<Keybuk> ianm_: so?
<Keybuk> what do you want?
<psusi> when thrashing no task is using much cpu
<Keybuk> novice users can't deal with non-gui
<psusi> you just have one that is using all the ram... that's what needs to die
<grndslm> is there such a thing as too much swap?
<psusi> yes
<ianm_> Keybuk: right, so I'm proposing that we don't let a process DO that to the system
<Keybuk> ianm_: how do you prevent a process doing doing that?
<psusi> how do you propose that?
<Keybuk> psusi: then that's the one the kernel kills
<ianm_> I can't say for sure, I'm not a kernel hacker, but maybe just preventing one process from allocating more than X ram?
<Keybuk> ianm_: then you're talking about this in the wrong channel
<Keybuk> this is the channel for people with proposed solutions
<grndslm> anyway...could you guys tell me how i could find out if a certain patch was applied in an ubuntu release version, specifically lvm?
<grndslm> after apt-get sourcing?
<psusi> can someone teach ubotu to quit telling users to use the disks applet to mount partitions since it has been removed in edgy?
<ianm_> Keybuk: heh and must someone be 100% sure of their proposal..?
<ianm_> Keybuk: "preventing one process from allocating more than X ram"  <--- proposed solution
<psusi> ianm_: there is no good way to choose a value of X that will not annoy people who actually want to load a really big app
<psusi> ianm_: and you can just have n tasks that use X and still thrash the system
<ianm_> how about locking critical stuff in RAM, so that the system stays responsive?
<tfheen> ianm_: sure, set ulimits sensibly.
<Keybuk> ianm_: what's critical?
<Keybuk> the kernel already does that
<ianm_> Keybuk: the things that keep the GUI responsive
<psusi> have to be careful about that because then it lowers the ram availible to other things when you don't need the "critical stuff"
<Keybuk> the primary thing that keeps the gui responsive is also the primary allocator of RAM
<sivang> Keybuk: just wanted to ask, I poked at eject for making sure ubuntu changes were not dropped in the merge, but couldn't find the base packag. Do you have an idea where it went ? (I couldn't find it on snaphost/qa.d.o)
<Keybuk> sivang: merges.ubuntu.com
<ianm_> psusi: I agree re: careful, but aren't there core gnome things that have to stay in RAM for the GUI to be used?
<Keybuk> ianm_: no
<slomo> Keybuk: hi :) if you have some free time could you take a look at bug #69647? the sync is needed for some other stuff and the only ubuntu change is trivial
<Ubugtu> Malone bug 69647 in cli-common "Please sync cli-common 0.4.6 from debian/unstable (main)" [Undecided,Confirmed]  http://launchpad.net/bugs/69647
<Keybuk> slomo: no.
<Keybuk> syncs are in auto again now
<psusi> ianm_: there is a LOT of stuff that would need to be locked... which is the problem
<Keybuk> they will take 3-4 days
<ianm_> Keybuk: like... the gtk library?  glib?  no??
<Keybuk> ianm_: they aren't processes
<sivang> Keybuk: you store the base source somewhere on m.u.c ?
<Keybuk> sivang: naturally
<ianm_> Keybuk: didn't say processes, said "core gnome things"
<psusi> Keybuk: yea, but they still could be locked in ram if you wanted to
<Keybuk> psusi: it wouldn't help
<psusi> Keybuk: well, it would... but it would be costly
<sivang> Keybuk: okay, I was just puzzled by not being able to find the base anywhere else then :)
<Keybuk> psusi: no, it wouldn't
<Keybuk> sivang: please don't try and do merges by hand, use mom
<psusi> how would it not help to not have to swap them back in?
<ianm_> psusi: costly only in the sense that no process could take up 100% of RAM and swap? 
<slomo> Keybuk: this one involves dropping ubuntu changes though
<psusi> costly in the sense that there would be a lot less ram that could be used by other things that might need it more than the gui at times
<Keybuk> slomo: then it'll be done in roughly two weeks
<slomo> ok
<psusi> now what might be really cool is if there were a magic sysreq key or something you could hit that would stop the kernel from swapping out from a list of important tasks for a while... so you could hit that to regain control of a thrashing gui
<Keybuk> psusi: there is
<psusi> then switch it back after
<psusi> there is?
<Keybuk> well, there's a key to stop swapping, and others to kill processes
<Keybuk> if swapping is actually causing a system problem, you've got bigger problems than just the wrong things in the wrong place
<Keybuk> you really need to kill things
<ianm_> Keybuk: are we back to that?  how does a normal user kill processes?
<psusi> yea, but you don't just want to have the kernel pick something to kill, and you may in fact, want to let the process keep running.... just not at the cost of gui responsiveness
<sivang> Keybuk: okay, I'll try to get less confused by it :)
<psusi> and when you say there is a key to stop swapping, what exactly does that mean?  just swapoff -a?
<psusi> cause that's not what you want either
<ianm_> if we assume that 1) a normal user will never use the command line, 2) the GUI gets unresponsive in these conditions, 3) when the system is unresponsive, a normal users assumes it needs a reboot, then aren't we *effectively* back in windows 3.1 days where any app can hard-lock the system? (not literally/technically, but effectively!)
<Keybuk> ianm_: then propose a solution
<Keybuk> this is NOT a bitching channel, or a bug reporting channel, or even a support channel
<Keybuk> this is "I have a concrete idea to fix this problem, here's my idea"
<ianm_> I came here to pick your brains on this topic
<psusi> practically though the only time I can see this happening is if someone opens a 3 gig image in gimp... and they can just click the close button and it will be killed
<Keybuk> you haven't given a single idea yet
<Keybuk> ianm_: this is not a brain picking channel either
<Keybuk> start a thread on the ubuntu-users mailing list
<Keybuk> when you have a concrete idea, start a thread on ubuntu-devel proposing it
<tfheen> Keybuk: we could conceivably make c-a-d bring up the task manager or something like that.  Or some thingabob similar to the windows c-a-d dialog
<ianm_> tfheen: would whatever components the task manager needs have to be locked in memory for that to work?
<ianm_> Keybuk: if you haven't seen a single idea yet, read more carefully
<tfheen> ianm_: you seem to be very attached to the "lock in memory" idea which has bad implications for other reasons.
<sladen> when swapping gets bad the system responsiveness gets aweful.  Best thing to do is Ctrl-Alt-F1 and come back 20minutes later
<ianm_> I'm not attached to any idea, just asking
<sladen> at which point the system will be normal again
<mjg59> Is mlocked memory still shared?
<tfheen> mjg59: unsure, but mlock requires root privs, iirc?
<cjwatson_> not any more
<tfheen> oh, ok
<cjwatson_> that was changed in the Ubuntu kernel (at least) a while back
<mjg59> There's a configurable amount that can be done per user
<psusi> I like the idea of rather than locking the task manager all the time, setting it up so that ctrl-alt-del will bring it up, and set the task such that the kernel will not prune pages from its working set for a while
<mjg59> Right, what you /actually/ want is for the kernel to just stop caring about anything other than that application
<psusi> that way it will get itself faulted in and running in a timely manner and then be fully responsive
<mjg59> Oh. Other than X, of course.
<mjg59> Which makes things trickier
<sladen> yup/win 346
<tfheen> mjg59: so really just renice a bunch of processes -5 or so?
<mjg59> Since by X we actually mean "the X server that this application is going to connect to"
<mjg59> tfheen: I'm not sure how well the linux scheduler works when stuff is deep in swap
<psusi> true... X needs to not be thrashed as well
<tfheen> probably not great.
<mjg59> Which is probably what the actual problem is
<psusi> nice itself won't help since it isn't an issue of cpu scheduling
<iwj> sladen: /var/lib/dpkg/updates is so that dpkg doesn't have to rewrite /var/lib/dpkg/status each time.
<mjg59> psusi: If the thrashing tasks don't get scheduled, they won't trigger page faults
<psusi> unless the swapper respecs nice?  which I don't think it does
<ianm_> is there a time when a user *wants* X to thrash?  
<psusi> mjg59: they do get scheduled... then page fault and block again... that's the problem
<mjg59> psusi: Right. So to some extent it /is/ a cpu scheduling thing
<psusi> mjg59: no... it isn't... it got scheduled... but can not run because it page faulted
<mjg59> psusi: In the specific case of us wanting the system to remain responsive enough for people to kill tasks, we don't want the applications that are causing the memory starvation to get scheduled at all
<Keybuk> mjg59: and probably dbus and HAL for the task manager to communicate with the other random bits
<Keybuk> and the window manager
<Keybuk> so it can get painted
<psusi> ohh, yes... if you stop the bloated tasks then they won't be faulting in pages anymore
<Keybuk> oh, and the composite manager, so it can be drawn
<mjg59> But to be honest, my gut feeling is that this is something that would make a nice research paper for someone
<psusi> but nice isn't going to do that for you
<mjg59> Right, it would need to be rather more invasive
<psusi> aye
<psusi> I have a question about Suggests: and Recommends:  do these fields exist for any reason other than to inform the inquisitive power user about other things they might want to install?
<mjg59> Yes
<psusi> if they are supposed to list packages that are not strictly depended on, but things that you really should install to use this package properly, shouldn't the add applications applet and maybe even synaptic at least prompt the user to install them?
<mjg59> psusi: http://www.debian.org/doc/debian-policy/ch-relationships.html
<psusi> mjg59: that doesn't say what tools actually DO in response to the field... and from my experience, it looks like they do nothing
<psusi> i.e. apt-get and synaptic do not prompt you to install the Recommended or Suggested packages
<mjg59> psusi: What the tools do is entirely up to the individual tools
<psusi> from a user perspective, shouldn't the tool at least prompt to install the Recommended packages?  it seems none of them do
<psusi> should I file a feature request for the add applications applet to do this?
<tfheen> we need to vet the list of recommends first, iirc
<ianm_> psusi: also it seems it would have to explain the choice, which it isn't prepared to do
<psusi> tfheen: vet it?
<ianm_> psusi: saying "xftgbd is recommended, do you want to install it?" probably isn't appropriate
<tfheen> make sure it's sane
<psusi> ianm_: I think it would be sufficient to put up a dialog that says "It is strongly recommended that you also install the following to get the full use of out this package:" and have the other packages checked to install unless they uncheck them then hit ok
<ianm_> I agree that'd be fine for synaptic, as that's not what normal users will be using anyway
<psusi> followed by "The following packages are Suggested to be installed as they may add in some way to the functionality of this package, install?" and list them but have them not to be installed unless the user checks them off before hitting ok... maybe even make the package names clickable so they can read the description
<psusi> I raise this issue because I used the simple add applications applet to install Grip to rip some cds, and it does not work out of the box because it needs vorbis-tools to encode... it is listed under Recommends: but since that field is ignored,
<psusi> we have a package that does not work out of the box.
<psusi> this leads to poor user experience
<ianm_> that sounds more like a data bug, no?
<ianm_> as in vorbis-tools should be required
<psusi> no, because it is not required
<psusi> you can choose not to encode to ogg
<psusi> you can just keep it in wav, or go with mp3
<psusi> but for it to just work out of the box... it needs vorbis, which is why it is strongly recommended
<psusi> unfortunately, the installer ignores this fact
<ianm_> oh I see.  the app could possibly be wise to the situation as well
<psusi> yea, I was thinking maybe the debconf script for the package could check to see if any of the encoder packages are installed, and prompt the user to install them?  not sure if you can do that with a debconf script, I'll have to hack around with it
<ianm_> there has been talk about media apps making it easy to install codecs.  this seems to fall into that category
* psusi goes to lunch
<pygi> dholbach: thanks, was already approved as part of -qa team :)
<zOrK> hello
<cbx33> hey jono 
<jono> hey cbx33
<cbx33> guys, who would I talk to about using the arrows for the undo/redo in the Human theme in a logo for a new ubuntu product
<jono> how did you get on with gstreamer?
<cbx33> jono I jhave a working prototype
<pygi> jono: as always, are you willing to be boethered? :)
<cbx33> ;)
<pygi> bothered even :)
<cbx33> bothered....? with me?
<jono> cbx33: awesome :)
<pygi> cbx33: no, I wanna bother him :P
<cbx33> oh heh
<jono> pygi: huh?
<cbx33> jono I can now convert ogg mp3 and wav to wav ;)
<jono> cbx33: woo!
<cbx33> i was hoping for amr
<cbx33> but it's not in the repo
<pygi> jono: do you have the power to setup a mailing lists at lists.ubuntu.com?
<jono> cbx33: I saw some of the gstreamer trick modes yesterday - funky shit
<jono> pygi: nope
<pygi> jono: you know who does? :)
<jono> pygi: yep, lemme check
<jono> pygi: mail mailman@lists.ubuntu.com
<cbx33> trick modes?
<pygi> jono: ok, I'll write there
<pygi> jono: thanks
<jono> pygi: :)
<cbx33> jono tell me more about these trick modes
<jono> cbx33: you can stuff like slowing and speeding up audio in realtime, its pretty cool
<jono> doing reverse playback and stuff
<cbx33> ooooh
<sladen> jono: how the heck to do you reverse playback realtime?
<Treenaks> sladen: gstreamer ;)
<cbx33> heheh
<sladen> oooh, gstreamer has gained so much.  I'd missed the Time Machine going in
<cbx33> sladen, hiya...had chance to sign my key yet? :p
<sladen> cbx33: you control panel got a mention by ogra in the introductary talk
<cbx33> oh really?
<cbx33> good or bad?
<cbx33> :p
<sladen> cbx33: sounded good to me
<cbx33> w00t
* _ion should try implementing http://johan.kiviniemi.name/pictures/misc/better_crossfading with gstreamer some day.
<zOrK> Is anyone working on easy-ndsiwrapper?
<zOrK> https://features.launchpad.net/distros/ubuntu/+spec/easy-ndiswrapper
<DShepherd> I don't know if anyone else noticed but the firefox icon in the main menu differs from the one that shows on the application itself... was this intended? 
<robertj> already filed
<DShepherd> robertj:ok 
<jdong> DShepherd: hehe, the DFSG spirit always finds ways to cling onto our packages :D
<DShepherd> jdong: ;-)
<sladen> jono: re: Rosetta, stub, carlos and danilo are all marked down to be in the session running concurrently
<jono> sladen: ahhh cool
<zOrK> is there any patch for the broadcom wireless card?, I am thinking about make one
<volvoguy> hey folks. rebuke me if you must, but i can't find any documentation anywhere that mentions whether the server kernel is SMP capable. can i get a quick yes or no?
<infinity> volvoguy: Yes.
<volvoguy> infinity, thank you. :) bye bye now. 
<geser> infinity: hello. are you still working on bug 65266 ?
<Ubugtu> Malone bug 65266 in php4 "[UVF Exception]  Sync php4 4.4.4 from Debian unstable" [Medium,Confirmed]  http://launchpad.net/bugs/65266
<claviola> where can I find this year's signing keys for the archives?
<tepsipakki> Seveaz: hi, do you know of any efforts on packaging nx-2.1.0?
<Seveaz> tepsipakki, no, focus in the free software world is on the 2x.com packages and not nomachines mess
<tepsipakki> oh
<tepsipakki> didn't know such exists
<ajmitch> Seveaz: where are these packaging efforts?
<ajmitch> I haven't seen 2x.com as much of an improvement on the nx mess
<Seveaz> kanotix
<tepsipakki> in the meantime, I have the 2.1.0 mess compiling atm :)
<Seveaz> it's an improvement, all parts are free
<tepsipakki> thats good
<Seveaz> it's still messy though
<tepsipakki> I took the nx-1.4..+1.5.0-11ubuntu1 and made some changes to the patches so at least it is compiling right now.. we'll see if it get's through
<tfheen> have they stopped shipping a complete copy of an X source tree yet?
<tepsipakki> nope :)
<tfheen> won't make the archive, then
<pygi> tfheen: why would someone do that? :-/
<tepsipakki> oh that's the reason.. wondered why there were no packages
<tfheen> pygi: because somebody had a very bad idea one morning, or something?
<pygi> tfheen: right :-/
<doko> gicmo: slacker!
<gicmo> hey!
<sivang> hey gicmo 
<dholbach> doko, gicmo: having fun? :)
<gicmo> dholbach: sure enough!
<doko> dholbach: stay at your session, no more place on the couch ...
<seb128> dholbach: aren't you suposed to draft telepathy? :p
<bhale> seb128: will we get galago in main?
<dholbach> doko, gicmo: don't worry - I'll leave you guys the couch - enjoy your time there together ;-)
<bhale> seb128: with telepathy?
<pygi> seb128: we did that already I think? :P
<dholbach> seb128: i'm working on it
<seb128> bhale: we didn't really speak about galago 
<seb128> dholbach: suuuuuure :)
<gicmo> dholbach: yeah, the couch! ;-D
<seb128> couch rulez!
* dholbach slaps seb128
<seb128> heh
<bhale> vibe the fuck out?
<seb128> we are working like house elves there!
<tfheen> cuddly house elves you are
<sivang> couch ?
#ubuntu-devel 2006-11-07
<tepsipakki> Seveaz: well, the 2x.com version doesn't seem much better ;) the 110MB tarball contains not only the X tree (twice) but also many other static source-tarballs
<tepsipakki> (like cups, openssl, zlib...)
<tepsipakki> but maybe the are there only because of GPL
<tepsipakki> I'll be damned, the nx build went through.. time to test it tomorrow
<lifeless> doko: where are you ?
<doko> lifeless: in the auditorium
<lifeless> theres an auditorium ?
<doko> lifeless: the big room, near the food
<lifeless> Riddell: your branch is out of dat e with edgy :(
<seb128> Keybuk: http://weblogs.mozillazine.org/ben/archives/009210.html
<Burgwork> seb128: what was the final conclusion from that tab discussion?
<Keybuk> Burgwork: we're eliminating all tabs from all applications and using multiple windows
<Burgwork> Keybuk: right
<seb128> tabs are evil
<Burgwork> and who is going to carry all those patches?
<seb128> the packages
<Burgwork> I can't wait to see Mozilla react to this one :)
<apokryphos> wow, very surprising
<_ion> I'm okay with eliminating tabs from applications as long as the window manager is modified to have tabs or changed to one that has.
<_ion> One issue with Firefox is that opening a new window takes *much* longer than opening a new tab.
<Riddell> lifeless: mm, I certainly thought it was up to date
<plugwash> yeah, i really can't see mozilla standing for ubuntu shipping a patch to eliminate tabs in a branded firefox
<thom> plugwash: why would you patch? it's just an about:configure option
<lifeless> Riddell: archive is ubuntu16, your branch is ubuntu15
<lifeless> ogra: find me today (after wrap up) please to talk hwdb.
<Riddell> lifeless: yeah, just read your e-mail, I'll fix that when I have a moment (which could well be next week)
<lifeless> Riddell: thats fine, I'm not blocked. But the longer the larger the merge skew :)
<jdong> doko: ping regarding Azureus bug 42269; I heard you have a fix ready?
<Ubugtu> Malone bug 42269 in azureus "Does not create a tray icon" [Medium,Confirmed]  http://launchpad.net/bugs/42269
<doko> jdong: did I say so?
<jdong> doko: crimsun told me that you had a fixed orig.tar.gz ready to go :D
<jdong> I'm going by what I've heard
<jdong> either way, I have fixed source packages available if you can spare the time to flex your upload muscles :D
<jdong> or whatever the new-fangled SRU policy dictates
<Fujitsu> jdong: Azureus is universe, is it not?
<bluefoxicy> someone is telling me upgrading to edgy isn't supported, you have to do a full reinstall?   o.o
<jdong> Fujitsu: yeah
<doko> jdong: it's universe, so oyu have to talk to dholbach first
<bluefoxicy> I thought update-manager -c worked
<Fujitsu> doko: Not quite.
<jdong> all I'm saying is that the bug has been there for a year, the fix has been ther for a month.... I'd like to prod it forward towards a fix!
<Fujitsu> jdong: You need to get the update approved by a MOTU, uploaded to {distro}-proposed, tested by 5 people for full workiness, wait for a week, then get somebody to upload it to -updates.
<Hobbsee> bluefoxicy: from what?
<jdong> Fujitsu: ok, hmm
<Fujitsu> Hey Hobbsee.
<Hobbsee> hey Fujitsu 
<jdong> I guess I should head to -motu for this then
<Fujitsu> jdong: Certainly.
<bluefoxicy> Hobbsee:  Dapper
<doko> jdong, Fujitsu: dholbach will update the process/wiki
<bluefoxicy> speaking of unsupported activity, when is edgy+1 opening?
<Hobbsee> bluefoxicy: maybe you'd better tell the person to put down the crack pipe.  mind you, unofficial stuff like automatix and beryl tend to bring breakage.
<Fujitsu> doko: Are you sure he is doing that?
<Fujitsu> bluefoxicy: Feisty will open when it opens.
<bluefoxicy> I am starting to get tired of not having to wonder if X will break the next time I reboot
<Hobbsee> hah
<jdong> Hobbsee: yeah, it seems like unofficial stuff has really taken its toll this time around
<bluefoxicy> Feisty ... ?
<doko> Fujitsu: you are allowed to kick him if he doesn't ;)
<bluefoxicy> Fox?  Folf?
<Fujitsu> bluefoxicy: Feisty Fawn.
<bluefoxicy> wtf is a fawn
<Hobbsee> jdong: they backported mesa and xorg to a higher version than what was in edgy, according to quinn.  enough said.
<Fujitsu> bluefoxicy: A baby deer.
<jdong> Hobbsee: why don't we, when upgrading, pin official repositories to priority 9999 ?
<jdong> or higher :LD
<bluefoxicy> Fujitsu:  oh ok
<Hobbsee> jdong: i've got no idea.  maybe more effective would be to just reinstall dapper's versions of everything, then dist-upgrade.  but what's the point, you lose the config?
<jdong> Hobbsee: both would work. Your proposal is more sane and probably will work better
<jdong> (restore a Dapper system before upgrading)
<jdong> but either way, as long as it's automated, all's good
<Hobbsee> jdong: true.  i believe mvo is trying to make it more sane
<jdong> that's good to hear
<jdong> I know it's easiest to blame 3rd party packagers for these problems....
<jdong> but it'd be really nice if Ubuntu was more resilient to this
<Hobbsee> well, when it's their problem....unfortunately, we cant really fix their stuff
<jdong> we can't expect to control what users install, and how they go about doing it
<Hobbsee> of course - but htey cant expect their stuff to all dist-upgrade properly either
<jdong> right
<jdong> but there are some feasible workarounds that we can implement to hopefully make it go more smoothly
<Hobbsee> we can make it easier so that they wont need to use crack though.  to a degree
<Hobbsee> true
<plugwash> i heared a lot of people mention ubuntuguide with regard to stuff that is liable to break your next upgrade
<jdong> Hobbsee: in addition, most of the broken upgrades I've had to deal with were easily fixable
<Hobbsee> true
<jdong> Hobbsee: with combinations of dpkg --configure -a, dpkg --force-overwrite $pkgname, apt-get -f install, apt-get install ubuntu-desktop, etc
<Hobbsee> plugwash: true.  i didnt think ubuntuguide was that bad...
<jdong> those are all things a script can try
<Hobbsee> jdong: force overwrite is a scary option to do via a script - how do you know what you're overwriting?
<jdong> Hobbsee: the guide does have some HOWTO's that instruct to install some guy's debs
<Hobbsee> true
<jdong> Hobbsee: judging that the upgrade is TO an official Ubuntu version, I would HOPE an overwrite is appropriate :D
<Hobbsee> good point.  but then they lose their config?
<jdong> I wouldn't say so
<jdong> config files aren't affected by installing a new deb package
<jdong> they are managed as config files
<jdong> force-overwrite only applies to the non-config files....
<Hobbsee> they do?
<jdong> config files are handled in the Setting up $pkgname step....
<jdong> and if there are differences, the user gets prompted about it
<jdong> also, dist-upgrader should check for locally installed packages, and also members of the 'checkinstall' group, and warn users about these packages
<jdong> especially if they are members of checkinstall :D
<jdong> Fujitsu: can you acknowledge in the bug ticket that someone is doing something about it? :D
<jdong> mv lastmessage #ubuntu-motu
<Hobbsee> but the user doesnt know, and shouldnt have to
<plugwash> imho anything not installed from official or known sane unofficial repositries should trigger a warning
<jdong> plugwash: +1
<leonel> no official ubuntu  position on the ms - novell agreement 
<leonel> ?
<plugwash> leonel what agreement?
<Hobbsee> heya mpt 
<Hobbsee> leonel: why would ubuntu have one?  and you wont get one at this time of day
<jdong> leonel: does Ubuntu have to give a statement on everything that happens in the IT world?
<jdong> I'd really love a Mark Shuttleworth statement on my recent purchase of a 12-inch Subway sub that had a free Coke with it
<leonel> wow  nice  answers ...
<Hobbsee> leonel: basically, the people you want arent around here - they're all together at a conference.
<leonel> Hobbsee: what worries me  is that they say that  only suse is free from  patent problems   that's why I'd like to hear something from Ubuntu  about it  as redhat did   that's all
<tepsipakki> does the "don't show tabs on default" mean that I'm still able to open a new one with ctrl-t (or similar) on firefox et al? the spec-wiki doesn't mention that
<Treenaks> yes..
<tepsipakki> phew..
<Treenaks> I don't see a tab bar when I only have one tab, basically
<tepsipakki> makes sense
<Treenaks> which has been the default since forever, afaik
<tepsipakki> but not on every app that uses them
<tepsipakki> like gedit
<Treenaks> gedit should abandon them :)
<Treenaks> imho
<tepsipakki> altogether? noo :)
<Treenaks> Except for web browsers, I'm a one-window one-file kind of person
<tepsipakki> but.. that's not consistent :)
<Treenaks> I never claimed to be consistent ;)
<tepsipakki> heh
<tepsipakki> I never use gnome-terminal tabs.. so there
<tfheen> tepsipakki: sure is, all applications using tabs will then behave in the same way.
<Treenaks> tepsipakki: gnome-terminal tabs should map to screen screens.. THEN I'll be happy ;)
<Fujitsu> Treenaks: Wouldn't that be just so nice!
<Fujitsu> screeen FTW!
<Ng> Treenaks: you can do that with screen -x, but obviously it's a manual setup process per-tab
<tepsipakki> tfheen: yes, thanks for clarifying that.. I was close to getting upset about the change, until I saw what it really meant :)
<Treenaks> Ng: it also breaks when I do Ctrl+A space ;)
<Ng> Treenaks: well yeah, you'd use the g-t shortcuts for next/previous tab
<mnepton> Hobbsee: Brandon keeps asking if i have nude photos of you. make it stop.
<Hobbsee> mnepton: hah.  no one has any of them.
<mnepton> Hobbsee: that you know of.
<Hobbsee> mnepton: i'd know if any had been taken.
* Mez does
<Mez> wait... of Hobbsee?
<Burgundavia> mnepton: I can said him nude shots of me with her head pasted on? :D
<Mez> wrong person ;)
<Burgundavia> might be good for a laugh
<Hobbsee> hahaha
<Mez> Burgundavia, DO IT :P
<Mez> hmmm
<Hobbsee> i'm sure that'd work out *real* well among a dev conference.
<Mez> my router sounds like a brothel
<Mez> "multiple PVC operation"
<Hobbsee> Burgundavia: that would raise interesting questons
<mnepton> we could just blame Novell
<Mez> since when has feisty been open ?
<mnepton> 10/28
<mnepton> errr, 26
<mnepton> Burgundavia: are you not at UDS?
* Hobbsee notes that typing pbuilder-edgy update has become habit, by now
<StevenK> I see that, does that mean the toolchain is sorted out?
<Burgundavia> mnepton: I wish. Work and I disagreed about whther I should go. I lost
<mnepton> grah. le suck.
<Mez> hmm... /me doesnt know
<Mez> I just got a bounce from someone uploading a new version of katapult
<Mez> or maybe everythings still under manual revire ?>
<Mez> review *
<mnepton> Burgundavia: anything you need brought to anyone's attention?
<StevenK> Feisty is set to DEVELOPMENT, so it should be okay.
<Burgundavia> mnepton: nope
<Burgundavia> I have my little minions doing my work for me
<mnepton> heheheh
<mnepton> is any of that work "give mnep cash?" and if not, why?
<Hobbsee> mnepton: because its' going to me.  duh.
<mnepton> *facepalm*
<Burgundavia> mnepton: no, no it is not
<mnepton> i love you, too, Corey :)
<Burgundavia> I try, but I am broke currently
<Burgundavia> end of the month, I am rich, but not today
<CheGuevara> hi
<ereminii> have everyone been able to get the latest feisty updates
<ereminii> like new gnome etc
<Hobbsee> most people arent trying to run feisty on a separate partition yet
<Hobbsee> and no, that wont have been merged yet
<ereminii> heh i run it on the one and only box as main os
<ereminii> oh that explains it
<ereminii> i just saw them all in commit log
<ereminii> but in update manager its empty
<Hobbsee> that's kinda....silly...to say the least
<ereminii> after using gentoo unstable for 2 years, i am pretty sure it dont get more on the edge then that
<Hobbsee> oh good, as long as you're aware
<Hobbsee> and know how to use dpkg when apt breaks
<ereminii> yeah
<ereminii> i am probably am silly
<ereminii> just like always having the latest versino numbers
<ereminii> cant explain it heh
<hunger> ereminii: gentoo was always behind debian with package versions (both unstable) with all the packages I cared about.
<ereminii> gentoo ehind packages vesions?
<ereminii> seems impossible heh
<ereminii> filing bug reports usually works
<ereminii> unless of course its some rare stuff with no maintainer
<hunger> ereminii: Well, I tend to care about the rare stuff:-)
<ereminii> oh heh
<ereminii> fun starts when u downgrade glibc lol
<ereminii> gotta take off battery almost died
<ereminii> cya and thx for ur help
* Mez -> bed
<blujay> Can I get a dev's attention on a very widely-annoying Edgy bug that desperately needs to at least have a priority set in Launchpad?  bug#64841
<Fujitsu> bug #64841
<Ubugtu> Malone bug 64841 in wlassistant "wireless assisant does not connect in edgy" [Undecided,Confirmed]  http://launchpad.net/bugs/64841
<blujay> (Hm, on a different note, perhaps Ubugtu could also recognize "bug#xxxx" format as well.  :)
<Hobbsee> blujay: why not use knetworkmanager?
<Hobbsee> and what's the solution there?  fiddling with the interfaces file?
<blujay> Hobbsee: Well, I thought it was pretty widely-known that NetworkManager only works for a few cards/configurations right now.  And no, the problem seems to be something with either dhclient or the kernel; fiddling with /etc/network/interfaces doesn't fix it.
<blujay> Hobbsee: One of the duplicate bugs (there have been about 4 now) had a high priority set, but this one (the first) has none.
<Hobbsee> hmmm
<Hobbsee> hmmm, i thought it looked familiar. i replied to one of those bugs
<blujay> Hobbsee: This is one of the things that bugs me about Ubuntu.  In Debian anyone can adjust the priority of bugs, but in Ubuntu...this bug has been filed for a long time, and has had many dupes, but no devs are taking notice, but it's very important.
* StevenK notes wlasistant is in main, and therefore takes his motu-sru hat off.
<StevenK> blujay: It's important to *you*.
<Hobbsee> blujay: just because it's set to high doesnt mean that any devs necessarily see it.  
<blujay> StevenK: This affects most wifi users on Edgy.  Isn't that important?
<Hobbsee> blujay: excluding all the ones who arent using knetworkmanager or dhclient, yes
<StevenK> And using wlassistant.
<Hobbsee> StevenK: it's a kde thing.  i've never been able to get the bugger to work, but i'd presumed it was a config somewhere
<StevenK> Ah.
* Hobbsee sets it to high.  and?
<blujay> wlassistant works fine in Dapper, perfectly.  It worked in Edgy Knot2.  But not since then.
<StevenK> The bug said Knot 3. 
<blujay> StevenK: ...ok so I was off by one.  The point remains.  :p
<blujay> Hobbsee: thank you.
<Hobbsee> blujay: not a problem, but that doesnt really change anything
<blujay> Hobbsee: Well...do you have any suggestions for getting the devs to pay attention to this?
<StevenK> blujay: If you have the skills/want to learn, debugging it out could really help.
<Jozo-> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375551 wlassistant: Wrong call to dhclient 
<blujay> StevenK: I'll be glad to help the devs, but digging into it isn't really practical, because I have a very old, very slow laptop to run it on.
<Ubugtu> Debian bug 375551 in wlassistant "wlassistant: Wrong call to dhclient" [Normal,Open]  
<Hobbsee> blujay: they're at a conference this week.  i dont think they're going to do anything about it at the moment
<StevenK> blujay: That isn't a problem.
<blujay> Hobbsee: Well I realize that, but...after that?  I mean, this was broken in the Edgy process.  It's just a shame.  :/
<blujay> Jozo-: thanks, I'll add that to the Launchpad report
<Hobbsee> StevenK: do you know the debian maintainer?
<StevenK> I know of him.
<Hobbsee> StevenK: is he active?
* StevenK checks.
* StevenK waves his leet-DD powers around.
<Hobbsee> hehe
<Hobbsee> dont wave them around too much.
<StevenK> :-P
<StevenK> Hobbsee: Unsure. 
<Hobbsee> StevenK: what happens if you remove -r from the config?  does it work then?
<StevenK> Hrm?
<Hobbsee> StevenK: the debian bug
<StevenK> How can I be lazy when you're asking me to a look at bug!
* StevenK lugs out the laptop.
<StevenK> s/\(bug\)/\1s/
<Hobbsee> hehe
<StevenK> Neat.
<Hobbsee> hmmm?
<Hobbsee> i seem to remember reproducing debian's bug before
<StevenK> wlassistant is dragged in by kubuntu-desktop.
<Hobbsee> yes, it is
<Hobbsee> as we dont load knetworkmanager by default, and kwifimanager is a POS
* StevenK wishes NetworkManager was a little less buggy.
<Hobbsee> indeed
<StevenK> Oh geez, I hope I don't have to install kubuntu-desktop on my laptop.
<StevenK> I'll kill networkmanager and see if I can convince wlassistant to work
<blujay> StevenK, Hobbsee, thank you for checking this out.
<Hobbsee> okay
<Hobbsee> blujay: that doesnt mean we'll be able to fix it
<blujay> Hobbsee: I know, but I still appreciate your checking.
<StevenK> Oh neat.
<StevenK> wlassistant looks to be crap, too.
<blujay> I had a feeling that, "Oh neat," was sarcasm.  :)
<blujay> StevenK: It's not great, but I will say that it works fine in Dapper, and it's the only GUI WiFi tool that does, AFAIK.
<StevenK> Yeah, who'd thunk it. :-P
<blujay> StevenK: for KDE, that is.
<Hobbsee> StevenK: yeah well.  breezy was worse
<StevenK> KDE users should stick to wired. :-P
<Hobbsee> hah
<Hobbsee> yes, but what about gnome users?
* StevenK holds his breath, and downloads the source.
<Hobbsee> you mean you hadnt?  what were you looking for before?
<StevenK> The debug log.
<StevenK> That told me enough
<StevenK> The amount of *crap* it spews to the console? I mean, geez
<Hobbsee> NM is worse
<Hobbsee> mind you, it's built wiht a very verbose wpa supplicant
<vogelfaull> why
* StevenK looks for a debug-me-harder option for wlassistant.
<Hobbsee> haha
<vogelfaull> why
<Hobbsee> the last log it appears to work....right?
<Hobbsee> vogelfaull: ?
<vogelfaull> why
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+b *!*@84-72-41-27.dclient.hispeed.ch]  by Hobbsee
* vogelfaull was kicked off #ubuntu-devel by Hobbsee (Hobbsee)
<Hobbsee> dont you start here too, you rotter...
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<StevenK> I hope I'm reading this wrong.
<Hobbsee> StevenK: which bit?
<StevenK> "Let's set all of this stuff up. Okay, done. Now let's kill the DHCP client. Hrrrm, I don't seem to have a connection."
<bhale> Hobbsee: why?
<Hobbsee> bhale: because i said so!
<Hobbsee> :P
<bhale> :)
<Hobbsee> StevenK: yes, i *thought* that might be what it said.   and then appears to want to kill it harder
<lastnode_> Hobbsee, he had a very limited vocabulary :-)
* lastnode_ reads back the logs
<Hobbsee> lastnode_: the idiot was just in #ubuntu too - which was why i banned him so quickly
<lastnode> :-)
<Hobbsee> right, that's *3* channels the rotter has now been banned in
<Hobbsee> [23:08]  [Whois]  vogelfaull is a user on channels: ##php #emacs #nethack #wikipedia-de
* Hobbsee wonders where to, next
<blujay> Hobbsee: I'm curious..."rotter"?  Where did that originate?
<StevenK> rotter
<StevenK>        n : a person who is deemed to be despicable or contemptible;
<apokryphos> blujay: just possibly a bot. Same "why" repeating or general other abusive messages
<Hobbsee> blujay: no idea?  rotter being rotten person?
<Hobbsee> apokryphos: or an annoying user
<Hobbsee> apparently it's a java user, but...
<blujay> Hobbsee: ah, just not used much in the US I guess
<apokryphos> right
<Hobbsee> blujay: musnt be
<StevenK> blujay: But neither is English.
* StevenK ducks.
<blujay> StevenK: hehe...where are you from then?
<StevenK> .au
<blujay> ah
<lastnode> i hate you xchat win32 :\
<blujay> at least most of us don't eat Vegemite...yech
<lastnode> Hobbsee, had a chance to check out the Upstream .debs yet? :-)
<StevenK> Right, I'm mistaken, it does run dhclient.
<Hobbsee> lastnode: nope
<StevenK> blujay: But Vegemite is great!
<lastnode> marmite rocks btw
<Hobbsee> StevenK: after killing all other copies of it, apparently.  or trying to
<blujay> StevenK: I actually tried some once, brought to the US by a genuine Australian.  But...great?  ...?  :)
<lastnode> Hobbsee, cool, just asked
<Hobbsee> :)
<StevenK> blujay: All I know is I like it on toast with butter.
* lastnode resolves to trying reverse psycho on Hobbsee 
<StevenK> Occasionally by itself on a knife, too.
<blujay> StevenK: with butter too?  wow
<lastnode> Hobbsee, don't get them .debs, ever!
<Hobbsee> haha
<Hobbsee> lastnode: fix wlassistant, kthnksbye!
<lastnode> lolz what is wlassistant kk?
<lastnode> Hobbsee, bug number?
<StevenK> Hobbsee: That's, 'ktnxbye'
* lastnode opens firefox
<lastnode> kthxbye
<StevenK> Oh right.
<StevenK> I was closer.
<StevenK> AH HA!
* lastnode hung out on Efnet far too long to ever forget how to spell that
<Hobbsee> lastnode: bug 62156
<Ubugtu> Malone bug 62156 in dhcp3 "no ip address after boot" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62156
<Hobbsee> oops
<StevenK> I know what is going on.
<Hobbsee> lastnode: https://launchpad.net/distros/ubuntu/+source/wlassistant/+bug/64841
<Ubugtu> Malone bug 64841 in wlassistant "wireless assisant does not connect in edgy" [High,Confirmed]  
<Hobbsee> StevenK: what?
<lastnode> lolz wrong bug kthx bye
<StevenK> wlassistant fires off dhclient, which complains about a zero length PID file on stderr. wlassistant takes any output on stderr as being a problem, and so kills dhclient.
<StevenK> Stupid bloody things.
<blujay> Yay, good job StevenK!
<StevenK> So the bug is dhclient being a piece of crap. :-P
<StevenK> The bug can be worked around in wlassistant, however.
<StevenK> Which requires learning QT file handling functions.
<StevenK> And coding C++.
<Hobbsee> hahaha
<StevenK> Neither really appeals.
<Hobbsee> StevenK: or fix dhclient?  nah...
<StevenK> Maybe.
<StevenK> dhclient sucks a lot, though.
* StevenK takes the fourth option, and runs away to the shops.
<Hobbsee> am i being slow tonight, or do you just have to check if the output on the stderr is about the zero length PID, or nothing else fail?
<blujay> StevenK: is there anything that doesn't suck? :)
<Hobbsee> haha
<Hobbsee> blujay: sure.  linda.
<StevenK> Hah!
<Hobbsee> or does that suck too?
<blujay> Hobbsee: I know lintian  but I'm not familiar with linda
<StevenK> Of course it does, I wrote it.
<Hobbsee> blujay: its' another package checker
<Hobbsee> hahaha
<blujay> ah
<StevenK> Hobbsee: The point is dhclient should remove it's PID file on exit.
<Hobbsee> well, seeing as you tend to write sucky things, how about you fix it so it doesnt suck
<Hobbsee> true that
<StevenK> Hmph!
<blujay> StevenK: So, how come Dapper and pre-Knot3 didn't have this problem?  :/
<Hobbsee> heh
<StevenK> blujay: dhclient could have been upgraded?
<Hobbsee> blujay: i think i saw one there for knot 2.  but a dhclient update could do ti
<StevenK> Hobbsee: Why don't you fix it? :-P
<blujay> StevenK: so, a new bug in dhclient, or a regression...?
<Hobbsee> StevenK: because you like fixing things
<StevenK> blujay: Oh, who knows. dhclient is getting that bad it could have damn well updated itself
<blujay> hehe
<StevenK> Anyway, gone now.
<blujay> StevenK: thanks for looking into it, I'll update the bug report
* StevenK will look at a fix in about 5
<Hobbsee> why is he going shopping for anything at this time of night?
<Hobbsee> oh yeah, i see the problem now
<StevenK> Hobbsee: Because we ran out of milk.
<Hobbsee> StevenK: ahh
<StevenK> Right, this bug can fixed in one (or more) of three ways.
<StevenK> 1. wlassistant shouldn't assume stderr means an error.
<StevenK> 2. dhclient cleans up its pid file on exit.
<StevenK> 3. dhclient ignores zero-length pid files when it starts.
<StevenK> I think it should be fixed in dhclient, since this might be biting other things.
<Hobbsee> so will you take 2 or 3?
<StevenK> Ahh, that I'm not sure about. :-)
<Hobbsee> and will they accept it as a SRU?
<StevenK> That's up to Kamion and/or mdz.
<StevenK> I suspect so.
<StevenK> When was knot 3 released?
<Hobbsee> sometime before 19/10
<StevenK> I hope so, that being the beta date
<Hobbsee> maybe a week before, or something?
<Hobbsee> yeah
<StevenK> Hum.
<StevenK> I think silencing it is the easiest option.
* StevenK notes it's already patched somewhat.
<StevenK> Submitted by pitti, even
<admin123> ok oem-config doesn't work correctly with nl_NL@euro it crashes!
<admin123> i tried this on several machines, and they all work fine with oem-config until a missing locale is generated nl_NL@euro
<Hobbsee> abattoir: ^
<Hobbsee> abattoir: or is that not your domain?
<Hobbsee> StevenK: fix it harder?
<StevenK> dhcp3 is building now.
<Hobbsee> :)
<StevenK> But I will talk to pitti about it.
<abattoir> Hobbsee: i think Kamion would be in a better position to answer it ;)
<abattoir> admin123: was the installation in a
* StevenK forces networking on his laptop up so he can actually scp to it.
<abattoir> *in English?
<Hobbsee> abattoir: ah
* StevenK grins shiftily
<Hobbsee> StevenK: heh.  clever
<StevenK> Hobbsee: Hush.
<abattoir> bug 68030
<Ubugtu> Malone bug 68030 in oem-config "configures wrong locale" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68030
<abattoir> admin123: is it similar to that^^^ ?
<StevenK> Oh DAMN
* StevenK rebuilds dhcp3, this time for the correct arch.
<Hobbsee> haha
<Hobbsee> StevenK: *very* clever.
<StevenK> Hmph.
* Hobbsee hugs StevenK 
* StevenK smiles.
* StevenK hugs Hobbsee back.
<Hobbsee> :
<Hobbsee> :)
* StevenK sighs.
<StevenK> I have this feeling the way dhclient handles its pid files leaves a lot to be desired.
<Hobbsee> hehe
<Hobbsee> you can do it!
* StevenK sighs.
<StevenK> If you don't initialise the variable, it's very hard to see if it's been set because it's full of uninitialised memory.
<StevenK> Yes, pitti this means you!
<Hobbsee> haha
<Hobbsee> what's it in?  python?
<StevenK> C, if you please.
<StevenK> Python doesn't suffer from this problem.
<Hobbsee> ah
<Hobbsee> c++ it at least generates a warning.  then again, if there are a lot of them...
<StevenK> That's a point.
<pepsiman> python throws an exception
<StevenK> Oh yeah
<StevenK> Hobbsee: Yes, if you compile with -Wall... which dhcp3 doesn't. :-)
<Hobbsee> ah
<StevenK> Well, -W<stuff>
<Hobbsee> heh
<neuralis> pepsiman: no, python doesn't have the concept of uninitialized variables. don't confound this with undeclared variables.
* StevenK threatens wlassistant with a large electromagnet.
<Hobbsee> haha
* infinity tries to decide if it's jetlag, stress, or just garden variety insomnia that's kept him up all night.
<StevenK> infinity: Oh good, wanna help me debug this bloody thing? :-P
<StevenK> "ifconfig_dhcp: /sbin/dhclient -q eth1"
<StevenK> *pause*
<infinity> Wasn't making feisty's kernel build on i386 and doing a few more hours of hppa bootstrapping enough good deeds for the night? :)
<StevenK> "kill_dhcp: /sbin/dhclient -r eth1"
* StevenK sighs.
<neuralis> infinity: i've been unable to sleep as well.
<Hobbsee> infinity: nope
* StevenK is trying to get to bed, actually.
<infinity> Bah, it's only 12:30 back home.
<Hobbsee> you're losing that battele
<Hobbsee> *battle
<infinity> Be a man.
* Hobbsee can go to bed, on that basis :D
<StevenK> My wife has already asked me to come to bed twice.
<infinity> Oh, then be a man and go to bed with your wife. :)
<StevenK> Bwahaha
<highvoltage> heh
<StevenK> The conclusion I'm coming to is that wlassistant is POS.
<StevenK> is a, even
<StevenK> Use knetworkmanager, => Rejected
<StevenK> :-P
<infinity> NM does the job for me.
<infinity> No perfectly, but "well enough".
<StevenK> Which ever bastard though writing a C++ KDE GUI wrapper around dhclient, ifconfig and iwconfig needs to be SHOT.
<StevenK> s/iwconfig/iwconfig was a good idea/
<Hobbsee> haha
<StevenK> infinity: Can I at least bounce ideas of you? I know what the problem is, even if I haven't fixed it.
<infinity> Bounce away.
<infinity> I may put on some pants, sneak out of the room (without waking thom, fun!) and go have a smoke.
<StevenK> infinity: The problem is that wlassistant fires off dhclient -q eth1, notes there's output from dhclient saying that it has a stale pid file on stderr, declares the sky is falling and kills dhclient.
<pepsiman> neuralis: technically you're right, but in practice it's the same thing
<StevenK> So we can either fix wlassistant to ignore that erorr, or have dhclient not complain.
<infinity> StevenK: And doing those steps by hand, you're confirming that wlassistant is correct about dhclient's crackful returns?
<StevenK> That was reading the code by hand.
<StevenK> There seems to be something else going on, though.
<StevenK> I've rebuilt dhclient to quieten it, and it still doesn't work.
<StevenK> Ahh, no. It's because my rebuild causes dhclient to segv.
<StevenK> Riiiiiight.
* StevenK finds a brown paper bag.
<Hobbsee> heh
* Hobbsee|Remote removed all the brown paper bags from your house long ago
<Hobbsee|Remote> they're good for setting on fire
<fabbione> morning
<StevenK> Really now?
<Hobbsee> hey fabbione (here too!)
<Hobbsee> StevenK: of course!
<StevenK> That's curious, since I still found one.
<StevenK> So nyah
<infinity> Hotel wireless go boom.  Yay.
<Hobbsee> hehe
<StevenK> Heh
<infinity> StevenK: Hah.  Fixing the segv fixed it? :)
* infinity was about to grab the wlanassswhataver source to step through.
<StevenK> I tell you, killing NetworkManager every 3 minutes is therapeutic.
<Hobbsee> haha
<Hobbsee> sure it is :)
<StevenK> Right. SEGV fixed.
* StevenK puts the "id10t" sticker back on his forehead.
<infinity> Was the segv from your "insult pitti and initialise his variables for him" fix?
<StevenK> Yup
<infinity> Always classy to introduce a worse bug when fixing a lesser one. :)
<StevenK> Well, I try. :-)
<StevenK> long temp = 0; fscanf(..., &temp); made it blow up.
<infinity> Gee, I can't imagine why.
* StevenK idly notes scanf was never his strong point. :-/
<infinity> (Also, hooray for useless variable names, pitti)
<StevenK> Heh
<StevenK> scanf() and friends just seem to be entirely counter-intuitive.
<infinity> Well, I won't disagree there.
<StevenK> infinity: What bonehead did I make, so I can file it away?
<StevenK> bonehead error, even
<StevenK> Okay, wlassistant, you suck.
<StevenK> DHCP works, and it goes on to test the connection by some nefarious means, and fails.
* Yagisan waves
<StevenK> Ahh, more Aussies who can't/won't sleep.
<Yagisan> StevenK, its can't and only because I recently threw out a crackful, Win32 centric threading system and replaced it will SDL threads, and apparently I'm supposed to test it
<Yagisan> StevenK, I mean, isn't that what users are for ;)
<StevenK> Indeed.
<StevenK> Just applications are the test suite for the kernel. :-P
<StevenK> Just like
<Yagisan> StevenK, at least you know "temp" is a temp variable, code I just fixed had "i" as a temp counter O_o
<StevenK> Heh.
<StevenK> I like using i as a counter for short for loops.
<Yagisan> StevenK, and for reasons unknown to me, assumes pointers = ints everywhere. :'(
<StevenK> Yagisan: Because that holds true on i386? :-(
<Yagisan> StevenK, and 32bit powerpc
* StevenK waves his amd64 at that code.
* bhale waves StevenK at his amd64
<Yagisan> StevenK, if you want to chat more about it, we can go to pm
<StevenK> Yagisan: Heh, I'll cope. :-)
<StevenK> bhale: Ah, but is your amd64 a quiet SFF PC? :-)
<bhale> StevenK: no its a big loud dell 2850
<StevenK> Heh
<bhale> actually a dozen or more of them
<Yagisan> my poor abuse amd64 is in a big ugly green tower that looks like it houses an old i386 server
<Yagisan> s/abuse/abused
<StevenK> Heh
<Yagisan> my p2 is in the shiny new case
<bhale> that gives me an idea to mod an SFF into my sgi o2 chassis
<bhale> not that I would do it
<Yagisan> so if it gets pinched, someone gets a rude shock :)
<neuralis> pepsiman: no, it's really not the same thing at all.
<bddebian> Howdy
<sladen> iwj: is there an equivalent way to (/updates) of updating dpkg/available without having to rewrite it each time?
<sladen> iwj: see the Issues section at the end of https://wiki.ubuntu.com/LiveCDStackedFileSystem
<psusi> what's wrong with the file being replaced a few times?
<tfheen> sladen: unionfs doesn't give you diffs, it gives you the file multiple times anyway.  I've discussed evil ways of working around this already.
<sladen> tfheen: could you update the page if you already have a solution figured out
<tfheen> sladen: no, we have not decided on what approach we'll use.
<sladen> tfheen: if there are some ideas for a solution that I didn't write up, could you add them
<tfheen> sladen: the spec is not "we might want to pursue this approach, or this approach or this approach".  It's "we'll solve the problem this way"
<iwj> sladen: No, there isn't.
<sladen> tfheen: so, are there any other ideas ("I've discussed evil ways of working around this already") that are not one of the three listed at the bottom
* iwj goes to read ...
<sladen> iwj: thanks
<tfheen> sladen: correct.
<iwj> sladen: You could supply an empty available file and download it as needed ?
<sladen> tfheen: what are those other ideas, it would be useful to have them recorded somewhere
<fabbione> jdub: ping?
<Riddell> keescook, tfheen: I added KDE bits to network-roaming, please let me know if that's good or no
<tfheen> oh, this is special.
<tfheen> >>> isinstance("blah", str)
<tfheen> True
<tfheen> >>> isinstance(u"blah", str)
<tfheen> False
<tfheen> (yes, it's true, but it makes mailman unhappy)
<robertj> tfheen: I thought isinstance was eebil?
<tfheen> it's used in the email package
<tfheen> not my code
<thom> infinity: quit slacking and get lrm in for feisty
<chrisj> How do I submit a bugfix for a package thats in main?
<chrisj> a patch, it's just a one liner
<bddebian> chrisj: Attach it to a bug report
<Lure> chrisj: attach patch to bug
<chrisj> bddebian, Lure: thanks
<bddebian> NP
<keescook> Riddell: thanks for the kde bits; I think it looks fine.  We'll see what smurf thinks now.  :)
<keescook> doko: what do you think of turning on RELRO by default for the feisty toolchain?  gentoo seems to have tested this and not seen any problems with it.
<fabbione> keescook: too late
<fabbione> keescook: plus glibc detects it automatically
<fabbione> i don't think you need more than that
<cr3> fabbione: quick question about preseeding: how can I write or generate a preseed file?
<keescook> fabbione: yeah, figured it was too late, but I think I'd ask.  I thought the toolchain needed to mark up the ELF sections for glibc to actually allow for the differing segment permissions?
<desrt> seb128; poke
<seb128> outch
<desrt> got a sec?
<fabbione> keescook: not sure, but it's for feisty+1
<seb128> on IRC? yep
<fabbione> cr3: cjwatson.. i am not the installer god
<desrt> please make https://features.launchpad.net/distros/ubuntu/+spec/easy-codec-installation depend on https://features.launchpad.net/distros/ubuntu/+spec/gnome-app-install-codecs
<fabbione> pitti: ping?
<desrt> alternatively, please flip whatever switch will allow me to do so :)
<gnomefreak> is it safe to reboot when linux-libc-dev doesnt match kernel version?
<seb128> desrt: looking at doing the change, launchpad UI doesn't make it easy
<seb128_> desrt: done
<desrt> seb128_; thanks
<seb128_> np
<pitti> fabbione: busy pong
<fabbione> pitti: no rush.. libvirt is out of NEW
<pitti> ah, nice
<ulaas> hi where can i get good technical info on "upstart"
<doko> keescook: you missed the feisty toolchain session
<Ng> ulaas: upstart.ubuntu.com
<mario_> sivang, ping?
<cjwatson> Keybuk: can I just dump override-Ubuntu-changes syncs I want to make into ~lp_archive/syncs/ and have you punt them into the sync queue when you're done with the rest?
<mario_> hey cjwatson 
<cjwatson> hi
<niktaris> hi, I am trying to pass some preseed options to casper but it seems no to work. I am giving xserver-xorg/config/inputdevice/keyboard/variant=us,gr on the boot prompt. Anyone has an idea why ?
<cjwatson> niktaris: I'd recommend using console-setup/variant=us,gr instead - xorg should grab its defaults from there
<cjwatson> assuming edgy
<niktaris> hi cjwatson. I am trying to pass 2 options. 1 is the variant option to xorg.conf. and 2 the "Xkboptions" 
<niktaris> cjwatson, so basicly xorg.conf should have Xkblayout "us,gr" and Xkboptions "ctrl:alt_shift_toggle". Any tips ?
<niktaris> yes on edgy
<cjwatson> do you mean grp:alt_shift_toggle?
<niktaris> cjwatson, yes
<cjwatson> niktaris: just say console-setup/layout=gr and console-setup should sort out the rest
<cjwatson> it knows that gr is a non-Latin keymap and automatically does the us, variant and alt_shift_toggle business
<niktaris> lets see
#ubuntu-devel 2006-11-08
<niktaris> cjwatson, nope. It gives "Xkblayout us" and Xkboptions lv3:ralt_switch
<niktaris> cjwatson, I was hoping to get polytonic to work on it....
<niktaris> well I need gr(polytonic) for that but if plain gr is not working then....
<niktaris> cjwatson, selecting greek from F2 at boot gives the same but only gr instead of us
<exarkun> I am curious about the location of some Python packages in edgy.
<exarkun> What is the reasoning behind /var/lib/python-support/?
<LaserJock> exarkun: it's used by the python-support package
<LaserJock> to support the new Debian Python Policy
<LaserJock> I'm guessing that's what you mean
<LaserJock> or do you mean the specific choice of /var/lib/?
<lritter> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/63418
<Ubugtu> Malone bug 63418 in linux-source-2.6.17 "CPU soft lockup during bootup" [Medium,Confirmed]  
<lritter> somebody please calm down the riot? ;)
<exarkun> LaserJock: I am curious about the specific choice of /var/lib/, yea, but mainly about the choice of something other than /usr/lib/python<version>/site-packages/
<exarkun> LaserJock: So it is based on a Debian policy change for Python packages?
<LaserJock> exarkun: yes
<exarkun> Alright, thanks :)
<LaserJock> exarkun: the idea was to eliminate locking into a specific python version
<exarkun> That sounds like a big idea so I don't think I'll think about it too hard right now.
<LaserJock> exarkun: it's not too difficult of an idea
<exarkun> btw, the reason I noticed the change at all is that python-nevow seems to be broken in the base edgy install (importing anything from it results in a traceback).
<LaserJock> exarkun: interesting, have you filed a bug report?
<LaserJock> exarkun: the idea is we used to have to  provide a binary package for each supported python version for modules/extentions
<LaserJock> so python2.4-* and python2.3-*
<LaserJock> and python apps needed to use the default python version
<exarkun> LaserJock: I'm looking at launchpad now to see if it has been filed already.
<LaserJock> with the new policy python-support and python-central byte-compile for all the python versions and keep tack of things
<LaserJock> exarkun: if it's not, file it so it doesn't get lost somewhere in IRC space ;-)
<exarkun> It was.  I put a "me too" on the report. :)
<exarkun> https://launchpad.net/distros/ubuntu/+source/nevow/+bug/61423
<Ubugtu> Malone bug 61423 in nevow "Impossible to import nevow on edgy" [Undecided,Unconfirmed]  
<LaserJock> hmm, well I don't think it should be looking there
<pygi> sivang, ping
<TheMuso> c
<Burgundavia> d
<Fujitsu> e
<TheMuso> I could say F followed by a particular set of three letters, but I shan't.
<_ion> face? farm? fast? feet? file? film? fire? fish? five? flea? folk? font? food? fork? frog?
<TheMuso> hahahaha
<TheMuso> Yep, one of those. :)
<slomo> keescook: just FYI, the avahi package i uploaded yesterday will add the ipv4ll routes and installs itself as dhclient plugin that is used when dhcp gives no ip
<lotusleaf> Any plans for clamav to move up to 0.88.6 in Edgy? I hear there was a security related issue that was fixed re: 0.88.5. I build clamav myself every version, so personally I don't care, I'm just curious about the other folks who can't or don't build for themselves and use the repos.
<lotusleaf> And at present 0.88.4 is in the repos
<siretart> uuh, new nvidia binary driver just released. now with GLX_EXT_texture_from_pixmap support..
<siretart> http://www.nvnews.net/vbulletin/showthread.php?t=79719
<Burgundavia> siretart: that means that it works with AIGLX?
<siretart> Burgundavia: seems pretty close to the previous 'beta' releases
<Burgundavia> right
<Burgundavia> except for a whole "nvidia vs disclosure" thing, I am almost pleased
<siretart> the main difference seems that this release seems to be meant for 'production use'. (whatever that means)
<pygi> siretart, since you are involved in cdrecord packaging, why not be in #u-burning
<siretart> pygi: I'm not involved in cdrecord packaging. I considered it when the cdrkit fork started, though
<pygi> siretart, right, but still you should get involved with ubuntu burning team :)
<pygi> sec siretart :)
<pygi> siretart, http://pygi.pykix.net/?p=21
* pygi doesn't want to comment cdrkit mess :-/
<Burgundavia> pygi: what is wrong with cdrkit?
<pygi> Burgundavia, won't comment on that, sorry :)
<Burgundavia> ok
<Burgundavia> there is a real danger right now that every distro will got their own way with burning
<Burgundavia> which is bad
<Burgundavia> ie: start talking to debian pygi
<Burgundavia> :)
<pygi> Burgundavia, ie: I tried? :)
<Burgundavia> ah
<pygi> Burgundavia, most of cdrkit people refuse to listen to any sane advice
<Burgundavia> too bad :(
<pygi> true :(
<pygi> Burgundavia, and the thing is that this issue will have to be resolved during feisty cycle
<pygi> at least a provisional solution, but it'll have to be solved
<pygi> and I know what I'll suggest, if anyone will be willing to listen
<siretart> pygi: don't get me wrong, I'm of course very interested in improving the mess of cdburning in ubuntu and debian
<siretart> pygi: however, I'm currently busy as hell with my thesis, and I don't think I can spend much time in the ubuntu-burning team
<siretart> pygi: I'll consider joining you next year, okay?
<pygi> siretart, I know you are busy, don't worry :)
<khajjak> how i play mp3 files in ubuntu? any one help me plz
<gnomefreak> khajjak: ask in #ubuntu this is not a support channel
<khajjak> ubuntu is no such channel sir ?
<Fujitsu> khajjak: Type /join #ubuntu
<khajjak> oh ok
<niktaris> cjwatson, ping
<toresbe> Is the conf in Mt. View still going on?
<neuralis> toresbe: yes.
<toresbe> neuralis: Neat. You there?
<neuralis> yeah.
<toresbe> neat - you should tell the guys that they might want to check out the Computer History Museum in Mt. View - just down the street from Googleplex
<toresbe> I miss it... :)
<gnomefreak> neuralis: go back to bed its too early there to do anything ;)
<gnomefreak> its like 2 or 3 am there
<tarzeau> where can i find a person who maintains the ubuntu package that i get bug reports about?
<tarzeau> i maintain it in debian, and it works perfect for me, but ubuntu removes files and makes the software not work anymore
<tarzeau> this is really annoying to me, because i have no chance to fix bugs in ubuntu
<tarzeau> when i went to motu botu thingy they told me it makes no sense to create packages for ubuntu and then later debian
<Hobbsee> tarzeau: which package?
<StevenK> Hobbsee: -motu
<Hobbsee> ah
<sivang> hi all
<LockUp> I need free program to export ODT or DOC files to PDF/X-1a. What do you propose?
<giftnudel> hi sivang, do you have some time at the moment? (doesn't have to be a lot)
<Chipzz_> first of all, this is not a support channel
<jsgotangco> well I'm no PDF expert but doesn't OOo already do that
<Chipzz_> second, dunnow if there's a better way, but printing to a file should produce a .ps, which you can convert to .pdf
<LockUp> okay
<giftnudel> openoffice can export to a pdf directly
<LockUp> so I have some propositions to make Ubuntu good to desktop and easier for users :)
<LockUp> 1. Easier access to root (wait for more info).
<LockUp> a) remember password for this session - system won't ask user for root password until he will logoff
<jsgotangco> LockUp: dude, you are better off filing a bug or a spec for next release..an irc channel is pretty "chatty" for suggestions and can easily get bypassed
<Chipzz_> LockUp: that would actually be a security problem
<LockUp> b) if i want to get access to root, I must use SUDO command. It isn't so good for easy using and configuration.
<giftnudel> hmm, I got kicked out from my vpn ...
<_ion> I don't see what's the problem with the sudo command.
<LockUp> So it should be a option in context menu (right button of mouse) - "Open ... as..."
<Hobbsee> it already is, in kde at least
<Hobbsee> in konq
<jsgotangco> in konqeuror
<jsgotangco> yeah
<LockUp> but in Gnome - Ubuntu?
<Hobbsee> how the hell is pingus 10mb???    ouch!
<jsgotangco> well bug gnome :)
<LockUp> The next - installation program. Packages aren't so configurative. If it's a bigger program, it should have a installator - reading a licence, choosing components, choosing shortcuts, etc...
<LockUp> I propose to create a installation system in Ubuntu.
<jsgotangco> LockUp: dude?
<LockUp> Think about it. \away
<jsgotangco> in an irc channel? good luck, noise comes here so fast chat logs easily get filled up and your suggestions will just go to waste like i said, irc is not the proper forum for suggestions
<_ion> Yeah, i definitely want to read GPL every time i install a new program.
<Hobbsee> jsgotangco: has there been more talk of smart in this UDS?  i ahvent followed terribly closely
<giftnudel> _ion: the way openoffice does it, forcing you to even scroll down the license ...
<jsgotangco> i haven't the foggiest either, but smart seems to work well at the moment, but not something to really replace our stuff
<_ion> giftnudel: Yeah, that's very userfriendly.
<jsgotangco> i would say improve g-a-i for intuitiveness further and people won't even notice that its smart or what
<Hobbsee> jsgotangco: true that
<jsgotangco> we need the powers of glatzor and mvo!
<giskard> how i can install the complete *vim*?
<minghua> giskard: install vim-full.  and that question belongs to #ubuntu
<Huahua> giskard: sudo apt-get install vim-full
<Chipzz_> *vim* even :)
<mjg59> Uh.
<bddebian> Howdy
<aktiwers> Is it possible to get help with Java Programming here? I doing a project on my school and I am really stuck! But again its not really Ubuntu related 
<jdong> no... it's not possible to get any kind of programming help here...
<jdong> this is the developers' work room :)
<aktiwers> Ok thanks..  and sorry. Let me instead tell that I love you guys work! Keep it up! :)
<aktiwers> Can you maybe point me to a place where I can get help with Java Programming before I leave?
<jdong> I have no idea :D
<_ion> Uh, #java?
<Spads> ##java, even
<aktiwers> Thanks a lot :) See ya guys!
<mailer> Hi, will report this to -bugs channels ... cannot see bug files with launchpad --- evince 0.6.1 shipped with edgy wont print in landscape
<mailer> evince irc channel lets us  know the issue (possibly others) fixed in source and there was talk of a new release soon. ANything else I should do?
<Chipzz> mailer: 1) this is not the right place for bug reports 2) edgy in general won't get any new upstream versions, unless severe bugs are fixed, and I doubt your bug classifies as "severe", so the chances of getting it in are slim
<cjwatson> Chipzz: let the stable release updates team decide that, please :)
<Chipzz> cjwatson: just giving an educated guess ;)
<bhale> Chipzz: possible reasons for SRU include "major regressions from the previous release"
* Mez sighs
<Mez> I'm still waiting for approval on an SRU
<cjwatson> Chipzz: well, it doesn't sound obvious to me that we would turn it down (and I'm on the SRU team ...)
<seb128> as the evince maintainer I think I will rather do an update with the patch backported than asking for a new version approval
<Chipzz> in that case, ignore what I just said
<cjwatson> seb128: *nod*, sane
* ..[topic/#ubuntu-devel:cjwatson] : Ubuntu Development (not support, even with feisty) | #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 | Edgy is released
<cjwatson> (topicdiff: remove "edgy ... or" from the "not support" bit)
<thiagocmartinsc> Hi !
<thiagocmartinsc> I want to rebuild Ubuntu Edgy - Server with my own packages, just like OEM provides.. but without X...
<thiagocmartinsc> I know two solutions for creating a custom install CD, the project reconstructor and package oem-config... what is the best way to do this?
<Burgwork> thiagocmartinsc: what are you planning to do with it?
<thiagocmartinsc> Burgwork, my plan is to create a custom install CD, with my packages on it... but is for server side...
<thiagocmartinsc> I don't need entire X on the server...
<Burgwork> thiagocmartinsc: just for yourself? then I would checkout kickstart
<Burgwork> or fai
<thiagocmartinsc> kickstart?
<thiagocmartinsc> Burgwork, you talk about this: https://help.ubuntu.com/community/KickstartCompatibility
<Burgwork> thiagocmartinsc: yep
<thiagocmartinsc> thats nice! thanks!
<Burgwork> no worries
<thiagocmartinsc> what's will happen after I reconfigure my system and run "sudo oem-config-prepare"  ?  :-P
<Burgwork> no idea
<thiagocmartinsc> hauhAUHa...   :-D   no problem...
<thiagocmartinsc> Burgwork, I see that this KickStart is just for auto-answer some questions... but how to put my own *.deb file into the "MY-ubuntu-6.10-server-i386.iso"   ...
<thiagocmartinsc>  I see that this KickStart is just for auto-answer some questions... but how to put my own *.deb file into the "MY-ubuntu-6.10-server-i386.iso"   ...
<thiagocmartinsc> ?
<thiagocmartinsc> hellouw!
<thiagocmartinsc> anyone can help me!?
<LaserJock> thiagocmartinsc: you want to add .debs to the Ubuntu Desktop .iso?
<thiagocmartinsc> :-P
<thiagocmartinsc> nop.,..
<thiagocmartinsc> I don't need X
<thiagocmartinsc> I want to rebuild Server install CD... with my package
<thiagocmartinsc> I trying oem-config package... but ins't what I want...
<thiagocmartinsc> I see project reconstructor... but is for recreating Desktop iso...
<thiagocmartinsc> I see Kickstart but isn't for recreating Ubuntu Server iso...
<sbalneav> thiagocmartinsc: http://uck.sourceforge.net/
<LaserJock> thiagocmartinsc: perhaps look at the alternatecd customization stuff
<LaserJock> sbalneav: uck only does livecds
<LaserJock> as far as I know
<sbalneav> ah
<LaserJock> thiagocmartinsc: check out https://help.ubuntu.com/community/InstallCDCustomization
<thiagocmartinsc> and what about this: http://reconstructor.aperantis.com ?
<thiagocmartinsc> is for Desktop... right ?!
<thiagocmartinsc> anyone knows?
<thiagocmartinsc> ouw! I think this InstallCDCustomization will help
<thiagocmartinsc> :-D
<lifeless> doko: ping
<DerekS> ping mdke_ 
<niktaris> tarzeau, on the live cd how are the files /etc/passwd and /etc/shadow created? Are they copied from somewhere ?
<niktaris> on the live cd how are the files /etc/passwd and /etc/shadow created? Are they copied from somewhere ?
<niktaris> sorry tarzeau. not (only) too you 
<mdke_> DerekS: pong
<psusi> I believe they are created at boot time
<DerekS> mdke_: thanks for your blog post on SA.... it was really helpful
<mdke_> DerekS: :) one of the support people recommended it to me when I whinged about the junk filtering. Great guide huh
<mdke_> glad to spread the love
<DerekS> yeah, its great how i don't have to filter everyone's email (only my own).. and imho, SA has always been the best
<DerekS> anyways, just wanted to say thanks :)
<cjwatson> niktaris: I'm at this conference and latency is extremely high. Please mail me rather than pinging me on IRC
<niktaris> cjwatson, ok
<cjwatson> niktaris: /etc/passwd and /etc/shadow are created during installation of base-passwd during the live CD build process. user-setup is run by casper to add the ubuntu user to them
<niktaris> cjwatson, I just though that maybe the problem with the greek keyboard is releated to a bug in xserver-xorg (in etch at least)
<niktaris> I;ll try and let you know
<cjwatson> niktaris: right, I'm not around reliably enough at the moment to help with that on IRC
<cjwatson> (and I'm nowhere near my usual test rig and therefore can't just try it)
<niktaris> cjwatson, I understand. np
<jdong> cjwatson: ping
<jdong> cjwatson: out of curiousity, do you have the source for the script you use to generate backports source packages?
<cjwatson> jdong: Please tell me what you want and I'll reply when I'm around.
<cjwatson> jdong: I'm afraid I can't give it out - too much in the way of Launchpad internals in there
<jdong> cjwatson: can you answer some non-sensitive questions about it though?
<jdong> cjwatson: namely, what's being used to mangle the version and generate the .dsc file for it?
<jdong> cjwatson: I'm basically trying to write my own version of it for an automated backporting script, but my version is quite imperfect
<jdong> it uses dch, then pdebuild
<jdong> but for that to work some build deps, like cdbs, have to be installed on the host machine
<cjwatson> jdong: you're nearly there - mine prepends to the changelog manually in python (although dch should be OK too, if you use -b), and then uses 'dpkg-source -b package-version' in the parent directory and 'dpkg-genchanges -S -sa' in the build directory
<cjwatson> that avoids having to run the clean target
<cjwatson>     os.chdir("..")
<cjwatson>     spawn_get_output(["dpkg-source", "-b", "%s-%s" % (pkg, upstream_version)] )
<cjwatson>     os.chdir("%s-%s" % (pkg, upstream_version))
<cjwatson>     changes = spawn_get_output(["dpkg-genchanges", "-S", "-sa"] ,
<cjwatson>                                stderr_with_stdout=False)
<jdong> cjwatson: ooh, thanks, I'll try that
<jdong> I was considering using --use-internal-pdebuild
<jdong> which works too, though I'm not clear how much "risk" this poses to the build host
<cjwatson> I'd stick to lower-level tools
<jdong> cjwatson: ok, thanks. dpkg-source -b is the magical command I was missing
<jdong> thanks for your time
<cjwatson> it's basically an exceedingly careful wrapper around tar :)
<cjwatson> np
<Fujitsu> cjwatson: Can I convince you to let gcl into dapper-proposed?
<cjwatson> Fujitsu: will have to be a bit later, I'm afraid ... about to go and talk about ubiquity driver updates
<Fujitsu> OK, no problem.
<mirak> hi
<mirak> when I run mythtv-backend script, a --verbose is happened at the end
<mirak> where does it come from ??
<_ion> Please see the topic.
#ubuntu-devel 2006-11-09
<Hobbsee> morning mpt 
<mpt> cjwatson, ping
<mpt> er, retract contentless ping
<mpt> cjwatson, if the text of Ubiquity's navigation buttons will be "move[d]  ... into Ubiquity's own translation infrastructure", does that mean "Forward" can be renamed to "Next"?
<mpt> afternoon Hobbsee 
<neuralis> lifeless: i'm around now, can chat
<lifeless> I'm free next session
<lifeless> (in 10 minutes)
<uenyioha> hey guys 
<uenyioha> what pakages provides the linux header files
<uenyioha> ?
<popey> linux-headers
<popey> surprisingly enough
<uenyioha> i can't seem to be able to compile anything in edgy
<uenyioha> does linux-headers also provide the socket programming headers?
<uenyioha> i recall there's a package that one should install before attemping any c coding in breezy but i've forgotten the name
<uenyioha> hoary too
<Hobbsee> build-essential
<uenyioha> right on...
<uenyioha> thanks!
<tfheen> ajmitch: you're aware that the kerberize-* specs won't be scheduled until they have a priority?
<ajmitch> I thought they had been set to low priority
<ajmitch> should they be low or medium?
<tfheen> it's discussion, not implementation priority
* Mez -> bed
<jc-denton> hi all
<jc-denton> ok i know that this is not reall a question for here
<jc-denton> but in #ubuntu nobody ha an idea
<jc-denton> how can i compile this example on edgy: http://tldp.org/LDP/lkmpg/2.6/html/x121.html ?
<jc-denton> i also want to use the kernel shipped with edgy and not a custom kernel
<lucas> by clicking "Next" at the bottom of the page
<danielinu> Hi, I have a problem installing ubuntu Edgy Eft on a Dell PowerEdge because when I'm at the first reboot during the installation after the "Please stand by while rebooting the system." the computer doesn't do nothing.
<abattoir> danielinu: this is a development channel, please try #ubuntu for support
<danielinu> abattoir: ok, excuse me but now answer from #ubuntu :(
<abattoir> danielinu: be patient, someone who knows might answer :)
<danielinu> thanks
<sivang> hmm , font's breakup after my last upgrade...
* sivang examines some fonts changelog
<Fujitsu> sivang: Same.
<sivang> Fujitsu: I guess some naming / font list have changed or were merged from debian without local patches of ours.
<Fujitsu> You're getting some silly ultra-ugly serif font replacing everything?
<sivang> Fujitsu: indeed, at least suspend to ram is back ;)
<sivang> (was broken since yesterday's noon upgrade)
<Fujitsu> I upgraded earlier today, broke upon reboot.
<sivang> Fujitsu: you mean you couldn't boot?
<Fujitsu> No, the fonts broke on reboot.
<sivang> Fujitsu: ah, I just suspended to ram and when I came back the fonts were "broken"
<TheMuso> Am I right in guessing from LP that feistyis now open?
<Fujitsu> TheMuso: Has been for some days.
<TheMuso> Right.
<Fujitsu> Got a new something-or-other to upload?
<TheMuso> Not yet.
* Fujitsu gets on with some merges.
<TheMuso> I guess I'd better set up a feisty chroot.
<visik7> is possible to have a non stripped vmlinux of the ubuntu kernel ?
<visik7> the one of about 34Mb
<sivang> hmm, dbus also seems broken to some extent
<Fujitsu> How does that exhibit itself?
<Fujitsu> Aha:
<Fujitsu> dbus_bindings.DBusException: Could not get owner of name 'org.freedesktop.Hal': no such name
<Fujitsu> (starting hal-device-manager)
<Fujitsu> So, HAL seems to have ceased to exist. Fun.
<sivang> or any other hal/dbus using program
<sivang> Fujitsu: :)
<sivang> let's see if we can fix it
<sivang> and maybe later try to fix up the fonts problem :)
<bddebian> Howdy
<Mirv> should a sync request be done also for packages that are in debian, but not yet in ubuntu?
<Mirv> martin pitt's script does seem to work only for packages already existing in ubuntu, or perhaps I'm just using it in a wrong way
<Riot777> Hello I got development-like question about Ubuntu
<Riot777> is /opt directory made by default after new Ubuntu (not Kubuntu, Xubuntu etc.) install 
<_ion> It's a LFS directory, so i guess it should be there.
<Riot777> I'm not sure about that if it's made in the installation process of ubuntu can I check it somehow ?
<Riot777> any recommendations
<Riot777> what scripts should I see etc.
<Riddell> Riot777: yes it's made by default
<Riot777> ok, thank you
<pitti> sfllaw: can you please cross-check https://wiki.ubuntu.com/BugReportingTool ?
<sivang> hmm yummy bug reporting tool
<thiagocmartinsc> Hi !
<thiagocmartinsc> I finish rematering Ubuntu Server Edgy following this doc: https://help.ubuntu.com/community/InstallCDCustomization
<thiagocmartinsc> but I miss one thing...
<thiagocmartinsc> anyone knows what is ExtraOverride ?
<thiagocmartinsc> I see in: apt-ftparchive-deb.conf the line: ExtraOverride "path/to/indices/override.dapper.extra.main";
<thiagocmartinsc> but.. I don't run extraoverride.pl < /media/cdrom0/dists/dapper/main/binary-i386/Packages > path/to/indices/override.dapper.extra.main
<thiagocmartinsc> this is a problem ?!
<thiagocmartinsc> ??
<psusi> why on earth does the coreutils source package contain the original .tar.bz2 instead of the extracted source?
<_ion> What's the problem with that?
<psusi> source packages should contain source code?
<psusi> you shouldn't have to extract the package, and then extract the source from the tarball in the package
<Mithrandir> psusi: tarball in tarball is fine.
<psusi> Mithrandir: fine in what way?
<psusi> when you extract a source package, don't you expect to have source code?
<Mithrandir> psusi: fine in the way that there's nothing wrong with it?
<psusi> it seems odd to have to go through a second extraction... never seen a source package like that before
<psusi> and I'm prety sure this package didn't used to do this because I've worked on it before
<psusi> what does it gain?  why make things more complex?
<thiagocmartinsc> _ion, take a look at the of freetype... there is 3 tarballs inside it.. :-D
<Mithrandir> hello-dbs does it, apache1 does it, iirc, random other packages do.
<Mithrandir> psusi: make clean is trivially simple.
<psusi> what does make clean have to do with it?
<_ion> .orig.tar.bz2 isn't allowed IIRC. Am i wrong?
<Mithrandir> psusi: debian/rules clean should work.
<psusi> should work for what?
<Mithrandir> psusi: it should return the package to a pristine condition.  Tarball in tarball makes that easy.
<psusi> I'm not trying to clean anything, just look at the source.. .and when I extracted the source package, I got a tarball inside to again extract
<psusi> hrm....
<psusi> how so?
<psusi> how is a clean rule that cleans up first, and then tars up easier?
<Mithrandir> the clean target can just be rm -rf build instead of unpatch-handle-failure-cases-make-distclean.
<Mithrandir> uh, tars up?
<psusi> make clean isn't supposed to discard any changes you have made
<thiagocmartinsc> anyone knows if this doc: https://help.ubuntu.com/community/InstallCDCustomization works with Ubunru server Edgy  ?
<thiagocmartinsc> i trying to rematerizing the server iso with my extra *.debs files on it... but after boot my CD.. there is lot of md5 errors...
<thiagocmartinsc> computer?! hello computer?!
<thiagocmartinsc> :-P
<psusi> hrm... 
<psusi> looks lie coreutils is not built with 64bit file size support
<psusi> thiagocmartinsc: you need to update the md5sums.txt list like the wiki page says
<thiagocmartinsc> but as wiki says: To build the repository, sign it, and update the MD5SUM file, you can use a script like this:
<thiagocmartinsc> I'm use this script .. and it doesn't return any error.
<thiagocmartinsc> all goes fine..
<thiagocmartinsc> well.. I will revise all from the beginning ... but.. I think I need some help here...
<thiagocmartinsc> thanks psusi
<mc44> It seems there are a fair few specs that will not get discussed before the end of this conference; Could specs that don't get a chance for discussion at the conference still be approved, or are only specs that are approved at UDS going to be targeted for feisty?
<thiagocmartinsc> psusi, maybe the variable "BUILD=/opt/firewall-image-dapper" must be "BUILD=/opt/cd-image/"..
<Burgwork> mc44: any spec that gets approved can be worked on, but most specs require some sort of discussion
<thiagocmartinsc> because at this time /opt/firewall-image-dapper doesn't exists...
<pygi> hey dholbach ogra :)
<dholbach> heya pygi
<LaserJock> well, any spec can be worked on
<LaserJock> some are just "official" goals
<LaserJock> at least that's how I think of it
<ogra> nope
<ogra> "Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes."
<ogra> thats the header every spec should have
<LaserJock> well sure
<mc44> ogra: he was talking about implementation I think
<ogra> oh, right
<LaserJock> but if somebody wants to write a spec and do it, they don't *have* to have it approved before working on it do they?
<ogra> implementation is sorted in one of the first distro team meetings after the conference
<mc44> I just wanted to know if a spec doesnt get scheduled for discussion by tommorrow whether there was any possibility it would be
<mc44> accepted
<LaserJock> I'm guessing not
<LaserJock> but I don't think that should stop people from working on things
<ogra> nah, it shouldnt
<ogra> it will just not be "official"
<mc44> sure, I was just hoping someone more qualified would work on it @:)
<LaserJock> ah, well then that's an issue
<Burgwork> I suggest you talk about any spec before you start into it
<psusi> that's nice.... extracting the coreutils source package and attempting to immediately debuild -S it back fails
<fabbione> have you considered installing the build-deps first?
<psusi> you aren't supposed to need build-deps just to package the source
<psusi> right?
<LaserJock> right
<LaserJock> did you install dbs?
<mjg59> Erm.
<psusi> ding.. search on the missing file just came up with dbs, yea, looks like it needs that ;)
<psusi> the clean rule fails
<psusi> looking for a dbs file
<mjg59> "The Build-Depends and Build-Conflicts fields must be satisfied when any of the following targets is invoked: build, clean, binary, binary-arch, build-arch, build-indep and binary-indep."
<LaserJock> apt-get install dbs
<psusi> my.... is there a way to surpress the cleaning with debuild -S?
<mjg59> -nc
<keescook> LaserJock: is that right?  for doing debuild -S for things like l-r-m I needed things from the build-deps...
<LaserJock> keescook: it depends
<LaserJock> you need stuff for the clean rule
<Zdra> hi, I'm managing public computer at university running ubuntu dapper. We have a problem: users lock their screen or click on "switch user" which lock the screen too. I'm currently working on a patch to remove all possibilities in the gnome-session gui to let the user only logout/reboot/halt the computer (no more hibernate, etc). I think this kind of work is needed by every one managing public computers, can this kind of think be 
<Zdra> optional and integrated into ubuntu ?
<mjg59> It's acceptable for a package to require the build-deps in order for the clean target to work
<LaserJock> so the usual things are dpatch, cdbs, etc.
<keescook> LaserJock: yeah... and there isn't a distinction made.  :(
<LaserJock> keescook: yeah, but the usual suspects are the build helpers so I generally have them around anyway
<psusi> shouldn't things that the makefile itself requires be pre-depends?
<mjg59> No
<mjg59> That's not what pre-depends means
* psusi shrugs... working now that I installed dbs
<psusi> hopefully this enables 64bit file support...
<psusi> holy crap
<psusi> I crashed gcc
<psusi> can someone set #ubuntu to only allow registered users?  got some flooders
<Burgwork> psusi: -ops
<psusi> ahh
* psusi wonders how to proceed now that gcc crashed
<Zdra> hi, I want to work on a package's patch, but to apply the patch I have to apply previous patches, how can I do it ? and once I modified what I want, how to generate the new patch ?
<_ion> What patch system does the package use?
<Zdra> I don't know ... I'm not very familiar to package systems
<cjwatson> sadly this is all hopelessly non-standard
<Zdra> it's gnome-session
<cjwatson> you have to figure it out from debian/control and debian/rules
<_ion> See the package's build dependencies in debian/control. Is there anything with "patch" in it, or perhaps quilt?
<cjwatson> figure out which patch system is in use, that is - and then 'dpkg -L whatever-the-patch-system-package-is' to look for tools
<cjwatson> if it's gnome, it's probably cdbs, in which case cdbs-edit-patch will help you
<cjwatson> yes, it's cdbs
<Zdra> yeah seems to be cdbs
<Zdra> I'll try that, thanks :)
<_ion> (If it's cdbs + quilt, you might want to use quilt directly instead of cdbs-edit-patch)
<Zdra> _ion: cdbs-edit-patch worked just perfect :)
<raffael> hi. there is very annoing bug in edgy - libgnomevfs2 package, preventing from using samba shares in totem and rhytmbox. it's been already fixed and commited into gnome cvs. i just recompiled it and it works fine. i guess it's worth updating ubuntu package soon since people are still complaining on it. who is responsible for backporting patches?
<fabbione> raffael: you need to file a bug in launchpad and the right people will be notified
<raffael> i see it's already fixed in next package release, but targetted for feisty and marked as low urgency
<raffael> still not backported for edgy
<raffael> what a pity cause it really harms ubuntu image, my friends are dissapointed after upgrade to edgy
<LaserJock> it generally needs to be in feisty before it gets backported
<raffael> package was created 2 days ago so hopefully you are right
<raffael> i'll leave it as is
<raffael> thank you for information
#ubuntu-devel 2006-11-10
<pitti> slomo_: yay dbus 0.95 breaking *everything* :(
<slomo_> pitti: i'm working on it right now... i wonder why everything works fine for me here though :/
<pitti> slomo_: does this require a mega update of death and a soname bump, or is that a bug?
<slomo_> pitti: it's a bug imho
<pitti> ok *phew*
<ajmitch> it's caused lots of pain :)
* gnomefreak goes to see what dbus version i have. thinking its .95 and nothing other than fonts look broken 
<slomo_> normal warnings that could easily be ignored are fatal now and cause abort()
<gnomefreak> yep .95
<gnomefreak> is there something i can do to try and produce the dbus bug? i havent seen errors
<slomo_> gnomefreak: call lshal for example
<gnomefreak> that looks like it did it
<keescook> pitti: okay, i've updated the def-net-services wiki.  added one thing I remembered from the discussion, and cleaned up some other tiny details.
<pitti> keescook: cheers
<Keybuk> lamont: pingy wingy ding ding
<lamont> eh?
<lamont> Keybuk: in the cool-kids room
<Keybuk> lamont: __thread on hppa?
<lamont> heh
<lamont> what?
<Keybuk> it doesn't exist?
<Keybuk> does hppa not have TLS?
<lamont> what suite?
<lamont> Keybuk: not until feisty
<Keybuk> unstable
<lamont> no.  sid sucks
<Keybuk> ok
<lamont> hppa will not get it for etch
<Keybuk> so it's in feisty?
<Keybuk> what added it?
<lamont> new glibc
<kylem> moo.
<azeem> Keybuk: experimental should have it
<jbailey> azeem: Need new binutils, too.
<lamont> Keybuk: more to the point - TLS and NPTL were what killed edgy/hppa
<azeem> ah
<infinity> kylem: I sneak past to bun.
<Mithrandir> infinity: your caps lock key is broken.
<infinity> It's mapped to CTRL.
<Fujitsu> :O
<Fujitsu> Mithrandir: You've got a sane nick again!
<Mithrandir> Fujitsu: indeed
<LaserJock> Fujitsu: if only we could convince bhale ;-)
<Fujitsu> Heheh.
<Fujitsu> (Hi LaserJock)
<minghua> does tseng has a special meaning, too?
<bhale> minghua: no
<bhale> minghua: sorry
<minghua> bhale: just curious.  :-)
<bhale> i had it since 97 or something like that
<bhale> its had enough
<minghua> I was doubly-shocked the other day when I realized the term MOTU was from comic He-Man, and that I actually watched He-Man cartoon but didn't recognize it
<HrdwrBoB> hahaha
<HrdwrBoB> you didn't know?
<minghua> so I figure I'd better ask this time
<minghua> how am I supposed to know?
<minghua> the He-Man I watched was in Chinese
<Mithrandir> bhale: you need to change to nv or firegl or something. :-P
* LaserJock calls an emergency Council Grayskull meeting to discuss minghua's MOTUship
<_ion> I have MOTU hardware in my rack.
<bhale> Mithrandir: hah. I was unaware of the video card at the time
<Mithrandir> bhale: heh. :-)
<minghua> LaserJock: I bet I am not the only MOTU who doesn't know the source of the name ;-)
<LaserJock> I think we just found a good way of thinning out the MOTUs
<LaserJock> hehe
<LaserJock> forget the packaging stuff
<LaserJock> we'll administer a He-Man test
<Fujitsu> minghua: I didn't know the source of it until it came up a couple of days ago :P
<minghua> Fujitsu: I assume you never read/watched He-Man then?
<bhale> minghua: when i was 6 I had a light up He-Man sword
<LaserJock> sweet
<bhale> damn right
<Fujitsu> I hadn't heard of He-Man until a couple of days ago when I looked it up.
<bhale> Fujitsu: holy crap
<bhale> its a staple of 80's culture
<minghua> For some strange reason Chinese TV channels played She-Ra first, then He-Man
<LaserJock> that's just sad
<LaserJock> kids these days ;-)
* Fujitsu reminds bhale that he's 15.
<minghua> so I had always thought He-Man is the spin-off
<bhale> Fujitsu: oh, no kidding
<LaserJock> Fujitsu: no Magnum PI or the A-Team?
<Fujitsu> I've not heard of either.
* LaserJock head-desks
<bhale> oh man
<bhale> here it is
<bhale> he man sword li
<bhale> http://www.mastersunbound.com/He-Man%20toys%20Images/HM-LA-powersword.jpg
<LaserJock> oh yeah, I remember those
<jsgotangco> haha
<bhale> I wish i still had it
<bhale> we could use it to knight people
<bddebian> Uhm, no
<bddebian> I have a real Claymore you can use ;-)
<bhale> we are talking about He-Man, not Braveheart
<LaserJock> lol
<bddebian> Yeah but that thing is fruity looking
<bhale> dude, it was the 80's
<LaserJock> "By the power...." -> "Freeeeedoooom" ;-)
<Fujitsu> So, erm... Why was it decided to take a name from He-Man in the first place?
<bhale> Fujitsu: uh
<bhale> Fujitsu: universe? masters of?
<jsgotangco> MoTU?
<Fujitsu> bhale: Good point, I guess :P
<jsgotangco> "universe" repo?
<cjwatson> I'd need to check, but I think I may have coined the name
<bhale> jsgotangco: Thanks, echo
<cjwatson> to my shame ;-)
* Fujitsu applauds cjwatson.
<bhale> cjwatson: there werent that many other people around at the time :)
<bhale> cjwatson: you're a likely suspect
* Fujitsu hints to cjwatson to fall to peer pressure, and bring Kamion back.
<bhale> Fujitsu: the only pressure is Mithrandir whimping out
<cjwatson> nah, this is less easily confused with Keybuk in running discussions
<LaserJock> now I feel the peer pressure :/
<bhale> LaserJock: jmantha please
<jdub> Fujitsu: cjwatson was sick of people telling him he was crazy, because they were mistaking/mistabbing him with Keybuk
<Fujitsu> jdub: Hahah.
<LaserJock> heh
<Fujitsu> Mmm... dubgrant.
<bhale> jdub is another likely suspect for MOTU
<Mithrandir> bhale: dude, I'm back to running IRC off my previous host. :-)
<Mithrandir> bhale: my switch to tfheen was just temporary and never was anything but it.
<jdub> MOTU? unless i've been unceremoniously dumped, i'm still core! :)
<bhale> jdub: the naming
<cjwatson> jdub: he means for coining the term
<jdub> oh
* Fujitsu searches various mail archives.
<cjwatson> I can't find the first reference in the public IRC logs - by the time of the first instance of it, it had clearly already been coined
<thom> cjwatson: oxford i think
<jdub> Fujitsu: no, MOTU was thought of in meatspace
<Fujitsu> ... meatspace?
<jdub> as in the opposite of cyberspace
<Mithrandir> mmm, meatspace.
<cjwatson> thom: sounds plausible
<Keybuk> COUNCIL GREY SKULL!
<bhale> thom: oxford was before warty beta, right?
<jdub> it must've been oxford, because that's when we came up with universe
<Mithrandir> cjwatson: it was discussed in the big room in oxford, yes.
<bhale> because motu was after
<Fujitsu> Oh, coined at that first UDS in Oxford?
<bhale> I don't buy that story
<cjwatson> long before we called them UDSen, but yes
<cjwatson> jdub: no, it wasn't
<Fujitsu> jdub: There's nothing other than cyberspace! Real life doesn't exist.
<jdub> cjwatson: sure?
<cjwatson> jdub: universe was come up with on warthogs@ following a mail from Mark, which I found recently
<jdub> ahr
<cjwatson> the subject was "Blue Sky Bombshell", IIRC
<bhale> i didnt make a public contribution until after hte public release
<bhale> and MOTU was created soemtime after
<jdub> oh right, we finalised all the policies to go with the names at oxford
<cjwatson> bhale: it wasn't created until after preview, but it was dreamed up earlier
<bhale> some weeks
<jdub> bhale: making the MOTU team was, but the name was around for longer
<Fujitsu> Are all the early lists archived somewhere easily accessible?
<jdub> much like kubuntu
<Fujitsu> Hi Hobbsee.
<cjwatson> since we had to have a community before we could instantiate MOTU :)
<cjwatson> Fujitsu: warthogs@ isn't - we'd need to sanitise it of corporate stuff
<jdub> Fujitsu: old archives of sounder give some insights
<bhale> huh, Mark seemed to have no plan at the time
<Fujitsu> Aha.
<Fujitsu> Thanks.
<cjwatson> was warthogs@, then Ubuntu stuff moved to sounder@, then ubuntu-*@ were created after the preview
* minghua likes the no-name-yet name better
<Hobbsee> hey Fujitsu 
<bhale> no-name-yet sounder 7 was ground breaking
<Fujitsu> Something I've wondered for a while... why Warthogs!?
<HrdwrBoB> warty warthog
<jdub> warty warthog -> we were the warthogs
<bhale> HrdwrBoB: no.
<jdub> this was before "ubuntu"
<bhale> HrdwrBoB: there was no official name until shortly before preview
<cjwatson> Sounder 6 was the first one we announced on a non-private list, I believe
<jdub> we knew what the first release would be called before we knew what the product would be called ;)
<HrdwrBoB> bhale: I know
* cjwatson greps mail archives
<HrdwrBoB> I started using no-name-yet
<bhale> daniels gave me 6 or 7 or so
<cjwatson> Date: Wed, 18 Aug 2004 09:54:44 +0100
<cjwatson> From: Colin Watson <cjwatson@flatline.org.uk>
<cjwatson> To: sounder@lists.no-name-yet.com
<cjwatson> Subject: Sounder CD 6
<cjwatson> first mail I have on sounder@
<bhale> rock
<Mithrandir> Date: Sat, 17 Jul 2004 14:16:52 -0700
<Mithrandir>  from mdz on warthogs talks about universe
<Hobbsee> it's Mithrandir!!!!
<Mithrandir> (with an explanation)
<Hobbsee> heya Mithrandir!
<Fujitsu> Hobbsee: I know, it's incredible.
<Mithrandir> hiya Hobbsee 
* Mithrandir hugs Hobbsee 
* Hobbsee hugs Mithrandir back :)
<jdub> first mail on public sounder was jorge :)
<cjwatson> Sounder CDs 1 through 5 were announced privately on warthogs@; 5 was the first distributed from ftp.no-name-yet.com rather than auckland.warthogs.hbd.com
<jdub> well, pre-public sounder
* sladen remembers seeing  warthogs@rince.firstafricaninspace.com  or some such flying through muse mail logs fairly early on (after everyone disappeared off to London in April?)
<bhale> i still get mail from rince
<LaserJock> jeeze, I fell so young. I first tried Ubuntu during Hoary :/
<LaserJock> *feel
<jdub> that was the machine that mark insisted on upgrading from debian to warty online
<jsgotangco> lol
<jdub> which handled all of our lists for a long time (way too long)
<Mithrandir> I apparently got on board sometime just after sounder 3.
<bhale> jdub: you're the first post on -devel in sept 2004
<jdub> scared the shit out of me
<Mithrandir> jdub: and then a bit longer.
<Fujitsu> LaserJock: I think I tried Warty just before Hoary was released.
<jdub> "jeff, can you look at rince, there's an upgrade problem" ... *WARTY?!*
<LaserJock> I think the very first I tried was a Hoary beta
<Fujitsu> jdub: Hahah.
<bhale> I only made the second post :(
<bhale> almost famous
<cjwatson> Date: Wed, 28 Jul 2004 18:12:30 +0100
<cjwatson> that was a mail from Mark saying that we could start inviting sounders
<Fujitsu> ie. that was when it went public?
<jdub> that was after the initial sounder participants
<jdub> Fujitsu: not really, it was staged
<jdub> first we had targeted sounder invites
<jdub> then we had open invites from the whole team
<bhale> begining daniel stone worked
<bhale> begging
<HrdwrBoB> heh
<jdub> then we launched the preview
<jdub> at which point sounder became the discussion list
<Fujitsu> Interesting.
<Fujitsu> Was there a purpose for the staging?
<bhale> it was All New
<bhale> alpha stuff
<jdub> Fujitsu: fo'sho -- we got very specific people geared up about it
<bhale> not ready to release on the world, good enough to get hackers interested
<jdub> Fujitsu: there's probably a short book to be made on the design and launch of ubuntu and the community
<Fujitsu> Only a short book? :P
<Keybuk> The only distribution with BABY JESUS in its governance structure?
<jdub> Keybuk: which gets a laugh at *every* talk
<jdub> Fujitsu: there's a lot of story left :)
<Keybuk> jdub: except the Baghdad one?
<Fujitsu> What's baby Jesus got to do with anything!?
<bhale> Fujitsu: baby jesus freed us from nude south africans
<jdub> Fujitsu: gotta have checks and balances on the sabdfl
<Fujitsu> bhale: Ah, thank goodness.
<Fujitsu> Who would this be?
<bhale> Baby Jesus
<bhale> don't question him
<Fujitsu> ...
<bhale> "checks and balances" really means jdub screaming at the top of his lungs about being "the fucking laughingstock"
<jdub> there was never screaming
<thom> lies.
<Hobbsee> much screaming, anyway
<jsgotangco> haha
<Fujitsu> So it was you who saved us, jdub?
<jdub> but unlike george bush, history has proven me right. :)
<bhale> he saved us from Bad Idea #2
<jdub> i didn't do any saving on that one
<bhale> Bad Idea #1 was put to a pseudo-vote
<Keybuk> jdub saves the world again
<bhale> where the whole community got to shout at mark in -meeting
<Fujitsu> Was the aformentioned one #2?
<bhale> Ubuntu Spatial
<bhale> if you don't know what that is, its for the best
<HrdwrBoB> hehehe
<Fujitsu> No! I must know! :P
<Hobbsee> tell anyway
<Ng> ffefefef
<HrdwrBoB> it was the worst of both worlds
<HrdwrBoB> and made EVERYBODY angry
<Fujitsu> Not Nautilus spatial mode?
<jdub> Fujitsu: molested nautilus spatial.
<Fujitsu> Spatial isn't too bad... But how was it molested?
<thom> Fujitsu: google "ubuntu spatial"
<Fujitsu> thom: I have, and am looking at a couple of articles.
<bhale> thom: adult filter off?
<thom> Fujitsu: https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/14838 is a reasonable summary
<Ubugtu> Malone bug 14838 in nautilus "New spatial breaks browsing usablity" [Medium,Fix released]  
<Fujitsu> I also saw that bug, yes.
<Fujitsu> That's a nice long bug.
<Burgundavia> thom: seems this release the bad idea is tab-consistency
<Fujitsu> Burgundavia: That's a bad idea?
<Burgundavia> Fujitsu: the implementation is
<Burgundavia> check planet in about 5 minutes
<Fujitsu> Oh dear.
<Fujitsu> Burgundavia: Konsole currently has the `new tab' button on the tab bar, to the left of the tabs.
<Burgundavia> Fujitsu: ah, interesting
<Burgundavia> how does it work?
<bhale> you left click and it creates and focuses a new tab
<bhale> nothing suprising
<Fujitsu> bhale is correct. It does what you would expect.
<Fujitsu> And it works fine.
<Fujitsu> However, I agree with the other points you make.
<Burgundavia> I will update my blog post
<Burgundavia> after I pull down half of KDE just to look at konsole
<Fujitsu> Hahah.
* Fujitsu looks for some lunch.
<Fujitsu> Is feisty-changes asleep or something?
<Burgundavia> bhale: did you attend the tab consistency discussion?
<bhale> Burgundavia: no, i have little patience for such things
<Burgundavia> right
<Burgundavia> wow, I love how the top of planet is all people ripping on things
<Burgundavia> I hate how planet changes the look of some things
<jdub> oh, i didn't realise lennart was there
<Fujitsu> Burgundavia: With the moving tabs thing, do you mean like how gnome-terminal does it now?
<Burgundavia> Fujitsu: like ephy does' it
<Burgundavia> Fujitsu: gnome-terminal moves it too quickly
<Burgundavia> epiphany makes it slide along
<Fujitsu> Ah, that sounds much nicer.
<jdub> Burgundavia: "affordance" :)
<Fujitsu> I didn't think that was particularly practical.
<Burgundavia> jdub: affordance?
<Burgundavia> Fujitsu: ephy probably has the nicest tab moving I have seen
<Fujitsu> Mm, I like it.
<Fujitsu> It's very nice.
<Burgundavia> you pulled down ephy?
<Fujitsu> Yes.
<Fujitsu> Where pulled down == grabbed from mirror sitting under my hands.
<Burgundavia> right
<jdub> Burgundavia: look it up, you'll find it handy
<Mithrandir> Burgundavia: where you can't move a tab off the window it's sitting in?
<Burgundavia> Mithrandir: that is one thing that sucks
<Burgundavia> like I said, tab consistency is good. that implementation idea is crack
<Burgundavia> jdub: right
<Keybuk> Mithrandir: you're back!
<Keybuk> we missed you!
<Mithrandir> Keybuk: I am, my irc client missed you too
* Mithrandir bounces
<Fujitsu> Hm, can I convince one of the multitude of archive admins that are around here that they want to let my gcl upload to dapper-proposed through?
<jdong> infinity: ping (probably not gonna happen)
<Mez> jdong, I believe he's gone to the pub
<Mez> or similar ;)
<jdong> Mez: hence the pessimism
<jdong> Mez: if you catch him before I do, poke him about backports building against -updates
<jdong> that'd be nice
<Mez> though, to be fair to him, he didnt spend that much time in the bar at UBZ
<Mez> jdong: just ping off an email to him
<jdong> Mez: but I might discover a pile of launchpad bugs in my inbox
<jdong> Mez: evolution hides on desktop 4 ;)
<Mez> jdong,  .... ?
<whiprush> infinity is currently packed up and listening to the end-of-the-day schedule thing
<Mez> jdong, ogh, I see
<jdong> Mez: btw, you let a prevu changelog entry slip into feisty-changes :D
<Mez> jdong ... ... wtf where?
<jdong> Mez: https://lists.ubuntu.com/archives/feisty-changes/2006-November/000205.html
<jdong>  knights (0.6-7.1ubuntu2) feisty; urgency=low
<jdong>  .
<jdong>    * Automated backport by prevu. No source changes
<jdong>    * Fixed if in rules to work properly
<Mez> jdong, lol - oh, thats ok I thought you were on about the version
<jdong> prevu no longer touches the working directory in the latest revisions...
<jdong> no, not the version :D
<Mez> I know - thats why I filed the bug you see ;)
<Burgundavia> jdong: can you email me a bit about prevu to put int eh UWN?
<Mez> that's ok ... it's just a lil ... iffy
<jdong> Burgundavia: sure thing, love to
<Fujitsu> jdong: I pointed that out yesterday.
<jdong> Fujitsu: to me, yes
<jdong> Fujitsu: I'm now taunting Mez about it
<Mez> Burgundavia, I'm gonna put it in universe soon too
<Fujitsu> Mez: I was somewhat surprised when I saw that. Backporting to Feisty already? :P
<Mez> Fujitsu, no ... 
<jdong> Burgundavia: I was planning on waiting for prevu to be in feisty, and backported to dapper & edgy first
<jdong> Burgundavia: that way users don't have to go out to a 3rd party location to grab prevu
<Burgundavia> jdong: whatever. Whenever you want to talk about it
<jdong> Burgundavia: ok. thanks :)
<Fujitsu> Backporting new packages? Has that been done before?
<Mez> Fujitsu... yes it has
<jdong> Fujitsu: hehe, in warty and hoary backports, debian sid/experimental were fair game
<Fujitsu> I didn't think that sort of thing would be done :/
<jdong> Fujitsu: I was more crackful at that time
<Mez> and fujitsu - the reason for prevu'ing knights :P https://launchpad.net/products/edgy-backports/+bug/70929
<Ubugtu> Malone bug 70929 in edgy-backports "Backport knights 0.6-7.1ubuntu2" [Undecided,Confirmed]  
<Mez> and bug 70930
<Ubugtu> Malone bug 70930 in prevu "Prevu'ing a package should revert changelog after" [Medium,Fix released]  http://launchpad.net/bugs/70930
<Fujitsu> Yes, that one.
<jdong> Fujitsu: Originally, prevu executed its 'dch -i' in place when executed in an unpacked source tree
<Fujitsu> jdong: It now copies the tree elsewhere?
<jdong> Fujitsu: correct
<Mez> Fujitsu, I prevu'd it to make sure it built in fiesty and backported, and then i debuild -S -sa'd it and pushed it
<Fujitsu> Sounds like a much better idea.
<jdong> Fujitsu: initially I hadn't considered prevu used as a developer tool :)
<Mez> jdong: surely it would be easiest to just make a hook for pbuilder that did that in the pbuild?
<Mez> or would that cause issues for pbuilder ?
<jdong> Mez: I'm not sure; I hadn't considered that method
<Mez> thats an interesting idea.
<Mez> Does pbuilder error out if the version is changed inside the pbuild ;)
<jdong> Mez: hehe, I'm not sure
<jdong> Mez: I don't think so
* Mez has a look at the internals
<jdong> wow this new frozen bubbles is addictive
<Fujitsu> jdong: There's not much different, is there?
<jdong> Fujitsu: network mode :)
<Fujitsu> Ah, that'd do it.
<jdong> Fujitsu: and the overall experience is a lot more polished/professional
<Fujitsu> jdong: Yes, it's rather shiny.
<jdong> yeah
<Fujitsu> I think the actual bubble textures could do with an overhaul, though.
<jdong> it really stuns windows users with the "wow, that's free?" shock
<jdong> Fujitsu: I agree, I'm disappointed nothing happened with the bubbles
<Fujitsu> They look really out of place :(
<jdong> they sure do
* jdong playing f-b transparently while watching some backports builds behind it
<Fujitsu> Aw... `Eye-candy animation is too slow, disabling.'
* Mez has never played frozen bubble 1
<jdong> Fujitsu: yeah, my Xgl environment triggers that same error
<Mez> jdong: nvidia card ?
<jdong> Mez: no, ati/fglrx card
<jdong> mobility radeon 1400
* Mez just gets a f**king white screen
<Mez> (with aiglx)
<jdong> Mez: enabled strict binding?
<Mez> and Xgl just crashes out on me
<jdong> Mez: if you're using beryl that is
* Fujitsu tries it on the desktop, which has an ATI card.
<jdong> without strict binding, I get blank terminals
<Mez> jdong, I was using beryl, and with Xgl, it would work for a few secs, then Xgl would crash and I'd have nothing but a wallpaper staring at me
<jdong> hmm
<Mez> aiglx would only not give me a white screen if i used ati instead of fglrx
<Mez> but if I did that then it would crash out X after a few secs
<jdong> Mez: in general I've found aiglx to be slower than xgl
<jdong> :(
<Mez> aiglx was slower
<Mez> but both crash out
<jdong> heh
<Mez> which is :'(
<jdong> yeah, it definitely is
<Mez> Xgl worked fine for a few mins until it crashed ;)
<jdong> eye candy is a necessity :D
<Mez> jdong: what instructions did you use to set it up ?
<jdong> Mez: the ones at the beryl wiki?
<Mez> link ?
<jdong> http://wiki.beryl-project.org/index.php/Install/Ubuntu
<Mez> jdong, using ubuntu or kubuntu ?
<jdong> Mez: both
<jdong> Mez: I tend to switch back and forth out of boredom
<Mez> lol
<jdong> to be perfectly honest though I prefer GNOME more often
<jdong> though I do have some kde stuff running in my gnome always
<jdong> like klippy
* Fujitsu notes that Frozen Bubble must be like the only free game in history which has music that isn't totally vile.
<jdong> klipper*
<jdong> ktorrent
<jdong> Fujitsu: oh yeah
<Mez> Fujitsu, you ever played UT2004?
<Mez> or Doom 3 ?
<jdong> Mez: I am a light UT2004 player
<Fujitsu> Are they free?
<jdong> Fujitsu: I got mine for 5 bucks, so close enough :D
<Mez> jdong: want a game ?
<jdong> Mez: naw, not right now
<Mez> aw :(
<jdong> I don't have it set up on my serious work laptop either
<jdong> :D
<jdong> I actually keep my ut in a squashfs
<minghua> Fujitsu: if free beer qualify as "free", I believe there are games with good music
<jdong> it compresses it down quite significantly
* theCore points -> http://taspring.clan-sy.com/ 
<Fujitsu> I was more thinking free as in libre.
* jdong upgrades to beryl svn out of boredom
<jdong> please stand by while I break my computer
* Fujitsu merges 915resolution out of boredom.
<jdong> Fujitsu: speaking of azureus
<jdong> Fujitsu: what did happen to repacking orig.tar.gz
<jdong> Fujitsu: oh yeah, I stumbled across spe the other day, they used "+repack" to designate this scenario
<Fujitsu> Ah, that.
<jdong> 0.8.2a+repack-0.1: all
<Fujitsu> Well, it's ready to go, I think.
<Fujitsu> jdong: It's not really a repack.
<Fujitsu> It's got changes.
<Fujitsu> Or has spe got similar changes?
<jdong> Fujitsu: I'm not sure what happened to them
<jdong> Fujitsu: and I'd call it a repack in the sense that the first time it was packed wrong
* jdong still oddly curious how it happened
<Fujitsu> Same...
<Fujitsu> The upstream tarball should be the upstream tarball...
<Fujitsu> Yet in this case it appears to not be :S
<jdong> Fujitsu: it's actually laid out nothing like the upstream sources
<jdong> Fujitsu: actually, the upstream sources are in a zip file :D
<jdong> wow, beryl svn is snappier
<jdong> infinity: I've got free cookies if you talk to me!
<jdub> Burgundavia: re your blog -> ie7 has a "new tab" tab that is always on the very right of all tabs
<jdub> Burgundavia: it is mildly confusing
<robitaille> if you don't use ie7  then the confusion will magically go away :)
<racter> hi -- i have a process question w/r/t developing ubuntu; how do those working on the project share and manage code?  do you use something like SVN?
<minghua> racter: most developers use bzr
<racter> ok thx -- so the core codebase of ubuntu is managed through bzr?
<racter> i'm just trying to figure out how a larger open source project like this is managed
<minghua> racter: I don't know the details, I suppose every developer has his own style to manage his/her packages
<minghua> racter: and the tool upstream uses is a factor too -- I am sure the kernel maintainer uses git
<minghua> racter: I don't think there is an enforced policy
<racter> ok
<racter> so what about actually putting everything together?
<racter> is that just centrally managed on this project?
<minghua> yes, Launchpad: https://launchpad.net/
<racter> like the livecd etc
<racter> oic
<minghua> and then there is the archive
<racter> ok thanks for the leads, minghua!
<minghua> you are welcome
<Burgundavia> jdub: ah, other interesting news
<Burgundavia> jdub: is that the little tab that is unlabelled at the end?
<jdub> yeah
<jdub> and the tab with four squares on it gives you a thumbnail preview of all the tabs
<Treenaks> it's labeled '*SHINY STAR THINGY*'
<jdub> like those firefox plugins
<Burgundavia> hmm
<Treenaks> Burgundavia: and I agree with you on the 'it should be upstream' bit... breaking upstream has made baby jesuses cry since hoary..
<Treenaks> (babies jesus?)
<Burgundavia> I have noticed Ubuntu catch some flak for not upstreaming our patches recently (outside of the usual Debian concerns)
<jdub> if there are api/abi changes, there's going to be some serious shit going down
<Burgundavia> even if there are not, I would deeply concerned
<Burgundavia> it really shows there has been a lack of debate about this whole spec
<jdub> well, yeah, shit going down due to wrong implementation choice as well
<jdub> but hey
<Treenaks> *cough*logout dialog*cough*
<Burgundavia> Marks One Dumb Idea Per Release
<Burgundavia> TM
* Lathiat smirks
<Fujitsu> Burgundavia: What about beryl-by-default?
<Burgundavia> Fujitsu: it is now composite by default
<Burgundavia> and if you look at the spec, I don't see how Beryl is going to meet the requirements
<Fujitsu> Ah good.
<Burgundavia> it was clear from day one that this tab spec has gotten Marks attention like a shiny toy
<Burgundavia> if you notice, it was the first spec marked High
<jdub> it is his spec
<Burgundavia> that it was
<Burgundavia> I just hope people see my blog post as not a rant but as a genuine wish to start some real dialog about the spec
<jdub> HOLY SHIT! WOOKIE COOKIES!!!!11
<Burgundavia> heh
<jdub> http://youtube.com/watch?v=z7ieS1zB_E8
<Burgundavia> jdub: you are sabotaging my efforts to get to sleep
<jdub> haw haw haw
<jdub> "Every company has its blowhards and its various good guys," Shuttleworth said. "We have ours."
<Burgundavia> jdub: where is that from?
<jdub> http://www.theregister.co.uk/2006/11/10/shuttleworth_oracle/
<robitaille> it's on the fridge :)  
<jdub> robitaille: i note that bit wasn't quoted
<jdub> !
<robitaille> yeah...I should probably had a quote in there.
<robitaille> s/had/add
<Burgundavia> you know mark talks a lot about Canonical being different from RH. All I see right now is some non-free software
<jdub> i'm giving hima qotd
<jdub> lollerskates
<jdub> http://perkypants.org/blog/2006/11/10/qotd-mark-shuttleworth/
<robitaille> I didn't get the bit in the article about Sun and a glass fish...I must be too dense tonight
<jdub> robitaille: sun released glassfish under the cddl
<jdub> java ee server
<Burgundavia> jdub: here is a nother good qotd: "I'll give you an example: My son, seven years old, runs Windows Vista, and, honestly, he doesn't have an antivirus system on his machine. - Jim Allchin
<robitaille> ah.. thanks jdub
<Treenaks> Burgundavia: botnet!
<Burgundavia> Treenaks: apparently Vista has some ASLR thingy
<Treenaks> alt.sysadmin.l[??] .recovery?
<Burgundavia> address space randomization
<Treenaks> ah
<Treenaks> another hack around the real problem
<Burgundavia> some handwaving about "every version of Vista being slightly different". it might help, but I seriously doubt it
<Fujitsu> All 8 versions.
<Burgundavia> I thought it was 7
<Treenaks> Fujitsu: YOU WIN! :)
<Fujitsu> I think it's 8, there's Home, Home Premium, Business, Enterprise, Ultimate, plus a couple of odd N variants.
<Fujitsu> Maybe 7, though.
<Fujitsu> Ah, and Starter.
<jdub> there's also the Bendover pack
<Fujitsu> ...
<robitaille> it is 5 according to their web site  http://www.microsoft.com/windowsvista/getready/editions/default.mspx
<robitaille> not that I really care...
<Burgundavia> I think Bendover(TM) is a free addition to all versions of Vista
<robitaille> interestingly  it seems Microsoft doesn't own vista.com
<Burgundavia> oops
<Burgundavia> imagine they would pay a fortune for that now
<robitaille> I imagine someone is still waiting to get as much money as possible closer to the official release
<Fujitsu> robitaille: That page leaves out Starter and the two extra European options.
<Burgundavia> oh, the N editions
<minghua> they don't own ie7.com either
<Burgundavia> ouch
<robitaille> Fujitsu:  the text mentions 5 editions...the 4 in the table, plus starter available in some countries.  
<minghua> you just can't predict everything :-)
<Burgundavia> 2nd hit for ie too
<Fujitsu> robitaille: Also Enterprise Edition, just above the table.
<Burgundavia> http://dean.edwards.name/IE7/ <-- and this is the 3rd hit
<Fujitsu> Hahah.
<Fujitsu> Nice
<robitaille> well... it seems not all ubuntu sites points to the distro.   ubuntu.tv for example
<Fujitsu> And ubuntu.ch.
<Fujitsu> Hm, the owner of that seems to have emptied it.
<robitaille> ubuntu.fm doesn't resolves.
<StevenK> And ubuntu.org is something else entirely.
<Fujitsu> StevenK: That annoyed me a lot at the start.
* StevenK just dealt with it.
<johanbr> I read about a tubing manufacturing company which owns the domain utube.com. Apparently they've had to shut down their web server several times because of all the traffic. :)
<Fujitsu> I kept typing it for ages.
<Fujitsu> johanbr: I've also heard they're attacking YouTube about it.
<johanbr> I can feel their pain. My old home number was one number away from a lumberyard's number. 
<Burgundavia> I had a friend who had a one number off the most popular pizza place in town
<Burgundavia> we had fun with that one
<Fujitsu> Burgundavia: Ouch.
<Burgundavia> anchovie pizza? sure!
<robitaille> In Montreal, our phone number was 2 small number off from the US consulate...
<StevenK> Our support number is a slight transpose for Fisher & Paykell, which makes for some interesting phone calls.
<Burgundavia> what is fisher and paykell?
<StevenK> A large Australian whitegoods manufactuer.
<Burgundavia> whitegoods?
<StevenK> Fridge, oven, washing machine, dryer, dishwasher, etc
<Burgundavia> ah
<Burgundavia> you aussies speak funny
<johanbr> A year ago, someone from the cargo terminal at Vancouver Airport called and left a message for my boss "Your monkeys have arrived. Can you please come and pick them up, they're becoming quite agitated." He had no idea what the guy was talking about. :)
<Fujitsu> You Burgundavians speak funny.
<Burgundavia> johanbr: should have gone and picked them up for a laugh
<StevenK> Said in a non-Aussie accent, that line is very funny. :-)
<Burgundavia> johanbr: why don't I see you in #ubuntu-ca ?
<Mithrandir> Hobbsee!
<Fujitsu> Evening, Hobbsee.
<StevenK> Gasp, it's actually Mithrandir.
<Fujitsu> (hey Mithrandir)
<johanbr> Burgundavia: No reason, really. I've looked at the mailing list, but I didn't know of the irc channel.
<Fujitsu> StevenK: I know, it's most incredible.
<Mithrandir> StevenK: indeed.
<StevenK> Mithrandir: Your machine took a while to get fixed.
<Burgundavia> johanbr: as leader of Ubuntu Canada, you are now marked and I will hound you until you admit defeat and join #ubuntu-ca :)
<Mithrandir> StevenK: yeah, and I got distracted by random other things I needed to fix
<johanbr> Burgundavia: Sounds like I just have to give in then. :)
<Hobbsee> Mithrandir!
<Hobbsee> hey Fujitsu 
<StevenK> "I am Burgundavia of Borg. You will be assilimated. Resistance is futile." ?
* StevenK is reminded of the Thinkgeek shirt.
<StevenK> Resistance is futile, if < 1 ohm
<ajmitch> evening
<Hobbsee> hey ajmitch 
<Burgundavia> StevenK: I build my loco team through threats and intimidation
<StevenK> Burgundavia: Muaha
<Burgundavia> this leadership stuff is fun :)
<Mithrandir> what's normal dry skin resistance?
<Fujitsu> Mithrandir: A lot.
<Mithrandir> about 1 M, it appears.
<jdub> im in ur developer summit, writin ur specs
<johanbr> Is there a Spanish-speaking loco team?
<Fujitsu> Whadeva you say, jdub.
<Fujitsu> johanbr: Spanish team, most probably.
<desrt> jdub; yr weird
<johanbr> Fujitsu: I see my feeble attempt at a joke failed.
<Mithrandir> jdub: you're totally not. :-P
<jdub> johanbr: #ubuntu-es
<Mithrandir> jdub: but you _should_ have been here, writing uwr specs.
<johanbr> Failed twice, even.
<jdub> johanbr: ah, don't be so hard on yourself. you only failed once. the world failed you many times.
<jdub> ;-)
<Fujitsu> jdub: You need to be around more often! It's a whole lot better with you here.
<jdub> lies!
<minghua> Mithrandir: I think the resistance depends on people quite a bit, there can be ~10 times difference from person to person
<minghua> but yes, 1M ohm is about right
<Fujitsu> minghua, Mithrandir: We are discussing this /why/, exactly?
<minghua> Fujitsu: I am just interested, being a physicist, you know
<Mithrandir> Fujitsu: we're trying to find out if resistence is actually futile or not.
<Fujitsu> Heheh.
* Hobbsee has forgotten the resistance experiments that she did
<Hobbsee> we did actually do the resistance of various bits of ourselves, though
<minghua> does futile has some special meaning in electrical circuits context?
<Hobbsee> not that i know fo
<Mithrandir> I'm not an EE, but not that I know of, no.
<Mithrandir> (I have had some EE classes, though)
<johanbr> For some fun with an oscilloscope, get nekkid, put the wires over your heart and turn up the resolution far enough. Poor man's ekg. 
<johanbr> ecg, rather.
<Mithrandir> I don't know about you, but I can get at my chest by just taking off my shirt.  :-P
<Hobbsee> hah
<StevenK> Mithrandir: Yes, but you can burn yourself very badly if you're wearing anything with metal, like say, the button of a pair of jeans.
<Mithrandir> StevenK: sure?  Why would you do that?
<StevenK> Hum. I think I've just confused two different pieces of medical technology. :-(
* StevenK goes and hides under his rock.
* Hobbsee stole the rock
<Hobbsee> StevenK: you cant hide under air.
* StevenK demateralises.
<StevenK> Are you sure?
<Hobbsee> yes
<jdub> StevenK: "oral" and "suppository"?
<pygi> sivang, ping?
<cge> Does anyone know why ttf-arphic-uming is declaring itself as the preferred font for every alias in fontconfig?
<Fujitsu> cge: Feisty?
<cge> Fujitsu: Yes.
<Fujitsu> cge: I noticed everything had changed to some overly bad font.
<cge> I'm asking about the rationale of doing so.
<Fujitsu> Can't have been deliberate.
<cge> Well, the code was certainly deliberate, I think the author just didn't realise that the configuration file for the individual font overides the global configuration file.
<Fujitsu> Oh, it's a bug in that font specifically?
<Fujitsu> Ouch.
* Fujitsu removes.
<cge> I wrote a patch for it, which is in bug #71121
<Ubugtu> Malone bug 71121 in ttf-arphic-uming "0.1.20060928-2 makes default gnome fonts ugly" [Undecided,Confirmed]  http://launchpad.net/bugs/71121
<Fujitsu> Oh, it's not just GNOME, it's everything.
<cge> Yes
<cge> I don't particularly want to spam everyone by changing the title.
<Fujitsu> Probably a good idea.
<cge> It's an easy fix. I just don't understand why the code was there in the first place, so I ended up putting in two patches, one which changes the <prefer> tags to <accept> so that uming is still in the list of fonts used for the aliases, and another which just removes the <alias> sections altogether.
<Fujitsu> I don't think the aliases are particularly valid, but they must be there for a reason.
<cge> Well, one is actually an alias section for a deprecated alias...
<_ion> Way to go. Some guy has made a list <http://3v1n0.tuxfamily.org/blog/lista-repository-sourceslist-ottimizzata-per-ubuntu-kubuntu-linux/> of random apt repositories all over the Net, and recommends people to dump them all to their sources.list without thinking. Suddenly some 700 (almost all of them Italian) computers are using my repository  the maintainer of any of those repositories could do some serious damage to ~700 systems.
<Hobbsee> way cool
<Fujitsu> Yep, fantastic.
<Fujitsu> BURN!
<cge> wow
<Fujitsu> Can we, you know... DESTROY whoever made that list?
<cge> I'm not sure what is worse. That someone made that list, or that 700 people actually listened to him.
<Fujitsu> Or we could Digg it!
<cge> Oooh, he also suggests in the instructions that someone should add all of those those using kadept, *one by one*.
* Fujitsu hyperventilates:
<Fujitsu> # Trevios Ubuntu edgy Beryl-SVN Repository (GPG key: 81836EBF - DD800CD9)
<Fujitsu> # Daily Updated Beryl (and related projects) Packages
<Fujitsu> Great, kernels too.
<cge> Can some Ubuntu member please email him with an @ubuntu.com address and tell him to take it down?
<hunger> cge: Better explain to him why it is a bad idea, or he'll end up blogging about being bullied by cannonical.
<cge> I'm still trying to find an email address...
<Mithrandir> @ubuntu.com != canonical.
<hunger> Mithrandir: I know that, but will the average /. reader?
<Fujitsu> Ooh, ooh!
<Fujitsu> http://forums.whirlpool.net.au/forum-replies-archive.cfm/612629.html
<Fujitsu> It's everywhere.
<cge> I hope the person there copied it for entertainment purposes.
<sivang> Fujitsu: any news about the fonts bug? :)
<cge> sivang: I posted a patch for it.
<sivang> slomo_: I saw you uploaded a new dbus that fixes the close shared connection, is this in response to my bug report?
<Hobbsee> _ion: one of them is your repo right?
<Fujitsu> sivang: It's bug #71121
<Ubugtu> Malone bug 71121 in ttf-arphic-uming "0.1.20060928-2 makes default gnome fonts ugly" [Undecided,Confirmed]  http://launchpad.net/bugs/71121
<cge> sivang: ttf-arphic-uming declares itself as the preferred font for every alias that fontconfig has, and overrides the global config.
<Hobbsee> _ion: why not just upload something that breaks their X or something?  :P
<Fujitsu> sivang: Remove ttf-arphic-uming, and everything is good.
<Hobbsee> or just breaks something so badly that it says "this should nto be used"
<sivang> cge: an idea how that happened? how did it differ from the edgy version
<Fujitsu> Hobbsee: Or a patched wallpaper.
<Hobbsee> Fujitsu: yeah...
<slomo_> sivang: it doesn't really fix anything, it just allows applications to call the dbus api with bogus parameters and thus solves your problem for now ;)
<Fujitsu> imbrandon's repo is in their too.
<cge> sivang: The new upstream version changed the configuration.
<Fujitsu> *there
<slomo_> sivang: applications should still be fixed and i'll upload a fixed hal later probably
<_ion> hobbsee: Yep, but i removed the "all" section, which is the only section listed in there. Oh, i wouldn't be that malicious. :-)
<sivang> slomo_: ah, I thought you said it was pitti's domain :)
<cge> sivang: But even then, it seems like it might be broken partially in edgy, and the only reason it worked was because it was using the deprecated sans alias instead of sans-serif.
<Hobbsee> _ion: hehe.  why not?  they'd learn quickly
<Fujitsu> sivang: Is there a bug on LP for that HAL thing?
<sivang> Fujitsu: ofcourse
<cge> sivang: Which, of course, the author fixed for the new upstream.
<sivang> Fujitsu: slomo_ migt have it )
<sivang> hmm
<sivang> W: /usr/share/fonts/truetype/arphic/uming.ttf: not registered.
<sivang> nice
<sivang> :)
* sivang just purged the package
<Fujitsu> sivang: Same.
<slomo_> Fujitsu: afaik there is no bug yet
<Fujitsu> Purging crud is good.
<sivang> slomo_: just a sec
<sivang> slomo_: I sub'd only pitti, as you said it his respo to fix hal
<_ion> hobbsee: OTOH, changing the background wouldn't be very evil.
<Hobbsee> _ion: no, but causing dep hell would be
<_ion> Could someone translate "Using repositories you don't trust may cause irrepairable damage to your system" to Italian, please?
<sivang> Fujitsu, slomo_ : https://launchpad.net/distros/ubuntu/+source/hal/+bug/71092
<Ubugtu> Malone bug 71092 in hal "hald-runner crashes making hal unusuable." [Undecided,Unconfirmed]  
<cge> _ion: take a look at the root of Trevino's site.
<Fujitsu> sivang: Thanks.
<cge> _ion: The site is  Dennis Kaarsemaker <dennis@kaarsemaker.net> :)
<sivang> Fujitsu: you're welcome.
<slomo_> sivang: thanks
<_ion> cge: Only Falcon is  him.
<cge> _ion: ah
<Fujitsu> He's apparently a PLF contributor.
<Fujitsu> Evil evil evil.
<cge> Ok, found his email
<Fujitsu> I ended up finding it through LP, then found it on his website.
<Fujitsu> Anybody here speak Italian? A Babelfish translation of that site doesn't make much sense.
<cge> Not really, why?
<Fujitsu> Well, a Babelfish translation of the first paragraph is interesting...
<Fujitsu> It basically seems to say `yay, Edgy's out, but not without it's fair share of problems.'
<Fujitsu> I presume he means upgrade problems...
<Fujitsu> So, he goes out and makes something which will cause more! Yippee.
<Fujitsu> Of course, that translation could be completely wrong.
<cge> He used apt-get -f dist-upgrade to upgrade, apparently.
<Fujitsu> Looks like it.
<cge> He must be used to apt problems...
<Fujitsu> Is that a surprise?
<cge> IRC unfortunately lacks the wide range of intonations one can use in speaking.
<Fujitsu> It is very unfortunate, yes.
<cge> From reading it, and my skills in Latin, it appears that he is saying that the upgrade wasn't without problems, but one apt-get -f install fixed nearly all of them.
<cge> Of course, it also says that this is his sources.list updated for edgy. If he had that list for Dapper as well, I'm surprised he was able to upgrade at all.
<Fujitsu> Yeah, I'm most impressed that his system didn't explode entirely.
<cge> Oh dear, he also has a package in his repository which automatically replaces the user's sources.list with his.
<cge> at least it makes a backup
<Fujitsu> I also got that information from the translation.
<cge> Oh. I could have just read that instead of dpkg-deb -e'ing it.
<Fujitsu> Of course, we could easily put a version of that package with a very high version number in another of those repositories, replacing the sources.list with a sane one :P
<cge> Finally, a good use for epochs.
<Fujitsu> LOL
<cge> Does anyone know if epochs are unsigned ints or unsigned chars?
<StevenK> Ints
<Fujitsu> Hahahah.
<StevenK> Well, 1 through to 9
<Fujitsu> Only through 9? Bugger.
* StevenK beats Fujitsu with Policy
<crimsun> well, kde's already up there
<cge> Now I'm going to actually have to remember how to build packages without helpers.
<Fujitsu> Hm, that list has only been there for 4 days.
<cge> Fujitsu: And 700 people are using already...
<Fujitsu> Yeah, and it's being distributed further.
<StevenK> cge: tar ; tar ; touch ; ar e ......
* StevenK ducks
<Fujitsu> `I'm Trevio a happy Italian Kubuntu User...' (from the wiki page)
<StevenK> ar a, even
<Fujitsu> Happy, soon to be shredded into lots of tiny little pieces, Italian Kubuntu User.
<Fujitsu> Hahah, check the first comment on http://www.daniweb.com/blogs/entry769.html
<_ion> http://johan.kiviniemi.name/tmp/untrusted_repositories
<Fujitsu> _ion: Nice.
<cge> That comment is great.
<Fujitsu> It is, yes.
<cge> Anyone have a copy of the default sources.list?
<Fujitsu> Not on any of my machines.
<tepsipakki> make sources.list read-only, and force users to put extra repos in sources.list.d/foo.list
<tepsipakki> it's silly to add everything in the default version
<cge> I'm thinking about just blanking sources.list, and telling the user to reinstall.
<radone>  I am trying to compile project and I got:  "/lib/modules/2.6.15-27-386/build: No such file or directory"
<radone> linux sources are already installed, but how can I create build directory?
<cge> radone: You should generally ask questions like that in #ubuntu.
<radone> cge: ok, thanks
<cge> radone: But it sounds like you need to install kernel sources and link them to that directory.
<_ion> Ok, http://johan.kiviniemi.name/ubuntu/dists/edgy/all/
<_ion> The first download already happened.
<cge> _ion: !?
<cge> _ion: Here, you can take (http://evanslabs.org/3v1n0-sources-list_8.7_i386.deb) package and modify it to your tastes. I think it should work reasonably well. It will move the users sources.list to sources.list.moved, remove trevino's list in /usr/share, print an explanation in English and "You need to reinstall Ubuntu!" in English and Italian, and then will have postinst fail so that it will force the user to do something.
<cge> Oh dear, here's another version: http://www.debianadmin.com/ubuntu-edgy-eft-complete-sourceslist-repository-list-file.html. It even claims that it is "highly secure".
<jonh_wendell> guys, i've downloaded a package with apt-get source. How can i rebuild it, i haven't changed anything, i just want to rebuild it
<gnomefreak> jonh_wendell: that is best asked in #ubuntu-motu there is also a packaging guide i think its !packaging
<Trevinho> Hi... O got this message from "cevas" on msn [10:11:56]  cevans-ms@costinet.org says Hello? If you are available, would you mind coming to #ubuntu-devel on freenode?
<Trevinho> Anyone knows something about? :o
<Hobbsee> Trevinho: no idea
<Trevinho> ah, ok... thanks anyway....
<gnomefreak> im not sure who that is either sorry
<Trevinho> Ah, here it should be known as "cge"... He's cevans (sorry for typo of first msg): https://launchpad.net/people/cevans
<Hobbsee> who was here, but left a while ago
<Trevinho> mh... Yes... I've mailed him...
<sladen> ooh, we're up to 70xxx range bug numbers
<giftnudel> yeah, see all the people running away in fear
<bddebian> Howdy
<lifeless> 'think of the kittens'
<_ion> That Trevinho guy that visited was the maintainer of this. http://3v1n0.tuxfamily.org/blog/lista-repository-sourceslist-ottimizzata-per-ubuntu-kubuntu-linux/
<_ion> 66 computers have installed the "new version" of edgy-wallpapers with the warning about using untrusted repositories so far.
<LaserJock> _ion: my gosh that is one huge sources.list
<_ion> laserjock: Yes, and he's recommending people to dump it straight to their sources.list. And seems like about 700 computers, mostly Italian, are using it.
<LaserJock> how nice :(
<_ion> I removed everything from my "all" section (which is the only one in that list) and added a "new" edgy-wallpapers package there that replaces the images with http://johan.kiviniemi.name/tmp/untrusted_repositories
<Ng> # CANONICAL COMMERCIAL REPOSITORY (Hosted on Canonical servers, not Ubuntu servers.
<Ng> hehe
<Ng> erm ;)
<mjg59> Keybuk: So I think there's a way of potentially reducing the number of screenmode changes, but we're not trivially going to be able to lose the textmode switch before X
<Keybuk> mjg59: why not?
<Treenaks> some X drivers break when the screen isn't in textmode before they init..
<mjg59> Keybuk: Otherwise X doesn't know to reprogram text mode when you hit ctrl+alt+f1
<mjg59> It'll assume that you want the vesa mode on the consoles
<Keybuk> mjg59: interesting
<Keybuk> mjg59: so usplash-until-desktop is probably not doable
<Mithrandir> can't we tell it what the mode should look like?
<mjg59> Keybuk: Unless we have some mechanism to tell X what to do on switches to console, correct
<mjg59> Mithrandir: How do you describe VGA text mode?
<mjg59> Other than "This large number of registers need to look like this"...
<Mithrandir> mjg59: vbetool knows how to, doesn't it?
<mjg59> By relying on the video BIOS, yes
<sladen> mjg59: "the mode the card defaults to".  An that is the problem.
<Mithrandir> since it stores that set of registers already, doesn't it?
<mjg59> sladen: Uh, no. You can do better than that.
<Mithrandir> it being X
<mjg59> Mithrandir: Nope
<mjg59> Mithrandir: Oh, erm.
<Mithrandir> (sorry)
<mjg59> Mithrandir: Not really. I doubt that most X drivers actually know how to program text mode
<Mithrandir> what do they do, then?
<mjg59> Mithrandir: In most cases, I suspect it's "This is the way the registers were when we started"
<Treenaks> that sounds eek
<sladen> Keybuk: so, usplash-until-desktop is doable with /some/ X drivers at the moment, and is -potentially- doable with all at a later date which magic foo be done to the X drivers
<Mithrandir> we can record that before usplash starts, can't we?
<mjg59> Mithrandir: Ish
<sladen> effectively what vbe vgastate is doing already
<Mithrandir> mjg59: not saying it's pretty, though
<mjg59> Mithrandir: We can store that state, but then we'd need some means to pass that information to X
<Treenaks> shared memory? *goes into hiding*
<sladen> what happens is the contains of /var/lib/acpi-support/vbestate are used after an X mode switch back to text?
<mjg59> sladen: Given that it's currently saved while usplash is running, nothing good
<sladen> mjg59: write an extension, connect, beam it to the X server
<sladen> mjg59: okay, so that needs moving into the initramfs stage before usplash ?
<mjg59> That's still dependent upon us using VBE to restore the console mode
<mjg59> Which isn't what all of the drivers did
<mjg59> s/did/do/
<Mithrandir> is there a particular reason why they don't?  (As in, can we make them?)
<mjg59> Because VBE modesetting is generally regarded as only slightly better than punching yourself in the face repeatedly
<Mithrandir> have you ever tried to punch your own face?  It sounds hard to actually do effectively.
<malcc> I guess it'd be all about angular momentum
<LaserJock> mako: ping
<LaserJock> mako: nvm, I'll have to catch you later
<mako> Laser_away: i'm here now
<Treenaks> You owe the oracle an ntp-server
<Keybuk> mjg59: does vbesave actually work with usplash running?
<Laser_away> mako: do you get mail from your @ubuntu.com address?
<mako> Laser_away: yes
<Laser_away> mako: I seem to be getting some spam addressed to you
<mako> Laser_away: probably it's just forged headers
<mako> Laser_away: or rather, they just put me in the from address
<Laser_away> I just had my redirect changed and since my LP id is mantha I wondered if something got tweaked
<mjg59> Keybuk: Yes
<Laser_away> mako: the To: header says mako@
<mako> Laser_away: oh, perhaps i recieved that spam too
<mako> Laser_away: what was teh message-id or subject?
<Laser_away> the subject is always "hi mako"
<Laser_away> mako: anyway, gotta run, but I just didn't want you to miss any non-spam mail
<Laser_away> mako: I'm guessing you don't want your spam back ;-)
<mako> Laser_away: no thank you
<mako> Laser_away: take a look at the headers
<mako> Laser_away: i suspect it was delivered for mantha in a BCC
<mako> Laser_away: aalthough it's very likely that it always went to me
<mdz> mjg59: which vesa mode does usplash use without a config file?
<mjg59> mdz: I believe 640x480, though it may depend on the theme
<jonh_wendell> how can i get a feisty package with apt-get source if i run edgy?
<gnomefreak> jonh_wendell: you try not to mix packages as things break. this is not a support channel. join #ubuntu for support related questions
<jonh_wendell> gnomefreak: uau
<jonh_wendell> thank you
<jwhitlark> oops, sorry.
* mnepton wriggles erotically
<jwhitlark> /MSG mnepton To add a new package to universe, do I need to do
<jwhitlark>     anything special for it to bw available to dapper, edgy, etc.?
* mnepton stares blankly
<mnepton> a package is usually release specific, as libs change between releases. it may be that the package works prefectly in both, so you'd just use the single package, but with different revision claims.
<Laser_away> jwhitlark: complete new packages won't be in dapper, edgy, etc.
<mnepton> Laser_away: wel, backports
<Laser_away> nope
<Laser_away> I believe backports are only allowed for existing packages
<Burgwork> jwhitlark: new versions of an existing package can be updated
<jwhitlark> I've working on an emacs package that's so dead simple it will work on all, 
<Burgwork> completely new packages, no
<mnepton> if it's important enough, it will get in
<mnepton> but it has to be *drop dead* important
<mnepton> otherwise, Feisty
<Laser_away> mnepton: not if it's a new package
<jwhitlark> perhaps it wouldn't go in universe then.
<Burgwork> it can go in Feisty universe
<jwhitlark> I want it available for my dapper servers, and while I can do that with a local repository, I was thinking to get it official somewhere...
<Laser_away> once a release is released, that's it for new packages
<jwhitlark> ah, so it doesn't matter what repository you aim for.  I see.
<jwhitlark> So I'm stuck with a local repository, then.
<Laser_away> jwhitlark: yep
<jwhitlark> got it.
<Mithrandir> ajmitch: who put me as the drafter for networkauth?
<andrunko> hi all, i am trying to create a package that uses python-distutils, but i have 2 issues, first dh_iconcache is not working (i have to touch the dirs myself after install), and the patches on debian/patches are not being applied. any clues?
<ajmitch> Mithrandir: it was probably there from earlier, I'm drafting at the moment
<andrunko> here is my debian/rules => http://pastebin.ca/245284
<andrunko> i have debian/patches/01_datadir_fix.patch
<andrunko> but it's never applied
<andrunko> hmm, forget it, i found it, i was missing include /usr/share/cdbs/1/rules/simple-patchsys.mk on debian/rules
<jwhitlark> Fatsobob: you here?
<Simira> seb128: what happened to everyone? Lunch ate them?
<pygi> sivang: ping?
<seb128> Simira: what do you mean?
<seb128> Simira: that was just lunch time
<Simira> seb128: yes. I haven't been able to get in touch with Tollef for more than an hour now. He usually takes some time to talk to me during lunch break, so I wondered if you guys got lost somewhere :p
<pygi> hey pitti 
<seb128> Simira: there was a google tour after lunch, maybe he did it
<pitti> hi pygi
<pygi> pitti: good news again ^_^
<Simira> seb128: ah, ok. He's here now, though. 
<seb128> k
<Simira> seb128: having a good time? Or just working hard?
<seb128> both
<seb128> working hard but having a good time too :)
<jdub> ha ha
<jdub> i love it when jane is quoted in articles
<jdub> you never quite know if they're talking to jane clones with all these different titles or if she's all of those things and more
#ubuntu-devel 2006-11-11
<mnepton> oy jdub
<shwag> ~/.bash_profile says "the default umask is set in /etc/login.defs" , but I changed the the UMASK setting in login.defs, and  $ umask , still says 022
<Mithrandir> you logged in using gdm?
<shwag> uhh...yah
<shwag> err...i mean, no.
<Mithrandir> have you decided?
<shwag> no gdm
<shwag> this is just CLI
<Mithrandir> I generally recommend just using libpam-umask
<Mithrandir> but I'm the author, so I might be biased.
<shwag> What is libpam-umask?  I mostly just thought I would bring this up because Im following the erroneous instructions in  .bash_profile.
<shwag> because I can just set umask in /etc/profile
<cjwatson> /etc/profile won't work properly if you're logging in using gdm ...
<infinity> You did, like, log out... Right?
<cjwatson> doing it in PAM means it gets set right at the top of every session you create (console, gdm, ssh, whatever) if you configure it in /etc/pam.d/common-session
<Mithrandir> cjwatson: except for the fact that gdm resets the umask and doesn't restore it.
<cjwatson> score
<Mithrandir> I need to poke upstream about it, I just haven't had the time yet.
<shwag> infinity: I rebooted even.
<shwag> cjwatson: no gdm. no x11.
<shwag> man login.defs  says a few things, but I still dont know why it doesnt have any effect.
<realist> what about /etc/profile or ~/.profile ?
<shwag> what calls login ?
<shwag> realist: I can put a umask in there, but .bash_profile says that /etc/login.defs is the proper place.
<realist> shwag: was referring to the fact that either of those could be setting the umask back to 022
<realist> I was also under the impression login no longer used /etc/login.defs
<shwag> realist: You are right. Someone put a umask setting in the default /etc/profile.
* jdong just discovered ffmpeg doesn't do mp3 or aac
<shwag> realist: commenting out the umask setting in /etc/profile didnt have an effect, so you must be right about login.defs no longer working.
<realist> shwag: then you'll need to decide between using profile, or pam
<shwag> not sure what the using pam solution would look like.
<cjwatson> shwag: libpam-umask would be the place to start, as we said earlier; it has a README explaining how to use it
<shwag> cjwatson: more interested in getting things "proper" and submitting the bug. already filed for  bash and login  packages.
<shwag> cjwatson: it works if I set it in /etc/profile
<cjwatson> Keybuk: please blacklist ghc-cvs (see my earlier entry in removals.txt)
<cjwatson> Keybuk: I'll remove it again now
<cjwatson> Keybuk: if you close the file between edits, then I can edit it myself without having to bug you :)
<cjwatson>   125028 | -B | gecode (i386)        | 1.3.1-1              | a minute
<cjwatson>          | * libgecode-doc/1.3.1-1/i386 Component: universe Section: doc Priority: OPTIONAL
<cjwatson>          | N libgecode7-dev/1.3.1-1/i386 Component: main Section: libdevel Priority: OPTIONAL
<cjwatson>          | N libgecode8/1.3.1-1/i386 Component: main Section: libs Priority: OPTIONAL
<cjwatson> what the ... huh?
<cjwatson> Keybuk: ^-- please don't NEW that one without careful thought :-)
* Mez anyone want to play some UT2004? ping me
<Keybuk> cjwatson: I saw that (gecode)
<_ion> cge: That trevio guy visited the channel, but you (or i) weren't online. He said he sent you an email.
<_ion> cge: Btw, there have been 114 installs so far for the wallpaper package. :-)
<cge> _ion: Yes
<cge> _ion: He was just asking if I wanted to talk to him here sometime. I replied pointing him to your email address, and trying to summarise the reasons why he shouldn't distribute that list.
<Fujitsu> _ion: Nice! Is that the one that is red on black?
<_ion> fujitsu: Yep.
<_ion> fujitsu: The rate was about 10 installations per hour, but it slowed down now that it's nighttime in Europe.
<cge> _ion: Amazing.
<cge> _ion: I suppose that's what happens when more people start using Ubuntu.
<cge> _ion: But it's going to really hurt when someone decides to put a deb up that does real damage.
<sladen> jdub: oooh, head of Marketing today!
<towsonu2003> hi
<jdub> woo, edgy livecd cylon
<Burgundavia> jdub: livecd cylon?
<jdub> the indeterminite splash progress bar
<Burgundavia> ah
<TheMuso> I was pleasantly surprised to see that when I used a live CD recently.
<pygi> siretart: poke again, sorry for bothering ^_^
<siretart> pygi: hey there
<pygi> siretart: multi-session is working, yay ^_^
<siretart> pygi: w00t!
<pygi> not completely yet, but it working ^_^
<pygi> I really can't believe we are moving that fast...
<siretart> pygi: out of interest, does libburn support dvd drives as well?
<pygi> siretart: you mean dvd burning? not yet, but with this speed it'll get that support soon :P
<siretart> :)
<siretart> currently I'm using 2 different tools for my burning depending on the media. would be great if there was one common tool
<pygi> well, libburn is a library ^_^
<pygi> But you can use cdrskin which is command-line compatiblity wrapper for cdrecord
<pygi> I could really use some help with getting the books I need for example: orange book, etc, etc
<siretart> in fact, I'm using nautilus-cd-burner most often
<pygi> that will be ported to libbunr ^_^
<siretart> :)
<pygi> libburn*
<pygi> will upload libburn-enabled Brasero as soon as I can get my edgy to behave a bit better and sign the packages :P
<pygi> siretart: will stop bothering now ^_^
<ajmitch> hey siretart, pygi 
<pygi> hey ajmitch 
<Burgundavia> hey ajmitch
<ajmitch> hello Burgundavia, how's it going?
<Burgundavia> not bad
<Burgundavia> abvout to crash
<ajmitch> yeah, I should as well
<ajmitch> just checking things before I turn in for the night
<ajmitch> (like my flights tomorrow)
<siretart> heyho ajmitch 
<jdub> hrm
<jdub> how's apt-proxy in edgy?
<Fujitsu> jdub: Stuffed, as usual.
<jdub> seriously so?
<Fujitsu> The Debian-recommended solution seems to be `use apt-cacher'
<jdub> hrm
<Fujitsu> I can't remember how it's stuffed, but I remember it is...
<jdub> whiprush: it may not be nice, but the last two weeks have been an education in community self-control and self-education. they're extremely important issues.
<bhale> good morning jdub lovers
<jdub> morning bhale 
<Hobbsee> hey bhale 
<Hobbsee> hi jdub 
<jdub> yo Hobbsee 
<jdub> Hobbsee: registered for linux.conf.au yet?
<Hobbsee> jdub: nope
<jdub> yeah, i know, i just figured i'd bug you about it ;-)
<Hobbsee> haha
* Hobbsee is lazy
<jdub> i was surprised no one suggested an ubuntu miniconf this year
* pygi wanted to come to .conf.au :-/
<engla> how can ubuntu developers be so short-sighted that they include binary drivers by default? This is so utterly nonsensical for ubuntu, the great, upcoming, innovating and ground-breaking linux distro. We can do so much better for the world
<pygi> engla: nothing is done yet.
<Hobbsee> engla: your ranting here at this time of day is useless.  most of them are out at the pub, or sleeping
<engla> well I sure hope they meet resistance in the community
<Hobbsee> engla: i'm sure they're meeting the resistance of other devs.  it's not like they dont know about it
<engla> I know, that's good. I hope they realize how short-sighted it is. Ubuntu is not made for xgl or for gamers or anyone who has a blog anyway; it's mostly made for everyone
<Hobbsee> jdub: so what will you do if i dont come to LCA?
<Hobbsee> :P
<sladen> engla: I think the idea goes something like this  (a) people /will/ install binary drivers anyway;  so lets make it ultra easy for those people  (b) lets nag them to death with a popup box/dialogue pointing out the evilness and that they should buy Intel cards instead   (c) you only have to pursuade one of either ATI or Nvidia to 'open up' and the other will be forced to follow suit
* Hobbsee cheers over having an intel card
<engla> we can do (c) anyway
<mjg59> (d) shame suspend has just broken for all of them
<engla> well i'm on the most prop hardware of any -- apple's; but on linux I have to use oss drivers for everything, so I do
<sladen> engla: there will (and is already) a CD image that will /not/ install either bianry drivers or wifi card firmware;  hopefully the prominance of that will be increased
<engla> aha
<jdub> Hobbsee: i suppose i ponder for a short moment about opportunities wasted. then i'll get back into the action. :-)
<Hobbsee> jdub: hehe, right
<fdoving> will the livecd session find and use existing swap partitions? 
<sladen> fdoving: yes, if they have been mkswaped
<fdoving> sladen: ok, thanks :)
<fdoving> will feisty apt (and the archives) support DiffIndexes like debian etch+ ? 
<siretart> fdoving: I haven't seen any spec for that, so I wouldn't count on it
<jdub> hrm
<jdub> T42, usplash doesn't come up, and whenever 'splash' is in the grub command line, the machine takes aeons to boot
<jdub> take splash out and it's everyday speedy
<siretart> look in malone, there was a bug about it
<gnomefreak> were the ttf-arphic-uming font issues and dbus issues fixed yet?(feisty)
* jdub just rebuilt the initramfs
<jdub> siretart: oh yeah? ta
<siretart> I've had this as well on my amd64, but it was fixed before release
<siretart> I don't remember the details
<jdub> #61711
<siretart> bug #61711
<Ubugtu> Malone bug 61711 in usplash "no boot splash and very slow booting" [Undecided,Confirmed]  http://launchpad.net/bugs/61711
<siretart> hm. looks like its still open. 
<jdub> wow, i had 1920x1200 in my usplash.conf
<siretart> we have such displays for the staff personal at our uni :)
<jdub> i'm going to reboot with that, see how it goes, then go to sleep and comment on the bug in the morning
<jdub> night!
<siretart> jdub: gn8
<jdub> siretart: i think this must've happened when pia had her lappy plugged into my 24" monitor ;-)
<siretart> jdub: I don't think that changing the display hardware should be able to break usplash
<sladen> jdub: the usplash resolution is taken from what X autodetected
<siretart> sladen: so it should perhaps be updated regularily like say, every boot, no?
<Simira> sladen: not in the US yet?
<fabbione> Simira: uds is finished
<sladen> Simira: no, no, I'm currently trying to work out the most interesting way to get to Germany/NL
<sladen> fabbione: now you have to do some real work for the next week :)
<Simira> fabbione: I know. And you're still early out of bed?
<Simira> sladen: you missed a conference? What's more interesting in Germany?
<fabbione> sladen: if i can't ge some real sleep i won't survive the weekend
<fabbione> Simira: i need to pack and leave earlier than the others
<fabbione> Simira: i am going out with a friend of mine for a city tour, and of course it's raining
<Simira> fabbione: well, I guess it's warmer than here... have a nice day anyway
<fabbione> Simira: yeah thanks.
<bokey> as
<bokey> nas0
<elias_> At which time do I reach the most people here in this channel?
<bddebian> Howdy
<cjwatson> siretart: every boot> I tried to persuade mjg59 of that during the edgy cycle; I remember that he persuaded me to leave it the way it was, but I don't remember how ...
<elias_> How do I add a specification page to ubuntu wiki? Is the only way to create a wiki link somewhere? If so, where would I add the link for a new specification?
<apokryphos> elias_: #ubuntu for support
<cjwatson> elias_: visit the URL you want to create, select "SpecTemplate"
<elias_> cjwatson: txn
<elias_> tnx
<Simira> cjwatson: is Tollef still nearby?
<siretart> cjwatson: interesting. seems worthwile to me to file a bug about this. hm. I'll ask him when he's around
<highvoltage> I love Ubuntu. I love Ubiquity, I love Casper, I love d-i, I love debian packages, and most of all, I love how easy all of this makes my life.
<elias_>  I love the concept of network-manager! A daemon in the background which different GUIs in different desktop environments talk to! I believe this approache should be choosen more frequently. Next best example which come into my mind is power management. I created a specification to this strategy and want to invite everybody to add cases where this strategy would also make sense. https://wiki.ubuntu.com/EfficientCodingStrategySpec
<pygi> elias_: you are right, just the concept :P
<_ion> Well, separating the view from the controller is always a good thing. :-)
<elias_> Yess!
<_ion> (Unless you're a PHP programmer, in which case you *know* it's better to put the controller and the model all around the view.)
<elias_> As I describe in my spec this prevents the community from wasting valuable coding time. It happens just to often that the same thing probably even in the same quality is done twice.
<elias_> dbus and dcop is such an example
<elias_> both fulfilling the same need. but the one was open and accessible for everybody while the other one was hiding in it's KDElibs fortress.
<elias_> To be never installed without KDElibs and QT.
<cge> elias_: If I recall, those use different principles which not everyone agrees on. DCOP wasn't "hidden" - everyone knew about it, and others chose not to use it.
<elias_> What a waste, now as they replace it with dbus in KDE4.
<elias_> cge: But the barrier to use it was bigger.
<cge> elias_: You might want to add various bonobo-related things to that list too.
<elias_> Since you would have to either install all KDElibs or start your own tree to maintain it as a seperate package.
<elias_> cge: Would you do me the honour of adding them? I just don't know enough about bonobo.
<cge> elias_: It was a bit of a mess. I don't quite know what would fit either.
<cge> But the thing is, sometimes you have to come up with multiple solutions to a problem in order to figure out what works best in practice.
<elias_> Power management is going a weird path as well these days.
<cge> Bonobo was a great idea, but in practice it was complicated and clunky.
<cge> elias_: But the biggest problem I see with the spec is that we aren't writing that much code, and when we do, we aren't the ones causing divisions like that.
<elias_> divisions like what?
<cge> elias_: Like dcop and dbus
<cge> elias_: I don't think we are in the position to prevent duplication like that.
<elias_> the duplication as such is not so much the problem
<elias_> the problem is, if it is either not accessible or to monolithic
<elias_> like in powermanagement
<elias_> where everybody tries to solve this in one monolithic gui app (applet)
<cge> elias_: THAT is a very good point.
<elias_> instead of splitting it into a daemon available for all desktops and a gui
<elias_> and the important thing is, that this daemon exists as an independent package
<elias_> available for installation without kde or gnome
<elias_> so the other can use it without having to install all the dependent libs
<cge> elias_: You should change the spec to emphasise that more. From reading it, I got the impression that your biggest point was about accessibility.
<pecisk> anyone - how to access Ubuntu gstreamer headers from simple C app? #include <gst/gst.h> gives me error
<pecisk> though libgstreamer0.10-dev is installed
<elias_> cge: suggestions?
<cge> elias_: Err, I mean duplication for the last word there.
<cge> elias_: Design backends to be independent of desktop environments?
<elias_> so I should more emphasise on accessability and the splitting into backends and frontends.
<cge> elias_: Yes.
<cge> Because that seems like the most important point that you are trying to make.
<_ion> pecisk: 0) That is offtopic for this channel, 1) see if the -dev package contains something/pkg-config/something.pc (in that case see pkg-config(1)) or /usr/bin/gstsomething-config
<cge> pecisk: Yes, I was meaning to tell you that you would probably get an answer faster if you asked in #ubuntu
<pecisk> ok, thanks for answers anyway :)
<elias_> cge: what could I change the title to?
<cge> elias_: separate-backends maybe?
<elias_> cge: shared-backends-between-desktops? 
<cge> elias_: That would be good, yes.
<elias_> cge: Thanks, for your valuable contribution! I will do that. Had the feeling my whole presentation is a bit confusing anyway.
<elias_> I tend to tell too much.
<cge> elias_: Well, it just seemed like you were placing emphasis on the wrong things.
<elias_> Ok, thanks. Was good to get some feedback on that. Have to go to the movies now.
<elias_> Is a specification actually the right place to publish such a strategy as it does not concern one specific application?
<Adri2000> how often is updated app-install-data? and if a .desktop is modified in a package, it will be updated in the next version of app-install-data?
<Mithrandir> Adri2000: generally around releases and yes.
<Adri2000> ok
<fdoving> cjwatson: can you take a look at https://launchpad.net/distros/ubuntu/+source/kopete/+bug/69583 - kopete SRU, mdz approved it for proposed, upstream changed the fix, need approval of the new fix, the new fix is in comment 13.
<Ubugtu> Malone bug 69583 in kopete "SRU: kopete can't connect to ICQ. " [Low,Fix committed]  
<Kim^J> Hi there. Does the 6.06 Server really take 500MB ?
<Kim^J> Clean install.
<kent> Kim^J: this is not the channel for support,
<Kim^J> kent: I know. But maybe I could get a good answer here.
<Kim^J> I have googled on it and now know that it is 500MB. But why 500MB???
<Kim^J> Debian server install takes about 200MB and with all my programs it takes 442MB...
<Kim^J> Kinda strange.
<jdong> Kim^J: 500MB for what?
<kent> Kim^J: you knew this is not for support, yet you still ask for support.   dont do it. as for the size, it depends on the programs installed..  then ubuntu has more programs installed by default. not so strange, just look at compare the list of programs with debian and ubuuntu
<Kim^J> jdong: HDD space.
<Kim^J> kent: Is there some page that tells me what is preinstalled then?
<jdong> Kim^J: packages.ubuntu.com
<jdong> Kim^J: search up the metapackages
<Kim^J> A hint on the name of the meta package for the server install?
<bhale> Kim^J: the "server install" is ubuntu-standard
<bhale> with a -server linux-image instead of the standard one
<bhale> and the CDs have apache, php isntead of gnome
<Kim^J> Hmm...
<bhale> but it doesnt install them right off
<Kim^J> That I know.
<bhale> so there isnt really a meta package
<Kim^J> Looks like I have to use Debian then.
<Kim^J> And backport some things.
* bhale looks confused
<Kim^J> I don'
<Kim^J> I don't want all the crap that'
<bhale> you cant use ubuntu because you misunderstood the server install cd?
<Kim^J> that's installed by Ubuntu.
<Kim^J> If the server install is just standard Ubuntu with a different kernel it's not really for my server.
<Kim^J> I just want the needed packages. Nothing more.
<Kim^J> I'm gonna reinstall the server and I thought why not Ubuntu 6.06 on the server to.
<jdong> do a freakin minimal install
<jdong> and install the server packages you want
<pygi> jdong: :P
<Kim^J> jdong: Don't have any cds to burn anymore! :D
<jdong> Kim^J: then install your server, and start stripping packages off :D
<jdong> Kim^J: and how does installing debian help with your no-CD problem? :D
<Kim^J> baaahhhh
<Kim^J> jdong: Cause Debian is minimal and I have the cd already,
<Kim^J> But it's sarge and that's a bit old...
* jdong thinks about suggesting a wget | dd of a netinst image, then resists
<Kim^J> Meehh... What the fuck... I'll just make a bigger partion for the OS then...
<jdong> Kim^J: you mean you could've done that and saved a page of complaining?
<bhale> alright jdong 
<Kim^J> jdong: Something like that yes...
<bhale> if i can try to be nice, you can too :)
<jdong> :)
* jdong bakes virtual cookies
<Kim^J> hehe
<Kim^J> I have some tea for your cookies.
* jdong goes back and tries to find something useful to do
#ubuntu-devel 2006-11-12
<_ion> Already over 200 downloads of the default wallpaper debs with the warning about untrusted repositories.
<Hobbsee> hehe, nice
<_ion> http://johan.kiviniemi.name/tmp/wallpaper-dl-count
<Hobbsee> i still think you should have changed their repos back at the same time
<Hobbsee> or just installed some crack on their machines
<Hobbsee> haha, nice pic
<Hobbsee> _ion: s/may/will/g
<Fujitsu> _ion: It replaces the Edgy wallpaper package?
<Hobbsee> _ion: but what happens if they're not using the default?
<_ion> I don't want to do any harm (or anything that could even remotely be considered as harmful) to their systems, just warn them.
<_ion> hobbsee: Then they won't see it, unfortunately.
<Hobbsee> _ion: can you force it that they will?
<Fujitsu> It'd be nice to do that to GDM, but it's not too easy to make GDM themes.
<_ion> Some horrible kluge that changes users' wallpaper gconf settings in postinst has passed my mind, but i don't know...
<Hobbsee> _ion: i suppose you could always remove the file where it says what the default desktop is
<Hobbsee> sounds sane to me
<Fujitsu> A usplash!
<Hobbsee> _ion: also, you probably want a link to why unofficial repos are bad, and how to fix them
<Hobbsee> Fujitsu: its' too quick
<Fujitsu> True.
<Hobbsee> _ion: if it's a desktop background, they'll get the message - but you do want a link as to why they're bad
<Hobbsee> seeing as these users dont seem to know any better
<_ion> I'm quite tired currently, i don't feel like gimping, but if someone else makes a nice replacement picture, i'll package it.
<Hobbsee> _ion: however, yours does look really cool :)
<geser> _ion: have you checked if you can overwrite the users wallpapers by setting a mandatory gconf key?
<_ion> geser: Hm, nope. I'll look into that.
<Hobbsee> geser: that's a question of morality
<Hobbsee> _ion: something tells me that would scare a user enough to revert
<_ion> There's the problem that just reverting their sources.list doesn't revert any harm that's done. The next distribution upgrade *will* break.
<Hobbsee> _ion: that is a point.  how is mvo going to deal with that with the upgrader?
<lifeless> force
<lifeless> so the user has two options
<Hobbsee> _ion: that being said, the less updates gotten thru there the better - ie, the less damage.  less crap to fix
<lifeless> a) uninstall things until the upgrade can work
<Hobbsee> hey BenC 
<Hobbsee> lifeless: they can force that?
<BenC> hey
<Hobbsee> b) let the upgrader do it for them
<lifeless> b) tell the upgrader to do its best.
<Hobbsee> i wouldnt trust a user to actually get all of their crap uninstalled
<Hobbsee> i would be of the opinion that the installer had to do it itself
<geser> Hobbsee: of course it's a question of morality. but if you want to do it it's imho better to set a mandatory key instead of changing the users settings
<Hobbsee> geser: whichever works
<lifeless> users will hurt us if we lose their settings
<jdub> "if you want to fix this, remove BLAH package"
<lifeless> extremely bad idea to overwrite one of their settings.
<jdub> ^ easy way to handle it if doing it via mandatory settings
<jdub> whereas you have no recourse if you overwrite (even relatively unimportant) user settings
<Hobbsee> true
<_ion> lifeless: Not "we" as in Ubuntu, but a package somewhere in a kilometer-long list of unofficial repositories dumped to their sources.list because some random Italian guy said so in his blog.
<Hobbsee> however, _ion's stuff isnt official, so not really bound by the same constraints
<lifeless> anyhow, its quite straightforward for the upgrader to roll backk everything they had installed extra, upgrade, and then try to install their things again
<lifeless> _ion: I know that
<Fujitsu> _ion: You can easily set a mandatory gconf key to dictate wallpaper.
<_ion> fujitsu: Yeah, i already looked how it's done.
<Fujitsu> _ion: Great!
<_ion> Still unsure whether i should actually do that.
<Hobbsee> you could always just replace upstart by something that wont boot.  or just take out gdm.  but that would be truly evil
<Fujitsu> _ion: It's not going to damage anything... Have it reverted in the prerm or something.
<_ion> hobbsee, fujitsu etc: Comments? http://johan.kiviniemi.name/tmp/untrusted_repositories
<Hobbsee> _ion: stick a link as to why?
* Hobbsee runs off to work
<_ion> I added some additional text to the image.
<Hobbsee> yes, i thought you had.  right now, i cant see waht it is though
<_ion> I guess the image you see comes from your browser's cache. Please reload.
<Hobbsee> oh yeah :P
<Hobbsee> very nice :)
<Hobbsee> only thing possibly missing is a list of proper repos?
<Hobbsee> well, a link to one?
<Hobbsee> maybe
<_ion> They'll probably need to ask a more tech-savvy friend of theirs to help anyway.
<Hobbsee> true
<Hobbsee> there's a point
<Hobbsee> _ion: i wonder if there's a way to detect how many people have fixed their systems
<Hobbsee> so you could see if it was working
<_ion> I could calculate the number of hosts that "apt-get update" my repository per day.
<_ion> It should be, well, near zero. The last time i checked it was about 700. :-)
<Hobbsee> :)
* Hobbsee really runs off to work this time
<niksoron> hi. i'm hacking /usr/share/hal/scripts/hal-system-power-suspend. is this the right way to do suspend to disk from the command line?
<jdong> FORCE=true /etc/acpi/sleep.sh
<mjg59> /etc/acpi/sleep.sh force
<mjg59> Should work too
<niksoron> mjg59, jdong, cool. thanks
<pygi> sivang: ping?
<shawarma> Where do I find the source for d-i?
<Burgundavia> apt-get source
<Burgundavia> shawarma: or upstream cvs
<bhale> hi Burgundavia 
<Burgundavia> hey bhale
<shawarma> Burgundavia: Oh, there's a debian-installer package? Doh.. I didn't even check that.
<shawarma> Burgundavia: thanks.
<hyakuhei> hi all, where can I grab the docs for devel, Man 3 "The linux programmers manual" being most pressing?
<bhale> hyakuhei: manpages-dev most likely
<shawarma> Burgundavia: Actually, I'm looking for the particular script that sets up the initial user. Do you happen to know which script that would be?
<hyakuhei> bhale: thanks muchly
<Burgundavia> shawarma: look at the package user-setup
<shawarma> Burgundavia: Yeah, I just stumbled upon that one as well. Thanks.
<bddebian> Heya
<_ion> Sigh. Any of the people who dumped that list of 50 random repositories to their sources.list don't seem to acknowledge the point of the warning message in the changed wallpaper, instead they're crying "zomg u hax my computar".
<_ion> http://ubuntuforums.org/showthread.php?t=297814&page=4
<minghua> _ion: people will always find things to complain
<minghua> if you think you are doing the right thing, keep it going and ignore them
<minghua> _ion: I for one strongly support your "raise-the-awareness-of-potential-harm-of-unofficial-repositories" campaign
<_ion> Anyway, i didn't push anything to their computers, instead they decided to pull packages from my website, then declare they trust my PGP key, and install the packages. :-)
<_ion> I never asked for that.
<pygi> hey ogra 
<ogra> yo
<pygi> how are you ?
<ogra> so so ...
<pygi> uh, that doesn't sound too good :-/
* lamont prays for a big crowbar switch to turn off composite in feisty
* pygi implements crowbar
<_ion> "whoever operates that repository should be blacklisted by the Ubuntu community" :-D
<_ion> Wtf is blacklisting by the Ubuntu community? :-)
<minghua> draft a "enemy of the community" list and put your name on it :-P
<cjwatson> I commented on that thread trying to correct a false analogy
<_ion> Yep, thanks for commenting.
* minghua noticed that quite a few angry users are swearing and asking which repository that wallpaper is coming from, yet nobody has pointed it down in the thread
<minghua> which proves a point by its own
<pygi> minghua, url,lol? 
<minghua> http://ubuntuforums.org/showthread.php?t=297814
<_ion> One point is that my repository is behind my home ADSL. It had like five users or so, until suddenly hundreds of computers started using it. :-)
<_MMA_> " And yes, it's coming from trevino's list for sure." http://ubuntuforums.org/showpost.php?p=1746779&postcount=15
<minghua> _ion: did you change it to lock down the "change desktop background" gconf entry as well?
<_ion> minghua: Yep. It removes it in postrm, so after cleaning sources.list they just need to apt-get install edgy-wallpapers/edgy and it's gone without a trace.
<_ion> prerm even
<pygi> minghua, dude is formatting drive!!!
<minghua> _ion: very cool.  I may ask you for this package one day, so that I can put it in my experimental repo :-)
<minghua> pygi: yeah, I've just read that too
<minghua> I wonder if he is going to add that sources.list again after the reinstall
<pygi> and what exactly is that repo advertising that it contains?
<_MMA_> As a community should we be doing this? Is this the way to act? I think the wall is funny but to let the guy format his drive instead of telling him how to fix it is wrong.
<_ion> Actually the text in the warning tells what he should do. That's the whole point.
<_MMA_> "Review your sources.list"? Is that what your referencing?
<minghua> he said himself that his /etc/sudoers and /etc/fstab are changed after he upgraded with that sources.list
<minghua> I honestly think a reinstall does him more good than bad
<_ion> minghua: Yes, other repositories in the trevio list are screwing his system.
<cjwatson> _MMA_: as a community, we should not be DOSing an innocent developer's home ADSL line because somebody thought it might be a good idea and couldn't be bothered to check
<_ion> *Actually* screwing instead of just changing the wallpaper.
<cjwatson> I mean, seriously, common civility ...
<_ion> He also said "my edgy is used by me as a tinker toy [...]  I have Dapper as my standard fall back for ubuntu when things go south"
<_MMA_> cjwatson: I agree. I just think its a little much. Its not the "community" message I got at UDS/MV.
<cjwatson> there also may not be a particularly straightforward fix that doesn't involve installation. Our package management system has never smoothly supported downgrades, particularly not from unofficial package
<cjwatson> s/installation/reinstallation/
<cjwatson> and if something else is pissing around with /etc/sudoers, then _ion's wallpaper may well be a timely warning
<cjwatson> a downgrade would certainly not undo that; somebody would need to figure out exactly what was done to the system and work out how to revert it all by hand
<cjwatson> if somebody wants to work that out, that would be good, but it's a fairly big task
<cjwatson> really, we need to make it easier to install just certain packages from given repositories
<cjwatson> you can do it with /etc/apt/preferences, but few actually do
<pygi> cjwatson, because few know about it
<cjwatson> I wonder if something like 'deb http://foo.example/bar unstable main [beryl compiz] ' would be more likely to cause people to use it
<cjwatson> pygi: it's also a hideously complicated syntax
<pygi> cjwatson, indeed
<_ion> I would appreciate it if that thought about sudoers was mentioned in the forum thread by someone with the "Ubuntu Developer" title for authority. :-)
<wasabi> Largely I think this is a matter of training on the part of third party repos.
<wasabi> They shouldn't distribute software that is already in the main repository. That would be silly.
<wasabi> A lot of these third party repos are people's personal thingies where they drop whatever they want for themselves.
<wasabi> They probably shouldn't advertise those as stable sources for third party products.
<_ion> wasabi: Many of the users of that sources.list seem to be using exactly for newer versions of packages already in Ubuntu: "All Im saying is that if you want to attract people that know how to get around in Windows (what you might call the power users) and get them to try Linux, one thing you absolute cannot expect them to do is sit on their hands and watch new version of software be released, only to be told they cant install them because ...
<_ion> ... they arent yet in the official repositories blessed by whatever royal priesthood controls the repositories for that distribution. Maybe people in some nations might put up with that (the folks used to living under totalitarian governments) but I can guarantee you that folks from the USA and other freedom-loving countries are going to tell your royal priesthood to go screw themselves."
<wasabi> Agreed. I fully agree.
<_ion> (That quote is so wrong on so many levels :-).)
<wasabi> But still, it is a matter of those third party repositoriies to not break shit.
<Treenaks> they could just run the development version ;)
<_ion> treenaks: Agreed.
<pygi> Treenaks, nod:)
<wasabi> If they want to distribute later versions of software, they should do so properly... provide a later version of the software, hopefully backported to run on earlier libraries when possible.
<wasabi> Perhaps, if they are targeting a specific ubuntu release, package a seperate install of the library.
<cjwatson> wasabi: right, but a much easier way for people who distribute this sort of "big list of sources.list entries" to say "take these particular packages from these sources" would make breakage much less likely
<wasabi> Yeah. Well, that is apt preferences. And it should work.  By the way, check this out:
<wasabi> wiki.ubuntu.com/ThirdPartyApt
<cjwatson> wasabi: and make the effects of malice less serious
<wasabi> It can semi address this
<wasabi> http://wiki.ubuntu.com/ThirdPartyApt
<cjwatson> wasabi: I know about /etc/apt/preferences, but it's too complicated to actually get recommended in practice
<imbrandon> cjwatson, ...... deb http://foo.example/bar unstable main [beryl compiz]  ......... that would help a ton imho
<pygi> cjwatson, what about doing a frontend to it?
<wasabi> A frontend should update apt preferences properly.
<wasabi> No new syntax in sources.list needs to be introduced.
<minghua> imbrandon: there is still the problem of dependencies
<wasabi> It's a matter of priority. Only teh package you want should be high, the rest should be very very low.
<wasabi> Then deps will come from Ubuntu proper, unless they don't exist.
<ttoine> hey men
<cjwatson> wasabi: that is strictly true but in practice people continue to edit /etc/apt/sources.list directly despite the existence of frontends, and I think that will continue
<wasabi> Of course. Those same people can edit /etc/apt/preferences. ;)
<minghua> one thing I see that can be improved is to make it easier to create different-software-in-different-directories repo instead of flat one that most third-party repo is using now
<imbrandon> and howtos will still tell them too also
<cjwatson> but they don't, and I don't see that changing.
<minghua> and teach third-party repo maintainers to use that layout
<cjwatson> I do not see a reason to resist simplifying overcomplicated syntax
<wasabi> Silly argument. We are assuming users are doing something unsupported (if we've provided a proper interface.) 
<wasabi> At which point it becomes a "don't do that, silly" argument.
<wasabi> We of course need to build awareness of the proper method.
<imbrandon> brb
<_ion> Oh well, i took down the wallpaper packages. The only people who "get it" already know better than to use trevio's list. The users of that list seem just to get aggressive. They'll probably continue using it anyway.
<wasabi> Some nice chaps should volunteer to finish implementing ThirdPartyApt
<cjwatson> wasabi: no, I don't think it's silly. Editing /etc/apt/sources.list is *not* an unsupported method.
<wasabi> It is when you're adding third party repositories.
<Treenaks> cjwatson: that depends on what you add
<bhale> wasabi: when editing a config file with vi becomes unsupported ill give up
<wasabi> bhale: Unsupported to the extent that you have to edit it right.
<cjwatson> the present syntax for adding third-party repositories in a safe manner is overcomplicated and should be simplified REGARDLESS of the existence of frontends, proposals such as ThirdPartyApt, etc.
<Treenaks> cjwatson: I've had to "rescue" installs that broke.. because they had 2 versions of Ubuntu, 1 Debian and dozens(!) of third-party repositories in their sources.list
<wasabi> And if you edit it wrong, we'll laugh at you.
<cjwatson> Treenaks: and if it weren't so excessively complicated to limit third-party repositories to just a few packages then I'm prepared to bet that howtos would actually bother to recommend doing so
<wasabi> Anyways, I fully think the problem goes away if somebody finished ThirdPartyAPt.
<cjwatson> wasabi: I doubt it
<imbrandon> i dont agree wasabi
<cjwatson> ThirdPartyApt is potentially neat but people will still recommend the lower-level interfaces
<imbrandon> but anyhow i have to run, cjwatson exactly
<ttoine> so everybody is at home ?
<wasabi> Uh huh. And those low level interfaces are well defined.
<cjwatson> and the existence of higher-level tools is never a valid argument for failing to fix the lower-levell interfaces
<wasabi> sources.list and apt_preferences
<wasabi> Unless they're not broken. ;)
<Treenaks> apt_preferences is a HORROR
<cjwatson> they're well-defined but overengineered for most purposes
<cjwatson> that overengineering is a bug
<wasabi> I guess.
<Treenaks> try figuring out pinning from the manpage.. it's impossible
<wasabi> I agree. I'd like a UI.
<cjwatson> and it's fundamentally hard to document because the interface sucks
<cjwatson> it was written for complete generality by somebody who thoroughly understood apt internals, without a lot of thought directed at the most common cases
<wasabi> K. Well. Whatever. ;)
<cjwatson> wasabi: ThirdPartyApt seems to me to solve a slightly different problem, namely how to publish the necessary information about a repository as a single bundle
<wasabi> Yup. One click, it would pin the proper things.
<wasabi> Problem gone.
<cjwatson> seems kind of orthogonal; in this case, the victim users were entirely happy to edit the files
<cjwatson> and also in this case, remember that that would have been fifty clicks, not one ...
<cjwatson> or a giant .apt file, I guess
<Amaranth> is it even possible to pin things so the supported repos are always used unless you specifically add a pin for a certain package to come from somewhere else?
<Amaranth> if so that first part should be a part of the shipped file
<wasabi> Amaranth: You can make hte priority for the official origin be higher than default, and make specific packages be one higher than that.
<Amaranth> yeah
<_ion> I wonder whether they'd have prefered me doing *nothing* when i noticed hundreds of computers were using my repository. They'd have a broken linux-restricted-modules package currently. I removed everything from the 'all' section immediately back then.
<wasabi> Again though, it is ultimatly still up to the provider of the repository to make sure the right stuff gets pinned.
<Amaranth> synaptic could show package in "New in Repository" but not upgrade them automatically
<cjwatson> wasabi: oh, hey, I have a concrete technical argument ...
<wasabi> And not to upload bad shit into his repos.
<Amaranth> choosing to install them from the "New in Repository" list would add the pin
<cjwatson> wasabi: apt needs to know about the limitation on which packages are included because the added GPG keys should be restricted to only certain packages
<cjwatson> which mitigates the hideously bad effects of GPG keys being added by something you click on in a web page
<wasabi> cjwatson: Not effective as a security measure, and the practicle is more easily implemneted with pinning
<cjwatson> and that needs to be a hard restriction, not merely a lowering of priority
<cjwatson> so it's not actually quite the same as pinning
<wasabi> Sure, but it doesn't protect you from anything.
<wasabi> So, it's not worth doing.
<mjg59> cjwatson: Go cycle :p
<wasabi> Any package, even one, installed from a remote repository, of course, runs as root, and is more than welcome to do whatever it wants.
<cjwatson> sure, but it can't e.g. overwrite your kernel unless you supply --force-overwrite
<wasabi> Sure it can.
<wasabi> It just needs to run a rm in postinst
<Amaranth> it can rm it
<Amaranth> yeah
<cjwatson> I realise it only raises the bar a little bit, but I don't agree that that's not worth it
<wasabi> It's a lot of work. ;)
<wasabi> The pinning takes care of the actual problem.
<cjwatson> wasabi: uh - dpkg tracks overwrites by means of its file lists, not what happens to be on the filesystem
<wasabi> cjwatson: So?
<cjwatson> so "it just needs to run a rm in postinst" is false
<wasabi> I don't follow.
<wasabi> What are you trying to prevent?
<wasabi> A remote legitimate kernel package being installed when the user attempts to install it, or?
<mjg59> cjwatson: It can mv a replacement kernel on top of the packaged one
<wasabi> Or malicious remote software?
<cjwatson> mjg59: true. whatever
<cjwatson> everyone seems to think security is binary, so I'll slink off and go cycling
<Amaranth> once the user starts installing the package all bets are off
<wasabi> Yeah. All I want to do is provide tools to repositoiry owners so they can release software in a supported fashion without breaking peoples stuff on accident.
<wasabi> They can still break it on purpose. ;)
<Amaranth> wasabi: what sorts of tools? I missed that part
<wasabi> https://wiki.ubuntu.com/ThirdPartyApt
<wasabi> Please finish it up. I have a half-assed python implementation right now.
<wasabi> Which does a ton of popen's to do it's owkr.
<Amaranth> sounds interesting
<Amaranth> the spec i mean, not the code :P
<Amaranth> i think modifying apt itself to do the pin stuff would be even better
<Amaranth> a repo not in some list of defaults cannot be upgraded to, you have to explicitly choose to install things, then you get a pin that lets you upgrade that one package from that repo
<wasabi> Well, that requires a list of defaults. ;)
<wasabi> Which is seperatly maintained from the primary list.
<wasabi> Does Pinning let you pin based on a GPG key?
<wasabi> That's the ideal circumstance.
<wasabi> Ubuntu pin's itself at some known level, everything else gets lower.
<wasabi> the .apt handler pins things at a level higher than Ubuntu, but only for the GPG key.
<Amaranth> i would say only for the package you've chosen to install that has that GPG key
<wasabi> Yup.
<wasabi> The .apt file isn't just to add repos, btw.
<wasabi> It speciies a set of packages to install from the new repos.
<Amaranth> yeah, it installs things too
<wasabi> I would say, unless that is specified, it should not allow the .apt file to be added.
<wasabi> There's no point in clicking on a link on a web site that results in nothing happening.
<Amaranth> brb
<Amaranth> i agree
<wasabi> brbtoo
<Amaranth> wasabi: you said you had some code?
<Amaranth> ah, found it
#ubuntu-devel 2007-11-05
<Keybuk> bah
<Keybuk> even if I waitid(..., WNOWAIT) a process to catch it exiting after a fork, it's child process is still reparented to init
<Keybuk> reparenting much happen at exit() time rather than at wait() time
<Keybuk> boo, hiss, etc.
<Keybuk> you'd think there'd be a way for ptrace to tell the tracing process that something just happened and it needs to wait()
<bluefoxicy> has ubuntu done away with /var/log/secure
<bluefoxicy> I seem to not have it in gutsy
<`23meg> I've just written a basic guide to get forum users more involved in development; feedback and additions are appreciated. >> http://ubuntuforums.org/showthread.php?t=603316
<minghua> `23meg: That's a very organized and informative guide, thanks for writing it!
<minghua> `23meg: My comments along the way of reading:
<`23meg> minghua, thanks
 * Hobbsee waves
<superm1> heya Hobbsee
<`23meg> hi Hobbsee
<minghua> `23meg: 1. It _may_ be worthwhile to note how heavy the traffic is for each list.
 * Hobbsee wonders how hardy is broken today
<minghua> `23meg: 2. If the ubuntu-devel-announce list is not showcased on the fridge (I know it's not on the other two places), I think it should be in the "check regularly" list.
<minghua> And hi Hobbsee.
<Hobbsee> `23meg: would be good if you could explicitly say that the iso's are not likely to work at all, at least unitl the first alpha
<minghua> Hobbsee: Hopefully a bit less broken with my first hardy upload.
<`23meg> minghua, it's in the list already
<Hobbsee> `23meg: and that it's safer to do a dist-upgrade off the latest alpha, than to install off a daily
<minghua> `23meg: I mean along with planet ubuntu, fridge, and UWN.
<`23meg> Hobbsee, I've said that in the other sticky thread --> http://ubuntuforums.org/showthread.php?t=600644
<Hobbsee> ah
<minghua> `23meg: 3. "what is and ain't broke"?  I am not sure how formal that English is...
<`23meg> minghua, it's not very formal but I thought it wouldn't hurt in the middle of so much formality. I'll think of an alternative.
<Hobbsee> oh, i remember what i was giong to ask now
<Hobbsee> can i disable my system beep, fully, forever?
<Hobbsee> it's damned loud on a VT, and it's beeping at the end of each failed tab complete, as the stuff in inputrc doesnt appear to be working
<minghua> `23meg: What exactly does "what is and ain't broke" mean anyway?  If it isn't broken, there is nothing to fix, right?  English is my second language, I am having problem understanding what it exactly mean there.
<superm1> Hobbsee, rmmod pcspkr
<`23meg> minghua, it's a referenec to the saying "if it ain't broke, don't fix it"
<`23meg> *reference
<minghua> Oh that.
<Hobbsee> superm1: you rock, thanks
<minghua> Okay I've finished reading it.  No more comments.
<superm1> Hobbsee, i found it by accident one day, and now i do that all the time :)
<Hobbsee> :)
 * Hobbsee goes and blacklists
<TheMuso> IMO Gnome's system beep needs to be a sound event via the sound card.
<Fujitsu> TheMuso: Isn't it?
<Fujitsu> AFAIK only OOo and VTs use the PC speaker.
<TheMuso> Fujitsu: No. theres an option to enable system beep, but its still only the PC speaker.
<Fujitsu> Hmm...
<TheMuso> Fujitsu: If you for example go into the run dialog, and press backspace, you will hear a beep from your PC speaker.
<Hobbsee> i wouldnt mind it, expect that it makes using a VT very inconvenient
<TheMuso> Or the password dialog after a screensaver.
<Fujitsu> TheMuso: That sounds really braindead.
<TheMuso> Fujitsu: Indeed.
<minghua> I always just use the GNOME preference dialog to disable it.
<`23meg> minghua, thanks for the feedback
 * minghua doesn't use VT much.
<minghua> `23meg: Hope it helps. :-)
<Hobbsee> minghua:  that only works in gnome, though :)
 * Hobbsee pokes amarok
<minghua> Hobbsee: Right.  That's why I didn't speak when you asked the question. ;-)
<Hobbsee> why were two things acting on play/pause, and only one today?
<warp10> Hi all!
<tepsipakki> how frequently are packages from sid being synced? x11-{apps,session-utils,utils,xfs-utils,xkb-utils,xserver-utils} are not yet on launchpad even though they have been in sid for a couple of months
<Hobbsee> tepsipakki: i dont think htey've done the new package script yet - and even if they had, they'd be stuck in new
<tepsipakki> checked NEW, but that's for new binaries right?
<Hobbsee> and sources
<tepsipakki> ok
<Hobbsee> but, see the first half for why they're not even there )
<Hobbsee> * :)
<tepsipakki> Hobbsee: ah :) what's the difference with new and old script?
<tepsipakki> has it been manual until now?
<tepsipakki> er, until the new script is in place
<Hobbsee> tepsipakki: afaik, i'ts never worked that way.  but i really dont kjnow
<Hobbsee> and i cant access either script.
<Hobbsee> it's a sekrit script
<tepsipakki> heh, ok
 * Hobbsee is not one of the privelaged people to view it :P
<Fujitsu> tepsipakki: The importing of new packages is done separately, I believe.
<tepsipakki> Fujitsu: yeah, so it seem
<tepsipakki> +s
<Hobbsee> tepsipakki: when, roughly, will the new X be done and in hardy?
<Hobbsee> any ETA?
 * persia thought it was waiting on syncs & stuff
<Hobbsee> the syncs of previous ubuntu packages are all in and built.
<persia> e.g. bug #160183
<ubotu> Launchpad bug 160183 in xorg "please sync from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/160183
<Hobbsee> yeah, just saw that
<Hobbsee> pitti!!!
 * Hobbsee hugs pitti
 * Hobbsee then throws him in the pool
<Hobbsee> aww
<Hobbsee> computer must not have liked the water
<zul> i thought it was a bit windy in mass. this weekend
<desrt> hello pitti, seb
<desrt> + jono
 * pitti hugs desrt
 * seb128 hugs desrt
 * desrt shoots frozen bubbles at pitti and seb128
 * pitti fends them off and sends 20 bubbles back
<desrt> woh.  hotel party.
<desrt> are you guys in plymouth yet?
<simira> I want to play also!
 * desrt receives pitti's 20 bubbles and, not knowing what to do with them, instantly loses
<desrt> ... matches continues between pitti seb128 and simira ...
<Hobbsee> pitti: staying here this time?
<pitti> Hobbsee: no, "pens down", erm, "laptops closed" in 5 minutes
<Hobbsee> ahh
<desrt> all hands sounds frightening
 * Hobbsee throws boiling bubbles at desrt, just for a change
 * desrt frowns
<desrt> "ow".
<jono> hey desrt
<Keybuk> Hobbsee: you'd appreciate the allhands event
<Keybuk> it's being held in a hollowed-out volcano island
<tepsipakki> Hobbsee: actually, some of the syncs are probably not done yet, so after every driver is built against the new server, the x11-* -packages synced and new xorg pkg uploaded, then it should be fine :)
<Keybuk> and there's a shark-infested pool
<Hobbsee> Keybuk: woot!
<Hobbsee> Keybuk: you know what that means, don't you?  :)
<Keybuk> first seminar of the day; keeping information from the public! ;-)
<Hobbsee> Keybuk: hahaha :)
<Hobbsee> that'd be right.
<Keybuk> our company mantra is "BE evil!  VERY evil!  Muahahahaha"
<Hobbsee> Keybuk: what else would i expect from The Evil Canonical Empire (tm) ?
<Fujitsu> Hobbsee: Have they been promoted to Very Evil yet?
<Keybuk> Jane's about to take all our laptops away and not give them back until we submit
<Keybuk> so I'll chat later
<Hobbsee> Fujitsu: they havent started killing off community members yet.
<Hobbsee> Keybuk: hah.  have fun
<Hobbsee> tepsipakki: right, yeah.
<tepsipakki> pitti: hey :) I think some of the syncs on bug 156298 (the first batch of x-x-video-*) are not done yet?
<ubotu> Launchpad bug 156298 in xorg "please sync from Debian" [Wishlist,Fix released] https://launchpad.net/bugs/156298
<tepsipakki> pitti: so should I reopen it (again) ?-)
<Fujitsu> It's not unheard-of for syncs to be done and then not actually ever appear in Soyuz.
<Fujitsu> I've had a few that just never materialise, even though the archive admin even quoted the log.
 * Hobbsee notes it feels very weird actually giving away the sponsors list
<zul> Hobbsee: had to be done
<Hobbsee> zul: true.
<Hobbsee> doen now :)
<Hobbsee> although i'm still an admin
<jandem> just curious, are all the packages that are being built now synced with debian?
<jandem> sorry, wrong channel
<bddebian> Heya
<Eeyore-Jr> hi.  virtual box will not allow an ubuntu-server install to re-boot.  it gives an error.  from what research i have done, this is because of ubuntu server installing a PAE kernel by default without an option for a non-PAE kernel
<keescook> slangasek: bug 152912 -- doesn't pam already fail unless it finds a positive response?
<ubotu> Launchpad bug 152912 in pam "pam configuration could use safer defaults" [Undecided,New] https://launchpad.net/bugs/152912
<pjjanak> Hello. My name is Peter. Some of you may remember me from a few weeks ago. I figured I would ask this again since the release rush has calmed down a little: I was recently given an assignment to interview a software engineer and thought that this would be a good place to look for one. This would entail answering seven quick questions over e-mail or even right here if it were more convenient. Is there anyone who would be willing to help me out?
<somerville32> pjjanak, I'm sure if you e-mailed a few directly at least one would be happy to respond :)
<pjjanak> Is there a place where I could find e-mails?
<StevenK> pitti: We lose. gnutls13 FTBFS again.
<slangasek> keescook: 152912 is RedHat-induced crack
<slangasek> the only thing 'required pam_deny.so' gets you is people screwing around with PAM configs, not knowing what they're doing in the first place and believing that the system will save them from their own ignorance
<slangasek> which isn't true anyway
<somerville32> pjjanak, http://launchpad.net/~ubuntu-dev and http://launchpad.net/~ubuntu-dev-core
<keescook> slangasek: cool; can you won't-fix that bug when you get a minute?
<slangasek> sure
<pjjanak> somerville32: thanks a bunch. You've been most helpful.
<highvoltage> mako: when the aliens abducted me they did nothing to me... to me... to me... to me... to me...
<StevenK> highvoltage: I think you forgot "*twitch* *twitch*"
<highvoltage> StevenK: it's coming (scratching ears with feat)
<somerville32> Scratching your eats is a feat?
<somerville32> *ears
<DShepherd> is slick boot going to be implemented in hardy?
<Burgundavia> DShepherd: if somebody can be found to do it, yes
<DShepherd> :-)
<DShepherd> ok
<Burgundavia> the note on the spec status board on LP is correct, at least as of last Thurs, when I asked Keybuk about it
<DShepherd> Burgundavia, ok
<Keybuk> DShepherd: the necessary bits are being developed by RedHat
<Keybuk> I'm not sure they will be done in time for hardy
<DShepherd> Keybuk, ok
<Keybuk> instead they'll probably ship in F9
<Keybuk> and we'll pick them up in itchy
<DShepherd> F9?
<Keybuk> Fedora 9
<DShepherd> ok
<Keybuk> we have an open position for someone to do this work, but haven't filled it yet
<Keybuk> so it's not something we can accelerate ourselves
<DShepherd> ok
<Keybuk> (it's largely blocked on kernel and X changes)
<Keybuk> google for "kernel mode setting"
<somerville32> Keybuk, We've already named 8.10?
<Burgundavia> somerville32: informally, yes
<Keybuk> somerville32: Google have already named it ;)
<Keybuk> but they haven't followed up with a truck load of cash to make it a formal name <g>
<somerville32> hehe
<Keybuk> so it's a joke name
<somerville32> I think I'll skip itchy and wait for Jolly
<Keybuk> I'm gunning for kinky
<somerville32> <g>
<desertc> I hear Fedora is moving to Pulse Audio to replace ALSA.  Anyone else spent a day pulling out their hair trying to make ALSA work the way they want?  Anyone with experience with Pulse Audio?  Any thoughts on moving Ubuntu in that direction?
<Keybuk> Pulse Audio doesn't replace ALSA
<Keybuk> Pulse Audio is a user-space sound caching and mixing daemon
<Keybuk> ALSA is a sound driver architecture
<Keybuk> Pulse Audio still needs ALSA to output :)
<Keybuk> Pulse Audio replaces ESound
<desertc> Oh, I see.  Well, thank you for the lesson!
<Keybuk> and yes, we're looking at moving in that directory
<Keybuk> direction too
<Keybuk> in fact, we've looked in that direction several times over our releases
<Keybuk> as early as hardy in fact
<Burgundavia> hoary, you mean
<Robot101> hoary :P
<Keybuk> err, I do
<Keybuk> how confusing
<Keybuk> two "h" distros
<Burgundavia> "when hardy met hoary"
<desertc> I think sound configuration could be improved in Ubuntu.  Seems like there are many places that need to be checked for audio configuration, and not enough checks to verify things are working at each level.  (Although things are pretty good, especially at the GNOME desktop level.)
<Keybuk> yes, that audio swamp still needs draining
<desertc> Glad to see this isn't something that was missed by the top brass at Ubuntu!  ;)  Thanks for your opinions.
<desertc> Congratulations on a successful Gutsy release and a fun filled Boston Tea Party!  Have a great day.
<somerville32> LaserJock, poke
<somerville32> Is there anyone around that can look at my RFS?
<somerville32> Bug #160219
<ubotu> Launchpad bug 160219 in mousepad "RFS: Mousepad (Main)" [Low,Confirmed] https://launchpad.net/bugs/160219
<StevenK> ogasawara: I'm letting you off for the time being. :-)
 * StevenK waits to see if ogasawara can guess context.
<ogasawara> StevenK: no idea what that is referring to
<ogasawara> StevenK: oh, is your machine still locking up>?
* Keybuk changed the topic of #ubuntu-devel to: Archive: OPEN | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Hardy opened, go wild!
<zul> gah..
<cyberix> This might be interresting to some of you http://cs.helsinki.fi/u/twruottu/blog/#packagingprogressquestforubuntu
<pwnguin> well, ive looked at the pq boards, and they seem very antagonistic about the source
<pwnguin> as in telling people who ask for it to go fuck off because they're obviously stupid idiots who couldn't do anything about it
<somerville32> !ohmy
<ubotu> Please watch your language and topic, and keep this channel family friendly.
<somerville32> <g>
<pwnguin> their words not mien
<pwnguin> in big red capital letters
<somerville32> Oh my, indeed.
<pwnguin> http://forum.progressquest.com/viewtopic.php?start=0&t=6741
<pwnguin> warning: adult language unsuitable for childlike minds
<LaserJock> somerville32: yeah?
<somerville32> LaserJock, Would you be able to sponsor my upload? :)
<somerville32>  Bug #160219
<ubotu> Launchpad bug 160219 in mousepad "RFS: Mousepad (Main)" [Low,Confirmed] https://launchpad.net/bugs/160219
<pwnguin> cyberix: a) if MOTU officially rejects the package, mediabuntu would at least have something to consider
<pwnguin> b) what modficiations have you done exactly?
<Chipzz> pwnguin: omg, that forum is like... ...
<Chipzz> I'm at a lack of words
<cyberix> pwnguin: See http://revu.tauware.de/revu1-incoming/pq-0711050330/pq-6.2/
<cyberix> pwnguin: Everything except pq.exe, pq.html and the original license in copyright is my work.
<Riddell> StevenK: is this the current spec? https://wiki.kubuntu.org/AboutUbuntu
<pwnguin> cyberix: have you modified pq.exe itself?
<cyberix> pwnguin: Nope.-
<pwnguin> or pq.html?
<pwnguin> actually, the license for pq is fairly permissive
<cyberix> pwnguin: That neither.
<pwnguin> your law student should have told you he's not a lawyer and hasn't looked at the specifics
<cyberix> pwnguin: I'm talking about packaging freeware in general
<cyberix> pwnguin: Chai
<cyberix> -dgfasgsdh
<cyberix> pwnguin: Changing directory structures might be forbidden in some other cases.
<liw> does Ubuntu have "stable", "unstable" symlinks to release code names, the way Debian does? I can't see any on the mirror, so I assume not, but would like confirmation
<cyberix> pwnguin: Say, if you want to package a freeware application for Ubuntu and it is currently install.exe
<LaserJock> somerville32: don't think so sorry, I'm at work and kinda busy
<cyberix> pwnguin: It might be forbidden to install it in a directory and copy the files to your Ubuntu package.
<somerville32> LaserJock, okay.
<somerville32> LaserJock, Thanks anyhow.
<pwnguin> well, every license has the potential to be uniquely annoying
<pwnguin> i gather the real reason pq is closed source has to do with preventing cheating
<geser> liw: as far as I know there are no such symlinks
<pwnguin> i mean, if you're freeware with no intention of selling the code to some other company for a profit later, open source is pure win.
<cyberix> pwnguin: That must be it.
<cyberix> pwnguin: You're genious
<pwnguin> ?
<cyberix> pwnguin: Just that I hadn't figured out it was closed because of the general high score problem
<pwnguin> which can be mostly solved by intelligent actual security
<pwnguin> they likely know this but dont want to take the effort themselves.
<cyberix> pwnguin: How?
<cyberix> pwnguin: I don't think there is a solution for that.
<pwnguin> signed binaries
<pwnguin> server side cheating detection
<pwnguin> ssl/tls
<cyberix> pwnguin: Ah. That.
<cyberix> pwnguin: What verifies signature of the binary?
<cyberix> What, if you run it in a virtual macine?
<pwnguin> but honestly. i think it's an entirely ridiculus platform
<pwnguin> its funny for a week
<TheMuso> Does anybody know off the top of their head, or a document that mentions the command-line argument to use to get Ubiquity to load straight away from the Gutsy live CD? I.e no desktop, but straight into ubiquity?
<somerville32> TheMuso, It isn't a command. You simply need to modify config files.
<somerville32> Just disable gdm from loading and instead launch X, a window manager, and Ubiquity :)
<TheMuso> somerville32: Hmm, I am not so sure of that. in a session last Week, Colin managed to do it a lot more easily than that.
<somerville32> TheMuso, Than there must be a boot option.
<somerville32> When you're at the boot screen, go into the options menu
<TheMuso> somerville32: Hmm maybe. I was under the impression that it wasn't a user visible option.
<somerville32> You would have to type it in
<somerville32> It might not be documented also
<somerville32> I guess you'll have to look at the logs
<seb128__> superm1: could you describe the changes you merge in the changelog?
<somerville32> (or ask someone else)
<seb128__> superm1: the libgnomesu one has no description
<evand> TheMuso: http://www.mail-archive.com/ubuntu-devel-discuss@lists.ubuntu.com/msg01943.html
<evand> so only-ubiquity, provided you're not using preseeding
<evand> on the kernel cmdline
<StevenK> Riddell: Ah. Sorry, I've been around and about. https://wiki.ubuntu.com/HardyAboutUbuntu
<Riddell> StevenK: ok, KDE sentence added
<Riddell> StevenK: give me a ping when the gtk version gets to a state where it's worth starting on the qt version
<TheMuso> evand: Thank you very much.
<evand> TheMuso: anytime
<StevenK> Riddell: Sure. At this point I want to get the spec approved.
<siretart> StevenK: thanks for your work on bug #139635
<ubotu> Launchpad bug 139635 in libgpg-error "[cryptsetup] library dependency in /sbin/cryptsetup" [Undecided,In progress] https://launchpad.net/bugs/139635
<siretart> StevenK: do you take the SRU uploads over as well?
<StevenK> siretart: I did not. I need to poke more and get gnutls13 to actually build
<StevenK> pitti: Can you point me at the perl package that wants to pull yada into main?
<pitti> StevenK: btw, did you see that gnutls13 FTBFSed? It can't find the .la file (looking in /lib)
<siretart> StevenK: ok, but do you intend to?
<pitti> StevenK: sure, it's in component-mismatches.txt
<StevenK> pitti: I did. I wanted to talk to you about it.
<gicmo> hey hey pitti
<pitti> StevenK: I asked Keybuk, and I think we should just move everything to /lib (including the .la)
<StevenK> pitti: Ah. I will look
<pitti> StevenK: libbsd-resource-perl
<gicmo> so what script do people use for the keysigning?
<pitti> StevenK: pulled in by libapache2-mod-perl2
<gicmo> I tried to one from keysigning-party fails with some strange error inside of Mailer.pm
<pitti> StevenK: I'm currently doing some archive cleanup (just killed binary NEW, yay), I'll look into gpg-erro later if you want me to
<StevenK> pitti: Please. I'm happy to fix it, I just need a hint.
<pitti> StevenK: I think moving everything to /lib should be fine
<pitti> StevenK: autoconf doesn't really support the splitting, and libtool just keeps getting it wrong, so let's stop trying
<StevenK> pitti: Sure, I will reupload both of them.
<pitti> StevenK: . o O {base-files.preinst: ln -s / /usr }
<pitti> StevenK: both?
<pitti> StevenK: you mean libgcrypt needs the same treatment?
<StevenK> pitti: I suspect it does.
<StevenK> pitti: Since it has the same thing.
<pitti> StevenK: doing NBS now FYI, to get rid of some noise in hardy_outdate
<pitti> StevenK: ah, no, need to wait for buildds first
<slangasek> keescook: did you give me a fingerprint copy when you flashed me your ID?  because I think I took it out in the hotel in Cambridge for signing, and with due care left it sitting on the desk when I checked out
<keescook> slangasek: hehe
<keescook> slangasek: I may be out of biz cards.
<slangasek> oh, was it on a business card?
<fabbione> slangasek: did Principessa arrived home?
<slangasek> if it was a business card, there's still a chance that it's in my possession and I just need to sort out where
<slangasek> fabbione: I just got an SMS from her saying that she's landed in PDX
<fabbione> slangasek: ok cool
<YokoZar> keescook: that reminds me, I just signed your key
<keescook> YokoZar: excellent!  thanks.  :)
<YokoZar> I think I gave out about 25 cards, but I only got 5 signatures or so so far
<keescook> YokoZar: I hope one of those was from me.  :)
<keescook> I've gotten 1 so far.  :P
<YokoZar> Thunderbird w/ enigmail by far provides the best interface to this.  Just search for key by their email address, right click sign key, verify the fingerprint, then I can upload it myself (or mail it to them)
<YokoZar> It's even better than seahorse
 * keescook is a caff (signing-party) junkie
<Mithrandir> keescook: we've signed beers^Wkeys, haven't we?
<keescook> Mithrandir: I thought so, but I think you never sent mine back to me -- let me double-check
<mdke> can you securely sign a beer?
<Mithrandir> mdke: sure.
<keescook> Mithrandir: yeah, no sig from you in my keyring.
<cyberix> "a beer" is quite short.
<cyberix> Are you sure it cannot be used in a security attack
<Mithrandir> keescook: hm, weird.  I have it in my signing.input file.
<mdke> Mithrandir: I suppose if it's your 4th beer, it's not so trusted
<Mithrandir> mdke: true dat
<slangasek> surely that depends on your beer metric and whether you're in the Soberly Connected Component
<superm1_> pitti, ping
<pitti> superm1_: pong
<keescook> Mithrandir: do you want to see my passport again?
<superm1_> hey pitti i just got some bugmail with comments on the mythtv sru
<gicmo> seb128: ALTER!
<seb128> gicmo: Alter!!!
<gicmo> mvo: some for you
<gicmo> same
<seb128> how is that going?
<gicmo> ;-)
<gicmo> pretty good
<gicmo> jetlag though
<mvo> gicmo: hello! good to see you :)
<gicmo> indeed!
<mvo> gicmo: who was your presentation?
<gicmo> how is it going?
<mvo> how
<mvo> even :)
<superm1_> pitti, i had thought the archive admin's role in this was just to check version numbers, and then let people actually do the testing once it's built
<gicmo> mvo: it IS tomorrow!
<gicmo> ;-)
<superm1_> since motu-sru doesn't exist anymore
<Riddell> mvo: http://isv-image.ubuntu.com/vmware/
<Mithrandir> keescook: given that I have your fingerprint here, no
<keescook> Mithrandir: okay, cool.
<Mithrandir> if it's not 9FA3 C49C 23C9 D1BC 2E30  1975 1FFF 4BA9 1706 3E6D
<Mithrandir> you need to tell me
<keescook> looks good to me.
<Mithrandir> keescook: sent
 * keescook hugs Mithrandir (and slangasek)
<keescook> now lets see if anyone actually gets through to outflux.net.  :P  yay for my insano anti-spam filters.
<Mithrandir> 2007-11-05 22:33:56 1Ip9Zu-0006Es-7D <= tfheen@err.no H=(thosu.err.no) [75.144.175.202] P
<Mithrandir> =esmtps X=TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32 S=9525 id=20071105213401.B35D457989@thosu.e
<Mithrandir> rr.no
<Mithrandir> 2007-11-05 22:34:22 1Ip9Zu-0006Es-7D => kees@outflux.net R=dnslookup T=remote_smtp H=smtp
<Mithrandir> .outflux.net [69.93.193.226] X=TLS-1.0:RSA_AES_256_CBC_SHA1:32
<Mithrandir> 2007-11-05 22:34:22 1Ip9Zu-0006Es-7D Completed
<Mithrandir> seems like it
<keescook> sweet
<keescook> now slangasek will poke me in the eye for reject email from dynamic IPs.  :P
<keescook> *rejecting
<Mithrandir> why would he send from a dynamic IP?
<slangasek> haha
<slangasek> I won't poke you in the eye, I'll just note that I sent the mails using caff and didn't otherwise note down your key fingerprint, so you might have trouble getting my sig :)
<pitti> bdmurray: https://wiki.ubuntu.com/StableReleaseUpdates?action=diff -> ok?
<keescook> slangasek: yup.  but if you felt like hand-sending the .caff/keys/2007-11-05/1FFF4BA917063E6D.key.*outflux*.asc file to me, I wouldn't mind.  :)
<slangasek> heh :)
<Mithrandir> or just set up a proper MTA on your laptop
<slangasek> I have a proper MTA on my laptop kthx
<Mithrandir> make it use freerelay.err.no or a similar service, then?
<slangasek> what, and play into the hands of email terrists like kees?
<keescook> I knew I wouldn't avoid the flames for long.  ;)
 * keescook suspends
<Keybuk> has anyone contacted our FreeNode contact about our shared IP?
<gicmo> hey Keybuk
<Keybuk> hey
<superm1_> slangasek, are you still here?
<IntuitiveNipple> Any ideas why kdelib's libkmid MidiPlayer component only plays the first note of a MIDI file (called from kmid) on x86_64 ?
<unggnu> Woran kann es liegen, dass dvdauthor und ffmpeg > /dev/null ignorieren?
<unggnu> 2> geht, aber eigetnlich sind as keine Fehler
<unggnu> und die Fehler mÃ¶chte ich ja gerade haben
<tormod> unggnu: wrong channel? :)
<unggnu> Warst Du da?
<unggnu> I am sorry
<unggnu> too late
<unggnu> ciao
#ubuntu-devel 2007-11-06
<somerville32> bye
<slangasek> superm1_: no
<superm1_> slangasek, i forget what exactly i messaged as i pinged you before.
<superm1_> slangasek, it was probably related to that mythtv sru
<slangasek> superm1_: you asked me if I was still here
<superm1_> slangasek, ah okay
<superm1_> slangasek, well i was going to ask you about the sru then when you responded :)
<slangasek> and if it's about the sru, I'm really probably not here until tomorrow morning when I've had a chance to rest some. :)
<superm1_> slangasek, sounds good :)
<superm1_> slangasek, enjoy your evening
<somerville32> Hobbsee, I need some love.
<somerville32> Bug 160314
<ubotu> Launchpad bug 160314 in xfce4-session "xfce4-session: merge new Debian version" [Undecided,New] https://launchpad.net/bugs/160314
<Hobbsee> somerville32: oh?
<somerville32> :)
<somerville32> Hobbsee, Think you can help? :]
<Hobbsee> somerville32: nope :)
<somerville32> Hobbsee, Why not? : *(
<Hobbsee> because i'm doing uni stuff, and i'm only on irc to speak to some people
<somerville32> moogles.
<BlaenkDenum> hey I'm wondering where I can propose something regarding the IRC channel, would the forums be a good place?
<BlaenkDenum> I figured launchpad but then that's mainly for distribution problems I figure
<Burgundavia> BlaenkDenum: irc channels are covered by the IRC council
<Burgundavia> what is your issue?
<PriceChild> BlaenkDenum, "the"... which channel?
<BlaenkDenum> maybe the most popular, #ubuntu
<BlaenkDenum> Burgundavia: oh haha there's an IRC council, where can I contact them?
<Burgundavia> BlaenkDenum: what is your issue?
<BlaenkDenum> Alright, well it's not really an issue I was just wondering if it's something to think about.
<Burgundavia> instead of being obtuse, you could tell us what is on your mind
<Hobbsee> #ubuntu-irc
<Burgundavia> then we can help you a lot better
<Hobbsee> Burgundavia: this still isnt the correct place :)
<BlaenkDenum> I will, hold on I'm typing heh
<BlaenkDenum> okay I'll go to #ubuntu-irc
<PriceChild> Hobbsee, #ubuntu-ops you mean? ;)
<Hobbsee> BlaenkDenum: use #ubuntu-irc.  most of the develpoers are not ops.
<Hobbsee> PriceChild: er, yes, that.
<Burgundavia> Hobbsee: I have no idea what exactly he is saying yet
<Hobbsee> Burgundavia: if ti's regarding the irc channel...
<Burgundavia> Hobbsee: and he mentioned LP and the forums, thus I am still confused
<Hobbsee> Burgundavia: as places to put his proposals, yeah.
 * Hobbsee waits to see what it is
<somerville32> Carefully BlaenkDenum, they might eat you alive :P
<viviersf> hi guys, does ubiquity copy files from the squashfs image only or the squash+unionfs ?
<Mithrandir> viviersf: the squashfs, then a handpicked selection of items from the unionfs
<Hobbsee> Mithrandir!
<Mithrandir> hello little crazy Australian!
<Hobbsee> hiya Mithrandir!
 * Hobbsee is sad little crazy
<Hobbsee> Australian
<Mithrandir> why are you sad?
<Hobbsee> my boss is leaving :(
 * Hobbsee notes that her underlings are *all* sad, and are saying she isnt allowed to go :P
<Mithrandir> heh
 * Mithrandir ruffles Hobbsee 
 * Hobbsee hugs Mithrandir
<Hobbsee> so we probably get a terror person, next
<viviersf> Mithrandir, there a place one can define things to be copied form unionfs ?
<Mithrandir> viviersf: you can set up a hook, sure.  /usr/lib/ubiquity/target-config contains a list of hooks
<viviersf> Mithrandir, heh okay, so i just put a scipt in that copies the stuff
<Mithrandir> viviersf: that ought to work, yes.  You might want to look at the bits there already to work out how it all fits together.
<viviersf> Mithrandir, cool thanks
<viviersf> Mithrandir, was this changed for gutsy ? in feisty it copied form all unionfs ?
<Mithrandir> no, it's been the same way since dapper
<viviersf> Mithrandir, in feisty i used to update packages from the live cd and install with the new versions. In gutsy it seems to revert everything
<Hobbsee> morning cjwatson_
<Mithrandir> viviersf: if you got that, I think you would have dreamed it.
<viviersf> Mithrandir, haha no i didnt. Maby there was a bug :P
<Mithrandir> viviersf: somehow, I think we would have noticed.  Just copying the unionfs would break a whole lot of things.
<viviersf> Mithrandir, i dunno it worked. Its weird then
<norsetto> stevenk: how is the battle against libtool going?
<StevenK> norsetto: I will have my revenge!
<Hobbsee> good luck with that.  will you succeed?
<norsetto> Hobbsee: the official score is libbtool 1 - stevenk 0 (see bug 139635 last comment)
<ubotu> Launchpad bug 139635 in libgpg-error "[cryptsetup] library dependency in /sbin/cryptsetup" [Undecided,In progress] https://launchpad.net/bugs/139635
<Hobbsee> norsetto: pity.
<manchicken> Hobbsee: Howdy :)
<Hobbsee> hiya manchicken!
<manchicken> How goes it/
<Hobbsee> manchicken: it goes, gnome style :)
<bddebian> Heya
<tekteen> anyone here know what packages I can take off of the alt install cd for kubuntu? I need to make room.
<BUGabundo> hya
<tekteen> hi
<BUGabundo> today I've add Hardy reps
<BUGabundo> did a few (really few packages) updates
<BUGabundo> found a little prob
<BUGabundo> SoftwarePropertiesGtk didn't work! should I report it on LP?
<warp10> Hi all!
<BUGabundo> is Michael Vogt here?
<Hobbsee> BUGabundo: you want #ubuntu+1
<Hobbsee> and no, he's not
<BUGabundo> thanks Hobbsee
<highvoltage> Was anyone here at the Gobuntu sessions at UDS Boston?
<popey> i was at one of them
<fabbione> FYI: we are going to disable automatic package ACCEPT in launchpad for a few hours
<Hobbsee> oh noes!
<Mithrandir> fabbione_: as in, disable build-from-unpublished-source?
<fabbione_> Mithrandir: not sure.. ask pitti
<fabbione_> Mithrandir: we need to import the partner archive in LP
<Mithrandir> ah
<Mithrandir> pitti: ^^; are you disabling the publisher completely or just the build-unpublished-source bits?
<pitti_> Mithrandir: completely, just for safety
<Mithrandir> ok
<pitti_> Mithrandir: b-f-a stays enabled for now
<Riddell> carlos: spooky japanese https://translations.edge.launchpad.net/ubuntu/gutsy/+source/kde-guidance/+pots/guidance/nb/+translate
<carlos> Riddell: https://bugs.edge.launchpad.net/rosetta/+bug/133315
<ubotu> Launchpad bug 133315 in rosetta "at least, four wrong language imports for gutsy" [High,Confirmed]
<StevenK> pitti: libbsd-resource-perl should be okay to be promoted, it built everywhere
<pitti> StevenK: it still needs at least a shallow review for MIR
<StevenK> pitti: Yeah, okay, but that's you or me doing that?
<StevenK> pitti: All I was planning on doing was crowbarring yada off of it
 * StevenK beats bloody dexter with the crowbar
<warp10> Hi all!
<Joe_CoT> hey, the gutsy-security repo has an invalid signature. Has all morning. Anyone to report it to?
<jdong> Joe_CoT: really?
<jdong> I just applied security updates 1.5hrs ago
<Joe_CoT> jdong, yeah.
<Joe_CoT> W: GPG error: http://security.ubuntu.com gutsy-security Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
 * jdong runs a 2nd update
<jdong> no error on apt-get update
<Joe_CoT> really? hmm
<jdong> sure you don't have an intercepting proxy or something upstream?
<Kmos> i'm applying them without problem..
<Kmos> Joe_CoT: isn't a problem of your mirror?
<jdong> Kmos: it shows sec.ubuntu.com
<jdong> Kmos: somehow the traffic is getting corrupted on the way over to him....
<jdong> odd to say the least
<Kmos> ah yeah =) is direct
<pitti> StevenK: ah, libbsd-r-p package looks so *delightfully* easy now
<pitti> StevenK: mainified, thanks
<pitti> StevenK: on a related note, gnutls13 FTBFSed again, probably because of the libtool-crackification in libgcrypt11
<StevenK> pitti: Thank you for the compliment. :-)
<StevenK> pitti: I saw the FTBFS, I wanted to ask you about it. Shall I just fix and upload gcrypt11 and then we give back gnutls13 once more with feeling?
<Chipzz> StevenK: weren't there plans to eliminate .la files from the packages several releases back?
<slangasek> it's an uphill battle
<Chipzz> looks more like a battle that never got out of the planning stage to me really ;)
<StevenK> It's hard to kill .la files
<StevenK> Since libtool is a pile of crap
<geser> and some KDE apps need them
<tekteen> can someone help me. My preseed file is not working. It does not seem to be answering any questions. I pasted it at http://paste.ubuntu-nl.org/43569/.
<soren> tekteen: please don't ask questions and run away before you've given people a chance to answer. kthxbye
<slangasek> soren: why?
 * slangasek runs away!
 * soren grumbles
 * soren shakes his fist at slangasek
 * popey waves at soren 
<soren> o/
<slangasek> mathiaz: http://lists.alioth.debian.org/mailman/listinfo/pkg-samba-maint
<slangasek> bdmurray: are the Portland Cabal going to go in on Adilson's planning for airport transit?
<StevenK> Heh heh. Portland Cabal
<fabbione> FYI: uploads to LP will be processed automatically from now
<bdmurray> slangasek: I've considered it
<seb128> keescook: the glib copy is pcre 7.2
<seb128> keescook: the changelog has that
<seb128>         * glib/gregex.c: define PCRE_ERROR_NULLWSLIMIT if it's not defined by
<seb128>         PCRE, has PCRE 7.3 removed this definition. (#475474)
<seb128> not sure if that's a compatibility breakage or something not exported
<slangasek> fabbione: hrm, what uploads to LP?
<fabbione> slangasek: all of them.. we had the publisher in manual for a bit
<fabbione> it's all good now
<slangasek> oh
<StevenK> pitti: Are you busy?
<pitti> StevenK: currently typing a mail, but not particularly muc
<pitti> h
<StevenK> pitti: Shall I come find you and we can bitch at each other about gnutls and libtool?
<slangasek> ugh, does gnutls still have .las?
<StevenK> slangasek: It's worse than that. All three of us can talk about it if you want
<slangasek> ok
<StevenK> So as soon as pitti tells us where he is hiding, both of us can find him.
<pitti> StevenK: main room
<StevenK> Oh, duh
<pitti> bdmurray: ok, mail is away
<StevenK> I'm right behind you
<StevenK> pitti: ^
<StevenK> slangasek: Come find us?
<slangasek> StevenK: in a meeting
<StevenK> slangasek: Ahh. pitti and I will discuss it.
<slangasek> bdmurray: we probably need to get a plan together pretty soon, lest all the vehicles in town get filled up before Saturday? :)
<broonie> c
<broonie> Gah.
<fabbione> is it normal that a stat(file, &sb) on a symlink that points to a dir will have S_ISLNK(sb.st_mode) set to FALSE and S_ISDIR set to TRUE?
<zul> fabbione: gah?
<fabbione> zul: stat(2)
<zul> fabbione: ah..
<fabbione> zul: make a symlink pointing to a dir
<fabbione> stat it
<fabbione> check what it is via S_IS macros
<fabbione> it tells me that it is a dir and not a symlink
<fabbione> might be a bug or a feature.. just need to understand
<lamego> fabbione, man fstat
<fabbione> lamego: that's the same man page as stat..
<lamego>        lstat() is identical to stat(), except that if path is a symbolic link,
<lamego>        then the link itself is stat-ed, not the file that it refers to.
<lamego> no it is not
<lamego> it has a clear statement regarding how slinks are treated :)
<fabbione> lamego: read carefully what i said... man stat = man fstat
<lamego> lstat() unlike stat() identifies links
<fabbione> ok perfect
<lamego> ok, whatever, it answers to your question :)
<fabbione> that is not fstat.. i don't need that
<lamego> fabbione, stat follows links, as per the developers man page
<liw> violent agreement detected
<fabbione> lamego: yeps right.. i missed lstat
<fabbione> liw: no.. he is right for lstat.. we agree on that.
<fabbione> liw: i don't agree that the man pages are different :)
<lamego> you are correct
<lamego> :P
<fabbione> lamego: thanks tho
<fabbione> :)
<Riddell> bdmurray: bug 155784
<ubotu> Launchpad bug 155784 in qt4-x11 "[gutsy] /usr/lib/libssl.so missing" [Undecided,In progress] https://launchpad.net/bugs/155784
<pitti> seb128: new cdbs uploaded, works with libgcrypt11
<warp10> pitti: Hi! Did you received my email?
<seb128> pitti: you rock! ;-)
<pitti> warp10: no, seems I didn't; which mail you mean?
<warp10> pitti: I sent it 5 days ago, November 1st
<norsetto> pitti: if I ask nicely, would you look at the fix for bug 155498 which is in gutsy-proposed since a month?
<ubotu> Launchpad bug 155498 in rutilt "rutilt 0.15-0ubuntu5 crashes while applying a profile" [Medium,Confirmed] https://launchpad.net/bugs/155498
<pitti> norsetto: oh, in fact I looked at it yesterday, but there was something about it I didn't like
<pitti> norsetto: give me a minute
<norsetto> pitti: sure
<pitti> norsetto: oh, right; it doesn't have approval from motu-sru
<pitti> and it has a whole lot of changes in it, which don't look critical
<pitti> so I want motu-sru to ack it
<pitti> norsetto: also, it doesn't have a changelog which is useful
<pitti> even less so for users, so it does not tell anything about the impact and severity
<norsetto> pitti: ok, for the first point, that was motu-uvf at the time
<pitti> oh, eww, I didn't know that
<pitti> so that's replaced by motu-uvf team?
<norsetto> pitti: but its ok, I subscribe motu-sru then
<pitti> norsetto: no, please don't
<pitti> norsetto: LP says that motu-sru is obsolete
<pitti> norsetto: hang on a minute
<pitti> norsetto: hm, seems that the MOTU SRU process recently changed to not actually require acks
<pitti> norsetto: so, sorry, it's not your fault
<pitti> but I don't like this at all
<norsetto> pitti: I will make it only for that bug if necessary but its a pity to miss the other fixes, they really enhance the package
<pitti> norsetto: but every change bears the risk of breaking it for current users
<pitti> norsetto: only "severe regressions" or "loss of data"
<norsetto> pitti: just between you and me, I'm using it since a month
<pitti> norsetto: btw, with "I don't like this at all" I didn't refer to your patch, but to the process change of not needing acks from motu-sru any more
<norsetto> pitti: sure :-)
<pitti> the current process basically makes stable-universe fair game for breaking
<StevenK> The point was more to trust MOTUs to make calls about what to fix.
<pitti> well, the current mythtv in gutsy-proposed unapproved is a prime example of how *not* to do an SRU
<StevenK> Who uploaded it?
<pitti> "Rewrite the entire tv backend driver because it's better"
<StevenK> Oh geez
<pitti> and once we go down that route of never ack'ing uploads, I'm also afraid that too much effort will be spent fixing minor things in stables
<pitti> which is really better spent on improving the current dev release
<pitti> norsetto: ok, I let this through based on the fact that it matches the currnet policy
<pitti> but I'll initiate a change to that policy
<norsetto> pitti: thanks, I really appreciate it
<norsetto> norsetto hugs pitti
 * pitti hugs norsetto
 * norsetto hugs stevenk too (he is in a hugging mood, so there)
<pitti> seb128: ok, we have fixed prepared for gnutls&friends
<pitti> seb128: however, in the long run we need to convince Debian about this concept, or we need to use clean-la.mk by default in cdbs (right now it isn't)
<pitti> seb128: I'm actually pondering doing the latter
<seb128> pitti: well, clean-la comes from Debian, so there is already people convinced there ;-)
<seb128> but right, should be discussed there
<pitti> only amongst the gnome team, I guess
<seb128> I think Keybuk is not that happy with that and consider .la useful
<pitti> what for?
<seb128> static building apparently
<Keybuk> so, here's a theory for you ...
<pitti> they just cause extra useless dependencies and other trouble
<slangasek> seb128: the answer to that is to make sure a .pc file is provided when the .la is removed
<Keybuk> if you don't want .la files
<Keybuk> why do you compile with libtool at all?
<seb128> but I'm not sure that's true on linux nowadays
<Keybuk> why not just use gcc?
<pitti> Keybuk: because upstream build systems do?
<Keybuk> upstream install the .la file
<pitti> but TBH I think that dh_shlibdeps does a much better job
<slangasek> no, libtool installs the .la file
<seb128> Keybuk: libtool install those
<seb128> that's a side effect
<Keybuk> no, it's the primary effect
<seb128> upstream just wants to build their libs
<Keybuk> the side effect is the installation of .so
<pitti> and I'm not really concerned about having it working on a 20 year old VAX
<Keybuk> libtool uses and manipulates .la files
<slangasek> installing the .la file is an implementation detail of a poor implementation
<Keybuk> so don't use the poor implementation
<slangasek> don't have that choice
<Keybuk> if you're using libtool, you should ship its .la files
<slangasek> why?
<pitti> right, we just hack around it ATM
<Keybuk> if you don't want .la files, don't use libtool
<slangasek> they're useless if you have a .pc file
<Keybuk> it's easy not to
<seb128> Keybuk: that's not true
<seb128> what is the issue with not shipping those?
<Keybuk> it breaks static linking
<slangasek> seb128: none if you provide a .pc file instead
<Keybuk> slangasek: not true
<slangasek> .pc isn't broken; .la is
<Keybuk> even with .pc files you need .la for static linking
<slangasek> no, you don't.
<Keybuk> yes, you do
<slangasek> not if the .pc file isn't broken
<Keybuk> the .pc file doesn't list the list of dependencies for the shared library
<Keybuk> because if it did, you'd be removing those too
<Keybuk> you need that list of dependencies for static linking
<Keybuk> we fixed libtool years ago to ignore that list for dynamic linking
<slangasek> er, no, you just need a version of pkg-config that supports the --static option
<Keybuk> maybe the current Debian maintainer reverted my patches *shrug*
<slangasek> Keybuk: except that libtool *still* has to recurse the actual .la files at build time
<Chipzz> Keybuk: static linking tends to break for complex programs with lots of libs anyway
<slangasek> so when the dependencies of your build-dependencies change, .la shows its true evil
<Keybuk> slangasek: I have no issue with replacing libtool with something else
<pitti> . o O { if that breaks static linking, so much the better :-P }
<Keybuk> it's not difficult
<seb128> Keybuk: that's not something we want to do at a distro level
<slangasek> and you told me that aspect of .la behavior couldn't be fixed without a compatibility break
<Chipzz> back in the gnome 1.4 days I tried linking a program using orbit statically; broke horribly
<Keybuk> Chipzz: yet we still ship .a files
<Keybuk> seb128: we overwrite config.guess and config.sub for every package
<Keybuk> adding a third file to that list seems trivial
<slangasek> the only thing installation of .la files is legitimately needed for on Linux is static linking; there is a way to support static linking via .pc files without the side-effects of .la files. QED
<Keybuk> slangasek: .pc has different problems ;)
<Keybuk> the main one being they can only be installed in one place
<Keybuk> so you can't (easily) parallel install different version
<Keybuk> ...unless that's fixed, I'm not up to date
<seb128> Keybuk: how do other distros which don't ship .la do? that's not possible to do static linking on redhat?
<Keybuk> seb128: ever tried static linking gtk? :p
<pitti> Keybuk: but that's equally true of .la? /lib/libfoo.la doesn't work
<Keybuk> *boom*
<Keybuk> pitti: yes it does
<Keybuk> assuming you compiled it for /lib
<Chipzz> 23:01 < Keybuk> if you don't want .la files 23:01 < Keybuk> why do you compile with libtool at all? >> Several reasons actually, the prime one being "I didn't decide this as I didn't write the thing"
<Keybuk> one of the usual complaints about libtool is precisely because it *does* support .la files by specific paths
<Keybuk> Chipzz: the upstream maintainer almost certainly didn't decide either
<Keybuk> most people only use libtool because automake demands it for shared libraries
<Chipzz> second one: because it helps on other platforms than linux
<pitti> Keybuk: we did, but libtool doesn't find them in /libs; we tried and it failed
<Keybuk> Chipzz: we're Ubuntu *Linux*
<Chipzz> Keybuk: I'm sure upstream cares about us being ubuntu linux ;)
<Keybuk> like I said, upstream probably doesn't care about libtool
<Keybuk> they got it as a side-effect of automake (which makes writing make files easier)
<seb128> right
<seb128> what upstream actually cares about is building and installing .so
<Keybuk> yeah, and that's easy
<Keybuk> just replace ltmain.sh with something that just calls gcc with the same arguments
<Chipzz> Keybuk: anyway I think there's a difference between libtool being evil and .la files being evil
<Keybuk> Chipzz: .la files are part and parcel about what libtool *does*
<Chipzz> I'm not convinced of the former, but rather of the latter
<Chipzz> Keybuk: libtool works fine without .la files
<Keybuk> not true
<Keybuk> I'm afraid
<Keybuk> it works only for the commonest case
<Keybuk> it's really a bit thick without them
<Chipzz> try rm /usr/lib/*la and build something using libtool; it still builds fine
<Keybuk> which is why I've continually resisted removing them
<Keybuk> I *know* the bugs
<Keybuk> actually
<Keybuk> it doesn't
<Keybuk> usual test
<Keybuk> rm /usr/lib/*.la
<Keybuk> have a package with a convenience library that links to something in /usr/lib
<seb128> do you have concrete example of things which doesn't work without those for people who don't know the bugs?
<Keybuk> and an app that links to it
<Keybuk> app will fail to link
<Keybuk> (convenience libraries are arguably bugs in themselves, but people love them)
<seb128> what do you call "a convenience library"?
<Keybuk> seb128: info libtool search for "convenience library"
<seb128> rm /usr/lib/*.la is the usual way jhbuild users get GNOME to build
<Keybuk> what most people use when they spread code amongst multiple sub-directories in their package
<Keybuk> yeah
<Keybuk> GNOME are particularly well-behaved
<Keybuk> it certainly never affects them
<Keybuk> but it affects a random bunch of other crap
<norsetto> pitti: err, I owe you an apology for bug 155431 ... can you pls. un-subscribe ubuntu-archive. Sorry :-(
<Keybuk> I honestly can't remember, because I stopped seriously caring about this years ago ;)
<ubotu> Launchpad bug 155431 in apr "documentation in /usr/share/doc/libapr1-dev missing" [Low,Confirmed] https://launchpad.net/bugs/155431
<seb128> let's fix those then?
<Keybuk> I came to the conclusion that the build chain support was utterly broken
<Keybuk> and nobody had any desire to properly fix it
<pitti> so, we could probably fix libgpg-error to ship the shlib in /lib *and* have a working .la file, but autoconf and libtool make this exceptionally hard
<pitti> it seems that they actively make it hard to ship libs in /lib
<Keybuk> I fully support replacing ltmain.sh with a very small shell script
<Keybuk> so .la files cease to be a problem at all
<Chipzz> Keybuk: one of the problems of .la files (which I'm sure you're aware of) is it totally defies any attempts of using -Wl,--as-needed
<pitti> Keybuk: sounds good to me
<seb128> I don't know enough about the build system to have an opinion on that
<Keybuk> Chipzz: patched in Debian years ago
<seb128> but if you are comfortable doing a such change
<Keybuk> (when I maintained libtool)
<pitti> norsetto: don't worry
<Chipzz> Keybuk: yes, and if upstream doesn't use debians libtool and rolls a tarball you're still screwed
<Keybuk> -- random tangent -- does anyone know how you tell OpenOffice what the individual text boxes on a slide master *mean* ?
<Chipzz> (or you need to run relibtoolize)
<Keybuk> Chipzz: autoreconf
<pitti> (which tend to break more often than not)
<Chipzz> autoreconf tends to be a chore to run, and it produces big patches which have to be reviewed
<Keybuk> it only produces big patches if the upstream is done wrong
<Chipzz> or with an older/different version than we use
<seb128> Chipzz: you can use the same version than upstream, just look to the Makefile.in
<Keybuk> hell
<Keybuk> just running "make" will always use the same version as upstream
<Keybuk> (except where Debian deliberately change the upstream package to prevent all that useful functionality from working -- yay working around perceived problems)
<seb128> Keybuk: usually the libtoolize patch have an aclocal and an autoconf call
<seb128> anyway what do we argue about now?
<Chipzz> Keybuk: we currently have autoconf2.13; what happens if for example upstream tarball was rolled with autoconf 2.12 ?
<Keybuk> aclocal will just replace a file in m4
<seb128> Chipzz: let's stop there
<Keybuk> like I said
<Keybuk> I don't really care about any of this
<seb128> most of us know the issues with the current system
<Keybuk> it's all broken, and made worse by people doing workarounds rather than fixing the system
<Keybuk> do what you want ;)
<Keybuk> but don't complain to me when you break it <g>
<seb128> fair enough
<slangasek> Keybuk: a convenience library referencing the .la files in /usr/lib is precisely a symptom of *why* we shouldn't ship the .la files :)
<Chipzz> seb128: that actually was a genuine question; but whatever ;)
<slangasek> if they weren't present when the convenience lib was built, the application will also link just fine
<Keybuk> slangasek: no, it won't
<slangasek> huh?
<slangasek> if there was no .la file in /usr/lib, the convenience lib's .la will only reference the libraries, not the non-existent .la files
<Keybuk> not true
<Keybuk> but I can't be arsed to argue anymore
<slangasek> you're claiming that the convenience lib's .la file *will* reference .la files that never existed? :P
<Keybuk> no
<slangasek> then what? you're saying that you can't have a convenience lib .la without having .la files for all the underlying libs?
<gaspa> seb128: ping
<gaspa> are you working on pygoocanvas? i should work with it, so i can take a look for the merge/sync of it.
<seb128> gaspa: no, I'm not, you are welcome do to the merging, feel free to ping me if you need sponsoring then
<gaspa> seb128: ok, thank you ;D
<seb128> gaspa: no problem
<LaserJock> seb128: are you generally ok with people merging gnome packages?
<LaserJock> seb128: or are there ones that you need to handle yourself
<seb128> LaserJock: https://wiki.ubuntu.com/DesktopTeam/TODO
<seb128> LaserJock: feel free to claim any update or merge there
<seb128> LaserJock: just put a link to the .dsc or to a bug with the informations
#ubuntu-devel 2007-11-07
<Hobbsee> morning all
<ajmitch> hi
<jdong> is there anything  anti-HIGgy about if gnome-screensaver reported failed unlock via libnotify bubble?
<jdong> I mean, there's already a mechanism for g-s to pop up libnotify (for leaving message) -- I'd like to know how many times, and at what time, people tried and failed to unlock my screen.
<jdong> would that be a crackpot feature request to file, or does it sound reasonable?
<somerville32> I don't like how it is now. I think there should be a widget to launch an application to view the events.
<somerville32> And there should be a field to put your name in for the message.
<somerville32> Maybe even integrate it with ldap and a network messaging mechanism.
<jdong> somerville32: that would be cool too :)
<jdong> somerville32: IMO there also needs an event viewer for update-manager post-update messages
 * somerville32 nods.
<jdong> somerville32: some of the messages shown, it's unreasonable to expect the user to remember them 2 weeks later
<somerville32> I agree completely.
<jdong> i.e. xserver-xgl tells the user to touch ~/something/disable to disable XGl for the user
<jdong> I mean, how the heck is the user supposed to remember that? Pull out a sticky note?
<somerville32> hehe
<jdong> :)
<somerville32> Maybe Tomboy? :P
<jdong> haha, that'd be a good april fools feature addition
<jdong> all libnotify events get saved to tomboy
<jdong> and you have to use tracker to find them.
<somerville32> lol
<somerville32> And we'll have Microsft Bob giving hints and suggestions.
<johanbr> jdong: Seriously, I think a notification caching applet would be a nice thing to have.
<jdong> johanbr: yeah
<jdong> johanbr: IMO ideally the system log viewer applet should be extended to being able to aggregate per-user events into a per-user type log too
 * jdong wonders if a dbus/hal powered syslog clone would be a good idea or satire of dbus :D
<Hobbsee> uh oh.  volume keys broke
<somerville32> jdong: Why not just create a log that the current system log view can understand?
<somerville32> hmm... firefox needs to die.
<wasabi> So, sudo thinks my timestamp is in the future. And it is. Clock got changed.
<wasabi> sudo -v doesn't seem to help
<desrt> open about a dozen gnome-terminals
<desrt> then open one more and sudo -s in that one
<desrt> then blow away the timestamp dir
<Fujitsu> wasabi: sudo -K?
<wasabi> Nope, just tells me it's in teh future
<jdong> somerville32: that looks cool, but it seems like HAL and DBUS are the buzzwords nowadays
<desrt> wasabi; it is the only way
<jdong> somerville32: and everything should be done over it, yada yada yada
<somerville32> lol
<wasabi> What is the only way?
<Fujitsu> jdong: No, we should be doing everything of KDE4's HAL Abstraction Layer.
<Fujitsu> s/of/over/
<jdong> Fujitsu: we might need to abstract that too just in case AmaroK2's abstraction layer of the KDE4 abstraction layer needs to be fed into a lower abstraction layer :)
<wasabi> Why doesn't sudo just reprompt for the password in this case?
<nicio> what is devel?
<somerville32> nicio, Development
<nicio> so here is not for users but ops? somerville32
<somerville32> nicio, Not ops nor users - people who are interested in developing Ubuntu.
<jdong> nicio: not ops, but developers.
<somerville32> Please see #ubuntu for user support and #ubuntu-ops for operators.
<nicio> erf
<nicio> ok i'm not a devel
<somerville32> :D
<Hobbsee> hm, no, it just buggered the shortcuts.  go figure.
<Hobbsee> why isnt hardy broken yet, dammit?
<Fujitsu> Hobbsee: It is! Think X.
<Hobbsee> Fujitsu: yeah, but that's avoidable.
<somerville32> Hobbsee, Solution: Automatically import the PPAs
<Hobbsee> *snort*
<Hobbsee> no thanks, i'd prefer not to become getdeb, or worse.
<jdong> Hobbsee: ooh! I know! I'll import eclipse 3.3 and new Azureus!
 * somerville32 has 6 (but really 7) uploads to Feisty.
<somerville32> Pretty much half way to making the top 10
<Hobbsee> hah
 * jdong sits impatiently waiting for the buildd to churn out gtkpod.
<somerville32> Where is that motu-science list thinger?
<somerville32> people.ubuntu.com.au or something
 * Hobbsee unsubscribes from more bugmail.
 * Lrrr_ wavez.
 * Lrrr_ is looking for an example of use of the data produced by Germinate.
<Hobbsee> Lrrr_: ubuntu-desktop metapackage would be a good start
<Lrrr_> mm
<Lrrr_> The source package?
<Hobbsee> yes
<Hobbsee> well, binaries too
<Hobbsee> unsure what use the final data is, though - it's just lists of dependancies
<Hobbsee> what are you trying to do?
<Lrrr_> I'm investigating the use of Germinate for a custom, Debian-based, distribution at work.
<Lrrr_> I thought Germinate was cool and all but could not go from that, to a distributable CD, for example.
<Lrrr_> I wondered what to do with the data.
<Hobbsee> ah right, so you want to look at the seeds as well
<Lrrr_> I've seen the Ubuntu seeds.  Made my own example.
<Hobbsee> start with the seeds, run the update script in ubuntu-meta, and look at the output :)
<Lrrr_> I see.  It's used to generate the list of package included in the respective Ubuntu & derivatives metapackages.
<Hobbsee> yup
<Lrrr_> what package is used to generate the Ubuntu CDs?
<LaserJock> Lrrr_: like to build the .isos?
<Lrrr_> yes
<LaserJock> check out debian-cd, ubuntu-cdimage, and germinate
 * Lrrr_ jumps for joy! germinate-to-tasks germinate-to-tasks!
<Lrrr_> Now THAT was my missing link.
<Lrrr_> I certainly don't need that much complexity but that will help me understand how to use Germinate data.
<Lrrr_> thanks you LaserJock and Hobbsee
<Hobbsee> no problem
<nicio> can i ask a question to how to install a driver?i dont understand nothing
<Hobbsee> #ubuntu for support.
<nicio> im ban
<Hobbsee> that doesnt make this the place for support, though
<nicio> Hobbsee: it will be quik
<Hobbsee> no, this still isnt the place for support
<nicio> ok
<Hobbsee> try the forums.
<Hobbsee> oh, it's wii.
<Hobbsee> problem solved.
<TheMuso> lol
<Hobbsee> (serial troll)
<Hobbsee> bantracker FTW!
<Hobbsee> hint:  ban evasion is BAD.
<knix> Hobbsee: Ban the entire abo.wanadoo.fr
<knix> It's a bot
<knix> It joins like 20 channels on oftc
<Hobbsee> it's an isp, afaik.
<Hobbsee> abo might not be.
<knix> it has many names =/
<knix> and many isps
<knix> erm
<knix> ips
<Hobbsee> yeah, and people get pissed off when we ban their entire ISP.
<knix> heh
<knix> Have you been getting the same stuff from noos.fr?
<Hobbsee> dont remember :)
<Hobbsee> only the really bad ones get remembered
<Hobbsee> hiya cprov!
<cprov> Hobbsee: hi there
<Hobbsee> cprov: did you revolutionalise launchpad while you were away?
<cprov> Hobbsee: before you complain, let me say that the builders are stopped for maintenance <wink>
<Hobbsee> cprov: wasnt planning on it, i saw the announcement.
<Hobbsee> cprov: i didnt think i complained that much, do i?  :)
<cprov> Hobbsee: well, no ... but I wasn't exactly away
<StevenK> cprov: You ought to have been.
<Hobbsee> oh, i thought you went to all hands
<cprov> Hobbsee: you have been softened by the time
<Hobbsee> cprov: still, there's a nice critical security bug for ppas to fix if you get bored...
<cprov> Hobbsee: I'm at all hands, right. it doesn't mean I'm not coding
<cprov> Hobbsee: We are aware of it
<Hobbsee> cprov: oh.  when i said 'away', i meant away from irc.
<Hobbsee> not away from launchpad
<cprov> Hobbsee: did you miss me that much, it was only away for dinner ...
<Hobbsee> cprov: oh, i thought you hadnt been on for a couple of weeks.
<cprov> Hobbsee: I was hiding
<ajmitch> heh
<Hobbsee> heh.  smart, perahsp
<cprov> Hobbsee: did a light talk about ppa today, I wish you and the other enthusiastic people from motu were here
<Hobbsee> cprov: set up voip? :)
<TheMuso> Certainly would have been nice to hear it.
<Hobbsee> cprov: maybe some day.  but all hands is supposed to be incredibly sekrit, dealing with the plans from the evil canonical empire, isnt it?
<Hobbsee> s/from/of/
<cprov> Hobbsee: nah, there is not voip in AllHands, you might know why.
<Hobbsee> cprov: only for the specific stuff that you actuallyw ant input about.  but then the question is raised - why not do it at UDS?
<cprov> Hobbsee: ehe, not that *evil* ... just megalomaniac at some sense, you know 'world domination' approach
<Hobbsee> cprov: evil and world domination can go hand in hand.
<cprov> Hobbsee: i didn't have time, was attending to class, launchpad-training
<Hobbsee> ah
<cprov> Hobbsee: and usually end up working very well
<Hobbsee> cool :)
<cprov> Hobbsee: it was quite a EOF (on my face) :) I got it, let me do some work to make you life easier.
<Hobbsee> cprov: what kind of work?  as in, what on?
<cprov> Hobbsee: like, fixing the damn builders.
<Hobbsee> cprov: woot!  :D
<Hobbsee> cprov: can you poke people into giving me buildd admin access too, while you're at it/
<cprov> Hobbsee: wot ?
<Hobbsee> s/woot/yay/
<cprov> Hobbsee: seriously ?  do you actually want to help us with it ?
<cprov> Hobbsee: it's dirty.
<Hobbsee> cprov: i would, yes.
<Hobbsee> i'm aware of that, based on how often iv'e seen it break :)
<cprov> Hobbsee: have you talked with tollef and/or colin ?  how they feel about it ?
<Hobbsee> cprov: i only spoke to sabdfl and tollef
<Hobbsee> colin doesnt have a problem with it, but doesnt have the power to do it
<Hobbsee> (although he gave me archive admin, and i've been messing around with that a bit)
<Hobbsee> cprov: sabdfl was fine with it, on the agreement that i didnt "mess with the buildds", which is fair enough
<cprov> Hobbsee: well, I guess that you could start getting access to the LP-actions already available, you are going to add more features to that.
<Hobbsee> cprov: that would be the hope, yes.
<Hobbsee> cprov: they seem to refuse to give me chinstrap access, so i'm stuck using LP UI's - and not doing it, if the LP section is broken.
<cprov> Hobbsee: +1 (dunno, if my opinion really counts on this, but ..)
<Hobbsee> :)
<StevenK> Neat. There's no pending builds at all
<StevenK> (Which is a lie, but anyway)
<ajmitch> I'm sure that'll change
<cprov> Hobbsee: you know what, you could do great if you have access to rescore builds, rescue builders and things like that (already available)
 * TheMuso only has to process uus and be lucky enough to find 100% good debdiffs, and it will change. No argument.
<Hobbsee> cprov: indeed.  which was the stuff i was after :)
<Hobbsee> cprov: i havent been able to find an admin for long enough, that can actually add me to said team.
<ajmitch> then we can all bug Hobbsee to do stuff for us
<cprov> Hobbsee: specially in your TZ (ok, you are a workaholic, which is even better)
<Hobbsee> cprov: obviously,i'd likely take more if offered, but i understand that you cant really offer it
<Hobbsee> cprov: :P
<Hobbsee> ajmitch: no you cant.  no drescher access.
<Hobbsee> that'd be the really useful one
<ajmitch> Hobbsee: not yet, you mean
 * Hobbsee taps fingers, and hums quietly
<ScottK> StevenK: Got a moment for a Debian New Maintainer question?
<cprov> ajmitch: of course, you would prefer to bug her instead of me, he actually stays in the channel, I just show up once a while
<ajmitch> cprov: plus Hobbsee is usually around at a (somewhat) sane time
 * cprov nods
<Hobbsee> cprov: i doubt i can rescue builders - that would require ssh access, surely?
<cprov> Hobbsee: not often
<StevenK> ScottK: Sure
<ScottK> StevenK: I'm about to send in may New Maintainer Application and they want First Name/Last Name.  I go by my middle name.  Should I put the name I actually use or my legal first name (both are on my signed key)?
<bddebian> ScottK: How old are you again?  You should be about retirement age by the time you get DD..
 * bddebian hides
<StevenK> ScottK: You are more well known as Scott, so I would put that - and I can think of another example.
<ScottK> bddebian: Sounds about right.
<ScottK> StevenK: Thanks.  That's what I'll put then.
<ScottK> StevenK: OK.  I've applied.  Now the clock starts ...
<bddebian> ScottK: Do you you already have a sponsor?
<StevenK> ScottK: Who's your advocate, and who signed your key?
<ScottK> bddebian: Advocate, yes.
<slangasek> hmm, all the DDs I know of who go by their middle name also don't use their first name on their key IDs
<ScottK> slangasek: Well it said legal name, so I put the full legal name.
<StevenK> slangasek: I could only think of Overfiend
<bddebian> ScottK: Ah, cool
<ScottK> StevenK: slangasek signed my key (thanks again) and Piotr OÅ¼arowski is going to advocate for me.
<ScottK> AKA POX
<slangasek> StevenK: who also doesn't have the 'G.' listed on his key id, whatever it stands for
<slangasek> (the others I know of are Ryan Murray and Isaac Jones)
<StevenK> slangasek: Indeed. I think he's scared we might not think he's scary with a name like Garry or something.
<bddebian> heh
<StevenK> ScottK: Keep in mind (and slangasek is the same), that my legal name is Steven, but my key says Steve
<ScottK> StevenK: OK.  Well I clicked submit, so it's done for now.
 * ScottK figured more information was better than less.
<slangasek> my legal name isn't Steven, thanks
 * ScottK considers a Debian <-> Ubuntu IRC name association table.
<bddebian> hehe
<manchicken_> Anybody know if the default mysql-server package is compiled with --with-innodb?
<manchicken_> It looks like it is, but if you actually connect to the server it says that "has_innodb = DISABLED"
<manchicken_> or whatever the variable is.
<ScottK> manchicken_: I'd suggest #ubuntu-server
<manchicken_> Righto.
<gallr> wacom supports 64-bit?
<tepsipakki> gallr: why wouldn't it?
 * gallr slaps keescook around a bit with a large trout
<gallr> sorry
<gallr> ok sounds good tepsipakki
<gallr> us 002 Device 004: ID 056a:0017 Wacom Co., Ltd
<tepsipakki> so it works?
<warp10> Hi all!
<gallr> yep
<siretart> slangasek: do you happen to know if the recent change in the SRU procedure (add a test-case description) should be applied to packages which are atm already in -proposed?
<mantiena-baltix> Hi all
<somerville32> Hi
<mantiena-baltix> maybe someone knows, where to find wubi developers ? I'm developing ubuntu-based distro and wubi-cdboot doesn't work with my CD - it says "Could not find any appropriate CD !" :(
<superm1_> mantiena-baltix, in #ubuntu-installer is where the main wubi guy comes
<superm1_> mantiena-baltix, xivulon is his name.
<superm1_> mantiena-baltix, i dont know his time zone though, so you'll have to see when he pops up next
<mantiena-baltix> superm1_: thanks
<jc-denton> hi all
<jc-denton> how can i rebuild the aacraid driver w/o compiling the whole kernel?
<jc-denton> its using dkms,  but that's for redhat afaik
<jc-denton> i guess compiling is a bit of development ;)
<mantiena-baltix> jc-denton: I think you should ask such questions not at this channel, maybe #ubuntu-kernel is right for you ?
<jc-denton> ah i did not know this channel
<jc-denton> thx
<jc-denton> humm however i get no answer there :(
<gasp1> jc-denton: is that driver inside the kernel or a third-party driver?
<jc-denton> both
<jc-denton> but i got it from the adaptec website
<jc-denton> because the version there is higher then the one that modinfo shows me
<jc-denton> and i was having trouble with it
<gaspa> ok, in that case module-assistant could be fine for you.
<gaspa>  you should have the right sources installed and configured
<jc-denton> ah is there a wiki page how to use it
<jc-denton> where do i have to place the driver sources, so they are found by module-assistant
<highvoltage> asac: ping
 * Hobbsee de-spams ubuntu-devel
 * Mithrandir tickles Hobbsee 
 * Hobbsee tickles Mithrandir back, holds him to the ground, and stomps his feet
<Hobbsee> good morning!
<Mithrandir> morning
<Hobbsee> Mithrandir: ah, it's you up early, as opposed to everyone else being eaten by sharks.  gotcha.
<Spads> Anyone here got a shark-bite kit?
<Fujitsu> Spads: Of course, here. I always keep one around, just in case a shark makes it inland.
<Hobbsee> Fujitsu: you jus tneed to move to adelaide.
<Fujitsu> Hobbsee: Good idea.
<Hobbsee> they really do get eaten by sharks there
<Hobbsee> and the locals tend to talk about it for a few weeks
<Hobbsee> damned fear-mongering paper of theirs
<Fujitsu> Heh.
<Hobbsee> (disclaimer:  Hobbsee is from adelaide herself)
 * Fujitsu faints.
<Hobbsee> hm?
<zul> morning
<Seveas> Hobbsee, so that's why we can't throw you in a pool, shark fear :)
<Hobbsee> Seveas: no, you cant throw me in the pool, as it might get you bashed up.
<slangasek> siretart: I would assume not, but I suppose you should ask pitti
<Seveas> I prefer the shark :)
<Hobbsee> Seveas: a wise move.
<Hobbsee> Seveas: although i'm not sure which would cause more pain
<pitti> Good morning
<zul> hi pitti
<geser> Hi pitti
<Hobbsee> tag, pitti
<asac> highvoltage: pong
<highvoltage> asac: is it possible to seperate the Firefox artwork from the firefox package, so that you could have another package to apply the mozilla artwork?
<highvoltage> asac: it would make it easier to have an unbranded/gobuntu/iceweasel branded version in Gobuntu.
<asac> in general yes ... if you want to contribute, you are welcome. I will have to check back with my mozilla contact though
<asac> highvoltage: join #ubuntu-mozillateam :)
<highvoltage> asac: right :)
<^robertj> ok, the protective gpt partition in mbr had the wrong tag assigned to it by the guided install and much unhappyness resulted, what package gets that bug? partman? grub2?
<^robertj> (-server install btw0
<bddebian> Heya
<mantiena-baltix> bigon: hi
<mantiena-baltix> bigon: you closed bug #89431 - did you checked if VOIP works for you in empathy 0.14 ?
<ubotu> Launchpad bug 89431 in empathy "Enable voip (audio/video talk) support in gossip-telepathy" [Undecided,Fix released] https://launchpad.net/bugs/89431
<Zdra> mantiena-baltix: VoIP support in Empathy is extremely experimental and disabled by default in upstream
<Zdra> I'm pretty sure it won't work well for most users...
<bigon> mantiena-baltix: yep voip "works" with empathy, you need telepathy-stream-manager and a webcam
<bigon> Zdra: :p
<Zdra> bigon: it "works" but not stable at all :)
<mantiena-baltix> bigon: for me it doesn't work at all, I don't have webcam, but have microphone
<bigon> mantiena-baltix: you must start telepathy-stream-engine and set FS_VIDEO_SRC=videotestsrc is-live=true
<bigon> mantiena-baltix: btw Zdra is the upstream dev :p
<mantiena-baltix> Zdra: nice to meet you
<mantiena-baltix> bigon: empathy does not start telepathy-stream-engine automatically ?
<mantiena-baltix> glatzor: hi
<glatzor> servus mantiena-baltix
<Zdra> mantiena-baltix: yes, it's started magically, but it need to be installed
<Zdra> mantiena-baltix: but if you want to start stream engine with some special parameters you have to start it manuelly first
<bigon> mantiena-baltix: yes it does but you must pass FS_VIDEO_SRC=videotestsrc is-live=true before starting it
<bigon> Zdra: does tp-se looks at the gstreamer-properties?
<Robot101> bigon: no, it's made of loss
<mantiena-baltix> bigon: why I must set FS_VIDEO_SRC to videotestsrc
<Robot101> bigon: for audio it always uses alsa src/sink
<bigon> mantiena-baltix: because tp-se always looks for a webcam
<mantiena-baltix> and because of this it doesn't work for me ?
<Robot101> for video stuff it tries gconfvideosrc, v4l2src then v4lsrc
<bigon> if tp-se takes 100% of cpu time, yes it the reason
<Robot101> so it will use the gst-properties choice of video input device
<mantiena-baltix> btw, maybe it's enough to set video input to videotestsrc in  gstreamer-properties ?
<mantiena-baltix> bigon: yes, it uses 100% CPU when I try to call to someone
<mantiena-baltix> bigon, Robot101: after setting video input to videotestsrc in  gstreamer-properties calling dialog doesn't eat 100% CPU, but I still hear no sound and volume controls are grey and inactive :(
<mantiena-baltix> maybe I can call to you for testing ?
<bigon> mantiena-baltix: the control of the volume is not implemented yet
<mantiena-baltix> bigon: hehe, it just shows nonworking volume control elements ? ;)
<bigon> mantiena-baltix: yep, are you sure your microphone is working in gst-proprerties?
<mantiena-baltix> yes, I got working VOIP at least ;)
<mantiena-baltix> bigon: thanks for help
<pitti> ArneGoetje: bzr get lp:langpack-o-matic
<slangasek> pitti: that command gives me a really awesome stack trace :)
<slangasek> (on gutsy)
<soc> hi
<soc> will libsoprano be updated the next few days or is it worth to build it on my own?
<soc> because kde4 requires now a higher version than the one shipped in hardy
<soc> someone?
<Riddell> soc: I can't say when it'll be updated
<Riddell> probably next week
<soc> ah ok
<soc> thanks ...
<Lure> soc: it is probably easier to just use soprano from kde svn (kdesupport module) - just remove soprano packages
<soc> ah ok
<soc> thanks!
<soc> about the encryption plans of hardy:
<soc> is it intended that one can just put in his usbstick in and use the additional partition?
<Lure> soc: that what they are looking for for kubuntu
<soc> ah cool
<Lure> soc: similar as opensuse 10.3
<soc> because currently with device mapper you have to put the stick in before you boot
<soc> and thats really crappy
<soc> additionally, IF i choose to encrypt something, i would be happy if the kernel/ubuntu wouldn't complain the whole time at the startup if the stick isn't put in
<soc> i can't understand that
<soc> IF a person decides to encrypt something, it would be sensible that the kernel wouldn't tell everyone that there is an encrypted partition
<hunger> So far a package for hardy needs about 1.7 times longer to build as it did in gutsy:-( Is that due to the new gcc or were only the big guns compiled so far?
<soc> :-)
<soc> looks like gcc is really getting slower and slower over time :-/
<hunger> Yeap, I am afraid so.
<nny> working on one of these new eee pc laptops. Does anyone have a site with good init boot time reduction or ways to speed up the boot process?
<hunger> soc: I am a bit concerned as it will take about 6month to build all the source packages for hardy... and I was only counting the successful builds, too.
<tonyyarusso> nny: Well, I know you can use the 'bootchart' package to find where the bottlenecks are, but I don't know how to fix them.
<nny> ok thanks thats a start
<nny> not so bad right now, using alt cli install (523 MB)
<soc> hunger: right ...
<soc> maybe it will be fixed in time ...
<soc> if not, hardware upgrades might be necessary
<soc> and with people having the change to build there own personal repo pressure won't get less ---
<siretart> crimsun: your @ncat.edu mail account is over quota. If you are interested in my signature for that uid, ping me for resending the mail to you
<soc> hunger: http://kerneltrap.org/Linux/Compiler_Misoptimizations
<soc> maybe that's is part of the problem ...
<hunger> soc: There was a mail on gcc-devel recently where one compiled some code with several versions of GCC. The 4.3 produced the slowest code, took the longest to compile and produced the biggest binary:-(
<hunger> soc: The response was along the lines of "but it is better anyway":-(
<broonie> hunger: "See, higher benchmarks in everything!"
 * hunger waits for the xorg-mess to straighten itself out. Somebody bumped the packages in the build queue recently:-)
<soc> :-)
<soc> hunger: sometime gcc devs are weird ...
<soc> maybe we need something like ecgs again, to wake people up ..
<hunger> soc: What do you expect? They spend their time on open source;-)
<soc> :-P
<soc> btw, i just wonder, why we can't use one or two compiler versions ... not FOUR!
<hunger> soc: yeap, we'd need an xorg-for-compilers.
<soc> i have gcc 3.3, 3.4, 4.1, 4.2 installed here
<hunger> soc: 3.4 is from the libc5 IIRC.
<soc> 3.3 is only needed for sun-java and fglrx kernel mess
<hunger> Dunno why there is a 4.1 around.
<soc> 3.4 for ghemical and some progs i never heard of
<hunger> But then that was the default compiler in gutsy (at least on my system), so maybe they just did not get round to remove it yet.
<soc> 4.1 is completely useless..
<hunger> soc: Isen't cpp-x.y enough for that?
<soc> lsen't?
<hunger> soc: Some programs need the cpp from an outdated gcc for some reason or another.
<hunger> soc: Sorry, it's gcc-3.3-base that is needed for the old libc stuff, not gcc-base-3.4
<soc> those programs should be fixed up ...
<soc> but of course, ati is one of the candidates again
<soc> how could i think, that they would leave out a chance to produce mess?
<hunger> soc: Actually the LSB says it is OK IIRC, so there is little a distri can do.
<soc> yes, of course
 * hunger wonders how big gnustep-base is... running for 9h on one of the buildservers already.
<soc> but on the other side, it would be nice if programs would have fewer dependencies
<soc> and old compiler versions might be a dependencie easy to fix ...
<hunger> soc: Not always.
 * hunger is waiting for the new freeciv for ages now... and it is still in the pending queue.
<hunger> At least it is packaged already.
<hunger> I'd love to be able to "vote" for packages in the build queue on LP;-)
<jonmasters> Anyone seen Martin Pitt?
 * jonmasters is in Plymouth looking for him
<jcastro> he's upstairs
<jcastro> jonmasters: he's in a meeting
<jonmasters> If someone can ping him, it would be *awesome*
<jonmasters> Ah.
<jcastro> I'll ping him irl and have him get ahold of you
<jonmasters> jcastro: no rush, I'm working from this little coffee shop called kiskadee
<jcastro> yeah it'll probably be like 40 minutes or so
<jonmasters> I'll hang out here, and if he's around, cool, otherwise I'll ping him later. But I drove down, so if he's around, it would be cool. Whatever works!
<jonmasters> no problem.
<jcastro> oh, you're in plymouth?
<Keybuk> jonmasters: we're in a meeting until 4pm, and then there's a group trip somewhere :-/
<Keybuk> though you may be able to grab him for 15 mins in between the two :)
<jonmasters> Keybuk: well, I've got 4 hours of parking and am sitting having coffee. If he has time, awesome. If not, no big deal.
<Keybuk> http://patches.ubuntu.com/by-release/extracted
<Keybuk> ^ still experimental
<jonmasters> Keybuk: btw, someone really should document that "there is no unstable ubuntu" and explain the differences between Debian and Ubuntu in terms of development.
 * jonmasters installed Hardy recently to keep up with the Jones'
<Keybuk> jonmasters: it's somewhere in the wiki
<jonmasters> Keybuk: -ENOTFOUND
<jonmasters> I only finally realized this when I tried to dist-upgrade to a non-existent tree
 * jonmasters thought there might be something beyond Hardy
<jonmasters> (an unstable branch)
<Keybuk> jonmasters: https://wiki.ubuntu.com/UbuntuForDebianDevelopers
<jonmasters> Keybuk: yes, I specifically read that. It specifically does not mention this ;-)
<Keybuk> jonmasters: mail Colin, it probably should
<jonmasters> It implies this, but does not state it.
<jonmasters> Keybuk: thanks. I'm just trying to help!
<jonmasters> ;-)
<Keybuk> we don't have a permanently unstable branch
<Keybuk> instead we have a development (next release) and stable (current release)
<jonmasters> right. Which means it's more like Fedora than I thought
<jonmasters> :-P
<Keybuk> heh
<jonmasters> (joke)
<Keybuk> didn't Fedora reorganise their entire community structure to match Ubuntu's where possible? :p
<^robertj> is there a workaround for bug #160803
<ubotu> Launchpad bug 160803 in ubiquity "can't install grub on device > 2.1TB, guided partitinioning assigns wrong type to masking partition" [Undecided,New] https://launchpad.net/bugs/160803
<soc> hi
<soc> i'm just wondering what will be the cornerstones upon 8.04 will be built ...
<soc> i assume x.org 7.3, server 1.4, linux 2.6.24, gcc-4.2, gnome 2.22, kde 3.5.8
<soc> correct me if i'm wrong!
<soc> OOo 2.4?/3? upstart 0.5?
<soc> working radeonhd/nouveau?
<Kmos> something like that, i think too =)
<soc> :-)
<Mithrandir> soc: take a look at the specs?
<soc> the uds ones?
<Kmos> soc: https://blueprints.launchpad.net/ubuntu/hardy
<soc> mh
<soc> not really much ,,,
<Tonohono> glad to see 24 was decided upon. using rc-1 on my 64bit laptop bumped battery life up ~40 minutes.
<soc> Tonohono: how that?
<soc> i'm quite happy beacuse of the new wirless stack ...
<Tonohono> tickless idle for 64 bit finally
<Tonohono> on packaged 22 kernel, powertop reports 400+ wake ups/second. with 24, I got it down to under 30.
<Tonohono> Battery loved me for it
<soc> cool
<soc> i'll try that immediately :-)
<Tonohono> good luck~
<soc> i have 300-600 wakeups/s with 2.6.22
<soc> but i'm compiling kde4 and dist-upgrading ...
<Tonohono> Ah
<soc> hope the 2.6.24 gets in soon
<soc> afaik, .24 will have merged i386/amd64 archs
<Tonohono> mhmm. rc2 released today, havent had time to give it a whirl yet
<Tonohono> aye, it will. went through half the rc1 changelog during a very, very slow day at work
<soc> ^lol
<soc> that was a very slooooooow day ... compressed changelog was 11 mb afair
<Tonohono> somewhere around there, yeah
<soc> :-)
<soc> i'm very interested in the new iwl driver from intel ...
<soc> i hope it works!
<pwnguin> it does
<pwnguin> theres a few tricks to getting it to work in gutsy
<soc> Linux 2.6.24 will have a lot of new wireless drivers using the new stack, 2,3 MB of source files in total
<soc> iwlwifi (intel), rt2x00 (ralink), adm8211 (admtek), b43 + b43legacy (broadcom), p54 (prism)
<soc> this looks _really_ good!
<tepsipakki> soc: noveau has no maintainer in debian, fwiw
<tepsipakki> so it's not in ubuntu either
<Tonohono> pwnguin, any online sources ye know off getting the iwl driver to run under gutsy? it's still might finnicky for me
<tepsipakki> soc: maintaining it would mean tracking upstream drm/mesa closely
<soc> mhh
<soc> tepsipakki: i see the problem ...
<pwnguin> Tonohono: lemme check my irclogs
<soc> they often have their own dri/drm trees with additional patches
<soc> would be hard to get a perfect combination between stable xserver and brandnew nouveau ...
<tepsipakki> soc: exactly
<tepsipakki> and since there is no release..
<ajmitch> tepsipakki: RAOF has been packaging it in a PPA, though
<tepsipakki> ajmitch: oh, I think I've seen that some time ago
<tepsipakki> maybe he knows how painful it is :9
<tepsipakki> *:)
 * ajmitch doubts that it'll really be ready enough for hardy
<pwnguin>  < RAOF> Epox_Ardere_: You'd put ipw3945 into the /etc/modprobe.d/blacklist file, and add iwl3945 to /etc/modules
<pwnguin> #ubuntu-motu.log-01:58 < RAOF> Epox_Ardere_: And be on Gutsy, and have linux-generic (or linux-rt) installed.
<ajmitch> maybe the drm stuff will have settled down a bit, but they're trying to move modesetting stuff into the kernel as well
<Tonohono> oh, thanks pwnguin
<pwnguin> Tonohono: there may be more
<Tonohono> alrighty
<tepsipakki> ajmitch: yeah, and that's not going in 2.6.24, maybe .25
<ajmitch> always chasing after a stable interface.. :)
 * pwnguin wishes for irclogs.ubuntu.com search
<ajmitch> wget & grep
<ajmitch> or maybe google search can help you
<pwnguin> or google
<pwnguin> but i seem to have more than google does
<pwnguin> Tonohono: from my irssi logs <amar*nth> had to add ATTRS{type}=="1" in 70-persistent-net.rules
<pwnguin> Tonohono: i recall having to do something similar
<Tonohono> noted~
<Tonohono> thanks again, i'll poke at it this evening when I try out rc2
<Kopfgeldjaeger> n8
 * jonmasters will swing by Plymouth again tomorrow.
<somerville32> Is releases.ubuntu.com still short on hd space?
 * jonmasters is hanging out in Plymouth for a while longer. Gonna head back to Cambridge in a few.
<soc> Tonohono: ok, back ...
<soc> just thought about it ...
<soc> wireless looks quite stable after all now
<soc> new drivers are coming, but i don't think kernel devs will significantly change the framework in the next few months
<soc> but with hardy we might had one of the last stable things on the graphics side ...
<soc> with things like gallium3d in 2008 some breakage will be guaranteed ...
<soc> whole ttm looks good at the moment, but people will need some time with it ...
<soc> question is how smooth the transition to gallium3d will be
<soc> how long they will maintain their non-gallium, pre opengl3 code ...
<hubuntu> regarding the kernel.. Is there any way to try other kernels with ubuntu?
<hubuntu> GNU/Solaris GNU/Hurd and the like?
<hubuntu> (writing a presentation about ubuntu and I just want to hace it plain from the sources :)
<soc> does someone know when we get the first kernel update in hardy?
<LaserJock> hubuntu: I think Nexenta is basically Ubuntu with Solaris kernel
<LaserJock> I don't think anybody's tried Hurd
<LaserJock> bddebian: ping?
<hubuntu> I knew about nexenta, but was thinking more of project indiana and trying to see if there's a ubuntu connection.. Thanks
<hubuntu> or som GNU endorsed ubuntu (like gnewsense is, and maybe Gobuntu will become...)
<LaserJock> hmm, I have no idea
<bddebian> LaserJock: Yo
<LaserJock> bddebian: have you ever tried Ubuntu/Hurd ?
<bddebian> I wanted to but no
<bddebian> Might be possible now.  Before we were waay behind on glibc vers
<sladen_> hubuntu: there aren't /that/ many kernels around
<ajmitch> bddebian: it's up to 2.1 now?
<bddebian> haha
<hubuntu> sladen: I know but I heard the Hurd is getting better and wondered if the darwin/fink people is up to some ubuntu love... Just trying to update the ubuntu presentation for the spanish speaking users
<hubuntu> Not that relevant, but... It's better to check, right?
<sladen> hubuntu: there was the debian knetbsd, and we do have the nexenta example that it can be done
<sladen> hubuntu: Linux has driver support.  Linux has momentum.  Linux has backing, and R&D and hotplug, and, and and...
<sladen> hubuntu: this is why Linux as a kernel is attractive.  If the OpenSolaris kernel takes momentum then, I'm sure people would switch
<sladen> hubuntu: Ubuntu generally tries to deliver the best and ensuring that "what nearly works" gets turned into "it just works"
<sladen> hubuntu: and it's always possible that somebody even forks the Linux kernel and takes that fork into a more attractive version.  See Xf86/Xorg ubuntu jumped faster than most people
<johanbr> I guess you could say many distro kernel trees are forks in a way.
<hubuntu> true
<hubuntu> I have another one for you guys: Is the LPIA port ("low-power on Intel architecture") officially supported or community supported?
<mjg59> Official, but you can't buy the hardware yet
<hubuntu> but you can test it on the nokia devices, right?
<mjg59> No, they're arm, not intel
<mjg59> Based on a TI chip
<hubuntu> ok...
<mjg59> The Nokia devices aren't targetted
<hubuntu> I see. But is much of their code used in the lpia port?
<mjg59> Nokia's? Yes.
<hubuntu> Is the gnome mobile platform then supported for both lpia & arm?
<hubuntu> or are we using something else on lpia (guess not, but better dumb asking than sorry not knowing..)
<pwnguin> hubuntu: there was some commotion a few days ago about a community based ARM port
<hubuntu> pwguin... Cool. Ubuntu on my nokia phone would be nice... :) A community port should definitely be welcomed... The Ubuntu skin for S60 is not as good as having the real thing...
#ubuntu-devel 2007-11-08
<crimsun> siretart: apologies, I've had an admin clear it
<aquarius> How does Add/Remove Programs know where on the menus an application has just been installed? Is it just watching the .desktop files cache?
<aquarius> (not sure if this counts as an "application development *on* Ubuntu" question...)
<pwnguin> aquarius: i dont think it does. it knows whats installed and somehow knows where they usually go
<pwnguin> maybe debtags, maybe from scanning the .desktops from the packages
<IntuitiveNipple> There's a .menu file for Gnome
<aquarius> aha, gnome-app-install is Python. that makes my life easier :)
<Fujitsu> aquarius: gnome-app-install gets all of its information from .desktops. That's where it gets the list of applications, so it probably works out the path from there too.
<aquarius> ah. gnome-app-install has a pre-existing cache of .desktop files for apps that aren't installed. :(
<Fujitsu> aquarius: How else would it know they existed?
<aquarius> Fujitsu: yeah, that's fine for gnome-app-install, no problem, it just doesn't help me with what I'm trying to do, which is work out, for a given arbitrary .deb file, what its .desktop file is after it's installed...
<Fujitsu> aquarius: dpkg -L package | grep desktop$
<aquarius> yeah, that's what I'm debating doing now...
<RAOF> apt-file search *.desktop?
<RAOF> (For the reciprocal problem)
<IntuitiveNipple> aquarius: In the .desktop file that comes with the package, and is installed to /usr/share/applications/ , the "Categories=Application;XXXXX" sets the location in the menus. you also need "Type=Application"
<Fujitsu> IntuitiveNipple: Except that the Application category has been deprecated for years.
<aquarius> tilda.desktop, say, has "Categories=GNOME;GTK;Application;Utility;TerminalEmulator;"; does it end up only in Applications on the main menu because that's the only one that exists, and there's no "Utility" or "TerminalEmulator" submenu on the Applications menu?
<Fujitsu> `Utility' should translate to `Accessories', I believe.
<Fujitsu> And that .desktop is broken.
<aquarius> erm. I meant Accessories, sorry, yes :)
<aquarius> so there's a lookup list somewhere which says "Category:Utility" == "Accessories menu"?
<Fujitsu> Utility becomes Accessories in GNOME, yeah.
<aquarius> If I wanted to build an "Applications" folder which reflected the structure of the menu (so submenus become subfolders)...has someone already done this? If not, is there a .desktop file cache somewhere I can read, or do I need to parse all the .desktop files myself?
<IntuitiveNipple> aquarius: Parse /etc/xdg/menus/applications.menu for the <Category>...</Category> tags (use the <Directory/> tag for the display name
<IntuitiveNipple> aquarius: sorry... my brain is dead ... use the <Name/> tag for the display name
<aquarius> erm...that file just defines the names of the submenus?
<aquarius> it doesn't define what's in them
<IntuitiveNipple> It defines the categories. They are parsed by gnome-menus and then it uses those when it reads the .desktop files to work out where to put the application entries in the tree
<aquarius> oh, right, gotcha.
<aquarius> so if I want to duplicate the structure I need to parse all the .desktop files myself, dividng them up according to applications.menu -- there's no handy cache anywhere? darn :_
<aquarius> :)
<IntuitiveNipple> I'm not sure if there is a cache, I believe it rescans each time it starts but I could be wrong, it isn't an area I have looked into much aside form working out how to get my packaged apps into the menus
<rockets> silly question. why is it that we have firefox, not iceweasel, but we have iceape, not seamonkey
<Hobbsee> wb, elkbuntu
<elkbuntu> Hobbsee, is the network still being epileptic?
<StevenK> We'll see
#ubuntu-devel 2008-11-03
<cjwatson> Laney: still Steve; I'm just doing some of the jaunty bootstrap while Steve is taking a well-deserved holiday
<TheMuso> jdong: alsa panicing? Now theres a surprise. It seems that not much testing goes into the tarballs when upstream creates them. From reading alsa-dev recently, all they do is check that the tarballs build it seems.
<TheMuso> s/panicing/panicking/
<ajmitch> that sounds promising, for such a fundamental part of the desktop
<TheMuso> ajmitch: Indeed.
 * TheMuso can't understand why the bits of the system he is interested in working on are not always quality controlled...
<wgrant> My bits of the system are always 64-bit unsafe!
<TheMuso> Pulse being such a moving target I can kind of understand, but alsa, and *SHUDDERS* dmraid?
<ajmitch> because you love the pain
<TheMuso> Dmraid being one of the worst, due to the upstream author not being very descriptive in his changelogs and vcs commits. Added to that, his vcs commits are in huge chunks, with messages like "such and such version checkin."
<wgrant> Haha.
<wgrant> Ouch.
<TheMuso> Yeah.
<jdong> TheMuso: yeah this is ridiculous I'm swithcing back to stock alsa
<TheMuso> Oh, and added to that, dmraid can be split into a backend and frontend. So when you attempt to build with the split backend and frontend, what happens, the library needed for the backend is requested to be linked against the frontend, which of course doesn't work.
<wgrant> This is why we shouldn't have FF.
<wgrant> Just push new versions!
<TheMuso> wgrant: heh.
<TheMuso> I think the opinion relating to anything kernel related is that people just pull patches to fix things anyway, so version releases aren't very important in terms of QA.
<ajmitch> wgrant: including post-release?
<wgrant> ajmitch: Yes. Fedora does, why not us?
<ajmitch> it'd lessen the complaints about universe, at least
<ajmitch> to be honest I wouldn't mind it so much for some parts of the archive :)
<TheMuso> Fedora does? ewww. However they are more of a RHEL test bed are they not?
<slangasek> directhex: hmm?
<wgrant> TheMuso: I've often seen them push new upstreams.
<wgrant> And break things.
<ScottK> opensuse does too, but they also break things or patch them in very unfortunate ways.
<TheMuso> ouch.
 * TheMuso subscribes to jaunty-changes, and starts mirroring jaunty.
<ajmitch> if only I had the bandwidth for it
<TheMuso> Well I already have intrepid, so mirroring jaunty is a matter of fetching new indexes, as well as the 6 updated packages in jaunty so far, so there is not much.
<TheMuso> Actually, not 6 packages, there have been 6 uploads.
 * ajmitch isn't bitter at all about being very close to capped to 64Kbp for the next 2 weeks
<TheMuso> The biggest bandwidth hog was when I set up the miror initially.
<ScottK> ajmitch: I hadn't noticed in increase in bitterness.
<ajmitch> I've only got most of main for hardy & intrepid on my laptop
<ajmitch> ScottK: good :)
<cjwatson> start merging jaunty too! I'm feeling lonely as the only one who's got started on the merge queue
<ajmitch> I will very shortly
<TheMuso> Jaunty is not open yet...
<ScottK> cjwatson: Is it open?
<cjwatson> no, but that doesn't stop you uploading
<cjwatson> it'll sit in a queue
<ScottK> OK
<TheMuso> Point.
<StevenK> Woot. Now only powerpc and ia64 are busted
<TheMuso> StevenK: ??
<cjwatson> glibc
<ajmitch> hppa isn't?
<TheMuso> Oh.
<cjwatson> I have ideas for both, will discuss them with doko when he's next up
<StevenK> ajmitch: It built on hppa, at least
<TheMuso> NCommander: reckons that glibc will need a newer kernel on powerpc to complete at least.
<ScottK> Progress.
<cjwatson> TheMuso: no, shouldn't
<ajmitch> StevenK: if that includes tests, I'm impressed :)
<cjwatson> TheMuso: just needs some test exemptions
<TheMuso> cjwatson: Right.
<cjwatson> but that's trivial, we just need to agree on them
<cjwatson> pselect wasn't implemented in the kernel until after what the buildds are currently running so I think that's probably an obvious exemption
<cjwatson> I'm waiting for infinity to tell me whether the ia64 buildd has the relevant filesystem mounted with relatime in order to find out whether that's the cause of its failure
<NCommander> cjwatson, just out of curosity, what are the buildds running as a host
<NCommander> or at least the kernels on each
<cjwatson> NCommander: apparently hardy+powerpc is busted on the buildds so they're running dapper. You can tell what kernel they're running by searching for "current=" in any recent glibc build log
<NCommander> dapper?
<NCommander> Ouch
<NCommander> Hardy works fine on PowerPC
<cjwatson> I trust infinity not to be lying to me.
<cjwatson> He co-administers those buildds and you don't, bluntly :)
<NCommander> let me rephrase
<NCommander> We were unaware of any issues with hardy on the buildd hardware
<TheMuso> NCommander: I'd trust infinity's opinion on this one.
 * NCommander nods
<StevenK> Hardy doesn't boot on the hardware that the buildds are on
<cjwatson> 04:05 <infinity> cjwatson: Actually, powerpc is still dapper, because hardy+powerpc=fail. :/
<cjwatson> is all I know
 * NCommander nods
<cjwatson> but this is not really a huge problem. The glibc build was all fine, it was just the tests at the end that exhibited regressions that hadn't been explicitly tagged as OK.
<NCommander> cjwatson, Ok, so thats easy to fix
<cjwatson> yes, like I say I just want to agree it with doko
 * NCommander would never touch the toolchain without doko's seal of approval :-)
<cjwatson> ia64 I'm less sure about; if it's due to relatime then that's a simple test fix, if it's not then I'm unsure of the right answer
<NCommander> cjwatson, is it possible to find out the extact modem of machines used a buildds for PowerPC? (I've been told they are XServes, but I dunno what model xserve)
<NCommander> s/modem/model
 * TheMuso also needs to look into d-i fixes for powerpc as well. d-i for powerpc generic hardware is... broken... at least for CD installs. :)
<cjwatson> NCommander: don't know offhand, ask #canonical-sysadmin I suppose
<TheMuso> for intrepid that is
<cjwatson> TheMuso: hmm, what fails?
<NCommander> cjwatson, the IDE modules udeb is broken due the fact the IDE module itself was renamed and no one updated the ports kernel d-i files to reflect this change
<cjwatson> ah
<TheMuso> cjwatson: a combination of important udebs being dropped for the cdrom initrd, and the ide-cd module being renamed and we missed it.
<TheMuso> +/c
<dholbach> good morning
 * lamont grumbles at wireless being b0rked on his dell 1520
 * StevenK grumbles at Compiz not showing the titlebar of the active window properly
<lamont> what was the final solution to iwlagn not supporting iwl4965 ?
<lamont> s/solution/workaround/
<lifeless> lamont: oh. intrepid loses on iwl4965?
<lamont> lifeless: interestingly, the livecd works just fine.  hardy upgraded to intrepid? not so happy
<pitti> Good morning
<pitti> Keybuk: hi
<lamont> OTOH, the upgrade hung walking through packages to see what it should remove.. maybe that's relevant...
<StevenK> Morning pitti
<pitti> Keybuk: hm, in previous releases the apt cache wasn't present at all, so you only got the driver notification on second login (after the cron job); that was fairly okay
<pitti> Keybuk: copying it across from the livefs would be even more elegant indeed
 * pitti subscribes to jaunty-changes
<lool> morning
<NCommander> morning lool, pitti
<Mirv> lifeless: release notes tells to install linux-modules-backports for iwl4965 to work
<Mirv> oh, lamont, actually
<lamont> Mirv: although I'm not seeing panics, nor am I using a G or N network.
<lamont> nor is it seeing the network
<lamont> fails to allocate an irq for it
<lamont> the device, that is
<lamont> and anything with 'backports' in its name makes me cry
<lifeless> lamont: please tell me if it worked :P
 * lamont goes looking for linux-backports-modules-intrepid
<soren> lamont: It was renamed to iwlagn, apparantly.
<soren> lamont: sha 4fc22b21b3fcb3580c32b70605ef114178f8e611
<lamont> soren: and broken, too.
<soren> Clever.
<lamont> I suppose I could flatline the poor 320GB drive, since the livecd works just fine, and the upgraded hardy machine not at all
<NCommander> lamont, depends on your hardware. I upgraded hardy to intrepid from iwl4965 -> iwlagn no issue
 * lamont even downreved his upgraded machine from 7.15 to 7.14 to better reflect the livecd
<pitti> asac: do you happen to know about iwl3945 not connecting to WPA/WPA2? (just got a PM with that problem descsription, but I don't have any encrypted network here for testing)
<lamont> [   99.140972] iwlagn 0000:0c:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
<lamont> ^^does not occur on the upgraded hardy box
<NCommander> lamont, maybe its a firmware issue
<lamont> pitti: the only 3945 issue I've seen is the US default thing
<lamont> NCommander: same firmware
<cjwatson> lamont: I didn't hear that it was broken across the board
<pitti> lamont: what does that do?
<lamont> --> bed for me, then slap the kernel guys around in the morning
<lamont> pitti: refuses to connect on channel > 11 until you give it permission - see the release notes
<NCommander> -1/-2 firmware?
<pitti> lamont: sleep well
<pitti> lamont: ah, thanks
<lamont> NCommander: linux-firmware 1.2
<lamont> on both
<NCommander> Hrm
<NCommander> Odd
<NCommander> What specifically does gmesg say on the subject
<NCommander> i.e.
<NCommander> [   20.947800] iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
<NCommander> lamont, -^
 * NCommander guesses lamont left for bed
<lamont> http://paste.ubuntu.com/66653/
<lamont> that's the grep output
<lamont> the 99.* lines are unique to the (working) livecd
<NCommander> lamont, we have the same extact hardware as far as the kernel cares
<NCommander> lamont, so we know the driver works on this hardware, its just a matter of figuring out why it doesn't work for you
<lamont> note that the driver and kernel are perfectly happy... just not when I upgraded my hardy machine to intrepid
<lamont> NCommander: you have now caught up with where I was 30 min ago
<NCommander> Oh
<NCommander> Hrm
 * NCommander might know the issue
 * NCommander personally doesn't have the requesting firmware line either
<lamont> that was 'dmesg | grep iwl'
<NCommander> Oh
<NCommander> Yeah, I do have it
<NCommander> That line is missing when you boot from upgraded box, correct?
<lamont> it's more the assigning and IRQ and initialzing the card that i'd like to see...
<NCommander> WHat looks like is happing is your card is initalizing to off
<NCommander> It will only get an IRQ when the card is on
<NCommander> DOes your laptop have a physical RF kill switch?
<lamont> yes.  untouched between the two boots
<lamont> and, in fact, set to 'on' as it has been for the past 9 months
<NCommander> RF kill support was added in intrepid for some dirvers
<lamont> and this state is stored in the filesystem???
<NCommander> No, but if there is a bug in the driver ...
<lamont> note that the same &(%)*^*_ ( driver stack works from livecd, fails from filesystem
<NCommander> when I flip the switch to off:
<NCommander> I get PCI INT A disabled
<NCommander> And then when I flip it back on, it reassiocates with an IRQ
<NCommander> This might just be boardline crazy, but try booting up with the switch off (make sure iwl sees the card), and then flip it to on and see if it initalizes
<NCommander> (there should be a log message about RF kill switch enabled)
<lamont>  grep switch /media/LEXAR/x/dmesg.out
<lamont> -mix 547 :
 * NCommander found a related bug
<NCommander> Still no wireless
<NCommander> ^?
<NCommander> One other thing
<NCommander> Right click Network Manager
<lamont> that was the livecd boot dmesg
<NCommander> make sure "Enable WIreless" is actually checked
<lamont> still booting with the kill switch off
<lamont> ISTR it was
<NCommander> ISTR?
<lamont> I seem to recall
<dholbach> wtf is your friend :)
<NCommander> Ok
<NCommander> Looking at the history, there was a bug involving the RF kill switch on Hardy, that caused a crash if it was switched
<NCommander> That patch might be causing something to go wrong with you
 * lamont plugs back in the wired lan cable, so that the network manager icon will appear
<lamont> or not appear
<NCommander> bah
<lamont> NCommander: but only when booted from the disk?????
<NCommander> lamont, do cat /sys/class/rfdisk/*/state
<lamont> it's really a question of WTF is installed on the disk that isn't on the livecd (or viceversa)
<NCommander> I did a fresh upgrade, no issues
<NCommander> Er
<NCommander> Dist-upgrade
<NCommander> no issues
<NCommander> same hardware
<NCommander> (its a sony viao VGN660N)
<lamont>  /sys/class/rfdisk/*/state -> ENOENT
<NCommander> did iwlagn even load?
 * lamont did 'do-release-upgreade'
<NCommander> Ok, if you flip the switch now, does dmesg say anything?
<lamont> which did the dist-upgrade, then went into a seemingly infinite loop that I killed after about an hour, while it tried to figure out what packages it should be removing
<lamont> didn't
<NCommander> It sounds like the kernel did not get upgraded
<NCommander> What's uname -a say
 * NCommander notes if the linux metapackage wasn't properly upgraded, you could end up in a situation with an old kernel, and dist-upgrade not saying anything
<lamont> 2.6.27-7-generic, just like it does on the livecd.
<NCommander> so much for that theory
<NCommander> does lsmod show iwlagn loaded (with the kill switch disabled)
<lamont> wasn't much of a theory.
 * lamont -> bed
<NCommander> lamont, well, kernel debugging is half guessing, half banging your head on a wall
<NCommander> lamont, when you wake up, ping me, and the debugging shall continue! ;-)
<lamont> NCommander: in all the years I've been debugging kernels, it very rarely involves guessing
<NCommander> not if you can't reproduce locally :-/
<cjwatson> Keybuk: there's one Debian change to udev that I need to make the installer keep working in jaunty. Mind if I merge it in advance of whatever other merge plans you have?
<cjwatson> it's the start-udev thing
<asac> pitti: hmm ... point them to the ~network-manger PPA
<pitti> asac: ah, I told him to try the modprobe.d workaround from the release notes, let's see
<pitti> asac: if that doesn't work, I'll have him try the PPA, thanks
<asac> pitti: we have: 292054 and 263963
<asac> pitti: ppa packages fixes it for about 50% ;)
<soren> asac: Hey. About the mullplugin thing I mentioned on Friday before running out the door. It's listed, but the "Enabled" column says "no".
<asac> soren: tools -> addons -> plugins ?
<asac> -> enable ;)
<soren> asac: The button says "Disable" :/
<asac> soren: heh. why do you need nullplugin?
<asac> i mean ... its nullplugin ;)
<soren> asac: The description suggested that it was the plugin in charge of helping me install other plugins... Is that wrong?
<asac> soren: no that is correct, but enabled/disabled shouldnt matter.  what plugin do you want to install?
<soren> asac: What I really wanted was a java plugin. A month before Intrepid released, my homebanking system worked fine. Now it doesn't, and I want to find another java plugin that works.
<asac> soren: heh ;)
<asac> soren: ok
<soren> I have no idea what changed (if anything).
<liw> soren, Danske Banken?
<asac> so go to your banking site ... so that java is used ;)
<soren> liw: Nope.
<asac> soren: then go to tools -> manage content plugins ... and search for other plugins.
<soren> asac: But the thing that offers me to download new plugins doesn't show up. That's the point.
<soren> Oh.
 * soren goes to try that.
<asac> soren: well if you have a plugin installed it wont show up because you already have one. thats why we the tools -> manage contnt pluginst stuff exist
<soren> asac: Oh, I don't. I removed all the java plugins.
<soren> br
<asac> hmm
<soren> brb, even.
<asac> soren: i would suggest that you go to some other java driven site then
<asac> soren: most likely your banking site wants to be smart and uses javascript code to gather whether it makes sense to load an applet at all
<asac> cant tell without any details. for me the "missing plugin" puzzle show properly up when the website uses a plugin
<soren> asac: Fantastic timing. Their site just went down for maintenance.
<soren> asac: I did mention that nullplugin is still listed as "Enabled: No" in the about:plugins page, right?
<asac> soren: ok. 1st. there is no java plugin in about:plugins?
<asac> soren: well nullplugin isnt important ;)
<asac> soren: http://www.dgp.toronto.edu/~mjmcguff/learn/java/01-drawingLines/
<asac> if i go there the "install missing ... " bar pops up
<soren> asac: No java plugin, no.
<soren> Ah, so it does.
<asac> soren: right. so that means your bank  wants to be stupid and probes for a javaplugin
<asac> if no java plugin found it doesnt even try to display an applet
<asac> kick them ;)
<soren> Hm... installing the openjdk plugin failed. Can I find out how somehow?
<asac> soren: to get he real results you should go to about:plugins .... edit the pfs.datasource.url pref and replace 8.04 with 8.10
<soren> Er.. I mean "why somehow".
<asac> soren: thats an ugly bug
<soren> asac: You mean about:config, I presume?
<asac> soren: yeah
<asac> soren: search for pfs.datasource
<asac> soren: and pfs.filehint.url
<soren> Changed them both...
<asac> soren: both suffer from the same problem :(
 * soren tries again.
 * soren has two with identical descriptions..
<asac> soren: yes. java applets dont have a description ... thats the only class of plugins that wasnt updated
<soren> Both of the icedtea ones fail to isntall. :(
<asac> soren: when it tries to install ... you can see apturl as a process ... what package does it try to install
<asac> ?
<soren> asac: I get this on the console: http://pastebin.com/m754814e1
<soren> asac: cacao-oj6-plugin
<asac> soren: ok. so the error happens reawlly quick?
<calc> i'm here in the hotel in beijing, really tired :\
<calc> i somehow lost a day during the flight over the north pole
<asac> calc: heh ;)
<soren> asac: Yes.
<calc> got on the plane at 6:30am sunday and got to the hotel at 5:30pm monday
<asac> soren: the error is probably something mvo wants to take a look at
<soren> asac: Perhaps it's because I'm not using an official mirror and apturl gets all confused.
<asac> soren: can you try to run apturl apt:cacao-oj6-plugin ?
<calc> and something is weird with their dhcp i can't get an address in linux it claims the message length is too long
<asac> (guessing that thats the packag name)
<calc> so i'm stuck in vista (gag)
<asac> calc: chinese dhcp
<asac> ;)
<calc> asac: heh
<mvo> soren: are you running jaunty already?
<directhex> jaunty is ready for work?
<asac> mvo: is that a jaunty bug? ;)
<mvo> asac: it looks like it to me :)
<soren> mvo: I might be :)
<soren> mvo: I updated base-files just for kicks :)
 * soren reverts that
<mvo> soren: heh :) wait for the python-apt update then - I can push a version into my ppa too if you want?
<asac> soren: that might help
<soren> it works fine from the command line, though.
<soren> (apturl that is)
<asac> soren: otherwise you should have replaced 8.04 with 9.04 ;)
<soren> brb
<asac> (just to be accurate)
<soren> Yay, it works.
<asac> soren: good .... so now try the tools -> manage content plugins thing
<asac> soren: and then file bugs against java to properly support that by also linking the plugin in /usr/share/ubufox/plugins/
<soren> asac: I don't have that.
<asac> soren: you only have that when you are on a website with java content (or any other content)
<asac> soren: you dont have ubufox then
<asac> (if you dont have that at all)
<soren> ii  ubufox                             0.6-0ubuntu1                       Ubuntu Firefox specific configuration defaults and apt support
<asac> soren: and in tools there is no menu entry?
<soren> asac: Sorry. I'm an idiot. An illiterate one, even.
<soren> You really shouldn't put it all the way at the bottom. It's very hard to spot :)
<asac> soren: well. you also get a plugin symbol in the status bar
<asac> soren: when you visit a page that has a plugin in-use
<asac> soren: not that the color is better to spot ;) ... but we have two hardy-to-spot places now
<soren> Ok, progress... I can now login to the homebanking system. Let's see if it works properly...
<soren> asac: Their status page says that the system is unstable at the moment... I'll wait until they think it's stable before I start distributing blame between firefox, java and my bank :)
<siretart> slomo: lool: I think I understand both of your arguments. still, I'd like to hear Mithrandir's opinion on the issue where this should be fixed: the package, ffmpeg upstream, pkg-config or gstreamer0.10-ffmpeg
<asac> siretart: wpasupplicant really takes ages for iwl chipsets nowadays ;) ... maybe there is also something broken  on the supplicant side?
<asac> siretart: look 263963 272185 292054
<siretart> asac: sorry, I don't follow wpasupplicant upstream that closely. how about asking that on the hostap mailing list?
<asac> siretart: do they allow to post without suscription ;)?
<asac> let me check
<pitti> tjaalton: do you still have your -evdev fix for the amd64 joystick misdetection in the pipe? would be good to upload now
<siretart> asac: how about subscribing? I'm reading that list via gmane/nntp, btw.
<asac> hmm
<asac> siretart: yeah. wil,l do that now
<asac> i think i cannot ignore that any longer ;)
<asac> found some interesting thread about WPA-EAP with TTLS
<cjwatson> calc: oh, hmm, doko's in Beijing too isn't he, I completely forgot about that
<cjwatson> guess I should just go ahead with the glibc changes I had in mind
<directhex> when's the time to talk about demoting a package from main?
<cjwatson> directhex: normally you don't need to talk about it much ... if the package isn't seeded or depended upon by anything seeded, we'll eventually get around to removing it
<cjwatson> check http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt to find out if it's supposed to be on its way out
<directhex> cjwatson, it's mono-dbg. i suspect it's in main due to a misunderstanding about its contents
<cjwatson> directhex: no, it's in main because *-dbg is automatically in main if any other binaries from the same source are
<tjaalton> pitti: yes, will do
<directhex> cjwatson, can that be overridden?
<cjwatson> directhex: the exception mechanism for that is Extra-Exclude in the supported seed
<cjwatson> directhex: you can look up the reasons why packages are in main in http://people.ubuntu.com/~ubuntu-archive/germinate-output/
<cjwatson> directhex: so explain to me why we don't want mono-dbg? the package description says it contains debugging symbols for various libmono-* and mono-* packages, which seems like something we'd normally want
<pitti> tjaalton: thanks; I can test it, I have an amd64 installation here on my test box
<tjaalton> pitti: nice, I'll prepare it after lunch and let you know
<directhex> cjwatson, it contains managed mono debugger symbols, which aren't much use unless you're using the (universe-based) mono-debugger. the symbols for crashes of the mono runtime itself are in mono-jit-dbg
<leszek_fh> hi
<cjwatson> directhex: well, that does raise the question of whether mono-debugger should be in main ...
<cjwatson> but OK, I agree that for the moment it should be wherever mono-debugger is
<directhex> cjwatson, whichever is preferred. i've been trying to ease up on all the promotions i've been requesting lately
<cjwatson> directhex: I've taken it out of ubuntu.jaunty/supported; might need to come out of some of the other flavours' supported seeds too
<directhex> cjwatson, understood. thanks
<elmo> cjwatson/Hobbsee : belatedly done
<directhex> cjwatson, i'd like to have a discussion at a later point about what from to drop to universe in mono - the big restructure being worked on in debian means a significant reduction in tomboy/f-spot dependencies, which really means a reduction in things that need to be in main too. but i won't have a proper handle on exactly what until packaging work is complete
<cjwatson> elmo: thanks
<cjwatson> directhex: right, hopefully *that* one should be mostly automatic
<directhex> this should mean 10-20 meg of space freed up on the jaunty cd, at least from us
<cjwatson> Keybuk: http://paste.ubuntu.com/66683/
<cjwatson> oh, that will be very nice
<directhex> cjwatson, short version: there are two versions of .net - 1.0 and 2.0. apps like tomboy are 2.0 apps using 2.0 libs, but many tools & libs in the dep chain are compatible with both 9and have 1.0) deps. we're making tomboy/f-spot 2.0-pure, by essentially removing 1.0 support from packages & building everything as 2.0-only
<cjwatson> right
<directhex> so gtk-sharp won't pull in ~10 meg of unneeded 1.0 stuff anymore
<directhex> but it's not crystal clear on what to drop yet, as some build-depends may remain on 1.0
<wgrant> pitti: Thanks for sponsoring #280148.
 * wgrant hits Launchpad. It doesn't notify when new series tasks are created.
<Hobbsee> elmo: cool, thanks :)
<slomo> siretart: ok, great... the last part shouldn't need fixing though as gst-ffmpeg doesn't even use the libtheora/vorbis/raw1394 stuff from ffmpeg ;)
<pitti> wgrant: you're welcome
<calc_> hmm my other account still shows online
<calc_> i think i got blocked by the great firewall :\
<calc_> i can't tracert past the first hop to my computer at home anymore
<calc_> weird its working again now, but my machine hasn't rebooted or anything like that
<Q-FUNK> asac: please slow down with bug #112248.  I think you misunderstood what the report was about.
<ubottu> Launchpad bug 112248 in network-manager "fields to set MTU and MSS missing" [Wishlist,Fix released] https://launchpad.net/bugs/112248
<RainCT> slomo: thanks
<Q-FUNK> wgrant: did the X logs I attached to the g-s-d bug provide anything useful?  is there anything else I can test for?
<asac> Q-FUNK: we have a new bug. opening a real old bug for a regression is not the preferred way for me
<asac> its 258743
<Q-FUNK> asac: closing a valid bug to open a new one doesn't sound to practicla either
<asac> Q-FUNK: ok thought it was reopened
<asac> if it was never closed then its ok
<asac> but we have the other bug which properly tracks that
<Q-FUNK> then mark it as a duplicate, not as invalid
<asac> Q-FUNK: feel free. .. i posted the info there ,)
<Q-FUNK> plus, you haven't answered anyone's question in the thread.  where in NM 0.7?
<ranjithk> hi guys
<asac> Q-FUNK: i cannot answer all questions. bugs are not questions ;)
<asac> Q-FUNK: you can set MTU in connection editor
<ranjithk> i m having a small problem with my terminal font settings
<ranjithk> anybody here uses monaco font in their terminal?
<asac> Q-FUNK: if you want more options open a similar bug as 278309 for openvpn
<asac> but be precise which options that should be
<asac> (except mtu which is now properly dealt with in the other bug)
<Q-FUNK> asac: we *had* a proper bug already, before you marked it as invalid.
<Q-FUNK> be more careful in reading reports before you run and invalidate or merge them.
<Q-FUNK> it wasn't only about MTU.  the report clearly said that the NM pluging for OpenVPN doesn't support even half of what OpenVPN itself supports and that this is the real issue.
<LordMetroid> Is there any reason why USB Wifi-peripherals drivers needs to be installed through ncurses?
<asac> Q-FUNK: then the title should have been better
<asac> Q-FUNK: only thing i saw is that i had a bunch of MTU bugs open now
<asac> and so i dont need the bug that popped up latest
<asac> (and it doesnt provide any info which isnt in the other bugs)
<Q-FUNK> to asac with a hammer, every NM bug is about the generic MTU feature sticking out ;)
<ranjithk> guys . when I select monaco as the font for my terminal the spacing between the letters in terminal increases, it looks very bad... any idea how to solve it?
<asac> Q-FUNK:  not sure what you mean
<Q-FUNK> cat /dev/coffee  >> /ubuntu/devel/asac
<asac> hehe
<asac> yeah
<asac> but i had coffee already
<Q-FUNK> you seem to be on a point and shoot rampage today ;)
<wgrant> Q-FUNK: I replied to that bug yesterday...
<Q-FUNK> wgrant: with the mention about the final version of the patch?
<asac> Q-FUNK: i do post release bug triaging ... yes.
<wgrant> Q-FUNK: No, see the end of bug #287462
<ubottu> Launchpad bug 287462 in gnome-settings-daemon "Intrepid: left-handed mouse setting forgotten after resuming from sleep/hibernation (dup-of: 280148)" [Undecided,New] https://launchpad.net/bugs/287462
<ubottu> Launchpad bug 280148 in gnome-settings-daemon "g-s-d needs to set mouse properties when a new device appears" [Medium,In progress] https://launchpad.net/bugs/280148
<maxb> In intrepid, my thinkpad seems to have decided that the "mute" softkey is now a "lock screen" softkey, what is the proper package for me to file a bug against?
<Q-FUNK> wgrant: odd. I didn't see this one in my mailbox yet.  OK, let's try deleting the xorg.conf and reloading X, then.
<Q-FUNK> brb
<wgrant> This doesn't, on the whole, look good.
<Yoe> hi -- can anyone please tell the relevant persons that nbd hasn't been using sf.net's CVS repository in years anymore, but has switched to SVN instead?
<Hobbsee> Yoe: you'd better tell debian that, as we don't modify that package at all.
<Mithrandir> Yoe: both intrepid (just released) and jaunty (current release) are pulling the stock package from Debian.
<Mithrandir> Hobbsee: ISTR Yoe being the Debian maintainer.
<cjwatson> Yoe: do you mean launchpad.net/nbd?
<Yoe> cjwatson: yes
<Hobbsee> Mithrandir: oh.
<cjwatson> Yoe: it's maintained by ~registry, so mere mortals can't change it; you'd need to ask #launchpad
<Hobbsee> right, ignore me then :)
<Yoe> ah, okay.
<Yoe> didn't realize that's a different channel :)
<ogra> Yoe,  Wouter Verhelst, wouter@debian.org maintains it in debian, we usually only pull his fixes/changes
<cjwatson> ogra: Yoe *is* Wouter.
<Yoe> ogra: that's me :)
<ogra> err
<ogra> lol
<ogra> sorry for that :)
<Yoe> ogra: nvm :)
<cjwatson> Yoe: Ubuntu folks generally don't have god privileges on LP (only demigod at most)
<Yoe> right
<Mithrandir> cjwatson: you're good at nethack.  You could ascend.
<Mithrandir> ;-)
<cjwatson> Mithrandir: still only gets you to demigod(dess). :-)
<cjwatson> http://launchpadlibrarian.net/19279370/buildlog_ubuntu-jaunty-sparc.glibc_2.8%2B20081027-0ubuntu4_CHROOTWAIT.txt.gz erk, I screwed *that* one up
<stefanlsd> cjwatson, is the process you go through for prepping the new release available to read about?  just interested in whats involved.
<cjwatson> stefanlsd: http://wiki.ubuntu.com/NewReleaseCycleProcess
<stefanlsd> cjwatson, great. thanks!
<cjwatson> stefanlsd: getting the toolchain to work and dealing with whatever exciting new changes are coming down the pipe is different every time, of course
<cjwatson> so it's just a framework
<Mithrandir> cjwatson: for a user, is it possible to remove stuff from the SendEnv list?
<stefanlsd> cjwatson, nodnod. i see the schedule says by the 6th. fun!
<Mithrandir> (using .ssh/config or similar)
<lool> Mithrandir: Don't think so
<lool> Mithrandir: I tried once and couldn't
<lool> But this was a couple of openssh releases ago
<lool> Mithrandir: Pissed of by SendEnv LANG LC_ALL, aren't you?  :)
<cjwatson> Mithrandir: I don't think so, sorry
<ogra> wasnt there an ugly way to override that ?
<lool> Override them in your shell's init :-(
 * ogra thinks he remembers an option that drops a lot of security though
<cjwatson> Mithrandir: https://bugzilla.mindrot.org/show_bug.cgi?id=1285
<SurcouF> hi
<ubottu> bugzilla.mindrot.org bug 1285 in ssh "provide fallback options /etc/ssh/ssh_config" [Enhancement,New]
<cjwatson> ssh -F /dev/null perhaps
<cjwatson> or ssh -F ~/.ssh/config
<Mithrandir> lool: no, I was barking up the wrong tree.  It looked like a sunos box got really unhappy when I sent it a locale it didn't grok.
<Mithrandir> as in, closed the connection.
<cjwatson> we could add a quirk for that
<cjwatson> get me ssh -vvv output
<stefanlsd> cjwatson, where do the new toolchain packages come from? do we sync or merge those from debian (if they have any later, not sure) - or build from source from upstream?
<cjwatson> stefanlsd: mixture. Our toolchain maintainer also maintains the toolchain in Debian
<cjwatson> or at least large chunks of it
<stefanlsd> cjwatson: heh. cool. pretty handy
<lool> cjwatson: Nice workaround
<lool> Now I just need a way to set -F from .ssh/config   ;-)
<SurcouF> how update-manager has known that a new distribution is available ?
<lool> SurcouF: It checks a special meta file on the archive
<cjwatson> SurcouF: meta-release* files on http://changelogs.ubuntu.com/
<SurcouF> cjwatson, to setup an offline mirror, I must download theses meta-files ?
<SurcouF> is changelog.ubuntu.com is hardcoded ?
<lool> SurcouF: You can override it in update-manager by subclassing, but I don't think you can configure it
<SurcouF> I can through /etc/update-manager/meta-release
<lool> I stand corrected
<SurcouF> thanks for help
<ogra> cjwatson, how hard do you think it will be to make gfxboot support syslinux ?
 * ogra is preparing a spec for the mobile images to have some kind of bootmenu)
<Mithrandir> probably not hard, given the not-huge difference between isolinux and syslinux.
<ogra> right, that was my thought
<ogra> even though gfxboot is quite painful
<ogra> but it makes no sense to invent something new if we use it everywhere else
<cjwatson> ogra: I thought it already did
 * soren concurs
<cjwatson> ogra: the gfxboot patch to syslinux certainly patches ldlinux.asm
<ogra> ah, cool, well, nobody ever tried to use it with syslinux to my knowledge
<ogra> at least not on the mobile images
<anilg> How can i tell dpkg -r <package> to not run the prerm and postrm files.. and just go ahead and remove the files?
<tseliot> anilg: try removing the prerm and postrm from /var/lib/dpkg/info/
<RainCT> uhm.. is the raw popcon gzip broken?
<RainCT> (I mean http://popcon.ubuntu.com/all-popcon-results.txt.gz, not the application)
<kirkland> pitti: around?  looks like we finally got to the bottom of bug #259631 ...
<ubottu> Launchpad bug 259631 in ecryptfs-utils "Cannot open Private directory after a reboot" [Undecided,Invalid] https://launchpad.net/bugs/259631
<kirkland> pitti: obviously (to me), automatic mounting of encrypted private is not going work when the user has chosen to automatically login (with no password)
<kirkland> pitti: this isn't obvious to some of our users, though
<kirkland> pitti: i'm looking for some help/advice/assistance in solving this in a desktoppy way
<superm1> kirkland, there is unfortunately the same type of problem with WPA keys if you do automatic login since your keyring can't be automatically unlocked
<kirkland> superm1: ah, thanks, good to know that my case isn't the only one
<superm1> kirkland, but that case isn't "horrible", you get a GUI offering for unlocking the keyring with your password at least
<kirkland> superm1: i'm thinking we might need something like that for an encrypted Private directory
 * kirkland is hoping that a desktop developer will volunteer for this one :-)
<superm1> kirkland, well if you can perhaps hook into the same mechanism and unlock it through the gnome keyring instead of the method you currently do, or possibly supplemental to the method you currently do, you can get it for free; I don't agree with it being automatically unlocked for you on an automatic login though without at least a passphrase.  that entirely defeats the purpose
<kirkland> superm1: i have to use the kernel keyring, not the gnome keyring
<kirkland> superm1: in that the filesystem is mounted in kernel space, not userspace
<kirkland> superm1: and you're absolutely right about defeating the purpose, if there's no prompt for passphrase at all
<superm1> kirkland, ah didn't consider that the filesystem was mounted in kernel space not userspace, but that makes sense then.
<kirkland> superm1: perhaps you know ...  what is the gui method for prompting a user for a passphrase?  with that, this should just be a 3-line shell script
<superm1> kirkland, no sorry, i'm not sure
<kirkland> superm1: looks like i might be able to do it with gksu
<ScottK> kirkland: gnupg-agent uses pinentry and that has ncurses, gtk, and qt support.  Maybe that'd be a place to look.
<kirkland> ScottK: cool, thanks, let me check....
<pitti> kirkland: hm, I thought we already discussed that; would be cool if going into Private and clicking that magic script would work
<pitti> kirkland: a gksu wrapper or something
<kirkland> pitti: okay, i'm looking at it now
<tjaalton> pitti: ok, here's the diff/dsc for the new evdev: http://users.tkk.fi/~tjaalton/dpkg/
<pitti> tjaalton: thanks! please upload
<tjaalton> pitti: sure
<pitti> asac: hm, n-m is apparently not in https://edge.launchpad.net/~asac/+archive ? that's just an old version
<asac> pitti: we have a ~network-manager team
<asac> thats the place
<pitti> asac: ah, thanks; I asked him to try that (modprobe.d trick didn't work)
<asac> pitti: so did you find something about your huawei interfaceNumber bouncing?
<pitti> asac: not really; it does bounce between 0 and 1, but both work
<Keybuk> cjwatson: m-o-m appears to be working normally
<cjwatson> cool
<cjwatson> now I just need to track down infinity to re-bootstrap glibc/sparc
<pitti> tjaalton: hm, why does your upload remove evdev-with-high-keys.diff ?
<cjwatson> lamont: ... or maybe you can help?
<asac> pitti: both interfaces work?
<pitti> asac: yes, apparently
<asac> pitti: hmm. ok. but you still need NM to be restarted?
<pitti> asac: only real problem is that the PIN number doesn't work (I followed up in the bug), and the different vodafone tariff
<pitti> asac: no, I don't need to restart it
<lamont> cjwatson: other stuff that would be ahead of that... RT is love, worst case
<asac> pitti: ok and you workaround the pin number by unlocking in phone first?
<pitti> asac: right
<pitti> asac: well, I actually enabled the PIN again, to test a possible fix
<pitti> and to be able to debug it further
<pitti> always good to be nagged about bugs :)
<asac> pitti: ok i think i saw a mail from you with serial debug
<tjaalton> pitti: oh, it was just a temp file from quilt
<cjwatson> lamont: already RTed
<tjaalton> pitti: didn't notice that 0ubuntu5 had it
<cjwatson> lamont: but I'm blocking on this to open jaunty so am trying the nag approach too
<tjaalton> pitti: it's already pulled from master
<pitti> tjaalton: ah, right, it's patches/, not debian/patches
<pitti> tjaalton: someone forgot QUILT_PATCHES apparently :)
<tjaalton> pitti: yep, seems like it :)
<asac> pitti: so you get a bunch of +CREG: 0,0
<asac> at the end
<asac> afaik thats an undefined return value for gsm standard. but what i find even more wierd is that it doesnt abort right after seeing that the first time
<asac> let me check that in code
<lamont> cjwatson: I feel your frustration, if that helps any
<pitti> asac: what I found weird is that this debug log didn't have the "PIN timeout" message I got originally from /var/log/daemon.log
<asac> hmm 0,4 was the one thats undefined. 0,0 means -> wait a bit longer
<asac> most likely we should give it more time and dont use idle_add, but timeout_add
<asac> pitti: so if you failed like: http://launchpadlibrarian.net/19271027/nm-serial.txt ... and wait a bit and then try again, does it work then?
<pitti> asac: "try" -> disconnect/reconnect in nm-applet?
<asac> pitti: without disconnect. just connect again?
<asac> pitti: try http://launchpadlibrarian.net/19271027/nm-serial.txt
<asac> pitti: sry: http://paste.ubuntu.com/66792/
<asac> :)
<asac> should give your net more time to find a network and so on
<pitti> asac: I love this thing; now PIN actually seems to have succeeded, but now it SIGTERMed pppd
 * pitti prepares log
<asac> pitti: sigterm most likely happens when NM gave up
<pitti> asac: http://people.ubuntu.com/~pitti/tmp/nm-serial-connect-pppterm.txt is for my current attempt
<pitti> asac: it spun for a while, maybe 10 seconds
<pitti> it did get DNS and everything
<pitti> tel, brb
<asac> pitti: err ... that log doesnt even have "tty" in it ;)
<asac> wlan0 + eth0 only ;)
<pitti> asac: argh, sorry; seems i killed hte log when restaring n-m to get back eth0
<asac> heh
<pitti> asac: anyway, I have a confcall, bbl
<asac> pitti: yeah. apply and build the patch while callilng ;) (multitask)
<asac> 16:59 < asac> pitti: sry: http://paste.ubuntu.com/66792/
<pitti> asac: re
<pitti> asac: http://people.ubuntu.com/~pitti/tmp/nm-serial-connect-pppterm.txt for real now
<pitti> asac: your patch is for PIN auth timeout?
<asac> pitti: ok thats a different issue. please check whether the patch makes you connect more reliably
<asac> (e.g. the last log is ok)
<pitti> asac: "last log is ok"?
<pitti> asac: I'll apply the patch and try again
<asac> pitti: yeah: http://people.ubuntu.com/~pitti/tmp/nm-serial-connect-pppterm.txt  that is good
<asac> pitti: its a differnt issue that we can fix in a minute i think
<pitti> asac: you mean "good for debuggin"?
<pitti> ok
<mvo> hm, can we do syncs from debian to intrepid-proposed for "SRUs"  (I'm thinking of bug #289603)
<ubottu> Launchpad bug 289603 in sabre "Please sync sabre 0.2.4b-26 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/289603
<asac> pitti: i think bug 268667
<ubottu> Launchpad bug 268667 in network-manager "MASTER - not all required ppp options get set on command line which makes ppp use bad values from /etc/ppp/options* (WAS: CDMA (cellular modem) connection drops often with network-manager)" [Medium,Triaged] https://launchpad.net/bugs/268667
<asac> pitti: the woarkaround for that bug is to add lcp-echo-failure 0 to /etc/ppp/options
<pitti> asac: I did that ^ and now n-m is spinning eternally in an "Sending AT+CREG?" loop
<asac> pitti: you mean with the patch?
<asac> pitti: with 0,0 ?
<asac> or 0,2?
<pitti> asac: no, with the patch it's still building
<asac> pitti: ah
<pitti> asac: with 0,2
<asac> pitti: the lcp-echo-failure 0 stuff made it spin eternally?
<pitti> asac: well, it's really hard to confirm that, since n-m seems to break in a different way every time I restart it :(
<asac> unlikely ... lcp-echo-failure 0 will give you stability if the connect succeeds
<asac> shouldnt change anything before that
<pitti> asac: I just reconnected again, and now it doesn't loop any more, but says http://paste.ubuntu.com/66799/
<pitti> ah, finished building
<asac> pitti: hmm. crazy stuff.
<kirkland> ScottK: Riddell: is there just a simple, shell-callable program i can use to graphically prompt a user for a password, and print the output to stdout?
<kirkland> ScottK: i looked at pinentry
<kirkland> ScottK: it's another dependency, that I'd like to avoid at this point
<kirkland> ScottK: Riddell: i'm trying kdesu/kdesudo, but it's not behaving like gksu/gksudo
<kirkland> note that I don't actually need to run anything as root, or another user.
<kirkland> i just need to get their login password, to pass as input
<pitti> asac: so the patch did have one effect; now I get two "Searching for network/AT+CREG?" messages per second, and the tray applet spin speed is normal
<pitti> asac: before that, the spinning speed was absurdly fast
<asac> pitti: ok so more time didnt help
<asac> pitti: yeah i can assume that
<pitti> asac: it apparently took a while
<pitti> asac: seems it finally connected, then ppp died again
<Cheery> error in overgod: ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 failed: No such file or directory
<asac> pitti: oh it connected?
<asac> pitti: did it go from 0,2 ... over 0,0 to 0,1 -> success?
<pitti> asac: well, it said "CONNECT 7200000", but then it died
<pitti> http://people.ubuntu.com/~pitti/tmp/nm-serial-connect-pppterm-patch.txt
<RainCT> Uhm.. can anyone tell me why this doesn't work? "curl https://wiki.ubuntu.com/MOTU/Headers/NextREVUDay?action=raw"
<asac> pitti: do you ahve the lcd- stuff in your options now?
<pitti> asac: loop with 0,2, then 4 times 0,0, then 0,1 and then COPS and CONNECT
<asac> pitti: ok that means the patch is good ;)
<RainCT> bah, the wiki is evil :(
<pitti> asac: yes, I have "lcp-echo-failure 0"
<pitti> asac: patch> yes, it definitively fixes the "retry" speed, and the tray icon appearance
<pitti> asac: now that I see what it does, I understand it :)
<asac> pitti: well. the main purpose wasnt the applet, but just to give the modem some time and rest ... but ok. lets look at the ppp dying now
<pitti> yeah, I know
<asac> pitti: can you post the syslog tail too? (it has better timestamps)
<pitti> asac: http://people.ubuntu.com/~pitti/tmp/daemon.log
<pitti> asac: weird, that worked consistently well while I had the PIN disabled
<pitti> asac: and now it never connected a single time while I have PIN enabled
<pitti> asac: do you want a daemon.log/serial debug when it works? (i. e. without PIN)?
<asac> pitti: no. i want the syslog where you see the ppp sigterm
<asac> or tell me at what time i should look above
<asac> pitti: at best really the syslog not sure if g_message stuff goes to daemon.log at all
<pitti> asac: oh, ok; indeed, syslog has pppd messages, daemon.log doesn't; copying...
<pitti> asac: http://people.ubuntu.com/~pitti/tmp/syslog
<asac> pitti: ok and you added lcd-echo-failure to options right?
<pitti> asac: right, with value "0"
<asac> pitti: err sorry ... i think i mistyped
<asac> pitti: lcp-echo-failure 0
<asac> and while you are at it also add
<pitti> asac: yes, that's what I actually have; it was already there, commented
<asac> lcp-echo-interval 0
<pitti> that's "30" right now
<asac> pitti: yeah. make it 0
<pitti> done
<asac> i had people for which it helped that they instantly got disconnected
<pitti> restart n-m, try again, new log?
<asac> (and its a known bug)
<asac> pitti: yeah. at best a tail
<asac> started when you restart NM
<pitti> yep
<asac> pitti: ensure that no ppp stuff is running
<lakitu> hey, no one in ubuntu could help me - i used gparted to shrink an ntfs drive, & now it's file system is damaged.  one, i'd like to report this, two, how do i solve this?
<lakitu> #ubuntu/ubuntu
<pitti> asac: connected!
<asac> pitti: good crack. please do a bit stress testing ;)
<asac> like reconnecting, replugging and stuff
<asac> if it doesnt work sometimes its ok ... as long as it works most of the time ;)
<pitti> asac: http://people.ubuntu.com/~pitti/tmp/syslog-lcp-echo-interval-0.txt
<asac> yeah cool. seems ok
<pitti> asac: clicking on the connection again (reconnect) doesn't work
<asac> pitti: this time the modem didnt even go over 0,0 ... which means you were a bit lucky at least
<pitti> asac: http://paste.ubuntu.com/66818/
<pitti> ^ reconnect attempt
<asac> pitti: yeah. does it work after that again?
<pitti> asac: whoops, sorry, that paste was incomplete
<asac> pitti: i think i have the same issue when i directly reconnect (without disconnect)
<pitti> no, it was complete, sorry
<asac> pitti: for me without a disconnect it works every second attempt
<asac> e.g. connect -> ok, reconnect -> fail -> connect -> OK ...
<asac> and connect -> ok, disconnect -> ok -> connect -> OK
<pitti> asac: disconnect/connect worked 4 times in a row
<asac> pitti: ok thats good enough.
<pitti> I agree
<pitti> asac: direct reconnect 3 failures out of 3, but *shrug*
<pitti> asac: stress test 3, unplugging/replugging
<asac> pitti: ok. so we have: 1st -> fix database (event.vodafone.de), 2nd -> patch for ppp options, 3rd -> patch for "give more time"
<asac> 2nd is already scheduled for SRU ... so we should make a bug out of 3
<pitti> asac: the changes I did to ppp/options should be done statically for all people?
<pitti> how will that affect users of modems?
<asac> pitti: no .... it will be done by NM
<asac> pitti: its a bug that it forgets to specify a bunch of default options
<pitti> asac: 1st (event.v.d) -> I can do that if you want me
<asac> pitti: i will do that ... have to talk with upstream guy about next SRU anyway
<asac> pitti: not sure if we want to use the bug you posted the log to for the timeout patch though
<pitti> asac: yeah, what I thought; accumulate some more fixes; if there aren't any, we can just do it for this own patch, though
<pitti> asac: okay, unplug/replug/connect worked 3/3, too \o/
 * pitti hugs asac
<pitti> asac: I'll revert the changes to /etc/ppp/options now, so that I can test the SRU properly
<pitti> asac: bug/timeout patch> depends, is it actually related to the problem of the original reporter?
<asac> pitti: nobody can tell. asked now
<asac> pitti: will target that bug for -updates
<pitti> asac: thanks
<asac> pitti: will provide test packages there on next round
<asac> have to get all the patches i send out for testing together first ;)
<asac> pitti: yeah. the options bug is bug 268667 ;)
<ubottu> Launchpad bug 268667 in network-manager "MASTER - not all required ppp options get set on command line which makes ppp use bad values from /etc/ppp/options* (WAS: CDMA (cellular modem) connection drops often with network-manager)" [Medium,Triaged] https://launchpad.net/bugs/268667
<asac> (in case you want to subscribe that)
<asac> but you will see this soon enough anyway ,)
<pitti> done
<pitti> asac: whom can I ping about the database SRU?
<pitti> I'd like to find out whether it's worth doing an SRU for that websessions tariff, or whether there are more fixes piled up upstream
<asac> pitti: last time i talked to him he said he would like to establish a procedure to make a new database release every 2-4 weeks
<asac> pitti: his nick is wellark ... he sometimes is in my mozilla channel
<asac> pitti: but otherwise he is in #nm or #mbca
<asac> pitti: https://bugs.edge.launchpad.net/mobile-broadband-provider-info
<Cheery> how to provide /dev/snd/midiC0D0 ?
<pitti> asac: ok, he's away right now, I'll discuss that procedure with him
<asac> pitti: there are the bugs that wait to be pulled upstream. also there might already be more upstream commits
<pitti> asac: right; I pinged him
<pitti> asac: thanks a lot for your help!
<asac> pitti: welcome
<asac> pitti: ok i also told him that he should ping you here ... so double tapping ;)
<pitti> Keybuk: after reading https://bugzilla.redhat.com/show_bug.cgi?id=453095, I'm not that convinced any more that bug 280931 (where you commented on) is indeed a kernel bug
<ubottu> bugzilla.redhat.com bug 453095 in udev "Cd tray is closed automatically after ejecting" [High,Closed: errata]
<ubottu> Launchpad bug 280931 in udev "Tray retracts automatically after eject with 2.6.27-6 and -7 (dup-of: 283316)" [Undecided,Confirmed] https://launchpad.net/bugs/280931
<ubottu> Launchpad bug 283316 in ubuntu-release-notes "opening /dev/scdN causes tray to be closed" [Undecided,Fix released] https://launchpad.net/bugs/283316
<Keybuk> oh?
<Keybuk> it's a dup of a bug that's filed on the kernel
<pitti> Keybuk: I did confirm that reverting a kernel commit fixes it
<liw> cd tray closing after eject? I had that, I used setcd (I think) to disable it
<pitti> but that RH bug and http://marc.info/?l=linux-hotplug&m=121749053301147&w=2 are pretty convincing, too
<Keybuk> what do the RH people say?
<Keybuk> having web browser issues
<pitti> Keybuk: udev has a rule which causes vol_id to be run on the device, which does open(), which closes the tray
<Keybuk> is that a change rule?
<pitti> Keybuk: so applying that rule patch allegedly fixes it (haven't tried myself yet, but lots of confirmations)
<pitti> and reverting that kernel change fixes it, too
<Keybuk> sounds reasonable
<pitti> so maybe the kernel change just triggered the udev rule
<Keybuk> has anyone filed the bug to udev upstream?
<Keybuk> since that's an upstream rules file, I avoid patching it
<pitti> the kernel change fixed the DISC_INFO ioctl (open/no disk/etc.)
<pitti> Keybuk: yes, it is fixed upstream already
<pitti> Keybuk: I'll continue to poke in this
<Keybuk> ok, we'll pick up the fix when I update udev then
<pitti> Keybuk: I just wanted to ask you whether you just said "itz kernel bug" based on the dup bug, or whether you actually read that RH bug
<sebner> pitti: Keybuk already and EST for doing a proposed upload? /me is interested because my family's pc is also infected =)
<Keybuk> just based on the previous existance of the dup
<Keybuk> sebner: upload of?
<pitti> Keybuk: ok, thanks; just wanted to make sure to not discard any insight from you
<pitti> sebner: for that cd eject bug?
<Keybuk> I'm not planning a udev upload for a few weeks
<sebner> yep
<Keybuk> jaunty isn't even open yet
<pitti> I think I'll read everything again now, check udev upstream status, test the fix myself, and prepare an upload (or Keybuk does it, if he wants to)
<pitti> Keybuk: oh, I'm more concerned about intrepid SRU at this point
<Keybuk> and I plan to switch to using upstream rules (which need me to do some work on them first) with the jaunty upload
<sebner> pitti: so an upload could be ready in the next few days?
<Keybuk> I'm uninterested in intrepid SRU :)
<Keybuk> it doesn't seem that worthy a bug for it
<pitti> Keybuk: ok, I'll do that then
<pitti> Keybuk: oh, I regard it as very serious
<Keybuk> and I really don't like fiddling with those rules, because you tend to end up breaking other things
<Keybuk> very serious?  the CD tray pulls itself back in every now and then?
<pitti> Keybuk: I just started appreciating when I used my desktop with a motor tray again :)
<Keybuk> vs. "my RAID doesn't boot anymore"
<pitti> Keybuk: it does it every time, you can't sanely take out a CD
<Keybuk> sure you can, just push the button on the CD drive
<Keybuk> works for me ;)
<sebner> At least here the tray opens, closes and doesn't open anymore until xserver is restarted
<pitti> and since it's so unexpected, it's likely to physically squash media or fingers
<pitti> Keybuk: not for me
<pitti> eject button or eject program is all the same
<Keybuk> make sure you get a lot of testing
<pitti> yeah
<Keybuk> not just that it fixes it for people, but that it doesn't break things like lvm, raid, etc.
<Keybuk> the patch is quite ... widely encompassing
<Keybuk> it could make vol_id not be run for all sorts of things
<Keybuk> and we need vol_id for mounting disks ;)
<pitti> Keybuk: https://bugzilla.redhat.com/attachment.cgi?id=312742 is weird, but it's not what upstream used AFAIK
<pitti> is udev upstream in gitweb somewhere?
<Keybuk> it's in kay's sekrit git
<Keybuk> might also be on gitweb proper
<Keybuk> http://git.kernel.org/?p=linux/hotplug/udev.git;a=log
<pitti> Keybuk: http://marc.info/?l=linux-hotplug&m=121783305407150&w=2
<Keybuk> though be slightly careful
<Keybuk> Kay's completely rewritten udev's rules matching engine
<Keybuk> pitti: that rule seems entirely sane
<Keybuk> (for once, it's completely backwards compatible
<pitti> found it
<pitti> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=f755fd5657b619fd27160ad202fc5d773d096e9c
<Keybuk>  but rules written for the new engine won't necessarily work with older udev)
<Keybuk> pitti: looks good
<Keybuk> rule should work with old udev too
<pitti> Keybuk: ok, thanks for review; the upstream commit seems pretty focused and few side effects to me, too
<pitti> Keybuk: ok, I'll have some dinner and prepare an SRU afterwards
<Keybuk> the basic difference (other than no shared code ;p) is that the new engine supports things like KERNELS=="foo", KERNELS=="bar"
<Keybuk> the old engine only allowed one of any match
<Keybuk> (or 5 env or attr matches)
<pitti> Keybuk: WDYM with "old engine"? intrepid has 124
<Keybuk> git head has a rewritten rules matching engine
<Keybuk> and, for that matter, rewritten run and device queue
<Keybuk> it's quite a lot faster and less memory-hungry
<Keybuk> and also less braindead
<Keybuk> but WAAAAAAAH!
<kirkland> pitti: okay, i have a debdiff for ecryptfs-utils for interactive password prompt, but I'm really, really going to need you or someone on the desktop to have a look at it
<kirkland> pitti: to tell me if the user-experience makes sense there
<kirkland> pitti: http://pastebin.ubuntu.com/66842/
<pwnguin> is anyone interested in getting seekwatcher packaged for jaunty?
<pwnguin> http://oss.oracle.com/~mason/seekwatcher/ (check out the videos)
<s0u][ight> hello what are big packages that are installed on the live cd that can be missed?
<s0u][ight> like sound
<s0u][ight> what package manages all the sound?
<s0u][ight> so i can remove everything about sound
<mohbana> hi, when is texlive 2008 going to be in the repo?
<mohbana> also how do i force the installation of a 32bit .deb file, i've got adobe reader but it's only available as 32bit binary
<ranjithk>  anybody here uses monaco font in their terminal?
<mohbana> ranjithk: i've tried it, but i quickly went back to the default
<mohbana> ranjithk: rendering is crap, i bet
<mohbana> also how long does it take to resize a partition, i think i've allocated to little to ubuntu
<mohbana> ranjithk: i've filled a bug. i understand what you mean
<mohbana> it's horrible
<s0u][ight> where can i find info about how the live cd of ubuntu is made
<mohbana> ranjithk: 1. https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/190848 and 2. https://bugs.launchpad.net/ubuntu/+bug/292375
<ranjithk> i m using monospace for now, but monaco was simply superb
<ubottu> Launchpad bug 190848 in gnome-terminal "font in terminal does not resemble font in preview" [Unknown,Fix released]
<mohbana> ranjithk: complain
<mohbana> because this is just horrible, i can;t believe they allowed this to get through
<ranjithk> yeah!.. very bad.
<pitti> kirkland: in general this looks fine to me, however, some notes
<pitti> kirkland: (1) so there isn't a convenient KDE counterpart to this?
<NCommander> morning world
<pitti> kirkland: (2) does ecryptfs have any gettextization so far? it would be important to wrap the strings into a gettext call
<pitti> kirkland: (3) I think mpt will have some wording improvements; e. g. "THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA" -> "Your private directory needs to be unlocked with your password. Run me to authenticate" or something?
<mpt> ECONTEXT
<pitti> mpt: that was a reply about http://pastebin.ubuntu.com/66842/
<pitti> mpt: do you know about ~/Private ?
<mpt> pitti, no, where is it explained?
<pitti> the encrypted directory which is unlocked at login, when you use ecryptfs?
<pitti> kirkland: ^ any good doc URL for that?
<kirkland> pitti: 1) i farted around with kdesu, and couldn't get it to work correctly; posed a couple of questions above in this channel to the kde developers
<kirkland> mpt: pitti: http://help.ubuntu.com/community/EncryptedPrivateDirectory
<kirkland> pitti: 2) not much i18n for ecryptfs yet; hoping to improve that in Jaunty timeframe
<mpt> There's no button to turn it on?
<pitti> kirkland: maybe the dummy file name could say "Run me" if gksu is available (and in the future, the KDE counterpart), or "run ecryptfs-unlock-blabla" if ont?
<pitti> mpt: only in the alternate installer so far
<mpt> heh
<kirkland> pitti: 3) I'd like to keep that wording the same for Intrepid, improve for Jaunty
<pitti> kirkland: 2) OK; it's dynamic text, so we can i18n it once the package has i18n infrastructure
<kirkland> pitti: i have a new patch, moves around this stuff a little bit
<pitti> kirkland: yes, I'm not suggesting to change it for intrepid
<kirkland> pitti: i think it might be a little better, i'm testing it now
<pitti> kirkland: all three of my points actually refer to jaunty
<kirkland> pitti: oh, okay
<kirkland> pitti: so tell me this.....
<kirkland> pitti: how do we want to handle this in intrepid?
<kirkland> pitti: document that encrypted private + automatic login is incompatible?
<mohbana> also how long does it take to resize a partition, i think i've allocated to little to ubuntu
<pitti> kirkland: TBH I think the existing file stub is enough to point it out, or do you disagree?
<pitti> kirkland: I wouldn't worry too much about intrepid for that
<pitti> kirkland: ubiquity doesn't even offer it, so people who run it actually have to search and fiddle anyway
<kirkland> pitti: we have multiple users, multiple duplicate bug reports complaining about their encrypted private not working .... after 2 weeks of discussing, it finally comes out that their automatically logging in (no password)
<pitti> kirkland: gotta run now (Taekwondo), can we continue tomorrow? thanks
<kirkland> pitti: please
<kirkland> pitti: or ping me if you come back around later
<pitti> kirkland: yeah, I'm not *opposed* to fix it in intrepid
<pitti> just not the full i18n'ing and all that
<kirkland> pitti: i'm just looking for a realistic approach
<kirkland> pitti: righto
<mpt> pitti, I don't understand what that string is saying
<mpt> kirkland, is this a graphical alert or something that appears in the terminal?
<mpt> or something else?
<kirkland> mpt: when your ~/Private directory is not mounted, you can't see any of your data there
 * NCommander looks at evil bug #286175
<ubottu> Launchpad bug 286175 in fontconfig "evince crashed with SIGSEGV in FcConfigSubstituteWithPat()" [High,Confirmed] https://launchpad.net/bugs/286175
<kirkland> mpt: in its place, you see a single file (actually a symlink) that contains that string, above
<kirkland> mpt: the symlink actually points to the binary that can "fix" the situation for you, by mounting your private directory again (prompting you for a password along the way)
<mpt> Ah yes, we talked about this at the last UDS
<kirkland> mpt: yup, we did
<mpt> though I'm pretty sure the word "unmount" wasn't used ;-)
<kirkland> mpt: i think it might have been your idea?
<kirkland> mpt: the symlink bit?  maybe, maybe not....
<mpt> I think that was your idea
<mpt> so, if double-clicking will make the Private folder available again
<mpt> why are you trying to also include command-line instructions?
<kirkland> mpt: because there is no gui in the server
<mpt> What difference does that make?
<mpt> (for "double-clicking" read "running the script")
<kirkland> mpt: from the command line, if you cd to ~Private, and do "ls", you see this informative file name
<kirkland> mpt: if you on the command line, you say, "Oh, okay ....  mount.ecryptfs_private"
<mpt> Why does it need to be informative instead of imperative?
<mpt> ./Show\ the\ Private\ folder
<kirkland> mpt: what do you suggest the text should be?
<mpt> If it's a script that already does the right thing, why wouldn't people just run the script
<kirkland> mpt: it's a symbolic link to a binary
<mpt> ok, a binary then
<kirkland> mpt: possibly not immediately obvious that it is executable?
<mpt> Even without -l, ls shows which items in a directory are executable
<kirkland> mpt: take a look at a symlink to an executable
<mpt> aha
<mpt> Fix ls then ;-)
<mpt> I don't have any other particularly great ideas on improving that
<s0ullight> what package do i have to remove to remove sound?
<azeem> s0ullight: please ask in #ubuntu
<calc> i wanted to let everyone know i am out of email contact since linux dhcp doesn't work here :(
<azeem> calc: are you running the Hurd now or what?
<calc> azeem: vista
<azeem> ah
<calc> azeem: no matter what i did on ubuntu it wouldn't stop giving me 'message too long' errors
<calc> maybe i'll be able to access it from the university but the hotel definitely doesn't work :(
<calc> this 14hr offset is really weird getting used to
<superm1> calc, you might try calling up the support number at your hotel.  When I was at a hotel in MTV, they actually had some sysctl parameters that needed to be adjusted when that happens
<kirkland> is there some tool i can run a .desktop file through, to check compatibility across gnome/kde?
<cjwatson> kirkland: desktop-file-validate?
<kirkland> cjwatson: perfecto, thanks.
<cjwatson> kirkland: perhaps with --warn-kde, not sure of the exact semantics of that
<calc> superm1: i'm in beijing i'm lucky to reach anyone who can evern speak english :\
<pochu> hi
<pochu> when will packages start to be autosynced from Debian?
<cjwatson> pochu: next couple of days
<pochu> cjwatson: thanks
<cjwatson> pochu: currently waiting for sparc to build glibc (delayed for various reasons), then build dpkg merge, then build debhelper merge, then open
<pochu> it's ok to upload fixes to intrepid-proposed, and upload them/get them synced to Jaunty when it's opened, right?
<NCommander> cjwatson, if I can provide a patch to fix the powerpc's glibc (once I run it by doko), does anything special need to happen to get the powerpc buildds to update?
<cjwatson> NCommander: err - it's already done
<NCommander> It was?
<NCommander> Cool.
<cjwatson> yes, I uploaded that earlier
<cjwatson> pochu: given how close jaunty is to opening, it would be better to upload to jaunty first
<NCommander> thanks cjwatson
<cjwatson> on previous form sparc will take about five more hours though
<NCommander> cjwatson, I look foward to jaunty as we will hopefully be able to improve support on the port architectures :-)
<cjwatson> we won't block everything on working ports of course; glibc is a special case
<cjwatson> well, the initial toolchain bootstrap in general
<cjwatson> we could have opened primary architectures over the weekend if not for that
<NCommander> cjwatson, how is the inital bootstrap of the toolchain done on each architecture?
<mohbana> i get an 'exec: 579: /lib/ld-linux.so.2: not found' after i've installed adobe reader
<mohbana> what's up
<cjwatson> NCommander: by-hand builds of Ubuntu packages in a Debian base system (usually) until we have build-essential going, then bootstrap from that temporary set of builds and build everything again
<cjwatson> needs to be done by a buildd admin in order to get into LP though
<NCommander> cjwatson, sounds like a very time consuming and tedious process :-/
<jcristau> sounds like a bootstrap, actually..
 * RainCT is scared :)
 * NCommander has done a bootstrap, hence the very time consuming and tedious comment ;-)
<cjwatson> NCommander: yes
 * Keybuk giggles at Iron Man
<Keybuk> nobody who knows Mark can possibly not laugh at one particular line
<mDuff> Re bug #129285 -- I've had a patch in the tracker since February, and it still hasn't been applied (or objected to); it still applies (and is needed) on Ibex. Is there anything I can do to help nudge this along?
<ubottu> Launchpad bug 129285 in dmraid "dmraid and LVM are incompatible" [Low,Triaged] https://launchpad.net/bugs/129285
<directhex> ember, and possibly pitti and seb128 and, god, lots of others: PING
<seb128> directhex: (I don't reply to contentless questions on IRC)
<directhex> seb128, you've got your fingerprints over f-spot in ubuntu. i'm trying to make tomboy/f-spot people aware that the upcoming mono transitions in debian will completely break building packages, without changes to build-deps
<seb128> directhex: why would they do that?
<james_w> mDuff: hi, if you subscribe the "ubuntu-main-sponsors" team then someone will look at it. Providing debdiffs that showed the exact changes would help the sponsors review, but isn't required.
<directhex> seb128, because the changes are needed to significantly shrink the dependency chain of produced packages
<seb128> directhex: we will figure than in jaunty anyway, I don't think mono is synced directly so whoever does the merge should figure what to do
<mDuff> james_w, thanks
<directhex> seb128, sync. been working to allow mono to be synced rather than merged.
<directhex> that's another incoming change
<seb128> directhex: ok good, seems you have things under control
<EspadaV8> hey, just been told to try here instead of #ubuntu...
<EspadaV8> basically, i'm trying to get my Qt4 app to compile on ubuntu, i works fine on gentoo (what i developed it on) but on ubuntu it doesn't like a #include <phonon>
<EspadaV8> anyone know what i should be including instead?
<EspadaV8> or what needs to be apt-get'd to provide it?
<directhex> seb128, ... mostly. it's gonna end up in experimental for now. the lagging release of lenny is unfortunately timed for jaunty - but jaunty will look bloody stupid if it ships with the same old release of mono as intrepid
<seb128> directhex: I would say most users don't care about mono but having it updated would be nice indeed
<directhex> seb128, it's attractive for windows developers
<seb128> directhex: right, what I said, users usually don't care ;-)
<directhex> seb128, about as much as they care about having the latest & greatest python release, i.e. a few users will bitch & whine, most won't care
<seb128> directhex: seeing the number of duplicate and comment on the request to update the version it just doesn't seem to have a real traction
<seb128> directhex: right, anyway this discussion has no real interest, having mono updated would be nice indeed
<directhex> k
<seb128> directhex: experimental is not autosyncing so we will not sync anything by mistake when jaunty opens anyway
<seb128> directhex: if you are looking at what debian is doing just ask for syncs when you think the packages are good to be synced, transitionning early in the cycle is better than late that gives time to do the transition
<psusi> TheMuso: are you the original author of isw-raid10-nested.dpatch in dmraid?
<directhex> seb128, i'll request it when i think it's ready. of course, that's all for mono 2.0 - 2.2 is relased in december -_-
<seb128> directhex: will the packaging need to change a lot between those versions?
<directhex> seb128, we hope not, but upstream can be a little erratic. we don't think so, barring unforseen changes
<seb128> ok good, let's see than, thank you for letting us know about the coming changes
<seb128> not something for today in any case and it's late enough to stop working ;-)
<seb128> bbl
<directhex> seb128, forewarned is forearmed.
<cjwatson> Keybuk: I think I know which bit you mean and I think I said exactly the same thing to Kirsten in the cinema :)
<trv> does anybody know why linux-image-debug in intrepid is for 2.6.25 kernel and not 2.6.27? i want to find the vmlinux file for the current kernel
<cjwatson> it moved to ddebs.ubuntu.com, I believe
<cjwatson> so I'm told anyway; not a kernel hacker
<Keybuk> it did
<Keybuk> despite being a dependency and build-dependency of things in the archive
<trv> thank you
<trv> there are too many things pointing to the old kernel
<trv> like linux-image-i386
<trv> and stuff like that
<TheMuso> /c/c
<psusi> TheMuso: are you the original author of isw-raid10-nested.dpatch in dmraid?
<TheMuso> psusi: No it was taken from mandriva.
<TheMuso> As noted in an earlier changelog entry when the patch was originally included.
<psusi> ahh... I think I found the problem with it but I'm trying to understand the patch better before I'm sure
<wasabi> Think apport is ever going to be useful to enable in releases?
<wasabi> Like, is anybody actively working on automatic duplicate collapsing?
<Keybuk> wasabi: I don't think it'd ever be useful
<Keybuk> we don't actively fix bugs in our releases once they're out
<Keybuk> our focus is always the next release
<wasabi> That is true. I do think collecting stack traces is useful though.
<wasabi> I mean, MS does some amazing stuff with their error reporting data.
<wasabi> Analyzing trends over time, etc.
<trv> ok, can't find the vmlinux image at ddebs.ubuntu.com either.. does anybody know where can one find the vmlinux images for our kernel?
<bryce> wasabi: there is risk that the added noise would just dilute the bugs that we can fix
<wasabi> I agree. I was just wondering if it's been considered.
<bryce> esp. for packages not actively triaged
#ubuntu-devel 2008-11-04
<mrintegr1ty> Hi, what is the name of the script / app used to create the jauntyReleaseSchedule?
<Keybuk> Steve Langasek
<mrintegr1ty> is it built into launchpad?
<directhex> yes, he is
<cjwatson> actually this time round it was me ;-)
<cjwatson> I copied it from IntrepidReleaseSchedule and edited it
<cjwatson> no script involved
<mrintegr1ty> cjwatson: lol ok
<Keybuk> previously it's generally been me
<cjwatson> as you can tell from the way I typoed 2008 for 2009 in a number of places
<directhex> so slangasek is NOT built into launchpad?
<mrintegr1ty> cjwatson: lol, so it's just manual ish html then?
<slangasek> no, but I've got some interesting IRC integration features
<TheMuso> lol
<mrintegr1ty> cjwatson: btw, the "download ical" links dont work
<cjwatson> mrintegr1ty: yes, Steve hasn't created the jaunty .ics yet
<mrintegr1ty> ok np
<slangasek> hrm, I haven't, have I
<cjwatson> mrintegr1ty: I believe that UbuntuReleaseSchedule.ics is up-to-date though
<cjwatson> ish
<cjwatson> mrintegr1ty: just manual wiki notation
<slangasek> UbuntuReleaseSchedule.ics should be fully up-to-date
<slangasek> if it's not, I'm not aware of it
<cjwatson> I hadn't checked it to see how much detail was there
<cjwatson> e.g. DebianImportFreeze which I made up following the last discussions we had
<cjwatson> (and which probably shouldn't be final as it stands)
<mrintegr1ty> im at work just now, trying to open the ics in outlook gives an error (what doesnt give an error in outlook)
<mrintegr1ty> so I cant check it just now
<cjwatson> jaunty opening status: glibc built everywhere, running publisher by hand, will accept dpkg and debhelper after that
<jdong> coolness :)
 * wgrant celebrates.
<jdong> multimedia crack any second now... :)
<cjwatson> you overestimate the speed of the publisher
<ajmitch> jdong: restrain yourself
<jdong> cjwatson: hehe and you overestimate the speed of me finishing this homework that's due tomorrow :)
<slangasek> cjwatson: yeah, DIF isn't included on the main Ubuntu Schedule
<cjwatson> slangasek: ok
<cjwatson> slangasek: I thought you were still supposed to be on holiday. :)
<slangasek> I am
<cjwatson> /kick slangasek excessive work
<slangasek> but I appear to have not taken adequate steps to disable IRC highlighting :-)
<Keybuk> cjwatson: you're not his boss anymore ;)
<cjwatson> true :)
<lamont> DIF?
<slangasek> DebianImportFreeze
<cjwatson> http://launchpadlibrarian.net/19314713/buildlog_ubuntu-jaunty-powerpc.dpkg_1.14.22ubuntu1_CHROOTWAIT.txt.gz argh
<StevenK> cjwatson: You fixed that problem on sparc, and now it pops up on powerpc?
<cjwatson> it's just not my day
<cjwatson> I don't understand how glibc built though ...
<Hobbsee> Oh dear.  I have a SRU to push.  it's 200 lines.
<cjwatson> ah. when building glibc, powerpc didn't upgrade libc6 for some reason
<cjwatson> that's really annoying
<cjwatson> infinity: I'm going to need another manual bootstrap, sorry :-(
<Yasumoto> hey guys, if someone has some time, would you mind making sure I've got https://bugs.launchpad.net/bugs/272316 set up right so far? thanks! :)
<ubottu> Launchpad bug 272316 in libgnomecanvas "[regression, intrepid] redraw problems, patches from fedora" [Low,Confirmed]
<cjwatson> infinity: /wg 83
<cjwatson> (oops, sorry)
<cjwatson> infinity: please bootstrap glibc/2.8+20081027-0ubuntu6/powerpc as with sparc - sorry again, I owe you a beer
<lukehasnoname_> bug #286175
<ubottu> Launchpad bug 286175 in fontconfig "evince crashed with SIGSEGV in FcConfigSubstituteWithPat()" [High,Confirmed] https://launchpad.net/bugs/286175
<wgrant> bug #1
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Won't display info)
<Hobbsee> bug 218958
<ubottu> Launchpad bug 218958 in konversation "konversation defaults to #debian/irc.debian.org if kubuntu-default-settings is not installed" [High,In progress] https://launchpad.net/bugs/218958
 * Hobbsee uploads her first package to jaunty.
<infinity> cjwatson: Will do when I'm back from family time.
<dholbach> good morning
<kirkland> pitti: hey, i subscribed you to https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/259631
<ubottu> Launchpad bug 259631 in ecryptfs-utils "Cannot open Private directory after a reboot when "Automatic Login" enabled" [Medium,In progress]
<kirkland> pitti: i spent pretty much all day today refining the debdiff attached there
<kirkland> pitti: i'd like to review that with you at some point, but i think it's just about ready for -proposed
<kirkland> pitti: i'm going to catch some zzz's now.  will ping again in the morning.
<soren> kirkland: Why do you put a .desktop file in /usr/share/app-install?
<pitti> Good morning
<Hobbsee> hey pitti, the SRU man!
<pitti> kirkland: awesome, thanks
<siretart> kees: would you mind committing your latest cryptsetup upload to bzr?
<emgent> morning
<Hobbsee> thanks pitti
<mdke> if anyone has any idea what this error is or what is causing it - http://launchpadlibrarian.net/19268761/hiba.png - please post it to bug 292959
<ubottu> Launchpad bug 292959 in ubuntu-docs "ubuntu-dokcs error code" [Undecided,New] https://launchpad.net/bugs/292959
<pitti> kirkland: I reviewed and replied in the bug report
<pitti> Keybuk: hm, why isn't MoM generating .patch files for the Debian update any more?
<pitti> Keybuk: of all the output MoM generates, the Ubuntu and Debian patches are the two that I actually use :)
<ido_> can any one help me with guidelines on how to start developing for ubuntu ?
<ido_> eg, is there a repository which I can work with to get the sources
<ido_> how to compile, etc..
<pitti> Keybuk: hm, seems that some are missing the ubuntu .patch
<pitti> Keybuk: e. g. http://merges.ubuntu.com/a/autogen/ just has the ubuntu patch, while http://merges.ubuntu.com/a/asciidoc/ just has the debian one
<stefanlsd> ido_: Have a look at https://wiki.ubuntu.com/ContributeToUbuntu
<persia> ido_, Also, you'll want to ask in #ubuntu-motu : such discussions are more on-topic there.
<stefanlsd> ido_: If you would like to contribute with dev specifically, have a look at https://wiki.ubuntu.com/MOTU/GettingStarted
<stefanlsd> or as persia says, come visit us in #ubuntu-motu     :)
<pitti> mvo: can you please set the correct task for bug 293486? is that for hardy?
<ubottu> Launchpad bug 293486 in update-manager "installed 'postgresql-plperl-8.1' prevents upgrades" [Medium,In progress] https://launchpad.net/bugs/293486
<mvo> pitti: its intrepid, sorry
<mvo> pitti: I added a milestone, but not a correct task, fixed now
<pitti> mvo: ah, since the test case speaks about gutsy and hardy
<mvo> pitti: yeah - its probably uncommon, just for people who kept the package around
<mvo> pitti: ups, I accidently subscribed bug #293497 to ubuntu-sru (its universe) - please ignore, I seem to be unable to unsubscribe you again
<ubottu> Launchpad bug 293497 in psad "package psad failed to remove : find: `/var/run/psad/': No such file or directory" [Medium,In progress] https://launchpad.net/bugs/293497
<pitti> mvo: that's fine, don't worry
<cjwatson> infinity: any word on that bootstrap?
<Hobbsee> Is there any way that the debian-installer can be told *not* to install
<Hobbsee> recommends yet apt is configured to install recommends by default?
<Hobbsee> cjwatson: can ^ be done?
<Hobbsee> (by preseed or something, i guess)
<cjwatson> not really
<directhex> ehm... debian does that already iirc
<directhex> which is why tomboy isn't installed by default from d-i installation
<directhex> i think tasksel is to blame
<cjwatson> directhex: I mean that the way Ubuntu is set up it's not really possible to disable that
<cjwatson> tasksel is not to blame
<directhex> right.
<cjwatson> Ubuntu's Task: fields are generated including Recommends
<cjwatson> there's no real way to filter out "what would Task: have been if Recommends: were not included?"
<Hobbsee> right
<Hobbsee> Someone really needs to go thru the seeds, throw everything that isn't required for running an ubuntu desktop to recommends, and remove a lot of cruft from this bugtracker - hitting most ofit with the wontfix stick.
<Hobbsee> Only problem is, it'll require someone who knows close to everything to know if things are valid or not
<Pelo> anyone home ?
<Pelo> how do I switch text editor in cron , I'm stuck in vi since the upgrade
<directhex> update-alternatives --config editor
<stefanlsd> Pelo:  update-alternatives --config editor
<directhex> i win!
<stefanlsd> hehe
<Pelo> stefanlsd, I put that in the terminal ?
<cjwatson> with 'sudo' in front of it, yes
<directhex> are you sure you weren't looking for #ubuntu ?
<Pelo> thanks guys been driving me nuts
<cjwatson> and indeed, you wanted #ubuntu not #ubuntu-devel
<Pelo> directhex, , but stefanlsd used my nick , so he's the first one I noticed
<Pelo> directhex, no , I asked there first , but trust me this is out of the usual stuff dealt with there
<Pelo> thanks guys
<Riddell> mvo: I got a fix for bug 291115, shall I upload as a SRU?
<ubottu> Launchpad bug 291115 in update-manager "[kde] Kubuntu Update Manager crash problem with Turkish language" [Undecided,Triaged] https://launchpad.net/bugs/291115
<mvo> Riddell: I just did a sru upload, just add your fixes to the intrepid branch and upload a new version I think
<mvo> Riddell: or let me re-upload it if it was not accepted for the sru yet
<Pelo> hello again ,
<Pelo> no luck , stick stuck in vi
<cjwatson> Pelo: in future, please don't use #ubuntu-devel just because #ubuntu was unable to answer your question.
<Riddell> mvo: nothing recent in bzr
<cjwatson> Pelo: this is not an escalation channel for hard questions.
<cjwatson> it is a developer channel
<Pelo> cjwatson, I'm aware of that
<cjwatson> please don't ask, then
<Riddell> mvo: oh yes there is, just the date in the changelog is old
<Pelo> but this is a rather pointed one and I've been looking for cron channel and answers elsewhere for several days
<Riddell> mvo: so I'll reject the one in intrepid-proposed unapproved and commit my fix to .33
<cjwatson> Pelo: https://answers.launchpad.net/ubuntu
<mvo> Riddell: please do, I will then re-upload
<mvo> Riddell: just let me know when the commit is done
<cjwatson> Pelo: or the forums. but not here, please.
<Hobbsee> Pelo: or forums.
<Hobbsee> ^5 cjwatson
<Pelo> ok I'm out
<Riddell> mvo: Committed revision 1152
<mvo> Riddell: thanks, you put it into the "main" branch, I will merge into the "intrepid" branch
<Riddell> mvo: oh sorry, didn't know it had branched
<mvo> Riddell: no problem
<kirkland> pitti: cool, thanks for the review, i'm fixing the issues you raised now
<kirkland> pitti: i dropped the gksu check & usage in favor of the command line bit;  that allows me to have the same code usable across desktops & from the command line
<jdong> great... I lured myself into replying to a shirish e-mail
<ogra> have fun then :)
<jdong> "You might also be able to find the firmware file at this link.. but for possible legal reasons (?) I wouldnât know anything about that."
<jdong> "this link" is mediafire
<jdong> what the *HELL*?
<jdong> does anyone actually look over Planet's contents?
<jdong> "note: if you are using Ubuntu 8.04 âHardy Heronâ you can use the isight-firmware-tools package from the intrepid repositories."
<jdong> *blink*
<kees> siretart: ah! yeah, sorry about that.  fixed now.
<mvo> seb128: is that a common one? I can run my autotest magic to see if I can reproduce it
<seb128> mvo: no, I had a quick glance to the postinst but it looks correctly
<mvo> seb128: ok, I let a auto-test run and will check the result when it finishes)
<seb128> mvo: danke
<kwwii> can anyone confirm bug #293482 ? seems really funky that nobody else has noticed it but the reporter says it happens on both update and fresh install
<ubottu> Launchpad bug 293482 in human-theme "DarkRoom theme no longer dark!" [Undecided,Incomplete] https://launchpad.net/bugs/293482
<ogra> kwwii, my darkroom looks like before ... all whips in place still
<liw> kwwii, my darkroom theme is fine here
<ogra> kwwii, that looks like a broken gnome-settings-daemon
<ogra> or a not properly running one
<kwwii> ogra, liw: thanks...that is kinda what I thought as well
<tedg> gnome-settings-daemon has started dying for me again.  I uninstalled libvisual-plugins, but that didn't help this time :(
<theterl> HGello , I am a programmer who knows what to do with xorg.conf files, and I am having a lcd refresh rate problem that needs fixing like,now... Also. #ubuntu didn't know what to do with me. I realize I should file a bug report in launchpad, but I am too lazy/coding a program right now.  Does a fix exist yet for LCD monitors locking up when full-screen 3d programs are launched?
<theterl> this.lblHeading.Text = "\"PLSPLSPLS!\"";
<Caesar> Could I get a wee bit of sponsorship on #293705 if possible please?
<Adri2000> Caesar: subscribe ubuntu-main-sponsors
<Caesar> ooh
<Caesar> Adri2000: is there a ubuntu-universe-sponsors as well?
<Adri2000> yes
<Caesar> Sweet!
<theterl> Ok I tried to get this problem fixed in nvidia and xorg as well as #ubuntu
<theterl> Will someone tell me if there is a workaround to prevent "input out of range" on lcd monitors when running full-screen 3d apps
<theterl> I've done everything I know to do to xorg
<tseliot> theterl: maybe try asking here? http://www.nvnews.net/vbulletin/forumdisplay.php?f=14
<theterl> good try.
<theterl> I have gone there.
<bsnider> tkamppeter, printing is broken for a lot of people in intrepid. in my case it seems to be the pstopdf filter
<theterl> I just want ONE thing I can change
<theterl> this has NOTHING to do with xorg
<theterl> Nothing to do with nvidia
<theterl> this has to do with the way a linux distro allows a program to alter refresh rates
<theterl> if I could go case by case and modify the .config files for the programs, I would
<theterl> unfortunantly, they seem not to exist for the particular examples I have been testing
<theterl> um, I expect you all to stop what you are doing and fix this?
<theterl> No more releases till this is fixed. Stop the presses, delay 9.04 till 2010, and forget about everything besides fixing little terlies problem.
<theterl> or I am going to try to cout this room into /dev/null and see what comes out
<theterl> probably the beast
<Treenaks> theterl: this is not a support channel, so please
<theterl> is this a support channel for programmers?
<tjaalton> no
<theterl> how about for college students?
<Mithrandir> nope, this is a discussion channel for Ubuntu development.
<theterl> well I'm developing support for a problem.
<tjaalton> a problem in a binary blob?
<theterl> NOpe.
<Mithrandir> what is the problem, then?
<tjaalton> sounds like it
<theterl> Scroll up?
<tjaalton> I did
<theterl> I will give you the very basics.
<theterl> FretsonFire.
<Mithrandir> that opengl apps can request fullscreen mode and the X server changes to it, even though the monitor doesn't support that mode?
<theterl> right
<tjaalton> driver problem
<theterl> driver.
<tjaalton> blame nvidia
<theterl> blame nvidia.
<theterl> *jaw drops*
<Treenaks> theterl: they probably have a 'contact' form on their website
<theterl> blame the god of computing.
<Mithrandir> I don't think I can reproduce that on my intel laptop, at least.
<azeem> I had the issue on my Radeon
<azeem> at least, I think it was the same issue
<theterl> Drivers now?
<theterl> azeem did you find a fix0r?
<Mithrandir> what are the steps to reproduce it?
<azeem> theterl: yes, but it's off-topic here so I can't disclose
<Mithrandir> and what's the bug number?
<theterl> *I* am off topic.
<theterl> reproducing the problem is as simple as finding a 15 inch lcd monitor, hooking it to a desktop machine running ubuntu intrepid...
<theterl> wait...
<ogra> bugs are a good way to discuss such issues, if you give your bug number to azeem he can add his info
<theterl> I think I may have something.
<theterl> azeem, were you using a vga cable?
<tjaalton> I have a 24" lcd monitor and no such problems (nvidia)
<theterl> because this is vga>lcd setup.
<theterl> tjaalton are you using DVI?
<tjaalton> of course
<Mithrandir> finding a 15" monitor here would be somewhere in the range of "impossible". :-P
<theterl> ok so this is probably lcd spefic
<theterl> yes mithrandir I know you are FILTHY rich
<bsnider> it has nothing to do with money. they're not being made anymore
<tjaalton> the driver is forcing a mode which the monitor can't handle, so yes, it's a driver problem..
<theterl> no more coding on a lisp machine with font color set to black for you
<theterl> it's probably just because I am having to use VGA with an lcd.
<Mithrandir> theterl: 15" monitors probably cost more than 20" monitors those days.
<theterl> I still say a dell triniton crt is the best monitor ever.
<theterl> 4000 luminscense.
<bsnider> with sony guts?
<bsnider> i had one of those. it had a manufacturing defect. the 1110
<tjaalton> the driver might not get the specs via vga..
<theterl> that's probably half the issue.
<ogra> who knows ... if its nvvidia, only nvidia can tell
<theterl> but, I still ask..
<theterl> is there a userland way to force my games and programs to respect xorg settings?
<ogra> yeah, ask them
<theterl> because xorg as you can see is working fine.
<tseliot> theterl: without a bug report and an attached log it's hard to guess the cause of your problem
<tseliot> please file a bug report on launchpad
 * tseliot > dinner
<theterl> I didn't ask you to find the cause.
<theterl> I just said make my system OBEY THE HYPNOTOAD
<theterl> https://bugs.launchpad.net/ubuntu/+bug/293739
<ubottu> Launchpad bug 293739 in ubuntu "Input Signal Out of Range(Specific to Full-Screen Apps)" [Undecided,Confirmed]
<theterl> here.
<theterl> no flaming now.
<tjaalton> theterl: right, force HorizSync/VertRefresh in the xorg.conf.. but hey, you already knew that?
<theterl> yes I did.
<theterl> I set both of those parameters in that manner and also tried modelines.
<kees> james_w: what's the state of the s-t-b update?
<james_w> kees: I was going to ask you whether you wanted it as -security or -proposed?
<kees> james_w: -security please
<kees> well
<kees> hm
<kees> yeah, security
<james_w> ok, I'll work on that tomorrow
<kees> james_w: I guess what I should ask is, is your diff the final version of the fix?  seems workable to me.
<kees> james_w: because if so, I can just upload it immediately.
<james_w> ah, I don't think I finished testing
<james_w> and it doesn't have the requisite changelog format
<kees> s'okay, it's really a regression more than a vuln fix.  I'm fine with the changelog as-is.
<james_w> ok, I'm sure you want it tested though :-)
<kees> that I do.  :)
<kees> james_w: initial testing seems fine to me.  :)
 * NCommander is mulling over making a second attempt to PIE build the archive
<james_w> kees: oh, if you are willing to test then go ahead.
<tkamppeter> bsnider, what exactly goes wrong for you?
<bsnider> tkamppeter, well, nothing actually works. the printer is set up apparently using the correct driver, but i can't clean the heads, i can't print a test page, i can't print anything from any app etc. the typical error message is "/usr/lib/cups/filter/pstopdf failed"
<bsnider> the last cups update involved a change to that filter
<tkamppeter> bsnider, can yoiu set CUPS into debug mode (server settings in s-c-p, last item) and then try printing again to see whether there are more messages from pstopdf?
<bsnider> yes but unfortunately it doesn't actually say why the filter is failing
<tkamppeter> bsnider, can you tell me which PPD you have used and which files you tried to print? Also which paper size you have used?
<tkamppeter> bsnider, the best is you create a bug report on LP with all this info. Also with attached error_log. This would help me to reproduce the problem.
<tkamppeter> bsnider, and did the problem not occur before the last CUPS update?
<bsnider> i've tried to print office documents, pdfs, odt files, and text files from different programs. the ppd is whatever is set up by default to use with this epson cx4200 paper size is 8x11
<bsnider> the problem is that there are several bug reports, the one i've commented on has not been owned yet
<tkamppeter> bsnider, can you tell me the bug numbers?
<bsnider> i've contributed to bug 289759
<ubottu> Launchpad bug 289759 in cups "cups kyocera" [Undecided,New] https://launchpad.net/bugs/289759
<bsnider> there are 3 or 4 others that i was looking at today that are along the same lines. this problem did not exist prior to the last cups update
<bsnider> there's 271350 which you've been contributing to
<tkamppeter> bsnider, can you print a PDF or JPG directly with the lpr command, without GUI app? Or can you try to print an image from the GIMP, using the standard print dialog, not the Gutenprint one? Can you print this way?
<bsnider> there's also 286456 and 283605
<bsnider> i haven't used lpr since college. what's the command going to be?
<tkamppeter> lpr simply sends a file to CUPS so that CUPS prints it. This way you can make CUPS do all file conversions without a GUI app converting everything to PostScript at first.
<bsnider> so it's lpr filename?
<bsnider> that's what i meant. usage
<tkamppeter> Yes.
<bsnider> tkamppeter, lpr also fails
<tkamppeter> bsnider, with non-PostScript files? What does your error_log tell then? In this case pstopdf will not be used.
<bsnider> there's some nonspecific errors
<bsnider> Ghostscript 8.63: Unrecoverable error, exit code 1
<bsnider> not that that says much
<bsnider> tkamppeter, there's no indication of any error in the log when i try to print from lpr but the cups admin page says "device busy"
<tkamppeter> bsnider, can you do "cancel -a" to clean up after the failed jobs and then try with lpr?
<Reenen> lo everyone... sorry, for coming in here, but I think the question needs some developer insight... on Lazarus (Free Pascal) "copy" / "cut" suddenly crashes (since 8.10).
<Reenen> did the clipboard behaviour change in 8.10?
* cjwatson changed the topic of #ubuntu-devel to: Archive: Jaunty open, go wild! | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
 * Laney dances
<jdong> did someone say svn checkouts of x264, xvid, ... ..?
<jdong> </joke>
<fta> my 1st breakage with jaunty: http://paste.ubuntu.com/66315/  i used to be able to run this python script to update some mozilla sources, now, it fails (while it's still ok in intrepid/hardy).
<cjwatson> impressive given that hardly anything has changed yet
<fta> tried with both hg 1.0.1 (same as intrepid and the new one 1.0.2)
<cjwatson> looks likely to be a coincidence, to me
<fta> 100% reproducible
<cjwatson> the only thing that could possibly be related is libc6
<fta> indeed
<cjwatson> and you'd need to delve a bit deeper to find out why that's causing a python tuple to be a different length!
<cjwatson> anyway, TV time
<fta> :)
<madmac2501> hi, i do sudo apt-get build-dep gstreamer0.10-plugins-bad but it says that libcelt-dev version dont satisfy requirements
<jdong> fta: btw, driveby ping: Do we have an up to date bzr branch for firefox's hardy-security packaging?
<madmac2501> how do i install the rest of libraries?
<jdong> fta: I have backports of hardy-security -> gutsy-backports but I'd like to coordinate that with a bzr branch before we end up diverging left and right :)
<fta> jdong, i did a backport the other way around, ie, from intrepid/hardy (it's the same branch) to gutsy
<fta> jdong, it's fine for xul, but for ff, it needed more work as ff2 is still the default in gutsy
<fta> jdong, and it introduced abrowser too, not sure it's wanted/wise
<fta> so basically, i stopped there
<jdong> fta: ah, well my h-s backport preserves FF2 as the default browser like the previous backport
<jdong> fta: I basically diffed hardy against hardy-security and rebased that diff on top of the old gutsy-backport
<jdong> fta: the result is in the backporters PPA and from my tests it doesn't look too bad
<jdong> I just wanna get something out that's not beta3 in gutsy-backports before we call it a day with gutsy :)
<fta> jdong, i see. well, i don't mind. your way or mine, both are fine to me. if you're done, please go ahead.
<fta> as i said, i still have to drop a few thing from ff3 so i'm not done.
<fta> thingS
<jdong> fta: ok, I'll do a bit more testing and probably push that out. I spent a lot of time on the original gutsy backport and had a huge QA effort to make sure it cooperated correctly with existing Firefox, so I feel personally a bit more confident with my approach for now
<jdong> fta: just wanted to make sure I wasn't diverging too much from Mozilla team
<fta> jdong, don't worry, i'm all fine dropping my branches. if you have a debdiff, i could sure give it a look
 * NCommander dist-upgrades to jaunty
<NCommander> wooo
<jdong> fta: the debdiff would be from https://edge.launchpad.net/~ubuntu-backporters/+archive to hardy-security. There's no changes that I've introduced since the original beta3 backport that asac reviewed and coordinated with me
<psusi> is it just me or are a lot of users being plagued by some sata breakage in intrepid?
<TheMuso> psusi: In what way?
<psusi> TheMuso: I'm working a thread in the forums where several people get dropped to a busybox promt trying to boot, and I think there was another massive one with people having that, but they appeared to be blaming the video aperature being over 4 gb since that was the last thing they saw
<psusi> and it looks like under the new kernel it fails their ata links so they have no root device
<NCommander> That's usually a problem when the drive fails to spin up
<NCommander> ScottK has a similar issue
<ajmitch> wasn't there something mentioned in release notes, or was I dreaming about that?
<ajmitch> bug 290153
<ubottu> Launchpad bug 290153 in ubuntu-release-notes "Fails to find boot device in Intel D945Gnt" [Undecided,Fix released] https://launchpad.net/bugs/290153
<asac> jdong: fta: could we please make a decent branch out of it this time?
<asac> jdong: fta: it just better scales and wont fall off our radar that easily in future i hope
<fta> asac, you know i have branches for everything ;) here, it's not my call
<TheMuso> psusi: re dmraid and the initramfs script, using dmraid via udev relies on vol_id to identify dmraid arrays. Unfortunately it can't identify newer VIA and possibly other types or metadata. What really needs to be done is link vol_id against libdmraid and use dmraid to do the identifying. The script is a catch-all for those arrays that are not detected via vol_id/udev.
<psusi> TheMuso: ahh.... or what about not using vol_id but rather call dmraid and ask it to identify the disk... if it claims it, flag it as a raid member?
<TheMuso> psusi: Possibly, but that is code duplication to an extent, and another wrapper script would have to be written to make sure the udev environment for that disk node is updated. I think its much cleaner to get vol_id using dmraid's library instead.
<psusi> that would make it depend on dmraid then...
<TheMuso> Yes so?
<psusi> hrm... maybe it could link statically for the udeb
<TheMuso> No need, as the dmraid library is in udeb form.
<psusi> err... hrm.... I'm just thinking it's a waste to have the whole libdmraid in the initramfs on systems that don't have dmraid installed
<TheMuso> I split dmraid into a library and a command-line binary for this very reason.
<TheMuso> This is true.
 * psusi shrugs.... not a big deal I guess
<psusi> hopefully some of those with the isw bug will find my ppa package fixes it and we can get that into -updates
<psusi> then I'll have to poke debian and mandriva
<TheMuso> I can poke debian easily enough, I am in contact with the debian dmraid maintainer, even have svn upload access to the dmraid packaging.
<psusi> might want to update the control headers to point to that svn then isntead of bzr
<psusi> and it looks like rc15 will supersede that patch anyhow
<jdstrand> slangasek: hi! can you reject apparmor 2.3+1289-0ubuntu4.1 that was uploaded (and unapproved) in intrepid-proposed?
<jdstrand> slangasek: upstream updated their patch and I'd like to use it instead
<slangasek> jdstrand: sure, done
<TheMuso> psusi: Yeah I am actually hoping that dmraid for jaunty will be a sync at this point, once a few things are checked.
<jdstrand> slangasek: thanks. btw, can I upload with the same version number?
<slangasek> jdstrand: yes
<jdstrand> excellent
<slangasek> (that's possible even if you don't get the first one rejected out, it just gets confusing in that case because only one of them can be accepted :)
<kjohansson> Hello, I have an application which is dynamically linked against libQtCore.so (and others). This lib is in the standard system directories. I want to override this lib with another libQtNewCore.so. Is it possible to rename the new lib or put it into LD_LIBRARY_PATH, so that it will be used by every app that links libQtCore.so?
<jdstrand> slangasek: good to know. thanks! :)
<kjohansson> My attempts show that LD_LIBRARY_PATH is searched after /usr/lib. Can I change this order?
<slangasek> kjohansson: that's inconsistent with my understanding of the linker; are you sure you don't have a binary with RPATH set?
<slangasek> (a trivial test here shows LD_LIBRARY_PATH being checke first)
<kjohansson> strange. Can you shortly explain how the RPATH would change this order and how I can check it?
<slangasek> kjohansson: objdump -p /path/to/binary | grep RPATH; RPATH takes precedence over everything else
<kjohansson> RPATH is kind of hard coded LD_LIBRARY_PATH?
<slangasek> basically, yes
<kjohansson> slangasek: you were right. the objdump command shows an RPATH within the app installation path, where a second set of Qt libraries live. Any chance to override the RPATH?
<slangasek> kjohansson: only by editing the binary
<slangasek> there's a utility, 'chrpath', that lets you wipe out the RPATH value
<kjohansson> many thanks. I'll learn about RPATH and its utilities.
<Laney> kjohansson: http://wiki.debian.org/RpathIssue
<kjohansson> Laney: I'll need some time to study that link. But in "The Problem - Dynamic Linking" it says, that LD_LIBRARY_PATH is search _before_ RPATH? Is this correct?
<mohbana> hi, so i've installed open-jdk
<mohbana> i'm just wondering, where is the api installed them?
<Keybuk> pitti: it should be, is it missing for all packages or just particular missing ones?
<jordi> TheMuso: hey
<TheMuso> Hey jordi.
<TheMuso> jordi: I see that alsa bits are not in experimental, but wondering whether you guys have prepared tarballs yet.
<TheMuso> TO base your alsa uploads against.
<jordi> TheMuso: ha
<jordi> TheMuso: I just mailed you re: that
<jordi> to your themuso.com address
<TheMuso> jordi: Oh ok thanks.
#ubuntu-devel 2008-11-05
<asac_> fta: it is your call :)
<mohbana> does flash work?
<jdong> no. we specifically put in some code to break it because it'd be funny to watch 30 million people install it and scratch their heads.
<mohbana> ok bug dound
<samtb2> hi there. ant in intrepid seems to depend on gcj even though i have openjdk installed. is this correct? am i supposed to ignore dependencies or something or just install gcj too?
<jibel> ScottK: Hi, the bug with pycentral in bug 293208 is the way dist-upgrade of python-modules are handled by pycentral
<ubottu> Launchpad bug 293208 in python-central "package python-reportlab 2.1dfsg-2 failed to install/upgrade: " [High,Triaged] https://launchpad.net/bugs/293208
<jibel> ScottK: mvo and pitti have discussed about it in bug 291262
<ubottu> Launchpad bug 291262 in python-central "package python-psyco 1.6-1 failed to install/upgrade: pycentral pkginstall: not overwriting local files" [High,Triaged] https://launchpad.net/bugs/291262
<Keybuk> pitti: hmm, seem to be hitting a large number of archive 404s :-/
<Keybuk> elmo: around?
<elmo> yeah
 * cjwatson starts to flush out syncs, at least as far as the autosyncer managed to get before falling over
<Keybuk> elmo: is there an internal archive casey should use instead of archive.u.c ?
<elmo> Keybuk: what's wrong with archive.u.c ?
<Keybuk> elmo: it keeps 404ing
<elmo> checking
<Keybuk> as if Packages is being updated but not pool
<elmo> nah, a couple of machines are out of sync
<elmo> due to trigger hoarkage, I'm ficking it
<wgrant> cjwatson: Are we expecting queue-builder to collapse again this time, meaning buildds sit idle for hours, or is that fixed?
<Keybuk> I'm sure whatever bug we hit last time is fixed
<cjwatson> wgrant: I have no idea and am not all that desperately worried
<cjwatson> wgrant: we'll find out
<Keybuk> and that we'll find all new bugs this time
<Keybuk> ;)
<wgrant> Heh.
<ajmitch> wgrant: have faith
<LordMetroid> Alright, lets get on deving 9.04
<LordMetroid> But how do a newbie as me go about doing so?
<LordMetroid> I mean newbie to Open Source development
<cjwatson> http://wiki.ubuntu.com/ContributeToUbuntu
<wgrant> ajmitch: Perhaps.
<elmo> Keybuk: all in sync, and should be ok going forward
<Keybuk> thanks
<Keybuk> looks like it ran this time
<LordMetroid> cjwatson: thank you
<slangasek> tjaalton: have you seen bug #283015 by chance?  I see that you've done a lot of the xkb-data uploads
<ubottu> Launchpad bug 283015 in xkeyboard-config "Error in numeric keypad -> "." (dot) key  displays "," (comma) instead" [Undecided,Confirmed] https://launchpad.net/bugs/283015
<Thayle> How do I get involved?
<directhex> Thayle, #ubuntu-motu is best for you
<Thayle> Alright thanks.
<directhex> remember that many people are busy with the election though
<slangasek> with the election, or with the election parties?
<TheMuso> heh
 * ajmitch really should go & vote this weekend then
<slangasek> so you can get your free coffee at Starbucks?
<ajmitch> I doubt they'd do that here :)
<jdong> slangasek: isn't that a felony?
<ajmitch> we have to endure a few more days of campaigning in NZ still
<slangasek> jdong: getting free coffee?
<ajmitch> darn, hardy
<wgrant> What has Hardy done now?
<ajmitch> hardy's debootstrap won't let me create a jaunty pbuilder tarball
<wgrant> Hah.
<wgrant> Symlinks win there.
<ajmitch> haven't upgraded the laptop to intrepid yet :)
<slangasek> ajmitch: pass the extra arg to tell it to use the intrepid or hardy script for building
<jdong> slangasek: it's offering a monetary incentive to vote, is it not? :)
<ajmitch> jdong: I believe they've stopped doing that
<jdong> ajmitch: really? is it for that reason?
<slangasek> jdong: Starbucks actually already got slapped for trying to offer it as an incentive for voting, so they instead changed it to giving free coffee to everyone
<jdong> slangasek: ah, gotcha :)
<jdong> slangasek: sadly I don't have any starbucks around here
<ajmitch> jdong: from what I heard, yes, a number of companies have changed to just giving free stuff/discounts to all
<jdong> ajmitch: haha interesting, I didn't think they'd take that radical reading of election laws so literally :)
<slangasek> jdong: well you're not missing much, it's only brewed coffee that they're giving away :)
<slangasek> also, it's not that Starbucks took the reading literally, it's that the Washington sec of state smacked them
<jdong> slangasek: with that money I can power my car for 0.5 seconds!
 * Keybuk tries to remember what the tomerge files are for
<Keybuk> DaD maybe?
<Keybuk> Adri2000: ?
<cjwatson> ajmitch: I haven't backported that debootstrap yet
<cjwatson> ajmitch: but yes, the jaunty script is just a symlink to gutsy, let alone hardy/intrepid
<ajmitch> yes, I've just put in that symlink for now
<Keybuk> ok, mom's brain wiped again *sigh*
<wgrant> That sounded very strange.
<jdong> wgrant: better than last time we had that mom and dad merging discussion.
<jdong> that sounded much worse.
<wgrant> jdong: Indeed, indeed.
<Keybuk> ERROR:root:dpkg-genchanges for changes/ubuntu/d/dia/dia_0.96.1-7ubuntu1_source.changes failed
<Keybuk> kooky
<Keybuk> right
<Keybuk> let's try a patch publish again
<Keybuk> ok, http://patches.ubuntu.com/ now has correct data I think
<superm1> hum what happened to mom?  did she die?
<Keybuk> she suffered an aneurysm during her move
<superm1> is she talking about moving in with dad again?
<StevenK> Keybuk: MoM moved?
<cody-somerville> Your MoM is so fat... ugh, never mind. :(
<Keybuk> StevenK: casey likes to throw disks
<Keybuk> and when casey isn't throwing disks, mom is filling 'em
<Keybuk> looks like there was more damage from the filled disk than I thought
<Adri2000> Keybuk: yes that was for doing a DaD-like front-end to MoM. iirc I started doing something but nothing was actually finished and published
<Adri2000> I guess you can keep them though, they might be useful for something else in the future
<Keybuk> mathiaz patched them to add more info, so he must be using them for something ;)
<Keybuk> comments support:
<Keybuk> it would be nice to have that as plain cgi
<Keybuk> not being resident in memory would make elmo happier
<Keybuk> right
<Keybuk> let's spin this again and see whether we get merges with patches this time ;)
<Keybuk> ValueError: process failed 17: dpkg-source -x abiword_2.6.4-4.dsc /srv/patches.ubuntu.com/unpacked/a/abiword/2.6.4-4
<Keybuk> GnNNAARRGH
<ajmitch> that's not a useful error to work with
<NCommander> ScottK, hola
<lifeless> Keybuk: :13:57 < nhandler> Is MoM being updated? It only goes up to 'm' right now
<lifeless> :
<lifeless> from -motu
<Keybuk> see above
<lifeless> Keybuk: ah, I only recalled your saying patches should be ok earlier
<lifeless> Keybuk: thanks
<NCommander> wgrant, ping
<wgrant> NCommander: Hi.
<NCommander> wgrant, care to do some upload sponsoring?
<wgrant> NCommander: Sorry, lots of homework.
<NCommander> np
<ScottK> NCommander: Hello.
<NCommander> hey ScottK
<Keybuk> mom working on universe now
<Keybuk> pitti: http://merges.ubuntu.com/a/autogen/ now has both sets of patches ;
<Keybuk> oh, I mean multiverse
* Keybuk changed the topic of #ubuntu-devel to: Archive: Jaunty open, MoM running, go wild! | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Keybuk> ...
<Keybuk> looks like cjwatson did a sync
<pitti> Good morning
<Hobbsee> hey pitti!
<pitti> Keybuk: I noticed some packages which have both patches
<pitti> Keybuk: archive 404> ah, that could be it; I occasionally get that on my box as well, but 5 seconds later it works again
<Keybuk> looked like a combination of factors
<pitti> yay jaunty
<Keybuk> of course, now it has to catch up with the sync
<StevenK> Hey pitti
<superm1> cjwatson, it looks like that task bug won't actually be resolved until soyuz 2.1.11 on at least 2008-11-19.  at least until then would you anticipate any ramifications in switching it back over to calling upon the meta packages in livecd-rootfs?
<superm1> if not, i'll do another upload of livecd-rootfs with that hack in place to do a first alpha, planning to remove it shortly after first alpha
<michael__> MoM?
<bryce> merge-o-matic
<bluefoxicy> damnit
<bryce> iz our lil' friend
<bluefoxicy> I cannot sing Beautiful Dreamer, and I haven't been able to actually record on Ubuntu for like 6 releases
<michael__> cool
<tjaalton> slangasek: aww that one.. yes it was mentioned on another bug that got fixed.. should be simple to fix
<slangasek> ok, cool :)
<pitti> ArneGoetje: intrepid-proposed langpacks copied; however, since the jaunty sync wave is building, too, building the langpacks will take a while
<StevenK> i386      1532 builds waiting in queue
<StevenK> Daaaaaaaaaaaaaamn
<pitti> need more buildds :)
<pitti> unifying the ppa and ubuntu buildds would be great in times like that
<Hobbsee> whee!
<Hobbsee> pitti: does that mean you'll fix your buildd.py script to work for rescores again?  :)
<wgrant> pitti: There are bugs about that, filed by almighty people.
<pitti> yeah, I talked about that with Adam
<liw> pitti, if there was a way to run buildds easily under kvm, perhaps temporary buildds could be arranged for these times
<wgrant> Pooling buildds between the big three archs and PPA/primary would indeed be very nice.
<pitti> and about 800 of those builds are langpacks, which are currently only built by i386 buildds
<wgrant> Hmm, pretty pathetic sync run. Was that incomplete, or are we seeing the effects of the Lenny freeze?
<liw> wgrant, I'm pretty sure we are
<liw> though I can't be bothered to dig up statistics for how sid has changed in the past several months
<pitti> ogasawara: o_O
<pitti> ogasawara: I thought we settled for having just one bug for tracking 2.6.27.y patches, to ease bureaucracy?
<pitti> ogasawara: so from all those invalid bugs I take it that intrepid final already has 2.6.27.2?
<pitti> ogasawara: ah, yeah, that's what the changelog says anyway
 * soren makes a note to remember to upload a new vim with syntax highlighting for Jaunty+1 *before* Jaunty releases
<lasko> *nod*
<Treenaks> soren: current vim doesn't have syntax highlighting?
<lasko> current vim should.
<Treenaks> lasko: *phew* :)
<soren> Not for "Jaunty" in changelogs.
<Keybuk> it does highlight jaunty
<Keybuk> in that oh-so-attractive yellow-on-OMG-red ;)
<soren> Well.. Yes. :)
<lasko> Though... if I remember correctly it requires vim-full?
<soren> No, it's in vim-runtime.
<soren> The syntax definition, that is.
<lasko> ahh
<soren> cjwatson: Are you doing vim already or should I grab it?
<Keybuk> I don't think he's up yet
<pitti> soren: just do it :)
<NCommander> hey soren
<soren> NCommander: ahoy.
<soren> pitti: Will do :)
<pitti> random throught of the day: using vimplate helps a lot for creating debian bugs with ubuntu patches
<NCommander> soren, how goes it this $TIME_OF_DAY
<pitti> soren: which remeinds me that I totally forgot to upload mutt as my first merge; damn
<pitti> oh, we are current, nevermind
<soren> NCommander: I'm not sure, really. I'm rather knackered. I didn't get to sleep much last night.
<soren> NCommander: Yourself?
<sebner> pitti: mighty pitti. mind moving audacious from proposed to updates? bug #291643
<ubottu> Launchpad bug 291643 in audacious "Audacious plays the last playlist instead of the double-clicked file" [Low,Confirmed] https://launchpad.net/bugs/291643
<pitti> sebner: hm, I already went through the list today, that wasn't on my radar
<pitti> sebner: nack; just 2 days old, needs 7
<NCommander> soren, trying to sleep and failing miserably -/
<sebner> pitti: also though I have already 4-5 positive comments?
<soren> NCommander: 'tis easy. Just stop.
<pitti> sebner: it's current policy; we occasionally do exceptions for really grave bugs, where the severity outweighs the risk of regression
<sebner> pitti: Ok Ã see. anyway, thx
<pitti> but it needs explicit justification
<pitti> \sh: heck, what *is* wrong in the picture? :-)
<StevenK> pitti: You don't see it? :-P
<pitti> oh, now I do
<pitti> oops :)
<StevenK> Haha
<Keybuk> that's the australian mirror
<StevenK> Haha
<pitti> Ê×ÊÉÉxÇ
<NCommander> wow
<NCommander> McCain got slaughter
<NCommander> er
<NCommander> wrong channel
<Keybuk> yay, MoM finished
 * Keybuk remembers to unlock her
<StevenK> You lock up MoM?
<Keybuk> sure
 * Keybuk decides that chewing on a permanent CD marker is not such a great idea
 * mvo uploads a jaunty update-manager (for the early birds)
<Hobbsee> oh dear...
<Keybuk> pitti: you leave the Changed-By to be mom?
<pitti> Keybuk: whoops; not usually, that was a brainfart
<pitti> Keybuk: I usually merge by hand, but that asciidoc thing was so simple that I just took MoM's output
<StevenK> pitti: Including "DESCRIBE CHANGES HERE" ?
 * sebner hugs mvo for that :P
<pitti> StevenK: no, the changelog is fine :)
<pitti> but apparently I used "vi", not "dch"
<Keybuk> I often wonder if I made MoM secretly add "THIS PACKAGE WAS MERGED BY AN INATTENTIVE PERSON" to the description, how many people would notice :p
<StevenK> Hahah
 * pitti sighs at the devscripts delta
<mvo> soren: do you think we could make "-net nic,model=virtio" default in the kvm in jaunty?
<mvo> soren: and maybe a bigger default than -m 128 ?
<pitti> mvo: oh, is that the magic incantation to actually get network in kvm?
<Keybuk> and -soundhw all
<Keybuk> and make it somehow magically work on my XPS
<mvo> pitti: for me "-net user -net nic,model=virtio" is the key to get fast networking
<pitti> mvo: well, at first I wanted to get networking *at all*
<mvo> Keybuk: yeah, good point
<mvo> pitti: otherwise its stuck at ~300kb/sec even from a local cache
<mvo> pitti: oh? -net user did that for me, but that is the default AFAIK
 * Keybuk has the only Intel Core 2 Duo without Virtualization support
<pitti> mvo: inside it might work, but at the host I tried to configure pan0 appropriately, and it wouldn't work
<pitti> mvo: simply no ping; and that didn't even get to masquerading or so
<pitti> I ended up kpartx-mounting the image for copying stuff into the vm
<NCommander> Keybuk, nope, I got one too
<NCommander> Yay first generation hardware
<Keybuk> but since it can run amd64, vmware works
<NCommander> Keybuk, wait, if it supports amd64, it should have VTx
<Keybuk> NCommander: tell that to Dell
<NCommander> THe chip supports it
<NCommander> you might need to cox the bios to enable it
<soren> mvo: No.
<Keybuk> NCommander: no vmx in /proc/cpuinfo
<soren> mvo: That would make anything but Hardy and Intrepid fail miserably.
<Keybuk> whereas my Intel Core Duo has vmx in /proc/cpuinfo even when disabled in the BIOS
<NCommander> Keybuk, d'oh
<soren> mvo: (the nic model thing, that is)
<NCommander> Keybuk, what model Dell is it?
<Keybuk> NCommander: XPS m1330
<NCommander> hrm
<NCommander> Keybuk, the m1330 is listed as supporting it
<NCommander> You need a BIOS greater than A2 however
<mvo> soren: oh, ok - that is a good arguement against it ;)
<NCommander> Keybuk, to get it to work on mine, I had to apply a hack to my BIOS :-)
<Keybuk> a hack?
<NCommander> Sony locks out VTx on their chips
<NCommander> YOu have to mod the BIOS to enable it
 * NCommander LOVES playing find the offset
<NCommander> Dell just seems to require a new enough BIOS
 * Keybuk has bios A08
<NCommander> And no VTx ENABLE in the POST menu?
<Keybuk> nope
<soren> Keybuk: vmx capabilities show up in cpuinfo even when disabled in the BIOS. That's expected.
<NCommander> soren, not always
<Keybuk> it's a T5550
<NCommander> Ouch
<NCommander> Ok
<NCommander> Yeah
<soren> NCommander: I've never seen it not happen.
<NCommander> I can't believe they actually shipped a core without VMX which the T5550 is
 * Keybuk has no understanding of Intel product names or numbers
<NCommander> soren, I know on this machine I always had it, it was just a matter of hacking the Phoenix BIOS this POS came with
 * NCommander notes that he got this machine at prices that are disturbing low
<NCommander> Only reason I got a sony
<Keybuk> this was the cheapest on-offer pick from the website
<Keybuk> it mostly runs iTunes and Lightroom ;)
<NCommander> Keybuk, it could be worse
<directhex> when does jaunty go EOL?
<Keybuk> t'other half got the expensive, top-of-the-range 1550
<soren> NCommander: Do you actually have examples of hardware that manages to hide vmx even from cpuinfo when disabled in the bios?
<Keybuk> directhex: two years last thursday
<directhex> soren, yes! this desktop pc does that!
<NCommander> directhex, its a little early for that ;-)
<NCommander> directhex, its a little early for that ;-)
<NCommander> er
<directhex> NCommander, not when warning upstream of which versions of their apps will be shipped
<NCommander> Not offhand sommer
<NCommander> wow
<NCommander> I totally fail Keybuk
<NCommander> wait, no, that was soren
<soren> directhex: Brand?
<NCommander> -ENOSLEEP
<directhex> soren, HP
<soren> directhex: Can I see your cpuinfo, please?
<directhex> soren, i had to actually flash on a replacement BIOS just to get the ability to turn it on
<NCommander> directhex, It has an AMD core, right?
<directhex> NCommander, intel
<NCommander> O_o;
<NCommander> I've only seen AMD's do that
<soren> NCommander: AMD's don't have vmx.
 * Keybuk bestows the Tollef Award for Terseness on mvo
<Keybuk> update-manager (1:0.95) jaunty; urgency=low
<Keybuk>   * updated for jaunty
<NCommander> I meant the equivelent of vmx for AMD
<Keybuk> --
<Mithrandir> NCommander: svm, then
 * soren nods
<directhex> soren, i turned it on in the replacement "vpro" bios: flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
<directhex> soren, the regular bios doesn't have the functionality, full stop
<soren> directhex: So no chance of seeing the full cpuinfo with the regular bios?
<NCommander> soren, some processors only report abilities when they are actually active
<directhex> soren, not unless i boot XP and re-flash
<NCommander> soren, i.e., last time I checked, lm only shows up when my process is actually in long mode
<NCommander> s/process/processor
<directhex> soren, an HP dc7700, if you care
 * mvo happily accepts the award from Keybuk and put it into his trophy glass cabinet
<Keybuk> speech!
<NCommander> soren, you seem suprised that cpuinfo isn't always static
<directhex> soren, http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=3232108&prodTypeId=12454&prodSeriesId=3232029&swLang=13&taskId=135&swEnvOID=1093#120
<directhex> soren, the "HP Compaq Business Desktop System BIOS (786E1 BIOS)" download cannot do vmx
<directhex> "HP Compaq dc7700p Business Desktop System BIOS for Intel vPro Technology (786E1 BIOS)" can
<soren> NCommander: Not really. I'm just puzzled that it's the case for vmx/svm. I never encountered a system where it wasn't reported in cpuinfo, if the CPU had the capabilities.
<NCommander> soren, well, I would think its a safety feature
<soren> How so?
<Chipzz> hrrrrm
<Chipzz> Error in /home/chipzz/.mutt/sidebar, line 5: sidebar_width: unknown variable
<NCommander> Programs trying to use VTx are supposed to check with the BIOS to make sure it actually would be safe to do so
<Chipzz> but the changelog documents the sidebar patch as being applied?
<NCommander> Virtualization solutions like Xen run guest OSes in Ring 1, and only fault to -1 (VTx) when needed
<NCommander> I would guess that this behavior exists to make sure no instructions are not run in the wrong ring by accident
<Chipzz> soren: ^^
<Chipzz> since you did the last upload
<NCommander> soren, I have absolutely no idea if thats the truth, but its the only plausable explication I can think of (lm is the other mode that sometimes seems to disappear and reappear as well ...)
<soren> Chipzz: Do you have mutt-patched installed?
<Chipzz> just mutt; but the mutt changelog documents the patch as being applied
 * soren is using the sidebar patch quite happily.
<soren> Chipzz: Yes. To mutt-patched.
<Chipzz> are mutt and mutt-patched build from the same source?
<soren> Yes.
<Chipzz> ah, that would explain
<Chipzz> quite misleading though
<soren> What is?
<directhex> NCommander, it's true - kvm was what told me i had no vmx flag
<Chipzz> that the changelog of mutt documents a feature being applied in mutt-changed
<Chipzz> (yes I know packages built from the same source have the same changelog;
<NCommander> directhex, wait, kvm told you?
<Chipzz> hence my comment about "quite confusing")
<directhex> NCommander, well, the init script
<NCommander> directhex, that error message usually means the BIOS isn't allowing access to ring -1
<Chipzz> anyway problem fixed
<directhex> NCommander, the init script just looks for "vmx" or "svm" in cflags, and if you have neither, says "                log_failure_msg "Your system does not have the CPU extensions required to use KVM. Not doing anything.""
<directhex> cpuflags, even
<NCommander> Oh, I see
 * NCommander notes VTx is an amazing hack
<Chipzz> soren: maybe make a note in the changelog about mutt-patched?
<NCommander> directhex, you know how VTx works?
<directhex> NCommander, black magic and voodoo? that's enough for me
<NCommander> lol
<soren> Chipzz: I'm not going to change earlier changelog entries. I might add a reference to mutt-patched in mutt's long description, though.
<pitti> mvo: I just started upgrading my wife's computer to 8.10; u-n told me about the missing nvidia driver
<pitti> mvo: however, since version -96 now works again in intrepid-proposed, we should update u-m as well for that; is that already on your radar, or shall I open a tracking bug for this?
<pitti> mvo: (or a new task, rather)
<mvo> pitti: its on my radar, tseliot mentioned it yesterday
 * pitti hugs mvo
<mvo> pitti: I just need to add checks so that we ensure we never end up with the non-working version
<pitti> mvo: that's similar to the jockey update (bug 293107)
<ubottu> Launchpad bug 293107 in jockey "Offer nvidia driver version 96 again" [High,Fix committed] https://launchpad.net/bugs/293107
<Chipzz> soren: I wasn't suggesting that. but in the next changelog maybe?
<pitti> mvo: I think we can safely do it once the new driver is in intrepid-updates, right?
<pitti> mvo: btw, version 71 still seems to fail
<soren> Chipzz: Like " * Oh, look! There's a package called mutt-patched, too!" ? :)
<mvo> pitti: oh, good to know
<Chipzz> soren: :) or just mentioning that the patch is only applied to mutt-patched next time updating the patch?
<Treenaks> 11:05 <@     _mike_> zo, alle newszilla dreaders zijn nu debian/lenny, met de  laatste diablo code, en een openvz 0-master
<Treenaks> 11:05 <@     _mike_> <phew>
<Treenaks> OOPS
<Treenaks> --------------------------------------------------------------------------------
<mvo> pitti: yeah, I think so too. when its in -updates we should be fine
<Chipzz> Treenaks: where you from?
<Treenaks> so.. on-topic, what about disabling middle-button emulation (left+right=middle) for jaunty?
<directhex> Treenaks, it's disabled? :(
<Treenaks> directhex: no, it's enabled
<directhex> Treenaks, thank god
<Treenaks> directhex: that's why I pasted something I didn't want to paste
<Keybuk> Treenaks: get a better IRC client?
<Keybuk> xchat requires you to press Enter after pasting
<directhex> i wonder if smuxi does
<Treenaks> Keybuk: so does irssi, but only if you paste more than 3 lines
<Treenaks> Keybuk: but good idea, thanks.. I'll see if I can configure that
<Keybuk> Treenaks: the real problem there is using an IRC client that is blissfully unaware of the fact you're running in a GUI
<Keybuk> there are plenty of real GUI clients available ;)
<Treenaks> Keybuk: make a screen for X apps and I'll consider them ;)
<Keybuk> it's called vnc :P
<Treenaks> s/screen/gnu-screen like program/
<liw> for those who use irssi so that they can run it under screen, I note that bip seems to work very well with xchat: you can quit xchat whenever you like, and then re-connect to bip (an irc proxy) when you feel like being flooded again
<directhex> really?
<directhex> -directhex- VERSION bip-0.7.2
<Keybuk> see, I just don't bother
<Hobbsee> liw++
<Keybuk> and accept that people will talk about me when I'm not here
<Keybuk> I don't let it worry me
<ion_> Middle button emulation for the win.
<liw> Keybuk, I don't care if people talk about me, but I find it practical to know when they talk _to_ me, without my having to monitor irc constantly
<liw> Keybuk, there is an unfortunate tendency amongst people to wait for people to get onto irc rather than e-mail them :(
<Keybuk> if you're eating dinner, or asleep, why does it matter if they're talking to you?
<Keybuk> you can't do anything about it - so there's no real point to being online
<Keybuk> and the best bit is
<Keybuk> if you're not online
<Keybuk> they stop trying
<liw> that's certainly a valid point of view, I don't disagree with that at all
<liw> but people have expressed annoyance if I*m not on irc throughout my entire work day
<Keybuk> why would you disconnect during your working day?
<liw> to be able to concentrate for a while, without having xchat interrupt me
<soren> Keybuk: But you might miss out on people talking *about* you. :(
<Keybuk> liw: I just ignore it
<liw> Keybuk, you're a better man than I am (but we knew that)
<Keybuk> then again, I have very minimal notification
<Keybuk> it just places an icon in the notification area at the top
<cjwatson> superm1: it's fine to use the metapackages until then
<cjwatson> wgrant: it got stuck at libxcrypt; I fixed that by hand and am rerunning
<cjwatson> soren: vim> go ahead if you haven't already
<soren> cjwatson: Almost done. Got distracted. :)
<cjwatson> mvo: your debconf changelog is bizarre; the remaining changes allegedly include a backport from trunk, but those changes were in the Debian upload you merged
<cjwatson> mvo: could you commit your changes to bzr, too?
<cjwatson> with a 'bzr merge' there
<mvo> cjwatson: my only change to debconf (that I can remember is): 1.5.23ubuntu2 - is that the one?
<mvo> and that change is in bzr
<cjwatson> oh, it was Scott
<cjwatson> Keybuk: ^-
<Keybuk> cjwatson: ?
<cjwatson> Keybuk: you uploaded debconf, apparently
<Keybuk> a merge?
<cjwatson> yes
<Keybuk> right
<cjwatson> Keybuk: you didn't commit the changes to bzr, and the merge changelog entry was wrong
<Keybuk> I know
<cjwatson> can you please fix that?
<Keybuk> I can't retroactively fix the changelog message
<cjwatson> MoM should have a warning for packages maintained in bzr
<Keybuk> packages maintained in bzr are a pain in the arse
<Keybuk> it's impossible to ever get them right
<Keybuk> I won't touch it next time
<cjwatson> they're trivial to get right if you use bzr ;-)
<stefanlsd> Keybuk: i agree with cjwatson. We just need a process
<seb128> the issue is that not everybody uses bzr
<Keybuk> you have to apt-get the source
<Keybuk> then you have to get the branch
<cjwatson> not in this case
<Keybuk> then you have to figure out what's in the branch that's not in the source
<Keybuk> and somehow overlay them over each other
<Keybuk> and then figure out where you got to
<Keybuk> and then probably do other things to make it build
<Keybuk> it's utterly stupid
<cjwatson> seb128: no, the issue is when people decide not to use bzr even when the package already does
<cjwatson> seb128: I don't mind (well, I do, but :-) ) that not everyone uses bzr right now; it's the clash that's awkward
<Keybuk> no
<seb128> right
<Keybuk> the issue is that bzr is fundamentally incompatible with the way we do source packages
<Keybuk> and we're trying to force people to use it
<Keybuk> and it doesn't work
<seb128> but everybody doesn't want to spend half an hour rather than 5 minutes just to fight bzr
<cjwatson> Keybuk: in this case, the bzr branch is sufficient; I don't believe any overlaying is necessary
<pitti> Keybuk: apt-get source warns, and you have debcheckout for convenience
<seb128> I just stopped touching packages in bzr due to that
<cjwatson> Keybuk: I try to make that be the case for all my packages
<cjwatson> or at least have it be obvious when it isn't
<mvo> Keybuk: I find bzr a huge help for my package maintainance in many ways
<cjwatson> Keybuk: so AFAICT you're complaining about something which is true for other packages but not this one
<wgrant> I think much of the problem is that bzr usage is very inconsistent.
<cjwatson> wgrant: yes, I agree with that
<Keybuk> cjwatson: my compaint is the time it takes to figure out what package this one is
<Keybuk> whether it's one that's easy, or hard
<Keybuk> and that you still have to assume it's hard to find out it's easy
<cjwatson> Keybuk: so leave it alone if you don't want to put in that effort
<Keybuk> and it's a waste of time
<seb128> mvo: that's likely because you have complicated packages, it's just annoying when doing simple changes
<Keybuk> cjwatson: like I said, I'll leave it alone next time
<cjwatson> don't screw it up for other people
<pitti> Keybuk: but I think a MoM warning if a package has Vcs-Bzr:.*launchpad* would be utterly helpful
<seb128> mvo: but we already had this discussion ;-)
<Keybuk> pitti: I'd rather just have MoM ignore those packages
<mvo> seb128: indeed :)
<Keybuk> since it clearly will never be the right thing
<cjwatson> Keybuk: I use MoM as a to-do list even while ignoring its *output*
<pitti> Keybuk: it can point out the need for merge, but not output anything, right
<cjwatson> Keybuk: so ... what pitti said
<pitti> Keybuk: maybe its report should point out "debcheckout" or so
<Keybuk> can't do that with the current design
<Keybuk> either it generates a merge, or it doesn't
<cjwatson> make it spanner the merge somehow
<Keybuk> why?
<Keybuk> whatever it does will clearly be wrong
<Keybuk> just like whatever anyone does that doesn't know the package will clearly be wrong
<Keybuk> this is why I hate bzr packaging
<pitti> the need for merging isn't wrong
<Keybuk> it, ironically, makes it impossible to maintain packages as a team
<pitti> s/impossible/different/
<pitti> and that's what we need to improve
<Keybuk> yes, we can spend a lot of time working on the procedures
<Keybuk> training
<Keybuk> getting everybody to do things the right way
<Keybuk> and we'll end up with something almost as good as what we had before
<Keybuk> only a little extra work
<pitti> (wasn't it you who wrote NoMoreSourcePackages? :-) )
<cjwatson> I think there should be a rule that every package that's in bzr should either be buildable straight from the branch, or should fail in an obvious way with directions as to what to generate (but preferably the former, and moving towards universally the former)
<cjwatson> there are not enough packages in bzr right now to make that terribly hard to enforce
<pitti> yeah, if debcheckout+debuild doesn't work, that's a bug
<mvo> does that mean we should keep it as it is and abandon the whole maintain-packages-in-bzr idea?
<Keybuk> pitti: the whole point of that document was my assertion that the *only* way do to bzr packaging was to *only* do bzr packaging
<pitti> Keybuk: I fully agree :)
<Keybuk> trying to package both ways simultaneously is just pain for pain's sake
<cjwatson> the problem with that assertion is that it's false. I get by just fine otherwise
<pitti> yes, I don't argue that
<Keybuk> bzr packaging fails the moment you have an .orig.tar.gz
<Keybuk> because you can't put that in bzr in a way that works
<pitti> no, that's not true
<pitti> you are just not using the tools we have for that
<Keybuk> the tools we have are hacks
<Keybuk> they get one bit from other there, and the other from other *there*
<Keybuk> and end up only slightly worse than apt-get source
<pitti> well, apt-get source fetches orig.tar.gz and diff.gz and applies that
<Keybuk> which is what I find ridiculous
<pitti> debcheckout fetches orig.tar.gz and the branch and applies that
<pitti> I don't see the fundamental difference
<pitti> well, I do appreciate that it could be cleaner
<pitti> but it works as well as apt-get source, IMHO
<Keybuk> I disagree
<cjwatson> fixing this is one of the reasons James has put lots of effort into bzr-builddeb
<Keybuk> you can't do a diff.gz with that
<seb128> it's just extra steps, slower and a different workflow you need to learn
<Keybuk> and none of this actually gives us anything we didn't have before
<Keybuk> in fact, it's worse
<Keybuk> because in the brave new bzr world you can't use merge-o-matic anymore
<Keybuk> so merges become hard work again
<pitti> seb128: if someone uploads jockey or apport without committing to bzr, it's much slower and extra steps for me to clean up after him...
<cjwatson> Keybuk: merge-o-matic gets things wrong when bzr merge doesn't
<Keybuk> unless you're lucky enough to be Colin and only focus on things which are native and in revision control upstream along with their packaging
<pitti> Keybuk: merges are a snap of a finger with bzr
<seb128> pitti: right, but you just discourage people to fix things on your packages then
<cjwatson> your claim that it's worse is based on the theory that merge-o-matic is at least as good
<Keybuk> cjwatson: such as?
<pitti> seb128: and doing serious upstreamish development work without revision control is insane
<Keybuk> you've not filed any bugs
<seb128> pitti: we don't discuss upstream work but packaging there
<pitti> Keybuk: I don't use MoM  for merging cups or hal -- I just use "bzr merge", and that just works
<cjwatson> Keybuk: it has less context for changes; I don't see it as something MoM can fix
<Keybuk> cjwatson: it has the same context
<pitti> no, MoM doesn't have history
<Keybuk> yes it does
<Keybuk> it might not be quite as discreet as the commit logs
<Keybuk> depending on whether the author releases often or bunches things up
<Keybuk> but otherwise it's basically doing the same thing
<pitti> but it can't tell that patch A has been applied as modified patch A' upstream and thus is merged
<Keybuk> in fact, MoM tries to be a bit smarter about the merge than bzr
<cjwatson> Keybuk: lucky enough? ignoring the native thing which I really don't think is as important as you make out, the reason I'm in this position is that I've put effort into it
<Keybuk> cjwatson: and that means you're the only person who can really make changes to those packages now
<Keybuk> because you're the only person who understands the way you've done it
<Keybuk> which is almost certainly different to the way pitti does it
<cjwatson> Keybuk: demonstrable bollocks
<Keybuk> and probably different to the way mvo does it
<cjwatson> you can tell this from the fact that other people change them
<pitti> I had no problem so far committing changes to d-i or update-notifier
<Keybuk> and get ranted at on IRC for fucking it up
<seb128> right, because you put the required efforts to figure how to update those and you are used to bzr so it's likely something easy for you
<cjwatson> the people who utterly ignore stuff that's in place will screw it up, sure; in other cases I haven't had many problems actually
<cjwatson> people generally get it right
<Keybuk> I didn't get it right
<Keybuk> and I don't think I'm incompetent
<pitti> seb128: that may be true, yes
<cjwatson> you ignored the vcs-bzr, which I think tools could have helped you with
<cjwatson> if you hadn't, I'm confident that you would have got it right
<Keybuk> to see the vcs-bzr, I had to get it from bzr
<mvo> asac: could you please check #272314 ? I think you were a bit quick with making it "invalid" ;)
<Keybuk> it's a chicken and egg
<cjwatson> huh?
<pitti> Keybuk: no,apt-get source warns you
<cjwatson> the vcs-bzr field is in the package as uploaded, and as pitti says ...
<Keybuk> at no point there, did I run apt-get source
<seb128> pitti: I don't even know where to push my changes usually, I apt-get source which gaves me a bzr command, which I use and gives me a readonly checkout and there I'm stucked
<cjwatson> Keybuk: and, like I say, I think MoM should have warned somehow
<pitti> Keybuk: right, you downloaded from MoM, which brings us back to the original problem of MoM not warning about it :)
<Keybuk> and as I've frequently filed bugs - apt-get source has never given me a bzr warning
<cjwatson> hence "I think tools could have helped you"
<Keybuk> cjwatson: patches welcome
<soren> Keybuk: You could put the info in REPORT and have grab-merge warn you.
<mvo> (asac: and adding a update-manager taks for that matter)
<cjwatson> apt-get source often gives me bzr warnings
<cjwatson> so "WFM" is unfortunately the best I can say at the moment ...
<cjwatson> anyway, midwife visit
<pitti> seb128: debcheckout :)
<Keybuk> quest tmp% apt-get source debconf
<Keybuk> dpkg-source: extracting debconf in debconf-1.5.23ubuntu2
<Keybuk> dpkg-source: info: unpacking debconf_1.5.23ubuntu2.tar.gz
<seb128> pitti: what is that?
<Keybuk> see, no warning
<pitti> seb128: convenience script to fetch orig, branch, and set it up correctly
<liw> Keybuk, weird: NOTICE: 'debconf' packaging is maintained in the 'Bzr' version control system at:
<seb128> pitti: should apt suggest than rather than bzr get on http locations?
<Keybuk> if bzr is the correct way to get a package
<Keybuk> then apt-get source should *not* bitch at you
<pitti> seb128: yes, very much so; in fact, it should use "lp:~/ubuntu-core-dev/debconf/ubuntu", which works for read-only as well as push
<Keybuk> apt-get source debconf should automatically use bzr to fetch it properly
<pitti> mvo: ^
<asac> mvo: sure
<asac> let me look
<mvo> Keybuk: I can add that (for bzr+lp branches)
<pitti> Keybuk: that, or at least a stronger warning if DEBEMAIL =~ /ubuntu/ is a good idea
<pitti> mvo: and advocating http:// is really outdated now, I think
<Keybuk> pitti: warning is silly
<Keybuk> I really never read apt output
<pitti> mvo: but I guess it takes that straight from Vcs-Bzr
<Keybuk> it's all random crap about package lists and stuff
<Keybuk> which is why it's turned off
<pitti> Keybuk: it could just fail
<Keybuk> pitti: that's not being helpful either
<mvo> pitti: yes
<Keybuk> "do this" ... FAIL!
<Keybuk> if apt knows what you're supposed to have done instead, it should just do that
<mvo> Keybuk is right, it should to it automatically, problem is how to ensure the diff gets sent back to lp when its finished?
<asac> mvo: well. ia32libs wasnt updated for them
<liw> "apt-get source" can work (local mirror) whereas bzr might fail (no Internet access)
<pitti> mvo: what about apt-get source just calling debcheckout if it sees Vcs-Bzr:.*launchpad ?
<Keybuk> liw: in which case, according to colin, you shouldn't be allowed to fetch the source package
<asac> mvo: should be a lower depends bound ... true
<mvo> asac: right, that clearly indicates that there is a versionized dependency missing, no?
<pitti> Keybuk: fetching is fine, uploading is disallowed (which is why we are currently doing it that way)
<asac> mvo: but still those folks claimed that multiverse got disabled ;)
<mvo> asac: I asked for the upgrade log, in general, we keep multiverse, but of course there might be a bug (or corner case)
<pitti> but yeah, it's a tricky problem
<mvo> asac: yeah, that worries me a bit :/
<asac> mvo: maybe update manager could do better to see that there are packages from a now-disabled component?
<pitti> maybe we should just try to make apt-get source call debcheckout, and see who complains
<asac> mvo: lets assume user disabled it ;) ... that could be the case for sure
<mvo> pitti: yes
<asac> mvo: or maybe apturl :)
<pitti> it coudl still download the package with --force, or so
 * Keybuk didn't know about debcheckout, btw
<Keybuk> where was that announced?
<asac> mvo: but update-manager could also know that there are packages from multiverse and do something imo. otherwise the upgrade would fail too i guess
<mvo> asac: well, what should it do in this case? I can not embed special knwledge into it for each package, if the dependencies are fine, u-m will install it
<pitti> Keybuk: devscripts 2.10.8, Tue, 11 Sep 2007
<asac> mvo: how? if multiverse isnt enabled the upgrade will either fail (because the dep cannot be fulfilled) or removed?
<mvo> pitti: I think calling debcheckout if fine, but how do we ensure that the change in bzr are then sent back to LP? or does debcheckout do that?
<Keybuk> pitti: I can't see any ubuntu-devel posts introducing it?
<pitti> Keybuk: but right, that's why apt-get source should point it out/JFDI
<mvo> asac: or kept at the same version. but it does something sensible, even if that is removing the package
<Keybuk> which is an interesting point
<Keybuk> we're getting an increasing number of DTRT tools
<Keybuk> yet you can only learn about them by osmosis, since we don't really document them anyway
<asac> mvo: true. i think if package comes from a none-ubuntu archive it should be removed if it would cause problems to keep it at same version
<pitti> mvo: you mean teaching people how to use "bzr commit"?
<mvo> asac: right, but how should u-m know? it can not have special knowledge for each package, if its not encoded in the dependencies, there is little I can do AFAICS
<asac> mvo: but cant we do better if people have things from ubuntu archive ? maybe an index of package names mapped to archive section?
<mvo> pitti: yes
<asac> mvo: hmm ... isnt the info to identify a package as being from multiverse in the cache?
<mvo> pitti: it sounds silly, but you did not have to do it with apt-get source / dput
<asac> mvo: like in the Pool file name?
<Keybuk> pitti: it's a shame that Vcs-Bzr isn't in the changes file :-/
<asac> but yeah. lets keep this as a dependency bug
<mvo> asac: it is, but why should it tread multiverse differently than say universe?
<mvo> or restricted ?
<pitti> mvo: well, I don't think we can pretend to not use bzr
<asac> mvo: no it should treat all that way
<pitti> mvo: if we'd do that, we wouldn't need it in the first place
<asac> mvo: if you hav a package for which the section was disabled and that comes from ubuntu archives, we can consider to enable that pool for upgrade
<mvo> pitti: I agree - I think i just need to add a message explaining that bzr commit is required or something like this
<Keybuk> actually
<pitti> mvo: point to https://wiki.ubuntu.com/BzrMaintainerHowto ?
<Keybuk> this is damned hard
<Keybuk> we end up with three different Vcs-Bzr fields
<pitti> (which should get an update...)
<Keybuk> one from BASE, one from LEFT and one from RIGHT
<mvo> asac: that information is not recorded (yet) if the user commented out his repos
<Keybuk> which one do we believe?
<Keybuk> and how do we deal with them being different?
<mvo> asac: but yeah, having this information "Installed-From" would be *really* useful
<pitti> the one from ubuntu
<mvo> asac: for liw and his system-cleaner for example
<asac> mvo: which information? i can currently look at apt-cache show and see the poolname in the filename
<Keybuk> pitti: two of those may be ubuntu ;)
<Keybuk> in fact, three of them may be in some circumstances
<pitti> Keybuk: well, RIGHT is Debian, and LEFT is what you are just generating, isn't it?
<Keybuk> no
<mvo> asac: right, now try to comment out multiverse and do that apt-cache policy thing again
<asac> mvo: Filename: pool/multiverse/f/flashplugin-nonfree/flashplugin-nonfree_10.0.12.36ubuntu1_amd64.deb
<pitti> Keybuk: ah, no, LEFT is current ubuntu, RIGHT is current Debian
<mvo> asac: or try it in a version that is no longer downloadable (because there is a new version in jaunty and the old one got removed from the archive)
<pitti> Keybuk: so, "LEFT" is the right Vcs- field
<Keybuk> pitti: not so much
<asac> mvo: ok ... i believe you ;)
<Keybuk> all three can come from the same distro
<Keybuk> .e.g initramfs-tools
<pitti> Keybuk: but as I said, it's not really necessary for MoM to do the merge; it is actively wrong to upload it
<Keybuk> BASE might have been in ubuntu first
<mvo> asac: we should talk about this at uds, the "record where it comes from" idea is really good
<Keybuk> LEFT and RIGHT might also have been in ubuntu
 * mvo needs to run for lunch
<Keybuk> well, normally not, but it's possible
<Keybuk> the problem is that just about every debian/control we're talking about inherently has a conflict
<Hobbsee> when is the ETA for moving everything to bzr?
<Hobbsee> (is there one?)
<Keybuk> since the apparent change made to everything is to change the Vcs-Bzr to point to launchpad
<Keybuk> pitti: the problem is that MoM has to do the merge
<Keybuk> since the information is in debian/control
<Keybuk> which it only has when doing the merge
<pitti> Keybuk: it's also in the .dsc
<Keybuk> is it?
<pitti> well, it's in Sources.gz, so it has to
<pitti> It's VCS-Bzr:
<asac> mvo: is that fixable in a SRU (for new upgraders) at all? will update-manager look at -updates for updates or do an intermediate step to "plain" first?
<Keybuk> interesting
<Keybuk> here's a thought
<asac> mvo: or do we need a tweak as hardy SRU now?
<Keybuk> grab-merge could branch the bzr repository into a temporary directory
<Keybuk> and move the .bzr into the directory the merge result is unpacked into
<pitti> and auto-add the new files in debian/ ?
<Keybuk> not auto-adding would make people manually check a bit more carefully
<Keybuk> lifeless: around?  I feel momentarily evil
<pitti> sure
<Keybuk> I wonder if I can fake a bzr conflict for the conflicted files :p
<pitti> well, I don't use grab-merge, but if many people do, that sounds helpful
<asac> fake a conflict? for the not added files?
<pitti> for the real conflicts in the files, I figure
<Keybuk> asac: for the ones with MoM conflict markers in them
<soren> Keybuk: .bzr/checkout/conflicts
<asac> oh. so we still want to do our own merge logic and not bzr merge?
<pitti> Keybuk: but that would still not record the merged revisions from trunk
<pitti> Keybuk: so you'd break bzr merge
<Keybuk> sure
<pitti> so if debian/trunk is in bzr, doing that would be wrong, too
<Keybuk> so which header field is that documented? :p
<pitti> Keybuk: Debian's Vcs-*? :-)
<Keybuk> or does that require personal knowledge of the package
<pitti> we only need to consider Vcs-Bzr, I think
<Keybuk> pitti: there doesn't seem to be a standard for those
<pitti> I do have bzr imports for vcs-svn, too
<Keybuk> I've seen people using both XS-Debian-Vcs-Bzr and XC-Original-Vcs-Bzr
<pitti> but since svn doesn't really support branches and merges, it doesn't matter
<soren> Keybuk: The latter is certainly wrong.
<Keybuk> see
<Keybuk> this is the problem
<pitti> Keybuk: no, scratch that
<pitti> look at the debian .dsc
<soren> Keybuk: It needs to be XS- at the very least.
<Keybuk> soren: I mean XS
<Keybuk> pitti: look at it for?
<Keybuk> Vcs-Bzr ?
<soren> Keybuk: There was some discussion a long time ago about whether to use Debian or Original.
<pitti> Keybuk: yes
<Keybuk> what do you do in that case?
<pitti> Keybuk: I guess that only really affects d-i
<soren> Keybuk: I'm quite sure we agreed Debian was correct.
<pitti> Keybuk: don't use MoM
<Keybuk> debconf uses Original ;)
<Keybuk> pitti: so how do we document which packages to use MoM for and which not to?
<Keybuk> you see my point here
<Keybuk> we've ended up in the situation where no developer can touch anything for fear of getting it wrong
<pitti> Keybuk: If Ubuntu has a Vcs-Bzr:, I would discourage MoM
<pitti> otherwise use MoM
<pitti> and if Debian has a Vcs-Bzr, too, MoM shouldn't output anything, since uploading it breaks bzr merge
<pitti> admittedly having just ubuntu in bzr, and not debian/trunk, is utter crack
<Keybuk> why would you discourage MoM in the former case?
<pitti> and I doubt that many people use that actually
<pitti> since it makes merges so much harder
<Keybuk> if you're just committing uploads to bzr, the MoM upload is worth committing
<Keybuk> I don't agree
<Keybuk> I think bzr is making the merges so much harder
<pitti> Keybuk: well, discourage, or use your magic grab-merge approach
<soren> Keybuk: https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023379.html
<pitti> Keybuk: just keeping ubuntu in bzr and not the debian side is, IMHO
<pitti> I did it long enough, and it was a PITA
<pitti> now I import debian's svn to bzr and merge from that
<pitti> so much easlier
<Keybuk> see, everyone's doing it differently ;)
<pitti> well, "just ubuntu in bzr" -> pain, discourage, not document
<ScottK> pitti: I thought I'd gotten that Spamassassin SRU you just accepted rejected.  It's got two problems.
<pitti> "import deiban into svn" -> love, and you don't need MoM
<ScottK> pitti: 1.  I forgot to add the patch to 00list, so it doesn't get applied.
<sebner> pitti: will the "old" way once gets disabled so we are forced to use bzr?
<pitti> ScottK: whoops, that slipped my review (argh too many SRU reviews today); sorry
<ScottK> pitti: 2.  I uploaded it to dapper-updates, not dapper-proposed (so it's just as well actually the patch wasn't applied).
<ScottK> pitti:
<ScottK> pitti: No problems.
<ScottK> pitti: There's a fixed one I just uploaded.  I'd appreciate it if you'd accept it.
<pitti> ScottK: thanks, will do
<pitti> sebner: which old way?
<ScottK> pitti: Great.  Thanks.
<sebner> pitti: the normal way we work on packages now ^^
<Keybuk> pitti: can you think of an unmerged package using bzr?
<pitti> Keybuk: hal
<pitti> Keybuk: but as I said, I have debian in bzr, too, so all I do is "bzr merge", and it's happy
<Keybuk> http://merges.ubuntu.com/h/hal/REPORT
<Keybuk> that detected that you have ubuntu in bzr \o/
<pitti> sebner: maybe once we have everything in bzr, but notuntil that
<Keybuk> but you're missing vcs-bzr for the debian version :p
<pitti> Keybuk: that's because debian is in svn
<pitti> Vcs-Svn: svn://svn.debian.org/svn/pkg-utopia/packages/unstable/hal
<Keybuk> and you use bzr-svn?
<pitti> yes
<Keybuk> see
<sebner> pitti: how long will this take? I suppose you are already actively migrating?
<Keybuk> how is another developer merging hal when you're away supposed to know this stuff?
<pitti> sebner: we have some prototypes, but don't hold your breath
<Keybuk> the sheer amount of magic required to merge hal that's only in your brain is worrying to me
<Hobbsee> Keybuk: no one's else is insane enough to merge hal.
<pitti> Keybuk: as long as he commits it to bzr, I don't mind
<pitti> Keybuk: having debian in bzr is making things easier for *me*
<Keybuk> pitti: but you've said yourself, you'd rather they didn't because it'd be wrong
<pitti> if someone else wants to do it the hard way, and doesn't ask me, *shrug*
<Keybuk> the problem is, by making it easier for you, you're making it harder for everyone else
<pitti> Keybuk: no, only if debian/trunk is in bzr, too
<pitti> Keybuk: why? that I have debian hal in an svn-imported bzr is totally opaque to anyone else?
<pitti> and that I have ubuntu hal in bzr is obvious due to vcs-bzr
<Keybuk> unless they're trying to merge
<pitti> you can just commit a manual merge
<pitti> that's just bad if trunk/debian is a real bzr branch, since then you don't record the merged revisions
<Keybuk> or they can just upload it as normal, and you can sort it out later? :)
<pitti> but for svn that doesn't matter anyway, because svn doesn't know
<pitti> Keybuk: "normal" in the sense of committing the changes to bzr without worrying at all about the debian svn, yes
<Keybuk> I mean just dupload
<pitti> often people just upload without committing, so I just prod them to send me the diff or commit afterwards
<mvo> asac: that is fixable, update-manager will use the latest stuff in the archive
<sebner> pitti: kk
<cjwatson> I don't actually mind when people upload rather than committing, since I can just ask them to commit; it doesn't normally turn into an hour-long argument about life the universe and everything
<cjwatson> (and I have committed stuff on other people's behalf before)
<cjwatson> pitti: is your Debian hal branch lp:~ubuntu-core-dev/hal/debian ?
<cjwatson> code.launchpad.net/hal is where I would naturally look for this stuff
<pitti> cjwatson: yes, I push it there; updating now
<pitti> it's just a bzr-svn alioth <-> lp gateway
<pitti> this is a setup which I don't actually *like* and which should be much easier
<pitti> but well, it's a package that I work on a lot, so doing that initial setup is worth it
<cjwatson> I agree, it ought to be lp:debian/hal
<cjwatson> and automatically imported
<pitti> since you lose merge tracking if you do another svn import
<pitti> since svn is just so <censored> <beep>
<cjwatson> presumably, though, pulling the branch from LP, running 'bzr pull' with bzr-svn installed, and pushing is fine
<cjwatson> that should probably be in the branch whiteboard
<Mithrandir> pitti: uhm, svn does merge tracking now, you know that?
<pitti> Mithrandir: oh? since when?
<Mithrandir> 1.5
<pitti> wow, that brings it on par with cvs :)
<Mithrandir> so intrepid + hardy-backports.
<Keybuk> http://pastebin.ubuntu.com/67874/
<Keybuk> that turns out to be quite easy
<ogra> Mithrandir, dont mix intrepid with hardy-backports :P
<Mithrandir> *shrug*; unless bzr it doesn't change the on-disk format twice a week and then proceeds to whine at me.
<pitti> Keybuk: I'd use Vcs.*launchpad
<Keybuk> pitti: that doesn't work for your packages
<Keybuk> this will err on the false positive side
<pitti> Keybuk: otherwise we'd catch all the alioth vcs-svn ones which we don't care about
<Keybuk> but I think that's ok
<pitti> Keybuk: my packages?
<Keybuk> ie. hal
<Keybuk> it wouldn't show up the debian bit
<Keybuk> why would it have launchpad in it anyway?
<Keybuk> shouldn't it be Vcs-bzr: lp:~ubuntu-core-dev/hal/ubuntu ?
<pitti> Keybuk: suppose package foo is in alioth svn, but not in bzr in ubuntu anywhere
<pitti> then a standard non-VCS merge is the right thing
<Keybuk> pitti: then they'll get a warning
<Keybuk> and can figure out whether its safe to continue
<cjwatson> I haven't been using lp: so far, but maybe I should
<pitti> Keybuk: yeah, if it's just a warning, that's in fact fine
<Keybuk> right, that goes at the bottom of grab-merge
<pitti> cjwatson: I don't use it in the Vcs-: fields, because I like them to be clickable
<cjwatson> the thing about using lp: is that you can't c'n'p them into a web browser
<pitti> but for bzr checkout/pull/push/get they work nicely
<cjwatson> so you have to have a separate vcs-browser field which is more fiddly
<pitti> cjwatson: but debcheckout is clever enough to translate them, I think
<Keybuk> cjwatson: the thing about not using lp is that it doesn't translate nicely into a writable or readonly url automatically
<cjwatson> Keybuk: yeah, I don't pretend to have a perfect answer there
<cjwatson> pitti: it is
<cjwatson> maybe I should just bite the bullet and use vcs-browser
<cjwatson> I just don't want to be changing things round every five minutes since that's confusing too
<jernst> bryce: ping?
<ogra> jernst, likely to early for him
<jernst> I thought so too ;-), thanks
<pitti> bryce: do you want to do the inkscape merge? it's currently on my plate, since I tossed the recommends: around right before release, but you feel more attached to it :)
<pitti> soren: ^ likewise, do you wnat to do virtinst?
<soren> pitti: I'll do virtinst, yes.
<pitti> soren: thanks
<pitti> argh, guys, pretty please forward patches to Debian
<kwwii> mvo: could you look at #293482 and confirm that it is not a compiz problem?
<asac> TheMuso: your ppa is named here: https://wiki.ubuntu.com/MozillaTeam/Bugs/FlashAnswers :) ... anything else you would like to be asked on NEW sound bugs?
<ahasenack> is there a way for apport to report the time of the crash?
<ahasenack> I have a bug report saying that when a program called Me-TV was closed, apport reported a crash in landscape-sysinfo, which is clearly wrong
<ahasenack> so I'm guessing apport is reporting an old crash
<pitti> ahasenack: yes, it's written into the report by default
<pitti> ahasenack: "Date:"
<ahasenack> pitti: I must be blind then, I don't see it here: https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/271954
<ubottu> Error: This bug is private
<pitti> ahasenack: oh, it's not copied to the LP bug report
<pitti> ahasenack: in fact it was doing it before, but I was asked to throw out redundant fields
<ahasenack> pitti: only that field?
<ahasenack> pitti: can you put it back please? :)
<pitti> ahasenack: how would it help you with that bug?
<pitti> ahasenack: yes, ignore the "me-tv" comment, it's clearly wrong
<pitti> ahasenack: you got one of those nice python segfault crashes
<ahasenack> pitti: I would compare the date of the crash with the date of the bug
<pitti> I'm regularly lost what to do with those, too
<pitti> ahasenack: it should be "5 minutes earlier" or so
<pitti> ahasenack: it apparently happened while a session was running
<ahasenack> pitti: I was assuming that apport was reporting an old crash that was for some reason not reported when it actually happened
<pitti> ahasenack: apport pops up and reports straight after the crash happens
<pitti> unless you don't have a running session, in which case it asks you when logging in
<pitti> but that's not the case here, according to the description
<pitti> ahasenack: given that landscape-sysinfo is cron'ed every 10 minutes, I guess me-tv was just a coincidence
<ahasenack> pitti: yes, that's what I'm thinking now
<ahasenack> pitti: so, if the crash happened outside of a session and the user logged in only the next day into gnome, then we would get very different dates for the crash and the report, right?
<mvo> kwwii: "I get the same result with or without Compiz. As I already said, the
<mvo> fresh account experiences the same issue too." (last comment) so I doubt its a compiz issue
<pitti> ahasenack: yes
<kwwii> mvo: yeah, in the meantime I am not sure if this guy is being honest in the report...thanks for checking
<ahasenack> pitti: thanks
<mvo> kwwii: oh, ok - I double check here on my system
<mvo> Riddell: for bug #291115 there is no "TEST CASE" in the description yet, is it sufficient to just use turkish locales to trigger the bug?
<ubottu> Launchpad bug 291115 in update-manager "[kde] Kubuntu Update Manager crash problem with Turkish language" [Undecided,Fix committed] https://launchpad.net/bugs/291115
<mvo> kwwii: works for me on a fresh system with and without compiz (just tested it on a freshly upgraded test system)
<Riddell> mvo: yes
<mvo> Riddell: thanks, I added a test case now, it would be cool if you could fill in the extact commands that are required (how to run adept to get the --proposed version of hte upgrader, how to switch default language with kde )
<mvo> did we release note that evms was removed from the archive?
<soren> It was?
 * soren lets out a sigh of relief
<mvo> rmadison evms tells me its no longer in intrepid
<mvo> it just is a pain for people upgrading with evms root
<mvo> and update-manager will happily remove evms because its now obsolete
<Keybuk> I thought we kicked that out back in edgy or something
<Keybuk> ah, universe in gutsy
<Keybuk> gone from intrepid
<mvo> bad for people with evms roots
<Keybuk> sync'd removal from Debian
<Keybuk> so we probably never noticed
<kwwii> mvo: cool, thanks...I appreciate your help
<mvo> aha, thanks
<Keybuk> cjwatson: removals.txt isn't updated anymore?
<mvo> Keybuk:  I was wondering about that
 * mvo prepares a update-manager SRU for the two evms users
<Keybuk> mvo: one assumes if they had it installed, it wouldn't be removed?
<Keybuk> or does update-manager remove it?
<mvo> Keybuk: update-manager removes everything that is obsolete unless its told otherwise
<mvo> (obsolete == vanished from the archive)
<Keybuk> how does it tell the difference between that and local packages?
<mvo> Keybuk: it checks what is local before it updates the sources.list and then calcs the difference
<Keybuk> cunning
<Keybuk> mvo: who's the *other* evms user?
<mvo> heh :)
<Keybuk> actually, I can think of two
<Keybuk> Tollef and wasabi
<cjwatson> Keybuk: https://launchpad.net/ubuntu/+source/evms/2.5.5-26ubuntu2 logs the removal; bug 159585 is for the fact that removal data is spread over two places
<ubottu> Launchpad bug 159585 in soyuz "lp-remove-package.py does not log removals to our standard place" [Low,Confirmed] https://launchpad.net/bugs/159585
 * cjwatson nags that bug
<tseliot> Riddell: do you know if there's something similar to the gnome-settings-daemon in KDE? For example something which loads the screen settings (resolution,etc.) on login?
<pitti> mvo: btw, no need to do a no-change upload of intrepid-proposed to jaunty; we can just copy-package it (which I usually do for SRUs if jaunty and intrepid versions are the same)
<pitti> mvo: also, you didn't build with -v, thus the bugs don't get autoclosed
<ogasawara> pitti: yah, sorry for the extra noise with those 2.6.27.2 bugs that I had opened and closed.  It was an oversight on my part.
<pitti> ogasawara: no problem about the noise; I'm more worried about misunderstandings about the future SRU workflow
<ogasawara> pitti:  I believe tim was under the impression people wanted an SRU bug report/patch
<pitti> ogasawara: hm, who? I'm fine with just one bug report, with a changelog
<pitti> I want the kernel team to read the changelog and check for something fishy
<pitti> not to create busywork for themselves and me to create tons of bug reports :)
<ogasawara> pitti: agreed, that's why I had scripted opening the bugs for them.
<ogasawara> pitti: let me talk with them, just a sec
<rtg> pitti: while clumping all of the stable updates into one report makes SRU processing easier, it will make regressions a little more difficult to track.
<pitti> rtg: okay
<rtg> 'cause there is a pile of them. About 40 committed, another 57 in the pipeline,
<pitti> rtg: well, if you actually want to have one SRU bug per commit yourself, I'm fine; I was just under the impression that you didn't
<pitti> I think I can easily counterattack ogasawara's script with a script to close SRU bugs when moving things to -updates :)
<ogasawara> heh
<rtg> pitti: I was just trying to find a way to change policy so we could add stable updates. The mechanics don't matter to me.
<pitti> rtg: it seems easier to me to create bug reports about particular regressions when they are found, not in advance, but that might be just me
<rtg> pitti: however, that being said, whoever is doing the work really needs to look at each patch.
<rtg> pitti: that works for me as well.
<pitti> rtg: for a casual tester/reporter, it's not really feasible to find the commit that was responsible for the regresssion anyway
<rtg> so, clump the stable updates into one SRU request, then create regression reports as they appear?
<mvo> Riddell: is #241314 sru worthy?
<pitti> that, or just use that one bug; I think it's a matter of common sense
<pitti> rtg: also, if we notice that we get like 5 regressions per stable pull, that's not a sign to change the bug reporting policy, but a sign that we shouldn't do it in the first place :)
<pitti> one regression is worse than 10 known bugs usually...
<rtg> pitti: I guess experience will tell us if we're doing the right thing.
<pitti> (unless they are of the data loss/security kind, of course)
<Riddell> mvo: I wouldn't say so
<pitti> rtg: exactly
<mvo> Riddell: ok, good
<tseliot> Riddell: is there no equivalent?
<Riddell> tseliot: oh sorry, no there's nothing which sets resolution as far as I know
<ogasawara> rtg: I'll open a master bug for 2.6.27.3 and 2.6.27.4 then and clean up those other bugs that got opened.
<tseliot> Riddell: ok, thanks
<rtg> ogasawara: cool. I think that will constitute enough change that an upload is required.
<rtg> pitti: in checking on https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27 I see that it needs building, but I can't find it in any of the Intrepid queues.
<rtg> why are the buildd's so backed up anyway?
<pitti> rtg: the source is already accepted, so it's not in a particular queue (well, it's in "DONE")
<pitti> rtg: we have the initial jaunty sync wave, plus new langpacks
<rtg> ah, the DONE queue. 111K entries.
<rtg> hrmph. make that Jaunty stuff wait until _my_ builds are done.
<ScottK> pitti: If you're still up for doing archiv'ish things, please have a look at intrepid backports for lintian, devscripts, and debootstrap.
<pitti> ScottK: seb128's archive day today :)
<ScottK> pitti: OK.  Thanks.
<ScottK> seb128: ^^^
<seb128> oh right, I forgot about that
<seb128> will have a look
<ScottK> seb128: Thanks.
<seb128> pitti: I got used to not touch the archive during the intrepid freeze ;-)
<tseliot> Riddell: is it a bug the fact that Konsole doesn't remember its previous size when you launch it?
<Riddell> tseliot: yes, fixed in trunk
<tseliot> Riddell: ok, thanks god it's not a feature ;)
<danimo> hi
<danimo> asac: ping?
<mvo> pitti: re bug #272199 - the reason this is not in intrepid already is that it breaks the string freeze (that was the reason why its not in gnome too). I can still do a upload if the regression is more imporant than the string freeze (I don't mind either way)
<ubottu> Launchpad bug 272199 in gnome-terminal "[intrepid REGRESSION] Missing option to disable "switch to tab" keyboard shortcuts" [Low,Confirmed] https://launchpad.net/bugs/272199
<pitti> mvo: not sure, but we did have that string until shortly before RC
<nxvl> cjwatson: i'm not getting jaunty-changes's confirmation e-mail, is that list moderated?
<asac> danimo: ?
<cjwatson> nxvl: err, are you trying to mail it directly?
<mvo> pitti: well, we had it for about a week (added 2008-10-21 and removed 2008-10-31
<maxb> But the strings were in hardy, weren't they?
<tedg> Keybuk: So, if MoM will do a merge automatically will it propose that as a merge in the packaging VCS?  How does that work?
<mvo> pitti: I have no strong opinion either way, I'm fine with doinga sru for it
<mvo> pitti: it would be nice if we could resurrect the strings from hardy somehow
<mvo> (the translations I mean)
<pitti> mvo: there's a script which copies them over
<cjwatson> nxvl: mails to jaunty-changes are moderated, but subscription is open
<cjwatson> nxvl: the moderation queue is also empty
<Laney> mvo: Please do it!
<mvo> pitti: oh? is that script in the bug somewhere (and I overlooked it?) - if so, I'm happy to do it right away
<Laney> :)
<nxvl> cjwatson: i mean the subscription
<cjwatson> nxvl: nothing to do with us ...
<nxvl> cjwatson: mmm, i will check what's happening, thank you
<pitti> mvo: it's a Launchpad thingie; I don't know it either, I just know about its existance
<mvo> pitti: so it happens automatically?
<pitti> mvo: someone has to call it
<danimo> hi asac
<danimo> asac: Riddell said you could help me with tracing down an issue with network manager
<danimo> asac: my provider assigns me an ipv6 address, and I guess nm thinks it thus doesn't need to assign me an ipv4 address via dhcp
<danimo> asac: but I need to prove it somehow
<ogra> ARGH
<ogra> tkamppeter, my cups went on strike after printing once
<ogra> i get a "No %%Pages: comment in header" message
<ogra> it worked a second ago and now i cant even print a testpage
<ogra> not even a reboot and resetting the printer helped
<asac> danimo: is that pppoe?
<Spads> ogra: a friend of mine got that problem shortly after upgrading to intrepid.
<ogra> well, i rinted several times on intrepid already
<ogra> and it woked a minute before this job
 * ogra goes mad ... why does such a thing only happen if i'm in massive time pressure 
<danimo> asac: no, plain ethernet
<danimo> asac: (student dorm)
 * ogra cries
<asac> danimo: then how does your provider assign you ipv6?
<danimo> asac: the student dorm is my isp
<danimo> asac: ipv4 and ipv6 via one ethernet line
<asac> danimo: open a bug, reproduce and attach the complete syslog so i get an initial idea ;)
<asac> dont use IPv6 here :/
<danimo> asac: I wanted to ask where to look
<danimo> asac: the ipv6 address is assigned as the interface is brought up
<danimo> asac: ipv6 doesn't require dhcp
<superm1> asac, is there any particular reason that libmbca depends on bluez-gnome?
<asac> superm1: yes. i think the wizard itself support bluetooth somehow
<asac> we cannot use that in NM though for now
<superm1> it's pulling in the entire bluetooth stack whenever you install network-manager gnome
<asac> hmm
<superm1> because network-manager gnome is recommending libmbca0
<asac> superm1: could you file a bug about that? is that a big problem? i men in the end we want to support bluetooth by default i think
<asac> s/men/mean/
<superm1> asac, well it's not a problem for main distro, but for derivatives it is adding a lot of dependencies
<superm1> asac, i'll file a bug though
<asac> superm1: ok. but assume next release NM supports bluetooth ... fixing this bug wouldnt change much for derivates then i think
<asac> (not really sure how NM will do that in the end ... so there might be less depends involved)
<superm1> asac, right.  well i guess that also depends on the timeframe of that release
<superm1> i guess the better question to pose is why it's asking bluez-gnome rather than libbluetooth3 or similar
<asac> superm1: point that out in the bug. libmbca upstrewam has to give a comment then
<asac> danimo: ok. first stare at the log and see if it tells you something special about ipv6
<asac> danimo: then go and look in code how the nm-setting-ip6-config.h things are used
<asac> and if they prevent stage4 from getting the ip
<ogra> URGH !
<ogra> so as soon as a print job gets sent to /dev/usblp0 the device vanishes
<ogra> what a mess
<danimo> asac: will  try, bbl
<ogra> pitti, ^^^^ any idea ?
<pitti> ogra: urgh? no, that's news to me; anything enlightening in dmesg?
<ogra> [  847.544312] usb 7-3: USB disconnect, address 8
<ogra> [  850.168082] usb 7-3: new high speed USB device using ehci_hcd and address 9
<ogra> [  850.321234] usb 7-3: configuration #1 chosen from 1 choice
<ogra> [  850.324979] usblp0: USB Bidirectional printer dev 9 if 0 alt 0 proto 2 vid 0x03F0 pid 0x4117
<ogra> [  852.301256] usblp0: removed
<ogra> thats all
<ogra> between 850.324979 and 852.301256 i clicked on "print"
<ogra> i can cncel the job, replug the printer and have the device back
<ogra> printing again gets me the same result
<ogra> the printer ui just shows "No %%Pages: comment in header"
<pitti> ogra: sounds like a kernel bug or hw problem
<pitti> ogra: device disconnect when you talk to it...
<pitti> you talked too loudly, it fell over
<ogra> well, the device works/worked in hardy
<ogra> i'm cursing here
<seb128> and it worked in intrepid you said
<seb128> and just before breaking usually things work
<ogra> i should be on the autobahn since 30min, but cant print my badge for the conf i'm heading to
<ogra> seb128, it worked during the dev cycle
<ogra> i probably scared it by loud cursing :)
<ogra> and it constantly worked in hardy
<ogra> just intrepid final seems not to
<seb128> boot an hardy cd and print your badge?
<ogra> hrm
<seb128> it'll be faster to boot a CD than to debug
<pitti> Riddell: good news
<wasabi> Keybuk: mvo: I no longer use evms
<wasabi> So, 1 left.
<wasabi> But, I no longer use it because it's in such a crappily maintained state, not because I think it sucks. I still think it's awesome. ;0
<Riddell> pitti: mmm?
<pitti> Riddell: I found the msgctxt problem, and band-aided it
<Riddell> pitti: ooh?
<pitti> Riddell: next langpack build shoudl be good
<Riddell> pitti: is it not a launchpad issue?
<pitti> Riddell: unfortunately intrepid's gettext-po.h/glibc implementation is too stupid to know about msgctxt
<pitti> so I disabled using that
<pitti> that will make the packs considerably bigger (the English ones), but at least correct
<pitti> and for -updates we don't care so much
<Riddell> pitti: why much bigger?  the strings were always in the .po files
<pitti> Riddell: it filters out msgid == msgstr ones
<Riddell> ah
<pitti> Riddell: for those people who have fun earning easy karma by translating C into en_US and en_GB
 * liw ponders using Finnish for msgids
<sebner> wb nxvl
<Keybuk> cjwatson: yeah I saw that the removal records are now in soyuz, that's where I got the "removed from debian" bit from
<ogra> no way ...  and suddenly th same hapens with hardy as well, on all three printers in my house
<jdong> is there a way with apt_preferences(5) to pin a glob of packages?
 * ogra doesnt get whats happening here 
<ogra> pitti,
<ogra> E [05/Nov/2008:17:13:56 +0100] [Job 36] No %%Pages: comment in header!
<ogra> E [05/Nov/2008:17:14:15 +0100] Pause-Printer: Unauthorized
<ogra> E [05/Nov/2008:17:14:19 +0100] PID 9919 (/usr/lib/cups/filter/pstopdf) stopped with status 1!
<ogra> E [05/Nov/2008:17:18:55 +0100] Resume-Printer: Unauthorized
<ogra> i see a lot of that in my cups log
<pitti> tkamppeter: ^ any idea?
 * ogra wonders where the pause and resume comes from
<ogra> sigh
 * ogra doesnt get it 
<rtg> kees: is CVE-2008-3831 important enough to warrant another -security upload?
<mvo> if there is anyone faimilar with evms, I would appreciate if you could help me with writing the sru test case for bug #292179 - I need a recipt how to add a evms parition to the system (for someone with no clue about evms like me)
<ubottu> Launchpad bug 292179 in update-manager "Intrepid upgrade removed EVMS but should not have allowed upgrade" [Medium,In progress] https://launchpad.net/bugs/292179
<Keybuk> evms --cause-pain --hurt --ow --ow --make-it-stop --please --illl-do-anything /dev/sda1
<pitti> Keybuk: didn't you forget --fsck-drives?
<ion_> The idea of evms sounds nice. I hope someone makes an equivalent UI for lvm, md etc.
<ogra> pitti, hmm, now i can print but get empty pages
<Keybuk> btrfs!
<Keybuk> btrfs!
<Keybuk> btrfs!
<ogra> pitti, and the intresting part is:
<ogra> ogra@osiris:~$ ls /dev/usblp0
<ogra> ls: Zugriff auf /dev/usblp0 nicht mÃ¶glich: No such file or directory
<ogra> though it prints  ...
<Keybuk> my mouse just stopped working
<Keybuk> wtf
<ion_> btwfs, huh. /me takes a look
<ion_> r
<jdstrand> rtg (and kees): unless there is more to it than the CVE description, I'd say it can wait til the next round
<rtg> jdstrand: works for me. I'm about to upload 40 plus SRU/stable patches
<jdstrand> rtg: is it included in there?
<rtg> yep
<jdstrand> yeah-- that sounds right to me
<jdstrand> -updates, and wait on -security
<rtg> but this kernel will likely stay in -proposed for quite awhile
<Keybuk> silly things to type #143: rmmod usbhid
<jdstrand> well, there are a lot of ways for a local DoS besides that ioctl, so IMO, it's low priority (so we'll wait until we have several of them or something bigger)
<rtg> jdstrand: np
<Keybuk> HMM
<Keybuk> things you cannot do without a mouse
<Keybuk> LOG OUT!
<mvo> ctrl-alt-backspace
<mvo> see, it works!
<rtg> Keypucnhing the power button doesn't bring up the dialog?
<cjwatson> alt-f1 right right up up enter (alt-tab if necessary) alt-l
<cjwatson> see, obvious
<Keybuk> it's sad that I still blame Linux for problems like that
<Keybuk> (the battery had run out)
<ion_> :-)
 * ogra goes to install a windows pc 
<jernst> bryce: ping
<kees> rtg, jdstrand: I thought CVE-2008-3831 was fixed already?  (or was intrepid still vulnerable?)
<rtg> kees: well, its in the stable series. Did I already get it? checking changelog....
<rtg> its not in the Intrepid changelog
<bryce> jernst: rather than pinging people, it's better to just ask the question...
<kees> rtg: ah, dang, we'll get it in the next round then.
<rtg> kees: well, as I pointed out to jdstrand, this kernel is going to cook in -proposed for several week, perhaps longer.
<kees> should be fine.
<jernst> bryce: sorry, was not sure that you were back. regarding https://bugs.launchpad.net/bugs/286924 could you please review your patch rejection reason in the light of my last comment ?
<ubottu> Launchpad bug 286924 in usb-creator ""Create a USB startup disk" menu entry should be named "USB startup disk creator"" [Low,Triaged]
<kees> slangasek: why is "die" more correct than "done" for the PAM regression?
<bryce> jernst: sure
<tkamppeter> ogra, pitti, the failure of /usr/lib/cups/filter/pstopdf is bug 289759
<slangasek> kees: I'm not sure that it is?
<ubottu> Launchpad bug 289759 in cups "cups kyocera" [Undecided,New] https://launchpad.net/bugs/289759
<tkamppeter> ogra, pitti, the unauthorized resume should not influence the job.
<slangasek> kees: it's more correct than 'ok', because using 'ok' will fall through to the next module, which is probably pam_deny
<kees> slangasek: right, "ok" clearly fails.  regardless, I'd like to get it SRU'd asap, since it's clearly a regression.
<bryce> jernst: the patch isn't rejected, only the intrepid task
<tkamppeter> ogra, pitti, bug 289759
<ubottu> Launchpad bug 289759 in cups ""/usr/lib/cups/filter/pstopdf failed" in error_log and only blank page printed" [Undecided,New] https://launchpad.net/bugs/289759
<jernst> bryce: sure no problem however the reason (breaks translation) doesn't stand as no translations exists
<slangasek> kees: yes, by all means.  I would suggest using '=done' then, and SRUing ASAP
<bryce> jernst: fair enough
<kees> slangasek: will there be any conffile silliness?  (I assume you have just buck-passed the SRU to me)
<slangasek> kees: nope, none at all; you should be able to just edit the unix profile and it should work
<slangasek> yes, I'm passing it to you so that I can do the SRU approval :)
<ogra> tkamppeter, what i dont get that i printed yesterday and the whle morning stuff and it worked, it just suddenly stopped working
<kees> slangasek: hah, perfect, I'll jump all over it.
<kees> murdok: hola!  :)
<murdok> hola :Ã
<murdok> it's about bug https://bugs.launchpad.net/ubuntu/+source/procps/+bug/216398
<ubottu> Launchpad bug 216398 in dosemu "default mmap_min_addr breaks dosemu" [Medium,Confirmed]
<kees> yup, hopefully my comments have described the situation a bit.  have you looked at what wine did to solve this in intrepid?
<murdok> You said that is better to include in the package a /etc/sysctl.d/dosemu.conf file to fix it
<murdok> yes i have
<murdok> is it as simple as including this file or do i miss something? i would like to do it
<kees> murdok: well, according to the README in /etc/sysctl.d/, I'd recommend something very late in the process, so naming it 90-dosemu-low-memory.conf or so
<murdok> okay
<kees> murdok: it should be trivial to add to the dosemu package.  (this is why there was a push for /etc/sysctl.d/, so we could support per-package configurations)
<murdok> wine's config is named  wine.sysctl.conf
<murdok> maybe it should be also change to 90-*
<kees> murdok: yeah, it's an over-sight, since they created the file prior to there being a standard for sysctl.d.  but as it happens, they resolve last anyway, so it works.
<kees> murdok: the maintainer-script juggling to rename that file is non-trivial, but if one of the wine maintainters is up for it, I'd like that too.  :)
<ogra> tkamppeter, do you have anything about "No %%Pages: comment in header" ?
<ogra> tkamppeter, seems thats the issue it started with
<murdok> isn't it as easy as cp wine.sysctl.conf 90-wine.sysctl.conf and if it doesn't exists create it?
<murdok> oops mv*
<ogra> and apparently the printer doesnt work at all anymore on any of the laptops i try it on
<murdok> well but it works at the end
<murdok> i'll try it with doesmu, should i assign the bug to me?
<kees> murdok: no, since it's possible the user has changed the conf file, so an md5 check is needed.
<kees> murdok: sure, yeah
<murdok> okay, let's see if I have it ready tonight
<murdok> now I must go
<murdok> thanks :D
<kees> Keybuk: is there more currect documentation on conffile removal/renaming than http://wiki.debian.org/DpkgConffileHandling ?
<murdok> kees: oops i forgot, should i do the patch for jaunty and intrepid?
<murdok> both still have the same versions
<kees> murdok: if you want to pursue an SRU, do intrepid, but probably best to start with jaunty so you can test it
<murdok> okkie
<ogra> ok, at least windows worked :(
 * ogra cuses that he has to install windows to get a printout, especially since i wont get any sleep through that 
<Keybuk> kees: no idea
<kees> Keybuk: okay.  I saw a whole bunch of extra magic added to the procps maintainer scripts when removing the tcp timestamp stuff.
<Keybuk> colin did that ;)
<Keybuk> I think he took my functions and replaced sed with dpkg-query
<Keybuk> so his are probably the most current ;)
<kees> I will use procps as the gold standard now.  :)
<Keybuk> pitti: pidgin
<pitti> Keybuk: mutt
<Keybuk> err, disregard
<Keybuk> I'm sure pidgin had an NM plugin
<pitti> Keybuk: oh? then we should activate it
<pitti> or switch to empathy now, maybe
<Keybuk> that's the thing
<Keybuk> I thought it was on
<Keybuk> but I'm clearly hallcuinating
<kees> slangasek: do you have docs on how the pam-configs stuff is processed?  I haven't found anything in the PAM debian/ tree yet.  I'm trying to figure out how -Initial differs from the entires without -Initial
<kees> slangasek: and under which situations do I need to update the md5sums in local/pam-auth-update ?
<kees> (oh, nm, that's just for templates?)
<kees> slangasek: okay, 291091 updated and ready for SRU evaluation.
<slangasek> kees: documentation is only in the wiki currently, at https://wiki.ubuntu.com/PAMConfigFrameworkSpec; and yes, the md5sums are just for the templates
<kees> slangasek: ah! a pointer to that page would be Nice(tm) in the debian/ tree somewhere.  in the meantime, I will read that just to double-check my changes are sane.
<slangasek> kees: you've installed this, just to confirm that it does update your configs files correctly? :)
<NCommander> hey kees
<kees> slangasek: yea, it works for me
<kees> NCommander: heya :)
<slangasek> kees: ok, please upload
<kees> slangasek: okay, done.
<slangasek> thanks
<superm1> slangasek, can you disable the cron job that would be creating jaunty mythbuntu alternates whenever dailies would be starting?  We've decided not to do alternates any more due to their enormously low take rate and the testing burden of testing both.  I'm working on porting over all the bits and pieces of our hacks in our live cd build script to other packages so that live cds can be built with livecd rootfs.  it'd be more ideal at that poin
<superm1> t to have daily live disks generated in the alternate's place
<lifeless> Keybuk: has it passed?
<vadi2> I was told that my webcam driver is buggy, but how can I find out who to report the bug to in launchpad?
<johanbr> vadi2: file a bug against the kernel (package "linux")
<vadi2> johanbr: alrighty, thank you
<psusi> can anyone remind me how you turn on KERN_DEBUG printks?
<vadi2> johanbr: sorry, but I don't see an option to add an affected package: https://bugs.launchpad.net/ubuntu/+source/cheese/+bug/294142
<ubottu> Launchpad bug 294142 in cheese "[intrepid] Cheese chooses wrong resolution by default and fails to work" [Low,Triaged]
<johanbr> vadi2: Should be another way to do it, but try https://bugs.launchpad.net/ubuntu/+source/linux/+bug/294142
<ubottu> Launchpad bug 294142 in cheese "[intrepid] Cheese chooses wrong resolution by default and fails to work" [Low,Triaged]
<vadi2> johanbr: thank you
<slangasek> superm1: ok, changed in bzr
<kees> slangasek: uhm, is soyuz supposed to auto-submit things from intrepid-proposed into jaunty?  or did you trigger that?
<slangasek> I did that
<kees> (i.e. https://edge.launchpad.net/ubuntu/+source/pam  -- I was not expecting it to build in jaunty)
<kees> okay, whew
<slangasek> er, hrm
<slangasek> did it get built twice?  that would be a sign that I screwed up.
<kees> slangasek: in that case, do you want me to push those changes into bzr?
<slangasek> it should all go to bzr anyway, yes
<slangasek> but if it built in jaunty, then... oops.
<kees> I yelled at me about a build failure, that's how I noticed
<ogra> use earplugs :)
<lifeless> Keybuk: (that was a pong)
<kees> slangasek: do you want it in bzr as 1.0.1-4ubuntu5.1 or as UNRELEASED with 1.0.1-4ubuntu6 ?
<slangasek> kees: I'm already taking care of it in bzr
<slangasek> (5.1, now 5.2 since I have to do a rebuild
<slangasek> )
<kees> d'oh, okay, nm
<RainCT> anyone knows if it's possible to limit the bandwith pbuilder uses?
<tkamppeter> ogra, pitti, I have dound a possible solution for the pstopdf problem in bug 289759. Please try. It should also fix several other bugs, should get SRU.
<ubottu> Launchpad bug 289759 in cups ""/usr/lib/cups/filter/pstopdf failed" in error_log and only blank page printed" [Undecided,Incomplete] https://launchpad.net/bugs/289759
<ogra> tkamppeter, i will do so if i caom back on sat. for now i had to print on windows to get the papers i need tomorrow morning
<jdstrand> slangasek: hi! so pitti sent apparmor to intrepid-proposed like 13 hours ago, however all archs show 'needs building'
<jdstrand> https://launchpad.net/ubuntu/+source/apparmor/2.3+1289-0ubuntu4.1
<jdstrand> slangasek: is this cause for concern or just archive lag?
<infinity> jdstrand: jaunty-release is scored higher than intrepid-proposed.
<infinity> jdstrand: So, you get to wait until the autosync queue is done.
<infinity> jdstrand: Or, if it's urgent and we need it built and tested ASAP, let me know, and I'll score it up.
<jdong> infinity: is that a bug or a feature?
<infinity> jdong: Feature.
<jdstrand> infinity: no, not that urgent-- I made a comment in the bug. we should be good. thanks!
<infinity> jdong: With rare exceptions, -proposed is never meant to be "urgent", while bugfixes in the devel release may well be.
<jdong> infinity: gotcha
<seb128> kees: there?
<kees> seb128: yea, but on a conf call
<seb128> kees: ok, did you upload a system-tools-backends new version? there is some new bugs about postinst errors
<seb128> whoever did the upload might want to have a look to those
<james_w> seb128: intrepid or jaunty?
<kees> seb128: back.  bug #?
<seb128> james_w: intrepid
<james_w> odd
<seb128> kees: bug #294291
<ubottu> Launchpad bug 294291 in system-tools-backends "package system-tools-backends 2.6.0-1ubuntu1.1 failed to install/upgrade: il sottoprocesso post-installation script ha restituito un codice di errore 1" [Undecided,New] https://launchpad.net/bugs/294291
<kees> seb128: looks like a problem due to being in the middle of an upgrade?
<seb128> ok, I didn't look into details I was just reading my mails before going to bed and there was 2 upgrade errors for the new version so I figured I would let you now to maybe keep an eye on coming bugs there
<seb128> bug #294389
<ubottu> Launchpad bug 294389 in system-tools-backends "package system-tools-backends 2.6.0-1ubuntu1.1 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/294389
<kees> geh, I will try to reproduce, but I didn't have any problems with it yesterday
<seb128> that's the other one
<kees> james_w: any idea how to reproduce this?
<seb128> the issue doesn't seem due to the changes
<james_w> kees: no clue
<seb128> and there was already a similar bug opened before intrepid
<james_w> kees: the second one may be that it is already started
<seb128> so that's likely not due to the update and just a coincidence
<james_w> kees: in the second log it apparently starts fine once, and then it tries to start it again later and fails
<seb128> kees: sorry for the noise
<kees> seb128: well, it's clearly related to people getting the security update, but I'm not sure in what way they're set up that it's breaking
<seb128> kees: right but it doesn't seem specific to security changes, the postinst has just corner cases where it can break apparently
 * kees nods
<seb128> mvo is right, all those postinst are not robust enough
<NCommander> kees, so I have a PIE-built chroot (I need to hand it to Gentoo; when you want to do something completely insane, it works well)
<kees> NCommander: kewl
<NCommander> kees, do we want to add anything like PaX, or are we just going to stay w/ AppArmour
<seb128> anyway enough work for today
<seb128> 'night everybody
<NCommander> night seb128
<kees> NCommander: most of PaX is already in mainline.  beyond that, AppArmor works well enough for a MAC system.
<NCommander> kees, MAC?
<NCommander> Macs didn't have AppArmour until jaunty
<kees> NCommander: heh.  Mandatory Access Control.  (AppArmor, SELinux, SMACK, etc)
<NCommander> ah
<NCommander> Cool
<NCommander> Gentoo has already done quite a bit of the hardwork needed to make this fly, and based with my previous attempt, I think I can successfully get an amd64 PIE built chroot off the ground
<jordi> TheMuso: I uploaded alsa-lib & alsa-driver to unstable, with some changes re: what was in svn
<TheMuso> jordi: Right I got those already./
<jordi> TheMuso: next will be -utils,tools and plugins
<TheMuso> jordi: Right.
<jordi> TheMuso: -plugins includes a biarch patch that you could somehow ask for testing :)
<TheMuso> jordi: Awesome!
<jordi> TheMuso: ie, it will generate lib64asound2-plugins and so on
 * TheMuso nods.
<RAOF> jordi: Oh?  That biarch patch I put up there some time ago has finally hit a package? :)
<jordi> TheMuso: still not committed, I'm trying to finish improving the package descriptions
<RAOF> Yay!
<jordi> RAOF: so it's you
<RAOF> Yup.  That was me.
<jordi> RAOF: it's taken a while
<jordi> but it's the beginning of both Ubuntu and Debian cycles
<jordi> so I decided to apply it, look somewhere else and let TheM^WUbuntu fix it if something goes wrong ;)
<RAOF> Yeah.  I was too late for pushing that for Intrepid, or for lenny for that matter.
<jordi> TheMuso: it's also a perfect time to bring our diffs close to 0. Go ahead and discuss whatever you want (specially alsa-lib I guess) in the list
<jordi> or commit whatever is clear we want in both distros
<jordi> RAOF: yep
<jordi> and the patch is scary :)
<jordi>   [ Christopher James Halse Rogers ]
<jordi>   * debian/control, debian/rules: import the multi-arch magic from
<jordi>     alsa-lib to build a lib32asound2-plugins package wherever
<jordi>     lib32asound2 is built, and similarly for lib64asound2 (closes: #436201).
<jordi> this is the uncommitted changelog
<jordi> many thanks, RAOF!
<vadi2> intrepid-security isn't enabled by default for a clean install, but intrepid-updates is. Is there any rationale behind this or is it a bug? https://bugs.launchpad.net/bugs/289197
<ubottu> Launchpad bug 289197 in update-manager "[Intrepid] security updates aren't enabled by default" [Undecided,Incomplete]
<TheMuso> jordi: Ok.
<rulus> Hello, can someone enlighten me on bug 293127? (I'm the reporter) Are there plans to update these images, or am I doing something wrong? :)
<ubottu> Launchpad bug 293127 in debian-installer "Update Intrepid hd-media images to final release" [Undecided,New] https://launchpad.net/bugs/293127
<bdmurray> TheMuso: Are you familiar with ubuntustudio-menu at all? bug 276503 was brought to my attention
<ubottu> Launchpad bug 276503 in ubuntustudio-menu "package ubuntustudio-menu 0.10 failed to install/upgrade: there is no script in the new version of the package - giving up" [High,Triaged] https://launchpad.net/bugs/276503
<TheMuso> bdmurray: I have touched the package on several occasions, and the studio team is well aware of that bug. Since nobody else has seemed to do anything about it yet, I'll likely take a peak at some point in my own time.
<bdmurray> TheMuso: Great, I'll pass it on.
<NCommander> hey TheMuso ]
<jordi> RAOF: ooh
<jordi> +       # We don't necessarily have pulse, dbus, or jack biarch libraries
<jordi> +       # and even if we do, we don't have the .so symlink for them
<jordi> +       # since ia32-libs-dev doesn't exist.
<jordi> +       # SO: we need to detect these libs when they exist, provide .so
<jordi> +       # symlinks, and copy the pkg-config files.
<jordi> RAOF: I think I didn't like this too much
<jordi> why can't we have biarch libs for these?
 * slangasek shoots biarch in the forehead
<jordi> la la
<jordi> there it goes.
<jordi> now debian/rules is as ugly as it can get
<jordi> slangasek: enjoy
<jordi> http://svn.debian.org/wsvn/pkg-alsa?op=comp&compare%5B%5D=%2Ftrunk%2Falsa-plugins@2126&compare%5B%5D=%2Ftrunk%2Falsa-plugins@2140
<slangasek> I assume that involves biarch and will therefore pretend it doesn't exist
<jordi> you can't escape biarch
<slangasek> I can replace it with multiarch
<jordi> RAOF: I guess this will create duplicate files with ia32-libs or so
<jordi> slangasek: that would be quite cool :)
<jordi> RAOF: here?
<RAOF> jordi: Briefly.
<jordi> RAOF: ia64-libs doesnt exist, but was added to Build-Depnds
<jordi> any clue?
<RAOF> Um, was it?
<TheMuso> ia64-libs sounds... weird.
<RAOF> I presumably had some reason to think that ia64-libs existed.
<jordi> amd64-libs?
<RAOF> Aaah.
<RAOF> Brain transcription error :)
<jordi> yep ;)
<RAOF> I sometimes like to forget IA64 is an ISA distinct from x86-64.
<NCommander> You can run x86 binaries on ia64 however
<TheMuso> At what performance penalty?
<stgraber> not only on part of them ? (I thought the first ones didn't have the x86 compatibility thing)
<lifeless> TheMuso: no penalty
<lifeless> TheMuso: the penalty is in the fact that the chip is HUGE
<lifeless> TheMuso: and its clock rate doesn't scale as high, so its x86 work/sec is less than current x86-64 dedicated chips
<RAOF> jordi: The crazy "create symlinks and pkg-config files" madness was there for some reason.  Possibly because ia32-lib-dev exists only on ia64, and that's an uninteresting arch for me.
#ubuntu-devel 2008-11-06
<RAOF> jordi: The pkg-config madness was, from memory, because configure would pick up on the native-arch pkg-config files for the biarch build - even when there weren't actually any biarch libs for those, which would cause linking to fail.
<jordi> RAOF: hm, pulse plugin which is probably the most interesting one wasn't built in the 64bit version
<RAOF> jordi: Is libpulse in amd64-libs?  If so, the magic *should* pick it up.
 * RAOF actually looks at the filelist of amd64-libs
<NCommander> hey TheMuso
<RAOF> jordi: If http://packages.debian.org/sid/i386/amd64-libs/filelist is accurate, then it's not much of a surprise that the pulse plugin wasn't built!
<TheMuso> Hey NCommander .
<NCommander> TheMuso, how goes it?
<TheMuso> NCommander: Well thanks. Yourself?
 * NCommander is determining how print-architecture works in dpkg
<NCommander> TheMuso, not bad. I have dpkg running on Gentoo ;-)
<TheMuso> haha
<NCommander> and now APT
<NCommander> :-)
<ajmitch> I wouldn't think they'd be hard to run on gentoo
<NCommander> You'd be suprised
<NCommander> There is a circular dependency
<NCommander> dpkg depends on itself to determine build information
<NCommander> (else dpkg --print-architecture and a whole lot of other things don't work right)
<ajmitch> so yay, you just installed dpkg & apt, now you have another debian-like system
<NCommander> ajmitch, sorta, I'm rebootstrapping amd64
<StevenK> NCommander: We did that already so you don't have to.
<NCommander> StevenK, with everything as position independent exectuables ;-)?
<zul> ok why?
<StevenK> zul: Because NCommander has a lot of spare time, apparently.
<zul> StevenK: well good for him then
<NCommander> Having the archive exist as PIEd executables will allow us to intact address space randomization
<NCommander> Or in other words, it would be near impossible to execute a stack smash or return-to-libc attack
<RAOF> NCommander: What's the performance impact on ia32 like?
<NCommander> Bad
<NCommander> 10-15% I think
<NCommander> And no real improvement to security
<NCommander> Due to the small address space
<NCommander> Hence why ASR is only sane on 64-bit architectures
<RAOF> The address space is still _pretty_ big, isn't it?
<NCommander> Its been proven it can be brute forced extremely quickly
<NCommander> SOmething like 10 hours
<RAOF> Fair enough.
<mrooney> bryce: what is an EPR, re the fglrx r3xx bug?
<bryce> Engineering Problem Reports
<mrooney> bryce: hm, I see, so where is the report that it corresponds to?
<bryce> mrooney: it is in AMD's internal bug tracker
<dcolish> Any update-manager developers?
<ScottK> Almost certainly sleeping.
<dcolish> ah, well I wanted to try and understand some of the reasoning behind recent changes to update-manager and why it's reconfiguring my xorg. Can't seem to find anything clear on launchpad
<wgrant> dcolish: You mean its commenting-out of inputdevices?
<dcolish> yup, I mean I understand that HAL is supposed to be doing that work with the new autoconfig, but why when I make local changes does it not honor those?
<wgrant> Because you should be using fdi files.
<wgrant> See https://wiki.ubuntu.com/X/Config/Input
<wgrant> Speicifically https://wiki.ubuntu.com/X/Config/Input#hal
<dcolish> I see, maybe a link in the xorgs would be helpful for overrides. I might never have found that link and I've been doing a bunch of support help on the xubuntu channel
<dcolish> A link to that page
<wgrant> That's a good point.
<wgrant> But mvo doesn't seem to be around yet.
<dcolish> Let me see if I can find the project in launchpad. I'll try and add a note there
<pitti> Good morning
<Hobbsee> pitti!!!!!
<pitti> infinity: erm, isn't it exactly the other way around? SRUs are always more urgent that jaunty? at least at this time, right after a release?
 * Hobbsee throws rather hot gummy bears at pitti
<pitti> infinity: last time I discussed that with cprov, I asked for SRU > devel, hm
<pitti> Hobbsee: yummy! but wouldn't they melt?
<Hobbsee> pitti: not sure.  somewhat, i think
<soren> They do on pizza.
<Hobbsee> you've tried this, i take it?
<soren> I may have :)
<StevenK> I've had gummy bears in ice cream
<pitti> tkamppeter: doesn't seem to fix it for everyone? but an improvement in any case, so please commit it to bzr; once people in the bug are happy enough, I'll upload an SRU
<StevenK> Morning pitti
<soren> StevenK: In Denmark youcan get ice cream with gummy bears preinstalled.
<StevenK> soren: As you can here
<soren> Wel... Not ice cream, actually. Ice lollies.
<StevenK> Well, I go to a shop that sells ice cream with a choice of stuff in it, and they mix it in front of you
<soren> Neat.
<StevenK> (Like chocolate biscuits, cookie dough, fruit pieces...)
<soren> I've tried that once, but I'm quite sure they'd ground it up first. That doesn't really work well with gummy bears, I think.
<StevenK> The gummy bears just get mixed in and go hard
<StevenK> Mango ice cream with mango pieces, gummy bears and M&Ms
<pitti> soren: I forgot, is that HÃ¤agen Dasz from Denmark, too? gooood stuff
<wgrant> StevenK: That sounds rather awesome.
<StevenK> wgrant: It's all kinds of awesome
<StevenK> I might have to hit up a local to see San Francisco has something similar
<wgrant> Heh.
<wgrant> Yay, UDS.
<soren> pitti: What do you mean "too"?
<soren> pitti: And no, HÃ¤agen Dasz isn't Danish, I'm afraid. It's good stuff, though :)
<pitti> soren: as in "ice cream without gummy bears, but other good ingredients"
<soren> pitti: Ah, I thought I missed someone talking about something else that was from Denmark. :)
<soren> Gah...
 * soren changes wifi driver
<wgrant> What? How can something with Ã¤a in it not be Danish?
<soren> For starters because we don't have Ã¤ in our alphabet :p
<wgrant> Blah!
<soren> We have a-z+Ã¦Ã¸Ã¥. No Ã¤.
 * StevenK is trying to remember which European languages use Ã¤
<wgrant> German is all I know.
<wgrant> Probably Norwegian or similar.
<StevenK> Finnish does
<soren> Swedish and Norwegian.
<liw> StevenK, Swedish, too
 * soren is suddenly not so sure about Norwegian.
<wgrant> $STEREOTYPICAL_EUROPEAN_LANGUAGE
<soren> No, not Norwegian. My bad.
<liw> StevenK, http://en.wikipedia.org/wiki/%C3%84
<StevenK> Ah.
<StevenK> German's use is different.
 * wgrant just thought to go to Wikipedia too.
<wgrant> But I didn't have a compose key set.
<StevenK> In Finnish and Swedish, it's a seperate letter, and German it's an accent
<wgrant> And was too braindead to consider copying it from the IRC window.
<soren> StevenK: Are you sure about that?
<soren> My German classes were in another millenium, but I seem to remember that it's a completely separate letter.
<liw> soren, mine were only 20 years ago, and I remember it being a variant of a, for all practical porpoises
<persia> soren, Wikipedia claims it's just "ae", and not actually 'Ã¦'
<tjaalton> hmm candy talk.. must bring some Turkish Pepper to UDS ;)
<slangasek> persia: in reference to German?
<wgrant> tjaalton: Turkish Pepper?
<persia> slangasek, Yes.
<tjaalton> wgrant: http://en.wikipedia.org/wiki/Tyrkisk_Peber
<slangasek> yes, umlaut in German is a stylized e
<soren> tjaalton: Ah, yes! Yet another Danish invention :)
<wgrant> tjaalton: So it's Finnish and Danish, rather than Turkish? Strange names.
<tjaalton> soren: hehe, yes :) But we ate the company, literally
<tjaalton> (Linus's blog also mentions salmiac)
<soren> tjaalton: Apparantly. I didn't even know that :)
<soren> I wonder when that happened..
<soren> 1996, it seems.
<tjaalton> soren: stores had them in a big plastic jars, and since the candy is hygroscopic, they'd get sticked together. When I was a kid my mom got those jars cheaply from a store, and we then tried to break the massive blob with spoons :)
<tjaalton> hmm, blob is not right..
<wgrant> I was fairly amused that the Wikipedia page actually mentions that they're hygroscopic.
<tjaalton> lump is better
<wgrant> Blob could be right.
<wgrant> But lump is probably better, yes.
<tjaalton> the jar was maybe 40cm high, so my arm barely reached the bottom :)
<soren> Heheh :)
<tjaalton> (25y ago)
<jordi> NCommander: I think there's a static dpkg build just for that kind of bootstrapping
<jordi> could be wrong though
<NCommander> Was it a bad thing that when I thought of jar, I thought of Java
<NCommander> jordi, its more of a toolchain issue, there are circular dependencies between glibc and gcc :-)
<NCommander> I could PROBABLY get away with just rebootstrapping the glibc packages and the toolchain
<NCommander> But I want to make sure everything gets built with pie, and I wanted to learn how to do a bootstrap for future reference
<tkamppeter> pitti, I have already uploaded the new pstopdf to the BZR yesterday (see my mail). It should at least fix a part of the bugs. My tests show at least that bugs of mis-centered printouts and the problem that PostScript printers (Kyocera, Xerox, ...) have pstopdf crashing are fixed. The garbage when printing with SpliX is perhaps SpliX itself.
<pitti> tkamppeter: I'm just walking through the bugs
<pitti> tkamppeter: some say that the new filter doesn't fix it
<pitti> tkamppeter: so for those we either need more fixes, or remove the bug references from the changelog
<pitti> tkamppeter: I think we should wait for more feedback for a couple of days, and if we have a clear "fixes it" or "doesn't fix", do an upload
<pitti> WDYT?
<tkamppeter> pitti, I did not get any feedback. The reporter of bug 293883 is on travel ...
<ubottu> Launchpad bug 293883 in cups-pdf "8.10 Printed PDF missing parts / corrupt" [Undecided,New] https://launchpad.net/bugs/293883
<pitti> tkamppeter: I saw quite a lot of feedback in the bugs...
<tkamppeter> bug 293832 is without answer
<ubottu> Launchpad bug 293832 in foomatic-db "printer prints page at wrong position, page cut" [Undecided,New] https://launchpad.net/bugs/293832
<pitti> tkamppeter: once you are content with a particular bug, please reassing it to cups and subscribe ubuntu-sru
<tkamppeter> pitti, bug 293832 seems really not to be covered, but also fixable in pstopdf, as you get it right by sending a PDF directly to CUPS, as then no pstopdf is involved and get it wrong if you send from evince, as evince sends the job in PostScript. Here I need your help as you have the actual printer and can reproduce the bug.
<ubottu> Launchpad bug 293832 in foomatic-db "printer prints page at wrong position, page cut" [Undecided,New] https://launchpad.net/bugs/293832
<pitti> tkamppeter: I can reproduce bug 292690
<ubottu> Launchpad bug 292690 in splix "Garbage bitmaps printed on left margin in ubuntu testpage on A4 on Samsung printers" [Undecided,Incomplete] https://launchpad.net/bugs/292690
<pitti> tkamppeter: the page position is actually fine for me, I just get the garbage
<tkamppeter> bug 289759 is fixed according to my tests and also according to one user, but there are still problems reported by another user
<ubottu> Launchpad bug 289759 in cups ""/usr/lib/cups/filter/pstopdf failed" in error_log and only blank page printed" [Undecided,Incomplete] https://launchpad.net/bugs/289759
<pitti> tkamppeter: ok; if the followup is an unrelated bug: as I said, please subscribe ubuntu-sru once you think that a particular bug is fixed by the patch
<tkamppeter> pitti, the one who complained that it still does not work for him probably did not do the download correctly, his error_log shows a syntax error in pstopdf
<tkamppeter> pitti, can you test bug 292690 with my new filter? Thanks.
<ubottu> Launchpad bug 292690 in splix "Garbage bitmaps printed on left margin in ubuntu testpage on A4 on Samsung printers" [Undecided,Incomplete] https://launchpad.net/bugs/292690
<pitti> tkamppeter: okay, let me walk over and test it there
<pitti> tkamppeter: btw, I thought gtkprint would spit out PDF now instead of PS?
<pitti> i. e. why does evince send out ps still?
<seb128> pitti: hey
<seb128> pitti: do you know if firefox3 and openoffice.org use gtkprint? the new comments on bug #248902 seem rather a cupsys issue no?
<ubottu> Launchpad bug 248902 in gtk+2.0 "Cannot print to remote authenticated printer" [Low,Incomplete] https://launchpad.net/bugs/248902
<tkamppeter> pitti, unfortunately, some GTK/GNOME apps do not use the function of GTK Print for which I made the patch. They do the PostScript generation by themselves or with another library (something older, Cairo, ...).
<pitti> tkamppeter: 292690 updated; unfortunately it doesn't fix it :(
<pitti> seb128: ffox looks like it's using gtkprint, the dialog is exactly the same
<pitti> seb128: OO.o still has its own thing
<pitti> looking at the bug
<pitti> seb128: hm, it says it works fine with lpr...
<seb128> pitti: thanks
<seb128> pitti: the recent comments
<seb128> pitti: I think they hijacked the bug for a different issue
<seb128> users tend to do that and that's annoying, when they don't know they should not guess and just open a new bug and mention the other one is the description
<pitti> seb128: according to the log, they are likely suffering from the same pstopdf problems that tkamppeter is just working on
<pitti> but also, seems they are trying to print to an SMB printer, which fails to log in
<tkamppeter> pitti, so you get the garbage of bug 292690 also with the "gdi" driver? Not only with SpliX?
<ubottu> Launchpad bug 292690 in splix "Garbage bitmaps printed on left margin in ubuntu testpage on A4 on Samsung printers" [Undecided,Incomplete] https://launchpad.net/bugs/292690
<pitti> tkamppeter: right
<pitti> tkamppeter: ISTR that splix didn't even work at all with pstopdf from intrepid final; shall I test that case again?
<tkamppeter> pitti, yes.
<pitti> ok, brb
<pitti> tkamppeter: ok, nevermind; same result with splix+old pstopdf
<pitti> tkamppeter: hm, if the bug is in the pstopdf filter, I wonder why it isn't reproducible when printing into a ps file
<tkamppeter> pitti, it looks like that it is the pstopdf filter according to your following comment: FYI, this happens if I print a PDF from evince. If I print it with "lp foo.pdf", the output is fine, so that's a temporary workaround.
<tkamppeter> If you do "lp foo.pdf" CUPS gets a PDF file and it goes directly through pdftopdf->pdftoraster->rastertoqpdl
<pitti> tkamppeter: if I remove that filter, cups should use the normal ps workflow, and it should work again?
<tkamppeter> pitti, yes
<tkamppeter> If you print from evince, the filter chain is pstopdf->pdftopdf->pdftoraster->rastertoqpdl
<tkamppeter> pitti, it looks like that for some files pstopdf does not use the correct page size for the conversion. This depends on certain conditions and needs to be investigated.
<tkamppeter> Can you print your PDF file with evince into a PostScript file and then run
<tkamppeter> cupsfilter -m application/vnd.cups-pdf -p /etc/cups/ppd/<yoursamsungqueue>.ppd evince.ps > output.pdf
<pitti> mvo, soren: anyone who could test ubuntu-vm-builder in hardy-proposed? It stacked a plethora of fixes, but no feedback for them
<mvo> pitti: I think I did the last sru so I'm probably not a good candidate
<mvo> but I would definitely welcome that
<tkamppeter> pitti, I have also fond a bug in evince which can have influence. Independent of your localization and /etc/papersize the "Print Setup" of evince is set to "US Letter". You can set it to "A4", bgut this does not get saved. When you close evince and open it again it is back to "US Letter". This is a possible cause for outputting bad PostScript.
<seb128> that's http://bugzilla.gnome.org/show_bug.cgi?id=525185
<ubottu> Gnome bug 525185 in printing "Make paper size persistent for printing" [Normal,Unconfirmed]
<seb128> or bug #224882
<ubottu> Launchpad bug 224882 in evince "Evince chooses default paper size the wrong way" [Unknown,Confirmed] https://launchpad.net/bugs/224882
<tkamppeter> pitti, when I take a PDF file in A4 and simply print it with evince into a PostScript file I get a Letter-sized PostScript where the original content is shrinked by around 2cm.
<directhex> whereas i can't even print in evince
<seb128> directhex: why not?
<directhex> problem with brother printers, i forget the bug #
<pitti> mvo: well, I don't mind that; if you know how the package works and use the actual -proposed .deb, please do it
<pitti> tkamppeter: I'll try the test now
<tkamppeter> pitti, evince prints only in the correct size if I manually set the paper size in "Page Setup".
<tkamppeter> pitti, doing this way should probably lead you to a good printout, but there is still a bug somewhere in the printing chain as if the page size is wrong the printer driver should not fill blank space with garbage.
<pitti> tkamppeter: I tried the cupsfilter -m application/vnd.cups-pdf ... test, and it produces correct PDF
<pitti> tkamppeter: I do get
<pitti> ERROR: No %%BoundingBox: comment in header!
<pitti> ERROR: No %%Pages: comment in header!
<pitti> tkamppeter: that's with intrepid's original pstopdf
<pitti> tkamppeter: bug updated (also tested with new pstopdf)
<sbeattie> pitti: any idea why the apparmor package for intrepid-proposed is still listed as needs building? https://launchpad.net/ubuntu/+source/apparmor/2.3+1289-0ubuntu4.1
<tkamppeter> pitti, as the garbage does not appear up to the post-pdftopdf state, it is produced by the driver. It seems that the input file has somewhere Letter dimensions inside, but the drawing is A4-sized. This makes the driver perhaps setting the printer to Letter and then sending an A4 bitmap, which leaves a small stripe of memory in the printer uninitialized which leads to the garbage.
<pitti> sbeattie: infinity told me that apparently soyuz got the build priorities the wrong way around, and first builds the thousands of jaunty packages, and then SRUs
<pitti> sbeattie: let me bump the priority
<sbeattie> pitti: thanks.
<pitti> tkamppeter: that makes sense
<tkamppeter> pitti, so take the output file of your last comment (/tmp/out.pdf, using the new pstopdf) and search it for the numbers 612 and 792. Which lines contain these numbers?
<pitti> tkamppeter: not contained at all
<pitti> tkamppeter: I can attach the file to the bug, if it helps you?
<tkamppeter> pitti, please do so.
<pitti> tkamppeter: done
<tkamppeter> pitti, thanks.
<tkamppeter> pitti, probably the PDF file has no completely white background but transparent areas at the borders (do not know any program to visualize that) Here it could happen that the driver renders garbage or leaves the printer with uninitialized memory.
<infinity> pitti: Not positive on when the rationale was laid down, but I suspect -proposed had the lower priority from back before we had the copy-from-proposed-to-updates workflow.
<infinity> pitti: So proposed really was a low prio queue at that point (sort of a "yeah, test this junk if you get around to it" thing)
<infinity> pitti: I still argue that devel breakage is often far more urgent than anything else though (ie: we upload something, find out it's HORRIBLY BROKEN, and want a fix in the next hour)
<infinity> pitti: If anything in a released series is that broken, sure, we can special-case it, but there shouldn't be any world-ending, causes-machines-to-stop-booting stuff in released dists.
<infinity> pitti: Classically, the queue orders on Debian buildds (or, the ones I ran) were "security > devel > proposed"
<infinity> pitti: But we've usually treated "proposed" as "nice-to-have updates and bugfixes, but not world-endingly critical", I thought.
<pitti> infinity: in confcall, will respond later
<liw> seb128, how can I attach a crash report if apport doesn't even notice the crash?
<seb128> liw: did you enable apport and start it as explained in the comment?
<liw> seb128, apport has been enabled all along
<seb128> liw: it's not running by default on stable versions
<seb128> liw: are you sure?
<liw> I checked...
<liw> yes, I am sure
<seb128> so talk to pitti about why apport is not working after his phone call
<seb128> or you have a .apport-something configuration saying to ignore those crashes?
<liw> I have not
<seb128> do you have anything in /var/crash?
<liw> /var/crash is empty
<seb128> ok, so talk to pitti about why apport is not working for you
<seb128> usually that's because it's not running but if you did enable it and ran apport start and still get the issue that's an apport bug
<liw> seb128, so you're not even going to care about .xsession-errors output?
<seb128> no, we need a debug stacktrace for a crash
<seb128> you can install all the dbg packages and use gdb if you really want
<seb128> that's extra work for you and it'll not have automatic duplicate checking etc, that's much nicer if you could try to get apport working
<seb128> you are sure it's crashing btw? not exiting or aborting because apport catches only crashes
<seb128> try running evolution under gdb and wait for the next crash
<liw> seb128, "crash" is not a technical term with a clear definition: I use it here to indicate that evolution goes away without my asking it to quit
<seb128> crash == segfault usually on bug trackers
<liw> I don't think that is a universal definition
<liw> but message understood, there's no point in reporting evolution bugs manually
<liw> only via apport
<seb128> not really but apport makes the job much easier for everybody
<brrt> simple question about releases: is ubuntu-8.10-rc really different from ubuntu-8.10-release?
<Hobbsee> brrt: yes
<brrt> how much?
<brrt> because I have got an iso from rc and if there isn't significant difference I just install rc
<seb128> liw: you can read http://wiki.ubuntu.com/DebuggingProgramCrash and get a stacktrace using gdb
<brrt> if there is I first download the release
<seb128> liw: that should at least tell you if it's crashing or exiting which are useful informations
<Hobbsee> brrt: this is a questoin for #ubuntu, but you can just do an upgrade after you install the rc, and you'll get to the final.
<seb128> liw: the bug right now has not enough details to be useful
<brrt> ok thanks
<tkamppeter> pitti, can you try out whether you can get rid of the garbage when running the pstopdf conversion with other Ghostscript parameters? Edit PS2PS_OPTIONS and PS2PDF_OPTIONS in pstopdf.
<liw> x-+
<tkamppeter> pitti, doc about the options you find here: http://ghostscript.com/doc/current/Ps2pdf.htm
<tkamppeter> pitti, I have uploaded a pstopdf with some parameters changed to the bug
<pitti> infinity: depends, I think; one week after intrepid, proposed is more important; one week before jaunty release, devel is more important
<persia> infinity, I suspect that autosync is a special case, as when 1500 packages get uploaded all at once (or more when Debian is less frozen), that can block critical bugfixes.
<Mithrandir> proposed will generally be much smaller than devel, won't it?
<infinity> persia: Why, I won't disagree that autosync time is a "special" time.
<persia> Mithrandir, Almost assuredly.
<infinity> pitti: You have the power to rescore proposed.  I'd suggest, honestly, that we just manually fiddle with proposed scores during autosync hell.
<pitti> infinity: yes, that's what I'm doing; I'm fine with that
<NCommander> infinity, I assume score values can only be calculated between archive sections, and not by releases?
<pitti> tkamppeter: can you please upload that to the bug report? I have to finish my conf call, and then leave for two hours
<pitti> tkamppeter: I'll test that in the afternoon then
<pitti> liw: was it a python or SIGSEGV-like crash?
<pitti> liw: in the latter case, you should have something in /var/log/apport.log
<tkamppeter> pitti, I have already uploaded it.
<liw> pitti, there is nothing in apport.log related to this (only to epiphany and synergyc)
<Kano> hi, has u an autodetection of macbooks for the special keyboard layout?
<liw> pitti, afaik evolution is not implemented in python, so presumably not that, either
<pitti> liw: does this work: bash -c 'kill -SEGV $$'
<liw> pitti, yes, yes, apport works, before and after evolution crashes
<pitti> liw: hm; if it crashes with an assertion, apport.log should have at least a note about it
<pitti> liw: if you open evolution and kill -SEGV it manually, do you get an apport.log snippet?
<liw> pitti, yes
<liw> apport (pid 8382) Thu Nov  6 13:54:58 2008: called for pid 7418, signal 11
<liw> apport (pid 8382) Thu Nov  6 13:54:58 2008: executable: /usr/bin/evolution (command line "evolution --component=mail")
<liw> modinfo: could not open cdrom: No such device
<pitti> liw: hm, I have no idea then; even if the core dump gets too large, apport.log has something
<liw> pitti, there is no core dump
<pitti> liw: maybe it didn't actually crash with a coredump, but through normal exit() or whatever
<pitti> I'm off for two hours, bbl
<gammy> G'day. In https://help.ubuntu.com/8.04/serverguide/C/user-management.html#where-is-root it does not mention that crontabs will stop functioning if the root account is locked.
<joaopinto> gammy, which crontabs? user's crontabs do not depend root's account
<gammy> joaopinto: crontabs run by root. /etc/cron.d/ stuff for example.
<joaopinto> for system crontabs, /etc/cron.d works just fine
<gammy> Lies.
<gammy> if I lock the root account, CRON just spits out "Authentication error" and never runs them.
<gammy> This caused quite a lot of problems for me :P
<gammy> Er, this is regarding ubuntu-server of course.
<persia> gammy, That's a known regression with intrepid, and only happens if the root account has been unlocked and relocked.  I believe there is a fix underway, which should be available soon.
<gammy> (As the documentation says)
<gammy> persia: Might you know where I can find information regarding this bug?
<joaopinto> gammy, next time please do not call me a lier, I am using 8.04, the documentation you are pointing is for 8.04, and I do not have such a problem
<gammy> "liar"
<gammy> :|
<gammy> And that was a joke.
<gammy> Actually it's odd. I thought I joined #ubuntu-doc, not -devel
<persia> gammy, I don't find it now, but I was sure I saw a bug with that description.  You might ask if anyone in #ubuntu-bugs remembers which one.
<gammy> persia: Also - I don't have intrepid installed. Perhaps that *is* the issue in of itself?
<persia> Oh, if you're using hardy, then I have no guess why you should encounter that at all, as I don't remember seeing a report about that against hardy.  You might still ask in #ubuntu-bugs.
<persia> Or maybe someone in #ubuntu can help you troubleshoot.
<gammy> Oh. Wait. intrepid is the name of 8.10..
 * gammy slaps forehead
<gammy> I thought it was the name of some daemon :D
<gammy> persia: Yes. this is indeed intrepid. So what you said is likely true
<gammy> Quick silly question: What is a Sigfile? Cron now whines about not finding it.
<gammy> Well, thank you for the assistance. Have a nice day!
<pitti> tkamppeter: you rock!
<pitti> tkamppeter: bug 292690 updated
<ubottu> Launchpad bug 292690 in cups "Garbage bitmaps printed on left margin in ubuntu testpage on A4 on Samsung printers" [Undecided,In progress] https://launchpad.net/bugs/292690
<tkamppeter> pitti, so the garbage goes actually away with my last approach of pstopdf (the third one in this bug report)? This means the bug is fixed?
<tkamppeter> pitti, can you then do one other check?
<tkamppeter> pitti, I have added "-dHaveTransparency=false" to the PS2PDF_OPTIONS in pstopdf. Can you test whether this is really needed by simply removing it (or setting it to true) and try again?
<Kalidarn> hi, in relation to this bug http://bugs.kde.org/show_bug.cgi?id=167767 apparently fixed in the kubuntu distribution
<ubottu> KDE bug 167767 in kwrite "kwrite doesn't show file contents if it contains only one line" [Major,Resolved: fixed]
<Kalidarn> im wondering what svn trunk patch is being used in KDE sources to fix it.
<Kalidarn> nobody ever replied to my request to know if it was possible to backport the patch from svn trunk to kde 4.1
<Kalidarn> (apparently the bug is fixed in svn trunk) ... its KDE 4.1.3 (and yes i don't use kubuntu) but what im trying to work out is what patch you guys are applying.
<Kalidarn> obviously it hasn't been applied to the 4.1 branch upstream
<Riddell> hi Kalidarn
<Riddell> Kalidarn: not sure off the top of my head, let me look
<Kalidarn> thanks
<Kalidarn> ;P cos this bug annoys the shit out of me ;)
<Kalidarn> Christoph Cullmann 2008-08-18 20:17:22  Seems to work with current /trunk, please retest
<Kalidarn> Dotan Cohen 2008-10-09 15:11:02  I can confirm that this is fixed in the KDE provided with Kubuntu 8.10. Thanks.
<Kalidarn> that was b ack in the days of KDE 4.1, and i've been hoping it would be ported back to 4.1.X (ie 4.1.2 or 4.1.3) but it looks like it has not.
<Kalidarn> unless ofcourse dotan is using a KDE build from svn trunk but i doubt that
<Kalidarn> because i doubt KDE would be 'providing a untagged build of kde with kubuntu 8.10' like he says
<Riddell> we've no patches to kate in kde4libs
<Kalidarn> :(
<Kalidarn> hmmm....
<Kalidarn> what build of KDE do you have atm?
<Kalidarn> or version
<Riddell> 4.1.3
<Kalidarn> ya can u test that bug to see if it exists
<Kalidarn> its really easy to test
<Kalidarn> and type "kwrite blahblah"
<stdin> https://bugs.launchpad.net/ubuntu/+source/kdesdk/+bug/259772
<Kalidarn> should give u a message about no file being called that.. and you should notice that no text shows up when you typ
<Riddell> Kalidarn: I can't recreate the problem
<Kalidarn> e
<stdin> is it that one?
<Kalidarn> right it must be fixed then
<ubottu> Launchpad bug 259772 in kdesdk "kate doesn't show symbols when opening empty file" [Low,Confirmed]
<Kalidarn> looking at that
<Kalidarn> sounds like it
<Kalidarn> >When I open "compile" then try to type stuff. The text is invisible.
<Kalidarn> yar thats exactly what i just said ;)
<Riddell> we've no patches to kwrite in kdebase
<Riddell> mysterious
<Kalidarn> that bug has a link to a duplicate of the one i pasted of upstream
<Kalidarn> so where the hell did it get fixed. because i've obviously got a unpatched copy :P
<Kalidarn> as im using archlinux (kdemod) atm
<Riddell> might be an idea to see if it affects debian
<Kalidarn> yer possibly.
<Kalidarn> what's their dev channel?
<Kalidarn> ah found it it's #debian-devel
<Riddell> Kalidarn: #debian-qt-kde on oftc
<Kalidarn> [01:37:48]--- Topic for ##debian-qt-kde is This unofficial channel is available as needed. Thank you for using freenode!
<tkamppeter> pitti, did you answer my last message? My connection got stuck and I had to reconnect.
<Kalidarn> and it has one user... chanserv ;)
<Kalidarn> im sure chanserv will be lots of help muahahahaha
<stdin> Kalidarn: on oftc
<Kalidarn> oh ;P
<Kalidarn> mm
<Kalidarn> sorry im tired i missed that :P
<stdin> irc.oftc.net
<Skiessi> !info lmms
<ubottu> lmms (source: lmms): Linux Multimedia Studio. In component universe, is optional. Version 0.3.2-1ubuntu2 (intrepid), package size 3424 kB, installed size 8136 kB
<Skiessi> "2008-10-31: LMMS 0.4.0 has been released!"
<Skiessi> is there some scheduled time for upgrading the packages? or could it be done now?
<Riddell> Skiessi: now is the best time
<Kalidarn> Riddell, apparently fixed in debian
<Kalidarn> too
<directhex> although another ":(" @ things being updated in ubuntu but not debian
<Keybuk> pitti: how do I make debcheckout use bzr+ssh?
<jcristau> Keybuk: debcheckout -a iirc
<NCommander> jdong, ping
<Riddell> Kalidarn: I don't see anything obvious in Qt either that would help it
<Riddell> so not sure I'm afraid
<Kalidarn> mm
<pitti> Keybuk: right, -a should DTRT
<jdong> NCommander: sup?
<pitti> tkamppeter: will do the test now, I have to reboot that other computer with the printer
<Keybuk> cjwatson: debconf merge redone in bzr
<Keybuk> it'd be really nice to have some way of saying if there's a usual upstream cvs as well
<Keybuk> XS-Upstream-Vcs-Bzr: ?:p
<cjwatson> Keybuk: XS-Debian-Vcs-*
<Keybuk> that contains an svn url
<Keybuk> obviously lp:debconf works rather nicely
<cjwatson> yes ...?
<cjwatson> oh, you said "usual upstream cvs"
<cjwatson> I didn't realise you meant bzr
<Keybuk> usual one you merge from I mean
<cjwatson> hmm
<Keybuk> I guess we should really be adding a XS-Debian-Vcs-Bzr: in there as well along with our Vcs-Bzr
<pitti> tkamppeter: setting it to true works as well; noted in the bug report
<cjwatson> sort of seems like lp:<project> should always DTRT if it exists
<Keybuk> is it XS-Debian- or XS-Original- ? :p
<cjwatson> should be XS-Debian, I've already changed almost all the branches I care about from XS-Original to XS-Debian after being reminded by the discussion yesterday
<cjwatson> I have an appropriate diff for debconf in my working copy but didn't want to commit it until you'd sorted out your merge
<Keybuk> pushed
<cjwatson> committed XS-{Original,Debian} fix
<cjwatson> thanks
<Keybuk> actually, from doing that, I can see why you generally like using bzr that way
<tkamppeter> pitti, thanks. Can you also remove it and see whether pstopdf works without Garbage on the Samsung?
<Keybuk> the merge is easy, since it's just "bzr merge"
<pitti> tkamppeter: argh, just shut that machine down again :)
<cjwatson> I do agree that it's a real mess when not all the files you need are in revision control
<pitti> tkamppeter: so true isn't the default either?
<pitti> tkamppeter: okay, will do
<cjwatson> I was thinking of redoing ubiquity/oem-config so that 'debian/rules update' isn't necessary after checking out
<Keybuk> yeah, just trying to think a way of sorting that out atm
<cjwatson> and just commit all the d-i/source/ stuff
<Keybuk> would be nice to move udev and upstart to bzr packaging
<Keybuk> but they're both difficult
<cjwatson> it would give us a more easily reconstructable historical record
<Keybuk> upstart is maintained in bzr upstream, but without the autogenerated files
<cjwatson> udev due to git upstream?
<Keybuk> so I'd need an intermediate "tarball" branch
<Keybuk> and right
<Keybuk> udev uses git
<cjwatson> git upstream is actually handleable
<cjwatson> it just takes a little creativity
<Keybuk> stick a .git and .bzr in the same directory
<Keybuk> remember to type "git" when updating from upstream
<cjwatson> didn't mean that :-)
<Keybuk> and "bzr" when committing ;)
<cjwatson> git fast-export | bzr fast-import -
<Keybuk> oh, I don't know that one?
<cjwatson> lp:~bzr/bzr-fastimport/fastimport.dev
<cjwatson> it's one of the category of tools that you often have to hack a bit to make it do what you want; the flip side is that it isn't a black box at all so you *can* hack it to deal with weird special cases
<Keybuk> what do you do?
<Keybuk> git checkout in one directory
<Keybuk> maintain a bzr import alongside, and run that to keep it up to date?
<cjwatson> right
<Keybuk> then a third packaging directory alongside that?
<cjwatson> my import script for debian-policy looks like this:
<cjwatson> #! /bin/sh
<cjwatson> [ -d .bzr ] || bzr init-repo .
<cjwatson> (cd ~/src/packages/debian-policy/git/policy && git fast-export --signed-tags=strip master --tags) | bzr fast-import -
<cjwatson> that creates lp:~kamion/debian-policy/master
<cjwatson> and then lp:~ubuntu-core-dev/debian-policy/ubuntu is a branch from that
<cjwatson> this is strictly inferior to git imports in Launchpad, and it's possible that I might have to rebase or something when those turn up
<cjwatson> but I can probably cope with that
<cjwatson> I actually found bzr fast-import when I was trying to do some very, very custom one-time imports
<cjwatson> I have a long-term project to migrate all my private Debian svn packaging branches over to bzr branches that are true branches of upstream
<cjwatson> and I want to keep all the history intact
<pitti> tkamppeter: tested, bug updated
<cjwatson> bzr fast-import is hackable enough to let me say "OK, so this revision here, I actually want it to be a merge from that revision of that branch over there as well as including the patch content it claims"
<Keybuk> why init-repo ?
<cjwatson> bzr fast-import really likes to have a repository - I think it's because it can potentially import multiple branches
<cjwatson> the short answer is "because it broke when it didn't" :-)
<Keybuk> bzr: ERROR: exceptions.KeyError: None
<Keybuk> :-/
<cjwatson> what's the URL for udev git?
<Keybuk> git://git.kernel.org/pub/scm/linux/hotplug/udev.git
<cjwatson> git imports are something like number two on the LP code priority list, so this should get sorted out soon even if we can't get bzr fast-import working
<Keybuk> hmm, actually, git fast-export is erroring
<Keybuk> maybe that's what's choking it
<cjwatson> sometimes need to tweak the options there
<Keybuk> seems to be --tags ?
<Keybuk> what does that do
<cjwatson> note that the output is a text stream - in extremis it can make sense to sed the bugger :)
<cjwatson> git help rev-parse
<cjwatson>        --tags
<cjwatson>            Show tag refs found in $GIT_DIR/refs/tags.
<cjwatson> you can leave that out reasonably enough
<Keybuk> yeah, without that it seems to work nicely
<Keybuk> it's done 1,000 commits so far
<cjwatson> do check the output pretty carefully; I suggest diffing at some specific revisions or something
<cjwatson> and check things like exec bits that won't show up in diff
<Keybuk> meh, tracebacked again :-/
<cjwatson> I have a few crazy patches lying around that deal with complicated directory structure rearrangements
<cjwatson> but they slow it down a lot and I'm not entirely confident in them
<Keybuk> I'll have to debug that a bit more later
<cjwatson> anyway, feel free to file it in the category of "neat idea, needs polish" :)
<Keybuk> this cycle I want to drop all of our patches to udev
<cjwatson> hmm, yeah, breaks for me too
<cjwatson> bzr: ERROR: parent_id {etcudevslackware-20081106160805-210n85iwk7nvgmkv-1477} not in inventory
<Keybuk> (of which there are only really rules ones remaining)
<cjwatson> even with my crazy patches
<tkamppeter> Thanks, pitti, uploaded into the BZR and to upstream (OpenPrinting). I have also updated changelog. Can you now upload it to Debian and Jaunty? Then we will request an Intrepid SRU for the pstopdf fix (and perhaps also to your AppArmor config fix).
<pitti> tkamppeter: yep, I planned to SRU the apparmor one, too
<cjwatson> Keybuk: I have once done the trick of having a single directory in two revision control systems at once ...
<pitti> tkamppeter: are all other referenced bugs confirmed fixed with the new script?
<Keybuk> cjwatson: the nice thing is you just do "git pull;bzr commit"
<cjwatson> a previous company had a CVS repository that you could check out as ~/.vim/, with some handy bits and pieces
<Keybuk> the bad thing is  you don't really end up with a useful bzr repository as a result
<cjwatson> I had my home directory in svn, including ~/.vim/
<cjwatson> so I just made it be both at once and didn't necessarily add all the files on either side
<liw> mvo, does python-apt handle translated package descriptions?
<pitti> tkamppeter: hm, did you push?
<timrc> Does apt try to install packages with no inter-dependencies in parallel or is package installation done linearly regardless of relationship (or lack there-of) ?
<wasabi> Linearly.
<wasabi> Odd race conditions could exist otherwise in scripts invoked by the individual packages.
<pitti> tkamppeter: e. g. bug 282186 isn't tested yet; mind if I drop the bug reference and instead we ask the reporter to test with the new version?
<ubottu> Launchpad bug 282186 in hplip "HP Photosmart 2610 top first cm not printed" [Undecided,Incomplete] https://launchpad.net/bugs/282186
<wasabi> timrc: Why that question?
<timrc> wasabi: I was just curious, I kind of like the idea of efficiency... but I see your point
<wasabi> Well, there are some things which can be done to speed up dpkg.
<wasabi> Some of which I've played with. Which is why I find your question interesting.
<wasabi> The largest problem with it is the sync IO that it ends up doing.
<tkamppeter> pitti, confirmed as fixed are: bug 292690, bug 289759.
<ubottu> Launchpad bug 292690 in cups "Garbage bitmaps printed on left margin in ubuntu testpage on A4 on Samsung printers" [Undecided,In progress] https://launchpad.net/bugs/292690
<ubottu> Launchpad bug 289759 in cups ""/usr/lib/cups/filter/pstopdf failed" in error_log and only blank page printed" [Undecided,In progress] https://launchpad.net/bugs/289759
<jdong> wasabi: it's hardly ever the unpack phase IMO that can benefit from parallelization
<wasabi> jdong: it is.
<pitti> tkamppeter: yep, just walking through them
<tkamppeter> bug 282186 I could reproduce and with my fixed pstopdf it is fixed.
<ubottu> Launchpad bug 282186 in hplip "HP Photosmart 2610 top first cm not printed" [Undecided,Incomplete] https://launchpad.net/bugs/282186
<jdong> wasabi: look at postinst/configure phases
<wasabi> But not the kind of paralization you think of.
<jdong> wasabi: it's annoying when update-initramfs is spending 30 seconds compressing modules, then scrollkeeper spends another 10s pegging CPU , etc
<pitti> tkamppeter: and e. g. 293832 is confirmed not fixed
<wasabi> Unpacking causes many many many IO blocks. That is, when unpacking a file, it stats for an existing file, then extracts, then stats, then extracts. Each stat waits for IO.
<pitti> tkamppeter: can you please bzr push?
<tkamppeter> bug 293832 is not fixed, it seems that that one is not caused by pstopdf.
<ubottu> Launchpad bug 293832 in foomatic-db "printer prints page at wrong position, page cut" [Undecided,New] https://launchpad.net/bugs/293832
<jdong> wasabi: I'm not saying unpacking isn't a big time waster, I'm saying that parallelization probably will benefit the postinst state a lot
<wasabi> jdong: No, really. You can speed up an apt run by about two times by making a little Pre script that issues async requests to stat every file involved.
<wasabi> Done it.
<jdong> but as mentioned, the race conditions involved are really annoying
<timrc> wasabi: that's really interesting, actually
<tkamppeter> pitti, sorry, I have forgotten that. Now I have done the "bzr push".
<jdong> wasabi: I am sure statting all the files en masse will help
<wasabi> Yup, it helps a *lot*
<jdong> but that's not really parallelism
<pitti> tkamppeter: thanks; I'll drop the unconfirmed patches and prepare the sid/jaunty upload now
<wasabi> No, it's not.
<jdong> in fact that's quite the opposite
<jdong> that's avoiding parallelism due to seek/wait times :)
<wasabi> Well, it's  paralizing IO, in a way.
<jdong> no, it's deparallelizing IO :)
<jdong> rather, reordering it intelligently
<jdong> or optimistically.
<wasabi> Yeah, you are right.
<tkamppeter> pitti, the reporter of bug 293883 is on travel, so we do not know.
<ubottu> Launchpad bug 293883 in cups-pdf "8.10 Printed PDF missing parts / corrupt" [Undecided,New] https://launchpad.net/bugs/293883
<wasabi> Issue all the async stats, the kernel can reorder them, do them in fewer requests.
<tkamppeter> pitti, which unconfirmed patches?
<pitti> tkamppeter: I know; we'll just wait
<jdong> but between instaling things fast and installing them reliably, I think I know which one I prefer :)
<wasabi> jdong: I think though it's a simple way to get some large speed increase out of dpkg.
<pitti> tkamppeter: sorry, "unconfirmed bug refs"; but you did already
<wasabi> Well, pre-stating does not cause unreliability.
<jdong> wasabi: I think the main "brokenness" is stats are too expensive :)
<timrc> To do parallelization would require you walk dependency trees (and if you want to absolutely avoid configuration conflicts) you'd have to walk the file lists... and the return would be greatly diminished in terms of time and even the probability that you'd be able to install in parallel
<wasabi> jdong: The main problem with any IO is that it's sync. It should be async.
<jdong> wasabi: it also doesn't necessarily help a lot on filesystems with fast stats.
<jdong> i.e. reiserfs
<wasabi> Well, I don't think it's realistic to paralize package installs.
<wasabi> So, that's a no go.
<pitti> tkamppeter: so for 282186 you could reproduce it yourself and it's fixed for you?
<jdong> wasabi: for now I agree
<wasabi> The effort to do that would be massive, and package maintainers would have a huge new thing to consider.
<wasabi> With many many corner cases.
<wasabi> That only exhibit on SMP machines.
<jdong> wasabi: yeah, brings a WHOLE new set of QA challenges to the plate
<tkamppeter> pitti, yes.
<timrc> My other gripe with apt right now may actually be a personal probably... I find myself in situations where I'll absentmindedly try to install something from the console with aptitude while synaptic is open... it'd be great if there was an 'apt queue' which all these various apt front-ends would queue packages on... let the queue handle ordering and installation
<jdong> I doubt all of our postinsts are parallel-safe
<pitti> tkamppeter: cool, thanks; I modified the bug accordingly
<wasabi> I doubt many of them are.
<wasabi> And Id oubt we have any sort of ability to vet them
<jdong> timrc: that would be cool but difficult to implement
<wasabi> timrc: PackageKit or whatever is supposed to solve that.
<wasabi> Though I have no idea how Ubuntu views that.
<timrc> wasabi: hm, I'll investigate... thanks for the tip :)
<jdong> timrc: particuarly if you install package a, b,c, then queue d which conflicts b and a, etc etc
<wasabi> Nor whether it's even sane software.
<wasabi> Synaptic should not lock teh database while open.
<wasabi> That should be fixable.
<tkamppeter> pitti, we have three bug confirmed to be fixed by my new pstopdf, and they are all of high impact, so I think we can do the SRU even without waiting for bug 293883
<ubottu> Launchpad bug 293883 in cups-pdf "8.10 Printed PDF missing parts / corrupt" [Undecided,New] https://launchpad.net/bugs/293883
<jdong> wasabi: I think it must in order to consistently build a package marking set to apply
<pitti> tkamppeter: yes, I agree
<wasabi> jdong: Can't it op;en teh database only when it needs to?
<pitti> tkamppeter: just saying that I don't like to auto-close 293883 until we got confirmation; but I'll ask there to test the intrepid SRU
<timrc> jdong: why wouldn't you be able to detect that conflict with a queue implementation?
<jdong> wasabi: how does it know it doesn't need to recalculate every previosu marking every time you make a selection?
<wasabi> jdong: It might. Can't it do that by reading the database once?
<jdong> timrc: you would be able to, but that might abort previously queued installations in ways previous programs are not aware
<jdong> timrc: and the actual set of packages to be installed or removed might change after you agreed to the install
<wasabi> jdong: Launch, read. Operate on read information. Apply: Open, check to see if marked stuff is still sane, apply.
<jdong> wasabi: what if it is no longer sane?
<jdong> wasabi: undo all the user's markings and start over again?
<wasabi> Naw, just make them right. :0
<jdong> wasabi: I think locking the DB and preventing other package installs while the user is marking is entirely sane
<jdong> wasabi: "make them right" might be a relative term :)
<jdong> wasabi: if I install apache-mpm-prefork and a bunch of strict subdepends while the user marks apache-mpm-worker, have fun convincing the userbase what is the right thing to do :)
<pitti> tkamppeter: btw, do you know about Mike's plans to adopt the PDF workflow/filters?
<wasabi> Ahh well. timrc, it's pretty trivial to do the prestat thing.
<wasabi> I had some code for it, I seem to have lost it.
<timrc> wasabi: yeah, I like that idea
<wasabi> pre-stat isn't how it should eb done though.
<wasabi> It's just an interesting way to test teh idea.
<jdong> read: hack.
<wasabi> yeah.
<jdong> :)
<jdong> not saying we don't do the same anyway *cough readahead-list*
<wasabi> What should happen is dpkg should take all the operations it intends to do, all the stating, and submit them using Real Async IO
<wasabi> And then as those requests complete, issue new requests.
<wasabi> The dpkg-prestat crap I did just spawns a bunch of forks of 'stat'
<wasabi> So, bunch of useless processes.
<wasabi> But it was still quite a speed improvement.
<wasabi> Quick little shell script hack.
<jdong> wasabi: probably building a statcache using some batch operation at the kernel/vfs level would be faster even
<jdong> and much less thrashing around
<wasabi> jdong: yeah. I know almost nothing about the kernel's IO layer, nor async APIs
<jdong> probabilistic/markov stat associative readahead :)
<jdong> lol kidding
<wasabi> But the idea of an async API is you should just be able to call async_stat(file, cb) repeatidly.
<wasabi> And the kernel should do it's own reordering and smartness, and cb should be invoked as results filter in
<wasabi> or yeah, some sort of batch submission.
<wasabi> But I doubt we have that.
<tkamppeter> pitti, Mike did not answer anything about his plans on http://www.cups.org/str.php?L2897
<wasabi> All my little hack was doing was priming the page cache.
<tkamppeter> CUPS bug 2897
<jdong> wasabi: right, we could use a bunch of kernel-layer APIs for priming the page cache
<wasabi> Well, i'd still not prime the page cache.
<wasabi> As you can never guarentee the page cache size.
<wasabi> So you could end up dumping too much, and defeat yourself.
<wasabi> You just need an async queue that can be invoked as appropiate depending on teh device's ram, etc.
<jdong> wasabi: not really, Windows prefetching mechanisms don't suffer from those issues.
<wasabi> How not?
<jdong> a smarter / more aware pagecaching system isn't entirely unreasonable
<wasabi> If I say stat 1000 files, and the last 500 files throw out the first 500.
<wasabi> Then I haven't helped.
<jdong> wasabi: it builds "bundles" of "caches" in C:\Windows\Prefetch
<wasabi> Oh. I don't think that's useful.
<wasabi> That's for fixing crappy software.
<jdong> wasabi: whether or not the extra IO overhead it generates is useful is up for debate
<wasabi> That software should be using async APIs to begin with.
<wasabi> And there would be no problem.
<jdong> wasabi: async APIs doesn't solve disk seeking issues.
<jdong> wasabi: i.e. starting up openoffice
<jdong> wasabi: the second startup on Windows even after a coldboot is almost double the speed
<wasabi> If you start up open office, and the first thing the code does is issue an async request for each bit of data it will need throughout the entire process, and then as those pieiecs arive, it operates on them, then the problem solves itself.
<pwnguin> if you do async writes, you better be prepared to handle async write failure
<jdong> wasabi: not really, there's sequential dependencies on each component.
<jdong> wasabi: loading an entire program by async storms is entirely nontrivial
<wasabi> How deep?
<jdong> wasabi: probably a linear chain
<wasabi> And how are those dependencies expressed?
<jdong> wasabi: probably by natural imperative flow of the startup procedure
<wasabi> I dunno. I'd be curious to see it graphed.
<jdong> wasabi: at any rate, all I'm pointing out is that the Windows prefetch layer can, without any modification to applications, often turn a random set of read operations into a single contiguous IO request
<wasabi> Yeah. I get ya.
<jdong> and it wouldn't be entirely unreasonable for us in Linux world to get something like that
<wasabi> We've tried before.
<wasabi> With various levels of success
<jdong> wasabi: AFAIK the COW system in ZFS and friends already do similar things with being able to represent random writes as a single sequential write
<wasabi> preload - adaptive readahead daemon
<pwnguin> jdong: ever seen seekwatcher?
<jdong> wasabi: preload is a pretty ugly userspace hack though
<wasabi> yeah, it is.
<jdong> wasabi: it could be done better :)
<wasabi> So we were talking about dpkg.
<jdong> pwnguin: no, heard of it
<wasabi> Superfetch-like stuff doesn't really apply.
<wasabi> As the IO semantics are not repeatitive between runs in any way.
<jdong> wasabi: it is a seek-heavy workload
<wasabi> Sure, but there's nothign to record.
<wasabi> You can't record somebody installing gnome, and then use it to usefully make installing eclipse faster.
<jdong> well why are you seeking so much?
<jdong> there's got to be a reason why your requests are seemingly random
<wasabi> They're not, they're just ordered with waits in between.
<jdong> and there must be a way to group that
<pwnguin> jdong: ah; i think it'd be neat to chart out readahead
<jdong> why are there waits in between?
<wasabi> for each file { stat file; wait for stat; write new file; relink; }
<jdong> wasabi: what if after the 5th file statted, the kernel has a probabilistic model of the next 500 stat requests from the process and begins to lookahead? :)
<wasabi> The writes get deferred, but the stats must be finished before proceeding.
<wasabi> jdong: Then that's awesome. but the only way to build that model is for dpkg to submit it.
<jdong> wasabi: this can probably be done with a markov chain type model for each process
<wasabi> for each file { submit stat request to kernel; callback to X }    X  { write new file; relink }
<jdong> wasabi: generic implementation-agnostic probabilistic readahead at the kernel level :)
<wasabi> Dude. it can't figure out what dpkg is about to do
<wasabi> It has no way to know the files dpkg is about to work on.
<jdong> wasabi: sure it can. from experience.
<wasabi> What, reading the .deb files itself?
<jdong> wasabi: the first set of writes will be expensive
<jdong> wasabi: the the next time you unpack the same app it will be inexpensive.
<wasabi> Sure, but that doesn't happen that often.
<jdong> we can prepopulate this cache per-install
<wasabi> Oh. I don't think that's going to wrok at all.
<wasabi> That's ungodly complicated.
<pwnguin> http://oss.oracle.com/~mason/seekwatcher/
<wasabi> Takes up space for a profile of each possible instaleld app?
<jdong> wasabi: sure it is, but it's a properly engineered solutions with applications to EVERY app that is IO intensive.
<wasabi> Somehow you need to have this huge profil daemon thing... dpkg still needs to somehow submit the profile to it.
<jdong> wasabi: how much space do you think a list of blocks needs?
<wasabi> They're not blocks.
<wasabi> Each install moves the file.
<pwnguin> is apt percieved to be slow?
<jdong> pwnguin: some people do stare at their apt installs
<jdong> for one reason or another.
<wasabi> I don't think it's slow.
<wasabi> I just think it can be much faster. :)
<jdong> I can't think of ONE performance-critical usecase of apt
<pwnguin> i mean, scrollkeeper
<wasabi> Triggers removed the only complaint I had.
<pwnguin> jdong: install?
<jdong> pwnguin: we don't even use apt to install these days
<pwnguin> dist-upgrade?
<wasabi> I do. :0
<jdong> except on the alternate
<cjwatson> and server
<wasabi> I've never used the Live CD installer.
<wasabi> And I probably never will. heh.
<dilinger> hi, how do i get myself off a bug notification list?
<dilinger> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/294527
<ubottu> Launchpad bug 294527 in nvidia-graphics-drivers-177 "Conflict between nvidia-glx and openafs-modules kernel module" [Undecided,New]
<liw> incidentally, wasn't installing from the live cd supposed to be faster than from the alternate?
<jdong> has anyone ever tried doing upgrades on a tmpfs+ext3 unionfs? :D
<jdong> liw: of course
<dilinger> i was automatically added to that bug because i one did openafs stuff, but i don't work it it anymore.. and i see no way to unsubscribe myself
<dilinger> s/one/once/
<cjwatson> dilinger: https://bugs.launchpad.net/openafs/+subscribe maybe?
<liw> because when I did ISO testing under kvm, I could start booting a live install, then start it installing, and then boot+install+test an alternate ISO in parallel
<liw> might be a kvm quirk, of course
<jdong> liw: the livecd is just a simple copy proceedure for installing while the alternate cd uses dpkg -i on a bunch of debs
<liw> jdong, yes, I know that
<dilinger> cjwatson: that offers me the option to subscribe
<jdong> liw: a VM also restricts your block device to a much smaller seek radius
<cjwatson> dilinger: I don't know, then - I suggest asking #launchpad for advice
<jdong> liw: and in fact on my main system I can fit an entire VM's blockdevice and installation image into pagecache
<cjwatson> liw: how much memory did you give the live install?
<jdong> and I could do a 2 minute live install from start to finish
<liw> cjwatson, a gigabyte (same as the alternate)
<cjwatson> liw: a gotcha is that kvm's default memory size is 128MB, which dooms the live CD to swapping a lot
<cjwatson> liw: ok
<liw> jdong, I could fit both kvm's, both isos, and both virtual disk images in RAM at once, so I doubt that was the problem
<jdong> liw: the question is whether or not the OS was doing that :)
<jdong> on a 1TB XFS volume it was quite apparent that was the case
<jdong> pdflush disabled
<jdong> (no I don't recommend that setup :D)
<pitti> mvo: did you upload this? http://launchpadlibrarian.net/19389671/gnome-terminal_2.24.1.1-0ubuntu1_source.changes
<pitti> mvo: in case you did, it's missing a bug ref in the changelog
<pitti> mvo: ah, it was you
<kirkland> pitti: hey, thanks for the raid backport review
<kirkland> pitti: i have a couple of responses to your questions
<pitti> kirkland: hi; sorry for being picky
<mvo> pitti: ups, sorry :/
<mvo> pitti: pleae reject
<pitti> well, not sorry for being picky, but for the additional work it creates
<kirkland> pitti: you want them here, via synchronous conversation, or back in the bug report
<pitti> mvo: already done
<kirkland> pitti: no worries at all!
<kirkland> pitti: this stuff needed a critical eye
<pitti> kirkland: I actually prefer bug report, for keeping a record
<kirkland> pitti: this is by far the most complex backport i've ever done for Ubuntu ;-)
<pitti> kirkland: but if you have questions which need discussion, IRC is fine
<kirkland> pitti: well, two minor ones, i think would help to mention here
<kirkland> pitti: i'll record the summary in the bug report
<pitti> kirkland: yeah, and we actually don't backport features either, so the entire thing is an exception
<kirkland> pitti: " - panic(): Why the chvt 1? Boot messages are usually on VT8, and this changes behaviour of an existing function."
<kirkland> pitti: see https://edge.launchpad.net/ubuntu/+source/initramfs-tools, changelog for 0.92bubuntu12
<kirkland> pitti: i added an inline comment to the shell in this next iteration
<kirkland> pitti: there's a prompt that comes up, "Do you want to boot your degraded RAID?  [y/N]: ", which times out after 15 seconds
<pitti> kirkland: chvt> yes, for the raid case; but my concern is that other initramfs-tools scripts might call panic(), too, and this changes behaviour for those
<pitti> kirkland: maybe the chvt cna be done right where the prompt for mdadm is done, instead of in existing code paths?
<kirkland> pitti: that seems fair, i'll need to do some testing
<kirkland> pitti: okay, the other one ....
<kirkland> pitti: the code removed from panic()
<pitti> mvo: I won't accept u-m right now; we already have two SRU uploads stacked in -proposed
<pitti> mvo: the second one is verified, but none of the three bugs of the first
<kirkland> pitti: this is due to the way we've separated the try_failure_hooks() and the panic() calls in scripts/local
<kirkland> pitti: perhaps we're going to need a new panic() function
<pitti> kirkland: right, that was an underlying problem, too, it changed the API
<kirkland> pitti: just_panic()
<kirkland> pitti: whereas the current one tries-failure-hooks-then-panics()
<mvo> pitti: I agree with that plan, while the evms issue is anoying I think its rare enough to justify the that
<pitti> mvo: I hope that the reporters or QA team can test the others soon; u-m fixes are quite urgent those days, when many people upgrade
<mvo> pitti: absolutely, I talk to ubuntu-qa and ask if they can prioritize it
 * pitti hugs mvo, thanks
<pitti> jdstrand: in bug 271252 you tested the actual .debs from -proposed
<pitti> ?
<ubottu> Launchpad bug 271252 in apparmor "aa-logprof generates faulty output messages" [Undecided,Fix committed] https://launchpad.net/bugs/271252
<mvo> thanks pitti :)
<jdstrand> pitti: yes-- which is why I waited til today to comment :)
 * mvo needs to find out how to create a evms parition anyway before the verification for the one in the queue can begin
<pitti> jdstrand: cool, thanks
<tkamppeter> pitti, thanks for uploading the new CUPS package and doing the SRU request.
<pitti> tkamppeter: no problem; thanks a lot to you for figuring out the fixes :)
<jdstrand> pitti: np
<pitti> tkamppeter: the SRU is uploaded and accepted, waiting for feedback now (well, still needs to build, but I prioritized the SRUs)
<NCommander> oooh, new shiny icons
<liw> mvo, does python-apt support package description translations?
<kirkland> pitti: can you give this a once-over?  http://pastebin.ubuntu.com/68445/
<kirkland> pitti: see if that addresses your concerns
<kirkland> pitti: it's a _royal_ pain to test
<kirkland> pitti: so it would help if you can at least spot check it for your concerns, and I'll go FVT it
<mvo> liw: yes, out of the box
<mvo> liw: so python -c 'import apt; print apt.Cache()["apt"].description' should DTRT
<liw> mvo, ok, good, then I just haven't them configure
<mvo> liw: what locale do you use?
<liw> mvo, I'm actually using summary and not description, but I assume that doesn't matter
<liw> mvo, fi_FI.UTF-8
<mvo_> RainCT: hey! if you are interessted in apturl, I did some code refactoring in http://bazaar.launchpad.net/~ubuntu-core-dev/apturl/ubuntu - it should be *much* nicer now
 * RainCT pulls
<ScottK> mvo_: Is it still going to hard depend on synaptic or will it be front end agnostic?
<mvo_> RainCT: well, the code should be much nicer :)
<mvo_> ScottK: I put some effort into it today to make it frontend agnoistic
<ScottK> mvo_: That's great news.  Glad to hear it.
<mvo_> ScottK: it should be really easy now to write a qt frontend by just filling in the (few) needed UI functions
<mvo_> ScottK: it was on my agenda for some time, I finally got around doing it :)
<mvo_> I think rgreening was interessted in working on this
<ScottK> mvo_: Yes.  That's my recollenction too.  I've just ping'ed him on #kubuntu-devel.
<rgreening> mvo: ping
<mvo_> ah, hello rgreening
<mvo_> rgreening: I did the refactoring we talked about the other day in apturl
<mvo_> rgreening: its in the ubuntu branch (http://bazaar.launchpad.net/~ubuntu-core-dev/apturl/ubuntu/files)
<mvo_> let me know if there is anything I can help with
<mvo_> AptUrl/UI.py and AptUrl/gtk/GtkUI.py should be good starting points
<rgreening> ty mvo_
<mvo_> my pleasure
<rgreening> mvo_ I added this to the Jaunty specs page so it won't get lost :)
<RainCT> mvo_: there's already a get_dist function in AptUrl/Helpers.py :P
<RainCT> mvo_: to call lsb_release -c -s
<RainCT> mvo: but the changed look great :)
<RainCT> *changes
<mvo> rgreening: cool
<mvo> RainCT: oh, I thought I killed the duplicated one, will do that now (unless you beat me to it :)
<RainCT> mvo: oh, seems like you have, my fault :)
 * RainCT checked the diffs
<RainCT> mvo: I've fixed two typos in my branch, btw
<RainCT> (lp:~rainct/apturl/ubuntu)
<mvo> excellent, thanks RainCT
<gicmo> network .... slow ....
<psycardis> Why jigdo download not available for the standard 8.10 install disc?
<mvo> RainCT: merged
<persia> psycardis, No benefit : most of that disc is a single file.
<psycardis> Is that not the case with all of the other install discs?
<persia> The alternate CDs have lots of individual files, rather than one big one.
<persia> (these are files *inside* the ISO, the ISO itself is always one big file)
<tedg> Okay, so if I want to SRU something into Hardy, does it have to be SRU into Intrepid first?
<persia> tedg, Technically no, but if the bug is open in intrepid, it's standard practice to fix it there first.
<persia> Essentially, users who haven't upgraded are expecting a higher degree of stability, and so the fix should first be presented to the most recent users for additional time to collect regression data.
<persia> Exceptions are mostly bugs that affect hardy, but don't affect intrepid.
<tedg> persia: Okay, so I should SRU it into Intrepid.  Wait a while, and then SRU it into Hardy (assuming it gets approved of course)
<persia> tedg, That's the standard practice for an SRU that affects both intrepid and hardy.  If you think it's *really* critical, stick it in both -proposed queues at the same time.
<psycardis> Sorry had to step out, even the non-alternative install variations of ubuntu with the exception of ubuntu desktop have jigdo links, the only one lacking it is ubuntu desktop live cd
<persia> psycardis, Hrm?  None of the LiveCDs benefit from jigdo.
 * persia looks at releases.u.c
<tedg> persia: Not really critical, but effects large installations, so should probably go into an LTS.  Isn't a crash as much as a usability issue.  bug 203217
<ubottu> Launchpad bug 203217 in fast-user-switch-applet "fast-user-switch heavy cpu usage" [Undecided,Confirmed] https://launchpad.net/bugs/203217
<persia> tedg, That's something that would probably benefit from some testing in intrepid before it hit hardy, unless the other FUSA changes render the code-path obsolete.
<tedg> persia: Fortunately not this one.  It's in code untouched by the other changes.
<persia> tedg, Remember to fix it in jaunty first, as otherwise chances of approval are slim :)
<persia> psycardis, I've just double-checked.  There's no jigdo for any of the live images (Ubuntu Desktop, Xubuntu Desktop, Kubuntu Desktop, Ubuntu UMPC, Ubuntu MID).  Everything else is an alternate CD.
<persia> Where do you see a non-alternative jigdo link?
<psycardis> http://releases.ubuntu.com/8.10/ubuntu-8.10-server-i386.jigdo
<persia> That's an alternate CD.
<psycardis> Yeah, my bad. I just noticed that. It's a shame it's not an option.
<psycardis> Although, now that I'm reading about how the live cd is built i see why...
<psycardis> Thank you.
<persia> Yeah.  Just no point to jigdo for that.
<persia> The torrent works fairly well though ...
<cjwatson> right, jigdo works by creating a template with "holes" that can be filled in by byte-for-byte copies of .debs downloaded from more local mirrors
<cjwatson> live CDs have very few such possible slots, because mostly the .debs are uncompressed and then recompressed as a single giant filesystem
<cjwatson> in principle I'm sure it's possible to construct something *like* jigdo that would do the job, but it would really be completely different
<infinity> cjwatson: It would be far more CPU intensive, client-side, since it would need to unpack debs after downloading them, to try to shove the raw files in place.
<infinity> cjwatson: Doesn't seem practical, really, though it might be a fun exercise for someone bored enough to do it.
 * quadrispro is away: Away
<ion_> Le sigh
<Mithrandir> quadrispro: please turn off public away.
<pwnguin> Mithrandir: you know much about openGL ES?
<Mithrandir> pwnguin: I don't know much about opengl at all; why?
<pwnguin> ah, i thought you were into compiz. nevermind then ;)
<quadrispro> sorry Mithrandir
<mklebel> will RandR 1.3 be in the alpha 9.04 release?
<pwnguin> when is randr 1.3 scheduled to be in a release?
<pwnguin> (from xorg)
<mklebel> yes pwnguin
<pwnguin> mklebel: when will xorg release xrandr 1.3? now?
<mklebel> oh it's not even out yet?
<pwnguin> i dont know
<pwnguin> xorg verioning is insane
<mklebel> i guess ill check out #xorg-devel then
<mklebel> pwnguin, yes it is.
<TheMuso> psusi: WHen you work out the necessary fixes for those dmraid bugs, let me know. I have another dmraid bug I need to fix, and I'll throw them together in one SRU.
<psusi> TheMuso: k
<wasabi> Anybody running an ARM port that I don't know about? :)
<pwnguin> wasabi: do you know about the arm port?
<pwnguin> Hasty
<pwnguin> http://mojo.handhelds.org/distributions
<persia> The intrepid equivalent will probably be a month or two, based on past performance.
<pwnguin> Icy imp is slated for q4 2008
<persia> Right.  A month or two :)
<pwnguin> just in time for my pandora :)
<genii> Is there anywhere to learn about incorporating CUDA into ubuntu apps?
<pwnguin> the GPU compiler?
<genii> pwnguin: Yes, like with an NVidia Tesla or so
<genii> I understand it doesn't use gcc
<pwnguin> http://www.nvidia.com/object/cuda_develop.html
<pwnguin> but basically, if the compiler's nonfree it'll never be integrated
<genii> Hm
<genii> pwnguin: Thanks anyhow :)
<pwnguin> and im  not sure how much perfomance benefit there is for the average program
<pwnguin> for video playback, maybe
<pwnguin> but i cant see how it'd make your RSS reader any better off :)
<pwnguin> oh, and being nvidia hardware specific is a strike against inclusion =/
<genii> pwnguin: I want to use it on shading/lighting/physics calculations when rendering in POVRay
<pwnguin> you're better off talking with the upstream projects about it, since they know the software they publish best
<genii> Well, true there about the NVidia origin :)
<pwnguin> it'd suck to install POVray and discover you can't use it because you have intel or amd
<pwnguin> or even just an older geforce
<genii> pwnguin: The Tesla is purely a dedicated GPU multithread card, no video output. You just use it to crunch numbers then out to whatever video card you want
<genii> 240 cores
<pwnguin> but you could always just publish it personally if you just want to toy around; this channel is more focused on core ubuntu components
<genii> pwnguin: Thanks. Now I'll need to remember how to work my ppa ... ;)
<pwnguin> oh, i guess the problem there is build tools
<pwnguin> you cant use a ppa if you have build deps outside of ubuntu
<genii> Hm
<genii> You can't just link static binaries?
<pwnguin> with what?
<pwnguin> nvcc?
<genii> Yes, build on local box with nvcc the CUDA specific stuff then link it into the regular gcc
<pwnguin> somehow that seems like against the terms of service
<pwnguin> uploading object code as source package
<genii> OK. I won't chance it then
<pwnguin> you can always debuild locally
<genii> True.
<genii> OK I'll leave you be then and sort it out... thanks
#ubuntu-devel 2008-11-07
<mathiaz> slangasek: what's your opinion on bug https://bugs.launchpad.net/ubuntu/+source/samba/+bug/211631?
<ubottu> Launchpad bug 211631 in wpasupplicant "CIFS/SMBFS shares not unmounted before network is shut down" [Medium,Confirmed]
<slangasek> mathiaz: <opinion>"blech"</opinion>
<mathiaz> slangasek: it seems that most of the issue are related to network manager.
<mathiaz> slangasek: what about adding an script to umount cifs share in ifdown.d for network manager?
<slangasek> two things: 1) network-manager shouldn't be allowed to kill off the network before unmounting remote filesystems in the general case, 2) the kernel and/or umount.cifs needs to be fixed to not have long timeouts in the case that the server is unreachable
<slangasek> I think the latter is actually a kernel rather than userspace issue
<slangasek> ifdown.d is probably wrong because you don't want to unmount the remote filesystems when *a* network interface goes down, you want to unmount them when the *corresponding* network interface goes down
<mathiaz> slangasek: right - there is also the issue of processes having an file open on the mounted device
<mathiaz> slangasek: IIUC this is why umountnfs is run after sendsigs in the shutdown sequence
<slangasek> yes
<mathiaz> slangasek: in the case of network manager it may not be a good idea to kill all process that have a file open on the mounted device
<slangasek> sorry, what do you mean?
<mathiaz> slangasek: before umount a network fs, we could try to figure which processes have a fd open on the network fs and kill them.
<slangasek> are you talking about at shutdown time?
<mathiaz> slangasek: to mimic the shutdown sequence where processes are killed before umounting network filesystem
<mathiaz> slangasek: nope - when a interface is brought down
<mathiaz> slangasek: assuming we'd add a pre-ifdown.d script to umount the network filesystem
<slangasek> er, how are you going to write an ifdown.d script that doesn't gratuitously unmount filesystems that it shouldn't?
<mathiaz> slangasek: well - I haven't about that yet. But it seems that adding adding an ifdown script is too complicated.
<mathiaz> slangasek: haven't *thought*
<slangasek> if I have more than one interface, I don't want all the NFS mounts for my internal network to disappear every time I adjust my external interface, e.g.
<slangasek> regardless of anything else, the timeouts are a kernel/umount.cifs bug that should be fixed there
<slangasek> and if we fix that, the only other problem is at shutdown time, AFAICS
<mathiaz> slangasek: correct. And you'd also have to figure out a way to match which interface is used for each network filesystem.
<slangasek> which can be addressed by fixing n-m's behavior on shutdown
<mathiaz> slangasek: correct. people are complaining because it takes too long to shutdown.
<slangasek> i.e., either move n-m to /sbin and add it to the ignore list for sendsigs, or arrange for n-m to not tear down the interfaces when signalled, I think?
<mathiaz> slangasek: well - some user reported that they had issue when logging off.
<mathiaz> slangasek: in the case of a wireless connection, is the connection brought down when the user logs off?
<slangasek> possibly.  shouldn't that be considered a bug?
<mathiaz> slangasek: hm - I don't know. asac and the desktop team should probably be involved into this discussion.
 * slangasek nods
<mathiaz> slangasek: anyway it seems that the most practical solution is to lower the timeout.
<slangasek> that's a bandaid, though.
<slangasek> what *should* be happening in this case is that the network route is gone, so trying to send to it will get you a no-route-to-host
<slangasek> which can be detected and handled by the kernel
<slangasek> so either the route isn't being torn out when it should be, and we should fix that; or the cifs driver doesn't handle no-route-to-host, and we should fix that
<slangasek> then adjusting the timeouts shouldn't matter at all
<mathiaz> slangasek: ok. I'll add a note to the bug with the explanation you've just given.
<slangasek> ok
<EvanCarroll> man bluetooth support is *so* bad overall.
<EvanCarroll> I've literally had problems with every component of bluetooth support.
<EvanCarroll> seems as if there are general problems with all keyboards and keymaps in ibex, as well as no ui to make a bluetooth keyboard setup for gdm. and no logs for bluetooth-applet, no decent reconnects,,, gah i rant
<EvanCarroll> having been sold into bluetooth I'm trying to run three devices a keyboard mouse and mic/earphone phone thingy
<EvanCarroll> so far they all have suprises.
<cody-somerville> Its a good thing you're working on it then
<EvanCarroll> the catch is, I'm not sure which bugs are faulty hardware, or which bugs are OS.
<EvanCarroll> I'd have to install windows to figure it out.
<EvanCarroll> the disconnects could be faulty hardware from the bluetooth usb dongle or from the mouse. or from the load of three devices on the adapter
<EvanCarroll> or, most probably, linux support
<cody-somerville> then why even go with the improbably premise until probable?
<EvanCarroll> well. the probability is based on the guilty-by-association.. which seems to be based on things *I* know to be reproducable linux problems lingering from a bad userspace implimentation for hotswap devices.
<EvanCarroll> like keymaps, how can unplugging a usb keyboard and plugging it back in revert a keymap, and how come when a computer comes on with a bluetooth keyboard it has to be manually connected in bluetooth-applet, and after it is connected even though the keymap is international in keyboard preferences, it is en-us in reality.
<EvanCarroll> if you only have a bluetooth keyboard, how do you type in your password in GDM.
<EvanCarroll> lol.
<emgent> moin moin
<pitti> Good morning
<pitti> kirkland: looking
<pitti> kirkland: that looks excellent
<dholbach> good morning
<geser> good morning dholbach, pitti
<dholbach> hiya geser
<NCommander> morning geser
<pitti> hey geser
<pitti> NCommander: congrats to your MOTU badge!
<NCommander> pitti, yup, it got my my backports one too
<NCommander> (and I highly recommend you use caution on opening your inbox pitti :-))
<NCommander> There is one removal, and 14-16 backporting ACKs
<pitti> NCommander: too late
 * NCommander gives you the flamethrower of justice
<NCommander> oh and an SRU
<NCommander> ;-)
<geser> Hi NCommander
<NCommander> morning geser
<NCommander> geser, I'm loking at your merges, any one you want me to do upfront?
<geser> NCommander: no specific order
<NCommander> geser, well, one of your merges became a sync since Debian rolled your fix bashisms patch
<NCommander> so one down
<geser> NCommander: I guess squid3 might be a sync too as that patch came from upstream and should be included in 3.0.STABLE8
 * NCommander is trying to determine if the requestsync script actually works :-)
<geser> NCommander: ilohamail is a fakesync due to bad versioning, so an easy one too (if you prefer the easy ones :)
<NCommander> fakesync?
<geser> NCommander: in cases where we don't have any changes but can't sync (different .orig.tar.gz, bad versioning etc.) we need to do an upload nonetheless (e.g. take the Ubuntu .orig.tar.gz and Debian .diff.gz in the case of a different .orig.tar.gz)
<NCommander> What's the version number I need to upload w/?
 * NCommander requests another sync for libnet-cups-perl
<geser> as there aren't any changes -XbuildY should work (generally speaking)
 * NCommander nods
<geser> in case of ilohamail you need to upload 0.8.14-0rc3sid6 as  0.8.14-0rc3ubuntu4
 * NCommander grabs the debian packaging
<NCommander> so debian diff, ubuntu orig.tar.gz
<geser> you can use also the debian .orig.tar.gz as they're both the same (it's just the versioning which went bad in the past)
 * soren wishes people would stop writing more php webmail systems and write a Python one instead
 * NCommander nods
<NCommander> geser, what do I use for the -v in debuild?
<soren> The last version known to Ubuntu.
<NCommander> Right
<NCommander> But there are no other ubuntu entries in the changelog
<geser> use 0.8.14-0rc3sid5 so you get also the new Debian changelog entry into the .changes file
<NCommander> ah
<soren> The point is that the .changes file should list all the changes since the last version uploaded to Ubuntu.
 * NCommander test builds, and installs
<NCommander> Ok, now it makes sense
<liw> lifeless, and don't you just love a discussion that bounces across channels? :)
<lifeless> liw: only when there is enough people capable of following it
<ara> NCommander: congratulations on your MOTU!
<NCommander> Yup :-)
 * NCommander takes his head off to you
<kirkland> pitti: awesome, thanks!
<seb128> calc: why did you reassign this mimetype issue thing to nautilus?
<t3rm1n4l> hi
<t3rm1n4l> may i know who is loading kernel modules for ethernet card, graphic cards?
<t3rm1n4l> is that udev?
<kelemengabor> hi mvo, do you have some time for i18n bugs? :)
<kelemengabor> for example bug #289798
<ubottu> Launchpad bug 289798 in app-install-data-ubuntu "KDE4 GenericNames should be marked for translation" [Undecided,New] https://launchpad.net/bugs/289798
<mvo> kelemengabor: oh, right - sorry that I haven't worked on it earlier
<kelemengabor> np
 * mvo puts it on his list for today
<kelemengabor> any hope that such changes can make it into intrepid? or only jaunty?
<kelemengabor> thanks
<mvo> kelemengabor: I think we could sru it, but from a first glance it looks like we might get a ways with regenerating the pot template and uploading into into rosetta
<mvo> kelemengabor: what do you think?
<kelemengabor> yeah, some 160 new strings showed up for me locally
<kelemengabor> oops, life calls me, see you later
<pitti> crimsun: is bug 282316 fixed in jaunty's alsa-plugins?
<ubottu> Launchpad bug 282316 in alsa-plugins "erratic elapsed time count in "sound recorder" " [High,In progress] https://launchpad.net/bugs/282316
<ScottK> pitti: On spamassiss, the dapper task needs to stay open.  The one that got accepted didn't actually apply the patch and there's another one in -proposed for testing.  I'll reopen the task.
<pitti> ScottK: I thought that's what I did? dapper -> fixcommitted, dapper backports -> fixreleased?
<pitti> ScottK: anyway, that's what I *intended* to do. If I broke them, I apologize
<ScottK> pitti: On one bug.  On the other one you did dapper fix-released.  No trouble.  It's a confusing situation.
<pitti> ScottK: thanks for double-checking
<ScottK> pitti: (Still double checking spamassassin) were you going to do the backports for Gutsy/Hardy too?
<pitti> ScottK: yes, backports and other archive stuff is still on my list
<pitti> I still didn't finish with SRUs
<pitti> (gosh...)
<ScottK> pitti: OK.  No rush.  Just making sure (since it's a lot of pieces to push around on that package).
<james_w> pitti: hi, I have a user that has an apparent problem with the sources.list entry added for their printer driver
<james_w> pitti: apparently it is not the right case. It sounds like this is a problem with openprinting's database, but should it be filed on jockey?
<pitti> james_w: yes, please file it on jockey for now, it should filter those out; I'll forward it to openprinting
<james_w> thanks
<mathiaz> pitti: when an SRU bug is marked for verification-needed, should the uploader do the verification or it'd better be someone else?
<pitti> mathiaz: usually someone else, like QA team or bug reporter
<persia> mathiaz, Note that if nobody steps up, asking for help in #ubuntu-bugs or #ubuntu-testing can help the process.
<pitti> Riddell: can you please commit your cdbs change to bzr?
<Riddell> pitti: oh doh, will do
<pitti> Riddell: for 0.4.52ubuntu7 too, please; thanks!
<Riddell> done
<pitti> NEW -> 611 entries
<pitti> yeah, must be post-release time ...
 * jdong blames NCommander  :)
<ScottK> Good thing Lenny freeze slowed things down.
<ScottK> ;-)
<pitti> well, credit where credit is due, most is Debian imports :)
<pitti> (I *hope*)
<thvdburgt> hi all, I would like to try to add emesene support to the fast-user-switch applet. Is there a bzr-branch for the code or is http://packages.ubuntu.com/source/intrepid/fast-user-switch-applet this the most recent code?
<pitti> tedg: ^
<thvdburgt> ah, I notices Ted is the maintainer, tedg can you help me?
<tedg> thvdburgt: Sure.  I'm sorry, what is emesene?
<thvdburgt> http://www.emesene.org/ It is an Instant messenger for the msn-network
<tedg> thvdburgt: Ah, cool.  Probably the branch you want is this one: https://code.launchpad.net/~ted-gould/fast-user-switch-applet/show_status  (note, you can get all of them by looking here: http://code.launchpad.net/fast-user-switch-applet )
<tedg> thvdburgt: You should only have to edit src/status-manager.c to add another set of functions for emesene.
<thvdburgt> thank you tedg I'll give it a shot :)
<aaroncampbell> How would I configure Gtk+ to allow "accelerator changes" ?  I'm running Kubuntu, but I guess Pidgin could use this?
<little> Are there any developers in here who can answer a question about the linux-ubuntu-modules-2.6.24-21-generic update?
<little> Is anybody in here who knows anything about the linux-ubuntu-modules-2.6.24-21-generic update?
<seb128> if you were asking your question maybe somebody would reply
<little> The description for the update says, "You likely do not want to install this package directly. Instead, install the linux-generic meta-package, which will ensure that upgrades work correctly, and that supporting packages are also installed.". Is this anything to worry about, or can I go ahead and update it?
<tseliot> little: you can go ahead
<little> tseliot: Any idea why there's a warning?
<tseliot> little: because we want users to install the linux-generic metapackage so that when the kernel is updated you will automatically get  linux-ubuntu-modules for the new kernel
<little> tseliot: I never messed with the kernel when installing Hardy Heron - I let it install whatever it wanted. (:
<tseliot> little: if you install the package without the metapackage your linux-ubuntu-modules won't match the new kernel
<cjwatson> then you should have linux-generic already installed
<little> I'll check for both of those before I do the upgrade, then, thanks!
<cjwatson> that isn't a warning primarily intended for upgraders - it's in the package description so that people installing the package from scratch know the intention
<cjwatson> it happens that update-manager can be asked to display the description
<cjwatson> but it's a description of the package rather than of this specific update, if you see what I mean
<little> Ah, okay, that makes sense.
<pitti> cjwatson: installation-report ended up on my merge list, since I did a small fix; shall I do it, or is it on your radar anyway?
<cjwatson> pitti: either's fine with me; all of d-i is notionally on my list if nobody else does it
<little> You guys might want to re-word those warnings, then. (:
<cjwatson> linux-ubuntu-modules no longer exists in more recent releases than 8.04, so we probably won't put too much effort into its description TBH :-)
<cjwatson> it got folded back into the main image
<little> Ah well. (:
<cjwatson> I think actually we should probably rethink how update-manager displays this stuff, rather than rewording the descriptions
<cjwatson> it's not going to be a problem unique to linux-ubuntu-modules
<cjwatson> bug 145764 is related
<ubottu> Launchpad bug 145764 in update-manager "doesn't state why updates are necessary" [Wishlist,Confirmed] https://launchpad.net/bugs/145764
<cjwatson> I've added a comment to that bug about this case
<little> From a user's standpoint, many users will probably just grab the update, but those of us who read somthing like that will hesitate or not install it at all. If the update in question fixes a vulnerability or other significant issue, that might leave a lot of users without the update. (:
<cjwatson> I agree that it is a confusing presentation, just debating how to fix it properly :-)
<little> For the record, I'm using Kubuntu Hardy Heron, so this is in Adept Manager.
<little> I'm not sure how it displays in Ubuntu.
 * little is into documentation
<cjwatson> ah. could you file a bug on adept about this, then? I don't see one there
<little> Okay, will do.
<cjwatson> thanks
<little> Should it be a bug on warnings in descriptions in general?
<cjwatson> no, I don't think so
<cjwatson> the description wasn't intended to be displayed this way, so it's hardly surprising that it seems odd
<cjwatson> the bug is in the presentation, not the content (which is designed for an entirely different use case)
<cjwatson> I think we'd be fighting an uphill battle to make descriptions suitable, and that doing so would not buy very much
<little> I don't know how those descriptions are created, but maybe instead of changing them, you could simply add a blanket comment beneath any that are like that to let people know that if this is an update for an existing package, the warning doesn't apply.
<little> If that's something that could be done by running one command that would affect all similar packages, it might not be too hard to do. (:
<cjwatson> little: I honestly don't think that would be appropriate
<cjwatson> little: we shouldn't need to touch the descriptions at all for this - we should simply not present them as descriptions of the update
<cjwatson> because they aren't
<cjwatson> and no, it wouldn't be a matter of running a command, it would be a slow and tedious process of uploading lots of packages
<cjwatson> which is one reason I think we should fix it in the right place rather than a workaround that's in fact harder work :-)
<little> LOL! You poor things! Isn't there a team somewhere in Ubuntu that works on simplifying all that stuff? (:
<cjwatson> we are indeed working on improved collaborative development
<cjwatson> still wouldn't change the fact that the package descriptions are the *wrong place to change this* :-)
<little> I mean the final database that holds all the information about all the packages. It would be awesome if that was in plain text and accessible so you could do blanket edits. (:
<kees> cjwatson, slangasek, or others, I'm trying to understand what seems to be vagueness in the Debian Policy Manual regarding Depends.  Here are the two sections that are confusing me:
<kees> http://www.debian.org/doc/debian-policy/ch-binary.html#s3.5
<cjwatson> little: we don't want to maintain that as a central database, rather than considering the package the proper source of that information
<kees> http://www.debian.org/doc/debian-policy/ch-relationships.html (7.2)
<cjwatson> little: the database is built dynamically from the packages
<cjwatson> this is actually much more maintainable in reality
<kees> first says "Sometimes, a package requires another package to be installed and configured before it can be installed. In this case, you must specify a Pre-Depends entry for the package."
<little> cjwatson: Ah, that makes sense.
<kees> second says "A package will not be configured unless all of the packages listed in its Depends field have been correctly configured.'
<slangasek> kees: the second use of "installed" there should be "unpacked"
<kees> slangasek: ah-ha!
<cjwatson> yeah, "installed" is dpkg internal jargon for "unpacked"
<cjwatson> and hence policy is sometimes a bit confused about the wording here
<Koon> ah-ha!
<kees> okay, that resolves some confusion, but now it sounds like if I have  Depends: one, two   then one and two will run their postinsts before my own
<cjwatson> yes, unless there is a dependency loop involved
 * slangasek nods
<Koon> cjwatson: in which case the loop is broken arbitrarily, right
<kees> okay, I believe that's what we're fighting, then.
<cjwatson> Koon: right
<cjwatson> if you have a dependency loop you need to ensure that it works either way round
<dx9s_work> still is an unusual question.. but where does one download the ubuntu maintained patches for the kernel source code? I know I can download the kernel source code already patched by ubuntu maintainers, but where do I get what the maintainers used to patch the kernel source in the first place?
<cjwatson> the .diff.gz for the package contains the differences between our source and upstream
<cjwatson> they were acquired from a number of sources; the easiest way to inspect them is probably by using revision control. http://wiki.ubuntu.com/KernelGitGuide
<dx9s_work> sooo. I have to download the source for a package that is (in itself) already source code.. two levels of source getting ...
<pwnguin> im pretty sure the kernel team uses git
<pwnguin> so it's not quite that bad
<dx9s_work> pwnguin, am I making sense.. I don't want the source code to the kernel.. I want the patches (diffs) the ubuntu team applies to that source code
<pwnguin> thats what git keeps track of
<pwnguin> they dont publish it seperately
<cjwatson> that's what's in the .diff.gz file
<cjwatson> I do not believe that it is shipped as part of the linux-source binary package, which seems to be what you're thinking of
<cjwatson> linux-source isn't really intended for this purpose, as far as I know; for more sophisticated questions like yours you are better off ignoring linux-source and just fetching it from git
<pwnguin> cjwatson: how does it figure out what the base tarball is?
<dx9s_work> I understand that the ubuntu patches are outside the offical kernel source (been compiling kernels from kernel.org for years)
<cjwatson> pwnguin: the developer doing the upload supplies it
<dx9s_work> just trying to find the easiest way to get ubuntu's diffs on that source
<cjwatson> I've now told you it twice
<cjwatson> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.24-21.43.diff.gz for 8.04, http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.27-8.17.diff.gz for 8.10
<dx9s_work> cjwatson, thanks
<pwnguin> dx9s_work: there's 12 megs of diff there
<persia> 8.17 is in -proposed.  8.10 is currently still 7-16.
<cjwatson> .diff.gz tells you what the patches *are*; git will let you ask questions about how they break down in more detail
<cjwatson> depends what you need to know
<cjwatson> some people just care about the sum total of what we change
<dx9s_work> is each diff dependent (aka not accumulative)? (hence the 12M comment from pwnguin )
<pwnguin> "each diff"
<pwnguin> it's just one diff
<pwnguin> not patches
<pwnguin> one patch
<cjwatson> if you want to get separate patches, use git
<cjwatson> each .diff.gz is the accumulated change from the base tarball to that Ubuntu revision
<pwnguin> it should also contain things like how to build the .deb
<dx9s_work> been doing the kernel .deb thing for a little while on a newer machine
<dx9s_work> have that bookmarked on computer at home
<pwnguin> what is your goal here? to rebuild your kernel based on the ubuntu kernel?
<dx9s_work> using "fakeroot make-kpkg ..."
<dx9s_work> no .. interested in trying a few different options
<pwnguin> so rebuild... with a few different options
<dx9s_work> I am about 1-2 years into ubuntu (former slackware guy, and the slack-build process is different and simplier -- no dependency checking) .. just trying to do something and figured instead of brute force compiling a kernel/installing (was installing kernel outside .deb for the first year BTW).. should review the whole process ... it's 1 part learning and 1 part I am interesting in custom tweaked rt kernel
<pwnguin> in my opinion, the first thing you should learn about the kernel is git
<dx9s_work> I've used git a little bit in the past... and before git was even a tool written to help maintain the kernel source
<dx9s_work> aka I'm not new to compiling the kernel... I'm new to ubuntu's way .. and still have some to learn about git ...
<pwnguin> ubuntu's way is subject to stupidity, improvements and change ;)
<pwnguin> git however, is probably going to be a bit more stable
<dx9s_work> too many cooks in the kitchen?
<pwnguin> i dont think so.
<pwnguin> maybe even too few
<pwnguin> anyways, i gotta bolt for work
<dx9s_work> thanks
<dx9s_work> who comes up with this names ... "Trembling Tortoise" .. heheh
<little> cjwatson: I filed the bug. I hope I worded it well: https://bugs.launchpad.net/ubuntu/+source/adept/+bug/295277
<ubottu> Launchpad bug 295277 in adept "Adept Updater shows installation warning when updating existing package" [Undecided,New]
<persia> dx9s_work, If you're interested in the -rt kernel, you might want to also take a look at the linux-rt source package.
 * dx9s_work understood
<dx9s_work> persia, understood
<dx9s_work> persia, that rt kernel is not *perfect* hence this WHOLE line of questioning in the first place
<cjwatson> little: thanks; I have added some clarification
<persia> dx9s_work, In fact it has several bugs, for which fixes would be appreciated.  It's the combination of the things in git or in the linux source with the patches in the linux-rt source that are your best bet for -rt though.
<dx9s_work> persia, are the patches that the -rt patches use in the same git source?
<persia> dx9s_work, No.  Those are in the linux-rt package.
<persia> upstream -rt is in quilt, and linux-rt uses quilt to apply those (and some integration bits) to the linux-source binary package produced from the linux source, which is in git.
<dx9s_work> I don't know what quilt is .. I know of http://rt.wiki.kernel.org/
<cjwatson> kees: I've filed a debian-policy bug for the text to be disambiguated
<cjwatson> dx9s_work: apt-cache show quilt
<dx9s_work> ah
<little> cjwatson: Thanks - well done! I didn't want to put in any explanations since bug reports generally don't want us (the general user) venturing guesses. (:
<kees> cjwatson: oh! thanks
<thvdburgt> tedg, how can I easily test my newly compiled version of the applet?
<thvdburgt> I see the "old" version is in /usr/lib/fast-user-.../ how can I get the panel t pick up my version?
<tedg> thvdburgt: killall fast-user-switch-applet then a dialog will come up to reload.  Run yours, it'll sit there a second, then hit reload.
<little> Hey there, should users of the 64 bit release of Kubuntu Intrepid Ibex have this file: linux-kernel-devel ?
<dharanpdeepak> any one here to help me ?
<dharanpdeepak> i wish to start contributing to ubuntu
<dharanpdeepak> but i don't know where to start
<dharanpdeepak> ???
<dharanpdeepak> helloo ?
<dharanpdeepak> anyone in there ???
<little> dharanpdeepak: How would you like to contribute?
<little> dharanpdeepak: This is a good place to start: https://wiki.ubuntu.com/Teams?action=show&redirect=TheUbuntuCommunity
<cjwatson> little: linux-kernel-devel was removed in 8.10
<cjwatson> regardless of architecture
<RainCT> mvo_: Hi. Yesterday I looked at that method to only retrive the diff of Sources files which can be used in Debian experimental and in a comment on the BTS you stated that it doesn't work for Ubuntu. Could you explain why please?
<cjwatson> little: you may still have it installed if you installed it manually on 8.04
<cjwatson> (and then upgraded)
<cjwatson> Depends: build-essential, curl, debhelper, git-core, gitk, kernel-package, kernel-wedge, openssh-client, rsync
<little> cjwatson: Uh oh. There is a user following my instructions for installing the NVIDIA driver and he can't find the file. Does he simply not need it? My instructions (the one in question) are here: http://littlergirl.googlepages.com/NvidiaDriverHowTo.html#step04
<cjwatson> is all it contained so you could just install that stuff manually
<cjwatson> and some of that was just for committing to the kernel anyway
<little> Can he just ignore that part of that step?
<cjwatson> looking at your page,  build-essential debhelper kernel-package kernel-wedge  would probably be sufficient
<little> Did you catch that, thomas?
<cjwatson> (to replace linux-kernel-devel)
<cjwatson> and if you mention build-essential then you can remove gcc and make, as well
<cjwatson> or rather you don't need to list those explicitly
<thomas_> I caught it but I dont understand it.. lol
<cjwatson> thomas_: instead of "linux-kernel-devel", pretend that that page says "build-essential debhelper kernel-package kernel-wedge"
<little> So Intrepid users need build-essentials, debhelper, kernel-package, kernel-wedge, pkg-config, xserver-xorg-dev, linux-source-2.6.24, linux-headers-2.6.24-19 and linux-headers-2.6.24-19-generic, right?
<thomas_> oh... haha alright
<little> And everyone else needs what I have listed minus gcc and make and with build-essentials instead, right?
<cjwatson> little: for intrepid, it shouldn't be 2.6.24(-19) - replace with appropriate versions
<cjwatson> the substitutions I gave are good for 8.04 too
<little> cjwatson: Yeah, I'll update it with the latest kernel.
<little> thomas: I'll paste a list for you in pastebin.
<thomas_> alright
<little> thomas, what do you get when you type this in a terminal window: uname -r
<thomas_> 2.6.27-7-generic
<little> These are the packages you must have installed: http://paste.ubuntu.com/69012/
<little> Is that right, cjwatson?
 * little doesn't want to steer thomas wrong.
<thomas_> alright, they are installing
<cjwatson> little: looks fine except you wrote "build-essentials" instead of "build-essential"
<little> Ouch, thanks, I'll fix it and tell thomas.
<crimsun> pitti: yes, 282316 is fixed in jaunty's alsa-plugins
<thomas_> cjwatson: when I try installing the display drivers as little suggests it gives me an error saying something like unable to find the source tree for the currently running kernel
<thomas_> then it says something about kernel-devel
<little> Maybe my instructions won't work in Intrepid?
<cjwatson> thomas_: at this point I suggest the two of you should take this to a different channel
<cjwatson> this isn't really a discussion about development of Ubuntu as such
<cjwatson> plus I don't know any further answers here :-)
<thomas_> alright thanks
<mvo_> RainCT: pdiff in debian can be used because debian re-generates the packages file only twice a day
<mvo_> (used to be once a day only)
<mvo_> RainCT: we used to do it every 1h (not sure how often we do it now) - so it does not scale well for us as its one individual file per change
<mvo_> RainCT: the other thing is that its most interessting for unstable, the stable Packages file does not change, only -updates -security etc but they are much smaller than the full packages file
<mvo_> RainCT: I'm off to bed now, but I'm happy to talk about this in more detail if you are interessted
<RainCT> mvo_: what about implementing some fallback? like keeping one week of files and for people who haven't update since over a week apt would just download everything like it does normally
<RainCT> mvo_: I am :). When should I best ping you to talk about it? (Or will you ping me? :))
<mvo_> RainCT: I'm here all week usually during european daytime hours :)
<mvo_> RainCT: (and a bit more usually)
<mvo_> RainCT: the support in apt is available, we just need something that puts the diff on the server and we are ready
<RainCT> mvo_: "something to put the diff on the server"? How is it working on Debian if this isn't done?
<RainCT> (we can continue tomorrow if you want to leave :))
<mvo_> RainCT: essentially its as simple as "diff -e Packages.old Packages.new; md5sum Packages.new >> DiffIndex" (well, slightly more, but not a lot really)
<mvo_> RainCT: it would need support from the soyuz infrastrucure
<mvo_> RainCT: https://bugs.edge.launchpad.net/soyuz/+bug/214612
<ubottu> Launchpad bug 214612 in soyuz "Provide pdiffs for apt-get update" [Undecided,New]
<RainCT> Ah, so there's nothing we (ie, the community) can do?
<RainCT> @ mvo_
<mvo_> RainCT: not sure, I can ask the soyuz people for their opinion - but I think its less interessting for ubuntu really because of the massive churn we do
<mvo_> or at least we would/should try to make it better
<mvo_> RainCT: in the meantime a "me too" comment n the bug is probably the right answer
<mvo_> RainCT: happy to talk about it later, need to get some rest now :)
<wgrant> pitti: Around?
<wgrant> Hmm, I'd guess not. I can't count.
<RainCT> wgrant: he's away - "off for the weekend"
<wgrant> Blah. Unfortunate.
<LaserJock> persia: ok, so here's what I'm trying to accomplish
 * persia notes that the publisher still tries to run roughly every hour
<LaserJock> I have 1, and perhaps more, people who would like to help maintain some Edubuntu packages
<LaserJock> I'm trying to figure out the best way to set that up so we can collaborate via VCS and still keep it sane
<LaserJock> it was suggested that I create a edubuntu-packaging LP team and throw branches in there
<superm1> yeah
<persia> OK, so you do have the use case where you want many people to collaborate on uploads, but not have frequent uploads (because they can't all upload those packages).
<superm1> just make sure that they never actually put the distro in the changelog entry until it gets uploaded
<persia> ArchiveReorganisation would help, but in the short term, having packaging in VCS makes it easier.
<superm1> so most people should leave it as UNRELEASED, and then whoever has rights and does upload it makes that one change
<LaserJock> a few of the packages do have vcs-imports so I have access to upstream code
<LaserJock> but I'm wondering if it's easier to just put debian/ in VCS
<persia> And all the packages have Debian packaging, but none of that is VCS, right?
<LaserJock> hmm, most that I'm particularly interested in don't
<LaserJock> there might be a few that do
<persia> In that case, I'd recommend just putting debian/ in VCS for now.  Proper VCS packaging is lots easier than just debian/ in VCS, but the infrastructure isn't all there if you can't get a vcs-imports feed from Debian.
<LaserJock> right
<persia> So you'd do a commit for each change, including merges with Debian.
<persia> When something is in sync, just shove the debdiff as a commit when autosync publishes to keep things sane.
<LaserJock> yeah, none of the packages are really active in Debian, such that it would be very difficult to keep up
<persia> From what I understand of future infrastructure, there should be generated branches of Debian upload history and Ubuntu upload history from which you can derive, which would allow for proper VCS packaging, but trying to replicate that manually is just going to be painful.
<LaserJock> ok, sounds reasonable
<LaserJock> does creating a packaging team seem decent?
<persia> (and possibly generated branches from Debian VCS history, but that's only gravy)
<LaserJock> I'm not sure if other projects are doing that
<persia> On the strength of ArchiveReorgansiation alone, I'd advocate the creation of an Edubuntu-dev group.  If you end up with too many people in it, you can always create an Edubuntu-core-dev group, where -dev can commit to branches, and core-dev upload if you need.
<persia> Personally, I'd recommend that people first interested be expected to submit some patches (perhaps preparing candidate branches for merging) first, and only after showing a history of good contributions be added to edubuntu-dev.
<LaserJock> persia: heh, we have over 20 Edubuntu LP teams but no -dev
<persia> Yeah.  You went crazy on teams a couple years ago :)
<LaserJock> is there any decent ETA on ArchiveReorganisation ?
<persia> None I've seen announced.  At one point a member of the TB suggested it would happen for Jaunty, but Jaunty opened.  I'm currently choosing to interpret that remark as "During the Jaunty cycle".
<cjwatson> it's on my list but no ETA yet
<cjwatson> there's a dependency on the Soyuz development roadmap which was given a high priority but I don't have an ETA on *that*
<persia> cjwatson, On your list for implementation, or for more spec documentation?  What needs doing beyond Soyuz, process coordination, and TB confirmation of delegated groups?
<cjwatson> persia: mostly implementation, although still need to sort out how apt and mirroring utilities are going to play with it
<persia> Well, the quick & dirty way is to just semantically redefine "main", but that's probably not enough to preserve ogre-model style restrictions.
<cjwatson> ogre-model is exactly the concern
#ubuntu-devel 2008-11-08
<NCommander> How long after a package enters dep-wait will it clear once its dependencies are available
<NCommander> http://launchpadlibrarian.net/19414431/buildlog_ubuntu-jaunty-i386.alsa-plugins_1.0.18-1ubuntu1_MANUALDEPWAIT.txt.gz - this build log is extremely puzzling
<geser> NCommander: why should it leave DEPWAIT?
<NCommander> geser, LP to my knowledge clears things that are actually dep-wait on its own
<NCommander> Am I wrong?
<NCommander> (the status is MANUALDEPWAIT)
<geser> that's correct
<NCommander> maybe I'm not following you
<geser> but amd64-libs is not available
<geser> perhaps I did get your question/your problem
<NCommander> oooh
 * NCommander only looked at amd64's depwait
<NCommander> d'oh
<NCommander> hrm
<NCommander> amd64-libs did exist
<NCommander> Then it vanished
<NCommander> Strange
<geser> for amd64 is easy: alsa-plugins (main) vs ia32-libs (universe)
<NCommander> ia32-libs is not in main?
<NCommander> oh
<NCommander> Ok
<geser> looks like the build-dependencies need an update for at least i386 and amd64
<NCommander> ok
 * NCommander fails
<geser> ia32-libs is not in main according to LP: https://edge.launchpad.net/ubuntu/+source/ia32-libs
<NCommander> Yeah
<NCommander> I would have swore it was
<NCommander> Odd
<geser> till dapper is was in main
<NCommander> How did lib32asound2-dev then get built
<NCommander> if ia32-libs is in universe
<geser> without checking I guess with the needed lib32* libs
<geser> or lib64 libs
<geser> amd64-libs is on the sync-blacklist
<NCommander> ia32 libs will not be installed out of the box
<NCommander> I mean they are physically not installed
<NCommander> It might be saner to do a promotion of ia32-libs to main
<geser> I mean the biarch packages like lib32asound2
<geser> or lib32z1
<NCommander> Oh I see
<geser> I doubt the archive admins want it back in main
<NCommander> ok
<NCommander> so alsa-plugins actually needs fixing
<NCommander> The 32 bit fix is clear
<NCommander> I have no idea how to fix building the 64 varients
<NCommander> hrm
<geser> there are lib64* variants of some packages
<NCommander> ok
<NCommander> I give
<NCommander> alsa-plugins is not depending on ia32
<NCommander> *ia32-libs
 * NCommander begins working backwards
<NCommander> oh wait
<NCommander> nm
<NCommander> found it
<geser> check which 32bit packages it needs on amd64 and if they exist in a lib32 version
<NCommander> geser, they are listed in the control file oddly enough
<NCommander> (both are)
<NCommander> what was the bug number?
<geser> bug number?
<NCommander> there was a bug that pointed me to that build failure
<NCommander> I forgot I posted the log :-)
 * NCommander tweaks his build environment to build only in main/restricted
<NCommander> apachelogger, ping
<NCommander> StevenK, ScottK: ping
<NCommander> ENEEDCOREDEV
<persia> NCommander, Are you seeking advice or an upload?
<NCommander> persia, the later
 * NCommander has created and built tested the fix patch in main-only pbuilder instances
<persia> NCommander, Just subscribe ubuntu-main-sponsors then.  Shouldn't be too long.
<NCommander> did
<persia> And it's time critical because?
<NCommander> upgrading pulse audio uninstalls other packages, and removes the -desktop packages?
<persia> And you've marked the relevant bug critical?
<NCommander> High
<persia> I'd bump it, based on breaking the default installation for a majority of users.
<NCommander> I thought critical was only for violations, or serve risk of data/security lose and issues
 * persia checks
 * NCommander finds Ubuntu's priorities are at best a little loosely defined
<persia> Critical: A bug which has a severe impact on a large portion of Ubuntu users
<NCommander> Works for me
 * NCommander bumps
<persia> So it'll probably be one of the first things that any of the main sponsors hits.
 * NCommander did mark the urgency critical in the changelog so it will take relatively little time to build
<persia> That said, the number of jaunty users currently is small, and all of them are expected to be able to deal with breakage of that sort, so a day or so won't hurt, really.
<persia> In the changelog you'd be better off with "medium".  It sorts before others, but still lets someone push something truly critical (like a key toolchain bug or something) in front of it.
<NCommander> The toolchain will go first anyway
<NCommander> the kernel and the toolchain are scored so they are built a moment a builder is together
<NCommander> From the way I understand
<NCommander> for packages without explicate build scores
<persia> Well, OK, but still.  Using "critical" means there's no flexibility.  "medium" would have the same relative effect, and leave flexibility.
<NCommander> So I should kill the patch and reupload?
<wgrant> Does urgency actually matter in Ubuntu?
<NCommander> wgrant, it actually affects the build score
<NCommander> The way I understand it, if a package isn't scored explicately (i.e., kernel, toolchain), it starts at 1000, 2000, 3000, 4000 for main, restricted, universe, multiverse
<NCommander> (I'd guess parther is 5000 if there is anything built from source there)
<NCommander> Then a number (its either 1 or 5 if I understand correctly) is added for each queued build
<NCommander> so if there are two queued packages for main, its 1005 and 1010 respectively
<persia> wgrant, Only a very little, and only within an otherwise identical set.
<NCommander> Urgency bumps the build score by ten per level of urgency set
 * NCommander notes that might not be 100% correct
<NCommander> ScottK, & jdong: http://mail.google.com/mail/?shva=1#inbox/11d7ba7d3a88a605 - care to weigh in on this?
<wgrant> NCommander: Erm, wrong URL?
<NCommander> oops
<NCommander> http://mail.google.com/mail/?shva=1#inbox/11d7ba7d3a88a605
<NCommander> argh
<NCommander> Bug #295495
<ubottu> Launchpad bug 295495 in hardy-backports "Please backport debhelper 7 from intrepid" [Undecided,New] https://launchpad.net/bugs/295495
<NCommander> there
<edson> hi. after the upgrade that following packages: libgphoto2-2 (2.4.0-8ubuntu7) to 2.4.0-8ubuntu8
<edson> libgphoto2-port0 (2.4.0-8ubuntu7) to 2.4.0-8ubuntu8, the web pics on firefox cant be seeing. some one can help?
<cjwatson> NCommander: it's five per level of urgency set; doesn't make a whole lot of difference though since that's less than most other factors
<NCommander> cjwatson, oh, I thought it was ten
<cjwatson> NCommander: for comparison five minutes in the queue gets you a credit of 5, 15 minutes gets you a credit of 10, 30 minutes a credit of 15 ... being in main vs. universe grants 1000 vs. 250
<cjwatson> etc.
<NCommander> Ah
<NCommander> Cool
<cjwatson> I look forward to LP being open source so that we can just stick a URL to the relevant code in some documentation :)
<Hobbsee> oh, neat.
<NCommander> cool
<NCommander> LP internals
<NCommander> Build scores probably should be doc'ed somewhere
<StevenK> The numbers themselves mean very little
<ScottK> NCommander: I know backports.org backports debhelper regularly with no issues.  Since it only affects building packages, not using them, I think it's worth considering.
<DeadPanda> hey, just wondering if DKMS would throw a fit if it replaced a module already in the kernel?  (I need a newer uvcvideo than that available in Intrepid for this laptop)
<superm1> DeadPanda, as long as the kernel module isn't compiled as "part" of the kernel (eg not modular), it would be fine
<DeadPanda> superm1: thanks
<\sh> moins
<Pelo> morning folks I think something is broken in the envyng packages,
<tseliot> Pelo: what exacty?
<Pelo> envyng-gtk install , along iwth common, but when I run envyng-g it wants  me to install envyng-qt , which I do and then it seems to install a full kde , very unnessary , just tought I would let you know
<Pelo> never did that in hardy
<tseliot> Pelo: the gtk ui wasn't ready therefore you will have to use either the qt ui or the textual ui
<Pelo> tseliot, understood , thanks
<superm1> cjwatson, is there a particular reason that laptop-detect casper and lupin casper aren't just in the live task, but instead explicitly listed in livecd-rootfs?
<emgent> heya
<jdong> NCommander: backporting debhelper 7 is outside my scope of comfort, I think ScottK should answer your question :)
<ScottK> jdong: Since -release can't build against -backports and debhelper is only relevant to the build process, I think it should be fine.
<ScottK> debhelper is one package where if it wasn't backwards compatible a huge amount of stuff would have blown up and we'd know it.
<ScottK> There's an etch-backport of debhelper 7 if that's any comfort.
<jdong> ScottK: alright, that sounds safe to me then
<ScottK> Safe in the scheme of backports safe, yes.
<X3> hi everyone
<X3> please dont hate me
<X3> |18:33:58| (X3) off topic question Im looking for skilled coders both windows and linux for new projects hardware manipulation/embedded systems/some web coders with knowledge of current standards other skills necessary these are opensource projects that will be be using some existing sourcecode most of it is really done just needs modifying/updating/adding features to suit the wip concept...
<X3> |18:34:00| (X3) no reinventing of the wheel just making it current running better and target a large audience immediatly available to use programs in both projects please message me with contact detail @ http://x3webworx3.spaces.live.com/ any help even finding interested coders even students are welcome. thank you...
<X3> |18:38:31| (X3) http://www.xps-wiki.com/forum/showthread.php?t=88&goto=newpost
<X3> |18:39:11| (X3) http://www.xps-wiki.com/forum/showthread.php?t=87&goto=newpost
<X3> that contains more information about project that may give you an idea many new laptop users could benefit os both that wish to dual boot linux and windows
<X3> not just Dell laptops but all laptops
<X3> no ok
<emgent> someone know in that package is lzm2dir ?
<emgent> s/that/what/
<ScottK> emgent: http://www.linuxquestions.org/questions/linux-software-2/how-do-i-decompress-lzm-files-586399/
<emgent> saw that danke :)
 * jdong questions mail-notification's "sent: about 41 minutes ago" field.
<jdong> is that really rough enough an approximation to require wording it that way? :)
<Kopfgeldjaeger> do-release-upgrade stops when /var/lib/update-notifier/ doesnt exist (when update-notifier isnt installed..). but that's probably not that important because afaik you should install ubuntu-desktop before upgrading.(?)
<Kopfgeldjaeger> [the same with /var/games]
 * soren notes that the trigger related stuff is missing from Debian/Ubuntu Policy.. How odd.
<liw> is it a policy issue?
<soren> The policy lists all the ways in which maintainer scripts can be called.
<soren> Err...
<soren> The policy lists all the ways in which maintainer scripts can be called except the trigger related ones.
<soren> Chapter 6.
<liw> oh, I didn't know triggers involve calling maintainer scripts in special ways
<soren> How would you? It doesn't say in the debian policy :)
<ion_> Documentation often lags behind code. :-)
<liw> http://lists.debian.org/debian-dpkg/2007/04/msg00076.html -- right, that does specify that the postinst takes care of triggers
<liw> soren, you should perhaps file a bug against the debian-policy package in the Debian bug tracking system
<soren> Yes, I should.
<ScottK> But the entertainment value would probably be higher if you could get Ian Jackson to file the bug.
<Cheery> hi
<Cheery> http://stackoverflow.com/questions/275207/python-ctypes-and-function-calls
<Cheery> I'd like to know how to disable no-execution -flag for my heap
<Cheery> Q9550 seems to have such retarded feature
<soren> ScottK: :)
<click170> Howcome irb in Hardy isn't compiled with --readline ?
<click170> *hangs head in shame* nm, found it
#ubuntu-devel 2008-11-09
<NCommander> ScottK, I'm glad you agree on debhelper since it would make life a lot easier w.r.t. to backporting stuff
<directhex> NCommander, DH7 for hardy!
<NCommander> yup
<directhex> 7.0.13ubuntu1~dhx1 worked fine for me, before upgrading to intrepid ;)
<NCommander> It means making backports will be tons easier since now we don't need to mangle the rules
<directhex> 0 changes needed from 7.0.13ubuntu1 according to my changelog
<NCommander> right
<directhex> i'd be very happy about an official backport, since i could erase it from my ppa
<NCommander> We could also do DH7 for dapper
<NCommander> So if we backport something, it will stop meaning having to fudge things down to DH4
<directhex> ehm... my spidey sense is screaming "check the required version of dpkg-dev" at me
<directhex> i wonder why. let me check...
<NCommander> directhex, it built w.o issue
 * NCommander sees if it installs and works
<NCommander> directhex, note, you can't drop dh7 from your PPA, since PPAs don't have backports enabled :-/
<directhex> oh anuses -_-
<NCommander> Its a long standing bug
<directhex> so is lack of debian targets for debian/ubuntu synergy
<NCommander> ScottK, when backporting something to hardy from jaunty, do we also need to backport it to intrepid?
<directhex> but important things like new launchpad logos take precedence!
<NCommander> (since hardy-backports > intrepid base)
<Hobbsee> directhex: you'll never win that battle.
<NCommander> Hobbsee, we've been promised it was going to happen "real soon now"
<Hobbsee> NCommander: yeah, yeah.
<directhex> which battle? i fight a lot of losing battles
<directhex> then grumble & move on to other things
 * NCommander notes we should just dump everyting in Hardy backports into a PPA, then make it so other PPAs can depend on it 
<Hobbsee> directhex: the one about wanting (and getting) launchpad to implement more possibly useful stuff, like fixing regressions, or adding useful features
<Hobbsee> NCommander: that would be the sensible optoin
<directhex> i probably shouldn't mention that opensuse's PPA-like service can build against pretty much any major distro, from RHEL to Debian
<directhex> it might be seen as pushing a pro-novell agenda or some crap
<NCommander> directhex, they don't take debian source packages
<directhex> NCommander, sure they do
<NCommander> I'm told you put a .orig.tar.gz, and then a debian folder
<NCommander> not the normal tar.gz/diff/dsc
<directhex> it takes orig/diff/dsc
<directhex> and some other random undocumented things
<directhex> i ran a test build, let me find it
<NCommander> ScottK, poke
<NCommander> ScottK, if we backport something from jaunty to hardy, should we also backport it to Intrepid?
<directhex> NCommander, here we go. an old mono backport build, targeting etch & hardy, from orig/diff/dsc. https://build.opensuse.org/package/show?package=Mono&project=home%3Aoerc
<NCommander> ah
<NCommander> Neat
<StevenK> NCommander:  debhelper | 7.0.13ubuntu1 |      intrepid | source, all
<NCommander> Jaunty has a slightly newer one
<NCommander> which fixes a few bugs
<StevenK> "Meh"
<NCommander> StevenK, https://bugs.edge.launchpad.net/intrepid-backports/+bug/295495
<NCommander> :-)
<ubottu> Launchpad bug 295495 in intrepid-backports "Please backport debhelper 7 from intrepid" [Undecided,Won't fix]
<StevenK> Won't fix
<NCommander> in intrepid
<NCommander> in Hardy its In Progress
<StevenK> That was actually my point. Backporting debhelper from Jaunty to intrepid is silly
<directhex> because it doesn't fix the core issue of the bug
<directhex> since it's still 7
<directhex> and the purpose of the bug is to have 7 in 7less versions
<directhex> much as bug fixes are nice
<NCommander> my concern is the upgrade path
<NCommander> Is it a bad thing is hardy-backports > intrepid?
<directhex> know what? time for beds.
<ScottK> NCommander: There isn't a strict requirement to backport to every release.  I think it's a good idea for upgraders though.
<NCommander> ScottK, Well, I just requested to backport from intrepid. so no issues
<NCommander> But we maybe should draft a policy on backporting across multiple releases
<ScottK> NCommander: I think that's a good idea.  It needs to be a function of the upgrade path.   For example, if you backport to Dapper there's no need to hit Gutsy because that's not on the upgrade path for Dapper anymore.
<NCommander> But ATM, due to our backports, the Hardy->Intrepid upgrade path may not work as expected
<NCommander> (well, anything we've backported from jaunty, which isn't much)
<ScottK> Agreed.
<NCommander> Generally speaking, if you backport to Hardy, intrepid should just work
<NCommander> THe only issue is do-release-upgrade disables backports on upgrade AFAIK
<ScottK> NCommander: It doesn't.
<NCommander> Oh
<NCommander> So as long as backports remains enabled, no issues
 * ScottK just looked at a box I recenly upgraded and backports is still enabled.
<NCommander> We should talk to jdong and make it an offical policy I guess
<OltreIrc`1517> .:::] Ci40 @ Tutti [:::. Â»BuTT3rF|y sCr|pTÂ«Â»rEvOLuTiOnZÂ»v3.1.5Â«
<OltreIrc`1517> !list
<ubottu> Hi! I'm #ubuntu-devel's favorite infobot, you can search my brain yourself at http://tinyurl.com/5zfb6t - Usage info: http://wiki.ubuntu.com/UbuntuBots
<alex-weej> is the console font supposed to be something other than the default, old IBM(?) PC one?
<alex-weej> i just booted intrepid live CD and noticed that the console font was different
<alex-weej> but in my hardy->intrepid upgraded machine it's not
<bdheeman> hello
<bdheeman> can i build x86_64 packages of an x86 machine, if yes - how?
<directhex> no.
<bdheeman> s/of/on/
<bdheeman> directhex: but, i saw openwrt build system builds kind of some ARM and other packages even on an x86 machine
<directhex> you can cross-compile, but you can't use a cross-compiler for package building in the conventional sense
<directhex> cross-compiling means using a different gcc (or different gcc flags)
<bdheeman> ok, thanks
<directhex> and you need all the libs and so on...
<bdheeman> so, better buy an amd64 machine
<directhex> well... it's certainly an easier prospect than trying to build packages you can't test, with a cross-compiler
<directhex> consider also: a PPA, since PPAs do amd64
<bdheeman> directhex: i have not heard about PPA's here in India
<bdheeman> but AMD machine are quite popular there days
<directhex> bdheeman, PPA. personal package archive. a build service on launchpad.net
<bdheeman> directhex: thanks, i was not aware of that service
<superm1> slangasek, I believe i've got all of the important pieces in order for mythbuntu live disks via livecd-rootfs and cdimage now.  i can reliably build livefs'es that are the right size at least.  could you set up the cron job(s) for building those now for whenever dailies start back up again?
<jdong> does Ubuntu squashfs support the LZMA compression method?
<jdong> i.e. in-kernel?
<pwnguin> i doubt it
<jdong> I figured
<jdong> the userspace tools support it which made me curious
<jdong> I'm re-doing my backup strategy... again... and I'm considering squashfs archiving
<pwnguin> if squashfs makes it into the kernel
<pwnguin> it might make sense to visit it
<pwnguin> lzma
<pwnguin> the liveCD is perennially out of space
<pwnguin> (or maybe perpetually)
<jdong> makes it into... the linus tree you mean?
<jdong> well bi-anually out of space ;-)
<pwnguin> yea, when i looked into it last, squashfs decided to try to get into the linus tree again
<jdong> right, I understand that's the reason why there's no LZMA support
<hyperair> vlowther: ping
<jdong> i.e. upstream doesn't want any more compression methods in the kernel
<pwnguin> jdong: you should probably double check with the ubuntu kernel ML
<pwnguin> i donno if there's plans or if i missed something, etc
<RainCT> (btw, does someone know how to fix/workaround some applications which are displaying solid black instead of input from the webcam? I believe this to be because the webcam uses JPEG compression and the applications don't support it.)
<mohbana> hi, anyone familiar with fontconfig? what's wrong with this; http://pastebin.com/m53266bde
<jdong> grumble stupid pulse dying after suspend
<hyperair> jdong: there's a bug regarding that
<hyperair> jdong: and a fix ready
<jdong> hyperair: neat :)
<hyperair> jdong: bug 202089
<ubottu> Launchpad bug 202089 in pulseaudio "Pulseaudio is blocking normal sound after resume" [Low,In progress] https://launchpad.net/bugs/202089
<hyperair> it seems to be assigned to someone else, and in progress
<hyperair> i realized that after i came up with a workaround and created a debdiff
<hyperair> so now i'm actually wondering what i should do
<directhex> cry!
<jdong> hyperair: well it's been assigned to crimsun, so I'd say it's in the best hands :)
<hyperair> =\
<hyperair> directhex: hmph
<pwnguin> who assigned it to crimsun?
 * hyperair has no idea
<pwnguin> if it wasn't crimsun himself, might as well at least attach the debdiff
<hyperair> pwnguin: it's attached
<jdong> pwnguin: I see a SRU-compatible debdiff attached
<ScottK> According to the activity log he assigned it to himself.
<pwnguin> hyperair: then i guess you just wait ;)
<hyperair> i guess
<hyperair> speaking of sru and debdiffs... could someone help me out with bug 267922 /
<hyperair> ?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/267922/+text)
<pwnguin> eep
<hyperair> lol
<hyperair> i don't have any trouble accessing that
<hyperair> bug 267922
<ubottu> Launchpad bug 267922 in banshee "Banshee hangs up/crashes when pluggin in MTP-USB-Player" [Undecided,Confirmed] https://launchpad.net/bugs/267922
<hyperair> there we go
<jdong> hyperair: ok that one is within my umbrella of authority, lemme take a look at your debdiff
<hyperair> jdong: thanks =)
<jdong> hyperair: where did the patch come from? did you write it?
<jdong> it's pretty big, just trying to understand it
<hyperair> jdong: extracted from trunk
<jdong> hyperair: gotcha
<jdong> hyperair: ok I acked the SRU for you
<hyperair> thanks
<jdong> subscribe ubuntu-universe-sponsors
<jdong> let me know if you don't get sponsorship in a reasonable timeframe
<hyperair> alright
<hyperair> what's a reasonable timeframe?
<jdong> within a few days, I'd say.
<hyperair> okay
<hyperair> jdong: should i unsubscribe motu-sru?
<jdong> hyperair: no need ,keep them subscribed
<hyperair> okay
<Heller_Barde> hai
<Heller_Barde> I am an Archlinux user and would like to know how i can find out how ubuntu packages are built and packaged. Can someone help me with that?
<directhex> Heller_Barde, specifically...?
<Heller_Barde> directhex: actually the background is that i would like to build some packages (around xorg) with ubuntu patches because i have serious performance issues with opengl applications
<hyperair> Heller_Barde: what do you want to know?
<sebner> !packageing | Heller_Barde
<ubottu> Sorry, I don't know anything about packageing
<sebner> !packaging | Heller_Barde
<ubottu> Heller_Barde: 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
<Heller_Barde> and i found my way to the patches and everything and i found out that its not only the patches that made the difference but obviously too how it is built.  i got as far as debian/rules but that's source-package specific, i now would like to know how the actual packages are built
<hyperair> debian/rules
<hyperair> that's the key to everything
<Heller_Barde> ubottu: oh cool, ill look at that and get back to you with questions
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<Heller_Barde> ah
<Heller_Barde> ^^
<hyperair> heh
<Heller_Barde> sebner i meant
<Heller_Barde> ^^
<hyperair> Heller_Barde: debian/rules is a Makefile. everything goes in there
<sebner> Heller_Barde: :) np
<Heller_Barde> hyperair: yes, i saw that. but from one source packages several binary packages are made
<directhex> okay, the whirlwind tour. source packages (with a few exceptions) come in three files - foo.orig.tar.gz contains the upstream software, converted to gzip where required. foo.diff.gz contains a gzip diff of all the changes between the upstream tarball, and what is needed for packaging - typically it should only contain the "debian" folder, which has the files in it about how to build. foo.dsc is a manifest, pointing to the other tw
<directhex> o files
<directhex> the key files in the debian/ folder are "rules" and "control"
<hyperair> Heller_Barde: patches in debian/patches, configure flags in debian/rules somewhere, post installation stuff also in debian/rules
<Treenaks> directhex: hurricane warning ;)
<directhex> "control" is the list of information about the package - dependencies, general package metadata, and contains the list of binary packages (and their deps) as well as info on the source package. the metadata is used by apt/dpkg
<directhex> Treenaks, i prefer to think of it as a monsoon
<Heller_Barde> mhhmhh but lets say i have the source packages, i patched everything and then built it (which is pretty tough without a debian system ^^) and then what? where comes the splitting stuff up in the several packages?
<directhex> "rules" is a makefile, which does the configure.make stuff. in most cases, it'll use a "helper" app of some kind, such as debhelper, which will do assorted cleanup - generating automatic deps, putting files into actual packages, and so on
<hyperair> Heller_Barde: then there's postinst, postrm, preinst, prerm which are hooks that are run when installing/upgrading/removing the package on the user's system. kinda like the one archlinux has.. what was it called? something.install?
<Heller_Barde> hyperair: yep
<hyperair> damn my archlinux packaging is rusty.
<directhex> Heller_Barde, the splitting is done by a debhelper command in debian/rules
<Heller_Barde> hyperair: how so? there is soo little to know ^^
<Heller_Barde> directhex: ahh, i seem to have missed that
<Heller_Barde> i'll scour through mesa-src again
<hyperair> Heller_Barde: i know. i forgot it heh. the names mostly. i still remember how to make a PKGBUILD build() function
<directhex> Heller_Barde, specifically, look for lines about dh_install and dh_installdeb
<hyperair> wait, you're poking around with mesa? i've got experience with that one.
<Heller_Barde> yes
<hyperair> Heller_Barde: exactly what are you looking for?
<directhex> Heller_Barde, those two will use a list of files matching the binary package name - e.g. libmoon0.install contains the list of files which dh_installdeb will put into the libmoon0 package
<Heller_Barde> i use compiz as performance: 3-8 fps in archlinux (with testing) and 30-40 fps in ubuntu 8.10 on a intel x3100 (965gm chipset)
<Heller_Barde> and i tracked it down to some packages
<hyperair> regarding the package splitting, you needn't really look into those... archlinux doesn't split packages
<hyperair> so yo wouldn't be able to use it anyway
<Heller_Barde> hyperair: actually it does
<hyperair> eh? since when?!
<Heller_Barde> *smiles sheepishly*
<Heller_Barde> just some
<hyperair> O_o
<Heller_Barde> exactly the ones i need
<hyperair> how?
<Heller_Barde> well its just that intel-dri is built from mesa-src
<hyperair> @_@
<Heller_Barde> no idea why its not integrated
<Heller_Barde> no fucking clue (sry for language)
<hyperair> lol
<hyperair> anyway
<hyperair> here's how the build process works.. mostly
<hyperair> the debian/tmp folder is ismilar to archlinux's pkg/ folder
<Heller_Barde> one moment i'll get my project folder, i have one or two questions
<hyperair> that's where everything goes just before splitting happens
<hyperair> then it'll go into debian/package_name
<Heller_Barde> hyperair: okay
<hyperair> well sometimes you can skip debian/tmp
<hyperair> and go straight into debian/package_name
<hyperair> but generally for stuff with many packages, we dump everything in debian/tmp first
<hyperair> and stuff is split based on package.install files
<hyperair> which contain lists of files
<hyperair> what goes into where kinda thing
<Heller_Barde> holy moly, i get it now
<hyperair> okay =)
<Heller_Barde> i just looked at it again and went am i frickin stupid
<hyperair> heh
<hyperair> well
<Heller_Barde> sry, i had an epiphany
<Heller_Barde> i guess i was too tired last time
<hyperair> heh
<hyperair> no worries i get stuff like that once in a while
<Heller_Barde> it was pretty frustrating... well, that's what you get going from warm, fuzzy, easy packaging in arch to the hard world of debian :P
<Heller_Barde> brb
<hyperair> well it depends on whether they're using raw debhelper or cdbs
<hyperair> cdbs packaging is awesome
<hyperair> i use it all the time
<RAOF> hyperair: CDBS is magic harvested from the rich plumes of arcanum which spew from deep-sea volcanoes.  When you're doing exactly what it's designed for, it's great.  When you try to bend it a bit, you play "chase the make rule" through endless includes, all alike.
<hyperair> RAOF: nice analogy
<sebner> hyperair: another try would be: "Black magic"
<hyperair> xD
<hyperair> i like cdbs. it does most of what i need, compared to debhelper and its 186940747134 different dh_* commands
<sebner> hyperair: already tried dh7? :)
<hyperair> nop
<hyperair> i haven't even bothered learning the names of all the dh_* commands
<sebner> hyperair: take a look at it and tell me again the difference between dh and cdbs ;)
<hyperair> =.=
<RAOF> It's all the joy of cdbs, but with the ability to clearly see what the hell's happening.
<hyperair> any docs i can read?
<RAOF> man dh
<lifeless> dh(3SSL)                                                                                            OpenSSL                                                                                           dh(3SSL)
<lifeless> NAME
<lifeless> :P
<lifeless>        dh - Diffie-Hellman key agreement
<lifeless> ?
<hyperair> lifeless: wrong dh
<RAOF> lifeless: You'd be after "man 1 dh", then.  :P
<lifeless> RAOF: I think I was hinting that you should be more precise :>
<RAOF> lifeless: Pfft.  Precision is for mathematicians!
<lifeless> RAOF: zigactly
<lifeless> RAOF: unless you're a statistician
<RAOF> Then you have precise things to say about how imprecise you are.
<lifeless> precisely
<Heller_Barde> okay, i do have some questions now. wtf do all these dh_* commands do?
<pecisk> Heller_Barde: dh stands for debian helper scripts
<Heller_Barde> ah -.-
<directhex> each script has a specific job
<Heller_Barde> what is the $* variable in a makefile?
<radix> Heller_Barde: each of the dh_ programs has a man page
<radix> and there's a 'debhelper' man page
#ubuntu-devel 2009-11-02
<amikrop> Hello. Please package the latest gnome-screensaver into the main repos, because it now has the bug of not being able to stop when playing fullscreen movies.
<amikrop> A signal (I think --poke) does not work with the current version.
<amikrop> But now there is a patch.
<MsMaco> is a bug filed?
<amikrop> I think.
<superm1> yes, siretart was on that shortly before release
<superm1> i'm not sure what happened of it though
<MsMaco> hi superm1
<superm1> hi MsMaco
<ajmitch> superm1: it's in a PPA, I'm guessing he might look at getting it into -updates
<amikrop> https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/428884
<superm1> i sure hope so. it's certainly a very suboptimal experience right now
<ubottu> Ubuntu bug 428884 in gnome-screensaver "gnome-screensaver --poke functionality does no longer inhibit screen blanking" [Unknown,Confirmed]
<amikrop> I think this is the report. So, is the package ready to get available as an update?
<MsMaco> superm1: im going to be attempting to make a dkms-based package soon, going off that UDW session you did a while back. if i get stuck, do you mind if i poke you?
<superm1> MsMaco, it would be better if you did said poking tomorrow, but yes feel free
<superm1> things are actually significantly easier nowadays too
<superm1> and will only be improving now that debian is working on dh_dkms :)
<mneptok> amikrop: is the person that fixes that bug the "Screen Savior?"
<MsMaco> ah, i wont be attempting it today anyway. i have to migrate laptops so i can send this one for a replacement hinge. lid's almost detached :(
<ajmitch> mneptok: puns like that should be shot
<superm1> ah, then that would make it quite difficult to work with.
<wgrant> Are the powerpc buildds still running Dapper?
<MsMaco> will also make it difficult to test with since the hardware itd be enabling is on the to-be-fixed laptop :P gonna get bugabundo to test it for me ;)
<amikrop> mneptok: :P
<amikrop> superm1: excuse me, but I didn't get what it is going to happen with this case
<amikrop> the package is ready and it is going to be moved on official updates?
<superm1> amikrop, i've not followed the details here, but once the proper fix has been developed, it will be put into -proposed
<ajmitch> amikrop: no, from reading the bug, the package is mostly ready but needs some further work
<wgrant> s/will/may/
<bluefox_> why is rhythmbox stupid?
<superm1> people will need to verify that it works, and it will live there for about 2 weeks, and then go to updates if it fixes the problem properly without introducing regressions
<ajmitch> wgrant: I think siretart plans to follow through with fixing it :)
<MsMaco> bluefox_: because applications lack brains?
 * bluefox_ saves a file into ~/Music/, rhythmbox sees the .part and then loses the file when the .part is lopped off and the file's called .mp3
<amikrop> superm1: wow. would you suggest any workarounds until then?
<iWolf> Is there any Community Council Members Here?
<MsMaco> iWolf: pleia2 is signed on to freenode, but she's afk right now
<iWolf> Anyone else
<wgrant> iWolf: Why do you want a CC member?
<iWolf> I need to ask a question
<iWolf> Community Council Related
<iWolf> Community*
<lifeless> just ask it
<lifeless> if we can't help we'll point you at the list
<iWolf> Its about Teams
<iWolf> Check this bug: https://bugs.launchpad.net/ubuntu/+bug/464710/
<ubottu> Ubuntu bug 464710 in ubuntu "LiveCD freeze" [Undecided,New]
<iWolf> Problem with distro?
<jgoppert> I'm trying to repackage libjsw on my ppa. My first go at this. Anyways it doesn't work for karmic due to a gtk 1.2 dependency. I've got a quick fix that will work but I can't figure out dpatch. I try to modify debian/rules not to run the makefile in the jscalibrator directory and somehow after i create the patch and apply all patches it still tries to call the makefile in this directory. I think it is possibly that someone unp
<MsMaco> "someone unp..." cutoff
<jgoppert> I think it is possibly that somehow unpatch is being called by build and that somehow allows make to run on an unpatched debian rules file?? help??
<ebroder> jgoppert: You can't patch debian/rules using dpatch. Just edit it directly
<RAOF> And you're right: unpatch will be a part of the clean target, which will be run first in the build process.
<jgoppert> ok thats kind of what i thought was going on, so i modify the original tarball? or how do i go about that
<jgoppert> stupid question i know but i've tried that and have been very lost, do i do it in the patch to the original tarball? like the .gz.diff
<RAOF> You don't modify the original tarball, you modify the packaging directly, then the source package contains your changes in the diff.gz.  This is better suited to #ubuntu-motu, by the way.
<jgoppert> ok thanks for the help guys
<jgoppert> they are kind of dead over there a motu, so anyways i figured out what i was doing and got libjsw packaged, i noticed that when uploading to the ppa i just give it my .changes file, but since there is no original tarball on my ppa do i need to upload that as well, the tarball is also not in karmic yet
<ScottK> jgoppert: #ubuntu-motu really is more appropriate than here.
<bluefox_> okay I'm going to ask this before going forward.
<bluefox_> Did someone hard-disable IP forwarding in the Ubuntu kernel?
<ion> Works in 2.6.31-14-generic-pae
<bluefox_> nevermind I'm dumb
 * bluefox_ writes a firewall rule for IP masquerading.
<dtchen> not that I can see. /etc/sysctl.conf unsets the /proc bits by default, but that's fairly straightforward to enable.
<bluefox_> Yeah, I had forgotten that I have to do PAT for this to work.
<slangasek> pitti: is there some straightforward way that apport could check for "package is already installed and configured" as the error message, and file the bug against dpkg or apt or something instead of the individual package which isn't at fault?
<lifeless> slangasek: probably; we can haz bug plz?
<slangasek> done
<MsMaco> lolspeak is an accepted dialect here?
<StevenK> MsMaco: Sometimes.
<emgent> ccheney`: ola ola
<syn-ack> I know its waaaaaaaaaay OT but you guy have GOT to see this: http://www.youtube.com/watch?v=pAoqOCQlb0E
<syn-ack> I'm still laughing
<lifeless> MsMaco: selectively :)
<laptopnenolod> so, umm
<laptopnenolod> mountall has some weird bug where it hangs when ran on Xen
<eboyjr> Does Quickly have a dev website besides Launchpad?
<eboyjr> https://wiki.ubuntu.com/Quickly is good, nvm
<dholbach> good morning
<eboyjr> dholbach, good night
<dholbach> hi eboyjr
<eboyjr> Lol hiya.. It's night over here :P
<dholbach> :)
<pitti> Good morning
<omani> g morning
<pitti> MsMaco: no problem :)
<pitti> slangasek: yes, should be easy; found the bug
<pitti> (... report)
<lifeless> anyone spent any time looking into the wrong kernel/initramfs after upgrading to karmic?
<MsMaco> lifeless: dan's been looking
<MsMaco> apparently users are prompted about keeping old config or using new one
<MsMaco> and are choosing to keep the old config
<MsMaco> and thus grub is not updated
<lifeless> MsMaco: I wasn't prompted...
<slangasek> pitti: ok - morning :)
<pitti> slangasek, mvo: for disabling apport again after that dist-upgrade, would I do the conffile change in preinst or postinst? I think "preinst", to avoid conffile questions, right?
<MsMaco> lifeless: nor was i. thats the confusing bit. no idea what determines who is prompted
<mvo> I think preinst
<pitti> since "no" is the default
<slangasek> pitti: I don't think there's much difference, really - since the conffile shouldn't have changed between the previously installed version and the current one, there'd be no conffile prompt anyway
<slangasek> preinst lets you correctly handle the exceptional case where the user has removed apport and is reinstalling it
<pitti> slangasek: ah, true
<slangasek> so preinst is a bit better :)
<slangasek> lifeless, MsMaco: has anyone grabbed a copy of one of these "Don't install the maintainer's version" menu.lst files yet?
<pitti> changing conffiles in maintainer scripts is new territory for me, so I better double-check
<lifeless> slangasek: let me see if a backup was kept by update-grub
<slangasek> update-grub keeps one backup
<lifeless> MsMaco: whats the bug #
<MsMaco> lifeless: there isnt a single bug. there's hundreds of bugs over the last 3 days that dtchen has triaged
<MsMaco> of people with "no sound after upgrade" because they're using the wrong kernel
<MsMaco> slangasek: no idea. dan may have
<MsMaco> slangasek: he's asleep though
<lifeless> MsMaco: there should be a single master bug or the failure to upgrade the menu.lst correctly
<MsMaco> i guess...vast majority are being filed as audio bugs
<MsMaco> there's also the caveat that some of these people, when told to use the right kernel...end up with no X
<MsMaco> so they have to choose between 2.6.31-with-sound-but-no-X or 2.6.28-with-X-but-no-sound
<MsMaco> (ive spent a lot of time on the forums the last few days)
<slangasek> lifeless: well, they're each going to have to be looked at individually regardless, because many of these are likely to be "I changed menu.lst by hand, then update-grub did what I told it to" - there's no way to fix that other than using <blink> tags in the release notes, the menu.lst format is crap and this was a major reason for pushing grub2
<slangasek> (too bad we didn't get grub2 by default on upgrade, this cycle)
<lifeless> slangasek: sure, they have to be looked at
<lifeless> slangasek: so, is the bug, 'if any menu.lst changes were made, we fail to run update-grub' ?
<slangasek> no, not atall
<lifeless> slangasek: then I totally misunderstood what you said
<slangasek> we run update-grub, update-grub pops up a message informing the user that there's a conflict between their local changes and the changes the system wants to make, user clicks through "keep my changes" and ends up not getting entries for the new kernel
<MsMaco> whereas it should be more of a merge?
<slangasek> merge is one of the options the user didn't choose
<lifeless> slangasek: ok. That doesn't match what happened to me.
<slangasek> lifeless: gonna need more info, then
<lifeless> slangasek: I upgraded, rebooted, no sound. Ran 'sudo update-grub', which did not prompt me at all. Rebooted, had sound (though initially muted).
<slangasek> lifeless: and the kernel package was in 'installed' state?
<lifeless> I have the backup menu.lst.
<slangasek> hit me
<MsMaco> oh. what dan saw in one comment looked more like "i upgraded, during upgrade i was prompted, i chose no, rebooted, and had no sound"
<lifeless> slangasek: I can make no assertions about the kernel packages state at the time, i didn't think to check.
<slangasek> lifeless: have you run update-manager or apt or dpkg since then?
<lifeless> slangasek: I think so
<slangasek> lifeless: ah; well, give me time stamps for the menu.lst files and full dpkg/apt logs as well, then :)
<lifeless> slangasek: what bug do you want it on
<lifeless> or should I make a new on?
<lifeless> one?
<slangasek> lifeless: feel free to open a new one on grub
 * lifeless pops through to the other machine
<slangasek> these other bugs apparently haven't been getting triaged over to the grub package yet, so I've only seen the barest trace of this issue
<MsMaco> slangasek: look at pretty much any "alsa-driver" bug in the last week...
<MsMaco> dan sent one of 'em to you two in email
<MsMaco> he pasted a link to another comment along the same lines in here earlier, but i dont have scrollback
<lifeless> 108576 could be a candidate
<slangasek> *week*?  and no one thought to escalate it before the release?
<MsMaco> he said he hit a couple of these weird "booting into the wrong kernel" ones back around beta but didnt notice the trend
<slangasek> MsMaco: I have one thread in my mailbox about this starting Saturday, though lifeless isn't Cc:ed, so not sure if that's who you mean by "you two"
<MsMaco> lifeless = robbie?
<slangasek> MsMaco: hah, no
<MsMaco> oh oops
<JanC> according to crimsun some changes need a 2-5 min power down before they work because of crappy hardware, so that might also accidentally explain what lifeless saw...
<slangasek> lifeless: 108576> unlikely to be the same bug, the ucf-based update-grub handling didn't exist back then
<slangasek> lifeless: well.. might be the same as /your/ bug, but not the same as the other one I'm complaining about
<lifeless> slangasek: kk
<lifeless> slangasek: is apt/term.log useful?
<MsMaco> i only heard about grub not updating when a week before release someone in #ubuntu+1 said current was -10 because his grub hadnt been updated since then
<slangasek> lifeless: apt/term.log and dpkg.log both; I expect I'll need to cross-reference
<lifeless> anything sensitive in term.log? its 0500
<MsMaco> shouldnt be...its just the spew from apt-get install type operations
<lifeless> no passwords ?
<slangasek> right, I'm not aware of anything sensitive; they routinely get copied to bug reports without setting the 'private' bit
<slangasek> passwords> God, I hope not
<slangasek> that would be Special
<lifeless> ok
<MsMaco> haha
<lifeless> slangasek: bug 470265
<ubottu> Launchpad bug 470265 in grub "intrepid to karmic upgrade failed to update menu.lst" [Undecided,New] https://launchpad.net/bugs/470265
<lifeless> bug 470265
<lifeless> bug, ubottu fail..
<lifeless> bug, ubottu fail..
<lifeless> bug 470265
 * lifeless shrugs
<lifeless> slangasek: its there, ping me if you want more.
<slangasek> intrepid to karmic, eh?
<slangasek> lifeless: will do, thanks
<lifeless> slangasek: jaunty.
<slangasek> ok :)
 * lifeless slaps himself
<slangasek> lifeless: timestamps on menu.lst*?
<slangasek> (need to know where to line it up with in the logs)
<lifeless> slangasek: the backup appears to be open, copy data as opposed to 'cp -a' or 'mv'
<lifeless> slangasek: the timestamp is unlikely to be useful, still - I've attached it
<slangasek> right, ok; that limits its usefulness, but I should be able to get something out of it
<slangasek> huh, the diff is telling
<slangasek> update-grub has only successfully run once since the new kernel was unpacked
<lifeless> right
<lifeless> I just don't know *why* :)
<slangasek> lifeless: grep postinst_hook /etc/kernel-img.conf ?
<lifeless> zip
<slangasek> we really ought to put those hooks in /etc/kernel/postinst.d instead of relying on the installer's setup to have infinite shelf life
<lifeless> nada
<lifeless> nothing
<slangasek> lifeless: that's it, then.  On a normal system, you should see 'postinst_hook = update-grub'
<lifeless> I haven't touched kernel-img.conf
<slangasek> lifeless: when was this machine installed, and how?
<lifeless> so the bug is 'somehow kernel-img.conf is missing postinst_hook'
<slangasek> did you ever have lilo on it instead of grub?
<lifeless> no, its my new i7 desktop
<slangasek> please post your full kernel-img.conf to the bug
<lifeless> which dates it
<pitti> slangasek, mvo: apport fix committed (see bug followup, and http://bazaar.launchpad.net/%7Eubuntu-core-dev/ubuntu/karmic/apport/ubuntu/revision/1570); quick eyeballing appreciated
<lifeless> slangasek: done, with datestamp
<lifeless> slangasek: which is either the jaunty cd datestamp, or when I installed the machine.
<slangasek> lifeless: ack, thanks
<lifeless> slangasek: I'm quite sure I installed jaunty fresh on it
<slangasek> hmm, disturbing thought that all jaunty installs from liveCD might have this problem :/
 * slangasek will start poking at the livefs
<lifeless> its certainly never had lilo on it
<slangasek> right
<lifeless> Was it a livecd install? I think so. dmraided though, so I may have manually partitioned
<lifeless> theres probably a log somewhere ;)
<lifeless> indeed, installer logs are present if you want them
<slangasek> lifeless: oh awesome, please attach those also :)
<slangasek> (anyone wandering by this bug is going to be completely confused by the stack of attached files)
<lifeless> 21 april is the deb timestamp
<lifeless> slangasek: are passwords in the installer logs?
<slangasek> pitti: $1 check is superfluous but not wrong; bdmurray pointed out on the bug that release-upgrader 0.126.5 would also have this bug, so best to grep for 0.126.[56].  Otherwise, looks ok to e
<slangasek> me
<slangasek> lifeless: nope
<slangasek> (man, what do you take us for :)
<pitti> slangasek: ah, thanks
<slangasek> oh hey, I don't have to download a copy of the jaunty ISO to check this, do I
<slangasek> the bandwidth of me walking across the house and back is awesome
<pitti> slangasek: I just noticed that apport doesn't upgrade with being disabled (the upstart job failed, which causes postinst to fail); I'll file a bug and fix this first
<slangasek> pitti: meep; methinks we should have a session on writing upstart jobs at UDS
<pitti> slangasek: oh, nevermind; it's the new lucid debhelper apparently
<slangasek> oh, hmm
<pitti> it adds an additional invoke-rc.d call
<slangasek> mismerge?
<mdke> slangasek: pitti: I wonder if you have any ideas on the cause of bug 464037 - we have two duplicates (from Dell machines) and I can confirm it myself when installing gnome-user-guide-gu. I've read through the build log but can't figure it out, I wonder if it is something to do with pkgstriptranslations. Not urgent, but if you have any bright ideas...
<ubottu> Launchpad bug 464037 in gnome-user-docs "package gnome-user-guide-gu (not installed) failed to install/upgrade: trying to overwrite '/usr/share/omf/gnome-access-guide/gnome-access-guide-C.omf', which is also in package gnome-user-guide 0:2.28.0+git20090921ubuntu2" [Medium,Confirmed] https://launchpad.net/bugs/464037
<lifeless> slangasek: I've written a good summary I hope
<slangasek> pitti: oh, you merged it ;)
<pitti> slangasek: well, most of the upstart bits were committed to debian, so apparently there was an eror somewhere; will look into this after I'm done with this SRU
<lifeless> MsMaco: this bug is the master, if you have other bugs where just upgrade-grub fixed the problem (no prompts being asked, just-worked), please feel free to close them as dups to this bug
<slangasek> pitti: no, only *some* of the upstart bits were committed to Debian, then Keybuk extensively modified debhelper again after I'd negotiated that patch with joeyh
<lifeless> slangasek: the concept of this being every or even  many livecd installs is scary-as
<slangasek> so the chance of a mismerge is actually quite high
<pitti> slangasek: yeah, there were some bits which weren't accepted, I merged those
<pitti> especially the --only-upstart bits
<slangasek> lifeless: indeed - but it gives us a nice way to clean up all the bug reports at once
<slangasek> pitti: well, it's not that they weren't accepted, it's that they haven't been submitted... anyway, I guess you'll be able to sort it now that you're looking at it :)
<slangasek> [281264.038921] SQUASHFS error: Major/Minor mismatch, older Squashfs 3.1 filesystems are unsupported
<slangasek> <cough> right, how do I mount a jaunty squashfs :P
<MsMaco> lifeless: alrighty
<lifeless> slangasek: someone claimed that the initramfs could be stale too, but I haven't seen data to corroorate that
<lifeless> s/oo/obo
<slangasek> that'd be a separate bug, and should only ever happen when the kernel package has failed to finish installing
<MsMaco> yeah i saw one person in #ubuntu where initramfs was wrong after an update-grub. the initramfs existed, so i just told them to edit it manually and it worked
<MsMaco> er edit menu.lst manually
<MsMaco> slangasek: inside a jaunty vm?
<slangasek> MsMaco: no virtualization capabilities here
<slangasek> if I had a jaunty vm, I wouldn't need to loopback mount the CD, I could just... boot the CD :)
<slangasek> (which is what I'm going to end up doing as soon as I wrap this email)
<MsMaco> i can look if you tell me what to look for
<wgrant> cjwatson, slangasek: How important is v3 source package support before 2009-12-05?
<slangasek> MsMaco: I want the contents of /etc/kernel-img.conf from inside the livefs
<slangasek> MsMaco: specifically, I'm comparing it with http://launchpadlibrarian.net/34936461/kernel-img.conf
<MsMaco> ok
<pitti> wgrant: we'll start the syncs/merges from Debian in the next days, so if we need it at all, we need it soon, I guess
<slangasek> wgrant, pitti: well, I wonder how quickly the new formats are going to be adopted - so far we just have buxy's one test package, right?
<slangasek> and if we're autosyncing from testing, that's 10 days grace period
<wgrant> Right. It's unclear exactly how quickly it will be adopted.
<pitti> slangasek: apport waiting in karmic/unapproved now
<pitti> wgrant: right, that's the "if we need it at all" (for lucid) bit
<pitti> I haven't seen such a package yet
<slangasek> pitti: ok; may not get a chance to approve that 'til morning
<wgrant> pitti: There is only one in the Debian archive at the moment.
<slangasek> pitti: there's one test package in the archive; I know buxy is chomping at the bit to be able to start uploading them :-)
<pitti> if it's only two or so, we can easily rebuild them on our side for lucid
<wgrant> But dak only gained support for it last week.
<\sh> moins
<MsMaco> lifeless: wait where's that bug number?
<MsMaco> 470265?
<lifeless> bug 470265
<ubottu> Launchpad bug 470265 in grub "[MASTER] intrepid to karmic upgrade failed to update menu.lst (update-grub missing from kernel-img.conf)" [High,New] https://launchpad.net/bugs/470265
<lifeless> oh wow ubotto fail
<lifeless> or hmm
<lifeless> no slangasek trampled on my edit
<lifeless> it should say jaunty
<slangasek> heh
<slangasek> thank AJAX :)
<lifeless> hell no
<lifeless> least you didn't edit the description
<lifeless> :)
 * slangasek grins
<\sh> oh that bugged me too...and I thought I messed my installation (intrepid -> jaunty -> kernel update fail)
<MsMaco> lifeless, slangasek: ok, livecd's /etc/kernel-img.conf attachd to bug
<MsMaco> lifeless: it says jaunty when i look in firefox in the vm
<slangasek> MsMaco: thanks
<MsMaco> np
<lifeless> MsMaco: yes, cause I just fixed it ;)
<slangasek> lifeless: was yours i386 or amd64?
<lifeless> amd64
<slangasek> ok
<slangasek> (probably doesn't matter, just wondering which livefs build logs to look at)
<slangasek> somebody want to check the kernel-img.conf in a *karmic* livefs?
<MsMaco> booting i386 karmic...
<slangasek> no mention of kernel-img.conf anywhere in the livefs build log for jaunty final, so not sure what actually generates the one that's there in the livefs - the kernel package, maybe
<slangasek> well, when ubiquity calls grub-installer it should unconditionally add its hooks to /etc/kernel-img.conf
<MsMaco> still need the karmic live cd's /etc/kernel-img.conf?
<lifeless> slangasek: what one in the live fs ?
<slangasek> MsMaco: might be nice for reference
<lifeless> MsMaco: yes, I'd say that that is a useful thing.
<MsMaco> ok
<slangasek> lifeless: the /etc/kernel-img.conf
<lifeless> slangasek: not the file, the hook :)
<lifeless> http://launchpadlibrarian.net/34939246/kernel-img.conf - no hook
<lifeless> I wonder if it might be an ordering problem
<lifeless> grub-installer before /etc/kernel-img.conf exists
<lifeless> if grub-installer is depending on dpkg hooks to run lazily at the right time
<buxy> slangasek: everybody can upload new packages using new formats, I did logitee-tools, quilt itself and ftplib
<slangasek> lifeless: not in the karmic version of grub-installer; checking jaunty now
<slangasek> buxy: quilt> bah :)
<slangasek> buxy: anyway, obviously everybody /can/ upload packages in the new format, I just have no feel for how many /will/ do so or how quickly
<buxy> slangasek: that depends also whether I make dpkg-source produce new formats by default or not :)
<slangasek> ugh
<slangasek> well, that would neatly screw Ubuntu over until LP supports v3, then
<buxy> it has been accepted as release goal, and there aren't that many packages failing to build with new formats, see http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=hertzog@debian.org;tag=3.0-quilt-by-default
<slangasek> it's been accepted as a release goal to make it the /default/?
<slangasek> that's not mentioned on http://release.debian.org/squeeze/goals.txt or http://wiki.debian.org/ReleaseGoals/NewDebFormats
<buxy> "Have all packages in the archive buildable using the new source package formats." => this is my prerequesite to enable dpkg-source to produce new format by default
<slangasek> well, yes, but that doesn't mention anything about actually /making/ it the default for squeeze...
<buxy> well, the other half is my responsibily as dpkg (co-)maintainer, I can surely make that decision? and it's not like I haven't made it clear since quite some time
<lifeless> buxy: changing the default will affect every derivative distro
<slangasek> obviously if we're having this conversation, it wasn't clear to me that you meant to make it the default for squeeze
<slangasek> it is your decision; I'm informing you of one side effect of this decision
<buxy> but it needs some fine-tuning still, I will probably solicit some input
<buxy> slangasek: I'm still not sure we can make it for squeeze, it has taken much longer than what I hoped
<Whoopie> jdong: thanks for ACKing bug 427217. What are the next steps?
<ubottu> Launchpad bug 427217 in openwsman "FTBFS in karmic" [High,In progress] https://launchpad.net/bugs/427217
<al-maisan> EOCHAN
<buxy> slangasek: is there a launchpad ticket requesting support of the new format in the ubuntu infrastructure?
<slangasek> wgrant: ^^ ?
<wgrant> Bug #293106
<ubottu> Launchpad bug 293106 in soyuz "does not support debian v3 source formats" [Critical,In progress] https://launchpad.net/bugs/293106
<wgrant> The code is pretty much done.
<wgrant> But it is very very awkward timing.
<buxy> thanks, I subscribed to it, if you have questions just ask
<slangasek> MsMaco: well, so far my sampling of recent alsa-driver bugs yields me only reports from people who /are/ running the karmic kernel
<slangasek> hmm, a lot of checkbox bugs
<fatal^> buxy: debian bug #485137 should be fixed in unstable (sometimes during the 2.27.x experimental era).... would be nice if you could confirm that (and tag the bug appropriately)...
<ubottu> Debian bug 485137 in totem "totem: FTBFS when converted to new source format 3.0 (quilt): diff.gz contains cruft" [Minor,Open] http://bugs.debian.org/485137
<buxy> fatal^: the recipe to reproduce is easy, why don't you do it yourself?
<MacSlow> tseliot, yeah... let's hope that "special driver" is an OpenSource one
 * tseliot nods
<fatal^> buxy: no time/interest/access_to_suitable_system at the moment. will probably forget it, so I thought it might be slightly better to poke you about it now.
<MacSlow> tseliot, th GPU-core in the GMA500 isn't too bad... has geometry-, vertex- and fragment-shaders in hw
<buxy> fatal^: it might be better to record that information in the BTS
<buxy> I don't have time for such individual request, if I do anything like that it will be automated over all the bugs I submitted :)
<tseliot> MacSlow: yes, it doesn't draw too much power and has hardware HD video decoding
<tseliot> so it's good on the paper
<MacSlow> tseliot, afaik the same GPU-core also drives the iPhone's screen
<tseliot> power-VR?
<MacSlow> tseliot, yes
<tseliot> let's cross our fingers and wait then :-)
<SandGorgon> is Ubuntu going to follow XDG desktop specifications (http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html) - for config file locations ?
<pitti> SandGorgon: we try, anyway; but of course there's still a lot of old upstream software which doesn't
<lucas> gah. ruby1.8 needs a SRU. The version in unstable/testing fixes several major bugs, but nobody noticed :(
<soren> Do we have an expected ETA for when Lucid opens? Do we expect it to be this week?
<mvo> soren: rumors in #ubuntu-release say soon, almost certainly this week
<soren> mvo: Cool. Thanks.
<pitti> soren: still waiting for a debhelper fix to publish, then I think we're ready
<pitti> soren: feel free to upload already (it'll land in the queue)
<tseliot> MacSlow: http://www.phoronix.com/scan.php?page=news_item&px=NzY2Mg
<soren> pitti: Great. Thanks!
<engla> DktrKranz: thanks for your work on Kupfer. I think next version is going to default to install in DATADIR
<engla> (install its python package there). I think it's smarter anyway, and as long as the binary is in the $PATH, there is no trouble to find the package
<DktrKranz> yup :)
<engla> but it is strange for a linux package to be installed all in one directory like that
<DktrKranz> well, it's one of the features provided by python packaging, in case someone ever wants to package some "kupfer" module, and make it available system-wide, we're safe
<dholbach> https://wiki.ubuntu.com/UbuntuOpenWeek kicking off in 1 minute in #ubuntu-classroom
<mantiena> Hi all
<mantiena> I've noticed lots of identifical bugreports about jaunty->karmic upgrading problems when users have ttf-mscorefonts-installer (same bug occurs when also during installation ttf-mscorefonts-installer package, but not so often), maybe someone from Ubuntu developers can assign bug #464422 to the right person and increase importance ? Every day since karmic release about 10 identifical bugs are reported about this problem :(
<ubottu> Launchpad bug 464422 in baltix "fail to complete upgrade jaunty > karmic ttf-mscorefonts-installer" [Undecided,New] https://launchpad.net/bugs/464422
<mantiena> This problem appears because ttf-mscorefonts-installer always tries to download fonts from internet servers without asking if user wants to do this and returns an error if there are no access to the fonts download locations
<hdon> hi all. does the libevent-dev package even work at *all*? it seems to contain errors :(
 * hdon wonders if it has been tested
<nxvl> james_w`: ping
<nxvl> james_w`: i'm trying to bzrize a package, but i can't find any documentation in https://wiki.ubuntu.com/DistributedDevelopment/Documentation/
<james_w`> hi nxvl
<nxvl> james_w`: i remember that with svn there was a way to do that from the dsc
<james_w`> nxvl: a new package?
<james_w`> oh
<james_w`> bzr import-dsc
<nxvl> james_w`: yup
<nxvl> james_w`: awesome, will check the manpage for that, thank you
<james_w`> bzr help import-dsc will get you started
<james_w`> also file:///usr/share/doc/bzr-builddeb/user_manual
 * nxvl HUGS james_w` 
<kklimonda> james_w`, will there be a way in future to work completely in VCS? Download upstream source though svn or git, merge with package branch and release ready source package?
<Laney> will need to run autogen.sh or similar
<kklimonda> Laney, i know, i know
<james_w`> kklimonda: yes
<Laney> I once tried to package f-spot based on the git tags, then decided it was too much work
<joaopinto> is /etc/rc.local expected to be called on Karmic boot ?
<_lemsx1_> the lsb-base package on Ubuntu introduces /etc/lsb-base-logging.sh which is supposed to be provided by sysadmins and other packages wanting to change the way init functions are called. this is inconvenient for others
<_lemsx1_> there are 4 new bugs that should be merged with this one LP #328089
<ubottu> Launchpad bug 328089 in splashy "[Jaunty] splashy 0.3.13-3ubuntu1 fresh install conflicts with lsb-base" [High,In progress] https://launchpad.net/bugs/328089
<_lemsx1_> now that karmic is out, i want to get this resolved some how...
<feisar> I know this is officially not the right place to ask for support but the normal channels seem clueless. How do I add a new user with an encrypted home? --encrypt-home does not work in 9.10, it did in 9.04
<bdmurray> pitti: Do you know why apport-kerneloops reports are still coming in about karmic?
<pitti> bdmurray: unfortunatly kerneloops wasn't disabled before release; james_w wanted to look into this AFAIR
<bdmurray> pitti: we are getting lots and lots of these
<james_w> pitti, bdmurray: just uploading to -proposed now
<bdmurray> james_w: is there a bug number so we can get it verified quickly?
<bdmurray> sbeattie: ^
<pitti> james_w: thank you!
<james_w> bug 471137
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/471137)
<zul> so umm I know this has been asked before but is lucid open yet?
<ogra> zul, https://wiki.ubuntu.com/LucidReleaseSchedule
<ogra> give it till end of the week
<zul> ogra: thanks
<jdong> pitti: potential verification-failed on bug 415766; ebroder's latest comment?
<ubottu> Launchpad bug 415766 in openafs "evince makes openafs to kernel oops" [Undecided,Fix committed] https://launchpad.net/bugs/415766
<ebroder> jdong: I'll admit that I have no idea how that interacts with dkms, which you may care about more than module-assistant
<hoonteke> is there a way to mirror an ubuntu via bittorrent?  I don't mean just offering bittorrent, I mean saving some mirror's bandwidth by utilizing bittorrent to download it my private mirror.
<jdong> ebroder: yeah I have no idea either
<ebroder> I guess I could go poke at that for a second
<MsMaco> if it should be -1 not 0.1, jdong made me do it!
<MsMaco> s/-//
<ebroder> No, no - it should definitely 0.1
<ebroder> It's a question of ubuntu0.1 or +ubuntu0.1
<jdong> MsMaco: no, it's the - vs +
<MsMaco> ah ok
<jdong> + is like the professional edition ;-)
<MsMaco> :P
<ebroder> Anyway, I'll poke as soon as I finish dealing with the fallout of bug #430224 for my build servers
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/430224)
<jdong> yay ubottu!
<ebroder> *eyeroll* This is the "initctl in a chroot does the wrong thing" bug
<ScottK> pitti: I was wondering if you could take a look at Bug #466028.  I think it may be a post-update regression (I don't recall seeing the error before).
<jdong> heh has anyone gotten anything amusing to happen as a result of that?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/466028)
<ebroder> jdong: I don't think anything amusing will happen; just annoying errors. Although I can certainly see it causing problems for Debathena's login chroots at some point down the line
<jdong> ebroder: yeah, I'd imagine
<ebroder> jdong: I can't tell for sure, but it looks like dkms tracks modules outside the package manager. If that's true, the version number wouldn't matter if you're using dkms, but it still would if you use the module-assistant
<jdong> ebroder: now that you mention it, yeah, it'd purge the dkms modules and re-build them during postinst
<jdong> not a big deal there
<ebroder> (My perspective is biased, because Debathena is still distributing module-assistant-built modules for everybody)
<jdong> not biased at all; no reason why not to do a 1-character regression correction :)
<lantizia_> I'm very much sufficiently *ISSED off... whose bright idea was it to have GDM restart OVER AND OVER AND OVER if it fails to start X?
<lantizia_> Jesus didn't this thing go under any testing?
<lantizia_> Dependant on name server chosen, network-manager is screwed at name resolution too
<ebroder> lantizia_: I don't know anything about your problem, but a word of advice from the other side: I have very little desire to help someone who starts their bug report by ranting about how incompetent I am
<lantizia_> Then don't brand something as stable just because 6 months have passed
<jdong> that's a very helpful attitude
<lantizia_> No it isn't... but I'm not using a very helpful OS either
<lantizia_> I don't argue that I'm being a cock right now but it's irritated me greatly
<jdong> well sorry to hear that
<jdong> but it's unlikely this approach will yield any productive results
<lantizia_> And #ubuntu is full of people who have silly questions like how to delete a file, or run a windows games... the odd's of having any real dialogue to work through issues is nill
<ScottK> Doesn't make this a support channel
<MsMaco> ebroder++
<mdeslaur> Riddell: I have some qt4-x11 packages for intrepid and jaunty in https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages
<mdeslaur> Riddell: if you want to try them out
<Riddell> mdeslaur: ok, I'll try them in a couple of hours
<mdeslaur> Riddell: cool, thanks
<mdeslaur> Riddell: it's webkit security updates, so anything that uses qt4-webkit
<mdeslaur> Riddell: no rush
<davidroderick> I ran out of disk space and so I started to apt-get remove stuff I found in /var/lib/dkpg/available.  This broke my system in subtle ways.  How should I have found a list of end packages?
<chrisccoulson> siretart` - there?
<davidroderick> I think that I might trash the os and move to gentoo
<siretart> chrisccoulson: yes?
<chrisccoulson> siretart - did you do any work on the screensaver/vlc issue?
<chrisccoulson> i was looking at the totem source earlier, and it contains the same hackery (simulating fake keypresses) as gnome-session for preventing the session from going idle
<siretart> chrisccoulson: nope. I've just digged out the patch from the gnome bugzilla and prepared a ppa package
<RAOF> davidroderick: This isn't really the channel for that question, and it's not entirely obvious what you're trying to ask, but I think "deborphan" is the answer.
<siretart> chrisccoulson: but I've read a bit about xlib. There is this API called XResetScreenSaver. Why can't we use just that API?
<chrisccoulson> siretart - not sure about that
<siretart> btw, how do KDE applications prevent the screensaver from activating?
<chrisccoulson> siretart - i'm not sure about that either. in gnome, applications must prevent the session from going idle somehow. once the session goes idle, gnome-screensaver will display the screensaver after a preset time
<siretart> btw, I found that API from this message: http://lists.freedesktop.org/archives/xdg/2009-May/010461.html while googling around..
<chrisccoulson> siretart - interesting. i'll have to try and figure out what that does on the server-side
<chrisccoulson> basically, we just need a way of resetting the IDLETIME counter
<chrisccoulson> which is reset automatically when you move the mouse / press keys etc
<siretart> hm. the documentation XSetScreenSaver(3) fits perfectly to this description...
<Riddell> siretart: I believe they insert fake key events using libxtest
<chrisccoulson> Riddell - that's also what some gnome apps do as an alternative to using the inhibit interface
 * siretart reads the xlib specification, page 195, section 9.7. Controlling the Screen Saver.
<chrisccoulson> siretart - remember though that gnome-screensaver disables the built-in X screensaver anyway
<chrisccoulson> just to complicate things ;)
<chrisccoulson> it's all very confusing :-/
<siretart> chrisccoulson: it does?! why the heck is this?
<siretart> btw, what *is* the 'built-in X screensaver' anyway?
<chrisccoulson> siretart - the built in X screensaver is all controlled server-side. ie, it takes care of the timeout and screen blanking itself
<chrisccoulson> but gnome-screensaver disables this and takes control of the screen itself
<chrisccoulson> and the screen blanking is handled by gnome-screensaver too
<siretart> hm. I guess I need to do way more research here
<chrisccoulson> at least that's my understanding of it
<siretart> chrisccoulson: you said that one cannot assume that the MIT-SCREEN-SAVER extension is always available. is that correct?
<siretart> do you know of examples when it is not available?
<chrisccoulson> the built-in X screensaver probably doesn't allow a nice fade, and probably provides no way of drawing the unlock dialog too
<siretart> but it defines a documented and fine API for locking/unlocking/inhibiting the screen
<chrisccoulson> siretart - i've no specific examples of when the extention might not be available, but i've had to debug several issues recently where people have made invalid assumptions about the presence of various X server features.
<siretart> wouldn't it be great if g-s-s would just handle these xlib defined notifications just as one would expect it?
<ajmitch> siretart: wouldn't it be great if no software had bugs? :)
<chrisccoulson> and regardless of whether it is available or not, you must always make a call to XScreenSaverQuesryExtension to properly initialize some client-side parameters
<chrisccoulson> else behaviour is unpredictable
<chrisccoulson> it would be great if software had no bugs:)
<chrisccoulson> but then i'd have nothing to do...
<chrisccoulson> ;)
<siretart> ajmitch: sure, but we are not (yet) able to identify the defect exactly
<ajmitch> I know, I was reading through that bug. It's a shame that screensavers are still a complicated field
<chrisccoulson> they are too complicated. i knew nothing about gnome-screensaver until i had to debug a separate issue 3 weeks or so ago
<chrisccoulson> i had to spend several evenings trying to figure out how it worked ;)
<siretart> chrisccoulson: re: XScreenSaverQueryExtension - you're right, this is even documented in XScreenSaver(3)
<chrisccoulson> siretart - this is also the case for any X extension request
<chrisccoulson> i think the call is needed for obtaining the major op code associated with the extension
<siretart> chrisccoulson: ah, I think now I understand the issue. g-s-s has moved away from libxscreensaver (the MIT-SCREEN-SAVER) extension to directly query the IDLETIME sync counters in order to make the fading out effect interruptible
<siretart> is this correct?
<chrisccoulson> siretart - almost. it's actually gnome-session which queries the IDLETIME counter
<chrisccoulson> gnome-screensaver just listens to the session idle status from gnome-session
<siretart> okay, but I assume applications should still be able to use libxscreensaver to reset the IDLETIME counter and thus inhibit g-s-s
<siretart> or even just plain libx11
<chrisccoulson> siretart - the IDLETIME counter is accessible via the SYNC extension
<chrisccoulson> but it is not writable by any clients
<chrisccoulson> that seems to be the issue
<siretart> chrisccoulson: perhaps XResetScreenSaver can be used to reset that counter?
<siretart> or rather: make XResetScreenSaver(3) reset the counter?
<chrisccoulson> siretart - i don't know. perhaps it does that indirectly already?
<siretart> chrisccoulson: what library exposes the SYNC extension?
<siretart> Xext?
<chrisccoulson> siretart - yes, i think that's the one
<siretart> okay, that seems to be documented here: http://www.xfree86.org/current/synclib.pdf
<siretart> chrisccoulson: do we have client programs to query the xsync counters, or do I have to hack something up myself?
<chrisccoulson> siretart - gs-idle-monitor.c in gnome-session has some examples
<chrisccoulson> siretart - that file also contains an example of how to reset the counter
<chrisccoulson> which is copied directly from totem too
<siretart> I'm just reading that file right now
<bluefoxicy>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<bluefoxicy>  4576 bluefox   20   0 1307m 117m  22m R  188  3.2   2696:39 pidgin
<bluefoxicy> htf can pidgin use 200% CPU
<bluefoxicy> to idle
<jdong> hahaha :)
<bluefoxicy> it's been doing this a lot too
<chrisccoulson> bluefoxicy, empathy?
 * chrisccoulson runs
<bluefoxicy> empathy is crap
<chrisccoulson> hmmm
<slangasek> bluefoxicy: not helpful
<siretart>         /* FIXME: is there a better way to reset the IDLETIME? */
<siretart> hrmpf
<chrisccoulson> siretart - that's the bit i referred to in the bug report
<bluefoxicy> FIXME and XXX are awesome
<bluefoxicy> grep at the source code for a while, find these, examine
<bluefoxicy> hack the shit out of everything
<bluefoxicy> wash, rinse, repeat
<chrisccoulson> siretart - it's really not very nice ;)
<bluefoxicy> (FIXMEs occasionally become exploitable bugs)
<siretart> chrisccoulson: hm. synclib.pdf mentions the API Status
<siretart> XSyncSetCounter ( Display * dpy, XSyncCounter counter, XSyncValue value )
<siretart> XSyncSetCounter sets counter to value. It returns False if dpy does not
<siretart> support the SYNC extension; otherwise, it returns True.
<siretart> <endofquote>
<slangasek> chrisccoulson: did my xtrace help? :)
<chrisccoulson> siretart - i tried patching gnome-screensaver to do that already
<chrisccoulson> but Xorg doesn't let you change the value
<directhex> hm
<chrisccoulson> siretart - you just get a BadAccess error, and a crash;)
<chrisccoulson> slangasek - thanks - i've not had time to have a proper look at it yet
<directhex> apparently debian now finally supports source format 3.0 - does ubuntu?
<dtchen> slangasek: I'm beginning to think this grub issue is caused by users' errors. I haven't been able to reproduce the issue, but that doesn't mean very much...
<slangasek> chrisccoulson: no worries
<chrisccoulson> but i suspect it probably will help. i noticed something briefly at the end of the file when i glanced at it eariler, although that might end up being nothing
<slangasek> dtchen: some of them will have been.  But each occurrence should be inspected individually before drawing a broad conclusion.
<slangasek> (FSVO "each")
<slangasek> directhex: no
<directhex> slangasek, so don't upload any 3.0 stuff to debian i want to be syncable?
<slangasek> directhex: for the nonce
<siretart> chrisccoulson: have you seen http://antony.lesuisse.org/software/xorgsync/synctest.c?
<chrisccoulson> slangasek - it looked like the last XRRSetScreenSize call sets the screen size to 1280x800 when there is still an output allocated to a range outside of that new size
<siretart> chrisccoulson: there various xsync API calls are demonstrated. the alarm ones fail for me, though
<chrisccoulson> from the randr documentation: "All active monitors must be configured to display a	subset of the specified size, else a Match error results."
<chrisccoulson> might be nothing though. i need to look in more depth
<slangasek> chrisccoulson: feel free to use me as a sounding board, but I know nothing about the protocol, so can't give you much feedback :)
<slangasek> chrisccoulson: I do think it's odd that it switches the size to 2640x800 and then immediately back down to 1280x800
<chrisccoulson> siretart - i've not had a proper look at that source file, but SYNC does allows clients to set up and manipulate counters. unfortunately though, IDLETIME is a special counter which clients aren't permitted to modify directly
<chrisccoulson> slangasek - the larger size there would probably be normal if you have a second screen located to the right of your main screen
<siretart> i see
<slangasek> chrisccoulson: er, why is it normal for gnome-settings-daemon to not make up its mind on the first go? :)
<chrisccoulson> slangasek - AFAICT, it should pick an existing configuration if the hardware that is attached matches that of a configuration that was stored previously
<chrisccoulson> if the hardware configuration is new, it auto-configures by appending new screens to the right-hand side of existing screens
<chrisccoulson> at least that's how i understand it ;)
<slangasek> chrisccoulson: sure; my question is, why does it issue the command *twice* with two different resolutions, when I only hit the button once?
<slangasek> it's not new hardware
<slangasek> (it has no EDID, so maybe it doesn't know this is the case)
<chrisccoulson> ii'm not too sure without looking at the data in more detail. i don't have 2 screens to test it out, and i don't have the benefit of playing with RANDR either
 * chrisccoulson curses proprietary drivers
<jdong> did keybuk ever make any headway on the mystery sreadahead-is-slow bugs
<jdong> http://bradmisik.com/random/mike-desktop-karmic-20091102-1.png
<ion> Yes. He wrote ureadahead.
<jdong> was just helping someone with this craziness
<jdong> pretty beefy system, sreadahead seems to just thrash
<ion> Itâs available for testing from the ubuntu-boot PPA.
<jdong> *nods*
<gp> hi guys pl help my server has run out of space (ec2 instance ) ......i created a new partition and mapped home folder to it but its now working
<azeem> if it's now working - great!
<gp> # /etc/fstab: static file system information.
<gp> # <file system>                                 <mount point>   <type>  <options>       <dump>  <pass>
<gp> proc                                            /proc           proc    defaults        0       0
<gp> /dev/sda3                                       None            swap    defaults        0       0
<gp> /dev/sda1                                       /               ext3    defaults        0       0
<gp> /dev/sda2                                      /home            ext3    nodev,nosuid    0       2
<jpds> !paste | gp
<gp> not working :-(
<ubottu> gp: For posting multi-line texts into the channel, please use http://paste.ubuntu.com (or !pastebinit for CLI) | For pasting !screenshots use http://tinyurl.com/imagebin Please give us the URLs for your posts!
<gp> sorry
<gp> is fstab is correct here
<gp> ?
<azeem> gp: this is not a support channel, please ask in #ubuntu
<slangasek> or possibly #ubuntu-server, in the case of ec2
<brown`> What should be permissions on /etc/cron.daily/apt be for Karmic?
<brown`> On my my system, installed fresh from alternate CD, they are 644.
<wgrant> brown`: 755 here, installed from the final i386 alternate CD.
<gp> pl in the name of Gaint panda pl help me
<gp> i copied to home folder to /mnt   and then renamed the home folder
<gp> changed "/dev/sda2 /mnt ext3 defaults 0 0"  to "/dev/sda2                                      /home            ext3    nodev,nosuid    0       2"
<gp> but fstab is not mounting it
<brown`> wgrant: Thanks.  I installed from one of the betas and then upgraded to Karmic final.  Update manager is not checking for updates daily.  Is there an easy way to verify permissions and content for all installed packages?
<gp> its national emergency pl help me
<brown`> Second question:  My PC running 9.10 hibernates.  On reboot the root partition is identified as having problems, so the system mounts it read only.  Can applications already running write to files on the root partition.
<wgrant> brown`: You probably want to ask in #ubuntu.
<brown`> wgrant: ok, will do, thanks.  Figured I'd ask here, since it's a kernel question.
#ubuntu-devel 2009-11-03
<gp> its internationa national emergency pl help me
<Pici> gp: This isn't a support channel, please use #ubuntu-server or #ubuntu
<joaopinto> hum, Giant Panda what is that :) ?
<ebroder> Does anybody know if it's possible to get the list of package versions I've uploaded through launchpadlib? (i.e. the equivalent of https://launchpad.net/~broder/+related-software)
<wgrant> ebroder: No.
<ebroder> wgrant: As in it's not possible?
<wgrant> ebroder: That's right. You can list uploads in a particular PPA, but that's about as close as you can get at this time.
<showard> Hello, a regression was reported in LP where a qtiplot (an important science program) was rendered unusable (bug #471238).
<ubottu> Launchpad bug 471238 in qtiplot "Program crashes when doing any plot or fit" [Critical,Triaged] https://launchpad.net/bugs/471238
<showard> I've confirmed the bug, wrote a patch that fixes it, and tested the patch to be working. As per the SRU proceedure on the wiki, I'm posting here to get some attention to it
<showard> thank you!
<jdong> showard: looking at it right now
<jdong> showard: you can feel free to take comment #3 and edit the original description of the bug with that
<jdong> showard: change changelog section from karmic --> karmic-proposed
<LaserJock> showard: well done on that bug report, thanks for looking at that bug
<showard> jdong: thanks, got it targeting karmic-proposed
<showard> jdong: thanks! One last thing, I can't upload - is there anything else I should do (subscribe motu-sponsor?) or is it out of my hands now?
<jdong> showard: you should definietly subscribe universe sponsors
<jdong> I'm unfortunately not in a location where I can sponsor the upload at the moment
<jdong> so if you can "kidnap" a MOTU in a more timely manner
<jdong> I should point out that LaserJock just spoke and even in an manner implying he's interested about the bug ;-)
<LaserJock> :-)
<showard> ha thanks - LaserJock - mind if I take you to the back room and hold you for ransom (or at least sponsoring ;-) )
<ebroder> Hmm...I'm intrigued by this ransom thing. I should try it some time
<ebroder> (And jdong is even in the same room as me right now!)
<jdong> ebroder: haven't you abused that once already tonight??
<ebroder> jdong: Totally quentin's fault, not mine!
<LaserJock> jdong: the previous version is a build1 should the SRU be a ubuntu0.1?
<jdong> LaserJock: it's a corner case I haven't much dealt with before. 0.1 is a bit better, yeah
<bryce> anyone else seeing wiki.ubuntu.com breakage?
<ebroder> Yep
<kklimonda> indeed
<syn-ack> wow
<syn-ack> yeah, its pretty broken, I'd say
<bryce> lost my edits :-(
<ebroder> ==
<LaserJock> showard: btw, yes I'm working on it :-)
<ajmitch> ebroder: so you've not been adversely affected by jdong's madness?
<ebroder> ajmitch: Would I be able to tell?
<ajmitch> true...
<showard> laserjock: thanks - by the way, i'm a laser jock too
<LaserJock> showard: awesome
<dotblank> Well looks like karmic broke suspend/resume.. worked in 9.04 but in .10 it does not work at all
<dotblank> << on the asus n50v
<lifeless> #ubuntu-bugs for bug reports ;)
<billisnice> I find 9.10 sluggish and slow? 9.04 runs great but 9.10 is slow...anyone else notice the slowness?
<dholbach> good morning
<TheMuso`> c
<hyperair> does anyone get sreadahead terminating prematurely during bootup?
<spaetz_> who did the new tux boot screen. dos?
<spaetz_> oops, wrong channel
<amik>  is there a k/ubuntu updates changelog somewhere? where I can see which packages were updated and when?
<wgrant> amik: http://lists.ubuntu.com/listinfo/<RELEASE>-changes (eg. karmic-changes)
<amik> "The requested URL /listinfo/karmic-changes was not found on this server." - or did I mistype something?
<amik> wgrant: http://lists.ubuntu.com/listinfo/karmic-changes gives me a 404, is tha the link?
<dholbach> https://lists.ubuntu.com/karmic-changes should redirect you to the right page
<dholbach> ah, a mailman was missing
<amik> dholbach: translation? :-)
<debfx> amik: http://feeds.ubuntu-nl.org/UbuntuChanges
<amik> thanks debfx
<pitti> Godo morning
<hyperair> TheMuso`: ping (re sdl). could we have libsdl1.2debian depend on libsdl1.2debian-pulseaudio | blah blah instead of libsdl1.2debian-alsa | blah blah?
<hyperair> TheMuso`: the alsa-pulseaudio plugin sucks badly with sdl using apps
<hyperair> mainly due to the -alsa plugin being installed automatically instead of -pulseaudio
<pitti> ScottK: thanks for pointing out!
<pitti> free: please have a look at bug 466028
<ubottu> Launchpad bug 466028 in landscape-client "landscape-sysinfo crashed with ImportError in <module>()" [Critical,New] https://launchpad.net/bugs/466028
 * ogra grins
<ogra> are we re-rolling alternates or why did i just get a message from the iso tracker
<ogra> (to test 20091103)
<pitti> ogra: ara is preparing the tracker for openweek
<ogra> ah !
<ogra> good, so we dont re-release :P
<ara> ogra, if you go to the tracker you will see the message "we are testing the fake open week release" ;-)
<ara> ogra, sorry for the spam
<TheMuso`> hyperair: I have thought about that a bit, but its a sticky situation, since users who want to use SDL may be from kubuntu or xubuntu, both of which don't ship pulseaudio by default.
<hyperair> TheMuso`: how about ubuntu-desktop recommending libsdl1.2debian-pulseaudio then?
<TheMuso`> hyperair: Worth considering, given there is enough disk space.
<hyperair> mmhmm
<TheMuso`> Hrm I just received a tracker mail re new studio isos. Whats going on with that?
<ogra> TheMuso`, openweek fake entries
<TheMuso`> hrm seems cdimage is not updated, so sounds like a false alarm.
<TheMuso`> oh ok
<ogra> seb128, hmm, i just installed epiphany for the first time since years, is it wanted that the toolbar is hidden by default ?
<seb128> ogra, dunno I've not used a stock config for years
<seb128> I guess it is if that's the default
<ogra> looks weird
<ogra> geez, thats so fast !
<pitti> wgrant: you were looking for a new-style source package -- tzdata was converted to quilt format, so we can't sync any more now
<pitti> slangasek: (^ FYI)
<slangasek> doh
<wgrant> pitti: There are quite a few around now, it seems :(
<slangasek> Keybuk: ping
<slangasek> james_w, jml: can you confirm that the lucid bzr branches are a go?
<jml> slangasek, I've had confirmation from james_w and mwhudson. I believe they are go.
<slangasek> w00t
<slangasek> thanks
<fivetwofive> .h
* slangasek changed the topic of #ubuntu-devel to: Ubuntu 9.10 now playing in a theater near you | Archive: open for uploads! | 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
<dholbach> yeeeeeeeeehaw!
<chrisccoulson1> hey dholbach ;)
<dholbach> hiya chrisccoulson1
<chrisccoulson1> ooh, i just saw the announcement :)
<Laney> when is the first autosync run?
<siretart`> err, didn't we used to have some pre-release toolchain updating freeze something?
<chrisccoulson1> siretart` - that's already happened
<chrisccoulson1> i blinked and missed it too ;)
<siretart`> err, so no gcc 4.5 for lucid (yet)?
<joaopinto> hum, the topic is not correct, #ubuntu is not for general discussion :)
<TheMuso`> siretart`: conservative is the word for lucid I think.
<ion> dapper-karmic is a single compound word, dapperâkarmic implies a range. </nitpick> :-P
<Amaranth> *sigh*
<Amaranth> yay people asking for an SRU for a bug with no known fix
<Amaranth> that doesn't even appear to be a real bug
<Riddell> mdeslaur: your qt update seems to be working fine on jaunty i386, I can browse the web no problem in arora
<chrisccoulson1> Amaranth OOI, which bug is this?
<mdeslaur> Riddell: cool. I personally tried the demo browser in qt4-demos and webkitkde.
<Amaranth> chrisccoulson1: bug 150702
<ubottu> Launchpad bug 150702 in metacity "alt shift tab stopped navigating windows" [Medium,Fix released] https://launchpad.net/bugs/150702
<cwillu_at_work> Amaranth, some compiz related goofiness?  that binding has caused me some grief, but I always figured it was just something I did
<Amaranth> cwillu_at_work: I don't know what is happening, that is the point
<Amaranth> People keep saying "this is completely broken, I have to set the binding myself" but on my system the only way I can break it is to manually unset the binding
<cwillu_at_work> Amaranth, so, are you looking for unwarranted guesses as to behaviour that might trigger it?
<Amaranth> something like that
<cwillu_at_work> (I've only ever noticed it when changing switchers from the default to static or ring)
<Amaranth> I even installed jaunty on another computer, screwed with the related settings a bit, then upgraded
<Amaranth> still no bug
<cwillu_at_work> unsurprisingly, I can't duplicate it right now;  I run into it enough times to remember that I've run into it, but ya;
<Amaranth> All of these weird settings bugs keep adding up toward me saying "screw users who want crazy effects" and stripping out almost everything we don't use
<pitti> kirkland: hm:
<pitti> $ kvm -m 512 -cdrom http://mirrors.kernel.org/ubuntu-releases/8.04.3/ubuntu-8.04.3-desktop-amd64.iso
<pitti> CURL: Error opening file: Connection time-out
<pitti> qemu: could not open disk image http://mirrors.kernel.org/ubuntu-releases/8.04.3/ubuntu-8.04.3-desktop-amd64.iso
<kirkland> pitti: pick a closer/faster mirror
<pitti> kirkland: it does seem to try curl, but unsuccessfully?
<kirkland> pitti: any URL to an ISO
<seb128> pitti, you got internet a local speed now? ;-)
<seb128> at
<seb128> no need to download isos
<kirkland> pitti: looks like you just have a slow connection to mirrors.kernel.org
<pitti> ah, nice, that works
<pitti> seb128: just testing an SRU :)
<seb128> ;-)
<kirkland> pitti: this is going to be a very useful way of testing ISOs, going forward :-)
<pitti> well, rsync is still magnitudes faster, I figure
<cjwatson> ion: if you're going to be that picky, actually "dapperâkarmic" is a single compound word; "dapper-karmic" is "could be either a compound word or a range since we're trying to fit this into ASCII, and since you're presumably a somewhat intelligent human being you get to work it out from context". As I'm sure you well know. :-)
<Bsims> I have an issue, I have been bitten by Bug # 425704 affecting my capslock, but does it affect numlock as well?
<Bsims> I have an issue, I have been bitten by Bug # 425704 in console-setup affecting my capslock, but does it affect numlock as well?
* sladen changed the topic of #ubuntu-devel to: Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | 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
<ion> cjwatson: For a pure-ASCII representation of a range, iâd suggest âdapper - karmicâ. :-)
<cjwatson> ion: given the fact that we often run out of topic space, I'm not going to waste bytes
<cjwatson> IRC is a legacy medium in many senses, deal with it :)
<martianixor> hi, this is ubuntu 9.04 x86_64bit on HP Pavilion dv6 laptop, I have multimedia touchkeys one of them "speaker mute" works but had no keycode, I did dumpkeys to find unused one then set a new keycode for it using setkeycode, now I no longer get the errors in dmesg
<martianixor> I wonder what would happen after reboot, the issue is that Its color doesn't change from white to red
<martianixor> while the wireless touchkey does turn to red when pressed to deactivate wireless, how can I change the behavior of speaker mute accordingly?
<martianixor> thanks in advance
<martianixor> am I making sense? any missing info? Oh this is 2.6.28-16-generic
<martianixor> I have a problem with audio, few minutes it was working greatly, then when I stopped mplayer audio stopped functioning, this is Advanced Linux Sound Architecture Driver Version 1.0.21, downloaded gnome-alsamixer and found all sliders up except for pc-beep when I moved it halfway up then unmuted it, found out that when I trigger a beep I get a static like sound instead of beep
<ebroder> martianixor: If you're trying to get something working, use #ubuntu. If you think you've found a bug, use #ubuntu-bug. This isn't the right channel, though
<martianixor> Not sure how to go about troubleshooting this, tried mplayer with all possible devices
<martianixor> ebroder: I'm trying to make sure what the issue is in the first place
<martianixor> ebroder: thanks, sorry if I filled the channel with garbage :-)
<mathiaz> kees: jdstrand: mdeslaur: is there a qa-regression test for avahi?
<jdstrand> mathiaz: yes
<hyperair> anyone free to upload an SRU? LP #248392
<ubottu> Launchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] https://launchpad.net/bugs/248392
<hyperair> causes 64-bit wined3d to segfault, among other things
<mvo> Amaranth: I just got a request from a translator about compiz-config-settings-manager translateion, should I point him to the compiz server? or should we open LP up for translations ?
<Amaranth> mvo: I think upstream translation is kind of stalled
<Amaranth> the guy running pootle or whatever they use to manage it is gone
<Amaranth> Every time a translator comes to ask about it they offer to have them take over running the translation efforts, anyway
<mvo> Amaranth: hm, so maybe the easiest option is to just use LP until pootle is fixed?
<Amaranth> seb128: (moving hear to get it out of the meeting) I know compiz starts a heck of a lot faster when I restart it in an already running session though
<Amaranth> mvo: yeah
<Amaranth> s/hear/here/
<Amaranth> Instead of a couple seconds of the script checking things then compiz starting compiz just starts
<gigabytes> hello
<gigabytes> is anybody here from the Mactel Support Team?
<dpm> Amaranth, mvo, I've just caught the conversation on compiz-config-settings-manager translations and I'm interested. Do you think I should tell Ubuntu translators to rather translate it on LP, then? Or is there any possibility they might want to host translations on LP and we could help them on that?
<mvo> pitti: assuming that python is broken and segfaults, then apport would not be able to capture that, right? bug #467027 looks like that is happening there
<ubottu> Launchpad bug 467027 in update-manager "Upgrade from Jaunty 9.04 to Karmic 9.10 installArchives() failed" [Undecided,Incomplete] https://launchpad.net/bugs/467027
<pitti> mvo: eww, yes; if apport can't run, no core dumps for us :-(
<pitti> mvo: he could try to disable apport, and run a root shell with ulimit -c unlimited and then update-manager
<pitti> to collect a core dump
<bryce> pitti, heya, I don't remember if I mentioned it, but I added some logic to apport-symptom for display bugs
<pitti> bryce: oh, nice!
<lfaraone> Have there been major changes in the way graphics drivers work that would stop a module written for compatibility on Ubuntu 8.04 from running recompliled on 9.10? (it's a proprietary module, but the company might be interested in getting it in partner for the next LTS)
<bryce> pitti, would be nice to get that rolled out in lucid
<pitti> bryce: you didn't upload yet, apparently?
<bryce> pitti, no I assumed you were taking care of the uploads for it
<bryce> actually I'd appreciate your review of the code as well
<pitti> bryce: sure, no problem; I'll do that right away
<pitti> cr3: posted a question to you in bug 465447; quick answer appreciated, for the sake of bryce's mental health :)
<ubottu> Launchpad bug 465447 in checkbox "Disable checkbox from filing bugs against X in released versions of the distro" [Undecided,New] https://launchpad.net/bugs/465447
<cr3> pitti: I'm in the montreal datacenter, so hard to look into things. however, I took a moment to look at the patch and it would need a few tweaks
<cr3> pitti: just the package.name == '' lines should be removed
<debfx> is the kernel supposed to adjust the brightness on fn key press?
<pitti> cr3: ah, so if the dictionary doesn't have a package name, it'll cope?
<pitti> debfx: no, it's not
<pitti> debfx: many keys are hardwired, the hardware itself does it; the other class just sends normal key press events, which are passed through the kernel's input system through X to gnome-power-manager
<riddley> Hi, I'm reading https://launchpad.net/ubuntu/karmic/+source/xorg/1:7.4+3ubuntu7 and I see bryce removed 60x11... and as far as I'm able to discern, that's the only thing that lets my non-root user have xauthority... what am I missing?
<pitti> cr3: thanks for quick review!
<cr3> pitti: yep, there are plenty of tests without a package.name and everything works, so there's precedence for reassurance purposes :)
<riddley> Also, I have a co-worker with the same version of the package (but 32 vs my 64bit) and his package has that file and his system works correctly
<debfx> pitti: if I boot with "nomodeset" the brightness is adjusted automatically otherwise it isn't
<cr3> pitti: this is extreme reviewing, with one foot in a cabinet and the other underneath the floor
<pitti> lol
<pitti> debfx: right, the kernel needs to provide the interface for changing the brightness; this is unfortunately often broken with KMS, there's lots of bug reports about it already
<bryce> riddley, hmm
<cr3> pitti: if you give me a moment, I could create a branch... almost there
<bryce> riddley, you've tested that putting that file in place restores it to working?
<riddley> I just copied it, but wanted to wait for your reply... should I test now?
<riddley> I know that 'xhost' doesn't list me currently
<gigabytes> hello
<riddley> is there something else that should add it?
<gigabytes> which component should be responsible to handle keyboard backlight? gnome-power-manager, right?
<riddley> bryce, I looked all through gdm/x11/pam and couldn't find anything that replicated that functionality
<bryce> riddley, did your co-worker add the 60x11-common_localhost manually?  it should not have gone out in any updates
<riddley> bryce, but I'm not an expert...
<riddley> bryce, dpkg -L x11-common on his machine lists it as the last file in the package. One diff: he upgraded, I installed fresh.
<gigabytes> anybody knows?
<riddley> bryce, how should it work?
<riddley> if that file is errant
<bryce> riddley, and both you and him are on the same version of xorg?
<bryce> xorg (1:7.4+3ubuntu7)
<riddley> bryce, we have the same version of the package, I'm 64bit and he's 32.
<bryce> 64 vs. 32 won't matter
<riddley> we both have the version you listed
<riddley> he upgraded, I installed fresh
<riddley> but let's say you were correct in removing the file... how should it work?
<riddley> what should add me to xhost?
<debfx> pitti: strange thing is with nomodeset the brightness key press is sent twice
<riddley> bryce, w/o that file are you able to open a terminal and run xclock or even xhost itself?
<bryce> yes I can, but standby I think I see the problem
<riddley> groovy
<cr3> bryce and pitti: I have reviewed your changes, merged into trunk and submitted for review for inclusion in karmic. for more details, see bug #473185.
<ubottu> Launchpad bug 473185 in checkbox "Candidate revision checkbox_0.8.6" [Undecided,New] https://launchpad.net/bugs/473185
 * cr3 heads out of the datacenter
<pitti> bryce: you defined a function problem_boot_fail() but aren't actually using it anywhere; is that intended? (i. e. code for future improvements?)
<pitti> bryce: (btw, please pull; I did two trivial fixes)
<bryce> ah yes that is future code
 * pitti commits another trivial fix
<bryce> pitti, I actually wrote up a much bigger amount of code to cover a wider range of symptoms, but decided to pare it down to just a few symptoms and add things more incrementally
<bryce> probably I just forgot to remove that one, but yeah it's something planned for the future
<bryce> boot failure is a common symptom but diagnosing it properly will probably need more sophisticated logic than I'd implemented
 * riddley is still standing by...
<pitti> bryce: no problem to keep it there
<bryce> riddley, right see bug 276357
<ubottu> Launchpad bug 276357 in xorg "disable xauth for local users" [High,In progress] https://launchpad.net/bugs/276357
<bryce> riddley, actually I'm updating the description, give me a few more minutes and it will be more informative
<riddley> so as a temp solution I can grab his file and be g2g?
<pitti> bryce: seems to work nicely; it's intended to file all of them against xorg? or is that just preliminary?
<bryce> pitti, yes that is intended
<pitti> bryce: e. g. would it make sense to detect the driver, map it to a package, and file it against that
<pitti> ?
<bryce> pitti, eventually I'll implement logic to file against the appropriate video driver, but it will take additional logic... some bugs will need to go to mesa, others to xserver, others to kernel
<bryce> currently I have a separate script which processes bugs filed against xorg and moves them to the right package, so by having the symptoms script file to xorg, it'll take advantage of that
<bryce> pitti, fwiw in the "future code" I mentioned, I do have driver detection logic, but I realized it actually is not quite as simple as it seemed at first blush, there's several corner cases that need attended to
<pitti> bryce: so, want me to upload the current one? looks fine to me
<bryce> pitti, sure please do
<bryce> pitti, btw do you have any stats on how many people have been using apport-symptom so far?
<pitti> I don't, sorry
<pitti> bryce: I just noticed that a lot of the devicekit-disks bugs now originate from the storage symptom
<pitti> so it does get used
<pitti> and for hotplug failures it's immensely valuable
<bryce> kewl
<riddley> bryce, how should I fix my xhost problem short-term?
<bryce> at first I thought the checkbox bugs were all coming from apport-symptom, but wasn't the case
<pitti> bryce: thanks for this; now the symptom list isn't so empty any more :)
<bryce> riddley, just copy that 60x11-common_localhost file from your friend
<riddley> great thanks
<bryce> I'll also upload a copy to the bug report in case anyone else needs it
<akgraner> marjo, ara 's session on ISO tracking Rocks!!!  Thanks ara!!!
<bryce> pitti, SRU for bug #276357 mentioned by riddley above is ready for review
<ubottu> Launchpad bug 276357 in xorg "disable xauth for local users" [High,In progress] https://launchpad.net/bugs/276357
<bryce> bbiab (food)
<marjo> akgraner: glad to hear it
<pitti> bryce: ok; I'm reviewing SRUs twice a day nowadays, so I'll get to it tomorrow morning; is that enough, or is it really urgent?
<mathiaz> kees: is there a page about SELinux in Ubuntu Karmic ( Mathias Gug
<mathiaz> Ubuntu Developer  http://www.ubuntu.com
<mathiaz> kees: meh
<mathiaz> kees: https://help.ubuntu.com/community/SELinux?
<kees> mathiaz: yup, that's the best there is or wiki.ubuntu.com/SELinux
<mathiaz> kees: tank ya weray moutche!
<kees> hehe
<jcastro> can someone moderate my UDS mail to -devel please, message needs to get quickly.
<pitti> jcastro: you mean u-d-a@?
<jcastro> -devel will be fine I think
<pitti> ah, can't do that, sorry
<jcastro> thanks for trying!
<jpds> jcastro: evand1 should be able to push it through.
<pitti> Keybuk: FYI, if you plan to update lucid's udev soon, can you please warn me before? udev and consolekit need to be updated in lockstep (new udev needs CK 0.4, which doesn't work with current udev)
<nxvl> Keybuk: any idea why iptraf and iputils (build1) are showing in mom?
<pitti> nxvl: mom doesn't know about the XbuildN case
<nxvl> pitti: ooohhh
<nxvl> thnx
<mathiaz> kees: there is a thread on the sssd-devel mailing about building sssd with selinux - https://fedorahosted.org/pipermail/sssd-devel/2009-November/001232.html
<mathiaz> kees: the question is whether the administration tools could be linked against selinux and still be used in the default Ubuntu install
<kees> mathiaz: not sure what sssd is, but Ubuntu has modern SELinux tools.  it should all Just Work for the most part
<mathiaz> kees: is there a way to perform runtime SELinux detection?
<mathiaz> kees: https://fedorahosted.org/pipermail/sssd-devel/2009-November/001236.html
<mathiaz> kees: This^^ is upstream last reply
<kees> mathiaz: yes, libselinux provides that ability.  there is no harm linking against libselinux (it's in main, lots of stuff links, etc)
<mathiaz> kees: Can I CC you on my reply?
<kees> mathiaz: sure
<cjwatson> pitti: Keybuk's on holiday this week
<pitti> cjwatson: ah, thanks (much deserved)
<pitti> I wonder why he left IRC running
<smoser> https://launchpad.net/~smoser/+archive/ppa/+build/1318926 says "Start 2009-11-05 (2505)" is that right ? is that expected to "start" building in 2 days ?
<Keybuk> because I use IRC for talking to friends as well as for work ;-)
<cjwatson> jcastro: moderated
<jdong> Keybuk: that doesn't suck you right back into work while vacationing?
<jcastro> cjwatson, thanks!
<TheMuso`> /c/c
<Keybuk> jdong: no ;)
<jdong> lol, your self-control is clearly superior!
<Keybuk> jdong: I'm on sofa watching DS9's "O'Brien must suffer" episode from the 6th season :p
<jdong> Keybuk: so if I asked why my bootup is thrashing... *ducks*
<Keybuk> jdong: then I would cheerfully ignore you <g>
<jdong> :) good man! Enjoy your vacation!
<MsMaco> Keybuk: if you're on vacation, why are you on irc? (people always ask me this when i'm on vacation and ive yet to come up with a decent answer)
<Keybuk> MsMaco: ah, I believe we've reached the middle of this conversation
<jdong> Keybuk: wait if you're on vacation.... why doesn't MsMaco have an IRC bouncer?
<jdong> haha ok no more clowning around
<jdong> back to homework!
<ebroder> Ugh. Don't say that - it just reminds me that I should be working on homework too
<MsMaco> *confused*
<jdong> ebroder: haha. I catch myself doing this instead of homework way too often ;-)
<jdong> *heads over to W20 reading room....*
<MsMaco> ubuntu is waaaaaaayyyyyyyy better than homework
<jdong> MsMaco: but it doesn't help in passing classes
<MsMaco> unfortunately :(
<Keybuk> passing classes is overrated
<Keybuk> I failed all of mine
<Keybuk> then never went to university
<cjwatson> not that I would necessarily recommend this approach to impressionable youngsters ... but getting involved with free software in my third year was a lot more useful to my career than the classes I missed due to being up all night hacking
<MsMaco> :)
<MsMaco> im pretty sure id be a MUCH worse programmer if the only code i ever wrote was my homework
<ebroder> Ha!
<pitti> Keybuk, cjwatson: http://xkcd.com/519/ ? :-)
<pitti> ebroder: ^ I meant
<MsMaco> meanwhile today one of my classmates realized (as i was chatting with the OS prof about filesystems) that "wait...you do this *outside* of class too?? WHY?"
<sebner> pitti: perl?? Oh my .. ;-P
<mathiaz> pitti: wait - are you also suggesting that in your *own* experience classes are overrated?
<pitti> mathiaz: nah, I just remembered that xkcd comic :)
<MsMaco> haha just wait til dt ch en notices this conversation. he's always getting on me to do my homework
<TheMuso`> cjwatson: I was in a somewhat similar position, although free software only partially helped in only one module of the music degree I was completing. :)
<pitti> actually, my university time/classes haven't helped me at all career-wise
<pitti> but they certainly did for learning how to quickly get into technical things, doing political work, learning how our world works (in a scientific sense), and generally having lots of fun, too
<pitti> I'd do it again if I had the choice
<sebner> pitti: no wonder .. isn't it that 90% all for university time is not useful for realworld jobs? Anyways, you need the diplom
<pitti> sebner: right, but that's not the point of an uni in the first place, so that's okay IMHO
<MsMaco> pitti: fun? there was fun in your classes? i feel gyped!
<sebner> heh
<pitti> MsMaco: well, more of it outside, but yes, discussing scientific things can be fun, too
<ebroder> I get a lot out of a very small number of classes I've taken here. And almost nothing out of most of them. But I think I'd have a hard time doing some of the cool stuff I can do here outside of my classes if I didn't go to school
<pitti> for my own very personal definition anyway :)
<MsMaco> i keep starting out classes hating them and thinking their useless then at the end going "OH! so THAT's how that works! COOL!!!"
<MsMaco> s/their/they're/
<pitti> also, I really enjoyed maths at uni, to understand how algebra/arithmetics REALLY work
 * MsMaco shudders
<MsMaco> i hate math
<pitti> sure, I don't need to be able to proof that 2+2=4 for Ubuntu work, but I find it interesting anyway :)
 * TheMuso has never enjoyed maths, however I do accept its a necessary part of life. If I need to do any mathamatics for computre related stuff and I don't really know it, I will learn it.
 * Keybuk likes math
<MsMaco> im just pretty resolved to the fact that i'll never write a physics engine. thus, dont need math :)
 * pitti goes back to fixing those #*($#($ LVM udev rules and just notices that this is not in anyway less complicated than maths..
<Keybuk> pitti: LVM is closer to dark magic than math
<MsMaco> oh you uk/au people are going to try to make me start pluralizing "math" arent you?
<ebroder> Yes, and then we're going to start talking about ceiling cat :-P
<ebroder> (Oh wait - "maths" is a commonwealth thing? I didn't realize that)
<slangasek> mathi
<pitti> MsMaco: hm, AFAIR that's how I learned it at school; so "I like math" is actually correct?
<MsMaco> pitti: in the US, "math" is the common way
<slangasek> pitti: it's correct in the US, and incorrect in England :)
<MsMaco> im in the US
<cjwatson> pitti: xkcd> yes :)
<Keybuk> slangasek: maths is incorrect in any country
<pitti> I think they taught me British English, although nowadays I speak a wild mixture of US/GB/Denglish
<slangasek> heh
<Keybuk> if it's an abbreviation for mathematics, it should be MATH'S :p
<MsMaco> Denglish???
<slangasek> Keybuk: are you a grocer
<james_w> it's easy, just remember that it is the opposite of the usual use of sport/sports
<MsMaco> i assume D = Deutsch?
<pitti> MsMaco: "Deutsch/English" wild mix (our way to say that in Germany)
<Keybuk> slangasek: the apostrophe indicates missing letters
<sebner> pitti: school english is Oxford English in D/AUT :)
<Keybuk> since you can't have one mathematic, the "s" isn't pluralising, so if you keep the "s" but miss out the "ematic" - you need the apostrophe because you missed them out <g>
<MsMaco> pitti: given that one derives from the other, i cant imagine it looks *that* screwed up to mix them. i mean, "address"/"adress" one looks like a typo of the other
<pitti> sebner: yeah, but that was 11 years and umphteen conferences ago :)
<sebner> Keybuk: you are a smart one :D btw, thx for your cool mail help =)
<slangasek> Keybuk: maybe you can't have one mathematic, but let me show you my new counting theor
<slangasek> y
<Keybuk> slangasek: you should me yours, I'll show you mine
<sebner> pitti: heh, wondering why they still stick to oxford one. It's not really spoken, sounds snobistig (Denglisch!1!1!1!) I've heard
<pitti> slangasek: oh, you replaced the Peano axioms by the Langasek axioms?
<slangasek> pitti: and let me tell you, they're AWESOME
<sebner> pitti: uhuhu, just learned about the Peano axioms 2 weeks ago :D
<pitti> slangasek: can't wait to see them!
<mathiaz> slangasek: like: 9.10 + 1 = 10.04?
<pitti> sebner: ah, so you can prove commutativity of + now? isn't it great? :-)
<pitti> (and so absolutely useless, too..)
<sebner> pitti: heh, don't worry, we've already passed the complex numbers :D
<pitti> slangasek: I bet it's like "10 bugs (reported) - 1 bug (fixed) == 15 bugs (reported)"
<MsMaco> sounds about right
 * pitti wonders how to fix the lvm2 rules without becoming TIL and having to merge the package
<MsMaco> TIL?
<pitti> "touched it last"
<MsMaco> oh
<pitti> TIL -> poor soul who has to do the merge
<geser> pitti: factorise a RSA key, so you can fake a signature and let somebody else become TIL
<pitti> geser: heh, speaking of math(s?)..
<Keybuk> pitti: you can add fake people to ubuntu-core-dev, upload, then delete them ;)
<pitti> in all seriousness, a merge is long overdue, but I'm afraid of breaking kees' setup if I did
<ajmitch> surely there's some poor sucker who understands it?
<pitti> and if I do, he'd upload his frozen-bubble hack and I can never ever win again
<MsMaco> "if $user == pitti ; lose();" ??
<MsMaco> ummm s/;//
<pitti> MsMaco: no, he added a key which sends a penalty bubble to the opponent
<MsMaco> mangle that mentally into non-stupid syntax
<pitti> and then he kept banging on that
<MsMaco> wait you can play frozen bubble as multi-player?
<geser> sure, you didn't know?
<pitti> MsMaco: ...
<MsMaco> no! i always play it just-me, like Snood
<pitti> MsMaco: if you want to stay productive: No, you can't :)
<MsMaco> apparently i need to play games more often than once every...year
<pitti> but beware, it's brutal
<sebner> pitti: aren't we pre-alpha so breaking is not allowed but welcomed? ;D
<pitti> my wife is always close to killing me :)
 * sebner is wondering if there will be a ubuntu-dev nexuiz challange *cough cough*
<geser> sebner: propose a gaming session for the next UDS to find out which game stops productivity most :)
<MsMaco> geser: wouldnt the most productivity-stopping game then be the most productive game in that situation/
<apachelogger> jcastro: btw, I think it would make sense to CC kubuntu-devel in the next spring registration mail, to make sure them poor blue headed stepchilds actually see it ;)
<sebner> geser: nahh, this is "deep investigation to find and eliminate bugs in the universe" :P :P :P
<MsMaco> apachelogger: spring registration email?
<jcastro> apachelogger, sure!
<sebner> hihu apachelogger :D
 * sebner knuddelt apachelogger 
<apachelogger> s/spring/sprint
<apachelogger> jcastro: thx :)
<apachelogger> yo sebner
<bryce> MsMaco, all springs and pulleys need to be properly registered in order to get things lifted into place properly
<Keybuk> pitti: I was just thinking
<Keybuk> if you created a GPG key with Kees Cook as the name
<Keybuk> signed it with your key, then added it to LP
<Keybuk> then set Changed-By to Kees Cook too
<Keybuk> and uploaded
<MsMaco> you're evil
<Keybuk> would anyone know the difference? :p
<Keybuk> MoM certainly wouldn't
<slangasek> heh
<pitti> Keybuk: well, in terms of MoM it would be enough to just set it in the changelog
<pitti> (I'd still count as sponsor, of course)
<Keybuk> pitti: MoM also records the GPG signature name and shows that
<wgrant> LP is fortunately smarter than that, and would email out the signer's LP name and email address, and also link to their profile page.
<ajmitch> if he's going to that much trouble, he may as well bribe a LOSA to avoid any unnecessary mail about it
 * sebner sees a lot of dark energy waving through this channel :P
 * kees reads backscroll to see how he's being trolled
<wgrant> ajmitch: Well, you don't need a LOSA for that if you know what you're doing.
<sebner> oh noez! Hide everybody .. kees is here!
<kees> heh
 * apachelogger blinks
<kees> Keybuk: heh, yay all merges are assigned to me!  ;)
<bryce> kees, ok thanks
<kees> bryce: noooo
<ajmitch> kees: you're a hero
<slangasek> kees: it's ok, I'll do some merges for you and you can owe me beer
<kees> well, as Keybuk demonstrated, I'll only take the merges where I have been impersonated in MoM.  ;)
 * kees is waiting for the first round of auto-sync to happen before diving into MoM
 * slangasek is waiting for confirmation that the LP tool is grabbing testing by default before doing the first round of auto-sync
<geser> slangasek: why do I get the feeling that the syncing from testing is so badly prepared when the decision was already made during the last UDS?
<wgrant> slangasek: Do you know if it has been verified how the autosyncer will deal with v3 sources while they are unsupported?
<slangasek> geser: I don't know, but the launchpad unstable->testing change is scheduled to land today
<slangasek> wgrant: I don't believe it has
<slangasek> wgrant: we can provisionally blacklist as necessary to work around any problems, though
<wgrant> The testing default change has landed.
 * wgrant tries to sync v3 packages with a non-v3-supporting LP.
<slangasek> wgrant: landed, but not rolled out on prod
<wgrant> Right.
<ajmitch> wgrant: hoping that it doesn't cause the whole sync to grind to a halt?
<wgrant> ajmitch: We'll see soon.
<Bsims> I have been bitten by Bug #425704 in console-setup... can this bug also affect numlock led?
<ubottu> Launchpad bug 425704 in console-setup "[karmic server] Capslock don't turn on LED" [Low,Triaged] https://launchpad.net/bugs/425704
<cjwatson> Bsims: it shouldn't affect numlock, and doesn't for me
<functionofxy> does anyone know about e4defrag implementation in karmic?
<cjwatson> nor scroll lock
<Bsims> cjwatson: wierd, it affects all three for me
<Bsims> cjwatson: It could be the keyboard led burned out but the timing is very odd if thats the case
<jdstrand> mdeslaur: fyi, apparmor_2.3.1+1403-0ubuntu27.1 uploaded with your and my SRU updates
<cjwatson> Bsims: then you have a different bug, not 425704, as far as I can see
<Bsims> cjwatson: Ok, any clue as to what package I should file the bug against? Kernel, or console setup
<cjwatson> I'd start with the kernel
<Keybuk> slangasek: ok, I give up
<Bsims> cjwatson: Ok, its just that apport takes eons to run...
<Keybuk> I've been googling for the past fifteen minutes
<Keybuk> and I cannot find *any* documentation for the new dpkg source format
<wgrant> Keybuk: The dpkg-source manpage is helpful
<wgrant> But it's not wonderful.
<mdeslaur> jdstrand: cool! thanks
<functionofxy> any ext4 or e4defrag experts around? I'm looking for documentation on the defrag implementation.
<slangasek> Keybuk: don't look at me, I've not been following v3 at all
<Bsims> cjwatson: thanks for the heads up...
 * Bsims grumbles a note that system bell is now blacklisted would have saved me a few days of googlemancy
<slangasek> Keybuk: is bug #453579 still reproducible for you after your hardware shuffle?
<ubottu> Launchpad bug 453579 in ubuntu-release-notes "corruption of large files reported with linux 2.6.31-14.46 on ext4" [Undecided,Fix released] https://launchpad.net/bugs/453579
<Keybuk> slangasek: ask me when I'm at work ;)
<slangasek> meh
<Bsims> cjwatson: how long does it usually take apport-bug to finish doing its thing so I can file the bug?
<slangasek> well, in the meantime the bug report is a magnet for all kinds of random followups
<Keybuk> slangasek: I haven't *used* a computer hard enough since thursday to tell
<slangasek> heh
<slangasek> I thought you were hardware swapping prior to that :)
<cjwatson> Bsims: dunno
<Bsims> cjwatson: heh I'd have thought I'd get something after 5 minutes
<cjwatson> sorry, I don't know
<Bsims> cjwatson: it starts a gui doesn't it... or it did when ran under X... I'm in a ssh tunnel
 * Bsims grins
<wgrant> slangasek: An autosync will crash immediately if it attempts to process a v3 package. The fix for that crash is simple, and would result in the syncs just being rejected later instead, but it's probably too late :(
<wgrant> So you'll need to watch and blacklits.
<slangasek> wgrant: understood, thanks for checking.  I don't expect any of these packages to be in testing by the time we do the first autosync, anyway
<wgrant> slangasek: True.
<slangasek> Keybuk: heh, is MoM still generating a changelog that says "merge from debian unstable"?
<Keybuk> any merge generated before thursday will have that
<Keybuk> and will be from unstable
<Keybuk> only new merges will be from testing
<slangasek> ok
<slangasek> don't suppose the capitalization of "Debian" is fixed? :)
<Keybuk> no
<Keybuk> though I think it's screwed anyway
<Keybuk> MoM can't process v3 source packages :p
<Keybuk> have disabled it and locked it out, since it's not doing any good
<Keybuk> will look into it at UDS I guess
<Keybuk> (if someone else wants to fix it in the meantime ...)
#ubuntu-devel 2009-11-04
<wgrant> lamont: Around to talk a bit about fairly important buildd changes?
<spm> wgrant: fyi. he may answer anyway; but he eod' about 90 mins ago.
<wgrant> spm: Oops, I thought it was closer than that, but I forget that DST switched off a few days ago.
<lamont> wgrant: heading out to dinner with my sister - catch me tomorrow PST work hours?
<wgrant> lamont: OK, I'll try to catch you late in that interval.
<lamont> sounds good - when do you come online?  (UTC fine)
<wgrant> lamont: I'm +11 at the moment, and am normally around from about 2100 UTC.
<lamont> so yeah - I'm generally wrapping things up and getting ready to run by 2200-2300UTC
<wgrant> Right.
<lamont> and this week, I'm -8, and trying to be done by 3PM local --> 2300... so not too bad
<exewmt> Just watched karmic boot cd fry a monitor
<exewmt> On first boot, i386
<hyperair> fry a monitor?
<hyperair> that's pretty interesting. i wanna see too
<exewmt> Yep, booted until modesetting for 2nd splash
<exewmt> Flashing light now
<exewmt> Can't even display post
<exewmt> Dead
<hyperair> do you smell anything? =p
<exewmt> Not my pc either, after installing ubuntu for people for 4 years, I get to buy a monitor
<exewmt> No
<exewmt> No burning, nothing of the sort
<hyperair> heh
<hyperair> well, if it can burn from improper settings, it sure as hell has to be very old =p
<hyperair> about time, i'd say
<wgrant> I think that monitor is disobeying some fairly important common sense.
<hyperair> i agree
<exewmt> Yeah, Dell 15" , veery common
<exewmt> Scary how common actually
<exewmt> For legacy desktop stuff
<exewmt> About time? It's now on me to replace it, way to go
<exewmt> Just figured I'd tell you, but I guess it's just on everyone to upgrade
<jcastro> ScottK, around?
<exewmt> I really hope that isn't the stance shuttlesworth wants .com take
<ScottK> jcastro: Yep
<jcastro> ScottK, pretend I want to run -proposed to be a good citizen so I can find bugs before they hit -updates
<MsMaco> exewmt: this isnt where bugs get reported
<ScottK> exewmt: I think it's worth a bug report, although I think it's unlikely it's anything other than coincidental.
<exewmt> There should be a big red banner until that gets fixed though, because Dell has sold millions of these models in the us
<jcastro> ScottK, is there a bug list or tag I can follow?
<ScottK> jcastro: There is.  Let me find it.
<MsMaco> "warning: using the wrong mode is bad for screens"?
<LaserJock> jcastro: ;-)
<exewmt> Scott: I watched it, it booted to splash
<ScottK> jcastro: Did the OpenWeek PDF get fixed.
<jcastro> I don't think it did
<exewmt> MsMaco: It's Automaticc
<wgrant> MsMaco: The thing is, it hasn't been bad for them for like 15 years.
<MsMaco> wgrant: wow
<ScottK> exewmt: I'm not saying it didn't fry when you booted it, I'm just saying I think it's unlikely it was caused by a bug.
<jcastro> ScottK, I can check it now
<ScottK> I still think it's worth filing, just in case.
<exewmt> ScottK: Thing is.... It won't even go to amber led
<ScottK> exewmt: I don't doubt it died.
<exewmt> Now just the same flashing green that first occurred when mode changes to grey screen w bar in boot seuence
<exewmt> like, right when the mode changes to 2nd booting splash
<ScottK> jcastro: http://people.canonical.com/~ubuntu-archive/pending-sru.html - I don't recommed 'running proposed' however.  I recommend enabling it, installing just the package you want to test, and then disabling it.
<exewmt> That is why I don't think it was purely coincidence
<exewmt> I have a few more, should I fry another!
<exewmt> ? (sorry touchtyping$
<wgrant> Oh, right, I forget about the DIEMONITORDIE command that xsplash sends on startup.
<serialorder> is debootstrap ready so i can set up a chroot for Lucid? I was looking at it and noticed its the same one as used in Karmic
<exewmt> wgrant: Just saying that between every other ver of xsplash used
<exewmt> Maybe t's a bug affecting the ver bundled in the cd
<ScottK> exewmt: What's in the CD and in the archive is the same.
<ScottK> serialorder: I think they added lucid to the karmic one before release.
<jcastro> ScottK, I've always just thought we're supposed to run -proposed and report bugs.
<exewmt> k, But should I test w an identical monitor and see if it bricks it?
<ScottK> exewmt: Your call.  If it did, it would be pretty conclusive.  I think it's unlikely to.
<ScottK> jcastro: I know people do that, but I don't recommend it nor do it myself.  The point is that we put stuff in proposed to test it and it doesn't always work out well.
<wgrant> jcastro: That can cause problems when something is copied from -proposed to -updates, and all the testers use -proposed in its entirety. It could be broken with versions in -updates.
<exewmt> ScottK: We have a running bet then
<exewmt> I'll be back tomorrow to report
<wgrant> So it's important to get people to test each -proposed package with everything else in -updates.
<ScottK> jcastro: I've personally seen more problems with running -proposed than with -backports.
<ajmitch> ScottK: that doesn't sound positive
<MsMaco> i usually run with proposed enabled
<ScottK> ajmitch: Thus my recommendation.
<jcastro> wow
<ScottK> I've also almost never seen a problem with backports.
<hyperair> has anyone noticed any issue with the recent udev SRU?
<MsMaco> ScottK: i can think of one problem with backports :P
<ajmitch> I hadn't noticed there was a udev SRU
<ScottK> I remember that one.
<jcastro> ScottK, I only noticed this problem now when LaserJock told me his empathy was crashing and I asked him to enable -proposed and he was wary of enabling the whole thing
<serialorder> ScottK, thanks
<jcastro> ScottK, has someone talked about this with like pitti or something?
<ScottK> jcastro: It gets discussed every now and then.
<MsMaco> well the point of proposed is to catch bugs...
<LaserJock> it seems like we had some threads about this like a year ago
<ScottK> So far the "If we have people enable everything, we get more testers" has won the day.
<ScottK> LaserJock: We did.
<LaserJock> something about when the desktop team was thinking of having a staging PPA or something
<LaserJock> for me a lot of the -proposed vs -backports issue stems from a lot of -proposed packages being pretty core things
<LaserJock> I don't often get a whole new kernel, Xorg, evolution, etc. from -backports
<LaserJock> :-)
<jcastro> well, backports are new upstream releases
<LaserJock> yep, but in my experience new upstream releases of low-risk packages
<ScottK> Or when we do backport risky stuff, we do actually test it a lot before putting it in.
<ScottK> Backports is often more tested than Proposed, but generally less tested than Updates.
<jcastro> proposed is supposed to be the staging area for updates afaik
<wgrant> Right.
<wgrant> And sometimes stuff gets in there with very, very little testing.
<wgrant> Which is why very few people should run -proposed.
<LaserJock> right, there's no real check on what goes in to -proposed other than pitti's quick check
<jcastro> do you have examples of little tested things that hit proposed?
<wgrant> I sense that this is turning into that ML thread.
<MsMaco> i thought the point of proposed was to do testing
<ScottK> jcastro: We had a bad svn regression in -proposed that I recall.
<MsMaco> i mean, the uploader should test yeah, but...if it was perfectly tested before upload, we wouldnt need proposed
<jcastro> MsMaco, yeah but in some cases (like hardware stuff) there's only some testing an uploader can do
 * ScottK recalls a MOTU who was unaware udpates should be tested before uploading to proposed.
<ScottK> I asked him how to test the fix and the response I got was, "I don't know".
<jdong> b/i/r in pre... oh wait wrong process
<MsMaco> jcastro: right so...proposed is for testing...
<MsMaco> im confused by whats surprising about that
<ScottK> Which is why you should just install stuff from it you plan to test, IMO.
<MsMaco> ok i should just shush since im obviously the weird one in this bunch
<jcastro> I don't think it's weird
<MsMaco> if i run stable, its with proposed enabled. though i rarely run stable.
<MsMaco> "production" system or not
<MsMaco> (read "production" as "the only computer i have")
<jdong> well IMO if you install a package from -proposed, it should be to contribute to the verification process
<ScottK> The theory last time we went around on this was more peole just running proposed would increase the odds of catching an odd regression.
<MsMaco> there were a few odd evolution regressions on hardy-proposed, i remember
<johanbr> it worked the way it was supposed to? :)
<wgrant> pitti: You might want to copy jaunty-updates' tzdata to karmic-updates and lucid. We're seeing a few people confused by bug #467165.
<ubottu> Launchpad bug 467165 in tzdata "karmic version is lower then jaunty-updates" [Undecided,New] https://launchpad.net/bugs/467165
<dholbach> good morning
<ebroder> Hmm...am I supposed to be poking somebody to get lilo-installer accepted into hardy-proposed?
<stooj> Morning Daniel
<dholbach> hi stooj
<stooj> I feel sorry for you - 9.10 is awesome, and you have to move straight on to Lucid already!
<wgrant> But Slashdot and The Register say that 9.10 sucks. They must be right.
<stooj> Grr @ elReg: "60% of people hate Karmic in a poll on ubuntuforums" == News
<wgrant> Yup.
<dholbach> stooj: karmic development slowed down a lot in the last weeks, so some of us got a bit of a break :)
<stooj> Glad to hear it
<stooj> Going home - later all
<highvoltage> well they say there's no such thing as bad publicity
<user_> hi guys.. i'm manipulating init scripts on my machine - I want service 1 to be stopped only AFTER service 2 is stopped. Do I use "Should-Stop 2" for this ?
<primes2h> apw: Hello, any news about this bug #446146?
<ubottu> Launchpad bug 446146 in linux "Several Huawei USB dongle don't work with kernel 2.6.31-12.40" [Medium,Fix committed] https://launchpad.net/bugs/446146
<jsgotangco> hello sabdfl
<apw> primes2h, the fix for that is committed and will be rolled out in the first kernel SRU which is expected pretty soon.  likely thursday currently
<pitti> Good morning
<pitti> wgrant: ah, because of the +repack thing
<pitti> wgrant: yeah, will do; thanks
<wgrant> pitti: Thanks.
<pitti> wgrant: ah, no, can't do; the packaging changed slightly, and it would be a regression to move the jaunty one to karmic
<pitti> wgrant: what I'll do instead is to update the entire squad to 2009q, which was just released
<wgrant> pitti: Even better.
<primes2h> apw: Oh, that's nice. At least users would stop changing status to "fix released" on their own. ;)
<slangasek> pitti: you marked bug #441638 as assigned to you; still working on it?  it seems there are a fair number of users for whom having bulletproof-X available would be a particular help right after upgrade
<ubottu> Launchpad bug 441638 in gdm "upstart job keeps restarting a dying gdm" [High,In progress] https://launchpad.net/bugs/441638
<pitti> it's still on my list; although I didn't really intend to implement bulletproof X, just to stop the eternal auto-respawning
<pitti> but if someone else wants to beat me to it, be my guest, of course :)
<slangasek> pitti: ah - then per https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/441638/comments/20, I'll take it if you won't
<ubottu> Ubuntu bug 441638 in gdm "upstart job keeps restarting a dying gdm" [High,In progress]
<pitti> oh, thank you
<slangasek> siretart: hum, your cryptsetup apport hook change makes the package ftbfs in bzr
<slangasek> siretart: though I have yet to figure out why
<siretart`> slangasek: I thought keybuk uncommitted it? - anyway, I think there is just a 'mkdir' missing in debian/rules
<slangasek> well, or an entry missing from debian/dirs
<slangasek> (though why does this package not use dh_install, sigh)
<siretart`> ah, right. that'd be easier
<slangasek> anyway, no, not uncommittd
<NCommander> superm1, ping? (I'd like to talk to you about recovery partitions if you have a moment soonish)
<Laney> Could someone rescore https://launchpad.net/~laney/+archive/ppa/+build/1319012 for me, pretty please?
<Laney> (testing an ftbfs fix for lucid)
<Laney> never mind, someone else did it :)
<pitti> cjwatson: could we have http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid ?
<seb128> do we know when autosyncs should start? they are blocked on source format changes too?
<ogra> doko, is the gcc in the archive already using ARMv7 and thumb2 ? or is that only the one in your ppa ?
<wgrant> seb128: The autosyncer will crash at the moment due to the new source formats.
<james_w> seb128: the autosyncer is currently pointing at unstable
<james_w> that will be fixed in the LP rollout scheduled for tomorrow morning I believe
<seb128> is there anything stopping me to sync the desktop things I want if they are in good old source format still?
<wgrant> seb128: I have a LP branch waiting for RC approval which will stop it from crashing, however it will not be able to sync v3 packages until somebody from the distro world convinces LP that it is important.
<pitti> seb128: no, that works fine
<james_w> specific syncs in the old format are fine as far as I know
<seb128> ok thanks
<wgrant> That will work fine, right.
<pitti> I did several syncs and they work well
<seb128> I just wanting to make sure before stepping where I should not ;-)
<pitti> seb128: if Soyuz breaks, we'll blame you :)
<seb128> I knew it!
<seb128> ;-)
<sebner> slangasek: is the ext4 corruption bug already fixed? LP says no so I'm wondering if it's the same issue linus closed with new -rc kernel. http://lkml.org/lkml/2009/11/3/377
<siretart`> james_w: if some package branch is not available, does it make sense to report it as a bug, nag you on irc, or should I rather ignore it and just merge the package it in the "traditional" way?
<smoser> does anyone know why ppa builds are taking so long ? https://launchpad.net/~smoser/+archive/ppa/+build/1318926 has been uploaded for 17 hours, it is to "start in 9 hours"
<ScottK> smoser: Look at the number of actively PPA buildds currently.
<Laney> apparently they were taken out to be release mirrors
<smoser> ScottK, where is that info?
<smoser> ah.
<smoser> but, just wondering, where can you see that?
<ScottK> smoser: https://launchpad.net/builders/
<james_w> siretart`: yes, yes and yes :-)
<soren> I'm still somewhat surprised that computing power is the bottleneck rather than bandwidth :)
<smoser> thanks ScottK .
<james_w> if you want me to take a look then I will, but it is often more than a 5 minute thing, so if it is urgent doing it another way would probably be wise
<siretart`> no, it is not urgent. I'm just experimenting with merging package with bzr and I am making great experiences
<smoser> more wondering, if "Architecture: all" then it gets built on i386 ?
<ScottK> smoser: Yes
<sgallagh> mathiaz: A few months ago, you reported a set of unused dependencies in the SSSD. I didn't have time to look into them until now. I saw that you guys pulled in 0.7.1 recently. Would it be possible for you to point me to the build log, so I can see the set of unused dependencies?
<sgallagh> /set/updated set/
<mathiaz> sgallagh: sssd is still at 0.5.0 in the developement  version (lucid)
<mathiaz> sgallagh: there is a bug to update it to 0.7.1 though
<sgallagh> mathiaz: Oh ok, so it hasn't been run yet. I was just trying to get the updated set of dependencies so I can fix them all in one go.
<mathiaz> sgallagh: ok - I'll try to get a test build run
<mathiaz> sgallagh: and file a bug report about it
<sgallagh> mathiaz: That would be fantastic. Thank you.
<davmor2> pitti: I've done a bunch of upgrade tests and I can't reproduce the issues people are having with the kernel being the jaunty one.  Also only issue I did come across was one on audio where the gfx card has hdmi out.  But once I'd told pulse which card to use and unmuted it was fine.
<pitti> davmor2: thanks; perhaps it's related to using apt-get dist-upgrade?
<davmor2> pitti: I can run one and see for you if you want?
<pitti> if you want, would be interesting to see if we have a bug there; but it should all be covered by the metapackages, I'd think?
<pitti> davmor2: it wouldn't work if they removed the linux meta packages, of course
<mvo> the upgrader will take care of a linux meta-package automatically, only apt-get users can be hit by that
<davmor2> I'll try an apt-get upgrade and see how it does
<davmor2> dist-upgrade even
<pitti> davmor2: thank you!
<doko> kees: online?
<kees> doko: I am now, hi!
<cjwatson> pitti: oops, forgot about that. It'll generate next time the cron job fires
<seb128> doko, could you unbreak python in lucid too for the -lssl issue?
<pitti> cjwatson: thanks
<doko> seb128: no, please fix the apps
<seb128> doko, there is a ton to do, could you be help having smooth transitions?
<seb128> doko, that breaks a good part of GNOME
<seb128> and I will not be able to look at those before uds
<doko> it's not breaking a running a system, so we should fix these during merges
<seb128> between vac, travelling and sprint next week
<seb128> I don't know how to fix those
<seb128> could you send patches please?
<seb128> doko, I guess I will just add libssl depends everywhere for now
<doko> not this week, and maybe not next week. if such a package is on my merge list, I'll fix it of course
<doko> seb128: don't do that, the bug report is concise about the exact fix
<seb128> doko, could be clear to you but it's not to me and I said I don't want to get things blocked until after uds
<doko> seb128: what exactly is unclear?
<seb128> the same packages is working in debian and those build fine in any other distro
<seb128> I've no time to deal with autotools changes and convincing upstream of why ubuntu need that now
<doko> seb128: no, it's not in experimental
<seb128> it's a compatibility breakage on your side imho
<seb128> but whatever I don't want to argue now
<seb128> I will add the depends so I get things to build
<seb128> thanks
<jcastro> Riddell, pitti, you have scheduling powers in the summit system now
<pitti> jcastro: thanks
<pitti> jcastro: rickspencer3 as well?
<jcastro> yep
<doko> seb128: I'm a bit pissed about your attitude to work around a known bug; it'll just be extra work later in the cycle
 * Riddell feels the power
<seb128> doko, looks like a compatibility breakage on your side and not a known bug to me but I don't think arguing will bring you somewhere
<seb128> doko, so let's agree to disagree
<doko> seb128: no, it has nothing to do about "compatibility"
<seb128> doko, the python package should not those public if they are not meant to be used and if they are public you should install enough to get it working
<pitti> what is the actual issue?
<seb128> it's like shipping a .pc and saying to not use it
<seb128> pitti, some python flag bringing -lssl without depends on libssl-dev
<seb128> pitti, let me look again to the exact build failure
<seb128> pitti, /usr/lib/python2.6/config/Makefile: LOCALMODLIBS=                       -lssl -lcrypto  -lssl -lcrypto      -L$(exec_prefix)/lib -lz
<seb128> pitti, that is shipping with python2.6
<seb128> and GNOME softwares use it
<seb128> but python doesn't have the depends corresponding to the -l<nnn>
<pitti> seb128, doko: are LOCALMODLIBS meant to get linked to external softare?
<doko> it is wrong that an extension links with LOCALMODLIBS
<seb128> what should be used instead?
<seb128> I just feel that I understand the issue enough to argue upstream or open a bug there
<seb128> +don't
<pitti> can't we just stop the affected packages from including LOCALMODLIBS into their linkage list?
<pitti> that would also avoid extra dependencies and make transitions easier
<doko> don't use LOCALMODLIBS at all
<seb128> why did they start using it in the first place?
<doko> the jaunty and karmic behaviour always links these libs with -lz, which is wrong as well. just by chance, or because zlib-dev is installed, lets you get away with it
<seb128> ok, let me try to just drop that from the configure
<doko> what was the bug number?
<seb128> do you have any pointer saying why those should be used to use for upstream bug reference?
<seb128> doko, bug #450355
<ubottu> Launchpad bug 450355 in totem "python extensions must not link with LOCALMODLIBS" [High,Triaged] https://launchpad.net/bugs/450355
<doko> seb128: at least for rhythmbox this is code which pre-dates distutils (i.e. python1.5). upstream is removing more and more of this old build stuff in every release, so an application/extension shouldn't rely on it. This code in gnome is really, really old. either distutils should be used, or at least python-config
<doko>         PYTHON_CFLAGS="-I$PY_PREFIX/include/python$PYTHON_VERSION"
<doko>         PYTHON_LOCALMODLIBS=`sed -n -e 's/^LOCALMODLIBS=\(.*\)/\1/p' $PYTHON_MAKEFILE`
<doko>         PYTHON_BASEMODLIBS=`sed -n -e 's/^BASEMODLIBS=\(.*\)/\1/p' $PYTHON_MAKEFILE`
<doko>         PYTHON_OTHER_LIBS=`sed -n -e 's/^LIBS=\(.*\)/\1/p' $PYTHON_MAKEFILE`
<doko>         PYTHON_EXTRA_LIBS="$PYTHON_LOCALMODLIBS $PYTHON_BASEMODLIBS $PYTHON_OTHER_LIBS"
<doko> pitti, seb128: for a quick fix, just remove the lines about PYTHON_LOCALMODLIBS and PYTHON_BASEMODLIBS. PYTHON-CFLAGS should use the output of python-config --includes to pick up the correct headers for debug builds, but apparently is not necessary in that package
<doko> anyway, afk now
<seb128> doko, ok thanks
<Riddell> doko: word reaches me that gdb 7.0 is broken for c++, do you know anything about it?
<Riddell> http://lists.trolltech.com/pipermail/qt-creator/2009-November/004963.html
<davmor2> pitti: apt-get dist-upgrade seems to be correct just confirming now
<Riddell> ScottK: what does your backports hat say to having a gdb-6.8 in backports and having qt-sdk depend on that?
<davmor2> pitti: it is in fact correct
<ScottK> Riddell: I don't understand.  We already have 7.0 in Karmic?
<Riddell> ScottK: and I'm told it's broken
<Riddell> for c++
<ScottK> Riddell: So you're thinking introduce a new gdb-6.8 package?
<Riddell> ScottK: yes
<ScottK> If so, I'd say get it into Lucid and a backport of a new package is no problem at all.
<Riddell> doko: got an opinion on that?
<ScottK> It might not be a bad idea to have a non-broken with C++ gdb in the development series either.
<davmor2> pitti: anything else you'd like me to try?
<pitti> davmor2: thanks; so I guess it's a customized /boot/grub/menu.list or something such
<davmor2> pitti: it certainly sounds it, that or a modded kernel
<jdstrand> soren: is there a vmbuilder somewhere that let's me build a lucid vm?
<jdstrand> soren: hi btw!
<tag> I've been having trouble with a segfault in libc since one of the Karmic beta releases and it has continued even on a fresh install of the official karmic release.
<tag> It appears to be related to catgets, now I'm not sure if it has anything to do with localization files somehow.
<tag> I know that's what catgets/catopen is used for.  When javac segfaults:
<tag> or java, rather
<tag> # C  [libc.so.6+0x31b08]  catgets+0x18
<tag> I'm having trouble with both swing apps and some SDL apps, but specifically *all* java swing apps and the fancy-terminal tilda.
<tag> I can't seem to recreate the segfault by simply exercising catgets()
<mathiaz> robbiew: hi - are there any guidelines for naming blueprints for lucid uds?
<mathiaz> robbiew: for karmic we used to have karmic-$track-foo as a template
<mathiaz> robbiew: has this changed for Lucid UDS?
<robbiew> not that I know of
<robbiew> as long as you are consistent
<robbiew> it really doesn't matter
<robbiew> just helps with finding the blueprints quickly for scheduling
<mpt> robbiew, is mvo's reply enough info for you to schedule UDS sessions on Ubuntu Software Center stuff?
<robbiew> yeah...I'll be doing the scheduling
<robbiew> this week
<mpt> ok, thanks
<slangasek> sebner: no, it's completely unrelated to the problem Linus is seeing in 2.6.32.
<sebner> slangasek: oh, I'm sorry than
<kirkland> https://bugs.launchpad.net/bugs/458549  <--- most entertaining bug report in a while
<ubottu> Ubuntu bug 458549 in ecryptfs "One Tin Platter (The Legend of Davey Jack)" [Critical,Incomplete]
<buxy> Unfortunately merge-o-matic is down due to Debian's change of source package format.
<buxy> anyone knows for how long? unfortunately the PTS mails me every 6Â hours when http://patches.ubuntu.com/PATCHES can't be downloaded
<buxy> slangasek: ^ (ping someone random that I know :))
<slangasek> buxy: until someone can update the merge-o-matic code to cope with the new packages; I think next week at the earliest
<ScottK> buxy: It's actually down due to Ubuntu not planning for the new source format.  Debian didn't do this by suprise.
<james_w> ScottK: bear in mind you are speaking to someone that is intimately familiar with how Debian did it ;-)
<buxy> heh :)
<kirkland> pitti: hi there
<kirkland> pitti: around? procedure question for you
<kirkland> pitti: order of operations, really
<mathiaz> sgallagh: hi - the current code in sssd trunk is supposed to be named 0.7.2 or 0.8.0?
<mathiaz> sgallagh: making sure to have the right upstream version number in the snapshot I'm preparing
<kirkland> mathiaz: okay, i have *fixed* https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/404394  :-)
<ubottu> Ubuntu bug 404394 in kvm "qcow2 corruption regression" [High,In progress]
<kirkland> mathiaz: i just uploaded to -proposed for SRU ification
<kirkland> mathiaz: i also uploaded the fix to hardy-backports and intrepid-backports, as it needs to be fixed there too
<mathiaz> kirkland: as in: a SRU for -backports?
<kirkland> mathiaz: right, sort of
<mathiaz> kirkland: out of curiosity - do you plan to do a backport of karmic kvm to hardy?
<jdong> bugfix on top of backports (tm) :)
<kirkland> mathiaz: no
<mathiaz> kirkland: virtio doesn't work on hardy host + karmic guests
<kirkland> mathiaz: the kvm-84 backport took a *lot* of effort
<mathiaz> kirkland: agreed.
<kirkland> mathiaz: how so?
<kirkland> mathiaz: i think this new upload might fix that for you...
<kirkland> mathiaz: you want a ppa package to test?
<mathiaz> kirkland: hm - I don't find the bug right now :/
<mathiaz> kirkland: it had to do with disk errors
<kirkland> mathiaz: that's this
<mathiaz> kirkland: you'd see them in the guest - like I/O errors
<kirkland> mathiaz: right
<mathiaz> kirkland: ok - then it's good news :)
<kirkland> mathiaz: i believe this upload fixes your problem
<kirkland> mathiaz: you want to grab the patch and test, or you want a ppa build?
<kirkland> mathiaz: ppa build will take a while
<mathiaz> kirkland: it will cut down iso testing from 4 hours to 2 h and 42 minutes
<mathiaz> kirkland: I can wait for the PPA build
<kirkland> mathiaz: https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/404394/comments/16
<ubottu> Ubuntu bug 404394 in kvm "qcow2 corruption regression" [High,In progress]
<kirkland> mathiaz: that's the hardy patch
<mathiaz> kirkland: ok - I may have a look at it later
<kirkland> mathiaz: is your hardy kvm server amd64 or i386 ?
<mathiaz> kirkland: amd64
<superm1> hi NCommander, what's up?
<KEBA1> considering the new gnome features (gnome shell and gnome zeitgeist) will come september 2010, is it possible that 10.10 will be a lts version instead of 10.04?
<KEBA1> because mabye the old gnome wont be supported a long time
<MsMaco> 10.04 wasnt going to get gnome 3 anyway
<kirkland> popey: outstanding blog post on upgrading
<popey> thanks kirkland
<MsMaco> popey++
<KEBA1> MsMaco: ah ok, because it might be to unstable?
<KEBA1> like kde 4.0
<MsMaco> i guess so
<MsMaco> lessons learned?
<nxvl> james_w: did you know why lp:ubuntu/hardy-security/firefox-3.0 is firefox 3.0.14 and not 3.0.15?
<nxvl> i mean the branch
<nxvl> james_w: isn't it updated automagically after upload?
<james_w> yes
<james_w> I've been working out some kinks that meant it sometimes fell over though
<nxvl> james_w: mm, so i just need to wait?
<nxvl> james_w: it has been 2 days
<james_w> nxvl: forced a check of that package
<nxvl> james_w: thank you
<james_w> nxvl: damn
<james_w> hit a bzr bug
<james_w> let me see if I can do anything about that
<nxvl> james_w: my problem isn't exactly now
<nxvl> james_w: i'm already late and doing some workarounds to make it work, so don't worry
<nxvl> james_w: what i'm worried is about it becaming my primary process
<nxvl> james_w: maybe we can discuss this better at UDS
<james_w> yes
<kirkland> mathiaz: build done -> https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1320609
<kirkland> mathiaz: could you grab that .deb, try it out and let me know?
<mathiaz> kirkland: sure - when do you need an answer?
<wgrant> lamont: Around?
<kirkland> mathiaz: today'ish?
<kirkland> mathiaz: i figure pitti will accept the upload for -proposed tonight
<kirkland> mathiaz: i'd like to have your feedback before then, if possible
<mathiaz> kirkland: okoidoikoi
<sebastien_> Hello tous le monde
<james_w> nxvl: I appreciate the testing, I'm working to iron out the kinks as you find them. Thanks.
<sebastien_> what is the chan for the ubuntu dev web ?
<nxvl> james_w: thank you for making my life easier :D
<mathiaz> james_w: seems that the karmic checkbox branch is not up-to-date
<mathiaz> cr3: ^^ this is why it generates these huge diff
<mathiaz> cr3: when you ask the review
<james_w> mathiaz: queued an import, thanks
<mathiaz> james_w: great - thanks
<james_w> I took the opportunity of the release to do some infrastructure work, so downtime was longer than desirable
<lifeless> james_w: hi
<james_w> hi lifeless
<lifeless> you have mail
<lifeless> I think I mailed you about this some months ago
<lifeless> but I was reminded recently
<james_w> don't see it yet, give me a clue?
<lifeless> pristine tar
<lifeless> bzr
<wgrant> slangasek: I slipped that autosync crasher fix into 3.1.10, as it has been delayed.
<slangasek> has it?
<wgrant> Yeah, by 24 hours -- 2009-11-05 0900
<james_w> lifeless: the answer is still the same as before
<lifeless> james_w: I don't recall what it was, sorry
<slangasek> wgrant: ah, ok
<slangasek> wgrant: that must be why the announcement mail didn't look right to me :)
<ScottK> Fortunately someome pointed out they'd neglected to announce their planned outage, so they rescheduled and announced.
<fta> do we already know if lucid will use gcc 4.5 or stick with 4.4?
<slangasek> fta: 4.4
<fta> ok, thanks
<mathiaz> cr3: http://bazaar.launchpad.net/~cr3/ubuntu/karmic/checkbox/0.8.5-0ubuntu1/revision/13
<mathiaz> cr3: is this^^ the diff to apply to checkbox?
<mathiaz> cr3: (except for the revision number - that I can fix)
<mathiaz> kees: hm - trying to do a SRU for a native package (checkbox)
<mathiaz> kees: the new revision number is 0.8.5-0ubuntu0.1 as suggested by https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging
<mathiaz> kees: however debuild -S complains about a missing .orig.tar.gz file
<james_w> I don't think that recommendation applies to native
<mathiaz> kees: http://paste.ubuntu.com/309940/
<kees> mathiaz: hrm, yeah, that suggestion in the wiki may be wrong.
<slangasek> honestly, I think it's better to ignore the debuild complaint
<kees> mathiaz: I would have said 0.8.5ubuntu0.1 or 0.8.5~0.1 .... native packages are weird.
<mathiaz> slangasek: doing that create a checkbox_0.8.5-0ubuntu0.1.tar.gz
<kees> slangasek: that works too :)
<slangasek> mathiaz: I don't see a problem with this :)
<slangasek> 0.8.5~0.1 doesn't work, that would sort earlier than 0.8.5
<mathiaz> kees: ok - so what do you suggest?
<kees> slangasek: it won't?  I thought that's what ~ did.
<kees> mathiaz: 0.8.5-0ubuntu0.1 without an orig should be fine
<slangasek> kees: ~ sorts before null
<slangasek> so if you're already at 0.8.5, 0.8.5~0.1 means going backwards
<mathiaz> kees: ok - thanks.
<kees> slangasek: right, i assumed 0.8.5 did not yet exist (i.e. SRU)
<kees> I see, however, that this is not true.  :)
<mathiaz> kees: oh - 0.8.5 is already in the archive
<kees> mathiaz: how about 0.8.5.1 then?  :)
<mathiaz> kees: that's possible as well
<mathiaz> kees: I was just following https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging
<slangasek> well, given that it's a native package anyway, 'ubuntu' in the version number seems redundant
<slangasek> 0.8.5+nmu1?
<kees> nooo
<slangasek> or 0.8.5+nmu0.1
<slangasek> or 0.8.5-0.1
<slangasek> or flog cr3 and make him stop using native version numbers
 * kees likes the latter
<mathiaz> kees: "flog cr3 and make him stop using native version numbers" ?
<kees> mathiaz: yup.  there's rarely a reason to use native numbers.  he should release proper tar balls, and use -0ubuntuN package versions
<mathiaz> kees: well - we've discussed this.
<mathiaz> kees: he used to do that (release tarballs)
<mathiaz> cr3: we should probably revisit that at the next UDS then
<james_w> mathiaz, cr3: checkbox branches up to date
<mathiaz> james_w: awesome - thanks
<lifeless> james_w: is there a command to export a tarball from a bzr branch [with pristine-tar magic]
<james_w> no
<lifeless> ok. I think thats what I'm basically looking for
<lifeless> I have use cases beyond debs
<lifeless> which is perhaps why you've been answering diferent questions than I've thought I had been asking
<siretart> james_w: if you have a free minute, you might want to review the imports for the devscripts package. I've just finished merging it with debian using bzr branches, but noticed that there are tons on conflicts, and most of them are spurious...
<james_w> siretart: from sid?
<siretart> it doesn't really matter if I merge the sid branch into the karmic one or the other way round
<siretart> generally, merges seem easier if you merge the ubuntu branch into the debian one
<Laney> semantically that's what you are doing, right?
<james_w> yeah
<james_w> siretart: it's because unfortunately the latest shared ancestor we have is ages old
<james_w> we don't have a full debian history, and so in some cases there have been huge changes since we can last infer a merge
<james_w> hang on, that's not quite right
<mathiaz> kirkland: seems that your kvm backport is working well here
<james_w> it's a bug that has been fixed in the meantime
<mathiaz> kirkland: I'm able to perform a successfull install of a karmic guest using a qcow2 file via virtio on a hardy host
<mathiaz> kirkland: which is failing with the version from hardy-backport
<kirkland> mathiaz: \o/
<kirkland> mathiaz: okay, please provide feedback in that bug
<mathiaz> kirkland: commented in the bug
<kirkland> mathiaz: that'll help get the uploads approved
<kirkland> mathiaz: great
<kirkland> mathiaz: sorry about that in the meantime
<mathiaz> kirkland: now the question I have is: are there any side effects on other configuration?
<mathiaz> kirkland: like raw+virtio
<mathiaz> kirkland: or qcow2+ide
<mathiaz> kirkland: or block device+virtio?
<kirkland> mathiaz: good question; i'm not sure.  but this code is upstream
<kirkland> mathiaz: and was released in RHEL5
<mathiaz> kirkland: right - so IIUC the patch is against block-qcow2.c
<mathiaz> kirkland: so it would only affect qcow2 files right?
<mathiaz> kirkland: why would qcow2+virtio fail and not qcow2+ide?
<kirkland> mathiaz: it should only affect qcow2+virtio
<kirkland> mathiaz: the affected code is in the qcow2 block driver
<mathiaz> kirkland: so qcow2+scsi uses a different block driver?
<kirkland> mathiaz: http://paste.ubuntu.com/309969/
<mathiaz> kirkland: so qcow2+*ide* uses a different block driver?
<kirkland> mathiaz: qcow2 is one block driver
<kirkland> mathiaz: raw is another
<mathiaz> kirkland: ok - so why does virtio trigger the bug and not ide?
<kirkland> mathiaz: ide, scsi, virtio are different interfaces
<kirkland> mathiaz: i'm not exactly sure
<mathiaz> kirkland: there's another comment added in the diff - probably related to the issue
<mathiaz> kirkland: does that mean that IDE doesn't do multiple writes while virtio does?
<kirkland> mathiaz: that sounds plausible; i don't know this code well enough to say for sure
<kirkland> mathiaz: thanks for the reminder to fix this issue in this morning's meeting
<kirkland> mathiaz: i had mostly forgotten about it
<mathiaz> kirkland: np - that's what bug lists (and LP fwiw) are for :)
<sgallagh> mathiaz: Sorry for the delay. We haven't officially decided what we're numbering the next release of SSSD. It's supposed to be a 1.0 release candidate. We might call it 0.8.0, 0.9.0 or 1.0.0rc (I'm leaning towards the latter)
<mathiaz> sgallagh: ok thanks for the update. It's not that important for now. Just making sure the release number are working correclty for package upgrades.
<mathiaz> sgallagh: so I'll use 0.8.0 and the version number could always be bumped for the final version
<sgallagh> mathiaz: Thank you for reporting the build failure. I'll look into that first thing tomorrow
<sgallagh> mathiaz: Yeah, I'm using 0.8.0 for our internal builds right now, with the same reasoning
<mathiaz> sgallagh: great. Probably a linking issue
<sgallagh> mathiaz: Yes, I suspect that the way we determine SELINUX_LIBS is probably coming up with the wrong set of flags on Ubuntu.
#ubuntu-devel 2009-11-05
<TheMuso> dtchen: given the upstart stuff you tried to sort out for alsa-utils, do youf irstly mind if I do that merge, and secondly, do you want me to include those upstart changes you made in the update?
<slangasek> pitti, cjwatson: a little present for you in the -proposed queue (gdm+xorg)
 * cjwatson looks
<cjwatson> slangasek: could you look at lilo-installer in hardy-proposed for me, in return? :)
<cjwatson> slangasek: we don't want to use a respawn limit instead? I thought historically we made the sketchy assumption that gdm might do better a second time, or something
<cjwatson> oh, it respawns itself on a crashing X server
<cjwatson> slangasek: where does EXIT_STATUS come from?
<cjwatson> ha, undocumented upstart feature
<cjwatson> oh, just not documented in init(5), but stopped(7)
<cjwatson> slangasek: what if gdm was killed by a signal (other than the usual termination signals - e.g. SEGV)?
<m4t> i was wondering earlier, where the .04 and .10 versioning scheme comes from?
<lifeless> months of the year
<m4t> oh ;-)
<wgrant> 9.04 == April 2009
<m4t> thanks
<slangasek> cjwatson: lilo-installer> ack, looking :)
<slangasek> cjwatson: haven't looked in detail at signal handling; I can dig into that further if you wish, but the major problem is gdm exiting on its own, and I think this upload is a marked improvement regardless of how it handles signals
<slangasek> cjwatson: btw, I noticed after upload that bryce also had a 7.1 upload to -updates, so I rejected my own ubuntu8 - bryce has merged the two and uploaded ubuntu9
<dtchen> TheMuso: I don't mind, and I would like that bit merged, yes.
<TheMuso> dtchen: ok will do, thanks.
<dtchen> TheMuso: great, thanks
<ebroder> dtchen: Can you take a look at bug #330766?
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Unknown,Fix released] https://launchpad.net/bugs/330766
<cjwatson> slangasek: I think it would be worth checking into signal handling some more, yes, but I agree that it makes sense to accept this in the meantime, and have done so
<cjwatson> slangasek: are any corresponding changes needed to kdm?
<slangasek> cjwatson: bulletproof-x only ever hooked into gdm... we could do kdm as well, but that would involve quite a bit of fiddling and is probably not a good idea for SRU
<slangasek> thanks for the accept :)
* spm changed the topic of #ubuntu-devel to: LP down 0900UTC - 1030 | Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | 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
<m4t> anyone familiar with getting grub2 to boot openbsd and the like?
<m4t> i thought a simple chainloader +1 should suffice
<cjwatson> slangasek: ok, I wasn't sure if kdm had hooks or not
<cjwatson> m4t: not familiar with BSD, but I know that GRUB2 has explicit commands for it, which rather suggests to me that chainloader is not sufficient
<cjwatson> m4t: you might try 'help openbsd' in the GRUB shell
<cjwatson> (it'll change to 'kopenbsd' in the future to denote that it's for the openbsd kernel specifically
<lifeless> cjwatson: is grub2 nice?
<cjwatson> ask a more meaningful question :) I like it, personally
<cjwatson> much nicer to hack on than grub legacy was
<slangasek> and some day it will free us from menu.lst
<lifeless> cjwatson: I considered the question carefully :) - and cool
<lifeless> slangasek: orly? speaking of menu.lst...
<lifeless> do we know the cause of the missing entries yet?
<cjwatson> some day> I believe the only remaining blocker is sorting out reliable disk identification
<cjwatson> which I've asked Robbie to allocate me a work item for for lucid
<cjwatson> (have already designed it, but regrettably ran out of time in karmic)
<slangasek> lifeless: I'm attributing it to the unexplained causality bubble that follows you around
<slangasek> because nobody could reproduce it on a fresh install
<lifeless> slangasek: and yet, many folk have this problem :)
<lifeless> slangasek: did the testers try manual partitioning?
<cjwatson> many folk have a problem with the same symptom
<slangasek> really?  you're the only one who's been confirmed to have /this/ problem
<lifeless> cjwatson: true
<cjwatson> lifeless: did you already attach your installer syslog to a bug?
<lifeless> cjwatson: yes
<cjwatson> oh yes, I think I looked at it and it was inconclusive
<slangasek> long term, though, grub2 ought to hook into /etc/kernel/p*.d/ and sidestep this
<cjwatson> I know for a fact that manual partitioning is not fucked in this way, in general
<slangasek> (there's a bug just opened on the Debian package about that, in fact)
<cjwatson> this is not to say that there are not specific problems
<cjwatson> but it doesn't pay to overgeneralise
<cjwatson> the only cause I can think of for update-grub not getting hooked properly would be the installer crashing before it gets to the end of grub-installer
<cjwatson> sometimes people miss the fact that the installer crashed, assisted by the installer not always being terribly clear about the fact that it crashed
<cjwatson> so they end up continuing to run semi-busted systems
<lifeless> cjwatson: thats entirely possible
<lifeless> ok, so I generalised too early I think.
<cjwatson> you might be able to notice this by the fact that, in this scenario, the ubiquity package would be installed on the installed system
<cjwatson> is/was this the case?
<lifeless> dpkg -l ubiquity -> <none>
<lifeless> I haven't been on a cleanup crusade that I remember
<cjwatson> the weird bit was that I didn't see any definite indication in your log that grub-installer *had* run properly
<cjwatson> but I'm travelling this week so only had about 30 seconds for analysis
<lifeless> its : purge ok not-installed in initital-status.gz
<cjwatson> that's fairly indicative
<cjwatson> indeed the fact that you have initial-status.gz at all is a good indication that installation completed successfully
<lifeless> so, other than I had to manual partition (dmraid system) I don't recall any oddities about the install
<cjwatson> I wonder if something broke kernel-img.conf later, then
<lifeless> and by manual partition I mean configure dmraid, then run ubiquity and clicky-clicky config the partitions on the dmraid device
<cjwatson> sure
<cjwatson> (no longer necessary in karmic)
<lifeless> cjwatson: datestamp on kernel-img.conf is 2009-04-21 00:01
<lifeless> which is, I think the cd timestamp - there are other directories and stuff in /etc with the same
<cjwatson> it ought to be installation timestamp not cd timestamp
<cjwatson> what's your bug unumber?
<lifeless> I installed the machine fresh with jaunty
<lifeless> one sec
<lifeless> bug 470265
<ubottu> Launchpad bug 470265 in grub "[MASTER] jaunty to karmic upgrade failed to update menu.lst (update-grub missing from kernel-img.conf)" [High,New] https://launchpad.net/bugs/470265
<cjwatson> I don't see it running grub-installer at all there
<lifeless> that would explain the hook not being present
<lifeless> OTOH
<lifeless> how come I can boot?
<cjwatson> you clearly have a bootloader installed, but that doesn't necessarily mean your new installation put it there
<cjwatson> new> the jaunty one I mean
<lifeless> thats true
<lifeless> so I bought the machine new
<cjwatson> did you do anything in the advanced dialog in ubiquity, like uncheck the "install grub" box?
<cjwatson> and install a bootloader by hand?
<lifeless> I don't recall going into the advanced dialog
<cjwatson> that's the only way I can see how this log could have happened
<lifeless> does ubiquity journal the options?
<lifeless> if install-grub is off, is the grub package still installed ?
<cjwatson> unfortunately not
<lifeless> cool
<cjwatson> quite possibly, copied from the live filesystem
<lifeless> so if I have grub, and didn't manually install it?
<cjwatson> the reason I think you unchecked the option is that the characteristic mount pattern in configure_bootloader is missing
<cjwatson> grub is unconditionally kept installed regardless of that option, but it isn't necessarily installed *as a bootloader*
<lifeless> right
<lifeless> I grok the difference :)
<cjwatson> in jaunty, you may well have had to do something like this to make things work with dmraid
<lifeless> I don't trust my memory of an install 4 months back :(
<lifeless> ok, so we should close this bug - its not representative I guess?
<cjwatson> please don't close it
<cjwatson> I'm attempting to analyse the cause, not apportioning blame
<cjwatson> even unrepresentative bugs shouldn't necessarily be closed :)
<lifeless> cjwatson: I get that, but if the cause is 'the user chose not to have grub installed' ? :)
<cjwatson> but then you chose to use it later, and that wasn't handled correctly
<lifeless> cjwatson: and as grub2 will be less fragile in having the right setting in the hook
<cjwatson> it's still a bug
<lifeless> k
<lifeless> I apply a similar analysis to bzr bugs, was really just asking what you wanted
<cjwatson> I don't think that grub2 is less fragile in this particular way (kernel-img.conf), although it is less fragile than others
<m4t> cjwatson thanks, uhm, grub shell...is there a grub shell with grub2?
<cjwatson> s/than/in/
<cjwatson> m4t: the command line when you boot
<m4t> ah yea.
<cjwatson> press c at thee menu
<cjwatson> slangasek: is lifeless about the only person who has update-grub just plain missing from kernel-img.conf?
<m4t> ehm maybe i am just silly
<m4t> # For booting OpenBSD
<m4t> menuentry "OpenBSD" {
<m4t>         set root=(hd0,1,a)
<m4t>         openbsd /bsd
<m4t> }
<m4t> from docs/grub.cfg in the latest grub2 source
<cjwatson> I'm wondering if a useful workaround would be to have the kernel packaging explicitly call update-grub if it notices /boot/grub/{menu.lst,grub.cfg} and update-grub isn't in postinst_hook
<m4t> what gets me, though...
<m4t> is why openbsd refuses to install its second stage loader in the openbsd partition
<m4t> slight off-topic but #openbsd doesnt seem very responsive
<m4t> let me try with this
<cjwatson> afraid I don't know
<m4t> (did grep  -ri on the grub2 source)
<m4t> er
<m4t> grub -ri openbsd
<m4t> heh
<cjwatson> please don't use the enter key as punctuation. :)
<lifeless> cjwatson: so, perhaps fixing the postinst_hook if the grub package is installed and /boot/grub/menu,cfg are  present ?
<cjwatson> your menuentry stanza matches the one in up-to-date grub trunk, so I'm afraid I don't know more ...
<cjwatson> lifeless: or just doing the right thing regardless of the dodgy hook thing
<cjwatson> which was (frankly) never a particularly sane design
<lifeless> cjwatson: or using a dpkg trigger and doing the right thing?
<cjwatson> I don't know whether triggers are the right thing long-term, but I would rather not introduce them in an SRU
<lifeless> calling update-grub from a new spot might be a problem too
<cjwatson> this wouldn't be a new spot, really - just do it alongside where it already processes postinst_hook
<cjwatson> it's new code, but fewer moving parts
<cjwatson> triggers are cool but they can have some slightly weird consequences sometimes :)
<Vkontakte> A lot of free mp3 and video clips. Other pages in social networks "Vkontakte" www.vk.com/reg4286668 and invite your friends!
<NCommander> superm1, yay for IRC ping-pong :-/. I completely missed your earlier ping
<AnAnt> Hello, will Source format "3.0 (quilt)" be allowed in lucid ?
<cjwatson> AnAnt: probably, but not for a little while yet
<hyperair> hello. who handles hal here?
<dholbach> good morning
<hyperair> hal stops and doesn't restart when udev is restarted.. hmm
<hyperair> how does upstart handle "and" and "or" for events?
<hyperair> does it remember when one event is fired, or what?
<AnAnt> ok
<mdke> we've had a lot of bugs lately being filed on ubuntu-docs which are nothing to do with documentation. I'd like to understand why they end up there instead of just without a package allocated. They all say "Binary package hint: ubuntu-docs" at the beginning - does that suggest any explanation to anyone?
<hyperair> ubuntu-bug ubuntu-docs, perhaps?
<mdke> hyperair: I suppose it could be, but I don't see why a user would type that if they have a problem which is nothing to do with docs
<mdke> I'm wondering if Launchpad is suggesting the package or something
<hyperair> agreed =\
<cjwatson> they type 'ubuntu' and it's early in the list?
<hyperair> heh
<hyperair> does launchpad understand the concept of binary packages when it comes to bugs?
<hyperair> i mean you don't see a launchpad.net/ubuntu/+binary/<pkg> do you?
<cjwatson> only in that it can map binary to source when you type a binary package name in the "affected package box
<soren> If you just type "ubuntu" in the search field, it'll tell you there's too many matches.
<hyperair> ah
<mdke> hmm
<mdke> a mystery I guess
<hyperair> you could ask one of the bug reporters how they reported it
<hyperair> =p
<mdke> hyperair: occasionally we do but it's never yielded any results
<hyperair> heh
<hyperair> another one of those kinds of mysteries eh
<hyperair> at one point of time, #ubuntu-sg was getting a lot of people connecting to it from US, UK among other faraway places
<hyperair> they'd connect when everyone was sleeping, start kicking up a big fuss about how nobody's around to help them and leave before anyone woke up =.=
<pitti> Good morning
<pitti> kirkland: hi
<pitti> kirkland: will process SRUs this morning (as every morning, afternoon, and evening nowadays :) )
<pitti> ttx: any chance to give euca some testing with the packages in -proposed? (see bug 461090)
<ubottu> Launchpad bug 461090 in libxstream-java "updates for karmic and lucid needed to get maven plugins building" [Medium,Fix committed] https://launchpad.net/bugs/461090
<pitti> ttx: I'll also do a binary debdiff to ensure that the only thing that changed is the added .pom files; but better be double-sure..
<ttx> pitti: sure
<ttx> pitti: I need to purge my inbox first, but i'll update my setup to -proposed and run a few tests soon
<pitti> ttx: merci beaucoup!
<ttx> pitti: bitte
<slangasek> cjwatson: lifeless is the only one w/ a botched kernel-img.conf missing that I've run across /so far/.
<pitti> argh, LP offline
<seb128> pitti, hey, same here
<seb128> I could have slept an extra hour ;-)
<seb128> weird, I didn't read any mailing list announce about it
<pitti> seb128: there was one yesterday
<pitti> wgrant: FYI, something like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538679#10 is now sent to quite a lot of packages, so I think we won't get around having dpkg-3.0 in lucid :-(
<ubottu> Debian bug 538679 in dclock "dclock: FTBFS with new source format 3.0 (quilt): removes .pc before quilt pop" [Wishlist,Open]
<wgrant> pitti: We certainly won't get around it for Lucid.
<wgrant> pitti: The thing in question is whether we can get away without it until 2009-12-05.
 * wgrant checks the rate of 3.0 migration.
<seb128> wgrant, what is special at this date?
<siretart`> next scheduled lp rollout?
<wgrant> seb128: LP 3.1.11.
<seb128> oh ok
<wgrant> We have the option of cherrypicking before then though, since the DB changes slipped into 3.1.10.
<Phurl> hi all, I would like to help with these new problems of the upgrade
<Phurl> I am a developer, and can do all types of things.
<Phurl> right now I have upgraded my ubuntu from 8.4 over the months
<Phurl> and the sound and netowork stopped working
<Phurl> is there anything that I can do to fix this?
<Phurl> ok well i will file a bug report
<AnAnt> Hello, is it possible to build a Source format "3.0 (quilt)" package on my karmic installation ?
<AnAnt> using pbuilder that is
<slangasek> AnAnt: the dpkg in karmic supports it if you pass some magic options (which I don't know offhand); Launchpad won't currently accept any such packages though, FWIW
<slangasek> Phurl: filing a bug report sounds like a good idea there
<Phurl> ok
<wgrant> It shouldn't need magic options besides the existence of debian/source/format.
<slangasek> oh, well, that's magic enough :)
<AnAnt> wgrant: so, does one still need to put quilt in build-deps ?
<AnAnt> if he is using quilt patch system that is
* mthaddon changed the topic of #ubuntu-devel to: Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | 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
 * StevenK blinks at why his shiny new Dell doesn't want to talk via Ethernet
<StevenK> pitti: Oh, I wanted to talk to you about one of your specs?
<pitti> StevenK: please do :)
<StevenK> pitti: You subscribed me to the UNR session one so that desktop people could try it?
<StevenK> pitti: I was wondering if we could also do it the other way -- if the UNR session was the default for UNR images, but people could choose a desktop session too
<StevenK> Oh, duh. Don't play with Jockey when apitude is installing stuff
<StevenK> pitti: But Jockey could give a better error than "installArchives() failed"
<pitti> StevenK: that should be easy as well
<StevenK> pitti: If you're happy to cover that in the spec, then that is one less I have to write :-)
<pitti> StevenK: sorry, had a DSL reconnect; I got your "Oh, duh...", but not anything before that
<StevenK> [22:07] < StevenK> pitti: You subscribed me to the UNR session one so that desktop people could try it?
<pitti> StevenK: it'd be a separate package though, I guess
<StevenK> [22:07] < StevenK> pitti: I was wondering if we could also do it the other way  if the UNR session was the default for UNR images, but people could choose a desktop session too
<pitti> [12:11]     pitti| StevenK: that should be easy as well
<StevenK> pitti: Right, then you were answering what I thought you were. :-)
<pitti> StevenK: can be covered in the same spec; it's the same scheme, just a different package and session name
<StevenK> pitti: Can you also subscribe davidm to the spec?
 * StevenK digs for it
<pitti> StevenK: done
<pitti> StevenK: please change the summary accordingly (how you want it to look in UNR, since you don't have gdm visible)
<StevenK> pitti: We still use gdm, so it could be hand waved, I guess
<mvo> amitk: if you have a moment I would like to ask about bug #453444 - is the kernel in karmic-final fixed or is this a fix that is commited and will be part of a commin update?
<ubottu> Launchpad bug 453444 in rsyslog "/var/log fills up with "all normal" messages @ about 575/sec fill up the available space" [High,In progress] https://launchpad.net/bugs/453444
<mvo> amitk: I ask because I got reports (eg. from YokoZar) that this is still a problem with karmic-final
<mvo> pitti: hm, there is a discussion on flag-restart-required *before* actually doing the upgrade in update-manager. what do you think about "XB-Restart-Required: [system, session, app]" in debian/control ?
<pitti> mvo: oh, instead of having to change the postinst? sounds nice
<mvo> yeah
<mvo> nice and simple, I'm trying to think of downsides, but I can't see any
<pitti> mvo: before the upgrade> so that the user can choose not to do it right now?
<mvo> yes
<pitti> mvo: which bit would check that flag and call restart-required? dpkg?
<mvo> showing in u-m "this update requires a restart"
<mvo> well, I was not thinking that far :)
<mvo> we could have a debhelper thing that generates a postinst just like we have now
<pitti> or that
<mvo> or modify dpkg/apt/apt-listchanges
<seb128> mvo, what do you want to do from this info?
<james_w> mvo: would it be able to specify versions as well?
<mvo> seb128: showing in update-manager "2 updates that require a restart"
<james_w> XB-Restart-Required: system (<= 0.1-1)
<seb128> mvo, is that a "you need to restart to be able to use the upgrade" or a "you should restart because you don't get the security fix until then"?
<mvo> james_w: sweet, that is a nice idea
<james_w> some packages do dpkg --compare-versions currently in the postinst?
<soren> james_w: Meaning "if you're upgrading from a version of this package earlier than 0.1-1, you need to reboot"?
<mvo> seb128: I'm not sure I understand the difference, but it would be purely to show the user in advance that this update will require some sort of restart (e.g. fireofx)
<james_w> soren: exactly
<soren> james_w: Ok.
<james_w> for those packages that don't require a restart every time they are upgraded
<seb128> mvo, the difference: is it to point cases where the upgrade will break what you do and force you to restart?
<seb128> mvo, or is that for things like dbus or you are suggested to restart
<mvo> james_w: I wonder if there are any currently (but its good to have the feature)
<james_w> of course, it can always be more complex, like "restart if this other package is installed", but you can always suggest restarting too much
<james_w> mvo: what would signal update-notifier?
<mvo> seb128: currently its mixed together, it might make sense to have a different one. like restart-suggested, restarted-required
<james_w> mvo: would dpkg now write the /var/run/ file based on XB-Restart-Required?
<mvo> james_w: not sure yet, it could either be the currently mechanism and debehlper would do some magic
<pitti> well, it's not really "suggested"
<james_w> ok
<mvo> james_w: or we move it to dpkg or we add a pre-run hook
<pitti> the difference is just that ffox breaks after the upgrade, while dbus doesn't
<mvo> (like apt-listchanges, just for this)
<seb128> pitti, well I think the user is rather interested to know about things which will break
<mvo> pitti: yeah, for the "it-breaks" it would be a "restart-required: app"
<pitti> seb128: exactly
<mvo> restart-requires: [system, session, app, app-breaks] ;)
<seb128> app and app-breaks is the same
<seb128> you only want to notice about breakages
<seb128> you can assume than in any case you need to restart an app to get the change anyway there
<mvo> good point
<seb128> in any case seems fine to me
<seb128> +1
<seb128> we can figure what we do from the info later
<soren> How about something like this: We add the field (as an XB-Restart-Required), and add a debhelper script that detects it and adds a handler to postinst. The handler will dump the information in a state directory somewhere, and call "dpkg-trigger restart-required".
<soren> Packages like update-notifier can add a handler for that trigger and do somethign useful with it.
<mvo> soren: that sounds like a good plan, I think we have just create a mini-spec :)
<superm1> NCommander, if we are on different time zones right now, email might be better then
<soren> That way, we don't need extra magic in dpkg at all, and we have flexibility in adding multiple handlers.
<mvo> thanks seb128, pitti, soren, james_w
<mvo> soren: yeah
<pitti> soren, mvo: right now the script/inotify ensure that dpkg is completely done; with a trigger, the user might click "reboot" too early (e. g. when a later trigger is still doing stuff)?
<NCommander> superm1, we're in relatively close timezones. The problem is my internal body clock thinks its in Japan at the moment
<soren> pitti: Depends.
<soren> pitti: Whatever is triggered can check if the package db is still locked.
<soren> Or whatever.
<soren> pitti: It's definitely solvable.
<pitti> ah, fork & poll FTW :)
<soren> Well, in the case of update-notifier, doesn't it just send a dbus event that something else will handle?
<pitti> soren: solvable> agreed, just needs to be kept in mind
 * soren hasn't really looked closely at that stuff.
<soren> pitti: Sure. Good point.
 * mvo nods
<pitti> soren: no, u-n inotifies a flag file that /usr/share/reboot-required script sets
<pitti> and then waits on apt to finish
<soren> The thing that actually suggests to the user to reboot should be smart enough to not do this if e.g. the package db is locked.
<soren> pitti: Ah, ok.
<pitti> soren: but you are right; we clearly need to involve d-bus here! :-)
<soren> So if someone starts apt again in the mean time, what happens?
<pitti> soren: after the upgrade? you lose
<superm1> NCommander, okay well what's up?
<soren> does the restart dialog disappear..
<soren> oh.
<pitti> i. e. if you start another install and click reboot
<soren> well, that should probably be fixed, too :)
<NCommander> superm1, mind if I PM you?
<superm1> sure
<mvo> I think what we want is a more general "if you reboot while dpkg is running, give it a bit extra time to finish". but that becomes tricky when the user is e.g. in a hurry
<mvo> its also a problem in how to represent it
<soren> mvo: As a first step, how about just having the UI not offer the option to reboot if dpkg is running?
 * soren runs an errand
<mvo> soren: that should already be the case, but it should also auto-vanish if dpkg gets started again after the dialog was shown
<soren> mvo: ..and turn up again when dpkg is done, surely?
<mvo> yes
<soren> Ok.
<soren> Great :)
<mvo> :)
<james_w> mvo: one thought
<mvo> just the vanish-again part needs to get done, then its cool
<james_w> does "XB-Restart-Required: package" depend on whether it is an upgrade or install?
<james_w> would we have anything that needs to trigger a restart when installed for the first time?
<mvo> hm, in the case of an app not, but in the case of a kernel it might be I think
<james_w> because you could force only-on-upgrade with "XB-Restart-Required: package (>= 0)"
<mvo> or of e.g. a nvidia driver, a session restart is suggested then
<mvo> right
<james_w> but it may not be possible to force only on install
<james_w> so "XB-Restart-Required: package (install)"
<james_w> could be supported or something
<james_w> depending on what "XB-Restart-Required: package" alone means
<mvo> I think its something to keep in mind
<james_w> I don't mean "package" do I? I mean "system"
<mantiena> dholbach: hi, I've noticed, that you fixed some bugs in msttcorefonts package few years ago, now this package has very big problems, which doesn't allow smootly upgrade to Ubuntu 9.10 (Karmic) :(
<mantiena> Look at bug #464422 - about 60 duplicates already, about 10 duplicates are reported every day since release of Karmic :(
<ubottu> Launchpad bug 464422 in baltix "package ttf-mscorefonts-installer 3.0 failed to install/upgrade" [Undecided,New] https://launchpad.net/bugs/464422
<mantiena> I think Ubuntu developers should release a fixed version of ttf-mscorefonts-installer ASAP, it's not hard to fix this bug - ttf-mscorefonts-installer shouldn't return an error if there are no access to corefonts download servers, AFAIK a dialog with buttons "Try again" and "Download later" (run dpkg-reconfigure ttf-mscorefonts-installer when you will have internet connection) should be displayed instead
<slangasek> "download later" shouldn't result in the package being configured
<slangasek> the flash installer did that for the longest time, and people ended up with no flash plugin on their systems and no idea why
<mok0> Should multiverse be enabled during install???
<mok0> Like slangasek says, there are other packages downloading non-free stuff and that is bound to screw up
<mok0> Perhaps downloading packages should be moved to a different component alltogether
<slangasek> not really
<mok0> slangasek: not really what? :)
<slangasek> they shouldn't be moved to a different component
<slangasek> making new buckets doesn't change the underlying problem
<mok0> slangasek: it does, because you can disable the bucket during upgrade
<slangasek> but we don't want people not upgrade parts of their system. :)
<slangasek> +to
<mantiena> slangasek: in any case - user should get interactive dialog instead of canceled Ubuntu upgrade procedure. Please read the description of bug 464422 - there are lots of situations, when internet connection is lost after packages are downloaded (in configuration stage), so, ttf-mscorefonts-installer shouldn't fail silently if there are no access to download servers
<ubottu> Launchpad bug 464422 in baltix "package ttf-mscorefonts-installer 3.0 failed to install/upgrade" [Undecided,New] https://launchpad.net/bugs/464422
<mok0> slangasek: that's what's happening anyway, in these bugs
<mok0> slangasek: besides, when the bucket is disabled, the system doesn't know that it's supposed to upgrade something :)
<slangasek> mok0: giving them a button to click that lets them defer the upgrade indefinitely isn't a good solution, though.
<mok0> slangasek: I agree
<seb128> jdstrand, hi, if you do a sru on a desktop package where the karmic and lucid version are the same please commit to bzr too
<slangasek> mantiena: right, the package should at least make it clear why it's failing
<seb128> jdstrand, not sure if you forgot for evince or if the policy was not clear about where the store sru changes
<mantiena> slangasek: what about moving fonts download to preinst script?
<slangasek> that would only change the type of error you get
<seb128> jdstrand, I've fixed it in bzr now so no need to look at this one btw ;-)
<mantiena> slangasek: but if preinst will fail, then ttf-mscorefonts-installer will be left in older version and upgrade procedure will continue, right?
<mok0> preinst script could check that the box is connected to the internet
<mantiena> because currently ttf-mscorefonts-installer is updraded and status is partially installed if there are no access to download servers
<slangasek> mantiena: I'm not sure how far it will continue, mvo would know better.  In both cases, apt will see an error, and eventually report it to the user
<slangasek> mok0: why?  that doesn't change anything about what the script needs to do
<mok0> slangasek: ... you're right
<slangasek> can't download --> failure
<mok0> slangasek: it just seems wrong to me somehow to download in preinst
<slangasek> well, I tend to agree; but for ephemeral, aesthetic reasons - whatever works best must be the right thing to do ;)
<mok0> heh, yes
<slangasek> but if you mean checking for internet connection in the preinst, so we can abort early; but only download in the postinst - this is obviously not atomic, so the preinst check would then be redundant
<mantiena> slangasek: AFAIK the best situation would be: if there are no access to corefonts download servers, then ttf-mscorefonts-package should be not installed (or not upgraded) and don't return a critical error (distribution upgrading should continue)
<mok0> Sort-of when the upgrade of a package requires the installation of a new package, it's left un-installed
<slangasek> distribution upgrading should continue anyway; if it doesn't, I think this is an issue with package manager error handling, TBH
<mantiena> checking internet connection in preinst isn't good decision, because there are plenty of cases, when internet connection is ok, but fonts can't be downloaded from some download servers (for example because of timeouts of lots internet connection during download)
<mok0> In any case, this package should have no reverse dependencies, and should have the lowest priority of all -> installed at the very end
<mantiena> slangasek, mok0: in reality updrading ttf-mscorefonts-installer shouldn't download any files from internet, because fonts files are already installed in user's system ;)
<slangasek> heh, I think that's a separate bug from what we've been talking about so far, then. :)
<mok0> mantiena: Indeed
<mok0> Why hasn't this been a problem with earlier releases?
<jdstrand> seb128: ack. I was thinking lucid was different now, so didn't commit to bzr. your policy makes sense and I'll keep that in mind going forward. thanks for taking care of the commit, and sorry for not committing
<seb128> jdstrand, thanks ;-)
<mantiena> mok0: Few years ago msttcorefonts package always informed user before download, that he needs internet connection and users can type "none" if  they do not wish to download these fonts now or do not have internet access, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549882#25
<ubottu> Debian bug 549882 in ttf-mscorefonts-installer "ttf-mscorefonts-installer: Poor handling of font downloads" [Normal,Open]
<mantiena> This text was displayed before download: If you have already downloaded Microsoft's TrueType Core Fonts for the web,  type the name of the directory which contains them. Those files are in the  Microsoft Windows self-installing format, and are named andale32.exe,  arial32.exe, arialb32.exe, comic32.exe, courie32.exe, georgi32.exe,  impact32.exe, times32.exe, trebuc32.exe, verdan32.exe and webdin32.exe.   If you haven't yet downloaded these fonts, leav
<mok0> mantiena: hm, perhaps that was changed in connection with the switch to kpackagekit
<mantiena> mok0: no, that was changed earlier, maybe in 8.10 (Intrepid)
<mok0> mantiena: I see
<mantiena> Bug #464422 still isn't assigned to Ubuntu developer, I'm talking here because I hope to find a developer for fixing this bug :)  About 60 duplicates already, about 10 duplicates are reported every day since release of Karmic, AFAIK it's big problem for users.
<ubottu> Launchpad bug 464422 in baltix "package ttf-mscorefonts-installer 3.0 failed to install/upgrade" [Undecided,New] https://launchpad.net/bugs/464422
<mok0> eeekk gotta go
<mantiena> slangasek: so, what you think about finding a developer to fix bug 464422 ? Or maybe you can fix this bug?
<ubottu> Launchpad bug 464422 in baltix "package ttf-mscorefonts-installer 3.0 failed to install/upgrade" [Undecided,New] https://launchpad.net/bugs/464422
<slangasek> mantiena: I'll take a look, but I don't guarantee that it'll get fixed for 9.10; most downloader packages I've seen have been horribly done, and it may resist surgical fixing
<mantiena> slangasek: If this package will be not fixed and not put into karmic-proposed, then there will be 200 duplicates after 2 weeks... :(
<apw> slangasek, any idea where i'd find the gcc devs ?
<mantiena> I can help you to find ideas how to fix and to test ;)
<slangasek> apw: no?
<apw> seems the compiler is exploding
<apw> doko, ahh ... seems you are involved in gcc
<slangasek> try turning on -fno-explosions?
<apw> i am getting seg faults trying to compile the kernel with the 4.4.2-1ubuntu2 gcc upload
<slangasek> ah
 * apw wishes
<slangasek> there's a -1ubuntu3 that's been uploaded, only the source is available
<apw> yeha the changelog there talks only about arm build failures
<dholbach> mantiena: I can't remember I ever touched that package - could it be you mean somebody else?
 * apw retries the build to see if its consistent on the files which kill it
<slangasek> mantiena: looking at the package, it *does* know not to re-download if it already has the fonts
<mantiena> dholbach: I've found you name in changelog.gz ;) msttcorefonts (1.2ubuntu1) hoary;
<mantiena>   * tightened build-depend on defoma (>= 0.8.11ubuntu2)
<mantiena>  -- Daniel Holbach <dh@mailempfang.de>  Fri, 18 Mar 2005 22:05:09
<dholbach> mantiena: that was a mass upload for a couple of fonts
<dholbach> so, I'm sorry, but don't think I can help
<mantiena> slangasek: maybe, but main problem is not in re-downloading, but in returning an error during configure...
<slangasek> mantiena: well, that part we don't seem to be in agreement on; if the fonts aren't there, returning the error is the correct thing to do
<mantiena> dholbach: ok, I hope, that slangasek can :)
<dholbach> rock on!
<mantiena> slangasek: AFAIK the best situation would be: if fonts can't be downloaded from servers, then ttf-mscorefonts-package should be not installed (or not upgraded) and don't return a critical error (distribution upgrading should continue)
<slangasek> mantiena: but that's meaningless, because the only thing *trying* to download the fonts is this package
<slangasek> you can't know it will fail before it tries
<mantiena> slangasek: so, font downloading should be moved to preinst, as preinst script is run before package installation, right?
<slangasek> moving it to the preinst won't prevent an error being passed up to the package manager
<slangasek> it will just show up as "error unpacking" instead of "error configuring"
<mantiena> slangasek: if ttf-mscorefonts-installer package will be not installed, then it's ok, system packaging dabase will be in correct status without half-configured packages
<slangasek> I don't think that's a useful distinction
<slangasek> the system is still incompletely upgraded
<mantiena> slangasek: you think, that there will be a problem, if one package - ttf-mscorefonts-installer will be not upgraded?
<slangasek> I think it *is* a problem if the package isn't upgraded
<slangasek> I also don't think, from reading the source, that this is being caused by a failure to upgrade the package; I think this is happening when the package is being pulled in as a new dependency
<slangasek> Installing ttf-mscorefonts-installer as dep of wine
<slangasek> mantiena: ^ in the master bug, that's where the package comes from
<slangasek> this is actually a bug in the wine package, which shouldn't really be recommending a package in multiverse
<Rockj> if Im wondering if something is a bug regarding dhclient-package, I should idle in #ubuntu-bugs and wait for an answer aye?
<dholbach> https://wiki.ubuntu.com/UbuntuOpenWeek Day 4 starting in 11m on #ubuntu-classroom
<jcastro> Keybuk, hey you know we're not doing the little intro bits with the schedule and stuff this UDS right?
<Keybuk> jcastro: no?
<jcastro> it's just going to be "if you need to schedule something, see a track lead"
<jcastro> and people seem to be doing a good job registring blueprints and stuff
<Keybuk> jcastro: sounds fair :p
<ebroder> Is there a way to get the ubuntu-installer to grab udebs from -proposed, or am I stuck doing it by hand?
<mantiena> slangasek: I've got that bug during upgrade Jaunty system without wine, just ttf-mscorefonts-installer
 * hyperair grumbles. cowbuilder is buggy shit.
<Laney> yes
<nxvl> slangasek: are we having key signing party again in Dallas?
<Laney> It doesn't resolve the dependencies most of the time for me so I just leave it alone
<hyperair> Laney: well, it's giving me tonnes of issues with my pbuilderc.
<hyperair> pbuilderrc*
<Laney> not worth it
<Laney> i'd sooner use sbuild
<hyperair> heh
<hyperair> wait, what dependency issues?
<Laney> Cannot install debhelper as it is a virtual package, etc
<ebroder> Sounds like a broken sources.list somewhere
<Laney> works with pbuilder
<maco> debhelper is a virtual package?
<Laney> nope
<Laney> that's what pbuilder says when it can't find something
<hyperair> Laney: yeah, broken sources.list, definitely
<hyperair> Laney: probably because it's shitting around with $DISTRIBUTION
<hyperair> it mixed up my sid sources with my karmic OTHERMIRRORS sources
<hyperair> because it won't preserve $DISTRIBUTION
<Laney> did you use pbuilder-dist?
<hyperair> no, i rolled out my own cowbuilder-dist >_>
<hyperair> but it won't honour my --distribution
<hyperair> nor will it honour my $DISTRIBUTION set on the environment
<hyperair> which is utterly ridiculous
<Laney> well pbuilder-dist passes the sources explicitly
<hyperair> it's unsetting it somehow.
 * Laney shrugs
<hyperair> pbuilder-dist also doesn't allow me to use my own mirror =.=
<kirkland> mathiaz: pitti: ETA on getting the Eucalyptus upload into -proposed?
<mathiaz> kirkland: well - I first need to upload it to -proposed
<mathiaz> kirkland: how is the PPA testing going on?
<mathiaz> ttx: ^^ did you get a chance to review the eucalyptus SRU?
<ttx> mathiaz: PPA ?
<mathiaz> ttx: https://launchpad.net/~mathiaz/+archive/eucalyptus
<mathiaz> ttx: I've CC'ed you on an email to mdz about the avahi/eucalyptus SRU
<Cilyan> didrocks: Hello ! If you're around, I would like to ask you some questions about your packaging of Clutter (related to the "glReadPixels" bug)
<ogra> hmm, funny
<ogra> is anyone here currently listening to music with rhythmbox and would like to test something ?
<hyperair> Laney: correction: pbuilder is buggy shit. it can't handle passing --distribution after --configfile
<hyperair> Laney: which was what cowbuilder was doing
<Laney> heh
<mathiaz> ttx: https://bugs.launchpad.net/ubuntu/karmic/+source/eucalyptus/
<mathiaz> kirkland: ^^
<hyperair> Laney: and so the workaround is to use another env var to pass it in
<Laney> wanna patch pbuilder-dist?
<hyperair> Laney: to do what?
<Laney> work
<hyperair> Laney: i'd patch pbuilder-dist-simple, but i refuse to touch that convoluted crazy python script that is pbuilder-dist
<hyperair> i've looked into it once, really =.=
<hyperair> it can seriously be accomplished in bash, and in a much shorter manner.
<hyperair> and simpler
<ttx> mathiaz: looks good to me
<mathiaz> ttx: ok
<mathiaz> ttx: wrt to the eucalyptus bug list relevant to karmic
<mathiaz> ttx: I were using a tag before right?
<mathiaz> ttx: instead of https://bugs.launchpad.net/ubuntu/karmic/+source/eucalyptus/
<ttx> mathiaz: no
<ttx> mathiaz: the "eucalyptus" tag is for bugs in discussion with upstream
<mathiaz> ttx: well - point being that for bug 460085 you had to reopen a task for the eucalyptus package
<ttx> mathiaz: which may or may not be ablout SRUs
<ubottu> Launchpad bug 460085 in eucalyptus "memory leak; rampart_context not freed (memory leaked per connection)" [High,Confirmed] https://launchpad.net/bugs/460085
<mathiaz> ttx: which is not really true
<mathiaz> ttx: ah ok.
<ttx> mathiaz: bug 460085 also needs a fix on euca side
<mathiaz> ttx: I'm just trying to define the best way to get a list of bugs related to uec that should be fixed in karmic
<ttx> not just on rampart side.
<mathiaz> ttx: ah ok.
<mathiaz> ttx: so https://bugs.launchpad.net/ubuntu/karmic/+source/eucalyptus/ is a good list
<ttx> but yes, "UEC" bugs are more than just eucalyptus
<ttx> euca2ools and rampart have a few extra bugs we need to keep in scope
<mathiaz> ttx: right - do you track these directly in LP?
<mathiaz> ttx: using tags could help - as we can do search on tags under ubuntu/karmic/
<mathiaz> ttx: so we can actually track all the bugs tagged uec (for ex) that are *relevant* to karmic (for SRU purposes)
<ttx> mathiaz: its a little redundant with the karmic nomination, but not completely
<ttx> mathiaz: so that might make sense
<ttx> mathiaz: "uec-karmic" tag ?
<mathiaz> ttx: well all bugs still need to be nominated for karmic
<mathiaz> ttx: just that they get lost in the noise
<ttx> mathiaz: I used to use the ubuntu-server / karmic bugs
<mathiaz> ttx: ubuntu-server/karmic bugs?
<ttx> mathiaz: but signal /noise ratio might go down on that one
<ttx> karmic bugs where ubuntu-server is supervisor
<mathiaz> ttx: right - that doesn't work as expected :/
<mathiaz> ttx: because ubuntu-server is *not* a bug supervisor for ubuntu-server packages
<mathiaz> ttx: ubuntu-server is a bug *contact* for these packages
<mathiaz> ttx: and there isn't a search critiria for bug contacts (which is what is really needed here)
<mathiaz> ttx: this is why a search with ubuntu-server supervisor doesn't give all the expected bugs
<mathiaz> ttx: so a proposal is to use the uec tag and then do a advanced search under ubuntu/karmic/ with the uec tags
<mathiaz> ttx: that why bugs require to be nominated (which is mandatory for SRUs) and we can get an overview that is cross package.
<mathiaz> ttx: that *way*
<ttx> mathiaz: ok, makes sense
<mathiaz> ttx: ok - I'll update the current bugs
<mathiaz> ttx: and send out an email (to ubuntu-devel? ubuntu-server? ubuntu-cloud?) outlining the policy above to track uec bugs relevant for karmic
<ttx> mathiaz: I'd say ubuntu-devel.
<ttx> mathiaz: these tags are for developer use
<Cilyan> bigon: Are you around ?
<kirkland> mathiaz: to answer your ppa-testing question...  my testing went well.  i think it should be pushed to bake in karmic-proposed now
<mathiaz> kirkland:  ok - I'm about to upload it to -proposed
<bigon> Cilyan: yes?
<Cilyan> :)
<Cilyan> I saw you where involved in the packaging of clutter ?
<Cilyan> I'm currently trying to correctly package it on ArchLinux and I'm facing a well known problem with Mesa and the radeon driver (glReadPixels is badly implemented)
<Cilyan> And strangely, Ubuntu is not affected by this bug (whereas OpenSuSE and Fedora are for example)
<Cilyan> So I would like to know If you made some magic on that package or on Mesa to achieve correct support of picking in clutter ?
<mathiaz> bdmurray: hi!
<maco> Cilyan: #ubuntu-x would know best i think...
<mathiaz> bdmurray: is there a page with the official tags used in LP?
<bigon> Cilyan: the clutter pkg doesn't have any patches
<bigon> maybe radeon driver?
<Cilyan> Hmm, in fact it is not provided by the mesa package, I'm having a look on it
<bdmurray> mathiaz: http://wiki.ubuntu.com/Bugs/Tags has some of them but not the "official" ones in Launchpad
<mathiaz> bdmurray: ok - I'm compiling a list of tags used by the server team
<mathiaz> bdmurray: I plan to put it in the Server Team KnowledgeBase (https://wiki.ubuntu.com/ServerTeam/KnowledgeBase)
<bdmurray> mathiaz: the portlet at https://bugs.edge.launchpad.net/ubuntu has the official bug tags (if you disregard all the number ones before bitesize)
<bdmurray> mathiaz: could you maybe put them in Bugs/Tags and use an include on the server team page?
<apw> doko, you about?
<mathiaz> bdmurray: I was thinking about doing something like that (the other way around probably)
<mathiaz> bdmurray: as long as the information shows up in both places, but only maintained at one place
<bdmurray> mathiaz: sure, I actually think that's how some of them work
<doko> apw: ?
<apw> doko, the 4.4.2 compiler have seems to have at least two internal compiler errors when compiling the kernel
<apw> doko what should i be doing beyond filing a bug against gcc-4.4 in LP
<doko> apw: which version, which arch, preprocess source?
<doko> preprocessed even, and how to build it
<apw> amd64 and lpia for sure (which is i386) the 4.4.2-1ubuntu2 upload in lucid
<apw> i've put the snippets which trigger the issue in the bug
<doko> apw: and telling me if gcc-snapshot works. so 4.4.2-1ubuntu1 did work?
<apw> https://bugs.edge.launchpad.net/ubuntu/+source/gcc-4.4/+bug/475450
<ubottu> Launchpad bug 475450 in gcc-4.4 "gcc-4.4 4.4.2-1ubuntu2 __builtin_offsetof and & (address of) seems to trigger "internal compiler error: Segmentation fault"" [High,New]
<doko> apw: it it's a self-contained test case, it fine
<apw> yeah there are two bugs apparently in a similar construct
<apw> one in __builtin_offsetof and one in & (address of)
<apw> i've pared the triggers down the minimum and put them in the LP bug
<apw> i'll go find the ubuntu1 and see if that work
<apw> i am bolloxed without a working compiler in lucid, so let me know what i can do to help
<apw> i can work round the first one in the kereml, but & not workig is a bit of a showstopper
<Cilyan> bigon: thanks for the help, it seems that KMS and DRI2 are needed here
<zul> james_w: can you import apache2 please using your bzr magic
<james_w> zul: queued, should be there in around 20 minutes
<zul> james_w: thanks
<lbrinkma> Can I upgrade to lucid yet?
<pitti> lbrinkma: technically yes, but you really must know what you are doing; if it breaks, you have to keep both pieces
<pitti> lbrinkma: at this point, I think that most of the developers still run karmic (mainly to focus on SRUs, etc.)
<lbrinkma> pitti, I'm running as well. I want to test lucid in a vm
<lbrinkma> how can i performe an update?
<pitti> lbrinkma: we don't have an alpha yet, so install karmic, replace "karmic" with "lucid" in /etc/apt/sources.list and upgrade
<lbrinkma> pitti, I alredy thought that's something like that. Thanks in advanced.
<thebloggu> I am sorry for asking for support in a development channel, but I need to talk to one developer because of the function keys in my asus eee pc 1101HA. Brightness keys simply wont work. gnome-brightness-applet works but fn+f5 and fn+f6 aren't recognized by any of the capturing keybind programs i used. compiz wont catch it, neither wont xev or showkey and xbindkeys -k
<pitti> thebloggu: can you please exercise the steps in https://wiki.ubuntu.com/Hotkeys/Troubleshooting ?
<thebloggu> pitti, sure
<thebloggu> pitti, after killing gnome-settings-daemon and power manager xev continued to report nothing
<pitti> thebloggu: I suppose it doesn't know about the scan codes; you have to run /usr/share/doc/udev/README.keymap.txt
<thebloggu> pitti, i read /usr/share/doc/udev/README.keymap.txt  and tried the steps to identify both the keyboard and the keypress event code
<pitti> (as described on the wiki page)
<thebloggu> codes*
<thebloggu> pitti, tried ti find the broken keycodes with /lib/udev/keymap and none of the special fn keys (besides from numbers and home,end,insert, numlock, etc) work. they wont show up
<thebloggu> pitti, acpi_listen produces output to most fn keys except brightness
<james_w> zul: there's a performance issue somewhere, so that 20 minutes is looking incredibly optimistic right now
<james_w> it's churning, but the ETA may be some time off, in case you are waiting
<thebloggu> pitti, https://bugs.launchpad.net/ubuntu/+bug/429942
<ubottu> Launchpad bug 429942 in acpi-support "ASUS 1101HA brightness hotkeys don't work, generate ACPI errors" [Undecided,Fix released]
<wgrant> lamont: Around today?
<lamont> yeah - fighting with a kernel thing
<wgrant> lamont: Ah. Well, if you have time today, it would be handy to talk about source format 3.0 support on the buildds at some point.
<lamont> wgrant: what all does it require?
<lamont> when do you go offline?  (what tz are you??) <--wgrant
<wgrant> lamont: I'm +11. I go offline somewhere around 1300UTC, normally.
<wgrant> lamont: It requires either a new (Karmic-era) dpkg on all the buildds, or sbuild modified to run dpkg-source inside the chroot.
<wgrant> lamont: Neither is trivial.
<lamont> any chance of backporting just that piece to hardy (and dapper, thank you ppc) versions of dpkg?
<gigabytes> hello
<wgrant> lamont: I'm not sure (I wouldn't have been too concerned about backporting everything, but then I remembered powerpc).
<gigabytes> to write an init script that saves a value on shutdown and restores it at startup, where is a right place to store that value?
<wgrant> lamont: A plain backport of dpkg (with a couple of dependencies) to hardy crashes dpkg-source. Not quite sure why, and didn't have time to look deeply into it.
<gigabytes> a file somewhere... but where? it's not something editable by the user
<wgrant> I daren't even think about dapper.
<lamont> great
<gigabytes> anybody knows?
<gigabytes> alsa scripts do that
<wgrant> lamont: Note that non-ancient-unmaintained-fork-of-dead-fork sbuild runs it inside the chroot.
<lamont> wgrant: runs apt-get install inside the chroot - the source is still fetched outside
<wgrant> lamont: I see it called with CHROOT => 1 here.
<lamont> so... running the source fetch inside the chroot sounds like a good plan
<wgrant> (our sbuild does not, but real sbuild does)
<lamont> "real sbuild" ==?
<wgrant> The one in Debian, that most of the Debian buildds use now.
<lamont> right - migrating towards that one is probably a good idea
<wgrant> Certainly. Will be easier once we get rid of the revolting ddeb and translation hacks.
<wgrant> But we need a solution to this before then, unfortunately :(
<lamont> are we really going to get rid of ddeb and translation hacks?
<wgrant> lamont: The translation hack hasn't been necessary for nearly three and a half years. The ddeb hack will become unnecessary in a month or two.
<lamont> yay!
 * wgrant checks the current sbuild diff that we hold.
<wgrant> Oh, right, I remember this.
<wgrant> We have no version control history for most of the changes, and nobody is quite sure which point of which fork we forked from.
<lamont> "we" might be a bit of an overstatement
<lamont> though the relationship between the version in debian and the version that used to be used on debian buildds is unknown to me
<wgrant> Most of the changes were made before sbuild appeared in the LP tree.
<lamont> yeah - I have that tree in arch, of all things
<lamont> maybe converted to bazaar, almost certainly not in bzr
<wgrant> Oh! That sounds useful.
<lamont> well, except for the arch part. :-p
<wgrant> But arch is easy enough to import.
<lamont> yeah.  'tis arch
<lamont> {arch} even
<lamont> and there might be a hole between there and the lp tree
<wgrant> alternatively, all I would really like is the full Ubuntu diff.
<wgrant> So I can see what needs to be done to open up the possibility to migrate to a stock sbuild.
<lamont> the lp tree should give you that, no?
<lamont> or you need the debian version it's based on?
<wgrant> lamont: I don't think the LP tree goes all the way back to the Debian version. It looks to me like there are changes in between, but I don't know since I can't find a Debian buildd sbuild from that era.
<lamont> right.  so the original debian sbuild that we forked, + top-of-lp, should give you the total diff, yes?
<wgrant> It should.
<wgrant> Do you know which original Debian sbuild that was? It's not anything that was ever in the archive, IIRC.
<lamont> never was in the archive - there was a bit of a "that stuff is crack" schism, and a separate version was maintained from the archive, with totally diff version numbers
<wgrant> Lovely, lovely, lovely.
<lamont> yeah - I'm pretty sure I might have something close lying around
<lamont> will have to dig though
<wgrant> That would be great, thanks.
<wgrant> Who hacks lp-buildd these days?
<lamont> mostly me, though in theory it's trying to be the soyuz guys
<lamont> and there's at least one tweak that hasn't made it back into the tree (EPERM)
<lamont> which I'll get hashed out tomorrow, possibly.  failing that, next week
<wgrant> What is it? I have three other compatibility changes that I need to land soonish.
<lamont> ah, right.  Depends: apt-transport-https
<lamont> and rev 52
<lamont> though if we get the source fetching into the chroot, then we can drop that broken-on-dapper depends, too
<wgrant> True.
<wgrant> So you have a separate bzr tree for this, which is only occasionally copied into RF?
<lamont> well...  historically, the archive has been the revision control history..  I'm new to this whole "it's in LP" thing... note also that there's a bug that it doesn't actually build from source atm, either
<lamont> it needs things that are above the "top" directory for the dpkg-source, and hence dies in copy
<wgrant> daemons/buildd-slave.tac?
<lamont> sounds about right
<wgrant> Right, it's a bit strange that it lives outside.
<wgrant> "the archive" -- there is an internal archive as well? Is that this dapper-cat thing I see in changelogs?
<lamont> yep
<wgrant> I seeeee.
<lamont> mind you, that's mostly because it has things that we can use internally, but can't redistribute, and has no concept of public/private
<lamont> and it's easier to have one archive than 2
<wgrant> Yep.
<slangasek> nxvl: I haven't planned one; would be great if someone else had time to plan it
<slangasek> ... in advance, so we can bring our own paper this time :)
<nxvl> slangasek: yeah, that would be great
<nxvl> slangasek: we still have one week for planning it
<jelmer> /win 20
<ogra> Keybuk, any chance that we get MoM's overview pages back at some point ? while i like merging with bzr i really miss the simple overview MoM gave me
<Keybuk> ogra: no, it's completely screwed up by the v3 packages
<Keybuk> keeps tripping over them
<ogra> :(
<ogra> *sniff*
<ogra> Keybuk, btw, take a look at the disk throughput :-D http://people.canonical.com/~ogra/osiris-karmic-20091105-4.png
<Keybuk> nice SSD, which is it?
<ogra> samsung
<ogra> it's specced with 240MB/s ...
<Keybuk> what's the modprobe taking all the time in the initramfs?
<Keybuk> heh, nice to see we're almost maxing it
<ogra> sadly i didnt get such rates in subsequent boots
<ogra> its rather at 180/190
<ogra> modprobe is getting mad about my touchscreen
<Keybuk> ah
<ogra> it loops several times until it times out
<Keybuk> modprobe doesn't loop?
<Keybuk> do you mean the driver?
<slangasek> Keybuk: how does it trip over them?  There should be no v3 packages in testing today, and couldn't the /current/ set of merges still be made available on the website?
<lamont> dear cryptsetup understading people... when are you around maybe?
<ogra> well, there is a probe loop somewhere
<slangasek> even if importing new ones fails?
<lamont> specifically looking for what I missed on this "install" such that I have to run cryptsetup manually in initramfs in order to have any love
<Keybuk> slangasek: well, there clearly are v3 packages
<Keybuk> one of them begins "a"
<Keybuk> which pretty much screws things up, since it processes alphabetically
<slangasek> in testing?
<Keybuk> I assume so
<Keybuk> I looked at it for about 10 seconds
<Keybuk> the package had extra files in its dsc, etc.
<slangasek> v3 packages have been supported in the Debian archive for a week; I don't see how that could possibly be the case in testing already
<wgrant> There were none in testing yesterday.
<wgrant> The first won't migrate for another three days.
<slangasek> Keybuk: anyway, not having the list of already-known merges available is kinda hamstringing the start of lucid; what breaks by just making the last successful run available at merges.u.c?
<Keybuk> slangasek: the last successful run was in august
<Keybuk> from unstable
<slangasek> hmm
<Keybuk> and I wiped that from the disk
<wgrant> There is always http://qa.ubuntuwire.org/mdt/, although that doesn't show ownership.
<slangasek> Keybuk: where's the MoM code located?
<Keybuk> slangasek: in launchpad
<Keybuk> lp:merge-o-matic iirc
<slangasek> ok
<Keybuk> slangasek: I suspect a large part of the fail is that casey doesn't have an updated dpkg on it
<Keybuk> so it can't unpack them
<slangasek> there shouldn't be any "them" to unpack
<Keybuk> # Default source distrbution and release
<Keybuk> SRC_DISTRO = "debian"
<Keybuk> SRC_DIST   = "testing"
<Keybuk> *shrug*
<Keybuk> oh, it's probably because it has to download unstable too
<slangasek> yes, which is why I want a look at the code to find out exactly which package it's failing with
<slangasek> ah
<Keybuk> otherwise we could never go back to merging from unstable
<slangasek> well, does it have to be able to parse them at that time?
<Keybuk> feel free to rewrite the code so it doesn't ;P
<Keybuk> shouldn't we be using james_w's bzr branches this cycle anyway?
 * Keybuk thought we were
<slangasek> Keybuk: happy to, but MoM was the only index to what *needs* merging
<james_w> hey Keybuk
<slangasek> and who's responsible for it
<Keybuk> slangasek: right, but that index is the last thing it generates
<Keybuk> MoM is not very well written :p
<Keybuk> hmm
 * Keybuk tries something
<Keybuk> slangasek: I've turned off the code that mails patches to the Debian PTS
<Keybuk> that might be the only bit unpacking unstable packages
<Keybuk> if wgrant is right that a v3 package is not due in testing for another few days, it'll give us a few merge runs
<Keybuk> slangasek: could you RT for elmo to upgrade casey to have lynx's packaging chain
<wgrant> Keybuk: ftplib was first. PTS says 6/10 days.
<Keybuk> of course
<Keybuk> this could still fail
<Keybuk> if we have any packages with a base debian version newer than what's in testing
<Keybuk> but I'm hoping it just doesn't generate a merge for those
<slangasek> Keybuk: yep, can do that this evening
#ubuntu-devel 2009-11-06
<Keybuk> slangasek: it's making patches now
<slangasek> woohoo
<Keybuk> don't know whether this is good or not
<Keybuk> next she makes merges
<Keybuk> then cookies
<cowgarden> hi, why is there a new add/remove software dialog? (where are the advantages? I'm just missing the ratings which makes it useless for aimless lurking arround)
<maco> yeah, lots of complaints about lack of ratings. its not done yet ;-)
<maco> !softwarecenter
<ubottu> Sorry, I don't know anything about softwarecenter
<maco> boo!
<maco> cowgarden: https://wiki.ubuntu.com/SoftwareCenter
<cowgarden> but it will come I read from that :)
<cowgarden> thank you!
<cowgarden> 9.10 should boot faster, shouldn't it?
<cowgarden> and how strict is the feature freeze, can I expect smaller features coming through updates or will there be bugfixes fpr 9.10 only?
<Keybuk> cowgarden: 9.10 is done
<Keybuk> out
<Keybuk> finished
<cowgarden> I know
<Keybuk> you can this, because it's now November
<Keybuk> and then it'd be Ubuntu 9.11
<directhex> cowgarden, short version: very limited developer resources, devs like new & shiny, not arguing with the bureaucracy to get backports into old releases
<Keybuk> which would upset people
<Keybuk> ;)
<cowgarden> ok :)
<cowgarden> thank you
<Keybuk> we only update releases with critical bug fixes and security fixes
<Keybuk> (mostly)
<directhex> cowgarden, new features in released releases are Bad(tm) - e.g. SLES10 changed its entire software update management stack twice now since release
<cowgarden> and the "new software for easy application development" which one is that?
<directhex> and their kernels have totally changed how they treat some devices
<cowgarden> %/
<directhex> cowgarden, probably "quickly" - although i like monodevelop personally for such things ;)
<cowgarden> directhex, so which are the "fun, speedy and easy" tools?
<directhex> Keybuk, don't think i can promise you more than a meg (if that) shaved off this release. still, 25% drop between intrepid & karmic
<directhex> cowgarden, "quickly" is what the cool kids are talking about in that context
<cowgarden>  directhex oh, thats the name *laughing*
<Keybuk> directhex: a meg?
<Keybuk> directhex: I'm missing context
<directhex> Keybuk, I think we've pretty much exhausted ways to make f-spot/tomboy smaller on disk. intrepid->jaunty was 6 meg smaller, jaunty -> karmic was 6 meg further still
<Keybuk> oh, I don't care about that ;)
<Keybuk> I just want to see Mono to shared libraries in shared memory properly ;)
<slangasek> Keybuk: how long should the MoM run be expected to take?
<Keybuk> slangasek: usually a week ;)
<slangasek> hmm
<Keybuk> I've short-cutted some bits
<slangasek> heh, ok
<Keybuk> so a few days maybe
<Keybuk> I've never had to restart it based on a whole new distribution before
<slangasek> fwiw, I don't think it would have hurt to pick up where last cycle's unstable left off, assuming the code could handle that (i.e., the possibility of some packages going backwards at the source)
<Keybuk> slangasek: https://merges.ubuntu.com/main.html
<Keybuk> universe looks like it is genuinely days away
<d3matt> hello
<d3matt> anyone know the file format of the initrd.gz file?
<geofft> it's a gzipped cpio archive, but... why?
<d3matt> doesn't appear to be
<geofft> (mkdir /tmp/initrd; cd /tmp/initrd; gunzip < /initrd.gz | cpio -id)
<geofft> er, initrd.img. I assume initrd.gz is the same
<d3matt> I get "not in gzip format"
<d3matt> this is from the 9.10 live cd
<d3matt> tried installing it to a USB key and it's looking to mount /dev/sr0
<d3matt> was gonna dig into the init script but can't seem to find out how to extract the thing
<geofft> I don't actually know if this changed in 9.10 but I'd be surprised. what does the file command say?
<d3matt> date
<d3matt> data*
<geofft> er, you're aware of the magic bootable USB stick creator that uses a live CD, no?
<wgrant> It's even on the live CD.
<d3matt> yea
<d3matt> usb-creator
<d3matt> used the 9.04 one...
<d3matt> I don't **have** to use a usb key, but I kinda like it
<slangasek> Keybuk: yaaaaay thanks
<\sh> moins
<kees> slangasek: why do buildN packages show up in MoM?  shouldn't they auto merge?
<ScottK> kees: They do, but until they are sync'ed they show up
<kees> oh! okay.
<\sh> MOM showing diffs between testing and lucid now? or still sid ?
<ogra> testing
<\sh> ogra, thx mate...starting up the engines ;)
<ogra> :)
<crypt-0> on upgrade fom 9.04> 9.10 : $ amarok
<crypt-0> amarok: symbol lookup error: /usr/lib/libamaroklib.so.1: undefined symbol: _ZTIN6TagLib3MP44FileE
<crypt-0> any idea to what the problem is?
<crypt-0> i have seen it in a mailing list, but no solutions.
<tsimpson> crypt-0: you seem to be missing libtag1c2a (which amarok depends on)
<crypt-0> seem to be  however that is not the prolem.
<tsimpson> well, that's where the symbol is defined
<crypt-0> libtag1c2a is already the newest version.
<tsimpson> then you're missing /usr/lib/libtag.so.1 and or /usr/lib/libtag.so.1.6.0
<crypt-0> (and yes i ran apt-get update)
<tsimpson> which are part of that package
<crypt-0> strange why wouldn it be in the package?
<tsimpson> well libtag1c2a depends on libtag1-vanilla or libtag1-rusxmms
<tsimpson> and the lib is in both
<tsimpson> I guess make sure one of them is installed, should be libtag1-vanilla by default I think
<crypt-0> $ sudo touch /usr/lib/libtag.so.1.6.0
<crypt-0> $ sudo touch /usr/lib/libtag.so.1
<crypt-0>  
<crypt-0> they are both intact.
<crypt-0> libtag1-vanilla is already the newest version.
<nxvl> hey, got some stupid packaging question
<tsimpson> "nm -D /usr/lib/libtag.so.1.6.0 |grep _ZTIN6TagLib3MP44FileE" should output something like "0008e88c V _ZTIN6TagLib3MP44FileE"
<nxvl> using cdbs and patchsys-quilt, what goes first, the patching, or the pre-build?
<crypt-0> i dont know why the egacy"version of amarok is not supported.
<crypt-0> 0008e88c V _ZTIN6TagLib3MP44FileE
<tsimpson> nxvl: patch, then pre-build (configure et all)
<crypt-0> and by the way, the upgrade broke  the wine package , however i do not care for it.
<nxvl> tsimpson: mmm, ok, thank you
<tsimpson> crypt-0: make sure "ldd /usr/bin/amarok" shows the the libs under /usr/lib
<tsimpson> crypt-0: amarok (and wine) work here
<siretart`> morning
<nxvl> siretart`: night :D
<siretart`> :)
<nxvl> tsimpson: just re-checked, and it's the other way, first pre-build, then patch
<nxvl> :S
<tsimpson> it should be the other way round
<tsimpson> unpatch should be before clean
<nxvl> dunno, i'm trying to run some code in pre-build, that needs a patch to be applied and getting en error
<nxvl> just checked and i get the code running before the patch is applied
<nxvl> asac: ping
<crypt-0> tsimpson, "ldd /usr/bin/amarok" shows all the libs
<tsimpson> all in /usr/lib too?
<crypt-0> http://pastebin.com/m63f5f5b
<crypt-0> mostly under /usr/lib....
<tsimpson> libtag.so.1 => /usr/local/lib/libtag.so.1
<tsimpson> not in /usr/lib ;)
<pitti> Good morning
<geser> Guten Morgen pitti
<crypt-0> $ ls /usr/lib/|grep tag
<tsimpson> crypt-0: /usr/local/lib comes before /usr/lib when searching for libraries
<crypt-0> http://pastebin.com/m2f2eb8a0
<tsimpson> so /usr/local/lib/libtag.so.1 is being picked up before /usr/lib/libtag.so.1
<dholbach> good morning
<ikonia> morning
<slangasek> kees: they should, dunno
<slangasek> kees: which package (to confirm sync-source /is/ merging it)?
<dholbach> james_w: you think we can move the DistributedDevelopment/Merging to UbuntuDevelopment/Merging?
<dholbach> james_w: or at least add it in there?
<kees> slangasek: specifically sharutils, but there are a ton in universe -- I will assume it's just not caught up yet
<slangasek> kees: well, autosyncing is happening very slowly for the first pass; I have to keep restarting it because of all the orig.tar.gz mismatches that haven't been declared in the blacklist file yet
<kees> ah, fun
<kees> the testing vs unstable thing is going to throw me for a bit too
<slangasek> someone definitely goofed somewhere, for the packages to be in a needs-sync state, but with mismatched orig.tar.gz that's not already documented in the blacklist from last time
<dholbach> oh and james_w:
<dholbach>  _   _    _    ____  ______   __  ____ ___ ____ _____ _   _ ____    _ __   ___
<dholbach> | | | |  / \  |  _ \|  _ \ \ / / | __ )_ _|  _ \_   _| | | |  _ \  / \\ \ / / |
<dholbach> | |_| | / _ \ | |_) | |_) \ V /  |  _ \| || |_) || | | |_| | | | |/ _ \\ V /| |
<dholbach> |  _  |/ ___ \|  __/|  __/ | |   | |_) | ||  _ < | | |  _  | |_| / ___ \| | |_|
<dholbach> |_| |_/_/   \_\_|   |_|    |_|   |____/___|_| \_\|_| |_| |_|____/_/   \_\_| (_)
<dholbach>                                                                                
<pitti> ooh! /me hugs james_w; happy birthday!
<seb128> james_w, happy birthday
 * dholbach hugs james_w too
<\sh> james_w, congrats :) and nice work on the merging bzr stuff
<nxvl> james_w: Happy Bday!
<nxvl> cjwatson: happy bday to you aswell!
<Laney> greetings to all oldies
<siretart`> james_w: congratulations from my side as well!
<jpds> james_w, cjwatson: Happy birthday!
<davmor2> james_w: happybirthday dude
<davmor2> oh and cjwatson
<siretart`> oh collin as well? Congrats!
<wgrant> slangasek: ISTM that sync-source.py shouldn't really crash when it finds a mismatch.
<slangasek> wgrant: well, hmm; that's an idea :)
<dholbach> happy birthday cjwatson! :)
<mjr> where're the gnome-panel default applets configured?
<geofft> /usr/share/gconf/defaults, I believe, which update-gconf-defaults turns into /var/lib/gconf/debian.defaults
<mjr> right, there...
<mjr> oh, debian.defaults indeed, I'll just mention that at least on 8.10 it appears to generate debian.defaults as world-unreadable if umask is 077, probably not ideal for when system umask is set that way...
<pitti> did anyone else already use summit.u.c.? I can't dnd blueprints to the per-track view, just to the per-day view (but there I don't know which room to take)
<geofft> mjr: that seems poor. but then, I'm vaguely impressed if that's the only thing that breaks
<ion> dpkg probably should use umask 022 for all maintscripts.
<Chipzz> happy birthday cjwatson! :)
<vrodic> hello guys. I'm thinking about joining in for lucid. by testing the distro on various hardware at some point. which point would that be? during the developer sprint? earlier?
<vrodic> where to propose additional drivers/pieces of firmware?
<pitti> vrodic: the best time for testing are the alpha and beta releases
<vrodic> pitti: thanks. i have another question about drivers. some hardware doesn't work without firmware, however, nowhere in the new 9.10 GUI can I find information that I should install a certain firmware package. are there any changes planned for that?
<pitti> vrodic: we have some coverage in system -> admin -> hardware drivers
<dholbach> the seahorse-agent bug is getting a bit out of control :)
<dholbach> bug 467175
<dholbach> err
<ubottu> Launchpad bug 467175 in seahorse-plugins "seahorse-agent assert failure: ERROR:iop-profiles.c:606:IOP_generate_profiles: assertion failed: (obj && (obj->profile_list == NULL) && obj->orb) (dup-of: 429322)" [Undecided,New] https://launchpad.net/bugs/467175
<ubottu> Launchpad bug 429322 in seahorse-plugins "seahorse-agent assert failure: ERROR:iop-profiles.c:606:IOP_generate_profiles: assertion failed: (obj && (obj->profile_list == NULL) && obj->orb)" [High,Confirmed] https://launchpad.net/bugs/429322
<vrodic> pitti: i know, but not about this particular broadcom b43 wlan card
<vrodic> pitti: i'm not sure if there is a system to make the kernel notify the userspace about missing firmware, other than parsing the kernel logs, which seems ugly
<pitti> there is no hotplug support yet
<pitti> you have to call it manually, or have the device plugged in after first installation
<pitti> s/after/at/
<vrodic> pitti: this is not hotplug, this is a device that sits in the system all the time
<vrodic> regarding the keychain management, i got bitten by that and i think that the keychain dialogs should include a "don't ever ask me for a password for this type of operation again"
<vrodic> pitti: do you understand my scenario?
<pitti> vrodic: yes, but not the details why it fails for you; please run it once and do "ubuntu-bug jockey-gtk", this will attach the necessary debug information
<vrodic> pitti: does this command need the network? should I remove the firmware files before i do this? because I've got it working by manually installing b43-fwcutter package
<pitti> vrodic: ubuntu-bug needs network, yes; jockey needs network for downloading the package and firmware
<vrodic> pitti: okay, should i then remove the b43-fwcutter package, and run ubuntu-bug jockey-gtk? i'll connect it with ethernet cable
<pitti> vrodic: that, and /lib/firmware/b43
<pitti> vrodic: if the firmware is present, the driver will be shown as "enabledZ"
<pitti> vrodic: but if your problem is that the driver doesn't appear at all in jockey, you don't need to remove anything
<vrodic> okay, i'll do it now and let you know
<pitti> vrodic: it should just show it as "enabled" for you
<vrodic> pitti: the driver appears in jockey, but after i manually install it :)
<pitti> vrodic: ok, then please remove firmware and package
<vrodic> doing that now.
<vrodic> pitti: alright i cant reproduce it anymore, maybe it got fixed when i did apt-get update, or where does jockey store the driver/hardware database?
<geofft> I'm kind of disappointed patches.ubuntu.com isn't clever enough to compare firefox to iceweasel
<dholbach> geofft: fix it: https://code.launchpad.net/merge-o-matic :)
<pitti> vrodic: immediately after installation you won't see it; you first need to do an apt-get update (or wait until the cron job does it)
<pitti> vrodic: that's a known bug
<vrodic> pitti: okay great, where can i vote for it ?:)
<vrodic> or whats the bug number?
<pitti> vrodic: bug 439530
<ubottu> Launchpad bug 439530 in jockey "Does not offer drivers when packages are not available" [Medium,Triaged] https://launchpad.net/bugs/439530
<vrodic> thanks
<pitti> siretart`: do you want to merge cryptsetup for lucid? (I need a never version for proper DK-Disks support; our 1.0.6+git snapshot doesn't yet support proper UUIDs)
<pitti> or shall I look into merging it?
<siretart`> depends how fast you need it. If you can do it before monday, please
<siretart`> go for it
<pitti> ah, I meant "by alpha-2" or so :)
<pitti> I'm not even running lucid yet
<siretart`> I've decided to participate early, and already upgraded my notebook to lucid
 * pitti still needs to do some karmic SRUs
<siretart`> I hope this wasn't a bad decision :)
<pitti> siretart`: apw warned that the current lucid kernel has some serious ext4 corruption issues
<pitti> siretart`: (and the fixed one doesn't build because of a gcc regression)
<pitti> I didn't hear other reports yet
<siretart`> the karmic kernel is pretty unusable for intel users. prety bad flickering
<siretart`> so I'ver reverted to the karmic kernel
<siretart`> for now
<apw> siretart`, the ext4 issues are on crash, data can be lost.  the next lucid kernel has the fix but i can't build it
<ttx> james_w: trying bzr-merge, I run into "bzr: ERROR: Unknown target distribution: lucid" when trying to mark-uploaded
<vrodic> siretart`: what intel chip is not usable on karmic? it works for me on 915 and 945
<Keybuk> slangasek: around?
<cjwatson> nxvl,jpds,davmor2,siretart`,dholbach,Chipzz: thanks :)
<pitti> hey cjwatson; happy birthday!
<cjwatson> ta
<vrodic> where can i see all nominated bugs for lucid?
<Keybuk> cjwatson: sit-rep on MoM: looks like main is up to date
<Keybuk> and universe is still catching up
<Keybuk> main should be refreshing though
<pitti> ooh, MoM back? thanks so much!
<cjwatson> neat, thanks
<Keybuk> the stuff that sends patches to Debian is down though
<Keybuk> and probably will be until the whole v3 nightmare is figured out
<Keybuk> now that LP is doing per-upload patches, it may be much simpler to port it over to that
<zul> james_w: can you import bacula as well?
<cjwatson> Keybuk: I still haven't grasped why 3.0 is a problem, aside from having a new enough dpkg-dev - does it not just use dpkg-source to unpack the packages?
<Keybuk> cjwatson: that may be the only problem
<Keybuk> I just haven't looked
 * cjwatson nod
<cjwatson> s
<Keybuk> also obviously a package converting from v2 to v3 might have an enormous diff, across which merge-o-matic output isn't useful
<Keybuk> but that's no worse than cdbsing a package, etc.
<Keybuk> cjwatson: unrelated
<Keybuk> I was having a bit of a think
<Keybuk> you know GRUB2 has that whole "search" thing?
<Keybuk> does it put the result of that anywhere
<Keybuk> (other than being the filesystem it looks for kernels on)
<cjwatson> Keybuk: it lands in GRUB's 'root' environment variable (or whichever variable you nominate), although right now I don't believe it passes that on to the kernel
<cjwatson> and of course the device name inside GRUB has little to do with anything Linux understands
<cjwatson> I imagine you could stick grubroot=${root} on the 'linux' line if you wanted to
<Keybuk> yeah, that's what I was thinking ;)
<Keybuk> if GRUB has already done the hard work, we could bypass initramfs entirely
<cjwatson> what would it be useful for?
<cjwatson> ah
<Keybuk> (non-separate /boot obviously)
<Keybuk> but it's a nice way of bypassing the initramfs without hardcoding root=/dev/sda1 ;)
<cjwatson> device naming would probably be a killer
<Keybuk> hmm?
<Keybuk> if you could do root=${grubroottolinux} that'd be fun ;P
<cjwatson> enumeration won't be the same
<cjwatson> if there's one disk it's easy, obviously :)
<Keybuk> wouldn't the device tree stuff partially solve that?
<cjwatson> I confess I haven't looked at that
 * Keybuk wonders what happens if he phones evand :p
<evand> My iPhone melts.
<Keybuk> such fun ;)
<evand1> argh
<evand1> faulty cable, which they can't replace until *the 16th*
<Keybuk> evand1: but you're back online now?
<evand1> yeah, that's the confusing part
<evand1> I imagine not for long
<evand1> as it's been up and down the past few days
<siretart`> vrodic: I have a GM945, and with the current lucid kernel, I get spontanous but very annoying flickering
<siretart`> vrodic:  sometime the screen becomes totally dark, and I need to suspend/resume the laptop to get the screen back
<siretart`> very strange
<vrodic> siretart`: i'm on debian 2.6.32-rc5 kernel, but i've briefly used karmic without problems. my mothers laptop with 915GM works fine on karmic too. lucid probably has 32-rc kernel with newer intel drm that has some bugs. my 32-rc5 has s2ram broken
<vrodic> it's not really that strange that rc version of the kernel has issues, especially if intel drm is concerned
<maco> yep -32 is not so happy on my 965 either
<astechgeek> stupid question will visual basic work with ubuntu
<astechgeek> i got my java stuff working
<Chipzz> astechgeek: ask on #ubuntu; and next time, pls read the topic of a channel before asking random questions
<maco> no
<astechgeek> where would be the app development channel?
<maco> AFAIK, there isnt one
<Chipzz> there are various channels like #perl etc for various programming languages, but none of those are ubuntu-specific
<astechgeek> okay well then I guess thats where I need to be thanks
<slytherin> Can someone help me isolate this problem. I was upgrading my laptop yesterday to karmic using update-manager the machine rebooted halfway through upgrade and was in unbootable state (temporarily). How can I find out at the package that caused the problem?
<kklimonda> where does sudo dependency in "bare" ubuntu install (for example the one created by debotstrap for pbuilder) come from?
<jpds> kklimonda: ubuntu-minimal package?
<kklimonda> hmm.. ubuntu-minimal is pulling it in..
<kklimonda> jpds: yeah, looks like it
<superm1> slangasek, re the fix to bug 441638, i suspect that this will cause some problems with the DKMS auto build of nvidia or fglrx when necessary.  if DKMS isn't done building by the time gdm tries to start, it wont try again I suspect
<ubottu> Launchpad bug 441638 in gdm "upstart job keeps restarting a dying gdm" [High,Fix committed] https://launchpad.net/bugs/441638
<superm1> only solution that comes to mind will be to convert dkms to an upstart job and emit graphics-device-added or something of that nature
<kklimonda> Is /dev/.blkid.tab only created when user uses "blkid" (or some program uses libblkid1) ?
<kklimonda> shouldn't it be created empty at "start" so /etc/blkid.tab is pointing to something? right now it's a broken symlink before /dev/.blkid.tab is created.
<popey> is there a way to grab the data that "ubuntu-bug foo" captures for manual attachment to a bug, where a machine has no net connection?
<popey> there is nothing in /var/crash btw
<pitti> popey: for a bug or a crash report?
<popey> a bug
<pitti> popey: "apport-cli packagename", and select "save report", then move the .apport file to another computer and doubleclick on it
<popey> ah awesome
<pitti> or say "report" and say "no" to open web brwoser, and c&p the URL
<popey> thats great, thanks very much!
<pitti> ah, no, you couldn't upload the blob then
<pitti> so, first method
<pitti> the second is nicer for servers with network, but no fancy browser
<gigabytes> hello
<gigabytes> anybody from the mactel support team here?
<gigabytes> I've asked some days ago to join the launchpad team but no response yet
<pitti> bigon: would you mind applying http://launchpadlibrarian.net/31716020/gupnp-igd_0.1.3-0ubuntu2_0.1.3-0ubuntu3.diff.gz in Debian (enable test suite) and upload, so that we can sync?
<Caesar> slangasek: you got a minute to talk about PAM or are you up to your eyeballs in post-release stuff?
<bigon> pitti: it's already done in the git branch of gupnp-igd pkg but the test fails in debian with last version of gupnp
<_jer_> Hey all. Just wanted to say thank you. 9.10 was the version that tipped me from "ubuntu on side machines" to "ubuntu is now my primary os". You guys did an amazing job.
<ziesemer> Can someone help me with a casper issue?  Had it working great on a USB drive.  However, I wanted to clean things up and move everything into a /ubuntu-live subdirectory.  My boot options are /ubuntu-live/casper/vmlinux boot=casper live-media-path=/ubuntu-live/casper .  This works great, but now fails with "persistent".
<ziesemer> I get a "mounting /dev/sda1 on /cow failed: Device or resource busy".
<ScottK> ziesemer: Support is in #ubuntu.
<ziesemer> Including devel support?
<ziesemer> I see this is coming from initrd/casper, using the return path from find_cow_device in casper-functions.
<ziesemer> I'll try at #ubuntu, thx.
<jcastro> mdke, 15 minute warning!
<mdke> jcastro: thanks
 * lamont thinks bug 476935 deserves a fix
<ubottu> Launchpad bug 476935 in squid "Massively parallel builds make for very unhappy buildds" [Undecided,New] https://launchpad.net/bugs/476935
<crypt-0> amarok  issues over here
<crypt-0> $ amarok
<crypt-0> amarok: symbol lookup error: /usr/lib/libamaroklib.so.1: undefined symbol: _ZTIN6TagLib3MP44FileE
<slangasek> Caesar: PAM> what's up?
<ScottK> lamont: I think Prozac for the buildds.
<lamont> ScottK: ??
<ScottK> lamont: Since they are massively unhappy
<lamont> heh
<lamont> I'd prefer to address the root of the problem... apparently the default make -j value on armel is b0rked because /proc/cpuinfo is totally diff from the rest of the architectures, and make doesn't notice it.  that, or the default make -j value really is "infinity"
<jdong> lamont: the latter is true
<lamont> jdong: that was what I thought - we should really fix that to be NCPU*2 or NCPU+1 or some such
<lamont> because "all of them" is just plain F*^*&^)^&_ING STUPID
<jdong> If there is nothing looking like an integer after the `-j' option,
<jdong> there is no limit on the number of job slots.
<jdong> that's from info make
<lamont> yeah - and it's flawed by design
<jdong> lamont: totally agree with you
<jdong> but is it really a Ubuntu-appropriate thing to do to "fix" it?
<lamont> remember to patch the info docs when we patch the source. :-)
<jdong> HAHAHA
<jdong> and forward it upstream!
<lamont> mebbe I'll go pester manoj about it
<lamont> oh, always push upstream
<slangasek> lamont is a pusher robot
<slangasek> here to push upstream down the stairs
<lamont> slangasek: only if there are no witnesses, you know that
<lamont> slangasek: are there stairs at your house? :-D
<Laney> I AM PROTECTED!
#ubuntu-devel 2009-11-07
<lamont> Laney: we can take you to a place where stairs are.  Say, maybe, Dallas. :-p
<lamont> but ya' gotta be upstream before you have any worries
<lamont> well, upstream, or slanagasek
<lamont> slangasek even
<lamont> wandering, slow response
<slangasek> superm1: what mythtv-related package in mythbuntu is going to be calling pam_open_session() ? (bug #287715)
<ubottu> Launchpad bug 287715 in pam "Do not create CK sessions for cron and other system sessions" [Medium,Fix released] https://launchpad.net/bugs/287715
<JanC> meh, seems like all the binary Canon printer/multifunctional drivers as provided on Canon's site won't install anymore, due to how they depend on libcupsys2 plus version number  :-(
<crypt-0> amarok: symbol lookup error: /usr/lib/libamaroklib.so.1: undefined symbol: _ZTIN6TagLib3MP44FileE
<geofft> didn't you say that yesterday?
<crypt-0> yes and it never got fixed.
<tsimpson> crypt-0: I told you, it's loading /usr/local/lib/libtag.so.1 rather than the one in /usr/lib
<tsimpson> you have some custom-built library in /usr/local.lib which is not the one amarok expects
<crypt-0> so what commads can i drop to fix it?
<crypt-0> sudo rm /usr/local/lib/libtag.so.1
<crypt-0> worked
<crypt-0> thnks
<crypt-0> sorry for asking again
<crypt-0> *thanks
<JanC> and Canon flat out refuses to update them...?!
<m4t> anyone know rhythmbox dbus bindings?
<m4t> methods/routines whatever
<m4t> actually...http://svn.gnome.org/viewvc/rhythmbox/trunk/shell/rb-shell-player.xml?view=markup
<Guest10506> ubuntu does not have xorg.conf anymore?
<ScottK> Guest10506: In most cases not.  Upstream did away with it.
<Guest10506> ScottK, any idea how to add a resolution then
<ScottK> Guest10506: If your gui tools won't help you, use xrandr (see the man page), but help is in #ubuntu
<Guest10506> no one in there has any idea
<Guest10506> xrandr giving me errors
<ScottK> That doesn't make this a support channel.
<ScottK> You might try #ubuntu-x
<Guest10506> yea no one in there
<Guest10506> thanks
<superm1> slangasek, you are thinking of bug 445953
<ubottu> Launchpad bug 445953 in consolekit "shutdown asks for password with only 1 user logged in" [Low,Confirmed] https://launchpad.net/bugs/445953
<slangasek> superm1: not by name, but I guess that's related, yes. :)
<superm1> slangasek, mythbackend does this as it runs as the 'mythtv' daemon user, as well as several cron jobs that run as this same user
<superm1> and they actually need to run as the user, not just the uid because they need a proper $HOME
<slangasek> superm1: ehm, I think that's an artificial distinction (regarding su as "run as the user")
<slangasek> superm1: start-stop-daemon + a wrapper script to set $HOME would achieve this
<superm1> start-stop-daemon in an upstart job?
<slangasek> oh, is it upstarted?
<superm1> Yeah
<slangasek> well, start-stop-daemon should work in an upstart job too
<superm1> http://bazaar.launchpad.net/~ubuntu-mythtv/mythtv/mythtv-fixes/annotate/head:/debian/mythtv-backend.upstart
<slangasek> s-s-d is part of dpkg, not sysvinit
<superm1> but read keybuk's comment from that bug  (#14), this still sounds like it's a deficiency of consolekit
<slangasek> no, "they're non-interactive sessions" - it's not consolekit's fault for not knowing you're using su noninteractively
<slangasek> the normal use of su is interactive, and the su PAM config is configured that way intentionally
<slangasek> s-s-d seems to fail at using -u $USER to set the uid, though; hmm
<slangasek> oh, there we go; -c
<chenillen> hi there
<Caesar> slangasek: I wanted your opinion on http://sourceforge.net/tracker/?func=detail&aid=2892189&group_id=6663&atid=106663
<ubottu> Error: <Bugtracker.plugin.Sourceforge instance at 0x292a878> bug 2892189 not found
<jdong> LOL
<ebroder> That's /awesome/
<Caesar> That bug, or ubottu's handling of it?
<ebroder> The latter
<wgrant> SF.net changed their URLs and pages, so ubottu is confused nowadays.
<chenillen> anyone here fixed the zlib php5 bug in 9.10?
<slangasek> Caesar: ah yes
<slangasek> Caesar: I know nothing about netgroups; you've cited your sources though, so if no one else speaks up with a counterargument, I'm certainly willing to push a revert of that change
 * slangasek wonders where notifications of new bug reports on SF go :P
 * wgrant eeps a bit at today's format 3.0 adoption jump of 11 packages.
<ScottK>    All the cool kids are doing it.
<wgrant> SleepIRCing again, are we?
<Caesar> slangasek: cool
<Caesar> I would appreciate that
<ScottK> wgrant: Yeah.  Insomnia is 'fun'
<wgrant> ScottK: :(
<TerminX> anyone getting broken kernel builds with gcc 4.4.2-1ubuntu3?
 * TerminX posts http://ubuntuforums.org/showthread.php?t=1317856
<TerminX> guess I could try gcc from sid just to see what happens
<sivang> pitti: ping
<TerminX> ah, yeah, gcc from sid seems to work
<sivang> pitti: how are you my dear old freind ?
<TerminX> guess the lucid toolchain is broken in some way at the moment
<naftilos76> Hi everyone, it is soo unfortunate that 9.10 has some serious issues! Firefox keeps crashing and Evolution crashes as soon as i try to open a video or OO attachment! Any temp solutions around?
<janisozaur> i want to create two versions of some algorithms and benchmark it one against the other. i'm interested solely in the time it takes to execute the algorithm, i.e. without initialization time, user input and so on. what should i use to check the time it took to execute a piece of code? would rdtsc be sufficient, given it will be multi-thred/-core application or is there any better alterantive?
<maco> janisozaur: the "time" command? though im not really sure this is on-topic for this channel...
<janisozaur> maco: where should i ask then? time() returns unix_time which is seconds sine 1/1/1970, too small precision
<janisozaur> maco: oh, you mean command
<janisozaur> maco: well it's even less suited to this for the reasons I stated above
<maco> maybe #C?
<maco> if thats the langauge you're operating in
<maco> as /topic sas Development of Ubuntu (not support, not app development on Ubuntu)
<maco> *says
<om26er> after install ubuntu on acer aspire one memory card you cannot boot until you insert you memory card in a usb card reader and then add modules to the initrd. thos modules are mmc_core mmc_block sdhci sdhci-pci. there are many tutorials online but if in lucid lynx these modules are inserted in the intitrd that would be great. and also in which package name i can report this at LP. linux package?
<ilil> hi all! one question about new packages and Debian Import Freeze: are new packages from debian-multimedia.org auto imported too?
<ilil> my app cant be in Debian due to mjpegtools dependence, so it is in C.Marillat repository
<ScottK> ilil: Not automatically
<directhex> not automatically. and many packages in  that repo are of poor quality, so i'd hope the packages are manually proof-read before syncing
<ilil> ok, and how to start including in ubuntu
<ilil> ?
<directhex> "requestsync" command files appropriate bug
<ScottK> directhex: I think for debian-multimedia you have to make the sync request manually
<directhex> oh, true
<ilil> just to file bug "sync" in launchpad?
<ScottK> ilil: Yes and then subscribe ubuntu-universe-sponsors to the bug.
<ilil> ScottK: ok, thanks
<ScottK> TheMuso: I'd appreciate it if you would have a look at https://launchpad.net/ubuntu/+source/qt4-x11/4:4.6.0~beta1-1ubuntu1/+build/1328648 - I think "ld terminated with signal 11 [Segmentation fault]" is not a good thing ....
<geser> soren: if you're in sponsoring mood: bug #477491
<ubottu> Launchpad bug 477491 in gnupg2 "Merge gnupg2 2.0.13-1 from Debian testing" [Undecided,New] https://launchpad.net/bugs/477491
<soren> geser: Added to my todo list for Monday.
<bluefoxicy> lol
<bluefoxicy> farmville crashed X
<Chase_> I'm trying to run debuild, but when I do I get "Unmet build dependencies"
<Chase_> I'm trying to rebuild the xserver-xorg-core package
<Chase_> the unmet deps seem to be all x related, so how do I get the build deps?
<maco> sudo apt-get build-dep xserver-xorg-core
<Chase_> maco, thanks!
<Chase_> maco: does that install the build deps onto my system itself?
<Chase_> or just download them so they may be installed in the fakeroot when building?
<Chase_> are there instructions somewhere on how to add a patch to a package?
<Chase_> I've done: apt-get source xserver-xorg-core
<Chase_> then I patched the source, put the patch in debian/patches and in the debian/patches/series file
<Chase_> I've copied the orig tarball into the top dir of the source
<Chase_> but when I run debuild, it errors out with:
<Chase_> dpkg-source: error: cannot represent change to xorg-server-1.6.4/xorg-server_1.6.4.orig.tar.gz: binary file contents changed
<maco> Chase_: it installs them on yours
<maco> Chase_: the tarball doesnt go inside the source...
<maco> the .dsc the .diff.gz and .orig.tar.gz should all be at the same level
<Chase_> maco, I need to create a new diff.gz file though
<Chase_> I thought debuild -S would eventually do that
<maco> Chase_: you might want to try pbuilder to automate chroot/fakeroot/getting build-deps/building/etc
<maco> yes it does
<maco> but your .orig.tar.gz shouldnt go *inside* the source
<Chase_> where should it go?
<maco> next to it
<Chase_> and how do I tell it where it is?
<maco> it knows to look backwards one directory
<Chase_> ok
<maco> Chase_: make sense?
<Chase_> maco, I think I've got everything working now
<Chase_> yes
<maco> great :)
<Chase_> maco, so I'm a little confused by the patching process
<Chase_> I see some patches in debian/patches
<Chase_> so I figured the diff.gz file wouldn't include any patches against the source itself
<Chase_> but diff.gz includes patches against the source AND patches inside debian/patches that seem to be waiting to be applied
<ebroder> Right - the .diff.gz is /everything/ that's different from the .orig.tar.gz
<ebroder> The debian/patches directory is just used so that patches can be separated from the source in the unpacked package
<BenC> Chase_: patching the stock source and using debian/patches/ is the wrong way to go...should use either one or the other
<ebroder> Sure, but that's a convention, not something enforced by the packaging format. It's important to know the difference
<Chase_> yeah, I understand, but my issue is I'm seeing the ubuntu package having it both ways
<BenC> correct, but still worth pointing out :)
<Chase_> so which way should I be doing it?
<BenC> I'm jumping in the middle, so I might be making things more confusing
<BenC> Chase_: if debian/patches/ exists already, then go with that
<Chase_> ok
<BenC> Chase_: if it's an ubuntu specific patch, then name the patch file something that shows that, and try to make it so it gets applied last to help later patching efforts
<BenC> like calling it 99_ubuntu_xxxx.diff or whatever
<Chase_> it's not ubuntu specific
<Chase_> it's a crash bugfix, and I want to make a package to test it out
<Chase_> I'm actually not seeing where the patches are applied...
<BenC> Chase_: then keep the naming scheme of the original package
<Chase_> from debian/patches
<Chase_> yeah
<BenC> Chase_: it's probably something like dpatch or a similar packaging tool that handles it
<BenC> Chase_: check debian/control build-deps for what packaging tool it is using
<Chase_> I tried building it, and it patched it anyways
<Chase_> so I guess it works
<ebroder> Chase_: You probably shouldn't add a new patch as 99_ something - it makes it hard to add more patches later
<Chase_> ebroder, what should I be doing?
<ebroder> Put it just after the patches that are already there
<Chase_> you mean in the series file?
<Chase_> if I make a new version of the xserver-xorg-core package and I want to upload it into my own lp ppa, should I just increase the ubuntu* number?
<Chase_> making it -ubuntu5 instead of -ubuntu4
<jbicha> Chase_: it would be better to name it -ubuntu5~ppa1 as discussed at https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage
<Chase_> jbicha, thanks for the pointer
<tag> This bug has been blocking me for some time :-( https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/463199
<ubottu> Launchpad bug 463199 in sun-java6 "java 6 segfault" [Undecided,New]
<tag> I'm unable to recreate it just using catgets()
<nxvl_> geser: i just updated gnupg debdiff
<nxvl> geser: i indeed forgot to remove those entries, even when i removed that from the source since they were conflicting :P
#ubuntu-devel 2009-11-08
<cellofellow> how do I see the futon interface for my instance of desktop-couch? There used to be a ~/.local/share/desktop-couch/couchdb.html file but that's gone.
<cody-somerville> Is it possible to create lucid chroots yet? I'm getting: diff: PreDepends: diffutils but it is not installed
<gnomefreak> cody-somerville: diff was held back because it needed to add packages (if that is what the above means)
<gnomefreak> install it directly and it installs
<gnomefreak> trying now
<lamont> Nov  7 18:02:11 rover3 avahi-daemon[1069]: Invalid query packet.
<lamont> Can I have a little more detail please, avahi?
<gnomefreak> cody-somerville: i ran into it just run apt-get -f install and it fixes it
<jdong> is there a decent way for per-user upstart jobs
<jdong> like what OS X / launchd allows?
<jdong> I'd like a per-user service to respawn when it crashes, and figured while I could write a script to do that, it'd be cooler if the user had control over it
<ion> Itâs in TODO. :-P
<jdong> ion: yay? ;-)
<ion> Dunno wherher Keybukâs planning to implement that for 0.10 or after.
<maco> planning for 2100 already? O_O
<JanC> it shouldn't be too difficult to add that
<ramblagir> Is there a development tools CD image somewhere? I want to install some development tools on my Ubuntu computer but it's not connected to the internet.
<salty-horse> after upgrading to 9.10, wireshark no longer has a "run as root" desktop file. is this on purpose? (I think ScottK is the packager)
<ScottK> salty-horse: It was an intentional change by Debian or upstream, I don't recall.
<salty-horse> what am I supposed to do with wireshark without root? should I give my desktop user the necessary  permissions?
<ScottK> I guess open a shell and gksudo or kdesudo wireshark.
<Laney>    * removed wireshark-root.desktop to discourage running Wireshark as root
<salty-horse> Laney, thanks. I didn't find it while looking through https://launchpad.net/ubuntu/+source/wireshark/+changelog
<superm1> it doesn't help though that significant parts of the tool need root
<dtchen> superm1: right, different distros have taken approaches like giving users the necessary caps and restricting them via selinux, smack, etc.
<dtchen> hyperair: WRT cracking and ppc, yes, it's a known issue, and it doesn't just affect ppc. However, it's unclear whether it's a driver issue, a library issue, or a PA issue
<dtchen> crackling*
<hyperair> dtchen: er what?
<dtchen> hyperair: please file a bug (affecting linux -- ubuntu-bug alsa-base and then retriage it to affect linux)
<dtchen> hyperair: sorry
<hyperair> wait, what's this about cracking?
<hyperair> and ppc?
 * hyperair attempts to understand
<dtchen> hyperair: finger-rot. It was supposed to be addressed to slytherin.
<hyperair> aah
<hyperair> okay
<MattJ_> Is there a way to see a human-readable list of patches that have been applied to a package in Ubuntu, specifically libssl in my case
<MattJ_> ?
<ion> http://patches.ubuntu.com/o/openssl/
<djsiegel1> pitti: hello
<djsiegel1> pitti: was beeping improved in karmic? it seems to be, and I'd like to mark bug #77010 fixed
<ubottu> Launchpad bug 77010 in hundredpapercuts "Overuse of system beep without volume control" [High,Confirmed] https://launchpad.net/bugs/77010
<maco> possibly the hardware beep was disabled?
<MattJ_> Thanks ion :)
<dtchen> maco: / djsiegel1: no, and no.
<dtchen> there was a rather hackish workaround applied
<djsiegel1> dtchen: but is there improvement for users?
<djsiegel1> I have heard fewer beeps
<dtchen> but, if you ... well, you've already marked it Fix Released, so I won't comment further
<djsiegel1> or is it my imagination
<djsiegel1> no, please comment further
<maco> hahaha
<djsiegel1> If we've significantly curbed occurrences of the hardware beep, and a stronger fix is on track for Lucid, I would consider it fixed
<djsiegel1> but if we didn't cut down on the beeps, I will revert to unfixed, dtchen
<dtchen> you've papered over the symptom, yes. You haven't fixed the cause.
<djsiegel1> ok, "papered over" sounds great for a paper cut :)
<dtchen> the fix for the cause won't land until 2.6.33 at the earliest.
<dtchen> really, you're a better judge of whether the paper cut was resolved
<djsiegel1> As far as status in hundredpapercuts is concerned, if the users feel less pain and discomfort, it's a win.
<dtchen> sure
<dtchen> I just want to warn you that there are changes on the horizon that will break this workaround further
<djsiegel1> I know it feels dirty to celebrate a dirty hack job...
<dtchen> again, you're the better job of paper cuts
<dtchen> s/job/judge/
<sladen> djsiegel1: yeah, but instead of a low latency, short hardware beep there is a now a high-latency, 800 msecond software beep with longer (150 msec) before it starts playing than the total length of the hwardware beep
<djsiegel1> sladen, then that's a new paper cut. As long as the beep is played at the user-controllable volume label, that is great
<djsiegel1> this particular paper cut is just aimed at the heinously lound hardware beep, but I agree there is more work to be done on beeps in general :)
<osiris> any chances the 70ba2a374704e00df8868a7ac3d7350329d28924 (32bit ioctl compat fix for radeon drm) will get into the ubuntu kernel?
<dtchen> osiris: file a bug affecting linux
<dmb> is there daily builds for the next version of ubuntu yet?
<chrisccoulson> dmb - not yet. checking http://cdimage.ubuntu.com/daily/ would tell you this though ;)
<dmb> chrisccoulson, have uploads started (i don't know if the topic is old or not)
<chrisccoulson> dmb - yes. the title says "Archive: lucid open for uploads"
<chrisccoulson> and if you're interested, you should be subscribed to the lucid-changes list
<dmb> oh, so thats the new name!
<dmb> ok, i'm done :)
<ryanakca> What importance would bug 264313 be?
<ubottu> Launchpad bug 264313 in coreutils "ls --color hangs for directories linked from network " [Undecided,Confirmed] https://launchpad.net/bugs/264313
<ryanakca> Medium or High?
<dmb> i would say high, but thats just me
<ryanakca> dmb: OK
#ubuntu-devel 2010-11-08
<psusi> external media is mounted with the user and group of the logged in user, which works great for vfat and udf, but not ext[234].  I've been pondering the idea of patching the kernel to allow those options to work with ext[234] and override permissions on external media.. anyone have any thoughts about that?
<psusi> mac seems to have an option you can toggle on its hfs+ disks to enable or disable permissions... seems handy for removable media
<psusi> and shouldn't be too hard to implement
<RAOF> That naievely sounds like a good idea.
<RAOF> ?
<ebroder> What should the UID of a file I create on an ext* fs mounted with this option?
<ebroder> Also setuid seems like it's going to be problematic
<psusi> ebroder, well, the way it works with udf is that the on disk uid is -1 when you are the interactive user and it was mounted with uid=yourid, then if someone else mounts that disk, the -1 is turned into their id on read
<psusi> a few years back I patched udf to accept additional options to give more control over it... originally it only applied the uid option as a default if it was already -1 on disk, if it was something else then it used that... I added options allowing you to specify that it should override any on disk id
<ebroder> What happens if you mount a drive that has files with uid -1 without a forced uid?
<psusi> you mean without the force option I added, or without any uid= option?
<ebroder> Without any uid= option
<psusi> then it is owned by -1
<psusi> err, wait, no
<psusi> it's owned by root
<psusi> yea... -1 on disk gets translated to 0 by default, or whatever you specify in the uid= mount option
<ebroder> ok. so i coerce someone (or something) into mounting a filesystem with uid=me, make a file setuid, then coerce someone (or something) into mounting it without a uid= option
<psusi> typically removable media is mounted with the nosuid option
<psusi> and/or noexec
<ebroder> do you know if, say, udisks does that?
<psusi> yep, nosuid, nodev,uid and gid options
<ebroder> and it looks like it doesn't allow the user to override with suid. that's good, at least
<psusi> yea, the only problem is that the uid option is ignored except by vfat, ntfs, and udf ( and even with udf it is only used if the on disk id is -1, which it will be as long as you created the file mounted the same way )
<calamari> hey.. just spent the last few *hours* compiling the kernel and wanted to just say THANK YOU to everyone creating packages and updates for us, I have a new appreciation for the dedication it must take to do this day after day.  Thanks a lot!
<psusi> lol
<lool> mdeslaur: I'm not sure how I relate to LP: #631980, but this seems ok
<mdeslaur> lool: I asked because you're on the linaro release team...that's all
<lool> mdeslaur: Oh ok; thanks
<lool> Hmm something corrupts my usb-creator-ed USB keys on reboot
<lool> I get dropped to a grub rescue shell if I boot them more than once
<jfer> hi, i am new to packaging and i was wondering what you should put in the section part of the control file
<RAOF> jfer: Debian policy has a list of current sections; a google search for âdebian policy sectionsâ will get you http://www.debian.org/doc/debian-policy/ch-controlfields.html as the first link, which will link you through to http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections which ends up http://packages.debian.org/unstable/
<JanC> looking at what other, similar packages use might be helpful too
<dholbach> good morning!
<pitti> yofel: yes, file-bug is supposed to be implied; I assigned the bug to me
<mdz> pitti, ping
<seb128> mdz, he's taking a swap day after travel today
<mdz> seb128, ah, thanks, I'll send email
<seb128> mdz, so maybe better to let some ping context
<seb128> ok
<hdon> hi all. if i want to compile with -m32 from my 64-bit system, what packages should i install?
<cr3> cjwatson: when I preseed a ubiquity install with mirror/http/hostname, it seems that sources.list still gets us.archive.ubuntu.com. might this be a known problem?
<cr3> cjwatson: by the way, that's for lucid and I could confirm if the problem is also on maverick if you'd like
<cjwatson> cr3: can I see your full preseed file, please?
<cr3> cjwatson: https://pastebin.canonical.com/39485/
<cjwatson> cr3: I'm not sure.  Can I have a DEBCONF_DEBUG=developer syslog?
<cr3> cjwatson: also, while pitti's out, might you happen to know why the i386 linux-meta package doesn't seem to be published to the archive even though launchpad.net says that the build is done: https://launchpad.net/ubuntu/lucid/+source/linux-meta/2.6.32.26.28
<cjwatson> it is published
<cjwatson> well, it's published on the master system anyway
<cr3> cjwatson: I'm only seeing 2.6.32.26 images for amd64 here: http://archive.ubuntu.com/ubuntu/pool/main/l/linux-meta/
<cjwatson> probably just waiting for mirrors to catch up
<cjwatson> (note that archive.ubuntu.com is a mirror network itself)
<mathiaz> statik: hi - seems like you've started to package Graphite - http://graphite.wikidot.com/ - Graphite - Enterprise Scalable Realtime Graphing
<mathiaz> statik: what's the status of packaging?
<cr3> cjwatson: ok, so I should start seeing them soon, thanks for the confirmation. I'll try to get those DEBCONF_DEBUG logs for you soon
<cjwatson> which is odd given that the timestamp is five hours ago though
<cjwatson> cr3: I recommend asking #is (internal IRC), since it looks to me as though the mirroring is stuck
<mathiaz> cjwatson: hi - do you have any hint to fix bug 448682?
<ubottu> Launchpad bug 448682 in couchdb (Ubuntu Karmic) "Cannot stop couchdb using /etc/init.d/couchdb after package install" [Medium,Triaged] https://launchpad.net/bugs/448682
<cjwatson> cr3: http://archive.ubuntu.com/ubuntu/project/trace/cocoplum.canonical.com is timestamped 07-Nov-2010 20:18
<mathiaz> cjwatson: it seems to be related to blocked signals by dpkg/apt
<jpds> cjwatson / cr3> mirroring fixed.
<cr3> cjwatson: good point, launchpad.net says that the image was built on 2010-11-05, I'll hop into #is now
<cr3> jpds: too quick for me :)
<cjwatson> mathiaz: a workaround is easy - set SIGINT back to SIG_DFL on starting the daemon.  as for the proper fix, I'm not sure.  it would be helpful to start by stracing everything in sight to figure out what's actually ignoring SIGINT
<cjwatson> (you will find that dpkg ignores SIGINT in the parent process while the child maintainer script is running, but that doesn't count - you want stuff actually on the path to forking erlang)
<cjwatson> there's some suspicious code in apt
<cjwatson> err, SIGHUP, not SIGINT
<Keybuk> cjwatson: is the signal even in the process signal mask?
<mathiaz> Keybuk: SigIgn: 0000000000001007
<cjwatson> Keybuk: there's information in the bug ...
<cjwatson> Keybuk: apt's code is suspicious to me because it ignores signals *before* forking child processes, not after as is more usual
<Keybuk> masking signals across a fork() is a common idiom
<Keybuk> it's used when the signal handler has complex code, e.g. modifies lists of pids
<cjwatson> sure, but it's ignoring stuff a la system(), not quite the same thing
<Keybuk> otherwise you could interrupt the fork+record pid mechanism at a bad point
<cjwatson> I know, but that's not what's happening
<Keybuk> sure, it's probably someone picked up a "I must mask signals" meme without understanding it
<cjwatson>       /* Mask off sig int/quit. We do this because dpkg also does when
<cjwatson>          it forks scripts. What happens is that when you hit ctrl-c it sends
<cjwatson>          it to all processes in the group. Since dpkg ignores the signal
<cjwatson> but they did it at the wrong point
<cjwatson>          it doesn't die but we do! So we must also ignore it */
<mathiaz> cjwatson: I've tried to insert a 'trap true 1' in the couchdb shell script
<mathiaz> cjwatson: but it seems like it doesn't work as expected
<mathiaz> cjwatson: is there another way to unblock signal 1?
<cjwatson> mathiaz: well, if you've gone through the shell to figure out exactly how that's implemented ...
<cjwatson> mathiaz: I meant calling sigaction in the daemon itself
<cjwatson> I'm surprised that more daemons don't have this kind of problem, though
<cjwatson> maybe they do and we just don't notice
<mathiaz> cjwatson: http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/natty/couchdb/natty/annotate/head%3A/bin/couchdb.tpl.in#L225
<mathiaz> cjwatson: ^^ this is where the erlang process is created
<cjwatson> I mean do it inside whatever $command is
<cjwatson> in couchdb itself
<mathiaz> cjwatson: ok
<cjwatson> or create a tiny C wrapper that does  struct sigaction sa; memset (&sa, 0, sizeof sa); sa.sa_handler = SIG_DFL; sigemptyset (&sa.sa_mask); sa.sa_flags = 0; sigaction (SIGHUP, &sa, NULL);  and then execs the program
<cjwatson> this is just a crappy workaround though
<mathiaz> cjwatson: given that erlang doesn't seem to support linux signal (http://stackoverflow.com/questions/2459672/erlang-linux-signal-handling)
<mathiaz> cjwatson: it seems that the C wrapper is a good option
<cjwatson> that's a bit rubbish
<psusi> cjwatson: speaking of signals and debconf, the other day I inadvertantly got postfix installed while installing something else and when the debconf for it came up, could not cancel out or ctrl-c, and it kept running after I closed the terminal.. shouldn't it die on SIGHUP?
<cjwatson> psusi: we weren't speaking of signals and debconf; we were merely speaking of signals
<psusi> ohh... thought you were talking about them being ignored when dpkg was running child processes
<cjwatson> psusi: debconf ought to die on SIGHUP, but the very same apt bug referred to above probably means that it never sees it
<cjwatson> psusi: debconf != apt/dpkg
<psusi> cjwatson: btw, I proposed merging branches to drop the patches removing the 'p' from the partition device names of dmraid disks in dmraid and parted... I assume you just didn't have time to do that in maverick, or did some reason come up not to?
<cjwatson> psusi: it was too late in the cycle by the time I realised it was dmraid and not lvm2 that needed to be synced with - thanks for your patches, I plan to merge them in maverick
<psusi> cjwatson: you mean natty, or going to maverick-updates?
<mathiaz> JamesPage: where is the zookeeper request for removal?
<psusi> I'm still waiting to hear back from a user testing my ppa with those patches applied to fix grub installing on his dmraid where the name ends in digits so I think it can't identify the base disk name vs partition without the 'p'
<mathiaz> JamesPage: for bug 666028
<ubottu> Launchpad bug 666028 in openldap (Ubuntu) "apt-get install slapd => Can't locate object method "new" via package "Debconf::Element::Noninteractive::Booleam"" [Medium,In progress] https://launchpad.net/bugs/666028
<JamesPage> mathiaz: I'll just dig out the details.
<mathiaz> JamesPage: could you also prepare a branch to fix the bug in natty as well
<mathiaz> JamesPage: ?
<mathiaz> JamesPage: the first step to get an SRU is to get the bug fixed in the development release
<JamesPage> mathiaz: yes (for bug 666028/natty)
<ubottu> Launchpad bug 666028 in openldap (Ubuntu) "apt-get install slapd => Can't locate object method "new" via package "Debconf::Element::Noninteractive::Booleam"" [Medium,In progress] https://launchpad.net/bugs/666028
<psusi> Keybuk: I've been working with updating lvm2 to a new upstream release with --merge support and you wrote a patch to prevent opening disks for write access when activating to prevent a feedback loop where change causes activate causes open for write causes change... why does open for write cause change, and why do we activate all vgs on change, as opposed to just add?
<Keybuk> open for write causes an inotify IN_CLOSE_WRITE on the block device
<Keybuk> udevd listens for those, and will synthesise a "change" event for the block device
<Keybuk> this means that if you create a lv, then run mke2fs on it
<Keybuk> you get a "change" event
<Keybuk> which means udevd will re-run blkid, and update the UUID/LABEL symlinks to the new filesystem
<psusi> ahh... ok... that makes sense... but why vgchange -a y?
<Keybuk> likewise, if the pv is inside an md, you have to activate vgs on "change"
<Keybuk> because only a change of a md singifies it's ready
<Keybuk> you may be confusing the "change" event of the lv with the "change" event of the block device containing the pv
<psusi> ohh... when it's added it isn't yet actually readable?
<Keybuk> correct
<psusi> ahhh
<Keybuk> add /dev/md0 - not ready
<Keybuk> change /dev/md0 - ready, run vgchange -a -y
<psusi> yea, only talking about change on the partition device used as pv
<Keybuk> add /dev/dm0 - not ready (haven't yet made a filesystem in it)
<cjwatson> psusi: only really interested in doing it for natty, sorry, yes, I meant that
<Keybuk> mke2fs /dev/dm0 causes:
<Keybuk> change /dev/dm0 - ready, symlinks to the e2fs filesystem now visible
<Keybuk> right
<Keybuk> so we can't make assumptions about the behaviour of the partition device used as a pv
<psusi> Keybuk: got ya...
<Keybuk> not all devices are ready on add, in fact, the majority of multiple-block-device devices *are not* ready on add
<Keybuk> so we also run on change
<JamesPage> mathiaz:  zookeeper removal is under Debian bug#602694
<lifeless> whats 'https://launchpad.net/~ubuntu-irc-members' all about?
<Keybuk> I think it means you've been a member on IRC
<dholbach> jussi, ^
<jussi> lifeless: exactly the same as kubuntu members or edubuntu members etc, but with irc as the contribution.
<kees> did vte just stop paying attention to the gnome browser settings?? grrr
<lifeless> jussi: this seems very odd
<lifeless> jussi: I hadn't heard of it
<lifeless> jussi: and if its giving our ubuntu *membership* as a result, I wouldn't have expected to be just added to the group without communication.
<lifeless> jussi: (not to mention that I'm already an Ubuntu member ... so it seems redundant to boot)
<jussi> lifeless: we did a cross check of ops who are members, and added them automatically. this group will be the people who have the opportunity to vote for the IRCC.
<JamesPage> mathiaz: question re bug 666028 and Natty; should this fix be a point release i.e. ubuntu3.3 like it is for Maverick?
<ubottu> Launchpad bug 666028 in openldap (Ubuntu) "apt-get install slapd => Can't locate object method "new" via package "Debconf::Element::Noninteractive::Booleam"" [Medium,In progress] https://launchpad.net/bugs/666028
<mathiaz> JamesPage: yes - for maverick ubuntu3.3
<mathiaz> JamesPage: for natty - ubuntu4
<lifeless> jussi: Some communication about this would have been nice. Being added to teams without discussion feels pretty uncomfortable.
<JamesPage> mathiaz: OK
<jussi> lifeless: you have a fair point. I will note to make sure that all are aware next time.
<gbs> why $(TOPDIR) doesn't come by default in ubuntu?
<gbs> export TOPDIR=$(pwd) in bashrc
<ScottK> jussi: Why is the polity for IRCC to be limited to Ops?  Don't all Ubuntu people that use IRC have an interest in that?
<jussi> ScottK: it isnt
<jussi> ScottK: the ops were auto added and cloaked people were given the choice.
<ScottK> jussi: Then I don't understand what you just told lifeless.
<ScottK> I read your message as "consider adding yourself to the team if you feel IRC is a significant part of your contribution to Ubuntu" not "Add yourself to the team if you want to be able to vote for IRCC".
<JamesPage> mathiaz: branch uploaded for bug 666028/natty
<ubottu> Launchpad bug 666028 in openldap (Ubuntu) "apt-get install slapd => Can't locate object method "new" via package "Debconf::Element::Noninteractive::Booleam"" [Medium,In progress] https://launchpad.net/bugs/666028
<jussi> ScottK: this is probably not the correct place for this discussion, so feel free to join me in -irc or pm.
<mathiaz> JamesPage: your maverick branch should be reviewed against the maverick-updates branch rather than the maverick branch
<mathiaz> JamesPage: as it builds on maverick-updates rather than maverick
<JamesPage> mathiaz: it should be but for some reason its not; let me take a look.
<mathiaz> JamesPage: when the merge proposal is created, maverick-updates should be used instead of maverick (which is the default IIRC)
<JamesPage> mathiaz: OK; so if I delete the proposal and re-propose that should sort this out?
<mathiaz> JamesPage: yop - that should work out correctly
<JamesPage> mathiaz: OK - on it now...
<mathiaz> JamesPage: and you probably wanna push your maverick SRU to lp:~james-page/ubuntu/maverick-updates/openldap/fix-666028
<mathiaz> JamesPage: rather than maverick
<JamesPage> mathiaz: this would be why it selected maverick rather than maverick-updates as the branch?
<mathiaz> JamesPage: yop
<mathiaz> JamesPage: the list of branches is a bit confusing when an update has been published
<mathiaz> JamesPage: the branches follow the same structure as the pocket (maverick, maverick-updates), etc...
<ebroder> cjwatson: do we do a grub-install on release upgrades?
<JamesPage> mathiaz: OK; let me trash the merge proposal for maverick-updates and associated branch and I'll re-push
<mathiaz> JamesPage: right
<mathiaz> JamesPage: it's complicated to get things right
<mathiaz> JamesPage: the way I noticed it was by reviewing the diff
<mathiaz> JamesPage: associated with the merge proposal
<mathiaz> JamesPage: as it had too much information
<mathiaz> JamesPage: the diff should represent the difference with the *latest* package published in the archive
<JamesPage> mathiaz: yes - I had spotted that; thanks for pointing me in the right direction...
<mathiaz> JamesPage: so it can be against the release (ig maverick) or an update (if there was already a package published)
<mathiaz> JamesPage: it can even be against -proposed
<mathiaz> JamesPage: if there is already a package in -proposed
<JamesPage> mathiaz: I see; it all becomes clear....
<JamesPage> mathiaz: hmmm; when I try to push to lp:~james-page/ubuntu/maverick-updates/openldap/fix-666028
<JamesPage> mathiaz: I get a 'No such distribution series maverick-updates' message
<mathiaz> JamesPage: hm - I don't know what's the issue here - may be lifeless or james_w can help here ^^
<cjwatson> ebroder: only if grub-pc is upgraded
<cjwatson> ebroder: we do grub-install when upgrading grub-pc, and update-grub when upgrading grub-pc or a kernel package, basically
<james_w> JamesPage, push just to maverick
<ebroder> cjwatson: ok, good. i think my patch to /etc/grub.d/10_linux will work even if the lua module isn't installed, but i'd prefer to not worry too much about it
<mathiaz> james_w: and then create a proposal against maverick-updates?
<ebroder> cjwatson: in any case, i have a patch to /etc/grub.d/10_linux along with a lua script that it runs, but i'm having a hard time integrating it into the packaging. can you give me some direction on what piece should be installing my lua script into /usr/lib/grub/i386-pc/etc/?
<JamesPage> mathiaz: uploading to maverick and then proposing against maverick-updates generates the right diff.
<mathiaz> JamesPage: \o/
<JamesPage> mathiaz: OK; so bug 666028 now has branches and merge proposals ready for maverick-updates and natty.
<ubottu> Launchpad bug 666028 in openldap (Ubuntu) "apt-get install slapd => Can't locate object method "new" via package "Debconf::Element::Noninteractive::Booleam"" [Medium,In progress] https://launchpad.net/bugs/666028
<mathiaz> JamesPage: great - looks good to me
<mathiaz> JamesPage: I'll sponsor them later today
<JamesPage> mathiaz: thanks; finishing my day now so catchup tomorrow....
<mathiaz> JamesPage: o^5 - well done
<cjwatson> ebroder: I'd be inclined to suggest just putting it in debian/grub-pc.install.in, at least for the moment
<ebroder> cjwatson: oh! it's i386-pc on both i386 and amd64, isn't it? i just realized i'm looking at i386-pc on my amd64 machine
<slangasek> pitti, cjwatson, jdong: all the bits Linaro needs out of maverick-proposed are published to maverick-updates now, feel free to consider -proposed unfrozen
<ebroder> cjwatson: that makes it easier. i should be able to write up a patch once i get back to my machine with all of my credentials
<cjwatson> ebroder: yes, the "i386" there refers to the architecture of the boot loader objects
<cjwatson> which are always 32-bit when built for the BIOS platform
<RoAkSoAx> slangasek: howdy!! I was wondering if you had the time to review the library split for cluster-glue/pacemaker?
<slangasek> RoAkSoAx: not at all yet, sorry :/  Hoping to get to it this evening
<RoAkSoAx> slangasek: idon't worry abot it L:). Thanks though :)
<bruteforce_allti> Hi, while on local systems(Lucid and Maverick ), I was able to build a package suffecssfully. But when I uploaded(ppa) it in respective series(Lucid and Maverick), all Lucid packages failed to build. While Maverick build successfully.
<bruteforce_allti> Build Log http://launchpadlibrarian.net/58724370/buildlog_ubuntu-lucid-amd64.sugar-datastore-0.90_0.90.0-1ubuntu1_MANUALDEPWAIT.txt.gz   and failed because of unsatisfied dependency. After installing, the following source dependencies are still unsatisfied: cdbs(inst 0.4.62+nmu1ubuntu9 ! >= wanted 0.4.75~)
<bruteforce_allti> Can anyone please guide me how to solve this and explain why this error is occuring?
<cjwatson> neeraj: you're asking (via Build-Depends) for a version of cdbs considerably newer than what's in luci
<cjwatson> *lucid
<cjwatson> you will need to figure out what's needing newer features of cdbs, and backport them to whatever is available in lucid
<cjwatson> alternatively, perhaps there is a newer version of cdbs in some other PPA somewhere, in which case you can make your PPA depend on that
<cjwatson> it's in the web UI
<neeraj> cjwatson: ok.  Thats what I thought. Was searching about latest cdbs available in lucid. And yes there is cdbs 	0.4.82  present but in under sugarteam.(while lucid ones were inside sugar-test2).
<neeraj> That cdbs 	0.4.82  is in Lucid series
<NCommander> cjwatson: ping, you don't happen to have a  copy of the spice seed notes, would you, or know someonw ho does?
<ogra_ac> NCommander, i thought i saw them in gobby today
<ogra_ac> 8didnt open them though)
<NCommander> ogra_ac: there's a doc there, but its empty
<ogra_ac> ah
<ogra_ac> then ask persia
<ogra_ac> if he took the notes, he didnt take them in gobby
<persia> I didn't take the notes of that session.
<NCommander> ogra_ac: you see the problem :-)
<NCommander> I'm going to have to listen to the audio and recreate them
<NCommander> ogra_ac: BTW, did you review either of the specs I wrote (I sent you an email about that)
<ogra_ac> NCommander, i couldnt get to any mail the last week
<ogra_ac> plumbers had the worst network i have ever seen ... redhat needs an elmo ;)
<NCommander> ogra_ac: obviously you forgot the internet connection in Holiday Inn, Berlin :-)
<ogra_ac> that was still better
<NCommander> Ouch
<ebroder> SpamapS: i don't have my LP credentials with me - could you fix packageselection-server-n-upstart-server-enhancement to say that maintainer scripts should always use invoke-rc.d, and that there's an outstanding bug that that doesn't result in calling upstart jobs?
<SpamapS> ebroder: Sure.. I was just dumping the gobby doc in.
<SpamapS> I wonder, if I have an upstart job that pipes to logger, can i use expect fork? I'm guessing no.
<SpamapS> Keybuk: poke ^^ ???
<SpamapS> hrm...
<SpamapS> I am typing out work items and I think this one does need a full specification to explain the rationale.. :-P
<psusi> Keybuk: a while back I patched ureadahead to use the tracer in pipe mode instead of log file mode, which eliminated the need for a large trace buffer.  I see you have since lowered the size of the trace buffer to 8mb.. given that would you be interested in pipe mode?
<tony_> Hello, my external speakers did not work, but I tweaked with HDA-Analyzer and found that by unmuting two things (in Node[0x0c]) get my external speakers to work. But how can I make this change permanent?
<tony_> Because everytime I reboot I have to run HDA-Analyzer and change it again and again.
<ScottK> tony_: Help is in #ubuntu.
<tony_> ScottK, noboy's answering and I thought it would be too a technical question so I asked here
<ScottK> Lack of help in #ubuntu doesn't make it on topic here.  Sorry.
<cjwatson> NCommander: afraid I don't, sorry
<NCommander> cjwatson: bugger.
<pasteeater> siretart: would a comment showing support/interest in your x264 MIR be useful or just noise?
<Daniel0108> hi
<paddy_> I created a key for launchpad with gpg --gen-key but i cannot find the file i give to launchpad, the key appears in seahorse though
<SpamapS> paddy_: you'll want to export that public key to an ASCII armor format and upload it.
<lifeless> SpamapS: err, not for launchpad
<SpamapS> oh?
<paddy_> SpamapS, an .asc file, tried that, gave errror
<paddy_> lifeless, what do?
<lifeless> https://launchpad.net/people/+me/+editpgpkeys
<lifeless> and follow the instructions
<lifeless> SpamapS: paddy_: ^
<paddy_> lifeless, thanks
<SpamapS> lifeless: doh.. if only everything were so simple. ;)
<SpamapS> slangasek: ping, do you know if there is an existing place where the "best practices" for upstart in ubuntu are documented? I've googled for a few but maybe you have the definitive answer?
<slangasek> SpamapS: what is it you want to practice?
<slangasek> adding jobs to packages?
<slangasek> there's no documentation for that - it should be documented by way of debian/ubuntu policy
<SpamapS> specifically in "how to write an upstart job" and "how to manage upstart jobs"
<ScottK> SpamapS: The best practice is ask Keybuk.
<SpamapS> ScottK: ;)
<SpamapS> slangasek: I went through your old IRC class and it had a few things in there that were somewhat non obvious.. stuff like that.
<SpamapS> https://wiki.ubuntu.com/MeetingLogs/devweek1007/UpstartJobs
<slangasek> SpamapS: yeah, there's work to be done around codifying and documenting this stuff
<SpamapS> slangasek: https://blueprints.launchpad.net/ubuntu/+spec/packageselection-server-n-upstart-server-enhancement
<SpamapS> slangasek: I'm hoping to do a lot of that work this cycle. :)
<SpamapS> including documenting when this is a permanent thing, and when this is "only until upstart bug #x is fixed"
<slangasek> SpamapS: if you were to take that meeting log and massage it into a wiki write-up, that would probably be a good start?  And I'd be happy to review for you
<SpamapS> slangasek: I intend to do just that.
<SpamapS> I think the idea is to make sure we are simply documenting the use cases, and pointing to the man page for details.
<SpamapS> Would it make sense to also try to add an EXAMPLES section to man 5 init?
<slangasek> I have no strong opinion there
<ScottK> SpamapS: I almost always love examples in man pages.
<SpamapS> ScottK: agreed, that way it stays close to the software when changes are made.
<ScottK> SpamapS: It's generally the first documentation I look at and so if it solves my problem, life is good.
<SpamapS> ScottK: right, I think once people find man 5 init, they get a deeper understanding of upstart and cut out the hate, so much of this will serve to push people to that man page.
<barry> SpamapS: okay, i've done all i can do for your mp on cheetah :)
<RAOF> Urgh.  Why does symbol visibility appear to be a compile time rather than link time decision?
<syn-ack> That't the way it's always been, RAOF. I think it should be a link time option though
<RAOF> syn-ack: It does make it somewhat more difficult to do what I want:)
<syn-ack> RAOF: heh
<lamont> cjwatson: both of us are too short to use signals.
<lamont> just sayin'
<Iraqi> there are people the power off on PC and after want running ubuntu 10 will not running so how fix it please?
<SpamapS> barry: thanks for the review though, preparing a patch for the debian experimental cheetah
<bryceh> persia, is it still proper for people who want to become core dev to apply for motu first?  There's a regular xorg contributor (now canonical employee) who is aiming to gain core-dev.  Should he start by applying for MOTU or just shoot for core-dev directly?
<syn-ack> good afternoon, SpamapS.
<persia> bryceh, There's certainly no need to apply for MOTU prior to applying for core-dev.  That said, the requirements for core-dev have become rather more strict than previously, as other options have become available.
<persia> Depending on the breadth of packaging experience, it is often appropriate for candidates for core-dev to previously have been approved as some other sort of Ubuntu Developer, simply to show responsibility to the archive and skill in packaging.
<persia> Depending on the prior work of this individual, another option would be to apply for upload rights to specific packages of interest (those that are considered part of X), or similar.
<bryceh> persia, ok thanks
#ubuntu-devel 2010-11-09
<twb> So this "weyland" thing that Mark was waffling on about... does it mean ssh -X won't Just Work in upcoming releases of Ubuntu?
<twb> (Or: is there a more appropriate channel to ask that?)
<kklimonda> twb: it's simply way to early to ask that
<twb> okey dokey
<kklimonda> also, X are not the only way of running applications remotely.
<twb> I realize that, but I'd prefer not to replace ssh -X with some raster-based nightmare like RFB or RDP
<kklimonda> but it's still too early to ponder about it.
<twb> Nod.
<Chipaca> is there an easy and magic way to split a library package into libfoo and libfoodev?
<lifeless> .install files
<Chipaca> lifeless: thanks
 * Chipaca reads
<electrofreak> I've realized a problem with the powernowd and Phenom II's dynamic clocking. For example... if I download mprime and run 4 stresses from the program, my CPU usage will go to 100%, but the clocks of all the cores is 800MHz except for 1, which is at 3.2GHz. This was also a problem when doing multithreaded converting with ffmpeg. But if I use 'stress' with 4+ cpu stresses, it will clock up all the cores properly. So, there seems to
<electrofreak> be a problem with the threading and powernowd clocking each of the cores independently. Any ideas on a proper fix? (killing powernowd is a workaround)
<psusi> electrofreak, uninstall the powernowd package... it's obsolete and I have requested that it be removed from the archive... the functionality it provides is now provided by the kernel itself
<twb> Doesn't it just set the CPU scaling governor to performance on AC and conservative on battery?
<psusi> I think that's laptop mode tools...
<psusi> though it is interesting that your cores report different clocks... usually all the cores in a multi core cpu must be using the same clock
<twb> Last time I looked, all those throttling apps basically just modprobed the driver and then set the governor on ACPI events
<twb> i.e. they were all pretty much useless
<electrofreak> psusi, well... I don't think that the kernel's version works right either
<electrofreak> psusi, I could be wrong maybe
<electrofreak> psusi, well, in older CPUs... they clocks were different per core...
<electrofreak> but this is a brand new Phenom II... each core clocks differently
<psusi> electrofreak, given that it works correctly with one program and not the other, I'd guess that the one is either not actually running multiple threads and keeping all cores busy, or they are running at low priority so are ignored by the governor.. but first thing I suggest is that you remove the powernowd package...
<electrofreak> psusi, err... I messed up that sentence... in older CPUs, they clocks on each core were the same. But on new CPUs... each core can clock independently
<electrofreak> psusi, well... that program is definitely doing multiple threads... because in top it reports nearly 400% CPU (4 cores) and when I stop powernowd... the temperature jumps up very quick.
<electrofreak> psusi, 'stress' actually spawns separate processes.
<electrofreak> psusi, I'll try removing powernowd
<electrofreak> psusi, although, I might need to reboot now... because it just stopped it and the kernel itself isn't handling it on its own right now (probably because powernowd took over before
<electrofreak> psusi, or is there something that I can set in /sys to make the kernel take over again?
<electrofreak> psusi, ok. I echo'd "ondemand" into /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor, that seems to work
<electrofreak> but now, mprime for some reason doesn't cause any of the cores to clock higher now.
<psusi> electrofreak, it's probably nicing itself and iirc, ondemand by default ignores processes using the maximum niceness
<electrofreak> nice value is 10
<electrofreak> should I try 0 nice?
<electrofreak> psusi, ok. I figured this out. have to set ignore_nice_load=0... then everything works fine.
<electrofreak> psusi, adding it to sysfs.conf to persist through reboots, too.
<pitti> Good morning
<pitti> slangasek: nice, thanks
<dholbach> good morning!
<neeraj> Hi, while uploading my package in ppa, I am getting this error msg again and again or two/six packages which I am packaging. Rejected:
<neeraj> Unable to find sugar-presence-service-0.90_0.90.1.orig.tar.bz2 in upload or distribution.
<neeraj> Files specified in DSC are broken or missing, skipping package unpack verification.
<neeraj> anyhelp? I tried google but not able to find a soln
<akheron> neeraj: try building with the -sa option
<neeraj> akheron: thanks. I forgot to use "-sa" and kept trying with -s flag :(
<pitti> sconklin: I assigned bug 672964 to you, it's a regression in the lucid proposed kernel
<ubottu> Launchpad bug 672964 in linux (Ubuntu Lucid) "2.6.32-26 unbootable: does not find root file system" [Critical,New] https://launchpad.net/bugs/672964
<pitti> sconklin: diwic reported it, I guess he can supply additional debug info if needed
<Riddell> doko: what should we do about -mimplicit-it=thumb ?
<Riddell> doko: so far we added it to qt and kde4libs to work around failing to build
<Riddell> doko: should we add it to other packages as needed or should it go back in the gcc defaults?
<Riddell> currently the kde stack is stuck on http://launchpadlibrarian.net/58639702/buildlog_ubuntu-natty-armel.kdepimlibs_4:4.5.3-0ubuntu1_FAILEDTOBUILD.txt.gz
<mdeslaur> cjwatson, ev: bug 673028
<ubottu> Launchpad bug 673028 in ubiquity (Ubuntu) "Ubiquity encrypted home doesn't setup encrypted swap" [Undecided,New] https://launchpad.net/bugs/673028
<Riddell> \sh: could you verify bug 533369 ?
<ubottu> Launchpad bug 533369 in debootstrap (Ubuntu Lucid) "Fails to debootstrap squeeze chroot due to missing apt-get" [Undecided,Fix committed] https://launchpad.net/bugs/533369
<Riddell> oubiwann: hi, what was the outcome of the touch sessions with the Qt people?
<\sh> Riddell: I trashedbin my squeeze stuff, but can redo do it tomorrow...not right now...
<oubiwann> Riddell: they liked the architecture, have used v1 of the GEIS API (complete with a Qt demo), and are even more excited about GEIS v2
<oubiwann> they provided a great deal of feedback on all aspects of utouch, and really improved the quality of the UDS sessions as a result
<Ng> 9
<Ng> doh
<ogra_ac> 10
<ScottK> 11
<Riddell> oubiwann: so presumably we can look forward to touch on linux being in Qt 4.8?
<oubiwann> Riddell: well, it's more complicated than that... full MT support on Linux with Qt depends on XInput 2.1 landing
<oubiwann> we're hoping that 2.1 makes it into the X 1.11 release
<oubiwann> 1.10 is probably going to come out around Apr 2011, and that will still be too soon for XI2.1 to be fully tested
<oubiwann> 1.11 is likely to come out around August of 2011, so that's the target for XI2.1 getting released
<oubiwann> toolkits aren't interested in supporting touch officially for linux until 2.1 lands
<oubiwann> but the Qt guys are really staying closely involved with the 2.1 dev process and plans, and I would expect that they'll be ready to go as soon as X is
<oubiwann> (in other words, I wouldn't expect a 6 month lag from them after August 2011)
<Riddell> oubiwann: right, thanks for the update
<oubiwann> Riddell: no prob
<bilalakhtar> Where can I find a listing of people with upload rights to 'which packageset' and other details
<geser> bilalakhtar: the data is in LP and to some part also distributed in the heads of some people
<bilalakhtar> geser: I mean, what is the URI to the LP page?
<bilalakhtar> since I know there is one
<geser> I don't know a single page
<bilalakhtar> geser: okay
<bilalakhtar> fine then
<geser> especially that I don't know of any page in LP that shows upload permissions at all
<geser> you have to use the LP API to get the data
<bilalakhtar> ok
<geser> PPU and similiar (e.g. package sets) are only managed through the LP API
<geser> are you looking for something special? perhaps I can tell you the right spots to look at
<cjwatson> bilalakhtar: might be easiest to use edit_acl.py from lp:ubuntu-archive-tools - it has a query feature
<bilalakhtar> cjwatson: thanks
<SpamapS> So.. I'm wondering why there was no discussion of btrfs at uds-n .. don't we want it as a default FS for 12.04? is that being relaxed now?
 * SpamapS has started using btrfs for all cache/temporary data.
<cjwatson> mostly forgetfulness, but I thought there were still serious issues with reliability and things like being able to use a halfway reasonable percentage of the block device
<SpamapS> since UDS-M I've been using it for my local mirror and now I'm working on getting schroot's setup on it
<SpamapS> have had no issues, but have never gotten near capacity on a drive. does it just fragment badly?
<pitti> I have used it as / (not /home yet) for about half a year without data loss
<pitti> however, resuming from RAM often hangs, and I heard that this was particular to using btrfs
<jdong> I've used it as / and /home and /srv for a year...
<jdong> no data loss but two reformats due to metadata occupying tens of gigabytes of space
<cjwatson> SpamapS: I don't know the details.  comments I've heard are that you're lucky if you get it to use even half the disk space.  I think that's unacceptable for Ubuntu
<jdong> and performance, I've found, rapidly degrades with time
<jdong> cjwatson: it's lately more like 80%, but still not great.
<cjwatson> (I haven't looked in a while though, and I recognise that we're not contributing much to the kernel side)
<jdong> it's much more irritating when it mysteriously goes slow though...
<jdong> particularly with qemu/kvm type workloads (random IO on gigantic files), btrfs can generate a lot of disk traffic
<jdong> it's still missing important features like a consistency check / repair mechanism too
 * cjwatson grumbles at having to do http://paste.ubuntu.com/528747/ to busybox
<SpamapS> jdong: wow.. ok .. so not in 12.04 ;)
<jdong> SpamapS: well I don't know. I'm not great at predicting the future, and Ubuntu doesn't have a stake in doing this kernel development right now
<jdong> so it's just speculation on our end
<jdong> this looks like a case of proverbial "it's ready when it's ready"
<\sh> cjwatson: why?
<SpamapS> jdong: IMO, if its not ready by 11.04, its not ready for 12.04 given the long term ramifications of a default filesystem choice on an LTS
<cjwatson> \sh: see build logs.  irritating header incompatibilities
<jdong> SpamapS: well the filesystem is certainly not something to risk mass-exposure to. But who knows, maybe by 12.04 ext4 will be deprecated in favor of btrfs :)
<jdong> SpamapS: never know what'll happen in a year+ of Linux dev
<jdong> SpamapS: but I think the bottom line is, we'll decide around UDS time for 12.04 with the information then. Right now it's hard to speculate one way or the other
<jdong> but users are already welcome to do btrfs installs and play with the technology
<SpamapS> jdong: if there is one thing to be conservative about.. default filesystem on an LTS is probably it. ;)
<jdong> yep :)
<\sh> cjwatson: hmm...wasn't there some discussion about not using <linux/*> includes when avoidable?
<SpamapS> jdong: if its not already default for 11.10 .. it would be hard to convince *me* that its ready enough for 12.04. :-P
<jdong> SpamapS: your opinion might be different if all the other popular OS'es by 12.04 have features afforded by btrfs-type filesystems.
<SpamapS> Seems to me like there's another thing going on, which is changing the way people think about files in general. There's the traditional static folder/tree view, and then there's something else.. I like the idea of a file manager that is entirely time-oriented.
<SpamapS> jdong: If they have something btrfs-type that is tested and agreed upon, then lets use that. ;)
<jdong> SpamapS: indeed if OS X, Windows, RedHat, and friends ALL had time machine type snapshotting features, live checksumming / recovery, etc... we might get impatient
<ebroder> i'm kind of skeptical that's a compelling enough use case to be worth getting impatient over
<SpamapS> ebroder: people don't think twice about saving a file if they know it is version controlled. "forever undo" is quite freeing. :)
<jdong> ebroder: deep integration with the rest of the desktop of COW snapshotting would make me very impatient ;-)
<cjwatson> \sh: yes.  hence "grumbles"
<doko> Riddell: are thre bug reports open about this?
<Riddell> doko: no, just build logs
<doko> Riddell: I'll have a look tomorrow with the linaro people
<doko> Riddell: so this is kdepimlibs, qt and kde4libs ?  a bug report would be nice
<TeTeT> tkamppeter: hi, I'm encountering a black/white vs color printing problem in eog, I filed a bug against eog, but not sure if it's not actually cups: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/673082
<ubottu> Launchpad bug 673082 in eog (Ubuntu) "10.04: Print in black/white instead of color" [Undecided,New]
<m4t> hey, i've got a .config that fails to boot when compiled with 10.10 32bit toolchain
<m4t> i verified this on another maverick install also
<m4t> CONFIG_MPENTIUMM and CONFIG_M686 both have the issue
<m4t> should i file this under linaro-gcc?
<pitti> cjwatson: any idea how this could have happened? https://launchpad.net/ubuntu/jaunty/+source/xserver-xorg-video-geode/2.11.10-1~jaunty1
<pitti> cjwatson: Q-FUNK just accidentally uploaded it (was meant for PPA)
<pitti> cjwatson: shall I reject the binary?
<psusi> jdong: I've been playing with lvm snapshots to test ugprading to natty and then reversing it... very nifty
<pitti> it should just have been rejected (upload to stable), and on top of that jaunty is EOL
<RoAkSoAx> kirkland: ping?
<pitti> wgrant: ^ any idea about this jaunty upload?
<cjwatson> pitti: madison-lite on cocoplum doesn't list it
<pitti> cjwatson: it was just uploaded a few mins ago
<cjwatson> absolutely should have been uploaded, do what you can to reject it
<cjwatson> er, shouldn't
<pitti> cjwatson: I rejected the binary, but of course the source is there now
<RoAkSoAx> pitti: howdy! I have a question for you! I'm gonna ship the scripts (to reduce power consumption) with powernap. So I was wondering if it would be better to install the scripts in usr/lib/powernap/actions and then symlink to  etc/pm/power.d, or should I install them directly to etc/pm/power.d ?
<pitti> RoAkSoAx: install directly, please; that's much less confusing
<jdong> psusi: yeah and btrfs's potential to extend that to the per-file/per-directory level, once integrated with applications, will be incredible too
<RoAkSoAx> pitti: indeed. though I'm also writing a tool to enable/disable scripts easily and also list scripts with their description. So i gues that the tool will just remove the executable bit
<pitti> RoAkSoAx: or rename them to .disabled or so
<pitti> RoAkSoAx: but chmod -x sounds okay, too
<SpamapS> https://launchpad.net/~clint-fewbar/+archive/fixes/+build/2037553/+files/buildlog_ubuntu-lucid-amd64.mongodb_1%3A1.2.2-1ubuntu1.1~ppa1_FAILEDTOBUILD.txt.gz
<SpamapS> can anybody explain why this symlink produces this error:
<TerminX> anyone know why rsyslog hasn't been synced from debian in quite a long time?
<SpamapS> dpkg-deb: building package `mongodb' in `../mongodb_1.2.2-1ubuntu1.1~ppa1_amd64.deb'.
<SpamapS> tar: ./usr/bin/mongo: file changed as we read it
<SpamapS> /usr/bin/mongo is a symlink
<RoAkSoAx> pitti: alright, will evaluate which one is more convenient. Thanks for the Input :)
<SpamapS> to ../lib/mongodb/xulwrapper
<cjwatson> TerminX: needs merge, somebody needs to look at it by hand
<cjwatson> (like all merges)
<RoAkSoAx> SpamapS: you doing the symlink manually?
<SpamapS> no, with dh_link
<SpamapS> it works fine when building locally w/ sbuild
<TerminX> cjwatson: ah, I guess there's no specific maintainer for the package then?  I was under the impression that ubuntu had switched to rsyslog by default
<TerminX> I don't think anybody looked at it during the maverick dev cycle either
<SpamapS> some things just get lost in the scuffle. ;)
<cjwatson> TerminX: merges are assigned to the person who touched the package last by default; but not everyone gets around to all their merges
<cjwatson> the standard rubric is that if you want to do it, you contact the person who touched it last to avoid duplicating work
<RoAkSoAx> SpamapS: idk then... maybe the symlinks gets overriden by something else during the creation of the package (i'm just guessing :) )
<SpamapS> RoAkSoAx: at this point all I can do is guess. :-/
<ebroder> looking at the diff from debian, there's probably a bunch of stuff you could drop if you merged rsyslog now - stuff like sysklogd transitional code
<SpamapS> RoAkSoAx: I suppose I can ls -lR debian/mongodb in the rules file so we see what it looks like before that point
<RoAkSoAx> SpamapS: or see if soemthing is installing in /usr/bin/mongo instead of just symlinking
<SpamapS> RoAkSoAx: ls -lR will show that I hope
<SpamapS> RoAkSoAx: doesn't relaly make sense that it would "change while reading" though
<SpamapS> and why it does it only on the buildd's I'm a little confused
<juk_> bug-buddy just caught stardict with: ** GLib **: /build/buildd/glib2.0-2.26.0/glib/gmem.c:239: failed to allocate 512 bytes
<SpamapS> hmm
<RoAkSoAx> SpamapS: try building with a pbuilder instead ..
<ebroder> pitti: by the way, i'd very much like to help with the perl-sectomy, or the footprint work more generally. please feel free to throw tasks at me if you'd like
<SpamapS> I just updated my lucid schroot and one of the things it pulled down was this:
<SpamapS> Get:14 http://archive.ubuntu.com/ubuntu/ lucid-updates/main tar 1.22-2ubuntu1 [390kB]
<pitti> ebroder: ooh, much appreciated
<RoAkSoAx> SpamapS: ah!1 that might be it then
<SpamapS> If it breaks now, there may be a regression
<RoAkSoAx> SpamapS: indeed
<RoAkSoAx> SpamapS: btw.. is there a meeting today?
<SpamapS> RoAkSoAx: yes, 18:00UTC, though I think that will be moved to 16:00UTC going forward
<RoAkSoAx> SpamapS: ok cool... will be back later ... my battery is almost drained :)
<SpamapS> looks like zul forgot to update the header
<pitti> ebroder: do you want to start with some small ones, like cups-driver-gutenprint and libfile-copy-recursive-perl?
<pitti> ebroder: not sure whether you followed the changes I already uploaded today?
<pitti> ebroder: in the ideal case, packages already don't need anything from perl-modules, so a simple dh_perl -d is enough
<pitti> ebroder: for some packages I needed to replace functionality from perl-modules with external programs (like rm -r) or other small replacements
<pitti> ebroder: I sent them to Debian, too, one patch is already accepted :)
<ogra_ac> pitti, we need to talk abotu the WI tracker some time this week ... (mobile got renamed to arm etc)
<pitti> ebroder: the biggest thing left is apparmor-utils
<ogra_ac> (not today anymore though, just a heads up that i will ping you some time)
<pitti> ogra_ac: sure; please feel free to adapt natty.cfg yourself (~platform on lillypilly)
<ogra_ac> ok
<ebroder> pitti: sure, the small ones sound fine. i can look at apparmor-utils too if i get a chance, but what is our solution if a package does need something from perl-modules?
<pitti> ebroder: for easy cases I rewrote the code to just use perl-base
<jdstrand> pitti, ebroder: you might check with kees on the apparmor one-- he may already be working on it
<pitti> ebroder: like "dirname"
<pitti> ebroder: for doc-base the only place that needed it was --dump-db, which is a debug option; I changed the code to say "Please install perl for this blabla" if you use it
<ebroder> pitti: ok, sounds good. i'll try to be sufficiently creative
<pitti> ebroder: I haven't yet worked on a package where perl-modules is necessary for core functionality
<pitti> ebroder: in that case we still have the option to split out that module from perl-modules, so that we can install it separately
<pitti> ebroder: we should make a list of those in the blueprint, so that we can do that in a larger step
<pitti> ebroder: so if you stumble over one of those, please make a note there
 * ebroder nods
<cjwatson> I wouldn't do that casually though, the Replaces forest can get pretty insane
<pitti> ebroder: thanks! please let me know about the progress, so that we can coordinate
<pitti> cjwatson: no, we should try to avoid that
<cjwatson> you'll probably run into File::Path at some point
<pitti> fortunately so far it wasn't needed
<pitti> you can do surprisingly much with perl-base
<kees> pitti, ebroder: so apparmor-utils uses libterm-readkey-perl, librpc-xml-perl in the Depends
<cjwatson> libfile-copy-recursive-perl uses File::Copy which is in perl-modules
<ebroder> pitti: in the cases where we can just do dh_perl -d, why don't i just make a note on the blueprint? it'll probably be faster for you to just do those than you dealing with a branch from me
<kees> actually, ${perl:Depends}
<pitti> kees: right, those are fine (as soon as we fix those to not pull in perl); we need to fix apparmor-utils' "perl" dependency itself, though
<cjwatson> sometimes you can use the module optionally and implement some other fallback
<kees> pitti: it's coming from ${perl:Depends} I assume
<kees> pitti: shouldn't we fix dpkg's idea of that instead?
<pitti> kees: right, dh_perl adds a perl dependency by default
<cjwatson> kees: that's what dh_perl -d does
<kees> pitti: so what's the right solution?
<pitti> kees: I usually go through "grep -wr use" and check where all imported modules come from
<kees> ah, s/dh_perl/dh_perl -d/ in rules
<pitti> kees: and once nothing is left, change dh_perl to -d
<cjwatson> be sure to check require as well as use
<pitti> right
 * pitti will still do some maverick SRU catchup and then call it a day; enough breakage for one day :)
<pitti> so, good night everyone!
<kees> okay, I remain confused. what is the process to make sure I can switch to perl-base?
<kees> because it seems like a lot of stuff lives in perl-modules, which requires perl currently
<pitti> kees: grep the source for "use" and "require" and check whether all of those are in perl-base, or standalone perl packages (which are seprate dependencies)
<kees> pitti: right, I have the list now. I guess doing the perl-name to package is the trick
<pitti> kees: for "use foo" I usually do "dpkg -S foo.pm"
<pitti> not sure whether there's something better
<kees> yeah, that's where I am too. Okay, cool.
<pitti> kees: thanks for looking into it!
<kees> you bet.
<kees> pitti: btw, with the loss of changelog.Debian.gz, people will not be able to examine their local filesystem to determine why a security update to a package was performed...
<kees> what happens if I encounter something that requires perl-modules ?
<pitti> kees: they just came back :) (in reduced form), see u-d-a@ and planet
<pitti> kees: but apt-changelog should pick those up as well
<pitti> kees: for simple cases it's often possible to rewrite
<kees> require Term::ReadLine;
<kees> pitti: ah, top 10 changes, nice.
<pitti> e. g. rmtree($dir) -> system('rm', '-r', $dir)
<kees> use Data::Dumper
<pitti> kees: that's more tricky; perhaps we could use libterm-readline-gnu-perl for that, and un-"perl"-ize (and MIR) that
<pitti> kees: Dumper was used in doc-base, but it was only a debugging tool; I did http://launchpadlibrarian.net/58890660/doc-base_0.9.5_0.9.5ubuntu1.diff.gz for that
<kees> File::Basename, the list goes on and on
<pitti> kees: as I said, this one will be hard :)
<pitti> Basename is trivial to express with core Perl, though
<kees> hrmpf.
<kees> yeah
<pitti> kees: I don't (much) expect to actually be able to drop Perl completely in Natty; but working towards it
<kees> -    mkpath ($d, 0, 0755);
<kees> -    rmtree ($d.$suffix, 0, 0);
<kees> +    system ('mkdir', '-m', '-p', $d);
<pitti> at least it will be much easier to drop it for custom projects, etc
<kees> that's wrong. -m requires an argument
<pitti> kees: oops, thanks; didn't come up in testing
<kees> I think we'd be better have a perl module that lives in -base that implements all these common uses
<pitti> kees: as I said above, for the more complex ones we might actually just split them out from perl-modules
<pitti> so that we can install them separately
<kees> okay.
<pitti> kees: fortunately most packages just look like http://launchpadlibrarian.net/58895007/foomatic-filters_4.0.5-0ubuntu3_4.0.5-0ubuntu4.diff.gz
<kees> pitti: heh, good. apparmor-utils seems to make up for it. :) 6 things from -modules or perl itself. :)
<pitti> I'll keep that for later then :)
<kees> heh
<pitti> kees: I'll start with the simple libraries, they should be easy, and can collect necessary stuff along the way
<kees> have you replaced File::Temp anywhere yet?
<pitti> no
<pitti> I touched some 6 packages so far, 4 were trivial (just add -d), one required a simple code change, and doc-base was the one nontrivial one so far
<pitti> kees: (doc-base fixed, FTR, thanks for spotting)
<kees> pitti: cool
<SpamapS> RoAkSoAx: darn, no failure with the updated tar
<kees> pitti: oh, actually, sorry, it's still wrong. File::Path::mkpath's $mode is filtered by umask where as mkdir -m is not.
<pitti> kees: but it's just a cache from public doc data..
<apw> pitti, whome owns the launchpad-janitor scripting ?
<pitti> I think having that directory 700 would be wrong
<pitti> apw: launchpad?
<pitti> apw: you mean the thing that autocloses bugs and so on?
<apw> pitti, yeah indeed ... my real question is, is there a way to say 'really don't close this bug' so that we can have a proposed kernel with two uploads, the first one closes a bug and the second reopens it ...
<apw> and if there isn't do we think that they would accept a new syntax to allow that
<pitti> apw: accepting into proposed doesn't close bugs
<pitti> just when they get moved to -updates
<apw> pitti, right ... exactly but when it does go into -updates everying in the changelog which is all proposed versions in one block via -v<old updates version> get processed and closed
<pitti> apw: correct
<pitti> apw: so the followup upload has to change the changelog accordingly to not mention the dropped patches any more
<apw> pitti, and i want to be able to close a bug in the first -proposed upload, but undo it in the second -propoesed upload ... so that the bug is not closed when moving to -updates
<pitti> we can't close bugs in the first upload
<pitti> they aren't fixed if they are only in -proposed
<apw> pitti, so it is acceptable to hand edit the changelogs to drop the LP: bits from the first upload to proposed to ensure they don't close on move to updates ?
<pitti> apw: there is no actual need to start a new changelog record, though; you could just bump the existing one and drop stuff
<apw> pitti, yep ... get you on the proposed not doing anything bit
<apw> pitti, that is acceptable ?
<pitti> apw: that works for me as well
<pitti> whatever is more convenient
<pitti> i. e. update the first changelog record, or add a new one for the new version and just retro-fix the previous one
<pitti> the former would look less confusing to users, though
<apw> pitti, doesn't that mean that our changelog sort of lies ?
<pitti> apw: not really IMHO; the bits that get released to -updates never had the dropped changes after all
<pitti> apw: but as I said, I'm also fine with your method
<apw> pitti, ok thanks
 * pitti waves good night for real now
<RoAkSoAx> SpamapS: weird then
<cjwatson> kees: BTW, best not to do any of this (perl-base -> perl) unless you have to, IMO - I don't think we should be aggressively doing it for stuff not on the CDs
<cjwatson> apw: why list them in the -proposed upload in the first place, then?  Why not just say "see LP #nnnnnn" (or some similar syntax which carefully doesn't match the close regex) if you just want to refer to it?
<bilalakhtar> pitti: So this means that there won't be a debian/changelog in ubuntu packages from now on?
<apw> cjwatson, well we are uploading a -proposed with them in where they should close, then if they fail testing we revert them and want them not to close any more... seems the appropriate thing is to as you say change that first reference from LP: xxx to SEE: xxx and we'll be golden
<bilalakhtar> BTW, why is -proposed frozen?
<cjwatson> apw: so you're not unconditionally leaving them open in -updates, only if -proposed fails?
<cjwatson> bilalakhtar: be careful about the distinction between debian/changelog (source packages) and changelog.Debian.gz (binary packages).  pitti's work only affects the latter (and there's open TB discussion about it)
<cjwatson> bilalakhtar: -proposed is frozen to assist the Linaro 10.11 release
<bilalakhtar> cjwatson: okay, thanks
<cjwatson> or was frozen, I think I saw slangasek saying he was OK with it being unfrozen nowish
<apw> cjwatson, we are marking them for closure yes in the first upload to -proposed, then we re-upload to -proposed undoing the commits which didn't work (or could not be verified) so we have a changelog block which has them closing and one which reverts that change.  when that moved to -updates it would erroneously close (via the janitor) so we were checking how to best avoid the bad close.  it seems effecticly removing the bug numbers from the first ch
<apw> angelog section is the right approach
<cjwatson> or you could just reopen after the janitor closes them
<cjwatson> consider how much technical work is worth it :)
<cjwatson> technically, a reupload ought to require some degree of reverification, which is expensive
<apw> cjwatson, heh indeed, i think updaing the references in the old is easier than touching all the bugs as we can script the former
<apw> cjwatson, yes, and the regression testing is meant to occur on the second upload to give us more confidence
<lool> Hmm any idea why postgresql-9.0 isn't in natty?  I see it has been in unstable for ~20 days, perhaps we only sync packages which made it to testing?
<cjwatson> you can script the latter too ... :-)
<cjwatson> lool: no, it's because it delivers at least one binary package (libpq-dev I think) which is also in natty built by another source package.  I asked pitti about it and he said he wasn't sure if he wanted to switch to 9.0 yet
<cjwatson> lool: testing isn't related
<cjwatson> apw: sounds like a lot more work to me, but as you like ...
<lool> cjwatson: Ok; thanks for the explanation, I remember you also mentioned that in your email, just didn't think of this explanation
<robbiew> cjwatson: so http://cdimage.ubuntu.com/ubuntu-server/daily/current/ has server images for Mac/PPC32/PS3...was this done on purpose?
<robbiew> consolidation?
<cjwatson> robbiew: yes, https://blueprints.launchpad.net/ubuntu/+spec/ubuntutheproject-foundations-n-cdimage-ports-consolidation
<cjwatson> killing off the ports directories in general
<robbiew> ah ha!  I knew there was a blueprint
<robbiew> couldn't find it
<robbiew> thanks!
<robbiew> cjwatson: so from a QA perspective, did we agree to test these as well?
<cjwatson> (though the exact set of images being built may well change ...)
<cjwatson> certainly not, no
<robbiew> cool
<robbiew> hggdh: ^^^
<cjwatson> there's a separate blueprint somewhere for what we should be testing
<cjwatson> this was just reorganisation of what we were already building
<cjwatson> mind you, *somebody* should be on the hook to test anything we build
<cjwatson> but it shouldn't necessarily be Canonical QA
<hggdh> cjwatson, robbiew: thanks
<robbiew> cjwatson: ack
<robbiew> agreed
<robbiew> cjwatson: so much for me requesting PS3s for the Server team
<robbiew> lol
<ajmitch> robbiew: surely you could get a few PS3s donated to willing community members to test? :)
<robbiew> heh...they don't even support Linux as another OS anymore ;)
<cjwatson> robbiew: :-)
<cjwatson> yeah, I think ps3 was slated to be EOLed, I'm just waiting for somebody who purports to be authoritative for that port to tell me - don't like doing it by fiat
<robbiew> cjwatson: so who's authoritative for PS3?
<cjwatson> robbiew: good question.  I passed it on to somebody called IIRC Tiago Faria a while back, but I don't know who took it from there
<wgrant> pitti: Hm, that's unfortunate.
<jdstrand> sbeattie: fyi, apparmor hit maverick-proposed
<sbeattie> jdstrand: cool, thanks
<lifeless> sladen: hi
<sladen> lifeless: hello
<highvoltage> hi lifeless and sladen!
<mathiaz> cr3: http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html
<mathiaz> cr3: ^^ this is the SRU tracker I mentioned
<cr3> mathiaz: thanks, zul actually answered me. email sent to victorp for his information
<bdrung> kirkland: thanks for the merge. can you move the errno tool from u-d-t to bikeshed?
#ubuntu-devel 2010-11-10
<psusi> I'm trying to reproduce a bug reported installing grub on a usb disk, but when I try with my 8 gb flash stick, ubiquity does not list the drive ( sde ) as an option.  It is mentioned in the partman log files as being discovered, but ubiquity hides it.  Does it hide usb flash drives on purpose?
<cjwatson> it hides the disk you're installing from on purpose
<cjwatson> since there are going to be serious limitations on partitioning it and attempts to do so usually lead to enormous confusion and bug reports
<james_w> SpamapS, barry: https://lists.launchpad.net/pkgme-devs/msg00000.html
<psusi> cjwatson, that's what I thought, but I booted from a cdrom and tried to install to the usb stick
<james_w> SpamapS, barry: may I suggest you join https://launchpad.net/~pkgme-devs and subscribe to the mailing list?
<psusi> maybe I messed up and booted from the wrong one... I'll give it another go when I finish writing up this wiki entry on LVM
<barry> james_w: done. thanks for the write-up
<james_w> thanks
<adamsa> hi i am trying to develop and test my software on 64bit ubuntu but libmudflap64 is only compiled / available for i386? ... so i get errors about real_munmap etc. --> has anyone else found this?
<adamsa> (10.10)
<micahg> adamsa: you might be looking for libmudflap0
<maco> seriously? theres a lib named that? O_o
<adamsa> i have that installed, that isn't the issue, i also have gcc-multilib and the -dbg packages etc.
<micahg> adamsa: #ubuntu-app-devel might be a good resource for you
<adamsa> perhaps but i was hoping a dev here already hit it ...
<adamsa_> fixed it --> broken symlink :) reporting bug
<wgrant> pitti, cjwatson: Is there any reason we would ever need to accept an upload in any pocket of an obsolete series?
<pitti> Good morning
<pitti> wgrant: we should never accept an upload into a released series, obsolete or not; and for the other pockets they should always land in unapproved
<RAOF> Aloha pitti
<pitti> wgrant: there might be a corner case where we do accept a package into an obsolete series, like a fixed update-manager or whatnot
<pitti> hey RAOF
<wgrant> pitti: Right, I (and Launchpad, fortunately...) know about the supported/current pocket restriction. But it would be convenient if we could just reject anything for an obsolete series.
<wgrant> I guess I'll just make it behave like supported/current.
<RAOF> You'll be happy to know my local libgl1-mesa-dri package now takes up 30MB less on-disc :)
<pitti> RAOF: oooh! *hug*
<pitti> RAOF: dynamic linking FTW?
<RAOF> Indeed.
<RAOF> That's without stripping out any of the lesser-used DRI drivers.
<pitti> RAOF: I guess these just take ~ 200 kB now?
<ebroder> pitti: by the way, libnss-mdns's perl dependency is completely bogus. it just uses perl -i in the postinst
<pitti> ebroder: nice
<ebroder> but i think apparmor is going to be our downfall
<RAOF> Mmm, mga is as big as 330kB :)
<pitti> ebroder: yes, that's going to be tough
<pitti> RAOF: heh
<RAOF> So there's ~1MB to be claimed by sacrificing the lesser-used drivers.
<pitti> RAOF: I think that's much less urgent now
<pitti> RAOF: but we can shelve that idea for a later cycle when we get desperate again :)
<RAOF> :)
<dholbach> good morning!
<\sh> Riddell: kirkland: Testing bug #533369
<ubottu> Launchpad bug 533369 in debootstrap (Ubuntu Lucid) "Fails to debootstrap squeeze chroot due to missing apt-get" [Undecided,Fix committed] https://launchpad.net/bugs/533369
<\sh> Riddell: tested bug #533369 and it works...please see the my comment
<ubottu> Launchpad bug 533369 in debootstrap (Ubuntu Lucid) "Fails to debootstrap squeeze chroot due to missing apt-get" [Undecided,Fix committed] https://launchpad.net/bugs/533369
<pitti> ebroder: thanks for the gst-plugins-base0.10 fix! can you please send this to Debian as well?
 * ogra hugs RAOF ... thanks for bringing back the kbd driver
<ogra_ac> ouch
<ogra_ac> cjwatson, apparently i get a segfault trying to boorstrap natty on arm
<ogra_ac> *boot
<ogra_ac> it ends with:
<ogra_ac> W: Failure trying to run: chroot /mnt/natty-chroot dpkg --force-depends --install /var/cache/apt/archives/base-files_5.0.0ubuntu25_armel.deb /var/cache/apt/archives/base-passwd_3.5.22_armel.deb
<ogra_ac> looking at natty-chroot/debootstrap/debootstrap.log there is only "Segmentation fault" in it
<ogra_ac> ogra@ac100:/mnt$ sudo chroot /mnt/natty-chroot dpkg -l
<ogra_ac> Segmentation fault
<ogra_ac> hmm, seems to be dpkg
<ogra_ac> things like --help seem to still work
* bilalakhtar changed the topic of #ubuntu-devel to: Archive: Open | maverick-proposed is now unfrozen | 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
<cjwatson> ogra_ac: I saw the build failure, but I will need the arm team's help to debug it
<ogra_ac> cjwatson, oh, it didnt build ? i missed that
<cjwatson> the livefs build failure
<ogra_ac> strace doesnt show anything obvious http://paste.ubuntu.com/529305/
<ogra_ac> ah, k
<cjwatson> the change to lib/compat/scandir.c is the only one I can imagine being involved
<ogra_ac> hmpf, how do i run gdb on that
<cjwatson> not sure how that would have made anything *worse* though
<ogra_ac> running sudo gdb chroot /mnt/natty-chroot dpkg only gets me chroot backtrace ... and indeed i dont have gdb inside the chroot yet
<cjwatson> and you'll want dpkg-query anyway, since dpkg just execs that for -l
<cjwatson> try something like  sudo gdb --args /mnt/natty-chroot/usr/bin/dpkg-query --admindir=/mnt/natty-chroot/var/lib/dpkg -l
<cjwatson> in fact I suspect you won't even need --admindir
<ogra_ac> ah, yeah, that seems to be better ... i need the ddeb though
 * ogra_ac goes fiddling
<cjwatson> hm, actually, I don't see how it can be scandir either
<cjwatson> if it were due to that patch, we'd at least see it opening /var/lib/dpkg
<ogra_ac> it does that if i dont use -l
<cjwatson> well, let's try to explain one segfault at a time though
<ogra_ac> http://paste.ubuntu.com/529315/
<ogra_ac> thats for the command debootstrap tries to run
<cjwatson> still not in scandir
<cjwatson> that's just lock stuff in filesdbinit
<ogra_ac> ah, k
<cjwatson> I mean modstatdb_init
<ogra_ac> geez
<ogra_ac> SIGILL
<ogra_ac> http://paste.ubuntu.com/529317/
<ogra_ac> oh
<cjwatson> maybe executing natty binaries directly from whatever your host system is is not in fact a recipe for glorious success?
<ogra_ac> running "run -l 2>&1 | tee ~/gdb-dpkg.txt" gets me proper output
<cjwatson> in which case, copy your gdb binary into your chroot and hope it doesn't need too much else :-)
<ogra_ac> same command but 2>&1 | tee ~/gdb-dpkg.txt added
<ogra_ac> hmm, weird, that seems to have run on the host
<ogra_ac> and now it works every time
 * ogra_ac doesnt get that
<ogra_ac> yeah, it now seems to access the hosts database etc
<ogra_ac> now it doesnt anymore
<ogra_ac> hrm, whats up here
<ogra_ac> using run -l one time accesses the host and the next time it doesnt
<ogra_ac> and its not reliable reproducable
<ogra_ac> i guess i better build a maverick chroot, upgrade that and run all that stuff fully chrooted
 * ogra_ac tries that
<roxdragon> hi
<bilalakhtar> pitti: Speaking about bug #323815, I fixed it long ago in bug #616569 but it appeared that the patch modified the UI file, and a subroutine later set the title back to "" . Do you think I am right? I have a fix ready in a branch
<ubottu> Launchpad bug 323815 in jockey (Ubuntu) "Install progress window has no title" [Low,In progress] https://launchpad.net/bugs/323815
<ubottu> Launchpad bug 616569 in jockey (Ubuntu) "hardware drivers shows window called untitle windows at scaning/download drivers (dup-of: 323815)" [Low,Fix released] https://launchpad.net/bugs/616569
<ogra_ac> cjwatson, so upgrading a mavercik chroot to natty i dont get any issues and given that dpkg under gdb with a half debootstrapped chroot behaves differently at every run i'm inclined to suspect a race
<pitti> bilalakhtar: I saw your MP, will follow up there after lunch; thanks!
<bilalakhtar> pitti: you're welcome
<cjwatson> ogra_ac: it could be something that only breaks with certain status files
<ogra_ac> well, i can run it under gdb and get different results every run, do the status files change every time ?
<ogra_ac> i would have assumed its the same one
 * ogra_ac tries another debootstrap to monitor the status file 
<cjwatson> you're the one best placed to figure out what the problem is I suspect
<cjwatson> but it happened to every armel debootstrap attempt in today's livefs builds, as far as I can see, so if it's a race then we normally lose it
<ogra_ac> right, its reliably failing in debootstrap, just not in gdb
<ogra_ac> cjwatson, got it !
<ogra_ac> cjwatson, the status file in natty misses a final newline
<ogra_ac> err, no, sorry to many chroots around, i looked at the wrong one
<roxdragon> !bug
<ubottu> If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.ubuntu.com/ IRC is not a good medium to report bugs and this channel is for development coordination.
<cjwatson> roxdragon: were you talking to ogra_ac?  he and I are discussing this problem, it's fine for it to stay here
<ogra_ac> wow
<ogra_ac> copying the status file from the host makes it not segfault
<ogra_ac> so i guess you are right
<roxdragon> yes cjwatson  ;)
<ogra_ac> copying the old one back gets me the segfault back
<ogra_ac> copying the one from the upgraded maverick chroot works too
<roxdragon> hi 11.04 testing?
<ogra_ac> cjwatson, soo ... weird but true, the segfault vanishes if i manually add Maintainer and (short) Description to the status file
<cjwatson> that's interesting, because there was a change in that area in 1.15.8.5 - but we'd already backported it to maverick as 1.15.8.4ubuntu2 a few months ago
<ogra_ac> http://paste.ubuntu.com/529332/
<ogra_ac> well, did we bootstrap any images since ?
<cjwatson> every livefs build, yes
<ogra_ac> weird
<ogra_ac> it reliably fails if i remove either of the fields
<cjwatson> can you tar up the broken /var/lib/dpkg (without your workaround) and put it somewhere for me?
<cjwatson> I can see if I can reproduce it on kakadu, for instance
<ogra_ac> i can just bootstrap a fresh one one sec
<stgraber> Is it possible that icedtea6-plugin as been deprecated in favour of icedtea-plugin ? it's making the edubuntu daily build to fail because icedtea-plugin is pulled by something and conflicts against icedtea6-plugin (which is explicitly seeded)
<stgraber> from what I see in the seeds, it should affect all DVD builds, not only Edubuntu
<cjwatson> yes, but it's a bug that it fails this way
<cjwatson> the Conflicts in icedtea-plugin should be versioned to less than the version where it became a transitional package - could you make sure that there's a bug filed on icedtea-web about this?
<cjwatson> shows up in http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html too
<stgraber> ok, I'll quickly check if someone already reported it and if not, will file a new one
<stgraber> should the seeds be changed to icedtea-plugin anyway ?
<cjwatson> yeah
<stgraber> bug 673524
<ubottu> Launchpad bug 673524 in Ubuntu "Unversioned conflict between icedtea-plugin and icedtea6-plugin making transitional icedtea6-plugin uninstallable" [Undecided,New] https://launchpad.net/bugs/673524
<stgraber> argh, forgot to open against icedtea ... fixing that
<stgraber> (was doing an ubuntu-wide bug search before, so "File a bug" opened it against ubuntu ...)
<ogra_ac> cjwatson, natty-cjwatson-dpkg.tgz in /home/ogra on kakadu
<cjwatson> I really did just need /var/lib/dpkg, but thanks :)
<ogra_ac> heh
<ogra_ac> note that chroot is using my local mirror
<ogra_ac> well, approx instance
<ogra_ac> so sources.list and apt lists might differ
<cjwatson> I removed everything except /var/lib/dpkg so it doesn't matter
<ogra_ac> k
<cjwatson> building a debug dpkg now
<lool> doko, cjwatson: Hey, how much do you two care about lp:~ubuntu-core-dev/eglibc/eglibc-2.12-pkg ? I currently can't branch from it (some bzr error when doing on the fly format conversion) so I was about to upgrade it, but I wonder whether we should just abandon it and move to lp:ubuntu/eglibc instead
<cjwatson> lool: I haven't touched it for some time
<doko> it works for me
 * lool upgrades the old packaging branch to see if anything needs to be rescued fro mthere
<ScottK> ogra_ac: I'm catching up on yesterday's IRC logs and saw the discussion you had with Riddell/NCommander on arm status.  Currently none of the arm FTBFS are due to the qreal issue, they are all due to the CXXFLAGS issue that doko is looking into.
<ScottK> ogra_ac: Upstream KDE accepts that the qreal issues we see are valid bugs that they shouldn't cause.  I'm working on an upstream KDE arm buildbot so they can discover this stuff before we get it here and the amount of rework we need to do in the future will be reduced.
<ogra_ac> ScottK, upstream QT agrees that it should be fixed in QT though
<ScottK> ogra_ac: Yes, but in Qt5.
<ogra_ac> they just cant do that atm for historical reasons
<ScottK> We can't either for the same reasons.
<ogra_ac> and asked us a year ago to carry it as a distro patch for armel only
<ogra_ac> its just insane that we spend several mandays every release to adjust the application patches
<ogra_ac> and i really expect that to hit us again once the flags are fixed
<ScottK> ogra_ac: It's not adjusting application patches.  The ones we find are all upstreamed, the problem is new occurences.
<ScottK> That's why I hope that if we can build the upstream source regularly, before we get it, the amount of trouble we see will go down.
<ogra_ac> right, still i would like us to fix the core of the prob if thats possible
<ogra_ac> and according to linaro it isnt to hard
<ScottK> Isn't hard to fix and maintain ABI?
<ogra_ac> it would break the ABI on arm
<ogra_ac> but only there
<ogra_ac> and given that we rebuild the world anyway i doubt it matters much
<ScottK> Not all software lives in the Ubuntu archive.
<ogra_ac> as ?
<ogra_ac> for binary compatibility you have to rebuild anyway
<ScottK> I don't intend to get into a debate about how which apps that aren't in Ubuntu are used on arm.  Use of third party repositories is quite normal and supported.
<ogra_ac> and ISVs dont offer any ubuntu arm stuff
<ScottK> And vendors are all we care about?
<ogra_ac> no
<ScottK> ogra_ac: I think we will have to agree to disagree on the importance of maintaining ABI.
<ogra_ac> well, asac is tasked to talk to thiago next week in person aboout it
<ogra_ac> lets see what comes out of that
<ScottK> I did want to let you know that I'm working on getting these qreal problems more visibility in upstream KDE so there is some reason to expect it to get better.
<ScottK> OK.
<doko> ScottK, Riddell: the current CXXFLAGS "problem" is one in qt
<ogra_ac> i want to follow what upstream suggests here
<ogra_ac> (who were first in suggesting the change to us initially)
<ScottK> doko: Right, the question is what to do about working around it.  Do we have to modify debian/rules for several dozen packages or will it go back in defaults.
<doko> pitti: why the limitation to 10 changelog entries? I would prefer to keep the entries of the current and the last release
<doko> ScottK: so when would you change it?
<ScottK> doko: You are asking when we'd stop carrying the work around?
<pitti> doko: well, you can define an arbitrarily complex condition which ones to keep; 10 should be quite enough to see the recend development?
<doko> pitti: well, make it the maximum of 10 and what I propose.
<doko> apt-listchanges should still work
<doko> for distro upgrades
<ebroder> pitti: thanks for the sponsorship. i'll be sure to forward the patch on
<doko> pitti: do you re-join the MIR team?
<apachelogger> jcastro: ping, do you happen to know whether the audio streams from uds got recorded?
<jcastro> I don't think they did
<ogra_ac> oh, that will make NCommander cry
<ogra_ac> he lost his notes
<jcastro> gobby accident?
<ogra_ac> no idea
<ogra_ac> gobby doc is empty
<ogra_ac> so might well be
<ogra_ac> or notes were taken locally and lost
<apachelogger> having recordings would be very useful indeed, notes can be too limiting on complex matters ^^
<tumbleweed> apachelogger: I have recordingns of the second half, http://mirrors.tumbleweed.org.za/uds-n/
<jcastro> apachelogger: someone from IS would be the best to ask
<apachelogger> tumbleweed: groovy, cheers
<barry> mvo: hi!  have you seen: https://code.launchpad.net/~barry/update-manager/673297-py27/+merge/40510
<apachelogger> jcastro: something to look into for next UDS for sure
<mvo> barry: no, looking now
<pitti> doko: fixing apt-listchanges is on the TODO list
<pitti> ebroder: thanks
<pitti> doko: wasn't planning to actually; SRU kills too much of my time already
<jcastro> mvo: we're so close, all you need to do now is enable the apt zeroconfing bits by default!
<ScottK> doko: I know the proper fix for the Qt IT issue is to implement it upstream, but in the mean time, do you want us to modify all the affected packages or will you put it back in the GCC defaults?  We can do either, we just need to know.
<psusi> pitti: weren't you working on auto mount of esata drives?  I did some digging and it seems that AHCI has the ability to report that a port is external, but the kernel driver doesn't bother checking that bit
<pitti> psusi: "working" is a bit too much; I looked at it back then, and found that there's currently no way to tell
<pitti> if this can be exported in /sys, that'd help much, of course
<highvoltage> doko: hey, are you around?
<micahg> pitti: is there a problem w/SRUing new binaries either through -updates or -security?
<pitti> micahg: not a technical one, but we try to avoid it if at all possible
<ScottK> pitti: It's for new translations (why he's asking)
<micahg> pitti: the case is newer thunderbird translations when we move to Thunderbird 3.1
<micahg> * extra languages
<pitti> that sounds fine
<micahg> pitti: ok, thanks
<cjwatson> barry: gnome-python and dbus-python uploaded
<cjwatson> Keybuk: so, watching with dbus-monitor - am I right in believing that there are dbus signals for job instances being added and removed, but that that doesn't really necessarily correspond to jobs being started and stopped (for plymouth integration)?
<cjwatson> Keybuk: maybe a signal for each state change or something would be best?
<Keybuk> right, that might be the "missing piece"
<psusi> pitti: that is what I thought... the external bit should be exported somehow in /sys so you can tell it should be auto mounted... but I also thought even if the hardware can't tell us the port is external, if a sata drive appears after boot, maybe we could pop up and ask the user if that port is external, and set a persistant storage rule to set the extern flag anyhow for future use
<Keybuk> state is a property, so it'd be a property changed signal
<cjwatson> one of these days I must learn dbus properly
<cjwatson> slightly embarrassing
<ogra_ac> use dfeet :)
<cjwatson> is property-changed a standard thing?
<cjwatson> I know about d-feet; my comprehension hole is a bit more general
<cjwatson> hm, PropertyChanged ought not to require specific upstart support from what I'm seeing
<cjwatson> PropertiesChanged that is
<slangasek> could someone here who writes better German than me fix http://wiki.ubuntuusers.de/Plymouth to not include made-up "noplymouth" boot options?
<cjwatson> actually maybe it does need a bit of upstart support
<Keybuk> cjwatson: huh?
<Keybuk> yeah it needs libnih-dbus support or upstart support or something
<Keybuk> as I said at UDS, I couldn't remember whether I put it in there or not
<Keybuk> and if I didn't, it's literally a one-line patch
<cjwatson> Keybuk: wouldn't it need everything that does job->state or equivalent to be converted to using a setter function of some kind?
<Keybuk> fortunately I am a kick-ass, stellar programmer
<Keybuk> one of the best in the known universe
<Keybuk> and there is only one place in all of Upstart that changes job->state
<Keybuk> job_change_state()
<cjwatson> ./init/job.c:108:       job->state = JOB_WAITING;
<cjwatson> ./init/job.c:289:               job->state = state;
<Keybuk> which is pretty much the core function as far as jobs go, in fact
<cjwatson> oh, you meant one function :-)
<Keybuk> the first one of those is job_new() so doesn't count
<cjwatson> fair point
<cjwatson> and I don't think we need to know about goal changes
<Keybuk> no, indeed
<cjwatson> in that case I concede your self-aggrandisement ;-)
<Keybuk> all you should need to do is add a signal tag to dbus/com.ubuntu.Upstart0_6.Instance.xml
<Keybuk> then add a function call in job_change_state
<Keybuk> err, dbus/com.ubuntu.Upstart.Instance.xml
<Keybuk> something like
<cjwatson> dbus 1.4 made PropertiesChanged a standard signal on org.freedesktop.DBus.Properties
<cjwatson> do you want to follow that?  since if so it shouldn't be in com.ubuntu.Upstart0_6.Instance.xml AIUI
<Keybuk> yeah, but that would need teaching libnih-dbus about it
<Keybuk> which would be ... harder
<Keybuk> for 0.6, may as well just add a custom signal
<cjwatson> ok, fair enough
<cjwatson> I should be able to manage the rest of that then, thanks
<Keybuk> so if you have
<Keybuk> <signal name="StateChanged">
<Keybuk>   <arg name="state" type="s">
<Keybuk> </signal>
<Keybuk> or sometihng
<Keybuk> then the matching function call in job_change_state() would be
<Keybuk> NIH_LIST_FOREACH (control_conns, iter) {
<Keybuk>   NihListEntry *entry = (NihListEntry *)iter;
<Keybuk>   DBusConnection *conn = (DbusConnection *)entry->data;
<Keybuk>   job_emit_state_changed (conn, job->path, job_state_name (job->state);
<Keybuk> }
<Keybuk> ok
<Keybuk> a bit more than one line to cope with the multiple connections
<cjwatson> and I get to write the boring test case, right? :)
<Keybuk> yup :p
<bilalakhtar> doko: there? It appears that you recently NMUed a change to package libtuxcap in Debian. Yet, the change wasn't made, could you please check?
<cjwatson> Keybuk: would you prefer separate tests for the case where a dbus connection is open, or shall I just extend test_change_state to check signal emission in each test along the way?
<cjwatson> I started with the former but I think the latter might be less wordy
<Keybuk> there's a *LOT* of test cases in test_change_state
<Keybuk> it depends whether you want to "test that a signal is emitted for a state change"
<bilalakhtar> How do I try and find out the changes made to a debian package in a particular version?
<Keybuk> or "test the specific set of signals are emitted for each given state change"
<Keybuk> e.g. in test_change_state you're going to have to deal with the cases where a job undergoes multiple state changes in any one test
<bilalakhtar> its difficult to navigate through Debian packages as they don't have something like LP for all packages
<Keybuk> so check for multiple signals
<cjwatson> the interaction between StateChanged and InstanceRemoved seems slightly worth testing
<cjwatson> bilalakhtar: packages.qa.debian.org/<package> may be helpful
<Keybuk> I've tended so far (iirc) to just test the signals are emitted independantly of the state mechanics
<bilalakhtar> cjwatson: but it doesn't show the debdiff between versions
<Keybuk> but icbw, haven't looked at those tests in a while
<tumbleweed> bilalakhtar: snapshot.debian.org
<dannf> bilalakhtar: if you need to compare actual source (not trusting the changelog) you can pull versions from snapshot.debian.org & debdiff 'em
<bilalakhtar> thanks tumbleweed and dannf
<bilalakhtar> dannf: yes, I am sure a changelog entry is misleading
<cjwatson> bilalakhtar: or http://patches.ubuntu.com/by-release/atomic/debian/, or bzr get lp:debian/<package>
<lool> doko: I started reviewing the Debian -> Ubuntu eglibc diff, and I'm now trying to minimize it to ease merges and be in a position to document what changes we carry over Debian; do you mind if I drop lpia support in the next natty eglibc upload?
<kees> hallyn: say, where is the code in the kernel for "if both fscaps and setuid, ignore setuid"?
<kees> hallyn: ah, found it: b5f22a59c0356655a501190959db9f7f5dd07e3f
<bilalakhtar> doko: so the libtuxcap debdiff between your NMU and the previous one doesn't contain the B-d change
<hallyn> kees: why, has that been accidentally undone?
<bilalakhtar> please look at it, since the patch is now made to modify the thing according to 2.6, but the package doesn't b-d on 2.6
<kees> hallyn: no, I just wanted to point it out to someone (oss-security mailing list discussion on filesystem capabilities)
<psusi> pitti: is it /sys/block/sda/removable that is checked to see if the drive should be auto mounted?
<pitti> psusi: yes
<pitti> psusi: that and the drive type (USB/firewire are removable)
<psusi> hrm... looking at the scsi layer code, it seems that removable really means that the MEDIA can be removed... but what we're dealign with is really hot plugging the hole drive, so flagging it as removable doesn't really seem correct
<pitti> psusi: ah, right
<pitti> psusi: we need a new flag for that then
<pitti> psusi: so far udisks considers the bus type for the "hotpluggable" property
 * pitti -> Taekwondo and off for the night, see you tomorrow
<psusi> o/
<lool> doko: Similary, do you care to keep the sparc flavors?
<mdz> tkamppeter, around?
<tkamppeter> mdz, hi
<mdz> tkamppeter, I've brought home an HP DeskJet 3050 which requires hplip 3.10.9. do you know when the new version will be available in Debian and Ubuntu?
<mdz> tkamppeter, or maybe in a ppa?
<ScottK> ogra_ac: Someone hand built the rest of KDE on Natty with implicitIT=thumb and they didn't hit any qreal porting issues, so at least so far that doesn't seem to be an issue in Natty.
<arek_deepinit> can anyone tell me what is default version of glib installed with 10.04?
<arek_deepinit> please
<ajmitch> arek_deepinit: from the look of things, 2.24.0 in lucid, 2.24.1 in lucid-updates
<cjwatson> ~.
<cjwatson> ~.
<arek_deepinit> great, thx ajmitch
<ion> cjwatson: Itâs beneficial to switch to something like the status window first, otherwise thatâs bound to happen sooner or later. ;-)
<cjwatson> ion: drat
<cjwatson> (for the record, that was the fault of https://bugs.maemo.org/show_bug.cgi?id=6009, which still isn't fixed ...)
<ubottu> bugs.maemo.org bug 6009 in X Terminal ""Enter" key sends wrong keycode to console applications" [Normal,New]
<NCommander> ogra: I already told you that yesterday ;_P
<Drakeson> is appmenu broken with emacs ?
<Drakeson> Where should I discuss issues with Unity?
<mwhudson> Drakeson: it works ok for me i think?
<mwhudson> not that ever actually use the menu in emacs at all ever
<Drakeson> mwhudson: oh, mine has a serious problem leading to segfault
<Drakeson> for example, if I switch to another buffer the menu does not change
<mwhudson> ah yeah, seems you're right there
<mwhudson> doesn't segfault for me though
<Drakeson> It doesn't segfault immediately
<Drakeson> it does after a while of usage
<Drakeson> I depend on emacs, so that is serious for me
<Drakeson> are Super+S and Super+M gone for good?
<Drakeson> Anything other than Super+1,2,...,Super+0 doesn't seem to work with Super.
<Drakeson> I have already tried #ubuntu-unity and #unity.  Where else should I seek the culprit(s)? :p
<kklimonda> I've reported one bug on appmenu-gtk where some emacs menus are empty
<kklimonda> Drakeson: I'd report a bug
<Drakeson> kklimonda: sure, only if I know which package is the faulty.  I cannot figure out the relation between appmenu, appmenu-gtk, libfamd, and a couple more.
<Drakeson> could you please direct me to the unity channel?
<kklimonda> Drakeson: when it crashes it should generate a report (if it doesn't enable apport and recreate it) and you can send it to launchpad
#ubuntu-devel 2010-11-11
<psusi> what's the incantation to get emacs into the style mode of the kernel again?
<Drakeson> psusi: ?
<psusi> so it does things like use hard tabs to indent instead of 2 spaces
<cjwatson> psusi: it's in Documentation/CodingStyle
<Drakeson> is emacs-snapshot older than emacs23?
<kklimonda> looks like it
<ebroder> cjwatson: reading the foundations team logs. in addition to the packaging probably needing some love, i've tested not yet tested the whole patchset together (just the individual pieces). just fyi
<cjwatson> ebroder: gotcha
<cjwatson> been distracted by upstart/plymouth anyway
<Drakeson> Was there a huge recent change regarding compiz and the indicators?  I don't seem to have the indicator applets anymore.
<RAOF> Drakeson: There was the upload of compiz 0.9; that's a big compiz change.
<psusi> well holy crap... I wrote a kernel patch and it compiled on the first try
<psusi> now to see if it /works/ ;)
<psusi> wow... it worked...
<TheMuso> psusi: It must have been a one-liner. :)
<psusi> TheMuso, heh, actually was adding a few bit flags that weren't defined to headers, then cloning some sysfs functions to export them and modifying them to work with the new flag
<TheMuso> Well, close.
<psusi> so not that much, but not exactly a one liner either... still amayzed it compiled AND worked on the first try
<psusi> now to see if it correctly reports true for the external status of the esata port on my laptop... desktop doesn't have an external port...
<psusi> AHAH!  IT WORKS!
<psusi> cat /sys/devices/pci0000:00/0000:00:1f.2/host2/scsi_host/host2/achi_port_external -> 1
<chrisa> What package do I need to actually do a build-dep on to get all the dependencies of newer gccs? I can do build-dep gcc-4.1 for instance, but gcc-4.3, gcc, etc don't seem to work out
<steev_> sorry to intrude, but to which channel would i go for assistance in packaging an application for ubuntu?
<RAOF> steev_: Either #ubuntu-motu or here (if you're aim is to get the package into the official archives) or in #ubuntu-packaging if it's just for a PPA.
<steev_> thanks RAOF
<ebroder> does the intel driver do its own round of mode setting when X starts, even with KMS?
<ebroder> (is this configurable somehow?)
<RAOF> ebroder: No; once KMS is in use, the kernel is the only thing that can do modesetting without making everything fall down in a screaming heap.
<ebroder> RAOF: hmm...ok, maybe i understand this less well than i thought. if i have an intel gfx machine, and i boot it with multiple monitors plugged in, KMS appears to set the mode correctly (and independently for the two monitors), then when X starts something switches it into cloned mode
<RAOF> ebroder: That starting X *will* cause the X driver to probe available modes from the kernel, and then X will make its own decision as to the best mode, possibly triggering the intel driver to delegate a modeswitch to the kernel.
<ebroder> ah, ok - right
<ebroder> i'm wondering if this is a piece of why people think multi-monitor is so non-deterministic
<RAOF> It is, a bit.
<RAOF> Hm.  Actually, it might be reasonable to delegate the clone-setting to the DE / login manager.
<ebroder> I don't suppose there's a way to change X's mode selection algorithm without hard-coding layouts and resolutions in xorg.conf?
<ebroder> (I know we decided to always clone at UDS; I happen to have a scenario where I want to always extend)
<RAOF> This is a case where delegating to gnome-settings-daemon would be the right thing to do.
<ebroder> That would certainly be awesome
<RAOF> Which is the X policy anyway.  I don't think there'd be a huge outcry against leaving the KMS-set mode until the settings daemon says otherwise.
<ebroder> And it's not like there'd be anything to show in place of plymouth before then
<RAOF> Right.
<psusi> cjwatson, you around?  I'm not sure but it looks like dist-upgrade to natty is broken because grub2 depends on a natty version of base-files, but base-files depends on a natty version of grub2-common, so dist-upgrade can't upgrade...
<psusi> weird.. third time is the charm I guess..
 * psusi sighs at the number of times things like update-grub and update-initramfs are still run during a dist-upgrade, despite dpkg-triggers
<freeflying> persia, ping
<ebroder> psusi: update-grub isn't triggerized, is it?
<c4pt> hi
<c4pt> i was reading an log of this irc channel and i had a similar question to what i was reading
<pipegeek> Hi, folks.  It looks like the kernel option CONFIG_SOUND_OSS_CORE was disabled lucid => maverick.  Why was that done?  I have some very old binaries that are oss-only, some of which open /dev/sequencer explicitly and which no longer work
<c4pt> YokoZar, hello, what do you think about updating the packaging of ia32-libs for mesa-dri-experimental? like it is done in xorg-edgers ppa
<c4pt> ricotz
<c4pt> ^^
<pipegeek> Also, disabling CONFIG_SOUND_OSS_CORE and friends breaks the oss-compat package.  I've filed a bug report
<YokoZar> c4pt: for 11.04?  I think I'm still waiting on multiarch
<pipegeek> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/60987
<ubottu> Launchpad bug 60987 in linux (Ubuntu) "Loss of sound devices (/dev/dsp /dev/mixer /dev/sequencer /dev/midi) (dup-of: 94333)" [Undecided,Incomplete]
<ubottu> Launchpad bug 94333 in linux-source-2.6.20 (Ubuntu) "[regression] sound card not working after clean install of Dapper, Edgy and Feisty" [Low,Won't fix]
<c4pt> YokoZar, well i am trying to install this on debian
<YokoZar> c4pt: relatedly I am putting together an ia32-libs update for the Wine PPA though
<YokoZar> that will contain all the gstreamer codecs
<YokoZar> yum
<c4pt> YokoZar, and xorg-edgers breaks X11 pretty bad when i let apt-get do its thing for that package
<pipegeek> errg.  WRong bug
<pipegeek> sorry
<YokoZar> c4pt: you mean if you do/don't have xorg-edgers ppa?
<c4pt> YokoZar, if i add xorg-edgers into debian squeeze sources and start installing stuff i can kiss my X11 goodbye eventually
<YokoZar> well yeah
<c4pt> YokoZar, but i just want two packages from it
<c4pt> lol
<YokoZar> but how would updating ubuntu's ia32-libs change that?
<c4pt> YokoZar, well i was searching around for someone who i could talk to . to give me an idea of what i can do?
<pipegeek> https://bugs.launchpad.net/ubuntu/+source/oss-compat/+bug/673845
<ubottu> Launchpad bug 673845 in oss-compat (Ubuntu) "snd-*-oss modules are not present, so this package does nothing" [Undecided,New]
<pipegeek> Should I also file a feature request to get kernel oss compat turned back on?
<c4pt> YokoZar, ive tried building mesa from sources (i got it working once or twice but i am overlooking a symbolic link somewhere or something isnt getting updated
<c4pt> YokoZar, i found this ia32-lib-mesa-exp packag on ubuntu one day for nouveau and its so simple its mindblowing
<c4pt> *package
<YokoZar> yes it's something that should be in ubuntu's ia32-libs
<YokoZar> but not as a backport, so it can be fine in its ppa atm
<c4pt> YokoZar, well how can i get it installed on debian?
<YokoZar> I really don't know, debian has quite a delta with ia32-libs
<YokoZar> and the 11.04 goal is to get rid of ia32-libs for multiarch, so I don't see the reason to futz around with it unless that gets delayed again
<c4pt> brb
<RAOF> Aww, man.  Proper multiarch.  Woot!
<ebroder> pipegeek: have you seen the padsp command?
<pipegeek> I do, but I'm not sure how useful that is in the case of things that need /dev/sequencer
<pipegeek> It's certainly not useful for things which explicitly *open* /dev/sequencer
<ebroder> pipegeek: oh, sorry. i thought /dev/sequencer was one of the things padsp faked
<pipegeek> I'm not sure.  I thought padsp just overrode calls to the oss API
<pipegeek> I thought it was an LD_PRELOAD hack
<ebroder> it is an LD_PRELOAD hack, but it works by intercepting open() calls for /dev/mixer, /dev/sndstat, and /dev/dsp
<pipegeek> oh neato
<pipegeek> :)
<pipegeek> OK, in any event..... is there a reason that was removed?  Is there a reason it shouldn't be turned back on?
<pipegeek> It is useful, now missing functionality
<ebroder> I can't speak to the decision-making process, but I can only assume it's because OSS has been deprecated for years, so it was finally time to put it out to pasture?
<pipegeek> I mean, I'm happy to build my own kernels for now, but .... a) if that was an intentional removal, then oss-compat should be removed from universe and b) I'd love to be able to partake in ubuntu security updates which I can't do if I'm rolling my own
<pipegeek> ebroder: Is anything (except maybe a few kB) lost by leaving it in?
<pipegeek> I know it's long since deprecated, but there are things that can't be rebuilt
<pipegeek> and projects that petered out years ago
<pipegeek> I'm a dreadfully unimportant case of this, but I'm sure there are others
<pipegeek> I don't think it's been taken out of debian unstable
<pipegeek> at the very least it'd be nice to have those modules there, even if they're not loaded by default
<ebroder> pipegeek: Honestly, I have no idea why it was actually taken out
<pipegeek> If I wanted to press the issue, what's the correct channel to go through?  Should I file a feature request?
<pipegeek> ebroder: yeah, and sorry for the textual deluge :)  I'm just disappointed
<ebroder> pipegeek: It's probably worth looking through the archives for the kernel-team mailing list to see if there's an explanation (http://lists.ubuntu.com/mailman/listinfo/kernel-team)
<pipegeek> OK.  Will do, and thanks
<RAOF> TheMuso will have insight into the process, if he's around.
<pipegeek> Is it alright (if I don't find a relevant thread) if I post to that list, or do I need to be an ubuntu developer or package maintainer?
<ebroder> https://lists.ubuntu.com/archives/kernel-team/2010-May/010647.html points to https://wiki.ubuntu.com/KernelTeam/Specs/KernelMaverickConfigReview points to bug #579300
<ubottu> Launchpad bug 579300 in linux (Ubuntu) "Please disable CONFIG_SOUND_OSS* and CONFIG_SND_*OSS*" [Wishlist,Fix committed] https://launchpad.net/bugs/579300
<pipegeek> https://lists.ubuntu.com/archives/kernel-team/2010-May/010647.html
<pipegeek> oh
<pipegeek> ehehe
<pipegeek> you beat mne :)
<pipegeek> there's a lot of unhappiness in that bug
<TheMuso> As as been said, OSS has been deprecated for ages. If your app still uses OSS and OSS only, then you need to find a new app, or request that the upstream author switches to ALSA or pulse, depending on what the app is, and who it targets.
<TheMuso> Unfortunately we ran out of time to get ossproxy in Ubuntu maverick, hopefully it will be in for natty.
<pipegeek> TheMuso: Does ossproxy handle /dev/sequencer?
<TheMuso> pipegeek: No I don't think it does, as PulseAudio doesn't deal with MIDI at all.
<pipegeek> TheMuso: which means anything that is trying to speak MIDI through OSS is now stranded.  ossproxy/padsp aren't complete replacements for oss emulation in the kernel.
<pipegeek> in my case, the app is a game whose maintainers stopped working on it ten years ago, and the svn repository went down a few years after that.  I am supremely unimportant, but I don't doubt there are other old binaries floating around
<TheMuso> Right, but OSS is deprecated.
<TheMuso> Hrm ok.
<pipegeek> Why not build the modules?
<pipegeek> they don't have to be loaded by default, but having them there is tremendously useful for the few who need them.
<pipegeek> and I believe they're still included in debian
<TheMuso> Well Ubuntu and Debian's kernels tend to be rather vastly different.
<pipegeek> hehe, fair enough
<pipegeek> but.... why cut people off from OSS before linus decides it's time?
<TheMuso> As for your use case, I think it bares consideration.
<TheMuso> i.e re-enable OSS emulation for MIDI only.
<pipegeek> that'd be nice :)
<pipegeek> but if that's being done anyway, why not include all the modules (perhaps as a separate, installable/buildable package, ala sshfs et al)?
<pipegeek> err, perhaps I shouldn't push my luck :)
<pipegeek> yes.  That would entirely solve my problem
<pipegeek> or a userspace LD_PRELOAD hack to reroute /dev/sequencer to /dev/snd/midi
<pipegeek> or something :)
<ebroder> pipegeek: Wait, does /dev/snd/midi exist and function as a drop-in replacement for /dev/sequencer?
<pipegeek> no
<ebroder> oh. ok :)
<TheMuso> ebroder: No, didfferent protocols etc, you have to go through alsa-lib to reliably use /dev/snd stuff.
<pipegeek> err, I don't know.  I'll try symlinking it and seeing if it works, but I really doubt the ioctls are the same
<pipegeek> ebroder: what TheMuso said :)
<ebroder> TheMuso, pipegeek: Got it. Sound is still on my list of "things where I vaguely know the terms but have no clue how they actually work" :)
<ebroder> (I need to fix that at some point...)
<pipegeek> TheMuso: Thank you very much for considering my case.
<TheMuso> I'll see what can be done.
<pipegeek> I really appreciate it.
<rocket16> Hello friends
<rocket16> Is it true that Ubuntu 11.04 will only have Unity as its default desktop?
<persia> rocket16, That's complex.
<persia> It's more true to say that "Ubuntu Desktop 11.04" will feature the Unity interface.
<rocket16> persia: Oh, I see. Then will GNOME be available by default as well?
<persia> rocket16, Unity is mostly atop GNOME.  I'm not sure what you mean by "available by default".
<rocket16> persia: Oh, many thanks. I just meant to say whether GNOME will be installed by default or not. But your answer already answered my question. Thanks. :)
<rocket16> Thanks for the help, persia.
<persia> My understanding is that Ubuntu Desktop will remain a GNOME-based flavour, just with Unity.
<pitti> Good morning
<pitti> kirkland: *chuckle* at the byobu (3.8-0ubuntu1) changelog -- s3kr1t stuff?
<dholbach> good morning!
<stefanlsd> james_w: im looking at merging dahdi-linux using udd. It seems debian uploaded a .pc directory with patches applied (not sure how this happened) - do we have an idea how we handle this .pc directory with udd?
<pitti> stefanlsd: perhaps bzr imports the source packages with the patches already applied now? that's the way dpkg-source unpacks 3.0 (quilt) packagese
<pitti> james_w: ^ ?
<stefanlsd> pitti: i guess if thats the case, we def. need the .pc directory, as to build it needs to unapply
<pitti> yes, with pre-applied patches you also need .pc/
<stefanlsd> pitti: yeah. there was talk about not importing .pc. in this case we cant do that.
<pitti> in that case we shouldn't pre-apply patches
<cjwatson> uh
<cjwatson> it's a bit more complicated than that, IMO
<cjwatson> 3.0 (quilt) must *always* be patches-applied except when you're actively editing patches; but importing .pc creates a lot of noise and it's tricky to figure out how to commit correctly atop that; http://bugs.debian.org/572204 is probably part of this
<cjwatson> what I do at the moment is run http://people.canonical.com/~cjwatson/dpkg-quilt-setup if patches are applied but the .pc directory isn't there
<cjwatson> but I think what we want is for bzr to set up the .pc on checkout, or similar
<cjwatson> it's as yet an incompletely solved problem
<pitti> cjwatson: why wouldn't we have .pc/ tracked in bzr in this case then? I thought the goal would be to mimic what apt-get source does, i. e. have a buildable tree?
<cjwatson> I've never seen anyone get the commits right on top of that
<pitti> if we want to require using bzr bd (which would be okay, I think), then we might just as well not apply the patches
<pitti> I've not seen it either yet
<cjwatson> the other longish-term approach is to represent the patches as a loom
<cjwatson> if that ever works, then it should be good
<pitti> that'd be even better
<Laney> I thought that was agreed by the bzr guys at UDS, so hopefully there will be some movement there
<pitti> right now it seems kind of silly that we don't use revision control for the things that would benefit most from it :)
<cjwatson> I'd really rather not have unapplied patches though, that's just back to the bad old days
<cjwatson> there are strong benefits to having things like bzr blame for 3.0 (quilt)
<cjwatson> if the revision control representation is patches-applied, then you have blame across both upstream and distribution-patches transparently
<cjwatson> FWIW, I do 3.0 (quilt) in bzr outside udd, without committing .pc, and it works quite nicely for my purposes except that you have to do something like that dpkg-quilt-setup business on checkout
<cjwatson> but IMO this is a small price to pay, and if bzr sorted it out automatically it would be nice and smooth
<cjwatson> (I talked to the bzr developers about this at the last platform rally)
<maxb> cjwatson: Ooh, nice script. And yes, the current situation (of .pc in branch) is just broken
<geser> cjwatson (or someone from ubuntu-desktop): could you please also do a no-change rebuild of pyorbit as the recent rebuild of gnome-python (for py2.7) added a dependency on python2.7-pyorbit (to python-gnome2) which isn't in the archive yet. Thanks
<mvo> geser, cjwatson: I can do that
<ifdef> cjwatson: morning! do you mind if I install a pkg in the natty chroot on kakadu (ctags)?
<cjwatson> ifdef: not at all, in general you're free to on porter boxes
<ifdef> cjwatson: thx
<juk> hi, i accidentally pointed anjuta ide to my home folder, as project root, and it won't start now for hours!
<juk> anyway to stop anjuta ide from going through my home dir at startup? it 80Gb+ big
<JamesPage> hi, how do I get a package that FTBFS rebuilt for Natty?  The missing main dependency has now been MIR'ed
<tumbleweed> JamesPage: you ask a core-dev to rebuild / "give-back" it, you need to mention the package name...
<JamesPage> tumbleweed: OK so if I follow the normal sponsorship route with the bug that should do the trick?
<tumbleweed> JamesPage: no, all you need to do is ask here
<JamesPage> tumbleweek: ah - right understand now;
<pitti> JamesPage: which package is it?
<JamesPage> tumbleweed: libmx4j-java
<JamesPage> pitti: ^^
<pitti> JamesPage: done
<JamesPage> pitti: thanks!
<ifdef> cjwatson: something nasty going on with dpkg - getting corrupt stack frames
<lool> Hmm new linux-libc-dev causes some FTBFSes like https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/672580 and eglibc
<ubottu> Launchpad bug 672580 in wpasupplicant (Ubuntu) "wpasupplicant FTBFS with latest kernel headers on natty" [Undecided,New]
<geser> lool: perhaps a similar change like in the recent busybox upload helps here too
<lool> ah thanks for the pointer; this is going to be painful  :-/
<cjwatson> ifdef: I think valgrind is at least somewhat usable on armel nowadays, so might be worth a go
<cjwatson> lool: I thought cyphermox was already dealing with that
<ifdef> cjwatson: I was going to install that, but it seems to be trying to pull in a new libc...?
<cjwatson> ifdef: otherwise, maybe traditional malloc-arena-debugging techniques might help
<cjwatson> ifdef: if it's just an upgraded version, that should be ok
<cjwatson> ifdef: the 'sudo apt-get install' is pretty locked down, it shouldn't let you do anything excessively dangerous
<cjwatson> lool: https://code.launchpad.net/~mathieu-tl/ubuntu/natty/wpasupplicant/ftbfs-lp672580
<lool> cjwatson, ifdef: for Linaro, we prepared an updated valgrind which was too intrusive to upload to maverick late in the cycle; it's in https://launchpad.net/~linaro-maintainers/+archive/overlay/+packages
<lool> I expect we will update to 3.6.0 in natty though
<lool> I mean in natty itself, no need for a PPA anymore
<lool> cjwatson: Yeah wpasupplicant has been taken care of, I'm facing the eglibc FTBFS
<lool> and I don't want to change eglibc code to use linux headers instead of glibc headers, this would be insane
<cjwatson> lool: I filed bug 673073 about the painful bit of the incompatibility
<ubottu> Launchpad bug 673073 in linux (Ubuntu) "<net/if.h> and <linux/if.h> are incompatible" [Undecided,New] https://launchpad.net/bugs/673073
<ogra_ac> cjwatson, btw, do we have a bug for the dpkg/debootstrap issue ?
<ogra_ac> else i'll open one
<cjwatson> ogra_ac: not to my knowledge
<lool> cjwatson: Thanks for the pointer; sub-ed
<ogra_ac> cjwatson, k
<lool> I checked the upstream glibc list and git repos and didn't see anything relevant going in
<cjwatson> likewise
<lool> Nothing in Fedora's packaging either
<stgraber> doko: ping
<highvoltage> doko: ping
<stgraber> doko: Does http://launchpadlibrarian.net/58992414/icedtea-web_1.0~20101021-0ubuntu4_1.0~20101021-0ubuntu5.diff.gz look like an acceptable fix for bug 673524 ?
<ubottu> Launchpad bug 673524 in icedtea-web (Ubuntu) "Unversioned conflict between icedtea-plugin and icedtea6-plugin making transitional icedtea6-plugin uninstallable" [High,New] https://launchpad.net/bugs/673524
<stgraber> doko: apparently quite a few packages depends on/recommends icedtea6-plugin still making some DVD builds to fail
<frukt_> hi! i'm not a ubuntu user, but i use the ubuntu-patched cairo, fontconfig, libxft and freetype2 on my arch install. it seems that as of late, the lcdfilter settings in fontconfig have no effect? i.e. lcdlegacy, lcdlight and lcddefault all look the same. can anyone shed a light on that?
<jdstrand> wendar: hey. so I have on my todo list to add to the wiki the security team's thoughts/recommendations on ARB. where is the best place to put that?
<kirkland> where did pitti go?
<Ng> .1
<Ng> bah
<gamerpro2000> Guys, I realize this is a dev channel, but I have a serious problem with Ubuntu that is dev related.
<gamerpro2000> Anybody in here got a minute to assist?
<pitti_> gamerpro2000: you should just ask your question, otherwise nobody will know what it is about
<gamerpro2000> ....................................................seriously?
<gamerpro2000> Yay! life!
<pitti_> (and some patience, please..)
<gamerpro2000> pitti_, sorry.  I've been trying to develop a script and stuff to get this working for 9 weeks.  patience is wearing thin
<kirkland> pitti_: howdy;  sorry, I don't get what you mean?
<pitti_> kirkland: now, if only I'd remember what I asked :) /me reads logs
<gamerpro2000> Anyway, XOrg is giving me a segmentation fault with a signal of 13
<gamerpro2000> However, it only happens once and a while
<pitti_> kirkland: aah
<kirkland> pitti_: the 3.7 release moved ~/.byobu to the xdg recommended location of ~/.local/share/byobu
<pitti_> kirkland: well, the changelog just said "UNRELEASED"
<kirkland> pitti_: huh?  really?
<gamerpro2000> and only about 25% of the time.  I'm trying to patch Xorg to stop it from doing this.  It seems that there is a buffer or something that's getting stuf
 * kirkland checks
<pitti_> kirkland: https://launchpad.net/ubuntu/+source/byobu/3.8-0ubuntu1
<gamerpro2000> *stuck
<pitti_> gamerpro2000: signal 13 is SIGPIPE, not a buffer overflow
<kirkland> pitti_: whoops, i wonder how that happened
<gamerpro2000> Because it happens several times over and over again, then once it comes out of it, it won't do it for several reboots
<gamerpro2000> pitti_, just so that you're aware, this is a multiseatX environment
<kirkland> pitti_: okay, thanks for the heads up
<pitti_> kirkland: so I just joked about "you now accidentally released your s3kr1t stuff" :)
<kirkland> pitti_: hah :-D
<kirkland> pitti_: my release script broke somehow
<gamerpro2000> Much of this started happening when gdm and kdm updated, removing support for multiseat
<gamerpro2000> Does anybody know when the multiseat additions will be added back into the tree so that it will make it easy again for people to use multiseat
<gamerpro2000> or does anybody know a good implementation for a multiseat environment?
<gamerpro2000> for Ubuntu 10.04 LTS
<psusi> pitti_: I came up with a working patch last night to export the esata bit and it correctly identified the external port on my laptop... now for udisks to use that, it still needs to be picked up by udev and added to the information it keeps for the block device right?
<krisphillips> Hey guys, I realize you guys don't do support, but sine you guys are devs, I was wondering if you can tell me what this segmentation fault means from my logs?  I would really appreciate it, since I've been beating my head against it for weeks.
<krisphillips> Log is here: http://pastebin.com/qg1TtiXz
<krisphillips> I don't have any understanding on what the heck it means, and I would be in your debt if you could explain it and give me a direction to resolve it.
<pitti_> psusi: right; but once that's in the kernel, that should be easy
<pitti_> psusi: well, in udisks, not in udev
<krisphillips> Anyone?  Please? :(
<pitti_> kirkland: that's not a very useful stack trace, I'm afraid; did you get an apport report?
<kirkland> pitti_: i did not
<kirkland> :-)
<pitti> ebroder: thanks for forwarding the gst perl fix upstream!
<pitti> ebroder: you are going to do that for gutenprint as well, I suppose? I'll sponsor that now
<ebroder> pitti: please don't just yet
<pitti> oh, ok
<ebroder> I'd like to do at least a modicum of testing :)
<ebroder> pitti: if you're hunting for something to upload :), you can drop the perl dep from libnss-mdns with no other changes
<ebroder> (dep as in it's in debian/control directly for no good reason)
<pitti> ebroder: right, that's on my mental queue
<pitti> ebroder: just thought you'd like to see your change in action :)
<krisphillips> So, anybody willing to help me now?
<krisphillips> I submitted a bug report here: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/674112
<ubottu> Launchpad bug 674112 in xorg (Ubuntu) "XOrg Segmentation Fault with XServer when running MultiSeatX" [Undecided,New]
<krisphillips> I would reaaaalllllly appreciate it :)
<segv`> There anyway to install 10.04 with the 10.10 CD? 2.6.32 likes to make my 'hdd's dissapear. 2.6.35 does not however.
<cjwatson> not really
<cjwatson> I suppose you could debootstrap and then fix it up afterwards, but that's definitely a "some assembly required" kind of option
<segv`> Figured as much, i'm willing to dive in and build a livecd with a newer kernel on it, would that work?
<cjwatson> I suppose.  You can't just install 10.10 directly?
<cjwatson> (since you said its kernel works)
<segv`> I have it installed, I just want LTS (for various other reasons, compatibility etc.) and I have cfengine managing these machines
<segv`> Like to keep them all the same version
<segv`> So i don't have a one off other than kernel version.
<psusi> should probably try to figure out what's wrong with 2.6.32 and fix it...
<segv`> DID_BAD_TARGET is what happens, ICH7, USB drops out too during "hardware detection"
<segv`> with acpi enabled, noacpi, usb doesn't drop.
<segv`> 2.6.35 does not require any of these steps etc.
<segv`> and it's alread in lucid-proposed so *shrug*
<segv`> psusi: I really should, I just need this system up, it's a virtual server host it being down for > 24 hours is bad.
<segv`> If I had time to debug, I would *love* to.
<segv`> If I can find another D945GTP intel mboard with a 64bit proc for under 140 in the next week or two, i'll go down the gauntlet of debugging it
<segv`> cjwatson: you think it's possible to use the kernel off of the 10.10 livecd and use it on the 10.04 livecd?
<pitti> segv`: we already have a maverick kernel backport in lucid
<segv`> pitti: (i can't install it w/out the livecd using it)
<segv`> pitti: 2.6.32 (the version on the livecd) as soon as hardware detection goes through the hdd's become inaccessible
<pitti> yeah, you'd need to remaster then
<pitti> or perhaps try a netinstall; the expert mode should allow you to select a kernel, but I'm not quite sure whether this requires extra magic in d-i
<segv`> pitti: that's what I was thinking, i was going to just add the lucid-proposed, where the linux-image-2.6.35 is hiding
<segv`> to the live-cd giving me the ability to use it.
<segv`> hmm, wish I knew how to make custom kernels work for the live-cd..
<segv`> pitti: Would copying over the kernel from the 10.10 cd work and just rebuild it?
<pitti> segv`: I thought the 10.04 CD wouldn't even see your hard disk -- so no
<segv`> it sees it it just dumps it
<segv`> as soon as it gets to hardware detection is throw DID_BAD_TARGET errors (Read errors)
<segv`> Got it, figured out a pretty hack.
<segv`> pitti: I booted with the 10.10 livecd just cloning a 10.04.1 install with the 2.6.35 kernel installed, just need to chroot grub install and done. Problem solved.
<pitti> heh
<segv`> Sometimes I make things way too difficult/
<ifdef> ogra: hi! could you raise a bug for the armel dbootstrap/dpkg sigsegv issue?
<ogra_ac> ifdef, yeah, will do
<ogra_ac> did you take a look already ?
<ogra_ac> ifdef, do youu want it against dpkg or debootstrap ?
<ifdef> ogra_ac: I've been looking at it all day. So far, I've hit a bugs in valgrind and dmalloc and a limitation with gdb :)
<ogra_ac> yeah, valgrind and arm dont go so well together
<ifdef> the problem seems to be with dpkg-query so I guess dpkg
<ifdef> I got the classic, "valgrind: the 'impossible' happened:"
<ogra_ac> heh
<ogra_ac> ifdef, bug 674146
<ubottu> Launchpad bug 674146 in dpkg (Ubuntu) "dpkg segfaults during debootstrap on natty armel" [Undecided,New] https://launchpad.net/bugs/674146
<doko> stgraber: yes, looks ok
<highvoltage> doko: unping (I emailed you instead!)
<superm1> pitti, what exactly is this PNG optimization that started happening in builds for natty?  i'm assuming another size reduction initiative?
<ifdef> ogra: a belated thx for 674146
<ebroder> superm1: https://blueprints.edge.launchpad.net/ubuntu/+spec/performance-desktop-n-install-footprint (in short, yes, it's a size optimization thing)
<superm1> ebroder, thanks, that explains it.  i guess i'll just need to double check the pngs that are being optimized to make sure they still look right afterward then
<ebroder> superm1: pitti wrote a script to do that verification - it's somewhere in pkgbinarymangler
<superm1> pitti wrote a script to verify how they /look/ ? i knew he was smart, but didn't think he could make computers replace humans for that kind of stuff :)
<ebroder> It converts them to bitmaps and compares them somehow :)
<ebroder> I think it's pixel-for-pixel, but I don't remember for sure
<gamerpro2000> Can someone look at my bug report and at least give me a bit of direction?  Thank you.  https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/674112
<ubottu> Launchpad bug 674112 in xorg (Ubuntu) "XOrg Segmentation Fault with XServer when running MultiSeatX" [Undecided,New]
<ikonia> gamerpro2000: this isn't a support channel, please don't ask for support in here
<psusi> pitti: if I patch udev's ata_id utility to add a new variable to the udev db entry for esata, that will be sufficient for udisks to auto mount them right?  do you have a preference for what it should be called?
<psusi> hrm... no, ata_id isn't the right place... hrm...
<psusi> hrm... how can you have the shell test a bit in a hex number?  hrm...
<ebroder> psusi: if you're using bash, you can use && and || within $(( ))
<ebroder> if not...call out to something more powerful?
<ebroder> psusi: err, sorry, '&' and '|'
<psusi> hrm... is bash what udev uses? or does it use the default shell, which these days is dash?
<ebroder> psusi: probably dash
<psusi> aha!  bash -c 'test $((1 & 0x$(<foo))) -eq 1' should do it
<Book_em_Dano> can I aks questions regarding packaging here?
<micahg> Book_em_Dano: #ubuntu-packaging is probably better for generic questions
<kees> lool: still around?
<lool> yup
<kees> lool: I sent two emails, and then realized I could probably talk with you live. :)
<lool> EH!
<kees> if you have a moment, can you read those, and then we can compare notes again? I think eglibc is close, but some minor re-arrangements would be nice.
<lool> kees: I'm bzr pushing as maybe my branch is out of date
<lool> xmlrpclib.Fault: <Fault -1: 'Unexpected Zope exception: AssertionError: '>
<lool> but Pushed up to revision 87.
<lool> kees: I think I had failed to push r87 with cvs-issue12113
<kees> ah! okay
<kees> let me know when it's there and I'll look again
<lool> kees: it is now
<lool> I also have it in my tree and in the series
 * kees waits for LP
<lool> kees: You're looking at lp:ubuntu/eglibc, right?
<kees> I was looking at https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/eglibc/natty because I'm still waiting for bzr checkout to finish :)
<kees> lool: okay, cool, let me re-arrange some other patches, and I'll commit too
<lool> kees: Now keep in mind that some of these patches landed via Ubuntu
<kees> I'll just move the one ld_audit one, since that'll stay ubuntu-specific
<lool> kees: Ah you say debian/patches/any/disable-ld_audit.diff in changelog but it's ubuntu/disable-ld_audit.diff everywhere else
<lool> I got it via the maverick-security which uses debian/patches/any/disable-ld_audit.diff
<kees> right, I moved it for the old -pkg tree
<kees> and updated it's comment to include the CVE
<bdrung> bryceh: wow, you are cleaning up all old audacious bugs
<lool> kees: Ok; this indeed wasn't copied over
<lool> We have a debian/patches/any/dst-expansion-fix.diff instead of patches/any/cvs-dst-expansion-fix.diff
<lool> (cvs- missing)
<lool> Albeit it's the Debian name, so you could keep it like that
<lool> And patches/any/ignore-ORIGIN-in-priv-progs.diff was not added but we got any/submitted-origin.diff from Debian which is disabled
<lool> kees: So just a rename from /any to ubuntu of disable-ld_audit.diff + updated desc to copy; you're doing it, or you want me to?
<kees> lool: I've got it, one sec
<kees> okay, I've committed now.
<lool> kees: I've added a comment in the old branch's changelog to point at the new one
<lool> the good news is that bzr merge lp:debian/eglibc just works now  :-)
<kees> \o/
<lool> kees: Hmm you chose to move debian/patches/any/cvs-dst-expansion-fix.diff around? we don't use it and it will show up in a straight diff with Debian; I guess people should use bzr
<lool> kees: Looks good; thanks for moving this across, and sorry for missing parts of it
<kees> lool: no problem, sorry it was so confused. :)
<kees> we do use debian/patches/any/cvs-dst-expansion-fix.diff ... ?
<kees> I just chose to stick to their naming convention since eventually that patch will go away when we get it automatically from upstream.
<lool> Sorry, #any/submitted-origin.diff is the one which is disabled because redundant with our fix
<bryceh> bdrung, yeah was gonna put in 30 min on fixing a bug, but saw that just tons of cruft had built up so ended up just cleaning out obsolete bugs.
#ubuntu-devel 2010-11-12
<YokoZar> Who do I poke for a higher PPA size limit?
<mwhudson> YokoZar: ask a question at answers.launchpad.net/soyuz i think
<TheMuso> Is it just me, or is sbuild rather broken in natty?
 * TheMuso notes he is not currently using a .sbuildrc
<RAOF> Not broken, but certainly *seriously* chatty about debug_level
<RAOF> Certainly not screen-reader friendly :)
<TheMuso> heh right. I was wondering whether that had to do with why packages/essential build deps step is failing... Maybe my chroot is broken...
<TheMuso> I.e essential build deps not being satisfied.
<RAOF> Oh, that.
<RAOF> I don't think I hit that brokenness because I use the aptitude resolver.
<TheMuso> Ah.
<RAOF> (Because I need to build against Debian experimental sometimes, and that requires the aptitude resolver to work properly)
<TheMuso> Right.
<TheMuso> How does one change that?
<RAOF> $build_dep_resolver = 'aptitude'; in ~/.sbuildrc
<TheMuso> Thanks, not mentioned in the example.
<TheMuso> Ah much better. :)
<TheMuso> Oh it failed because there are actually broken packages in the archive. :)
<RAOF> Heh
<ebroder> RAOF: following up from the conversation yesterday, do you think that delaying X from changing modes until g-s-d is up is something that could happen this cycle?
<RAOF> ebroder: Yes, I think it could.
<RAOF> I'll be walking through that code as a part of the multi-monitor experience stuff anyway.
<ebroder> Cool. Do you know yet when you expect to be looking at it? (It looks like I may need to attempt to backport whatever you come up with for work)
<RAOF> I was going to wait until we'd decided whether or not we were going to ship xserver 1.10; that'll be the beginning of December.
<RAOF> I could re-order that, though, and just work on xserver master (+ possibly backporting) anyway.
<ebroder> I don't want to make you go out of our way - I'm just making sure I know what to tell my boss when he asks :)
<psusi> I have found the information in sysfs needed to decide that a disk is esata, and therefore udisks should auto mount it, but I'm a little confused and as a result, can't figure out how to have udev extract that information.  Specifically the disk device is a child of a scsi target, which is a child of a scsi host, and the scsi host has a scsi_host/hostN/ahci_port_cmd file with the bit that says it's eSATA.
<psusi> but it seems that udev searches for attributes walking up the tree, but you have to go back down a level to reach that attribute... which I can't make sense of or figure out how to get udev to do
<psusi> it seems like sometimes a subdirectory in sysfs means it is a new device that is a child of the parent, and sometimes subdirectories are... personalities, for lack of a better term, of the device, but I can't figure out how to tell the difference or how to get udev to look at the attributes of a personality
<TheMuso> Ah. So thats why compiz is broken installability wise.
<TheMuso> Hrm but the build log shows things correctly...
<TheMuso> Hrm, mirror skew.
 * TheMuso refreshes local mirror.
<ebroder> How would people feel about SRUing the fix for bug #589487 to Lucid and Maverick?
<ubottu> Launchpad bug 589487 in Percona Server "Add INFORMATION_SCHEMA table for time spent in different thread statuses" [Wishlist,Triaged] https://launchpad.net/bugs/589487
<ebroder> Sorry - that's Debian bug #589487, ubottu :)
<ubottu> Debian bug 589487 in update-inetd "pawserv: "postinst configure" hangs" [Serious,Fixed] http://bugs.debian.org/589487
<pitti> Good morning
<pitti> superm1: right, it uses optipng and advancecomp on those
<pitti> superm1: yes, I did :)
<dholbach> good morning!
<pitti> superm1: http://launchpadlibrarian.net/58704226/optipng-check FYI
<pitti> superm1: I used find /usr/share -name '*.png' | ./optipng-check
<pitti> cjwatson: FYI, apt-listchanges should now work again as of yesterday evening; I tested it on a bunch of .debs (like on upower, which still has no changelog at all); but I couldn't get the apt-get dist-upgrade integration to work, not even with fully "normal" packages
<pitti> cjwatson: bah - after having said that, it just worked for my current dist-upgrade
<cjwatson> pitti: cool, thank you!  I haven't upgraded to natty yet
<ion> apt-listchanges works fine in my natty. Upgraded from maverick a couple of days ago.
<pitti> ion: it didn't show changelogs for packages which got their debian changelog completely stripped
<pitti> that happened for a week
<pitti> tkamppeter: won't coldplugging fail as well if there is no local unix socket?
<pitti> tkamppeter: I made my patch so that it skips coldplugging in that case
<pitti> tkamppeter: since it's very likely to fail
<pitti> tkamppeter: and at that point (if you disable the local socket) you are on your own anyway IMHO
<pitti> ah, I finally got cups to build with gcc 4.5
<dholbach> lamont, how does the patch in bug 674199 - would you get it into debian too?
<ubottu> Launchpad bug 674199 in bind9 (Ubuntu) "bind9 1:9.7.2.dfsg.P2-1 FTBFS in natty" [High,Triaged] https://launchpad.net/bugs/674199
<dholbach> ... err ... how does it "look to you"? :)
<tkamppeter> pitti, cold-plugging only needs the presence of CUPS. CUPS is only accessed via system-config-printer (executables udev-configure-printer and udev-add-printer) and this also works if CUPS is configured for local access via localhost.
<pitti> tkamppeter: it tries socket and localhost TCP?
<tkamppeter> pitti, s-c-p does not nail down the access method. It simply uses libcups through the pycups byndings.
<tkamppeter> pitti, why do you supply the upstart script as a patch? It is one file in debian/ and no change on upstream files, so it is much simpler to supply the file directly.
<pitti> tkamppeter: can't, since then it would be used in Debian as well
<pitti> well, I don't know the exact reason any more, but having both in debian/ breaks stuff
<pitti> yep, apparently it was that
<pitti> in debian we need the init.d script
<htorque> hi everyone! i have a created a custom shortcut to 'gnome-screenshot --area' and it only works if i press it twice (fast). running the command from the terminal and via a panel launcher works fine. is this more likely a bug in gnome-screenshot or in gnome-settings-daemon?
<ogra> cjwatson, would you object to build dpkg with dropped optimization for arm until the toolchain issue is fixed (so we can build images)
<tkamppeter> pitti, thanks for the patches on the PDF filters so that they build under GCC 4.5.x. I have upstreamized the changes now.
<cjwatson> ogra: I'd rather have actually analysed the problem first
<cjwatson> nobody else's images work yet either :)
<ogra> cjwatson, indeed, but i'd like to have something by A1
<ogra> no hurry yet indeed
<pitti> tkamppeter: oh, cool; thanks
 * cjwatson promotes unionfs-fuse temporarily
<cjwatson> (let's see if that helps)
 * pitti takes a first look at oversizedness
<pitti> so we added 23 MB of packages and some grew quite a bit (gnome-system-monitor 1.8 MB, linux-firmware 3.9 MB)
<pitti> out of interest, why do we currently install two python versions by default?
<pitti> oh, and we have libicu42 and 44, both 7 MB
<pitti> an OO.o rebuild should get us rid of 32
<pitti> 42, I mean
<ogra_ac> pitti, how does the WI tracker handle the new spec namings, i.e. it currently mainly points to $team-$release_letter- will it automatically match $track-$teram-$release_letter- with that ?
<ogra_ac> s/teram/team
<pitti> ogra_ac: it doesn't care about spec names except for the contact point
<ogra_ac> k
<pitti> ogra_ac: it reads the specs targetted to natty
<pitti> ogra_ac: and the contact point regexps over the names have been adapted
<ogra_ac> well, i have 'canonical-mobile':         'mobile', in the teams list for my team
 * pitti uploads a fixed pkgbinarymangler to reclaim the 1.8 MB that gnome-system-monitor has grown
<ogra_ac> if i change the latter to arm that should just work ?
<pitti>     'arm-': ['jb@linaro.org'],
<pitti> that's the contact point
<ogra_ac> yes, that will go away
<ogra_ac> linaro wont use arm- anymore
<ogra_ac> thats reserved for ubuntu arm
<pitti> ogra_ac: oh, I'm not sure about that "roadmap" thing, this is an apw-ism I believe
<ogra_ac> i'm just concerned about the teams
<pitti> ogra_ac: so please update the error_contact matches as appropriate
<ogra_ac> yes, thats what i plan
<ogra_ac> but i'm not clear about the teams stuff yet
<pitti> ogra_ac: teams has to include all teams who we want to generate reports for
<ogra_ac> yes
<pitti> (other than the "all teams" report
<ogra_ac> as i said above, my team currently uses the "mobile" tag
<ogra_ac> for natty we properly switched to "arm"
<ogra_ac> i was just wondering if that will properly match
<ogra_ac> linaro will likely do its own thing and drop the 'arm' match from its setup
<pitti> ogra_ac: error_contacts does match over the spec names, yes
<ogra_ac> and teams ?
 * pitti toddles off for lunch, bbl
<pitti> ogra_ac: teams are not a match, they are a simple list
<ogra_ac> ah, k
<pitti> ogra_ac: I don't know what the "roadmap" bit is for, i. e. the values in the teams map
<ogra_ac> then the header is wrong
<ogra_ac>     # lp team                   # spec name match to show up in roadmap
<pitti> ogra_ac: the value is presumably a spec name match
<pitti> but not the keys
<ogra_ac> k
<ogra_ac> go to lunch :)
<mterry> james_w, pkgme trunk has odd layout: pkgme/pkgme/* instead of pkgme/*
<james_w> mterry, hmm, that's certainly not what I was intending
<james_w> mterry, looks ok to me. Did you just check the branch out as pkgme?
<mterry> james_w, just tried it again and it was fine.  I must have created a pkgme directory in the past without realizing it, and the branch created a subdirectory for me
<mterry> whoops
<james_w> mterry, np. How's the vala backend looking?
<mterry> james_w, good...  I did some yak-shaving with vala-dep-scanner (which discovers dependencies)
<james_w> cool
<james_w> mterry, you might have seen that trunk now has ./bin/pkgme, and it will work on itself as there is a rudimentary python backend. My next task is to get it to write a changelog, as currently you can't build a source package from it.
<mdeslaur> cjwatson: is it normal that tarballs on merges.ubuntu.com come with patches _already applied_ but no .pc directory?
<ari-tczew> good occasion to ask about .pc files in patches created by MoM - can we avoid to not including .pc files?
<Chipzz> ari-tczew: I assume you mean "avoid including .pc files". But why on earth would you want that?
<ari-tczew> Chipzz: useless data. merges patched should be as clear as possible.
<Chipzz> ari-tczew: I assume you mean patches which are shipped as a diff as part of the tarball should be applied before doing the diff?
<Chipzz> "as part of the tarball" -> "as part of the debian diff"
<Laney> You can use filterdiff to remove the .pc file from the diff you are looking at, but it's not useless data.
<Laney> There was a discussion yesterday (I believe) about this
<ari-tczew> Chipzz: dunno how, just I hate cutting MoM patches from .pc files.
<ari-tczew> I just want to in diff: -x '.pc'
<ari-tczew> .pc~
<Chipzz> but...
<Chipzz> .pc~ looks like a backup
<cjwatson> mdeslaur: 3.0 (quilt), I assume?
<mdeslaur> cjwatson: yeah :(
<Chipzz> seriously, you should just have cleaned your shit up and removed stray backup files
<cjwatson> the problem with just removing .pc is that people need to know how to operate on the quilt patches if you do that
<cjwatson> I don't think this can be fixed solely in MoM - dpkg needs to be improved.  I filed a bug some time ago about that
<cjwatson> I did think about simply removing .pc from MoM patches a while back, but concluded that it wasn't that simple
<ari-tczew> Laney: I never heard about include .pc files in merges. Did I came back from moon?
<Chipzz> ari-tczew: lets for a moment assume you meant .pc and not .pc~ ... what you're asking for is basically doing the patching (ie, a step of the build process) while diff'ing
<Chipzz> and diff'ing has very little to do with building
<ari-tczew> sorry, I have no strength to explain in detail what I mean. For me case is clear.
<ogra_ac> doko, could you take a look at bug 674146 ? seems to be a toolchain issue
<ubottu> Launchpad bug 674146 in dpkg (Ubuntu Natty) "dpkg segfaults during debootstrap on natty armel" [High,Triaged] https://launchpad.net/bugs/674146
<skkeeper> hi everyone, can someone tell me if its possible to drag a foreign window (firefox for example ) to my pygtk aplication?
<Chipzz> skkeeper: wrong channel :)
<skkeeper> shit
<skkeeper> sry
<doko> ogra_ac: isn't james hunt looking at this one?
<skkeeper> i noticed
<skkeeper> xchat changed on me
<skkeeper> xd
<Chipzz> and I don't think you can - not with arbitrary windows anyway
<ogra_ac> doko, yes, but not at the toolchain stuff
<ari-tczew> doko: did you read my mail about sync gcc-snapshot ?
<doko> ogra_ac: are you sure that this is not due to the optimized memcpy?
<doko> ari-tczew: why? there will be a new snapshot anyway
<ogra_ac> doko, doesnt that live in the toolchain ?
<cjwatson> doko: see my comment - I'm pretty certain it has nothing to do with memcpy, it's plain wrong assembler
<Chipzz> cjwatson: why would you want to remove .pc files from patches? or do you mean .pc files which aren't shipped by upstream, but which are shipped by ubuntu?
<cjwatson> Chipzz: sorry, I don't have time to go into this in more detail today again.  We had a longish discussion about it here just yesterday
<Chipzz> cjwatson: np, just trying to understand the issue :)
<ari-tczew> doko: hmm, I think about upload to Debian first and autosync to Ubuntu.
<ari-tczew> Chipzz: are you familiar with merging?
<mterry> james_w, how do I run the pkgme testsuite?
<james_w> mterry, you can install testrepository and use "testr run"
<james_w> and python-subunit too
<james_w> mterry, I think setup.py test works as well
<mterry> james_w, ah, it does now that I have the packages
<mterry> james_w, do they pass for you?  I get errors like "AssertionError: Backend python (/home/mike/Projects/natty/pkgme/build/lib.linux-x86_64-2.6/pkgme/tests/../backends/python) has no 'want' script" and the backends don't seem copied to the build directory
<james_w> mterry, ah, I haven't run them with setup.py yet. Seems setup.py is missing some of what we need.
<mterry> james_w, testr run gives "ImportError: No module named Cheetah.Template", so maybe I'm missing something
<mterry> and after installing python-cheetah and running 'testr init', I get AttributeError: 'module' object has no attribute 'test_backend' from testr run
<pitti> cjwatson: heh, catching up with lucid fixes? :-)
<cjwatson> pitti: yeah, a bit :)
<pitti> ugh, that fuse upload has quite a diff
<cjwatson> pitti: yeah, as I said in the SRU bug the three upstream patches I backported were so entangled and subtle I reckoned that if I tried to disentangle them I was likely to do more damage
<pitti> *nod*
<cjwatson> it was "add --no-canonicalise" "fix race condition [unclear if it was related]" "fix weird interaction between previous two"
<Chipzz> ari-tczew: I've never actually done a merge, but I can imagine how it works, yes
<psusi> pitti: just replied to your email... take a look and see if you can help me figure it out... or maybe involve someone more knowlegable about udev?
<pitti> psusi: what I don't understand is why you so desperately need this in the udev db
<pitti> psusi: why can't udisks check the sysfs attribute? it can then do some more elaborate checks of its parents and siblings
<psusi> well, I guess it doesn't have to go there, it just seems to be a good place to put it once it's figured out... seems like what it's for
<pitti> with the gudev interface
<psusi> I suppose it could...
<pitti> psusi: actually it's not; the udev db shouldn't really replicate stuff that's already in sysfs
<pitti> we should add new information to it, like "this device is a camera" (ID_GPHOTO), or "don't show this for automount" (UDISK_PRESENTATION_HIDE) or so
<psusi> but it seems like it might be better to keep udisks generalized to just checking a well known external attribute on the disk in the udevdb, and leave it to udev rules to figure out if the disk is external...
<pitti> we _do_ replicate a few bits for convenience, like from usb_id
<pitti> psusi: well, it's a valid approach as well
<james_w> mterry, that will be another missing dependency. Probably python-fixtures, that I think is just in natty
<pitti> psusi: you could just join #udev, explain the situation a bit, and then we'll discuss with davidz and kay
<psusi> ok
<pitti> psusi: i. e. the bit that we need to check is in the parental chain?
<pitti> ah, no, nevermind; saw your mail
<hallyn> james_w: barry: hi, ISTR a recent email about UDD talking about .pc/ inclusion.  Was there such an email, and what did it decide?
<mterry> james_w, apt-cache search fixtures doesn't come up with anything named that, and the couple packages that it does hit don't make the testr run error go away (i'm in natty)
<psusi> pitti: yea, up, but then back down another branch for some reason
<ari-tczew> Chipzz: my advice: do some merges and then talk about .pc utility in patches.
<james_w> hallyn, there was, it is on my to-reply list
<james_w> mterry, hmm, maybe it's not landed in natty. I thought Rob uploaded it
<james_w> barry, what's the best way for mterry to continue?
<hallyn> james_w: ok, thanks.
<ebroder> ari-tczew: the .pc files are a limitation of source format 3.0 (quilt)
<BlackZ> cjwatson: as far as you know, is there any bug report about ubiquity not making the installation possible because of the user account chosen starting with a capital letter?
<BlackZ> cjwatson: from what I seen it makes the installation not possibile without a warning; do you plan to add a warning for that?
<ari-tczew> BlackZ: are you going to merge sbuild?
<Chipzz> ari-tczew: no need to belittle me; I follow the conversations here closely, and I try to be aware of how things work
<jdstrand> barry: hi!
<mterry> james_w, I'm not blocked.  setup.py test works for me, as long as I copy the backends into place
<Chipzz> ari-tczew: and IMO you're the one that's wrong; if ubuntu ships a .pc file that doesn't exist upstream, that IS an integral part of the diff
<ari-tczew> Chipzz: I only show the way to the best understand.
<Chipzz> ari-tczew: what if the .pc accidently gets dropped?
<james_w> mterry, ok, great
<BlackZ> ari-tczew: I'll merge it but if you want to, I don't mind :)
<jdstrand> james_w: actually, I will 'hi' you too :)
<ari-tczew> Chipzz: merges should include only really required changes.
<james_w> hi jdstrand
<ogra_ac> pitti, any idea who from the SRU team pushed alsa-utils to updates ? the fix is not done yet at all
<jdstrand> barry, james_w: I am having trouble with udd. see http://paste.ubuntu.com/530751/
<pitti> ogra_ac: it was verified..
<ogra_ac> huh ?
<ari-tczew> Chipzz: sorry, I don't have a time to explain how merge works if you didn't done any merge and you think that I;m wrong.
<ogra_ac> i talk about bug 637947
<ubottu> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) "no sound devices on current ES2.0 boards" [High,Fix released] https://launchpad.net/bugs/637947
<jdstrand> james_w, barry: basically, with libvirt, we have been doing the whole 'quilt push -a ; bzr add' methodology
<jdstrand> james_w, barry: but the tree with my commit yesterday for 0.8.5-0ubuntu1 totally blew apart with today's 'bzr update'
<jdstrand> (a gagillion conflicts)
<ogra_ac> pitti, it definitely wasnt verfied
<ogra_ac> and its totally broken in -updates now
<cjwatson> BlackZ: already fixed in natty - bug 555896
<ubottu> Launchpad bug 555896 in ubiquity (Ubuntu) "Username starting with upper letter marked as OK during install and the refused" [Medium,Fix released] https://launchpad.net/bugs/555896
<Chipzz> ^^
<BlackZ> cjwatson: I thought that, thanks!
<jdstrand> so I compared the apt-get source with what is in a newly checked out branch, and see that there are some slight differences... (as seen in the paste)
<ari-tczew> BlackZ: no, just I'm amazed that you didn't take this one yet :) (I know that sometimes you can response quickly)
<jdstrand> james_w, barry: ^ (this is a source format 3.0 (quilt)) package
<ogra_ac> pitti, ugh, i see what heppened, seems lag just set it to fix released
<ogra_ac> based on a totally unrelated comment in that bug
<jdstrand> james_w, barry: is there an official sanctioned way to handle quilt source format 3.0 with udd?
 * ogra_ac curses
<jdstrand> james_w, barry: every time I try to do it with libvirt, it blows up and I waste a ton of time. I seem to be doing it wrong, though I've tried several different things...
<BlackZ> ari-tczew: I'll merge it then; I noted that now
<pitti> ogra_ac: so, do we need to pull that alsa-utils package from maverick-updates then, or follow up with a reversion? for armel? was it the kernel or alsa-utils which caused the regressinon?
<ogra_ac> pitti, kernel is fine, alsa-utils isnt even near to be finished
<ogra_ac> pitti, how hard is it to pull it ?
<lag> ogra_ac, pitti: My bad :(
<ogra_ac> i'll have a completed fix on monday
<ogra_ac> lag, yeah, the conversation on that bug was quite confusing
<pitti> ogra_ac: is 3.3 enough?
<pitti> ogra_ac: we could upload a 3.5 which is 3.3
<ogra_ac> pitti, i had uploads from ubuntu3 on, i'm not sure which one would unbreak
<james_w> jdstrand, from your brief description it sounds like the right approach to me. I don't have enough info to be able to say straight away why you got the conflicts though.
<ogra_ac> pitti, after all it only breaks on omap4, we could still leave it in but be fast with the next upload
<jdstrand> james_w: so the correct approach ismake sure to use 'quilt push -a', 'bzr add', bzr ci?
<BlackZ> ari-tczew: I seen right now that lool merged it
<ogra_ac> pitti, if we can do a fast path for the actual 3.5 we shouldnt need to pull it
<james_w> jdstrand, yes, I think so
<jdstrand> james_w: right, so that is what I did :)
<jdstrand> james_w: but if you look at the paste, there is a difference between the apt-get sourced package and the branch
<ari-tczew> BlackZ: ok sorry then for messing your head :)
<jdstrand> james_w: which presumably has to do with the quilt source format 3.0 stuff...
<james_w> jdstrand, right, that may be different dpkg-dev versions?
<pitti> ogra_ac: so looking at https://launchpad.net/ubuntu/maverick/+source/alsa-utils/+changelog it seems that all SRUs were omap4 related, so if it causes trouble, we could pull it; but I'd prefer a new version, as we can't otherwise get it off people's systems
<ogra_ac> pitti, ok, then just leave it as is and i'll have a fix on monday
<jdstrand> james_w: ugh. I'm on maverick, the package is natty and I don't know what udd used behind the scenes...
<hallyn> and, you shouldn't have to (he mumbles)
<cjwatson> james_w,jdstrand: I've found that I generally have to do 'bzr add .pc/new-patch-name.patch/*' or life is inconsistent
<jdstrand> cjwatson: I did that
<cjwatson> (and there's a udd bug about that, I blieve)
<james_w> jdstrand, hardy with a backported dpkg-dev I think
<cjwatson> *believe
<hallyn> and, you shouldn't have to (he mumbles again)
<cjwatson> hallyn: indeed not
<jdstrand> cjwatson: well, much more generally, I just did 'bzr add'
<james_w> hallyn, I absolutely agree, but bugs happen
<pitti> ogra_ac: ok
 * jdstrand can't decide on the most robust approach...
<hallyn> james_w: my problem with keeping the patches applied is that when you refresh patches, bzr doesn't seem to want to do the right thing with updating .pc/ contents
<james_w> hallyn, agreed
<jdstrand> james_w: slight history, hallyn and I (and soren) are trying to coordinate our libvirt work with udd
<hallyn> (and it complicates updates in general)
<hallyn> but, ok, - i wanted to check whether 'keep the patches applied' is the accepted best practice
<jdstrand> yeah. it hasn't worked right yet... I feel like we are doing it wrong cause people are obviously using it, but based on feedback just now, it seems we are using the recommended procedures
<james_w> hallyn, it is, and it sucks
<cjwatson> hallyn: we talked about this yesterday, and what I said, in brief, was that for my own 3.0 (quilt) packages in bzr I just don't revision-control .pc, and that for the most part this works better *except* that people have to know to run a magic command after checking out or (sometimes) updating the branch
<littlegirl> Hey there, do any of you devs know when the 260 series of NVIDIA drivers will be made available via Ubuntu --> System --> Administration --> Hardware Drivers?
<jdstrand> cjwatson: do you quilt pop -a or just bzrignore .pc?
<cjwatson> I keep patches pushed, quite deliberately
<cjwatson> I just don't check in .pc
<jdstrand> hallyn: I guess we can try to bzrignore .pc
<cjwatson> but this doesn't work well when the importer touches the branch (so I try to avoid that happening ...)
<cjwatson> if the importer has already given you a .pc, you need to keep it consistent
<cjwatson> an inconsistent .pc is worse than either other option
<jdstrand> cjwatson: can you explain that last comment? how do we keep the importer from touching the branch?
<littlegirl> Hey there, do any of you devs know when the 260 series of NVIDIA drivers will be made available via Ubuntu --> System --> Administration --> Hardware Drivers?
<cjwatson> do absolutely everything in bzr, mark-uploaded before uploading, etc.
 * jdstrand will need to read the latest on UDD
<jdstrand> I think I am out of date...
<cjwatson> littlegirl: have you searched the bug database to see if there's a thread there?  repeating your question here probably won't help
<ebroder> Is there a way to search for LP bugs linked to a particular Debian bug?
<cjwatson> ebroder: yes, but it's a bit obscure, one moment
<littlegirl> cjwatson: The bug database contains the bug that lead to this question. I'm not asking about a bug. I'm asking when the latest version of the NVIDIA driver will be made available in Ubuntu. This seems like the most appropriate place to ask that question.
<jdstrand> hallyn: I didn't "bzr mark-uploaded"
<jdstrand> I was unaware of that command
<cjwatson> littlegirl: I'm asking because if you have a bug number I might be able to interpret it better.  (I don't know anything about nvidia)
<hallyn> jdstrand: i've never heard of it
<jdstrand> james_w, cjwatson: thanks
<jdstrand> hallyn: https://wiki.ubuntu.com/DistributedDevelopment/Documentation. specifically 'Uploading a package'
<littlegirl> cjwatson: It's not about a bug. I am asking when the most recent NVIDIA driver will be made available via the Ubuntu --> System --> Administration --> Hardware Drivers interface that comes by default with Ubuntu. This has to be a bug in order for developers to help me with it?
<cjwatson> ebroder: https://bugs.launchpad.net/bugs/bugtrackers/debbugs/<bugnumber>
<ebroder> cjwatson: Awesome, thanks
<cjwatson> littlegirl: well, I don't know the answer to that question.  If you happened to have a bug number I might have been able to make an intelligent guess.  And no, it's not usually best to just ask here - not all developers are on IRC, particularly not at any given time
<cjwatson> it seems to be in 10.10 already; as for lucid, I don't know
<cjwatson> (but I'm just looking at package versions here)
<littlegirl> cjwatson: Here is the bug: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/629910 and here is the solution: http://www.nvnews.net/vbulletin/showthread.php?p=2314331 but the solution is not available via Ubuntu --> System --> Administration --> Hardware Drivers.
<hallyn> i suspect #ubuntu-kernel is the place to ask?
<littlegirl> cjwatson: If the developers cannot be contacted via IRC, how do I contact the developers that are in charge of the Hardware Drivers interface?
<jcastro> or #ubuntu-x
<cjwatson> you shouldn't contact the developers responsible for Hardware Drivers for this.
<jdstrand> cjwatson: so, iiuc, I do a branch, I do my quilt work, I bzr add debian/patches (ie, ignore adding .pc), then bzr mark-uploaded, then bzr push.
<littlegirl> Lucid is the LTS. Why is a fix that is in place in 10.10 not in place for the LTS?
<cjwatson> the change wouldn't be made by changing that interface, it would be made by upgrading the nvidia-graphics-drivers package
<jdstrand> cjwatson: (I forgot to commit in there, but you get the idea)
<ebroder> littlegirl: We are probably not going to do a significant update like for an Ubuntu version that's already been released. However, there are generally newer versions of the proprietary NVIDIA and ATI drivers available at https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
<cjwatson> lots and lots and lots and lots and lots of changes are in later versions and not in the LTS - the LTS only gets high-priority changes
<cjwatson> tseliot is the developer assigned to that bug
<cjwatson> he's not here right now
<cjwatson> but he would be the person to ask, I imagine
<cjwatson> of course, that bug as such doesn't seem to apply to 10.04 - it's about a regression in nvidia 256.53, and 10.04's version is older than that (195.36.24, by the looks of things)
<littlegirl> ebroder: Thank you for the link! If I add that PPA to my system, will the Hardware Driver interface offer me the latest driver or will I still have to add that manually?
<cjwatson> jdstrand: this only works if the branch doesn't already have a .pc
<ebroder> littlegirl: I honestly have no idea
<littlegirl> Also, it is a very bad idea for you guys not to fix this in the LTS, since it *is* an LTS. This is a serious bug that affects text scrolling in everything (terminal and text programs) and I can't believe you would want to leave the LTS in such a condition.
<jdstrand> cjwatson: the main point of my question isn't a rehash of UploadingAPackage but getting at your workflow for avoiding .pc breakage
<littlegirl> ebroder: Well, thank you again anyway. That PPA will probably be a huge help. (:
<jdstrand> cjwatson: hmm. so I guess we have to fiddle with .pc (it is already there)
<cjwatson> littlegirl: "you guys" - the person who'd be involved isn't here so that's a rather misdirected comment
<jdstrand> cjwatson: thanks
<cjwatson> jdstrand: all of the 3.0 (quilt) packages I care about, I imported by hand myself from previous revision control systems
<cjwatson> I don't have a good answer for such packages imported by the UDD importer
<littlegirl> cjwatson: 10.04 has 195.36.24, which is way behind.
 * jdstrand wonders if we should just ignore the importer branch...
<cjwatson> littlegirl: it really is best to raise this kind of thing through the bug tracker, honestly
<maco> !sru | littlegirl
<ubottu> littlegirl: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<littlegirl> cjwatson: It was a general comment regarding whatever the approach is to the LTS.
<jdstrand> cjwatson: it would seem I could just bzr --remove .pc and commit and then be ok, no?
<cjwatson> jdstrand: I don't know
<maco> littlegirl: if you read that page, you'll see the policy reasons why "old" (ie stable)  things are kept around
<cjwatson> it's possible the importer will try to put it back
<littlegirl> maco: I understand about stable things. This is an unstable thing. (:
<cjwatson> (note that these policy reasons are *not* "we don't want to fix important bugs")
<jdstrand> james_w: who should I talk to about the importer and the libvirt branch? (I realize this isn't really your main focus these days)
<maco> er...that bug just has a link to other stuff...
<james_w> jdstrand, I'm happy to talk to you about it, I'm just in the middle of something OMFG URGENT right now, so if you can wait until later I'm happy to chat
<jdstrand> james_w: sure. thanks
<apw> cjwatson, have you heard of issues with 'all' of a users initramfs's becoming dammaged during an update?
<jdstrand> cjwatson: thanks again to you too :)
<apw> cjwatson, do we regenerate them all if the tools are updated ?
<smb> apw, cjwatson Which was lucid in my case
<smb> It was a bigger update though I did not pay attention on what changed
<smb> Just seemed that three versions of initramfs were updated into an unusable state
<smb> see bug 672964
<ubottu> Launchpad bug 672964 in linux (Ubuntu Lucid) "2.6.32-26 unbootable: does not find root file system" [Critical,New] https://launchpad.net/bugs/672964
<jdstrand> hallyn: whenever I have my chat with james_w, I'll try to figure out a robust way to udd libvirt, commit my little patch and see how it goes. then I'll talk to you and soren about the new procedure. we can reevaluate if it doesn't work again
<hallyn> jdstrand: awesome, thanks
<hallyn> jdstrand: i'd like to listen in on yoru conversation, but i've got far less experience with udd than you, obviously - so i only have my blind unreasonable prejudices :)
 * hallyn figures that makes him perfect for arguing on irc
<jdstrand> hallyn: well, I think you are giving me too much credit. I've had many failures with udd. They are certainly experiences, but to say I have experience with it is probably overstated :)
<jdstrand> hallyn: but I'll ping you
<cjwatson> apw: not heard of such issues, no.  bootchart regenerates all initramfses, but I don't think other packages do
<apw> cjwatson, the error on boot is this "udevadm trigger is not permitted while udev is unconfigured"
<cjwatson> don't know, sorry
<jdstrand> that isn't totally fair. I have had some successes outside of libvirt
<apw> cjwatson, would udev updates not need to regen as well
<cjwatson> no, most packages should only regenerate the *current* initramfs
<cjwatson> by design
<cjwatson> bootchart is a bit unusual because you're going to want to compare multiple kernel versions
<apw> cjwatson, ok there was a udev update 3 days ago on lucid
<cjwatson> that symptom sounds as though update-initramfs was run between udev unpack and configure
<cjwatson> udev itself will not be directly at fault
<apw> and as the message is the udev, .... i suspect that update has triggered the issue somehow
<cjwatson> no
<cjwatson> something else was doubtless upgraded at the same time as udev, and called update-initramfs at an inopportune point
<cjwatson> but it's not udev's fault
<apw> oh in parallel ... ick
<cjwatson> however, udev could avoid the problem by making its initramfs hook more robust
<cjwatson> -copy_exec /sbin/udevadm /sbin
<cjwatson> +if [ -e /sbin/udevadm.upgrade ]; then
<cjwatson> +    copy_exec /sbin/udevadm.upgrade /sbin/udevadm
<cjwatson> +else
<cjwatson> +    copy_exec /sbin/udevadm /sbin
<cjwatson> +fi
<ebroder> That still seems a little racy
<cjwatson> [note: check that that copy_exec syntax actually works, in lucid as well as in more current releases]
<smb> cjwatson, Maybe you would see more in dpkg.log. I updated the bug report with those
<cjwatson> maintainer scripts are not going to race with commands inside the update-initramfs run
<ebroder> Oh, I see. Yeah, that's fine
<cjwatson> smb: grep 'initramfs.*all' /var/lib/dpkg/info/*
<apw> cjwatson, the message the users are reporting at boot which is a udev.preinst message ... which seems very odd during boot
<cjwatson> BTW, I think it's unlikely that this is a new bug or a regression
<cjwatson> the probability is that you got unlucky with an existing latent bug
<lamont> dholbach: I'll upload a new bind9 today
<DktrKranz> could someone approve nomination for maverick in bug #642071 ? TIA
<ubottu> Launchpad bug 642071 in kexec-tools (Ubuntu) "kexec --load does not work in maverick amd64" [Medium,New] https://launchpad.net/bugs/642071
<cjwatson> apw: that's because the temporary /sbin/udevadm wrapper got copied into the initramfs
<cjwatson> apw: read udev.preinst
<dholbach> lamont, sweet - thanks
<apw> cjwatson, ahh now that makes sense
<smb> cjwatson, http://pastebin.ubuntu.com/530770/
<cjwatson> those are all false positives
<cjwatson> so I don't understand why multiple initramfses were updated for smb, but aside from that I understand the problem completely
<smb> Yes I think I remembered to have seen the issue a while before.
<smb> Then diwic got hit by it too and today me
<smb> I just was a bit quick in regenerating the ramdisks, I guess
<cjwatson> should it remain assigned to sconklin, since it isn't a kernel bug?
<smb> No I think it should get reassiged. probably also to a different package
<smb> uh, actally it isnt
<smb> never mind then
<cjwatson> I already reassigned it to udev
<smb> but I think sconklin will be more than happy when he isn't assigned to it
<cjwatson> assign it to me then
<smb> done
<apw> cjwatson, is plymouth special?  that was also updated 3 days back
<apw> (special in the sense it it triggers all initramfs's rebuilt)
<cjwatson> apw: not as far as I know
<cjwatson> it triggers the current initramfs, like most packages that ship initramfs components
<cjwatson> the only package on my system that rebuilds all initramfses is bootchart
<cjwatson> of course, upgrading a kernel package will rebuild its own initramfs
<pitti> cjwatson: ah, nice catch, want me to take a look?
<pitti> oh, you're already on it?
<manjo> superm1, ping
<cjwatson> pitti: yeah, have patch, just need a moment to test
<pitti> cjwatson: ah, me too..
<pitti> cjwatson: I added a test case to the bug
<cjwatson> pitti: if you want to take over, I don't mind - http://paste.ubuntu.com/530793/ is my working tree
<pitti> cjwatson: I have almost the same patch, except that I used -x
<pitti> cjwatson: I tested that in a VM
<pitti> cjwatson: sorry for the duplicate work, should've waited, I guess
<cjwatson> that's ok, if you've tested you should probably keep going
<cjwatson> I've been thoroughly distracted by hacking on plymouth
<pitti> ok
<RoAkSoAx> kirkland: still around?
<pitti> cjwatson: ok, uploaded to lucid/maverick/natty; needs SRU review now
<pitti> cjwatson: I also have a gnome-settings-daemon in the maverick queue which OEM is urging about, if you have a minute for that
<superm1> manjo, whats up?
 * pitti waves good night
<manjo> pitti, don't bite the bug
<mterry> james_w, OK, I have a vala backend done, except the hard part of the build_depends :)  Is it worth proposing for merging yet?  It is autoconf (only) based right now, and some of the autoconf bits are sharable with other autoconf-based backends.  Is there a mechanism for sharing that logic yet?
<james_w> mterry, not yet, other than normal code sharing mechanisms
<james_w> mterry, I have no problem with merging something which doesn't do the whole job
<cjwatson> pitti: g-s-d done
<mterry> james_w, https://code.launchpad.net/~mterry/pkgme/vala/+merge/40746
<james_w> sweet
<cjwatson> pitti: heh, exactly the same udev test case I would have proposed
<cjwatson> pitti: udev accepted too
<Eeyore-Jr> hi.  i'm looking at a gpsbabel-gui ppa and it's requiring dependencies for maverick that are not there
<james_w> mterry, looks great at first glance. I'll go over it and merge later, thanks.
<Eeyore-Jr> https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/gpsbabel/maverick
<mterry> james_w, sure!
<james_w> mterry, we should think of ways to make an autotools backend using the same code
<mterry> james_w, yeah, some of that code is tricky, and very little (so far) of the vala backend is actually vala-specific
<mterry> would be nice to reduce code for writing new backends
<mterry> james_w, maybe some way to declare that you subclass a backend, and then a way of calling parent backend's version.  And fall-through to parent if child doesn't declare?  Else, a simpler way may just be to ship autoconf scripts in /usr/share/pkgme/autoconf that backends can call
<mterry> maybe the latter is better in case a backend wants to support multiple build systems...
<mathiaz> jdstrand: hi!
<jdstrand> hey mathiaz :)
<mathiaz> jdstrand: I'm merging openldap from debian and I'm wondering whether /etc/apparmor.d/force-complain is required to be shipped by packages
<mathiaz> jdstrand: IIUC this was needed for supporting upgrades from pre-feisty
<jdstrand> mathiaz: if the upgrade logic to force complain is not in there, no. you should still clean up /etc/apparmor.d/force-complain/usr.sbin.slapd and /etc/apparmor.d/disable/usr.sbin.slapd though (to be friendly)
<jdstrand> mathiaz: well, more than friendly, you don't want to leave a dangling symlink on purge
<jdstrand> mathiaz: I thought it used dh_apparmor these days?
<mathiaz> jdstrand: yes it doesn
<mathiaz> jdstrand: yes it *does*
<dannf> what's the SRU versioning scheme? specifically, if there were an update to a 2.52-1 version of a package, what would it be - 2.52-1ubuntu1?
<micahg> dannf: depends, usually 2.52-1ubuntu0.1
 * dannf is trying to find a version in between - 2.52-1ubuntu0.1~foo1 (or 2.52-1ubuntu~foo1 maybe)
<micahg> dannf: which package?
<dannf> micahg: dnsmasq
<micahg> dannf: the version I gave is correct in this case
<dannf> right - i'm trying to do a private version that would upgrade to an SRU version if it occurred
<micahg> dannf: then 2.52-1ubuntu0.1~ppa1?
<dannf> micahg: yeah, that works - thx
<mathiaz> jdstrand: hi - should the ufw profiles be sent to debian as well?
<mathiaz> jdstrand: (openldap has a ufw profile)
<jdstrand> mathiaz: sure. ufw is in Debian
<ebroder> dannf: Daviey asked about a dnsmasq SRU in #ubuntu-motu - do you know if you're looking at the same bug? I was planning to sponsor it but if there's more than one SRU, it would be good to coalesce them
<mathiaz> jdstrand: however apparmor is not - right?
<jdstrand> mathiaz: not yet no
<Daviey> o/
<m4n1sh> pitti: Martin, will natty stick with libnotify 0.5 or will update to 0.7 in few months when it comes out? (AFAIK it's not out)
<RoAkSoAx> kirkland: proposed a branch for merging into powernap, however i don't really need it to be merged just yet, but I'd like you to review it when you have the time.
<jdstrand> wendar: ping re ARB security notes
<kirkland> RoAkSoAx: cool, will do
<kirkland> RoAkSoAx: not today, but maybe sunday
<RoAkSoAx> kirkland: no prob. :) It don't really need an immediate review so whenever you can is fine ;)
<ScottK> barry: python-lzma fails to build on Natty in what I suspect is some python2.7 specific way.
<ebroder> Does unity's window maximization not work on amd64?
<rmrfslash> can someone here help me disable nouveau once-and-for-all?
<rmrfslash> little guy is persistent
<rmrfslash> sudo apt-get remove --purge xserver-xorg-video-nouveau
<rmrfslash> ?
<rmrfslash> I've tried a few iterations to try and get rid of this thing... always shows up in lsmod
<ebroder> rmrfslash: This isn't the right channel for support issues. Please ask for help in #ubuntu
<rmrfslash> thx
<wendar> jstrand: pong? (from a couple hours ago)
<wendar> jdstrand, that is ^
<jdstrand> wendar: hey, did you get me message yesterday?
<jdstrand> s/me/my/
<jdstrand> wendar: (on irc)
<jdstrand> wendar: well, I'll just ask again. I had said that the security team could come up with some recommendations for ARB and add it to the wiki
<jdstrand> wendar: (that was at UDS)
<jdstrand> wendar: where is the right place to add that?
<wendar> jdstrand: how about a new page https://wiki.ubuntu.com/PostReleaseApps/SecurityChecklist ?
<jdstrand> wendar: sounds good. I'll add it sometime next week (about to go eow)
<jdstrand> wendar: thanks
<wendar> jdstrand: awesome, thanks!
#ubuntu-devel 2010-11-13
<smplman> when ever i run a ./configure on anything i get an error that gcc cannot create executables. Any ideas\
<cjwatson> smplman: make sure you have gcc and libc6-dev installed
<psusi> pitti, I got it... kernel patch to put the attribute saying the drive is external in the drive device in sysfs for esata
<op_amp>  /join #ubuntu-devel
<op_amp> Can I install Daily Build image of Natty using simple wubi installer?
<tmzt_dg2root> op_amp: you might want to ask in #ubuntu+1 this is a development channel
<tmzt_dg2root> or is natty the released one?
<tmzt_dg2root> so just #ubuntu
<op_amp> ok
<directhex> http://i.imgur.com/oqgFC.png
<geser> what's the meaning of the red lines?
<nemo> trying to locate https://launchpad.net/ubuntu/intrepid/i386/libghc6-utf8-string-dev/0.3.1.1-2 for lucid or maverick
<nemo> ah
<nemo> exists for lucid
<nemo> hm
<nemo> is in bytestring according to unc0rr
 * nemo looks
<marcosroriz> hi guys
<marcosroriz> guys I'm helping out uploading screenshots for debian and debian-derivated (Ubuntu/DL/Etc) but there are some questions in my mind here..
<marcosroriz> is there any guideline for uploading screenshots of cli app
<eitch0000> marcosroriz: interesting question. And what is with all the library packages? Shouldn't they be filtered out on the screenshots website?
<marcosroriz> I tried to demonstrate the use of the cli app --> http://screenshots.ubuntu.com/package/ant
<marcosroriz> eitch0000, yep and also there is a problem with -data -common pkgs
<eitch0000> marcosroriz: your pic is looking good
<marcosroriz> thanks :)
<nemo> hm. can't find it in maverick. well. I guess figuring out how to build it without cabal is up to the package maintainers
<ScottK> marcosroriz: Since it's Debian's screenshots project, I'd ask them.
<ebroder> Do we generally update the maintainer field for no-change rebuilds? My inclination is that you shouldn't, but I'm not sure
<Laney> no I wouldn't bother
<ebroder> Hmm...how about the version number for a no-change SRU? Is the different between ubuntu0.1 and build0.1 semantically interesting in that case?
<ebroder> *difference
<ScottK> It's important that it be lower than the version in the next release.
<kklimonda> if it's ubuntu you have to change Maintainer
<ebroder> kklimonda: I'm looking at your bug 673789
<ubottu> Launchpad bug 673789 in librmagick-ruby (Ubuntu) "lucid (and probably newer?) version has to be rebuilt against newer imagemagick" [Undecided,New] https://launchpad.net/bugs/673789
<kklimonda> it looks almost like someone is... right ;)
<Laney> the tools will try to make you, depending on your DEBEMAIL, but you don't /have/ to
<kklimonda> Laney: at least bzr bd -S will fail if you use ubuntu version and Maintainer isn't set to @ubuntu.com
<Laney> DEBEMAIL= bzr bd -S
<ebroder> So it sounds like build0.1 + no maintainer change isn't offensive to anyone
<kklimonda> right
<ebroder> Err...except there's already a librmagick-ruby 2.11.1-1ubuntu0.1 sitting in lucid-updates
<kklimonda> hmm
<kklimonda> now that's embarassing :)
<ebroder> No worries. It's bug #518122; I'm going to dup yours to it
<ubottu> Launchpad bug 518122 in librmagick-ruby (Ubuntu Lucid) "Please rebuild for newer version of ImageMagick" [Undecided,Fix committed] https://launchpad.net/bugs/518122
<ebroder> I'm...very confused by the bug's history, though
<ebroder> I guess it went to updates with the outstanding other bug (which isn't a regression), so that makes sense
<chrisccoulson> could a core-dev please add lucid and maverick tasks to bug 655707 for me please? (it's already fixed in natty)
<ubottu> Launchpad bug 655707 in pango1.0 (Ubuntu) "Firefox crashes opening pages that use webfonts " [High,Triaged] https://launchpad.net/bugs/655707
<stgraber> chrisccoulson: done
<chrisccoulson> stgraber, excellent, thanks
#ubuntu-devel 2010-11-14
<jfer> hi. can someone help me with fixing the clean section of a makefile? i am having some trouble getting it to work
<micahg> jfer: if this is not for a package in teh archive, #ubuntu-packaging would be more appropriate
<jfer> ok thanks
<TLE> pitti: Hallo, do you have a second
<TLE> gotta set up new internet, be back later
<GNU\Stallman> Hi is Mark Shuttleworth here?
<TLE> Riiight
<ikus060> Hi, I need someone to get me started creating a debian package. I would like to use launchpad
<ikus060> The project is iFolder, there is already a group of people working on it to create a 'debian' folder. The solution is working farely well, but I want to put everything in launchpad and have a nightly build based on the iFolder trunk (which is SVN)
<ikus060> Any suggestion ?
<ebroder> ikus060: #ubuntu-packaging is more appropriate for people working on packages that aren't going into Ubuntu itself, but you might want to check out https://help.launchpad.net/Packaging/SourceBuilds/Recipes
#ubuntu-devel 2011-11-07
<pitti> Good morning
<Laibsch> stgraber: you have plans to release a new pastebinit for precise
<dholbach> good morning
<pitti> hey dholbach, how are you?
<jml> morning folks
<dholbach> hey pitti - doing great - how about you?
<pitti> dholbach: I'm quite fine, hoping that the jetlag won't be too bad
<dholbach> yeah, same here :)
<Laibsch> I'm requesting a mentor for a simple package that I intend to create (upstream and in Debian).  The purpose is to carve out some volatile data that is currently hard-coded in a bunch of packages and thus necessitates a bunch of SRU (which don't always happen).
<Laibsch> I have packaging experience, but I'm not really a programmer.  I could use somebody to help me with some design decisions.  Overall the package is VERY simple, a small collection of flat-file databases.
<htorque_> pitti: hello! i don't know where to ask, but i know that you know the answer: where should we place custom udev rules and keymap files? is there a special place for those or is it okay to just put them in /lib/udev/..?
<pitti> htorque_: put them into /etc/udev/rules.d/, to avoid overwriting them
<htorque_> pitti: and the keymap file?
<pitti> htorque_: I recently added a patch to udev to support /etc/udev/keymaps/, but that might not be in oneiric yet; but for a new keymap file you can just use /lib/udev/keymaps/
<htorque_> pitti: ok, thanks a bunch! btw. was it ok to ask that question here? it feels wrong, but you don't get support on things like this in #ubuntu(+1).
<pitti> htorque_: formally it's OT here, but I don't mind; you can ask in #udev
<htorque_> ok, thanks again! :-)
<Chipzz> pitti: your work on the new apport interface looks nice :)
<lifeless> ev: we should talk
<ev> lifeless: sure thing
<ev> when works for you
<lifeless> ev: not now, ETIRED, but soon. About crash db stuff.
<ev> lifeless: sure, I figured as much.
<ev> just pop something in the calendar and I'll find the time :)
<lifeless> ev: I have shiny new library and open sourced analysis console, all in the right space.
<ev> oooh yay
<lifeless> ev: okies
<ev> wonderful
<lifeless> ev: lp:python-oops-tools is the analysis console - a fairly stock django app at the moment
<lifeless> ev: you can probably follow your nose from there to find the rest of the treasure (including e.g. amqp transmission of error reports - so doing a job queue is simples)
<ev> lifeless: great stuff! Digging in now
<lifeless> some scaling work probably needed to hit 'bigdata' scales, but...
<lifeless> we have 27M oopses in there today and its ok
<lifeless> the disk store can be directly mapreduced if we put it on an hdfs volume
<lifeless> so its actually a reasonable starting point
<cjwatson> jelmer: are you on top of this bzr/armel build failure?
<jelmer> cjwatson: I wasn't, looking into it now. Thanks for pointing it out.
<cjwatson> jelmer: ta
<mok0> ScottK: ping
<davromaniak> hi
<davromaniak> is it the good place to ask question about pbuilder issues ?
<davromaniak> I can't create a pbuilder for Ubuntu > Jaunty
<davromaniak> (for ARM)
<davromaniak> I tried to use the ubuntu-ports repository, but the chroot fails
<davromaniak> http://paste.davromaniak.eu/?show=21 <== here is the log of the pbuilder creation
<davromaniak> http://paste.davromaniak.eu/?show=23 <== and here is the strace for the chroot command that fails
<davromaniak> http://paste.davromaniak.eu/?show=24 <== I tried to chroot only /bin/bash
<cjwatson> davromaniak: you'll have to use old-releases.ubuntu.com; jaunty reached its end-of-life some time ago and we no longer support it
<cjwatson> davromaniak: er, but your pbuilder log says natty.  please explain
<cjwatson> davromaniak: I suspect that you are trying to build this on an architecture which does not support executing ARM binaries?
<davromaniak> cjwatson: so I tried to compile packages for Ubuntu ARM
<davromaniak> it only works when trying to create a pbuilder for Ubuntu Jaunty (with the old-releases repo)
<davromaniak> but when I try to create a pbuilder for a newer version than Jaunty (Natty for example), it's not working
<cjwatson> davromaniak: what is the host architecture?
<davromaniak> and the worst, is the machine which runs the pbuilder is an armel machine
<cjwatson> davromaniak: does /var/cache/pbuilder/build/3518/debootstrap/debootstrap.log exist?
<davromaniak> by the way, it's not an Ubuntu machine, because I only have 1 armel server, which runs under Debian Squeeze
<davromaniak> yes, this file exists
<cjwatson> please pastebin it
<cjwatson> PS if you're on an armel host then why are you explicitly saying --arch armel?
<cjwatson> oh - is it ARMv7 capable?
<cjwatson> Ubuntu armel will not run on pre-ARMv7 systems
<cjwatson> jaunty and karmic supported ARMv5t/ARMv6, but that support was dropped in lucid, sorry
<davromaniak> http://paste.davromaniak.eu/index.php?show=25 <== here is the log
<cjwatson> https://wiki.ubuntu.com/Mobile/ARMv7AndThumb
<davromaniak> Linux arthur 2.6.32-5-kirkwood #1 Wed Jan 12 15:27:07 UTC 2011 armv5tel GNU/Linux
<davromaniak> so the version for the arm arch which is not supported
<cjwatson> yep, sorry, not supported by Ubuntu any more
<davromaniak> ok
<davromaniak> so I will try to use qemu and rootstock to create a virtual machine for my builds
<smoser> kirkland, awake?
<stgraber> Laibsch: no plans, though it probably would be a good idea
<kirkland> smoser: yo
<kirkland> smoser: here now
<smoser> kirkland, when you do get in, look at http://paste.ubuntu.com/730977/
<kirkland> smoser: so your small dir isn't getting used?
<smoser> thats what it appears to me, yeah.
<smoser> i would have expected most of that upgrade to be < 40M debs
<kirkland> smoser: agreed
<kirkland> smoser: i was suspect of lifeless's instructions to stack those up, more than one
<smoser> "stack those up, more than one" ?
<kirkland> smoser: two different cachedir lines
<kirkland> smoser: in the squid.conf
<kirkland> smoser: i wonder if it would make a difference to swap their order
<kirkland> smoser: put "big" first
<smoser> i can try that, real quick.
<cjwatson> cyphermox: are you intending to deal with the usb-modeswitch merge today?  It's causing ISO build failures across the board
<Laibsch> tumbleweed: Is there visibility of classical SRU bugs (ubuntu+1 task closed as fixed, nomination pending for stable release) for Ubuntu Drivers?  Particularly those with patches attached?
<smoser> kirkland, ok. so back from the above.
<smoser> i restarted with order reversed and it seems to have no affect.
<smoser> my "big" grows even for small dowwnloads.
<smoser> http://paste.ubuntu.com/731053/
<smoser> lifeless, around ? maybe you can shed light.
<ScottK> mok0: pong
<PaoloRotolo> pitti, Hi :)
<cnd_> seb128, what version of gtk+ will we ship in 12.04?
<cnd_> seb128, in case you missed my question, do you know which version of gtk+ will ship in 12.04?
<seb128> cnd_, hey, depends of you
<cnd_> hmm/
<cnd_> ?
<seb128> cnd_, we were planning to go for 3.4 but that got blocked on getting the gesture story sorted
<cnd_> ahh
<seb128> cnd_, so 3.2 or 3.4, depending of how much conflict we will get
<cnd_> ok
<smoser> kirkland, or lifeless if you see this, i opened bug 887186 against orchestra with details on squid issue.
<ubottu> Launchpad bug 887186 in orchestra (Ubuntu) "squid proxy big and small buckets not functioning correctly" [Undecided,New] https://launchpad.net/bugs/887186
<tumbleweed> Laibsch: I'm not on the SRU team. I know there's a page for reviewing those nominations, but I don't know if anyone reviews them regularly. Generally it's best to ping on IRC.
<Laibsch> tumbleweed: the problem is that those pages currently (and for quite a while actually) oops in launchpad.  So, many of those patches fall through the cracks and are ignored.  Same problem as in the bad days :-(
<Laibsch> I have a lot of personal experience of that.  Having to ping may or may not work for me (I have a lot of experience of it NOT working) but should not be the default process.
<Laibsch> bug 618399
<ubottu> Launchpad bug 618399 in Launchpad itself "DistroSeries:+nominations timeouts" [Critical,Triaged] https://launchpad.net/bugs/618399
<lool> geser: Would you be tempted to merge latest fuse?  python-fuse in precise now Depends on fuse instead of fuse-utils, which is what the Debian package now provides (there's a fuse-utils compatibility package in the Debian source as well)
<apw> slangasek, in the conversions for the kernel packaging you did for multiarch, you use DEB_HOST_MULTIARCH as part of build destination addresses, that seems wrong given there is also a _BUILD_MULTIARCH thing ?
<jdstrand> smoser: hey, so istr you being involved in an rsyslog transition of some sort. was that 4 -> 5.8 or 5.8.1 -> 5.8.6?
<jdstrand> smoser: it is showing up on my merge list and I don't want to step on the server team's toes
<roaksoax> pitti: howdy!! are you free by any chance?
<cjwatson> apw: build/host naming is confusing (inherited from autoconf terminology) - build is the arch you're building on, host is the arch you're building for, so destination paths normally want host
<apw> cjwatson, nnnng, could they have made it more confusing
<cjwatson> lool,geser: oh, I had a fuse merge in progress already
<cjwatson> I'll get round to it this week
<cjwatson> lool: (also, I'm TIL on merges.ubuntu.com)
<jdstrand> smoser: actually, looking at it, I think I'd prefer your team to handle it. the CVE I fixed is fixed in the version in Debian now, so you can drop that
<smoser> jdstrand, my toes will not be hurt if you did it.
<jdstrand> heh
<smoser> so we just need to sync to debian.
<smoser> i can do that. i only did it before as it was somethign that was really behind debian.
<smoser> jdstrand, bug # ?
<jdstrand> smoser: well, there is a bit of delta that I didn't want to make the call on, since your team has been managing it
<smoser> s/been managing/last touched/
<jdstrand> smoser: no bug number. was looking at https://merges.ubuntu.com/main.html
<smoser> but thats fine.
<smoser> oh, i thought there was a security bug that made you look
<jdstrand> smoser: no. I fixed the security bug (I last touched it actually) in oneiric. Debian took a newer upstream that has the fix
<roaksoax> pitti: could you please reject redhat-cluster from oneiric's -proposed?
<jdstrand> so my teeny change to the oneiric packaging is no longer needed in future merges
<slangasek> apw: HOST in C speak is "the architecture this code will be hosted on"; rather than BUILD which is "the architecture this code will be built on" - so HOST is almost always correct
<apw> slangasek, yeah i got "reeducated" :)
<slangasek> ok :)
<slangasek> cjwatson: though I'd be hard pressed to put my finger on it in a spec, I'm reasonably certain we can't blame autoconf for the host/build confusion, I think they inherited it from elsewhere ):
<slangasek> :)
<cjwatson> I'll take your word for it; at the very least I suppose it was in the Cygnus build system before it became autoconf
<lool> cjwatson: TIL?
<cjwatson> lool: touched it last - the rule that you should ask the person who last uploaded the package about a merge, to avoid duplicate work
<lool> cjwatson: Ah right, I should have pinged you too, I pinged the last merger because there were a lot of Ubuntu changes
<lool> cjwatson: Oh actually you did, I searched for merge instead of ubuntu in the changelog, and hit geser instead of you
<cjwatson> we need a single consistent rule (hence "last Ubuntu uploader"), otherwise you get duplicate work
<cjwatson> obviously the last uploader is entitled to pass it on if they want
<lool> cjwatson: Makes sense
<mewerner_arand> Which was the first version of Ubuntu to introduce the @+@home subvolume layout for btrfs? (Info for wiki section)
<cjwatson> mewerner_arand: 11.04
<slangasek> lool: btw, you're listed as TIL on mawk and ca-certificates ;) https://merges.ubuntu.com/main.html
<mewerner_arand> Ok, good, I'm doing a section detailing this layout, and why one should avoid set-default in ubuntu, amongst other things..
<slangasek> lool: if you don't want them, let us know :)
<Laibsch> stgraber: if you make a new upstream release, please do so early enough that it can go into Debian first.
<smoser> mterry, are you around ?
<mterry> smoser, heyo
<smoser> i'm looking at rsyslog, and the rsyslog binary package has 'ucf' dependency , which i can only seem to attribute to you, and a comment that says
<smoser>   debian/control: Depend on adduser
<smoser> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/rsyslog/precise/view/head:/debian/control#L17
<smoser> it doesn't look to me that that came from debian
<smoser> and i'm just trying to figure out if it is necessary
<cjwatson> jbicha: the ubuntu-desktop yelp branch is out of date (even before my most recent upload, which I just realised needs to go into that branch)
<mterry> smoser, looking.  I believe ucf is used to handle merging debian conf files?
<smoser> well, sort of. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/rsyslog/precise/revision/17#debian/control
<smoser> i suspect that you just inadvertantly copied another depends line from debian in the merge
<smoser> (you're human, thats ok, i just wanted to see if you did it on purpose and knew why)
<mterry> smoser, no, I remember the ucf bit was intentional
<mterry> smoser, trying to remember why (I mean, ucf is clearly used in the package, just not sure why the depends was separate)
<smoser> mterry, well, a grep shows it only used in rsyslog-mysql and rsyslog-postgresql pre and post.
<mterry> smoser, yeah, that same revision adds a call to ucf in debian/rsyslog.postinst that uses --three-way (hence the >= 0.8 versioning since that argument was added in that version of ucf)
<mterry> though, we no longer support any Ubuntu that has such an ancient ucf
<smoser> ok. so i think we can drop it.
<mterry> smoser, I just did an apt-get and I have it in rsyslog.postinst, postrm
<mterry> smoser, on precise.  What version of the source are you looking at?
<smoser> hm..
<smoser> mterry, i was grepping in debian sourc.e
<smoser> thank sfor your input. i'll poke aroudn a bit more.
<mterry> smoser, ok!  thanks for looking at rsyslog, it's kind of a bear
<AnAnt> Hello, when was the last sync from Debian testing to precise ?
<jbicha> cjwatson: ok, I pushed my yelp update to the desktop branch
<lool> slangasek: Yes, I actually did mawk earlier today and just want to reboot with the new binaries (in my PPA) to test them; didn't check ca-certificates yet
<slangasek> lool: ah, cool :)
<lool> slangasek: I am probably better placed to do ca-certificates, but I don't have time to fix the root causes in the Debian source to address the regressions we faced some time ago
<slangasek> lool: would be happy to have mawk back in sync, btw, but haven't gone fishing in the Ubuntu package to see what's needed; looks like there are a pair of changes that would still apply, one of which I'm pretty sure has not been forwarded to Debian at all
<cjwatson> jbicha: thanks, I'll sort mine out this evening or tomorrow then
<cjwatson> AnAnt: this moring
<cjwatson> *morning
<AnAnt> is there a reason that xcb-util-renderutil is not sync'ed from Debian testing ?
<slangasek> AnAnt: seems probable that no one got to it during UDS
<slangasek> oh, no, cjwatson says otherwise :)
<slangasek> AnAnt: new sources are handled differently
<AnAnt> ok
<smoser> mterry, yeah, it should be there. thanks.
<slangasek> cjwatson: so with libfl-dev in, pam can now be cross-built sensibly, yay :)
<tkamppeter> www.openprinting.org is back up again, so printer driver auto-download is available again now (tested with Oneiric).
<AnAnt> I have another question regarding swt-gtk & xcb-util/xcb-util-renderutil)
<AnAnt> during oneiric cycle, xcb-util source packages was split into two source packages xcb-util & xcb-util-renderutil, where libxcb-render-util0-dev was provided by xcb-util-renderutil
<AnAnt> Hence in oneiric a delta was added to swt-gtk changing Build-Dep from libxcb-render-util0-dev to libxcb-util0-dev (which is provided by xcb-util)
<Laibsch> does being a MOTU include the priv to accept nominations for relase (driver-priv)?
<Laibsch> nominations for packages in universe, of course
<AnAnt> the question is, that I don't know the difference between libxcb-render-util0-dev & libxcb-util0-dev, hence I am not able to decide wether to sync this change back into Debian or not
<AnAnt> or just wait until Ubuntu decides  sync xcb-util-renderutil (and wether it will add it to main or not) ?
<debfx> Laibsch: yes, you can nominate all packages that you are allowed to upload
<Laibsch> debfx: OK.  Thx
<micahg> you can accept nominations when you're an uploader, you can nominate if you're in bug control
<lool> slangasek: mawk has two pieces remaining, one is the autopkg/autodebtest stuff which seems a bit useless because it's not actually run during build (AFAIU) and the other is a patch for long regexps which has been forwarded to Debian and merged upstream, but not uploaded in Debian yet; if you could take it that'd be nice, you could decide either way for the autopkgtest/autodebtest bits
 * lool goes rebooting
<slangasek> lool: "merged upstream" - inaccurate
<slangasek> I don't recognize Thomas Dickey's work as upstream of us
<slangasek> because I'm unwilling to work with an upstream who throws tarballs over the wall as a development methodology
<slangasek> especially tarballs that are built using his personal version of autoconf
<slangasek> lool: so as the "upstream" status of mawk is still in limbo, I'm currently not actively merging patches :/
<cjwatson> slangasek: hooray
<cjwatson> lool: we're planning/hoping to start running autopkgtest tests automatically this cycle, I believe (not during build, but that's not the point)
<cjwatson> AnAnt: I've synced xcb-util-renderutil into Ubuntu now; I think it was an oversight that it wasn't done in oneiric
<AnAnt> cjwatson: but will it be in main ?
<cjwatson> I was still typing :)
<AnAnt> ah, ok
 * AnAnt waits ...
<adam_g> !regression-alert facter Bug #732953
<cjwatson> AnAnt: I've put the source package in main initially, although it will only stay there if something starts (build-)depending on it, so please go ahead and revert that delta in swt-gtk
<ubottu> Launchpad bug 732953 in facter (Ubuntu Precise) "can_connect function inside ec2.rb always return false" [High,Fix released] https://launchpad.net/bugs/732953
<ubottu> adam_g: I am only a bot, please don't think I'm intelligent :)
<adam_g> !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
<cjwatson> adam_g: yep, saw that this morning - are you working on a fix?
<adam_g> ^ i've pushed 3 branches to to fix this, but need sponsorship
<AnAnt> cjwatson: well, syncing swt-gtk would revert that sync
<AnAnt> cjwatson: well, syncing swt-gtk would revert that delta
<adam_g> cjwatson: there are 3 branches (lucid, maverick, natty) tagged "732953_fixregress" that fixes the issue. should i file a
<adam_g> MP?
<cjwatson> that's fine; it will dep-wait until xcb-util-renderutil binaries are published
<cjwatson> adam_g: yes
<cjwatson> can somebody who's in their working hours deal with adam_g's sponsorship request?  as a stable regression it's urgent
<adam_g> SpamapS: ping? ^
<AnAnt> cjwatson: so you'll sync swt-gtk ?
<cjwatson> AnAnt: can't you do it yourself?
<AnAnt> cjwatson: swt-gtk is in main
<AnAnt> cjwatson: I can file a syncrequest if needed
<cjwatson> AnAnt: oh; please use requestsync then, I don't deal with sync requests over IRC because the audit trail is hard to follow then
<AnAnt> ok
<cjwatson> AnAnt: I assume you're checking with the last uploaders to avoid duplicate work, when looking at merges in main?
<lool> slangasek: I didn't check the actual upstream status, but the Debian bug had been tagged fixed-upstream; I didn't know his maintenance style was problematic   :-/
<lifeless> smoser: is your small full ?
<slangasek> lool: he considers RCS state-of-the-art
<slangasek> :)
<cjwatson> slangasek: state-of-the-art,v please
<slangasek> hah!
<lool> cjwatson: autodeb/autopkgtest -- cool; so these should be kept I guess
<AnAnt> cjwatson: I don't understand your question
<lool> slangasek: ^ mind merging them in Debian?  essentially you can take the whole Ubuntu diff now
<lool> (just uploaded mawk to Ubuntu now)
<smoser> lifeless, no.
<smoser> $ sudo sh -c 'du -ks /var/spool/squid/small'; grep cache_dir /etc/squid/*.conf
<smoser> 16456   /var/spool/squid/small
<smoser> cache_dir aufs /var/spool/squid/big 40000 16 256
<smoser> cache_dir aufs /var/spool/squid/small 40000 16 256 max-size=40M
<cjwatson> AnAnt: are you aware that the standard rule for merges is that you must check with whoever uploaded the package last, to avoid duplicate work?
 * lool had fan issues on reboot, probably should call Lenovo tomorrow
<slangasek> lool: a bug report and split-out patch would help, fwiw :)
<cjwatson> https://merges.ubuntu.com/main.html "If you are not the previous uploader, ask the previous uploader before doing the merge. This prevents two people from doing the same work."
<slangasek> lool: otherwise it goes into my overflowing bucket of things-to-merge-from-Ubuntu-when-I-get-to-it
<lool> slangasek: there's one for the actual patch, I'll update it with the quilt version now, and report the autodeb/autopkg tests as a separate bug; I thought you had access to some Vcs or something since you had done a Debian upload
<cjwatson> AnAnt: it's fine to deal with other people's merges, you just have to ask them first
<cjwatson> (usually fine, anyway)
<AnAnt> cjwatson: I didn't know about that rule, but I did talk to doko
<slangasek> lool: sure, it's in a bzr branch that shares history with the UDD branch, but so do lots of other things that I haven't had time to review myself and merge
<slangasek> the value of a bug report is that someone else gets to write the rationale and do the analysis :-)
 * AnAnt checking logs
<cjwatson> AnAnt: it's been on the top of every merges.ubuntu.com index for six years
<cjwatson> (at least)
<cjwatson> AnAnt: ok, you know now :-)
<AnAnt> cjwatson: I never go to merges.ubuntu.com
<cjwatson> it's also on https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Syncing_and_Merging (although less forcefully), and probably elsewhere
<AnAnt> cjwatson: I just check the Ubuntu status of packages that I maintain (or care for) on Debian
<cjwatson> the rule is there because often multiple people care about something
<AnAnt> cjwatson: http://irclogs.ubuntu.com/2011/10/18/%23ubuntu-java.html
<cjwatson> and it's good to have a single rule that's easy to interpret
<cjwatson> anyway, in this case it should be fine
 * micahg wonders what we can do about people not passing -v to dpkg-buildpackage (or bzr not doing it)
<slangasek> bzr has an option to do it
<slangasek> I occasionally forget to use that option :/
<lool> slangasek: Hmm the Debian bug actually mentions a commit to a collab-maint git repo
<lool> http://anonscm.debian.org/gitweb/?p=collab-maint/mawk.git;a=commitdiff;h=e2e6d7ad
<lool> with a different fix from the one in Ubuntu
<slangasek> lool: yep, set up without the consent of the maintainer
<AnAnt> micahg: what's that for ?
<micahg> AnAnt: getting the Debian changelogs since the last merge in the .changes file so they show up on the -changes ML
<ajmitch> micahg: I thought that bzr-builddeb was meant to set -v back to the last tagged version?
<micahg> -v followed by the last Ubuntu version
<lool> slangasek: I'm confused, there's both a collab-maint git repo and a bzr branch you just added?
<m4n1sh> anyone from core-dev can review my merge request? https://code.launchpad.net/~manishsinha/software-properties/fix-887249-handle-404-error/+merge/81488
<micahg> ajmitch: if that's the case, that would explain why it's broke with UDD merges :)
<AnAnt> micahg: does syncpackage do that ?
<slangasek> lool: the good news is, I can delete the collab-maint git repo to eliminate the confusion
<ajmitch> micahg: better to check with someone who knows for sure :)
<lool> slangasek: did you save the patches in there that weren't uploaded?
<slangasek> lool: no?
<lool> slangasek: the automated testing patches are already forwarded in Debian #351820
<ubottu> Debian bug 351820 in mawk "automated testing - patch to wire in upstream test suite" [Wishlist,Open] http://bugs.debian.org/351820
<slangasek> the collab-maint repo is not mine
<slangasek> lool: ah, ok
<ajmitch> micahg: running into something like bug 876888 ?
<ubottu> Launchpad bug 876888 in bzr-builddeb "bzr bd -S --package-merge on e2fsprogs 1.42~WIP-2011-10-09-1ubuntu1 generates a .changes file recording the birth of the universe" [Undecided,Fix committed] https://launchpad.net/bugs/876888
<lool> slangasek: The only Ubuntu patch has been forwarded in Debian #391051 but fixed differently in upstream and in the collab-maint repo; I will use the collab-maint fix because it seems cleaner, and forward that to the bug (which already has a link to the patch in collab-maint)
<ubottu> Debian bug 391051 in mawk "mawk: buffer overflow in collect_RE from overlong regexp" [Normal,Open] http://bugs.debian.org/391051
<slangasek> lool: ok then :)
<micahg> ajmitch: not me, I usually don't use UDD, but have seen plenty of merges from Debian w/out it
<barry> ajmitch: i stopped using --package-merge while that bug was outstanding.  from the bug tasks it looks like it's been sru'd into oneiric, so i'll try it on my next merge.
<micahg> AnAnt: syncpackage uses LP to sync a package from Debian to Ubuntu similar to what we used to request from an archive admin w/requestsync (this only works if you have upload rights for the package in question)
<AnAnt> micahg: I use --no-lp usually
<micahg> AnAnt: why?
<cjwatson> --no-lp is deprecated and is only for cases where nothing else works
<cjwatson> please don't use it frivolously
<AnAnt> micahg: I sync a package that has just been accepted into Debian
<AnAnt> micahg: when I sync a package that has just been accepted into Debian
<micahg> AnAnt: ideally, this cycle, that should wait until it hits testing
<cjwatson> it's rare that there's that much of a rush
<micahg> by which time syncpackage will work fine with LP
<AnAnt> micahg: ah, that's right for precise, but I was generally speaking
<AnAnt> cjwatson: well, usually I am the debian maintainer of that package, so I just do so to avoid forgetting that I need to sync
<cjwatson> for my own packages, I generally wait until I've seen that it's built cleanly everywhere in Debian, which is usually enough time for LP to have picked it up
<cjwatson> and I save the Debian upload ack in my mailbox until I've synced it into Ubuntu
<cjwatson> this works well for me
<micahg> right, also if it's rejected by the ftpmasters for one reason or another, there will be problem with bzr
<micahg> you can end up with the same version of the package having different contents
<lool> slangasek: uploaded + sent to Debian; you'll have good pain merging the new upstream into bzr as there were at least 3 tarballs from upstream merged into the git branch, some of which renaming #defines over the place or changing indentation wholesale
<slangasek> lool: I have no intention of using the collab-maint git repo for anything
<slangasek> or of merging the "new upstream" at all until Thomas becomes a responsible upstream, which he currently isn't
<slangasek> it's on my todo list to raise this issue with him again, and either convince him to do it right or else cut my losses and just maintain the Debian package directly
<bryceh> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | 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 application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: none, bryceh
* micahg changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | 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 application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh
<slangasek> lool: if this wasn't clear, Thomas is not the upstream author; when I first adopted mawk, the package was abandonware upstream, which is not ideal but is workable.  Thomas came along and unilaterally declared himself the upstream and started doing over-the-wall tarball releases, which is not ok
<slangasek> having an upstream would be fine, but not one who's going to work like this
<lool> slangasek: Ok; thanks for sharing the history
<lool> or story rather
<bjsnider> what does "over-the-wall" mean in this context?
<slangasek> bjsnider: no public VCS, only monolithic tarball drops that intermix a large number of changes
<bjsnider> he's committing all of the changes himself?
<slangasek> certainly, as he's the only one who has access to his personal directory where he maintains it :)
<slangasek> but the issue is not "who commits", the issue is reviewability (and auditability)
<lool> slangasek: /c
<lool> Ups
<lool> slangasek: forwarded email to you
<slangasek> ok
<ion> /c pronounced in Finnish sounds like the word for arse (âperseâ).
<SpamapS> adam_g: do you still need somebody to look at your SRU?
<bjsnider> doesn't sound very FOSS to me
<cjwatson> it's not non-free to have a private repository; it's just not good modern practice
<adam_g> SpamapS: yes please
<SpamapS> certainly gives one pause to keep something like that in main and depended on by lsb-core :-P
<lifeless> fortunately, 'diff'
<slangasek> SpamapS: what, mawk?  the mawk in main isn't maintained that way at all, that's the point ;)
<SpamapS> adam_g: whats the status of the bug in Oneiric?
<SpamapS> slangasek: oh cool :)
<SpamapS> adam_g: seems like the regression itself should be reported and tracked as a new bug
<adam_g> SpamapS: it does not affect oneiric.
<adam_g> SpamapS: i can certainly do that.
<cjwatson> SpamapS: I thought that's what the bug linked to earlier was
<cjwatson> oh, it's not what adam_g linked to.  Try bug 885998
<ubottu> Launchpad bug 885998 in facter (Ubuntu) "facter upgrade crashes puppet" [Critical,Confirmed] https://launchpad.net/bugs/885998
<SpamapS> oh I missed that one
<SpamapS> adam_g: so, first point of feedback would probably be to change the bug reference to 885998
<adam_g> SpamapS: doing that now
<SpamapS> adam_g: let me know when you've pushed, will pull and sponsor w/ the updated bug reference.
<adam_g> SpamapS: done
<lifeless> kirkland: wants (top left corner thing)
<lifeless> kirkland: wants wants wants!
<SpamapS> adam_g: ok, sponsoring now
<adam_g> SpamapS: thank you
<SpamapS> hrm, we really need to fix sponsor-patch to work with UDD+SRU
<tumbleweed> SpamapS: that's not really sponsor-patch's problem, is it?
<SpamapS> tumbleweed: no, UDD should probably redirect lp:ubuntu/lucid/$package to the right place..
<SpamapS> tumbleweed: but since that seems to be eluding the UDD masters.. I wonder if sponsor-patch couldn't "figure it out"
<tumbleweed> SpamapS: most of the time lucid-proposed/$package doesn't exist
<micahg> SpamapS: right place is relative
<SpamapS> micahg: indeed, that is the problem in a nut shell.
<kirkland> lifeless: okay, i found it
<kirkland> lifeless: it only works with u3d though, not u2d which i'm running for aforementioned battery reasons
<lifeless> kirkland: ah :(
<kirkland> lifeless: if you're on 3d, it's easy though
<slangasek> cjwatson: can you offer any guidance regarding the merge of debian/keyboard-configuration.config in console-setup?  I'm walking the history now to understand it, but maybe there are specific pitfalls I should be watching out for?
<slangasek> (the conflicts are rather broad, unfortunately)
<lifeless> kirkland: cool... how
<kirkland> lifeless: ccsm
<kirkland> lifeless: search for 'unity'
<kirkland> lifeless: top option, "reveal mode"
<kirkland> lifeless: set to 'top left'
<cjwatson> slangasek: it basically amounts to (1) ubiquity integration (2) improved upgrade handling of various degrees of horribleness (3) handling of some more layout/variant combinations and defaults (4) cdebconf-keystep integration (just make sure to keep the state machine numbers right)
<slangasek> yeah, that last one is the bit that gives the nasty merge
<cjwatson> I would be inclined to reapply that by hand one case-option at a time, and adjust the following states on the way
<slangasek> hmm
<cjwatson> it's not desperately hard to keep track of if you do it that way, but bzr is not likely to be able to do a good job
<slangasek> yeah, especially considering the file had a different name when this was originally applied, I'm struggling with bzr
<cjwatson> in extremis I guess I could take the conflicted file plus {BASE,THIS,OTHER} and try to progress it
<cjwatson> although collaborative merge resolution is ... hard
<slangasek> I think I'm starting to understand how it fits together
<slangasek> I might ask for review when done :)
 * cjwatson nods
<slangasek> cjwatson: where is $detect_keyboard even supposed to come from?  Way back in rev 217 of debian/config.proto, I see it being set; but the current file doesn't have this
<cjwatson> hmm, that's an excellent question
<cjwatson> I fear I screwed up the merge in r355 slightly
<slangasek> cjwatson: so the bits from 217 should be put back?
<cjwatson> ... so how did keyboard detection work last time I observed it working then?
<slangasek> (the capb stuff)
<cjwatson> oh, hah
<cjwatson> $ detect_keyboard=
<cjwatson> $ if $detect_keyboard && true; then echo yes; fi
<cjwatson> yes
<cjwatson> shell semantics can still surprise me after all these years
 * slangasek snickers
<cjwatson> it's probably broken in the gtk frontend
<cjwatson> so yes, those bits should be put back
<cjwatson> well spotted
<cjwatson> (I know it works in oneiric, at least in d-i, I test it from time to time)
<broder> what do i do to get listed on the "People" page on the workitems tracker?
<bryceh> broder, would think you should be there automatically; pitti can fix, so chat with him?
<broder> ok. i'll try to catch him tonight
<broder> i know i never showed up last cycle, and i thought i had work items assigned to me
 * cjwatson blinks
<cjwatson> $ dpkg-architecture -qDEB_BUILD_ARCH; dpkg-query -W gcc-4.6; gcc ---_this_is_not_a_flag_ -o /dev/null -xc -c /dev/null
<cjwatson> armel
<cjwatson> gcc-4.6 4.6.2-2ubuntu1
<cjwatson> $ dpkg-architecture -qDEB_BUILD_ARCH; dpkg-query -W gcc-4.6; gcc ---_this_is_not_a_flag_ -o /dev/null -xc -c /dev/null
<cjwatson> i386
<cjwatson> gcc-4.6 4.6.2-2ubuntu1
<cjwatson> gcc-4.6.real: error: unrecognized option â---_this_is_not_a_flag_â
<cjwatson> (yes, gcc on $PATH points to /usr/bin/gcc-4.6 in both cases)
<slangasek> gcc-4.6.real?
<slangasek> ccache or something?
<cjwatson> hardening-wrapper
<slangasek> ah
<slangasek> in both cases?
<cjwatson> no, just i386, and same behaviour after removing it
<cjwatson> which is good for i386; it's the armel behaviour I don't understand
<cjwatson> oneiric/armel behaves properly; precise/armel is busted
 * slangasek nods
<cjwatson> these xz binary upload failures are getting irritating; shame there's not much to be done about them except whack-a-mole and wait six months
<cjwatson> the Debian perl team has started transitioning at rather a rate of knots
<slangasek> phooey
<debfx> couldn't pkgbinarymangler add the missing Pre-Depends if xz is used?
<cjwatson> I guess that might be a possibility
#ubuntu-devel 2011-11-08
<psusi> kees, re: bug #556167 when you say "actual disk files" what are you referring to?  a block device?
<ubottu> Launchpad bug 556167 in vm-builder (Ubuntu) "vmbuilder uses parted to create disk images, which leads to broken sector counts (cannot use grub2 on disk images created by vmbuilder/parted)" [Medium,Confirmed] https://launchpad.net/bugs/556167
<bryceh> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | 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 application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> could somebody (a Kubuntu person perhaps) merge libkipi and kde-baseapps?  The lack of those merges is causing gwenview to fail to build
<slangasek> ev: has bug #542310 been a problem lately?  the change apparently got dropped in a console-setup merge in maverick
<ubottu> Launchpad bug 542310 in Ubuntu Translations "Corrupted layout/variant list on Step 3 in installer" [High,Fix released] https://launchpad.net/bugs/542310
<adam_g> is there anything that needs to be added to bug #885998 to expedite release of the regression fix? i can't seem to nominate it for series, but the proposed branches have been merged into -proposed earlier today. awaiting upload
<ubottu> Launchpad bug 885998 in facter (Ubuntu) "facter upgrade crashes puppet" [Critical,Confirmed] https://launchpad.net/bugs/885998
<slangasek> cjwatson: lp:~ubuntu-core-dev/console-setup/ubuntu/ updated and ready for review
<slangasek> adam_g: looking
<slangasek> adam_g: since I don't speak ruby so I'm not sure what this does; what's 'rescue'?
<slangasek> (accepting, anyway)
<adam_g> slangasek: it catches an exception. ive run it by jacob (upstream) and he confirms the fix
<adam_g> gah. i need to run
<adam_g> slangasek: thanks for checking that
<slangasek> adam_g: well, that would've been my first guess; I think I'm confused that explicitly catching the one exception, but returning the same value as in the common case, is semantically significant :)
<slangasek> adam_g: packages accepted for lucid/maverick/natty; as soon as someone confirms that the package fixes the regression, one of the SRU team members can push to -updates
<slangasek> cjwatson: do we apply the same policy as Debian regarding including translations in udebs (i.e., only when translation percentage is high enough)?
<slangasek> cjwatson: user-setup has wo, cy translations dropped upstream, but there are local Ubuntu translations
<pitti> Good morning
<pitti> roaksoax: I am now, what's up?
<pitti> roaksoax: rh-cluster is not in the queue, I suppose someone already did
<pitti> broder: I'm not actually sure; can I please refer you to cjohnston about this?
<pitti> broder: but NB that it doesn't yet produce precise charts; you might just turn up automatically if you get precise WIs
<broder> pitti: sure, no problem. i might alternatively get bored and go source diving
<manish> pitti: can you review my review request for software-properties?
<pitti> manish: sure, in a bit; I need to do some firefighting right now
<pitti> manish: can you toss me the link, and I'll review it ASAP?
<manish> pitti: sure https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/887249
<ubottu> Launchpad bug 887249 in Software Properties "Providing wrong ppa format in add-apt-repository throws a 404 error which is not handled appropriately" [Undecided,In progress]
<manish> yeah sure, look at it when you are free. No hurry
<dholbach> good morning
<Laibsch> Can somebody please accept the nomination for LTS for bug 807545?
<ubottu> Launchpad bug 807545 in piuparts (Ubuntu) "piuparts uses debian instead of ubuntu keyring" [Low,Fix released] https://launchpad.net/bugs/807545
<Laibsch> it really is too easy for SRU work to be ignored because the main task is already fixed (which is a prerequisite for an SRU, mind you!).  I don't think I need to tell you that this is very frustrating for a contributor.
<pitti> Laibsch: done
<Laibsch> pitti: thanks!!
<smb> jhunt_, morning, are you around?
<jhunt_> smb: hi
<smb> jhunt_, Just wanted to let you know that I "fixed" the battery info problem in hardware (seems it needed a battery removal for a bit). Still I think it would be good if we could get udev fixed in a way not to repeat something till eternity that fails (and in turn setting the machine on fire, sort of)
<jhunt_> smb: interesting. However, I believe kay's view is that upstart-udev-bridge should be tweaked to handle this rather than changing udev. My concern is that *if* any hardware already exposes data via utf-8, fixing this problem at any level will potentially cause a change in system behaviour since before dbus added this new assert, utf-8 data may have been propagating into userspace.
<jhunt_> smb: I'll take a look at this today.
<smb> jhunt_, I agree. I think what the contents of the data are is a different problem and finding that it just was crappy hw makes it a much less important thing to fix. The lesson learned here would rather be that upstart-udev-bridge needs a way to handle this in a way of knowing that the invalid characters error won't go away by sending them again to dbus.
<chrisccoulson> hmmm, does anybody have any idea what's going on with https://launchpadlibrarian.net/84686467/buildlog_ubuntu-natty-powerpc.firefox_8.0%2Bbuild1-0ubuntu0.11.04.1_FAILEDTOBUILD.txt.gz ?
<chrisccoulson> it fails because of a missing file, despite the fact that this source is identical to one which already built successfully
<chrisccoulson> i can't reproduce it on the ppc porter box
<chrisccoulson> and there's lots of "rm: cannot remove directory `chroot-autobuild/build/buildd/*" after it fails too
<ev> slangasek: huh, I haven't noticed any further reports like that
<pitti> chrisccoulson: looks like someone interrupted the build
<pitti> chrisccoulson: the standard way of cancelling a build is to rm -rf its build tree
<chrisccoulson> pitti - hmmm, they've interrupted all of the builds then. all the firefox builds failed in the same way
<pitti> chrisccoulson: perhaps they needed the powerpc builds for an urgent security update?
<chrisccoulson> pitti - this was a security update ;)
<pitti> chrisccoulson: so, no idea I'm afraid; lamont might know more
<chrisccoulson> thanks
<pitti> slangasek: I set you as reviewer of https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-power-consumption; is that ok for you or want me to find someone else?
<cjwatson> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | 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 application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cjwatson
 * dholbach hugs cjwatson
<iceroot> cjwatson: hi
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, it is about bug 877793. Some people use the upstreanm source HPLIP instead of the Ubuntu one because they want the newest for some reason (and there is no LSB package of HPLIP).
<ubottu> Launchpad bug 877793 in HPLIP "Ubuntu 11.10 HPLiP drivers not working for Color Laserjet CM2320nf printer" [Undecided,In progress] https://launchpad.net/bugs/877793
<iceroot> cjwatson: if i am correct, you help people getting there patches in ubuntu and/or upstream?
<tkamppeter> The upstream HPLIP installs certain libraries to /usr/lib64 on 64-bit systems. This was no problem until Natty, as there /usr/lib64 was a softlink to /usr/lib. This got dropped in Oneiric. Why?
<cjwatson> iceroot: that's the theory anyway
<iceroot> cjwatson: :) may  i steal some of your time?
<cjwatson> iceroot: sure
<pitti> tkamppeter: I don't know really; presumably because of the multiarch transition
<tkamppeter> pitti, who should I ask?
<pitti> tkamppeter: slangasek is probably the best person
<tkamppeter> slangasek, hi
<iceroot> cjwatson: https://bugs.launchpad.net/ubuntu/+source/kwalletcli/+bug/802274  is there a way instead of this debdiff-thing that i can build and upload! the package myself to some proposed repos?
<ubottu> Launchpad bug 802274 in kwalletcli (Ubuntu) "Security issue in kwalletcli_getpin(1): tty I/O now properly disables echoing input when asking for a passphrase is not fixed" [Low,Confirmed]
<cjwatson> iceroot: you can certainly use a PPA (https://help.launchpad.net/Packaging/PPA); that may be useful to you to have a fixed version in the meantime, although it won't help it get into the security repository
<iceroot> cjwatson: so the correct way to get it in the sec-repos is waiting for a review of the debdiff?
<iceroot> cjwatson: so the steps i did were correctly and nothing more to do for me
<cjwatson> right, that's the only way.  there are a couple of improvements you could make though; the version number would be more obviously correct for a security update if it were 2.03-1ubuntu1.1 rather than 2.03-1ubuntu2; the upload target should be "natty-security", not "natty"; and if I were you I would use 'quilt rename' to rename the debian/patches/ file to something more descriptive, and fill out the patch header template
<cjwatson> (I would help, but I don't have access to upload to -security myself; you did the right thing in subscribing ubuntu-security-sponsors)
<cjwatson> thanks for your patch, sorry it seems to have taken a while for people to look at it
<iceroot> cjwatson: thanks for the feedback sounds good. for the version-numer is was just using dch -i, the upload target "natty-security" is the "tag" where also the tag "patch" is? and what do you mean with "patch header template"?
<iceroot> cjwatson: ah ok, i see what you mean with patch header
<iceroot> cjwatson: but +Reviewed-By: <name and email of someone who approved the patch>  should not be filled from me?
<cjwatson> iceroot: version number - right, but dch -i isn't always the best thing to use for security updates, see https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<cjwatson> iceroot: upload target - where it currently says "natty" on the first line of debian/changelog
<cjwatson> iceroot: patch header - leave out fields you can't fill in, don't just leave them as the template
<iceroot> cjwatson: ok then i only will use +Bug-Ubuntu: https://launchpad.net/bugs/<bugnumber>
<iceroot> cjwatson: thank you very much for your feedback and your time. i will no recreate my debdiff and upload it again
<cjwatson> it should also have Description and either Author or Origin
<cjwatson> at minimum
<iceroot> cjwatson: already set
<cjwatson> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/openssh/precise/view/head:/debian/patches/auth-log-verbosity.patch for example
<cjwatson> iceroot: true, though it's best to trim down the Description from the one that was automatically created there.  "Description: tty I/O now properly disables echoing input when asking for a passphrase" for instance
<cjwatson> anyway, this is relatively minor, just helps the person reviewing it to see that you know what you're doing and thus process it faster :)
<iceroot> cjwatson: i will do so. a patchpilot is a good "thing" to help people with things like that :) good work
<cjwatson> ok, glad to help
<dupondje> Hi, could somebody look @ https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887481 ?
<ubottu> Launchpad bug 887481 in papyon (Ubuntu) "Unable to connect to MSN/Windows Live network" [Undecided,Confirmed]
<dupondje> seems like alot of people are affected
<apw> pitti, do we have a precise work-items db as yet ?
<pitti> apw: status.u.c. has been switched apparently
<apw> pitti, are we maintaining our own bot for that or dropping it
<apw> (the one in ~platform)
<pitti> apw: well, it is our's
<pitti> apw: no, the one on people is gone
<pitti> it just retains the old charts for hysteric raisins
<apw> and does the one on status maintain db we can snarf?
<pitti> james_w: ^ do you know?
 * pitti checks on cranberry
<pitti> apw: http://status.ubuntu.com/ubuntu-precise/ubuntu-precise.db
<pitti> james_w: unping
<apw> pitti, thanks
<sebner> cjwatson: thanks for syncing flightgear and related stuff :)
<apw> pitti, so i assume james_w is the one to hastle about issues on status ... seems its importer isn't well as it sees 2 WIs on https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-config-review which has about 20
<cjwatson> sebner: np
<dupondje> https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349 and anoher one :( bugfix seems to be already upstream
<ubottu> Launchpad bug 887349 in papyon (Ubuntu) "Can't login in Windows live acount using empathy" [Undecided,Confirmed]
<zyga> mvo, hi
<zyga> mvo, quick question: is aptitude supposed to work well with multiarch?
<zyga> mvo, I keep getting odd behaviour, some of which smells like bugs
<mvo> zyga: its not working well, but not totally broken. i would suggest to use apt-get for now
<zyga> mvo, ah, ok so this is expected
<mvo> yeah, at least currently
<zyga> mvo, I mainly see 'new packages' going crazy (resetting to ~18K) and spurious remove frenzy when I accidentally try to install i386 library
<herton> pitti: launchpad.net/bugs/871899 is waiting to be copied to -updates/-security for some time, can you take a look? (I want to push a new update this week to -proposed)
<pitti> herton: oh, I thought I caught them all last Friday
<pitti> herton: doing
<herton> thanks
<pitti> herton: done
<pitti> herton: ah, I remember -- I skipped this on Friday
<pitti> herton: releaseing a new major kernel to -updates on a Friday before everyone hopped into planes seemed a bit bold
<herton> hehe ok, np. thanks
<dupondje> https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349
<ubottu> Launchpad bug 887349 in papyon (Ubuntu) "Can't login in Windows live acount using empathy" [Undecided,Confirmed]
<dupondje> attached debdiff
<dupondje> could somebody check please?
<dupondje> barry: are you there ?
<tkamppeter> slangasek, hi
<cjwatson> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | 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 application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dupondje> its silent here :(
 * dupondje looks nice to some people to review patch in https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349 :)
<ubottu> Launchpad bug 887349 in papyon (Ubuntu) "Can't login in Windows live acount using empathy" [Undecided,Confirmed]
<lamont> chrisccoulson: that looks for all the world like someone stabbed a build... wasn't me
<chrisccoulson> lamont, it's ok. someone killed it because the builds hang. i was confused because the same person must have killed the precise build, which is the only one without the problem
<chrisccoulson> i uploaded a fix for all the other releases now
<m4n1sh> mvo: as I see you are the uploader of software-properties, can you look into this merge request when you have time https://code.launchpad.net/~manishsinha/software-properties/fix-887249-handle-404-error/+merge/81488
<lamont> chrisccoulson: it is sad when we're overly thorough. :(
<chrisccoulson> lamont, that's ok :)
<lamont> cool
<chrisccoulson> lamont, would you mind killing the builds on ross, buttercup and cushaw though? :-)
<lamont> bah
<lamont> sure, why not.
<chrisccoulson> those all have the same problem
<dupondje> kenvandine: I see you also did uploads for papyon. Could you check the bug above please? Nobody is able to connect to msn anymore with empathy ... :)
<lamont> chrisccoulson: terminating now
<chrisccoulson> lamont, cool, thanks
<lamont> chrisccoulson: in the classic manner:  rm -rf ../chroot-autobuild/build/buildd/*
<kenvandine> dupondje, sure
<lamont> well, .../chroot....
<chrisccoulson> lamont, excellent, thanks :)
<lamont> the idea being that when you look at a build and go "wtf, looks like the source tree just disappeared from under the build", you know it was terminated with prejudice
<chrisccoulson> lamont, yeah, i'll remember that in future :)
<kenvandine> dupondje, cool... i'll sponsor that
<dupondje> sweet :D
<dupondje> at least we can msn again then :D
 * kenvandine doesn't use msn, but glad to help others :)
<dupondje> well its the only way to communicate with girls online ;) except facebook :P
<kenvandine> hehe
<mvo> m4n1sh: sure, I have a look now
<m4n1sh> mvo: another clarification. I have some ideas in mind on how to improve adding PPA - both by command line and via GUI
<m4n1sh> it it would need launchpadlib as a dependency
<m4n1sh> would it be okay to have it as a dependency? AFAIK launchpadlib is in main
<mvo> m4n1sh: yes, adding LPlib is fine
<mvo> m4n1sh: hm, hold on a sec, I need to check how much this adds to the CD, but in general it should be fine .)
<m4n1sh> isn't python-launchpad installed by default?
<m4n1sh> mvo: where can I get the list of packaged on the CD? IIRC a URL had some  iso seeds or something like that
<mvo> I don't think so, but let me double check
<m4n1sh> sure
<cjwatson> python-launchpadlib is already on pretty much all our images
<mvo> m4n1sh: the seed output is here http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/ but I'm lazy and just boot the livecd in a vm. aha, it appears that python-launchpadlib is installed already
<cjwatson> if you're just checking whether it's on the CD it's usually quicker to check the .manifest and .list files at http://releases.ubuntu.com/oneiric/ or http://cdimage.ubuntu.com/daily-live/current/ or whatever's appropriate
<pitti> I usually use apt-cache show and look at Task:
<pitti> Package: python-launchpadlib
<pitti> Task: cloud-image, ubuntu-desktop, server, ubuntu-usb, [..]
<cjwatson> yeah, me too, but that requires a bit more interpretation
<cjwatson> $ curl -s http://releases.ubuntu.com/oneiric/ubuntu-11.10-desktop-i386.manifest | grep python-launchpadlib
<cjwatson> python-launchpadlib     1.9.8-2
<pitti> mvo: if nothing else, then apport depends on it
<m4n1sh> another question is whether this same application is present in debian too
<pitti> but launchpad-integration, too
<m4n1sh> in this case care has to be taken to make sure that if launchpadlib is not present
<m4n1sh> then it should now throw an error
<m4n1sh> software-properties is also used in debian?
<mvo> cjwatson, pitti: thanks, both solutions are good to keep in mind :)
<m4n1sh> *not throw an error
<mvo> m4n1sh: yeah, indeed
<m4n1sh> my plan was to provide a section in software-properties-gtk
<m4n1sh> when you click add
<m4n1sh> instead of just providing a line for adding deb
<m4n1sh> I was thinking adding a PPA section too
<mvo> m4n1sh: patch looks fine, I will merge now
<m4n1sh> thanks
<dupondje> kenvandine: could you SRU that also ? :)
<kenvandine> dupondje, already did :)
<dupondje> aight :D
<dupondje> thx
<kenvandine> np
<roaksoax> pitti: howdy! it seems that rh-cluster is in -proposed still (at lesat that's what lp says), is there a way to unapprove that upload?
<pitti> roaksoax: oh, I misunderstood you
<pitti> roaksoax: I thought you meant "reject from the queue"
<pitti> roaksoax: yes, we can remove the pacakge from -proposed, the question is why
<pitti> roaksoax: if we remove it, that won't magically uninstall/downgrade it for people who already installed the -proposed update
<pitti> roaksoax: if we are going to fix it harder, there should just be a new -proposed upload
<roaksoax> pitti: yes that's the plan. Reject the upload and upload a new ubuntu5.1 package with more fixes or should I go ahead an upload a ubuntu5.2?
<pitti> roaksoax: you can't reupload ubuntu5.1, the version number is taken
<pitti> roaksoax: just upload 5.2
<pitti> with a fix for the fix :)
<pitti> but we are not exactly short of natural numbers
<pitti> I heard there's quite a lot of them :)
<roaksoax> hehe will do
<roaksoax> thanks
<dupondje> kenvandine: the patch will prolly needed to be SRU'ed in lucid etc also.
<kenvandine> dupondje, can you create a debdiff for lucid as well?
<kenvandine> i suspect the patch won't apply cleanly as is
<dupondje> I make one
<kenvandine> dupondje, thx
<dupondje> kenvandine: attached patch in https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349
<ubottu> Launchpad bug 887349 in papyon (Ubuntu Oneiric) "Can't login in Windows live acount using empathy" [High,Confirmed]
<kenvandine> dupondje, thx
<kenvandine> dupondje, can you do natty and maverick as well?
<dupondje> sure, give me some minutes :)
<kenvandine> thx
<kenvandine> :)
<dupondje> kenvandine: attached
<kenvandine> dupondje, thx
<slangasek> pitti: happy to be reviewer for desktop-p-power-consumption
<slangasek> ev: alright, if there are no reports of that regression I'll not worry about it further and leave it to you to decide if the patch should be reapplied or if it's obsolete
<ev> I'm happy to drop it and see what breaks, knowing that everything is safely tucked away in version control
<slangasek> tkamppeter: /usr/lib64> this directory is disallowed as an installation target by Debian plicy
<slangasek> policy
<slangasek> tkamppeter: why does the upstream build not auto-create this directory when installing?
 * JLuc is away: OccupÃ©
<Pici> JLuc: We'd appreciate if you disabled those messages in Ubuntu channels.
<Laney> occupy #ubuntu-devel
 * Laney sits down
<nigelb> heh
<lynxman> Laney: want some cookies?
 * lynxman distributes cookies and milk amongst the occupiers
<chrisccoulson> Laney, did you see https://twitter.com/#!/search/%23occupyhtml5 ?
<chrisccoulson> i found that last week at UDS. made me laugh ;)
<cr3> is there a way I could some of the steps during the installation of a package, like configure for example, from within the source of a project with a debian/ subdirectory? I'm not sure if that even makes sense though, I'm just hoping someone got tired of the debuild/pbuilder, then install, to work on the installation scripts
<cr3> s/I could some/I could run some/
<cjwatson> cr3: you could dpkg --unpack an earlier build of the package, edit the postinst in-place in /var/lib/dpkg/info/ to match how you want it to look, then dpkg --configure $package
<cr3> cjwatson: I wasn't familiar with --unpack, thanks!
<infinity> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | 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 application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<infinity> <-- coughing, sniffing, pilot of exploding sinus doom.
<SpamapS> ahh lovely, offlineimap has decide today is the day it should delete and re-download all of my email
 * SpamapS gets coffee :-P
<infinity> SpamapS: Maybe it got bored?
<SpamapS> yeah, its like my 2 year old.. if it can't figure things out, it just screams and sets it all on fire
<cjwatson> wow, your house must be fun to live in
<infinity> Warm, at any rate.
<m4n1sh> mvo: is software-properties under CLA?
<glatzor> m4n1sh, right. it is.
<m4n1sh> glatzor: really? wans't it created before CLA came into existance?
<m4n1sh> I remember software-properties-gtk in 6.06 too
<glatzor> m4n1sh, you are free to distribute, fork or modify it. the code is released under GPL
<m4n1sh> well, that is not a solution anyway
<m4n1sh> never mind, just wanted to know
<glatzor> m4n1sh, but if you want to make a larger contribution to the software-center hosted and deployed by ubuntu you have to sign
<glatzor> the cla
<m4n1sh> hmm
<glatzor> m4n1sh, the cla "only" affects the canonical source code repository
<m4n1sh> glatzor: I am changing lp:software-properties
<glatzor> m4n1sh, why?
<m4n1sh> for making apt-add-repository more friendly
<m4n1sh> now noticed it is under CLA
<tkamppeter> slangasek, still there?
<tkamppeter> slangasek, as I understand, the upstream package creates /usr/lib64 because it is missing and then installs libs into it. The system then searches them in /usr/lib.
<slangasek> tkamppeter: right - saw the bug you assigned, understand the problem now
<tkamppeter> If Debian policy forbids installing stuff in /usr/lib64 this directory would stay empty if it exists or not exist, so I see no problem to keep it a symlink simply to make badly done third-party software happy.
<slangasek> tkamppeter: not something that we can straightforwardly solve in the distribution, however; /usr/lib64 was never a part of the FHS/LSB that Debian and Ubuntu accepted
<tkamppeter> So as /usr/lib64 has no meaning at all, why not simply keep the symlink?
<tkamppeter> slangasek, ^^
<slangasek> because in multiarch, package unpacks that follow that symlink can lead to incorrect overwrites of the system libraries
<slangasek> breaking the entire system
<infinity> tkamppeter: Libraries should be installed to the correct locations.  Why it this problematic?
<slangasek> infinity: it's problematic because upstream is following the FHS, and getting bitten by it
<slangasek> because /usr/lib64 isn't on the path
<infinity> slangasek: Sure, but that becomes a non-issue when we package things sanely, surely?
<slangasek> infinity: the issue here is with unpackaged upstream stuff
<infinity> (I realise this all fails with third-party binaries, and that's a problem we've been dealing with for far too long)
 * slangasek nods
<infinity> Speaking of.  How goes the multiarch-versus-FHS battle?
<slangasek> ETOOMANYIRONS
<slangasek> the revived FHS process suffers in general from a deplorable amount of LSBitis
 * infinity gets vorlon a bigger forge.
<slangasek> which is kinda something that should be addressed, not simply taken advantage of :P
<tkamppeter> slangasek, infinity, so the bug is solely in HPLIP and in no part of Ubuntu?
 * infinity is hoping that, shortly after we get concensus that m-a paths are the way and the light, we then convince everyone that Debian's triplets are the right ones...
<slangasek> tkamppeter: it's a standards dispute; I think the right thing for hplip to do on Debian and Ubuntu is to use /usr/lib instead of /usr/lib64, because that's how we define our system
<infinity> tkamppeter: The bug is standards diverging from practice, and then some practice following new standards.
<infinity> tkamppeter: For packaged software, this is a non-issue.  For people who want to ship a single binary for "Linux amd64", it gets probelmatic if they have libraries involved.
<infinity> tkamppeter: That said, if they distributed with a tiny shell script instead of just a tarball, it fixes itself readily by just installing to the correct path.
<slangasek> we could theoretically have /usr/lib64 put on the linker path, but that still doesn't help if things like python modules get installed to /usr/lib64
<slangasek> (and from the bug report, I gather that python modules are involved)
<tkamppeter> slangasek, infinity, HP's installer is a script, it even compiles from source instead of shipping binaries. So it could for example check the absence of /usr/lib64 and then install in /usr/lib, or check the libs in /usr/lib with "file", see that they are 64-bit and then drop its own libs there too.
<tkamppeter> slangasek, infinity, am I right that SUSE does something different here, like /usr/lib/ being 32-bit-only and /usr/lib64 being the place for all 64-bit libs and executables?
<slangasek> tkamppeter: correct; that's the current FHS/LSB directory for amd64 libraries, which was driven by SuSE and Red Hat and never adopted by Debian and Ubuntu
<infinity> tkamppeter: Checking things with file would hackishly work.  They could also make their installer script depend on the existance of lsb_release and DTRT depending on the target OS.
<slangasek> or even check for the existence of /etc/debian_version, really
<infinity> tkamppeter: And yeah, the problem is that Debian was doing 64-bit for ages (on sparc, power, parisc, etc) before RH/SUSE decided to standardize on doing the inverse with ia64 and amd64.
<infinity> slangasek: Fair point, I suppose we're the only oddballs here, despite being the trailblazers.
<slangasek> infinity: whether or not we are, debian_version guarantees that we'll DTRT on all Debian derivatives even if lsb-base isn't installed
 * slangasek upgrades to precise and sighs as his terminal fonts immediately become squat and ugly.  I guess I need to try to do something about that freetype regression.
<slangasek> preferably before I go blind
 * highvoltage is reminded to complete his half-way upgrade to precise
<infinity> slangasek: Sure, it would work for us, I was trying to come up with a sane solution for upstream.  But then again, I suppose LFS and other whacky distros might not even have lsb_release available, so it's a lose-lose.
<SpamapS> slangasek: Do you think you will have time to take a look at uploading MySQL 5.5 to Debian for me today?
<slangasek> SpamapS: hmm, conceivably
<slangasek> SpamapS: where is it?
<SpamapS> svnURL: svn+ssh://svn.debian.org/svn/pkg-mysql/mysql-5.5/branches/experimental
<SpamapS> slangasek: sorry, unintentinaly raw paste.. but.. um.. ^^
<slangasek> the svn, it hurts us
<SpamapS> Agreed
<SpamapS> not sure why it ended up there and not in bzr
<infinity> That might be my fault.
<slangasek> I think that svn repo predates bzr :)
<SpamapS> possibly Norbert not having time to learn bzr. :)
<infinity> But yes, if it was my fault, it would have been long before bzr and git.
<slangasek> augh all my 1s look like pipes
<slangasek> seriously need to punch freetype
<slangasek> why is no one else screaming at me about this? :)
<SpamapS> slangasek: clearly we're all waiting for you to fix it before we upgrade
<slangasek> that's backwards
<slangasek> :P
<Chipzz> so you actually want more ppl to upgrade so you can get yelled at? that's novel :)
<slangasek> yelling is easier on my eyes
<Chipzz> true that :)
<slangasek> but no, I'm concerned at why I'm not hearing more complaints from those who have already upgraded
<broder> because they don't know to yell at you? :)
<slangasek> yeah, probably
<Chipzz> they're probably blogging "UBUNTU SUCKS" instead :P
<slangasek> SpamapS: ok, where's my upstream tarball? :)
<slangasek> will uscan dtrt?
<SpamapS> http://dev.mysql.com/get/Downloads/MySQL-5.5/mysql-5.5.17.tar.gz/from/http://mysql.he.net/
<slangasek> uscan> nope
<slangasek> SpamapS: you might want to fix debian/watch when you get a chance
<SpamapS> there is a get-orig-source .. but it looks.. scary
<slangasek> does upstream distribute signatures for that trojaned payload?
<SpamapS> whoa the watch looks.. kind of crazy
<SpamapS> http://dev.mysql.com/downloads/gpg.php?file=mysql-5.5.17.tar.gz
<slangasek> thanks
<slangasek> and of course it's only signed by the GPG Global Directory Verification Keys
<slangasek> s/GPG/PGP/
<slangasek> ahwell, better than nothing :/
<SpamapS> pub   1024D/5072E1F5 2003-02-03 [expires: 2013-09-18]
<SpamapS> sad
<SpamapS> Oracle can't afford computers that can do 2k keys
<slangasek> SpamapS: http://paste.ubuntu.com/732351/
<hallyn> (/me prepares to feel stupid)  what does this mean exactly:  W: lxc source: debhelper-overrides-need-versioned-build-depends (>= 7.0.50~) ?
<SpamapS> I did not refresh the patches, oops
<SpamapS> slangasek: will do some test builds and such with 5.5.17 ..
<SpamapS> slangasek: thanks for taking a first crack.
<slangasek> n/p
<slangasek> yeah, this is the kind of thing you generally only catch when you try to actually generate the source package :)
<slangasek> hallyn: it means your debian/rules file is using features of debhelper first introduced in that version, so the package should have a versioned build-dependency
<SpamapS> slangasek: I kind of expected you to say "no I'm busy today, lets do it tomorrow" ... ;)
<slangasek> heh
<SpamapS> my own test build just failed identically.. started before I pinged you (mk-sbuild hadn't been run on my new box yet)
<dupondje> How long does it take before a SRU gets accepted in the queue ?
<nikolam> hi, I am just experiencing some random X lockup/problem with radeo driver. X stays up frozen, console is availble and spitting radeon driver messages.
<nikolam> Hardware is Amd 690G chipset with z1250 graphics, XUbuntu 10.04 LTS amd64
<nikolam> How do I catch errors and provide enoug info for a bug report?
<nikolam> Or it is just interesting to report it on old LTS, but not important, since there are newer drivers and x both supported and in development?
<nikolam> besides, i dont have quite idea how to reproduce it.
<nikolam> But would like to learn reporting such X bug
<nikolam> driver bug etc.
<slangasek> SpamapS: btw, is libmysqlclient multiarchied in 5.5? :)
<SpamapS> slangasek: guessing it might not be.. cmake may complicate the matter. :-/
<SpamapS> usr/lib/libmysqlclient*.so.*
<broder> hmm...how do people send patches to mailing lists with bzr? i can't figure out how to get bzr-send do the git-send-email-style mailings i've been seeing on, e.g., upstart-devel
<SpamapS> broder: bzr diff ?
<SpamapS> Thats what I usually do anyway.. just bzr diff into a text file
 * broder nods
<slangasek> broder: bzr send -o $file and attach to mailer?
 * slangasek has a strong personal preference for the bzr bundles, since they show up as a merge later on my side
<broder> slangasek: preference over merge proposals? i was mostly submitting this to the mailing list as a paper trail for the MP
<SpamapS> slangasek: mysql still uses .files and a lot of explicit stuff in debian/rules .. guessing a multiarch transition will be painful, but necessary
<slangasek> broder: I sometimes send them places that don't support LP merge proposals :)
<slangasek> broder: if there's an MP, that's of course fine
<broder> slangasek: this is for setuid/setgid in upstart
<lousygarua> i think this should go to #ubuntu-app-devel but there are not as many people there as in here, so i will give it a try.
<lousygarua>  hello, i have a n00b c/c++ packaging question. i used to write my own Makefiles but I got tired of adding each new source/header file manually (i also tried some *.cpp pattern function but that's not the way to do that). I though automake/autoconf will save me the trouble of adding files manually but after reading a bit it seems that it does not do what i though it would have done. how do REAL hardcore people like you devel
<lousygarua> op c/c++ projects?
<hallyn> slangasek, no way to have lintian say which features (are newer than the debhelper version needed) I assume?
<SpamapS> lousygarua: automake and autoconf are still the gold standard. You can get a fair headstart with 'autoscan'
<broder> hallyn: http://lintian.debian.org/tags/debhelper-overrides-need-versioned-build-depends.html suggests that it's override_*
<slangasek> hallyn: the original error message actually did already... it's the override_dh_* targets that are the feature in question :)
<slangasek> hallyn: lintian -i will probably be helpful
<slangasek> broder: yeah, for upstart, an MP + bzr diff should be fine :)
<slangasek> SpamapS: so cmake shouldn't be that much of a problem for multiarching; I'm sure there are others that have been converted already, let me do a quick peek
<slangasek> SpamapS: the .files stuff is harder, and I would suggest going all the way to dh compat 9 in the process
<hallyn> d'oh, i see
<hallyn> so there's no way to use a debian/rules with override_* in a lucid build?
<slangasek> hallyn: sure there is, lucid has 7.4.15ubuntu1
<hallyn> oh, sweet
<hallyn> thanks :)
<slangasek> hallyn: but you're supposed to declare the versioned build-dependency on 7.0.50~ all the same
<hallyn> I'll just use >= 7.0.50~
 * slangasek nods
<hallyn> slangasek, oh, ok
<hallyn> thanks
<hallyn> yay, no warnings :)
<slangasek> SpamapS: cmake-using libs that are multiarched in precise: alure apiextractor cuneiform generatorrunner gtk2-engines-oxygen kvirc libdbusmenu-qt libechonest libgooglepinyin... and a few others :)
<SpamapS> slangasek: what should be the starting point for multiarching a package then?
<slangasek> SpamapS: http://wiki.debian.org/Multiarch/Implementation
<slangasek> currently it has no advice about cmake
<slangasek> that could be fixed :)
<ScottK> SpamapS: If you're looking at cmake, you might want to talk with debfx as I believe he's worked on it some before.
<bjsnider> if you declare the versioned build-dep then it breaks the build because of a lack of a new enough version of debhelper, even though it will work anyway
<bjsnider> so then you have to make an adjustment just for lucid
<slangasek> SpamapS, ScottK: OdyX seems to have done a bit of this as wel
<slangasek> well
<slangasek> bjsnider: no, it *won't* work anyway
<ScottK> slangasek: Yes.  Him too.
<slangasek> it's a versioned build-dependency because you need that version of debhelper for the build to succeed correctly
<slangasek> right, now how do I trigger gnome-terminal to see the new libfreetype
<broder> PSA: http://lintian.ubuntuwire.org/ is now live, thanks to some help from ajmitch. i'll be sending mail shortly, but feedback on what i can do to make it more useful for you would be appreciated
<ajmitch> \o/ :)
<kenvandine> dupondje, papyon uploaded for {lucid,maverick,natty,onerick}-proposed
<dupondje> kenvandine: cool
<bjsnider> slangasek, what i mean is if you use dh_make right now it will version depend debhelper to >= 8, but i think it would still work with >= 7.0.50
<lousygarua> SpamapS, thanks for the reply, i will have a look on autoscan
<lousygarua> SpamapS, or 'at autoscan', i don't know english
<slangasek> bjsnider: I haven't looked at dh_make's output recently, so I can't speak to that.
<slangasek> oho, so it's not a libfreetype issue at all
<slangasek> well, maybe that's why people aren't yelling at me
<bjsnider> ran it a few days ago on oneiric
<dupondje> kenvandine: but still some people seem to have issues even with the patch :(
<kenvandine> saw that... no idea
<kenvandine> i confirmed it failed before the update, and worked with the update on each release
<kenvandine> at least for me
<infinity> slangasek: Oh?  Local issue?  Cataracts perhaps?
<kenvandine> dupondje, perhaps they didn't make sure telepathy-butterfly restarted
<slangasek> infinity: well, I know that it's not a freetype issue, because downgrading freetype didn't help :)
<slangasek> infinity: but it may be a font regression somewhere... so hard to tell given that there's no straightforward way to map a font name to a file AFAIK
<slangasek> I was using monospace 9pt though, which is not the default
<slangasek> so others' mileage likely varies
<infinity> slangasek: Fiddle with font sizes.
<slangasek> I don't want it bigger, I just want it !ugly
<slangasek> DejaVu Sans Mono seems better
<infinity> slangasek: I had awful visual issues with Ubuntu Mono at my preferred size, turns out they just need better kerning at some point sizes.
<SpamapS> slangasek: don't fall into the same trap I did.. where my monitor was just in analog mode accidentally. ;)
<dupondje> kenvandine: could be, but I talked to upstream, and they prepared some additional patch now ...
<infinity> slangasek: (I switched back to Lucida, I think?  I can never remember what's what anymore)
<slangasek> infinity: I wasn't even using Ubuntu Mono; switching to Ubuntu Mono is also an improvement
<slangasek> SpamapS: LVDS
<slangasek> and only VGA output on the laptop, so it has to be analog for the external monitor :-P
<slangasek> anyway, I can read again, so moving on
<slangasek> chrisccoulson: I see that ubufox is being disabled for me on upgrade; is there a procedure to make sure that gets updated in a timely manner?
<chrisccoulson> slangasek, which version? i thought that was already fixed...
<chrisccoulson> micahg ^^ (may affect oneiric too)
<micahg> ugh, we'll I'm still 6 hours out at least from publishing natty+oneiric, so if you've got a fix...
<chrisccoulson> micahg, have you tested a straight 7.0.1 -> 8.0 upgrade yet?
<micahg> not yet
<chrisccoulson> slangasek, where is ubufox installed for you?
<dupondje> kenvandine: uploaded a .deb in the bugreport with the improved patch. Lets see if it fixes the issue for them.
<chrisccoulson> (in /usr/lib/firefox-addons/extensions, or somewhere in /usr/share/mozilla/extensions)?
<chrisccoulson> and was that the only extension which got disabled?
<broder> Laney: looks like (debian's) udd is already importing (debian) lintian logs. think you could look into importing ubuntu's as well?
<slangasek> chrisccoulson: xul-ext-ubufox 1.0.1-0ubuntu1, /usr/lib/firefox-addons/extensions/ubufox@ubuntu.com ?
<slangasek> chrisccoulson: it also wants to disable "Global Menu Bar integration"
<chrisccoulson> g'ah, ffs
<chrisccoulson> i hate this stupid feature
<chrisccoulson> thanks for letting me know though :)
<slangasek> y/w :)
<slangasek> want a bug report for any of this?
<chrisccoulson> micahg, you'll need to hold fire on the oneiric and natty upgrades then
<micahg> chrisccoulson: aye
<chrisccoulson> it sucks that they changed the behaviour of this feature the week before UDS
<chrisccoulson> i'm not particularly happy about that
<chrisccoulson> slangasek, is extensions.autoDisableScopes set to "11" in about:config?
<slangasek> chrisccoulson: yes
<chrisccoulson> slangasek, thanks
<slangasek> chrisccoulson: and apparently firefox throws up a prompt in a random tab asking me if I want to enable ubufox, prompting me to restart if I say yes
<chrisccoulson> slangasek, yeah, i was hoping i'd managed to disable this mis-feature for our extensions
 * slangasek nods
 * SpamapS waits for the massive mysql test suite to finish
<slangasek> broder: so one thing I'd like lintian.u.c to give us is a report of packages that use dpkg-maintscript-helper in preinst without pre-depending on dpkg (>= fwibble)
<slangasek> I suspect there isn't currently a lintian check for this
<broder> slangasek: that sounds like a good place to start :)
<slangasek> broder: you mean creating the lintian check?
<broder> slangasek: yeah. i believe that lintian upstream can accept checks that only run in an ubuntu context. and if not, patching it into our package seems reasonable (might want to check with bdrung - i know he's done a lot of work on lintian)
<micahg> yes, lintian now has a concept of profiles with Ubuntu having one
<broder> but lintian.uw.o does do per-tag reports (e.g. http://lintian.ubuntuwire.org/tags/binary-compiled-with-profiling-enabled.html)
<slangasek> broder: right - well, you asked for feedback about things you can do to make it more useful, so I was proposing one ;)
<broder> haha, ok :-P
<broder> right now i'm using our lintian source package, and only modifying it to adjust the templates. i'd like to keep it that way, and in fact i'll probably just push the templating changes into our package
 * slangasek nods
<broder> but i'll see what i can do
<bdrung> broder: nthykier did a lot of work on lintian. we have a ubuntu profile, where we can add or remove checks
<slangasek> broder: thanks :)
<broder> slangasek: by the way, if i said "caps lock" and "plymouth logo splash" in the same sentence, i'd get laughed at, right?
<slangasek> broder: why would you get laughed at?
<broder> is it expected to wokr?
<slangasek> I would think so
<broder> hmm...i wonder if my theme is broken or something
<slangasek> I'm not sure why the theme should even affect it
<slangasek> mind you, I may be showing my naivete again where consoles are concerned
<slangasek> but I thought capslock happens at a lower level than anything plymouth touches
<broder> possible. i had filed it away with "arrow keys" as being sufficiently high-level concepts that plymouth didn't care about them, but i'll take another look :)
<broder> aha. the caps lock works, but the caps lock light does not
 * broder sighs
<slangasek> heh
<broder> hmm, that actually seems to be generally true for non-X ttys
<slangasek> SpamapS: fwiw, libmysqlclient is one of two packages blocking me from being able to cross-build
<slangasek> SpamapS: ... cross-build qt4 in a multiarch env :)
<infinity> And the other?
<slangasek> libpopt
<slangasek> I may finish that one off this afternoon
 * infinity wonders why libbz2 still isn't multiarched...
<slangasek> it is in Debian
<slangasek> have we not merged that?
<infinity> Oh, we might have for precise.  This laptop's still oneiric.
<slangasek> yeah
<infinity> In which case, yay.
<slangasek> was gonna say, thought I merged that earlier
<slangasek> so that means the only package blocking a cross-grade is libapt ;D
<angelo_> Good evening to all!
 * slangasek waves
<angelo_> I'm new in ubuntu development (not in development in general). I'm trying to get a patch accepted, can anyoune help me?
<slangasek> angelo_: certainly.  where are you stuck?
 * infinity looks at the topic.
<infinity> slangasek: This might be my job today. :P
<slangasek> :)
<angelo_> I filed the bug number 881695, made a patch, made a branch of the package and made a merge proposal
<SpamapS> slangasek: I'll try to take a look at it ASAP.. still running through the test build of 5.5.17.
<infinity> angelo_: Let me have a look.
<slangasek> SpamapS: ok :)
<SpamapS> slangasek: should not be too complicated even w/ cmake
<slangasek> SpamapS: it shouldn't, but it could be :)
<angelo_> I'm really intrested became an ubuntu contributor, I'll be really proud!
<SpamapS> the libmysqlclient bits of the package are actually quite straightforward. Its all the other stuff that is a bit bonkers. :-P
<slangasek> heh
<SpamapS> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | 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 application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: SpamapS, infi
<SpamapS> time to do my duty :)
* broder changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | 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: SpamapS, infinity
<broder> that should get us enough characters to support 2 patch pilots :)
* slangasek changed the topic of #ubuntu-devel to: Precise open for uploads | 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: SpamapS, infinity
<slangasek> grabbing a bit more.. last month's release is yesterday's news ;)
<slangasek> SpamapS: btw, please run this command against the mysql svn repo: svn propset mergeWithUpstream 1 debian
<angelo-c> infinity: any news?
<Beret> should apparmor related issues go in the apparmor project or the app in which they occur?
<infinity> angelo-c: I'm digging to see if your patch just trades unportable code for unportable code.
<SpamapS> slangasek: ok, what does that do?
<slangasek> Beret: if it relates to an existing apparmor profile, then to the package which ships the profile; otherwise apparmor itself as a starting point
<infinity> angelo-c: I have a sneaking suspicion that the second argument to ioctl() is prototyped differently on every arch.
<slangasek> SpamapS: it's a property to set on the directory which tells svn-buildpackage how the svn repo relates to the upstream source
<slangasek> so that I can build with 'svn-buildpackage'
<Beret> Nov  8 16:53:58 courage kernel: [ 1065.398974] type=1400 audit(1320792838.439:23): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/telepathy/telepathy-*" name="/etc/apt/apt.conf.d/" pid=2969 comm="telepathy-butte" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<Beret> looks like I should send to the package there in that case
<SpamapS> slangasek: AHHH I was wondering why svn-buildpackage didn't work. :)
 * slangasek grins
<infinity> angelo-c: As for the second half of your patch.  Does this need ESD to work correctly, or is that just a personal preference?  I realise the current state of sound on Linux is messy, but I'm not sure making it messier is the answer. ;)
<micahg> Beret: telepathy-mission-control-5 most likely
<Beret> micahg, OK, thanks
<angelo-c> infinity: could be possible, the patch works for sure in x86-64, how I may help you in finding confirmation? I read the padsp source code and there the ioctl has an unsigned int as a second argument
 * micahg wonders why Microsoft wants to see one's apt configuration
<Beret> micahg, apt and /etc/default/apport
<infinity> angelo-c: If using a uint seems to be common practice, I suppose I can live with that.  I was actually walking headers to see if I could find opposite examples.
<infinity> angelo-c: But if padsp fails, people would/should notice. :P
<Beret> micahg, http://pastebin.ubuntu.com/732560/
<angelo-c> infinity: xoscope was written for esd and pulseaudio is a drop in replacement for esd. The fallback mechanism was to use raw /dev/dsp, but it's not present in the latest releases of ubuntu
<micahg> Beret: idk, file the bug and tag apparmor
<angelo-c> infinity: the problem is that with the esd support disabled at compile time the software simply doesn't work!
<Beret> micahg, idk?
<micahg> Beret: I don't know
<Beret> ah got it
<infinity> angelo-c: Obviously, you've spent more time on this than I ever care to. ;)
<slangasek> "pulseaudio is a drop-in replacement for esd" - really?  I wasn't aware there was any protocol compatibility
<infinity> angelo-c: I'll take your word for it, and close my eyes and "la la la" over 17 sound thingees on my system that all seem to do remarkably similar things. ;)
<angelo-c> welll, yes, I'm using the software in previous releases of ubuntu because I'm passionate about electronics and cannot afford an oscilloscope!
<ion> pulseaudi 2209  ion   45u  unix 0x0000000000000000      0t0   12723 /tmp/.esd-1000/socket
<infinity> angelo-c: Though, it's worth noting that on my system, the only thing that depends on libesd0 is mplayer.  Not a rousing recommendation for it being a sane solution.
<slangasek> ion: oh, quite - neato
<ion> /usr/lib/pulse-1.0/modules/libprotocol-esound.so
<infinity> Anyhow...
<angelo-c> infinity: I personally tested the patch, and for me it works. I think that from an audio point of view, there is no problem, because it is simply a client. Pulseaudio recongnise the client as it was a really pulseaudio software written for!
<infinity> angelo-c: Care to update your branch with a debian/changelog and such?  I'm doing nothing here but reviewing, I'd rather you get the credit for the upload when I sponsor it.
<infinity> angelo-c: And were you hoping to target this same fix at oneiric (that brings us to more red tape and fun), or happy with getting it fixed in precise?
<Chipzz> angelo-c: don't know if anyone mentioned this already, but as an aside: most ppl prefer patches in unified diff format. so create patches with diff -u in the future ;)
<infinity> Chipzz: He made a merge proposal.
<infinity> Chipzz: Seems reasonable enough to me.
<Chipzz> infinity: there's also a patch attached to the bug
<Chipzz> https://launchpadlibrarian.net/84216243/uiioctl.patch
<infinity> Chipzz: Yes, the MP came after the patch.
<infinity> Chipzz: As in, you're preaching to the choir. :P
<infinity> (Also, as a side note, unless a patch is literally unreadable, I find complaining about how people help fix software to be pretty offputting)
<angelo-c> ok ok, sorry, i'm confused! I think I messed up something
<ion> You can convert patches to -u format with filterdiff.
<infinity> (Side, side note, I hate LP merge proposals, but I don't care)
<infinity> angelo-c: You didn't mess anything up. ;)
<ion> filterdiff -v --format-unified foo.patch
<ion> --format=unified
<angelo-c> so, the best is to make a unified diff or a merge proposal? In the doubt I made both!
<StevenK> infinity: You prefer Github PRs? Which mostly look like LP's MPs anyway?
<Chipzz> infinity: I wasn't complaining. but I have seen it happen multiple times that ppl submit a patch in normal format and get told to resubmit in unified format.
<infinity> StevenK: I just prefere patches, usually.  At least, for Debian packages.
<angelo-c> for the sake of completeness, from the pulseaudio website: Make sure to load the module-protocol-esound-unix PulseAudio module for optimal support for ESOUND clients. Since this is the default you shouldn't need to change anything.
<angelo-c> the module is default also on ubuntu
<infinity> angelo-c: Yep, yep.  From your explanations (and a quick gander at the padsp source), your patch seems sane to me.
<infinity> Well, as sane as software scopes can be.
<infinity> I applaud your frugality. :)
<angelo-c> infinity: Yeah! big news!
<Chipzz> angelo-c: I think in general (although taste differs, like you can see from infinity's response) ppl prefer branches
<Chipzz> (easier to merge)
<chrisccoulson> slangasek, any chance you could send me the extensions.sqlite from your firefox profile? i'm having a really hard time trying to recreate this :(
<angelo-c> Chippzz: it was my tought also
<ion> Oh, filterdiff doesnât support the default diff format.
<angelo-c> so, I have to update debian/changelog and push my branch, ok?
<slangasek> chrisccoulson: emailed
<infinity> ion: Well, without the original source, converting a diff to a udiff would be impossible.
<infinity> ion: It's CSI-style enhancement.
<chrisccoulson> slangasek, thanks
<infinity> angelo-c: Ideally, yes.  "dch -i", make sure the version number is sane, target it at precise.
<Chipzz> angelo-c: and wrt to -u format, in my experience I've seen lots of ppl (including project maintainers) say that they find unified diffs easier to read. It's not wrong per se, more like a "generally preferred" format
<infinity> angelo-c: Or if you were hoping to get this fix into oneiric, we need to talk more about process there. ;)
<angelo-c> infinity: wait a minute
<infinity> Chipzz: Yeah, I won't disagree that unified diffs are easier to read.  I just tend to be "the guy" who gets annoyed when "your format is wrong" seems to be the first feedback to a contribution. :P
<Chipzz> infinity: I wasn't trying to bash the guy, rather give some advice on what is considered "normal" by most ppl. hence the smiley after my first sentence
<ion> infinity: The only thing https://launchpadlibrarian.net/84216243/uiioctl.patch seems to lack is a filename, and diff -r seems to include them, too. If you had filenames, i guess you could convert to -u format.
<infinity> ion: Filenames and the original source, yeah.
<infinity> ion: But filterdiff can work magic without the original source, which is generally its fancypants usecase.
 * slangasek snags the multiarch patch for popt from the Debian BTS, yaay suihkulokki
<broder> infinity: i think we need more of "those guys"
<ion> Does patch crap itself if given a unified diff without context lines? One would think it would still work as well as the default-format contextless diff.
<infinity> angelo-c: I'm going to run off for a quick smoke and a drink.  I'll check in with you in a few minutes.
<infinity> ion: Try it?  It tends to get right annoyed if you break unified format even a little.
<infinity> ion: But I see what you're driving at.  You could make a contextless unified diff from a classic diff.  Of course, the only point would be to turn <> into -+ and make the line position marker more human-readable.  Doesn't seem like a worthwhile exercise. ;)
<ion> infinity: diff -U 0 generates unified diffs without context and patch accepts them fine.
<ion> Definitely not worthwhile, i was just thinking of whatâs possible hypothetically. :-)
<Chipzz> ion: well it's not the contect that's annoying in unified diffs IMO
<leex> hi
<Chipzz> ion: the "location" (line number) tends to be a bigger problem in practice
<Chipzz> (if unified diffs cause problems at all)
<broder> Chipzz: honestly, i think the normal diff format was perfectly clear in this particular case :)
 * slangasek gratuitously cross-builds libpopt, to test its coinstallability before uploading
<leex> why do the decnet packages fuck up my mac addresses? resulting in the situation that both my machines at home have the hwaddr aa:00:04:00:0a:04
<angelo-c> infinity: ok, i pushed the patc with changelog!
<angelo-c> wooow!
<Chipzz> broder: in this case yes. but I was trying to point out in a polite matter that if he wanted to submit patches in the future (be it ubuntu or anywhere else) using unified diff is usually a better idea
<angelo-c> infinity: can you summirize what I have to do to make patch right for inclusion also in oneiric?
<angelo-c> ok, summarizing, using of merge proposal is discouraged, better is a unified diff, ok?
<broder> angelo-c: i don't think i would say that. i think the conclusion is unified diff over normal diff
<slangasek> leex: you're unlikely to find any decnet support here
<broder> but if you're more comfortable with merge proposals, then that's fine - you should use those
<slangasek> ... or anywhere except with the upstream author of the software in question
<Chipzz> 00:11 < Chipzz> angelo-c: I think in general (although taste differs, like you can see from infinity's response) ppl prefer branches
<infinity> angelo-c: No, merge proposals are perfectly fine.
<slangasek> SpamapS: popt done.  you're up :P
<infinity> angelo-c: The take-home from our side conversation here is "there's no incorrect way to contribute".
<leex> slangasek: yeah, i figured it out: http://sourceforge.net/apps/mediawiki/linux-decnet/index.php?title=FAQ4 and rmmod e1000e and modprobing it helped me, but i will never have decnet installed again and I guess this bug should be dealt with
<Chipzz> infinity: outside the ubuntu project, I've seen ppl ask to resubmit patches in unified format
<slangasek> leex: why in the world did you install it in the first place?
<angelo-c> ok, I really like branches and merge proposal, they are very clear form the starting point. If you know where is the source you have to modify, you are on track. For me, it has a very clear workflow
<slangasek> do you actually have a network running decnet that you can connect to?
<infinity> Chipzz: Yes, it's not a problem unique to us.  It annoys me everywhere. :P
<Chipzz> angelo-c: as for most ppl with experience with DVCS's :)
<Chipzz> infinity: the point of my initial sentence was not to blow him off, but to avoid him getting blown off in the future.
<infinity> Chipzz: I know, I know. :P
<SpamapS> sys_vars.collation_database_func         [ pass ]    255
<SpamapS> slangasek: still running tests.. 3 hours later.. :-P I need a new hard drive I think
<angelo-c> Chipzz: in a previous work the DVCS was simulated with html email sent with outlook!
<slangasek> SpamapS: :)
 * SpamapS needs to finish writing that script that runs a build in a RAM disk on an EC2 m2.xlarge
<leex> slangasek: i did not install it. it came as a dependency or while upgrading to 11.10. otherwise I wouldn't be here an flaming ;)
<infinity> angelo-c: So, you might want to have a quick read at https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<Chipzz> angelo-c: sounds painfull :)
<infinity> angelo-c: If you want to see this fix in oneiric, there's a bit of process we need to follow.
<SpamapS> $0.50 for a 5 minute build of MySQL is probably worth it. :)
<broder> SpamapS: ha! i want that script :)
<infinity> angelo-c: (I'll be uploading the precise fix in a second, though)
<Chipzz> leex: flaming here about bugs tends to be rather unproductive :P
<SpamapS> broder: I actually may just do it in a juju charm.. :)
<angelo-c> infinity: thank you for the link, I'm reading greedily
<leex> Chipzz: i guess it was ffmpeg (websearch)
<SpamapS> with a t1.micro playing the part of persistence.. when the build finishes I'll just rsync the build artifacts and set the m2.xlarge to die 5 minutes before Amazon charges me another $0.50
<slangasek> leex: which package was a dependency, precisely?
<Chipzz> leex: uh? how does ffmpeg set your mac address? ^^
<leex> slangasek: Chipzz http://www.fantaghost.com/2010/06/eth0-mac-address-fixed-on-aa0004000a04/
<leex> will research it, but I didn't install the decnet packages. they are some kind of dependency for something, this blog post says ffmpeg
<slangasek> leex: that doesn't tell me what package was installed on your system
<angelo-c> infinity: it was really a big load! Is really late, I think I can update the bug as in point 2 tomorrow evening.
<leex> sorry slangasek libdnet and i guess libdnet-dev
<leex> slangasek: let me check again
<angelo-c> infinity: another question
<infinity> angelo-c: Sure, no problem.  I'm merging and uploading for precise right now, so you can point to that in your update to the bug if/when you target it for an SRU.
<leex> slangasek: dnet-common, libdnet, libroar1, xtrans-dev
<infinity> angelo-c: Oh, one last thing.  Can you explain the esdrecord change?
<Chipzz> why in the name of ** does ffmpeg depend on decnet? ^^ :)
<leex> Chipzz: now you do it too ;)
<infinity> angelo-c: (I'll also be converting this to a patch in debian/patches, perhaps something for you to look at after I've uploaded and see how that works)
<Chipzz> leex: what? :)
<leex> the flaming part
<Chipzz> I didn't realise that was considered flaming :P
<angelo-c> infinity: for the esdrecord, the software works more reliable if the soundcard microphone is used in recording mode (as you are singing at singstar in front of your tv!), but this option is configurable at runtime via the software gui. This is only a default to facilitate new users
<leex> Chipzz: hmm aptitude show ffmpeg doesnt mention it
<slangasek> leex: have you filed a bug against the dnprogs package?
<leex> slangasek: shall I?
<slangasek> you should
<slangasek> then I can mark it critical
<leex> slangasek: here: https://launchpad.net/ubuntu/+bugs
<slangasek> I've found the brokenness in dnet-common
<slangasek> leex: 'ubuntu-bug dnet-common'
<leex> slangasek: but I am not sure which package pulls it in
<slangasek> leex: you don't need to worry about that part
<angelo-c> infinty: the question: the esd support on oneiric is broken as I stated in the bug report (https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/864071 pulseaudio crashed with SIGABRT)
<ubottu> Launchpad bug 864071 in pulseaudio (Ubuntu) "pulseaudio crashed with SIGABRT in pa_format_info_from_sample_spec()" [Medium,Fix released]
<angelo-c> infinity: working package was released some time ago in oneiric-proposed. My patch doesn't work if this package was not installed. Can you see problems with this?
<leex> slangasek: so I created an account, will post it in a second
<jasox> Does anyone what should i do to solve this on Launchpad "Keys pending validation", I tried to register openPGP 5 days ago. :S
<infinity> angelo-c: Looks like there's a fix for that in oneiric-proposed.  Can you test it and leave feedback on the bug?
<infinity> angelo-c: The SRU team likes to see feedback. ;)
<infinity> angelo-c: Oh, wait.  Nevermind.
<infinity> angelo-c: It's already made it to oneiric-updates.
<infinity> angelo-c: And no, no problems with your patch requiring a fixed package in updates.
<slangasek> jasox: I have never seen such an error message before and I'm not sure what you mean by "register openPGP".  What is it that you're trying to do?
<angelo-c> infinity: ok, you hit my concern
<leex> slangasek: nice, didn't know there is a tool for that ;)
<slangasek> leex: when you have the bug filed, please post the number here
<leex> slangasek: I will
<slangasek> infinity: when you have a half hour you would prefer to spend sputtering in disgust, you should look at the dnet-common package
<jasox> slangasek, I mean on this http://imageshack.us/photo/my-images/31/screenshotat20111109004.png/, sorry for my bad english
<angelo-c> inifinity: ok, so tomorrow I'll begin to make the bug report compliant
<infinity> slangasek: Gee, you sure know how to sell it.
<slangasek> jasox: ok.  I don't remember for sure, but my guess is that Launchpad wants to verify the key change by email
<slangasek> jasox: so it's probably trying to contact you at the email address that's listed as the primary for your launchpad account?
<slangasek> jasox: also, #launchpad is a better place to ask for launchpad support
<jasox> slangasek, thanks bro
<angelo-c> jasox: well yes, you have to decript the email message sent to your mail folder to activate the key, I made it some days ago!
<jasox> angelo-c, i didn't get any mail :S
<leex> slangasek: https://bugs.launchpad.net/ubuntu/+source/dnprogs/+bug/887825
<ubottu> Launchpad bug 887825 in dnprogs (Ubuntu) "libdnet creates fake mac address" [Undecided,New]
<angelo-c> jasox: for, it was delivered in seconds, have you a typo in yuor mail address?
<angelo-c> jasox: in the same page there is a comprehensive guide
<leex> slangasek: thanks for taking care of it ;) and sorry if I was a bit huffy
<slangasek> leex: you're well within your rights to be; it's ridiculous that this package got this far
<angelo-c> bye guys, I'm really tired, really honored to chat with you, thank you for your support!
<leex> slangasek: have had 3 fuck ups since my upgrade, i'm just not used to run into trouble since i left gentoo
<slangasek> leex: can you please attach /etc/decnet.conf from your system to the bug report?
<slangasek> (if you still have it)
<leex> slangasek: sorry purged the package
<slangasek> ok, no worries
<slangasek> will try to reproduce it here
#ubuntu-devel 2011-11-09
<slangasek> leex: actually, it seems that this package only breaks things if you specifically choose to configure it
<slangasek> Choices: configure now, configure later, skip and leave config as it is
<slangasek> Default: skip and leave config as it is
<slangasek> by default, the package does not create /etc/decnet.conf
<slangasek> and with no decnet.conf, /etc/init.d/decnet does not mangle the interface configuration.
<leex> slangasek: as said I did not install it by hand, it must have been part of a dependency, therefore I did not configure anything on my own
<leex> just did aptitude update+upgrade, wouldn't have noticed it unless it happened on both my machines
<leex> slangasek: but i am using the daily ppa for firefox and mplayer, that might have something to do with it
<slangasek> leex: ah, I see, this is Debian bug #637179, which did exist in versions prior to the latest version in precise
<ubottu> Debian bug 637179 in dnet-common "postinst script does always generate node database" [Critical,Fixed] http://bugs.debian.org/637179
<SpamapS> slangasek: ok, the mysql 5.5.17 in the repo I pointed you to builds...
<SpamapS> Build needed 02:24:21, 1379708k disc space
<SpamapS> slangasek: with current sid
<slangasek> SpamapS: spiff
<SpamapS> did not build an experimental chroot :p
<slangasek> shouldn't be necessary :)
<SpamapS> slangasek: I also have a merged version for Ubuntu.. so as soon as its accepted we can upload a merge and start the rebuilding.
<SpamapS> probably worth loading up a PPA with those rebuilds now
<SpamapS> no sense waiting
<slangasek> hmm, not in sync?
<jasox> slangasek, I solve probelem, I used another mail :)
<SpamapS> slangasek: no, there's an upstart job and a few other bits
<SpamapS> slangasek: I'm sure we can get them in sync soon tho
<slangasek> jasox: great :)
<leex> slangasek: I will go to bed now, it's quite late here, but I will check for PMs tomorrow if you send me one ;)
<leex> good night and thanks
<slangasek> leex: good night
<SpamapS> slangasek: IIRC some of our changes were somewhat big so we could drop some binary bits to universe.
<poolie> tjaalton, RAOF, can you give me any suggestions on what to do/test for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745112
<ubottu> Launchpad bug 745112 in linux (Ubuntu) "[arrandale] desktop is messed up with external monitors (x86_64)" [Critical,Triaged]
<bryceh> poolie, slangasek, are either of you able to set releasedate for oneiric in launchpad?  It's returning None presently
<broder> slangasek: can you point me at an old version of something that is missing the .xz pre-depends so i can test the lintian check?
<poolie> bryceh, just so you know you can ask 'losa' in #launchpad to do superuser type things
<slangasek> bryceh: no; I've been asked this before, I've never seen any releasedate for distributions
<slangasek> we have release dates for milestones, the releasedate for the series is something new
<slangasek> poolie: I doubt it's in the UI at all
<micahg> broder: I did this one: https://launchpad.net/ubuntu/precise/+source/lyx/2.0.1-1ubuntu1
<bryceh> released:  oneiric None
<bryceh>  Supported  natty 2011-04-28 11:36:14+00:00
<bryceh>  Supported  maverick 2010-10-10 10:19:39.197066+00:00
<bryceh>  Supported  lucid 2010-04-29 17:33:27.289933+00:00
<bryceh>  Supported  hardy 2008-04-24 00:00:00+00:00
<poolie> i doubt i can change it myself
<broder> micahg: perfect, thanks
<spm> poolie: as a general rule, with some known exceptions, we don't go near the ubuntu stuff. "can" as distinct from "should/shall"
<infinity> bryceh: Are those actually accurate?
 * infinity grumbles at no longer having access to things like https://launchpad.net/ubuntu/oneiric/+edit
<bryceh> infinity, they appear to be in the ballpark but I didn't check exact dates
<slangasek> infinity: hrm, *that* seems to be a regression
<infinity> slangasek: I don't think it is.
<infinity> slangasek: Unless you mean me not being a duckie is a regression, and I agree. ;)
<slangasek> infinity: I'm pretty sure I remember ubuntu-release giving access to that before
<infinity> slangasek: I don't think release ever did, except as a subset of drivers, which they no longer are.
<slangasek> well
<slangasek> that's a regression ;)
<infinity> slangasek: Ubuntu and ubuntu-drivers is still ickily special-cased all over, despite the lies the UI tells.
<tumbleweed> bryceh: I filed a bug for that date to be changed, too. Hoping that someone would at least set oneiric's date before ignoring the longer term bug of setting it automatically, but no such luck
<tumbleweed> bug 876345 fwiw
<ubottu> Launchpad bug 876345 in Launchpad itself "distro series releasedate not automatically set" [Low,Triaged] https://launchpad.net/bugs/876345
<bryceh> tumbleweed, thanks
<NCommander> Who do I poke to get a new topic added to the status.u.c page?
<cjwatson> bjsnider: dh_make puts '8' in debian/compat, so the Build-Depends it sets is correct for that.  If you want to make it build in contexts where debhelper 8 is unavailable, then you also need to drop the compat level; but I do think the default in dh_make is reasonable, given that 8 is debhelper's current recommended lvel
<cjwatson> *level
<cjwatson> spm: FWIW we asked for the natty release date to be set by LOSAs (and it was done) on the basis that there was no way for us to do it otherwise and people were complaining to us
<cjwatson> (for values of "we" that aren't me; I don't know if a bug was filed)
<cjwatson> oh, let's read more scrollback, how about that
<spm> cjwatson: ahh! that's new to me. it's usually just been the freeze/unfreeze thing.
<spm> heh
<cjwatson> spm: I'd kind of hoped it was a one-off
<cjwatson> it's clearly nonsense for it to have to be set manually after the fact
<infinity> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | 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: SpamapS
<slangasek> SpamapS: still doing the build here; I think I started mine significantly after yours :)
<SpamapS> slangasek: the tests are brutal on I/O
<SpamapS> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | 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:
<slangasek> maybe I should've run 'eatmydata svn-buildpackage'
<SpamapS> I have a feeling that might cause the test suite to freak out. ;)
<dr3mro> hello , I am new to linux programming and I want to create a package for ubuntu contains some files to extract on certain paths on my system .. i did create the deb file using dpkg-deb but I need to create a PPA for that can you hel me :)
<bregma> dr3mro, you can create a PPA from the home page of your Launchpad account
<dr3mro> bregma, i did the ppa and fail to build
<dr3mro> bregma, it's not a source code but rather a bunch of scripts and files to extract
<bregma> PPAs require a proper source package to build the debs from, perhaps you just want a local archive on your own machine?
<bjsnider> dr3mro, where's the buildlog?
<mwhudson> SpamapS: have you seen https://bugs.launchpad.net/ubuntu/+source/offlineimap/+bug/877883 ?
<ubottu> Launchpad bug 877883 in offlineimap (Ubuntu) "offlineimap occasionally deletes mail it has previously downloaded" [Medium,Incomplete]
<infinity> dbus build-depending on dbus is brilliant.
 * infinity shakes his head.
<broder> ugh, there are too many of those
<infinity> broder: Some of them have valid excuses (like compilers).
<infinity> broder: dbus has no such clever excuse.
<StevenK> Perhaps dbus only wishes to send messages to itself about how the compile is going.
<infinity> StevenK: *laugh*
<infinity> StevenK: It actually build-deps on python-dbus, libdbus-glib-1-dev, which is actually pretty bizarre, but I can't be bothered to hunt down why.  A few by-hand builds and some mangling, and it's easy enough to work around.
<infinity> I'd like to get to a point some day where after hand-bootstrapping a toolchain, the rest of the distro can "just build", though.  That would be novel.
<StevenK> infinity: See also 'pipe-dream'
<infinity> That was a good game.
<broder> infinity: debian/control has:
<broder> # libdbus-glib-1-dev and libglib2.0-dev can be omitted for bootstrapping,
<broder> # but if you have them in Build-Depends, more tests can be run
<infinity> broder: And python-dbus?
 * infinity shrug.
<infinity> s
<infinity> That's basically what I did anyway.
<broder> uh, don't know - i only have an old package lying around at the moment
<infinity> Though, with the usual interim "build, fail, and install anyway" step.
<infinity> I'm already over it. ;)
<pitti> Good morning
<ajmitch> hi pitti
<SpamapS> mwhudson: no I hadn't, but that is *definitely* my issue
<broder> hmm...pkgbinarymangler always strips out upstream changelogs, right? so i should probably suppress that tag on lintian.uw.o
<pitti> broder: yes
<pitti> broder: btw, thanks for setting this up!
<broder> no problem!
<dholbach> good morning
<lapo> Can someone please upgrade this patch to 11.10 http://bigbrovar.aoizora.org/index.php/2011/05/24/better-clickpad-support-for-ubuntu-11-04/
<pitti> lool: bonjour, ca va?
<pitti> lool: AFAIR you were able to reproduce the udev boot breakage which you resolved by reverting the SOCK_NONBLOCK option, right?
<pitti> lool: do you have some time to test https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034386.html ?
<didrocks> hum, I guess there is a tool that parses debian/changelog to know what the last package revision of a source is
<cjwatson> dpkg-parsechangelog
<didrocks> thanks cjwatson, my tab completion skill was pretty poor ;)
<OdyX> SpamapS: w.r.t. cmake and multiarch, take a look at the pyside stack (apiextractor, generatorrunner,shiboken,pyside). But it mostly works thanks to their CMakefiles...
<Daviey> Could an archive admin please sync bug 882507, thanks.
<ubottu> Launchpad bug 882507 in puppet (Ubuntu) "Sync puppet 2.7.6-1 (main) from Debian sid (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/882507
<StevenK> cjwatson: I think I've tracked down why datereleased doesn't get set for Ubuntu.
<cjwatson> oh good
<StevenK> Or not. It should be set.
<StevenK> cjwatson: Actually, that might it. It seems that +edit will only set .datereleased in some circumstances, but +admin will always set it. Which is making me go O.o
<StevenK> cjwatson: Do you know if there is there a bug for the datereleased thing?
<cjwatson> 00:29 <tumbleweed> bryceh: I filed a bug for that date to be changed, too. Hoping that someone would at least set oneiric's date before ignoring the longer term bug of setting it automatically, but no such luck
<cjwatson> 00:31 <tumbleweed> bug 876345 fwiw
<ubottu> Launchpad bug 876345 in Launchpad itself "distro series releasedate not automatically set" [Low,Triaged] https://launchpad.net/bugs/876345
<cjwatson> StevenK: ^-
<StevenK> Excellent, thank you.
<StevenK> cjwatson: Fixed. https://code.launchpad.net/~stevenk/launchpad/distroseries-edit-datereleased/+merge/81730 has the gory details.
<cjwatson> StevenK: excellent, thanks
<StevenK> cjwatson: I can also prod to get Oneiric fixed if you wish.
<StevenK> cjwatson: Or you can, I don't mind.
<cjwatson> StevenK: please go ahead
<Laney> broder: should be easy to do: copy the existing lintian stuff in config-org.yaml, add some sql to sql/setup.sql and modify the lintian gatherer to insert into the ubuntu table based on 'source'
<Laney> the last part might not even be necessary
<nigelb> 20
<nigelb> ERR
<nigelb> sorry
<cjwatson> jelmer: any progress on the bzr/armel build failure?  and is anyone working on making bzrtools and bzr-git installable again in precise?  I'm happy to help given pointers
<lool> cjwatson: after submitting some patches to P-a-s, I discovered that Debian is now looking at dropping most entries there when "Auto-not-for-us" is enough; do we have plans to implement this in Launchpad too?
<cjwatson> lool: I don't know
<cjwatson> lool: but we shouldn't maintain a delta against P-a-s just for the sake of it
<lool> cjwatson: I can drop an email to the lp stakeholders list
<cjwatson> well, is it possible LP already DTRT?
<jelmer> cjwatson: one of the other bzr devs is looking at the bzr build problem. I'm about to upload bzrtools.
<lool> it's entirely possible, I don't know
<cjwatson> lool: for example, syslinux-themes-ubuntu isn't in P-a-s but https://launchpad.net/ubuntu/+source/syslinux-themes-ubuntu/2 only built on the architectures listed in the Architecture line
<cjwatson> lool: I think there's nothing to do in LP
<Laney> auto-nfu is using the Architecture: list in control?
<cjwatson> I believe so
<lool> cjwatson: awesome, so we can just merge the removals then; thanks
<cjwatson> you used to get a trivial build failure instead
<lool> Laney: yes
<Laney> nice
<cjwatson> jelmer: thanks
<cjwatson> jelmer: and bzr-git too?
<lool> cjwatson: do we have some process to update ubuntu's P-a-s?
<cjwatson> lool: JFDI
<cjwatson> do you mean merging from Debian?  I do a bzr merge occasionally
<lool> cjwatson: that's what I meant
<cjwatson> just 'bzr merge lp:packages-arch-specific', resolve, commit
<lool> our branch is lp:~ubuntu-core-dev/packages-arch-specific/ubuntu right?
<lool> seems that's the only other one
<cjwatson> yes
<lool> thanks
<jelmer> cjwatson: sorry, yes - that too. It just needs to be synced from Debian.
<cjwatson> it gets deployed every hour or so I think
<cjwatson> jelmer: OK, you should be able to do that with 'syncpackage -d unstable bzr-git'
<jelmer> cjwatson: thanks
<rbasak> Do I need to declare a versioned dependency if I know that a particular release will have the version I need?
<cjwatson> rbasak: not doing so can be a dangerous game
<rbasak> cjwatson: OK I'll take that as a yes then, thanks :)
<cjwatson> rbasak: sometimes people drop them after an LTS cycle has passed, but personally I would always keep them.  What's the exact situation?
<jdstrand> @pilot in
<cjwatson> versioned dependencies are cheap and they help with things you might not have thought of like LTS-to-LTS upgrades, bootstrapping new architectures, etc.
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | 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: jdstrand
<rbasak> cjwatson: I'm backporting a fix for an SRU to Oneiric. The fix requires a particular version of python-django. The previous control file does not specify a required version, but I know that the fix does require a version which we have in Oneiric already, so I was wondering if I should amend the control file
<geser> rbasak: think also about backports. when someone backports this package to a previous release then the depedency is fulfilled but not the version requirement
<cjwatson> rbasak: imagine somebody upgrading from natty to oneiric + updates in one shot
<cjwatson> SRUs shouldn't assume that they are being installed on a system that's already been upgraded
<cjwatson> so if it needs something in particular, then absolutely include the versioned dep
<rbasak> cjwatson: OK will do, thanks.
<SpamapS> http://packages.qa.debian.org/m/mysql-5.5/news/20111109T134815Z.html
<SpamapS> woot
<apw> can anyone tell me what extras.ubuntu.com is, and whether i would expect that to exist for precise yet
<tumbleweed> apw: it should be empty for precise. https://wiki.ubuntu.com/AppReviewBoard
<tumbleweed> (but yes, probably should exist)
<cjwatson> yes please because then I could install its signatures in apt-setup
<cjwatson> it's a problem if it doesn't exist pre-release
<apw> it cirtainly doesn't exist as we stand
<apw> should i file a bug, or will someone handle it
<tjaalton> slangasek: looks like ia32-libs-multiarch mistakenly depends on gtk2-engines-murrine, which doesn't seem to be multiarched (and forces partial upgrade to precise)
<bigon> sforshee: hi, do you know if the alps patch you have made will be merged?
<sforshee> bigon, the upstream maintainer has accepted the patches, and we'll be using them in the precise kernel
<bigon> the 0.10 version of the patches?
<sforshee> basically, with a few minor (non-functional) updates
<bigon> sforshee: thx :)
<apw> sforshee, did those hit 3.2 ?
<sforshee> apw, no, they're in linux-next now
<apw> sforshee, ok so are you going to send us a pile of those ?
<sforshee> apw, i sent the pull request yesterday, and ogasawara just applied them to master-next
<apw> sforshee, oh then i'll shut up :)  cool, good work
<apw> so do we expect to be able to update via update-manager this early in the cycle?  seems to let me use -d and tell me 12.04 is there, but then dies later with "WARNING: Failed to read mirror file"
<mvo> apw: it should allow the upgrade at this point, the warning there is harmless
<apw> mvo, ok so after the -d making me be unsupported on oniric i see the normal screen.  hit upgrade and it tries to scare me.  hit upgade again and it does its normal stuff preparing, then setting new channels, then it errors about the extras.ubuntu.com being missing.  (which i also thought was not a big issue) and then close causes it to backout
<apw> so perhaps then its the extras.ubuntu.com not having anything for precise thats fubaring me
<mvo> apw: right, its there now, it will take a bit (probably until tomorrow) to get synced, if you want to upgrade now you could simply comment it out in sources.list (/etc/apt/sources.list that is)
<apw> mvo, ok confirmed that fixes it
<broder> Laney: are those scripts public? i can't find any reference to them on the udd page
<m4n1sh> mvo: can you look at one more merge proposal for software-properties?
<mvo> m4n1sh: absolutely!
<m4n1sh> sorry, not able to provide the link as I am on EDGE network (tethered), so can't even open launchpad now.
<slangasek> tjaalton: it's not a mistake; see https://lists.ubuntu.com/archives/ubuntu-devel/2011-October/034279.html
<mvo> m4n1sh: no problem I will followup in the merge proposal :)
<m4n1sh> sure
<tjaalton> slangasek: ah ok, seems I missed/forgot that one
<m4n1sh> mvo, can you make some minor tweaks if needed. I can't even branch or push on this slow connection
<mvo> m4n1sh: ok, when will you be back on a faster one? soon(ish) or will that be a matter of days? (just curious so that I can judge if I should tweak it myself or followup in the proposal)
<tumbleweed> broder: yes, http://anonscm.debian.org/viewvc/collab-qa/
<m4n1sh> mvo, I just shifted house  today
<m4n1sh> so I hurriedly finished the proposal yesterday
<m4n1sh> mvo, not sure about when I get a faster one. Need to call the iSP
<m4n1sh> *ISP
<m4n1sh> mvo, well you are the maintainer, you can tweak it
<m4n1sh> not a problem
<mvo> m4n1sh: great, thanks, will do :)
<m4n1sh> thanks :)
<lynxman> hey everyone, which would be the best way to check for the existance of a package? My package depends on either of two packages (activemq | rabbitmq-stomp) and on the postinst I need to check the existance of either to do the proper config, I was thinking about checking for the config dir to exist but not sure if that's the best method, recommendations?
<mvo> m4n1sh: the only small tweak is to move it into a function I think
<m4n1sh> mvo, I think that is fine. Not something really big or anything that changes the behaviour of the script
<SpamapS> lynxman: the config dir would still be there if one had been removed and the other were installed
<Laney> broder: in svn.d.o/svn/collab-qa/udd
<lynxman> SpamapS: that's why :)
<mvo> m4n1sh: yeah
<SpamapS> lynxman: do the two conflict?
<lynxman> SpamapS: not necessarily, but they could
<SpamapS> lynxman: so it seems that you probably need to configure for them both separately based on the existence of their executables
<broder> lynxman: could you split the setup into two subpackages - one for each - and then have the parent package depend on package-that-configs-activemq | package-that-configs-rabbitmq-stomp?
<lynxman> broder: that could be an option, but it would break compatibility with the previous versions of the same package
<lynxman> broder: that's why I'm trying to be just smart enough to solve it out :)
<lynxman> SpamapS: checking the binaries is a good idea indeed...
<SpamapS> like,    if -x rabbitmqctl ; then ... fi ; if -x activemq ; then ... fi
<lynxman> SpamapS: would you say relative or full paths are the best way for that?
<lynxman> SpamapS: I tend to do full paths but I know is a bit frowned upon
<broder> lynxman: debian policy says use relative paths in maintainer scripts
<SpamapS> errr
<broder> lynxman: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s6.1
<lynxman> broder: ah there you go :)
<broder> (last paragraph)
<broder> i know because i noticed there was a lintian tag for it :)
<SpamapS> relative to what?
<brendand> are there instructions on building compiz somewhere?
<SpamapS> He's not calling
<SpamapS> checking for existence/executableness
<SpamapS> my -x was just an example
<SpamapS> you *must* do the path for -x
<lynxman> SpamapS: yeah, doing if -x /usr/bin/activemq or just if -x activemq
<broder> if hash foo >/dev/null 2>&1; then ...
<broder> is the standard incantation
<SpamapS> hash? I've never seen that.
<lynxman> broder: oh interesting, any examples?
<SpamapS> but that makes sense
<SpamapS> lynxman: so    if hash rabbitmqctl > /dev/null 2>&a; then
<lynxman> SpamapS: cool :)
<lynxman> SpamapS: broder: thank you very much for your answer, I'll use hash then
<smoser> $ sh -c 'hash foo'
<smoser> sh: 1: hash: foo: not found
<smoser> the *right* way to say "is this something i can run" is
<smoser> sh -c 'command -v foo >/dev/null'
<smoser> sh -c 'command -v foo >/dev/null' && echo yes || echo no
<smoser> broder, ^. hash is a bash builtin. not available in posix sh.
<broder> huh? it's totally available
<broder> evan@caron:~$ sh -c 'type hash'
<broder> hash is a shell builtin
<broder> foo on the other hand...
<cjwatson> I tend to use 'type', or 'which' in contexts where /usr is available, or on occasion a tiny shell function equivalent to 'which'
<cjwatson> you totally don't need to fork a new shell to use 'command -v', in any event
<smoser> broder, yes, you are correct. i am a dolt.
<SpamapS> smoser: hash is in dash
<cjwatson> 'type' (or 'command -v') tells you whether the command exists with varying levels of standards conformance; 'which' tells you whether it exists specifically on $PATH
<broder> smoser: no worries - it's still early for us US folks ;)
<broder> Laney: i couldn't figure out how to checkout the svn repo, but http://paste.ubuntu.com/733216/ and http://paste.ubuntu.com/733219/ should be sufficient if i understand this stuff correctly
<smoser> it appears to me that type, command -v and hash all search PATH.
<smoser> http://paste.ubuntu.com/733217/
<smoser> cjwatson, were you stating otherwise ?
<Laney> broder: right, and you need an entry in config-org.yaml
<cjwatson> they search PATH but they *also* search builtins
<smoser> ah.
<cjwatson> 'which' only searches PATH
<smoser> right.
<broder> Laney: first pastebin :)
<Laney> oh yeah
<cjwatson> (by design, and because it's an external command)
<Laney> svn> svn co svn+ssh://svn.debian.org/svn/collab-qa/udd/
<smoser> right
<broder> svn+ssh://> still don't think i have that setup
<Laney> should work without +ssh
<broder> ah, so itdoes
<cjwatson> there's a 'searchpath' function in base-passwd.postinst which I cut down from 'which', and there's osextras.find_in_path in ubiquity if you want a Python implementation, and I have a C one in man-db/lib/pathsearch.c - I've written this several times ;-)
<Laney> broder: will deploy it later
<Laney> cheers
<broder> cool, no rush from me
<broder> i'll probably end up stealing the script and running it on my lintian lab anyway so i can make the report generation a bit more configurable (e.g. ubuntu-only package report)
<Laney> which script?
<broder> the importer
<zul> cjwatson:  can you review python-passlib please?
<Laney> thought you were mirroring udd
<broder> i am. but for things like the ubuntu-only report, i'm planning to slurp the lintian.log into a database, then filter it appropriately, spit it back out, then run it through the html report generator again
<cjwatson> zul: hm, I think I'm out of time for today (or rather all my remaining time is already committed), sorry, it would be better if somebody else could do it but otherwise I can look tomorrow morning
<zul> cjwatson: ok ill bug someone else then
<SpamapS> silly question, when using sbuild, whats the appropriate way to set DEB_BUILD_OPTIONS ?
<broder> SpamapS: looks like you might be able to set $build_environment = {'DEB_BUILD_OPTIONS' => 'stuff' }; in your ~/.sbuildrc?
<SpamapS> ahh, /usr/share/doc/sbuild/examples/example.sbuildrc is quite helpful :)
<lool> pitti: Sorry for the delay, tried udev from your PPA now and it failed to boot
<pitti> lool: oh, what happens?
<pitti> lool: stuck in initramfs?
<chrisccoulson> slangasek, i still can't reproduce the addon problem you had yesterday. is it easily reproducible for you (ie, if you uninstall firefox-globalmenu, restart firefox, reinstall firefox-globalmenu and restart again, do you get the extra tab asking you to enable the addon?)
<slangasek> cjwatson: mmk, Debian publisher has had time to catch up, I'm syncing all the X packages in the libxmu stack now
<slangasek> chrisccoulson: nothing about having to restart firefox is easy, but I'll check :)
<chrisccoulson> slangasek, thanks
<cjwatson> slangasek: great
<SpamapS> slangasek: https://launchpadlibrarian.net/84784123/buildlog_ubuntu-precise-i386.mysql-5.5_5.5.17-1ubuntu1~ppa0_FAILEDTOBUILD.txt.gz .. segfault on the buildds :-/
<slangasek> hmm!
<slangasek> well, it's i386
<slangasek> who uses that anyway :)
<SpamapS> only the weak
<lool> pitti: Yes; uploading pictures of the crash
<lool> sorry for the delay, had to solve another ubuntu install not starting weirdly -- unrelated
<SpamapS> slangasek: no such failure on amd64 .. :-P
 * SpamapS builds an i386 precise chroot.. :-P
<lool> pitti: http://ubuntuone.com/5UdVl0S9Nnf7qNqI6TfhH6 http://ubuntuone.com/01ckC0NMdYZb8Y423lMlmf
<mterry> slangasek, your upload of popt that now depends on gettext:any seems to confuse the buildd: https://launchpadlibrarian.net/84756245/buildlog_ubuntu-precise-i386.popt_1.16-1ubuntu1_FAILEDTOBUILD.txt.gz
<mterry> slangasek, do you know what the fix for that is?
<lool> pitti: apparently, initramfs gives up waiting for root device before it appears, not sure what udev fails to do there, perhaps it thinks all events have been processed when they haven't; should I set some debug flags in the initramfs to check it out?
<slangasek> mterry: the fix is that the new sbuild will be rolled out tomorrow morning UK time
<mterry> slangasek, beautiful  :)
<cjwatson> jelmer: bzr-git failed to build; I don't know if LP has fixed the bug where the syncer doesn't get mailed about such things
<Laney> given that they went for recording synced packages separately, I think probably not
<jelmer> cjwatson: I didn't get any email so I guess not. Thanks for the ping.
<slangasek> SpamapS: so how did mysql 5.5 wind up with cmake anyway?  It seems to have been pleasantly autoconfy in 5.1
<SpamapS> slangasek: upstream wanted to use the same build tool on windows and *nix
<SpamapS> slangasek: basically all the smart people in the build team left when Sun bought MySQL AB .. ;)
<SpamapS> s/smart/autoconfy people/
 * SpamapS should really be nicer, they've been quite pleasant when we've reported bugs in the new cmake build. ;)
<SpamapS> [100%] Building CXX object sql/CMakeFiles/sql.dir/sys_vars.cc.o
<SpamapS> and cmake at least has a % done counter.. :)
<slangasek> heh
<slangasek> cjwatson: do you remember which packages were mangling the console from underneath X most recently?  some Russian support package?
<cjwatson> console-cyrillic is the one you're thinking of I think
<slangasek> right, thanks
<cjwatson> I hit it with a hammer.  bug 597673
<ubottu> Launchpad bug 597673 in console-cyrillic (Ubuntu Oneiric) "console-cyrillic changes settings on consoles it doesn't own, causing crashes with plymouth + X" [Critical,Fix released] https://launchpad.net/bugs/597673
<slangasek> :)
<slangasek> bug #887445 has a user reporting the same behavior... no console-cyrillic installed. looking through his package list now
<ubottu> Launchpad bug 887445 in xserver-xorg-video-ati (Ubuntu) "I can not login" [Undecided,Incomplete] https://launchpad.net/bugs/887445
<highvoltage> Riddell: hi, have Kubuntu decided yet about its 12.04 LTS status? and whether it will be supported for 3 or 5 years?
<YokoZar> What do I do after a kernel panic in a stable release if I'm a good citizen?
 * YokoZar hasn't had one till now in 7 years of Ubuntu...
<SpamapS> [1:1:157311113007:ERROR:nacl_fork_delegate_linux.cc(78)] Bad NaCl helper startup ack (0 bytes)
<SpamapS> I keep seeing these...
<SpamapS> wtf?
<LaserJock> lol, I automatically read that as "Bad salt helper".
<SpamapS> "Your table salt has failed to fork" does conjure up an interesting image
<LaserJock> I'm teaching general chemistry this semester, I guess it's starting to soak in :-)
<micahg> well, chromium has NaCL...
<micahg> SpamapS: ^^which version are you running?
<SpamapS> ii  google-chrome-stable    15.0.874.106-r107270    The web browser from Google
<SpamapS> so just chrome whining about something
<micahg> SpamapS: I can't help you if you're running chrome
<micahg> we didn't build chromium with NaCL for M15, toolchain issue
<SpamapS> will ignore it for now
<Laney> who maintains the ubuntu pastebin?
<Laney> having to log in for plaintext is really annoying
<micahg> laney: I thought it's ubuntu-website, but I could be wrong
<infinity> Laney: Canonical IS.
<Laney> do they have anything other than RT?
<infinity> Laney: And they have the login-for-plaintext thing set up that way intentionally, so you might have to present an argument.
<infinity> Laney: (It's to prevent people using pastebin as a file trading service, as I recall)
<Laney> I'm sure; it must have taken some effort.
<Laney> It could perhaps generate private links which bypass the logging in requirement
<infinity> Laney: How would that help?  Then people storing files there would just pass people said private links?
<Laney> whereas now they just have to log in?
<tumbleweed> infinity: and it also means you can't curl $url | patch -p1
<tumbleweed> which is something one wants to do rathe roften
<infinity> Laney: Sure, but requiring a launchpad account is a high enough barrier, I suspect.  Either way, wasn't my call.  Bug the IS folks. ;)
<infinity> (I'd like plain-text-without-login to work too, I'm just pointing out the arguments I've seen against it)
<infinity> ...
<infinity> Really?  We still have packages that build-dep on dbs?
<infinity> REALLY?!
<LaserJock> wow
<infinity> And not, like, crazy leaf packages.
<infinity> newt.
<infinity> Pretty core.
<infinity> Wow.
<infinity> I'm shocked.
<LaserJock> huh, interesting
 * infinity wonders if that's a sign that newt needs to be hijacked in Debian.
<micahg> slangasek: I reproduced your firefox upgrade issue, so you're not alone, but chrisccoulson still can't...he's still investigating though
 * infinity promptly forgets about the previous statement.
<chrisccoulson> micahg, how reproducible is it for you?
<slangasek> micahg: ok
<micahg> chrisccoulson: new profile works, let me try the other one that existed
<LaserJock> infinity: is there any mechanism in Debian that would tell a maintainer "look, it'd be swell if you could update your build system"?
<micahg> chrisccoulson: I got it in the other profile that existed before upgrade as well
<infinity> LaserJock: A bug report? :P
<LaserJock> I would think unless it became like a security issue it's pretty much up to the maintainer
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576054
<broder> LaserJock: formal deprecation as a release goal :)
<ubottu> Debian bug 576054 in src:newt "newt: Please stop build-depending on dbs" [Wishlist,Open]
<cjwatson> ^- like that one
<infinity> Usertags: drop-dbs
<infinity> Hah.
<cjwatson> Usertags: drop-kick-dbs
<infinity> The dbs maintainer just needs to do a no-code-change upload that renames it back to Doogie Build System.
<infinity> That should prompt some action.
<lynxman> jhunt: ping
<jhunt> lynxman: hi
<lynxman> jhunt: my man :)
<lynxman> jhunt: I see that "pid file" is no longer supported in upstart, what should I try to manually specify the pid file for a process?
<lynxman> jhunt: since it's getting it wrong (logging pid from parent that dies after fork)
<jhunt> lynxman: funny you should say that - I'm currently working on a cookbook update that will cover all that in truly painful detail.
<lynxman> jhunt: can you give me a painless preview? :)
<SpamapS> lynxman: if the pid it thinks is the right one is dying too early, then you actually *do* have 2 forks, and you need expect daemon.
<lynxman> jhunt: I can go the never daemon route and just respawn on demand as well, just trying to avoid that one
<Laney> broder: it iz dun
<SpamapS> lynxman: and if the process ever re-forks (like sshd does on SIGHUP) then you can't use expect fork / daemon and have to use foreground mode.
<lynxman> SpamapS: coolio :)
<broder> Laney: cool. i'll check it out next time i pick up a dump
<jhunt> lynxman: SpamapS types faster than me :)
<lynxman> jhunt: heh :) he's on his morning coffee I reckon
<Laney> sweet
<jhunt> lynxman: coffee levels dangerously low over here, in fact... pop.
<Laney> http://ubuntu-dev.alioth.debian.org/junk/lintian.txt
<rando_uu> beginners question: I want to build package_b on launchpad but it requires package_a, which is in my ppa, to be installed in the chroot environment, can I just add package_a to build dependes?
<cjwatson> yes
<cjwatson> that's exactly what build-depends is for
<rando_uu> thx I'll give it a shot ;)
<binarymutant> is Ubuntu still using revu?
<maco> There's talk of getting rid of it
<maco> It's frequently ignored and getting packages into debian first is preferable
<binarymutant> ah, thanks for the info
<Randolph> hi all
<Randolph> I wanted to know if it is normal that when there are some updates for Ubuntu 11.10, the user does not need to supply the root password ?
<micahg> Randolph: yes, https://wiki.ubuntu.com/SecurityTeam/FAQ#Update_Manager_doesn.27t_prompt_for_security_updates
<micahg> Randolph: and it would be the user's password not root in any event
<Randolph> You mean it is normal ?
<Randolph> I think it is not a good idea in term of security
<jdstrand> Randolph: sure it is. we make it easier for people to install security updates. you can't install new software without a password
<Randolph> It could be a break into security, maybe with possibility of privilege escalation
<micahg> Randolph: have you read the link I provided?
<jdstrand> Randolph: I suggest reading the FAQ if you haven't already. the behavior is configurable via PolicyKit if you prefer to be prompted
<Randolph> I read it quickly I must admit
<maco> That's pretty cool
<Randolph> that sound right
<maco> I remember using a local root escalation exploit to gwu root so I could install security updates on one of the machines at my school since the admins weren't really doing their jobs
<maco> s/gwu/get/
<jdstrand> heheh
<jdstrand> nice
<Randolph> s/gwu/get/ what is this ?
<micahg> ubottu isn't as talented as kubotu in explaining such things
<ubottu> micahg: I am only a bot, please don't think I'm intelligent :)
<micahg> exactly
<broder> Randolph: s/gwu/get/ refers to a syntax in scripting languages for substitution
<broder> so maco was indicating that she typo'd, and we should mentally replace "gwu" with "get" when we read her message
<Randolph> broder, oki s for substitute
<maco> Yes
<Randolph> broder, I do not link with it
<Randolph> like in VI or sed
<maco> Yes
<micahg> or perl regexps
<maco> Vi is where I got the regex habit
<broder> hmm.../etc/console-setup/cached.kmap.gz on my machine has keycode 58 = CtrlL_Lock (keycode 58 is caps lock). is this one of those weird bits of keymap arcana, or is that actually wrong?
<mwhudson> SpamapS: ubuntu support via the company quotes page!!
<broder> slangasek, ogra: have you guys thought at all about dealing with fscking the root partition in the no-initrd world? just came to mind as something i don't think we talked about
<SpamapS> mwhudson: indeed, really, thanks.. I've already uploaded it to oneiric-proposed.. that was a REALLY annoying problem.
<mwhudson> SpamapS: no kidding
<slangasek> broder: we always do that from the root fs anyway
<slangasek> we mount ro, and let mountall fire off the fsck
<broder> oh right, because we haven't remounted rw yet
<broder> so yes, you've thought about it more than me :)
<mwhudson> SpamapS: would a comment from me somewhere that the version from precise fixed the problem help the SRU process along?
<mwhudson> i guess i've already said that on the report
<SpamapS> mwhudson: its in the bug already, yeah.
<SpamapS> mwhudson: would help if you downgraded to the oneiric version when it hits oneiric-proposed, since that would count as verification. :)
<mwhudson> SpamapS: ah ok
<mwhudson> SpamapS: what is the version you uploaded?
<SpamapS> mwhudson: 6.3.3-somethingubuntusomething ;)
<mwhudson> SpamapS: haha ok
<SpamapS> 6.3.3-3ubuntu1
<SpamapS> has not been SRU reviewed quite yet
<SpamapS> slangasek: looks like the build problem is not unique to 5.5 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627208
<ubottu> Debian bug 627208 in src:mysql-5.1 "mysql-5.1: FTBFS with segmentation fault (signal 11) on i386" [Grave,Fixed]
<slangasek> "fixed"?
<SpamapS> Yeah, apparently its a gcc 4.6 issue
<SpamapS> so the fix was to force 4.5
<SpamapS> http://bugs.mysql.com/bug.php?id=61509
<SpamapS> I didn't merge that bit in from the 5.1 packaging...
<SpamapS> trying now.
<slangasek> chrisccoulson: so after doing that restart dance, I get *no* tab asking about re-enabling; this time it gets reenabled automatically
<chrisccoulson> slangasek, yeah, i think we understand the bug now
<chrisccoulson> thanks
<slangasek> ok
<chrisccoulson> i need to fix it quickly because it blocks the security update for oneiric :)
<slangasek> right :)
<slangasek> SpamapS: so I played around and got myself a multiarching patch for mysql-5.1; how soon will that be obsolete? :)
<SpamapS> slangasek: hopefully by Monday
<slangasek> hmm
<slangasek> I'll upload anyway then :)
<slangasek> because I want cross-buildable qt4-x11 *now* :)
<SpamapS> slangasek: yeah inevitably there will be barriers to this transition.. I haven't even started the rebuild tests of all reverse deps.. :-P
 * SpamapS ponders starting up a c1.medium to at least do all the amd64 rebuilds while he fixes i386
<SpamapS> so many rebuidls, so few cores... ;)
<slangasek> ooh, I bet the gcc 4.5 handling in mysql-5.1 isn't cross-build-safe
<slangasek> pitti: libncurses5-dev has inconsistent symlinking of changelog.Debian.gz across architectures... on armel it's a symlink, on amd64 it's a file.  Should pkgbinarymangler's behavior be consistent here?
<slangasek> cjwatson: what do you recommend for keeping track of generic autoconf checks that should be added to dpkg-cross?  File a bug on dpkg-cross for each?
<slangasek> tjaalton: has libx11 102_double_arrows_Compose.patch been submitted to Debian? seems to be the only delta...
<slangasek> tjaalton: also, the patch doesn't seem to be in effect in my own compose map :)
<slangasek> (and furthermore, <= collides with the compose map for â¤)
<slangasek> tremolux, barry: what other information would be useful to provide in bug #888297 (before I bypass aptdaemon and finish the upgrade with apt-get)?
<ubottu> Launchpad bug 888297 in aptdaemon (Ubuntu Precise) "aptdaemon gets confused and refuses to upgrade multiarch packages in precise" [High,New] https://launchpad.net/bugs/888297
<tremolux> slangasek: hmm, so does sudo apt-get dist-upgrade -o Debug::pkgProblemResolver=true show anything interesting?
<slangasek> tremolux: nope - a brief discussion of the packages I have held back (mythtv stuff), otherwise nothing
<slangasek> tremolux: note that every single one of the complaining lines from aptdaemon is something that shouldn't be an issue, either
<tremolux> slangasek: yeah, sounds like apt itself is happy
<tremolux> slangasek: I don't know of anything else offhand you might add, seems to me like the info there is good
<tjaalton> slangasek: right, it's a bogus patch that should be dropped if it's still there
<slangasek> tremolux: ok, moving along with dist-upgrade then
<slangasek> tremolux: thanks
<tremolux> slangasek: you bet
<slangasek> tjaalton: right, will drop it and sync
<tjaalton> slangasek: yeah, thanks
<barry> slangasek: i always just `apt-get install -f` before i follow up with `apt-get upgrade`.  /me commmented on the bug
<slangasek> barry: yeah... apt-get itself works just fine here, it's an aptdaemon problem
<barry> slangasek: smart is similarly busted, hence the continual landscape failures
<cjwatson> broder: CtrlL_Lock> there's a comment in the console-setup source about that - it's a choice between two bugs, one major and one minor
<cjwatson> slangasek: dpkg-cross> yeah
<jdstrand> @pilot off
<udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<jdstrand> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | 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:
<slangasek> cjwatson: right-o
<cjwatson> broder: it's a choice between the caps lock key not working, or caps lock not actually doing anything for non-ASCII letters (as I remember)
<cjwatson> er, the caps lock *light* not working I mean
<cjwatson> I consider the light bit minor
<cjwatson> (annoying, granted)
<angelo-c> Hi guys, I was here yesterday for LP: #881695
<angelo-c> Ca anyone help me?
<angelo-c> patch pilots out there?
<Fusionite> Hey all
<maco> Angelo-c say bug instead of lp and the bit will provide a handy link and summary
<maco> *bot
<angelo-c> https://bugs.launchpad.net/ubuntu/+source/xoscope/+bug/881695
<ubottu> Launchpad bug 881695 in xoscope (Ubuntu) "Xoscope doesn't work on soundcard (No valid data sources found... exiting)" [Undecided,Fix released]
<angelo-c> I'm proposing a patch to be SRU:ed
<maco> Use nominate for series button to add a task for the ubuntu version you want to sru (so your patch has something to close)
<micahg> maco: only bug control can nominate
<broder> cjwatson: yes, you're absolutely correct. it was fairly well documented once i figured out where to look, but oh god are my eyes bleeding :)
<maco> Since when?
<micahg> almost a year I think
<maco> I thought anyone could but only bug control could approve
<micahg> no, only uploaders, release team, drivers can approve
<maco> *grumble*
<angelo-c> this page https://answers.launchpad.net/launchpad/+question/140509 says that only bug supervisor can make something
<micahg> angelo-c: right, that's what I was saying
<angelo-c> this page is nominated by this official one https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<maco> Security through pain-in-the-butt-ery
<angelo-c> any bug supervisor here?
<micahg> maco: not security, lack of utility, people were clicking for their pet fixes, so the nominations became useless
<slangasek> maco: it's not security, it's "can we please have a queue that's not completely useless as a source of data kthx"
<slangasek> when everyone could nominate, everyone did
<cjwatson> broder: it's not an entirely fun problem
<maco> Any of the three people talking now are able to
<maco> Four
<maco> I have no idea what that software is though
<slangasek> so the nominations were useless and just wasted the time of those clicking the button
<angelo-c> wow, fantastic! This is my first bug, so be clement whit me!
<broder> cjwatson: i'm currently looking at https://lkml.org/lkml/2010/3/10/188 to see whether it can be revived, which i think might largely reduce the outstanding issues to a that-makes-me-want-to-cry-but-it-will-at-least-work level
<slangasek> angelo-c: which releases did you care about seeing this fixed in?
<slangasek> (i.e., which ones will you actually test the fix for? :)
<cjwatson> broder: *nod*
<cjwatson> Samuel has contributed to the userspace side of things too so knows what he's doing
<maco> *snerk*
<slangasek> angelo-c: IIRC from yesterday, your main concern was for oneiric... so I've opened an oneiric task there
<angelo-c> tha branch was accepted yestarday for precise, i think should go also on oneiric-proposed
<angelo-c> slangasek: yep, you are right!
<angelo-c> I complied the bug description to include necessary sections, am I right?
<slangasek> angelo-c: ok.  The bug state is as it should be for this.  Can you take care of the next steps from https://wiki.ubuntu.com/StableReleaseUpdates#Procedure ? (test case, debdiff prepared with appropriate version number and target in the changelog)
<slangasek> yes, please :)
<infinity> angelo-c: Have you tested the precise binaries from yesterday's upload to make sure they do what they should?
<slangasek> cjwatson: ok, libx11 is the last blocker for libxmu; it's stuck in Debian new though, and I'm afraid of trying to get syncpackage to actually DTRT for a fakesync :)
<angelo-c> slangasek: I think i wrote everything on bug description
<maco> I suspect it's the debdiff he's asking about
<cjwatson> slangasek: fakesyncs are the only thing syncpackage used to be good for, before the recent API enhancements :-)
<infinity> angelo-c: And please, base the debdiff off the source I uploaded to precise, rather than your branch. ;)
<infinity> angelo-c: (I converted your changes to a patch in debian/patch)
<angelo-c> infinity: glad to see you! nop, but I think that the sources are identical because they had the same version number before the patch
<infinity> es
<infinity> Well, yes.  Just taking my sources, and changing the version number in the changelog (and the target) would work fine. ;)
<slangasek> angelo-c: ah, I see the information in the comments, ok.  Normally we put this information in the bug description (using the pencil icon to edit), because comments don't stay where you can find them as a bug grows
<cjwatson> slangasek: it looks it will need to be a merge though?
<slangasek> cjwatson: according to tjaalton we can drop that last patch
<cjwatson> ah
<cjwatson> so why would it need to be a fakesync?
<maco> Infinity: I'm going to have to actually install precise and oneiric if I want to start doing srus for o, huh? *lazy semi-dev*
<cjwatson> do you just mean to accelerate past Debian NEW?
<slangasek> cjwatson: perhaps I'm meaning something different by the word.  "sync from NEW"
<slangasek> yes
<angelo-c> slangasek: oh, my fault
<cjwatson> ah.  I'm sure you know enough bribable ftpmasters. :-)
<infinity> maco: Not sure about installing precise to do oneiric SRUs.. :P
<cjwatson> though it's so fast these days I don't usually bother
<slangasek> heh
 * slangasek impatient
<maco> Infinity: there was an and in there. I'm on maverick and natty
<cjwatson> SRUs> chroots work for a lot of things ...
<cjwatson> (spot the non-desktop developer)
 * slangasek grins
<angelo-c> slangasek: ok, I removing the comment and editing the bug description
<slangasek> angelo-c: thanks :)
<infinity> cjwatson: *grin*
<maco> I did all of my oneiric stuff in a vm since ubiquity was pretty much all I did
 * cjwatson ponders purging his hardy chroot
<maco> Start the install, swear, poke python, start the installer again...
<infinity> cjwatson: We still support it.
<cjwatson> yeah, but like I ever actually touch it
<infinity> cjwatson: I did a hardy SRU of apt only a month ago!
<cjwatson> overachiever
<angelo-c> slangasek: ok, done
<maco> Haha
<DktrKranz> slangasek: do you need libx11 out of NEW?
<infinity> cjwatson: Pot, kettle?
<cjwatson> infinity: shh
<maco> I'm going to go with hoping colin doesn't screw around too much with a grub that seems to work!
<cjwatson> well, since you ask, there've been a lot of nice fixes upstream lately ;-)
<maco> Hardy boots, now lets never touch it's grub again!
<cjwatson> I suspect this will be a cherry-pick cycle though
<infinity> maco: The upshot is that if he screws it up, it's even MORE his job to fix it than ever before.
<angelo-c> infinity: I have to test the patch mandatory?
<angelo-c> infinity: I tested the patch extensively for oneiric!
<infinity> angelo-c: In the case where it's literally the same source package, and I based it on your original patch, I think we can let the pre-upload testing slide.
<infinity> angelo-c: Obviously, post-upload, it'll need to be tested from -proposed.
<angelo-c> infinity: I think that
<slangasek> DktrKranz: "need" is overstating it slightly... "getting twitchy waiting for" :)
<angelo-c> infinity: testing from -proposed implies only to add the proper repository to sources.list, right?
<infinity> angelo-c: Or, in the case of a single fixed package, just downloading the one deb and installing it manually. :P
<infinity> angelo-c: But the point is testing the built binaries, that's all.
<slangasek> -b$R{53<B2><87>Qv<B7><AF><CC>^? <B0>-^T<D6><8D><F9>M<94>Q9I<CD><87>.<FF>^KZl<8D><F6><80>5^@^@
<slangasek> +b$R{53<B2><87>Qv<B7><AF><CC>^? <B0>-^T<D6><8D><F9>M<94>Q9I<CD><F7>P<FF>^WZl<8D><F6><80>5^@^@
<infinity> slangasek: I agree.
 * slangasek calmly stabs gzip
<angelo-c> infinity: ok, it's really in my intrest!
<infinity> slangasek: Oh, the manpage bug?
<slangasek> infinity: yep, finding more hits
<slangasek> libtasn1-3 NEWS.gz
<infinity> slangasek: Outside of PAM finally?
<slangasek> oh yes
<infinity> slangasek: That's oddly comforting.
<slangasek> it's not at all isolated to PAM
<slangasek> there's a Debian bug filed about it now as well
<slangasek> jwilk ran an archive scan to find inconsistencies in packages marked M-A: same.. turned up a few
<slangasek> Debian bug #647522
<ubottu> Debian bug 647522 in gzip "gzip -9n is not deterministic" [Normal,Open] http://bugs.debian.org/647522
<infinity> slangasek: That's... Two characters different?
<maco> Gzip is fubar?
<slangasek> infinity: three
<DktrKranz> slangasek: processed, it will be accepted in ~12 minutes
<slangasek> DktrKranz: thanks :)
<infinity> slangasek: How is that even the same stream when unzipped?  Still makes my head hurt.
<DktrKranz> so, does anybody say I'm bribable? ;)
<infinity> slangasek: I liked Colin's dictionary theory, but that would lead to drastically different streams.
<slangasek> infinity: dunno yet, haven't had a chance to dig
<infinity> (Or, more than 3 chars, anyway)
<slangasek> 7msg DktrKranz when will you collect this beer?
<SpamapS> slangasek: so, for multiarch, the -dev packages can have executables, right?
<broder> oh noes! slangasek has accidentally revealed the secret to his success at manipulating ftpmasters! :-P
<SpamapS> slangasek: just not the runtime libs?
<infinity> slangasek: Are we supposed to believe you don't use a US keyboard?
<slangasek> SpamapS: if you want co-installable -dev packages, they generally need to be free of executables; but this is a softer goal than the goal of coinstallable runtime libs
<angelo-c> infinity: how do you converted my changes to a patch in debian/patch?
<slangasek> infinity: I don't use the US keymap!
<SpamapS> slangasek: libmysqlclient-dev has /usr/bin/mysql_config ..
<infinity> slangasek: You use... A... German one?  I can't think of who else has the / there.
<SpamapS> oh wait
<SpamapS> thats a script
<PasNox> Evening
<slangasek> SpamapS: scripts are sometimes fine... and sometimes they foolishly embed library paths, so *look* fine when you start out and become less fine after you've built for multiarch :)(
<infinity> angelo-c: In the case of that package, it was just pruning 'bzr diff' into a sane patch, dumping it in debian/patches, and adding it to debian/patches/series.
<PasNox> I'm trying to create a package for my lib for oneiric, but the deb generation fails after a success build with error : http://paste.kde.org/144506
<PasNox> do u have any hint on why ?
<slangasek> infinity: yeah, that's a German typo :)
<SpamapS> bah.. that will be updated based on the LIB_PREFIX ..
<slangasek> PasNox: looks like your packaging has failed to install libfresh.so.1.0 into the binary packages
<PasNox> the file exists but not in the same path that the fresh.so python binding file
<slangasek> SpamapS: yep :)  But I wouldn't worry about that for now
<infinity> slangasek: I don't actually consider this a good thing that I know the German layout well enough to know that.  I wonder what useful thing I've forgotten as a result.
<SpamapS> slangasek: indeed, libmysqlclient18 is the one we need fixed
<slangasek> SpamapS: it's not like X libs, where your headers have circular dependencies on the foreign-arch versions :P
<sebner> slangasek: please put 500â¬ into an envelope and send it to DktrKranz drive 666, Italy
<PasNox> slangasek: the file exists : http://wstaw.org/m/2011/11/10/plasma-desktoppU1919.jpg
<PasNox> but i want to create 4 package, 2 -dev package and 2 libs package
<angelo-c> infinity: really thanks, another army in my bag!
<slangasek> PasNox: but what does 'find debian -name libfresh.so.1.0' return?
<PasNox> slangasek: here is my control file that i build with cowbuilder : http://paste.kde.org/144512
<PasNox> slangasek: the fresh lib is not installed system wide
<slangasek> PasNox: if debhelper is told to install the library into one of the binary packages, dh_shlibdeps will automatically know how to find it.
<slangasek> I understand that
<slangasek> but it needs to be installed into the target directory for one of the binary packages you're building
<slangasek> the error message indicates that it isn't
<PasNox> i'm not familiar with creating package, it's my first try :D
<angelo-c> inifinity: so what happens now to the package in oneiric proposed?
<PasNox> slangasek: in the image i give the url some lines ago we can see fresh.so ( python lib binding ) and libfresh.so* exists but not in same folders )
<PasNox> i then use *.install files to copy files in correct package folder
<PasNox> currently i make install in the tmp folder, and move fiels using *.install rules
<slangasek> PasNox: please show me the output of 'find debian -name libfresh.so.1.0' run from the package root
<PasNox> yes, sorry
<PasNox> slangasek: from which path i should execute this ?
<slangasek> PasNox: from the top level of the directory where you built this and got the error message
<slangasek> the directory above the one named 'debian' that contains your packaging
<PasNox> i created a script for packaging the lib and then it's cowbuilder building the lib in a chrooted env so i have not the build folder
<slangasek> but the command needs to be run after a failed build
<slangasek> right
<slangasek> so you need to tell cowbuilder to not throw away the build directory on failure
<PasNox> ah ok, so let restart the build :)
<slangasek> (there's a pbuilder option for this, but I don't use pbuilder so can't tell you what it is)
<PasNox> ah, and how i can do that ?
<PasNox> oki
<slangasek> I guess there are others here who use pbuilder and can tell you
<PasNox> i will add the commande before executeing the dh_install
<PasNox> slangasek:
<PasNox> find /tmp/buildd/fresh-1.1.0/debian -name libfresh.so.1.0
<PasNox> /tmp/buildd/fresh-1.1.0/debian/tmp/usr/lib/x86_64-linux-gnu/libfresh.so.1.0
<PasNox> as expected in the correct folder
<slangasek> PasNox: that's not the correct folder :)
<PasNox> xD
<SpamapS> slangasek: first attemptted multiarch build starting...
<slangasek> the correct folder would be /tmp/buildd/fresh-1.1.0/debian/libfresh/usr/lib/x86_64-linux-gnu/libfresh.so.1.0
 * SpamapS will not attempt proper spelling tho
<slangasek> PasNox: if find only shows it in the debian/tmp directory, this means it's missing from your libfresh.install file
<slangasek> (also, 'libfresh' is the wrong name for a runtime library package; it should be named 'libfresh1')
<PasNox> slangasek: ok, i will rename it once the package build fine ;)
<bjsnider> PasNox, if you add a hook script it will preserve the build dir in pbuilder if the build fails. there's an example on the ubuntu wiki page for pbuilder
<PasNox> slangasek: btw ias i said, as the make install will produce 4 package, i make install in tmp, and then use *.install fiels to mvoe files to correct folder
<slangasek> PasNox: once the packaging for libfresh (or libfresh1) is correct, dh_shlibdeps will see it and generate the correct autodependency
<PasNox> maybe this install file is run before the needed one ?
<slangasek> dh_install needs to run before dh_shlibdeps
<PasNox> let me check
<slangasek> if you're using any of the common packaging tools, this will be done for you
 * cjwatson waves a flag with "dh $@" written on it
<slangasek> ooh, are you selling those at cafepress
<PasNox> slangasek: http://paste.kde.org/144518
<cjwatson> now there's an idea
<PasNox> i call the dh_install in the 'install' rule ( so just after 'make install XXX'
<PasNox> it's not the good place ?
<slangasek> PasNox: oh, you inserted the find command directly in debian/rules?  That's not what I expected :)
<cjwatson> DH_VERBOSE=1 in the environment is usually a good way to track down this kind of bug
<slangasek> PasNox: what does debian/libfresh.install contain?
<PasNox> slangasek: yes not optimal but it was working :)
<PasNox> i will remove it after
<PasNox> slangasek: libfresh.install: http://paste.kde.org/144524
<PasNox> cjwatson: yeah i will activate it if i can't resolve easily this problem :)
<slangasek> PasNox: ok... that .install file looks correct.  I think you want to double check, by getting the output of that find command *after* dh_install runs
<PasNox> slangasek: http://paste.kde.org/144530 looks it's called before :/
<slangasek> yes
<slangasek> so move the 'find' command down a line :)
<angelo-c> i saw tha bug was triaged for oneiric, so what's next?
 * cjwatson refers to jml's "hack like an evil overlord" talk (you can google it): "If I have an unstoppable superweapon, I will use it as early and often as possible"
<cjwatson> don't hold back your debugging tools that give you extensive traces of what's going on until you're already confused
<infinity> angelo-c: Well, normally, next would be you submitting a debdiff for the proposed upload.  But since it's literally identical to the one I did yesterday (modulo version number), and you'd need it sponsored anyway, I'll spare you that hassle, and just do it in a bit.
<slangasek> oh, oops
<slangasek> Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file.
<slangasek> PasNox: ^^ you need to call dh_makeshlibs
<slangasek> by which I mean, you should replace this packaging with dh(1)
<slangasek> because sequencing debhelper commands by hand is a waste of your valuable time :)
<infinity> cjwatson: And this is why every command on my system is aliased to "strace $@"
 * slangasek lols
<angelo-c> infinity: thank you!
<PasNox> slangasek: hm not sure i got u :/
<slangasek> PasNox: you have a difficult to spot error in your debian/rules, which is that dh_makeshlibs must be called before dh_shlibdeps if you are building a shared library package.
<PasNox> ok so i have to put this command before the seconds, let me check
<slangasek> PasNox: this "difficult to spot error" would not exist if you were using dh(1) for your packaging, which is my current recommendation for all packages
<cjwatson> PasNox: the point is that there exists a program which does all the commands in the right order for you
<PasNox> hm ??
<PasNox> i use dh_XXX tools it's not what to use ?
<cjwatson> #! /usr/bin/make -f
<cjwatson> %:
<cjwatson>         dh $@
<cjwatson> (starting point)
<PasNox> slangasek: here are the result for before / after the dh_install call
<PasNox> /tmp/buildd/fresh-1.1.0/debian/libfresh/usr/lib/x86_64-linux-gnu/libfresh.so.1.0
<PasNox> /tmp/buildd/fresh-1.1.0/debian/tmp/usr/lib/x86_64-linux-gnu/libfresh.so.1.0
<cjwatson> it understands qmake already so there's a fairly decent chance it will just work as is
 * SpamapS <heart> dh7+
<cjwatson> /usr/share/doc/debhelper/examples/rules.tiny, and 'man dh' for help on customising it if it does turn out that the defaults aren't quite right
<cjwatson> this is one layer above the dh_* tools you are already using
<slangasek> PasNox: yep.  add a call to dh_makeshlibs immediately before the call to dh_shlibdeps
<slangasek> PasNox: then, once you've confirmed that this fixes your problem, replace your debian/rules with the stuff cjwatson is pointing to :)
<PasNox> slangasek: ok, let try, thank u
<broder> slangasek: you should file a bug against dh-make - i think it still spits out old-style dh_ rules files :)
<slangasek> broder: I don't think that's the default anymore, is it?
<slangasek> broder: dh_make(8) says it is not
<broder> slangasek: ooh! it changed since i last looked. awesome
<PasNox> btw i create the template using 'dh_make -c XXX' and it's what the ubuntu wiki told me to do :/
<PasNox> i was using this how to: https://wiki.ubuntu.com/PackagingGuide/QtApplication
<PasNox> so u say they are outdated ?
<slangasek> PasNox: I don't think the documentation is outdated, that's still a reasonable way to create the template
<slangasek> PasNox: what version of Ubuntu did you run this on?
<SpamapS> dh_make spits out shiny new tiny rules files
<PasNox> slangasek: kubuntu oneiric 64bits
<SpamapS> and has for quite some time
<slangasek> PasNox: ok.  Then there is a bug in dh_make, unfortunately
<PasNox> xD ok
<cjwatson> that's odd, I tested that recently
<slangasek> cjwatson: maybe specific to some multipackage option chosen interactively?
<PasNox> this was the command i used:
<PasNox> dh_make -c "lgpl3" -f "$START_PWD/$FRESH_FILE_SRC" --createorig -l
<cjwatson> perhaps; I just tested it with single-package and it gave me dh7
<slangasek> PasNox: can you point me to the original upstream source for fresh, so I can test here?
<PasNox> then i added new *.install *.dirs and package rule in the control files to create 4 package instead of 2
<PasNox> shadeslayer:
<cjwatson> same with -l, which I agree might have influenced this
<PasNox> https://github.com/pasnox/fresh/tree/master/debian
<PasNox> this is my current files for create / build the packages
<PasNox> and i use the master working copy to be packaged
<cjwatson> PasNox: can I have the output of 'dpkg-query -W dh-make'?  that debian/rules is not consistent with the version I'm looking at
<PasNox> from where i should run that ?
<cjwatson> a terminal, anywhere, doesn't matter
<PasNox> cjwatson: dh-make 0.59
<cjwatson> huh
<cjwatson> well, then I don't understand this; the comment "This version is for packages that are architecture dependent" near the top of the file looks like it's from a template, but it's not in any of the current dh_make templates
<PasNox> hm
<PasNox> yeahs
<PasNox> the
<cjwatson> incidentally, I have to very strongly recommend against the practice in debian_fresh_packaging.sh of putting dh_make in a script
<PasNox> dh_shXXX call shadeslayer say to add
<PasNox> fix my problem
<PasNox> :)
<PasNox> the deb are built and they content what i wanted them to contains
<cjwatson> it's something you run once at the very start, not something you should be putting in a script you run to update your package to new versions
<PasNox> cjwatson: yes it's why it's in the function i no longer call
<PasNox> but i keep it becasue it can help me later for create other package
<PasNox> i'm so noob / new at creating package :)
<slangasek> yeah, I can't reproduce this dh_make behavior
<cjwatson> so shadeslayer advised you to replace the debian/rules template created by dh_make with this version?  in that case I think shadeslayer should take the blame for having to support the result :-)
<slangasek> oh
<PasNox> i do not understand xD
<slangasek> cjwatson: I think that's tab-complete-error and he's saying that dh_makeshlibs fixed his error?
<PasNox> i did not repalce the template rules files
<PasNox> i jsut added what it seem to be a missing command
<cjwatson> then none of us understand how that debian/rules got there in its current state
<PasNox> ah
<PasNox> xD
<PasNox> what i'm sure is that it comes from a dh_make -c XXX call
<cjwatson> you weren't running it in a chroot or something?
<PasNox> no
<SpamapS> slangasek: looks like cmake actually makes it pretty simple
<PasNox> i commited in master my last rules file that works
<cjwatson> now, the version in PackagingGuide/QtApplication looks like your version
<PasNox> so now it create correct deb package, but it seem u say me my tempaltes are bad and i should recreate them from a clean  debian folder ?
<cjwatson> and it's also based on /usr/share/doc/debhelper/examples/rules.arch from old (pre-oneiric) versions of debhelper
<cjwatson> PasNox: we're not saying they're *bad* as such, we're saying that this entire conversation would have been unnecessary if you were using a modern rules format because you wouldn't have to micromanage which dh_* commands to call in which order
<PasNox> cjwatson: i see, the problem is that i follow the how to from https://wiki.ubuntu.com/PackagingGuide/QtApplication
<PasNox> so this is outdated ?
<cjwatson> it is not adequate for libraries and it is not up to date with current recommendations
<PasNox> oh i think i remember
<cjwatson> it would be better off recommending /usr/share/doc/debhelper/examples/rules.tiny
<slangasek> SpamapS: yeah, cmake was already multiarch-sorted in the first round :)
<PasNox> possible i copy / paste the content from the how to in my rules files
<PasNox> :/
<PasNox> it's why it does not looks like the generated one ??
<cjwatson> this sort of thing is really nice to remember so that you don't send people off on wild goose chases ;-)
<PasNox> ok so the better, is to get rules.tiny and make changes to it and use this one instead of my current rules file ?
<cjwatson> that would be my recommendation, yes.  you don't need to start again as far as the rest of the files under debian/ are concerned, though
<SpamapS> is there a script somewhere to do a mass upload of all the rdeps of something? I want to do a test-rebuild against MySQL 5.5 in my PPA before raining down rebuilds on the main archive.
<PasNox> cjwatson: ok, i will try that now, thanks u
<cjwatson> 'man dh' has a bunch of examples of how to do little customisations - the idea is that you only have to describe how your package differs from normal
<PasNox> and thank u all for your valuable help :)
<slangasek> SpamapS: StevenK probably has such a script, but I'd think it's a shell oneliner
<cjwatson> I use variations of http://paste.ubuntu.com/733682/ (and a for loop) for my mass rebuilds
<SpamapS> Thats precisely what I need. :)
<broder> SpamapS: i think you could do this with a really short shell loop combining tumbleweed's new rdepends service (http://qa.ubuntuwire.org/rdepends/) and backportpackage
<cjwatson> wait for vi to appear, wait one second to be sure the timestamp has ticked over, :wq, check diff, enter
<SpamapS> well, that and an unlicensed particle accelerator that I can carry on my back.. but.. need may be too strong for that..
<cjwatson> SpamapS: if it's a biggish library soname transition, we can set up a transition tracker for it
<cjwatson> all that needs is patterns for affected (which packages should we bother to look at, usually a regex on build-depends), good (usually a regex on depends), and bad (ditto)
<infinity> cjwatson: libmysqlclient qualifies as big, yeah.
<cjwatson> so what are the old/new sonames?
<infinity> adconrad@cthulhu:~$ apt-cache rdepends libmysqlclient16 | wc -l
<infinity> 164
<cjwatson> er, package names
<infinity> Old is anything <= 16, new is 18.  Looks like.
<cjwatson> we can ignore < 16 for these purposes I think
<cjwatson> given that we only have 16 in precise
<infinity> Yeah, looks like < 16 got properly transitioned from where I'm sitting.
<infinity> SpamapS: Verify that the new SOVER is 18?
<infinity> SpamapS: I've only been half awake today.
<slangasek> that's the sover he mentioned earlier
<cjwatson> http://people.canonical.com/~ubuntu-archive/transitions/libmysqlclient.html should appear in a few minutes
<cjwatson> anyone in https://launchpad.net/~ubuntu-transition-trackers can tweak it if I got it wrong
<SpamapS> infinity: yes, its 18.. or at least, it was at 5.5.15 ..
 * SpamapS re-checks 5.5.17
<SpamapS> cjwatson: thank you
<angelo-c> bye, thank you all!
<slangasek> SpamapS: bah, mysql-5.1 ftbfs on amd64: https://launchpadlibrarian.net/84808548/buildlog_ubuntu-precise-amd64.mysql-5.1_5.1.58-1ubuntu2_FAILEDTOBUILD.txt.gz
<slangasek> main.query_cache_28249                   [ fail ]
<cjwatson> SpamapS: whoops, I got the good/bad regexes backwards; but you can look at that tracker page now and check the 'good' button to get a list of source packages
<cjwatson> fixed for the next regen in an hour from now
<PasNox> for the package name
<PasNox> i should calle libfresh1 and libfresh1-dev ?
<PasNox> or libfresh1 and libfresh-dev ?
<PasNox> should name*
<SpamapS> slangasek: hmm.. http://bugs.mysql.com/bug.php?id=43861
<slangasek> ibfresh1 and libfresh-dev is best
<cjwatson> I would normally recommend libfresh-dev, unless you think you're likely to be in a position to want to support people building against multiple different versions of the library in the same release
<slangasek> sorry, libfresh1 of course
<cjwatson> (which you probably aren't)
<slangasek> SpamapS: so... give-back? :P
<PasNox> ok, so let got for libfresh1 and libfresh-dev
#ubuntu-devel 2011-11-10
<PasNox> thank u for all your help guyz :)
<SpamapS> slangasek: I think we should disable that test. It looks to be non-deterministic based on the comments from Kristofer Pettersson
<SpamapS> slangasek: Stewart Smith (very highly respected mysql internals dev) is calling to reopen the bug too near the bottom
<SpamapS> slangasek: but yeah, retry the build, there's a chance it will work
<PasNox> and for the python package
<slangasek> SpamapS: ok
<PasNox> python-qt4-fresh1 / python-qt4-fresh-dev or python-qt4-fresh / python-qt4-fresh-dev ?
 * SpamapS spies something wicked in the way 5.5 builds its libraries..
<SpamapS> lrwxrwxrwx root/root         0 2011-11-09 15:53 ./usr/lib/libmysqlclient.so -> libmysqlclient.so.16
<slangasek> hehwhat
<slangasek> is that courtesy of debian/rules?
<SpamapS> I am not sure
<SpamapS> mysql has always had.. problems.. with building their libraries
<slangasek> I know that the symlinks in -5.1 were being done via debian/rules instead of trusting the upstream build system to do it, so maybe fixes are needed there
<slangasek> mmnope
<SpamapS> entirely possible that the upstream forgot to bump SOVER properly
<SpamapS> slangasek: possibly need to resurrect the thing that does the symlink manually though.. :(
 * slangasek nods
 * SpamapS is so tired of rebuilding mysql.. :-P
<SpamapS> slangasek: AHA! ./debian/libmysqlclient-dev.links:usr/lib/libmysqlclient.so.16	usr/lib/libmysqlclient.so
<SpamapS> it is debian/rules fault.. sort of ;)
<slangasek> score
<SpamapS> hrm.. I wish I'd kept that last chroot around.. such a tiny problem. :-P
 * TheMuso has a double take at the download speed from cdimage with a DVD iso to Australia.
<TheMuso> I've never pulled images from cdimage this fast before.
<StevenK> SpamapS: "increasingly convinced that @Percona & Ubuntu are the only people who ever regularly run the MySQL test suite and naively expect it to pass."
<SpamapS> StevenK: we're just a bunch of silly gits aren't we? ;-)
<StevenK> Haha
<slangasek> "naively expect it to pass" is a funny way to spell "demand quality control from a database server"
<StevenK> slangasek: That's from Stewart Smith, he's allowed to be bitter.
<slangasek> I also expect the php test suite to pass
<slangasek> even though I know it has test cases that care which side of Greenwich you're on :)
<StevenK> Hah
<SpamapS> actually
<SpamapS> 5.4 has fixed that
<StevenK> slangasek: Twisted sets the timezone to UTC+0530 for its test suite for exactly that point.
<SpamapS> http://ci.qa.php.net/ btw
<SpamapS> the PHP release process has been formalized and the tests must pass now. :-P
<StevenK> I wonder why that is. :-P
<StevenK> *cough*
<slangasek> does that include the unixtojd test that was written wrong? :)
<SpamapS> I believe its been ammended
<slangasek> (and correctly verifies that the function returns the wrong answer it was programmed to return? :)
<slangasek> ok :)
<SpamapS> haha probably tho ;)
<SpamapS> still , its a happy thing that there is actual CI for PHP now
<SpamapS> and actual guarantees for backward compatibility
<SpamapS> just don't ask them about unicode. ;)
<SpamapS> Ugh, mysql has really gone and #%!@'d up libmysqlclient_r ... instead of just leaving it out and letting people update their build scripts.. :p
<SpamapS> lrwxrwxrwx root/root         0 2011-11-09 16:39 ./usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18 -> libmysqlclient.so
<SpamapS> lrwxrwxrwx root/root         0 2011-11-09 16:39 ./usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18.0.0 -> libmysqlclient.so
<SpamapS> *doh*
 * SpamapS ponders just removing it so builds will fail and we can fix them
 * SpamapS does just that
<slangasek> not sure how ./usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18 would prevent a build from failing anyway
<SpamapS> slangasek: that would make libmysqlclient18 depende on libmysqlclient-dev
<SpamapS> slangasek: technically anyhow.
<slangasek> oh, well obviously the symlink as-is is wrong
<SpamapS> slangasek: I'm just removing it. -lmysqlclient_r is actually deprecated, may as well find them all and fix them now.
<slangasek> I just don't see any reason having it at all would help anyone
<slangasek> because -lmysqlclient_r wouldn't match libmysqlclient_r.so.18 anyway
<SpamapS> slangasek: right, at one time libmysqlclient_r.so pointed at libmysqlclient_r.so.18
<SpamapS> It will mean that anything that we change from -lmysqlclient_r to -lmysqlclient will have to build-dep on libmysqlclient-dev ( >> 5.5.17-2 ) so that they don't accidentally backport and lose thread safety.
<slangasek> yep
<SpamapS> ok.. enough building ... I'm off to see the wonderful wizard of Trader Joes
<Riddell> highvoltage: we would like LTS for 5 years, it'll be up to the tech board if we get it of course
<nigelb> Yay chrisccoulson! http://blog.mozilla.com/meeting-notes/archives/702
<nigelb> "Chris has done a ton of work with integrating both Thunderbird and Firefox nicely with Ubuntu. Heâs a machine. "
<TheMuso> D/c
<pitti> Good morning
<ion> o hai
<pitti> lool: thanks; so I guess that was the same problem as  last time then?
<pitti> slangasek: yes, it should be consistent; chances are very high that it just needs a rebuild, I fixed an instance of this in the last upload
<micahg> pitti: looks like we might not need a FIrefox transition for Maverick, will confirm next week
<pitti> micahg: oh, 3.6 will be supported longer?
<micahg> ATM, looks like until Apr 2012
<pitti> that should be enough indeed, nice
<broder> awesome. i apparently earn the idiot award of the day for uploading a source-change backport...and forgetting to make the source change
<broder> pitti: can you at least reject the natty upload for znc? :)
<pitti> broder: urgh, sorry, didn't spot that; reupload, and I'll process right away?
<pitti> broder: done
<micahg> broder: debdiff is your friend :)
<broder> i know! and i think i decided not to look because it was such a simple change and how could i possibly have screwed it up :-/
<pitti> broder: it'll just FTBFS, right?
<pitti> (or depwait)
<broder> pitti: FTBFS - <= oneiric's swig2.0 conflicts with swig
<broder> pitti: thought since i'm actually fixing this, i'm going to make sure the natty one depwaits until the pending no-change backport of swig2.0 is processed
<broder> pitti: double-checked, and reuploaded. should show back up in your queue mometarily
<broder> sorry about that!
<pitti> thanks!
<broder> ...huh, oh dear. the regexps i wrote for backport-helper totally don't work :)
<broder> "Please backport activity-log-manager (0.8.0-1) from precise" => backport-helper gets "activity" as the package name
<lool> pitti: it looks like last time
<lool> pitti: but then, I don't have a lot of caracterizing evidence to claim it's the same bug
<pitti> lool: so I'll revert that patch once again; could you check if it's working then?
<lool> pitti: if you'd like, we can try debugging this, but I wouldn't mind some handholding
<lool> pitti: Sure
<pitti> lool: ok, 175-0ubuntu0test2 uploaded; I'll ping you when it's built
<pitti> so let's confirm first that it's that part of the code
<dholbach> good morning
<lool> pitti: test2 booted fine
<pitti> lool: thanks
<Daviey> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | 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: Daviey
<dholbach> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | 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: dholbach, Daviey
 * dholbach hugs Daviey
<dholbach> hum, can somebody help me with http://paste.ubuntu.com/734002/ please?
<dholbach> not quite sure what to do about "bzr: ERROR: None 0.3.4 was not found in <PristineTarSource at http://bazaar.launchpad.net/%7Eblair/ubuntu/precise/rbtools/rbtools-fix-886436/>."
<pitti> hm, perhaps the branch didn't use merge-upstream/
<pitti> ?
<dholbach> probably
<Laney> how do you see the raw pristine-tar data in udd branches?
<pitti> you can't see in http://bazaar.launchpad.net/~blair/ubuntu/precise/rbtools/rbtools-fix-886436/revision/3, though
<pitti> you could check out the branch and try bzr bd -S
<pitti> if that works, then it's a bug in merge-package (not taking new pristine-tars)
<gaspa> barry: can you take a look at: http://pastebin.ubuntu.com/734039/ ? (this works in debian sid and in 10.10, but not in Oneiric, nor in Precise)
<geser> gaspa: gcc -I/usr/include/python2.7 -o pyrun pyrun.c/tmp/ccImdWA6.o -lpython2.7
<geser> the -lpython2.7 has to come after the .o which uses it (ld --as-needed)
<gaspa> geser: oh, as-needed,  ... and debian didn't use it yet?
<geser> no, not yet as far as I know (but accepts patches fixing such issues)
<gaspa> geser: ack. thanks :)
<pitti> hmm
<pitti> /etc/alternatives/javac -> /usr/lib/jvm/java-6-openjdk/bin/javac
<pitti> but I have /usr/lib/jvm/java-6-openjdk-amd64/bin/javac
<pitti> incomplete multi-arch-ification?
<pitti> ah, bug 887077, updating
<ubottu> Launchpad bug 887077 in openjdk-6 (Ubuntu) "alternatives are not updated to new paths" [Undecided,New] https://launchpad.net/bugs/887077
<dholbach> can somebody please reject https://code.launchpad.net/~pallavikumarijha/ubuntu/oneiric/battery-stats/oneiric/+merge/80145?
<dholbach> can https://code.launchpad.net/~gandelman-a/ubuntu/natty/facter/lp876130_lp732953/+merge/80276 be marked as merged please (r16)?
<dholbach> https://code.launchpad.net/~gandelman-a/ubuntu/oneiric/facter/lp876130/+merge/80277 (r16) too
<janimo> ricotz, hi, do we wait for newer version of clutter-gst to land in debian first? We are  2 minor releases behind upstream. There's a fix going into 11.10 via SRU and I wonder whether it makes more sense to just upgrade to the new version in precise instead of cherry-picking the fix as for the SRU
<dholbach> Daviey, up until now no mid-air collisions while we're working on the queue - seems there's still enough in there ;-)
<ricotz> janimo, hi, yeah syncing it to precise after an update in debian would be better -- is this fix actually in 1.4.4?
<Daviey> dholbach: I'm going to continue working bottom up, ok?
<dholbach> Daviey, sure sure
<ricotz> janimo, http://git.gnome.org/browse/clutter-gst/commit/?id=11cce755880127565e88bd50c63c6f0b7ee6051f -- it wasnt committed to the 1.4.x branch
<Daviey> dholbach: looks like we did have a near miss :)
<janimo> ricotz, ah, I saw Oct 6 yesterday and assumed it was in a 1.4 release
<ricotz> janimo, 1.4.4 isnt so important though, i guess you confirmed that this works and fixes the problem ;)
<ricotz> since you already uploaded it
<janimo> ricotz, indeed it fixes it
<janimo> ricotz, so in order to comply with SRU should I just add the patch to our precise package exactly the same way?
<dholbach> can https://code.launchpad.net/~jtaylor/ubuntu/oneiric/bitlbee/fix-879730/+merge/80498 please be marked as merged?
<pitti> dholbach: done
<dholbach> pitti, and the other ones above as well?
<ricotz> janimo, yeah i guess you can do so, i will ask for this patch to get in 1,4
<janimo> ricotz, thanks. Although they seem to consider it a sort of ABI breakage even if these may not have been very public shader variables
<pitti> dholbach: done
 * dholbach hugs pitti
 * pitti hugs dholback, kein Problem
<ricotz> janimo, ok
<ricotz> janimo, probably there will be a 1.4.6 soon including this fix
<janimo> ricotz, great
<dholbach> can https://code.launchpad.net/~cldunlap1/ubuntu/oneiric/xine-lib/fix3-for-835437/+merge/78959 be rejected (fix is upstream already, and a bug in Debian already filed)?
<pitti> done
<dholbach> merci
<Daviey> dholbach: are you looking at bug 881695?
<ubottu> Launchpad bug 881695 in xoscope (Ubuntu Oneiric) "Xoscope doesn't work on soundcard (No valid data sources found... exiting)" [Medium,Fix committed] https://launchpad.net/bugs/881695
<dholbach> Daviey, I thought that one had the fix already uploaded, it was just sitting in the queue?
<lifeless> ev: are we on for that call in ~7h ?
<Daviey> dholbach: I haven't sniffed, i just saw your latest comment.
<ev> lifeless: sure are!
<lifeless> cool
<lifeless> I'll go get some sleep :)
<ev> enjoy :)
<dholbach> can https://code.launchpad.net/~cldunlap1/ubuntu/oneiric/xchat/fix-for-816506/+merge/80118 be rejected?
<jandrusk> test
<seb128> what team is giving ubuntu series nominations rights?
<seb128> i.e the right to nominate a bug for a serie
<geser> isn't it ubuntu-dev?
<pedro_> its ubuntu-drivers ^
<seb128> geser, is that for suggesting nominations or approving?
<geser> IIRC MOTU can nominate for packages in universe, not sure if for packages in main too (didn't use it for some time)
<seb128> pedro_, doesn't make sense, you just said you can approve but you are not in ubuntu-drivers?
<cjwatson> bug supervisor (ubuntu-bugcontrol) can nominate; driver (which in this context is either ubuntu-drivers or ubuntu-release I think, possibly the union) can approve
<cjwatson> at least by my reading of the code
<seb128> ok, I guess pedro can approve by ubuntu-release which include canonical qa team then
<cjwatson> right
<cjwatson> ubuntu-release is typically the series driver
<ScottK> So developers can't?
<ScottK> Seems off.
<cjwatson> er, not sure, as you know it's hard to tell by experimentation
<cjwatson> do not assume anything in particular from my attempt to divine it from the code - in particular don't assume malice!
<seb128> do we have a definition somewhere of how nominations and targetting should work and who should have access?
<seb128> I've some people who asked me if they should have access or not to nominations, that's what I was trying to figure
<seb128> would it be a TB topic to get some clarification on that?
<tumbleweed> I'm pretty sure I could approve MOTU nominations before I was on -release
<tumbleweed> s/MOTU/universe/
<cjwatson> yofel_: hey, I was just looking at the kalgebra build failure and noticed that you'd added libncurses-dev to the build-deps in bzr
<yofel_> cjwatson: ah right, it didn't get uploaded yet - should I close a bug in the changelog?
<cjwatson> yofel_: this is *a* fix, but I don't think it's the ideal fix - calgebra doesn't actually use ncurses, so it would be better to drop that linkage
<cjwatson> yofel: would you mind if I worked on removing the ncurses requirement instead?
<cjwatson> yofel: I don't think there's a bug, no, I was looking at the ftbfs list for main
<cjwatson> (I was gently corrected by one of the Debian ncurses developers when I made a similar mistake in one of my packages)
<yofel> no, as long as you send that to KDE, and notify the debian-qt-kde team about it, as they added libncurses-dev to their package too
<cjwatson> ok, sure
<dholbach> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | 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: Daviey
<cjwatson> yofel: do you have the tarball location handy?
<cjwatson> ah, never mind
<yofel> found it?
<cjwatson> yeah
<cjwatson> seb128: https://bugs.launchpad.net/launchpad/+bug/174375 has the history; at this point I think you should ask Launchpad rather than the TB if you want clarification
<ubottu> Launchpad bug 174375 in Launchpad itself "Distribution drivers permissions may need redesign" [Low,Triaged]
<seb128> cjwatson, thanks
<brendand> can someone point me to the page on the requirements for proposing an SRU?
<seb128> brendand, https://wiki.ubuntu.com/StableReleaseUpdates
<jdstrand> cjwatson: speaking of that... I see this comment from you in the bug "Pete has approved canonical-qa's membership of ubuntu-release, so I have gone ahead and removed canonical-qa from ubuntu-drivers."
<jdstrand> cjwatson: (hi btw)
<jdstrand> cjwatson: it would be good if the security team was part of one of these groups, since we routinely use release tasks for tracking security bugs
<jdstrand> cjwatson: we've approached skaet, but she said something about needing to talk about it with people. I am a driver like pete is, I wonder if we can actually just do it if I say my team needs it?
 * jdstrand is not trying to circumvent anything of course, just want my team to not be blocked
<jdstrand> right now, jjohansen is unable to perform his duties on his own because of this
<jdstrand> cjwatson: telling me you don't want to be involved and keep dealing with skaet is a perfectly acceptable answer :)
<hallyn> cjwatson, I'm thinking of syncing syslog-ng.  Just pinging you bc you did the last commit.  Had you started that?
<cjwatson> jdstrand: I don't want to be involved but surely you should deal with the TB not with skaet, since the TB is the owner of ubuntu-drivers and skaet isn't
<cjwatson> I mean I don't want to be involved personally
<jdstrand> I understand
<jdstrand> we approached her for the ubuntu-release bits
<cjwatson> oh, ubuntu-release not ubuntu-drivers
<jussi> Hrm, I asked this elsewhere this morning, but no one seemed to know. After marks keynote, Is there a part of canonical looking into phones, phone applications etc for ubuntu? and if so, who are the relevant people?
<cjwatson> I do not think we should artificially add even more people to ubuntu-release, TBH ...
<cjwatson> if you can't do what you want with the privileges you have then perhaps we should open a discussion with LP about it
<jdstrand> cjwatson: yeah, figured ubuntu-drivers was too much. really, I think ubuntu-security should just be one of the groups allowed to create tasks, but that is probably a slow fix
<cjwatson> the problem is that a slow undesigned accretion of privileges was the position we were in before
<cjwatson> people understood it even less
<jdstrand> I just hope it doesn't take months/years to fix...
 * jdstrand files a bug
<cjwatson> I mean, it's possible to add ubuntu-security if we need to I guess
<cjwatson> I'd just like to understand what we're doing and plan for a better fix
 * jdstrand nods
<cjwatson> because if we just turn ubuntu-release into a copy of the mess that ubuntu-drivers used to be, we won't have gained a whole lot
<jdstrand> the bug is the correct thing to do. I'll file it and maybe we can workaround in the meantime
<cjwatson> hallyn: if the libdbi-dev fix is in Debian now, feel free to sync, otherwise merge; I'm not working on it
<hallyn> cjwatson, thanks
<jdstrand> cjwatson: thanks
<seb128> cjwatson, jdstrand: do we have any Ubuntu definition of who in theory should have access to nominations?
<seb128> out of the launchpad groups and teams handling issue
<cjwatson> seb128: not AFAIK
<jdstrand> I just filed bug #888568 to expand any existing definition
<ubottu> Launchpad bug 888568 in Launchpad itself "ubuntu-security should be able to target to release" [Undecided,New] https://launchpad.net/bugs/888568
<cjwatson> we have lots of opinions
<cjwatson> some of them may even be the same
<jdstrand> and I added one more :)
<seb128> cjwatson, who would be qualified to come with a definition, TB?
<cjwatson> I guess.
<seb128> thanks
<jdstrand> seb128: if you are crafting correspondence to the TB, feel free to reference my new bug :)
 * jdstrand likes piggybacking
<seb128> jdstrand, ok, I've put it on my list but I will probably don't get to it this week since tomorrow is off there and I've still work I want to do today, but maybe next week ;-)
<jdstrand> seb128: sure thing. I would like to see the larger issue fixed, but I'm currently focused on getting something going so my team can do their work. as such, your timeframe works fine for me :)
<seb128> jdstrand, right, I think we should workaround to unblock your team and then try to get a better definition of who should have access or not
 * jdstrand nods
<cjwatson> yofel: committed, sent upstream, forward to Debian in progress
<nigelb> g20
<nigelb> urgh
<debfx> Laney, ScottK: bug #828017 has been marked as a duplicate. is there another bug that tracks the "backports can't build-depend on other backports" issue?
<ubottu> Launchpad bug 717969 in Launchpad itself "duplicate for #828017 storeBuildInfo is sometimes ineffective" [Critical,In progress] https://launchpad.net/bugs/717969
<Laney> i didn't know about that issue
<debfx> it's that way since NotAutomatic has been introduced (natty)
<Laney> so you need to specify a version constrant
<debfx> that doesn't help, see https://launchpad.net/ubuntu/+source/teeworlds/0.6.0-2~natty1
<debfx> it's stuck in dep-wait
<Laney> interesting
<Laney> lamont: any clue ^ ?
<ScottK> debfx: I'm not sure if it's the same thing or not.  I guess we'll know when the fix lands if teeworlds builds.
<dr3mro> hello i have created a package with some bash scripts and python scripts the package just copy them into /usr/bin .. and i made it by debuild -S and uploaded it into launchpad by dput .. but it fails to build ??? can anyone help me ? why to build there is nothing to build
<dr3mro> http://pastebin.com/jwDSfVX6
<slangasek> dr3mro: you use debhelper in debian/rules, but debian/control doesn't declare this as a build dependency
<slangasek> you can only use tools at build time that are listed as build dependencies
<slangasek> (Build-Depends: debhelper (>= 7.0.50~)
<slangasek> )
<dr3mro> slangasek, but the package have no code to build just plain bash scripts
<slangasek> dr3mro: you still have to be able to run debian/rules to output the binary package
<dr3mro> slangasek, http://dl.dropbox.com/u/8828739/packages/nautilus_actions_etxra/nautilus-actions-extra_0.1.3-1_all.deb
<dr3mro> slangasek, http://dl.dropbox.com/u/8828739/packages/nautilus_actions_etxra/nautilus-actions-extra_0.1.3-1.debian.tar.gz
<slangasek> dr3mro: I'm not sure what you expect those files to tell me; I've already given you the answer to your question, which is that you need to fix debian/rules to list the correct build dependencies for your package
<dr3mro> slangasek, i am noob and i don't know about that :) sorry .. how to do that can you explain plz
<bjsnider> dr3mro, did you use dh_make to create build scripts?
<slangasek> dr3mro: edit debian/control; make sure the stanza has a 'Build-Depends: ' field that includes 'debhelper (>= 7.0.50~)' as one of the values
<dr3mro> bjsnider, yes
<slangasek> (sorry, it's debian/control that needs fixed, not debian/rules - I misspoke)
<bjsnider> well, then debhelper should have been added as a build-dep automatically
<slangasek> yes, it should have
<bjsnider> pastebin your debian/control
<dr3mro> ok i had added it to control
<bjsnider> that file could have other problems
<dr3mro> http://pastebin.com/MMuLys6S
<slangasek> dr3mro: the field name is 'Build-Depends:', not 'Build-Depend:'
<slangasek> so the full line should be:
<slangasek> Build-Depends: debhelper (>= 7.0.50~)
<dr3mro> slangasek, thank you ... i will fix it
<bjsnider> dh_make didn't create that line by itself? i don't accept that.
<slangasek> dh_make does add the line itself
<dr3mro> slangasek, why it succeeded to build on my system but failed on launchpad ?
<dr3mro> It finished upload by dput .. waiting for it to appear on ppa and build
<slangasek> because you have debhelper installed on your system
<slangasek> whereas launchpad only installs the things that the package tells it to
<dr3mro> slangasek, thank you it was very helpful
<slangasek> you're welcome :)
<dupondje> kenvandine: pitti: prepared new patches for papyon, as the current patch didn't seem to solve the issues for everybody. New patches uploaded in https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349
<ubottu> Launchpad bug 887349 in papyon (Ubuntu Maverick) "Can't login in Windows live acount using empathy" [Undecided,Confirmed]
<iceroot> dupondje: the issue is based on routing-issues (imo) so you cant patch that issue for all users
<iceroot> dupondje: because on of the servers cant be reached from everyone
<dupondje> iceroot: but now the server to be used is hardcoded to a .us based one. This works indeed fine for most people.
<dupondje> The new patch uses the 'old' server, but follows the redirection to the server supplied by msn itself
<iceroot> dupondje: ah ok
<dupondje> This should be better as msn will prolly push a server near to your location
<dupondje> Its also the patch that got included upstream and in emesene and debian
<dupondje> and no isses reported there atm
<iceroot> dupondje: sounds good
<Fusionite> Hey all
<debfx> ScottK: that commit won't fix the backports problem. that's an issue in sbuild or how sbuild is used.
<lifeless> ev: hiya; I'm up early :>
<ev> lifeless: hi
<ev> ready whenever you are then
<lifeless> will ping shortly then
<ev> cool
<dr3mro> .
<dr3mro> how to create a recipe on launchpad to build app against gtk 3 .. lets say equevalent to ./configure --gtk3
<debfx> Laney, ScottK: I've opened a new report: bug #888665
<ubottu> Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [Undecided,New] https://launchpad.net/bugs/888665
<mterry> slangasek, libmysqlclient-dev is installing into /usr/lib/${DEB_HOST_MULTIARCH}/libmysqlclient.so (literal characters)
<slangasek> hmm
<slangasek> well I'll just fix that then, shan't I
<mterry> :)
<lifeless> ev: http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops/trunk/view/head:/oops/config.py
<broder> infinity: just fyi re bug #888665, i honestly don't think anybody has particularly well-formed expectations for how the backports pocket is *supposed* to work these days (see also last week's TB discussion), so as long as there's some way to pull in build-deps from backports, i'm not sure the exact behavior on the corners is that important
<ubottu> Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [Undecided,Confirmed] https://launchpad.net/bugs/888665
<broder> which is really a long winded way of saying that i think overriding NotAutomatic for builds would be fine
<slangasek> mterry: mysql-5.1 fixed
<micahg> broder: I think I'd almost prefer it to behave like experimental where the dependency had to be explicit to minimize the requirement of installing packages from backports on users' systems
<broder> micahg: i think that's a better solution, but i'd rather fix the issue quickly than fix it better
<broder> and try to do that in the longer term
<micahg> broder: the fix is to bump the versioned dependency in the build-depends when backporting :)
<broder> no, that's not sufficient, because sbuild's resolver is too dumb
<broder> micahg: the problem is that sbuild's apt resolver just takes the un-versioned build-deps and passes them to apt-get install
<broder> you can see it if you look at a failing build log: https://launchpadlibrarian.net/84871107/buildlog_ubuntu-natty-i386.teeworlds_0.6.0-2~natty1_MANUALDEPWAIT.txt.gz
<micahg> broder: ugh, is that the case with a more current sbuild as well?
<broder> the bug description makes it sound that way
<broder> oh wait, no, i think they fixed it
<broder> it does the pbuilder thing where it generates a dummy package
<broder> so that would work
<broder> i'll mention that on the bug
<mterry> slangasek, thanks!
<chrisccoulson> slangasek, fixed your issue now (bug 888307)
<ubottu> Launchpad bug 888307 in thunderbird (Ubuntu Oneiric) "Bundled Firefox extensions disabled on upgrade to 8.0" [Critical,Fix committed] https://launchpad.net/bugs/888307
<chrisccoulson> we disabled this new feature entirely in the end :)
<tumbleweed> broder: currents sbuild has 3 different resolvers, you can choose between them. lp sbuild in an old version of the internal resolver
<broder> tumbleweed: right. infinity said that there were plans to upgrade lp's sbuild
<tumbleweed> well, people have been talking about that for years, but apparently that's non-trivial
<broder> i'm sure
<slangasek> chrisccoulson: ok :)
<sebner> slangasek: is it safe to upgrade to precise atm?
<hallyn> Is there a standard command one can use to say "add release-updates and release-security to /etc/apt/sources.list" ?  Or does that need to be done by hand?
<slangasek> sebner: somewhat? :)
<slangasek> hallyn: software-properties-gtk lets you do it interactively; not sure if there's a commandline version
<hallyn> slangasek, ok, thanks
<sebner> slangasek: sufficient for me :D
<broder> hallyn, slangasek: software-properties is backed by a python library that could probably be scripted
<slangasek> broder: so the answer to "is there a standard command" is "no" :)
<broder> oh, sure
<hallyn> it definately sounds worth doing at some point
<hallyn> but for now the files I'm working with are guaranteed to be simple enough that it makes sense to do it by hand :)
<hallyn> thanks
<Daviey> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | 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:
<Daviey> oops
<angelo-c> inifinity: are you here?
<SpamapS> infinity is always "here"
<angelo-c> great news! hi spamaps!
<angelo-c> I have to test the bugs infinity helped me to submit
<angelo-c> I'm asking an advice on that
<MDesigner> hey guys, who is head of the audio team?
<MDesigner> I'd like to contribute
<MDesigner> I actually asked before, but forgot the link. there was a page w/ someone's name on it..
<infinity> SpamapS: I am?
<SpamapS> infinity: you are technically imaginary.. but.. every time we divide by zero, there you are.
<infinity> angelo-c: The oneiric-proposed upload is still sitting in the queue waiting for the SRU team to let it in.
<slangasek> MDesigner: I don't know that we have an "audio team" per se, but TheMuso is usually the right person to talk to
<infinity> angelo-c: So, not much for you to test right now. ;)
<slangasek> (particularly at this time of day)
<infinity> SpamapS: Well, stop dividing by zero and maybe I could finally get some sleep?
<MDesigner> slangasek: actually I found this- https://launchpad.net/~ubuntu-audio-dev
<slangasek> MDesigner: yes, TheMuso is listed as the sole administrator of that team :)
<MDesigner> ok, I'll come back when he's not idle. or maybe drop an email
<TheMuso> I am here.
<TheMuso> Please read the message at the top of that team page.
<TheMuso> Help is welcome however.
<MDesigner> actually.. I just wanted to contribute a new startup sound for Ubuntu
<TheMuso> But that team has direct access to packaging that goes into the Ubuntu archives.
<TheMuso> MDesigner: Oh right. You might want to talk to the design/dx team about that, as it probably needs to be run by them. That is, if you want to get it into Ubuntu proper.
<TheMuso> Otherwise, I'd just make a sound theme deb availab eiwth your ifferent startup sound.
<MDesigner> ok. who do I talk to?
<angelo-c> infinity: it's advisable to test for precise?
<TheMuso> I am not sure who you should talk to re design team.
<MDesigner> hmm
<infinity> angelo-c: Testing the precise version would be nice.  But testing the SRU version is essential (or, will be once it's accepted)
<angelo-c> infinity: if yes, if I download a cd image and install to a vm, I can download the latest version of xoscope with patch applied?
<infinity> angelo-c: Yeah, xoscope in precise will be with the patch applied.
<infinity> angelo-c: And if you can verify it's fixed in precise, that would be nice.
<angelo-c> infinity: when the package will be ready, i'll test for oneiric as soon as possible
<angelo-c> infinity: I think it doesn't should be too much difficult, I'm downloading a daily cd image of precise, when done, i'll install inside the live cd, clean and simple!
<infinity> angelo-c: Danke.  The SRU team will post a comment to the bug when they accept it and ask for testing.
<angelo-c> great, i'm impatient!
<angelo-c> infinity: great, i'm impatient!
<MDesigner> ok I'll try to find a contact for the design team
<TheMuso> MDesigner: I believe there is an ayatana design mailing list, perhaps thats the best place to ask.
<TheMuso> No other idea where to ask I'm affraid.
#ubuntu-devel 2011-11-11
<poolie> can i use pycentral across all of hardy..oneiric?
<Riddell> poolie: yes, pycentral isn't new
<poolie> i knew it was old; i wondered if it was too deprecated
<poolie> thanks though
<Riddell> poolie: using dh_python2 is more fashionable than using pycentral
<mwhudson> but doesn't work on even lucid, right?
<Riddell> right, it's newer
 * micahg thinks there's a workitem to backport dh_python2 to lucid
<micahg> poolie: pycentral has been deprecated as well
<broder> i think there are plans to demote it to universe this cycle
<micahg> well, hopefully we can just finish the transition and drop it from the archive
<micahg> 943 packages to go
 * broder is a bit skeptical whether that's the best use of developer time this cycle
 * micahg has a few other things he'd like to drop as well that require transitions
<taladon> i'm getting this when i try to build gnome-nettool http://pastebin.com/qNC0NEyu   not sure what I need to satisfy configure
<taladon> hmm, think I may have just figured it out... just did apt-get install gtk2.6 252meg download
<broder> taladon: there are a few ways to figure this out. you can use "apt-get build-dep gnome-nettool"
<broder> if you're working from the debian package, you can also look at debian/control for the "Build-Depends" line
<taladon> already tried that... but it didn't grab the gtk2.6
<taladon> i'm pulling branch from launchpad
<broder> taladon: did you grab an old version of gnome-nettool? the current one shouldn't need gtk2
<taladon> i did a bzr branch lp:gnome-nettool
<poolie> micahg, thanks
<poolie> i think at the moment i don't totally need either of them
<poolie> this is the lp-buildd package, so it's quite special
<pitti> Good morning
<porthose> Would a kind archive admin please process bug #888212, thx :)
<ubottu> Launchpad bug 888212 in Ubuntu "Sync openteacher 2.2.1-1 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/888212
<dholbach> good morning
<Daviey> cjwatson: Good morning, can i ask if bug 833994 is on your roadmap for precise?
<ubottu> Launchpad bug 833994 in debian-installer (Ubuntu) "debian-installer does not support https when using with preseed files" [Medium,Triaged] https://launchpad.net/bugs/833994
<cjwatson> Daviey: not at the moment; if somebody could work on slimming down wget-udeb I'd probably take a patch
<Daviey> cjwatson: thanks
<Daviey> cjwatson: Hmm, wget-udeb is 159K, is that so bad?
<cjwatson> Daviey: it's quite a bit compared to the size of the netboot initrd
<cjwatson> I don't like to bloat that without bound!
<dr3mro> please can any one help me create a daily build ppa of an application i am not a contributer to in launchpad ??
<Daviey> cjwatson: agreed.. I was thinking about it in iso context, i'm a donut not thinking about it in netboot usecase.
<Daviey> please slap me.
 * cjwatson fetches the trout
<cjwatson> I think it was mostly just that I noticed that wget-udeb was being built with obviously unnecessary options and that 159K seemed rather a lot for a minimal version of wget; perhaps I'm out of date though
<dr3mro> can any one help me what is the problem here ?http://pastebin.com/Xh272MSD
<geser> dr3mro: lp:~dr3mro/+junk/nautilus-actions looks pretty empty
<dr3mro> I am building  a ppa  and i am a noob how can i make a ppa of that lp ?
<geser> I'm not very familiar with recipe builds but you should have some files in that branch you want to build from
<pitti> jibel: we now have two packages in the archive with DEP-8/autopkgtest support, FYI; do you have time today for a 30 minute mumble call about how to set that up in the DC?
<pitti> jibel: I'm interested in how we need to extend autopkgtest to work for us
<dupondje> pitti: I createdd a debdiff for python-papyon. Its in https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349
<ubottu> Launchpad bug 887349 in papyon (Ubuntu Maverick) "Can't login in Windows live acount using empathy" [Undecided,Confirmed]
<soreau> I'm trying to remember how to find the build log for a package to determine the configure flags used. So far I've been unsuccessful with packages.ubuntu.com and apt-get source
<cjwatson> soreau: start from https://launchpad.net/ubuntu/+source/PACKAGE-NAME, follow links
<cjwatson> (I have a keyword bookmark for https://launchpad.net/ubuntu/+source/%s - it's useful for so many things)
<soreau> aha
<soreau> thanks cjwatson
<pitti> dupondje: ah, thanks, did you subscribe the sponsors?
<dupondje> pitti: ubuntu-sponsors or ? :)
<pitti> yes
<dupondje> done
<ockham_> hi, i'm on natty, and i'd like to  setup pbuilder for precise. i'm using the ~/.pbuilderrc from the wiki, but it doesn't work: i'm getting
<ockham_> Unknown distribution: oneiric-proposed
<ockham_> what am i doing wrong?
<cjwatson> which wiki page?
<ockham_> https://wiki.ubuntu.com/PbuilderHowto
<ockham_> -- from the "Multiple pbuilders" section
<cjwatson> can you pastebin the entire output from pbuilder?
<ockham_> with oneiric and precise added, that is
<cjwatson> including the command you're running
<ockham_> okay. i'm trying to invoke it via cowbuilder -- one second
<sagaci> ockham_, pbuilder-dist precise create
<cjwatson> sagaci: I don't think that's the problem, let me debug this please
<ockham_> http://pastebin.com/9hFpiY4z
<cjwatson> I mean I think there may be an interesting problem in here
<sagaci> ok no problemo
<ockham_> (i'm on amd64, so that option is kinda redundant...)
<cjwatson> ockham_: are you running this command in a directory where debian/changelog exists?
<ockham_> actually, yes
<cjwatson> ockham_: what is the first line of debian/changelog?
<ockham_> ooh, i get it. it's really oneiric-updates. i just cd'ed somewhere else...
<ockham_> hm, still failing
<ockham_> now with a different error
<cjwatson> I've fixed the pbuilder howto to cover that situation: https://wiki.ubuntu.com/PbuilderHowto?action=diff&rev2=177&rev1=176
<ockham_> great!
<cjwatson> but cding somewhere else for creation is the right thing to do anyway
<ockham_> i've updated my pastebin to reflect the new error
<cjwatson> it might have given you a new url for the update?
<cjwatson> (no change when I reload)
<ockham_> oops. http://pastebin.com/CzGgaSKB
<ockham_> oneiric is already in /usr/share/debootstrap/scripts/
<ockham_> precise, though, isn't
<ockham_> so i'd need an updated version of whatever package contains those scripts?
<cjwatson> you could (debootstrap), or you could just add a symlink
<cjwatson> sudo ln -s gutsy /usr/share/debootstrap/scripts/precise
<cjwatson> that reminds me though, I should do some backports of debootstrap
<ockham_> didn't check with ls -al first. created the symlink now, but yeah, OOTB would be even better...
<ockham_> okay, cowbuilder seems to work now. thanks a bunch cjwatson!
<cjwatson> making its way through to {maverick,natty}-backports now
<ogra_> .oO(thats what you get if mark decides so late on a name)
<ogra_> we had releases where such changes were in before release day
<ockham_> hm, can i ask you guys about a different issue? i'm trying to
<ockham_> DIST=oneiric ARCH=amd64 pdebuild
<ockham_> unity-lens-applications
<ockham_> which fails with some CDBS related complaints
<ockham_> http://pastebin.com/fxWNXA3j
<ockham_> anyone?
<geser> looks like some build-dependencies are not installed, but as I don't use pdebuild (only pbuilder) I don't know how to "fix" it
<ockham_> geser: i think normally, these should get installed automatically when using pdebuild...
<geser> ockham_: after a quick look at pdebuild, I'm not sure if it's already inside the chroot at this point at pdebuild wants to build a source package first
<ockham_> geser: really? hm, what do i need to do then?
<geser> try installing cdbs and dh-autoreconf to see if the error messages goes away (or at least less errors)
<ockham_> geser: or, how do you normally invoke pbuilder to build a package
<ockham_> ?
<geser> ockham_: I usually use "debuild -S" to build the source package and then use pbuilder on this source package to build it
<ockham_> about the chroot, you were right. i installed cdbs and dh-autoreconf, and it doesn't complain anymore.
<geser> (you need to have the packages used in the clean target installed to be able to build a source packages, mostly it's debhelper, cdbs and similar)
<jelmer> what's the best way to make sure an init file gets installed on Debian and the upstart file on Ubuntu?
<jelmer> From what I can tell, dh_installinit won't necessarily do the right thing. I'd prefer to have a single source package for both, so that there's no need for merging back and forth all the time.
<geser> dh_installinit doesn't the right thing? how?
<jelmer> geser: if I read its manpage correctly, it wouldn't install debian/FOO.init if debian/FOO.upstart exists
<geser> oh, this isn't an ubuntu delta that it prefers the upstart file?
<geser> jelmer: I'd probably try to use dpkg-vendor to check if Ubuntu or Debian and move the .upstart file out of the way if Debian
<jelmer> geser: its manpage is the same on Debian, from what I can tell
<jelmer> geser: thanks, I'll give that a try.
<ockham_> i've heard that tomboy was dropped from the precise standard installation. what's the launchpad project for the standard install? i'd like to suggest gnote (C++ implemented tomboy clone) as a replacement.
<jamespage> jelmer: the nova source package does a dpkg-vendor check and installs the upstart configuration instead of an init script when required (i.e. for Ubuntu) if you want a working example
<jamespage> however slangasek did mention some work that is happening in Debian to address upstart/init co-existence at UDS-P (unless I got the wrong end of the stick)
<jelmer> jamespage: thanks, I'll have a look at the nova package
<ockham_> anyone?
<brendand> ockham_ - it was dropped from oneiric too
<pitti> no, tomboy was still installed in oneiric
<Laney> i am unaware that it has been 'dropped' from anything
<brendand> pitti - oh. it wasn't in the install for a while though. maybe we were thinking of dropping it?
<pitti> we were thinking of it, but 11.10 still installs it
<ockham_> FWIW, http://packages.ubuntu.com/precise/gnote
<brendand> ockham_ - you can put suggestions on https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-default-apps
<brendand> ockham_ - unless someone says otherwise
<ockham_> brendand: thanks, that's what i was looking for
 * brendand install gnote
<brendand> (to find out if it can import tomboy notes)
<brendand> i think it's a shame something with such nice U1 integration is getting dropped. i guess because it has mono
<brendand> hopefully a good replacement can be found
<brendand> well, it seems to use the same notes database. ain't that nice
<ockham_> brendand: i know. i've used it before, but last time i checked, it was lacking an indicator (still using old gnome-panel applet style), i think
<ockham_> but that might be not too hard to fix
<cjwatson> lucas: there used to be an entirely different source package called yard (http://packages.qa.debian.org/y/yard.html).  I don't suppose you'd consider slapping an epoch on your new package?  I don't want to sync it and then find that LP rejects it due to versions-must-increase constraints ...
<ockham_> hi, i'm currently trying to produce a patch for #785101 (to unity-lens-applications)
<ockham_> as i'm on natty, i can only check if it builds with pbuilder, but i can't test it...
<ockham_> anyone running oneiric willing to try it out for me?
<mdeslaur> Riddell: I plan on removing the icedtea plugin from ubuntu-restricted-addons (LP: #889171). Any objections to me doing it for kubuntu also?
<mdeslaur> Riddell: too late, done.
<porthose> would a kind archive admin please process bug #888212, it's a new package in debian that I would like to backport to oneiric thx :)
<ubottu> Launchpad bug 888212 in Ubuntu "Sync openteacher 2.2.1-1 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/888212
<slangasek> porthose: that's really something that's meant to be handled by batches, not as individual bug reports requesting individual syncs
<cjwatson> though that's true, I 've generally said "feel free to file bugs to ohurry it up"
<cjwatson> since the batches require manual review
<slangasek> oh, well, I'll run the batch now anyway :)
<cjwatson> go for it :)
<broder> slangasek: could i get you to run backport-helper while you're already ssh'd into the right machines? :)
<slangasek> broder: not sure, will have to see where things lay when I finish with this bit
<porthose> slangasek, thx much appreciated :)
<slangasek> ScottK: dkim-milter was removed from Ubuntu as "dead upstream", but the package is still in Debian (with an RC bug).  Do you think it should be removed from Debian as well?  Do you want to follow up on bug #629663?
<ubottu> Launchpad bug 629663 in KARL3 "Implement "Useful Calendar Alerts" blueprint" [Medium,Fix released] https://launchpad.net/bugs/629663
<slangasek> well that's interesting.  why is X not seeing my USB keyboard / mouse?
<marw> hello. i'm trying to find info (other than rumors) about the future of mono in ubuntu.
<micahg> marw: mono isn't leaving Ubuntu, as for the default install, here'e the thread: https://lists.ubuntu.com/archives/ubuntu-desktop/2011-November/003393.html
<marw> thanks, micahg. the net is full of bombastic titles about this
<abhishek> pls, can anyone tell me where should I start with ubuntu development
<abhishek> i have registered for launchpad
<abhishek> and I know C and php, but I don't know what level of knowledge is required for development
<marw> tomboy notes is also being slashed?
<slangasek> abhishek: you might find this list of bugs useful as a starting point: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
<abhishek> thanks slangasek
<angelo-c> infinity: Hi all!
<angelo-c> infinity: I tested the updated package on precise, it works like a charm! I updated the bug!
<angelo-c> infinity: I tested the updated package on precise, it works like a charm! I updated the bug!
<infinity> angelo-c: Cheers, thanks.
<angelo-c> infinity: thank you very much! Is there any area where I can help, I'm really proud to be part of ubuntu!
<sebner> slangasek: lightdm still shows ubuntu 11.10 but other than that you were right, my laptop didn't explode on the upgrade to precise :)
<cjwatson> slangasek: could you merge libtool?  I'm pretty sure it being out of sync with dh-autoreconf is what's causing vlc to fail to build (and presumably anything else that uses 'dh_autoreconf --as-needed')
<cjwatson> or I'll do it if you prefer
#ubuntu-devel 2011-11-12
<slangasek> cjwatson: libtool> ack, will have a look
<cjwatson> slangasek: I guess you're still working through the new-source queue, so I'll steer clear of ~/syncs/
<slangasek> yeah, 'sbeen slow to iterate :P
<cjwatson> are you checking for packages that were removed previously?
<slangasek> yes
<cjwatson> the fonts-* packages in main will need some care too
 * slangasek nods
<cjwatson> I don't see how you can sync fonts-unfonts-* - isn't the greater version of ttf-unfonts a problem?
<cjwatson> that defeated me earlier today
<slangasek> those looked unsyncable due to Ubuntu delta anyway
<slangasek> but yeah, I punted those
<cjwatson> oh, they're in ~/syncs/ but with no .changes file, that's what confused me
<slangasek> ah right - yes, I've been finding the problem children by running sync-source over the list and looking when it complains ;)
 * cjwatson stops stickybeaking and goes to bed
<LLStarks> hi, is there any documentation for creating a modern dkms package?
<LLStarks> all directions i've found are outdated
<slangasek> LLStarks: I don't know, but my inclination would be to look at the dh_dkms manpage - if that doesn't tell you what you need to know, I consider that a bug
<LLStarks> thanks slangasek, i'll take alook
<LLStarks> slangasek, any way to make dput recognize my key? i'm getting verifcation errors.
<bjsnider> LLStarks, did you add it to the ubuntu keyserver?
<broder> LLStarks: is it the ["General error", "General error", "General error"] or whatever thing? that's spurious - it doesn't actually block the upload from going through
<LLStarks> "no public key"
<LLStarks> don't think i added my new one to the keyserver yet
<bjsnider> check your launchpad page for that
<bjsnider> what do you mean by "modern"?
<LLStarks> bjsnider, older than dh_dkms
<LLStarks> the older methods for cdbs
<slangasek> LLStarks: your pgp has to be associated with your account through your launchpad webpage, yeah
<slangasek> LLStarks: does that mean the dh_dkms manpage answered your questions?
<broder> oof. http://pastebin.ubuntu.com/735922/
<LLStarks> yes slangasek, i'm all set thx
<broder> ...ubuntu-docs spits out 8875 lintian tags
<broder> and it looks like we have a bunch of packages getting mis-built because of umask issues. there are...666 packages throwing non-standard-file-perm with 0664 != 0644
<Randolph> hi all
<angelo-c> Hi all!
<angelo-c> Is there a list of simple bug to solve for getting started in the wonderlful land of ubuntu developers? In kde there are junior jobs, something like these
<bjsnider> angelo-c, https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
<bjsnider> have at them
<angelo-c> thank you!
<broder> bdrung: debian-news-entry-has-unknown-version is a tag on the binary package, which i bet means it's finding news items that are older than the 10 changelog entries pkgbinarymangler saves
#ubuntu-devel 2011-11-13
<broder> bdrung: what's the issue with debug-symbols-directly-in-usr-lib-debug? i'm having a hard time understanding it from reading the bug
<broder> cjwatson: do you know what uid/gid was showing up in the broken builds? lintian doesn't seem to have an explicit tag for this, but the lintian lab has enough information for me to scrape out a report manually
<broder> also, does anybody remember when the buildd sudo issue was, even roughly?
<broder> wc -l ~/non-root-files -> 11534
<broder> might require a little more pruning
<wgrant> broder: https://wiki.ubuntu.com/IncidentReports/2011-02-25-Permissions-build-failures?
<broder> wgrant: excellent. thanks
<broder> actually, bdrung's example of audacity was built 4 weeks ago, so it's clearly not fallout from the sudo incident
<wgrant> broder: Link?
<broder> wgrant: https://launchpad.net/ubuntu/+source/audacity/1.3.13-5 is triggering non-standard-file-perm from lintian - http://lintian.ubuntuwire.org/full/pkg-multimedia-maintainers@lists.alioth.debian.org.html#audacity
<broder> there are about 21000 warnings from cases where lintian expects the file permissions to be 0644 but they are actually 0664
<broder> http://web.mit.edu/broder/Public/non-standard-file-perm is the full list
<broder> (that last link is just instances of the lintian warning that are not present in debian's lintian instance)
<broder> wgrant: looks like just about all of those broken uploads happened after precise opened (http://paste.ubuntu.com/736896/), though it's certainly not universal to all builds
<wgrant> broder: Which arches?
<broder> wgrant: i'm just looking at i386
<wgrant> broder: Ah, so most of this are stuff that would have been done by pkgbinarymangler.
<wgrant> pngs/svgs mostly
<broder> oh, good point. i wonder if optipng started screwing up permissions
<micahg> umm, there was a bug last cycle about images having issues with permissions as well...
<wgrant> That's normally a bad umask issue.
<wgrant> So we may have some non-virt builders with the sudo issue still/again.
<wgrant> (LP people have very little visibility into our builders, unfortunately :/)
<broder> fyi http://paste.ubuntu.com/736898/ is just non-png and non-svg
<wgrant> In fact, they're almost all pngs and svgs.
<wgrant> Thanks.
<wgrant> Do those appear in Debian too?
<broder> no, all of these should be unique to us
<wgrant> k
<broder> (assuming i didn't screw up the queries)
<wgrant> Although I think some of these packages are Ubuntu-specific.
<broder> the brother-* ones were uploaded in february, so could be early uncaught fallout from the sudo thing
<wgrant> I thought we caught everything from that, but I was working on second-hand information on which buildds were affected and when.
<broder> right, the incident report says it was first caught 2/25, but the brother-* uploads were 2/20
<wgrant> Hmm.
<wgrant> At least vernadsky and rothera have been bad in the last week.
<wgrant> But there are so few affected builds that it can't really be a general issue.
<broder> ok. you're on your own for cross-referencing builds. the ultimate debian database doesn't have that
<wgrant> I figured :)
<wgrant> Hmm
<wgrant> readline-common is interesting
<wgrant> debian/readline-common.overrides is 664 in both Ubuntu and Debian.
<broder> i...probably didn't filter out overridden tags
<broder> one moment...
<wgrant> No, it's correct.
<wgrant> In the Ubuntu binary it's 664
<wgrant> But in Debian it's 644
<broder> oh, i see
<wgrant> The source is 664 in both.
<broder> though i still think i included overridden tags, though i doubt we have any of those
<wgrant> Hmmm
<wgrant>         cp -p debian/readline-common.overrides \
<wgrant>                 $(d_comm)/usr/share/lintian/overrides/readline-common
<broder> hmm. do you think debian's binaryful upload of readline was for i386?
<wgrant> Hah
<wgrant> That is a good theory.
<broder> looking...
<wgrant> It was.
<wgrant> Architecture: source all i386
<broder> awesome
<wgrant> Perhaps we should check powerpc or something instead. Or do you only have lintian results for i386?
<broder> i only have debian's results for i386
<wgrant> Ah, but it's readline-common, so it didn't matter anyway.
<wgrant> In fact, an awful lot of them are arch-indep packages.
<wgrant> eg debdelta seems to be the same thing.
<wgrant> source.conf is 664 in the source
<wgrant> sources.conf, that is.
<broder> how is cp -p supposed to interact with umask?
<wgrant> Seems to ignore it.
<broder> huh - i'm surprised that we're still triggering issues on images. i see a patch in pkgbinarymangler to deal with that
<wgrant> Yeah, I'm just trying to track that down now.
<wgrant> It's odd.
<wgrant> There are certainly svgs from the last week.
<wgrant> But pkgbinarymangler doesn't do that.
<broder> and the pkgbinarymangler changelog says it was fixed in oneiric
<wgrant> Hmmm.
<wgrant> What is touching the svgs, if not pkgbinarymangler...
<broder> i thought pkgbinarymangler compressed both svgs and pngs
<wgrant> grepping for svg yields nothing.
<wgrant> But I thought the same.
<wgrant> HMm
<wgrant> But gbrainy is on the CDs.
<wgrant> Maybe it has a patch to do it.
<wgrant> Doesn't seem to.
 * broder goes and tries to hunt down old uds discussions
<wgrant> Although it's cdbs.
<wgrant> So who knows what evil is going on there.
<broder> "scour" is the program you're looking for
<broder> ah - pitti created a dh_scour
<broder> https://blueprints.launchpad.net/ubuntu/+spec/performance-desktop-n-install-footprint
<broder> aha - and patched /usr/share/cdbs/1/rules/debhelper.mk
<broder> sneaky
<wgrant> Ahhh
<wgrant> That's why I couldn't find it.
<wgrant> Sneaky indeed :(
<broder> "if grep -q '^Component:[[:space:]]*main' /CurrentlyBuilding 2>/dev/null; then dh_scour -p$(cdbs_curpkg) $(DEB_DH_SCOUR_ARGS); fi"
<wgrant> scour respects umask
<broder> is that a good thing or a bad thing?
<wgrant> gbrainy built on zirconium, which is an ex-lpia builder so I don't trust it at all.
<wgrant> I'd prefer that it preserved the original mode, but I guess it's OK.
<wgrant> Hmmmmm.
<wgrant> Our sbuild has had umask(022) at the top since the incident.
<wgrant> So the sudo config shouldn't matter so much.
<wgrant> Oh
<wgrant> Except yes it does, because sbuild still calls sudo itself.
<wgrant> -rw-rw-r-- 1 wgrant wgrant 113 2011-11-13 15:23 ./deb-specific/pkginfo.inc.php
<wgrant> Looks like fusionforge may be another binary upload issue.
 * wgrant kicks Debian a bit.
<broder> haha
<wgrant> zirconium and roseapple at least have had the scour issue in the last week.
<wgrant> I'll get their sudo checked out on Monday, hopefully.
<wgrant> See if we can blame that.
<wgrant> broder: Is it easy enough to produce http://web.mit.edu/broder/Public/non-standard-file-perm with dates as well?
<broder> wgrant: probably. you want package, filename, date? give me a few to remember how to write sql :)
<wgrant> broder: Version might be handy too, and is probably pretty trivial :)
<wgrant> But I don't know the UDD schema any more.
<broder> yeah, i think i can do this
<broder> wgrant: http://web.mit.edu/broder/Public/non-standard-file-perm-with-dates
<wgrant> broder: Thanks!
<broder> np
<wgrant> It looks like *all* the recent stuff is scour.
<wgrant> Except for two dirs in sip4, and the readline6 issue which probably affects Debian too.
<wgrant> However, what's our policy now on how builds have to cope with umasks?
<wgrant> Since we've changed the default...
<broder> i have no idea
<wgrant> broder: So, I'll get sudo configs checked out this week. I guess we also want a bug against scour (dh_scour seems like it really should preserve the mode), and probably against readline6 and fusionforge in Debian.
<wgrant> For now, at least.
<broder> that all sounds reasonable
<ben_> Does Ubuntu have a place like Debian's WNPP?
<broder> ben_: not generally. we have a needs-packaging tag for bugs for new packages, but since ubuntu doesn't have maintainers in the sense of debian, there's not as strong of a concept of orphaned, etc packages
<ben_> broder: Ok, are there other places besides the WNPP site?
<broder> ben_: what do you mean?
<broder> what are you trying to figure out?
<alkisg> Hi, where can I find the final decision about a UDS session called "FreeRDP and Remmina to replace rdesktop, vinagre and tsclient"?
<alkisg> I'd like to know if remmina will replace vinagre, so that I change my app to take advantage of the default Precice packages
<iceroot> cjwatson: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502  can you have a look here? specially https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502/comments/94  the changelog says that you did the change
<ubottu> Launchpad bug 869502 in linux (Ubuntu) "Kernel-Panic with 3.0.0.12-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)" [High,Confirmed]
<cjwatson> iceroot: You are confused.  The only change I made was to deliver the existing firmware to the installer.
<cjwatson> iceroot: I am not a kernel hacker and cannot help you.
<cjwatson> iceroot: You'll need to ask somebody who actually works on the kernel ...
<Fusionite> Hey
<iceroot> cjwatson: and where did the firmware came before it was inside "linux-firmware"
<iceroot> so that i know where i have to look
<cjwatson> iceroot: I have no idea
<cjwatson> sorry, I really don't have the ability or knowledge to help you here
<iceroot> cjwatson: ok no problem
<cjwatson> the change I made had no effect on installed systems
<iceroot> cjwatson: ok, i was just looking where rt2860.bin is coming from and apt-file told me "linux-firmware", because the bug we are facing comes from rt2860.bin  and i saw a changelog from you about rt-cards, so i asked you
<cjwatson> right, I'm sorry that the changelog was confusing, but my change is not the change you were looking for
<iceroot> cjwatson: ok, thank you for the info
<dr3mro> hello can any one tell me how to merge bazzar branch into trunk ... i own the branch but i am not a amember of trunk
<tumbleweed> dr3mro: that's pretty OT for this channel. But if you don't have permission to write to the trunk, then you can't do the merge. You could create a proposal on launchpad, though
<dr3mro> create a proposal is what i look for but how ?
<tumbleweed> push the branch to LP, and click on the button on it's page, labelled Propose for mering
<broder> hmm. the rsync daemon on one of the archive.ubuntu.com servers (91.189.92.170) seems to be down. who do i contact about that?
<tumbleweed> broder: you should be using rsync.archive.ubuntu.com (although both hosts in archive.ubuntu.com also appear in rsync.a.u.c)
<tumbleweed> generally #ubuntu-mirrors for this kind of issue
<lifeless> ok, semi random question tinme
<lifeless> is launchpadlib included on the Ubuntu installer CD these days ?
<JackyAlcine> lol
<lifeless> broder: #canonical-sysadmins if I remember the channel name correctly
<lifeless> broder: or #ubuntu-mirrors
<infinity> lifeless: Which lplib bits are you looking for?
<infinity> lifeless: But if you check apt-cache, you'll note that liblaunchpad-integration-3.0-1 (for instance) is in every *-desktop seed.
<lifeless> infinity: python-launchpadlib
<infinity> adconrad@cthulhu:~$ apt-cache show python-launchpadlib | grep ^Task
<infinity> Task: cloud-image, ubuntu-desktop, server, ubuntu-usb, kubuntu-desktop, kubuntu-mobile-desktop, edubuntu-desktop, edubuntu-usb, xubuntu-desktop, mythbuntu-backend-master, mythbuntu-backend-master, mythbuntu-backend-slave, mythbuntu-desktop, mythbuntu-frontend, lubuntu-desktop, ubuntustudio-desktop
<lifeless> thanks
<broder> tumbleweed: hmm, ok. debmirror defaults to archive.ubuntu.com (i'm not actually specifying it explicitly). i'll file a bug
<tumbleweed> broder: is rsync the default method?
<broder> hmm, no it's not
<tumbleweed> although I know it does always rsync some extra bits, unless you tell it not to
<tumbleweed> but those are small enough, that the load shouldn't be problematic on a.u.c
<broder> what's the difference between r.a.u.c and a.u.c? it looks like all the same IPs
<tumbleweed> broder: r.a.u.c is a much bigger pool
<broder> really? the pool looks exactly the same from where i am
<tumbleweed> I only see two IPs in a.u.c
<broder> yeah, i used to, but i just started seeing 6
<tumbleweed> but then US, is problematic, because you don't have ab ig countrywide mirror
<tumbleweed> ok, yes 7 here now
<broder> from here, us.a.u.c, rsync.a.u.c, and a.u.c are all the same set of IPs
 * broder shrugs
<tumbleweed> broder: hrm, found the mail where rsync.releases.ubuntu.com was announced and we were asked to use it, but that was private, not on a list. Can't find anything mentioning rsync.archive.ubuntu.com. Maybe I just discovered it existed and started using it
<lool> Hmm I'm getting an upload error to a PPA
<lool>   Uploading powertop-1.13_1.13-1ubuntu2_source.changes: 1k/2k550 Changes file must be signed with a valid GPG signature: Verification failed 3 times: ['General error', 'General error', 'General error'] : Permission denied.
<lool> gpg --verify works on the .changes file
<lool> and on the .dsc
<lool> ah intermittent Launchpad bug apparently
<micahg_> yeah, that's an old bug
<BiosDestroyer> Take care all
#ubuntu-devel 2012-11-05
<skunk> whats the Ubuntu software centre written in??
<skunk> sorry was that a bad question??
<TheMuso> Whoo! Chroot tarball corruption on armel raring. :(
<infinity> TheMuso: It's not the tarball, it's the buildd.  Let me go abuse it.
<pitti> Good morning
<jk-> hi pitti
<dholbach> good morning
<dholbach> doko_, maybe you can help me? with the new libxml2 in experimental we should be able to get back in sync again, but it FTBFS in raring (http://paste.ubuntu.com/1334247/). it seems to build in debian, also using binutils-gold - I'm not quite sure where to go from here - is this something we should fix in debian/ubuntu or something which should be forwarded upstream? Do you know which compiler version or flag might be responsible for the erro
<dholbach> r so they know how to reproduce it?
<dholbach> ^ or anyone else really :)
<doko_> dholbach, a verbose build log maybe would already help ...
<dholbach> doko_, the normal raring build log?
<mitya57> hi cjwatson
<mitya57> ScottK thinks we should re-add essential flag to python-minimal
<mitya57> (which was reverted by you): https://code.launchpad.net/~mitya57/ubuntu/raring/python-defaults/resync/+merge/131193
<pitti> mitya57: why that? I thought it was spelt "python3" now
<mitya57> pitti: "You can't remove essential until it's been verified nothing in the archive assumes it's present."
<doko_> dholbach, no, that silent too ...
<mitya57> I hope cjwatson will now say he has verified that somehow :)
<dholbach> doko, can you help me understand what you'd need?
<doko> dholbach, compiler flags, linker flags, ...
<mitya57> hi dholbach, doko
<dholbach> hi mitya57
<mitya57> maybe one of you can sponsor the new sphinx?
<mitya57> (I mean my debdiff at bug 1070336)
<ubottu> Launchpad bug 1070336 in sphinx (Ubuntu) "Sphinx FTBFS in raring (again)" [High,In progress] https://launchpad.net/bugs/1070336
<cjwatson> mitya57: I'd be happy to argue with ScottK about this directly; it seems a bit daft to do so by proxy
<cjwatson> mitya57: I'll follow up in the MP
<mitya57> cjwatson: thanks
 * cjwatson finally moves auto-sync from cron.cjwatson to an actual crontab entry
<cjwatson> only about eight years late
<jamespage> cjwatson: is syncpackage use into raring-proposed safe? I see the minor thread on ubuntu-devel ML but it was unclear to me whether the log changelog was OK or not?
<jamespage> log/long
<cjwatson> jamespage: there's some problem on the LP side; if you have ubuntu-dev-tools << 0.143ubuntu0.1 then it'll produce wrong output in your terminal, but that doesn't really matter
<cjwatson> bug 1073492 is the LP bug
<ubottu> Launchpad bug 1073492 in Launchpad itself "Sync changelog doesn't include all changelogs between release version and new Debian version" [High,Triaged] https://launchpad.net/bugs/1073492
<cjwatson> I wouldn't block on that for now if I were you; go ahead and sync stuff where appropriate
<jamespage> cjwatson, great - thanks
<xnox> dholbach: doko is after a build with VERBOSE=1 set, such that the build-log is about 3-4 times longer than the current one. The information as to why it is failing, is currently hidden.
<cjwatson> isn't it V=1?
<cjwatson> looks like automake at least
<cjwatson> (cf. Debian #680686)
<ubottu> Debian bug 680686 in debhelper "pass --disable-silent-rules to configure by default" [Important,Open] http://bugs.debian.org/680686
<xnox> cjwatson: yes, it's V=1 & VERBOSE=1 in CMake.....
<xnox> cjwatson: yes, it's V=1 for autotools & VERBOSE=1 in CMake.....
<dholbach> xnox, in http://paste.ubuntu.com/1334398/ I used --disable-silent-rules now
<xnox> dholbach: I like how make is in Deutsch and gcc in English in that build log =)
<dholbach> haha
<xnox> doko: here is a verbose log for you http://paste.ubuntu.com/1334398/ I don't see anything suspicious and -fPIC is used.....
<rbasak> xnox: sorry I didn't manage to make the bibisect session. Have you considered the apt by-hash stuff? Then you'd just need to keep the hash of InRelease (when we have it) and alter expiry of old files. Perhaps with a (possibly internal) redirect to take you from a "dated" URL to the correct InRelease by-hash, and then apt should Just Work with it
<rbasak> (and debootstrap too)
<rbasak> although that would add a dependency on the by-hash stuff, so perhaps that's a reason not to use it
<xnox> rbasak: I was not at the bibisect, nor at the apt-hash session. I was at the "keep the snapshot" session only.
<rbasak> (on me completing the by-hash stuff)
<xnox> rbasak: I am not sure what the by-hash stuff is =) the current "implementation" I have for the snapshots I have is to simply rsync-snapshot the dists/ & proxy redirect pool/ to launchpadlibrarian.
<xnox> rbasak: is there anything concise I can read about the by-hash stuff?
<rbasak> xnox: https://wiki.ubuntu.com/AptByHash
<rbasak> xnox: I'm hoping to have it done by Raring FF
<rbasak> xnox: progress so far is a PoC that works with a patched apt in a PPA
<xnox> rbasak: interesting stuff. If the hashes are kept for the past month with a proxy to launchpad librarian beyond that horizon we are golden for full snapshots archive.
<rbasak> xnox: exactly - snapshot capability just falls out of the design. I'm not sure about the proxy to launchpad librarian for > one month though. What would be doing about the index files?
<xnox> rbasak: are you running a PoC mirror anywhere with this stuff already on continuous basis? or just locally.
<rbasak> xnox: I was running one but I turned it off when it got postponed last cycle
 * rbasak looks
<rbasak> Argh
 * rbasak reinstalled his phone today, and just realised that he's lost all his Google Authenticator setups
<xnox> rbasak: well we need to keep dists/ snapshots in by-hash/ or by-date/ dirs. But the files in pool/ are expired and redirected to launchpadlibrarian via smart proxy upon request.
<rbasak> No AWS for me today then :-/
<xnox> =(
<rbasak> There was a mirror in S3. Let's assume it's not there right now, but I'll get it going again soon
<rbasak> Ah OK. Yeah - as long as we keep the indexes around that'll work. I like the idea of deferring to launchpadlibrarian instead of keeping the packages around forever
<Laney> launchpadlibrarian isn't guaranteed to keep all files around forever
<cjwatson> no, but it does keep them for the lifetime of the release
<cjwatson> not guaranteed by code but guaranteed by process
<xnox> rbasak: and if dists will keep on growing forever, but we can implement round-robin expiry e.g. similar to how pnp4nagios does it. Keep dists 0.5 for the past 2 weeks, keep dailes after that for 3 months, then weeklies... etc. And redirect expired dists to the closes new one.
<xnox> where "0.5" is "0.5 hour"
<xnox> although we might not want to play with time that much.
<rbasak> Sure. Just decide what the expiry algorithm is and we can implement it :)
<xnox> rbasak: I like the "wait until we are running out of disk space and see how can we expire the least amount of stuff while maximizing usefulness"
<cjwatson> you might also consider proxying large objects in dists/ such as installer uploads somehow
<cjwatson> the custom tarballs that are unpacked into that should be somewhere in the librarian
<cjwatson> that would require a somewhat more intelligent proxy though
<rbasak> xnox: my PoC is in S3. I'm not sure if we can detect when S3 is running out of disk space :-P
<xnox> rbasak: hmm... yeah expiring a bucket may be drastic if we are not careful what we put in it.
<cjwatson> nobuto: Would you mind merging mozc?  uim is stuck in raring-proposed because it makes versions of uim-mozc earlier than 1.5.1090.102-4 uninstallable.
<cjwatson> nobuto: (Or let me know if you don't have time and I can do it)
<nobuto> cjwatson: if syncing from debian experimental, no merge will be needed. the patch has been upstreamed. but I will contact the maintainer in Debian to confirm it's OK.
<ScottK> cjwatson: No need to argue about python-minimal.  You dropping it with intent is different than it being dropped in an upload that I was considering sponsoring.
<cjwatson> nobuto: OK, either way is fine by me, though I know nothing about the safety of mozc in experimental
<cjwatson> ScottK: cool
 * cjwatson grumbles in the general direction of bison
<cjwatson> DFSG-cleaning that breaks autoreconf considered annoying
<nobuto> cjwatson: OK, I will double check that.
<pitti> doko: hm, I'm slightly puzzled by https://launchpadlibrarian.net/121262133/buildlog_ubuntu-raring-i386.ubuntu-drivers-common_1%3A0.2.71build1_FAILEDTOBUILD.txt.gz
<pitti> doko: "/bin/sh: 1: python3.2: not found", how can that be? it depends on python3-all, and fails with that on i386 and armhf only (works on other arches)
<pitti> doko: is/was that something transient?
<xnox> pitti: I don't see it depending on python3-all
<pitti> oh sorry, looked at the wrong version
<pitti> doko did add the -all dep in https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.71ubuntu1
<pitti> and that built fine
<doko> pitti, I do love these shell script style makefiles :-/
<xnox> ack.
<pitti> doko: yeah; if only debhelper supported py3 properly..
<pitti> so, that leaves the question of what failed in ubuntu1
<doko> it doesn't try to install python2
<pitti> doko: as I said, I was looking at the wrong log; you already fixed this error in ubuntu1
<doko> ahh, ok
<pitti> ev: btw, I was talking to seb128 about sending crashes to daisy only -- he says that he depends a lot on having direct submitter contact/feedback, so I think we shouldn't do this just yet
<kumadasu1> Hi. I want to apply this patch to chromium-browser in local build.  http://code.google.com/p/webrtc/issues/detail?id=512
<kumadasu1> But I don't know how to apply patch.
<ev> pitti: okay, at what point would you like to re-evaluate that? When we have the server-side hooks implemented?
<stgraber> @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 dicussion 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: stgraber
<ev> Or perhaps taken from a different angle, why do we want direct submitter contact?
<kumadasu1> chromium-browser's sorce code is compressed and
<ev> and can we eliminate the need for that over the medium term
<pitti> ev: yes, I think having the extra scripts feature is a minimum requirement for that
<ev> okay, cool
<pitti> ev: which might be sufficient in a lot of cases, but due to the nature of GUI bugs even those might not be sufficient in a lot of cases
<pitti> seb128: ^ was there anything else?
<pitti> I think so, but I might have forgotten (post-party morning..)
<seb128> ev, pitti, mpt: was there any consideration to have an text entry on the dialog? to let user optionally put a description of what they were doing when the issue happened
<seb128> that's what firefox is doing
<ev> yes
<ev> seb128: it's on the list of work items for 13.04
<seb128> ok
<seb128> well I guess we should reconsider once that happens
<ev> if you hit "show details" you'll have an optional box to add some details
<seb128> without description it's just too hard to figure how to reproduce issues
<seb128> hum, hidden in "show details"? I'm not sure anyone will go find it there :-(
 * didrocks doubts about it too
<ev> well, we've only briefly talked about the UI for this. But the belief is that technical people, the kind who you'd want to provide a description, would be hitting show details anyway
<ev> at least the one time it would take them to realise it was there
<ev> and do recall we're operating at scale
<ev> out of 800 instances of a crash, someone is bound to enter something there
<ev> speculation, of course
<ev> we can always see how it goes
<seb128> well, firefox has it in the main ui
<seb128> looking through some of their bug, 90% of descriptions are useless but you get infos from the other 10%
<ev> but I'm worried about putting it in the main UI as I think anything that makes the dialog look more complex is going to scare away some people from hitting submit
<seb128> well, people don't need to hit submit
<ev> mpt: you might be interested in this conversation :)
<ev> seb128: why don't they?
<seb128> the way it's currently designer it sends the report even if you close the dialog
<seb128> you would need to uncheck the checkbox to not send it
<seb128> and I guess users who get scared by the dialog just close
<ev> oh I see your point
<ev> by the way, the fact that the dialog has a close button at all is a bug
<ev> it's supposed to just be minimise
<seb128> well, any of the buttons at the bottom would send the report
<seb128> so even if users don't read the content and click on any of those it would send the report
<ev> indeed, that was just an aside
<seb128> to go back to the topic, I think we need to keep launchpad submit by default until we get useful descriptions from e.u.c
<ev> yes - I don't want to rip out anything that you find useful
<seb128> I will let mpt and you figure the ui that leads us there ;-)
<ev> but hopefully we'll get those useful descriptions soon
<ev> seb128: cheers :)
<pitti> I guess the server and foundation guys will/should be happier with the "run extra scripts" possibility
<seb128> pitti, the extra script thing will be useful without doubt
<seb128> it's a bit orthogonal to the description though
<pitti> can these be interactive?
<pitti> so for desktop we could use a dialog which asks for more information, or some messages like "now reproduce the problem and click ok", or something such?
<pitti> ev: ^ I think I already asked you taht
<pitti> but it might have been rejected in design already
<ev> no
<ev> as in no I really don't want them to be interactive
<ev> for a number of reasons which I'm happy to enumerate
<ev> but lets see where we get without them being interactive first
<seb128> it's a bit tricky, I doubt you will be able to get some infos without those being interactive
<seb128> like you can't really go and fetch private infos without asking the user
<ev> the interactivity we currently have is confusing at best for non-technical people
<jbicha> ev: can we not kill all the close buttons? some users get really annoyed when we do that (like in Software Updater)
<seb128> count me in the "hate that I can't close the "you need to reboot""
<ev> seb128: fetching private information will be covered by the text in the initial dialog, though admittedly we don't have a mock up for that yet
<seb128> I right click the unity launcher icon to do it but it's a workaround
<ev> but we're definitely going to have implied consent there
<ev> jbicha, seb128: what if we mapped escape to "dismiss this dialog with the default action (send report)" ?
<ev> I also think that a lot of these changes layer on top of each other. When we fix the system errors so they get collected into a single dialog, hopefully the frequency you'll see this will go down and your need for a quick dismiss action will decrease
<ev> equally so when we add the "don't bother me again with this - just send the damn reports" ;) checkbox
<stokachu> mterry: does pcreate recognize raring yet?
<seb128> ev: not sure about that, I would expect esc to "undo" the action, e.g exit without submitting anything
<ev> hmm, yeah
<mterry> stokachu, it relies on underlying tools, it doesn't know about code names itself
<stokachu> mterry: ah, so debootstrap needs some modification
<pitti> ev: during the devel cycle we can/have to assume some degree of "technical people", though
<mterry> stokachu, yeah, I don't think quantal debootstrap is updated yet...
<ev> pitti: sure - how does that fit into the current conversation? Sorry, I'm just not making a clear connection there.
<stokachu> mterry: yea i dont even see it in devel branch
<jbicha> what about if we had different modes: 1. send crash reports automatically without getting asked every time (but with the ability to click a button to view the reports you've sent); 2. Ask me first so I can include additional info or decline to send the report 3. Don't send crash reports & don't notify me of crashes
<Laney> it's in the q-proposed queue
<pitti> ev: that was re "ev | the interactivity we currently have is confusing at best for non-technical people"
<Laney> (debootstrap)
<stokachu> Laney: does this require a sru for precise as well?
<Laney> if it's to be updated there, yes
<ev> pitti: oh, I see. Well, the intent is to have these server-side hooks on post-release.
<ev> and I think we end up with a lot of complexity if we're trying to maintain two sets - one for before release and one for after
<Laney> stokachu: it's trivial if you want to do it; just adding a symlink raringâgutsy
<stokachu> Laney: ok, would it be a good idea to just update all scripts across the releases?
<stokachu> Laney: ok i can do that
<ev> I'd really like to get them implemented without interactive UI and see what the remaining cases are where we need some human interaction, then address those specifically
<jbicha> ev: people expect pre-release to be "buggy"; I hear regularly about people that think precise is more buggy than oneiric because of the popups
<Laney> use bug #1068707
<ubottu> Launchpad bug 1068707 in debootstrap (Ubuntu Quantal) "Add raring as a symlink to gutsy" [Undecided,Confirmed] https://launchpad.net/bugs/1068707
<stokachu> Laney: awesome thanks ill get that updated
<pitti> ev: *nod*
<ev> jbicha: I don't think people should ever expect our software to be of poor quality. Our whole push at the moment is towards a rolling release
<ev> something that's stable throughout
<ev> sorry, I don't think we should ever settle for people expecting it to be buggy
<ev> I also think we make things harder for ourselves if we let things slide towards instability with the promise that we'll clean up the mess eventually
<jbicha> ev: people interpret those popups as "buggy"; I think defaulting from 2 to 1 closer to release is a good thing
<ev> jbicha: I did not understand the second half of your sentence. Can you elaborate, please?
<jbicha> and we can't make promises about Ubuntu being stable during the Alpha phase
<pitti> ev: yeah, that was the "old" mode indeed, and we haven't been good at it given the constant feature pressure
<ev> why can't we make promises about it being stable during development (there are no more alphas)
<jbicha> ev: see my previous 3-mode comment
<ev> pitti: *nods*
<pitti> but now that pressure has shifted around, and we have a lot more machinery in place to avoid regressions; I'm hopeful we can improve that enough to really make the dev release "stable"
<ev> yeah, me too
<ev> really excited as well
<ev> there's so much potential and good ideas here
<jbicha> ev: because then we land features at the last possible minute because we are too paranoid about regressions which makes the releases *worse* because they didn't get time to be tested in the actual repositories
<pitti> well, they land two weeks after the last possible minute right now
<jbicha> there definitely is an Alpha stage still as long as we have autosyncs from Debian
<ev> jbicha: so the dialogs serve two purposes
<pitti> that can't possibly get any worse
<ev> one is to let the user report the issue to us, and that's great
<ev> but the other and equally important need is that they actually explain what just happened
<ev> there are a lot of non-technical people out there who don't know what an application disappearing means
<ev> they need some further explanation
<ev> and that's what the dialog does
<cjwatson> jbicha: putting those through -proposed is already making a rather big difference
<ev> plus turning on automatic reporting requires some sort of initial consent anyway
<jbicha> ev: like the Amazon integration requires initial consent? ;)
<stokachu> zing!
<ev> jbicha: pretty sure you at least get a link of some legal text to read there
<jbicha> checkbox in the installer "Help us make your Ubuntu experience better" :)
<ev> and for the millions who are already using Ubuntu? :)
<ev> believe me
<jbicha> checkbox in the upgrader :)
<ev> I'd love to see lots of machines automatically sending us reports
<ev> but I think there is a real need here for some explanation
<ev> and for the technical people who don't want to see these dialogs, we'll have a very easy way to turn on automatic reporting in 13.04
<stokachu> it doesn't automatically send kernel dumps though right
<ev> it doesn't automatically send anything right now
<ev> everything puts up a dialog that carries with it your implied consent to send us the information
<ev> we're reducing the number of dialogs as well, for those of you who weren't in the plenary or were watching at home as I crashed the live stream
<ev> sorry, wearing that like a badge of honour, but I'm most amused
<stokachu> ev, is there something that detects if it is a kernel dump and explains possible security implications?
<jbicha> maybe we should keep track of how many turn on automatic crash reporting so that we can get an actual sample size for our bugs/install ratio
<ev> stokachu: https://wiki.ubuntu.com/ErrorTracker#kernel-crash
<ev> jbicha: we will
<stokachu> Laney: is debootstrap out of sync with bzr and whats being released?
<ev> I'm all about measuring, and you can rest assured that we'll have a percentage of systems that report crashes which have done so automatically
<Laney> stokachu: it would not surprise me; I didn't use bzr myself
<cjwatson> debootstrap has never been maintained in bzr
<Laney> UDD bzr presumably
<cjwatson> any resemblance there is probably coincidental
<stokachu> so when im doing patch work i was under the impression i always pull from latest bzr in launchpad
<cjwatson> it often doesn't work desperately well for SRUs ...
<cjwatson> you should always double-check versions against rmadison output or LP
<cjwatson> if UDD bzr is in sync, great, otherwise do something else
<stokachu> cjwatson: thats kind of confusing dont you think?
<cjwatson> Yes
<cjwatson> I'm stating current reality
<stokachu> lol ok
<cjwatson> If we had any resource to polish UDD properly, it'd be different
<stokachu> no problem ill just adjust my workflow
<stokachu> ev: this dialog just says it experienced an internal error, but doesn't say anything about if its a kernel dump that could be 50 gigs and that you are sending what was currently dumped in memory
<stokachu> i dont think financial instituations would want that whether it be desktop or server
<stokachu> or governments.. or ninjas
<mfisch> How long should it take for UDS-R tasks to show up on status.ubuntu.com/ubuntu-raring/people.html  ?
<stgraber> mfisch: status.u.c should be mostly up to date after FeatureDefinitionFreeze
<mfisch> stgraber: thanks
<ev> stokachu: you may not be sending the dump if we already have one for that signature. Institutions can completely disable error reporting if they don't want sensitive information leaking out (Google and Ericsson do this).
<stokachu> ev: but that disables for everything, couldnt we have a blacklist?
<stokachu> and maybe have kernel set as a default
<ev> stokachu: we want kernel crashes.
<stokachu> ev: oh is it just stack traces sent and not actual core dumpes
<stokachu> dumps*
<ev> no - a subset of the systems are sending us core dumps.
<stokachu> ev: but not kernel?
<ev> sensitive information is possible in an application crash too
<ev> disabling crashes system wide is the right thing to do if you're a company that cares about these sorts of things
<ev> we don't have kernel crashes full wired up yet. When they are, a subset of the systems out there will be sending the full dumps, yes.
<ev> do note that we don't even get a lot of those
<ev> the conditions for actually being able to write a kernel crash to disk mean that they're not going to ever approach the frequency of regular application crashes
<stokachu> ok
<doko> bah, hard disk shows I/O errors again ...
<diwic_> ev, I'm looking at a stack trace @ errors.ubuntu.com. The error is present in several versions of pulseaudio - from which version are the actual stack trace - line numbers differ between releases?
<ev> diwic_: oh interesting
<ev> so we don't currently track that
<ev> give me one moment to just see if we can easily grab it given the information we have
<diwic_> ok
<stokachu> Laney: ok i uploaded a debdiff to that debootstrap bug
<Laney> cool cheers
<Laney> can you subscribe the sponsors?
<Laney> i'll try to look in a bit anyway
<stokachu> Laney: yea i got sponsors and sru subscribed so it should be int he queue
<_val_> Hey guys. When are you going to release a spice-xpi package? Compiling this the source of spice-xpi gives me head ache. Someone?
<stokachu> Laney: thanks :D
<_val_> the xulrun-embedder.. not found... etc.. is not solveable.
<stokachu> _val_: did you see this https://launchpad.net/spice-xpi
<jpds> _val_: spice-client in quantal?
<_val_> stokachu: looking at it
<seb128> what's the status of autosyncs for r?
<_val_> jpds: I meant the precise
<cjwatson> seb128: enabled
<_val_> I need the precise build
<cjwatson> seb128: in fact they're now fully automatic rather than in cron.cjwatson
<cjwatson> seb128: are you looking for something in particular?
<seb128> cjwatson, no, just not being fully awake, I was looking at http://people.canonical.com/~platform/desktop/desktop.html but we didn't change the serie so it's listing quantal versions ...
<cjwatson> heh, ok
<seb128> sorry for the noise ;-)
<seb128> cjwatson, good to read that syncs are fully automatic now though ;-)
<pitti> indeed
<pitti> cjwatson: btw, my anxiety is gone: http://people.canonical.com/~ubuntu-archive/testing/raring-proposed_probs.html actually is non-empty :)
<cjwatson> heh, yeah, it is occasionally
<cjwatson> that one should clear shortly
<pitti> my hands are itching to graphviz-ify http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<pitti> but that's not straightforward, one needs more info than on that page to get the dependencies apparently
<Laney> oh, I should proposedify ben really
 * Laney slots that into the todo
<pitti> or there just are not any excuses due to uninstallability
<stokachu> _val_: you can get the source from launchpad and rebuild for precise and fix any errors there
<pitti> Laney: qu'est-ce que c'est "ben"?
<pitti> another magic archive status tool?
<Laney> transition tracker
<stokachu> stgraber: could i get bug 423252 put under the libgcrypt11 package it is currently set to sudo
<ubottu> Launchpad bug 423252 in sudo (Kairos Linux) "NSS using LDAP+SSL breaks setuid applications like su, sudo, apache2 suexec, and atd" [High,Confirmed] https://launchpad.net/bugs/423252
<stgraber> stokachu: hmm, I see it already has a libgcrypt11 task, what exactly do you mean with "put under"?
<stgraber> stokachu: when only accessing by bug number instead of the full URL LP seems to be taking some random task (or maybe the first?), but accessing the bug with https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/423252 should give you the right view
<ubottu> Launchpad bug 423252 in sudo (Kairos Linux) "NSS using LDAP+SSL breaks setuid applications like su, sudo, apache2 suexec, and atd" [High,Confirmed]
<stokachu> stgraber: ok i just didnt know b/c it says in "sudo"
<stokachu> stgraber: i guess it doesn't matter?
<stgraber> stokachu: apparently somebody added a sudo task for Debian to that bug and ubottu is using that one when you mention the bug on IRC, that's all
<stokachu> stgraber: ok no worries then
<achiang> are auto-syncs from testing, unstable, or experimental?
<carif> #ubuntu-devel, I submitted a merge proposal for lp 967229, just wanted to confirm that someone can review it
<ubottu> Launchpad bug 967229 in plymouth (Ubuntu) "Text mode shown briefly with various "cryptic" texts when logging out or shutting down" [High,Triaged] https://launchpad.net/bugs/967229
<cjwatson> achiang: unstable
<achiang> ta
<cjwatson> achiang: we may go back to testing for the next LTS cycle (14.04); OTOH we may not if our own stability protections are working out well enough by then
<cjwatson> achiang: experimental is right out :)
<achiang> cjwatson: heh, ok. i'll ask motu to sync a small package of mine from experimental. :)
<cjwatson> sure - with syncs being self-service there isn't much reason to put lots of effort into selective auto-syncing from experimental or what-have-you
<ogra_> cjwatson, did you ever try that raring update on your nexus you asked about ?
<achiang> ah, that makes sense.
 * ogra_ is curious if it survived
<cjwatson> 14:32 <cjwatson> ogra_: I upgraded my nexus7 to raring (after pinning the ubuntu-nexus7 PPA) and found that Unity failed to start because the runtime linker failed to find libnvwsi.so for
<cjwatson>                  /usr/lib/nux/unity_support_test, even though /usr/lib/nvidia-tegra still seems to be in ld.conf.d and that library is there.  I worked around it for now by symlinking that library into
<cjwatson>                  /usr/lib/arm-linux-gnueabihf/, but I assume that's wrong.  Is this known?
<cjwatson> 14:32 <cjwatson> (There was also an onboard regression with python3.3, and I just uploaded a backport of the upstream fix for that)
<cjwatson> ogra_: ^- results
<ogra_> oh, thx !
<cjwatson> so the verdict is "almost"
<ogra_> yeah, thats a bug in the nvidia package the libs have no SONAMEs
<ogra_> i guess the linker ges confused by that
<ogra_> *gets
<cjwatson> um, right, but I didn't notice those packages changing from quantal to raring
<achiang> ogra_: i thought there was a fix for that?
<ogra_> achiang, only for tegra2
<cjwatson> unless glibc 2.16 is stricter
<cjwatson> I didn't try to narrow it down much further
<achiang> ogra_: do you have a bug for tegra3? i can escalate to nvidia
<ogra_> achiang, nope, i'll create one but ebroder is fully aware of the issue
<ogra_> he was the one who got me the tegra2 rebuild, and promised me tegra3 would be fixed in their next release
<ogra_> cjwatson, i'm pretty sure you simply got the tegra3 package from raring, the PPA one has a .links file to work around the issue ... linking all libs to /usr/lib, i was a bit reluctant to push that into the official archive
<achiang> ogra_: got it, thanks
<achiang> ogra_: i think you meant e. brower, not ebroder :)
<ogra_> err, yesw
<ogra_> heh
<cjwatson> ogra_: let me unpack my nexus7 and check
<ogra_> downgrading to the PPA package would fix it in that case
<achiang> cjwatson: you mean it's not your primary dev machine yet?
<Laney> what's the full package name?
<ogra_> i should probably just upload the hack to raring ... as ugly as it is it helps atm
<Laney> nvidia-graphics-drivers-tegra3?
<ogra_> Laney, yep
<cjwatson> ogra_: I pinned the entire PPA, so I'm sceptical about that answer
<Laney> I don't have that installed at all
<ogra_> binary is nvidia-tegra3
<Laney> ah
<cjwatson> achiang: :-P
<Laney> ubuntu@nexus7-bisquicks:/usr/lib/arm-linux-gnueabihf$ dpkg -L nvidia-tegra3 | grep libnvwsi
<Laney> /usr/lib/nvidia-tegra/libnvwsi.so
<Laney> /usr/lib/1libnvwsi.so
<ogra_> EEEK !
 * Laney giggles
<ogra_> oh dyslexia !
<achiang> lol "bisquicks"
<ogra_> haha, yeah
 * Laney is quite pleased with that
<achiang> sadly, we are going to roll the image again to change that due to http://goo.gl/826tPall and http://pad.lv/1072086
<ubottu> Launchpad bug 1072086 in ubuntu-nexus7 "Having random hostnames can result in offensive hostnames" [High,Fix committed]
<ogra_> well, we probably want a fix for that typo above as well :)
<Laney> achiang: first one doesn't work
<ogra_> though i dont get why that would affect release upgrades
 * Laney reboots hopefully into R ...
<achiang> Laney: someone out there got nexus7-m*****f*****
<achiang> oh, the correct link was http://goo.gl/826tP
<Laney> aha
<Laney> I was going to suggest a wind-up, but the phrasing there makes me think it is not
<stokachu> achiang: lol
<cjwatson> ogra_: for the record, "tegra" appears nowhere in dpkg.log for the day I did the upgrade
<ogra_> ok
<cjwatson> ogra_: also, I wonder if there's a general robustness problem here; it seems kind of odd for a failure in unity_support_test on a system with no non-unity fallback to result in a blank screen rather than some attempt at a usable desktop
<ogra_> cjwatson, well, libnvwsi.so is fixed now, just uploaded to the PPA
<cjwatson> great, thanks
<ogra_> oh, there definitely is
<ogra_> and i think that was also discussed in some desktop session
<ogra_> so i think i should upload the same "fix" to raring for now
<stokachu> stgraber: could i get bug 1013798 nomination approval?
<ubottu> Launchpad bug 1013798 in libgcrypt11 (Ubuntu) "Blink SIP client segfaults with libgcrypt11 1.5.0-3ubuntu0.1" [Critical,Confirmed] https://launchpad.net/bugs/1013798
<stgraber> stokachu: done
<stgraber> stokachu: no oneiric?
<stokachu> stgraber: sure i can do oneiric too
<stokachu> stgraber: ok nominated oneiric
<stgraber> stokachu: and approved. thanks!
<stokachu> thank you :D
<stokachu> pitti: is there any other information you require to have bug 1036834 approved for precise?
<ubottu> Launchpad bug 1036834 in gdb (Ubuntu Precise) "[FFe] gdb should be marked "Multi-arch: allowed"" [High,In progress] https://launchpad.net/bugs/1036834
<cjwatson> Laney: haskell-persistent now requires haskell-devscripts from experimental; should haskell-persistent be reverted, or should we upgrade haskell-devscripts?
<Laney> cjwatson: Those version constraints are artificial to get packages built against the experimental ghc
<cjwatson> Which doesn't work in Debian either AFAICS, judging from buildd.debian.org ...
<Laney> someone accidently uploaded to unstable.
<cjwatson> OK, so that should be reverted?
<Laney> which is about as fun as you can imagine
<Laney> did anything build against it?
<cjwatson> I doubt it since it failed to build
<Laney> oh, yeah, that works. So you can revert for now if you like, but I plan on (harassing iulian to) uploading the new stack soonish.
<cjwatson> New stack or not I'm trying to keep britney update_output as clear as possible
<cjwatson> Even if that involves more uploads than long-term necessary
<Laney> hmm, how did nomeata do the binNMUs?
<Laney> some of the packages must have been uploaded without the bumped BD
<Laney> so I suspect there's some uninstallability in raring if that stuff got autosynced
<cjwatson> in raring-proposed
<Laney> yeah
<cjwatson> So haskell-persistent 1.0.1.3-1+really0.9.0.4-2ubuntu1?
<cjwatson> or is it just a matter of reverting the haskell-devscripts bit?
<Laney> I'd do a test build and see if you get back to the same ABI hash we had before
<Laney> if not then you might as well push on
<cjwatson> We won't because of haskell-unordered-containers
<mlankhorst> guess it's too soon to attempt a upload just to test if it works?
<cjwatson> Which I've been rebuilding for today
<Laney> so the only concern is if it breaks API and so requires changes to other packages
<Laney> did you find any other sourceful changes required?
<cjwatson> Not so far
<Laney> good
<cjwatson> haskell-persistent looks like API changes to me although I don't really know the difference
<cjwatson> Some changes to function signatures and the like; no idea what counts as API
<cjwatson> Though the diff is only 1250 lines
<cjwatson> But then, it fails for other reasons; no libghc-monad-logger-doc
<Laney> I expect the ' functions are internal, but don't know for sure
<Laney> maybe it's best to go back :-)
<cjwatson> I think this is just buggered and we should revert and then rebuild rdeps
<Laney> hmm
<Laney> will have to make sure that we don't miss it next time then
<Laney> I suppose any breakage will make itself known
<cjwatson> 1.0.1.3-1+really0.9.0.4-2build1 perhaps?
<cjwatson> To preserve autosynciness
<Laney> yeah
<Laney> perhaps I'll upload it to exp anyway
<Laney> sigh
<Laney> nobody made any real attempt to clean up after the mistaken uploads: http://packages.qa.debian.org/h/haskell-persistent.html
<cjwatson> Actually, that would be a different upstream tarball wouldn't it
<cjwatson> And not actually << 1.0.1.3-2
<mlankhorst> Laney: when does everything get set up? :-)
<Laney> everything?
<mlankhorst> erm for ubuntu membership i mean
<cjwatson> YM upload permissions?
<Laney> oh well I can add you to ubuntu-dev now
<Laney> someone on the TB will need to push buttons to give you the PPU though
<mlankhorst> oh sure
<stgraber> mlankhorst, Laney: I'll try to take care of creating the packageset today. micahg said he'd create the team, once that's done I can grant that team upload rights to the packageset and you'll be good to go
<Laney> oh, yeah, we did a team didn't we
 * Laney deactivates the direct membership again :P
<Laney> stgraber: I made ubuntu-xorg-dev
<mlankhorst> yay
<stgraber> Laney: thanks. I'll take care of the rest after lunch
<Laney> mlankhorst: added you
<Laney> it will give you indirect ubuntu membership too
<mlankhorst> ah k
<cjwatson> Laney: is http://paste.ubuntu.com/1335410/ too terrible?  I don't actually see a way to preserve no-new-upstream-release-autosynciness without breaking the spec for the Debian revision part
<cjwatson> or having a terribly misleading version
<Laney> nah, that's what I'd do
<Laney> this is what you get when you revert
<cjwatson> yeah
<cjwatson> worst case we end up with 1.0.1.3+really1.0.1.3-... for a while :-)
<stokachu> cjwatson: so my shell-fu is probably wrong but could you look at http://paste.ubuntu.com/1335451/ and see if im missing something here?
<cjwatson> stokachu: That looks OK to me if it works
<stokachu> cjwatson: the second half is whats actually output to the file and it fails to load
<cjwatson> Put 'set -x' at the top and look at the logs
<stokachu> ok ill re-test
<cjwatson> (You can just hack this in locally, no need to rebuild the package)
<cjwatson> Should hopefully end up in .xsession-errors
<stokachu> ok trying that now
<stokachu> bah nothing showing up in .xsession-errors
<stokachu> ah i see whats going on
<infinity> It's just a shell script, you could just manually run it with "sh -x /path/to/script" and see if it does what you think it should.
<stokachu> yea
<stokachu> http://paste.ubuntu.com/1335471/
<stokachu> i need a /usr/lib/*/$moduledir_suffix...
<infinity> (I assume the same thing is being done to appmenu-gtk3 as well?)
<stokachu> infinity: yep
<stokachu> infinity: wouldnt this be easier in perl? :P
<infinity> You said it, not me.
<stokachu> hah
<infinity> Wait...
<infinity> moduledir=/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/menuproxies
<infinity> Wasn't the whole point of this to ship a conffile that didn't have the arch bits in it?
<infinity> Since this is part of an MA:same package?
 * infinity wonders if this wouldn't be a trillion times easier if you just shipped 80appmenu_${triplet} for each build, so they don't conflict, and can continue having hardcoded paths...
<stokachu> wouldn't that be adding more complexity unecessarily though?
<infinity> Then you could go back to the same 4-line 80appmenu file as before.
<infinity> I don't see how it's added complexity, really.  You're shipping one conffile per arch lib, not unheard of.
<infinity> See, eg: dpkg -S /etc/ld.so.conf.d/{i686,x86_64}-linux-gnu.conf
<stgraber> Laney: shouldn't that team be called -graphics-dev or similar considering wayland is included in the set?
<mlankhorst> details, it's the xorg team responsible for it ;)
<stgraber> mlankhorst: package set created and populated. I'm generating a new report now to confirm that the list matches what we discussed
<mlankhorst> sure
<stgraber> mlankhorst: http://people.canonical.com/~stgraber/package_sets/raring/xorg
<mlankhorst> yeah noticed :)
<mlankhorst> thanks
<stokachu> infinity: i think ill be forced to do 80appmenu_{triplet} otherwise package conflicts happen on the config when both architectures attempt to install
<stokachu> or i could separate out into an appmenu-data package
<infinity> stokachu: A -data package for a single conffile seems a bit silly.
<stokachu> yea, however, i think /etc/X11/Xsession.d/80appmenu-gtk_{i386,amd64} 80appmenu-gtk3_{i386,amd64} seems excessive
<stokachu> but i dont see a way around it
<stokachu> the wiki seems to think that shipping configs with data files in a shared library is wrong
<stokachu> s/with/and/
<kumadasu1> Hi. I want to apply this patch to chromium-browser in local build.  http://code.google.com/p/webrtc/issues/detail?id=512
<kumadasu1> But I don't know how to apply patch.
<kumadasu1> This kind of question is appropriate here?
<kumadasu1> I'm using Ubuntu 12.04 precise.
<kumadasu1> Probably I should use quilt.  I tried $quilt push -a and I got below
<kumadasu1> Patch chromium_useragent.patch does not exist
<kumadasu1> Applying patch chromium_useragent.patch
<kumadasu1> I looked the directory and found "debian/patches/chromium_useragent.patch.in" instead of ".patch".
<kumadasu1> What is .patch.in? and How to apply the patch to chromium-browser?
<ScottK> kumadasu1: Something .in usually means it's used to generate that file in same way.  I don't know the way the chromium-browser package is set up beyond "really complicated".
<ScottK> It's probably in the top handful or two of packages for complexity to deal with.
<kumadasu1> Hmmm, so now I understand chromium is so complicated.
<stokachu> if the policy for multi-arch states we should not include arch-independent files in the shared library package is it still wrong to assume a -data package is necessary even though its for one file? we already create -bin packages for executables
<stokachu> appmenu-gtk is kind of a special case, a shared library relying on a configuration file in /etc/X11/Xsession.d/
<kumadasu1> chromium has compressed source code like tar.lzma.  It's bothered me too.
<kumadasu1> I could build chromium-browser with pbuilder,
<ScottK> stokachu: Can you just generate it in the postinst if it's not already there and make it not a conffile or are there arch specific differences in the file?
<stokachu> ScottK: http://paste.ubuntu.com/1335739/ this is an example of what gets generated during install
<slangasek> stokachu: where do you see it said that arch-independent files may not be included in the shared library package?
<stokachu> we could do something where we just ignore moduledir and test for /usr/lib/*/gtk-2.0/2.10.0/menuproxies
<slangasek> also, appmenu-gtk isn't a shared library package, it's a plugin package
<stokachu> slangasek: https://wiki.ubuntu.com/MultiarchSpec#Architecture-independent_files_in_multiarch_packages i was reading this
<ScottK> stokachu: I think that would be 'wrong'.
<slangasek> stokachu: right - that's specifically addressing shared library packages, not DSOs
<stokachu> slangasek: gotcha
<slangasek> there's no soname here, so there's no reason to worry about that section
<kumadasu1> so if I know what quilt does, I can handwrite diff file.
<kumadasu1> quilt command generate patches/a.patch and modify patches/series and are there other files?
<stokachu> slangasek: with that said im running into an issue when coinstalling amd64/i386 wrt 80appmenu and 80appmenu-gtk
<slangasek> stokachu: well, the file does need to be identical across all architectures
<ScottK> Which it's not.
<stokachu> slangasek: so does it make sense to have it in a -data package?
<slangasek> no
<slangasek> you need to solve whatever's causing it to be different across architectures
<slangasek> otherwise, your -data package would probably only work on one architecture
<stokachu> ah i wonder if its because im storing moduledir=@moduledir@
<slangasek> that would do it, yeah
<stokachu> ive been staring at this to long :\
<stokachu> ok that clears everything up, thanks for the fresh set of eyes
<slangasek> sure :)
<kumadasu1> I tried once handwrite diff and modify series,  and pbuilder (precise armhf) to package chromium-browser.
<achiang> slangasek: hi, this blueprint seems to be associated to me, but perhaps you should be the approver? https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-arm-boot-resume-speedup
<kumadasu1> I succeeded package and it could run as browser, but it doesn't work mediastream(patch purpose) and webgl doesn't work properly too.
<kumadasu1> I don't know the istruction is correct or not.  Any suggestion?
<slangasek> achiang: seems reasonable, marking.  are you and mfisch still the right assignee/drafter? (and is the drafting done?  If so, please set definition to 'pending approval')
<achiang> slangasek: i don't think we should be the assignee/drafters
<kumadasu1> Ah, kernel version may different between pbuilder's environment and target.
<slangasek> achiang: ah, well then - ok, will get that sorted out on our side
<slangasek> achiang: btw, I missed this session... did you happen to notice my question in the whiteboard about what "fixed version" of bootchart refers to?
<achiang> slangasek: yes, i believe in our build, bootchart was looking in the wrong spot for the logs and we wrote a small simple patch to fix it
<mfisch> slangasek: we put a fixed version of bootchart in the public PPA and we have an open bug upstream
<kumadasu1> because the target environment uses PPA from TI OMAP.  I run chromium-browser on precise on pandaboard.
<slangasek> achiang, mfisch: could you please file a bug against the Ubuntu package with patch, and link that bug to the blueprint?
<achiang> slangasek: yep, will do
<slangasek> ta
<stgraber> @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 dicussion 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:
<mfisch> slangasek: I linked the bug # into the Blueprint and cwayne is adding the patch
<robert_ancell> StevenK, can you reject the latest gnome-games update to quantal-proposed? I gave it the wrong version number
<StevenK> robert_ancell: I could, except I can't see it in -proposed
<robert_ancell> StevenK, I see it here https://launchpad.net/ubuntu/quantal/+queue?queue_state=1&queue_text=
<StevenK> Oh, I've looking in NEW, sigh
<StevenK> robert_ancell: Rejecting gnome-games/1:3.6.0.2-0ubuntu2
<robert_ancell> ta
 * infinity had completely forgotten StevenK was in ~ubuntu-archive until he just read backscroll.
 * xnox thinks it's time to upgrade to raring =)
<infinity> xnox: Why so late?  I've been running it since it opened!
<xnox> infinity: i didn't trust britney at first.
<infinity> She'll be crushed to hear that.
<xnox> infinity: now that she is handling haskell back, I can see it's working.
<mwhudson> britney is a ridiculous name inherited from debian?
<mwhudson> i certainly hope we've stopped inventing names like that
<xnox> mwhudson: http://pad.lv/~katie
<mwhudson> xnox: well yes, and gina and fiera and other things
<mwhudson> but they're all old
<infinity> Most of the ones in Debian have since been renamed.
<infinity> britney is an odd hold-out.
<mwhudson> oh good
<xnox> well ben is still called ben and it's fairly newish.
#ubuntu-devel 2012-11-06
<skunk> im working on a c program for the Software centre... why is it good practice to put 'f' after a float value?
<pitti> Good morning
<pitti> stokachu: I am fine with a precise SRU and did upload your fix, but the SRU team rejected it (followed up in the bug); infinity, do you know why gdb was rejected for precise?
<dholbach> good morning
<mitya57> guten morgen dholbach
<dholbach> mitya57, Ð´Ð¾Ð±ÑÐ¾Ðµ ÑÑÑÐ¾
<pitti> doko_, ScottK: hm, no /usr/bin/python2 in Debian? that's a bit of a bummer
<pitti> as /usr/bin/python has been ruined by PEP-394, we need that to reliably get python 2
<mitya57> I remember jcristau said he won't allow addition of that symlink for wheezy
<mitya57> so we'll probably get that later
<pitti> hm, that requires hacks like http://bugzilla-attachments.gnome.org/attachment.cgi?id=228194
<pitti> and PEP-394 mandates its existence
<mitya57> dh_python2 (in Debian) automatically converts python2 shebangs to python, doesn't it?
<pitti> that only works for packages, though
<pitti> not for custom scripts, jhbuild, or upstream configure/make/make install
<mitya57> that's sad, yeah
<cjwatson> pitti: write polyglot 2/3 code and then you can pretend that you are in a sensible universe where that PEP doesn't exist
<pitti> haha
<cjwatson> pitti: also, any distribution that *actually* points python to python3 has doomed itself to lots of python code failing anyway; who'll notice another one
<pitti> yes, that's pretty much what I said in https://bugzilla.gnome.org/show_bug.cgi?id=658237
<ubottu> Gnome bug 658237 in general "Fix Python shebang lines" [Normal,Unconfirmed]
<pitti> that seems to be a really bad move from Arch
<pitti> but formally it's covered by this silly PEP, unfortunately
<pitti> (not that this helps in any way to fix the actual breakage of pretty much all programs and custom scripts)
<batee> Hello, does anyone know about applying seccomp filter rules to a newly spawning process through exec(). Further application of filter should be only  for newly spawned process.
<menace> Hi, is there a tool for comparing repositories according to package-differences?
<darkxst> is anyone around that can sponsor an xorg-server fix? https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724. it fixes an incredibly annoying bug with broken pointer barriers in gnome-shell and I believe has no ill effects for unity
<ubottu> Launchpad bug 1073724 in xorg-server (Ubuntu) "Pointer barriers have gaps along the edge of the screen" [Undecided,Confirmed]
<cjwatson> menace: https://code.launchpad.net/~cjwatson/+junk/suite-diff might help
<cjwatson> not especially polished :-)
<menace> oh nice
<menace> perhaps i have some time for polishing ^^
<seb128> dholbach, hey, I've a libxml2 question for you
<dholbach> sure
<seb128> dholbach, http://launchpadlibrarian.net/119213170/libxml2_2.8.0%2Bdfsg1-5_2.8.0%2Bdfsg1-5ubuntu1.diff.gz
<seb128> dholbach, you added a libxml2-udeb binary in that upload but it's not documented in the changelog
<seb128> dholbach, what's the deal with that?
<dholbach> seb128, no, it was automatically added
<dholbach> it's always added upon ubuntu builds
<seb128> hum, "automatically"? by what?
<dholbach> WITH_UDEB := $(shell dpkg-vendor --derives-from Ubuntu && echo yes)
<dholbach> debian/rules
<seb128> dholbach, ok, I see the rules is doing weird stuff ... it's just weird that it ends up in the diff this way
<seb128> dholbach, danke
<dholbach> seb128, so yes, we can sync from experimental - the problem is https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/1075146
<ubottu> Launchpad bug 1075146 in libxml2 (Ubuntu) "libxml2 2.9.0+dfsg1-3 FTBFS in raring" [High,New]
<dholbach> I asked for help to decide where to file a bug about the problem (upstream?) or if we need to patch this locally, but so far nobody could figure out where the problem came from
<seb128> dholbach, yeah, I ran into that as well, I figured out it's a doko issue ... I'm just merging the current unstable version for now instead
<dholbach> might be better to just figure out the build problem - AFAIR the unstable diff was not too important
<seb128> dholbach, ok
<seb128> dholbach, I will look at another package, I don't feel like debugging toolchain issues before lunch ;-)
<dholbach> seb128, it's just interesting that it's just the new version which FTBFS in raring
<dholbach> seb128, libxml2_2.9.0+dfsg1-3.dsc fails in quantal too - it's just weird that it does not occur in sid
<pitti> dholbach: do you want to earn extra karma and forward bug 1073323 to debian?
<ubottu> Launchpad bug 1073323 in gzip (Ubuntu) "Add simple test cases" [Undecided,Fix committed] https://launchpad.net/bugs/1073323
<pitti> dholbach: or are you working on making the upstream tests work in adt?
<dholbach> pitti, ah yes, I can forward it - I'll add it to my TODO list
<Laney> does anyone have a handy script to deduplicate Packages/Sources files, keeping only the newest version?
<pitti> bdrung: do you want to upload/forward to Debian bug 1073390, or want me to sponsor/help out?
<ubottu> Error: Debian bug 1073390 could not be found
<pitti> bdrung: I mean bug 1073390
<ubottu> Launchpad bug 1073390 in libarchive (Ubuntu) "libarchive-dev needs a compile/link/run test" [Undecided,In progress] https://launchpad.net/bugs/1073390
<pitti> In file included from argmatch.c:28:0:
<pitti> ./stdio.h:1012:20: error: 'gets' undeclared here (not in a function)
<pitti> err, what?
<pitti> that line merely does #include <stdio.h>
<pitti> (that's a new FTBFS of coreutils in raring)
<pitti> seems gets() is only exported if __USE_ISOC11 is not set, which might be a new default in raring
<pitti> doko: ^ did you happen to see this already?
<doko> pitti, yes, I think cjwatson did fix something similar in bison
<pitti> doko: ooh, thanks for the pointer!
<pitti> that's useful indeed
 * pitti tries to remember how dpatch works
<mitya57> does anybody know why python-markdown is in main (no binaries are)?
<mitya57> (it is in main according to LP)
<pitti> python-markdown |    2.2.1-1 | raring/universe | source, all
<pitti> it's not
<mitya57> so Launchpad lies? https://launchpad.net/ubuntu/+source/python-markdown
<pitti> yeah, apparently
<mitya57> ah, ok
<StevenK> release (universe) ?
<geser> mitya57: don't get fooled by the "Component: main" field, simply ignore it and look at the table instead
<Laney> that's main in debian I believe
<StevenK> There's even small text saying it comes from the package and may be wrong
<StevenK> Maybe it needs a <blink> tag
<mitya57> geser, StevenK: Laney is right, it's main in debian, question solved
<cjwatson> pitti: there are various different approaches depending on the exact version of gnulib files involved - you might also look at m4 and diffutils if that helps
<xnox> pitti: i was that happen with parted and one more package.
<xnox> I've tried to "update" / "bootstrap" gnulib in those packages but failed to do so in a correct manner.
 * xnox likes the patch in bison.
<seb128> slangasek, RAOF, SpamapS, other SRU team members: what's the official line from the SRU team on copying updates to the new serie as well as copying them from -proposed to -updates? seems to be done inconsistently at the moment
<cjwatson> xnox: I wouldn't recommend doing a full update
<cjwatson> not unless you're upstream
<cjwatson> xnox: I'm happy to sort out parted if you could push the merge work you've done so far
<bdrung> pitti: i'll take care of that patch
<cjwatson> I've done it half a dozen times or so now so I can do it pretty much by rote :)
<cjwatson> xnox: or come to think of it I could just fix it in Debian ...
<xnox> cjwatson: ack.
<xnox> cjwatson: I think I can just adapt your patch in the ubuntu merge. As it doesn't affect debian yet.
<xnox> do we have a bts tag for eglibc2.16 ftbfs?
<xnox> (e.g. the gets issue)
<cjwatson> no idea
<cjwatson> I'll do it in Debian anyway, at least in our git repository, as otherwise it'll inconvenience the glibc maintainers
<pitti> bdrung: thanks
<pitti> cjwatson: I shamelessly stole your reduced backport for bison; that only needed minor unfuzzing and works fine
<siretart> cjwatson: hi. sorry to bother you, but did you see my inquiry regarding libav for raring on the mailing list? i have no problem with waiting a few more days, but i just wanted to know if you intend to answer that mail or not.
<cjwatson> siretart: I didn't see it
<siretart> cjwatson: Good that I ping you on irc then ;-) -- https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036083.html
<siretart> hm. did I scare him that much?
<Peace-> hi i would like know if someone can help me to create a new package for bashrc
<cjwatson> siretart: replied now, anyway
<Peace-> basically i would like add some stuff to default .bashrc for each user
<siretart> cjwatson: thanks!
<Peace-> the only way is skel?
<robru> Peace-, yeah, when a new user is created, the files are copied from /etc/skel, so if you modify the files there then it is copied to each user. is that a problem?
<Peace-> robru: i have read that put too much stuff on skel is not reccomended
<Peace-> just that
<robru> Peace-, well I'm not an expert on that. I don't really see why it would be a problem. what are you wanted to add? a ton of stuff?
<Peace-> robru: :D
<Peace-> i was asking anyway cuz it works i did already my own package
<Peace-> so i was just curiorus
<robru> Peace-, it's probably fine. I mean unless you are putting hundreds of GB's in there. it just copies the files, so it's not like the system is bothered by copying some files that are slightly larger than before.
<Peace-> robru: well i have made this http://code.google.com/p/kde-peace-settings/source/browse/#git%2Fkde-myown-settings%2Fetc%2Fskel
<Peace-> robru: so i have vlc bashrc and some other little things
<robru> Peace-, yeah those are really tiny, I don't see any problem there
<Peace-> ok
<ev> pitti: do you have the power to unbreak ddebs.u.c? https://bugs.launchpad.net/daisy/+bug/1075056/comments/1
<ubottu> Launchpad bug 1075056 in Daisy "Retracers hung on "ERROR: Package download error, try again later: Failed to fetch..."" [Critical,Confirmed]
<cjwatson> Peace-: it's not recommended for the *distribution* to put too much stuff there - that policy directive doesn't apply to local packages though
<pitti> ev: hm, let me try to regenerate those; which release is that for?
 * pitti sighs at the ddebs.u.c. hack
<cjwatson> for the distribution, there's not only a concern of size, but also what you do about upgrades - usually when you think about this hard the resolution ends up being to put things somewhere else instead, so the advice in policy is there to try to stop people wasting time
<ev> huh, quantal
<ev> I was looking at precise
<ev> but libicc2-dbgsym doesn't exist in quantal as far as I can see
<Peace-> cjwatson: well i am going to create a package that contains what i want to each user and i should upload it on ppa
<Peace-> i have already did but i was not sure if this could be a problem for users expecially for skel folder i mean
<Peace-> anyway as robru said it's very tiny folder so it should not be a problem if some users would install my package
<pitti> ev: hm, in quantal libicc2-dbgsym doesn't exist at all in ddebs' indexes..
<pitti> ah, the version in the bug report is for precise
<ev> ah I must've misread the pastebin
<pitti> ev: running
<pitti> (sorry, doing three things at once)
<cjwatson> Laney: ok, never mind - while I worked out a reasonably uncomplicated set of build-deps to allow both, I think it's probably safer to just bump them to the new version, i.e. prepend "1.0.1.3+really" to both << and >> versions
<ev> pitti: no worries
<cjwatson> anyway.  not actually meant to be working today :-)
<seb128> cjwatson, "the new -proposed migration system will enforce that this work is done before" ... what "work" for you refer too? is the system checking for nbs status (e.g enforcing that all rdepends are ported to the soname version of a lib when there is an soname update)?
<cjwatson> Yes
<cjwatson> At least if you make those libraries go away in the new source package
<seb128> urg
<seb128> I didn't think about that, seems to be problematic
<cjwatson> I don't think it will be
<cjwatson> I view it as an actively good thing
<seb128> or we will need start to press the delete source button a lot
<cjwatson> Or people could actually do the damn work to port NBS
<cjwatson> We do it anyway - it's not like this is work we avoid
<seb128> well, we also end up dropping stuff, usually at the end of the cycle
<seb128> like for e-d-s in quantal
<cjwatson> And it is troublesome when people are lazy and don't do it, because then we discover build failures when we're trying to do urgent updates
<cjwatson> It hurts velocity
<seb128> I guess we should drop early and let people add stuff back if they are interested in ported
<cjwatson> We need to stop doing things in a giant rush at the end of the cycle, and do things incrementally through the cycle instead
<cjwatson> That's one of the things I'm trying to move toward
<cjwatson> s
<seb128> right
<seb128> well I'm all for agressive universe cleaning
<cjwatson> I'm not
<cjwatson> I'm all for *fixing* it
<pitti> if there are universe packages which are hard to port and are "for later", a workaround/compromise could be to remove their binaries, but keep the source?
<seb128> I've neither the time nor the motivation to port all universe's rdepends to be able to update libs
<cjwatson> Removing the binaries is certainly a possibility
<cjwatson> seb128: That's not my problem, sorry!
<pitti> there will always be some universe packages which need lots of upstream work for porting
<cjwatson> And that's one of the things the +1 maint team is explicitly supposed to be helping with
<pitti> but for those where we can, we should certainly do it right away rather than having them linger for month
<pitti> s
<seb128> cjwatson, yeah, and I know different people have different opinions on what to do with universe outdated packages
<cjwatson> I've lost patience with the "universe doesn't matter" thing I'm afraid
<cjwatson> Turns out that to many of our users it does
<stokachu> cjwatson, infinity: is it possible to have bug https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1036834 re-evaluated for inclusion into precise?
<ubottu> Launchpad bug 1036834 in gdb (Ubuntu Precise) "[FFe] gdb should be marked "Multi-arch: allowed"" [High,In progress]
<cjwatson> stokachu: I'm not familiar with why it was rejected in the first place ...
<xnox> seb128: upload new library soname bump as a new source package & transition main to it, then the old one drops out to universe and you can hand over to motu/+1
<stokachu> yea there wasn't any information in teh bug as to why
<seb128> cjwatson, it's not that it doesn't matter, is that we have limited resources and we can either spend those improving what 90% of your users run or spend the same time porting universe stuff used in aa magnitude less
<cjwatson> xnox: I don't recommend that except in extreme cases
<cjwatson> seb128: We are doing lots of this work anyway.  You're just making the +1 maint team do it instead
<ogra_> yeah, the libs would pile up over time
<cjwatson> This isn't actually a net saving, it just annoys everyone
<stokachu> is there a way to see who actually rejected it?
<seb128> cjwatson, well, as said I would recommend agressive dropping instead
<cjwatson> stokachu: No
<xnox> cjwatson: I understand and agree that fixing stuff is the best way.
<seb128> which we sort of did for e-d-s rdepends in quantal
<cjwatson> seb128: Which is no help to people who have it installed, so I do not recommend that unless there is no realistic alternative
<seb128> we even dropped evolution-indicator which was canonical's code
<pitti> yeah, under the new regime that seems to be the best thing for stuff that's effectively unportable by us
<cjwatson> It is an option, but it is not and should not be the first resort!
<pitti> the nice thing is, it forces us to keep the universe in an installable shape all the time!
<stokachu> who would I talk to in order to get this overruled?
<stokachu> possibly overruled*
<seb128> cjwatson, the alternative is to spend a month of my time porting universe stuff and tell my manager I couldn't deliver thing we should have delivered
<cjwatson> stokachu: None of us can overrule anything until we figure out who did it and why
<cjwatson> seb128: oh nonsense
<cjwatson> It's not a month of your time, stop exaggerating
<pitti> cjwatson: I think you might be seeing this under a too absolute perspective
<cjwatson> And I'm not saying it has to be *you*
<pitti> cjwatson: for a lot of cases it is actually a month
<stokachu> should i just post a question in the bug and hopefully someone will say why?
<xnox> seb128: 3 people did python3.3 transition of main & universe in less than a week.
<seb128> cjwatson, well, we estimated evolution-indicator to be a week worth of time to port to the new e-d-s last cycle and same for pidgin-libnotify
<pitti> cjwatson: and we just can't/don't do it and drop instead if upstream abandoned the project; I think that's only fair
<cjwatson> pitti: On the contrary I think seb128 is being way too absolutist.  I've done lots of this porting and hey, look, it turns out I delivered plenty of other stuff too
<cjwatson> pitti: where did I say we should *always* port everything?
<cjwatson> (hint: I didn't, and I'm annoyed at being characterised that way)
<seb128> cjwatson, well, you are saying that not porting block the migration of the new libs
<seb128> we we need to port or drop
<cjwatson> I said repeatedly that removal is an option, just not the first resort
<cjwatson> seb128: Yes
<stokachu> cjwatson: i<3u
<seb128> cjwatson, so I think we agree, I'm just saying that in practice time constrain mean we will see drops increase (maybe to add things back a bit later when time allows)
<cjwatson> stokachu: might be worth grepping IRC logs and the like
<pitti> right, that falls under the "no realistic alternative" exception
<seb128> cjwatson, like in practice time for porting comes rather after ff than before
<cjwatson> seb128: we shipped precise and quantal with zero out-of-date binary packages and zero NBS, so I don't see why things would need to change
<cjwatson> we're doing all this work over the course of a cycle anyway
<seb128> cjwatson, well, I do consider that we have been agressive in dropping for quantal...
<pitti> seb128: well, we did survive it with dropping packages; that seemed to have worked fine?
<cjwatson> and what you're saying is basically that Adam and I get to pick up all your trash at the end
<seb128> pitti, we dropped stuff used in quantal, e.g evolution-indicator (indicator-messages' integration for evolution)
<pitti> it now just means that we need to do it right away
<seb128> or pidgin's indicator-messages integration
<seb128> or a bunch of universe rdepends from eds: dates, contacts, ...
<seb128> pitti, right, that's what I was saying
<pitti> well, we have to pick either: velocity or having a giant universe with a lot of upstream-unmaintained bits
<seb128> cjwatson, "<cjwatson> and what you're saying is basically that Adam and I get to pick up all your trash at the end" ... sorry I didn't say that, I say we should be more agressive in dropping unmaintained stuff from the archive
<xnox> seb128: I think I clearly remember you saying that all indicators will be ported to the new api. If pidgin's indicator-messages integration is dropped.... how are xubuntu & lubuntu getting ther notifications currently?
<pitti> and personally I'm favoring the former, even if some of those universe packages might have users
<seb128> pitti, that conversation started with me saying that I'm "all for agressive dropping"
<pitti> we can't have our cake and eat it too
<xnox> they are using the older api, is it still in the archive?
<cjwatson> pitti: cleaning things up as we go should ultimately improve velocity; I don't at all agree that this is a binary thing
<cjwatson> we lose velocity by having to stop and fix the archive all the time in order to land changes
<pitti> no, it's not a binary thing; I didn't say that we'd immediatley drop all NBS rdeps
<seb128> xnox, they don't I guess
<cjwatson> pitti: I mean it's not a choice between velocity and fixing things
<xnox> seb128: 8-?
<cjwatson> (changes> which BTW are often actually in universe - things that customers want but that we haven't yet qualified for main are in universe, for instance)
<pitti> cjwatson: well, it is; we need to find a good balance
<cjwatson> pitti: it should not be a choice.  one of the things that has absolutely killed our velocity in the past is a constantly broken archive
<cjwatson> and I believe I have pretty clear management backing for fixing that, so if you feel that you have a problem with delivering things as a result then I think you should talk to your manager
<pitti> right; but if you have to port 50 rdepends of e-d-s it kills velocity too, as you effectively can't land it for weeks
<seb128> or poppler
<pitti> so, certainly we have to do that
<cjwatson> poppler is a great example because the desktop team didn't bother to do that at all and it fell to apw
<cjwatson> last time I remember
<Daviey> dropping 50 rdepends would be crazy talk, just because someone wants a slightly newer library.
<seb128> we do bother doing the main desktop part, we are just so overworked that we can't possibly porting universe as well
<pitti> Daviey: nobody is proposing that
<cjwatson> like I say, I don't mind some removals, but you need to take a sensible position rather than just "I can't be bothered porting any of this, remove"
<seb128> or we need to stop what we are doing to port universe
<xnox> Somehow i am failing to see how a newer poppler or e-d-s is a hard-dependency for any feature work.
<Daviey> Anyone that claims it's not their job to keep the archive good, should renounce their ubuntu-dev membership.
<cjwatson> where "port" is often "reupload"
<pitti> I'm just saying that claiming that "porting all rdepends right away is increasing velocity" is not quite right
<pitti> I'm not saying that we shouldn't port things right away; I think we should, and I'm quite happy that it's now being enforced
<pitti> (with my former archive admin / stable+1 maintainer hat on)
<cjwatson> I mean, lots of the porting people say they don't have time to do I've done in the past, and a pretty sizeable proportion has been a matter of no-change uploads
<cjwatson> so, I'm sorry but I don't see that as a major imposition on anyone
<seb128> Daviey, there is a different between "keep the archive good" and "care for everything in universe, including old stuff that you think are unmaintained and have no users"
<seb128> cjwatson, well, it's not a "major imposition", I just fear that still like libav stay in proposed for a month and block other things
<cjwatson> and I'm not saying you need to do the latter, only that you actually need to analyse the trade-offs before removing, and if it's just a matter of no-change uploads then why on earth not
<seb128> that I agree with
<cjwatson> seb128: many of the unported libav rdeps were on images and really used
<mvo> slangasek: hi, do you mind if I do a raring apt upload?
<seb128> usually those non ported at those which are non trivial though
<seb128> at->are
<cjwatson> seb128: they wouldn't have been that hard for the person who changed libav to do; they were not too bad for me once I figured out the patterns
<pitti> e-d-s is certainly a rather extreme case; most libraries are quite a bit easier
<cjwatson> it's not like I'm not speaking from experience here, since I did a lot of the libav porting personally last time round
<seb128> pitti, extreme but real
<pitti> yeah, but not the common case
<seb128> e-d-s was simply not doable without somebody full time for a month
<seb128> we did end up dropping tons of stuff
<seb128> but at least we didn't block the main image on having all those resolved/dropped
<seb128> well, let's see how it goes in practice
<seb128> I guess we will need to get down to the "I've looked at it, will take a week of work to port, nobody has time atm, let's drop and add it back later"
<cjwatson> BTW the more stuff we move out to universe (e.g. Kubuntu last cycle) the less I agree with the "universe -> nobody cares" built-in assumption
<seb128> on the case by case basis
<pitti> the nice thing is that it puts responsibility at the right place for Ubuntu uploads; for Debian syncs, it'll still fall under stable+1, but it's been like that before anyway
<cjwatson> I think we've been way too far on the side of "the uploader can just forget about it" until now
<seb128> pitti, I'm not sure I agree with that, because I've to update e-d-s to update GNOME doesn't mean I want to be responsable for the e-d-s rdepends in the archive
<cjwatson> This way, the uploader actually has to think - not necessarily do all the work personally, but do some of it, find people to help, remove stuff if it's too painful
<pitti> it'll decrease the speed of landing things (i. e. velocity) a bit, but the net result is much nicer IMHO
<pitti> especialy if we want to go to the rolling release thing
<Daviey> Maybe the real issue here is the ease that a lib transition can be done?  I wonder if more scrutiny is the correct answer here?  It seems that this is pain we endure when we jump ahead of Debian... no?
<cjwatson> Before, they could make it somebody else's problem all the time, and I honestly think that in the majority of cases - not necessarily all - that was just plain irresponsible
<seb128> cjwatson, there is probably a bit of that as well yes...
<pitti> Daviey: that'd be velocity again -- Debian's freeze takes very long, we can't afford to wait until they release
<seb128> well, let's see how that plays out
<Daviey> pitti: And you can outline specific reasons for needing a transition ?
<cjwatson> so, I'm probably way too knee-jerk on this, sorry, it's one of my hot buttons
<pitti> Daviey: in some cases we do Debian experimental uploads, but that of course doesn't really address the "port all Debian main" issue
<Daviey> that outweigh the cost?
<pitti> I'm not sure that I understand the question; we could also stop updating package versions entirely surely
<cjwatson> I do think that when we drop binaries that amounts to making it the user's problem, which is sometimes even worse, so I don't see that as an automatic solution
<cjwatson> It can be a solution if things are really unused; but I'm just aware that for a developer who might otherwise have to do porting work, the incentive is definitely to say "oh, whatever, nobody cares about this surely"
<cjwatson> (I've done that myself and been occasionally wrong)
<seb128> cjwatson, well, as said it's not used or not, it's "what will benefit more user, time spend on the default desktop or time spent on universe packages that we doubt are used"... there is a balance to find for sure, but porting 50 rdepends is taking time even if the fixes are trivial and can easily can put you some days off
<seb128> cjwatson, where the said soname update is needed to land some chunck of work you need to land it can be problematic to find those "some days" in between
<pitti> seb128: I think that's a price we just have to pay
<cjwatson> Mm, I wonder which of those users actually thank us more for :-)
<pitti> (but as cjwatson says, more people than just you can be involved in that)
<seb128> pitti, in an ideal work sure I would like to have time to land my features and fix everything in universe, in practice...
<cjwatson> Sometimes the problem is that if you happen to be in the 1% of people who use something, well, that's 100% of you
<cjwatson> And there's only so many times that we get to annoy 1% of users
<pitti> seb128: but to be honest, so do the people who need to clean up NBS :)
<Daviey> pitti: What i am saying is, this specific example.. all i can find as rational is "gstreamer (via gst-libav) requires this version"... That isn't IMO, enough justification.  Has anybody looked at if it is a hard requirement?  Is it less work to resolve that?
<cjwatson> Anyway, I agree that there is a balance and I guess we'll find some kind of medium between our positions
<Daviey> (it probably turns out that all that is required is no-change-rebuilds :)
<cjwatson> stokachu: I've followed up to the gdb bug with what I think happened
<cjwatson> stokachu: (erm, really this time - LP timed out on my first attempt)
<siretart> how to add a transition to http://people.canonical.com/~ubuntu-archive/transitions/? file bug or is there a bzr branch that I can could touch?
<pitti> hah, gvfs' autopkgtests discovered a Python 3.2 â  3.3 behaviour change in Popen
 * pitti fixes
<siretart> ah, seems to be https://code.launchpad.net/~ubuntu-transition-trackers/+junk/transition-tracker - nvm
<pitti> ev: ... still waiting on apt-ftparchive to finish...
<ev> :)
<zyga> hey, I'm running some tests and I'd like to build a chroot for raring
<zyga> I'm using debootstrap but it has no script for raring yet
<zyga> are we going to update debootstrap in quantal to make that possible?
<cjwatson> Upgrade to raring or use the debootstrap from quantal-proposed
<zyga> or should I use some other means of doing that
<zyga> oh, cool
<cjwatson> Or 'sudo ln -s gutsy /usr/share/debootstrap/scripts/raring'
<zyga> thanks, let me try those
<cjwatson> It'd have been in quantal as released but we found out about the name too late
<zyga> hmm, I'm already using proposed
<cjwatson> siretart: Laney should be able to help (he says, carefully washing his hands)
<zyga> with debootstrap 1.0.42
<cjwatson> zyga: Oh, sorry, it's still in the queue.  Just set the symlink manually for now
<zyga> thanks
<mr_pouit> pitti: hey, any thought on https://bugzilla.gnome.org/show_bug.cgi?id=687525 ? I've SRUs for xfdesktop and thunar waiting for approval to quantal-proposed, but if this gvfs patch is fine for a SRU, I guess it's better than my workarounds.
<ubottu> Gnome bug 687525 in general "gvfs causes filemanagers to show partitions twice" [Normal,New]
<xnox> siretart: yeah, just make a merge proposal for that branch and it will all just magically happen.
<Laney> you can't do MPs for junk branches
<Laney> but give xnox the address and he'll review it for you :-)
<xnox> siretart: there is a README for "how to get started"
<xnox> siretart: yeah I used to target the "lp:ubuntu-transition-target and that means merge notification is sent to all people who can merge"
<xnox> siretart: but yeah, I'll be happy to merge trackers =))))
<siretart> xnox: https://code.launchpad.net/~siretart/+junk/transition-tracker.libav
<pitti> mr_pouit: this looks SRUable to me indeed
<siretart> I don't see the button 'merge proposal'
<pitti> mr_pouit: just don't take my word as the final one, as I'm neither in -desktop or SRU teams any more
<pitti> siretart: right, +junk don't have MPs
<siretart> i see
<siretart> thanks for the clarification, pitti
<mr_pouit> pitti: yeah, but you're a lot in the gvfs git commit log :P. Thanks, I'll look into preparing the sru.
<cjwatson> zyga: accepted the {precise,quantal}-proposed debootstrap uploads now
<xnox> siretart: merged. now after some time it will be available on the website.
<siretart> xnox: thanks. that'll help me to get started with what to test and upload.
<xnox> siretart: ;-)
<pitti> cjwatson: ^ which reminds me, do we need an NBS report for -proposed?
<seb128> pitti, <cjwatson> making a -proposed version of NBS is on the to-do
<pitti> ah, thanks
<seb128> pitti, just seen on #ubuntu+1-maint ;-)
<seb128> <cjwatson> but you can use http://people.canonical.com/~ubuntu-archive/proposed-migration/
<seb128>  (will take some practice to learn the format)
<pitti> because that should provide most of what we need for transition tracking?
<seb128> pitti, for completeness ;-)
<cjwatson> Yeah, in practice everything from NBS should show up on update_output
<cjwatson> (or update_excuses if not fully built)
<Daviey> cjwatson: I need to start creating an NBS report for another (non-primary) archive.  I'd greatly like to re-use something you create.
<cjwatson> Which I expect the +1 team to be keeping as low as possible
<cjwatson> Daviey: it's all in ubuntu-archive-tools ...
<Daviey> cjwatson: Oh, i thought you were going to create something refreshed.  Last time i looked at the tool in u-a-t, it had an issue.. Maube i am talking crap
<cjwatson> Well, that's what outputs the reports we use
<cjwatson> I certainly had no intention of rewriting it from scratch
<cjwatson> update_output> For instance the haskell-unordered-containers transition shows up as the first "Trying easy from autohinter" section there and you can see the uninstallables left after the attempt to shove in that plus all its rdeps
<cjwatson> Which mostly corresponds to the yesod* stuff on http://people.canonical.com/~laney/www-test/ghc.html
 * Laney just deleted that
<cjwatson> poo :)
<cjwatson> but anyway, you can imagine :)
<Laney> use the normal URL now
<cjwatson> So http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
<cjwatson> Or for the ptlib stuff it's clearer - you can see that just t38modem is left untransitioned
<cjwatson> What the transition tracker does is give you the build-dep/dep hierarchy which in some cases approximates a sensible order to approach the uploads
<cjwatson> The red lines should wind up basically the same as what update_output says
<cjwatson> (There are some confusing haskell autohinter entries further down which are essentially random "what if we try some of these packages but not all of them" heuristics - in this case, ignore them)
<cjwatson> I look forward to running the next perl transition through this - that'll be a laugh)
<cjwatson> apw: the entries in the "main run" section of update_output correspond to attempting to promote single packages rather than groups; so for instance it tries to promote uim, discovers that that makes uim-mozc uninstallable, and backs out
<cjwatson> (I already corresponded with the uploader about that since it needs a mozc merge; it's just an example)
<cjwatson> mjpegtools is a more interesting example that IIRC corresponds to actual NBS
<pitti> ScottK, Riddell: hm, apport-kde fails on this: http://paste.ubuntu.com/1337463/ -> known bug?
<cjwatson> And some of the packages are just uninstallable on their own account, for example python-augeas which depends on libpython2.6
<cjwatson> apw: that roughly help?
<apw> cjwatson, yeah thanks, will poke at it and come back at you
<pitti> ScottK, Riddell: i. e. pykde4 incompatibility with py3.3?
<stokachu> cjwatson: you got it figured out?
<cjwatson> stokachu: I updated the bug
<stokachu> cjwatson: ok cool, so i just need a sponsor again then i believe?
<cjwatson> wait, gdb is already in precise-proposed ...
<cjwatson> I mean in the queue
 * cjwatson reviews
<cjwatson> stokachu: why expand the @gnu@ et al items in debian/control.in ?
<pitti> stokachu: no need to reupload BTW; one can fish it out of rejected
<cjwatson> http://paste.ubuntu.com/1337490/
<cjwatson> pitti: it's in unapproved
<pitti> stokachu: (if you did already, no harm, though)
<pitti> cjwatson: ah, ok
<cjwatson> stokachu: the Build-Depends changes there look spurious, as if somebody had copied debian/control over the top of debian/control.in or something
<stokachu> its the way previous people have been building i believe
<cjwatson> Well, no, it isn't or it wouldn't be in the diff to this version
<stokachu> previously they were just modifying debian/control i believe
<xnox> pitti: ev: the crash handler (apport) fails with "__init__() takes from 1 to 6 positional arguments but 7 were given" in raring, so I can't submit much....
<cjwatson> stokachu: You should indeed modify both debian/control.in and debian/control for the Multi-Arch change, but there should have been no need to modify the Build-Depends line at all
<cjwatson> That looks accidental
<stokachu> ill go back and look its beena while
<pitti> xnox: right, I just fixed that in trunk
<cjwatson> stokachu: If you agree that only the Multi-Arch line needs to be changed, I can just reupload without the spurious B-D change
<xnox> pitti: ack.
<pitti> xnox: half of my packages have some problem with py 3.3 ..
<stokachu> cjwatson: yea only the multi-arch needs changing
<pitti> xnox: new upstream release is out, currently test-building ubuntu upload
<pitti> xnox: I'm walking through all adt-raring-* failures
<stokachu> cjwatson: im still pretty sure i did the build-depends change intentionally
<cjwatson> stokachu: I can't understand why
<stokachu> cjwatson: during my builds control.in was overwriting control
<stokachu> missing all the build-depends
<cjwatson> Those @...@ symbols are meant to be automatically expanded
<cjwatson> In the process of generating control from control.in
<stokachu> right.. but control.in was missing build-depends
<cjwatson> That's not what the diff says
<stokachu> thats why i added the additional build depends to control.in
<cjwatson> I reversed the @gnu@ and @kfreebsd@ expansions and there was no other change
<cjwatson> You didn't add any build-depends
<cjwatson> You expanded @gnu@ and @kfreebsd@ symbols - that's all
<stokachu> hmm ok im not sure then
<cjwatson> Which should be unnecessary and I'd like to avoid unnecessary changes in an SRU
<cjwatson> If you like, I'll revert that part and try test-building without
<stokachu> sure, thanks
<cjwatson> (But I should go, meant to be on holiday today)
<stokachu> ok no worries
<stokachu> i can do it and see if i can reproduce why i thought modifying control.in was necessary
<stokachu> like i said its been awhile since i messed with it
<stokachu> cjwatson: it looks like control isn't build populated with @gnu@ or @kfreebsd@ during my builds
<stokachu> s/build/being/
<apw> stokachu, are you saying there that they remain as @gnu@ etc in debian/control ?
<stokachu> http://paste.ubuntu.com/1337554/
<stokachu> they are empty
<apw> stokachu, and that prevents it building ?
<stokachu> apw: yea its complaining about missing build depends
<stokachu> i did a fresh source tree and only added Multi-Arch: allowed in control.in
<apw> stokachu, version you are working against is ?
<stokachu> 7.4-2012.04-0ubuntu2 in precise
<didrocks> xnox: do you mind pushing the unity-lens-radios changes to lp:ubuntu/unity-lens-radios please?
<apw> stokachu, where are you cleaning this, ie. what release are you building your source package ?
<apw> stokachu, as when i clean that combination i get something in the []'s there
<apw> stokachu, http://paste.ubuntu.com/1337577/
<stokachu> apw: im building within sbuild targetted for precise-amd64
<apw> stokachu, right but the source package where are you making that
<stokachu> apw: im just using the existing one from the archive
<apw> stokachu, i thought you said you had added a line to debian/control.in
<xnox> didrocks: ack.
<didrocks> xnox: thanks :)
<stokachu> apw: sorry not sure i follow, i get a clean source with either pget (from pbuilder-scripts) or apt-get source then I just modify the file within the tree and re-run pbuild
<stokachu> last month i attempted with sbuild but got similar results
 * apw regets the source to confirm
<stokachu> ive also attempted to pull straight from bzr and run a bzr bd -- -S -us -uc
<stokachu> each one hating me more and more
<apw> stokachu, ok so the source before any mods has stuff in my brackets ...
<stokachu> and when you attemp to build it what happens?
<apw> stokachu, where are you adding m-a: allow ?
<apw> for which package, so i can make sure my build matches yours
<stokachu> the gdb stanza
<stokachu> second one from the top
<apw> ok to build mine i am then going to build a new source package and build that with sbuild
<stokachu> ok
<xnox> didrocks: hopefully the importer will not have a fizzy fit about it =)
<didrocks> xnox: it doesn't really like for the kind of merge-upstream branch
<didrocks> xnox: that's why I specify the branch in Bzr-Vcs
<xnox> didrocks: ok. I did push to lp:ubuntu/unity-lens-radios as you requested. Do you want stuff in lp:unity-lens-radios as well?
<didrocks> xnox: for upstream changes, sure :)
<apw> stokachu, ok i think i see what is going wrong.  wherever you are building this does not have the build-depends installed, soooo you lose some of your dependancies on clean
<stokachu> apw: i thought sbuild/pbuild would handle that portion cleanly?
<apw> stokachu, basically when i made my source pacakge it has the same issue, because i was lazy and didn't install the build-deps before making the source package
<stokachu> ah
<apw> stokachu, so it depends, if you make the source package right and submit that it has the right things in it
<apw> stokachu, so i think looking at it in this case installing type-handling may help
<apw> as it is that that errors here and leaves those []'s empty for me
<apw> but to be 'right' you should have the build-deps installed
<stokachu> ah ok
<apw> i use mk-build-deps --install <package> to make a fake package to pull them all in, so i can remove it later
<stokachu> apw: ok ill do that on the host machine and re-try
<stokachu> apw: this is the first time this has happened, should i add this into my workflow for all packages?
<apw> stokachu, i have to concur it is the first time i have been bitten by it also, i believe that is the right thing to do
<stokachu> ok ill make a note of that
<apw> stokachu, myself i tend to build the package and debdiff against the previous one, and confirm its only different the way i expect; if not like here then i worry about the builddeps
<apw> stokachu, to spot the issue here i did debian/rules clean and looked at that output, the error was plane there
<stokachu> ok that makes sense
<xnox> doko: libguestfs fails to build from source because it misses a presence of an optional symbol in libpython. The way it checks for correct library is via: http://paste.ubuntu.com/1337639/
<xnox> which is different between python3.2 & 3.3.
<xnox> is that intentional or libguestfs is silly?
<batee> Hi, Could you please suggest me a place to download the source code of the "Seccomp Filter"?
 * didrocks wonders why ubuntu.getSeries(name_or_version="quantal") doesn't work with the launchpad api
<Adri2000> EmilienM: hi :)[A[A[A[A[Asn: Vuillemot
<Adri2000> paste fail. sorry about that :)
<apw> batee, you'd have to be more specific as to what you are using that you want the source for, but there is a package called libseccomp0 which claims to be the high level interface for that; otherwise it is likely kernel side code
<batee> apw, I need to look at the source code for the function SCMP_SYS(). I am currently using libseccomp library. In the library when we define new filtering rules seccomp_rule_add() function is used. One argument for that function is the return value of SCMP_SYS() function. it is an integer id relevent to each system call.
<Laney> didrocks: WFM - what do you get?
<Laney> >>> lp.distributions['ubuntu'].getSeries(name_or_version='quantal').displayname
<Laney> u'Quantal'
<doko> xnox, this seems to be an error. The Makefile has a correct value. so something seems to be wrong when generating the _sysconfigdata.py at build time
<apw> batee, so i would start with the source for that library then, apt-get source libseccomp0 should get that
<didrocks> Laney: '', hum, I'm using lp.distributions['Ubuntu'] though, which returns me a valid ubuntu distro containing all series when calling .series collection
<didrocks> Laney: let me try 'ubuntu'
<xnox> doko: do you want a bug about this?
<didrocks> Laney: indeed, that works :) funny that those double objects exists, both valid, but different behaviors :)
<doko> xnox, I'd prefer a patch ;-P
<didrocks> Laney: thanks!
<Laney> weird
<Laney> np!
<xnox> doko: well, I have a patch against a single package that fails to build because of this misgenerated file.
<xnox> :P
<batee> apw, Libseccomp simply use the SCMP_SYS(). library dose not define the SCMP_SYS() function. It is from the seccomp kernel code itself.
<apw> batee, then that is in the package 'linux'
<batee> apw, ok thanks
<apw> batee, that said i cannot see SCMP_SYS in it anywhere
<apw> batee, and it is actually in libseccomp:
<apw> ./include/seccomp.h:#define SCMP_SYS(x)__NR_##x
<apw> batee, which is basically converting the string 'read' to __NR_read, which is a define in unistd.h
<batee> apw, Thank you very much for the information.
<batee> apw, Is there a simple way to get the integer value corresponding to each system call.
<apw> batee, they are in unistd.h; so grep -r __NR_read /usr/include will tell you or you could just include those files
<batee> apw, Thank you.
<slangasek> mvo: no objections
<stokachu> could i get a sponsor for bug 1036834 with the latest debdiff for precise
<ubottu> Launchpad bug 1036834 in gdb (Ubuntu Precise) "[FFe] gdb should be marked "Multi-arch: allowed"" [High,In progress] https://launchpad.net/bugs/1036834
<stokachu> it has all the necessary corrections made
<slangasek> seb128: the official line is that you're supposed to be uploading to raring at the same time as you SRU for all SRUs uploaded after raring opening, and for those uploaded before raring opened the SRU team is supposed to copy them forward... but this is an error-prone process currently
<seb128> slangasek, do you recommend we get manual uploads for those which didn't get copied then?
<slangasek> seb128: generally that's going to be better, yeah, because then the package is built against the new toolchain
<seb128> slangasek, well, it's not like we didn't copy the whole archive without rebuilding it on serie open ;-)
<seb128> slangasek, but fair enough, it's a bit extra work but not the end of the world, thanks
<slangasek> seb128: true, but now we are open so those copies are meant to stop.  If you have a list of packages that were missed and you'd like copied, I can do that now
<slangasek> seb128: certainly for any SRUs uploaded today though, the usual rules apply and the package should be uploaded to raring first (and not doing so is a blocker for the SRU)
<seb128> slangasek, bamf file-roller libunity unity-lens-applications unity-lens-photos unity-lens-video
<seb128> slangasek, thanks ;-)
<seb128> slangasek, btw if you have any SRU review time I would appreciate http://launchpadlibrarian.net/121655774/gnome-settings-daemon_3.4.2-0ubuntu0.5_source.changes to get it (it's a bug leading to have user configs overwriten on "dconf update" runs)
<slangasek> well, I can certainly squeeze in some time for that one
<didrocks> thanks slangasek, seb128, will upload directly from now on
<seb128> slangasek, thanks
<seb128> didrocks, 'ci
<stgraber> slangasek: is there a tool giving the list of source packages in the stable release updates and proposed pockets that aren't in the dev release?
<slangasek> stgraber: not afaik, which is what makes this whole thing error-prone; it should really be part of http://people.canonical.com/~ubuntu-archive/pending-sru.html, probably as a flag or highlight or something so we know to run sru-release with -d
<stgraber> slangasek: ok, I wrote a script for that yesterday so I can send a MP for it and then someone (or me) can extend the sru report for it
<stgraber> slangasek: btw, according to my script, we're good now. The only missing SRU was bamf which was accepted in the release pocket a few minutes ago: http://paste.ubuntu.com/1338017/
<stgraber> slangasek: the script itself is: http://paste.ubuntu.com/1338023/
<infinity> stgraber: suite-diff can do it.
<infinity> Which may or may not exist in a useful place...
<stgraber> infinity: can't find any script by that name in ubuntu-dev-tools or ubuntu-archive-tools :)
<infinity> Yeah, I realised after I said it that it may be a cjwatson special that only exists on ftpmaster.
<slangasek> stgraber: really?  I was still in the process of copying the packages seb128 pointed out above (copy-packages didn't want to copy them for me all at once); did you double-copy here?
<stgraber> slangasek: the first run of my script spotted bamf as missing, a second run didn't. According to LP, it's been published to the dev release so will be actually published at the end of the publisher run.
<slangasek> stgraber: right, but seb128 listed a bunch of other packages
<slangasek> and those are still in progress
<stgraber> slangasek: pocket = release, "Published 7 minutes ago" "Copied from ubuntu quantal in Primary Archive for Ubuntu by Steve Langasek"
<infinity> stgraber: Your script is almost certainly wrong, given that I also know that linux is out-of-date (intentionally) in raring.
<stgraber> infinity: hmm, that's true, wondering what happened there... /me digs
<infinity> stgraber: Here's what I get from quantal-updates to raring:
<infinity> http://paste.ubuntu.com/1338048/
<infinity> stgraber: If you want to compare and debug your script.
<infinity> (though vorlon's about to fix half of those)
<stgraber> infinity: thanks
<infinity> stgraber: And since your script was also doing proposed: http://paste.ubuntu.com/1338054/
<stgraber> infinity: alright, found a few things that were wrong (including apt_pkg's help that was lying to me...), fixing those now
<infinity> (We could probably jam suite-diff into ubuntu-archive-tools too, but since it's used against Sources/Packages files, it's slightly less useful to people who don't keep a dists/ mirror around)
<infinity> Though, it's likely way faster than an API implementation.
<slangasek> infinity: do we care about the standalone tool if we get the info integrated into pending-sru?
<infinity> slangasek: The standalone tool has a lot of cool uses, but for this use-case, a single report of "these packages are older in raring than in quantal-updates" is probably enough, yes.
<infinity> Or, rather, raring+raring-proposed.
<stgraber> infinity: hmm, my script is saying that yours is lying :)
<stgraber> infinity: you're missing: gnome-shell, linux-lowlatency, linux-meta-lowlatency and ubiquity
<infinity> stgraber: Oh, I only did main.  (And I'm not missing ubiquity, read harder)
<infinity> stgraber: But my only doing main explains the other three.
<infinity> slangasek: Any plans on a new udev that links with kmod (which will keep libkmod-udeb in main), or should I just drop it to universe for now?
<slangasek> infinity: plans yes, but not immediate ones
<stgraber> infinity: oh right, I'm actually the one missing ubiquity, misread the diff.
<infinity> slangasek: Alright.  I'll just drop it for now, and let magic sort it out when libudev-udeb starts depending on libkmod-udeb.
<infinity> (Or however that dep will work)
 * infinity tries to remember what evil is afoot when various d-i components decide to try to drag every universe kernel into main...
<infinity> I know we've seen this in previous cycles, I don't recall the cause.
<stgraber> infinity, slangasek: ok, I think I fixed all the bugs (was mostly down to apt_pkg.version_compare being weird): http://paste.ubuntu.com/1338119/
<stgraber> oh, I probably should have it show the version numbers
<stgraber> output with version numbers: http://paste.ubuntu.com/1338154/
<infinity> stgraber: That looks somewhat saner.
<smoser> so with -proposed being where we upload..
<smoser> if we're doing udd should i commit things to lp:ubuntu/raring-proposed/cloud-init ?
<infinity> smoser: You upload to "raring", we force it into proposed. ;)
<smoser> good answer
<smoser> thanks
<infinity> smoser: UDD's understanding of this is, perhaps, a bit flawed right now.
<smoser> good enough for me.
<smoser> wonder if someone can tell me why bug 1070345 does not show up on https://bugs.launchpad.net/ubuntu/precise/+source/cloud-init
<ubottu> Launchpad bug 1070345 in Ubuntu Raring "need to restart landscape after updating config" [Medium,Triaged] https://launchpad.net/bugs/1070345
<achiang> are people with @ubuntu.com email addresses allowed to post unmoderated to -devel? or is that completely unrelated, and you actually need to have launchpad team membership?
<infinity> smoser: Because you're looking at ubuntu/precise/+source, instead of ubuntu/+source
<smoser> but i *want* precise/+source
<smoser> i was hoping to see a list of bugs that were nominated for precise
<infinity> smoser: Oh, I see, it has a precise task.
<smoser> maybe because its not fix-released in ubuntu ?
<infinity> Err, oh.
<infinity> No.
<infinity> It has no precise task. :P
<stgraber> infinity: hmm, looks like quantal released with a few packages missing from precise-updates. Cleaning up the list now.
<infinity> smoser: Those shouldn't be Ubuntu tasks, they should be cloud-init in Ubuntu tasks.
<infinity> smoser: Preeeeetty sure that bug does affect the entire Ubuntu project.
<smoser> yeah. your'e right. thats it.
<jbicha> achiang: unrelated, I believe you have to be in ~ubuntu-dev or on the whitelist
<achiang> jbicha: ok, thanks
<smoser> hm.. now how do i do that.
<smoser> "This bug is already open on Ubuntu with no package specified. You should fill in a package name for the existing bug."
<smoser> i think i'm just going to delete the ubuntu task and re-add it.
<infinity> smoser: Nah.
<infinity> smoser: I'll fix.
<infinity> smoser: Or, you can get there first. :P
<smoser> infinity, well, it seems ew crossed paths.
<slangasek> smoser: hey, any chance you could smoke test mountall 2.43 from raring for me?
<slangasek> smoser: this fixes the last regression I know of from the asynchronous events change; if it checks out for you I'll SRU that back to quantal and then SRU the whole thing back to precise
<smoser> slangasek, i'll give it a quick sniff on an instance.
<smoser> what is the bug thtat you've addressed?
<infinity> Changelog claims https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1059471
<ubottu> Launchpad bug 1059471 in mountall (Ubuntu Quantal) "2.41 fails to mount root partition" [High,Triaged]
 * infinity reads the bug.
<slangasek> yeah, not one you're likely to hit in your setup
<slangasek> but I'm looking for a regression-regression test
<infinity> slangasek: Hrm, will that fix the bug I've been seeing very recently where my machine claims /tmp isn't ready and then boots anyway?
<slangasek> infinity: I don't know, try it and tell me :)
<infinity> slangasek: I shall, once my laptop's idle.
<infinity> The best bugs are the ones I don't have to file.
<stgraber> slangasek, infinity: result for precise => quantal: http://paste.ubuntu.com/1338218/
<slangasek> infinity: is /tmp a real mount point for you?
<slangasek> stgraber: oh srsly?
<infinity> slangasek: Nope.  I have no /tmp in my fstab, I haven't hunted down yet WHY I'm getting that bizarre message on boot.
<slangasek> stgraber: ugh, what's with that boinc version number?
<slangasek> infinity: mmk
<stgraber> nvidia-* is a false positive, I need to fix the script, but the rest should probably be fixed
<infinity> alias fancontrol='killall plugin-container'
<slangasek> that mythtv mismatch looks nasty
<slangasek> someone uploaded the same upstream version twice, but managed to use the wrong datestamp and uploaded them the wrong way around? :P
<infinity> Something like that...
<infinity> Given that I assume the last part of that version is a commit ID, I'm guessing they're both identical save the version in the changelog.
<arges> did the ddebs move? looking for 3.5.0-13-generic don't see it on ddebs.ubuntu.com
<infinity> arges: No, you're just living in the past.
<infinity> arges: We don't keep old ddebs on ddebs.ubuntu.com forever, and 3.5.0 is -17- in the release pocket, -18- in updates...
<doko> xnox, done
<infinity> arges: (Both of which are on ddebs)
<arges> infinity, but the past is so much fun
<infinity> arges: Until you get eaten by a dinosaur, sure.
<infinity> arges: (In other words, if lamont's hungry, run)
<arges> so I take it, there were a few more ddeb sacrifices?
<infinity> arges: Erm, no sacrifice here.  We just don't keep ddebs for every version ever published, only the ones currently published (ish).
<infinity> arges: That will change (sort of) when we push them to the librarian instead, though ddebs.u.c will still only host ddebs that match published versions.
<arges> infinity, ok.  yup that makes sense. When will we push to librarian
<infinity> arges: This isn't some culling, though, this is how it's always worked.
<arges> and anything I can do to help with that?
<infinity> arges: The librarian bit, I'm looking into this week.  Need to do some testing to make sure the world won't asplode, then I can flip the switch.
<arges> infinity, sweet
<lamont> infinity: my hunger doesn't enter into it. :-p
<infinity> lamont: Om nom.
<lamont> that which eats only yummy stuff: omnomnivore
<doko> infinity, do you work on the debhelper merge?
<infinity> doko: I was going to.  It's actually a clean merge, but I'm suspicious there may be logical conflicts between the two patchsets, so wanted to have a quick poke,
<doko> thanks
<GunnarHj> charles: ping?
<charles> GunnarHj: pong
<GunnarHj> charles: Hi! Saw you decision. I'd hoped for something else... ;-)
<GunnarHj> charles: "an RFE against GDateTime" What's an RFE?
<slangasek> infinity: really?  the remaining delta should be quite self-contained... I wouldn't expect conflicts
<charles> GunnarHj: I was conflicted, too. I hate turning down good code
<charles> GunnarHj: what I meant was you should file a feature request in glib for a GDateTime function that does what that indicator-datetime bug describes
<infinity> slangasek: Hrm, now I feel like I may be misremembering.  Or I was sleepy. :P
<charles> GunnarHj: so that J Random App doesn't have to reinvent the wheel by doing the code itself
<slangasek> infinity: there was a one-time fix-up already to merge the upstart handling, but that should all be in the past now
<infinity> slangasek: I thought the Debian delta had some init-related something in it that I was concerned might logically conflict with our own init-mangling, but now that I look, it looks entirely unrelated.
<slangasek> infinity: (and was due to me pushing patches to do things differently in Debian than we have in Ubuntu up to now)
<GunnarHj> charles: Ok, thanks for explaining. Think I'll do that.
<infinity> slangasek: I must have been somewhere else when I last looked at this. :P
<GunnarHj> charles: Would you oppose to an Ubuntu specific patch in the meantime?
<charles> GunnarHj: an Ubuntu-specific patch to GDateTime?
<GunnarHj> charles: No, I meant to indicator-datetime.
<charles> GunnarHj: hrrm, that puts us right back where we were :)
<infinity> slangasek: Maybe I was looking at our delta and assuming it was Debian's, or something equally sleep-deprived and silly.
<charles> GunnarHj: I'd like to see what upstream thinks first, and treat indicator-datetime changes as a last resort
<GunnarHj> charles: Ok, that makes sense. I'll approach them soon with the idea.
<slangasek> infinity: we should be able to further reduce the debhelper delta in the future I think, but that first requires unhobbling insserv in Ubuntu
<charles> GunnarHj: sounds good. Could add a comment in the indicator-datetime bug that links up to the upstream bug?
<charles> s/Could add/Could you add/
<slangasek> (and that's lower priority than getting upstart itself in working order in Debian)
<GunnarHj> charles: Will do that too. Thanks for your advice!
<maxiaojun> hi
<infinity> slangasek: So, that new mountall fixed my bug.  Yay.
<slangasek> infinity: damn
<slangasek> infinity: that means I don't understand the change I made :P
<infinity> slangasek: Your apt kernel autoremoval stuff is curious, though.  Does it actually work?
<slangasek> infinity: works in my tests
<infinity> slangasek: I would have assumed that NeverAutoRemove influences how it writes the DB, not how it interprets it.
<infinity> slangasek: (Which is why none of my kernels are currently marked auto...)
<slangasek> evidently not
<infinity> slangasek: Hrm.  Your computer and mine disagree, then. :P
<slangasek> however, the Never-MarkAuto-Sections *does* influence how it writes the db
<slangasek> which is why I filed bug #1074787
<ubottu> Launchpad bug 1074787 in linux-meta (Ubuntu Raring) "linux-meta metapackages should not be in section 'metapackages'" [High,Triaged] https://launchpad.net/bugs/1074787
<slangasek> (and overrode everything in the archive)
<infinity> slangasek: Ahh.  And THAT's why none of my kernels are auto?  Check.
<slangasek> so once that fix gets committed to the kernel team's repo, and things have had a chance to settle out, I'm thinking to do an upgrade quirk in update-manager
<slangasek> ... or whatever that other thing is called that used to be part of u-m but isn't anymore... ubuntu-release-upgrader?
<infinity> That thing.
<infinity> Which reminds me, I should fix live-build to have the same hack for linux-image that it does for linux-headers...
<infinity> Or we'll have the install kernel installed forever.
 * slangasek nods
<infinity> slangasek: So, the theory here is that if I apt-mark auto all of my current linux-image* packages, your bits should magically DTRT?
 * infinity wonders if there's any sane way for us to SRU that...
<slangasek> that's the idea, yes; and yes I'm planning to SRU
<infinity> I mean to SRU "mark all kernels auto", not the other bits.
<slangasek> right, that's the part I was going to put in the u-r-u quirk
<slangasek> for precise and later
<infinity> Sure, that doesn't help people who've been running precise for 6 months.
<infinity> They'll get new kernels autoremoved, and the last 6 months of SRUs installed forever.
<slangasek> the archive override helps them immediately to prevent the problem from getting worse
<slangasek> and the last 6 months of SRUs will stay only until their next upgrade
<infinity> Which could be in 4.5 years. ;)
<infinity> But yeah, that may be the best we can safely do.
<slangasek> AFAICS we can *only* effectively apply this fix from something *not* running from a maintainer script
<slangasek> so u-r-u is the only option that comes to mind
<infinity> I assume you fixed the overrides in updates/proposed for both precise and quantal?
<infinity> Oh, but they'll need to be re-fixed every time until all the SRU kernels are DTRT.
<slangasek> just reviewing now to make sure I've gotten them all (inc. security)
<slangasek> do they?  this is an override on the metapackages
<infinity> Oh.
<slangasek> so that should be sticky
<infinity> Right.
<infinity> Neverming.  Sticky indeed.
<maxiaojun> Anyone interested in or involved in Jockey here?
<slangasek> so I'd gotten precise-{updates,proposed} and quantal-proposed; no kernel in quantal-updates yet
<infinity> slangasek: So, apt writes out the auto DB as the very last thing, I geuss?  A Dpkg::Post-Invoke hook would still be too early?
<slangasek> taking care of precise-security now
<slangasek> infinity: yeah, it writes it out from what it has in memory, so no dice
<infinity> slangasek: There's a kernel in quantal-updates.  I released it yesterday.
<slangasek> maxiaojun: jockey has been renamed to / replaced by 'ubuntu-drivers'; I don't know if anyone who's involved with it is currently around
<infinity> (That said, there are more on the way, for other flavours)
<infinity> Assuming all the -meta packages have this bug.
<slangasek> infinity: in that case, the override I did to quantal-proposed pre-yesterday should have already taken, I think?
<infinity> slangasek: Seems like a reasonable guess.
<slangasek> (apt-cache says yes)
<infinity> slangasek: I wasn't sure of the timing there. ;)
 * infinity marks all his kernels auto to see what happens.
<maxiaojun> Is ubuntu-driver shipped in 12.10? Any code to see in LP?
<maxiaojun> ubuntu-drivers I'm sorry
<slangasek> maxiaojun: according to the source package, the code lives at git://github.com/tseliot/ubuntu-drivers-common.git
<slangasek> maxiaojun: (shown by 'apt-cache showsrc ubuntu-drivers-common | grep Vcs')
<infinity> slangasek: You also missed linux-backports-modules in your no-auto-removiness.
<maxiaojun> slangasek: Thank you for your help. I generally use packages.ubtuntu.com since I run 12.04
<maxiaojun> packages.ubuntu.com
<infinity> slangasek: And while I'm looking, why do you use "^linux-image-$kernel.*"?  Wouldn't an exact match be saner?
<slangasek> infinity: rmadison claims linux-backports-modules doesn't exist?
<infinity> slangasek: (That means that, for instance, linux-image-1.2.3-12-generic would also match linux-image-1.2.3-12-generic-pae, for instance)
<slangasek> infinity: exact match> you're probably right, I was perhaps adhering too closely to existing convention
<infinity> slangasek: linux-backports-modules-3.2.0 would be the precise source package.  The regex would be something like ^linux-backports-modules-.*-$kernel
<slangasek> (and nevermind the fact that .* on the end is redundant in a regexp)
<maxiaojun> My issue with Jockey or ubuntu-drivers is that they don't try to pull b43 firmware at all.
<slangasek> infinity: so if that didn't already get fixed, it's presumably not in 'metapackages'?
<infinity> slangasek: And, I suppose $-terminated in all cases, if it's matching those as partial strings.
<jayco> Hello all, im new to this. I am a third year software engineering student and I would like to know how i can get involved in ubuntu development.
<maxiaojun> Another issue is that some hardware now support VAAPI (Video Acceleration API), but enable such features requires manual package installation now.
<slangasek> maxiaojun: I'm surprised to hear that, b43 is a long-known use case.  but beyond filing a bug report or reviewing the branch history, I have no specific advice I can offer
<maxiaojun> jayco: No offence, do you run Ubuntu natively on at least one of your computers?
<infinity> slangasek: The lbm meta bits don't seem to be in the wrong section, no.  I was referring to the apt snippet not trying to keep lbm around to match the installed kernels.
<jayco> maxiaojun: yes that is the only operating system i run at home.
<slangasek> jayco: http://www.ubuntu.com/community/get-involved
<slangasek> infinity: oh, ok
<maxiaojun> slangasek: I think there are (many) bug reports for Jockey already. Not sure the state of ubuntu-drivers.
<maxiaojun> jayco: You should notice some bugs of Ubuntu already?
<slangasek> infinity: fwiw this is not a regression, linux-backport-modules was never marked before.  do you want to file a new bug report for this etc etc?
<infinity> slangasek: Sure.  I was figure you'd JFDI while fixing the other regexes to be exact matches. ;)
<infinity> (Or I can do both right now)
<scientes> is there a amd64 kernel in i686 for 11.10?
<infinity> dpkg -l linux\*image\*[0-9]\* | awk '/^i/ {print $2}' | xargs sudo apt-mark auto && sudo apt-get --purge autoremove
<infinity> ^-- Actually DTRT.  Yay.
<maxiaojun> jayco: Do you have an LP account?
<slangasek> infinity: be my guest :)
<infinity> scientes: There aren't amd64 kernels in i386 in any release, but from (at least) precise on, you can add amd64 as a foreign-arch and install the amd64 kernel through the magic of multi-arch.
<infinity> scientes: That may or may not work on oneiric, I don't recall if all the kernel's rdeps were multi-arch friendly in oneiric.
<slangasek> which is hands-down the best ride at Disneyland, fwiw
<slangasek> (The Magic of Multi-Arch)
<scientes> i just want to be able to chroot into amd64 installs
<jayco> maxiaojun: sorry for the deleyed response, kids running around and screaming in the background. Yes I have a LP account and have just installed the tools.
<scientes> without the bad-binary party fail
<infinity> scientes: Right, this is the sane way to do it, s'all I'm saying.
<infinity> (Many of us run i386 userspace and amd64 kernels this very way)
 * infinity grumbles about dkms poop in his /lib/modules preventing clean purging.
<scientes> i'll just try --force-architecture
<slangasek> why would you do that instead of enabling multiarch?
<slangasek> given that you frequent #multiarch, I wonder if I'm being trolled: )
<scientes> lololol
<scientes> b/c its just one package...
<infinity> One package that you might want to get upgrades for automatically...
<scientes> aha, good point
<maxiaojun> jayco: https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&search=Search%20Bug%20Reports&field.scope=project&field.scope.target=ubuntu&orderby=-heat&start=0
<xnox> is it just me or svn 1.7 is fast and no longer has nested .svn directories everywhere?
<infinity> xnox: Both those things are true, yes.
<infinity> xnox: And if both these things had happened five years ago, people might care.
<jayco> maxiaojun: thanks for your patience. I will start at the link you have given me. Cheers.
<infinity> Damnit, I shouldn't have removed all my kernels before testing this change. :P
<slangasek> heh
<infinity> slangasek: Oh, the other thing Andy and I discussed was keeping headers in lockstep with the current kernels too (so, you'd potentially have 2 or 3 headers packages installed), so dkms can actually act on all installed kernels.
<xnox> infinity: just install a few from kernel ppa.
<scientes> depends linux-firmware:amd64 but it is not installable
<xnox> cause those should be cleaned up as well =)
<infinity> scientes: yeah, that may have been one of the deps Colin had to mangle.  If you just grab linux-firmware:amd64 from precise, it should work.
<infinity> scientes: (Cause it'll have the right M-A bits)
<slangasek> infinity: I'm less convinced headers handling warrants a backport since we've never done that part before
<infinity> slangasek: No, true.  Oh, actually, it can also be done outside of apt.  I think we once discussed having linux-image-$abi suggest linux-headers-$abi, which would be enough to keep it from being autoremoved, wouldn't it?  It's been a while since I tested the headers theories.
<slangasek> dunno
<infinity> Anyhow.  Can be looked at later.
<scientes> yeah i've filed many m-a bugs....i guess i'm just impatient when it comes to problems with legacy systems
<slangasek> I wouldn't expect Suggests to have that effect
<slangasek> scientes: then upgrade from the legacy system to 12.04 :)
<infinity> scientes: Well, the right answer is probably "don't run oneiric". ;)
<maxiaojun> scientes: I guess support period mostly means security fixes.
<scientes> maxiaojun, that is what it has always meant
<yofel> cjwatson: would you be so kind to refresh the kubuntu packageset please? I added ffmpegthumbs, kfloppy, kiten and pairs to supported as they're part of the KDE SC
<scientes> except for firefox, e.g.
<maxiaojun> scientes: exactly
<scientes> what is "gdb-multiarch"?
<infinity> scientes: The package description seems to shed some light...
<scientes> you mean like debug arm over ssh with gdbserver?
<scientes> from x86?
<infinity> Dunno.  I know about as much as the description tells me. :P
<scientes>  (i did read the description)
<scientes> aka includes all the disassemblers
<slangasek> ooh, I wonder if it's time to drop the ia32-libs package
<xnox> slangasek: ev: or cjwatson: please make "raring" the series goal of https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-wubi-publishing
<xnox> carry over from quantal.
<slangasek> xnox: done.. how's that recipe coming? :)
<slangasek> xnox: btw, somewhere along the line I thought I heard ScottK say "patches welcome" wrt the python-qt4 split?
<xnox> slangasek: there are a few things to be done (given the last analysis between me and ev) it might be half built & half pre-compiled binaries =)
<slangasek> tasty
<xnox> slangasek: after ScottK saw doko's patch to "fix" pykde4 against python3.3 (it was the last package) ScottK may now have reservations about _any_ patches.
<xnox> https://launchpadlibrarian.net/121171442/pykde4_4%3A4.9.2-0ubuntu2_4%3A4.9.2-0ubuntu3.diff.gz
<xnox> +    ${PYTHON_INCLUDE_DIR2}
<xnox> is an excellent variable name =)
<doko> f*ck cmake ...
<slangasek> doko: what about putting all the headers under the multiarch include path... so we don't have to fight with cmake anymore?
<xnox> my CMake patches were sensible as it has depricated the _DIR and _PATH variables and the PYTHON_INCLUDE_PATHS is actually a correct solution.
<doko> slangasek, thought about it, will break other configuration stuff, which checks for Python.h in /usr/include/pythonX.Y
<slangasek> cute
<slangasek> ok
<xnox> CMake implemented this after the first round of fighting with regular multiarch.
<cjwatson> yofel: I've refreshed it up to whatever the current data said, but I suspect that's only updated daily, so remind me tomorrow
<yofel> ok, thanks
<infinity> Gee, I really wish apt was one of those packages that ran configure on clean, that's so very convenient.
 * doko curses debhelper about LP: #1075146
<ubottu> Launchpad bug 1075146 in libxml2 (Ubuntu) "libxml2 2.9.0+dfsg1-3 FTBFS in raring" [High,New] https://launchpad.net/bugs/1075146
<xnox> infinity: jam and one other buildsystem does it as well.
<xnox> agree waste of time & will fail with flames at cross-arch build probably =)
<infinity> slangasek: New apt uploaded with discussed changes.  I'll take up the headers issue separately.
<stgraber> slangasek: so apparently merging my code into sru-report would make the report 15m slower to generate ;)
<slangasek> yeah let's not do that then
<slangasek> the report already knows about what versions are where
<slangasek> we really just need it to additionally check raring, and copy packages over as needed
<slangasek> er, tell us to copy packages that is
<slangasek> I'm not looking for this to report on all archive inconsistencies, I just want it to tell us when we should be using -d
<cjwatson> I think sru-release should work that out for itself
<stgraber> right, checking just raring should be fine, that's just an extra version check so doesn't take really long. What's really slow is when checking for older releases (oneiric and precise mostly) where we have hundreds of packages in -updates (langpacks mostly)
<slangasek> cjwatson: that works too
<cjwatson> it could easily say "quantal-updates == raring, obviously this should just be copied up" - or prompt about it if that makes people nervous
#ubuntu-devel 2012-11-07
<infinity> Having it automated when they're, in fact, equal, seems perfectly reasonable.
<stgraber> slangasek: for the full report on all supported releases: http://paste.ubuntu.com/1338655/
<stgraber> slangasek: maybe that kde langpack should be copied to precise-updates, looks like it was removed in quantal
<ScottK> slangasek and xnox: I guess I should modify and say 'sane patches welcome' wrt PyQt4 split.  I'm particularly interested in a sane way to determine appropriate dependencies since we're doing a more fine grained split than upstream.  FWIW, I agree with doko re CMake and Pytyon stuff.
<slangasek> stgraber: right, kde-l10n-kn copied
<pitti> Good morning
<jaaso> Allways get this error while trying to build ubuntu unity http://paste.ubuntu.com/1339148/, I am following this guide http://unity.ubuntu.com/getinvolved/development/unity/    :/
<sarnold> jaaso: is that the first error in the build output?
<jaaso> Yes
<sarnold> drat, there goes the usual easy first response :) hehe
<pitti> ev: ddebs.u.c.'s precise indexes ought to be better now, FYI
<jaaso> I tried to build unity yesterday on fresh ubuntu install, and have same error
<dholbach> good morning
<didrocks> bonjour dholbach
<dholbach> didrocks, bonjour mon ami - comment Ã§a va?
<didrocks> dholbach: bien occuppÃ©, mais Ã§a va! et toi? :)
<dholbach> oui - la mÃªme chose ici
<dholbach> :)
<jaaso> omg, fixed previous error, now I get this http://paste.ubuntu.com/1339290/. So annoying
<jaaso> I this DECLARE_LOGGER(logger, "unity.bghash"); should be in unity namespace. ...../unity/trunk/unity-shared/BGHash.cpp file
<pitti> Riddell, ScottK: FYI, I filed the PyKDE4 crash as bug 1075891
<ubottu> Launchpad bug 1075891 in pykde4 (Ubuntu Raring) "PyKDE4 broken with Python 3.3: ImportError: No module named 'DLFCN'" [High,New] https://launchpad.net/bugs/1075891
<ev> pitti: Thanks!
<apw> cjwatson, so i think i have .signature support prototyped out ok, but grub is picking them up as kernels; do we want to rethink the naming or fix grub
<apw> pitti, are you still the main man on .ddeb handing, and particularly reaping ?
<pitti> apw: yeah, I am
<cjwatson> apw: inclined to fix grub since I think any renaming would have to be obscurantist otherwise
<apw> pitti, so we seem to have lost the ddebs for 3.2.0-32 which is -security,-updates in preceise
<apw> cjwatson, we could consider having /boot/signature/vmlinuz-.....efi
<xnox> pitti: Riddell, ScottK: it's a bug in python3.3
<pitti> xnox: DLFCN is supposed to exist?
<cjwatson> apw: we could; do you think it's worth it?
<pitti> apw: looking
<cjwatson> I suppose it might look cleaner or something
<xnox> pitti: yes, it's /usr/lib/python2.7/plat-linux2/DLFCN.py & /usr/lib/python3.2/plat-linux2/DLFCN.py
<apw> cjwatson, i dislike both really for various reasons
<xnox> pitti: but completely missing in python3.3. There is an upstream bug that it was not being built on plat-linux3 (3.X kernels) but that was fixed.
<cjwatson> do we have to change grub anyway for this scheme to work?  I guess not ...
<xnox> pitti: I am guessing that DLFCN.py should be in a multi-arch location in python3.3 but I can't find it anywhere.
<apw> no as it stands we still make .signed kernels as kernels
<apw> and they get picked up as one would hope
<apw> the signature is just noise, and generally not even usable by the user without effort
<cjwatson> Maybe it shouldn't be in /boot at all?
<cjwatson> It's not needed at boot time
<xnox> pitti: there is /usr/lib/python3.3/plat-x86_64-linux-gnu/IN.py in the package libpython3.3-stdlib ....
<cjwatson> So strictly it should be in /usr or something
<pitti> xnox: ah, so the multiarch handling works in general, just not for DLFCN?
<xnox> pitti: yeah.... nor for CDROM nor TYPES
<apw> thats a fair statement indeed -- it could go almost anywhere
<pitti> apw: do you know when it disappeared?
<apw> pitti, i don't, smb has an email informing us
<smb> pitti, Not really I just saw an email complaining about it from a user yesterday
<pitti> apw: hm, only the armel ones are left indeed
<pitti> meh
<apw> its an odd combination indeed
<pitti> apw, smb: they were built more than 7 days ago though, so I'm afraid there's nothing I can do now
<pitti> we just have to stop the madness of how we currently handle ddebs :(
<pitti> apw: 33 is there, when is that due for release?
 * smb guesses maybe two more weeks
<apw> pitti, 'real soon now' i believe
 * pitti hopes we can get ddebs into Launchpad librarian soon
<pitti> infinity: ^ do you know how we can/should test this? uploading a new pkg-create-dbgsym to staging and doing a test build there? or would that not suffice?
 * pitti is a bit afraid to break LP when uploading it to raring
<apw> pitti, heh yeah that sounds like a bit of a nightmare
<apw> pitti, if by magic we had a copy would you be able to reinsert them and then perhaps figure out why they went missing ?
<pitti> apw: we can reinsert them, yes
<pitti> apw: as for why they went AWOL, I'm not sure
<pitti> apw: the whole mechanics how this archive is created is insanely brittle and slow
<apw> pitti, ahh i guess they may not have appeared even
<apw> pitti, so they must have been there as carbou has a copy
<pitti> ddebs@macquarie:~$ ping carbou.canonical.com
<pitti> ping: unknown host carbou.canonical.com
<pitti> hmm
<pitti> apw: can you toss me an URL?
<apw> pitti, heh caribou is someone in L3 who keeps copies against loss like this
<apw> pitti, working on getting them somewhere
<pitti> oh, mind the "i" :)
<apw> pitti, ok we seem to have some general issue here ... smb is telling me we have a number of older ones there, but generally the ones in -security are missing
<apw> pitti, if what smb is saying in my ear is right then we might be keeping the right number but the wrong ones
<smb> Seems at least true for Oneiric and Lucid
<pitti> hm, my cron jobs have all -updates and -security pockets
<smb> 2.6.32-44.98 (has only versatile), 3.0.0-26.43 (only has omap)
<smb> pitti, Could it miss a "not"? :) We seem to have kept all we don't care about and deleted the ones we do...
<apw> pitti, ok if you look just at 2.6.32-* (http://ddebs.ubuntu.com/pool/main/l/linux/) we have like every abi from release to now other than the one in -updaes or something ?
<pitti> smb: I'm fetching the Packages.gz from the archive and find out which ddeb needs to go in which index by comparing pkgname + '-dbgsym' and version numbers
<pitti> there's no negation involved
<smb> pitti, Just nagging. ;) Otherwise nothing would be left in some way
<pitti> but yeah, it looks strange
<pitti> it might be due to the fact that we never really NBS out old ABIs in stables?
<caribou> pitti: apw smb I have been mirroring them on a server in Mtl for a while. Not sure if everything is there though
<apw> caribou, yeah great, we may want some of those indeed
<xnox> doko: so there are two python3.3 bugs now: https://bugs.launchpad.net/ubuntu/+source/python3.3
<smb> caribou, could you get together with pitti and let him know how to access the copies?
<doko> xnox, cute
<caribou> smb: ok
<xnox> doko: yeah =/  enjoy multi-arch?!
 * xnox really needs to get hardware to build gcc/python quickly.
<xnox> doko: the DLFCN one is important, the DLDLIBRARY is a nice to have type of thing.
<caribou> smb: regarding Bug #1064475, I'll speak with arges later on. Don't know why he got it
<ubottu> Launchpad bug 1064475 in crash (Ubuntu) "crash version is outdated. Needs to import Debian version of the package" [Medium,In progress] https://launchpad.net/bugs/1064475
<caribou> pitti: ddebs for 3.2.0-32 are here : http://people.canonical.com/~lbouchard/precise_ddebs/
<pitti> caribou: cheers!
<caribou> pitti: just let me know if you need more, got 400Gb of them :-)
<smb> caribou, Just want to make sure he and I spent time on it and I was hoping to get that completed soon. So yeah, I will try to talk to him too
<caribou> smb: what was the outcome of the Ubuntu specific module ? do we want it submitted upstream or we just drop it ?
<smb> caribou, There is not really an outcome there. As far as I know it got in for ps3 stuff. Not sure one would still need it. I would leave it in for now and thought to get in touch with Ben. But given the unclear heritage I thought it would not really be useful to approach him without being able to fill in a bit of background,.
<caribou> pitti: regarding ddebs mirroring, I only mirror {flavor} & {flavor}-updates. Should I include the security bits ?
<pitti> caribou: in many cases they should be identical; it certainly cannot hurt to mirror them
<pitti> caribou: at least until we get ddebs into the LP librarian
<caribou> pitti: ok, I will see if I have enough diskspace to get them
<smb> caribou, pitti, Sorry if I missed the info in the various thread, but if the reason for the disappearance is found, can you also bring back the Lucid and Oneiric ddebs from updates/security (both the same in those cases)
<jaaso> Should I bulid anything else except nux for latest unity, unity.ubuntu.com/getinvolved/development/unity/#build-unity. Still have damn problem with this line of code from BGHash.cpp  "DECLARE_LOGGER(logger, "unity.bghash");"
<cjwatson> jaaso: #ubuntu-unity might be more likely to contain experts
<jaaso> cjwatson, thanks.
<apw> cjwatson, this signing data, so reading the FHS i think /usr/lib/linux might be an appropriate place, as the signatures are architecture specific and overlap i386/amd64
<apw> cjwatson, now ... that brings up a question, now that the kernel is multi-arch are the binary names in /boot wrong as they can clash across multi-arch architectures
<pitti> apw, caribou: put the 3.2.0-32.51 .ddebs back to http://ddebs.ubuntu.com/pool/main/l/linux/, thanks! I'm rebuilding package indexes now and then see what is wrong with that
<apw> pitti, great ...
<cjwatson> apw: The kernel is only Multi-Arch: foreign, not Multi-Arch: same, so doesn't have to worry about coinstallation across multiple architectures
<apw> cjwatson, ahh ok, of course
<cjwatson> (Or is it even that?  It perhaps should be, but linux-image-3.5.0-18-generic doesn't seem to have that header here)
<cjwatson> Anyway, it's multiarch-installable, which is more about the kernel's dependencies than the kernel itself
<cjwatson> apw: I agree that /usr/lib/linux is reasonable if you don't have any other suitable existing directory
<apw> cjwatson, is it reasonable to use a srcpackage prefix in /usr/lib ?
<cjwatson> Yes
<cjwatson> It only matters that it not clash with other stuff
 * apw rechecks
<cjwatson> And /usr/lib/linux/ is unused
<cjwatson> So you should be fine there
<apw> i suppose i could dump it in the /lib/modules/<version> directory too
<apw> bu then we'd have to worry about clashes with kmod thinking on the meanings
<apw> why is naming the hardest part
<cjwatson> I don't see any reason this would need to be in /lib
<apw> no there would be no reason to need it early
<cjwatson> /boot is needed by the boot loader, and /lib is needed during early boot; this is only needed when installing the package, so /usr
<apw> sold to the man in the hat
<cjwatson> And it's architecture-dependent as you say so /usr/lib
<cjwatson> Seems like fairly solid reasoning :)
<pitti> apw, smb: they are back in http://ddebs.ubuntu.com/dists/precise-security/main/binary-amd64/Packages as well now
<pitti> so something is wrong with the cleanup apparently
<pitti> they do appear, and then disappear after some time
<apw> pitti, want us to look at the logic ?
<pitti> apw: if you want, sure; it's on my list for today as well, just finishing up with gvfs
<pitti> but more eyes are always better
<apw> heh except when they arn't :)
<pitti> http://bazaar.launchpad.net/~pitti/+junk/ddeb-retriever/files
<pitti> hm, I ought to add quantal for ports, argh
<mlankhorst> hm so maybe I picked up something from uds after all :(
<scott-work> is there a convention to mark blueprints for previous releases as 'obsolete' or otherwise?
<mdeslaur> @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 dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
 * dholbach hugs mdeslaur
 * mdeslaur hugs dholbach back
<caribou> smb: can I drag you in a mumble discussion with arges on crash ?
<caribou> s/on crash/about crash/
<menace> is there any document which describes the various codewords in release-files in .deb-repositories?
<menace> like FakeCodename, Origin, Suite, Pull or stuff like that?
<herton> @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 dicussion 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: herton, mdeslaur
<cjwatson> Never heard of either FakeCodename or Pull
<pitti> xnox: OOI, what does http://launchpadlibrarian.net/122171219/ubuntu-drivers-common_1%3A0.2.71ubuntu1_1%3A0.2.71ubuntu2.diff.gz do?
<pitti> xnox: also, I'll drop the ${python3:Depends} again; nvidia-common is a transitional pacakge, and dh-modaliases is perl
<menace> cjwatson: we need that because of building against codename, but distributing than for codename/x.y.z AND codename/x.v.z... problems are reoccurring with that. :)
<pitti> xnox: --shebang isn't documented in dh_python3, and I haven't seen it before
<cjwatson> I actually can't find any particularly obvious documentation of the Release file right now
<pitti> xnox: ah, so previously it said #! /usr/bin/python3.3
<cjwatson> Some of it is sort of documented indirectly in apt_preferences(5)
<menace> where do you look for it? i already tried to look through the blueprints, but there are too much with "repository" in it :D
<cjwatson> Actually fairly directly
<OdyX> menace, cjwatson: Debian #671503
<ubottu> Debian bug 671503 in debian-policy "document APT repository format" [Wishlist,Open] http://bugs.debian.org/671503
<cjwatson> under "Determination of Package Version and Distribution Properties"
<cjwatson> menace: The Release file format predates Ubuntu, so there's no point looking for it in Ubuntu bluepritns
<cjwatson> *blueprints
<cjwatson> 'man apt_preferences' is the best I can find
<menace> ah, that are a few starting points, thx :)
<OdyX> menace: in particular, jak's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671503#67
<ubottu> Debian bug 671503 in debian-policy "document APT repository format" [Wishlist,Open]
<OdyX> menace: which then leads to http://wiki.debian.org/RepositoryFormat
<cjwatson> Ah, excellent, yes
<OdyX> :)
<menace> Thank you, that looks quite right! :-)
<pitti> update-initramfs: Generating /boot/initrd.img-3.5.0-18-generic
<pitti> WARNING: could not open /tmp/mkinitramfs_OiW40C/lib/modules/3.5.0-18-generic/modules.builtin: No such file or directory
<pitti> apw: ^ should this worry me?
<pitti> apw: it's (one of two) reasons why ubuntu-drivers-common's autopkgtest currently fails
<apw> pitti, no not really, it is wrong, it is a bug in initramfs-tools which i thought infinity had a fix for
<pitti> so is it okay to leave that as a failure for now?
<pitti> instead of ignoring, I mean
<apw> it is wrong but not the end of any worlds, we should have that file in there but we can live without
<apw> yeah, i recon
 * pitti uploads the other half of the fix in bcmwl
<cjwatson> can anyone reproduce the python-apt/raring-proposed build failure?
<cjwatson> I can't make it happen in a local sbuild
<xnox> pitti: yeah need to open a bug about documentation. It's not in the manpage, but it is in the dh_python3 --help
<xnox> pitti: sorry about extra ${python3:Depends} dpkg-gencontrolled complained about unused substitute variables, maybe dh_python3 should be run with "-pubuntu-drivers-common" or something.
<xnox> pitti: feel free to revert any bits, as long as the shebang end's up as python3 on the python scripts =)
<pitti> xnox: yep, I kept that bit and committed it to git
<pitti> doing a few other fixes now
<xnox> cool.
<Laney> cjwatson: yeah, fails that way here
<Laney> @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 dicussion 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: herton, mdeslaur, Laney
<Laney> herton: mdeslaur: How can we avoid colliding? :-)
<mdeslaur> Laney: uhm, let's just say here what we're looking at
<mdeslaur> herton, Laney: I'm working on vim and rhythmbox
<herton> Laney, don't worry about me, I can just look on kernel bugs
<Laney> ok
<Laney> I'll start from the bottom
<cjwatson> Laney: any chance I could impose on you to figure out what's going wrong, since it's hard to do so without a reproducer?
<herton> s/just/only
<Laney> cjwatson: piloting now, but I will later if and when I get the chance
<xnox> pitti: jodh: bug 1075976
<ubottu> Launchpad bug 1075976 in upstart (Ubuntu) "test-suite fails in autopkgtest environment" [Undecided,New] https://launchpad.net/bugs/1075976
<xnox> have fun =)))) I'm stuck.
<jodh> xnox: looking...
<cjwatson> Laney: I'm trying with one of the official chroots now to see if it's some tedious discrepancy at that level
<Laney> cjwatson: mine were created with mk-sbuild FWIW
<cjwatson> So were mine
<Laney> ho hum
<mdeslaur> Laney: I'll take php5 LP: #1069529
<ubottu> Launchpad bug 1069529 in php5 (Ubuntu) "Regression in system fallback for date_default_timezone_get()" [Medium,Triaged] https://launchpad.net/bugs/1069529
<cjwatson> Laney: I can't even reproduce this with the official i386 chroot :-(
<Daviey> cjwatson: you grabbed the chroot from LP?
<cjwatson> Yes
<Daviey> cjwatson: I had a FTBFS last year that i could not reproduce locally using the locally generated chroot with either pbuilder or sbuild.. Grabbing the one from LP, i could reproduce with one of the build tools.. but not both.. can't remember which now.
<infinity> pinky: Merging initramfs-tools will fix that, I'll get to that today.
<cjwatson> guessing you mean pitti
<pinky> me too
<infinity> pitti: ^
<infinity> cjwatson: I sure did.
 * infinity has never made that tab-completion mistake before...
<tazz> Hey, in unity if my application uses the system notification which requires user action, would i be able to do that?
<xnox> tazz: app-development on ubuntu -> #ubuntu-app-devel . And yes, a gtk fallback dialog with buttons will be shown instead of a translucent bubble.
<xnox> tazz: in general don't do that, instead color your indicator read and have a red menu/action item there.
<doko> are CFLAGS etc still exported by dpkg-buildpackage?
<cjwatson> Not as of quantal
<cjwatson> specifically dpkg 1.16.1.2ubuntu8
<doko> but by dh_auto_build apparently :-/
<doko> $ DH_VERBOSE=1 debian/rules build
<doko> dh build --buildsystem=autoconf
<doko>    debian/rules override_dh_auto_build
<doko> make[1]: Entering directory `/home/packages/python/3.3/mpdecimal-2.3'
<doko> env | grep CFLAGS
<doko> CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
<doko> dh_auto_build
<doko>         make -j1
<doko> make[2]: Entering directory `/home/packages/python/3.3/mpdecimal-2.3'
<doko> gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c basearith.c
<doko> In file included from basearith.c:36:0:
<doko> typearith.h:251:4: error: #error "need platform specific 128 bit multiplication and division"
<doko> make[2]: *** [basearith.o] Error 1
<xnox> doko: but you can set an option for those to be exported.
<cjwatson> doko: debhelper 9?
<cjwatson> if so that's a feature
<doko> gah ... how to turn this off?
<xnox> cjwatson: rm -rf /etc/apt/preferences.d/ && debuild => fail like in the build log.
<xnox> cjwatson: the error appears to be comming on stderr from apt itself since it's printed even after a $ apt-get update
<cjwatson> doko: you can set DEB_CFLAGS_MAINT_STRIP in debian/rules to remove individual exports
<cjwatson> xnox: huh, I thought I'd tried that
<xnox> cjwatson: in a raring sbuild chroot.
<xnox> I think I had the same weirdness with test-suite of apt-clone or something like that....
<cjwatson> ok, I'll give it another go, thanks
<cjwatson> although the LP chroots contain /etc/apt/preferences.d/ (empty)
<xnox> same here... but deleting it here, made the error appear.... dunno what's going on.
<doko> cjwatson, not that useful, if the flags are taken in the configure step, upstream adds something to these, and then they are overwritten in the build step. I think I'll just use v8 and do the multiarch stuff myself
<doko> DEB_CFLAGS_MAINT_STRIP is for removing stuff in an export, not removing the export afaics
<ogra_> jono, poke
<cjwatson> doko: just export an empty CFLAGS then?
<jono> hey ogra_
<jono> (otp)
<cjwatson> doko: if the environment variable exists (not just is non-empty), debhelper won't touch it
<ogra_> jono, ping me when you are free
<jono> ogra_, will do, feel free to type ina  msg and I will respond when I can
<ogra_> jono, so i have this blueprint ... https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-rebuild-gl-games-for-gles which is rather "get the community to pick low hanging fruit and make ubuntu prettier" than anything else ... the spec is currently desktop- but i think it would fit better under the community- umbrella
<xnox> ogra_: isn't it motu stuff?
<ogra_> xnox, surely that as well
<ogra_> i think its bigger than just motu
<ogra_> after all it will stretch into main as well as debian
<ogra_> (i.e. the "Add good C/C++ practise to developer.ubuntu.com" likely is more than jst motu)
<infinity> cjwatson: What chroot-related failure were you and Laney looking at?  I'm having no luck with backscroll.
<cjwatson> infinity: python-apt/raring-proposed
<Laney> python-apt ftbfs
<doko> cjwatson, yes but it doesn't help, it's already configured by the upstream configury
<cjwatson> doko: uh, I mean at the top level of debian/rules
 * infinity likes that it succeeds on the one arch that always fails.
<cjwatson> since that runs before configure there's no "already"
<cjwatson> infinity: I guess that might indicate I could try throwing it against the wall a few times ...
<infinity> cjwatson: If it's a race, it should probably be hunted down.
 * infinity thinks the contents of /etc/apt/preferences.d is a red herring, since it's the same on all arches.
<cjwatson> Yeah
<Laney> cjwatson: so I just managed to reproduce it on a cloud instance
<Laney> raring on quantal didn't reproduce, but precise did
<Laney> raring on precise, that is
<cjwatson> wtf
<Laney> I can just authorized_keys you up if you like
<cjwatson> please
<xnox> cjwatson: I am raring on raring.
<cjwatson> Laney: racy or every time?
<Laney> only tried once
 * Laney does again
<Laney> I tried thrice or so on my system here though, failed every time
<Laney> ssh ubuntu@10.55.63.164
<Laney> yeah, just failed again
 * cjwatson tries
<cjwatson> argh, other sbuild instances have the normal upstream default of purging the session on failure :)
<xnox> cjwatson: schroot, then build... =))))))
<cjwatson> Or I could just use -p never --purge-session never
<Laney> just change .sbuildrc
<Laney> this is the one that mk-sbuild auto-generates :-)
<cjwatson> *shrug* my second build's already in progress so y'all can stop bikeshedding me :)
 * Laney slinks off back to the queue
<cjwatson> So /etc/apt/preferences.d/ is indeed definitely a red herring; creating that directory in the test environment makes no difference apart from silencing the warning
<xnox> cjwatson: and the tests still fail? interesting.
<mterry> stgraber, hello!  As discussed before 12.10's release, deja-dup now has separate metapackages for its supported backends, and the ubuntuone backend is not installed by default.  So edubuntu can seed the backend it prefers (I assume deja-dup-backend-s3)
<mterry> stgraber, oh shoot
<mterry> stgraber, it wasn't edubuntu...  it was gnome3 I think.    ^ jbicha
<stgraber> mterry: yeah, sounds like gnome3, we have ubuntuone in edubuntu :)
<mterry> stgraber, and no deja-dup I believe  :)
<stgraber> mterry: hmm, no, we should have it, we inherit from ubuntu-desktop
<mterry> oh.  seeded-in-ubuntu deja-dup only gave me the daily-live
<jbicha> mterry: yeah, edubuntu-desktop depends on ubuntu-desktop
<stgraber> mterry: ah yeah, seeded-in-ubuntu doesn't know that we seed it as edubuntu didn't get a succesful dvd build yet for raring
<mterry> ah fair enough
<mterry> jbicha, anyway, hopefully the gnome3 seeds can be done more nicely now wrt deja-dup
<SpamapS> slangasek: Where do we stand with upstart jobs alongside init scripts in Debian packages?
<superm1> can an archive admin axe the build of mythtv in raring proposed?  looking over the build log, something is wrong with it - it shouldn't be producing a NEW libmyth 0.27 binary package - it should be a NEW libmyth 0.26, so I need to investigate a little closer what went wrong with the build scripts
<Laney> diwic: is bug #973014 comment #76 the thing to sponsor there?
<ubottu> Launchpad bug 973014 in gst-plugins-bad0.10 (Ubuntu Quantal) "gstreamer0.10-plugins-bad, (libgstvideoparsersbad.so), causes a failure to decode many common video files encoded as AVC 1 Baseline - L2.1, Baseline - L1.1 & others" [High,Confirmed] https://launchpad.net/bugs/973014
<Laney> and is it fixed in R?
<Laney> actually, I'd like some information about the origin of the patch in DEP3 headers if you can provide that
<SpamapS> Specified release (raring) not known to debootstrap
<slangasek> SpamapS: the infrastructure is all in place so that you can put them in the Debian package and debhelper (and friends) will DTRT; the only outstanding bit is that if someone happens to actually be running upstart in Debian, it will probably break for them
<SpamapS> shouldn't we have already SRU'd that to quantal? :p
<Laney> we did
<SpamapS> slangasek: oh.. thats unfortunate.
<slangasek> SpamapS: (because upstart in Debian is still ancient, for a little while longer, and therefore uninteresting for anyone to run)
 * SpamapS checks for updates
<Laney> not been promoted to updates yet
<SpamapS> slangasek: I'm just thinking to resolve package deltas
<SpamapS> Laney: ahhh
<Laney> maybe it should be done early though, given the amount people are complaining
 * SpamapS now wonders why he's not running -proposed
<slangasek> SpamapS: at this point I think you should probably feel free to push those jobs to Debian
<SpamapS> slangasek: sweet!
<SpamapS> slangasek: that was the last bit preventing resolving the delta for mysql. :)
<slangasek> SpamapS: because as soon as my udev NMU goes in (currently in DELAYED), I'll upload the new upstart and we'll be good
<SpamapS> slangasek: Seems I'll finally be able to switch my Debian VM to upstart! :)
<Laney> @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 dicussion 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: herton, mdeslaur
<mdeslaur> @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 dicussion 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: herton
<GunnarHj> herton: Hi Herton!
<GunnarHj> herton: Saw that you are piloting... I have a few items in the sponsorship queue, and the most urgent are the MP + SRUs at http://pad.lv/875435, since they affect quite a few Asian users. It's really the SRUs that are interesting, but I suppose we should do it in the right order. Do you have time to take a look? The MP is reviewed and approved.
<ubottu> Launchpad bug 875435 in OEM Priority Project precise "iBus indicator does not show on the panel" [Medium,In progress]
<herton> GunnarHj, sorry, I can only look into kernel bugs
<GunnarHj> herton: Aha, didn't know that. Guess it has to wait til tomorrow, then.
<herton> @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 dicussion 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:
<bdmurray> @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 dicussion 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: bdmurray
<sarnold> GunnarHj: pssst new pilot arrived :)
<GunnarHj> sarnold: Thanks! :)
<sarnold> :)
<GunnarHj> bdmurray: Hi Brian!
<GunnarHj> bdmurray: Saw that you are piloting... I have a few items in the sponsorship queue, and the most urgent are the MP + SRUs at http://pad.lv/875435, since they affect quite a few Asian users. It's really the SRUs that are interesting, but I suppose we should do it in the right order. Do you have time to take a look? The MP is reviewed and approved.
<ubottu> Launchpad bug 875435 in OEM Priority Project precise "iBus indicator does not show on the panel" [Medium,In progress]
<bdmurray> GunnarHj: sure, just a moment
<GunnarHj> bdmurray: Great! :)
<sarnold> GunnarHj :)
<GunnarHj> sarnold: Your tip was fruitful. Thanks again! ;-)
<bdmurray> GunnarHj: okay, I've had a look and it seems fine
<GunnarHj> bdmurray: Great. Do you have upload right?
<bdmurray> GunnarHj: I do indeed
<GunnarHj> bdmurray: Then, could you upload both to raring and to -proposed for the stable releases?
<bdmurray> GunnarHj: right, I'll do that
<GunnarHj> bdmurray: I prepared separate branches for O, P and Q.
<darkxst> bdmurray, are you able to take a look at this sru https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724?
<ubottu> Launchpad bug 1073724 in xorg-server (Ubuntu) "Pointer barriers have gaps along the edge of the screen" [Undecided,Confirmed]
<bdmurray> darkxst: for the SRU to be considered for quantal the bug first needs to be fixed in the development release (raring in this case)
<bdmurray> darkxst: otherwise the bug description looks good
<bdmurray> darkxst: also did you try to determine why that patch was added and exists in the package?
<darkxst> bdmurray, that patch does the sticky edges in unity
<darkxst> i.e. pointer barriers with a velocity threshold
<darkxst> bdmurray, I will test it under raring then
<bdmurray> darkxst: you might also check with the X developers in #ubuntu-x
<darkxst> bdmurray, ok, will do
<yofel> cjwatson: hi, did you have a chance to look at the kubuntu packageset update?
<dobey> can sokmeone confirm for me that the only thing depending on desktopcouch in quantal/raring, is dmedia?
<diwic> Laney, thanks for having a look - when I made the SRU for Q and P the R archive wasn't opened
<micahg> dobey: yes, you can also use reverse-depends from ubuntu-dev-tools
<diwic> Laney, still around?
<dobey> micahg: right; just wanted secondary confirmation. :)
<dobey> micahg: for this: https://bugs.launchpad.net/ubuntu/+source/dmedia/+bug/1076123 :)
<ubottu> Launchpad bug 1076123 in dmedia (Ubuntu Raring) "Remove desktopcouch from Ubuntu archives" [Undecided,New]
<dobey> actually; i wonder if we could remove them from quantal also? :)
<micahg> dobey: no
<dobey> bribes with fun dip? :)
<micahg> dobey: I've ack'd dmedia and desktopcouch is in your packageset, so you can go ahead and subscribe ubuntu-archive
<dobey> dmedia is in my packageset?
<micahg> dobey: that's not what I said...
<dobey> oh
<dobey> actually, i should add couchdb-glib to that too, probably
<dobey> couchdb-glib isn't in the u1 packageset though
<infinity> dobey: How does couchdb-glib relate?
<dobey> infinity: it includes a C binding to desktopcouch. just realized removing desktopcouch might break that, so we should remove it as well (as nothing is using it any more, since apparently evolution-couchdb was already removed in quantal)
<infinity> Yeah, nothing depends on it, not in Debian, etc.  Check.
<dobey> so, frabjous day! :)
<infinity> dobey: Done.
<dobey> infinity: thanks much
<barry> cr3: ping
<cjwatson> yofel: done now
<yofel> cjwatson: all there now, thanks a lot!
<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 dicussion 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: bdmurray, xnox
<cr3> barry: pong, wazap?
<barry> cr3: hi.  i think i answered my own question.  checkbox was ported to python3 in quantal, right?
<cr3> barry: yep
<barry> cr3: awesome!  i was just doing some blueprint gardening.  thanks
<cr3> barry: we're really happy to have done our part in that effort
<barry> cr3: very much appreciated
<cr3> barry: we'll be migrating to go during raring
<barry> cr3: :(
<cr3> barry: j/k, wanted to see your reaction :)
 * barry uncocks the hammer
 * cr3 walks back slowly
<barry> :-D
<bdmurray> @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 dicussion 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> @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 dicussion 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:
<mightyiam> hiiiiiiiii why does 'do-release-upgrade -d' on quantal doesn't give me a new release?
<slangasek> bdmurray: ^^ metarelease update needed?
<slangasek> mightyiam: do-release-upgrade queries a central server to find out about the availability of releases and their release/support status; it seems the server needs updated
<mightyiam> thanks, steve
<chilicuil> mightyiam: however you can replace 'quantal' for 'raring' in your /etc/apt/sources.list file to upgrade to raring
<mightyiam> chilicuil, just like a good 'ole release upgrade in debian? even since ubuntu i'm using the upgrader tool. ok. thanks
<slangasek> the release-upgrader is Strongly Recommendedâ¢, but particularly this early in the cycle a plain dist-upgrade should work fine
<slangasek> janimo: hey there!  how come you're using a native package for linux-nexus7?  is there no "upstream" tarball to preserve?
<bdmurray> slangasek: I'll have a look at metarelease
#ubuntu-devel 2012-11-08
<ironhalik> Hello
<ironhalik> I'm wondering about licensing issiues regarding ubuntu development
<ironhalik> I'm working on an enterprise app that would interface with my software on Ubuntu
<ironhalik> the android app would be paid, the Ubuntu part is intended to be open sourced on via launchpad
<ironhalik> can I use any part of Ubuntu logo on the paid android app?
<slangasek> ironhalik: http://www.ubuntu.com/aboutus/trademarkpolicy
<slangasek> ironhalik: (short answer: no)
<ironhalik> Or I need to contact canonical :>
<ironhalik> Thanks for the link
<GunnarHj> bdmurray: still there?
<bdmurray> GunnarHj: yes
<GunnarHj> bdmurray: Good. I don't see any signs in Launchpad of your SRU uploads.
<bdmurray> GunnarHj: well its there - https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1
<bdmurray> GunnarHj: somebody from the SRU admin team needs to approve it so it ends up in -proposed
<GunnarHj> bdmurray: Aha, didn't know that. Thanks!
<ubuntu_user2> Hello. If anyone is willing to help, I'm having a unique problem in 12.04
<mfisch> robert_ancell: can we mark this as fix released?  seems to be fixed in Q: https://bugs.launchpad.net/ubuntu/+source/gcalctool/+bug/926676
<ubottu> Launchpad bug 926676 in gcalctool (Ubuntu) "False result after special character input" [Medium,Fix committed]
<robert_ancell> mfisch, yes, if it's in quantal
<mfisch> robert_ancell: it is as far as I can tell
<pitti> Good morning
<pitti> infinity: initramfs-tools> pinky thanks!
<infinity> pitti: Thank me when I get it done.  Working on an obscure glibc bug right now. :P
<pitti> cjwatson: FYI, just filed bug 1076237; nice example of how autopkgtest detects regressions introduced by a new proposed apt :)
<ubottu> Launchpad bug 1076237 in apt (Ubuntu) " /etc/kernel/postinst.d/apt-auto-removal creates comment with invalid # character" [Undecided,New] https://launchpad.net/bugs/1076237
<infinity> pitti: Except that it got the regression target wrong.
<infinity> pitti: Unless you meant "this is a regression IN $version"... "from" makes it sound like that version was okay.
<pitti> infinity: what I meant is that this upload introduced the wrong "#" comment
<infinity> pitti: Ahh.  The wording was ambiguous, then. ;)
<pitti> infinity: so grammatically, "regression in <that version>" is better?
<infinity> pitti: Or, rearrange the sentence entirely to "This regression appeared in $version"
<pitti> even better :)
<persia> When talking about regressions, I think it's important to not only mention when it was introduced, but also against which version it is being compared (as this may not always be the immediately prior version, for example when discovering regressions during release upgrade testing)
<infinity> autopkgtest doesn't necessarily have a concept of which version worked, only that the current one's broken.
<persia> True :(
<infinity> It's assumed to be a regression only because we assume the tests all currently pass.
<infinity> (Which won't be true in the case of racy and nondeterministic test-suites, but we need to stamp those out)
<pitti> yeah, autopkgtest didn't tell me that, I just reviewed the diffs and checked which upload introduced it
<persia> all tests passing also isn't true if we start TDDD, where we define the behavioural tests prior to patching packagegs.
<infinity> persia: You may have one too many Ds.
<persia> I most decidedly don't.
<infinity> Test-driven dessert development?  Yum.
<persia> Test driven distribution development
<persia> See liw's blog posts from ages ago
<lifeless> o/
<persia> lifeless: Is the highlight on "TDD" or "TDDD" or just fuzzy neural matching semantics beneath the threshold of conciousness?
<lifeless> godlike powers of observation
<persia> Ah, I knew it was something
<persia> infinity: So, anyway, the point being that there are ongoing discussions that would lead to actions diametrically opposed to stamping out tests that fail, although the concept of expected-to-pass and expected-to-fail need to be introduced to Jenkins for things to be sensible before that happens.
<persia> (whlie liw's blog posts are old, some of these discussions were active in the just passed UDS)
<pitti> I think at the beginning cjwatson only wanted to introduce blocking on autopkgtest regressions
<persia> That's my understanding also.
<infinity> persia: I consider an XFAIL a pass, from the POV of not regressing.
<pitti> i. e. if a package test already fails in -release, a -proposed failure wouldn't block
<persia> infinity: Excellent then.
<pitti> that's still a bad situation of course, as eternally failing tests render the whole idea moot
<infinity> (Granted, I'd prefer if all our software were in a state where XFAIL wasn't ever needed, but whatever)
<persia> pitti: Are we running against -release for comparison, for packages that haven't been updated since warty?
<pitti> persia: yes, we run both
<pitti> https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/
<persia> Ah, then I misunderstood.  Excellent.
<pitti> we started with that, and in quantal we introduced testing against -proposed, too
<persia> pitti: Thanks for the quick overview: helps me to catch up :)
<infinity> pitti: Anyhow, yay for it catching a bug, fix uploaded.
<pitti>  infinity: oh, thanks; I was going to wait for mvo for upstreamization, etc.
<infinity> pitti: This isn't upstream.
<pitti> so I guess we don't really want to support the # character there then
<infinity> pitti: No, it's a pleasant coincidence that some bits of apt respect POSIX shell style comments, but the only documented correct comment style is C++.
<pitti> funny debdiff (http://launchpadlibrarian.net/122343308/apt_0.9.7.6ubuntu2_0.9.7.6ubuntu3.diff.gz)
<infinity> pitti: So, was just a goof on vorlon's part when he used #, that's all.
<pitti> yay for having autom4te.cache in packages..
<infinity> Yeah, apt's build system is a mess.
<infinity> Refreshing the po files on every version bump is lunacy too.
<pitti> so, thanks!
<pitti> infinity: btw, I found that "debuild -S -nc" helps with those cases
<pitti> but yes, it's still mad
<pitti> and more important for SRUs
<infinity> pitti: I use -nc all the time, I don't -nc apt intentionally cause this is also how it updates its version.
<infinity> (Granted, the version will update on clean during the build, but it'll be wrong in the source until then)
<persia> Um, isn't needing to use -nc a bug as clean wouldn't be idempotent?
<infinity> persia: clean is idempotent for apt.
<infinity> persia: If you mean to use the actual meaning of the word. :P
<persia> I think I mean that when you do it, and you do it again, and you do it again, and you do it again, and you get sick of doing it, you notice that doing it once got the same result as doing it all the extra times.
<infinity> Right, that's what it means.  And it is.
<pitti> the problem here is what it does at the first time :)
<infinity> It's that the first run of clean won't leave you at the same state as you were pre-clean.
<infinity> Doing it 17 more times won't change state.
<persia> But I don't understand how this could be important for SRUs, as presumably the last upload was also clean.
<infinity> (Well, except for automate.cache jumping line ordering around, but we'll ignore that)
<pitti> persia: I meant, it's better to have minimal diffs for SRU reviews
<infinity> persia: It just makes SRU diffs more readable, other than that, it matters not.
<pitti> rather than diffs which are full of autom4te and .po update noise, which make the actual changes harder to see
<infinity> And, honestly, our SRU reviewers are smart enough to filter noise from diffs.
<persia> pitti: Sure, but if I didn't upload -nc last time, I presumably ran clean, so I don't see how running clean again generating a different diff should not be considered a bug.
<infinity> persia: Every new version/upload will change some bits on clean.  That's not a problem.
<pitti> infinity: actually, I don't think it's idempotent as the .po file timestamps would always change
<infinity> (Well, it's a horrible build system and silly decision, but it's not actually buggy, just gross)
<infinity> pitti: Well, okay.  True.  It's logically idempotent, but not literally. :P
 * persia agrees with pitti, but admits that this is considered unimportant
<infinity> Anyhow, fixing that mess is somewhere low on the TODO of pretty much everyone who's ever uploaded the package.
<infinity> One of us will get annoyed enough to do it some day.
<persia> Ah, then it is a bug, just not an important bug.  My worldview is restored.
<infinity> It's only a bug in the world where "wishlist" = "bug", which is questionable in some people's minds.
<infinity> It's a feature request that the build system not suck.
<infinity> It's not buggy that it does suck.
<infinity> (In that it produces sane results, just suboptimally)
<infinity> Hrm.  I need to file a UI bug with Android: "Please don't tick the battery meter down on the lockscreen when I'm staring at it".
<infinity> Rather disconcerting.
<infinity> It may as well make a sucking noise while it's doing it.
<jk-> PATCH: Add staring-at-phone face detection to lock screen
<pitti> isn't facelock doing pretty much that already? :-)
<FourDollars> Where are patch pilots? :(
<FourDollars> cjwatson: ping
<dholbach> good morning
<IanWizard-Cloud> dholbach: good night
<IanWizard-Cloud> (off to bed :P )
<IanWizard-Cloud> dholbach: Have a nice day :)
<dholbach> IanWizard-Cloud, sleep tight :)
<IanWizard-Cloud> thx
<cjwatson> pitti: that was my initial plan, but I changed my mind during UDS; it'll involve much less fragile tracking to just say that any failure, regression or not, blocks migration, and I don't think we have so many autopkgtests that it's necessary to set up a ratchet
<cjwatson> FourDollars: helps to say what you want ...
<pitti> cjwatson: ah, ok; I'm mostly concerned about those which never succeeded
<pitti> we should fix them anyway, of course
<persia> Or, rather, those that are failing currently in raring, even if they passed previously.
<cjwatson> well, if it's really intractable, worst case we disable them
<pitti> yeah, at least until we fix them; I'd love to just have them always pass, it just will take a bit
<janimo> slangasek, I just did as with previous kernel packages I co-maintained, just used native packaging. The ubuntu kernel package seems to be native too. But I agree having upstream + delta would be nicer
<cjwatson> The Ubuntu kernel package is randomly native or not depending on whether the kernel team remembers to put the orig in place :-)
<cjwatson> (as far as I can tell)
<FourDollars> cjwatson: https://code.launchpad.net/~fourdollars/ubuntu/precise/ubiquity/lp1046241/+merge/132653
<FourDollars> cjwatson: https://code.launchpad.net/~fourdollars/language-selector/singleton_and_escape_key/+merge/132595
<FourDollars> cjwatson: Could you help to review my patches?
<cjwatson> FourDollars: I can look at ubiquity but not language-selector.  However you need to work based on lp:~ubuntu-installer/ubiquity/precise-proposed
<smb> cjwatson, Huh? Oops, which release has not? Usually it should happen as soon as there is a orig from the upstream I would believe...
<FourDollars> cjwatson: Thanks for your information.
<persia> smb: So it's native until upstream release, then non-native?
<smb> persia, yes
<apw> persia, right we don't really have a valid .orig until linus releases with the version we are using
<persia> For other packages, we tend to create a fake (incorrect) .orig, marked to indicate it's a git snapshot in a version-safe way.
<persia> Usually something like appending ~gitYYYYMMDD to the orig version string.
<persia> Depends if you ever want to upload something with just packaging or sauce changes, rather than upstream changes.  If so, saves bandwidth to have an orig.  If not, doesn't matter that much except insofar as it might be confusing to others.
<cjwatson> smb: ah, yes, you're right, only 3.7.0 lacks it right now which is sane enough.  It used to be more haphazard, so thanks for fixing your process :-)
<cjwatson> FourDollars: I can go ahead and backport that patch to the right branch now if you like
<cjwatson> FourDollars: unless you already have something in progress
<FourDollars> cjwatson: If you can do that, that will be great. :D
<FourDollars> cjwatson: Thanks a lot.
<cjwatson> FourDollars: OK, done.  Not uploading quite yet because I'm going to need to upload ubiquity soonish for secure boot patches which I haven't yet backported
<FourDollars> cjwatson: Got it, Thanks. :)
<mlankhorst> can someone drop the xorg-xserver in the sru queue for quantal?
<pitti> mlankhorst: apparently someone already did, I don't see it
<pitti> https://launchpad.net/ubuntu/quantal/+queue?queue_state=1&queue_text=xorg only has nouveau
<mlankhorst> ah k :)
<pitti> mlankhorst: unless you uploaded it in the last 4 minutes?
<mlankhorst> nah
<FourDollars> pitti: Could you help to review https://code.launchpad.net/~fourdollars/language-selector/singleton_and_escape_key/+merge/132595 ?
<pitti> not right now, but I'll be patch-piloting on Monday and can get to it then
 * cjwatson starts to get a handle on the python-apt failure
<cjwatson> missing Architecture: lines in the test Packages files; now to determine whether that's a deliberate increase in strictness or a bug
<FourDollars> pitti: I see. Thanks.
<FourDollars> pitti: Do you know where is the Patch Pilots schedule? Any wiki page?
<pitti> there's a google calendar for it
<FourDollars> pitti: Could you give me the link?
<pitti> it's on https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews
<FourDollars> pitti: Excellent! thanks a lot.
<pitti> that's going to be fun: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=missing-testsuite-header;users=autopkgtest-devel@lists.alioth.debian.org
<pitti> let's see how many of those actually work
<Laney> \o/
<dholbach> :-)
<Laney> I saw that Debian got a jenkins instance too: http://jenkins.debian.net/
<dholbach> but I couldn't find the autopkgtests in there
<pitti> yes, that mass bug filing started because of that
<dholbach> and 4 of those bugs are already marked wontfix :/
<pitti> it was just set up, it's not yet doing autopkgtest
<pitti> dholbach: yeah, Jakub Wilk did that without explanation
<Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685508#10
<ubottu> Debian bug 685508 in src:sphinx "Please add "XS-Testsuite: autopkgtest" header in debian/control" [Wishlist,Open]
<pitti> ah
<pitti> so, we'd need to convince LP to generate a Contents-source.gz
<xnox> dholbach: pitti: did anybody talk to jwilk?
<pitti> not me, I just saw his response
<pitti> so if they want to use that field for jenkins.d.o, that certainly works
<pitti> but we need to add it until Soyuz learns about contents-source.gz
<Laney> it's not certain if he's just a lone voice yet though
<mpt> ev, hi, I just experienced bug 1012358. Anything I can provide to help debug it?
<ubottu> Launchpad bug 1012358 in apport (Ubuntu) "This problem report is damaged and cannot be processed." [Undecided,Confirmed] https://launchpad.net/bugs/1012358
<caribou_> tseliot: ping
<ev> mpt: attach the report to the log
<ev> it will be in /var/crash
<ev> and ew, a python tuple in an error message
<ev> mpt: we really need to turn that UDS presentation of yours into a thousand error dialog paper cuts or something similar
<mpt> ev, unfortunately, this is one of (cough) five error reports I'm being asked about at the moment ... How do I tell which one it is? :-)
<mpt> five errors, I mean
<ev> is the dialog still up?
<mpt> yes
<ev> mpt: xprop | grep WM_PID in a terminal window
<ev> click on the error dialog
<ev> that will get you the PID
<ev> then ps aux | grep $whatever_the_pid_is
<mpt> oh, now one of the others did the same thing
<mpt> ok
<ev> and that *should* give you something like /usr/share/apport/apport-gtk /var/crash/the_report_file.crash
<ev> I hope
<mpt> ev, no such luck ... it just gives me "mpt       5024  0.1  1.4 160076 28520 ?        Sl   10:44   0:00 /usr/bin/python3 /usr/share/apport/apport-gtk"
<ev> oh right
<ev> because it's being launched from update-notifier in "process all the outstanding reports" mode
<ev> maybe just send a zip of your entire /var/crash directory
<mpt> Ah, that's why I get five at once?
<ev> yup
<mpt> Yeah, we should fix that :-)
<ev> bug please
<ev> be sure to tag it :)
<cjwatson> ogra_: Do you know if there's any chance of overlayfs being turned on in the nexus7 kernel?  I don't quite know where to file bugs
<persia> janimo: ^^
<dholbach> cjwatson, there's a ubuntu-nexus7 project in LP
 * mpt uses "sudo file-roller" to add root files to the archive, and feels dirty
<xnox> mpt: use gksudo and feel all "gnomish" =)
<mpt> xnox, file-roller should use PolicyKit to get permission to read the files
 * xnox > seb128 
<seb128> xnox, patches are welcome ;-)
<cjwatson> dholbach: ah, thanks
<ev> work items are great and all, but I'd love to be able to indicate finer grained progress for individual items
<ev> but compared to what we used to deal with, I'm so happy to have this
<seb128> ev, split the item in more details?
<zequence> Where can I find more info on how Ubuntu syncs packages from Debian?
<zequence> ..for the development release of Ubuntu, that is
<ev> seb128: yeah, perhaps this is the equivalent of a code smell. I need to refactor my work items :)
<ogra_> cjwatson, well, there is a linux-nexus7 package in the queue, waiting to enter the archive i think ... once thats in, that should be the bug target, for now dholbach is right, use the nexus7 project
<mpt> ev, I added the archive
<ev> mpt: cheers, I'll have a look momentarily
<zequence> Or more specifically, from which Debian repo(s) does Ubuntu development release get their packages from? testing/experimental?
<diwic> zequence, unstable by default
<diwic> zequence, testing for LTS releases
<persia> diwic: In practice, but aren't there some package-specific hints for some packages in the sync scripts?
<diwic> persia, if so, that's more than I know of
<cjwatson> persia: No.
<cjwatson> diwic is correct, although if our current stability work turns out well then we may just stick with unstable for the next LTS too.
<cjwatson> (Will need discussion.)
<cjwatson> zequence: the auto-sync script in https://code.launchpad.net/+branch/ubuntu-archive-tools is what actually does the work.
<zequence> cjwatson: Thanks
<persia> cjwatson: Hrm.  I thought I remembered some continued syncs from experimental, but indeed, it seems that was the result of concientious archive-admins rather than autosync.
<cjwatson> Or possibly just self-service syncs by developers.
<persia> My memory of that predates that facility, but yes, that is likely more true now :)
<cjwatson> We did occasionally use to get requests to sync stuff from experimental; I don't remember doing so routinely, only on request
<cjwatson> (But you may not necessarily have seen the requests, of course :-) )
<persia> Indeed, as there were N fora in which they appeared :)
<janimo> cjwatson, ogra_ overlayfs is not part of our 3.1 based Nexus kernel. We'll need to backport if it is required for the installer. If it is a SAUCE patch in Ubuntu it will be part of the sync-up that should happen so the nexus kernel is as close to Ubuntu's as possible
<ogra_> diwic, i dont see you in #ubuntu-arm, for the nexus there are two android files at https://android.googlesource.com/device/asus/grouper/+/7fce7d56cb077e869b9509cd2770d92e8cf29dcc/audio_policy.conf and https://android.googlesource.com/device/asus/grouper/+/7fce7d56cb077e869b9509cd2770d92e8cf29dcc/mixer_paths.xml , nots sure that helps though :)
<ogra_> oh, and there is https://android.googlesource.com/device/asus/grouper/+/7fce7d56cb077e869b9509cd2770d92e8cf29dcc/audio/ with some .c files
<mpt> ev, on the tagging thing, I think it might be a bit quicker overall if you use a project group, containing apport, whoopsie, daisy, and errors
<ev> mpt: I think I tried to turn whoopsie-daisy into that, but because it was already a project it didn't work
<ev> any suggestions for a name
<ev> ?
<mpt> ev, because LP can show an aggregated bug listing for a project group. So instead of the chore being tagging whoopsie-daisy bugs in every project, the chore would then be making sure apport bugs were filed upstream. Still a chore, but you'd need to do that for fewer bugs.
<mpt> ev, ubuntu-error-tracker?
<cjwatson> janimo: I think it's sauce
<ev> mpt: at what point did you see this error dialog? Was it after you hit show details or continue?
<mpt> ev, I got it twice. I think I had clicked "Show Details" in all five. I don't know whether the error was for one of the ones I'd already clicked "Continue" for.
<mpt> (for two of the ones, rather)
<ev> I think this may be dependent on information it's collecting as part of that Show Details step, as I can't seem to reproduce it here
<ev> pitti: ^ are you okay with me adding the apport project to an ubuntu-error-tracker project group?
<pitti> ev: sure, that sounds sensible
<ev> cool
<ev> pitti, mpt: https://answers.launchpad.net/launchpad/+question/213666
<pitti> ev: thanks, subscribed
<tseliot> caribou: pong
<diwic> ogra_, yeah, that's the same files I've seen as well, but as cyagenomod. That's where I got the idea to try 44100 kHz only, thinking that Pulseaudio's initial probing might cause something to stall
<caribou> tseliot: I'm back.
<caribou> tseliot: just wanted to let you know that my Nvidia install issue automagically disapeareed
<caribou> tseliot: I was able to enable nvidia-current. But I suspect that, in the meantime, I installed the linux-headers pkg
<caribou> tseliot: and it was needed for the dkms build
<tseliot> caribou: ah, good
<Daviey> xnox: hey, are you looking to merge autofs?
<xnox> Daviey: yes.
<xnox> Daviey: you want it urgently?
<Daviey> xnox: no,just going through the packages i care most for :)
<xnox> ;-)
<ev> pitti: can you hit "Change details" on http://launchpad.net/apport and put "ubuntu-error-tracker" in the "Part of" field?
<Daviey> considering debian has been in freeze.. the list is larger than i hoped :)
<pitti> ev: oui, je peux
<ev> cheers
<pitti> ev: done
<ev> yay
<ev> mpt: bam! https://launchpad.net/ubuntu-error-tracker
<pitti> ev: that just made me aware of an OMGcritical bug
<ev> oh?
<pitti> ev: daisy and whoopsie SO MUCH need a proper icon!
<ev> hahaha I was just thinking that a moment ago
<ev> mpt? :)
<ev> pitti: ps. I'm trying to get a handle on this lovely one: https://launchpadlibrarian.net/118068239/Traceback.txt https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1059938
<ubottu> Error: malone bug 1059938 not found
<ev> I'd quickly assume it's hardware (which we should handle, regardless), but I'm not ruling out something more nefarious
<mpt> pitti, ev: I requested a better icon for the error alerts themselves, but yes, it would be sweet to have related icons for the components
<pitti> ev: yeah, if it doesn't have dupes, I'm inclined to attribute it to cosmic rays
<mpt> pitti, it's happened to me three times today, and sunspot activity has been quiet this week
<ev> god damn I love errors.ubuntu.com
<ev> I mean, I realise that's slightly self-congratulatory
<pitti> mpt: oh, you can reproduce this?
<ev> but I looked at apport and there was just that one instance
<ev> then I looked at https://errors.ubuntu.com/?package=apport-gtk&from=year
<ev> and it's the #3 most common issue in apport
<pitti> ev: wow, and look at the rate 13.04 is getting better :)
<mpt> pitti, no, it's just three that happened to appear today
<ev> :) mpt has some math to smooth those spikes out
<pitti> ok, so that is real then
<mpt> pitti, I think the first day of 13.04 was just 12 of the same problem
<mpt> or something like that
<pitti> it still looks nice :)
<ev> mpt: how wide do you think the range of dates for the average number of errors per calendar day graph should be? Too wide and we run the risk of the milestone markers overlapping
<ev> (with it expanding on the right hand side to include the next release day)
<ev> pitti: you said that ddebs.u.c was back to normal, right?
<pitti> ev: it should, yes
<ev> yay
<pitti> the bug got closed anyway
<ev> :)
<ev> cheers
<ev> I've notified webops
 * xnox did something naughty
 * xnox -> lunch
<highvoltage> xnox: explain.
<Quintasan> bdrung: nudge
<bdrung> Quintasan: you are desperately waiting for it?
<Quintasan> bdrung: Not really THAT impotant but just nudging you
<bdrung> okay :)
<bdrung> Quintasan: the fingerprints lay on my desk. so i will not forget to sign the keys.
<Quintasan> Oh
<Quintasan> That's quite a good idea
 * Quintasan spreads the keys on his desk
<bdrung> Quintasan: there are 5 other items on the disk that require my action. there are ~10 mails waiting for my reply. there are at least 2 patches that i should look at. i want to write a blog post...
<bdrung> at least the keys are not buried under more staff :)
<Quintasan> blog post
<Quintasan> crap
 * Quintasan goes off to do something productive instead of annoying poeple
<Quintasan> people*
<bdrung> Quintasan: i recommend to work on that: http://reqorts.qa.ubuntu.com/reports/sponsoring/
<Quintasan> alt+f4
<Quintasan> bdrung: :P
<pitti> xnox: FWIW, if nobody complained about the lack of ndiswrapper since precise, let's try and drop it for good; it uses a ton of old libraries which we try to get rid of
<stgraber> +1
<cjwatson> Laney: you can go ahead and kill that cloud instance you set up for me to debug python-apt - thanks!
<Laney> cjwatson: righto - nailed down?
<Laney> eet eez deleted
<cjwatson> Laney: well, mostly
<cjwatson> Laney: I'm still a bit nervous that it was only reproducible on some systems, but it amounted to apt being at least vaguely intentionally stricter about Packages stanzas without an Architecture field
<cjwatson> so after debugging for hours to try to figure out where the discrepancy was, I gave up and made the trivial test fix since it was clearly busted anyway
<xnox> pitti: what "old libraries" are talking about? =))) http://launchpadlibrarian.net/122375899/ndisgtk_0.8.5-1_0.8.5-1ubuntu1.diff.gz
<pitti> xnox: oh, err, wow!
<xnox> pitti: I found out that there is no kernel module at the final step of testing in the live cd....
<stgraber> :)
<dobey> can i get someone to approve the u1db binnew in raring-proposed so it gets to raring?
<pitti> mpt, ev: I found a similar bug which is very very likely the same reason, and duplicated bug 1059938
<ubottu> Error: Launchpad bug 1059938 could not be found
<pitti> the new master is public and has some analysis
<cjwatson> xnox: "replace program with new program" :-)
<pitti> anyway, time to stop sitting in front of that computer for today and play some Badminton, cu tomorrow!
<cjwatson> dobey: looking
<xnox> cjwatson:  "[14:44] * xnox did something naughty"
<cjwatson> heh, I wondered
<pitti> xnox: what about * Port Windows drivers to Linux"?
 * pitti ducks and heads off
<xnox> pitti: that was done part of canonical re-writting linux kernel in python, wasn't it?
<cjwatson> dobey: done
<dobey> cjwatson: thanks!
<jetsaredim> is there a guide for making changes to a package and then submitting them for approval?
<astraljava> jetsaredim: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff might work?
<jetsaredim> astraljava: possibly
<mpt> ev, can you stagger alternating milestone markers?
<mpt> ev, i.e. odd-numbered ones higher than even-numbered ones
<ev> mpt: you mean raise or lower their height? Won't that ultimately have the same problem (at the cost of a lot of extra computation)
<mpt> ev, eventually.
<ev> mpt: so you'd like to see if we can include all the data we have so far for the default view?
<mpt> ev, definitely, I'd like to see the past five years in the default view
<ev> okay, I'll give that a bash
<mpt> (even if the horizontal scale ends up a log scale to show the past few months in more detail)
<ev> mpt: wouldn't that be confusing given that our x-axis currently only shows values for the milestone dates?
<ev> it would be hard to see that it was in fact a log scale
<mpt> ev, it would, we'd need to add other tick marks before then
<mpt> or at the same time
<mterry> @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 dicussion 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: mterry
 * dholbach hugs mterry
<mterry> :)
<bdmurray> ev: is there a way to track current error counts for a bucket?  I know a fix for a crash has been released and I want to make sure it drops to 0
<ev> bdmurray: I'm not sure I follow. How is this different to looking at the instance count for the version you just uploaded?
<jetsaredim> what is the review process for a patch to a quantal package?
<bdmurray> ev: well, its bug 875879 where the error was in aptdaemon not update-manager.
<ubottu> Launchpad bug 875879 in aptdaemon (Ubuntu Quantal) "update-manager crashed with AttributeError in show_diff(): 'NoneType' object has no attribute 'group'" [High,Fix released] https://launchpad.net/bugs/875879
<bdmurray> ev: I was thinking about something like https://errors.ubuntu.com/api/1.0/problems-count/?format=json&period=day&limit=14 but for the specific bucket
<ev> hmm, that's doable, but I wonder if that's the ideal solution, given others are going to run into this and not know about the API
<ev> brb
<seb128> can somebody set https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422 to Work In Progress to get it out of the sponsoring queue? (c.f comments, it's not ready to be uploaded)
<ogra_> slangasek, do you happen to know what the --tty= option of plymouth does exactly ? i was trying to use it to force a splash on the nexus but it doesnt seem to affect the splash side of things, only stdio
<bdmurray> ev: I guess I'd like to "subscribe" to the bucket and get emails regarding counts
<slangasek> ogra_: it certainly is supposed to affect which tty the splash appears on
<ogra_> hmm, i think i added --tty=/dev/tty1 to all plymouthd calls in the boot process, but it still seems to use the console= option
<ogra_> slangasek, http://paste.ubuntu.com/1342880/
<ogra_> the nexus bootloader has a hardcoded console=none ... we override that with the kernel cmdline options to console=tty1
<ogra_> but it seems to pick none as default no matter what i do
<ogra_> add_consoles_from_kernel_command_line:console /dev/none found!
<ogra_> and that is a clear lie :)
<slangasek> ogra_: oh; but console != tty of course
<ogra_> there is no /dev/none anywhere
<slangasek> so this would be a bug in plymouth's /proc/cmdline parsing
<ogra_> yeah, it should ignore =none
<slangasek> (IIRC, one you've run into in the past on ARM :P)
<ogra_> i only ran into the "serial ttys foirce splash to off" one
<slangasek> yes, which is the same bug :)
<ogra_> and that seems fixed since 0.8.5
<ogra_> (which we dont have yet)
<slangasek> plymouth should support multiple specifications of console= and DTRT with them
<slangasek> ok
<ogra_> right
<ogra_> http://cgit.freedesktop.org/plymouth/commit/?id=6baab7a8f889f6b48cb559fd5a62750203f62c3b
<ogra_> (at leats that one is lonked from https://bugs.freedesktop.org/show_bug.cgi?id=22239)
<ubottu> Freedesktop bug 22239 in general "improve console= handling" [Normal,New]
<jodh> ogra_: have you tried the '--kernel-command-line=...' option? See https://wiki.ubuntu.com/Plymouth
<slangasek> we certainly don't want to embed something like that
<ogra_> slangasek, well, but it might help for a test :)
<slangasek> sure
<ogra_> i at least would like to see a splash at some point to make sure the framebuffer driver doesnt mess up
<jodh> slangasek: purely for testing :)
<slangasek> ogra_: btw, I guess you missed my question over the weekend about not being able to ssh into my nexus
<ogra_> hmm, no splash
<ogra_> slangasek, well, did you install openssh-server ?
<ogra_> we dont ship it preinstalled
<slangasek> am I being trolled
<ogra_> heh, sorry
<ogra_> the dev images used to have it by default
<slangasek> ogra_: yes, I can tell the difference between a machine that's running an ssh server and one that isn't ;)
<ogra_> we only disabled it in the last build before UDS, thats why i'm asking
<slangasek> ogra_: the problem I'm seeing is that the connection hangs *after* authentication, once the tty is supposed to be opened
<slangasek> and I then can't kill the client using either ^C or ~.
<ogra_> wow, weird
<slangasek> so it's in some weird state
<ogra_> never had that prob here, did you create your own user or do you use ubuntu@ ?
<slangasek> ubuntu@
<slangasek> I don't see how it could be related to the user, though
<slangasek> I'm suspecting a bug in the network drivre
<slangasek> driver
<slangasek> because there are some suspicious retransmits shown in a packet trace
<ogra_> might be, but its the first time i hear about it
<slangasek> you should bring your nexus over to my wireless, to see if it's reproducible :P
<ogra_> hahaha, ok, approve the flight and i'll be right there
<seb128> mdeslaur, did you see https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1068486 while doing piloting yesterday?
<slangasek> ok, if you haven't heard anything about it I guess I'll keep futzing until I figure it out :)
<ubottu> Launchpad bug 1068486 in python-django (Ubuntu) "Please backport Django 1.3.4/1.4.2 security updates" [Undecided,Confirmed]
 * ogra_ could need the miles
<seb128> mdeslaur, (I guess security uploads need sponsoring from somebody in the security team)
<ogra_> mfisch, did you ever see any issues with ssh'ing into the nexus ?
<ogra_> (or heard about them)
<bdmurray> fwiw I haven't had any issues and I'm closer to slangasek
<mfisch> ogra_: I had issues more with wifi/connectivity
<mdeslaur> seb128: no, didn't notice that yesterday...jdstrand is on community this week, so he'll go down the security sponsoring list at some point
<slangasek> bdmurray: I thought the Columbia river was a barrier passable only through heroic effort and at great personal risk ;)
<seb128> mdeslaur, ok, thanks
<mfisch> ogra_: where I'd have to try ssh 2-3 times before I could get in, but I haven't seen that at home
<mfisch> whats the issue?
<ogra_> mfisch, for slangasek the connect attempt seems to hang the whole connection
<mfisch> I never saw that
<ogra_> i have seen that before but never on the nexus
<slangasek> mfisch: see scrollback for details; summary: connected to wifi, the ssh connection consistently hangs right after sending env variables (according to ssh -v), leaving the client in limbo
<mfisch> we had those early issues with the certs, but those were all fixed
<ogra_> (in a way that you cant ctrl-c out of it and need to kill -9 from another termianl)
<slangasek> bdmurray: but yeah, happy for you to swing by sometime and check if this is reproducible, or trade off hardware or something
<ogra_> and now that i think about it, i have actually only ever seen it on arm
<mfisch> I'll be back in 20, will catch up on SB then
<slangasek> (much though it would pain me to part with nexus7-geekiest)
<ogra_> lol, well, newer images  just use uuidgen now
<ogra_> no more shiny names
<ogra_> there are to many explicit words in dict
<xnox> jodh: you rock! =)
<jodh> xnox: autopkgtest you mean?
<xnox> yeah =)
<ogra_> [main.c]          add_display_and_keyboard_for_console:adding display and keyboard for console /dev/none
<ogra_> *sniff*
<jodh> xnox: ... I'll send you one of my new grey hairs after spending the day poking it for that compliment! :-)
<xnox> jodh: nah... I have enough thanks =)
<jodh> xnox: haven't achieved full disentanglement, but I think its close.
<ogra_> so the --kernel-commandline= option is ignored as well
<ogra_> from the log it looks like it is a newly spawned process doing that though
<Logan_> Can somebody please perform a requeue on the hives package, per Bug 714622?
<ubottu> Launchpad bug 714622 in Ubuntu Distributed Development "import fails when lp branch has been push --overwrite'n" [High,Confirmed] https://launchpad.net/bugs/714622
<Logan_> $ requeue_package.py --full hivex
<Logan_> (meant hivex above as well)
<cjwatson> Logan_: #bzr or #launchpad probably better
<Logan_> Hmm, alright.
<Logan_> I figured this would be the most specific channel for that kind of request.
<xnox> Logan_: hmm.... but I don't think I pushed over-wrote hivex.
<Logan_> Oh, weird.
<xnox> Logan_: maybe it's the raring-proposed -> raring & britney interraction with udd?!
<Logan_> There are so many packages with that error, I was beginning to speculate that push --overwrite wasn't the only thing causing it.
<Logan_> Ooh, that's an interesting conjecture...
<xnox> Logan_: what's the actual error/bug you are seeing with hivex?
<Logan_> When I try to do bzr branch ubuntu:hivex, the branch is reported as "OUT-OF-DATE."
<Logan_> I was going to do a Debian merge. :P
<Laney> it happens, and shouldn't stop you - the old tools are still available
<Laney> or you could likely use bzr import-dsc to still use the bzr workflow if in the end you supply a debdiff to be sponsored
<slangasek> import-dsc of a Debian version is a good way to ensure the branch remains broken
<slangasek> since that needs to happen on the Debian branch, which you won't be able to write to
<Laney> I carefully suggested not pushing anything
<slangasek> oh, you said debdiff, right
<slangasek> sorry, had momentarily forgotten what those were ;)
<ev> bdmurray: can you file a bug for this against http://bugs.launchpad.net/errors ? With your json API and subscription ideas
<bdmurray> ev: of course
<ev> thanks
<ev> I just want to have more of a think of how this will look in the UI
<seb128> could somebody reject https://code.launchpad.net/~carifio/lightdm/lightdm-lp967229/+merge/131478 ?
<stgraber> seb128: done
<seb128> stgraber, thanks
<Laney> can we get an "ubuntu-13.04-feature-freeze" milestone?
<stgraber> Laney: doing
<Laney> I forget what we agreed at UDS - wasn't it monthly ones except for (as well as?) feature freeze and beta?
<Laney> stgraber: thanks
<stgraber> Laney: done. I also moved beta-1 to the proper date
 * Laney hands stgraber a Launchpad Gardener achievement
<jpds> Laney: I'm sure any garden next to a rocket launchpad is doomed
<smoser> is there some way to convince 'do-release-upgrade' to just do the thing and not prompt me?
<smoser> do-release-upgrade --just-do-it-already!
<seb128> can somebody mark https://code.launchpad.net/~darkxst/ubuntu/quantal/telepathy-logger/lp1049210/+merge/131497 merged?
<smoser> hm.. seems like : do-release-upgrade --frontend=DistUpgradeViewNonInteractive
<smoser> seb128, that happened to me too recently.
<smoser> "Ubuntu branches" was requested for the merge, and as a result i couldn't do anything.
<smoser> was there some change that is causing this?
<seb128> smoser, no, it was always like that, merge requests targeted to a stable serie are "stucked"
<smoser> ah. so 'stable' was what was different.
<seb128> quantal is frozen, the request should have been targetting an active serie, e.g quantal-proposed
<smoser> right.
<smoser> well, but annoyingly there is no 'quantal-proposed' for the first sru
<seb128> smoser, yeah, UDD doesn't work great for SRUs
<smoser> darkxst, ^ can you mark that merged?
<dobey> barry: did you subscribe twisted-buildslaves to your ubuntuone-control-panel branch?
<cjwatson> sigh, coreutils is one of those packages that can't build on overlayfs, isn't it ...
<cjwatson> (tail -f tests run into broken inotify support)
<xnox> cjwatson: $ mk-sbuild --vg scratchvg raring
<xnox> =)))))))
<xnox> lvm snapshots win over overlayfs =)
<stgraber> that or just replace tail by a symlink to the busybox binary
<cjwatson> that wouldn't be a terribly brilliant test of coreutils tail
<stgraber> indeed :)
<stgraber> I'm surprised nobody fixed the kernel to actually do inotify on overlayfs, that bug has been there for years now...
<cjwatson> and yes, I'll start using lvm snapshots when I get round to rearranging partitions on my laptop
<cjwatson> (i.e. not soon but ...)
<Daviey> meh, i wouldn't switch back to lvm myself.
<xnox> cjwatson: well I did partitions surgery late last cycle to have half disk encrypted lvm and the other half "unembargo" aka non-encrypted lvm for builds.
<xnox> now, I need to test grub2+luks+lvm without separate /boot and then I can switch to that & convert my /boot to be come UEFI system partition
<xnox> this is a surgery for this cycle =)
<Sweetshark> doko_: I scped boost1.49_1.49.0-3.1ubuntu4 for raring to chinstrap btw
<barry> dobey: re bug 1029094: do you need anything more from me?
<ubottu> Launchpad bug 1029094 in Ubuntu One Control Panel trunk "Replace simplejson with json" [Undecided,In progress] https://launchpad.net/bugs/1029094
<dobey> barry: don't think so; but glyph was complaining about getting spammed by the bug (was actually the merge proposal); and it looks like for some reason twisted-buildslaves was subscribed to the branch which you proposed
<barry> dobey: weird
<darkxst> smoser, done.
<alexbligh1> cdrom/try-usb was removed from cdrom-detect somewhere between lucid & precise; does something else in the installer use this flag?
<Daviey> tyhicks: Geez, why do you still need a sponsor?
<tyhicks> Daviey: Because I still don't know what I'm doing half of the time :)
<Daviey> tyhicks: join the club :)
<tyhicks> Daviey: I'm also waiting on sbeattie
<Logan_> mterry: Regarding Bug 1038298 (which you just forwarded to Debian), that typo only appears in the Ubuntu delta...
<ubottu> Launchpad bug 1038298 in zsh (Ubuntu) "zshrc comment typo: .zprofice should be .zprofile" [Low,In progress] https://launchpad.net/bugs/1038298
<Daviey> tyhicks: I've said the same to him.. but i think i went as far to say i wasn't going to sponsor his work anymore, to try and persuade him to apply.
<tyhicks> Not a bad idea... :)
<Daviey> tyhicks: I take that back, your upload isn't lintian clean. :)   E: acpid changes: bad-ubuntu-distribution-in-changes-file raring
<tyhicks> See...
<mterry> Logan_, shoot.  I looked at the changelog to see if that were the case, but I didn't look at the actual delta with debian
<mterry> Logan_, OK, thanks.  I'll close that bug out then.  :-/
<Logan_> mterry: Haha, alright. No worries.
<Logan_> mterry: Also, any chance of approving my merge request, in that case?
<mterry> Logan_, sure
<barry> bdmurray: uploaded to quantal-proposed
<tyhicks> Daviey: Actually, I just tried lintian again and didn't see that error. What am I missing?
<Daviey> tyhicks: Sorry.. I did this from my 12.04 system, which didn't know raring was a valid release.  You did nothing wrong, i was pulling your chain.
<tyhicks> Aha... I figured that was the problem :)
<mterry> @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 dicussion 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:
<mightyiam> hiii raring here from upgrade from quantal. when logging in through lightdm i get thrown back to lightdm immediately. which logs should i check?
<mightyiam> i've something in auth.log about dbus rejected send message seems to be from indicator-session-service to console-kit-daemon
<mightyiam> otherwise i didn't find anything terrifying in the logs
<mightyiam> libsecret-1-0 conflicts with itself. this causes a conflict between the amd64 and the i386 versions of it, breaking stuff when ia32-libs-multiarch is needed
<mightyiam> submitted the libsecret issue as bug #1076766
<ubottu> Launchpad bug 1076766 in libsecret (Ubuntu) "raring libsecret-1-0 conflicts with itself" [Undecided,New] https://launchpad.net/bugs/1076766
<mightyiam> issue where i can't login is submitted as bug #1076777
<ubottu> Launchpad bug 1076777 in lightdm (Ubuntu) "Get thrown back to lightdm right after trying to log in" [Undecided,New] https://launchpad.net/bugs/1076777
<TheMuso> mightyiam: Are you possibly getting this bug? https://launchpad.net/bugs/1076787
<ubottu> Launchpad bug 1076787 in xorg (Ubuntu) "GLX error: Can not get required symbols" [Undecided,New]
<slangasek> mmm
<slangasek> xnox: ?
<TheMuso> He was planning to turn in. I was following on in #ubuntu-desktop where he noted that he filed this bug.
<slangasek> ok
<slangasek> hmm, why does he have fglrx installed on an intel system?
<slangasek> Sarvatt: fwiw the system in bug #1076787 is xnox's laptop, I'm reasonably certain he didn't have a removable AMD card in it
<ubottu> Launchpad bug 1076787 in xorg (Ubuntu Raring) "GLX error: Can not get required symbols" [Critical,New] https://launchpad.net/bugs/1076787
<slangasek> which suggests to me that the fglrx may not have been of his choosing :/
#ubuntu-devel 2012-11-09
<bkerensa> Laney: https://code.launchpad.net/~bkerensa/ubuntu/raring/swauth/fix-for-1061020/+merge/133195
<bkerensa> Laney: you asked me to forward to Debian but the package does not exist in Debian
<xnox> Laney: somehow the packages list is ~8 hours out of date on the transition-tracker.
<pitti> Good morning
<mightyiam> thanks, TheMuso, i'll check
<dholbach> good morning
<mightyiam>  good morning indeed
 * seb128 looks at dholbach and opt-in for some extra friday sponsoring out of his normal shift
<seb128> !pilot in
<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 dicussion 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: seb128
 * dholbach hugs seb128
 * seb128 hugs dholbach back
<dholbach> I'll sponsor a few bits later on, got to finish 2 other things first :)
<mightyiam> my kernel in raring is "obsolete"
<mightyiam> 3.5.0-18-generic
<mightyiam> 29
<cjwatson> mightyiam: Yes, I'm processing the 3.7.0-0 one through the archive at the moment.  No need to report it.
<mightyiam> thanks, cjwatson
<Laney> bkerensa: fair enough, comment in the MP to that effect then
<Laney> xnox: uhh
<xnox> Laney: or maybe there is a mistake in my tracker. http://people.canonical.com/~ubuntu-archive/transitions/onlypy3oncd.html shows ndisgtk at 0.8.5-1 while if I generate the tracker locally  it's at 0.8.5-1ubuntu1.
<xnox> =(
<Laney> I'll look in a second
<Laney> just collecting the pieces from that libgcrypt11 thingy
<xnox> =)
<xnox> thanks
<Laney> stokachu: !!!
<Laney> -rw-r--r-- 1 ubuntu-archive ubuntu_archive 1140090 Nov  8 14:09 Packages.bz2
<Laney> xnox: suspicious eh
<xnox> yeah....
<Laney> hm
<Laney> cjwatson: I suppose you didn't intend to turn that off :-)
<mlankhorst> is the dpkg-diverts from libgtk-3-bin good enough as dumb example for dpkg-divert? :p
<cjwatson> Laney: no - I'll lok
<cjwatson> *look
<Laney> ta
<Laney> would JFDI but bzr
<Laney> alternatively if I can just branch that and fix/push then I will
<cjwatson> edit in place and commit
<cjwatson> but
<cjwatson> Laney: raring-proposed is up to date - I thought you'd stopped using raring in the transition tracker
<Laney> it merges the two
<Laney> because partial suite
<cjwatson> oh, so you need to be triggered on a change to either, then?
<Laney> well I suppose you could just sync release as well if proposed changes
<Laney> you should only need to regenerate the tracker if proposed changes, right?
<cjwatson> Laney: ok, should be fixed now
<Laney> cheers
<ScottK> seb128: Where there API changes in 12.10 for messaging menu?  I'm looking at Bug 1076362 and I'm really confused because it works for me fine with the Qt/KDE messaging indicator and literally nothing changed in Quassel between 12.04 and 12.10.
<ubottu> Launchpad bug 1076362 in quassel (Ubuntu) "Quassel messaging menu integration broken in Ubuntu 12.10" [Undecided,New] https://launchpad.net/bugs/1076362
<seb128> ScottK, yes, https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1040259
<ubottu> Launchpad bug 1040259 in skype-wrapper "FFE: libmessaging-menu transitions for quantal" [High,In progress]
<seb128> ScottK, there is a new lib,api in quantal
<ScottK> Sigh.
<ScottK> Thanks.
<seb128> yw
<seb128> I didn't know KDE has a messaging indicator compatible with the old api
<seb128> sorry about that, we should probably have added that to the list of things to port or at list consider it
<seb128> hum
<seb128> who synced glew?
<seb128> whoever did I hope there was a test rebuild of the unity stack with the new glew, we had glew updates breaking unity in the past
<Laney> https://lists.ubuntu.com/archives/raring-changes/2012-November/000950.html
<seb128> Laney, "Sorry, changesfile not available."
<Laney> the From line says who did it
<seb128> oh, there is the signed-by
<seb128> does alessio do IRC?
<pitti> quadrispro
<seb128> not there
<seb128> grumpf
<didrocks> cjwatson: is there a way hold manually proposed -> release pocket migration for this component?
<pitti> hm, we don't yet have unity in autopkgtest; that ought to catch that?
<didrocks> pitti: well, we can't run autopilot in autopkgtest as discussed in the UDS session
<didrocks> pitti: because of need of bare metal
<pitti> yeah
<cjwatson> didrocks: I've blocked it for the time being
<ScottK> seb128: It's not just us as DBus menu is in upstream KDE, so it needs porting work upstream too and we're now too late for KDE 4.10.
<didrocks> cjwatson: thanks a lot. Let's try to sync with quadrispro when he's here (or sending an email if we can't catch him)
<ScottK> seb128: I'm not actually sure all the bits it touches.
<cjwatson> (lp:~ubuntu-release/britney/hints-ubuntu - it just has a file for me at the moment, but the list of hinters is in britney.conf in lp:~ubuntu-release/britney/britney2-ubuntu)
<didrocks> sweet, that the conf is versionned :)
<cjwatson> so please let me know if/when that can be unblocked
<cjwatson> having that in bzr is probably overengineering but meh
<seb128> didrocks, I emailed him and ubuntu-devel
<didrocks> seb128: thanks!
<didrocks> cjwatson: well, at least, we are sure to have a reason written in
<cjwatson> yeah (I've just added a reference to this conversation)
<cjwatson> I have no problem with anyone in ~ubuntu-release setting themselves up as a hinter
<cjwatson> although I think any changes to lp:~ubuntu-release/britney/britney2-ubuntu still need to be deployed manually
<Laney> you forced something in the other day - was that not through hints?
<Laney> (I'm aware that the release team can do copies directly)
<cjwatson> Laney: I forced eagle in using a hint
<Laney> ah
<Laney> I see it in history indeed
<Laney> used to Debian ones where they use 'finished'
<cjwatson> the release team can but shouldn't - better get britney to do it
<cjwatson> yeah, their hints files aren't versioned, or weren't when I was last involved
<cjwatson> given a VCS I see no point in leaving cruft in the file
<pitti> mvo: does https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-ubuntu-release-upgrader/lastFailedBuild/ARCH=i386,label=albali/artifact/results/dsc0t-nose-tests-stdout make any sense to you?
<pitti> mvo: I see that the "Ã¤Ã¤Ã¤" appears on stdout (or err), and the fp.read() doesn't seem to get it
<mvo> pitti: let me check
<mvo> pitti: I wonder if mabye "less" is not installed in the test env
<pitti> plausible, let me check
<mvo> pitti: I update the test depends
 * pitti runs run-adt-test -l
<pitti> mvo: hm, I do have it installed here; that's a standard prepare-testbed VM
 * pitti runs tests in there
<mvo> pitti: I can do a upload with it added, maybe the server version is a bit different
<pitti> oh, the tests runs a while
<mvo> yeah
<pitti> hm, no Python 3.2 any more in raring :(
<xnox> pitti: nope. please rebuild your chroot as well, as there are packages that try to compile themself againsts "--installed"
<xnox> python versions.
<pitti> oh, I did, it's a fresh VM from yesterday
<pitti> but we have packages which don't work yet with 3.3, so its removal seems a bit premature
<xnox> pitti: which packages?
<pitti> for comparing/debugging I can install it from quantal, though
 * xnox thought we ported everything.....
<pitti> like python-docutils; there are certainly more, though, it's just the one I'm currently looking at
<xnox> I thought doko & mitya managed to get python-ductils workings....
<pitti> the last build in raring was against 3.2
<ogra_> xowow, thanks for the fstools, that was really fast
<ogra_> xnox, ^^^
<pitti> but oh well, I'll disable thre six failing test cases for now to fix the FTBFS; the other 1204 work, after all
 * ogra_ wishes some archive admin would review the nexus kernel now so it can get out of NEW
<pitti> and that's happening from current upstream svn trunk as well, so upstream should be on it
<xnox> ogra_: and it's in the ppa.
<ogra_> xnox, well, its on archive.u.c and ports.u.c
<xnox> ogra_: everywhere, where it matters =)
<ogra_> yeah
 * ogra_ is just missing the kernel now to start playing with the first images
<cjwatson> why was the last linux-nexus7 upload in the queue rejected, do you know?
<cjwatson> I saw a reject/reupload cycle but no explanation
<ogra_> iirc there was an ftbfs with the tools package
<ogra_> jani only discovered after upload
<ogra_> janimo, ^^^
<janimo> cjwatson, FTBFS with raring gcc. I reuploaded with tools package build disabled as it was don efor linux-ac100 as suggested by infinity
<janimo> ogra_, so for the firmware are we settled on a separate package that puts up a notice when installed?
<ogra_> janimo, apparently :/
<ogra_> janimo, it needs to be preseedable though
<janimo> is there a package I can look at that does something similar?
<ogra_> so we can suppress the notice on image builds
<janimo> preseedable?
<ogra_> since there usb-creator will show it at image flash time
<ogra_> the notice in the package just needs to be there for people installing the package separately
<xnox> ogra_: hmmm....
<xnox> ogra_: is the notice required, i thought we were meant to step that aside.
<ogra_> xnox, apparently it is :(((
<xnox> ogra_: so are you driving the legal workitem from the spec then?
<ogra_> i'm not keen having it either
<ogra_> legal is done
<ogra_> victorp_, ^^^^
<ogra_> we just need to display the same npotice that the shell script installer does nowadays
<ogra_> (same thing for the package)
<xnox> ogra_: ... and the notice will be a text file inside the tarball? (tar.gz: boot.img rootfs.img notice.txt README)
<xnox> ;-)
<ogra_> oh, sure, i could fish that out of the rootfs at build time
<xnox> ogra_: that would be lovely, cause currently the website lists it on the hwe. So the notice needs to be accesible on cdimage as well.
<xnox> ogra_: and within tarball should be sufficient. Or maybe along side the tarball as well for apache to pick up as README
<ogra_> i prefer inside if possible
 * ogra_ doesnt like to touch make-web-indicies if avoidable :)
<xnox> ack =)
<pitti> mvo: I can reproduce the failure with less installed
<ogra_> the first builds will be without firmware anyway i guess
<seb128> could somebody mark https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/kde-l10n-sl/precise-updates/+merge/133394 as merged?
<seb128> it was uploaded: https://launchpad.net/ubuntu/+source/kde-l10n-sl/4:4.8.5-0ubuntu0.1
<pitti> mvo: "xvfb-run python3 tests/test_view.py" succeeds, though
<didrocks> cjwatson: should I still use syncSources() compared to syncSource()? I remember we discussed about it a year ago and you told me to use the first one
<cjwatson> didrocks: Generally?  Neither.  What are you doing?
<didrocks> cjwatson: I'm written the latest script for the copy from the PS release ppa to -proposed
<didrocks> I have a list of package source name for a serie that are validated at this stage
<cjwatson> I probably told you to use syncSources because it would either succeed or fail all at once rather than maybe copying some but not others
<cjwatson> But I don't really think that's a concern with copies into -proposed
<cjwatson> Besides, both syncSource and syncSources are (lightly?) deprecated because they're synchronous and often time out
<cjwatson> I would recommend using copyPackage instead
<cjwatson> (you'll need to use the devel API version)
<didrocks> cjwatson: copyPackage, not copyPackages? (like if one operation times out, maybe I'll push the validated stack partially)
<didrocks> ah, it's async
<cjwatson> You *could* use copyPackages, but I wouldn't as that suppresses announcement mails
<cjwatson> Timeouts are very unlikely with copyPackage
<cjwatson> And the proposed-to-release process should protect against most partial-copy situations
<cjwatson> So I wouldn't worry about that
<didrocks> cjwatson: makes sense, I'll follow your advice and test between ppas meanwhile. Thanks :)
<didrocks> as I'm seeing the "auto_approve" parameter, I think I can keep it to False, so that we don't bypass potential freezes
<cjwatson> didrocks: You're acting with a developer hat on here rather than with an archive admin hat on, so you shouldn't use auto_approve
<didrocks> cjwatson: agreed, just checking that I understand the parameter corectly.
<cjwatson> You do
<pitti> mvo: I confirmed it's not TMPDIR and similar; something more involved
<didrocks> cjwatson: last thing (sorry to bother you), but I see that the relationship between source and binary packages is established here. However, if I try source.getPublishedBinaries(), I can get some tricky situation
<didrocks> cjwatson: like some binaries were published for amd64, but then the source becomes superseded, and the following call to source.getPublishedBinaries() won't give anything as it's only PUBLISHED or PENDING binary package state
<didrocks> and there is no parameter compared to ppa.getPublishedBinaries() to catch them
<didrocks> I wonder if I miss any obvious API to ensure I always get all the published binaries, even superseded (this is not for the copy, but for another step of the build process)
<victorp> ogra_ hi
<cjwatson> didrocks: not sure there's a desperately good way at the moment; maybe figure out the binary names you care about and call Archive.getPublishedBinaries repeatedly (ugh)
<ogra_> victorp, hey, see backlog
<pitti> mvo: aaah!
<cjwatson> SPPH.getPublishedBinaries is not my favourite interface
<pitti> mvo: reproduces with xvfb-run python3 tests/test_view.py |cat
<pitti> mvo: happens because stdout is not a pipe
<pitti> mvo: so presumably less fails to start up?
<cjwatson> less is normally quite happy if stdout isn't a tty - it basically just acts like cat
<didrocks> cjwatson: yeah, I have a workaround to avoid making all those calls for Archive.getPublishedBinaries and infering the binary namesâ¦ :/ But wanted to ensure I wasn't missing something obvious at least. Thanks again for your advice.
<victorp> ogra_, read that, not sure what did you decide
<ogra_> victorp, i just wanted you to confirm to xnox that legal work is done :)
<ogra_> so its only some code thats missing now to chow the notice ...
<ogra_> *show
<victorp> done as in, I have talked to our legal team and they are happy that if we display the notice we can distribute the fw blobs
<ogra_> right
<ogra_> thats enough
<victorp> yeap
<pitti> mvo: so I tried this, which works in a shell: PAGER="sh -c 'cat >/tmp/xx; true'" man man
<pitti> mvo: but it doesn't work in that test, I get "Syntax error: Unterminated quoted string"
<doko> xnox, are there any outstanding patches?
<xnox> doko: not that I can find. but pitti reports that it's not working.
<seb128> bdmurray, https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1064962/comments/100 ... is that an hard requirement? we track libreoffice 3.7 for raring, not 3.6 but it's not ready for upload yet
<seb128> slangasek, ^
<ubottu> Launchpad bug 1064962 in indicator-appmenu (Ubuntu Quantal) "[SRU] Global menubar items do not work when opening a document directly from nautilus with no LibreOffice instance running" [High,Confirmed]
<xnox> ogra_: victorp: ack.
<doko> xnox, well, yes, disable these three odp tests ...
<doko> or odt. I don't think packages build docs for this format
<seb128> pitti, could you mark https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/kde-l10n-sl/precise-updates/+merge/133394 as merged? it's in  https://launchpad.net/ubuntu/+source/kde-l10n-sl/4:4.8.5-0ubuntu0.1
<seb128> pitti, (sorry for the direct ping but I mentioned it earlier and noboby picked it)
<cjwatson> apw: did you intentionally drop linux-headers-omap, linux-image-omap, and linux-omap from linux-meta for armel and armhf?  There's no clear mention in the changelog, and the diff for linux-meta has lots of */DEBIAN/* junk in it too ...
<cjwatson> apw: wait, never mind, I'm misreading and those binaries weren't actually dropped.  The */DEBIAN/* junk in the diff indicates that your source package build tree is dirty though, I think
<cjwatson> apw: but that shouldn't block migration to release, so just for your next upload or whatever
<seb128> can somebody mark https://code.launchpad.net/~matttbe/ubuntu/quantal/rhythmbox/1010619_795765/+merge/133343 as merged?
<seb128> pitti, ^
<apw> cjwatson, yeeks, i was pretty sure i git zapped the tree first ... :/  will look at it
<ogra_> dpkg-gencontrol: error: the Depends field contains an arch-specific dependency but the package is architecture all+
<ogra_> GRRR !
<ogra_> silly stuff, its a binary dep why shouldnt an arch all package not have arch specific binary deps
<cjwatson> Because arch-specific dependencies are valid in source package control files, but are processed at build time and are syntactically invalid in the binary package's control file
<ogra_> hmm, k
<pitti> seb128: looking (just returned from lunch, sorry for delay)
<seb128> pitti, no worry, nothing urgent, thanks!
<pitti> seb128: fini
<seb128> pitti, danke
<diwic> I've got an SRU for PulseAudio coming up. Any religious sacrifice I can do to make it a smooth sailing experience instead of it getting stuck on the stormy patch review ocean?
<seb128> diwic, don't have an impossible to review diff, have SRU compliant bugs for the changes you include?
<diwic> seb128, hmm, I think I got that covered
<diwic> It's okay to SRU four different bugs in one SRU, right?
<Laney> yeah
<Laney> if they all meet the criteria
<diwic> in case of PulseAudio, we've agreed to be a little more flexible; which is the case for at least one of the bugs, to avoid having to do a backport stack thing like we do for X
<seb128> diwic, yeah, as long as each bug is SRU compliant it's fine
 * diwic uploads and hopes it all will go well
<diwic> seb128, btw, how is the transition to gnome 3.6 going and should I do my reduction of the sound-nua delta before or after you upload 3.6 to raring?
<pitti> mvo: ok, committed a verified fix now, using tee instead of less
<pitti> mvo: doing an upload now; I want more green on jenkins :)
<seb128> diwic, 3.6 is being prepared in the vcs and and in https://launchpad.net/~ubuntu-desktop/+archive/ppa ... you are welcome to rebase the sound-nua ui bits, we just dropped that in favor of the upstream version so far
<seb128> diwic, it's not a blocker for the update but would be good to have
<mvo> pitti: thanks!
<mvo> pitti: I like tee more actually not less
 * mvo makes a cup of tea
<pitti> mvo: yeah, I couldn't make it work with a "sh -c"; and dd doesn't work either as it stumbles over the appended "-"
<diwic> seb128, okay. I think the unity UI looks better :-)
 * pitti chalks up the 6th fixed autopkgtest
<pitti> mvo: I'll fix unattended-upgrades now (stderr and missing dependency), ok?
<pitti> ah, cjwatson already committed the dep
<mitya57> pitti: thanks for docutils & python-markdown uploads, two items less in my todo list! :)
<pitti> mitya57: ah, I thought you already fixed markdown independently in svn?
<pitti> mitya57: docutils now built, so test suite runs fine during package build; it still failed in jenkins though, will have a look later
<mitya57> pitti: yes, but now it's not urgent for me to do a new upload
<mitya57> upstream bug for docutils is http://sourceforge.net/tracker/?func=detail&atid=422030&aid=3582720&group_id=38414
<mitya57> I'll maybe look at it if I have time
<pitti> mitya57: ah, thanks; I had a quick try to fix the _ElementWrapper â Element thingy, but failed
<pitti> yeah, and I have no clue about that one
<cjwatson> utlemming: I notice hv-kvp-daemon-init is built on all architectures - is it actually useful on non-x86?
 * mitya57 hopes that wifi will work better here
<mitya57> did I miss anything? :)
<pitti> mitya57: I said two things to you after your previous comment, then nothing related
<mitya57> pitti: please repeat...
<pitti> mitya57: ah, thanks; I had a quick try to fix the _ElementWrapper â Element thingy, but failed
<pitti> yeah, and I have no clue about that one
<pitti> mitya57: "that" -> the bug you referred to
<mitya57> that was not after my last comment, seems like it was not sent actually
<mitya57> <mitya57> pitti: "it still failed in jenkins though, will have a look later" â I don't see -0ubuntu3 jenkins job â where is it?
<pitti> mitya57: still on the internal one, will publish soon
<pitti> mitya57: actually it is: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-proposed-adt-python-docutils/lastFailedBuild/
<pitti> yay, unattended-upgrades now works locally, /me uploads
<mitya57> that one is with -0ubuntu1
 * pitti aime le vert
<mitya57> but ok, I'll wait until it's published
<pitti> oh right, that was the FTBFSing one
<Laney> ricotz: OK uploaded with some changes. Look at the diff to see what I changed - I suggest you do the same in Debian too
<pitti> mitya57: yay, it just succeeded!
<Laney> oops, was meant to be in #-desktop
<pitti> mitya57: (on the internal one for -proposed)
<mitya57> well done pitti!
<pitti> mitya57: well, it's at the price of disabling tests, but I don't know enough about it, and the failures are at least visible upstream
<pitti> I feel better about the other 6 fixes, as these fix things properly
<pitti> mitya57: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-proposed-adt-python-docutils/ :)
<snikker|2> i'm tring to recompile ubuquity, but i've got this error: http://pastebin.com/H2ke9ne3 can oyu help me, please?
<mitya57> I'll take a quick look at that right now
<snikker|2> mitya57: ok, thanks
<pitti> mvo: is someone working on the software-center failures?
<mitya57> snikker|2: that was for pitti, not for you :((
<xnox> snikker|2: please see #ubuntu-installer. please publish _full_ build log.
<mitya57> snikker|2: maybe xnox knows
<mitya57> oops, he's already here
<mitya57> :)
<seb128> is a build-depends "change libtiff4-dev to libtiff-dev" something worthing having a diff for on universe package?
<seb128> do we try to drop libtiff4-dev from ubuntu? (I didn't follow much what was happening in quantal thereÃ 
<seb128> )
<xnox> seb128: yes. it's a tiff4 -> tiff5 transition.
<seb128> e.g http://launchpadlibrarian.net/117905009/love_0.8.0-1_0.8.0-1ubuntu1.diff.gz
<seb128> xnox: we do it without debian on the whole archive?
<cjwatson> Yes
<seb128> ok
<seb128> thanks
<cjwatson> Please don't drop those changes, I spent ages on them
<cjwatson> Besides, they should be forwardable
<cjwatson> libtiff-dev is tiff4 in Debian right now; after wheezy releases it'll be flipped to tiff5
<seb128> cjwatson, I didn't plan to drop them don't worry, I was just asking because I was unsure if that was a "let's migrate the default install" or something we would take diff on the whole universe for
<cjwatson> the latter
<seb128> cjwatson, xnox: thanks
<cjwatson> I ran a transition tracker for it
<seb128> cjwatson, so "please use libtiff-dev" is valid for Debian reports as well? (double checking)
<snikker|2> xnox: i'm lookng for the full log, because in the terminal i don't have the full log
<cjwatson> seb128: Yes
<seb128> cjwatson, excellent, will forward that one then, thanks
<cjwatson> seb128: Though maintainers might well not apply it until later ...
<seb128> well, I just want to send a bug to the bts
<cjwatson> For anything that uses libtiff-dev in Debian, a binNMU will suffice to transition it to tiff5
<seb128> that's fine if it sits there for a while
<seb128> ok
<seb128> that makes sense
<cjwatson> seb128: the reason I did the whole archive rather than just a subset is that it became very quickly clear that if we transitioned just a subset then we ran into build failure problems with libtiff4-dev and libtiff5-dev conflicting
<cjwatson> it was *very* much easier to just do the lot
<seb128> I see
<seb128> that will go away once debian release as well and those are easy to cary until then so no worry
 * cjwatson fixes MoM again, hopefully
<mightyiam> ricotz: thanks for the libsecret patch
<ricotz> Laney, thanks!
<pitti> mvo: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-proposed-adt-ubuntu-release-upgrader/lastFailedBuild/ failed on amd64 because it expects "main restricted universe multiverse" in apt sources, but something writes it as "... multiverse universe"
<seb128> pitti, can you set https://code.launchpad.net/~hggdh2/ubuntu/precise/cobbler/lp-967815/+merge/132172 to "work in progress"?
<pitti> mvo: is that apt's fault, or u-r-upgrader's itself?
<pitti> seb128: done
<seb128> pitti, danke
<pitti> mvo: at least it succeeds on i386 now
<pitti> mvo: might be py 3.3 hash randomization or so?
<xnox> pitti: smells like PYTHONHASHSEED
<xnox> oh =)
<xnox> ;-)
<mvo> pitti: need to look in detail, but it does smell like the randomization
<pitti> mvo: I ran it two times with the same result
<pitti> mvo: but shouldn't this be ordered explicitly anyway?
<ScottK> seb128: There's no bug in debian/changelog for the havp upload you just did.  Would you please add it and reupload.  It breaks SRU tracking if we don't have it.
<mvo> pitti: let me check the failure in detail, it should be yes
 * pitti misses the gdb magic for debugging python (printing Python objects)
<seb128> ScottK, sorry about that, rejected the upload and redid it with the bug reference
<ScottK> seb128: Thanks.  No problem.
<mlankhorst> ugh this rename libdrm stuff scares me, hopefully it works and I'll never have to look at it again..
<seb128> pitti, could you see https://code.launchpad.net/~betienne/ubuntu/quantal/gelemental/update/+merge/131998 to "Work in progress"?
<snikker> xnox: sorry but i've got a problem with internet connection, btw the full log is here: http://pastebin.com/S3mTkpee
<xnox> snikker: it doesn't say what machine you are building it on.
<xnox> snikker: also 2.12.16 is the latest quantal installer. not 2.12.14.
<xnox> snikker: are you building this on quantal?
<snikker> yes i'm on quantal 64-bit
<snikker> xnon: --^
<snikker> xnox: --^
<bdrung> cjwatson: what does oif stand for?
<xnox> snikker: please try 2.12.16, not 2.12.14. We released images with 2.12.16
<cjwatson> bdrung: I just work here
<cjwatson> bdrung: I think it's Open Input Framework or some such
<Laney> https://launchpad.net/oif
<Laney> yeah
<snikker> xnox: on launchpad page of ubiquity, i've got this error: "Failed to fetch package details"
<snikker> xnox: now download page work
<cjwatson> just try again or follow the link rather than the expander
<mlankhorst> Laney: ok can I get all of -lts-quantal added to the xorg package list? :p
<Laney> mlankhorst: mail devel-permissions with a complete list
<seb128> could somebody set https://code.launchpad.net/~betienne/ubuntu/quantal/gelemental/update/+merge/131998 to "Work in progress"?
<seb128> https://code.launchpad.net/~utlemming/popularity-contest/oneiric.lp707311/+merge/131878 to rejected as well
<mlankhorst> Laney: ok is it enough that those packages were uploaded to a ppa in launchpad?
<Laney> dunno
<stokachu> Laney: did i break something? :D
<Laney> stokachu: yeah :( https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1076906
<ubottu> Launchpad bug 1076906 in libgcrypt11 (Ubuntu) "1.5.0-3ubuntu2 breaks gpg-agent" [Undecided,Confirmed]
<hallyn> slangasek: yuck, udevadm trigger action=change to fix the perms is as ugly as the initial udev and consolekit acls on the device :)  but, of course, if that's the proper way, i'll change to that (when I get a good chance to test).
<stokachu> damn
<hallyn> slangasek: one downside would have been that containers can't do udevadm trigger, but then they shouldn't get /dev/kvm auto-created by udev either so shouldn't have this bug.
<hallyn> thanks
<stokachu> Laney: this libgcrypt library is really becoming a headache
<Laney> I hadn't heard of it before this morning :-)
<stokachu> Laney: do you want to assign that to me?
<stokachu> Ill nominate it for the raring series
<Laney> the bug description there understates the impact BTW
<Laney> it meant I couldn't log in
<stokachu> ah ok
<Laney> see the dupe
<stokachu> ah
<xnox> stokachu: hah. breaking gpg-agent, breaks me logging into my desktop environment.
 * xnox disabled gpg-agent and carried on.....
<stokachu> lol
<cjwatson> time for a quick revert if you won't be able to fix it before the weekend?
<stokachu> cjwatson: yes please
<cjwatson> can you do that yourself or do you need help?
<stokachu> cjwatson: am i just creating a new debdiff with the previous code path?
<arges> tyhicks, hey when you have time, can you let me know what else is needed for bug 1052038? thanks
<ubottu> Launchpad bug 1052038 in ecryptfs-utils (Ubuntu Precise) "ecryptfs_fnek_sig missing when login at the same time on cron session close" [Medium,In progress] https://launchpad.net/bugs/1052038
<cjwatson> Just reverse-apply the debiff from 1.5.0-3ubuntu1 -> 1.5.0-3ubuntu2 apart from debian/changelog, and add a new changelog entry documenting the reason for the reversion
<xnox> stokachu: take old package, add the current changelog entry, add a higher version changelog entry saying "this reverts previous upload", generate package done =)
<stokachu> gotcha ill do that now
<cjwatson> That reminds me, I was going to create a wiki page with a brief log of all the reversions we do during the development cycle
<xnox> stokachu: well, and debdiff it =)
<cjwatson> Seems like a good time to start
<stokachu> cjwatson: i also updated teh appmenu-gtk with what i hope is correct way to m-a it
<stokachu> could i get a review/sponsor for bug 932860
<ubottu> Launchpad bug 932860 in appmenu-gtk (Ubuntu Quantal) "Broken (or missing) multiarch support" [High,In progress] https://launchpad.net/bugs/932860
<stokachu> also an approval for raring nomination
<xnox> Daviey: any good reason why python-gnupginterface is explicitely seeded in development/ubuntu-server?
<Daviey> xnox: i wasn't aware it was!
<Daviey> xnox: did you blame?
<xnox> Daviey: nah, I didn't blame. In precise the upgrade-tarball / landscape-client were using them. But not any more.
<xnox> Daviey: asking you as the ubuntu-server's seed point of contact.
<xnox> Daviey: unless I am very confused how/where development seed is included.
<Daviey> xnox: i don't think development was really defined.. If i am honest, foundations normally touches that
<xnox> Daviey: blame says mdz 2006 "add development seed"
<cjwatson> xnox: Feel free to ditch it if it's no longer appropriate
<xnox> Daviey: ok, thanks. I'll go talk to somebody in foundations..... =)
<Daviey> well that is the first commit, so doesn't help.. clealry broken out from something
<xnox> cjwatson: ack.
<cjwatson> stokachu: Of course this patch was in itself a regression fix :-/
<Daviey> xnox: JFDI. :)
<xnox> Daviey: it's just scary, why $ seeded-in-ubuntu -b python-gnupginterface
<xnox> reports: ubuntu-server: daily
<xnox> tumbleweed: ^^^^ can you help me understand above
<xnox> ?
<jpds> xnox: landscape-common ?
<stokachu> cjwatson: yea to many dependencies on libgcrypt
<cjwatson> seeded-in-ubuntu is badly named and concerns what's actually in images
<stokachu> Laney: i uploaded a revert to that gpg bug if you want to take a look
<xnox> jpds: not in raring anymore ;-)
<cjwatson> the development seed isn't relevant to images
<xnox> jpds: as in, in raring, landscape-common does not depend on python-gnupginterface.
<tumbleweed> better name suggestions are always appreciated
<cjwatson> xnox: well, germinate thinks that's why it's pulled in
<Daviey> Anyway, it's unseeded now :-)
<cjwatson> xnox: remember that seeded-in-ubuntu's output is based on the last successful image build
<xnox> cjwatson: so germinate will catch up, on the next run =)
<xnox> cjwatson: ah, so tomorrow it will be ok =)
<cjwatson> xnox: And you only changed landscape-client today
<snikker> xnox: smare error with ubiquity 2.12.16: http://pastebin.com/xLRJUbac
<snikker> *same
<Daviey> seeded-in-ubuntu IMO is just a guide.. i wouldn't trust it's output entirely.
<cjwatson> I trust its output, but only for the specific thing it does
<cjwatson> i.e. "what images is this on"
<cjwatson> tumbleweed: something like grep-ubuntu-images?  But I don't know whether it's worth the effort of renaming.
<tumbleweed> if there is a reasonable way to include germinate seeding, it could do that
<Daviey> cjwatson: Last cycle it reported openvswitch was in kubuntu, which it didn't seem to be.
<xnox> cjwatson: "smare error with ubiquity 2.12.16: http://pastebin.com/xLRJUbac " <--- any idea why the test now gests Eastern/Canada instead of Eastern/US on that users machine?
<cjwatson> Daviey: that was because I didn't purge the Kubuntu images that we weren't building any more for some time
<cjwatson> Daviey: But they were still the last on disk so it was reasonable
<Daviey> cjwatson: I don't believe it was /ever/ in kubuntu
<cjwatson> xnox: No
<xnox> snikker: can you reproduce this in a pbuilder? have you modified tzdata / ubuntu packages?
<xnox> snikker: the test does not fail on ubuntu dev machines, nor in ubuntu sbuild / pbuilder.
<xnox> snikker: if you really, really want to build ubiquity disable that test. but I'm guessing you are mixing up embeded software somewhere.
<xnox> cjwatson: Daviey: i'd like to drop all of the development seed. It only has a semi-random set of  python2 libraries that we want to all port to python3 and drop python2 equivalents from main.
<cjwatson> Daviey: Hard to debug at this point.  If you see oddities such as that again I'd be happy to look when the evidence is still present.
<cjwatson> xnox: If you do anything like that then please do a before/after comparison of germinate output to make sure that you aren't dropping things out of main that we want to keep supporting.
<cjwatson> (In terms of source packages.)
<snikker> xnox: i don't have modified nothing... i'll try in pbuild...how can u disable the test?
<xnox> cjwatson: ack. that was my first though. cause something useful might be hanging on via that.
<xnox> s/though/thought/
<cjwatson> stokachu,slangasek: I've created https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog so that we can collect data about these kinds of discussions
<Daviey> cjwatson: turns out, that example you already did.. http://irclogs.ubuntu.com/2012/10/02/%23ubuntu-release.html#t18:32 :)
<stokachu> cjwatson: ok cool ill update the wiki with outcome
<cjwatson> Daviey: you were apparently asking about package sets there, not about seeded-in-ubuntu output
<cjwatson> Daviey: so are you sure you're remembering it correctly now? :-)
<Daviey> cjwatson: Why let facts get in the way of a perfectly good rant? :)
<cjwatson> heh
<bdmurray> Is anybody uploading libgcrypt11 to raring?  If not I will.
<Laney> I'm test building it now
<Laney> you can take care of rejecting the SRUs
<Laney> if not done already
<bdmurray> Laney: I did that already
<Laney> stokachu: you don't need to explicitly target proposed when uploading to the dev series
<stokachu> Laney: ok ill note that down
<seb128> could somebody set https://code.launchpad.net/~betienne/ubuntu/quantal/gelemental/update/+merge/131998 to "Work in progress"?
<seb128>  https://code.launchpad.net/~utlemming/popularity-contest/oneiric.lp707311/+merge/131878 to rejected as well
<seb128> stgraber, ^?
<stgraber> sure
<seb128> thanks
<mpt> ev, why have the 12.04 and 12.10 lines stopped?
<ev> stopped?
<mpt> ev, yes, at October 26
<mpt> whereas the 13.04 line goes on to November 8
<xnox> ev: https://errors.ubuntu.com/ the graph not plotting 12.04 and 12.10
<ev> oh, that's fixed in trunk
<mpt> ok :-)
<xnox> also, raring has mood swings =)
<Laney> stokachu: ok, seems to work, uploading
<cjwatson> so few users of 13.04 as yet that the granularity is rather coarse, I suspect ...
<cjwatson> a lot of it seems to be failures to install ia32-libs-multiarch
<mpt> By my calculations there are 40.5 machines running Raring
<xnox> mpt: 1/8 of which are mine.
 * Laney has 2 of them
<mpt> It's probably the 0.5 of a machine that's causing all the trouble
<stgraber> that seems a bit low considering I have 8 just here, but quite a few never reported a crash so I guess that may still be correct ;)
<mpt> stgraber, yeah, I really mean 40 that have reported any errors so far
 * xnox is still at 1/8th
 * xnox goes to regenerate uuids....
<Laney> stokachu: ok, done. I expanded your changelog a bit, fixed the target and inserted a bug reference
<cjwatson> ia32-libs seems installable here, although I guess that's a relatively sensitive test
<cjwatson> but proposed-migration *should* have rendered that much more robust in the development series
<stokachu> Laney: ok thanks!
<cjwatson> four of the six reports I saw were from the same user
<cjwatson> *shrug*
<bdmurray> seb128: I've accepted libreoffice now
<seb128> bdmurray, thanks a lot
<seb128> Sweetshark, ^
<Sweetshark> bdmurray: thanks, awesome
<xnox> barry: python3-chardet is packaged as a separate source package.
<xnox> barry: so chardet is "ported"
<xnox> barry: do I mark it green on the spreadsheet? remove it? or simply drop it from the tracker?
<barry> xnox: yep, it's a separate upstream code base too
<xnox> barry: is it compatible?
<barry> xnox: in the 13.04 spreadsheet, i guess let's mark it green (doesn't matter too much i guess either way)
<xnox> barry: how about I drop it from the tracker?
<barry> xnox: i haven't done an exhaustive api comparison ;)
<barry> xnox: +1
<xnox> barry: =))) http://people.canonical.com/~ubuntu-archive/transitions/onlypy3oncd.html
<xnox> barry: similarly python-oauth should not be on the tracker, as we have oauthlib.
<barry> xnox: agreed.  i'm in the process of filing bugs on the relevant task:destktop packages to switch to oauthlib
<xnox> barry: ack.
<xnox> barry: is oauthlib in main yet? (Main-Inclusion-Report etc...)
<barry> xnox: that's a good question
<barry> xnox: yes, i think so.  fwiw, upstream just released 0.3.2 and that's now packaged in raring.  it fixes all the outstanding bugs we've had (and quilt patches we were carrying)
<xnox> barry: cool =)
<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 dicussion 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:
<seb128> stgraber, can you mark https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422 as "work in progress" as well?
<stgraber> seb128: done
<seb128> thanks
<slangasek> seb128: I'm not convinced that LibO should have a general exception to the SRU rule of "fix in dev first", but it doesn't need to be a hard rule, yeah
<slangasek> hallyn: udevadm trigger + containers> right, presumably you've already solved the general class of problem of udevadm called in a container
<slangasek> (or will soon :)
<hallyn> slangasek: nope :)
<hallyn> i meant :(
<hallyn> that's device ns
<hallyn> all we have now is a big stick
<hallyn> ("no writes under /sys)
<micahg> @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 dicussion 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: micahg
<micahg> I forget, was it decided to enable proposed when test building?
<marrusl> quick question... even for raring, the changelog for a patch should target raring-proposed yes?
<ogra-cb> no need for that
<dobey> marrusl: it doesn't matter if the changelog says raring or raring-proposed; it will go straight to -proposed anyway
<ogra-cb> your behavior doesnt need to change at all
<marrusl> gotcha.
<marrusl> while I'm here... is there a doc/wiki that will help me divine whether to bump the #ubuntu# version by 1 or .1 ?  (it's a really trivial patch)
<dobey> dch -i
 * micahg wonders how ogra doe IRC over CB
<marrusl> dobey, I should be in a raring chroot though, yes?  or does that not matter.
<ogra-cb> micahg, using ubuntu ;)
<ogra-cb> and xchat
<micahg> dobey: that's not clear
<dobey> marrusl: doesn't matter, you can change the entry to raring if it doesn't set it to it
<marrusl> dobey, right.  ok just wondering if that affects the behavior of dch -i....  which now makes no sense to me. basically I'm hearing trust dch -i  :)
<dobey> marrusl: using .1 is typically for special cases where the exact same version already exists on development version and stable version, and you need to update both; the stable version would get the .1
<micahg> marrusl: SRUs general bump by .X, dev release is generally X, dch -i won't DTRT for the first SRU of something
<marrusl> aaah.... that helps!
<ogra-cb> security is also usually .X
<marrusl> dobey, micahg, ogra-cb .....  much appreciated!
<micahg> security update versioning is documented: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<dobey> marrusl: simple solution; never trust software. but it's text file and dch -i just adds a new section. you can still tweak it appropriately in $EDITOR :)
<marrusl> dobey, right yeah, for something this minor I can't think of a good reason to bother with a chroot even.  that's pretty much what I've done before.  minimal effor... pull-lp-source; vi  :)
<marrusl> cool.
<micahg> ogra-cb: stgraber: is https://launchpad.net/ubuntu/+source/classmate-initramfs still useful?
<ogra-cb> micahg, no, should be burned
<micahg> ogra-cb: thanks, will file for removal
<micahg> can a TB person please mark this as WIP or rejected: https://code.launchpad.net/~vericalcroft/ubuntu/quantal/classmate-initramfs/added-misc-depends/+merge/125442
<micahg> can I get a TB person to mark this as merged: https://code.launchpad.net/~obounaim/ubuntu/quantal/z3c.formui/added-homepage/+merge/125418
<stgraber> micahg: done
<stgraber> micahg: feel free to highlight me directly for those, I don't always notice "TB" :)
<micahg> stgraber: ok, thanks
<slangasek> seb128: isn't the conclusion here that we should make Logan a MOTU and then the sponsorship queue will be manageable again? :)
<micahg> @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 dicussion 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:
<seb128> slangasek, yeah, I told Daniel that he should get him onboard ;-)
 * slangasek grins
<obounaim> micahg, what does TB stands for?
<infinity> obounaim: Tech Board.
<obounaim> ok thanks
<ogra-cb> or thunderbirs if tou are in the #ubuntu-desktop channel ;)
<ogra-cb> *you
<zZommm> hello everyone, i have a packaging question, hope someone can help me here.
<zZommm> i tried building libvirt-1.0.0 for quantal.
<zZommm> threw out a few patches that were not needed, a few other changes and now it builds.
<zZommm> but libvirt0 depends on libyajl1 instead of libyajl2. what could have gone wrong? libyajl1 is not even in quantal.
<zZommm> shlibs:Depends is obviously right, because the library in the built package is linked to yajl1:
<zZommm> $ ldd libvirt.so.0.1000.0  | grep yajl
<zZommm>         libyajl.so.1 => not found
<slangasek> zZommm: to have generated such a reference, you must have had libyajl.so.1 somewhere on your system when you built it.  Perhaps there's an embedded copy in the source tree?
<zZommm> i'll check, but i doubt it.
<zZommm> this is a fresh quantal install and i've used pbuilder to build the package.
<zZommm> slangasek, no, nothing on the system with yajl and 1 in the name
<zZommm> as i've said, fresh QQ install, pbuilder env created and this package built. Nothing else.
<slangasek> zZommm: oh.  Does this show up when you instead run 'objdump -p libvirt.so.0.1000.0 | grep NEEDED.*yajl ?
<slangasek> '
<zZommm> slangasek, yes:   NEEDED               libyajl.so.1
<slangasek> fun fun
<slangasek> zZommm: well, it would be nontrivial to generate a library with that content without the library actually being present at build time
<zZommm> yes it is :) the package build-depends on libyajl-dev, and that has only version 2.0.something available, it couldn't be anything else.
<zZommm> ok
<zZommm> i'll build again and keep the pbuilder chroot.
<slangasek> right, let me check the *actual* contents of libyajl2
<zZommm> this is a first one for me too, i've built (backported mostly) my fair share of packages and never encountered this.
<slangasek> the libyajl2 package in the archive is correct (filename libyajl.so.2, soname matches)
<slangasek> is the source package that you're building available somewher?
<zZommm> no.
<zZommm> but i can put it somewhere.
<zZommm> just a sec.
<zZommm> slangasek, http://9bit.biz/libvirt/
<slangasek> zZommm: and you're sure this isn't a matter of building it in the wrong pbuilder chroot?
<zZommm> 100%
<zZommm> wait
<zZommm> i'll check again
<slangasek> because precise had libyajl1
<zZommm> yes
<zZommm> that was it
<zZommm> pbuilder set up a wrong chroot
<zZommm> stupid stupid stupid me for missing that
<zZommm> thank you.
<slangasek> aha, ok :)
<zZommm> who would have thought
<zZommm> that the debootstrap default on quantal is precise.
<zZommm> according to the manpage pbuilder uses debootstrap default if nothing is specified
<Sweetshark> anyone here able to nominate bug 1017125 for quantal pls? thx.
<ubottu> Launchpad bug 1017125 in boost1.49 (Ubuntu Quantal) "[SRU quantal] boost::unordered_multimap<>::erase(iterator, iterator) broken in boost1.49" [High,New] https://launchpad.net/bugs/1017125
<Sweetshark> disregard that. already happened
<cjwatson> zZommm: I can't see such a statement in pbuilder's man page, and debootstrap doesn't *have* a default
<zZommm> cjwatson, let me check again... i might have misread. Anyway, i ran pbuilder create without any other parameters and it created a precise chroot.
<cjwatson> pbuilder has its own default
<cjwatson> which is indeed still precise
<zZommm> my mistake, yes. I was skimming over the manpage and somehow concluded that it used debootstrap defaults. which is strange, since debootstrap requires you to specify the distribution :)
<cjwatson> exactly
<zZommm> ok, package built and installed, seems to be working :)
<zZommm> should i submit this somewhere? Debian already has libvirt-1.0.0 in experimantal, i just used the latest ubuntu packaging and applied it to the new version. I had to remove a few patches that are not needed anymore and make one or two other small changes.
<infinity> zZommm: You might want to talk to smb and see what he's got going on for libvirt for raring.
<infinity> zZommm: Or possibly hallyn.
<slangasek> indeed, there was a UDS session about libvirt plans
<zZommm> i'll check that out.
<slangasek> http://summit.ubuntu.com/uds-r/meeting/21087/servercloud-r-libvirt/
<zZommm> thanks
<sarnold> .. I thought someone had a 1.0.0 ready to upload already?
<infinity> That's not much for session notes.
<zZommm> i created a package because 0.9.13 (in Q) has trouble with openvswitch networking.
<slangasek> the blueprint has some notes, and also points at the people to harrass :)
<infinity> (which happens to be the two people I mentioned, though in the inverse order)
<infinity> zZommm: If you can identify what needs fixing and backport a patch to SRU 0.9.13, that might be nice.  We don't tend to push new versions to old releases, except in exceptional cases.
<zZommm> i don't need you to put it in Q, i made this for me. But since the package should also work on R, I don't see a reason not to share it :)
<zZommm> infinity, the problem on Q is that virt-manager does not really know what to do if you're using openvswitch. It just tries to use the classic linux bridge and fails.
<slangasek> mdeslaur: that reminds me... did you have any further thoughts on the OVMF thing in virt-manager?  Given that we do have to change both the bios and the video bios
<zZommm> libvirt 0.9.13 supports ovs, but only if you change the XML config of a VM by hand. Creating a new network type with ovs config doesn't really work (well). Or so I've been told by a libvirt developer earlier today.
<zZommm> I can't access that blueprint, seems i'm not sexy enough :)
<marrusl> zZommm, I think you just need to join the ~ubuntu-etherpad group in LP.  Anyway, that's the etherpad for the UDS discussion, here's the actual blueprint:
<marrusl> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-libvirt
<zZommm> thanks.
<marrusl> np!
<zZommm> i msgd him, but he's obviously not here, and I'm not on IRC 24/7. Should I send an email? would that be hallyn at canonical?
<zZommm> oh i got it, i can get the email off launchpad. good.
<mdeslaur> slangasek: I've poked at it a bit, but I can't think of a good way to do it that isn't a complete hack....the best idea I've come up with so far is to define a new arch, ie: "x86_64 UEFI" or something, and use a qemu-system-x86_64-uefi wrapper
<slangasek> mdeslaur: hrm; why is that better than just setting the xml options?
<mdeslaur> slangasek: because the xml files are handled by libvirt, and virt-manager is a level of abstraction away from that, and all the options are determined by libvirt "capabilities"
<slangasek> ok
<slangasek> so would libvirt need extended first?
<mdeslaur> yes, and even libvirt doesn't really know things like filesystem paths, it's relying on qemu knowing all about that
<mdeslaur> so in theory, you can specify the video bios as part of the xml definition of the video adapter, but that part isn't hooked up yet in the qemu libvirt backend
<mdeslaur> it's a big abstracted mess
<slangasek> can you?  I didn't find a libvirt option for specifying a video bios, only a card type
<mdeslaur> devices, like network cards, have a "romfile" option
<mdeslaur> qemu supports the same property for video devices
<mdeslaur> slangasek: there's some info in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=811227
<ubottu> bugzilla.redhat.com bug 811227 in libvirt "RFE: Ability to specify custom BIOS for QEMU/KVM using <loader> XML (for WHQL testing)" [Unspecified,Closed: errata]
<mdeslaur> slangasek: and also a link to how to combine the video rom into the main rom
<mdeslaur> slangasek: but even if we do that, the gui would still be pretty awkward...ie: you'd have to manually specify an alternate bios for the video device, etc.
<mdeslaur> which is why I was thinking of just creating a new arch (x86_64 EUFI)
<mdeslaur> whoops, UEFI
<slangasek> right... it's also not great to allow users to specify incompatible combinations of bios and video rom
<mdeslaur> the ovmf package could ship the qemu-system-x86_64-uefi and qemu-system-i386-uefi scripts, which would just be a shell file that adds the appropriate option for the alternate directory
<mdeslaur> and a trivial distro patch could be added to libvirt to gain knowledge of those two new archs
<mdeslaur> it's also hackish, but that's where I'm at now
<mdeslaur> (is i386 relevant for UEFI?)
<sarnold> mdeslaur: _maybe_ initial apple intel machines?
<mdeslaur> sarnold: I'm not sure that relevant for ovmf
<mdeslaur> oh, seems vvmf does have some 32 bit stuff
<cjwatson> mdeslaur: in principle, although not currently in practice for Ubuntu
<mdeslaur> slangasek: do you have a package somewhere with the ovmf stuff in it?
<slangasek> mdeslaur: not yet... jk took the action to provide that
<slangasek> (I think he has a binary build floating about somewhere)
<jelmer> One of my syncs into raring was just rejected "Rejected by archive administrator.". How do I tell why that is?
<xnox> jelmer: DO NOT PANIC - we are removing armel
<xnox> jelmer: check the publishing history, probably just the armel binary was "rejected"
<jelmer> xnox: ah, ok - thanks
#ubuntu-devel 2012-11-10
<psusi> anyone know what the status is with x32?
<cjwatson> xnox: Eh, let's check
<cjwatson> jelmer: What was the package name?
<xnox> cjwatson: i had it with git.
<cjwatson> Yes, I want to know what jelmer got, please :)
<xnox> psusi: we had a uds session about it, check uds notes...
<jelmer> cjwatson: ldb
<jelmer> cjwatson: shall I forward the email to you?
<cjwatson> jelmer: No need, thanks.  This is indeed the removal of armel - I just wanted to check.
<cjwatson> I've had cases before where I missed real problems because I assumed that they were related to something known that was ongoing without checking.
<xnox> cjwatson: samba4 on armel is in depwait state: https://launchpad.net/ubuntu/+source/samba4/4.0.0~rc4+dfsg1-1/+build/3969881
<cjwatson> xnox: That's OK.  If the dep-wait ever clears, it'll flip to superseded.
<xnox> cjwatson: ok.
<mspencer> I'm working on LP #657275, once the report is saved, what should be done with it then? Automatically send it when connected to the Internet, tell the user where it was saved and have the user deal with it, or what?
<ubottu> Launchpad bug 657275 in apport (Ubuntu) "ubuntu-bug should save reports offline automatically rather than giving a cryptic error message" [Wishlist,In progress] https://launchpad.net/bugs/657275
<bogor> I downloaded apt source code and i am trying to read it so that i can write a plugin. But apt source contains many folder and many many files. Can someone suggest me where i should start ?
<mightyiam> morrrrniiiiiig goodee
<OdyX> tkamppeter, pitti: you might want to take a look at Debian #692791, cups STR #4223 .
<ubottu> Debian bug 692791 in cups "members of lpadmin can read every file on server via cups" [Critical,Open] http://bugs.debian.org/692791
<mspencer> Hi, I'm working on LP #657275. Once the report is saved, what should be done with it? Automatically send it when connected to the Internet, tell the user where it was saved and have the user deal with it, or what?
<ubottu> Launchpad bug 657275 in apport (Ubuntu) "ubuntu-bug should save reports offline automatically rather than giving a cryptic error message" [Wishlist,In progress] https://launchpad.net/bugs/657275
#ubuntu-devel 2012-11-11
<bjsnider> i'm trying to submit updated scripts so gecko-mediaplayer will build in raring, but i can't find the lp branch
<bjsnider> assuming there is one. otherwise i don't know what the procedure would be
<bjsnider> it will not build now due to changes in the gecko sdk
<trism> bjsnider: lp:ubuntu/gecko-mediaplayer , seems to still build though
<bjsnider> where's the buildlog?
<bjsnider> i think it was just copied over from an early quantal build
<trism> bjsnider: yeah it was, I just rebuilt it locally, if you mean the build failure from quantal, that was fixed in 1.0.6-1ubuntu2
<bjsnider> wait
<bjsnider>  i just checked the changelog
<bjsnider> someone already implemented the changes i was going to propose
<bjsnider> that's good
<bjsnider> i knew about the problem and the fix weeks before the build failure happened and the bug and fix were submitted. it seems like it would have been good if i had been notified of the build failure when it happened
<bjsnider> well, about one week anyway
<persia> bjsnider: You might look at the FTBFS page source for some code that does polling of build failures, and then run something similar that drives some notification system for the packages about which you wish to be notified.
<persia> That said, most folk who have such knowledge post fixes to the upstream VCS or bug tracker (depending), which fixes are often cherrypicked by those Ubuntu developers working on FTBFS who prefer research to rediscovery.
<mah454> I Compiled new kernel and switch to this , but consoles [tty1-6] (Ctrl+Alt+F[123456]) not work !
<mah454> How can find problem and fix it ?
<mah454> all options on drivers -> character devices enabled ...
<TomFlint> hello
<queency> hello all : can you tell me where is the logs of start-stop-daemon ?
<infinity> queency: It doesn't log, its callers are responsible for logging, if appropriate.
<queency> How can i direct the output to my open terminal ?
<lfaraone> queency: this quesiton may be better answered in #ubuntu
<lfaraone> "/script exec $ENV{'TZ'}='<nameofyourtimezone>';"
<micahg> stgraber: https://code.launchpad.net/~vericalcroft/ubuntu/quantal/classmate-initramfs/added-misc-depends/+merge/125442 to WIP/rejected please
<stgraber> micahg: done
<micahg> stgraber: thanks
<DNS> hi.. how to add an entry to the ubuntu software center, or in other words how to make it visible? is this info stored in a .desktop file?
<DNS> should i rephrase? not sure if my question was clear
<jtaylor> I think the info is in the desktop file
<DNS> hm
<DNS> do the icons in usc need to have min size?
<DNS> probably
<DNS> anyone knows which size exactly?
<cjwatson> BenC: Looking at your linux-ppc package - since this is to be the primary set of kernels for powerpc, shouldn't it generate linux-libc-dev, not linux-ppc-libc-dev?  Otherwise libc won't actually end up depending on it, and will probably become uninstallable when we try to drop the NBS binaries from linux
<DNS> or max size
<cjwatson> BenC: Also, there's some debian/*/DEBIAN cruft
<BenC> cjwatson: It's not going to generate that package at all
<cjwatson> Indeed some general unclean-source-type stuff
<cjwatson> BenC: Not going to generate which package?
<BenC> cjwatson: the master linux package is still building linux-libc-dev
<cjwatson> For all architectures, really?
<jtaylor> DNS: the smallest size in share/icons is 16x16 I guess thats the minimum
<cjwatson> I thought it wasn't going to build on powerpc at all any more
<BenC> cjwatson: linux-ppc-libc-dev may show in the control file, but the rules have it forced to not build (in linux-ppc)
<cjwatson> Oh, what do you know, it's still there.  OK
<BenC> cjwatson: I talked with apw and rtg and we decided it was best to have it still built from linux.master
 * cjwatson peers at linux
<cjwatson> OK, gotcha.  5-minute linux build on powerpc, that's gotta be a first
<psusi> it fail to build? ;)
<BenC> Yeah, very tame :)
<cjwatson> psusi: successful, but building only headers
<cjwatson> BenC: Do you think you could fix up base-installer at some point to know about the new kernel names and conditions for using them?
<cjwatson> It has a test suite and everything these days ;-)
<BenC> cjwatson: Yeah, definitely
<BenC> cjwatson: Is does base-installer cover livecd and alternate installer?
<cjwatson> Latter yes, former sort of mostly
<cjwatson> Probably simplest if I advise once I see the base-installer diff
<cjwatson> Are the new kernel flavours for actual different subarchitectures (i.e. the existing powerpc-smp and powerpc64-smp won't boot), or are they optimised?
<BenC> cjwatson: Also, I'll be working on grub-kexec starting tomorrow, since the e500* kernels depend on this missing package
<cjwatson> OK
<cjwatson> Hm, so that will block this from getting into raring which will in turn block the master kernels ...
<cjwatson> I might end up forcing that for now
<cjwatson> (NEWed, anyway, so it can build overnight)
<BenC> Actual different sub-architectures. The regular kernels won't boot on e500* and the e500* kernels only work on those systems
<BenC> Thanks
<cjwatson> OK, so you end up with a ginormous live CD if you want that to boot on everything
<cjwatson> I guess
<BenC> Recommends: grub-kexec
<cjwatson> Oh, that's OK then
<BenC> Might be ok, since it isn't depends?
<cjwatson> We're still waiting for linux-lowlatency to be updated anyway
<BenC> cjwatson: yeah, and I'm unsure if we should just create a new CD for e500* or not
<cjwatson> Can they handle DVDs?
<cjwatson> Or USB?
<BenC> USB, DVD if you have a USB capable external (our system doesn't have any CD/DVD media built-in)
<cjwatson> If so I'd be inclined to suggest just bloating the image, as otherwise you're going to end up increasing the test matrix for any Ubuntu flavour including powerpc
<BenC> I'm all for that
<BenC> bloating the image, that is
<cjwatson> anyway, gotta run
<BenC> cjwatson: Thanks for processing the packages
<cjwatson> np
#ubuntu-devel 2013-11-04
<xnox> highvoltage: =)))) it was magic to me, when "accelerated" dlocate was pointed out to me.
<infinity> siretart: I noticed, yep.  handbrake finally built after being in proposed for two cycles. :P
<infinity> siretart: I guess as soon as the libtiff5 transition happens in Debian, we can just sync?  That'll be pleasant.
<infinity> siretart: Should make security much simpler too, assuming you're already doing decent security support for libav in Debian.
<infinity> (And maybe no one is... Hrm...)
<pitti> Good morning
<infinity> jamesh: Where did your openvswitch "2.0.0" come from?  All I can find tagged upstream is 1.9.3
<infinity> jamesh: Also, still not ported to 3.12.  Boo.
<infinity> jamesh: Err, james tab fail.
<infinity> jamespage: ^^^
<pitti> http://openvswitch.org/releases/openvswitch-2.0.0.tar.gz ?
<pitti> (that's what Debian PTS says, with the watchfile)
<infinity> pitti: Cute, given that it's not tagged in git.
<infinity> Looks like maybe they just forgot to tag it, I see the "prepare" commit.
<infinity> jamespage: Nevermind on the first question, looks like they just forgot to tag it.
<infinity> jamespage: The "not ported to 3.12" thing's still irksome, though.  I now have autopkgtest yelling at me. :P
<pitti> perhaps we could add a linux-libc-dev build depend to openvswitch, so that in the future openvswitch's autopkgtest runs with a kernel update
<pitti> then the kernel would be held back until openvswitch is fixed, instead of silently breaking it
<infinity> pitti: Hrm?
<infinity> pitti: It's not linux-libc-dev, it's linux-headers (it's a dkms module that explodes), but yeah, ISWYM.
<pitti> infinity: ah, or make openvswitch-datapath-dkms depend on some linux-y package, sure
<pitti> not sure whether we would actually want to block the kernel for these, but in principle it's "new linux breaks existing stuff"
<infinity> pitti: Well.  It shouldn't.  That's a bit of a problem.  Adding arbitrary incorrect dependencies to trick adt seems a bad idea.
<pitti> infinity: not really -- openvswitch-datapath-dkms does need the kernel headers and doesn't depend on them
<infinity> pitti: No, no, no, no.  And no.
<pitti> we just mostly don't add them because we don't know *which* kernel headers to depend on
<pitti> it's a kind of "implicit", "you need some of them" dependency
<infinity> pitti: I've faught hard to get people to STOP adding linux-headers-foo deps to packages, because they're never correct, and can't be.
<pitti> which we can't express
<pitti> infinity: yes, I'm aware of that
<infinity> pitti: No different from packages that depend on a linux kernel version, we can't express that either.
<pitti> infinity: hence my proposal to add linux-libc-dev instead, which is also built by the kernel
<pitti> while any fixed package name as a dep is wrong, not having any dependency at all is also wrong
<pitti> it's just more conveniently wrong :)
<pitti> but stops us from being able to detect those regressions in -proposed
<infinity> I suppose it ends up pulling in linux-libc-dev anyway, since it depends on libc6-dev, so it's not going to add more useless croft.
<infinity> Nor cruft...
<pitti> yes, it's build-essential
<infinity> But perhaps we should rather special-case dkms rdeps to recurse for kernel testing.
<infinity> Adding debian/control curft to every dkms package seems inelegant.
<infinity> WHY CAN'T I TYPE THE WORD CRUFT?!
<pitti> (you just did)
<infinity> Yeah, yeah. :P
<infinity> croft... curft... I'm on a roll.
<pitti> but yes, it affects many other packages, too
<pitti> infinity: we have a whole set of jenkins jobs for dkms, FYI (https://jenkins.qa.ubuntu.com/view/DKMS/)
<infinity> pitti: Yeah, I know, but those don't block kernel migration, clearly.
<infinity> Or proposed migration in general.
<pitti> right
<pitti> jibel and the kernel team discussed that at length, not sure whether not blocking in -proposed on DKMS regressions was intended or not
<pitti> (as we clearly don't want to block it for *every* DKMS package we have in the archive)
<infinity> Sure we do.
<infinity> Just as we block on any other regression.  So we can examine the situation and take a decision.
<infinity> The kernel isn't any more a unique snowflake than any other package in that regard.
<pitti> I guess their concern was that we don't really support most DKMS packages that we import from Debian, and if we'd do that blocking we essentially would have to
<infinity> See, the way I see it, we have to either fix, remove, or temporarily ignore every failure.  But it's better to know than not.
<infinity> Just like any other transition.
<pitti> we certainly don't want to break the nvidia/fglrx/bcmwl drivers with new kernels, though
<infinity> A, B, and C get fixed, D gets removed because we don't care.
<infinity> Leaving D broken is bad.  Not fixing C when we could have with a trivial patch is also bad.
<pitti> I'd be happy with that; I was just saying what they discussed back then
<infinity> I think the story is different for lts-hwe stuff, where a dkms package might work with 3.2 but not 3.8, and we might opt to just leave the 3.8 path broken.
<infinity> But no such excuse in a devel series with only one kernel.
<infinity> Anyhow, I don't remember ever discussing tying this into britney when we talked about dkms automagic testing, so I don't think there's some process failure here, just something we never got around to discussing and implementing. :)
<jibel> we never discussed about blocking automatically the kernel when there is a failure with a dkms module. Currently kernel n+1 from the kernel team ppa is tested and manually reviewed, and published to the distro after review by the kernel team.
<infinity> jibel: Sure, I know, I'm a big part of the SRU process, and that's all basically fine, IMO, but I think the devel process might need some work here.
<infinity> jibel: Not anything newly broken that wasn't before, so no big rush to sort out something better, but I think we should think about it.
 * infinity glares at libticables' configure.ac and wishes for laser vision.
 * xnox thought at one point we wanted to block kernel on some _important_ dkms modules, but not all of them.
<jamespage> infinity, I failed to find time for the powerpc build failure as well
<jamespage> infinity, and yes it does not support 3.12
<infinity> jamespage: I fixed the PPC failure, which is why I'm now being yelled at by autopktest about 3.12 incompat. ;)
<jamespage> infinity, but we may actually be able to drop the dkms packages as the kernel natively supports GRE and VXLAN tunnels
<jamespage> infinity, but I still need to check that out...
<infinity> jamespage: Oh, if the dkms package can disappear, that would be lovely.
<jamespage> infinity, agreed - I'm really looking forward to not having to fix it with every kernel bump we do
<jamespage> I had to cherry pick the 3.11 support from trunk
<infinity> jamespage: Yeahp, and by the time 3.12 is fixed, we'll be on 3.13. ;)
<infinity> (Not to mention lts-backport kernels in 14.04...)
<jamespage> infinity, I just need to check with upstream with some of the megaflows stuff - I don't understand whether thats in the upstream native kernel module or not
<jamespage> and will be important to some larger cloud users
<jamespage> infinity, time is my problem this week
<infinity> jamespage: I'm happy to leave it in its current state in proposed, if you're chasing down the dkms things.  I was just whining because of the angry email I got after fixing it. :)
<jamespage> infinity, OK - leave it with me - I'll check this next week
<jibel> pitti, I proposed a patch for sbuild and pbuilder autopkgtest failures. If you have a minute for a review it is bug 1247420
<ubottu> bug 1247420 in sbuild (Ubuntu) "autopkgtest failure: build deps of procenv cannot be satisfied because expat is in universe and universe is not enabled" [High,Triaged] https://launchpad.net/bugs/1247420
<pitti> jibel: oh, do we limit autopkgtest dependencies to main now for main packages?
<jibel> pitti, no it is in the test, the chroot used to test pbuilder and sbuild only have main enabled
<infinity> Yeah, it's creating a chroot in the test, which makes sense, given the package being tested.
<infinity> jibel: So, I'm all for the other improvements to those tests (fixing set -e, using better lsb_release bits), but would have been nice to have them in another commit, so you could more easily split out the bunch and submit them to Debian as two different patches.
<pitti> jibel: or it could perhaps build a package in main?
<pitti> infinity: the autopkgtest of at least sbuild isn't in Debian at all, FYI
<infinity> Oh, it's not?  Figured it was, given the lsb_release forking based on release.
<infinity> Nevermind, then. :)
<pitti> jibel: ah, nevermind; with that it can test the "components=" functionality, too :)
 * infinity does appreciate it when a test tests as much as it can.
<infinity> Unit testing is for wimps.
 * infinity is quite fond of rbasak's libapache2-mod-svn test that appears to test svnadmin, svn, and the apache module, all in one go.
<infinity> Which is, basically, the entire source package.
<pitti> i. e. "fastest" and "hardest to debug" :)
<pitti> but as long as these tests give you useful output when they fail, it seems okay
<infinity> pitti: Well, when your testsuite is essentially a shell script, it's not hard to debug where one line breaks.
<infinity> (Obviously, unit testing and the like have their place when your tests need to be more complex, or you're testing for specific regressions, etc, but most autopkgtests don't seem that fancy)
<infinity> I do question if maybe some of them SHOULD be that fancy.
<pitti> jibel: can you please forward the updated test to debian bug 705926 ?
<ubottu> Debian bug 705926 in sbuild "sbuild: Add basic DEP-8 autopkgtest" [Normal,Open] http://bugs.debian.org/705926
<infinity> When I was working on Maemo, we were religiously breaking build-time test suites out into -tests runtime packages and mangling them to run under a runtime test harness.
<infinity> Which, obviously, took way longer to run than the average autopkgtest, but also provided some decent coverage in some cases.
<infinity> Undecided if the pain was worth it.
<jibel> pitti, sure, and pbuilder diff to 705917
<pitti> jibel: en effet, merci !
<sil2100> stgraber: ping!
<pitti> tseliot: hm, nvidia and fglrx build, but nvidia-updates and fglrx-updates fail: http://paste.ubuntu.com/6357855/
<pitti> tseliot: (detected by ubuntu-drivers-common autopkgtest)
<pitti> tseliot: want a bug for that, or are you on it? I suppose the non-updates variants have a patch which isn't applied to -updates?
<tseliot> pitti: I'm wondering why the system we have in place doesn't send me an email as planned
<pitti> tseliot: that's
<pitti> err
<pitti> tseliot: that's mostly because the autopkgtest isn't in the nvidia/fglrx package itself, but in u-d-common; that didn't get an upload
<pitti> tseliot: so the system doesn't know whom to contact, it just contacts jibel and me as fallback
<tseliot> pitti: oh, ok. Please add my email address when you can. I'll check all the flavours, just to be sure
<pitti> tseliot: the other flavours are fine; the current u-d-c test on jenkins fails all of them due to something else, but I just fixed that in git (uploading now)
<pitti> well, we test nvidia 304 and 319 and fglrx, and all -upates for those, perhaps there are other flavours by now
<tseliot> pitti: there's 173. Also I'm going to introduce 331
<pitti> tseliot: thanks; I'm uploading u-d-common now as the other tests are fixed again
<tseliot> pitti: ok, thanks
<didrocks> pitti: hey!
<seb128> is anyone here on saucy with some hardware which requires binary drivers (e.g use of the software-properties' driver install)
<seb128> I need somebody to SRU confirm bug #1241210
<ubottu> bug 1241210 in software-properties (Ubuntu Saucy) "shouldn't use deprecated gtk-logout-helper" [High,Fix committed] https://launchpad.net/bugs/1241210
<didrocks> pitti: IIRC, you were the one adding me to ubuntu-drivers. I think I'm going to expire from the team. I think it would make more sense that I'm part of this team through UDS organizer, being a track lead?
<didrocks> pitti: it seems only the tech board (but only having sabdfl in this team?) is an admin for it
<seb128> didrocks, TB expired and need to be renewed I think, until then you might need sabdfl/get stucked :/
<didrocks> yeah, let's see how it goesâ¦
<didrocks> I guess the issue of TB expiring impacted many other nominations
<pitti> didrocks: -ENOTECHBOARD at the moment, I'm afraid :/
<didrocks> yeah
<pitti> seb128: /usr/share/ubuntu-drivers-common/fake-devices-wrapper software-properties-gtk ?
<seb128> pitti, thanks, I didn't know about /usr/share/ubuntu-drivers-common/fake-devices-wrapper
<pitti> seb128: heh, I cobbled that together back then for that very reason (it's been a while since I actually had a computer which needs binary drivers)
<seb128> pitti, is it actually downloading/installed drivers when you use the UI? (it seems to be really downloading stuff, I wonder if I'm going to end up with nvidia installed :p)
<seb128> it does it seems
<pitti> seb128: yes, you will
<pitti> so better uninstall it again afterwards, unless that's a VM
<seb128> pitti, thanks
<seb128> (hum, it doesn't prompt me for reboot :/)
<pitti> seb128: in the original designs it was supposed to update the status to something like that after installation ("restart computer to activate" or so)
<seb128> pitti, well, I'm trying to test https://code.launchpad.net/~seb128/software-properties/dont-use-deprecated-reboot-commands/+merge/191720
 * seb128 reads code again
<seb128> good, that's working
<seb128> pitti, danke
<pitti> seb128: ah, good; seems a bit confusing to invoke that dialog, but I guess better than no confirmation at all
<seb128> pitti, right, better than getting a whoopsie dialog because the code is calling a non existing binary, in any case
<pitti> heh, absolutely :)
<hrw> hi
<brainwash> pitti: hey, could the logind resume issue be indeed related to some bug in kernel 3.11? the new systemd-shim package only fixed the problem for like 50% of the people
<pitti> brainwash: or it could be that they suspended for more than 10 minutes?
<pitti> brainwash: if that's not it, then I suppose there's another, independent, bug somewhere between logind and shim
<brainwash> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1184262/comments/103
<ubottu> Ubuntu bug 1184262 in systemd-shim (Ubuntu Trusty) "[logind] times out too early, stuck in PrepareForSleep, causing network and other services to not resume" [High,In progress]
<brainwash> maybe the 30sec d-bus timeout?
<brainwash> i can only reproduce it with a fake suspend
<brainwash> but it would explain why logind does not get stuck for some people, it simply reverts back to PrepareForSleep = false after the d-bus timeout
<brainwash> hopefully some people will post their log files
<maxiaojun> https://bugs.launchpad.net/ubuntu/+source/rar/+bug/776851
<ubottu> Ubuntu bug 776851 in rar (Ubuntu) "Please backport rar 2:4.2.0-0ubuntu1 from raring" [Undecided,Confirmed]
<maxiaojun> can anyone help this?
<xnox> maxiaojun: why bug against ubuntu-package? backports are tracked / managed by backports projects only.
<maxiaojun> the bug wasn't a back port request
<xnox> maxiaojun: it had tasks open against Backports project so yes, it was a backport request. Was it meant to be something else?
<xnox> maxiaojun: and it's fix-released in 13.04 and up.
<maxiaojun> xnox: fixed in short term releases isn't that useful
<maxiaojun> xnox: it was a bug towards rar package only
<xnox> maxiaojun: in that case, you should have nominated the bug for series where it's still a problem and follow the StableReleaseUpdates procedure. Do you know about Stable Release Updates?
<maxiaojun> i should have asked and may be someone told me that the best i can get is back port
<xnox> maxiaojun: #ubuntu-bugs are usually helpful when "i know where/what needs to be fixed, but not sure how to properly triage/request that"
<xnox> maxiaojun: load up bug #776851 again
<ubottu> bug 776851 in rar (Ubuntu Quantal) "Please backport rar 2:4.2.0-0ubuntu1 from raring" [Undecided,Incomplete] https://launchpad.net/bugs/776851
<xnox> maxiaojun: I've nominated it for Precise & Quantal with status incomplete, and set it to fix released (aka raring and up are fine)
<xnox> maxiaojun: I've also added a comment about stable release updates.
<xnox> maxiaojun: if you can provide information as per template "https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template" that would be a great help.
<maxiaojun> the problem is very very clear
<xnox> focus on test-cases and regression testing, e.g. sample test files that used to fail and now pass, and regular files that worked before and not after.
<xnox> maxiaojun: it is not to me. It should be made clear to those who don't use that package, developers and "Ubuntu Stable Release Team" who ultimately decide if an update goes in.
<xnox> maxiaojun: by default we do not update package in stable releases, and only release targetted bugfixes.
<maxiaojun> haven't you seen all the previous user comments?
<xnox> maxiaojun: sure, but somebody neeeds to summarise what a problem is, steps to re-create reproduce, and assess regression potential.
<maxiaojun> *any* rar file with non-ascii filenames in it is a test case
<xnox> maxiaojun: well then write that up. using https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
<maxiaojun> yes, rar 4.20 is very likely to break rar 4.0 beta 3
<maxiaojun> because old bugs cannot be reproduced
<xnox> maxiaojun: without those steps done, it will not be uploaded / accepted into stable updates channels for precise/raring.
<xnox> maxiaojun: did command line options changes? are all/same binaries present? did it gain extra dependencies? or loose some?
<maxiaojun> none
<xnox> maxiaojun: if you don't want to work on getting a Stable Release Update out for rar, that's ok. But _I'm_ not going to do it. Hopefully somebody else well.
<xnox> s/well/will.
<maxiaojun> i appreciate your wild imagination
<maxiaojun> https://bugs.launchpad.net/ubuntu/+source/rar/+bug/731066
<ubottu> Ubuntu bug 731066 in rar (Ubuntu) "[needs packaging] New upstream stable release available: RAR 4.20" [Wishlist,Fix released]
<maxiaojun> asked about SRU before
<maxiaojun> but as bugs being marked "fixed", it is a bit hard to find them out
<xnox> maxiaojun: now it's on https://bugs.launchpad.net/ubuntu/quantal and https://bugs.launchpad.net/ubuntu/precise pages
<xnox> maxiaojun: bug needs to be nominated to the series where it's still a bug, if it's significant enough to warrant an SRU, and if someone is working on getting it out.
<maxiaojun> but a normal use cannot request for nomination
<maxiaojun> during the raring cycle the culture was a bit different, as 9-month-support (useless support) isn't decided yet
<maxiaojun> xnox: do you think i should still try sru request?
<xnox> maxiaojun: i believe anyone can request to nominate. and then it will be pending to be "accept/decline" nomination. which developers regularly go through.
<maxiaojun> xnox: not the case
<xnox> maxiaojun: or ping people on #Ubuntu-bugs to get bugs nominated.
<maxiaojun> that's time-consuming
<xnox> maxiaojun: i filed the sru request for you, based on your request. (nominated bug for the right series)
<maxiaojun> thank you! where?
<xnox> maxiaojun: if you fill out the template, then it will move to confirmed state. After that and update needs to be prepared (should be easy, since it's basically package version tweak) and then a sponsor will need to upload it.
<xnox> maxiaojun: bug, same one. I've updated it to be nominated for series. <xnox> maxiaojun: load up bug #776851 again
<ubottu> bug 776851 in rar (Ubuntu Quantal) "Please backport rar 2:4.2.0-0ubuntu1 from raring" [Undecided,Incomplete] https://launchpad.net/bugs/776851
<xnox> clcik on it.
<maxiaojun> done
<pitti> tseliot: FYI, https://jenkins.qa.ubuntu.com/job/trusty-adt-ubuntu-drivers-common/9/ARCH=amd64,label=adt/ is a current run, and has .crash files for the DKMS failures, and the logs (which now succeed for all packages except said two)
<tseliot> pitti: thanks. I have fixed nvidia locally and now I'm working on the other package
<pitti> tseliot: sweet, thanks
<psusi> does anyone know what happened to the /etc/mtab -> /proc/mounts transition?  I thoguht we supposedly had done that for new installs a release or two back, but it doesn't seem to be the case.  What component is responsible for creating /etc/mtab ( dpkg says not owned by anyone )?  Is it d-i?  ubiquity?
<maxiaojun> xnox: don't how to do the version change in debdiff, and debdiff seems a little useless here as some files are binary only
<xnox> maxiaojun: debdiff against raring package.... it will have correct version for the SRU, target release, changelog entry with bug closure (LP: #NNNYNNN)
<xnox> something that a sponsor can apply against raring package, such that it's appropriately ready to be uploaded into "precise" and "quantal" series.
<maxiaojun> "it will have" means i don't need to do anything special?
<maxiaojun> as this package packages binary-only software, debdiff just captures some doc change actually
<xnox> yes. it's packaging metadata change.
<xnox> (the debian/changelog needs updating)
<xnox> $ pull-lp-source rar raring
<xnox> $ cd rar-*
<xnox> $ dch -i
<xnox> and then correct the entry: 1) target series 2) version number 3) entry text 4) bug number closure.
<xnox> build the source package with $ debuild -S
<xnox> and do a debdiff between raring version and the new one with $ debdiff
<xnox> rince, repeat twice - once for precise and once for quantal.
<chiluk> so I'm trying to sru a fix for bip in precise, and it's currently versioned 0.8.8-1build1   what is the correct way to increment that build number?
<xnox> chiluk: 0.8.8-1build1.1   or 0.8.8-1ubuntu0.1
<xnox> chiluk: note that u > b =)
<chiluk> yeah...
 * xnox preffers 0.8.8-1ubuntu0.1, but either is valid
<xnox> chiluk: the only hard-rule is that it needs to be >> then precise but << than quantal (or any possible SRUs / Security versions there)
<xnox> s/then/than/
<xnox> and there in infinite amount of versions between 0.8.8-1build1 and 0.8.8-2 =)
<xnox> chiluk: for luci-updates they used 0.8.2-1squeeze4build0.10.04.1
<xnox> which looks a bit odd =) but well, it works.
<chiluk> xnox well in this case I'm backporting the only change from quantal back into precise.
<maxiaojun> xnox: debdiff done, are they what you expected to see?
<xnox> maxiaojun: yes, looks good. Subscribing ubuntu-sponsors.
<xnox> maxiaojun: a few request piled up in the sponsoring queue at the moment. http://reqorts.qa.ubuntu.com/reports/sponsoring/ but very soon one of the patch pilots will review your debdiffs and/or comment with reviews or uploads it for Ubuntu Stable Release team to review.
<xnox> maxiaojun: thanks a lot for your work! =) everything is done now, just wait for a sponsoring
<xnox> your bug will appear on the report, next time it refreshes.
<maxiaojun> thank you for your helps also!
<xnox> maxiaojun: no problem =)
<mapreri> Do you now if someone (doko?) will take care if pushing automake 1.14 in trusty? (ref: http://packages.qa.debian.org/a/automake-1.14.html   and bug # 1191959)
<mapreri> of*
<xnox> mapreri: i'm working on it. but got sidetracked.
<xnox> mapreri: i am aware of that bug and fix/patch.
<xnox> mapreri: i still need to run full autopackage test.
<xnox> I will send an email about it to ubuntu-devel and I hope to get automake 1.14 in, before the first full-archive trusty rebuild.
<mapreri> xnox: great! I'm waiting for it :). Yesterday I was working on merging lighttpd, and it complains about the lack of automake 1.14, and I don't want at all to patch it to work with 1.13 :p
<xnox> mapreri: just wait, or upload it with "Build-depends: automake (>= 1.14)" or whatever the proper epoch:version is. It will go into dep-wait state and will be built once the new automake is in.
<cjwatson> It's also not terrible to just let it FTBFS until automake 1.14 is in
<mapreri> xnox: cjohnston  I prefer waiting... I definitely prefer performing a local build before uploading something
<slangasek> cjohnston: do we have an autoscheduler for this vUDS?
<cjohnston> slangasek: nope
<cjohnston> well, shouldnt
<cjohnston> doesn't appear as though we do
<cjwatson> FYI: publisher down pending investigation of I/O errors
<slangasek> cjohnston: what do you mean, "shouldn't"?  So the track leads need to schedule everything by hand
<slangasek> ?
<cjohnston> slangasek: correct... no auto scheduler... leads need to manually schedule things
<slangasek> cjohnston: and who decided that this was a good idea?
<cjohnston> slangasek: this was based on complaints from track leads
<cjohnston> been this way for atleast all of the vUDS events IIRC
<slangasek> cjohnston: ok, but who made this decision?  I am a track lead, and have *never* complained about the presence of the autoscheduler.  I also haven't been manually scheduling sessions for vUDS, which means someone else must have been doing it for the foundations track
<slangasek> so if someone else is going to manually schedule the sessions, then I suppose I don't need to worry about it; but so far no one has done this for our blueprints this round
<slangasek> and if no one else is doing this, then I will complain - loudly - about the busywork involved in manually scheduling these sessions
<cjohnston> mhall119: do you have any more backstory on ^
<mhall119> I don't know who made the original decision not to use autoscheduling, bit cjohnston is correct that it was never used for vUDS
<mhall119> I think, because track leads have to start every session's Hangout, we wanted to make sure they were scheduled according to the track lead's needs
<knocte> hallo, how many Approve votes must a merge-request receive to be merged?
<infinity> knocte: It's not about voting, it's about someone who can actually merge it being the approver.
<infinity> (Can, and is willing to)
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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: infinity
<infinity> knocte: Which MP is this?
<knocte> infinity: https://code.launchpad.net/~knocte/ubuntu-themes/cleanup-empty-rules/+merge/192903
<infinity> Ahh, I won't touch that with a 20-foot pole, my knowledge of GTK themes isn't deep enough, but I'll see if it can get reviewed by someone who can merge it.
<knocte> infinity: it doesn't require gtk superpowers really, just CSS knowledge to know that the patch brings sanity :)
<knocte> s/CSS/basic CSS/
<infinity> knocte: Well, see.  I know CSS well enough from, like, 1999, but I don't know if GTK's CSS relies on empty classes to work around quirks, or if the ubuntu themes themselves might, or whatever.  So, I'd rather have someone more knowledgable sort it out and commit to the upstream branch.  I've pinged someone to that end.
<knocte> infinity: ok thanks; and to the best of my knowledge, gtk's CSS works (or should work, if it doesn't "file a bug") in the same way as normal CSS so I don't think there would be quirks or similar hacks
<hallyn_> tjaalton: hey - so looking at https://launchpad.net/ubuntu/+source/xserver-xorg-video-qxl/0.1.1-0ubuntu1 - do you think it's worth just trying rebuilds?
<hallyn_> it looks like libxext-dev didn't get installed
<hallyn_> I can dig, but don't know the dependencies in the X cruft very well
<hallyn_> hm, looks like xserver-xorg-video-qxl should perhaps be build-depping on it
<mdeslaur> xnox: looks like you dropped some changes in thin-client-config-agent that caused LP: #1187450
<ubottu> Launchpad bug 1187450 in thin-client-config-agent (Ubuntu) "Depends on python3-pycurl" [Undecided,Confirmed] https://launchpad.net/bugs/1187450
<stgraber> utlemming: upload rights granted, you're all set
<utlemming> stgraber: awesome, thank you sir
<xnox> mdeslaur: =/
<xnox> mdeslaur: assigned to myself & scheduled SRUs.
<mdeslaur> xnox: not sure if it's worth sruing, honestly
<xnox> mdeslaur: well if remote login is broke, that's kind of important =/
<mdeslaur> xnox: ok
<mdeslaur> xnox: thanks
<infinity> hallyn_: You have any qemu days coming up in your schedule?
<infinity> hallyn_: https://wiki.debian.org/Arm64Qemu <-- Do want in Ubuntu.  And vagrant and co would happily take a sane patch for it in Debian too, from what he told me in #debian-arm
<psusi> cjwatson: grub-install takes the GRUB_DISTRIBUTOR and truncates it at the first space and converts it to lower case for use as the efi bootloader_id... why is this?
<hallyn_> infinity: i'll take a look this week.  I'm less than thrilled that it's a whole separate tree, but maybe it only has a few cleanly cherrypickable patches
<hallyn_> (i'll check the m-l for past submissions too)
<hallyn_> (hopefully tomorrow)
<infinity> hallyn_: They're in the process of upstreaming it with a target of (I believe) 1.8, but pulling in a patch for 1.6 would be nice.
<infinity> hallyn_: I haven't looked, but I'm hoping/assuming it's fairly self-contained.
<hallyn_> yup will give the backport a shot
<hallyn_> tjaalton: xserver-xorg-video-qxl built fine for my in chroot on porter-armhf.  can you just add libxext-dev to build-deps?  (I don't have upload rights)
<infinity> What.  The.  Eff.
<infinity> Alt-Right and Alt-Left have started swapping me between VCs.
<infinity> This is seriously messing with my head, since that's also how I move between irssi windows.
<psusi> infinity: did you hit sysrq-e?
<infinity> Oh, I bet this is a consequence of running console-setup under my X session while fiddling with a chroot.
<infinity> psusi: Definitely not. :)
<infinity> This is remarkably jarring, though.
<infinity> And Alt-F1 works from my X session without the need for the usual Ctrl modifier now.
<infinity> Head explodey.
<stgraber> infinity: that's fairly easy to fix, let me try to remember how
<infinity> stgraber: I was thinking "toss hands in air; reboot".
<infinity> And was already closing terminals to that end. :P
<stgraber> kbd_mode can fix it for you
<infinity> Probably.  But I only reboot my laptop once a month anyway, it's due.
<stgraber> infinity: sudo kbd_mode -s
<infinity> stgraber: That did indeed fix it, though.  Thanks.  I'll try to remember that the next time I do this to myself.
<infinity> (And now I'll reboot anyway, cause I like to see what explodes when I do)
<infinity> Which reminds me...
<infinity> Whose baby is the "waiting 300 minutes for your network configuration to happen" upstart job?
<infinity> stgraber, slangasek: ?
<slangasek> infinity: yes
<stgraber> not mine, though usually when it happens it's my fault somehow ;)
<slangasek> infinity: if you're actually waiting 300 seconds for your network configuration, it's because your network is misconfigured :P
<infinity> Every time I accidentally leave eth0 in auto and then do something silly like reboot in an airport lounge, I have a sad.  That could really do with an "I don't care, skip it" key, like fsck has.
<stgraber> (since it should never appear if ifupdown/NM do their job)
<infinity> slangasek: Yes, it's absolutely because I left something on auto and don't have a cable in.  Not arguing otherwise. :)
<infinity> slangasek: The "I don't care" key would still be nice, for idiots like me, and also for people who actually have a broken network and would like to get to the OS in a timely fashion to debug it.
<infinity> Currently, I swear I can hear a tiny whip cracking and cackling in the distance while it says "your network is still broken, I shall punish you for another minute.  hold please."
<slangasek> infinity: ah, hmm.  well, that would take some rejiggering of /etc/init/failsafe.conf to give it a way to listen for a key asynchronously
<infinity> slangasek: Want a wishlist bug?
<infinity> slangasek: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1247963
<ubottu> Ubuntu bug 1247963 in upstart (Ubuntu) "Would be nice to be able to cancel the wait for network configuation in failsafe.conf" [Wishlist,New]
<stgraber> I'm not sure how the user interaction works within plymouth, but from an upstart point of view, we could do it by having failsafe.conf do "start failsafe-keypress &" with that job waiting for a keypress from plymouth and if it matches whatever we're looking for, emit static-network-up which will get failsafe.conf to exit and the boot to continue
<xnox> stgraber: we are already watching for some keypresses and emit events for those. E.g. "control-alt-delete" =) we could overload that job, to try emitting static-network-up ;-)
<stgraber> well, in this case, I think it'd be much cleaner to get plymouth to forward the keypress (same thing as we do with mountall) than have upstart watch another obscure key combination :)
<jtaylor> can one fix gdb for python3 in saucy without recompiling gdb against python2?
<slangasek> infinity: wishlist bug> well, that's not likely to be fixed unless you work on it, fwiw
<RAOF> jtaylor: Yeah, mostly. You can run 2to3 on the gdb hook, and that worksish.
<jtaylor> unfortunately not
<jtaylor> that fixes the error in starting gdb
<jtaylor> but the python plugins are still broken
<jtaylor> I recompiled with py2 now, easier than figuring out how the plugins work :/
<slangasek> mmm? are you working on porting gdb's python support to py3?
<jtaylor> no trying to debug python extension code
<slangasek> ah
<jtaylor> may I ask why gdb was changed? its not seeded
<jtaylor> oh it is
<slangasek> right, gdb is certainly in main at the very least :)
<jtaylor> everything in main must now be python3?
<slangasek> well, "must"
<slangasek> we are in the process of deprecating python2 from main and have been for a couple of years already
<slangasek> but it hasn't been the easiest transition in the wolrd
<jtaylor> yes but gdb wasn't really ready for py3 yet
<jtaylor> the python plugins are incredibly useful
<slangasek> according to the changelog the change to support it was made upstream
<slangasek> are the plugins part of the gdb source or from somewhere else?
<jtaylor> I think they are part of python
<slangasek> e.g.?
<jtaylor>  /usr/lib/debug/usr/bin/python2.7-dbg-gdb.py
<slangasek> the equivalent scripts seem to exist in the python3.3-dbg package
<jtaylor> tried those too, didn't really work
<jtaylor> I didn't look into it much, just tried 2to3 and the python3 file, then I recompiled gdb
<slangasek> I'm not familiar with how these are used, how can I reproduce the problem you're seeing (so I can help make sure it gets fixed)?
<jtaylor> just needed to debug something rather quickly
<jtaylor> if you start gdb you get a syntax error, and if the plugins are working you get nice python object resolving, e.g. http://paste.ubuntu.com/6361710/
<slangasek> if you start gdb how?
<slangasek> when I run 'gdb' I get no such error
<jtaylor> hm I get it everytime, do you have python-dbg installed?
<slangasek> no - you mean installing python3.3-dbg, and running 'gdb' with no target, is sufficient to reproduce the problem?
<jtaylor> let me just revert my gdb
<jtaylor> ah no you have to debug python
<slangasek> ok
<jtaylor> http://paste.ubuntu.com/6361721/
<jtaylor> hm there is bug 1241668
<ubottu> bug 1241668 in python3.3 (Ubuntu Saucy) "gdb embeds python3.3, but support scripts are not compatible" [Medium,Triaged] https://launchpad.net/bugs/1241668
<jtaylor> the upstream patch does not work :/
<jtaylor> like 2to3 it just fixes the syntax errors but not the functionlity
<slangasek> right, it seems like even /usr/lib/debug/usr/bin/python3.3dm-gdb.py is a python2 script, not a python3 script... I guess nobody was able to test this until recently because gdm didn't support python3
<slangasek> er, gdb
<slangasek> jtaylor: so, how would I test the functionality?  2to3 lets me run gdb, and I can set a breakpoint on a C function but don't know how to use this to set a breakpoint on a python function
<xnox> (there were bugs with it, but i thought is or in-process of being fixed and uploaded)
<xnox> third party plugins non-with-standing...
<jtaylor> slangasek: break e.g. in PyTuple_Size
<slangasek> Python Exception <class 'AttributeError'> 'PyDictObjectPtr' object has no attribute 'items':
<jtaylor> the frame should show the content of the tuple if the plugin works
<slangasek> I guess that's the issue?
<jtaylor> yes
<slangasek> righto
<jtaylor> one of them, depending on what feature is used you get different errors
<jtaylor> upstream issue is http://bugs.python.org/issue19308
<jtaylor> the patch there does not seem to work (commented on it)
<barry> oh my, look at all the python going on here
<StevenK> barry: O HAI. If you have a second, care to weigh in on https://bugs.launchpad.net/launchpad/+bug/1050173 ?
<ubottu> Ubuntu bug 1050173 in Launchpad itself "bugwatches set to accepted closed in python.org roundup maps to 'fix committed' not 'fix released'" [High,Triaged]
<slangasek> fwiw that looks suspiciously like a bug in the gdb support, to me... why does it want 'items' instead of 'iteritems' (the function that's provided by the class in this script, even for python2)?
#ubuntu-devel 2013-11-05
<jtaylor> hm I seem to have applied the patches wrongly
<jtaylor> the upstream patches do work error less, but the py3 output is less useful
<jtaylor> yup, just be being dumb again, the upstream patches work for me
<jtaylor> slangasek: ^
<jtaylor> < goes to bed, bye
<barry> StevenK: fix committed sounds right-ish at least, since python's roundup doesn't really have a fix released status, and nothing's really fix released until the next python (patch) version, which isn't tracked in round up.
<StevenK> barry: Do you want to add that to the bug and change the status as you see fit, then?
<barry> StevenK: i just added a comment. let's see if lifeless responds before setting status
<StevenK> barry: Thanks
<lifeless> barry: url ?
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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:
<slangasek> cjohnston, mhall119: do you have any idea why there are duplicate sessions for a blueprint, and can you tell me how to get rid of one of them? http://summit.ubuntu.com/uds-1311/meeting/22028/core-1311-dmraid2mdadm/ http://summit.ubuntu.com/uds-1311/meeting/22017/transitioning-to-use-mdadm-by-default-for-some-of-the-fakeraid-devices/
<pitti> Good morning
<rbasak> infinity: I'm not sure how to test libapache2-mod-svn without also relying on svnadmin and svn to work :)
<infinity> rbasak: Heh.  Well, I like it anyway.  It's the complete opposite of unit testing, but the build-time tests do a fair job of that.  Your test is a great one-shot "yeahp, pretty much the whole package still works when installed".
<rbasak> A happy coincidence :)
 * infinity curses firebird, which appears to hate him on arm64.
 * rbasak appreciates the praise. Thank you!
<pitti> infinity: would you mind adding a "bad test" override for debtags? someone added an XS-Testsuite: without actually having tests; I removed the jobs from jenkins, but britney still thinks it's "failed"
<infinity> pitti: Sure, if it's removed and won't have a sad next time.
<pitti> infinity: no, the override can go again once it propagated
<pitti> infinity: I would just have updated the autopkgtest status file, if I could remember to which host britney moved to :)
<infinity> pitti: Done.
<pitti> infinity: cheers
<infinity> pitti: And nakefruit.
<infinity> snakefruit, too.
<infinity> The first barrier of entry is deciphering my typos.
<pitti> ah, thanks
 * infinity decides he cares a lot less about porting firebird2.5 to arm64 than he did an hour ago and finds something less stupid to do.
<tseliot> pitti: https://jenkins.qa.ubuntu.com/job/trusty-adt-ubuntu-drivers-common/10/ :)
<pitti> tseliot: indeed, thanks for fixing!
<tseliot> :)
<tseliot> pitti: oh, BTW, where do you suggest that I file a bug report on the python gtk (gir) bindings?
<pitti> tseliot: that'd be gtk+3.0
<tseliot> pitti: yes, the 3.0 ones
<tseliot> pitti: or do you mean that I should file the report against the source of gtk+3.0?
<pitti> tseliot: right, as that builds the Gtk GIR bindings
<tseliot> pitti: ok, thanks
<seb128> cjwatson, hey, how do you determine if config.guess/sub have support for arm64?
<pitti> seb128: check if config.guess contains "aarch64"
<pitti> "aarch64:Linux:" more specifically
<seb128> pitti, danke
<seb128> cjwatson, I'm syncing libisoburn (it's on your merge list, the only diff was running dh-autoreconf to have an updated config.guess/sub for arm64, the new version is Debian has those recent enough)
<xnox> slangasek: hm, i filed a blueprint _and_ did the propose a session "simple form" on summit.u.c. So the earlier "manual" one needs killing, i.e. kill http://summit.ubuntu.com/uds-1311/meeting/22017/transitioning-to-use-mdadm-by-default-for-some-of-the-fakeraid-devices/
<xnox> cjohnston: ^
<seb128> cjwatson, doh, ignore that, we already have the new version in trusty-proposed it seems (I didn't have proposed enabled)
<seb128> cjwatson, well, I updated libisofs which unblocked the depwait at least :p
<seb128> pitti, thanks CurrentDesktop btw ;-) oh, and hey ;-)
<cjwatson> seb128: grep aarch64 config.{guess,sub}
<cjwatson> oh, pitti got there
<seb128> cjwatson, thanks ... yes ;-)
<cjwatson> seb128: right, I was assuming you'd get to libisofs :)
<cjwatson> I went through the same sync decision last week
<pitti> seb128: Ã§a va :)
<seb128> cjwatson, ;-)
<pitti> seb128: rmadison FTW!
<seb128> cjwatson, did you have a good trip back btw?
<seb128> pitti, indeed
<pitti> since the archive stuff moved to a new server, rmadison is actually usable again
<cjwatson> meh, as good as you can get for that duration :)
<cjwatson> slept a bit and the plane didn't crash
<cjwatson> I've been vaguely meaning to have merges.u.c look at both trusty and trusty-proposed so that we don't have this duplicate-work window
<xnox> ev: can you make me an admin of https://launchpad.net/~timezonemap-team ?
 * Laney sniggers
<ev> xnox: done
<xnox> Laney: I think you are now the highest contributor to timezonemap. And as the one who touch it last, you are now the maintainer ;-)
<Laney> Someone must have witten all the existing code :-)
<Laney> anyway, review iz good
<xnox> Laney: well ev copycatted some of it, then passed the maintainance baton to me, and now it's you =) it's a desktop component anyway ;-)
<Laney> but ta
<sladen> xnox: ev: talking of which, did the original 2.7MB 'tz_map.svgz' get included?
<Laney> haha, it's both desktop & installer
<xnox> sladen: i have it in an email somewhere. Let me check.
<Laney> destroy the silo
<sladen> xnox: ev: it was PD derived from a CIA map (confirmed by kwwii), and sabdfl okay'ed shipping it (based on the CIA's PD statement)
<sladen> xnox: if so, you can probably finally close off bug #651064
<ubottu> bug 651064 in ubiquity (Ubuntu) "Missing pixmap for Australia/Eucla timezone" [Medium,In progress] https://launchpad.net/bugs/651064
<xnox> sladen: pushed.
<Laney> phwoar
<Laney> that calls for a release
<Laney> xnox: do you need to make it use that somehow?
<xnox> sladen: well I committed the original .svg into timezonempa, but I don't know how to render the timezone pixmap.
<Laney> also, didn't put it in src/data?
<Laney> which already has some countryInfo1.svg thing
<xnox> Laney: oh.
<Laney> yeah I guess there is something more to be done here
<xnox> sladen: if you can update the rendered.pngs that would help the original svg and rendered.pngs are in src/data in lp:timezonemap
<xnox> sladen: similarly russia has moved one timezone to the right across the board, so I general refresh of timezones rendered pngs would be nice.
<brainwash> is this behavior intended? bug 1248137
<ubottu> bug 1248137 in xfce4-session (Ubuntu) "logout does not remove logind session" [Undecided,New] https://launchpad.net/bugs/1248137
<brainwash> I read about this issue some time ago in this channel, some processes still remain alive after session logout
<brainwash> upstart?
<pitti> we didn't enable logind's option to kill all remaining processes after logout, mostly for safety
<pitti> (as it would make it impossible to leave stuff running in the background deliberately)
<pitti> brainwash: check "ps aux | grep <username>" after logout for leftovers?
<brainwash> pitti: it's not my report, but I'll try to confirm it
<brainwash> pitti: did you already take a look at the new dbus-monitor logs which got added to the logind suspend/resume report?
<pitti> not yet, no
<brainwash> this issue is causing way too trouble, we need to fix it asap :)
<brainwash> because most users are forced to reboot their system, if they are not aware of any workaround
<pitti> yeah, I know; I need to grab desrt, but I didn't reach him yesterday
<seb128> pitti, he might not be back before a few days, he was taking some swap days for thanksgiving and travelling
<pitti> seb128: ah, thanks for letting me know
<seb128> pitti, yw
<mati75> hello, I'm looking for sponsor this package: https://launchpad.net/~mati75/+archive/lubuntu/+sourcepub/3642755/+listing-archive-extra
<tseliot> pitti: shall I also file bug 1248152 upstream?
<ubottu> bug 1248152 in Ubuntu "Gtk.FileChooserWidget won't show the "create folder" button" [Medium,Confirmed] https://launchpad.net/bugs/1248152
<pitti> tseliot: sorry, back from lunch
<pitti> tseliot: followed up to the bug
<tseliot> pitti: ah, thanks. Is the .new() method documented somewhere?
<tseliot> pitti: as in when to use it
<tseliot> pitti: as opposed to simply calling ClassName()
<pitti> tseliot: it's rather that *not* using the _new() method isn't documented well
<pitti> https://wiki.gnome.org/PyGObject/IntrospectionPorting#Constructors
<pitti> tseliot: so, ^ usually you have the choice between a class' constructor (often there are several ones, like gtk_button_new_with_label), or a GObject constructor which you pass initial properties
<pitti> and usually a class constructor should do nothing else than setting the properties from its arguments, but some classes violate that (like GtkFileChooserWidget)
<pitti> in that case you have to use the real constructor
<tseliot> pitti: so there's no way to know for sure until you try?
<pitti> tseliot: calling the class constructor should always work
<pitti> tseliot: calling the GObject constructor should work in most cases these days, but it seems you found a case where it doesn't
<pitti> that part is worth a bugzilla report as it will also break e. g. loading from a GtkBuilder file
<tseliot> pitti: are you going to file it yourself or shall I? (you definitely have more context to do it)
<pitti> tseliot: so Gtk.FileChooserWidget(self, Gtk.FileChooserAction.SELECT_FOLDER) does not make any sense at all (both the self, and the positional flag argument), I'm currently checking why it doesn't raise an exception
<pitti> tseliot: I can file it if you want
<tseliot> pitti: yes please
<pitti> tseliot: filed upstream bug for pygobject and linked to the LP bug
<tseliot> pitti: great, thanks!
<mhall119> slangasek: was one of them entered manually into summit
<mhall119> ?
<mhall119> slangasek: or was an old BP removed from Launchpad?
 * mhall119 blames xnox either way
<xnox> mhall119: yes, i manually entered into summit.
<xnox> mhall119: do you have powers to delete the manual one?
<mhall119> yes I do
<mhall119> xnox: slangasek: done
<xnox> mhall119: delete this one - http://summit.ubuntu.com/uds-1311/meeting/22017/transitioning-to-use-mdadm-by-default-for-some-of-the-fakeraid-devices/
<xnox> mhall119: \o/ thanks.
<pitti> cjwatson: OOI, why is dell-recovery on http://people.canonical.com/~ubuntu-archive/transitions/html/hal.html ?
<pitti> cjwatson: it has Depends: udisks | devicekit-disks | hal (of course all of these are obsolete, but it shouldn't really pull in hal)
<pitti> i. e. is that just a bug with alternative dependencies, or shouldn't hal be in the transition tracker in the first place?
<cjwatson> pitti: *shrug* the config has .depends ~ /hal/
<cjwatson> sorry, rather: .depends ~ /(^| )hal([ ,]|$)/
<xnox> pitti: well the stanza for bad is ".depends ~ /(^| )hal([ ,]|$)/ " which is don't specify alternate "hal" dep.
<xnox> snap.
<cjwatson> pitti: you could just ignore it :)
<cjwatson> I see dff still Recommends: hal
<brainwash> the pulseaudio user process keeps the logind session alive after session logout, is this a known issue? I recall reading about this some time ago in this channel
<brainwash> bug 1248137
<ubottu> bug 1248137 in xfce4-session (Ubuntu) "logout does not remove logind session" [Undecided,Invalid] https://launchpad.net/bugs/1248137
<tseliot> stgraber: why did you reject nvidia-prime for precise-proposed?
<stgraber> tseliot: what? The only nvidia-prime related stuff I did today was release two SRUs into -updates, didn't do any rejecting
<tseliot> stgraber: Rejected: nvidia-prime 0.4.2~hybrid0.0.1 in precise (source has no binaries to be copied)
<stgraber> oh, that's LP, not me :)
<stgraber> let me try and see what happened there
<stgraber> tseliot: doh, I know what's going on, let me try to sort it out
<tseliot> stgraber: thanks
<stgraber> tseliot: basically it's one of those packages that got introduced post-release, so the binaries end up in New every time. Apparently nobody processed that one for some reason, so the testers grabbed the binaries straight from the librarian and the copy failed since the binaries weren't actually in -proposed
<stgraber> tseliot: I just accepted the binaries into -proposed now and will retry a copy once that's published
<tseliot> stgraber: oh, I see. Thanks for your help
<tseliot> stgraber: also can you have a look at bug 1246735 when you have the time, please?
<ubottu> bug 1246735 in nvidia-graphics-drivers-319 (Ubuntu) "Package nvidia-persistenced" [Medium,In progress] https://launchpad.net/bugs/1246735
<davmor2> tseliot: oooooohhh
<tseliot> davmor2: yep :)
<slangasek> mhall119: ta
<barry> mitya57: hi :)
<mitya57> hi barry!
<mitya57> Actually I may leave soon, so if you have something long, please send mails insteadâ¦
<barry> mitya57: thanks for helping out with coverage :)  i'd like to see how ben responds before we do the merge.  otoh, i suppose we can merge now and resync later based on his responses
<barry> mitya57: naw, we can use email.  just wanted to say hey
<mitya57> Yes, and if we don't merge now we can include the fix for debug packages when it's ready
<barry> mitya57: yep
<seb128> slangasek, what do you mean by "The GNOME stack should be handling the suspend suppression"?
<slangasek> seb128: it's GNOME components that are responsible both for the reboot signal and the suspend trigger
<slangasek> upstart has nothing to do with this
<seb128> slangasek, do you call logind "GNOME components"?
<slangasek> seb128: ah, is this not handled on the gnome-settings-daemon side?
<slangasek> do we signal logind directly to request a reboot?
<seb128> slangasek, that bug happens if you close your lid during shutdown, at a time where there is no session open
<seb128> slangasek, e.g if you close the lid on the plymonth shutdown screen
<seb128> slangasek, I'm not sure how a GNOME component could be still holding an inhibitor at this time
<slangasek> seb128: ah, ok; I understood it as "close lid during shutdown while the session is still open but shutdown has been requested"
<slangasek> if it's after the session has exited, then yeah, that's obviously a logind bug, so feel free to reassign
<seb128> slangasek, no, and I can confirm that bug, I've the plymonth logo displayed for 5-10s here, if I close the lid during that time it goes to suspend
<seb128> slangasek, doing that, thanks
<rbasak> What are we supposed to do for the Maintainer field for Ubuntu-only packages in universe for new packages? I've seen it be "Ubuntu Developers" and also an individual person. Are we supposed to use one or the other?
<xnox> rbasak: as long as it has "ubuntu.com" somewhere in the string it's fine. =)
<xnox> rbasak: if it's the typical one the devel-discus mailing list, it's fine. If you put your email in there, you'll get upload notifications for it even if somebody else does the upload.
<rbasak> xnox: thanks. I'm reviewing/sponsoring for someone else (@ubuntu.com), so just wanted to check that non devel-discuss was acceptable.
<xnox> rbasak: yeah, anything is ok.
<Laney> It doesn't mean they are the maintainer though
<mati75> I have question where I can find sponsor for Ubuntu patched package?
<TheLordOfTime> is someone here with permissions to approve a bug nomination for Saucy able to do so on https://bugs.launchpad.net/ubuntu/+source/nautilus-dropbox/+bug/1242413?
<ubottu> Ubuntu bug 1242413 in nautilus-dropbox (Ubuntu) "nautilus-dropbox needs a dependency on libappindicator1" [Undecided,In progress]
<TheLordOfTime> it was requested in -bugs to get it nominated and set accordingly for an SRU, with a claim that this is already fixed in Trusty
<ivanka> hi seb128 - you around?
<seb128> ivanka-train, hey, yes
<ivanka-train> seb128, How are you?
<seb128> ivanka-train, I'm good thanks! How are you?
 * ivanka-train has a question, of course
<seb128> ivanka-train, I was expecting so ;-)
<seb128> ivanka-train, let me guess, you upgraded to 13.10 and have an issue?
<ivanka-train> seb128, I am very well
<ivanka-train> seb128, you are so clever! :-)
<seb128> ;-)
<ivanka-train> seb128, my battery life has disappeared
 * xnox is intrigued
<seb128> ivanka-train, you mean the battery indicator?
<ivanka-train> ivanka-train, no, i mean that I have gone from having a couple of hours of battery life to 19 minutes
<ivanka-train> I mean seb128 ^
 * ivanka-train has started talking to herself now
<seb128> ivanka-train, is the estimation wrong or is your battery drained out like that?
<seb128> ivanka-train, what's your CPU usage in top/gnome-system-monitor?
<ivanka-train> seb128, it seems to get drained out
<seb128> ivanka-train, check the cpu usage, just in case something max it out
<ivanka-train> seb128, it looks like 10%
<seb128> ivanka-train, if not, I would tend to say your battery is having hardware issues
<seb128> ivanka-train, how old is the battery?
<ivanka-train> seb128, it is a couple of years old but it seems a weird coincidence that it dies all of a sudden, no?
<seb128> ivanka-train, you can click on the indicator -> battery line -> battery in the sidepane
<ivanka-train> seb128, hmm - it looks like the capacity is down to 8%...how annoying!
<ivanka-train> actually it is about to die now and I am on the train
<ivanka-train> seb128, I am going to drop off rudely
<seb128> ivanka-train, looks like an hardware issue, battery to get buggy like that
<ivanka-train> seb128, thanks for your help - I will check out a new battery and report back
<seb128> ivanka-train, the Ubuntu upgrade is probably a coincidence timing
<seb128> ivanka-train, good luck
<seb128> ivanka-train, have a nice evening!
<jtaylor> is it worth filing bugs for crashes when /tmp is not writable?
<ivanka-train> seb128, thank you!
<jtaylor> a collegue somehow made it read only and lots of unity related stuff just crashed
<jtaylor> e.g. unity-scope-loader, firefox due to the menu integration (probably) etc.
<seb128> jtaylor, not really worth it, code could handle a buggy system better (same as no space on disk) but in reality that's still a buggy system
<jtaylor> but I guess non writeable /tmp is unusual
<seb128> jtaylor, e.g you can file those but I expect they are not going to be ranked high on priority lists
<jtaylor>  /tmp is cleared on boot in ubuntu, shouldn't it also restore permissions on boot?
<xnox> ivanka-train: you can try this drain the battery until it will not turn on, leave it off and fully charge for e.g. 3 hours. Perform that 3 times. It should recover and make battery capacity increase.
<jtaylor> it was owned by some random user with 700
<seb128> xnox, you missed her it seems
<xnox> =(
<seb128> xnox, how much do you expect those charge cycles to change things?
<seb128> jtaylor, /etc/init/mounted-tmp.conf
<jtaylor> so thats no it should not reown the folder?
<seb128> jtaylor, I'm not sure what it's supposed to do, the upstart job reacts on tmp being "mounted" it seems ...
<seb128> jtaylor, I guess you need somebody from foundations to reply to that question, e.g maybe xnox knows ;-)
<jtaylor> so far I see the script will overlay a working tmp if its full, but not if the permissinos are wrong
<Serus> Hi
<Serus> Can I import a keyboard map from my raspberry pi? my current maps are a tiny little bit different from what I want
<sladen> Serus: what operating system are you running on the Raspberry Pi?
<Serus> raspbian
<sladen> Serus: if it is something Linuxy (very likely) then somewhere it will be using kernel and X keymaps, which is the same as Ubuntu (based on Debian) uses under the hood
<Serus> raspbian is also based on debian
<sladen> Serus: Raspbian is based on Debian too.  What is the keymaps you are wanting to import called?
<Serus> Dutch - US international
<Serus> the English (US) - US international behaves different
<Serus> for example I now do this when I try to type "I'm"
<Serus> IÂ´m
<Serus> Iá¸¿*
<Serus> Which is pretty annoying, since I switch between windows and ubuntu. And it's even more annoying when programming.
<sladen> Serus: in Ubuntu, open "system settings"; type 'keyboard', click 'Keyboard layout', click [+] (bottom left), type 'Dutch', select "Dutch US international" from the list (if it is there)
<Serus> It's not there.
<Serus> Running ubuntu 12.04
<Serus> Should I do a dist upgrade
<sladen> Serus: no, hold on
<Serus> Ok
<sladen> Serus: apologies, need to re-aquint myself with where keyboard layouts are kept
<Serus> /usr/share/
<Serus> /usr/share/X11/xkbd
<Serus> /usr/share/X11/xkbd/symbols *
<sladen> Serus: yes, thankyou.  They are from the 'xkb-data' package
<Serus> That one is installed
<sladen> Serus: dpkg -l xkb-data   on Raspbian, what version is shown?
<sladen> Serus: on ubuntu 12.04 LTS, you probably have 2.5-1ubuntu1.3?
<Serus> I need to setup my ssh server on the raspberry pi with a few new keys for ubuntu
<Serus> yes, thats the version I have on ubuntu
<Serus> If you give me a moment, I reboot into windows and see what version I have on the pi
<Serus> brb
<Serus> Ok I'm in windows now
<Serus> Only now my sound is gone O.o
<sladen> Serus: btw, you can copy your existing ssh private keys from the windows partition to ~/.ssh/
<sladen> Serus: in Ubuntu
<Serus> they are putty keys
<Serus> will they work?
<sladen> Serus: use puttygen to convert them to the standard format
<Serus> Export OpenSSH key right?
<sladen> Serus: if you're already back in Ubuntu;   sudo apt-get install putty   then run 'puttygen foo.ppk -O private-openssh -o foo_private
<Serus> I'm still in windows
<sladen> Serus: http://84kids.com/how-to-convert-your-putty-key-to-openssh-format/  this suggests that under MS Windows  puttygen is GUI, and that there is a Tools->Export OpenSSH key menu
<Serus> Yeah I did that
<Serus> Ok, I'll go back to ubuntu
<Serus> brb
<Serus> Ok I'm back
<sladen> Serus: any how; either manually copy+add your desired keyboard layout; or find a newer .deb containing the Dutch US int layout
<Serus> ok
<sladen> Serus: did you find out what version you had on the Pi?
<Serus> Yeah, I'll check it
<Serus> because I saw it on windows, but now I'll copy+paste it
<Serus> Ok I'm finally in
<Serus> ii  xkb-data       2.5.1-3      all          X Keyboard Extension (XKB) config
<Serus> that's the output on the raspberry pi
<sladen> Serus: is (on Rasbian), "Dutch US International" (exactly that string) available in the GUI
<sladen> Serus: I've installed a new xkb-data on an Ubuntu 12.04 LTS machine, and not (yet) made it come up
<Serus> not (yet) made it come up?
<sladen> Serus: I have not yet made "Dutch US International" appear as an available option in the keyboard configuration
<Serus> well Iá¸¿ used to selecting a language and then selecting a layout for that language.
<Serus> Which makes the layout behave slightly different.
<sladen> Serus: in the console?  Or the GUI?
<Serus> I used raspi-config from the console. But for some reason that won't work from ssh on ubuntu
<hallyn_> tjaalton: around?
<Serus> let me try via remote desktop
<sladen> Serus: do you mean "raspi-config" won't work over SSH;  or you make a selection but it doesn't make a difference over SSH?
<Serus> it won't work over ssh
<sladen> Serus: do you mean "raspi-config" won't work over SSH;  or you make a selection but it doesn't make a difference over SSH?
<Serus> I don't get to see the screen where I can select a keyboard layout
<sladen> Serus: if it is the first; what error does it show.  If it is the second, it is probably because the keyboard configuration is the one of the MS Windows/Ubuntu
<sladen> Serus: do you get the command prompt back?
<Serus> yes
<Serus> I get the message that it's loading keymaps
<Serus> and then it stopts
<sladen> Serus: are you running 'sudo raspi-config'  or just  'raspi-config'
<Serus> stops*
<Serus> sudo raspi-config
<tjaalton> hallyn_: sorry, forgot to check the fbtfs..
<tjaalton> ftbfs
<Serus> It also happens over RDP
<Serus> guess I'll reboot it
<hallyn_> tjaalton: near as I can tell it should just need libxext-dev in build-deps
<hallyn_> why it gets pulled in automatically on x86 i'm not sure
<Serus> Also it could've been loading the windows keymap
<tjaalton> hallyn_: ok, i'll investigate a bit and fix it, thanks for testing
<hallyn_> tjaalton: thanks.
<utlemming> is there a definitive place to look up info on cgroups? i.e. all the things that it can do?
<infinity> utlemming: Ask Lennart, obviously.  According to him, no one else understands them.
<infinity> (But, more seriously, stgraber and hallyn might be able to point you at some decent writeups/docs/whatever)
<infinity> stgraber: ^
<stgraber> ;)
<stgraber> utlemming: most documentation is in the kernel tree, there's typically a .txt file per controller listing all the keys and valid values
<stgraber> utlemming: https://www.kernel.org/doc/Documentation/cgroups/
<hallyn_> infinity: so fwiw the patchset applies cleanly on top of trusty's package.  I'm first going to build and test that with no aarch64 target actually enabled - though our testsuites don't do much if any lniux-user testing (hm).  then i'll enable the aarch64 arch and see how that goes
<hallyn_> (over next few days)
<infinity> hallyn_: Awesome, thanks.
<infinity> hallyn_: Bonus points if you push those changes to Debian too, so they don't have to do it all over again.
<infinity> hallyn_: (And so we agree on pathnames and such)
<hallyn_> infinity: yeah i'll talk to mjt after testing
<hallyn_> (now, off to dinner.)
#ubuntu-devel 2013-11-06
<leb> can anyone help with this?  https://gist.github.com/tildeleb/7329005 what is the issue with #include <fcntl.h>
<sarnold> leb: change linux/inotify.h  to sys/inotify.h
<xnox> snap.
<xnox> leb: yeah, what sarnold said.
<Serus> How can I see which graphics card ubuntu is using?
<xnox> Serus: top-right system cog -> about this computer
<xnox> Serus: should have a line "Graphics: "
 * xnox has IntelÂ® Ivybridge Mobile
<Serus> can't find the about this computer in the menu
<xnox> Serus: what ubuntu are you using?
<Serus> 12.04
<xnox> ah
<Serus> found it
<Serus> Graphics: Unknown
<xnox> Serus: lspci on cmdline might give you more info. Btw, this sounds more of a support question which are handled on #ubuntu
<Serus> #ubuntu is so full that many questions remain unseen
<brainwash> Serus: make sure that the package "mesa-utils" is installed
<infinity> That feature in the about box doesn't work in 12.04 without mea-utils being installed, if I recall.
<infinity> brainwash: Jinx. ;)
<brainwash> :D
<Serus> ok and then reboot or something?
<brainwash> does it still show "Unknown"?
<Serus> Ah it uses the geforce card now :D
<Serus> GeForce GT 630M/PCIe/SSE2
<Serus> should all the artifact in video be gone now?
<Serus> artifacts*
<Serus> nope still artifacts in video :/
<brainwash> the guys in #ubuntu might know an answer, this here is the channel for development talk and not general support :)
<Serus> ok
<Serus> well I'm going to sleep first
<brainwash> good night
<Serus> you too.
 * infinity glares at /etc/gnome/defaults.list conffile prompts.
<infinity> Oh, wait.  This is chrome's fault, I knew that already.
 * infinity glares at Google instead.
<mwhudson> heh
<Noskcaj-school> rsalveti: Can you look at the merge for elementary? I think it's a sync but it would be better if you check since you made the ubuntu delta
<rsalveti> Noskcaj-school: sure
<Noskcaj-school> thanks
<rsalveti> Noskcaj-school: the only difference are the additional dependencies to add support for efreet, eio and edbus
<Noskcaj-school> oh, so there is something
<rsalveti> I might just try to get that change in debian, and then we can sync
<rbasak> Oooh. I found a build that eatmydata actually causes to fail in sbuild.
<rbasak> (libvirt does some kind of fsync test that eatmydata breaks and causes a segfault)
<ScottK> cjwatson: Would it be possible to do a one time MoM run (or some equivalent to get the diffs) against experimental?  All the KDE packages we need to merge against for trusty are there and doing it just by hand would be less fun.
<pitti> Good morning
<Noskcaj> tjaalton, Can you try and merge sssd from debian?
<tjaalton> Noskcaj: i maintain both..
<Noskcaj> tjaalton, I know. In the case that someone else might have to work on either, would it not make it easier if it was merged when possible? Why isn't it already?
<tjaalton> iirc there isn't much to merge, and a new upstream release needs to be merged anyway
<ScottK> Noskcaj: For packages that are actively maintained (also like pyqt5), it's probably better to leave it to the people that are already focusing on it until later in the cycle.
<Noskcaj> ok
<seb128> stgraber, hey, could you have a look to bug #1244736?
<ubottu> bug 1244736 in gnome-session (Ubuntu) "upstart configuration for user launches an extra ssh-agent" [Undecided,New] https://launchpad.net/bugs/1244736
<tjaalton> Noskcaj: besides, we don't have the new samba in trusty yet, so a sync/merge wouldn't build without reverting the changes to build-deps
<tvoss_> xnox, ping
<tvoss_> cjwatson, I'm trying to mark some symbols as optional in a .symbols file, but cannot remember the syntax. Do you have a link to documentation handy?
<seb128> tvoss_, http://wiki.debian.org/UsingSymbolsFiles
<tvoss_> seb128, thx, http://manpages.ubuntu.com/manpages/lucid/man1/dpkg-gensymbols.1.html was the place to look at :) rtfm, that is ;)
<seb128> tvoss_, or see man dpkg-gensymbols
<seb128> tvoss_, ;-)
<xnox> ScottK: if you a smallish list of src-packages (e.g. in kubuntu seeds?!) i can run MoM against them for you. With added bonus of testing if my patches to diff against trusty-proposed work or not.
<xnox> ScottK: and i'll publish result on people or some such.
<pitti> xnox: as for your WI change on the logind BP: September is still in the past ;)
<pitti> xnox: oh, it's DONE now, ignore me
<xnox> pitti: yeah, i think it was september when I finally gave up on logind dbus api, and instead made ubiquity-dm actually create a PAM session and close it.
<pitti> xnox: ah, so much more robust :)
<Laney> wasn't that always the right way
<Laney> ?
<xnox> Laney: we ain't no need a PAM session, ubiquity-dm haz root.
<cjwatson> ScottK: remind me tomorrow?  I'm on holiday tomorrow and I suspect this is non-trivial.  (actually it would probably be easier to have a package list that gets overridden to be always merged from experimental for a while, or something)
<cjwatson> oh, xnox replied
<cjwatson> fine
<Laney> xnox: Well, other things can happen at session opening as you demonstrated by that fix
<xnox> Laney: well, my first try was mimicking pam_systemd.so with dbus calls, which only resulted in pam-session being opened & then logind giving a hizzy hit, assume that session is dead and close it straight after.
<Laney> ISTR the documentation saying "don't do this"
<xnox> Laney: and it's not really a generic PAM session, as I set logind private & undocumented & non-standard variables to create a "display-manager" logind session, which seems to be enough to please network-manager and friends.
<xnox> Laney: also "noone understands init/cgroups/linux but Lennart"
<xnox> Laney: I don't find "PAM" the best protocol / API at all =(
<Laney> oh well
<Laney> done now :P
<xnox> =)
<sil2100> pete-woods: hi!
<pete-woods> sil2100: hi
<sil2100> pete-woods: how familiar are you with camera-app and autopilot...? ;)
<pete-woods> sil2100: my familiarity is limited to knowing that the camera app autopilot tests are "somewhat unreliable"
<sil2100> pete-woods: ok, then maybe I'll wait for Bill to pop up as I see he made the most commits to camera-app
<sil2100> pete-woods: since we're getting test failures after the AP 1.4 switch
<pete-woods> sil2100: unfortunately all I've done with the camera app is patching in the infographics support
<tvoss_> doko, ping
<tvoss_> doko, I stumbled across some interesting behavior with symbol versioning for this mp: https://code.launchpad.net/~thomas-voss/dbus-cpp/refactoring/+merge/191369
<tvoss_> doko, two things: turns out that enabling coverage for gcc results in additional symbols being exported from a shared object. More to this, there are some arch dependent symbols exposed for std-library features that I would love to get rid of :)
<ScottK> xnox: Yes.  It's anything with an upstream version of 4:4.11.* (or seeded in Kubuntu, whichever is easier).
<xnox> ScottK: can you use something like dctrl-grep on a downloaded Sources file to generate a package list & check it's what you want? It should let you specify tag to grep for (e.g. Version) and tags to print (e.g. Package)
<xnox> (also it will let you grep task, etc)
<mitya57> ScottK: what do you think about bug 1243102? If we upload pyqwt5/pyqwt3d with good version numbers, we will be able to drop sip4 delta.
<ubottu> bug 1243102 in pyqwt5 (Ubuntu Trusty) "python-qwt5-qt4 segfaults immediately in saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1243102
<mitya57> (Some comment suggests that a rebuild solves the bug)
<ScottK> I'd update sip4 from Debian first so we don't end up rebuilding again, but that's a good ide.
<ScottK> idea even
<mitya57> Actually, we can even add an autopkgtest to make sure we never break these again
<mitya57> Re qtserialport build-wait, it's because our qtbase is still 5.0.2, but I think it can actually build with 5.0, will look now
<ScottK> OK.  I'm about to be offline for ~12 hours so good luck.
<caribou> xnox: I see that you marked the zsh package as "up for grab" to be merged
<caribou> xnox: I would like to gain experience in merging (never done before) and I thought that this could be a good opportunity
<xnox> caribou: it's a tough one to merge. If you do it, i'll carefully review it for you & provide feedback.
<xnox> and if all good sponsor it.
<caribou> xnox: tough in what sense (I'm looking at the report)
<caribou> xnox: I can pick another one to get my feet wet
<xnox> caribou: well try to resolve the conflicts and see how far you get =)
<caribou> xnox: ok, will try it out
<xnox> caribou: i think merging libpng (which is also offered up for grabs) is a better one to get ones feet wet.
<caribou> xnox: ok, I'll look at this one too
<caribou> xnox: I hope you don't mind me coming to you for a few questions ?
<xnox> caribou: yeah, just ask me here.
<caribou> xnox: for instance, the REPORT for libpng does not list any conflict; does this mean that only modifications b/w ubuntu's version and the new debian version need to be verified ?
<xnox> caribou: i don't usually use REPORT. but as far as I understand it means that: MoM generated diff between current ubuntu & common base, took that patch, slapped on top of new debian, and "it worked"(tm)
<xnox> caribou: but the resulting tree, might be complete brain dead and FTBFS =)
<xnox> caribou: are you using grab-merge script?
<caribou> xnox: yes
<xnox> caribou: that should download all relevant files and tell you what to do =)
<caribou> xnox: so basically check the .patch files make sure that old ubuntu modification are either still there or carried over in Debian and verify if it builds
<caribou> xnox: for a start
<xnox> caribou: usually i'd expect a person to rebase all applicapable changes, drop no-longer needed ones, adjust debian changelog, test-build the package, and compare diff (new_ubuntu -> new_debian) with old diff (old_ubuntu -> old_debian) to make sure it all still is sensible.
<xnox> caribou: exactly! =)
<caribou> xnox: ok, I will go that way, thanks
<seb128> hum
<seb128> shotwell autopkg tests started failing
<seb128> https://jenkins.qa.ubuntu.com/job/trusty-adt-shotwell/10/ARCH=i386,label=adt/console
<seb128> StateNotFoundError: State not found for class 'WelcomeDialog'.
<seb128> sil2100, didrocks, jibel: is that due to the new autopilot? is anyone handling that transition/going to fix the autopkgtests for stuff in the archive?
<didrocks> seb128: shotwell is using autopilot?
<sil2100> seb128: this looks like something that AP 1.4 *could* cause
<seb128> shouldn't also autopilot be blocked if it regresses tests? (it's marked as valid candidate on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
<seb128> didrocks, yes, pitti added autopilot tests to it
<pitti> ah, just saw the failure notification, I'll have a look
<pitti> seb128, didrocks, sil2100: yes, clearly from AP 1.4, I know what it is
<pitti> that's one of the two behaviour changes that it does
<pitti> will fix after meeting
<seb128> pitti, do you know if whoever is doing the autopilot update plans to deal with rdepends in the archive? (that might be worth an email to ubuntu-devel@)
<seb128> pitti, danke
<sil2100> pitti: thanks!
<seb128> hum
<seb128> something seems weird with https://launchpad.net/ubuntu/+source/gnome-keyring/3.10.1-1ubuntu1
<seb128> the builds are stucked on " dpkg-buildpackage: binary only upload (no source included)"
<seb128> for 3 hours
<seb128> cjwatson, infinity: ^ any idea about that?
<didrocks> seb128: most of the time I've seen this is because of a daemon (test daemon most of the time) wasn't killed by the tests
<seb128> didrocks, oh, I guess that makes sense, thanks
<didrocks> yw
<seb128> I guess infinity is going to be after me next for blocking the builders :p
<didrocks> right ;)
<pitti> seb128: oh, someone didn't commit to the bzr branch on upload :(
<seb128> pitti, shotwell?
<pitti> seb128: yes
<seb128> pitti, that would be me :/
<seb128> pitti, let me fix that
<pitti> seb128: or you do happen to have these commits locally and you forgot to push?
<seb128> pitti, I forgot to update the vcs, but I've the different sources locally so I can "replay" the commits easily
<pitti> seb128: or diffs from https://launchpad.net/ubuntu/+source/shotwell/+changelog :) (last two uploads)
<pitti> seb128, didrocks: test ported, FYI (now changing debian/tests/import to use the new autopilot-sandbox-run)
<didrocks> excellent, thanks pitti!
<pitti> seb128: (want me to do the import, if you are busy? no problem)
<seb128> pitti, sorry, door bell, I was away for a bit, doing it now
<seb128> pitti, ok, you can pull
<pitti> seb128: thanks
<seb128> pitti, I put back your unreleased change on top of the releases
<pitti> seb128: aand uploaded, cheers!
<seb128> pitti, danke ;-)
<bdmurray> pitti: could you have a look at change for bug 1084979?
<ubottu> bug 1084979 in apport (Ubuntu) "Submitting error report asks confounding questions" [Medium,Triaged] https://launchpad.net/bugs/1084979
<mlankhorst> confound these questions!
<pitti> bdmurray: it's a nice hack, but not something which I'd like to put upstream (as this is quite specific how we bolted on whoopsie support in the ubuntu branch); need to think about it
<pitti> bdmurray: I'd rather not pass an UI object to the hooks but call them anyway, as they usually do other things than just asking questions
<pitti> bdmurray: some, like rhythmbox, even change the affected package
<pitti> not passing an UI object will crash those hooks which don't check for it, but that doesn't matter that much
<bdmurray> pitti: Do you mean you'd rather the solution stopped passing an UI object to the hook but that it still ran?
<pitti> right
<bdmurray> pitti: got it, thanks
<pitti> bdmurray: that bug is still in an open tab; sorry, getting too many higher-urgency requests lately :/
<maxiaojun> hi, does anyone know the utf8 filename issue of unzip in 12.04-13.04 ?
<bdmurray> pitti: no problem, thanks
<pitti> maxiaojun: unzip works fine with UTF-8 in general
<maxiaojun> pitti: no, it makes all filenames appear to be ???? until 13.10
<pitti> ah sorry, I tried on current trusty; misread 13.04
<pitti> but we have unzip 6.0 since lucid
<pitti> maxiaojun: ah, apparently fixed in http://packages.qa.debian.org/u/unzip/news/20130224T163250Z.html
<GunnarHj> pitti: Hi Martin, do you have any idea what causes the problem at bug 1248343?
<ubottu> bug 1248343 in language-selector (Ubuntu) "language-selector-gnome "Failed to fetch" (language for firefox and libreoffice)" [Undecided,New] https://launchpad.net/bugs/1248343
 * pitti really needs to run out for a bit, bbl
<maxiaojun> pitti: sure, the fix is there, i'm just asking how to deal with the issue in old releases, most importantly, 12.04
<GunnarHj> pitti: No hurry with my question...
<happyaron> does Super-Space for switching input method really work for you?
<seb128> happyaron, define "switching input method"
<pitti> 25.0+build3-0ubuntu0.12.04.1
<pitti> GunnarHj: needs an apt-get update, it's now version 25.0+build3-0ubuntu0.12.04.1
<happyaron> seb128: switching among "input sources"
<seb128> happyaron, it works for me with gsd if I run ibus-setup and change the ibus binding to another one, I guess there is a grab conflict between ibus and gsd
<seb128> happyaron, ibus sources or gsd input sources?
<maxiaojun> ... what about the unzip issue in 12.04-13.04 ...
<hggdh> maxiaojun: supposing it is just a patch applied on the same version, we will need a SRU for it
<happyaron> still not very clear for me, but it just does not work out-of-box on my newly installed system.
<seb128> happyaron, right, there is that conflict (I noticed this week)
<seb128> happyaron, you also need the current gsd SRU
<GunnarHj> pitti: Aha, will suggest that. Thanks!
<pitti> GunnarHj: (followed up to the bug)
<seb128> happyaron, can you check with the gsd SRU and ibus changed to not conflict?
<happyaron> ok
<pitti> meh, autopkgtest fail galore due to uninstallable pykde
<pitti> jibel: ^ FYI, will retry in a bit
<maxiaojun> there are various fix over unzip 6.0 (upstream almost dead) accumulated over time
<GunnarHj> pitti: You are too fast to me as usual. ;-)
<TheLordOfTime> maxiaojun: i would assume that perhaps the patch that exists on the Debian bug for unzip, if it's in the Debian package, might be able to be applied to the packages as SRUs... (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682682 is relevant?)
<ubottu> Debian bug 682682 in unzip "unzip: Incorrectly displayed file names with UTF8 characters" [Normal,Fixed]
<maxiaojun> i just wonder whether we just upgrade to what saucy have or just apply the specific patch, i don't care other fixes at this point
<maxiaojun> i just want to know which is more acceptable to you and i will file a sru request then
<seb128> bdmurray, can you let the file-roller SRU in saucy be rolled out? The system reported a bunch of new issues but none seems related to the SRU (they are mostly retracing not working that create new buckets and slightly different signatures of existing issues that e.u.c fails to match in the same report)
<bdmurray> ev: Can we update errors yet?  I noticed and fixed saucy-proposed not being enabled in the retracers yesterday.
<bdmurray> seb128: I'll have a look
<seb128> bdmurray, not having proposed would explain why some of the retracing didn't work
<seb128> bdmurray, thanks
<maxiaojun> hggdh: maybe you can answer my question?
<GunnarHj> happyaron: Hi Aron! I just changed the font for Chinese to fonts-droid (bug 1173571). Considering that this is kind of a mined area, do you have any thoughts? I noticed that fonts-droid is used in Ubuntu Touch.
<ubottu> bug 1173571 in ttf-wqy-microhei (Ubuntu) "please change wenquanyi micro hei back with 69-language-selector-zh-tw.conf" [Medium,In progress] https://launchpad.net/bugs/1173571
<TheLordOfTime> pitti, hggdh: i'm curious on maxiaojun's behalf, about whether this would be version-bumped or SRU'd to fix the UTF8 issue.
<happyaron> seb128: after changing the ibus's shortcut, gsd's works, but then unity's shortcut help page will be displayed at the same time.
<TheLordOfTime> pitti, hggdh: there is a patch on the debian bug for it, so I'd think SRU, but again, you guys know better.
<TheLordOfTime> (in relation to maxiaojun's issue)
<bdmurray> TheLordOfTime, maxiaojun: I'll have a look at it.  Is the Ubuntu bug linked to the debian bug?
<happyaron> GunnarHj: it's good to use fonts-droid as default for Chinese, but there could be problem that they cannot be displayed in the editor area in libreoffice
<TheLordOfTime> bdmurray: i dont' see an Ubuntu bug on it
<seb128> happyaron, that's because you hold super for longer than a second, we have the same issue on other shortcuts (e.g super-s/f/v/...)
<happyaron> GunnarHj: that would need to be checked
<TheLordOfTime> maxiaojun: is there a bug about this in Ubuntu?
<bdmurray> bug 580961
<ubottu> bug 580961 in unzip (Ubuntu) "unzip fails to deal correctly with filename encodings" [Critical,Triaged] https://launchpad.net/bugs/580961
<TheLordOfTime> yeah just saw it
<happyaron> seb128: if press shorter then the input source switch does not work for me
<TheLordOfTime> (failed to search all bugs :/)
<TheLordOfTime> bdmurray: the debian bug with the fix is 682682...
<TheLordOfTime> bdmurray: the ubuntu bug doesn't seem to be linked right to that...
<happyaron> seb128: it's actually first show the help and then switchable among input sources.
<maxiaojun> https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/1199239
<ubottu> Ubuntu bug 1199239 in unzip (Ubuntu) "Do not call isprint when listing" [Undecided,Confirmed]
<TheLordOfTime> maxiaojun: i... think that's the wrong bug...
<TheLordOfTime> maxiaojun: but 580961 which bdmurray found seems to be right... https://launchpad.net/bugs/580961
<ubottu> Ubuntu bug 580961 in unzip (Ubuntu) "unzip fails to deal correctly with filename encodings" [Critical,Triaged]
<GunnarHj> happyaron: Needs to be checked by someone who speaks Chinese, I suppose. Could you check it out when language-selector has made it into the archive? Or should we just wait and see if bug reports drop in?
<maxiaojun> this was the bug that i filed when i noticed that the unzip utf8 issue can be fixed, and soon I found debian fixed it already
<TheLordOfTime> bdmurray: i think that debian 483290 got overlooked in favor of debian 682682...
<ubottu> Debian bug 483290 in unzip "unzip: Can not open shift-jis zip file on UTF-8 environment" [Normal,Open] http://bugs.debian.org/483290
<ubottu> Debian bug 682682 in unzip "unzip: Incorrectly displayed file names with UTF8 characters" [Normal,Fixed] http://bugs.debian.org/682682
<caribou> xnox: here's bug #1248573 regarding the merge of libpng
<ubottu> bug 1248573 in libpng (Ubuntu) "Please merge libpng 1.2.49-5 (main) from debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1248573
<happyaron> GunnarHj: I will check that later, just wonder when will it be made into archive?
<GunnarHj> happyaron: Anytime (already in -proposed).
<maxiaojun> i know a bug from end users would be more ideal, but many people don't understand the concept of utf8 zip, as both non-utf8 and utf8 zip both appeared broken
<GunnarHj> happyaron: TIA
<ev> bdmurray: yes! Could you please file an RT for it?
<TheLordOfTime> maxiaojun: bdmurray and I already ID'd a bug about this, I think he was going to take a look at it...
<happyaron> GunnarHj: I'll need to check them after working on ibus of saucy, and I think allow it in trusty archive right now is ok.
<bdmurray> Yes, hopefully today but this week for sure
<maxiaojun> ok
<GunnarHj> happyaron: That's fine; no hurry.
<seb128> happyaron, weird :/
<seb128> happyaron, with the current SRUs and changing the ibus binding the keypress is fine here
<seb128> happyaron, well, anyway, attente is looking at moving the key grabbing to unity, hopefully that should fix that
<seb128> happyaron, btw do you know if we still need ibus to handle the keybinding or if we should just unset it from there?
<happyaron> seb128: I think it's still needed (at least for now), there are missing functions from gsd/indicator-keyboard right now
<maxiaojun> for the ibus issue, actually in my u12.04 untiy 2d, super+space works ...
<happyaron> good to know, never tested that.
<happyaron> seb128: do you think we need a session evaluating fcitx?
<seb128> happyaron, what is missing? it seems to not make sense to have different pieces of code handling the same thing
<seb128> happyaron, that would be good to have I guess, not sure we have enough people knowing both and the impact of a change to have a discussion though
<happyaron> seb128: for example bug 1188509
<ubottu> bug 1188509 in indicator-keyboard (Ubuntu) "Embedded in menu doesn't work in IBus indicator" [High,Triaged] https://launchpad.net/bugs/1188509
<pitti> chrisccoulson: did you see the chromium autopkgtest failure?
<seb128> hate keyboard and input methods, hate hate hate
<pitti> chrisccoulson: "Package 'libunity-webapps-chromium' has no installation candidate"
<Laney> I pinged qengho about that already
<seb128> happyaron, I've no clue what is right there, some days I wonder if we should go back to just have different indicators for layouts and ims rather than trying to combine both
<happyaron> seb128: if so I can send some comparision material later, and do not have a dedicated session for it.
<happyaron> :)
<seb128> happyaron, and go back use libgnomekbd/libxklavier
<pitti> Laney: ah, it's qengho now, sorry; thanks (the notification went to chrisccoulson)
<Laney> He's been doing some sponsoring / uploading IIRC
<chrisccoulson> hi :)
<happyaron> seb128: well at least input method is having really bad experience right now. after installing saucy ISO, when I login to the user for the first time, ibus-ui-gtk3 crashed...
<pitti> seb128: yeah, combining the two wasn't the best thing in the world; I still have my ears ringing from a friend of mine "you broke my keyboard" :)
<seb128> happyaron, that's the bug assigned to you right?
<pitti> seb128: (not your fault, I know)
<seb128> happyaron, I asked you to have a look for a reason :p
<qengho> pitti, Laney, hi hi.  Ah, autopktest. Hrm.  Thanks for that.
<seb128> pitti, I pushed back on those changes for 3 cycles, we couldn't keep revert of GNOME code for ever
<seb128> pitti, but yeah, situations sucks
<pitti> I know
<happyaron> seb128: ok, I didn't get a trace from apport and think that could be another issue, will try again.
<pitti> qengho: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-chromium-browser/13/ (started failing yesterday)
<seb128> happyaron, the SRUs should improve things, if you set the keybinding to e.f ctrl-space things should be mostly working with current versions
<happyaron> seb128: but seems installing SRUs solved it, I cleaned my user dir and it won't crash on login
<pitti> qengho: (it also holds back systemd and gdk-pixbuf)
<qengho> pitti: "it" holds back?
<cjwatson> seb128: gnome-keyring> I suggest asking #webops to help investigate if you haven't already
<Laney> qengho: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html search for chromium
<qengho> What does chromium-browser have to do with systemd?
<seb128> cjwatson, done, thanks
<Laney> Depends: libudev1
<pitti> qengho: it seems to depend on udev and gdk-pixbuf
<pitti> qengho: and we test reverse dependencies before allowing a package to go in (see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
<GunnarHj> Laney: I broke my promise and filed the u-s-s bug 1248349. ;-) Not directly related to "the prepend issue", but I still thought I'd let you know.
<ubottu> bug 1248349 in ubuntu-system-settings (Ubuntu) "[language] Confusing list of display language options" [Low,Triaged] https://launchpad.net/bugs/1248349
<Laney> I saw it
<GunnarHj> Laney: Ok.
<maxiaojun> any news on the unzip utf8 filename issue?
<Laney> GunnarHj: note that it's different in trunk
<GunnarHj> Laney: Didn't know. Maybe I'd talk to attente about it?
<Laney> try building a package from lp:ubuntu-system-settings yourself
<Laney> it doesn't use that helper but I think achieves the same effect
<GunnarHj> Laney: Ok, will do that. (But code reuse is still a good idea, isn't it?)
<Laney> sure
<saiarcot895> Just to check, the Depends field in debian/control can specify an upper-bound version and lower-bound version like so: package (>> minversion), package (<< maxversion), correct?
<pitti> saiarcot895: yes
 * maxiaojun is editing bug ...
<TheLordOfTime> maxiaojun: bdmurray is kinda busy, he and many others have a lot of stuff to juggle... patience is a virtue, this won't be addressed as a priority above everything else...
<maxiaojun> TheLordOfTime: so i'm doing my part of editing bug :)
<pitti> rsalveti: FYI, I just updated your PARTNAME udev patch from not too long ago: http://paste.ubuntu.com/6371440/
<pitti> rsalveti: upstream pointed out that /dev/disks/by-name/ is for FS labels, /dev/disks/by-partlabel/ is for that kind of thing (GPT uses that, too)
<rsalveti> pitti: right, but the by-name was to match what android was using
<pitti> rsalveti: do we depend on that? or can we move the ubuntu side to by-partlabel/?
<rsalveti> I need to check if this patch is still useful, will take a look later today
<rsalveti> yeah, will check
<pitti> rsalveti: I just committed it to my local disk, no problem to revert/change it; but I just had it upstream reviewed, that's how it came up now
<ogra_> rsalveti, pitti, i tried to drop it back when we discussed it last and iirc not all devices got a link then
<pitti> no reason to completely drop the patch
<ogra_> (which is why i didnt push for dropping it before release)
<pitti> I'd just like to keep fs labels and partition labels apart, as they don't need to coincide
<ogra_> well, it would be nice to use the same thing across phone and desktop ... whatever we end up with
<rsalveti> yeah
<pitti> not yet relevant for desktop -- the PARTNAME property is an Android kernel change for now
<pitti> although https://www.kernel.org/doc/Documentation/block/cmdline-partition.txt already documents it (it's just not actually implemented in linux)
<rsalveti> right
<maxiaojun> my bug become a sru request now: https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/1199239 no branch or debdiff yet though
<ubottu> Ubuntu bug 1199239 in unzip (Ubuntu) "[SRU] unzip list utf-8 (non-ascii) filenames as ??" [Undecided,Confirmed]
<tjaalton> hallyn_: did you mean adding libxext-dev fixed -qxl build on arm? for some reason it builds fine on debian
<hallyn_> tjaalton: i mean taht the first failure in the build log is a missing file from that package;  and the porter-armhf box builds it fine in chroot, but the chroot has that package installed
<hallyn_> so i'm not 100% sure that that's the only thing needed, but it is apparemtly needed
<tjaalton> ok, and the debian package version wasn't pushed to git
<tjaalton> though it looks like not missing a build-dep or anything
<tjaalton> umm i mean the diff didn't add any build-dep
<tjaalton> but yeah, I'll just add libxext-dev and sort the mess with guoliang
<infinity> pitti: You around?
<tjaalton> hallyn_: it's missing a check for xextproto > 7.1, I'll add it
<hallyn_> tjaalton: cool, thanks, here's hoping that's it :)
<tjaalton> yeah, src/qxl_drmmode.c includes dpms.h if the conditional for xextproto isn't set, and this was added in the new release (kms support)
<tjaalton> fallback is dpms.h
<slangasek> bdmurray: so in trusty, apport seems unwilling to submit bug reports to LP for me; do you know of anything that's changed to cause this?
<slangasek> bdmurray: btw, I noticed from my upstart logs a bug in the use of watershed... watershed isn't on the path, it needs to be invoked as /lib/udev/watershed
<bdmurray> slangasek: bug reports or crash reports?  for the latter see problem_types in /etc/apport/crashdb.conf
<bdmurray> I think apport (reporting to Launchpad) has traditionally been disabled until alpha something
<tjaalton> hallyn_: looks good, arm64 still fails but looks like some sort of asm error
<hallyn_> tjaalton: yeah arm64 won't build anything for me :)
<GunnarHj> Laney: My test with an u-s-s build from the trunk made it even worse. :(
<hallyn_> tjaalton: thanks!  now i can try and get unity running in a container
<tjaalton> nice :)
<bdmurray> stgraber: could you have a look at bug 1196975 again?  The reporter responded a bit ago.
<ubottu> bug 1196975 in ifupdown (Ubuntu) "ifupdown calling dhclient with -1 causes it to fail when dhcp server unavailable" [Undecided,New] https://launchpad.net/bugs/1196975
<stgraber> bdmurray: yeah, I'm aware of that report, but it's not very high on my todo
<stgraber> bdmurray: it's very far from a trivial change, fixing this properly would likely need some more heavy patching of isc-dhcp, so I prefer the status quo to rushing a patch in isc-dhcp
<stgraber> anyway, moved to isc-dhcp for now
<bdmurray> stgraber: great, thanks for looking at it
<jibel> pitti, the problem with pykde4 is the latest upload of systemd adds a Breaks: consolekit (<< 0.4.6-1) to udev but consolekit 0.4.5-3.1ubuntu2 is available and libpolkit-qt-1-1 depends on consolekit
<TheLordOfTime> bdmurray: around still?
<jibel> pitti, output of apt-get install -o  Debug::pkgProblemResolver=1 software-properties-kde http://paste.ubuntu.com/6372301/
<bdmurray> TheLordOfTime: yes
<TheLordOfTime> bdmurray: i'm not super familiar with the bug, but with https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/580961 are we certain 483290 is the correct Debian bug for this?
<ubottu> Ubuntu bug 580961 in unzip (Ubuntu) "unzip fails to deal correctly with filename encodings" [Critical,Triaged]
<TheLordOfTime> because there seem to be two debian bugs on it..
<TheLordOfTime> one with a fix implemented in Sid, and another without...
<bdmurray> TheLordOfTime: I didn't read through all fo 580961 or the corresponding debian bug and just uploaded SRU fixes for the other bug
<TheLordOfTime> bdmurray: ack.
<bdmurray> but the change also resolves the test case in bug 580961
<ubottu> bug 580961 in unzip (Ubuntu) "unzip fails to deal correctly with filename encodings" [Critical,Triaged] https://launchpad.net/bugs/580961
<TheLordOfTime> bleh stupid IRC client...
<TheLordOfTime> bdmurray: ah, okay, cool.
<slangasek> bdmurray: bug reports; I have a modified /etc/apport/crashdb.conf to set problem_types = ['Bug', 'Package'], and it seems not to be talking to my browser
<bdmurray> slangasek: it's missing, 'Crash'
<slangasek> bdmurray: oh - is this a new behavior change?
<bdmurray> slangasek: well before whoopsie apport would be just turned on or off, now for stable releases 'Crash" is removed from the list of problem_types to set to Launchpad
<slangasek> hmm
<slangasek> I don't remember ever seeing that value before
<slangasek> hopefully we don't have something automatically editing the conffile on package upgrade
<bdmurray> slangasek: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/saucy/apport/ubuntu/revision/2249
<bdmurray> oh maybe if problem_types is not there it sends them all
<slangasek> ah, ok
<slangasek> so it seems my problem was mistakenly accepting the new version of the conffile on upgrade
<slangasek> I wonder if we aren't at the point that we should stop flip-flopping this between devel and release... just leave it off by default and only turn bug reporting on for those who explicitly edit the file
<bdmurray> I think it may have been discussed in the past and we were waiting for server side hooks in the error tracker, so that we can communicate with / get data from reporters.
<slangasek> alright
#ubuntu-devel 2013-11-07
<infinity> xnox: Thanks for cleaning up those last two boost1.53 rdeps.
<infinity> xnox: And it looks like librime and yaml-cpp are caught up with some other fun, but we can deal with that later.
<infinity> Oh, a simple SONAME transition there.  I'll fix that.
<infinity> xnox: On, but neither rivet nor opencolorio actually build with the new yaml-cpp.  Fun.
<pitti> Good morning
<pitti> infinity: I'm around now
<pitti> slangasek: we didn't yet enable LP crash reports for trusty again
<pitti> jibel: oh, my fault, thanks; I'll fix that one way or the other
<pitti> slangasek: just comment out the whole problem_types line
<pitti> bdmurray: ^ yes, you are right
 * infinity finds pitti catching up on backscroll oddly fascinating.
<infinity> pitti: Does anyone other than you (and GSA, I guess) have access to the ddeb-scraping stuff on germanium?
<pitti> Alt+N FTW :)
<pitti> infinity: according to getent groups, it's cjwatson, seb128, slangasek, and me
<infinity> pitti: Curious.  Okay, more importantly, does anyone else know how it works? :)
<pitti> infinity: you ought to have access as well
<infinity> pitti: We've going to take a buildd offline tomorrow, and I'd like to do a final scrape before we do, so we don't lose any ddebs.
<pitti> infinity: it's more or less a checkout of https://code.launchpad.net/~pitti/%2Bjunk/ddeb-retriever/ plus this crontab: http://paste.ubuntu.com/6374416/
<infinity> pitti: I ought to as in you think I have access already, or you think it would be good if I did?
<pitti> infinity: ah, sure; so whoever is around of these four, should run this command: ~/ddeb-retriever/ddeb-retriever today
<pitti> infinity: yes, I do; filing an RT
<pitti> infinity: RT sent, CCed you
<infinity> pitti: Cheers.
<pitti> infinity: if it doesn't happen by tomorrow, do you have enough flexibility there to wait for one of these four?
<infinity> pitti: I can get the RT done. :P
<pitti> the command takes some 30 seconds
<pitti> infinity: heh, if you have r00t, what am I complaining about :)
<infinity> pitti: No root, but I have friends in low places. ;)
<infinity> (or high, depending on your endianness)
<pitti> infinity: that was fast
<infinity> pitti: ;)
<slangasek> oh, I have access to germanium? ;)
<pitti> slangasek: not sure about ssh etc., but you are in the ddebs group there anyway
<slangasek> huh
<slangasek> no one ever told me :)
<pitti> then, good that infinity asked and I checked :)
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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
 * Laney gets scared
<seb128> Laney, bah, I did some sponsoring yesterday, I would have left you those if I knew you were piloting today ;)
<Laney> :(
<mlankhorst> ooh fun bug
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1247607
<ubottu> Ubuntu bug 1247607 in Nouveau Xorg driver "Libdrm compiled with gcc 4.8 makes card hang on resume from s2disk" [Medium,Confirmed]
<brendand> does anyone experienced with launchpadlib know how to update tags in a bug?
<brendand> if i try writing to the tags attribute of a bug then it gives me a strange error
<brendand> is that the right way to do it, or something else?
<cjwatson> What's your current code?
<cjwatson> There are some bugs in this area; you can do it but you have to be a bit careful
<cjwatson> Specifically https://bugs.launchpad.net/launchpadlib/+bug/254901
<ubottu> Ubuntu bug 254901 in launchpadlib "appending tags to bug.tags is not supported properly on lp_save()" [Low,Triaged]
<cjwatson> A form that works is: tags = bug.tags; tags.append("name-of-tag"); bug.tags = tags; bug.lp_save()
<cjwatson> Or, as suggested in that bug, bug.tags = bug.tags + ["name-of-tag"] rather than trying to use list operations on bug.tags directly
<brendand> cjwatson, mine was something like 'bug.tags = bugs.tags + ['name-of-tag']'
<brendand> :/
<brendand> cjwatson, so that *should* work
<brendand> cjwatson, let me fish out the error i get
<brendand> *** NoBoundRepresentationError: Resource is not bound to any representation, and no media media type was specified.
<brendand> media media
<brendand> heh
<cjwatson> Perhaps you could give me a way I can reproduce this.
<cjwatson> So that I can get a proper traceback ...
<brendand> cjwatson, sure i'll create a simple test case
<brendand> which will of course, not trigger the bug !
<brendand> let's see
<ara> hello! anyone in the SRU team would have a look to this unapproved upload? https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=pm-utils
<ara> the bug description should be now SRU compliant
<ara> thanks!
<ev> any tech board members awake? Could someone add me to ~uds-organizers?
<infinity> ev: What tech board?
<seb128> infinity, the sabdfl one :p
<seb128> ev, you need sabdfl until we get a TB back...
<infinity> ev: (GSA or WeBops can add you, or Mark)
<henrix> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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: henrix, Laney
<brendand> cjwatson, ok so i think the problem is that i'm accessing the bug via a task
<brendand> cjwatson, yep so doing bug = task.bug, then proceeding to use bug works
<brendand> cjwatson, but task.bug.tags = task.bug.tags + ['tag'] doesn't
<brendand> problem 'solved'
<cjwatson> Yeah, I can believe that.  lazr.restfulclient is odd
<brendand> yeap
<cjwatson> doko_: Is there any reason python-setuptools depends on python rather than python:any (and similarly python3-setuptools), or is it just an oversight?  I see it overrides the standard substvar generation
<pitti> Laney: I'm going to do 5 sponsors as dholbach asked, mind if I look at the libpng, lighthttp, spacefm, sks, libxvmc merges?
<pitti> Laney: (don't want to step on your toes if you are already at them)
<pitti> henrix: ^ question for you, too
<Laney> pitti: go for it
<cjwatson> So who isn't asking the touched-it-last person about merges, then?
<cjwatson> $ grep-merges cjwatson | grep lighttpd
<cjwatson> lighttpd        Colin Watson <cjwatson@ubuntu.com>
<Laney> It was me that asked btw, not dholbach
<Laney> I was just channeling him
<Laney> :P
<cjwatson> Frankly this kind of thing is why I'm increasingly demotivated to sponsor
<pitti> some "Mattia Rizzolo" -- cjwatson, do you want to handle that one? (didn't look at it yet, just listed the first 5 merges I saw)
<seb128> cjwatson, it's not obvious to most contributors that merges are not "free to grab" I think :/
<cjwatson> Sponsoring merges is twice as hard as doing them
<cjwatson> So not really
<cjwatson> seb128: Shame nobody reads, apparently ...
<pitti> cjwatson: I meant, should I reject and say "cjwatson wants to do it", or review/upload it?
<cjwatson> I mean, it's the first bullet point on the MoM output pages
<henrix> pitti: ack, thanks.  i can do kernel only btw...
<cjwatson> pitti: Go ahead and review/upload if you want, I guess
<cjwatson> As it happens I hadn't finished working on that
<cjwatson> Please be careful though, IIRC that isn't an entirely trivial merge and a naive merger could easily accidentally drop important bits
<pitti> *nod*
 * infinity is pretty sick of this whole "stealing merges are a good way for people to contribute" thing too.
<pitti> xnox: someone did the sks merge (bug 1247908), any objection as the TIL?
<ubottu> bug 1247908 in sks (Ubuntu) "Merge sks 1.1.4-2 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/1247908
<infinity> Well, "stealing" is a silly word to use there, but.  As has been pointed out on many occasions, merges come in 2 flavours: 1) So simple that it's faster to do the merge yourself than to properly review and sponsor someone's patch to do one, or 2) So complex that you have to do the merge yourself anyway just to verify that the person you're sponsoring did it right by comparing your work.
<pitti> well, I don't mind much for the "fly-by" fixes that I do to random universe packages, but I would mind merging "my" packages without asking me
<Laney> Oops, didn't notice you said libpng in your list
<infinity> pitti: Not convinced that most people who don't personally know you make that distinction. :P
<xnox> pitti:please steal. I only had a no-change rebuild. Last "TIL with changes" was LoganCloud though.
<pitti> infinity: yeah, that's the problem :) (and that's why I go over all my merges at the beginning of the cycle usuallY)
<Laney> xnox: You told caribou to take libpng but it already had a merge branch up for sponsoring
<pitti> the ones that are left over in main.html are the ones where the Debian updates don't bring anything substantial
<caribou> Laney: yeah, I sent an email to the previous dev who merged it
<caribou> Laney: turns out he had done the work already
<pitti> xnox: ah sorry, https://merges.ubuntu.com/universe.html thinks you were
<xnox> Laney: /o\ damn. sorry, caribou.
<caribou> xnox: nm
<pitti> xnox: hah, you are :) (No change rebuild against db 5.3.)
<caribou> xnox: I'll do another one later to get more experience
<xnox> pitti: yeah, not sure how to version no-change rebuilds on top of Xubuntu1, without "stealing" TIL =)
<infinity> xnox: You don't, you just get to end up owning half the archive (and be very motivated to push things back to Debian)
<pitti> xnox: I read that as "you don't care", I'll review/merge
<pitti> infinity: or, in this case, teach LP to do binNMUs? :-)
<seb128> xnox, https://code.launchpad.net/~ankitbko/ubuntu/saucy/eject/fix-for-795239/+merge/173335 ... no reply on the debian side, do you think it would make sense to sponsor it (were you happy with the changes?)
<xnox> infinity: i like doko's hands off approach =) upload -defaults bump and wait for archive to "naturally" migrate.
<xnox> infinity: all we need is binNMUs....
 * infinity is still very binNMU-averse...
<infinity> xnox: I have a sneaking suspicion doko's "pull db-defaults from experimental" thing is about to backfire when they upload 5.3.x (without an epoch) to unstable, and we get to whine and ask them to add the epoch back.
<infinity> Just wait for it.
<xnox> seb128: yeap, go ahead.
<seb128> xnox, thanks
<xnox> infinity: well, debian's maintainer is also thinking to request db6.0 removal from the archive.
<infinity> xnox: And rightfully so.
<ev> seb128, infinity: thanks!
<pitti> Laney: apache-log4j1.2 and xmpi as well, while I'm at it?
<Laney> pitti: sure thing
<pitti> Laney: ack (I'm using the bug assignment you suggested in the mail)
<pitti> Laney: ok, all merges on sponsoring page done
<Laney> \o/
<Laney> pitti: thanks for helping out on that
<Laney> 85, looking a bit better already
<pitti> Laney: you called to the flags :)
<ev> infinity, cjwatson, pitti, others: do we have a means of extracting coverity data, code coverage, and test results inside packages built in a PPA (from dep8 tests)? Could we (ab)use binarypkgmangler for such a task?
<ev> we're trying to be good citizens of Launchpad in the new CI Airline architecture, but this is one area where we've seemingly needed pbuilder hooks
<caribou> Laney: FYI, I did contact the previous owner who had done the work but left the "please take" comment on merge.ubuntu.com
<caribou> Laney: timezone did the rest; I got his reply while I was gone
<Laney> caribou: fair enough
<Laney> Still was good experience, I hope
<caribou> Laney: it was; I'll try some other one later
<mlankhorst> can I close launchpad bugs in packages uploaded to debian?
<mlankhorst> when synced back
<Laney> yes, that works
<mlankhorst> found an awesome undefined behavior bug, struct->member++ = func(struct); will func() see old or new struct->member? :P
<mlankhorst> oops
<mlankhorst> *struct->member++ = func(struct);
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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: henrix
<pitti> ev: not pkgbinarymangler, as that runs too late; AFAIK you need to change the ./configure/CFLAG arguments, don't you?
<pitti> ev: so it might be a modified dpkg which supplies these extra CFLAGS by default, or something like that
<pitti> ev: I don't know whether it's just CFLAGS or whether the build system needs to support gcov/lcov in other ways; so far I've just used the gnome-common macros
<caribou> yesterday I worked on fixing the FTBS on the crash package
<caribou> the fix got implemented in the debian package
<caribou> which had the same FTBS
<caribou> So now the package that builds correctly is 7.0.3-2 but we carry 7.0.1-2 in the archive
<caribou> will the most current crash package be eventually picked up from Debian ?
<apw> pitti, took the liberty of pushing some pending changes to apport branch for your next upload for trusty
<caribou> or is there something to be done for this to happen ?
<apw> pitti, pulling up the fixes we did for precise and will be needed in 14.04
<pitti> apw: ah, thank you
<pitti> caribou: yes, we auto-sync daily
<caribou> pitti: then any reason why crash is at 7.0.1-2 in our archive and 7.0.3-2 in debian's ?
<pitti>      crash | 6.1.6-1ubuntu2 |        trusty | source, amd64, armhf, i386, powerpc
<caribou> pitti: 7.0.2-1 got uploaded to debian/unstable on 10-30-2013
<pitti> caribou: because it has ubuntu modifications, so it needs a merge
<caribou> pitti: yeah, this is because 7.0.1-2 fails to build in -proposed
<pitti> caribou: or someone needs to check that the ubuntu modifications are obsolete and can be synced
<pitti>     crash | 7.0.2-1ubuntu1 | trusty-proposed | source, amd64, armhf, powerpc
<pitti> caribou: still, ubuntu modifications
<caribou> pitti: ah, yes, the autopkgtest
<pitti> caribou: and the aarch64/armhf/autopkgtest changes are not in Debian, so need merge
<caribou> pitti: so what would you suggest : merge 7.0.3-2 or backport the FTBS fix ?
<pitti> caribou: usually merging
<caribou> pitti: ok, I'll take care of it
<mapreri> cjwatson: umh... I think I have to make my esce
<mapreri> Excuse...
<mapreri> I choose to don't ask you because you made a very simple upload and I thought you don't have particular knowledge on the package.... I went wrong.
<mapreri> pitti ^ (FYI)
<caribou> pitti: btw, wouldn't it be simpler to get the ubuntu specific modifications in the debian package if possible ?
<pitti> caribou: yes, absolutely
<pitti> caribou: whoever did these changes should usually file a Debian bug with the patch
<caribou> pitti: ok, I'll check with Troy
<ev> pitti: sorry, I'm not sure I follow. How can we provide a modified dpkg to a PPA? If you upload dpkg to a PPA does it automatically pick up and use that version (if so, very clever). Does pkgbinarymangler really run too late for extracting out the coverage, coverity, and test case artifacts?
<cjwatson> It does
<cjwatson> Since the PPA itself is in sources.list for any builds to that PPA, and the builder upgrades its chroot at the start of each build
<cjwatson> pkgbinarymangler could certainly be hacked to extract artifacts, provided that something has arranged to generate them in the first place ...
<cjwatson> (dpkg seems a bit low-level for this though, and that would be an utter pain to maintain)
<cjwatson> You could divert dpkg-buildflags, as long as you only care about packages that use it (we could reasonably mandate that for things we own)
<cjwatson> Most of our stuff probably uses it already by way of dh9
<cjwatson> mapreri: Thanks.  It's a good idea to check anyway; it's not so much about whether the person who touched it last has specific knowledge, it's because by default they're the person responsible for the merge and if you steal it from them without asking then there's a risk of duplicated work.  In fact I had already started on the merge, though hadn't got very far yet.
<henrix> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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> ev: right, I actually meant dpkg-buildflags (I thought that was in dpkg)
<cjwatson> pitti: It's in dpkg-dev, yes, but it would be quite a bit of ongoing cost to do that by uploading a modified dpkg - would have to keep merging
<cjwatson> Should be easy enough to divert if that's what's needed - call the underlying one and tweak
<pitti> right
<mapreri> cjwatson: you right.... Sorry again.
<cjwatson> np
<ev> well the problem then becomes how do you make the package doing the diverting of dpkg-buildflags a requirement for all the packages in the PPA without explicitly asking for it in their control files
<ev> at least as I see it
<cjwatson> ev: That's not a problem if it's one of the things that's already preinstalled in the chroot; pkgbinarymangler would qualify
<ev> cjwatson: I thought while pkgbinarymangler was determined to be a good target for extracting the artifacts, it ran too late to divert dpkg-buildflags? Or did I misunderstand what you said above?
<pitti> ev: it currently only diverts dpkg-deb, but it could additionally divert dpkg-buildflags
<ev> pitti: ohh. So if I understand correctly: given a PPA that we want to extract gcov data from, we upload a fork of pkgbinarymangler that diverts dpkg-buildflags to include the gcov flags and also splits out the coverage data into a "-coverage" package?
<pitti> ev: or upload that mangler to ubuntu, and make it check something in the PPA to see whether you want cov enabled
<pitti> ev: of course the first tests should actually happen with a forked pacakge in a PPA, yes
<seb128> mhall119, hey, you probably know but checking ... are the hours on summit.ubuntu.com UTC ones? (e.g are sessions from 14utc to 20utc)?
<mhall119> seb128: yes
<seb128> mhall119, thanks
<mitya57> Mirv: do you have anything against /me uploading a qtsensors merge with Debian NEW queue? I need the renamed -dev package for my PyQt5 sync.
<Mirv> mitya57: it sounds ok (it's a switch from git snapshot to released version with not too many commits in between), but can you check qtubuntu-sensors continues to build against it?
<cjwatson> caribou: stud uploads - you can't upload the same version to multiple series like that
 * mitya57 checks
<cjwatson> caribou: 2/3 of them will fail
<arges> cjwatson: i'll fix that. do they need to be rejected first?
<caribou> cjwatson: I don't understand, I tested each one of them
<cjwatson> arges: Doing so
<arges> cjwatson: thanks
<doko_> cjwatson, should work with :any. the substvars overwrite is only there to build it for all available versions before they are supported
<arges> cjwatson: I'm assuming this is the correct way to version for same version in two releases: lahttps://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<cjwatson> caribou: two out of three of the uploads would have failed because you can't have the same version with different contents
<cjwatson> arges: exactly, just mentioned that in the reject message
<caribou> cjwatson: oh, I see
<jdstrand> cjwatson: hey, I asked you this in #ubuntu-touch. in case you didn't see:
<jdstrand> 06:08 < jdstrand> cjwatson: hi! if I do 'pkcon install-local <click>' is 'pkcon remove <pkgname> <pkgvers>' expected to work now
<jdstrand> 06:11 < jdstrand> cjwatson: click list tells me it is installed, but both 'pkcon remove <pkgname> <pkgvers>' and 'pkcon remove <pkgname>' fail with:
<jdstrand> 06:11 < jdstrand> Command failed: This tool could not find the installed package: could not find com.example.am-i-confined
<cjwatson> jdstrand: That's not a syntax pkcon accepts
<cjwatson> jdstrand: https://lists.launchpad.net/ubuntu-appstore-developers/msg00553.html shows the syntax in the last bullet point
<jdstrand> ah, I see
<mitya57> Mirv: copied to my test ppa (to simulate a clean environment), will now prepare a merge in Bzr and upload it tomorrow(?) if the build succeeds
<jdstrand> cjwatson: thanks (I tried looking at pkcon help, but that didn't actually help)
<cjwatson> no, quite ... but I didn't write pkcon, I'm just attaching to it because it's better than doing my own dbus interface from scratch :)
 * jdstrand nods
<cjwatson> doko_: ok, do you want me to upload for that or will you fix it in Debian?
<cjwatson> I see we're in sync at the moment, so maybe better the latter ...
<Mirv> mitya57: ok, sounds like a plan. thanks!
<doko_> need to merge with setuptools, barry's already pestering me
<cjwatson> well, I'm just trying to unblock people who are trying to do cross-building
<doko_> ok
<doko_> but then, you almost always need to make cross-buildable python modules be aware of the cross build
<kirkland> admittedly it's been *ages* since I used VNC to an Ubuntu desktop, but I'm trying to do so right now, to a 13.10 desktop, over gigabit LAN, and it's unusably slow...  is unity3d to blame?
<cjwatson> doko_: hm, the one I'm looking at is an odd case, it builds some other arch-dependent stuff but it looks like all its Python module handling is arch-indep
<cjwatson> doko_: (ubuntu-keyboard)
<doko_> sure, go ahead
<cjwatson> ok, thanks
<pitti> jibel: what's the current status of cherrypy3? last thing I remember is that the py3 package is broken?
<pitti> jibel: (it doesn't have any test output, just "exit with status 70")
<pitti> oh, no zul
<jibel> pitti, I notified zul that the package must be fixed
<jibel> pitti, it doesn't install the deamon to the right location and python3 is half-done
<pitti> ah
<pitti> jibel: thanks
<dpm> hi cjwatson, on fat click packages, are all the binaries supposed to be installed on disk?
<cjwatson> yes
<dpm> tedg, ^
<tedg> cjwatson, Do they have specific directories based on arch?
<cjwatson> that's up to the SDK / app developer conventions
<tedg> cjwatson, Or is that for the app to decide?
<aquarius> cjwatson, we briefly discussed t'other day, and I understood that fat packages are arch "multi", and have a lib/$arch/qml, lib/$arch/lib etc folder (naming to be decided), and the app runner takes care of putting lib/$arch/lib on LD_LIBRARY_PATH before running the app, or something similar?
<cjwatson> we should have a convention and common dispatcher code to handle it; we don't yet
<tedg> I think the question that aquarius had there was how do I handle that if I can't have a shell script.
<cjwatson> I suggest lib/<multiarch triplet>/
<cjwatson> tedg: we need common code in the platform for this
<cjwatson> aquarius: something along those lines
<tedg> cjwatson, K, do we have someone with a work item to do that?
<aquarius> I think we want lib/$multiarchtriplet/thingy because there are different thingies -- qml components to go on QML2_IMPORT_PATH, libraries for LD_LIBRARY_PATH, etc
<cjwatson> tedg: I don't think so yet, haven't managed to con anyone into doing it
 * tedg says "not it!" ;-)
<aquarius> what I'm not sure about is... how does it work if your main executable is a binary?
<cjwatson> aquarius: I'd prefer lib/$triplet, qml/$triplet, etc.
<cjwatson> aquarius: bin/$triplet?
<cjwatson> I mean you still need a dispatcher anyway ...
<aquarius> so my .desktop file contains Exec=binaryname, and the dispatcher says "aha! this looks like a fat package to me, so I shall look for and execute bin/$triplet/binaryname ?"
<tedg> cjwatson, The only thing I'm curious about is how much we want to put in generic dispatcher vs. app specific.  For instance, some apps may not have QML.
<cjwatson> aquarius: well, we already mangle desktop files, we could mangle differently
<aquarius> or maybe it just adds bin/$triplet to $PATH, qml/$triplet to QML2_IMPORT_PATHS, lib/$triplet to LD_LIBRARY_PATH, and then just execs as normal?
<cjwatson> tedg: I'm honestly not sure and don't feel I have enough knowledge about what people tend to do in apps to implement this
<tedg> aquarius, I imagine we'll say "fat package, set PATH to include that dir"
<tedg> Yeah, I think just setting the env is best.
<cjwatson> all I can do is lay down some general guidelines for what I think will work well with click and what I think is suitably cognate with the rest of the system
<tedg> And we already do that for PATH
<cjwatson> and hope that if I repeat it enough times then somebody will implement something sensible and people will stop asking me about it :)
 * tedg knows what cjwatson wants for Christmas ;-)
<tedg> If it's just adding those env vars, I think upstart-app-launch should do it for that case.  And jdstrand's aa-exec-click would need to as well.
<xnox> lib/$triplet/bin is actually more used location by many tools out there.
<aquarius> I personally don't care abou tthe names, as long as there are some chosen :)
<aquarius> tedg, it's a tiny bit more complex than that because you have to *get* the arch triplet from somewhere
<aquarius> and dpkg-architecture is not in the image
<tedg> aquarius, I can get it at compile time.
<aquarius> e
<aquarius> er
<aquarius> that works?
<xnox> tedg: it's a fat one, one has multiple.
<tedg> xnox, Compile time of upstart-app-launch
<xnox> tedg: i can totally execute armhf binary on my amd64 desktop.
<xnox> tedg: and i386.
<doko_> xnox, were the libnih issues solved, or are there any more?
<aquarius> xnox, I think he means that upstart-app-launch doesn't ask at runtime "which arch am I on"... we compile the arch triplet into upstart-app-launch at compile time
<tedg> xnox, Sure, you can.  My dad can't :-)
<cjwatson> yeah, as long as the dispatcher is arch-dependent this is fine
<cjwatson> xnox: then execute by hand; that is out of scope
<aquarius> upstart-app-launch is currently a real executable rather than a script
<tedg> We could put it as a var in the upstart job though.  Then it could be overriden easily enough.
<xnox> doko_: i solved it by writting more simplistic code. I will dig into it at one point in the future - cause it seemed like for that code it, it was doing something sensible on !arm - and something it cannot compile itself on arm*
<aquarius> which I discovered when I assumed it was a script and looked at it to see how it worked :)
<cjwatson> probably good for it to be a real executable since it's fairly performance-sensitive
<tedg> aquarius, It's a very special scripting language defined by Intel ;-)
<xnox> doko_: but i want something smaller than 12k LOC & 40MB big *.i / *.s files for you =)
<cjwatson> tedg: I hope it's not defined by Intel on the phone :-)
<aquarius> ha!
<doko_> xnox, is this in libnih multi-k line's test functions?
<xnox> doko_: yeah. which use #define magic, to actually generate unrolled massive loops, from that multi-k line's test functions, into even bigger ones. I've dared to touch the magic, and it was too much for arm to handle.
<cjwatson> I never understood why those test functions weren't just split up
<xnox> cjwatson: yeah, it's boggling to me. but libnih is still keybuk upstream, so i don't want to modify it too much.
<xnox> cjwatson: but then again, i do plenty of work on it lately.
<xnox> (spare time stuff)
<slangasek> doko_: so, regarding TLS and bionic
<slangasek> we've done some evil, evil things in the thread handling... effectively making pthread mutexes no-ops on the bionic side, to account for the fact that the TLS struct on glibc is smaller than it is in bionic
<slangasek> doko_: do you think it would be practical to rebuild glibc with a padded struct?  or would this be horribly abi breking?
<slangasek> breaking
<slangasek> and maybe I should be asking infinity this
<slangasek> infinity: ^^
<doko_> slangasek, ugh, should I know about that?
<slangasek> maybe? you know things ;)
<cjwatson> this is ultimately the "reasons Nexus 7 is painful" thread, right?
<slangasek> cjwatson: yes - but I'm now wondering whether it's also why the emulator is failing
<slangasek> depending on where and how the TLS neutering was done
<xnox> slangasek: hm. i thought TLS struct was smaller on bionic side, which is now fixed in kitkat (it's up to 128bits now)
<xnox> slangasek: not the other way around.
<xnox> cjwatson: hm, was that thread somewhere I can see?
<slangasek> xnox: no, I'm told it's larger on bionic, which is why when it's allocated by glibc (as it would be in the case of any Ubuntu apps), you get segfaults
<xnox> ok.
<xnox> ah, yeah. https://code.google.com/p/android/issues/detail?id=43040
<xnox> no that's something else. anyway.
<cjwatson> xnox: "thread" = "pub conversation"
<cjwatson> at least in my case
<xnox> ok
<slangasek> pub local storage
<hallyn_> hi - just curious, anyone know offhand why the re2 package hasn't gotten past debian experimental?
<hallyn_> (I ask bc lmctfy - google's cgroup manager - depends on it)
<Laney> the maintainer is probably the best person to answer that`
<Laney> however: "ROM; NPOASR; moved to experimental, pending upstream ABI stability"
<hallyn_> feh
<hallyn_> where does that info come from?
<Laney> I went to http://packages.qa.debian.org/r/re2.html and clicked on Removed 0+hg23+dfsg-1 from unstable
<Laney> Appears to have dropped the library package for that reason too
<hallyn_> oh, iw as looking at http://packages.qa.debian.org/r/re2.html but didn't see that history, thx
<hallyn_> that doesn't bode well for me
<Laney> tumbleweed is your man
<slangasek> rsalveti: can you tell me where I should look to see any patches to the android tree regarding the pthreads hybris hack-around?  Or were the changes all handled in libhybris itself?
<rsalveti> slangasek: they are mostly in hybris, there's only one in android that changes the tsl slot, but that's only used when qemu is using the host gl
<rsalveti> slangasek: we're actively debugging it as we speak, so hopefully we should know better soon
<rsalveti> translator can't find the qemu pipe and sw emulation is busted, debugging now why
<slangasek> ok
<infinity> slangasek: I'm not positive that the TLS struct is actually part of libc's advertised ABI, but even if not, mangling it sounds like the sort of thing that could have all sorts of undesired and hard-to-find knock-on effects.
<dkessel> hello. i tried upgrading to trusty via 'do-release-upgrade -d' - however I am getting problems because the package sources seem to be unavailable at the moment... is this known?
<brainwash> dkessel: same for me, but I cannot remember the exact error message
<Laney> anyone got a script for doing a mass-give-back in a PPA?
<dkessel> brainwash, i think i got it. disabling the extras package sources worked... downloading packages now
<Laney> oh, that was simple
<brainwash> dkessel: yeah, you might be right, it was related to the extras repository I think
<Laney> blah... for b in builds: if b.can_be_retried: b.retry()
<seb128> slangasek, how come you get to upload SRUs without bug reference? ;-)
<infinity> seb128: Because he's a cowboy.
<seb128> infinity, he's from Portland, how comboy is that?!
<sarnold> people in portland own -chickens-!
<infinity> sarnold: But do they ride them?
<sarnold> infinity: I hope not :)
<seb128> who knows, slangasek might?
<tumbleweed> Laney, hallyn_: yeah, I've just had a request for it in unstable. I guess I need to start the ABI rollercoaster (at least development has slowed down now)
<hallyn_> tumbleweed: oh yippe, that's good for me :)
<hallyn_> tumbleweed: otherwise i'd have tolook at the licensing to see about simply including a snapshot in with the lmctfy source
<hallyn_> tumbleweed: what kind of timetable do you think there'll be for that ?
<hallyn_> i.e. can it possibly hit in time to make trusty before FFE?
<tumbleweed> hallyn_: hard to say. I haven't been very active recently. But yes, that seems reasonable
<tumbleweed> it's just resurrecting some work I've already done, and tidying it up a bit
<tumbleweed> just need to do it
<hallyn_> tumbleweed: excellent, thanks (if you find time to do it :)
<hallyn_> tumbleweed: so did you ever write any programs linking aginst the liblmctfy.so ?
<slangasek> seb128: shim was special, because it was a binary copy; shim-signed should've been done with proper bug refs, but no one called me on it until it was too late. :P  The next one will be better.
<slangasek> these were hardware enablement SRUs, effectively
<seb128> slangasek, k, it just looks weird in the sru report page, the sru team has been good about enforcing the requirement to have a bug linked with update otherwise ;-)
<slangasek> seb128: there was a global SRU bug with a test case for all of them, it just couldn't be included retroactively in the shim changelog
<slangasek> so this covered shim, sbsigntool, shim-signed, gnu-efi
<seb128> k
<slangasek> in the future, we should only need shim + shim-signed; binary copies (again) for shim, and shim-signed for the SRU tracking
<slangasek> also, there seem to be several other packages in the SRU queue with no bug refs, heh.  (plasma-nm?  xserver-xorg-video-savage?)
<seb128> slangasek, those should probably be rejected
<slangasek> seb128: indicator-messages in quantal was yours, it unfortunately had wrong bug syntax in the changelog... do you want to fix that?
<seb128> slangasek, quantal...
<seb128> slangasek, let me have a look
<seb128> shrug, we have SRUs hanging there for a year :/
<slangasek> well, yes... too many uploads, not enough verification, it's the classic story
<seb128> slangasek, to be fair I think we can just bankruptcy for quantal and just drop everything
<seb128> +declare
<slangasek> yeah, we should probably clean up the quantal queue
<seb128> slangasek, some of the precise and raring items can probably be kicked out as well
<seb128> it's a shame to see so much work/fixes going in the queue and never moving to updates though :/
<RAOF> Yes :(
#ubuntu-devel 2013-11-08
<pitti> Good morning
<xnox> pitti: i didn't go to sleep yet =/ i guess i should =)
<pitti> xnox: eek; yes indeed :)
<infinity> doko: Removing libmudflap0 made libmudflap0-4.4-dev, libmudflap0-4.6-dev, libmudflap0-4.7-dev uninstallible.
<cjwatson> barry: Any objection to me syncing python-wsgi-intercept from Debian over the top of our entirely Ubuntu-local wsgi-intercept source package?  debdiff is http://paste.ubuntu.com/6381487/
<seb128> jpds, hey, I saw you did some redshift uploads today, could you check https://bugs.launchpad.net/ubuntu/+source/redshift/+bug/868904 (it's in the sponsoring queue)?
<ubottu> Ubuntu bug 868904 in Redshift "Redshift fails to start with session due to geoclue failure" [High,Confirmed]
<jpds> seb128: Oh, that'd be marrusl's patch.
<jpds> seb128: Yeah, I'll add that in.
<seb128> jamespage, hey, could you look at https://bugs.launchpad.net/horizon/+bug/981269? you wrote on it a while ago saying you would handle it and unsubscribed sponsors, it's back in the sponsoring queue ... is that still on your list?
<ubottu> Ubuntu bug 981269 in horizon (Ubuntu Precise) "instance_type is still set as a property value of "none" even when flavors cannot be retrieved" [Medium,In progress]
<seb128> jpds, thanks
<seb128> slangasek, xnox, infinity, cjwatson: hey, is there any chance you guys could look at the sponsoring queue a bit? The red items are mostly stuff desktop doesn't feel competent enough to review (sysvinit, debian-installed, efitbootmgr, acpi-support, partman-base, ...)
<seb128> smoser, jamespage: same for server stuff, you guys have horizon/cloud-init/mysql stuff in there
<cjwatson> The partman-base one is probably mine, I'll try to look today
<seb128> cjwatson, thanks
<cjwatson> Part of a gigantic bug of doom
<seb128> cjwatson, xnox, https://code.launchpad.net/~srwarren/debian-installer/tegra/+merge/175967 ... do you have any recommendation on who would be right for review?
<mdeslaur> cjwatson: FYI, I'm going to release an openssh security update for saucy today for http://www.openssh.com/txt/gcmrekey.adv
<xnox> seb128: i'd say infinity
<seb128> infinity, ^? ;-)
<seb128> xnox, thanks
<mdeslaur> cjwatson: do you want me to do the trusty upload also, or shall I wait?
<brainwash> pitti: just curious, wouldn't it be possible to push your systemd-shim package into proposed? it fixes the issue for most users already
<barry> cjwatson: go for it!
<cjwatson> seb128: yeah, that's an infinity one
<cjwatson> mdeslaur: go ahead; I was just in the process of chasing up http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722970 so I can do the update to 6.3 ...
<ubottu> Debian bug 722970 in fail2ban "fail2ban: adapt to OpenSSH 6.3" [Important,Open]
<rbasak> seb128: jamespage is at ODS this week.
<cjwatson> barry: done, thanks
<mdeslaur> cjwatson: thanks...oh, you might want to update to 6.4 :)
<seb128> cjwatson, thanks
<seb128> rbasak, ok, thanks
<cjwatson> mdeslaur: well, either one :)
<cjwatson> need to avoid the regression in fail2ban either way
<seb128> slangasek, bdrung: how do we move forward on https://code.launchpad.net/~vorlon/ubuntu-packaging-guide/dont-recommend-packaging-dev/+merge/192244 (that's in the sponsoring queue ... should it be there, or should we mark it Work in progress to get it out of the queue? (seems it's a discussion between concerned parties rather a sponsoring request)
<bdrung> seb128: i think we should raise it to the wider audience or we should adjust the text to reflect that _some_ developers prefer to use packaging-dev and others selective installations of tools
<seb128> bdrung, seems like moving the discussion to ubuntu-devel@ could be a good idea there?
<bdrung> seb128: yes
<seb128> xnox, do you need sponsoring for https://code.launchpad.net/~xnox/ubuntu-dev-tools/fix-series-alias-lookups/+merge/191700 ? can't you just upload?
<xnox> seb128: i need code review, sensibility check, et al. I'm not "ubuntu-dev-tools" upstream.
<seb128> xnox, who is upstream for those?
<xnox> seb128: and i think it got rejected on irc, setting the status appropriately.
<seb128> xnox, thanks
<xnox> seb128: well: who-uploads ubuntu-dev-tools
<xnox> seb128: mostly bdrung
<xnox> seb128: in general if a core-dev requests code-review, there are $reasons =)
<seb128> xnox, yeah, but stuff sit in the sponsoring queue for months, it would be nice if people were a bit more active seeking for reviews when that happens
<psusi> according to the man page for dpkg-source, you have to specify --abort-on-upstream-changes to have it do so, but it seems to be on by default... why is this and how do you turn it off?
<psusi> ( and it isn't in debian/source/local-options... in fact there is no debian/source )
<xnox> psusi: typically i add files to ignore which are modified/regenerated at build time. Or add them to debian/clean, such that they are always removed.
<xnox> psusi: are you sure it's the only warning? maybe there are errors, such as unrepresentable changes in diff.
<xnox> psusi: please paste full error.
<psusi> that's the one
<psusi> I'm trying to rebuild the source package from the debian git repo for util-linux... let me get it up again
<xnox> psusi: git repository is not a valid source package format =)
<xnox> psusi: thus i'm not sure why you think "dpkg-source manpage" is at fault here ;-)
<psusi> xnox: because this is how lamont maintains the package... debianised in the git repo
<psusi> so you must be able to build the source package from there but it seems to complain that there have been upstream changes
<xnox> psusi: locally I have source/format "1.0" defined in util-linux package. So i'd guess you have unrepresentable changes in your tree somehow.
<psusi> well yea, that's intentional
<psusi> ohh I see, that's just a warning... the real error is the unrepresentable changes... hrm...
<lamont> psusi: git clone, and then debian/rules autofiles; debuild "$@"
<psusi> pfft.. it's trying to include the .git direcotry
<lamont> debuild -I.git
<xnox> lamont: i think the changelog is dated. As 2.19 tags are merged, yet changelog is still at 2.17.
<lamont> xnox: ON WHAT BRANCH
 * xnox tried fetching a tarball matching the changelog, how naive
<lamont> xnox: master is so totally irrelevant to anything
<xnox> lamont: ok. It's just what $ debcheckout util-linux
<xnox> gave me.
<psusi> lamont: would be nice to delete it then and set the HEAD to something sane ;)
<lamont> debcheckout... I can sort of tell what that command is going to try based on the name...
<xnox> lamont: as per debian policy Vcs-git should point to packaging repository, there is no syntax agreed on specifying packaging brach, thus it is expected for HEAD to point to something packaging-like. =)
<lamont> xnox: that makes sense, sort of
<xnox> lamont: anyway, i'll go away and do my thing. But you certainly placed enough hoops =)))) to make sure that one knows what they are doing, when touching it ;-)
<xnox> which is good =)
<lamont> git branch -l -a <-- pretty much tells the tale
<psusi> debuild -I.git is not working, it's still trying to include .git
<xnox> lamont: is the remote repository up to date? git tag --list | grep v2.20, gives me nothing.
<xnox> lamont: yet you did upload 2.20.1-5
<psusi> the git url in the control file is also wrong ;)
<psusi> seems debian migrated the git repo and the web browser link auto forwards you
<psusi> the correct url is now git://anonscm.debian.org/users/lamont/util-linux.git
<xnox> psusi: right, I see. yeah, now i get v2.21 and v2.20 et al.
<lamont> clearly, benevolent neglect is failing here.
<cjwatson> Ooh, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725767
<ubottu> Debian bug 725767 in ftp.debian.org "RM: dbs -- ROM; deprecated, superseded by the `3.0 (quilt)' source format" [Normal,Open]
<cjwatson> And it's safely removable from Ubuntu too
<xnox> it's the end of an era.
<cjwatson> slangasek: If you managed to find time to merge isdnutils, we could remove automake1.7 and the kitten quotient would increase
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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: mdeslaur
<fishor> hello devs. are there any way to connect hardware database with bug reports in launchpad? I working on atheros ath9k-htc firmware and it is hard to find related bugs. Mostly they are reported per factory name, not per driver or related chip
<sladen> fishor: try ogra_, who used to look after it a (long, long) time agin
<sladen> ago
<sladen> fishor: ogra_ might be able to tell you who took over the baton
<fishor> ogra_, ping
<fishor> sladen, "took over the baton"?
<fishor> sladen, do you means this functionality or this hardware?
<ogra_> sladen, fishor i have had nothing to do with the hardware database in 4 years or so ...
<ogra_> i only wrote the initial stuff for it about 8 years ago
<ogra_> afaik it is called checkbox today ... and there should be a LP team ...
<bdmurray> slangasek: regarding bug 1193509 apport-checkreports does kind of print the crash file name
<ubottu> bug 1193509 in apport (Ubuntu) "invalid problem report" [Undecided,New] https://launchpad.net/bugs/1193509
<fishor> ogra_, how about custom search with email notification?
<cjwatson> IIRC the old hwdb is scheduled for removal from LP
<ogra_> yeah
<ogra_> its dead since ages
<slangasek> bdmurray: ah, so we could check that $MATCH is in the list?
<ogra_> fishor, i dont know anything about checkbox or whatever the new hwdb is (if there is even any)
<bdmurray> slangasek: well its a truncation of the filename - print(r.split('.')[0].split('_')[-1])
<bdmurray> but that could probably be fixed
<fishor> ogra_, are there any good way to help finding bugs related to some chip or project?  For example "TP-Link TL-WN821N" and "TP-Link TL-WN822N" and so on ... may have differiert  HW insight
<slangasek> bdmurray: or we could do the same truncation on $MATCH for matching purposes, maybe?  but yeah, that seems like a good approach
<fishor> mostly they are never reported upstream
<fishor> since i work on this HW i would like to find some one who can report enough information.
<bdmurray> fishor: if this is something collected by apport when bugs are reported you might find it in bug descriptions or probably in attachments of bugs reported by apport.  You could then log for bug reports with this information.
<bdmurray> s/log/look/
<fishor> for now i just take a list from wikidevi and search for device names,
<bdmurray> slangasek: okay thanks
<fishor> bdmurray, first i need to find related bugs - it is already problematic
<fishor> then, apport usually do not provide information i need
<fishor> we know there is some crasher in our fimware, it seems to be related to some spesial conditions or access points, but till now, no one provided information we need
<slangasek> cjwatson: blah, how did I ever become TIL for isdnutils
<fishor> is it possible to extend apport or ubuntu-bug, to help gether wireless related information?
<cjwatson> slangasek: ... or get somebody in Germany (who therefore cares) to do it :-)
<slangasek> oh, I see how, I multiarcheded it
<bdmurray> fishor: apport when used to report a bug about the linux package collects lsusb information - this is a usb device right?
<fishor> yes
<bdmurray> so you could find people with this hardware if that's what you want to do
<fishor> uff, i just found the reason why it was not enough results with ath9k_htc. For some reason they are reported as ath9k_usb
<fishor> bdmurray,  here is one example, Bug #1049383  it is still imposible to get needed information :(
<ubottu> bug 1049383 in Linux "ath9k_usb: TL-WN821N v3 (AR7010+9287) Connection drops" [High,Confirmed] https://launchpad.net/bugs/1049383
<fishor> but is is probably not new for you :)
<slangasek> cjwatson: isdnutils hasn't been merged with Debian since feisty; this is going to take a while
<bdmurray> fishor: you might look at bugs reported about network-manager by apport as that would contain some of the wireless information you asked for in comment #7
<fishor> bdmurray,  suddenly there is no results for network-manager + ar9271 or ar7010, nor ath9k_htc or usb
<fishor> may be there is any
<bdmurray> Did you also check expired bugs?
<fishor> bdmurray, no results. but thank you for the tip
<hyperair> so upower -d shows can-suspend: no, but pm-is-supported --suspend shows that it is supported (exit code 0) and pm-suspend does work.
<hyperair> what gives?
<dave_>  
<hyperair> ?
<seb128> bdmurray, hey, are you (or somebody else in foundations) looking at debugging https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1024590? it's ranked 1 in e.u.c daily issues now that the hud and some other ones got resolved
<ubottu> Ubuntu bug 1024590 in update-manager (Ubuntu Saucy) "update-manager crashed with AttributeError in _on_download_changed(): 'NoneType' object has no attribute 'get_value'" [Medium,Confirmed]
<seb128> in fact update-manager has the 1 and 3 (and 2 is fixed so going to drop in the list)
<seb128> dobey, hey, are you looking at the s-c issues on e.u.c? It's having the 7-8-12-17 entries there
<seb128> ev, ^ 7-8 are failed retracing, anything we could do to have a that fixed? (e.g who has access to the e.u.c retracers to debug retracing issues?)
<bdmurray> seb128: I got as far as I could with bug 1024590 - could use some help from glatzor or mvo...
<ubottu> bug 1024590 in update-manager (Ubuntu Saucy) "update-manager crashed with AttributeError in _on_download_changed(): 'NoneType' object has no attribute 'get_value'" [Medium,Confirmed] https://launchpad.net/bugs/1024590
<dobey> seb128: the failed retrace ones are the webkit2 issue
<seb128> bdmurray, I tried to ping mvo this morning without success
<seb128> dobey, I doubt it, there is no webkit in the filenames
<dobey> seb128: the partial trace that is there includes cairo, which is where the webkit crash is happening
<seb128> shrug
<seb128> dobey, I opened an upstream bug on webkit but nobody replied ... did you get any luck trying to debug it?
<dobey> and i can't view the list of crashes on errors.ubuntu.com, unless i select a specific package so the 7-8-12-17 numbers mean nothing to me
<dobey> seb128: no i don't have time to try and debug webkit
<seb128> dobey, e.u.c doesn't work for you? (you say you can't see the list)
<seb128> https://errors.ubuntu.com/problem/eb9f7ebe2cb2dbf7d79986d38e2d000bb4bfaf04
<seb128> https://errors.ubuntu.com/problem/ddf3377b6988d948653e94fa421be8d713a624fc
<dobey> seb128: if i tell it to display all binary packages it just says "No data to display"
<seb128> https://errors.ubuntu.com/problem/94f7beb32c9a9172de3f9281691510762d655d47
<seb128> https://errors.ubuntu.com/problem/8a013246d3c6a42c90701932a3a8d4dfde51af89
<dobey> seb128: if i select only software-center, it displays only software-center
<seb128> dobey, what if you load https://errors.ubuntu.com/?release=Ubuntu%2013.10&period=day ?
<dobey> that seems to have loaded
<seb128> but the table is empty?
<dobey> not on that link, no
<dobey> although the numbers don't exactly line up with the ones you mentioned
<seb128> weird, dunno about that
<dobey> https://errors.ubuntu.com/problem/8a013246d3c6a42c90701932a3a8d4dfde51af89 looks like a bug in libmenu?
<seb128> but yeah, changing the combo doesn't always work
<seb128> could be
<dobey> or gnome-menus or whatever it's called
<bdrung> xnox, seb128: everyone can commit changes to ubuntu-dev-tools, but only a few developers do the upload to debian.
<bdrung> xnox, seb128: re the sponsoring request: i am not that familiar with this code segment. so the requested change could be what we want. a test case would be nice.
<slangasek> cjwatson: wow, the isdnutils merge is mind-bogglingly bad, somewhere along the way someone added a dpatch build-dep to the package in Ubuntu :p
<stgraber> slangasek: do we actually have any remotely useful delta on that one?
<slangasek> stgraber: how can I know the answer to that before merging it? ;)
<stgraber> slangasek: by reading the very well maintained and readable changelog? :)
<tumbleweed> does hardware supported by that package still exist?
<slangasek> heh
<stgraber> tumbleweed: I'm pretty sure I still have an ISDN PCI card somewhere, not that I've used it in the last decade ;)
<slangasek> stgraber: there's some stuff, it may be mostly merged into Debian but it's different enough I can't be sure yet
<infinity> slangasek: I assume you're tearing out the dpatch bits as you merge?
<slangasek> "tearing out" would be too gentle
<infinity> I'm really not okay with this Midway system being so much faster than my old PPC machine.
<infinity> On the one hand, it's ten years newer.  On the other hand, it's ARM.  It's not allowed to be fast.
<slangasek> on the gripping hand, oh no it's an ARM with three hands
<infinity> SO MANY HANDS.
<stgraber> infinity: oh, we actually have a midway system somewhere now?
<infinity> stgraber: OEM has a chassis with some cards.  I used it for the d-i enablement a few months ago, and I'm using it right now for glibc test building.
<stgraber> nice, any of you tried running VMs on that stuff?
<infinity> That's still a WIP, I believe.
<infinity> Though the goal is to ship 14.04 with a sane A15 KVM and libvirt solution, I think.
<stgraber> would be kind of nice if we could get working openstack on A15 (and maybe A57?) hardware, having a few of those in canonistack and buildstack would solve our current porter and buildd situation
<infinity> stgraber: Our buildd situation is great (except for PPAs).
<infinity> stgraber: But yeah, my plan for builders is to skip from our A9s to A57s, and do some PPA virt fanciness there when we have 'em.
<stgraber> infinity: btw, how do those calxeda box boot? Should I add some code to my d-i branch to spit out something they can actually boot from?
<infinity> stgraber: I'm not sure I can justify the budget to upgrade the A9s to A15s.
<hallyn_> tjaalton: sadly, Xspice is giving me segv :(  will have to try under debian ...
<infinity> stgraber: They boot raw vmlinuz/initrd.gz, the one pooped out in the base generic/ directory works fine.
<stgraber> infinity: yeah, doesn't seem worth it, the ton of A9 we have currently clearly is enough to deal with any distro workload. The qemu based buildds kind of suck but they shouldn't be getting any worse and aren't on the critical path since we can turn on devirt for distro use, so waiting for A57 based server seems perfectly reasonable.
<stgraber> infinity: ah good, so they have their bootloader and config built into some kind of onboard chip?
<infinity> stgraber: Yeah, u-boot's in firmware, and so is the DTB.
<infinity> stgraber: Would be a weird chicken-and-egg issue to say "sure, you can pxeboot this, but only after you insert 24 SD cards with u-boot on them".
<infinity> (viable for a Panda, laughable for a server blade chassis)
<stgraber> sounds like a reasonable implementation. I guess they're using the stock u-boot pxe implementation which basically just parses a subset of pxelinux.cfg, grabs kernel and initrd, and then they pass the dtb to the kernel on top of that
<stgraber> infinity: finally managed to get a succesful build: https://www.stgraber.org/download/d-i/current/images/generic/
<stgraber> infinity: would be nice if you could test those .img.gz on your beagle and panda
<infinity> stgraber: Is that beagle image really xM-only?
<stgraber> infinity: the only dtb we have in our package says beagleboard-xm
<infinity> stgraber: Our current omap3 images boot on a few beagle models (and the one I have is an old c3)
<infinity> Of course, this could be a lie, and maybe our current omap3 images don't boot at all. ;)
<infinity> I'll try to test later today.
<stgraber> it very well could be that the xm dtb works fine on older models too, I try to keep the name in the d-i build in sync with the dtb though
<stgraber> hmm, looking at the result in my browser now, I think I'll move vmlinuz and initrd.gz to a "standalone" directory (better names are welcome) should be slightly less confusing to someone who doesn't know how things work on arm
<infinity> stgraber: Except that a ton of people rely on that structure. ;)
<infinity> (I don't mind breaking Panda, I do mind breaking production highbank setups)
<stgraber> infinity: well, I kinda broke the structure already when I dropped netboot/ from the path ;)
<stgraber> infinity: hmm, I guess I could keep vmlinuz and initrd.gz in netboot/ and dump the rest into a new board/ directory maybe?
<stgraber> that way URLs for highbank should still work
<infinity> Oh, you dropped netboot?  I didn't notice the path mangling...
<infinity> No netboot, cdrom, etc...
<stgraber> yeah, I dropped that level, but I'll re-introduce it now so that the path to vmlinuz and initrd.gz stays the same
<infinity> stgraber: Well, and you can't just drop the cdrom images... We use those.
<infinity> And they're different from the netboot ones.
<infinity> (Well, the initrd is)
<stgraber> infinity: what's using the cdrom ones? (not that I mind re-introducing them, I just couldn't think of anywhere we were actually using those)
<infinity> stgraber: We still produce server CDs for omap* (though, maybe we should stop).
<infinity> stgraber: But they're also convenient for someone else who wants to do the same.
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.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 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> infinity: building d-i again with cdrom builds back on, and the fs structure tweaked to be more conventional with the board images under netboot-boards (which should be clear enough that those are netboot images for particular boards)
<dobey> anyone know a good way to flash an ubuntu iso to a usb flash drive, in 13.10 that has udisks which apparently casuses usb-creator-gtk to segfault?
<mdeslaur> dobey: you can just use dd
<infinity> dobey: dd
<dobey> dd if=foo.iso of=/dev/sdg ?
<mdeslaur> dobey: yep
<infinity> dobey: Yeah.  And add a bs=4M or so, if you don't want it to take a year.
<dobey> thanks, that did work
<stgraber> infinity: new proposed structure: https://www.stgraber.org/download/d-i/current/images/generic/
<Noskcaj> pitti, Is there any chance i could get a testimonial for MOTU from you? https://wiki.ubuntu.com/Noskcaj/MOTU
<Noskcaj> (I'm not actually applying till next month, but i'll try and get the testimonials now
<ari-tczew> can you log-in on wiki.ubuntu.com ?
<Noskcaj> ari-tczew, The page isn't loading, but i think that's just my internet crashing
<Noskcaj> works fine, internet fixed
 * ari-tczew sees Please contact the server administrator, webmaster@ubuntu.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
<melodie> hello
<melodie> I have been told that the build method for the isos would have been changed for the Saucy version. If this is right, is there any available doc about it somewhere?
<slangasek> melodie: it hasn't; there was a rewrite to the tools, but that was a couple of cycles ago already, and available at lp:ubuntu-cdimage
<melodie> thanks slangasek
#ubuntu-devel 2013-11-09
<melodie> slangasek are you still around?
<slangasek> melodie: at least somewhat :)
<melodie> thanks
<melodie> maybe I should ask a private talk, won't take long, if you can give me just a few minutes
<melodie> ?
<slangasek> that's fine
<melodie> great!
<infinity> stgraber: Based on the vomit in dmesg on a system with linux-lts-saucy installed, I think https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1197484 needs SRUing to precise.
<ubottu> Ubuntu bug 1197484 in isc-dhcp (Ubuntu) "Connection requests to saucy server VMs from a hosts fail after fresh VM installs" [High,Fix released]
<Noskcaj> osgearth is stuck on a dependency wait that has never been satisfied. Could someone please force it to release? (which also can't build on ARM)
<rsalveti> pitti: so, the latest 204-5 systemd series update breaks the ubuntu touch init logic, because it replaces the upstream rules file for persistent-storage
<rsalveti> +	install -D --mode=644 debian/extra/rules/* \
<rsalveti> +		debian/udev/lib/udev/rules.d/
<rsalveti> from 204-5ubuntu1
<rsalveti> it replaces both 60-persistent-storage.rules and 80-drivers.rules, and as a consequence the init script logic can't find the partition name (either partname, partlabel, etc)
<rsalveti> ogra_: ^
<rsalveti> pitti: there are quite few other changes in the debian/extra rules file, so I'll not revert it and wait for your to review them
<ogra_> rsalveti, great, thanks for researching this on a weekend ... !
<ogra_> xnox, ^^^
<xnox> ogra_: yeah. well, wait for pitti =)
#ubuntu-devel 2013-11-10
<Azendale> how hard is to it get a new stable version of a package in trusty at this point?
<Azendale> I'm trying to make a ejabberd juju charm, and in the latest stable version they switch to the yaml format for the config file. So, if I use an older version, I'll probably need to take a couple of hours to build an Augeas lens that won't be of much help when the new stable version ends up in Ubuntu. I'm not in a rush to have the charm ready, I don't mind if it is only available on Trusty
<JanC> Azendale: probably depends on whether it's available in Debian
<Azendale> JanC: It looks like the package is also in debian, it looks like they have version 2.1.11-1, the ejabberd site says 13.10 is the latest stable version
<JanC> they changed version numbering?
<Azendale> JanC: It looks like it. http://www.ejabberd.im/ejabberd-13.10 says that "ejabberd 2.1.x support is discontinued" and mentions 13.03 and 13.06 as previous releases
<Azendale> JanC: So it would have to be updated in debian first I assume?
<JanC> that would be the easiest way, yes
<maxiaojun> http://packages.ubuntu.com should defaults to saucy now?
<tumbleweed> maxiaojun: I waved that at Rhonda, and she's fixed it
<pippo> salve
<jkitchen> obey
<fhf> Hi guys. Sorry to bother you but I have a problem with packaging python software. I follow this quide: http://developer.ubuntu.com/packaging/html/packaging-new-software.html and there is an error http://paste.ubuntu.com/6393308/ with setup.py: http://paste.ubuntu.com/6393305/ anyone know how to package it propertly?
<cjwatson> fhf: Looks like resources/fbmessenger.png doesn't exist.  Is the path written in setup.py wrong?
<fhf> cjwatson: its confusing becouse file is there already. I have tried moving and changing path in setup.py but without success ls -lR: http://paste.ubuntu.com/6393363/
<cjwatson> fhf: That's indeed confusing.  Unfortunately I don't have a lot of time right now as I need to pack, but perhaps if you put your source package so far up for download somewhere, somebody else would be able to download it, reproduce the failure, and figure out what's going on.
<cjwatson> (I suspect it will be reasonably easy for somebody experienced to sort out that way)
<fhf> cjwatson: I'm trying to pack fbmessenger from https://github.com/oconnor663/fbmessenger/
<cjwatson> Failing that you might try applying strace and see what file it's actually looking for and in what working directory
<cjwatson> Yeah, don't talk directly to me, I'm going now :)
<fhf> ok anyway thanks ;)
<fhf> join #ubuntu-pl-loco
<fhf> damn typo
<Noskcaj> When should automake 1.14 be ready for stuff to build against? A number of FTBFS packages need it
<slangasek> why would it not be ready now?
<Noskcaj> slangasek, A number of packages FTBFS because they say they need it. I assume it's something in autoreconf. i'll find an example
<Noskcaj> https://launchpadlibrarian.net/155725612/buildlog_ubuntu-trusty-i386.lbzip2_2.3-1_FAILEDTOBUILD.txt.gz
<slangasek> Noskcaj: that package has a buggy versioned dep on automake.
<slangasek> (it's missing an epoch, so *all* versions of automake satisfy it)
<Noskcaj> ok. Thanks for the info. I think i saw the issue elsewhere, but the same cause.
<Noskcaj> Can someone rebuild xfce4-whiskermenu-plugin on arm64? The chroot broke
#ubuntu-devel 2014-11-03
<quidnunc> How do I access packages merged from debian?
<JanC> define "access"
<pitti> Good morning
<pitti> infinity: denneed02 is unreachable (at least via apache) for about 3 days now; it's active and building in https://launchpad.net/builders though
<pitti> infinity: does apache need some prodding there? otherwise we'll lose ppc ddebs
<infinity> pitti: Erk, really?
 * infinity looks.
<infinity> pitti: So, it seems angry building wine, and has been for 17h.  But that doesn't account for the previous two days you say you couldn't reach it...
<pitti> infinity: well, I got a metric ton of cron warning mails; let me look when they started
<infinity> pitti: Should be reachable now?
<pitti> infinity: ok, only since yesterday, sorry
<pitti> infinity: confirmed, works again; thanks
 * pitti mops them up
<infinity> pitti: Do you have any prototype for how you plan to populate ddebs.u.c from the librarian once we make the switch?
<infinity> pitti: The time is drawing nearer, finally.
<pitti> infinity: no, I don't; if we have the ddebs in LP but need to do the publishing on ddebs.u.c with ddeb-retriever, this will once again mean some rewrite
<pitti> but at least it'll get massively simpler
<infinity> pitti: Well, we still want the apt-gettable archive, I think, and putting in a second publisher instance to create ddebs.u.c, while perhaps the ultimate goal, won't happen right away.
<infinity> pitti: But I think it should be as simple as walking all the Packages files, backtracking to the source:version tuple that produced the binaries, then gathering the ddebs from the API.
<pitti> right
<pitti> as opposed to now, where I have to do this crazy queueing, and try to match a ddeb to a release/pocket/component/source
<infinity> pitti: Really not sure how we'll manage the publishing with a real publisher thing, when all our current content isn't in LP.  Though, I guess the publisher doesn't actually ever remove files from disk that it doesn't know about.
<infinity> pitti: So, maybe we could just start publishing in the middle of your populated archive, and it would Just Work.
<infinity> (And we'd have to manually clean out pool when we retire old series')
<infinity> wgrant: Would that work?
<infinity> wgrant: I mean, assuming other things, like having a parallel publisher for ddebs will work at all. :P
<pitti> infinity: I think this will become incrementally easier over time; after a full release or so we can rebuild everything which hasn't been rebuilt since then, and then LP has a full set of ddebs to publish
<infinity> pitti: Sure, at some point, we can just decide the past doesn't matter, but that point isn't for a long time.
<infinity> pitti: Because trusty.
<pitti> unless we can import the current ddebs somehow?
<infinity> pitti: We've talked about that, and every "solution" seemed crazier than the last.
<wgrant> infinity: They also wouldn't be in indices...
<infinity> pitti: But it's not beyond the realm of possibility to staple the ddebs onto existing build records.
<wgrant> Yes it is.
<infinity> wgrant: No, not beyond the realm of "possibility", just also crazy, see above. :P
<pitti> well, otherwise we'll just have to wait until trusty goes away, and keep the ddeb-retriever thing until then
<infinity> pitti: We can ditch ddeb-retriever as soon as we can publish LP ddebs in the middle of your archive.
<wgrant> Well, no
<pitti> or that
<wgrant> It'll still have to sort of exist
<wgrant> Something has to download them from LP
<wgrant> It'll just be about 1000x less awful.
<infinity> wgrant: So, yeah, backscroll.
<wgrant> I'm currently trying to get my desktop to boot. Backscroll comes later :P
<infinity> wgrant: We started with "let's fix ddeb-retriever to pull from API backrefs to the librarian".
<infinity> wgrant: And then I moved on to "wait, a parallel publisher wouldn't in any way damage the files already on disk, cause it literally cares nothing for files it knows nothing about, so we COULD just publish ddebs in the middle of pitti's archive".
<infinity> wgrant: And skip ddeb-retriever entirely.
<infinity> wgrant: Assuming a parallel publisher is doable at all.
<wgrant> LP will not be able to publish ddebs.ubuntu.com without significant work.
<infinity> wgrant: Right, so that's a "next phase" thing, and a simpler ddeb-retriever is phase 1.
<wgrant> And anything LP publishes might have external ddebs in the pool, but they wouldn't be able to be in indices.
<pitti> the publishing is actually the most painful part, as it takes about 2 hours, or more than 24 if I remove the cache (which I need to do from time to time once publishing time hits the 6 h mark or so)
<infinity> pitti: Some of us have some experience that might be able to help speed that up.
<infinity> pitti: ddeb-retriever scares the poop out of me, but if we reduced it to the 20 lines or so probably required to parse Packages, backtrack, find API ref for ddebs, pull to disk, then it'll suddenly be something I'd be happy to contribute to. :P
<infinity> pitti: Perhaps we could prototype on a parallel miniddebs archive that's using a PPA w/ ddebs as its source.
<pitti> infinity: scares> heh, same; it's half of a soyuz implementation, and a really bad one
<infinity> Doing the backref hunting via lplib instead of direct SQL will probably be slow as heck, but I imagine that won't matter much if we're not averaging more than a few thousand files per run.
<pitti> yeah, that too
<pitti> and we have to do it once per every other hour or so
<infinity> Once per ftpmaster pulse, ideally.
<pitti> we can probably iterate over the builds since the last time, and keep track of when the last run happened
<infinity> When we get it working and proven-not-crap, we'll trigger it from the publisher.
<pitti> that should only iterate over the recent builds
<pitti> infinity: too slow
<wgrant> Trigger, not blokc.
<pitti> apt-ftparchive is excruciatingly slow
<infinity> ^
<infinity> pitti: It shouldn't be.  You're using it wrong. :)
<infinity> pitti: We'll fix that.
<wgrant> Particularly since you're not publishing sources.
<wgrant> Binary publishing is really quick when you have it set up right.
<infinity> pitti: Or, it's decided that ddebs aren't debs and it's not caching them properly, which would be a 1-char fix somewhere.
<wgrant> It only took us 7 years to get there, too.
<pitti> infinity: it does cache them in the big db; as I said, if I remove that it takes > 24 hours to run dpkg/tar on all of them
<infinity> Of course, ddebs are bigger than debs, and thus slower to hash, but whatever.  The fact that ddeb-retriever has otherwise slightly less work to do than frpmaster should balance that out.
<pitti> yeah, any hint how to make it faster would be greatly appreciated
<infinity> pitti: I'm confident we can find he bottlenecks and stomp them out.
<infinity> pitti: But let's start with prototyping the new/slim variant againt a ddeb-publishing PPA, and go from there.
<infinity> pitti: So I have a codebase to work with that doesn't make me want to stab my eyes out and mail them to Germany.
<pitti> heh
<pitti> (brb)
<infinity> wgrant: Do the trigger points in the publisher have knowledge of which pockets were dirty?
<infinity> wgrant: I'm guessing no, but that could be passed in the env, perhaps?
<wgrant> infinity: I think so.
<wgrant> But if not, we can tell them,
<infinity> Maybe not needed for this, I guess, I could just cmp old and new Packages before deciding who needs a-f love.
<infinity> But in general, might be handy to pass along if it's not.
<wgrant> Oh
<wgrant> X randomly started after 150 seconds.
<wgrant> I guess that... works.
<infinity> Is this your way of telling me not to reboot today?
<wgrant> I just upgraded my nvidia-plagued desktop to vivid
<wgrant> It's running nvidia-343 from xorg-edgers.
<wgrant> So it's a bit of a special case.
<infinity> Ahh.
<infinity> Right, I'm going to get an early night tonight and see if this strange feeling of enthusiasm carries forward to Monday morning.
<infinity> pitti: Let's revisit this in a week or two and see what we can come up with for a prototype that won't suck when the ddeb world improves.
<pitti> infinity: yeah; for that it would be good to actually have some ddebs somewhere in LP to try this on
<infinity> pitti: Easily done in a PPA, like I said.
<pitti> but I figure this will use something like getPackageUploads(created_since_date=last_run)
<pitti> and custom_type='raw-ddeb' or similar
<pitti> so that we only process the recent uploads, not the entire archive
<infinity> pitti: I'd rather have it match the Packages files we mirror from ftpmaster identically, so no need for date windowing.
<infinity> pitti: Rather, we'll just be processing deltas from last run to current.
<pitti> infinity: that's quite a lot more bookkeeping then, though?
<pitti> yes, we still need to match them up against the archive's Packages.gz of course
<infinity> pitti: Shouldn't be too bad.
<wgrant> pitti: ddebs aren't actually custom uploads. They have BPPHs, but they just don't hit disk.
<pitti> for now I think we can only rip out the wgetting of http://*.buildd/ and replace that with getPackageUploads(created_since_date=last_run)
<wgrant> So you'd basically want to look up the SPPHs that you have, call getBuiltBinaries(), and then filter to ddebs.
<pitti> I think that ridiculously involved matching against the archive's Packages.gz needs to stay
<pitti> wgrant: but still from getPackageUploads(created_since_date=)?
<wgrant> Or watch new entries in getPublishedBinaries, but I'm not sure how GC for that would work on your end.
<wgrant> Right, that could work too.
<wgrant> There are a few approaches, but it's not like raw-static-translations.
<pitti> I just can't query all packages in all releases all the time
<infinity> No, but we can keep local state.
<pitti> that's like three magnitudes too slow
<infinity> So if we walk Packages, then only query things we've never queried before, we're getting the delta.
<infinity> Then GC stuff that's no longer referenced.
<wgrant> Personally, I would watch the Packages files, and keep a local map of (source, version) -> [ddebs]
<infinity> Then run a-f with a file list generated from the above steps.
<wgrant> When you see a source version drop out of all the Packages files, you drop those ddebs.
<wgrant> When you see a new one appear, you query for which ddebs it should have and download them.
<infinity> wgrant: I think we just said more or less the same thing. :)
<pitti> wgrant: that's what ddeb-retriever more or less does
<wgrant> Probably. I wasn't listening to you :P
<infinity> Typical.
<infinity> Kids these days.
<pitti> it downloads all Packages.gz and builds a packagename -> pocket -> version -> arch -> component map (this takes some 20 mins already)
<wgrant> pitti: Right, except now you can ask LP for the map, rather than having to do the hilarious madness with guessing which ddeb filenames map to what after you download them from the backdoor :)
<wgrant> Hmm.
<wgrant> That really shouldn't take more than 5 seconds.
<wgrant> Unless germanium is secretly a 6502.
<wgrant> That would explain a lot, actually.
<infinity> germanium's decently speedy.
<pitti> and then match ddebs against that mapping
<pitti> I hope that can get massively simpler, if I can get the proper releases/versions/components etc. from LP
<wgrant> Anyway, we should indeed find an appropriately configured PPA and fix the temporary, short-term, 8 year solution to work for another 8 years :)
<pitti> right now, the downloaded tarballs tell me just about nothing
<pitti> heh
<wgrant> Right.
<wgrant> LP can get you the map from source -> ddebs, and we might even want to add a new API call or two to make that easier if it proves too slow.
<wgrant> No more guessing from tarball contents.
<wgrant> The main problem for you is working out which sets of ddebs you want.
<wgrant> And that should be easy to calculate from the Packages files.
<pitti> yes
<pitti> and then of course building the lists for a-f and calling that, which takes effing log (but is conceptually easy)
<infinity> Building the lists should be near instant if we do it right with some local intelligence and caching.
<infinity> a-f runs might be slower than peop, cause germanium's not actually as fast as I remember. :P
<infinity> But we'll work that out.  A big lock around the whole thing so it can take longer than ftpmaster and skip a run here and there should make it good enough.
<wgrant> a-f should take less than 15 seconds per DAS when configured correctly, I suspect.
<wgrant> Even on germanium.
<pitti> 42.5 MB/s read speed
<pitti> (on germanium's disk)
<wgrant> It's seek speed and a-f cache maintenance that's the bigger concern.
<pitti> yeah
<wgrant> Unless you keep your a-f cache clean, you are basically dead.
<wgrant> As we discovered 18 months ago.
<infinity> All tractable.
<pitti> wgrant: yeah, I don't know the secret recipe to do that
<infinity> As we discovered from the FEATURE CELSO IMPLEMENTED SIX YEARS AGO AND FORGOT TO TELL ANYONE ABOUT.
<wgrant> We have the power.
<pitti> wgrant: I just drop the db from time to time, take the "runs for 30 hours" hit, and go on
<infinity> Not that I'm bitter.
<wgrant> Heh
<wgrant> Yeah, that's what we used to do.
<pitti> 15.6 MB/s write speed on germanium
<pitti> that's really not great
<pitti> and that was a linear cp of an 843 MB file
<wgrant> Now we run a daily cronjob which removes files that no longer exist in the pool.
<pitti> so I don't know how much it sucks on random access
<wgrant> And keeps the cache snappy.
<infinity> wgrant: Actually just triggered on a timer from the publisher itself, but whatever.
<pitti> wgrant: you mean remove from the db?
<wgrant> pitti: Right.
<wgrant> So the DB doesn't grow without bound.
<wgrant> infinity: Well yeah, but effectively.
<infinity> Important difference, cause racing those caches with an external job could have dire consequences.
<infinity> Or just fail entirely if a-f actually uses proper BDB locking.
<infinity> Pick one.
<wgrant> Dire consequences are the spice of life.
<infinity> If germanium really is too slow for this, one might ask IS nicely to slap germanium's array on a newer machine.
<infinity> But I don't think it'll limit us when we get it set up right.
<wgrant> Agreed.
<infinity> Bed for realz.
<wgrant> Night.
<pitti> sleep well
<infinity> ... my Firefox just decided I'm Arabic.
<infinity> Oh, no.  Not Arabic.  But some language I don't read that goes right to left.
<infinity> Oh, yes.  Arabic indeed.
<infinity> So confused.
<pitti> mvo: guten Morgen
<pitti> mvo: do you know if there's a fix for apt's test suite regression with the new dpkg?
<mvo> pitti: I don't think so, did I miss a mail from autopkgtest?
<pitti> mvo: notifications aren't back on (will do with jibel today), so falling back to "pitti annoys people on IRC"
<pitti> mvo: https://jenkins.qa.ubuntu.com/job/vivid-adt-apt/?
<mvo> pitti: heh :) ok
<pitti> mvo: might be fixed in Debian git already, as dpkg has been there for a while
<mvo> pitti: right
<mvo> pitti: I will take care of it
<pitti> mvo: danke!
<pitti> utlemming: I tested http://cloud-images.ubuntu.com/vivid/20141031.4/ amd64, working well; thanks!
<pitti> utlemming: I suppose /current will appear once this gets cron'ed?
<seb128> Noskcaj, pitti: since that gsettings-desktop-schemas changed some default value, do we override for e.g "button-layout" in ubuntu-settings to avoid regressions/behaviour change on upgrade?
<seb128> same for "action-middle-click-titlebar"
<seb128> do we need override*
<pitti> mvo: "Jenkins Fixed - vivid-adt-apt 7" -- cheers!
<pitti> bonjour seb128
<seb128> pitti, salut, Ã§a va bien ?
<pitti> seb128: sorry, I didn't notice a change in the general desktop or control center
<pitti> what changed?
<seb128> pitti, did you restart unity? is middle click on the title bar still doing minimize?
<pitti> seb128: oui, alors j'ai me levÃ© Ã  3 h :/
<seb128> :-(
<pitti> I tried in a guest session and an existing user, but I didn't try title bar clicking; hang on
<pitti> seb128: that maximizes/unmaximizes a window; is that different than before?
<pitti> (not minimize)
<seb128> pitti, well, I just read the diff
<seb128> http://launchpadlibrarian.net/188976878/gsettings-desktop-schemas_3.12.2-0ubuntu1_3.14.1-1ubuntu1.diff.gz
<seb128>      <key name="button-layout" type="s">
<seb128> -      <default>':minimize,maximize,close'</default>
<seb128> +      <default>'appmenu:close'</default>
<seb128>      <key name="action-middle-click-titlebar"
<seb128>           enum="org.gnome.desktop.GDesktopTitlebarAction">
<seb128> -      <default>'lower'</default>
<seb128> +      <default>'none'</default>
<seb128> pitti, ^
<mvo> pitti: your welcome
<seb128> so it seems like it's going to create behaviour changes, we might need to add those back in our ubuntu-settings override
<pitti> seb128: yeah, but I figure the Ubuntu theme or so overrides this; I didn't check where that happens, just that it happens
<seb128> pitti, ok,I didn't get the update, it looks in theory that middle click on the wm decoration should stop minimizing after that update
<seb128> but maybe compiz has some override in some way
<seb128> I'm going to check later when I get the update
<LocutusOfBorg1> hi developers, have a nice week!
<cjwatson> pitti: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/archivepublisher/model/ftparchive.py cleanCaches has the magic you need.  It should be pretty easy to stitch that in right now, independent of any other work.
<pitti> cjwatson: thanks!
<roaksoax> /wi/win 9
<saladim> some help in understanding schroot and sbuild needed plz
<saladim> i always get errors using sbuild 'Permission denied', 'could not clean source directory' with sbuild
<saladim> have setup btrfs-snapshot schroot, to which i can login and do things
<xnox> mdeslaur: may i package gpgme to provide one library for gpg2 and one for gpg1, conflicting with each other? also what needs to be done to get gpg2 by default on the desktop?
<xnox> gtk3 pinentry?
<mdeslaur> xnox: I know nothing about gpgme, so I'm not the one to ask, sorry
<mdeslaur> xnox: as for gpg2, I thought the problem was that it required an agent to work, and that was an issue
<xnox> mdeslaur: so was it not you who uploaded https://launchpad.net/ubuntu/+source/gpgme1.0/1.5.1-6ubuntu1 ?
<mdeslaur> xnox: yes, because i TIL for a security update
<mdeslaur> xnox: but I'm knowledgeable about it
<mdeslaur> s/I'm/I'm not/
<xnox> mdeslaur: we ship an agent by default - gnome-keyring one, which doesn't support everything that gpg2 needs however. we'd need a change of the default agent.
<xnox> mdeslaur: ok.
<mdeslaur> xnox: and we'd start an agent by default on the server?
<xnox> mdeslaur: on the server, gnupg fallsback to forking tty agent by itself.
<LocutusOfBorg1> Laney, did you upload -v3 for gdcm?
<LocutusOfBorg1> seems so, wonderful
<LocutusOfBorg1> thanks
<LocutusOfBorg1> thanks, I can ping you if it gets accepted (and published, to avoid other rebuilds)
<Laney> np
<pitti> hallyn, stgraber: hmm @ https://jenkins.qa.ubuntu.com/job/vivid-adt-lxc/7/ARCH=i386,label=adt/console --  did anything in cgmanager recently change wrt. the cgroup controllers?
<hallyn> pitti: yeah, cgmanager 0.33 has an updated api, which lxc uses - and uses wrongly.  there is a fix in upstream lxc, but i guess it needs to go into vivid
<pitti> there surely is bug 1346734, but we don't run systemd in vivid yet by default
<ubottu> bug 1346734 in systemd (Ubuntu) "Unprivileged LXC containers don't work under systemd" [Medium,Triaged] https://launchpad.net/bugs/1346734
<hallyn> no it's not that
<pitti> hallyn: ah, splendid; so I can chalk this off as "understood/handled"
<hallyn> it's that lxc tries to pass "all" to getpidcgroup
<pitti> hallyn: thanks
<hallyn> (which isn't suported)
<hallyn> np.
<hallyn> stgraber: ^ were you going to push a new lxc to vivid soonish?
<stgraber> pitti: I'll upload a fix to vivid once upstream Ci is back online and I confirm the fix works
<pitti> stgraber: merci
<brendand> bregma, omg are you going to implement https://bugs.launchpad.net/bugs/793482 ?
<ubottu> Ubuntu bug 793482 in Compiz "[WISHLIST] Windows in global expose (Super+W) should have title underneath" [Low,Triaged]
<bregma> brendand, hopefully at some point, but realistically "low" priority means we may suffer from the inevitable heat-death of the universe before we get to it
<brendand> bregma, well it's only taken 3 years to be triaged
<brendand> bregma, i can wait another 3 for it to be implemented :)
<brendand> (or do it myself, yes i know)
<brendand> patches welcome etc etc
<bregma> brendand, I'm sure you can just whip something up in your spare time?
<brendand> bregma, actually if i could get a hint or two about where to look...
<hallyn> stgraber: pitti: I went ahead and pushed lxc with the attach regression fixed to vivid, as that's pretty high prio
<bregma> brendand, I'd start in the Compiz source at plugins/expo/src/expo.cpp
<pitti> hallyn: ah, great, thanks
<brendand> bregma, and does that already have some visibility to the window objects (note i know nothing about compiz)
<brendand> ?
<brendand> bregma, so that i would just have to fish out the title of the window
<gQuigs> anyone know how to get the whoopsie identifier for a user from the CL?
<gQuigs> you can get it from the gui by going Dash -> Security & Privacy | Diagnostics -> Show Previous Error Reports
<gQuigs> (you can get it using C like this- https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1319160/comments/2)
<ubottu> Ubuntu bug 1319160 in sosreport (Ubuntu) "Collect /var/crash info or the users personal crash key" [Medium,Triaged]
<bregma> brendand, I can't be certain the name is available without digging down through the code -- at which point the fix would become trivial
<brendand> bregma, well you should find out soon :)
<xnox> gQuigs: there is dbus api to query it.
<xnox> gQuigs: gdbus call -y -d com.ubuntu.WhoopsiePreferences -o /com/ubuntu/WhoopsiePreferences -m com.ubuntu.WhoopsiePreferences.GetIdentifier
<xnox> or similar with dbus-send
<gQuigs> xnox: thanks!
<bdmurray> xnox: you'd talked about a casper patch for /var/crash the other day. Is that something you could do or give me an idea about?
<xnox> bdmurray: in a meeting atm. i'll respond later.
<bdmurray> xnox: okay, thanks
<xnox> bdmurray: i concluded that it works correctly already, by virtue that we had to disable whoopsie to get rid of the pop-ups.
<xnox> bdmurray: if it was working, simply because we are crashing all over the place and the upload daemon starts after the first crash, then indeed this needs to be fixed in casper.
<xnox> bdmurray: something simple like "touch /var/crash/.anyfile; rm /var/crash/.anyfile" after the overlay has been setup for the target.
<xnox> this will create an inode & /var/crash directory in the overlay and then inotify will work for the whoopsie daemon.
<xnox> bdmurray: i have not created a patch for this, but will be happy to review it if you write one.
<bdmurray> xnox: so the overlay work is already done we just need to "initialize" it so inotify will work?
<barry> @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: barry
<barry> @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:
#ubuntu-devel 2014-11-04
<sarnold> pitti: good morning; 1388962 mentions some systemd-logind errors in CurrentDmesg.txt, I'm curious if this one is for you :)
<pitti> Good morning
<pitti> sarnold: those messages are bug 1359439 and only cosmetical
<ubottu> bug 1359439 in systemd-shim (Ubuntu) "[ 7.287663] systemd-logind[1057]: Failed to start unit user@126.service: Unknown unit: user@126.service" [Undecided,Triaged] https://launchpad.net/bugs/1359439
<pitti> infinity, ScottK, wgrant: is https://wiki.ubuntu.com/ArchiveAdministration#Blacklisting still current? I thought a while ago we discussed blacklisting the packages with an LP API?
 * pitti wants to remove and blacklist init-select
<infinity> pitti: It's still current.
<pitti> infinity: thanks
<pitti> stgraber: for the resolvconf merge, do you think it's ok to drop the resolvconf/fixing-immutable debconf question now? it's a huge delta, and shoudl be obsolete after 12.04 as all the migration (making file un-immutable and move it around) was done in 12.04, right?
<pitti> stgraber: Debian's version now just spits out an error message which explains what to do if it still happens
<pitti> stgraber: but I'd consider this a "don't do that then" issue -- one doesn't randomly make runtime files immutable and can expect things to work still
<pitti> meh, this is a hideously complex merge
 * mgedmin wonders how often random websites offer 'chattr +i /etc/resolv.conf' as the "solution" to NetworkManager/resolvconf changing it all the time
<pitti> mgedmin: they did in the past, but in 12.04 we moved to resolvconf
<pitti> so /etc/resolv.conf is a symlink, and you can make it as immutable as you like
<mgedmin> oh, chattr doesn't follow symlinks?  neat
<infinity> Why would it?
<infinity> It makes the symlink immutable.
<infinity> It's just another file.
<seb128> bdmurray, ev, hey, do you know why https://errors.ubuntu.com/?release=Ubuntu%2014.10&package=file-roller&period=month lists only a libreoffice issue? changing to "week" makes it have file-roller ones, so there are reports and they should also be in the week view?
<seb128> https://errors.ubuntu.com/?release=Ubuntu%2014.10&package=file-roller&period=week
<seb128> those also are all failing to retrace, is there a known issue with utopic e.u.c retracers?
<pitti> stgraber: I now merged resolvconf, tested in a VM (with static /e/n/i) and my workstation (NM); tested upgrade, purge/reinstall
<pitti> stgraber: the delta got a bit smaller, fortunately Debian plans to drop the /etc/resolvconf/run bits after jessie (which is 95% of our delta)
<pitti> stgraber: do you want to review the merge before I upload? http://people.canonical.com/~pitti/tmp/resolvconf-merge/
<caribou> I'm working at merging libnss-ldap for a critical bug. I'm mostly done, except for one autoreconf.patch patch that fails for a few hunks
<caribou> any specific way to deal with such autoreconf issues ?
<caribou> LP: #1387594 btw
<ubottu> Launchpad bug 1387594 in libnss-ldap (Ubuntu Utopic) "init: symbol lookup error: /lib/powerpc64le-linux-gnu/libnss_ldap.so.2: undefined symbol: __libc_lock_lock" [Critical,Confirmed] https://launchpad.net/bugs/1387594
<geser> probably either redo the autoreconf (and update the patch file) or switch to dh-autoreconf (if possible)
<infinity> caribou: You shouldn't generally attempt to reapply autoreconf patches to different upstream versions, that way lies madness.
<infinity> caribou: Switching to dh-autoreconf is the best answer, if it works.  If it doesn't, fix-and-forward so it does, or redo the patch by hand.
<infinity> caribou: Though, given that it built on all arches in Debian, the autoreconf patch may not be needed?
<caribou> infinity: well I sort of get caught offguard with this autoreconf patch...
<caribou> infinity: I've been hacking at the merge & was almost done, rebuilt many times
<caribou> infinity: then I found out that that autoreconf.patch was not applied, then I got into madness :-/
<infinity> caribou: I'm pretty sure you can just drop it.
<caribou> infinity: it was my feeling. Then if, in your greatness of soul you agree to sponsor the merge, you will be able to confirm ;-)
<infinity>    * Apply patch from Peter Green to solve build failure on arm* kfreebsd*
<infinity>      (closes: #683011).
<infinity> caribou: That's fixing the same thing our patch was meant to fix.
<infinity> caribou: Which would also be fix-glibc-test-for-armel-gnueabi.patch, if you didn't already drop that.
<infinity> caribou: debian/patches/treat-all-debian-systems-like-linux.patch is the one that superseded our fix-glibc-test-for-armel-gnueabi.patch and autoreconf patch.
<infinity> caribou: I'm heading to bed (yes, really), but if you mail me about it, I can review and sponsor.  Looks like a disgusting sort of merge that I might have to re-do just to verify your result. :/
<caribou> infinity: I took note of everything so I'll do just that; thanks !
<infinity> caribou: Worth noting that fix-glibc-test-for-armel-gnueabi.patch was probably also subtly wrong for armhf, so we might want to SRU the patch swap when you SRU the other fix.
<mdeslaur> arges: I think the trusty update in bug 1382133 was skipped by mistake, and is ready to be release
<ubottu> bug 1382133 in evolution-data-server (Ubuntu Trusty) "Issue with servers with SSLv3 disabled due to Poodle " [Undecided,Fix committed] https://launchpad.net/bugs/1382133
<mdeslaur> released
<Laney> I only verified the second SRU today, so probably not
<arges> mdeslaur: i'll take a look at it
<Laney> but yeah, releasing appreciated
<arges> todays my review day, just working on some other reviews first
<mdeslaur> Laney: hrm? looks like someone verified it on 2014-10-21
<Laney> mdeslaur: the *second* sru, there are two uploads waiting to go in
<mdeslaur> Laney: oh! I see now
<arges> mdeslaur: Laney: ok looks good released into trusty-updates.
<Laney> thanks arges
<Laney> â¥
<mdeslaur> arges: thanks
<apachelogger> does the arch-indep change to amd64 also apply to utopic builds? and if not, how does one find out what architecture is used for arch-indep?
<infinity> apachelogger: It doesn't.  Out of curiosity, why would it matter?
<apachelogger> infinity: various kubuntu buildtime QA bits only run on arch-indep for some reason
<apachelogger> which was hardcoded as i386... so now things fall flat on the face ^^
<infinity> apachelogger: That sounds like a bug, not a feature. :P
<infinity> apachelogger: Packages should never assume an arch-indep arch.
<infinity> apachelogger: Do you have an example?
<apachelogger> it's not the packages, it's just additional stuff run before dh_builddeb to output data about the build
<apachelogger> infinity: lintian for example
<apachelogger> or actually
<infinity> apachelogger: By "packages", I meant "source packages".
<apachelogger> Riddell: where was it hardcoded anyway?
<Riddell> apachelogger: in the script which makes this little report http://qa.kubuntu.co.uk/kf5-status/build_status_5.4.0_vivid.html
 * apachelogger scratches head
<apachelogger> infinity: ok, so it seems I was wrong it's not the packages at all but the scripts evaluating the output generated by the build
<infinity> How is this going wrong for you?
<Riddell> it's not now that I updated the script
<apachelogger> Riddell: now it's wrong for utopic
<apachelogger> infinity: let me read the code, I am very unsure about the details
<infinity> Riddell: I guess what I was asking was why was it hardcoding an arch-indep arch, and could it be made smarter? :P
<infinity> Riddell: As in, why does it need to know at all?
<infinity> But yes, maybe seeing the script would be enlightening.
<Riddell> the /usr/share/pkg-kde-tools/qt-kde-team/3/debian-qt-kde.mk makefile which is what we use to build our packages only runs the bits which output list-missing on arch-indep it seems, dunno why
<apachelogger> I don't even see why
<apachelogger> post_binary: list-missing lintian
<apachelogger> ah different target, apparently post_binary-arch is what would be calle don !indep
<infinity> apachelogger: post-binary probably only gets run on full builds, on arch-dep builds, it's probably something like post-binary-arch
<infinity> apachelogger: Jinx.
<infinity> apachelogger: post_binary-arch is probably a dep of post_binary, though, so would be called in either case.
<apachelogger> infinity: yes
<apachelogger> so in fact lintian and list-missing are only run on arch-indep, not sure why that decision was made
<infinity> apachelogger: I doubt it was made on purpose.
<apachelogger> infinity: well, it's from debian pkg-kde so it might be to not waste time on the slow architectures
<infinity> apachelogger: Unless this is inherited from Debian, then the decision would have been made so that it only ran on developers' systems.
<infinity> apachelogger: Since arch:all is never built on buildds.
<apachelogger> I see, would make sense
<infinity> apachelogger: But they really need to fix that way of thinking in pkg-kde soon, since the old world order is going away. :P
<infinity> apachelogger: Anyhow, an Ubuntu delta that did your testing on all arches would seem sane to me.
<apachelogger> to be honest I think that would just make things more complicated
<apachelogger> 99% of the time we'd only care about the arch-indep architecture as it presents the superset of issues lintian/list-missing would report anyway
<infinity> Or just accept the status quo and make your scripts check for the right arch, I guess. :P
<infinity> apachelogger: I'd challenge your assertion, though.  It's amazingly common for people to make the "full" build work, and break the arch-only build.
<apachelogger> infinity: yeah, that's why I was asking how to figure out what the arch-indep arch is :P
<apachelogger> I'd rather avoid fiddling with series versions to decide which log to look at
<infinity> apachelogger: Assuming this is an lpapi script, you can use something like:
<infinity> (base)adconrad@cthulhu:~$ lp-shell
<infinity> E: ipython not available. Using normal python shell.
<infinity> Connected to LP service "production" with API version "1.0":
<infinity> Note: LP can be accessed through the "lp" object.
<infinity> >>> lp.distributions['ubuntu'].current_series.nominatedarchindep_link
<infinity> u'https://api.launchpad.net/1.0/ubuntu/vivid/amd64'
<apachelogger> that should work
<apachelogger> infinity: thanks :)
<infinity> apachelogger: Replacing current_series with a proper API lookup of the series you care about...
<infinity> apachelogger: Perhaps like so:
<infinity> >>> lp.distributions['ubuntu'].getSeries(name_or_version='utopic').nominatedarchindep_link
<infinity> u'https://api.launchpad.net/1.0/ubuntu/utopic/i386'
<infinity> >>> lp.distributions['ubuntu'].getSeries(name_or_version='vivid').nominatedarchindep_link
<infinity> u'https://api.launchpad.net/1.0/ubuntu/vivid/amd64'
<infinity> apachelogger: Or, to just return the arch string:
<infinity> >>> lp.distributions['ubuntu'].getSeries(name_or_version='vivid').nominatedarchindep.architecture_tag
<infinity> u'amd64'
<apachelogger> infinity: yeah, we iter through PPA entries using the api, so we should just be able to work our way to the archindep from there
<infinity> apachelogger: If you're iterating through builds, there will soon be a tag on each build to tell you if it was archindep or not.  That'll land this week.
<apachelogger> ah, cool beans, best fix it next week then I guess
<apachelogger> shadeslayer: ^ In case I forget, all tooling needs change to dynamically get archindep for builds instaed of hardcoding one
<infinity> apachelogger: For now, though, it's perfectly reasonable to just assume vivid=amd64, and *=i386.
<infinity> apachelogger: Which is the logic we'll be using to backfill the new DB column. :P
<infinity> (Well, minus some annoying bits we need to fix from vivid opening, but la la la)
<shadeslayer> apachelogger: ack
<infinity> apachelogger: On an academic note that kubuntu might not care about, but is interesting nonetheless, this also fills in one of the missing puzzle pieces for abritrary package-controlled arch-indep affinity.
<infinity> apachelogger: (Say, you want a source package to be able to say "I build an arch:all package, but it has to build on powerpc")
<infinity> arbitrary, too.  That's an oddly difficult word to type.
<Riddell> I do remember that being an issue for someone once
<infinity> Yeah, me. ;)
<infinity> Well, a few someones.
<infinity> But typically, it's when you want to ship firmware or a bootloader or something as a "payload" package that can be installed on all arches.
<infinity> We currently hack around it by cross-compiling a few such packages.
<infinity> But that's gross.
 * infinity heads to the store, wondering what combination of Vitamin C and cough syrup will lead to sleep and waking up feeling less sick.
<StevenK> infinity: LD50 minus one teaspoon? :-P
<infinity> StevenK: LD50 is for the weak, go 100 or go home.
<StevenK> infinity: But that fails your requirements, since it won't lead to sleep
<pitti> a rather long sleep..
<infinity> StevenK: Fine, 99.
<StevenK> Haha
<mdeslaur> infinity: the best stuff is labelled "Whisky"
<pitti> mdeslaur: oh, so the vitamime "C" expands to "Chivas Regal"?
<mdeslaur> pitti: hehe :)
<arges> mlankhorst: i see two mesa uploads in utopic... i'm assuming the old one is no longer needed?
<mlankhorst> yeah
<mlankhorst> figured doing .2 was just as much effort as verifying .1
<pitti> hallyn: cgmanager sets a release_agent, but right now we don't enable notify_on_release anywhere; does cgmanager itself depend on those somehow?
<pitti> hallyn: I'm looking into debian bug 756076 (logind sessions don't get cleaned up but stay in "Closing" forever)
<ubottu> Debian bug 756076 in systemd-shim "does not cleanup sessions when user logs out: No such interface 'org.freedesktop.systemd1.Scope'" [Grave,Open] http://bugs.debian.org/756076
<pitti> hallyn: systemd installs its own release handler there to tell it when a cgroup got cleaned up, then it cleans up the dangling sessions
<pitti> hallyn: and I wonder if systemd-shim can do that, or whether we need to actually call cgmanager's release agent (which we don't ATM)
<pitti> at least calling "sudo /run/cgmanager/agents/cgm-release-agent.systemd user.slice/user-1001.slice/session-c2.scope" currently has no effect as the cgroup itself is already gone, so one just gets a dbus error
<bdmurray> seb128: past month is calendar month not 30 days so the week view would include october stuff but the month view would not
<mdeslaur> barry: any idea why this is happening in vivid? the package names are obviously wrong: http://paste.ubuntu.com/8820356/
<barry> mdeslaur: there was a new dh-python uploaded to unstable recently.  this is curious:   * Suggest the right file name for dependency overrides (closes: 748296).  but otoh, it looks like it was just a doco change: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748296
<barry>  
<ubottu> Debian bug 748296 in dh-python "dh_python2 shouldn't suggest py3dist-override" [Minor,Fixed]
<barry> dhpy2
<barry> so that's not it
<barry> but i'll bet it's the dh-python upload
<mdeslaur> yeah, I'm diffing it to try and figure it out
<barry> mdeslaur: to be clear, you don't see that in utopic?
<mdeslaur> barry: nope, utopic works
<mdeslaur> barry: I think it's Add support for guessing dependencies from egg-info files (closes: 756378)
<mdeslaur> still looking
<barry> mdeslaur: sorry, trying to work on something else atm, but ping me if you find anything interesting
<mdeslaur> barry: yeah, my egg-info has stuff like Requires: gi.repository.GLib , but that's definitely not how any of the gi packages are called
<mdeslaur> barry: thanks, I'll let you know
<mlankhorst> arges: the changelog is correct, it's a copy back from vivid to utopic
<hallyn> pitti: if you configure logind.conf correctly, then systemd-shim will remove the cgroups
<pitti> hallyn: that happens by default already
<hallyn> if you leave it set to "abandon", then it will only remove the cgroup if all tasks are already gone
<pitti> hallyn: the thing that's missing is cleaning up logind sessions after logging out
<hallyn> if you set it to kill (wahtever it's called) it will forcibly kill al ltasks and remove the container
<hallyn> pitti: it's not missing, so this must be a bug.
<pitti> hallyn: right, but the cgroup is already gone, that's not hte problem
<hallyn> oh, you mean logind isn't told to forget about it?
<pitti> hallyn: the problem is that the cgroups don't have notify_on_release, and no callback which tells logind that those sessions are now gone
<pitti> hallyn: right, debian bug 756076
<ubottu> Debian bug 756076 in systemd-shim "does not cleanup sessions when user logs out" [Grave,Open] http://bugs.debian.org/756076
<hallyn> pitti: if you don't premount the cgroups, then notify_on_release will be set by cgmanager
<teward> anyone know what package provides udev rules?
<hallyn> but if the cgroups were premounte,d then cgmanager will not set it (and shouldn't)
<pitti> hallyn: in our default utopic it's not set
<arges> cjwatson: ^^ what is the policy with SRU changelogs for backports? mlankhorst had mesa with <version>ubuntu1 (vivid) then the next entry was <version>ubuntu0.1 (utopic) ... does it make sense to have this kinda changelog?
<arges> mlankhorst: can you post the changelog in pastebin really quick?
<mdeslaur> barry: filed 1389283
<hallyn> pitti: that's a bug
<hallyn> pls file against cgmanager
<pitti> hallyn: but anyway, even if it would set it, it would then call the cgm_release thing, which doesn't do what we need; so I primarily wondered if we'd ever need to use those for the "systemd" controller
<hallyn> what do you mean it doesnt' do what we need
<barry> mdeslaur: cool, thanks.  i'll forward that to p1otr
<mlankhorst> arges: sec
<pitti> hallyn: so the fact is, cgmanager *works*, the org.freedesktop.systemd1.Scope Abandon call now works and does clean up the cgroup (even without release_notify)
<pitti> hallyn: but that doesn't tell logind about it, so its sessions forever stay in state "closing" and it never removes dynamic ACLs
<hallyn> pitti: ok, that should be up to systemd-shim to do i guess
<pitti> hallyn: correct
<hallyn> oh, right.  ntify-on-release should NOT be set in utopic..  right
<hallyn> pitti: ok.  i assume that's some dbus magic?
<pitti> hallyn: but for that I need to use release_notify and plug in my own agent
<mlankhorst> arges: i dont have the exact log, so have this mockup instead. http://paste.debian.net/130248/
<hallyn> pitti: hold on, lemme switch rooms and get back to you
<pitti> hallyn: and my q is whether that's ok for hte "systemd" controller, or whether my own agent should additionally call cgm_release (I don't see what for, but cross-checking)
<mlankhorst> this has been how I did mesa updates all along, where they make sense
<barry> mdeslaur: over in #debian-python: <p1otr> barry: which package adds gi.repository.GLib egg-info?
<mdeslaur> barry: pasaffe (it's not in debian)
<barry> ack
<mdeslaur> barry: v
<mdeslaur> barry: https://launchpad.net/ubuntu/+source/pasaffe
<hallyn> pitti: so i'm not following.  Right now, iirc, when you log out, one and systemd-shim is installed, one of two things happens:
<hallyn> if you've set to abandon, then cgmanager will (for all cgroup controllers) try to remove the cgroup, then set notify_on_release if the remove failed
<hallyn> (so that the cgroup will be deleted when it becomes empty)
<hallyn> if you've set to kill, then it'll kill all tasks and rm the cgroup
<hallyn> it doe sit for name=systemd a swell as the others, since systemd is presumed not running
<hallyn> as yo usaid, systemd-shim should be telling logind to remove the session as well, if that's needed.  i 8thought* that simply replying to the Abandon msg from logind would do that
<pitti> hallyn: ok; I didn't test kill mode, just a normal logout (which doesn't leave anything behind, so the cgroup does get removed)
<pitti> hallyn: no, it's async
<pitti> hallyn: so roughly what happens:
<pitti> hallyn: logind is told to close a session (ReleaseSession "c1" or so)
<pitti> hallyn: then pid1 or shim picks that up, tells cgmanager to clean up etc.; this removes cgroups
<hallyn> (or sets notify-on-release if cgroup is not yet empty)
<pitti> hallyn: then, systemd sets notify_on_release and installs an agent which then sends the UnitRemoved session-c1.scope back to logind
<hallyn> ok
<pitti> hallyn: then logind removes the session, removes ACLs, etc.
<pitti> hallyn: and the last two lines are currently missing
<hallyn> yeah
<pitti> hallyn: so what I need to do in shim is enable notify_on_release and install my own agent
<pitti> which mimics what systemd as pid 1 would do
<hallyn> that's a problem
<hallyn> i don't recall - can you set an agent for a cgroup subtree?
<hallyn> or only for the whole hierarchy?
<pitti> hallyn: no, only from teh top
<pitti> hallyn: you need to enable notify_on_release per cgroup, but there's only one global (per controller) agent
<pitti> hallyn: so: you are saying that sometimes cgmanager needs its own handler
<pitti> hallyn: so if systemd-shim installs its logind callback handler, it could just chainload cgmanager's?
<hallyn> we don't know that every use of notify-on-release is going to be for such a rm, so i don't know that we can unconditionally have our release agent send that msg
<pitti> hallyn: s/chainload/call/
<pitti> hallyn: no no, I'm not going to tell cgmanager's agent about logind
<pitti> and I don't want to touch any controller except "systemd"
<hallyn> don't you need to do it for all controllers?
<hallyn> or doe slogind only need to be told about the one
<hallyn> you're making it sound like you would set that shim release agent only for a short time...  is that what you're thinking?
<pitti> hallyn: no, logind is only concerned about the systemd controller
<pitti> hallyn: hm, I think I need to set it for the entire lifetime of a session
<hallyn> pitti: ok, that's better
<hallyn> yeah i guess chainload is fine
<pitti> hallyn: so systemd-shim should get the current handler, install its own, and chainload the old
<pitti> hallyn: from my experiments calling it seems to be harmless if the cgroup is already gone
<pitti> (but it's not too hard to check this in advance either)
<pitti> if it causes error message spew or so
<hallyn> pitti: sounds good.  you can push that change to systemd-shim ?
<pitti> hallyn: yes, I'm working on it now (still need to figure out the details)
<pitti> hallyn: but I wanted to discuss the cgm release agent with you first
<caribou> infinity: sorry got pulled onto something else, I'll send the merge data your way tomorrow morning
<pitti> hallyn: it's a grave bug in Debian, so we better get that fixed ASAP for the freeze
<pitti> hallyn: I also fixed two other (simple) bugs in git already
<arges> mlankhorst: well feel free to re-upload, but I'll let another SRU member review as I'm not confortable accepting. thanks
<pitti> so with that one we should have a good release 9
<pitti> hallyn: thanks
<hallyn> pitti: why is it a grave bug?
<pitti> hallyn: mostly for the lingering ACLs, I suppose
<pitti> I wouldn't call it "grave" myself, but *shrug*, it should be fixed anyway
<hallyn> oh, on sound devices and such?
<hallyn> that makes sense
<hallyn> pitti: thanks much.
<pitti> hallyn: so the scenario would be something like 1. login locally, get ACLs, log out
<pitti> then 2. log in remotely, re-use the old permissions which you shouldn't have
<pitti> plus, the sessions pile up, so if you have a lot of logins, it's kind of a memleak
<hallyn> right.  i'm ok with claling that grave :)  thx
<arges> mlankhorst: one more thing bug 1386620, is this fixed in vivid/utopic for xorg-server?
<ubottu> bug 1386620 in xorg-server (Ubuntu Vivid) "re-enable rotation for the intel driver in optimus mode" [Critical,New] https://launchpad.net/bugs/1386620
<bdmurray> pitti: any news on bug 1370230?
<ubottu> bug 1370230 in Apport "apport-retrace has become slower" [High,Triaged] https://launchpad.net/bugs/1370230
<flexiondotorg> bregma, I've created a Compiz meta package for Ubuntu MATE. Which works a treat except I need to have the Window Decoration plugin enabled by default.
<flexiondotorg> bregma, Is there a way for me to enable that plugin at the system level without compiling a separate compiz-mate (for example) package?
<bregma> flexiondotorg, I'm surprised it doesn't work out of the box like Gnome-fallback does
<flexiondotorg> I am going to test again on a fresh install, but without Window Decoration is would seem that the gtk-decorator is not available.
<flexiondotorg> Therefore, no window controls.
<flexiondotorg> bregma, Is is possible to modify to Compiz configuration at a system level via a meta package?
<pitti> bdmurray: sorry, not yet; overloaded with other stuff ATM :(
<bregma> flexiondotorg, unfortunately I'm not sure, it's a compizconfig issue and I'm hoping there is a way for other reasons, but really I don't know ... Trevinho do you know^^?
<flexiondotorg> bregma, Just tested on a clean system. No window decorations by default in MATE.
<bregma> flexiondotorg, does MATE use gnome-session?
<flexiondotorg> bregma, No, it uses mate-session
<Riddell> mdeslaur: bug 1389296 for some ~ubuntu-security love
<ubottu> bug 1389296 in konversation (Ubuntu Vivid) "konversation: out-of-bounds read on a heap-allocated array" [Undecided,New] https://launchpad.net/bugs/1389296
<mdeslaur> Riddell: thanks!
<doko> cjwatson, plplot is merged
<Trevinho> flexiondotorg: decor plugin is enabled by default when using the standard profile
<Trevinho> flexiondotorg: however when accessing to an unity session, the plugin is removed using a migrationn script
<Trevinho> flexiondotorg: so, in general it should always be there, make sure that one of the migration scripts won't delete it
<Trevinho> or that you're using the proper profile (i.e. not the compiz ubuntu profile)
<flexiondotorg> Trevinho, Can I enable the standard profile via a meta package? For example, in gsettings or a config file.
<flexiondotorg> Trevinho, How can I determine which profile I have defaulted too?
<Trevinho> flexiondotorg: migration scripts can do that, or using COMPIZ_CONFIG_PROFILE variable
<flexiondotorg> I am a compiz nupty, but my users are really keen to have a easy way to enable compiz.
<Trevinho> flexiondotorg: by default ubuntu unity has that variable set as "ubuntu", and that profile is for the unity sesion
<Trevinho> yes, sure... in general in != unity sessions, the default compiz settings should be used
<Trevinho> like it happens in the flashback
<flexiondotorg> Trevinho, Thanks. What should the variable be for the standard profile? "Default"?
<Trevinho> flexiondotorg: you can just unset it
<flexiondotorg> Trevinho, OK. I'll do some testing later. I only have a VM available here and decor appears to trying to load but claims the is no compositor.
<flexiondotorg> I'll test on real hardware later ð
<Trevinho> flexiondotorg: one thing you can also do is provinding a compizconfig profile, in /etc/compizconfig/mate.ini such as the one we ship with unity
<Trevinho> flexiondotorg: this is our unity.ini http://paste.ubuntu.com/8821774/
<Trevinho> but you can tune it more
<flexiondotorg> Trevinho, Oooh. Does the name of the file need to match the session name?
<flexiondotorg> I'll give that a test.
<Trevinho> flexiondotorg: no, that's defined inside /etc/compizconfig/config
<Trevinho> flexiondotorg: something you might look at is also /usr/share/session-migration/scripts/00_remove_unityshell_in_gnome_session.py
<Trevinho> and other migration scripts like that
<flexiondotorg> Trevinho, This is all very useful. Thanks.
<sarnold> pitti: thanks :)
<mlankhorst> arges: I'd have to check, but the xxv-intel driver works at least
<cyphermox> xnox: hey
<cyphermox> xnox: mind if I merge ppp?
<xnox> cyphermox: go for it.
<xnox> cyphermox: it's actually in a dire need of a merge I believe, and I was hoping to not touch it =)
<cyphermox> ahah, indeed it is
<Unit193> cyphermox: Still looking into NM?
<cyphermox> Unit193: I am, currently building it
<Unit193> Fantastic, thanks for letting me know!  Some Xubuntu docs will need modified.
<cyphermox> it's also why I asked about ppp; debian has 2.4.6 in the build-deps for NM
<cyphermox> Unit193: ah?
<Unit193> cyphermox: Yeah. nm-tool is mentioned.  Ah, I see.
<cyphermox> oh, yeah
<cyphermox> nm-tool no longer exists
<cyphermox> you can use nmcli / nmtui instead, one is the straight CLI interface, the other is a curses-based interface
<Unit193> Indeed, and I'm personally looking forward to nmtui. :P  But yeah, that's why I asked, know it's missing.
<cyphermox> the equivalent of nm-tool is 'nmcli dev list', in case you're wondering
<Unit193> Fancy that, thanks.
<cyphermox> np
<cyphermox> if you want to help testing, I'll ping you later when I'm done with the merge
<Unit193> Sure, though it wouldn't be wireless, those are still on connman/utopic.
#ubuntu-devel 2014-11-05
<xnox> stgraber: is lxd on github / linuxcontainers.org yet?
<xnox> =)
<stgraber> xnox: github.com/lxc/lxd all 0 bytes of it :)
<xnox> stgraber: =) cool.
<xnox> stgraber: pleaora of people are talking about it, sounds exiting and people are undecided whether it's an NIH or indeed something cooler than docker.
<xnox> stgraber: however with lack of public source code for inspection it's hard to tell what it is.
<stgraber> well, currently there's very little code available, we've got a python prototype and a Go prototype which each do different things. The plan is to have the Go one be split into pieces and contributed upstream through the usual review process bit by bit rather than have a single massive code dump that nobody can seriously review.
<xnox> stgraber: i take it, the go code is/was not written by you?!
<hallyn> chuckle
<hallyn> xnox: I wrote some of it.
<xnox> hallyn: i did bits of gocode for phablet gogotools. How do you like golang so far?
<hallyn> xnox: i have issues with the dogmatic refusal to allow me to control goroutines.
<hallyn> aside from that, it's a lot of fun
<hallyn> i love the multile return values
<hallyn> i appreciate the way you build 'classes', basically feels like the way the vfs in the kernel does it
<xnox> hallyn: i don't think i've used goroutines correctly (especially asynchronously feeding a channel and synchronising that / calling golang select across them and all that)
<xnox> i don't quite like how error handling is done, but i guess that will not change (essentially everything must return an error as one of the multiple return values, and everything must check/bubble it up)
<hallyn> right, my problem was i was doing io.Copy() inside goroutines to pass data from console to a socket, then on the other end from a socket to a pty which was hooked to a container using attach,
<hallyn> and my problem was that i couldn't find a good way to select(0 so that i  could add a second channel with which to interrupt
<hallyn> but it worked out ok with how the attach happens through the lxc go bindings.
<hallyn> so yeah, i like it :)
<hallyn> better than i thought i would
<hallyn> anyway, it's 1:30am here and i should really get to bed - gnight
<xnox> night.
<RAOF> !regression-alert
<ubottu> bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<RAOF> openjdk security update - https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1389493
<ubottu> Ubuntu bug 1389493 in openjdk-7 (Ubuntu) "Package dropped pulse-java.jar, breaking some development environments" [High,New]
<cyphermox> xnox: I see now why you were happy not to touch ppp :)
<infinity> doko: ^
<slangasek> RAOF: I'm puzzled by that description.  Projects show as broken in eclipse even if they don't use pulse-java.jar?
<RAOF> slangasek: Apparently eclipse keeps a list of all the files in the JRE it's got registered and complains if any of them disappear.
<slangasek> RAOF: fwiw my understanding from watching from the sidelines was that pulse-java.jar had been superseded by icedtea-sound.jar; I'm not sure how it's anything other than a bug in eclipse that it behaves this way though
<RAOF> slangasek: I agree that it does seem to be profoundly stupid behaviour from Eclipse.
<slangasek> (of course, we may be stuck working around it in openjdk-7, but I'd like to know why eclipse does this)
<slangasek> anyway, no quick rollbacks on this one; I'll assign it to doko for further investigation
<RAOF> I have no idea why Eclipse would choose to do this, but my knowledge of Java development is pretty much restricted to âthere was a dude on IRC complaining that we broke Eclipseâ.
<RAOF> Yeah, that was my assessment of the situation.
<pitti> Good morning
<MasterPiece> pitti, moin :)
<pitti> infinity: https://jenkins.qa.ubuntu.com/job/vivid-adt-glibc/7/ARCH=i386,label=adt/console -> looks like fallout from new dpkg?
<pitti> dpkg-source: error: binary package stanza libc-bin is using an obsolete Build-Profiles field syntax
<Tribaal> guys, how can I help with https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1386455 ? It is a little scary that some potentially serious vulnerabilities have been addressed and not yet packaged...
<ubottu> Ubuntu bug 1386455 in chromium-browser (Ubuntu) "Chromium 37 has 159 known security issues" [Undecided,Confirmed]
<Mirv> would some core dev be available to review (ack) bregma's first vivid compiz release packaging changes? seems like ok cleanup https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141104-0ubuntu1.diff
<Mirv> compiz-gnome seemingly got python dependencies since it already had the migration scripts in python, but missed the explicit dependencies
<infinity> pitti: Whee.  Probably already fixed in Debian, I'll have a look and either merge or fix and merge.
<pitti> infinity: thanks; it's probably trivial, but I haven't looked into that field at all
<infinity> Mirv: I assume the removal of debian/patches/99_valid_ccsm_desktop_file.patch coincides with upstream fixing that?
<infinity> Mirv: It would be (really) nice if the Debian changelog actually logged the debian changes. :/
<infinity> Mirv: The changes (except that patch dropping, which I can't audit on a partial diff) all look sane to me, but I'm going to NACK it based on being sick and tired of changelogs without changes logged.
<infinity> Mirv: Which means there's no rationale for the new python dep or the patch being dropped.
<Mirv> infinity: yes, the MP states it was moved into the source
<infinity> Mirv: The rules, copyright, and language cleanup changes look fine though.
<infinity> Mirv: That's lovely that the MP says that, why isn't it in the changelog?  Seriously.
<Mirv> bregma: ^ infinity would want better changelogs
<infinity> Mirv: Is this a process failure that MP changes should be getting jammed into the changelogs, or an upstream failure that the changelog should be hand-edited to be more verbose?
<Mirv> infinity: that's a common problem. it's a process failure that the MP commit messages for the branch are kept shorter than for example the actual accumulated commit messages that were made to the branch.
<Mirv> for example here https://code.launchpad.net/~bregma/compiz/fix-lintian-warnings/+merge/240298 it only says "fixed numerous minor Lintian warnings in the Ubuntu packaging" (this gets into debian/changelog), while the description is a lot more verbose and the branch has later commits which say eg "ccsm.desktop: removed deprecated attributes (moved patch inline)" that should have been added to the branch's commit message
<infinity> Mirv: Maybe we should get Linus up in here to tell people (with his usual "friendly" style) what good changelogs look like. ;)
<infinity> Though, I'm pretty sure that Linus and the Ubuntu CoC are fundamentally incompatible.
<Mirv> I see that all around canonical upstreams that the MP:s are well thought out and tested, but the branch commit message is there often just "fixes important bugs" or such
<Mirv> infinity: this is also an usability issue in LP. I find it cumbersome that when proposing a branch, only description is asked for, while the commit message is what gets used here. so commit message more naturally always comes as an afterthought "oh right I should fill in something here"
<Mirv> instead of it being thoughtfully written at the time of proposing the branch
<infinity> Mirv: Well, a branch commit message is often just "pull random crap from George" anyway.  It's the next level down that's interesting.
<mardy> Mirv: hi! I added you to this review, I guess it should be pretty familiar changes for you :-) https://code.launchpad.net/~online-accounts/accounts-qml-module/packaging/+merge/240688
<smb> Question, I have a package that uses .xz for the orig tarball in Vivid. Now I want to do minor release updates for Utopic and Trusty (where I previously still used .gz). Is it ok to change the compression type of the orig tarball in a MRE upload?
<Mirv> mardy: thanks, looking
<apachelogger> stgraber: remember the ip problems I had when starting multiple containers at the same time? http://paste.ubuntu.com/8833121/ <- I am no specialist but that output looks rather weird (:
<LocutusOfBorg1> Laney, gdcm accepted, can you please rebuild insighttoolkit and insighttoolkit4?
<LocutusOfBorg1> (nifti2dicom should wait for them)
<mlankhorst> arges: ok re-uploaded mesa. :P
<Laney> LocutusOfBorg1: will do later
<LocutusOfBorg1> thanks :)
<Laney> yw!
<infinity> smb: An MRE implies it's a new upstream version, right?
<infinity> smb: And thus, a new orig.
<infinity> smb: So, sure, compression type really doesn't matter, as long as the tools in the target distro support it (and trusty supports .xz just fine).
<smb> infinity, right. 4.4.0 -> 4.4.1
<smb> infinity, Ok, then I go forward and use the same orig for all of them. thanks
<ochosi> hey folks, if this is the wrong channel, sorry in advance (and please feel free to point me in the right direction), i just quickly wanted to know whether there is a plan on when status.ubuntu.com will be activated for V
<doko> pitti, do you understand the marble autopkg test failure?
<cjwatson> arges: on vac / conf leave this week, hopefully somebody else can advise
<doko> Riddell, ScottK, jibel, pitti: the marble autopkg tests fail very often. any hint on that? for now it's blocking gcc-4.9
<pitti> doko: looking now (sorry, had a long doctor appointment, just back)
<pitti>   8 - MarbleRunnerManagerTest (Failed)
<pitti> that doesn't look like an infrastructure problem, but a real failure?
<pitti> it's also holding back qt4-x11
<pitti> doko: ah, Riddell already overrode the test
<pitti> doko: gcc-4.9 is blocked on gamera; that regressed because apparently distutils is unhappy about parsing the "2.0rc1" version number from pygments (?)
<doko> fixed, it's testing for a strict version
<pitti> https://jenkins.qa.ubuntu.com/job/vivid-adt-gamera/6/ARCH=amd64,label=adt/console
<pitti> infinity, cjwatson: can you make any sense of this? http://paste.ubuntu.com/8834547/
<pitti> i. e. why don't the -proposed binaries get cleaned up?
<Riddell> doko: upstream says it fails often anyway because it tries to download stuff so I overrode it
<pitti> doko: "fixed" -> i. e. there's a new upload of pygments/distutils/whatever in -proposed which resolves this? or does this need further investigation?
<Riddell> pitti: â
<pitti> tests can downlaod stuff now (through the proxy), but that's apparently not what marble stumbled over
<brainwash_> mdeslaur: isn't bug 1312219 a critical one? I'm somewhat surprised that there is still no official or ubuntu-only fix
<ubottu> bug 1312219 in pepperflashplugin-nonfree (Ubuntu) "Plugin needs to update automatically" [Undecided,Confirmed] https://launchpad.net/bugs/1312219
<mdeslaur> brainwash_: it's a hard problem to solve, we can't redistribute it like we do with the ordinary flash, so we can't rely on a version being available somewhere as when new chrome versions come out, they remove the old ones
<mdeslaur> brainwash_: if you have a good idea on how to solve that, feel free to comment in the bug
<brainwash_> recommending google chrome is the only solution as of now I guess
<brainwash_> also, chromium-browser updates are delayed most of time
<brainwash_> which makes chromium-browser + pepperflashplugin-nonfree a dangerous combination
<mdeslaur> brainwash_: yep, which is why they are both in universe still
<Tribaal> brainwash_: mdeslaur: any news on chromimu 38? 37 has quite a few secuirty problems...
<Tribaal> I am glad to help if I can
<brainwash_> bug 1386455
<ubottu> bug 1386455 in chromium-browser (Ubuntu) "Chromium 37 has 159 known security issues" [Undecided,Confirmed] https://launchpad.net/bugs/1386455
<mdeslaur> Tribaal: it's being worked on, as usual, it refuses to compile on some of our archs, so chad is working hard on getting it fixed
<mdeslaur> we have someone full-time on getting chromium built
<Tribaal> mdeslaur: ahhh I understand the problem now. I didn't realize it was a compilation problem.
<Tribaal> mdeslaur: thanks for the answer
<mdeslaur> you can monitor progress here: https://launchpad.net/~canonical-chromium-builds/+archive/ubuntu/stage/+packages
<mdeslaur> also, upstream switched to requiring llvm to compile it, so chad has been working on getting llvm built for older releases, etc.
<brainwash_> sadly I cannot help with fixing those issue
<brainwash_> but I assume that chromium and the pepperflashplugin are quite popular
<brainwash_> maybe the update policy for both packages should be discussed (somewhere)
<ypwong> xnox, cjwatson: could you take a look at bug 1330410? not sure what wrong, but from the package I built myself, the bug does not exist.
<ubottu> bug 1330410 in Ubuntu Kylin "All keyboard types in "Keyboard layout" are not localized during installation" [High,Triaged] https://launchpad.net/bugs/1330410
<ypwong> thanks
<Riddell> mdeslaur: further security update in bug 1389665 goes public tomorrow
<ubottu> Error: Launchpad bug 1389665 could not be found
<mdeslaur> Riddell: ack, subscribed ubuntu-security-sponsors
<mdeslaur> Riddell: thanks
<didrocks> Riddell: hey, not sure if you saw my ping the other day, but I plan to have a bluez5 session at UOS. Would be nice to have some kubuntu guys to sync up (from what I read, everything is ready from the KDE-front to work with bluez5)
<Riddell> didrocks: oh yes, I asked a bit and didn't get any answer, I'll ask louder
<didrocks> thanks :)
<cjwatson> pitti: they need to migrate but have unsatisfiable dependencies; see near top of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<cjwatson> ypwong: not until next week at least, on vacation / conference leave
<pitti> cjwatson: right, but why is britney migrating the version at all? I thought it should wait for all arches?
<cjwatson> pitti: it only waits for things that are out-of-date
<cjwatson> pitti: so if only those first four architectures had ever been built first time round, it wouldn't have considered that it needed to wait for the remaining two
<pitti> ah
<pitti> jibel: ^ FYI
<infinity> cjwatson: Although, it's broken anyway, since it copied armhf, which has the same problem.
<infinity> cjwatson: I presume because it's just a source-with-binary copy, and the armhf build raced in under the wire.
<infinity> (Though, how ppc64el didn't, I don't know...)
<cjwatson> Could be, haven't gone back to analyse
<infinity> Seems to come down to libfftw3 being broken on some arches.
<infinity> Oh, not broken, just missing longdouble support on some.
<infinity> Retrying arm64 and ppc64el should work, armhf will still fail.
<mardy> Mirv: I updated https://code.launchpad.net/~online-accounts/accounts-qml-module/packaging/+merge/240688
<stgraber> apachelogger: hmm, yeah, that looks like a lxc-info bug :) Can you report that?
<ypwong> cjwatson, ok, no hurry, perhaps xnox will be able to check the bug since he did the last upload of that package
<xnox> ypwong: highly unlikely. Maybe stgraber or infinity would step in to do it =)
<bdmurray> seb128: the file-roller retraces fail due to missing debug symbol packages for file-roller
<bdmurray> seb128: http://ddebs.ubuntu.com/pool/main/f/file-roller/ notice no amd64 / i386 for the utopic package version
<seb128> bdmurray, hum, do we know why?
<seb128> bdmurray, I guess we need a no change rebuild to fix that?
<bdmurray> seb128: yeah, I did a few uploads during the sprint before release didn't get to file-roller
<bdmurray> pitti: is there some way to get utopic amd64 and i386 ddebs for file-roller?
<bdmurray> pitti: we have them for every other arch...
<seb128> bdmurray, if we need an upload I'm just going for a bugfix worth SRUing so we don't do an upload for nothing
<bdmurray> seb128: alright, sounds good
<Laney> LocutusOfBorg1: okay, got some time now
<Laney> what's the first level?
<LocutusOfBorg1> Laney, I would say insighttoolkit and insighttoolkit4
<LocutusOfBorg1> the second/last level should be nifti2dicom, but itk4 takes almost 10 hours to build...
<Laney> I made a transition tracker entry
<Laney> let's see what it says
<LocutusOfBorg1> Laney, http://people.canonical.com/~ubuntu-archive/transitions/
<LocutusOfBorg1> I don't see it...
<Laney> you need to wait for it to update
<Laney> see the time at the bottom
<LocutusOfBorg1> oh yes ;)
<LocutusOfBorg1> I don't know how much time takes ben to update :)
<Laney> LocutusOfBorg1: there
<LocutusOfBorg1> mmm strange, so nifti2dicom doesn't need a rebuild=
<LocutusOfBorg1> seems legit
<Laney> no it only depends on libinsighttoolkit4.6
<LocutusOfBorg1> yep, I though it was a level2, but yes, doesn't need a rebuild
<eto> hello i would like to know if it is possible to run systemd on current ubuntu server LTS
<eto> and if yes how hard it would be to switch to it?
<eto> does such switch require compiling it from source?
<LocutusOfBorg1> ubuntu 14.04 LTS has systemd in the repository
<LocutusOfBorg1> switching to it from an existing installation might be hard, because I got some upgrades (mainly in debian testing) that didn't boot up after the reboot
<Quintasan> LocutusOfBorg1: Trusty has no candidate for systemd package if I'm not mistaken
<LocutusOfBorg1> https://launchpad.net/ubuntu/+source/systemd
<LocutusOfBorg1> the package seems built for trusty
<Quintasan> LocutusOfBorg1: I believe it is crippled as in it's lacking systemd binary
<LocutusOfBorg1> https://wiki.ubuntu.com/systemd
<LocutusOfBorg1> Quintasan, don't know honestly
<LocutusOfBorg1> :)
<LocutusOfBorg1> I think pitti has the correct answer ;)(
<Quintasan> Yeah, it's crippled in Trusty
<LocutusOfBorg1> I won't install that think unless forced to :)
<Quintasan> I believe I wanted to give it a go before the whole Debian stuff happened and I no packages provide the binary
<Bluefoxicy> Sometimes, I really wonder if it's a waste of effort to respond to the mailing list with a logical, well-thought argument; or if I should just hit REPLY ALL and type "Your mom."
<eto> LocutusOfBorg1: well i am not really familiar with ubuntu-server per se but given it's linux and systemd is inevitable i would like to use it at least
<eto> LocutusOfBorg1: as external admins use ubu-server i was thinking maybe i could at least get some systemd features just by replacing init
<LocutusOfBorg1> eto, I don't know what to say, I would like to give a try with debian jessie, with systemd by default
<LocutusOfBorg1> maybe you can test your system, and when ubuntu switch you can go back
<eto> LocutusOfBorg1: actually our requirements are minimal
<eto> LocutusOfBorg1: i mean we probably don't neet everything included in ubu-server - so maybe it would be wiser to interview admins if they would be okay with debian jessie?
<Bluefoxicy> jessie?  is Debian using Pokemon for names now?
<eto> LocutusOfBorg1: are there big differences between debian and ubuntu-server ? besides extra tooling i guess
<LocutusOfBorg1> Bluefoxicy, https://www.google.it/search?q=Jessie+toy+story&safe=off&client=ubuntu&hs=F7Q&channel=fs&tbm=isch&imgil=dNwnIGUOfxNI4M%253A%253B8TFYPGjXPwr_0M%253Bhttp%25253A%25252F%25252Fdisney.wikia.com%25252Fwiki%25252FFile%25253AJessie_from_toy_story_2.png&source=iu&pf=m&fir=dNwnIGUOfxNI4M%253A%252C8TFYPGjXPwr_0M%252C_&usg=__N8VW64Q0nKA4RjuvlHcNS9WT7cU%3D&biw=1920&bih=954&ved=0CDMQyjc&ei=bmFaVP3AF4eR7Abm8YCwBQ#facrc=_&img
<LocutusOfBorg1> dii=_&imgrc=dNwnIGUOfxNI4M%253A%3B8TFYPGjXPwr_0M%3Bhttp%253A%252F%252Fimg4.wikia.nocookie.net%252F__cb20130718165011%252Fdisney%252Fimages%252Fd%252Fdf%252FJessie_from_toy_story_2.png%3Bhttp%253A%252F%252Fdisney.wikia.com%252Fwiki%252FFile%253AJessie_from_toy_story_2.png%3B1200%3B1052
<LocutusOfBorg1> oops http://img4.wikia.nocookie.net/__cb20130718165011/disney/images/d/df/Jessie_from_toy_story_2.png
<LocutusOfBorg1> jessie is from toy story, like all the other debian names
<LocutusOfBorg1> (excluding rc-buggy lol)
<Bluefoxicy> o.o
<Bluefoxicy> that URL is amazing
<LocutusOfBorg1> bdrung_work, do you plan to merge this? https://code.launchpad.net/~uwelk/vlc/daily-packaging/+merge/240758
<LocutusOfBorg1> adding protobuf-compiler should fix the building issues
<LocutusOfBorg1> https://code.launchpad.net/~uwelk/vlc/daily-packaging/+merge/240759 this one
<Bluefoxicy> so, I work at a major media company
<eto> so basically from quick search jessie seems like lighter alternative to ubuntu server is that right?
<Bluefoxicy> we've found that the ffmpeg precompiled, static-linked binary is like... it takes 5 seconds to encode a video that takes 35-45 seconds on the same version out of the repos in Fedora or Ubuntu
<Bluefoxicy> H.264 with AAC
<eto> Bluefoxicy: with static buld all filters are included into single binary?
<eto> build
<Bluefoxicy> eto:  Yes, but that only affects dynamic linking; it doesn't affect runtime speed
<Bluefoxicy> a static built Openoffice.org would load immediately, instead of in 17 seconds; but it would operate all runtime functions at the same speed as the dynamic binary
<eto> Bluefoxicy: but if you use lot of execs from external script it might affect processing right? ffmpeg
<Bluefoxicy> no
<Bluefoxicy> the single binary runs for the full encoding period, one run.
<Bluefoxicy> we're talking about bulk mathematics processing, not large amounts of shell script invocation
<eto> yes but it starts in 5 seconds without linking stage right?
<Bluefoxicy> no
<eto> roger
<Bluefoxicy> it completes the full task of encoding the video in 5 seconds
<eto> how come?
<Bluefoxicy> that's what I want to know.
<Bluefoxicy> There was a point in time when Ubuntu's firefox was slow as living hell, and the static build of Firefox was snappy; it was so bad that nearly everyone had installed the Firefox downloaded from mozilla.org at the time
<eto> Bluefoxicy: are you using ubuntu server in your stack?
<ogra_> Bluefoxicy, likely because you only build it for one arch and dont need to take ppc, ppc64, arm64 or whatever into account ... which might add other code paths and patches to generalize the code a bit more
<Bluefoxicy> I've tested with multiple
<Bluefoxicy> ogra_:  those are defined with conditional compilation
<ogra_> some are, some arent
<Bluefoxicy> also, code existing and code being run are two different things.  You can compile in as much code as you want without making a program slower, if you don't ever call that code
<ogra_> also are you sure you use the exact same toolchain with exactly the same options ? (which are also a selection to make it work on as many arches as possible)
<Bluefoxicy> ppc and ARM patches tend to provide an alternate code path, often hand-optimized assembly.  Similarly, mmx and sse patches use wrapper functions or direct assembly
<Bluefoxicy> ogra_:  regardless, none of that should cause one compilation of an application to run 5-10 times faster than another.
<Bluefoxicy> as well, libav is different than ffmpeg in many ways, but it's not clearly ridiculously slow; and the ffmpeg in fedora is also slow.
<ogra_> you are heavily using math ... it will definitely make a difference if you have your code adjusted for generic usage vs very specific optimization for just one arch
<Bluefoxicy> yeah, but the generic one is the one that's fast.
<ogra_> you said the archive one isnt fast
<ogra_> while your personally compiled one is
<Bluefoxicy> ogra_: https://www.ffmpeg.org/download.html these are fast (particularly, the linux static build)
<eto> ty guys
<Bluefoxicy> ogra_:  anyway, my point is there should be some investigation about why libav in Ubuntu is ridiculously slow compared to the release provided; it's investigation I don't know how to do
<Bluefoxicy> and I am now in webinar for negotiation for 5 hours, sorry later.
<ogra_> well, i would start comparing the patch sets vs the source that static package was built from
<ogra_> if you are sure you use the same toolchain for both, it can only be patches
<Bluefoxicy> wow
<Bluefoxicy> that guy responded to the list with "fuck you", and then called me a femenist and talked about Tim Cook ruining the world for "regular men" o.o
<Bluefoxicy> just wow.
<Bluefoxicy> and... now he's advocating murder.
<Bluefoxicy> Somebody please check the lists.
<Bluefoxicy> mhall119:  Thanks.
<mhall119> yeah, trolling troll is trolling, I'm working on it
<rickspencer3> slangasek, around at all?
<slangasek> rickspencer3: hi
<rickspencer3> slangasek, there seems to be some unfortunate exchange going on on @ubuntu-devel-discuss
<slangasek> mmm
<ogra_> rickspencer3, mhall119 is on it
<rickspencer3> it doesn't seem to really have any value to the community, I was wondering if there options to stop it?
<rickspencer3> ogra_, thanks
<rickspencer3> slangasek, nm
<rickspencer3> :)
<slangasek> ok
<ogra_> though we might need a list admin to block the troll
<slangasek> I'm sure there are options, but I don't know who the list admins are - I'm not
<rickspencer3> ok
<rickspencer3> I think if mhall119 is on it, then it will be handled professionally and quickly
<ogra_> ubuntu-devel-announce list run by cjwatson at ubuntu.com, steve.langasek at ubuntu.com, adconrad at ubuntu.com
 * rickspencer3 backs away slowly
<ogra_> slangasek, the list disagrees :)
<rickspencer3> boom
<rickspencer3> :)
<slangasek> ogra_: you may notice that -announce != -discuss
<slangasek> ;)
<ogra_> oh, wait
<ogra_> sorry ...
 * ogra_ blames evulotion :P 
<slangasek> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss/ says it's mhall119's problem!
 * slangasek wipes his hands
<ogra_> haha
 * rickspencer3 exercises mute feature on thread
<mhall119> slangasek: it is now
<ogra_> argh
<ogra_> he moved to ubuntu-users
<mitya57> systemd threads â now on every mailing list near you
<dobey> multiprocessing via email
<mitya57> (as usual, incorrectly capitalized)
<Bluefoxicy> man this is ridiculous.  I'm trying to update a printer firmware, but it uses a windows software program instead of giving me a firmware update file to upload to the printer
<Bluefoxicy> so I tried to install the printer on windows.
<Bluefoxicy> ... ... ... yeah uh.  Why does hardware just plug in and work on Ubuntu, but require some arcane incantation to make work on Windows?
<sarnold> "arcane incantation"? what could be simpler than googling for "<printer model number> download drivers", clicking on the first 438 megabyte file you can find, double-clicking it to start an installer, clicking "next" nine times, uninstalling the three browser toolbars you get, and then rebooting?
<mdeslaur> sarnold: you forgot the step where you run the weird registry cleaner tool because you *gasp* plugged the printer in _before_ installing the driver
<sarnold> mdeslaur: haha you don't make that mistake twice! :)
<teward> is there a way to see what udev rules get installed on a Vivid system by default...?
<teward> i'm trying to figure out a hardware support problem i've observed in Trusty and Utopic with certain equipment, and checking the udev rules accordingly
<Bluefoxicy> sarnold:  the problem is I installed the print driver on Windows, and it says it doesn't know what to do with it.  I downloaded the print driver software package, and it says it can't find the printer.  And so on and so forth.  "What's this funky USB device?"  "Here's the driver"  "I don't know how to talk to it to see if the driver works"  "Okay, here's the software the manufacturer sent"  "Where's the printer?  I can't i
<Bluefoxicy> nstall the drivers if I can't see the printer!"
<Bluefoxicy> sarnold:  plug it into an Ubuntu box.  "WOULD YOU LIKE TO PRINT A TEST PAGE?!"  o.o
<Bluefoxicy> and yet people still mock me about the strange shell commands supposedly required to get a sound card working on Linux.  :|
 * Bluefoxicy is frustrated today.
<sarnold> Bluefoxicy: we haven't even had to edit modelines in a decade.. sheesh :)
<dobey> sarnold: go buy a 4k monitor and try to get it working on displayport :)
<dobey> sarnold: if you don't need to edit modelines, you just need better hardware ;)
<sarnold> dobey: hahaha :)
<sarnold> actually, I've got the 4k tv.. I doubt this intel graphics in my laptop could actually drive it at that resolution, but it might be fun to see how far it can get
<dobey> is it ivybridge or haswell?
<sarnold> "Intel(R) Core(TM) i7-3520M CPU"
<sarnold> not haswell but I also don't know about ivybridge :)
<dobey> you might be able to do it on hdmi
<dobey> it's ivybridge
<Bluefoxicy> i plugged my computer into a 39 inch TV from LG
<Bluefoxicy> HDMI on my computer
<dobey> ivybridge doesn't do displayport 1.2 i don't think, which is required for the multi stream transport used by 4K monitors
<dobey> eh 39" is way too big to use at a desk
<ogra_> depends on the thickness of your glasses
<sarnold> dobey: oh, cool, though all I've got for outputs is minidisplay port and VGA
<dobey> ogra_: would depend more on the curvature than the thickness. you'd need fisheye lens to be able to see the whole screen from so close :)
<ogra_> :)
<pitti> desrt: hey Ryan!
<desrt> hihi
<pitti> desrt: would you mind doing another systemd-shim upstream release?
<desrt> no problem
<desrt> for the security policy thing?
<pitti> desrt: I fixed several bugs, amongst them the grave Debian RC one
<desrt> there was an RC bug?
<pitti> desrt: yeah, see git log
<pitti> desrt: I was also looking into bug 1359439
<ubottu> bug 1359439 in systemd-shim (Ubuntu) "[ 7.287663] systemd-logind[1057]: Failed to start unit user@126.service: Unknown unit: user@126.service" [Undecided,In progress] https://launchpad.net/bugs/1359439
<desrt> thanks :)
<pitti> desrt: but despite looking really simple, it's a can of worms
<desrt> ...like most things here
<shirgall> Yeah, I saw that one this morning.
<pitti> desrt: I have a patch which "fakes" those units, but then this requires implementing even more properties/API, etc.
<pitti> desrt: so I think it's better to do a release now, calm down the debian folks a bit, and tackle this for release 10
<desrt> pitti: sounds like you were in the same area of pain that i was
<desrt> pitti: will roll a release right now... i have a few minutes :)
<pitti> desrt: if you have some mins to cross-check my commits to see that I don't anything profoundly stupid, that'd be welcome of course
<desrt> you in fact fixed what i had been working on before (before i got distracted to other things)
<pitti> desrt: otherwise, I tested it pretty thoroughly on my workstation and in a VM with various scenarios, and the logind session cleanup works really nicely now
<desrt> pitti: isn't the usual pattern to ask for this before committing? :)
<pitti> desrt: *shrug*, github allows push -f :) but yeah, if you prefer that I can also work in a branch
<desrt> pitti: i'm sure this is all quite fine
<desrt> don't overestimate how much i care about this project
<desrt> which is: not much :)
<pitti> desrt: oh, were you working on the notify_on_release stuff, too?
<desrt> ya
<desrt> i'm happy that you beat me to it though
<pitti> desrt: care> well, this is mostly for Debian's benefit at this point, jessie freeze is today
<desrt> it was getting can-of-wormsy as well
<xnox> stgraber: Montreal folks are so vicious, it's been a year now, and the bug reporters cannot get used to the fact that America/Toronto & America/Montreal got merged into a single timezone in zone.tab - "America/Toronto - Ontario & Quebec - most locations"
<pitti> desrt: yeah, took me a while to fully understand what systemd/logind are doing there
 * xnox closed 3 bug reports now.
<pitti> slangasek: ^ on that note, do you want to package systemd-shim 9 (bug refs are in the git changelog), or want me to?
<pitti> Maintainer: and all that
<desrt> pitti: looks like there are some compiler warnings here
<slangasek> pitti: you can probably get to it sooner than me, I'm happy for you to and also add yourself as an uploader ;-)
<pitti> oha? I didn't spot any, sorry
<pitti> slangasek: ack
<slangasek> pitti: and thanks for sorting out these bugs!
<desrt> implicit declarations of g_access and perror
<desrt> i'll clean them up
<pitti> slangasek: cheers
<pitti> desrt: whoops
<desrt> pitti: fwiw, don't use g_access()
<desrt> this is only useful if your program is intended to be portable to windows
<pitti> desrt: EAFP instead of LBYL?
<desrt> since otherwise it is just an alias for access()
<pitti> ah
<pitti> desrt: I got into a habit of using that for glib-y stuff, fewer includes etc.
<pitti> is there any downside to it?
<desrt> pitti: you need to include gstdio.h for this one :)
<desrt> since it is only a #define alias for the standard library function
<desrt> (so you still need the system headers)
<pitti> desrt: I just built it again, and get zero warnings; but I just ./configure'd with the defaults, so maybe I'm missing some extra warning opts that you specified?
<desrt> pitti: i did the same, but i'm on fedora
<desrt> so maybe my gcc is stricter by default
<pitti> desrt: ah, I'm on vivid
<stgraber> xnox: well, it'd help if clicking on Montreal on the map would actually do something rather than give you an empty timezone :)
<stgraber> xnox: so yeah, the two were merged, but badly so :)
<desrt> pitti: diversity win, i guess
<pitti> heh
<pitti> desrt: oh, and we don't install the d-bus policy any more, so perhaps we should remove it upstream as well?
<pitti> desrt: it was only really useful for a split systemd-services build, but nobody does that any more
<xnox> stgraber: our plan (b) was to ship 10'000 top locations on the cd and pick from them. Because we also have a persistent request to "add Beijing" instead of "Shanghai". Man, politics are hard - google maps have three maps for ukraine at the moment.
<pitti> desrt: if you want to, I can commit that cleanup for 9 still (it's trivial)
<desrt> pitti: sure
<desrt> i just pushed the warnings fixes
<pitti> desrt: policy drop fixed
<pitti> desrt: err, what a grammar -- policy dropping committed
<pitti> desrt: peux-tu prÃ©parer la nouvelle version neuf maintenant ? :-)
<desrt> uh... oui!
<desrt> (i hope)
<desrt> so we have an interesting problem
<desrt> my homedir on gnome.org has mysteriously vanished
<pitti> WT...H?
<desrt> #sysadmin says they know about it and are investigating
<desrt> want me to email you the tarball or something? :)
<pitti> desrt: WFM, or people.c.c. or whatever
<desrt> first let's get this out of the way:
<desrt> f1d69073037cc48562dd25d10ba069ff92f759381fa79042c5be4248b9c56e78  systemd-shim-9.tar.xz
<pitti> desrt: cheers! got it
<pitti> desrt, slangasek: uploaded
 * pitti waves good night, take II
<sarnold> night pitti :)
<bdmurray> slangasek: any ideas about bug 1384946?
<ubottu> bug 1384946 in ubuntu-release-upgrader (Ubuntu) "Trying to upgrade to utopic, cannot compute changes due to gnuplot" [Undecided,Confirmed] https://launchpad.net/bugs/1384946
<desrt> pitti: cheers
<infinity> hallyn: Why is there no qemu-kvm on arm64 and ppc64el?
<hallyn> infinity: does 'qemu-system-ppc64 --enable-kvm' work?
<hallyn> if so, then it's just bc we need to add those arches to the qemu-kvm pkg, so i should see if we can do that straight in debian
<infinity> hallyn: Yes, it does.
<infinity> hallyn: (Only on a subset of machines, but that's no different from x86, their subset is just larger)
<infinity> hallyn: The description for qemu-kvm is also a lie. :P
<infinity> hallyn: Or does that get arch-specific mangling at build time?
<hallyn> which part is a lie?  it is in fact currently a wrapper script only around qemu-system-x86
<infinity> hallyn: Oh.  So, that's entirely wrong, then, that it's built on arm, powerpc, and sparc.
<infinity> hallyn: I would have epxected it to depend on qemu-system-${native} and then wrap appropriately.
<infinity> hallyn: So we have a one-stop shop to tell people "if you want qemu w/ kvm capabilites on any arch, just apt-get install qemu-kvm" instead of having the end user map machine arch and qemu-system-arch.
<mwhudson> oh hai
<mwhudson> fwiw, devstack needs to do exactly this
<mwhudson> it currently installs qemu-kvm
<mwhudson> for my arm64 patches i install qemu-system but that's overkill
<mwhudson> i wonder what the nova packaging does...
<infinity> mwhudson: So, the short term solution is a local mapping of arch:arch.
<mwhudson> oh right, installing nova doesn't get you a hypervisor, you get to decide
<infinity> mwhudson: So on arm64, you install qemu-system-arm, on ppc64el, you install qemu-system-ppc, etc.  But fixing qemu-kvm is the right answer, IMO.
<mwhudson> infinity: ack
<mwhudson> infinity: shall i file a bug on +source/qemu
<mwhudson> ?
<infinity> Plus, installing qemu-system-foo doesn't tell you what command you need to run to make it work.
<infinity> Which the kvm wrapper fixes.
<infinity> mwhudson: If you want to summarize the above and file a bug, that would be great.
<mwhudson> i guess libvirt has that knowledge somehow?
<infinity> mwhudson: Yeah, if you're running through libvirt, it's supposed to know.
<hallyn> infinity: agreed, it'd be good to generalize that
<hallyn> yeah libvirt just round qemu-system$arch --enable-kvm
<hallyn> really qemu-kvm just providses a wrapper script for the lazy
<hallyn> like me
<infinity> hallyn: The wrapper script is less interesting to me (though we should fix it at the same time), it's the packaging shortcut that's nice.
<infinity> hallyn: I'd rather depend on "qemu-kvm" for native support than "qemu-system-foo [foo bar], qemu-system-quux [quux baz], etc"
<hallyn> true
<hallyn> yeah mwhudson pls file the bug and while i have scant days left in 2014 i'll try to get that fixed in vivid
<infinity> hallyn: And, FWIW, if we fix it sanely in vivid, I'd happily accept (and even encourage) an SRU to trusty and utopic with the same change.
<infinity> Would be great if HOWTOs can just say "Step 1: install qemu-kvm" and it works on all arches.
<infinity> Well, all arches with KVM support, but that happens to be all the ones we ship (plus sparc, apparently).
<mwhudson> infinity, hallyn: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1389897
<ubottu> Ubuntu bug 1389897 in qemu (Ubuntu) "no way to install "enough qemu for kvm" in a cross platform way" [Undecided,New]
<mwhudson> i think even my packaging skills might be up to fixing this
<mwhudson> it's just a matter of sprinkling []s in qemu-kvm's Depends: line, right?
<hallyn> "plus psarc, apparently" - wut?
<hallyn> mwhudson: i'm abroad this week so if you don't mind then by al lmeans please do
<slangasek> bdmurray: 1384946> doesn't that show that the user has an old, pre-trusty version of gnuplot installed?  trusty has 4.6.4-2, not 4.4.3-0ubuntu3
<slangasek> ah
<slangasek> you noted this already
<slangasek> so, hmm, no specific ideas here, but I guess we should fix the precise->trusty dist-upgrade path for it if possible
<infinity> mwhudson: That, and fixing the description to be arch-agnostic.  And, the harder part, fixing the wrapper to DTRT (perhaps generating it at build time, rather than having complex case statements)
<mwhudson> oh right, the wrapper
<infinity> mwhudson: And dropping /usr/bin/qemu-system-x86_64-spice and /usr/bin/kvm-spice from !x86
<mwhudson> fetching git://anonscm.debian.org/pkg-qemu/qemu.git is taking aaages
<infinity> mwhudson: Oh, I'd just work from the vivid sources, throw a patch at hallyn, and let him resolve it with git. :P
<infinity> mwhudson: But I'm lazy that way.
<mwhudson> ehh the kvm wrapper is only installed on x86 it seems
<mwhudson> even though the package is built on various arches
<infinity> mwhudson: So, a first cut could just be to change the deps, but the right answer is to make the wrapper work everywhere, IMO.
<hallyn> infinity: mwhudson: yeah the ubuntu-devel branch of git://anonscm.debian.org/pkg-qemu/qemu.git should be identical to the vivid sources, so if you want to jus tpost a debdiff to the bug i'll work out the git bits and try to convince mjt it's a good idea for debian too :)
 * hallyn out - gnight
<mwhudson> the clone has finished now
<mwhudson> er
<mwhudson> is there a reason why it depends on qemu-system-x86 (>= 1.7.0+dfsg-2~) rather than (= ${binary:Version}) ?
<doko> great, now gcc-4.9 migration is blocked by some r-cran stuff ... https://jenkins.qa.ubuntu.com/job/vivid-adt-r-cran-surveillance/lastBuild/ARCH=amd64,label=adt/console
<doko> pitti, jibel: ^^^ this definitely doesn't scale ....
<mwhudson> infinity: does qemu-system-ppc cover ppc64el?
<infinity> mwhudson: Yeahp.
<infinity> mwhudson: For powerpc, ppc64, and ppc64el, it should all be 'qemu-system-ppc64 --enable-kvm' in the wrapper.
<infinity> mwhudson: If there are 32-bit systems with KVM support, they're outliers, and I'll let BenC whine about them. :P
<BenC> infinity: Theyâre far from outliers
<infinity> mwhudson: I assume that dep was originally because of the Breaks/Replaces there too (as files moved around), but (= ${binary:Version}) would probably make more sense if the intent is to use qemu-kvm to install the right qemu-system.
<BenC> But I canât get Canonical to bother with anything Iâm doing so, have at it
<infinity> BenC: Well, I'm not regressing anything here, this already doesn't work right.  But if we can come up with a way to make the wrapper DTRT, do let's.
<infinity> BenC: We could key off 'uname -m' on powerpc, and call the right qemu.
<BenC> infinity: Check CPU type in /proc/cpuinfo. If itâs e500mc, use qemu-system-ppcemb
<infinity> BenC: Oh, there's a special build for emb?
<BenC> If ifâs `uname -m` == ppc and not e500mc, then use whatever else
<infinity> So there is.
<BenC> infinity: It has all the right mojo to emulate a n E500 machine and connect to the right kvm bits
<BenC> e500 or e500mc that is
<infinity> BenC: Want to pastebin a cpuinfo from such a machine?
<mwhudson> so if feels like mv debian/kvm debian/kvm.x86, vim debian/kvm.aarch64 etc etc and install the right one?
<mwhudson> *it
<mwhudson> or is ppc the only snowflake and we can do the others with sed?
<infinity> mwhudson: Others may be snowflaky in Debian (like mips*, perhaps)
<BenC> infinity: http://pastebin.ubuntu.com/8842972/
<infinity> mwhudson: So, having one file per arch, and mangling as needed seems the right path.
<BenC> That other would show cpu: e500v2"
<BenC> Which would use the same binary
<infinity> mwhudson: For most, it should look identical to the current x86 one, for ppc, it'll be a bit more involved.
<BenC> Itâs self detecting for the host
<infinity> BenC: Are there any e500* that wouldn't want this, or can we just wildcard it?
<BenC> infinity: e500v1, but that wont have a /dev/kvm, so wouldnât much matter
<infinity> Right, kay.
<BenC> e500mc and e500v2 are the kvm enabled ones
<infinity> So, we can just wildcard a case, probably.  That's lazier/easier. :)
<mwhudson> oh god, kvm has a shitty inaccurate man page too
<BenC> Sure â^cpu:[[:space:]]*e500.*â should match all things of interest for ppcemb
<mwhudson> oh maybe not inaccurate
<mwhudson> why is everything horrible
<infinity> Because life.
<infinity> BenC: So, your 64-bit platform just uses the standard qemu-system-ppc64?
<BenC> infinity: Iâd have to check. I think it may need to use ppcemb as well
<BenC> proc cpuinfo would show e6500
<BenC> infinity: Confirmed
<BenC> so e500* and e6500
<BenC> processor	: 20
<BenC> cpu		: e6500, altivec supported
<BenC> clock		: 1666.666650MHz
<BenC> revision	: 1.0 (pvr 8040 0010)
<BenC> Thatâs the relevant cpu stanza
<BenC> Both platforms are BookE, hence the ppcemb usage
<infinity> BenC: So, something like this: http://paste.ubuntu.com/8843119/
<infinity> mwhudson: ^
<mwhudson> good timing, i'm typing my commit message for the other wrappers now
<infinity> Err, missing a trailing ;; on the last outer case.
<BenC> infinity: The awk statement works on both systems, so passes a cursory check
<infinity> That was obviously written blind. :P
<BenC> It atleast passes the the correct output on my boxes :)
<mwhudson> infinity: is there a reason to handle power64 in this same file, particularly?
<infinity> mwhudson: Most 32-bit powerpc installs are on 64-bit kernels.
<BenC> mwhudson: 32-bit userspace can run on 64-bit platforms
<mwhudson> ok
<infinity> http://paste.ubuntu.com/8843150/ <--- that one looks like more correct shell.
<infinity> BenC: Can you run that with sh -x on your machines and make sure it's trying to run the right binary?
<infinity> Passes on a ppc64, ppc64el and ppc machine here.
<BenC> infinity: If youâre going to use $(â¦) notation, should it not use bash?
<BenC> Or am I behind the times
<infinity> $() is POSIX.
<infinity> Could be backticks, doesn't really matter.  I just use $() more these days to avoid confusing myself when nesting.
<BenC> infinity: Works on both, thanks
<infinity> BenC: Ta.
<infinity> mwhudson: So, that last pastebin with the quoting and ;; fixes should DTRT for qemu-kvm:powerpc
<mwhudson> infinity: thanks
<infinity> mwhudson: You could reuse it for :ppc64 and ppc64el too, though it's mostly a no-op for them, it simplifies the packaging to just symlink. :P
<mwhudson> infinity: i just attached some patches to the bug https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1389897
<ubottu> Ubuntu bug 1389897 in qemu (Ubuntu) "no way to install "enough qemu for kvm" in a cross platform way" [Undecided,Confirmed]
#ubuntu-devel 2014-11-06
<infinity> mwhudson: Oh, the sparc bit is an Ubuntu delta?  We can probably just drop that, then.
<mwhudson> oh yes
<mwhudson> you mean, stop building the package for sparc?
<infinity> mwhudson: Yeah.
 * mwhudson gets his rebase on
<infinity> mwhudson: Oh, and probably add x32 to the x86 cases, in case Debian wants to pick it up.
<infinity> mwhudson: Then rebase the whole thing down to one readable patch. :)
<infinity> mwhudson: But looks good.
<mwhudson> infinity: new commits on https://github.com/mwhudson/qemu/commits/qemu-kvm-arches
 * infinity clones.
<mwhudson> ok, deleted my first patches from the bug, attached a diff of the whole thing and linked to gh
<mwhudson> i suppose i should do a testbuild
<mwhudson> i should also have lunch
<sarnold> Laney,xnox, http://ubuntu-codesearch.surgut.co.uk/ is returning "502 bad gateway", is this expected?
<infinity> mwhudson: I like it.
<mwhudson> infinity: thanks
<infinity> mwhudson: If you carry on accidentally displaying competence with packaging, I might railroad you into applying for MOTU or core-dev.
<infinity> mwhudson: Though, you'll have to explain to me some day how 4 is the integer after 1.
<infinity> mwhudson: (Looking at your upload history, and the changelog in gccgo-go :P)
<sarnold> well it's certainly not -before- 1 :)
<infinity> sarnold: Fait point.  It's one of the many integers after 1, just not the one I'd expect. ;)
<infinity> s/Fait/Fair/
<sarnold> infinity: hehe :)
<mwhudson> in my defense, i didn't actually propose that for ubuntu i think
<mwhudson> i imagine 2 and 3 were broken versions in my ppa
<mwhudson> infinity: E: qemu-kvm: subdir-in-usr-bin usr/bin/kvm/
 * mwhudson fails
<mwhudson> LIMITATIONS
<mwhudson>        dh_install cannot rename files or directories, it can only install them with the names they already have into wherever you want in
<mwhudson>        the package build tree.
<mwhudson> well stink
 * mwhudson vanishes for a bit
<infinity> mwhudson: Oh, yeah, you probably just want good ol' install.
<infinity> mwhudson: As in 'install -m755 debian/kvm.x86 debian/qemu-kvm/usr/bin/kvm'
<Mirv> infinity: retry, https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141105-0ubuntu1.diff
<infinity> Mirv: +1
<Mirv> thanks!
<mwhudson> infinity: don't i need something to indicate that it should be part of the qemu-kvm package?
<mwhudson> i guess a .install file suffices for that
<mwhudson> (seeing as the installed file is the same on all platforms, that's the point :)
 * mwhudson reads what infinity wrote again
<infinity> mwhudson: No.
<infinity> mwhudson: But I'm guessing you got there from your last comment.
<mwhudson> yeah
<mwhudson> didn't sleep well last night, please excuse lack of brain
<infinity> mwhudson: The alternative would, indeed, be to install that to debian/tmp/usr/bin and then have an .install file that copies it, but that seems pointless.
<mwhudson> yes
<pitti> Good morning
<pitti> jibel: gcc has that eternal "test in progress" problem again for r-cran-surveillance and cuneiform
<pitti> doko_: ^ I already tried to work around it, but I don't have access to tachash; gosh, I'm so glad when this stuff gets replaced
<pitti> doko_: but right, that's a nuisance :(
<LocutusOfBorg1> can anybody please retry https://launchpad.net/ubuntu/+source/insighttoolkit4/4.6.0-3build1/+build/6541532 ?
<LocutusOfBorg1> I don't know if rebuilding fixes, usually it does for itk4 :(
<LocutusOfBorg1> in the meanwhile I talk with the maintainer :)
<jibel> pitti, I cannot find any result for cuneiform, I'm looking into it. I regenerated a result and it will be fixed on next run of britney.
<pitti> jibel: cheers! for r-cran-surveillance too?
<jibel> pitti, yes both
<pitti> jibel: merci
<cjwatson> LocutusOfBorg1: retried
<LocutusOfBorg1> thanks :)
<pitti> infinity: as TIL you called dibs on the kmod merge (which curiously is missing from MoM); I just saw bug 1372035 which would be solved by that
<ubottu> bug 1372035 in kmod (Ubuntu) "modprobe: ERROR: could not insert 'off': Function not implemented" [Undecided,New] https://launchpad.net/bugs/1372035
<pitti> infinity: do you plan to do the merge, or release it to the "general core-dev public"? (NB I can't do it right now, but probably within the next week or so)
<jibel> pitti, wrt. cuneiform, the problem was that multiverse was not enabled on jenkins' side and results were just ignored because the package was not found.
<pitti> jibel: ouch, you mean in our testbed VMs?
<jibel> pitti, no the part that takes the results from the testbed and push them into the queue for britney
<pitti> ah
<pitti> jibel: wow, so we now know that we have exactly one multiverse package with a test :)
<caribou> infinity: had any chance to look at the libnss-ldap merge ?
<jibel> pitti, exactly 4 packages
<didrocks> bdmurray: hey, it seems you didn't push whoopsie 0.2.41 to trunk, mind if I'm doing so?
<pitti> didrocks: just do it
<didrocks> pitti: ok, preparing that. I'm fighting with a FTBFS as well with the current version first (seems some automake targets are not triggered)
<didrocks> pitti: mind pushing lp:~didrocks/whoopsie/0.2.41 to lp:whoopsie? (I don't have commit rights here)
 * didrocks on the FTBFS now
<Laney> builds for me in sbuild, fwiw
<pitti> yeah, was working well for me too
<didrocks> ok, my local system is having hard time thenâ¦ weird as it's make -j1
<didrocks> so not etoomanyprocessesâ¦
<pitti> didrocks: done
<didrocks> thanks
<pitti> didrocks: no automake -- this is a simple Makefile
<pitti> didrocks: make -j4 works just fine here (right out of clean trunk)
<didrocks> pitti: do you have valgrind installed?
<pitti> didrocks: not in my build schroot, but also not on my workstation
<didrocks> that's why it passes :)
<didrocks> if type valgrind >/dev/null 2>&1; then \
<pitti> (I do all builds in schroot, I don't have any -dev installed on my system)
<didrocks> APPORT_REPORT_DIR=/tmp/tmp.ScDOedTr3S ./tools/check_valgrind; \
<didrocks> fi
<didrocks> this is what fails
<pitti> ah
 * didrocks files a bug for now
<infinity> pitti: I'll do the merge, but I thought we already fixed that bug in Ubuntu.
<infinity> pitti: Will look tomorrow, though.
<pitti> infinity: ah, cheers
<infinity> pitti: Oh, maybe someone broke it when they stole my last merge. :P
<infinity> pitti: Anyhow, will check when I'm awake.  Going to ingest a gallon of cough syrup and try to sleep.
<pitti> infinity: ouch, get better soon!
<StevenK> infinity: A gallon? Damn.
<pitti> stgraber: I think I already asked like three times, but I still don't know how: can I tell my ephemeral containers to mount the /delta thing on a tmpfs? at the moment it's hitting the disk, which is not only very slow, but also still tends to kill my SSD (probably a hardware or btrfs bug)
<pitti> I see why this isn't being done by default for possibly RAM limited systems, but I've got plenty of RAM
<sil2100> @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: sil2100
<Laney> LocutusOfBorg1: it failed again, could you look?
<sil2100> @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:
<cjwatson> Logan_: Could you merge salome-kernel, please?  Needed for new hdf5
<LocutusOfBorg1> Laney, I already asked to Gert, the debian maintainer, let me see
<LocutusOfBorg1> I suspect this is due to the newly uploaded gcc 4.9.2
<cjwatson> Logan_: And meep too please, same reason
<LocutusOfBorg1> I'm going to reproduce with pbuilder/vivid and pbuilder/sid, will take a while
<Mirv> any core-dev to ack removal of "libthumbnailer-dev" build dependency from UI Toolkit landing? https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-ui-toolkit_1.1.1311+15.04.20141102-0ubuntu1.diff
<cjwatson> doko: Could you merge libgpiv, please?  Needed for new hdf5
<stgraber> pitti: if you're using lxc-start-ephemeral, then pass --storage-type tmpfs
<LocutusOfBorg1> cjwatson, libgpiv built on debian/ppc64el, so what about sync it? :)
<mzanetti> tvoss: hey, have a situation here on my phone where you might be able to help:
<mzanetti> there's location-service taking 1GB of memory, causing oomkiller to kill the dash every time its respawned
<mzanetti> and location-service's oom score is 452, while the dash is 50
<mzanetti> so 2 issues I guess
<mzanetti> tvoss: want me to fetch some logs for you?
<pitti> stgraber: ooh! thanks!
<tvoss> mzanetti, please file a bug against, https://bugs.launchpad.net/ubuntu/+source/location-service
<tvoss> mzanetti, and please list device and image number
<addiks> hi, when clicking on a background/non-focussed window, which program is responsible for bringing that window to the front, giving it focus and giving the click-event to the program belonging to that window?
<mzanetti> ok. some interesting things (logs) to collect and attach? so far I'd go with dmes, location-service's oom score info and some memory stats
<mzanetti> tvoss: ^
<tvoss> mzanetti, yup
<mzanetti> tvoss: btw, it keeps on leaking memory
<tvoss> mzanetti, not much we can do about it right now
<mzanetti> ok
<cjwatson> LocutusOfBorg1: I'm not going to but doko is welcome to
<cjwatson> LocutusOfBorg1: if he thinks it appropriate
<LocutusOfBorg1> I was just giving my .02$ :)
<cjwatson> that's fine, just don't give it to me in this case :)
<pitti> stgraber: wth -- that reproducibly crashes my machine immediately (need to sysrq+b)
<stgraber> pitti: hmm, that's, unexpected... are you getting a panic or oops or something similar?
<pitti> stgraber: the screen goes off/black, so I don't really see anything
<pitti> I can only sysrq+s+u+b
<stgraber> and nothing interesting in kernel.log post-reboot I assume?
<pitti> stgraber: was OTP, done now; let me check
<pitti> stgraber: nothing relevant at all :/
<pitti> stgraber: I guess I'll try that again without splash/quiet and on a VT
<pitti> stgraber: anyway, when I have more data I'll file a bug (too much other things that keep me busy today)
<stgraber> pitti: you may also want to install linux-crashdump and then turn it on in /etc/default if you don't already have it
<RobertDupont> hello guys
<RobertDupont> I got a packaging question if you guys don't mind
<RobertDupont> I didn't get any useful answer from #ubuntu-packaging
<RobertDupont> anyway, I'm trying to build a package
<RobertDupont> I can build it manually just fine and I thing I pretty much got the thing set-up correctly
<RobertDupont> well, almost
<RobertDupont> I'm trying to package barnyard2
<RobertDupont> and there is autoreconf first then it runs configure
<RobertDupont> during the packaging phase, where it runs the configure, it test for the presence of a bunch of headers
<RobertDupont> nothing unusual
<RobertDupont> it works fine when building in the command line, manually
<RobertDupont> however, within one of those dh_* commands, it adds some stuff when compiling those tests
<RobertDupont> which makes compilation (and thus the test) fail
<RobertDupont> I can see a bunch of different "gcc -c -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat =format-security -D_FORTIFY_SOURCE=2 conftest.c >&5" on the screen
<RobertDupont> basically, you can see the issue is that it adds '=format-security' but there is an extra space
<RobertDupont> I have absolutely no idea where this gets added (and it works just fine when doing manually)
<cjwatson> Do you have a copy of the package and a full build log somewhere?
<RobertDupont> and google didn't return me any useful answer
<rbasak> Looking up dpkg-buildflags and https://wiki.debian.org/Hardening might help you there. That's where the hardening flags come from.
<cjwatson> The actual string in libdpkg-perl used there is -Werror=format-security
<cjwatson> I suspect some foolish bit of the package's build system is attempting to remove -Werror and botching the job
<RobertDupont> cjwatson: is that logged somewhere or do I need to copy the content of the screen?
<cjwatson> Depends how you built it
<cjwatson> debuild leaves a .build file around, sbuild usually does too
<cjwatson> But a copy of the packaging would probablyd o
<cjwatson> *probably do
<RobertDupont> found it
<RobertDupont> I'll paste it somewhere
<RobertDupont> it's in build-area
<cjwatson> Honestly having looked into this I'm not actually that interested in the build log
<cjwatson> Put a copy of the source package somewhere first :)
<RobertDupont> the orig.tar.gz?
<RobertDupont> or the directory containing the debian/ directory?
<cjwatson> .dsc, .orig.tar.gz, and whichever of .debian.tar.* or .diff.gz exists
<RobertDupont> http://demo.ovh.eu/en/c9c928994686b4ddce3d91f4ac466a58/
<cjwatson> Bit more than what I asked for, but OK
<RobertDupont> sorry about that
<cjwatson> RobertDupont: look for the first mention of "Werror" in configure.ac, there's the problem
<cjwatson> that sed needs to be smarter to avoid removing half an option
<RobertDupont> so I guess, there was -Werror=format-security
<RobertDupont> -Werror got removed
<cjwatson> Simplest fix would be:   sed -e 's/-Werror\(^=\|$\)//g'
<cjwatson> That's right
<cjwatson> Though actually even the above isn't quite right, you need a matching change to the grep above it as well
<cjwatson> Can you figure it out from here?
<cjwatson> BTW your debian/rules is wrong in some other ways
<cjwatson> DEB_CONFIGURE_EXTRA_FLAGS is a cdbs thing, and DEB_DH_AUTORECONF_ARG is a misspelled cdbs thing
<cjwatson> Neither will do anything because you're using dh, not cdbs
<RobertDupont> wow, I didn't know
<cjwatson> You should be using override rules for dh_auto_configure and dh_autoreconf instead; see "man dh" and "man dh_autoreconf"
<cjwatson> Also, the #! line should be the first line of debian/rules, not the second; you need to remove the blank line above that
<RobertDupont> thanks a lot
<cjwatson> Hopefully that gets you going a bit further
<cjwatson> no problem
<RobertDupont> oh yeah, it's helping me a lot
<RobertDupont> awesome ;)
<pitti> sil2100: â¥ @ https://wiki.ubuntu.com/LandingTeam
<sil2100> pitti: glad you like it! Remember to poke us whenever you think somethin is missing :)
<ogra_> sil2100, i have somethin missing ... the MilestoneProcess subpage :P ... once olli finally answered in the mail thread :)
<olli> ogra_, yeah, I might be owing you a response
<ogra_> :)
<jdstrand> Riddell: question for you in 1389665
<sil2100> ogra_: hah, it'll land there eventually!
<ogra_> :)
<pitti> slangasek: hey Steve!
<pitti> slangasek: so currently under systemd we don't handle the system clock being in local time (bug 1377258)
<ubottu> bug 1377258 in util-linux (Ubuntu) "/etc/default/rcS: UTC=no: Utopic time is off by 4 hours after boot" [High,Triaged] https://launchpad.net/bugs/1377258
<pitti> slangasek: I put two options there; the other day you seemed quite firmly against using /etc/adjtime for this, so I'd like to ask your opinion about that
<pitti> slangasek: as Debian uses /etc/adjtime for the LOCAL vs. UTC, we keep having a delta in at least two, maybe three packages (and perhaps some which we just didn't spot/change yet)
<pitti> slangasek: personally I'd be in favor of dropping that delta and going with instead of against Debian here; in the end it doesn't matter that much where the setting lives, and in an upstart or systemd world "rcS" isn't quite the most intuitive name either any more :)
<pitti> slangasek: but we can fix it either way
<slangasek> pitti: it does matter, /etc/adjtime is a wrong interface and using it means using it for more than just the TZ setting
<pitti> slangasek: yeah, it's not paying attention to the drift bit, just the utc vs. local option
<slangasek> hmm
<slangasek> ok
<pitti> slangasek: you mean the definition (whereever that lives) of adjtime doesn't include those options?
<slangasek> so in that case it's not buggy, but using this binary file for just the TZ is dumb and we should fix that in Debian
<pitti> binary?
<slangasek> isn't it?
<slangasek> maybe I'm misremembering :)
<pitti> slangasek: the manpages don't seem to document this, I'll google a bit for some POSIXy or similar spec
<pitti> I thought it was just a simple text file with two nubmers for the drift
<slangasek> hmm maybe so
<pitti> we can probably argue at length whether one or the other is more elegant etc, but it seems for both admins (more consistent documentatino between distros) and for us (less delta and less potential breakage due to the diff) it's easier to follow Debian
<pitti> "The correction factor for the RTC is stored in /etc/adjtime" -- thanks for being so precise
<slangasek> pitti: so as long as we are using /etc/adjtime *only* for TZ, then that's fine; my concern is that if we're using adjtime, things will sneak in that assume it should be used for drift
<pitti>         *   # /etc/adjtime
<pitti>          *   0.0 0 0
<pitti>          *   0
<pitti>          *   UTC
<pitti> I found that as the general format
<pitti> TBH I have no idea what those numbers mean, aside from the drift
<pitti> at least hwclock.sh and systemd only look for "UTC" vs. "LOCAL" in the third line, i. e. the equivalent of UTC=yes or no
<pitti> slangasek: ooh! http://www.thegeekstuff.com/2013/08/hwclock-examples/#more-14337
<pitti> not quite a reference, but an explanation at least
<pitti> slangasek: ok, got it: "sudo hwclock --adjust" writes that file, and it has exactly that format
<pitti> slangasek: so in summary, doing the migration sounds pretty much right to me..; WDYT?
<pitti> (bbl)
<bdmurray> Laney: I don't see a utopic upload of webkitgtk for -proposed
<slangasek> pitti: again, my concern is that reinstating /etc/adjtime is going to cause people to start misusing hwclock --adjust
<slangasek> which per Scott's analysis during the upstart implementation, we should not be doing ever
<pitti> slangasek: oh, ok; I didn't actually identify that as the reason of your concern before
<pitti> https://wiki.ubuntu.com/FoundationsTeam/Meetings/2009/0311 references it, but not much explanation
<pitti> slangasek: so, if you happen to have more information about that (why it's a misuse, and what currently keeps people from using --adjust), I'd be very interested
<pitti> but given that it's not very clear, I guess I'll patch systemd to read it from rcS for now
<slangasek> pitti: well, it's a misuse in the context of system boot because it adds sleeps to an op that should be instantaneous :)
<slangasek> system boot / shutdown
<slangasek> maybe we don't need to worry about this in practice
<flexiondotorg> As some of you maybe aware I am working on Ubuntu MATE.
<flexiondotorg> I understand that it is possible to have newer MATE packages uploaded to the 14.04 archive by way of an SRU.
<flexiondotorg> And in fact, this is desirable since the MATE packages in the 14.04 archive are incomplete and broken, so updating them would be for the good.
<flexiondotorg> However, is it possible to retrospectively modify the build tools so that an official Ubuntu MATE 14.04.x could be made?
<flexiondotorg> cjwatson, Your thoughts on the above?
<RobertDupont> cjwatson: I got a few more questions if you don't mind
<RobertDupont> I managed to fix that rule file and a bunch of other things but for some reason, I only see the documentation in the package
<RobertDupont> it seems to do the autoreconf
<RobertDupont> but not the configure and not compiling (and the patch I put in debian/patches (and in series in that directory) don't seem to be applied
<RobertDupont> and it doesn't look like it takes care about the init.d file
<blueyed> I am trying to debug why XBell() is silent for my user (via urxvt; https://github.com/exg/rxvt-unicode/blob/master/src/screen.C#L1971). xkbbell and other terminal emulators work, but they do not use XBell.
<blueyed> It seems like pulseaudio-module-x11 "just" does not handle XBell calls.
<blueyed> Investigation at: http://askubuntu.com/questions/546569/pulseaudio-does-not-ring-bell-through-xbell-function-urxvt
<RobertDupont> cjwatson: I made some more progress but now I'm facing the issue where it removed or forgot to add -Werror=unused-but-set-variable
<RobertDupont> that should be a 'fairly' easy fix
#ubuntu-devel 2014-11-07
<apachelogger> stgraber: I think lxc-info output broke because stdout got messed up or something due to excessively too high load, also code wise it didn't make sense that for example the Name: line would be repeated so for now I'll let it pass as a load problem and keep an eye out
<kees> tedg: if I have a gtk application, and it doesn't show menus due to whatever has been done to shove menus into the global menu bar... and I'm not running compiz.. how do I get my menus back?
<mdeslaur> kees: what app is it?
<mdeslaur> kees: chances are they migrated to gtk appmenus
<mdeslaur> kees: oh, if you're not running the menu indicator, you can launch the app with UBUNTU_MENUPROXY=0
<Bluefoxicy> that reminds me, I have to find the tweak that puts menus back somewhere sane
<Bluefoxicy> I'd like to think one day, in 5 or 10 years, people will awaken from whatever confusion of ideas leads them to put menus at the top of the desktop space
<Bluefoxicy> but I'm well aware that certain inobvious facts are hopeless to reason a normal person into
<Bluefoxicy> It's not UI designers that put menus at the top of the screen; it's programmers who think it's a good idea
<Bluefoxicy> they have the mistaken belief that the screen has an origin point, that the top left corner is (0,0), and that this has some meaning
<mdeslaur> Bluefoxicy: menus are going away, they're all being put in hamburger icons now
<Bluefoxicy> in truth, the computer screen is an artificial idea.  It's a position in space; the relative position of a window on that screen is also a position in space.  If you move the screen, you can move the window to put it back into the same position in space it was previously occupying
<mdeslaur> Bluefoxicy: so you're saying Apple doesn't have UI designers? :P
<Bluefoxicy> ... and then the menus have moved.
<Bluefoxicy> mdeslaur: apple has a paradigm.
<Bluefoxicy> It's well-known Apple does things the way Apple does them because either A) that's how Apple does it; or B) it's different and shiny and distinctly Apple (this is how Apple gets new things done the way Apple does them)
<Bluefoxicy> anyway the simple version is this:  a window is a concrete, independent object; the desktop around it isn't.  Moving the window moves it arbitrarily relative to the desktop, meaning it moves the relative position of the window and the menu.
<Bluefoxicy> When working within an application--when working on a sketch pad in real life, or any other physical object--the workspace shrinks down to that object.  In real life, you can reach to the same spatial position and grab something, so multiple things in your workspace are easily handled.
<Bluefoxicy> On a computer, you manipulate a pointer device.
<Bluefoxicy> Rather than reach to the absolute position on-screen, you have to judge the relative positions of objects in the full workspace (the whole screen) before moving from one to another.
<Bluefoxicy> Putting the menus away from the application window means suddenly having to assess where the menu is in relation to the window when you want to use the menu
<Bluefoxicy> That's the cold truth.  There are other esoteric arguments, like working with multiple windows with their own menus (seriously, two clicks instead of one); but the basis of it is that an application window is a whole thing, and putting the window at the top of the screen separates it into two things.
<RAOF> Unless the menu is in an absolute location, in which case it's always âmove the pointer top leftâ?
<Bluefoxicy> RAOF: how far is the top left?
<RAOF> Doesn't matter
<RAOF> There's an edge.
<mdeslaur> it's always in the same place :)
 * RAOF â lunch, anyway :)
<sarnold> besides vim doesn't have menus anyhow
<Bluefoxicy> For me to traverse the entire screen can become physically challenging.  Particularly, I can't reach the bottom right; top-right corner is actually the easiest position for a right-handed person
<Bluefoxicy> of course, I'm using a single 32 inch display
<Bluefoxicy> a WIDE SCREEN 32 inch display
<mdeslaur> Bluefoxicy: so you must be happy that you can move the menus back to windows in Ubuntu 14.04
<Bluefoxicy> mdeslaur:  I'm having an odd time where some of my applications have menus in windows, and others have no menus and I've recently discovered how to access the menu
<Bluefoxicy> LibreOffice has a menu bar, but also a top menu that brings up Preferences, About, Help, and Quit
<mdeslaur> wow, that's weird
<Bluefoxicy> try grokking that.  I have two menus, one in-window and one out, in LibreOffice
<Bluefoxicy> and menu->preferences is the same thing as tools->options
<mdeslaur> Bluefoxicy: what desktop environment are you seeing that?
<Bluefoxicy> mdeslaur:  14.10 Gnome shell here
<mdeslaur> ah, yeah, gnome split the menus in half
<Bluefoxicy> Well
<Bluefoxicy> that's stupid.
<Bluefoxicy> I'll add that as #3 on my list
<mdeslaur> yes, I definitely agree
<mdeslaur> I don't like that at all
<Bluefoxicy> #1 is the alt-tab behavior (applications instead of windows) in gnome-shell, which is so useless I no longer use alt-tab at all, ever.
<sarnold> what was #1 and #2? :)
<mdeslaur> wow, I didn't realize people still used alt-tab
<Bluefoxicy> The most productive feature of the desktop environment--Gnome's old alt-tab behavior, where it grouped (Current desktop | other desktops) and would bypass the separator if you tabbed QUICKLY--has been turned into a pile of garbage
<mdeslaur> isn't that a windows thing?
<Bluefoxicy> Old Gnome did alt-tab well
<Bluefoxicy> it was great if you were swapping between precisely two windows on the same desktop (on different desktops, just use ctrl+arrows to swap desktops back and forth)
<Bluefoxicy> Often I'd be typing a response to an e-mail, and be able to tab between Thunderbird and the Compose window
<Bluefoxicy> thus I could scroll a long e-mail in the main mail window, rather than scroll around in my quoted reply; or look at a different e-mail in a thread for reference
<Bluefoxicy> with new Gnome, you hit alt-tab and it goes, "Well, your last window was Thunderbird.  So is your current one.  You must want CHROMIUM ON ANOTHER DESKTOP!" and takes you away
<Bluefoxicy> no, my last window was another Thunderbird window, and that's what I want to tab back to.
<Bluefoxicy> anyway
<Bluefoxicy> #2 is that they altered the scroll wheel behavior in Activities
<Bluefoxicy> Activities is the reason I use gnome-shell.
<Bluefoxicy> it shows you an exposÃ© view of a single desktop, and you can move up and down through desktops, created dynamically.
<Bluefoxicy> You can drag windows to other desktops, or between desktops (to create a new one); and you can just type and it'll give you the application you want to launch.  So awesome
<mdeslaur> in Unity, you can use Alt-# to switch between windows of the same app
<Bluefoxicy> Previously, scroll wheel did mnay things.  Notably, moving the pointer over the virtual desktops and scrolling would move you up and down; while pointing at a window and scrolling would zoom in and out on it without having to leave Activities view, raise the window, and change pointer focus.  Leaving activities view sent you back to the window last used on the current desktop
<Bluefoxicy> now, scroll wheel ALWAYS switches desktops
<Bluefoxicy> I can't get a closer look at a small window in a cluttered desktop by zooming
<Bluefoxicy> so, I will make split menus in Gnome-shell my gripe #3
<mdeslaur> sounds like gnome-shell isn't for you
<sarnold> control+scrollwheel? alt+scrollwheel? numlock+scrollwheel?
<Bluefoxicy> gnome-shell is the best desktop I've used in history.
<Bluefoxicy> I've used KDE, enlightenment, and even recent versions of xfce4 and unity
<Bluefoxicy> unity is MUCH lighter than gnome-shell
<Bluefoxicy> bring 2GB of RAM if you want to run gnome-shell.  Bring under a gig if you want Unity.  But I can accept that.
<Bluefoxicy> That doesn't mean it isn't broken in a few places
<Bluefoxicy> It's like a golf club
<sarnold> wow, coming from i3-wm land, unity feels huge and bloated :)
<Bluefoxicy> almost a straight stick, except for that bit at the end
<Bluefoxicy> sarnold:  I used to use icewm exclusively for a few months too :)
<mdeslaur> activities sounds a lot like what Super+S does in unity
<Bluefoxicy> does it?
<sarnold> .. icewm was the first win95-alike window manager, right?
<Bluefoxicy> I thought Unity just brought up the 4 desktop quadrants
<Bluefoxicy> and there are only 4 desktops; you can't drop windows between them to create new desktops, and it doesn't auto-destroy empty desktops.
<mdeslaur> oh, I missed the part where you can launch apps
<mdeslaur> right, and the dynamic number of tem
<mdeslaur> them
<Bluefoxicy> the Windows key goes straight into Activities on Gnome.  I tend to tap teh top left corner; really, hitting the Super key if you want to launch an app is better, since navigating the applications menus is ... a feature that should be left in for the curious alone.
<mdeslaur> ok, so not similar at all
<Bluefoxicy> never bother navigating the applications menu
<Bluefoxicy> it's a pointless exercise
<dupingping> Hi I hope become a ubuntu devel member.
<dupingping> What do I do to do it?
<Bluefoxicy> super -> s o f -> "Software Updater" "Ubuntu Software Center" "Additional drivers" -> click or use arrow keys to select the application to launch
<Bluefoxicy> unity has a search bar too though.
<Bluefoxicy> last I checked, it doesn't pick up immediately if you start typing; you have to explicitly tell it you want to search.
<Bluefoxicy> anyway
<Bluefoxicy> haha.  I remember how awesome Gnome's deskbar was supposed to be
<Bluefoxicy> and that it never actually worked (it crashed a lot)
<Bluefoxicy> by the time it was shaped up, nobody cared anymore
<kees> mdeslaur: makerware! :)
<kees> mdeslaur: UBUNTU_MENUPROXY=0 did not work.
<kees> oh, whoops, it's Qt not GTK
<kees> https://bugs.launchpad.net/ubuntu/+source/appmenu-qt/+bug/1045640 <- maybe?
<ubottu> Ubuntu bug 1045640 in appmenu-qt (Ubuntu) "Menu not showing up for some Qt apps" [Undecided,Confirmed]
<pitti> Good morning
<LocutusOfBorg1> Laney, what happens if I cannot reproduce the insighttoolkit amd64 failure in a clean pbuilder-dist vivid environment?
<LocutusOfBorg1> I build it successfully with sid and vivid both amd64
<LocutusOfBorg1> I can mail you both build logs
<pitti> Riddell: hmm @ https://launchpad.net/ubuntu/+source/kde-workspace/+publishinghistory
<Laney> LocutusOfBorg1: Erm, does it work in a PPA?
<pitti> Riddell: so kde-workspace got removed in vivid, then apparently reintroduced with a security update, which failed to upload everywhere (https://launchpad.net/ubuntu/vivid/+source/kde-workspace/4:4.11.12-0ubuntu2)
<pitti> Riddell: and stuff like kdevelop needs kdebase-workspace (https://jenkins.qa.ubuntu.com/job/vivid-adt-kdevelop/12 just failed)
<Laney> bdmurray: looks like I forgot to push upload maybe
<Laney> bdmurray: there
<pitti> Riddell: I take it kdevelop and friends will be updated to thew new plasma-workspace, so that's temporary, but there was apparently some confusion about reintroducing kde-workspace?
<Riddell> pitti: I uploaded the kde-workspace security, realised that wouldn't work since we had plasma-workspace to replace it and deleted kde-workspace
<Riddell> pitti: there will be stuff like kdevelop that I need to fix up now yes
<pitti> Riddell: ah, so we'll need to delete it again, I figure?
<Riddell> pitti: did it reappear?
<pitti> Riddell: https://launchpad.net/ubuntu/vivid/+source/kde-workspace/4:4.11.12-0ubuntu2 is in vivid-proposed (the source)
<pitti> the binaries failed to upload
<Riddell> pitti: oh I guess I need to delete it from -proposed as well, no problemo
<pitti> doko_: btw, gcc-4.9 has been a "valid candiate" since yesterday, but http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt complains about some uninstallability (i386: libstarpu-dev)
<pitti> doko_: that one depends: gcc-4.9 (<< 4.9.1A) (WTF??)
<pitti> doko_: looks like it's autogen'ed, I'll check if a rebuild fixes it
<pitti> doko_: yep, helps; uploaded
<cjwatson> flexiondotorg: I'm generally stepping back from this stuff over the next couple of months (see my blog), so it would be advisable to find somebody else release-team-ish to help you out.  If you have packages in trusty-updates then riding along with the next point release ought not to be horribly difficult, I'd have thought, maybe
<lifeless> cjwatson: good luck with the move, hope it achieves your goals!
<cjwatson> lifeless: thanks :)
<Tribaal> hi all. Who should I talk to to resync the bzr branches for a particular package? It seems the branches are out of date compared to what is uploaded.
<geser> Tribaal: have you checked if it's listed on http://package-import.ubuntu.com/status/ with a reason why it failed?
<Tribaal> geser: I hadn't, and it seems to be listed there indeed
<Tribaal> geser: I'm not sure I understand what the failure means, however
<geser> in most cases it either a bug or the package importer found the branch in a state which it can't handle on it's own
<cjwatson> The whole package-import system is pretty much unmaintained at this point; any substantial bugs probably won't be fixed.  Should be much easier to do with git.
<Tribaal> so, it's this bug: https://bugs.launchpad.net/udd/+bug/494481
<ubottu> Ubuntu bug 494481 in Ubuntu Distributed Development "Too easy for people to not use merge-upstream" [High,Triaged]
<Tribaal> I'd like to fix the situation for the package I'm interested in (landscape-client)
<Tribaal> geser: so, what is the "current best" way to go?
<cjwatson> Surely for landscape-client you should *not* be using UDD anyway, but rather proposing merges to lp:landscape-client.
<cjwatson> The parallel import is counterproductive there.
<Tribaal> cjwatson: so, what I'm currently trying to do is: build and release a new landscape-client pacakge to Ubuntu (starting with devel). Last time this involved attaching debdiffs to bugs, and was quite painful for everyone involved. So I suspect there is a better way to do it, and I'm trying to find what that is.
<Tribaal> I thought it would be udd, but apparently not :)
<cjwatson> UDD is not likely to make anything less painful at this point.
<Tribaal> cjwatson: hehe noted :)
<cjwatson> I don't quite get why you wouldn't just branch lp:landscape-client as needed.
<Tribaal> cjwatson: so, maybe I misunderstand how the process works then. Let's say we'r ready to release now, I branch, push a "landscape-client-14.10" or whatever to lp. What happens then?
<Tribaal> (how do we go from  lp branch to an available deb package)
<ogra_> you make your branch a merge proposal against lp:landscape-client
<ogra_> upstream merges it and releases a package from it
<Tribaal> we do this on a daily basis, and merge on a daily basis
<Tribaal> I am upstream :)
<mdeslaur> kees: perhaps just uninstall appmenu-qt and appmenu-qt5?
<Tribaal> I'm trying to figure out "..and releases a package from it" :)
<cjwatson> you build and upload it from the relevant branch
<cjwatson> "debuild -S" or "bzr bd -S" or whatever
<ogra_> yoou call bzr bd in the branch
<Tribaal> ok
<Tribaal> and the SRU process remains debdiffs?
<cjwatson> the SRU process does not require attaching patches of any kind ...
<cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates
<cjwatson> however if it is useful to point to the specific broken-down commits (and it may well be) you can just link to the commits on LP
<Tribaal> well, so, we need a branch per release we target, at least
<cjwatson> Sure
<Tribaal> ok, I think I'm starting to see things a bit more clearly
<Tribaal> thanks
<cjwatson> np
<Tribaal> I will probably shoot more questions - but at least that's a good start
<Tribaal> :)
<LocutusOfBorg1> I need a builder with at least 60GB of space, because insighttoolkit needs 55 and doesn't finish the build :(
<LocutusOfBorg1> I tried to package the new release on costamagnagianfranco/locutusofborg-ppa
<LocutusOfBorg1> to help finish the itk transition
<LocutusOfBorg1> s/itk/gdcm
<mdeslaur> cjwatson: my google-foo is failing me...what mounts /boot/efi at boot?
<cjwatson> mdeslaur: should be in /etc/fstab
<cjwatson> put there by partman-efi
<mdeslaur> cjwatson: hrm, ok, thanks
<bdmurray> Laney: did you want 2.4.6 in trusty or 2.4.7?
<Laney> bdmurray: 7, did I miss that one too?
<Laney> I probably dputted them at the same time and missed some error
<bdmurray> Laney: its still 2.4.6 in the trusty queue
<Laney> okay I just uploaded .7
#ubuntu-devel 2014-11-08
<Wizard> I've built unity8 from trunk.
<Wizard> Is it possible to install it system wide?
<Wizard> Default package available in vivid fails.
<Wizard> Nah, sources contain debian control files :D
#ubuntu-devel 2015-11-02
<FourDollars> Why can we use some kind of suffix like 6.14.04.1 in https://launchpad.net/ubuntu/+source/partman-efi for trusty? In there any documentation for this kind of rule?
<darkxst> FourDollars, the rule is that an SRU version can't conflict with any past or future versions of the package
<FourDollars> darkxst: OK. So can I use 25ubuntu6.20151102.1 if the previous version is 25ubuntu6?
<darkxst> FourDollars, well you could, but dates are usually used for vcs snapshots
<FourDollars> darkxst: How about 25ubuntu6trusty1? Is it also valid?
<FourDollars> darkxst: The precise version used 25ubuntu1.2 for 25ubuntu1. I am wondering why the trusty version used 25ubuntu6.14.04.1 for 25ubuntu6.
<darkxst> FourDollars, well that would be greater than the version that copied into utopic, so no
<darkxst> 25ubuntu6.14.04.1 or 25ubuntu6.1, would have been equally fine
<darkxst> and they are the two most common forms of SRU versions
<FourDollars> darkxst: I guess using 14.04 is to indicate this change is used for trusty, right?
<darkxst> FourDollars, yes
<darkxst> also if there had been a 25ubuntu6.1 in utopic before the trusty upload that could not have been used either
<darkxst> that kind of situation would probably only happen with projects with dead or slow upstream releases though
<FourDollars> darkxst: 25ubuntu6.14.04.1 is also greater than the version that copied into utopic. Why is it OK?
<darkxst> FourDollars, sorry itss the other way around, you can't upload 25ubuntu7, because that would be a possible future version
<darkxst> so  6trusty1 would be ok
<FourDollars> darkxst: OK. I see. Thank you for your explanation.
<dholbach> good morning
<Odd_Bloke> pitti: Xenial images for you to play with are at http://people.canonical.com/~dwatkins/20151028/
<Odd_Bloke> :)
<nikolam> Hi, shouldn't I have btrfs-tools with same version as the kernel in LTS? I have 3.19.0-31 kernel and 3.12-1 btrfs-tools and I am having an issue with very slow Btrfs send...
<highvoltage> /win/win /win 26
<highvoltage> (lol sorry)
<ogra_> what a winner you are today :)
<nikolam> winnner of windows 3.1 starting with win ?
<Mirv> Laney: would the "Please add packages to qt5 package set" thread on devel-permissions need something more still.I did a proposal two weeks ago, but then obviously there was release rush etc so I can see why it'd be easily forgotten again.
<Laney> Mirv: I don't remember, sorry, let me check on it shortly
<Mirv> Laney: ok, thanks, no hurry
<seb128> hum
<seb128> $ ./process-removals -s obexd
<seb128> INFO:root:obexd (0.48-2.1): back in sid - skipping.
<seb128> but no
<seb128> $ rmadison -u debian obexd
<seb128> obexd      | 0.28-1        | oldoldstable | source
<seb128> obexd      | 0.46-1        | oldstable    | source
<seb128> wth?
<didrocks> Comment: (From Debian) ROM; obsolete; Debian bug #772094
<ubottu> Debian bug 772094 in ftp.debian.org "RM: obexd -- ROM; obsolete" [Normal,Open] http://bugs.debian.org/772094
<didrocks> Remove [y|N]?
<didrocks> with process-removals here
<didrocks> (I didn't accept yet, the warning is after it?)
<cjwatson> seb128: you probably have an old cached Debian_something file in your current dir
<cjwatson> process-removals is kinda ropey
<didrocks> yeah, I check on my Sources.gz that were downloaded, no reference for sure
<didrocks> seb128: want me to ack?
<Laney> FourDollars: Do you have an XPS 13 with 14.04 on it to check the fix for https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1480217 ?
<ubottu> Launchpad bug 1480217 in nautilus (Ubuntu Trusty) "Nautilus background handling screwed when changing scaling factor." [High,In progress]
<seb128> didrocks, if you want
 * didrocks flushes
<didrocks> Laney: FYI ^
<seb128> cjwatson, indeed I had, thanks for pointing that out
<seb128> Laney, did larsu fix the icons issue as well now?
<Laney> looks ok to me
<cyphermox> good morning!
<teward> does anyone know how apport / ubuntu-bug detects duplicate bugs?  Second related question is if it can detect duplicate package-type bugs based on a given signature...
<seb128> slangasek, your python-pgmagick no change rebuild failed, the new version (pypi.debian.net/pgmagick/pgmagick-0.5.12.tar.gz) add compat for the graphicsmagick version if you want to do the update
<slangasek> seb128: thanks, that build failure was on my list of things to look at
<FourDollars> Laney: Yes, I have an XPS 13 with HiDPI screen.
<Laney> FourDollars: with 14.04, right?
<FourDollars> Laney: Let me check.
<FourDollars> Laney: Yes, it is with 14.04.
<Laney> FourDollars: ok, could you check with the debs in http://people.canonical.com/~laney/package-junkyard/ please?
<dobey> teward: the bugs that apport marks as duplicate, matches the stack signature afaik
<FourDollars> Laney: Yes, it seems to fix the issue.
<Laney> FourDollars: thanks
<FourDollars> Laney: np
<davmor2> Laney: does that let me off the hook or do you want a second confirm?
<Laney> davmor2: you can verify it from trusty-proposed later on if you want :P
<dholbach> can somebody moderate my mail on u-d-a?
<cjwatson> dholbach: done
<dholbach> thanks cjwatson
<teward> dobey: OK, so no way to make an apport bug detect something from the report attachments itself, then, to determine a duplicate...?
<NikTh> Hello, anyone else getting similar errors ? https://launchpadlibrarian.net/224027178/buildlog_ubuntu-trusty-amd64.linux_4.3.0-00.201511021933_BUILDING.txt.gz
<NikTh> Found this one, seems similar but... no coding here :-) https://lkml.org/lkml/2015/9/11/644
<pitti> teward: there is; normally through the signature of the stack trace, but we also have plenty of "patterns" to match on e. g. dpkg log files or X.org logs
<dobey> what pitti said
<pitti> http://bazaar.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns/files
<pitti> teward: ^
<teward> pitti: does that work from output of commands done by package hooks?  The reason I've been asking is there is a *substantial* number of bugs being filed against 'nginx' for "Could not bind to *:80: Address in use" errors, and they come up in most of the bug reports seen.  Thanks to the apport hooks i can tell what causes the install/upgrade postinstall failure (it's that), but... trying to eliminate some work :p
<teward> pitti: thanks i'll peek
<pitti> teward: yes, on any field of the report, doesn't matter
<sarnold> NikTh: maybe add libssl-dev to your Build-depends: line?
<teward> pitti: OK, i'll start poking and peeking.  Thanks.
<NikTh> sarnold: Thanks. Let me try.
<sarnold> NikTh: (I haven't verified that that package has the file you need, it just doesn't appear in your build logs and seems plausible)
<teward> sarnold: betcha it's openssl-dev not being installed.
<teward> sarnold: apt-file shows openssl-dev as installing that file to /usr/include/openssl/opensslv.h so...
<teward> (with regard to NikTh's issue)
<teward> (at least in Trusty)
<NikTh> sarnold: I have the trusty's config files as they are. I have changed nothing except adding my <e-mail> there (in control files)
<sarnold> teward: heh, N: Unable to locate package openssl-dev
<teward> oops
<teward> libssl-dev
 * teward yawns
<teward> sarnold: E:NoCoffee
<teward> :)
<NikTh> haha :)
<sarnold> :)
<NikTh> Ok, libssl-dev it is, then. I will try this one. :)
<teward> Thank goodness, coffee's here.  *steals a "Box o' Joe" and gets to developer work*
<teward> pitti: so, then in the bug patterns XML file, key would be whichever item grabbed by the package hooks I want to look at, and regex-matching?  *trying to wrap head around the apport bug pattern detection*
<pitti> teward: right; the README file hopefully explains the basics of it
<teward> ok
<teward> you know what the page didn't show me?  The README file
<teward> >.<
<teward> pitti: that reminds me, I have a typo in my package hooks... oops.
 * teward should fix that xD
<teward> pitti: with regards to apport and duplicate detection, how does that work if we have different versions in different releases that will have different report data?  (Vivid+ has my apport hooks, Trusty and earlier don't and use different files for the data...)
<pitti> teward: I guess you'd create two patterns, one for vivid+, one for trusty?
<teward> ok
<teward> works for me, for now i'll focus on vivid+ 'cause that's where the hooks exist, i'm still ironing out the trusty/precise ones.
<teward> thanks
<teward> pitti: would you be able to spot-check for blatantly obvious evil errors in my pattern that i've written locally?
<pitti> teward: sure! pastebin the diff?
<teward> will do shortly, in the middle of beating an nfs share 'cause i need the data there :P
<sil2100> cjwatson: hey! So, would it be possible to move the LP weekly translation exports for ubuntu-rtm/15.04 a day later? (on Wednesdays) I remember the rationale for it being set for Tuesdays was that it's hard to schedule as normally those take a lot of time to create
<sil2100> cjwatson: but the 15.04 ones actually build in 5-10 minutes
<sil2100> cjwatson: you think that would be doable?
<teward> pitti: i'm going to thoroughly test this of course but in the interim:  http://paste.ubuntu.com/13085614/
<teward> my regex-fu is not super strong though
<pitti> teward: hm, that bug doesn't actually have a SystemctlStatusFull_Nginx.txt attachment, but I suppose one of the dupes
<teward> pitti: no, that bug doesn't, it's the master
<pitti> teward: ( and ) are magic in REs, so you need to escape them
<teward> there's multiple dupes, I got tired of canned-responsing
<teward> ok
<teward> pitti: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1495805 is one of the 'dupes'
<ubottu> Launchpad bug 1512344 in nginx (Ubuntu) "duplicate for #1495805 [Master Bug] Package nginx-* failed to install/upgrade due to Port 80 not being able to be bound to, due to "Address In Use" errors." [Undecided,Invalid]
<pitti> teward: you can run ./test-local <supposed dupe> to make sure your pattern works
<teward> OK
<pitti> teward: so if you run it now against a dupe, it will most probably say that it didn't find a match
<teward> pitti: i also have a typo in my apport hook which is going to be fixed soon so this is a 'testing first' before 'suggest inclusion' (gotta fix the apport hooks, gotta merge)
<teward> pitti: ok.
<teward> i'll do testing, but the blatantly obvious errors were the regex :)
<pitti> teward: perhaps say "failed.*98: Address already in use" to avoid having to match the parentheses?
<teward> mmm... that'd work.
<pitti> teward: and then ./test-local should recognize it as a dupe
<teward> will test that, thanks pitti
<henrix> utlemming: the fixes for bug #1454758 have been applied to the Precise kernel, but it looks like they should actually be applied to the linux-backports-modules-3.2.0 instead.  could you confirm this?
<ubottu> bug 1454758 in linux (Ubuntu Precise) "[Hyper-V] storvsc: Set the SRB flags correctly when no data transfer is needed" [Critical,Fix committed] https://launchpad.net/bugs/1454758
<henrix> utlemming: (apw suggested me to ping you ;) )
<henrix> utlemming: this caught my attention because this seems to break the -lbm build
<teward> pitti: who has to do the review of a merge though, once I have this 'tested' and 'working'?  Do I just make a merge req?
<sil2100> slangasek: https://bugs.launchpad.net/ubuntu/+source/hevea/+bug/1512467
<ubottu> Launchpad bug 1512467 in hevea (Ubuntu) "Release no-change rebuild for ocaml transition" [Undecided,In progress]
<teward> pitti: test-local's causing "file stream must be in binary mode" errors, 15.04 testing.  Passing it the path for the .crash file, is this normal?
<sil2100> slangasek: thanks for sponsoring!
<slangasek> sil2100: no prob
<cyphermox> slangasek: should we be looking at the ocaml transition in particular?
<sil2100> cyphermox: I'm working on that now
<cyphermox> yeah
<sil2100> Moving steadily with the bleh rebuilds
<cyphermox> I know, that's why I'm asking; I think we want to avoid duplicating work, but there is a lot of ocaml anyway
<sil2100> I might be done somewhere tomorrow since I want to spend most of my time there
<slangasek> cyphermox: sil2100 is driving it, I don't know that it needs more eyeballs currently
<cyphermox> slangasek: I figured; I picked $random !ocaml.
<cyphermox> sil2100: are you using update-output-helper too?
<sil2100> cyphermox: no, not sure if I know that one, I use chroots, check if it installs and why not and rebuild/fix
<sil2100> I have a script that does the no-change rebuilds for me
<cyphermox> sil2100: ok
<teward> pitti: nevermind, i fixed it although I had to generate another bug to test it.  Looks like the pattern, with your help, matches and spits out the 'master bug' for the issue I created earlier today.  How do I go about getting it included in the apport patterns?
<teward> (I'll upload a new branch just for that)
<NikTh> sarnold: I've passed the error with openssl because of your suggestion and thanks. Any thoughts in the new error? http://pastebin.com/raw.php?i=6HM0WzCc
<sarnold> NikTh: look higher up in the build log
<NikTh> sarnold: if it matters this lines occur immediately after "  LD      drivers/built-in.o"
<NikTh> these
<NikTh> hmm, maybe I have to paste the full log ? I'm trying this local now (pbuilder)
<sarnold> if it's immediately after the LD .. line then you may need to add V=1 to the top-level make command to figure out what exactly died
<NikTh> sarnold: I will try this. Thanks.
<pitti> teward: re (sorry, meeting)
<pitti> teward: just do an MP and I'll review/merge it
<teward> pitti: OK, will do, gotta poke a few things
<teward> pitti: the test-local doesn't work with .crash files though
<teward> (see the error I said it printed earlier)
<teward> in which case the 'usage' help on it should be updated perhaps
<pitti> teward: no, just with LP bugs, as that's what it operates on
<teward> OK
<teward> pitti: (the actual executable says to pass it a .crash file path though or an LP bug)
<pitti> teward: oh, ok; sorry, it's been ages since I've used it
<teward> "Usage: %s <.crash file or bug number>", line 27 :)
<teward> pitti: i'll have a bugpatterns update, but then i may go poking at the script, propose a few changes if it only works with LP bug numbers.
<teward> give me a few minutes, gotta change wireless APs.
<pitti> teward: that would be appreciated
<teward> pitti: feel free to reject if the target bug is not satisfactory, I have another bug avaialble that can be the target.  Merge Req. against the bugcontrol repo, or the lp:apport project?
<pitti> teward: against the branch you branched it off, i. e. the ubuntu-bugpatterns one
<teward> ack
<teward> pitti: https://code.launchpad.net/~teward/apport/ubuntu-bugpatterns-nginx/+merge/276471 is the merge, let me know :)
 * teward has no issues if it's rejected
<pitti> teward: pulled, thakns!
<teward> eheheheheh, i spammed myself 'cause it's a bugcontrol branch xD
<teward> pitti: thank you for pulling it in :)
<teward> i appreciate all the help from you and others on the apport bug stuff (both the package hooks and the dupe detection)
<teward> pitti: if I happen to update the report attachment name in Xenial (as a result of fixing a couple typos in my hooks), I assume i'll have to make an update to the bugpatterns?
<pitti> teward: right; you should duplicate the entire pattern clause and adjust the key name if that changes
<teward> pitti: it may or may not change, depends on whether the tiny typo (it duplicates the .txt extension twice on attachments) really irritates me that much :P
<teward> i'll let you know when I have any such changes :)
<teward> again, thanks for your help though :)
<sil2100> Does anyone know who's the current maintainer of our transition tracker code? lp:ubuntu-transition-tracker
<pitti> teward: the key="" value itself is not a re, the re matching applies to the contents of the key
<pitti> teward: so this does need a new rule then
<teward> ok
<teward> pitti: right, i know it isn't a re, just wanted to make sure that's what I'd have to edit if i fix the typo in the hooks :)
<teward> as it stands it's so minor that it's not really needing fixing - doesn't affect the report much
<sil2100> slangasek, other-core-devs: could anyone sponsor https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.5/+bug/1512502 for me?
<ubottu> Launchpad bug 1512502 in llvm-toolchain-3.5 (Ubuntu) "Release no-change rebuild for ocaml transition" [Undecided,In progress]
<slangasek> sil2100: done
<sil2100> slangasek: thank you!
 * sil2100 feels silly uploading so many no-change rebuilds
<sil2100> Free karma I suppose
<slangasek> ;)
<Unit193> You know what they say about Karma...
<NikTh> sarnold: If this helps you , because I cannot understand what is happening. http://pastebin.com/raw.php?i=f6sNZvEL
<sarnold> NikTh: sorry, I can't spot anything unusual or incorrect
<sarnold> NikTh: it's possible that the error is still earlier in the log, I guess
<NikTh> sarnold: no problem. Thanks for all your help till here. Maybe it's my misconfiguration after all (in debian.master/ folder , because I've changed too many things there). I will try tomorrow again. bb.
<sarnold> good luck :)
<cjwatson> sil2100: I expect we can find some time when it won't collide with other things, but please could you remind me during the daytime or send me mail or something so I'll remember?
<sil2100> cjwatson: sure! Thanks :)
#ubuntu-devel 2015-11-03
<ePierre> Hi everyone!
<ePierre> I'm working in the Checkbox team <https://launchpad.net/checkbox-project> and we just raised two issues to get packages removed from Xenial repositories: pad.lv/1512641 and pad.lv/1512642 ; please let me know if there are anything else I need to do or provide for this to happen. Thanks!
<Mirv> has anyone running 14.04 LTS been able to workaround bug #1497420 to attach to xenial lxc?
<ubottu> bug 1497420 in lxc (Ubuntu) "systemd 226 (moving pid 1 into /init.scope cgroup) breaks lxc-attach" [High,Triaged] https://launchpad.net/bugs/1497420
<mardy> seb128: hi! Did you have time to look at https://requests.ci-train.ubuntu.com/#/ticket/446 ?
<Laney> utlemming / Odd_Bloke / smoser: know when we'll get the first cloud images?
 * Laney is trying to use adt-buildvm-ubuntu-cloud :)
<Odd_Bloke> Laney: We're doing a major rework of how we build images for xenial, so dailies on cloud-images.ubuntu.com aren't imminent.
<Odd_Bloke> Laney: I did point pitti at some sample images for him to test out, but I don't know that he's managed to get to them yet (I believe he's sprinting this week).
<Laney> Odd_Bloke: OK, thanks, I'll check if a-b-u-c can use those somehow
<pitti> Odd_Bloke: oh, you did? sorry, missed them
<pitti> Odd_Bloke: ETA 4 hours, go hotel network :)
<mgedmin> huh, collectd in debian testing is 5.5.0; collectd in xenial is still 5.4.1
<mgedmin> ah, judging from the .ubuntu1 version it needs a merge
<seb128> mardy, sorry for the delay, published now
<mardy> seb128: nw, thanks a lot! :-)
<mardy> seb128: ah looks like it failed
<mardy> seb128: packages changed in the archive, let me sync them...
<seb128> mardy, if they are no change upload we can override
<seb128> but please check if there is content to include
<mardy> seb128: ok, I'll let you know in a minute
 * mgedmin finds and reads https://merges.ubuntu.com/c/collectd/REPORT
<mardy> seb128: yes, all three are "no change rebuild"
<seb128> mardy, ok, published again with override which worked
<Odd_Bloke> pitti: :)
<mardy> seb128: thanks!
<seb128> mardy, yw!
<rbasak> pitti: taking the nis merge to work on with cpaezler. I trust that's OK.
<pitti> rbasak: please
<rbasak> Thanks
<pitti> rbasak: no, thanks to you :)
<pitti> Odd_Bloke: http://people.canonical.com/~dwatkins/20151028/ amd image is working fine here! I tested it with local qemu, not with an actual cloud, but I guess you already did that
<seb128> what's the way to let britney to let a package through if it reduced the list of archs it's building a binary on? deleting the binary for those archs in the release pocket?
<cjwatson> seb128: that
<cjwatson> though obviously check reverse-dependencies first
<seb128> right, I just did
<seb128> it's for xserver-xorg-video-vmware
<seb128> (I hope I didn't overlook thing)
<seb128> cjwatson, thanks
<mardy_> seb128: the message about the packages being "in the proposed pocket", does it mean that it's all right, or is it an error? https://requests.ci-train.ubuntu.com/#/ticket/446
<seb128> mardy_, it's normal, things go through proposed and migrate when/if they are ok (tests passing, not creating un-installability issue, etc)
<mardy_> seb128: ok, thanks
<seb128> mardy_, see https://wiki.ubuntu.com/ProposedMigration if you are interested by the detailzs
<ogra_> cjwatson, infinity, does either of you know how live-build enforces immediate execution of triggers ? (i have a problem installing the raspi2 kernel package during a livefs build, afaik it is 100% based on the -generic package so it should work, yet it defers the update-initramfs trigger, so the postinst fails) https://launchpadlibrarian.net/224109673/buildlog_ubuntu_xenial_armhf_ubuntu-core-system-image_BUILDING.txt.gz
<ogra_> the apt.conf manpage only seems to have options to suppress trigger execution
<TJ-> ogra_: I may be mis-remembering but from a looong way back I seem to recall seeing/using OrderList::Score::Immediate
<ogra_> TJ-, hmm, i'll try
<cjwatson> ogra_: as far as I know, it doesn't
<ogra_> weird, so that would be a packaging bug in the raspi2 package ?
<cjwatson> that would be my first guess
<ogra_> hmm and the kernel team is traveling :(
<cjwatson> deferring triggers isn't really a thing
<cjwatson> err
<ogra_> enforcing :)
<cjwatson> I mean, enforcing immediate execution of triggers isn't really a thing
<cjwatson> OrderList::Score::Immediate is a bit different really
<ogra_> yeah, thats how i read the manpage
<Laney> doko: Do you have an idea on how we can get past https://sourceware.org/bugzilla/show_bug.cgi?id=19188 ?
<ubottu> sourceware.org bug 19188 in ld "[2.26 Regression] binutils assertion fail ../../bfd/elfnn-aarch64.c:4631" [Normal,Assigned]
<Laney> it's breaking webkit2gtk/arm64 which is going to be the last thing holding up a big-ish migration soon
<seb128> hum
<seb128> gdb doesn't work on xenial for me :-/
<seb128> (gdb) bt
<seb128> Python Exception <class 'SystemError'> <built-in function isinstance> returned a result with an error set:
<seb128> those python errors is everything it returns
<sarnold> seb128: maybe disable autoloading python? https://sourceware.org/gdb/onlinedocs/gdb/Python-Auto_002dloading.html#Python-Auto_002dloading
<seb128> sarnold, thanks
<seb128> Laney, you could have updated python-pgmagick to 0.5.12 that patch is basically all there is in the new version ;-) (I pinged slangasek about that yesterday)
<seb128> sarnold, that works ;-)
<sarnold> yay :)
 * Laney shrugs
<Laney> why didn't you upload it?
<seb128> Laney, because slangasek said it was on his list
<Laney> didn't see a bug
<seb128> he was the one who uploaded the version that failed to build
<seb128> yeah, I should probably have opened one
<seb128> sorry about that :-)
<seb128> I though he would handle it yesterday
<doko> Laney, sorry, not yet. gold fails too. for unity it only showed up build the test cases, so I proposed to disable these.
<doko> Laney, this is https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1511542
<ubottu> Launchpad bug 1511542 in unity (Ubuntu) " [2.26 Regression] binutils assertion fail ../../bfd/elfnn-aarch64.c:4631" [High,In progress]
<seb128> doko, hey, gdb giving the python errors I just copied, is that known? what component should that be reported against?
<Laney> doko: :(
<doko> seb128, do you have a test case, or is this just loading the pretty printer?
<seb128> doko, I just do "gdb something" and "run" and ctrl-C and bt
<seb128> or attach to an existing process
<stgraber> cyphermox: hey, who's in charge of network-manager these days? we've got a very serious regression affecting wily and xenial
<stgraber> slangasek, cyphermox: bug 1512749
<ubottu> bug 1512749 in network-manager (Ubuntu Xenial) "lxcbr0 dissappears on Ubuntu 15.10" [Critical,Triaged] https://launchpad.net/bugs/1512749
<barry> Laney: matplotlib 1.5.0~rc2-1ubuntu3 \o/
<barry> Laney: i was just about to start looking at that one :)
<Laney> barry: hehe
<Laney> you should make more things depend on glib
<Laney> then you get people like me to care :P
<barry> Laney: :)
<barry> Laney: now i know how to trick you into fixing all the bugs
<sil2100> slangasek, doko, cyphermox, any-other-core-dev: could you release https://bugs.launchpad.net/ubuntu/+source/ledit/+bug/1512776 for me? Thanks!
<ubottu> Launchpad bug 1512776 in ledit (Ubuntu) "Release no-change rebuild for ocaml transition" [Undecided,In progress]
<yofel> pitti: fixes for some of the kubuntu autopackagetest failures uploaded, sorry that it took a while (some still need to be uploaded once I fixed our packageset..). Is there some way to list all kubuntu packages with test failures?
<pitti> yofel: I think the easiest thing to start from is http://autopkgtest.ubuntu.com/data/status/xenial/amd64/packages.json
<yofel> ah nice, that works
<yofel> thanks
<pitti> yofel: probably easiest with three lines of python -- iterate over status "fail" and "kde" in package, or so?
<pitti> I'm fairly sure one can do it with json_pp, but I never learned the magic of this; Laney knows this
<yofel> if the naming would be that easy I wouldn't have trouble :P
<yofel> but we have lists of all our maintained sources, so filtering that won't be hard
<Laney> pitti: yofel: The tool that I used was called 'jq'
<pitti> ah, or that
<yofel> thanks, I'll look at that
<pitti> not knowing that i'd just do something like "for p in json.load(f.read()): if p['package'] ...
<cyphermox> sil2100: looking
<cyphermox> sil2100: done.
<bdmurray> tumbleweed: did you say you had updated distro-info-data?
<sil2100> cyphermox: thanks!
<sil2100> doko: https://bugs.launchpad.net/ubuntu/+source/unity-api/+bug/1512784 - MIR request pretty please
<ubottu> Launchpad bug 1512784 in unity-api (Ubuntu) "[MIR] unity-api" [Undecided,New]
 * ogra_ wonders whats up with the arm builders ... 
<cjwatson> ogra_: ?
<ogra_> cjwatson, well, they seem busy https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/ (i had them starting immediately all day during test builds)
<cjwatson> ogra_: they have about a ten-minute queue at the moment due mostly to a batch of KDE uploads, but nothing serious
<cjwatson> ogra_: see https://launchpad.net/builders/
<ogra_> ah, k
<ogra_> well, i'll wait
<cjwatson> arm64 will take longer, but that's normal
<cjwatson> I think the 28 minutes on your page is a misestimate
<ogra_> yeah, for test builds i dont care for arm64 ... i should have excluded it from ARCHES=
<bdmurray> tumbleweed: I ask as I don't seem them in the unapproved SRU queues
<stgraber> cyphermox: did you see my question above?
<cyphermox> I had not
<cyphermox> so, the short answer is "nobody really".
<cyphermox> NM shouldn't touch the interfaces it doesn't manage, especially not bridges, at all, so something clearly got broken
<stgraber> I just uploaded a very very ugly workaround to xenial now, if that does the trick, we'll have to SRU this very quickly to wily too until NM gets fixed
<cyphermox> ok
<cyphermox> which package?
<stgraber> lxc
<stgraber> cyphermox: http://paste.ubuntu.com/13092923/
<cyphermox> oh yuck
<stgraber> yeah
<stgraber> as I said, very very ugly workaround, does the trick though
<stgraber> the alternative was a "sleep 5" but well, that'd just be racy :)
<cyphermox> yeah
<cyphermox> so, I think we're running into more of the veth vs. straight ethernet device issue
<stgraber> and nmcli doesn't seem to have a "wait until we reach some kind of final state"
<stgraber> cyphermox: nah, it's a bridge here and NM does try to do stuff with the bridge backend code
<stgraber> cyphermox: run: ip link add dev test type bridge && ip link set dev test up && ip addr add 1.2.3.4/24 dev test && sleep 2 && ifconfig test && ip link delete test
<stgraber> cyphermox: you'll get an interface without an IP
<stgraber> Nov  3 12:13:17 castiana NetworkManager[21958]: <info>  (test): new Bridge device (carrier: OFF, driver: 'bridge', ifindex: 94)
<stgraber> so NM does detect it as a bridge and then still does stuff to it...
<stgraber> it doesn't seem to start DHCP on it though, but it still does flush any pre-existing config from it
<seb128> cyphermox, you are not maintainin n-m anymore? do you still plan to do the point release updates?
<cyphermox> I do what I can given available time; but these days there's a lot of things going in front of NM in the todo queue.
<seb128> k, just wondering if we should do updates like we handle GNOME ones
<bdmurray> tumbleweed: Ah, I see its in -proposed for everything except wily.
<Laney> presumably because we have it in there as Xenial X, so might as well wait for the real release date before SRUing again
<bdmurray> Laney: got it thanks
<cyphermox> seb128: by all means, feel free to do the updates for NM, but some may be quite involved :/
<seb128> cyphermox, right...
<mterry> pitti, hi!  I'm looking at the strip-nondeterminism MIR.  Looks fine, but I had a question about if enabling this means we'll fail a build if the tool has a problem or if it continues the build in that case (there are several bugs in Debian about strip-nondeterminism having problems on weird files)
<pitti> mterry: haven't checked for sure, but I'd expect it to FTBFS if dh_strip_nondeterminism fails
<pitti> mterry: but Debian has run it in production for some time, so I figure the worst bugs have been shaken out already
<pitti> mterry: and as I said on the bug, if this causes extra FTBFS the foundations team will certainly deal with this
<pitti> (in the worst case by disabling it for that package or in general)
<mterry> pitti, OK.  Well that's a decision for integration into debhelper anyway.  Not a reason to block the MIR.  This package itself is maintainable
<mterry> pitti, cool, thanks!
<pitti> mterry: right; once approved, I'll revert the delta of dropping the dep from debhelper
<tumbleweed> bdmurray: oh, yes, I forgot to verify them
<mterry> bdmurray, the foundations team is looking after strip-nondeterminism in main, FYI
<bdmurray> tumbleweed: I've verified Trusty and Vivid.
<tumbleweed> bdmurray: thanks
<cyphermox> stgraber: what about this? http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e29ab54335c6a5ef1ce6bac525f1f18a8e81b96e
<stgraber> cyphermox: the reproducer in that commit is identical to what we're doing, so that's probably right
<mterry> bdmurray, and unity-api is being looked after by unity-ui-team in main, FYI!
<decci> I am trying to build .DEB package
<decci> I ran dh_make -f ../.tar.gz , then  debian/rules clean, build and binary. It went good and built .DEB package
<decci> Now when I again re-run the debian/rules binary it threw error override_dh_auto_install
<decci> Error code 2
<decci> Any idea how to  fix this
<ricotz> decci, you should use "debuild" or "dpkg-buildpackage" to build a source package
<decci> ricotz: Do you mean use it instead of debian/rules build
<mterry> jdstrand, and alabaster in main is also looked after by foundations team, fyi!
<decci> ricotz: So whats the correct way of building .DEB
 * mterry is clearing out MIRs  :)
<decci> ricotz: All I follow: 1. dh_make 2. debian/rule clean 3. debian/rules build 4. debian/rules binary
<decci> ricotz: Where do I need to run debuild?
<decci> ricotz: I mean after which step
<ricotz> decci, you downloaded a source package, e.g. having a *.dsc file lying around?
<ricotz> do "dpkg-source -x *.dsc", go into the src folder and run "dpkg-buildpackage" or "debuild"
<decci> ricotz: I have source code, when I run dh_make it creates debian folder where rules, preinst and postinst gets created and .dsc gets created at ../
<ricotz> so you want to create a debian package from some tarball without any existing packaging information?
<decci> ricotz: This is a source code internal to company..pre-compiled and linked already
<decci> ricotz: All I am trying to do is build it to .deb
<decci> ricotz: yes
<ricotz> decci, you might want to use "checkinstall" then
<decci> ricotz: checkinstall doesnt handle rules, preinst and postinst
<decci> ricotz: I dont see any option for rules specification
<ricotz> you don't have any packaging information in the first place
<decci> ricotz: I have rules, postinst and preinst, control files in place
<ricotz> so simply use the tarball and build it and checkinstall creates a deb
<ricotz> ok, because you ran dh_make
<decci> ricotz: All I want to build .DEB package using these rules, preinst and postint
<ricotz> then debuild from within the root srcdir should work
<decci> ricotz: dh_make gives me debian folder with rules, post and preinst file created to add the rules
<ricotz> search for debian packaging details to make further adjustments if needed
<decci> ricotz: I can try debuild , so do I need to run under my source
<decci> ricotz: which has Makefile, configure.ac
<decci> ricotz: CMakeCache.txt
<decci> ricotz: What could be reason of override_dh_auto_install Error: code 2
<ricotz> debuild looks for the debian folder and its content
<ricotz> sound like an error in your changes to rules
<ricotz> better paste a more detailed error output (via pastebin), so someone can look at it
<ricotz> I need to go
<decci> ricotz: dpkg-source: error: unwanted binary file: debian/CMakeFiles
<decci> ricotz: dpkg-source: error: detected 4 unwanted binary files (add them in debian/source/include-binaries to allow their inclusion).
<mterry> bdmurray, and foundations for python-hypothesis too!
<bdmurray> mterry: got it, thanks
<decci> dpkg-buildpackage: error: dpkg-source -b dcde_source gave error exit status 29
<mterry> bdmurray, (is this the easiest way to update the list? -- I'm fine with it, just curious if these pings get annoying)
<bdmurray> mterry: the list of teams I'm already aware of can be found here - http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/package-subscribers#L107
<bdmurray> mterry: If the team isn't in that list then being notified would be useful
<mterry> bdmurray, ahh...  so if a team subscribes to a bug, you assume they are looking after it as long as they are in this list.  It's not a granular team->package thing
<bdmurray> mterry: right, we look at the packages to which those teams are subscribed
<mterry> bdmurray, cool OK, then I can drop a lot of pings  :)
<bdmurray> mterry: indeed!
<cyphermox> stgraber: looks like it's good; I'll upload to xenial now and then we can look at the SRU for this. Can you update the bug to add the template?
<stgraber> cyphermox: sure, I'll add a testcase once we have it in xenial and working
<stgraber> cyphermox: I was going to SRU the ugly lxc workaround but if we can get network-manager fixed itself, even better
<chiluk> slangasek: I know you are busy, but can I get an upload for nfs-utils done for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1509120  I have a feeling it will look familiar to you.
<ubottu> Launchpad bug 1509120 in nfs-utils (Ubuntu) "Process accounting deadlock with idmapd callout when writing to NFSv4 mount" [Medium,In progress]
<slangasek> chiluk: oh hah, is that really just a keyutils upcall bug?
<cyphermox> stgraber: yeah, feel free to not SRU your ugly lxc fix now if this NM update works :)
<stgraber> cyphermox: already reverted it in xenial, it's clearly not something I wanted to have to keep around :)
<cyphermox> ack.
<chiluk> slangasek: yes it is.
<slangasek> chiluk: I notice the rationale for adding the dependency in vivid+ was that this is required for systemd compatibility, because in the systemd case everything assumes we only use /usr/sbin/nfsidmap as an upcall *instead* of running idmapd (/etc/request-key.d/id_resolver.conf).  So this certainly seems to be a workaround rather than a proper fix
<slangasek> do I have that right?
<chiluk> slangasek: it's not a workaround when communicating with old nfsv4 servers that don't support sec=sys, and thus aren't using idmapd.
<slangasek> hmm
<chiluk> afaik.. but I wouldn't consider myself an nfs expert by any stretch of the imagination
<slangasek> should anyone? ;)
<chiluk> we were only able to rerpoduce the hang by using an ancient 2.6.32 centos machine
<chiluk> precisely because sec=sys isn't supported by such an ancient kernel.
<slangasek> do you know what the RPC is that triggers this path, vs. working via idmapd?
<chiluk> I don't.
<slangasek> ok
<chiluk> I could tcpdump it real quick if you'd like.
<chiluk> slangasek: ^^
<slangasek> chiluk: hit me
<chiluk> don't tempt me...
<slangasek> chiluk: has this been reproduced cross-architecture?
<slangasek> chiluk: because my next question is, is it reproducible with the 14.04.0 kernel or only with hwe-v?
<chiluk> yeah ppc is hitting it although I don't have a trustable backtrace yet from them, and I'm seeing it on x86_64
<chiluk> oh no, I'm using 3.13.
<slangasek> ok
<chiluk> do you still want that tcpdump?  I just realized that the machine will become unusable once I instantiate the crash.. so we'll see what kind of messages actually can get logged.
<chiluk> nm I can capture from the server.
<slangasek> chiluk: I think I'm happy without the tcpdump
<chiluk> slangasek, yeah .. I was a bit curious myself about the rejected rpc call.
<Unit193> FWIW, Debian 786690 still affects wily.
<ubottu> Debian bug 786690 in pbuilder "pdebuild fails to builds package with dpkg-dev 1.18.0 (dpkg-buildpackage -S failing with missing build-deps)" [Important,Fixed] http://bugs.debian.org/786690
<xnox> i'm blinking over "1TB PCIe Solid State Drive" whilst starring at XPS 15 (9550).
<sarnold> ooo
<sarnold> chrisccoulson: ^^^
<xnox> the new XPS 15, however so far it's with windows only, and i don't see a developer edition with ubuntu yet.
<xnox> http://www.dell.com/uk/p/xps-15-9550-laptop/pd
<xnox> superm1: is XPS 15 (9550) pre-orderable as a developer edition? i shall give them a call tomorrow.
<sil2100> doko: so, to continue on the ocaml transition I need multiple arm64 binaries built from the dependency level 3 uploads I made, meaning I'm currently stalled on that
<sil2100> But tomorrow at least some of them should be available, so I can continue from there then
<superm1> xnox: not currently. It's a work in progress still.
<superm1> danjared: will know current status better than I
<cjwatson> sil2100: yeah, for that number it's sensible just to wait - at least the ocaml stack isn't too deep
<cjwatson> the queue's "only" an hour long at the moment
<danjared> what'd I do?
<danjared> xnox: no, no current plans for an Ubuntu version of the XPS 15. there are plans for the Precision Mobile 5510
#ubuntu-devel 2015-11-04
<doko> pitti, barry, infinity: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python3
<barry> pitti: LP: #1440388
<ubottu> Launchpad bug 1440388 in ubuntu-system-service (Ubuntu) "please port ubuntu-system-service to Python3" [Undecided,Fix committed] https://launchpad.net/bugs/1440388
<lfaraone> stgraber: re LP #1501588 , I've heard similar reports from people in our Ubuntu deployment (and experiencing the problem myself); is downgrading wily to 2.1 (vivid's version) an acceptable fix, or would it be better to find the problematic patch and revert it?
<ubottu> Launchpad bug 1501588 in wpa (Ubuntu) "Wily's wpasupplicant frequently fails on WPA enterprise networks" [Critical,Confirmed] https://launchpad.net/bugs/1501588
<stgraber> lfaraone: well, so in my case the downgrade doesn't actually solve it
<stgraber> lfaraone: one thing I've noticed here and it may well be the source of the problem is that NM is misbehaving wrt IPv6 MTU. It's occasionally getting a frame without a MTU and so interprets it as MTU=0, it then attempts to set the interface MTU to 0, fails and falls back to the minimal MTU of 1280
<stgraber> lfaraone: so from that point on, my network interface has a wrong MTU (1280 instead of 1500) which prevents wpa_supplicant from setting up an EAP session and leads to the error I've reported
<stgraber> lfaraone: I only came up with that theory a couple of hours ago when noticing the wrong MTU and a lot of MTU related messages from NM in /var/log/syslog
<stgraber> and that'd explain why downgrading the kernel, firmware and wpa_supplicant didn't do the trick here, it looks like, at least for me, the main issue is NM
<lfaraone> I have yet to try to downgrade. I'll play with it later.
<lfaraone> except now I can't repro :(
<Mirv> Laney: any chance for the devel-permissions Qt thread answering?
<Laney> I pinged the others yesterday
<cjwatson> snakefruit (various archive cron jobs, http://people.canonical.com/~ubuntu-archive/, etc.) going down soon for a RAM upgrade
<cjwatson> snakefruit back
<ogra_> cjwatson, if you are interested .... my kernel package install prob from yesterday is caused by:
<ogra_> + rm -r var/lib/dpkg var/log/apt
<ogra_> + rm usr/bin/dpkg-query usr/bin/dpkg-split usr/bin/dpkg-divert usr/bin/dpkg-trigger usr/bin/dpkg-statoverride usr/bin/dpkg-maintscript-helper
<ogra_> (i use the rootfs chroot after tarball creation, snappy removes dpkg ...)
<ogra_> (or parts of it)
<antgel> Hi all, I was referred here from #u. I'm trying to run nm-tool (or nmcli) from a user's crontab. It works from the shell, but from cron, it fails with Could not initialize NMClient /org/freedesktop/NetworkManager: Rejected send message, 3 matched rules; type="method_call", sender=":1.613" (uid=1000 pid=7278 comm="nm-tool ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination="org.freedesktop.Ne
<mgedmin> because cron has a separate environment and doesn't see your DBUS_SESSION_BUS_ADDRESS
<antgel> mgedmin: Any pointers to where I can configure this? It seems bizarre as default, but I don't mind tweaking the config. I'll google the variable you mention in any case
<antgel> mgedmin: Okay, I added something to pull that envvar in, and I can see it in cron via echo $DBUS_SESSION_BUS_ADDRESS. But the call still fails, in the same way. Any clues?
<mvo_> cyphermox: looks like fwupdate-signed is in dependency wait since a couple of hours. do you know what is going on?
<cyphermox> probably waiting for fwupdate itself, lemme look
<cyphermox> oh, crap, missing a character.
<cyphermox> mvo_:  yeah it's broken because yeah.
<mvo_> cyphermox: thanks for checking
<cyphermox> mvo_: it will be fixed shortly.
<mvo_> ta
<dholbach> chrisccoulson, tyhicks, smoser: do you know who's running the libv8/node.js session in the core track in a few?
<dholbach> is it doko?
<smoser> doko i assumed
<dholbach> hum, he's not online
<chrisccoulson> I saw doko at breakfast about 20 minutes ago
<hallyn> hi - can a no-build rebuild (of vm-builder) be done in wily without the need for an SRU?  This would be to enable the build for power8.  (bug 1510720)
<ubottu> bug 1510720 in vm-builder (Ubuntu) "vm-builder doesn't support ppc64el" [Medium,Fix released] https://launchpad.net/bugs/1510720
<infinity> dholbach: There's a nodejs session?  Who registered it? :P
<dholbach> infinity, http://summit.ubuntu.com/uos-1511/meeting/22590/nodejs-and-libv8-for-1604/
<caribou> cyphermox: https://bugs.launchpad.net/ubuntu/trusty/+source/haproxy/+bug/1481737
<ubottu> Launchpad bug 1481737 in haproxy (Ubuntu Trusty) "HAProxy init script does not work correctly with nbproc configuration option" [Medium,In progress]
<cyphermox> barry: caribou: pitti: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1513110
<cyphermox> unity, for lack of a better idea where this would need to be reported :/
<ubottu> Launchpad bug 1513110 in unity (Ubuntu) "global menus are broken and cannot be clicked" [Undecided,New]
<cyphermox> barry: also; https://bugs.launchpad.net/ubuntu/+source/bamf/+bug/1513113
<ubottu> Launchpad bug 1513113 in bamf (Ubuntu) "name to icon matching for Terminal broken in xenial" [Undecided,New]
<Trevinho> cyphermox: that's a byobu bug
<kirkland> Trevinho: I'm happy to fix that in byobu, but I need a real fix in bamf or whatever
<barry> cyphermox: LP: #1512498
<ubottu> Launchpad bug 1512498 in gnome-terminal (Ubuntu) "gnome-terminal thinks it's Byobu Terminal" [High,Confirmed] https://launchpad.net/bugs/1512498
<cyphermox> Trevinho: is it?
<kirkland> Trevinho: in vivid, unity/bamf/whatever stopped showing the byobu icon entirely
<cyphermox> seems very wrong if some random app can break the matching for another
<barry> kirkland, Trevinho: you might want to dupe one of those two bugs to the other
<Trevinho> kirkland: yeah, I need to add some support to desktop API to change that, but... It's something that's going to work only with gnome-terminal probably
<kirkland> Trevinho: cyphermox: instead showing the gnome-terminal one
<kirkland> cyphermox: I agree with that -- that could be a security problem, honestly
<Trevinho> kirkland: in a meeting, we can discuss later
<cyphermox> kirkland: stretching "security" a bit, but hey ;)
<kirkland> cyphermox: imagine a PPA or random package in the archive that ships an icon.png which is a goatse type image, but replaces firefox/chrome's icon
<cyphermox> heh
<kirkland> Trevinho: so I'm happy to revert the byobu change (which I agree is wrong) as soon as the other one gets fixed;  I've left it there to call attention to the problem, which hasn't received much attention thus far :-)
<Trevinho> Well good way to get attention :)
<cyphermox> kirkland: Trevinho: you guys will dedupe the two bugs?
<kirkland> Trevinho: ;-)
<jgdx> larsu, hey, when Albert approves [1], will you be landing it too? [1] https://code.launchpad.net/~larsu/gsettings-qt/lp1503693/+merge/276190
<larsu> jgdx: I won't, but I'll make sure somebody will ;)
<jgdx> larsu, thanks :)
<barry> Trevinho: have you seen LP: #1513110 ?  That's a nasty one we're all seeing here at the sprint
<ubottu> Launchpad bug 1513110 in unity (Ubuntu) "global menus are broken and cannot be clicked" [High,Confirmed] https://launchpad.net/bugs/1513110
<infinity> Trevinho: Nasty and entertaining!
<infinity> Trevinho: Not only are the menus busted, but it exposes another shrinking window sizing bug. :P
<cyphermox> it's a fun way to resize terminals though, maybe it should be a feature
<Trevinho> infinity: don't blame me... :P It's kirkland that used the hard hand ;-)
<infinity> Trevinho: Hrm?  Are we talking about different bugs here?
<hallyn> arges: can a no-build rebuild of vm-builder in wily be done without an SRU?
 * larsu is not seeing that
<bdmurray> chrisccoulson: Could you add a comment to bug 1512099?
<larsu> this is stock xenial?
<ubottu> bug 1512099 in firefox (Ubuntu Wily) "Don't report plugin-container crashes with Apport" [Undecided,Triaged] https://launchpad.net/bugs/1512099
<kirkland> Trevinho: I don't think I've broken window sizing
<Trevinho> infinity: ohhhh. sorry, I'm in on hangoout so so I ddid't read that properly
<Trevinho> kirkland: no you didn't, sorry I misunderstood
<infinity> kirkland: WAY TO GO DUSTIN.
<infinity> kirkland: YOU BREAK EVERYTHING.
<kirkland> muuuhahahahaha
<cyphermox> hey, I no longer have indicators :)
<infinity> \o/
<infinity> cyphermox: I blame kirkland.
<pitti> hallyn: so just running https://github.com/hallyn/lxcfs/commits/testing should suffice, I don't need a newer cgmanager to go along with this? (on xenial)
<cyphermox> I'm waiting for the "self-destruct sequence initiated" message.
<chiluk> slangasek: no rush.  SRU template fixed.  Not sure how I missed the testcase earlier.  bug 1509120
<ubottu> bug 1509120 in nfs-utils (Ubuntu) "Process accounting deadlock with idmapd callout when writing to NFSv4 mount" [Medium,In progress] https://launchpad.net/bugs/1509120
<hallyn> pitti: correct, it simply doesn't use cgmanager
<mterry> barry, is the python3 session in 5 min?
<barry> mterry: yes
<arges> hallyn: i'm not entirely sure
<hallyn> stgraber: ^ do you know?  vm-builder is arch:all, not built for power8;  someone wants it in wily for power8.  Can we do a no-build rebuild without going through sru, and would that enable it for power8 in wily?
<xnox> hallyn: no, as it will not publish as far as i can know.
<xnox> hallyn: sru should be (a) quick and (b) fast to do / validate.
<hallyn> xnox: and sru would then enable it for power8?
<xnox> hallyn: that is that needs to be tested.
<hallyn> xnox: ok, thanks :)
<hallyn> let's try
<hallyn> cjwatson: is there a flag that cna be set in the back end to make vm-builder in wily be enabled for power8?
 * hallyn holds his finger over the dput button, under the assumption answer will be no
<cjwatson> hallyn: sorry, no context, in what way is it disabled?
<hallyn> it simply doesn't seem to be available for power8 in wily.
<cjwatson> hallyn: an arch: all binary exists for all architectures, that's the point
<hallyn> right, but power8 didn't exist last time vmbuilder was uploaded
<hallyn> should that have become available anyway automatically?
<cjwatson> hallyn: power8 is not a different architecture
<cjwatson> hallyn: it was just a change in default toolchain for ppc64el/xenial
<hallyn> cjwatson: bug 1510720 is the original reporter
<ubottu> bug 1510720 in vm-builder (Ubuntu) "vm-builder doesn't support ppc64el" [Medium,Fix released] https://launchpad.net/bugs/1510720
<cjwatson> hallyn: none of this is making any sense
<cjwatson> hallyn: this isn't some magical archive thing, afaics the reporter is complaining that the *code* doesn't support ppc64el?
<cjwatson> hallyn: why does it need to be architecture: any?
<mvo_> cyphermox: yay, fwupdate-signed is now pending publication
<hallyn> cjwatson: it doesn't
<hallyn> disregard comment where i said that
<cjwatson> hallyn: so I have no idea why you need to rebuild, or what a no-change rebuild would achieve
<cjwatson> hallyn: https://launchpad.net/ubuntu/wily/ppc64el/python-vm-builder shows that it's there
<hallyn> cjwatson: actually, i'm seeing it now on a power8 anyway.  wtf
<hallyn> cjwatson: i thought a rebuild would magically fill in some db field saying "this exists for that platform"
<hallyn> i was wrong
<hallyn> cjwatson: sorry for the noise, thanks
<cjwatson> hallyn: I think this must be talking about all the architecture conditionals in vm-builder, not about archive-level stuff
<cjwatson> e.g. ./VMBuilder/plugins/ubuntu/maverick.py which seems to be the current list of valid flavours by inheritance
<hallyn> cjwatson: i had wondered that at first, maybe it is that after all.
 * hallyn wishes h'ed yanked it from the archive before 14.04
<sarnold> when in doubt, ask reporter for a copy-paste of error messages :)
<hallyn> sarnold: well i just tol dhim it is there, if he meant the other thing he'll shout i'm sure
<hallyn> thanks again
<sarnold> :)
<cyphermox> mvo_: yep
<seb128> doko, I think your babeltrace delta can be dropped and the package can be synced from Debian, you might want to have a look to that
<seb128> doko, you can probably sync openexr as well
<dkessel> mterry: looks like you had one or too looks into duplicity's codebase - i am confused what the upstream VCS for it is... is it hosted on launchpad bzr?
<mterry> dkessel, yes
<dkessel> mterry: oh, you even worked on a python3 port. i wondered about that while reading the the session notes from today.
<mterry> dkessel, yeah, I've been slowly working on python3 pieces that need to get it ready
<mterry> dkessel, next piece I was doing was strings/bytes
<mterry> dkessel, but I never finished it
<mterry> dkessel, and don't have time this cycle likely
<mterry> dkessel, but would gladly help someone else!  :)
<dkessel> mterry: well it would be great not to have duplicity require a download of python2 with all that stuff, right? :)
<dkessel> are the dependencies all there on python3?
<mterry> dkessel, for the core, I believe so.  For all the backed plugins, I'm less sure
<mterry> But it would be nice to avoid the download.  Especially since *eventually* we'll need to port to py3 anyway
<dkessel> is your port a pure manual port? or did you run 2to3 initially?
<hjd> Could someone please trigger a rebuild of node-iconv and node-nan on Xenial? They might work a bit better now that node-gyp should be installable again :)
<doko> seb128, done
<seb128> doko, thanks
<seb128> doko, I didn't follow the replies, but is there any workaround we could try for the binutils aarch64 issue that is blocking webkit? that's basically holding the cheese/evolution-data-server/poppler/libgtop/gnome-desktop transitions in xeny-proposed
<mvo_> cyphermox: hm, fwudate-signed is still not published, should I ask someone in #ubuntu-relase to binary-NEW it?
<mdeslaur> pitti: how can I retrigger the autopkgtest for libapache2-mod-perl2? It should be fixed by my libbsd-resource-perl upload yesterday
<mdeslaur> which will unblock apache2, which will unblock php5, and will make me TIL on half the archive
<doko> seb128, no, I'm on it. no work around yet
<seb128> doko, ok, thanks
<seb128> mdeslaur, https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests
<mdeslaur> hrm, guess I can't put off installing the vpn any longer... :P
<mdeslaur> seb128: thanks
<seb128> mdeslaur, yw
<doko> seb128, would you like to look at https://launchpad.net/ubuntu/+source/openexr/2.2.0-7/+build/8264422 ?
<cjwatson> hjd: done
<tkamppeter> slangasek, hi
<hjd> cjwatson: ty :)  They still failed though, but looks like the initial problem is gone
<mterry> doko, looks like you subscribed foundations team to fonts-font-awesome, but not modernizr
<slangasek> tkamppeter: hullo
<pitti> mdeslaur: you can't right now (needs ubuntu_archive@snakefruit), I've done it
<pitti> mdeslaur: thanks for fixing!
<mdeslaur> pitti: thanks!
<doko> mterry, ugh, I thought I did ... now done
<mterry> doko, perfect thanks  :)
<sil2100> mterry: hey! So are those recommendations you made on the unity-api MIR bug required for changing the component to main?
<sil2100> Or is it fine enough as is?
<sarnold> Do we have plans on supporting ZFS in trusty's HWEs? This deserves a look, perhaps for an SRU https://bugs.launchpad.net/trusty-backports/+bug/1454740
<ubottu> Launchpad bug 1454740 in utopic-backports "Please backport libguestfs 1:1.28.6-1ubuntu1 (universe) from vivid" [Undecided,New]
<machinaut> How do I send a patch for a package like `tzdata`?
<infinity> https://mm.icann.org/mailman/listinfo/tz
<machinaut> infinity:
<machinaut> It's already in their package, and in the wily version of tzdata, but not the precise (12.04) version of tzdata.
<infinity> machinaut: precise has the same version as wily.
<infinity> (base)adconrad@nosferatu:~$ rmadison -a source tzdata | egrep 'precise|wily'
<infinity>  tzdata | 2012b-1              | precise          | source
<infinity>  tzdata | 2015g-0ubuntu0.12.04 | precise-security | source
<infinity>  tzdata | 2015g-0ubuntu0.12.04 | precise-updates  | source
<infinity>  tzdata | 2015g-1              | wily             | source
<machinaut> On my wily machine tzdata is version "2015g-1" and on precise its "2015g-0ubuntu0.12.04".  What's missing is a leap-seconds file.
<infinity> machinaut: Oh. Yes, I didn't backport that change intentionally.
<machinaut> Crap.  Exactly that backport was what I was looking for.  Whats the reason?
<infinity> I don't backport packaging changes, only zone info changes.
<infinity> If you file a bug justifying why you want/need the leap second file (running an ntp server and want to point at it?), I can perhaps SRU just for that.
<machinaut> Is there any way to get leap-seconds otherwise on a precise system?
<infinity> The canonical URL for it is... Hold on.
<infinity> https://www.ietf.org/timezones/data/leap-seconds.list
<machinaut> I was looking for a operating-system provided method (cant hit the web for other reasons).  I think I might just parse it out of the 'right/UTC' zoneinfo then.
<machinaut> infinity: will precise continue to get leap-second updates to its 'right/' timezone infos?
<infinity> machinaut: Yeah.
<infinity> machinaut: I can ship the leap second file too in a future update, just file a bug with a justification and I'll make it happen on the next upstream bump.
<machinaut> Roger, wilco, thanks!
<dobey> the problem with watching the uos sessions after the fact, is that you can't just go round pinging the people while you're listening to it
<cyphermox> kirkland: Trevinho: barry: I think we want to revert that revert: https://git.gnome.org/browse/gnome-terminal/commit/?id=b735feff4ca0a88b389a89d151bb075bf39e32f8
<Trevinho> cyphermox: yeah that would be the easiest fix..
<Trevinho> cyphermox: however, being a gnome-terminal-server just a single instance, is this working for all the created  windows?
<cyphermox> Trevinho: I don't know, I haven't tried
<Trevinho> i.e. if you've a gnome-terminal and a byobu instance open, will this cause any issue?
<Trevinho> ok
<Trevinho> but being on terminal-app... Maybe...
<Trevinho> it seems reasonable, though
<Laney> You can see from the referenced bug that both desrt and larsu have worked on this issue
<Laney> I think you should talk to them and work it through upstream
 * Laney isn't really here though - bye :)
<Trevinho> Laney spotted!
#ubuntu-devel 2015-11-05
<syntroPi> im trying to compile (any maybe package someday) a software which i guess was written on arch. it comes with a cmake script looking for "gstreamermm-1.0" but ubuntu only has "libgstreamer-1.0-dev" which it doesnt see. Any ideas how to get cmake use that?
<Unit193> LocutusOfBorg1: I see you're upstream on pbuilder (thanks!) and are trying to merge it into Xenial.  Are you aware it doesn't work in wily without a slight modification to fix Debian 786690?
<ubottu> Debian bug 786690 in pbuilder "pdebuild fails to builds package with dpkg-dev 1.18.0 (dpkg-buildpackage -S failing with missing build-deps)" [Important,Fixed] http://bugs.debian.org/786690
<mgedmin> ohi
<mgedmin> 'pull-lp-source -d python3-defaults xenial' reliably fails for me with a socket.error (connection reset by peer)
<mgedmin> after successfully downloading both the .dsc and the .tar.gz
<Mirv> a core-dev would be needed for running https://ci-train.ubuntu.com/job/ubuntu-landing-026-2-publish/build , solely because there's a change in apparmor-easyprof-ubunt by jdstrand (https://ci-train.ubuntu.com/job/ubuntu-landing-026-1-build/129/artifact/apparmor-easyprof-ubuntu_packaging_changes.diff) other packages are universe packages.
<Mirv> it's going to the overlay PPA
<tsdgeos> xnox: do you have a link for those patches you speak of that remove gtk2 dependency on Qt5?
<LocutusOfBorg1> Unit193, well, I didn't try wily, but I'm trying to fix xenial
<__marco> Good morning. How can I find more informations about trusty-changes ml?
<__marco> For example, what are -proposed, -updates and -security changes?
<__marco> I see that python-tz 2012c-1ubuntu0.1 is -proposed (Accepted) and presents in the trusty-updates
<__marco> while qemu 2.0.0+dfsg-2ubuntu1.20 is also -proposed and Accepted but not in the repositories
<cjwatson> most uploads go to -proposed first and are then copied elsewhere after QA
<xnox> tsdgeos: yes, i got an email about it.
<xnox> tsdgeos: https://codereview.qt-project.org/#/c/139867/
<tsdgeos> i see
<tsdgeos> tx
<xnox> tsdgeos: np
<brendand> i just upgraded a raspberry pi 2 running trusty to xenial and fontconfig won't install (which seems to be stopping upstart from installing fully, as i am missing some of the binaries it provides)
<brendand> particularly i no longer have any reboot/shutdown command
<decci> Hello
<decci> I am trying to build .DEB package
<decci> I am able to create .DEB package but while I try to install it it puts everything under /tmp folder
<decci> and not under specific /etc, /usr or /opt
<decci> How to troubleshoot it
<decci> My buildroot says debian/csde/tmp/DEBIAN/..
<decci> under rules file
<gQuigs> is this the right place to change ubuntu restricted extras and friends - https://code.launchpad.net/ubuntu/+source/ubuntu-restricted-extras  of is there  a seeds like equivalent for that too?
 * gQuigs realized that gstreamer0.1 can still be brought in by that package
<pitti> Good morning
<diwic> seb128, hi!
<seb128> diwic, hey
<diwic> seb128, hi, how are things? Are you still the one to talk to about unity-control-center?
<seb128> diwic, things are going well, thanks! hope it's the same for you :-)
<seb128> yes
<seb128> or at least I'm one of those looking after it
<diwic> seb128, so I wanted to fix up the subwoofer slider and just added a comment about the proposed fix in bug 1505705
<ubottu> bug 1505705 in unity-control-center (Ubuntu) "[sound] Subwoofer slider works in mysterious ways" [Undecided,New] https://launchpad.net/bugs/1505705
<diwic> seb128, I just feel that would be good to get your ack on how things should work before I go coding them
<diwic> seb128, so if you had some time to reply to that (not urgent) it would be great
<seb128> diwic, I see there are several comments forth and back upstream so I need to have a proper read, keeping that for later
<diwic> seb128, sure, np
<seb128> diwic, but if upstream agrees on a solution that's +1 from me as well
<diwic> seb128, well, I don't think hadess's suggestion is as good as the one I'm proposing
<seb128> diwic, I trust you on the topic and seems you got a +1 for the idea on the pulse list, so pre+1 from me, I'm still going to read that bug in details later and get back to you but you can probably start hacking on it
<diwic> seb128, ok, thanks!
<seb128> mdeslaur, hey
<mdeslaur> seb128: hey
<seb128> mdeslaur, bug #1513293 seems to be a regression in the recent unzip trusty security update, unsure how to flag those
<ubottu> bug 1513293 in unzip (Ubuntu) "unzip security update leads extracting errors" [High,New] https://launchpad.net/bugs/1513293
<mdeslaur> seb128: ok, thanks, I'll take a look
<seb128> mdeslaur, thanks
<seb128> mdeslaur, just for the record, is there an official way to flag those (out of IRC pings)? for next time...
<mdeslaur> seb128: not that I'm aware...you can just mention it in #ubuntu-hardened if you don't want to ping anyone specific
<seb128> k
<seb128> thanks
<kirkland> cyphermox: ooooh, you managed to identify the breakage?
<cyphermox> kirkland: to some degree.
<kirkland> cyphermox: have you verified reverting that fixes the problem?
<cyphermox> kirkland: sorry, no. I'm not spending extra time on the issue
<kirkland> cyphermox: okay, no worries, I'll captuer that URL in the bug in LP
<Laney> doko: any chance you can poke binutils upstream about the arm64 bug?
<cyphermox> ok. there may be side-effects we haven't anticipated to doing that revert, so I'll let the desktop team weight in
<Laney> it's annoying to have so much stuff blocked
<irctc747> Hi
<doko_> Laney, <doko> seb128, no, I'm on it. no work around yet
<Laney> doko_: not necessarily a workaround, but maybe you could poke upstream
<doko_> Laney, I'm on it, no worry
<pitti> mdeslaur: mind if I steal your rpcbind merge?
<pitti> mdeslaur: the next upload to Debian should make the package syncable; I'd like to double-check, test the socket activation, and sync
<mdeslaur> pitti: not at all, go ahead
<chiluk> mterry: are you around?
<mterry> chiluk, yup
<chiluk> mterry trusty debdiff uploaded https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871
<ubottu> Launchpad bug 1432871 in coreutils (Ubuntu Trusty) "`df` shows bind mounts instead of real mounts." [Low,In progress]
<mterry> chiluk, oh nice.  Might not get to it today, but will try tomorrow for sure
<chiluk> It was pretty much a pain in the ass to find/document provenance, but I think it resulted in a better patch
<chiluk> sure.
<chiluk> mterry I might get someone else to upload it then.
<mterry> heh k
<TJ-> anyone familiar with resolvconf, and how it /etc/resolvconf/update.d/ scripts swap the active nameserver? Looks like I've found a bug when multiple dnsmasq instances are in use which knocks out name resolution
<sarnold> TJ-: your description reminds me a little bit of a bug I filed https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1163147
<ubottu> Launchpad bug 1163147 in libvirt (Ubuntu) "Please run dnsmasq in such a way that it can also be used on the host â to look up the VMs' names" [Medium,Confirmed]
<sarnold> TJ-: jdthood was insanely helpful, but I had trouble articulating what exactly I wanted to achieve so it was hard for him to figure out what to do..
<TJ-> sarnold: I wish I had DNS to look at that!
<sarnold> TJ-: ohhhhhh man
<sarnold> TJ-: 91.189.89.224
<TJ-> BUT... I think my issue will be different. There's 3 'primary' dnsmasq instances usually: lxc, libvirt, and Network Manager - all OK
<sarnold> there's nothing there that is "run this to fix things", but he goes into great details about how the whole thing works
<TJ-> I've just configured the system-wide dnsmasq to ONLY do DHCP/BOOTP (no DNS) on a single interface
<TJ-> But... despite that, when I do "systemctl start dnsmasq" the resolvconf / nss-lookup.target are re-writing /run/resolvconf/resolv.conf to point to 127.0.0.1 ... which isn't listening of course! I've enabled shell 'set -x' debugging on the /etc/resolvconf/update.d/* scripts, which dumps to syslog, but cannot find out where this "127.0.0.1" is coming from.
<TJ-> That knocks out NMs "127.0.1.1"
<TJ-> the "127.0.0.1" is coming from "/run/resolvconf/interface/lo.dnsmasq" - I delete that file, but something recreates it!
<sarnold> pitti: ^^^ does any of this sound familiar?
<pitti> sarnold: I'm afraid not; I have a vague idea what resolvconf does, but lo.dnsmasq sounds just wrong
<sarnold> pitti: dang, thanks
<TJ-> this is the syslog/shell debug capture http://paste.ubuntu.com/13117195/
<TJ-> line 74-79 is the part that brings it in from lo.dnsmasq, but I've not been able to find out how that is getting recreated
<sarnold> TJ-: fatrace may help, it's sort of like a global strace for file opens...
<TJ-> Ha! "start_resolvconf()" in /etc/init.d/dnsmasq !
<TJ-> # If interface "lo" is explicitly disabled in /etc/default/dnsmasq
<TJ-> # Then dnsmasq won't be providing local DNS, so don't add it to
<TJ-> # the resolvconf server set.y
<TJ-> Grrr, "IGNORE_RESOLVCONF=yes" doesn't help
<TJ-> I wonder what this means "If interface "lo" is explicitly disabled in /etc/default/dnsmasq"
<TJ-> OK, got it :) /etc/default/dnsmasq requires "DNSMASQ_EXCEPT=lo"
<TJ-> Now to figure out why dnsmasq isn't replying to the BOOTP request :s
<TJ-> doh! port needs a VLAN tag!
<sarnold> sweet
#ubuntu-devel 2015-11-06
<psusi> wasn't there a tag to assign to bugs related to the dmraid -> mdadm transition for intel fakeraids?
<krypto> i have follwing cgroups defined in cgconfig.conf and cgrules.conf http://paste.ubuntu.com/13122187/ but i dont know how to tell libvirt use that instead of creating seperate "machine" group.Can some one please help me with this?
<krypto> in centos its in /etc/sysconfig/libvirt but not sure what to add in /etc/default/libvirt
<dholbach> good morning
<Odd_Bloke> cjwatson: The diff on https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1513754 are the changes we need to move more building on to Launchpad.
<ubottu> Launchpad bug 1513754 in livecd-rootfs (Ubuntu) "Move cloud image building further on to buildds" [Undecided,New]
<Odd_Bloke> infinity: wgrant: You may also be interested in ^.
<Mirv> dholbach: hey, if around could you do ./copy-package --from=~ci-train-ppa-service/ubuntu/landing-021 --from-suite=xenial --to=ubuntu --to-suite=xenial-proposed -b unity-api ? we're working around a mistaken commit in a branch by manual copying, and publishing a QA approved silo (https://requests.ci-train.ubuntu.com/#/ticket/564)
<dholbach> Mirv, I don't think I have access to whatever requires ./copy-package to be run
<Mirv> I copied the PPA ones + all others for xenial which were universe, but that one package is in main
<dholbach> I'm not an archive admin
<Mirv> dholbach: you don't need to be
<Mirv> dholbach: you can copy any package you'd have upload rights to, like I did for those universe packages (https://lists.canonical.com/archives/xenial-changes/2015-November/thread.html)
<Mirv> the command only complains if one tries to copy to real xenial instead of proposed
<Laney> you get it from lpubuntu-archive-tools
<dholbach> ok, I'll take a look
<dholbach> just a sec
<Mirv> thanks. I only selected you since you said good morning here so I thought you'd be around :)
<dholbach> :)
<dholbach> Mirv, done
<Mirv> dholbach: thanks! Saviq ^ all done now
<rbasak> pinba-engine-mysql FTBFS on some architectures is blocking mysql-5.6 from proposed migration. The issue is forwarded upstream but currently doesn't have a resolution
<rbasak> Opinions on forcing it and dropping pinba-engine-mysql from those architectures?
<rbasak> (the Debian maintainer forwarded it)
<cjwatson> rbasak: well, we shouldn't force it in proposed-migration, but yeah, I'm somewhat inclined to remove it from the affected architectures.  let me look
<cjwatson> I know I synced it, doko had previously reverted it, had been meaning to look anyway
<cjwatson> rbasak: could you remind me of a reference to the upstream bug?
<cjwatson> Odd_Bloke: thanks, looking
<rbasak> cjwatson: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793511 and https://github.com/tony2001/pinba_engine/issues/40
<ubottu> Debian bug 793511 in src:pinba-engine-mysql "pinba-engine-mysql: FTBFS (32-bit): cannot convert 'uint64_t*' to 'Word_t*" [Serious,Open]
<cjwatson> rbasak: thanks, nuked from xenial
<cjwatson> (on 32-bit arches)
<rbasak> cjwatson: thank you!
<cjwatson> Odd_Bloke: uploaded
<cjwatson> thanks for the long patch!
<Odd_Bloke> cjwatson: Thanks!
<roaksoax_> pitti: howdy! is there a way to tell adt to build different packages when passing --unbuilt-tree ?
<roaksoax_> pitti: right now we are saying "--unbuilt-tree=$PATH/maas" and 'maas' is the source, that contrais debian/ inside
<roaksoax_> pitti: however, I not only want to build MAAS, but I also want to build another package *before* maas
<roaksoax_> pitti: i.e: http://pastebin.ubuntu.com/13123203/
<roaksoax_> pitti: or is there another way to insert dependencies?
<Shock> hi
<Shock> I found a bug regarding the adding of routes related to multiple IPs on the same interface, but I'm not sure if I should report it for network-manager or linux. can you help me?
<Odd_Bloke> cjwatson: Would you expect powerpc cloud images to have UEFI and a PReP partition a la ppc64el?
<Odd_Bloke> cjwatson: FFS, s/UEFI/GPT/.
<Odd_Bloke> Some day I will stop conflating those two things.
<Odd_Bloke> cjwatson: Or would a single-partition MBR (a la amd64/i386 -disk1 images) be what you would expect?
<cjwatson> Odd_Bloke: I'm not sure about the exact firmware details, but I suspect what would work best would be MBR with a PReP partition, so part-way between the two options you gave.
<cjwatson> Odd_Bloke: infinity might have a clearer idea.
<cjwatson> Odd_Bloke: It's possible that UEFI might work, but it will probably depend on the firmware ...
<cjwatson> Maybe it's safe to assume a new enough slof.
<cjwatson> Err, GPT not UEFI.  Now you've got me doing it. :-P
<Odd_Bloke> :D
<Odd_Bloke> OK, I'll try using the ppc64el codepath (because that's easy).  And then if we decide that we can't do that, I can look at doing something else.
<pitti> roaksoax_: in principle you can run another test (including build) before the maas argument, yes
<pitti> roaksoax_: or if you don't want to run the tests for those, just give adt-run the extra locally built .debs *before* the --unbuilt-tree, then these debs will be taken into consideration for the maas test
<ogra_> cjwatson, i just had a "temporary failure in name resolution" for ftpmaster during a PPA build (retry worked fine but i thought you might want to know )
<cjwatson> ogra_: thanks, not concerned right now (at a conference) if it isn't persistent
<ogra_> k
<roaksoax_> pitti: ok, great! Thanks!
<roaksoax_> pitti: so basically, doing something like this: http://paste.ubuntu.com/13124111/
<Odd_Bloke> cjwatson: https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc/+build/42512 \o/
<elbrus> is Martin Pitt around?
<seb128> elbrus, he's pitti on IRC
<Odd_Bloke> pitti: ^
<cjwatson> Odd_Bloke: whee
<cjwatson> Odd_Bloke: do you have a way to test that this actually does something useful? :-)
<Odd_Bloke> cjwatson: Not really; I was sort of hoping you did. :p
<cjwatson> infinity: ^- can you help out?
<elbrus> pitti: /me is looking at auto-pkg-test failures for dbconfig-common
<elbrus> last time you send me a patch.
<elbrus> I was wondering if the failure is related to $TMP(which I removed from the command)
 * elbrus wonders how much work it is to set up an environment where I can properly test my auto-pkg-tests such that they don't need to fail for Debian and Ubuntu
<cjwatson> elbrus: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test isn't too bad last I checked; I expect it isn't *too* much harder for Debian ...
<elbrus> cjwatson: last time I looked I couldn't get qemu stuff working on my computer, so I don't want to spend much time in that direction. lxc works great here however, so if that can trivially be hooked up...
<cjwatson> qemu> !
<elbrus> it is mentioned (but not explained how)
<cjwatson> you might find that the slew of options autopkgtests passes to qemu all by itself means you don't have to spend much time on that
<cjwatson> maybe you just weren't using the right options ... qemu has lots
<elbrus> ok, let me look at that after my current project than.
<pitti> elbrus: hey
<pitti> elbrus: man adt-virt-qemu explains how to build a suitable VM for sid
<pitti> elbrus: https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html (or in /usr/share/doc/autopkgtest/) explains teh available runners
<elbrus> pitti: did you already look at dbconfig-common by any chance?
<pitti> elbrus: lxc is fine, as long as you don't have a test which needs to twiddle kernel-y things (dbconfig shold be fine)
<pitti> that should even get along fine with a simple schroot
<pitti> elbrus: no, not yet, sorry
<elbrus> no, I mean I should look at it myself instead of you
<pitti> http://autopkgtest.ubuntu.com/packages/d/dbconfig-common/
<pitti> indeed, recent regression
<elbrus> (Debian mentality here ;))
<pitti> elbrus: that'd be great (I don't have much time right now, sprint and all)
<pitti> mkdir: cannot create directory â/shareâ: Permission denied
<pitti> ASSERT:expected:<1.8 1.10 1.10.1 1.10.2 1.11 1.12> but was:<>
<pitti> that's hopefully not too difficult to reproduce/understand for you?
<elbrus> do you think it could be related to TMP not being set by me anymore?
<pitti> looks like this is new in 1.8.55
<pitti> elbrus: sure, if that mkdir does something like mkdir $TMP/share
<mterry> chiluk, ever find another sponsor?  I can look at coreutils now
<chiluk> rtg took a quick look, but he got scared away.. so mterry that would be fantastic.
<elbrus> the regression doesn't make sense for anything in the "normal" code and the regression test runs fine for me...
<elbrus> so I believe it must be the env that is different
<mterry> chiluk, so this patch was different, did you have to backport more commits, or just make some minor adjustments or what?
<chiluk> rtg wanted me to split out each individual commit into it's own patch, but I think that would be more trouble than it's worth since almost all of those patches rewrite the filter_list function over and over again
<pitti> elbrus: we've never set $TMP explicitly in the tests
<chiluk> mterry I had to backport another 6 or so prereq patches.
<chiluk> the patches to the mountlist function are fairly similar..
<chiluk> df needed a bunch more work.
<mterry> chiluk, ick yeah.  I'm on board with one patch.  Not like they will be removed one by one later
<elbrus> pitty: now, but my old testcase had it in the command, but I thought it wasn't really needed
<chiluk> right.. it would make it easier to review in whole later.
<elbrus> apparently it is for the auto-pkg-test framework
<mterry> chiluk, not that trusty is a moving target really  :)
<chiluk> mterry .. may i suggest patching the sources, and then comparing the result with upstream at the last patch..
<mterry> chiluk, good idea  :)
<mterry> nice that we're in sync with upstream then
<chiluk> i.e. compare the df.c patch with http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9
<chiluk> and compare mountlist.c at http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9
<chiluk> mterry ^^
<elbrus> pitti: I should have said TMPDIR...
<pitti> elbrus: ah; adt-run did set that some years ago, but this was dropped a long time ago, not in the last month
<chiluk> mterry I originally wanted to find all the cherry-picks, but that quickly became not as useful because of all the patch overwriting
<elbrus> pitti: what SHOULD I use as TMPDIR
<elbrus> when I need one?
<pitti> elbrus: I don't know; what's not good enough about /tmp?
<elbrus> don't know, why is it not set then?
<pitti> elbrus: I don't know why you need a $TMPDIR, so that's hard to answer
<elbrus> a place to store temporary stuff ;)
<pitti> -Test-Command: TMPDIR=/tmp test/runtests.sh
<pitti> +Test-Command: test/runtests.sh
<pitti> ah
<pitti> so if you explicitly use $TMPDIR without a fallback, but don't set it any more, there's the problem :)
<elbrus> indeed
<pitti> elbrus: mkdir(1), mkstemp() etc. all default to /tmp
<elbrus> well, fallback is the empty string
<pitti> right, but then mkdir $TMPDIR/share will be /share
<pitti> you probably either want something like
<pitti> myworkdir=$(mktemp -d)
<pitti> or perhaps use ${TMPDIR:-/tmp}
<elbrus> ok, I will fix the test framework to do a proper fallback with mktmp
<chiluk> mterry then I'll poke pitti or arges to approve the SRU after your review.
<pitti> or just hardcode /tmp/workdir/
<elbrus> yeah, I like  ${TMPDIR:-/tmp}
<pitti> elbrus: ^ this is bad style for production code (susceptible to symlink attacks and DoS), but probably tolerable for test code
<pitti> elbrus: oh, perhaps you meant $ADTTMP
<elbrus> indeed
<pitti> elbrus: you can use that, it's created/cleaned for every test, and it's owned by you
<elbrus> could I do that TMPDIR=$ADTMP in the command line?
<pitti> elbrus: sure
<elbrus> or does the command line not resolve variables?
<elbrus> pitti: I mean in the "Test-Command" line
<pitti> elbrus: it does, it's a normal shell string
<mterry> chiluk, where is lib/mountlist.c in coreutils trunk?
<pitti> elbrus: you used that before, after all
<chiluk> mterry that's part of the gnulib trung
<elbrus> nope: I just set it, not use an other variable in it
<chiluk> mterry debian takes both the gnulib and coreutils projects and merges them into the coreutils package
<elbrus> but ok, I will just update the test-command line then
<mterry> chiluk, ah right...  humph
<pitti> elbrus: it'd be the first test that uses $ADTTMP in the Test-Command:, but it ought to work and is certainly meant to
<chiluk> mterry  http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe
<pitti> elbrus: thanks!
<elbrus> np
<mterry> chiluk, so I'm on board with the patch itself.  But building it in a pbuilder failed on some tests.  Trying to figure out why, but have you seen anything similar?
<chiluk> pbuilder doesn't build coreutils well.
<chiluk> mterry use sbuild.
<chiluk> I hit the same issue.
<mterry> humph
<chiluk> yeah we should probably care, but I just moved to sbuild for coreutils
<chiluk> mterry++ for test building!
<mterry> chiluk, yeah except I'm just going to trust your build rather than moving to sbuild  ;)
<chiluk> mterry now I'm scared...
 * chiluk goes to build it one more time for shits and giggles.
<elbrus> pitti: just a thought, could the results of auto-pkg-test not be made more visible, e.g. in the launchpad page of the source of a package?
<elbrus> now everytime I need to search where again these results are stored (no I don't bookmark a lot)
<pitti> elbrus: we certainly could; just didn't happen so far
<elbrus> I believe it is worth it
<elbrus> other question, how long does a package stay in the proposed slot if auto-pkg-test doesn't fail?
<elbrus> I mean, if it is there, can I assume the test failed?
<pitti> elbrus: we don't have time based migration; as soon as it's built, installable, and tests succeed it lands
<cjwatson> LP doesn't currently have good support for linking to artifacts outside LP
<pitti> elbrus: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dbconfig-common
<cjwatson> we'd like to have that so that LP itself doesn't have to grow so much, but we don't really yet
<pitti> elbrus: you see there's no excuse for "too young", we don't do that
<cjwatson> William did some work recently on generalising cross-references, with an eye towards supporting this better in the future
<elbrus> cjwatson, pitti: ack
<infinity> cjwatson, Odd_Bloke: I can give that a try in a VM and see what it does.
<chiluk> mterry yes built fine, with pristine sources for me.
<Odd_Bloke> infinity: Yes please!
<mterry> chiluk, nice
<mterry> chiluk, commented on bug, uploaded to trusy
<infinity> Odd_Bloke: I assume it's a "proper" cloud image with cloud init and such and will do Bad Things without a fake data source or whatever?
<chiluk> yeah it's a pbuilder sbuild issue somehow.
<Odd_Bloke> infinity: Yep.
<Odd_Bloke> infinity: The disk is created using the same codepath as ppc64el; cjwatson thought that disk format might be an option, and it was easy to create so that's what I did.
<Odd_Bloke> infinity: If we need to do something different (e.g. MBR rather than GPT), that's doable. :)
<infinity> Odd_Bloke: GPT should work fine.  I just have to remember how to boot a cloud image. :P
<Odd_Bloke> infinity: If I'm testing stuff in a published image, I do it in a cloud because they remember how to do that for me. :p
<infinity> Odd_Bloke: Yeah, well, chickens and eggs.  I'm just testing with raw qemu to see if it does a thing.
<Odd_Bloke> It will not work on a chicken.
<ogra_> cloudy chicken ?
<seb128> bdmurray, hey, the nautilus retracing in 15.10 seem to fail, do you know why? e.g https://errors.ubuntu.com/problem/d3c6ff4abc2efa01df5d1b7e2c89932a61eabe27
<infinity> Odd_Bloke: No dice.  Drops me to a grub CLI.
<Odd_Bloke> infinity: Sadface.  Is there a way I can reproduce the boot problem?
<infinity> Odd_Bloke: Do you have access to the power test network in 1SS? (can you connect to 10.245.64.15?)
<Odd_Bloke> infinity: Doesn't look like it.
<infinity> Odd_Bloke: Might want to ask IS nicely if you can get VPN/firewall access to it.  Then I can give you root on a host to fiddle.
<Odd_Bloke> infinity: Ack; RT opened.
<elbrus> pitti: $ dput ssh-upload ~/tmp/packages/dbconfig-common_1.8.56_source.changes # done
<pitti> elbrus: \o/ cheers
<pitti> elbrus: oh, do source uploads for arch:all now work for Debian?
<elbrus> let's see if it works (didn't test that)
<elbrus> yes
<elbrus> only restriction is you can't do it with packages that go throu NEW (but that is also true for arch:any)
<bdmurray> seb128: I'll have a look.
<seb128> bdmurray, thanks
<bdmurray> seb128: It has a bunch of ?? () in the retraced Stacktrace
<seb128> bdmurray, same for https://errors.ubuntu.com/problem/38f94b04b1728eb78d82f272f0a7ec8d53ec8bab and https://errors.ubuntu.com/problem/bb3d8512e950429cd93b4fdea436327758d988bb ?
<bdmurray> seb128: yeah
<seb128> bdmurray, do you know if any debug symbol is missing or something?
<bdmurray> seb128: a couple mention libibus-1.0-5, libuuid1, libgirepository-1.0-1.
<seb128> those shouldn't matter for the top of the stacktrace...
<bdmurray> seb128: right
<slangasek> doko_, infinity, dannf: is there any known breakage with the neon implementation on our armhf autobuilders and/or cady?  ffmpeg FTBFS with a neon test failure which doesn't fail in Debian unstable; ffmpeg itself is supposed to dynamically detect whether neon is present, and appears to be doing that correctly based on /proc/cpuinfo, so the test would be skipped if neon were not available
<dannf> slangasek: not known breakage; is this exynos5? I know we did a lot of performance testing back in the day w/ neon enabled and didn't have any problems. so, neon is there, but perhaps it is buggy
<slangasek> er, rather - the test would fail if built on a machine without neon, but the code itself would runtime-detect
<infinity> slangasek: The highbanks are NEON-capable and should be fine.
<slangasek> dannf: cady is exynos5.  I don't know about the builders
<dannf> builders are highbank
<slangasek> ok, so why does this NEON test explicitly pass in Debian and fail in Ubuntu
<dannf> or midway - one of the calxedas
<infinity> slangasek: Debian's builders might not be NEON-capable, you might be debugging it backwards.
<ogra_> yeah
<slangasek> infinity: no, the Debian build log shows the NEON test running and passing
 * ogra_ was about to say that
<slangasek> which AFAICS it wouldn't be able to pass if Debian's builders were non-NEON; if I'm reading right it would give invalid instruction
<infinity> It wouldn't just skip the test and claim a pass?
<slangasek> infinity: by my read, no; #if HAVE_NEON (which the log shows is true), call the neon function
<infinity> Hrm.
<slangasek> anyway
<slangasek> if there are no known problems w/ neon on these boxes, I'll continue digging - thanks
<infinity> Certainly none that I've run into.
<infinity> We build and test a lot of NEON code.
<infinity> And the highbanks are pretty much just stock A9s, nothing sketchy going on with the core design.
<ogra_> are there actually still non-NEON v7 arches that we support ?
<ogra_> probably it is time to re-visit the defaults of this anyway
<infinity> ogra_: Well, "the defaults" don't need to change even if we revisit (which, yes, I wanted to do for 16.04), just the "disable NEON where it's on by default upstream" thing could change.
<infinity> Auto-vectorization with NEON still sucks, so the toolchain shouldn't ever change.
<ogra_> ah, k
<ogra_> yeah, i meant the toolchain/compiler opts
<infinity> No one cares about Tegra1, AFAIK, the only other interesting target is some older Armadas.
<infinity> I think the newer Armadas have NEON.
<ogra_> right, both of them is what i'd consider dead by now :)
<infinity> But I meant to draft a mail about it and gather some data and opinions before changing our position.
 * ogra_ is all for switching ... 
<dannf> doko_: do you know if this was ever submitted upstream? looks like i might have a need to sru it back to trusty - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785756
<ubottu> Debian bug 785756 in src:libffi "libffi: bug on arm64 when passing small struct on stack" [Normal,Fixed]
<doko_> slangasek, I don't know about any
<dscastro> hello, i have random crashes on my apache, i managed to get the stack http://www.fpaste.org/287684/44682637/
<infinity> dscastro: https://bugs.launchpad.net/ubuntu/+source/php5/+filebug
<chiluk> mterry https://launchpadlibrarian.net/224248565/buildlog_ubuntu-vivid-ppc64el.coreutils_8.23-3ubuntu1.1_BUILDING.txt.gz   do you know if this is valid?
<mterry> chiluk, failed on test-lock?
<chiluk> yeah that doesn't make any sense to me.
<chiluk> I'm really quite confused because it builds for every other arch including wily
<chiluk> mterry did you happen to turn that test off for the wily upload?
<chiluk> I just wonder if there was a coincidence..
<mterry> chiluk, I don't think it was that test that got changed
<chiluk> maybe it was a fluke build failure?
<chiluk> I wonder if infinity has any clue why it might be failing on ppc64el
<chiluk> infinity: https://launchpadlibrarian.net/224248565/buildlog_ubuntu-vivid-ppc64el.coreutils_8.23-3ubuntu1.1_BUILDING.txt.gz
<chiluk> infinity it's only failing on ppc64el, and mostly the same code works in wily...
<chiluk> I don't think my patch affected that test at all.
<caribou> cyphermox: LP: #1491894 has the debdiff for the review we've made yesterday
<ubottu> Launchpad bug 1491894 in grub2 (Ubuntu Trusty) "lucid to precise to trusty upgrade may leave system unbootable" [High,In progress] https://launchpad.net/bugs/1491894
<seb128> doko, what's the right component to report the fact that gdb doesn't work when python-scripts is loaded?
<cyphermox> caribou: great.
<doko> seb128, gdb
<seb128> doko, thanks
<infinity> chiluk: Dunno off the top of my head, but a hint for you is that ppc64el is the only arch that builds -O3 by default, the rest are -O2.
<infinity> chiluk: It could also just be a cosmic rays oops.  I'll retry it.
<chiluk> thanks infinty
<infinity> chiluk: Worked on a retry.
<pitti> utlemming: how does the net.ifnames=0 get into a cloud-image boot? I don't see it in the cloud-init package
<pitti> utlemming: my images got broken as I purged cloud-init and rebooted, then the network names changed
<ogra_> pitti, livecd-rootfs revision 1219
<pitti> ah, so it's the image build process
<ogra_> -GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0"
<ogra_> +GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 net.ifnames=0"
<ogra_> seems it mangles /etc/default/grub
<pitti> so I wonder how it's not there any more after a reboot
<seb128> doko, k, so the gdb issue might be 32bits specific
<seb128>   File "/usr/share/gdb/python/gdb/FrameDecorator.py", line 97, in function
<seb128>     if not isinstance(self._base, gdb.Frame)
<seb128> OverflowError: Python int too large to convert to C long
<ogra_> pitti, well, do you see it in /etc/default/grub ?
<seb128> doko, unsure why it's starting in xenial/with the python default change
<seb128> barry, ^ you might know?
<pitti> ogra_: ah, I have a /etc/default/grub.d/, and that doesn't have this change
<ogra_> aha
<fossterer> Hi! I've been using 15.10 daily builds so far. Now that 16.04 daily-builds are getting ready, is there a way for me to move to 16.04?
<barry> seb128: yes, that's a 32bit thing.  i had the same problem in system-image way back when
<pitti> meh
<ogra_> fossterer, sudo do-release-upgrade -d
<pitti> so this hack ripples through everything using cloud images now
<ogra_> that should get you onto the development release (if update-manager already knows about it)
<seb128> barry, do you know what changed between wily and xenial that it starts being an issue now only?
<fossterer> ogra_: Can you use it to upgrade an installed 'daily-build' ?
<ogra_> pitti, yeah, sadly using the "hooks" subdir for hack in livecd-roofs has become a common practice :(
<ogra_> *for hacks
<barry> seb128: sorry, is that in gdb?
<seb128> barry, yes
<seb128> barry,  File "/usr/share/gdb/python/gdb/FrameDecorator.py", line 97, in function
<seb128>      if not isinstance(self._base, gdb.Frame)
<jtaylor> ah problem in gdb/python in xenial is that the frameobject is optimized out now
<jtaylor> very annoying
<jtaylor> might be related
<seb128> barry, gdb didn't change though, it just got a non change rebuild with the new python default
<jtaylor> I wonder if doko would accept a patch to python to keep the object not removed, I doubt it has performance relevance
<seb128> jtaylor, what do you mean optimized out? is there a report about that?
<seb128> jtaylor, also gdb didn't change so why/how did that change?
<barry> seb128: yeah, my question too :)
<jtaylor> let me have a look, reproducable how?
<seb128> reported bug #1513922
<ubottu> bug 1513922 in gdb (Ubuntu) "[xenial] backtrace gives python error" [Undecided,New] https://launchpad.net/bugs/1513922
<seb128> jtaylor, use i386, "gdb <binary>", run, ctrl-C, bt
<jtaylor> hm that looks more like a bug in gdb
<jtaylor> 0xffffffff is a bit strange address
<seb128> yeah, i'm just wondering why it was working in wily
<jtaylor> isn't that range reserved for kernel?
 * jtaylor needs to create a chroot first
<fossterer> Ok,Thanks for responding, ogra_!
<fossterer> I'll try with 'do-release-upgrade'
<jtaylor> seb128: which binary did you use?
<jtaylor> i386 kernel too?
<seb128> yes for the kernel
<seb128> binary I tried different ones
<seb128> initially nautilus
<seb128> but it does the same on e.g gnome-calculator
<seb128> jtaylor, does the same with "vim"
<seb128> (attaching an instance open elsewhere)
<jtaylor> I only have an amd64 kernel available maybe I won't see it
<jtaylor> weird that you get such a number, I think the userspace max address should be 0xbfffffff on 32 bit
<seb128> yeah
<slangasek> doko, infinity, dannf: fwiw the ffmpeg build failure is reproducible on armhf with the previous version of ffmpeg on xenial, so looks like a toolchain regression
<pitti> ogra_: thanks for pointing out
<ogra_> :)
<pitti> utlemming: I now added a counter-hack in autopkgtest, but meh not pretty; I added a task to bug 1510345, can we clean this up for xenial?
<ubottu> bug 1510345 in cloud-init (Ubuntu Xenial) "[SRU] Cloud Images do not bring up networking w/ certain virtual NICs due to device naming rules" [Undecided,Triaged] https://launchpad.net/bugs/1510345
<jtaylor> seb128: fwiw I think the bug is in py-framefilter.c:1103 which is missing an overflow check
<jtaylor> but I'm clueless where the number comes from, probably need to fix gdb first to see that :)
<seb128> jtaylor, can you comment on the bug saying that?
<jtaylor> I posted a patch there
<seb128> thanks
<jtaylor> might be the wrong spot, just guessing :)
<dobey> is there a debootstrap update for trusty, that supports xenial?
<dobey> ie
<dobey> E: No such script: /usr/share/debootstrap/scripts/xenial
<dobey> i get that when trying to lxc-create a xenial container
<jtaylor> dobey: apt-get upgrade should do it
<dobey> jtaylor: was it just released today? i install updates every morning, as i have some daily PPAs
<jtaylor> dobey: oh you need -proposed
<dobey> oh, no bzr imports for xenial?
<dobey> jtaylor: how much longer til it shows up it in -updates?
<dobey> meh i'll just copy the xenial version to my ppa :)
<jtaylor> you can also just create the symlink yourself
<chiluk> thanks infinity
<dobey> jtaylor: ugh. well lxc-create failed because "lxcguest" is not available but referred to by another package, now :(
<dobey> guess i'll have to create a vivid image and then dist-upgrade it to xenial :-/
<chiluk> mterry, infinity says the respin fixed the ppc64 vivid build.
<mterry> chiluk, oh nice
<chiluk> mterry how's the review going?  any questions?
<mterry> chiluk, didn't I mention uploading to trusty?
<mterry> chiluk, I commented in bug too
<mterry> chiluk, just waiting on sru approval to go through to proposed
<chiluk> alrighty thanks!
#ubuntu-devel 2015-11-07
<mitya57> Can someone please reject pyflakes in xenial NEW? See debian #804319 & debian #804320
<ubottu> Debian bug 804319 in src:pyflakes "package split missing proper brekas/replaces" [Serious,Open] http://bugs.debian.org/804319
<ubottu> Debian bug 804320 in python-pyflakes,python3-pyflakes "python-pyflakes,python3-pyflakes: missing B+R: pyflakes for package split" [Serious,Open] http://bugs.debian.org/804320
<cjwatson> xnox: ^- pls fix pyflakes kthxbye :)
<cjwatson> mitya57: done
<mitya57> ta
<psusi> does anyone know why gnome-keyring-daemon is no longer set to --components gpg in 15.10?  without it gpg-agent is used instead, but that is not set up correctly to prompt for the password in the gui
<psusi> is UDD kind of dead?  I seem to keep seeing more and more packages that do not have an up to date bzr branch
<psusi> hrm... strange... pinentry-gnome3 is listed as task: ubuntu-desktop, yet ubuntu-desktop does not depend on it, so it has not been installed after upgrading from vivid... why is this?
<cjwatson> psusi: We haven't got round to getting UDD running for xenial yet.  But it's also essentially unmaintained and will probably be replaced by dgit as soon as we get that working with LP
<cjwatson> (by coincidence, I'm working on one of the requirements for that at the moment)
<cjwatson> ubuntu-desktop Recommends: gnome-keyring Depends: pinentry-gnome3
<psusi> cjwatson, hrm... it depends on pinentry-gnome3 | pinentry.. for some reason when I upgraded I got pinentry instead of pinentry-gnome3
<psusi> shouldn't ubuntu-desktop force pinentry-gnome3 instead?
#ubuntu-devel 2015-11-08
<psusi> I'm guessing it is because gnupg-agent depends on pinentry-curses | pinentry
<psusi> and apt evaluated that first and so selected the curses version, which then satisfied gnome-keyring
<cjwatson> in xenial it just outright Depends: pinentry-gnome3
<Guest84389> Hi, is there a reason that starting from libpython3.4-dev (3.4.3) there is no libdir variable set in the pkg-config?
<ari-tczew> cyphermox: I'm just looking on changes happened in network-manager. I noticed that in merge version 0.9.10-4 you got "Don't have network-manager Depend on adduser.", but in the next merge 1.0.4 such change doesn't exist anymore. Could you check that one?
<__marco> Hi where should I ask for a package removal?
<sladen> __marco: launchpad
<sladen> __marco: but it's probably easier if you say what package it might be ;-)
<__marco> virtualbricks
<__marco> http://packages.ubuntu.com/wily/virtualbricks
<__marco> That version is so old that could be considerate obsolete
<sladen> https://packages.debian.org/jessie/virtualbricks  seems to the same version as in Debian ?
<sladen> (both 0.6.352-1)
<sladen> __marco: what's the plan for Debian?
<__marco> yes, but a new version should be uploaded soon
<__marco> I contacted the Debian maintainer and he will upload the new version as soon as he has time
<sladen> so to avoid breaking people's systems, and save work overall, would it make more sense to wait a couple of weeks and have it synced from Debian
<__marco> will the versions in willy and xenial updated as well?
<__marco> I mean, now that willy is releases, will a new version of a package accepted?
<__marco> otherwise waiting few weeks is not a problem at all
<sladen> __marco: it will get auto-synced to Xenial
<sladen> __marco: if there is a significant-enough reason (major bugs/non-functionality) then one can apply for an SRU (Stable Release-Update) to get it into wily
<sladen> __marco: there are occasional removals, but it's got to be a pretty strong reason.  For example bittorrent after the protocol changes and the other clients became /useless/
<sladen> __marco: being old on its own it's really reason enough, if it still works
<sladen> __marco: because users, by choosing a release, rather than the development pre-release are after stability
<xnox> cjwatson: sigh =)
 * xnox wishes that e.g. with dgit support these things can be auto-detected and auto-generated.....
<__marco> sladen: that version is full of bugs :). It never worked really and only cause of trouble to our users.
<infinity> So backport the bugfixes.
<__marco> The new version is the bugfix. It is (mostly) compatible with the old one
<infinity> Yeah.  That right there isn't suitable for an SRU.
<infinity> We don't take new versions just to fix bugs in *stable* releases.  Stable means "stable interfaces and behaviour", not "free of bugs".
<infinity> So, to fix bugs in a stable, you need to fix the bugs, not pull in a whole new version willy-nilly.
<__marco> a version is just a number. Pull the changes and you get the same interface and the same behaviour without the bugs
<infinity> You literally just used the evasive phase "(mostly) compatible".
<infinity> So, it's not "just a number".
<infinity> s/phase/phrase/
<__marco> we had few compatibility issues that we fixed. The problem is that the users of the old version are so few that our tests weren't enough. But will continue to work to improve that aspect
<__marco> a non-compatibility is a bug
<__marco> The major problem with that version in ubuntu is that "irritate" our users. Most of them never seen linux and a terminal. They do not understand what a repository is and how to install a specific version of a package
<__marco> when they do `apt-get install virtualbrick` and "it does not work, the program hangs", it is our fault for them
<infinity> So submit patches to fix the hangs?
<__marco> it does not matter if they just installed the wrong version
<infinity> We do this sort of thing all the time, there's no reason you need hundreds of commits to fix a few bugs.
<__marco> because the whole structure of the program was fragile and, if you will, I am such a good programmer to fix all of those problem in few commits
<__marco> I am sorry but I will try to backport the new version to willy and, if it will not work, I will try to remove it
<sladen> __marco: "whole structure of the program was fragile", this is why backport small eyeball-able fixes, instead of "just taking the new release"
<sladen> __marco: patches to fix bugs fully greeted with enthusiasm (both here, and in Debian---file in Launchpad/debbugs with minimal diff and precisely attributable to the bug it fixes)
<sladen> __marco: the crucial difference is bug fix vs. new features
<sladen> __marco: yes, it's tempting to put new good stuff in, but that doesn't keep the bug fixes trackable, nor achieve interface/library stability---which is the reason people choose "a release" (even if they don't know it)
<__marco> So looks really simple I will more than happy to do it if only I could. The cause of such hangs was a wrong use of threads. Many of commits are the attempt to fix it. I looks to work, until the program hanged one time more
<__marco> And fix threads problems is not so easy. "That threads should do something and use a library which is not threadsafe but have to use it to achieve that"
<__marco> so a new core was born which does not use threads. It this a feature o a bug fix?
<__marco> And all the refactoring, is splitting a function in two a feature or a bug fix?
<__marco> I am not trying to teach you your work nor trying to be an asshole. Just we think that that version should be not used by anyone. And not just because we want so.
<__marco> We never thought that it could be part of Ubuntu. That was our main mistake
<__marco> Because, I could prove it, it will not work in Ubuntu
<__marco> s/will/does/
<__marco> but anyway, I want to thank you to bear with me and show me such a big problem
<__marco> :)
<cyphermox> ari-tczew: IIRC it's unimportant, it's just that adduser gets used in debian to add the user to netdev, which we don't use in ubuntu. so I suspect it was just forgotten
<ari-tczew> morphis: are you going to merge network-manager? I've partially done
#ubuntu-devel 2016-11-07
<cpaelzer> good morning
<tsdgeos> any idea why when i press "ok" in the "Send this crash bug" i get no browser?
<tsdgeos> i think the crashes are not being reported
<tsdgeos> or are they just being sent to errors.u.c?
<mitya57> tsdgeos, they are sent to errors.u.c, and that happens silently
<mitya57> But you can enable sending them to Launchpad as described in https://wiki.ubuntu.com/Apport#Ubuntu_12.04_and_later
<tsdgeos> ok, so we don't even open the browser anymore?
<tsdgeos> interesting, i guess it's an old intall vs new install thing?
<mitya57> For me when apport upgrades, I am prompted whether I want to keep my crashdb.conf or update it to the package version
<mitya57> I always have that commented out, so I say no :)
<mitya57> And the browser is not opened, because users do not have access to errors.u.c.
<abeato> pitti, hi, I have opened bug #1639754, and would like to get your opinion. Ideally NM should manage all network connections if present, but not sure if that can be done easily when installed as a snap in Core. What would you think it is the best solution?
<ubottu> bug 1639754 in snappy-hwe-snaps "Ethernet devices have higher metric than wlan or wwan ones" [Undecided,New] https://launchpad.net/bugs/1639754
<tjaalton> doko: x-x-i-libinput MIR bug modified
<mdeslaur> xnox: hi! are you going to look at the openssl issue?
<xnox> mdeslaur, check #ubuntu-installer
<mdeslaur> ah!
<xnox> there cannot be a more obscure channel to discuss openssl 1.1 transition lol
<mdeslaur> yeah, I saw mention of it yesterday because my channel lighted up, but I couldn't find it again this morning :)
<doko> infinity, pitti: please could you hold back the dpkg merge a bit? I'd like to do one more test rebuild for the Linaro toolchain first in Nov, and would like to avoid mixing this with any PIE changes
 * Mirv thinks of asking about openssl but notices I'm not alone
<Mirv> I guess I'll build against libssl-dev for now instead of libssl1.0-dev Debian uses
<slangasek> doko, infinity, pitti: well, shouldn't we have a discussion about whether we want to enable PIE on the remaining archs, independent of Debian's decision and independent of the dpkg merge?
<doko> slangasek: sure, let's do that at the sprint
<slangasek> doko: how about at UOS?
<doko> meh, maybe
<doko> tjaalton: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg please could you have a look at the khronos mismatch?
<doko> ahh, that was already done an hour ago
<nacc> cpaelzer: do you happen to know what the tags pointed to before such that I can reproduce? and if so, can you file a bug?
<nacc> rbasak: ping
<rbasak> nacc: o/
<nacc> rbasak: hey! have time for a quick sync up -- can do here or HO, whichever is easier
<rbasak> Sure
<rbasak> nacc: how about the regular team hangout?
<nacc> rbasak: thanks!
 * rbasak is there
<IemSPkZpALESHgmU> https://www.youtube.com/watch?v=3EsJLNGVJ7E & https://wikileaks.org/podesta-emails/emailid/15893, https://wikileaks.org/podesta-emails/emailid/23561, http://www.reuters.com/article/us-usa-election-foundation-idUSKBN12Z2SL & https://wikileaks.org/podesta-emails/emailid/3774 (ctrl+f qatar) - please don't let these be buried
<dobey> sigh
<dobey> stupid botnet
<nacc> smoser: so, the dsc branch: would you prefer importer/{debian,ubuntu}/dsc as branches or importer/dsc:{debian,ubuntu}/ as paths ?
<smoser> i think consistent with pristine-tarball branch or tags... again, i guess they dont have to be a branch
<nacc> so right now we have improter/{debian,ubuntu}/pristine-tar, because they need to be branches and, in theory, there could be collisions
<smoser> sure. so i think importer/{debian,ubuntu}/dsc for consistency dont you think ?
<nacc> yeah, i think that's fine
<nacc> fwiw, we're going to namespace the branch of lpusi/lupsd to importer/
<nacc> that way it's clear that the series branches are ubuntu/ and debian/
<nacc> while the importer-specific branches are in importer/
<xnox> tedg, in https://bileto.ubuntu.com/#/ticket/2129 i have retried zesty unity-shell thing it should build now with fixed boost.
<xnox> (retried builds in the ppa, not sure what needs to be clicked on the bileto once those finish and fully publish)
<tedg> xnox: bileto should pick it up
<tedg> xnox: When the builds are complete
<xnox> cool, then i will not check on it =)
<rbasak> smoser, nacc: is there any chance we'll want to store anything else? Because then instead of a branch per-thing-to-store, we may want to use a single branch and a flatfile arrangement for things-we-want-to-store instead.
<rbasak> git-annex does this, for example. pristine-tar is effectively doing the same - one branch per project.
<rbasak> But really perhaps each project should parameterise the branch and use a subdirectory.
<rbasak> Anyway, I have No Strong Opinion. Just a thought.
<nacc> rbasak: not sure that'd work with pristine-tar
<nacc> rbasak: as in, i think we need a branch for each to gain the benefits, and to separate out the tarballs
<rbasak> It could work in theory I think, but of course that would require support in pristine-tar.
<nacc> pristine-tar and gbp are rather inflexible
<nacc> i've found
<nacc> rbasak: smoser: so gbp does the `gbp <subcommand>` stuff via setuptools, it seems. Do we want to go down that route (more reorganization). Or is it appropriate to do it manually ourselves (as we don't have a setup.py currently anyways) -- preferences?
<rbasak> nacc: I'm not sure. I'm not really very familiar with this area.
<rbasak> Being able to run it out of the working tree is useful.
<nacc> rbasak: yeah, and it seems like gbp, e.g., can't be run that way (direct from the git tree)
<nacc> so maybe i'll just write  asimple wrapper for now
<rbasak> OK
<nacc> and we can figure out packaging later :)
<smoser> nac, so.. gbp uses setup tools for entry points.
<nacc> smoser: right, amongst other things, yeah
<smoser> entry points dont indicate how subcommands are done.
<nacc> i mean, gbp defines the subcommeands using an entry point
<nacc> 'console_scripts'
<nacc> i'm just trying to look at how other packages do it, gbp was the first i tried
<nacc> git is a C program, so that doesn't help
<nacc> i could probably wrap waht gbp does in direct python
<nacc> smoser: i think that's your point?
<smoser> well, no.
<smoser> as far as i can see, git-buildpackage defines a single console_script (gbp.scripts.supercommand:supercommand)
<nacc> yes
<smoser> that just gest you the python launcher that goes in /usr/bin
<nacc> yes
<smoser> it doesnt indicate how you do subcommands
<nacc> gbp.scripts.supercommand is *how* gbp does subcommands
<nacc> specifically, gbp.scripts.supercommand.supercommand()
<nacc> basically i'd take something similar and put that in usd
<smoser> well, unless you have a reason, i'd suggest just using argparse.
<smoser> https://docs.python.org/3/library/argparse.html#sub-commands
<nacc> ah nice
<nacc> i hadn't found that
<nacc> no, i have no reason to do it other way
<nacc> smoser: thanks!
<nacc> yeah that looks way easier :)
<smoser> it has some hangups, largely my issues are when you're trying to pas through args that you dont really want to "know".  and dont' want to go the '--' route.
<smoser> ie, gbp build -uS -uc
<smoser> without "knowing" about uS and uC things can be tricky
<smoser> ie, determining when that was bad arguments to you versus stuff to be passed on.
<nacc> i think we're going to rely on --
<smoser> https://realpython.com/blog/python/comparing-python-command-line-parsing-libraries-argparse-docopt-click/
<nacc> it only is needed for usd buildpackage (note the rename)
<smoser> just something i googled here... the other options he discusses there are not standard library, so i'd probably use argparse
<nacc> smoser: pythonic question for you; given that we have a module namespace of usd, and i would like to use usd as the command base-name, would you recommend I 1) move usd/ to _usd/, 2) use a differnt command name (ubp?), 3) someting else?
<smoser> definitely not 1
<smoser> the entry point doesnt have to match anything really
<smoser> oh. you want python -m usd ? to do something?
<nacc> smoser: so i'm *not* using entrypoints, as you suggested to use argparse :)
<nacc> smoser: so i've got that mostly working
<nacc> but the base command, e.g, `usd`
<smoser> argparse and entrypoints are not contraditory with each other
<nacc> that name is obviously the name of a directroy already
<smoser> i think i'm confused though.
<smoser> lots of things would use both entry points and argparse
<nacc> so we don't have entry points at all right
<smoser> you dont have to.
<nacc> ok
<nacc> i'll read more
<smoser> an entry p oint just makes an executable out of a string like 'usd=usd.cmd.main'
<smoser> so that you get a /usr/bin/usd that does 'from usd import cmd; cmd.main()'
<smoser> or the like.
<smoser> then, what you do in that main is anything you want.  you can have one 'cmd' that does all the subcommands or separate them out
* ChanServ changed the topic of #ubuntu-devel to: Yakkety Yak (16.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-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<roaksoax> has something changed in zesty?
<roaksoax> mv: cannot stat '/<<BUILDDIR>>/maas-2.1.1+bzr5542/debian/tmp/usr/lib/python*/*-packages/maasserver/static': No such file or directory
<roaksoax> debian/rules:46: recipe for target 'override_dh_auto_install' failed
<roaksoax> before the python*/*-packages would match to python3/dist-packages
<nacc> smoser: got it
<nacc> smoser: but entry points only help for installation, afaict? that is, i can switch to entry points, but you won't be able to use usd (there won't be one) in the repository itself
<nacc> smoser: aiui, entry points provide a means to do `usd` if we 'install' the package. But given just a clone (as we have it now), there's no trivial way to do what you're suggesting?
<nacc> ah i think i found it
<nacc> but there's not a way around the aliasing issue (usd being both the eventual executable name and the package name)
#ubuntu-devel 2016-11-08
<smoser> nacc, you are correct. entry points generate little python executable scripts.
<smoser> i dont think there is an issue
<smoser> see curtin if you'd like.  curtin/bin/curtin <-- the exe.
<smoser> curtin/__init__.py stuff there.
<smoser> curtin/bin/curtin is more involved because we want it to work with any working python (not just /usr/bin/python2 or /usr/bin/python3). but it could just as easily have a python executable (and has in the past).
<nacc> smoser: right, it's just a (fully-expected) oddity that i need to create a bin/usd
<nacc> so it's one more dir to type
<nacc> but i think that's totally fine :)
<smoser> oh. ok. yeah. i see.
<smoser> well, youc ould name it usd.py
<nacc> right :)
<smoser> but yea.
<nacc> i'm about 50% done converting merge over
<smoser> i didn't understand your question till just now.
<nacc> clone should be really easy
<nacc> yep, i wasn't being clear, monday!
<smoser> with the bin/ thing, you also end up having to do something like maas-images/bin/meph-util
<smoser>  http://paste.ubuntu.com/23444358/
<smoser> which  uses dirname(__file)) to find "one up" dir and add it to the path
<smoser> (line 14 there).
<nacc> yeah
<roaksoax> doko, howdy... are there any python packaging changes in zesty we need to make ? A package that builds fine on xenial, yakkety, fails on zesty
<roaksoax> doko: lamont investigated it and found "21:32 < lamont> roaksoax-romania: so... I've isolated the problem to an update of python3-setuptools (and python3-pkg-resources)..  26.1.1-1 works,  28.7.1-1 does not.  if doko happens to be in romania,
<roaksoax> "
<cpaelzer> nacc: yeah I wisely made a copy of the tree, so I can reproduce - but I guess it is not an important one
<cpaelzer> btw good morning everybody
<pitti> Good morning
<RAOF> Aloha!
<cpaelzer> Still fishing my humuhumunukunukuapuaa
<pitti> hey RAOF, how are you?
<pitti> cpaelzer: your what? :)
<RAOF> pitti: Pretty well, thanks!
<cpaelzer> The hawaian national fish in reference to the Alo-ha
<RAOF> Yourself?
<pitti> RAOF: pretty good too; seems I evaded ubuflu this time, and Bucharest was nice
<cpaelzer> https://en.wikipedia.org/wiki/Reef_triggerfish
<RAOF> Woot!
<cpaelzer> pitti: is ubuflu the nickname for travel+sprint=cold ?
<pitti> cpaelzer: yes, it's got a long tradition
<RAOF> For the SOFT!
 * RAOF thinks he's evaded all the ubuflus.
<cpaelzer> too many people in over-airconditioned rooms and long plane trips I can't think why that happens :-P
<cpaelzer> pitti: every 1-2 hour on a plane and any those rooms one puff of https://www.aponeo.de/03114158-tetesept-nasen-gel-spray.html?a=1&src=ggl.pla is my defense - and since I do that neither ubuflu nor formerlly ibmflu got me
<cpaelzer> nacc: bug reported, but as I said not suprt important as one can work around with manually setting the tag just fine
<tsdgeos> is there a way to match one of my crashes in /var/crash to a report in errors.ubuntu.com ?
<mardy> Laney: hi! Have you any news about signon-ui? I think that I might push the "lander approved" button on the silo, as anyway it seems like an improvement over the current situation
<Laney> hey mardy
<Laney> you can if you like and handle this as another bug
<Laney> I didn't get it a second time
<mardy> Laney: ok, thanks
<doko> TheMuso: pulseaudio tries to pull python-qt4 into main ...
<doko> and python-sip
<doko> xnox: now demoting some boost1.62 binaries. you can't wait with this until the transition is finished
<StevenK> win 23
<pitti> hey StevenK, how are you? (good I suppose after winning so many!)
<nearffxx> HI, where can I get the git for binutils used in ubuntu?
<coreycb> bdmurray, good morning, can you promote nova 2:13.1.2-0ubuntu2 to xenial-updates?
<rbasak> nearffxx: there isn't necessarily a git tree (we've been doing this long before git existed). See https://launchpad.net/ubuntu/+source/binutils for links to the source.
<nearffxx> rbasak: I'm trying to fix a segfault in ar 2.6.1
<nearffxx> 2.26.1
<nearffxx> rbasak: It doesn't seg fault with standard config. What configuration did you use for the released version?
<rbasak> I don't know. Did you follow the link to the source? It's available from https://launchpad.net/ubuntu/+source/binutils/2.26.1-1ubuntu1~16.04.3.
<rbasak> You can follow the "Builds" links to get to the build logs, too.
<nearffxx> rbasak: I already downloaded and compiled
<nearffxx> I didnt see that
<nearffxx> thanks
<rbasak> The configuration is part of the source package.
<nacc> cpaelzer: right, but we want to ensure, if at all possible, that the defaults work for most people
<bdmurray> coreycb: one bug seems unverified so no
<coreycb> bdmurray, doh. i'll take a look.
<mdeslaur> infinity, kees, slangasek, stgraber: TB meeting in 10 min.
<attente> has there been some change to the synaptics driver? my touchpad settings don't work and synclient gives me "Couldn't find synaptics properties. No synaptics driver loaded?"
<seb128> attente, did you try to remove synaptic and just use libinput?
<seb128> attente, but otherwise tjaalton might know
<tjaalton> attente: do you have xserver-xorg-input-synaptics installed?
<attente> tjaalton, seb128: yeah, xserver-xorg-input-synaptics is installed. is it better to just remove that? how is libinput configured?
<tjaalton> you can't if you have unity
<tjaalton> configure it
<attente> ok, it's working now, thanks guys!
<tjaalton> how?
<doko> zul: rejected the monasca-statsd uploads. while 1.3 had the upstream copyrights fixed, debian/copyright is incomplete
<zul> doko: ok thanks
<nacc> smoser: quick q, is it just me or does usd-clone currently just accept --git --http --https all specified
<nacc> smoser: it just takes the last one it parses?
<smoser> that sounds possible
<smoser> yeah.
<nacc> smoser: ok, i can fix on the rewrite to `usd clone`
<nacc> smoser: just watned to check i wasn't going crazy :)
<smoser> its not necessarily wrong ;)
<smoser> it takes the last one. its *a* behavior. but sure, its fine to complain and fail
<nacc> smoser: yeah, i'm just going to make it explicit
<nacc> and i think it's not clear as-is :)
<nacc> it'll be a separate commit from the reorg, to be clear
<barry> nacc: hi!  can you update the usd-import for claws-mail?
<nacc> barry: sure
<barry> nacc: thanks!
<nacc> barry: it's going now; note that the tree structure has changed a little bit, but that shouldn't affect using the contents of imports -- we've added some new branches, etc. and updated the commit messages
<nacc> barry: i'll ping again when it's done
<barry> nacc: thanks, and cool.  i'm going to attempt a merge.  will let you know how it goes
<nacc> barry: also, fyi, i'm mid-updating the tools in the tree, you may want to wait til that's done to use the tools (should be done later today)
<barry> nacc: ok, thanks
<Unit193> LocutusOfBorg: There ya're.  Feeling sponsory?  I've got a simple one again.
<LocutusOfBorg> Unit193, go ahead
<Unit193> LocutusOfBorg: ssh://git.debian.org/git/collab-maint/inxi.git
<LocutusOfBorg> .
<nacc> barry: sorry, had lunch and it threw an error, fixed it, usd-import-team tree should be updated now.
<Unit193> LocutusOfBorg: Danke!
<TheMuso> doko: Urm I would have thought pulseaudio-equalizer would be in universe?
<TheMuso> doko: In any case, I'll drop that package for now so we can get things in...
<nacc> smoser: find_lp_user, does it end up trying more than one insteadof line? or only the first one?
<smoser> the awk exits on the first match
<nacc> smoser: ok, just trying to make sure i reproduce the behavior
<smoser> so just one. that matches that regex
<smoser> url.git\+ssh:.*@git.launchpad
<LocutusOfBorg> yw!
<nacc> smoser: there's a good chance i might break something subtly in this rewrite, just FYI :) will appreciate your testing once i push
<doko> TheMuso: ok, it's in main in zesty-proposed. will demote it
<TheMuso> doko: ugh just uploaded a revision to drop it, too late.
<doko> TheMuso: works for me too =)
<doko> infinity: glibc needs a pull from the debian branch to fix the ftbfs on ppc64el
#ubuntu-devel 2016-11-09
<g2> Exciting election talk and debate in #debate2016
<cpaelzer> good morning
<pitti> Good (well, "some") morning!
<LocutusOfBorg> TheMuso, hi, you there?
<LocutusOfBorg> question about Tascam US-122L
<LocutusOfBorg> should I just add a new profile in libasound2-data to make it work?
<pitti> stgraber: if you get pings about lxc being broken in zesty: this is https://github.com/lxc/lxc/issues/1280 and I reverted the usage of the unified hierarchy in systemd 232-3 (will hit zesty ~ tomorrow); local workaround is to boot with systemd.legacy_systemd_cgroup_controller
<stgraber> pitti: ok, thanks. I heard about it through Debian and assumed it'd affect us shortly after too and that you'd do the right thing on both :)
<pitti> stgraber: ah, ok; I just wanted to ensure that you don't have to do duplicate work; sorry for the hiccup
<pitti> nevertheless, it was useful to find these bugs
<pitti> but we shoudln't have to fix them under pressure
<stgraber> pitti: well, we knew about that issue and some others, the problem is that since the kernel won't let you mount cgroupv1 AND cgroupv2 for the same controller, even in separate namespaces, there is effectively no way to fix this...
<stgraber> pitti: other than convince Tejun that we do need to be able to mount cgroupv2 on the host and cgroupv1 in containers and have him allow that in the cgns code
<stgraber> or fake all that stuff with fuse, but that'd suck...
<stgraber> we mentioned all of this last week at Kernel Summit + Plumbers, with both Tejun and Lennart in the room, so neither of them can say they didn't know this would happen...
<stgraber> tych0, hallyn: ^
<tych0> in fact i had a big argument with tejun and he said he wouldn't fix it :)
<pitti> stgraber: ack; at least it shouldn't segfault, I see the difficulty in supporting v1 containers with v2 on the host, but I thought with cgroup namespaces you could actually do that? so that's not the case?
<tych0> pitti: right, it's global
<doko> seb128, Laney: is the desktop team caring about all the spell checkers? looks like hunspell-bo is seeded now, and would need a MIR
<seb128> hey doko, I don't think we are ... is that due to libreoffice?
<doko> seb128: I see it at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<Laney> doko: There's a regex which puts them all in supported
<Laney> others have this https://launchpad.net/~translators-packages team subscribed
<doko> one member team ...
<Laney> I don't think they require any real maintenance on our side
<smoser> cyphermox, mostly unrelated to the discussion in #ubuntu-release, so i've moved it here instead (and i'd also like pitti's input)
<smoser> http://paste.ubuntu.com/23374663/
<smoser> please do read https://git.launchpad.net/~smoser/ubuntu/+source/open-iscsi/tree/debian/tests/README-boot-test.md?h=diglett-master along with it and especially the Caveats there.
<smoser> i'm not sure where we should ultimately be running these tests, but we need to be running them somewhere for sure.
<cyphermox> heh, if it works in open-iscsi, that should be fine
<cyphermox> and hopefully doesn't break when at the start of a new release and there are no images, or something like that
<smoser> well, but what is the correct behavior in that case?
<cyphermox> what do you mean?
<smoser> if there is no image, what should it do ?
<cyphermox> I'm all for fixing those tests, they're broken in lots of fun ways, I only did enough for them to pass
<cyphermox> I suppose they should fail, but in a way that makes it obvious that it is a transient failure.
<smoser> and (see caveat 1), how should you patch an image in a dep8 test to include only the dependency that its attempting to verify
<smoser> ie, i can't just add -proposed and apt-get upgrade the image
<cyphermox> why not?
<smoser> as that will get everything in -proposed
<smoser> and no 'control'
<cyphermox> we probably could just install the new initramfs-tools, it's likely good enough
<smoser> does the environment have information on which package it is running to test ?
<cyphermox> I don't know
<smoser> this is what i'm saying... and even if it did, how do i get the right set of packages to update the image with ?
<cyphermox> I think that's the problem with running images like that though, not much of a way around it
<cyphermox> unless pitti has some idea
<cyphermox> otherwise I suppose the boot tests could be moved to the image promotion logic
<pitti> just here with Â½ a brain cell (deep in debugging), but the test does know which package it's running for: it's in $ADT_TEST_TRIGGERS
<smoser> the source package..
<smoser> you'd still have to tthenupgrade the image with the packages that were created from that and only those (i think )
<pitti> but, it seems much easier to look at the current package versions that are installed
<smoser> ?
<pitti> autopkgtest already install the minimal set of -proposed packages to verify that
<smoser> but they install them in the host
<pitti> (IOW: don't try to be clever)
<smoser> and i basically have to copy that set of things to the guest
<xnox> barry, is claws-mail python plugin written with boost-python at all?
 * xnox has no idea about claws codebase
<barry> xnox: it's not explicitly declared to, but otoh, the build log does pull it in
<barry> libboost-filesystem1.62.0
<barry> libboost-system1.62.0
<barry> xnox: otoh, python.so does not link against it afaict
<xnox> barry, in zesty? using old boost1.62? could you try rebuilding with 1.62.0+dfsg-2ubuntu1? and is it python2 or python3 that fails?
<barry> xnox: the plugin is a python2 plugin
<xnox> -2 had python3 broken; -2ubuntu1 should have python3 fixed; but maybe python2 is borked now.
<barry> xnox: and it does look like it picked up 1.62.0+dfsg-2ubuntu1 (this was a zesty schroot as of yesterday)
<xnox> not good if i broke python2 now.
<barry> xnox: so yeah, maybe python2 is broken (i don't know whether upstream supports python3, but i should look into that)
<xnox> barry, it's a double edge sward. these sort of plugins process user scripts and hooks and stuff; which is most likely written in python2.
<barry> xnox: like other plugins, it should build two versions and let the user decide
<xnox> if you can somehow make python2 & python3 plugins that would be great.... but i daubt one will be able to load and run, user scripts/hooks with python2 and 3 simultaniously.
<barry> i see that it pulls in both py2 and py3, but ldd shows it's linked only against py2
<pitti> stgraber: seems tejun and h_allyn figured this out in https://github.com/systemd/systemd/pull/3965
<barry> xnox: oh for sure, it will be a binary choice, but the user could decide which one they want
<xnox> pitti, \o/
<stgraber> pitti: based on discussion in #lxc-dev, it sounds like this only works if the container manager pre-mounts things instead of having systemd mount things itself
<stgraber> pitti: so not exactly perfect because LXD doesn't know what distro you're running, whether you want those mounts or not and where they should be
<pitti> stgraber: right -- like nspawn/lxc etc. mount a new hierarchy root "container" and then the guest does whatever it likes with it?
<stgraber> pitti: instead we much prefer the init systemd (or whatever else) in the container just do the mount
<pitti> ok; I'll leave it between h_allyn and tejun to continue discussing this, I don't know enough about the details
<stgraber> pitti: well, right now lxc doesn't mount anything, it creates the cgroups, moves you to them and unshares a cgroup namespace. the mounts are entirely done by systemd as it would on a normal system
<stgraber> pitti: and that part fails
<pitti> stgraber: oh, I understood it like the only thing that lxd needs to do is to create the new cgroup namespace, not any actual mounts
 * pitti bbl
<stgraber> pitti: yeah no, Tejun is talking about actual mounts
<juliank> pitti: Seems like apt/xenial failed on s390x. Is there a button for me to retry that?
<juliank> Ah found it
<Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#apt
 * Laney too slow
<juliank> Well, not sure it likes me: A server error occurred.  Please contact the administrator.
<juliank> There are some regressions from autopkgtest and sbuild, but I'm not sure they are related.
<juliank> That is, sbuild seems to fail ever since yakkety and now zesty became devel
<juliank> And autopkgtest also similarly seems to fail regardless of apt triggering the test or not
<juliank> Anyway, gtg now
<bdmurray> barry: could you have a look at this merge proposal for aptdaemon? https://code.launchpad.net/~flexiondotorg/aptdaemon/aptdaemon-lp1623856/+merge/309871
<flexiondotorg> bdmurray, Not yet.
<flexiondotorg> I've got an update in the works for it.
<flexiondotorg> Should be done tomorrow.
<bdmurray> flexiondotorg: The aptdaemon fix is incomplete?
<flexiondotorg> Actually no, the aptdaemon fix should be fine. There are some additions for update-manager.
<flexiondotorg> But both should be tested together.
<bdmurray> I don't see how that should block reviewing the upstream merge proposal.
<flexiondotorg> OK
<barry> bdmurray: commented
<bdmurray> barry: do you not want to merge it?
<barry> bdmurray: oh, i thought you were just looking for a review.  you want me to merge and upload?
<bdmurray> barry: please!
<barry> bdmurray: ok.  i need to finish up a few other things first.
<bdmurray> barry: Sure, not a huge hurry - I just saw you in the aptdaemon developers group
<barry> bdmurray: betrayed again!
<doko> bdmurray: is translators-packages a team which is ok for bug subscriptions?
<doko> only has one member
<bdmurray> doko: yes, its a placeholder for reports
<doko> bdmurray: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg please could you add hunspell-bo? then I'll promote it
<bdmurray> doko: translators-packages is now subscribed to all bugs about hunspell-bo.
<doko> hta
<doko> promoted
 * doko wonders why bo is selected for Tibetan ...
<cjwatson> doko: https://en.wikipedia.org/wiki/Bodish_languages
<cjwatson> The word for Tibet in Classical Tibetan was "Bod", apparently
<doko> cjwatson: ta for the pointer :)
<barry> bdmurray: do we want to sru this into yakkety or just fix it in zesty?
<bdmurray> barry: It sounded like flexiondotorg had some more update-manager work to do so lets wait for him to get that squared away for the SRU.
<barry> bdmurray: okay.  what i don't really remember is how to do aptdaemon releases.  we currently have deltas from debian, so i'm trying to decide whether to just upload this to zesty (furthering our delta).  i might contact upstream and see if we can get that merged there with an eventual merge to zesty
<bdmurray> barry: okay
<barry> bdmurray: i'm not even sure aptdaemon is still a thing in debian.  in any case, i've contacted upstream so we'll see
<coreycb> bdmurray, hello, if you have a chance this week could you review neutron in the trusty queue?
<bdmurray> coreycb: releasing neutron into -updates or accepting a new one into -proposed?
<coreycb> bdmurray, so many neutrons...  :) for trusty, just accepting into proposed would be great.  the xenial neutron should be ready to promote to updates.
<bdmurray> coreycb: got it
<coreycb> bdmurray, thanks
<nacc> jgrimm: sorry for the long delay, i'm re-running hte at import now
<nacc> jgrimm: smoser: rbasak: i just pushed up my local changes; i'm still testing them, but they seem stable, please ping if you find breakages (it was a ton of reorganizing)
#ubuntu-devel 2016-11-10
<nacc> jgrimm: https://code.launchpad.net/~usd-import-team/ubuntu/+source/at/+git/at
<pdeee> RAOF, hlieberman picking up the conversation about a xenial update to Certbot:
<RAOF> pdeee: Hi!
<pdeee> Hi!
<pdeee> (we have to distract ourselves from depressing news today)
<RAOF> I'm going to get a coffee right now, but I'll be back in 5 :)
<pdeee> RAOF, okay, I'll give you a status update then go and get a coffee :)
<pdeee> Certbot 0.9.3 is now in zesty
<pdeee> However, the team has identified a few reasons why they might want to wait for 0.10.0 if the updates process is sufficiently complex and time consuming
<pdeee> It both includes a couple of important bugfixes, and also a couple of very valuable features we'd want Xenial users to have
<pdeee> However, there's one noteworthy way in which 0.10.0 alters workflows
<pdeee> in a subjective if not substantive way
<pdeee> in particular, the dialog-based user interface has been removed
<RAOF> Hm.
<pdeee> (because it was both mysteriously rendering in broken ways when sshing into some servers, and because of weird annoying bugs like these:
<RAOF> That doesn't particularly scream âlet's push this as a bugfix only release to all our most conservative usersâ.
<pdeee> https://github.com/certbot/certbot/issues?q=is%3Aissue+dialogerror+is%3Aclosed
<pdeee> So running Certbot 0.10.0 will be like running Certbot 0.9.3 with -t
<RAOF> So, the SRU process for 0.9.3 shouldn't be terribly onerous.
<pdeee> But you think it would be harder for 0.10.0?
<RAOF> I'd be more hesitant to SRU something that drops a previous UI, yes.
 * pdeee nods
<RAOF> I understand that this is not ideal for you - or, even, for new users - but if existing users have successfully used the dialog UI then they haven't been hitting the bugs in it, and removing it breaks whatever documentation they've put into place.
<RAOF> (We're meant to be the ones getting all the bugs related to the dialog UI, but that doesn't always end up being the case)
<pdeee> And, if you were going to score the strength of this objection out of ten, how high would you score it?
<RAOF> Off hand, I'd probably put it at a 7 or so?
<pdeee> Here are some examples of the dialog bugs:
<pdeee> https://github.com/certbot/certbot/issues/2025
<RAOF> What does the new text interface look like?
<pdeee> RAOF, do you have a copy of Certbot?
<pdeee> If so, run it with -t
<pdeee> if not, I can screenshot you something
<pdeee> (Certbot on Zesty or Yakkety)
<RAOF> Hm. I can run it, but it fails immediately because I don't have a webserver on this laptop.
<pdeee> okay, I'll screenshot
<RAOF> To
<RAOF> Ta
<pdeee> https://isnot.org/certbot-t.jpg
<RAOF> Ah, cool.
<RAOF> So, I'm still hesitant; I'd start a discussion with the rest of the SRU team about that.
<RAOF> But I'm happy to sponsor 0.9.3 into xenial- (and yakkety-) proposed.
<RAOF> We can easily do that in parallel.
<pdeee> okay, nice
<pdeee> our team had concluded that we should work to switch the instructions we provide at https://certbot.eff.org from Xenial packages to pointing folks toward a PPA,
<pdeee> but if the SRU is fairly easy I think we can stick with that
<nacc> mdeslaur: is it just me or did bind9 get a security update in y that it didn't get in z? 1:9.10.3.dfsg.P4-10.1ubuntu1.1
<pdeee> btw, if you want to play with Certbot on a box with no webserver, the following invocations should work:
<pdeee> sudo certbot certonly --standalone # bind to a port to prove control of a domain
<pdeee> sudo certbot certonly --manual # manually prove control of a domain. Can also be run as non-root with some extra flags
<pdeee> You can add -t to the 0.9.3 command line to see how things will look in 0.10.0
<sarnold> pdeee: just out of curiosity, could you amend the eff.org instructions to tell people to pass the -t option?
<pdeee> sarnold, in all cases or just some?
<pdeee> Do you mean, as a way to get that result without changing our code?
<sarnold> pdeee: yeah
<sarnold> like the sru sounds useful, but adding a -t to instructions sounds easier, and most people copy-paste things anyway :)
<pdeee> sarnold, I think our dev team was keen to close all the dialog-related bugs, and remove that extra dependency and complexity from the code
<pdeee> I meant to paste a few of the dialog bugs, but got interrupted:
<sarnold> pdeee: hehe with that list of bugs I can certainly see why :)
<pdeee> https://github.com/certbot/certbot/issues/2025
<pdeee> https://github.com/certbot/certbot/issues/3764
<pdeee> Providing instructions in one place, even the most prominent place, to use -t wouldn't actually get the word out to all of our users
<pdeee> Personally, I would have kept dialog in place and switched the default, but others on the team are more focused on simplicity than I am, and I'm happy for them to overrule me :)
<pdeee> However, I'll say this:
<pdeee> if Ubuntu really wants to keep dialog as the default, we could consider going back to that plan
<pdeee> then Ubuntu could flip the default back to "dialog" on Xenial
<pdeee> I think folks would be unhappy with that stuff staying in the tree, and the complexity of some users having Certbot behave differently than others, but they might live with it.
<pdeee> I think the prevailing view is, "let's get this to the place we want it to be, then call it 1.0.0 -- until then, it's in beta, expect a few [nonbreaking] changes"
<mdeslaur> nacc: I usually wait to sync from debian...but it looks like it's not in debian yet....I'll upload it to Z tomorrow, thanks
<nacc> mdeslaur: np, i was just updating a PPA for a bugfix-test and noticed
<RAOF> pdeee: That's a perfectly sensible approach; we've just already declared it 1.0 downstream by shipping it in 16.04 LTS :)
<jgrimm> thanks nacc!
<pdeee> RAOF, :)
<RAOF> pdeee: So, I guess to move this onto actionable items: who is going to dedicate some time to SRUing 0.9.3?
<pdeee> I can if hlieberman doesn't have cycles
<pdeee> or he and I can work on it together
<pdeee> but presumably we'll also need a Canonical / Ubuntu person
<pdeee> Do you need us to compile a list of High Impact Bugs?
<pdeee> Do you additionally need us to list new features?
<pdeee> (of the sort that may be important enough to warrant inclusion)
<pdeee> Or would a list of fixed bugs be sufficient?
<sarnold> this template ought to guide what'd be most useful https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
<pdeee> sarnold, if I filled that out once for every important bug we've closed, it would be a very long document
<pdeee> will it be okay to provide a narrative, "we fixed these kinds of bugs, <links to lots of examples>",
<RAOF> Are you aware which bugs on launchpad are fixed in 0.9.3?
<pdeee> <These are the steps we took in general to prevent regressions of any sort>
<pdeee> RAOF, a couple, but mostly bugs are filed with our github repo rather than launchpad, even for xenial packages
<pdeee> I can of course make some Launchpad bugs for you, though that's more work :)
<RAOF> pdeee: Not really any need for launchpad bugs; it's nice if you can identify some of them, you don't need to have one per issue fixed.
<smoser> nacc, am i doing something wrong ?
<smoser> $ time ./bin/usd -h >/dev/null
<smoser> real	0m3.248s
<smoser> user	0m0.560s
<smoser> sys	0m0.044s
<nacc> smoser: no, i think there's an issue with one of the constructors
<nacc> smoser: i need to debug it still
<nacc> smoser: i got it functional first :)
<nacc> smoser: i think i need to defer one of the init steps for the importer object
<smoser> and i think i suggest renaming '__main__' to just 'main'. then you can do things like: python3 -m  usd.main (or even add __main__ to the 'usd')
<nacc> smoser: interesting, ok -- i read somethjing that setuptools uses that specific naming
<nacc> smoser: but i trust your knowledge
<smoser> oh. silly. you did do that interestingly.
<smoser> ah. well,
<smoser> python -m usd
<smoser> er... python3 -m usd
<smoser> does work because usd.__main__
<RAOF> pdeee: So, next steps would be to (a) file a launchpad bug along the lines of âplease SRU 0.9.3 to xenial and yakketyâ with the justification and some details of the testing done, (note that xenial has letsencrypt 0.4, and so predates certbot) and (b) prepare the Debian packaging for those SRUs - which will start with a copy from zesty's 0.9.3 packaging, and add a changelog entry mentioning at least the SRU bug and preferably the other LP bugs
<RAOF> fixed.
<smoser> i'd not seen it done like that. but ok.
<nacc> smoser: :)
<nacc> smoser: magic!
<RAOF> pdeee: Oh, and I'm happy to sponsor the upload of the packaging to *-proposed.
<nacc> jgrimm: i submitted a build that should fix heimdal in -proposed, and sent the patch to debian
<pdeee> great okay I'm preparing a template; I will file a bug containing it, and ask hlieberman to do the packaging work
<pdeee> which sounds pretty minimal
<pdeee> and then be back in touch
<smoser> nacc, http://paste.ubuntu.com/23453623/
<smoser> still crashes with ./bin/usd clone cloud-initramfs-tools
<smoser> but through a couple failures :)
<nacc> smoser: http://paste.ubuntu.com/23453650/
<nacc> smoser: with that and passing -l nacc, it works
<nacc> pushed up
<nacc> smoser: fixed the lp prompt case too
<smoser> nacc, AttributeError: module 'os' has no attribute 'getwcd'
<smoser> getcwd not getwcd
<nacc> smoser: fixed and pushed
<smoser> AttributeError: 'int' object has no attribute 'encode'
<smoser> :)
<smoser> i got to run
<nacc> yeah that's the input returning 0 for some reason
<nacc> smoser: i'll fix that tmrw
<smoser> later.
<nacc> smoser: fixed, fwiw, pushed
<nacc> jgrimm: heimdal built successfully, hopefully it migrates now
<cpaelzer> good morning
<pitti> Good morning
<mwhudson> pitti: morning
<pitti> hey mwhudson, how are you?
<mwhudson> pitti: just curious really, but wondering where routes: support in netplan is on your roadmap?
<mwhudson> pitti: good, spent a while learning all about netlink which is fun but doesn't feel very 21st century somehow :)
<pitti> mwhudson: more like the good old assembly days? :-)
<mwhudson> not quite that bad, but definitely more C than nodejs :)
<pitti> mwhudson: routes: is a work item (the last remaining one that concerns netplan itself, in fact)
<pitti> mwhudson: indeed, it's 2016, give us a kernel written in JS already!
<pitti> make the kernel great again!
<pitti> (sorry..)
<mwhudson> heh
<mwhudson> pitti: oh cool (routes: being the last netplan thing missing)
<pitti> mwhudson: so, I haven't thought about some syntax or use cases for this yet -- do you have one?
<mwhudson> pitti: only overriding the default route i think
<pitti> mwhudson: that already exists
<mwhudson> pitti: gateway4/gateway6?
<pitti> mwhudson: i. e. gateway[46]:
<mwhudson> hm, that's only per-interface isn't it?
 * mwhudson doesn't understand networking configuration use cases very well though
<pitti> right, but that's what they conceptually are anyway
<pitti> i. e. there is no "free floating" default route by default, all default routes are attached to some interface (AFAIUI)
<pitti> mwhudson: that might be a bit confusing, let me try again
<pitti> mwhudson: so, an interface can add a route to 0.0.0.0/0 (IOW the "default" route) via a given IP
<mwhudson> no that makes sense i think
<pitti> mwhudson: and all routes have a metric
<pitti> mwhudson: so if the kernel needs to route a packet to an IP which doesn't have a more specific route, it picks the default route amongst the above set with the lowest metric
<mwhudson> pitti: afk for a few mins
<pitti> which is really just the same algorithm as for picking the "most specific" route
<pitti> happyaron: hey, how are you? I was wondering how the NM 1.4 update was coming along?
<happyaron> pitti: hey, guess tommorrow. or by next Mon
<cpaelzer> is there a better way than "uploading to archive and crossign fingers" after writing a new dep8 test to run it on "the other archs"?
<cpaelzer> I wonder if that is the day I could/should use bileto the first time and check if permissions actually work
<rbasak> I feel that pain too. I'm not sure how to use Canonical's porterboxes for dep8 test testing.
<rbasak> (they seem a bit too locked down for that)
<rbasak> mdeslaur: FYI, taking your TIL lock on the squid3 merge.
<cpaelzer> I mean I can technically do ppc64el and s390x due to being lucky and only cross fingers for arm
<cpaelzer> uh wait s390 had issues
<cpaelzer> time to check that again with all updates
<mdeslaur> rbasak: ack, thanks
<cpaelzer> pitti: are you sure on that reject of the dovecot SRU?
<cpaelzer> pitti: 2.2.22-1ubuntu4 never (really) went into the archive nor did 2.2.22-1ubuntu3
<cpaelzer> pitti: last SRU was 1:2.2.22-1ubuntu2.1
<cpaelzer> pitti: Refering to "Rejected by Martin Pitt: needs to rebase against 1:2.2.22-1ubuntu4"
<xnox> cpaelzer, rbasak - go to https://bileto.ubuntu.com/ request new ppa; add source package name; click build that creates ppa; upload into said ppa; and it will run autopkgtests on all arches and report britney results too (for uninstalability)
<xnox> that's what i do.
<xnox> it runs the tests on the same infra as the proposed-migration autopkgtests.
<cpaelzer> xnox: thats what we talked about a few months ago, and sil2100 was so kind to check if it could be set up for non-core dev
<cpaelzer> I guess it is the day then
<cpaelzer> I'll poke #ubuntu-ci-eng with questions if I have some
<xnox> cpaelzer, if you need sponsoring, i'm happy to upload experimental things into bileto ppas =)
<sil2100> Yeah
<xnox> cpaelzer, sil2100 - honestly using bileto ppas for experimental builds is totally fine, even if you do say in description "will be abandonned"
<sil2100> Sure, Bileto PPAs are also for this since we have ephemeral PPAs now, so yeah
<pitti> cpaelzer: hm, they exist in https://launchpad.net/ubuntu/+source/dovecot/1:2.2.22-1ubuntu3 and https://launchpad.net/ubuntu/+source/dovecot/1:2.2.22-1ubuntu4, but I guess that was a very confusing case then
<cpaelzer> pitti: yes, in september we did the 2.1 SRU
<cpaelzer> pitti: if wrong it was wrong there already :-/
<cpaelzer> pitti: can you un-reject the upload or is the case worse and we need to clean up even more?
<pitti> cpaelzer: no, I can generate a real diff manually and accept from rejected
<cpaelzer> pitti: ok, I'll do nothing on this case then; unless you tell me to do so - ok
<cpaelzer> ?
<pitti> cpaelzer: should be all good now; sorry for the trouble
<cpaelzer> pitti: thank you for sorting out, no reason to excuse at all
<cpaelzer> pitti: it is a weird case
<ogra_>  Err:1 http://ports.ubuntu.com/ubuntu-ports xenial/universe armhf libtext-unidecode-perl all 1.27-1
<ogra_>   403  Forbidden [IP: 91.189.88.150 80]
<ogra_> wow
<ogra_> whats that ?
<pitti> ogra_: since Trump it is forbidden to write new software in Perl!
<ogra_> LOL
<dobey> ogra_: it's an issue with the ports server it would seem. i'd say bug IS
<ogra_> well, looks like the Packages file is out of sync with the actual archive content
<ogra_> http://ports.ubuntu.com/ubuntu-ports/pool/universe/libt/libtext-unidecode-perl/
<ogra_> weird
<ogra_> (the files in that dir are from 2005 and 2008)
<ogra_> aha
<ogra_> and now the dir updated
<ogra_> yep ... and it works ... weird
<ogra_> smells racy
<Laney> ogra_: weird that it gives a 403 and not a 404
<Laney> it's not updated here
<pitti> ogra_, Laney: presumably one of the mirrors is out of date, and you just hit that one (or not) at random?
<Laney> I tried from a few boxen
<persia> Is the feed to ports.u.c still managed by ubumirror?  If so, it's (intentionally) racy w.r.t content vs. packages files, but the intended raciness should avoid the situation described above.
<Laney> but us.ports.ubuntu.com works
<persia> That would be mirrored from ports.u.c, rather than from the internal all-arches true master archive.
<Laney> I don't know that ports is even round robin
<Laney> persia: This particular package hasn't changed in $ages
<persia> (unless mirroring is very different than my memory.  I'll stop blathering now, in case it has changed)
<ogra_> Laney, well, it magically started working, pitti might be correct
<Laney> ogra_: It's all guessing isn't it
<ogra_> yep
<Laney> what IP are you getting?
<ogra_> 91.189.88.150 was the one that did not work initially ...
<pitti> same as me
<ogra_> and i get the same when pinging now
<pitti> maybe that's just a load balancer
<ogra_> so it was the same server
<xnox> pitti, i would vote for such policy =)
<Laney> Then one of the backends is broken
<Laney> I'll go ask, since nobody else wants to
<Laney> (being debugged, FYI)
<smoser> pitti, your comment 27 on bug 1636912
<ubottu> bug 1636912 in systemd (Ubuntu Xenial) "systemd-networkd runs too late for cloud-init.service (net)" [High,In progress] https://launchpad.net/bugs/1636912
<smoser> 'drop "Wants=networking.service"' .  What we have there is 'After=networking.service'
<smoser> and i think that is necessary or we wont run after ifup has been done..
<rharper> smoser: we also had Requires=networking.service
<rharper> smoser: IIRC, there's a built in wants for networking.service via /etc/systemd/system/network-online.target
<smoser> right..
<rharper> so, ifupdown will run if installed
<rharper> when means we should be able to just say After for ordering
<smoser> right, but by not Wanting it we dont force it to run otherwise.
<rharper> correct
<smoser> the other thign that Require did (which is why i used it) is it says "It ran and succeeded"
<smoser> After just says "it ran"
<rharper> correct
<pitti> smoser: right, sorry, I meant "Requires=", not "Wants="
<smoser> so thats less than ideal, but maybe ok.
<rharper> but if we have an either networking or networkd;  we'd like to say that either ran and which ever one selected succeeded
<smoser> right. ideally is saying "whatever would configure the network ran and succeeded"
<smoser> but i guess honestly if it didnt succeed then we're kind of sol
<rharper> right
<rharper> well, for network based datasources
<rharper> or if someone wanted networking...
<rharper> it's possible for a device to use cloud-init with nocloud seed and not care about networking (during boot)
<rharper> so ideally we'd somewhat not care in the sense that it only matters truely if the user-data/metadata is over the network  (as in that will fail)
<smoser> rharper, well right. that'd have no networkign, but that would be succeed
<smoser> right  ? an empty /etc/network/interfaces just says "don't do anything".  and that succeeds very quickly.
<smoser> pitti, you have a minute for some questions about cloud-init's systemd jobs generally ?
<pitti> smoser: literally one minute, yes (our meeting starts in 5, currently prepping)
<smoser> you ahve time after ?
<smoser> i'd like hangout if you can
<smoser> some stuff here: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310547
<smoser> but woudl ike to just review all of it.
<pitti> smoser: LGTM, as long as cloud-init-local.service makes no assumptions at all about writable root and mounts?
<pitti> smoser: sorry, not after either, meeting someone for dinner
<smoser> pitti, well, it does assume it can write to /var/lib
<smoser> and /run
<smoser> how should i say that ?
<pitti> smoser: reviewed
<pitti> smoser: /run is always there, so add After=systemd-remount-fs.service and RequiresMountsFor=/var/lib
<pitti> smoser, rharper: http://summit.ubuntu.com/uos-1611/meeting/22716/netplan-introduction-and-next-steps/ â do you want to attend?
<rharper> pitti: yes
<smoser> pitti, sure
<nacc> rbasak: do you have a link to the pad from yesterday? for some reason, i'm disconnected
<rbasak> nacc: http://pad.ubuntu.com/git-workflow-talk
<nacc> rbasak: thanks
<nacc> caribou: i'm working through your import requests, fyi
<nacc> rbasak: --^
<caribou> nacc: thanks!
<nacc> smoser: i might add a default value for the lp username prompt -- at least i find it really annoying to have to type my local username or pass it (i don't need to do this for the importer, e.g.)
<smoser> nacc, how would you add a default ?
<smoser> and you only provide it once.
<smoser> then it stores it.
<nacc> smoser: only if i tell it to :)
<nacc> smoser: same way we do for the importer
<smoser> why dont you answer yes
<nacc> smoser: maybe we shouldn't, i just don't like that clone behaves differently
<smoser> then fixed
<smoser> and its right.
<nacc> smoser: becasue i'm going to delete the tree
<nacc> smoser: i don't care about configuration caching
<smoser> it storees it in your ~/.git
<smoser> ~/.gitconfig
<smoser> you probably dont delete that too often :)
<smoser> doesnt it?
<nacc> oh you're doing --global
<nacc> hrm, ok
<rbasak> nacc: I think launchpadlib has something. When I use other Launchpad API tools that need privilege, they don't prompt me.
<nacc> so we probably have a bug, as i do have local configs in .gitconfig
<nacc> smoser: will investigate
<nacc> rbasak: ack
<nacc> caribou: thank you, btw, you helped me find a bug :)
<nacc> at least not one i didn't introduce in my rewrite :/
<caribou> nacc: always happy to help ;-)
<nacc> rbasak: jgrimm: do you want to stay on the HO?
<jgrimm> nacc, rbasak: i'll defer to you if wanting to start now or need a break
<nacc> jgrimm: ack, we're in the HO now
<smoser> nacc, http://paste.ubuntu.com/23457110/
<smoser> that method is much more standalone , so i made it a staticmethod there. can just as easily move it somewhere more common.
<smoser> and just fyi, you were 'match' with beginning '^'. i'm pretty sure thats redundant.
<nacc> smoser: nice, thanks!
<tdaitx> bdmurray, from where does the UnreportableReason in the error tracker comes from?
<bdmurray> tdaitx: from apport
<tdaitx> bdmurray, right, then my question is from where does apport fetch that information?
<bdmurray> tdaitx: it creates it - what are you seeing?
<tdaitx> bdmurray, just trying to figure out what that field mean on those package-data-downloader errors
<bdmurray> tdaitx: out of date packages
<tdaitx> yeah, but why?
<bdmurray> tdaitx: because they haven't installed all their updates.
<tdaitx> ok, so it's just a usual message fom apport
<bdmurray> tdaitx: wrt apport you could read apport/report.py and data/general-hooks/ubuntu.py
<bdmurray> tdaitx: yes
<tdaitx> bdmurray, anyway, I noticed that /usr/lib/update-notifier/package-data-downloader is also called from update-notifier-common.postinst
<tdaitx> not sure it that one can ever have no stdout/stderr set
<bdmurray> tdaitx: okay, thanks for looking
<nacc> rbasak: ah i think i see what is wrong with kexec-tools -- you did the merge step that the importer is expecting to do, is all
<nacc> smoser: can you send me a MR?
<smoser> nacc, https://code.launchpad.net/~smoser/usd-importer/+git/usd-importer/+merge/310580
<pitti> smoser, rharper: is bug 1636912 also eventually relevant for Debian? I. e. are they following upstream relatively closely and will be aftected by this networkd > dbus.service thing?
<ubottu> bug 1636912 in systemd (Ubuntu Xenial) "systemd-networkd runs too late for cloud-init.service (net)" [High,In progress] https://launchpad.net/bugs/1636912
<pitti> smoser, rharper: (it would actually make things easier if they are -- then removing the After=dbus.service wouldn't be an Ubuntu specific thing)
<rharper> pitti: possibly, not sure if we upload cloud-init to debian, but we do support debian as an os target
<rharper> pitti: that's a netword change, right, so it's certainly a reasonable common change
<smoser> we do not maintain cloud-init in debian
<pitti> they have 0.7.8-1, and https://tracker.debian.org/pkg/cloud-init looks reasonably active
<smoser> but there is cloud-init in debian
<pitti> right, I mean this will eventually go into 0.7.9 or 0.8 or whatever? i. e. "upstream"; or stay in ubuntu?
<smoser> pitti, oh, i'd put it upstream
<pitti> smoser: ack
<smoser> pitti, that is correct for debian too, right ?
<smoser> i think all those systemd files are ...
<smoser> at least hope
<smoser> and even for fedora is the goal
<pitti> smoser: yes; but we'd run into the same networkd After=dbus.service issue in Debian then, so we'd need to patch it out there too (and break UseHostname:)
<LocutusOfBorg> highvoltage, sorry for not looking at the RFS
<LocutusOfBorg> I'll try to look at it tomorrow if nobody beats me
<LocutusOfBorg> I have too many packages to look at, and today I'm fixing llvm stack :/
<nacc> smoser: thanks!
<smoser> pitti, can you fix typo in https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310547
<smoser> what bug is that ?
#ubuntu-devel 2016-11-11
<nacc> rbasak: fyi, i found an interetsing case with `usd merge reconstruct` -- the reconstruct commits (and the ones between old/debian and it) are not reproducible (at least not for the sha). I guess it's obvious, because the committer is the one doing the cherry-pick at the time of the cherry-pick; but do we want to make the tooling workaround  that (retaining the original commit information, e.g.?)
<rbasak> nacc: kexec-tools> ah. It's nice to not have to do that now!
<rbasak> Perhaps less of a problem then?
<rbasak> nacc: not reproducible> I can't think of where that might be an issue, since those commits will not end up in the history that others actually use. Only short-lived branches. Is there any case you can think where that won't happen?
<rbasak> nacc: I don't see any reason to object to them _not_ being made reproducible, but I also don't see why it would be worth the effort
<rbasak> nacc: interesting observation though!
<nacc> rbasak: yeah, the importer will handle it correctly -- it actually produces the same merge as you did, but it doesn't know (currently) how to handle us doing the merge and not it (as it finds a current debian/changelog but no import commit)
<nacc> rbasak: it will spit a warning now
<nacc> *error
<nacc> rbasak: yeah, i'm not sure either, was just thinking about it as i considered two people doing the merge at the same time
<rbasak> My linting doesn't actually check the intermediate reconstruct branches, only the final one I think.
<rbasak> But I think that's OK.
<nacc> rbasak: yeah it doesn't matter, as once we push up to the repository the tagged upload/ it's no longer reconstructed; also that tag is really just a helper
<nacc> cpaelzer: ok, i just pushe a ton of changes up to master for the merge subtool
<nacc> i think that fixes your bug
<pdeee> RAOF, https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1640978
<ubottu> Launchpad bug 1640978 in python-letsencrypt (Ubuntu) "letsencrypt 0.4.1 contains numerous bugs fixed upstream" [Undecided,New]
<pdeee> ^ hlieberman
<rbasak> pdeee: interesting. Do you work for certbot upstream?
<rbasak> RAOF, pdeee: I'd also be happy to help out. Please ping if needed.
<pdeee> rbasak, yes
<rbasak> pdeee: good job with the SRU paperwork there! It might be worth making it really clear exactly what behaviour changes you believe will and won't affect your proposed update to 16.04 - that's particularly important.
<rbasak> I guess that depends a little on the packaging that presumably isn't ready yet? Eg. aliases wrt. letsencrypt vs. certbot, etc.
<pdeee> aliases etc are handled in debian's 0.9.3 packages
<pdeee> since they had the same transition
<pdeee> the only things I could maybe see for Xenial would be:
<pdeee> - a changelog entry pointing at the SRU paperwork
<pdeee> - if people want it, a more prominent dselect question about the renewal cron job
<pdeee> sorry s/dselect/debconf/
<rbasak> From an SRU review perspective, what I most want spelled out the exact list of any behaviour changes you expect Xenial users to receive, and your confirmation that you don't believe that there are any other changes.
<rbasak> Your word as upstream carries a great deal of weight on this.
<rbasak> What you've written is great and sound like it covers most of this already - it's just a clear summary of what the final upload to Xenial will do is what I feel is missing - though of course I know you haven't finalised that yet.
<nacc> rbasak: if you have some time, could you do a `usd clone php7.0; cd php7.0; usd merge tag ubuntu/devel; usd merge reconstruct ubuntu/devel`? I'm getting a source change mismatch between reconstruct and old/ubuntu, but only from pygit2. `git` itself isn't showing me any differences and oddly `git-blame` and `vi` are showing me differnt file contents (a $Id$ substitution)
<rbasak> nacc: note that php7.0 ships (or at least used to ship) a .gitignore file, which messes things up annoyingly. Could that be an issue here?
<rbasak> And those $Id$ style substitutions are pesky too.
<rbasak> Unfortunately git didn't seem to have a global option to ignore .gitignore the last time I looked.
<rbasak> nacc: usage: usd [-h] [import|buildpackage] ...
<nacc> rbasak: pull master
<nacc> rbasak: you're about a day of date :)
<rbasak> Oh I'm sorry. I did pull but I had a detached head.
<nacc> oh there's also a .gitattributes
<nacc> that's what's doing it
<nacc> bah, so frustrating :/
<rbasak> git needs a "I'm external to the project; ignore that stuff" mode :-/
<nacc> yeah
<nacc> i believe this is actaully covered somewhere int he manual -- how to repackage upstreams that use git
<nacc> i will need to look tmrw
<rbasak> Last time I sent a patch to the git project I got bikeshedded :-/
<rbasak> (about a test no less; not even the bugfix)
<nacc> it seems like they should put this in .git/info/attributes in the php7.0 repo
<nacc> rather than in the source dir
<rbasak> That depends on whether they want cloners to automatically inherit all that or not.
<nacc> well they do now by virtue of it being in the path
<rbasak> If they want everyone to have it active, then that's what .gitattributes/.gitignore is for
<nacc> oh you're saying if a user had a separate attributes setting already?
<nacc> hrm
<rbasak> No I mean that if they put it in .git/info/attributes then everyone who clones it needs to set it up separately
<nacc> rbasak: not acc'g to the gitattributes manpage
<nacc> rbasak: git uses that first
<rbasak> I don't think you follow me.
<nacc> i dunno, not a big deal right now
<rbasak> If they want to do a thing project wide, automatically, for everyone who clones, then they can't put that in .git/info/attributes because others won't pick that up when they clone.
<nacc> oh i see what you mean
<nacc> rbasak: i'm not sure how to avoid .gitattributes in an upstream like this, though; istr talking about this a while back, for a case you hit as well
<nacc> rbasak: ah crlf issues, maybe
<nacc> rbasak: bouncycastle?
<nacc> rbasak: at the time, you did a "echo '* -text' > git/info/attributes" I think
<rbasak> nacc: ah yes. That was to override the default IIRC, rather than a .gitattributes file.
<rbasak> nacc: IMHO, git should have options to disable everything from inside .git/. If it doesn't we should see if we can get that in upstream.
<nacc> rbasak: so i think this might just be a bug in `usd merge` -- i think i have a workaround for php at least
<nacc> but it is something we should look into
<rbasak> When I did it by hand I ended up committing a removal of .gitattributes and .gitignore from the tree. Painful.
<nacc> rbasak: ack, not a great solution :)
<nacc> rbasak: ok, pushed something up that lets me proceed, at least
<nacc> rbasak: i'm off the evening, thanks!
<pdeee> rbasak, I replied on the ticket
<pdeee> in short, we don't believe there should be any workflows that have changed
<pdeee> there are lots of new flags that and options that are supported
<cpaelzer> nacc: thanks for the fixes, I'll let you know next time I hit it
<pitti> Good morning
<cpaelzer> good morning pitti
<highvoltage> LocutusOfBorg: no problem at all!
<pitti> rbasak: iptraf got removed in Debian in favor of iptraf-ng (Debian bug #842355); iptraf is seeded on ubuntu-server daily; do we want to follow suit?
<ubottu> Debian bug 842355 in ftp.debian.org "RM: iptraf -- ROM; obsoleted by iptraf-ng" [Normal,Open] http://bugs.debian.org/842355
<rbasak> pdeee: thanks!
<rbasak> kirkland, jgrimm: opinion on pitti's question above please?
<rbasak> Sounds like a yes to me?
<LocutusOfBorg> highvoltage, kpmcore sponsored
<LocutusOfBorg> but the symbols are really sad
<doko> xnox: what is your plan with openssl 1.1?
<xnox> doko, stay on 1.0 until debian transitions 500 more packages.
<xnox> doko, then revisit with mdslaur.
<xnox> doko, at the moment he does not want to maintain cves for two series. or worse two series in a single release.
<cjwatson> openssh ain't moving off 1.0 for a while yet
<cjwatson> to name but one
<xnox> somehow i expect it to drag on forever.
<Son_Goku> xnox: have you seen this? https://github.com/patch-exchange/openssl-1.1-transition
<cjwatson> and yes, I'm aware of the patch sent upstream for openssh, but I consider it irresponsible to apply a ~4000 patch with lots of delicate crypto code that isn't yet upstream
<Son_Goku> Fedora and OpenMandriva guys are collaborating on the openssl-1.1 transition, and maybe you guys could help pitch in for it
<cjwatson> wouldn't surprise me if a similar thing applied to some other packages
<cjwatson> s/~4000 patch/~4000-line patch/
<xnox> Son_Goku, my advice is for those who are interested in openssl 1.1 contribute to debian, and similar efforts in porting. Longer term I do see it as a necessory transition, but in my mind that's 18.04 LTS not necessarily 17.04
<xnox> no objections on the intentions; just the timing; and how the timing makes sense for ubuntu.
<Son_Goku> xnox, I don't disagree, but I figured I'd make you aware of the patch-exchange for it
<Son_Goku> you can let your friends in Debian know about it, so that we don't keep duplicating work over and over
<rbasak> Son_Goku: https://github.com/patch-exchange looks interesting. Someone should mention this on the cross-distro list.
<Son_Goku> what cross-distro list?
<rbasak> (what is the cross-distro list, you ask?)
<rbasak> :-)
<rbasak> I can make the same point about the patch-exchange :-P
<rbasak> https://lists.linaro.org/mailman/listinfo/cross-distro
<Son_Goku> wait, isn't that just for ARM things?
<rbasak> I don't believe so.
<rbasak> It just started up because there was a need in that area.
 * Son_Goku shrugs
<Son_Goku> I've seen that list before, but I've only seen ARM things talked about there
<pitti> realistically, such a list isn't going to happen or be useful
<pitti> IMHO, for any such porting there should be an upstream bug/issue/whatever where people interested in that project (like distro maintainers) are subscribed
<pitti> that at least makes it N:1 instead of N:M (which is too intangible)
<rbasak> pitti: sure, but in addition to that, it's useful to have a general forum for wider issues. I wouldn't expect individual patches to be discussed on such a list, but wide reaching issues would be relevant.
<Son_Goku> at least in the case of patches, I don't know how it is between Debian and other distros, but at least in my experience in Fedora, Mageia, and openSUSE, we do a lot of patch sharing
<Son_Goku> so it made sense to set up the patch-exchange
<rbasak> Indeed. I wasn't aware of a forum before, but it is quite common for Debian/Ubuntu to look at the other distros and grab their patches. I assumed they did the same with us. And patch-exchange certainly does look useful.
<rbasak> But someone needs to announce them to the distros!
<rbasak> Or announce _it_, at least.
<Son_Goku> rbasak, half the time, I have no idea where to find patches for stuff in Debian
<rbasak> sources.debian.net.
<rbasak> For modern packages, always inside debian/patches.
<pitti> https://patches.ubuntu.com/ too
<Son_Goku> the crappy part is when it's 2.0 or 1.0 split format
<cjwatson> Son_Goku: Debian developers manage to work it out for other distros :)
<Son_Goku> which means diff.gz
<cjwatson> Son_Goku: that's increasingly rare nowadays
<Son_Goku> Mir is released that way, for example
<cjwatson> Sure, you can always come up with examples
<cjwatson> But statistically
<Son_Goku> it's less common now, thankfully
<Son_Goku> but it still pops up enough to be annoying
<rbasak> You should file a bug against mir and ask them to move to 3.0 (quilt). I'm surprised about that one.
<Son_Goku> 1.0/3.0 native and 3.0 quilt formats are my favorite
<Son_Goku> everything in the middle sucks
<cjwatson> https://upsilon.cc/~zack/stuff/dpkg-v3/   graph seems to be broken but it has the numbers at least
<cjwatson> that's for Debian rather than Ubuntu
<cjwatson> as for mir, they don't have any patches at the packaging level anyway, so while it would be nice if they used 3.0 (quilt) on general principles, it wouldn't make any difference at all to finding patches
<cjwatson> the way it's released very nearly enforces landing upstream first
<Son_Goku> rbasak: filed: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1641121
<ubottu> Launchpad bug 1641121 in mir (Ubuntu) "Switch packaging to "3.0 (quilt)"" [Undecided,New]
<Son_Goku> cjwatson, yes, but it's the principle of the thing
<Son_Goku> and how the heck am I supposed to know until I do dpkg-source foo?
<rbasak> Son_Goku: thanks. I'd add that the point is to make it simple for people to easily confirm there aren't any patches, which is just as useful as being able to find any.
<rbasak> Right :)
<cjwatson> I guess it doesn't seem particularly harder to me than having to track down and extract a source RPM ...
<Son_Goku> cjwatson, you typically don't need to go to that level
<cjwatson> (sure, nowadays it's usually in a git repository, but wasn't historically the case and I'm reaching for an apples-to-apples comparison)
<Son_Goku> because the sources are in a central VCS typically
<Son_Goku> right
<rbasak> Son_Goku: you might be interested in http://summit.ubuntu.com/uos-1611/meeting/22710/git-based-merge-workflow/ BTW. I hope that soon we'll have Ubuntu packages clonable from git.
<Son_Goku> rbasak, zyga actually is managing snap-confine using a similar workflow to what we do in Fedora
<Son_Goku> I think it's probably the sanest approach for managing packaging
<Son_Goku> rbasak: https://git.launchpad.net/snap-confine
<cjwatson> ugh, non-full-source
<cjwatson> horrible
<Son_Goku> cjwatson, it is designed to make it harder to do random monkey-patching
<Son_Goku> which is something that I've had the misfortune of seeing from Debian packages before
<cjwatson> I am an absolute unashamed partisan of full-source packaging repositories
<cjwatson> you won't persuade me otherwise, it's a firm opinion established over 15 years
 * Son_Goku shrugs
<Son_Goku> I've done both workflows myself
<pitti> bzr-buildpackage actually made debian/ only trees not suck
<Son_Goku> doesn't git-buildpackage do the same thing?
<Son_Goku> for git stuff
<pitti> I actually quite enjoyed it, it was clean and super-fast as it doesn't have to drag along the huge upstream portion
<Son_Goku> pitti: \o/
<pitti> maybe it can, but I've always seen it full-source
<pitti> and I'm using it myself that way -- the usual triumvirate of upstream, pristine-tar, master
<cjwatson> ditto except with git-dpm
<Son_Goku> I personally prefer having the original sources stored as a tarball or archived in a lookaside system and maintaining the packaging sources in VCS
<Son_Goku> to me, it enforces the split between the software and the packaging better
<cjwatson> I find it enormously useful to be able to do consolidated 'git blame' across both
<cjwatson> which doesn't work if you "enforce the split"
 * pitti waves good bye and bids a nice weekend to everyone; gotta leave early today
<Son_Goku> cjwatson, sure, and that is an advantage
<Son_Goku> until it isn't
<rbasak> I think "enforcing the split" is more appropriate as a cultural thing at review/upload time. No need to compromise our tooling for it.
<cjwatson> I've not hit the "until"
<Son_Goku> when you can't tell whether it's an upstream or downstream change, it's a problem
<cjwatson> it's not that I can't tell
<Son_Goku> or when you refer to commit hashes that don't exist upstream
<cjwatson> it's that I don't care when I'm in the middle of investigating a bug
<cjwatson> when I'm preparing a fix, sure, I'll work out where the appropriate target is
<cjwatson> but that comes later, and I don't want my convenience compromised
 * Son_Goku shrugs
<rbasak> Son_Goku: why can't you tell if it's an upstream or downstream change? And why do you accidentally refer upstream to downstream commit hashes?
<Son_Goku> rbasak, I've seen Debian packages have downstream patches applied to master and referred to in changes as upstream commits
<rbasak> Certainly I can see how this could be a problem with 1.0 format. But not 3.0.
<Son_Goku> and because they never made it upstream, I have no idea where they are
<rbasak> Applied to master where? In debian/patches? Or via git-dpm?
<Son_Goku> and also, since Debian doesn't enforce a VCS for packaging, tracing it is hard, too
<rbasak> We have dep3 headers to track origin and status.
<Son_Goku> rbasak: applied to the master in the deb-git structure
<Son_Goku> and not as a debian/patch file
<rbasak> If we're talking about best practice of git, gbp, git-dpm and 3.0 (quilt) packages, you can't invoke "but 1.0 and no VCS". That isn't part of the debate.
<cjwatson> I really don't think that "some people have screwed things up" is a reason for making the tools harder to use
<Son_Goku> eh, no, this is with 3.0 packages
<Son_Goku> with a VCS
<Son_Goku> but you're right, the not enforcing VCS thing is irrelevant in this case
<rbasak> Son_Goku: if it's not a debian/patch file, dpkg-source will refuse on a 3.0 quilt package. That's just an error and an unbuildable package. Not a workflow difference that encourages bad practice. It can't encourage bad practice, because it doesn't work.
<rbasak> dholbach: o/ would you mind setting up a UOS MySQL/MariaDB session for me please? I asked jgrimm but just realised he's out today (US holiday).
<rbasak> dholbach: I have a slot preference since we have some external employees attending. I'll just work it out from the RSVPs.
<rbasak> dholbach: can we have it at 1500-1600 UTC on Tuesday please? That seems to fit the key attendees the best.
<dholbach> hey rbasak, does http://summit.ubuntu.com/uos-1611/propose_meeting/ work for you?
<rbasak> Oh, I didn't know about that. Sorry!
 * rbasak uses it
<dholbach> you might have to go to  http://summit.ubuntu.com/uos-1611/registration  before it
<dholbach> no worries :)
<rbasak> dholbach: done, but I don't see a scheduling option
<dholbach> let me take a look
<dholbach> rbasak, thanks, scheduled
<dholbach> http://summit.ubuntu.com/uos-1611/2016-11-15/
<rbasak> dholbach: thank you!
<dholbach> anytime
<jgrimm> thanks rbasak
<kirkland> rbasak: I have no opinion on that
<rbasak> kirkland: thanks. We'll JFDI then I think.
<rbasak> Though I think this may need an MIR :-/
<rbasak> No, it looks like it's a fork.
<rbasak> pitti: iptraf-ng> ^ are you happy to proceed without a MIR?
<rbasak> pitti: swapped in the seed, and subscribed ~ubuntu-server. Please override.
<doko> rbasak, jgrimm: please could you have a look at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg ? freeradius tries to pull collectd into MAIN
<nacc> doko: might be late for rbasak and jgrimm is on holiday; looking
<nacc> doko: it seems freeradius has grown a b-d on libcollectdclient-dev
<nacc> doko: looks like we'd need a delta to change our build?
<nacc> doko: yeah, i think that's what is driving freeradius-utils to dep on libcollectdclient1
<nacc> doko: working on a merge now, i'll take a look after this
<doko> nacc: ta
<dmj_s76> What kind of updates can we expect for Unity in the next LTS point release?
<dmj_s76> Will there be an updated release or just cherry picks/backports?
#ubuntu-devel 2016-11-12
<nacc> smoser: while trying to import freeradius `gbp import-orig` died on seeing '-- Arran Cudbard-Bell <a.cudbardb@freeradius.org>  Thu, 30 April 2014 11:35:00 +0100
<nacc> as dpkg-parsechangelog requires Apr not APril
<nacc> i think it's unfortuante (and sort of unclear to me) why gbp uses debian/changelog on an upstream to determine the version
<nacc> oh i see
<nacc> it uses if it can find it, but doesn't properly ahndle parse errors
<nacc> smoser: i might make pristine-tar failure non-fatal
<nacc> doko: sigh, it seems like there is not a measn to disable collectd in freeradius 3.x
<nacc> rbasak: jgrimm --^
<nacc> doko: ah interesting, just dropping the build-dep, though, does seem to work
<doko> LocutusOfBorg: are you explicitly syncing haskell packages?
<LocutusOfBorg> doko, yes, in the correct order
<LocutusOfBorg> see -release discussion a few hours ago
<mapreri> does launchpad understands and make use of alternate build-dependencies, as opposed to wanna-build?
<LocutusOfBorg> I don't think so, but not sure
<cjwatson> mapreri: yes - specifically it uses sbuild --resolve-alternatives
<cjwatson> LocutusOfBorg: ^-
<mapreri> cjwatson: I see, thank you.
<ilmaisin> is trying to getting 16.04 working right somehow considered a lost cause now?
<ilmaisin> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1598300
<ubottu> Launchpad bug 1598300 in cups (Ubuntu Xenial) "cups hang after a while" [Undecided,Confirmed]
<ilmaisin> quite serious bugs are ignored for months
<ilmaisin> it's hard to imagine such important bug being ignored like this in any other mainstream distro, of course this happens often on many less important packages, but on ubuntu this happens on core components
<ilmaisin> as of now it's hard to recommend ubuntu or at least 16.04 to "normal" people who would rather use their computers instead of working around ridiculous bugs
<dobey> clearly the wey to get bugs fixed is troll on irc
<dobey> and the bug hardly seems to be "ignored for months"
<ilmaisin> dobey: ubuntu's "wey" seems to be name-calling and and not doing any qa
<gQuigs> mhall119: hi there, would it be possible to have this event moved earlier on Wednesday? - http://summit.ubuntu.com/uos-1611/meeting/22714/architecture-discussions/
#ubuntu-devel 2016-11-13
<hjd> Anyone familiar with ubiquity who might know where the list of cities reside? See bug 1641327
<ubottu> bug 1641327 in ubiquity (Ubuntu) "There is a typo in the name of the city Montreal (Canada) in ubiquity, the Ubuntu installer" [Undecided,Confirmed] https://launchpad.net/bugs/1641327
<mdeslaur> xnox: I suspect you know the answer to that ^
#ubuntu-devel 2017-11-06
<mwhudson> er what http://launchpadlibrarian.net/319496467/zope.security_4.0.3-1ubuntu2_4.0.3-1ubuntu3.diff.gz
<xnox> tsimonq2, doko - hey, I wanted to demo anthy merge as a sample one on a google on air as a demo for +1 maintainance. but since it's now blocking qt transition, i guess i should just keep a copy of the merge, and just upload it.
<xnox> bah &> #ubuntu-release
<doko> LocutusOfBorg: your merge comment for baloo seems to be outdated
<LocutusOfBorg> doko, I didn't write that comment, maybe tsimonq2 or somebody else did
 * tsimonq2 bounces to acheronuk
<acheronuk> tsimonq2: what merge?
<acheronuk> oh, on mergomatic. that baloo is the old KDE4 one, and should be killed off/removed this cycle. I don't care what happens to it
<LocutusOfBorg> acheronuk, mind filing a bug report?
<popey> xnox: you pinged me last week about GCI. Want to detail the tasks you were looking to add?
<xnox> popey, hi, almost end of day soon. I was thinking these tasks: 1) remove upstart user session jobs from a package 2) remove upstart system job from a package, with correct maintainer scripts 3) write a systemd unit for a package which only has init.d script and/or upstart job
<popey> Oooh! Those are good!
<xnox> popey, the tasks are small, and easy to review/integrade, but do cover a lot of ground.
<popey> I like. Would you be willing to mentor for them?
<xnox> popey, i'm happy to mentor these tasks, and sponsor them into ubuntu (and debian)
<popey> You are amazing. Thank you.
<xnox> popey, do i need to provide qty counts for these tasks?
<popey> Not right now. We can discuss the details tomorrow if you like?
<xnox> popey, ack.
<xnox> popey, it is hte right level of size and/or difficulty?
<popey> yes, totally
<xnox> popey, is it the right level of size and/or difficulty?
<xnox> ack
<popey> we need lots of tasks across lots of difficulty levels
<popey> some will be relatively simple, others much longer
<popey> the simple ones are great to get people started with the tools
<xnox> popey, the remove user session job should be trivial; system job a bit harder, as one needs a correct debian/pkg.maintscript line; the writting systemd unit a bit creative, can be trivial just a debian/foo.service or can be quite hard.
<popey> Gotcha.
<geofft> nacc: hey, are you around? want to sponsor LP #1725110 for artful now that it's in bionic?
<ubottu> Launchpad bug 1725110 in config-package-dev (Ubuntu Artful) "config-package-dev 5.2 broke transforms" [Undecided,Confirmed] https://launchpad.net/bugs/1725110
<nacc> geofft: oh yes, I'm sorry!
<nacc> geofft: i'll get it done today
<nacc> geofft: been distracted with other work,
<geofft> thanks!
<andreas> hi, could someone please accept my zesty nomination for https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1565060 ?
<andreas> thanks
<ubottu> Launchpad bug 1565060 in bind9 (Ubuntu Yakkety) "defaults file is ignored" [Undecided,Confirmed]
<sarnold> andreas: done
<andreas> sarnold: thanks
<sil2100> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
<nacc> geofft: still around?
<nacc> are you ok if i sponsor the config-package-dev_5.2ubuntu0.1.debdiff? I'm a lot more comfortable with a one-line change SRU than a minor version SRU.
<nacc> geofft: --^ sorry
<geofft> yeah, that's fine with me
<nacc> geofft: thanks, i'll prep that nnow
<geofft> it's mostly up to you folks whether you feel more comfortable with a tinier diff, or a larger diff that adds tests, I'm pretty indifferent :)
<nacc> geofft: done :)
<geofft> nacc: thank you!
<nacc> geofft: yw, sorry again for the delay
#ubuntu-devel 2017-11-07
<doko> seb128, Laney, didrocks: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg fonts-smc was split. Please could you review the licenses and subscribe desktop-bugs to the split packages?
<andreas> sil2100: hi, the trusty version of ubuntu-advantage-tools failed to build: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1719671/comments/56
<ubottu> Launchpad bug 1719671 in ubuntu-advantage-tools (Ubuntu Artful) "[SRU] include recent version containing fips and livepatch" [Medium,Fix committed]
<andreas> is it because of universe?
<sil2100> andreas: hey, yeah, for a main package an universe package won't really be visible
<sil2100> I mean, well
<andreas> all ppa builds I did before didn't show this problem
<andreas> even our daily build ppa
<andreas> and how did the other packages build? The ua-tools ones that are in proposed for x, z and a?
<sil2100> andreas: I guess I need to see first what's happening before I start talking
<sil2100> eh
<andreas> :)
<sil2100> Anyway, I'll take a look at this in some moments
<andreas> thanks
<slashd> sil2100, andreas seems like universe hasn't been enable in trusty but xenial yes --> http://pastebin.ubuntu.com/25910954/
<sil2100> Anyway, clearly I made a mistake and didn't take notice that u-a-t is actually a main package
<cjwatson> that changed in xenial, but trusty uses the old model
<cjwatson> right
<cjwatson> (sorry, I was a little further back in scrollback without noticing)
<andreas> these build deps are only used for tests at buildtime, not at runtime
<andreas> does that help?
<cjwatson> irrelevant
<cjwatson> >>> lp.load('/ubuntu/trusty').strict_supported_component_dependencies
<cjwatson> True
<cjwatson> >>> lp.load('/ubuntu/xenial').strict_supported_component_dependencies
<cjwatson> False
<andreas> I mean, in terms of policy: a main package having build-deps from universe
<cjwatson> we made the policy more liberal in xenial, but for trusty it does not help
<andreas> then let's reject that trusty sru
<cjwatson> you could probably just disable those tests for trusty
<andreas> yeah, would that be acceptable from the sru point of view?
<andreas> we can show them in the daily build ppa
<sil2100> andreas: I told you last time it was - if we can't run the tests on a given platform then I'm generally good to skip
<sil2100> It's just that if a series can run the tests then they shouldn't be disabled
<sil2100> slashd: could you re-upload u-a-t to trusty with the tests disabled and test deps removed?
<slashd> sil2100, sure can take care of it
<sil2100> slashd: thanks
<slashd> sil2100, thanks to you
<LargePrime> does anyone know if https://launchpad.net/~network-manager has a #irc
<nacc> !alis | LargePrime
<ubottu> LargePrime: Alis is an IRC service to help you find channels. For help on using it, see "/msg Alis help list" or ask in #freenode. Example usage: "/msg Alis list http"
<cyphermox> LargePrime: #nm
<LargePrime> thanks nacc cyphermox
<nacc> LargePrime: yw
<slangasek> stgraber, infinity, kees, mdeslaur: TB 15 minute warning
<mdeslaur> ack
<bdmurray> slangasek: release upgrade failure due to having apt and apt-transport-https:i386 installed. That seems crazy right?
<slangasek> haha
<slangasek> bdmurray: yes, that's a crazy state.  maybe it's our bug that the system got in that state to begin with, but the failure to upgrade from it is not a bug
<NewGnuGuy> What is the process for moving a package from multiverse to universe if the latest version is fully freely licensed? Asking specifically about the redeclipse package which is licensed under a combination of zlib and CC-BY-SA and which is in the main repository in Debian.
<jbicha> NewGnuGuy: file a bug and subscribe the ubuntu-archive team
<NewGnuGuy> Which bug tracker should I file under?
<jbicha> you can run   ubuntu-bug redeclipse
<jbicha> or https://launchpad.net/ubuntu/+source/redeclipse/+filebug
<ekristen> I'm trying to compile a custom version of python for ubuntu, and I've basically used the .dsc to get all the patches etc, and then dropped in the customizations I need to make, when I compile though the binary behaves differently, the stock python interpretter searches for shared objects with suffixing everything with x86_64-linux-gnu
<ekristen> while my custom binary does not, and I am unable to figure out how to make my binary search for shared objects the same way
<mwhudson> are the autopkgtest queues actually going down at all?
<xnox> mwhudson, yes as fast as fed normalising QE balance sheet.
<xnox> mwhudson, it was 14k now it's like 13.9k and things are moving, it's just new things keep being added.
<xnox> too.
<nacc> ekristen: how are you compilinng?
<ekristen> nacc: I was using dget -u to pull down everything, then I modified the files necessary, then ran dpkg-buildpackage, then tested the resulting binary
<ekristen> nacc: it compiles with what I need, it just doesn't search shared objects teh same way. I tried also to compile directly from source from python too, with the same behavior
<ekristen> I'm sure it's something simple, a small patch or configure option that tells python to look for shared objects in a few different ways, but I cannot seem to figure out where that is setup.
<nacc> ekristen: the binary or the .deb?
<ekristen> nacc: ultimately I'm trying to compile the python interpretter with some custom changes, and install it on ubuntu, ideally I wanted to be able to create a .deb package that contains the binary as well. For my changes to work I've passed the disable-shared, and added my library references to LDFLAGS and CFLAGS, I've tried compiling the binary with and without dpkg-buildpackage.
<ekristen> It makes the .deb file and the python interpreter with teh changes I need, however when I go to import a module like `gi` for example
<ekristen> my custom interpreter looks for _gi.so and that's it
<nacc> ekristen: i'm asking if you tested the binary (e.g. ./...python) or the binanry package (the .deb)
<ekristen> however ubuntu's 2.7 python interpetter looks for _gi.so and _gi.x86_64-linux-gnu.so
<ekristen> nacc: both
<ekristen> I've tested both
<nacc> ekristen: i'm curious what changes you are doing?
<mwhudson> xnox: yeah i know things are being processed, it's just the rate of that vs the rate of things being added that i wasn't sure of
<xnox> mwhudson, we are one cloud down.
<mwhudson> still?
<infinity> No.
<xnox> infinity, it keeps deing taking out the lcy builders for 6 hounts.
<xnox> infinity, so after 28 jobs, we are one cloud down for 5 hours.
<infinity> xnox: They're being reset more often than that.
<xnox> then they come back.
<ekristen> nacc: hard to explain, some legacy stuff inside my company for a python gtk app we have
<infinity> xnox: You're operating on old info.
<nacc> ekristen: ok, i'm looking at hte source myself to see
<infinity> (Yes, lcy isn't in perfect state, but it's not as dire as that)
<xnox> infinity, i'm going by the info, from someone with autopkgtest data, from about two hours ago.
<xnox> infinity, there is a problem with lcy when booing bionic guests.
<xnox> (all good with xenial guests)
<infinity> 11:00 < Laney> nah, I'll make the reset job run hourly so we limp along a bit
<infinity> xnox: Trust me, I'm aware of all of this.
<xnox> infinity, ok.
<infinity> xnox: They're resetting more often than every 6h, as I said.
<xnox> slangasek, ^^^
<xnox> infinity, i've been told fake news again then!
<infinity> xnox: Not fake, just old.
<infinity> xnox: Just irksome when I tell you that it's old news, you keep arguing. :P
<ekristen> nacc: thanks, any help would be greatly appreciated
<nacc> ekristen: i guess my first attempt would be to use a PPA or a good build environment (e.g., sbuild, clean LXD) and see if you can rebuild the existing srcpkg with the same beahvior?
<slangasek> xnox: it was not fake news when I told you
<blahdeblah_> cpaelzer: When you're around, would you have a few minutes to talk about the solutions you investigated when fixing https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1620407 ?
<ubottu> Launchpad bug 1620407 in libvirt (Ubuntu Xenial) "vm startup broken when interface definition has script tag" [Medium,Fix released]
#ubuntu-devel 2017-11-08
<cpaelzer> blahdeblah: I'm here now
<cpaelzer> blahdeblah: are you still around?
<blahdeblah> cpaelzer: sure am
<cpaelzer> you wanted to talk about script tag in libvirt xml?
<blahdeblah> More about the things you discovered in the process of fixing that.  You said you considered a backport of a larger feature from upstream?
<cpaelzer> blahdeblah: yeah but we dropped that - anybody really needing it can/shall use newer libvirt - the regression risk was too high
<blahdeblah> which seemed to be https://libvirt.org/git/?p=libvirt.git;a=commit;h=9c17d665fdc5f0ab74500a14c30627014c11b2c0
<cpaelzer> yeah that was it
<blahdeblah> So it seems that under libvirt 1.x using interfaces of type ethernet are pretty much not recommended
 * blahdeblah rummages for reference
<cpaelzer> IIRC it was not recommended for a long time, waren't there some needs to elevate permissions to use it
<blahdeblah> yeah - e.g. RH discourage its use altogether: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/virtualization_host_configuration_and_guest_installation_guide/app_generic_ethernet
<cpaelzer> yeah there are more refs
<cpaelzer> https://fedoraproject.org/wiki/How_to_debug_Virtualization_problems?rd=Tools/Virtualization/BugReporting#Errors_using_.3Cinterface_type.3D.27ethernet.27.2F.3E
<blahdeblah> And on xenial, even if you implement those 4 settings, it still doesn't work because the AppArmor profile blocks it. :-)
<blahdeblah> cpaelzer: So that's confirmed that I understood what you said in that bug correctly, here comes the question:
<blahdeblah> Is there any safe way to use libvirt with generic ethernet on xenial?
<cpaelzer> it was used heavily at earlier times
<blahdeblah> yeah - I found another bug saying on precise & trusty it worked
<blahdeblah> (presumably because people just ignored the risks of the elevated privilege)
<cpaelzer> it was changed who executes the script (also for security) - but in the past just dropping security was more common than today
<cpaelzer> yeah just what you wrote in your second msg
<blahdeblah> cpaelzer: So is there any safe, sensible way to use this in xenial, or do I need to upgrade to zesty or later?
<cpaelzer> blahdeblah: well, the TL;DR is - back in hat time qemu was executing the script - so to do most of the work (setup a vnic) it needs a set of permissions you usually take away for security reasons
<cpaelzer> blahdeblah: if you consider not dropping capabiliteis and running it as root unsafe (likely) then there would be no safe way that comes to my mind immediately
<blahdeblah> The whole point of this is to run some custom setup on the interface, so my thought was to just use an unprivileged process to send the right info to something running as root.
<cpaelzer> blahdeblah: in the bug you referred the reporter had I quote "we do have our own infrastructure installed to overcome these restrictions. One such measure is having a daemon running as root that does the actual interface creation, triggered by the interface setup script."
<cpaelzer> blahdeblah: if you have something like that, then yes it can be made safer
<cpaelzer> blahdeblah: your thought sounds very similar to what they had in place
<blahdeblah> Probably because I read their comment in the bug. :-)
<cpaelzer> hehe
<blahdeblah> cpaelzer: So back to the fix for that bug: it gives the impression that the fix is already included in the current xenial packages, and all we need to do is specify a different setup script and it should be possible to make that - is that correct?
<blahdeblah> *make that work
<cpaelzer> yes
<cpaelzer> it no more does some prechecks which were broken (that was the bug)
<cpaelzer> so you can reference to your script of choice, that is called in the context of qemu and qemu's user
<cpaelzer> if you can make that script work you are good
<cpaelzer> in later versions libvirt will call the script before qemu (higher permissions)
<blahdeblah> Because I tried that and I still got the error "could not open /dev/net/tun: Operation not permitted"
<cpaelzer> there are some of the caps which still ahve to be lifted I think
<cpaelzer> just a sec
<cpaelzer> blahdeblah: essentially depending on how much your script already does you need a asubset of https://docs-old.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Virtualization_Deployment_and_Administration_Guide/App_Generic_Ethernet.html
<cpaelzer> likely the cgroup_device_acl thing
<cpaelzer> that has no tap/tun by default
<blahdeblah> I tried that on its own without success
<cpaelzer> hmm, I thought back then that was it for me - any apparmor denials or other ususal suspects left in the picture?
<blahdeblah> not that I can see: https://pastebin.canonical.com/202632/
<cpaelzer> let me cross check that for a few minutes, sometimes memory is better when doing than when talking about it
<blahdeblah> cpaelzer: Don't spend a lot of time; this isn't a critical thing - just me trying to get my preferred network topology created.
<cpaelzer> ok, but my personal rule of thumb would then be "do not try to base your preferred thing on soemhing deprecated" :-)
<cpaelzer> I'll let you know if I see soemthing you can try in addtion to what you did
<blahdeblah> cpaelzer: Is generic ethernet actually deprecated as a libvirt interface?  Because that would definitely put a damper on my preferred topology.
<cpaelzer> Read the section "investigation" on https://docs-old.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Virtualization_Deployment_and_Administration_Guide/App_Generic_Ethernet.html - that pretty much covers my known state of it
<blahdeblah> OK - thanks.  I'm grateful for the time you've already spent.
<cpaelzer> blahdeblah: ok I have what you need
<cpaelzer> blahdeblah: you have to apply all I sent you in the fredora link plus the following two for apparmor
<cpaelzer> in /etc/apparmor.d/abstractions/libvirt-qemu
<cpaelzer> capability net_admin,
<cpaelzer>   /etc/qemu-ifup rmix,
<cpaelzer> the latter is your script
<blahdeblah> cpaelzer: Already?  Wow. :-)
<cpaelzer> of course that is far from save :-)
<cpaelzer> leaving the case now, have fun
<blahdeblah> cpaelzer: Yeah - so given how unsafe it is, I think I'll upgrade the host and try with libvirt 2.x
<blahdeblah> cpaelzer: Much appreciated
<doko> mitya57: could you have  look at https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.9.2+dfsg-2build1/+build/13692836 ?
<mitya57> doko, ok will look
<doko> ta
<Laney> hmm, I thought I saw a way to boot a (nova) cloud instance with a kernel on the local system but I can't find that now
<Laney> did I make that up?
<doko> mitya57: and same for https://launchpadlibrarian.net/344935458/buildlog_ubuntu-bionic-amd64.kdb_3.0.2-1build2_BUILDING.txt.gz  (I was pointing a the new cmake, but maybe it's qt related as well)
<mitya57> doko: it's new Qt, some *.cmake files were moved from qttools5-dev-tools to qttools5-dev, needs a new B-D.
<mitya57> I will likely fix both in Debian and then sync.
<doko> mitya57: note that debian still has icu 57
<mitya57> Should that make any difference?
<doko> I hope not ...
<doko> Laney, seb128: is TheMuso still looking at sound issues?
<doko> https://bugs.launchpad.net/cairo-dock-plug-ins/+bug/1730947
<ubottu> Launchpad bug 1730947 in cairo-dock-plug-ins (Ubuntu) "package fails to build with glibc-2.26" [High,Confirmed]
<doko> infinity: ^^^
<jbicha> doko: no, duflu works on pulseaudio though
<smoser> hey all. anyone know of a way to "wait until system is booted".
<smoser> sh -c 'while :; do s=$(systemctl is-system-running); r=$?; [ "$s" = "initializing" -o "$s" = "starting" ] || break; sleep .2; done; read up idle < /proc/uptime; echo "$r $s $up";
<smoser> that works, but i figure theres probably holes in it and i'd love something that didnt poll
<smoser> xnox ? any ideas ?
<doko> Laney: do you see slow setups of autopkg tests environments on lyc-* auto testers?
<xnox> smoser, what do you want to do, when things finish booting?
<xnox> smoser, you can create an idle unit that kicks in after everything is odne
<smoser> stuff
<rharper> smoser: like you want to listen to sd_notify bus
<rharper> for an "i'm done booting event"
<smoser> the reason for my asking today, is that i often write:
<smoser>  lxc launch ubuntu-daily:xenial x1
<Laney> doko: haven't noticed it being slower than lgw01 but I've not exactly been looking
<smoser>  sleep 10 ; # wait for the system to boot
<smoser>  lxc exec x1 -- do-some-thing-useful
<Laney> are you talking about instance startup?
<Laney> like time-to-ssh?
<doko> Laney: https://portal.admin.canonical.com/107182
<xnox> smoser, with lxc1 there was http://man7.org/linux/man-pages/man1/lxc-wait.1.html which blocks until instance is booted.
<smoser> i figure i'm not the only person in the world that wants to do that sort of things.
<xnox> smoser, i thought there was "not ready yet state"
<smoser> xnox: i'd rather ask the system than ask lxc to figure it out.
<smoser> because honestly it can't possibly know for a generic container.
<smoser> the system itself is best suited to say "i'im done"
<cjwatson> I tend to loop until lxc exec $foo runlevel has a digit in the second field, but that's kind of old-school and not exactly elegant
<smoser> cjwatson: my loop above a newer-school example of effectively that.
 * smoser is happy that no one here is giving him the system-init-author response of "there is no way to tell when the system is 'finished' booting"
<rharper> smoser: that's left as an exercise to the questioner
<smoser> i think ideally there'd be a command in ubuntu that ran in a non-polling mode and just blocked until systemd showed something other than 'initializing' or 'starting'. and then parroted that value.
<smoser> wait-for-booted --block --max-wait=1m
<smoser> degraded
<xnox> smoser, well systemctl list-jobs -> will show if it is still doing stuff or not.
<smoser> i think that checking for values other than 'initializing' or 'starting' is what i want
<smoser> but it just seems like that is somethign that the system should give me. so i was asking if such a thing existed.
<lolek> hello
<lolek> I'm tyring to find a way to disable menuproxy from inside a c++ any hints?
<TJ-> nacc: ping? patch available fixing bug #1730731 be great if you can test/confirm the fix and get it published
<ubottu> bug 1730731 in ycmd (Ubuntu) "[16.04] no autocomplete and multiple errors due to not using python3 interpreter or extension calling conventions" [Undecided,In progress] https://launchpad.net/bugs/1730731
<nacc> TJ-: weird that i didn't get a notification
<nacc> TJ-: i'll look at it today
<nacc> TJ-: ah just got it, ok
<TJ-> nacc: Thank-you. It's working fine here; the patch wsa originally suggested for Debian (in the tracked bug) but then they fixed it by pulling an entirely new upstream release
<nacc> TJ-: ack, that's normal, and also what has it fixed in the later releases
<TJ-> nacc: the patch is still being carried in the later Debian releases so I guess it is still required (it's in 17.10 too)
<TJ-> nacc: anyhow, it's quite minimal and it works so I'm happy :)
<nacc> TJ-: cool, will keep you posted in the bug
<dmj_s76> jbicha: How do you feel about packaging a new version of python-xlib for debian and ubuntu?
<jbicha> dmj_s76: the Debian maintainer will take care of that. I pinged him last week.
<dmj_s76> jbicha: okay, good to hear!  It looks like debian still points to the project on sourceforge, when it switched to github years ago.
<jbicha> dmj_s76: since you're here, the fix for LP: #1724024 is ready to be verified
<ubottu> Launchpad bug 1724024 in mutter (Ubuntu Artful) "can't set usable scale for hidpi internal display if when using external display less than 1600x1200" [Medium,Fix committed] https://launchpad.net/bugs/1724024
<dmj_s76> jbicha: Thanks, I'll test and get back to you on that.
<niedbalski> arges, rbasak hello guys , any of you can check the verification for LP: #1657256? also, not sure why the Trusty series wasn't moved into -proposed (it's currently seating in unapvd).
<ubottu> Launchpad bug 1657256 in percona-xtradb-cluster-5.5 (Ubuntu Trusty) "Percona crashes when doing a a 'larger' update" [High,In progress] https://launchpad.net/bugs/1657256
<bdmurray> blackboxsw: Could you add a test case to bug 1722564? I've uploaded a fix to the artful SRU queue.
<ubottu> bug 1722564 in apport (Ubuntu Artful) "apport question will not accept multi-character responses" [Medium,In progress] https://launchpad.net/bugs/1722564
<blahdeblah> Starting firewall maintenance now (see previous message to ubuntu-devel-announce)
#ubuntu-devel 2017-11-09
<mitya57> doko: both qtwebengine and kdb are now fixed in -proposed
<doko> mitya57: ta
<doko> jamespage: please merge/sync python-testtools, bzr is dep-wait on it.
<doko> it's Debian openstack package
<doko> jbicha, seb128: udisks2 needs another merge, gnome-disk-utility is dep-wait
<LocutusOfBorg> jbicha, gnome-shell is a "please steal it from me"
<seb128> doko, right, that's known but blocked on libblockdev that needs to be MIRed first
<jbicha> LocutusOfBorg: I already did ;)
<LocutusOfBorg> <3 jbicha
<jbicha> LocutusOfBorg: but if you want that gnome-shell/virtualbox bug SRU'd to artful, you'll need to add the SRU template to the bug description
<LocutusOfBorg> jbicha, I don't even know if it is worth the fix or not
<LocutusOfBorg> and if it fixed at the end completely the issue
<LocutusOfBorg> vbox in bionic is utterly broken it seems
<jbicha> I haven't had much of a problem with VirtualBox
<LocutusOfBorg> host or guest?
<LocutusOfBorg> setting up a bionic or artful machine is painful
 * Faux uses virtualbox pretty heavily on an artful host.
<LocutusOfBorg> Faux, what is the guest
<Faux> XP, Win7.
<jbicha> I have bionic guest on artful host, doesn't feel very painful here
<LocutusOfBorg> Faux, the problem seems to be wayland or so
<LocutusOfBorg> and new kernels
<Faux> Aha. As an nvidia user, I will never get to use wayland on the host.
<LocutusOfBorg> jbicha, why not merging from Debian?
 * LocutusOfBorg gnome-shell is context
<jbicha> because there is substantial diff and I wanted to get the 3.26.2 SRU started sooner
<TJ-> nacc: whilst you're looking at my fixes for ycmd  maybe you'd look at couple of other papercuts fixes (related to vim) I've prepared debdiffs for: bug #1575802  and bug #1726441
<ubottu> bug 1575802 in powerline (Ubuntu) "default dependancy should be python3-powerline" [Medium,Confirmed] https://launchpad.net/bugs/1575802
<ubottu> bug 1726441 in powerline (Ubuntu) "powerline version from repository is not compatible with fish version" [Undecided,In progress] https://launchpad.net/bugs/1726441
<nacc> TJ-: i'll add them to my list :) they are lower priority generally for me right now, but i should be able to sponsor them sometime soon
<nacc> TJ-: I promise I will at least look tonight
<nacc> TJ-: if i read the ycmd bug, it needs a xenial only task? can you help make sure that there is a comment in each (if it's already there, it's fine) saying where the fix is needed (including 16.04, 17.04, 17.10, 18.04 as possiblities) and where ot?
<nacc> *not
<TJ-> nacc: will do :)
<nacc> TJ-: thanks!
<TJ-> nacc: argh! my membership of bug-control has lapsed. I'll have to re-join
<nacc> TJ-: if you do the nomination, i can approve them
<nacc> I believe anyone can nominate, at least
<nacc> TJ-: i just want to make sure the bug stat is right
<nacc> *status, sorry
<TJ-> nacc: no nomination links for me :(
<nacc> TJ-: ok, can you add comments with the relevant info?
<TJ-> will do; sorting out my bugcontrol membership too
<niedbalski> bdmurray, ping
<bdmurray> niedbalski: howdy
<niedbalski> bdmurray, hey bryan, sorry to pester you about this, could you check the verification for LP: #1657256? also, not sure why the Trusty patch wasn't moved into -proposed (it's currently seating in unapvd).
<ubottu> Launchpad bug 1657256 in percona-xtradb-cluster-5.5 (Ubuntu Trusty) "Percona crashes when doing a a 'larger' update" [High,In progress] https://launchpad.net/bugs/1657256
<bdmurray> niedbalski: There are some autopkgtest failures for zesty w/ diaspora-installer
<niedbalski> bdmurray, where I can look for those errors?
<bdmurray> https://people.canonical.com/~ubuntu-archive/pending-sru.html
<niedbalski> bdmurray, hard to tell if those failures are related to the change though.
<superm1> Hi all.  I was interested in fixing autopkgtest for a package I maintain (fwupd).  I've got it working on debci now, but on Ubuntu it fails with an error i'm not sure how to properly fix.  http://autopkgtest.ubuntu.com/packages/fwupd/bionic/amd64 the particular error is "Failed to restart dbus.service: Operation refused, unit dbus.service may be requested by dependency only (it is configured to refuse manual start/stop)." which yes,
<superm1> I'm trying to manually start dbus because it's needed in the test environment. ....  The debian/tests i'm using is here: https://github.com/hughsie/fwupd/tree/master/contrib/debian/tests
<infinity> superm1: Depending on dbus should be all that's required to have it started in the test environment.
<superm1> infinity: really?  OK well that's an easy enough fix, thanks
<infinity> superm1: "The test enviornment" is a regular system (in a VM or container, depending on arch).  So, yes, depending on daemons should start them the same way it would on your desktop or laptop.
<infinity> superm1: Not like a build chroot, where we intentionally hamstring daemons.
<superm1> Alright, thanks
<infinity> superm1: Oh, but looking at the script, it seems the intent there wasn't to start dbus, but maybe to reload your config?
<infinity> superm1: If so, it wanted to be reload, not restart.
<superm1> no, it was to start dbus
<infinity> superm1: (and reload does work)
<infinity> superm1: Kay.  If the intent was to use restart to start, indeed, dbus should alread be started.
<superm1> I just had this thought that it needed explicit starting since that's how i'm used to working in chroots and stuff like travis CI
<infinity> superm1: Yeah, debci is (IMO) better than that, in the sense that it's really testing how your stuff behaves on a real non-hobbled Debian/Ubuntu system.
<infinity> superm1: If you have to do any synthetic setup after installing your packages, it's a pretty crap test of how your package works, after all.
<superm1> infinity: yeah true
<superm1> the peculiar thing to me though; why was I not hitting this in debian's debci?
<superm1> It's been working just fine there
<infinity> Their dbus service might not block restart like ours does.
<superm1> ah yeah; that looks to be the case: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1540282
<ubottu> Launchpad bug 1540282 in dbus (Ubuntu) "Breaks policykit/systemctl commands when restarted" [Low,Fix released]
<infinity> Yeahp, just checked in a sid chroot, they don't block restart.  They really should, for the same reasons.
<infinity> dbus restart is amazingly harmful.
<infinity> I'm going to blame pitti, who probably should have committed that back to Debian. :P
#ubuntu-devel 2017-11-10
<doko> jbicha: looking at the notofonts in NEW ... I'd like to wait for the Debian import to get the copyright check done. is the package that urgent?  if that goes to main, it should be packaged to use python3. not accepting new python2 packages for main if possible
<jbicha> doko: it's not particularly urgent. nototools is only a Build-Depends so it doesn't need to be in main. (Sorry that upstream doesn't support py3 yet)
<Doow> Hi, I'd like to see if I can add a progress bar in the ubuntu dock to a program, any good tips on where to start?
<ret2libc> i saw https://ldd.tbe.taleo.net/ldd03/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=1320 today... didn't canonical stop working on mir?
<cjwatson> ret2libc: No, Mir is still going.  http://voices.canonical.com/tag/mir/ seems to be a good link for recent news about it
<cjwatson> (I am not a Mir developer and in general don't know much about it beyond just listening to people, so I'm not a good person to follow up with about any of that)
<ret2libc> cjwatson: i see! thank you
#ubuntu-devel 2017-11-11
<alkisg> Hi, I reported LP #696435 and now I'm asked to do the verification step. My problem is that the method to reproduce that I originally reported, is completely different to the method that the ubuntu dev doing the SRU documented,
<alkisg> and I can't reproduce it at all using his method, not even on the original kernel, so I can't do the verification step.
<ubottu> Launchpad bug 696435 in systemd (Ubuntu Xenial) "wait-for-root fails to detect nbd root" [Undecided,Confirmed] https://launchpad.net/bugs/696435
<alkisg> xnox, since you commented on the bug, may I ping you for clarification? :)
 * alkisg commented on the bug report, "the initial testcase isn't yet fixed, while the sru testcase was never an issue for me"
<madigens> sladen: pinging again regarding the ubuntu font discussion :)
<doko> mapreri: some of the qt changes seem to affect qt4 as well: mm3d qoauth
<sladen> madigens: plan is same as always :)
<madigens> do nothing? :)
<mapreri> doko: wrong person?
<doko> oops
<sladen> madigens: postive thoughts and support are always really appreciated.  Somethings are complicated by politics, or external factors and can take longer than might be hoped.  "Rome was not built in a day" etc
<madigens> sladen: alright, i'm channeling my positive energy in your direction!
<ricotz> tsimonq2, hi, I am hoping you noticed that your cairomm upload isn't working and proper rebuilds are required
<jbicha> can we please just delete that cairomm upload unless that change is made in Debian first?
<jbicha> LocutusOfBorg: ^
<tsimonq2> ricotz: yep, *just* got online for the day :)
<tsimonq2> jbicha: Fine by me.
<tsimonq2> (if that's what you'd prefer)
<tsimonq2> Personally I'd like to get the rebuilds done and get it to migrate before 18.04 so we don't have to carry transitional packages for the next 2 years.
<tsimonq2> (and iirc Debian NEW is pretty slow...)
<tsimonq2> (but yeah, at your discretion, you seem to be part of the Debian team)
#ubuntu-devel 2017-11-12
<mwhudson> omg the autopkgtest queues look almost reasonable
<mwhudson> and arm64 autopkgtests? that's fairly exciting
<tsimonq2> *finally*
<xnox> mwhudson, indeed \o/
<xnox> well, arm64 we have baseline for xenial, and finishing zesty i guess. still to rerun artful and bionic....
<mwhudson> and s390x autopkgtests are running in vms now?
<mwhudson> or did i imagine that?
<xnox> mwhudson, i believe they are, yes.
<mwhudson> w00t
 * mwhudson is a bit tired of running the docker.io arm64 and s390x tests by hand
<xnox> we do need https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1730647 in the cloud images before s390x adt tests can upgrade kernels on boot though
<ubottu> Launchpad bug 1730647 in ubuntu-meta (Ubuntu Artful) "on s390x one should alway be able to manipulate z devices" [Undecided,Fix committed]
<tsimonq2> xnox: Could that at all be related to enabling s390x in PPAs? ;)
<xnox> tsimonq2, not there yet - see lack of s390x in the virual build status at https://launchpad.net/builders
<tsimonq2> xnox: I see... is there a general timeframe for when those will be available?
<xnox> tsimonq2, nothing to do with me...
<tsimonq2> xnox: ok :)
#ubuntu-devel 2018-11-05
<infinity> Querying Debian BTS for reports on libprelude (source)...
<infinity> Unable to connect to Debian BTS (error: "TypeError("fixer() missing 1 required positional argument: 'check_hostname'",)"); continue [y|N|?]?
<infinity> doko, mwhudson: ^-- Does reportbug need a merge/fix for newer python bits?
<doko> infinity: where do you see that?
<mwhudson> infinity: well isn't that great
<doko> coreycb: please could you have a look at the murano sync/merge and look at the autopkg test failures?
<doko> coreycb: same for ironic, libcloud
<doko> jamespage: ^^^
<handsome_feng> Hi, Does anyone know how to unpack and repack the initrd? cpio -idv < ../initrd.img only got a AuthenticAMD.bin; and 'dd if=initrd bs=xxxx | lz4 | cpio -tdv | head' didn't work too.
<TJ-> handsome_feng: "unmkinitramfs"
<seb128> handsome_feng, unsure if that's still current/valid, but https://wiki.ubuntu.com/CustomizeLiveInitrd
<TJ-> handsome_feng: you're dealing with an image that has an early-prefix for microcode on it
<handsome_feng> TJ-, seb128 : Thanks! unmkinitramfs works and BTW the wiki page is out of date :)
<seb128> handsome_feng, would be nice to update it if you have some free cycle for that :)
<TJ-> seb128: I've been waiting to do some Wiki editing but it seems to take an age to get approved to the wiki editors team
<TJ-> by the time it gets approved I'll have forgotten what it was I intended to edit :)
<seb128> that seems suboptimal :/
<seb128> unsure who can approve wiki editor nowadays
<TJ-> oh yeah - malware at the target of some links
<seb128> ?
<TJ-> domains expire/rot, get taken over by operators hosting malware payloads
<seb128> popey, ^ you might know who is approving wiki-editor membership?
<seb128> TJ-, right, I think I lack some context, why are you talking about that now?
<TJ-> seb128: that's reminding me what I wanted to edit to fix; a user reported it in #ubuntu a couple weeks ago
<seb128> TJ-, I was just saying that I'm unsure who is reviewing the member-ship requests to approve them, so who to ping to help you getting edit rights
<seb128> let's see if popey can help
<popey> seb128: i can do that
<seb128> popey, hey, ah nice :)
<popey> done
<seb128> thx!
<seb128> TJ-, ^
 * TJ- does a happy dance :)
<handsome_feng> seb128: Sure, I will do it when I have time. :)
<rbasak> vorlon: the git-ubuntu importer service won't restart because it is running on Xenial and using the ubuntu-keyring package, and the archive now has a signature for which it doesn't have a public key. I guess there are currently no plans to SRU updates to this package?
<rbasak> I'm not sure how to handle this general case.
<rbasak> ISTR there was some reason git-ubuntu needed every key used in Debian and Ubuntu ever.
<rbasak> But I don't want to have to release upgrade the git-ubuntu importer service host every time there's a key rotation.
<coreycb> doko: jamespage: i'll take a look at those.
<coreycb> vorlon: thanks and no problem on the delay. there is charm support going on for octavia that ramped up recently and shined light on octavia-dashboard.
<rbasak> "ISTR there was some reason git-ubuntu needed every key used in Debian and Ubuntu ever." -> Now I think about it, it might just be for all supported releases.
<rbasak> ahasenack, cpaelzer: may I have your opinion please on my proposed approach in bug 1801725? This is for an upcoming fix to git-ubuntu, without which the importer service is down.
<ubottu> bug 1801725 in usd-importer "Importer service fails to start due to missing public key" [Critical,Triaged] https://launchpad.net/bugs/1801725
<ahasenack> rbasak: wasn't something similar done already in e1b4cd8c9c488a0403f6efecd2cdf3748aa85963 for when bionic was released?
<ahasenack> it links to https://bugs.launchpad.net/bugs/1752656
<ubottu> Launchpad bug 1752656 in ubuntu-keyring (Ubuntu) "Please SRU archive keyrings to older releases" [Undecided,New]
<rbasak> ahasenack: aha. Perfect. Thanks!
<rbasak> I guess I'm bumping those up then.
<ahasenack> +1
<xnox> rbasak, ahasenack - please do not duplicate work w.r.t. 2018 key update only. irrespective of the acient bug asking for effectivly `sru everything all the time`
<xnox> rbasak, also your guess is wrong =)
<xnox> however, i was not planning to go further than bionic. because debootstrap in xenial is not good enough to bootstrap disco.
<xnox> commented on https://bugs.launchpad.net/usd-importer/+bug/1801725
<ubottu> Launchpad bug 1801725 in usd-importer "Importer service fails to start due to missing public key" [Critical,Triaged]
<xnox> rbasak, ahasenack - also it should be normal for only one signature out of the two valid.... that's why we have dual signing.
<ahasenack> xnox: gpgv doesn't like it, exits status 2
<rbasak> xnox: "Thus imho this is a bug in the importer if it requires all keys." -> it's a problem with gpgv then.
<rbasak> (or a feature request in gpgv at least)
<xnox> rbasak, ahasenack - do you have the full cmdline you execute? and/or where is this code at?
<xnox> i believe we managed to fix this right; using gpgv; for e.g. ubuntu-release-upgrader
<rbasak> xnox: https://git.launchpad.net/usd-importer/tree/gitubuntu/apt_repo.py#n85
<xnox> rbasak, ahasenack - gpgv should be able to return signed output, which should be trustworthy, irrespective of errorcodes. Cause full untrusted stuff should return nothing in stdout. Or something along those lines.
<xnox> thanks, let me check that out.
<rbasak> xnox: and yeah, it's a wheel reinvention. Unfortuantely I couldn't find any library code that did this.
<xnox> there is no library for gpg stuff, it sucks.
<xnox> and the C embeded netgpg library i found in netbsd is very bad - leaky and not memory safe, thus one is stuck forking to gpg(v)
<xnox> rbasak, love the comments there
<rbasak> Thanks
<rbasak> xnox: so the gpgv manpage (in Xenial at least) says: "The program returns 0 if everything is fine, 1 if at least one signature  was  bad,  and  other error codes for fatal errors."
<xnox> yeah
<rbasak> xnox: that makes me reluctant to treat non-zero as anything but "everything unverified".
<ahasenack> rbasak: do you have gpgv complaining about trustedkeys.kbx too? https://pastebin.ubuntu.com/p/3RPK3F3MxT/
<ahasenack> I got that on bionic
<ahasenack> I do have the key 3B4FE6ACC0B21F32, just not 871920D1991BC93C
<ahasenack> gpg (not gpgv) confirms that, and validates the signature made by 3B4FE6ACC0B21F32
<rbasak> ahasenack: no - I'm using --keyring= which I think overrides the default of looking in your ~/.gnupg
<ahasenack> anyway passing it the right file via --keyring still returns 2, even though it then verifies one signature correctly
<ahasenack> so "no public key" is treated more seriously than "invalid signature" perhaps
<xnox> dunno, it seems to me that gpgv is completely broken. as it outputs cleartext, irrespective of signature validity. E.g. i clearsigned something with my own key; validating against archive-keyring; fails to validate any input, yet still spits out output.
<xnox> not having any more luck with gpg --decrypt
<cjwatson> no library> gpgme exists
<cjwatson> (not *necessarily* recommending it, but in some contexts it can be helpful)
<rbasak> cjwatson: I meant a library to verify the apt repository
<cjwatson> I was replying to
<cjwatson> 14:01 <xnox> there is no library for gpg stuff, it sucks.
<rbasak> Ah
<xnox> well, i do know about gpgme, but yeah i wouldn't call it a `useful` library =) cause it also does fork to gpg. So far i found forking gpg/gpgv by yourself easier.
<xnox> and the netpgp was done in the context of no-forking allowed (for pid1)
<xnox> granted, thankfully, never released that code.
<xnox> the go openpgp library is quite good, for these things.
<xnox> but it is in golang.
<xnox> hm apt-key verify is just as broken.
<Faux> It so is.
<infinity> doko, mwhudson: I got that error from reportbug when running 'submittodebian' on disco.
<xnox> juliank, how does apt deal with multi-signed apt archives? because e.g. apt-key verify isn't doing what i need/want. Or apt code parses the status-fd stuff?
<xnox> juliank, i wonder if i can (re)use /usr/lib/apt/methods/gpgv somehow
<TJ-> xnox: how much trouble do you want to go to? Because I've just tested a method locally of splitting the 2 signatures off, then reconstructing with 1 at a time, so gpgv can return 0 if 1 matches (so you'd just loop over each signature).
<xnox> TJ-, well, i like the logic that is performed by /usr/lib/apt/methods/gpgv already and it matches what apt itself does.
<juliank> xnox: yes, it does parsing, and maybe
<juliank> I think the logic is in the library
<xnox> TJ-, i wish that to be exposed, in some user-friendly format, perhaps injected to be used as the backend for $ apt-key verify
<xnox> juliank, yeap, found it. It parses the logger/status-fd and correctly counts things as we need/want.
<xnox> TJ-, ideally i would not want to do signature splitting. As parsing openpgp packets is error prone =/
<xnox> TJ-, also imho gpgv in these cases should be returning error code 1, not 2.
<xnox> TJ-, i think i will file a gpg/gpgv bug; and also will file an apt bug, cause imho standard ubuntu system should have a gpgv like util out of the box for easy apt-key verification of stuff.
<xnox> TJ-, if you pastebin your signature splitting code that should be doable too.
<xnox> doable/nice
<xnox> or update all the ubuntu-keyring everywhere....
<juliank> xnox: you could try to use apt-helper Download-File gpgv:$path too
<juliank> Sans upper case
<juliank> And with a destination filename
<xnox> juliank, oooooh
<juliank> I'm not sure what happens, but it's worth trying
<xnox> juliank, i didn't find apt-helper yet =) i think this might be what i need.
<juliank> /usr/lib/apt
<TJ-> xnox: yes, I agree about returning 1 not 2
<xnox> juliank, cause by-hand Acquire-URI commands into the stdin of gpgv method were doing the right thing for me.
<xnox> juliank, TJ- lunch first, then bugs.
<TJ-> xnox: I've 1 last bit to fix-up, figuring out the CRC algorithm used on the signature block :) ... I used gpgsplit to break out the signatures
<TJ-> xnox: I give up - no easy way with limited tooling to recreate the PGP signature CRC (and gpgv cannot be told --ignore-crc-error as gpg can)
<xnox> =(
<xnox> TJ-, parsing status-fd, and/or using the apt's gpgv method imho is the way to go.
<xnox> this shall be the master bug to track this: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1801762
<ubottu> Launchpad bug 1801762 in ubuntu-release-upgrader (Ubuntu) "Dual-signed things should be easy to verify with one key" [Undecided,New]
<TJ-> I fed the crc32 poly and init values into jacksum to recreate, but jacksum is quite heavy (being Java)
<juliank> xnox: did you try the helper, does it work? /me curious
<xnox> juliank, tried. did not do what i wanted =/ it either `downloads` files without any verification, or fails.
<xnox> juliank, maybe i'm not using the right syntax.
<xnox> juliank, timed-out trying to work out what it is doing. was going to strace it next.
<xnox> maybe i needed to something like gpgv+file:// ?!
<juliank> xnox: FWIW, one of src/dest is the keys, the other the data to check (in case of clearsigned, both are the same)
<juliank> I think the destination is the key file
<juliank> s/key/sig
 * juliank disappears again, enough screen time for now :(
<TJ-> xnox: I've got a script that works - wraps gpgv. Any good to you? http://iam.tj/projects/ubuntu/gpgv-aptkeys
<TJ-> xnox: grr, sent you the symlink version. Use this: http://iam.tj/projects/ubuntu/gpgv-multisig
<rbasak> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<slashd> o/
<slashd> sorry we changed hours here
<tsimonq2> Hi
<infinity> coreycb: That ironic update also claims to require python-scciclient>=0.8.0 ... we only have 0.6.1
<infinity> coreycb: Similar problem in cosmic, mind you, where it wanted 0.7.2 ..
<infinity> coreycb: Might want to fix both those issues.
<coreycb> infinity: ok will take a look, thanks for catching that
<infinity> coreycb: The cosmic reqs might be a lie (but worth investigating if you need to fix something there or update scciclient or whatever), but the disco one looks legit.  The do_async flag didn't exist before 8.0
<coreycb> infinity: can you reject that? I'd like to run dep8 tests and do this via bileto.
<infinity> coreycb: Done.
<coreycb> infinity: thanks
#ubuntu-devel 2018-11-06
 * mwhudson eyeballs the publisher
<mwhudson> coreycb, jamespage: are you guys onto ironic vs python 3.7?
<mwhudson> pitti: hey any idea what happened here? https://launchpadlibrarian.net/396208508/buildlog_ubuntu-disco-amd64.python-dbusmock_0.18-1ubuntu1_BUILDING.txt.gz
<pitti> mwhudson: o/
<pitti> mwhudson: I don't know I'm afraid, I haven't seen this before
<pitti> mwhudson: I suppose it's time to add disco to the upstream CI and reproduce; supposedly something in systemd changed
<pitti> I keep that tab open as a reminder, will look at it in the next evenings
<mwhudson> pitti: thanks
<doko> jamespage, coreycb: pycryptodome needs a MIR, needed by python-pysnmp4
<doko> autopkgtest [07:22:24]: test minimized:  - - - - - - - - - - stderr - - - - - - - - - -
<doko> /usr/bin/germinate:25: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
<doko>   import imp
<doko> cjwatson: ^^^ with python 3.7, would need a fix
<xnox> doko, vorlon already proposed a fix for this
<xnox> doko, see ##cloundations
<cjwatson> doko: I'm off today but will look at that MP tomorrow
<doko> zyga: https://tracker.debian.org/pkg/plainbox needs an update, RC issues, removing from disco for now
<zyga> doko: there's a bug to remove it from ubuntu and Debian - CE doesn't maintain the package anymore and I think it's best to drop it
<doko> well, upstream is 0.38, debian is 0.25 ...
<jbicha> zyga: could you file a Debian RM bug for plainbox?
<zyga> jbicha: I don't know how but I can look and try
<jbicha> zyga: if you use reportbug, try something like
<jbicha> reportbug -B debian ftp.debian.org
<jbicha> or if you want to file manually, Debian bug 894269 is an example and bugs will show up at https://ftp-master.debian.org/removals.html after a short delay
<ubottu> Debian bug 894269 in ftp.debian.org "RM: esound -- RoM; RoQA; unmaintained for years" [Normal,Open] http://bugs.debian.org/894269
<jbicha> you don't need moreinfo though, that was added because that pkg wasn't yet ready for removal when I filed it
<jbicha> the important part in Debian removal bugs is the subject line really
<coreycb> mwhudson: working on ironic here - https://bileto.ubuntu.com/#/ticket/3505
<coreycb> doko: for pycryptodome MIR: https://bugs.launchpad.net/ubuntu/+source/pysmi/+bug/1748572
<ubottu> Launchpad bug 1748572 in pysmi (Ubuntu) "[MIR] pysmi, pycryptodome" [High,Fix released]
<doko> coreycb: thanks for the pointer. re-promoted
<coreycb> doko: thanks
<doko> coreycb: so that still leaves us with murano and libcloud
<coreycb> doko: i'm not sure who owns libcloud. i've got murano.
<doko> mehh, nobody owns it
<doko> ahasenack: I force synced libcloud, discarding your changes. looks like these were all applied in debian
<ahasenack> let me try to remember what that was
<ahasenack> those were dep8 fixes
<ahasenack> and maybe an ftbfs one
<ahasenack> yeah, my 1ubuntu1 was about dep8: http://autopkgtest.ubuntu.com/packages/libcloud/cosmic/amd64 that's when they became green
<doko> ahasenack: they are now read again: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/libc/libcloud/20181106_101506_7107b@/log.gz
<ahasenack> doko: and your sync, is that still making its way through?
<doko> ahasenack: I don't know, currently building
<ahasenack> doko: ok, let's wait to see how it goes. If it fails dep8, I can take a look
<doko> tsimonq2: please could you have a look at the libkolabxml ftbfs? only dependency is kdepim
<smoser> archive is still closed ? (as topic states) ?
<doko> smoser: yes, still working on perl and python
<smoser> thanks doko
<tsimonq2> doko: Sure, in a bit.
<seb128> rbasak, I reuploaded the bolt SRU to bionic to really remove the -Ddb-path option use and comment on the bug, I would appreciate if you could have another look (or delegate to another SRU member if you are busy, since the previous SRU had a regression and it's blocking the current fwdup SRU which is bionic-proposed)
<rbasak> seb128: I don't think I'll get to it today, sorry. My regular shift day is tomorrow.
<rbasak> seb128: if it's a serious regression then I'd prefer a roll back than marching ahead with even more regression risk.
<rbasak> (since the upstream bump includes a bunch of not-necessary-for-the-fix changes)
<rbasak> I'm fine if any other SRU team member wants to take it.
<seb128> rbasak, I don't think it's a serious regression and tomorrow is fine
<seb128> rbasak, it's basically fwupd and bolt which can step on each other toes, the new version add an API which fwupd uses to sync and make sure there is not conflicting between them. Tomorrow is fine if you think you can have another look during your normal shift :) thx!
<rbasak> OK, thanks!
<pitti> Laney: hey, how are you?
<pitti> Laney: any idea why http://autopkgtest.ubuntu.com/statistics is broken? the page loads forever
<Laney> hi pitti
<xnox> infinity, join #ubuntu-installer maybe?
<Laney> let me look
<Laney> pitti: it loaded for me, just took a few (10s of) seconds
<pitti> Laney: hm, I stopped it here after 1.5 minutes
<pitti> I thought it was just a bunch of sqlite queries
<Laney> no idea why it's so slow
<Laney> the machine isn't particularly overloaded
<Laney> perhaps apache is having a hard time
<Laney> ah the download-results thing is running, probably fighting for access to the database
<Laney> that could probably batch its inserts
<pitti> ah, that makes sense
<pitti> if the db is locked
<pitti> indeed it finished loading now
 * Laney had an idea about eliminating that step by notifying directly when a job completes
<Laney> I've not got much time for things like that, though
<ahasenack> doko: libcloud's tests are passing
<doko> I saw, ok, everything is fine
<tsimonq2> doko: Home for lunch, looking (earlier than I expected).
<doko> tsimonq2: already fixed
<tsimonq2> doko: oh?
<tsimonq2> ah
<doko> tsimonq2: here's one more: https://launchpadlibrarian.net/395871642/buildlog_ubuntu-disco-i386.ecflow_4.10.0-2ubuntu2_BUILDING.txt.gz
<doko> I'm ak now
<doko> afk
<tsimonq2> doko: have fun
<coreycb> bdmurray: hello, i've uploaded a new stable point release of neutron to the bionic unapproved queue. that would replace the version that is currently in bionic-proposed.
<coreycb> bdmurray: if you have a chance, can you take a look?
<coreycb> bdmurray: the stable point release of 12.0.5 includes the 2 cherry-picked patches so they've been dropped fro d/patches
<coreycb> from
<mwhudson> Need to get 695 MB of archives.
<mwhudson> After this operation, 2521 MB of additional disk space will be used.
<mwhudson> this is going to be a lightweight test!
#ubuntu-devel 2018-11-07
<doko> coreycb: nova needs the 3.6 fix: http://autopkgtest.ubuntu.com/packages/n/nova/disco/amd64
<seb128> tsimonq2, hey, you have SRU in bionic that need verification for a long time, e.g openbox since june or python-phabricator since august, could you get them verified?
<ahasenack> do I need to run germinate-update-metapackage in disco, or am I just missing a package from backports perhaps? I'm on bionic: https://pastebin.ubuntu.com/p/ydGWxd4XgY/
<ahasenack> that 'update' script is from the ubuntu-meta source package
<cjwatson> Either make sure you have at least as new a version of debootstrap as the last person who ran the script (reported in that error message), or you can ignore it by hacking the debootstrap-version file but then it's on you to check the diff with a fine-toothed comb
<ahasenack> cosmic is fine then
<ahasenack> no, I need disco
<ahasenack> let's see if I can get disco yet
<cjwatson> ahasenack: I don't see why.   debootstrap | 1.0.108ubuntu1       | cosmic          | source, all
<cjwatson> ahasenack: You might need the one from cosmic-proposed in order to get the disco symlink
<ahasenack> it complained about missing /usr/share/debootstrap/scripts/disco
<ahasenack> I hacked update.cfg to point at disco instead of cosmic
<ahasenack> anyway, got a disco image
<cjwatson> ahasenack: https://launchpad.net/ubuntu/+source/debootstrap/1.0.108ubuntu1.1
<ahasenack> hm, no I didn't get a disco image
 * ahasenack looks for his coffee
<doko> coreycb, jamespage: please see the autopkg test failures triggered by python-greenlet: nova cinder heat
<coreycb> doko: i'll take a look
<seb128> rbasak, thx for the bolt review!
<rbasak> np!
<rbasak> Laney: please could you help with the autopkgtest failures in the glib2.0 SRU to Bionic? There are rather a lot :(
<rbasak> (and I think we want to be force-badtesting everything after verifying if we are to ignore them)
<smoser> dannf: https://code.launchpad.net/~dannf/cloud-initramfs-tools/+git/cloud-initramfs-tools/+merge/344193
<smoser> is that still a problem ?
<bdmurray> mpt: Could you comment on bug 1787553? I find the frequency of the livepatch reminder rather odd.
<ubottu> bug 1787553 in update-manager (Ubuntu Bionic) "Add a reminder to enable Livepatch " [Medium,Incomplete] https://launchpad.net/bugs/1787553
<rbasak> xnox: are you planning on sorting the MERGED_USR thing in the debootstrap SRU backports please? The lack of debootstrap support for the distro-info-data development release is what is I think causing sbuild autopkgtests to fail in the stable releases.
<bdmurray> rbasak: agreed
<rbasak> I wonder if an alternative is to accept it as-is, given that users release upgrading won't get usr-merge we have to support that anyway.
<Laney> rbasak: Okey dokey - do you want my assessments here?
<rbasak> Laney: I'm not entirely sure. It'd be nice if you could give me an MP for hints to suppress everything, with justifications. Then I suppose my job is to check that they all seem reasonable, and then I can get the report clear.
<rbasak> I'm not sure if that's the expected process now or what.
<rbasak> (and of course mark verification-failed-* if any failures are genuine; I'm not sure if I've ever actually seen that :-/
<Laney> rbasak: Alright. Doing this makes sense if you want to move to using britney to release the SRUs, anyway.
<Laney> For the dev. release the release team shoulders much of the burden - I like that for SRUs you're pushing that back to the uploader
<Laney> it's mostly "crappy flaky tests" though, because we don't have good mechanisms/incentives to get them fixed
<cpaelzer> hi, has anybody experience using the scons build system with python3 ?
<rbasak> pushing that back to the uploader> only because it feels like I make no progress on an SRU shift otherwise, which seems particularly inefficient given that there are relatively few SRU team members and any uploader can do it.
<rbasak> it's mostly "crappy flaky tests" though> yeah it's frustrating. I'm not convinced that the benefit of dep8 is currently worth the trade-off of developer time trawling through a gazillion failures.
<Laney> imagemagick was obviously broken by something that got released into bionic
<smoser> rbasak: interested in what you think about https://code.launchpad.net/~smoser/usd-importer/+git/usd-importer/+merge/358390
<smoser> i realize the chicken-and-egg thing, but I feel that the solution there provides a quick way to run tests and pylint that cannot really be provided by tox
<smoser> and https://code.launchpad.net/~smoser/usd-importer/+git/usd-importer/+merge/358413 is really just a upstream policy... if you want tests in the same files or not.  Either way on that one I think that the pytest.cfg change is an improvement.
<rbasak> smoser: on tox, I have no particular opinion, though I was going to run it past powersj wearing a QA hat.
<rbasak> smoser: on _test.py, I agree and we adopted that policy a while ago - we just hadn't actively moved old tests into that form.
<smoser> so the policy is to move to _test.py.
<smoser> ok
<smoser> wrt tox. i'm ok to wait on a suggestion from powers, but i can't imagine he'd disagree.  For a number of reasons tox just doesn't "fit" here.
<smoser> I love tox, and depend on it elsewhere. but it just doesnt fit here.
<rbasak> Sure. I'm just consciously inexperienced in this area.
<tsimonq2> seb128: Sure, it's on the TODO list.
<tsimonq2> What's the rush?
<tsimonq2> (It's been sitting there for a bit, what's the sudden urgency?)
<seb128> tsimonq2, having SRUs in the proposed queue unverified since june just feels wrong, what if we need to stack another fix on those? also it means a fix that was upload is not reaching users which is a waste
<Laney> What urgency?
<Laney> You just got pinged, after multiple months - I think that it's fair enough to think you might need a reminder ...
<tsimonq2> Fair.
<Laney> ð
<tsimonq2> seb128: needing to stack things on top> Lubuntu maintains both packages, and while my name is on the package, *poke* wxl (QA manager in Lubuntu) to verify. :P
<tsimonq2> (Phabricator less so, but it's seen very few updates and we use the archive package in prod.)
<seb128> tsimonq2, well, that might be a non point, still we often have SRUs that end up sitting in the proposed queue for years not being verified which is just wrong, those are fixes we cared enough to upload so we should care enough as well to have them reaching the users
<seb128> tsimonq2, if we don't care about getting them to user why did we bother doing a SRU upload and wasting reviews time?
<tsimonq2> Understood.
<seb128> thx :)
<tsimonq2> Thanks for the reminder.
<coreycb> doko: i'm hitting py36 test failures on disco with 'import _cffi_backend as backend'. it's not an issue if python3.6 is going to be dropped from disco but for now the openstack packages auto-detect py3 versions during builds.
<seb128> when can we expect disco to really open?
<Laney> after perl and python3-defaults I think
<tsimonq2> I wanted to get Qt in too but that's a maybe at this point.
<seb128> k, I've no idea how far those are so I guess I will just keep waiting for a while :)
<Laney> looking quite good AFAICS
<seb128> great, because we are already 3 weeks into the cycle
<seb128> so would be good to start moving for other things thattoolchain & early transitions :)
<seb128> well, as long as SRU team doesn't block my cosmic fixes "because the fix is not in disco" yet it's ok
<rbasak> FWIW, I don't think it makes sense to block SRUs on that. As long as an upload is ready somewhere for Disco I'll be satisfied.
<seb128> good to know :)
<doko> coreycb: you don't have 3.6 extensions anymore
<dannf> smoser: yes, still seeing it. and fyi, hit another issue just now when checking it: https://code.launchpad.net/~dannf/cloud-initramfs-tools/+git/cloud-initramfs-tools/+merge/358453
<smoser> dannf: i'll upload as soon as archive is open.
<smoser> i'll get that one too.
<dannf> smoser: thx!
<doko> coreycb: heat ftbfs with test failures
<coreycb> doko: working on it thanks. it's the py36 unit tests.
#ubuntu-devel 2018-11-08
<mwhudson> so i'm using the git-ubuntu merge workflow, which is generally great but now i have conflict markers in a patch :(
<mwhudson> xnox: why are the systemd autopkgtests such a pain?
<mpt> bdmurray, done
<doko> xnox: the fix for ubuntu-image doesn't work: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/arm64/u/ubuntu-image/20181107_212237_630e2@/log.gz
<doko> py3.5 is still skipped, but it wants to run 3.6 and fails due to missing extensions modules
<doko> the good news is that the 3.7 tests succeed
<doko> coreycb, jamespage: python3-defaults migrated, "reverse-depends src:python3.6" now gives you a better overview of pending openstack issues
<coreycb> doko: ok thanks. they are my main focus but keep getting side-tracked.
<xnox> doko, hm. not what i expected. i expected py36-nocov to end up with InterpreterNotFound as well
<xnox> doko, python3.6 is still preinstalled in the cloud image that runs the tests
<xnox> i guess it will, whilst anything still supports python3.6 in the archive =/
<seb128> bdmurray, hey, could you have another look to the gnome-initial-setup SRU to bionic/cosmic, I just replaced the previous one in the queue to fix an error, the new SRU fixes a problem with the one currently in proposed so it would be good to have it in
<cpaelzer> rbasak: I was able to confirm that scons fix to work
<cpaelzer> rbasak: I'd push my branch implementing that fix on top of the current salsa to "my" salsa
<cpaelzer> and I'd update the bug referring to all that
<cpaelzer> rbasak: would you need anything else to consider NMU/TMU helping on the case?
<bdmurray> seb128: I'll have a look today
<seb128> bdmurray, thx!
<seb128> bdmurray, oh, while you are around I was curious if there was a particular reason you converted https://errors.ubuntu.com/problem/de2163c7e1ac3121ceee359e1cc10fe3bb471d7c to a launchpad bug
<seb128> bdmurray, there has been no report in 17.10 and newer series which suggest the issue is fixed, and the number of report in xenial is rather low so I don't think it would qualify as important enough to justify a SRU to LTS-1
<bdmurray> seb128: Is 1800 low? Oh maybe over a couple of years
<seb128> bdmurray, sounds low to be, "common" issues on LTS series usually collect to 10k report by week
<seb128> -to
<seb128> bdmurray, 1900 since 16.04 it's like 3 reports a day
<bdmurray> seb128: Okay, so then don't worry about it.
<seb128> bdmurray, :-) I was about to close the bug but I was wondering if you had special reasons to open in, thx for the reply
<rbasak> cpaelzer: looks like the maintainer isn't a DM or DD, and all his recent uploads have been sponsored.
<rbasak> cpaelzer: I wonder if contacting the sponsor would help?
<rbasak> cpaelzer: he's listed in Uploaders
<cpaelzer> rbasak: Laszlo ?
<rbasak> Yes
<rbasak> Perhaps Cc the bug
<cpaelzer> Sure I can give it another ping - and we can still consider doing an NMU later on
<cpaelzer> will ping him
<rbasak> cpaelzer: also maybe write to ...-submitter@bugs.d.o as the original submitter is a package maintainer also and might have an opinion.
<cpaelzer> rbasak: the original submitter knows
<cpaelzer> rbasak: I'm in contact with him on gpsd
<rbasak> Ah OK
<bdmurray> seb128: Something is wonky with the g-i-s in cosmic the diff is empty
<seb128> bdmurray, sorry, looks like I did dput the wrong file
<bdmurray> seb128: okay, rejecting
<seb128> bdmurray, reupload, looks better this time, http://launchpadlibrarian.net/396496950/gnome-initial-setup_3.30.0-1ubuntu3_3.30.0-1ubuntu3.1.diff.gz
<seb128> bdmurray, thx
<rbasak> Laney: around? Thank you for the MP. So does this mean the imagemagick dep8 on Bionic regressed with the upload of imagemagick 8:6.9.7.4+dfsg-16ubuntu6.4 but the failure is correct, the test is working - just not glib2.0 that's breaking it?
<rbasak> Or is it a false positive caused by the security update?
<rbasak> FWIW this is the part that bothers me - it feels like I'm unnecessarily blocking the glib2.0 SRU even by having to ask the question and investigate.
<rbasak> I feel that it should be sufficient to verify that the failure isn't caused by the glib2.0 SRU and proceed on that basis, leaving imagemagick behind, but this seems to be in conflict with what I've been told to do (unless I'm not being told to do that, or I'm permitted to make an exception in this case, but that's what I'm not clear about).
<Laney> rbasak: I didn't really dig into the failure. It seems likely that 6.4 broke it, but I don't think we're required to figure that out for releasing further SRUs that happen to trigger it.
<Laney> If you wanted, we could perform a run with imagemagick as the only trigger to verify that it fails in that case in the same way.
<Laney> and then without actually investigating we'd know that some change in <the autopkgtest system> + <imamgemagick and its transitive dependencies> between 2018-08-30 and 2018-10-17 broke it
<Laney> I guess we can do a little bit better if you happen to know about ubuntu-security-proposed ppa runs: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-ubuntu-security-proposed-ppa/bionic/amd64/i/imagemagick/20180928_205901_0b4c9@/log.gz
<Laney> Which looks a little bit like the security team might have investigated... :-)
<rbasak> Laney: I'd like to clarify on the ML what to do in this case, but I'm out of time today :-/
<rbasak> I'll post tomorrow. Sorry for the delay.
<Laney> Alright, no worries.
<Laney> sbeattie: ^- (pinging you since you uploaded imagemagick/bionic-security, not to blame) - what do you do with the autopkgtest results in triggered for security uploads?
<Laney> It looks like that update made the tests go to red, so I'm wondering if that gets noted / assessed / something.
<rbasak> For reference: http://autopkgtest.ubuntu.com/packages/imagemagick/bionic/amd64
<rbasak> and https://code.launchpad.net/~laney/britney/hints-ubuntu-bionic-glib2.0/+merge/358449
 * Laney nods
<sbeattie> Laney: currently the autopkgtests on the security-proposed ppa are a new thing to us, so we don't often look at them. But we should change that.
<Laney> ah, OK, that would be good :-)
<Laney> I was pleased to see that they're being run
<sbeattie> Okay, the failure there is due to the configuration change to disable pdf support by default in the policy definition for imagemagick.
<sbeattie> (because that gets handled by ghostscript for imagemagick, and ghostscript unfortunately has had a ton of security vulnerabilities around handling things safely)
<Laney> That's fine if it's deliberate, and it sounds like the right thing to do is to update the tests
<rbasak> Sounds like a force-badtest is the right thing to do then.
<Laney> (Not saying that has to be done now, but if there's a good way to stage it for the next upload ...)
<Laney> Agreed
<ahasenack> what's the appropriate way to fix a package that was uploaded to -proposed as part of an sru, verification failed, and the error was found, meaning a new upload has to happen, with regard to the changelog?
<ahasenack> In this case (https://pastebin.ubuntu.com/p/mTCwhtDB7S/),
<ahasenack> verification-failed is 2:4.7.6+dfsg~ubuntu-0ubuntu2.3
<ahasenack> and the good one will be 2:4.7.6+dfsg~ubuntu-0ubuntu2.4
<ahasenack> a) should I do it like it's in the pastebin?
<infinity> ahasenack: That's fine, yes.
<ahasenack> b) should I use the changelog message from 2.3 in the new 2.4?
<ahasenack> (ignoring 2.3)
<infinity> ahasenack: No need to erase 2.3 from history.
<ahasenack> so like that is fine?
<infinity> ahasenack: If there were a bug for the regression, you'd address that in the 2.4 upload, but if the bug was just noted in a comment on the original, the way you've done it is fine.
<ahasenack> great, thanks
<WoC> in a multi-arch installation, is there any tool that can grab the sources for the packages  installed on a system and create a local repository for the packages not in the public repositories ? (ppc64)
<sarnold> do you mean, from ports.ubuntu.com or .. something else?
<WoC> sarnold, yes
<WoC> since there are no ppc64 pkgs pre-compiled
<sarnold> WoC: hmm, can you specify what you mean? e.g. http://ports.ubuntu.com/ubuntu-ports/pool/main/b/bash/bash_4.4.18-2ubuntu3_ppc64el.deb is a precompiled ppc64 pacakge..
<WoC> i got big endian
<sarnold> oh.
<sarnold> so you've got a big project ahead of yourself :)
<WoC> ppc64el is incompatible
<WoC> aye, ust trying to find out if there is already some tools for it
<WoC> the Machine i got is a Dual cpu power mac g5
<sarnold> WoC: wild guess time, try adding [arch=ppc64el] deb-src http://ports.ubuntu.com/ubuntu-ports/ ...
<sarnold> then you might be able to use apt-get source ... to download the packages to the current working directory
<sarnold> (is the arch bit even needed? hrm.)
<WoC> ty, i'll try
<WoC> hopefully it wont cross compile to ppc64el
<sarnold> WoC: btw if you just want a working system, adelie linux has gone to some effort to support BE
<WoC> Oh, never heard of, link ?
<sarnold> WoC: https://www.adelielinux.org/about.html
<WoC> ty
<WoC> I do run ubuntu on all my other computers, so I would really like to run it on the G5 as well, but not as a 32 bit system
#ubuntu-devel 2018-11-09
<WoC> E: Type '[arch=ppc64el]' is not known on line 11 in source list /etc/apt/sources.list
<sarnold> does anyone know who "owns" https://help.ubuntu.com/lts/installation-guide/powerpc/index.html  ? it calls power4 "recent".  Isuspect the whole thing is useless at this point..
<sarnold> WoC: okay, try removing the [arch=ppc64el] bit ..
<WoC> sarnold, G4 ?
<mwhudson> no https://en.wikipedia.org/wiki/POWER4
<mwhudson> Installing Ubuntu 18.04 âBionic Beaverâ For powerpc <- um, installing ubuntu 18.04 on an architecture it's not built for?
<sarnold> mwhudson: yeah. probably the whole guide ought to be nuked..
<mwhudson> sarnold: seems like it
<sarnold> at first I was annoyed by the "powerpc" entry on z/OS line .. but that's the least of the problems on that page, I think :)
<stokachu> stgraber: hey, is there some sort of setting i can apply so that my lxdbr0 doesn't keep resetting it's MTU back to 1500?
<stokachu> i need it to persist at 1458
<WoC> Is there a handy dandy guide for how to setup for cross compiling ?
<sarnold> hmm. the cross-gcc-dev package looks like it's supposed to help set up the environments. I've never tried it though :/
<WoC> ty ty ty sarnold
<sarnold> oh maybe that just lets you build the packages that are already in teh archive, like gcc-7-powerpc-linux-gnu
<WoC> E: Unable to locate package cross-gcc-dev
<sarnold> odd, but probably it was the wrong path to suggest :)
<WoC> Found a guide; https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
<stgraber> stokachu: bridge.mtu
<JanC> """This package provides the rules and scripts for making cross-toolchain packages. It can also be used directly to make cross-toolchains that are not packaged for the archive."""
<JanC> so cross-gcc-dev in cosmic seems like it would help with what you want
<WoC> JanC, wouldnt have the ppa for that ?
<WoC> Builds
<WoC> ï¿¼ amd64
<JanC> like I said, it's in cosmic (Ubuntu 18.10)
<WoC> could be why i dont see it
<WoC> JanC, is there a simple way to upgrade from 18.04 to 18.10 without wiping the current install ?
<sarnold> do-release-upgrade -- maybe do-release-upgrade -d
<JanC> or do it in the GUI when you use that
<WoC> o-release-upgrade -d
<WoC> Checking for a new Ubuntu release
<WoC> Upgrades to the development release are only
<WoC> available from the latest supported release.
<sarnold> then just do-release-upgrade :)
<WoC> do-release-upgrade
<WoC> Checking for a new Ubuntu release
<WoC> No new release found.
<WoC> JanC, how do you do it in the gui ?
<JanC> you might have to change the setting from LTS-only to all releases
<WoC> oh
<sarnold> /etc/update-manager/release-upgrades
<jbicha> don't use  -d   that will get you Disco 19.04 which is in early alpha
<WoC> ty, seems to work w/o -d
<WoC> just a bunch of new updates 1st
<stokachu> stgraber: thanks
<mwhudson> this is a new one: a setup.py that manages to link it's 3.7 extensions to libboost_python27.so
<sarnold> 3.7 2.7 who'll notice the difference? :)
<mwhudson> mr segfault notices it seems
<sarnold> quick call dr watson!
<stokachu> stgraber: lxc network set lxdbr0 bridge.mtu 1458 right?
<stokachu> ip link list shows lxdbr0-mtu and lxdbr0, is that expected?
<mwhudson> coreycb, jamespage: would anything bad happen if we synced src:bandit from debian?  (also Someone(tm) should fix it so it depends on python3 not the python3X it was built with...)
<stgraber> stokachu: yep because you can't set the mtu on an empty bridge, so that device is created just to force the bridge mtu to line up
<mwhudson> haha brilliant it now ftbfs on all arches _except_ amd64
<stokachu> stgraber: ack thanks, in the end lxdbr0 will have correct mtu set?
<stgraber> stokachu: yeah, the bridge should take the mtu of the interface with the lowest one
<stokachu> stgraber: 10-4, thanks again
<mwhudson>     libdirs = user_libdirs+[os.path.join(sys.prefix,'lib'),'/usr/local/lib', '/usr/lib','/usr/lib/x86_64-linux-gnu']
<mwhudson> OH YOU EFFING WAHT
 * mwhudson rages
<WoC> upgrade to 18.10 good so far ;] I just hope it doesnt infect my system with nouveau
<foua> hi! what's the recommended way of creating/building a package which works with both upstart and systemd?
<foua> or is the recommended way to side-step the question and build a separate package for each system?
<tjaalton> foua: man dh_installinit
<foua> tjaalton: had a look there --- but the package still ends up with _both_ sysv-rc and init-system-helpers dependencies
<tjaalton> foua: so you have d/package.init?
<foua> tjaalton: I don't, no -- I have d/{service}.upstart and d/{service}.service
<tjaalton> does the upstream install something in etc/init.d?
<foua> the run/install-time dependencies of the package is only `Depends: ${misc:Depends}` --- so it shouldn't be
<foua> worth mentioning is that I use compat 9
<tjaalton> didn't answer the question
<foua> tjaalton: not sure I understand what you mean with `upstream` here in that case
<tjaalton> upstream sources
<tjaalton> actually looks like it's a feature of compat 9
<tjaalton> bump it to 10
<coreycb> mwhudson: bandit should be safe to sync. i don't think we even use it tbh.
<coreycb> mwhudson: i'll work on it and make sure it's ok to sync
<tarzeau> https://popcon.ubuntu.com/ the links of the archs link to dapper... is that 10 years ago?
<tarzeau> shouldn't ubuntu either support p.u.c and the package right, or just drop it?
<ginggs> dapper dingo
<tarzeau> i thought it's disco?
<ahasenack> hi, this sru has a verification-failed tag. I fixed the problem and uploaded a new package just now, should I just remove the verification-failed tag? What about the verification-needed one?
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1795772
<ubottu> Launchpad bug 1795772 in samba (Ubuntu Bionic) "rmdir on non-empty samba directory fails silently" [High,In progress]
<ahasenack> rbasak: as an sru team member :) ^
<rbasak> ahasenack: leave the failed tag there please. When the replacement is accepted by the SRU team, the tags will get reset correctly by the script.
<ahasenack> ok
<rbasak> That way it won't show up as green in the pending-sru report in the meantime, which would be bad.
<ahasenack> even if verification-needed was also removed?
<rbasak> I'm not sure exactly what the report does with both failed and needed present
<ahasenack> I just don't want it to be ignored
<rbasak> Or needed gone but no failed
<ahasenack> i.e., someone sees the upload, glances at the report, it's red because of verification-failed, nothing to do
<ahasenack> something like that
<smoser> xnox: around ?
<smoser> looking for systemd related help at https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1802354
<ubottu> Launchpad bug 1802354 in open-iscsi (Ubuntu) "iscsid does not run if there are only initramfs initiated targets" [High,Confirmed]
<xnox> smoser, yeah.
<xnox> smoser, *host* service => is that client or server side?
<smoser> the answer to the question i *think* you're asking is 'server'.
<xnox> smoser, tah.
<smoser> basically any time we have an iscsi mount we want iscsid to be running.
<xnox> true
<smoser> if it isn't running, and the iscsi server on remote-system gets restarted
<smoser> then our system might fall over
<xnox> which on my books means a udev rule with ', SYSTEMD_WANTS=iscsid.service"
<xnox> such that such mounts (actually systemd .device autogenerated unit) starts iscsid.service.
<smoser> oh. on the disk
<smoser> but "wants" ?
<smoser> i think this is convoluted by the .scoket
<smoser> err.. .socket
<smoser> will the wants result in the *service* running? rather than the .socket ?
<xnox> i hope that iscsid.service; has After=iscsid.socket Wants=iscsid.socket => such that starting iscsid.service, actually starts socket and the service, with socket passed to the service
<xnox> thus the answer to your quextion, is the result is that *both* service and socket are running.
<xnox> but
<smoser> well, no
<xnox> we don't run systemd inside initramfs; and hopefully replug post initramfs does start these things.
<xnox> i guess look at mdadm udev rules and systemd units.
<smoser> right. thats something to check.
<xnox> by default no units are running at all; and the mdmon@ units are started purely from udev rules.
<xnox> and because of lack of systemd, initramfs does its own thing.
<smoser> ok. wants=iscsid.service, compared to just 'iscsid'. that makes sense.
<smoser> but the cold plug may trigger
<smoser> which woudl be sufficient.
<xnox> yeap
<xnox> well. `naked` unit name, results in `.service` appended. but i preffer full unit names everywhere.
<smoser> that makes sense.
<smoser> ok. i can play with udev rules.
<smoser> but then ... this is all much more complicated
 * smoser is somewhat frustrated that this change was pushed in to fix a "bug" of a service running that wasn't necessary.
<smoser> so i'm not thrilled about more moving parts
<smoser> xnox: also.. what about a container? no udev there.
<xnox> smoser, explain.
<smoser> well, if the only way we run iscsid.service is through udev
<smoser> then in that case, where there were non-"open-iscsi.service" created iscsi mounts, we would not get iscsid to run
<smoser> but i suspect /sys/class/iscsi_session is not namespaced anyway
<smoser> so thats probably a good thing
<xnox> smoser, and how would those mounts appear? from initramfs -> but there isn't one. If they came from the host? then the host should be running iscsid, not the container.
<smoser> right. yes, from the host is what i was suggestiong.
<smoser> in the container creationo.
<smoser> andyou're right, then the host's iscsid coudl/should be doing it.
<coreycb> mwhudson: i've synced bandit and requests. bandit needs python-hacking to build successfully but it's ftbfs. I think fixed by the requests sync - rebuilding atm.
<smoser> xnox: still there?
<smoser> never mind. sorry for current ping mioght bother you later.
* infinity changed the topic of #ubuntu-devel to: Archive: Open | 18.10 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Cosmic | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<WoC> is there an easy way with apt/dpkg to force a reinstall of two specific packages w/o regarding dependence's ?
<xnox> WoC, sudo apt install --reinstall foo bar
<xnox> does that not do what you want?
<xnox> or if you have specific debs you can allo do
<WoC> checking
<xnox> $ sudo apt install --reinstall ./foo_1-3_amd64.deb
<xnox> note the './' ie. full path
<xnox> just "foo_1-3_amd64.deb" will not work
<WoC> Nope, the packages are; cacti & cacti-spine
<WoC> i can not seem to purge
<WoC> broken
<xnox> well, this is not a support channel, and without seeing the output of your system, it's hard to blindly guess and recommend things.
<xnox> but yes, apt/dpkg need to be in a consistent state first.
<WoC> is there a way to erase them from the list of installed packages ?
<xnox> ....
<xnox> please use pastebin, to paste what's the output from apt?
<WoC> k
<xnox> one can like | pastebinit
<xnox> `| pastebinit` is very handy
<WoC> http://paste.ubuntu.com/p/rwrNjQH9f4/
<WoC> this is after do-release-upgrade, btw
<WoC> 18.04 -> 18.10
<WoC> i want you to know, i really appreciate your help
<Faux> Whatever you do, don't go put "exit 0" at the top of /var/lib/dpkg/info/cacti*.prerm. That wouldn't be an approved solution at all.
<Faux> Oh, luckily that was ages ago and they left.
#ubuntu-devel 2018-11-10
<mwhudson> coreycb: ta
<WoC> xnox, had to wipe the entire installation and reinstall ubuntu... well, now i know not to ever install cacti again for any reason
<WoC> say, xnox is there any guide to mk-sbuild ?
<WoC> i only get to the; * Before continuing, you MUST restart your session to gain "sbuild" group permissions! *
<cjwatson> you didn't have to reinstall, people tried to give hints after you left IRC
<cjwatson> https://wiki.ubuntu.com/SimpleSbuild
<cjwatson> and yeah, you either have to restart the session at that point or else 'newgrp sbuild', quirk of Unix
<WoC> oops, i thought it was the cross compile session, lol
<WoC> ty ;]
<WoC> so with some luck and fair winds i may have a ppc64 18.10 ;)
<WoC> actually, was a good thing i did reinstall... clean now ;] the original install was 14.05 i think
<WoC> or 12...
<cjwatson> that's fine if it's managed well :)
<WoC> dang... E: Unable to locate package libc-dev:ppc64
<cjwatson> my laptop was installed from a 13.04 alpha; my server with Debian either slink or potato, I forget
<WoC> well, i ponder on that later.. 0312 here, bed time... Well, can
<WoC> not say it was well maintained ;)
<cjwatson> I assume you have a build daemon of some kind already set up since otherwise this'll be extremely tedious
<cjwatson> and a local repository
<WoC> working on that :)
<WoC> i do have a actual ppc64 running though
<WoC> but right now it runs 16.04
<WoC> gn
<WoC-> seems like precise, would have worked for the cross compile with mk-sbuild, but the precise version of dpkg does not have --add-architecture and one need to add the --debootstrap-no-check-gpg
<WoC-> ;P
<WoC-> edited the mk-sbuild to use the --foreign-architecture
<WoC> did --foreign-architecture in precise require it to be used per pkg ?
#ubuntu-devel 2018-11-11
<WoC> well, problems solved, FreeBSD istalled, 64 bit kernel and 64 bit userland
<xnox> ehhhhh
<xnox> oh he left.
<xnox> clearly did not find `$ mk-sbuild --arch ppc64el` option to setup a cross-compilation chroot.
<xnox> oh well.
<PenguinPerk> Looking for a hand. I am running Ubuntu 18.04 and i need to install docker 18.06? This isn't working "apt install docker-ce=18.06.1"
<infinity> PenguinPerk: This isn't a support channel, and "docker-ce" isn't a package in the Ubuntu archive.  docker.io is at 18.06.1 in xenial and bionic, though.
<infinity>  docker.io | 18.06.1-0ubuntu1~18.04.1     | bionic-updates/universe  | source, amd64, arm64, armhf, i386, ppc64el, s390x
<mwhudson> only in proposed for xenial so far but yeah
<mwhudson> coreycb: extremely unimportant q, can python-pika-pool be synced?
<TJ-> Trying to build apt from upstream git repo, on 18.04, and getting "dh_auto_configure: unable to load build system class 'cmake+ninja': Bareword "ninja" not allowed while "strict subs" in use at (eval 2) line 1." - any ideas whether this is a bug in debhelper or else the apt debian/rules which has "dh $@ --buildsystem=cmake+ninja" ?
<cjwatson> TJ-: I mean, maybe apt?  But I'd go for debhelper anyway if only because that's a weird error message.
<TJ-> cjwatson: yeah; the latter part "Bareword..." is from Perl rename as far as I can tell
<cjwatson> What?  No.
<cjwatson> It's from 'eval "use $module";' in debhelper's Debian::Debhelper::Buildsystem module
<cjwatson> But what version of debhelper do you have installed?
<TJ-> maybe what I should have said is, it's from Perl and most reports of it I found were related to rename :)
<cjwatson> I reckon you're ignoring Build-Depends, and this is what you get for doing so.
<cjwatson> apt build-depends on debhelper (>= 11.2~) precisely because 11.2 added support for the cmake+ninja buildsystem.
<cjwatson> 18.04 has an older version than that
<cjwatson> So nobody's bug, in fact - if you're backporting then you need to work out how to make the backport work, one way or another
<cjwatson> (I usually advise working out how to back out the dependency on newer debhelper because backporting debhelper can often be complicated, but I don't know how hard that is in this case)
<TJ-> ahhh! I was trying to use upstream repo in order to develop a wrapper for method/gpgv
<xnox> PenguinPerk, docker-ce sounds like something provided by docker upstream maybe? what does this say $ apt-cache show docker-ce
<xnox> PenguinPerk, maybe contact whoever provides that repository about more info.
<PenguinPerk> ty xnox
<xnox> mwhudson, done.
<mwhudson> xnox: looks like the livecd-rootfs change fixed live-server builds at last
<mwhudson> https://launchpad.net/~mwhudson/+livefs/ubuntu/disco/live-server-test/+build/149595
<xnox> mwhudson, well i knew it will fix it, cause i pretested in ~xnox build too ;-)
<xnox> hopefully the morning will pop the proper images out
<mwhudson> xnox: ah nice
#ubuntu-devel 2019-11-04
<ejat> hi .. anyone can take a look into this bug
<ejat> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1772683
<ubottu> Launchpad bug 1772683 in libreoffice (Ubuntu) "[snap] Cannot sign a document, gpg keys are not listed" [Medium,Triaged]
<xnox> doko:  so, not so fast with django, need to fix 5 more packages or so =/
<doko> that's what I thought ...
<xnox> doko:  if i do $ tox -e py37 => during a package build, it works. But if I do $ tox -e py38 => it does not.
<xnox> doko:  are our wheels off the wheels somehow?
<cjwatson> Any time I've tried to use tox in a package build, I've ended up giving up and using some other test runner instead
<cjwatson> And finding that roughly nothing else in the archive is using tox in package builds
<cjwatson> It's great upstream, I use it nearly everywhere I can, so this seems like a bit of a shame
<xnox> cjwatson:  all i need is to make pybuild execute ./runtests.py and i naively thought that PYBUILD_TEST_TOX=1 will make it so
<cjwatson> Yeah, I've naively thought that multiple times
<cjwatson> But survey has always said no
<xnox> i've added all the things I need into - debian/pybuild.testfiles
<xnox> but failing to force pybuild to use a "custom" test runner
 * xnox will just override the dh_auto_test i guess
<doko> xnox: you'll have to ask the pybuild developer, and persist after his initial "see pybuild(1)" reply
<doko> or "it's in the man page"
<xnox> i'm ended up doing
<xnox> override_dh_auto_test:
<xnox>         pybuild --system=custom --test --test-args='python{version} runtests.py'
<xnox> doko:  but it does seem like something is broken with tox, in focal for py38 at the moment.
<xnox> and it's pip usage
<doko> xnox: looking at the upstream git, I can't see any 3.8 specific issues, however a 14.x release seems to be planned
<doko> and tox didn't migrate yet due to an arm64 autopkg test failure
<xnox> doko:   i don't see any issues in tox itself, but in its inability to find a python3.8 pip when initializing 3.8 env
<doko> xnox: hmm, why not? that's arch-indep. or is this marked as 3.7 only?
<xnox> doko:  for example, pyvenv-3.8 does not exist
<xnox> doko:  i thought tox creates a venv, and needs 3.8 wheel for pip, no?
<cjwatson> Even if you fix that, IIRC the usual problem with using tox in package builds is that it tends not to have the pile of sdists it needs available to build the rest of the virtualenv
<cjwatson> sdists or wheels
<cjwatson> I think there was some problem with using system-site-packages too any time I tried, but don't remember what it was
<cjwatson> Possibly trouble locating tests or something
<xnox> sure, i'm not planning to use tox in the package build anymore. It's just I suspect our py3.8 as supported, is incomplete in the archive w.r.t. venvs.
<xnox> whilst 3.7 works
<xnox> hm, outside of chroot, on the host, it works.....
<doko> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/n/natsort/20191104_094524_acaa7@/log.gz
<ahasenack> rbasak: hm, I'm having an interesting problem with mysql8 in focal, due to fakeroot
<doko> cjwatson, xnox: ^^^ so that downloads everything, and ignores everything in the distro ...
<ahasenack> rbasak: d/rules calls out to d/setup-mysql.sh, which has:
<doko> trying to understand what is getting tested
<ahasenack> https://pastebin.ubuntu.com/p/Cr7wGg5NcH/
<ahasenack> due to fakeroot, id -u returns 0, so it thinks it's running as root
<ahasenack> then it does: + chown mysql: /home/ubuntu/git/packages/php7.3/php7.3/mysql_db
<cjwatson> doko: Right, I think the only legitimate way to use tox in a package build would have to use --system-site-packages or however it's spelled
<cjwatson> As opposed to upstream where you probably don't want that
<ahasenack> and starts mysql, which fails: mysqld: Can't create directory '/home/ubuntu/git/packages/php7.3/php7.3/mysql_db/data/' (OS errno 13 - Permission denied)
<ahasenack> hm, mysql shouldn't have been able to switch users, so it's still running as my build user... hmm....
<xnox> cjwatson:  is there CI running on launchpad pull requests? or do I need to run things locally myself?
 * xnox hasn't done a launchpad merge request in ages
<cjwatson> Locally
<cjwatson> We do post-landing CI but that's not what you want for making sure your MP is good
<cjwatson> If you have an old tree lying around, note that we're on git now
<cjwatson> For what I imagine you're doing, "bin/test -vvct lp.snappy" shouldn't take too long
<rbasak> ahasenack: this is the PHP 7.3 FTBFS, or something else?
<ahasenack> rbasak: that one, yes
<rbasak> I thought Marc had resolved it?
<rbasak> He pasted a solution somewhere
<ahasenack> just wondering if you have seen that before, and also wondering how it worked before, but I've heard people comment that the tests were never run before correctly
<rbasak> Or am I mixing things up?
<ahasenack> rbasak: he disabled the tests in the end he said
<rbasak> Ah
<ahasenack> I'm going into more detail now
<rbasak> No I've never really delved into this area
<rbasak> I usually defer to Skuggen for this kind of thing :-)
<doko> cjwatson: ouch, this test doesn't even test the built package, but downloads the package zip file from the net ;p
<cjwatson> I'm not surprised
<cjwatson> xnox: If you have trouble running the tests then I don't mind running them here for something simple like that branch
<ahasenack> rbasak: it's the apparmor profile that's denying mysql's datadir in that directory
<ahasenack> [Mon Nov  4 13:22:00 2019] audit: type=1400 audit(1572873722.995:988): apparmor="DENIED" operation="mkdir" namespace="root//lxd-andreas-focal-php73-mysql8_<var-snap-lxd-common-lxd>" profile="/usr/sbin/mysqld" name="/home/ubuntu/git/packages/php7.3/php7.3/mysql_db/data/" pid=18671 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1001000 ouid=1001000
<rbasak> Ah!
<ahasenack> rbasak: don't know yet how it was working before, afaik this profile is enabled by default
<rafaeldtinoco> infinity: would u mind approving bionic sru for https://bugs.launchpad.net/ubuntu/+source/sg3-utils/+bug/1833618 ?
<ubottu> Launchpad bug 1833618 in sg3-utils (Ubuntu Bionic) "MAAS can't deploy Ubuntu if ID_SERIAL of any block device is broken (USB pendrive in this case)." [High,In progress]
<rafaeldtinoco> i just verified disco (ok to migrate) but bionic hasn't been approved to -proposed yet.
<rbasak> ahasenack, bryce: so I think I'm finally ready with the importer test branch originally from Nish. I've resubmitted his MP, which means that Andreas is already listed as a reviewer. I added Bryce. I don't mind who reviews but I think it'll probably be Bryce?
 * ahasenack thinks so too
<infinity> ahasenack: I don't recall who on your team had context the last time (years ago?) I whined about this, but is there any intend to fix the "squid halts shutdown forever" bug for the upcoming LTS?
<ahasenack> infinity: I could be convinced to work on it, I have a card even
<ahasenack> infinity: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898469 right?
<ubottu> Debian bug 898469 in squid "Squid waits on shutdown even though there are no active clients" [Normal,Open]
<infinity> ahasenack: That's the one.
<infinity> ahasenack: I like the comment about "squid 3.4 blah blah" and we're on 4.8
<infinity> ahasenack: I imagine it's a pain point for people who run all the squids ever in clouds and grump at slow instance reboot times, but for people like me, it's totally squid-deb-proxy making my laptop take forever to reboot that drives me nuts. ;)
<infinity> ahasenack: I guess I could mask the service to just shoot it in the head, but then I'm ignoring a bug that affects others, which I tend to prefer not to do.
<ahasenack> infinity: I've been using it with a lower setting for shutdown_lifetime
<infinity> ahasenack: See above, re: ignore bug that affects others. :)
<ahasenack> but I also every now and then get an error about it failing to fetch an object from the cache, and I wonder if some corruption is happening
<ahasenack> yeah< i mean that his recommendation of just lowering that value is probably not correct
<infinity> I remember looking into it and, indeed, there's an intricate maze of fds and sockets it needs to close to shutdown cleanly, but there must be some way when that's done to signal "I got it all!" and then end the process, instead of just waiting and hoping for the best.
<infinity> I mean, even the 30s timeout could be too short for some instances, while being too long for most.
<ahasenack> correct
<ahasenack> I'll try reaching out again
<ahasenack> not in that bug, though, something different
<infinity> Telepathy?
<sarnold> I've always wondered why it cares to shut down cleanly. clients and servers ought to be prepared to get RSTs at crazy times. I don't know why it doesn't just _exit(0) and be done with it. harumph.
<infinity> sarnold: Upstream's argument is that it isn't about shutting down client connections, it's about shutting down internal sockets/fds cleanly to avoid corruption of data, logs, etc.
<infinity> sarnold: Still seems like a piss-poor argument for what amounts to poor design choices, IMO.
<sarnold> infinity: I'm not too shocked that a program designed so long ago has such poor design choices, but even then, I'm not sure how a graceful cleanup would take more than half a second on the typical dev laptop, or maybe two seconds on a busy system..
 * infinity nods.
<infinity> sarnold: And, to be clear, it probably *is* only taking half a second or less on my laptop.  But, because they've entirely failed to write a way to record and signal a clean shutdown, the whole thing just sits in a wait loop and then hard muders itself with hope and bunnies.
<sarnold> and "rewrite it with sqlite3 so we don't have to think so hard about corruption" is probably a fair amount of work
<infinity> sarnold: So, for 99% of people, it's waiting 29 seconds too long, for 1%, it's still not shutting down cleanly.
<sarnold> hah
<sarnold> and to think this is the caching thingy that gave me the *least* amount of trouble
<infinity> Yep.
<infinity> rafaeldtinoco: I don't see an upload of sg3-utils in bionic's queue, so not much for me to review...
<rafaeldtinoco> :/ I thought it was sponsored already, will check, sorry for the noise
<infinity> dannf: Feel free to JFDI on the versioning fix if that's all you're waiting on to sponsor sg3-utils.
<ahasenack> sarnold: infinity: what other cacheing proxy servers are out there? Anything promising that you know of?
<ahasenack> "apt-cache search proxy | grep cache" isn't encouraging
<dannf> infinity, rafaeldtinoco ack
<sarnold> ahasenack: apt-cacher-ng was the one that gave me trouble, endless chasing hash sum mismatches. funny thing is, I know folks who've switched from squid-deb-proxy to apt-cacher-ng because squid gave them the hash sum mismatches..
<ahasenack> ok, but that's just for debs anyway
<ahasenack> I get hash sum mismatches on mirrors directly even
<infinity> Really?  Still?
<infinity> I haven't seen one since we switched to by-hash indexes.
<ahasenack> yeah, the br mirror every now and then
<ahasenack> I do have a proxy, but when I get that, i disable it, clean run apt get update, and it fails
<ahasenack> then I switch to archive.u.c
<infinity> sarnold: My complaint with apt-cacher-ng is that over time, it seems to corrupt its data just enough that the weekly cronjobs end up whining until you delete it all and start over.
<infinity> Maybe that's fixed now, but I gave up and switched to squid and didn't look back.
<sarnold> same here, squid's been a lot better for me, just the shutdown / reboot experience is bad news :)
<infinity> Plus, squid is dogfooding an actually useful proxy server that thousands/millions use for all sorts of things, apt-cacher-ng is weird boutique software just for nerds like us.
<ahasenack> kanashiro: your target branch in your MPs for merges from debian is incorrect, it should be debian/sid
<ahasenack> that's why you have conflicts on those mps
<kanashiro> ahasenack, ah, just noticed this... fixing them now
<kanashiro> thanks btw
<ahasenack> np
<rafaeldtinoco> dannf: thx for the version fix
<rafaeldtinoco> dannf: should I do something or u have already uploaded ?
<dannf> rafaeldtinoco: np - its here now: https://launchpad.net/ubuntu/bionic/+queue?queue_state=1
<rafaeldtinoco> great. thx!
<melodie> hi
<ahasenack> kanashiro: what cpaelzer and I do sometimes when a merge becomes a sync is to just file an MP anyway, showing that all delta can be dropped, for review purposes
<melodie> I have used a few commands in the shell to try to get which package contains the /etc/passwd file and I didn't find any. I would like to know who is in charge of this file in the *ubuntu editions?
<melodie> I have a premice related to computing and digital skills and I found a sensitive bug in one of my client's computer. So I'd like to send a mail to the right person
<ahasenack> melodie: it's created in base-passwd's postinst
<melodie> ahasenack thanks, let me see
<dax> which also means it doesn't show up in the output of the usual "which package owns this" tools, because it's generated, not installed
<ahasenack> or rather, preinst
<rbasak> melodie: please don't just email the maintainer of base-passwd though
<melodie> I should find a mail in the output of apt-cache show base-passwd I think?
<melodie> rbasak why that? Who then?
<rbasak> melodie: if you think you found a security bug in base-files package, please file a bug and mark it as either Public Security or Private Security as appropriate.
<melodie> aha
<melodie> let me have a look at the lauchpad bugs section
<kanashiro> ahasenack, re a merge becoming a sync: nice, I'll submit a MP for review purpose
<rbasak> melodie: because we use bug trackers to track issues so we can work on them collectively - private email is usually inappropriate for matters relating to public work like this
<melodie> good to know
<melodie> I see, maintainer shows Colin Watson. I'll do as you say and search for a "Private Security" option
<melodie> I guess Colin Watson might have his plate full :D
<rbasak> melodie: and also for security matters Ubuntu has a security team who are on a rota. For all you know, Colin is on vacation (though he isn't as it happens) :)
<melodie> never mind rbasak everyone deserves his vacation, even if still here online
<rbasak> :)
<melodie> :)
<melodie> rbasak ahasenack this is bug #1851300
<ubottu> Error: Launchpad bug 1851300 could not be found
<melodie> and thanks for your help!
<melodie> ok ubottu bot, https://bugs.launchpad.net/ubuntu/+source/base-passwd/+bug/1851300
<infinity> melodie: The bot can't find it because it's private. :P
<sarnold> one moment..
<melodie> infinity I thought so
<infinity> /etc/passwd shouldn't have passwords in it at all, plain or hashed.
<sarnold> melodie: how did this user change the password on her system?
<infinity> And there's no way in our default installations for that to happen.
<infinity> Gonna need a lot more info to figure out who/what did that. /
<infinity> :/
<melodie> sarnold she didn't. She is an old lady who would never be able to do that. An the "computer tech" who installed probably just did an regular install not complicated, through the install option in the live
<melodie> I can tell as I have had several clients coming to me after served at his shop
<infinity> I suspect you'll need to ask this "tech" how he's setting up user accounts.
<infinity> He might be imaging systems and then echoing users/passwords into /etc/passwd or something equally insane.
<melodie> infinity what I might be able to do: see if I shows again in other Xubuntu 18 installs
<melodie> I perform some, once a while, as tomorrow I have one scheduled
<melodie> if it shows again*
<melodie> infinity not possible, he is a very simple tech who performs simple services
<melodie> I can't ask him. He is a "lone wolf" kind of guy :D
<melodie> still I don't fancy this guy doing crazy technical things, he doesn't use his time this way. He just wants to earn money and provide not too expensive services (even if he does not understand well the ins and outs in at gnu/linux distribution)
<infinity> melodie: You say that's not possible, but I'm telling you that the scenario of "no one ever changed the password after ubiquity created the user" can't possible lead to anything in /etc/passwd other than "x"
<infinity> melodie: I'd be open to the idea that some random xfce utility for user/password changes has done something very bad.  Or that the tech doing the install did something silly.
<infinity> But if she didn't change it, and he didn't do it weird, we're at a bit of an impasse.
<melodie> infinity all I can do is report a bug which I have recently seen, and when possible have a close look to see if it pops up again
<melodie> and I have read a few years ago that this issue already arised once, in Ubuntu which was then fixed.
<melodie> so I don't want to raise concerns among the users, I want it to be checked and looked closely. nothing more.
<infinity> melodie: Err, when was this issue?
<melodie> I am proud of being a GNU/Linux user, which I started almost right away after I got my first computer, 15 years ago.
<melodie> infinity I met with it a few days ago.
<infinity> melodie: I meant your claim that you "read a few years ago..."
<infinity> melodie: I don't recall ever having a "clear text passwords in /etc/passwd" issue.
<melodie> infinity this one, I don't remember
<infinity> Not that we haven't had other issues, like passwords in log files (in 2005!) and wifi passwords in clear text...
<melodie> I do remember about it
<melodie> anyway I have always read that a security issue in a free software should first be brought to the people in charge of the concerned software, in order to get a fix for everyone before anything else
<melodie> now, if you will all excuse me, I have to get up early tomorrow, I'll be back for more if I find more clues or other examples of this issue.
<melodie> thanks for your help.
<sarnold> thanks melodie :)
<melodie> so, good night/week/evening...
<melodie> sarnold welcome. :)
<Phruis> where is the code linux uses to save its state on hibernation?
<teward> slashd: FYI the nginx upload was accepted and has been in focal for a bit now, and should Just Work now for the nginx IPv6 stuff, please double check, my tests seem to reflect it's fixed but a second set of eyes and tests never hurts :)
#ubuntu-devel 2019-11-05
<sarnold> Phruis: this is a good starting point https://elixir.bootlin.com/linux/latest/source/kernel/power
<sarnold> Phruis: each architecture is also going to have arch-specific code too https://elixir.bootlin.com/linux/latest/source/arch/x86/power
<xnox> infinity:  thank you for your klibc upstream comments.
<Phruis> sarnold, thanks
<seb128> ddstreet, hey, do you plan another bionic/n-m SRU? I need to do one for a fix but I saw you have bug #1850267 in progress
<ubottu> bug 1850267 in network-manager (Ubuntu Bionic) "autopkgtest 'nm' fails because it can't find dnsmasq" [Low,In progress] https://launchpad.net/bugs/1850267
<xnox> doko: thank you for removing the requested python2 django things
<xnox> doko:  i actually think there might be more to remove..... some of them smell like ex-Ubuntu1 team shipping things they use in production, which they don't anymore.
<xnox> doko:  btw, i think to migrate mailer & piston, i need AA to remove _binaries only_ of python-django-mailer python-django-piston3
<xnox> because they are now only python3-django-mailer and python3-django-piston3
<xnox> (dropped python2 packages)
<doko> xnox: django-piston3 ftbs in -proposed
<xnox> ah
<xnox> doko:  eh?! https://launchpad.net/ubuntu/+source/django-piston3/0.3~rc2-3ubuntu9
<xnox> doko:  it was in error an arch:any package, changed to arch:all package
<xnox> so it claims to be "missing" on all arches
<xnox> but it totally did build
<doko> ahh, I see
<xnox> i don't know what AA need to do when a package goes from arch:any to arch:all
<doko> silly britney
<xnox> doko:  some of the packaging in these is beyond silly too. So never mind britney.
<xnox> doko:  but python-django-piston3 binary needs to be removed, which was arch;any and now is fully gone
<xnox> doko:  and that is the one that britney correctly complains about
<xnox> (not the python3 one)
<xnox> so actually it's complaining about the dropped arch:any python2 package
<xnox> doko:  django-ratelimit is actually miss-upload, and should be removed src from -proposed just like you already removed from release.
<doko> .
<gpiccoli> hi rbasak, can we discuss LP #1847924 when you have some minutes? Thanks!
<ubottu> Launchpad bug 1847924 in mdadm (Ubuntu Focal) "Introduce broken state parsing to mdadm" [Medium,In progress] https://launchpad.net/bugs/1847924
<xnox> gpiccoli:  my biggesst worry about that one is "degraded boot" however that also makes no sence in raid0 case =)
<gpiccoli> hey xnox! Yeah, I don't think the patch could cause degraded boot, it could cause in worst case, for example, a failure in a parsing tool for raid0 status if that doesn't cope with broken state hehe
<gpiccoli> in order to patch getting "triggered", raid0 must be already in a bad state
<ddstreet> seb128 i don't have anything else for nm, feel free to take that bug, i'm pretty sure it only needs dnsmasq-base added to the test/control file Depends: for that test.  thanks!
<seb128> ddstreet, thanks!
<ahasenack> infinity: hi, there is no verification tag to flip in bug https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1849665
<ubottu> Launchpad bug 1849665 in zfs-linux (Ubuntu Eoan) "zfs diff: Unable to determine path or stats for object " [Undecided,Fix committed]
<ahasenack> I can of course add one, but did the script fail?
<ahasenack> the sru script that adds the comment with instructions, I mean
<rbasak> gpiccoli: o/
<gpiccoli> o/ rbasak
<rbasak> Thank you for your reply in the bug
<gpiccoli> You're welcome, thank you for the valid concerns!
<rbasak> gpiccoli: so on the first point, I'd like the Regression Potential section to detail where regressions are most likely to occur in order to inform review and testing.
<rbasak> THat's documented at https://xdsports.uk/weight-belt
<rbasak> Uh
<rbasak> https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<rbasak> On the second point, I'm hoping to reduce the scope in worrying about the impact to consumers of mdadm
<gpiccoli> hehe sure rbasak, I'll add the Regressions Potential! my bad not adding before
<rbasak> Is it possible/correct to state that, if an array is not in the new failed state, the observable behaviour for a user of mdadm will be the same in all cases following the patch?
<rbasak> s/the same/exactly identical/
<gpiccoli> rbasak, it should, but to be completely accurate with you, I'll check all states and a comment in the bug, showing it doesn't change (except for broken), or, if changes, how so
<gpiccoli> *add a comment
<rbasak> gpiccoli: that would be useful - thanks!
<gpiccoli> Just to speed up things,
<gpiccoli> what if it changes?
<rbasak> With that knowledge we can reduce the scope of what we need to consider.
<gpiccoli> ok - perfect
<rbasak> If it changes then we need to consider what consumes that
<rbasak> Eg. will we break some tool that parses mdadm output, such as monitoring tools?
<gpiccoli> great, makes sense!
<gpiccoli> after adding regression potential and such comment, I will ping you again, thanks a lot !
<rbasak> If the output is identical except in the new failed state, then that breakage would be limited to a failure that wasn't accounted for by the monitoring tool anyway, in which case arguably the new situation would be better anyway
 * xnox ponders if X should have a "clear after timeout" or like "clear after one paste" for all of the copy&paste functionality.
<rbasak> I swear I pressed Ctrl-C, and that this happens to me more often than what would be explained by user error
<rbasak> I suspect that Firefox has some condition when it doesn't actually copy.
<gpiccoli> makes sense rbasak, thank you o/
<xnox> rbasak:  i find that focus follows mouse interferes sometimes. I.e. copy only happens from a "focused" window.
<rbasak> gpiccoli: oh, one more point. On User Impact, right now it sounds like a theoretical bug only. Could you detail why we need an SRU? Are users hitting the problem in practice, for example?
<rbasak> It's OK if the answer is that it's theoretical but data loss is severe enough that you want to pre-emptively fix it.
<rbasak> But I'd like that documented if so
<gpiccoli> ok rbasak, thanks for the heads-up aboutthis
<rbasak> xnox: I think it does have something to do with focus change, though in my case I'm using pretty much entirely GNOME defaults on this.
<slashd> teward, I have tested on focal with ipv6 disable using nginx '1.17.5-0ubuntu1', and everything went well to that regard.
<seb128> bdmurray, hey, can you get the rygel/eoan SRU moved to -updates now rather than waiting for the full week period? the bug it fixes is rather important and it got properly verified
<xnox> coreycb:  hey, can you please explain to me the manila-ui 0ubuntu2 upload which says "d/control: Ensure python3-django is << 2:2.2.4." ?
<xnox> coreycb:  is there like a >> 2:2.2.X version that is also good? I'm trying to do migration to 2.2.6 in focal now.
<coreycb> xnox: hey, that should've been changed back to python3-django >= 1:1.11. it was an attempt that was later reverted but apparently not for manila-ui.
<coreycb> xnox: upstream openstack should be getting 2.2.4 support this cycle
<coreycb> xnox: bug 1842969 fyi. I'll fix that for manila-ui in focal and eoan though.
<ubottu> bug 1842969 in python-django (Ubuntu) "python-django 2.2.4 not for eoan" [Undecided,Fix released] https://launchpad.net/bugs/1842969
<xnox> coreycb:  so it needs this cherrypick too https://github.com/openstack/manila-ui/commit/83a0e432fe475a263c2f5e5337511db96263c3b8.patch
<xnox> coreycb:  but otherwise it builds..... i have a package ready and can just upload it.
<coreycb> xnox: ah, ok great. thanks just let me know when you do and i'll apply your debdiff to our master branch.
<xnox> coreycb: ack. If even that, cause it will not be needed with any new/next upstream release.
<xnox> coreycb:  also less than 1:1.11 is pre-xenial, imho such a version constraint is a bit redundant.
<coreycb> xnox:  i think you meant greater than, and I agree that's redundant
<xnox> yes and yes
<xnox> coreycb:  http://launchpadlibrarian.net/450008718/manila-ui_1%3A2.19.0-0ubuntu1_1%3A2.19.0-0ubuntu2.diff.gz if you must
<coreycb> xnox: thanks
<kanashiro> I git clone'd the python-tornado package using git-ubuntu and the content in ubuntu/devel branch is not the same in the archive (ubuntu/devel has 4.5.3-1 and in focal the version is 5.1.1-4ubuntu5 according to rmadison), did something go wrong here?
<kanashiro> rbasak, ^
<rafaeldtinoco> kanashiro: has the migration failed ?
<rafaeldtinoco> sometimes branch was updated, archive has the source package but it hasnt migrated yet due to excuses
<rbasak> mwhudson: pandas import done (at 12:19)
<rbasak> 2019-11-02 18:46:53|python-tornado|1572720413.91573|error|20
<rbasak> kanashiro: ^ looks like an import failure
<rbasak> The cause is bug 1764814
<ubottu> bug 1764814 in usd-importer "awscli import fails: package_creator.display_name results in HTTP error 410: Gone" [High,In progress] https://launchpad.net/bugs/1764814
<rbasak> I'm working on that now as it happens, but I don't expect the fix to land for a few days
<rbasak> kanashiro: you can do the merge without git-ubuntu, but in your case I suggest moving on to another package for now
<kanashiro> rbasak, ack, I'll move to the next then
<bdmurray> seb128: Sure, that reminds me we noticed rygel uses a lot of memory during its postinst. We had to bump the automatic upgrade testing units memory allotment because it was hanging on rygel.
<seb128> bdmurray, how much?
<seb128> bdmurray, and thx :)
<bdmurray> seb128: from 1G to 2G which while that is the recommended amount of RAM it was still surprising.
<seb128> bdmurray, thx for pointing it out, I will have a look, that seems buggy
<bdmurray> seb128: Thanks - I forgot to fill a bug during the flurry of the release sprint.
<Eickmeyer> Oof.. bug 1851346 hitting Ubuntu Studio like a nasty ton of bricks.
<ubottu> bug 1851346 in ubiquity (Ubuntu) "Ubuntu Studio 19.10 Installer Causes Wanted Programs to be Removed" [Undecided,Confirmed] https://launchpad.net/bugs/1851346
<Laney> does anyone know if it is possible to use the output of dh_listpackages in the clean target? I'm just getting all packages, probably because it doesn't know if it's doing arch, arch+indep, indep at that point, I guess
<Laney> alternatively: how can I conditionally act in clean based on whether I'm building indep packages or not?
<Laney> or maybe I need to do something else altogether
<Laney> basically: dh-sequence-foo doesn't work in B-D-I and is documented as such, and I don't know how to manually pass the --with= properly for the clean target if I specify the real package in B-D-I instead
<teward> slashd: good, then we know that works fine now.  :)
<slashd> teward, indeed
<andrewsh> hi
<andrewsh> can please someone look at https://answers.launchpad.net/launchpad/+question/685319?
<andrewsh> at the moment thereâs nobody to review and/or approve Slovak translations for a lot of things on Launchpad
<andrewsh> Iâd like to change that
<cjwatson> andrewsh: Queued up but I can't look at it today as I have to finish up
<andrewsh> thanks!
<cjwatson> GunnarHj: ^- would be useful if you could verify that - I'm not totally sure on the conventions for the Ubuntu-specific vs. LP-wide translation teams
<cjwatson> (if you can, of course)
<GunnarHj> cjwatson: I'm not a member of "Launchpad Translations Coordinators" (only "Ubuntu Translations Coordinators").
<GunnarHj> andrewsh: How come you are not a member of ~ubuntu-l10n-sk? I'm asking because normally there are local procedures in place to approve new translators.
<ahasenack> rafaeldtinoco: around?
<rafaeldtinoco> ahasenack: yep, just saw your update
<rafaeldtinoco> will dput
<ahasenack> rafaeldtinoco: when building the source packages for the corosync and pacemaker upload,
<rafaeldtinoco> thx!
<ahasenack> rafaeldtinoco: use the right -v option
<ahasenack> or use git ubuntu build-source -v --sign --for-merge
<ahasenack> "--for-merge" being the thing that adds the correct -v parameter
<rafaeldtinoco> ah good to know
<ahasenack> it should be the previous ubuntu version
<ahasenack> so that the changes file includes the debian releases up until this merge
<ahasenack> you can open the changes file to take a look
<ahasenack> it must start with the first non-ubuntu version, and go all the way up to the version you are uploading
<ahasenack> rafaeldtinoco: --for-merge also takes care of fetching the correct orig tarball in the case it's a new upstream version
<ahasenack> and also passes the right options to dpkg-buildpackage to include the orig tarball in the upload in that case
<rafaeldtinoco> ahasenack: i dont use the git ubuntu build-source
<rafaeldtinoco> but I do use dpkg-buildpackage
<ahasenack> that's why I'm saying all of this :)
<rafaeldtinoco> u know the exact flags it does ?
<ahasenack> rafaeldtinoco: check dpkg-genchanges, it's -sa for the orig tarball
<rafaeldtinoco> -sa <- for the new upstream
<rafaeldtinoco> right ?
<ahasenack> yes, but you need to have it locally
<rafaeldtinoco> yep I do
<ahasenack> it won't generate the tarball for you, it will just include it in the upload
<rafaeldtinoco> I have generated the source packages already
<rafaeldtinoco> i was mostly concerned on the signing
<rafaeldtinoco> you mentioned
<ahasenack> and -v
<rafaeldtinoco> I use dpkg-buildpackage -S -k$MYKEY -sa
<ahasenack> you need -v
<rafaeldtinoco> ok
<ahasenack> also a parameter that makes its way to dpkg-genchanges (via dpkg-buildpackage)
<ahasenack> rafaeldtinoco: for pacemaker, for example
<ahasenack> rafaeldtinoco: you would use -v2.0.1-4ubuntu2
<rafaeldtinoco> ah gotcha
<rafaeldtinoco> the previous one
<ahasenack> rafaeldtinoco: then check the changes file, it should be listing 2.0.1-5 and 2.0.1-5ubuntu1
<rafaeldtinoco> cool let me give it a try
<ahasenack> as these are "all the changes in that package since the last time it was uploaded to ubuntu"
<ahasenack> including debian changes
<ahasenack> so if 2.0.1-5 for example closed an ubuntu bug, launchpad would auto-close it, since that version (and the mention of the bug) is included in the changes file
<ahasenack> rafaeldtinoco: pacemaker is not a new upstream release, so no -sa needed
<rafaeldtinoco> yep, only corosync
<ahasenack> yep
<rafaeldtinoco> I realized that when doing the source package locally
<rafaeldtinoco> it complains about the missing .tar.gz
<rafaeldtinoco> then I get it
<ahasenack> yes
<ahasenack> I suggest pull-debian-source -d
<rafaeldtinoco> https://www.irccloud.com/pastebin/xoB688RL/
<rafaeldtinoco> ahasenack: yep, i use pull-lp and pull-debian
<rafaeldtinoco> pls check the pastebin
<rafaeldtinoco> for the signed changes
<ahasenack> I don't know if pull-lp-source handles debs from debian, I guess it could, since they are also stored in lp
<rafaeldtinoco> if looks good
<rafaeldtinoco> ahasenack: the version ddstreet did
<rafaeldtinoco> supports debian and ubuntu iirc
<rafaeldtinoco> but not sure if it was merged or not
<ahasenack> rafaeldtinoco: hm, that changes is incorrect
<ahasenack> rafaeldtinoco: where are the changelog changes we talked about yesterday?
<rafaeldtinoco> oh wait
<ahasenack> Launchpad-Bugs-Fixed: 1828228 <-- it's fixing that bug again, for example
<ddstreet> rafaeldtinoco not yet, sorry, it's on my todo list
<ddstreet> you can use ppa:ddstreet/ubuntu-dev-tools if you want
<rafaeldtinoco> ahasenack: its wrong indeed, and it wasnt
<rafaeldtinoco> i wonder if my cron did something to my local branch
<rafaeldtinoco> let me fix that andreas
<ahasenack> it's your first dput, be careful :)
<rafaeldtinoco> yep yep
<rafaeldtinoco> ddstreet: were your changes accepted ?
<rafaeldtinoco> from that time... or not yet ?
<rafaeldtinoco> its been what ? 2 years :P
<ddstreet> rafaeldtinoco well...i gave up after over a year
<rafaeldtinoco> lol
<rafaeldtinoco> i remember there was some cool features
<rafaeldtinoco> to download previous versions
<ddstreet> but i am not painstakingly rebasing and splitting things up so i can open multiple merge requests to get it added
<rafaeldtinoco> gotcha
<ddstreet> it just is quite time-intensive since my code is really, really far from what's in git
<ddstreet> yeah, you can even download deleted pkgs or from -security ppa
<ddstreet> i'm going to add pulling from upload queues when i have a minute also
<ddstreet> sorry i meant 'now ...rebasing' above, 'not' was a typo
<rafaeldtinoco> ahasenack: wow, i was in the wrong computer
<ahasenack> dude
<rafaeldtinoco> ahasenack: #) that is the bad thing about having 2 or 3 computers
<rafaeldtinoco> lol
<rafaeldtinoco> ill delete my local branches from the one
<rafaeldtinoco> im not using for this never to happen again
 * rafaeldtinoco fear
<ahasenack> double check the hash that was approved in the mp
<ahasenack> otherwise the upload tag is useless
<rafaeldtinoco> ddstreet: ill play with it
<rafaeldtinoco> maybe i can help you out with the merges/split
<rafaeldtinoco> ahasenack: it would not upload
<rafaeldtinoco> relax
<rafaeldtinoco> i would not force things for sure
<rafaeldtinoco> but i wont have any "git ubuntu" local branches
<rafaeldtinoco> in the machine I dont use for coding
<rafaeldtinoco> that is a good thing to be done = )
<ddstreet> rafaeldtinoco thnx, and my git for it is https://code.launchpad.net/~ddstreet/ubuntu-dev-tools/+git/ubuntu-dev-tools, mostly in the 'work' and 'work_cp*' branches
<rafaeldtinoco> ddstreet: i can see you rebasing things :o)
<rafaeldtinoco> rebase-orig rebase-orig
<rafaeldtinoco> lol
<infinity> vorlon, mdeslaur, kees, stgraber: TB?
<marcoagpinto> infinity: Thunderbird?
<marcoagpinto> :p
<rafaeldtinoco> ahasenack: ping
<rafaeldtinoco> ahasenack: sorry got preempt here
<rafaeldtinoco> https://www.irccloud.com/pastebin/7OqGRPY7/
<rafaeldtinoco> just checking one more time before the 1st
<rafaeldtinoco> then it will be smoother =)
<rafaeldtinoco> ok, looks good, double checked, moving on
#ubuntu-devel 2019-11-06
<jibel> vorlon, hi, about https://code.launchpad.net/~jibel/ubiquity/+git/ubiquity-1/+merge/374920 do you want to discuss the design further with mpt or it's okay to merge it now and possibly update the UI later?
<andrewsh> Iâm wondering whether anyone is checking https://launchpad.net/~ubuntu-wiki-editors/+members; it seems Iâm unable to edit the wiki without being a member of this?
<RikMills> popey: ^?
<popey> andrewsh: approved
<popey> thanks RikMills
<andrewsh> popey: thanks
<GunnarHj> Hi cjwatson, can you please look at the discussion at https://answers.launchpad.net/launchpad/+question/685319 . I speculated a bit, but don't know about possible procedures in cases like this.
<cjwatson> Yeah, nor am I, I was going to dig around a bit today
<cpaelzer> rafaeldtinoco: IIRC you wanted to repro 1849720 right?
<cpaelzer> be careful thou, since I used ZFS in my setup and that won't work nicely with the mainline kernel builds (lacking the ZFS module)
<cpaelzer> just to avoid you running into similar issues
<rafaeldtinoco> cpaelzer: I have not tried with q35 yet
<rafaeldtinoco> I had to move my VMs (win2019) to an intel only machine
<rafaeldtinoco> so that would be my 1st move now
<cpaelzer> ok
<rafaeldtinoco> and cascardo stole the icelake machine i was going to use =(
<rafaeldtinoco> bad cascardo
<rafaeldtinoco> :o)
<cpaelzer> rafaeldtinoco: I have an ISO on horsea
<cpaelzer> we might work together on that
<rafaeldtinoco> cpaelzer: my win2k9 is ready
<rafaeldtinoco> all updated, same kernel
<rafaeldtinoco> i literally have just to change to q35 and test
<rafaeldtinoco> lets see
<cpaelzer> ok
<cpaelzer> I had a bug update on that bug held by by timeouts
<cpaelzer> added it now
<cpaelzer> leaving the repro to you then, as you seem much deeper into it already
<cpaelzer> thanks btw
<rafaeldtinoco> on that one ?
<cpaelzer> yes on that bug
<cpaelzer> just a question to the latest external bug updater
<rafaeldtinoco> the first user was a bit lost in providing feedback
<rafaeldtinoco> this last one is much better
<cpaelzer> as he indicated it might be host kernel related
<rafaeldtinoco> yep
<rafaeldtinoco> but the last user has 5.3 and 1st had 5.0
<rafaeldtinoco> iirc
<rafaeldtinoco> ill try both if cant repro
<cpaelzer> they all complained in 19.10 which would be 5.3 all the time
<cpaelzer> maybe odd upgraders
<cpaelzer> so if (IFF) you can repro semi-bisecting the kenel ould be great
<rafaeldtinoco> yep I think the 1st was right after upgrade
<rafaeldtinoco> maybe using old kernel still
<rafaeldtinoco> win2019crashq35.xml -> moving on, will let u know
<cpaelzer> see comment #19, even this guy reports it as "after going 5.0 -> 5.3"
<rafaeldtinoco> true
<cpaelzer> yeah, I'll stop disturbing you - hear you later then
<cpaelzer> doko: do you really think we need a new MIR for postgresql-12?
<cpaelzer> I've checked and 10 / 11 also just got adopted in the past
<cpaelzer> I already had powersj subscribe our Team (so responsbility is clear)
<cpaelzer> ahasenack: ^^ FYI
<cpaelzer> that is bug 1851396
<ubottu> bug 1851396 in postgresql-12 (Ubuntu) "[MIR] postgresql-12" [High,Incomplete] https://launchpad.net/bugs/1851396
<doko> cpaelzer: hmm, I think I checked the subscriber status before filing the issue ...
<doko> ok, promoting
<cpaelzer> thank you doko
<cpaelzer> I double checked and to me it shows us as subscribed
<cpaelzer> https://bugs.launchpad.net/ubuntu/+source/postgresql-12/+subscriptions
<cpaelzer> I'm never sure who can see subscriptions on these pages, but at least I see ours
<doko> hmm, and some binaries were already in main, somebody must have demoted stuff ...
<cpaelzer> doko: auto-demoted or manually?
<cpaelzer> I got no ping or FYI
<cpaelzer> ahasenack: did you get anything about PG related deomtions going on as part of the transition?
<ahasenack> no
 * ahasenack doing online training
<doko> cpaelzer: while you are here, could you look at the asyncpg test failures during the build?
<cpaelzer> doko: I have looked at that last week and myon uploded the changes we need
<cpaelzer> doko: it probably needs custom test triggers to build against the right versions
<cpaelzer> doko: I was away up until today, I'll look again what todays status is
<doko> ta
<cpaelzer> doko: the old asyncpg FTBFS is resolved as planned, but now crashes into something new
<cpaelzer> doko: I will continue checking this, but it will tkae more time just so you know
<cpaelzer> it has a lot of errors around python object streams being unexpectedly garbage collected
<cpaelzer> but I'm not sure yet it is symptom or the reason for the new FTFBS
<cpaelzer> I updated the bug so that anyone else looking at it is aware
<doko> ta
<vorlon> jibel: don't block on me
<jibel> vorlon, k, thanks
<rafaeldtinoco> cpaelzer: sbd bad tests passed, corosync migrated fyio
<cpaelzer> rafaeldtinoco: so my retry did resolve it
<cpaelzer> rafaeldtinoco: well, we still don't know what it was, but I'm glad it migrated now
<cpaelzer> rafaeldtinoco: thanks for open-vm-tools btw
<cpaelzer> uploaded for SRUs
<rafaeldtinoco> cool
<cpaelzer> ahasenack: btw on postgres I did some custom test triggers with the right components together and as you have seen doko did the promotion - I'll recheck tomorrow once time passed to run these tests
<seb128> do we have a vcs for console-setup?
<seb128> the source has Vcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/console-setup/ubuntu
<seb128> but that didn't get updated since 2016...
<seb128> cyphermox, rbalint, vorlon, ^ you might know since you did recent uploads?
<vorlon> zeb
<vorlon> seb128: if I uploaded and didn't update the listed repo, it's because it was already stale when I looked; and if the VCS isn't there, I don't know where one is
<seb128> k, same as me then
<seb128> thx, I will probably do the same (or maybe I should just remove the Vcs-Bzr reference since it's obviously buggy)
<rbasak> rbalint: o/ in bug 1849679, did you "Run the autopktest in a WSL environment where the user name contains space"? From your screenshot it looks like all the user names are "ubuntu"?
<ubottu> bug 1849679 in wslu (Ubuntu Eoan) "[SRU] Please backport 2.3.2-0ubuntu2 to supported releases" [Undecided,Fix committed] https://launchpad.net/bugs/1849679
<rbalint> rbasak, the Windows user name had space
<rbalint> i think it is visible at least on one of the screenshots
<rbasak> OK no problem thanks
<rbasak> I don't require it to be visible in a screenshot, just wanted to make sure it hadn't been accidentally missed :)
<rbalint> rbasak, i appreciate that :)
<ahasenack> Skuggen: hi, have you seen this mysql error, on an upgrade from 5.7 to 8? https://pastebin.ubuntu.com/p/94YMBxTz2B/
<ahasenack> query_cache_limit: Do not cache results that are bigger than this. Removed in MySQL 8.0.3.
<ahasenack> hmm
<ahasenack> wondering if postinst should handle that, like it handles some other upgrade paths
<teward> I think I found a cdbs bug/issue heh...
<teward> or namely, Eickmeyer discovered the issue with some of the Studio package builds, I just noticed the headache more deeply.
<teward> (and I don't use cdbs so I need someone fluent in that to check my assumptions)
<teward> namely, the cdbs debhelper rules for inclusion refer to  dh_systemd_enable but for debian compat >= 11 it is supposed to be using dh_installsystemd (which is not defined in the CDBS rules/scripts it seems in the .mk rules files)
<infinity> teward: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885407
<ubottu> Debian bug 885407 in cdbs "debhelper class broken in compat level 11 (dh_systemd_enable deprecated)" [Important,Open]
<infinity> teward: Given the age of that bug, I'd read it as "stop using cdbs".
<teward> infinity: seems to me like CDBS should be consider deprecated
<infinity> teward: But in the short term, "use compat 10" also works.
<teward> Eickmeyer: ^ read above
<teward> same for you tsimonq2
<teward> infinity: considering this is for a new/updated package version of hydrogen for the Studio team, do we have a problem with compat 10 in the interim until the package is fully DH and not CDBS functional?
<Eickmeyer> teward: ack. Will reduce compat to 10.
<teward> ... that came out as a weirdly syntax-failing string
<tsimonq2> teward: Why does anyone even use that?
<teward> tsimonq2: ask Debian
<teward> regarding hydrogen
<Eickmeyer> tsimonq2: In this case, probably just legacy.
<teward> on another note
<teward> ***read your darn messages for once**
<tsimonq2> teward: No.
<tsimonq2> :P
<teward> Eickmeyer: until such time as you/simon/debian has time to remove CDBS from the equation in the package I'd fall back to compat 10 as infinity indicated
<teward> *for now*
<Eickmeyer> teward: ack
<teward> infinity: might we be able to run a report to see exactly how many packages are using CDBS as their build environment?  Just out of pure curiosity
<infinity> teward: "Why does anyone use cdbs?" -- Inertia.  It was there before dh(1) style debhelper, and it eased many people's burdens for repetitive tasks of similar packages (the entirety of GNOME was CDBS, for instance), but once something clearly better came along (dh(1)), some people gobbled it right up, some people never found the time or motivation to switch.
<infinity> And some of us still have packages that use neither.
<infinity> And some of us still have a package that contains the prototype for what became CDBS....
<infinity> teward: grep '^Build-Depends.*cdbs' /var/lib/apt/lists/*Sources?
<tsimonq2> infinity: Next mission after Qt 4 is gone? :P
<tsimonq2> ...is it still even maintained?
<infinity> cdbs maintenance seems to be light.  It gets uploads, but they're hardly exciting.
<infinity> I think considering it deprecated and trying to move people off it is The Right Thing, but it should be done in Debian.
<teward> *yikes* 2155 packages
<infinity> Gratuitous Ubuntu deltas to switch build systems would be worse than doing nothing.
<teward> have it as a build-dep
<tsimonq2> infinity: Fair.
<tsimonq2> K can start with the orphaned packages. :P
<tsimonq2> *I
<teward> you mean your face?  :P  *shot*
<infinity> teward: So, yeah, "yikes", but also keep in mind that cdbs and dh were solving the same problem for most packages (how do I avoid doing packaging?), so many of those 2k packages might be veeeery simple to convert in a matter of seconds, or with a scrpt.
<teward> true
<teward> infinity: or many of those packages are old, obsolete, and orphaned and can be purged
<teward> most of the ones I see here in ths output are Universe
<infinity> teward: As in, if they don't do anything fancy in cdbs, they also probably don't need fancy in dh overrides, and can just be replaced with the dh 1-liner.
<teward> infinity: do we maintain an Ubuntu specific variant of Lintian for Ubuntu-specific things?
<teward> just curious
<infinity> Nope.
<teward> hmm
<teward> maybe Debian can update lintian to include a warning in there about CDBS being a build dependency and not working with compat > 10
<infinity> If you consider 2 years of non activity on that bug as concensus that CDBS isn't meant to work with compat >> 10, that might be a reasonable check.  I dunno.
<infinity> Also, did you try compat 12 too, or was it specifically 11 that failed?
<teward> Eickmeyer: ^
<infinity> Cause the debhelper manpage itself warns against using 11 because it does Weird Things with systemd.
<Eickmeyer> infinity: It was >=11 that was being indicated.
<Eickmeyer> infinity: That said, I only used 11.
<Eickmeyer> infinity: I suppose if it's in Focal only that I could go 12.
<infinity> I mean, CDBS might also hate 12 too.
<Eickmeyer> For safety sake, probably 10 would be best.
<infinity> I just know that 11 is called out by debhelper as being evil and wrong, specifically because of dh_installsystemd, and should be avoided.
<infinity> Even without CDBS in the mix.
<teward> infinity: will I have to ask the Debian governance teams to decide about CDBS throwing lintian warnings, or will just filing a bug against Lintian work?  I forget how Debian governs crap at that level
<infinity> teward: Just filing a lintian bug, pointing at the CDBS bug will be a good start.  They may push back with "lintian isn't meant to be a source for documenting bugs in other packages", but I think given the situation, you can argue for why it's not a terrible check.
<infinity> teward: I'd also love a lintian warning of "CDBS is deprecated crap, please switch to dh(1)", but without the CDBS maintainers agreeing that, that one might need a tech-ctte decision. :P
<infinity> s/agreeing that/agreeing to that/
<teward> i'm quite tempted to send a message to tech-ctte to ask them to consider CDBS deprecated in favor of DH due to this major bug
<teward> so that in Debian POlicy latest versions it's defined as "CDBS is not supported"
<teward> but that's my opinion and i have no gauge on debian-devel yet on this
<teward> so that's a later task :p
<infinity> teward: A mail to debian-policy, CC to devel, along the lines of "should we consider CDBS deprecated" might start a fun flame war, if you're bored.
<teward> hah
<teward> *spoofs the origin email to be infinity's @ubuntu.com address then lets hell loose*
<infinity> (Or it might prove entirely non-contentious, it's hard to predict these things)
<teward> :P
<teward> yeah that's on my "Later" list
<teward> i've got some more important things on my radar, esp. for this dev cycle constantly tracking nginx mainline upstream and updating focal xD
<teward> 'cause it's That Time Again (TM)
<infinity> teward: I don't think one bug is enough to deprecate a tool used by thousands of packages.  But there are other arguments to be made about ease of use, easing third-party contributions, standardising, etc, etc.
<infinity> Back when I started, all but the most complex packages had nearly identical dh_make rules files.  They were a bit messy, but if you'd seen one, you know how they all worked.
<infinity> dh(1) offers that, but much simpler, and it's definitely mind-bending when you run into something that breaks from that standard.
<teward> infinity: Indeed, but if 90% of packages with cdbs are written for deb policy earlier than ${LATEST} then they aren't updated for the standard anyways so in *theory* they wouldn't get completely purged
<teward> the DH incompatibility alone here should be enough to make it an RC blocker for most packages
<teward> at least, IMO
<teward> s/most packages/most packages reliant on CDBS with compat >> 10)
<teward> BAH i can't type to save my life >.<
<teward> blocked from testing maybe, but...
<teward> considering I know little to nothing about CDBS any email I write will need extra eyes (such as yours) before being sent
<teward> and I'm still busy wioth Ubuntu level of policy things (Backports comes to mind!) and am working with others on those things first
<teward> and I"m hesitant to suggest a radical policy change in Debian without backup xD
<teward> infinity: lintian maintainers NACK'd on the statement people will see FTBFS first.
<teward> infinity: so perhaps this should be a policy decision
<teward> (i'll have to email debian-policy, cc -devel, and ask them their opinions/thoughts)
<fred909> do the packages in the base deb repo for a release (like xenial) ever get updated or are all updates pushed to xenial-security or xenial-updates?
<teward> fred909: to my knowledge, all 'updates' get pushed to -updates, except in the case of security updates which get pushed to -security and -updates, and kernel updates which also get pushed to -security and -updates
<teward> and the base 'xenial' repositories don't really change much at all
<fred909> teward: thanks :)
<fred909> aaah apparently -updates are moved into the main repo after awhile...
<fred909> makes creating deterministic Docker images difficult. debian has https://snapshot.debian.org/
#ubuntu-devel 2019-11-07
<infinity> fred909: No, updates are not moved into the release pocket "after a while", or ever.
<infinity> fred909: That's how Debian does point releases, but not Ubuntu.
<infinity> fred909: On the other hand, if you want to create deterministic docker images by shipping known security flaws, you might want to re-think your entire endeavour.
<xnox> mwhudson:  doko: so pandas still fails 3.8 test suite, right?
<xnox> override_dh_auto_test: override_dh_auto_install
<xnox>         set -e; \
<xnox>         for ver in ${PY3VERS}; do \
<xnox>           if [ $$ver = 3.8 ] ; then \
<xnox>                 debian/rules python-test$$ver || true; \
<xnox>           else \
<xnox>                 debian/rules python-test$$ver; \
<xnox>           fi; \
<xnox>         done
<mwhudson> xnox: y
<mwhudson> need a new upstream version to get 3.8 compat
<mwhudson> there is a debian bug about this
<xnox> right
<xnox> and there are reverse-deps of pandas that are still failing (ie. dask)
<xnox> = 280 failed, 23302 passed, 2666 skipped, 742 deselected, 81 xfailed, 31 xpassed, 9569 warnings in 969.29 seconds =
<xnox> X connection to :99 broken (explicit kill or server shutdown).
<xnox> make[2]: *** [debian/rules:118: python-test3.8] Error 1
<xnox> is not good
<xnox> mwhudson:  is it out yet upstream? can we package/upload it?
<doko> dask needs an update, probably 2.6
<doko> also discussed
 * xnox remembers vowing to never touch pandas, but i think it was more than 3 years, so expired
<mwhudson> xnox: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931557
<ubottu> Debian bug 931557 in src:pandas "transition: pandas 0.23 -> 0.25" [Wishlist,Open]
<doko> xnox: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10703361/+listing-archive-extra
<xnox> mwhudson:  it's done in experimental
<xnox> doko:  nice! but sad that it still fails
<doko> but maybe let vorlon fix the statsmodels installation failure first ...
<xnox> yeah
<xnox> blocked on all fronts
<doko> there's only limited time
<doko> xnox: it's failing for the deprecation warnings, I didn't figure out yet where these come from
<doko> the build will succeed if you reduce the amount of tests, like for all non x86 archs
<doko> xnox: no, it's not done. it can't be tested
<vorlon> doko: only the -doc package is an install failure, what is that blocking?
<doko> vorlon: the much discussed pandas update, see https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10703361/+listing-archive-extra and re-enable the indep b-d's
<doko> sorry, ppa's don't have a history
<doko> anyway, 2am here, afk
<vorlon> doko: I still don't understand what this has to do with python-statsmodels-doc being uninstallable; it has no reverse-dependencies
<vorlon> and python3-statsmodels itself shouldn't be uninstallable
<vorlon> (but testing that locally now)
<vorlon> tested and it installs fine, so....
<doko> vorlon: seriously? https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10706889/+listing-archive-extra
<doko> please do your homework
<vorlon> doko: I ran 'reverse-depends -b', where is that build-dependency coming from?
<vorlon> doko: it's not a build-dep of pandas in the archive, so why is the new version /adding/ a doc build-dep?
<doko> wrong question
<doko> looking at the statsmodels build log (archive build) shows you the conflicting files
<vorlon> I understand that, we already talked about it
<jbicha> what's fun are the cdbs packages that try to be extra clever, like https://salsa.debian.org/gstreamer-team/gst-plugins-good1.0/blob/master/debian/rules
<jbicha> teward: before starting a big email to Debian about cdbs, maybe you could read through the recent-ish discussion https://lists.debian.org/debian-devel/2019/05/msg00178.html
<teward> jbicha: i have no plans to send any time soon :P
<jbicha> there's probably a summary of that email discussion somewhere ð­
<mwhudson> uwsgi is the best/worst cdbs package
<Unit193> I just converted 3 packages from cdbs to dh. :3
<RikMills> cjwatson: hi. merges.ubuntu.com seems to not be updating? sorry if this is something known and in-hand
<cjwatson> RikMills: Known in the sense that I have a bunch of overnight mails about it and hadn't dealt with them yet, yes
<cjwatson> Got stuck for some reason.  I've killed the stuck process
<RikMills> cjwatson: thank you :)
<TJ-> Just noticed on 19.10 (but exists since 17.10 I think) that by default os-prober spams the journal with debug messages - not noticed before due to GRUB_DISABLE_OS_PROBER=true ... os-prober has a OS_PROBER_DISABLE_DEBUG but it isn't exported from grub in /etc/grub.d/30_os-prober - is there some other way to prevent the spamming?
<cjwatson> You could put 'export OS_PROBER_DISABLE_DEBUG=1' in /etc/default/grub
<cjwatson> I think we probably ought to flip the debug default in os-prober instead of further hacking grub
<cjwatson> But maybe coupled with installer changes to turn on debugging in the installer context, since it can be very helpful when looking at logs of installer bugs
<gpiccoli> o/ rbasak - I detailed a bit the user visible differences in LP #1847924 , let me know if you think it's enough and your thoughts on the alternatives we have heheh
<ubottu> Launchpad bug 1847924 in mdadm (Ubuntu Focal) "Introduce broken state parsing to mdadm" [Medium,In progress] https://launchpad.net/bugs/1847924
<gpiccoli> Thanks in advance!
<TJ-> cjwatson:  just got back to os-prober. Yes, export in the sourced config files works. Agreed, user-tool-debug controllable would be best. Even with it disabled os-prober still uses 'log' to be extremely verbose with what I'd regard as debug messages - certainly not very helpful to users, and what is annoying is I cannot find a journal 'unit' that contains these messages. Typical 'unit' field is e.g.
<TJ-> 40grub2[$PID] and $PID varies due to many invocations
<ahasenack> any idea why this bug isn't showing up in the php7.3 excuses report? https://bugs.launchpad.net/ubuntu/+source/php7.3/+bug/1850190
<ubottu> Launchpad bug 1850190 in php7.3 (Ubuntu) "FTBFS with mysql 8.0" [Undecided,In progress]
<ahasenack> I added the update-excuse and update-excuses tag (just in case)
<ahasenack> or is it still mispelled?
<ahasenack> rbalint: ^
<gpiccoli> Folks, if we have "force-badtest makedumpfile/all/s390x" in ubuntu-hints, can we have a report of s390 autopkgtest regression?
<gpiccoli> I'd expect that arch to be skipped
<gpiccoli> According to this page https://people.canonical.com/~ubuntu-archive/proposed-migration/disco/update_excuses.html#makedumpfile though, it's listed as failed/regression
<xnox> it used to work
<xnox> and made sure that it did =/
<xnox> although people mostly care about zfcpdump which is not trivially testable in VM
<gpiccoli> xnox, I still don't understand - it's marked as badtest, I understand that once it worked..but, if in that file that is shown as force-badtest, should it report?
<xnox> all hints are per-series, did you check the disco hints branch?
<gpiccoli> I'm asking because I'll soon proposed a MP to force-badtest on ppc64 too, some infrastructure problem we need to debug, I've discussed that with the pkg maintainer, cascardo
<gpiccoli> hmm..I'm not sure xnox ! Thanks for the heads-up. I'm checking the file ubuntu-release in the repo lp:~ubuntu-release/britney/hints-ubuntu
<gpiccoli> Is this related to which series xnox ?
<xnox> devel
<xnox> i.e. currently focal
<gpiccoli> ohhh
<gpiccoli> odd!
<xnox> https://code.launchpad.net/~ubuntu-sru/britney/hints-ubuntu-disco is the disco one
<gpiccoli> I thought it was to specific release. Do we have a way to force badtest to all releases xnox ? Or should we change all releases' files manually, proposing a MP for every one ?
<paride> hey xnox, looking at https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1849563 I remembered that you did the nvidia passthrough at the release sprint
<ubottu> Launchpad bug 1849563 in edk2 (Ubuntu Focal) "Unable to passthrough GPUs to guest" [Undecided,New]
<paride> was there any special trick worth mentioning?
<xnox> gpiccoli:  propose for each release, yes.
<gpiccoli> tnx xnox!
<xnox> gpiccoli:  part of this is ACLs because only SRU team can touch stable release hints, vs release team who can touch devel series hints, and upon release the $devel series hints are forked to become the baseline of the stable release for future SRUs.
<rbalint> ahasenack, the php7.3 update-excuse shows up after the missing builds
<gpiccoli> nice, thanks for the explanation xnox ! I'm reporting a LP bug to investigate such recurrent failures in s390x and ppc64el, and will propose soon a merge request to bionic/disco hints
<rbalint> ahasenack, i think this is where block-proposed bugs are listed, too
<gpiccoli> xnox, sorry to bother again, just confirming - in the britney disco/bionic repo, the file to change in order to add force-badtest is ubuntu-sru correct?
<gpiccoli> _Not_ ubuntu-release
<cpaelzer> doko: you were so kind to promote postgresql-12 binaries for the MIR that you opened and we discuessed recently, but I found it hanging in excuses with dependencies
<cpaelzer> doko: truns out not all binaries of postgresql-11 were in main and postgresql-12 should follow the same
<cpaelzer> doko: could you selectively demote the following binaries of postgresql-12
<cpaelzer> postgresql-server-dev-12, postgresql-plperl-12, postgresql-plpython-12, postgresql-plpython3-12, postgresql-pltcl-12
<cpaelzer> the former one being the one that triggers the component  mismatches atm
<cpaelzer> but following the old style which pkg are main/univese the demotion I requested would resolve that
<cpaelzer> doko: also news on asyncpg (as you might follow in the bug) we might need v0.19.0 (or a patch thereof) - I'll continue on that
<doko> ok, but seriously, why the explicit dependency on clang?
<cpaelzer> doko: I never challenged that to the debian packaging, it is as we get it from there
<cpaelzer> let me check history on it for an explanation
<cpaelzer> doko: it is only on the -dev package and it is becaue things are built --with-llvm
<cpaelzer> as part of enabling that option it was added to the -dev dependencies
<doko> hmm, they have a jit, that explains why llvm is used, but not clang
<doko> and it's built with gcc, as it should
<cpaelzer> On that part Ubuntu never touched it, I'd have to ask Myon for reosons beyong what I found int he git log
<doko> that would be nice =)
<doko> they build a second time with flto=thin -emit-llvm
<xnox> gpiccoli:  any file works. it's just the team that commits things has different files. I'm not ubuntu-sru team, so ask them where they want hints
<gpiccoli> xnox, but for example, when autopkgtest is failed, which file is lookied to check if it was a bad test?
<gpiccoli> I'm confused which file I need to edit in order to prevent the regression flag
<xnox> gpiccoli:  i don't know either, and both ubuntu-release team and ubuntu-sru team refuse to document what they will take.
<xnox> gpiccoli:  so ping sil2100 rbasak RAOF vorlon about it
<gpiccoli> heheh xnox, okay! I guess your last message works as a ping. So the team above ^, please let me know what do you prefer
<xnox> i think i misspelled thair names, or they are not in the channel ;-)
<gpiccoli> vorlon merged my last MP from last badtest I needed, let's see hehe
<gpiccoli> tnx xnox
<sil2100> I am here!
<sil2100> Well, usually we don't explicitly require people to submit MPs for hint changes, which probably explains why it's not documented
<sil2100> For stable series basically both ubuntu-release and ubuntu-sru files are used (+ the per member ones as well)
<sil2100> Whenever I edit hints what I do is: if I need to bump an existing hint, I just leave it in the file it was previously in. But if it's a new badtest/skiptest, I put that in ubuntu-sru
<sil2100> (for stable series of course)
<xnox> sil2100:  add this to the StableReleaseUpdates wiki page please
<sil2100> Will do that I guess, but as said, I don't think there's a requirement for people to edit hints on their own
<gpiccoli> sil2100, thanks a lot for the great clarification
<xnox> sil2100:  correct, but those who do want at least some guidance.
<sil2100> I mean, I never ever required that and currently I'm not looking at hint MPs on LP - only when I'm explicitly pinged with an URL
<gpiccoli> So, if I want to add a force-badtest, what should I do sil2100 ?
<sil2100> xnox: +1
<xnox> "if you try to submit hints, use per series branches & keep bumps where they are, or use ubuntu-sru file for new hints" => i.e. things you said
<sil2100> gpiccoli: if there's no existing force-badtest for the given package and version, just put it in ubuntu-sru with a comment explaining why it's needed
<xnox> sil2100:  erh..... ubuntu-sru must subscribe to the hints branch changes!
<sil2100> I'm probably subscribed, but probably all the mail goes into /dev/null!
<gpiccoli> bumps where they are -> can I read that as "if we have a specific version entry in ubuntu-release and user is bumping to all versions, keep in ubuntu-release instead of ubuntu-sru" ?
<gpiccoli> this is what I got grepping for the package _after_ my addition sil2100 : https://termbin.com/i0v2
<gpiccoli> it's in bionic
<sil2100> gpiccoli: if it's like skipping a new architecture, then I'd include the new hint in ubuntu-sru then
<gpiccoli> thanks sil2100 ! I'll do the MP and loop you there, ok ?
<mdeslaur> Skuggen: hi! any luck with the s390x issue?
<sil2100> gpiccoli: ok, just give me the URL once you file it
<gpiccoli> awesome, much appreciated sil2100 =)
<gpiccoli> thanks
<sil2100> yw!
<xnox> coreycb:  out of all the things, i care about sad openstack in focal-proposed today! https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#ubuntu-openstack
<xnox> coreycb:  how can i help, getting those rolling? i.e. we could skip tests on py3.8 on those, or like try to fix them up? what do you think?
<coreycb> xnox: oh no, are they all py38 related?
<coreycb> xnox: oh good it looks like python3.8 is in bionic now. i can enable non-voting gate unit test jobs upstream now. unfortunately too late for this cycle to enable voting.
<infinity> coreycb: So, WTF happened with Openstack upstream for them to slip their 6-month cadence so hard?
<infinity> coreycb: Are there conspiracies afoot?  Was there some obvious oops?  More importantly, if it keeps slipping, do we really want to keep trying to "align" if it means SRUing final 2 months and then 3 months (etc) after release?
<infinity> I suppose if there is a conspiracy, it's not one involving Fedora, cause F32 still appears to be aligned with Focal.
<infinity> coreycb: Is there anyone who can talk sense into them and point out that being out of cadence with the two major 6mo-releasing distros (Ubuntu and Fedora) is daft?
<coreycb> infinity: i'm not sure why the cadence changed. beisner may know better (he's in china now though) or jamespage.
<coreycb> infinity: but yes if it gets worse then we will have to consider a new approach
<coreycb> infinity: for this cycle I think we can still make it work with the one month post-focal delivery of ussuri, assuming the release team and sru team are ok with it
<xnox> there is "Release Cycle Observations" thread but not much details or juice in it, and then just the cycle published.
<xnox> coreycb:  i think it needs a public mailing list post as to why it's 4 weeks longer than normal. It's 30 weeks long cycle.
<coreycb> xnox: infinity: we might know someone on the foundation board
<coreycb> xnox: infinity: let me check with others to see if they have a better understanding of the upstream rationale
<infinity> coreycb: The rationale would be interesting, but more interesting would be badgering them to re-align with Ubuntu/Fedora again.
<infinity> coreycb: This situation is pretty poop for all involved.
<infinity> coreycb: Heck, a short cycle focussed just on bugfixes and stability with an eye to pulling back a couple of months would be even better, so we could see final releases well BEFORE our release.  A man can dream.
<coreycb> infinity: agreed I'll discuss with the team a bit
<ahasenack> what is "live-installer"? https://launchpad.net/ubuntu/+source/live-installer
<ahasenack> ubiquity? d-i installer?
<ahasenack> it's not subiquity
<ahasenack> Skuggen: hi, what's your lp id please?
<ahasenack> Skuggen: I have a couple of mysql8 bugs that I would like your opinion on, upgrade issues where a config option is no longer supported by mysql8 and it fails to start
<ahasenack> Skuggen: https://launchpad.net/~lars-tangvald ?
<gpiccoli> sil2100, here are the MPs heh: https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-bionic/+merge/375279
<gpiccoli> https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-disco/+merge/375280
<gpiccoli> Thanks again for your help =)
<Skuggen> ahasenack: Hi
<Skuggen> Yeah
<ahasenack> thx
<fred909> infinity: thanks for the clarification. definitely don't want to ship security vulnerabilities, but we had test breakage... so trying to find a middle ground where we can control what goes in. i think the main issue was using a docker image (ubuntu:16.04) that's a moving target. the tagged versions shouldn't change though and security updates shouldn't change functionality... right?
<infinity> ahasenack: live-installer is the d-i component that copies the livefs into place on the old-style server ISOs.  It's the replacement for debootstrap in the same install flow.
<infinity> (ish)
<infinity> fred909: I'd somewhat ignorant about how our docker images are built/published (other than to note that, yes, they're updated regularly with post-release updates), so I'm not sure what you mean by "tagged versions".
<infinity> fred909: If you build your own stuff from scratch, excluding updates and security will get you the same versions every time.  Obviously not ideal, but gives a base reference.  Security and SRU (bugfix) updates both happen under a policy of not changing functionality unless necessary (ie: a feature has to be disabled because the whole thing, it turns out, is a security flaw by design)
<fred909> infinity: it seems the docker images pull from https://partner-images.canonical.com/core/. tagged versions are listed at https://hub.docker.com/_/ubuntu/?tab=tags.
<fred909> infinity: ok, thanks.
<infinity> fred909: So yeah, looking at that, the tags by date clearly won't ever change (though no idea how much history is kept), while the tags by version number will end up getting updates throughout the life of the product.
<infinity> Weirdly confusing use of the term "tag", which implies "unique and unchanging" to VCS people, but obviously doesn't (have to) mean that here. :/
<fred909> infinity: yeah, definitely alarming that they can be changed and it's left up to the maintainer of the particular image.
<fred909> infinity: you mentioned "Security and SRU (bugfix) updates", security go to -security... what repo do the SRU's go to? -updates?
<fred909> ah they're a subset packages in -updates, that are uplifted to the images?
<doko> LocutusOfBorg, or RikMills: is anyone of you looking at the paraview/armhf ftbfs?
<LocutusOfBorg> doko, I might have a look in 12h, but I failed so far to find a way to fix it
<LocutusOfBorg> it might be related to the embedded vtk version
<doko> LocutusOfBorg: I also filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944324
<ubottu> Debian bug 944324 in src:paraview "python-paraview has to be renamed to python3-paraview" [Serious,Open]
#ubuntu-devel 2019-11-08
<Unit193> Howdy!  I heard there was a plan to deprecate/remove indicator-* stuff, is that accurate?
<cpaelzer> rbasak: hiho, you added a delta to mediawiki for mysql8
<cpaelzer> rbasak: it seems that Debian has accepted that in 1:1.31.5-1
<cpaelzer> Could you check this and trigger a sync if you agree?
<cpaelzer> that also would give us 3 upstream minor releases and a CVE fix
<cpaelzer> I ran into that by checking postgres dependncies currently having issues, but since it is your delta I thought you might just give it a quick look and sync it
<cpaelzer> oh wait IIRC you said you won't be around this morning right?
<cpaelzer> I'll check and sync it if identical, but leave it to you if there are differences
<cpaelzer> ok, changes are 100% identical - I'll call syncpackage
<rafaeldtinoco> morning o/
<LocutusOfBorg> doko, I opened another RC bug for the armhf build failure
<doko> LocutusOfBorg: that's not because of different OpenGL/OpenGLes defaults?
<LocutusOfBorg> doko, it fails on Debian too
<LocutusOfBorg> but aren't the defaults in sync with Debian now?
<LocutusOfBorg> I see there is no qtbase delta anymore...
<LocutusOfBorg> mitya57? ^^
<LocutusOfBorg> paraview on armhf might fail differently in Debian, since it fails hours before the Ubuntu failure
<LocutusOfBorg> meh
<doko> may I remove paraview from -proposed for now?
<LocutusOfBorg> for sure :D
<LocutusOfBorg> double rc bug, if no rdepends, who cares
<LocutusOfBorg> so I can see what else is missing for vtk and friends to migrate
<ginggs> LocutusOfBorg: last paraview armhf attempt was a month ago, i gave it back now to see if anything changes
<LocutusOfBorg> ginggs, problem is that we have to disable parallel building to avoid ENOMEM
<LocutusOfBorg> but another machine might have more ram
<ahasenack> rafaeldtinoco: do you still have the tags locally for https://code.launchpad.net/~ubuntu-server-ha/ubuntu/+source/resource-agents/+git/resource-agents/+merge/375322 ?
<ahasenack> logical, split, etc?
<ahasenack> if yes, can you push please?
<rafaeldtinoco> sure
<rafaeldtinoco> ahasenack: done
<rafaeldtinoco> will do for crmsh also, forgot
<coreycb> infinity: xnox: some answers regarding openstack ussuri release alignment with focal. the reasoning for the change in release timing is simply based on the time between OSF summits. the timing was raised with the CEO, COO, and board, and they basically apologized, said that they hadnât thought about the impact to distros.  They recognized that it is an important impact and they will coordinate and communicate
<coreycb> better and with consideration in the future. but the ussuri release isn't changing at this point.
<ahasenack> rafaeldtinoco: quick needs-fixing for resource-agents, at the beginning of the process, so it will affect the remaining commits, so I'll wait
<rafaeldtinoco> ah u found it
<rafaeldtinoco> ahasenack: i thought it had came from debian or something was wrong
<rafaeldtinoco> let me fix it
<ahasenack> rafaeldtinoco: let me know when pushed please
<rafaeldtinoco> k, having a quick bite and will do right away
<xnox> coreycb:  they made it 30 weeks long which is shooting themselves in the foot really
<mitya57> LocutusOfBorg: not sure what you are asking me about. There is no major qtbase delta since Disco. Disco and Eoan had only some cherry-picks on top of Debian packaging.
<coreycb> xnox: well, yes. I think it's unfortunate as well and I really hope it will be better aligned in the future. it sounds like it will be.
<coreycb> xnox: for focal though we need to weigh whether the one month slip is a deal breaker or if we can work with it. the schedule for the current release isn't going to change.
<xnox> coreycb:  we need to request them to change the schedule harder
<xnox> coreycb:  and like have an earlier point release (do they do those?)
<coreycb> xnox: we can snapshot releases at any point in time
<coreycb> xnox: they only do point releases for stable support post-release
<infinity> coreycb: I'd like to know what "coordinate [...] in future" is actually going to look like.  I'm okay with a 1-time "yeah, we can make this wonky schedule work, I guess", but I don't want it to become a habit.  If they can commit to their next cycle being short and getting back on cadence, then alright, they screwed up once, oh well.
<infinity> coreycb: Also, the current cycle is still salvageable if they toss us a few bones via their own release policy.  Like, say, strongly discourage (or flat out disallow) changing of dependencies in components N weeks before release, for instance, as that's the most annoying change for distros to deal with post-release.
<infinity> Code is just code, but changing the package selections on end-user machines is never pleasant (sometimes because they use tools wrong, eg "apt-get upgrade" versus "apt-get dist-upgrade", sometimes because certain deployment strategies are just flat-out paranoid about stuff like "why is a new package needed and suddenly you say this one isn't?)
<infinity> "
<coreycb> infinity: agreed I think we need to get a better idea of coordinate in future.. something we can hold them to
<infinity> coreycb: I mean, a good start is knowing that for literally 15 (well, ish) years now, Fedora, Ubuntu, and GNOME have all managed to have a matching cadence (and some other projects tag along for fun).
<infinity> They could just.... Do That. :P
<coreycb> infinity: the dependencies are frozen 13 days prior to focal release so it would be bug fixes only beyond that
<infinity> And we don't really coordinate that, we just know how to count to 6.
<coreycb> infinity: hah
<infinity> coreycb: Okay, if the deps are frozen before release *and* the dep-frozen RCs can all make it into release, I'm less wary of this plan.
<LocutusOfBorg> mitya57, I remember some eglfs being enabled on arm64 or armhf or differently between debian and ubuntu
<mitya57> It is not the case since Disco. And it was arm64, not armhf.
<LocutusOfBorg> nice thanks
<infinity> coreycb: There's nothing scarier to paranoid "but you said it was a *stable* release" users than an upgrade saying "You now need python3-soundsscary, and you no longer need python3-soundsimportant, press Y to break everything."
<LocutusOfBorg> so, the failure should be reproducible in Debian too
<coreycb> infinity: mostly it would be that way. the upstream rc1 deadline (core projects) is one day after focal release so we would plan to snapshot core projects as late as possible for focal, maybe a week prior to release to not disturb things release week.
<infinity> coreycb: Alright, formally replied on-list.  Thanks for the back-and-forth.
<coreycb> infinity: alright, thank you
<infinity> ahasenack: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1851858
<ubottu> Launchpad bug 1851858 in ubuntu-advantage-tools (Ubuntu) "adds ESM to sources.list.d unconditionally, despite it being x86-only" [Undecided,New]
<infinity> ahasenack: I'll let you argue with the security/ESM team about who's at fault, but the situation is definitely broken.
<ahasenack> hm, I didn't know esm was x86 only
<sbeattie> ugh
<teward> just to fact-check myself, when we say x86 we also include amd64 in that yes? (x86_64)
<infinity> teward: Yes.
<teward> good, the lack of coffee is making my brain fail :)
<teward> thanks infinity
<infinity> As noted in the bug, I'd prefer if it wasn't x86-only, but that's a policy change I'm probably not in a position to make.
<tyhicks> infinity: it is *64-bit* x86 only: https://ubuntu.com/legal/ubuntu-advantage-service-description#uasd-subscription
<infinity> tyhicks: The archive has binary-i386
<infinity> tyhicks: So from the POV of this bug, it's x86-only.
<infinity> tyhicks: https://esm.ubuntu.com/ubuntu/dists/trusty-infra-security/main/
<tyhicks> hmm, I wonder if that's an artifact of the new trusty-infra-security
<infinity> tyhicks: Nah, precise was both arches too.
<infinity> tyhicks: It's probably just that IS filtered to those two arches (being the same two we publish on archive.u.c) and no one questioned them.
<infinity> tyhicks: Since the PPA has all arches, and they had to pick a filter for the mirror.
<mdeslaur> precise had both probably because precise builds the all arch on i386, no?
<infinity> mdeslaur: That doesn't mean i386 would need to be mirrored.
<mdeslaur> true
<cjwatson> Also, that's true of trusty too
<cjwatson> $ curl -s https://api.launchpad.net/devel/ubuntu/trusty | jq -r .nominatedarchindep_link
<cjwatson> https://api.launchpad.net/devel/ubuntu/trusty/i386
<infinity> Now, that said, there are other reasons you might want i386, like multiarch libraries.
<cjwatson> (It changed with vivid)
<infinity> Cause if you ESM a library that people have installed multi-arch, the version skew will tear it out if they can't get all arches.
<mdeslaur> ah, that would be a good reason to have it :)
<infinity> But that's also an argument for why we should publish all arches and just turn off !amd64 builds for packages we really don't want to support (the kernel?).
 * infinity shrugs.
<infinity> At any rate, the u-a-t bug is real and causing pain right now.  Any solution is better than none.
 * genii runs a hose from the coffeepot to teward's desk
<gQuigs> would anyone mind approving systemd in the upload queues (bionic/disco)?  got several customers who are looking forward to further testing when it hits -proposed  (https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd)
<rbalint> gQuigs, it is more of an #ubuntu-release question
<rbalint> gQuigs, try pinging SRU team members, the daily vanguards are listed at: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<gQuigs> rbalint: thanks! will do
