#ubuntu-devel 2005-05-30
<Mithrandir> argh
<Mithrandir> polyp icks.
<mdz> good morning
<crimsun> morning
<Riddell> hello mdz 
<Riddell> nice holiday mdz?
<zul> hi mdz
<tseng> welcome back, mdz
<jammcq> hello mdz
<mdz> Riddell: yes indeed
<mdz> apart from a boatload of email, I am in good shape
<fabbione> hey mdz
<mjg59> fabbione: I have so much acpi crack for you
<fabbione> ehheeh
<robertj> ooh ooh acpi
<robertj> hehe, when is the part of the show in which we give you root on our laptops and you test, fix, and commit changes upstream ;)
<robertj> (or more realistically, LaptopMission could use a step-by step and check-off matrix
* robertj idles a gbit
* robertj returns
<aquarius> I had a thought: it would be handy for people to be able to sign up to shipit and say "send me one CD every time there's a new release", so they stay up to date.
<robertj> aquarius: it would be but it would also cost more
<aquarius> Especially given the very nice "This is an Ubuntu CD; do you want to upgrade?" prompt you get when you put an Ubuntu CD in.
<aquarius> But I don't know whether shipit is built for that sort of thing or more as the hub of a grassroots distribution network...
<aquarius> robertj: ah, yeah, thought so.
<lifeless> robertj: its meant to promote grassroots stuff - thats why we ship boxes of 10 ;)
<lifeless> so that you give it to your friends. ..
<robertj> lifeless: I do order 10 ;)
<robertj> (still waiting)
<lifeless> heh
* aquarius nods. OK, that makes sense (and that was what I thought might be the case).
<lifeless> there are a lot of orders to fill
<robertj> (no biggy)
<AndyFitz> xfonts-utils  broken in hoary for everyone else ?
<daniels> what's wrong with -utils?
<bob2> breeeeeeeeeeeezy.
<AndyFitz> breezy sorry
<AndyFitz> oh man im sleepy lol
<AndyFitz> daniels,  its just not cruising along and upgrading like everything else
<AndyFitz> i'll go check whats holding it back.  something isnt provided yet
<jdub> ha ha
<jdub> http://www.whiprush.org/2005/05/were_our_own_wo.html
<jdub> thom: ^
<ajmitch> AndyFitz: expect fun with breezy
<jdub> WAIT, I'LL BANG TWO ROCKS TOGETHER AND CALL IT SECURITY SUPPORT!
<AndyFitz> ajmitch,  im a sucker for punishment. breaking and unbreaking is fun :-)
<ajmitch> AndyFitz: yeah, I've just been playing the unbreak my X game
<AndyFitz> ajmitch,  let me know how it goes for you.  i'll be doing that soon
<ajmitch> well the X server still runs :)
<KaiL> AndyFitz: telling that it to easy ;)
<KaiL> is..
<bob2> jesus
<bob2> why on earth is the extension API changing a SECURITY UPDATE, anyway?
<daniels> ajmitch: so, don't upgrade to xorg-common -15
<daniels> or wherever it was that /usr/bin/X11 became a directory
<AndyFitz> ajmitch,  you're an  important step ahead of me.   i'll get x to work once i sort out this xutils thing
<daniels> Bad Things Happen
<daniels> wait
<ajmitch> daniels: far too late for that.. /usr/bin/X11 disappeared
<daniels> AndyFitz: xutils, or xfonts-utils?
<daniels> ajmitch: sweet
<Amaranth> ajmitch: You got it to run? wow
<ajmitch> a symlink got it back for now until things are shifted
<AndyFitz> daniels,  nboth,  xutils is broken because xfonts-utils  isnt there to be upgraded also
<Amaranth> ajmitch: What voodoo made it run? I've done the /usr/bin/X11 symlink
<ajmitch> Amaranth: and updating the font paths in xorg.conf
<ajmitch> fairly minor fixes
<Amaranth> where are fonts at now?
<Amaranth> maybe gdmflexiserver is just messed up, but i don't want to restart X to find out :)
<ajmitch> I think it is
<ajmitch> or Xnest is
<ajmitch> ah, time to run to work :)
<Amaranth> xnest worked fine for me
<AndyFitz> so where are the fonts now?
<AndyFitz> cya ajmitch
<daniels> AndyFitz: oh, I see
<daniels> elmo: xfonts-utils needs to be in main when it hits the archive
<Amaranth> nothing like a nice hardlock to make you fix X
<Amaranth> that was...fun
<AndyFitz> lol
<Amaranth> gdmflexiserver + Ctrl-F8 == dead
<Amaranth> not going to try to reproduce :)
<Amaranth> ok, i lied. I tried to reproduce but since X works now it didn't do anything.
<AndyFitz> Amaranth, how did you get x to work.  what simlinks needed to be setup ?
<Amaranth> ln -s /usr/X11R6/bin/ /usr/bin/X11 is all i needed
<jsgotangco> morning
<Amaranth> plus i had to manually edit my xorg.conf because it was trying to use "Generic Mouse" and "Configured Mouse" but I only had the latter
<Amaranth> the fonts thing wasn't an issue, the fonts seem to exist in both places for now
<AndyFitz> radness.  okay thanks.  i'll have a go   brb
<ghpolo> last dist-upgrade removed x-window-system ?
<daniels> so don't do that
<ghpolo> me ?
<daniels> if a dist-upgrade wants to remove something that looks like it's essential, don't dist-upgrade
<ghpolo> ah ok, it was with me ;p
<tseng> daniels b0rk muh x0rgz
<tseng> :'(
<AndyFitz> g'day  again
<tseng> hi andy
<AndyFitz> tseng, how goes mate ?
<tseng> good thanks
<AndyFitz> ln -s /usr/X11R6/bin/ /usr/bin/X11    didnt work.  i had to create /usr/bin/X11  why would this now change anything 
<jdub> `anthony: really there?
<AndyFitz> speaking from damn centericq again :-P,  im guessing it has nothing to do with my previous xfonts-utils /  xutils issue
<daniels> nope, different issue
<ghpolo> yes AndyFitz 
<ghpolo> it changed several files
<ghpolo> same here
<AndyFitz> funky,  also X is not executable  but when i chmod 777 X it doesnt do anything
<ghpolo> doing a simple ln worked for me
<AndyFitz> ghpolo,  what ln did you create ?
<ghpolo> ln -s /usr/X11R6/bin /usr/bin/X11
<AndyFitz> ghpolo,  yeah thats been created
<AndyFitz> bugger,  no idea why X isnt executable  or wanting to be
<ghpolo> so strange
<ghpolo> after I did X worked again normally
<AndyFitz> the X is red in console  i have no idea what perm red is
<ghpolo> it is broken link usually
<AndyFitz> strange.  i tried again but the file exists
<daniels> /etc/X11/X should be pointing to /usr/X11R6/bin/Xorg
<daniels> (for the time being)
<ghpolo> it does here
<ghpolo> is that X red ?
<ghpolo> and Xorg exists ?
<AndyFitz> ln: '/usr/bin/X11//bin':  file exists
<ghpolo> that is wrong
<ghpolo> it shouldnt create a file named bin
<ghpolo> it should link the dir /usr/X11R6/bin as /usr/bin/X11
<AndyFitz> daniels:  so 'ln -s /etc/X11/X /usr/X11R6/bin/Xorg' ?
<Amaranth> other way around?
<ghpolo> other way
<AndyFitz> ok thanks
<ghpolo> anyways, what did you do to break your system so much ? ;p
<ghpolo> im using the latest dist-upgrade as breezy
<AndyFitz> file exists on that one too
<ghpolo> what shows when you do ls -l /etc/X11/X ?
<AndyFitz> ghpolo, yeah likewise mate
<ghpolo> maybe you did something wrong trying to fix startx after last dist-upgrade and broke something
<ghpolo> im not sure about what you did
<AndyFitz> etc/X11/X in red  -> usr/bin/X11/Xorg
<ghpolo> uh
<ghpolo> that is a problem
<ghpolo> what ls -l /usr/bin/X11/Xorg shows ?
<ghpolo> red color is a broken link
<ghpolo> meaning Xorg doesnt exist ;/
<ghpolo> or is somehow pointing to wrong place
<AndyFitz> i hadnt created any other simlinks asde from  'ln -s /usr/X11R6/bin/ /usr/bin/X11'  and for that it required me to make the dir X11 in /usr/bin   i thought that was kinda odd
<ghpolo> yes it is strange
<ghpolo> maybe you had the directory X11 before ?
<ghpolo> and then it tried to link /usr/bin/X11/bin ?
<AndyFitz> xorg does exist    and yeah x has always been in /etc/X11/X
<ghpolo> hmm
<ghpolo> so you didnt do the last dist-upgrade ?
<AndyFitz> this machines install has only existed since test1 of hoary so it wont have any Xf86 artifacts or anything
<ghpolo> it removed x-window-system and x-window-system-core
<AndyFitz> ghpolo,  i did do the  latest dist-upgrade
<ghpolo> i did aswell
<jdub> guys, just be careful with dist-upgrade - use -u and watch what it's doing
<jdub> then you won't get into pickles like this
<ghpolo> i believe you somehow forced a wrong link AndyFitz 
<ghpolo> but im not totally sure
<Amaranth> if you created an X11 dir in /usr/bin you're already off
<AndyFitz> ghpolo, the only links created manually by myself have been pasted here
<ghpolo> hmm
<ghpolo> ls /usr/bin/X11 shows what ?
<ghpolo> the same as /usr/X11R6/bin ?
<Amaranth> X11 was supposed to be a symlink to the /usr/X11R6/bin dir
<ghpolo> yes
<ghpolo> but last dist-upgrade removed that
<AndyFitz> jdub,  i'll watch it from now on obviously ;-) thanks
<ghpolo> so i remade it
<Amaranth> ghpolo: I know, I'm telling AndyFitz :)
<ghpolo> no problem
<AndyFitz> ghpolo  ls /usr/bun/X11 shows  a cyan 'bin'
<ghpolo> ah
<ghpolo> you did wrong link then ^^
<ghpolo> you could remove this link at /usr/bin/X11/
<ghpolo> then remove /usr/bin/X11
<ghpolo> and try ln -s /usr/X11R6/bin /usr/bin/X11 again
<AndyFitz> how do i remove the wrong link ?
<ghpolo> rm link
<Amaranth> rm
<AndyFitz> so rm link /usr/bin/X11 ?
<ghpolo> that is a directory i suppose
<ghpolo> do rm /usr/bin/X11/bin
<AndyFitz> or just rm the dir
<ghpolo> rmdir /usr/bin/X11
<ghpolo> then ln -s /usr/X11R6/bin /usr/bin/X11
<AndyFitz> oh bugger,  directory not empty.  if i remove the contents will that damage the other side of the link ?
<AndyFitz> i think it will
<ghpolo> it wont
<ghpolo> rm /usr/bin/X11/bin first
<ghpolo> then rmdir /usr/bin/X11
<AndyFitz> rmdir /usr/bin/X11  returns an error   : directory not empty
<AndyFitz> ok cool
<ogra> rm -r
<ghpolo> wait
<ghpolo> dont do rm -r
<ghpolo> maybe you did something else
<ghpolo> and it could damage
<ghpolo> remove the link inside it and try rmdir if it doesnt work check what else is there
<AndyFitz> ghpolo  i didnt
<AndyFitz> i am pretty silly but not going to wipe the contents and hurt myself further.   i did the order you just pasted
<ghpolo> ok then
<ghpolo> did you create the correct link ?
<AndyFitz> which link?  no i havent yet
<ghpolo> did you rmdir /usr/bin/X11 yet ?
<ghpolo> yet or already ?
<ghpolo> my english is bad
<AndyFitz> yes
<ghpolo> so just do ln -s /usr/X11R6/bin /usr/bin/X11
<AndyFitz> its gone without any grief, thank you
<AndyFitz> done
<ghpolo> nice
<AndyFitz> am i also meant to create another link for xorg ?
<ghpolo> everything should be right now
<AndyFitz> sweet.  okay i'll check it out
<AndyFitz> thanks ghpolo, cheers amaranth
<ghpolo> no problem ^^
* Amaranth goes back to loving etiquette :)
<AndyFitz> i'll watch myself from now on :)
<ghpolo> someone know a mail client or somehow did a plugin or filter to separate messages by threads ?
<AndyFitz> font paths :-/  lol
<AndyFitz> okay font paths need to be changed :-/
<ghpolo> cant find fixed font ?
<AndyFitz> USR/LIB/X11/FONTS/ ?
<ghpolo> what is says ?
<ghpolo> cant find fixed fonts ?
<daniels> AndyFitz: change /usr/lib/X11/fonts references to /usr/share/X11/fonts
<AndyFitz> daniels: ta mate.
<AndyFitz> wootage!!!  
<luis_> daniels: if I may ask, is there an ETA for packages that aren't busted? :)
<AndyFitz> thanks heaps.  its crusing along gdm is up.  time to kill the console apps
* luis_ waits for daniels to beat him
<daniels> luis_: the current packages are fine
<daniels> luis_: it's just teaching you a lesson if you've decided to customise your config :P
<luis_> hehe
<jdub> http://www.cebit.com.au/images/logos/frontbanner.jpg
<jdub> "no, that's why i made the mistake of getting plastic surgery - I AM NOT A MONSTER!!!"
<luis_> ah, so if I haven't fucked with anything, I'm find?
<luis_> fine?
<daniels> luis_: sort of :P
<jdub> luis_: when you're upgrading, just use 'apt-get upgrade -u'
<jdub> luis_: and every now and then use dist-upgrade -u
<jdub> luis_: this lets you track exactly what is going to be added/removed
<jdub> and keeps you safe most of the time
* luis_ uses synaptic
<jdub> except for when daniel mucks something up *in* a package :)
* luis_ is mostly convinced apt/dpkg suck
<schweeb> lies!
<schweeb> apt rules. IMO
<ghpolo> i agree with luis_ 
<jay> apt/dpkg are better than anything else that exists.  so if it sucks it sucks the least :)
<luis_> no offense, but, like, the command line options, the fact that one can't install local packages, the other can, etc., etc.
<luis_> I could go on for ever
<jdub> synaptic doesn't buy you anything more than apt, it just makes it harder for you to see what's going on in your *devel branch* os :)
<jay> luis_: somebody posted a script to the devel mailing list for integrating all the commands into one if that's your thing
<schweeb> I was just about to mention that
<jdub> luis_: those are pretty irrelevant in this instance
<luis_> jdub: <shrug> it's *gasp* easy to use
<jdub> try smart
<jdub> luis_: easy to use isn't helpful when it doesn't stop you from too-easily breaking your system
<jdub> you've probably clicked "smart upgrade, don't ask me again", too.
<luis_> I have
<luis_> and why 'stupid' (implicitly) is an option, I'm not sure
<jdub> because the guy who chose the terms didn't learn english first
<schweeb> apt/dpkg uses the cat/grep/head/tail etc... philosophy... small utilities with one duty that can be used in conjunction with each other
<luis_> AFAICT, one is 'get the dependencies right', and the other is 'don't bother to get the dependencies right'
<jdub> luis_: nup
<jdub> luis_: dist-upgrade will add and remove willy-nilly to resolve an upgrade.
<jdub> luis_: upgrade is more conservative.
<jdub> i recommend using upgrade in the general case
<jdub> (which is why the common occurance of "smart upgrade, don't ask me again" is so bad)
<luis_> I always check what is being done before hitting OK in synaptic
<luis_> I'm not braindead
<luis_> else I'd have been screaming in here about my missing tomboy weeks ago :)
<jdub> its the software's fault, not yours
<luis_> don't worry
<luis_> I place all the blame on the software :)
<jdub> (but largely unrelated to facile problems with apt)
<jdub> you're assuming i'm not, thus the point
<luis_> <shrug> I have no particularly deeply held opinions about apt; I mean the infrastructure may or may not be in place to make a fine tool.
<luis_> (the red-carpet team had strong opinions about that, but I don't really respect their judgment on the matter :)
<luis_> but, yeah... apt-get/dpkg as a combo feel like a substantial step backward from the design/flexibility/usability of rug. It's really the only thing I miss right now from rh+ximian or suse+ximian.
<justdave> Ubuntu Upgrade Manager does a normal upgrade
<justdave> er, Update Manager, whatever it's called :)
<justdave> and it prompts you to go use Synaptic if it'll break dependencies
<justdave> (I had that happen to me the other day)
<jdub> try smartpm
* luis_ apt-get installs
<luis_> hrm
<luis_> smart does, uh, not do what I want it to
<jdub> smart needs config out of the box
<daniels> warty still has security support, right?
<jdub> daniels: absolutely
<daniels> sweet
<daniels> i was just doing my regular dist-upgrade on a fd.o box running warty and thought I should make quadruply sure :)
* luis_ gives up for tonight
<jdub> should gcc-3.3 still be in main?
<mdz> jdub: it'll fall out when nothing build-depends on it anymore
<jdub> ok
<jdub> mdz: welcome back, btw :)
<jdub> mdz: good break?
<fabbione> morning
<ajmitch> hi
<jdub> can you put a pci card in a pci-e slot?
<ghpolo> is someone able to compile xen-unstable using latest breezy upgrade ?
<daniels> jdub: don't believe so
<fabbione> daniels: how broken is X today?
<crimsun> http://www.gen-x-pc.com/pci_basic.htm says "yes", jdub 
<fabbione> daniels: meaning.. can i upgrade and still work or will i be doomed to death?
<ghpolo> just some links to be done fabbione I believe
<ghpolo> that is what I did
<jdub> crimsun: hrm, rad :)
<jdub> hrm
<jdub> it says driver compatible
<jdub> not seeing hardware compat
<crimsun> about halfway down the page
<crimsun> "PCI-Express slots will also accept older PCI cards, which will help them become popular more quickly than they would if everyone's PCI components were suddenly useless."
<jdub> ahr, indeed
<jdub> cool
<jdub> was just looking at this:
<jdub> http://global.shuttle.com/Product/Barebone/SN25P.asp
<jdub> looks very tasty
<fabbione> oh yeah
<fabbione> i have seen them in some shops here around
<daniels> fabbione: don't know.  try it and see. ;)
<daniels> fabbione: might need to change the /etc/X11/X symlink
<tepsipakki> compare the pci/pci-e connectors.. no way to put a pci card on a pci-e slot ;)
<fabbione> daniels: dselect output is scary.. i guess i will wait a bit and work in chroot :)
<daniels> heh :)
<daniels> tepsipakki: depends on how many lanes
<daniels> it can physically fit in an x16, but not in an x1
<jdub> oh
<jdub> http://sys.us.shuttle.com/XP17.aspx
<jdub> ^ that's nice too
<daniels> elmo: any chance I can find out what B-Ds on a) libxp-dev, b) lesstif-dev?
<tepsipakki> daniels: but the card would go in reversed (the short part of the connector is on the other end) ;)
<tepsipakki> hmmh, actually isn't
<tepsipakki> oh f.., it is
<tepsipakki> wrong picture..
<svenl> hi.
<svenl> I was wondering what would be the best way to get a universe package rebuild ? 
<daniels> you can't get rebuilds, only upload new source versions
<daniels> and universe stuff -> #ubuntu-motu
<daniels> they take care of all the unvierse packages
<svenl> hardware-monitor, which i maintain for debian, seems broken in breezy.
<svenl> Oh, 
<svenl> YAC :/
<svenl> i think freenode is refusing me to subscribe to so many channels :/
<svenl> 08:15 [freenode]  -!- Cannot join to channel #ubuntu-motu (You have joined to too many channels)
<svenl> oh well.
<Amaranth> you can join it, just not all at once
<Amaranth> it's to prevent bot floods, i think
<svenl> Amaranth: yeah.
<svenl> Amaranth: still doesn't help me, since i don't think one of the channels i have open now i can dispense with.
<Amaranth> you should be able to join it now
<Amaranth> it just doesn't let you join a whole crap load at once, iirc
<svenl> Amaranth: not.
<svenl> Amaranth: i only joined this ones, the other where joined since days.
<svenl> but i am on the ppc devel channels, some debian ones, 4 ubuntu ones, and the pegasos support channels.
<Amaranth> odd
<Amaranth> i've been in about a dozen channels before
<svenl> i think the barrier is beyond a dozen :)
<svenl> ok, breakfast time.
<bob2> 20 is the limit
<AndyFitz> hrm ,  is anything happening to esd ?
<Amaranth> i thought it got replaced by polypaudio
<schweeb> no
<schweeb> wasn't quite ready in time for hoary
<schweeb> polyp got pulled about a month before release
<schweeb> iirc
<fabbione> hey pitti
<pitti> Morning
<AndyFitz> schweeb,  so whats happening between the two in breezy ?
<Lathiat> is it just me or is ubuntu using dmix by default now
<jdub> AndyFitz: potential to use polyp
<jdub> Lathiat: ick, no
<AndyFitz> I say this because the esd sound quality is atrocious in breezy 
* Lathiat wonders why the hell his system is then
<Lathiat> (and its not working very well, although ive had it working fine, but i have no alsa config files)
<Amaranth> i thought the plan for breezy was to use dmix when we could
<schweeb> AndyFitz: esd sound quality is atrocious everywhere
<svenl> daniels: the fonts are in /usr/share/X11/fonts, even with -12, is that as you would expect ? 
<AndyFitz> lol  I agree schweeb   ,  only this time its outdone itself.    rhythmbox won't play without esd,  and its pouring out some really interesting sounds along with playback
<schweeb> I seem to recall hearing recent stirrings of DMIX, but jdub would probably know better than I would
<Amaranth> AndyFitz: Did you try telling gstreamer to use alsa?
<schweeb> AndyFitz: RhythmBox uses gstreamer
<jdub> schweeb: it's on the "to try" list for sound infrastructure spec
<jdub> but it's spew
<schweeb> AndyFitz: open the gst config tool, and switch from ESD to alsa
<Amaranth> you'll have to restart rhythmbox
<schweeb> jdub: I've had mixed results with it
<schweeb> once when I set it up, all of my stuff played at like 1.25x speed
<schweeb> heh
<Amaranth> haha
<luis_> danm
<AndyFitz> rhythmbox won't play without esd running,      schweeb  yeah I can change that.  just don't know what mutated esd
<luis_> oops, wrong chan
* Amaranth hugs sound cards that don't suck
<jdub> schweeb: mixed results, eh? that sounds like the optimal outcome. :-)
<schweeb> you're punny :p
<Micksa> anyone know of a program suitable for quickly browsing through multi-page tiff files?
<jdub> Micksa: build the very latest evince
<Amaranth> didn't support for tiff files get added to evince?
<Treenaks> Micksa: evince
<Amaranth> evince is becoming our Preview :)
<Micksa> ta
<jdub> Micksa: or wait for sebuild to get to it when he wakes up
<schweeb> either that or gFaxView or whatever it's called (maybe)
<jdub> Amaranth: only i've yet to convince jrb to integrate static image viewing too
<Amaranth> sebuild, lmao
* Treenaks waits for someone to fix X
<Micksa> is evince what that guy was showing off at the gnome miniconf at LCA?
<Amaranth> Treenaks: It's only going to break more, but there is a simple way to make it work now. :)
<Treenaks> Amaranth: there is? :)
<Treenaks> Amaranth: apt pinning + hoary? :P
<Amaranth> Treenaks: ln -s /usr/X11R6/bin /usr/bin/X11
<jdub> Micksa: i don't believe anyone was showing off evince at gca.
<Treenaks> Amaranth: yes, that was the easy part
<Amaranth> Treenaks: then dpkg-reconfigure xserver-xorg
<Treenaks> Amaranth: then it started whining about "fixed"
<Amaranth> the fonts?
<Treenaks> Amaranth: yes
<Amaranth> hmm, my fonts are in /usr/share/X11/fonts and /usr/lib/X11/fonts, figure out which one you have and edit xorg to match
<Treenaks> good idea :)
<Amaranth> err, xorg.conf
<Amaranth> i don't know why i have both, most people don't
<Treenaks> Amaranth: I did see a "I didn't update xorg.conf because you fiddled with it" message when I was upgrading the other day
<AndyFitz> amaranth, how do I instruct gstreamer to switch to alsa ?
<Treenaks> AndyFitz: gstreamer-properties ?
<AndyFitz> there are a few  gst gui tools  but none that appear to manage that 
<Amaranth> System->Preferences->Multimedia Systems Selector
<schweeb> should be in the control center
<schweeb> ya
<Amaranth> or gstreamer-properties, they're the same thing
<AndyFitz> not in breezy,  gstreamer-properties   and  the control-center  shortcut are both missing 
<Amaranth> i have them?
<schweeb> as do I
<AndyFitz> all gstreamer apps I have installed are prefixed with gst-
<Amaranth> reinstall gnome-media
<AndyFitz> ;)  looks like I can't  :      Depends: dbus-1 but it is not going to be installed    Depends: libhal0 but it is not going to be installed  Depends: libnautilus-burn1 but it is not going to be installed
<Amaranth> *boggle*
<AndyFitz> will always dist-upgrade -you from now on
<AndyFitz> you = U  damn gaim autoreplace 
<Amaranth> um, your system is screwed :)
<AndyFitz> um  yeah.   all with one dist-upgrade 
<Amaranth> did it remove a lot of things? :)
<AndyFitz> she'll be right.  xmms  ... until this all blows over  lol 
<AndyFitz> Amaranth,  enough things to worry about but not enough to  make my system keel over and die..    I'm sitting in the threshold of painful package migration
<Treenaks> hmm... an empty dialog box saying "Xsession:" :)
<Amaranth> ok, new idea :)
<Lathiat> yeh i get that too
<Amaranth> AndyFitz: load up gconf-editor, change /system/gstreamer/0.8/default/audiosink to alsasink
<schweeb> fabbione: new xen just released, fyi
<AndyFitz> Amaranth,  ah sweet  the gconf entry is still there.  all good now :)
<AndyFitz> well,  the sound is all good lol
<fabbione> schweeb: you want to tell Mithrandir and smurfix :)
<Amaranth> the sad thing is that i knew that
<fabbione> schweeb: i am not on Xen anymore
<fabbione> they are
<schweeb> ahh :)
<fabbione> Xen 2.0.6 ?
<fabbione> bah.. changelog points me to bitkeeper...
<fabbione> how cool...
<smurfix> They've got a few weeks to switch yet :-/
<fabbione> hey smurfix 
<Amaranth> fabbione: you could ust that tool to pull from bk repositories that caused the big flamefest :)
<Amaranth> err, use
<smurfix> fabbione: still nothing from the afterburning guys?
<fabbione> Amaranth: i don't need to use bk when there are tarballs available
<fabbione> smurfix: you and Mith were supposed to get in contact with them
<fabbione> but i haven't heard anything from ben
<smurfix> fabbione: neither have I
<fabbione> did you try to mail him?
<smurfix> last week
<fabbione> ok
<fabbione> well let's start working on xen than
<fabbione> if they are not interested anymore.. it's not our problem :)
<smurfix> I found their whitepaper and CVS repo online this weekend though
<smurfix> so I'll start to look into it in the next few days
<fabbione> for L4 or afterburner?
<fabbione> because iirc they had afterburner in arch...
<smurfix> afterburner and xen, says the download page
<fabbione> uh ok
<smurfix> haven't had time to actually look through it yet :-/
<Mithrandir> smurfix: url?
<smurfix> Mithrandir: http://l4ka.org/projects/virtualization/afterburn/download.php
<smurfix> they want to patch binutils :-/
<fabbione> oh jeee
<smurfix> no L4 code that I can see
<fabbione> L4 was on a separate url
<Mithrandir> the l4 code is pistachio and marzipan
<fabbione> yeah
<smurfix> Mithrandir: ah, that makes sense
<smurfix> Anyway I'll grab time this week to try and set things up here
<Mithrandir> the cvs repo seems to be what we want, it's the xen wedge, the l4 wedge, the patches to linux.
<Mithrandir> looks like we're just missing userspace support.
<Amaranth> speaking of Xen, when CPUs support the Vanderpool extensions, does anyone know if it will be possible to run linux and windows at the same time?
* fabbione needs some chroots love
<fabbione> elmo: you awake?
<fabbione> thom: ?
* pitti joins the need for love
<fabbione> pitti: i hunted down the problem with the kernel build/dpkg crap
<fabbione> pitti: just be sure to get the latest kernel-package
<fabbione> it's another side effect of dpkg
<jdub> Amaranth: xen requires client os support
<Amaranth> jdub: It won't with the Vanderpool CPU extensions, from what I've been told.
<pitti> Hi carlos 
<carlos> pitti, morning
<carlos> pitti, do you think it's possible to recreate the translation tarballs for hoary again (as you did without using buildd)?
<ajmitch> hi pitti 
<pitti> carlos: well, it's a PITA, but I think so. Why?
<carlos> pitti, so they get the .pot file regenerated 
<pitti> ajmitch: hey, how are you?
<ajmitch> pitti: I'm alright :)
<pitti> carlos: I did not patch Hoary's cdbs
<ajmitch> getting back into breezy stuff after a busy week
<ajmitch> hi chmj 
<chmj> hey andrew
<carlos> pitti, we could use a nonofficial version with the patch, couldn't we?
<pitti> carlos: well, if I get the required dchroot support from thom/elmo, that would work
<ajmitch> bbl
<carlos> pitti, will check with them and will tell you if it's possible, ok?
<pitti> yes
<batma8> anyone up at this hour
<AndyFitz> batma8 yep
<batma8> right on man
<batma8> the guys in ubuntu try to help, but im still pretty lost
<AndyFitz> yeah the big kids stay away until 6pm
<batma8> i have an averatec 3250, and i cant get the wireless to work
<AndyFitz> awake :)   GMT+10
<batma8> its 2 am here
<AndyFitz> is it on the supported list ?  do you have to use ndiswrapper ?
<batma8> it is suported and i have ndiswrapper
<batma8> but when i get it installed it said its an invalid driver
<batma8> but i think its a location thing, not a driver thing
<batma8> this is only my 2nd day in linux
<batma8> so im still hella confused
<Treenaks> confused? why?
<batma8> http://www.ubuntuforums.org/showthread.php?t=9454
<batma8> i follow that exactly
<batma8> to a tee
<batma8> and i get errors
<batma8> not sucess
<Treenaks> what's it with the forums.. have you followed the guide on the wiki? (http://wiki.ubuntu.com/)
<batma8> yup
<batma8> that is step 2
<batma8> http://www.ubuntulinux.org/wiki/Rt2500WirelessCardsHowTo
<AndyFitz> are you sure its the correct inf ?  do you have the DLL as well ?
<AndyFitz> keybuk was a ninja and set this up for me.  but I remember not having the right windows binaries.  inf and dll   
<batma8> i do
<batma8> then i get this 
<batma8> sudo apt-get install build-essential linux-headers-$(uname -r)
<batma8> and put it in my terminal
<batma8> and it spits this out
<batma8> build-essential is already the newest version.
<batma8> linux-headers-2.6.10-5-386 is already the newest version.
<batma8> 0 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
<batma8> W: Couldn't stat source package list cdrom://Ubuntu 5.04 _Hoary Hedgehog_ - Release i386 (20050407) hoary/multiverse Packages (/var/lib/apt/lists/Ubuntu%205.04%20%5fHoary%20Hedgehog%5f%20-%20Release%20i386%20(20050407)_dists_hoary_multiverse_binary-i386_Packages) - stat (2 No such file or directory)
<pitti> Hi seb128 
<batma8> W: You may want to run apt-get update to correct these problems
<batma8> root@ubuntu:/home/batma8 #
<Treenaks> batma8: you don't need that, ndiswrapper is included
<seb128> hey pitti 
<seb128> what's this flood?
<Treenaks> seb128: #usersupport
<seb128> not the right chan
<Treenaks> true
<batma8> i do apologize
<batma8> but you guys have helped me more in 2 mins than all day in #ubuntu
<batma8> :)
<seb128> not a reason to turn this chan to a #ubuntu2 :)
<seb128> :p
<batma8> :)
<batma8> point taken
<batma8> i think i may have just made some progress
<fabbione> Mithrandir, smurfix: xen 2.0.6 code seems to be more clean
<fabbione> at least it doesn't fail on make ARCH=xen dep (2.4.30
<smurfix> well, they want to get into the mainline kernel, they better have to get clean. ;-)
<fabbione> ehhe
* fabbione needs to go offline for a bit
<Thom_Holwerda> hi, is the topic correct? breezy still broken atm?
<daniels> yes
<Thom_Holwerda> any idea when the transtition is complete? probably difficult to say, aint it
<daniels> quite, yeah
<daniels> there's also some pretty awesome X-related breakage
<Thom_Holwerda> well i broke my breezy ubuntu install by updating (missed the nottion about the transition) so i was wondering if it was done yet-- guess ill install hoary and just wait for the transition to be complete :)
<Amaranth> yeah X-related breakages are nuts
<Treenaks> daniels: yeah, they're annoying :)
<Kamion> fabbione: I've uploaded partman-auto-lvm at last - heading towards Debian NEW at the moment
<fabbione> Kamion: rocking!
<fabbione> Kamion: i think in a relatively short time we should be able to seed 2.6.12 to main and if you feel ok we can start building d-i on top of it
<fabbione> right now  i am blocked because i can't build on amd64/ppc
<doko> morning all
<hunger> hi doko
<pitti> Moin doko
<elmo> daniels: http://people.ubuntu.com/~james/paste/010.txt
<elmo> daniels: http://people.ubuntu.com/~james/paste/011.txt
<elmo> fabbione: ?
<mvo> hey doko 
<fabbione> hey elmo
<fabbione> elmo: i need an update for breezy and breezy-i386 on concordia and breezy on davis, to get the latest dpkg and kernel-package
<fabbione> (at least)
<fabbione> a general update would be fine too :)
<daniels> elmo: thanks dude
<daniels> thom: ?
<ogra> hmm, who did put the hint to disable esd on RestrictedFormats ? .... and backports are advertised there now too...
<ogra> morning
<mdke> morning ogra
<daniels> whoops
<daniels> infinity: so are you what passes fora  mozilla maintainer nowadays, or should I keep harassing thom?
<daniels> ** mozilla has an unsatisfied build-dependency: libxp-dev
<daniels> ** mozilla-firefox has an unsatisfied build-dependency: libxp-dev
<daniels> ** mozilla-thunderbird has an unsatisfied build-dependency: libxp-dev
<daniels> infinity: i would like for the above to not be an issue anymore
* hunger hates developers doing "whoops".
<infinity> daniels : Bugging thom is always a good thing, just on principle, but I can look at those.
<infinity> daniels : Are we allowed to upload CXX apps yet, though?
<fabbione> you can upload, but they don't get autobuilded
<daniels> infinity: probably not
<infinity> fabbione : Well, yes, that's what I meant.. "Is there any point?"
<ogra> infinity, check the dependencys in any case (do a pbuilder run or whatever)
<daniels> hunger: 'whoops' -> i hit ctrl-shift-w instead of ctrl-w and didn't start irssi in screen, so it died
<fabbione> infinity: no :)
<infinity> daniels : While we're whining about things, why does the default xorg config use such ridiculously conservative timings?  1600x1200 at 60Hz really hurts.
<hunger> infinity: I am using that setting... it is fine.
<Mithrandir> infinity: get an LCD? :)
<infinity> Mithrandir : A big CRT was a lot cheaper. :)
<Mithrandir> infinity: true enough.
<daniels> infinity: #14xx or something
<elmo> fabbione: done
<daniels> infinity: trawl my bug list for 'vbetool should use x86emu, subsume ddcprobe'; wasn't allowed to fix it for hoary
<daniels> infinity: itmt, just nuke the ranges from xorg.conf altogether.  nv, although really stupid, is smart enough to work the ranges out for itself in this case.
<Mithrandir> daniels: or just use hwinfo instead?
<daniels> Mithrandir: well, need to properly check out hwinfo
<infinity> daniels : Yeah, ISTR that both nv and nvidia could do so just fine, it was just a shock to have my initial config be kinda whacky.
<daniels> Mithrandir: been too busy trying to stop you whining by fixing xorg to check out hwinfo :P
<daniels> infinity: the downside of not having vm86
<fabbione> elmo: thanks!
<Mithrandir> daniels: :P
<daniels>  * Read the info out of the 'SuSE=' entry in /proc/cmdline. It contains
<daniels>  * (among others) info from the EDID record got by our syslinux extension.
<daniels> WRONG! WRONG! WRONG!
<mjg59> They get the EDID in SYSLINUX?
<mjg59> Christ
<elmo> haha
<mjg59> I guess it means they have working real mode...
<infinity> That's pretty insane.
<pitti> sjoerd: here?
* hunger grumles that it can't be sane if it comes behing SuSE=
<daniels> mjg59: and pass it in through the kernel command line
<daniels> mjg59: how awesome is that??
<daniels> Mithrandir: thanks for the pointer, dude :P
<hunger> I really do not understand why suse has such a following... people even stick with it even though it has screwed them several times in a row on upgrades.
<mjg59> daniels: Well, otherwise they might have to extend the kernel bootloader protocol
<Mithrandir> daniels: well, it works without the SuSE= entry too. :P
<mjg59> daniels: Hang the fuck on
<mjg59> daniels: Surely they're only using syslinux for the installer?
<mdke> hunger, someone told me that suse is exceptional
<hunger> mdke: exceptional what? stupid?
<Mithrandir> mjg59: what do you think of my idea to get syslinux to use different config files based on cpuid?
<mdke> hunger, just exceptional
<mdke> hunger, means very good
<mdke> haven't tried it myself tho
<mjg59> Mithrandir: Hmm, hadn't seen that
<hunger> mdke: It is exceptional in doing everything in its own way, ignoring the settings I put into the normal config files.
<Mithrandir> mjg59: you want it for the tripleplay DVD.
<hunger> mdke: If something breaks you need the exceptional suse training to fix stuff.
<daniels> mjg59: god only knows
<mjg59> Mithrandir: Nnf. Fun.
<mdke> hunger, hmm
<Mithrandir> mjg59: got any better ideas, really?
* infinity is concerned by the complete lack of options and verbosity in this nautilus ISO burning extensions...
<mjg59> infinity: If you want exciting features, then Nautilus isn't really the right program to be burning ISOs with...
<HrdwrBoB> I find it very exciting
<sjoerd> pitti: pong
<pitti> sjoerd: nevermind, sorry for disturbing :-)
<sjoerd> np
<hunger> daniels: Could you please set the path in update-fonts-dirs for mkfontdir? Currently it fails since it does not find that programm in /usr/X11R6/bin.
<hunger> daniels: Shall I write a bugreport?
<daniels> hunger: no, because it's already fixed
<hunger> daniels: Great, thanks!
<daniels> upgrade to 6.8.2-12 of xfonts-*, which will pull in xfonts-utils
<hunger> daniels: I did... that is when it failed.
<hunger> daniels: mkfontsdir is installed, but it is not found by the update-script.
<doko> daniels: you left a channel ;) what's the state of the xbase-clients dependency on xlibmesa-glu?
<doko> thom: ping
<daniels> doko: d'oh
<daniels> doko: still in the middle of a test build
<hunger> daniels: My path still points to /usr/bin/X11, I guess that is why the script fails for me.
<daniels> hunger: your path for what?
<hunger> daniels: $PATH of the root user.
<doko> daniels: ok, does this build puts the X headers to /usr/include as well?
<daniels> hunger: ok, I see
<daniels> doko: no, and it won't
<hunger> daniels: Same for the normal user...
<daniels> doko: things are only moving to /usr once they've been modularised
<daniels> doko: doing that within the monolithic tree a) is so WORLD OF HURT, b) would break nvidia/fglrx
<daniels> as much as I despise binary-only drivers and wish they would die in the arse, we can't break them right now
<daniels> hunger: fixed now, thanks
<hunger> daniels: You are welcome.
<hunger> daniels: Thanks for providing me with such a nice distro:-)
<doko> daniels: a) only effects you ;-) b) doesn't hurt me, so go for it :)
<pitti> trulux: your new kernel patch works great! However, I fixed another tyop
<pitti> typo, even
<ogra> heh
<daniels> doko: no, it effects everyone, since I spend a week doing nothing else
<daniels> s/effects/affects/
<jsgotangco> bye bye
<AndyFitz> holy new planetgnome
<Lathiat_> yeh i like it
<AndyFitz> likewise
<AndyFitz> oh no I don't!!!!
<AndyFitz> eww tables
<tseng> AndyFitz: CSS SNOB!
<ogra> doko, dpkg-architecture: warning: Unknown gcc system type amd64-linux, falling back to default (native compilation)
<ogra> doko, is this wanted ?
<ogra> i see it in all recent amd64 builds
<ajmitch> hi ogra 
<ogra> hey ajmitch 
<AndyFitz> http://planet.gnome.org/  oh hells no
<ajmitch> AndyFitz: lovely, innit? :)
<AndyFitz> tseng, you are witnessing semantic molestation
<AndyFitz> http://validator.w3.org/check?uri=http%3A%2F%2Fplanet.gnome.org%2F
<tseng> oh..
<tseng> its not xhtml
<tseng> they should mark it as html4 then? i dont see anything thats a big deal
<tseng> besides ALT
<tseng> leaving out alt on a site that big is lame
<AndyFitz> no its not valid html4.01 either
<AndyFitz> thats what its marked as
<tseng> 4.01 makes you close tags with /> ?
<ajmitch> ogra: I'm finally back to the c++ transition stuff :)
<AndyFitz> : there is no attribute "BACKGROUND"  anyway this isnt the room to winge
<ogra> ajmitch, great
<AndyFitz> yeah its a whore of a html page
* ogra goes to do the same now
<ajmitch> ogra: who should I CC in the bug reports?
<AndyFitz> it wants a piece of all doctypes.  it doesn't care where it gets its next fix
<Lathiat_> hmm
<ogra> ajmitch, me or doko
<Lathiat_> looks like the w3 parser got confused
<Lathiat_> (42th error for p.g.o)
<ajmitch> ogra: ok, will do
<tseng> AndyFitz: hah
<tseng> wow
<Lathiat_> oh, maybe not
<ogra> ajmitch, but as long as you note it on the wikipage, there is no need for a cc
<Lathiat_> you even need &amp; in HREFs... never knew that.
* tseng -> work
<Treenaks> Lathiat_: /everywhere/
<AndyFitz> ciao tseng
<ogra> tseng, dont lt the php bugs bite you ;-P
<ogra> let even
<ajmitch> ogra: great, I'm slowly filling my my spots on the wiki page
<ogra> great :)
<ajmitch> although some diffs are far too large
<ajmitch> silly build systems
<doko> ogra: there's already a bug in bugzilla
<ajmitch> hi doko 
<doko> ajmitch: hi
<ogra> doko, ah, ok
<doko> ogra: there are currently many CXX libs in the bug reports, which are not yet uploaded. which ones do you take care of?
<ogra> doko, i'll go through all motu claimed ones now...
<doko> ogra: thanks
<mvo> ping seb128 
<seb128> mvo: pong
<daniels> god the monolithic is a hulking piece of shit
<ogra> hulking ? 
<ogra> does that mean its green ?
<daniels> hulking == big, heavy, ungraceful
<daniels> also, stupid
<ogra> heh
<daniels> did I mention that I hate it?
<Mithrandir> fix it, then
<Mithrandir> (-:
<daniels> the only way to fix it is to destroy it
<daniels> and people keep distracting me from that by reporting these bug thingies
<fabbione> at least the big green thing was working
* fabbione ducks
<daniels> the modular bits work
<daniels> they just need a little bit of encouragement
<fabbione> are they shy
<fabbione> ?
<daniels> a little, yeah
<daniels> but when I fixed update-fonts-*, the build took under ten seconds
<Mithrandir> for all of the modular bits?  Impressive.
<daniels> just for xfonts-core
<daniels> which has a debian/rules consisting of a bunch of install commands
<Lathiat_> daniels: do you have the issue i have with keyboard shortcuts not working ?
<daniels> Lathiat: no, because I haven't restarted my X server for myriad reasons
<Lathiat> daniels: ah. :)
<Lathiat> your smarter than me i guess :)
<daniels> Lathiat: (i test by starting new X servers and checking it all looks alright, and I have way too many things open on both machines to restart gdm on either)
<daniels> my guess would be that you'd need to link /usr/lib/X11/xkb -> /etc/X11/xkb, and /usr/bin/X11/setxkbmap -> /usr/X11R6/bin/setxkbmap
<Lathiat> i dont have a /usr/lib/X11/xkb
<daniels> oh yeah, and /usr/bin/X11/xkbcomp -> /usr/X11R6/bin/xkbcomp
<daniels> right -- which is the problem
<Lathiat> right, where do i find that?
<daniels> you need to have one, which is a symlink to /etc/X11/xkb
<Lathiat> oh right
<daniels> sudo ln -s /etc/X11/xkb /usr/lib/X11/xkb
<daniels> sudo ln -s /usr/bin/X11/setxkbmap /usr/X11R6/bin/setxkbmap
<daniels> er
<daniels> sudo ln -s /usr/X11R6/bin/setxkbmap /usr/bin/X11/setxkbmap
<Lathiat> ok i'll try that thanks, brb
<daniels> sudo ln -s /usr/X11R6/bin/xkbcomp /usr/bin/X11/xkbcomp
<Mithrandir> daniels: I have no /usr/bin/X11 and I want to scream.
<daniels> Mithrandir: so make one as a directory :P
<fabbione> elmo: dpkg on concordia and davis is still the old one
<pitti> seb128: just to confirm that I'm not completely dumb, you didn't upload the new gstreamer yet, did you?
<daniels> that directory should just go the f**k away, to be blunt
<elmo> fabbione: dpkg is blacklisted
<fabbione> elmo: i tought that we did allow the new one to go in
<fabbione> elmo: as doko said
<elmo> no, no one's unblacklisted the apps yet
<Kamion> elmo: I need a package which isn't in Ubuntu yet, but I need to make modifications to it for Ubuntu. Is it better to wait/ask for it to be synced into Ubuntu and then modify it, or just upload a modified version directly?
<fabbione> elmo: i don't get it.. doko said that dpkg could go in, and i can't build with the old one
<Lathiat> daniels: no luck
<fabbione> s/old/broken
<elmo> fabbione: doko talking doesn't magically unblock dpkg on 12 buildds
<Lathiat> daniels: anything i can do to debug it?
<fabbione> elmo: ok... i get it :)
<daniels> Lathiat: /var/log/Xorg.0.log
<elmo> fabbione: I thought/had hoped lamont would have updated the block list, but he apparently hasn't been around
<seb128> pitti: nop, not yet, on my todo list for today
* fabbione logs out again
<Lathiat> http://bur.st/~lathiat/Xorg.0.log
<fabbione> elmo: he is VAC
<jane_> can someone here edit/approve the PDASupport spec? http://udu.wiki.ubuntu.com/PDASupport
<pitti> seb128: ok, no worries, thanks
<elmo> Kamion: hum, preferably the former, but the latters not disastrous as long as you're sure you use the debian source as your base
<elmo> fabbione: yes, now, I mean thu/fri time
<fabbione> elmo: yup....
<Mithrandir> jane_: add it to colincharlesqueue? :)
<Kamion> elmo: ok
<jane_> Mithrandir: will do, but we actually want to push it through for approval asap
<Mithrandir> jane_: uhm, it totally lacks a DraftSpec/EditedSpec thing?
<jane_> Mithrandir: it is in Colin's queue
<Mithrandir> jane_: I think you'll have to get mdz to review it?
<Mithrandir> jane_: he's back from vacation now, so just putting it in his queue and notifying be email should work, I'd guess.
<jane_> Mithrandir: ok I made it a draft spec... ITA about mdz, I was hoping to get someone at it sonner though ;)
<jane_> Mithrandir: also mdz will be pretty swamped today
<Mithrandir> jane_: Colin did approve specs at UDU, you could ask him if he can do it; Kamion?
<Kamion> jane_: I'm looking at it now. What's the desperate hurry?
<daniels> Lathiat: what happens when you do setxkbcomp -layout us -model pc104?
<jane_> Kamion: well jsgotangco is chomping at the bit to get going on it
* fabbione goes offline
<Kamion> jane_: he should just get on with it :)
<fabbione> elmo: thanks for the updates anyway :) too bad i can't use them :/
<jane_> Kamion: it's the only one he is lead on, I think he wants the nod from someone that his spec is on target
<Lathiat> daniels: i have no setxkbcomp
<Kamion> non-Canonical people whose time we don't schedule shouldn't feel blocked on doing useful stuff by bureaucracy
<jane_> Kamion: I'll tell him to proceed then ;)
<Kamion> (it looks like a reasonable spec though)
<jane_> good
<Lathiat> daniels: i have 'xkbcomp' in /etc/X11/xkb/xkbcomp
<daniels> Lathiat: s/setxkbcomp/setxkbmap/g
<Lathiat> thats all i can see
<Lathiat> daniels: ah
<Lathiat> daniels: returns fine
<Lathiat> (no output)
<daniels> hrm
<daniels> so if you run xev now, does doing ctrl+w, alt+w, whatever, give you proper keysym names?
<Lathiat> x-windowxutils is being kept back if that affects anythign
<Lathiat> daniels: i get funny weird characters being printed
<Lathiat> XLookupString gives 1 bytes: (12) ""
<Lathiat> for example
<Lathiat> keysym 0x72 (no name)
<daniels> damnit.
<Kamion> jane_: I've done some editing and bounced it back to him with one question; he should feel free to go ahead with the rest of it though
<elmo> jane shouldn't be allowed to IRC without the 'w' suffix, it's too confusing
<jane_> Kamion: great thanks
<\sh>  /nick Tarzan
<jane_> haha
<\sh> couldn't resist ;)
<Kamion> I'm sure she's never heard that one before even once
* \sh is an old man, so old jokes are fitting 
<JaneW> yes that's was completely original ;)
<JaneW> still, better than 'Jane the pain'
<chmj> hmmm
<zyga> does anybody know what is netconfig.h?
<JaneW> \sh: just saw your hackergotchi pic :P
<\sh> JaneW: (C) by ogra ,)
<ogra> \mw makes the christians happy and uploads sword
<ogra> oops
<\sh> hehe...the world is really small...yesterday I had a phonecall from a old lycos europe colleague and he's working now for web.de/united internet...chief of security is another guy, who is working for serendipity php blog..so the circle is closed..funny relations
<Treenaks> \sh: "internet land" in the netherlands is small as well :)
<Treenaks> \sh: I've seen lots of people switch around between ISPs :)
<Treenaks> \sh: (while working at one)
<\sh> hmm..something got wrong now
<pitti> crimsun: here?
<daniels> elmo: could I please get the b-ds on lesstif2-dev, if it's not too much of a hassle?
<elmo> where?
<lamont> redland-bindings is missing a build-dep on whatever provides swig
<daniels> elmo: or, rather, an answer to 'can we punt lesstif to universe?'
<daniels> elmo: as a side-effect of desperately not wanting to have to support the security and logistical nightmare that is xprint
<elmo> someone'd have to fix vim
<elmo> and we'd have to be okay with dropping xpdf
<elmo> but other than that, it's not used
<AndyFitz> xpdf is no fun anyway
<daniels> elmo: \o/
<Treenaks> AndyFitz: not now we have evince
<daniels> elmo: what the frig does vim do with xprint?  gvim?
<elmo> daniels: err, I mean lesstif
<elmo> not xprint
<Mithrandir> daniels: it's probably just smoking crack.
<Mithrandir> :)
<mjg59> Oh rock lesstiff
<AndyFitz> all OSS postscript/pdf renderers suck,    evince is the least-bad gui 
<elmo> nothing's using xprint AFAICS
<elmo> well from the current 'xprint' source package
<daniels> elmo: right
<daniels> Kamion: we can drop vim-lesstif, right?
<Kamion> daniels: don't see why not
<daniels> word
<Kamion> daniels: it's already in universe
<elmo> Kamion: yes, but source b-d's on lesstif
<Kamion> yeah, I know
<elmo> and we've tried to avoid just dropping things we don't want before
<elmo> not sure, if it's worth bothering for something so old skool as lesstif tho
<Kamion> sure, but we haven't always managed that
<Kamion> c.f. kde
<Kamion> in fact I'm not convinced we've tried very hard ;)
<elmo> we did it for at least php
<elmo> but yeah
<Kamion> speaking of, can I have libqt-perl in main?
<elmo> Kamion: it pulls in a bunch of crap
<Kamion> it does?
<Kamion> like what?
<elmo>  o kdebindings: libsmokeqt-dev, libsmokeqt1
<elmo>    [Reverse-Depends: libqt-perl] 
<elmo>    [Reverse-Build-Depends: libqt-perl] 
<Kamion> AFAICS it only depends on C libraries
<elmo>  o libqt-perl: libqt-perl
<elmo>    [Reverse-Build-Depends: debconf] 
<Kamion> oh, build-depends
<daniels> Kamion: php4-universe is defined as 'tried very hard', imo ;)
<Kamion> elmo: kdebindings doesn't seem all that evil a thing to support
<elmo> Kamion: ok, your call.  I only left it because it didn't fall comfortably into the 'obvious' rule and was pending approval from someone who can actually approve stuff (
<daniels> Kamion: eeeeeeeeeeeeerrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
<Kamion> daniels: ?
<daniels> Kamion: kdebindings is a horror freakshow
<Kamion> daniels: how else do we get Qt bindings?
<daniels> that's its only redeeming feature, is that it's the only thing
<daniels> but the thing is utterly horrible, and almost entirely unused
<Kamion> ok, I'll ask the Kubuntu guys
<daniels> (which either explains why it's almost permanently broken, or is caused by that)
<Riddell> Kamion: I'm all for as much of KDE in main as possible :)
<daniels> i mean, if libqt-perl works, and you want to use that, then go ahead
<daniels> but I would strongly recommend punting every single other bit of kdebindings to universe
<Kamion> daniels: don't have a choice as far as debconf is concerned
<Kamion> it's either that, or no KDE frontend
<elmo> daniels: only the stuff mentioned gets pulled in
<Kamion> not that the KDE frontend is particularly excellent, but
<Riddell> kdebindings doesn't build ruby currently so as not to bring that into main
<Kamion> Riddell: I mean have you had problems with kdebindings per security/supportability?
<daniels> lamont: ping
<Kamion> with particular regard to SMOKE
<lamont> daniels: si?
<daniels> lamont: unping
* lamont is bouncing between the computer and cooking breakfast, fwiw
<\sh> Kamion: concerning python bindings for qt and kde it's a mess
<Riddell> Kamion: no security issues that I can ever remember, as daniels says it's not very much used
<daniels> Riddell: (the irony being that ruby seems to be the only language that kde developers are interested in aside from C++)
<Riddell> \sh: but they're not being built from kdebindings :)
<Kamion> \sh: ok, python bindings not at issue here though
<elmo> ogra: dude, could you use a real name in Changed-By too?
<elmo> R. [  48: <hostmaster@grawert.]  Accepted stk 4.2.0-4ubuntu1 (source)
<elmo> uploads from you look like that ATM
<Riddell> daniels: yes
<\sh> riddell: but they're inside ;) please delete them ;)
<ogra> elmo, whoops ....
<ogra> elmo, sorry for that
<Riddell> \sh: I removed them from subdirs so they're not built now
<daniels> \sh: if they're in universe and they aren't causing an FTBFS, it doesn't matter
<daniels> right now the package isn't ftbfs and the only thing under discussion is the qt perl bindings
<Riddell> actually it did fail to build on powerpc due to lack of memory
<elmo> say what now?
<elmo> Riddell: I kind of doubt it
<elmo> the box has 2Gb real, 3Gb swap - I suspect it's a compiler bug
<Riddell> Kamion: smoke is activly developed and supported so it should be fine in main, I havn't used it personally though
<daniels> wtf?
<daniels> Riddell: um, not even close
<daniels> Riddell: it died in the arse due to numerous gcc4 problems
<elmo> virtual memory exhausted: Cannot allocate memory
<daniels> wait, I lie, sorry
<daniels> misread
<daniels> yeah, that's pretty awesome
<Riddell> it's about a 9Meg file that's being compiled at -O2
<cartman> Riddell: how much ram the box have?
<daniels> cartman: 13:33 < elmo> the box has 2Gb real, 3Gb swap - I suspect it's a compiler bug
<Riddell> cartman: "2Gb real, 3Gb swap" says elmo 
<cartman> ewwww
<cartman> oh yeah
<daniels> it might be fixed in his binary driver (ugh) on his website
<daniels> erk, ww
<cartman> as this is on ppc, would it worth to try with apple's gcc?
<Amaranth> apple's gcc would require OS X or darwin
<Amaranth> seeing how this is a linux distro...
<cartman> :/
<cartman> Amaranth: I thought it just required a ppc cpu
<Amaranth> plus apple's gcc is a fork from sometime before 4 was released
<Kamion> I hadn't heard that Apple's gcc was all that excellent
<cartman> i.e ppc only optimizations in code
<cartman> Kamion: I heard it compiles better for ppc
<cartman> at least for C/asm
<Kamion> cartman: sounds like Apple-worshipping to me :)
<cartman> Kamion: might be yeah :)
<cartman> non-biased opinions on Apple producsts are hard to get
<aj> i hadn't heard anything about apple's gcc being notable either
<Amaranth> i heard it was the same as a pull from CVS on the day they forked plus Objective-C++ support
<Kamion> considering that Apple folks seem to be active on gcc lists I'd imagine most applicable stuff gets merged back; gcc is complex enough that people don't want to fork all that far
<jdub> apple's gcc is notable in that it's not remotely useful in this case :-)
<cartman> yup
<daniels> elmo: vim fixed
<doko> the ObjC++ bits are merged in HEAD now
<cartman> doko: for 4.1?
<Amaranth> that's where HEAD is going, yeah
* cartman checks gcc wiki
<elmo> there's a whole bunch of stuff in their branch, but it's almost all darwin specific, from what I've seen, they do try to merge the non-specific parts
<elmo> as kamion says, it makes their lifes easier
<Amaranth> yeah, but they're still using a pre-release compiler on a released OS
<elmo> Amaranth: meet doko, our gcc maintainer
<doko> who does use released compilers anyway? 
<daniels> Kamion: so, is it cool to punt xpdf?
<Amaranth> hehe
* Amaranth checks gcc -v
<elmo> xpdf's already scheduled for punting, FWIW, it just needs Approval
<Kamion> 2005-04-11 19:19:03 GMT Matt Zimmerman <matt.zimmerman@canonical.com>   patch-1
<Kamion>     Summary:
<Amaranth> wow 20050522 but still called prerelease
<Kamion>       Drop gnome-gv and xpdf in favour of evince
<Kamion> that isn't approval?
<elmo> Kamion: that works
<Amaranth> doko: is that a prerelease of 4.0.1?
<elmo> does evince handle pdf.gz yet?
<doko> Amaranth: its gcc-4_0-branch CVS
<daniels> elmo: did last I checked
<Amaranth> doko: is that a yes then? :)
<elmo> ok, it doesn't in hoary
<daniels> elmo: hrm, ignore me; it must be ggv that supports it
<Treenaks> has the right-click/open-terminal plugin for the new nautilus been packaged yet?
<jdub> elmo: Unhandled MIME type: 'application/x-gzip'
<elmo> jdub: teh suck
<elmo> esp. since most pdf's under /usr/share/doc are compressed by default
<jdub> elmo: fixable
<elmo> jdub: sure, I wasn't saying it was a blocker, just whining
<jdub> elmo: "weird debian use case" :-)
<Mithrandir> jdub: doit! :)
<elmo> jdub: s/debian/\&+ubuntu/ :p
<crimsun> pitti: for a few minutes, yep. What's up?
<elmo> Bug 11111 has been added to the database
<elmo> BIDDIBIDDIBIDDIBIDDIBIDDIBIDDI
<ogra> whoo
<pitti> crimsun: alsa-libs 1.0.9 enables dmix for the first soundcard by default, that's fine. However, it doesn't for all other cards, do you know this issue?
<pitti> whoo
<pitti> only 31 bugs so far? :-)
<daniels> elmo: dude, that's piddling compared to bug #666 on Malone
<daniels> elmo: (which was, of course, Malone crashing)
<crimsun> pitti: hmm, nope, but it's worth following up on mantis (https://bugtrack.alsa-project.org/alsa-bug/view_all_bug_page.php). This # is relevant: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1068
<pitti> crimsun: okay, will do
* pitti registers to the 23423th bug tracker
<lamont> seb128: cp: cannot stat `./debian/tmp/usr/share/control-center-2.0/icons': No such file or directory
<lamont> control-center_1:2.11.2-0ubuntu1
<jdub> `anthony: really there?
<daniels> pitti: if only there was some sort of bug tracker that brought a bunch of upstream bug trackers together so you could do all your bug work from one central place
<pitti> daniels: indeed, *that* would be cool
<pitti> too bad that nobody is working on such a thing... 
* Amaranth senses an inside joke
<pitti> Amaranth: ever heard "Malone"?
<daniels> Amaranth: https://launchpad.ubuntu.com/malone/
<Treenaks> The force is strong in this one
<jdub> Treenaks: *chuckle*
<Amaranth> oh, that thing
<Amaranth> you guys need web design help :D
<seb128> lamont: k, thanks
<hunger> daniels: The new xfonts-debs install fine for me now. thanks!
<daniels> no worries
<Lathiat> go the dell diagnostic partition updater
<Lathiat> it ran, chunked for a while, only to point out i didnt have a diagnostic partition (which I knew) but it ate the start of my hard drive anyway
<Treenaks> ouch
<Amaranth> MOM posts bugs in bugzilla?
<daniels> yes
<elmo> (Damn scott.  so many your mum jokes)
<Amaranth> pretty cool, but spooky
<daniels> and he didn't even do it right
<Amaranth> until it said it was the merge-o-matic i thought a real person filed the bugreport :)
<daniels> it should've been merge-uh-matic
<daniels> A#@$(*&@#$OIU$#@)(*
<Amaranth> american english vs australian english, round 1
<JaneW> Does Ubuntu come out in an enterprise/server version at all?
<Kamion> you think Scott speaks American English?
<Mithrandir> JaneW: no
<daniels> Amaranth: (er, mum was UK English long before it was Australian English)
<Amaranth> i know, but you're in AUS, right?
<Mithrandir> JaneW: there's just Ubuntu, no separate server version.
* Mithrandir is off for waffles.
<sladen> mmmm, waffles.
<jdub> JaneW: stick in the CD, boot with 'server' :-)
<Kamion> JaneW: we may certify a version for longer-term "enterprise" support at some point
<Kamion> but it'll be fundamentally the same thing
<daniels> Amaranth: correct
<sladen> 1.  Stick it in the CD drive.  2.  type 'enterprise'.   3.  Feel Good(tm)
<daniels> sladen: so, uhm, possibly a stupid question, but do you have anything new on usplash?
<sladen> daniels: nope.  I've been taking a narrowboat on the canal with a bunch of kids this weekend
<daniels> cool
<JaneW> thanks for the responses, I'll relay the message
<elmo> did we really add an 'enterprise' alias?
<elmo> and I still can't get over you guys not using 'phat base' for the new seed :(
<daniels> heh.  we're now up to 191075 lines of patches, of which 166684 are either removing files in other modules, or stolen from HEAD
<chmj> phat base ?
<Amaranth> daniels: you're patching 6.8.2? i thought the X stuff was from HEAD
<Kamion> elmo: no, we didn't
<daniels> Amaranth: all the new stuff is coming from HEAD; new tarballs are just too painful
<Amaranth> ah
<daniels> and we still have too many patches to be tracking a moving target like HEAD
<Amaranth> daniels: doing all of this will make things easier in the long run, right?
<dilinger> ew
<dilinger> Xu disabled hyperthreading in kernels by default, in a security fix?
<pitti> dilinger: yes
<elmo> dilinger: seems reasonable?
<pitti> dilinger: https://www.ubuntulinux.org/support/documentation/usn/usn-131-1
<Amaranth> hyperthreading is crack anyway
<Kamion> having read the paper, fixing HT sounds kind of non-trivial
<dilinger> Kamion: having read the paper, it didn't seem like the sort of thing the kernel should be attempting to fix.  then again, I haven't read the followup thread on lkml yet
<Kamion> uh ... the paper explicitly advised that kernels work around the issue until chip vendors sorted it out
<Kamion> since it's not like you can hot-upgrade your CPU
<Kamion> which didn't seem like an unreasonable position to take
<Kamion> I mean, the alternative is that everybody rewrite their crypto libraries to be entirely immune to timing attacks, which is no small endeavour and not always obviously correct anyway
<mjg59> Kamion: Currently, the only real way of working around it seems to be to disable hyperthreading
<Kamion> mjg59: exactly
<mjg59> Which is a kernel command-line argument
<mjg59> So disabling it by default seems excessive
<elmo> why?
<elmo> we don't default-to-off for other security patches?
<mjg59> Oh. Is "Disable by default" equivilent to "Provide new option to enable"?
<Amaranth> the people who know there is a kernel command line are the ones who would be thinking about reenabling it, not those disabling it for security reasons
<Kamion> mjg59: yes
<Amaranth> yeah, you can use ht=on to enable it
<elmo> You can manually
<elmo> enable HyperThreading again by passing the kernel parameter "ht=on" at
<Kamion> mjg59: well, it's now default ht=off and you can type ht=on
<elmo> boot. (CAN-2005-0109) 
<pitti> Kamion: it's not just timing attacks
<mjg59> Ah, yes
* mjg59 should read the advisory properly first
<pitti> Kamion: a process can watch another process while they are on the same CPU at the same time
<dilinger> i just don't like security updates that change behavior like that.  i guess if it's unavoidable..
<mjg59> dilinger: If the changed behaviour is documented, it's less of an issue
<elmo> I wish it had been ready before I ran round 30+ machines disabling HT in the BIOS :P
<mjg59> Especially if it's the only real solution...
<elmo> Kamion: why does man still look in /usr/local/man ?
<Kamion> elmo: why shouldn't it?
<elmo> wouldn't /usr/local/share/man make more sense?
<Kamion> it looks there too
<Kamion> /usr/local/man's there for legacy support
<elmo> shiri 14:51 ~ % manpath
<elmo> /usr/share/man:/usr/local/man:/usr/X11R6/man
<elmo> ?
<Kamion> oh, it's computing that from $PATH
<daniels> daniels@catsby:~% manpath
<daniels> /usr/local/man:/usr/local/share/man:/usr/share/man:/usr/X11R6/man:/usr/man
<Kamion> daniels: you've set that by hand, I think
<daniels> Kamion: not that I'm aware of
<Kamion> daniels: echo $MANPATH # ?
<Kamion> elmo: I think that's a bug - it doesn't seem to be handling multi-valued MANPATH_MAP entries
<daniels> er
<seb128> jdub: about your g-s-t mail, not sure if that's a good idea. We have turned some of the option because they break stuff like rcn.d entries
<daniels> Kamion: /usr/local/man is in MANDATORY_MANPATH, /usr/local/share/man isn't
<daniels> Kamion: it's blank, and not set in ~/.zshrc or anything
<Kamion> hah, that wouldn't help
<Kamion> /usr/local/share/man is kind of crack though
<jdub> seb128: can we have that package for the ones that aren't broken?
<Kamion> I mean, nobody has /usr/local/share/bin that I'm aware of
<seb128> jdub: is there any reason to not include these one with the default package?
<Kamion> the FHS just went share-happy
<seb128> jdub: we can ship all of them during the unstable time and decide of which ones to keep on the freeze?
<Treenaks> Kamion: Share and Enjoy!
<Kamion> elmo: ah. I bet /usr/local/share/man doesn't actually exist on your system
<Kamion> but it exists on daniels'
<Kamion> path directory /usr/local/bin is in the config file
<Kamion> adding /usr/local/man to manpath
<Kamion> manpath: warning: /usr/local/share/man: No such file or directory
<elmo> Kamion: ah, you're right, it doesn't
<elmo> should base-files and/or man-db create it if it doesn't?
<Kamion>   * Added /srv, /media and /usr/local/share/man (Closes: #230909).
<Kamion>   * Added /usr/local/man as a symlink to /usr/local/share/man,
<Kamion>     since FHS says both directories should be "synonymous".
<Kamion> (base-files 3.0.13)
<Kamion> it only does that on initial install though
<jdub> seb128: ok :)
<elmo> oh, right, and this is some use-to-be-debian ancientness
<Kamion> my general opinion is that /usr/local/share/man is an FHS mistake though; I'm not all that concerned about propagating it further than I have to
<`anthony> jdub: yes
<maswan> jdub, jbailey: maswan-ping?
<jdub> maswan: pong
<seb128> elmo: any way to get the gnome-control-center build-deps on concordia?
<jdub> `anthony: aha, give me a minute - going to be about?
<`anthony> yeah, for about another 1/2 hour
<`anthony> doing a bunch of shtoom/dbus hacking...
<elmo> seb128: done
<seb128> thanks
<`anthony> currently writing a new UI layer for shtoom - dbus. the phone itself has no UI at all, other applications can call it to do stuff and get signals back when stuff happens.
<jdub> elmo: planet update please :)
<jdub> `anthony: you're inhaling again.
<elmo> -       <style type="text/css" media="screen"> @import url(file:///home/jdub/src/planet/ubuntu/www/planet-ubuntu.css);</style>
<elmo> +       <style type="text/css" media="screen"> @import url(planet-ubuntu.css);</style>
<elmo> giggle
<elmo> done
<jdub> :-)
<daniels> jdub: WORSHIP DBUS
<pitti> daniels: DBUS SUCKS
<jdub> daniels: so i had this problem with garbage collection at my apartment. i solved it with D-BUS.
<pitti> daniels: I have tried for ages now to get a dialog into gnome-volume-manager, but dbus completely messes that up
<jdub> also, it helped me catch fish when i was stuck on a desert island
<daniels> jdub: word
<daniels> jdub: preach it!
<`anthony> I use it to club small defenseless animals to death.
<daniels> pitti: hm?
<`anthony> Although something like omniorb has a more satisfying weight for dealing with anything larger than a fox.
<KaiL_> hmm, the updated kernel in hoary breaks the restricted modules!
<KaiL_> fabbione: ping?
<daniels> KaiL_: er?  which updated kernel?  and how?
<KaiL_> the 2.6.10-34.1
<jdthood> In Canada we kill baby seals with hakapiks.
<`anthony> jdthood: good thing too, otherwise we'd be overrun with the little bastards. I mean, look at the squid. Fuckers are everywhere now.
<GheRivero> res people
<KaiL_> daniels: so linux-restrivted-modules-2.6.10 must be recompiled ASAP
<KaiL_> restricted...
<KaiL_> even better remove the new image from the update archives instandly
<daniels> KaiL_: why?  what's actually wrong?
<daniels> did it change the ABI, or what?
<KaiL_> yes
<daniels> did it bump all the numbers to -6, or?
<Kamion> 15:23 < KaiL_> even better remove the new image from the update archives instandly
<Kamion> eh?
<Kamion> security updates > restricted modules
<daniels> right
<daniels> and stuff never gets removed from archives
<daniels> KaiL_: can you describe *how* it breaks the ABI?  what fails to work?
<KaiL_> daniels: nvidia driver
<KaiL_> see #nvidia, jd101 there
<daniels> i'd rather not join yet another channel
<KaiL_> Kamion: there's nowhere an updated restricted modules?!
<`anthony> which reminds me - should I log bugs against the nv driver against ubuntu, or fd.o ?
<daniels> `anthony: fd.o, preferably
<daniels> saves me the effort :)
<Kamion> KaiL_: you're missing the point - security updates are more important than restricted modules, so "remove the new image" would be the wrong answer no matter what
<KaiL_> Kamion: oh, being unable to have an X-Server is unimportant?
<`anthony> daniels: righto
<Kamion> KaiL_: *less* important than a security update
<daniels> KaiL_: less important than not being rooted
<KaiL_> daniels: wrong. 
<daniels> fabbione: apparently -34.1 caused an ABI bump, please investigate
<KaiL_> you can't be rootet, if you have no working system any more :)
<daniels> KaiL_: dude, hate to break it to you, but security trumps everything.  doubly so in the kernel.
<`anthony> KaiL_: You can always use the nv driver until the nvidia driver is fixed.
<KaiL_> it's not for me
<`anthony> Plus, then you get stuff like sane ACPI
<daniels> alternately, if you don't care about the security holes in the kernel, just downgrade for the time being
<`anthony> KaiL_: Then suggest to whoever is having the problem that they switch to nv until the module is recompiled.
<KaiL_> you understand, that everybody, who updates his kernel this morning and has any of these modules running (very many will have nvidia, not that much less fglrx) will have a console after reboot, yes?
<daniels> not necessarily everybody
<daniels> given that the udpates are tested by people who verify if the ABI stays the same or not
<daniels> so obviously it only triggers in some cases
<`anthony> KaiL_: is it possible the people with the problem are running their own compiled version of nvidia drivers?
<KaiL_> let's hope, they are tested...
<KaiL_> `anthony: he didn't even know, how to install the driver from nvidia
<Kamion> KaiL_: we're not saying "it won't be fixed", we're saying "relax"
<daniels> KaiL_: of course they're tested
<`anthony> If it _is_ broken, I'd expect it'll get fixed pretty quickly
<KaiL_> which btw *should* not matter technically...
<`anthony> KaiL_: Er, except that the nvidia driver code is truly heinous. If someone's grabbed the latest and "greatest" version, who knows what evil crap is in the driver.
<KaiL_> `anthony: we still have the "latest and greatest version" :)
<`anthony> KaiL_: In any case, suggest for now he just edit /etc/X11/xorg.conf and replace 'nvidia' with 'nv'. 
<`anthony> You lose GLX, but *shrug* you get a working X
<KaiL_> `anthony: that's the easy one. Now for the WLAN please :)
<KaiL_> and the winmodems :)
<KaiL_> ...I don't know, what else breaks
<`anthony> KaiL_: then downgrade ;)
<Kamion> are there verified reports of those breaking?
<`anthony> and wait for the compiling machine that is fabbione to fix ;)
<KaiL_> Kamion: not yet, and I hope it's really only nvidia
<KaiL_> which is bad enough, but that people *should* at least know, how to fix it
<Kamion> KaiL_: then please stop "The Sky Is Falling!", thanks :-)
<KaiL_> Kamion: you remember the laugh about MS, as one of their patches broke LAN in some silly, uncommon situations?
<`anthony> Kamion: "The Sky Is No Longer Rendered In Beautiful 3D, But Hey, Night (Suspend) Works Now!"
<daniels> `anthony: haha
<Kamion> KaiL_: if true, it's not the first time a patch broke ABI by mistake, and it probably won't be the last. the sky is still not falling.
<Kamion> we've fixed these things pretty quickly in the past, when people aren't screaming at us. :)
<ogra> `anthony, lol
<zul> Kamion: fix it now fix it now....aiiiiieee
<KaiL_> Kamion: maybe the restricted modules should be bound to EXACTLY one linux-image
<Kamion> KaiL_: it's appropriate for them to depend on an ABI, the way they do now.
<seb128> daniels: any idea on http://people.ubuntu.com/~seb128/config.log ?
<mjg59> KaiL_: If the kernel has broken it, then the dmesg command will contain errors from the nvidia module
<seb128> daniels: that's gnome-control-center not beeing happy, seems to be due to the new xorg
<jdub> mdz: permission to add python-beautifulsoup to desktop seed?
<mjg59> KaiL_: If those errors can be put somewhere, we can check what's happened
<jdub> mdz: recommended by `anthony 
<seb128> daniels: search for Xrandr.h on the log
<seb128> daniels: and the packages for these headers are installed
<KaiL_> jd101: see what mjg59  is asking for.....
<jd101> KaiL_: I typed dmesg. big list. what exactly am I looking for in the list?
<daniels> gcc -o conftest -g -O2 -Wall  -Wl,-O1 -Wl,--as-needed conftest.c -lXrandr -lXrandr -lXrender  -lSM -lICE  -L/usr/X11R6/lib -lX11
<mjg59> jd101: If you could redirect that to a file and put it somewhere, that would be helpful
<daniels> seb128: ^^ needs -I/usr/X11R6/include
<seb128> daniels: that's new?
<daniels> seb128: newish, yes
<seb128> k, because that builds fine on my box
<seb128> but I've not upgraded to the broken xorg versions :)
<daniels> heh
<daniels> they're not broken
<daniels> just ... different
<seb128> daniels: the -I/usr/X11R6/include should not automagically come from the autotools or other pkg-config?
<seb128> daniels: keyboard is broken according to pitti, dholbach and bugzilla :)
<daniels> seb128: it should come from autotools, but doesn't because parts of it are in /usr/include/X11 and parts are in /usr/X11R6/include/X11
<jd101> I'll be back in a minute
<daniels> seb128: if you don't need the g-c-c upload within the next few days, you could just wait until it works again when I upload libx11 separately
<seb128> ok, thanks
<seb128> I'll do an ugly Makefile.in change for now so :p
<seb128> hum
<seb128> configure change rather
<daniels> or just build with CFLAGS="-I/usr/X11R6/include"
<daniels> or --with-x-includes=/usr/X11R6/include
<seb128> right
<seb128> thanks daniels :)
<daniels> np
<daniels> (and yeah, keyboard is broken, that one's a little harder to debug)
<mvo> AndyFitz: do you have some cool ideas about the tray icon for update-notifier? various people seem to be unhappy with the current one (e.g. #11080)
<dredg> is linux-image-2.6.10-5-k7 (todays) in hoary boned?
<daniels> dredg: in terms of linux-restricted-modules?
<dredg> daniels: in terms of when i install it i get:
<dredg> cpio: (0xffffe000): No such file or directory
<dredg> cpio:   /lib/ld-linux.so.2 (0xb7feb000): No such file or directory
<daniels> awesome
<dredg> a reboot deads it with a panic
<mjg59> That's, uh, special
<daniels> jbailey: mkinitrd stuffed? ^^
<mjg59> dredg: Your install is plain Hoary?
<AndyFitz> mvo,   its symbolically fine but the shape isnt unique enough for it as a tray icon.  
<dredg> mjg59: pretty much
<lamont> Kamion: how usable is the current breezy debootstrap?
<lamont> that is, is the package list current?
<mjg59> dredg: Nothing from Breezy?
<ogra> dredg, what does retty much mean ?
<ogra> pretty even
<AndyFitz> id like to work on it .  mvo,  whats the pixmaps directory ?
<fabbione> hey lamont
<lamont> morning fabbione 
<dredg> i tend to backport anything i want from breezy for this machine
<daniels> dredg: ok, the answer there is 'don't do that'
<daniels> jbailey: nevermind
<mjg59> dredg: Uhm. There's the possibility that something is broken on your system, then.
<mjg59> Nobody else has reported that failure yet...
<mvo> AndyFitz: that would rock (please also have a look at the bugnumber I send you, it raises a interessting point). the icon is at /usr/share/pixmaps/update-icon.png
<daniels> haha
<daniels> so, speaking of keyboard problems, this just landed in bugzilla:
<daniels> i have this kind of problem... in fact, my "shift" key doesn't seem to work
<daniels> (sorry, no uppercase in this post)
<AndyFitz> mvo,  can you give me a url pointing to the bug report instead of the number ? 
<AndyFitz> I havent used malone before
<AndyFitz> assuming thats where it is ?
<mjg59> daniels: How did they manage quotes?
<mvo> AndyFitz: sure, https://bugzilla.ubuntu.com/show_bug.cgi?id=11080 (I sometimes forget that not everyone has the bugzilla open all day :P)
<dredg> mjg59: yeah, i accept that possibility. *shrug*
<daniels> mjg59: who knows
<Kamion> lamont: I think it'll break due to aptitude vs. C++ at the moment
<lamont> Kamion: ok.  aptitude is currently dying because libsigc++-1.2 doesn't like g++4.0
<jd101> mjg59: I saved the contents of dmesg
<mvo> lamont: what apt is used for the build?
<mvo> (for the build of aptitude that is)
<lamont> apt is the one outside the chroot --> hoary
<mjg59> jd101: Is it possible for you to put them on a website somewhere?
<bob2> fabbione: buildd's are running!
<lamont> the aptitude build failure is strhash.h:31: error: an explicit specialization must be preceded by 'template <>'
<jd101> mjg59: http://rapidshare.de/files/1933868/aaaa.html
<lamont> and I take back what I said about libsigc++1.2
<fabbione> bob2: and??????
<mjg59> jd101: Ok, that looks absolutely fine
<lamont> fabbione: bob2 is clearly developing a case of turrets. :-)
<elmo> tourets too
* bob2 blames mjg59 
<jd101> mjg59: but that's after i changes "nvidia" to "nv" and restarted
<elmo> tourette too too
<mjg59> jd101: Did you remove the nvidia module from /etc/modules ?
* thom knocks some cannon ports into bob2
<fabbione> lamont: whatever.. people should stop smoking my crack!
<mvo> lamont: I have a patch for that, I can do a new upload. what apt do you build against? 0.6.35ubuntu2?
<mjg59> jd101: It looks like it never tries to load the nvidia module. That should have nothing to do with a kernel upgrade.
<bob2> cannons and port, two of my favourite things
<jd101> mjg59: I # it
<mjg59> jd101: Ah. Please run sudo modprobe nvidia and then put up the contents of dmesg
<lamont> Selecting previously deselected package libapt-pkg-dev.
<lamont> Unpacking libapt-pkg-dev (from .../libapt-pkg-dev_0.6.35ubuntu2_i386.deb) ...
<Kamion> daniels: so will imake start automatically installing files in /usr/bin/ soon?
<Kamion> W: groff: packages-installs-file-to-usr-x11r6 usr/X11R6/bin/gxditview
<lamont> elmo: speeling disease names never was my strong suit.
<mvo> lamont: thanks. I would like to upload a new version of apt, but I would like to wait for mdz on that. do you think we could wait with the building of aptitude/synaptic until then (I suppose he comes back today)?
<daniels> lamont: oh my god, hideous
<daniels> s/lamont/Kamion/
<daniels> Kamion: probably eventually, but not before the server gets modularised.  which might well be a while.
<daniels> Kamion: (i didn't attempt to timeline it, only 'some time before august')
<Kamion> I'm wondering whether I should bother moving it by hand
<Kamion> or whether there's a way to override ProjectRoot
<daniels> #undef ProjectRoot
<daniels> #define ProjectRoot /usr
<daniels> honestly can't speak as to whether this will break shit badly, though
<Kamion> maybe I'll just mv stuff in debian/rules
<daniels> easiest that way, yeah
<bod> elmo: did you get a chance to see how dak copes with W&P format source archives?
<elmo> bod: no, not yet.  gar should have done it on the weekend
<mdke> mako, ping
<bod> elmo: no great hurry, just following up
<mako> mdke: hey dude
<mdke> ooh awesome
<mdke> hi mako
<Simira> morning!
<mdke> mako, just sent you my second attempt at a signed CC
<Simira> mako: are you updating the CC-agenda for tomorrows meeting?
<mdz> mvo: new version of apt?
<fabbione> hey mdz
<mdz> morning
<mvo> mdz: hey mdz. welcome back :) I send you a mail about the new apt
<\sh> python-apt?
<mako> Simira: yeah.. gonna work on that in the next couple hours
<mdz> mvo: mail...:-o
<mvo> mdz: how many do you have ;) ?
<mvo> mdz: just filter for my name :P
<pitti> Hey mdz! Welcome back
<seb128> hi mdz
<pitti> argh
<pitti> $ sudo cfdisk /dev/sda
<pitti> Segmentation fault
<pitti> this shouldn't happen...
<seb128> pitti: utch
<Lathiat> pitti: owwww
<fabbione> yeah i have seen it a couple of days back
<fabbione> forgot to check why
<fabbione> pitti: fdisk works
<pitti> ... and I just formatted the stick
<pitti> fabbione: yeah, I used fdisk
<seb128> mvo, pitti: you may want to subscribe to http://lists.ubuntu.com/mailman/listinfo/desktop-bugs :)
<seb128> (probably some other too)
<pitti> not more mails... *whine*
<seb128> pitti: better than ubuntu-bugs :p
<pitti> yeah, right
<fabbione> or gtk-bugs
* pitti has to reboot, brb
<eruin> anyone tested today's install-cd already?
<pitti> mvo: I know the difference between my usb stick and my camera (wrt. g-v-m dialog/dbus wreckage)
<mvo> pitti: tell me!
<pitti> mvo: the camera is just one device, but my usb stick has two partitions
<pitti> mvo: I reformatted my stick to have just one (encrypted) partition, and now it works
<pitti> mvo: so after the partition is detected, there simply are no further dbus messages
<pitti> mvo: however, that explains why it works with the camera, but doesn't solve the dbus bug, of course
<Lathiat> yeh i noticed with g-v-m
<Lathiat> i have a usb stick which has an emulated floppy
<Lathiat> and then the usb stick part
<Lathiat> and only the floppy bit ever mounts
<pitti> Lathiat: no, that should work (it does for me at least)
<Lathiat> i'll try again
<Lathiat> might have been fixed
<pitti> Lathiat: I currently try to introduce a dialog which asks for an encryption passphrase
<Lathiat> pitti: ah, thatd be sweet
<pitti> Lathiat: but while the dialog runs, gtk_main_loop() is called, which triggers dbus functions, which never return and use up 100% CPU
<`anthony> pitti: You should use the twisted dbus bindings, then you don't have to worry about this crap ;)
<pitti> `anthony: ENOPYTHON
<`anthony> pitti: *grin*
<ogra> pitti, get more CPUs then 2 CPUs = 50% 4 CPUs = 25% ;)
<pitti> ogra: 50% of what?
<Lathiat> ogra: haha
<pitti> ah, I see, sorry
<ogra> *g*
<pitti> I think I rather get 4 daniels to fix dbus
<ogra> poor pitty, everyone is fooling him today :)
* ogra comorts pitti
<ogra> comforts even
<pitti> *sniff* thanks ogra, I love you too
<ogra> :)
<mdz> where did helvetica go while I was away: -adobe-helvetica-medium-o-normal--*-120-*-*-*-*-*-*
<daniels> mdz: *cough*
<ogra> mdz, new paths ;)
<ogra> mdz, hi btw :)
* pitti points at daniels breaking everything recently
<daniels> mdz: sed -i /etc/X11/xorg -e s#/usr/lib/X11#/usr/share/X11#;
<daniels> pitti: not my fault!
<daniels> mdz: need to fix a couple of other packages before I can add a symlink
<Lathiat> daniels: http://bur.st/~lathiat/ubuntu-dbus-doc-suggests.patch
<mdz> daniels: thanks
<mdz> er
<mdz> mizar:[/etc/X11]  grep lib/X11 xorg.conf
<mdz> zsh: exit 1     grep lib/X11 xorg.conf
<mdz> all my FontPaths say /usr/share/X11
<mdz> but I don't have a /usr/share/X11
<mdz> should I do the reverse instead?
<daniels> mdz: upgrade xfonts-* to 6.8.2-12
<daniels> Lathiat: yeah, I saw that, dbus is sort of on the backburner at the moment
<Lathiat> daniels: ok
<daniels> mdz: (out of curiousity, what app do you have that still uses core fonts?)
<mdz> daniels: gnucash (universe)
<daniels> ah
<ogra> hmm, gtk1
<mdz> daniels: you know that x-window-system-core is currently uninstallable, right?
<Lathiat> and xbase-clients
<daniels> mdz: yes, that's why I'm still awake
<Lathiat> heh
<mdz> daniels: gotcha, thanks for the quick fix
<daniels> mdz: no worries
<fabbione> mdz: did you have nice holidays?
<doko> Keybuk, could we revert the change to *_GNU_TYPE and *_GNU_OS until Debian introduces dpkg-1.3?
<Keybuk> if you're going to do that, you may as well just use 1.10
<Kamion> meh, let's not flip-flop please
<mdz> fabbione: yes, excellent
<fabbione> mdz: nice :)
<mdz> daniels: btw, it's perfectly ok to leave that broken in the name of sleep; these are early days and breakage is a given
<Kamion> doko: we're going to have to deal with it eventually anyway, and we're almost certainly going to have to deal with it faster than some Debian maintainers do
<daniels> mdz: in dh_shlibdeps now, so I'll see if these don't work and go fro mthere
<doko> Kamion: I don't care about the packages that fail to build, but the ones that wrongly build
<elmo> doko: I still don't see why we can't grep for DEB_* ?
<elmo> hum, I wish zsh had timestamped history
<Kamion> doko: yes, and my point stands I think
<doko> elmo: we can, please do ;-)
<ogra_d> elmo, patches welcome :-P
<elmo> doko: dude, I'm not the one whining about breakage
<`anthony> elmo: fc -dl
<elmo> and I'll do your grepping, just as soon as you help deal with some of my sysadmin stuff
<doko> give me 5 minutes, finishing C++ first
<elmo> `anthony: dude.
<`anthony> elmo: zsh has _everything_. You just gotta find the right magic option.
<Kamion> argh. hello, Colin, average of X and Y is (X+Y)/2, not (Y-X)/2
<daniels> Kamion: interesting maths
<Kamion> er, I should say "mean", too
<Kamion> but now I have an option "Resize SCSI1 (0,0,0), partition #1 (sda1) and use freed space"
<elmo> kick ass
<daniels> nice
<Kamion> and I really wish I got a useful progress bar while resizing ext3
<lamont> doko/seb128: dasher needs xorg love
<trulux> pitti: heya
<pitti> Hi trulux 
<lamont> seb128: gksu looks like it needs some s/linux/linux-gnu/ love?
<trulux> pitti: hey, yesterday I was talking to ajmitch and organizing some stuff. how's krsec working? 
<pitti> trulux: your patch works
<pitti> trulux: however, fabbione had some reservations with applying it since it is very intrusive
<pitti> trulux: did you submit this upstream?
<thom> mdz: having hardware issues, or is this a long term annoyance (verbose hotplug in recovery mode)
<pitti> trulux: I think for upstream inclusion the patch is fine
<pitti> trulux: but it isn't that nice to introduce distro-specific sysctls, I was told
<mdz> thom: we regularly see this type of report from users, and it's tricky to debug because we can't tell which module is being loaded
<trulux> pitti: I hadn't, though I had some feedback with akpm but not related to the patch itself
<mdz> thom: I was reminded to file the bug due to dealing personally with a user experiencing such a problem
<thom> mdz: nod. ah, right
<trulux> pitti: that's because I pointed at vsecurity
<trulux> pitti: you just choose the hard way ;)
<pitti> trulux: I showed the patch to fabbione, he has to think about it
<trulux> pitti: vsec? it's not patch, we can maintain separate deb packages for the module, really
<pitti> trulux: it *might* be necessary to prepare another (lighter) patch without the sysctls, but otherwise it is fine
<trulux> pitti: and most important...
<trulux> pitti: I'm porting cap_over to it, so, we won't need suid binaries anymore
<trulux> pitti: a very basic binary-policy-based access control with capabilities
<trulux> pitti: well, using sysfs is a solution, but really, having vsec makes the effort no worth
<pitti> trulux: no, not sysfs
<trulux> pitti: vsec uses sysfs for a few things, though it also uses an internal sysctl for the policy stuff (cap_over)
<trulux> pitti: sysctl is going to be deprecated
<trulux> pitti: there are better interfaces
<pitti> trulux: what about dropping the sysctls for now?
<pitti> trulux: you can still enable/disable the stuff at boottime, but the patch would get lighter
<pitti> trulux: (sorry for the mess)
<trulux> pitti: I'll prepare a separate patch for that
<trulux> pitti: no worries
<trulux> pitti: I just try to get you all thinking in the right way, and that way means modularizing our stuff
<trulux> we are not upstream, so, modularizing makes work easier, faster...
<pitti> yeah, indeed
* mvo is off to play hockey. bb in ~2h
<trulux> pitti: I'm working now on finsihing the next 0.3 release, with the guy that managed the OpenPaX project
<Kamion> daniels: xorg.dsc still seems to mention libxau* and libxdmcp*
<daniels> WQ#@$OIJ@#$@#$
<Kamion> I guess they're still in debian/control?
<daniels> good catch, thanks
<fabbione> daniels: stop playing with X and give us back the monolitich tree :P
<daniels> i just uploaded the monolithic tree twice in like five minutes
<daniels> based on that, it's getting mroe attention than anything else ever :P
<fabbione> i can see that :)
<fabbione> daniels: but it's not an issue.. X is ccached.. it takes only around 2 hours to build :)
<Amaranth> seb128: ping?
<trulux> pitti: finished
<trulux> pitti: it's pretty small patch now
<seb128> Amaranth: ?
<seb128> why people don't say why they ping?
<Amaranth> seb128: was wondering if you could look into packaging pyxdg 0.11
<Amaranth> seb128: sorry, will next time
<seb128> I'll after dinner
<Amaranth> no rush
<seb128> was just going right now
<Amaranth> thanks
<seb128> np
<thesaltydog> I have a question concerning runlevels and sysv
<thesaltydog> I need to discuss runlevel and sysv policy in ubuntu
<thesaltydog> I need to discuss runlevel and sysv policy in ubuntu, to tune my application.
<trukulo> thesaltydog: what's your application?
<thesaltydog> trukulo, Ubuntu Bootup Manager
<trukulo> thesaltydog: similar to initng?
<trukulo> or grub?
<thesaltydog> no, it is a graphic tool to manage runlevels/priorities/etc... http://www.marzocca.net/linux/ubm.html
<trukulo> thesaltydog: same as rcconf?
<trukulo> well, similar, not same
<thesaltydog> rcconf has been the first step for the development.
<trukulo> umm, not very intuitive
<thesaltydog> sorry?
<trukulo> it seems not very intuitive to users, very cryptic (for novices)
<trukulo> just my opinion
<Lathiat> I think the idea is great but the interface could be much simpler
<thesaltydog> maybe. But novices has also to learn. Anyway, my question is just in this direction..
<thesaltydog> Is it stated somewhere that ubuntu's Runlevel 3-4-5 are the same as RL2??
<trulux> pitti: there?
<Amaranth> seb128: hold off on packaging that for the moment, i just found a nasty bug i'm talking to the upstream dev abou
<pitti> trulux: yes
<Kamion> thesaltydog: it's in Debian documentation, yes
<luis_> hrm, anyone here familiar with the liveCD bits? what fs type is / (and as a result /home/ubuntu/) exactly?
<luis_> mount reports it as... something very strange
<luis_> '/dev/mapper/casper-snapshot on / type auto (rw,noatime)'
<luis_> (I had expected tmpfs)
<Lathiat> isnt it cloop ?
<jdub> yes, it's a dm layer
<thesaltydog> Not true. Debian can diversify runlevels.. One user asked me to provide divesification from RL 3 and the others..
<surak> what is dm?
<jdub> device mapper
<Kamion> thesaltydog: Debian's default is identical to Ubuntu's.
<jdub> luis_: it's a dm overlay on top of cloop
<surak> jdub: Could you talk a little bit more about this?
<Kamion> thesaltydog: so I'd like to know exactly what you're disagreeing with when you say "not true"
<thesaltydog> Kamion, with debian I was used to have runlevel 4 as a non-graphic server configuration..
<Kamion> thesaltydog: that's not the default. You could do the same with Ubuntu if you like.
<thesaltydog> Kamion, no. Because then when you apdate a package, the postint script will run again update-rc.d and put all the RLs the same..
* luis_ is with surak
* luis_ has no idea WTF that is :)
<luis_> though I am googling furiously ;)
<Kamion> thesaltydog: which is *exactly the same* on Debian.
<Kamion> 17:49 < ewx> Pinkbeast: Fnqyl abg.
<Kamion> err
<Kamion> http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit
<thesaltydog> Kamion, I have read the debian-policy and they say that you can have different behaviours on runlevels.. 
<Lathiat> luis_: aiui, theres probably more to the story, its a layer for consistent naming of devices, notably used with things like lvm/raid but other stuff too 
<jdub> luis_: dm is just the kernel foo that lets us provide a writeable overlay on top of the cloop filesystem; it's also used for evms, lvm, etc.
<luis_> ah
<Kamion> thesaltydog: it's highly unconventional and I can't think of any Debian packages that do it by default. I also think it's unwise. Leave it to the sysadmin.
<thesaltydog> Kamion, anyway, my question is just simple: should I remove RL3-4-5 from the GUI of ubm?
<Kamion> thesaltydog: Please don't.
<thesaltydog> Kamion, but trulux was saying that the GUI is not simple. He asked to simplify..
<kiko-fud> surak, we use dm to implement a sort of COW on top of cloop.
<Lathiat> thesaltydog: thats not a simplification
<Lathiat> thesaltydog: thats just obfuscation
<trukulo> thesaltydog: one interesting thing, for usability, is to show what the default RL is
<Lathiat> thesaltydog: i would envisage the entire design to be different
<doko> elmo: do some of xorg's, libxau's build deps need NEW love?
<trukulo> thesaltydog: i'm not a developer, and this is just my opinion
<thesaltydog> Lathiat, I agree..
<elmo> nah, they need universe -> main love; I'm on it
<thesaltydog> Lathiat, I don't like to obfuscate, that's why I have added also rcS.d
<Lathiat> thesaltydog: so far example (this is just an example), you may say list all services, then you open that service and it lists what runlevels it starts and shuts down at, and to change it, etc
<surak> Kamion: still having trouble with inirtrd.
<thesaltydog> Lathiat, but in the way you don't have a first global impression of what your system is...
<Lathiat> thesaltydog: I dont see what you mean
<Lathiat> thesaltydog: its also possible to have multiple views
<trukulo> thesaltydog: i think about simplified conf, and advanced conf
<Lathiat> Service View
<Kamion> surak: ?
<Lathiat> Runlevel view
<Lathiat> etc etc
<surak> 1 min
<Lathiat> because sometimes you want to see different lists of tings
<surak> phone
<thesaltydog> Lathiat, multiple view means "<confusion>". My opinion..
<trukulo> thesaltydog: in simplified, just use default level, and enable- disable service
<trukulo> as rcconf
<thesaltydog> trukulo, so you mean to remove RL 3-4-5 information?
<trukulo> thesaltydog: no, i mean put it on tab advanced i.e.
<trukulo> use two tabs, simple and advanced
<thesaltydog> trukulo, a sort of "expert" mode?
<trukulo> advanced as you have
<trukulo> thesaltydog: yes
<trukulo> but very visible
<thesaltydog> trukulo, you see, I have also rcS.d
<trukulo> tabs are perfect for this
<thesaltydog> trukulo, and I already havce tabs
<trukulo> i see, just add another one, simple configuration
<trukulo> and make it default, for novices
<thesaltydog> trukulo, mmh. Nice. It could be..
<trukulo> thesaltydog: and with description of service
<trukulo> instead of RL
<trukulo> that would be very interesting for novices, as they would know what a service does
<thesaltydog> trukulo, description of service is always visible in the lower pane, as synaptic.
<thesaltydog> trukulo, the full description
<trukulo> umm, you're right
<trukulo> perhaps one line desc only
<trukulo> just for fast visual understanding
<thesaltydog> trukulo, no, it will double the info... Of course in novice mode that should not change start/stop priority??
<thesaltydog> trukulo, that==they
<trukulo> thesaltydog: just my opinion, if you want descriptions, you have to select services one by one
<trukulo> this way you can view it faster
<thesaltydog> trukulo, it is now this way. Have you tried moving in list with cursors..?
<trukulo> i know cursors do it, but that's not my point
<trukulo> i want to see entire list easy
<trukulo> imagine i'm a novice, and i want to stop printer service
<trukulo> do i have to select and read all descs for services? that's slow
<trukulo> it's just a commodity
<trukulo> and only in simple view
<thesaltydog> trukulo, no, you run the program, right-click con cupsys, and deactivate now. That's all..
<trukulo> boot/service name/description
<trukulo> novice don't know cupsys are for printers
<trukulo> they have to look for it
<mdke> trukulo, that will help them find out
<trukulo> mdke: that's the point
<thesaltydog> trukulo, mmh. Neither UBM knows...
<mdke> trukulo, imo there is nothing wrong with getting users to read a full description, it is good education
<trukulo> mdke: that's true, but you may help finding things
<thesaltydog> mdke, like synaptic does..
<trukulo> i can see cupsys is for printers, and then i select and read full desc
<mdke> trukulo, i think the interface makes the full description fairly easy to find
<thesaltydog> trukulo, between us. I don't want to make a Gates-like application for dummies.
<mdke> trukulo, if you see that, i feel that you won't read the description ;)
<mdke> thesaltydog, +
<trukulo> that's just my opinion, of course you can disagree
<thesaltydog> trukulo, hey, we are not arguing here, just brainstorming
<mdke> yeah
<mdke> iirc the old gnome-s-t service manager didn't have short descriptions
<mdke> actually i'll have a look
<trukulo> but easier, doesn't means "for stupids only" :)
<trulux> pitti: http://pearls.tuxedo-es.org/patches/security/kern-security-2.patch
<thesaltydog> trukulo, one last question.
<trukulo> thesaltydog: i'm just a sysadmin, not a ubuntu developer, eh?
<trukulo> so take mi opinions just as that, a sysadmin opinion
<thesaltydog> trukulo, is there a "standard & unique" way to detect if a script in init.d has a daemon running, currently?
<trukulo> thesaltydog: as i know, not in debian, if you find one tell me, as yast4debian has problems with the same thing
<thesaltydog> trukulo, i.e.: I see that a script is named cupsys, but his daemon's name is cupsd..
<mdke> the old gnome system tools one is here: http://mdke.mine.nu/images/g-s-t.png, it has some brief explanations
<trukulo> in other distros, it's with /etc/init.d/service status
<thesaltydog> trukulo, I can parse the init.d script file, but they are not the same, not standard
<trukulo> thesaltydog: you can take a look at yast4debian, they had the same problem
<trukulo> http://yast4debian.alioth.debian.org/
<thesaltydog> trukulo, ok. I will look. It could be nice coloring green running services and red stopped ones..
<mdke> sorry, dud link, http://mdke.mine.nu/images/g-s-t.png
<trukulo> thesaltydog: sure
<mdke> thesaltydog, good idea
<thesaltydog> mdke, but there is no way to get them..
<trukulo> thesaltydog: but , again, i want to return to my point of fast descs :)
<mdke> thesaltydog, :/
<trukulo> thesaltydog: there's a way, very strange, but there is
<trukulo> as yast4debian does this
<thesaltydog> trukulo, you need to parse the files, but the syntax is not standard. Someone use NAME=daemon, other use DAEMON=daemon
<thesaltydog> and other, like apache, use completely different syntax
<trukulo> let me see
<trukulo> thesaltydog: there was another way
<trukulo> let me look for it
<surak> Kamion: are u there?
<Kamion> surak: yes, for about 15 more minutes
<surak> Think I'll start working earlier, so I can cope with european time :-)
<surak> My problems with ubuntuexpress are:
<surak> 1) as you already know, the cd's initrd won't work.
<surak> 2) I must be doing something really wrong with mkinitrd.
<Kamion> 1) is a feature, not a problem. :-)
<thesaltydog> trukulo, ?
<Kamion> the initrd on the CDs is an integral part of the installer
<Kamion> 2) can you elaborate?
<Kamion> surak: mdz's back now, and he might be on more compatible times to you
<surak> 3) the /dev is not ok. For instance, live has a /dev/shm/network - running udevstart won't create it (so no apt-get)
<trukulo> thesaltydog: still looking for
<surak> hum. it worked now ( 3 )
<thesaltydog> trukulo, ah, okay. I wait..
<doko> mdz: please could you review mvo's changes to apt? it's the last library in main with the old C++ ABI
<Kamion> surak: you need to mount /dev/shm; there's an init script for it. Rebooting into the new system should be enough
<trukulo> thesaltydog: http://www.shallowsky.com/software/scripts/lsconfig
<trukulo> there you have
<mdz> doko: I already did
<thesaltydog> trukulo, wait.. I'll have a look
<mdz> doko: he emailed me yesterday
<Kamion> surak: 'mount -t tmpfs shmfs /dev/shm' ought to do it
<surak> kamion: ok
<mdz> doko: I responded to him today
<thesaltydog> trukulo, this is what ubm does to list the init scripts...
<thesaltydog> trukulo, but ubm does it better
<trukulo> thesaltydog: but there was another program
<thesaltydog> trukulo, maybe I have wrongly posed my question.
<trukulo> and look at this
<trukulo> http://lists.debian.org/debian-devel/2001/12/msg00737.html
<trukulo> there's no /etc/init.d/service status in debian
<trukulo> and nothing similar, as i know
<thesaltydog> trukulo, I know. Someone tried to make it standard, but it couldn't..
<thesaltydog> trukulo, ok. I will take care of it.
<doko> mdz: thanks
<thesaltydog> trukulo, you have been very kind
<trukulo> thesaltydog: i just try to help you :) you are helping us with your program more than i
<thesaltydog> trukulo, so your suggestion is: 3 tabs: 1. Short view 2-Standard Runlevels 3_System runlevel
<surak> Kamion: i need to do initrd in a chroot device, am I correct? Inside the mounted target. 
<trukulo> yes, and short descs in the list, and extended down, as know
<thesaltydog> trukulo,  don't know about this latter..
<trukulo> it's easier for finding services
<ogra> thesaltydog, you should work with the MOTU to get it included in universe
<thesaltydog> trukulo, but I should build a completely new cache for descriptions! Now I am taking those from the apt cache on the user's disk..
<ogra> thesaltydog, i already told that to abelli
<trukulo> thesaltydog: you just can use a crippled desc, from full
<thesaltydog> ogra, what do you mean by "work" with motu??
<thesaltydog> trukulo, look at the titles. They are not enough for a sjort description.
<ogra> thesaltydog, only MOTUs have upload rights to universe
<trukulo> cupsys ? doesn't seem printing service :)
<trukulo> for you and me, of course it is
<trukulo> but for new people... it isn't
<thesaltydog> trukulo, to make cupsys=printing services I have to write down (word by word) a dictionary
<trukulo> or just take first 80 characters of description you are using now
<thesaltydog> trukulo, aks to ubuntu mainteiners to change the descriptions
<trukulo> at least, it's useful information
<thesaltydog> trukulo, that could be
<trukulo> and people can continue reading full desc when select it
<thesaltydog> ogra, abelli already asked them. What should I do more?
<Kamion> surak: yes; you should also look at what base-installer does with mkinitrd.conf
<ogra> thesaltydog, yes, he asked me
<thesaltydog> trukulo, but I like to have full descr in the lower pane... please..
<ogra> thesaltydog, you probably should join #ubuntu-motu for a start ;
<Kamion> because you'll need to imitate it, or (possibly better) refactor base-installer's code so that you can use it directly
<ogra> ;)
<thesaltydog> ogra, I will try if I can
<thesaltydog> ogra, but I prefer to use my time for developing, than for making "public-relations"
<trukulo> thesaltydog: of course, full desc is a MUST-HAVE
<ogra> thesaltydog, if you want to see your app in ubuntu thats the way yu have to take
<Kamion> oh, also, it might be worth thinking of a name other than "Ubuntu Bootup Manager"
<Kamion> because we're trying to support derivatives and thus generally trying to move towards not stamping our name all over everything, except in clearly defined areas
<trukulo> Service Boot Manager
<thesaltydog> whay?
<thesaltydog> why?
<thesaltydog> trukulo, have you any babies in your family? Did someone ever asked you to change his/her name?
<trukulo> because imagine that Guadalinex use this, they can't have a program named Ubuntu blah
<trukulo> the only thing kamion says, is that is bad call a program ubuntu-blah
<trukulo> as ubuntu can be used to make derivatives distributions, as guadalinex
<Kamion> geez, don't equate programs with babies. :-)
<thesaltydog> ubuntu update manager could be used in debian..
<Kamion> thesaltydog: yes, and there's a bug open about its name ... it was written before we really started thinking about these issues
<Kamion> or its .desktop file, at least
<trukulo> can he call it UBM and change .desktop to say Service Boot Manager ?
<thesaltydog> Someone has opened a thread for me in ubuntuforums with that name U..B..M..
<TSWoodV> No one seems to care that "yum" is "Yellowdog Update Manager", from the eponymous PowerPC/Mac-oriented distro.
<surak> I thought it was yellowdog updater modified
* lamont finally lunches.  back in about 30
<Kamion> TSWoodV: abbreviations are fine, but we'd prefer to have some other user-visible name for the .desktop file so that it isn't a branding headache
<spotter> where did startx go in breezy?
<Kamion> we're in the middle of a large X shakeup
<spotter> any easy way to get my old X back :)
<Kamion> don't use breezy? :)
<spotter> what fun would that be?
<spotter> :)
<Kamion> at least not while it's in the middle of a fairly well-advertised transition
<spotter> I was in japan
<Kamion> upgrading may help, though, there've been fixes today
<spotter> wasnt really paying attention
<Kamion> breezy will settle down in time, but this is the "early breakage" period
<spotter> yes, and thats why its fun
<spotter> have a lot of packages on hold because of c++ issues
<spotter> what was the last version of X before the breakage?
<spotter> or shakeup that is
<spotter> hmm, I can probably get X working for me for now via xvncserver and the svga client. hmm
<surak> odd: hoary does not detect a second cd reader when running from live.
<thesaltydog> Kamion, were you serious about changing ubm name??
* Kamion -> karate
<Kamion> thesaltydog: http://udu.wiki.ubuntu.com/BrandingForDerivatives; read and ponder
<Kamion> "ubm" is fine on its own, IMHO ...
<thesaltydog> Kamion, so, change the name...change the gui... I did it for my enjoying and for the people, not for work!
<trukulo> thesaltydog: it was me who say to change the gui :)
<trukulo> thesaltydog: next tme, don't ask ;)
<thesaltydog> trukulo, right :-)
<spotter> argh, xbase-clients has xauth.1.gz but not the binary
<spotter> there goes vnc idea
<spotter> oh well, back to 1994 and no X for me
<spotter> 94 was a better time anyways
<eruin> muhaha. I like the daily X breakage :)
* lamont defers lunch
<spotter> btw
<spotter> anyone know how one switches channels in bitchx?
<spotter> :)
<eruin> alt+1 Id guess
<spotter> my bitchx skills are rusty
<trukulo> spotter: alt+number
<spotter> and if you have more than 10?
<spotter> :)
<ogra> spotter, did you use highly breaking development branches of software in 1994 for your regular work ?
<spotter> ogra: yes :)
<spotter> otherwise known as slackware
<ogra> heh
<surak> it hasn't changed a lot since that :-)
<surak> since then, sorry
<spotter> about the only thing it could ompile sucsefully was the kernel
<ogra> spotter, so then you are used to it, why do you complain ;)
<spotter> dosemu seemed to cause make to go into an infinite loop on it
<spotter> not complaining
<spotter> asking if possible anything I can do to fix it
<surak> Breezy live also does not seems to recognize a second cd drive...
<ogra> spotter, either sending nice cool patches to daniels... or just wait is what you can do...
<spotter> ok. I have the patience of a buddhist monk
<spotter> ah, I see how this window stuff works
<mdz> jbailey: I keep ending up with duplicate entries in /etc/locale.gen
<mdz> jbailey: is that a langpack issue or a locales issue?
<eruin> today's breezy i386 cd didn't seem to know how to install itself :-)
<dilinger> infinity: ping
<doko> thom: please could you have a look at the mozilla build failuere on ia64?
<pitti_> ogra: yay http://hwdb.ubuntu.com/buildlogs/
<doko> elmo: please could you install mozilla build-deps on halley?
<ogra> pitti_, could be faster, but well :)
<doko> ogra: fix more failures, a shorter list is faster to load ;-P
<ogra> doko, i'm working on it... 
<trulux> pitti_: going to sync the packages from ajmitch to pearls, will take a while
<trulux> pitti_: ;) (today's good day for us!)
<ogra> doko, not everybody is born to mass-upload ;-P
<ogra> doko, and i dont have the hardware (yet) to run 50 builds in parallel
<mvo> back from hockey
<jbailey> mdz: I don't see that on my boxes here.  My guess is probably langpack issue - locales shouldn't touch the /etc/locale.gen except if you do a dpkg-reconfigure.  I say that completely without proof, though.
<mvo> mdz: thanks for looking over the apt changes :)
<kiko> mvo, how did they look?
<elmo> doko: done
<doko> elmo: thanks. I did upload fixed libxau and libxdmcp packages, please could you process them from NEW?
<doko> elmo: do you see anywhere a x11proto-gl-dev (virtual) package?
<elmo> doko: they're not in new
<doko> ahh, ok, maybe the binaries will arrive there
<elmo> x11proto-gl-dev |      1.4-1 |        breezy | all
<doko> ok, then xorg should build at the next run
<lamont> daniels: a new xfonts-core?  sigh
* lamont reads -changes
<spotter> yay, X works again
<mvo> kiko: so far we merged some gcc-4.0 warnings and the cache-control patch
<kiko> mvo, you da man
<mvo> kiko: thanks man, but that's too much praise, really
<surak> :-)
<doko> smurfix: ping
<smurfix> doko: 
<Mithrandir> is that a pong character?
<smurfix> sure
<Mithrandir> which font do I need to see it?
<smurfix> good question. One moment
<spotter> where doe one get the nautilis-open-terminal extension?
<smurfix> Mithrandir: gucharmap finds "AR PL KaitiM GB", which probably is in whichever Chinese font I managed to install last time
<kiko> mvo, I think that including the full path is the correct approach to the path truncation issue, for the record.
<mvo> kiko: for error messages? or for all output?
<doko> smurfix: festival doesn't build using 3.4 or 4.0 ...
<smurfix> doko: That shouldn't happen. URL of the build log?
<kiko> mvo, for all output. otherwise it's just confusing. and the case where the strings get too long (>72chars) is pretty rare, isn't it?
<spotter> seb: you here?
<spotter> guess not. hmm
<smurfix> doko: did speech-tools build?
<doko> http://people.ubuntu.com/~lamont/buildLogs/f/festival/1.4.3-16build1/festival_1.4.3-16build1_20050523-1814-i386-failed.gz
<doko> didn't try, because we have build-deps on festival-dev
<mvo> kiko: for ubuntu it's very rare, but it's common for debian mirrors it seems
<lamont> xorg ftbfs: x include file errors.  /me giggles
<smurfix> doko: festival depends on libestools1.2-dev, built by speech-tools, and which presumably needs a c++ ABI transition ..?
<kiko> mvo, how common? hummm.
<mvo> kiko: it's easy for tools like synaptic that have scrollbars :P
<smurfix> doko: anyway, the (first) errors occur in a speech-tools include file
<doko> smurfix: ok, I have a look
<smurfix> doko: Upstream is busy completing their transition to Festival 2.0 which includes an updated speechtools which allegedly works with gcc 4.0
<smurfix> doko: ... which I obviously need to debian/ubuntu-ize as soon as I have a couple of spare hours :-/
<smurfix> doko: Looking at these errors, it seems that gcc has again become annoyingly more standards-conformant, otherwise known as "anal".
<surak> Kiko, are u there?
<surak> or Kamion?
<kiko> I am!
<surak> My trouble was that I was not able to create a initrd.
<surak> because of this: http://ubuntuforums.org/archive/index.php/t-20925.html
<jbailey> surak: Best bet there is to run "sh -x mkinitrd ...." and see why it's not calling the mkcramfs bit then.
<surak> doing it
<elmo> Kamion: around?
<elmo> GAR
<surak> jbailey: seems I've found it.
<surak> what happen is that if you don't type the full path, it will leave the initrd file inside the temporary folder, thus removing it right after creating it (if you don't use -k, of course. when you use it, you'll see your file as specified by -o inside the /tmp/mkinitrdXXXX folder)
<Kamion> elmo: kinda
<Kamion> surak: yeah, somebody just reported that bug in Debian recently
<elmo> Kamion: you killed anastacia, you bastard
<Kamion> elmo: how
<Kamion> ?
<elmo> kamion: removed the base seed
<Kamion> er, yeah :)
<Kamion> doesn't it use STRUCTURE?
<elmo> it wasn't even 2005 germinate :P
<Kamion> you should probably use 'cut -d: -f1' on seed-directory/STRUCTURE to get your seed list
<elmo> kamion: I'm using ALL - hopefully that's unchanged?
<elmo> err, 'all'
<elmo> hmm, yay, that didn't work
<Kamion> all? wassat?
<elmo> the output file, 'all'
<Kamion> elmo: that should still work
<Kamion> I thought you meant you had a seed list hardcoded somewhere
<surak> hum, seems I've done things right now. 
<surak> It booted, altough in the ugliest way :-D
<kiko> surak, woo!
<surak> I cannot sudo udevstart ... :-D
<surak> Well, let's make it inside my beatyful script now. This way, I'll have a completely borked system, right from ubuntu live! (just for today, of course)
<mx|gone> jbailey: ping
#ubuntu-devel 2005-05-31
<mdz> jbailey: how is EarlyUserspace coming along?
<robertj> mdz: do you know if last year's bounty budget rolled over into this year?
<surak> mdz: it seems the one who's not working here is me. 
<kiko> huh?
<bluefoxicy> does OOo2 crash in breezy if you touch the menus
<surak> kiko: we were talking on pvt. He corrected me, and I said that it didn't seem to work. But what does not work seems to be my brain after all that coffee...
<kiko> heh :)
<ogra> bluefoxicy, probably, its breezy :-P
<mdz> robertj: not exactly, why?
<ogra> bluefoxicy, things are supposed to crash from time to time for your entertainment :)
<robertj> mdz: just haven't heard alot about bounties
<mdz> surak: I am glad that it is working for you now
<mdz> robertj: you'll hear a lot more about bounties this week
<robertj> good
<mdz> soon after I dig myself out of my email pit
<mdz> robertj: if there's something specific you'd like to work on, contact me at any time
<robertj> hehe, no there's not
<robertj> I was just curious
<robertj> I stick to php stuff mostly
* surak has a lot to learn. I'll put irc to an speech engine and leave it loud all night long, like that tv memory courses: "learn while you sleep at #ubuntu-devel"
<ogra> bluefoxicy, which arch is that ?
<bluefoxicy> ogra:  I need to write a resume
<bluefoxicy> ogra:  386
<ogra> hmm..
<ogra> bluefoxicy, OOo 1.x too ?
* robertj is goign to give another go at cupid when hist dist-upgrade finishes
<ogra> surak, lol.... record it and sell the tapes if it worked ;)
<surak> who on those tv shows care if something works or not? I'll sell it anyway! :-)
<ogra> heh
<bluefoxicy> ogra:  don't have 1.x
<ogra> bluefoxicy, hmm but it could be a fallback if its urgent....
<bluefoxicy> ogra:  it doens't have opendoc format
<ogra> oh, ok
* ogra uses vi for his texts
* bluefoxicy uses formatting when he gets e-mail from *@fbi.gov
<bluefoxicy> sometimes you just want it to look nice.
<Keybuk> surely getting e-mails from @nid.gov is better? :p
<Burgundavia> can someone take a look at this bug? I don't think the use meant to assign it to themselves
<Burgundavia> https://bugzilla.ubuntu.com/show_bug.cgi?id=11122
<Nafallo> xorg_6.8.2-18 will need a kick to build?
* mvo goes to bed now
<seb128> 'night mvo
<Nafallo> mvo: night :-)
<mvo> night guys :) 
<surak> mdz: Where are you?
<surak> I mean, your geographic location
<kiko> surak, LA.
<surak> ok
<surak> tks Kiko
<Nafallo> Baby: wb! :-)
<Baby> thanks Nafallo :))
<mdz> surak: as kiko says, I'm in LA (UTC-7)
<surak> Kamion gave me the impression I'm always late to talk with him :-) and told me you would be in a better timeframe.
<jordi> kiko: I did it man
<jordi> I DID IT
<doko> jordi: photos!
<kiko> jordi!
<kiko> JORDI!
<kiko> woooo!
<jordi> doko: hmm, none of the race with me right now, my flatmate has them
<surak> ?
<kiko> jordi, tell us all about this
<jordi> I have a sexy one of the prize I got tho
<jordi> kiko: I have a blog entry ready to be scp'd!
<kiko> do it
<ajmitch> jordi: you live!
<jordi> ajmitch: I actually have no pain in my legs todayh. It's pretty weird
<ajmitch> well done :)
<jordi> let me boot that lappy to get the story out
<jordi> and the pic from the cam
<jordi> I also fixed a RC bug for Sarge yesterday
<jordi> introduced a new one, which I just fixed.
<jordi> Isn't that great
<mdke> ogra, still up? if i know you...
<lamont> ENOMVI
<lamont> MVO even
<lamont> aptitude doesn't like 64-bit architectures
<lamont> Build-Depends: mozilla-dev (<< 2:1.7.7.0)
<lamont> GAH
<lamont> enigmail has bad buildd-epends
<doko> lamont: mozilla did FTFBS on ia64
<lamont> doko: the issue is that enigmail build-depends on a version older than that currently found in the archive.
* lamont bets that libao needs dpkg-love
<doko> no, just a rebuild, libarts name did change
<doko> fixing ...
<lamont> kewlness
<Nafallo> lamont: could xorg be kicked or shall I try to see if it builds locally first?
<lamont> Nafallo: it is ftbfs
<Nafallo> lamont: even since libx{au,dmcp} is rebuilt?
<lamont> hrm...  /me kicks it for giggles
<Nafallo> :-)
* robertj ahhs after finding a nice python wrapper for howl
<jordi> howl is non-free and evil :)
<robertj> jordi: what's the blessed equivanelt then ;)
<jordi> robertj: the world awaits your contribution!
<jordi> none yet afaik.
<Nafallo> lamont: kicked locally to :-)
<Nafallo> lamont: atleast it
<Nafallo> damn enter
<Nafallo> lamont: atleast it's not the same builderror ;-)
<lamont> Nafallo: heh
<mdz> amu: what does "final package" mean in your qt-x11-free changelog?
<amu> good question, right, would be better to put all changes visiable    
<Nafallo> good night all!
<lamont> back later
<zul> holy crap my internet connection is slow
<KaiL_> somebody should look a bit at "installation without any network configuration", there seam to be billions of bugs
<surak> night
<AndyFitz> night
<AndyFitz> g'day bradb
<bradb> hi
<jsgotangco> hello
<KaiL_> daniels: you duped 11127 to 1421, which seams to be about fallback for no ddc infos
<KaiL_> that's wrong, 11127 is about screens, who really want such stipid resolutions
<daniels> KaiL_: it's not wrong at all
<daniels> KaiL_: if we get 60Hz, it's because we had to guess at a refresh rate
<KaiL_> nop
<daniels> and that's going to happen because we're on amd64, and have no way to do DDC probing there yet
<daniels> unless you meant something other than what you wrote in the bug report
<KaiL_> what I mean is on i386
<KaiL_> some screens (as my 15" CRT here) really list "1280x1024@60Hz" in ddcprobe
<daniels> right
<KaiL_> and that get's used
<daniels> not usually
<KaiL_> I had "more than enough" such in #kubuntu ;)
<daniels> xresprobe only gives you the *second* highest resolution
<daniels> so if 1280x1024@60 is the highest and 1024x768@80 is the second-highest, it'll use 1024x768@80
<KaiL_> and this second is what get's used?
<daniels> if 1280x1024@80 is the highest and 1280x1024@60 is the second-highest, it'll use 1280x1024@80
<daniels> yes
<KaiL_> then  why I get 1280@60Hz? :)
<KaiL_> does the 1x1 tell me something interesting in xresprobe?
<daniels> KaiL_: how did you configure your server?
<daniels> 1x1 tells you things went really, really badly
<KaiL_> nothing manually
<KaiL_> oh
<KaiL_> like "monitor sends nonsence"?
<Burgundavia> m vogt is mvo no?
<crimsun> yes.
<Burgundavia> ok, I don;t see him here
<Burgundavia> ok, dumb question. Is wxpython in Ubuntu/Debian linked against GTK1.x?
<daniels> KaiL_: either that or my regexp is broke, yeah
<crimsun> Burgundavia: two different answers.
<KaiL_> hmm, but ddcprobe find's something
<crimsun> Burgundavia: in Ubuntu Hoary, they're built against gtk2
<crimsun> Burgundavia: wxwidgets 2.5 has been removed from Debian
<KaiL_> lol, "timing: 1280x1024@75 (VESA)"
<crimsun> Burgundavia: in Ubuntu and Debian both, wxwindows (2.4) is built against 1.2
<Burgundavia> ah
<Burgundavia> so the program needs to link against 2.5?
* KaiL_ doesn't belive that this works ;)
<crimsun> Burgundavia: if you're using wxpython2.5.3, yes
<Burgundavia> ok
<Burgundavia> hmm
<ajmitch> 2.4 & 2.5 can have a slightly differentA PI in some places
<KaiL_> daniels: there we have the 1x1: "dtiming 1x1@642500"
<KaiL_> somebody should send MS 100 firmware coders - after one week they have destroyed windows totally
<Burgundavia> are we talkign python 2.5? the dev version?
<KaiL_> daniels: so your regex isn't broken, the firmware coder was just an idiot
<crimsun> Burgundavia: I was talking about wxwidgets 2.5 (compiled against gtk2 in Ubuntu) and wxpython 2.5
<daniels> KaiL_: oh dear
<crimsun> Burgundavia: the latter can be made to link against any version of python, though by default that should be 2.4
<daniels> i should blacklist that
<KaiL_> the problem why xresprobe lists 1280 (the highest..) isn't solved
<Burgundavia> crimsun, the problem is that then wxpython stuff looks like ass, becuase it is gtk1.2
<crimsun> Burgundavia: err, in Ubuntu Hoary/universe?
<Burgundavia> yes
<crimsun> Burgundavia: hmm, so apt-cache depends must be lying
<Burgundavia> both hoary and breezy show the issue
<Burgundavia> crimsun, so is the bug in the application or in wxwidgets?
<crimsun> Burgundavia: afaict, wxpython 2.5 links against wxgtk 2.5 which links against gtk 2
<crimsun> Burgundavia: what application?
<Burgundavia> londonlaw, only available in breezy
<crimsun> there's nothing wrong
<crimsun> londonlaw links against wxpython 2.4, which links against wxwindows 2.4, which links against gtk 1.2
* Burgundavia thinks that applications that look like gtk1.x are a bug
<crimsun> heh
<Burgundavia> I think I noticed it with jsconfigurator as well
<crimsun> as soon as Ron pushes wxwidgets 2.6 into Sid/experimental, it's time to ask for a sink
<crimsun> s/sink/sync
<Burgundavia> sinking feeling?
<Burgundavia> is there actual code changes to programs to make them work with 2.5 instead of 2.4?
<crimsun> usually no
<crimsun> 2.5 is compiled with abi compat with 2.4
<Burgundavia> so 2.5 does the messy work of moving from 1.x to 2.x?
<crimsun> for gtk, yes, but don't use 2.5 or Ron will scream at you
<Burgundavia> ok, why is that?
<crimsun> particularly since he has been hassled about 2.6 enough
<crimsun> that and the license issue that caused 2.5 to be ripped out of Debian
<Burgundavia> so once 2.6 comes out, we are going to have to manually rebuild all python packages to use 2.6?
<Burgundavia> s/python/wxwidget
<crimsun> no, because that's built as part of wxwidgets 2.6 source
<crimsun> oh, packages that depend on wxpython?
<crimsun> probably
<Burgundavia> but apps like londonlaw?\
<Burgundavia> ok
<Burgundavia> sign me up!
<ajmitch> 2.5 isn't always compatible with 2.4, I've found
<crimsun> ajmitch: sadly
<Burgundavia> ok, so there will be some upstream development needed
<Burgundavia> what was the licence issue?
<crimsun> plus there's talk of introducing an abi-incompat change into 2.6 (!)
<crimsun> so some people are hassling for a version bump to 2.8 (!)
<crimsun> it's all quite mad
<crimsun> Burgundavia: Debian#305300
<Burgundavia> ok, so a quite rundown. 2.6 is coming into debian and we will need to rebuild packages against it to get gtk2.x stuff. 2.5 didn't get into debian becuase of license issues.
<crimsun> it was in Debian, but it will not be in Sarge
<Burgundavia> ok
* lamont fixes samba, cursing (but only a little) dpkg
<infinity> lamont : What was broken with samba?
<lamont> dpkg love
<lamont> DEB_BUILD_GNU_TYPE      := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE| sed 's/linux$$/linux-gnu/')
<lamont> ,,,
<lamont> and then fix the if below to look for linux-gnu
<lamont> that's the current "traditional" fix for things that have suddenly stopped delivering lots of pieces of themselves
<infinity> lamont : Have you uploaded that fix yet?
<lamont> if you're lucky, the build fails.  If you're not, then the package does a good job of only deciding what should be there once...
<lamont> just barely
<infinity> Ahh, kay.
<infinity> Did you merge with Debian at the same time?
<lamont> uh.... 34.0.14a-1ubuntu2
<lamont> what's debian ahve?
<infinity> Kay, no then. :)  I'll merge later.
<dilinger> infinity: hey, is the apache2 pcre patch that you backported from 2.1 online anywhere?
<infinity> (Just one revision higher in Debian, but it's an icky bug)
<infinity> dilinger : The one from HEAD, or ours?
<lamont> infinity: and we need to pester keybuk and find out what verbage to file in the bug in debian for fixing it...)
<infinity> dilinger : Ours is obviously online, in the source package.
<dilinger> infinity: i was hoping for a link that i could put in the upstream bug report
<dilinger> 'cause people are reopening the bug
<dilinger> linking to a diff.gz is suboptimal
<lamont> infinity: you should drop that on patches.ubuntu.com
<infinity> Ahh.  Well, extract it and put it in your people.d.o space, then.
<dilinger> infinity: then it doesn't stay up-to-date
* lamont wishes again that lunchpad was online
<infinity> dilinger : How up-to-date does it need to be?... It's tracking a stable release.
<lamont> s/lunch/launch/
<infinity> Mmm... lunchpad.
* infinity is hungry.
* lamont is sleepy
<lamont> mirror-missing | wc -l
<lamont> 150 :-(
<infinity> dilinger : I need to forward-port my backport back to HEAD anyway, and submit my changes to Joe for 2.1
<infinity> dilinger : If you're feeling bored...
<infinity> *cough*
<dilinger> infinity: dude, i'm done w/ that crap ;p
<lamont> if someone is really bored, I could use gcj support in ccache
<infinity> dilinger : Heh.  Fair enough.  I'll find me a round tuit sometime before 2.2 releases, I'm sure.
<lamont> esp since doko keeps uploading gcc-*
<dilinger> i have no desire to do any sort of long term maintenance on it
<tritium> fabbione, are you around?
<fabbione> tritium: yes
<tritium> fabbione, there's some discussion in #ubuntu regarding kernel panics after the kernel security updates, and a thread on the forums.
<fabbione> tritium: open a bug with all the info
<fabbione> usual procedure
<fabbione> usual info required.
<tritium> fabbione, okay.
<Lathiat> eww
<Lathiat> in firefox in hoary
<Lathiat> if you open an unknown file you get a XUL error
<Lathiat> (in this case, a .tiff)
<Lathiat> http://bur.st/~lathiat/firefox-xul-error.png
<infinity> Lathiat : Can you file a bug?
<infinity> Lathiat : I'll look at it later.
<infinity> Lathiat : Assign the bug to adconrad@ubuntu.com
<Lathiat> infinity: ok
<Lathiat> infinity: oh man
<Lathiat> infinity: its *really* broken
<Lathiat> the download manager doesnt work either
<Amaranth> Lathiat: You went from breezy breakage to hoary breakage, nice.
<Lathiat> Amaranth: oh yeh
<Lathiat> Amaranth: im still terrified of pressing random shortcut keys :)
<Amaranth> hehe, i've gotten used to using the mouse for everything in gedit
<Amaranth> that's the only app i use that i've had to change my habits in though
<Lathiat> heh
<Lathiat> ^-shift-t in g-t is what bites me most
<Amaranth> new tab, closes the window instead?
<Lathiat> yeh
<Amaranth> i don't do tabbed g-t, so i'm ok there
<Lathiat> i dont use it that often
<Lathiat> but i do it to do random things quickly
<Amaranth> nothing like a 1am phone call to scare the shit out of you
<Amaranth> i thought someone died
<Lathiat> tut tut Amaranth 
<Lathiat> smeg died. :)
<Amaranth> ha
<Amaranth> err, that's not possible
<Amaranth> pygtk keeps it running when when you get an exception
<Lathiat> by died i mean spat out a backtrace :)
<Amaranth> gimme?
<Lathiat> http://www.squaa.org/smeg.txt
<Lathiat> trying to add an entry
<Lathiat> fucking hell firefox is *totally* broken
<Lathiat> bookmarks windows dont work either
<Lathiat> i assume everything is plain farked
<Amaranth> that's a fucked up backtrace
<Lathiat> maybe i should go get the backports version ;)
<Amaranth> it skips from one part of the code to another that aren't related
<Amaranth> making you think .get_active() is causing the error
<Lathiat> heh
<Amaranth> where were you creating the entry at?
<Amaranth> what menu did you have selected?
<Lathiat> clicked on sound &video
<Lathiat> new entry
<Lathiat> put in details
<Lathiat> hit ok
<Lathiat> nothing happened
<Lathiat> that spat out
* Amaranth tries to reproduce
<Amaranth> *** glibc detected *** realloc(): invalid next size: 0x085c67b0 ***
<Amaranth> Aborted
<Amaranth> eek
<Lathiat> uh, ouch
<Amaranth> your problem is reproducable, mine isn't
<Amaranth> fuck, i forgot a True
<Amaranth> change line 205 of /usr/lib/smeg/MenuHandler.py to         xmlparent = self.getMenuFromPath(path, True)
<Amaranth> err, that's 204, i have a debug print in there
<Amaranth> that'll do until i release 0.6.1
<Amaranth> need to figure out how to load KDE icons to do that
<Lathiat> :) cool
<Lathiat> heh
<Amaranth> or maybe not, i dunno
<Lathiat> im a sick sick puppy
<Lathiat> im syncing maildir from my server to my laptop
<Lathiat> then running a local imap server so thunderbird can read it
<Amaranth> yes, yes you are
* Amaranth hopes Matt Kynaston doesn't hate him
<Amaranth> he sent me a MenuEditor class he thought i'd like to use then disappeared
<Amaranth> The class kinda sucked but i took some methods from it for my MenuHandler. I gave him credit, but it's licensed under the GPL and his code didn't actually have a license with it.
<pitti> Morning
<mvo> morning pitti 
<bob2> daniels: fontconfig.org seems fucked.
<bob2> (dns-wise)
<bob2> hah, which isn't so surprising when it only has one dns server
<daniels> that server should be alright though (gabe)
<bob2> Name Server:NS.KEITHP.COM
<bob2> (which is unreachable)
<daniels> oh dear, no
<daniels> right
<daniels> yeah, that's the end of his DSL line
<bob2> hah
<\sh> morning gentlemen
<fabbione> hey pitti
<fabbione> pitti: rumors are that one of the security fixes is making OOPSorama on hoary :/
<pitti> fabbione: sounds like fun
<fabbione> but i can't see how and why. nobody gave me info yet (other than rumors)
<daniels> fabbione: did you see the abi thing too?
<pitti> fabbione: bah, hardware problem 
<fabbione> daniels: yes. the abi is ok
<daniels> fabbione: ok, cool
<fabbione> daniels: the check is done automatically at build time, otherwise FTBFS
<pitti> trulux: when you are here, please ping me back, we need to talk about the patch again
<Treenaks> pitti: have you packaged the LUKS tools already (or: are you planning to?)
<pitti> Treenaks: dist-upgrade, plugin your encrypted stick and watch the magic happen... :-)
<pitti> Treenaks: i. e. yes
<Treenaks> pitti: I mean the "other side"
<Treenaks> pitti: i.e.: how do I create an encrypted stick :)
<pitti> Treenaks: cryptsetup has the LUKS extension, pmount calls it transparently, and g-v-m asks you for a passphrase and forwards it to pmount
<pitti> Treenaks: ah
<pitti> Treenaks: there is not yet a GUI tool for that
<pitti> Treenaks: sudo cryptsetup luksFormat /dev/foo
<Treenaks> pitti: ok, "cryptsetup has the LUKS extension" was the missing piece of my puzzle
<pitti> Treenaks: sudo cryptsetup luksOpen /dev/foo mystick
<Treenaks> thanks :)
<pitti> Treenaks: sudo mkfs.XXXX /dev/mapper/foo
<pitti> ok
<pitti> Treenaks: I recently discovered that we don't even have a GUI tool to format things other than floppies
<pitti> Treenaks: somebody should write a nice pygtk thingy which calls mkfs.* on a device and supports encryption
<Burgundavia> pitti, why not extend the floppy formatter?
<Burgundavia> make it generic
<Treenaks> Burgundavia: skipping "known" (i.e. mounted partitions), probably?
<Treenaks> Burgundavia: and using HAL to get a list of "formatable" devices?
<Burgundavia> yes
<jsgotangco> floppy formatter died on me (i don't have a floppy drive on my laptop)
<Burgundavia> as formatting a floppy is really the same operation as formatting a stick, from the users perspective
<Treenaks> Burgundavia: clearing a CD-RW might as well be the same too
<Burgundavia> good point
<Treenaks> from a user pov
<pitti> well, if the interface is tweaked a bit to just display the density dropdown if you actually have a floppy, that might be easier, yes
<Burgundavia> it should automagically figure out the density and type
<pitti> Treenaks: n-cd-burner, and probably other tools as well, automatically clean a cd-rw
<Treenaks> pitti: HAL is pretty clear on that right? ('this is a floppy drive' etc0
<pitti> Burgundavia: well, I can't run Ubuntu on machines that still have low-density drives anyway :-)
<Treenaks> pitti: I have a 5.25" floppy drive -- still works
<jsgotangco> wow
<Burgundavia> for floppies that we can't figure it out, then it should offer the most common but have a list of the others
<Treenaks> jsgotangco: I even have floppies.. we need a GWBASIC compatible BASIC interpeter! :)
<pitti> Treenaks: "  storage.drive_type = 'floppy'  (string)"
<Treenaks> pitti: so that's easy
<pitti> Treenaks: but no hint about the size
<Treenaks> pitti: hm.. that should probably be added then?
<pitti> Treenaks: btw, if you test encrypted stuff, you can't unmount them properly in gnome yet
<pitti> Treenaks: you have to use pumount for now, I only uploaded g-v-m yesterday night
<Treenaks> pitti: I have to use pumount anyway, because hald crashes when I plug in my GPS
<pitti> ah, that bug...
<Treenaks> the 239-entry backtrace, yes :)
<pitti> Treenaks: it seems easy to fix, just no time yet...
<pitti> #1  0x08057695 in hal_property_new_string (key=0x8068c70 "info.product", value=0x0) at property.c:86
<pitti> ^ null string for value, and it calls a function on it
<Treenaks> ah.. the string is empty/non-existent
<Treenaks> "To test LUKS, you can use loop to make a blockdev out of any container file. The only requirement is that it's larger than 1mb." --> cool, 1.44M floppies work ;)
<pitti> Hey carlos, seb128 
<carlos> morning
<pitti> Treenaks: I'm not at fixing hal, I'll fix that at a very low level to catch similar issues as well
<Treenaks> pitti: ok
<pitti> Treenaks: argh, s/not/now/
<Treenaks> pitti: even more ok :)
<pitti> Treenaks: are you on i386?
<Treenaks> pitti: yes
<pitti> Treenaks: okay, I give you test debs in a minute
<Treenaks> pitti: but I'm not near the machine now, and the card isn't plugged in
<pitti> ah, too bad
<pitti> Treenaks: well, then I just upload
<pitti> I *know* my fix must be right *hehe*
<Treenaks> ;)
<seb128> hey pitti !
<Amaranth> seb128: btw, pyxdg 0.11 is good now
<Amaranth> seb128: he pulled the release and put it back up when we fixed the bug
<seb128> hum?
<seb128> he did 2 different 0.11?
<Amaranth> yeah, not my idea
<seb128> some upstream deserve some kicks
<Amaranth> afaik the first one was only up about 45 minutes
<seb128> not a reason
<daniels> that's what 0.11.1 is for
<Amaranth> yeah
<seb128> please tell him for next time :)
<Amaranth> i did the same thing with smeg though :)
<Amaranth> i uploaded 0.6, found the bug in pyxdg and pulled it. then i fixed some other little bugs in smeg and uploaded it again as 0.6
<seb128> what the issue with 0.6.1?
<Burgundavia> Amaranth, that is very bad, because as a user, if I downloaded it before your pulled it, I would think I have the latest version
<seb128> packaging wise too
<Amaranth> Burgundavia: I know, it was stupid. In my defense, I had been up 27 hours at the time.
<seb128> if somebody packages the new version there is no way to change the .orig.tar.gz
<Amaranth> smeg 0.6.1?
<seb128> yep
<Amaranth> line 204 in MenuHandler.py (/usr/lib/smeg/) needs to be         xmlparent = self.getMenuFromPath(path, True)
<Amaranth> unless i figure out how to load KDE icons in the next hour i'm going to release 0.6.1 with just that
<Amaranth> then i need a MOTU to sponsor my package :)
<Treenaks> Amaranth: who wants those anyway ;)
<Lathiat> Amaranth: another bug, new items dont appear in smeg
<Lathiat> Amaranth: as in when you create them with smeg
<Amaranth> Lathiat: It's a timing issue, I think. If you click on the menu again they show up.
<\sh> Amaranth: smeg == python kde?
<Amaranth> smeg == gnome 2.10 menu editor
<\sh> hehe
<Amaranth> yes, i know what smegma is
<\sh> whats your problem then with kde icons?
<Amaranth> appearently they aren't in the hicolor theme so i need to load them another way
<seb128> kubuntu guys have fixed that now
<Amaranth> i was told that was fixed in kde CVS for the apps they ship, at least
<\sh> Amaranth: u read riddells blog entry?
<seb128> \sh: you need to be agressive? when he changed that this was hoary
<seb128> and KDE/hoary is b0rked 
<Amaranth> kubuntu guys fixing it doesn't help gentoo and freebsd users :)
<Amaranth> and no, that entry isn't showing up on planet ubuntu, is he on there?
<seb128> neither hoary users
<Amaranth> I guess PyXDG has something for this, but I need to get the name of the being used.
<Amaranth> err, the name of the theme
<\sh> Amaranth: <ironicmode>You don't need to think about gentoo, all the guys are leaving gentoo</ironicmode> 
<Amaranth> which as far as i can see gtk.IconTheme doesn't give me
<Kamion> lamont: Keybuk said that the s/linux/linux-gnu/ thing was inappropriate, and that we should be preferring DEB_HOST_ARCH_OS if available instead
<mjg59> AndyFitz: Could you possibly stick a copy of /proc/acpi/dsdt from your Dell up somewhere?
<AndyFitz> mjg59,  sure thing 
<Burgundavia> AndyFitz, is there a way to preview the artwork stuff you are doing?
<Burgundavia> AndyFitz, to give feedback?
<AndyFitz> Burgundavia, it will be be packaged into ubuntu-artwork shortly if not already
<Burgundavia> AndyFitz, cool, thanks
<AndyFitz> brb
<Burgundavia> AndyFitz, I have seen no update to ubuntu-artwork
* Treenaks loves mjg59's blog
<Amaranth> do the gconf python bindings come in python's pygtk package?
<Lathiat> i think so
<Nafallo> hi all!
<seb128> gconf is a python-gnome stuff, not pygtk
<Amaranth> python-gnome2 or python-gnome2-extras?
<Amaranth> nevermind, it's python-gnome2
<AndyFitz> mjg59  pmed
<Lathiat> woo ipw2200 monitor mode
<Treenaks> \o/
<fabbione> yeah except that dpatch made the upload useless
<fabbione> a new kernel will be on the way soon
* Lathiat laughs at fabbione 
<Lathiat> fabbione: thanks ;)
<Lathiat> fabbione: ive gone back to hoary for the moment anyway
<Lathiat> the X breakage is hurting my productivity
* Nafallo pinned X to hoary til 6.8.2-18 builds :-)
<seb128> elmo: xpdf/hoary is b0rked according to some mail on the user list, the hoary index has a main path and the package is universe on the pool
<elmo> seb128: err, right
<elmo> more to the point, tho, xpdf wants to come back into main
<seb128> do you know why?
<mjg59> Hmm. I should really write up the HP stuff.
<elmo> cupsys b-ds on it
<elmo>  o xpdf: xpdf-common, xpdf-utils
<elmo>    [Reverse-Depends: cupsys] 
<elmo> err, depends even
<seb128> urg
<seb128> pitti: why, WHY? :)
<pitti> seb128: cups uses xpdf to convert PDF to Postscript
<pitti> seb128: in former times it used a verbatim copy of xpdf copy, which was *evil*
<seb128> k
<seb128> maybe it could use poppler? :p
<Lathiat> haha
<pitti> seb128: why is this a problem?
<pitti> seb128: I mean, why has xpdf to be demoted to universe?
<seb128> xpdf is ugly, do we need it for main?
<elmo> pitti: daniels wants to drop lesstif
<pitti> seb128: we can still have evince as default pdf viewer
<seb128> right
<elmo> so he can drop/not deal with xprint, AFAICR
<pitti> elmo: oh, that would indeed be nice
<seb128> but we have 2 basecodes to support then
<elmo> and xpdf is the last lesstif holdout
<pitti> well, cups does not need the frontend part
<seb128> I don't really care, you are the one doing security support
<pitti> seb128: supporting xpdf is reasonably easy, but supporting the old lesstif is a pita
<seb128> k
<seb128> any the hoary filename is b0rked
<seb128> that is to fix :)
<pitti> seb128, elmo: but does xpdf-utils really depend on lesstif?
<seb128> no idea
<pitti> (I can't see a dependency)
<pitti> no, it doesn't
<pitti> elmo: I can happily purge lesstif*, this only removes xpdf-reader, but not xpdf-utils
<pitti> seb128: ^ 
<Lathiat> firefox seems to have fixed itself
<Lathiat> infinity: firefox seems to have fixed itself, nfi wtf was u
<Lathiat> infinity: p
<elmo> pitti: I think we should split the source, like we did for php4, dropping xpdf-reader entirely (rather than just demoting it to universe) is a bit harsh
<pitti> seb128: I would like to have xpdf-utils in main, it's really useful
<seb128> pitti: I don't really care as said, I just thought than having xpdf to support too is extra work
<pitti> elmo: can't we have -reader in universe, and -utils in main? we are already doing this for a number of packages
<pitti> seb128: right
<elmo> pitti: no, -utils's source package (currently xpdf) has to be in main, if it's in main
<elmo> if it's in main, it's b-d's (i.e. lesstif) have to be in main
<pitti> ah, crap, rihgt
<pitti> elmo: okay, splitting the package would make sense
<pitti> shall I try?
<elmo> sure
<Lathiat> Amaranth: tip: "Smeg Menu Editor"
<Amaranth> Lathiat: SMEG = Simple Menu Editor for GNOME
<Burgundavia> Amaranth, you toot tip, should be "Edit the menus" or something similar
<Burgundavia> s/toot/tool
<Lathiat> Amaranth: yes but the menu item
<Lathiat> Amaranth: should say "Smeg Menu Editor"
<Lathiat> Amaranth: because "smeg" means nothing to someone
<Burgundavia> no
<Burgundavia> it should say Menu Editor
<Lathiat> Amaranth: take "Firefox Web Browser", "Gaim Instant Messenger" for example
<Burgundavia> or SMEG Menu Editor
<bob2> calling a serious app "smeg" seems a bit wrong
<Lathiat> bob2: heh
<Lathiat> bob2: but its so good
<pitti> elmo: would it be okay for you for "xpdf" source to only build -reader, and have the same orig.tar.gz for the source pkg "xpdf-utils" which spits out -common and -utils? copying the orig.tar.gz is a bit redundant, but actually separating the code is much work
<Amaranth> btw, what should my first entry into a debian/changelog be?
<elmo> pitti: sure, it's only 500K
<pitti> ok
<pitti> then that should be fairly easy
<Lathiat> Amaranth: * Initial revision. or something
<Lathiat> * hai2u, kthxbai
<Amaranth> would "Initial packaging" work?
<Lathiat> "initial release" seems popular
<Amaranth> *shrug*
<pitti> seb128: in fact, libpoppler actually sounds interesting...
<seb128> yep
<pitti> seb128: if it has a reasonably easy interface, I'd rather convert cups to use poppler than to have the pain of keeping two xpdf packages
<pitti> seb128: the code should be based on xpdf, does evince use poppler? (to get an impression of the quality)
<seb128> it should
<seb128> yes, it does
<seb128> they have switch from xpdf to poppler like 2-3 months ago
<pitti> seb128: does poppler have a nice command line tool?
<seb128> no
<seb128> that's only a lib atm
<Amaranth> Lathiat: 0.6.1 is out :)
<Lathiat> Amaranth: heh
<Lathiat> that was fast
<Amaranth> yeah, i have up on the icon stuff
<Amaranth> err, gave
<seb128> pitti: you can read the README, there is some details on poppler here
<Amaranth> damn, one warning in lintian because of a copy/paste job
<pitti> seb128: actually, having a proper pdf library was a longstanding wish for the packages that copied xpdf code, like cupsys and tetex
<Amaranth> so rushed to release i forgot to check :)
<pitti> seb128: so I rather invest my time to use the lib than to whack up xpdf, I guess
<seb128> better option I think yes
<mdke> morning ogras
<Kamion> um. is http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html really true?
<Kamion> zero uninstallables seems a bit optimistic
<thom> seems extremely optimistic
<pitti> seb128: hmm, ENODOCUMENTATION... :-(
<Lathiat> thom: heh
<Kamion> I think I must have caught it in the middle of mirroring; fixed
<Kamion> well, "fixed"
<Kamion> that's more like it, THE ENTIRE WORLD is uninstallable
<elmo> 15 4,10,16,22 * * * sh /home/archvsync/archive-sync
<elmo> kamion: ^-- rookery's mirroring, FWIW
<seb128> pitti: I'm asking on #evince if they have some hidden files about the API or something :)
<Kamion> elmo: the britney mirror's a separate job; runs at 15,45 * * * *
<Kamion> but thanks
<elmo> err, you do your own mirroring?
<elmo> anyway, if you do, I'd switch that to like 0,30, that's just before the cron.daily
<elmo> (I'm assuming/hoping you're only mirroring Packages/Sources, so that should be more than enough time)
<ogra> i'm just patching dupload to have ubuntu as the first mirror, by default the $default_host variable is commented out, is it ok to set it to ubuntu and uncomment it by default ?
<jsgotangco> bye bye
<mdke> night
<\sh> ogra: what about a postinst script for adjusting the settings
<ogra> \sh, why, the default config is there... no need to fiddle with scripts in it...
<\sh> ogra: right
<ogra> ok, if there are no further objections, i'll upload it...
<mdke> ogra, get my message?
<Kamion> elmo: it's not mirroring the archive, I haven't set up the separate britney run on rookery yet; it's only mirroring the output of the britney run on jackass, i.e. one HTML file and one text file
<elmo> kamion: _oh_
<Kamion> I've shoved it back five minutes though
* thom wallops ogra for using blink tags :-)
<ogra> :)
<\sh> hmm
<Netsnipe> hi everyone
<\sh> libdnet-0.29 after renaming libdnetc2-0.29-0ubuntu1 ?
<Netsnipe> seb128: ping
<seb128> pong
<Netsnipe> seb128: can you please sync balsa and tsclient in ubuntu against what's currently in sarge?
<Netsnipe> seb128: you guys are a bit behind and there's been a tonne of stabilisation patches = )
<\sh> argl...native package
<Netsnipe> seb128_: can you please sync balsa and tsclient in ubuntu against what's currently in sarge?
<Netsnipe> seb128_: you guys are a bit behind and there's been a tonne of stabilisation patches = )
<Kamion> Netsnipe: we have automatic bugs to remind us of merges
<seb128_> <seb128> no need to ask for syncs
<Kamion> they will all get done by upstream version freeze
<seb128_> <seb128> just wait
<Netsnipe> seb128_: never saw that message.
<seb128_> that's why I copy it
<Netsnipe> heh.
<seb128_> anyway balsa is universe
<seb128_> so not a priority
<Kamion> e.g. https://bugzilla.ubuntu.com/show_bug.cgi?id=10412
<Netsnipe> seb128_: 2.3.0-2 that you copied had a RC bug
<ogra> Netsnipe, MOTU will care for balsa... if you got a prob with a universe package, feel free to join #ubuntu-motu ;)
<seb128_> I didn't copied 2.3.0-2
<Kamion> also note the T-14 and T-13 weeks stages of http://udu.wiki.ubuntu.com/ReleaseCycle
<Netsnipe> ogra: seb128 is my counterpart in the "parallel universe"
<ogra> hehe
<Netsnipe> seb128: http://packages.ubuntu.com/changelogs/pool/universe/b/balsa/balsa_2.3.0-2ubuntu1/changelog doesn't list any other patches
<Netsnipe> but anyway...I've got nothing else to add
<Netsnipe> take your time. I've done all my hard work doing the squishing
<seb128_> Netsnipe: yeah, I need to sync
<Netsnipe> thanks seb128_ 
<Netsnipe> seb128_: if you're too busy you could always hassle me to join MOTU
<seb128_> we could do that automatically if the Debian package was using a current version of gtkhtml
<seb128_> IIRC it uses 3.2
<Netsnipe> seb128_: want to do some testing against the 3.5?
<Netsnipe> s/to/me to/
<seb128_> no, that's fine
<seb128_> I will do the sync now
<seb128_> just changing the Build-Depends to 3.6
<Netsnipe> seb128_: against 2.3,0-2sarge1 or 2.3.2-1?
<seb128_> current
<seb128_> is: 2.3.2
<Netsnipe> that's fine
<Netsnipe> btw: please pass on thanks to Ati (whoever does your Xhosa translations) from Erick Woods (upstream for tsclient)
<Netsnipe> s/Ati/Adi/
<Netsnipe> it's strange how that translation got to him
<Netsnipe> seb128 merged it into the ubuntu package
<Netsnipe> I merged it into the debian package
<Netsnipe> and then upstream merged the debian patches
<seb128_> he he
<seb128_> does upstream have a bug tracker or something?
<seb128_> I've no idea on what to do about tsclient bugs
<seb128_> which is a pity
<Netsnipe> seb128_: pretty much I am.
<Netsnipe> seb128_: he's on my gaim list
<seb128_> they should ask to use bugzilla.gnome.org
<Netsnipe> seb128_: I'll hassle him about that.
<seb128_> we have 8 bugs open on tsclient
<Netsnipe> seb128_: yeah. I'll pass those on to him
<seb128_> thanks
<Netsnipe> oh well gotta go. I'll get tsclient 0.140-1 uploaded into unstable once 0.132-7 gets pushed into testing
<Netsnipe> later seb128 
<pitti> seb128: oh, libpoppler-glib-dev has a nice API, in contrast to libpoppler-dev
<Amaranth> i suspect libpoppler-glib is what evince uses :)
<doko> mvo: aptitude fails on amd64 and ia64. why doesn't aptitude b-dep on gettext und uses the system libintl?
<mvo> doko: let me have a look
<doko_> mvo: aptitude fails on amd64 and ia64. why doesn't aptitude b-dep on gettext und uses the system libintl?
<mvo> doko_: I'll have a look
<pitti> seb128, elmo: forget the xpdf split, I modified xpdf's pdftops script to compile with poppler
<pitti> s/script/program/
<elmo> you mean cupsys's pdftops?
<pitti> elmo: no, that's a perl script that calls pdf2ps from xpdf-utils
<elmo> ah
<pitti> elmo: we can replace that pdf2ps by a lightweight version that uses libpoppler
<pitti> the only question is whether I shall just integrate this into cupsys, or create a new source package "poppler-utils" or so
<pitti> .. or modify the libpoppler source to create a new deb
<pitti> right now I'd favor the cups integration
<Burgundavia> ok, dumb question
<Burgundavia> when Debian moves the GFDL stuff to non-free, is Ubuntu going to follow that?
<elmo> no
<Amaranth> GFDL is non-free? wtf
<Burgundavia> yes
<robtaylor> Amaranth: where have you been?!
<Amaranth> appearently in the land of the sane
<Amaranth> what's the argument?
<Burgundavia> basically the screwballs at -legal decided taht GFDL is non-free because it has some yucky bits
<robtaylor> GFDL is non-free in lots (3) nasty ways
<mjg59> Amaranth: It restricts various things that should be allowed
<Burgundavia> and thus all docs are moving to non0free
<bob2> Amaranth: the gfdl is terrible
<Burgundavia> inlcuding useful things like, say 'man gcc'
<bob2> Burgundavia: lots of useful things are non-free
<Burgundavia> which means those things will not be installed by default
<bob2> it's a shame, but you can't go pretending they're not just because it would be nice
<Burgundavia> bob2, but to call the GFDL non-free is splits the hairs ont eh back of the flea
<bob2> it's really not
<Amaranth> so basically all the documentation is moving to non-free
<elmo> Burgundavia: no, it's really not
<elmo> Burgundavia: this has nothing to do with -legal being full of morons these days
<bob2> Amaranth: only documentation under that silly license
<elmo> the GFDL really isn't free
<Burgundavia> yes, the GFDL is not very nice
<mjg59> Burgundavia: Approximately nobody within Debian claims that the GFDL is free
<mvo> doko: aptitude fails because of a error in the configure bit that checks for gettext
<Burgundavia> mjg59, but where is the sanity?
<bob2> Burgundavia: blame gnu for concocting such a silly license
<Amaranth> all of wikipedia is under that license... :/
<mjg59> Burgundavia: We're working with the FSF to try to fix the license
<bob2> Amaranth: which is another shame, but see what mjg59 is saying
<Burgundavia> bob2, CC wasn't out then
<robtaylor> Burgundavia: blame RMS for just going ' you dont understand' when anyoen tries to discuss it...
<mjg59> The FSF are receptive
<bob2> Burgundavia: CC is also non-free
<Amaranth> but you'd have to get every contributor to wikipedia to accept the new one
<Amaranth> not possible
<bob2> Burgundavia: if you want a free documentation license, use the GPL or MIT
<Amaranth> anyone got a link to the debian-legal archive for all this?
<Burgundavia> bob2, ok, they are not specifically meant for docs
<bob2> Burgundavia: indeed, but they're still better license for documentation than CC or the GFDL are
<Amaranth> CC isn't either
<Burgundavia> Amaranth, about once a month it gets talked about
<bob2> Amaranth: http://people.debian.org/~srivasta/Position_Statement.html
<mjg59> CC is also being worked on
<Amaranth> in other news, i hate hoary
<Burgundavia> elmo, what I really care about is that ubuntu is not goign to follow this absolutely insane path
<robtaylor> Burgundavia: doesnt matter, you still often want to combine code and documentation, so licensing *needs* to be compatible. and preferably identical
<robtaylor> ;)
<Amaranth> Burgundavia: where could they move the docs to? restricted? that'd be silly
<Burgundavia> robtaylor, I understand all the legal issues, but there are times to use a nuke and times to use a popgun. This is using nuke to kill a flea
<robtaylor> what *exactly* is the defining chacteristic of main vs retrictued, univers vs multiverse?
<robtaylor> i though it was free/non-free, but obviously not...
<Amaranth> multiverse is like universe's restricted, i think
<robtaylor> Burgundavia: you're overestimating the issues dramatically
<bob2> main is free and supported, restrictes i non-free (drivers) and supported, universe is free and supported, multiverse is non-free and not supported
<mjg59> Burgundavia: Would you prefer that Debian place something that doesn't meet the DFSG in main?
<Burgundavia> I see all the license agruments, this is what I also see
<aj> what, like the text of the GPL? :-P
<robtaylor> bob2:  so gfdl docs wwill go in restricted/multi?
<Burgundavia> I type in 'man gcc' and I get nothing on a fresh install
<mjg59> aj: Bah. Yes, well, that case is special.
<mjg59> Burgundavia: Right. And how do you propose that be fixed?
<robtaylor> aj: taht iws frewew
<bob2> Burgundavia: you get that anyway, since gcc isn't installed on ubuntu or debian by default
<Amaranth> the text of the GPL is under the GFDL? :)
<robtaylor> ARGH. I'vew broken my keyboard
<Burgundavia> bob2, man $program, where $doc is gfdl
<mjg59> Burgundavia: (Leaving it in main isn't really possible without changing the social contract)
<Amaranth> if it's in main it has to be Free
<mjg59> Amaranth: Correct
<Burgundavia> mjg59, that is cutting the world very black and white, which it is not
<mjg59> So we can do that by fixing the license, which is what we're trying to do
<mjg59> Burgundavia: "Free" or "Non-free" is a black and white choice
<bob2> Burgundavia: a) this has been put off until after sarge, b) people are trying to unfuck the GFDL before the next release so that doesn't have to happen
<pitti> daniels: is xpdf the only thing that still requires lesstif?
<elmo> yes
<elmo> he fixed vim yesterday
<pitti> cool
<Burgundavia> mjg59, bob2, robtaylor I see all the issues, and I have now read most of the emails and position statements, and I understand why Debian is oding it, but it still strike me as insane and overkill
<mjg59> Burgundavia: If somebody can come up with a better solution, we're willing to do it
<mjg59> But non-free stuff in main is not an acceptable long term solution
<robtaylor> --
<trulux> pitti: ping
<pitti> Hi trulux 
<trulux> pitti: hey fellow
<daniels> pitti: yep, so we can demote that to universe soon, and then later demote xp when mozilla gets fixed
<lamont> Kamion: ok.  I'll make a note of that.
<lamont> infinity: <Kamion> lamont: Keybuk said that the s/linux/linux-gnu/ thing was inappropriate, and that we should be preferring DEB_HOST_ARCH_OS if available instead
<lamont> infinity: for when you do the samba merge
<Burgundavia> mjg59, that is the catch, as there is no easy solution
<kiko> yo hackers of the 21st century
<bob2> yo-yo, ki-ko
<daniels> wassup kiks
<pitti> hey kiko, how's going
<kiko> it's all cooking third-worldly
<kiko> enrico!
<enrico> hi!
<AndyFitz>   centreicq is so underrated
<seb128> elmo: tsclient sync
<elmo> seb128: done
<seb128> thanks
<Mithrandir> apt should accept comma separated lists on the command line.
<maswan> elmo: Hmm. We still occasionally fail the archive-sync, and this with a timeout on an rsync that has run for 15 minutes.
<maswan> elmo: isn't that a bit tight?
<elmo> maswan: the timeout's definitely set to 7200?
<elmo> I can do some tests, but I suspect it's not dropping on our end?
<maswan>  ftp-deb 41392 32062   0 14:32:06  pts/2  0:00 /usr/local/bin/rsync -rltv --timeout 7200 --exclude Packages* --exclude Sources* --exclude Release* --exclude Archive-Update-in-Progress-ftp.acc.umu.se se@syncproxy.ubuntu.com::ubuntu /export/ftp/mirror//ubuntu 
<maswan> that's the full command line that fails
<maswan> (well, some of the time)
<elmo> maswan: sorry, no, I mean it _is_ definitely 7200 on our end too
<lamont>   poxml: Depends: libqt3c102-mt (>= 3:3.3.3) but it is not installable
<maswan> ah, ok.
<lamont> poor d-i
<elmo> it's the same config + rsync as archive.u.c and I see long-running (days) rsyncs on that box
<maswan> this is quite odd then.
<ogra> AndyFitz, its perl, what do you expect ? ;)
<maswan> well, yeah, but the timeout doesn't trigger as long as both ends talk to eachother, even if it is slowly
<elmo> maswan: well, if you can reproduce it reliably I can, strace our end
<maswan> the issue here is that some of the time, the local file system traversal takes ~5 minutes, during which it times out.
<maswan> Hmm. Well, I can try.
<elmo> btw, according to the docs, our timeout setting overrides yours (as the client)
<maswan> Ah, ok.
<maswan> rsync: read error: Connection timed out
<maswan> rsync error: error in rsync protocol data stream (code 12) at io.c(162)
<maswan> rsync: connection unexpectedly closed (3609970 bytes read so far)
<maswan> rsync error: error in rsync protocol data stream (code 12) at io.c(150)
<maswan> that's the error message btw
* maswan runs off for a few minutes
<maswan> I'll see if I can make it reproducible
<elmo> I'm stracing the current rsync atm
<fabbione> Kamion: ping?
<maswan> hope it fails then. :)
<elmo> maswan: nah, it worked :(
<elmo> how often are you syncing?
<Lathiat> ] 
<Nafallo> elmo: 10 04,10,16,20
<elmo> OH, two part sync.  duh
<maswan> elmo: :/
<AndyFitz> breezy,  its so unstable its practically on par with my ex ;)
<doko> bug reports that the world needs:
<doko> #287539: [l10n]  Initial Czech translation of norwegian debconf messages
<\sh> ahahha
<Mithrandir> doko: :P
* daniels high-fives AndyFitz.
<\sh> Mithrandir: ping :) need debhelper ;)
<Nafallo> daniels: yay! latest xorg built on amd64 here :-).
<\sh> Mithrandir: forget it
<maswan> elmo: thing is, it works almost always when I run it manually. but for some reason, the cron:ed one breaks now and then.
<doko> Mithrandir: btw, should an aspell dictionary depend on libaspell or aspell-bin/aspell ?
<elmo> maswan: maybe strace on your end?  
<Mithrandir> doko: unsure.
<maswan> elmo: It just seems like it is hitting the timeout, but a 5 or 10 minute timeout, not the proper long one.
<pitti> cupsys_1.1.23-7ubuntu2_source.changes ACCEPTED -> bye bye, xpdf!
<lamont> Subject: Log for failed build of xorg_6.8.2-19 (dist=breezy)
* lamont pokes daniels
<fabbione> ahah i knew that!
<lamont> pitti: so what do I use to display pdf's on my screen then?
<Mithrandir> lamont: evince
<lamont> or is it just that cupsys used to use xpdf?
<fabbione> no wonder amd64 did succeed.. it was the only one tested
<lamont> Mithrandir: what an obvious name
<pitti> lamont: I converted cupsys to use libpoppler
<Amaranth> lamont: it's menu entry is "Evince Document Viewer"
<Amaranth> evince > * though, it's starting be turn into something like OS X's Preview
<lamont> Amaranth: there's a menu? :-)
<Mithrandir> lamont: beneath the pile of terminals.
<lamont> Mithrandir: nah - that's the desktop
<thom> why is it in GRAPHICS though?
<Amaranth> thom: good question
<Mithrandir> thom: it has a window => graphics, surely.
<thom> I WANT TO READ A DOCUMENT. GRAPHICS IS NOT THE OBVIOUS CHOICE
<lamont> thom: because it runs on a grahpics system?
<maswan> elmo: I'll try.
<Amaranth> thom: gpdf and iirc xpdf got put there too
<Mithrandir> thom: clickyclicky on the file itself, then?
<thom> Amaranth: they were in the wrong place, too
<thom> Mithrandir: *sssh*
<Burgundavia> thom, ggv is still there
<Amaranth> thom: not sure office would be better though, since it opens tiffs and such too
<kiko> Kamion, is the surak-call today?
<ogra> kiko, i was just about to ask
<fabbione> daniels, doko: you forgot to update the MANIFEST files....
<ogra> kiko, my evolution calendar thinks it 
<Xof> I hesitate to make this suggestion, but since evince is demonstrably both an image viewer and a piece of office software, why not give it entries in both menus?
<fabbione> daniels, doko: please do not forget sparc and hppa, kthxbye
<Burgundavia> Xof, that means two .desktop files and all the attendant fun, plus menu bloat
<daniels> fabbione: hm, I thought I did the MANIFESTs for everything
* daniels grunts.
<Amaranth> i see you guys have all these people making logos and mascots for breezy, how do i get in on the action? smeg could use some icon love :)
<Xof> Burgundavia: does that answer boil up to "our software doesn't let you do that at the moment, and it's a bad idea anyway because I believe everything in the world should fit in exactly one category"?
<fabbione> daniels: apparently not.. check the logs..
<Burgundavia> Xof, our software doesn't do it and it is a bad idea
* fabbione goes offline
<fabbione> bbl
<Xof> that's a shame
<Amaranth> Xof: More like "the standard doesn't allow that and it's a bad idea anyway because some apps would end up in every menu and look ridiculous"
<Nafallo> *hrm* nvu *hrm* ;-)
<Simira> Nafallo: did you say your gf wanted a gerbil? We've got one too much atm...
<Xof> OK, well, it's not my distribution: by all means do what you think is right -- but I can't honestly say that your answers have seemed to be any more than rationalization
<Burgundavia> Xof, there are good reasons why you don't want an app in multiple categories
<Xof> I believe you
<Kamion> fabbione: yo
<Kamion> kiko: erm, yes, probably, but I want mdz to be around if possible
<Nafallo> Simira: dunno. I could call her :-).
<Kamion> kiko: they seem to be reluctant to give me any contact details; I still don't have any e-mail addresses for them, despite asking for e-mails several times
<daniels> i guess naming a release 'what could possibly go wrong?' was just asking for trouble
<kiko> Kamion, let me sort that out.
<pitti> Kamion: a while ago we talked about dropping all packages from the seeds that are depended on by language-support-*
<pitti> Kamion: shall I do that now? IMHO it's a good time 
<Kamion> pitti: um, is that actually a good thing? I don't think so
<Kamion> pitti: I'd like to know exactly what would be removed rather than just saying "OK, let's nuke the lot"
<pitti> Kamion: essentially it's the whole "= Localisation =" paragraph
<pitti> (minus *-locales)
<Kamion> of which seed?
<pitti> breezy/supported
<Kamion> pitti: OK, although I think we should keep gettext-el there too
<pitti> Kamion: well, I don't _need_ to do that, we just discussed about this a while ago, and ISTR that you wanted to do that
<Kamion> I did? hmm, memory like a what's-its-name
<pitti> well, if you are unsure, we can leave it for now
<pitti> I would go through the whole list and drop everything that has a reverse dep to lang-supp-*
<pitti> so we would see which packages are not yet covered by langpacks
<pitti> ... but that is a good idea even if I don't commit the change
<Kamion> I'd be a little more cautious than that personally; there are things we explicitly want to have even though they happen to be currently depended upon by other things
<Kamion> the seeds are not meant to be leaf packages only
<Kamion> they're meant to be "stuff we want"
<pitti> right, the l-support pacakges are sort of a second kind of seed
<pitti> Kamion: so should we do it the other way round then? add everything to the seeds that is currently a dep of a langpack, but not yet seeded?
<Kamion> you're being too black-and-white
<Kamion> all I'm saying is that "already depended-upon by something else" is not sufficient reason to remove something from a seed
<pitti> yes, agreed
<Kamion> reason to remove something from a seed would be "we *only* need this because something else depends on it"
<Kamion> as in, if the other thing went away, we wouldn't need it any more
<pitti> well, the idea was to have the langpacks be the l10n seeds
<pitti> to avoid redundancy
<Kamion> I don't mind you removing the stuff you mentioned explicitly above, under Localisation
<pitti> this might be discussed on the ML or TB...
<Kamion> it just worries me when you say you're going to go through and REMOVE EVERYTHING :-)
<pitti> ugh, no
<pitti> basically the ooo-{help,l10n,...}-<lang> and similar packages
<Kamion> those should be fine, yes
<Kamion> I'm not sure I'm convinced yet by language packs as secondary seeds ...
<pitti> ok, then let's defer that until we discussed it at the ML?
<Kamion> how are the lists stored from which the langpacks are autogenerated?
<Kamion> sure
<Kamion> just trying to think of considerations for derivatives, etc.
<pitti> right now there is a langpack-o-matic subdirectory "support-depends" which has one file for each language
<Kamion> which essentially behave like seeds? so support-depends ~= seeds and language-pack-* ~= ubuntu-meta?
<pitti> yes
<pitti> I change support-depends/<Language> and call "./update-support"
<pitti> this 
<pitti> builds new l-support-<lang> packages
<seb128> pitti: well done for cups/poppler :)
<pitti> seb128: thanks :-)
<pitti> seb128: I wasn't aware of poppler, nice hint
<seb128> :)
<Kamion> fabbione: do you have that debootstrap/breezy.buildd diff handy?
<pitti> hey Mr. do"rebuild the world"ko :-)
<Treenaks> pitti: emerge world
<ogra> hehe
<pitti> I need some fresh air, see you later
<ogra> today he learns spelling ;)
<lamont> right.  honey-do's.  back in a while
<lamont> well, back in about 20 minutes for a couple minutes, then gone for 2-4 hours
<fabbione> Kamion: sorry, i was away.. i will need to retest it with the overall new crack, so just upload and i will do it with more quiteness.
<fabbione> Kamion: also.. can we start pre-seeding 2.6.12 into main?
<\sh> maswan: ping
<\sh> Mithrandir: ping 2 ;)
<Kamion> fabbione: I wouldn't bother with pre-seeding
<fabbione> Kamion: re-checking the diff now
<Kamion> just upload and shift to main when it's ready
<fabbione> Kamion: well we can shift to main anytime.. the kernel is there :)
<Kamion> I'm just about to upload debootstrap - it'll probably be broken on sparc because the required vs. base will be wrong, but that'll get sorted as soon as your builds come up to date
<fabbione> Kamion: i am testing the diff right now...
<Mithrandir> \sh: yes?
<fabbione> if you want to wait a couple of minutes..
<fabbione> otherwise go ahead and don't worry :)
<Kamion> fabbione: ok, I'll wait
<\sh> Mithrandir: see query :)
<Mithrandir> \sh: see query yourself. :P
<\sh> Mithrandir: hehe :) u need a build-dep bot ;)
<maswan> elmo: kread(3, " / 01 ", 4)                         Err#78 ETIMEDOUT
* Treenaks hugs seb128 for Subject: Accepted nautilus-open-terminal 0.2-1ubuntu1 (source)
<elmo> nobody    7497  0.0  0.6  16352 14376 ?        SNs  14:36   0:02  \_ rsync --daemon
<elmo> nobody    7708  0.8  0.7  16628 14624 ?        SNs  15:54   0:01  \_ rsync --daemon
<elmo> those are both you ..
<elmo> and the first one is just waiting on my side
<fabbione> Kamion: http://people.ubuntu.com/~fabbione/buildd.diff
<fabbione> Kamion: it works fine on both i386 and sparc
<fabbione> we get rid of some gcc-3.3 stuff
<ubuntu> hi
<ubuntu> someone using ubuntu in ppc?
<ubuntu> root@ubuntu:/# ybin
<ubuntu> Failed to initialize HFS working directories: No such file or directory
<ubuntu> ybin: /dev/hda5 appears to have never had a bootstrap installed, please run mkofboot
<ubuntu> I have this error when I try to install yaboot
<thom> ubuntu: users questions in #ubuntu please
<ubuntu> is not a questions
<ubuntu> is a bug
<ubuntu> xD
<thom> no, it's not
<fabbione> ubuntu: this channel is "There is a bug and this is the fix"
<ubuntu> ok
* lamont gets ready to run away
<ogra> run lamont, run (nad have fun)
<ogra> and even
<lamont> heh
<lamont> later all
<toresbe> http://homepage.eircom.net/~wastedyouth/gnu.jpg  :D
<ogra> WOW
<ogra> ogra@honk:~ $ sudo cfdisk
<ogra> Segmentation fault
<Treenaks> nice
<dilinger> is that sudo or cfdisk that's segfaulting?
<ogra> cfdisk... sudo works with other apps
<mvo> is muine broken in breezy right now?
<ogra> mvo, might be... tseng is holding back some stuff...
<elmo> heh, a broken sudo would have interesting consequences
<fabbione> ogra, amu: ping?
<fabbione> it's cfdisk
<ogra> fabbione, can we start testing finally.,...
<ghpolo> im too scared to do this last dist-upgrade ;o
<fabbione> ogra: i added a test case for OCFS2 in ClusterFileSystem
<fabbione> ogra: the kernel is in the buildd now.
<ogra> oki
<fabbione> the tools are in universe
<ogra> oki
<fabbione> well the kernel is too :)
<fabbione> and i am off for a while.. i might pass by later
<ogra> no problem, i already run the last version...
<fabbione> ogra: no no.. you need the one that is building now
<ogra> fabbione, i know... 
<fabbione> because in the previous version there is no OCFS2
<fabbione> ok
<fabbione> 2.6.11.92-1.3/ to be exact
<Kamion> fabbione: all uploaded
<fabbione> Kamion: thanks a lot :)
<fabbione> the new buildd chroots will show how is still abusing gcc-3.3 without declaring a direct b-d
<fabbione> unfortunatly dpkg still needs libstdc5
<fabbione> otherwise we could have killed gcc-3.3-base too
<fabbione> well.. at the next round :)
* fabbione goes offline again
<Kamion> haven't you rebuilt dpkg yet?
<Kamion> new dpkg shouldn't ...
<Burgundavia> seb128, can you take a look at https://bugzilla.ubuntu.com/show_bug.cgi?id=11126 ?
<Burgundavia> I suspect user error
<elmo> Kamion: do you know why /etc/network/interfaces no longer auto eth0's ?
<elmo> in hoary installs
<opi> elmo: hotplug is rising it?
<elmo> opi: yeah, not so much on a non-modular kernel
<opi> elmo: I was wondering that myself :-)
<eruin> where would I file a bug agains this? after installing and selecting norwegian bokmaal all the way, this is my language var: LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en_GB:en   - I just don't get why danish and swedish is added in that mix - makes no sense at all
<opi> elmo: like mine :->
<Kamion> elmo: netcfg only sets that up if the installer detected eth0
<Kamion> er ... and if it's not hotpluggable, apparently
<Kamion>         if (!iface_is_hotpluggable(iface) && !find_in_stab(iface))
<Kamion>             fprintf(fp, "auto %s\n", iface);
<elmo> Kamion: right, but warty put the auto eth0 unconditionally
<opi> at installation process?
<elmo> which is kind of nice, given that if you switch to a non-modular kernel, you end up without a network interface
<opi> what if I put a card that will not be modprobed by hotplug?
<elmo> opi: that would be !iface_is_hotpluggable
<opi> elmo: that's why I've been asking it this code snip is a procedure from installation or every boot proecss
<Kamion>   * Per Olofsson
<Kamion>     - Check for hotpluggable (PCMCIA) network interfaces in
<Kamion>       /etc/network/devhotplug and don't generate auto entries for them.
<Kamion>       Also put them in a "mapping hotplug" stanza. Closes: #239284.
<Kamion>  -- Joshua Kwan <joshk@triplehelix.org>  Sun, 11 Apr 2004 22:55:40 -0700
<Kamion> opi: installer
<Kamion> elmo: that change was considerably before warty - only thing I can think of is that the installer has suddenly worked out your interface is hotpluggable
<elmo> cock
<pitti> hehe
<pitti> http://www.nsa.gov/notices/notic00003.cfm?Address=%22%3E%3Cscript%3Ealert(%22We%20love%20our%20XSS%22)%3C/script%3E
<pitti> so far with "security"
<pitti> ;-)
<Kamion> but sounds like it's some evil PCMCIA thing, which I try not to touch
<Kamion> why does breezy's bash spin on waitpid() whenever a process exits?
* Kamion upgrades libc6 to see if he can make his chroot usable again
<Kamion> 11411 exit_group(0)                     = ?
<Kamion> 11408 <... waitpid resumed> 0x7ffff188, WUNTRACED|0x8) = -1 EINVAL (Invalid argu
<Kamion> ment)
<Kamion> ... and then it just spins ...
<mdz> morning
<mdz> kiko-fud: what time is the call?
<fabbione> morning mdz
<mvo> good morning mdz 
<pitti> Hi mdz
<seb128> hi mdz
<zul> hey mdz
<ogra> mdz, we said 13:00 utc in #ubuntu-meeting last time we met ....
<mdz> ogra: who said 13:00 utc in #ubuntu-meeting for what meeting?
<Kamion> uh, we did?
<Kamion> oh, damn, we did
<ogra> mdz, when kiko, Kaimon, me and the brazilians had the last UbuntuExpress meeting
* Kamion notes continued lack of phone number to call, anyway ;-)
<ogra> Kamion, did we say a conference call ? i noted #ubuntu-meeting
<mdz> ogra: I see
<Kamion> 14:22 < kiko> Kamion: I would suggest setting up a weekly phone call with surak to checkpoint on how it's going
<ogra> Kamion, ah...
<ogra> ok, i missed that then...
<Kamion> sorry, I suck at this management lark
<ogra> heh... but at least you remembered the phone call... i only relied on evolutions calendar :)
* Keybuk has tried management twice now, you'd think I would've learned from the first time
<ogra> heh, did you learn it the second time ?
<Keybuk> I think so :)
<fabbione> ogra: ppc and i386 kernel have been built finally
<ogra> yay...
<fabbione> i guess they will hit the archive at the next daily
* ogra upgrades the i386 ....
<jdub> gotta watch out for those barzilians
<fabbione> ogra: "next daily" is in 20 minutes ~
<rburton> so, hoary claims to support the dlink dwl-g650+ card but mine is clearly Not Working.
<ogra> fabbione, yep
<Kamion> fabbione: so should I switch d-i over?
<fabbione> Kamion: not yet. from the next upload.
<Kamion> i.e. are you going to have this moved to main?
<fabbione> Kamion: yes i would like to have it moved to main from now
<ogra> jdub, *g*
<fabbione> Kamion: 1.4 will get d-i love and then we can switch
<fabbione> but notice that there will be no restricted modules until 2.6.12 is final from upstream
<fabbione> and that we are not respecting abi changes yet
<fabbione> otherwise we will land with 12 final -3874.1
<Kamion> in that case I'll wait for final for d-i
<fabbione> works for me
<fabbione> it shouldn't be too far eithery
<fabbione> s/y$//
<fabbione> anyway.. dinner time
<fabbione> Kamion: do we still need to seed the kernel to get it in main? or is it enough to ask elmo now?
* fabbione will read the answer later
<Kamion> fabbione: seed
<fabbione> ok
<Kamion> fabbione: until such time as linux-meta starts depending on it
<Kamion> ... stick it in supported
<fabbione> Kamion: ok thanks
<fabbione> Kamion: the seed archive is still on chinstrap?
<fabbione> never mind.. it's only slow to death :)
<kiko-fud> mdz, I can't really recall. let me get hold of surak
<seb128> Burgundavia: you should ask how he installed the distro
<Burgundavia> seb128, that was my next guess
<seb128> maybe he upgraded from Debian or used the custom install
<seb128> which could give that, a root account and his user not configured correctly
<Kamion> custom/server install doesn't do that, although there are other methods that could
<seb128> which ones?
<Kamion> seb128: expert mode
<seb128> oh, I thought server was an alias to this one
<seb128> k, maybe the guy used that
<kiko-fud> Kamion, surak called and said their network is down but he will email you guys with phone numbers and email addresses
<Kamion> kiko-fud: thanks
<Burgundavia> Kamion, so the installer has 3 modes? normal, server and expert?
<Nafallo> Burgundavia: four. server-expert also :-)
<Burgundavia> ick
<Burgundavia> people seem to like choosing expert for some reason
<Burgundavia> validates them
* Nafallo chooses expert quite alot ;-)
<Nafallo> s/alot/often/
* Burgundavia trusts that Nafallo knows what he is doing
<Nafallo> hehe, just when I got doubtful about that ;-)
<Kamion> expert's for use when an installer developer tells you to use it. :-)
<Nafallo> Kamion: ... or for us controlfreaks that love servers? ;-)
<Kamion> you don't need to use expert mode to install a server
<jdub> expert mode is pants
<Kamion> you need to use expert mode when the installer's going insane and you have a developer with you to hold your hand
<jdub> all the cool kids *aren't* doing it ;-)
<Nafallo> I don't need to do it; but I'm still a controlfreak. and expert gives you lot more control :-).
<ogra> the cool kids use a magnetic pen to transfer the installation to disk ;)
<Kamion> and expert has a lot of bugs that I pay no attention to because they don't matter enough
<Kamion> generally duplicate questions and such
<Kamion> but it's possible that there's actually different default behaviour (not *too* likely because of how debconf works, but possible)
<Nafallo> Kamion: hmm, I haven't had any errors yet :-).
<Nafallo> hmm, time to try xorg=6.8.2-20 ;-)
<cartman> latest X.org (-20) works for anyone?
<tseng|work> support in #ubuntu
<tseng|work> and yes, Xorg breaks in major transitions
<cartman> uhn ok majorly borked
<ogra> yeah, isnt it great.... you actually *feel* the development going on :)
<jdub> ogra: have you read any of the ipodlinux stuff?
<jdub> ogra: they have some very interesting data transfer methods :)
* jdub goes to see if he can get some sleep again
<ogra> jdub, in -users ?
<jdub> ogra: no, the project porting linux to the ipod
<ogra> or is there a distro i'm not yet aware of ?
<ogra> wow, nope, not yet
* ogra goes lookin....
<\sh> ipod linux?
<ogra> jdub, GO to BED ! dont make pia unhappy....
<trukulo> jdub, good night man
<tseng|work> bye jdub
<shaya> is X safe again? :)
<\sh> i think daniels uploaded -18 and went to bed ;)
<Kamion> I'm off out for a bit; should be back before tonight's round of meetings start, though.
<Burgundavia> -20 is the latest
<shaya> I see -20
<Kamion> (failing that I have my mobile phone with me)
<\sh> oh i was asleep as well
<Burgundavia> -20 doesn't fix the fonts issue yet
<shaya> hmm
<Burgundavia> but it or an eariler release fixes the binary symlink issue
<\sh> is lubglu1-xorg and libglu-dev-xorg fixed?
<\sh> the deps?
<doko> \sh, yes gl is fixed
* shaya holds off for now
<shaya> already downgraded to hoary X once
<dholbach> hellas!
<pitti> Hey dholbach 
<dholbach> hey pitti :-)
<\sh> doko: wonderfull..so I can work on arkrpg
<thom> doko: mozilla on ia64 seems to build ok with gcc-3.4; take it reverting to that isn't an issue?
<Treenaks> pitti: ping?
* pitti waves
<doko> thom: no, I don't think so. but we should revert for ia64 only
<Treenaks> pitti: should serial devices show up in the HAL device tree?
<Treenaks> pitti: because they aren't
<Treenaks> pitti: (/dev/ttySxx)
<pitti> Treenaks: no idea, I don't have some
<Treenaks> pitti: not even empty ports?
<pitti> I guess hal works for you now?
<Treenaks> pitti: yes, it stopped crashing
<pitti> Treenaks: well, I have two serial ports in hal
<Treenaks> hm wait..
<pitti> Treenaks: I have a "16550A compatible COM port" with info.category == serial+
<Treenaks> *headdesk*
<pitti> and linux.device_file == /dev/ttyS1
<Treenaks> sorry.. I just upgraded.. new kernel.. need to reboot first
<pitti> hehe
<Treenaks> 2.6.12.. unstable abi.. *grr* :)
<Treenaks> brb
<mdz> mjg59: ping?
<mdz> (re: merging the hp stuff)
<thom> doko: indeed
<Treenaks> pitti: it works..
<Treenaks> pitti: it looks ugly, but it works :)
<pitti> Treenaks: define ugly?
<Treenaks> pitti: screenshot coming up
<Treenaks> pitti: http://foodfight.org/zut/Screenshot.png
<Nafallo> newest Xorg didn't like me :-P
<pitti> Treenaks: erm, what's wrong with this pic? I thought you would send me a hal-device-manager shot.. :-)
<Treenaks> pitti: hey!
<Treenaks> pitti: uh
<Treenaks> wait....
<cartman> Nafallo: it doesn't love anyone but daniels 
<Nafallo> cartman: hehe, true true ;-)
<Treenaks> pitti: reload
<cartman> Nafallo: were you able to start it at least? :)
<cartman> Nafallo: xinit was sitting here
<Nafallo> cartman: downgraded to hoary's xorg ;-)
<cartman> ah -16 worked for me :-)
<Nafallo> cartman: the damn thing had forgot my xorg.conf so I had to regenerate it.
<cartman> Nafallo: ugh :/
<pitti> Treenaks: uh, so that's where the empty string was...
<cartman> as bad as me installing nvidia drivers everytime Xorg updates :)
<cartman> to fix GL libs
<Treenaks> pitti: yes
<Treenaks> pitti: product info contains "CF CARD" "GENERIC", and 2 empty strings (it's a CF GPS in a CF-to-PCMCIA convertor)
<Treenaks> and it has 2 serial port.. one which uses \r\n, the other only \n ... for THE SAME DATA
<Treenaks> *headdesk*
<Nafallo> cartman: well, when we have -21 I probably upgrade again ;-)
<cartman> Nafallo: ah no way
<cartman> I won't be fooled this time :)
<cartman> xkb still borked already :/
<Nafallo> something does _not_ look as it should.
<doko> Kamion, lamont: in debootstrap, libgcc2 should be added for hppa
* lamont asserts that Kamion will remember that
<lamont> :-)
<lamont> mdz/Kamion/whoever: next time someone uploads ubuntu-meta, please add hppa to the list of architectures from ports.ubuntu.com.  kthxbye
<lamont> (eventually, it'll be far enough along with ubuntu-desktop to make it worth actually adding on its own, but would be nice to get it automated early
<thom> lamont: does firefox install now on hppa?
<mdz> jdub: have you worked out the schedule for gnome 2.12 yet?
<Riddell> wouldn't it just be a copy the 2.8 schedule with the year bumped?
<ogra> Riddell, thats not KDE ;)
<Riddell> ogra: KDE doesn't have schedules, it's just released when we get good vibes
<ogra> hmm, not very reliable....
<Burgundavia> as a second to the time based one, I like inkscapes feature based one
<AFK-Wolf> Guys, I just cleanly closed down ubuntu hoary, rebooted, and now I can't mount my / partition, grub error 17
<HiddenWolf> can anyone give me any pionters on what the F is going on?
<Burgundavia> HiddenWolf, this channel is for when you find a fix for it, #ubuntu is for finding that fix
<HiddenWolf> Burgundavia, Give me any clue on what the F could have gone wrong, and I'll happily file the bug
<opi> test installation of breezy in VMWare hurst :(
<lamont> thom: dunno yet
<lamont> it built
<lamont> Setting up firefox (1.0.4-1ubuntu2) ...
<lamont> Updating mozilla-firefox chrome registry...E: Registration process existed with status: 1
<lamont> E: /usr/lib/mozilla-firefox/extensions/installed-extensions.txt still present. Registration might
<lamont> +have gone wrong.
<lamont> mv: cannot stat `/usr/lib/mozilla-firefox/defaults.ini': No such file or directory
<lamont> dpkg: error processing firefox (--configure):
<lamont>  subprocess post-installation script returned error exit status 1
<lamont> uh, no.
<shaya> anyone running 2.6.10-5-686 here?
<lamont> or could a corrupt chroot cause that?  that is, do I need to start with something pristene
<lamont> ?
<shaya> I think the kernel headers are broken
<shaya> include/linux/version.h has #define UTS_RELEASE "2.6.10"
<shaya> which is wrong
<shaya> should be #define UTS_RELEASE "2.6.10-5-686"
<lamont> really?
<shaya> vmware refuses to compile b/c of that
<fabbione> shaya: holdon
<lamont> vmware built for me just fine
<lamont> do you have linux-headers-2.6.10-5-686 installed/
<fabbione> #define UTS_RELEASE "2.6.10-5-686"
<\sh> Riddell: are u having sometimes hickups with amarok?
<fabbione> no the headers are fine
<fabbione> you are pointing to the wrong header directory
<shaya> root@dent:/lib/modules/2.6.10-5-686/build/include/linux # dpkg --status linux-headers-2.6.10-5-686 |grep Installed
<shaya> Installed-Size: 17604
<Riddell> \sh: not on hoary
<Riddell> \sh: which engine?
<shaya> Version: 2.6.10-34
<\sh> Riddell: some mp3s are bugging amarok...it stops responding..but no crash
<shaya> fabbione: eh?
<fabbione> shaya: /usr/src/linux-headers-2.6.10-5-686/include/linux/version.h says otherwise
<thom> lamont: no, unlikely to be a corrupt chroot, sadly
<\sh> Riddell: arts
<lamont> thom: bummer.
<thom> lamont: oh well
<\sh> Riddell: but xmms is running fine
<lamont> fix that? kthxbye.
<fabbione> shaya: #define UTS_RELEASE "2.6.10-5-686"
<Riddell> \sh: try installing akode-mpeg from universe or use the amarok-xine engine
<shaya> fabbione: I edited it to that
<shaya> and it works
<shaya> got vmware built
<fabbione> shaya: that is out of a default install
<\sh> riddell: i will try...
<shaya> ?
<shaya> should UTS_RELEASE and uname -r be the same thing?
<fabbione> shaya: apt-get install linux-headers-2.6.10-1-686
<lamont> more /lib/modules/2.6.10-5-686/build/include/linux/version.h 
<lamont> #define UTS_RELEASE "2.6.10-5-686"
<lamont> and are
<lamont> shaya: of course, this is really a #ubuntu question....
<shaya> shrug, dont know why mine is screwed up
<shaya> broken header package is #ubuntu?
<lamont> shaya: did you pull headers from /usr/src. or from /lib/modules?
<shaya> I already built vmware
<shaya> /lib/modules
<fabbione> lamont: the one from /lib/modules are a symlink to /usr/src
<lamont> (this would be the channel to discuss your patch to fix the bug...)
<shaya> reinstalling
<shaya> I said how I fixed it
<shaya> <shaya> should be #define UTS_RELEASE "2.6.10-5-686"
<lamont> fabbione: why so it is...
<lamont> shaya: and it is that in the package\
<lamont> that is, there's no bug'
<shaya> not in what I had installed
<shaya> reinstalling and seeing what happened
<shaya> hmm
<shaya> reinstalled version is correct
<fabbione> lamont: UTS "2.6.10" doesn't appeare anywhere
<shaya> very very weird
<fabbione> the minitmum is 2.6.10-5
<shaya> sorry
<fabbione> from generic headers
<shaya> very very weird
<lamont> shaya: np
<fabbione> down to 2.6.10-5-$flavour
<shaya> Q
<shaya> why is EXTRAVERSION in the Makefile not set?
<lamont> shaya: because that's done in the build rules
<JaneW> REMINDER: there's a spec tech board meeting starting on the hour - 20:00 UTC in #ubuntu-meeting
<JaneW> s/spec/special
<shaya> I guess modules are still installed in correct place, so not a big deal
<mdz> tech board meeting on #ubuntu-meeting in ~10m
<camilotelles>  /join #ubuntu-meeting
<zul> uh not exactly
<lamont> Kamion: I think palo will need partman-palo added to the installer seed as well.... thoughts?
<Kamion> lamont: quite right, done
<lamont> daniels: xscreensaver looks to be a dpkg-victim, maybe.
<lamont> checking for X11/extensions/XScreenSaver.h... no
<lamont> maybe not.
<fabbione> lamont: wrong build-deps mostlikely
<Kamion> libxss-dev
<Kamion> or perhaps include path
<Kamion> doesn't build-dep on libxss-dev; I'm surprised that wasn't caught in hoary
<kiko> surak!
<surak> kiko!
<surak> watching what's going on at #ubuntu-meeting
<Nafallo> surak: TB :-)
<surak> yup :-)
<kiko> how's it going up north, surak?
<surak> much better today! I'm just testing it to not be embarrassed in front of all because something I forgot :-D
<surak> kiko: do you have a spare machine to try the installer? one which the hard drive contents are not important?
<kiko> surak, hummm. hmmmmm.
<surak> something to screw on? :-)
<kiko> surak, I could set one up, but that's a bit of extra work for me -- you guys don't have test boxes there?
<surak> I suppose it can work in a virtual machine, as long as the virtual machine hard drive can be 'safely' destroyed
<kiko> it can always be safely destroyed.
<surak> we do
<kiko> I have a P233 we could test on, problem is finding an intern willing to do it :)
<surak> I'm already testing it on two of them
<kiko> how's it looking?
<surak> Currently it just screws the partition, unless they are windows (then I resize them)
<Kamion> I just committed auto-resize code to partman-auto today
<Kamion> ideally you guys would be using that
<surak> hum
<surak> Ill change it then
<Kamion> figuring out how to use partman(-auto) code will be a reasonably-sized chunk of work though
<siretart> Keybuk: I read that you are the guy who wrote MoM (merge o matic). It rocks. I wanted to have a closer look for a few local packages in a custom installation. Is the source for it available somewhere?
<Keybuk> no, it uses a lot of code that we're planning to open source as part of the HCT project
<Keybuk> so today it isn't available, but it will be eventually
<seb128> Keybuk: speaking about HCT ... gdm?
<siretart> ah. ok. but, whats HCT?
<Keybuk> seb128: am preparing a release today/tomorrow :)
<seb128> cool
<Keybuk> siretart: a tool to manage source packages in revision control
<seb128> I'm waiting on it to work on gdm ... :)
<siretart> Keybuk: woah. sounds great!
<surak> last testing, so I can show the script.
<srbaker> how do i ask dpkg what package owns /usr/lib/libGL.so ?
<srbaker> i forget
<Keybuk> srbaker: dpkg -S
<srbaker> that,s i kept trying dpkg -L
<Keybuk> siretart: and, to be honest, is isn't that hi-tech; it basically downloads three packages and does some diff/patch to make a fourth
<siretart> Keybuk: jupp. but the output is nice, and I don't want to reinvent the wheel ;)
<kiko> surak, woo woo
<surak> kiko: Let me finish the grub process and I'll paste the partition destructor over here :-)
<surak> hum... I wrote something in portuguese. bad bad bad.
* ogra hopes surak thinks about renaming that part 
<ogra> :)
<ogra> but at least some cool icons come to my mind for that name :)
<surak>  /s/destructor/ubuntu-express-installer :-)
<ogra> hehe
<kiko> partition destroyer, hmm, has an interesting ring
<mdz> mvo: ping?
<mvo> mdz: pong
<kiko> mdz!
<mdz> mvo: what patchlevel should I merge to get the current apt in breezy?
<mvo> mdz: just get all of apt--fixes--0
<kiko> mvo, did you reach closure on the directory output crud?
<mvo> kiko: mdz is the last authority here :)
<srbaker> ubuntu-express-installer?  what's that/
<dholbach> http://udu.wiki.ubuntu.com/UbuntuExpress iirc :-)
<surak> its your personal partition destructor :-D
<srbaker> huh.
<srbaker> *my* personal partition destructor comes in a twelve pack of bottles
<surak> will, it's being my one for a week now..
<ogra> surak, i'll take over after you destroyed all your disks then ;) to make a nice ui
<surak> the damage is much more recoverable whan a 12-pack :-) as least in my test machines
<mdz> mvo: ok. also, will the apt transition be completed today?
<mdz> kiko!
<mdz> mvo: I can't seem to get all of apt/synaptic/aptitude/etc. upgraded together
<mdz> aptitude still depends on libsigc++-1.2-5c102
<surak>  /s/whan/than
<mdz> mvo: that's otavio's apt--fixes, or yours?
<ogra> Kamion, ping ?
<mvo> mdz: my fixes branch
<mvo> mdz: I carefully picked the good bits out of otavios branch, not all of it was ready
<mvo> mdz: aptitude upgrade seems to work for me, I get 0.2.15.9ubuntu4, what's your version?
<surak> something I was to ask for days: should a user be created or the ubuntu one is fine?
<Kamion> ogra: pong
<Kamion> surak: ubuntu user should be removed and a new one created with proper name and password
<ogra> Kamion, seed change for mono ? do we have to upload again for that ?
<Kamion> the installer has code to do the latter
<Kamion> ogra: no, you don't need to upload
<ogra> great
<Kamion> lamont: (xlibmesa-glu-* shows up in rene's partial NBS list)
<Kamion> ogra: what packages need to be seeded into main?
<ogra> Kamion, we are still discussing the apps, but for now mono and gtk-sharp are a go....
<ogra> tseng, ping
<tseng> ogra: pong.
<tseng>  + monodoc
<ogra> ah, yes....
<tseng> that will be pulled in as a gtk-sharp dep possibly
<ogra> tseng, anything we additionally need for dbus ?
<tseng> i havent really read up on the seeds
<ogra> oh, gecko-sharp for aure
<ogra> sure
<tseng> ogra: no we need mono-in-main
<tseng> yes
<tseng> we can ignore gtksourceview-sharp1 i think
<tseng> since no one is using it afaik
<ogra> yep
<Kamion> don't think about it too hard, just list the packages you want and don't worry about dependencies in general
<Kamion> as in the top-level packages
<ogra> Kamion, i'll mail you a list then
<robertj> if mono geos in main, does beagle as well?
<ogra> yep
<tseng> robertj: we will see what 0.0.10 looks like
<ogra> and probably some other mono apps
<Kamion> robertj: not automatically, but it's a major part of the rationale for mono-in-main
<tseng> i am confident it will be alot more sane
<tseng> and I can propose for main at that time
<tseng> im not comfortable with the dbus version as it stands
<tseng> all indications are beagle will be much more stable soon.
<robertj> why not stick in the dbus and then drop out in a month if things are looking bad?
<robertj> err dbus version
<ogra> robertj, because half of our system depends on dbus
<tseng> heh yes :)
<ogra> at least on the desktop
<robertj> ogra: but dbus doesn't die a horrible death if beagle misbehaves does it?
<ogra> robertj, nope, but we cant just juggle with the versions here.... even with mono in main goes a bigger responsibility then in universe
<tarvid> my 3c556b card throws vortex_probe1 fails. Returns -22. Any hope of debugging that?
<ogra> since it has to be supportable for 18 months
<surak> Kamion: I need now to worry with what happens after the machine boots - everything is borked.
<robertj> ogra: yes, but what I'm saying is that if it goes in now, and we have to revert to fam in a month, that should still leave plenty of time for things to fall into place, no?
<kiko> mdz, when will you have time to give me a ring? :)
<ogra> robertj, fam ?
<tseng> jdub: new gamin, dude.
<ogra> robertj, fam is dead since hoary....
<Kamion> surak: need a bit more detail to help :-)
<robertj> ogra: errr, fam++
<robertj> inotify
<ogra> robertj, even inotify is fine....
<ogra> no need to worry about that....
<tseng> inotify is fine in breezy
<ogra> kiko, you want to marry ?
<robertj> and beagle does play nice with just inotify now?
<ogra> yep
<robertj> so why not have that as the fallback position, try for something a bit more aggresive, and bail out in a set timeframe if its a no-go
<tseng> we need to update gamin first
<tseng> before even talking about it.
<tseng> the gamin inotify backend in the current ubuntuized package is pretty suck
<tseng> the new one is much improved
<robertj> (speaking of suck...I got Tiger today and Spotlight is kinda sucky as well)
<tseng> i would be comfortable proposing turning inotify back on for breezy once we get that in..
<tseng> really up to kernel team
<robertj> Technically it's fine but it doesn't query any non-local backends for the address book and that sort of thing
<Kamion> I thought inotify'd already been turned back on in the 2.6.12 kernel packages
<Kamion> ?
<ogra> yep it has
<tseng> i didnt notice that in the changelogs, but its quite possible
<zul> Kamion: it has
<tseng> hm great.
<srbaker> whoa.  joey's a little bitter today.
<JaneW> quick question and please don;t point me to #ubuntu but if I set my laptop to hibernate in ubuntu, when I restart must I use the normal boot up or recovery mode?
<elmo> JaneW: #ubuntu
<surak> :-)
<tseng> elmo: cold.
<Kamion> JaneW: normal
<elmo> janew: [you realise I stopped reading after "don't point me to #ubuntu right? :-P] 
<Kamion> recovery mode basically just boots into single-user mode
<JaneW> elmo: knew you would, it was  decoy :P
<JaneW> ok, think is I never get out of hibernate mode smoothly, and certainly not if I change networks in between...
<JaneW> s/think/thing
<mako> community council meeting in a few minutes in #ubuntu-meeting
* Simira just got her cupoftea
#ubuntu-devel 2005-06-01
<surak> Kiko! It copied everything correctly, installed grub! huhu! (I'll not tell you now that it panics right after the boot. I'll correct it first)
<surak> Kamion: it works!
<Kamion> hoorah
<kiko> heh
<kiko> <ogra> kiko, you want to marry ?
<kiko> LOL
<\sh> *gggg*
<ogra> *g*
<Simira> *g*
<surak> ?
<\sh> I will marry ogra ,)
<Simira> kiko: did you say yes? When's the occasion?
<ogra> surak, <kiko> mdz, when will you have time to give me a ring? :)
<kiko> please send me the wedding gifts
<surak> time==money
<ogra> in advance indeed ;)
<mdz> kiko: how about now?
<surak> money=0
<mdz> kiko: do we have some sort of conference capability?
<kiko> mdz, hmmm, only if we set it up in advance, there's some sort of dial-in we can use in the UK
<kiko> mdz, I was going to suggest either Kamion call surak directly (it's getting late) or you did it, but I wanted to talk to you about other stuff as well.
<Kamion> I'm in the community council meeting now, and getting pretty tired
<mdz> kiko: probably you and I should have a call, and Kamion and surak can do the same at a later time
<ogra> and it doesnt look like a >2h meeting
<kiko> Kamion, do you want me to try and get some magic codez for conference calling? the downside is that then surak needs to dial into the UK himself.
<ogra> err <2h
<Kamion> kiko: if it's only one-to-one, I'm happy to expense a call to Brazil ;)
<Kamion> but I'd like to have the facility to do confcalls
<kiko> so would I, but it doesn't help much for non-canonicals
<mdz> the long-term solution is voip
<kiko> Kamion, just do a one-on-one call. 
<mdz> that makes the most sense
<kiko> yeah, but shtoom is quite borked for me right now.
<mdz> and gives us more scheduling freedom
<mdz> two 1-1 calls rather than a 4-way
<kiko> yeah
<kiko> mdz, so ring me whenever.
<kiko> mdz, if you wanna call in 2h it is also good, I'll have finished my reviews.
<surak> Kamion: ping
<Kamion> surak: here, although still in the meeting so only half paying attention
<surak> Just let me ask you to grab the latest version of the script at the site I gave you - I'm correcting it now, ok?
<surak> When you test it.
<Kamion> surak: grabbed, thanks
<Kamion> surak: won't work though, the script you create isn't executable
<surak> ?
<Kamion> +cat <<EOF >$TR/tmp/initrd-create
<surak> duh
<Kamion> that'll be 644 by default, and there's no chmod
<surak> just did it
<Kamion> why do you need a helper script anyway? just chroot and run the commands you need to run
<Kamion> i.e. chroot /target dpkg-reconfigure ...
<surak> aint I allowed to run only one command after chroot?
<Kamion> surak: sure, but you can always chroot multiple times
<Kamion> neater than helper scripts :)
<Kamion> and 'uname -r' doesn't have to be run in the chroot, so we're only talking two commands here
<surak> yes
<surak> I was afraid that udev would loose its devices inside the chroot after I leave it
<trulux> ajmitch: I'm sorry on the flood I did while wget'ing your repo from helium machine
<trulux> ajmitch: it's downstream and upstream is kinda huge :D
<Kamion> surak: no, why would it?
<Kamion> surak: remember the udevstart process is exiting anyway
<Kamion> and it couldn't care less whether you chrooted to run it or not :)
<surak> my fault
<Kamion> no problem, udev is complex
<ajmitch> trulux: iptables helped
<ajmitch> trulux: the main problem is that you didn't use wget properly :)
<ajmitch> and it would have grabbed all the ubuntu packages I've built or am working on..
<trulux> ajmitch: it was way *too* late here
<trulux> ajmitch: ie. I'm on 4 Red Bulls tonight
<Mithrandir> did whoever updated libstlport4.6 also intend to port ooo to gcc4?
<trulux> ajmitch: I can hear my hearth
<ajmitch> trulux: heh, that means you haven't had enough yet
<surak> trulux: 4 red bulls would keep me awake for a week kicking walls over the town
<trulux> ajmitch: helps to keep migrains out of the business but harms a bit after you get asleep
<ajmitch> once it settles into a quiet, quivering mess.. then you've had enough 
<trulux> ajmitch, surak: I'm doing stuff in a rush, no kidding.
* trulux on steroids
<trulux> ;P
<trulux> pitti: solar (gentoo dev) pointed me at this one (I missed it):  http://www.ida.liu.se/~johwi/research_publications/paper_ndss2003_john_wilander.pdf
<trulux> surak: the record is sleeping 3 hours in a week in the past Xmas holidays. I could say that I learnt the basics on kernel hacking that times
<trulux> surak: in short, this year I got hardcore
<surak> My record is 63 hours working on a congress
<JaneW> surak: I would need something strong than red bull!
<JaneW> stronger
<surak> I was so tired I left to my house on foot - forgot my car over there.
<Burgundavia> JaneW, what is the status of edubuntu?
<ajmitch> surak: I don't think it would have been safe to drive
<surak> ajmitch: indeed
<surak> it would be some sort of real-world carmageddon
<jsgotangco> id like a redbull now
<JaneW> Burgundavia: still pretty mcuh stalled actaully, but hopefully there will be some movement soon.
<Burgundavia> ok
<jsgotangco> JaneW, sent Jeff (Elkner) and email regarding that, hopefully, he'll reply later
<JaneW> jsgotangco: I think I'll pass and opt for bed instead
<jsgotangco> JaneW, let me guess, dawn already in cape town?
<trulux> JaneW: japanese red bull is stronger than our one
<JaneW> jsgotangco: cool thanks, I got some mails from flint earlier, looks like he is russling it up a bit
<JaneW> jsgotangco: no it;s almost 1am
<trulux> JaneW: though, that's categorized as "Drugs" and you would start chulcking like a chicken on a table and feeling like Alice in Wonderland
<jsgotangco> gyahh thats not so bad
<jsgotangco> (unlike waking up at 5am)
<JaneW> trulux: I have had a thai version, really cheap and in a medicine bottle
<surak> wow
<JaneW> jsgotangco: I agree, that's worse ;)
<JaneW> trulux: I drank Thai redbull when I had my tattoo done ;)
<jsgotangco> i didnt see your tatoo
<JaneW> jsgotangco: It was visible some of the time... it's on my RHS shoulder/back
* Burgundavia adds channel +skin
<JaneW> heh
<trulux> JaneW: I buy them for 1.50 in the Chinese shop near my house, and well, I spend *lots* of money on buying energy drinks and the like
<jsgotangco> trulux, you should try the original named "Lipovitan"
<ajmitch> trulux: yeah, I've been spending a bit on that lately as well
<trulux> JaneW: I'm exempt of going to school except for exams, so, I need organize for myself and sleeping is not a reliable option
<JaneW> trulux: they are R10 - R20 her in SA, in Thailand I was buying them for Bt10 - 15 which is R2-3 :)))
<JaneW> they are cheaper than coke over there
<trulux> jsgotangco: well, that path goes to drugs, drugs to more drugs, more drugs to less money, less money to less drugs and that finally gets you in the real Dark Side (tm)
<surak> JaneW: what is r10, r20, bt10?
<JaneW> R10 is 10 Rand = SA currency. 1GBP ~= R11-R12
<surak> thanks
<\sh> R8 ~= 1 EUR
<JaneW> Bt10 is Thai Baht, wasa around Bt6 - R1 when I went last April
<Mithrandir> JaneW: R1 =~ NOK 1, so it's quite convenient for me. :)
<JaneW> Mithrandir: cool, how does the spending power compare?
<Mithrandir> JaneW: a normal wage is in the range of 250kNOK and up, depending a bit.
<JaneW> Mithrandir: how much would a coke cost? A 340ml can here is R4-R5 depending on where you buy it.
<Simira> JaneW: the double :p
<JaneW> and a McDonalds burger is R17
<Mithrandir> cans are more expensive than bottles; a 0.5L bottle costs you about 8 kr, double that if it's a newsstand or cinema or something.
<JaneW> I mean happy meal
<JaneW> the meals with coke and chips(fries) is R22 or so
<\sh> JaneW: but u have better fastfoods then mcdonalds :)
<Simira> Mithrandir: didn't you notice that the 0.5 bottles are 11kr now? :p
<Mithrandir> Simira: no, I only buy 1.5L bottles. :P
<JaneW> Simira: that's quite pricey!
<Mithrandir> JaneW: honestly, I don't know, I haven't been in a mcdonalds for years.
<JaneW> we get 2l of coke for around R10
<Mithrandir> 1.5L is often less than 0.5L, for some reason.  At least if you buy a four- or sixpack.
<surak> JaneWit costs the less than half in brazilian supermarkets
<elmo> janew: just say NO to NOrway.  they charge you for the air you breathe there
<Simira> JaneW: in your country, yes ;p On special offers, we get 1.5L for 13-15 nkr
<JaneW> Mithrandir: my kids have been sucked into the McD's toy ploy and so we go about once a month, I make sure it's not more often than that
<Simira> elmo: actually, we've got free air and fresh water. Mostly
<Mithrandir> Simira: < 10, but yes. :)
<Mithrandir> elmo: I'll get you a "free air" card next time you drop by. :-)
<Burgundavia> JaneW, if you quick, they will grow out of it, I did
<Mithrandir> elmo: so you won't be billed at the airport.
<JaneW> Burgundavia: well I watched the 'Supersize Me' movie
<JaneW> I like the idea of giving kids a BAD association with mcD's instead of a good one
<jsgotangco> mcD isn't so bad if taken moderately
<jsgotangco> (i was craving for it during UDU)
<lifeless_> avoid intravenous though
<JaneW> so like the guys says from when they are born, every time you drive past a Mac Donald's, punch your kid in the face
<lifeless_> thats too serious
<JaneW> that way they grow up thinking McD's is BAAAAD ;)
<surak> Here in brazil, McD is trying to change their image, selling healthy stuff. kinda creepy
<JaneW> here they have taken the supersize option off the menu
<JaneW> and if you ask for it you can still have it, but now it;s double the price
<surak> all their ads are now about how healthy their foods are
<JaneW> also our portion sizes are WAY smaller than the ones in the states
<lifeless_> JaneW: they never had supersize here
<JaneW> from what they showed on the movie
<Simira> JaneW: I guess they are here too...
<lifeless_> the US is just nuts.
<surak> lifeless: where are u?
<lifeless_> surak: at home.
* jsgotangco just goes to mcD to buy a happy meal toy for his daughter
<JaneW> The super size large here seems to be the small size in the states
<surak> lifeless: hum, what country is that?
<trulux> JaneW: a good one is civil dis-obeying: get a photo of a pedophile and pick it up to the face of that evil McDonalds red & yellow clown
<lifeless_> surak: oh, .au
<Mithrandir> JaneW: I don't know about the sizes you get in SA, but the biggest burger you get at mcdonalds here is like 140g, which is really not much.
<lifeless_> 140g of fat is huge ;0
<JaneW> Mithrandir: yeah I think it may be the quarter pounder which is what 140gm?
<\sh> JaneW: what was the name of this burger company? they're selling steak burgers
<JaneW> STEERS!
<JaneW> *YUM*
<HrdwrBoB> the quarter pounder is allegedly a 1/4 pound BEFORE cooking
<lifeless_> about the only thing I'll have @ mcds is an occasional chips & a chicken-thai burger (which is <relatively> lowfat)
<HrdwrBoB> ... though apparently during cooking it loses 66% of it's weight
<Mithrandir> JaneW: quarterburger would be 0.113kg, I think they have something a bit bigger now.
<jsgotangco> it becomes rubbery
<Mithrandir> lifeless_: their milkshake is nice.
<lifeless_> Mithrandir: blech, milk
* JaneW only eats left over junior cheese burgers ;)
<kierzko> hi
* surak will start to go to mcd when they sell mcbeer
<lifeless_> JaneW: where do you hunt the juniors ?
<\sh> JaneW: yeah,...steers :) it was wonderful to eat there
<opi> guys, help kierzko with a mirroring task :-)
<lifeless_> surak: move to france AIUI
<kierzko> ;P
<kierzko> so... i wish to mirror only i386 part of ubuntu
<JaneW> lifeless: oh there's loads running about all over the place... especially in the McD's play area ;)
<lifeless_> :0
<kierzko> is there any rsync mirror related only to i386 that i can use ?
<kierzko> or should i play with exclude switch ?
<surak> lifeless: I plan to do it, to learn to sail with the french
<JaneW> \sh: Steers is very good as fast food goes. Their slogan is 'real food made real good'
<JaneW> anyway I think I said I was going to bed
<JaneW> night all
<jsgotangco> anything "fast" in food has something sinister for me
<jsgotangco> night JaneW sweet dreams
<JaneW> thanks
<JaneW> jsgotangco: best 'fast' food is Thai roadside cooking :)))
<surak> night janew
<jsgotangco> yeah street foodrocks
<\sh> JaneW: but the best what I ate (real food) was in a suburb of cape town...small restaurant, waiter came from durban, and there was this 500g filet steak
<surak> I'm curious about street food in marrakesh
<jsgotangco> try the street hawker food in se asia and north asia
<surak> just saw something at discovery travel channel
<jsgotangco> mostly in thailand, malaysia, singapore and hong kong
<trulux> 2 years ago was the last time I went to a fast food site
<kierzko> ok. i'l play with exclude switches
<trulux> I want my over weight to be the pure, fresh, natural and healthy result of my sick obsession to work out for free here
* trulux grins
<Kamion> Mithrandir: (moved from #ubuntu-meeting) is that fallback for Norwegian just crack? I can remove it if that's the right thing to do
<Mithrandir> Kamion: I think we might want to consider that, yes.  It looks _weird_ when you have two forms of norwegian, some danish, some swedish and some english on the screen at once.
<Mithrandir> uniq: (from #ubuntu-meeting); if you get a norwegian ibook, great.  Please coordinate with Colin on 2539 then.
<uniq> I will.
<Mithrandir> Kamion: and I've actually been in situations where that was the case.. it's messy.
<Mithrandir> uniq: #ubuntu-no might be of interest.
<mjg59> mdz: Hi
<mdz> mjg59: hi
<mjg59> mdz: You pinged several hours ago
<mdz> mjg59: yes, about merging the hp changes into breezy
<mjg59> Ah, yes
<mdz> mjg59: is that straightforward, or do we need to plan it out?
<mjg59> A small amount of that I need to talk to HP about
<mjg59> The main issue is what happens with the video button and lid switch when you put it in ACPI mode
<mdz> mjg59: I'd like to make it an explicit Breezy goal so that it isn't forgotten
<mjg59> I think they make assumptions about the Windows video drivers
<mjg59> Sure, that's reasonable
<Kamion> isn't it part of LaptopMission?
<mdz> arguably, yes
<mdz> mjg59: if you don't think there's enough to be done to consider it a separate issue, I'm happy for it to be absorbed by LaptopMission
<mdz> mjg59: up to you
<mdz> so long as it happens
<mdz> if there's discussion/design that needs to happen, it might be nice to have that happen around a separate spec, but if not, cool
<mjg59> mdz: I think it's LaptopMission, but I think I need to talk to HP about it
<mjg59> mdz: There's not a huge deal of config that's HP specific (one ACPI scipt, one setserial thin that's arguably a kernel bug)
<elmo> mjg59: is this the stuff bdale was going on about, or do I need to ping him about that
<dholbach> good night everyone
<pitti> yeah, good idea, good night!
<surak> :-)
<trulux> need to go to sleep folks
<jsgotangco> night
<trulux> today I can't stand up to 6:00am even with 4 red bulls
<trulux> migrains are not anymore handy
<trulux> good night
<surak> night
<mkde> jdub, ping
<desrt> general question: how's ppc64 support coming along?
<desrt> on the Breezy wikipage, there is : Deferred / ppc64 kernel image / MatthiasKlose?, JamesTroup? / Need ppc64 gcc, then linux-image, then testing
<desrt> (ie: deferred from hoary)
<surak> kiko, there? the script is way much better now. have been removing the portuguese crap
<desrt> mako; poke?
<jdub> desrt: it's not hugely interesting for us atm
<surak> mdz: it's quite ugly, but it works wonderfully on i386, as kamion requested.
<Kamion> it's pretty interesting for G5s
<jdub> desrt: could be done as a community port in the mean time - that would be a good way to give it momentum
<surak> Kamion:
<jdub> Kamion: G5s have silicon brains, they cannot love
<Kamion> I did say that it should have portability hooks in it
<desrt> jdub; i'm not interested in a full port.. just a crosscompiler toolchain and a kernel image
<Kamion> that's what most ppc64 people actually want IME
<surak> Hey, it works. I'm on gnome of live installed!
<desrt> jdub; i've built a cross-compiler here... powerpc -> powerpc64.... maybe i should dpkg it or something?
<jdub> desrt: that'd be a really low-sweat way to kickstart it ;)
<desrt> (the kernel is being a royal pain tho)
<jdub> desrt: cross-compilers have been packaged in the past, i don't see why not
<desrt> ok.  i think i've seen a debian guide on how to build dpkgs... i'll try and find that again
<desrt> (worth noting: toolchain-src fails here)
<mjg59> elmo: Uh. Doesn't ring any bells, I'm afraid
<surak> Kamion: finished to shave every pt-br crap I had from my linux and it works. Now I need to make it work with real-world partitioning situations so grub (and after yaboot) will work.
<surak> can you tell me more about partman?
<Kamion> surak: what we were really looking for in a prototype was something that we can build on towards a finished product - the thing that concerns me is that while I'm sure it works, it really isn't the design we want, so I'm not clear on how we can build on your work
<Kamion> without rewriting it from scratch, which kind of misses the point :)
<surak> you are correct.
<Kamion> surak: not coherently at 1:30am - could you send mail with what you've understood so far, and I'll reply in the morning?
<desrt> jdub; k.  i'm gonna install a breezy box to work on this
<surak> Guess I'll go home now. It was a tough day.
<Kamion> I'm not too bothered about portugueseisms for now as long as we can understand the code :)
<surak> Could you take a look at it tomorrow? I will rewrite it from scratch, just wanted to put something working quick to know what caveats are inside live installed.
<surak> and of course, to have something which you could actually use.
<Kamion> partman is a fairly complicated beast - there's some discussion on the UbuntuExpress wiki about plans for refactoring it, but I'm not getting as much traction on that upstream as I'd hoped
<Kamion> but there is documentation here:
<Kamion> (hunts for URL)
<mako> desrt: hey there
<desrt> mako; how's work on ppc64 cross-compiler and kernel image coming?
<Kamion> http://svn.debian.org/wsvn/d-i/trunk/installer/doc/devel/partman/partman-doc.sgml?op=file&rev=0&sc=0
<mako> desrt: you *must* be thinking of someone else
<desrt> mako; possibly.  you're not james troup?
<Kamion> although I found it easier to understand by experimentation following reading the docs
<Kamion> desrt: that's elmo
<desrt> ah.
<mako> desrt: right
<desrt> google lied to me :(
<mako> desrt: wait.. what did you google for?
<desrt> "James Troup"
<desrt> first hit i got was under people.u.o/~mako/
<surak> Ok. Well, it worked. Now I can REALLY write something for ubuntuexpress for real.
<mako> right
<mako> desrt: ok, yeah, that's elmo
<desrt> cool.  thanks.
<mkde> Kamion, Riddell, so you guys think it will be alright to just rename the current BritishTeam? the page is not going anywhere. we can mail the guy who set it up and involve him
<surak> Kamion: Is python allowed?
<ogra> surak, wanted :)
* jdub grins.
<Kamion> surak: in the live CD installer, yes
<Riddell> mkde: I would use that page
<Kamion> surak: not in generic installer code
<Riddell> mkde: first event.. lugradio live
<ogra> surak, and dbus love would be nice to make it easy for me to attach the frontend there :=)
<surak> Ok!
<Kamion> that's why the live CD installer needs to be structured in clear layers
<mkde> Riddell, awesome
<surak> ogra, I'll start to write something clear and useful for us.
<ogra> yay :)
<Kamion> the bottom layer of which would be existing installer code, which has a restricted set of things it's allowed to depend on
<mkde> Riddell, UKTeam or UnitedKingdomTeam
<Kamion> a middle layer of glue from that to the live CD
<Kamion> and a GUI frontend
<Riddell> mkde: first one's shorter
<surak> Kamion: didn't get how would us 'glue' d-i with live installer. Mdz talked a standalone app would be desirable
<mkde> Riddell, true
<ogra> surak, the three layers put together are this app
<mkde> Riddell, what did you have in mind for lugradio
<Kamion> surak: http://udu.wiki.ubuntu.com/UbuntuExpress is quite clear that we want to reuse d-i components
<Riddell> mkde: well I'm giving a talk, as is Kamion and possibly sabdfl
<mkde> Riddell, when is dis?
<Kamion> and goes into some detail
<Riddell> mkde: but otherwise a list of who's all going would be interesting
<Riddell> mkde: next month, lugradio.org/live
<mkde> will check it
<mkde> maybe we can give it a bit of publicity
<Riddell> it's already been on slashdot, what more publicity do you need :)
<surak> ok. Thanks for your patience, Kamion. Thanks Ogra. Now I do need some rest.
<mkde> fair enough
<mkde> glamorous wolverhampton
<ogra> me too, 2:43 am ....
<surak> night people.
<ogra> night surak 
<mkde> ok Riddell Kamion https://www.ubuntulinux.org/wiki/UKTeam
<Kamion> cool
<mkde> now, i propose not to have a leader
<mkde> there is a guy as leader in LocoTeamList, we should definitely get him involved too
<mkde> but perhaps a leader as such would not be necessary
<Riddell> mkde: question is does UKTeam include Isle of Man :)
<mkde> good question
<mkde> if so we 0wn Ubuntu
<mkde> i'm gonna write to JohnLevin
<Riddell> good idea
<mkde> shall we amend the UK entry in LocoTeamList to say "no leader"?
<Riddell> mkde: ok
<mkde> if Kamion subscribes to the list then contact with the CC shouldn't be a problem...
<mkde> ok bed
<mkde> night all
<mkde> Riddell, ping me @ mdke when the mailing list is up and i'll subscribe
<jdub> mdz: around?
<dilinger> daniels: ping
<daniels> pong
<fabbione> hey dilinger 
<dilinger> hey
<dilinger> daniels: do you know if it's possible to override the xorg driver used on the live cd?
<\sh> morning
<dilinger> the ati driver does some really trippy things to the screen
<fabbione> dilinger: and switch to what?
<fabbione> vesa?
<daniels> dilinger: even better, you could file me a full bug report and get it fixed :)
<dilinger> vesa works, but that's after editing /etc/X11/xorg.conf
<dilinger> daniels: yea, that'll be done soon, i assume
<daniels> dilinger: if you have a custom /etc/X11/xorg.conf in place and write XORG_CONFIG=custom to /etc/default/xorg so it can get .'ed, then you're safe, but you can't do that automatically without re-mastering the CD
<daniels> maybe the X server just assumes it has all the keycaps available and fails because it's missing about half of them?
<dilinger> hrm
<dilinger> well, hopefully this won't happen on other machines
<dieman> heh
<dilinger> daniels: do you think this sort of problem will show up in the install cd?
<dilinger> i don't see why it wouldn't, but..
<daniels> dilinger: if the driver's broken on the install cd, then it'll be broken on the live cd
<daniels> and, in this case, vice-versa
<dilinger> ok
<AndyFitz> ping
<AndyFitz> JOIN #ubuntu
<\sh> whatsup
<daniels> OK
<jdub> daniels: is xorg -20 sane?
<jdub> daniels: ...ish?
<fabbione> jdub: 2 words in the same sentence that clash
<fabbione> xorg and sane
<jsgotangco> lol
<daniels> jdub: in three words: 'seems to work'
<daniels> jdub: (once you create the symlink for xkb)
<jdub> ahr
<jdub> thanks
<\sh> the deps are b0rked in any way..:(
* jdub goes to eat lunch instead ;)
<daniels> jdub: the key being sudo ln -s /etc/X11/xkb /usr/lib/X11/xkb
<daniels> after that, it all works fine
<Lathiat> daniels: doesnt help mine unfortunately
<daniels> Lathiat: seems to work fine here
<daniels> the difference between no keysyms at all, and prefectly-working keysyms
<daniels> i blame nvidia
<daniels> and/or seb128
<dieman> heh
<Lathiat> ive gone back to hoary for the meantime
<Lathiat> hard to do work without keybd shortcuts
<dieman> btw, if im not a member and am working on a bug, what should i do, just comment it that im working on it and then add a patch to the bug later?
<daniels> dieman: sure
<daniels> patches always appreciated :)
<dieman> and then afterwards harrass the list?
<dieman> or just wait for it to hit someones queue? :)
<daniels> dieman: someone will find it
<crimsun_> can anyone log in to bugzilla.u.c?
<dieman> daniels: ok
<crimsun_> nm, false alarm
<fabbione> guys who has older titaniom powerbooks?
<fabbione> titanium even
<daniels> fabbione: kamion?
<fabbione> awake :)
<jsgotangco> morning JaneW
<JaneW> mornign jsgotangco 
<JaneW> btw do spend 24-hours a day on-line? ;)
<jsgotangco> heh no :-) its only 2PM
<jsgotangco> when we talkedit was 6am
<\sh> JaneW: kids in school?
<dieman> heh
<dieman> its like 1:30 am here.
<dieman> i should go to bed
<JaneW> jsgotangco, no way... me works out how much sleep she had then.... er not that much!
<JaneW> \sh: yes, pre-school (nursery school)
<jsgotangco> pre-school is so expensive
<jsgotangco> (in my place anyway)
<dieman> im not looking forward to that.
<jsgotangco> well, i'm already a parent heh
<\sh> JaneW: oh young ones :) how old?
<JaneW> jsgotangco: schooling is not cheap here either, but if I didn't send them I wouldn't be able to work...
<JaneW> also they love going
<JaneW> the oldest is in Grade 0 now = starts official school next year
<JaneW> \sh: 3 and 5
<JaneW> jsgotangco: cool, age/s? gender?
<jsgotangco> i thought you were single then when i saw you in sydney
<jsgotangco> JaneW, 3y4mos. girl
<JaneW> jsgotangco: thanks - I think
<JaneW> jsgotangco: because I was acting single and 'easy', or because I look so young!?
<JaneW> joking
<JaneW> you don;t have to answer ;)
<jsgotangco> hah
<jsgotangco> i could have tried...
* jsgotangco hides
<JaneW> lol
<\sh> my little one is 11 :)
<jsgotangco> oh that is already manageable (i think?)
<\sh> jsgotangco: most of the time...but puperty is ringing at the door ;)
<jsgotangco> hah oh no
<\sh> or knocking ;)
<JaneW> \sh: wow!
<JaneW> \sh: I guess it depends if yu ave a doorbell or not...
<jsgotangco> JaneW, are you in an office or just at home telecommuting?
<\sh> JaneW: most of the time the doorbell is switched on :)
<\sh> JaneW: but have a look by yourself ;) see query
<pitti> Morning
<JaneW> jsgotangco: do half and half, I telecommute from home some days, and go into the office others. I am home today, partly due to the late night meetings last night, and because I am doing an airport run at lunch time
<jsgotangco> wow
<JaneW> it's nice aving the option
<JaneW> also I find I can often get more done at home, it;s quieter and the kitche is closer, so getting coffee doesn't involve a walk and chat with the person you bump into...
<jsgotangco> yeah i'd like to do that sometime too
<JaneW> I have noticed that I speed type with a cockney accent!
<jsgotangco> office work is becoming boring for me lately
<jsgotangco> (actually, im in an oracle meeting atm)
* dieman is happy to have very little to do with oracle at work.
<Treenaks> dieman: lucky you
<dieman> heh
<dieman> we have oracle in places, though
<dieman> but its all research based stuff, our actual production stuff for a few web-based apps is all mysql.
<jsgotangco> oh its the reverse in our side
<Treenaks> dieman: we use it as a very expensive version of mysql... we don't use ANY of the cool features
<dieman> heh
<jsgotangco> we just use mysql as proof of concept
<jsgotangco> (we actually use oracle applciations not just their dbase
<dieman> well, research, in the sense of academic research. im at a univ
<dieman> until recently the license prevented us from using it in infrastructure
<dieman> but they bought a site license because of setting up oracle calendar software, etc.
<dieman> was cheaper to just buy a license for everything, i guess.
<dieman> heh
<dieman> at work the central people have stuff like the calendaring software, lucent qip, and peoplesoft using oracle.
<dieman> we're all crossing fingers that lucent qip is going to go away someday.
* mvo is away for a bit, need to bring his car to the garage
<jsgotangco> bye bye
<KaiL> hmm, who broght that new "delete" icon to my kontact? ;)
<KaiL> ah, kdelibs-data 3.4.1 :)
<Riddell> KaiL: what's the new icon?
<KaiL> the trashbin for "delete" looks a bit nicer
<maswan> elmo: this is getting more and more "interesting", we get a ETIMEDOUT on a tcp read, not an rsync timeout. workign to figure out why.
<seb128> elmo: galeon/experimental sync please
<seb128> elmo: any reason why gtk-smooth-engine is not autosynced?
<opi> morning
<\sh> hey opi
<xuzo> hi
* opi *yawn*:s and get to the work :(
<Kamion_> lamont: try 'svn cat svn://svn.debian.org/d-i/trunk/packages/rootskel/src/lib/debian-installer-startup.d/Makefile' - I think that's as complex an example as one might normally need
<Kamion_> you might not need the amd64 handling there
<doko> seb128: any reason that gnome still uses libpng-10-dev, and not libpng-12-dev?
<seb128> what do you call "gnome" ?
<thom> pitti: see dbaron's email? :(
<pitti> thom: yes :-/
<pitti> thom: the new ffox point releases also contain new features, right?
<pitti> thom: so it would be a lie to state that warty has 1.0.4...
<thom> it includes a fix for a regression that we missed
<thom> and 1.0.3 also has unrelated features
<thom> so a total lie for warty and a smaller lie for hoary
<Simira> hm, who are the people working with LiveCD?
* Simira has just got a mail from a Norwegian student that writes his final project based around an BeatrIX/Ubuntu LiveCD for a school.
<ajmitch> hi pitti, thom 
<Treenaks> Simira: what's the question?
* thom nods at ajmitch 
<ajmitch> pitti: any idea of what hardened/selinux stuff has a chance of being approved for main?
<pitti> ajmitch: the updated selinux packages should go in in any case (mdz still has to approve, though)
<pitti> ajmitch: today I hope to get the vsecurity modules finished with trulux
<Simira> Treenaks: not a question, just a statement. It sounded very cool.
<ajmitch> pitti: yep, been working on those, as you've possibly seen
<pitti> ajmitch: at least some of them should be included as well
<Treenaks> Simira: hm, good point :)
<ajmitch> pitti: hopefully we can get some selinux policy & tools in as well
<pitti> ajmitch: at least in universe
<ajmitch> pitti: I'm hoping for main at this point :)
<jdub> morning tseng 
<tseng> hi jdub ;)
<Treenaks> tseng: ET4000? :)
<ogra> heh... 
* ogra tends to add this suffix too... (silently)
<Treenaks> ogra: ?
<ogra> Treenaks, et4000
<Treenaks> ogra: I think I'm missing some context here
<ogra> <Treenaks> tseng: ET4000? :)
<tseng> i thought I was dense
<tseng> jdub: did you see our livecd?
<jdub> yibbidayabbida--NO!
<tseng> jdub: mono-live.com
<ogra> Treenaks, i once had such a card... so my brain silently adds et4000 to the name
<Treenaks> ogra: yeah, me too :) tseng labs :)
<ogra> yep
<jdub> tseng: the bittorrent host:port part only has the port ;)
<tseng> hm
<tseng> lol
<tseng> i have the .torrent
<jdub> tseng: very nice tho - they're going to pimp this hard? :)
<tseng> wait no i dont, i did open in gnome-bt
<jdub> tseng: dude, mail sounder@ about it :)
<tseng> ok
<tseng> i dont think im subscribed either
<tseng> sec
<maswan> elmo: do you guys have a firewall or something else suspicious in the path?
<tseng> are firewalls suspicious?
<maswan> yes.
<maswan> elmo: because the only reason for this we have found so far is that something eats the tcp keepalive stuff and that timesout after 10 minutes.
<maswan> firewalls typically break stuff
<maswan> or run around saying "the sky is falling! the sky is falling!" at stuff like pmtu discovery
<mvo> tseng: re mono, is muine broken right now? 
<tseng> mvo: dbus is broken right now
<tseng> mvo: so, alot of other things by extension
<tseng> dbus-mono that is
<mvo> tseng: I get a error that the "gtk-sharp" assembly (version 2.0.0.0) could not be found in the global assembly cache
<Treenaks> wtf does muine use dbus for?
<tseng> yes there are missing dependencies from a slightly bad mono upload
<tseng> Treenaks: to talk to plugins
<Mithrandir> Treenaks: smoking crack.
<ajmitch> Treenaks: dbus is the way of the future, you know
<Treenaks> Mithrandir: no, that's the mono part
<maswan> tseng: or breaking large tcp windows for that matter, a hungarian debian mirror ran into that
<tseng> i cant fix it until mono goes to main and we build libdbus-cil again
<tseng> it would just FTBFS
<Treenaks> ajmitch: yes, dbus and xml, the solution to ALL future problems!
* tseng is reminded of the Aviator
<ajmitch> Treenaks: xml is old now
<tseng> Treenaks: spice up your life with d-bus!
<ogra> doko, ping
<mvo> tseng: a missing dep? on gtk-sharp2 maybe? (/me tries that)
<ajmitch> sleep time, night all
<tseng> mvo: its missing alot of deps
<tseng> i can send you a proper list from my local package
<mvo> tseng: ok. gtk-sharp2 did the trick for me 
<tseng> rock on then
<mvo> tseng: thanks, no need anymore :)
<tseng> great :)
* tseng finishes sounder email
<mvo> let's see how it deals with my mp3s ... rhymbox usually dies in the middle of scanning it
<ogra> mvo, there was one mono upload that couldnt resolve dependencys due to a broken binary in the package, the best workaround is to just install the build deps (even for other apps)
<tseng> muine plays 50gb of flac for me
<mvo> the build-deps? *uuuuuuu* 
<tseng> cant speak for number of files
<tseng> ogra: non-dbus stuff is already fixed
<doko> seb128: gnome-libs
<ogra> mvo, they are nearly identical to the deps ;)
<doko> ogra: pong
<ogra> tseng, yay
<seb128> doko: that's an old GNOME1 stuff, not sure .. is that an issue?
<mvo> tseng: yeah! still scanning but looks great so far :) 
<ogra> doko, vtk is on the transition list, any reason that python-vtk and vtk-tcl are listed besides libvtk4 ?
<ogra> seb128, do we need gnome-libs for anything ?
* ogra votes for morgue
<doko> seb128:, ogra: yes, for all the stuff that wasn't built in main for powerpc ...
<Kamion> ogra: yes, we need gnome-libs.
<Kamion> go look at germinate rdepends output
<seb128> doko: and is png-10 an issue?
<doko> it was, because it was miscompiled on powerpc, see the gnome-libs build logs, which failed
<seb128> k
<fabbione> infinity, thom: mind to look at #11122
<thom> holy heck; redhat have 800 lines of patches to dhclient's linux script
<fabbione> i find difficult to believe that xml errors are coming from the kernel
<Mithrandir> fabbione: you mean there's no XML parser in the kernel!?
<fabbione> Mithrandir: ehehe.. no
<fabbione> Mithrandir: are you running hoary on your amd64?
<fabbione> or did you switch to breezy?
<Mithrandir> fabbione: breezy.
<thom> well, checking a log is unlikely to be firefox related
<Kamion> I reassigned to kernel because of the CPU thrashing
<Mithrandir> fabbione: except my university workstation, which is hoary.
<thom> (one hopes, anyway)
<fabbione> Kamion: yes.. don't worry :)
<Mithrandir> thom: opening /var/log/foo in ff?
<fabbione> Mithrandir: ok... i was hoping you could shed some light to http://ubuntuforums.org/showthread.php?p=186041
<fabbione> Mithrandir: i have his initrd here
<thom> Mithrandir: puke
<Mithrandir> fabbione: does his initrd have a /lib64/ld-linux-x86-64.so.2 ?  I think he might have rm-ed /lib64
<Mithrandir> in his normal system.
<fabbione> Mithrandir: it's there
<fabbione> 90288 Kb
<fabbione> 879e394f510ae8c3bfe3f24052f7dd74  ld-linux-x86-64.so.2
<Mithrandir> 90MB?
<fabbione> meh sorry
<fabbione> Bytes
<fabbione> ld-linux-x86-64.so.2: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
<Mithrandir> mhm
<Mithrandir> can you get the initrd to me and I'll look at it?
<fabbione> Mithrandir: sure
<fabbione> Mithrandir: it's on http://p.u.c/~fabbione/
<ogra> doko, vtk ?
<doko> ogra: ?
<ogra> doko, vtk is on the transition list, any reason that python-vtk and vtk-tcl are listed besides libvtk4 ?
<doko> ogra: maybe not, but why do they have a shlibs file?
<ogra> hmm
<Mithrandir> fabbione: the search path for the linker doesn't include lib64 and lib64 isn't a symlink to lib..
<Mithrandir> hmm, does cramfs support symlinks?
<Mithrandir> yeah, has to, since there's some in dev.
<Mithrandir> jbailey: around?
<Mithrandir> fabbione: does he have a way to get a new initrd onto the system?
<fabbione> Mithrandir: yes
<fabbione> he is MistaED on #ubuntu
<fabbione> he is testing an older kernel just to be 100% sure that the kernel is not at fault (even if i know the kernel is ok)
<bob2> tseng: do you know the author of mojoportal?
<bob2> or does anyone? the license is broken.
<jdub> eh, what's that pythonic bug reporting thingy?
<bob2> reportbug?
<jdub> nono, the bug tracker
<ogra> RT ?
<jdub> that's very much perl
<ogra> err roundup i meant
<jdub> that's the one - thakns :)
<Mithrandir> fabbione: when he gets around again, could you do: MistaED: please try the initrd at http://err.no/tmp/initrd-test.img .
<fabbione> Mithrandir: sure
<Mithrandir> fabbione: I'm trying to write my thesis and fairly stressed out, so I try not to busywait on stuff like IRC: :P
<Mithrandir> fabbione: thanks.
<Mithrandir> give me a highlight and I'll see it.
<fabbione> Mithrandir: of course i understand.. thanks a lot for your help
<tseng> bob2: no, i dont
<bob2> ok
<tseng> i could ask jhill
<tseng> he seems to be into that stuff
<bob2> ah
<bob2> that would be good, if yo ucould
<tseng> sure
<tseng> time for work, cya.
<bob2> adios
<Mithrandir> fabbione: I have _NO_ clue how that happened.  At all.  It simply should not, in any way whatsoever, be possible.
<fabbione> Mithrandir: we need to talk with jb about it
<fabbione> Mithrandir: what change did you do to the initrd?
<fabbione> so i can explain to him if you are not around
<Mithrandir> fabbione: mv /lib64/* lib ; rmdir lib64 ; ln -s lib lib64
<fabbione> ah
<fabbione> OOOOOOOOOOOOOOOK john
<Mithrandir> fabbione: but it should have blown up spectacularly for everybody..
<fabbione> houston this is apollo13...
<fabbione> exactly
<trulux> heya fellows
<pitti> Hi trulux 
<trulux> pitti: going to fix that vsec thing
<pitti> fix -> port to 2.6.12?
<trulux> I forgot to buy the red cow crack today
<trulux> yup
<fabbione> 12rc5 please guys
<fabbione> packages will be probably up in the archive today
<fabbione> i am doing the usual build orgy
<trulux> fabbione: won't change API, so, no real diff to the work I need to do for rc4
<pitti> fabbione: sure, but that shouldn't make much of a difference
<pitti> fabbione: the final test will of course be with rc5
<fabbione> whatever :)
<trulux> one sec, door knocking
<fabbione> pitti, trulux: my orig.tar.gz for rc5 is on people.u.c/~fabbione
<fabbione> you can use the diff and dsc to unpack
<fabbione> but it won't build
<fabbione> i have other extra changes locally to fix that :)
<pitti> fabbione: no worries, the orig.tar.gz is enough
<trulux> fabbione: I use stack'ed patches so, I use vanilla sources. API, at the end, is the same
<trulux> pitti: this dpath shit can be an asspain
<trulux> pitti: I can't make it fully SMP safe
<trulux> lemme work out the crack, though
<Burgundavia> daniels, another bug report via forums for you
<bob2> someone who reads the forums needs to train them to file bugs
<Burgundavia> I working on that bob2 
<bob2> hehe :)
<Burgundavia> everytime I see a bug I tell them where to file it
<Burgundavia> I even had one success that I know of
<daniels> Burgundavia: ?
<Burgundavia> daniels, http://www.ubuntuforums.org/showthread.php?t=36909
<daniels> Burgundavia: that's vague enough to be useless
<Burgundavia> daniels, in terms of bug reports, should I be telling this "poor" souls that they should be filing bug reports, or just tell them to ride it out? What is more useful for you?
<daniels> Burgundavia: depends on the bug -- a lot of them are the same couple of bugs
<Burgundavia> daniels, ok, I will try and send the ones that don't look the same on
<daniels> thanks
<ogra> mvo, libapt-pkg-perl is not installable ?
<mvo> ogra: ok, I'll deal with it
<mvo> ogra: libdebtags is broken too, it has c++ issues
<ogra> ah, k... i was suspecting that
<Treenaks> libsmpeg too (which breaks libsdl-audio, which breaks dosbox)
<pitti> any gtk+ hacker here who touched a combo box before? (mvo? seb128?)
<pitti> is it possible to create a gtk_combo_box_new_text() with glade?
<bob2> hm, there's no console browser in the base system
<bob2> that seems kidna silly
<pitti> w3m?
<bob2> hm, I uninstalled ubuntu-base somehow.  thanks :)
<Treenaks> bob2: there's telnet, that's all you need!
<ogra> Treenaks, hey, libsdl-sound1.2 is in universe and only needs a rebuild, youre a MOTU ;)
<Treenaks> ogra: meh
<Treenaks> ogra: downloading source
<ogra> :)
<mvo> pitti: yes
<HrdwrBoB> bob2: it is annoying
<hunger> OOo crashes for me as soon as I try to open any menu. Anyone seeing the same in breezy?
<Treenaks> testing build :)
<ogra> :)
<Treenaks> oh wait
<Treenaks> pbuilder update'ing
<ogra> heh
<Burgundavia> mvo, should I bother asking on -devel about other opinions regarding the repo dialog redesign?
<Treenaks> mpt?
<Treenaks> [this IS devel btw] 
<Burgundavia> -devel the mailing list
<Treenaks> ah, ok :)
<mvo> Burgundavia: the bits that michiel pointed out? or did you send something new?
<Burgundavia> mvo, just asking for general opinions
<Burgundavia> as we have 2 sort of competeing visions
<mvo> Burgundavia: you don't like michiels ideas?
<Burgundavia> mvo, not really
<Burgundavia> mvo, the other issue we have is that we hae the same dialog being used in 2 very different places
<Burgundavia> synaptic and the u-manager
<Burgundavia> one has menus, and the other doesn't
<Burgundavia> therefor, for synaptic, I would move auth, etc. to menu items
<Burgundavia> but that doesn't work for the u-manger
<bob2> elmo: the readahead dir in the pool seems to be gone, but the Packages files say it should be there.
* thom shakes his fist at firefox
* pitti lends thom a third fist
<kiko> yawn
<pitti> hi kiko, tough night?
<kiko> just too rainy here
<kiko> hasn't rained for months, and now this.
<pitti> thom: don't worry, when GettingRidOfTheDesktop is implemented, maintaining lynx will be easier
<Burgundavia> security will also be much easier with OneButtonKeyboard
<mvo> Burgundavia: what would be you alternative idea?
<thom> pitti: grin
<Burgundavia> mvo, that is the stumbler, I am trying to reconsile these 2 competing ideas
<Burgundavia> mvo, I haven't had an epiphany yet
<daniels> thom: make the pain stop kthx
<daniels> S  SHR S %CPU %MEM    TIME+  COMMAND
<daniels>  9070 daniels   16   0  550m 462m 2420 S 12.2 46.1  65:15.61 firefox-bin
<jdub> Burgundavia: what's wrong with michiel's design?
<Burgundavia> jdub, I am not certain that MDI is the best way, but as I mentioned, this issue with two very different apps sharing the same dialog
<jdub> for the update manager prefs dialogue? that is *not* MDI, it's just tabs (which is a far saner way to aggregate related preferences than entirely new windows)
<dieman> ugh
<dieman> MDI.
<Burgundavia> jdub, have you read the first comment here: http://blogs.gnome.org/nb.cgi/view/michiels/2005/05/10/0
<Treenaks> pitti: current cryptsetup doesn't seem to have LUKS stuff in it :(
<pitti> it has!?
<lamont> Kamion: bash: svn: command not found
<lamont> hrm.. i can fix that. :-)(
<dieman> lamont: morning.
<lamont> morning dieman 
<pitti> Treenaks: http://changelogs.ubuntu.com/changelogs/pool/universe/c/cryptsetup/cryptsetup_1.0-0ubuntu1/changelog
<Kamion> lamont: hm what where?
<lamont> on my machine. 
<dieman> lamont: im going to try and find time to get patches for all your ftbfs bugs over the next few days because they are all so fun.
<lamont> dieman: WOOT!
<dieman> like, i learned so much about autotools last night i dont think i want to know why people use it. :)
<pitti> Treenaks: argh, it didn't build
<Treenaks> pitti: ah.. that explains it
<dieman> lamont: or at least mess around with ftbfs bugs, etc.
<lamont> dieman: autotools are evil
<jbailey> lamont: So I'm a freak for liking those too? =)
<pitti> Treenaks: my bad, will fix ASAP
<jdub> Burgundavia: the reference to MDI is just wrong
* jbailey cuddles with his sendmail, Hurd systems and glibc...
<dieman> ugh. sendmail.
<thom> jbailey: i think that's pretty well established regardless :P
<jdub> Burgundavia: the other points raised are about simplification, not the use of tabs
<dieman> the old OOo/staroffice interface was MDI, that was evil.
<jdub> Burgundavia: the sources and authentication pages are reasonable
<jdub> Burgundavia: the settings page is pretty reasonable to (though many of them could be ditched if we didn't want to expose those settings)
<jdub> mvo: i think the channel stuff in FindingPackages will have some impact on this
<Burgundavia> jdub, actually, I just realized that he has a new 2 tab one: http://blogs.gnome.org/nb.cgi/view/michiels/2005/05/12/0
<Burgundavia> jdub, I am composing my how to merge our ideas together comment on the bug
<pitti> Treenaks: uploaded cryptsetup_1.0-0ubuntu2, should be fixed
<Treenaks> pitti: cool
* Treenaks waits for -changes mail
<pitti> Treenaks: forgot a build dependency
<jdub> Burgundavia: right, so that's just simplification, not outright redesign
<Burgundavia> jdub, I just added my comment to the bug
<Burgundavia> https://bugzilla.ubuntu.com/show_bug.cgi?id=10453
<Kamion> lamont: oh :)
<Kamion> lamont: DEB_HOST_ARCH_OS := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS 2>/dev/null || dpkg-architecture -qDEB_HOST_GNU_SYSTEM)
<Kamion> lamont: that's one variant of the short answer
<lamont> Kamion: thanks
<Kamion> lamont: (and then you test 'ifeq ($(DEB_HOST_ARCH_OS),linux)')
<jdub> commented
<Burgundavia> jdub, cool, we will have a rockin dialog soon
<tepsipakki> why was readahead removed from main? breaks my hoary-installs
<seb128> are xine bugs supported 
<seb128> or that's universe crap?
<Burgundavia> jdub, did you see my mockup in comment #5? it isn't very hig happy, but I split the official and non-official
<seb128> libxine I mean
<Burgundavia> jdub, which allows for scaling
<Burgundavia> jdub, and the components would be defined, not hardcoded
<Burgundavia> jdub, thus is we add alllifeverse, it would simply be tacked on the end of multiverse
<jdub> Burgundavia: it may allow for scaling, but it doesn't actually scale
<Burgundavia> jdub, say again, I am not following you
<Kamion> elmo: ^-- readahead, shouldn't there have been a symlink left in main for hoary?
<jdub> Burgundavia: you've provided a way of showing other repositories, but i do not agree that it will scale usefully (particularly considering FindingPackages requirements)
<Burgundavia> jdub, so in finding packages we see people adding lots of little repos?
<jdub> yes
<jdub> in some use cases
<Burgundavia> ok
<jdub> it would be best to come back to this after further work on FindingPackages
<Burgundavia> ok
<Burgundavia> the currently dialog will not deal with that either, I don't think
<jdub> mvo: when are you going to be in stuttgart?
<Burgundavia> you will just have a mess
<mvo> jdub: saturday to monday
<jdub> cool
<jdub> i'll be in on saturday afternoon
<jdub> maybe we can meet up to work on FindingPackages
<seb128> what a nice saturday plan :p
<mvo> jdub: I will meet with ross in the 16-17:00 slot, maybe you can join?
<mvo> (at sunday)
<jdub> (i have a much better picture of the more difficult requirements now)
<jdub> mvo: um
<jdub> mvo: hrm, i had better be at the annodex one
<jdub> mvo: how about 17:00-18:00?
<mvo> jdub: I would miss robert love then :/
<ogra> oh :(
<daniels> dear seb128,
<daniels> GNOME IS ON CRACK AGAIN
<jdub> mvo: good point
<daniels> love,
<daniels> daniels
<seb128> what?
<seb128> panel? wkb?
<seb128> xkb
<daniels> panel
* seb128 goes to kick vuntz
<daniels> my bottom panel (the window list, wastebasket, show desktop) just jumped up to the top of my laptop
<trulux> another bomb in a car.....30 people injuried this time
<trulux> shit
<daniels> it's not spinning and eating all my ram any more, tough
<trulux> pitti: I'm going to have lunch and listen to the news for a few minutes
<daniels> trulux: eep :\
<trulux> pitti: will have vsec ready after that
<trulux> dand: yes ;(
<seb128> daniels: bah, just dnd it back at its place :p
<daniels> seb128: intuitive :P
<seb128> you moved it, you probably know how to move it back :)
* seb128 runs
<daniels> haha
<daniels> i didn't move it
<daniels> i was just reading my email, and bam
<seb128> weird
<daniels> it decided I didn't have enough things to harass you about
<ogra> daniels, blame your mail app
<daniels> so it gave me some ammunition
<daniels> ogra: mutt??
<seb128> that's probably the reason
<ogra> yeah
<ogra> :)
<Burgundavia> jdub, mvo can you write something up to -devel regarding the stuff you discuss, for those of us who are not going to be at GAUDEC?
<Unfrgiven> elmo: ping?
<jdub> Burgundavia: yeah, will be added to the spec
<Burgundavia> jdub, cheers, thanks
<dieman> daniels: don't worry, my bottom panel dances around depending on what machines i login to :)
<dieman> its really a floating corner panel or something ,though
<dieman> too bad gnome doesn't just keep it in the southeast corner at all times :|  login to a box with 1280x1024 and can find it in the middle of a 1600x1200 screen on my main desktop box (shared configs over nfs/orbit over ipv4)
<Simira> who has stolen my Norwegian letters??? And my at-sign?
<thom> Simira: daniels
<tseng|work> klammeraffe!
* Simira throws a shoe after daniels 
<Simira> help! Someone!
* tseng|work hands Simira an @
<thom> tseng|work: careful, yours'll be stolen next
<Amaranth> @
<Amaranth> ;)
<Amaranth> btw, what's the latest trick for making X work again?
<Seveas> editing fontpaths?
<Lathiat> order beer delivered to daniels
<Seveas> lol :)
<Amaranth> fonts this time? i thought that was last time
<Lathiat> Amaranth: i had to link /etc/X11/X
<Lathiat> to /usr/X11R6/bin/X or something i think
<Seveas> ah, then i missed this one already :)
<doko> elmo: please sync bash from incoming
<Lathiat> look in the error log...
<Simira> thanks, tseng, but I'll need a bunch of them during the day.
<Amaranth> /etc/X11/X is not executable <--nice :)
<tseng|work> you need a symlink
<Simira> do I need that?
<tseng|work> not if its starting X
<Simira> from to where?
<Simira> now I got confused
<Lathiat> Amaranth: yeh so symlink from wherever
<Simira> anyway
<Amaranth> Lathiat: It can't be /usr/X11R6/bin/X, that's a wrapper
<Lathiat> why cant it be
<Lathiat> iirc X is a wrapper anyway
<Amaranth> Xof: /etc/X11/X points back to X wrapper executable, aborting.
<thom> ls -l /etc/X11/X
<thom> lrwxrwxrwx  1 root 17 2005-05-24 16:58 /etc/X11/X -> /usr/bin/X11/Xorg
<thom> WFM
<Amaranth> err, xchat expanded X ro Xof 
* Xof waves
<Amaranth> hmm, busted symlinks
<Amaranth> /usr/bin/X11/Xorg and /usr/X11R6/bin/Xorg point to ../../X11R6/bin/Xorg
<Amaranth> oh, recursive symlinks, even better :D
<Simira> grumph
<Simira> ok, seems my keyboard settings are totally wrong, even though they seem right in the graphic keyboard-setup. Where/how do I get my keyboard set up so it works?
<thom> ah well, guess it's been upgraded and nuked the relevant symlink
<Treenaks> Simira: use hoary.. or threaten to do something horrible to daniels if he doesn't fix it in breezy
<Simira> Treenaks: it *IS* hoary
<Treenaks> Simira: scary
<Simira> I'm not running breezy for my server
<Simira> anyone?
<Simira> *cries a bit for help and sympathy*
<Amaranth> woo, i've totally broken X :)
<Simira> Amaranth: Breezy or Hoary?
<Amaranth> breezy of course
<Simira> right
<Simira> hm...
* Simira does some killing
<Amaranth> heh, your problem sounds like user issues
<Simira> Amaranth: probably. But it doesn't make it less annoying
<Simira> brb
<Simira> argh!
<Simira> how can I get anything done when none of my keys except stndard letters work?
<Lathiat> yeh simple
<Lathiat> dont run breezy
<chmj> straight forward even 
<Lathiat> yep
<Lathiat> i went back to hoary for now
<trygvebw> <Simira> Treenaks: it *IS* hoary
<trygvebw> ?
<Lathiat> while i dont mind dev stuff in general a totally broken X makes it hard to get work done
<Amaranth> note to self: dpkg -S X is worthless
<Lathiat> heh
<HrdwrBoB> haha
<mkde> Riddell, ping
<Riddell> mkde: hi
<mkde> Riddell, got an email from that JohnLevin chap just now, seems he is organising a Ubuntu stall for that lugradio event
<Riddell> groovy, get him to put it on the wiki page :)
<mkde> yeah thats what i wrote
<mkde> hows that list coming?
<Riddell> mkde: list isn't here yet, I'm sure jdub has been busy working on it all morning
<mkde> lol
<dilinger> heh
<dilinger> one of my coworkers has requested an ubuntu tshirt w/ naked people on it
<HiddenWolf> lol
<HiddenWolf> I'd sign
<kiko> dilinger, naked mdz  and elmo and sabdfl?
* Amaranth pukes
<Amaranth> no offense ;)
<thom> kiko: BAD MAN!
<mkde> those naked models would be more appropriate
<tseng|work> kiko, roughage
<bob2> kiko: don't give anyone ideas
<Amaranth> i'm making progress, i've got X: user not authorized to run the X server, aborting. now
<dilinger> kiko: that'd work, as long as he didn't wear it around the office ;)
<kiko> you guys are all about ubuntu and real people
<kiko> we give you the naked lunch
<tseng|work> thom: somehow the water from germany yesterday worked all the way to brazil
<bob2> ah, it's time for the daily "firefox go whacko" show
<bob2> today's stars include uncloseable error boxes and new tabs getting the url of previous ones
<tseng|work> bob2: wow, those are my pet peeves too
<HrdwrBoB> yeah
<bob2> it only happens sometimes.  but seems unfixable without a restart.
<tseng|work> of course entering a new url gets overwritten
<bob2> which is awesome when I have 20 lp tabs open.
<HrdwrBoB> and upgrading while runnig firefox and having the whole thing die in the arse
<tseng|work> by whatever it decided your url is
<tseng|work> eh that one is expected HrdwrBoB 
<HrdwrBoB> yeah but if you have it open, you can't save anything you've got open or do anything with it
<Mithrandir> use sessionsaver, then
<bob2> hmm
<HrdwrBoB> Mithrandir: hrm, not sure if it'd work
<Mithrandir> HrdwrBoB: it works.
<HrdwrBoB> in any case, I got over it, but firefox upgrading should be a tad more graceful
<tseng|work> how often do you upgrade firefox, really
<bob2> Mithrandir: on mozdev?
<bob2> tseng|work: there's been like 3 security releases since the last time I restarted X
<tseng|work> every few weeks
<HrdwrBoB> tseng|work: often enough... I rarely close it, so even a few upgrades is more than enough
<thom> tseng|work: seems that way, yeah
<tseng|work> i dunno, i consider firefox to be volatile and act as such
<tseng|work> not relying on it to save my work or stay open for weeks
<Mithrandir> bob2: I think so, yes.
<thom> currently on amd64 it doesn't stay open for 5 minutes
<tseng|work> upgrades arent often enough for me to take major issue with it
<thom> i might roll one with gcc3.4 and see if it is happier
<Riddell> mkde: http://lists.ubuntu.com/mailman/listinfo/ubuntu-uk
<mkde> Riddell rock
<Riddell> mkde: can you add that to the wiki page and announce it on ubuntu-user (and ubuntu-devel?)
<mkde> Riddell, its on the wiki page, i'll post to those lists sure
<mkde> Riddell, gimme a few hours tho
* thom supposes he should sign up
<pitti> Treenaks: cryptsetup built, there you go
<Treenaks> pitti: \o/
* mkde nudges thom in the direction of the list
<thom> mkde: already done
<pitti> mvo: uploaded new control-center with the default sound card selector; yay, my first gnome patch
<mkde> argh
<pitti> mvo: thanks for your hint about the combobox
<mkde> thom, yay
<Lathiat> pitti: woo
<mkde> i appear to be subscribed twice
<mkde> hmm
* mkde glares at Riddell
<mvo> pitti: np, glad(e) to help 
<Riddell> mkde: you were the first one I subscribed :)
<fabbione> pitti: all the sound changes are nice, but did you already switch to libesd-alsa ?
<pitti> fabbione: yes
<mkde> Riddell, i'm going to unsubscribe that address, but i appreciate the thought ;)
<fabbione> pitti: and more important... did we actually implemented the kill -HUP esd to reload the new config?=
<pitti> fabbione: we don't use esd any more (or at least not ATM)
<fabbione> uh ok
<pitti> fabbione: gstreamer pipes to alsa directly
<pitti> fabbione: esd + dmix really sucks, quality-wise
<pitti> fabbione: I tried a few patches, but none of them helped
<fabbione> and if there are other apps != gstreamer?
<pitti> fabbione: alsa or esd
<fabbione> so there is still esd around---
<pitti> fabbione: you *can* use esd
<pitti> fabbione: yes, we should switch that to polypaudio soon
<fabbione> note that's a little while i can't update my workstation :)
<pitti> fabbione: but I couldn't deal with that yet
<fabbione> ok
<pitti> fabbione: we now have dmix, can select the default device in gnome-sound-properties
<pitti> fabbione: I just need to add the hotplug dialog box
<pitti> Hey Keybuk 
<fabbione> pitti: yeah i was checking the changelogs.. impressive
<tseng|work> pitti: you rock!
* pitti blushes
<ogra> yeah
<tseng|work> cant wait to try it out
* pitti borrowed an USB headset for testing, works fine
<trulux> pitti: could you give me the default config file for breezy's 2.6.12?
<pitti> trulux: every arch and flavor has different configs
<pitti> trulux: apt-get source linux-source-2.6.12
<pitti> trulux: cd linux-source-2.6.12-*/debian/config
<trulux> pitti: then gimme i386 by dcc pelase
<trulux> please
<pitti> trulux: I have k7, is that ok?
<trulux> pitti: yes
<trulux> these terrorists are real motherfuckers
<jdub> daniels: around?
<trulux> there are kids in the streets at that hour
<pitti> trulux: people.ubuntu.com/~pitti/config-2.6.12-1-k7
<trulux> and more in the street the did the thing
<trulux> many thanks
<trulux> pitti: thanks
<fabbione> ogra, amu: ping?
<ogra> fabbione, not tested yet, upgrade in progress, the apps are there on one machine. i need to set up my second machine which is busy with Cxx builds...
<fabbione> ogra: ok
<dieman> hrm
<ogra> but you'll get your first report today
<dieman> readahead isn't working in the install im doing. hrummmph
<fabbione> ogra: ok :) tomorrow is fine too :)
<dieman> just because of that link issue.
<ogra> oi
<ogra> oki even
* dieman waits for the archive to be fixed...
<thom> right, lets see how hard i broke dhclient
* thom goes out
* \sh needs valium
<trulux> pitti: did you have problems related to inet = inet_sk(sock->sk);?
<pitti> trulux: don't know any more; I have to go no, see you tomorrow; sorry
* pitti has to run
<jdub> thom: nice upload ;)
<fabbione> lol
<fabbione> ciao enrico :)
<enrico> fabbione: ciao!
<thom> jdub: shame i fucked it really :P
<jdub> heh
<thom> (in a non-terminal way, i should add)
<Mithrandir> jbailey: I think fabbione has a totally crackful initrd bug for you.
<\sh> ah the right man the right time :)
<fabbione> Mithrandir: he knows already
<\sh> Mithrandir: libncurses5-dev
<Mithrandir> \sh: done.
<Mithrandir> fabbione: oh, ok.
<\sh> Mithrandir: thx :)
<daniels> jdub: yeah?
<jbailey> Mithrandir: He's handed it to me, and I've got the initrd from the guy now.
<jbailey> Mithrandir: The bug isn't jumping out at me, though.  I don't see other mentions of it in bugzilla yet, so hopefully it's just that this guy did something insane.
<omie> is it the kernel not booting?
<fabbione> jbailey: at least 2
<omie> i had that this morning, several people on ubuntuforums.org are having that problem, too
<jbailey> fabbione: Ugh, really?  Gmm
<fabbione> jbailey: one in the chan and one in the bug report
<jbailey> Ah, I hadn't looked to see that it was differnet people.
<ogra> daniels, no more gvim in the package ?
<fabbione> omie: can you be slightly more specific?
<omie> seems like ide-generic wasn't in the initrd or the initrd just wasn't working at all
<jbailey> omie: The bug that they showed me appared that libc6 wasn't being copied in.
<omie> because it couldn't boot off my /dev/hda1
<fabbione> omie: a reference to the forum
<omie> fabbione: sec
<fabbione> jbailey: it's probably the same bug all over
<fabbione> jbailey: the kernel boots.. as the old one can..
<omie> http://www.ubuntuforums.org/search.php?searchid=813405
<fabbione> the changes are close to 0 for the security fixes
<omie> almost all those topics are about the same thing
<fabbione> none of them can change behaviour like that
<jbailey> Right, but mkinitrd hasn't changed at all in the hoary release.  That's the confusing part.
<daniels> ogra: the only thing I deleted is vim-lesstif
<daniels> if that's what gvim is, good riddance to it :P
<daniels> but there's still -gtk and -gnome
<ogra> ~$ gvim
<ogra> E25: GUI cannot be used: Not enabled at compile time
<ogra> with the recent package
<Treenaks> ogra: *headdesk*
<ogra> heh
<daniels> ogra: never tried -gtk, -gnome worked for me
<\sh> ogra: u don't need s/^g// vim;)
<daniels> someone else reported that it was broken ... I don't know what it is, I'm not the vim maintainer, and I'm going to bed
<ogra> daniels, happens with both
<jbailey> Ah crap.
<jbailey> Acc. to the forums some people updated to glibc 2.3.5
<Lathiat> dnaiels please save the world kthxbai
<fabbione> jbailey: amen
<jbailey> Don't do that people.  When your system breaks you get to keep both halves with little sympathy.
<Lathiat> let me guess, it was a backports project?
<ogra> \sh, if i want to use my mousewheel to scroll through a 8.4M xscreensaver patch, its very helpful to have gvim :-P
<thom> jbailey: oh hoary? holy christ
<jbailey> The best I can do I guess is upload a new glibc that conflicts against the old initrd-tools.
<Treenaks> isn't "Sorry, you broke it. We warned you." enough?
<\sh> ogra: 8.4M?
<ogra> \sh, yep
<\sh> u rewrote xscreensaver?
<ogra> nope
<Treenaks> ogra: images?
<ogra> nope...
<Kamion> jbailey: that would cause fun upgrade issues, surely
<jbailey> Kamion: Possibly, but using the new glibc with an old initrd gives unbootable systems.
<\sh> hmmm..again a package with cp config.{guess,sub} . during the clean: target
<Kamion> jbailey: do we really want initrd-tools to be removed during the course of the upgrade?
* Kamion thinks not
<jbailey> Kamion: No, wouldn't it just put in the newer version?
<Kamion> jbailey: only if it can do so without requiring the newer glibc
<fabbione> jbailey: probably you want to force a dependency on a new one?
<Kamion> which it might be able to at the moment, but one stricter dependency from initrd-tools could break that easily ...
<Kamion> versioned << conflicts in upgrade calculations are really REALLY fragile
<jbailey> What do you suggest?
<Kamion> I'm not sure :-/
<Kamion> we need the Breaks: header
<jbailey> Keybuk: *poke*
<Keybuk> heh
<jbailey> Keybuk: help? =)
<fabbione> eheh
<fabbione> dpkg:
<Keybuk> patches welcome :p
<fabbione> Breaks: distro
<Keybuk> seriously, there isn't a robust way to do that without the long-proposed Breaks header
<jbailey> Is that just an "unpack me first" sort of reverse pre-depends type of thing?
<omie> is it something from backports that's pulling in 2.3.5?
<jbailey> No idea.  I haven't confirmed that it's this in all cases, I just saw it mentioned in the foru,s.
<omie> i don't think it's quite the case for me:  libc6: 2.3.2.ds1-20ubuntu13
<Kamion> jbailey: roughly, Breaks is to Conflicts as Depends is to Pre-Depends
<Kamion> it's a weaker relationship
<jbailey> omie: Right.  I'm looking at the specific case where the ld.so just isn't being copied to the initrd.
<Keybuk> if A breaks B, then A and B may be unpacked at the same time, but not configured at the same time
<Kamion> Conflicts says "may not be >= half-installed at the same time"
<fabbione> there we go
<fabbione> 2.6.12rc5 is up
<fabbione> Kamion: we are getting closer to final :)
* Kamion ponders enabling HashKnownHosts by default
<Kamion> upstream *did* say they wanted testing ...
<omie> jbailey: that's what was happening to me
<omie> shit
<omie> /lib/ld-linux.so.2 -> ld-2.3.5.so
<omie> don't know what that's about
<jbailey> omie: That's about severe suckage. =)
<jbailey> omie: If you can help us trace where that came from, that would be lovely.
<\sh> Mithrandir: ping
<\sh> ah forget it..wasn't in the chroot
<pef> hello
<pef> https://bugzilla.ubuntu.com/show_bug.cgi?id=10999 this is my first bug report, have I missed something ? Is it clear enough ?
<seb128> doko: you want gaim bugs? :)
<doko> hmm, not really ...
<seb128> k, because you just reassigned one to you so I was wondering :p
<doko> ahh, yes, and then I saw gaim was already uploaded ...
<seb128> k
<seb128> pef: the bug looks correct, if somebody wants extra informations he'll comment on it
<pef> seb128: thank you ;)
<\sh> hmmm
<javi> hi, I upgrade to breezy gnome-terminal go to hell when I type CNTRL-SHIFT-N .... do you know about it ?
<thom> javi: yes
<trygvebw> javi, things like that happens when you're using breezy...
<trygvebw> especially right now
<Burgundavia> javi, ctrl-X stuff is currently fubared
<Burgundavia> javi, no ETA on fix
<javi> ok, it isn't only  happens to me
<javi> thank you!
<doko> Kamion, elmo: libmime-perl (main) depends on libconvert-binhex-perl (universe). ? 
<Kamion> sounds like a straightforward thing to promote; it's in the anastacia report
<jvw> anastacia... why do I suspect that's enought member of the dak family of scripts :)?
<Kamion> correct
<Kamion> produces reports of suggested main<->universe promotions/demotions
<jvw> I see -- demotions, though, you mean removal from a certain ubuntu suite?
<Kamion> no, movement between components
<ogra> doko, i assigned you two Cxx transition bugs where i have no idea what to do... beware of vtk, it compiled 2h here
<jvw> ah, right
<Kamion> we don't require reuploads to do that, because otherwise we'd've had to upload everything in universe when we were getting started
<Kamion> instead there's a script called teri which does the move
<jvw> without recompile even, or with?
<Kamion> without
<Kamion> it's just overrides
<\sh> raping my rootserver with pbuilder
<jvw> right, that sounds like all of Debian packages are in some pool somewhere then, otherwise the move would be a bit tricky...?
<jvw> and covertly an upload anyway?
<Kamion> not really, it actually has to move the file from pool/main/ to pool/universe/ and leave a symlink behind
<Kamion> (if the file was in a different component in another suite, that is)
<jvw> oh, right, so the debian compontents are in the bigger pool too, next to the ubuntu components
<Kamion> no ...
<doko> hmm, what was the equivalent to packages.debian.org?
<Kamion> there's an auto-syncer that reuploads Debian packages to our pool
<jvw> I thought ubuntu didn't have a 'main', but maybe I'm wrong :)
<Kamion> doko: packages.ubuntu.com
<Kamion> jvw: you're wrong ;-)
<jvw> bad me ;)
<Kamion> (you asked for that)
<jvw> eh... I'm not offended or something if someone tells me that I'm wrong if I'm wrong...
<doko> seb128: could you care about bug-buddy? FTBFS, missing header
<seb128> k
<seb128> I'll upload pan for new aspell too
<doko> seb128: pan is already done
<seb128> doko: k, that less to do :)
<seb128> doko: I'll not get my upload rejected like for gst 2 days ago :p
<Kamion> jvw: there isn't a "bigger pool", anyway, the pool organisation looks pretty much the same as Debian's; it's just that we move stuff around in it a little more freely
<\sh> touch: cannot touch `/var/lib/update-notifier/dpkg-run-stamp': No such file or directory
<\sh> E: Problem executing scripts DPkg::Post-Invoke 'touch /var/lib/update-notifier/dpkg-run-stamp'
<\sh> E: Sub-process returned an error code
<\sh> while I was trying to create a new pbuilder env for breezy
<CarlK> I just duplicated https://bugzilla.ubuntu.com/show_bug.cgi?id=10999 - got the same "rt_sigaction(SIGINT..." - is that enough to mark it "confirmed/new", or is there more to it?
<doko> seb128: just trying to get main installable again, so Kamion can make a CD tomorrow ;)
<seb128> k
<fabbione> Mithrandir: benno is on irc :)
<fabbione> Mithrandir: no chan that i can see
<mdz> mvo: aptitude still seems to need a rebuild
<bob2> doko: should python-profiler really be in multiverse?
<mdz> mvo:   aptitude: Depends: libsigc++-1.2-5 but it is not going to be installed
<doko> bob2: yes, unfortunately
<bob2> ah, right, restriction on use
<doko> bob2: it's the license, it's restricted, in that the code may only be reused for python related things. whoever does really want to reuse a python profiler outside of the python world ...
<bob2> on code from 1994, even
<bob2> that all seems a tad silly
<Kamion> doko: ... seems ambitious :)
<Kamion> but go for it
<Kamion> mdz: libsigc++-1.2-5 is correct
<mdz> oh, we're going from c102->null rather than c102->c2?
<Kamion> apparently so
<doko> it is, I'm in contact with somebody, but you have to track the companies ...
<mdz> well, at any rate not all of the apt-related stuff is installable at once
<Kamion> ok, aptitude's installable as part of a debootstrap, so it must be something outside minimal
<ogra> \sh, see the PbuilderHowto, there is a note about hat
<doko> seb128, daniels: did somebody of you did adapt packages to the new dbus?
<mdz> I can't upgrade apt without removing aptitude
<ogra> that even
<Kamion> mdz: breezy_probs.html only lists kynaptic as being uninstallable
<mdz> though aptitude seems to be built with the new libapt
<\sh> ogra: new note ;)
<mdz> Kamion: they're all individually installable
<Kamion> ah
<mdz> they just conflict
<ogra> doko, mono moves to main, so we'll get a dbus-cil package out of the standard dbus source ....if that answers your question
<\sh> ogra: no there is no problem with doing the update from hoary to breezy, see my error message
<\sh> argl
<\sh> yes
<bob2> ogra: mono -> main for breezy?
<ogra> bob2, yep
<Kamion> mdz: ok to move the mono stuff to main now? ogra sent me mail with a list
<bob2> awesome
* \sh is blind...
<mdz> Kamion: yes
<ogra> bob2, beagle love :)
<bob2> ogra: looking forward to it :)
<ogra> yeah
<seb128> doko: what package? I updated some GNOME stuff with redhat/upstream patches mainly
<bob2> ogra: plus, when it crashes, you guys have to fix it for me ;p
<ogra> heh
<ogra> bob2, tseng has to, i only care for the amd64isms
* ogra hopes bob2 has no amd64 destop
<mako> ogra, tseng: you guys up for a backports meeting say, next wednesday at 19:30UTC?
<ogra> sure
<mako> and anyone else who wants to show up?
<mako> who else should be there?
<\sh> yeah
<Kamion> beagle, monodevelop, tomboy added to supported; of course elmo'll need to actually do the promotion
<jdub> mjg59: ping
<ogra> Kamion, yay :)
<mvo> mdz: I'll have a look at aptitude now
<ogra> mako dholbach will be there
<doko> seb128: workrave
<doko> ogra: no
<seb128> doko: fedora doesn't ship it apparently, so no patch here
<mdz> mvo: thanks
<mako> ogra: anyone else who should definitely be there?
<ogra> mako, dunno if mdz is needed here...or someone else from the desktop teamlead...
<mdz> where?
<mdz> oh, backports
<mdz> yes, I need to be there
<mako> mdz: can you be there?
<mako> next wed, 1930?
<Burgundavia> `+++++++++++++++0
<mdz> mako: yes
<Burgundavia>                                                                                                                                                7`-*+1`9-+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++`+78888888888888888888888888888888888888888888888888888888888888888888888887
<Burgundavia> +-*`*--/**********************************************************************ZERRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
<mako> Burgundavia: RRR
<mvo> Burgundavia: hrm, what are you doing?
<\sh> this is not ascii art?!
<ogra> kitti kitti kitti
<ogra> meow
<\sh> hahah
<Amaranth> that looks like nothing here
<Amaranth> what was it?
<ogra> Amaranth, dont you see the cat footprints in it ?
<\sh> it was ascii keyboard art (c) by Burgundavia cat...or his dog tried to become humanoid, an error in the matrix
<Amaranth> its' a bunch of non-lined up gibberish here
<Amaranth> oh
<Amaranth> maybe he fell asleep on the keyboard
<mako> cool, announced
<mako> mdz: the cc meeting yesterday was funny IRT the backports stuff
<mdz> mako: I have a todo item to write a spec for official backports
<mako> mdz: you looking to farm it out to someone.. i think next wednesday might be teh place to do it
<mako> people were like, "i've done loads of stuff for x and y"
<Burgundavia> whoops, sorry guys
<mako> "great great"
<mako> .. "and done LOADS fo backports work!"
<Burgundavia> was cleaning my desk
<mako> sort of like "let's focus on x and y"
<Amaranth> where are the irc logs again?
<mako> mdz: *loads* of people are using them
<mdz> mako: see above
<mako> mdz: they have the stats but it's scary
<Amaranth> yeah, the backports might not exist soon, they're so popular the server is pushing it's bandwidth limits
<Amaranth> wait, they got a mirror with a fat pipe, that's right
<mako> i'm sure tseng is relieved to hear that
<CarlK> apt needs to get in bed with bittorrent ;)
<bob2> people have started doing that, then got bored
<Burgundavia> Amaranth, I have some irc logs, but fabbione has the offical one
<Amaranth> CarlK: that would be worthless
<Amaranth> when you're using apt you want it to finish fast and get out of your way
<mako> Amaranth: i have some too
<mako> Amaranth: i'm going to publish the 'official' logs as soon as i write them up
<mako> likely not today though
<mdke> Amaranth, http://people.ubuntu.com/~fabbione/irclogs iirc
<mako> maybe tomorrow night
<CarlK> Amaranth anything that needs a "fat pipe" could be helped
<mako> http://www.ubuntulinux.org/wiki/UbuntuBackports
<Amaranth> CarlK: Only a select few packages would benefit. bittorent isn't the greatest thing to use for 400k files
<Amaranth> that's file size, not number of files ;)
<CarlK> Amaranth - I agree that the currennt BT wouldn't be good, more the distributed load concept
<mako> Amaranth: i was going to say that i suspect that bt is not useful for a lot more than 400k files
<mako> i'm happy to go ahead and generate over 400k files that it would be useful for right now to illustate the point :)
<CarlK> mako - if it will make you happy, don't let me slow you down ;)
<Amaranth> apt and synaptic are supposed to basically hide the fact that you're using the internet to download programs, otherwise people might be encouraged to download random programs and try to run them
<mdke> mako, that meeting is going to be crazy ;)
<Amaranth> it you use bittorrent it makes it more transparent
<Amaranth> I have to make it to that meeting, it's going to be funny as hell.
<Amaranth> Probably lots of users coming to back up/save their precious backports.
<mdke> i hope it will be civilised
<mdke> from both sides
<Amaranth> ;)
<fabbione> meeeeh
<ogra> mdke, at least from our side it will
<fabbione> backports are evil :)
<dieman> ugh.
<Amaranth> they put smeg and pymusique in their universe instead of their hoary-extras, it makes no sense
<dieman> backports.
<ogra> fabbione, but users demand them obviously.... so lets see to get them to a half way usable state at least
<dieman> backports were an invention for debian because policy and release management had different goals than the users who needed them.
<mako> mdke: CRAZY
<Amaranth> and anyone using backports is probably using a cvs version of gnome-menus
<mdke> mako, you chairing?
<Amaranth> of course, that was my fault so i'll hide now
<mako> mdke: i can
<mdke> mako, bring your cattle prod
<mako> mdke: charing IRC meetings can be tough
<mako> i have a little bit of practice
<mdke> i bet
<mako> -v 
<dieman> thats what +m is for, at worst
<bob2> mako has some experience chairing, them too
<fabbione> ogra: i partially agree, but the recent backports have fucked up security updates for users
<mako> bob2: actually, mostly charing
<fabbione> ogra: so i am not generally happy about them
<ogra> fabbione, if it would be  only that....
<mdke> from a philosophical point of view, backports encourage users to adopt the "i must have the latest version, regardless of whether i need it and the disadvantages" attitude
<mako> i *really* think that this is more a matter of the fact taht these guys are almost completely out of touch with what we're doing and how we're doing it
<kent> Cant you talk to the persons responsibel for the backports and make them work better with Ubuntu?
<ogra> fabbione, but coordinated backports fom people that have gone the MOTU way are at least packaged half way sane 
<bob2> kent: they're in their own world
<mako> kent: i just planned that meeting for next wed. :)
<mdke> kent, thats mako's plan
<dieman> hmm
<fabbione> ogra: there are packages that you simply can't backport
<dieman> i should show up, im interested now in hearing the discussion.
<bob2> getting them to usefully participate on the lists would be a good start
<fabbione> ogra: and i am sure they don't even know that
<ogra> fabbione, yep, i know... 
<bob2> and de-gatewaying the forums from the dev list
<mako> i mean, they don't even *know* or standards or why we think they are problematic
<ogra> fabbione, that are the tasks we have to solve with them... 
<mako> they seem to be reasonable people
<mako> we may not get everything we want.. and that's ok
<mdke> why do they make backports?
<mdke> what is the main reason?
<mako> but it's our interests to do this
<mako> mdke: they're young and impatient ;)
<mdke> mako, there must be a better reason
<fabbione> ogra: if i can decide i will put a veto on my packages on backport
<fabbione> or for the matter everything that is in base (see kernel, glibc, gcc-*)
<mako> yes, there is :)
<\sh> mdke: updates, software which will never be included into ubuntu, cause of legal concerns
<mako> \sh: that's only one reason
<mdke> \sh, why the updates tho?
<\sh> mdke: e.g. gaim-1.3.0
<\sh> best example
<mako> mdke: they want things more quickly.. and because they can work within their own repository more easily (they think) than in ours
<mdke> \sh, but hoary gaim is patched right?
<dieman> can the mailing lists be mailed to without being a member?
<\sh> it's not going to be updated for hoary (IMHO) but many users want to have it
<mdke> dieman, depends on the list, usually not
<\sh> mdke: honstly i don't know..I'm using psi :)
<dieman> hmm
<mako> mdke: if we make it easy to work in our repo, make them aware of policy and stuff, i think we'll see this problem sort of go away :)
* dieman likes using gmane.
<dieman> oh well
<bob2> dieman: almost certain they're just moderated for non-subscribers
<mdke> dieman, ah i think you might be able to post from gmane
<dieman> heh
<bob2> dieman: but it's mailman, you can subscribe but elect not to receove any mail
<\sh> mdke: but I think for those reasons backports can be quite usefull, if those guys are applying the same rules like ubuntu official does
<dieman> bob2: ahh, forgot
<mdke> mako, well unless you change the policy of not uploading new packages during a release cycle (!?!) then I imagine there will always be backports
<dieman> bob2: thats what i can do.
<mdke> \sh, i see
<mdke> mako, i love the way you are optimistic about everything
<Nafallo> morning all!
<ogra> fabbione, avoid collisions with essential packages, make sure that package quality is at least not fucking up your system....(and i've seen some of their packages .... they make you cry)
<Burgundavia> mako, I have met one of the backports people, at LFNW after my talk. He is quite a sane person, and would be happy to work within the confines of the official Ubuntu stuff
<ogra> fabbione, i would do too, but if you cant stop them from what they do, embrace them ....
<ogra> and make clear how evil it is to backport certain stuff....
<mako> mdke: that's fine.. but they also do backports in places they dont need to, in ways that make upgrading/maintaince very difficult and are in other ways problematic
<ogra> i.e. i have no objections in sane packaged universe backports....
<mdke> mako, well it will be cool if you can solve that
<mako> mdke: we're not going to get 100%
<mdke> mako, any progress is progress right?
<mako> mdke: but if we can make our life and the life of our users 50% less problematic, that's still a major victory
* mdke nods
<mako> mdke: and i think that if we offer these people a place to do work that is less problematic and some good reasons to do it, they might choose to direct their energy there.. but who knows :)
<fabbione> ogra: well i guess i will formally ask them not to backports the packages i maintain and their build-dep and deps...
<fabbione> ogra: this backport thing today made me lose almost 3 hours to dig in problems that are not even ours...
<fabbione> that's rather annoying
<ogra> fabbione, the initrd ?
<fabbione> since users regret to say that they have backports enabled
<fabbione> ogra: part of it yes...
<ogra> ARGH
<mdke> mako, :)
<bob2> fabbione: always ask for their /etc/apt/sources.list
<bob2> or you find out they installed some random package from debian experimental
<ogra> fabbione, i know how you feel, the only way to get mono in hoary re the backports.... and the packages are nearly the worst i've ever seen....
<fabbione> bob2: that's true, but still.. 
<ogra> bob2, even sid....
<ogra> (in hoary)
<ogra> fabbione, but you cant stop them doing it, we are open source.... so lets see to get some more control t avoid the snafu
<fabbione> ogra: yes.. i am not stopping them.. i will ask politely to stop backporting my packages, their build-dep and depends
<ogra> yep, thats good...
<fabbione> (that hounestly means all of ubuntu != gnome and kde)
<bob2> hah
<fabbione> humpf
<ogra> fabbione, oyoure a MOTU ?
<fabbione> jbailey: the latency problem was nothing to do with my eth0
<fabbione> jbailey: it's a problem with router cpu that overloads when the NAT table is full :/
<fabbione> ogra: uh?
<ogra> fabbione, i would restrict that to main...
<ogra> fabbione, let them play in the universe ;)
<fabbione> ogra: i don't have build-dep in universe :)
<ogra> fabbione, you also said depends ;) 
<\sh> huu? Message-ID: <BAY12-F4CCB660359D8A35D87ADEAD0E0@phx.gbl>
<fabbione> ogra: yeah.. not reverse-depends
<ogra> hehe
<\sh> SuSE has some fixed place from where you can get most of the 
<\sh> packages. This feature is absent in Ubuntu. You need to build your own 
<\sh> sources.list.
<\sh> did i miss something?
<ogra> lol
<Burgundavia> \sh, where is that from?
<Amaranth> dhcp stuff uses dbus now?
<Amaranth> is that for NetworkManager?
* fabbione goes for a smoke
<fabbione> Amaranth: sooner or later the kernel will depends on dbus
<bob2> Amaranth: yes
<fabbione> :)
<Amaranth> fabbione: scary
<\sh> Burgundavia: ubuntu-users ML
<Burgundavia> \sh, yes, I saw it now
<blueyed> The bittorrent tracker is "offline" (again).
<\sh> Burgundavia: answered already ;)
<Burgundavia> mdke, you are wrong about the UK team not need to do translations
<Burgundavia> mdke, there are very active welsh translation teams
<mdke> Burgundavia, argh shit
<Burgundavia> mdke, and gallic
<mdke> need to remedy that
<mdke> thanks
* mdke wipes egg off face
<luis__> and even fairly active british english teams
<luis__> s/color/colour/
<luis__> and such
<mdke> luis__, *rolls eyes*
<luis__> yeah
<luis__> I think it is sort of silly too
<mdke> but i can't believe i overlooked the other UK languages
<luis__> but they get pissy when you say that too their face and/or threaten to take it away :)
* luis__ relurks
<Burgundavia> this is cool http://news.bbc.co.uk/2/hi/uk_news/wales/3975519.stm
<mdke> thanks Burgundavia 
<Burgundavia> mdke, just figured I would point it out
<mdke> Burgundavia, i'll repost but just to the -uk list i think
<mdke> or maybe i should post to the others too
<Burgundavia> mdke, just to the UK and sounder I think
<Burgundavia> maybe users
<mdke> sounder?
<Burgundavia> mdke, the chit chat list
<mdke> i didn't post to that one
<Burgundavia> pretty low volume, you may want to
<omie> did you guys track down the libc6/mkinitrd problem yet
<\sh> http://star-techcentral.com/tech/story.asp?file=/2005/5/24/itfeature/11017020&sec=itfeature good to read (martin taylor, MS GM for platform strategy)
<syndicate> Is anyone working on adding the redhat cluster system and GFS to ubuntu?  If not, who would I talk to if I wanted to start working on it?
<ogra> syndicate, http://udu.wiki.ubuntu.com/ClusterFilesystems
<ogra> syndicate, ;)
<syndicate> sweet
<ogra> syndicate, if you happen to be crazy enough to use breezy, feel free to help testing :)
<syndicate> Yeah, i'm using it now
* Burgundavia kicks seb http://gstreamer.freedesktop.org/releases/gst-plugins/0.8.9.html
<ogra> syndicate, and if you want to help testing, please get in contact with fabbione :)
<syndicate> will do
<ogra> syndicate, great, fabbione will love to hear that :)
<syndicate> Yeah, I love clustering stuff
<syndicate> and I love ubuntu
<syndicate> I feel like a jackass just consuming :)
<ogra> yay, we too 
<syndicate> do you have his email handy?
<kiko> fabbione@canonical.com should work
<syndicate> excellent
<Amaranth> is it sad that i'm installing bits and pieces of KDE just to see smeg load the icons for them correctly?
<\sh> Burgundavia: u read the reply of this guy with the chaos sources.list?
<\sh> btw. a good example how bad backports can be
<Burgundavia> \sh, no, I don't follow users, except on the forum
<Burgundavia> \sh, just saw it now
<Burgundavia> \sh, that is pure insanity
<\sh> Burgundavia: this is bad
<Dilago> hi, How can mount floppy in boot process of Live-CD?
<Dilago> in the first interface of menu debconf ...
<ogra> \sh, but typical
<\sh> ogra: yeah...thats the reason why we need to get the hands on those backporting people ;)
<kiko> guys
<kiko> did hoary support ntfs-resizing?
<Mithrandir> kiko: iirc, yes.
<\sh> ntfs resizing?
<kiko> Mithrandir, how was it accessed in the installer menu?
<Mithrandir> kiko: press enter on the partition and it'll offer to resize, iirc.
<syndicate> truncating and update the tables :D
<kent> whats up with www.ubuntu.com?  Are you chaning the css or something? it looks a bit strange in firefox.
<kent> s/chaning/changing  :)
<kiko> Mithrandir, hmm, no resize option, though you can edit the size. nothing happens when you do that, though.
<Mithrandir> kiko: http://linux-ntfs.sourceforge.net/info/ntfsresize.html 
* mvo is away for a bit
<kiko> huh
<bob2> thom: is libapache-mod-security even useful anymore?
<sladen> lamont: I wrote this a couple of weeks ago;  it may help your live-cd situation on !i386 http://www.paul.sladen.org/ubuntu/e2fszero/e2fs-zero.py
<doko> elmo, Kamion: seb128 and me found one more packages for universe->main: libnautilus-burn2
<Mithrandir> hm, what's the font used in the logo?
<ogra> Mithrandir, i know a very similar one called VAG-Rounded.... but thats a commercial one
* \sh is a mss
<ogra> mss ?
<Mithrandir> ogra: any idea if there's something which won't look too bad together with it?  I just need to add "norge" to the logo for ubuntu-no
<mdke> kent, looks ok here, try shift reloading
<\sh> Most Stupid Supporter
<ogra> Mithrandir, i would take a different one, if you take just a similar one it might look like patchwork
<kent> mdke, it must have been temporary insanity on my side.  It looks ok now :)
<Burgundavia> Mithrandir, the ubuntu logo is hand created, not a font
<mdke> kent, cool. sometimes it has caching problems
<Burgundavia> Mithrandir, I would choose something that fits, but is complementary, but not an exact copy
<lamont> sladen: coolness
<sladen> lamont: would adding an option to copy the blocks to a new file (instead of writing zeros to the existing one) be more useful;  since then the file would be re-sparsed, whereas writing to it means that it'll always get expanded to full size (eg. 3GB, even if only 500MB is in use)
<lamont> today we do a unpack/pack into the same filename (which is a re-write).  I suppose writing to a new file would be better, though.
<omie> did any one figure out how libc6 2.3.5 ends up getting into hoary?
<omie> someone was saying backports and breezy, but we have a machine here that supposedly hasn't touched backports or breezy and it's got ld-2.3.5.so
<Mithrandir> smurfix: who is responsible for ubuntu-fr.org?  Can I rip the look off them or whom should I ask for permission?
<smurfix> I'd assume that David is (or knows) that person
<Mithrandir> smurfix: which David?
<smurfix> The one whose name is next to "FrenchTeam" on the LoCoTeamList wiki page. ;-)
<smurfix> Mithrandir:  david@ubuntu-fr.org
<Mithrandir> smurfix: cheers, thanks.
<mdke> smurfix, y0
<mdke> smurfix, what was the issue john levin was hinting at re: GB/UK?
<thom> uk is the iso code for ukraine, among other things
<smurfix> thom: No, the Ukraine is .ua
<Mithrandir> thom: the language code for Ukrainian, but the country code for the great britain.
<Mithrandir> great, isn't it?
<mdke> http://www.bcpl.net/~j1m5path/isocodes.html
<smurfix> The country is "Great Britain and Northern Ireland"
<thom> Mithrandir: thanks, is what i meant
<smurfix> so, .gb, being Great Britain, technically does not include Northern Ireland
<mdke> smurfix, yeah
<mdke> smurfix, which was why we preferred uk, but he suggested there was a good reason to go with gb?
<smurfix> Yeah, because the official country code *still* is .gb, and that's where he lives in ;-)
<mdke> confusing stuff
<smurfix> I'm going to compromise by allowing both, and strongly suggest to people to be somewhat consistent
<mdke> i have always used/heard united kingdom
<\sh> laters gentlemen
<Burgundavia> Mithrandir, ubuntu-ca has already ripped off their look with permission
<mdke> ca is another confusing one :/ *scratches head*
<smurfix> mdke: You just need to state what you're talking about... reallanguage example: what's a "wing"?
<Burgundavia> smurfix, dead chicken, thing on a plane
<mdke> or bird's wing
<smurfix> part of a building, part of a window
<Burgundavia> that to
<mdke> yeah all those
<mdke> although haven't heard the window one ;)
<Burgundavia> not part of a window, not in Canada
<Burgundavia> mdke, ca is the catalan lang code, but the Canadian country code
<smurfix> I've heard it. It's quite common usage in German
<mdke> Burgundavia, yeah thats what i mean
<mdke> german words don't count :p
<smurfix> So in the context of any given conversation that word is not ambiguous at all, and neither is "ca". Mostly. ;-)
* mdke nods
<ogra> mdke, they do: eins zwei drei ;)
<Burgundavia> in the context of ubuntu-ca, it is ambigous
<mdke> ogra, omg i just got that
<mdke> that's terrible
<ogra> heh
<ogra> but they count ;)
<mdke> you're just making it worse for yourself
* mdke checks the EC treaty for the official name of his country
<smurfix> Burgundavia: Possibly -- if it ever becomes an issue, we'll use three-letter language codes.
<Burgundavia> yes
<Mithrandir> *sigh*; why doesn't gimp have a "scale down and save a copy as?"
<mdke> smurfix, apparently our official name is "the united kingdom of great britain and northern island" ;) go figure
<Nafallo> tukogbani :-)
<smurfix> Mithrandir: so write a script ...
<ogra> Mithrandir, for mass resizig gthumb has some options
<Mithrandir> ogra: I'm not interested in mass resizing, I'm interested in working in high-res, but exporting to web-quality.
<ogra> ah
<Mithrandir> ogra: but thanks anyhow. :)
<\sh> time to go to bed :(
<uniq> gnite \sh.
<mvo> night \sh 
<ogra> night \sh 
#ubuntu-devel 2005-06-02
<ajmitch> morning
<uniq> gnite.
<uniq> :)
<mvo> hey koke 
<koke> hi!
<Burgundavia> kiko, ping
<kiko> Burgundavia, pong
<kiko> how may I be of assistance
<tseng> is rob.weir@c.com a valid pointer for bob2 ?
<thom> tseng: yes
<tseng> rock on
<ogra> c.com ?
<Burgundavia> kiko, #launchpad regarding malone bug 795
<ogra> ah
* mvo goes to bed now
<thom> u.com should also work
<ogra> night mv
<ogra> o
<mvo> :)
<Keybuk> man, Foster's _really_ need to sack their marketing department
<Keybuk> they've followed up on their spectacular UK campaign of "Brewed to taste better cold"
<thom> they have new ads?
<Keybuk> with the utterly jawdropping "You wouldn't want your beer to be warm, would you?"
<thom> way to play to silly .au prejudice
<tseng> omfg osnews
<tseng> "mono is to become key component of gnome 3"
<tseng> "read interview iwth miguel for proof"
<ajmitch> haha
<ajmitch> an interview dated 2003?
<tseng> if that isnt flamebait
<tseng> no actually.. its miguels blog
<tseng> even better
<ajmitch> osnews has dropped a lot in quality..
<ajmitch> and it was never very high to start with
<tseng> He also has the powers in achieving this goal. Novell is stronger and has more power than Red Hat or Sun and Novell are the legal owner of GNOME.
<tseng> wow
<ajmitch> I think that's one of the usual trolls on osnews
<Burgundavia> ajmitch, I think it was the "news" part of the title that fooled people that it actually was, as opposed to /. which has never really pretended to be a "news" site
<Burgundavia> tseng, I love the assertion Novell > Sun. Sun could swallow Novell tomorrow and not really notice
<tseng> yeah
<tseng> i dont see novell moving >1mil products
<Burgundavia> there was some scuttlebutt about them actually doing it
<tseng> there is that for everything
<tseng> thanks to slashdot and osnews
<Unfrgiven> good morning all
<tseng> hi
<Burgundavia> sometimes scuttlebutt has a way of being true
<ogra> oh, novell owns a dwarf ? i didnt know that
<ogra> but i doubt its legal to own dwarfs :)
<tseng> only if there are 42 of them
<tseng> and you are in cambodia
<ogra> heh
<ajmitch> morning Unfrgiven 
<Unfrgiven> ughh im so tired this morning
<ogra> the real question here is, do they also own snow white and is _this_ legal
<Unfrgiven> anyways... im wanting to get involved in the cxx transition... now i've tried reading the wiki pages but had some questions...
<tseng> ask ajmitch :)
<ogra> Unfrgiven, ask ajmitch 
<ogra> :)
<Unfrgiven> ajmitch: is it just a case of us providing patches for libs to build on gcc4?
<Unfrgiven> ajmitch: and then repackaging them?
<ajmitch> Unfrgiven: usually it's just changing the package name, sometimes patching, making sure it all builds nicely & getting past the ogra/doko filter ;)
<ajmitch> ogra: nice delegation there :P
<ogra> hehe
<ajmitch> ah, 'experimental for Ubuntu' :)
<ogra> ajmitch, you said i steal all your packages... so i thought i'd give something back ;)
<Burgundavia> figure this is a dmix bug? https://bugzilla.ubuntu.com/show_bug.cgi?id=11190
<mdz> jbailey: around?
<ajmitch> ogra: I never said such a thing..
<ajmitch> honest
<ogra> hmm
<Unfrgiven> ajmitch: cool. ill try and take a look at some packages later today
<Unfrgiven> tseng: who did you talk to to get your blog syndicated on planet ubuntu?
<tseng> Unfrgiven: mail your rss feed and hackergotchi to jdub
<ajmitch> Unfrgiven: check the list for packages that haven't been taken yet
<ajmitch> CxxLibraryList, that is
<ajmitch> instructions are there & on BreezyToolchainTransition, i think
<Unfrgiven> tseng: hmmm i dont have a hackergotchi yet... does it have to be a specific format/size?
<tseng> no
<tseng> its optional
<ajmitch> we can probably find a photo of you somewhere
<Unfrgiven> ajmitch: ok will do. i have training to attend at work in 10 min. so i'll prolly check it out later in the day
<Unfrgiven> ajmitch: oh ive got a photo so thats not a prob...
<ajmitch> it's more fun if we select one :)
<Unfrgiven> ajmitch: hence why i quickly added that i'll provide one :P
<bluefoxicy> back on hoary
<bluefoxicy> since breezy /usr/X11R6/bin/Xorg -> ../../X11R6/Xorg
<bluefoxicy> (symlink)
<trulux> ajmitch: there?
<ajmitch> yes?
<trulux> ajmitch: another red cow crack today. vsec fixed though and I'm getting skilled with the policy language
<ajmitch> ok..
<trulux> expect the targeted policy to be ready in a rush
<ajmitch> ok
* ajmitch is just heading out now
<ajmitch> bbl
<trulux> ajmitch: it's 2:00am here, I can't do what I did yesterday
<trulux> need to go to bed soon
<trulux> ajmitch: this the asspain anti-crack: -EXPORT_SYMBOL(in6addr_any);
<trulux> -EXPORT_SYMBOL(in6addr_loopback);
<trulux> I will do a dirty trick
<trulux> and tell pitti that it works fine on 2.6.12-rc5
<trulux> ajmitch: I dunno why they are on that fever of removing exported symbols
<trulux> dilinger: there for a while?
<trulux> const struct in6_addr in6addr_loopback = IN6ADDR_LOOPBACK_INIT;
<trulux> and then define the macro
<trulux> shit... this is the worst trick I've done in my life :)
<trulux> zul: heya
<trulux> aj: ping
<trulux> arg
<trulux> ajmitch: ping
<trulux>   CC [M]   /home/lorenzo/kernel/tmp/vsecurity/src/vsec_params.o
<trulux>   CC [M]   /home/lorenzo/kernel/tmp/vsecurity/src/vsec_funcs.o
<trulux>   CC [M]   /home/lorenzo/kernel/tmp/vsecurity/src/vsec_acl.o
<trulux>   CC [M]   /home/lorenzo/kernel/tmp/vsecurity/src/vsec_fs.o
<trulux>   CC [M]   /home/lorenzo/kernel/tmp/vsecurity/src/vsec_bsdjail.o
<trulux>   CC [M]   /home/lorenzo/kernel/tmp/vsecurity/src/vsec_hooks.o
<trulux>   CC [M]   /home/lorenzo/kernel/tmp/vsecurity/src/vsecurity.o
<trulux>   LD [M]   /home/lorenzo/kernel/tmp/vsecurity/vsecurity.o
<trulux>   Building modules, stage 2.
<trulux>   MODPOST
<trulux>   CC      /home/lorenzo/kernel/tmp/vsecurity/vsecurity.mod.o
<trulux>   LD [M]   /home/lorenzo/kernel/tmp/vsecurity/vsecurity.ko
<trulux> make[1] : Leaving directory `/home/lorenzo/kernel/linux-2.6.12-rc5'
<trulux> cc     testing/server_bind.c   -o testing/server_bind
<trulux> cc     testing/test-rlimits.c   -o testing/test-rlimits
<trulux> renbukai today
<trulux> :)
<trulux> now, bed time
<trulux> good night fellows
* lamont wanders off for a while
<jbailey> mdz: Am now for a moment, I'll be back in an hour or so though...
<mdz> jbailey: ping me when you're back and have some time for a phone call
<jsgotangco> morning :)
<tseng> hi.
<jsgotangco> tseng, that mono live cd is awesome crack just tried it
<tseng> jsgotangco: sweet
<tseng> its fun, a nice preview of my stuff for breezy
<tseng> for the impatient
<jsgotangco> yeah i was playing around with beagle
<tseng> how well does it perform on the cd?
<tseng> im worried about that
<jsgotangco> sure its not that fast but its tolerable
<tseng> k
<bluefoxicy> tseng:  does breezy break for you?
<bluefoxicy> Xorg's executable is a symlink to itself
<tseng> #ubuntu
<bluefoxicy> breezy broken bugs dammit, how is that user support and not development?
* bluefoxicy shrugs and just shuts up and eats his whopper
<tseng> everyone but you knows breezy is broken
* mode/#ubuntu-devel [+o daniels]  by ChanServ
<lifeless> daniels: you made xorg self referential ? lol
<tseng> if you want to cry about it, go to #ubuntu
* mode/#ubuntu-devel [-o daniels]  by daniels
<daniels> argh
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [+b *!*bluefox@*.whtmrs01.md.comcast.net]  by daniels
<daniels> second time lucky
* mode/#ubuntu-devel [-o daniels]  by daniels
<tseng> harsh
<tseng> i like it.
<lifeless> what does that do ?
<daniels> bluefoxicy: broken 'workarounds' bite you in the butt, news at 11.  it's still not #u-d material.
<lifeless> daniels: what does that mode line do ?
<daniels> what modeline?
<lifeless> daniels: 11:39 -!- mode/#ubuntu-devel [+b *!*bluefox@*.whtmrs01.md.comcast.net]  by daniels
<tseng> ban
<tseng> which has the side effect of him being silenced
<lifeless> even though hes still in channel .. ?
<jsgotangco> heh
<ajmitch> quite convenient at times
<tseng> yes.
<daniels> my tolerance ran out last week
<jsgotangco> he can bug you with pm though
<jsgotangco> in other news, i decidedto start saving for a n770
<jblack> Hey guys. WHat's up? 
<ajmitch> hi jblack 
<jsgotangco> jblack, hey its been a while how are you
<jblack> Pretty good. 
<jblack> How about you guys? 
<ajmitch> still alive
<jblack> Heh. Life is the stuff that ain't killed you yet? 
<jsgotangco> not bad im doing good lately
<jblack> I've got a bit of an ambigious question. I'm not exactly sure what I'm asking, and I don't know what kind of answer you'll give, so bear with me.
<jblack> Right now the baz team is doing these things called "imports". We're importing things into the launchpad that primarily have cvs and subversion sources, and spitting out baz archives on the other side.
<jblack> lifeless tells me that you guys are very good at hunting down these repositories very quickly. I was wondering what sort of rules of thumb you guys have come up with to do this sort of thing in an efficient manner.
<tseng> the upstream repositories?
<jblack> Yeah. hunting down cvs archives and subversion archives for those packages.
<tseng> for bigger stuff we probably just have an idea whether it is hosted by gnome, sourceforge etc
<tseng> and can go to the right place and do a quick search
<tseng> if not there is usually relevant info on the app homepage
<jblack> How do you generally quickly tell the different between whether something is part of gnome, or happens to run on it? 
<tseng> just previous knowledge really
<lifeless> tseng: what about the path binary package -> who the upstream reall is
<tseng> apt-get source and read copyright
<lifeless> tseng: theres a bunch of assumed knowledge you have ..
<tseng> will point you to the homepage
<tseng> even better..
<tseng> qa.debian.org
<lifeless> tseng: which jblack doesn't - which is why I have pointed him to you
<tseng> lemme try one
<jblack> some random package... 
<tseng> im going to do mono, since i know where it is
<jblack> Mono is good. 
<tseng> then ill walk you though if this works as expected
<jblack> though I know that one is gnome. 
<tseng> eh sortof
<tseng> has its own svn
<jblack> its not? 
* jblack bawls
<tseng> ok dude lets see if this is an acceptably pain-free proceedure
<tseng> bring up packages.ubuntu.com
<jblack> check.
<tseng> search for mono with distribution of breezy or hoary even
<tseng> under the obvious Search heading
<tseng> the page that comes up has a ton of stuff, most are all in the single "mono" source
<tseng> you can search just source packages also
<tseng> anyway, click libmono0 or something
<tseng> the link says breezy
<tseng> this page has a link to the copyright file
<jblack> desync
<jblack> Never mind. 
<tseng> which by policy always has a link to the package download page
<jblack> ok. viewing copyright file.
<tseng> which for lack of a more direct path..
<tseng> should eventually lead you to some svn/cvs page
<tseng> looking around
<jblack> Cool. This is useful.
<Burgundavia> where does pitti keep his list of vunerablities?
<dilinger> people.ubuntu.com/~pitti?
<jblack> so, here we've got about 10 mono packages created out of one authoritive source. 
<tseng> jblack: that wont always land you exactly in the right place
<jblack> give or take a dozen.
<tseng> but its close
<tseng> it could be that google gets you there faster if you have a good idea what you are looking for
<tseng> jdub: yep.
<tseng> er, jblack
<tseng> google for "mono svn" gets you there in less clicks, in this particular case
<jblack> Yeah. google problably works better for obviously huge. 
<tseng> yep
<jblack> Then again, obviously huge stuff is generally well documented.
<tseng> but good to know where to get it if all else fails, I guess
<tseng> i hope that helps some..
<jblack> Yeah, it helps some, though it's reopened a question that I've been trying to ignore.
<tseng> btw is there any plans to baz mirror svn.debian.org projects
<jblack> multiple products that are derived from the same repository. 
<tseng> hm multiple .debs, yes
<tseng> actually I can make it worse
<jblack> please do. I'm a masochist.
<tseng> pkg-mono repository on svn.debian.org has several directories, each of which representing a source package
<tseng> almost all of them representing several resultant .debs
<jblack> but svn.debian.org isn't authoritive for things like mono, correct? 
<tseng> no, its only the packaging bits
<jblack> The deb dirs and such.
<tseng> right
<jblack> Hold on. I need to check something quick.
<jblack> Ok. I'm not authoritive on this, but I believe we're sticking with authoritive product stuff
<tseng> ok..
<lifeless> we are importing upstream
<lifeless> tseng: ^^
<tseng> i thought part of HCT was importing other vendors as well
<tseng> thats fine, is there a simple tla newbie proceedure that i could do it for myself?
<jblack> Yeah. Thats what I mean. the authentic sources. 
<jblack> There's a public cscvs available, but it only works for cvs and its not as smart as it could be.
<jblack> tseng. Thanks for the advice. it'll help a bit. 
<ajmitch> baz seems to be fairly easy to use, for the basics at least
<tseng> jblack: great.
<jblack> One of the big problems I've had dealing with is linking up a package name with what you guys think the authoritive source is. 
<tseng> apt-get source binary-name will fetch the source that is associated with it
<tseng> if you cant guess from packages.u.c
<tseng> let me try this search agian
<jblack> I tried that a few times. Ironically more than one package out there didn't seem to have a web address at all. 
<tseng> yeah thats no good
<jblack> Just magically showed up in debian. 
<tseng> it cant search a binary down to a source name on the page
<ajmitch> unfortunately, it gets a bit hard to track down upstream when we have to hunt for patches on mailing lists
<jblack> No. I mean in the downloaded sources. 
<tseng> jblack: yeah definately check the copyright in those odd cases
<tseng> its policy for the url to be there
<ajmitch> debian/copyright is usually the best way, followed by google
<tseng> ajmitch: i just showed him to grab the copyright off packages.ubuntu.com to save the hassle of grabbing the whole source where he doesnt want it
<tseng> any other hot tips?
<ajmitch> none that I can think of at the moment
<tseng> ajmitch: man, it would be really nice to be able to work with pkg-mono in bazaar
<tseng> maybe its just because i dont know how to use svn
<tseng> but im basically editing over top of the repo
<tseng> and readding stuff by hand after checking out new stuff
<jblack> Thanks for the help guys.
<tseng> nps
<ajmitch> yeah I've started throwing all my selinux stuff in bazaar
<tseng> rock on
<tseng> how is tla-buildpackage?
<ajmitch> haven't tried it yet
<tseng> i could import the tree as it is now
<tseng> and make two branches
<tseng> make my changes in one
<tseng> import meebeys latest into another
<tseng> and merge
<tseng> or just go to sleep.. cya :)
<ajmitch> night
<jblack> Ok. Here's a good example. 
<jblack> mdz gave baz a list of packages that have been modified by ubuntu (that seems like a good list to work from). One of them is "anna".
<jblack> There's a svn for it, but its svn.debian.org, which I might or might not be able to trust as the authentic source. 
<Burgundavia> who handles gksu stuff?
<crimsun> MOM does, but I guess seb mainly
<crimsun> (not merge but maintainers)
<Burgundavia> he is not likely to be up either
<robitaille> jdub,  ping
<jdub> robitaille: pong
<robitaille> jdub,  it seems the ubuntu-ca mailing list administrator (alex combas) hasn't been seen online in a couple of weeks and right now someone cannot send any e-mails to our list.  So it has been suggested that I become a 2nd mailing list adminstrator to deal for problems like that while Alex is missing in action.  Is that possible?
<jdub> robitaille: sure, preferred email address?
<robitaille> robitaille@gmail.com  (I should really ask for my ubuntu.com address one of these days)
<robitaille> thanks
<jdub> hrm
<jdub> broken mailman
<Burgundavia> robitaille, shall we tack me on there as well, just in case?
<robitaille> Burgundavia,  if you want; it's fine with me.
<jdub> ah crap
<robitaille> Burgundavia,  it seems both our names keep coming back as "stable" members of the canadian community
<Burgundavia> yes
<robitaille> crap == problem?
<Burgundavia> and we have never jumped up and down and asked for it
<jdub> do you want to both be on?
<Burgundavia> yes
<jdub> preferred email address?
<Burgundavia> corey.burger@gmail.com
<jsgotangco> who do you ask for an ubuntu.com address?
<ajmitch> afaik it's not sorted just yet
<jsgotangco> (no rush anyway)
* ajmitch wants one as well, as do a few of the MOTUs :)
<jsgotangco> heh
<ajmitch> I missed out on asking about business cards
* ajmitch will bbl
<daniels> ajmitch: bradb will give you some
<lifeless> some hundreds
* jsgotangco too - lunch
<Burgundavia> jdub, poing
<WebWiz> anybody here use ruby?
<srbaker> WebWiz, yep
<srbaker> religiously
<srbaker> religously
<srbaker> or something.
<srbaker> very lots.
<srbaker> :)
<WebWiz> HelloWorld.rb:1:in `require': No such file to load -- gtk (LoadError)
<WebWiz> i am getting this in ubuntu
<srbaker> inst the ruby gtk bindings
<WebWiz> i thought i did....
<srbaker> dpkg -l |grep ruby |grep gtk
<WebWiz> ii  libgtk-ruby1.6 0.34-1         Gtk+ interface for Ruby
<WebWiz> ii  libgtk2-ruby   0.11.0-1ubuntu GTK+ bindings for the Ruby language
<WebWiz> did that help?
<WebWiz> lol
<srbaker> weird
<srbaker> paste line 1 of HellowWorld.rb
<WebWiz> require 'gtk'
<srbaker> huh
<WebWiz> hrm?
<srbaker> jussec
<srbaker> lemme try
<WebWiz> k
<srbaker> try require 'gtk2'
<srbaker> i bet 'gtk' works if you use ruby1.6
<WebWiz> HelloWorld.rb:3: uninitialized constant Gtk::WINDOW_TOPLEVEL (NameError)
<srbaker> hu
<WebWiz> hah at least i got farther
<srbaker> i don't know any more.
<srbaker> :P
<WebWiz> srbaker, you are totally correct
<WebWiz> ruby1.6 HelloWorld.by brought up my window fine
<WebWiz> using 'gtk'
<WebWiz> Thanks! :)
<srbaker> i would grab gtk1 for ruby1.8
<mako> ddd
<jsgotangco> hi mako
<mako> yeah, didn't meant to do that
<mako> i am about to crash :)
<mako> was just connecting to sync mail and sent off the next batch of cds to the shipping folks
<jsgotangco> hmmm right its probably 2am there now
<Burgundavia> daniels, dkpg-reconfigure xserver-xorg is currently producing gibbled xorg.confs, but unknown whether it is user error or not
<daniels> Burgundavia: wrt mouse settings, yeah
<Burgundavia> ok
<Burgundavia> that was the error I got
<Burgundavia> there is another small bug, to do with screen res sizes
<Burgundavia> seen that?
<daniels> yeah, with intel?
<Burgundavia> nope
<Burgundavia> ati
<daniels> cool
<daniels> url?
<Burgundavia> just a sec, my screen res went messed with that game
<Burgundavia> it adds "640x350" to all the monitor sections, when that is not a choosable option
<Burgundavia> this one maybe user error
<daniels> i'm thinking user error
<Burgundavia> hmm, I choose all defaults
<Burgundavia> hmm, anyway, not a huge bug
<daniels> grepping for 350 over the entire xorg debian dir produces nothing useful
<Burgundavia> hmm, odd little bug
<Burgundavia> whatever, I will try some reconfigures again, and if it comes up again, I will file a bug
<pitti> Morning
<mdz> pitti: morning
<pitti> Hi mdz
<fabbione> hey mdz
<fabbione> morning pitti
<mdz> fabbione: morning
<fabbione> mdz: got my email yesterady?
<mdz> fabbione: intel?  yes, thank you very much
<fabbione> mdz: no problem :) that was easy
<Treenaks> pitti: g-v-m asks for a passphrase now!
<Treenaks> pitti: but it doesn't seem to work :(
<Treenaks> pitti: (morning, btw)
<pitti> Treenaks: will look at it later, gimme some minutes please
<Treenaks> pitti: of couse
<Treenaks> +r
<ajmitch> hi pitti 
<fabbione> mdz: are you busy? or are you going to sleep soon?
<mdz> fabbione: yes and yes, why?
<mdz> fabbione: if you have some time, I would like to schedule a phone call with you
<mdz> tonight or tomorrow
<fabbione> mdz: well if you have a few minutes i would like to talk with you about ClusterFileSystem
<mdz> (UTC-7)
<fabbione> mdz: sure even now
<mdz> fabbione: not yet, perhaps in 30-45 min?
<fabbione> mdz: sure
<fabbione> works for me
<mdz> we will see if I can stay awake
<fabbione> mdz: this evening should be ok'ish
<fabbione> it depends from the time because we have guests at home
<mdz> fabbione: if we don't talk before I sleep, let me know what time would be good to talk tomorrow
* fabbione thinks...
<fabbione> mdz: even today after 19:00 UTC is fine
<mdz> ok
<fabbione> guests here tend to go away early in the evening :)
<fabbione> otherwise tomorrow after 05:00 UTC is fine
<fabbione> or now if you don't fall asleep :)
<fabbione> whatever you prefer is ok with me
<pitti> Treenaks: ok, can you check with "killall gnome-volume-manager; gnome-volume-manager" in a shell?
<jdub> mdz: meeting about backports?
<mdz> jdub: isn't that in like 9 hours?
<jdub> mdz: no idea, just wondering wtf ;)
<mdz> oh, you were responding to my mail
<mdz> yeah, mako is setting it up
<jdub> yeah
<mdz> next wednesday actually
<jdub> i guess sane backports are better than insane backports
<mdz> yep
<jdub> but it still makes me cry
<mdz> jdub: next wednesday, directly after the staff meeting, if memory serves
<mdz> I think we can twist backports into something sane
<Treenaks> pitti: I rebooted..
<Treenaks> pitti: that didn't work
<pitti> Treenaks: no, it can't; I'm interested in the g-v-m debugging messages; let's continue this in /query
<haggai> pitti: hmm, now I'm glad we ended up without cdrdao in main for hoary ;)
<pitti> haggai: does it have issues?
<haggai> pitti: yup, http://www.mandriva.com/security/advisories?name=MDKSA-2005:089
<pitti> haggai: uh, CAN-2002-*? that's stone old
<Treenaks> pitti: oh, one more small thing:
<Treenaks> ** (gnome-cups-icon:7940): WARNING **: IPP request failed with status 1030
<Treenaks> pitti: multiply that by 600.000 and you have my .xsession-errors :)
<pitti> haggai: our cdrdao isn't setuid root, so actually only the symlink race remains
<haggai> pitti: ah, not so bad then
<trulux> pitti: did you got the email?
<trulux> bbl, class
<pitti> trulux: yes, will try soon
<tepsipakki> do you know if g-v-m etc handles automagic mounts CF etc cards plugged on a USB card reader?
<tepsipakki> automagic mounts _of_ CF cards...
<tepsipakki> plugging one doesn't generate any events, as far as I know..
<Mithrandir> tepsipakki: if it doesn't generate any events, it's kinda hard to do.
<doko> Kamion, elmo: please move these packages from universe to main: libqscintilla5c2 libenchant1c2 libnautilus-burn2 libconvert-binhex-perl (needed for libmime-perl) xpdf-utils (needed to build kdegraphics)
<bob2> tepsipakki: works for me.
<bob2> for memory stick, anyway
<Mithrandir> didn't we just get rid of xpdf for main?
<Mithrandir> bob2: it depends on the reader.  Cheap readers often don't generate any fluffy events when you insert and pull out the card.
<bob2> ah
<bob2> guess I got lucky, mine was cheap (they only seem to sell cheap ones here)
<tepsipakki> the kernel lists this 4-in-1 reader as scsi-disks
<tepsipakki> made by Apacer
<Treenaks> tepsipakki: you're lucky. My built-in cardreader is some weird TI device (which, according to the docs should be in "ATA Compatible Mode")
<Treenaks> tepsipakki: but it doesn;t work at all
<tepsipakki> well, I haven't tested the functionality at all, yet. All I know is that they are a pain in the a**, because if they break, the kernel (2.4 at least) doesn't boot
<tepsipakki> hangs when trying to access it or something
<tepsipakki> there _really_ is no free lunch
<tepsipakki> and right now I got fed up with ircii
<tepsipakki> I'll try and debconfify it
<Treenaks> tepsipakki: I have a 6-in-1 USB cardreader which works fine
<jsgotangco> same here
<jsgotangco> mine is by TwinMOS andworks greate
<tepsipakki> these apacer-thingies just tend to break often
<jsgotangco> although i got to loan one cardreader that didnt work at all
<Treenaks> mine's made of metal :)
<Treenaks> probably a thin layer of cheap aluminium, but hey, it's metal!
<jsgotangco> still made in Taiwan heh
<tepsipakki> hmm, this is 8-in-1 maybe, but has only four slots (ER151)
<tepsipakki> and the front panel is definately plastic ;)
<bob2> hm
<bob2> the installer doesn't seem to let me use a different mirror for the base system to the installer stuff
<tepsipakki> bob2: it might be hairy
<tepsipakki> are you preseeding it?
<bob2> no
<tepsipakki> oh, ok
<bob2> I probably should
<bob2> but there's the fight between being lazy now vs being lazy later
<herzi> doko: ping
<doko> herzi: ?
<herzi> doko: did you have time to take a look at the gdb-powerpc problem?
<doko> herzi: sorry, no.
<bob2> new personal best for install a linux machine
<hunger_> Any chance of seeing gcc4-compiled libboost soon?
<pitti> elmo: mc sync, please
<doko> herzi: thanks for the attachment
* fabbione is puzzled by the rhcluster suite
<fabbione> i need an opinion...
<doko> elmo: please sync bash from unstable
<fabbione> should we build all the suite from one single source package
<fabbione> or 20 small little tiny bits and pieces?
<herzi> doko: np, that's just for by pleasure (as I need this -- I'm using a 6 month old sarge package for gdb as this version worked)
<daniels> fabbione: little tiny bits and pieces
<fabbione> daniels: it's not 200MB.. it more like less than 2MB
<daniels> oh
<fabbione> daniels: it's a bit of overhead both ways
<daniels> single
<fabbione> that's why
<jdub> heh
<jdub> weird
<fabbione> jdub: if that was the only problem...
<fabbione> right now out of this 20 bits and pieces
<fabbione> 5 of them needs to come from the FC4 branch
<fabbione> 3 from  HEAD
<fabbione> others from RH4L branch
<fabbione> it's a ROYAL mess
<jsgotangco> brb
<hunger> Sorry, libboost is already available compiled by gcc4... I checked a lib that was not yet updated before asking:-)
<Kamion> jblack: for anna, svn.debian.org is the authoritative source, yes; anna is a debian-installer component.
<thesaltydog> Kamion, I'm back. Sorry
<Kamion> thesaltydog: ok, but it's you who wanted to ask me a question, so go ahead :)
<seb128> daniels: any idea on when will the build/path issues be fixed?
<thesaltydog> Kamion, yes sorry, but I am at work and I was called outside. Here I am, so...
<seb128> daniels: nm :)
<thesaltydog> the matter is ubm, or what it will be.
<thesaltydog> I have added a deafult "novice" view, very much simpler than the others. Expert views are always reachable by clicking on tabs.
<daniels> seb128: NEVAH
<seb128> daniels: and the xkb issues? 
<seb128> should I upgrade and start pissing owen to know if he has an idea on this? :)
<Kamion> thesaltydog: um, OK, I'd rather not be your permanent contact within Ubuntu for this, I was just chiming in with a couple of points earlier
<thesaltydog> Kamion, can I come back on the "name" issue?
<daniels> seb128: don't bother Owen, it's actually an XKB issue
<daniels> seb128: the symlink has been working fine for me so far
<Kamion> like I say, read the BrandingForDerivatives spec and you'll understand where we're coming from on that
<seb128> daniels: what symlink?
<thesaltydog> Kamion, yes I know, but as last night you pointed out a couple of issues... I don't know I have to refer to..
<Kamion> I don't see a problem with "ubm" though
<thesaltydog> Kamion, didn't you say maybe to change name Ubuntu BottUp Manager? If no, I will happily leave it as it is..
<daniels> seb128: /usr/lib/X11/xkb as a symlink to /etc/X11/xkb
<seb128> daniels: k, thanks
<Kamion> thesaltydog: I asked if you'd consider having a different name appear in users' menus
<\sh> morning
<pitti> Hey ogra
<pitti> (s)
<doko> Kamion, ogra: bash-3.0-15 should fix the waitpid problem
<Kamion> doko: cool, thanks
<doko> Kamion: any news on the packages needing main love?
<seb128> pitti: 
<seb128> sound-properties-capplet.o(.text+0x194): In function `get_soundcards':
<seb128> : undefined reference to `snd_card_next'
<seb128> etc
<seb128> your g-c-c upload
<pitti> seb128: uh, isn't it linked to libasound.so?
<pitti> for me it is
<seb128> that's buildd not happy
<seb128> I've not tried to figure what's wrong
<pitti> ok, will do soon
<pitti> *sigh*
<seb128> it doesnt -lasound
<pitti> hmm? odd, worked for me (dh_shlibdeps)
<ogra> doko, yay
<zul> hey
<pitti> Hi zul, how is it going
<zul> better...im not throwing up anymore
<Kamion> doko: libqscintilla5c2 doesn't seem to be on the list for promotion; done libenchant1c2, libnautilus-burn2, libconvert-binhex-perl as obvious; skipping xpdf-utils because we're trying to get rid of xpdf from breezy/main
<Kamion> elmo: ^--
<Kamion> elmo: is hilarie safe to run, to fix up cross-component symlinks? (libconvert-binhex-perl)
<doko> Riddell, Kamion: xpdf-utils is a build-dependency of kdegraphics, so it currently hurts the KDE C++ transition a bit ... Riddell, amu: could you check, if it's needed?
<Unfrgiven> elmo: ping?
<daniels> doko: it's probably for kpdf
<daniels> which should be using poppler these days
<Kamion> doko: it's in hoary/universe, although I don't quite understand why, as it was on the Kubuntu release CDs
<Kamion> looks like a mistake
<Kamion> not something I have any intention of touching, though - leaving to elmo
<seb128> poppler is the way to go for sure
<Treenaks> they'll want qoppler of koppler or something
<doko> Kamion: libqscintilla-dev comes in/is as a build dependency of python-qt3
<seb128> libpoppler0-qt probably for kde
<tepsipakki> what's up with rhythmbox.. I can pause once, the next time it hangs
<Kamion> doko: yes, and python-qt3 is currently on the list for demotion to universe
<\sh> if u guys say xorg+kde is working  niceley, i will start with pyqt and pykde any the rest
<\sh> s/any/and/
<Kamion> doko: nothing in main depends on it (there are suggests, but no depends); if it's needed, somebody needs to change the seeds
<tepsipakki> ok, it's not rhythmbox, because the version in hoary hangs too. maybe gstreamer
<Treenaks> tepsipakki: gdb it..
<Treenaks> (build a debug version, gdb it)
<trulux> back
<tepsipakki> treenaks: no time ;) downgrading gstreamer helped
<pitti> seb128: ah, now I see, that wasn't from your system, but from the build log
<seb128> pitti: when I say "buildd is not happy", that's no my box, no :)
<pitti> seb128: sorry, I didn't pay close attention, was overly busy with sth else
<seb128> np
<trulux> pitti: heya fellow
<pitti> hi trulux 
<trulux> fabbione: argh, capabilities=m in Breezy's kernel
<trulux> fabbione: that shouldn't be built-in
<trulux> pitti: how' it going?
<pitti> trulux: what's wrong with that?
<fabbione> trulux: no. there is absolutely no problem with cap=m
<trulux> fabbione: OK, then other LSM modules will suck without appending a proper line to the kernel command line
<trulux> I think it was capability.disable=1 but I have NFC right now
<trulux> fabbione: what problem?
<trulux> the no-modularized-caps FUD?
<Riddell> doko: investigating kdegraphics and xpdf
<trulux> symbols are still exported
<trulux> I can corrupt it anyways, either built-in or modularized
<Riddell> \sh: kdelibs should be fine so you can work on pykde and pyqt
<fabbione> trulux: so what is the problem? module is fine :)
<trulux> fabbione: then why they're built-in?
<fabbione> trulux: cap is not built-in
<trulux> shit, right
<\sh> Riddell: thx
<trulux> fabbione: kick me NOW please
<trulux> fabbione: just a deja-vu
* fabbione spares a kick for a later usage
<trulux> fabbione: sorry
<fabbione> :)
<trulux> Now I feel really screwed up :(
<trulux> wtf... deja-vu, definitely
* trulux goes back to work
<trulux> daniels: I will write up on my wiki on the PSC thing, it works for me though we need to make cups being restart before printing while using hpijs
<daniels> yes, I told you that
<trulux> daniels: if we get that working, then we will have out of the box support for this PSC things
<doko> \sh, python-qt3 is done
<trulux> yup, just tested and worked a bit on it
<\sh> doko: saw it...but pykde will be patched badly now ;)
<trulux> daniels: how do you think we should do it? either using a helper binary/script or ...?
<pitti> trulux: I don't see a recent commit to http://cvs.tuxedo-es.org/cgi-bin/viewcvs.cgi/vsecurity/
<trulux> pitti: see inside include and src dirs
<pitti> trulux: oh, I do, sorry
<trulux> pitti: np/nw
<pitti> seb128: $%&$, c-c builds find on my machine...
<seb128> it doesn't on mine
<pitti> uh
<pitti> trulux: argh, if you already have a KERNEL_DIR variable, can you please use it in the vsec target?
<trulux> pitti: sure
<pitti> trulux: you still didn't fix the spin_lock issue
<trulux> pitti: stupid error
<trulux> mmm, it doesn't complain here
<trulux> with your .config
<trulux> and -rc5
<pitti> trulux: there is no cvs commit for vsec_acl.c
<pitti> trulux: did you change the spin_lock args to a pointer?
<seb128> pitti: I can have a look on the g-c-c build issue if you want
<pitti> seb128: if you can reproduce it, that woudl rock. it just works(tm) for me...
<trulux> pitti: nope, it doesn't complain here
<trulux> really
<seb128> pitti: k, I'll have a look
<pitti> trulux: I did apt-get install linux-headers-2.6.12-1 and built with them
<pitti> seb128: thanks
<seb128> np
<pitti> trulux: WTH did you do then? :-) You are sure that you did not modify vsec_acl.c locally?
<trulux> pitti: it's rc4 that? then it might be missing a few committs or I'm totally screwed up and missed all
<trulux> pitti: hahaha, I was on 4 Red Bulls, blood flowing like fire, I have dunno. it was dymb fast
<trulux> lemme check
<pitti> trulux: 
<pitti> /usr/src/linux-headers-2.6.12-1/include/linux/spinlock.h
<pitti> void __lockfunc _spin_lock(spinlock_t *lock)    __acquires(spinlock_t);
<pitti> trulux: -> it takes a pointer
<pitti> trulux: in vsec_acl.c:
<pitti>                 spin_lock(vsec_##WHICH##_##TYPE##_lock);                \
<pitti> extern spinlock_t vsec_allsocket_uid_lock;
<zul> is xorg for breezy relatively safe now?
<pitti> ^ in vsec_acl.h
<seb128> pitti: what does "pkg-config --libs esound" returns for you?
<pitti> $ pkg-config --libs esound
<pitti> -lesd -laudiofile -lm
<seb128> k, so that's not that
<pitti> seb128: shall I send you my build log for comparison?
<seb128> yes please
<pitti> I just rebuilt from scratch with "debuild -us -uc -b"
<trulux> pitti: is it complaining to you? I will check here
<seb128> the config.log too if possible :)
<trulux> just gimme one sec
<pitti> seb128: both on p.u.c/~pitti now
<seb128> thanks
<seb128> hum
<pitti> trulux: odd that you have a different spinlock.h (do you???)
<seb128> -ALSA_CFLAGS=' '
<seb128> +ALSA_CFLAGS='-I/usr/include/alsa  '
<seb128> pitti: you have hacked your alsa somewhat?
<pitti> seb128: odd, but still this should not provoke a linker error...
<seb128> do you have the .build?
<seb128> I've only found the config.log on your page
<trulux> pitti: test this, (more for sanitizing and removing the idea of a screwed trulux with a screwed up mind because of the red cow crack dopping)
<trulux> get vanilla 2.6.11
<trulux> and apply -rc5
<pitti> seb128: check again, please (sorry, my last scp was screwed somehow)
<seb128> k, it's here now
<seb128> thanks
* lamont leaves to play with fire at the power station
<seb128> where should we assign sparc bugs?
<seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=11154
<pitti> trulux: no idea, maybe it was changed in 2.6.11?
<trulux> pitti: bbl, lunch time. test the rc5 please and tell me what you get. I'm sure there's something wrong *out* of vsec and vanilla
<trulux> pitti: will committ the fix for the KERNEL_DIR thing though
<pitti> trulux: I have rc5 here
<seb128> pitti: are you didn't turn the LDFLAGS="-Wl,-O1 -Wl,--as-needed" from debian/rules?
<seb128> pitti: the build lines are the same on both .build
<seb128> ie: you don't -lasound
<seb128> pitti: the build is easy to "fix", but I'm wondering why it builds for you
<pitti> seb128: I didn't change debian/rules
<pitti> seb128: I used the pristine source package from archive.u.c
<pitti> seb128: my system is not completely up to date, though; just downloaded today's daily and wanted to reinstall
<seb128> pitti: mine neither, but I don't think something changed around this
<seb128> maybe your cdbs has some magic :)
<seb128> fabbione: around?
<fabbione> seb128: yeps
<seb128> fabbione: about https://bugzilla.ubuntu.com/show_bug.cgi?id=11154
<fabbione> checking
<fabbione> doh!
<seb128> how know what's wrong?
<fabbione> seb128: sparc didn't make it for hoary...
<seb128> k
<fabbione> just close the bug as "unsupported arch"
<seb128> fine, thanks
* pitti boots new kernel, brb
<fabbione> or port is in progress
<fabbione> really
<trulux> pitti: rc5 there? make sure you have this:
<fabbione> seb128: also..
<fabbione> well i will take care of it
<seb128> feel free
<trulux> pitti: KERNEL_DIR = /home/pitti/kernel/linux-2.6.12-rc5/
<trulux> vsec: check
<trulux> 	$(MAKE) -C /home/lorenzo/kernel/linux-2.6.12-rc5/ M=`pwd` modules
<trulux> (to be fixed that target thing)
<trulux> install:
<trulux> 	$(MAKE) modules_install -C $(KERNEL_DIR) M=`pwd` MODLIB=/home/lorenzo/kernel/linux-2.6.12-rc5/security/
<trulux> (set to your personal dir of course)
<trulux> and be sure you compiled with your k7 config
<trulux> it works here, and it should do there
<fabbione> seb128: thanks... done :)
<seb128> thank you!
<fabbione> no thanks to you
<fabbione> it's nice to see there are sparc users around :)
<fabbione> and the cool thing is that sparc was never announced 
<fabbione> at all
<CarlK> where is the proper place to post that the tracker at torrent.ubuntu.com:6969 is down?
<pitti> hell, apt-get dist-upgrade wants to remove the *entire world*
<Amaranth> CarlK: They already know.
<jdub> pitti: that's what we meant by world domination - you didn't get that memo? :)
<maswan> ah, if I only could name a package "the *entire world*" :)
* pitti remembers
<CarlK> Amaranth - that doesn't answer my question ;)
<seb128> pitti: "GetRidOfTheDesktop" in action?
<Amaranth> CarlK: I'd suppose you'd file a bug report.
<pitti> seb128:  debian/patches/23_default_soundcard_selector.patch -> thanks
<pitti> seb128: what was wrong?
<seb128> dunno why it works for you
<pitti> seb128: no, it even removed dbs and build-essential, that goes too far
<seb128> it links with libasound without using -lasound
<pitti> seb128: what did you fix?
<seb128> -gnome_sound_properties_LDFLAGS =
<seb128> +gnome_sound_properties_LDFLAGS = -lasound
<pitti> seb128: I have seen that, probably a library on my system still depended on asound, but the newest version doesn't any more (or whatever)
<pitti> ah, cool :)
<trulux> pitti: I will try to see what's wrong with the ubuntu sources
<trulux> pitti: coulkd you send me an url to a rafb paste of the compilation errors, please?
<pitti> trulux: I don't get it, your spinlock.h really has a non-pointer argument?
<pitti> trulux: http://www.rafb.net/paste/results/MdgODf87.html
<trulux> pitti: I will paste the relevant code of my spinlock code
<Kamion> elmo: please sync libdebian-installer from unstable, overriding Ubuntu changes
<trulux> pitti: http://rafb.net/paste/results/FjsHy288.html
<trulux> pitti: void __lockfunc _spin_lock(spinlock_t *lock)    __acquires(spinlock_t);
<doko> Riddell, amu: please fix kdebase, it's currently FTBFS, before uploading other KDE packages ...
<pitti> trulux: yes, that's a spinlock_t *pointer*
<trulux> pitti: right
<trulux> pitti: strange
<pitti> strange ideed...
<pitti> $ sudo ls
<pitti> sudo: pam_authenticate: Module is unknown
<pitti> HEEELP! gtk bug...
<bob2> hahaha
* seb128 double-combo kicks pitti
* pitti wants his r00t back
<pitti> bah
<ogra> pitti, root is evil :) 
* pitti r00ts his box, brb
<seb128> why? r00t is useless :p
<ogra> your system knows that
<trulux> pitti: SAK! SAK! SAK! DAMN SAK!
<trulux> :)
<bob2> so, once I edit /boot/grub/menu.lst to reenable ht, how do update grub?
<bob2> grub-install /dev/sda?
<Treenaks> bob2: no. just edit /boot/grub/menu.lst
<Treenaks> bob2: and reboot
<bob2> ohm pimp
<bob2> Treenaks: thanks
<jdub> seb128: ping
<pitti> bah, I love you all
<trulux> pitti: heya :)
<pitti> destroyed pam configuration, destroyed x.org, no gnome-terminal any mre...
<pitti> seb128: it's there :-) no command line any more 
<trulux> pitti: *shrug*
<seb128> jdub: pong
<seb128> pitti: ah ah
<jdub> seb128: n/m
<seb128> jdub: just say it since you wake me up !!! :p
<Kamion> pitti: what on earth did you do?
<pitti> Kamion: apt-get dist-upgrade
<jdub> seb128: ha ha
<Kamion> d'oh
<pitti> Kamion: then I stopped when I saw that it removed essential parts of my system
<pitti> Kamion: I did not see that it removed cracklib, so my pam configuration was screwed; and due to some xorg pacakge updates my xorg conf got screwed
* jdub is happily sticking to apt-get upgrade at this point :)
* seb128 to apt-get install
<pitti> jdub: I just want my xorg unbroken again, to get my Ctrl key back
<jdub> rhm
<jdub> the "use hoary" line won't work on you ;)
<Treenaks> pitti: how about your Strg key? :P
<pitti> Treenaks: it's broken in all gtk apps, but works in firefox
<daniels> pitti: xorg works just fine
<daniels> pitti: make sure /usr/lib/X11/Xkb is a symlink to /etc/X11/xkb
<daniels> er, /usr/lib/X11/xkb
<daniels> no capital X in xkb
<pitti> daniels: I already tried that once and it didn't change anything
<daniels> pitti: try putting symlinks to /usr/X11R6/bin/xkbcomp and /usr/X11R6/bin/setxkbmap in /usr/bin
<pitti> sudo: pam_authenticate: Module is unknown
<pitti> argh, I tried I *just* fixed that  *grrr*
<pitti> daniels: sorry, pam is again broken, and this time it isn't cracklib
<pitti> will try later
* Amaranth 's X won't start at all :)
<Amaranth> /usr/X11R6/bin/Xorg -> ../../X11R6/bin/Xorg *cough*
<daniels> yeah yeah, known issue
<Amaranth> is there a known fix? :)
<crimsun> yep, man ln
<jdub> let's sing a song!
<Treenaks> jdub: well, start one!
<Amaranth> crimsun: i know how to symlink, i need to know what to link to
<jdub> o/~ when trademarks get you down, and all the good names are gone, do the only thing you can, ... pwgen! o/~
<crimsun> Amaranth: it was tongue-in-cheek
<daniels> Amaranth: rm /usr/bin/X11 && mkdir /usr/bin/X11 && apt-get install --reinstall xserver-xorg
<Amaranth> daniels: so this is my fault? for making the /usr/bin/X11 symlink before the upgrade, i mean
<eruin> archive.ubuntu.com/ubuntu/pool/main/r/readahead/readahead_1.0.1-2ubuntu1_i386.deb 404 Not Found
<eruin> is anyone aware of this?
<daniels> Amaranth: uh, you made it a symlink?
<Kamion> eruin: yes, it'll get fixed next time somebody runs hilarie on the archive
<eruin> kk ;)
<bob2> eruin: known problem
<Kamion> 12:20 < Kamion> elmo: is hilarie safe to run, to fix up cross-component symlinks? (libconvert-binhex-perl)
<daniels> Amaranth: (if your answer is 'yes', my answer is 'both pieces')
<Kamion> I don't really feel like running random archive scripts that I found by grep without checking first. :-)
<Kamion> because elmo knows where I live
<daniels> Kamion: it's probably for the best
<daniels> in terms of archive sanctity and your wellbeing
<Am|NickTaken> whew, good thing that fix worked
<Am|NickTaken> started gdmflexiserver and my system locked hard :/
<daniels> xorg is never broken
<daniels> sometimes it just behaves unexpectedly
<Am|NickTaken> heh
<Treenaks> daniels: it is the world that's broken?
<crimsun> no, just users.
<Am|NickTaken> so was the breakage my fault for making that symlink?
<daniels> no, not even users
<daniels> just
<daniels>  expectations :)
<crimsun> :)
<Am|NickTaken> btw, can you repeat the xkb fix?
<daniels> amapretty much, yeah
<daniels> Am|NickTaken: 15:13 < daniels> pitti: make sure /usr/lib/X11/Xkb is a symlink to /etc/X11/xkb
<daniels> 15:13 < daniels> er, /usr/lib/X11/xkb
<daniels> 15:14 < daniels> pitti: try putting symlinks to /usr/X11R6/bin/xkbcomp and /usr/X11R6/bin/setxkbmap in /usr/bin
<daniels> 15:13 < daniels> no capital X in xkb
<daniels> or /usr/bin/X11 if /usr/bin is no good
<Amaranth> ok, did all those, brbr
<Amaranth> -r
<siretart> elmo: please sync pinfo from unstable, overriding ubuntu changes
<Amaranth> damn, no luck
<Amaranth> oh well, thanks anyway daniels 
<Amaranth> i can live with brokenness, i need GNOME 2.11.x
<Kamion> ... ok, WTF just beeped at me
<Kamion> I hate it when that happens
<Amaranth> wtf, gnome-panel 2.11 removed the run application entry from the menu
<pitti> SNAFU
<Amaranth> i thought they were joking :/
<ogra> why should they
<ogra> ?
<doko> Kamion, elmo: gnome-menus depend on python-gmenu, (universe->main), same for g77-3.4-doc, which may be obvious as well
<Kamion> doko: python-gmenu and g77-3.4-doc done
<Kamion> elmo: ^--
<ddaa> seb128: what is the relation between imlib and png2?
<ddaa> seb128: the various imlib packages in ubuntu come from a source package called "imlib+png2", as opposed to some deprecated packages that come from a source package called "imlib".
<ddaa> and the info files for both point to the same cvs module
<Mithrandir> ddaa: they're linked with different png versions, which is needed because that old libpng didn't have symbol versioning so it all blew up if you linked an application with an incompatible imlib and libpng.
<ddaa> Mithrandir: is that purely a packaging difference? i.e should HCT use the same upstream CVS data for both?
<Mithrandir> ddaa: I think it is, yes.
<Mithrandir> ddaa: you might want to verify with seb128 to be sure, though
<ddaa> seb128: beer?
<ddaa> okay... the orig tarball is the same
* ogra GRRs at the new xscreensaver
<Treenaks> ogra: why?
<ogra> because they made a mess of the code to pevent anyone to hange logos and the like
<\sh> I hate this naming convention
<ogra> change even
<\sh> python2.4-sip4-qt3
<\sh> but only python-kde3
<\sh> *grmpf*
<ddaa> \sh: suggest changing it python2.4-sip-bong4-qt3
<\sh> hehe
<ogra> Treenaks, Jamie tries all to make it impossible to change anything (and even mentions that in the file headers)
<ogra> he thinks its a copyright violation if you change the logo of the lock screen according to the file header text's
<Treenaks> ogra: uhh...
<Treenaks> I knew he's weird.. but this weird
<ogra> which is just nonsense, but i'll have to rewrite at least 3 complete files to get my patch back in which is just silly regarding that the patch will die anyway
<seb128> ddaa: imlib+png2 is imlib built with libpng2
<ddaa> seb128: thanks. I just diffed the orig tarballs, they are identical
<seb128> np
<ddaa> so, as far as I am concerned, they are the same thing
<seb128> they are
<seb128> for upstream
<ddaa> the way orig tarballs are built is not totally clear to me
<\sh> Riddell: kdebase 3.4 is ok for using?
<ddaa> I could have imagined that the orig tarball of one included the checkouts from two cvs modules, or some other crack.
<Kamion> ddaa: generally they are copied from upstream and renamed
<bob2> yay
<ogra>    change the logo that xscreensaver displays on the splash screen and
<ogra>    password dialog, please don't.  The logo is xscreensaver's identity.
<ogra>    You wouldn't alter the name or copyright notice on a program that
<ogra>    you didn't write; please don't alter its logo either.
<ogra>  */
<Kamion> ddaa: sometimes the maintainer constructs them by hand for other reasons
<bob2> the mplayer homepage has two levels of anti-software-patent-rants now
<ogra> GRRRR
<bob2> ogra: jwz?
<ddaa> bob2: make a donation to the FFII :)
<Kamion> ddaa: for example, sometimes the tarball as shipped by upstream contains non-free material, which must be removed first
<ogra> yep
<Lathiat> gotta love jwz
<ddaa> Kamion: that's interesting. But this particular case is of no concern to me, it's up to HCT to find the right connection.
<Mithrandir> ogra: we should just rewrite xscreensaver, then
<ogra> why would someone want to make the uglyness his identity ??
<ogra> Mithrandir, jdub's project ;)
<ddaa> Kamion: well, it's of no concern to my job, I find that interesting, personnaly.
<jdub> ogra: oi!
<ogra> *g*
<Riddell> \sh: 3.4.1-0ubuntu0pre3 is, doesn't seem to be in the archives yet for i386
<ddaa> jdub: oi? http://www.dropkickthefaint.com/
* jdub looks at ddaa funny
<ddaa> jdub: "oi!" sounds like a punk thing to me
<Treenaks> or dwarves
<ddaa> besides, I just find this game fun :P
<Amaranth> "oi!" is an aussie thing :P
<Amaranth> or at least a non-midwest-US thing
<ogra> oi! is also what the german skinheads use greet each other....
<jbailey> Aussies did it in the battery commercials they showed in .ca in the mid-80's.
<jbailey> I saw it on TV, it must be true...
<ogra> heh
<zul> heh...i thought the site was something on the drop kick murphys
<ddaa> ogra: actually "oi" is not limited to skinheads... it's rather that skinhead are the most infamous offshot of that movement.
<omie> oi is a classification of music as well
<ogra> ddaa, yep, i also heard punks using it here....
<omie> ogra: oi is like rowdy drinking punk music
<pitti> thom: can I please have gcj and gobjc in concordia's hoay-i386 dchroot
<pitti> ?
<thom> pitti: done
<pitti> great, thanks
<bob2> hahaha
<bob2> mplayer compiles itself with -O4
<pitti> so what?
* pitti has seen -O9 somewhere
<bob2> gcc doesn't know about anything above -O3
<pitti> yeah, but other compilers might
<\sh> gentlemen, what about python2.3 backward compatiblity? are we able to drop python2.3?
<Kamion> not worth it yet
<\sh> asking only, cause I want to drop it from python-qt3
<Kamion> oh, individual modules, not everything? I imagine so
<\sh> imagine != knowing ;) so I'm leaving it right now until further knowledge :) 
<Kamion> depends how much you desperately enjoy merging changes from Debian
<\sh> ah doko replaced python-qt3 already
<doko> Kamion: could you tell me, what you will need for the CD as installable?
<Kamion> doko: ubuntu-desktop
<ddaa> Riddell: it looks like the kdelibs source package comes from CVS
<Kamion> unfortunately I can't easily produce a list of just the problems descending from that
<Riddell> ddaa: why?
<ddaa> Riddell: is there a particular reason why? KDE devel appears to be conducted on SVN now.
<doko> Kamion, hmm, ok
<ddaa> Riddell: why do it appear so, or why am I asking?
<Riddell> ddaa: in which way does it appear to come from CVS?
<ddaa> there's a "CVS" directory in it.
<ddaa> and a .cvsignore file
<Kamion> doko: totem looks like the obvious one, plus various amd64-specific problems
<doko> Kamion, yes depending on what seb128 finds out, I'm going to build it with g++-3.4
<Kamion> 'k
<seb128> what?
<ddaa> Riddell: and I'm trying to figure whether we should import CVS or SVN. I'd say SVN because that's where upstream makes love, and CVS because that's what appears to be used by the source package. So I'm want to clear up the confusion with you.
<doko> seb128; you have (bugzilla-)mail
<seb128> k
<seb128> I'm looking on a totem build log atm
<seb128> edd: Package debhelper has no installation candidate
<Riddell> ddaa: which version are you looking at and where's the CVS directory?
<seb128> s/edd/E (completion..)
<seb128> WTF
<ddaa> Riddell: I'm looking at kdelibs-3.4.0
<Riddell> ddaa: that would have been made when KDE still used CVS
<\sh> Suggests: python2.4-qt3-gl, python-qt3-doc, libqt3c102-mt-mysql | libqt3c102-mt-odbc | libqt3c102-mt-psql
<\sh> doko: python-qt3 
<ddaa> Riddell: according to the info file, the cvs repo is at :pserver:anonymous@anoncvs.kde.org:/home/kde
<ddaa> and there is also http://webcvs.kde.org/kdelibs/
<\sh> doko: liqt3c102-* should be replaced ;)
<\sh> and depends is also mixed up
<Riddell> ddaa: webcvs is for historical use only, websvn is there now
<Riddell> ddaa: definatly import from SVN
<ddaa> may I quote you?
<Riddell> ddaa: what are importing in to?
<ddaa> arch.ubuntu.com
<doko> \sh: fix it, it goes to universe ;-)
<ddaa> that's providing raw data for HCT
<Riddell> ddaa: yep, KDE cvs is dead, use SVN
<\sh> doko: yeah..working on it...but u have to upload, until I'm recognized ;)
<ddaa> Riddell: cool, thanks.
<\sh> argl....
<doko> \sh, can you upload to universe?
<\sh> doko: right now? no, cause elmo didn't include siretats and my key ;)
<Riddell> ddaa: the change to subversion is quite recent so there will be remenents of CVS usage around, but you can ignore them
<\sh> doko: but approved we are ;)
<\sh> do we have an emacs without X deps?
<\sh> ah nox
<Riddell> emacs21-nox is the goodness
<bob2> hm, no sound, even after unmuting everything
<ddaa> bob2: what is it you are trying to do?
<Amaranth> bob2: after the gnome-media upgrade?
<bob2> Amaranth: just a new hoary install
<Amaranth> oh
<bob2> ddaa: listen to music :p
<bob2> drivers seem to be loaded and such
<ddaa> bob2: curiously, rhythmbox seems to dislike esd on my system. Maybe that's the problem with you too. pkill esd.
<Amaranth> yeah, rhythmbox didn't want to work until i set gstreamer to use alsa
<ddaa> I leave it to the distro guy to find a real fix.
<mdke> worth filing a bug tho
<ddaa> Amaranth: haaaa... that must be it :)
<bob2> ddaa: smarty pants
<Amaranth> pkill esd is the wrong way to do it though
<Amaranth> System->Preferences->Sound and uncheck enable sound server startup
<ddaa> Amaranth: yes, but then some good love is lost, like the gaim siren
<Amaranth> gaim doesn't use gstreamer?
<ddaa> just fixing my "Multimedia Systems Selector" setting, I fucked with it when I tried to make skype work.
<Amaranth> and/or oss/alsa?
<bob2> well, that's just silly, it plays sounds out of the internal speaker instead of the decent ones I plugged in
<ddaa> Amaranth: all I know is it makes no sound if esd is not here, even though gstreamer was configured for oss.
<Amaranth> bob2: You can set that in System->Preferences->Sound too
<ddaa> but then I'm definitely not familiar with gnome things, so do not pay too much attention to what I say.
<Amaranth> or not
<Amaranth> that's for a sound card
<Amaranth> unless your laptop runs a seperate sound card for the speakers...
<bob2> Amaranth: eh? this is pcm stuff, not beeps.
<Amaranth> otherwise your laptop is broken
<bob2> not a laptop
<Amaranth> err
<Amaranth> it has an internal speaker that does more than beeps and it isn't a laptop?
<bob2> yes
<Amaranth> scary
<ddaa> bob2: btw, you are welcome to proceed with kdelibs, from SVN, in case you missed the talk with Riddell :)
<Amaranth> hrm, rhythmbox doesn't seem to like to swamp me with debug output anymore
<Amaranth> oh, they changed it to -d
<ddaa> bob2: and you are welcome to put gnome-desktop in your queue and out of the ArchImportCandidates page, since I approved it.
<ddaa> (I did so yesterday, when you asked)
<Riddell> ddaa: do you know anything about a timeframe for grumpy groundhog?
<ddaa> hell no
<ddaa> I'm just a bazaar/launchpad person.
<Riddell> fair enough
<ddaa> but from what I know of the management style of the company, it's probably slightly shorter of humanly doable.
<mdz> morning
<Simira> morning, mdke 
<Simira> uhm
<Simira> morning, mdz
<ogra> hey mdz 
<Simira> *sigh*
* mdz comforts Simira
<Simira> :)
* Mithrandir comforts Simira more.
<Mithrandir> :P
<Amaranth> err, that's a lot of comforting
<Simira> easy now, boy
<thom> morning mdz
<pitti> Hi mdz 
<Simira> Mithrandir: please keep to the laundry hangup ;)
<jdub> ha ha
<jdub>  openoffice.org (1.1.3-8ubuntu5) breezy; urgency=low
<jdub>  .
<jdub>    * Work around xorg reorganisation.
<jdub> 
<jdub> SUMO PACKAGE BATTLE!
<jdub> openoffice.org dodges!
<Mithrandir> I wonder how ooo is going to work around the "hah, stlport is now built with gcc4!" thign
<Mithrandir> thing, even.
<mdz> Mithrandir: does oo.o not build with g++-4.0 yet?
<Mithrandir> mdz: unsure, but I would be surprised if it did.
<ddaa> Riddell: do you wish to become the owner of kde on launchpad?
<ddaa> Riddell: well, first you'd need an account on launchpad
<Riddell> ddaa: I'd be up for that
<ddaa> Riddell: cannot give you ownership if you do not have an account :(
<ddaa> s/:(/:)/
<Riddell> ddaa: my account is jr@jriddell.org
<ogra> Riddell, i guess he means chinstrap etc
<ddaa> ogra: no, I mean launchpad
<ddaa> kde project is yours
<Riddell> launchpad isn't chinstrap
<ogra> ddaa, oh, they are not the same...
<Riddell> oh boy, I own KDE.  what does that give me?
<Riddell> lots of malone reports I suspect
<\sh> Riddell: master of kde?
<ogra> Riddell, a lot responsibilitys :)
<zul> certain death
<ddaa> no idea, but it gave me low-level irritation to see keybuk owning it :)
<ddaa> kdelibs is yours
<\sh> i will write a mail to kde governance; hey, guys, u r obsolete, jriddell took over kde from this day...he will rule you now ;)
<Riddell> my power grows
<ddaa> kdepim is yours
<Riddell> I own your kontact
<ddaa> Riddell: now, if a KDE guy comes in and throws a fit because you show as the "lead maintainer" of KDE, it's your problem :P
<\sh> ahh..my kontact disobeyed my orders now
<mxpxpod> thom: ping
<\sh> doko: ping eling
<ddaa> Kamion: when can I find general information (for project/product descriptions) for the various partman components?
<ddaa> * where can I find
<Kamion> ddaa: debian/control in each
<Kamion> they should all be part of the d-i project (or di, or whatever it's wrongly called in launchpad :-P)
<Kamion> di
<Kamion> (bah, there's another program called di; have fun resolving that)
<ddaa> you like d-i or di?
<Kamion> it's called d-i
<ddaa> Kamion: the best way to have it named your way is to create the projects products
<Kamion> but di is already registered and approved in launchpad
<Kamion> I was told it had to be that
<Kamion> dude, imports aren't my job :-)
<ddaa> then we'll name the projects and product in any random way that suit your fancy and you won't complain
<Kamion> heh
<ddaa> That suits _our_ fancy
* Kamion would've thought calling them what upstream calls them would suit most people's fancy. :-)
<ddaa> I so consider that creating those description are not our job either. Everybody is getting away with creating products without descriptions except us, and we are the least qualified to do it.
<ddaa> Kamion: yeah, it's not exactly trivial to figure that out in the general case
<Kamion> FWIW, in the case of everything in d-i, the upstream name of the product == the source package name
<Kamion> by definition
<ddaa> yeah, I'm getting the point. It's all debian native.
<Kamion> *nod*
<ddaa> I see no reason why it has to be called di
<Kamion> IIRC hyphens in project names didn't work at the time, or something
<ddaa> Yeah, various launchpad policies driving everybody crazy
<ddaa> Kamion: it's now https://launchpad.ubuntu.com/doap/projects/d-i
<ddaa> if you tell me your launchpad user name, I could make you the owner, too
<Kamion> ddaa: cool, thanks! colin.watson@canonical.com
<ddaa> Kamion: FYI your launchpad user name is "name91" you might want to fix that :)
<Kamion> ddaa: heh. how?
<ogra> huh, its not simply colin like for the other users ?
<Kamion> ogra: mine was created pretty early
<\sh> hmm
<ogra> ah
<\sh> who changed the CSS of malone? ,-)
<ddaa> Kamion: no idea how :)
<\sh> its breaking the width of 1024 
<\sh> ;)
<\sh> and its breaking firefox
<\sh> https://launchpad.ubuntu.com/malone/bugs/739 there is a lot of data inside...and right now it crashed my ff
<ddaa> Kamion: you should probably ask stub
<Kamion> ok, will do next time I see him
<Kamion> ta
<ddaa> Kamion: also, is that on svn://svn.d-i.alioth.debian.org/d-i/trunk... or in svn://svn.debian.org/d-i/trunk... ?
* ddaa randomly picks the latter
<Kamion> ddaa: they're the same thing - I happen to use the latter
<Kamion> svn.d-i.alioth.debian.org was used for a bit when svn.debian.org's DNS was broken
<Kamion> ddaa: our current documentation says the former
<ddaa> Kamion: the website seems to say the latter
<ddaa> my guess is the documentation is out of date
<Kamion> http://www.debian.org/devel/debian-installer/svn
<Kamion> may depend where you look
<ddaa> http://svn.debian.org
<Kamion> well, I don't really mind
<ddaa> it does not matter, just in case they were different
<ddaa> or one of the two were obsolete
<mdke> buona sera thesaltydog 
<thesaltydog> mdke, mom arrivo subito
<mdke> hi
<Kamion> aha
* Kamion finally reproduces #8265
<Kamion> an IP address where the firewall is configured to DROP all packets to the outside world is sufficient
<mdz> Kamion: free for a call?
<fabbione> hey guys
<fabbione> morning mdz
<mdz> fabbione: morning
<Kamion> mdz: yes, one sec, getting something to drink
<Kamion> mdz: ready
<ddaa> Kamion: thanks for your help
<mdz> does anyone know enough about XSLT to know where to look for a bug where xmlto (or presumably one of its dependencies) writes the wrong output filename for a man page/refentry?
<mdz> it's a maze of twisty programs, all alike
<jbailey> mdz: I did at one point like 5 years ago, if you can't find a better candidate.
<mdz> jbailey: I have an XML man page with <refentry lang="fr">, but "xmlto man" writes out foo.8 rather than foo.fr.8
<jbailey> mdz: I'll have to look at it to even make a guess.  I ran screaming from XSLT after developing a classifieds web site that was driven by it.
<KaiL_> daniels: you are hunting totally outdated documentation in the X-Server stuff?
<KaiL_> /usr/share/doc/xserver-xorg/README.i810 is from 2000 :)
<jbailey> mdz: I'm following these folks who have initrd troubles from the glibc update.  The fix to make initrd-tools cope with the new output from ldd is quite small and backwards compatible (It's in Debian already).  Can I do up a version for hoary-updates?  Justification is largely smoother upgrades for people moving to breezy.  It shouldn't matter for release since we'll be able to just depend on the initramfs st
<jbailey> uff, but otherwise Keybuk&Kamion feel that conflicts handling is a bit fragile for what we need.
<mdz> jbailey: I'd much rather add the necessary versioned depends/conflicts to breezy
<mdz> so that initrd-tools gets upgraded if necessary
<mdz> e.g., have the breezy linux-images depend on initrd-tools (>= foo)
<mdz> if it were some package other than libc6, I'd recommend a versioned conflicts with the old initrd-tools, but a versioned conflict on an essential package sounds nasty for problem resolution
<jbailey> mdz: The problem isn't that people have pulled in a new kernel - it's usually that they've pulled something other, like gdm from the new breezy in.  It pulls in the new glibc.  Then they got the security update from hoary-sec which caused the old initrd-tools to break.
<jbailey> mdz: The change to the initrd-tools is a 3 line sed difference.
<doko> seb128: totem-gstreamer depends on gstreamer0.8-mad, libmad was multiverse?
<Mithrandir> thom: did you get anywhere with a gcc-3.4-compiled firefox?
<ogra> doko, ouch
<Kamion> mdz: given that apt's http method uses non-blocking connect(), is there any reason that it can't connect() to every host in an IP rotation and use the first that succeeds, rather than connecting to each one and waiting for the timeout before it fails?
<Kamion> mdz: (or would that be too much of a load on rotated hosts? it's just a connect ...)
<Kamion> mdz: this is one of the factors that get multiplied together to make the delay in #8265 so enormous
<mdz> jbailey: a versioned conflicts on libc6 is the correct solution, all things being equal, but I'm really not sure what that would do to us
<mdz> Kamion: it's a bit rude TCP-wise to connect to all of them and then RST all but one
<mdz> Kamion: is that really the cause of #8265?
<mdz> I didn't think we had more than 2 IPs for any mirror
<Kamion> it's not the fundamental cause, it's just one of the pieces
<Kamion> basically, for each repository, we wait Acquire::http::TimeOut * number of IPs * (Releases, main/Packages.bz2, main/Packages, restricted/Packages.bz2, restricted/Packages)
<Kamion> since Acquire::http::Timeout is 120 by default, that's a lot - but if I decrease it far enough for the delay to be acceptable, it'll be too small for even reasonable network delays
<jbailey> mdz: Do you want me to add xmlto to my to-look-at queue?
<Kamion> so I could get it down from ~40 minutes to (say) 1 minute and 40 seconds for a ten-second timeout, but that's still too long
<Kamion> anyway, I'm being called for dinner, will have to revisit this tomorrow
<Kamion> it would be nice if apt could spot that it had timed out on Release, and not bother with the others
<\sh> paralell
<Kamion> that's also a bit rude
<\sh> well...not at all, if it's implemented the correct way
<Kamion> that would spawn five processes on mirrors running apache
<Kamion> seeing as the number of concurrent connections is generally the limiting factor on the performance of an apache server ...
<\sh> Kamion: mirror1: release mirror2: packages mirror3: restricted
<Kamion> \sh: too easy to get out of sync
<Kamion> there's no reason it can't remember that it timed out, and stop
<\sh> u have to rotate internally...we used it at lycos :) 
<Kamion> we already have mirror desync problems
<seb128> doko: ups, merge bug, I'll fix it
<\sh> Kamion: hmmm...
<\sh> Kamion: push instead of "let them pull"
<\sh> when you're not doing it already
<Kamion> \sh: dude, we already do - and with a 30-minute mirror pulse cycle, our *internal mirrors* get out of sync
<Kamion> the ones in the datacentre on gigabit pipes to each other
<Kamion> it's usually not for very long, but users notice it
<\sh> Kamion: do u have a logical map of how your internal mirrors are connected, SANs and NAS such things?
<Kamion> I'm not one of our sysadmins
<\sh> I would like to see, who the connections are made, and the storage is done.
<Kamion> I still think you're attempting to optimise the wrong thing though :)
<\sh> Kamion: no :) some problems are occuring every time :) but they can be easily solved with some add. hardware or different links or changed software :)
<Kamion> \sh: no, a hardware change would help, but not in the way I want
<Kamion> anyway, gone
<\sh> Kamion: or how do u think, a portal site is running...500 frontends completly in sync behind 5 load balancer etc :)
<\sh> not to forget the backend...which is easier to break ;)
<Kamion> that's not the point, apt *doesn't need* to check the subsequent files
<mdz> Kamion: that should be fixable, talk to mvo
<Nafallo> JaneW_away: NetworkMagic has different seconds on BreezyGoals and the actual spec.
<mdz> doko: ping?
<doko> mdz:pong
<ogra> Nafallo, the spec lists the people that held the BOF for the topic, the Goals page lists the people that actually work on theimplementation
<Nafallo> ogra: ahh, I see. thanks :-).
<dholbach> hellas
<Nafallo> hi dholbach :-)
<dholbach> Nafallo :)
<seb128> daniel!!
<dholbach> woohoo seb128 
<dholbach> sb: no jabber fun anymore? ;)
<seb128> you are offline
<dholbach> hm, not really
* HWolf wonders why a lot of work is still being done on the udu wiki
* HWolf would assume that most nerds would've lost the tan by now
<ogra> HWolf, the udu wiki is our ressource for breezy specs and goals... most of the work documentation and project planning/tracking is done there
<HWolf> ogra, why isn't it moved to the main wiki?
<doko> Kamion: if we get screem and bluez-utils converted to the new dbus, then you can tomorrow build a CD
<ogra> becaue one is zwiki and the other is moin... it would drag away manpower from actual work to merge them
<HWolf> hm, ok
<torkel> doko: I think there is a new upstream release of screem that supports the new dbus (if you didn't already knew that)
<ogra> doko, ugh, since when is screem in main ?
* ogra would have preferred bluefish here
<Nafallo> ogra: since warty I believe? ;-)
<ogra> oh
<doko> torkel: thanks, seb128 or I will have a look
<seb128> torkel, doko: I've worked on 0.14.0 today and it doesn't
<Nafallo> maswan: ping?
<seb128> I've started to sync it from Debian
<seb128> doko: oh, I've just uploaded bluez-utils
<seb128> for the new dbus
<seb128> a GNOME guy pinged me about it
<seb128> so I've fixed it...
<maswan> Nafallo: pong.
<seb128> doko: and I've fixed screem 0.12 this morning, as said this afternoon 
<torkel> seb128: according to screem.org, 0.14.1 should support newer dbus
<Nafallo> maswan: something went wrong with the latest sync I believe?
<seb128> torkel: k, Debian has 0.14.0, I'll have a look on the 0.14.1
<seb128> thanks
<maswan> Nafallo: yes. for some reason the tcp connection closes with ETIMEDOUT when reading from it.
<maswan> Nafallo: I've been trying to figure out why, but I don't understand it.
<maswan> Nafallo: the only similar incident I've managed to google up was discussed but not resolved on the rsync mailinglist
<Nafallo> maswan: hmm, okey. you got a trace this time? :-)
<maswan> a trace? as in truss:ed it? yes.
<maswan> that's why I know that it goes into a select, sleeps a while, then resumes, does a kread on the tcp connection which fails with ETIMEDOUT
<Nafallo> maswan: hmm, annoying ;-)
<seb128> torkel: the issue is not dbus for screem, that's gnome-menus
<torkel> seb128: oh
<seb128> it uses the gnome-menus 2.10 API
#ubuntu-devel 2005-06-03
<Nafallo> night all!
<dholbach> have a nice day! *wave*
<opi> hi
<LinuxJones> opi, hi
<opi> I just killed my laptop with Array1 ;)
<opi> but I see that Kamion is away, so I'll write him e-mail instead of /query
<mkde> Amaranth, you here by any chance?
<Amaranth> mkde: yeah
<mkde> Amaranth, i was just thinking about the name for your menu editor
<mkde> ;)
<Amaranth> opi: colony 1
<Amaranth> mkde: hehe, that's part of the fun
<opi> Amaranth, right
<mkde> Amaranth, ahh, just checking it was intentional
<opi> Amaranth, it's almost 1AM so I'm dizzy ;)
<Amaranth> mkde: I didn't know it was short for smegma at the time, but I'm sticking with it now.
<mkde> Amaranth, thats not what i mean
<mkde> http://www.urbandictionary.com/define.php?term=smeg&r=f
<Amaranth> yeah, i found all that out later
<Amaranth> it's Simple Menu Editor for GNOME
<mkde> i hadn't heard of smegma ;)
<mkde> ouch
<mkde> now i have
<Amaranth> it's also a red dwarf thing, which is why i liked it
<mkde> Amaranth, if it goes into breezy will you stick with the name?
<Amaranth> i don't want the show but someone i know does and their nick is Smeggy, i thought he'd think it was funny
<mkde> *grins*
<Amaranth> unless you can think of a better name..
<mkde> nono
<mkde> just curious
<Amaranth> for the package for breezy i can patch it to be called just 'Menu Editor'
<mkde> all good
<mkde> nice prog anyhow
<Amaranth> it's even better on my machine :)
<Amaranth> all the long waits when you do things are gone
<mkde> cool
<mkde> ok bed for me
<mkde> keep up the top work
<Amaranth> night
<\sh> ok..also time to go to bed
<\sh> cu tomorrow 
<opi> OK, I'm going to install Slackware ;D
<thom> Mithrandir: i'm running the hoary security build currently and it's great; will try a rebuild of 1.0.4 in the morning
<Unfrgiven> elmo: ping?
<Unfrgiven> elmo: can we pull freemind from unstable into universe?
<lifeless> mjg59: ping
<daniels> KaiL_: well, this was just plain misleading, so I pulled it
<lifeless> daniels: ah there you are
<AndyFitz> #ubuntu-love
<lifeless> daniels: so the laptop screen isn't right
<lifeless> X thinks its 1024x768
<AndyFitz> opps no /join
<lifeless> my pixels are WIDE
<lifeless> daniels: where should I discuss this with you ?
<daniels> lifeless: awesome
<daniels> lifeless: your bios is probably shit.  i810, right?
<lifeless> 0000:00:02.0 VGA compatible controller: Intel Corp. Mobile Graphics Controller (rev 03)
<daniels> you WIN!
<daniels> your prize is getting to hunt around for 855resolution or something that works for your laptop
* tseng just packaged boo
<tseng> if anyone is into that kind of thing
<thom> boo? that scripting language thing?
<tseng> yes.
<lifeless> daniels: any chance to teach breezy to DTRT ?
<daniels> lifeless: not at all
<lifeless> :[
<daniels> lifeless: needs either a) people to write proper video BIOSes, b) intel to stop being shit and stop demanding people set modes through the BIOS, and tell us how to program modes ourselves
<lifeless> 915resolution apparently
<daniels> or, preferably, both
<lifeless> daniels: erkay.
<lifeless> daniels: is there some hook in the xorg.conf I can tell it to run the 915program
<lifeless> rather than hacking gdms startup script ?
<daniels> lifeless: nope
<jdub> daniels: can we support running those proggies where necessary by default somehow?
<lifeless> daniels: could we get something like that to make it less traumatic?
<lifeless> daniels: so that its 'apt-get install 915resolution' + dpkg-reconfigure and tell it what I've got, rather than 'learn all this shit once off just for my laptop'
<daniels> jdub: no, and I really don't want to
<daniels> jdub: there's no sensible way to work out which one to run by default
<daniels> jdub: get it wrong, and your video BIOS is fucked until we reboot
<daniels> jdub: if we're stomping all across the video BIOS at reboot ...
<tseng> thom: it runs on mono, naturally
<thom> tseng: indeed
<whiprush> evening gents.
<tseng> hi whiprush
* thom tips his hat to whiprush
<whiprush> jdub: let's talk about a large, rectangular device that cools food and drinks.
<lifeless> daniels: magic choice would be hard. but easy-to-do would be good and less hard.
<thom> and goes to bed
<daniels> whiprush: yo
<thom> whiprush: can i put beer in it?
<lifeless> Later thom
<whiprush> heya daniels 
<tseng> bye thom 
<lifeless> daniels: thanks
<lifeless> daniels: evil but works
<lifeless> other bit of weirdness you may be able to shed light on..
<lifeless> sleep the laptop
<lifeless> comes back ok, but the brightness is gone.
<lifeless> fn-bright up or down, and it comes normal
<daniels> lifeless: again, that's largely a video BIOS thing
<lifeless> I was hoping you wouldn't say that
<daniels> now you see why we really want to find out how to program modes for i8xx/i9xx
<lifeless> what do those programs do .. oh right, they fudge the bios executable code
<daniels> sure
<daniels> so you need to figure how to stash the brightness away over a suspend
<wasabi> Hmm. Interesting network/interfaces question.
<wasabi> I see the mapping hotplug thing, which apparently ups eth0 when it's actually plugged in.
<wasabi> Can that up eth0 AND eth0:1?
<daniels> tseng: ping
<daniels> pitt(or you)
<daniels> erk
<lifeless> daniels: the bios hack - will I need to do that after hibernate ?
<daniels> probably, yeah
<daniels> see, this is why you get an X40 :P
<bob2> what chipset does the x1 have?
<daniels> i915, but with a crap bios
<bob2> bet it has working xvideo, tho ;p
<lifeless> daniels: yeah yeah, heard it before
<fabbione> morning
<crimsun> morning
<jsgotangco> morning
<Amaranth> bah, i'm trying to find a package that won't install due to dependencies and you guys have gone and fixed all the ones i knew
<wasabi> Anybody able to answer this multiverse question? I have a package, Eclipse, which I'd like to get uploaded so that I can get people using it, and start cleaning it up. At this point it has one dependency which is not buildable from source with distributable tools (lucene, a Java component).
<wasabi> Classpath folks are working hard on getting this fixed.
<wasabi> Is this acceptable for multiverse?
<daniels> is it a buld-time or run-time dependency?
<wasabi> Both.
<wasabi> Java makes no distinction.
<jdub> wasabi: probably best to mail ubuntu-devel
<daniels> wasabi: it needs to be able to be built from source in a clean environment
<wasabi> For multiverse?
<wasabi> Somebody has pointed out eagle in multiverse which is a single binary wrapped in a deb package at build time, I haven't looked at it yet though. ;)
<wasabi> I shall mail -devel
<crimsun> I mentioned eagle, because I tweaked it for Hoary
* lamont sleeps.  was a long day
<fabbione> hey lamont 
<fabbione> before you go...
<lamont> sim?>
<fabbione> did you update anything in the kernel for hppa?
<lamont> hrm... checking
<lamont> (no I didn't, will look to see if I can, and will.)
<fabbione> lamont: ok.. it's no rush
<fabbione> i am not going to upload kernel today
<lamont> cvs host appears to be down.  I'll poke it again in the morning
<fabbione> so a build from pre2 + a config update would be nice
<fabbione> meh pre1.2
<fabbione> well the latest
<lamont> right
<fabbione> good night :)
<jsgotangco> brb lunch
<JanderClander> hi there
<jsgotangco> JaneW, hi
<Burgundavia> JaneW, any movement on edubuntu?
<JaneW> hi jsgotangco and Burgundavia, yes there should be very shortly
<Burgundavia> JaneW, cool
* JaneW will brb - school run
<pitti> Morning
<bob2> hey pitti 
<fabbione> hey pitti
<fabbione> pitti: are you subbed to kernel-team?
<pitti> fabbione: no, I don't
<fabbione> pitti: mail forwarded.. already informed Herbert
<pitti> uh, ht on warty... :(
* dilinger hopes he expressed his dislike for bugzilla sufficiently :)
<mjg59> lifeless: Hello?
<fabbione> probably hoary too
<fabbione> pitti: the patch is the same
<Amaranth> anyone know why gnome-panel stopped updating the menu recently?
<Treenaks> Amaranth: have you tried killing/restarting it?
<Amaranth> that's the only way to make it update
<Treenaks> it's gnome 2.11, it SHOULD be broken :)
<Amaranth> it's funny that the force quit applet doesn't make it close anymore
<Amaranth> and that when you kill it normally it doesn't came back anymore
<Amaranth> i'll bug upstream, i guess
<Amaranth> i thought maybe it was X related
<Amaranth> sucks working on a menu editor in these conditions :)
<fabbione> infinity: do you want me to reassign 11122 to your or thom?
<fabbione> that's all other than kernel related :)
<hunger> Why are the kdebase/kdegraphics debs not available in the archives yet? People claim they were successfully build yesterday afternoon.
<Amaranth> kdebase_4:3.4.1-0ubuntu0pre3_20050526-1433-i386-successful.gz    26-May-2005 14:51
<Amaranth> they should be there real soon
<hunger> Amaranth: The rest is there since yesterday evening.
<hunger> Amaranth: And those should depend on kdebase.
<\sh> ok..included patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304407 nice...
<pitti> Hey seb128 
<pitti> seb128: do you know whether evince could support gzipped and bzip2'ed files?
<seb128> it does
<seb128> .ps.gz which is a mimetype
<pitti> evince /usr/share/doc/udev/udev-OLS2003.pdf.gz
<seb128> the bugs about other stuff has been closed saying we should first define new mimetype if we need stuff like .pdf.gz
<pitti> Unable to open document
<seb128> yeah, that's not a correct mimetype
<pitti> Unhandled MIME type: 'application/x-gzip'
<seb128> right, gzip is not suited for evince
<seb128> ps.gz is by example
<seb128> I'm thinking about the issue
<seb128> just fought for a good hour to get a xorg starting again
<pitti> ok, thanks, but it's not really urgent
<seb128> I had to upgrade after some partial upgrades which b0rked it
<seb128> now my xkb is b0rked
<seb128> way to start a day :/
<pitti> seb128: my box was completely wrecked yesterday, I reinstalled hoary and upgraded to some breezy pacakges that I need :-(
* seb128 kicks daniels
<daniels> seb128: i'm not fixing it until you fix my panel :P
<seb128> stop splitting xorg and fix the xkb dude, people can't work with that
<daniels> seb128: i've said the workaround in here about a bajillion times
<pitti> hey, xorg split is nice
<daniels> and when I tried the workaround on both of my machines, it worked fine
<daniels> don't really know what else I can do
<pitti> seb128: <daniels> pitti: try putting symlinks to /usr/X11R6/bin/xkbcomp and /usr/X11R6/bin/setxkbmap in /usr/bin
<seb128> daniels: it doesn't work
<seb128> already did
<seb128> doesn't work for dholbach neither
<daniels> seb128: and /usr/lib/X11/xkb is a symlink to /etc/X11/xkb?
<seb128> too
<seb128> all you said yesterday
<daniels> try also putting the symlinks to those apps in /usr/bin/X11
<seb128> and some other stuff like xrdb than g-s-d wants
<daniels> then send me the Xorg.0.log if it's really still broken after all that
<seb128> k
<daniels> gotta go make dinner now
<jsgotangco> ahhh sounds good
<seb128> pitti:  http://bugzilla.gnome.org/show_bug.cgi?id=305081
<pitti> seb128: ah, thanks
<seb128> pitti: what do we want? .pdf.gz? any need for .bz2 formats?
<seb128> .ps.gz are application/x-gzpostscript
<pitti> seb128: why not the full range, the libraries should make that easy
<pitti> ah, so a complementary mime type is missing for pdf
<seb128> pitti: that's the issue, making evince opening 'application/x-gzip' is wrong
<seb128> since it's not an archive handler
<pitti> right
<seb128> grrr
<seb128> no way to get that ***** xkb working
<seb128> pitti: does that work for you?
<daniels> if all else fails, try linking everything in /usr/X11R6/bin into /usr/bin/X11
<pitti> seb128: I could't try since my box was trashed and I can't dist-upgrade now without removing the world
<koke> !
<koke> hi all!
<seb128> daniels: way to go :p
<daniels> sigh
<seb128> daniels: still the same with a "sudo cp /usr/X11R6/bin/* /usr/bin/X11"
<daniels> ok
* Nafallo hi all!
<mdke> i was just looking at http://www.ubuntulinux.org/wiki/LaptopTesting . I have a laptop where some of the hotkeys do not show up under xev. Where should I be reporting this? in that section of the wiki? ubuntu bugzilla? xorg bugzilla?
<Kamion> hunger: kdebase is in the NEW queue
<hunger> Kamion: Thanks for the info!
<Kamion> because kdebase-doc-html is new
<jsgotangco> mdke, there's a table made by mjg59 in the wiki as well that should like with that wiki page
<mdke> jsgotangco, yes, but i was wondering whether my problem applies, given that the keys don't even show up with xev
<jsgotangco> ahh
<seb128> daniels: any other idea for the xkb?
<siretart> The following packages have unmet dependencies:
<siretart>   xlibmesa-glu-dev: Depends: xlibmesa-gl-dev but it is not going to be installed or libgl-dev
<siretart> any ideas whats going wrong?
* pitti pats daniels
<seb128> k
<seb128> I'm going to break my box today I think
<seb128> at least I'll try to fix that
<seb128> if that doesn't work I'll use pitti's way, hoary with selected upgrades :)
<pitti> seb128: my way involved a partition break, PAM breakage, xorg conf breakage - believe me, it wasn't a nice experience
<Nafallo> breezy with selected downgrades works to ;-)
<daniels> seb128: nope
<pitti> seb128: (the partition break just was a PEBCAK while I worked in single user mode, forgot to unmount)
<seb128> pitti: I guess so, byt the xkb b0rkage is enough to break my productivity
<daniels> seb128: nothing I can do without your Xorg.0.log
<daniels> siretart: libglu-dev-xorg
<Riddell> Kamion: where can you find out the reason for a package being in the NEW queue?
<seb128> daniels: my homedir on chinstrap has it
<Kamion> Riddell: you should've got mail ...
<Kamion> oh, no, the buildd will have it
<siretart> daniels: ah, thanks. that'll do
<Kamion> Riddell: you ask elmo or me ;-)
<siretart> daniels: is there somewhere a summary about changes build dependencies from xfree to xorg? most of obvious, but this one rather not
<daniels> siretart: http://people.ubuntu.com/~daniels/xlibs-static-dev.txt, plus that
<siretart> daniels: thanks!
<seb128> daniels: so, anything from my Xorg.0.log? :)
<nanomad> hi all!
<nanomad> anyone else has openoffice.org broken?
<daniels> gar
<daniels> seb128: i'm not the vim maintainer
<seb128> daniels: you did this upload
<seb128> who break something fix it :)
<daniels> heh
<daniels> it only broke by being recompiled after the new X stuff
<seb128> k, I reassign that to me 
<seb128> you "just" fix my xkb issue :p
<daniels> hah
<seb128> have you looked on my log?
<daniels> yeah, didn't see anything obvious
<seb128> :(
<pitti> seb128: what exactly boke for you? the Control key?
<seb128> pitti: yep, like everybody else I guess
<seb128> ctrl-C opens new windows by example :p
<daniels> it hates your non-US keyboards
<Burgundavia> anybody known that python scripts in X-chat are borked right now in Breezy? should I bother filing a bug about it?
<seb128> that's known 
<Burgundavia> ok, just checking
<seb128> fill a bug if you want
<Burgundavia> nah, if you know, why file?
<Burgundavia> why waste your time seb128 , I already do that well enough
<seb128> no reason right
<jsgotangco> bye bye happy weekend :)
<tseng> bye
<ogra> ciao jsgotangco 
<Amaranth> it's 6am friday morning here :)
<Amaranth> byte jsgotangco 
<Amaranth> err
<jsgotangco> heh
<jsgotangco> ogra, hmmm..bugzilla..is it possible?
<ogra> jsgotangco, hmm ?
<jsgotangco> oh just filed something in bugzilla for hwdb-client just check it out when you're free
<ogra> did you assign it to me ?
<jsgotangco> yeah
<ogra> great, thanks
<doko> elmo: please sync java-gcj-compat from experimental
<fabbione> elmo: you around?
<trulux> pitti: heya!
<pitti> Hi trulux
<trulux> pitti: what's up?
<pitti> trulux: just finished today's security updates
<trulux> pitti: great, so, we can do some cool work now, right? ;)
<trulux> pitti: I had a look over the vsec stuff and it's scary that rc5 doesn't complain here. did you tested there?
<pitti> trulux: did you find out the spinlock issue?
<pitti> trulux: I already said, I tested against linux-headers-2.6.12-1
<trulux> pitti: yup, that was merged sometime out-of.git.scope though (there's no bloob with the info about such a diff)
<trulux> pitti: I will do the same here right now. just a thing, did you fixed that spinlock issues and it compiled well again? (the rest is done, including ipv6 dead symbols stuff)
<trulux> be sure to have your copy sync'ed with the cvs trunk
<trulux> pitti: http://www.tuxedo-es.org/blog/archives/5-Some-2.6.12-rc5-API-changes-for-the-shake.html
<trulux> pitti: http://lwn.net/Articles/100749/
<trulux> pitti: http://pearls.tuxedo-es.org/patches/vsecurity/vsec-0.3-20050526-2.6.12-rc5-fixes.patch
<jbailey> Kamion: ping?
<Kamion> jbailey: pong
<jbailey> Kamion: Just read your code review strategies email, and thinking about the FormalTestPlans spec.
<Kamion> I guess it's somewhat related
<Kamion> in that they're both under a QA umbrella
<jbailey> Kamion: Right.  I'm wondering if it's worth asking scott for a flag on HCT that also includes a "review requested before upload" mode.
<jbailey> Kamion: I like the idea of making code reviews possible, but I think it would be interesting to maybe be able to say "I'd be happier with a code review", and eventually (as we get a bigger community) requiring one for certain packages.
<jbailey> (toolchain, kernel, boot stuff and the like)
<jbailey> Or if a debdiff within the same version exceeds a certain size or whatnot.
<jbailey> Double custodianship on all changes was a big push we were starting to move to in my last job (Financial industry) and it might be worth something to be able to have an auditable signed-off-by like the kernel has.  (future, obviously)
<Kamion> jbailey: once we have the committer/maintainer distinction, that sort of thing will be useful, yeah
<Kamion> although for smaller/less-important packages, it would be too heavyweight
<Kamion> so as you say, a flag
<pitti> trulux: I got a tarball from your cvs tree
<jbailey> Right.  For smaller packages I can see it eventually, but there would have to be a decent reviewer committee who enjoyed doing that sort of work where you could generally expect a change reviewed very very quickly. =)
* Kamion nods
<ajmitch> hello pitti, trulux 
<trulux> hey ajmitch 
<Kamion> jbailey: feel like posting that to the list? a lot of us seem to have been kicking around thoughts about this sort of thing; I was talking about it in my review call with mdz last night, and he asked me to post in order that we could archive the discussion and maybe actually implement it :-)
<trulux> aj: how're you doing today?
* trulux may start doing hapkido soon
<ajmitch> trulux: been ill in bed for most of the day, haven't done any ubuntu work ;)
<trulux> ajmitch: oh, I hope you to get better. I was also a bit sick yesterday
<jbailey> Kamion: Will do - I wanted to make sure I didn't drag it away from the ideas you had if they didn't match.
<aj> trulux: i'm fine, thanks ;)
<ajmitch> heh
<trulux> ajmitch: a great shitload of work and caffeine this week, I had a royal headache and some other diseases
<trulux> aj: well, ajmitch/aj/aj* finally :)
<ajmitch> trulux: I added a few notes to wiki.ubuntulinux.org/SELinux
<Kamion> jbailey: it's more future-ish than the sorts of things I was thinking about (in that it requires HCT), but it'll be useful in the longer run ...
<ajmitch> about other things that may need done
<jbailey> Kamion: Yup, and I would love to scribble notes into the FormalTestPlans spec eventually to show any sort of review process.
<jbailey> Kamion: With moz and the kernel already doing code review, I can see the whole Free Software movement actually starting to adopt Software Engineering best practices.  It's kindof amazing.
<trulux> ajmitch: yup I added a diagram
<trulux> ajmitch: http://pearls.tuxedo-es.org/selinux/diagrams/selinux-binary-policies-1.png
<trulux> ajmitch: that's the way I thought we should go
<ajmitch> trulux: I think the relabelling may be needed at boot time in some cases
<Amaranth> anyone have all their menus and entries disappear lately?
<eruin_> nope
* Amaranth beats things
<trulux> ajmitch: yes, me too. I can work a few things out today, though I would like to have done the UI stuff
<trulux> ajmitch: (now that we have the packages ready except the policies)
* ajmitch has started working on UI parts
<trulux> ajmitch: how much do you have done? (I could help)
<trulux> ajmitch: though I'm stuck with the applet
<trulux> brb, phone
<ajmitch> trulux: I really don't think an applet is necessary - why would you need to have selinux config sitting on the panel?
<mpt> ajmitch, trulux: #ubuntu-hardened :-)
<trulux> ajmitch: it's a nice thing to be able to keep it simple, and an applet does the job pretty well, among that it won't take longer than 20min to finish the UI part (I have done the rest, and I can implement any function from libselinux if needed)
<trulux> mpt: ok :)
<pitti> trulux: I don't really have time ATM, could you please try to make it work with the current linux-headers-2.6.12-1?
<trulux> pitti: I will do, don't worry
<trulux> pitti: just doing a few things for mpt 
<trulux> :)
<Kamion> doko: should 1.0.28-2build1 have been -2ubuntu1? it seems to have source changes
<doko> Kamion: no, it should be synced from experimental again. same source, but the OOo2 build fails without it.
<Kamion> (I meant to say java-gcj-compat there, sorry)
<Kamion> ok
<seb128> grrrrrrrr
<seb128> I just closed a 10min running evolution build while trying to opening a new tab
* seb128 kicks daniels 
* Treenaks hands seb128 some spiked boots
<ogra> seb128, do you inderstand now why i dont like tabs ;)
<seb128> sure cahos all the time is better ...
* ogra thinks its time for revenge for everybody who made fun of him about not using tabs :P
<ogra> (in udu that is)
<Mithrandir> tabs?  what's that?
<Mithrandir> :-)
<ogra> seb128, but alt-tab works here :)
<Mithrandir> seb128: use screen.
<seb128> that's an option
<seb128> but that should not prevent daniels to fix xkb stuff :)
<Burgundavia> seb128, I had a crazy idea. Can we ship ross' notification icon by default?
<seb128> I've no objection
<Burgundavia> does it require another package? I cannot remember
<seb128> I don't think so
<seb128> rock
<seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=10942
<seb128> somebody has found the xkb issue and has a patch :)
<tepsipakki> hmm, .hidden files seem to work only on user home, this is a regression
<Mithrandir> seb128: yay!
<Mithrandir> seb128: now we just need to poke daniels into fixing it.
<seb128> yep
<seb128> tepsipakki: with nautilus? works fine here
<tepsipakki> seb128: yes, with nautilus.. not here ;)
<tepsipakki> duh, pkill nautilus solved it
<Burgundavia> seb128, how agressive are the gnome people about closing old bugs?
<seb128> depending
<seb128> a 1-2 months NEEDINFO bug is closed usually
<Burgundavia> ok
<tepsipakki> burgundavia: not very, just had a look at the list for rhythmbox ;)
<Burgundavia> that was my thought
<Burgundavia> as I wander through bugzilla
<Burgundavia> I see a lot of very old crasher bugs
<seb128> Burgundavia: upstream?
<seb128> Burgundavia: bug that could be useful are kept
<seb128> usually NEEDINFO are closed
<Burgundavia> ok
<seb128> when they have doubt on a crash they put a comment to know if that happens with the current version
<seb128> and if the guy doesn't reply they closed
<seb128> oh, a note
<seb128> you should put a comment when you close duplicates
<Burgundavia> on the dup?
<seb128> http://developer.gnome.org/projects/bugsquad/triage/stock-responses.html
<seb128> use that
<Burgundavia> ah, cheers, thanks
<seb128> np
<seb128> I've planned to do a such page or something for ubuntu
<Burgundavia> want me to put that on the wiki?
<seb128> that's much easier for triage
<seb128> yes please
<Burgundavia> shall do so now
<seb128> need to figure a standard reply for UPSTREAM too
<Burgundavia> ok
<Burgundavia> BugResponses ?
<ogra> sounds good
<seb128> yep
<Burgundavia> https://www.ubuntulinux.org/wiki/BugResponses
<Burgundavia> any thoughts on this? http://www.ubuntuforums.org/showthread.php?t=36945
<seb128> we turn this feature
<Burgundavia> off?
<seb128> because that's weird to get the whole screen fading just to enter a password
<Burgundavia> ok, figured, I just didn't know the answer
* ogra sees ltsp hitting -changes....
<ogra> mdz, ping 
<Burgundavia> seb128, having fun with evo bugs?'
<seb128> Burgundavia: that's quite borring, but I do a bug review during the sync/update to 2.11 versions for every package
<seb128> ~90 bugs for it
<Burgundavia> ugh
<Burgundavia> can I help?
<seb128> not really, I'm almost done with them now
<seb128> thanks
<Burgundavia> ok
<Burgundavia> if you need hlep with clearing out bugs, I usually have free time to give a hand
<seb128> there is a lot of NEW/UNCONFIRMED bugs, feel free to reply on them or forward upstream :)
<Burgundavia> ok
<seb128> thanks
<carsten> Hi. My update of binutils (on 5.04) makes compiling impossible. Is this a know issue with the new package?
<carsten> This breakages was confirmed to me in IRC
<pitti> carsten: I know and I prepared an update
<pitti> carsten: sorry, I screwed binutils
<carsten> ah, ok :-)
<Tsingi> I hope this is OT, I'm having a problem linking on a new install...
<pitti> carsten: http://people.ubuntu.com/~pitti/binutils_2.15-5ubuntu2.2_i386.deb
<pitti> Tsingi: ^
<Tsingi>   /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o: file not recognized: File format not recognized
<pitti> yes, that's the same
<pitti> Tsingi: <pitti> carsten: I know and I prepared an update
<carsten> pitti: ETA on the server?
<Tsingi> ahh, you know what it is?? fantatsic!
<pitti> carsten: < 1 hour, but let me test everything first
<carsten> k
<pitti> carsten: I tested my local debs
<Tsingi> I should wait?
<pitti> carsten: but I want to test the buildd output 
<pitti> Tsingi: yes, grab http://people.ubuntu.com/~pitti/binutils_2.15-5ubuntu2.2_i386.deb or just wait a bit
<pitti> Tsingi: (^ that's for hoary)
<Tsingi> ok, I can wait, or test for you if you like
<Tsingi> I installed 5.04 yesterday
<pitti> Tsingi: that regression comes from this morning's security update
<pitti> it's so secure, it refuses to build any code that has at least one hole
<pitti> seriously, sorry guys
<Tsingi> lol!
<Tsingi> well, I discovered it compiling nethack.  Then checked some of my projects (nethack is of course more important:)
<carsten> pitti: it doesn't even compile hello world here :-)
<Kamion> Tsingi: amen
<carsten> pitti: I dpkg'ed you deb and will test. Will let you know if everything links+runs here
<Tsingi> Kamion: 2 ascensions, 15 years:)
<Kamion> heh
<siretart> pitti: I tried 5ubuntu2.2, it 'works for me'
<pitti> siretart: yes, test suite is identical
<pitti> thanks for testing
<Tsingi> pitti: I forget how to do this manually, apt-get -i?
<carsten> pitti: survey/.libs/libsurvey.a: could not read symbols: Archive has no index; run ranlib to add one
<pitti> Tsingi: sudo dpkg -i foo.deb
<Tsingi> k
<carsten> but that might be another reason. /me cheack
<pitti> carsten: does that work with http://archive.ubuntu.com/ubuntu/pool/main/b/binutils/binutils_2.15-5ubuntu2_i386.deb ?
<carsten> pitti: another lib links
<carsten> ...
<carsten> pitti: I will test something else. If that also won't work I will test that ^^^^deb
<Tsingi> pitti: looking good
<elmo> pitti: grr, dude WTH are you doing?
<pitti> elmo: sorry, fixing ...
<pitti> elmo: upstream's patches seem to be broken...
<elmo> uh, which one?
<pitti> elmo: I tested some binutils programs, but didn't look at the test suiete
<elmo> the one I applied in Debian?
<pitti> elmo: no, that one is fine
<carsten> pitti: what was the problem with the old binutils? Was it worth the fuzz? ;-)
<Tsingi> pitti: another error, heh, but I think i forgot to install curses, so you're clear:)
<pitti> elmo: http://sources.redhat.com/ml/binutils/2005-05/msg00429.html or http://sources.redhat.com/ml/binutils/2005-05/msg00699.html
<pitti> elmo: I applied yours and these two since they were supposed to fix additional NULL pointers, etc
<pitti> elmo: now I reverted those and just used the one you applied, too
<elmo> pitti: I'd bet on the former, rather than the latter
<elmo> FWIW
<carsten> pitti: works (compiles+links+runs+doesn't crash)
<pitti> carsten: thanks for checking
<carsten> de rien
<pitti> carsten: the problem: http://www.ubuntulinux.org/support/documentation/usn/usn-136-1
<pitti> carsten, Tsingi: new debs are in the archive
<Nafallo> hmm, wasn't screem synced yesterday?
<seb128> no
<seb128> 0.14 doesn't build with gnome-menus 2.11
<Nafallo> ahh :-/.
<mooch> if x.org fscked in breezy?
<Nafallo> last package before I can switch to new dbus ;-)
<mooch> right now i get that it cannot find the "fixed" font
<ogra> doko, i know we already talked about it, but i forgot and now have a user request, will we have wxWindows/wxPython 2.5 in breezy ? pythoncard and boa-constructor seem to need it and boa is needed by Edubuntu
<pitti> brb
<doko> ogra: we will have 2.6, currently talking with upstrem/debian
<ogra> great, thanks :)
<Burgundavia> yay, non-ugly wxwidgets!!!
<ogra> but probably a lot broken apps that arent ported in time...
<Burgundavia> is 2.5/6 parallel installable?
<Burgundavia> s/is/are
<ogra> you mean 2.4/2.6
<Burgundavia> ya
<jbailey> In generally different versions of kernels are parallel installable, but Ubuntu doesn't support pre-2.6
<martink> mooch, some X fonts have moved from /usr/lib/... to /usr/share/.... Update your xorg.conf
<ogra> jbailey, we talk about wxWindows, wxPython :)
<jbailey> Whups, /me crawls back into his hole.
<jbailey> mooch: Data!
<zul> tut tut jbailey :)
<jnc> gahhhhh
* jnc grumbles something about "openoffice.org broke again!?!!?! on amd64. grr"
<mooch> jbailey: Jeff!
<cartman> the evil X.org bug has a patch now! see http://bugzilla.ubuntu.com/show_bug.cgi?id=10942
<jnc> Mithrandir: they broke OOo on amd64 again :(
<mooch> ups! no ubuntu-calendar-april/may ?
<Burgundavia> mooch, april exists on hoary, but not breezy
<jnc> oooh
<jnc> cartman: very good
<chris__> Hi
<jnc> cartman: i keep hitting "ctrl-x" thinking i'm going to cut text and instead in Evolution it sends the email message
<jnc> i'm absolutely traumatized by that bug
<trygvebw> hello chris__
<cartman> jnc: me too
<jasmuz> Hello all
<jnc> cartman: then i try to say something cool and collected about "hey, ignore that previous message i'm havving softwa"   
<jnc> after which i hit ctrl+x  ...
<chris__> I found an nasty bug in Gnome 2.10 :\
<cartman> jnc: hope daniels looks at it
<trygvebw> chris__, oh?
<jnc> then i send a third message "i'll give you a call.  sorry about the problems"
<chris__> trygvebw, The "Sticky Note" Applet (i dont know how its named in Englisch) is fucked up! In Warty and the "old" Gnome, the Notes were pinned to the Desktop
<chris__> in Hoary and the newest Gnome, the Notes are everytime in front of all Windows
<chris__> and this sucks!
<jasmuz> People i have this problem, can anybody help ? http://ubuntuforums.org/showthread.php?t=36596
<Treenaks> #ubuntu for user support please
<trygvebw> Treenaks, nobody knew his answer there...
<trygvebw> *the
<chris__> i think its a bug... or not?
<trygvebw> chris__, it's a feature, afaik :)
<jasmuz> Treenaks, i was sent from there to here
<chris__> trygvebw, but i hate this feature ;p i want to de-activate it ...
<trygvebw> chris__, check in sticky settings
<chris__> i cant set up things like this...
<jnc> chris__: you can check on the gnome website and see screenshots of the sticky app
<jasmuz> Anyways thanks for the help
<jnc> chris__: ask around in #ubuntu if other people have the same condition
<chris__> okay
<chris__> :)
<chris__> jnc, hmm i am Moderator of an German Ubuntu-Forum :D
<chris__> There is an big thread about this.. and 10 or more People have the same Problem
<ogra> chris__, bugnumber ?
<chris__> i don't know if its postet already...
<chris__> i dont know how the "name" is of the Applet (i am German :\)
<jnc> chris__: if it's not posted already,  file a bug report include screenshots and config files
<ogra> so how should we fix it ? nobody here reads forums
<chris__> here its named "Klebezettel" :D
<jnc> if you got a bug # then we can always rename it in the future
<chris__> :)
<chris__> where i shoud post it?
<ogra> jnc, i see nothing wrong with the name :)
<ogra> chris__, bugzilla.ubuntu.com and please advise your readers to post bugs to make them visible for us ;)
<chris__> okay :)
* ogra curses xscreensaver
<ogra> chris__, whats wrong with "klebezettel" do you have a better suggestion ? (i think you cant call it post-it's because the name is trademarked) 
<chris__> i dont unterstand..?
<ogra> i thought you were complaiuning about the translation too :)
<chris__> O_o
<chris__> i found this on the Gnome-Website:
<chris__> "And sticky notes now stay on top other windows, so you can't lose them. To hide the notes, simply use the applet's right-click menu."
<ogra> chris__, then its obviously a feature :) file a bug at bugzilla.gnome.org
<chris__> okay... :)
<chris__> thank you :p
<ogra> since its their decision
<ogra> youre welcome
<seb128> don't fill it
<ogra> seb128, why ?
<seb128> there is already a bug and some dups
<seb128> upstreams don't need dups
<ogra> oh, ok...
<ogra> seb128, btw, shouldnt we drop this applet, since we'll ship tomboy ?
<seb128> the applets work :p
<ogra> tomboy too :P
<chris__> :P
<ogra> seb128, its just redunant...
<seb128> anyway I don't think we should drop gnome-applets parts
<Burgundavia> seb128, but any bug triager loves dups. They validate their existence!
<seb128> just way to piss upstreams
<ogra> oki
<seb128> and for my part I use sticky not rather than tomboy
<seb128> I should try tomboy again
<ogra> yeah
<ogra> its quite good since it left the notification area
<ogra> and has a new icon ;)
<seb128> can you change the fonts now?
<ogra> yep, in the settings
<ogra> ARGH !
* ogra kicks and beats xscreensaver
<ogra> darn thing
* Treenaks puts ogra and jwz in one room together
<chris__> Tomboy is god? ;P
<ogra> Treenaks, nah, its not jwz's fault....
<ogra> Treenaks, either some build system changes that it cant cope with or the xorg change....
<Treenaks> ogra: oh..
* Treenaks puts ogra and daniels together in one room
<ogra> (i'm trying to compile the hoary version currently.... so our "colonial master" can make the next colony)
<Unfrgiven> elmo: ping
<elmo> Unfrgiven: ?
<Unfrgiven> elmo: can we pull the package freemind from unstable to universe?
<doko> elmo: could we move OOo2 back to universe for a while, so that's buildable again?
<Kamion> ogra: haha
<ogra> :)
<Kamion> doko: er ... desktop kinda depends on it
<elmo> doko: what's the state of bringin in NEW packages - safe to do yet?
<Kamion> d'oh, I broke debconf passthrough progress
* Kamion fixes
<Tsingi> what would a pair of snow boots for 8 zorkmids be?
<Tsingi> heh, hey Kamion
<Kamion> ECHAN :)
<Echylo> 8 zorkmids?
<Tsingi> oops, mis-chan:)
<Tsingi> sorry
<Kamion> but elven/kicking
<Treenaks> Tsingi: fumbling
<Echylo> sandals?
<Tsingi> not cursed
<Kamion> Treenaks: too cheap
<Treenaks> Kamion: they're /always/ fumbling for me :)
<Tsingi> ok, prolly, sorry for the OT:)
<jeroen_> Will there be a ubuntu-calendar-may package? (Yes, this should be in #ubuntu, but they don't know the answer, and you are the people making packages)
<elmo> Unfrgiven: atm NEW packages are frozen
<Kamion> jeroen_: jdub normally does those
<elmo> Unfrgiven: but once that's released new packages from Debian main/contrib will be auto-pulled in
<Kamion> don't think anyone else will know. :-)
<jeroen_> Kamion, well, I was just wondering.. I mean, it's the 27th.. not much of May left, huh?
<Unfrgiven> elmo: hmmm so are you saying ALL main/contrib packages or just the ones we've already selected?
<elmo> all of them, except the ones we explictly blacklist
<Treenaks> jeroen_: jdub is in some weird Australian timezone.. ask him when he's awake :)
<mdz> ogra: pong
<ogra> Unfrgiven, i.e. the ones we already changed
<Unfrgiven> elmo: ok. do we have a page listing the blacklist?
<jeroen_> Australia is +7, right? Then he'll be asleep
<ogra> mdz, we should talk about edubuntu once you have time :) i saw you already dd ltsp packages
<ogra> did even
<Unfrgiven> its 1:45am here in Sydney right now
<mdz> ogra: the current ltsp packages are a non-working prototype, but I have made some progress
<ogra> mdz, bsed on the src.rpms they provide ?
<ogra> based...
<ogra> or totally new ones ?
<pitti> seb128: btw, my xorg control key breakage is back, so I can try to fix it with daniel's method...
<mdz> ogra: src.rpms?
<pitti> Hey mdz
<mdz> ogra: this is something new
<ogra> mdz, ltsp.org has source rpm packages
<mdz> ogra: ThinClientIntegration should explain
<mdz> pitti: morning
<ogra> mdz, i would also like to get rid of NIS .... and introduce LDAP/kerberos...
<fabbione> morning mdz
* ogra reads up
<mdz> ogra: in what context?
<mdz> usually LTSP does not use any distributed authentication
<Unfrgiven> alright all im going to head off, good night
<ogra> mdz, edubuntu uses NIS 
<mdz> ogra: it does, why?
<ogra> mdz, at least in the spec
<seb128> pitti: https://bugzilla.ubuntu.com/show_bug.cgi?id=10942 has a comment about what causes the bug and a patch
<ogra> mdz, no idea, i'll ask james/colin
<Burgundavia> ogra, Netscape DS is should be released this month as GPL. Shall we annoy RH and have it in Ubuntu before they ship it in RH?
<Treenaks> ROFL
<ogra> Burgundavia, package it ;) its a great project for a upcoming MOTU
<Burgundavia> ogra, I can barely do games right now. I am not touching a server app
* ogra remembers thats the same sentence that led to hula packages .... 
<Burgundavia> but I am also waiting for tseng and his happy IntroDeveloperDocs
<torkel> ogra: are you using afs in edubuntu? or do you have any plans doing so?
<ogra> torkel, we have several option here... the latest nfs would be my choice, since we have it already ... tanks to jbailey
<Mithrandir> jnc: I guess I'll have to fix that, then.
<ogra> options even
<torkel> ogra: you mentioned ldap/kerberos and in that context afs is a good choice
<ogra> torkel, i'm just determining the options and the best choices we have without generating extra work...i'll look deeper into afs
<dholbach> hey
<dholbach> seb128: did you try the xorg patch already?
<ogra> dholbach, the one that reverts to a working version ? :)
<seb128> dholbach: no
<dholbach> hmm... either I was too dumb to apply the patch correctly or it breaks X even more :(
<seb128> :(
<dholbach> i wasnt able to type a single thing at gdm - everytime a silly popup appeared for ever keystroke
<dholbach> ok... i'll give it another try
<dholbach> *wave*
<Micksa> okay, someone explain the need for ssh's HashKnownHosts to me
<Kamion> Micksa: slows down attackers who've got into your system from immediately getting into the other systems you ssh into regularly
<KaiL|Sheep> Micksa: to find modified systems
<Kamion> (yes, it's just one vector of attack, and there are others such)
<Micksa> well then they should hash bash_history too
<Kamion> "they"
<Micksa> theo :)
<Kamion> theo != bash maintainer
<Kamion> anyway I believe there's a patch somewhere to implement configurable exclusion from .bash_history
<Micksa> I'm trying to be funny
<Micksa> work with me here
<Kamion> ah, no, don't need a patch
<Kamion> set $HISTIGNORE
<fabbione> elmo: can you please start syncing partman-auto-lvm from debian? i saw it in the debian archive, but never automagically imported...
<Micksa> the thing that worries me about HashKnownHosts is
<Micksa> what if a key becomes bad?
<Kamion> so if you're paranoid, HISTIGNORE=ssh
<Micksa> for valid reasons
<Kamion> Micksa: see the changelog, which I wrote carefully :-)
<Kamion> ssh-keygen has new options for managing known_hosts
<Kamion>       files, which understand hashing.
<elmo> doko: ping about NEW
<Micksa> oh, this is your doing? :)
<doko> elmo: pong
<Kamion> I made that release of the openssh package, yes; I'm not upstream
<Kamion> and I decided it was worth trying out HashKnownHosts as default
<Micksa> okay
<elmo> doko: what's the state of bringin in NEW packages - safe to do yet?
<Kamion> I don't think it merits a security update or anything, but it does seem to be a worthwhile tightening-up
<Kamion> we'll see how it goes
<Micksa> meh, I'm too tired
<Kamion> rather unfortunately the -R option is missing from ssh-keygen --help, but it's in the man page
<doko> elmo: the only thing we can do it to review for build-deps on C++ libraries.
<doko> s/it/is/
<Micksa> why does my hoary box want to download 343M of packages? I thought it was "released"
<Micksa> pardon my ignorance
<elmo> doko: how do you mean?
<daniels> Micksa: 'updates'
<daniels> Micksa: security and otherwise
<Kamion> security updates - or you accidentally switched to breezy :-)
<Micksa> oh never mind. I last updated this box ages ago :)
* Micksa shuts up
<trulux> argh, mpt: I'm wiki'ng the sec. center stuff
<doko> elmo: I think you can only decide it on a case by case basis. If the new package build-deps on a not-yet-converted cxxlibs package, then it has to stay out. how many are in NEW at the moment?
<trulux> anyone here is able to see encrypted wmv streams in mplayer?
<cartman> only those with jedi eyes
<trulux> cartman: hah, I'm still getting annoyed with it
<trulux> weird that I need to process this scholl shit wmv things
<trulux> s/scholl/school/
<Micksa> does apt-proxy still suck?
<cartman> trulux: well 1) #ubuntu for help 2) Search google for "wmv drm broken japanese"
<cartman> some japanese guy broke the drm but you need windows
<cartman> to de-drm
<elmo> doko: if a library's not yet converted, what's the harm in bringing in another app compiled against it?
<Micksa> I feel inclined to look for someone that's set up squid to act as a comparable archive cache
<doko> elmo: mixing new and old C++ ABI
<trulux> cartman: wine would work right? I have NFC on Windows apps. to do the job
<trulux> cartman: and I have no bitching windows here
<elmo> doko: OK, but it's a temporary thing which will be fixed, because we'll know we need to recompile it by the dep on the unconverted library
<cartman> trulux: well you need to run wmp9 afaik
<elmo> (well, or we would, if we'd used a non-completely-fucking-insane naming scheme)
<trulux> cartman: OK, thanks
<elmo> doko: basically, does it make the transition any harder?  if the answer's no, I want to do it.  I don't care if the built binary might be broken, it's a NEW package anyway, as long as we'll fix it eventually
<doko> elmo: ok, there could be some apps linking static libs, which we would miss, but anyway
<Kamion> (ah, sorry, HISTIGNORE='ssh*')
<trulux> cartman: http://home.wanadoo.nl/lc.staak/freeme.htm <- hope to not need to port this to our beautiful, holy and legal lands
<trulux> cartman: 'cos of points 1 and 2 of my work terms: 1) porn in wmv format 2) other stuf fin wmv format
<doko> elmo: ok, besides this corner case, the answer is no
<elmo> doko: static linking?  we're screwed there, regardless of NEWness, aren't we?
<elmo> iff the package only ever static links to C++ libs
<cartman> ha :)
<trulux> seems that I will to port this shit
<doko> elmo: true, but we will detect it, iff the library is provided as .a _and_ .so
<trulux> woaha shiiit man! WTF
* trulux relax set to ON
<elmo> doko: ok
<doko> elmo: so how likely is that case?
<elmo> doko: err, I don't know.  I think not very, and I don't think there's anything we can realisitically do about it
<doko> elmo: ok, then open the gates :-)
<elmo> as long as we don't change the -dev name, in any event
<doko> it would be nice to have a build-dep to detect C++ code ...
<elmo> which we can't do without changing build-essential, and we really want to do that in conjunction with Debian
<dholbach> :(
<ogra> dholbach, just buy another keyboard that works...
<dholbach> ogra: you know, it's quite hard for me to stick to the CoC atm :)
<dholbach> hrm
<ogra> i can imagine that.... daniels is probing us all hard
<Kamion> elmo: reping, libdebian-installer sync request
<elmo> Kamion: done
<elmo> fabbione: done
<fabbione> elmo: thanks
<g14> http://lwn.net/Articles/135685/ Has the kernel ELF vunlerability mentioned here been updated? I don't see any kernel updates
<siretart> elmo: please sync pinfo from unstable, overriding ubuntu changes (they are included)
<Burgundavia> g14, http://people.ubuntu.com/~pitti/ubuntu-cve/fixed.html CVE's in Ubuntu
<Kamion> ta
<g14> Burgundavia: Thanks, it's been fixed. I wasn't sure
<Burgundavia> g14, np
<zul> meh...excelent...linux-image-2.6.12-1-686-dbg
* ogra hugs seb128 for fixing his favorite editor
<seb128> np :p
<ogra> but libxt will get dropped from main iirc...
<Kamion> ogra: er?
<Kamion> that seems a bit unlikely seeing as how half the world depends on it
<ogra> Kamion, dainels disabled it explicitly...
<ogra> err....sorry i mddled it with lesstif
<ogra> muddled even
<Kamion> very muddled :)
<ogra> its simply to hot for my brain to work right today 
* mdke nods
<Kamion> I know the feeling
<mdke> i'll second that
* ogra gets some iced orange juice
<mdke> how can it be 29 degrees in england in may
<mdke> the world is going crazy
<ogra> yeah
<\sh> mdke: here it was max. 35 degree
<\sh> i was melting
<ogra> here too
<Simira> lovely
* Simira looks out at the rain
<Simira> some sun would be nice now
<Kamion> night all
<Simira> night Kamion 
<Kamion> have a good weekend
<\sh> Simira: come to germany :)
<\sh> night Kamion 
<ogra> Kamion, xscreensaver built btw.... ppc not done yet...
<ogra> oh, correction, just done
<stockholm> hi!
<stockholm> any edubuntu people arround?
<tseng|work> see ogra.
<stockholm> http://wiki.debian.net/?DebianEduAtDebconf5
<stockholm> tseng|work: was that for me?
<tseng|work> es
<tseng|work> *yes, you are the only person here
<stockholm> tseng|work: i am just coming, i cant know. (c:
<ogra> stockholm, heya
<stockholm> orga: hi!
<tseng|work> that doesnt look very similar to our system
<stockholm> ogra: what do you work on?
<ogra> stockholm, http://udu.wiki.ubuntu.com/Edubuntu
<stockholm> ogra: yes, i know the page
* stockholm checks if there is anything new
<ogra> stockholm, i just got Edubuntu assigned, i'm currently reading up on all the stuff....
<tseng|work> we just packaged ltsp for a start
<tseng|work> you can get in on the ground floor
<stockholm> ogra: do you know that we are cooperating? (c:
<ogra> stockholm, i was hoping so...
* ogra has the responsibility for edubuntu since two days.... 
<ogra> so i'm curretly looking at the different projects that are there
<stockholm> ogra: cool.
<stockholm> ogra: i am a debian-edu developer
<ogra> stockholm, yes, i grokked that ;)
<ogra> stockholm, will you be in bergen ?
<stockholm> ogra: we can take this to query and contiune in german
<stockholm> no
<ogra> :(
<stockholm> my wife booked a short term vacation then
<dholbach> tritium: hey michael
<tritium> hi dholbach :)
<\sh> hey dholbach 
<dholbach> hey \sh 
<\sh> hmm..i think it's ok when I'm drinking red wine while it's hot *hicks* ;)
<dholbach> *snigger*
<\sh> the shiraz from yesterday..ZA western cape area
<tritium> dholbach, I'll see you next week.
<dholbach> tritium: have a nice weekend michael :)
<tritium> you too!  bye!
<ogra> grrr
<tseng|work> ogra ?
<ogra> they killed my netblock, my server isnt reachable....
<tseng|work> ugh
<ogra> not the fun i like on fridays at 10:30 pm....
<tseng|work> yeah its 4:30 here
<tseng|work> i *need* to get out of work
<mdke> pm i hope
<tseng|work> yes
<mdke> ;)
<\sh> ogra: u called them?
<ogra> \sh, nope
<ogra> \sh, no need to
<ogra> \sh, i guess it was a broken UPS
<ogra> \sh, 10 IP's above and below mine were gone, now everything runs again.... i could shoot them, they broke my uptime statistics
<\sh> shit
<\sh> and I'm playing with wine and elsterformular
<\sh> i need to make my taxes
<dholbach> *wave*
<tseng> hi dh
<tseng> er.
#ubuntu-devel 2005-06-04
<kent> This is perhaps OT, but while creating a control file for a .deb package, I stumbled over the fact that it wont install if I depend on libgtk2.0. Whats the correct line to get it to depend on libgtk2.0? 
<dholbach> ROCK
<dholbach> IT WORKS :)
<dholbach> haha... the ctrl-keys work :)
<tseng> dholbach: hm?
<dholbach> bug #10942
<dholbach> one of the two most annoying bugs atm :)
<tseng> yep
<dholbach> this makes me happy :)
<tseng> good job
<dholbach> roderich's job :)
<dholbach> good night everyone
<jordi> fun, alsa 1.0.9
<srbaker> mozilla is quite broken after my upgrade today
<srbaker> i keep getting XML parsing erros on the chrom
<srbaker> chrome
<camilotelles> mdz, hey there
<tseng> srbaker: did you happen to restart the browser completely?
<srbaker> ahh, maybe not.  i forget
<srbaker> just did ti now
<tseng> pretty well known issue, #ubuntu next time
<camilotelles> mdz, do you have some time to talk about some QA activities and other stuff?
<mdz> camilotelles: sure
<camilotelles> mdz: here or ubuntu-meeting or private?
<mdz> camilotelles: here is fine
<camilotelles> ok. kiko talked to me about the script and the problems with the code. I agree totally.
<camilotelles> I agree with the idea of our group to do some QA to the installer.
<camilotelles> we have some machines here, and we can help to test in some diferents motherboards, processors and architetures. We receive some stuff right after or before the launch. Ex: we had one intel engineering motherboard last week with us to do some testing. And next week we will receive a new Athlon 64 motherboard from MSI
<mdz> camilotelles: sounds good
<camilotelles> mdz: We want to test/use the OEM stuff too.
<mdz> camilotelles: Kamion should be your contact for OEMInstaller
<KaiL> if you want something, that breaks, get Asus (or play with silly SATA controllers...)
<camilotelles> this last machine had an SATA. 
<camilotelles> s/an SATA/a SATA/
<camilotelles> and the final performance was less than using it with IDE.
<camilotelles> we don't have access for ASUS stuff. we have access for MSI and Intel stuff.
<KaiL> camilotelles: but intel SATA controller? that one seams to be rather unproblematic. Get some SiS- or ATI-Crap :)
<camilotelles> Maybe in this Athlon motherboard we will have some SiS or ATI. I will know in the monday.
<KaiL> nVidia is a bit more common :)
<KaiL> ..and seams to work perfect, as long as the Bios doesn't break anything
<camilotelles> mdz: we want to have a Ubuntu i386 repository here. Maybe I can in the future be a public repository. We have a good internet connection but i have to negotiate with more people about this use.
<KaiL> even more EVERYTHING seams to work, as long as the Bios doesn't break anything......:(
<mdz> camilotelles: if you decide that you want to be an official mirror, talk to elmo
<camilotelles> mdz. Ok. it's possible to us build the live CD from repository? how can I do this? 
<mdz> camilotelles: not in a straightforward way.  why?
<camilotelles> mdz: we want to customize the live  CD. change some packages, add some brazilian stuff. Our idea is to generate two ISO's. One exactly egual to the original ISO and another with our stuff.
<mdz> camilotelles: www.ubuntu.com/wiki/LiveCDCustomization
<mdz> you don't need to rebuild from scratch; you can customize the ISO
<camilotelles> mdz: it's exactly the way that we do today, but we don't like it.
<mdz> camilotelles: it is much simpler
<mdz> camilotelles: what is the problem that you have with it?
<camilotelles> mdz: because we think that this way is ok to do an one time customization. But if we want to track the changes is very complicated because of the possible modifications in the base ISO.
<mdz> camilotelles: it seems just as complicated to track changes if you build from scratch: if you are only modifying packages, it is easy in both cases, and if you are doing something other than modifying packages, the issues are the identical
<camilotelles> today we implemented this  using the knoppix. we integrated the one build process that we take a ISO image from the knoppix, customize it and generate a new ISO in one unique step. 
<camilotelles> mdz: All the stuff that we add to the ISO is inside one subversion repository.
<mdz> camilotelles: why can you not do the same with ubuntu?
<camilotelles> mdz: Our idea is to put the build process of the live CD inside the subversion. We think this will increment our configuration management.
<mdz> camilotelles: it seems to me like additional complexity without additional benefit
<camilotelles> mdz: Don't you think that we being able to follow the diferences of a live CD to another during the development might make our life easier in the customization process? How can we identify if any customization that we did is conflicting with something that was generated by the main build of live CD.
<camilotelles> mdz: we have this kind of problem today with the knoppix.
<mdz> camilotelles: I understand your concern, but building the live CD from scratch does not address this problem
<mdz> camilotelles: perhaps you can give me a specific example of a scenario where it helps?
<camilotelles> we use some package that disappears from the original ISO.
<camilotelles> mdz: our we change some script that is changed in the original ISO.
<camilotelles> mdz: if we do it, only once, is easy. If we do it in a process we have to track down without help from an changelog.
<mdz> camilotelles: if you use a package, you should declare aa dependency on it
<mdz> then there is no problem
<camilotelles> mdz: we generate our customizated ISO everyday for some kind of smoke test.
<mdz> or if you want a stable base where that will never happen, you can use Ubuntu 5.04
<camilotelles> mdz: why you think this is a bad idea?
<mdz> camilotelles: because it is complex and fragile, and we already do it for you
<camilotelles> do you have any changelog from one version to the other?
<mdz> I can't understand why you would want to do this
<mdz> one version of what to the other?
<mdz> I don't think I am understanding you very well
<camilotelles> development versions. do you build daily?
<mdz> yes, we usually build a new live CD daily
<mdz> currently it is disabled
<mdz> development versions of what?
<mdz> of the entire distribution?
<camilotelles> nope. the live CD.
<mdz> if so, no, we cannot possibly have a changelog
<mdz> every day there are hundreds of packages changed, including new versions from upstream
<tseng> camilotelles: eh the livecd is largely affected by the packages that are seeded being changed
<tseng> only during early development is there constant change to casper, di and friends
<mdz> I don't have any instructions I can give you for building the live CD, but I really think it is not the best way to accomplish your goals
<camilotelles> mdz: I'm starting to agree with you.
<camilotelles> mdz: when something breaks the build how do you track it down with hundreds of changes?
<mdz> camilotelles: when something breaks the build, we read the log and diagnose the problem
<camilotelles> mdz: build log?
<mdz> yes
<camilotelles> mdz: I'll forget about this idea to duplicate this build process here. I will port our solution to ubuntu and start the customization stuff.
<tseng> camilotelles: hey be on the lookout at mono-live.com
<tseng> camilotelles: he is planning to post the scripts he used in the process to simplify building
<tseng> im sure you already read luis's work on the wiki?
<robertc> mjg59: pinghttp://gmail.google.com/gmail
<robertc> bah
<robertc> mjg59: ping
<camilotelles> mdz:I'll talk with elmo about the repository and Kamion about the QA for the installer and OEM.
<camilotelles> mdz: thanks for your patience.
<mdz> camilotelles: no problem, let me know if you have further questions
<camilotelles> tseng: I'll be looking at it. thanks too.
<camilotelles> tseng: what wiki?
<tseng> http://www.ubuntulinux.org/wiki/LiveCDCustomizationHowTo/
<camilotelles> tseng: yes, we already do something very similar in our work with knoppix.
<camilotelles> tseng: we had automated it and 
<camilotelles> tseng: we put all our customizable stuff inside subversion and do everything in one reproducible step.
<tseng> great.
<camilotelles> tseng: we can generate every ISO since the beginning of our work.
<tseng> hi ankur 
<Unfrgiven> tseng: hey dudde
<tseng> +1 funny, the wordpress guys are promoting mod_security
<fabbione> morning
<\sh> hey fabbione 
<srbaker> yo.  can i burn DVD+R discs with a default install?
<Lathiat> srbaker: yep
<srbaker> Lathiat, in gnomebaker, it only lists -, so i wasn't sure if it knew how to do both
<srbaker> and it won't list "DVD image" only "CD image"
<Lathiat> srbaker: youc an either right click an iso in nautilus to write it to cd or open the cd creator (comes up when you insert a blank disk) -- Also these questions are suited to #ubuntu, this channel is for development discussion
<Lathiat> srbaker: theres no difference really ones just bigger than the other
<srbaker> wait.  if i right click the iso and choose "write to disc" it burns it as an image?
<srbaker> cool!
<srbaker> Lathiat, there are compatibility and formatting differences, but i'm aware of those
<Lathiat> srbaker: -> #ubuntu please
<mvo> ping ogra 
<cartman> yay daniels =) /me checked his bugzilla mail for #10942
<bob2> does apache2 Just Work with files > 2GB these days?
<elmo> no
<elmo> enabling LFS is an ABI bump (-> all modules recompiled, pkg name changes, etc.), so it hasn't been done for apache2 yet
<\sh> is it planned for breezy?
<\sh> elmo: btw...thx :)
<fabbione> hey elmo
<elmo> hey fabbione 
<elmo> \sh: np
<elmo> \sh: and, I don't know offhand, sorry
<bob2> elmo: ah, thanks
<\sh> elmo: we should put it on the list ;)
<elmo> I know the 2.1 packages enable it by default, but I don't know what the release timetable for 2.1 is
<elmo> (this is why *.ubuntu.com with > 2Gb files is using 2.1...)
<zyga> hello :-)
<zyga> this is probably due to transition but I thought I should ask
<zyga> zyga@falcon:~$ sudo dpkg --configure metacity
<zyga> Setting up metacity (2.10.1-1ubuntu2) ...
<zyga> update-alternatives: slave link name /usr/share/man/man1/x-window-manager.1.gz duplicated
<zyga> shoud I file a bug?
<\sh> fck
<\sh> it happened again...dput is broken
<zyga> \sh: ?
<\sh> i forgot to say "dput ubuntu" so now what happens? it uploads to debian (doko will kill me this time)
<\sh> but in the /etc/dput.cf the default_host_main is not set and therefor it takes the first host in the list
<\sh> ftp-master of debian in this case 
<zyga> \sh: I see :>
<\sh> i'm really annoyed of this
<\sh> this shouldn't be the default behaviour
<\sh> ha..now i'm a bit *censored* 
<zyga> \sh: that's pretty annoying I guess :-)
<\sh> now i have to appologize to the debian devs...*hardstuff*
<zyga> \sh: do you think I should file a bug about that duplicated thing above?
<\sh> zyga: why not :)
<fabbione> elmo: do you happen to remember the binary link policy for biarch? example: package foo and libfoo libfoo64. to which lib foo should link?
<fabbione> elmo: or should i provide foo64? given that having 64 libs without binaries is pointless
<elmo> fabbione: unless there's a major performance reason to do so, link to libfoo
<elmo> the poing of 64 bit libs is to enable people to compile stuff that cares (e.g. postgres or something) 64-bit
<elmo> s/poing/point/
<elmo> at least, that's how I understand things for our current hybrid arches (sparc, powerpc) where 64-bit isn't enough of a benefit to do it by default
<zyga> \sh: done, #11273
<fabbione> elmo: right.. i was talking exactly about sparc and ppc64 ...
<fabbione> elmo: thanks :)
<elmo> np
<Treenaks> Agh.. 20th person this week in #ubuntu-nl who thinks swap is only for people with <512M RAM
<mdke> sounds like you have a busy channel there
<Treenaks> mdke: it is quite busy, yes
<mdke> cool
<\sh> is python-qt3 moved to universe now? 
<ogra> mvo pung
<ogra> *yawn*
<mdke> where could this page be parented? http://www.ubuntulinux.org/wiki/UpdateManager
<mvo> hey ogra! good morning :)
<mvo> ogra: do you have a train now? will we be in the same train
<ogra> mvo, i'm just opening my eyes...
<mvo> ogra: hehe :)
<ogra> mvo, if i make it to get the train at 2:24pm, i'll be on the same ICE
<mvo> ogra: I use the ice at 14:49 (at bochum)
<ogra> mvo, i have to get to cologne first....
<mvo> ogra: my trains goes over colonge and stops there at 15:54
<mvo> ogra: ah, got it now
<ogra> mvo, yes, thats why we'll be on the same train if i make it :)
<\sh> guadec?
<ogra> \sh, something where KDE people never go ;)
<Amaranth> GNOME Users And Developers European Conference?
<Amaranth> completely expanding acronym's like that could take awhile
<Amaranth> acronyms with acronyms with recursive acronyms
<ogra> \sh, http://2005.guadec.org/
<\sh> ogra: yeah...saw the announcement :)
<Riddell> ogra: actually there's quite a few KDE people planning to go to guadec
<ogra> Riddell, will you ?
<Riddell> ogra: no
<ogra> :-/
<Riddell> ogra: but you should come to akademy
<ogra> Riddell, get over to the *right* desktop ;)
<Riddell> I think we should stop there before it gets out of control :)
<\sh> Riddell: when is akademy?
<Riddell> \sh: end of august, conference2005.kde.org
<ogra> Riddell, you know i'm not serios 
<mdke> shouldn't it be konference?
<ogra> hehe
<Riddell> ogra: yeah but I am :)
<ogra> lol
* ogra knew Riddell would say that
<Riddell> mdke: there are tales of Miguel complaining at LinuxTag about all these signs saying "Konference" thinking they were make by KDE fans
<\sh> 7topic Riddell vs ogra: which is the right desktop, come join the mess, see how our gnome and kde dinosaurs fighting with bare hands and teeth ,->
<mdke> Riddell, *laughs*
<mvirkkil> Is anyone seeing this with breezy: gedit (and ajunta) think every shortkut (ctrl+c, ctrl+s etc) is ctrl+n
<mvirkkil> It's freaking annoying not being able to use keyboard shortkuts.
<HiddenWolf> Well, KDE is cool, but the K in front of everything gets a bit repetititve. :)
<HiddenWolf> What's the name of that app again? K... something! ;)
<mvirkkil> HiddenWolf: Yes, because gedit, gconf, gcalctool etc is so different ;-)
* Riddell did not name kubuntu
<mdke> Riddell, http://www.uk.gnome.org/index.php?page=GnomeUKMarkers <-- we need one
<mdke> HiddenWolf, agreed
<mdke> HiddenWolf, in the docteam they started doing it with documents ;) kwickguide
<Riddell> mdke: UbuntuWorldWide?
<mdke> Riddell, i was thinking a uk one
<mdke> Riddell, but the worldwide one is cool yeah
<HiddenWolf> mvirkkil, G is just much sexier. ;)
<mdke> not as hard a sound
* HiddenWolf backs out before someone comes at him with a katapult :)
<\sh> hehehe
* mdke draws his gsword
<mvirkkil> The problem with this g* and k* stuff is that when there is a program like gwenview, you assume it's for gnome, and it's actually a pgoram for kde.
<mvirkkil> gsword=ghotscript word?
<mvirkkil> ghostscript word, even
<mdke> Riddell, any idea how those maps are done?
<rrichie> hi all
<rrichie> can i downgrade from breezy to hoary ?
<Riddell> mdke: with xplanet
<Riddell> mdke: jdub has the scipts
<mdke> you think they work for individual countries?
<mdke> i'll ask him
<mdke> rrichie, http://www.ubuntulinux.org/wiki/DowngradingFromHoaryHowTo might help, #ubuntu might also be able to help
<ogra> rrichie, technically yes, but it will cause 10x more pain that areinstall
<ogra> then even
<ogra> i would do a hoary reinstall
<rrichie> arg
<ogra> since nobody can guarantee that your system will work after a downgrade
<ogra> and you will surely have a lot breezy leftovers
<rrichie> ;(
<ogra> did nobody warn you ?
<rrichie> yes but i wanted to try, thinking i could downgrade easily
<ogra> nope, the up direction is fine... the down direction is a PITA
<ogra> pitti, !
<ogra> pitti, not on your way to guadec yet ?
<pitti> ogra: no, I'm not going to Guadec
<ogra> :(
<ogra> sad
<pitti> ogra: but I go to debconf5, do you?
<ogra> pitti, i doubt it... i'll likely be in london...
* pitti_ grumbles about kernel oopses
<mvirkkil> Is anyone seeing this with breezy: gedit (and ajunta) thinks every shortcut (ctrl+c, ctrl+s etc) is ctrl+n
<mvirkkil> All keyboard shortcuts are therefor unusable.
<tfheen> mvirkkil: yes, known issue.
<ogra> tfheen, stuttgart ?
<tfheen> ogra: no, I'm still doing my master's thesis
<ogra> ah, sad... i thought because of the nick
<tfheen> nah, just doing some upgrades on vawad.
<tfheen> moving a terabyte of data aroud.
<ogra> uff
<tfheen> nah, I'll end up with 3x400GB more disk space, so that's nice.
<ogra> but a moving a terabyte is quite time consuming...
(seb128/#ubuntu-devel) grumpf
(seb128/#ubuntu-devel) verbiste has a lib right, but nothing use it
(seb128/#ubuntu-devel) we agreed that it doesn't need a rename or anything
(seb128/#ubuntu-devel) elmo: I'll sort all that with doko, thanks
<maswan> elmo: but if you don't mind too much, could you check the firewall for settings on idle tcp connections or something like that, if there are any?
<seb128> daniels: dude, libxres-dev should Depends on libxres1, no?
<elmo> maswan: I ramp up tcp_rmem and tcp_wmem, but otherwise it's unmodified linux default 2.6 settings
<elmo> (and that ramp up is on syncproxy, obviously)
<seb128> it breaks libwnck/gnome-panel on amd64 with a -fPIC issue (it uses the .a since the .so is not here)
<maswan> elmo: nod
<maswan> elmo: if this doesn't work, I'll try upgrading rsycn and see if that works.
<hunger> quit
<eruin> hey lads... I just stumbled upon http://udu.wiki.ubuntu.com/AudioCDBurning , and I was wondering if seb128 or ogra have been tracking rhyhtmbox 0.9
<eruin> wouldn't it be good to focus some effort on getting that in too?
<eruin> I'd say the default music application is definately the best suited to burn audio cds ;-)
<Burgundavia> eruin, does .9 have burning?
<eruin> yep
<eruin> it uses nautilus-c-b too
<eruin> I'm not sure how much activity is in the official repository, but I know it's in there, and the current active repository (olemke@core-dump.info--2005/rhythmbox--merge) includes substantial upgrades that might be in ubuntus interest to track ;)
<jordi> who is olemk?
<eruin> Oliver Lemke on the rhythmbox-devel list
<eruin> pretty much any traffic on there revolves around that repo
<jordi> nod
<jordi> I'm glad to hear someone has picked it up
<jordi> I assume walters is not active at all anymore?
<eruin> I haven't heard or seen him in eons
<jordi> how far is 0.10.0?
<eruin> I think they're going for a gnome 2.12 release
<jordi> oh, that is so good news!
<eruin> yeah
<Amaranth> maybe rhythmbox won't suck anymore! ;)
<eruin> right now I think it's fabulous
<Amaranth> but seriously though, i'm using it now
<Amaranth> it's just annoying sometimes
<Amaranth> like showing you the metadata but not letting you change it
<eruin> --enable-tag-editing you say? .o
<jordi> afaik, that's in 0.9
<eruin> yeah
<eruin> they're still calling it experimental though
<jordi> seb128: dude package it :)
<jordi> eruin: bah ;)
<eruin> I havent had a single problem with it, but I guess they don't call it experimental for nothing ;P
<Burgundavia> I have one issue with burnign within rb, what about those of us who don't use it?
<jordi> Burgundavia: well, there's people who don't use nautilus
<eruin> that's a nice use case for serpentine
<Burgundavia> yes
<Amaranth> it wouldn't even be that annoying if they would use labels for the metadata instead of textviews
<eruin> but since rhythmbox is the default audio app, it makes perfect sense to use it for audio burning too
<Burgundavia> I don't mind integrated burning, but Ubuntu must provide another way as well
<Amaranth> i think there should be a library to handle audio cd creation that all these apps can use if they want
<eruin> yep
<eruin> I just think we need to push the rb guys to make it in time for breezy
<Amaranth> that way we can have Do One Job And Do It Well and Do It All It's Easier To Use
<eruin> they all use n-c-b
<Amaranth> eruin: Well, if they make 2.12 they can probably make breezy.
<eruin> yeah, the question is whether or not they will
<eruin> :P
<eruin> with all active development happening in a nonofficial repo...
<Amaranth> gnome things are the last to freeze, aren't they?
<Amaranth> eruin: All the development happening in an unofficial repository just shows off how useful arch is. :)
<eruin> hehe
<eruin> true, true
<kent> Amaranth, I read something on planet.gnome.org (i think) where on person thanked ubuntu for something I think was arch. Is Ubuntu-people developing that?
<Amaranth> kent: bazaar-ng
<Amaranth> and the launchpad guys import cvs and svn trees into arch for some reason
<Amaranth> that's what the p.g.o guy was thanking ubuntu for
<Burgundavia> Amaranth, they do it so more people can work on the codd
<Burgundavia> s/codd/code
<Amaranth> ah
<Amaranth> good idea
<Amaranth> anyone else using breezy notice their menus don't update unless they kill gnome-panel now?
<Burgundavia> Amaranth, yes
<Amaranth> ok, as long as it's not just me
<Amaranth> wanna test another nasty problem? :)
<Burgundavia> sure
<eruin> daniels unborked xorg? :)
<Amaranth> create ~/.local/share/desktop-directories/.directory with the data [Desktop Entry] \nName=Foo\nType=Directory and restart gnome-panel
<Amaranth> eruin: We unbork it ourselves on every upgrade with symlinks and quick hacks
<eruin> ah... I'm holding off more extensive testing until after exams :P
<Amaranth> good idea
<eruin> helps to have xorg/openoffice when you have papers to write :)
<Amaranth> latex ;)
<eruin> haha
<Amaranth> um, should libwnck-common be more or less empty?
<Amaranth> it seems to only have README, copyright, AUTHORS, etc
<seb128> jordi, eruin: rb0.9 is not suitable to be packaged
<seb128> jordi, eruin: I've talked with teuf and he said that's not really worth packaging it atm
<seb128> and I don't think it'll be near of stable soon
<Amaranth> besides not being released and being buggy, is there any other reason ;)
<jordi> then comes seb and takes all the fun away.
<seb128> :)
<eruin> I remember debian once had a galeon-cvs package
<eruin> hint hint hint :P
<Amaranth> whatever gets used it should be possible to select a group of songs in nautilus, right click, and choose burn audio cd
<Amaranth> :)
<seb128> eruin: ubuntu has several packages
<seb128> eruin: but pissing upstream by packaging broken version so they are flooded by bugs is not a way to go
<seb128> s/packages/cvs packages/
<seb128> anyway not an option for now
<eruin> yeah... I suppose its a good idea to keep that repo in the list
<Amaranth> perhaps something in universe called rhythmbox-unstable? :)
<Amaranth> eruin: what repo?
<eruin> though the current system of bugreports on a devel list is probably worse than having bzilla spammed ;-)
<eruin> Archive: olemke core-dump info--2005
<eruin> Branch:  rhythmbox--merge--0.9
<eruin> http://arch.core-dump.info/archive
<Amaranth> hey, at least someone will respond to the email one way or the other
<Amaranth> bleh, you're talking about arch
<Amaranth> i thought you mean someone made a rb0.9 package :)
<Amaranth> meant
<eruin> I did that once
<eruin> that was an rpm though... I have to read up on debs ;>
<daniels> seb128: uhmm, yeah
<daniels> seb128: ${shlibs:Depends} should take care of that
<daniels> eruin: locally, yes, but not uploaded
<Nafallo> #8760 is open for libxine1c2. the patch for libmad0 breakage seems to have been lost in the merge from debian.
<Nafallo> shall I reopen the bug or is here anyone who sees this and upload the fix? :-)
<seb128> Nafallo: the bug has been reopened I think
<Nafallo> seb128: nope, I was asking if I should do it :-).
<seb128> Nafallo: read the bug
<Nafallo> seb128: turns up resolved/fixed for me
<seb128> read the comments!!
<seb128> "anybody still getting the issue with the fixed package? According to #10977
<seb128> that's still an issue"
<seb128> "sorry, it isn't the same bug (no need to reopen it). it is linked to bugs :
<seb128> #8343 & #8759"
<seb128> 
<seb128> if you have differents informations say so
<Nafallo> seb128: well. I've just upgraded to libxine1c2 and jamesh patch (1.0-1ubuntu6) seems to have been lost in the merge from debian. (1.0.1-1ubuntu1)
<Nafallo> seb128: I hope that's was more clear :-).
<seb128> yep
<seb128> I've just uploaded a new version
<seb128> better to be clear instead of asking if you need to open a bug or not :p
<seb128> thanks anyway
<Nafallo> seb128: hehe, I'll remember that. and thank YOU! :-)
<seb128> np
<siretart> is there somethings wrong with the wiki? I get a 'password wrong' when logging in and I'm trying to find out if the error is on my side
<mako> Simira: hey there
<tsume> brezzy well broken?
<tsume> meaning I shouldn't upgrade my current breezy?
<tsume> last time I upgraded was at the KDE breakage
<bob2> if you want to use breezy, expect it to be broken
<bob2> if it's not, it's a nice surprise
<tsume> its not broken at all, except the KDE mount daemon not working right, but at least it mounts it correctly automatically
<bob2> as above
<tsume> I just can't use konqueror to read/write the devices
<tsume> no other problems though.
<tsume> well, I think I'll upgrade to the latest
<tsume> I always work around to fix problems temporarily :)
<tsume> umm, maybe I'll upgrade later. I don't have time to download 300+MB
<tsume> *sigh*
<tsume> its a fedora spy! :)
<tsume> They've come to steal away the ubuntu developers. /me shoves mdz in the safe and throws away the key.
<bob2> drbyte: using ubuntu yet?
<Lathiat> tsume: hehe 
<Lathiat> drbyte: hey :)
<drbyte> bob2: nope :P
<drbyte> hi Lathiat 
<bob2> hah
<bob2> drbyte: only a matter of time!
<tsume> drbyte: I'm just playing btw. We all welcome every person to this channel.
<drbyte> bob2: its on one of the boxes... require it for 'work' 
<drbyte> tsume: i'm usually here btw ;-)
<drbyte> either as cc or me
<bob2> hehe
<tsume> drbyte: and you haven't changed your mask to .ubuntu yet? ;)
<drbyte> tsume: no, no.
<bob2> tsume: probably should loook into what he does with his free time
<tsume> bob2: hes probably a fedora developer or repackager :)
<bob2> hahahahahaha
<drbyte> tsume: former, yes. whats a repackager?
<tsume> drbyte: build software and package in rpm
<drbyte> tsume: oh, like a DD. well, we do that too...
<tsume> drbyte: well I meant repackager as in the people who sit there all day looking for new software releases ;)
<drbyte> oh well, time to pretend to get some rest... 3am. bleh
<drbyte> tsume: oh, definitely not me. that'd be scary.
<bob2> nightynight
* tsume imagines silly nerd sitting at the computer reading newsforge, slashdot, freshmeat, and usenet all day :P
<Lathiat> 3am? week :)
<tsume> gtg, byes
* tsume &
<Simira> mako: do you have any statistics for how many cd's that are distributed or ordered of Hoary and Warty to each country?
<doko> seb128: verbiste ping
<ivoks> hi
<herve> hi
<ivoks> here is like on a train station.. lots of people, nobody speeks, and lots of people going in and out :)
<robertj> :)
<Amaranth> why does kde use kde-applications.menu instead of applications.menu?
<Amaranth> this breaks many things
<hunger> daniels: Could you please change /etc/X11/xinit/xserverrc to point to the proper binary? Thanks.
<hunger> I did apt-get source. How do I get the downloaded stuff into the setup just before building?
<herve> what do you call setup?
<hunger> herve: I want to see the source used to build the binaries.
<hunger> herve: With all the ubuntu patches applied, etc.
<hunger> herve: I do not want to build it.
<herve> apt-get source should have setup it
<herve> and you usually find patches in debian/patches
<herve> or directly applied to the sources in worst cases
<herve> (set it up, setup is not a verb)
<hunger> herve: I do not see the sources... just a tar and patches.
<ivoks> hunger: cd <packagename>
<herve> some developers do that yes
<herve> so you know the upstream source really are not modified by the package maintainer
<hunger> herve: Is there a standard way to "prepare for build" or will I have to mess with debian/rules?
<herve> hunger: build tools handle this all
<herve> this is a part of the whole process
<herve> you'll find patching calls in debian/rules, by the way
<hunger> herve: I do not want to build, just see what the source the build is going to use.
<herve> hmm
<hunger> herve: Is there a standard way to extract and patch the sources without building them?
<herve> you should run something like "fakeroot ./debian/rules configure"
<herve> i.e., call by hand the step the build tools would have called at some point
<herve> hunger: you should check debian/rules to be sure of the target where sources are untared and patched
<hunger> herve: OK, so there is no "standard" way to do so. thanks.
<ivoks> heh
<herve> hunger, in a way yes, targets are standard
<hunger> herve: configure target seems to be the right one:-)
<ivoks> there are standards
<herve> but maintainer are quite free to organize their rules file
<ivoks> but, as in real life, you have DIN, ISO, ANSI, etc :)
<hunger> ivoks herve: I was thinking of some dpkg-something as standard, not calling debian/rules directly:-)
<ivoks> hunger: for what? building package?
<hunger> ivoks: Getting a package into the state just before actually building it.
<herve> ivoks: preparing the sources with patches, etc.
<ivoks> hunger: apt-get source package
<ivoks> ah...
<herve> but stop before the build process occurs
<ivoks> that depends of rules :)
<herve> ivoks: my point :-)
<herve> but the configure target is 99% times what it means
<ivoks> yeah
<ivoks> patching isn't that often...
<hunger> ivoks: Im a idiot wrt. packaging... (and most other things as well for that matter).
<ivoks> :) ?
<ivoks> writting :)
<ivoks> ah, hunger i'm not too much better either :)
<herve> ivoks, you didn't know how to make a package like, what, one month ago?
<herve> :-p
<ivoks> herve: three weeks ago :)
<ivoks> since then... :))
<hunger> Not having X makes me feel nostalgic:-)
<ivoks> ah.. time to leave you guys
<hunger> ivoks: Bye!
<ivoks> bye all
<herve> bye
* hunger sighs.
<hunger> The new keysyms in X have values > 0xffff and are stored as unsigned shorts:-(
<hunger> No wonder some keys are broken... but those are farsi and other really strange characters, not the F-keys, etc. that no longer work for me.
<hunger> daniels: The XKeysymDB is in /usr/X11R6/lib/X11 while the sources say it is in /usr/lib/X11.
<Kamion> elmo: mv --reply=no
<Kamion> elmo: we decided that libqt-perl, libsmokeqt1, libsmokeqt-dev were OK for main, didn't we? it sounded like other parts of kdebindings were more troublesome than SMOKE
<Kamion> I'm just preparing a debconf upload so I'd like to have those promoted in order for this one to actually build
<Simira> how come most of the mails I've sent lately don't seem to be in my "Sent items"-folder?
<Simira> help?
<mkde> the email gnomes
<mkde> stealing email to make profit
<mxpxpod> when using make-kpkg on a vanilla kernel, do I have to do anything to make it with an initrd image?
#ubuntu-devel 2005-06-05
<Kamion> use the --initrd option
<Kamion> (when running the kernel-image target)
<mxpxpod> Kamion: what's the warning about?
* mdke waves at Amaranth 
<Amaranth> heh, not here
<seb128> doko: pong
<Amaranth> i think a #twisted developer has a similar nick
<mkde> Amaranth, then he'll have to die
<hajiki> could anyone help me verify if this is a bug or just an issue on my system?
<mkde> hajiki, sure, go to #ubuntu
<hajiki> ok
<seb128> what a description
<seb128> "this is a bug"
<mkde> he hasn't popped up in #ubuntu yet
<mkde> aha
<Gandalfar> Anyone knows how to pivot image with nvidia driver?
<doko> seb128: hi
<seb128> hey
<seb128> why are all these stuff still frozen?
<mkde> a support question which we can't figure out in #ubuntu to do with a security mirror. A guy is getting a GPG error from the security mirror. any ideas?
<doko> it's universe
<seb128> and?
<seb128> libapt-pkg-perl would unbreak apt-file by example
<doko> you don't know, if it depends on a library, which is not yet converted. if you know it, elmo and lamont can remove it from the list of frozen apps
<seb128> k
<seb128> ie: libapt-pkg-perl is all right, no?
<doko> yes, AFAIK elmo did open the gates for syncs again, so we have to ask lamont for an updated list on the buildds.
<seb128> k
<doko> don't do that too often, or lamont will ... maybe annoyed. maybe put a list of apps together, which can safely be built?
<seb128> k, I'll do this
<seb128> thanks
<doko> send a diff for chinstrap:~doko/cxxapps.txt
<doko> btw, ubuntu-desktop on breezy is at least installable again, all C++ apps are built using 4.0
<doko> Kamion: ^^^
<seb128> nice
<mkde> awesome
<Kamion> doko: woo, thanks
<doko> maybe wait for one more xorg upload and then try a CD build ...
<Kamion> I want debconf to build first; it has some important bug fixes
<doko> it needs universe -> main love
<Kamion> and debconf progress bar support is in the "early breakage" category :)
<Kamion> I know, see an hour and a half back
<doko> btw, are you able to do the main -> universe dance as well?
<Kamion> doko: technically, yes, but as with universe->main I'd rather do it only when I have to
<doko> ok, I don't like python-qt3 and openoffice.org2 in an unbuildable state
<Kamion> python-qt3 has too big a knock-on effect
<Kamion> and as I said I'd rather we kept openoffice.org2 in main so that it keeps bugging us
<doko> not only openoffice.org2 will keep bugging you, but me as well ;-)
<Kamion> yes, and so it should :-)
<Kamion> it's a breezy release goal
<mdz> Kamion, doko: what about x-window-system-core?  last I checked it was still behind
<mdz> ah, it's been fixed since
<mdz> or else whatever it was conflicting with has been
<mdz> at any rate, good work
<trulux> tseng: go ahead and ask mdz or anyone about that "12 pages shit" and the like
<tseng> trulux: eh dont bring that in here your latest adventure has nothing to do with ubuntu.
<tseng> we have a code of conduct here that says I should be civil to you and all that.
<trulux> tseng: hah, you're the first in violating it's rules
<daniels> hunger: fixed that locally
<trulux> tseng: go ahead, really. don't say it's not ubuntu related
<trulux> tseng: tell me publicly, what's your problem?
<trulux> you don't like how I work, maybe it's that what makes you feeling and acting that way
<Burgundavia> tseng, trulux please try and stay civil
<trulux> Burgundavia: it has nothing to do with being polite but saying the truth
* Burgundavia doesn't know why he is policing -devel, he thought that job only was required on #ubuntu
<Burgundavia> trulux, you can tell the truth, but you can say it in a way that doesn't hurt other people
<trulux> Burgundavia: sure, isn't it ironic?
<Burgundavia> I don't even know what the problem is, as xchat just crashed on me
<trulux> <tseng> pappy-: he's a funny kid
<trulux> <tseng> yep
<trulux> <tseng> or just work like everyone else
<trulux> <tseng> MadMethod: he just cant shut the fuck up and do something
<trulux> <tseng> he has to CC half the planet every time he takes a shit
<trulux> <tseng> and then write it up in a 12 page pdf
<trulux> <tseng> maybe spanish docs
<trulux> <tseng> hah
<trulux> I can imagine what's that following up
<trulux> though I have pappy- in my ignore list
<trulux> maybe 'cos you and others suspended him, funny
<tseng> for the record that has little to do with ubuntu, and is related by a dangling pointer
<trulux> isn't it ironic? how jerks can come up together to fsck those who make the feeling less than they think?
<trulux> tseng: biased? I don't think so
<\sh> pappy-?
<trulux> really, say everything or just shut up but don't come up with your biased-I-don't-like-that-kid shit
<\sh> he was gentoo dev right? before he left the project
<tseng> you are probably proving my point here, but can you please not bring a flame into this channel?
<trulux> \sh: that german jerk who spends time insulting and disturbing around while his kids grow up without the cheering of a father, yes
<trulux> that one
<Kamion> guys, if it wasn't in an Ubuntu context to start with, please don't bring it in here
<trulux> Kamion: it's quite related to it
<\sh> trulux: i know him so i shut my mouth :)
<trulux> \sh: thanks, I'm just trying to get things on board and shut the mouth of this jerk off
<Kamion> count to ten and have a coffee; no point escalating things
<trulux> \sh: I don't want to disturb anyone else from here, I've found many good people around to make such a weird thing
<Kamion> hm, maybe not a coffee. :-)
<trulux> Kamion: definitely not
<trulux> ;)
<\sh> check planet...this i did today :)
<\sh> brain reset :)
<trulux> tseng: so, can you please tell me what's wrong? that I'm 15 and you don't like it?
<trulux> \sh: haha, done
<\sh> and now I'm feeling fine...spend some money, bought new hardware
<mdke> while we're on the subject of planet, has anyone tried putting an "s" after the http in its address? is that meant to happen?
<trulux> \sh: I'm feeling violent now, both in verbal and physical terms. like taking someone's nose bleeding
<trulux> \sh: I'm just cold enough to not put things on the right place right now
<daniels> trulux: so walk away from your computer until you don't feel violent.
<trulux> \sh: it's better to do that once you get cool and chill
<trulux> daniels: no way
<\sh> trulux: i will tell you something now about pappy: don
<daniels> trulux: this had nothing to do with ubuntu, and the stuff with pappy- especially doesn't have anything to do with ubuntu.  take it somewhere else.
<\sh> 't take him serious..he has problems, he had problems with other devs from gentoo..and he to step back and he left.
<daniels> why are we arguing about gentoo developers in #ubuntu-devel?
<\sh> so for me, he's no one to worry about.
<trulux> daniels: to #gentoo-hardened-dev? my mentor is away, and some jerks keep around far away of the point
<tseng> #gentoo-hardened-dev is +s
<Kamion> if you're feeling violent, please do not bring that here. thank you.
<trulux> \sh: I've more information about pappy- and he needs real counseling, I'm just decent enough to not make it now flowing around
<daniels> look, put it this way.  the entire discussion (trulux vs tseng, pappy-) is massively off-topic.  it's also over.  the next person to try to carry it on gets a +q, ok?
<ajmitch> trulux: more bluntly - be quiet, you're making a fool of yourself 
<tseng> daniels: rock on.
<trulux> \sh: what I said: he is doing some weird stuff instead of keeping closer to his kids and wife. no need to get me more explicit nor wicked to cause damage on top of that, it's *their* choice.
<trulux> ajmitch: hah, no need. my reputation is far away of being affected by these jerks
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [+q *!*lorenzo@trulux.user]  by daniels
<\sh> trulux: i know whats behind this all of pappy...and I don't take him serious..if he needs counseling or not it's not my business. he's not recognized by many of serious devs, even if he is one of the most incredible coders out there
* mode/#ubuntu-devel [+q *!*shermann@server3.servereyes.de]  by daniels
<mdke> geez
<mdke> so did anyone check out https://planet.ubuntu.com?
<tseng> mdke: hm :P
<mdke> is that supposed to happen?
<tseng> its probably a default ssl vhost
<tseng> you can only have one ssl vhost active per ip address
<tseng> others get routed to it as you see here.
<mdke> ok
<Burgundavia> is there a reason that p.u.c doesn't syndicate kinnisons blog, but p.d.o. does?
<tseng> Burgundavia: i think p.d.o just was recently fixed
<Burgundavia> ah, and U hasn't been?
<tseng> possibly not
<mxpxpod> thom: ping
<camilotelles> Kamion: is there?
<jiyuu0> apt-get install samba will prompt during installation
<jiyuu0> anyway to bypass the prompt
<jiyuu0> something like settings the default answer?
<daniels> -y
<jiyuu0> i don't mean the -y thingi
<jiyuu0> e.g. samba, linpopup, nessus
<jiyuu0> will prompt once they install
<jiyuu0> i'm planning to write an unattended script
<jiyuu0> but these 3 will get stuck
<jiyuu0> cause they prompt for inputs :(
<infinity> jiyuu0 : Erm, doesn't samba use debconf to prompt?
<infinity> jiyuu0 : (That's a rhetorical question, I know it uses debconf)
<jiyuu0> anyway not asking them to prompt on apt-get install samba
<infinity> So, DEBIAN_FRONTEND=noninteractive apt-get install samba
<infinity> If you never want packages to prompt, do "dpkg-reconfigure debconf", and select "critical" priority" and "noninteractive" frontend.
<infinity> (You may want to make sure you check root's mail spool for notes about questions you miss, in that case)
<infinity> And if you don't want stuff to prompt, but you want set answers, read about debconf preseeding.
<infinity> And all of this belongs in a different channel (#ubuntu), but I didn't check before I started typing.
<jiyuu0> ok... i'll check out what u advice
<jiyuu0> thanks :)
* mode/#ubuntu-devel [-b *!*lorenzo@trulux.user]  by daniels
* mode/#ubuntu-devel [-o daniels]  by daniels
<trulux> daniels: thanks
<trulux> sorry about the flame that came out here
<trulux> hopefully things will get clarified themselves soon
* trulux goes to sleep
<fabbione> morning
<sladen> nn
<jiyuu0> Fresh from oven...
<jiyuu0> New Release: UbuntuGuide Add-On-CD (27th May 2005)
<jiyuu0> http://ubuntuguide.org/add-on-cd
<jiyuu0> Changes:
<jiyuu0> http://www.ubuntuforums.org/showpost.php?p=191197&postcount=46
<bob2> you dropped the JRE?
<bob2> but kept w32codecs?
<jiyuu0> sun-j2re
<bob2> oh, it's sun jre now
<jiyuu0> it uses backports 
<bob2> I'm pretty sure you're breaking the law by distributing either of those things
<jiyuu0> so there .deb for it
<jiyuu0> yikes...
<bob2> afaik no one can distribute w32codecs
<jiyuu0> mepis?
<bob2> er, no
<bob2> unless they actually wrote all those microsoft and real DLLs themselves
<jiyuu0> mepis includes em
<bob2> if mepis jumped off a cliff...
<jiyuu0> or should i just remove the whole thing
<bob2> surely you looked at the license of stuff before distributing them from your website?
<whiprush> bob2!
<bob2> whiprush: I WANT FRIDGE.
<daniels> bob2: that's not even a name!
<whiprush> bob2: soon
<daniels> jiyuu0: it really is illegal, btw
<jiyuu0> so should i discontinue it
<bob2> you should read the license for each thing and see if you're allowed to distribute each bit at all
<bob2> there is a reason this stuff isn't in ubuntu itself
<jiyuu0> there is a country limitation for this
<bob2> some of it is fine, e.g. nvu/clamav
<jiyuu0> i heard some country don't really have such law right?
<daniels> um, every country has copyright law
<bob2> this is just normal copyright law
<daniels> this isn't patents
<bob2> you don't have permission from MS to distribute their DLLs, therefore you can't
<daniels> this is the licence saying 'YOU MAY NOT DO THIS', where 'this' is exactly what you're doing
<bob2> just like you can't distribute MS Word on cd-rs
<daniels> including redistributing the DLLs, using it in other applications, etc
<jiyuu0> gosh...
<jiyuu0> how bout the instructions?
<fabbione> daniels:
<fabbione>  checking dynamic linker characteristics... /build/sparcbuildd/dbus-0.33/./configure: line 17745: gcj: command not found
<fabbione> daniels: perhaps you need to build-dep on gcj :P
<quitte> what is the default compiler you are using?
<bob2> gcc 4.0 is the default in breezy
<daniels> fabbione: we don't build java bindings
<daniels> fabbione: that didn't cause an ftbfs, no?
<fabbione> daniels: nope.. it's only a warning
<quitte> bob2 wow. did you use gcc-3.4 before maybe?
<bob2> 3.3 was the default before
<daniels> jiyuu0: fabbione cool
<daniels> er
<daniels> fabbione: cool
<fabbione> yeah ehehe
<quitte> :( 
<daniels> jiyuu0: whether or not you can provide instructions is uncertain
<quitte> i guess i
<daniels> jiyuu0: but distributing it is definitely very illegal
<quitte> 'd better move forward to 4.0 then.
<jiyuu0> if i stop it right now... how bout those that ppl already downloaded it or the mirros?
<bob2> jiyuu0: you should tell the mirrors they shouldn't be distributing it either
<jiyuu0> oh
<bob2> and you probably should put a note on the ubuntuguide website saying people shouldn't be distributing it to other people, either
<jiyuu0> ok
<jiyuu0> i'll do it
<jiyuu0> it's really sad
<bob2> yes
<bob2> proprietary formats suck
<jiyuu0> but so far is there any of this cases?
<bob2> this is straight copyright infringement
<jiyuu0> that someone being charged for distributing em
<bob2> this is equivalent to giving your friends copies of windows or whatever
<daniels> jiyuu0: this is not a legal 'grey area'
<daniels> this is something that you really, really, cannot do
<jiyuu0> ok
<jiyuu0> removing...
<jiyuu0> ok... too down the page already
<jiyuu0> this really sux
<jiyuu0> sux so bad
<bob2> don't forget to update the "add-on cd" section to include what happened to it and why
<jiyuu0> temporary chmod 000 it
<jiyuu0> will update it shortly
<jiyuu0> bob2,  is this 2 lines ok?
<jiyuu0> Due to copyright issues, UbuntuGuide Add-On-CD is discontinued immediately.
<jiyuu0> I would sincerely like to make an apology to those copyright holders...
<bob2> heh, ok
<jiyuu0> yub... done
<daniels> so, you may not think this
<daniels> but when every binary in xbase-clients is actually a directory (i.e. /usr/bin/setxkbmap and EVERYTHING ELSE are directories), X gets really unhapy
<daniels> bonus points for having a broken XKB map, so you have to SSH in and run chvt
<bob2> yay breezy
<Amaranth> jiyuu0: Don't apologise, you'll just draw attention to yourself.
<jiyuu0> oh.. ok
<fabbione> daniels: can you try to build gle in a fresh breezy buildd chroot?
<fabbione> or sbuild it
<fabbione> i get that with xorg -20 i can't satisfy b-d
<daniels> gle?
<fabbione> yeah it's a package called gle
<daniels> checking now
<jiyuu0> Amaranth, corrected
<Amaranth> jiyuu0: Oh, I meant don't go telling everyone you were distributing this illegal thing and now you've stopped. :)
<jiyuu0> so meaning?
<jiyuu0> took the whole page down?
<Amaranth> Just say you're not making it anymore or something.
<fabbione> daniels: it looks like a b-d messup in Conflicts | Whatever
<daniels> fabbione: freeglut3 needs a recompile
<daniels> Depends: libc6 (>= 2.3.4-1), libx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0), xlibmesa-gl | libgl1, xlibmesa-glu | libglu1, libglut3 (>= 3.7-25)
<jiyuu0> Amaranth, so i sentence will do
<jiyuu0> UbuntuGuide Add-On-CD is discontinued immediately
<jiyuu0> UbuntuGuide Add-On-CD is discontinued
<Amaranth> that'd work
<daniels> bob2: and this is the stuff that I *don't* upload
<bob2> hahahaha
<fabbione> humpf..
<fabbione> we should probably get elmo/infinity/lamont to do a mass rebuild for breezy and see what's the status
<jiyuu0> bob2, mrbass said he's willing to take the risk of hosting the files
<jiyuu0> but if the CD is build by me
<jiyuu0> do i get myself in trouble?
<daniels> yes
<jiyuu0> ok... guess i'm done wif it
<jiyuu0> bye bye Add-On
<Amaranth> that reminds me, who do i poke to get gxine rebuilt? :)
<jdub> daniels: um
<jdub> daniels: dude
<daniels> jdub: represent
<jdub> daniels: so i just plugged my laptop into a projector
<jdub> daniels: and the output was... it was like the entire room was on lsd
<daniels> awesome
<daniels> did you bust out some glowsticks?
<bob2> DRUG PARAPHENALIA
<daniels> jdub: were you using i855crt, or what was happening?
<daniels> maybe it was just running too high a res+refresh for the projector
<ogra> daniels, he already did represent .... claimed the stage ;)
<jdub> yeah, i855crt at 75Hz
<jdub> maybe i should try without the overlay stuff
<daniels> jdub: try at 60
<jdub> ok
* jdub does X testing on the main lectern at guadec
<jdub> no dice
<jdub> same ugliness
<daniels> jdub: try my xorg.conf
<jdub> it looks like a palette issue
<daniels> jdub: try http://amnesiac.heapspace.net/~daniels/misc/xorg.conf
<fabbione> daniels: how much hack do i need to do to upgrade X today? :)
<daniels> fabbione: just symlink your XKeySymDB and it should be OK
<fabbione> daniels: from where to where?
<bob2> drbyte: converted yet?
<jdub> hrm
<daniels> fabbione: /usr/lib/X11 needs to point to /usr/X11R6/lib/X11
<jdub> session not even starting there
<jdub> ok, will deal with this later
<fabbione> daniels: ok
<drbyte> bob2: not today, no !
<daniels> fabbione: both /XKeySymDB
<daniels> not just sudo ln -s /usr/{X11R6/,}lib/X11
<jdub> daniels: what's the XKeySymDB bit?
<daniels> jdub: that's if you want your keyboard shortcuts to actually *work*
<jdub> daniels: so i've symlinked /usr/lib/X11, what do i do for the xkeysym bit?
<daniels> jdub: err ... that's it
<jdub> ok
<daniels> jdub: you were meant to do sudo ln -s /usr/{X11R6/,}lib/X11/XKeySymDB
<daniels> or maybe XKeysymDB
<daniels> whatever it is on-isk
<daniels> on-disk
<Amaranth> i did all that when you told me, didn't fix my shortcuts :/
<Amaranth> /usr/lib/X11/xkb -> /etc/X11/xkb
<Amaranth> sudo ln -s /usr/X11R6/lib/X11/XKeysymDB /usr/lib/X11/XKeysymDB ?
<ogra> Eclipse is a program whic didn't need install and has his own
<ogra> update-manager.
<ogra> wow, you see me impressed....
<ogra> software that doesnt need install....
<ogra> just flies into your system by esotric rays.....
<daniels> Amaranth: yeah
<bob2> goddamn
<bob2> hoary makes a really creepy noise on login
* Amaranth saves his glade file and logs out
<daniels> bob2: you should supplant it with some samples from dmc champions vol 2
<daniels> bob2: available at a 24h jb near you!
<bob2> daniels: ah ah ah !
<daniels> hahsa
<Amaranth> damn, no luck
<Amaranth> any thing else i can try? :)
<daniels> um
<daniels> are you running amd64?
<Amaranth> no
<Amaranth> x86
<daniels> because I was having the same problem, and just fixed it locally
<daniels> ok, can't give you a new deb to test then
<daniels> so when you run xev and hit ctrl-a, f.e., it gives you (no symbol)?
<Amaranth> i don't have xev, what package is that in?
<Amaranth> i wonder if that's the problem?
<Amaranth> oh, it's just not in my path
<Amaranth> http://rafb.net/paste/results/9kLcIg63.html <--me hitting Ctrl-C
<daniels> so, if it helps, try sudo for i in /usr/X11R6/bin/*; do ln -s $i /usr/bin/$(basename $i); done
<Amaranth> bash: syntax error near unexpected token `do'
* Amaranth doesn't know bash scripting
<daniels> sudo sh -c 'for i in /usr/X11R6/bin/*; do ln -s $i /usr/bin/$(basename $i); done', in that case
<daniels> forgot about the semi-colon
<Amaranth> ok
<Amaranth> got some warnings about symlinks i'd already made, otherwise it's all good
<Amaranth> restart X?
<Amaranth> does that paste tell you anything?
<Amaranth> i give up :/
<fabb1one> daniels: ?
<bob2> jdub: "Jeff seemed pretty excited about this; I got the feeling Ubuntu would be switching to Thunar pretty shortly!"
<fabb1one> bob2: what was the solution for X not finding fixed fonts?
<bob2> fabbione: point X.org at /usr/share/X11/fonts for fonts, iirc
<bob2> since fonts went from lib -> share
<fabbione> meh
<fabbione> not all of them tho
<fabbione> ok
<bob2> well, adding it as a FontPath, I mean
<fabbione> that should be handled automagically :/
<fabbione> thanks :)
<bob2> np :)
<daniels> fabbione: there'll be a symlink later
<fabbione> daniels: so /usr/lib/X11 symlink to /usr/X11R6/lib/X11 + the font path...
<fabbione> do i miss anything?
<bob2> daniels: firegl on rdaeon 9250 is stupid, right?
<fabbione> apparently it works...
<fabbione> daniels: i didn't add the font paths.. just sed the ones already there
<fabbione> daniels: btw to compile nvidia just export CC=gcc-3.4 before invoking the installer.. that will make it work with 2.6.12
<Mithrandir> hm, does arch bloat the size of binaries checked into it noticeably?
<bob2> it stores two copies everytime you commit a change
<Mithrandir> I doubt I'll ever change those data.
<fabbione> daniels: something else is utterly wrong :)
<Mithrandir> (I'm looking for a sane RCS to handle my photo collection)
<bob2> then you'll just get one copy + tiny amount of metadata
<Mithrandir> ok, that's good.
<Mithrandir> apparently, svn bloats it by 50% or so
<fabbione> daniels: /usr/bin/X11 :)
<bob2> but ammortizes that by using an xdelta-style diff for future changes
<Mithrandir> bob2: I tend not to change my photos much
<bob2> heh, yeah
<Mithrandir> I hate file systems.  Or hardware.  Or both.
<mdke> jdub, ping?
<daniels> bob2: yes
<daniels> fabbione: yeah, /usr/bin/X11 is coming
<fabbione> daniels: ok....
<mdke> jdub, here yet?
<Riddell> that was seb and ogra on the guadec stream
<camilotelles> Kamion: ping.
<Kamion> camilotelles: hi
<camilotelles> hi Kamion, can you talk now?
<Kamion> sure
<camilotelles> did you saw my chat with mdz? kiko already talked with us about the coding style and approch problems of the installer script.
<Kamion> I didn't see your chat with mdz, no
<camilotelles> kiko talked with me about the problems in the script. the approach used and the lack of style.
<camilotelles> I agree with this diagnostic.
<Kamion> well, this is why we put together a specification in advance
<camilotelles> I know. 
<camilotelles> I think that we need to understand better the d-i.
<Kamion> we were thinking that it might make more sense for somebody who knows the installer well to put together a top-level framework that you guys can work within
<Kamion> we had hoped that it might be possible for you to do the framework as well, but in retrospect perhaps it was a bit ambitious to expect people to do that with no prior knowledge
<camilotelles> I agree with it. But I want to take a conservative approach to not jeopardize the project.
<camilotelles> If there is someone who can put the framework I think that we can handle some bits of the code. But I think that we can help better in the test team.
<Kamion> well, I don't want to totally reject your coding help; it's a matter of guidance more than anything else
<camilotelles> thats great.
<Kamion> unfortunately you did catch me in a particularly busy week, and the timezone thing made it too difficult to work with you in helping to get a framework together, which was a shame
<camilotelles> but you guys have time for it?
<Kamion> not really, but we'll have to create time somehow ;-)
<Kamion> gotta be done ...
<camilotelles> thats ok. but I think that we have to take care with the risk.
<camilotelles> when you put the framework we have to make some milestones clear.
<camilotelles> But we have others interest too. as a tester and user. and maybe contributing with some code.
<Kamion> yes, some degree of project management will be necessary as for all our other large goals
<camilotelles> thats ok. what do you think will be the next steps?
<Kamion> camilotelles: I haven't really had a chance to think about it yet - I imagine somebody will have to sit down for a while and write a script that runs the top-level procedures defined in the UbuntuExpress spec, with TODO comments left where components don't exist yet
<Kamion> we can use debconf for all the interaction, and then when ogra's GUI appears it'll just preset the relevant debconf answers and the UE backend code won't have to change at all
<Kamion> (I hope)
<camilotelles> kamion: ok. Iin the meantime we will focus to port our scripts from Knoppix to Ubuntu. We have automated the customization process of the knoppix and put everythink inside one svn repository. So we can do build in one step and we can reproduce any custom version that we have already made.
<Kamion> ok
<camilotelles> I think that a lot of our work is similar with the work that you are doing in BrandingForDerivatives. We are interested in this.
<Kamion> really?
<camilotelles> sure. in an ugly way, but sure it is.
<camilotelles> (remenber or last script)
<camilotelles> s/remenber/remember
<Kamion> hm, ok. I guess we're trying to do it at a lower level; much of our goal is to arrange for derivatives to have to do only a trivial amount of work to brand
<camilotelles> exactly. I think when your work is done, we can reduce or script and put it more cleaner.
<camilotelles> we can help to test this part too.
<camilotelles> kamion: and because we are doing our job for a computer manufacturer, we are interested in the OEMInstaller.
<Kamion> that one I've only *just* started
<Kamion> not much to show yet
<camilotelles> ok. when you need to test, you can call us. 
<Kamion> ok, thanks
<camilotelles> and finally, we have a lot of hardware here. sometimes new stuff. only MSI and Intel stuff. Ex: last week we are with an engineering intel board here.
<camilotelles> kamion: is it. we will be waiting for the installer stuff. when you think that we can help, call us. We will be always in the# ubuntu-devel and surak will be in a better time to meet you in the channel.
<ogra> grrr
<ogra> guadec locks port 25 on the router....
<ogra> everything else is open, but you cant send mails by smtp
<Nafallo> ogra: ssmtp? :-)
<ogra> Nafallo, yes, if i had the time to reconfigure my server
<seb128> who needs to send mails anyway
<trulux> chris38-home: here?
<trulux> chris38-home: how are you doing man!?
<zul> hey
<trulux> heya zul 
<zul> hey Treenaks 
<zul> damn it..trulux :)
<trulux> mpt: ping
<Robot101> anyone know of any samba4 snapshot debs?
<Lathiat> Robot101: no but i was considering making some
<{Seb}> hey all
<{Seb}> just upgrading to breezy
<{Seb}> it looks pretty sweet
<cartman> bad time to upgrade
<{Seb}> why?
<cartman> X is broken
<{Seb}> since when?
<cartman> since long time
<{Seb}> when is it going to be fixed
<cartman> with next X.org upload I hope
<cartman> no ETA on that though 
<cartman> so don't upgrade now
<cartman> or don't upgrade xorg bits
<{Seb}> i'm just on breey to check out mono and beagle
<{Seb}> i'm a beagle hacker
<{Seb}> normally using suse 9.3
<{Seb}> the only broken package i could find was tomboy 0.3.2
<{Seb}> when is gcc 4 coming in?
<Nafallo> {Seb}: ehm... read topic ;-)
<cartman> its in
<{Seb}> how is xorg broken?
<{Seb}> if i install it, will my system not boot up?
<cartman> it won't start X
<{Seb}> i'll just do a 'Force Version' then
<{Seb}> or Lock Version even!
<{Seb}> will that work
<cartman> just don't upgrade xserver-xorg
<{Seb}> why does everything depend upon openoffice2?
<{Seb}> i didn't want to install it
<{Seb}> as it is out of date but if i don't install it
<{Seb}> then everything else won't install :-(
<{Seb}> btw, when is the release of breezy going to be made?
<Nafallo> {Seb}: 5.10
<Nafallo> {Seb}: i.e. October 2005
<{Seb}> now that makes sense
<{Seb}> is it true that ubuntu might be moving to  Thunar as a file manager
<{Seb}> when Xorg is fixed and Tomboy is fixed, is there a way of finding out?
<{Seb}> mailing list?
<{Seb}> or just this IRC channel
<mdke> in breezy things don't stay fixed all the time
<mdke> best plan is to assume they will break
<{Seb}> in what sort of time table will things start to even out
<mdke> by october it will be stable
<{Seb}> not before that?
<{Seb}> hoary was stable in about February IIRC
<mdke> well it kind of depends on what you want to do with your system
<{Seb}> mono development
<{Seb}> beagle hacking
<{Seb}> hula hacking
<{Seb}> and a bit of tomboy possibly
<mdke> as in ubuntu packaging?
<Lathiat> the moral of the story is not to run breezy if you want to get any work done :)
<Lathiat> run it in a chroot or something
<{Seb}> sounds a good idea
<{Seb}> mdke: as in finding problems with the code, not packaging
<mdke> k
<mdke> well i don't know, but sounds like a stable system would be the way forward
<{Seb}> mdke: i don't understand of all the packaging system with ubuntu
<{Seb}> yeh but there is the mono problem
<{Seb}> mono in breezy is looking good
<{Seb}> mono in backports is sh*t
<{Seb}> mono is hoary is tooo odl
<{Seb}> or I could just use SUSE 9.3!
<Lathiat> s/mono in//g
<{Seb}> what?
<Lathiat> "backports is sh*t"
<Lathiat> no need for the mono qualifier :)
<{Seb}> lol
<mdke> won't you want the latest version if you are working on the code? maybe you can install it from cvs or whatever they use
<{Seb}> that's what i'll be doing
<{Seb}> tomboy and beagle from cvs
<{Seb}> but mono from packages me hopes
<mdke> maybe qemu?
<{Seb}> what is qeum?
<{Seb}> the name rings a bell
<{Seb}> as long as the basic things work
<{Seb}> like GNOME and Evolution, I'm fine
<mdke> its an emulator
<mdke> i haven't tried it tho
<mdke> there is an old guide on the wiki
<{Seb}> like xen?
<cartman> qemu is slow
<mdke> yeah you'll need a good comp
<cartman> Xen is fast but needs a custom kernel
<cartman> mdke: I have an Athlon64 3500+ 1gb  RAM
<cartman> its truly slow
<cartman> Xen shines though
<{Seb}> will Xen be intergral in Breezy
<{Seb}> like in SUSE?
<cartman> Xen better integrate itself with kernel first
<cartman> Getting into -mm would be a good start
<Nafallo> {Seb}: http://udu.wiki.ubuntu.com/Xen
<{Seb}> mmmm
<mdke> cartman, wow thats a nice computer
<{Seb}> what is BOF
<cartman> mdke: well qemu is slooow :)
<mdke> {Seb}, it means brainstorming session
<mdke> cartman, ok
<{Seb}> everyone in the ubuntu community is so helpful
<{Seb}> even stupid questions like BOF and packaging means i don't get flammed
* {Seb} wonders where these people were before Debian
<{Seb}> sorry
* {Seb} wonders where these people were before Ubuntu
<mdke> {Seb}, debian is the answer
<mdke> mainly
<kent> mdke, but its kind of strange. Isn't Debian famous for a very unfriendly (for beginners) irc-channel etc? And #ubuntu is more or less the opposite.
<mdke> kent, yes thats true
<mdke> not just for beginners either
<mdke> last time I went in there to ask a genuine debian related question, someone did a whois on me, saw I was on lots of ubuntu channels, and started swearing at me :p
<zenrox> fegueries
<zenrox> ubuntu bastared son of debian
<zenrox> heheheh
<kent> mdke, I got the fealing that some Debian-people are upset becaus lots of Ubuntu-newbies send bugreports/questions to them, rather than to Ubuntu. But that might have changed?
<mdke> kent, yeah that's right, but still, just being in ubuntu channels doesn't mean i can't run debian on one of my systems
<kent> mdke, No, and people should behave better aswell. :)
* mdke shrugs
<zenrox> who know
<zenrox> s
<mdke> now I can just ask in #ubuntu for debian related advice ;)
<{Seb}> i run debian on my server
<{Seb}> when i went into #debian and asked a question relating to Qmail
<mdke> yeah
<{Seb}> and then mentioned Ubuntu, it was like my hair was on fire
<mdke> *laughs*
<mdke> nice imagery
<{Seb}> why can't they accept that some like don't want to use exim
<mdke> hi thesaltydog 
<azeem> {Seb}: "they" is obviously not "Debian"
<{Seb}> they is some of the debian community
<mdke> just applies to the irc channel
<{Seb}> i'm suprised that Progency isn't more popular
<{Seb}> probally because ubuntu has stolen that spot!
<anna> Hello everybody, I have two questions: First, how do I debootstrap breezy from hoary, is that possible directly anyway?
<anna> Second: When is the next xorg update in Breezy ready? :-)
<pitti> anna: this is #ubuntu matter, however
<pitti> anna: 1) sudo apt-get dist-upgrade
<pitti> 2) just wait a bit more, breezy is currently *very* broken
<pitti> anna: for 1), you can also use synaptic, of course :-)
<anna> pitti: I want to make a chroot with breezy and not break my hoary
<pitti> anna: ah :-)
<pitti> anna: well, debootstrap is nice for that
<anna> Except that I can only debootstrap Debian with Hoary?!
<pitti> who told you that?
<anna> debootstrap :p
<tseng> you need the breezy scripts to debootstrap breezy
* pitti created warty and hoary dchroots with debootstrap
<tseng> that might be worth a hoary-update, debootstrap from breezy pulls back glibc
<pitti> anna: yes, of course, you need breezy's debootstrap, but that is able to install Debian slink to sarge and Ubuntu warty to breezy
<anna> hm.... so I am now making a hoary chroot
<pitti> anna: just compile the breezy debootstrap for hoary
<anna> Then dist-upgrade it there
<azeem> anna: you can just extract the breezy script from the .deb
<azeem> no need to install it
<tseng> pitti: easier to make a hoary and dist-upgrade
<tseng> yep :P
<anna> ah... ok, that will be easier
<tseng> or thats what I do now anyway
<azeem> of course, that might not work in practise due to brokeness etc.
<tseng> timtowtdi
<anna> Well, I actually want to unbreak my machine's X
<cartman> tseng: perl monger? :)
<tseng> cartman: no, i am forced to write tcl
<anna> So I wanted to prepare a package without the diff that kills all the keys
<tseng> cartman: and php
<cartman> oh :/
<thesaltydog> mdke, matt??
<mdke> thesaltydog, yes
<thesaltydog> nice to meet you here
<cartman> timtowtdi is kinda a perl signature, isn't it? :)
<mdke> thesaltydog, we met the other day ;) but hi
<anna> btw, except for X breakage, Breezy is not THAT bad so far...
<cartman> anyway time to sleep
<{Seb}> i agree
<{Seb}> i've just done a 'Forced Version' of xorg packages and it seems to be fine
<mdke> is there an official list of initscripts used in Ubuntu?
<anna> {Seb}: What do you mean, a versioned downgrade?
<{Seb}> i installed hoary
<{Seb}> but when i changed the repos to breezy
<{Seb}> i pressed 'Force Version' in Synaptic
<{Seb}> so xorg isn't touched
<anna> Ah... I see.
<pitti> trulux: here?
<pitti> ajmitch: ping
<{Seb}> btw
<{Seb}> is it kernel 2.6.12-1 that has the latest inotify enabled as default?
<JStrike> Yes
<{Seb}> it's coming down now
<JStrike> Does ubuntu-devel have anything similar to Burrito?
<Amaranth> nope, we have services
<Amaranth> instead of 'Burrito: seen foo' you do /ns info foo
<JStrike> ?
<JStrike> Thanks
<Amaranth> /ns is short for /msg NickServ
<JStrike> I get no such command
<Amaranth> try /msg NickServ info foo
<JStrike> Let me try with /msg NickServ
<JStrike> That works
<JStrike> Thanks
<JStrike> The reply from NickServe, is that just for the channel I am querying from or for the whole of freenode (i.e the person was last seen in #ubuntu-devel x hours ago, or somewhere on freenode x hours ago)
<Amaranth> freenode
<JStrike> hrm
<saintsjd> Quick question from a newbie: There is a package in Ubuntu universe called gdal.  What can I do to make sure that it is fully supported and inclded in the main repository for the breezy release?
<pitti> saintsjd: essentially two alternatives:
<pitti> 1) write to ubuntu-devel and confine a developer that we can't live without gdal :-)
<pitti> 2) become a developer and care for it yourself
<tseng> pitti: we were talking about it on -motu also
<tseng> pitti: what he really wants is security support for it, which he can help out on in universe as well
<pitti> well, right
<saintsjd> sorry, I am on the ubuntu-devel. It seems I have things cleared up. Universe will be fine for what GIS apps.  There are not needed by most users.
<mx|gone> mjg59: ping
#ubuntu-devel 2006-05-29
<seb128> hi
<_ion> Hi
<seb128> are bug fixes uploads authorized or better to wait for after dapper to upload to dapper-updates rather?
<infinity> seb128: Depends on the bug.
<seb128> infinity: http://people.ubuntu.com/~seb128/shared-mime-info.debdiff ... pdf incorrectly declared as text format
<seb128> infinity: the effect is that text handler are list to right menu by nautilus, but evince is still the default action so it's not a blocker of any sort
<seb128> the fix is trivial but I'm fine to upload it to dapper-updates later
<infinity> Yeah, I'd have no problems with that going in, but I'd wait for mdz, if I were you.
<infinity> Basically, when we start rolling CD images, all uploads will be halted for anything that isn't a CD blocker.
<seb128> right
<infinity> Until then (and we may have another day until then), some stuff like this should be able to get in still.
<seb128> I've just that one ready and I was wondering if I should ping mdz or Kamion about it or just wait for after dapper :)
<infinity> Kamion's taking the day off.
<infinity> It's a UK bank holiday.
<seb128> right
<seb128> dunno what you call "day"
<infinity> Or, rather, it will be when it's Monday.  Which it isn't yet.
<infinity> Stupid me, living in the future.
<_ion> ma toukokuun 29. 01:09:29 EEST 2006
<seb128> it's 0:10am on sunday evening :p
<_ion> Sorry, wrong locale.
<_ion> Well, anyway, it's monday here. :-)
<infinity> seb128: It's 8:09am for me. :)
<seb128> infinity: suck to be you then :p
<infinity> seb128: Nah, it means I get to see the final dapper release CDs 7 hours before you!
<seb128> I'm so jealous :p
<\sh> good to know, that I don't have internet connection while I'm in the hotel
<robertj> someone shoudl make a goal of breaking edgy really bad ASAP after it's open :)
<robertj> just to set a good pace ;)
<infinity> Oh, we will, don't worry.
<infinity> No need to try, it'll just happen.
<\sh> well, first we have to document some regressions for kubuntu which is really embarrassing
<\sh> then we need to fix them and push them through dapper-updates :(
* mdke is hoping for much from dapper-updates
<robertj> \sh: theres always something. DVD playback is less than great as well :(
* seb128 thinks he will not switch to edgy immediatly
<infinity> I suspect dapper-updates will get a lot more use than previous releases, since we want this LTS release to be Just Right.
<seb128> pushing GNOME 2.14.2 to dapper-updates first
<robertj> infinity: also include the fact that it will be around alot longer ;)
<\sh> robertj: functional regressions are so bad...I don't mind for last minute bugs
<mdke> infinity: I hope so.
<infinity> seb128: We're pushing the new GNOME point releases to -updates too?  Cool.
<infinity> robertj: Yes, hence "LTS release" from my above statement.
<seb128> infinity: Mark wanted us to do that I think and I agree that's a good idea
<mdke> seb128: that is good news, does it fix a lot of bugs?
<robertj> I'm glad to hear, although it's kinda disconcerting to have no hard-as-a-rock policy about what goes in updates
<seb128> mdke: medium, we backported a lot of good stuff from CVS stable
<infinity> seb128: Yeah, sounds fine to me, as long as it doesn't introduce regressions.  The idea that "GNOME point releases never introduce new features, and thus introduce few bugs" seems to be complete crack. :)
<seb128> mdke: so we have a good part of the bug fixes we can expect from it
<mdke> seb128: ah... oh well, hopefully a few more!
<seb128> mdke: right
<infinity> robertj: If you want hard-as-a-rock policy, don't use updates at all.  It /is/ optional.
<seb128> mdke: I expect fixing stuff like .Trash on removable medias to dapper-updates too
<mdke> seb128: heh. That would make you my favourite person
<seb128> mdke: I'm just not comfortable touching that code on what will be pressed on the CD yet
<seb128> s/yet/now
<mdke> sure, perfectly reasonable
* \sh needs to go the ubuntu-motu way again for edgy
<mdke> seb128: any luck with the bug where nautilus tries to move stuff instead of copying? does upstream have a fix?
<seb128> mdke: dapper-updates too
<mdke> well, that would rock
<infinity> What's this bug?
<seb128> mdke: upstream is not really responsive atm, I've some ideas on how to fix it but I'm not comfortable with the code to push it to dapper
<Kamion> seb128: that shared-mime-info change is fine if done now
* infinity is curious if the "bug" is what he considers expected behaviour...
<seb128> infinity: dnd from a ro directory to a rw directory on the same partition try to move
* _ion hopes mvo uploads notification-daemon with ion's ubuntu theme.c fix in time for dapper. :-)
<Kamion> (as opposed to tomorrow)
<mdke> infinity: if you drag and drop a file which you don't have write permissions for, it tries to move it, rather than copy
<infinity> seb128: Ahh, I see. :)
<seb128> infinity: like dnd from /usr to your Desktop will give you an error :/
<infinity> seb128: Correct behaviour, except for the whole "can't delete ro" part. :)
<seb128> right
<dholbach> Kamion: can I upload http://daniel.holba.ch/ubuntu/scim.debdiff (new panel icon for it)?
<seb128> and I didn't figure it sooner since my box has /usr on a different partition
<Kamion> dholbach: looks fine, though obviously I haven't looked at the icons; I'll trust you on that. BTW, "find ... -printf '%P\n'" would simplify your debian/rules change
<Kamion> dholbach: er, or not - isn't your debian/rules change just wrong?
<dholbach> Kamion: I use it in gnome-power-manager and ekiga already and all of the configure/clean targets work just fine
<Kamion> dholbach: I'd have expected just "mv -f $${i%.uue}.old $${i%.uue}" - taking basename of $i doesn't seem to help you
<dholbach> um
<infinity> dholbach: Is the "close icon doesn't fit in certain close widgets" bug being addressed?
<dholbach> infinity: no, I'll need to talk to Mark about that.
<Kamion> oh, no, never mind me, I'm reading it wrong
<Kamion> confusing, but OK
<infinity> dholbach: Shows up in epiphany tabs, gaim tabs, and probably most noticeably, the notification popup windows.
<dholbach> Kamion: I'll make a note of your suggestion.
<infinity> dholbach: But all over, really.
<dholbach> infinity: I know :-(
<seb128> dholbach: if the close icon is not fixed I'll be really unhappy
<seb128> dholbach: and I'm not that happy with the update-notifier icon change neither :p
<mdke> also the stop icon appears to be rather odd
<seb128> yeah, I don't like it neither
<seb128> too "sharp"
<mdke> all the other icons are nice and smooth, this one is just very sharp
<mdke> heh
<mjg59> The stop icon is like fine-grain crack
<mjg59> Cut with salt
<seb128> I don't get why artwork guys break icons now
<mdke> check out the difference between the Delete and Cancel icons in evolution
<infinity> But, while the above icons are crap, the only one that's actually "buggy" is the "close" icon.
<seb128> I understand they make change for blurry icons, stuff not ready, etc
<mdke> it just hurts
<seb128> but changing proper icons like that ...
<mjg59> Or the conversation windows in gaim
<mjg59> Send file has a nice picture of a disk
<mjg59> Warn has a little warning triangle
<infinity> mjg59: Yeah, I gave dholbach a screenshot, since he doesn't use gaim.
<mjg59> Block is like OH MY GOD IF YOU CLICK THIS BUTTON THE WORLD WILL END
<mjg59> It's less bad in Epiphany, but it's pretty bad there
<mdke> lol (really)
<seb128> Kamion: http://people.ubuntu.com/~seb128/shared-mime-info.debdiff ... any opinion on that for dapper? I'm happy to delay to dapper-updates if you want
<Kamion> seb128: 23:18 < Kamion> seb128: that shared-mime-info change is fine if done now
<Kamion> seb128: 23:19 < Kamion> (as opposed to tomorrow)
<infinity> seb128: He already said "yes, if you upload now"
<infinity> Someone remind me to never be stupid enough to transfer a DVD ISO over wireless again.
<seb128> Kamion: ah thanks, I skipped it somewhere it in the middle of the discussion with mdke :)
<\sh> infinity: lol
<mjg59> The close button is actually broken in gaim
<mjg59> It's scaled to the point of not having a beval
<mdke> has anyone in the dev team eyeballed https://wiki.ubuntu.com/LiveCDCustomizationHowToDapper ? I reckon it will be popular with languages that aren't supported on the desktop cd, so ensuring that it is valid would be really great
<infinity> mjg59: Yeah, same close button I was talking about elsewhere.
<infinity> mjg59: It's broken in epiphany too.  And in the notification popup windows.  And in gedit... And, and...
<infinity> mjg59: Like I said, that's the only icon that's actually "buggy", we can argue till the cows come home about others being "ugly".
<_ion> mjg59: Scaled, or cropped?
<_ion> http://johan.kiviniemi.name/pictures/icons/
<mjg59> Might be cropping
<mjg59> Oh, hmm, that's not what I have
<mjg59> Has it changed /again/?
<_ion> Sorry, i forgot to write "when using the Tangerine icon theme" to that page.
<_ion> But the same problem with cropped close icons probably applies to all the themes.
<infinity> Tangerine's the default, no?
<infinity> And for me, close is a puffy red square, with a white X in it.
<_ion> infinity: Human is the default. I'm using Tangerine.
<infinity> And it's cropped to heck.
<infinity> Ahh.  For some reason, I thought Human used Tangerine icons.
<infinity> Maybe it falls back to them or something.
<_ion> The ~/.gtkrc-2.0 hack fixes the close buttons, but unfortunately it affects other stuff undesirably.
<Kamion> mdke: I eyeballed it *extremely* quickly (I'm about to go to bed); the main deficiency I see is that it doesn't mention /casper/filesystem.manifest-desktop at all, so ubiquity installs from CDs customised that way may not DTRT
<Kamion> ubiquity removes (manifest minus manifest-desktop) after copying the live filesystem
<mdke> Kamion: that's helpful. I wouldn't know how to fix it, perhaps you (or someone else) could take a closer look and update it after the release?
<Kamion> will try to remember, yeah
<mdke> Kamion: i'll remember ya
<Kamion> TODOed
<mdke> :)
<RemyLaptop> hi guys, does anyone know if there are plans to give the update manager a time scheduler, so for example I can set it to update my system at 1 am ?
<seb128> Kamion: http://people.ubuntu.com/~seb128/gst.debdiff ... ok to upload? The code of the function is http://pastebin.com/743768, the is a double g_free(type) pretty obvious, that fixes a crasher
<seb128> s#is#issue is
<Kamion> seb128: yep, it's obvious, as you say
<Kamion> go ahead
* Kamion -> bed
<seb128> thank you
<seb128> 'night Kamion
<dholbach> good night Kamion
<mdke> noches
* desrt watches macbook exibit some flaky behaviour
<doko> infinity: fglrx works, same problems on amd64 as before
<infinity> doko: So, no regression, but no fixes?
<infinity> doko: Thanks.
<doko> correct
<infinity> desrt: If I build a new LRM with some madwifi-ng fixes, can you test for me?
<doko> i386 works for me as well, have to wait for the flickering to reappear
<desrt> ya.  of course
<desrt> infinity; i just tossed those two modules in /etc/modules -- fixed it up
<RemyLaptop> hi guys, does anyone know if there are plans to give the update manager a time scheduler, so for example I can set it to update my system at 1 am ?
<infinity> desrt: I think I've nailed down all the spots where we accidentally broke the modular nature of madwifi-ng.  I want to test the "right fix". :)
<RemyLaptop> or if not, where can I suggest it ?
<desrt> infinity; about wpasupplicant -- if madwifi-ng gets auto-loaded by the kernel as per default then why is wpasupplicant still built against the old madwifi?
<infinity> desrt: Because madwifi-ng is only the default for a very select few PCI IDs, everything else is using madwifi-old.
<desrt> ah.  good call
<infinity> desrt: Anyhow, be a dear and stick around for a bit.  I'll hack up something.
<desrt> word.
<ssam> RemyLaptop, system -> administation -> software preferences
<ssam> RemyLaptop, #ubuntu+1 is a better place for support questions
<RemyLaptop> ssam - that doesn't allow me to specify what time to do it at...
<RemyLaptop> as a feature that I can't find currently implemented I figured the development channels would be where to ask how to get it implemented ;-)
<\sh> RemyLaptop: what you need is cron or anacron
<\sh> RemyLaptop: but you don't want to have automatic updates anyways...and for automatic updates, update-manager is not the tool you need
<ssam> RemyLaptop, i think the options there control /etc/cron.daily/apt, which is run at what ever time the daily stuff runs
<\sh> ssam: anacron is running this job as well, and it doesn't matter what time you switch on your computer, anacron is checking which jobs he missed and execute the missed job, but it's only doing an apt-get update and not a doomed apt-get dist-upgrade ,)
<infinity> desrt: Which kernel are you using?
<\sh> and if mvo is implementing a self scheduler for update-manager like the windows update service on windows xp, i would travel to bochum and take away the wlan router ;)
<desrt> infinity; -23
<infinity> desrt: I meant which flavour. :)
<desrt> 686
<infinity> desrt: So I don't have to upload the full set. :)
<infinity> desrt: Do you use fglrx or nvidia-glx as well?
<desrt> i810
<infinity> Okay, cool.  So just LRM and LRM-common should do.
* infinity waits for this build to finish...
<infinity> desrt: http://cerberus.0c3.net/~adconrad/desrt/
<infinity> desrt: And be sure to remove your hack from /etc/modules before you reboot and test, or this won't be a very good test. :)
* \sh lols about the transnational republic thread on d-d
<infinity> desrt: I want to know if A) that fixes the problem, and B) if the modules still work. ;)
<desrt> ok
<desrt> binaries, hm?
<infinity> You want the sources too?
<infinity> Oh ye of little faith. :)
<desrt> my paranoid side is making itself known :)
<infinity> I can sign the binaries.
<desrt> it's cool
<infinity> Given that it's the same GPG key as "the guy who runs the buildds", that should do.
<desrt> you already have root on my box anyway :)
<desrt> well
<desrt> small difference
<desrt> you'd might have different moral requirements for uploading a trojan to a random directory on a webserver and to the ubuntu archive
<infinity> Not really. :)
<infinity> But I can pop 'em on people.
<infinity> I just didn't cause I can't be bothered with a 7MB upload.
<desrt> btw
<desrt> what's the deal with wlanconfig?
<desrt> it's built as part of madwifi-ng (which lives in l-r-m) but i don't see how i'm supposed to install it
<infinity> Not required for the standard station case, required to set up other stuff, like AP mode and whatnot.
<desrt> nod.
<desrt> rebooting
<infinity> We're not really shipping it or using it, since the madwifi-ng in LRM for dapper is "just to make shit kinda work on some new hardware"
<desrt> well
<infinity> For edgy, it'll actually get used, since madwifi-ng will be the only madwifi.
<desrt> in all fairness it works fairly well
<infinity> It works fairly well where it does.  And not where it doesn't. :)
<desrt> laptop = SO HOT
<desrt> omg
<infinity> (BTW, I tossed detached signs next to those binaries, if you're feeling paranoid)
<desrt> i've already rebooted :p
<infinity> A bit late now that you've rebooted, mind you. :)
<desrt> looks like it worked
<infinity> \o/
<desrt> ya.  it's fine
<infinity> Do some testing with the network.
<infinity> Does WPA work too?
<desrt> network-manager just automatically authenticated me to my home (wpa) network on login
<infinity> Cool.  And you definitely removed all traces of those modules from /etc/modules?
<desrt> this line was typed from my laptop.
<jdub> infinity: does this change allow us to use /sys/.../new_ids ?
<desrt> /etc/modules has 1 line -- sbp2
<infinity> jdub: You can use sys/.../new_ids to use madwifi-ng with something else, sure.
<infinity> jdub: No reason why you couldn't already.
<infinity> desrt: Yay.  I am teh win!  Thanks for testing.
<desrt> no prob.
* infinity goes to beat mjg59 for not testing this in the first place.
<mjg59> jdub: It's not clear to me why that would fail, and debugging this stuff is a nightmare
<jdub> infinity: with current lrm, it doesn't work (verified with two different pciids)
<nictuku> I'm sorry if this is off topic, but my project needs a mailing list. Do you guys know if lists.ubuntu.com is open for that?
<infinity> jdub: What's the failure mode?
<infinity> jdub: And do you have test kit handy?
<jdub> infinity: what is the change you've just made?
<jdub> infinity: no sign of ath0 whatsoever, even after mucking with wlanconfig
<mjg59> jdub: It makes the driver actually work (but not in the way you were observing)
<infinity> jdub: To unbusticate the internal module loader.
<infinity> jdub: On, yeah, your problem does indeed sound different.
<Burgundavia> nictuku, what is your project?
<jdub> so with infinity's package, i would still have to muck with new_ids
<infinity> jdub: And it may just be a "tough luck, sucks to be you, try again in edgy" bug.
<mjg59> jdub: madwifi-ng is there to support hardware that madwifi doesn't support
<desrt> but only if you don't like WPA
<jdub> mjg59: yeah, yeah 8)
<nictuku> Burgundavia, NWU https://dev.ubuntubrasil.org/trac/nwu/wiki, a ubuntu spec implementation. I tried #ubuntu+2 but no one was there :-)
<mjg59> jdub: It's been explicitly altered so that it doesn't get loaded by default on hardware that madwifi supports. If it can still be made to work, bonus. If not, notabug.
<desrt> since wpa in dapper with -ng is decidedly broken
<infinity> desrt: Win some, lose some.
<mjg59> IF ONLY WE HAD THE DRIVER SOURCE
* desrt isn't sure what this would fix :)
<infinity> We knew in January that the madwifi situation was going to suck.  The fact that it only half sucks right now isn't so bad. :)
<Burgundavia> nictuku, have you discussed it on ubuntu-server? seems to me to be the logical place
<mjg59> desrt: We'd be able to have improved hardware support without jumping to an entirely different codebase, and the world would be better
<nictuku> Burgundavia, that would be my next step, I just didn't want to bother the list with such a specific request.
<Burgundavia> nictuku, ubuntu-server is a good venue because then you can talk about how to integrate it into edgy
<nictuku> Burgundavia, I see. you mean the list, not the channel, right?
<Burgundavia> nictuku, either
<t0rtois3> The python-cairo bindings don't seem to have libsvg built in and libsvg doesn't seem to be in the dapper repositories at all, anyone know why?
<infinity> Do you mean librsvg?
<t0rtois3> maybe, this is confusing me.  Both appear to exist
<infinity> Though I'm pretty sure libcairo does SVG internally.  It certainly doesn't seem to depend on anything else to do it.
<infinity> Wait.  That was the most crackful thing I've said all day.
<t0rtois3> When I try to build python-cairo it looks for libsvg.
<infinity> Cairo doesn't read SVGs at all, it's just a rendering engine.
<t0rtois3> according to http://arstechnica.com/articles/columns/linux/linux-20050822.ars it can read them and then render them
<infinity> Hrm, it might read them natively.  If that's the case, you certainly don't need an external library for it.
<infinity> Given that GTK apps read SVG stuff all the time, I'm pretty sure our lack of libsvg isn't hurting us. :)
<t0rtois3> Maybe there is some new way to go about it using librsvg
<infinity> checking for libsvg-cairo >= 0.1.6... <-- That check?
<infinity> t0rtois3: Since we obviously don't build with that library in Ubuntu, I'd suggest you take your investigation somewhere other than ubuntu-devel. :)
<t0rtois3> ok, thanks for your time
<jdub> t0rtois3: you might be using a version of python-cairo that wants cairo > 1.0.4
<t0rtois3> jdub: it's both the latest and the one that ships with dapper.  I think the gtk way to do it is to use librsvg but the pygtk bindings havn't yet caught up.
<jdub> yeah - cairo in dapper is the latest *stable*
<jdub> but not the latest cairo available
<jdub> (1.0.4 knows squat about svg)
<\sh> ok..time to jump under the shower and get ready for karlsruhe^Wwork
<\sh> laters
<t0rtois3> jdub:So how do most gtk apps handle svg at the moment?
<jdub> t0rtois3: it's automagic, thanks to the rsvg-based GtkPixbuf loader
<jdub> t0rtois3: /usr/lib/gtk-2.0/2.4.0/loaders/svg_loader.so
<t0rtois3> really need to go cairo the whole way
<t0rtois3> ah ha:http://www.rittau.org/blog/20060414-00
<zul> jdub: you are going to be at ols in july arent you?
<jdub> doubt it
<bddebian> Heya folks
<zul> ah ok..
<zul> hey bddebian 
<bddebian> Heya Chuck
<AlinuxOS> hello , someone who can help me in fonts.config issue?
<bddebian> AlinuxOS: What's the problem?
* jdong wonders why mdke hasn't stepped in yet ;)
<AlinuxOS> I've finished testing fonts for future ttf-bpg-georgian-fonts 0.3 vesion.
<AlinuxOS> so I need to have personal ~/fonts.config file for user after installing ttf-bpg-georgian-fonts package.
<AlinuxOS> http://pastebin.com/743996
<mdke> notasupportchannelpleasetry#ubuntu
* mdke winks at jdub 
<mdke> gah
* mdke winks at jdong 
<jdong> :)
<AlinuxOS> mdke, no it's specific question that we should integrate into font pacakge.
<jdong> how are you doing lately, mdke?
<AlinuxOS> it's not only my problem.
<mdke> jdong: fine thanks
<mdke> jdong: you ok?
<AlinuxOS> bddebian, ttf-bpg-georgian contains BPG_Chveulebrivi.ttf  BPG_Elite.ttf  BPG_Rioni.ttf
<AlinuxOS> BPG_Courier.ttf       BPG_Glaho.ttf  fonts.cache-1
<jdong> mdke: I'm doing pretty good. A bit nervous about entering college this fall, but other than that fine
<bddebian> AlinuxOS: I don't think I can help you there.  Sorry :-(
<AlinuxOS> bddebian, ok.
<AlinuxOS> thank you ;)
<mdke> jdong: good. I'm sure that will be fun
<AlinuxOS> ok people
<AlinuxOS> I wish you good night! )
<jdong> good night, AlinuxOS 
<jdong> (and he left)
<jdong> btw, congrats on the great RC, everyone
<jdong> Dapper looks like it's going to be our most polished release ever
<bddebian> Aye
<jmg> hi
<bddebian> Hello jmg
<jmg> hi all
<ajmitch> afternoon
<bddebian> wb ajmitch :-)
<desrt> http://desrt.mcmaster.ca/macbook.xhtml
<desrt> yay.
<Lathiat> desrt: cool
<Lathiat> One interesting note is that the 'IEC958' setting in alsamixer toggles the headphone port between copper and fibre modes. If you turn this setting on you should see a red LED glowing inside the headphone jack.
<Lathiat> scary
<desrt> ya.  weird.
<crimsun> which codec does that machine use?
<desrt> ich7
<crimsun> stac9220x5?
<desrt> so whatver that is
<crimsun> (tail -2 /proc/asound/oss/sndstat)
<desrt> stac9221
<bddebian> crimsun!!
<desrt> 0: sigmatel stac9221 a1
<desrt> why do i get the feeling that crimsun is going to have me installing alsa-sources rsn?
<crimsun> no, not yet :-)
<desrt> no fixes yet?
<crimsun> well, there has been work for the macminis, and if you were to apply it, you'd have to add your sub{vendor,device} ids
<crimsun> (http://hg-mirror.alsa-project.org/alsa-kernel?cmd=changeset;node=14772d35b9a64e07d703c9eaac0d34fca76d87eb;style=gitweb)
<desrt> well
<desrt> thing is, the driver loads....
<desrt> oh
<crimsun> yeah, it must be routing at this point
<desrt> + { .pci_subvendor = 0x8384,
<desrt> + .pci_subdevice = 0x7680,
<desrt> + .config = STAC_MACMINI }, /* Apple Mac Mini (early 2006) */ 
<desrt> this doesn't look like a normal pci 'supported cards' list
<crimsun> don't worry, nothing's really standardised in sound/ :-)
<desrt> well
<desrt> i'll try that patch and let you know
<desrt> i love linux-headers
<desrt> it seriously makes my day
<desrt> crimsun; my snd_hda_intel is in use.  how to i un-in-use it?
<crimsun> desrt: kill whatever's using it (use ``lsof /dev/dsp* /dev/snd/*'' to get the pids)
<desrt> oh of course.  mixer applet
<desrt> no improvement :(
* desrt double-checks his device ids
<desrt> what's the story with subvendor and subdevice?
<desrt> are these the normal PCI device ids or some weird subdevice inside the soundcard?
<crimsun> lspci -nv -> pastebin
<crimsun> we should migrate to #ubuntu+1 to avoid cluttering the channel
<desrt> k.
<desrt> crimsun++
* desrt moves sound from the 'broken' to 'working' list :)
<desrt> awesome.  my 'fn' keys are working now
<jdub> no need to swear
<ispiked> what theming engine does the new human theme use?
<jdub> ubuntulooks, a minor branch from clearlooks
<crimsun> eslowerthanjdub
<ispiked> jdub: is this in gnome's cvs?
<jdub> i don't know
<jdub> you'd have to ask remenic
* ispiked wants to view the source online.
<ispiked> fedora seems to use the same one.
<ispiked> so it can't be all of Ubuntu's tweaking.
<Burgundavia> ispiked, I believe FC is still using clearlooks
<ispiked> Burgundavia: http://www.sitening.com/blog/2006/05/25/fedora-core-5-review-with-screenshots/
<ispiked> Burgundavia: looks like the new Ubuntu theme to me!
<crimsun> that looks like clearlooks.
<jdub> no, that's just clearlooks
<ispiked> I'm using clearlooks right now, and it doesn't look like that.
<jdub> there are only minor differences between them - ubuntulooks is based on clearlooks
<jdub> because the default clearlooks theme in gnome doesn't turn on all the clearlooks bling
<ispiked> the theme shown here looks like what I'm using: http://gnome.org/start/2.14/notes/en/rnusers.html
<jdub> yes, that's clearlooks with all the bling turned off
<ispiked> what controls the bling?
<jdub> settings in the gtkrc
<ispiked> hmm...
<ispiked> is ubuntlooks more than just a modified gtkrc?
<jdub> yes
<jdub> it's a modified engine
<ispiked> hmm... I wonder how much it differs from clearlooks.
<ispiked> enough that they needed to branch it, I guess.
<jdub> it has a bunch of different effects, like the shiny buttons
<ajmitch> even more shiny bling :)
* ajmitch hates to think what edgy will turn out like
<Burgundavia> ajmitch, don't you love shiny bling?
<Burgundavia> who cares if it crashes occasionally
<ajmitch> Burgundavia: no, I'm a boring person who uses clearlooks & tango
<ajmitch> XGl held my attention for an hour or so at most
<ajmitch> too much shiny to get any work done
<Burgundavia> haven't even tried it, tbh
* desrt wants DSDT-fu
<ajmitch> that sounds dangerous
<desrt> as far as i know, the DSDT is a sort of bytecode that describes what the OS ought to do in certain situations
<desrt> for example, if it wants to know how to sleep, it looks up the 'sleep' entry in the DSDT and pokes the ports that it tells it to
<ajmitch> yes, it's a scary area
<ajmitch> I prefer to leave that to people like mjg59
* desrt is on a roll tonight, though :)
* desrt has moved 3 items from his "not working" to his "working" list
<desrt> i want a 4th :p
<Burgundavia> desrt, how come I don't see you in #ubuntu-ca ?
<desrt> i'm not a canadian
* Burgundavia calls desrt's bluff
<desrt> :)
<Burgundavia> http://transmission.m0k.org/screenshots.php <-- we might want to replace gnome-torrent with this in dapper
<jdub> itym edgy
<Burgundavia> yes
<desrt> itym?
<desrt> i think you mean
<jdub> the gnome ui needs tidying up
<Burgundavia> yes, it does
<ajmitch> Burgundavia: why is it special?
<Burgundavia> ajmitch, it is SDI
<ajmitch> ah
<Burgundavia> no hundreds of little windows
<Burgundavia> be nice to have one that saved over multiple sessions too
<ajmitch> so closer to firefox's download window
<Burgundavia> yep
<Burgundavia> maybe the long-running thingy that is being done for GNOME might be better
<desrt> bittorrent has a weird focus
<Burgundavia> desrt, wierd focus?
<desrt> focus is the wrong word
<jdub> 'weird'
<desrt> mental model?
<desrt> it's very very different than any other p2p technology
<Burgundavia> ah
<desrt> wow.  my grammar is suffering.
<jdub> ber, this uses 'jam', yet another attempt to replace autofoo
<jdub> Burgundavia: would be better to replace the ui for the current one
<jdub> why reimplement bittorrent in C?
<Burgundavia> there was a plan by someone todo that, but I think it stalled
<desrt> having python bittorrent pretty much guarentees your backend code will never fall out of maintainership
<Burgundavia> except their v4 license is crap
<Treenaks> Burgundavia: there is a re-implementation in C - see 'rtorrent'
<Treenaks> Burgundavia: (warningL: ncurses interface hell)
<Burgundavia> should the installer have mounted my windows partition>?
<desrt>    ----- The following addresses had permanent fatal errors -----
<desrt> <andrew_j_dunham@hotmail.com>
<desrt>     (reason: 550 Error: ".crt" file attachment types not allowed in MIME)
<desrt> this is comical.
<Burgundavia> why so?
<desrt> wtf?
<Treenaks> desrt: You evil terrorist! Encryption is only used by people like you!
<desrt> ...
<Treenaks> desrt: (assuming that was some x.509 certificate file)
<desrt> it is
* desrt runs a smalltime certification authority out of his home :)
<Treenaks> argh, the wiki changed its From: address
<desrt> wow
<desrt> according to /proc/cpuinfo my macbook is running at 3.3ghz
<desrt> no wonder it gets so hot
<desrt> 165% overclocked
<Burgundavia> jdub, you seen this? https://wiki.ubuntu.com/GnomeBlingManager
<pitti> Good morning
<jdub> wow, someone bothered to write that in C?
<Burgundavia> same guy who wrote the livechatsupport
<Burgundavia> he is also the cross posting one
<neuralis> C for that? why on earth?
<desrt> quite the UI.
<neuralis> Burgundavia: well, the guy certainly has enthusiasm. if only it can be channeled a bit..
<pitti> mdz: permission to upload http://librarian.launchpad.net/2953556/alsa-utils_1.0.10-1ubuntu14.debdiff ? it is a trivial fix to repair sound on ppc G3 systems
<Burgundavia> neuralis, indeed, makes it so much harder
<desrt> jdub; why does planet strip style out of blog entries?
<jdub> desrt: because style is evil (as it happens, an upcoming version won't)
<desrt> hum.
<desrt> is there any way to float:right an image that will survive planet?
<Burgundavia> desrt, got an idea for a masters yet?
<desrt> Burgundavia; oh yes
<desrt> Burgundavia; program verification
<desrt> Burgundavia; with a decidedly educational spin, if i can swing it
<mantas_> hello all
<Burgundavia> desrt, program verification?
<desrt> Burgundavia; there is this formal language called BESTT (basic extended simple type theory) which can be used to formally state program semantics.  theoretically, we're supposed to be using it for teaching because it's really nice
<desrt> unfortunately, we don't have good tool support
<desrt> mostly due to the fact that nobody's really heard of BESTT before
<mantas_> pitti, hi, are you alive ?
<SuperQ> http://www.bevmo.com/productinfo.asp?sku=00000077065 <- so tasty
<desrt> that looks like it might be ok
<SuperQ> it is
<neuralis> desrt: most people i know who did substantial research in formal software verification walked away with the same conclusion; they were bored out of their minds.
<neuralis> there are a few notable exceptions, but they're rare.
<pitti> mantas_: yes
<desrt> neuralis; i'm well aware of the risks
<desrt> neuralis; i have something over top of the average grad student who gets bored doing formal verification, though
<desrt> so i think i'll do fine :)
<neuralis> desrt: all of the people i was talking about were professors ;)
<mantas_> pitti, language-packs in dapper are 1 week old - lots of translations are updated since ;)
<desrt> yes?
<desrt> most professors i know don't have the quality i'm speaking about
<pitti> mantas_: I know; maybe we'll update them today; if not, we'll update them post-release
<desrt> (the ability to code my ass off)
* pitti hugs desrt, how are you?
<whiprush> howdy gents.
<desrt> pitti; i'm fantastic :)
<desrt> pitti; yourself?
<whiprush> 3 days!
<pitti> desrt: quite breezy, almost dapper :)
* desrt tries to think if pitti can help with any problems
<desrt> pitti; don't drink any more coffee.  you may start getting edgy.
<pitti> desrt: I don't even drink coffee ;)
<mantas_> pitti, please, don't update post-release - in Dapper Release Roadmap langpack translation deadtime was on 25 May, but current langpacks are only 22 May :(
<desrt> oh.  perfect.
<pitti> mantas_: what's wrong with post-release? most langpacks aren't even on the CDs anyway
<neuralis> desrt: i think you'll find there's very little new ground to be broken with coding in that field. it's almost wholly theory work that's needed.
<mantas_> pitti, but all translations are in DVD
<desrt> neuralis; you may be onto something with this idea
<pitti> mantas_: hm, true
<mantas_> pitti, and DVD images will be not updated after release
<desrt> neuralis; but what i am planning is very practical and applied, and it seems (at least right now) that there is room for it
<pitti> mantas_: I'll talk with mdz; we were still undecided whether to update them again
<mantas_> pitti, and for example in Lithuania there are lots of computers without internet connection
<neuralis> desrt: fair enough. what level of a thesis is this? bs/ms/phd?
<mantas_> so, they will install/upgrade Ubuntu from DVD
<desrt> ms
<neuralis> desrt: so that's fine, you'll be able to mostly dodge theory if you want to. 
<neuralis> desrt: best of luck.
<mantas_> pitti, btw, is there a possibility to update only 1 language langpacks ? Bug #34914 is fixed only on May 26 (most traslations were sent until May 25, but rosetta accepted them only on May 26, because rosetta was busy with importing lots of openoffice translations...)
<Ubugtu> Malone bug 34914 in Ubuntu "GNOME 2.13 translation to Lithuanian language uses an artifical term for File translation (Rinkmena), which is incompatible with other free software (including previous versions of GNOME)" [Major,Fix committed]  http://launchpad.net/bugs/34914
<desrt> neuralis; :)
<desrt> i love how everyone has their angle
<desrt> everyone thinks that the freeze should break for them because their issue is _important_
* desrt is so guilty here too
<mantas_> desrt, you about our bug ?
<desrt> mantas_; about everyone :p
<LaserJock> what? my issues aren't important? ;-)
<mantas_> desrt, it's not our problem, that deadline of language pack translations was anounced on May 25 in Dapper Release Roadmap...
<mantas_> I think ubuntu developers should follow they roadmap, at least don't make deadlines earlier, than is annouced
<kagou> hi
<desrt> mantas_; i'm just kidding around
<desrt> and now i am falling into bed
<desrt> goodnight everyone.
<mantas_> desrt, hehe, goodnight (while in my country is morning ;) )
<pitti> desrt: good night!
<Mithrandir> uh, why is the "you have been subscribed to this spec" a <p class="error message">?
<pitti> mdz: permission to upload http://paste.ubuntu-nl.org/14826 ? only changes dependencies of postgresql-common, and it's not on the CD
<dholbach> good morning
<mantas_> morning
<carlos> pitti: I should talk with you by phone before the Ubuntu sprint, one of the specs I will work on is on a new infrastructure to deploy translatable resources without using .deb packages
<carlos> pitti: I talked with mark about this and he agreed that we should implement it for Edgy's univere
<carlos> universe
<carlos> and then, move it to edgy+1's main
<pitti> carlos: this reminds me of the controversial discussion we had in Mataro, where we had this option as well
<pitti> carlos: yeah, let's talk about it post-release
<carlos> pitti: yeah, is a bit controversial, but it's the only way to provide universe with language packs...
<carlos> pitti: I was thinking on taking what Lliurex is doing atm, let me send you the URLs so you read them before the phone call, ok?
<pitti> carlos: can we do that phone call not before Friday?
<carlos> pitti: sure, I only need to have it before the sprint so we can focus only in the details 
<carlos> pitti: I will be at Paris from Wednesday to Staturday (arriving Tuesday night)
<carlos> and I need to work on OO.org, Firefox and language packs for universe
<carlos> so I need some discussion done before
<crimsun> pitti: insight into the various alsa-lib error spew regarding not being able to find components for "default", etc. (bug #31699, bug #35540, debian #369299 and its dupes) has been posted and attached to bug #43146
<Ubugtu> Malone bug 31699 in alsa-utils "Can't use other than default sound card" [Major,Fix released]  http://launchpad.net/bugs/31699
<Ubugtu> Malone bug 35540 in gnome-volume-manager "Using alsamixer/amixer after selecting a non-default sound card (System> Preferences> Sound> Default sound card) results in errors" [Normal,Fix released]  http://launchpad.net/bugs/35540
<Ubugtu> Debian bug 369299 in libasound2 "Subject: libasound2: pcm.c:2146:(snd_pcm_open_noupdate) Unknown PCM default" [Important,Open]  http://bugs.debian.org/369299
<Ubugtu> Malone bug 43146 in alsa-lib "gnome-sound-properties generates broken alsa conf" [Normal,In progress]  http://launchpad.net/bugs/43146
<janimo> Kamion: can the desktop dependencies generated from the seeds contain alternate depends?
<dholbach> janimo: there's no support for alternate depends yet.
<janimo> dholbach: ok, thanks
<Mithrandir> I wonder why openvpn and rsyncing off cdimage seems to be broken.
<fabbione> Mithrandir: i think the same issues as before RC
<thep> Kamion, i've got a bug report on dapper installer (text) when choosing Thai keyboard map: it shows red screen of error
<Mithrandir> fabbione: what was that?  It works if I forcefully route it through my DSL connection instead of the openvpn connection.
<fabbione> Mithrandir: cdimage does limit to max 2 connection per ip
<fabbione> probably the other did hang and needs to timeout
<Mithrandir> fabbione: unless it hangs for (literally) ages, I wouldn't think so.
<Mithrandir> I haven't rsynced off this machine for a few days.
<fabbione> iirc the timeout is several mintues
<Mithrandir> unless it's > 72 hours, it should have timed out
<fabbione> eheh i guess so
<dholbach> Kamion, mdz: I'd really like to get the patch in bug 46440 in (it will enable documentation (scrollkeeper) for all the locales we have in language packs (there were a lot missing) - what do you think?
<Ubugtu> Malone bug 46440 in scrollkeeper "There is no Croatian translation of desktopguide" [Normal,Fix committed]  http://launchpad.net/bugs/46440
<janimo> mvo: hi, regarding the xubuntu-desktop conflicting with ubuntu-desktop bug
<mvo> janimo: what bugnumber?
<janimo> do you think it would be ok to make xubuntu-desktop alternately depend on gnome-system-tools
<janimo> mvo:  let me check
<seb128> janimo: any plan to fix thunar?
<janimo> seb128: yes
<seb128> when?
<janimo> seb128: waiting to see what upstream sais to my comments
<janimo> well today
<seb128> k, so maybe after dapper if upstream doesn't reply
<seb128> you were already saying that saturday
<janimo> seb128: I did not say I would fix it Saturday
<janimo> just before dapper
<seb128> no, you said you wait on upstream
<janimo> seb128: since then upstream replied and I replied back
<seb128> I'm wondering what you will do if upstream doesn't reply
<janimo> read the bugzilla comments
<carlos> pitti: would be possible to use tomorrow's language pack as the final one?
<janimo> mvo bug 46191
<seb128> looks like upstream is on crack
<Ubugtu> Malone bug 46191 in xubuntu-system-tools "xubuntu-system-tools conflicts with gnome-system-tools" [Normal,Confirmed]  http://launchpad.net/bugs/46191
<janimo> seb128: tell upstream that not me
<mvo> janimo: right, this one
<pitti> carlos: I don't know, that's mdz's decision and depends on the CD testing results; from my side it's no problem at all
<carlos> ok
<seb128> janimo: I've enough to do atm, I've already explained everything on the launchpad bug
<janimo> mvo, the altrenatives as I see it are either hand modify the generated xubuntu-desktop depends 
<carlos> pitti: I'm doing a small fix for KDE German translations
<carlos> would be good to have that fixed with latest release, but it's ok if we need to wait
<carlos> for next release
<janimo> mvo, or make xubuntu-system-tools Provide gnome-system-tools. But ther latter could affect mixed installs
<janimo> seb128: you actually did not explain, but  I will fix it nonetheless
<seb128> janimo: but I'll make clear how much bad willing you are putting to try to get the fixed for dapper
<janimo> seb128: you said it was a firefox bug if it happened so you don;t care
<janimo> seb128: so I have to check it myself and it takes more time than just saying go fix it
<mvo> janimo: hand modify to "xubuntu-s-t | ubuntu-s-t"?
<janimo> mvo: yes, what do you think?
<seb128> janimo: I'll let the bug for now because you seem to enjoy yourself not fixing it, but don't worry I'll fix it today if you don't
<janimo> seb128: give me a break already. I said I would fix it 
<seb128> janimo: I don't trust you to do so
<janimo> seb128: well what can I do?
<seb128> you show real bad willing on that for a week
<seb128> janimo: nothing, I'll fix it myself
<mvo> janimo: its ugly, but I guess it is better than breaking. we need to sit down together in paris to discuss what to do with the system tools
<seb128> don't bother
<janimo> mvo: I hope the system tools will be replaced by a pygtk one no by edgy?
<seb128> I doubt of that
<seb128> it's likely than by edgy the new g-s-t upstream infrastructure will be used
<mvo> janimo: we have little time and no that many resources. but it would be good if the system-tools would get some love
<seb128> using dbus etc
<seb128> mvo: Carlos closed a zillion of bug for some days in fact
<mvo> seb128: really? that is good to hear
<seb128> mvo: I think he landed to CVS the new g-s-t generation
<janimo> mvo, seb128 ok. I thought g-s-t was unmaintained and daniel said the 3 of you were planning a python replacement
<dholbach> mdke: um, are you aware of scrollkeeper breakage in ubuntu-docs? /usr/share/ubuntu-docs/common/et/preface.xml?
<carlos> seb128: the one that uses hal's security infrastructure to stop using setuid of gksu programs?
<dholbach> mdke: might be worth to fix that in the upload too, what do you think?
<carlos> that's good news
<seb128> carlos: I'm not sure there is anything like that, the one that uses dbus to communicate between backend and frontend rather
<mvo> seb128: i'll talk to him next time I see him online
<carlos> seb128: that's the same thing then
<janimo> mvo, so if I add the alternate deps manually paralell installs of {x,}ubuntu-desktop should be ok right?
<seb128> mvo: good, let me know when you start the discussion then I can join
<dholbach> janimo: while we plan it and would love to get that done, seb128 is right - it will require a lot of hard work
<mvo> seb128: we could add a python based network backend then, that would certainly be very good .
<seb128> carlos: I doubt he make that secure daemon yet
<mvo> seb128: I haven't seen him on irc for ages
<carlos> seb128: hal did
<carlos> seb128: it's not something specific from g-s-t
<seb128> carlos: he doesn't use hal, he just uses the dbus bus to communicate
<janimo> dholbach: it could be ubuntu specific witohut all the legacy that current backends support
<carlos> seb128: hal uses dbus too for that feature, so it's either implemented, or is the first phase to get it done that way
<mvo> janimo: yes, it should be. I can do a test-run for it in a bit
<seb128> carlos: I think it's rather the first phase to get it done
<janimo> mvo, I'll upload with next xubuntu-desktop then
<carlos> ok
<seb128> carlos: bug right, one step to the right direction ;)
<carlos> ;-)
<janimo> seb128: any news whether gtk 2.10 will be used by gnome 2.16?
<seb128> janimo: I stop talking to you, fix your bugs first
<janimo> seb128: man you're mean
<seb128> you are trying to make sure Ubuntu will be bugged and I don't like it at all
<janimo> seb128: if I try to make sure kubuntu is bugged would you forgive me?
<seb128> no
<janimo> damn
<seb128> I spend like 1 hour to comment on that bug saturday and to explain you what the issue is, but looks like you enjoy making it me spend time for nothing on it and refuse to fix it
<seb128> that's noted
<dholbach> calm down guys... it's release time and we're all stressed
<seb128> dholbach: I've been patient enough to explain him several time what the issue is, to comment with details on the bug when he asked but there is some limit where you can stop being calm then
<seb128> dholbach: and I'm calm ;) I just want that bug fixed
<dholbach> your language doesn't reflect that :-/
<janimo> seb128: FYI I have spent way more than 1 hour on this bug, which I consider a gnome bug BTW
<seb128> dholbach: I spend^Wwasted hours on that where I could have fix it in 1 min, to be nice
<janimo> if it want to call nautilus call nautilus do not go via an indirection which everyone knows about
<seb128> dholbach: but seems it doesn't work to be nice
<seb128> janimo: you didn't read anything on what I said saturday or on the bug, you make me waste my time on that
<seb128> nothing wants to call nautilus, then open a "x-directory/normal" mimetype
<dholbach> can't we have a pragmatic, easy fix which makes xubuntu and ubuntu happy?
<janimo> seb128: oh yes. Being nice works all the time. You are just not being nice that's all.
<seb128> janimo: not with you since you decided you will not fix it for whatever reason
<janimo> seb128: if you look at what users say, they get either thunar or nautilus popped up depending on what they click on. That is inconsistency in gnome IMHO
<seb128> janimo: nautilus will always open directories with nautilus, that's normal
<janimo> seb128: I assume you saw this coming 6 months ago, so you were not being nice in advance
<seb128> janimo: gnome-panel or deskbar uses the x-directory/normal handler
<dholbach> please choose an easy, pragmatic fix fow now which makes you both happy - this discussion about who is nice and and who not doesn't lead anywhere in case you didn't notice :-/
<seb128> dholbach: I'm not discussing who is nice, I don't care, I just want that bug fixed
<janimo> seb128: and you're commentig on the bug that this si not a mimetype it's wrong. It is a mimetype as it is in mime.cache. It is just gnome private. But still a mimetype
<seb128> dholbach: and I already explained a zillion of time what the fix is, but he will not listen nor provide a good argument on why he will not
<seb128> dholbach: I think that's just "you have been not notice so I'll screw dapper to teach you" game
<seb128> which is a pitty
<janimo> seb128: I told you I'll fix it already
<infinity> janimo: By that argument, application/x-flaming-poo would be a valid mime-type if I registered a handle for it.
<seb128> janimo: stop telling it and do fix it
<mdz> dholbach: the patch for bug 46440 is rather long and difficult to read
<Ubugtu> Malone bug 46440 in scrollkeeper "There is no Croatian translation of desktopguide" [Normal,Fix committed]  http://launchpad.net/bugs/46440
<seb128> janimo: your mimetype is not listed by /usr/share/mime/* -r
<janimo> infinity: sure, why not?
<pitti> mdz: good morning
<infinity> janimo: The fact that a mime HANDLER is registered as a private interface doesn't make it a valid mime-type for the world to use.
<seb128> public types are listed by /usr/share/mime/* -r 
<mdz> pitti: postgresql-common dep change is fine
<janimo> infinity: otherwise why would apps put it in .desktop files MIME=Type handler?
<janimo> and get in the mime.cache?
<janimo> infinity: i did not say valid or public or not? But a mimetype
<infinity> janimo: (Sure, I agree that nautilus and GNOME probably should have done this differently, rather than overload the MIME system, but it's a bit late to fix that now...)
<dholbach> mdz: I agree - I'll make a more appropriate diff (as I renamed one of the patches)
<msikma> test
<msikma> Great, now I can irc at work.
<mdz> pitti: what is the story with final langpacks for release?  I think we said yesterday or today
<janimo> infinity: that's why I was trying to make sure changin it does not break default xubuntu install before just commiting the proposed fix
<pitti> mdz: well, they get a bit better every day :) carlos said he would like us to use tomorrow's
<pitti> mdz: however, that might be a bit too late
<carlos> right
<janimo> infinity: as opposed to commiting right away to fix a non-ubuntu default corner case which is reached by user conciosuly installoing thunar
<carlos> mdz: pitti: Anyone will fit, but as much late we take them, more translations fixed we will get ;-)
<mdz> pitti: tomorrow is too late
<carlos> ok
<mdz> carlos: yes, after 1 June they will be even better ;-)
<carlos> right
<seb128> janimo: installing thunar seems a non-corner case 
<carlos> we should stop them at some point
<carlos> I know ;-)
<janimo> seb128: in gnome?
<mdz> carlos: even the sab agreed to stop today
<pitti> mdz: I'm fine with taking any of yesterday's or today's, they are all fine 
<seb128> janimo: in Ubuntu, you know, some people install several desktop and switch between them
<janimo> seb128: anyway it is not OMG janimo breaks dapper. Users installs thunar that is so not default ubuntu install
<carlos> mdz: Is ok for me, don't worry
<mdz> pitti: whatever you like, so long as they are uploaded today
<dholbach> mdz: I sent an updated patch on bug 46440
<Ubugtu> Malone bug 46440 in scrollkeeper "There is no Croatian translation of desktopguide" [Normal,Fix committed]  http://launchpad.net/bugs/46440
<doko> mdz: any word about the qt-x11-free and ia32-libs-kde uploads?
<pitti> mdz: alright, then I'll ask Kinnison or cprov to upload today's (shuold be finished around 1500 UTC)
<mdz> doko: I am still working through my scrollback
<infinity> pitti: If you're going to do langpack uploads right now, hold off for long enough for me to update the i386 buildd chroot tarball.
<seb128> janimo: some people install xfce to have a look, that's a shame it breaks their GNOME desktop directory handler and trivial to fix
<mdz> doko: did you check how this affects the CD size?
<pitti> infinity: no, not right now, in about 6 hours
<janimo> seb128: you know just as well I could tell you to change nautilus do not take over desktop by default. Users can install it and open a folder with it and it take the desktop away
<infinity> pitti: (So there's no update/dist-upgrade dance at the beginning of each of the 8 billion langpack builds, slowing things down even further..)
<fabbione> doko: ia32-libs is broken on ia64... if you plan to upload that, do you mind to fix the postinst script? the diversion goes bana
<fabbione> banana even
<janimo> seb128: should I start lamenting that you are undermining xfce and things like that?
<infinity> pitti: Ahh, kay.  That gives me time.  I'll be ready when you are. :)
<carlos> doko: hi, were you able to generate the OO.org language packs from the .po files I sent you?
<janimo> mixed environments are corner cases, and harder to fix well so that noone complains
<seb128> janimo: those points have nothing to do, nautilus doesn't take over your xubuntu desktop if you don't run it, and if you run it you have a gconf key and a --no-desktop
<dholbach> janimo, seb128: please stop the accusations, please.
<infinity> fabbione: Is there a bug for the ia64 breakage?  I haven't tested the ia64 upgrade path (though I just re-tested breezy->dapper on amd64 to confirm THAT was fine)
<janimo> dholbach: ok 
<fabbione> infinity: no i don't think i did file a bug
<seb128> dholbach: stop telling me to stop the accusations, I don't accuse anybody
<fabbione> infinity: and i can't test it atm because i have no ia64 turned on at hom
<fabbione> home
<seb128> dholbach: I just want that bug fixed now
<fabbione> tho i could get it online
<fabbione> infinity: can you test, or do i need to call my wife to get it on+
<fabbione> ?
<dholbach> seb128: I understand.
<fabbione> infinity: the bug was on fresh install
<fabbione> infinity: i am sure you can reprouce it in a chroot
<infinity> fabbione: Calling your wife to get it on sounds like fun, but I think I can manage.
<infinity> fabbione: I'll go play with debootstrap on an ia64 buildd.
<fabbione> infinity: just grab a buildd chroot and install ia32-libs
<fabbione> that's all i did to reproduce it at home
<infinity> Oh, fun.,
<infinity> Okay.
<mdz> doko: these changes will fix oo.o-kde on amd64 without touching oo.o itself?
<infinity> Of course, I'll probably also have to test the breezy->dapper upgrade path for ia64.
<fabbione> infinity: what really scares me to ask my wife is that the ia64 is right next to the server... wrong button and i need to fly back home
<infinity> And then make sure I'm not breaking amd64 in the process.
<infinity> Whee.
<fabbione> infinity: the amd64 part is if/def
<mdz> doko: I expect infinity is rather bored with building oo.o by hand at this point
<doko> mdz: it's plus 1,5MB on amd64-kubuntu, which is fine according to Riddell, no other images are getting bigger
<doko> mdz: if we want to fix OOo-amd64 on ia64, then we need to change OOo-amd64 as well, but that's not needed at this point
<infinity> OOo-amd64 isn't tough to change.
<infinity> Assuming you don't mean that we need to change OOo-i386 to put it in OOo-amd64. :)
<doko> mdz: I'm rather bored by trying to reproduce this failure myself, including setting up new installations on two single cpu machines.
<mdz> doko: why do we need different config dirs for this case?
<doko> mdz: for this case? we always need a different plugin directory for 32/64 bit plugins
<mdz> doko: what I mean is, how is this related to the oo.o-kde problem?
<doko> mdz: the kde theme and scim plugins can not be found
<mdz> doko: those are in the system-wide dir, yes?
<doko> they are in /usr/lib/qt3/plugins and /usr/lib/kde3/plugins, referenced by /etc/qt/qt_plugins_3.3rc; if this file cannot be written, it's written in the user's home dir
<doko> fabbione: which version? 1.4ubuntu17 or 1.4ubuntu18 ?
<mdz> doko: Riddell seems to have already changed kubuntu-meta to remove it
<doko> mdz: it=what?
<mdz> doko: oo.o-kde
<mdz>    * Removed openoffice.org-kde from desktop-amd64, desktop-ia64,
<mdz>      desktop-sparc
<ogra> mdz, got my mail about hwdb ?
<mdz> ogra: I am not there yet
<ogra> ok
<doko> mdz: ohh, fun, maybe he could have told me before spending the weekend on it?
<infinity> mdz: I think he changed it proactively, but was also working with doko to track down the problem so he could add it back.
<infinity> mdz: At least, that seems to match the sequence of events that I watched.
<seb128> janimo: for information according to a "grep "gnome-default-handler" * -r" to firefox source directory, firefox doesn't use "gnome-default-handler"
<janimo> seb128: already checked that, and it works w/o that
<janimo> thats' what I said to uptsream in bugzilla querying what use did he see
<janimo> seb128: so yes I have been working on the bug
<ogra> janimo, any feedback for the xubuntu ltsp install yet ? 
<janimo> ogra, two guys you saw on the list . I assume they'll feedback to the list as well
<janimo> by tomorrow as they said
<ogra> ok
* highvoltage is installing now under vmware
<infinity> Argh, where's cprov when I need him?
<Riddell> mdz: I was erring on the side of caution, but I'll put it back if doko's fixes get uploaded
<janimo> seb128: sorry for your wasted time and nerves.
<seb128> janimo: better to not make me waste efforts trying to explain what the issue is next time, if you decided you don't trust what I say and will wait for upstream anyway
<doko> fabbione: what exactly is wrong about ia32-libs? which version is wrong?
<mdz> Riddell,doko: let's go with what we have, and consider the better fix for post-release
<pitti> mdz: do you have a yay or nay for crimsun's alsa-utils patch to fix ppc g3 sound?
<mdz> pitti: I don't know what patch you mean
<pitti> mdz: http://librarian.launchpad.net/2953556/alsa-utils_1.0.10-1ubuntu14.debdiff
<fabbione> doko: the latest one.. it's a diversion error the preinst or postinst and only on ia64
<infinity> fabbione: I'm looking at it right now.
<fabbione> infinity: thanks
<mdz> ogra: hwdb patch is OK
<ogra> mdz, thanks :)
<infinity> doko: My last upload only fixed things on amd64, I never tested ia64.  My bad.  I'm looking right now.
<ogra> we'll re-rnable it in edgy again
<mdz> pitti: fine to upload
<fabbione> mdz: we have no patch for that memcpy bug :/
<doko> infinity: there was no difference on amd64 and ia64
<doko> in breezy
<infinity> doko: There's a huge difference in dapper, though. :)
<mdz> fabbione: I know, the deadline was yesterday :-/
<fabbione> mdz: yeah.. we will need to decide what to do.
<fabbione> mdz: specially because it bites on install
<mdz> seb128: regarding shared-mime-info, the bug is already marked Fix Released?
<Riddell> mdz: a couple of diffs for you to review: this one fixes a problem with gtk-qt-engine http://kubuntu.org/~jriddell/tmp/gtk-qt.diff
<seb128> mdz: which one?
<mdz> seb128: bug 44523
<Riddell> mdz: 
<Ubugtu> Malone bug 44523 in abiword "abiword (and other text editing apps) should not appear in the Open With menu for PDFs" [Normal,Confirmed]  http://launchpad.net/bugs/44523
<seb128> mdz: yeah, I've uploaded the package yesterday (Kamion approved it)
<Riddell> and one to add some missing mimetypes to the kmplayer plugin priority http://muse.19inch.net/~jr/tmp/kds.diff
<seb128> mdz: is that wrong?
<mdz> Riddell: this is not actually used in the default install, yes?
<mdz> seb128: oh, I thought you asked me about it this morning
<fabbione> infinity: what's the url to monitor buildds?
<Riddell> mdz: they are
<seb128> mdz: I did?
<infinity> fabbione: lp.net/+builds
<mdz> seb128: maybe you asked last night and it was in my scrollback
<fabbione> infinity: danke
<seb128> mdz: probably yep
<mdz> Riddell: the gtk-qt thing I mean
<fabbione> infinity: is it actually working??
<infinity> Isn't that the thing I uploaded yesterday that's in kubuntu-desktop and has the evil "don't use shlibs" hack?
<fabbione> infinity: it still reports ooo building on i386 and no ooo build on sparc...
<infinity> fabbione: sejong died, hence the sparc build is being rescued...
<Riddell> mdz: it's used if you don't have gnome installed
<fabbione> infinity: died, how?
<Riddell> for users with some gtk programmes but not full gnome
<infinity> fabbione: Ask Znarl.  He just informed me that the machine had locked up and needed to be power cycled.  I wasn't awake at the time.
<seb128> mdz: is that still ok to upload a crasher fix for gnome-system-tools (a double g_free call, Kamion said it was ok to upload yesterday but I just noticed that the upload got rejected)
<fabbione> Znarl: ping?
<fabbione> infinity: ok thanks
<infinity> But I think there is something goofy going on with the build queue DB as well...
<mdz> Riddell: right, but we don't install any of those by default (except perhaps in edubuntu? ogra?)
<infinity> Since vernadsky is definitely not building OOo anymore.
<infinity> Argh.
<Riddell> mdz: kubuntu installs gtk-qt by default
<Riddell> and kmplayer plugin
<ogra> mdz, nope, i wont touch gtk-qt in edubuntu even if my life depends on it
<mdz> Riddell: the patch looks correct but it seems equally valid to fix via dapper-updates
<mdz> Riddell: I haven't looked at kmplayer yet
<infinity> Oh, the buildqueue database is probably confused about vernadsky/OOo since it actually succeeded for once... After I'd uploaded a manual build.
<infinity> mdz: Good news, the bug is fixed1 :)
<mdz> infinity: eh?
<seb128> gtk-qt does weird stuff, we had bugs about volume sliders acting reversed due to it by example
<infinity> mdz: Okay, it's obviously not fixed, since we did nothing to fix it, but the autobuild of OOo on vernadsky actually completed this last time.  Bizarre.
<ogra> seb128, we also had bugs about the whole gnome desktop crashing with it installed
<mdz> Riddell: "(closing Malone #5346, #16469 and #16469)" ?
<Ubugtu> Malone bug 5346 in kaffeine "Kaffeine crashes konqueror when trying to play embedded movies" [Normal,Fix committed]  http://launchpad.net/bugs/5346
<Ubugtu> Malone bug 16469 in kdebase "konqueror crashes when accessing streams on spiegel.de" [Normal,Fix committed]  http://launchpad.net/bugs/16469
<Ubugtu> Malone bug 16469 in kdebase "konqueror crashes when accessing streams on spiegel.de" [Normal,Fix committed]  http://launchpad.net/bugs/16469
<Riddell> mdz: yes, kaffeine plugin is quite unstable, that's why we set it to use kmplayer as default plugin but we missed a few mimetypes that still need it set
<Riddell> obviously I'll remove the duplicate :)
<mdz> Riddell: so there is no third bug to look at?
<seb128> mdz: http://people.ubuntu.com/~seb128/gst.debdiff ... ok to upload?
<mdz> Riddell: in 5346 and 16469 we are working around kaffeine bugs by switching to kmplayer instead?
<Riddell> they are yes
<seb128> mdz: the code is http://pastebin.com/743768, the double g_free is previous obvious as you can notice :)
<crimsun> mdz: / pitti: thanks! (RE: alsa-utils)
<mdz> seb128: was just downloading the source ;-)
<mdz> seb128: yes, ok
<seb128> mdz: thank you
<mdz> Riddell: that seems like a fairly major change to make right now
<mdke> dholbach: yes, wasn't aware of that
<mdz> Riddell: the bugs seem to say that kaffeine is having problems only with some videos
<dholbach> mdke: if you drop that fix in, I'll do the upload asap
<mdke> dholbach: I'll do it now
<dholbach> mdke: merci beaucoup
<Riddell> looks like bug 35786 is the other one
<Ubugtu> Malone bug 35786 in kdebase "konqueror with kaffeine-xine plugin crashes on certain sites" [Normal,Fix committed]  http://launchpad.net/bugs/35786
<mdz> switching from one large code base to another so late makes me nervous
<Riddell> mdz: we already use kmplayer, this just adds some mimetypes that we missed
<fabbione> wouldn't kmplayer plugin require mplayer installed?
<Riddell> all the mimetypes have to be listed explicitly
<mdz> Riddell: how long ago did we switch for other types?
<Riddell> mdz: a couple of months at least
<mdz> fabbione: no, it is a separate package
<fabbione> ok
<mdz> I don't think it is even based on mplayer
<fabbione> i hope so
<Riddell> fabbione: we're using the xine backend
<mdz> looks like it is using xine
<fabbione> Riddell: ok
<mdz> Riddell: does this change which player is used for any of the example content?
<fabbione> mdz: you have about 8 minutes to catch breakfast
<mdz> fabbione: not hungry
<fabbione> mdz: ok
<Riddell> mdz: no, that all gets launched in a full player, this is just for webpages with embedded players
<mdz> fabbione: but thanks for the reminder ;-)
<mdz> do they really serve breakfast until 12 here?
<Riddell> full player is still kaffeine
<fabbione> mdz: eheh no problem
<highvoltage> mdz: where is 'here'? :)
<fabbione> mdz: 11:30 only on weekends and holidays.. otherwise 11
<mdz> highvoltage: the K+K Hotel George, or as I like to call it "home"
<highvoltage> ah, kk george, accordign to your IP :)
<infinity> fabbione: You sure do know your breakfast schedules. :)
<fabbione> infinity: you bet :)
<mdz> Riddell: can you check when that change was made please?
<pitti> mdz: it's a slow migration to become an European citizen, accept it :)
<fabbione> infinity: but just because i am a very slow starter in the morning
<fabbione> infinity: so i need to plan it properly
<Riddell> mdz:   * Added profilerc to define video player priority between kaffeine
<Riddell>     and kmplayer
<Riddell>  -- Anthony Mercatante <tonio@ubuntu.com>  Mon, 27 Mar 2006 00:30:30 +0000
<dholbach> mdz: ok to upload  http://daniel.holba.ch/ubuntu/gnome-power-manager.debdiff ?
<infinity> mdz: Tell me that you care so little about freetds (library for accessing Sybase and MSSQL servers) that I can push in a last-minute patch to fix date format handling...
<mdz> infinity: isn't that in universe?
<mdz> oh god it isn't
<infinity> mdz: No, it's always been in main.
<mdz> infinity: what build-deps on it?
<infinity> mdz: php5, at least.
<jdub> that
<pitti> mdz: and libgda2
<jdub> that's quite important for some php users
<mdz> jdub: yes, php5 is quite important for some php users
<mdke> dholbach: where do you see the error?
<mdz> infinity: do you have a diff?
<infinity> mdz: As history goes, vorlon long ago added a patch to do on-the-fly locale handling in ffreetds.  Which was great, but it also mangled date formats according to locale, which broke any number of expectations from using the library to, y'know, get dates from a SQL server.
<infinity> mdz: He just fed me a patch to fix that.
<infinity> mdz: Yeah, let me find the right browser window with the URL sitting in it.
<infinity> mdz: http://minbar.dodds.net/~vorlon/freetds-0.63-fixmylocale.diff
<mdke> dholbach: oh, i see it. scrollkeeper doesn't give me that error, odd
<infinity> mdz: (Obviously, that's the patch provided by vorlon, I can debdiff the Ubuntu source instead, but it'll come out pretty much identical.  We're in near version lockstep)
<janimo> jdub: hi, do you know if gtk 2.10 is going to be ready for gnome 2.16?
<dholbach> mdke: sudo scrollkeeper-rebuilddb
<jdub> janimo: that's the goal
<seb128> janimo: it'll probably
<mdz> infinity: woo, this has been in debian for a whole 5 days? :-P
<mdke> dholbach: odd, I don't see it, there seems to be an error in one of my scrollkeeper libs (failed to load external entity "/var/lib/scrollkeeper/(null)/scrollkeeper_cl.xml"), anyway, i've uploaded the fix, you are good to go
<dholbach> mdke: rock on
<rzr> hi
<mdz> infinity: looks non-trivial; any rationale for pushing it now rather than -updates?
<infinity> mdz: Yeah, I was going to hold off, but the rationale for pushing it now is so people don't end up with two different sets of SQL date results when using dapper or dapper-updates.
<infinity> mdz: Seems tacky to me to change that sort of thing post-release.
<infinity> mdz: But this is the "correct" way, matches upstream, and matches copious numbers of 3rd party applications that expect date formats to be in a certain Sybasish format.
<mdz> infinity: I understand the nl_langinfo bit, but what's with the other changes?
<infinity> The other half of the patch is to stop stomping on the user's chosen locale (the other mistake of vorlon's original patch)
<pitti> Kamion, mdz: the current live CDs have spare space again; is there anything that will make them bigger again? can I fill them with langpacks again?
<infinity> vorlon's original patch just took your environment and ran with it.  This properly checks the preferred local in /etc/freetds/locales.conf (as the library docs upstream claim it should), then falls back to environment if you have no preference.
<doko> mdz: would you consider to make the qt change in ia32-libs only, and delaying the qt-x11-free change until after the release? at least it fixes a crash for kubuntu-amd64 and makes scim work at all. of course we would need to make sure, that the qt-x11-free binary in ia32-libs-kde is built in a trusted environment (which could just be manual build on a buildd environment)
<mdz> pitti: how much space?
<pitti> mdz: about 20 MB on i386/ppc, 15 on amd64
<mdz> doko: what's the change? do you have a diff prepared?
<pitti> (that will still leave some 5 MB breathing room)
<infinity> doko: I can do the "fake" QT build if required.
<mdz> pitti: ok, so long as we have a buffer for, e.g., random icon updates later today
<pitti> mdz: I'll wait for Kamion's answer, too, to be sure (the last time I filled the CDs I wasn't aware of the pending ship-live addition)
<infinity> pitti: Spare space is suspsicious.   What fell off? :)
<infinity> (I'm pretty sure that spare space is actually spare, fwiw)
<pitti> infinity: that's what I wonder, too, and why I like to get Colin's opinion
<infinity> We had reserved it for example-content and the book and such, and those are all in now and smaller than expected.
<doko> mdz: http://people.ubuntu.com/~doko/ooo-amd64/
<mdz> pitti: Kamion is off today (UK bank holiday)
<doko> it's the qt change as posted, plus installation of the qt config files in /etc/qt3-32 in ia32-libs-kde
<dholbach> mdke: Could you look at my /query, thanks?
<infinity> pitti: Cheese rolling down the hill day!
<fabbione> sejong still idling
<infinity> Yeah.. And? :)
<fabbione> infinity: Oo.o. kthxbye :)
<infinity> Yeah, I'm fixing.
<fabbione> lovely
<infinity> The DB got itself wedged in a special way.
<infinity> Hence my earlier "where's cprov when I need him?" comment.
<fabbione> i didn't notice the comment
<fabbione> sorry
<Mithrandir> pitti: what's happening with translations done this weekend per jordi's request?  Friend's asking and hasn't seen new langpacks yet.
<mvo> mdz: is bug 45656 something for now? or rather for dapper-updates?
<Ubugtu> Malone bug 45656 in notification-daemon "Notification bubble shows sometimes wide, sometimes narrow" [Normal,Confirmed]  http://launchpad.net/bugs/45656
<mantas_> pitti, hehe, it seems I'm not alone - people are waiting for new langpacks... have you talked with mdz about regenerating language packs to match officially announced dapper translation deadline - 25th of May?
<mdz> mvo: what kinds of notifications are affected?
<mdz> mantas_: see the earlier discussion on this channel
<mdz> Mithrandir: ^^
<pitti> infinity, mdz: I phoned Colin, he's okay with it
<mvo> mdz: stuff from the notification-daemon (update-notifier, disk-full notification, rhythmbox)
<pitti> Mithrandir, mantas_: it's decided, we'll update the langpacks this evening
<Mithrandir> pitti: cool, thanks.
<mantas_> pitti, hehe, now you are hero in Lithuania ;)
<mdz> mvo: it seems entirely cosmetic from the examples in the bug
<mvo> mdz: it is, yes
<mdz> somewhere in Lithuania, work is quietly beginning on a statue shaped like pitti
<mdz> mvo: -updates then
<mvo> mdz: ok, targetet it for it, thanks
<impaque> hello, can you tell me with which CFLAGS is the majority of packages on kubuntu built with? i searched the net but couldn't find an answer. i'm not a gentoo ricer, i'm just curious. ;)
<mantas_> mdz, yea, we already have the Frank Zappa statue, so, I think with pitti statue would be less work ;)
<mdz> mvo: please add to DRR
<mdz> doko: how do these ia32-libs-kde changes affect the size of the package?
<Chipzz> impaque: should be in the buildlogs (you can find these on launchpad.net)
<doko> mdz: it's a plus of 1,5MB for ia32-libs-kde, which is unproblematic according to Riddell; didn't check myself.
<Riddell> plenty free space on kubuntu amd64 today
<mvo> mdz: done
<impaque> Chipzz: thanks
<infinity> fabbione: Okay, fixing build DB... If you run into cprov today, tell him he owes me a beer and a hooker for the pain I just went through.
<fabbione> infinity: ahahahah ok
<crimsun> mdz: Is http://librarian.launchpad.net/2969615/alsa-lib_1.0.10-2ubuntu5.debdiff acceptable for dapper? It fixes the root of the problem for a host of issues that pitti has had to work around.
<Kamion> thep: I'll need /var/log/syslog from the installer
<pitti> crimsun: it looks sane of course, but can we be 100% sure that it does not have any unintended side effects?
<crimsun> pitti: no location changes, but instead of using the buildd's directory, it uses /usr/share/alsa/, which is what we really want
<infinity> fabbione: Other than the dpkg status file, just how wide is the impact of this sparc memcpy bug?
<mdz> doko: ia32-libs-kde OK
<pitti> crimsun: right; I mean that this changes the behaviour of alsa in a way we don't want to
<fabbione> infinity: that seems to be the most evident breakage... there might be more hidden somewhere..
<infinity> fabbione: You do realise that the buildds have been running dapper kernels since sparc lit up in the DC.  I'm wondering just how broken the world may be because of it.
<mdz> crimsun: the only change is to configure with --datadir?
<fabbione> infinity: it affects only CPU < Sparc III
<fabbione> infinity: that's not the DC case
<thep> Kamion, OK. I didn't find the bug myself. I'll ask it from the reporter.
<infinity> fabbione: Oh, phew.
<crimsun> pitti: it doesn't change anything beyond saying "look in /usr/share/alsa and not where the buildd built". There are no other changes. All the Debian bugs closed verify that.
<thep> Kamion, actully, I've asked him to file a bug.
<fabbione> infinity: if the breakage was wider, i would have push the big fat red alert button a few days back
<crimsun> mdz: yes, that is the sole change
<infinity> fabbione: Good to know; thanks.
<fabbione> infinity: no problem
<pitti> crimsun: right, that's what I understood. What I meant is: it will certainly change behaviour; will it conflict with the asoundconf workarounds we did?
<pitti> crimsun: (don't get me wrong, I'd love to see that fix, but I want to make sure we don't break anything)
<crimsun> pitti: it will not conflict with any of the workarounds; I've tested locally to see that. It actually covers the last case we didn't, which is bug #43146.
<Ubugtu> Malone bug 43146 in alsa-lib "gnome-sound-properties generates broken alsa conf" [Normal,In progress]  http://launchpad.net/bugs/43146
<mdz> crimsun: what effect does it have?
<pitti> crimsun: great
<mdz> crimsun: it seems likely to introduce a lot of hardware-specific behavioral changes
<sivang> re all
<mdz> if all of the stuff in /usr/share/alsa is currently being ignored
<crimsun> mdz: David Ramsden's post in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369302 explains the current issue
<Ubugtu> Debian bug 369302 in libasound2 "Subject: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL default" [Important,Open]  
<mdz> doko: regarding bug 41592, that request hasn't been processed yet; isn't the existing version in the archive correct?
<Ubugtu> Malone bug 41592 in vnc4 "UVF Exception: vnc4 (now sync request)" [Normal,Needs info]  http://launchpad.net/bugs/41592
<pitti> crimsun: ah, this explains a lot; I might also fix the Logitech headset breakage I encountered :)
<Kamion> pitti: FWIW, if you're looking at filling up derivatives too, I don't know offhand how much of ship-live they each have
<pitti> Kamion: I'll ask ogra and Riddell before touching them
* Kamion nods
* pitti -> lunch
<doko> mdz: bddebian did overwrite the version built using xorg using the version build with xfree86
<ogra> Kamion, i didnt add anything to ship-live beyond your initial packagelist
<doko> repackaging the xorg based version.
<mdz> doko: already?
<Kamion> ogra: I added build-essential/fakeroot/linux-headers later, after my initial commit
<dholbach> mdz: if you find some tiny bit of time, can you look at  http://daniel.holba.ch/ubuntu/gnome-power-manager.debdiff  and the updated patch on bug 46440 or do you want me to mail them to you?
<Ubugtu> Malone bug 46440 in scrollkeeper "There is no Croatian translation of desktopguide" [Normal,Fix committed]  http://launchpad.net/bugs/46440
<mdz> doko: I thought he was proposing to overwrite our version via a sync, but we had not done it yet
<ogra> Kamion, which i didnt merge
<mdz> dholbach: g-p-m OK
<dholbach> mdz: merci
<ogra> dholbach, hal dep added ? 
<mdz> ogra: that seems perfectly logical
<dholbach> ogra: kinnison asked me to
<doko> mdz: no, meant to overwrite the version, which was in the archive before the conversion to xorg (overwriting the debian version with a very old version of xfree86)
<seb128> ogra: there was a bug about it
<mdz> I don't think it works without hal
<ogra> dholbach, mdz, just wanted to make sure its not forgotten
<ogra> seb128, yep
<dholbach> ogra: ah right, yes - added it
<ogra> mdz, it had no hal dep
<ogra> mdz, as seb128 said
<mdz> ogra: the patch that dholbach just referred to added one
<dholbach> seb128, ogra: does anybody of you know the bug number? i couldn't find it
<seb128> ogra: the update add the Depends now ...
<mdz> it sounded like you were questioning whether that was correct
<seb128> dholbach: sec
<ogra> mdz, nope, just wanted to make sure its in (havent seen the patch)
<doko> infinity: qt-x11-free_3.3.6-1ubuntu5* at http://people.ubuntu.com/~doko/ooo-amd64/
<mdz> ogra: grumblegrumble
<mdz> dholbach: what is po/fake.po?
<dholbach> mdz: the build needs a something.po file to generate a template for that language code
<dholbach> mdz: so I added an empty one, so it's happy.
<mdz> dholbach: it's not empty though; it's huge :-)
<dholbach> mdz: it has msgstr "" - that's what I call "empty" :)
<mdz> dholbach: seems simpler to just create .po files, rather than making these symlinks
<mdz> dholbach: any reason not to do it that way?
<dholbach> mdz: that would have made the diff even bigger :)
<dholbach> think of it as my way of trying to please you :-)
<mdz> dholbach: yes, but with no code changes it's obviously correct :-)
<seb128> dholbach: bug ##45536
<seb128> dholbach: bug #45536
<Ubugtu> Malone bug 45536 in gnome-power-manager "Shutdown, but logoff" [Normal,Fix released]  http://launchpad.net/bugs/45536
<dholbach> seb128: you rock - thanks
<seb128> np
* dholbach closes it
<dholbach> mdz: do you want me to replace all the particular translations and simplify debian/rules or just go with it?
<mdz> dholbach: simplifying makes mdz happy
<dholbach> mdz: Ok, that's all I want.
<seb128> lunch time, bbl
<mdz> dholbach: that patch, minus the debian/rules change and fake.po, and plus the various .po files, is OK to upload
<tepsipakki> is it possible to disable the hibernation option from logout-prompt?
<dholbach> mdz: rock on
<Kamion> mvo: er. so. have we signed the distribution agreement with VMware for these player packages?
<Kamion> mvo: if so, that information should be in debian/copyright
<mdz> tepsipakki: /etc/default/acpi-support, and please ask in #ubuntu next time
<mvo> Kamion: mdy is the person responsible for this, I was at a conference call with them and they said it was ok. but mdy will know for certain, I will mail him
<Kamion> mvo: are VMware aware that an arbitrary number of Ubuntu mirrors will probably mirror this if we stick it in multiverse? (i.e. it won't be just us distributing it, legally speaking)
<Kamion> I don't want our mirrors to get into trouble or to have to apply complicated rsync restrictions
<mvo> Kamion: we talked about this and they where aware and ok with this. but I have nothing written, just the info from the conference-call
<mvo> Kamion: I'm happy to wait for mdy on this, I totally understand your position
<tepsipakki> mdz: ok, thanks...
<Kamion> I understand we need to move quickly if we want to get this into dapper
<mvo> Kamion: I send him a mail and will text him and ask (politely) to look into his mail (if I can find his mobile number)
<Kamion> ta
<thep> Kamion, I got the syslog. It said:
<thep> May 27 02:14:59 debconf: Setting debconf/language to th_TH:th
<thep> May 27 02:14:59 kbd-chooser[2972] : INFO: kbd_chooser: setting keymap th-tis
<thep> May 27 02:14:59 kbd-chooser-apply[2978] : ERROR **: :unknown charset tis-620 - ignoring charset request
<Kamion> thep: in a bug report on kbd-chooser, please - I'm not actually working today (contrary to appearances)
<Kamion> unfortunately it is unlikely that we'll be able to fix that for dapper now, I'm afraid
<Kamion> because it would require a debian-installer rebuild
<thep> Kamion, even though it fails to install correctly?
<Riddell> mdz: did you make a decision on those gtk-qt and kmplayer mimetype patches?
<thep> Kamion, regarding the bug report, yes, I'll ask him to file the bug, for sure.
<Riddell> pitti: what's going into ship-live?
<Kamion> thep: I realise it's a serious problem, but it will take some time to fix and it's just been discovered too late
<infinity> doko: While I'm looking at it anyway, should ia32-libs be freshened?  The packages haven't been updated since March 30..
<doko> infinity: will do it
<infinity> doko: Kay, if you're going to do it, should I leave the "fix ia64 without breaking amd64" thing to you too, or do you want me to do that? :)
<infinity> doko: I suspect that just wrapping the second half of preinst in an if(amd64) guard should do the trick.  More or less.
<infinity> doko: Completely untested, of course. :)
<pitti> Riddell: nothing from my side :) from your's?
<doko> infinity: I'm currently installing a fresh breezy chroot, and want to upgrade to dapper; unfortunately that's a 1Mbit line ...
<infinity> doko: I haven't done an upgrade test yet, but just deboostrapping dapper and installing ia32-libs exposes the first bug (which I introduced when fixing amd64, my fault)
<infinity> doko: But fixing that might still mean upgrades are broken, yeah.  I can test in the DC.  Plenty of bandwidth to spare.
<doko> infinity: testing in the DC is definitely easier
<infinity> Even easier with all these chroot tarballs lying around, so I don't have to debootstrap. :)
<thep_> Kamion, OK. I respect all maintainer's decisions.
<infinity> Oh, except I don't have one for breezy-updates... Weird.
* infinity kicks the librarian to find that.
<Riddell> pitti: ok, you were talking with Kamion about filling up derivatives though
<pitti> Riddell: I could add 10 MB to the amd64 kubuntu one if you want me to; the other ones are full/oversized anyway
<Riddell> pitti: with what?
<pitti> Riddell: language packs
<carlos> pitti: could you remind me which package contains the patch that adds gettext support to .desktop files ?
<carlos> for GNOME
<pitti> crimsun: has there been an agreement with mdz about the alsa-utils fix? (my gut says dapper-updates material)
<Riddell> pitti: I was waiting for doko's ia32 package before filling up amd64
* carlos guess that KDE and XFCE were updated too to support that...
<pitti> carlos: glib2.0 and gnome-desktop
<carlos> pitti: ok, thanks
<pitti> Riddell: right, I'll leave it alone for now
<pitti> ogra: ping
<ogra> pitti, pong
<doko> Riddell: infinity is currently preparing the qt-x11-free build by hand
<pitti> ogra: edubuntu-live has plenty of space left, too; anything planned for it?
<carlos> pitti: I got an email saying that the icons in the gnome panel were missing translations
<ogra> pitti, langpacks ? 
<pitti> ogra: :)
<ogra> i have currently only de,fr,es,en
<pitti> ogra: do you want to care for filling or shall I?
<ogra> pitti, go ahead if you dont break it and have nothing else to do
<ogra> else i'll care
<Riddell> carlos: I'm told the koffice translations in rosetta are from koffice 1.4, the koffice package doesn't seem to be generating a .pot file, can i give you one to upload?
<pitti> ogra: I have always stuff to do, but I'm fine with doing it; I just want to make sure to not get into your way if you want to add stuff 
<carlos> Riddell: sure
<carlos> Riddell: anyway, the problem there is also that the 1.5 translations are in universe
<carlos> and I need to do a manual upload, do you remember?
<carlos> Riddell: I answered the bug report
<carlos> already
<Riddell> carlos: yep, can you do that too?
<carlos> sure
<carlos> Riddell: what about k3b?
<ogra> pitti, only thing i have left with edubuntu is fiddling with the cursor theme, i wont change anything but edubuntu-artwork
<carlos> should I do another upload for that one?
<pitti> ogra: is a spare space of 5 MB fine for you?
<ogra> yep, absolutely
<ogra> thats a big buffer ;)
<Riddell> carlos: I'm not sure what's currently in k3b but it wants to be k3b-i18n 0.12.10
<carlos> Riddell: well, my question is more 'did you upload a new release of k3b' recently?
<carlos> that's less than 2 months ago
<Riddell> carlos: oh, k3b and k3b-i18n are out of sync
<Riddell> k3b is 0.12.14 from Mar 15th
<infinity> dholbach: When do I get to whine about the Ubuntu panel logo changing to something completely hideous?
<carlos> Riddell: do you need to upload a new version?
<infinity> dholbach: The other one (which is still used for alacarte) looked much better.
<carlos> Riddell: if it's too late, you could provide me the tarball with translations and will do the upload into Rosetta by hand
<carlos> Riddell: I need to do it anyway by hand....
<carlos> seb128: I have a test request for you, do you have time now?
<Riddell> carlos: please import these by hand http://surfnet.dl.sourceforge.net/sourceforge/k3b/k3b-i18n-0.12.14.tar.bz2
<Mithrandir> why is there only a russian "about ubuntu" in example-content?
<Riddell> carlos: and these .pots for koffice http://kubuntu.org/~jriddell/tmp/koffice-po.tar.gz
<Riddell> carlos: and all the .pos from koffice-i18n-xx
<carlos> Riddell: ok. Take into account that those will take one month to appear in Dapper (with next language pack update)
<carlos> Riddell: ok
<seb128> carlos: pong
<carlos> seb128: do you have the Evolution launcher on your panel?
<seb128> carlos: yeah, and the description is not translated and I don't know why
<carlos> so it's a know bug
<carlos> ok
<seb128> yep
<seb128> but I've no idea of what is causing the issue
<carlos> I got complains about Rosetta / language packs not working
<seb128> I'm sorry about it :/
<carlos> dude, don't worry ;-)
<seb128> :)
<pitti> carlos: will anything drastically change in today's langpacks? like 3 MB of new translations due to some fixes or so?
<carlos> just noting you the bug, because the translation is part of the .desktop files and thus, language packs are not involved...
<Riddell> language packs take precedence over .desktop translations in ubuntu 
<Riddell> as I remember
<seb128> yep, they do
<carlos> pitti: well, today's snapshot uses yesterday translations, I'm not sure how many extra translations would we get
<pitti> carlos: you spoke about German KDE fixes?
<carlos> pitti: tomorrow's langpacks (with today data) will get koffice translations, k3b translations and fix some other German KDE translations to stop the fork we had
<pitti> carlos: we have to take today's
<carlos> go ahed
<carlos> ahead
<carlos> I think we already agreed on that...
<pitti> ok, -updates will get the rest
<Riddell> can't we make a new snapshot in a couple of hours with those KDE changes?
<carlos> Riddell: not really, OO.org is being imported atm
<carlos> and thus will block those translations to be imported
* infinity coughs.
<carlos> and we still use a mirror so we would need to update the mirror to generate a new snapshot
<infinity> Whatever you do, don't blame me.
<carlos> infinity: I'm not blaming you ;-)
<carlos> Riddell: it's a bit difficult to get all things in place in time for today
<doko> carlos: we should add a flag, when we want to import translations, and when not.
<infinity> carlos: Well, I am the one who's uploaded OOo like twelve times in the last week and stuffed up rosetta every time. :)
<carlos> doko: we will talk about it next month
<Riddell> carlos: ok, I'll just keep saying nice things to stop a riot on kde-i18n :)
<carlos> doko: I guess you already know I will be in Paris (from Wednesday to Friday)
<doko> carlos: didn't know. fine!
<Riddell> carlos: at the conference?
<carlos> Riddell: Rosetta will get the fixed strings today or tomorrow
<carlos> Riddell: so translators will work with upstream translations in place
<carlos> it's just dapper which will have some differences from upstream until next update
<carlos> Riddell: yes
<pitti> ogra: which are your most prefered languages? do you have a list?
<ogra> not really
<ogra> we have many users in brazil and chile
<ogra> and in asia, but dont ask be for langs there
<ogra> s/be7me/
<pitti> ogra: pt is #6 on the top 11 anyway, so it'll make it on all CDs
<Riddell> hmm, no mdz around to review patches
<ogra> pitti, not on the edubuntu install CD :/
<ogra> Riddell, after lunch :)
<pitti> ogra: right, the install CDs are almost full, I only change the live CD now
<ogra> yep
<carlos> seb128: I think I found the problem
<ogra> the install CD is full to the edge
<carlos> seb128: do you have time?
<carlos> seb128: Hmm, I need to have lunch now, but I will try to send a bug report with all information when I'm back
<pitti> EdgyEft: nice nick :)
<AlinuxOS> pitti, hello ;)
<pitti> hi AlinuxOS 
<ogra> pitti, thats Seveas' release specific logbot :) 
<sivang> what does EdgyEft does? :)
* sivang arghs at yet another patch attempt for malone #39482
<Ubugtu> Malone bug 39482 in nautilus "nautilus tries to move when dragging and dropping from read-only folders, instead of copying" [Normal,Confirmed]  http://launchpad.net/bugs/39482
<Mithrandir> dholbach: I'm wondering if I've found a bug in oo-about-these-files.odt.  Spell checking seems broken.
<seb128> carlos: pong
<seb128> carlos: sorry I just finished lunch break, I'm back to work now :)
<seb128> carlos: where is the pb?
<sivang> man, nautlilus takes time to build, not like evo, but long enough :p
<sivang> seb128: basically, loggin in and out is enough for use a new installed nautilus right?
<seb128> not true, nautilus is pretty fast to build
<seb128> running "make" is enough to try that bug
<seb128> and gnome-session-remove nautilus then src/nautilus
<sivang> k, thanks
* sivang does
<dholbach> Mithrandir: spell checking used to work fine in that file for me
<Mithrandir> dholbach: doesn't for me, i386 dvd oem-config install.
<dholbach> Mithrandir: missing *spell-<locale>?
<dholbach> Mithrandir: and it works for other files?
<Mithrandir> dholbach: works fine in a blank document.
<infinity> doko: Argh.  Okay, the ia32-libs fix is easy.  I just need to move one line 4 lines up in the preinst.
<infinity> doko: Want me to freshen it while I'm at it and just upload?
<dholbach> Mithrandir: you opened it in a location where you can write on?
<infinity> doko: Right, I'll just do it. ;)
<Mithrandir> dholbach: yes.
<tseng> hi Mithrandir dholbach 
<Mithrandir> hiya tseng 
<doko> infinity: I don't have any more changes for ia32-libs
<dholbach> Mithrandir: hum, that works for me. (not if I open from /usr/share/example-content, but copied over to ~ it works fine)
<infinity> doko: Alright, then I'll just do the ia64 fix and the refresh.
<infinity> doko: Same trick as OOo-amd64, I assume?  (BUILD=0 fetch-and-build)?
<pitti> seb128: what was the outcome of the poppler/tetex-bin unpatch/rebuild discussion?
<seb128> pitti: none
<doko> infinity: yes
<infinity> doko: Rock.  Will do, then.
<Mithrandir> dholbach: completely clean install?
<infinity> doko: And I'll get that QT build for you in a bit too.
<dholbach> Mithrandir: I tested it on all the installs I did.
<pitti> bah, ENOMDZ
<pitti> seb128: I'd love to at least do a no-change upload of tetex-bin to rebuild against the current poppler
<infinity> pitti: He's lunching.  What do you need?
<pitti> infinity: see above, to fix bug 42075
<Ubugtu> Malone bug 42075 in tetex-base "includegraphics fails" [Normal,Confirmed]  http://launchpad.net/bugs/42075
<seb128> pitti: I asked that to mdz, but he didn't reply
<infinity> pitti: You don't need approval to do those poppler uploads.  No source changes, and the bug obviously needs to be fixed.
<infinity> seb128: ^^^
<infinity> Get those rdeps rebuilt, like, yesterday.
<pitti> infinity: poppler is fine, we need a rebuild of the rdepends (only tetex-bin is left AFAIUI)
<infinity> PLEASE.
<seb128> ok, so just do a tetex-bin "rebuild with new poppler" one
* pitti does
<infinity> pitti: Yes, I meant "poppler-related"
<jsgotangco> hi guys
<seb128> hey jsgotangco
<Mithrandir> dholbach: hmm.
<ogra> pitti, wow, are you sure that will fit .... looks like a very long list of langs to me
<jsgotangco> yeah
<pitti> ogra: unless my script lied, it should
<_ion> Go, USA! http://www.timesonline.co.uk/article/0,,2089-2200170_1,00.html
<infinity> pitti: "changed api"?
<infinity> pitti: Surely, you meant "abi"...
<pitti> infinity: erm, yes, sorry
<infinity> pitti: Anyhow, are we positive that's the only upload required?
<pitti> infinity: I'll check the other ones in a minute
<infinity> pitti: Thanks, dude.
<mvo_> pitti: have you seen my last comment for bug #46338 ?
<Ubugtu> Malone bug 46338 in update-manager "language-support-en not installed any more" [Normal,Needs info]  http://launchpad.net/bugs/46338
<jsgotangco> _ion: topic
<sivang> does anybody know posible return values for gnome_vfs_uri_get_scheme() ? gnome reference seems a bit out of date..
<sivang> (one value is 'file', I wonder if there is a 'directory' one as well)
<pitti> infinity: confirmed
<_ion> jsgotangco: Oh, sorry, wrong channel.
<ogra> hrm, ia32-libs is really broken here ...
<ogra> is anybody working on bug #46285 ? (doko, infinity or Mithrandir perhaps ?)
<Ubugtu> Malone bug 46285 in ia32-libs "pre-installation of the package is trying overwrite '/usr/bin/ldd' with  `/usr/bin/ldd.amd64'" [Normal,Needs info]  http://launchpad.net/bugs/46285
<ogra> it breaks upgrades here completely
<pitti> mvo_: oh, I see
<infinity> ogra: It breaks on upgrade from dapper->dapper, you mean?  It works fine on breezy->dapper.
<pitti> mvo_: I can do that change, no problem
<infinity> ogra: But I think I can fix your broken dapper->dapper case at the same time, so no worries.
<pitti> mvo_: hm, that's certainly an issue for other language-support-* as well?
<ogra> infinity, yes, dapper (about 4 weeks outdated) -> dapper
<mvo_> pitti: yes, I'm pretty sure it is
<mvo_> pitti: if it is trivial to fix that would be good, if not, well 
<pitti> mvo_: sure, I can fix it
<mvo_> then we need  a different strategy
<pitti> mvo_: it just doesn't look very nice
<mvo_> pitti: the guy from the heise forum mailed me
<pitti> and I don't understand why it's removed in the first place
<infinity> ogra: /msg me the output of "dpkg -S /usr/bin/ldd" from that box.
<infinity> ogra: If you haven't already fixed it, that is.
<ogra> gah
<siretart> ogra: the problem is that there shouldn't be the /usr/bin/ldd diversion. remove it by hand and upgrades work again
<mvo_> pitti: but it is *very* mysterious, apprently the tool just vanishes, no excpetion, nothing
<ogra> infinity, 5 seconds to late
<infinity> Oh well, I think I know what it was anyway.
<ogra> siretart, yes, i know
<infinity> I'll fix it and test the fix in a bit.
<siretart> ogra: it is very unclear for me where this diversion come from
* mvo_ remembers the icon-theme-reload bug from hoary->breezy with horror
<pitti> mvo_: hm, that would mean the upgrade removes u-desktop, too?
<infinity> siretart: It came from an old broken version.
<siretart> ah,ok
<infinity> siretart: Easy enough to solve, I just need to know where all the failure cases are. :)
<mvo_> pitti: no, it always tries to ensure that u-d is installed (even when the dist-upgrade wants to remove it)
<siretart> ah, great
* ogra wonders if the darn ugly buttonish border around the distributor logo is supposed to be there
<tseng> ogra: it is.
<ogra> argh
<tseng> switch to a real theme
<ogra> thats horrible
<tseng> and it goes away
<pitti> mvo_: hm, but u-m can't be installed without l-s-en...
<ogra> tseng, well, i usually use edubuntu anyway, where we use a more beautiful distributor logo ;)
<tseng> :)
<ogra> just testing a ubuntu dapper upgrade
<tseng> other icon themes use the old distributor logo
<ogra> tseng, yep its in hicolor
<mvo_> pitti: language-support-en is not a dependency on my system of ubuntu-desktop (or am I missing something?) (only ubuntu-live)
<ogra> but i wonder who decided to make it *that* ugly ... even the 3d version was better
<mdz> Riddell: I asked you to confirm when the kmplayer change was made originally, and I don't remember seeing your reply
<pitti> mvo_: oh, oops, right
<mdz> Riddell: I'm OK with the change if kmplayer is very well tested in this context
<carlos> seb128: hi
<carlos> seb128: around?
<seb128> wb carlos
<seb128> yep
<carlos> so
<mdz> Riddell: gtk-qt is fine
<Riddell> mdz:   * Added profilerc to define video player priority between kaffeine
<Riddell>     and kmplayer
<Riddell>  -- Anthony Mercatante <tonio@ubuntu.com>  Mon, 27 Mar 2006 00:30:30 +0000
<carlos> seb128: I saw that gaim has the same problem
<carlos> seb128: and got the .po file from launchpad
<carlos> and gaim's .po file lacks the .desktop msgid
<Riddell> mdz: kmplayer is well tested
<mdz> Riddell: both OK then
<Riddell> mdz: one last patch, adding more translations to the .desktop files in kubuntu-docs http://kubuntu.org/~jriddell/tmp/kubuntu-docs.diff
<carlos> seb128: I wonder if the code that searchs the translation using gettext is falling back to the .desktop content if it gets the empty string....
<seb128> carlos: no it doesn't
<carlos> that's the problem then...
<seb128> carlos: the issue is that the Name= is to the template but not the description then?
<carlos> seb128: I'm going to check evolution now
<seb128> carlos: could you fix the evolution template to list that string or do I need a package upload for that?
<carlos> seb128: but gaim lacks all
<seb128> carlos: I just checked
<seb128> Name= is listed
<seb128> but the Comments= is not
<carlos> how's that possible?
<carlos> seb128: send me a fixed .pot file and I will upload it by hand
<seb128> carlos: the .desktop is a custom one, we use the same name as the official one but a different description
<mdz> Riddell: fine
<seb128> carlos: ok, doing that now
<mdz> pretty soon though we are going to need to stop uploading
<carlos> seb128: oh, I see
<Riddell> thanks mdz, that should be the last uploads from me
<carlos> seb128: anyway, the .pot regeneration should fix that
<carlos> that's the idea of regenerate all .pot files...
<mdz> *** if anyone has an approved upload which hasn't been uploaded yet, speak up
<mdz> (apart from Riddell)
<seb128> carlos: the .pot is generated, debian/evolution-mail.desktop is just not listed by po/POTFILES.in in that case
<infinity> mdz: I need to upload ia32-libs one more time to fix another upgrade/diversion bug, and to refresh the stale debs in the source package.
<infinity> mdz: I think that's the last thing on my list.
<carlos> seb128: that's a bug then... could you fix it for edgy?
<Riddell> infinity, doko: what's the status of ia32-libs-kde and qt?
<infinity> Riddell: The hacked QT is building on a buildd right now.
<seb128> carlos: I'll fix it to dapper-updates too yep
<carlos> seb128: I guess gaim has the same problem too, right?
<mdz> Riddell: you have kubuntu items on DapperReleaseRadar still; are those done now?
<seb128> carlos: I didn't look at it yet but that's likely, I'll fix it too
<carlos> seb128: about the code that looks for gettext translations
<carlos> seb128: is the spec stating that we are not going to fallback to the ones inside the .desktop files?
<mdz> dholbach: have you been able to reach mark regarding the icons?
<Riddell> mdz: yes, I'll edit
<Riddell> (yes, they are)
<seb128> carlos: we do fallback, but I think that's the same call asking for Name and Description of the .desktop
<seb128> carlos: we fallback if Name is not translated, but I don't think the case one was translated by gettext and not the other get considered
<seb128> carlos: that's sort of a corner case
<seb128> carlos: http://people.ubuntu.com/~seb128/evolution-2.6.pot
<seb128> carlos: could you upload it to rosetta now?
<carlos> seb128: gaim is not getting name nor description translations for Spanish (and I guess any other language as we lack those strings)
<carlos> seb128: but the .desktop file has the translations and I get them in English
<seb128> carlos: because the Name translation is found to the .mo
<seb128> carlos: and I don't think the code consider the case were Name and Description come from different code path
<carlos> seb128: yes, I'm going to upload it, but until OO.org is done, it will not appear...
<RicardoPerez> hi
<seb128> carlos: if the .mo has no Name,Description it uses the .desktop
<seb128> carlos: we are in the corner case where Name should come from gettext and Description from the .desktop
<carlos> seb128: no, gaim doesn't have the Name inside the .mo file
<carlos> seb128: that's evolution
<mdz> pitti: status of final langpacks?
<pitti> mdz: currently importing on rookery
<pitti> ETA 1 hour, plus some time for testing
<infinity> doko: chinstrap:~/adconrad/qt-hacked/
* infinity goes to finish up ia32-libs.
<doko> infinity: thanks
<carlos> doko: did you see my question about OO.org language packs ?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Release preparation in progress: https://wiki.ubuntu.com/DapperReleaseRadar | Uploads with prior approval only
<jdub> sabdfl: regarding bug #46801, this icon was never intended for us as a button unto itself - in fact, it's often rendered inside a small button, so it looks bizaare.
<Ubugtu> Malone bug 46801 in gedit "Bad close icon" [Unknown,Confirmed]  http://launchpad.net/bugs/46801
<jdub> s/us/use/
<doko> carlos: when?
<carlos> doko: two or three hours ago
<carlos> doko: anyway, I can ask again ;-) Were you able to use the Rosetta's .po files I sent you ?
<mdz> jdub: yes, that icon is terrible
<pitti> mdz: wrt bug 46338, ok if I update l-support-* to have the alternative ... | openoffice.org2-l10n-XX dependency?
<Ubugtu> Malone bug 46338 in update-manager "language-support-en not installed any more" [Normal,Needs info]  http://launchpad.net/bugs/46338
<pitti> mdz: it's a hack, but a safe one, and we probably won't be able to fix the actual bug now (according to mvo)
<mdz> pitti: yes
<ogra> jdub, no comments on the distributor icon ? 
<doko> carlos: sorry, don't see any mail from you; nor did I get .po files
<carlos> hmmm
<carlos> that's bad...
<carlos> doko: do we have time to do an upload before release?
<mdz> pitti: did you talk to Colin about getting final ubiquity translations from rosetta?
<pitti> mdz: no, what would be my job for that?
<mdz> pitti: only that you happened to speak to him earlier
<pitti> mdz: he already pulls translations from rosetta regularly AFAICS
<mdz> pitti: yes, but we need one more
<doko> carlos: sure; these are translations only. so if mdz agrees ... where can I find the translations?
<mdz> or at least it would be nice
<mdz> jordi did ask for installer translations on friday
<pitti> mdz: oh, I see; he told me that he is preparing an upload anyway
<jdub> ogra: there's a bug already filed about that one. i'm tip-toeing over this minefield. :-)
<pitti> mdz: I'm currently testing the fix for bug 47073, maybe Kamion wants to include it
<Ubugtu> Malone bug 47073 in ubiquity "does not offer to use physical drive when LVM partitions are present" [Normal,Unconfirmed]  http://launchpad.net/bugs/47073
<pitti> mdz: I'll speak to him
<ogra> jdub, did anybody notice that "about ubuntu" and "about gnome" both have different versions of the distributor logo in the menu entries ?
<seb128> ogra: ubuntu has an ubuntu logo, GNOME a GNOME logo
<ogra> jdub, hicolor has the flat variant replacing the icon for the gnome entry, human has the new one showing up in about ubuntu
<ogra> seb128, not here on my freshly upgraded system
<doko> carlos: are translations from packages, where the potfiles are desktop files, not imported to rosetta?
<Who_> dholbach: Mark suggested one of the art team pop in to talk about theme packaging...
<seb128> ogra: you have a GNOME foot for Ubuntu?
<ogra> seb128, nope i have a flat ubuntu logo for gnome and a "buttonized" one for about ubuntu
<carlos> doko: if the .desktop files are not using .pot templates to do translations, no we don't import them
<jdub> weird
<carlos> doko: ooo-build is using .pot/.po files
<carlos> but you asked me to block those 
<ogra> i think thats caused by having the flat one in hicolor
<carlos> are we using them now?
<seb128> ogra: what theme do you use?
* j^ stares at "reading printer database..." for over 5 minutes now
<ogra> seb128, human (it wasnt changed during upgrade)
<seb128> ogra: gnome uses gnome-logo-icon-transparent, that's weird to have an Ubuntu logo for that one
<z_diver> Who_: Hi, are you going to stick around and see if you can locate Daniel?
<ogra> seb128, yep
<ogra> thats why i mention it here
<seb128> ogra: what version of ubuntu-artwork do you have?
<seb128> ogra: I don't have that on my box, nor on my laptop when I did installations on it
<carlos> doko: I think the problem is that I sent the tarball by email... I need to regenerate the tarball with the .po files
<mdz> I get the GNOME foot for GNOME, and the horrible buttonlike Ubuntu logo for Ubuntu
<carlos> doko: let me prepare it and I will send you the URL
<ogra> seb128, 27
<Who_> z_diver: yea, for half an hour
<seb128> mdz: same for me
<carlos> doko: will Esperanto and Kurdish work? those are new languages
<jdub> i switched to tango, so i get a normal ubuntu logo ;)
<doko> carlos: maybe emails for some size are not accepted in the data center? elmo?
<ogra> mdke, seb128, but i just noticed there are some packages missing, due to the ia32 upgrade bug apparently let me run another dist-upgrade
<seb128> $ dpkg -L ubuntu-artwork | grep transparent
<seb128> $
<mantas_> pitti, sorry for disturbing, but it would be nice to know how many hours are left until you will start generating of new langpacks ?
<carlos> doko: well, those are huge
<dholbach> Who_: theme packaging as in moving stuff into the appropriate directories?
<z_diver> Who_: OK, well I'm going to be taking off.  I'll check back when I can.  Feel free to email me if you guys want me to test anythign.
<carlos> doko: so it was my fault
<ogra> s/ia32/ia32-libs
<seb128> ogra: no gnome-logo-icon-transparent shipped by ubuntu-artwork
<doko> carlos: kurdish is already in
<carlos> doko: I should not send emails bigger than 2-5 MB
<doko> 
<carlos> doko: ok
<pitti> mantas_: they are already building on people.ubuntu.com; I'll broadcast a call for testing when they are done
<seb128> mantas_: I think they are being generated already
<ogra> seb128, wait, let me pull the missing packages ... 
<doko> carlos: could you just put the tarball at some place?
<Who_> dholbach: I think mark just wanted one of us around to be quizzed in case you were unsure about anything
<mantas_> Hehe, Lithuanian XFCE translation isn't complete, so, I told to XFCE translators, that they have few hours ... ;)
<ogra> if NM gets my network up again :(
<dholbach> Who_: no, the clue about all the stuff in one directory helped - thanks. I'll fix with next upload.
<z_diver> dholbach: Do you know what caused the flat dirctories.?
<jdub> dholbach: might be good to change their default background layout to zoom
<dholbach> z_diver: yes
<seb128> mantas_: translations are never wasted anyway, you will get language-pack update to dapper-updates too
<dholbach> jdub: i'll do that
<ogra> grmbl... no NM for me anymore *cry*
<carlos> doko: yes, that's what I'm going to do
<mantas_> seb128, I know, but DVD iso images aren't regenerated, so, people, who don't have internet connection will use translations, which were at release time
<carlos> doko: I'm getting new uploads to use latest information
<seb128> mantas_: that is right too
<carlos> s/information/translations/
<Who_> dholbach: well if you have any questions I'll be around - did you get the LegacyHuman package?
<z_diver> dholbach: good.  I'll be available to test a little later today.  Thanks for everything.
<dholbach> Who_: no didn't get the package - hope it's not big - everybody has grey hair about cd size already
<dholbach> z_diver: cool
<Riddell> ogra: why no NM?
<ogra> Riddell, dunno, doesnt work after my last upgrade
<Who_> it's 6k :)
<Who_> dholbach: should be in your inbox now (6k)
<ogra> dholbach, you'll get used to the grey hair, belive me :)
<dholbach> Who_: thanks
<dholbach> ogra: yeah, in twenty years, but not now :)
<ogra> dholbach, haha, wanna care for edubuntu CDs for 2 weeks ? then you are prepared for the "in twenty years" case ;)
<dholbach> ogra: no, trust me...
<pkern> Is there any documentation how to activate suspend on a powerpc machine on Dapper?
<pkern> I did not find any, and all the ways that state to activate it are silent about the fact that this is "not for powerpc"(tm).
<ogra> pkern, works here out of the box (G4 ibook)
<pitti> pkern: argh, it seems that a recent gnome-power-manager broke that; in earlier versions it just worked
<pkern> ogra: I just made a clean install and it did not work. G4 ibook too.
<Who_> dholbach: that 6k size is only if the gtk2-engines-clearlooks package is on the CD already - which I assume it is...
<pitti> ogra: not here any more
<ogra> oh
<dholbach> Who_: urg
<pitti> ogra: it worked with my old ~, but not with a fresh user
<ogra> i'm not up to date on my ibook, sorry
<tseng> dholbach: btw
<dholbach> Who_: doesn't that conflict with ubuntulooks - I think so
<tseng> dholbach: most of the new themes in ubuntu-art are broken for me
<Who_> dholbach: I have them both installed here - themes work fine
<tseng> dholbach: like they are missing an engine
<tseng> dholbach: they show up as the default ugly win9x theme
<dholbach> tseng: I know
<dholbach> tseng: next upload
<tseng> dholbach: ok, hugs
<pkern> pitti: Will it be fixed in dapper-release? ;)
<dholbach> Who_: so that means having a new dependency there
<doko> mvo: java ping
<dholbach> Who_: i'm not so fond of that :-/
<pitti> pkern: I doubt; dapper-updates maybe; can you please look for/file a bug?
<pkern> pitti: Will do.
<mvo> doko: tee pong
<Who_> dholbach: I guess it does - but I'm new to this stuff :)
<Who_> dholbach: all the themes no using ubuntulooks need a dependency...Currently it looks to me like we only depend on ubuntulooks
<dholbach> Who_: seems that ubuntu-desktop depends on it already
<Kamion> mdz: the patch I was talking about is in a comment on bug 47073
<Ubugtu> Malone bug 47073 in ubiquity "does not offer to use physical drive when LVM partitions are present" [Normal,Unconfirmed]  http://launchpad.net/bugs/47073
<dholbach> Who_: arg - which other ones do we need?
<Kamion> pitti: any luck on testing that?
<Who_> dholbach:OK, I'm just checking
<doko> I'm looking at various reports claiming that sun-java5-bin cannot be installed using espresso and apt-get; didn't check espresso, but apt-get works for me, even for a new installation. See bug 46096, bug 47273
<Ubugtu> Malone bug 46096 in sun-java5 "Apt will not install j2re1.4 on an espresso install" [Normal,Unconfirmed]  http://launchpad.net/bugs/46096
<Ubugtu> Malone bug 47273 in sun-java5 "Installation of sun-java5-jre fails on clean system" [Normal,Confirmed]  http://launchpad.net/bugs/47273
<pitti> Kamion: I'm right on it; the lvm alternate install succeeded, now I want to start ubiquity
<Kamion> doko: it breaks in noninteractive mode
<pitti> Kamion: however, clicking on the icon suddenly doesn't work for me *boggle*
<mdz> pitti: I just called Kamion about that; he's fixing
<mdz> it's a syntax error in /usr/bin/ubiquity
<z_diver> dholbach: I noticed nuoveXT icon set didn't get in there today.
<Kamion> doko: it's really a bug in the live filesystem generation, that debconf/frontend gets left as noninteractive; I believe Adam fixed that last night
<pitti> mdz: ah, I see; I fix it manually
<dholbach> z_diver: let's take this to ubuntu-art
<doko> Kamion: sure, so should I just print an error message to stderr, when noninteractive is selected?
<Kamion> doko: yes
<Kamion> doko: but don't manually look for noninteractive
<Kamion> doko: print an error message if db_input returns non-zero
<doko> ok, thanks
<Kamion> I think I commented as such on one of the sun-java5 bugs
<dholbach> z_diver: could you join?
<z_diver> dholbach: sure, is it on FreeNode?
<Kamion> (because somebody assigned it to debconf)
<dholbach> z_diver: yes
<Who_> dholbach: Fray needs gtk2-engines-pixbuf (which I couldn't see in ubuntu-desktop). IndustrialXT needs nothing not already there (Industrial Engine is in Ubuntu-desktop) and the othere need Ubuntulooks or Smooth - which is included in Ubuntu-Desktop)
<z_diver> dholbach: not finding it.
<dholbach> z_diver: /j #ubuntu-art
<pitti> mvo: ok, I fixed all the l-support-* for OO.o[2] 
<dholbach> Who_: let's take it to #ubuntu-art
<mdz> pitti: what did you and seb128 decide about poppler?
<Who_> dholbach: That would be Gray that needs pixbuf
<pitti> mdz: I just rebuilt tetex-bin, which should fix the issue
<seb128> mdz: we rebuilt tetex-bin
<pitti> mdz: all other packages have been built against the current poppler (I checked)
<pitti> mdz: IMHO safer than reverting the patch now
<pitti> and rebuilding 4 other packages
<mdz> ok
<seb128> mdz: upstream took the patch and infinity asked to the Debian maintainer to apply the same, so be stay binary compatible with Debian (and upstream will probably change their soname with next version)
<Riddell> mdke: kubuntu-docs uploaded with translated .desktops, thanks
<pkern> pitti: But I guess you don't have any hint how to get g-p-m to notice the possibility of sleeping?
<pkern> pitti: The bug report is filed.
<pitti> pkern: Kinnison should know, but he's not online
<pitti> pkern: thanks
<mvo> pitti: \o/
<Kamion> ubiquity syntax error fixed in bzr
<seb128> pkern: what do you mean by "notice"?
<seb128> pkern: force it to show you the option?
* pitti turns is full attention to ubiquity & lvm now
<pkern> seb128: Well... in a way, yes. On !powerpc it checks acpi-support, which I don't have.
<pkern> seb128: But I do not even get suspend on lid close, just screen locking. (Which is bad because the PMU will force a suspend after a certain amount of time.)
<seb128> pkern: ok, I know there is a /apps/gnome-power-manager/can_suspend gconf-key, but dunno if that's from any use for you
<pitti> bah, since when do we have psychedelic colorful buttons again on ppc? *grr*
<seb128> probably not
<seb128> pitti: I just marked like 10 duplicates of the bug
<pkern> seb128: can_hiberate is toggled, but not shown in the dialog o_O
<seb128> pitti: you use ati driver right?
<pitti> seb128: right
<pitti> seb128: still remember the issue I had in London? that was fixed ages ago, and now it's back
<seb128> pkern: so g-p-m probably thinks that's not possible, dunno then
<seb128> pitti: weird it was fixed
<pkern> seb128: Well, suspend is shown in the menu now, thanks.
<pkern> seb128: Got to try it now ;)
<pitti> seb128: didn't have a problem for months, and now it reappeared some days ago
<seb128> pitti: it's a common cairo/xrender issue on ati it looks like, we keep getting duplicates and we didn't fix anything for it afaik
<mvo> doko: I was not able to reproduce this either, it works for me from apt and gnome-app-install
<seb128> pitti: the best you can do is probably to use a non-cairo based theme (ie: anything but Human)
<pkern> seb128: Well, a bubble says "Your computer failed to suspend", but it worked just fine.
<pkern> seb128: Network, display and input devices all work well. So thanks a lot. (:
<seb128> np
<ogra> seb128, mdz, now fully upgraded: http://people.ubuntu.com/~ogra/shot1.png
<sivang> seb128: I have a patch for malone #39482 , do you think it can be uploaded if some folks give it testing on some off-archive debs?
<Ubugtu> Malone bug 39482 in nautilus "nautilus tries to move when dragging and dropping from read-only folders, instead of copying" [Normal,Confirmed]  http://launchpad.net/bugs/39482
<pitti> Kamion: yay, the 'use whole disk' selector works fine with your patch, and installation is running now
<seb128> sivang: to dapper-updates probably
<pitti> Kamion: I'll report to the bug when the installation actually finished
<ogra> and NM still doesnt work (it did before the upgrade)
<seb128> sivang: where is the patch?
<sivang> seb128: do you prefer to see debdiff attached to the bug report , as I can also prepare source pkgs
<Kamion> pitti: great, thanks
<Kamion> mdz: ok to upload that partman-auto patch, then?
<seb128> ogra: cd /usr/share/icons && find . -name "*gnome-logo-icon-transparent*" ?
<seb128> sivang: the diff to start with
<pitti> Kamion: hm, now it failed with 'Erzeugen eines Dateisystems fehlgeschlagen' (creation of fs failed)
<Kamion> pitti: gar. logs?
<pitti> Kamion: while creating /dev/hda3 fs for /
<sivang> seb128: k, I will attached it to the bug report for your convinience :-)
<Kamion> pitti: may still need ''vgchange -a n
<Kamion> er
<Kamion> 'vgchange -a n'
<seb128> sivang: good
<mdz> Kamion: has it been tested?
<Kamion> pitti: but let's have the logs and I'll check
<pitti> Kamion: /var/log/partman.log?
<Kamion> pitti: /var/log/partman and /var/log/installer/syslog please
<ogra> seb128, its in human, gartoon, and the a11y themes
<mdz> Kamion: it doesn't fall under my preferred "obviously correct without context" criterion
<seb128> ogra: I blame gartoon then
<mdz> Kamion: can you explain the fix to me?
<Kamion> mdz: see conversation with pitti, I'll wait until we've checked out his current problem
<seb128> ogra: open the gartoon one?
<Kamion> mdz: certainly
<ogra> seb128, how should that influence anything, i dont use gartoon anywhere
<jsgotangco> woo language upload
<Kamion> mdz: if there is only one disk available, partman-auto skips the disk selector so that you don't get a dialog with only one sensible option
<Kamion> mdz: we exclude /dev/mapper/*-* from the disk selector, because it doesn't make sense to offer logical volumes there (you can't partition them)
<ogra> seb128, thats the gartoon gnome foot (a blue comic one)
<pitti> Kamion: http://people.ubuntu.com/~pitti/tmp/
<seb128> ogra: is one of those matching the icon you see for the menu item?
<ogra> seb128, and Human/48x48 shows the one from the menu
<Kamion> mdz: the script responsible for the disk selector was erroneously picking the first option from the list of devices available in the event that only one disk is available, without excluding /dev/mapper/*-*
<ogra> seb128, nope, gartoon isnt in any of my menus
<Kamion> mdz: so, if only one (actual) disk is available and there are also LVM volumes around, it might well pick a logical volume instead of the first real disk
<seb128> ogra: Human ships an gnome-logo-icon-transparent.png for you?
<Kamion> the only real disk, that is
<ogra> seb128, just dpkg -S ing here
<carlos> pitti: we got 8000 new translations since yesterday language pack
<pitti> Kamion: I can do another one with verbose logging
<Kamion> the fix just keeps track of the first real disk and chooses that in the event that only one real disk is available
<pitti> carlos: wow
<mdz> Kamion: ok, makes sense
<ogra> seb128, hmm, nope, i wonder wher that comes from then ... 
* ogra deletes
<seb128> ogra: ok, it would have been weird
<ogra> no idea wher that comes from :/
<mjg59> mdz: gnome-power-manager needs to unconditionally enable suspend for PPC
<Kamion> pitti: strange, I can't find any actual error in there; yes please, verbose logging would be great
<mdz> mjg59: hey what to who now?
<pitti> mjg59: that must be a gconf issue, right? because it worked with my old /home directory, but not with a fresh user
<mjg59> pitti: Indeed
<ogra> seb128, sorry for the chaos ...
<seb128> ogra: np, but is that a new install from the current CD ?
<ogra> nope, my upgraded hoary
<seb128> ogra: ie: is that likely to be something on the CD that created it?
<mjg59> mdz: Whether or not suspend is available is controlled via a gconf key, which always ought to be true for PPC (but currently isn't)
<seb128> ah, ok
<carlos> pitti: and 24331 since Friday
<ogra> hoary->breezy->dapper
<mjg59> mdz: Can I show you a patch in an hour or so?
<seb128> ogra: you probably played some time ago to change the panel logo
<ogra> seb128, must have been long ago since i dont remember it at all
<seb128> ogra: that icon used to be the panel emblem for hoary
<sivang> seb128: patch attached to bug report, now I have a train to catch, /me runs
<ogra> but well, its the only explanation:)
<seb128> later sivang
<seb128> ogra: right
<sivang> laters folks
<carlos> doko: hmm I think the impress' .pot and .po files are not being generated
<infinity> mdz: Ready to wrap your mind around some HideousHacks(tm)?
<ogra> btw, will we get a saner distributor logo or will we have to live with the "stolen from osX aqua" one ?
<infinity> mdz: HideousHacks, AKA "Why most people should never use diversions, cause fixing misuse sucks"
<ogra> this buttonish border looks scary :)
<pitti> ogra++
<seb128> ogra: https://launchpad.net/distros/ubuntu/+source/ubuntu-artwork/+bug/47260
<Ubugtu> Malone bug 47260 in ubuntu-artwork "Distributor icon is ugly" [Normal,Confirmed]  
<seb128> comment on it
<ogra> hehe
<ogra> will do :)
<pitti> the doc team already complained about breaking screenshots all over
<ogra> i neither didnt like the one before, but that looked a lot better
<mdz> infinity: the only reasonable fix for diversions bugs is to remove the use of diversions entirely
<infinity> mdz: Heh.
<infinity> mdz: Seeing this debdiff will likely solidify that opinion for you.
<pvanhoof> eeeeeeeeek. what is that border around the ubuntu logo
<infinity> mdz: http://cerberus.0c3.net/~adconrad/ia32-libs.diff
<infinity> seb128: Commented.
<jsgotangco> pvanhoof: amen
<mdz> why does it seem like all reporters of Kubuntu ubiquity bugs flag them as security-related for no apparent reason?
<infinity> mdz: The ia64 bit in preinst comes froms somewhere along the way, the diversion being randomly renamed from ldd.amd64 to ldd.ia32-libs, so now there's a mix of both in the wild.
<fabbione> mdz: because they are special?
<fabbione> the bugs i mean .. of course..
<infinity> mdz: The postinst ugliness comes from past failed attempts at removing diversions, so some machines ended up with a parentless /usr/bin/ldd for no sane reason.
<pitti> Kamion: http://people.ubuntu.com/~pitti/tmp/ *.verbose
<infinity> mdz: It's all very scary.
<infinity> mdz: But appears to be correct, and was tested on amd64 and ia64, breezy and dapper chroots.
<pitti> Kamion: exactly the same error after restarting ubiquity with verbosity (although the partition table was already updated in the first run)
<hunger> What are my chances to see suspend working in dapper as well as it did in breezy?
<infinity> hunger: If it's not currently, then "about nil".
<doko> Kamion: in the installer: did the console mode (frame buffer / vga) did change in dapper (compared to breezy)?
<infinity> hunger: We're going to close the gates for uploads completely very shortly.
<hunger> infinity: I feared that:-(
<Kamion> doko: it's 640x400 now
<Kamion> (vga16fb change in kernel)
<hunger> infinity: Well, I guess I'll have to install breezy again then:-(
<Kamion> pitti: oh, can you get /var/log/syslog too? I think the actual error may have landed there
<Kamion> I need to consolidate that post-dapper, the current situation is a mess
<fabbione> Kamion: can you confirm we don't have LAMP on dvd? (powerpc)
<infinity> doko: We changed the framebuffer to work a bit better for 5% of people, which made it worse for 1%... Are you in the 1% that got shafted?
<Kamion> fabbione: correct
<fabbione> Kamion: ok thanks.
<Kamion> fabbione: given a bit more time, it would be fixable, but ...
<Kamion> (ENOTIME)
<pitti> Kamion: indeed -- 'could not stat /dev/hda3 -- no such file or directory'; I'll send you the full log
<Kamion> pitti: whoa, oddness
<doko> infinity: no, see bug 47283
<Ubugtu> Malone bug 47283 in bash "Strange Resolution in Shell" [Normal,Unconfirmed]  http://launchpad.net/bugs/47283
<fabbione> Kamion: i think we can live without.. thanks
<pitti> Kamion: http://people.ubuntu.com/~pitti/tmp/var_log_syslog
<pitti> Kamion: Indeed I have /dev/hda[124] , but not 3
<infinity> doko: 80x25 is "strange" now? :)
<Kamion> pitti: 403
<pitti> Kamion: it seems udev needs to be poked after recreating partitions or so?
<Kamion> we do poke udev though, I think ...
<pitti> Kamion: sorry, fixed
<Kamion> do you have /bin/update-dev?
<pitti> yes, I have
<infinity> doko: I guess he got used to the non-standard 80x30 that the 640x480 console gave him.  He also needs to adjust his monitor to show the whole image, which might help.
<infinity> doko: Very much a Rejected bug waiting to happen. :)
<doko> infinity: already done :)
<infinity> mdz: Comments on the ia32-libs scariness, or do you just want me to upload it without you looking, so you don't have to vomit?
<fabbione> infinity: he is busy atm...
<infinity> fabbione: Ahh.
<infinity> Are you his new scecretary? :)
<infinity> secretary, too.
<fabbione> infinity: no,  but i can 
<fabbione> infinity: no,  but i can watch him moving around the office
<Kamion> pitti: I must say, I can't say I understand this
<carlos> mdz: Hi, When will be open edgy in launchpad?
<infinity> Did I promise anyone anything today that I haven't yet done (other than ia32-libs)?  I'm starting to lose track of my own body parts.
<Kamion> pitti: particularly given that that partition allegedly exists on boot, according to the syslog
<fabbione> infinity: to fill up my bank account?
<Kamion> so I blame, er, well, no idea
<infinity> carlos: When soyuz is ready for us.
<pitti> Kamion: fdisk -l /dev/hda3 also prints it
<pitti> Kamion: I just called /bin/update-dev manually, doesn't help
<carlos> infinity: so you need some code changes first?
<infinity> carlos: No, we just need to get the distribution created, make sure it works, etc.
<Kamion> pitti: what's in /sys/block/hda?
<carlos> so that means this week or next one...
<infinity> carlos: Other than the fact that we'll all be exhausted, I suspect that a couple of hours between cprov and I will be all that it takes to make it go.
<carlos> hmm, I'm being late then to get translations in place too
<pitti> Kamion: hda[124] , no 3
<Kamion> pitti: then your kernel is interestingly confused
<pitti> Kamion: vgchange -a n doesn't help either
<carlos> infinity: please, tell me if you agree on a date for it
<infinity> carlos: "Any time after June 1" :)
<carlos> ;-)
<carlos> ok
<infinity> carlos: Some of the devs will be itching to upload ASAP, so the faster we can get going on the infrastructure side, the better.
<pitti> Kamion: ok, let's debug that at a later point then? it seems unrelated to the partman patch I tried
<Kamion> pitti: I think so, yeah
<carlos> infinity: yeah, I will try to get it in place in time, if I'm late... I will execute it by hand and put it in place for edgy + 1
<Kamion> I've uploaded the partman-auto patch
* pitti reboots, hoping that this will fix it
<pitti> unless you need anything further
<Kamion> pitti: nope, thanks
<pitti> Kamion: I file a bug with what we have, as a reminder
<Kamion> thep: there's way too much hardcoded in kbd-chooser, sigh - I didn't realise that the *.syms.h files were copied in there too
<Kamion> not fixable before dapper, but fixable after
<Kamion> pitti: thanks
<mdz> infinity: can you upload an ia32-libs with only the new packages so that we can consider this more substantial change separately?
<mdz> carlos: some time after dapper is released
<infinity> mdz: Yeah.
<mdz> infinity: what is the bug it is fixing?
<mdz> is there a report open?
<ogra> mdz, amd64 dapper->dapper upgrades fail completely on ia32-libs
<thep> Kamion, OK. Will wait till post-dapper.
<Kamion> sorry it wasn't spotted earlier, again
<infinity> mdz: Some reported, some not.  Upgrades from several intermediate dapper versions are broken on amd64.  Upgrades from breezy to dapper are broken on ia64, fresh installs on ia64 are currently broken.
<Kamion> thep: ubiquity *might* manage to work (possibly by accident), not sure
<infinity> mdz: The failure cases are explained above in my ramblings to you to explain the changes.
<thep> Kamion, you mean another installer?
<Kamion> thep: the desktop CD installer
<Kamion> it does use kbd-chooser under the hood though, so my guess is that it will also fail
<mdz> infinity: why does breezy->dapper break on ia64 but not amd64?
<mdz> I must admit, I am not very sympathetic toward ia64 at this juncture
<thep> Kamion, it's another installer than espresso?
<infinity> mdz: Because ia64 still ships a divers, amd64 doesn't, and somewhere along the way, someone decided to rename that divers from ldd.amd64 to ldd.ia32-libs.
<mdz> doko: what do you mean by this?
<mdz>    * Build using qt-x11-free_3.3.6-1ubuntu5, entering the archive in
<mdz>      dapper-updates.
<infinity> mdz: So, we can either break all dapper->dapper upgrades by forcing it to be ldd.amd64, or break breezy->dapper by forcing it to be ldd.ia32-libs, or employ the hack I added in that preinst to normalise it.
<Kamion> thep: espresso is called ubiquity now
<thep> Kamion, i see
<doko> mdz: the qt-x11-free_3.3.6-1ubuntu5 is not yet in the archive, but built by hand on a clean environment. 
<infinity> mdz: Anyhow, the ia64 code is all if-guarded anyway, so it's a "for-free" change while fixing the amd64 stuff and updating the binaries.
<mdz> doko: the one that I said should wait until after release?
<doko> we did agree to upload the qt-x11-free_3.3.6-1ubuntu5 to dapper-updates, didn't we?
<doko> correct
<mdz> doko: dapper-updates, NOT dapper
<pitti> argh
<Kamion> right, 1600, time to download translations
* pitti kills anacron to get the live CD usable again
<ogra> wasnt that fixed ?`
<ogra> Keybuk poked on it a lot
<doko> mdz: I'm confused; you did OK ia32-libs-kde
<pitti> ogra: ISTR reading a pbbuttonsd changelog entry, but it's still started on ppc/live
<ogra> bah
<mdz> doko: please revert
<mdz> doko: if this is what you meant, I misunderstood you
<doko> mdz: well, yes, that was a misunderstanding. 
<pitti> carlos: now that we have all domains that the buildd tarballs have, can we be sure to have all PO files as well?
<pitti> carlos: i. e. can I drop the tarball merging?
<Kamion> hmm, I have several ubiquity bugs which I think are due to people not reformatting the root file system
<carlos> pitti: I think so, yes, the only ones that we would be missing are the ones that failed
<carlos> pitti: and we have that list already
<infinity> pitti: Drop tarball merging?  Does that mean I can stop publishing them and remove apache from the buildds? *excited look*
<Kamion> I think I'll worry about those after dapper, unless anyone radically objects ...
<doko> mdz: do we really need to revert that? it's a local change only affecting kubuntu on amd64, tested by Riddell and me. The rationale of this was having one less abort for OOo
<pitti> carlos: 'the ones that failed' -> is that yes or no?
<carlos> pitti: I have those entries available from launchpad.net/rosetta/imports
<carlos> pitti: so I guess the answer is 'yes'
<pitti> carlos: failed because they are broken, or because importing them doesn't work?
<carlos> pitti: most of them, because the files are broken
<pitti> carlos: in the former case, shipping them in the langpacks doesn't make sense anyway
<carlos> pitti: I guess a couple are due rosetta bugs, and from time to time, I review them
<carlos> pitti: don't worry, I will reduce that list to zero so any missing translation will appear in next language pack
<pitti> carlos: great
<Kamion> is Rosetta still stalled doing the OOo import?
<infinity> mdz: I can do a much smaller patch that doesn't worry about upgrade breakage at all, but at least makes ia64 installable from scratch (that's just an if guard around one statement, instead of the gobs of scary in the previous diff)
<Kamion> it seems to be taking longer than usual to do a couple of translation exports
<infinity> mdz: While I'd prefer to sort all the upgrade bugs, I can see the argument for just leaving it saying "oh well, good enough for most users"
<carlos> Kamion: 320 .po files to go
<seb128> carlos: did you update the evolution template? do you know when the change will be applied?
<Kamion> carlos: any rough ETA?
<carlos> Kamion: oh, the export thing is unrelated
<mdz> doko: I said that the change should go to dapper-updates, not that it should go in dapper for kubuntu/amd64
<mdz> infinity: this smells like dapper-updates to me
<carlos> Kamion: I'm doing full exports of OO.org to generate language packs, but should be much faster as I got already most of them
<carlos> Kamion: you should get your request in 10 - 15 minutes, don't think it would take much more
<carlos> but the imports don't block the exports
<carlos> so those are unrelated
<Kamion> carlos: ok, thanks
<Kamion> ah yes, there's one of them now
<seb128> carlos: and about my question? :)
<doko> mdz: my understanding was, that the qt-x11-free upload should go to dapper-updates and the ia32-libs-kde upload to dapper; therefore the followup discussion with infinity how to provide the qt-x11-free packages included in ia32-libs-kde. I think we would be better with working qt widgets and scim on kubuntu-amd64, but preparing the upload now.
<infinity> mdz: Here's what I'm talking about.  If I ignore all the possible upgrade snafus addressed by the scary patch (and leave those for -updates), this will at least make the ia32-libs on the ia64 ISO installable.
<infinity> mdz: http://cerberus.0c3.net/~adconrad/ia32-libs.diff2
<mdz> doko: you showed me a diff
<mdz> http://people.ubuntu.com/~doko/ooo-amd64/ia32-libs-kde.diff
<carlos> seb128: the evolution template is blocked by OOO imports
<mdz> doko: but that is not what you uploaded
<pitti> mantas_, seb128, Riddell, carlos: new daily language packs ready for testing. Please upgrade to them and report any issues you might find (final candidates)
<carlos> seb128: I don't think it will be imported until tomorrow
<seb128> pitti: ok, will do
<seb128> carlos: ok, then dapper will have that bug, no big deal that's a detail
<danimo> crimsun: ping?
<carlos> seb128: well, dapper will have it anyway, final language packs are already done
<carlos> seb128: even before you gave me the fixed .pot file
<seb128> carlos: right
<mdz> infinity: ok, you have a deal
<infinity> mdz: Danke.  I'll pester you for the other change on June 2nd. :P
<mdz> doko: this doesn't affect the CDs and we can look at it after release; it's not a trivial change by any means
<infinity> (Or I'll forget about it and won't care in a month)
<mdz> infinity: perhaps both of the ia64 users will remind you
<infinity> mdz: well, it affects OOo working properly on the kubuntu/amd64 livecd.  That's about it.
<danimo> crimsun: unping
<infinity> mdz: I suspect that after we made a lot of noise about Ubuntu and KDE, saving face with livecds that work well might be worth it.
<mdz> infinity: no, it just means it doesn't get the KDE file dialog
<mdz> right?
<infinity> mdz: Note that the change is localised to ia32-libs-kde, which is broken anyway.
<infinity> mdz: Riddell would have to confirm that.  I'd understood it as "the dialogs are completely broken", but I've not actually looked.
<mdz> infinity: the KDE dialog is broken; Riddell unseeded oo.o-kde to work around that.  it works.
<mdz> and we're not going to revert that change in favor of this one
<infinity> Ahh, well.  If it works perfectly well otherwise, then screw it.
<mdz> that would be exchanging a simple and safe fix for a complex and risky one
<infinity> But getting this in -updates ASAP for breezy->dapper upgraders would be nice.
<infinity> Cause they'll have OOo-kde installed, and it'll break.
<mdz> it's already broken
<mdz> and apparently has been for some time
<infinity> I understood that it worked in breezy.
<infinity> Then broke early in dapper.
<infinity> So people jumping from breezy to dapper will watch it regress.
<infinity> Achwell.  I'd rather go bikeshed about the ugly icon on my panel anyway.
<infinity> It's not the end of the world if this gets fixed post-release, it's just unfortunate that the livecd will lack the shininess of a pseudo-integrated OOo.
<pitti> rebooting to test final langpacks
<pitti> carlos: any idea why you don't export the 'libc' domain from glibc any more?
<carlos> pitti: https://launchpad.net/distros/ubuntu/dapper/+source/glibc/+pots/libc is setup to appear in language packs
<doko> mdz: I'm reverting it. it's not true, that I did upload something else. I adjusted the changelog after our discussion to be more verbose. See http://people.ubuntu.com/~doko/ooo-amd64/ia32-libs-5-6.diff for reference
<pitti> Riddell, seb128: apart from dropping libc domain (compared to yesterday), new langpacks look good to me
<carlos> pitti: the only thing I can guess is that we got no .po files for that translatio domain....
<pitti> carlos: the libc tarball has plenty
<carlos> for libc ?
<Kamion> gar, why are people translating pt and pt_PT separately] 
<Kamion> or es and es_ES
<carlos> Kamion: which domains?
<carlos> we are 'killing' those translations
<jdub> Kamion: where are the dvd images hosted?
<mdz> doko: thank you
<doko> mdz: is it ok to freshen the packages from the archive for the ia32-libs-kde upload?
<Kamion> carlos: ubiquity/+pots/ubiquity
<pitti> carlos: yes, glibc tarball has lots of po files; unfortunately it doesn't build mo files any more, so the buildd tarball doesn't have them
<Kamion> jdub: cdimage.u.c/releases/dapper/blah
<jdub> oh,ok
<Kamion> or cdimage.u.c/dvd/ for dailies
<mdz> Kamion: are installer translations going to make this cron.daily?
<Kamion> jdub: I don't think I published DVD images for the RC
<Kamion> mdz: er, maybe, if I stop being asked questions ;)
<Kamion> probably not though, it takes a while
<carlos> pitti: I will do a manual import of those .po files
<infinity> I can just turn off the publisher crontab and we can start by-handing it...
<pitti> carlos: right, let's ship them in -updates
<carlos> Kamion: I did some changes to prevent even more that situation
<infinity> Okay, I think that's my last upload for dapper-release.
<infinity> Who knows how many I'll be making for -updates, but whatever.  :)
<bgertzfield> infinity: Go have a drink. ;)
<infinity> bgertzfield: Well, no, now I get to drive the FTP and CD build machinery.
<infinity> After June 1st, THEN I can drink.
<infinity> Copious amounts, if I have my way.
<Kamion> I heartily wish that merging installer translations was quicker
<carlos> doko: I did a single .tar.gz export this time
<bgertzfield> infinity: Yes.  Yes you will.
<carlos> doko: http://people.ubuntu.com/~carlos/ooo-dapper-2006-05-29.tar.gz
<mvo> bgertzfield: hello! did you got my mail?
<bgertzfield> mvo: Yeah!  I just got the email.  Thanks again. :)
<doko> carlos, mdz: these OOo translations are still targeted for dapper?
<Kamion> mdz: no, no way I'll make this cron.daily, sorry
<carlos> doko: It lacks ooo-impress because for some reason, you didn't provide it or it wasn't imported into Rosetta (not sure why)
<carlos> mdz: those are to generate ooo.org language packs that have their own packages outside pitti's language packs
<mdz> Kamion: urgh, I would have uploaded a 1.0.10a fixing the typo if I had known
<mdz> it would be nice to have working desktop CDs this close to release
<thep> Kamion, Gotta go to bed. Thanks for handling the bug.
<Kamion> mdz: sorry, I'll have it for this cron.daily
<Kamion> working as fast as I can
<seb128> pitti: language packs look good to me
* pitti hugs seb128 
* seb128 hugs pitti
<infinity> Kamion: I can stop the soyuz machinery for you if you're not going to make it.
<mathrick> hi, I need some help with Ubuntu's fontconfig, namely, I'm trying to patch is so that FreeSans is considered as the very last candidate (it's too ugly for anything else), and also to make my Japanese fonts look right
<Tonio_> hi
<mathrick> I thought it'd include /usr/share/language-selector/fontconfig/$LANGUAGE, but apparently, that's not the case
<Kamion> infinity: I'll make this one, just not the previous one
<mathrick> the result is that Japanese-specific overrides for embedded bitmaps and similar don't work
<infinity> Kamion: Alright.
<mathrick> actually, I believe embedded bitmaps should be simply disabled per-script, no matter the current locale, but that's another step, right now I want to see why it does't work the way I expect it to
<mathrick> hey Burgwork 
<ogra> mathrick, please ask support questions in #ubuntu we're preparing the release here
<mathrick> ogra: this is not a support question, this is me trying to fix problems with language-selector
<mathrick> ogra: the desired end result is a patch
* mathrick looks for bug #
<mantas_> pitti, where I can find new language packs ?
<infinity> mathrick: Even if a patch is produced, it won't make dapper at this point, so this may not be the ideal time to discuss it.
<Burgwork> hey mathrick 
<pitti> mantas_: deb http://people.ubuntu.com/~pitti/langpacks/daily/ ./
<mathrick> infinity: okay, but that's nevertheless something that needs addressing, I got the first part figured out, now I need someone to tell me if /usr/share/language-selector/fontconfig/$LANGUAGE is supposed to be read by fontconfig
<mathrick> so that I know if I should move to #ubuntu and try to debug my install
<Kamion> infinity: could you hold soyuz after all please? hit a small snag
<infinity> Kamion: On it.
<Kamion> should only take an extra ten minutes
<infinity> I'm timing you.
<fabbione> infinity: me?
<Kamion> you're timing my ISP's upload bandwidth now
<Kamion> no me
<fabbione> :)
<Coyctecm> what's default font in open office, open office don't respect .fonts.conf ?
<mdke> Riddell: rock!! thanks a lot
<Kamion> infinity: Good to go now.
<Kamion>    39659 | S- | ubiquity             | 1.0.11               | 30 seconds
<Kamion>          | * ubiquity/1.0.11 Component: main Section: admin
<infinity> Woo.
<infinity> Publishing.
<Kamion> the snag was that I broke the encoding of partman-auto's Croatian translation by accident during the merge
<infinity> That was a lot of language packages that just scrolled across my screen...
* pitti hides and whistles
<crimsun> pitti: I've received no word (at least in awaylog). -updates is fine. Thanks.
<pitti> crimsun: yes, let's do it for -updates then, should be easier to undo if it should really break something
<pouet> I have done a libpam_mount patch, but the author doesn't seem to react on source forge. I want to know if it's possible to have them included in ubuntu patches ?
<pouet> or if there is some place to submit them.
<pouet> maybe launchpad ?
<pitti> pouet: please submit it as a bug report
<pitti> pouet: it's nothing for dapper, we are in ice cold freeze
<pouet> pitti: yes, but I will swich to edgy eft soon after it's released
<pouet> pitti: I have read the repository will open mid jun
<pitti> pouet: yes, it will
<jdub> ice cold freeze! *dink* ... that's the sound of another dapper-changes mail hitting the ice... ;-)
<pitti> jdub: Scrud managed to get out, too :)
<pitti> (the furry cute animal from Ice Age)
<pouet> I am impatient to have upgrades
<pouet> I hope edgy eft will not be too much broken ^^
<ogra> i hope it will
<jdub> pitti: ha ha
<ogra> at least in the beginning
<infinity> I'm planning on breaking it spectacularly.
<jdub> i hope edgy is a buckling tower of pain and horror to start with
<ogra> brokeness in the beginning of a cycle means more new features ;)
<ogra> yay
<jono> hey jdub
<jdub> morning jono
<zyga> hello
<zyga> I'm sorry for dissapearing yesterday but my laptop is no longer operational
<bgertzfield> hey zyga
<bgertzfield> sorry to hear that :(
<bgertzfield> I hope I didn't trash it!
<zyga> no
<bgertzfield> phew
<pitti> zyga: iz GTK bug?
<zyga> I turned it off because the fan was malfunctioning
<zyga> pitti: hum?
<bgertzfield> I see
<zyga> bgertzfield: it is not damaged but I need to get some hardware to re-assemble it
<pitti> zyga: nevermind, seb128 will kick me soon enough
<mvo> zyga: oh, that are bad news :/
<zyga> phone
<sivang> re all
<zyga> back
<zyga> hi sivang
<zyga> pitti: gtk display bug on ati drivers?
<sivang> hey zyga , how is it going?
<pitti> zyga: yes, that one sucks
<zyga> anyway I need to get some CPU heat paste and re-assemble the thing carefully
<zyga> pitti: yes it's very annoying
<zyga> pitti: but hibernation works ! :)
<zyga> sivang: I trashed my laptop
<sivang> zyga: oh god, how did you do that?
<zyga> (or, it died and I trashed it trying to repair)
<zyga> fan got stuck
<zyga> I disassembled it 
<zyga> I'll drop a pic because it's pretty picture :D
<zyga> so much stuff in that laptop is useless IMHO :)
<zyga> pitti: how is a bug like that generated?
<pitti> zyga: out of sheer malice; frankly, I don't know
<zyga> pitti: it's rather ackward, like some color mask gone wrong
<zyga> too bad it's this close to release
<sivang> pitti: I managed to fix something from the Radar :-) malone #39482 , but I forgot to drop the debug g_warnings in the debdiff I attached to the bug :-/
<Ubugtu> Malone bug 39482 in nautilus "nautilus tries to move when dragging and dropping from read-only folders, instead of copying" [Normal,Confirmed]  http://launchpad.net/bugs/39482
* sivang checks the bug trail
* sivang goes to fix the debdiff and re-attached
<pygi> sivang, hey
<sivang> pygi: hey dude
<pygi> you have a sec or working on bugs?
<sivang> pygi: 'sup?
<pygi> fixing Diva bugs (not that you know what that is, but still :P)
<sivang> pygi: I just need to fix a debdiff, so I can chat while doing that
<sivang> pygi: Diva, I think you showed me it's interface sometime ago?
<pygi> sivang, indeed :P
<pygi> sivang, https://wiki.ubuntu.com/HomeUserBackupNg
<pygi> some nice ideas from me :)
<sivang> pygi: k, cool thanks
<sivang> pygi: I had some discussins with mpt the other day,
<sivang> and I'm keen to change a bit our plans :)
<pygi> sivang, who is mpt? :-/
<pygi> and how do you want to change plans?
<sivang> mpt is Ubuntu's in house UI specialist and designer
<sivang> ;-)
<Treenaks> sivang: GUIru?
<pygi> o joy, and I guess changing plans means in UI ?
<sivang> pygi: not entirely :)
<pygi> sivang, ergh, what then? 
<pygi> Don't say you wanna change the scope to "World best backup application" ? :)
<sivang> but changing plans is more of to postpone the "super uber complete disaster recovery system" and first concentrate on making it rock solid , with all the bindings in place,
<sivang> and so get it and tell many users it's safe to use.
<sivang> we only have like 4 months before edgy, and I am not sure we would be able to complete everything in time if we try to do everything at one hit,
<sivang> we already have lots of work in doing better device detection, and making it respond in real time to plug events like hal does,
<sivang> in accordance with that we need to make sure all error are trapped and are accounted for in an appropriate way
<pygi> sivang, we won't have complete recovery disaster system ready for edgy ofcourse
<sivang> plus adding support to for remaining size probes for different devices etc..
<pygi> sivang, I added a lot more things we have to work on for system like that, so it's sure we wouldnt be able to finish it in time
<sivang> we have enough work to do together with the notifcation infrastrucutre without making it super uber disaster recovery system
<pygi> sivang, please look at that page I gave you , and add part (Edgy - Scope )
<sivang> pygi: cool, I will ldo that
<sivang> I'm just happy you're not disappointed by it
<pygi> also, please comment the things I wrote down :)
<sivang> You seemed very eager and I would hate to break you enthusiasm :-)
<sivang> pygi: will do, but first I Need to fix the debdiff I sent to seb128 so he won't get angry at me :)
<pygi> sivang, bah, I haven't even planned to have all that ready for edgy :)
<HiddenWolf> sivang: you've got some home user backup love planned? :)
<zyga> I'm pulling pictures of my mess
<pygi> All we need is get general infrastructure on which we can build on
<zyga> I should be ashamed of myself :)
<pygi> HiddenWolf, a lot love :)
<sivang> HiddenWolf: lots and lots of love
<sivang> HiddenWolf: I already have a team behind me :)
<HiddenWolf> SoC?
<pygi> HiddenWolf, nop, no SoC :)
<pygi> sivang, o joy, team is 3 people :)
<HiddenWolf> btw, is there a list of accepted _buntu projects?
<pygi> HiddenWolf, yup
* HiddenWolf curious
<HiddenWolf> ah
<pygi> sivang, that team on LP ... are we going to hold there all people interested in HUB, or just devs?
<pygi> sivang, btw. we are
<pygi> argh. :P
<pygi> will be back in sec
<pygi> sivang, back, hopefully you got the last pm
<pygi> dinner, brb
<sivang> back now
* sivang checks pm
* pygi is back
<sivang> pygi: after you do the doc I could write the neccessary bindings myself even I guess :)
<Mithrandir> sladen: why do you think 43780 has a lower severity because it's not in main?
<sivang> pygi: what did you mean in 
<sivang> GnomeVFS
<sivang> 1)Take advantage of GnomeVFS in "boot" mode
<sivang> 2)Port GnomeVFS pre-boot so we could take advantage of it (?!) 
<sivang> ?
<sivang> How is it related to the preboot/post-boot ?
<_ion> 0) Rewrite GnomeVFS to be a thin wrapper to something like fuse.
<_ion> The same applies to KDE VFS.
<sivang> to have it available in boostrap environments?
<pygi> sivang, sorry, afk, I'll be here later :(
<sivang> pygi: no problem :-)
<sivang> hmm, applying debdiff is with plain patch right?
<sivang> after all, it's just a patch :-)
<zyga> done
<zyga> I've got all the messy pictures :)
<sivang> hmm, how I tell patch to create a file that's listed on the patch if it's not laready there?
<sivang> zyga: any idea?
<zyga> hmm
<Mithrandir> sivang: run diff with -N; patch does so automatically
<zyga> right
<zyga> -N diff's new files
<chantra> hi there
<zyga> -Naur - new, treat all like text, universal, recursive
<zyga> the universal differ
<chantra> I would like to cross compile package from a i386 to amd64
<chantra> it seems that amd64 arch doesn't exist in the kernel
<chantra> should i use ia64 ?
<zyga> chantra: ?
<zyga> chantra: ia64 is not amd64
<chantra> :(
<zyga> chantra: the kernel fully supports x86_64 aka amd64
<zyga> but you want a cross compile first
<zyga> s/compile/compiler/
<chantra> okie dokie :)
<chantra> yep, I'm on my way to tpkg-make :)
<chantra> giving a try :)
<sivang> Mithrandir: I already did a debdiff, should patch then automaticaly handle stuff?
<Mithrandir> sivang: yeah
<zyga> sivang: unless it's binary then yes
<sivang> Mithrandir: I want to change only inside the debdiff already, instead of re-introducing the changes into a fresh source
<sivang> Mithrandir: and then apply and test the changes
<sivang> zyga: it
<sivang> zyga: not a binary pkg
<Mithrandir> just edit the debdiff, then
<sivang> zyga: only souce
<sivang> Mithrandir: ok, I've done that, tries to patch -p1 < ... and it gave a warning about the non exisitng debian/patches/.. file, and did not create it there
<sivang> patching file debian/changelog
<sivang> patching file debian/patches/94_readonly_dnd_fix.patch
<sivang> patch: **** unexpected end of file in patch
<chantra> zyga: while tpkg-make Hmph - dunno the x86_64-linux arch
<sivang> 94_readonly_dnd_fix.patch - this is the new file that did not exist before
<chantra> while tpkg-make x86_64-linux it tells me:
<chantra> Hmph - dunno the x86_64-linux arch
<_ion> sivang: Perhaps rediff(1) would help.
<zyga> chantra: I don't know tpkg-make, sorry
<chantra> arf :s
<sivang> _ion: right, thank you!
<chantra> zyga: cheers :)
<zyga> chantra: good luck
<sivang> Mithrandir: I just needed to fix the offest indicators :)
<Mithrandir> sivang: use a real editor which does so for you.
<sivang> Mithrandir: care to tell me which is it? :)
<sivang> nonetheless, patching failes... I guess I might do it manually afterall
<Mithrandir> sivang: emacs does, at least.
<sivang> okay, I'll try with emacs , maybe it will do better the offset adjustment
<sivang> well, it appears rediff gets confused over debdiffs
<chantra> zyga: have you ever cross compile .deb package?
<sivang> given debdiffs are diffs over diffs
<highvoltage> wow. that's deap, man.
<zyga> chantra: no but i cross compile stuff dauly
<zyga> daily
<chantra> well I want to create .deb package, therefore it would be handy to be able to use dpkg utils :)
* chantra it is a long time since I cross compile :s
<zyga> I don't know how to cross compile debs really
<Kamion> last I checked, dpkg-cross was the answer
<zyga> we use properiarity system at work
<chantra> Kamion: yep, but I need to set up the environment first
<chantra> and it seems amd64 and x86_64 are not supported by tpkg-make
<chantra>  wonder if ia64 will do the trick
<zyga> chantra: no
<chantra> <target> should be one of alpha-linux, arm-linux, hppa-linux, i*86-linux,
<chantra> ia32-linux, ia64-linux, m68k-linux, mipsel-linux, mips-linux, ppc-linux,
<chantra> powerpc-linux, sparc-linux, s390-linux or similar.
<zyga> that's 100% different arch
<zyga> different CPU and instruction set
<chantra> arf, the pasted bit is from tpkg doc
<chantra> to you see anything near to amd64?
<zyga> no
<chantra> :(
<chantra> :p
<sivang> highvoltage: deep? :)
<Kamion> I'm sure you could just search for any of those architectures and hack amd64 into the list ...
<highvoltage> sivang: i'm in the mood for joking :)
<sivang> highvoltage: well, you first need to let rediff work out your debian/patches level patch
<sivang> highvoltage: then , create a new debdiff
<sivang> as rediff on a debdiff seems not that useful :)
<highvoltage> :)
* sivang ownders if there a tool that works out edited debdiffs
<sivang> ah, finally
<sivang> clean debdiff attached
<sivang> now just wait for the Seveas 
<sivang> oops
<Seveas> ?
<sivang> , for the seb128 
<Seveas> heh
<sivang> :)
<Seveas> yeah, the seb128 is much more useful than the seveas 
<sivang> hehe
<sivang> Well, only when you need him to break stuff on your behalf in mina :p
<sivang> or mine as well
* sivang args at the net latency
<sivang> my battery is almost done with all this nautilus building
<sivang> laters all
<zyga> bye sivang 
<highvoltage> bye sivang 
<pygi> sivang, back :)
<pygi> sivang, so you wanna get rid of everyone once you have the doc? :P
<mdke> dholbach: something has destroyed the help system...
<dholbach> mdke: destroyed as in how?
<pygi> sivang, about GnomeVFS...I was thinking that we could transfer backup images to nfs, ftp, bla, bla and all that provided by GnomeVFS)
<mdke> dholbach: yelp is empty except for about ubuntu (gnome docs, ubuntu docs are gone)
<mdke> dholbach: something scrollkeeper related?
<dholbach> I can't confirm that
<mdke> ah
<dholbach> and I have the newest scrollkeeper version and everything installed
<mdke> dholbach: i see it, and so do two more in -doc
<dholbach> urg
<dholbach> which locales are that?
<mdke> en_GB
<dholbach> all of you?
<mdke> dholbach: yes I think so. The other two aren't around now
<mdke> dholbach: DonS the yelp guy who runs Ubuntu confirms it too
<dholbach> mdke: same locale?
<mdke> dholbach: he's English so I guess so
* mdke tries with -it
<olemke> dholbach, mdke: same yelp issue here with en_US.UTF-8
<mdke> dholbach: italian works ok
<mdke> bbiab
<dholbach> I'm trying something
<dholbach> i'll get back to you in a bit
<dholbach> olemke, mdke: can you try to install the .deb files from  http://daniel.holba.ch/ubuntu/scrollkeeper/ and try again?
<olemke> dholbach, sure
<olemke> dholbach, those are for amd64? i'm on 386 :-(
<dholbach> urg, sorry
<dholbach> just a min
<olemke> dholbach, no problem
<dholbach> didn't think about it :)
<dholbach> can you check again? reload the page?
<olemke> dholbach, better :-)
<dholbach> olemke: please tell me if that works for you
<olemke> dholbach, unfortunately still the same. LANGUAGE=en_GB or en_US only shows about ubuntu
<olemke> de_DE and it_IT works fine
<olemke> or do i have to do anything else after installing the packages (like re-login)?
<dholbach> no, not at all
<olemke> thought so
<dholbach> which version of ubuntu-docs is that?
<olemke> 6.06.1
* seb128 slaps pitti
<pitti> ouch
<pitti> seb128: what was that for?
<seb128> <pitti> zyga: iz GTK bug?
<pitti> seb128: oh, that one; SCNR :)
* pitti hugs seb128 
<seb128> pitti: I was away for some sport and diner, I'm catching up :p
* seb128 hugs pitti
<zyga> seb128: hi
<dholbach> olemke: what happens, if you run yelp from the terminal?
<seb128> hey zyga
<dholbach> olemke: can you paste the output in a query?
<zyga> I really don't know, could be an X bug too
<zyga> but I didn't manage to run anything, my laptop is dead
<zyga> :/
<olemke> dholbach, no output on terminal
<olemke> dholbach, what query?
<dholbach> olemke: ok, nevermind
<dholbach> olemke: i'm at a loss of words
<olemke> dholbach, ah got it now. :-) only output is that beagled is not running when searching for something, but i guess that's normal
<dholbach> yeah, I suppose so
<dholbach> olemke: i did a scrollkeeper update this morning, but I just added languages to it, no changes wrt to en_*
<olemke> dholbach, I'll have a look in my apt cache, probably the old scrollkeeper is still there
<seb128> I've the yelp issue on my box
<dholbach> seb128: what happens there?
<dholbach> seb128: which version of ubuntu-docs and scrollkeeper?
<seb128> dholbach: do you want me to debug?
<seb128> current
<seb128> scrollkeeper_0.3.14-11ubuntu5_i386.deb
<dholbach> ok, that's the old one
<dholbach> the one I didn't patch
<dholbach> ah no
<seb128> ii  ubuntu-docs    6.06.1         The Ubuntu Documentation Project
<dholbach> that's the one I patched already - sorry
<olemke> dholbach, i'm downgrading to 0.3.14-11ubuntu4 and see if that fixes it
<dholbach> olemke: thanks a lot
<olemke> dholbach, yes, that one works!
<dholbach> urg
<seb128> dholbach: downgrading to 0.3.14-11ubuntu4 works
<dholbach> URG
<seb128> dholbach: do you want me to debug that?
<olemke> *lol*
<dholbach> I have no idea what could have cause that
<seb128> dholbach: cf query
<olemke> i'll leave the debugging to seb128 :-)
<seb128> dholbach, mdke, olemke: I've a fix ready to upload
<seb128> mdz: http://people.ubuntu.com/~seb128/scrollkeeper.debdiff ok to upload?
<dholbach> seb128: thanks a lot.
<seb128> mdz: the scrollkeeper update from this morning dropped the C locale by mistake, that fixes it
<seb128> np
<mdke> kewl, thanks seb
<seb128> np
<olemke> seb128, great
<ciga> hi
<mirak> hi
<mirak> I am a bit tired by the nvidia driver from restricted modules that breaks after some upgrades. how is that possible ? isn't the restricted package bound to the appropriate kernel ?
<mirak> Error: API mismatch: the NVIDIA kernel module has the version 1.0-8756, but this X module has the version 1.0-8762.  Please make sure that the kernel module and all NVIDIA driver components have the same version.
<mirak> sorry
<mirak> mistake
<mdz> seb128: argh
<mdz> seb128: yes, ok to upload
<mdz> dholbach: how goes it?
<pitti> mdz: the two i386 buildds are still crunching through the langpacks :( (with all the other buildds idling around)
<dholbach> mdz: all seems to be good - i'm fixing up the community themes atm
<seb128> mdz: done
<dholbach> if somebody wants to test: http://daniel.holba.ch/ubuntu/ubuntu-artwork_28_all.deb
<mdz> pitti: I have resigned myself to the fact that we will not have working CDs until tomorrow
<dholbach> I'd be happy if somebody would look and check for obvious breakage
<mdz> dholbach: what's wrong with the community themes?
<seb128> is that going to be the dapper artwork?
* seb128 downloads that
<dholbach> mdz: referred to non existing icon themes (or stuff that had to be packaged) and I had a bug in the Makefiles
<mdke> dholbach: what sort of tests do you need?
<dholbach> i'm working on it high speed
<dholbach> mdke: install and check for missing icons or stuff that looks queer
<mdke> dholbach: ok :)
* mdz uses gdebi for the first time
<mdke> heh
<seb128> good idea
<zul> heylo
<seb128> dholbach: graphics, game, sound and video still look blury
<dholbach> seb128: we didn't get those in 48x48
<mdke> dholbach: is the menu logo supposed to be only about a third of the circle?
<dholbach> mdke: yes
<mdke> geez
<pitti> dholbach: cool, this becomes active at instant :)
<pitti> dholbach: yay for better close icons
<nomed> dholbach, gtkrc files shouldn't go in 
<nomed> gtk-2.0/gtkrc ?
<nomed> or not anymore ?
<seb128> pitti: that still looks ugly on close button
<pitti> seb128: but better than before IMHO
<seb128> pitti: no
<seb128> pitti: exactly the same for me 
<pitti> dholbach: System -> About Ubuntu still has this buttonish look, is that correct?
<seb128> pitti: open the theme selector by example
<seb128> pitti: restart your panel
<mdke> I can't get over the 1/3 menu icon... ughhh
<dholbach> pitti: kill the panel
<seb128> pitti: that's a coded entry, it's not updated dynamically
<seb128> hum, no, it comes from a .desktop
<seb128> but not updated dynamically ... :)
<pitti> seb128: right, big icons stay the same here
<seb128> notify bubble looks weird
<seb128> tool small icon on them
<mdke> close icons in gaim chat window still don't look like close icons
<seb128> we should really get that one delayed to after dapper
<seb128> still looks weird to gaim and gedit
<seb128> it's just better for epiphany
<mdke> yeah, confirm gedit too
<zyga> pitti: is there any way to help you with building langpacks?
<zyga> distdpkg-deb or something :)
<pitti> zyga: buy a third i386 buildd and quickly put it into the DC :)
<zyga> DC?
<pitti> data center
<zyga> I can do the former
<zyga> how fast do you use?
<zyga> pitti: bah, you were not serious
<pitti> zyga: oh, of course not
<zyga> I was :D
<zyga> langpack building is easy to parallelize
* pitti hugs zyga, sorry
<mdke> zyga: you are considering getting a new server into the datacenter in the next 24 hours or so?
<mdke> impressive
<zyga> mdke: I didn't say 24 hours but I could donate stuff I don't need
<pitti> zyga: right, but due to our current buildd machinery, they will only be built on i386 buildds
<mdke> zyga: that's kinda nice, but I think the langpacks are getting built now, and dapper is about to come out
<mdke> so pitti could only have been joking
<pitti> https://launchpad.net/+builds
<zyga> it'd be uber cool if we could somehow build langpacks for all languages daily
<robertj> Are those duck foot-prints on the new close icon for gedit & friends ;)
<pitti> zyga: already happening :)
<zyga> pitti: for *all* languages!?!
<zyga> :D
<pitti> zyga: https://lists.ubuntu.com/archives/ubuntu-translators/2006-May/000537.html
<pitti> zyga: yes, I changed it to build the complete set every day
<zyga> pitti:I read that mail
<zyga> nice, how long does it take to build the whole set?
<mdke> zyga: this one too? https://lists.ubuntu.com/archives/ubuntu-translators/2006-May/000567.html
<zyga> mdke: no, I've got 40 unread emails pending :/
<zyga> I'll go thru them tomorrow
<zyga> pitti: interesting host names ;] 
<seb128> the new distributor logo looks weird :/
<mdke> seb128: s/weird/terrible
<seb128> not that bad
<seb128> but I think I preferred the one with the border
<seb128> and that was already something :p
<zyga> is the ubuntu artwork on display somewhere?
<mdke> well, I think it should be consistent with the website and all other Ubuntu marketing and have the whole circle
<seb128> agreed
<dholbach> I'm fixing a last bug now, then I'll upload the package, so adventurous testers can have another look while I do a quick walk to get the dog out and fetch some candy somewhere - I need it badly now.
<dholbach> and after that I can do the upload 'for real'
<ogra> so does that mean we have an ETA for CD buiilds ? 
<zyga> dholbach: do you work at home?
<dholbach> zyga: yes
<ogra> "last bug" sounds promising
<ogra> err last upload indeed
<dholbach> ogra: yeah, installed the community ubuntu-art themes to the wrong directory
<mdke> ogra: don't worry... still another 10,000 or so to go
<ogra> ouch, but well, things donw in a hurry ....
<ogra> mdke, i hope you mean bugs
<mdke> lol
<ogra> i wouldnt want 10000 iso tests
<HiddenWolf> mdke: nearer 11k by now.
<zyga> hello sabdfl :)
<dholbach> ok, can you please test http://daniel.holba.ch/ubuntu/ubuntu-artwork_28_all.deb - I'm going for a 10-15 minutes walk now
* mdke tries it
<mirak> I am sure there is a problem with nvidia driver and kernel upgrade
<pitti> yay, langpacks have all built now
<LaserJock> \o/
<zyga> pitti: do you know if you can sucessfuly install dapper on a ppc alongside with latest osx?
<pitti> zyga: sure, that should work fine (does for me)
<zyga> pitti: what partition type did you use?
<zyga> I'm sorry to bother you with this it's just that I tried this several times and got no understanding of what's ultimatly wrong
<pitti> zyga: no special one, just what the installer creates
<zyga> (neither system sees the drive as partitioned after the other got installed)
<zyga> hmm, I choose hfs+ with journaling, case sensitive
<mdke> dholbach: gaim close button in chat window still bad, gedit seems a bit better, although still a bit small i think. Otherwise seems ok (apart from the distributor logo atrocity)
<mdz> " No pending builds for The Dapper Drake."
<ogra> YAY !!!
<LaserJock> mdz: time to open The Edgy Eft? ;-)
<ogra> ssshhh
<zul> ssh...dont mention the war
* LaserJock crawls back into his hole until after June 1 :-)
<mdz> LaserJock: that just means the last batch of stuff has all built
<mdz> s/last/most recent/
<mdz> we aren't finished yet
#ubuntu-devel 2006-05-30
<Kamion> vmware-player-kernel-2.6.15 FTBFS
<mdz> whee
<Kamion> I think I'd prefer to leave that one to mvo though - don't know how the interaction with the vmware packaging bods works
<Kamion> seems to be at least a missing Build-Depends: bzip2
<mdz> pitti: why did the langpacks take a substantial amount of time to build?
<mdz> Kamion: when do you come down to London; tomorrow?
<jono> hey
<pitti> mdz: because it's just two buildds that can build them ATM
<holycow> hey guys
<pitti> mdz: for the package itself, it takes some time to msgfmt all the PO files
<jono> hey
<holycow> any ubuntu / canonical people here?
<mdz> pitti: oh, I thought that was done in advance
<jono> holycow: usually quite a few
<mdke> holycow: define people
<holycow> would anyone know of any surveys detailing user satisfaction levels with linux/computers?
<holycow> lol :) sorry that was a leading to my question ... should of been a single line.
<pitti> mdz: for the sake of having real source packages I don't
<mdz> holycow: no, no ubuntu people here; they all hang out on #gnome
<ogra> mdz, huh ? 
<jono> :P
<holycow> mdz, eh, good point actually heh
* ogra leaves #gentoo then
<mgalvin> dholbach: that new artwork package works for me (was the legacy human stuff based on those packages I made or fresh artwork team work? (just wondering))
<Kamion> mdz: yes, tomorrow morning; I expect to get there around 11am
<mdz> Kamion: ok
<Kamion> mdz: showing up at the office, right?
<Kamion> (it's much cheaper to get a train after 9am)
<mdz> Kamion: if I only feel as close to death as I do now, then I'll be there.  if I'm worse, I may need to work from the hotel
<Kamion> I see. yay plague
<ogra> :/
<Kamion> well, I hope to see you tomorrow then
* Kamion -> bed; leaving vmware-player in NEW deliberately until vmware-player-kernel-2.6.15 is fixed
<HiddenWolf> Is there any way that I can unsubscribe from a bug in malone?
<LaserJock> HiddenWolf: i think you can if you go to the bug report
<mdz> the 'unsubscribe' button, or via email
<HiddenWolf> hm, i overlooked it then.
<LaserJock> you can't unsubscribe teams though, yet. AFAIK
<mdz> HiddenWolf: if you have further questions about it, please use #launchpad
<mdz> LaserJock: only by mail
<zyga> zyga -> bed
<zyga> night guys
<zyga> thanks for ubuntu :)
<mdz> (bug #30532)
<Ubugtu> Malone bug 30532 in malone "Unable to unsubscribe a team from a bug" [Critical,In progress]  http://launchpad.net/bugs/30532
<dholbach> mgalvin: I can't really tell - the ubuntu-art guys provided me with it
<dholbach> mgalvin: but thanks for your work on it
<mgalvin> dholbach: ok, no worries, was just curious since it seemd to pop up after my post ;), if it was based on mine then i am just glad to help :)
* dholbach high-fives mgalvin
* mgalvin high-fives dholbach
<dholbach> if you're all happy with it, I'll upload now. mdz, sabdfl: any other changes you want me to do now or other considerations?
<seb128_> dholbach: I think that the close button change should be dropped for dapper but that's probably not a decision up to you ...
<mdke> dholbach: maybe worth pinging henrik or something if the distributor logo is going to change: screenshot here needs redoing: http://www.ubuntu.com/desktop
<mdke> ah, 2 screenshots
<dholbach> urg, what a nice timing, holba.ch is offline
<Burgwork> mdke, /desktop looks good
<mdke> Burgwork: yeah, it does indeed :)
<mdke> Burgwork: do you do the screenshots? maybe you can redo those
<Burgwork> no, henrik did them
<mdke> ah, k
<mdke> well, he can redo em :)
<Burgwork> hmm, joel makes a good point about the logo on -desktop
<mdke> i didn't see that
<Burgwork> the mailing list. the distributor logo looks like a button
<sabdfl> https://chinstrap.warthogs.hbd.com/~mark/ulogo.png
<mdke> Burgwork: wait til you see the new one
<sabdfl> erk
<mdke> you're gonna hurl
<sabdfl> not sure how many people can see that
<sabdfl> mdke, that the one you are referring to?
<Burgwork> sabdf1, ah, us non-canonical people cannot see that
<ogra> Burgwork, https://launchpad.net/distros/ubuntu/+source/ubuntu-artwork/+bug/47260/+index
<sabdfl> i'm totally open to contributions
<Ubugtu> Malone bug 47260 in ubuntu-artwork "Distributor icon is ugly" [Normal,Confirmed]  
<Keybuk> sabdf1: only staff, copy it to rookery
<mdke> sabdfl: I can't see it. I'm referring to the one which is a 1/3 slice and looks like it has been failed to be resized appropriately
<sabdfl> the new one is 1/3 slice but properly done
<sabdfl> i've asked the artist to have a final stab with the full logo
<sabdfl> but - it always looks too fiddly
<mdke> sabdfl: but the website and all Ubuntu marketing has a whole circle as the logo... the one before the button was perfectly acceptable, IMO
<sabdfl> contributions welcome, in the next 8 hours :-)
<sabdfl> it was rather ugly, as an icon
<sabdfl> this is clearly part of the logo
<mdke> i know that last minute crack artwork is traditional, but it seems to me that it's getting changed just for the sake of it now
<Seveas> I loved it, was the best so fat
<Seveas> so far*
<Riddell> http://people.ubuntu.com/~jriddell/ulogo.png
* mdke shudders
<Burgwork> ugh, that is worse
<ogra> looks broken ...
<Seveas> much worse
<ogra> at least that will be what people will think
<Burgwork> I am left wondering where the logo went and whether of not I should resize my screen
<mdke> can we have at least "This is not the final artwork" written over it?
* ogra liked the plain old flt version most, we have enough *bling* everywhere 
<ogra> *flat
<Burgwork> ogra, I agree with you
* mdke switches to kubuntu on principle
<Keybuk> ogra: you can never have enough bling
<mjg59> sabdfl: Breezy shipped with a full logo rather than a gnome one, right? Is there a strong feeling that any of the changes offer significant improvements over that?
<Riddell> mdke: yay!
<ogra> Keybuk, so why dont we switch to Xgl quickly befor the CD building starts :P
<Burgwork> Riddell, might have me switching next. Then the world would trulyl end
<Seveas> ogra, Ublingtu 
<Keybuk> ogra: because I'm in the same hotel as mdz and he could break into my room and cut my balls off
<mdke> lol
<ogra> lol
<Seveas> haha
<Burgwork> Keybuk, would make less enjoyable, no?
<mdke> it's worth the sacrifice
<Burgwork> sabdfl, another concern I have is with copyright dilution. We should be careful to not hackup our logo too much
<Burgwork> s/copyright/trademark/
<sabdfl> that's true
<Burgwork> therefor, a plain simple Ubuntu logo works well
<sabdfl> but the point is still that our logo is unfortunately a bit delicate, and 24x24 (really 22x22) is not great for that
<sabdfl> it did NOT work well, i'm afraid
<Burgwork> it also isn't ugly and won't get you jumped at the next dev conference :)
<mdke> the one before the button was already an improvement over the breezy one, definitely
<ogra> we have even 16x16 in synaptic
<sabdfl> it always looked a bit cheap and nasty
<Seveas> sabdfl, what do you think is wronw with the one before the button?
<sabdfl> Seveas: the shadowing looked wrong
<Seveas> the one with shadowing was the one before that
<sladen> sabdfl: what happened to the really nice shiny logo (the one you had on your laptop during LinuxTag, which I remember commenting on)
<mjg59> I tended to agree that the sadowing looked slightly funny, but several people seemed to comment on it positively
<sladen> sabdfl: which could be further improved by dropping the shadow from near the bottom
<mjg59> (Which I can't say I understand, but, well)
<sabdfl> look, art gods, draw me the fricken' icon and send it to me for a decision
<sabdfl> i only picks them from what i sees
<sabdfl> if yous knows what i means
<sabdfl>  </goftather mode>
<sabdfl> erk
<sabdfl> so much for me as a mafia don
<ogra> heh
<Seveas> Don Marco
<Riddell> mdz: in a mood for one last guidance fix?  http://kubuntu.org/~jriddell/tmp/guidance.diff
<Burgwork> Riddell, how well does guidance seperate the qt bits from the underlying bits (ie, how easy would it be to tack a gtk frontend on it?)
<sabdfl> night all
<dholbach> i uploaded the package to http://people.ubuntu.com/~dholbach now
<dholbach> so if somebody wants to test it some more, that'd be great
<dholbach> i'm off to bed now
<dholbach> have a nice evening
<Riddell> Burgwork: it doesn't separate at all
<Burgwork> Riddell, hmm
<Riddell> Burgwork: although regardless they're probably much easier to port between frontends than gnome-system-tools :)
<Burgwork> hmm, indeed, plus in a nicer language
<Burgwork> that KDE and GNOME do not provide good config tools is a major shame
<Burgwork> that they don't work together on a common freedesktop.org set is even more nuts
<mjg59> sabdf1: Ha. I ended up getting a passport from a different country in order to avoid visa waiver hassles
<mgalvin> hmm, vmware-player in multiverse, nice
<Riddell> Burgwork: you're right in principle but abstracting for both distributions and frontends is never going to end up with nice code
<Burgwork> Riddell, no, you are right there
<Riddell> Burgwork: but what config tools do you think are missing?
<Burgwork> X,but also just thinking of the mess of the rh, suse, etc. shipping their own code
<sladen> win 194
<Burgwork> sladen, ?
<sladen> Burgwork: missing a /
<Burgwork> sladen, ah. What does that command do?
<Seveas> switch to window 194
<Seveas> sladen is insane
<Burgwork> Seveas, are you saying he has 194 windows open?
<Seveas> 194 or more
<mjg59> Burgwork: The X configuration pain is going to go away very soon
<Burgwork> mjg59, with better hotplugging on the X end?
<mjg59> Given that, right now, there's no standardised options namespace, a decent X config tool has to special-case every single driver
<mjg59> With magical dbus hurrah
<Burgwork> I like magic fairy dust
<mjg59> For great justice
<Seveas> X going dbus?
<Seveas> funky
<mjg59> And run-time configuration excellence
<Keybuk> *sigh*
<mjg59> RH are doing a lot of work on this right now
<Keybuk> dbus ... it's like IPC, only crappier
<Seveas> (c)Keybuk Advertisement Agency
<Robot101> where did the crappier bit come from?
<sladen> Keybuk: oh, but it's *simpler* than IPC.  "The _only_ requirement is an XML parser"...
<mjg59> X already has enough mad parsers that another doesn't matter?
<Keybuk> sladen: yes, this is the point I snort into my drink and cry "the world has gone MAD!"
* Keybuk is not a fan of dbus
<Seveas> I'm waiting for someone to create dbus over tcp to get upnp-like hell 
<sladen> Seveas: it exists.
<Keybuk> oh, I'm sure one day all web page accesses will be over dbus to a PornManager service
<Seveas> sladen, *shiver*
<Robot101> XML parsers? eh?
<sladen> Seveas: echo <listen>tcp:host=localhost,port=12434</listen> | sudo tee -a /etc/dbus-1/system.conf
<Seveas> sladen, no fun on localhost only
<Keybuk> Robot101: XML Configuration files are *the* in thing this season
<Seveas> open to the world by default 
<Keybuk> it's what all the good desktop environments are wearing
<sladen> except that you can't do that, you need to *parse* XML config file, then *insert* it into the right place
<sladen> Seveas: well change 'localhost' for 1.2.3.4 ...
<Seveas> wouldn't 0.0.0.0 work? I have a dynamic IP 
<Seveas> weird idea, managing your server via dbus-over-tcp/ipsec
<desrt> hmm
<desrt> macbook starts having random lockups
<Keybuk> tsk
<Keybuk> don't buy shint
<Keybuk> uh, shiny
<desrt> i wonder if they're heat releated
<Robot101> Keybuk: shint was closer to the desired word? :)
<desrt> it's obviously disk-related
<desrt> like the disc controller dies
<desrt> and if an app tries to touch disk it locks in D-state forever
<Keybuk> Robot101: allegedly so
<Keybuk> desrt: I like the PowerBooks, where they put the CD drive right under where most people's right wrist rests
<Keybuk> so after time, you crush the CD drive and it no longer wokrs
<robertj> Keybuk: I paid extra $150 for the black macbook, why isn't it working! It's not shiny!
<desrt> i have to say
<desrt> i'm fairly disappointed in apple wrt the macbook
<desrt> they didn't try very hard
<desrt> it runs bloody hot and it's _big_
<Burgwork> desrt, they don't have to. Apple fanatics would buy polished shit if Jobs said it was good for thek
<Burgwork> s/thek/them
<desrt> i'd gladly take a cut in speed if it meant that my laptop ran at a sane temperature, was stable, and had a longer battery life
<Burgwork> desrt, but they sold these things as 4x faster, not 4x as much battery life (something I would pay for)
<mdke> you do tend to get what you buy
<desrt> how about removing the bloody cdrom drive?
<mjg59> Probably the last conference season for my trusty X40
<desrt> apple has some pretty dumb ideas
<desrt> mjg59; my coworker was less than helpful today....
<mjg59> desrt: Mm?
<desrt> mjg59; about the backlight control stuff
<mjg59> Ah
<crimsun> mjg59: worn out from use?
<desrt> fwiw, backlight control _and_ sleep are supported in windows
<desrt> the trackpad is not
<mjg59> crimsun: Getting a touch knackered
<mjg59> It's been around the world a couple of times now
<bddebian> Howdy folks
<Seveas> gah
<Seveas> pkill -HUP gnome-panel kills xchat
<Seveas> stupid tray plugin
<Seveas> but anyway, I sent don marco a distributor-logo proposal :) 
<Seveas> http://www.ubuntulinux.nl/~dennis/logo/
<desrt> that's not the ubuntu menu icon anymore :(
<Seveas> it never was
<Seveas> I just created it
<ajmitch> afternoon
<FliesLikeABrick> the graphics in the log-out window (the nice big colorful ones) are all GPL, right?
<KaiL_> nice, that universe imports EVERYTHING from debian, but was it planned, to import it's kernel-images? ;)
<jdub> wow, some dude is recommending a UI that would let you enable DMA for a limited period of time
<tseng> jdub: is he recommending snorting crack cut with ajax?
<ajmitch> jdub: is that sounder thread still not dead?
<KaiL_> jdub, what should be the use of such an UI?
<jdub> punching users in the face, i guess... ;)
<bddebian> heh
<StevenK> Enable DMA for a limited time. Hrm, a big dial that has two points - "Slow I/O" and "Fast I/O" ?
<lifeless> StevenK: what about a spring
<lifeless> StevenK: you need to keep pushing it in to get fast io
<Mithrandir> can I have it in blue?
<bgertzfield> Does anyone know where I can see the Ubuntu buildd logs?
<KaiL_> lifeless, LOL
<bgertzfield> evidently Kamion mentioned the vmware-player-kernel-2.6.15 package had a FTBFS on the build machines
<bgertzfield> ah, found https://launchpad.net/distros/ubuntu/+builds
<bgertzfield> very nice
<Mithrandir> bgertzfield: https://launchpad.net/+builds/+build/200099 gives you a link to the log
<bgertzfield> Mithrandir: yep! just found it
<bgertzfield> /bin/sh: bzip2: command not found
<Mithrandir> that's not the kernel stuff, though
<bgertzfield> curses
<Mithrandir> build-depend on bzip2, then.  Should be trivial. :-)
<bgertzfield> https://launchpad.net/+builds/+build/200093 is the buildd log
<bgertzfield> I had no idea bzip2 wasn't essential (tar is...)
<bgertzfield> Mithrandir: how can I go about getting a new package to you folks asap?
<bgertzfield> mvo is handling the uploads, but he's asleep
<Mithrandir> bgertzfield: do you want to give us a new package yourself or should I just add the build-dep?
<bgertzfield> Mithrandir: I'd be perfectly happy if you just added the build-dep to vmware-player-kernel-2.6.15 (in a -4 revision)
<bgertzfield> but I'm happy to do it too
<Mithrandir> less hassle for me to do it myself, since I then don't have to comb the package for other things too.
<bgertzfield> I'd really appreciate that!
<bgertzfield> Mithrandir: you'll be pleased to see there are amd64 packages for this :)
<Mithrandir> bgertzfield: uploaded
<bgertzfield> Mithrandir: incredible! thank you
<Mithrandir> bgertzfield: nice. :-)
<Mithrandir> np
<Mithrandir> I didn't do a full test build, but I think it'll build just fine.  I'll keep an eye on it.
<bgertzfield> Mithrandir: I'll email mvo, Kamion, and yourself
<Mithrandir> cheers
<bgertzfield> Mithrandir: I'm sure it'll be good.  The whole build succeeded except the bzip2 (groan) :)
<Mithrandir> yeah, builds are picky that way.
<Mithrandir> (also pbuilder testing good.)
<Mithrandir> now I have to get some breakfast.
<bgertzfield> pbuilder is a buildd simulator of sorts?
<bgertzfield> thanks again. I'll use pbuilder next time
<Mithrandir> pbuilder builds in a chroot and only installs the build-deps + Essential: yes, Priority: required and build-essential
<bgertzfield> got it. makes sense
<tseng> hi Mithrandir 
<bgertzfield> will use it next time; last time I did a lot of Debian packages (che@debian.org :) was before that existed
<Mithrandir> yeah, Junichi wrote it just a few years back, iirc.
<Mithrandir> hiya yse
<Mithrandir> uh
<Mithrandir> hiya tseng 
<tseng> good one
<bgertzfield> yeah
<Mithrandir> so much for misaligned fingers and tab-completion
<bgertzfield> hm
<bgertzfield> wait a sec, why is vmware-player-kernel-2.6.15 trying to build on sparc?
<ajmitch> morning Mithrandir 
<bgertzfield> oh, it was trying to build the architecture-independent package (the kernel source) -- it also failed for the missing bzip2 dependency
<bgertzfield> never mind. :)
<bgertzfield> I'm pretty sure that's okay
<Mithrandir> bgertzfield: it's supposed to be masked off.  Anyway, you don't support sparc, so no need to fix that before release.
<bgertzfield> the architecture-dependent binary packages are masked off correctly
<bgertzfield> it was just trying to build the m-i source .deb
<Mithrandir> no, since that's, iirc, done in Packages-arch-Specific which is a file handled by the buildd people.
<bgertzfield> oh!
<bgertzfield> I see
<Mithrandir> infinity: ^^ correct me if I'm wrong
<bgertzfield> yeah, I was wondering who handled that
<bgertzfield> anyway, I truly appreciate how flexible all the Ubuntu folks have been
<Mithrandir> np
<Mithrandir> :-)
<bgertzfield> I'll be furiously hitting my web browser's "reload" button on the buildd log ;)
<Mithrandir> it needs to be published first, which is a process that starts at about :02 and ends ~20 minutes later before it'll start building
<Mithrandir> so I'd recommend getting yourself a cup of coffee, tea or similar first.
<bgertzfield> I see. good timing for us then
<bgertzfield> I will go for "similar". :D
<Mithrandir> I'm off for a bit, see you later.
<pitti> Good morning
<bgertzfield> howdy
<glatzor> ping mdz
<bgertzfield> Woo hoo!!
<bgertzfield> i386 build of vmware-player-kernel-2.6.15 2.6.15.10-4 in ubuntu dapper
<bgertzfield> Requested 2006-05-30 05:40:02 UTC in pocket RELEASE
<bgertzfield> Built 2006-05-30 05:45:03 UTC by vernadsky (i386) in two minutes
<bgertzfield> Mithrandir: Thanks so much.
<bgertzfield> OK, off to bed.
<highvoltage> Seveas: i like the monthly update iso idea too
<mvo> Kamion, mdz: I would like to upload a new app-install-commercial-data (small package, only data file changes). is this still ok?
<pitti> infinity: ping
<infinity> pitti: Good morning.
<pitti> infinity: it seems that yesterday's uploads (langpacks, other pkgs, whatever) used up the 5 MB margin and filled the CDs up to the rim; the ppc one is 702 MB, but there is no oversized tag - which is wrong, the missing tag or the size?
<pitti> infinity: good morning
<infinity> Mithrandir: Thanks for taking care of the vmware-player-kernel FTFBS.  You're a champion.
<Mithrandir> infinity: np
* mvo hugs Mithrandir
<Mithrandir> bgertzfield: yay. :-)
* Mithrandir hugs mvo back
<infinity> pitti: You'd have to ask Kamion, who's got the exact size memorised because he's a freak, but 702MB is probably not quite oversized yet.
<pitti> infinity: but in theory, the .OVERSIZED tag should be correct?
<pitti> (and its absence)
* pitti hugs dholbach 
* mvo \o/ dholbach
<dholbach> hello pitti - hello everybody
<dholbach> heya mvo
<infinity> pitti: That's a fine theory, yes.  I'll not commit to that, since I don't know the debian-cd internals as well as Kamion or Sledge. :)
<Kamion> Mithrandir: you hacked vmware-player-kernel-2.6.15's debian/control instead of debian/control.in
<Kamion> (although it built anyway)
<Mithrandir> Kamion: autogenerated control.ins are teh suck.  (I didn't even see the control.in)
<Mithrandir> s/in//
<Kamion> pitti: max size is 736051200 (see http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/bin/publish-daily - I let my scripts memorise things for me)
<Kamion> pitti: but for install CDs, you need to search for "CD 2 will only" in the build log too, to make sure debian-cd didn't try to overflow to a second CD
<pitti> Kamion: so 702 MB would actually be okay?
<pitti> Kamion: right, I know, the install CDs are fine
<Kamion> yes, the current powerpc live CD is about 400K inside the limit
<pitti> Kamion: ok; I can still upload a new -meta to fix the ia64 overflow
<Kamion> mvo: what's the app-install-commercial-data change?
<Kamion> pitti: erk, it's late for that, but ok
<mvo> Kamion: it add a vendor with a 3rd party repository (omnis webstudio)
<mvo> Kamion: only data files, 9kb package
<Kamion> mvo: that sounds like it can be done in -updates
<pitti> Kamion: since we have to roll new CDs anyway... (but I don't have to, was just a proposal)
<infinity> Kamion: New artwork's still being done anyway, so as long as the new app-install-data and ubuntu-meta beat the artwork in, no harm done.
<Kamion> pitti: if it's before the next cron.daily ...
<Kamion> infinity: oh, point
<Kamion> mvo: ok, do it quickly
<pitti> Kamion: alright
<mvo> Kamion: it is ready now,  will upload now
<mvo> Kamion: thanks
<crimsun> Kamion: are uploads to universe still acceptable for issues like "segfaults on start but trivial patch fixes it", or is that more -updates material?
<dholbach> crimsun: that kind of stuff is ok
<crimsun> dholbach: ok, just wanted to check before I uploaded, thanks
<dholbach> thank you
<infinity> Can anyone who's awake quickly install http://people.ubuntu.com/~dholbach/ubuntu-artwork_28_all.deb then log out and log back in and let me know if it's buggy in any way?
* pitti installs
<infinity> There's a certain sense of urgency on this one. :)
<Burgundavia> infinity, menus appear fine. I see you changed a few logos :)
<infinity> I did no such thing, this is more sabdfl and dholbach work. :)
<infinity> But it's also the final ubuntu-artwork package, if it seems to work.
<pitti> infinity: yay for the old distributor logo
<Mithrandir> infinity: seems to work for me.
<infinity> Anyhow, looks good on my end, except for the "tab close" bug that I think we're resigned to not having fixed before we release.
<mvo> infinity: the tab close button in gedit?
<infinity> Oh, yay, the "stop" icon isn't flat anymore, either!
<infinity> mvo: gedit, gaim, epiphany, notification bubbles, etc.
<mvo> yes, that looks ... not nice
<Burgundavia> infinity, I see no visual flaws with menus, logout, and any apps that use gnome icons
* infinity is happy to see that the new "stop" icon makes gaim's "block" action look less crap.
<infinity> Anyone else?
* mvo has installed it as well, it looks ok
<infinity> Okay, I'll wait for more success stories and/or bug reports until 08:00 UTC, then I'll upload to make cron.daily.
<pitti> infinity: I can't see any obvious breakage
<G0SUB> pitti: hello!
<pitti> hello G0SUB 
<G0SUB> pitti: I guess you are my mentor for SoC?
<pitti> G0SUB: indeed I am :) I'll send you an official introduction mail today
<G0SUB> pitti: that's great
<G0SUB> pitti: I will start working on the design from today ... will put up my ideas on https://wiki.ubuntu.com/OfflineUpdateSpec/DesignDiscussion
<pitti> G0SUB: sounds good! thanks
<G0SUB> infinity: why did the logout option disappear from System menu?
<G0SUB> pitti: ok
<pitti> G0SUB: !
<pitti> G0SUB: it's still here for me; the only thing that vanished a while ago is the Lock Screen item
<G0SUB> pitti: I don't see either
<triceratops> infinity: are you aware of bug #47371 (fglrx API ERROR). I'm asking because I'm not sure if it's worth filling a bug report against restricted modules itself..
<G0SUB> pitti: my dist-upgrade is a couple of days old though, may be it came back
<Ubugtu> Malone bug 47371 in Ubuntu "Can't start openoffice or blender after update to dapper" [Major,Unconfirmed]  http://launchpad.net/bugs/47371
<infinity> G0SUB: It turned into "Quit..."... Do you not have that?
<infinity> pitti: How's that -meta upload going?
<G0SUB> infinity: I can see that, but logout in that menu would need fewer keystrokes for me
<pitti> infinity: uploaded some minutes ago
<G0SUB> infinity: may be it's better for many people. it's fine
<G0SUB> btw, the update notifier icon looks out of the place ... it's not at all Tango-ish
<infinity> triceratops: Curious.  It works here, with lrm-686 and the latest fglrx.
<jdub> hrm, who was it that updated wine yesterday?
<jdub> 17:42 < tigert> hmm
<jdub> 17:42 < tigert> wine stopped working on my dapper
<jdub> 17:42 < tigert> interesting
<jdub> 
<infinity> triceratops: Maybe someone just needs to reboot after having installed the latest LRM to get the kernel and X driver to match?
<infinity> G0SUB: Yeah, I'm not too happy with the update-notifier icons either, but at least they're not buggy/broken, so we can ship with them.
<infinity> G0SUB: Now's not the time to whine about bad art, just bitch loudly about anything that's actually BROKEN. :)
<G0SUB> infinity: yes, I agree. it's solid, so it's fine
<jdub> sladen: PING
<jdub> 17:50 < tigert> $ wine GNC400WT.EXE
<jdub> 17:50 < tigert> err:ntdll:RtlpWaitForCriticalSection section 0x7fced940 "syslevel.c: Win16Mutex" wait timed out in thread 0009, blocked by 000a, retrying (60 sec)
<jdub> worked before yesterday's update
<jdub> http://librarian.launchpad.net/2974258/wine_0.9.9-0ubuntu2_i386.changes
<jdub> 17:50 < tigert> picasa also stopped working
<jdub> (picasa ships its own, so... hrm...)
<crimsun> infinity: 28 looks fine to me, no regressions from 27
<infinity> Okay, new (and hopefully final) ubuntu-artwork uploaded.
<jdub> heh
<jdub> dholbach: "- updated." -> stikes fear into the heart of u-a lovers. ;-)
* ..[topic/#ubuntu-devel:infinity] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Release preparation in progress: https://wiki.ubuntu.com/DapperReleaseRadar | Upload Queue closed, ping infinity if you need a non-main upload massaged through
<infinity> And now we begin with this whole business of releasing an OS....
<triceratops> infinity: Back again... fglrx error apears after reboot.
<infinity> triceratops: Bizarre, but not something I can do anything about before release, unfortunately.
<infinity> triceratops: Even more bizarre that I'm running identical packages to at least one person commenting in the log, and don't see the bug.
<mvo> wb dholbach
<triceratops> infinity: linux-restricted-modules-2.6.15-23-k7 ?
<infinity> triceratops: You never had the ATI packages installed at any point, did you?  That could lead to breakage due to files going missing, etc.
<dholbach> thanks mvo
<infinity> triceratops: No, I'm using -686, but so was one of the followup comments.
<infinity> dholbach: -artwork uploaded, for better or worse.  This is it.
<triceratops> This is on a dapper machine and fglrx works till the last upgrade..
* dholbach hugs infinity
<infinity> triceratops: I get that.  There's also nothing I can do about it right now.
<infinity> triceratops: I'll follow up to the bug post-release, and we'll see if there's anything I can fix in dapper-updates, but for now, this is it.
<infinity> triceratops: Note that, like I said, it does work for me, and a large number of other who tested it for me, so I suspect some sort of curious local breakage.
<triceratops> infinity: I don't think it is a local brakage due to the fact thatz it is a test machine I installed last sunday from the latest dayl build iso and only did tthe last upgrade
<triceratops> infinity: anything I can do to give you more input to trace this?
<infinity> triceratops: Probably, but it'll have to wait until June 1.  Seriously.  Changes to dapper are closed.
<infinity> triceratops: What model card do you have in that machine?
<triceratops> infinity: Ok, I'll be back on thursday. BTW which timezone is yours? :-))
<infinity> triceratops: There are reports of breakage on older (r200, aka 9200 and friends) cards.  It's an upstream bug.
<triceratops> infinity: R200 514D, Radeon 9100
<infinity> triceratops: Of course, the new driver fixed problems on some newer cards, so it's a catch-22.  Can't make everyone happy. :/
<triceratops> infinity: Grumble, damned proprietary sh...
<triceratops> infinity: nevertheless, thanks a lot. bye
<sivang> re all
<pitti> hi sivang 
<pitti> hey seb128 
<seb128> Hey pitti
* dholbach hugs seb128
* sivang hugs seb128 , dholbach , pitti 
<infinity> pitti: Should openoffice-l10n have a source-level seed in supported, so the binaries don't show up in anastacia?
<infinity> pitti: http://people.ubuntu.com/~cjwatson/anastacia.txt
* infinity needs to run to the store to buy snacks and CD blanks before this party kicks off.
<infinity> CD images will start building in ~60 mins, after a build-and-publisher cycle.
<\sh> moins
<infinity> (And I should be back by then)
<pitti> infinity: actually, they should be dependencies of language-support-*
<seb128> did we get stock close and distributors icons fixed?
<pitti> infinity: however, these packagages seem to have appeared just recently
<infinity> seb128: Distributor, yes, the "tab close" thing is deferred to -updates. :/
<infinity> pitti: Well, -l10n was FTBFS until just over a week ago.
<pitti> infinity: if you are fine with that, I'll upload new l-support-* packages for them (they aren't on CDs)
<seb128> infinity: "deferred"? why don't reverting?
<infinity> seb128: Ask the sab, dude.  Not me.
<seb128> that's a mistake we are doing ...
<infinity> pitti: Yes, please do.
<seb128> all those liveCD will look ugly :/
<infinity> Keybuk: Here's your big chance to drive the manual-queue on pitti's language-support uploads. :)
* infinity heads out for CD blanks and brain food right now.. Back in ~60.
<Kinnison> pitti: do you need me to do a mass upload of langpacks?
<infinity> Kinnison: No, no.  langpacks are finalised.  He's just fixing some metapackages.
<Keybuk> infinity: gee, thanks
<Kinnison> infinity: oh righty
<sladen> jdub: pong
<infinity> Keybuk: If nothing else is in incoming (which should be the case), you can just cheat and run lp_queue's disabled cronjob by hand, instead of doing the move/process/move thing.
<pitti> Kinnison, infinity: I don't mind uploading the l-support-* packagages directly; it's not that many, and the changelog might be useful to someone
* Kinnison nods pitti
* infinity is gone.
<mdz> pitti: more language-support updates?
<sladen> jdub: oh joy.  ta.
* \sh looks around in his office, and is seeing many people waiting for ubuntu/kubuntu/ubuntu-server release 
<pitti> mdz: infinity just pointed me to the number of new help and l10n packages which appeared some days ago (sorry, I wasn't aware of them)
<pitti> mdz: however, they aren't on CDs, so should be uncritical
<Mithrandir> aiee, mixing of english and norwegian text in "about ubuntu". That looks _really_ bad.
<mdz> ogra: have you verified the fix for bug #46426 in a recent CD build?
<Ubugtu> Malone bug 46426 in ltsp "Xubuntu install CD install ltsp" [Normal,Fix released]  http://launchpad.net/bugs/46426
<sladen> can somebody do  grep -c wine /etc/mailcap   It appears that  dh_installmime  didn't run 'update-mime' on postrm
<sladen> (at least on this laptop)
<jdub> sladen: don't worry, that wasn't it
<jdub> sladen: talk to tigert on #gnome-hackers to make sure
<mvo> hello Riddell, are you around? I was wondering if the dr-konqui has a external program that you can run "wrap around" a normal application and catch SIGSEGV (gnome has gnome_segv for this)
<pitti> Keybuk: I'm ready to upload the updated l-support-* stuff, can I just dput them?
<pitti> Keybuk, infinity: uploaded; to packs do not match a valid locale, so we need to see them manually (I'll do that now)
<infinity> Okay, back with brainfood.
<pitti> erm, s/see/seed/
<Keybuk> pitti: yes, you can just dput
<Keybuk> of course, _I_ would have uploaded them all at once, rather than individually :p
<pitti> Keybuk: ?
<pitti> Keybuk: oh, that's just how langpack-o-matic does it right now
<Keybuk> ls ... *zoooom* ... ok, so I need less
<infinity> yay for 8 rejects...
<Keybuk> yeah
<infinity> ./rejected/upload-20060530-094824-005547/language-support-ar_6.06+20060413_source.changes
<infinity> ./rejected/upload-20060530-094825-005550/language-support-km_6.06+20060413_source.changes
<infinity> ./rejected/upload-20060530-094826-005552/language-support-lo_6.06+20060413_source.changes
<infinity> ./rejected/upload-20060530-094826-005554/language-support-lv_6.06+20060413_source.changes
<pitti> infinity: known bug
<infinity> ./rejected/upload-20060530-094827-005556/language-support-mk_6.06+20060413_source.changes
<infinity> ./rejected/upload-20060530-094828-005558/language-support-ml_6.06+20060413_source.changes
<pitti> but cosmetical
<infinity> ./rejected/upload-20060530-094828-005560/language-support-ne_6.06+20060413_source.changes
<infinity> ./rejected/upload-20060530-094830-005564/language-support-sl_6.06+20060413_source.changes
<infinity> pitti: ^^^
<infinity> Err, what? :)
<infinity> Rejected uploads are cosmetic bugs?
<pitti> infinity: bug 44186
<Ubugtu> Malone bug 44186 in soyuz "language-support-* upload generates rejected mail for old version" [Normal,Unconfirmed]  http://launchpad.net/bugs/44186
<pitti> infinity: the curent version is accepted, and this ancient one from 0413 keeps being rejected on every new upload
<mdz> bizarre
<Keybuk> oh wow
<infinity> Oh, that's weird.  I didn't even check the timestamp or version.
<infinity> Though it was a fresh entry in the upload queue.
<Keybuk> he's right, he never uploaded those rejected packages
<infinity> That's awesome.
<Keybuk> rejects ... "rm -rf *" ... what rejects
<sladen> OMG, yet-another-aweful-menu-icon-logo  *sigh*
<pitti> infinity: ok, I seeded the remaining two oo.o-l10n-* packagages which do not fit into any l-support-*, so anastacia should be clean again
<infinity> pitti: Thanks, you are The Man.
<mvo> where would be a good place to ask why python seems to be unable to catch SIGSEGV (with the signal modul) - is there a python channel?
<Keybuk> mvo: uh... POSIX?
<infinity> mvo: I find that whining at spiv gets all my python questions answered.
<mvo> Keybuk: #POSIX ;)
* mvo will try to whine at spiv
<sivang> mvo: gjc and jhdalin might know in #pygtk, they helped me greatly in my subprocess questions in HUB
<mvo> Keybuk: can you elaborate please?
<Keybuk> mvo: there's conditions on how and when you can catch SEGV isn't there?
<Keybuk> I may be confusing SEGV and KILL though
<infinity> You may be.
<mvo> Keybuk: hm, I guess I need to look into my stevens again, but I was though it was KILL
<Kinnison> Keybuk: IIRC you can't catch SEGV from a SEGV
<Kinnison> SEGV is very catchable
<Treenaks> Kinnison: if the first thing you do in the handler is to reset the handler..
<Kinnison> Treenaks: true
<mdz> infinity: this publisher run should bring everything into sync, yes?
<infinity> Okay, NEW queue is empty, anastacia is empty, and we're on the last publisher run required for CD images...
<infinity> mdz: See above. :)
<Keybuk> ah, no, you can catch SEGV just don't return from the signal handler
<Keybuk> I was confusing SEGV and KILL
<infinity> Okay, all CD-related cronjobs are disabled.
<infinity> The entire DC is in manual mode, now... 
<infinity> (That's right, elmo has to type all downloads, bit by bit, so be patient)
<sivang> poor elmo 
<sivang> ;-)
<Znarl> ...I hope he doesn't delegate this.
<infinity> Znarl: You can't type at 1Gb/s?
<sivang> lol
<Treenaks> infinity: keyboard repeat++
<Znarl> infinity : I start to typo at around 800Mb/s
<infinity> Znarl: Poor flow control?
<\sh> I wonder if we get the possibility to create an ubuntu/kubuntu mirror here in our DC...20GBit/s is the highest bandwidth for one internet service company here in .de
<Znarl> \sh : join #ubuntu-mirrors if you need assistance setting it up.
<ogra> mdz, i havent verified bug 46426 (got no xubuntu CD here) but janimo can
<Ubugtu> Malone bug 46426 in ltsp "Xubuntu install CD install ltsp" [Normal,Fix released]  http://launchpad.net/bugs/46426
<janimo> ogra: this was reported fixed for RC
<janimo> oh I tested Rc too and it was gone
<ogra> good
<janimo> ogra: I got no feedback from the xfce /ltsp testers yet
<infinity> Let the CD making begin!
<fabbione> infinity: did the last publisher run?
<ogra> excitement !
<fabbione> infinity: are we in manual mode now??
<infinity> fabbione: We're manual now.  I'm spinning CDs as we speak.
<fabbione> infinity: ok.
<jsgotangco> great anticipation, intense moment!
<infinity> A (very long) drum roll, please!
<Mithrandir> sfllaw: why isn't the date for the current DVD on testing/short updated?
<Mithrandir> s/short/current/
<infinity> Mithrandir: Can we get the tables completely cleared and update the build number to 20060530.1?
<infinity> (At least, I think they'll all have the build number when I'm done)
<Mithrandir> infinity: you're doing DVD builds too?
<infinity> Okay, not everything will.  Some will be 20060530
<infinity> I'll let you know as they roll in. :)
<infinity> Mithrandir: Yeah, I'll do DVDs last.
<\sh> Singing: It's the final countdown...(Old 80ties Europe song, for those who were not born these days)
<infinity> (To make them match the livefses)
<Mithrandir> ok, I'll twiddle my thumbs and watch the logs, then
<infinity> Oh, cute, soyuz sends the accepted mail to the GPG signer.  Never noticed that before.
<infinity> Guess I've never sponsored someone else's upload since the switch.
<infinity> Or I just don't pay attention.
<sivang> \sh: one of my favorites
* sivang wonders how the fish that can give you an electric hock is called in correct english
<sivang> shock, een
<sivang> even, even
<Mithrandir> sivang: electric eel?
<sivang> Mithrandir: thanks
<Mithrandir> at least I think they can.  Maybe others can too
<\sh> you know guys, I'm totally on crack...I'm compiling an ubuntu kernel on a sles9 box, and packaging all the crack into an rpm, for having a good working and running kernel...I'm mentally ill somehow
<infinity> \sh: Why compile it again?  Just tear apart the binary package and re-pack it as an RPM.
<infinity> \sh: Then you'll know it's identical.
<G0SUB> infinity: the latest ubuntu-artwork rocks big time ... it's awesome
<infinity> (Reminds me of the scary "identical deb and rpm" method of calling debian/rules from the .spec file..)
<sivang> ohh
<sivang> that sounds like horror
<infinity> Works pretty weell, actually, just it LOOKS just plain wrong.
<sivang> I bet it feels wrong as well
<sivang> (when doing it)
<Gloubiboulga> ogra, janimo, highvoltage has tested a daily xubuntu build (alternate install) iirc, and asked for ltsp installation... which fails
<janimo> Gloubiboulga: oh sad :(
<janimo> how does it fail?
<janimo> highvoltage: ping ^
<Gloubiboulga> janimo, unable to configure the chroot I think
<Gloubiboulga> janimo, bug #47278
<Ubugtu> Malone bug 47278 in ltsp "Xubuntu chroot building fails on daily install" [Major,Unconfirmed]  http://launchpad.net/bugs/47278
<janimo> Gloubiboulga: thanks
<\sh> infinity: because I packaged my first kernel rpm package...just for the fun of it..time is money ;)
<dholbach> Gloubiboulga, janimo: you guys didn't rebuild the tang* packages and didn't do the icon-naming-utils patch - i fear it might be too late soon
<janimo> dholbach: it's ok
<dholbach> Gloubiboulga, janimo: but I daresay you have more pressing matters
<pitti> infinity: you know that u-artwork on at least the latest (30.1) altearnate CD is still at 27?
* Kamion arrives in Canonical HQ
<infinity> pitti: Don't say that.
<pitti> Hi Kamion 
<Keybuk> Kamion: hi!
<janimo> dholbach: any matter in particular or just release pressure in general?
<pitti> infinity: jigdo didn't download *any* new package compared to 30, I verified the md5sum, and the file list
<dholbach> janimo: no, I just thought you're busy with more important stuff :)
<pitti> infinity: same for ppc
<janimo> dholbach: yup
<infinity> /pool/main/u/ubuntu-artwork/ubuntu-artwork_27_all.deb
<infinity> Argh.
<\sh> hmm...to enabled selinux via kernel parameter, I need to feed the kernel append line the "selinux=1" parameter?
<pitti> ubuntu-artwork |         27 | http://archive.ubuntu.com dapper/main Packages
<pitti> ubuntu-artwork |         28 | http://archive.ubuntu.com dapper/main Sources
<infinity> Kamion: Is lithium not doing the pre-build mirror run properly?
<pitti> infinity: ^ seems it wasn't yet published?
<ajmitch> \sh: correct, and then watch everything still not work :)
<infinity> pitti: It was published a good 10 minutes before I kicked off the build.
<Keybuk> ubuntu-artwork |         28 |        dapper | source, all
<Keybuk> infinity: sure? :p
<infinity> Keybuk: Yes, positive.
<infinity> Keybuk: It was published around half an hour ago, the 30.1 build was started 5 or 10 minutes after that.
<Keybuk> it's not in the published archive
<infinity> Err, of course it is.
<infinity> source, all
<infinity> It's an arch:all package.
<Kamion> infinity: only reason it would skip the mirror run is if there was another build in progress (or it thought there was)
<infinity> Oh, feh.  The publisher crashed.
<Keybuk> ahh
<infinity> Danm it all to...
<Keybuk> yeah, it's sitting the pool
<infinity> I only looked in the pool during the publisher run, I didn't actually check the publisher's logs to make sure it, y'know, did its job.
<infinity> Feh.
<\sh> ajmitch: ok
<ajmitch> \sh: init won't load the policy, and you need newer userspace tools/libs to work with the newer reference policy
<infinity> Okay, that's messed up.
<infinity> The log doesn't show it crashing.  It shows the deb being added, and apt-ftparchive running...
<infinity> And then we don't get it published.
<infinity> But nothing from that run actually got in.. -meta didn't either.
<ogra> whee, there is CC meeting this evening ? 
<infinity> Double-U Tee Eff.
<Kamion> ogra: in theory ...
<ogra> yeah, but thats an optimistc theory :)
<Kamion> infinity: sounds like the mirrors are screwed; Packages on drescher is correct
<Kamion> Znarl: help
<Kamion> ubuntu-artwork |         28 |        dapper | source, all
<infinity> Kamion: But lithium mirrors from drescher, no?
<Kamion> nope, from syncproxy
<infinity> Ahh, kay.
<infinity> I use ftpmaster.internal for the livefs builds...
<Kamion> see cdimage/etc/anonftpsync
<infinity> And they look correct, so I don't have to re-do them.  Phew.
<Kamion> switching to ftpmaster.internal would mean I'd have to sort out ports exclusion and crap
<infinity> So, when the mirror issue is sorted, we can just do ISOs.
<infinity> Kamion: Or just have one mirror on drescher, instead of the main and ports mirror?
<infinity> Kamion: What's the harm in having a unified mirror?
<infinity> Kamion: It's not like hppa debs are going to jump onto an i386 CD...
<infinity> Err, so/on drescher/on lithium/
<Kamion> right, but let's not change it over *now* ...
<infinity> That sentence makes way more sense without that thinko.
<infinity> Kamion: No, no.  Not now.  Just saying "sometime".. :)
<Kamion> ftpmaster.internal seems to require auth for rsync
<Kamion> guess it needs configuration to allow lithium
<infinity> Kamion: Easily fixed, though.
<infinity> Znarl: Daaaa-aaaad!  Our toy is brooo-oooken!
<\sh> ajmitch: well, it was booting without any problems right now...lets see what our security guy is doing
<Kamion> infinity: you did fix that debconf/frontend issue with livecd-rootfs, didn't you?
<infinity> Kamion: Yes, though untested.
<Kamion> ok
<infinity> Kamion: Should be fixed on current dailies (and the build we're about to do), if you want to make a note to check that in your testing.
* Kamion nods
<infinity> Kamion: Do you want to drive lithium for alternate build when you're sure the mirroring situation is sorted?
<infinity> Kamion: I'll keep babysitting the world of live/desktop.
<infinity> s/build/builds/
<Kamion> infinity: sure
<Kamion> pitti: libextractor is funny
<Kamion>      - no longer using xpdf code: Christian wrote a PDF extractor himself, so we
<Kamion>        do not longer import security problems from xpdf.
<Kamion> OUR ONE WON'T HAVE ANY SECURITY PROBLEMS
<infinity> To be fair, it's hard to have as many security problems as xpdf has had.
<infinity> 20 monkeys, 5 typewriters, and a case of scotch could produce safer code.
<ajmitch> \sh: oh it'll boot fine, just without having a policy
<\sh> ajmitch: we are creating a policy by ourself ;)
<Kamion> dholbach: did you ever check out kleansweep for bug 40126?
<Ubugtu> Malone bug 40126 in Ubuntu "Dapper AptGetOrg import." [Normal,In progress]  http://launchpad.net/bugs/40126
<ajmitch> \sh: that's great, but with what tools?
<dholbach> Kamion: not yet - looking now
<dholbach> Kamion: let's drop that one
<dholbach> Kamion: thanks for your work and for reminding me
<\sh> setools, if this is not working I'm compiling new versions somehow...let's see what we find out :)
<ajmitch> \sh: you'll have to, and you'll probably end up having to get new libs, including ones that live in the initramfs, recompiling init, etc :)
<ajmitch> \sh: hence why it didn't make feature freeze
<Kamion> dholbach: ok, can I close the bug out then?
<dholbach> Kamion: yeah
* dholbach hugs Kamion
<sladen> mjg59: which package is /sbin/pccardctl in?  It's unconditionally called from acpi-support but it's not installed (this machine, or the bug reporter's)
<infinity> (base)adconrad@cthulhu:~/x/xorg-7.0.0$ dpkg -S /sbin/pccardctl
<infinity> pcmciautils: /sbin/pccardctl
<mdz> janimo: thanks for confirming, DRR updated
<janimo> highvoltage: ping
<highvoltage> janimo: pong
<janimo> highvoltage: hi, I just saw the ltsp but today
<janimo> as I was not subscribed
<janimo> was there anything else in /var/log/installer?
<highvoltage> janimo: no, there wasn't
<highvoltage> janimo: ogra told me to include it if it exists, but it didn't
<janimo> I don;t think I can debug this having never installed a ltsp server
<janimo> or anything ltsp for that matter
<highvoltage> janimo: i can rsync again, and test if it happens again today
<janimo> highvoltage: nothing changed since yesterday AFAIK
<highvoltage> janimo: ogra had an idea what it was about, apperently the same problem came up in edubuntu
<janimo> was the computer connected to the net?
<janimo> just in case some packages were missing froom the CD
<highvoltage> no, it wasn't
<highvoltage> hmmm.. perhaps that was the case.
<highvoltage> ogra: ping
<janimo> Kamion: do you know if for the packages you added manually (as opposed to in the seeds) for the ltsp xfce menu, the deps are also included?
<janimo> if not that may be the case. Since I found out recently that ldm depends on gnome libs, so if they are not installed the whole thing might fail
<highvoltage> hmmm.. i think you should ping ogra as soon as he's available. i think he could provide some insight there. in the meantime, i'll so an installation again, and check the output on the other tty's, i was too much in a rush to think about checking that yesterday
<\sh> ajmitch: you just agreed to help me with selinux...thx ;)
<ogra> janimo, the only intresting bit to debug the client builder itself is /var/log/instakller/messages, indeed /var/log/installer/syslog might have additional info but thats from the installer, not the client-builter itself...
<janimo> highvoltage: thanks
<ogra> highvoltage, i'm available since some hours :)+
<highvoltage> ogra: okay :)
<Kamion> infinity: FYI, I think we might have to respin for bug 46961 anyway
<Ubugtu> Malone bug 46961 in ubiquity "Gparted should return "1 Cancel" when its operation fails" [Normal,Unconfirmed]  http://launchpad.net/bugs/46961
<Kamion> janimo: they're in the ship seed, so germinate will take care of that
<highvoltage> ogra: can you remember what you suspected the xubuntu ltsp problem to be? janimo needs some more information.
<Kamion> janimo: (aren't they?)
<ogra> highvoltage, i have no clue at all without any log
<janimo> Kamion: ok, yeah they are, I moved them around for a while and forgot if they stayed in ship. thanks
<highvoltage> ogra: you said something about you bet it's the same problem we had in... (and i can't remember anything after that)
<janimo> highvoltage: irclogs ;)
<ogra> highvoltage, which i also get no logs for :P
<infinity> Kamion: Damn.
<ogra> highvoltage, expert install
<ajmitch> \sh: lucky me
<janimo> infinity: can you let through xubuntu-default-settings (stuck in the queue). It's ok if not too, it's just last moment icon and text color changes
<infinity> janimo: Will do.
<janimo> infinity: thanks
<infinity> janimo: You're lucky Kamion's bug is worth halting for. :)
<janimo> :)
<Kamion> ogra: /var/log/messages is obsolete in dapper, FYI - if you're using it, please switch to /var/log/syslog (preferably using log-output)
<infinity> Kamion: How long will it take to get a fix tested for that bug?
<Kamion> (obsolete in the installer, to clarify)
<Kamion> infinity: ... a while; no ETA yet :(
<infinity> Kamion: Fair enough.
<Kamion> we have a vmware clone here on which I can more or less reproduce it
<infinity> Kamion: Isolated where the fix needs to be, or do you need more eyes?
<Keybuk> Listing ubuntu/dapper (NEW) 0/0
<Keybuk> ... c0r
<Keybuk> Columns: number-out-of-date, number-newer-than-source, arch
<Keybuk>        0    0 amd64
<Keybuk>        0    0 i386
<Keybuk>        0    0 powerpc
<Keybuk> cute
<infinity> Keybuk: Yeah, fancy isn't it.
<fabbione> Keybuk: sparc?
<Keybuk> fabbione: ENOBRITNEY
<infinity> Keybuk: dapper_probs.html is finally clean too.
<fabbione> Keybuk: whops
<infinity> fabbione: http://people.ubuntu.com/~cjwatson/testing-ports/dapper_outdate.txt
<Kamion> infinity: more or less, but feel free to look - problem is in gparted, note how Apply_Operation_To_Disk is void
<infinity> fabbione: The only outdates in ports are a really longstanding guile FTBFS, and the gdb FTBFS tha tI ran out of time to help DaveM debug.
<infinity> fabbione: otherwise, all good.
<fabbione> hmm
<fabbione> there are some OO.o bits that can't be installed anylonger on sparc
<fabbione> W T #!?
<highvoltage> people who run on sparc uses OO.o?
<fabbione> highvoltage: when it's faster than amd64? yes
<ogra> highvoltage, yes, the ltsp users :P
* imbrandon needs to setup ltsp here at the house
<infinity> openoffice.org | 2.0.2-2ubuntu12 |        dapper | source, i386, powerpc
<infinity> WTF?
<infinity> fabbione: That's the source of the problem...
<infinity> Oh.  It landed in universe for sparc.  Hah.
<infinity> Fixing.
<fabbione> ah thanks
<infinity> We really need a tool to find stuff like that.
<fabbione> that should set the counter for sparc to 0
<Kamion> fabbione: ok, sparc should move from testing-ports output to testing at the next run
<fabbione> Kamion: thanks dude
<highvoltage> janimo, ogra: i got it
<ogra> you got it ? 
<ogra> tell us
<highvoltage> E: Package esound has no installation candidate
<ogra> aha
<highvoltage> ogra: the error ^^^
<ogra> janimo, you dont ship esd ?
<janimo> ogra, not sure.if it is pulled by the ltsp partes yes, if not no
* janimo checks
<infinity> Kamion: Do we have any sane way to find override disparities between arches, or just wait for them to cause bugs?
<ogra> its not a dependency, ltsp-build-client uses it
<janimo> ogra, ah so do I need to explicitely seed it?
<janimo> highvoltage: thanks for the catch :)
<ogra> janimo, yup
<janimo> ogra: any other such hidden deps :) ?
<janimo> I got the 4 or 3 packages with ltsp in their names + ldm so far, and now esound
<janimo> anything else?
<Kamion> infinity: I tried to write a script to do that at one point, but I think picking lint out of my navel suddenly became terribly exciting or something
<ogra> janimo, grep EARLY_PACKAGES ltsp-build-client
<infinity> Kamion: Well, you do have lovely lint.
<janimo> ogra, so libesd and esound-common were in the cd, only esound was missing
<janimo> ogra: where do I grep? where is that dir?
<janimo> on the iso?
<ogra> janimo, just esound should be fine, it was a dependency once, but debian revolted
<ogra> so i had to take it out and rely on the seeds, i wasnt aware you dont have esound at all, sorry for that
<ogra> its a script from ltsp-server (in /usr/bin/)
<janimo> ogra, np. So now I have quite some gnome libs + esd on the CD (ship only though). Seems to fit even on the ppc
<janimo> or maybe I just did not look at the build logs :)
<ogra> yes, that shouldnt be too much
<janimo> ok, should be mirrored in <15min then take effect in the next CD build. hope this is the only missing bit
<janimo> highvoltage: will you be able to test today's new image later?
<ogra> janimo, EARLY_PACKAGES="x-window-system-core ltsp-client discover1 laptop-detect xresprobe esound inputattach usplash ldm"
<janimo> whenever it is built?
<ogra> i guess the rest is available in your seeds
<janimo> ogra, huh usplash? thats ubuntu usplash
<ogra> yep
<ogra> but you have that ;)
<ogra> (its the binary)
<janimo> ogra, ok, phew
<janimo> I thought it was the artwork itself only
<jono> hey
<Treenaks> hm
<Treenaks> freenode is weird:
<Fujitsu> Hi, jono.
<Treenaks> 13:20 <        jono> hey
<Treenaks> 13:20 -!- jono (Jono Bacon) has joined
<jono> Treenaks: odd
<ogra> Treenaks, youre lagging
<jono> hey Fujitsu
<Treenaks> ogra: likely
<jono> biab
<mdz> infinity: are we building new livefses?
<Keybuk> jono: hey dude
<fabbione> janimo: ping?
<Kamion> mdz: please eyeball http://people.ubuntu.com/~cjwatson/tmp/gparted-safe-apply-operations.diff
<infinity> mdz: We will have to once Colin gets that gparted fix in.
<infinity> Kamion: Four Oh Four.
<Kinnison> Kamion: what infinity said
<janimo> fabbione: pong
<Kamion> it's there now
<fabbione> janimo: hey
* janimo is wondering what FTBFS on sparc
<infinity> janimo: ?
<fabbione> janimo: ??
<Keybuk> infinity: did you reenable publisher?
<janimo> infinity: no just being pinged by fabbione I assumed it was a sparc thing :)
<fabbione> janimo: nah..
<Kinnison> Kamion: a very rapid eyeballing says "looks okay to me"
<infinity> Keybuk: I'm publishing manually right now.
<Keybuk> ah
<fabbione> i would have lart you for that.... no ping ;)
<infinity> Kamion: I assume somehwhere outside of the context of the second hunk, apply is set to true?
<infinity> Err, third hunk.  Whatever.  The last one.
<infinity> Reading diffs of diffs makes hunk numbering confusing.
<Keybuk> infinity: yeah, at the top of the block
<infinity> Okay, cool.  Then it looks sane to me.
<infinity> Kamion: Will that prototype change require rebuilding anything else, or is this purely a private API anyway?
<Kamion> infinity: no, just internal to gparted
<Kamion> it's not quite working - it now fails to corrupt your disk but never tears down the progress bar
<zul> heylo
<sladen> can somebody with amd64 run  apt-cache search libgl*-dev
<infinity> Kamion: Well, failing to eat disks is progress.....
<infinity> sladen: Why would you epxect the output to be any different on amd64?
<ogra> sladen: libgl1-mesa-dev and libgl1-mesa-swrast-dev#
<ogra> (and mesademos)
<pitti> Kamion: yes, I'm not sure with which version we would be better off, I just routinely file sync bugs for stuff that's fixed in Debian
<sladen> ogra: no libglu..-dev ?
<sladen> infinity: because I have a bug report saying they are
<rpedro> hello
<infinity> sladen: apt-cache appears to glob in a special way, so libglu1-mesa-dev doesn't come back in that search.
<infinity> sladen: It's there, though.
<infinity> sladen: (If you search for it directly)
<ivoks> pitti: it seems that cups1.2 has some issues with older cupses
<infinity> sladen: What's the bug report?
<ivoks> pitti: we should consider cups1.2.1 for -updates asap :/
<infinity> sladen: If amd64 was missing any libgl*dev stuff, half the archive would be FTBFS.
<pitti> ivoks: yeah, it seems we still have quite a number of printing bugs
<pitti> ivoks: will that help?
<rpedro> can I get a backtrace from nautilus when it crashes and the 'restart app|inform developers| etc.' dialogue appears?
<pitti> ivoks: also, this libgnomeprintui bug about not reading ~/.cups/lpoptions really sucks
<ivoks> pitti: changelog of 1.2.1 says that those issues are fixed
<ivoks> pitti: i will try
<ivoks> pitti: yeah :(
<pitti> ivoks: I already backported some fixes from svn head a while ago, but I don't remember reading about compatibility fixes
<ivoks> pitti: but, atm cups 1.2 doesn't work with OSX (at least some versions of it) :/
<infinity> sladen: If you're referring to bug #29435, you really should read the comments.
<Ubugtu> Malone bug 29435 in mesa "Missing GL/gl.h" [Normal,Confirmed]  http://launchpad.net/bugs/29435
<ivoks> pitti: i spent 5 hours yeasterday making those two to work... finally i reverted to breezy
<seb128> rpedro: click on "inform upstream", the detail text has the backtrace
<seb128> rpedro: install nautilus-dbg before (and maybe libgnomevfs2-0-dbg too)
<infinity> sladen: And the guy who "couldn't get the latest version" was just suffering from an out-of-date mirror, and an inability to type "apt-get update"
<rpedro> seb128: ok, going to try that
<ivoks> pitti: "The scheduler no longer uses chunking in responses to clients - this caused problems with older versions of CUPS like 1.1.17 (PR #6143)"
<pitti> ivoks: I see
<infinity> sladen: Oh, I see.  You're looking at #47338 ... That's also complete 100% user error.
<sladen> infinity: bug #47338 but it's most like the same thing
<Ubugtu> Malone bug 47338 in mesa "libglu-dev and libgl-dev broken on amd64" [Normal,Unconfirmed]  http://launchpad.net/bugs/47338
<ivoks> pitti: that would explain some bugs that were reported
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/gparted-safe-apply-operations.diff updated, can you rebuild?
<infinity> Kamion: Looks the same to me...
<infinity> Of course, I wasn't smart enough to save the old one, so I can't diff.
<Kamion> reload
<Kamion> changes to apply_operations_thread to make it run off the end of the progress bar properly
<Kamion> yay distro team pair-programming for a change
<highvoltage> janimo: i will try my best. i'm extremely pressed on time, but i'll rsync and test as soon as i have a gap
<seb128> Kamion: "manual partitioning on ubiquity let with no bootable partition" would be a gparted bug, right?
<seb128> there is https://launchpad.net/distros/ubuntu/+source/gparted/+bug/41012 on the topic too
<Ubugtu> Malone bug 41012 in gparted "No (obvious) way to set a boot flag" [Normal,Unconfirmed]  
<seb128> (still my laptop refusing to boot when there is no bootable partition ...)
* Kinnison gets called away by his mother for lunch
<Kinnison> back in a bit
<Kamion> seb128: guess so
<Kamion> winn0r
* ogra applauds
<Kamion> uploaded, but I think I missed cron.daily
<mdz> janimo: it's time to stop uploading
<Kamion> ooh, manual mode
<Keybuk> "Day 1 in the Big Release House ... Colin is in the diary room"
<fabbione> Keybuk: lol
<Kamion> publisher running, I'm off for lunch
<highvoltage> Keybuk: lol
<infinity> Kamion: You sorted the manual queue mojo alright?
<mdz> infinity: yep
<infinity> fabbione: sparc looks okay on dapper_probs now.  Thanks for the heads-up.
<mdz> infinity: will you kick off livefs and CD builds when it finishes?
<infinity> mdz: Yup, yup.
<fabbione> infinity: thank, no problem
<sladen> what does gnome-volume-manager have to do with sound-cards (!?)
<ogra> it has the word "volumme" in its name ? 
<ogra> -m
<pitti> sladen: only that it restores the default sound card if you pull out the current default card (like an USB headset)
<janimo> mdz, yeah I've stopped, this one got in the queue shortly after it got closed, and asked inf to unstuck it only after a couple hours
<Kamion> infinity: yeah, I did
<ogra> dapper-dvd-i386.iso
<ogra>   3367493632 100%    2.60MB/s    0:20:34  (1, 100.0% of 1)
<ogra> nice :)
<doko> carlos: OOo translation ping ... it looks like  the current build finally will succeed. about 3.000.000 message strings, 50.000 warnings from translate-toolkit, 1500 errors (ignored) during the OOo import run; but too late for dapper; nobody had the chance to look at the translations (maybe except kurdish)
<carlos> doko: and Esperanto?
<carlos> doko: could you at least upload Esperanto and Kurdish?
<Kamion> upload? as in to dapper?
<Kamion> no
<carlos> Kamion: l10n files
<Kamion> yes, but do you mean upload to the dapper archive?
<carlos> yes
<Kamion> uploads are for absolutely critical showstopper fixes only
<Keybuk> sladen: gnome-volume-manager has ended up being the generic "do shit on hal events" process
<highvoltage> janimo: if i start the rsync now, will it include that esound fix? or should i hold on a bit?
<janimo> highvoltage: only if there's a CD built in the past half hour
* highvoltage checks
<janimo> highvoltage: not yet
<carlos> doko, Kamion: Is there any way to do those uploads as part of language packs updates (once per month) ?
<carlos> doko: or the lack of an initial Kurdish or Esperanto packages would prevent that?
<highvoltage> janimo: ok
<janimo> highvoltage: probably later today, when 30.1 CD's appear
<Kamion> if not, it could be a candidate for dapper-updates
<doko> carlos: the build takes 14h, so if something goes wrong, double the time. I couldn't do faster, working most of the night as well
<highvoltage> janimo: ok, i'm leaving for a birthday party i'll be killed for if i don't go in about 3 hours, so please let me know when it's there, if you happen to notice it :)
<carlos> doko: dude, don't worry, I know we were a bit late already...
<Kamion> I'm afraid 14h builds are totally unacceptable at this point
<Kamion> carlos: ^--
<Kamion> we hope to have the final images rolled long before that, and to be testing
<doko> carlos: sure, that should be possible, but we should have the packages up for testing before
<carlos> Kamion: indeed
<carlos> doko: we are doing daily language packs  atm
<janimo> carlos: did the langpacks go in yesterday? I did only see lang support packages on the list
<infinity> janimo: langpacks are uploaded silently to prevent flooding dapper-changes.
<carlos> doko: If I provide you with a fixed URL were you could fetch the .po files, would you be able to setup oo.org weekly lang packs?
<infinity> janimo: They all went in yesterday or the day before.
<janimo> infinity: thanks
<infinity> janimo: The language-support stuff today was just some bugfixes.
<highvoltage> the times displayed on cdimage.ubuntu.com, are they UTC?
<Kamion> language-support are *supposed* to be silent in general but may not have been in this case
<carlos> janimo: yes, they landed yesterday
<Kamion> highvoltage: London IIRC (+1)
<highvoltage> Kamion: thanks
<Kamion> infinity: the buildd sequencer is running normally automatically, right?
* Kamion waits impatiently for gparted to build
<infinity> Yes, but I just stopped it to run the queue builder.
<doko> carlos: in theory, yes. in practice: no. there are currently strings in rosetta which prevent OOo building at all. have to fix these first in the imported files and in rosetta
<Kamion> aha
<carlos> doko: could you send me a report about that after dapper release, when you are not so busy to see what I could do to improve that?
<doko> carlos: sure, let' chat about it on #irc next week
<carlos> doko: ok, thanks
<doko> carlos: but (hint, hint), import/export GSI files yourself ...
<carlos> doko: that's one of the things we should talk next month
<carlos> doko: I want to evaluate the possibility to import/export GSI files directly from Rosetta
<doko> carlos: and elmo will start to cry, when the diff get's bigger than the .orig.tar.gz. so an option to only export new or changed translations would be very nice
<carlos> doko: please, prepare a list of things/suggestions you have about this and let's talk about it before the sprint
<doko> carlos: I'll update the spec
<carlos> doko: cool, thanks
<infinity> Kamion: Okay, building.  I'll publish as soon as all the binaries are in.
<kagou> hi
<doko> mvo: ping
<mvo> doko: pong
<Keybuk> doko: you realise that a diff from 2.0 to 1.1 is roughly the same size as the current one
<Keybuk> WAIT A MINUTE!
<Keybuk> doko may have stumbled on a fantastic way to give Mark what he wants ;P
<doko> Keybuk: ?
<highvoltage> doko: i think Keybuk passed out of excitement :)
<Keybuk> doko: if you replaced the current openoffice diff with one that simply reverted the package back to the 1.1 packages ... it would be the same size! :)
<doko> mvo: bug 47328
<Ubugtu> Malone bug 47328 in update-manager "Consistent multiverse in synaptic and gnome-app-install" [Normal,Needs info]  http://launchpad.net/bugs/47328
<infinity> Kamion: Publishing.
<mvo> doko: hm, it is mostly a usability issue
<doko> mvo: tmarble did email you, could you reply?
* Mithrandir ponders a small nap
<mvo> doko: not yet
<lemsx1> good morning all
<ciga> hi
<OculusAquilae> infinity: ping
<sfllaw> Mithrandir: Mostly because I didn't know how frequent our daily builds are.  They, suspiciously, do not seem to happen once per day.
<infinity> OculusAquilae: ?
<infinity> sfllaw: When everything's in full auto, the dailies are (at least) daily.
<infinity> sfllaw: Which was certainly the case for the last few days.
<ogra> sfllaw, during release/milestone preparation we tend to build them more often
<OculusAquilae> infinity: I wanted to ask what to do because of Launchpad-Group kubuntu-de. Its owner isn't active anymore.
* Keybuk wonders how long it will take for the sign to be turned around
<OculusAquilae> infinity: and we have no active admins
<sfllaw> ogra: I suppose the testing matrix is pretty full right now.
<sfllaw> So we can afford to start over.
<Riddell> nice to see outside recognition of infinity's move to launchpad
<ogra> sfllaw, yep
<ogra> sfllaw, and the isos changed a lot since RC
<infinity> Riddell: Don't make me hurt you.
<sfllaw> ogra: OK.
<ogra> (edubuntu results are all for RC for example)
<infinity> OculusAquilae: Hrm, only two team members.  Not much of a "team".
<infinity> OculusAquilae: Anyhow, if you're looking to usurp the team by getting one of the active members promoted to team Admin, I suspect you should ask someone who's not me.
<OculusAquilae> infinity: We can't add more members because the team is restricted
<infinity> OculusAquilae: I'm only an LP admin for hilarious reasons best not discussed, I don't actually flex that power.
<Keybuk> http://people.ubuntu.com/~scott/releasecon.jpg
<ogra> OculusAquilae, #launchpad
<OculusAquilae> infinity: Who has that power then?
<infinity> OculusAquilae: I have the power, I just don't use it. :)  Try kiko, SteveA, stub, or lifeless on #launchpad.  All better choices than I for LP admin.
<OculusAquilae> infinity: ok thanks
<infinity> Okay, firing off livefs builds nowish...
* ogra crosses fingers
<mdz> iwj: ping
<ogra> Keybuk, one-man-con ? 
<ciga> does anyone have '[fglrx]  API ERROR: could not register entrypoint for *' error message when starting glxinfo in the latest dapper?
<ogra> where is the rest ? 
<infinity> ciga: Not the time or place to be discussing it, but yes, in fixing some newer cards, ATI broke DRI on some r200 cards.  There's a bug on launchpad already.
<ciga> infinity: thank you.
<bddebian> Heya folks
<iwj> mdz: Hi.
<iwj> Just writing a mail about this themes thing.
<iwj> mdz: Seen your mail of 10 mins ago, willdo.
<mdz> iwj: thanks
<iwj> You say `per Mark'.  Do you mean (a) Mark has told you this some place I didn't see it or (b) Mark has told you this in a mail that I am supposed to have a copy of ?  Because if (b) there is something wrong with mail from Mark to me.
<mdz> iwj: (a)
<iwj> Oh, good, thanks.
<Kamion> (over-the-cube-discussion)++. Er.
<Kamion> :-)
<Kamion> Riddell: isn't bug 47194 just a duplicate of bug 45437? or do you think qtparted has crashed and not told stderr?
<Ubugtu> Malone bug 47194 in ubiquity "Dapper RC:Installer crashed at partitionning step" [Normal,Needs info]  http://launchpad.net/bugs/47194
<Ubugtu> Malone bug 45437 in ubiquity "crash in installer @ partition screen" [Normal,Fix released]  http://launchpad.net/bugs/45437
<Kamion> Riddell: oh, no, it's in a different place that doesn't have a None check - ignore me please
<Riddell> yeah, I think they're different
<mdz> infinity: livefs builds finished?
<Kamion> Riddell: I don't believe your close of bug 46331, though :)
<Ubugtu> Malone bug 46331 in ubiquity "Cache issue with kde frontend" [Normal,Fix released]  http://launchpad.net/bugs/46331
<Kamion> especially because it's a known issue ...
<infinity> mdz: They're thinking really hard about finishing.
<infinity> Kamion: Mirroring issues okay enough to do alternate builds yet?
<infinity> Kamion: I'll let you verify that, and you can do alternates in parallel with my desktop builds.
<Kamion> Riddell: oh, wait, did you not stop qtparted from creating filesystems in installer mode?
<Kamion> infinity: yeah, it's fine - starting builds now
<infinity> Kamion: I'll do DVDs after the desktop run, I guess, since I'm watching for livefs goodness anyway.
<Riddell> maybe I'm misunderstanding what he's saying, he's saying partman doesn't pick up new patitions made by qtparted?
<infinity> Kamion: Rebuilding all the -alternate- images, I assume, so we're starting from a known archive state?
<Kamion> infinity: yes
<infinity> Kamion: Rock.
<Kamion> Riddell: ok, in the gtk frontend, we stop gparted from creating filesystems, and let partman do all of that work
<Kamion> Riddell: this has the advantage that filesystem creation flags are automatically consistent with those used by d-i
<infinity> And there comes the ubuntu livefs.
<Kamion> Riddell: but it has the downside that if you go back to gparted it doesn't remember the partition types
<Kamion> but apparently you don't do this for qtparted
<Kamion> I didn't realise that until now
<Riddell> yes, qtparted will still make the filesystems
<Kamion> that's a bit of a shame for consistency
<Riddell> although if you just click Back it'll forget all about what you've done, it only makes them on clicking Next
* Kamion nods
<Kamion> in edgy I hope to fix this by just writing a partitioning UI from scratch on top of partman
<Kamion> the approach of using an external partition editor was expedient for dapper, but it just has way too many reliability problems
<Riddell> yes
<BenC> so for this round of testing we should do the same tests we were assigned last time on the chart?
<infinity> BenC: And more!
<infinity> BenC: Test till you drop.  This is "it", after all.
<ogra> yeah 1
<ogra> !
* BenC prepares for a busy day
<bddebian> heh
<fabbione> BenC: we will need to swap some sparc tests,  because i have no cd here
<ogra> BenC, add the night as well ;)
* bddebian should get a Sparc just for "fun"
<BenC> fabbione: Ok, I can do cd install on my U2, and boot the installer (but not actually install) on my e3k
<BenC> that is, if it can boot from a CDR
<BenC> some of these old sun cdrom's are not burnable media aware
<fabbione> yeah i remember that
<Kamion> sfllaw: I'm in the London office now, so powerpc netboot testing plus the random crap lying around here is about all I can do
<Keybuk> likewise
<Keybuk> the London office seems well covered for PowerPC testing
<Keybuk> !PowerPC should be assigned to others
<sfllaw> Thanks guys.
<BenC> Keybuk: can you do powerpc-server too?
<Keybuk> BenC: define "server"
<fabbione> BenC: yes we can
<fabbione> we can also do amd64
<infinity> Keybuk: The ubuntu-server CD. :)
<sladen> infinity: when are the i386 images likely to be ready.  I'd like to grab them before I leave this nice fast JANET connection
<BenC> the server install from the alternate cd including LAMP
<Keybuk> I can install the ubuntu-server CD on a PowerBook :p
<fabbione> BenC: yeps
<BenC> server cd I mean
<_ion> LAPR > LAMP
<_ion> </provocation> :-)
<bddebian> heh
<Keybuk> LAPDANCE > *
<Robot101> LAMP = Linux, Apache, Many scripting languages, PostgreSQL
<infinity> sladen: ubuntu-desktop is ready now.
<Keybuk> fabbione: START UP RSYNC PONIES 1 THRU 3
<Treenaks> Keybuk: LAPDANCE!?
<fabbione> Keybuk: fired up
<pitti> rsync and jigdo pulling at full speed
<Chipzz> Robot101: Linux/Apache/Mysql/PHP actually
<infinity> Chipzz: I'm sure he's aware of that.
<Robot101> Chipzz: uh, yes. it's an anti-mysql joke... :P
<Chipzz> I find more things wrong with postgres than with mysql actually :)
<pitti> Chipzz: GRRR
<infinity> Chipzz: Can we avoid this holy war here?
<infinity> Chipzz: It'll just end in pitti and I mudwrestling in the channel, which won't help the release one bit.
<sfllaw> Keybuk: I do not want to know about your lapdancing pony fetish.  ;)
<Chipzz> yea maybe for the better ;)
* pitti decides to leave that for now and instead buy infinity a beer in Paris
<Kamion> oh yeah, Ubuntu alternate built
<bddebian> Lapdancing ponies?
<infinity> Kamion: If I don't tell you in Paris that I cut the livefs build time in half, tie me to a chair until I do so.
<infinity> Kamion: I swear it gets slower every day.
<maswan> the prancing pony release?
<bddebian> hehe
<Kamion> infinity: I'll bring my handcuffs and skipping rope
<HiddenWolf> Kamion: have fun with customs. ;)
<infinity> Kamion: I knew we should have been roommates...
<sfllaw> Oh my!
<Kamping_Kaiser> mmm. good quit message that one...
<dholbach> sfllaw: going to wipe or replace the Testing/Current table?
<sfllaw> dholbach: Didn't I already do that?
<infinity> Make sure to note the correct datestamp for ALL the images we're testing.  They're not all going to be the same.
<dholbach> sfllaw: then some people were quite fast in updating the sheet :)
<infinity> (20060530, 20060530.1, 20060530.2...)
<infinity> kubuntu-desktop CDs are built.
<Riddell> and I was just testing the existing ones
<Riddell> ok, thanks
<Keybuk> infinity: which are built, and of which vers
<infinity> Keybuk: -desktop-, AKA -live- ...
<Keybuk> 20060530.1  ubuntu-desktop
<Keybuk> 20060530.2  ubuntu-alternate
<Kamion> Kubuntu alternates built too
<Keybuk> 20060530.2  kubuntu-alternate
<Keybuk> ( I don't see updated kubuntu-desktop yet )
<dholbach> I remove all the comments from Testing/Currents - is that ok? sfllaw?
<infinity> kubuntu-desktop should be 20060530.1
<infinity> I think the mirrors are thinking really hard about syncing it.
<Keybuk> 20060530.2  edubuntu-alternate
<Riddell> dholbach: can you update the kubuntu cd numbers while your there
<pitti> dholbach: we should test everything with the current CDs, so that should be fine
<ogra> Kamion, thanks !
<Keybuk> ( No edubuntu-desktop yet )
<infinity> Keybuk: edubuntu-desktop and xubuntu-desktop still pending.
<ogra> live please :)
<Kamion> um? edubuntu-alternate still seems to be running
<infinity> Keybuk: And DVDs will come after all the desktop builds.
<Kamion> oh, never mind, my ssh session died
* Kamion reconnects screen
<ogra> edu install is there already
<Kamion> yeah
<sfllaw> dholbach: Comments?
<sfllaw> Like which bugs failed?
<dholbach> sfllaw: PASS/FAIL etc
<sfllaw> Uhm, nothing says PASS/FAIL on this page right now.
<dholbach> it does
<dholbach> in the various tables
<sfllaw> Some of them say 20060525-fail.
<sfllaw> But that's correct.
<sfllaw> Is that what you mean?
<dholbach> yeah
<infinity> Kamion: Building xubuntu-alt too?
<dholbach> I thought we'd clean it up completely
<dholbach> no?
<sfllaw> dholbach: It's good to keep track of the fact that things _used_ to fail.
<dholbach> oh well, ok
* infinity starts the ubuntu DVD while he wats for more livefses.
<infinity> s/wats/waits/
<dholbach> then I just updated the cd numbers
<Kamion> xubuntu alternate done
<Kamion> doing ports as well while I'm here
<highvoltage> yay!
<highvoltage> http://cdimages.ubuntu.com/xubuntu/daily/current/ is empty though :/
<Kamion> s/cdimages/cdimage/ dude
<Kamion> it may still be mirroring though
<highvoltage> Kamion: thanks dude
<Kamion> (the 'cdimages' alias normally works, but we've had problems with apache config not knowing about that in the past, so it's best to use the official name)
<infinity> Kamion: ubuntu-server and ubuntu-server-ports while you're at it too, SVP... I'll be stuffed up for a while on Live and DVD, I'm sure.
<Kamion> yeah, realised I should have done that before starting on the other ports
<Kamion> they're in my queue
<dholbach> iwj: there's a new ubuntu-artwork - I'll upload the firefox-themes-ubuntu again.
* iwj howls.
<iwj> Thanks.
<infinity> dholbach: Did you just say "new ubuntu-artwork"...?
<iwj> Or I can do it.  I mean, I just did one.
<dholbach> infinity: the one from 6h ago
<infinity> Oh, thank god.
<infinity> I was about to jump through my screen and strangle you.
<dholbach> infinity: ok, go ahead then :-)
<dholbach> infinity: oops
<iwj> Oh, if it was 6h ago, then I've already uploaded f-t-u since then.
<dholbach> iwj: ok, go ahead then :-)
<iwj> Quality stable stuff, this theme-builder package.
* dholbach removes it from his list
<infinity> iwj: Were you going to ask someone to process that upload at some point? :)
* infinity points at the topic.
<iwj> infinity: Err, they need processing manually now ?  In that case I should be, yes.
<dholbach> infinity: it's for universe
<infinity> dholbach: Yes, I shut down the WHOLE QUEUE. :)
<dholbach> infinity: I see :)
<infinity> iwj: I'll process it right now.
<iwj> infinity: Well, yes, err, would someone like to process my upload then please ? 
<iwj> Thanks.
<iwj> Should there have been an announcement about this on u-d-a ?
<Keybuk> dholbach: isn't it for main?
<iwj> The most recent thing I have there is mdz's from Friday.
<dholbach> Keybuk: I don't think so.
<iwj> Keybuk, dholbach: We don't know yet whether it's for main or universe.
<dholbach> oh ok
<fabbione> iwj: it's the same we did for the past 4 releases
<iwj> Currently universe.
<Kamion> it's currently in universe but Mark wants it in main
<infinity> Kamion: Not in ship, I hope...
<Kamion> infinity: "in desktop, in case we happen to be re-rolling CD images for some other reason"
<infinity> Gah.
<Kamion> or words to that effect
<jdub> Keybuk: ha ha
<jdub> What does the identity of the maintainer have to do with it? Maybe he
<jdub> knows more about the subject than you do, maybe not.
<bgertzfield> infinity: Good morning!
<jdub> Keybuk: do you know more or less about udev than the maintainer? *MORE* or *LESS*?
<Keybuk> jdub: I know equal amounts
<Keybuk> and he doesn't know more about the subject than me
<jdub> no, only two choices
<jdub> MORE or LESS!
<Kamion> jdub: "yes"
* Kamion attacks jdub with Zorn's lemon
<bgertzfield> infinity: Hey -- mvo just mentioned that the vmware-player-kernel-2.6.15 package that gets installed by default is the i386 flavor.  Did I mess up the packaging, or does linux-restricted-modules do the same?
<pitti> Kamion: but more or less isn't yet true, 'exactly equal' is missing :)
<infinity> bgertzfield: Hrm?  In what sense?
<infinity> bgertzfield: In the "apt-get makes stupid decisions" sense, it will resolve the pure virtual dependency by picking the first one in asciibetical order, then pulling in all its deps (ie: a new kernel)
<infinity> bgertzfield: Nothing you can do about that.
<Kamion> pitti: I see you are not a believer in the axiom of choice ;)
<infinity> bgertzfield: Smarter package management frontends will go for the "path of least change", which should lead to getting the modules for your current kernel installed.
<bgertzfield> infinity: I see.
<bgertzfield> infinity: OK, that's what I figured.  Thanks.
<infinity> bgertzfield: (Assuming you only have one flavour installed)
* pitti prefers the countable sets where equality is indispensable 
<sivang> he
<bgertzfield> infinity: so mvo ended up pulling in the i386 kernel as well.
<infinity> bgertzfield: There's not really much we can do to improve this, so we cope and users write HOWTOs when it breaks a bit. :)
<bgertzfield> hmm
<bgertzfield> this is also weird; I don't see the smp kernels in the 2.6.15 i386 kernel modules package list
<bgertzfield> let's see what happened
<infinity> There are no SMP kernels.
<infinity> -686 and -k7 are SMP/UP autoswitching.
<bgertzfield> Oh.
<bgertzfield> Really!
<bgertzfield> ubuntu++
<Keybuk> pitti: mmm, infinite sets
<bgertzfield> I had no idea.
<bgertzfield> infinity: thanks
<pitti> Keybuk: I said 'countable', not 'finite' :)
<dholbach> hum, doesn't the powerpc alternate cd have a memcheck?
<Keybuk> if you have an infinite number of hotel rooms, and each one is occupied, can you find room for infinity, should he be kicked out of home?
<Kamion> no
<Kamion> memtest => x86 assembly
<jdub> pitti: perhaps the the inter-relationships between scott's knowledges of udev are in indeterminite states
<dholbach> :-/
<Kamion> in fact it's called "memtest86+", which is a clue :)
<Keybuk> jdub: shut up.
<dholbach> right, now you say it...
<Keybuk> love Keybuk
<Keybuk> kthxbye
<Keybuk> ;)
<Keybuk> xx
<dholbach> so I need to find out which bit of memory is broken myself :)
<pitti> Keybuk: sure, we just kick out Mr. Hilbert from his room 
<jdub> hostile today, Keybuk 
<Keybuk> pitti: without kicking anyone out
<pitti> Keybuk: ok, gently ask him :)
<mvo> bgertzfield: exactly this happens, it installs a i386 kernel image and the i386 modules. the next problem is that vmware-player wants to start /etc/init.d/vmware-player in its post-inst. this causes the postinst to fail because the scripts fails (no modules loaded because there are no modules for the -k7 flvaour)
<pitti> Keybuk: it works with infinitely many buses each containing infinitely many Adams, but will it work with 2^oo-1? :)
<Keybuk> pitti: how long will it take infinity to process an infinite number of buildds building an infinite number of openoffices that have reached an infinite size?
<bgertzfield> mvo: right. according to infinity, there's not a lot we can do about that :( apt chooses the wrong package
<pitti> Keybuk: let's conquer some more universes to get the power and matter to try it out
<bgertzfield> mvo: that's the problem with virtual package dependencies and apt; it doesn't know it should pick the package that depends on a package already installed
<doko> Keybuk: the size of openoffice.org-l10n is limited by the number of translations ;-P
<Keybuk> doko: so it's all pitti's fault?
<doko> Keybuk: blame carlos and jordi ;)
<Kamion> ubuntu/kubuntu ports alternate done; ubuntu-server building
* carlos hides
<carlos> :-P
* jordi curses OOo in a loud way.
* jordi starts the GNOME-Office for Ubuntu project
<jsgotangco> lol
<jsgotangco> start an lp team? heh
<AlinuxOS> Hi great pitti, I've got this error today: Failed to fetch http://people.ubuntu.com/~pitti/langpacks/daily/./Packages.gz  404 Not Found
<pitti> AlinuxOS: known, I'll move them to langpacks/daily/dapper-updates
<mvo> bgertzfield: right. we could hack around it by depending on all vmware-player-kernel-module packages from the player and remove the dependency in the modules to the image. ugly and won't cover custom kernel builds
<pitti> AlinuxOS: today's build has failed because Rosetta didn't give me a tarball (hey carlos!)
<doko> JaneW: helpcontent2    source\text\simpress\main0106.xhp       0       help    tit                             0       af      Gereedskap^M\n<E2><80><94> Jane Weideman^M\nGereedskap^M\n<E2><80><94> Jane Weideman^M\nNutsgoed                                20060529 21:41:49
<doko> that's in an OOo translation ...
<carlos> pitti: I did
<bgertzfield> mvo: yes, very ugly
<carlos> pitti: do you remember the -updates change?
<pitti> dholbach: oh, didn't you want to clear the test matrix?
<pitti> carlos: yes, I did
<AlinuxOS> :)
<AlinuxOS> carlos, :D
<carlos> oh, fuck, I named it -update
<AlinuxOS> 100000000 people are waching you :)
<carlos> pitti: http://mawson.ubuntu.com/~carlos/rosetta-dapper-update.tar.gz
<dholbach> pitti: sfllaw wants to keep the old data
<AlinuxOS> entire nation deppends on you :)
<carlos> AlinuxOS: ;-)
<pitti> carlos: ah; I tried '-updates'
<AlinuxOS> carlos, god bless you :) pitti and ubuntu-devel team :D
<carlos> pitti: it's 'updates'
<AlinuxOS> hehe
<carlos> my fault
<carlos> pitti: let me fix it
<JaneW> doko: huh? :)
<AlinuxOS> http://ka.wikipedia.org/wiki/%E1%83%9A%E1%83%98%E1%83%9C%E1%83%A3%E1%83%A5%E1%83%A1%E1%83%98%E1%83%A1_%E1%83%93%E1%83%98%E1%83%A1%E1%83%A2%E1%83%A0%E1%83%98%E1%83%91%E1%83%A3%E1%83%A2%E1%83%98%E1%83%95%E1%83%94%E1%83%91%E1%83%98#Ubuntu_Linux
<AlinuxOS> ;)
<AlinuxOS> http://upload.wikimedia.org/wikipedia/ka/7/72/01_georgian_ubuntu_dapper.png
<AlinuxOS> how is sexy georgian Ubuntu Dapper :)
<AlinuxOS> loolz
<pitti> carlos: oh, I was just about to fix it; so, -updates or -update?
<carlos> pitti: -updates
<carlos> pitti: it's renamed
<carlos> and the script is fixed
<Kamion> AlinuxOS: ok, we appreciate your work, but we are trying to do a release here, so please if you ever find yourself typing "loolz" consider that it's noise here
<doko> carlos: ooo/rosetta-ooo-help-simpress/af.po
<mgalvin> Riddell: ping?
<doko> #: helpcontent2/source/text/simpress/main0106.xhp#tit.help.text
<doko> msgid "Tools"
<doko> msgstr ""
<doko> "Gereedskap^M\n"
<doko> " Jane Weideman^M\n"
<doko> "Gereedskap^M\n"
<doko> " Jane Weideman^M\n"
<doko> "Nutsgoed"
<pitti> carlos, AlinuxOS: ok, cranking up build of dapper-updates packages
<AlinuxOS> Kamion, oops, sorry :) You've right!
<carlos> doko: that's a bad copy and paste
<AlinuxOS> sorry all, pitti carlos Kamion all :)
<carlos> doko: that is hidden by a bug in Rosetta...
<doko> carlos: and the ^M's are all nasty ...
<AlinuxOS> Kamion, that was my emotion..you know it's very difficult to show emotions in IRC
* JaneW is no doubt guilty *blush*
<carlos> doko: copy and paste
<AlinuxOS> so don't be angry :)
<doko> carlos: that breaks the OOo build
<JaneW> carlos: sorry
<carlos> doko: I will try to get that bug fixed and 'migrate' that data (will set it as Needs review) before we prepare final .debs
<doko> carlos: ^M's in general?
<carlos> doko: no, that's a side effect
<carlos> doko: and thus should also be deactivated
<seb128> pitti: is dapper-updates already open?
<doko> carlos: that's not the only place with ^M's, so if you can replace them with \r where appropriate
<infinity> seb128: No.
<pitti> seb128: no, just for my daily langpacks on people
<Kamion> \r doesn't belong in msgstrs either
<pitti> AlinuxOS: http://people.ubuntu.com/~pitti/langpacks/daily/dapper-updates/
<pitti> carlos: wow, that works *really* fast now
<seb128> infinity: I know now is not time to speak about that, but will it be open on friday? ;)
<doko> Kamion: they do in GSI format, and as long as we have to convert to po format, we have to keep them
<AlinuxOS> pitti, so I substiute that in my sources.list.
<seb128> infinity: I'm not that in an hurry but GNOME 2.14.2 will be out tomorrow, and if I can update before my VAC, the Paris summit and the GUADEC that would be could :p
<infinity> seb128: No idea, TBH.
<AlinuxOS> pitti, ok, done. works great here. Thank You!
<carlos> Kamion: there are some msgstrs that need the \r char (if the msgid has it)
<infinity> seb128: I can prep some things to make it easier, but we'll see.
<seb128> infinity: k, we will see than on friday then ;)
<seb128> s/than/that
<infinity> seb128: You can always prepare all the uploads and trust dholbach to upload them. :)
<Kamion> carlos: gettext tools spam my screen massively for everything I download from Rosetta that has \r
<seb128> infinity: right :p
<Riddell> mgalvin: hi
<bgertzfield> mvo: hm.  I just ran synaptic to see how the installation goes
<bgertzfield> mvo: you're right, it's quite nasty
<bgertzfield> mvo: synaptic really doesn't let the user know "by the way, there are other things to make this work!"
<carlos> Kamion: hmm, I did a fix to prevent that char to appear in our database unless the msgid has it
<carlos> Kamion: was it recent?
<Kamion> carlos: downloaded on Monday
<mgalvin> Riddell: hi, we were just talking with JaneW about the newsletter stuff and mdz suggested consolidating them...
<Kamion> I have no idea how old the strings were
<carlos> Kamion: debian-installer ?
<Kamion> carlos: yes
<Kamion> can't remember what language
<JaneW> mgalvin: I just mailed the xubuntu guys too
<Kamion> ru possibly - there were several
<carlos> Kamion: ok, I will try to debug it
<mgalvin> Riddell: jsgotangco and myself are going to work on it to
<mgalvin> JaneW: great! thanks :)
<mvo> bgertzfield: yes :/
<Riddell> mgalvin: ok
<mgalvin> Riddell: so we started https://launchpad.net/people/ubuntu-newsletter
<infinity> Oh, holy crap, Ubuntu DVDs finished.
<mgalvin> Riddell: just wanted to make sure you were aware of what was discussed and the plan that is to make one larger newsletter with deriv specific sections
<jsgotangco> mgalvin: this could be one team that the LP calendar can be used heh
<_ion> Cool, distributor-logo.png in ubuntu-artwork has been fixed. 
<ogra> Kamion, any trace of edubuntu liveCD builds yet ? or am i to impatient ?
<mgalvin> jsgotangco: indeed
<Keybuk> Riddell: everything in K->Help is duplicated
<Keybuk> Welcome to KDE
<Keybuk> Welcome to KDE
<Keybuk> KDE Users' Manuals
<Keybuk> KDE Users' Manuals
<Keybuk> etc.
<Riddell> Keybuk: hmm, works on my install, I'll need to wait for these desktop CDs to rsync before I can confirm for a fresh user
<ogra> Keybuk, do you have kubuntu-docs installed twice ?  :P
<Keybuk> Riddell: this was the 30 kubuntu-desktop, rather than 30.n
<infinity> ogra: edubuntu livecd is happening right now, sorry.  It got backed up in the queue. :)
<ogra> ok, thanks :)
<ogra> i just saw the others were done already :)
<infinity> If anyone's doing Ubuntu DVDs, those are now current.
<infinity> (Which was what backlogged ogra's CDs.. Oops)
<ogra> heh
<ogra> i'll do eubuntu DVDs once they exist
<ogra> *edubuntu indeed
<bgertzfield> infinity: OK, mvo and I have a possible solution for the vmware-player kernel modules dependency
<infinity> bgertzfield: Colour me curious.
<bgertzfield> infinity: Our problem is that the linux kernel images depend on the correct flavour of linux-restricted-modules
<bgertzfield> we don't have that luxury here; the linux images can't possibly depend on something from multiverse
<infinity> bgertzfield: Right...
<infinity> bgertzfield: You can't force the upgrade at all in any sane fashion.
<mjg59> Do we implement enhances: yet?
<infinity> mjg59: Hahahahaha!
<bgertzfield> infinity: so instead, what if we make linux-player Depend: on a new set of virtual packages: vmware-player-kernel-modules-386|vmware-player-kernel-modules-custom, vmware-player-kernel-modules-686|vmware-player-kernel-modules-custom, ... etc.
<infinity> mjg59: (That's a "no")
<infinity> bgertzfield: That can perhaps help with the auto-upgrading magic, but it won't help with the "wrong flavour" problem.
<bgertzfield> then we make vmware-player-kernel-modules-386 Provided: by vmware-player-kernel-modules-2.6-16-386, and change the Depends: to a Recommends
<bgertzfield> infinity: It will, because users will have to install *all* kernel modules
<infinity> bgertzfield: Oh, I see what you've done, yes.
<bgertzfield> infinity: our problem is we have a user-space component (vmware-player) whose postinst will fail if its kernel modules are not present
<mvo> infinity: its not as bad as it sounds, the package is pretty small
<infinity> bgertzfield: Given the tiny size of the packages, I guess that hack won't hurt too much.
<bgertzfield> infinity: Excellent.
<bgertzfield> mvo: I had a second idea
<infinity> bgertzfield: But if you want to ship them all anyway, why have seperate packages at all?
<bgertzfield> mvo: we can do this "correctly" for both i386 and amd64 with substitution variables
<bgertzfield> infinity: hm.
<bgertzfield> infinity: yeah, that's an even better question
<infinity> bgertzfield: Just make vmware-player-kernel-modules-2.6.15 contain all the kernel modules and be done with it.
<bgertzfield> infinity: I didn't think of that. :)
<bgertzfield> mvo: what do you think?
<mvo> sounds ok to me
<infinity> bgertzfield: (Well, that would probably still be a metapackage, depending on vmpkm-2.6.15-23, to make the ABI thing work)
<bgertzfield> ok. that will handle the architecture issue as well
<bgertzfield> infinity: sure.
* mvo nods
<bgertzfield> infinity: hm, the ABI thing?
<infinity> So, just encode the ABI number in the package name, but not the flavour, and ship all flavours in one.  Easy enough.
<bgertzfield> ah, kernel ABI
<bgertzfield> you mean a metapackage Provided: by vmpkm-2.6.15-23. got it
<bgertzfield> ok!
<bgertzfield> mvo: you want to tackle this? or should I
<infinity> Someone show me the final code for this one before it gets uploaded, just in case there were some, uhh, miscommunications. :)
<mvo> bgertzfield: if you have the time to do it I would appreciate, I'm doing the final testing for dapper (image) right now
<bgertzfield> infinity: sure.
<bgertzfield> mvo: ok
<bgertzfield> I'll also fix Mithrandir's little mistake :)
<infinity> The control.in thing? :)
<bgertzfield> yep.
<pitti> I go offline for a bit to test CDs on my workstation
<bgertzfield> hm.  I just realized I also failed to make a proper source package for vmware-player 1.0.1
<bgertzfield> if I change from a "debian native" (1.0.1-3.tar.gz) to a proper .orig.tar.gz in a revision, will that work?
<infinity> bgertzfield: Yes, you can swap between releases.
<infinity> bgertzfield: Please do.
<bgertzfield> ok. fixing that too.
<bgertzfield> good thing I am upstream. :)
<siretart> 
<dholbach> Kamion: which information do you need if the "auto resize" option is not shown (desktop install) - or is there a bug about it already?
<bgertzfield> infinity: hm. It actually looks like I don't have to make any other changes in vmware-player 1.0.1 to make this work. Is it worth uploading now just to go from .tar.gz -> .orig.tar.gz?
<infinity> dholbach: It's only shown in certain circumstances.
<bgertzfield> or should I save that for when I need to make an actual change?
<infinity> bgertzfield: yeah, do the upload to fix the naive thing anyway, please.
<dholbach> infinity: oh? i thought it was shown if the disk was covered with partitions completely?
<bgertzfield> infinity: will do
<infinity> bgertzfield: I have to manually drive the archive to get the other change in, so just do both.
<bgertzfield> ok. thanks so much
<ogra> infinity, seems edubuntu live is ready, so if lithium has some spare cycles i'd appreciate a DVD
<Kamion> dholbach: there are more conditions than that
<Kamion> dholbach: given /var/log/partman, I can tell you why it wasn't displayed
<infinity> ogra: kubuntu DVDs and edubuntu DVDs are next on my list.
<ogra> cool, thanks :)
<dholbach> Kamion: if this is intended, I'm happy with that.
<Kamion> ubuntu-server done, BTW
<jsgotangco> yay
<Kamion> dholbach: feel free to stick the partman log somewhere and I can check quickly
<bgertzfield> Kamion: awesome.
<infinity> All desktop images (ubuntu, kubuntu, edubuntu, xubuntu) are done, FWIW.
<dholbach> Kamion: http://daniel.holba.ch/ubuntu/partman
<bgertzfield> infinity: so, this new mega-package for the kernel modules should probably neither Depend: upon nor Suggest: the linux-image flavors, I assume
<seb128> Kamion: https://launchpad.net/distros/ubuntu/+source/gparted/+bug/47520 
<Ubugtu> Malone bug 47520 in gparted "gparted should makes sure there is a bootable partition" [Normal,Unconfirmed]  
<seb128> Kamion: that's sort of an installer issue too since it let the system not bootable, if you want to subscribe to it ...
<elmo> mdke: ping?
<bgertzfield> hm.  I guess I can make it a Recommends (didn't mean Suggests) with alternatives
<Kamion> seb128: unfortunately it's painful UI changes and ubiquity changes to fix, I'm sorry, I heard you the first time too but I don't think we can fix it for dapper
<Kamion> yes, it's an installer issue, obviously
<infinity> bgertzfield: Recommends with alternatives, I guess.  Depends is more correct, but will lead to the previous apt confusion, I guess.
<seb128> Kamion: no problem, that's not like the issue was new, I pinged with a similar issue previous cycle too
<seb128> Kamion: that's just to have the bug listed somewhere
<bgertzfield> infinity: Right.  Since I want to do this correct for all architectures, can I use Recommends: linux-image-@@ABIVER@@-386 [i386]  | linux-image-@@ABIVER@@-amd64-generic [amd64]  ?
<bgertzfield> etc.
<seb128> (I was not pinged about the issue again, just pointing the bug I just filled about it in case you want to subscribe to it)
<bgertzfield> or should I use a substitution variable?
<Kamion> seb128: done
<seb128> thank you
<infinity> bgertzfield: No, write it per-arch.
<bgertzfield> infinity: via a substitution variable, right?
<infinity> bgertzfield: Right.  Substvars to the rescue.
<bgertzfield> oh, I suppose I could have two mega-packages with different names as well
<bgertzfield> but I don't see how that's super helpful
<bgertzfield> substvars it is.
<infinity> bgertzfield: No, one megapackage is saner anyway.  Just use substvars to get the right Recommends on each arch.
<bgertzfield> OK.
<bgertzfield> easy enough
<Kamion> dholbach: can you file a bug about that one on partman-auto, attaching that log? for a change I can't immediately see why it didn't want to offer auto-resize there
<dholbach> Kamion: ok, I'll do that - thank you.
<Mithrandir> sfllaw: so the whole chart should be wiped on each build, right?
<dholbach> Kamion: done: bug 47523
<Ubugtu> Malone bug 47523 in partman-auto "partman-auto didn't offer "Auto Resize" option on i386 Desktop Ubuntu 20060530.1" [Normal,Unconfirmed]  http://launchpad.net/bugs/47523
<mdz> dholbach: did you really mean FAIL?
<mdz> dholbach: or that you were unable to test?
<dholbach> mdz:  I changed that already
<dholbach> mdz: it's N/A now
<highvoltage> janimo: the LTSP chroot now builds fine with Xubuntu. Whohoo!
<janimo> highvoltage: great, thanks for testing! :)
<mdz> ok
<janimo> so you have a working ltsp server with xfce installed?
<Kamion> dholbach: thanks
<dholbach> de rien
<highvoltage> janimo: well, it's currently scanning for an apt mirror, but it built correctly, at least. i'll test if a client actually boots a bit later, i'm actually at a birthday party with laptop atm, doesn't look to good ;)
<janimo> highvoltage: ok ;)
<infinity> Kamion: You did all the ports -alternates right?
<Kamion> infinity: yeah
<infinity> Kamion: But not ports-live?  (If you did, I'll just do them again when kohnen finishes thinking)
<doko> carlos: another export problem: msgid "size *2 \\\\langle x \\\rangle" -> msgid "size *2 \\\\langle x \\^Mangle"
<carlos> doko: that's a broken input string
<carlos> doko: please tell me that OO.org is not soooo bad to have a string '\\\r' 
<carlos> as a valid one
<infinity> Kamion: Err, s/kohnen/castilla/ ... It's been a long day already.
<carlos> doko: I need to leave now
* Kinnison decides that disabling workrave was a bad plan
* Kinnison 's left wrist is now really hurtying
<carlos> doko: I will take a look later, thanks for noting that
<doko> carlos: stay connected, so you can read a backlog ;-)
<carlos> doko: sure
<pitti> argh, l-support-en is not installed with amd64/alternate
<ogra> pitti, you broke all edubuntu liveCDs as well 
<xhaker> pitti: does rsynching images still work?
<ogra> pitti, so your script lied
<Keybuk> seb128: Ubuntu Desktop ... Evolution, click "Contacts" ... "Error loading Addressbook"
<pitti> xhaker: sure
<seb128> Keybuk: known
<pitti> ogra: uh? it worked quite fine for the ubuntu ones
<seb128> Keybuk: the message is ugly but actually it works fine
<pitti> ogra: they are too large now?
<seb128> Keybuk: it happens on the first use only
<xhaker> pitti: then it must be my college blocking rsync :S
<ogra> pitti, amd64 and i386 are oversized
<Keybuk> seb128: won't it also do it for the user after install?
<ogra> ppc seems to have survived
<seb128> Keybuk: probably, there is just too many bugs for me to tackle all of them and upstream is not responsive neither
<ogra> infinity, no point in building edubuntu DVDs until thats solved
<pitti> hm, but what about the install CDs? I didn't touch any, neither ubuntu nor edubuntu
<infinity> ogra: Meh, too late, they're half built.
<ogra> pitti, install is fine
<Kamion> infinity: no lives
<Kamion> i.e. no ports daily-live
<infinity> Kamion: Okay, thanks.
<Keybuk> seb128: is evo still maintained by the indians?
<bgertzfield> infinity: OK, the work is done for the Great VMware Player Kernel Package Migration.  I'll test in an hour or so when I'm at work
<bgertzfield> infinity: or do you need the packages right away?
<infinity> bgertzfield: A little later is fine, I have my hands full anyway.
<bgertzfield> infinity: excellent. thanks again for the assistance!
<pitti> Kamion: hmm, http://people.ubuntu.com/~cjwatson/cd-build-logs/ubuntu-daily-20060530.2.log doesn't indicate any overflow, right?
<seb128> Keybuk: I'm not sure, there seems to be less people working on it. Jeffrey Stedfast was working on it again for some time and he moved to some other project again if I understood correctly
<jdub> mvo: what do you think about vmware-player-kernel-modules-686 style metapackages?
<ogra> pitti, all isos are fine apoart from edubuntu live, dont worry about ubuntu
<ogra> pitti, i'll drop the two additional blocks you added at the bottom
<ogra> (in the live seed)
<ogra> pitti, that'd be bn hi ru on i386 and additionally ja ca cy form amd64, do you think that suffices ? 
<bgertzfield> jdub: we worked out a better solution
<jdub> bgertzfield: oh?
<bgertzfield> jdub: all modules for all flavours in an arch will go into a single package that Provides: vmware-player-kernel-modules
<bgertzfield> they're pretty small
<jdub> bgertzfield: ah
<jdub> yeah, that's cool
<HiddenWolf> bgertzfield: the description for your vmware player packages is cut short, you might want to fix that.
<bgertzfield> HiddenWolf: oh? what is the end of the desc?
<jdub> bgertzfield: so the amd64 build of vmware is not just a 32 bit package?
<bgertzfield> oh!
<bgertzfield> HiddenWolf: I see
<bgertzfield> jdub: the kernel modules are native, the user-space is just 32 bit for now
<Kamion> pitti: nope
<jdub> s/package/binary/
<jdub> ah right
<jdub> ok
<Kamion> Riddell: Kubuntu daily is overflowing
<jdub> bgertzfield: is there a spot to configure which network daemons run by default?
<iwj> Kamion: can I delete those yaboot images now ?
<Riddell> Kamion: hmm, ok, thanks
<Kamion> Riddell: Kubuntu/amd64, Kubuntu/i386, Kubuntu/ia64
<infinity> bgertzfield: So, it depends on libc6-i386 and such?
<infinity> bgertzfield: I never did check the amd64 packaging..
<Kamion> also Ubuntu/ia64, ubuntu-server/i386, Xubuntu/powerpc
<Kamion> janimo: ^--
<Kamion> infinity: could you look at the ubuntu-server oversizing?
<janimo> oh, overflow :(
<infinity> Kamion: ubuntu-server oversizing, saywhatnow?
<infinity> Kamion: It used to be tiny...
<ogra> janimo, you ??
<janimo> ogra, well I had to put esound in ;)
<Kamion> CD 2 will only be filled with 230349968 bytes ...
<Kamion> (ubuntu-server)
<Keybuk> 230MB?!
<ogra> janimo, oh, right that as 100s of MB :P
<Kamion> janimo: lesson: never fill CDs up to the brim with language packs
<janimo> Kamion: how much do I need to take off from xubuntu ppc?
<Kamion> CD 2 will only be filled with 521606 bytes ...
<Kamion> ^-- xubuntu/powerpc
<Kamion> pitti generally leaves 5MB clearance
<janimo> Kamion: thanks
* infinity pulls the seeds...
<infinity> Kamion: A 230MB overflow sounds like a pretty big "whoops", given that the ISOs were only 230MB to start with a while back...
<ogra> i you accidentially buil ubuntu server DVDs ? :)
<dholbach> ogra: you're spell checker seems to have problems. :-p
<infinity> Well, okay, they were 400MB, but still.
<ogra> dholbach, nope, there is a big grain of salt in my keyboard ...
<Kamion> ok, who added language-support-{lots} to ubuntu-server?
<ogra> which just got stuck under the D
<infinity> Kamion: That CD2 warning on -server is for the source CD.
<infinity> Yay, false alarm.
<Kamion> oh, so it is.
<Kamion> language-support> sorry that was xubuntu, I knew about that ...
<janimo> Kamion: took out lang-support-pt from ppc
<infinity> That does remind me that I wanted to toss some random langpacks on -server and fill it out a bit, though.
<infinity> pitti: <poke>
<infinity> Typical. :)
<infinity> -24 revision(s) pulled.
<infinity> Go bzr.  Negative revisions.
<Treenaks> infinity: no, it _pulled_ negatively.. it pushed!
<Riddell> kubuntu ia64 is 115MB overflowed?!
<infinity> That seems excessive..
<Kamion> infinity: that means that somebody pushed a merge of lots of revisions
<iwj> This dpkg md5sum diversion upgrade problem - does anyone here have it ?
<Kamion> so 25 revisions -> 1 merge
<infinity> Kamion: Ahh, so my revisions got collapsed?
<mvo> iwj: I have not seen it myself, only got reports about it
<Kamion> infinity: right
<Kamion> people should try to pull rather than merge
<iwj> mvo: I don't understand it at all.  It's completely mystifying.  I tested this when I did it and thought about it quite hard and now I test it again I can't get it to do it.
<iwj> Furthermore, I can't see how that message from dpkg-divert could appear.
<iwj> Because dpkg-divert isn't supposed to rename and do that check unless you pass it --rename which I don't.
<infinity> iwj: What's the bug #?
<iwj> 46590, 42907
<mvo> bug 46590
<Ubugtu> Malone bug 46590 in update-manager "[dist-upgrader]  Upgrading breezy->dapper: coreutils update fails" [Normal,Needs info]  http://launchpad.net/bugs/46590
<iwj> dpkg-divert: rename involves overwriting `/usr/share/man/man1/md5sum.textutils.1.gz' with
<iwj>   different file `/usr/share/man/man1/md5sum.1.gz', not allowed
<infinity> Err, it's undiverting backwards?
<infinity> So it is.
<iwj> I've managed to reproduce it but only by creating a file md5sum.textutils.1.gz.
<infinity> iwj: The diversion is /usr/share/man/man1/md5sum.1.gz, not /usr/share/man/man1/md5sum.textutils.1.gz ... No?
<iwj> The diversion is by dpkg of md5sum.textutils to md5sum.
<infinity> Oh, it IS backwards.  I see.
<infinity> iwj: Then the only problem is this:
<iwj> It's completely batshit.
<infinity>     rm -f /usr/share/man/man1/md5sum.textutils
<infinity> (note the lacking .1.gz)
<iwj> Oh, those rm's are wrong.
<iwj> I didn't even touch those dammit.  I should have eyeballed them more closely.
<iwj> There's still something else wrong.  dpkg-divert shouldn't complain if it's not being asked to rename.
<infinity> --remove implies a rename, if it's removing a rename, no?
<LaserJock> mvo: ping?
<infinity> (ie, it just renames backwards)
<iwj> infinity: No, diversions are always renames in that sense.
<infinity> What else could --remove possibly do, but undo the original --rename diversion?
<mvo> LaserJock: here, but I leave for dinner in <5 minutes
<iwj> --rename means (is supposed to mean) `make the change in the filesystem as well as in the diversion list'.
<mvo> LaserJock: can we talk after that (~30-45min)?
<infinity> iwj: Yes, but --remove (IME) has always actually undone whatever you did in the first place.
<infinity> iwj: So if you renamed, it un-renames.
<LaserJock> mvo: sure, np
<iwj> infinity: No, there is no flag in the database for whether the original call had --rename.
<infinity> iwj: Oh, fair point.
<infinity> iwj: Then I have no idea.  But --remove has always seemed to imply the rename.
<infinity> iwj: In fact, I've relied on that behaviour in the past.
<trappist> I'm trying to rebuild kdelibs to test a patch, and graphvis is a build-dep, but there seems to be no such package.  is there a package floating around somewhere that's not in the repos?
<mvo> iwj, infinity: I'll read the backlog, need to run now
* mvo goes for dinner 
<infinity> trappist: It exists if you spell it correctly (graphviz)
<iwj> infinity: This behaviour has been changed by someone since dpkg 1.4.0.
* ogra wonders what happened to pitty
<ogra> *pitti
<trappist> sigh.  I looked and double- and triple-checked that I was spelling it right and I still missed it.  thanks infinity.
<iwj> In 1.4.0 you don't get --rename on --remove unless you ask for it.
<iwj> In current dpkg it's been broken so --remove always implies --rename.
<iwj> mvo: Never mind, I know what the problems are now.
<iwj> *sigh*
<iwj> Well, I'll fix the coreutils rm and it's obviously too late to fix dpkg-divert.
<infinity> iwj: I'd imagine a fair number of things have changed in the decade since 1.4.0.. :)
<Riddell> trappist: graphviz is in main, join us in #kubuntu-devel if you have KDE questions
<infinity> iwj: Fixing dpkg-divert at this point qould require auditing the Debian archive for every maintainer script that relies on the current broken behaviour and fixing it. :/
<pitti> yay network breakage
<mgalvin> Riddell: #ubuntu-newsroom ;)
<pitti> Kamion: sorry, if you answered something I didn't get it
<pitti> mvo: ping
<ogra> pitti, that'd be bn hi ru on i386 and additionally ja ca cy form amd64, do you think that suffices ? 
<ogra> pitti, i'll drop the two additional blocks you added at the bottom (in the live seed)
<ogra> (sorry wrong order of the sentences now)
<bgertzfield> infinity: Packages are ready.  I'll upload to an apt-get repository on the outside
<bgertzfield> infinity: Since you're not in a big hurry, I'll get them to you in an hour or two
<infinity> pitti: What magic do you use to decide how to fill out a CD with translations?
<infinity> pitti: The server CDs could perhaps use some langpack love.
<pitti> infinity: I have a script for that. Do you need them right now?
<infinity> pitti: I'm working on a few things right now, so "whenever"...
<pitti> ogra: sure
<glatzor_at_the_f> hi, could anyone please confirm the purpose of the repositories in Ubuntu: dapper - will never change, dapper-security - only security updates for dapper, dapper-updates - proposed updates and securityupdates for the installed proposed updates
<glatzor_at_the_f> a guy from sun asked about this
<Kamion> pitti: no overflow for Ubuntu first-class arches, overflows for some others though
<pitti> Kamion: I'll file a bug and attach the logs then; I can install l-s-en from the CD without any problems
<iwj> infinity: auditing> quite so.
<mdz> Riddell: how is the current Kubuntu candidate looking?
<Kamion> glatzor_at_the_f: dapper, dapper-security> correct, dapper-updates> data loss and other high-impact bug fixes
<mdz> ogra: how is the current Edubuntu candidate looking?
<Kamion> (but small, safe bug fixes, usually)
<iwj> infinity: At this stage inventing a new flag to turn off the new (IMO broken) default would be the only thing to do.  Oh well, at least I know I can fix dapper.
<ogra> mdz, live is overflown... testing i386 default install currently
<Riddell> mdz: desktops are all good, alternatives are overflowing so I'm about to rebuild them
<iwj> mdz, Kamion: heads-up, new coreutils on its way.
<mdz> iwj: *beg your pardon*?
<ogra> iwj, haha, good joke :)
<iwj> mdz: see ^.  It breaks on some upgrades due to a typo in the preinst.
<LaserJock> Kamion: in your opinion, could completely broken (segfault on startup or something similar) Universe packages be -updates candidates?
<iwj> bug 46590 etc.
<Ubugtu> Malone bug 46590 in update-manager "[dist-upgrader]  Upgrading breezy->dapper: coreutils update fails" [Normal,Needs info]  http://launchpad.net/bugs/46590
<mdz> iwj: add to DapperReleaseRadar under post-release updates
<infinity> LaserJock: Of course.
<mdz> target dapper-updates
<iwj> mdz: OK.  I don't have a clear idea of which breezy->dapper upgrades will fail as a result of this issue.
<LaserJock> infinity: hmm, thanks. does UVF apply?
<infinity> LaserJock: New upstreams in an already released distribution are frowned upon, yes. :)
<Kamion> LaserJock: yes
<mdz> iwj: fiddling about with fragile diversions in essential packages after Beta is considered harmful
<LaserJock> ok, great. that clears a couple things up.
<Riddell> Kamion, infinity: am about to rebuild kubuntu alternative CDs
<iwj> mdz: Yes, quite.  However in this case I think a review of the debdiff will convince that the change is definitely not harmful.  But it's your call of course.
<mdz> iwj: I mean the change which introduced this bug
<ogra> Riddell, without -meta upload ? 
<infinity> Riddell: Does that mean the DVDs need a respin too, to match?
<BenC> are we only supposed to mark tests that were different from the last time?
<iwj> There was always a bug.
<Riddell> ogra: only ship changed
<BenC> I've boot/install tested the livecd on amd64-k8, and boot/install tested on a G5
<BenC> getting ready to do some sparc64 netboot/installs
<infinity> BenC: Just pass/fail (and notes for failure).
<Riddell> infinity: I don't think so, just some language pack sizing
<ogra> Riddell, lucky you :/ i need a new -live
<BenC> infinity: same URL as before?
<iwj> mdz: I have no tests to prove it of course but I think the proportion of stuff that fails now is smaller than the proportion of stuff that would have failed before.
<infinity> BenC: Yeah, it should be updated to refer to today's images by now.
<BenC> ok
<BenC> BTW, I cannot do any CD installs on sparc
<BenC> none of my equipment can boot CDR
<infinity> Crap.
<mdz> BenC: talk to sfllaw and other sparc owners and see what can be done about that
<Keybuk> seb128: I get the same Evolution Error on a fresh install :-/
<BenC> and they are all SCSI cdrom's so no way to replace it :/
<seb128> Keybuk: as said that's a known issue, you will get it on 100% of the install you do
<Keybuk> meh; why is the UI e-mail choice now only between devolution and thunderbug :-(
<BenC> sfllaw: ping
<seb128> Keybuk: but that's only cosmetic and the only time you click, it actually works after that
<sfllaw> BenC: Pong.
<seb128> Keybuk: the file it complains about is created when it displays the message
<Keybuk> seb128: cosmetic is "the icon looks too much like a rabbit"
<infinity> Keybuk: Hrm?... Mine has mutt in the list.
<pitti> mvo: bug 46338 is still there
<Keybuk> not a "THE SKY IS FALLING" error message
<Ubugtu> Malone bug 46338 in update-manager "language-support-en not installed any more" [Normal,Confirmed]  http://launchpad.net/bugs/46338
<BenC> sfllaw: I cannot do CD boots on sparc, I can only netboot...my equipment doesn't do CDR
<sfllaw> BenC: We appear to have a dearth of useful sparc machines.
<sfllaw> Basically, it's fabbione.
<mdz> iwj: that stuff has been a source of bugs for ages, but I thought it was finally in a stable state in Debian
<fabbione> BenC: i did change that as we agreed before. just slam N/A
<BenC> sfllaw: fabbione asked me to do the cd installs, since I don't think he can do cd installs either
<fabbione> BenC: i will do CD's when i am back to DK next week
<fabbione> it's not an issue
<BenC> ok, NP
<BenC> fabbione has sparc-cd installs covered :)
<sfllaw> Uhm.  I think we might want to get some more working sparc machines.
<sfllaw> Just a hunch.
<infinity> fabbione: Uhh, we're releasing ubuntu-server-sparc.iso, we kinda need to test it.
<fabbione> infinity: no we don't.
<bddebian> heh
<bddebian> Send me a Sparc, I'll test it :-)
<BenC> sfllaw: I have an IDE (e.g. CDROM capable of CDR booting), it's just not where I can get to it
<BenC> my U5 is still in storage
<fabbione> sfllaw, infinity: we will delay sparc release
<seb128> Keybuk: right, evolution sucks but we are no better alternative
<fabbione> sfllaw, infinity: so there is not the same kind of hurry to test cdimages
<sfllaw> BenC: Well, we've got a whole lot more hardware coverage on the other platforms.
<sfllaw> fabbione: All right.  Thanks.
<Kamion> sfllaw, infinity: above is a direction from both mdz and sabdfl, btw
<BenC> sfllaw: we have a lot of sparc hardware, just that it's mostly legacy equipment that is not capable of cd booting
<BenC> I have 6 ultrasparc's to test on, just not CD boot :)
<BenC> I think it's more common for someone to netboot install a sparc than cd boot anyway (because not many people get their hands on a mastered CD for linux that they can boot)
<bddebian> What's a model I would need to test with?  For future reference :-)
<pitti> seb128: can you please ping me when you are done with the wiki page? it's my third failed attempt to get a lock (from different persons, though)
<iwj> mdz: What they have in Debian is exactly what we have in Dapper.  I'll have to mail them about this typo.
<BenC> bddebian: U5/U10 is a good test box
<bddebian> BenC: Thx
<seb128> pitti: done
* bddebian hits sleaze-bay
<zyga> hello
<bddebian> Heya zyga
<iwj> mdz: Of course we've had a different history (the diversion was released by us and not by Debian) so it's possible our users have more trouble with it.
<mdz> sfllaw: please add rescue mode and integrity check test cases to the matrix
<mdz> iwj: pre- or post-sarge?
<iwj> mdz: I don't have my notes here but IIRC the diversion is in sid only, and not in current sid (since they applied my patch).
<iwj> notes> I could dig them out ...
<zyga> I'd like to report that mac mini 10.4.x os X install creates ubuntu-incompatible filesystem and partition table, it is not possible to dual-boot in such configuration
<mjg59> zyga: ?
<zyga> mjg59: there is no way to put ubuntu and os x 10.4.x on mac mini I have, os x installer creates some non-standard partition table
<iwj> What do I need to do to get a copy of the autobuilder's package which seems to be sat in some queue somewhere.
<mjg59> zyga: You haven't described the failure and you haven't uniquely identified the hardware
<iwj> cf https://launchpad.net/distros/ubuntu/dapper/i386/firefox-themes-ubuntu vs https://launchpad.net/distros/ubuntu/+source/ubuntu-php-firefox-human
<ivoks> zyga: you are using ppc, right? :)
<zyga> ivoks: right
<infinity> iwj: Oh, I'll publish it.  Thanks for the reminder.
<Kamion> infinity: hang on
<seb128> pitti: got the lock that time? :)
<infinity> Kamion: Oh...?
<Kamion> infinity: might as well publish thunderbird-quickfile while we're at it
<pitti> seb128: yep, thanks
<Kamion> I'll just new it
<iwj> infinity: Thanks.
<Kinnison> -> dinner with mother
<zyga> mjg59: unique hardware: mac mini 1.25GHz, installed from 10.4 mac mini os x install cd
<zyga> s/cd/dvd/
<infinity> Kamion: Was going to do that too, yes.
<infinity> Kamion: But if you're there first. :)
<seb128> pitti: np ;)
<zyga> I really don't know how to describe the hardware more
<iwj> infinity: If you could let me know when I should expect it that would be great so I can test this new firefox (don't ask).
<zyga> the software bit is that no tool I have can see the os x-created partition layout
<Kamion> accepted
<pitti> seb128: bah, someone else broke my lock now. GRR
<infinity> iwj: BTW, if you follow that source link through (click the version, then click the i386 build, then click on the "resulting binary"), you can download the binary now.
<zyga> the installer asks me to create "partition label" of some kind, there are quite a few available
* infinity notes tha tthis is true even for some areas where it shouldn't be, and should really be fixed...
<iwj> infinity: Ooo.
<ogra> iwj, be careful, could be infinity is allergic to three O's and a dot currently ;)
<ogra> even though your dot was at the end :)
* infinity flies into a blinding rage for no apparent reason.
<iwj> Oh, there it is, hiding in one of those noise boxes in the corner.  Thanks, infinity.
<Keybuk> infinity: "Everything will be OK"
<zyga> mjg59: what else can I do to investigate this?
<fabbione> pitti: did you finish to edit Testing/Current?
<pitti> fabbione: no, it took me some time to merge my changes with the one who broke my log
<fabbione> ok
<ogra> pitti, hal should behave the same on all arches, right ? 
<ogra> pitti, my usb DVD writer offers me every speed from 1x to 48x on amd64 and i386 but only 15x and 32x on powerpc :)
<ogra> (in n-c-b that is)
<mdke> elmo: pong
<pitti> fabbione: done now
<pitti> fabbione, dholbach: your amd64 installs are marked with PASS - have you really got language-support-en installed?
<jdub> ogra: those curly endian errors, they'll bite you every time!
<pitti> ogra: well, 'behave' only modulo keys and attribures
<pitti> ogra: no idea about that bug, though
<ogra> its just funny, i'd not really consider it a bug
<fabbione> pitti: thanks
<ogra> jdub, yeah, that might be it
<pitti> sfllaw: sure that we need to keep the older test results? they make editing the page a pain since it takes very long to find stuff
<jdub> ogra: pfft 8)
<ogra> we should urgently fall back to the sigle pages for every derivative, editing that huge thing is a pain
<pitti> ogra++
<ogra> mdz, can you wave my edubuntu-meta through to fix edubuntu-live please
<sfllaw> ogra: All right.
<sfllaw> I will split them off.
<ogra> next release, for now lets kepp what we have to avoid confusuin
<ogra> *confusion too
<sfllaw> Ooh.  Confused.
<infinity> ogra: I'll send it through.
<ogra> infinity, thanks
<pitti> Kamion: I created and attached the logs to bug 47537
<Ubugtu> Malone bug 47537 in debian-installer "amd64/alternate does not install language-support-en" [Normal,Unconfirmed]  http://launchpad.net/bugs/47537
<mdz> ogra: what's up with edubuntu-meta?
<janimo> infinity: is there a way to automatically rebuild a package and bump ubuntu revno without an upload?
<pitti> janimo: no
<ogra> mdz, pittis langpack addition was a bit optimistic for edubuntu-live :) 
<pitti> ogra: still strange; did you add anything else, or were the sizes just wrong?
<ogra> pitti, i didnt touch seeds or -meta since a while
<ogra> surely not after you
<infinity> ogra: I see no upload...
<pitti> ogra: hm, still mysterious. sorry, though
<bgertzfield> infinity: OK, I'm regenerating the vmware-player apt repository now
<Keybuk> infinity: there is no upload ...
<infinity> Keybuk: Oh, thpt. :)
<ogra> infinity, 
<ogra> ...
<ogra> Good signature on ../edubuntu-meta_0.80.dsc.
<ogra> Uploading via ftp edubuntu-meta_0.80.dsc: done.
<ogra> Uploading via ftp edubuntu-meta_0.80.tar.gz: done.
<ogra> Uploading via ftp edubuntu-meta_0.80_source.changes: done.
<ogra> Successfully uploaded packages.
<ogra> Not running dinstall.
<infinity> ogra: Keybuk got to it before me.
<ogra> should be there
<ogra> ah
<ogra> heh, approval race :)
<Keybuk> infinity: actually I quickly moved it elsewhere while mdz queried it, to save your face ;)
<infinity> Keybuk: I was going to check the changes and make sure it was just langpack dropping. :)
<Keybuk> oh, I put an ubuntu-queue symlink in ~lp_queue
<Keybuk> because /srv/la<tab>grr was annoying me
<infinity> Yeah, that tab completion irritates me too.
<infinity> Especially with the latency between here and the DC...
<infinity> (~350ms, on a good day)
<Keybuk> so mv ubuntu-queue/incoming/* manual-queue/incoming
<Keybuk> etc.
<Keybuk> much easier
* infinity nods.
<pitti> infinity: http://people.ubuntu.com/~pitti/langpacks/langpacksize.txt
* ogra is off for some ppc testing
<infinity> pitti: And these are in some vague order of "worthiness"? :)
<pitti> infinity: right
<infinity> pitti: How is that determined?
<pitti> infinity: G is base+gnome, K is base+KDE, G+K is everything
<infinity> pitti: Cause ubuntu-server has a different audience from desktop..
<pitti> infinity: English, then the world's top 11, then alphabetically
<infinity> pitti: (For instance, lots of pl and cz users..)
<bgertzfield> infinity: Want me to send you a diff of the debian/ directory for the new vmware-player-kernel package?
<pitti> infinity: feel free to shuffle around :) then you just loose the cumulative sum
<infinity> Err, cs.
<infinity> bgertzfield: I can manage that on my own.  I'm SMRT that way.
<infinity> bgertzfield: Just give me a few moments to gather my scattered thoughts, and I'll grab the new packages and poke them with a stick.
<bgertzfield> infinity: OK.  I'm uploading them to the outside now.
<infinity> bgertzfield: There's no rush anyway, unless I missed the memo where we were going to ship these on the CD. :)
<bgertzfield> infinity: No, no CD. :)
<bgertzfield> Yeah, I know there isn't a rush, I just like to do a good job. :)
<pitti> I'm off to further CD testing
<Tonio_> hi
<bddebian> Hello Tonio_
<Keybuk> infinity: when you're done running the publisher, could you run it again?
<Keybuk> who needs cron.daily when you have cron.infinity?
<infinity> Keybuk: Yeah, I was planning on it already.
<infinity> I should just put it in a while loop.
<Keybuk> infinity: we could put publish-distro in a while loop, and just stop it every now and then to run apt-ftparchive? :p
<infinity> Keybuk: Actually, if we can get the soyuz kids to guarantee that publishing and archive maintenance won't stomp on each other (they've been non-committal on this), that idea's not as insane as it sounds.
<infinity> Keybuk: It's more or less how the rest of the machinery works, why not the publisher as well?
<Keybuk> infinity: I'm told these days that things are definitely happening transactionallish
<Keybuk> I've certainly not worried about whether or not p-d is running
<Keybuk> we've only come across one "interesting behaviour"
<Keybuk> (when you have a Pending already, e.g. a finished build, and try and change the overrides)
* janimo goes testing xubuntu desktop
<bgertzfield> infinity: OK.  Packages are updated:
<bgertzfield> deb http://foxden.org/apt sid non-free
<bgertzfield> deb-src http://foxden.org/apt sid non-free
<bgertzfield> infinity: I updated both vmware-player (to have the .orig.tar.gz) and vmware-player-kernel-2.6.15 (to use one megapackage for all the kernel modules).  I'm testing the packages now
<iwj> Has there been any movement on the stuff I report in DapperReleaseNotes/Kubuntu/UpgradeProblem ?
<darius_> 30557
<Riddell> iwj: no, that needs feature changes to adept
<darius_> bug 30557
<Ubugtu> Malone bug 30557 in linux-source-2.6.15 "cpu idle time in /proc/stat wrong" [Normal,Confirmed]  http://launchpad.net/bugs/30557
<infinity> darius_: Yes, we know.  It won't be fixed before release.  Please stop announcing the bug every 24 hours.
<darius_> infinity: I didn't think I had
<infinity> darius_: I recall you pointing it outa day or two ago, and perhaps one other time before that.
<darius_> infinity: heck, I don't visit here every 24 hours - but thanks for letting me know that it won't make release
<infinity> darius_: Sorry if I maligned you by implying that you've done it every 24 hours for the last month or so. :)
<iwj> Riddell: No, obviously we're not changing adept now.  As you see I suggest changing the release notes to document an upgrade procedure that works.
<iwj> Riddell: So, is anything being done about improving the release notes ?
<infinity> Oh crap.  We never did anything about changing the CD icon in Windows.  Do we care?
<infinity> mdz: ^^^
<mdz> infinity: no
<infinity> Right.  I'll TODO it for edgy.
<Riddell> iwj: I've upgraded with adept numberous times and not had any problems
<infinity> Mithrandir: Are you doing DVD testing?
<iwj> Riddell: Did you read my wiki page ?  Do you agree or disagree with these criticisms ?
<iwj> Or are you saying that I imagined the whole thing being so broken it couldn't reboot ?
<iwj> My point is that the user will have a much nicer experience if we tell them to get out a konsole and a copy of some dumb text editor.
<iwj> Command line notwithstanding.
<iwj> Riddell: Also, I take it 46404 isn't going to be fixed ?
<mvo> bgertzfield: do you have binary package (for amd64) in that repisitory as well? I would give it a test then
<iwj> Not that I'm sure it's RC but it's quite alarming and probably ought to be noted somewhere in an errata list.
<Riddell> iwj: 46404 is fixed, I thought I put it in the changelog but maybe not
<iwj> Riddell: I didn't look at the changelog I'm afraid.
<iwj> If it's fixed then excellent.
<iwj> I'll make sure to test it :-).
<Riddell> no but malone should close it if it was
<iwj> Still listed as `unconfirmed' here.
<Kamion> er ... changelogs don't auto-close bugs in malone
<Kamion> you have to do that manually
<Riddell> iwj: dcop and other kde things can break after upgrading until you restart kde but that won't change if you upgrade from a command line
<iwj> Riddell: Yes, but if you try to do the install and reboot from the command line you don't see any of the damage.
<Riddell> iwj: and I've not had a problem with being able to log out/reboot after ugrading but I'll look out for that when I test it today and tomorrow
<iwj> Also, please see my other comments about how editing your sources.list in adept is a pita.
<iwj> I'll try it again.  It's possible that my naive attempts to do the tests after upgrading (like the release notes suggest you might be able to) broke it more badly.
<Riddell> Kamion: hmm, I thought it did for some reason
<iwj> Do you not agree that editing sources.list in a text editor would be easier than in adept ?
<iwj> I mean, I hate vi but I'd rather use it than adept for this job.
<iwj> I'm sure the users would be able to cope with nano.
<Riddell> iwj: i've got my girlfriend using adept, I know I won't get her using nano or even a GUI text editor for sources.list
<iwj> It doesn't even have search-and-replace !
<iwj> And you _have_ to run apt-cdrom if you've got no network connection.
<iwj> (Even if you do have internet downloading all of dapper might be too slow and/or expensive.)
<iwj> So I think the bottom line is that not specifying in the release notes a sane way to do the required sources.list edits is an RC bug and because I've been asked to test the upgrade I have reported a fail for this reason.
<lemsx1> brb
<iwj> I can and will test the resulting system after the upgrade to see if it works but before I look at the upgrade process again with a testing pov, this issue should be resolved.
<iwj> It could be resolved by (a) fixing the release notes to suggest something I think someone could manage to do without throwing the computer out of the window or (b) being told by mdz or someone that they disagreed and I was being overruled.
<iwj> s/being told/me &/
<Keybuk> infinity: need another publisher run
<infinity> Lies.
<Keybuk> ubuntu-meta in outdate
<Keybuk> ^ed
<iwj> Riddell: Are you planning on (a) or (b) or (c) ignore the test failure and hope it goes away ?
<infinity> Yeah, checking if it built everything.
<infinity> s/everything/everywhere/
<infinity> Yup, looks good, publishing.
<iwj> Riddell: Sorry to be behaving like an arsehole about this but I'm looking for some concrete and robust response and haven't had it so far.
<Keybuk> RIDDELL!!!!!!!
<bgertzfield> infinity: Just realized I included the wrong rev of the kernel package in the apt repository on foxden.org.  Fixing.
<infinity> bgertzfield: S'ok, I've not gotten to you yet anyway. :)
<Keybuk> Riddell: Kubuntu screen got locked by switching VTs on Live CD
<bgertzfield> infinity: Lucky me ;)
<iwj> Keybuk: I think I've scared him off.
<Keybuk> iwj: you bad, bad man
<doko> testing edubuntu and ubuntu dvd i386 images ...
<iwj> Riddell: I have to go and have some dinner etc.  Let me know what we're going to do about these problems.  Feel free to contact the Management and get them to overrule me.  I look forward to it :-).
<mdz> iwj: summary of the issue?
<mdz> iwj: problem with the instructions, software defect, both?
<bgertzfield> infinity: OK, I just confirmed the out-of-the-box install "just works" with the new combined kernel module package.
<ogra> meh, ppc edubuntu install ended up without a lo interface
<ogra> did anybody else see that ? (non networked install)
<LaserJock> mvo: back?
<mvo> LaserJock: yes
<bgertzfield> mvo: ok, my apt repository is updated with the new kernel module package
<bgertzfield> infinity: apt repository updated
<bgertzfield> mvo: go ahead and grab the new revisions (I also bumped vmware-player to correctly use a .orig.tar.gz and fix a missing word in the description)
<bgertzfield> have to idle for a few.
<jdub> bgertzfield, mvo: you guys are teh rock. ;-)
<bgertzfield> jdub: I live to give. :)
<infinity> ogra: ping me when you release your lock on Testing/Current
<ogra> will do
<mvo> jdub: don't forget infinity, he is certainly a rockstar as well :-D
<Riddell> mdz: he says the adept repositories manager is less user friendly than text editor on sources.list, which I disagree with, and KDE breaks after upgrade until it's restarted which is true but seems to have broken worse for him than I've seen
<infinity> mvo: are you doing server/amd64 right now?  If not, I'll take it off your hands.
<Riddell> Keybuk: switching VTs by hand or quitting X?
<Keybuk> Riddell: switch user thingy
<mvo> infinity: not right now, feel free (and thanks!)
<Keybuk> Riddell: also Lock Session happens to have the same effect
<ogra> infinity, done
<ogra> did anybody test powerpc alternate already ? 
<bgertzfield> OK, I'm out for a bit.
<mvo> bye bgertzfield
<ogra> i ended up with no lo device on a non networked edubuntu default install over here
<ogra> anybody else seen that on ppc ?
<infinity> Erm.  I'm supposed to test the "rescue" mode of the desktop/live CD, but I'm pretty danged sure it doesn't have one...
<infinity> Am I an idiot, or should that row be removed from the table? :)
<infinity> (Answering both in the affirmative may also be correct)
<ogra> heh, intrgrity check is a bit "jumpy" on the screen
<ogra> *integrity
<mvo> bgertzfield: \o/ works now
* mvo hugs bgertzfield
<infinity> Oh, heh, someone did change the logo on the CD, I just wasn't paying attention.
<infinity> Yay.
<infinity> Kamion: "Ubuntu 6.06 amd6" <--- Is that the label limit for ISO9660/Joliet?
<pitti> Keybuk: since you had that problem as well: the installer offers resizing if there's a single large ext3 partition (and a swap)
<pitti> Keybuk: I just got that, it was the first time I got resizing offered (and it worked fine)
<ogra> erm, Kamion i have no expert mode on edubuntu anymore ? is that right ?
<pitti> sfllaw: am I right that the desktop CD doesn't offer a special 'rescue' mode?
<infinity> pitti: I'm pretty sure it doesn't.  I just made the same comment 2 minutes ago. :)
<pitti> sfllaw: shall I mark that line with N/A or remove it entirely?
<pitti> infinity: :)
<infinity> pitti: Feel free to just remove that row from the list.
<ogra> infinity, seems edubuntu-live 0.80 is in the archive, if you dont mind i'd like a new liveFS
<infinity> ogra: I don't mind in the least.
<ogra> :)
<infinity> ogra: Spinning.
<ogra> thanks :)
<Tonio_> mdz: ping ?
<pitti> infinity: hm, we don't have alternate/server, shall I add it?
<infinity> pitti: Err, what?
<infinity> pitti: Oh, you mean doing "server" from the aternate CD?
<ogra> heh
<pitti> infinity: installing the alternative CD in 'server' mode 
<pitti> right
* pitti adds, can't hurt
<Tonio_> mdz: we have a problem concerninf video streaming in konqueror
<infinity> pitti: Yeah, sure.  Add that.  I'd prefer if we had just removed the option from the menu or renamed it to something else, but way too late now.
* ogra just thought about dapper-desktop-server-$arch.iso
<Tonio_> mdz: it crashes on almost all streaming file due to a bug in kaffeine
<infinity> pitti: It is in the menu right, not just a command-line option for the clueful?
<infinity> pitti: If it's in the menu, it should definitely be tested, IMO.
<Tonio_> mdz: we have a fix readdy that just changes mimetypes asociations and that works pretty well
<Tonio_> mdz: would you agree with such an upload (concerns kubuntu-default-settings package)
<pitti> infinity: it is in the menu
<Tonio_> mdz: I know it is not critical, but since konqueror is the masterpiece of kde and default webbrowser, it is probably to have it as stable as possible...
<dholbach> hum, after I did changes with the oem user, I ran sudo oem-config-prepare and rebooted, created a new user, but the changes I made seem gone?
* pitti grabs amd64 and ppc expert installs now which need testing
<ogra> mdz, edubuntu shipit is safe (i386 install all fine)
<infinity> dholbach: What changes did you make?
<seb128> ogra: I'm going to do edubuntu on desktop CD amd64 now 
<dholbach> infinity: changed background, created a symlink to the book excerpt
<ogra> seb128, live ? 
<infinity> dholbach: Changed the oem user's background?
<seb128> ogra: ah right, you still use the old naming
<seb128> ogra: yep, ubiquity
<ogra> seb128, thats overflown, new lifefs'es are building ytm
<dholbach> infinity: yes - was that wrong?
<infinity> dholbach: Cause he gets deleted.  As does his ~
<ogra> *atm
<seb128> ogra: and install?
<infinity> dholbach: You kinda want to be making system-global changes. :)
<ogra> install is good to test
<seb128> I'll do install amd64 then
<ogra> thanks :)
<dholbach> infinity: ok, I see :-p
<infinity> dholbach: The oem user is only there so you have something to log in as.
<seb128> np
<ogra> i'm a bit worried about that ppc loopback device thing here
<ogra> who else will do ppc testing ?
<dholbach> thanks infinity
<ogra> i'd like to confirm that it works in ubuntu and i'm just crazy or something
<mvo> fabbione: how do I a netinst with ubuntu-server? or is this the normal install with "server"
<pitti> erm, dumb question: how do I get expert mode on amd64? on ppc I have it in the yaboot menu, but it's not in the gfxboot menu and F6 doesn't help either
<ogra> where do you have a gfxboot menu on ppc ? 
<fabbione> mvo: no you need to setup tftpd/dhcpd to netboot/netinstall from archive.ubuntu.com
<ogra> oh, nm
<infinity> Oh wow, keyboard-detection sure if fugly without a framebuffer.
<mvo> fabbione: I did that, I wonder if there is a special "netboot" image or if I use the one that I used to netboot the normal install
<infinity> "Please type one of the following black squares"
<fabbione> mvo: netboot images are all the same
<mvo> fabbione: right. so I type "server" and get the server install there?
<mdz> Tonio_: I already approved that last week; did it not get uploaded?
<fabbione> mvo: grab the one from archive.u.c/ubuntu/dists/dapper/main/install-i386/
<fabbione> mvo: i386? yes
<Tonio_> mdz: only half of the changes.... riddell didn't use the good debdiff I sent him
<Kamion> $ isoinfo -d -i cdimage/www/full/daily/current/dapper-alternate-amd64.iso
<mvo> fabbione: ok, that is what I needed to know, thanks
<Kamion> Volume id: Ubuntu 6.06 amd64
<Kamion> infinity: ^--
<infinity> kubuntu-default-settings (1:6.06-21)Add application/x-mplayer2 to profilerc to make KMPlayer the default Konqueror plugin
<Tonio_> I have a package here correcting the issue, si if you accept, we can upload it right now
<infinity> Tonio_: ^^^
<infinity> Tonio_: Was that not the change?
<infinity> Kamion: Ahh, so Windows is cutting it off.
<Kamion> ogra: sorry, what about edubuntu expert?
<infinity> Kamion: Suck.
<Tonio_> infinity: for streaming we also need to associate realaudio mimetype to kmplayer
<ogra> Kamion, there is no entry for expert in the install CD anymore
<ogra> Kamion, was that intentional ? 
<Kamion> ogra: powerpc loopback> did you skip netcfg by going back to the installer main menu, rather than by telling netcfg "don't configure network"?
<Kamion> ogra: no, which arch?
<Keybuk> ogra: you've just discovered the first test for worthiness of the "expert" option
<Kamion> ogra: oh, is this a gfxboot-using arch?
<ogra> Kamion, i left it fail on the broadcom card
<Tonio_> mdz, infinity: and concerning audio streaming, the issue isn't resolved at all....
<ogra> Kamion, yep i386
<pitti> mvo: do you have any idea about that disappearing l-s-en?
<Kamion> ogra: press F6 ("Other Options"), then F6 again to toggle between normal and expert modes
<Tonio_> mdz: that's why I think a "last of the latest" upload is a good idea (if you are okay of course)
<infinity> Tonio_: Argh, we're well into CD testing at this point.  I'd say these kinds of changes are ideal for dapper-updates.
<infinity> mdz: ^^^
<mvo> pitti: that is fixed now in my tests (i386 upgrade) 
<pitti> Kamion: ah, thanks, that was my question as well
<ogra> Kamion, i'm fine with it not being prominently available though
<mvo> pitti: amd64 upgrade is still runing
<pitti> mvo: did you upload a new version this afternoon?
<mvo> pitti: no
<ogra> Kamion, i just wasnt sure if it was removed due to the "server" mode removal
<pitti> mvo: I still got it on ppc today
<Kamion> ogra: nah, it's been in that position in gfxboot for months
<mvo> pitti: hmmmmm
<ogra> not in my last tests
<Kamion> ogra: I'm sorry, it really has
<ogra> there was an expert menu item
<Tonio_> infinity: I didn't consider the shipit process.... is that the reason icons changes on xubuntu-default-settings have still been possible today ?
* pitti tries again to find amd64/expert install, bbl
<ogra> Kamion, i'm sure jsgotangco and cbx33 will proof me, they both tested it in RC from the menu...
<mdz> Tonio_: we're much of the way through a many-hour-long regression test; we're only stopping now for true showstoppers
<Kamion> Tonio_: those sneaked through without approval
<mdz> Tonio_: I suggest queueing your upload for dapper-updates
<Tonio_> mdz: okay, thanks !
<Tonio_> Kamion: thanks for the info
<ogra> Kamion, any ide about the ppc loopback device ? 
<Kamion> ogra: well, I don't know, you can look through the history of tools/boot/dapper/boot-i386 in http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/ if you like
<Kamion> ogra: could I see /var/log/installer/syslog?
<ogra> sure
<ogra> Kamion, http://people.ubuntu.com/~ogra/syslog
<Firerabbit> https://launchpad.net/distros/ubuntu/+bug/45223 someone on here seems to claim that if "pmi capabilities" inclues 'suspend' then the option should show up in the quit window, however on my machine it does not, is this a wide-spread issue?
<Ubugtu> Malone bug 45223 in Ubuntu "Sleep not present in Dapper 6.06" [Normal,Needs info]  
<infinity> Okay, they probbaly don't work, and I probably don't care, but if anyone has the hardware, Ubnutu desktop CDs for {sparc,ia64,hppa} are built and current.
<mdz> Mithrandir: ping
<Kamion> ogra: interesting, you didn't back up from netcfg, so it's not that bug ...
<ogra> Kamion, want me to redo that install with the non wireless card instead (note i have no wired network around, so i cant test networked install) looks like its related to the firmware
<Kamion> ogra: give me a few minutes to investigate
<ogra> ok
<mdz> Riddell: you said the desktop CDs for Kubuntu were good, but I don't see test results; please update the table
<Firerabbit> I would be happy to investigate this problem further if someone can give me a little bit of background information on what changed that broke this.
<ogra> infinity, how's my livefs build doing ? 
<Kamion> ogra: can I see /etc/network/interfaces too please?
<Lure> Firerabbit: have noticed this with RC when testing Ubuntu (Kubuntu user otherwise)
<infinity> ogra: Still waiting on amd64 and powerpc.  I'll spin the ISOs as soon as it's done.
<ogra> infinity, oh, thanks ;)
<FireRabbit> Lure: does the KDE logout window also not include the option?
<FireRabbit> or is the problem specific to GNOME?
<Lure> Firerabbit: #ubuntu-laptop may be better place though (release is being prepared here)
<ogra> Kamion, oooh, thats intresting, http://people.ubuntu.com/~ogra/interfaces
<FireRabbit> okay, I was not aware of that channel, thanks.
<Kamion> not an installer bug then
<Kamion> I'd try to figure out why the networking scripts aren't bringing up lo
<ogra> i tried ifupping lo
<ogra> but it just returned quietly
<ogra> (without giving me a device)
* ogra reboots to check again
<LaserJock> infinity: I uploaded a 1 line bug fix for  mopac7 to Universe, can you process that when you have a chance? Thanks
<infinity> bgertzfield: Around?
<bgertzfield> infinity: Yes
<infinity> bgertzfield: Okay, I still have issues with the vmware stuff. :)
<bgertzfield> infinity: OK, what's up
<infinity> bgertzfield: You've not allowed for upgrades in any way.
<bgertzfield> I punted on the version issue mostly.  What do you suggest?
<infinity> bgertzfield: If a kernel ABI bump happens, the kernel and LRM will upgrade, your modules won't.
<bgertzfield> Is there a tight dependency from the kernel on the LRM ABI?
<bgertzfield> My thought was when a kernel ABI bump would happen, we would update the vmware-player-modules package.
<infinity> bgertzfield: vmware-player -> Depends: vmware-player-kernel-modules -> Depends: vmware-player-kernel-modules-$(latest-abi) | vmware-player-kernel-modules-custom
<infinity> bgertzfield: ie: make vmware-player-kernel-modules a real (empty) package, instead of a virtual package.
<bgertzfield> so you would suggest making an empty vmware-player-kernel-modules package with only dependencies?
<bgertzfield> this won't fix the problem, though, right? $(latest-abi) won't force the user to upgrade the package
<infinity> bgertzfield: Yeah, that way, when vmware-player-kernel-modules is upgraded, the new -2.6.15-24 package will get pulled in.
<infinity> bgertzfield: Then they'll have both on the system.
<bgertzfield> I see.
<bgertzfield> So we condition it on vmware-player-kernel-modules getting updated.
<bgertzfield> Makes sense!
<bgertzfield> That'll be easy.
<infinity> bgertzfield: Yup.  I look forward to seeing the change.  Then I'll be happy to sponsor these and get them in ASAP.
<bgertzfield> infinity: Fantastic.
<bgertzfield> I'll make the empty package Architecture: any
<ogra> Kamion, this time i got an error message from ifup
<ogra> Kamion, it complains about a malformed line 18 in interfaces
<ogra> (missing essid)
<dholbach> can somebody who burned "alternate cd, ubuntu i386" already check the "rescue" and "check" options and update those on the table?
<Kamion> ogra: oh I see
<Kamion> hmm
<ogra> Kamion, not sure if thats really critical though
<infinity> dholbach: I can do 'check' in vmware.  'rescue' might be tougher. :)
<dholbach> hehe
<ogra> sounds like something we can cover in the known issues section+
<dholbach> i can plug the disk containing the isos back to my amd64 later and then burn and test it, it's not a big deal
* dholbach waits for expert alternate install to end on amd64
<infinity> Make my LAMP install go faster!
<infinity> I really should have plugged one of Zofia's new SATA disks in to install to.. .Much faster...
<thom> infinity: would it help if i got out and pushed?
<infinity> Though, the crazy SATA/IDE mix on her system is good for testing grub-installer corner cases.
<infinity> thom: You could always download ISOs and help test.
<infinity> thom: Your name's still in enough changelogs here to incriminate you. :P
<dholbach> haha
<dholbach> yeah, thom, grab a seat and join in the efforts on http://wiki.ubuntu.com/Testing/Current
<iwj> mdz: both software defects and problems with the instructions; I think the best way to avoid the defects is to change the instructions to avoid the software.  https://wiki.ubuntu.com/DapperReleaseNotes/Kubuntu/UpgradeProblems has what I wrote about it.
* iwj goes back to dinner.
<elmo> mdke: it was about the wiki licensing stuff - could you catch up on the recent CC meeting, and give us some feedback?
<mdke> elmo: oh, right. I'll have a look yeah
<bgertzfield> infinity: how's this look?
<bgertzfield> deb http://vmweb.vmware.com/~beng/apt sid non-free
<bgertzfield> oops
<bgertzfield> stupid xterm copy and paste :)
<bgertzfield>  Package: vmware-player-kernel-modules
<bgertzfield>  Version: 2.6.15.10-6
<mdke> elmo: one line summary? did it go alright?
<bgertzfield>  Depends: vmware-player-kernel-modules-2.6.15-23 | vmware-player-kernel-modules-custom
<bgertzfield> there we go.
<infinity> bgertzfield: And the depends in generated on the fly, I assume.
<bgertzfield> infinity: naturally
<bgertzfield> so if the user builds a custom kernel package, we assume they know what they're doing and they can track their own dependencies.
<elmo> mdke: some people were concerned with making everything PD - wondering if we could default to PD, but make a list of acceptable licenses available for folks to choose from.  also concerns about embedding/attaching non-PD material (screenshots, themes, GPL code, etc.)
<infinity> bgertzfield: Right, that was the idea.
<bgertzfield> OK, great.  I'll give these a quick test and upload 'em.
<infinity> Oh, it's not uploaded yet?  I was about to go have a look. :)
<bgertzfield> it takes me a minute to upload them to the outside. I'll do so now
<infinity> bgertzfield: Oh, a little late to fix it now, but I assume that 2.6.15.10-5 version number was derived from LRM? :)
<thom> infinity: if i actually had machines available i would :/
<bgertzfield> infinity: er, yeah.
<bgertzfield> I wasn't sure where that came from
<infinity> bgertzfield: Yeah, "oops". :)
<mdke> elmo: yeah, I saw that on the agenda. I'm not sure if it's a problem in practice or not, I'll catch up on the log. Maybe an idea would be free-for-all on the main wiki, PD on the documentation wiki
<bgertzfield> what exactly is the first part supposed to mean?
<Keybuk> thom: borrow one of mjg59's thousands
<bgertzfield> was it originally the ABI?
<infinity> bgertzfield: LRM's version starts out at "KVER" (ie: 2.6.15), then gets revved every time I have to re-roll the orig.tar.gz for new upstream bits.
<bgertzfield> infinity: oh. I see. but since I am upstream, I don't need that.
<infinity> bgertzfield: Well, you would need to do sometihng similar if you update your orig.tar.gz, but it's still for kernel 2.6.15..
<bgertzfield> infinity: ah. yeah
<bgertzfield> ok, I'll leave it how it is. :)
<bgertzfield> thanks for explaining how it works
<infinity> bgertzfield: Or, build your version differently.. Say 2.6.15+1.0.1-1
<bgertzfield> right
<bgertzfield> Written down as a TODO. :)
<infinity> bgertzfield: Yeah, you can revisit versioning in about a week when you upload 2.6.17 modules to edgy. :)
<bgertzfield> woo hoo!
<infinity> Am I just easily impressed because I get a kick every time I do an LVM install and it "just works"?
<infinity> Probably easily impressed, but still cool.
<bgertzfield> Scary. ):
<bgertzfield> :)
<thom> infinity: i'm the same way, actually :-)
<ogra> YAY, edubuntu live isos have a sane size
<Kamion> ogra: netcfg fix committed upstream
<infinity> ogra: Oh, yeah, edubuntu ISOs done, BTW. :)
<ogra> infinity, heh
<ogra> Kamion, i really think we can keep that for the "known issues" 
<Kamion> I'm not sure it makes sense to fix it now though; I think it must have been like that for some time
<Kamion> ogra: yeah
<infinity> pitti: Thanks for taking the amd64/alternate stuff...
<infinity> mvo: Can you do ubuntu-server/i386 netboot as well, since you already have it all set up there?
<mvo> infinity: sure
<zyga> hello again
<mvo> infinity: just noted that I burned the server cd for nothing, but thanks a lot for taking it :)
<infinity> mvo: You can test too, if you want.  I don't mind double-coverage on the server stuff. :)  (I'm doing i386, despite mdz having tested it already..)
<bgertzfield> infinity, mvo: 5 minutes 'til the "last" packages are up. (hah)
<mvo> infinity: I will 
<infinity> CD integrity check + vmware + loppback ISO = Yay.
<mvo> bgertzfield: nice!
<pitti> dholbach: ping
<dholbach> pitti: pong
<pitti> infinity: no problem, I can give my desktop something to do while I do ppc tests :)
<infinity> Hrm, that was a special bug...
<pitti> dholbach: do you have l-support-en installed with amd64/alternate? I don't (both with normal and expert install)
<bgertzfield> mvo: made one change at infinity's suggestion to our last version, so we can track kernel abi changes better
<infinity> Kamion: Ever seen the d-i CD integrity check loop?  (Did the check, said it was okay, hit "continue" -- the only button, fwiw -- and then it did the check again. :)
<dholbach> pitti: i'll boot back and check
<infinity> Kamion: It rebooted after the second check, so I wasn't stuck there forever. :)
<mvo> bgertzfield: yeah, noticed (lurk-mode :)
<bgertzfield> mvo: good
<pitti> dholbach: I don't have much luck with l-s-en today :/
<bgertzfield> oops. I made my empty package arch: any instead of all. rebuilding.
* mvo hugs pitti
<bgertzfield> those could really have had better names.
<bgertzfield> how about "every" and "whatever"? so much clearer
<bgertzfield> (just kidding)
<infinity> bgertzfield: Heh.
<pitti> dholbach: chroot should be enough :)
<infinity> pitti: Err, what's supposed to install l-s-en?  d-i?
<infinity> pitti: (based on the installer language, or..?)
<pitti> infinity: l-s-en should always be installed, regardless of the language
<Kamion> infinity: I thought Mithrandir fixed that ages ago
<infinity> Kamion: Evidently not.
<pitti> infinity: that works fine on ppc, and has worked on amd64 in the past, too, but not today (for me at least)
<infinity> pitti: Is this also meant to happen on ubuquity installs, cause it doesn't...
<pitti> infinity: funny, with ubiquity it works here
<infinity> Oh, hah.  I'm sitting here wondering why the vmnet bridge isn't working...
<pitti> infinity: just not with alternate
<infinity> WOULD HELP IF YOU PLUGGED IN A CABLE INSTEAD OF USING WIRELESS, RETARD.
* infinity grabs a snack and a drink to refresh himself after that stupidity.
<pitti> Kamion: uh, yes, I said no to 'download l-s' because I don't have network here
* mvo makes another tea and prepares for a long night
<pitti> Kamion: (it's currently broken and I have to manually switch to modem)
<Kamion> pitti: right, so it didn't :-)
<pitti> Kamion: but l-s-en doesn't need to be downloaded...
<Kamion> ah, yeah, I suppose that's sort of a bug
<pitti> Kamion: anyway, it's probably just a confusing question
<pitti> Kamion: I'll try another install completely without network, then it should work, right?
<Kamion> mm, probably not, if you answer no to that question then it will not download any language-support-*
<Kamion> er, will not install any ...
<pitti> a present ethernet without functional internet connection is certainly corner-caseish enough to be ignored for the release
<ogra> pitti, at least it works this way in edubuntu, i just had such an install here
<Kamion> can you reopen that bug and clarify following this conversation?
<pitti> Kamion: I already did
<Kamion> it should be on pkgsel
<Kamion> ok, thans
* pitti reassigns
<Kamion> +k
<infinity> bgertzfield: How much do you know about your product? :)
<infinity> bgertzfield: Oh, nevermind.  Driver error.
<mvo> pitti: just verified, the "language-support-en gets removed" bug is gone for me on i386
<pitti> mvo: *scratching my head*, well, good to hear :)
<mvo> pitti: I'm doing amd64 now anyway, I check there too
<pitti> mvo: maybe depends on the moon phase then, or whether the current hour is a prime number
<mvo> pitti: yeah
<zyga> lol
<zyga> I remeber there was some one program that did depend on moon phase in a way ;] 
<mvo> pitti: amd64 is ok too ... all very strange
<mvo> zyga: which one?
<zyga> mvo: just a sec
<sfllaw> pitti: The documentation claims there's a rescue line.
<zyga> mvo: http://www.catb.org/jargon/html/P/phase-of-the-moon.html
<pitti> sfllaw: not on the live CDs, and since the actual live system is a pretty good rescue system, too, it wouldn't make too much sense, I guess 
<bgertzfield> infinity, mvo: foxden.org apt repository updated
<bgertzfield> going to ensure the packages work on amd64 now
<bgertzfield> vmware-player_1.0.1-4 moves to .orig.tar.gz and fixes a missing word in the desc
<bgertzfield> vmware-player-kernel-modules-2.6.15 ... -6 adds the new empty dependency helper package
<Kamion> zyga: nethack does
<bgertzfield> ahh, my old nethack package :)
<bgertzfield> those were the days
<zyga> Kamion: adom does too
<infinity> bgertzfield: Kay, I've already context switched, but I'll re-check those in a bit.
<bgertzfield> infinity: ok, confirmed everything is good on amd64
<bgertzfield> infinity: sure. ready whenever you are.
<zyga> Kamion: same on virtual moonphase and virtual birthday (try eating a hurtling cake as a hurtling on your virtual birthday :-)
<mdz> iwj: the most interesting part of your message is the description of what went wrong after the upgrade, but it's also the bit with the least detail
<sfllaw> pitti: Well, it is there.
<ogra> infinity, how about edubuntu DVDs, now that you had a snack and refreshment :)
<Kamion> infinity: bug 28033
<Ubugtu> Malone bug 28033 in cdrom-checker "cdrom-checker-menu never reboots" [Normal,Fix released]  http://launchpad.net/bugs/28033
<Kamion> should be reopened now I guess
<infinity> ogra: You need new ones?
<ogra> i have new live isos, so i would imagine so
<sfllaw> pitti: I think it might be a little late to remove this functionality.
<sfllaw> pitti: Hmm.  It appears to be a documentation fault.
<Mithrandir> mdz: hi
<Mithrandir> infinity: yes, but not right now.
<bgertzfield> Mithrandir: thanks again for all your help yesterday!
<dholbach> Riddell: sorry, I added a conflict in the wiki
<Mithrandir> bgertzfield: happy to help
<Riddell> dholbach: can you fix it?
<dholbach> you're done now?
<dholbach> Riddell: s'all good
<Riddell> thanks
<doko> is there a "package" to file bugs for help.ubuntu.com ?
<LaserJock> doko: what part? probably ubuntu-docs
<doko> LaserJock: start guide
<LaserJock> doko: I suppose ubuntu-docs then
<mdke> doko: that's a breezy guide though, we won't be fixing bugs for it
<elmo> mdke: is the CoC in ubuntu-docs btw?
<mdke> elmo: no
<infinity> Gah, partman, you suck.
<bgertzfield> partman's not fat; he's just big-boned
<infinity> Kamion: "Erase entire disk and use LVM" is telling me to piss off because I already have LVM volumes.
<mdke> infinity: maybe that's just an excuse to tell you to piss off
<mdke> not a great one either... you've seen through it
<doko> mdke: but it's still referenced on the toplevel help.ubuntu.com without mentioning the version?
<elmo> mdke: could we have it in there please?
<mdke> doko: yes. When dapper is out there will be a new website
<mdke> elmo: it's a decent idea. Bit late for dapper mind. Would you envisage having it in the front page of yelp?
<dholbach> Kamion: thanks for removing those two
<infinity> Oh well, I think I did something to anger it.
<dholbach> infinity: I think I ran into the same problem.
<pitt1> moo
<infinity> dholbach: It's tricky to trigger, mind you, so I'm just going to reproduce it later and file a bug.  It's not even close to RC.
<dholbach> yeah
<dholbach> when I removed the partitions it was happy again
<infinity> Man, I so need to file a wishlist bug on d-i for this one.
<pitti> Keybuk: I still get anacron on the ppc/live. Are you sure that's from pbbuttonsd? IIRC the changelog claimed that it got fixed recently
<infinity> Every time it asks "is your system clock set to UTC" but doesn't tell you WHAT THE SYSTEM CLOCK IS SET TO, a kitten dies.
<dholbach> so if one of a million people installing it runs into the problem, he's not going to cry in despair
<infinity> "Well, I dunno, maybe it's set to UTC... Maybe not... You've not told me what time it thinks it is.."
<pitti> infinity++
<Keybuk> pitti: ls /etc/rc2.d
<pitti> Keybuk: no anacron there
<Keybuk> pitti: no anacron at all?  (as apposed to K*anacron)
<pitti> Keybuk: ls -l /etc/rc2.d/*ana* gives nothing
<Keybuk> pitti: then you have an old version of casper, thus an old CD
<pitti> Keybuk: it's the very latest from today
* mvo grumbles about having to type this long url to netinst kubuntu
<Keybuk> pitti: Lies.
<Keybuk> pitti: dpkg-query -W casper
<pitti> Keybuk: 1.57
<Keybuk> pitti: that's fucked then
<LaserJock> infinity: that UTC clock thing gets me everytime
<Keybuk> 1.57 should have /etc/rc2.d/K00anacron
<mdke> elmo: ok, I've send a mail to c-c@lists about WikiLicensing, thanks for nudging me about it
<Keybuk> pitti: are you testing with a cow
<pitti> Keybuk: cow? moo?
<Mithrandir> pitti: do you have oopses in dmesg?
<pitti> Keybuk: no, no oopses
<pitti> a lot of buffer I/O errors on hdc (CD-ROM), but that's about it
<crimsun> I get an oops on i386 ([4294684.330000]  EIP is at finish_wait+0x36/0x70)
<mdke> doko: yes, we've fixed that bug in the dapper docs (as discussed on -devel mailing list) don't be offended if I close the bug, we can't fix all the breezy stuff
<crimsun> (seems to be related to kIrDAd, but it's non-fatal, so meh)
<Mithrandir> pitti: any mention of anacron in /var/log/casper.log?
<pitti> Mithrandir: ah:
<pitti>  /scripts/casper-bottom/25configure_init: 33: dirname: not found
<pitti>  `/K00anacron': exists
<Mithrandir> Keybuk: you suck, then. :-P
<infinity> pitti: Ah-ha.
<infinity> Would have been nice if someone had tested that change.. *cough*
<Keybuk> Mithrandir: oh, heh
<Keybuk> infinity: I did test it, just not in initramf
<Keybuk> +s
<Mithrandir> Keybuk: so you didn't test it.
<infinity> Keybuk: Well, yes.  I meant "test a daily after it was included".
<Keybuk> oh well
<Keybuk> it's not a regression on the previous behaviour
<Keybuk> just silly
<pitti> so, it'll make ppc installs horribly slow/unusable after 5 minutes, but oh well
<infinity> :/
<bgertzfield> :(
<pitti> it has worked so far
<Keybuk> pitti: that was the case before my fix too though
<Mithrandir> pitti: why does this just touch ppc?
<Keybuk> Mithrandir: would ${STUPID%/*} work in initramfs?
<Keybuk> Mithrandir: ppc has pbbuttonsd which generates a "power" event on boot to let you know it's on AC
<Keybuk> which kicks off anacron through invoke-rc.d
<Keybuk> and because you just removed the S* links, rather than replace with K* links, invoke-rc.d still started it
<Mithrandir> Keybuk: since ${%/*} is POSIX, yes.
* Keybuk sticks it in DRR for updates
<pitti> Keybuk: hm, that won't make much sense, will it? unless we'll roll new CDs in the future
<Keybuk> *shrug*
<Keybuk> certainly too late to put the fix in now
<pitti> right
<Keybuk> especially given that the fix doesn't break it *more* than it was broken before
<Keybuk> (broken fix)
<infinity> No point in having it in -updates unless we DO roll new CDs.  THough I guess it doesn't hurt to push it on the off chance that we might.
<Keybuk> infinity: we probably will for ubiq bug fixes
<pitti> Keybuk: actually, if I started an install immediately, it went just fine; it just got stuck if I played with the live CD for some minutes; maybe anacron checks the load before it kicks in?
<infinity> If we decide to do 6.06.1 or something.. I dunno.
<Keybuk> infinity: 6.06.6
<Keybuk> pitti: I believe it does
<mdke> Burgwork: no, you need smurf
<pitti> Keybuk: I agree, otherwise I would have never managed to finish any ubiquity installation (updatedb is merciless...)
* pitti reboots into his shiny new installed system, brb
<infinity> Mithrandir: Can you queue up (and test locally) a proper fix for that bug for the just-in-case-we-find-a-showstopper-and-have-to-rebuild-anway case?
<infinity> Mithrandir: But don't upload it, obviously.
<Mithrandir> infinity: yes, willdo
<Kamion> infinity: FYI, in case nobody said - we will be rebuilding for some bad Chinese issues in d-i and ubiquity
<Kamion> I've fixed half the problem, about to start investigating the other half
<Mithrandir> Kamion: does that mean I should do the casper fix immediately and get it in?
<Keybuk> Mithrandir: no!
<Keybuk> we want to change as little as possible
<Kamion> I'd rather change as few things as possible
<Kamion> so that the retesting process is as quick as we can
<Mithrandir> Kamion: ok
<infinity> Kamion: This one's pretty irritating, mind you.  Positive we can't sneak it in?
<infinity> (Not that I have a PPC machine that boots CDs, so I can just pretend the bug doesn't exist)
<pitti> Kamion: it means that the ppc live CD becomes unusable after a few minutes
<pitti> not the end of the world
<pitti> but ugly
<Mithrandir> I'm amazed nobody has reported this bug before.
<pitti> Mithrandir: I forgot about it after seeing that changelog :(
<Keybuk> Mithrandir: I was the first to notice
<Keybuk> last week, thus the quick fix
<Keybuk> obviously eyeballing the diff and testing locally wasn't sufficient
<Mithrandir> it means nobody has been using the live cd for more than a few minutes on PPC?
<Keybuk> Mithrandir: at least, nobody has been _not_ using the live cd for more than a few minutes
<Keybuk> anacron doesn't kick in under load
<infinity> and since our testing cycle involves opening OOo and other such..
<pitti> yeah, I noticed when booting the live CD, doing something else, and then wanting to test it
<infinity> But regular LiveCD usage on the other hand, is more like "boot, look around, go 'ooo, this is cool', sit at desktop for a while, decide to try installer"
<infinity> Which will be hell.
<Kamion> I'm very much inclined not to, I'm afraid - any more mistakes at this point would be very costly
<pitti> Keybuk, Mithrandir: X=/a/b/c; echo ${X%/*} works well here under bash and dash 
<Kamion> (I'm having people double/triple-check all my changes here)
<Keybuk> pitti: yeah, but so does dirname ;)  try under initramfs
<Keybuk> I did _that_ level of checks on the currently broken shell
<infinity> Keybuk: ${} is pure shell, dirname isn't. :)
<pitti> Kamion: that means we won't do another full test cycle with  the new images?
<Keybuk> ok, it seems to work
<Kamion> pitti: we'll do another test cycle, but we need to be prepared for not having enough time for a *full* cycle
<pitti> yes, that's what I mean
<Kamion> so I'd like not to change things with wide-ranging effects
<infinity> Kamion: I'm fine with the answer being "no", but if we fix the broken shell, the worst that happens is that it stays as broken as it currently is if we get it wrong.
<Keybuk> Mithrandir: you can pull both sets of fix from sftp://chinstrap/home/warthogs/archives/scott/casper for edgy
<infinity> Since casper clearly isn't 'set -e' at that point, or it would have broken horrible on the 'dirname: command not found'
<infinity> horribly, too.
<Kamion> infinity: I've tried to get in touch with mdz, and can't, so I guess it comes down to me - I think my answer is no, since at least this way we know what the problem is
<infinity> Kamion: Fair 'nuff.  I won't push it.
<Kamion> (I can imagine for instance that pbbuttonsd might get upset at a different invoke-rc.d exit code or something)
<Kamion> (maybe it doesn't, but that kind of thing)
<Mithrandir> I could rm the anacron binary instead.
<Mithrandir> but as infinity says, your choice
<Kamion> if people with ubiquity checkouts could pull my current tree and sanity-check the final patch in it, that'd be good
<Keybuk> Mithrandir: that wouldn't help
<Keybuk> in fact, that's exactly the kind of brokenness we want to avoid
<Keybuk> rm'ing anacron would mean cron would start running /etc/cron.* again
* Kamion sits down and stares at localechooser
<Mithrandir> Keybuk: that branch is missing your 1.57 commit.
<Keybuk> Mithrandir: no it's not
<Keybuk> it's just one commit for both
<Mithrandir> can you fix that, please?
<Keybuk> no :)
<doko> pitti: is not finding an USB stick worth reporting?
<Keybuk> it's my branch, and I'll commit how I want to
<doko> May 30 21:33:20 ubuntu kernel: [ 1161.366038]  usb 1-8: new high speed USB device using ehci_hcd and address 4
<doko> May 30 21:33:23 ubuntu kernel: [ 1162.775905]  usb 1-8: device descriptor read/64, error -110
<doko> May 30 21:33:49 ubuntu kernel: [ 1174.427425]  usb 1-1: new high speed USB device using ehci_hcd and address 5
<doko> May 30 21:33:52 ubuntu kernel: [ 1175.836836]  usb 1-1: device descriptor read/64, error -110
<Keybuk> it's one logical fix
<doko> May 30 21:34:07 ubuntu kernel: [ 1182.743514]  usb 1-1: device descriptor read/64, error -110
<pitti> doko: sure; we can't fix it right now, but maybe in-updates
<doko> [...] 
<pitti> doko: ah, that's known, many dupes
<pitti> doko: sudo rmmod ehci_hcd
<pitti> doko: in most cases it works with the usb 1.1 driver
<doko> pitti: bug number?
<Mithrandir> Keybuk: please refrain from breaking casper in the future, then.
<Keybuk> Mithrandir: stop being a twat
<pitti> doko: 27889, 32182, and probably some more
<Keybuk> (*fight*fight*fight*) :p
<Kamion> oh-kay
* pitti hugs Keybuk
<rddp> Are you guys in London having any official post release drinks at a friendly local pub tomorrow? I'd like to get you a round :)
<Keybuk> tomorrow is a bit optimistic for "post-release" given the release is on Thursday
<rddp> Ah its not quite midnight yet.. :)
<Keybuk> unless you're forseeing "it's all gone wrong, let's go get pissed and try to forget"
<rddp> well taht could work
#ubuntu-devel 2006-05-31
<green-mouse> Hi, somebody can tall to me, if this posble to include linux-phc to offical kernel? (see bug #46952 today i try`d to boot from ubuntu-live cd on my frend`s laptop, and cpufreq selector don`t work in such a way) 
<Ubugtu> Malone bug 46952 in linux-source-2.6.15 "cpufreq don`t work on centrino CPU in  "dapper" (kernel: linux-image-2.6.15-23-686)" [Normal,Needs info]  http://launchpad.net/bugs/46952
<infinity> green-mouse: We had this discussion just a day or two ago, didn't we?
<infinity> green-mouse: A) That patch is crack and is just trying to cover up the fact that you have broken ACPI, B) Fix your ACPI tables, C) We're releasing in a day or two, the kernel's not getting changed.
<green-mouse> infinity, not only I have broken tables, yes this hack but this can help to many plp...
<infinity> green-mouse: From "man mkinitramfs":
<infinity>        /etc/mkinitramfs/DSDT.aml
<infinity>               If  this  file exists, it will be appended to the initramfs in a way that causes it
<infinity>               to be loaded by ACPI.
<infinity> green-mouse: There should be plenty of HOWTOs out there (I'm a bit too busy to go hunting right now) on how to hack a DSDT update for your ACPI tables to make them "just work"
<doko> the Examples folder is not installed on an install from the live CD?
<dholbach> doko: it's in ~
<dholbach> doko: not in ~/Desktop/
<green-mouse> infinity, infinity ok thenks, I will see what i can do with this, if scceed i will write how to :)
<mvo_> dholbach: ping
<mvo_> dholbach: still around?
<dholbach> mvo_: pong
<dholbach> mvo_: yes, around
<dholbach> mvo_: still
<infinity> bgertzfield: Still alive?
<dholbach> mvo_: are YOU still there?
<mvo_> dholbach: obviously
<bgertzfield> infinity: hai1
<bgertzfield> er. hai!
<Kamion> http://people.ubuntu.com/~cjwatson/tmp/localechooser-chinese-fix.diff <- review greatly appreciated
<infinity> bgertzfield: Japanese much?
<bgertzfield> infinity: un, shabererundakedo sa
<Kamion> the added hunk is a copy-and-paste of the block below, with s/\$LANGUAGE/${LANGUAGE}_${COUNTRY}/g
<bgertzfield> infinity: (yeah, I speak a little. :)
<Kamion> seems to be working so far, but I want to test pt_BR, pt, some-random-other-language
<infinity> Kamion: Looks sane, I think...
<infinity> Kamion: I should probably go fetch some context.
<Kamion> copy/paste is maybe not the most elegant way to do it but it's the safest, I think
<mvo_> Riddell: ping
<infinity> Kamion: Ahh, yes, with a bit more context, it seems entirely sane.
<Kamion> also look at the templates file
<Kamion> grep for countrychooser/shortlist-
<Kamion> e.g.
<Kamion> Template: countrychooser/shortlist-ar
<Kamion> Template: countrychooser/shortlist-pt
<Kamion> Template: countrychooser/shortlist-pt_BR
<Kamion> Template: countrychooser/shortlist-zh_CN
<Kamion> Template: countrychooser/shortlist-zh_TW
<Kamion> no countrychooser/shortlist-zh, and therein lies the crash
<doko> Mithrandir: is suspend to disk known not to work on amd64?
<doko> Kamion: oem-install asks for a password?
<infinity> Kamion: Ahh.  No default zh for political reasons, I suspect?
<infinity> Kamion: Anyhow, yes, the bug (and the fix) make even more sense after generating the templates file and looking at it.
<Kamion> infinity: zh_CN and zh_TW are basically two different languages - different script etc.
<Kamion> two different written languages I mean
<Kamion> so it does make some kind of sense to choose them separately, aside from the geopolitical crap
<infinity> Kamion: Well, zh_TW users should be able to read zh_CN, though not necessarily the other way around.
<infinity> Kamion: But yes, point taken.
<Kamion> doko: elaborate?
<Kamion> I'm very tired, you need to not be terse :)
<infinity> bgertzfield: Okay, I need to review your stuff right now before I pass out for the "night" (where "night" is 8:30am)
<Kamion> infinity: I'll drive rebuilds after this lot
<doko> Kamion: sorry :) I'm asked for a password during the oem-installation (amd64 DVD), but not for a name and a user name. I suppose, I shouldn't be asked for anything (after confirming the partitioning dialog)
<infinity> Kamion: I assume this bug breaks both d-i and ubiquity?
<infinity> (Hooray for common codebases -- common bugs!)
<Kamion> infinity: it does indeed
<Kamion> doko: no, that's correct, the password is for the oem user that gets created for customisation
<Kamion> it's kind of er not very well-documented, but that's what it's for
<doko> ok, thanks
<seb128> is edubuntu liveCD on amd64 read to try now?
<Kamion> I think the installer does tell you that later on
<infinity> seb128: Yes, except that Kamion's going to do a mass rebuild soon. :/
<infinity> seb128: Testing the current image to find OTHER showstoppers won't hurt. :)
<seb128> infinity: oh? what change do we want to get?
<infinity> seb128: Fatal localechooser bug in d-i and ubiquity.  See above.
<seb128> ok
<seb128> I've a planner trivial fix to upload (planner is not on the CD afaik), should I upload it now so I don't forget about it or better later?
<infinity> Better in -updates.
<seb128> (define the mimetype as an xml format other way nautilus refuses to open a .planner)
<infinity> We're aiming for a "change nothing but localechooser" rebuild, so all the previous testing isn't  awaste.
<seb128> ok
<seb128> I don't think planner is on the CD
<seb128> so it should not impact
<infinity> Something even more trivial than your change (and with higher impact) was already rejected. :)
<seb128> but as you wish
<infinity> seb128: Well, if it's not on the CD, you can ask mdz or Kamion, but I suspect we'd all prefer to just get the CDs tested and let the archive as it stands now be "the final dapper"
<infinity> A day of testing will make people cranky.  Another day of testing tomorrow, because today wasn't good enough, will make people even more cranky. :)
<seb128> fine, with me :) That was just to not forget about the fix again (I thought it was fixed but the upload got rejected some time ago)
<maswan> se.{archive,releases} on new hardware and software now. poke me in case it has broken.
<jono> hey
<Keybuk> heyhey
<jono> heya Keybuk
<jono> hows things?
<Keybuk> Kamion: I wonder, is there an en_SO translation?
<Keybuk> (English as spoken to one's partner)
<Keybuk> jono: uh...
<Keybuk> jono: "Everything will be OK"
<jono> Keybuk: heh, I guess you are all working like nuts right now
<Keybuk> something like that
<dholbach> ogra: tell me when you finished editing the wiki?
<ogra> dholbach, sorry, resolving a conflict
<ogra> dholbach, go ahead
<dholbach> ogra: merci
<infinity> bgertzfield: The reason Mithrandir's hacking of debian/control worked, BTW, is cause your KVERS/MAIN_PACKAGE_BUILD stuff doesn't work.
<infinity> bgertzfield: KVERS isn't set at all, so ifeq ($(KVERS), unknown) doesn't trip.
<ogra> mdz, edubuntu install ppc all good
<infinity> bgertzfield: I suspect you just want "ifeq ($(KVERS),)"
<infinity> bgertzfield: If you can confirm that, the rest looks good, and I can just fix that and upload.
<Kamion> right, I can't make this break
<infinity> Kamion: \o/
<infinity> Kamion: I'm still here to drive LP, so let me know when you're ready.
<sabdf1> Kamion: did it turn out to be a small fix?
<infinity> Kamion: Oh, I see it's uploaded already.
<infinity> Kamion: Confirm that the one uploaded is the one you want? :)
<Keybuk> infinity: should be ubiquity and localechooser uploads?
<infinity> Just localechooser, so far.
<Keybuk> Kamion sez "nearly"
<infinity> (And a universe upload that is going in for free with this run as well)
<Kamion> sabdf1: two small fixes
* Keybuk movedlocalechooser into manual-queue
<infinity> Keybuk: May as well process the mopac7 upload too.
<Kamion> both ll_CC handling
<infinity> Yay, MOTU.
<Keybuk> infinity: ah, the legendary MOTU Freeze
<Keybuk> "Freeze" ... "You moved!"
<Keybuk> :)
<mdke> sounds like the UI freeze
<infinity> mdke: Bitter much? :)
<sabdf1> sugar for all you bitter people :-)
<mdke> infinity: that wasn't meant as bitter, just a joke
<infinity> sabdf1: Hey, I'll be missing the release party, since I'm way over on the other side of the planet.  Feel free to ship some goodwill over here. :)
<azeem> infinity: yeah, process mopac!
<mdke> I won't turn down some free sugar though
<sabdf1> hot damn, we must have enough sydney users + developers to have a release party (or at least a few beers) down under
<sabdf1> infinity: if you can organise it, i can chip in for some beers
<Robot101> ooh, release beer
<infinity> sabdf1: Except that I'm in Melbourne, not Sydney. :P
<sabdf1> doh
<Kamion> localechooser 0.27ubuntu22 and ubiquity 1.0.12 uploaded
<dholbach> release beer in Berlin too! :-)
<Kamion> debian-installer will need to follow once localechooser binaries are in
<azeem> there's not even a release party in London yet it seems
<holycow> hey guys ... are there any official ubuntu logotype documents available in the wiki?
<sabdf1> night all, and thanks for chasing this one down kamion
<Kamion> we can start livefs rebuilds once ubiquity binaries are in
<mdke> holycow: what is a locotype document?
<infinity> Keybuk: Manual queue processed?  I have a publisher session waiting.
<Keybuk> ok, go for it ... was going to do the publisher run myself, but if you have one ready to go, PUSH THE BUTTON
<holycow> logotype document would be say like an svg file containing the logo in the official colours with the offical font and offical lettering
<infinity> Button pushed. :)
<Kamion> (yes, the uploads I got mail for are the ones I wanted)
<ogra> meh, i just started rsyncing the dvd ...
<mdke> holycow: yes, the artwork pages have them
<infinity> ogra: It's not going to change much.
<holycow> mdke, oh! art work pages! of course
<holycow> my thanks :)
* mdke blinks
<Burgwork> holycow, http://www.ubuntu.com/ubuntu/TrademarkPolicy/
<Burgwork> holycow, https://wiki.ubuntu.com/Artwork/Official
* holycow windexes mdke eyeballs
<holycow> :)
<holycow> Burgwork, sweet!
<infinity> Keybuk / Kamion : I'll manually drive the buildds and the second publisher run.
<mdke> holycow: greek?
<ogra> infinity, i know but its horrible slow, so i suspect it to run still if the /current link changes
<holycow> nope
* mdke slaps Burgwork with a rtfwp
<Keybuk> infinity: a debian-installer is to follow once the localechooser binaries are in ... we'll leave that in incoming in case you get round tuit before we get back to the hotel
<infinity> Kamion: d-i can upload anytime, right?  (As long as I don't let it in the buildqueue until the localechooser binaries are published)
<Kamion> Keybuk just suggested that, yeah
<holycow> man this is great
<holycow> appreciate it
<Kamion> preparing the upload
<infinity> Kamion: yeah, let 'er rip.
<holycow> <-- makin a nice looking manual for new home user
<Keybuk> *parp*
<Kamion> debian-installer uploaded
<infinity> Spiff.
<Riddell> mvo: hi
<Keybuk> infinity: will leave that sat in u-q/incoming
<Keybuk> you can push it around to the right place then
<infinity> Keybuk: Yup, I'll mangle it when needed.  Thanks.
<infinity> Keybuk / Kamion : Grab yourselves a beer when you get to the hotel.  This'll be a while anyway, and I can kick off the livefs builds while you're relaxing.
* infinity goes to make himself a drink.
<Keybuk> infinity: sadly bar will be closed by now
<infinity> Go to a better hotel? :)
<elmo> yeah, 'cos the K&K is so cheap and nasty
<Keybuk> mmm... K&K Breakfast
<Keybuk> this morning, the world was a HAPPY place
<elmo> I should come get breakfast at the K&K
<elmo> I could pretend to be fabbio and rob him of his breakfast
<sivang> heh
<ogra> lol
<infinity> Can you do the accent?
<ogra> thats hard 
<Keybuk> infinity: you should probably plan to sleep this week too
<infinity> Me eats a can of tuna, and dreams of better breakfasts.
<holycow> *hmm* what file contains the default permisions for home directories when new users added? i'd like to restrict home dirs to only their users
<infinity> Keybuk: This is all part of my master plan to be back on my own timezone by the time we release.
<infinity> Keybuk: So the lack of sleep right now is somewhat positive, in that regard.
<shawarma> holycow: I think it's in adduser somewhere.
<infinity> holycow: /etc/adduser.conf
<holycow> ah! damnation, nice thank you
<infinity> holycow: Also, that's very much an #ubuntu question.
<Keybuk> or #adduser
<infinity> If adduser were sufficiently complex to require its own discussion channel, I'd be frightened.
<infinity> (Well, under the hood, it is a bit complex, but the user interface certainly isn't)
<Kamion> have you looked at its code lately?
<Kamion> right ...
<infinity> And here goes tuna can #2...
<infinity> I wish I hadn't already eaten everything else in the house. :P
<sivang> infinity: if you cut slices of onions into it it gets better
<ogra> *shudder*
* sivang does that all the time
<infinity> sivang: See above about "eating everything else in the house"... That includes great tuna fixings, such as mayonnaise, pickles, onions, olives....
<infinity> All I have is.. 6 cans of tuna.  And a pack of smokes.
<infinity> And tobbaco doesn't enhance tuna very well.
<sivang> infinity: ah, speaking of olives, are you only interested in olive oil , or other olive stuff from here?
<ogra> not really
<sivang> I wouldn't think tobacco can fix tuna just make it worse :-)
<infinity> sivang: I like pretty much anything that is -- or once was -- an olive.
<holycow> oh okay ... the gnome admin utility doesn't use adduser ... it uses useradd >_<
<holycow> at least the bug tracker shows added support for adduser so hopefully in next release
<Kamion> so mouldy olive decomposed for about a month would be goodd?
<Kamion> good
<ogra> lol
<infinity> Kamion: That level of "humour" really doesn't meat your ususal strict standards.  Clearly you need to sleep.  NOW.
<infinity> meat?
<infinity> Dear god.
<infinity> MEET.
<Kamion> oh, score, cron.germinate is running while apt-ftparchive is doing
<Kamion> er, running. yeah.
<Kamion> I wonder how well that'll work.
* sivang is worried about Kamion and infinity 
<Keybuk> Kamion: I don't think we need to burden infinity with the requirement to running those
<sivang> infinity: I'll see what I can drag with me without being asked funny questions at the airport :)
<infinity> Germinate will settle again by the time we've done TWO MORE PUBLISHER RUNS anyway.
<sivang> infinity: but a bottle of oil is the least
<Kamion> yeah, it's not like germinate is terribly important atm
<infinity> But I don't see why it should be upset in he least, since apt-ftparchive is operating on a copy of dists, not the real thing.
<Kamion> just a curiosity
<infinity> Unless germinate has suddenly started wandering around for random Packages files in dists.new, it shouldn't make a lick of difference. :)
<infinity> (And boy, that would be odd)
<infinity> I think I'm starting to develop a photographic memory of publisher logs to the point where I could type them verbatim if I had to.
<infinity> This isn't right.
<sivang> Kamion: actually, there is sort of what you described as a special olives make, and people like it. In free translation from hebrew that would read as "Screwed Olives" but they either come very ripe or the opposite
<sivang> for some reason there are some people that like to consume their olives that way.
<Kamion> just goes to show, people will eat anything if it's expensive enough
<infinity> And off goes the queuebuilder.
<sivang> heh, well, if you go to the street markets this is reatively cheap. but not when it comes canned.
<infinity> Kamion: ubiquity includes private copies of d-i components for now, right?
<infinity> Kamion: (ie: I can kick off livefs builds as soon as ubiquity 1.0.12 binaries are published?)
<infinity> Err, wait, yes, that's obviously true.
<infinity> Kamion: Ignore me.  Long day.  Reasoning out loud when I clearly shouldn't be.
<Kamion> yeah, it does, and you can
<Kamion> Scott and I are heading back to the hotel, hopefully there's at least a minibar
<infinity> :)
<infinity> Enjoy.
<Kamion> will be online from there at some point
<doko> heading to bed as well (no minibar)
<sivang> are you like in until-release sprint in the K&K ?
<azeem> infinity: thanks
<holycow> thanks for the help gus
<bgertzfield> infinity: still here?
<infinity> bgertzfield: Yup.
<bgertzfield> infinity: anything more you need for the vmware-player packages?
<infinity> bgertzfield: Did you get my last messages to you?
<bgertzfield> the last I saw, you asked me if I spoke Japanese
<infinity> 16:56 < infinity> bgertzfield: The reason Mithrandir's hacking of debian/control worked, BTW, is
<bgertzfield> ahh, I see it now
<infinity>                   cause your KVERS/MAIN_PACKAGE_BUILD stuff doesn't work.
<infinity> 16:57 < infinity> bgertzfield: KVERS isn't set at all, so ifeq ($(KVERS), unknown) doesn't trip.
<bgertzfield> read it through lastlog
<infinity> 16:58 < infinity> bgertzfield: I suspect you just want "ifeq ($(KVERS),)"
<infinity> 17:01 < infinity> bgertzfield: If you can confirm that, the rest looks good, and I can just fix
<infinity>                   that and upload.
<bgertzfield> infinity: interesting. in my testing it was actually set to "unknown" due to the include of /usr/share/modass/include/generic.make
<bgertzfield> and I believe that Mithrandir's hack worked because the build-deps were checked before debian/rules clean was called
<bgertzfield> modass sets it to "unknown" if not building from m-a
<Kamion> sivang: yes
<bgertzfield> from generic.make:
<bgertzfield> ifeq ($(KVERS),)
<bgertzfield> KVERS = unknown
<bgertzfield> endif
<infinity> Ahh, see, we do source-only uploads in Ubuntu, so build-deps don't have to be there to do the initial clean.
<Kamion> infinity: hello. how's it going?
<bgertzfield> infinity: interesting. 
<infinity> Which means that I don't have /usr/share/modass/include/generic.make installed when I'm doing it.
<bgertzfield> infinity: !
<infinity> Kamion: Publishing binaries, and the d-i source.
<Kamion> ok
<bgertzfield> infinity: we should handle it with an or then
<bgertzfield> because it will either be 'unknown' or empty
<infinity> bgertzfield: Yup.  ORify it.
<bgertzfield> infinity: want me to do it? or do you want to fix it?
<infinity> bgertzfield: Go ahead.  I'm too tired to wrangle sane make.
<bgertzfield> OK.
<bgertzfield> do I need to bump the version again?
<infinity> Nah, just add to the changelog for the same version.  I'm smart enough to download it again.
<infinity> Kamion: livefs builds should commence in about 10 mins, give or take.
<infinity> Kamion: We can start on -alternate- rebuilds in about 40.
<infinity> Kamion: I'm happy to drive the whole show if you'd rather sleep.
<azeem> infinity: will dep-wait packages be retried automatically at this point? (mopac7 upload unblocked libghemical and then ghemical)
<bgertzfield> infinity: ok. doing now. thanks for staying up. :)
<infinity> azeem: They will be if I let the queue-builder run free again.
<Kamion> infinity: don't feel you need to stay up just for this; I'm happy to drive stuff
<azeem> ok
<Kamion> infinity: if you tell me how to drive the buildd-sequencer
<infinity> Kamion: Like I told Scott, my goal is to be back on Melbourne time by the time we release, so staying up now is helping me get off UTC and right my schedule. :)
<azeem> infinity: last question, ghemical seems to be marked as failed rather than dep-wait is there a way to change this?
<infinity> azeem: Yeah, I can smack it.
<azeem> thanks a lot
<Kamion> infinity: really? er, ok ...
<infinity> Kamion: Seriously.  Don't worry about it.  I'll get a good rest (in my own timezone!) after this is all over and done with.
<infinity> Kamion: Sleeping at 10:30am doesn't really appeal to me anyway.
<infinity> Kamion: You, on the other hand, may find another showstopper in the installer tomorrow, so you should go rest your brain.
<Kamion> I'd better freaking not
<Kamion> or the London office will be finding out whether blood can be cleaned out of its carpet easily
<infinity> Yours, or some random coworker's?
<ajmitch> afternoon
<Kamion> Yes.
<Kamion> infinity: what are you on now - 26 hours?
<Kamion> actually no, you had breakfast at the same time I did
<Kamion> infinity: you'd better be asleep by the time I get up again, though. <threatening look>
<infinity> Kamion: Yes, mom.
<Kamion> :-)
<bgertzfield> infinity: Testing a build with m-a not installed now.
<Kamion> ok, -> bed; thanks again
<bgertzfield> infinity: OK, it's working correctly now.
<bgertzfield> infinity: thanks for noticing that!
<infinity> bgertzfield: Don't forget to test with as well, to make sure your magic still works. :)_
<bgertzfield> I couldn't figure out the $(or) syntax, so I just used an ifeq (...) else ifndef 
<infinity> bgertzfield: I'm not uploading this twice. :P
<bgertzfield> infinity: Yes, I tested with first. :)
<bgertzfield> infinity: uploading fixed package to foxden.org apt repository now
<infinity> \o/
<bgertzfield> infinity: upload complete. grab away
<bgertzfield> infinity: confirmed vmware-player-kernel-source still works great
<bgertzfield> so I think we're set
<infinity> We better be.  This is the last upload you get. :P
<bgertzfield> *gasps*
<bgertzfield> I think this'll meet the bar. :)  I appreciate all the constructive criticism and help
<infinity> After this, I stop being able to think clearly, and I just drive the archive machinery like an ox on a cart.
<bgertzfield> Aye.
<infinity> And, hopefully, tomorrow we release. :)
<bgertzfield> Oyes.
<infinity> (An event I may, ironically, sleep through)
<infinity> If I end up being up for the next 5 or 6 hours fixing new CD/DVD builds for everyone.
<bgertzfield> infinity: I'm going to stick around and see if you give these the ghumbs-up
<bgertzfield> err. thumbs-up. what the heck is a ghumb?
<bgertzfield> infinity: but I have to go after that, will be back in a few hours
<infinity> It's what you've been typing with? :)
<infinity> bgertzfield: I'll have them downloaded and checked out in ~10 mins.  After that, you should be free to go. :)
<bgertzfield> infinity: fantastic. you are incredible. :)
<infinity> (Also, you should get more bandwidth)
<bgertzfield> ubuntu is getting hugely popular at VMware, by the way
<bgertzfield> especially with the browser appliance
<bgertzfield> infinity: I'm trying to get 'official' VMware space for us to interact with the opensource crowd
<infinity> Oh, question for you...
<infinity> The kernel modules for vmnet and friends.  Are those identical between vmware-{player,workstation,server}?
<bgertzfield> sure
<infinity> Cause if they are, the "vmware-player-kernel..." package name seems a bit shortsighted. :)
<bgertzfield> No, they are not.  We will be changing the package name and adding Conflicts: for the other products.
<infinity> (Seeing as how you may later distribute the other products as debs as well)
<infinity> Ahh, these are stripped down in some way, then?
<bgertzfield> They're unfortunately both not compatible, and named the same. *grumble*
<infinity> Shame.
<bgertzfield> They're not stripped down, but the internal APIs change; the various products come from different source control branches
<infinity> Would be nice to get that unified at some point, but I guess I don't need to tell you your job. :)
<bgertzfield> It's a 'nice to have'. :)
<infinity> Well, it becomes more useful when you look at the packaging angle.
<bgertzfield> Which, you can probably guess, I've spent more time on the past week than anyone has in years. ;)
* infinity grins.
<infinity> bgertzfield: I'm not going to bother changing your changelog, but the problem isn't the buildds.  debian/control needs to be correct on UPLOAD, not on BUILD (well, parts of it, anyway, the parts that the .dsc are made from)
<bgertzfield> ahh, I see
<infinity> bgertzfield: So, it's on my machine when I do a source-only build for upload that debian/control doesn't get properly generated.
<bgertzfield> Got it.
<bgertzfield> so when you do a source-only build on any machine that doesn't have m-a installed, it was broken.
<infinity> bgertzfield: You'll also note that modules-assistant isn't a build-dep ANYWAY, completely invalidating the argument. :)
<bgertzfield> ...
<bgertzfield> That's me with a big anime-style sweat drop on the side of my face. :)
<infinity> (No need for it to be a build-dep obviously, since it's only needed to do the custom compile stuff, not the archive package build)
<bgertzfield> right. the debian/rules crap for m-a really ought to be in a completely separate file.
<infinity> Probably, but I can see the appeal of trying to unify it.
<bgertzfield> Yeah.  But it's just so kludgey.
<infinity> Anyhow.  This all looks good to me.  I'll upload this stuff for you and shove it through the queues with a pitchfork.
<bgertzfield> Rock on.
<infinity> Thanks for putting up with my pedantry. :)
<bgertzfield> Thanks so much.
<bgertzfield> Never a problem, I'm always glad to do things right.
<bgertzfield> OK, then, I'm out of here.
<bgertzfield> Get some rest. :)
<infinity> Ciao.
<infinity> In the words of Weird Al, "I'll be mellow when I'm dead."
<bddebian> heh
<bddebian> Hey folks
<infinity> bgertzfield: Ergh.  Come back.
<infinity> bgertzfield: Nevermind.  Don't come back. :)
<infinity> bgertzfield: naughty you for sending me a different orig for the kernel modules than the one we'd previous used, though.
<infinity> azeem: https://launchpad.net/+builds/+build/179738
<LaserJock> infinity: awesome
<bddebian> Heh
<robertj> does anyone know why sabdafl is interested in TeamSpeex ;)
<Burgundavia> robertj, no idea, but it does use the free speex protocol
<robertj> The protocol is fairly standard too
<robertj> But more curiously why would he be interested in a closed source client when there is an opensource gaim plugin (albeit probably out of date already...)
<Burgundavia> robertj, where did you hear/read/come upon this?
<robertj> he posted in the TeamSpeex forums
<Burgundavia> got a linky?
<robertj> http://www.savvy.nl/blog/forum/viewforum.php?id=5
<Burgundavia> robertj, oh very odd. Maybe the funding has strings attached?
<robertj> maybe this gaim plugin doesn't actually do voice, onl ytext
<Burgundavia> maybe
<robertj> TeamBlibbityBlabbity on sf
<Burgundavia> nothing in sf cvs for 3 months
<Burgundavia> robertj, that is truly odd, but then, meh. It is his money
<robertj> Burgundavia: nothing wrong with hiring a skillset
<Burgundavia> nope
<Burgundavia> hiring somebody who knows how to do voip is a good thing
<robertj> maybe he has a hankering for tetrinat + voip :)
<robertj> err tetrinet :)
<bddebian> "I hanker for a hunka, a slap or slice or chunka.."
<Burgundavia> bddebian, uh?
<bddebian> Burgundavia: Sorry, old "School of Rock" reference :-)
<bddebian> I hadn't seen/heard the word hanker for a long time :-)
<bgertzfield> zaszzsdskjdfhlkads
<bgertzfield> oops.
<bgertzfield> infinity: argh. sorry about that; I had messed up the apt archive and had to regenerate it from scratch; I don't know reprepro half as well as I should, so I wiped it clean and started over
<infinity> bgertzfield: Oh well.  I grabbed the old orig and sorted it.  No big deal.
<bgertzfield> infinity: Thanks. *sheepish grin*
<infinity> (Which is what you should have done...)
<bgertzfield> Sorry, I didn't know that would cause an issue.  Live and learn
<infinity> :)
<bgertzfield> Yeah, I didn't know how to import an old orig using reprepro
<bgertzfield> can you even do that?
<infinity> You used to upload to Debian, no?  Surely you know that an orig can't change. :)
<bgertzfield> Sure, I know it can't, but I thought it would be ignored. :)
<infinity> The md5sum of the orig is in the .dsc
<infinity> And since I assumed you'd given me the same one, I built against that one, hence got a reject. :)
<infinity> No big deal.
<bgertzfield> got it. sorry.
<infinity> S'alright.  Not like anyone was watching except me. :P
<bgertzfield> well, can you tell me how to properly use reprepro so old packages don't linger around?
<infinity> I've never used it, tbh.
<bgertzfield> the problem I was having was importing new revisions of packages would keep old revisions in the archive
<bgertzfield> and so uploading to my slow slow foxden.org was taking exponentially longer
<bgertzfield> well, linearly longer. :)
<infinity> My archive management suites of choice are dak (AKA "katie", the software run on Dbeian's ftpmaster) for complex sites, and mini-dinstall for simple sites.
<bgertzfield> mini-dinstall. will look into it
<bgertzfield> neat, that's exactly what I want
<bgertzfield> infinity++
* infinity goes to buy some sugar to keep him up another hour or so.
<infinity> If someone wants to send go-faster vibes to lithium (the CD build host), that would be grand.
* bddebian sends go-faster vibes
<bgertzfield> *sends vibes*
<LaserJock> I'm afraid I'd mistakenly send "eat the iso" vibes, I better not try it :/
<bddebian> LaserJock: :-)
<bddebian> Night folks
<ogra> infinity, are 20060531 the finals ? 
<infinity> ogra: Yes.  I'll be sending a mail out in ~20 mins announcing that it's all ready to go.  Not quite there yet.  (almost)
<infinity> ogra: Also, aren't you up rather early? :)
<bgertzfield> infinity: Fan fricking tastic.
<ogra> my live isos are there, thats all i care about 
<ogra> nope, i'm still up
<ogra> ;)
<ogra> as you are
<infinity> Ahh.
<bgertzfield> omg! http://packages.vmware.com/vmware-player works!
<ogra> its not your privilege to be masochistic ;)
<bgertzfield> I'm so tickled.
<bgertzfield> ooh, but it doesn't go anywhere yet.
<infinity> Baby steps. :)
<bgertzfield> Hehe.
<bgertzfield> Is that all automated? (I assume so..)
<infinity> Last time I checked, I never automated anything at vmware.com. :)
<infinity> If you meant packages.ubuntu.com, yeah, it's all automated, but it's run by a 3rd party (djpig, a DD who wanted to make it go)
<bgertzfield> err.
<bgertzfield> yeah
<bgertzfield> of course, I meant packages.ubuntu.com. :)
<bgertzfield> got it, thanks.
<bgertzfield> it looks quite nice!
<infinity> https://launchpad.net/distros/ubuntu/+source/vmware-player is the canonical (and Canonical) location.
<bgertzfield> I really want the IT/Ops folks at vmware to agree to let me make an APT repository
<bgertzfield> infinity: got it.
<bgertzfield> where did launchpad.net come from? it looks quite nice
<infinity> It's Canonical's NIH re-implementation of all things relating to free software infrastructure. :)
<bgertzfield> yay. :)
<infinity> So far, a bug tracking system, a translation tracking system, and an archive management suite.
<bgertzfield> it's got to be better than debbugs..
<infinity> You may find some disagreement on that point. :)
<bgertzfield> Wow. :)
<bgertzfield> I remember where you couldn't actually make a debian package of debbugs
<infinity> Some of the more oldskool DDs in Canonical (me included) REALLY like debbugs.
<bgertzfield> they depended on some ancient version of qmail
<infinity> debbugs has improved a lot since those days.
<bgertzfield> I'm sure
<infinity> And qmail is long gone from Debian's infrastructure (thank god)
<bgertzfield> of course. :)
<bgertzfield> I'm just cranky and old
<infinity> I'm crankier and older. :P
<bgertzfield> Probably. :)
<bgertzfield> I was very happy how far all the debhelper tools have progressed.
<bgertzfield> I only ran into a few problems with all my MIME type registering, GTK+ icon theme updating, and module loading
<infinity> Yeah, if you have a bit of clue (and you seem to), Debian packaging is really quite a joy to do these days.
<bgertzfield> Well, I'm pretty rusty.  But it's coming back to me. :)  Thanks for the compliment, it's appreciated.
<bgertzfield> I noticed dapper actually has a GTK+ icon theme dh_ tool.  I didn't use it; I wanted my packages to have a chance of building on hoary and debian
<infinity> Trust me, for a "rusty" DD, you did much better than some currently active DDs and UDs.
<bgertzfield> thanks. :)
<bgertzfield> yeah, I'll have to see if I can make etch packages
<bgertzfield> shouldn't have to do much
<infinity> Do you do RPM packaging as well?
<infinity> If so, you should look at the truely perverse "run debian/rule from the spec file" hack to just re-use your debian packaging to make RPMs.. :)
<bgertzfield> We have ancient RPM packages that aren't much more than tarballs.
<bgertzfield> (no dependencies, no kernel integration)
<infinity> So, is it normal for vmware to just occasionally decice it's not been configured and require you to re-run vmware-config.pl?
<infinity> (Just happened to me 20 mins ago..)
<bgertzfield> You mean with the new package?
<infinity> Not like I'd changed anything on the system since I ran it last night, mind you.
<infinity> Silly thing. :)
<infinity> bgertzfield: No, vmware workstation.
<bgertzfield> ah, workstation
<bgertzfield> If /etc/init.d/vmware start fails, I think it decides that something is broken, and forces you to re-run the whole config.
<bgertzfield> and many things in there can fail.
<bgertzfield> that's likely what you ran into
<infinity> Oh, does it write a stamp file if it fails, or something equally silly?
<bgertzfield> It modifies /etc/vmware/locations IIRC.
<infinity> Cause I tihnk I re-ran the start target a while ago when fiddling with the bridge.  Start twice in a row apparently fails on the second go. :)
<bgertzfield> setting something like "set configured = FALSE"
<bgertzfield> infinity: I would not doubt that.
<infinity> Fragile...
<bgertzfield> Yeeeah.
<bgertzfield> well, I can go moan at the tools team about that.
<infinity> Oh well, now I know.
<bgertzfield> they technically will be owning the .deb packages too
<infinity> (And knowing is half the battle)
<bgertzfield> Remember that vmware-config.pl is meant to run on every single Linux distribution since Slackware 0.97 or some such hooey
<bgertzfield> or maybe even Yggdrasil
<infinity> Heh.
<bgertzfield> so they made that a priority, not nice package integration or actually having /etc/init.d scripts that survive being called twice. :)
* infinity grins.
* desrt glares at infinity
<infinity> desrt: Is that any way to treat your oldest and dearest friend who fixed madwifi for you?
<desrt> infinity; what else did you change in madwifi-ng?
<desrt> my macbook locks on bootup now
<desrt> unless i erase the module files and load them later myself
<infinity> desrt: Err, what?  I uploaded the same code I gave you for testing.  Honest.
<desrt> ya.  i'm just kidding.
<desrt> no glare for you.  it's working great :)
<infinity> Oh, phew.
<infinity> Jerk.
<desrt> true story
<desrt> i think the wifi actually works better than the wired
<coz_> I realize this is a visiual thing however, out of curoisity , is there a way to change the location of the logout splash , it seems to be to the left and down from center
<coz_> sorry to the right and down
<desrt> coz; no, no and no
<infinity> coz_: Err, the usplash shutdown thing, or the logout box with all the option buttons?
<coz_> infinity, the logout box
<infinity> coz_: Either way, totally irrelevant to #ubuntu-devel, mind you. :)
<coz_> infinity, irealize that thought you guys could direct me to where I could find out
<desrt> (one 'no' for no easy way for you to change it, one 'no' for it won't be fixed in dapper and one 'no' for the "is this the right place to ask?" question)
<desrt> :)
<infinity> Okay, I just measured.  The left/right thing is an optical illusion.  You're right about it being way down from the center line, though.
<coz_> desrt, wel thanks for options and thanks for telling me and thank for being very verbose about it :)
<infinity> And, also.. "so what"? :)
<infinity> coz_: File a wishlist bug in Malone for it to move up in Edgy. :)
<coz_> infinity, wel l for th so what, it si inappropriate for the a final release
<desrt> infinity; can you rephrase that as a phrase starting with 'no'? :)
<coz_> and two there has to be a way to move it I will find out and let you guys know thanks and thanks again
<infinity> coz_: No such thing as "inappropriate", unless you find copyrighted imaged of german cam girls on your fresh dapper system.
<infinity> coz_: We're testing final release CDs right now.  Cosmetic changes aren't being considered. :)
<coz_> thanks :)
<desrt> think he was upset?
<infinity> s/upset/irritating/
<infinity> You bet!
<infinity> Glad you asked.
<desrt> heh
<crimsun> heh, don't worry, he has been pestering me for alsa assistance for three months.
<desrt> ah
<infinity> Well, sheesh.  No wonder he's bitter.  Fix the poor man's sound card already.
<infinity> How will he listen to wumpscut and cut himself?
<crimsun> eh, I fixed his sound, but he wants me to do more :/
<infinity> You know it's late when it takes you 2 minutes to remember the username of the test user you just created 5 minutes ago.
<bgertzfield> It's past late. :)
<desrt> oh right
<desrt> anyone know how to extract .msi files?
<infinity> cabextract?
<infinity> (you can hope it's a cab anyway... I have no idea what they are)
<desrt> interesting idea
<bgertzfield> I don't think they're actually cabs; they contain cabs
<infinity> They reinvent that wheel every 6 months in the windows world, so who knows..
<infinity> Man, DVD builds take a long time...
<infinity> ogra: Your DVDs will be ready "eventually".... But the rest is all fine...
<desrt> so get this
<desrt> i was talking to the sysadmin at school today
<desrt> and he's buying some new opteron servers to replace our sun boxes
<desrt> and he says to me "only problem is i'm gonna have to install your ubuntu on it" as a tease
<desrt> (he's a solaris type)
<desrt> point being, he's putting ubuntu on it -- and know why?
<desrt> the 5 year support commitment
<desrt> he's like "i can't just go reinstalling the entire server every couple of years..."
<infinity> Agreed.  That's why I love Debian stable releases.
<infinity> Dapper's going to be great for people like that (and me)
<wasabi_> Yeah. Having the OPTION to upgrade to another stable release is awesome.
<wasabi_> But having the freedom to not do so is just as good.
<desrt> i didn't realise how much the LTS thing meant to real people
<desrt> it's a big deal
<wasabi_> I ran my servers with Woody for the longest time... with backported Samba, NFS, OpenLDAP, Apache, and 40 other things.
<wasabi_> That sucked.
<wasabi_> LTS = ?
<infinity> Long Term Support.
<wasabi_> k
<infinity> Ubuntu 6.06 LTS is the official product name.
<desrt> 'dapper'
<wasabi_> Yeah. Just having something you can install, with a clear path of security updates, is awesome.
<HrdwrBoB> desrt: yes, all of my linux servers will bt 6.06 LTS
<infinity> wasabi_: I still have a woody server.  Don't tell anyone.
<desrt> Error: API mismatch: the NVIDIA kernel module has the version 1.0-8756, but
<desrt> this client has the version 1.0-8762.  Please make sure that the kernel
<wasabi_> Ubuntu still doesn't have much chance of winning at my company.
<desrt> module and all NVIDIA driver components have the same version.
<wasabi_> Over Windows. ;)
<wasabi_> But I've got it "in places."
<desrt> infinity; i didn't get a 'you need to reboot' bubble from upgrading l-r-m
<desrt> infinity; but clearly this is a problem
<infinity> desrt: Yes, I didn't add the reboot notification hook, cause I'm a bad man.
<desrt> anyway.  brb :)
<infinity> desrt: I'll sneak it in on the first security update (which, conveniently, will be the first time you need to reboot as a result of installing LRM)
<wasabi_> I desperatly need local LInux support companies.
<wasabi_> Consultants, etc.
<infinity> Where is "local"?
<wasabi_> dallas tx
<infinity> Oh, there should be a whack of decent firms there...
<desrt> hm
<wasabi_> See, the problem is the ones that are advertised have no accountability.
<desrt> wine has an new look
<wasabi_> For instance, my last boss, which I left with a bunch of Linux servers (Ubuntu), after I left, went looking for one.
<wasabi_> He found one which claimed they had linux knowledge, but they failed pretty miserably, and recommended he change the entire network back to windows.
<infinity> Ouch.
<infinity> Eek, I can't believe kbd-chooser is missing a string in French.
<infinity> I would have assumed french would have full coverage in most of the more visible d-i components.
<infinity> Oh well.
<wasabi_> That stuff doesn't happen much with MS.
<wasabi_> Because they have Certified Partners. ;)
<HrdwrBoB> wasabi_: dang
<HrdwrBoB> wasabi_: we have a similar problem here, there is one linux support company that I know of, and they are oldschool unix type people
<infinity> To be fair, it's a string people will only see when doing the sketchy "type some keys to guess your keyboard layout" thing.
<infinity> In a full-auto install, everything I've seen has been in French, so far.
<infinity> I should compute in French more often.
<infinity> Technical terms in other language are so.. Bizarre..
<ogra> infinity, are you editing the wiki currently ?
<infinity> ogra: Yes.  Hold on. :)
<ogra> oki
<desrt> bah
<infinity> ogra: I recommend keeping your results from yesterday, but tagging them, and then adding the new ones.  (like I've done with ubuntu-server), since the images were nearly idential.
<infinity> identical, too.
<desrt> i cabextract this file and all of the stuff inside it comes out as 0-byte files
<ogra> yup i planned to do that
<infinity> desrt: Then I guess it wasn't a cab?
<desrt> it was, i think
<ajmitch> desrt: how disappointing
<desrt> i say.
<desrt> windows does a lot to piss me off
<infinity> Oh, for the love of.
<infinity> STOP RUNNING UPDATEDB IN THE MIDDLE OF MY DVD BUILD
* infinity glares at cron.
<infinity> ogra: If I ever get any disk I/O back, I swear your DVD will finish.  It's the last build in the queue.
<ogra> infinity, no hurry, i have enough to test here :)
<infinity> 30513 pts/3    R+     0:00 /usr/bin/mkisofs -r -V Edubuntu 6.06 i386 ....
<infinity> \o/
<ogra> yay
<infinity> Of course, i386 is probably the first one...
<infinity> Oh, no, it's the second.
<infinity> So just powerpc to go.
<ogra> :)
<infinity> janimo: Feel like testing your latest (and hopefully final) Xubuntu CDs?
<janimo> infinity: just tested yesterdays :(
<janimo> ubiquity changed?
<ogra> yes
<infinity> janimo: ubiquity and d-i changed for a critical localechooser bug.  Everything else SHOULD be the same.
<desrt> http://times.usefulinc.com/2006/03/09-macbook
<desrt> heh.
<infinity> janimo: That said, testing that the new CDs boot and at least appear to function before we publish them would be a Good Thing.
<janimo> infinity: right
<desrt> i guess i should visit shipit
<infinity> Yeah, I need to put in my order too.
<desrt> do you guys plan on having a whack of CDs at GUADEC?
<desrt> like... enough that i could take a few dozen home with me?
<infinity> My girlfriend's decided she wants to hand out CDs at her university.
<infinity> I have no idea what will or won't be happening for GUADEC.
<infinity> I know *I* won't be there, which is about all I need to know. :)
<desrt> wtf.
<desrt> i can only request 10 cds through this shipit
<infinity> Oh, did we take out the custom order/comment box?
<desrt> indeed
* infinity pokes at it.
<desrt> they 'tweaked' my order last time and i ran out of PPC cds :(
<desrt> this time the tweaking occurs preemptively
<infinity> We have not yet opened the custom request section of ShipIt for version 6.06 LTS, but will do so shortly. If you'd like to order larger quantities of CDs than what is listed in the standard options, please supply a clear reason for ordering. We will consider special requests for larger quantities under special circumstances. If you experience any problems with ShipIt, please:
<infinity>     *
<infinity>       Email [MAILTO]  info@shipit.ubuntu.com
<infinity> (Fronthe FAQ linked at the bottom of the page)
<desrt> i wonder if using your @ubuntu.com address to order improves your chances of pushing through a custom request
<infinity> So, either "wait for the custom ordering to open up", or email now and beg to do one.
<desrt> i can wait
<desrt> i don't need them until september
<infinity> I'm guessing we're doing pre-packaged bundles only for now to get the CDs flowing as quickly as possible from the distributor.
<desrt> probably.
<infinity> Custom orders require manpower and thought, so slow down the whole process.
<desrt> for the time being, i'm going to bed
<desrt> goodnight, good fellow
<infinity> 'Night.
<infinity> ogra: Okay, your DVDs are done.  And so am I.  I'm going to go pass out.
<infinity> ogra: (The mirrors will be rsyncing for a while, though, so feel free to hold off for a bit before you refresh your local copies..)
<bgertzfield> infinity: Congrats again.  Go sleep.
<ogra> infinity, will do, sleep tight :)
<sfllaw> infinity: You rock.
<kagou> hi
<pitti> Good morning
<Burgundavia> morning pitti
<pitti> Hi Burgundavia 
<kagou> hey pitti 
<pitti> sfllaw: do you want to update the testing matrix? shall we dump old results?
<pitti> hi kagou 
<sfllaw> pitti: Yeah.  We probably should.  Except for old failures and passes with flaws.
<sfllaw> I'll do that before going off to bed.
<sfllaw> Which is soon.
<pitti> hi fabbione 
<fabbione> hi pitti
* fabbione > office
<ogra> sfllaw, are you still editing ? 
<pitti> hey ogra
<ogra> hi pitti
<sfllaw> ogra: Yes.
<G0SUB> pitti: hello!
<pitti> G0SUB: hey
<G0SUB> pitti: got my reply?
<pitti> G0SUB: hm, no
<G0SUB> pitti: what?
<sfllaw> ogra: Done.
<G0SUB> pitti: I replied to your mail almost imeediately
<G0SUB> immediately
* pitti checks procmail logs on his server
<sfllaw> ogra: Argh.   Conflicts.
<ogra> sorry, the lock was gone save your stuff
<ogra> (i have mine here to add)
<pitti> G0SUB: oops, SA sorted it into the spam folder, sorry
<G0SUB> pitti: damn! but which test did the mail fail?
<pitti> G0SUB: I'll teach it not to, sorry
<sfllaw> ogra: Done.
<sfllaw> MoinMoin needs better conflict resolution.
<ogra> sfllaw, sorry for the fuss
<G0SUB> pitti: heh, okay :)
<Burgundavia> sfllaw: it is minorly better than mediawikis, but yes, they both suck
<ogra> sfllaw, argh, how old was the copy you were working of ? the edubuntu table is compeltely empty
<sfllaw> ogra: I cleared out all the PASSes.
<ogra> ARGH
<sfllaw> Ah.  I see what's happened.
<sfllaw> I'll reconstruct.
<ogra> thanks
<ogra> 20060530.2 is only different from 20060531 in some lines of code for chinese language in d-i and ubiquity 
<sfllaw> ogra: Aren't we testing 20060531 now?
<pitti> G0SUB: ah, thanks!
<ogra> sfllaw, they are neary identical, so i woould like to keep the 20060530.2 results
<sfllaw> If you promise to go replace them with 20060531 results afterwards, then OK.
<sfllaw> I'll restore those.
<ogra> thanks, i dont think you will need extra testing for 20060531 except for chinese installs, but well
<sfllaw> ogra: Famous last words.
<ogra> oh, lucky me, i totally forgot we had no edubuntu powerpc in breezy, saves one upgrade test :)
* pitti -> parallel CD testing, need to go offline
<ogra> dapper-dvd-i386.iso
<ogra>   3452166144 100%    4.80MB/s    0:11:26  (1, 100.0% of 1)
<ogra> :D
<\sh> guys, who can I kick to have a look into hibernating on toshiba r200, since -23 it doesn't work anymore....I tested kubuntu RC yesterday and executed /etc/acpi/hibernate.sh and on toshiba r200, when it comes up again, it switches into graphics mode, and then nothing works anymore.
<\sh> same on some sony laptops
<\sh> brb
<Burgundavia> \sh: there have been intermittent reports of suspend breaking recently
<dholbach> good morning
<ajmitch> morning dholbach, seb128, mvo :)
<dholbach> hey ajmitch
<seb128> hi
<mvo> hello ajmitch
<\sh> Burgundavia: ah...I was surprised, because with -22 it was still working 
<carlos> Riddell_: hi
<carlos> around?
<Mithrandir> dholbach: we might want to look at getting ddccontrol in eft.  Useful for setting monitors that doesn't have controls on them
<Mithrandir> http://ddccontrol.sourceforge.net/
<dholbach> Mithrandir: that sounds cool
<Mithrandir> should be a system->settings thingy, I'd imagine
<dholbach> Mithrandir: daniel elstner will be delighted (a friend of mine)
<Mithrandir> :-)
<ajmitch> a good project for a potential MOTU to package up for edgy, perhaps :)
<dholbach> I think he even wanted to package it himself
<dholbach> or even has it already
<dholbach> I didn't have the time to look closer, I'm afraid
<seb128> bah, no screenshot
<Mithrandir> ajmitch: it's ITP-ed in Debian.
<ajmitch> ah right
<ajmitch> doesn't surprise me
<ajmitch> yay, 3K/sec rsync
* ajmitch blames his ISP
* ogra is off for more ppc testing bbl
<TheMuso> c
<fabbione> ok guys
<fabbione> are you all testing?
<ajmitch> still rsyncing
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Release preparation in progress: https://wiki.ubuntu.com/DapperReleaseRadar | Upload Queue closed, ping infinity if you need a non-main upload massaged through | TEST TEST TEST!
<janimo> JaneW: hi
<sivang> morning all
<azeem> infinity: great, cheers
<JaneW> janimo: hi - are you xubuntu jani?
<janimo> JaneW: yes
<JaneW> janimo: ah :)
<janimo> JaneW: I was going to ask about the newsletter :)
<janimo> should I just write one ASAP and send it to news?
<janimo> it is not clear to me weather I should just pass some data to the doc guys who can write a more coherent mail
<Burgundavia> janimo: you might want to ping mgalvin, he might be able to help you
<JaneW> janimo: I mailed you...
<JaneW> janimo: no it's each team to themselves for now, the doc team will probably take it on soon to start the consolidated letter, once the separate feeds are established
<janimo> JaneW: yes just read the mail, but was not clear if I should just go ahead chosing any day of the week or sync with the other teams
<JaneW> janimo: so far it's Riddell-kubuntu, jsgotangco et al - Edubuntu, mgalvin-ubuntu, janimo-Xubuntu
<JaneW> janimo: I think synching is the next step, so go ahead independently for now
<janimo> ok I think I'll write one right after the release
<Burgundavia> janimo: if not, I might be able to help you. Can you email the -doc list some ideas/stuff?
<janimo> Burgundavia: thanks, I'll try to
<Burgundavia> anyway, I need to sleep
<Kamion> morning all
<Kamion> DVD images need to be rebuilt - uninstallables due to a cdimage vs. seeds issue that's been there for a while but I only just noticed
<carlos> Riddell: hi, are you around?
<carlos> Kamion: morning
<Mirv> huge thanks for getting more language packs in, even though it means I have to retake my Finnish install guide screenshots :)
<Kamion> (the DVD issue is that packages in the live and ship-live seeds weren't appearing on the images - we had up to desktop and then a sort of "hole" between that and supported)
<Kamion> right, fix pushed I believe, DVDs rebuilding
<carlos> seb128: btw, the new evolution template is already imported
<seb128> carlos: cool, thank you
<dholbach> Mithrandir, fabbione: can we get something so that the X configuration gets the right resolution without a monitor plugged on? I have a bad resolution everytime, I have the KVM switch turned to the other screen :)
<fabbione> dholbach: hmmm let me think a second about it....  no
<fabbione> dholbach: or you can force the monitor frequencies in the config
<dholbach> Ok
<Kinnison> Kamion: do we have images of DVDs?
<pitti> Mithrandir: which package should I file a bug in OEM mode on?
<fabbione> oem-installer ?
<pitti> fabbione: ah, ok :)
<Kamion> pitti: that's oem-config
<pitti> no such package
<pitti> thanks
<Kamion> Kinnison: the DVD rebuilds are on their way
<Kinnison> Kamion: Do we make images, or just torrents/jigdos?
<fabbione> Kinnison: images too
<Mithrandir> pitti: oem-config
<Kinnison> fabbione: right
* Kinnison has almost finished his current tests
<Kamion> Kinnison: images
<Kamion> hmm, something's still wrong with the DVD builds
* Kamion investigates
<fabbione> Kinnison: current as when?
<Kinnison> fabbione: images downloaded an hour or so ago
<Kamion> I've improved the situation, but ...
<fabbione> Kinnison: new images have been rolled this morning around 6am
<fabbione> Kinnison: ok
<Kinnison> :-)
<Keybuk> Kinnison: come up with new tests ... try installing in a different language, try partitioning differently ... try doing something new on the live, etc.
<Kinnison> Keybuk: I've been running all the apps on the live
<Kinnison> Keybuk: slowly
<Kinnison> :-)
<Mithrandir> Kamion: the current DVD images aren't the final ones?  I'll do cd testing instead, then.
* pitti did a Russian install, that was quite entertaining :)
<fabbione> pitti: vodka!
<fabbione> i did try italian yesterday
<fabbione> a tragedy
* dholbach should try a french one next
<dholbach> although i guess the keyboard would kill me :)
<fabbione> something literally translated as "Installing" to "Installaizing"
<pitti> fabbione: and that's wrong?
<pitti> dholbach: you can still choose a German or English keyboard
<fabbione> pitti: quite...
<dholbach> Installizing sounds a bit wrong to me :-p
<pitti> Installazione Ubuntu pizza mafia Fabbione
<fabbione> ehhee
<Keybuk> Kinnison: you've run all the apps on the live cd, done a test install, run all the apps there, done an alternate install, tried other languages in both live and alternate, etc. in just an hour?
<Kinnison> Keybuk: No
<Kinnison> Keybuk: So far I've run the apps on the live CD
<Kinnison> Keybuk: Not all of them yet
<Kamion> Mithrandir: nope
<Kinnison> and I've sneezed the greater majority of my brain out along with my hayfever
<Mithrandir> Kinnison: mmm, brains.
* Kinnison thinks the grass pollens have started in the UK
<jdub> mvo, bgertzfield: new modules packages don't conflict/replace/etc the old separate ones
<Kamion> don't they install to a different location on the filesystem?
<jdub>  trying to overwrite `/lib/modules/2.6.15-23-686/misc/vmnet.ko', which is also in package vmware-player-kernel-modules-2.6.15-23-686
<Kamion> should be replaces then not conflicts
<Kamion> well, I guess it could be conflicts too since the old packages have gone away
<mvo> jdub: right, I will have a look
* jdub wonders why hald-addon-storage and gnome-cups-icon sit around chugging <= 1% cpu
<Kamion> right
* sivang -> back
* Kamion tries another round of DVD builds
<Kamion> including the server seed this time
<Mithrandir> jdub: because giving you up-to-date status on your printer is important.
<jdub> ooh
<jdub> May 31 19:48:52 localhost kernel: [4459711.966000]  VFS: busy inodes on changed media.
<jdub> ~4 every second
<fabbione> jdub: stop mplayer pron.avi while you do other stuff? ;)
* pitti goes back to more CD testing, bbl
<sladen> jdub: can you search back in the logs for the previous  "VFS: Disk change detected on device.*"
<sladen> jdub: and that will have the device major:minor at the end of the string
* Kamion notices himself joining and concludes that his home network has come back ...
<jdub> sladen: none at all, going back to dmesg
<jdub> sladen: but i just put a CD in the drive, and it's stopped
<jdub> sladen: must've been a mess left by an old cd mount
* jdub ejects, nothing in kern.log
<sladen> jdub: did you manage to eject the CD while it was still mounted/in use by something?
<sladen> jdub: yeah, very likely
<jdub> must have
<jdub> ok, so now it's just cups-icon jumping up and down, but that's normal
<Riddell> carlos: hi
<carlos> Riddell: hi
<carlos> Riddell: I need a .pot file for koffice that you didn't gave me, the one to translate the .desktop files
<carlos> Riddell: desktop_koffice
<carlos> Riddell: outside that one, koffice and k3b are fixed now
<carlos> Riddell: also, I had to fix kchart and kpresenter to set the encoding to UTF-8, seems like the .pot files you gave me are not using your script to fix that one
<Riddell> carlos: that won't be any use, there's nothing to put the strings back into the .desktop files
<carlos> Riddell: isn't KDE using gettext like we do with GNOME to get updates from .mo files?
<Riddell> not yet
<carlos> ok
* Riddell is unsure what to do about ia64 kubuntu being so oversized
<doko_> rsync's from cdimage are slow, or just abort (connection unexpectedly closed) :-/
* Kinnison moans at his router breaking while he's not paying attention
<Kamion> Riddell: alternate should be fixable
<Kamion> Riddell: I'll have a look in a moment
<Kamion> Riddell: I vote for ignoring desktop though - that would involve a -meta upload
<Riddell> Kamion: will it break anything to not have language-support-en on it?
<Kamion> Riddell: yes
<Kamion> I'll have a look and see what the problem is
<Kamion> Ubuntu (20060531.2) and Kubuntu (20060531.1) DVDs updated and now with zero uninstallables
<Kamion> about to rebuild Edubuntu DVDs
<Kamion> can somebody please update Testing/Current for those/
<Kamion> ?
<Riddell> Kamion: I'll update Testing/Current
<Keybuk> Riddell: already done
<Riddell> so it is
<dholbach> Kamion: how can I further debug  http://daniel.holba.ch/Screenshot.png ? which info do you need?
<Kamion> dholbach: sorry, what's the problem there?
<dholbach> Kamion: gparted is not gtk-plugged
<Kamion> oh I see
<Kamion> er, dunno, is it being invoked with the right arguments (window id)? use xprop to check ubiquity's window id
<seb128> dholbach: did you do something special like going forward backward and doing changes and cancelling them? I managed to get that some time ago while playing like that
<Kamion> hate hate gparted
<Kamion> </mantra>
<dholbach> seb128: yes, I tried manual partitioning and it jumped to the choose partition<->mountpoints thing and I though I'd hit "Forward" two times, so I went back
<mvo> is it known that the cd integrity checker jumps around a lot?
<pitti> mvo: ping (u-m could not calculate upgrade, although 'sudo aptitude dist-upgrade' didn't complain)
<dholbach> mvo: I think so.
<dholbach> Kamion: ps afxvw    says:       gparted --installer 0
<seb128> dholbach: k, might be worht mentionning what you did when you point a such bug :p
<Kamion> score!
<\sh> ILO Boards from HP == TOP, eRIC Boards from Peppercorn == Totally b0rked shit
<mvo> pitti: aptitude/apt never complain, they just happily remove ubuntu-desktop and go on :)
<mvo> pitti: can you put the logs somewhere for me please? 
<Kamion> that comes from gtk.Socket().get_id() basically
<pitti> mvo: sure, I'll file a bug
<mvo> pitti: it may take a bit for me to answer because I'm going to have lunch
<Kamion> well, after adding it to a window
<mvo> pitti: have you seen my cusys bugreport?
* mvo is having lunch
<Kamion> dholbach: ubiquity bug; my only guess is that there was already a gparted running for a brief period so ubiquity failed to add the new one to self.embedded and then got confused
<pitti> mvo: not yet
<dholbach> Kamion: which logs would you like me to attach to a possible bug report?
<\sh> I wonder if there is a patch to fdisk/sfdisk/cfdisk for partitioning disks with sectorsize is > %9L
<Kamion> dholbach: just /var/log/installer/syslog please
<dholbach> Kamion: ok
<Kamion> (may not be amazingly useful though)
<dholbach> Kamion: thanks
<Kamion> np
<pitti> mvo: bug 47648
<Ubugtu> Malone bug 47648 in update-manager "could not calculate upgrade" [Normal,Unconfirmed]  http://launchpad.net/bugs/47648
<sladen> \sh: 1MB sectors?
<dholbach> Kamion: bug 47652
<Ubugtu> Malone bug 47652 in ubiquity "ubiquity doesn't pass correct window ID to gparted --installer" [Normal,Unconfirmed]  http://launchpad.net/bugs/47652
<Kamion> thanks
<janimo> md
<janimo> never mind
<doko_> orga: FYI testing edubuntu DVD's
<Kamion> the edubuntu DVDs only *just* finished building :)
<Kamion> and have zero uninstallables, excellent
<ogra> Kamion, ??
<\sh> sladen: standard sectors
<Kamion> can somebody update Testing/Current for Edubuntu DVDs 20060531.1?
<Kamion> ogra: wake up, I mentioned this issue this morning
<\sh> sladen: it's not possible to set the EFI GPT id (ee) before you setup a partition...
<Kamion> uninstallables on DVDs due to cdimage vs. seeds issue
<ogra> Kamion, i was offline due testing 
<ogra> ARGH
<Kamion> it's fixed in the build I just did
<ogra> i'm just done
<Kamion> and you didn't notice the uninstallables?
<ogra> nope
<ogra> all fine
<Kamion> excellent testing there :-P
<Mithrandir> Kamion: the regular DVDs are built too now?
<Kamion> Mithrandir: yeah
<Mithrandir> excellent
<Kamion> ogra: you obviously didn't read report.html
<ogra> the amd64 workstation install is just finishing right of me
* Mithrandir rsyncs to make sure his stuff is fresh
<Kamion> there were several hundred uninstallables, although none in the regular installation path
<ogra> gar
<sladen> \sh: can you explain that in more detail?  Is this a limitation of gparted?
<sladen> \sh: or is that the only way to force a commit of the updated partition table to the disk?
* sivang needs to backup up stuff here and re-install with seperate /home and / and have a test round on the way
<ogra> Kamion, anything else important i have missed like i have to redo my liveCD tests as well or something ?
* Kinnison has been looking at the default desktop in french
<Kinnison> the OOo menu entries aren't translated unless 'Spreadsheet' and 'Word Processor' are french
* sivang goes to download a latest daily
<Kinnison> The GIMP entry isn't translated into french either
<pitti> Kinnison: you don't have the French langpack installed then?
<Kinnison> pitti: Just went to language-support and ticked 'french' then logged out and logged back in having chosen french (utf8@euro) from the language menu as per the instructions
<pitti> Kinnison: there still seems to be a bug in the fallback to the .desktop translations if the langpack doesn't provide the translations
<Kinnison> pitti: it installe a bunch of packages
<pitti> Kinnison: but most of the menu entries are French?
<pitti> Kinnison: OO.o .desktops are scarcely translated
<Mithrandir> Kinnison: utf8@euro? eww
<Kinnison> pitti: Aye everything I've looked at thus far except for the GIMP and OOo are translated
<Mithrandir> Kinnison: there's no UTF-8@euro in /usr/share/i18n/SUPPORTED ..
<pitti> Kinnison: ok, that sounds sane then; it at least sounds possible that the gimp .desktop is simply untranslated then (you can check the .desktop file)
* dholbach ran into bug 47607
<Ubugtu> Malone bug 47607 in ubiquity "At final stage of installation (96%) installer crashed" [Normal,Fix released]  http://launchpad.net/bugs/47607
<Mithrandir> pitti: probably got bit by the last-minute change to the ooo desktop files, then
<dholbach> I thought I'd try xfs
<pitti> Kinnison: right, UTF8@euro is something that has been an error from the beginning and should die
<Kinnison> Mithrandir: it was presented on the menu so I did the "I'm a user" thing of picking the one which was probably right for me being in europe
<pitti> Kinnison: menu -> in expert install or language-selector?
<\sh> sladen: no..there is a limitation in sfdisk/cfdisk/fdisk..parted works
<Mithrandir> ok, it took about two minutes to find a bug in konqueror. :-P
<Kinnison> pitti: language-selector
<pitti> Kinnison: ouch; that deserves a bug report
<Kinnison> pitti: looks like the gimp itself is translated
<Kinnison> pitti: just not its .desktop
<Keybuk> mvo: if I have an Ubuntu dapper DVD in the drive of a Breezy machine ... how do I "upgrade" to that using update-manager?
<mvo> Keybuk: we don't support a full upgrade with only a cd/dvd yet (full == including sources.list rewriting and everything) 
* Kinnison -> cook lunch, back soon
<pitti> mvo: I found out the cause of u-n breakage; it might affect hoary->breezy upgraders (unless that removes the old kernels, but I doubt that)
<sivang> should I follow http://wiki.ubuntu.com/Testing/Current to do testing ?
<pitti> sivang: yes, please
<sivang> pitti: k
<mvo> pitti: I have noticed, yes. I think we should add it to the release note 
<zul> heylo
<pitti> Keybuk: I manually did apt-cdrom add (or use synaptic, which adds it for you), then call u-n normally; that worked (just a cosmetics issue, bug 46340)
<Ubugtu> Malone bug 46340 in update-manager "confusing dialog when using CD as apt source" [Minor,Confirmed]  http://launchpad.net/bugs/46340
<pitti> mvo: do you think that can be easily fixed with another breezy-updates version?
<Kamion> ogra: alternate and desktop CDs have not been changed since this morning
<mvo> pitti: possible, but its a bit tricky :/ (needs some thought)
<ogra> Kamion, ok
<Kamion> dholbach: yes, ddon't use XFS for /
<AlinuxOS> pitti, https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/47393  here is everything for future 0.3 ttf-bpg-georgian-fonts realise, with bpg font optimised .fonts.conf file. As actual 0.2 version has ttf-bpg-georgian-fonts.hints bug. If it possible to fix after realise, no problems, We can wait :)
<Kamion> at least without creating an XFS /boot
<Ubugtu> Malone bug 47393 in ttf-bpg-georgian-fonts "ttf-bpg-georgian-fonts v 0.3 Candidate is Ready." [Normal,Confirmed]  
<pitti> mvo: ok, thank you; update-notes are probably fine for that
<pitti> AlinuxOS: not now, please; post-release
<dholbach> Kamion: I'd never do it in real life, I just wanted to do variations
<Kamion> oh, indeed
* pitti tried root on JFS the first time on his life, and found it working
<AlinuxOS> pitti, ok, don't worry! good luck! and good work to all!
<Kamion> ok, think I know why ia64 alternate is oversized
<sladen> pitti: try root on reiserfs, it's the first thing that Gentoo users try
<pitti> sladen: that's what I usually do anyway
* sladen runs away, fast
<\sh> ugh...reiserfs
<pitti> sladen: I use 50:50 reiserfs/ext3 in the install tests, and some XFS/JFS just for the fun in tests
<pitti> hey, just because Hans is a bit queer, the fs rocks
<Mithrandir> pitti: sure, for /tmp and such.
<Mithrandir> eraserfs isn't safe, IME.
<Seveas> ricer fs
<pitti> why do you think so? /me never had any problem with it
<sivang> reiser is nice, just not for /boot
<pitti> sivang: I don't have separate /boots (I don't need them, woudl just be a waste for me), but booting reiser works fine on the three arches I have
<Mithrandir> pitti: eraserfs and jfs are the two file systems which have lost data for me.
* pitti thinks this is more a religious than a technical war
<sivang> ah cool, I'll try that then in the upcoming install on this SATA laptop
<AlinuxOS> Mithrandir, is reiser faster then ext3 ? I personally use ext3 evrhywhere.
<Mithrandir> AlinuxOS: no idea.  I care less about speed than integrity.
<pitti> AlinuxOS: it handles many small files much more efficiently; I don't have benchmarks, but it's said to be faster due to some clever inode organization (binary trees and such)
<Keybuk> hey
<Keybuk> anyone with an i386 dapper desktop
<AlinuxOS> Mithrandir, I prefer speed as I use laptop... with 5400rpm. maybe I'll try reiser in future.
<Keybuk> please modprobe i83265
<Keybuk> (save any work before hand)
<pitti> AlinuxOS: both are journaling fses, and in my experience hard disks crash more often physically than due to fs corruption (but that's just me!)
<pitti> anyway, OT
<Seveas> Keybuk:
<Seveas> dennis@mirage:~$ sudo modprobe i83265
<Seveas> Password:
<Seveas> FATAL: Module i83265 not found.
<AlinuxOS> pitti, :) hehe personal experiences. The same for me :)
<AlinuxOS> pitti, ok. nomore OT.
<Mithrandir> Seveas: I think s/32/23/ is what he meant.
<Keybuk> sorry
<Keybuk> typo
<Keybuk> please modprobe i82365
<Seveas> dennis@mirage:~$ sudo modprobe i82365
<Seveas> FATAL: Error inserting i82365 (/lib/modules/2.6.15-23-686/kernel/drivers/pcmcia/i82365.ko): No such device
* Fujitsu is suspicious.
<Fujitsu> Same here.
<Keybuk> anyone else?
<HrdwrBoB> wfm
<HrdwrBoB> well.. fatal no such device
<dholbach> FATAL: Error inserting i82365 (/lib/modules/2.6.15-23-686/kernel/drivers/pcmcia/i82365.ko): No such device
<sivang> same here, but I am on laptop
<Keybuk> "No such device" is ok
<HrdwrBoB> yeah
<Seveas> same here on another machine
<sivang> err, no
<sivang> sivan@swirl:~$ modprobe i83265
<sivang> FATAL: Module i83265 not found.
<Fujitsu> I'm on a laptop, but I don't have a PCMCIA card slot.
<Seveas> sivang, s/32/23/
<Fujitsu> i82635, sivang.
<mjg59> sivang: i82365
<Fujitsu> Oops.
<mjg59> Not i83265
<Fujitsu> I said it wrong :(
<sivang> mjg59: ops, yes, I have this here
<sivang> -> No such device
<fabbione> sladen: did you finish to edit the page?
<fabbione> (testing/current)
<dholbach> no such device on another machine as well
<infinity> Kamion: Ouch on the DVD rebuild issue....
<infinity> Kamion: Otherwise, is everything looking good so far?
<Mithrandir> the volume label should have today's date, not tomorrow
<Mithrandir> 's, right?
<sladen> fabbione: go go go
<pitti> mvo: yay, successful breezy->dapper dist-upgrade with both l-support-{en,de}
<pitti> mvo: I'll try the ppc one again now, maybe it was just PEBCAK
<Kamion> infinity: think so, couple of -updates issues discovered
<Kamion> infinity: oh and I'm trying to sort out ia64 oversizing (overenthusiastic transitional packages in ship, can't fix in live though)
<dholbach> fabbione: tell me when you finished editing?
<infinity> Kamion: Well, we always have ia64 ubuntu-server, so whatever. :)
<fabbione> dholbach: saving now
<dholbach> fabbione: rocknroll
<fabbione> dholbach: done
* dholbach grabs lock
<Kamion> infinity: yeah, not too bothered about ia64 desktop, we can just not publish it
<Fujitsu> IA64 being distinct from AMD64?
<Kamion> yes
<HrdwrBoB> very much so
<infinity> Kamion: I don't think any of the ports/desktop CDs work anyway, I just built them for people who felt the urge to test.
<infinity> Kamion: So best to not publish the whole lot.
<simira> marilize: is it possible to get Dapper cd'e to Norway within a couple of weeks? We're having an install-fest
* pitti taps foot for dholbach's wiki lock
* sivang slowly backs up stuff to DVD while downloading a desktop-cd
<dholbach> pitti: saving...
<dholbach> pitti: done
<Kamion> infinity: *nod*
<pitti> dholbach: *hug*
<Keybuk> ok, nobody's desktop crashed; will assume that's safe on dapper then
<KaiL_> are there any ia64 desktops in the world? I thought, that arch is only used for (very few) servers?
<HrdwrBoB> possibly used by mad scientists and insane geeks
<HrdwrBoB> who are not relevant to real desktops
<infinity> KaiL_: There are thousands.
<KaiL_> infinity, compared to even millions for Sparc? ;)
<infinity> KaiL_: In the workstation world.  But none of them would be running Linux.
<Fujitsu> 64-bit Isomethingorother?
<Fujitsu> Itanium?
<KaiL_> Fujitsu, yes
<Fujitsu> THey are pretty rare, and only in servers, as far as I know...
<KaiL_> no wonder: afaik only a few Linux distributions and HP Unix run on it
* mvo hugs pitti
<Keybuk> infinity: did you sleep well?
<infinity> Keybuk: I kept tossing and turning, worrying about the release. :P
<pitti> so, I tested all variants of alternate, now let's go to desktop. I'll be offline for some time again
<Keybuk> heh, I was dreaming about something release related
<Fujitsu> So, there's Desktop, Alternate and Server?
<infinity> I had dreams that all the CDs had to be rebuilt because of something that wasn't even shipped on them, and it was all my fault, and blah blah.
<infinity> It was a pretty rought dream.
<infinity> rough, too.
<fabbione> Fujitsu: please move to #ubuntu. these are FAQ by now
<infinity> Hence this, as soon as I woke up:
<infinity> cdimage@lithium:~/cdimage/www/full$ find . -name current | xargs ls -l
<fabbione> and we are busy preparing a release
<infinity> And the pleasant discovery that only DVDs had been rebuilt.
<Fujitsu> Noted, sorry.
<fabbione> can somebody please make sure to perform an installation in Japanese and thai?
<Fujitsu> I did a Japanese installation a couple of days back...
<Kamion> we need one following the localechooser changes last night, I'm afraid
<Fujitsu> Aha.
<Mithrandir> Riddell: is kdm not translated?
<Riddell> Mithrandir: it is, it just never uses the translations
<ogra> Kamion, base-installer: info: found kernels ''
<Riddell> it doesn't use the system locale, it uses what's specified in /etc/kde3/kdm/kdmrc which defaults to english
<ogra> :(
<Mithrandir> Riddell: it should pick up the system default and put it in that file, then
<ogra> that didnt happen on 20060530.2
* morgs just noticed cool space images in screensaver... in /usr/share/backgrounds. Are they sabdfl's?
<LaserJock> morgs: I think those have been around since anchient times
<morgs> Duh, I should browse my filesystem more!
<ogra> morgs, the ones sabdf1 contributed are in the screensaver-default-images package
<Keybuk> LaserJock: where ancient ~= last week
<pitti> dholbach: ping
<ogra> Kamion, seems the GPG key on the edubuntu install CDs is broken
<LaserJock> Keybuk: oh sorry, I just remember using space pictures in Red Hat 7.2
<morgs> Mmm, space pics the founder took personally - some bling Gentoo doesn't have ;-)
<Kamion> ogra: GPG key> er, really? details
<Kamion> ogra: please send me the full log for that base-installer problem
<Kamion> ogra: I assume that was on a DVD although you didn't say
<sivang> oh crap, download ETA 54% [===================================================> 55% [===================>                 ]  403,619,864  153.43K/s    ETA 46:09
<sivang> /home/sivan/machines-backups
<sivang> 45:57/home/sivan/machines-backups
<ogra> Kamion, nope thats amd64 install
<ogra> no dvd
<Kamion> ogra: ok, please send me the log
<ogra> yep
<doko_> Kamion: how long does a fs resize take (150gb -> 75 GB)? the progress bar stays at 0% for now 5min.
<Kamion> doko_: ages
<Kamion> yes, I know the progress bar isn't updated, it's annoying but it's known
<infinity> doko_: If there's actually data on that partition, it'll take FOREVER.
<pitti> sivang: ah, I just discovered the breakage of moving files from 'Examples' to the Desktop (which fails due to r/o). Your patch works?
<pitti> doko_: for my standard ubuntu install it took about 5 mins
<pitti> doko_: on amd64, that is; about 10 on my iBook
<sivang> pitti: it's not in, seb128 said it is material for dapper-updates
<pitti> sivang: I know; I'm just curious whether the patch works
<sivang> pitti: let me test here (I'm patched
<Mirv> is seb128 the only one who could check why the translations for Gaim .desktop have disappeared at least for some languages in new installation? I filed bug 47669 now
<Ubugtu> Malone bug 47669 in gaim "Menu entry has lost its translation in at least Finnish" [Normal,Confirmed]  http://launchpad.net/bugs/47669
<Mirv> there :)
<pitti> Mirv: same here for German
<pitti> hey hey seb12
<pitti> and seb128
<pitti> and all other seb# around
<sivang> pitti: like a charm :)
<sivang> pitti: just tried
<Mirv> it looks a bit ugly as now finally about all the menu entries would have been nicely translated.. but Gaim is not
<seb128> hi pitti ;)
<ogra> Kamion, http://people.ubuntu.com/~ogra/gpg-error-syslog
<Mirv> seb128: I was _just_ talking about you. see http://launchpad.net/bugs/47669  - pitti said the same is with german
<Ubugtu> Malone bug 47669 in gaim "Menu entry has lost its translation in at least Finnish" [Normal,Confirmed]  
<seb128> Mirv: what menu entry is not translated?
<Mirv> seb128: Gaim; it used to be earlier, but with a fresh installation it is not
<pitti> Mirv: we should be able to fix that with updated langpacks, unless the POT file is broken, too
<Kamion> ogra: ok, the base-installer error is due to the GPG key problem
<seb128> it's translated to french
<Mirv> pitti: yes, the translations should be in langpacks, but the desktop file now being installed in a new installation has not got the translations
<Mirv> seb128: it might be translated for languages that had translations in the desktop file in upstream
<ogra> Kamion, yep, that far i grokked it, but why is the gpg problem ? 
<Kamion> -r--r--r--   1    0    0            1901 May 31 2006 [   2295 00]   Release
<Kamion> -r--r--r--   1    0    0               0 May 31 2006 [   2296 00]   Release.gpg
<Kamion> hmm, indeed
<ogra> ouch
<Kamion> weird, I'll look at that
<ogra> its fine on the liveCDs
<seb128> Mirv: that might be a bug with the gettext patch for .desktop, pitti will know better
<Zomb> high... stupid questions, how do plans for xorg-7.1 look like?
<sivang> hmm, "Exprience ubuntu.ogg" on my lap box basically has no video performance what so ever
<sivang> :-/
<seb128> Zomb: we are sort of busy with dapper atm
<Mirv> seb128: also, the translations are there if you don't have a new installation. my dapper at home still has the translation even though it's updated
<Mirv> seb128: ok
<Zomb> seb128: no doubts from me... :-)
<seb128> Zomb: so not the timefor new xorg or GNOME
<mvo> Zomb: lets talk about it after release :)
<Zomb> yeah
<Zomb> ok, thanks
<Kamion> ogra: only affects edubuntu alternate amd64; I just checked
<imbrandon> Zomb, you are better off asking in #ubuntu for the moment , the developers are busy with the release very soon ( or come back after release )
<infinity> That's bizarre.
<ogra> ah, good, race condition ? delay in copying ? 
<ogra> is it possible to rebuild only amd64 ?
<Kamion> gpg: fatal: can't read `/home/cdimage/.gnupg/random_seed': No such file or direc
<Kamion> tory
<Kamion> oddness
<Kamion> I wonder if that was a parallel build in progress or something
<Kamion> infinity: were you building something else at the same time?
<Kamion> ogra: yes, that's pretty easy, I'll do that
<ogra> thanks :D
<ogra> phew
<Kamion> building
* ogra takes a break
<infinity> Kamion: Yeah, I suepect the edubuntu alternates were in paralell with a DVD build.
<Kamion> fun little gpg bug, that
<infinity> Kamion: Likely because someone (not naming any names) has spend the last 6 months bragging about the cdimage parallelisation, and how wickedly fast and aweomse it is. :P
<infinity> awesome, too.
<Kamion> :-)
<Kamion> I think we still win overall ;)
<Kamion> but yeah, maybe better stick some locking in there - or just fix gpg
<pitti> Kamion: maybe gpg uses flock() for accessing the seeds, in order to avoid races on rewriting it, or so?
<Kamion> ogra: edubuntu amd64 updated; other arches carried over unchanged
<Kamion> 20060531.1
<Kamion> good catch on that
<ogra> thanks !! :)
<Kamion> -r--r--r--   1    0    0             189 May 31 2006 [   2296 00]   Release.gpg
<Keybuk> that was a very quick rsync ;)
<seb128> pitti: that was fast ;)
<Mithrandir> do we have a test plan for rescue mode or is it just "boot into it, make sure it looks decent, mark as pass"?
<pitti> seb128: yes, just rebooted from live CD to ubiquity install
<pitti> Mithrandir: I tried to reinstall grub/yaboot and to get a shell in my root partition
<infinity> Mithrandir: What pitti said.  I've actually tested that is DOES stuff a couple of times.
<infinity> s/is/it/
<Mirv> pitti: it looks like Rosetta has lost .desktop translations for Gaim. actually for German there's a translation in the desktop file, but it is from upstream and is just "Gaim Internet Messenger" instead of something more German
<pitti> I have to leave for about an hour, and can't do much anyway while the u-n dist-upgrade is running. BBL
<seb128> Mirv: not a bug then?
<Mirv> seb128: well, a bug somewhere.
<seb128> the upstream german translation is bugged then?
<Mirv> seb128: yes, and the upstream didn't have many translations last Autumn, while in Rosetta there would have been many more new translation as the desktop files were translatable there
<seb128> there should still be
<seb128> the gaim package didn't change for a while now
<Mirv> but it seems like they have disappeared from Rosetta, and in new installations it shows as missing menu entry translations
<Mirv> all the other menu entries besides Gaim are unaffected
<seb128> Mirv: maybe some german translator changed the gaim translation on rosetta
<bddebian> Hello folks
<seb128> hi bddebian
<Mirv> seb128: yes, that's the point.. probably German .desktop-file translation was also improved in Rosetta (to be actually in German), but now it has disappeared and the old upstream .desktop file is there instead
<seb128> Mirv: I doubt that the gaim template has changed, if the .desktop was translatable on rosetta it should still be
<Mirv> and for Finnish there is no translation at all now in the .desktop file, even though the two .desktop strings were translated in Rosetta much earlier this spring 
<Mirv> seb128: I checked out de.po from Rosetta and there are no string called "Gaim Internet Messenger" or anything related to the .desktop files. there were earlier.
<bddebian> Hello seb128
<bddebian> doko_: ping by any chance?
<seb128> Mirv: right, I'll fix that but after dapper now
<Mirv> seb128: yes, I understand, I just wanted to make the issue understood :)
<Mirv> thanks
<seb128> np
<seb128> that's still weird you say it was listed
<seb128> there is no reason for the template to change
<seb128> carlos: around?
<bddebian> pitti: ping?
<Mirv> I have somehow accustomed to weird things happening in Rosetta
<seb128> you should not
<seb128> if there is some bug there should be pointed and fixed
<seb128> you should not get accustomed to bugs and ignore them :/
<bddebian> Why not, we do it with Windows all the time? ;-)
<doko_> bddebian: not for work ...
<dholbach> pitti: pong
<bddebian> doko_: OK, sorry.  Can you grab me sometime if you get a sec?
* mvo takes a short break
<carlos> seb128: hi
<Mirv> carlos: as you can see from the discussion, seb128 probably wanted you to look why translations for the desktop files have seemingly disappeared from Rosetta templates and thus PO files, https://launchpad.net/distros/ubuntu/+source/gaim/+bug/47669
<Ubugtu> Malone bug 47669 in gaim "Menu entry has lost its translation in at least Finnish" [Normal,Confirmed]  
<Mirv> carlos: I mean, for Gaim, not others
<seb128> carlos: right, do you know when the gaim template changed previous time and what changed?
<carlos> seb128: let me check...
<carlos> seb128: POT-Creation-Date: 2006-05-17 14:49+0000
<seb128> carlos: is the pot update at every package upload even if there is no change?
<seb128> updated
<carlos> seb128: and last .po file uploaded from Ubuntu's archive was also on that date
<carlos> seb128: yes
<seb128> k
<seb128> do you have an history on the .pots for it?
<seb128> not the dates but the content
<carlos> seb128: yes, but outside Rosetta
<carlos> seb128: rookery
<carlos> at ~lamont/public_html/translations
<seb128> carlos: ok, thank you
<carlos> np
<Keybuk> *blink*
<Keybuk> I've entirely forgotten what tests I'm doing
<ogra> lol
<ogra> but i bet youu can type your name blind backwards
<sfllaw> wallsf.
<sfllaw> Damn.
<Keybuk> ogra: nope, never tried
<ogra> Keybuk, dont you use your name in the installer ? 
<mdz> is someone doing a desktop CD install on amd64? pitti?
<Keybuk> ogra: no, I just use dapper/dapper
<ogra> heh
<infinity> I was just about to ask someone to take my desktop/amd64 tasks.
<pitti> dholbach: unping
<pitti> bddebian: pong
<pitti> mdz: yes, I'm doing the full set of amd64 and ppc installs
<infinity> pitti: \o/  Thanks.
<mdz> Riddell: have you begun testing the current Kubuntu candidates?
<infinity> pitti: Will you have time to do all the amd64/desktop tests, or do you want me to try to take some?
<pitti> infinity: I'm fine with doing them all
<infinity> pitti: You rule.
<pitti> infinity: I only have 2 left anyway (auto-resize and manual), all the other amd64 alternate and desktop possibilities are done (also dist-upgrade)
<pitti> and I'm going to continue right now, brb
<jdub> does anyone have firefox just halt on them sometimes? no heavy cpu usage, it just stops, but comes back in a while
<jsgotangco> yeah
<jsgotangco> actually my cursor stops
<jsgotangco> (it doesn't happen in epi though)
<Riddell> mdz: yes, wiki page updated
<mdz> Riddell: thanks
<highvoltage> mdz: feeling better?
<nomed> hi all
<nomed> janimo: ping
<nomed> could u confirm bug #46571 is gone ?
<Ubugtu> Malone bug 46571 in xfce4 "xfce4 doesnt shut down properly" [Normal,Confirmed]  http://launchpad.net/bugs/46571
<mdz> highvoltage: alive
<highvoltage> mdz: hope you feel like mdz again by tomorrow, you'll need to be ready for some partying :)
<mdz> cmvo: thanks for recording your test results
<bgertzfield> mvo: morning!
<wasabi> Heh. We totally need a SDCE test... Supreme Dictator Certified Engineer.
<janimo> nomed: hi, that bug is not gone
<iwj> mdz: The reason I didn't give any detail about the way it broke when I upgraded KDE is that this is apparently a known feature of KDE.
<janimo> will be gone by edgy hopefully :)
<nomed> janimo: ok .. i do not understand why i do not see it :/
<janimo> nomed, are you using gdm?
<iwj> jdub: I've not really seen anything very much like that but I wouldn't be surprised if there are a few places where it takes out an overly big lock.
<nomed> sure
<iwj> jsgotangco: Mouse freeze is something different (swapping, probably).
<janimo> nomed, so when you restart from the logout dialog, are you not dropped after X stops to a tty which looks like it's asking you to log in?
<nomed> no
<janimo> do you see the system shutting down messages without switching console?
<nomed> yes
<janimo> you are lucky then :)
<janimo> I don;t know why but here those happen on vt7
<Keybuk> Ubuntu i386 Alternate OEM Resize in Xhosa PASS
<Keybuk> (aha!  bet nobody thought of testing _that_)
<iwj> You can read Xhosa ?
<sivang> heh
* sivang burns the install cd
<sivang> (desktop)
<sivang> is there a time when the releases it planned to go out?
<ogra> Kamion, can i have proper names for the edubuntu isos on my download html pages for release ? (edubuntu install says alternate in the header)
<Keybuk> iwj: I know my way around the installer well enough that I don't _need_ to
<Keybuk> and hda1 is hda1 in every language ;)
<iwj> True :-).
<iwj> A month or two ago I was running firefox in a locale where I didn't even know what the code meant.  Navigating through the preferences to test the fonts (which is what I was trying to do) was slightly tricky but not impossible.
<pitti> iwj: I'm regularly lost when I test new m-firefox-l-all languages :)
<cmvo> mdz: You're welcome. Installed server and expert/manual partion today, I'm about to add those.
<doko_> sfllaw: testing both i386/amd64 WinFOSS DVD images
<sfllaw> doko_: Thanks.
<bddebian> pitti: Still here?
<Kamion> ogra: I should be able to fix that, yes
<Kamion> Riddell: help, I just did a zh_CN Kubuntu install on powerpc, and now skim segfaults when the desktop is starting up and I don't get a working desktop
<ogra> Kamion, that'd be great, my doc guys are already confused what to write :)
<Kamion> Riddell: what do you need to ebug this?
<Kamion> er, debug
<Kamion> ogra: it's just a minor bug that it says "alternate" there, the explanatory text below it is how it's meant to be
<ogra> yep
<pitti> bddebian: yes
<mdz> mvo: have you seen any further reports of that upgrader segfault?
<mvo> mdz: no, nothing so far. maybe a heisenbug
<bddebian> pitti: Do we care about bug #45887
<Ubugtu> Malone bug 45887 in dokuwiki "Security update needed for all versions prior to 2006 March 9th" [Normal,Unconfirmed]  http://launchpad.net/bugs/45887
<mvo> mdz: but I have to do a (final) upload with the updated release-notes, updated translations and a one-line fix in the checkFreeSpace code - I'm preparing this now
<zyga> hello hackers :)
<mvo> mdz: is that ok?
* mvo waves to zyga
<bddebian> Hello zyga (Even thought I am not a "hacker") :-)
<zyga> mvo: cound you use my help in any way?
<Kamion> mvo: erm, upload to where?
<Kamion> dapper is officially frozen in LP
<Riddell> Kamion: is there a backtrace?  does it start up on second login?
<mdz> mvo: debdiff?
<Kamion> Riddell: where would the backtrace land? the message is in Chinese so unfortunately I cannot read it
<mvo> Kamion: hm, if dapper-updates can deal with uploads of the upgrader I can use this
* iwj waits for the install again.  This is a new (well, 9 months) fast machine but it's still slow.
<mdz> mvo: Kamion has a point; can we actually update the upgrader via -updates?
<Kamion> and I'm not familiar enough with the interface to cope with it in any language
<mdz> mvo: now is perhaps not the time to test that
<mvo> mdz: sure, I'm preparing it
<Kamion> mdz: we would need to check with cprov on that; the d-i handling code at one point did not deal with pockets
<mdz> mvo: I suggest working with cprov to test it on staging
<Kamion> mdz: or Kinnison would probably know too
<mvo> mdz: ok - the only important bit are the releae notes, but they can be fetched from any http location, we can work around this and do with the current version (if required)
<Riddell> Kamion: does the kde crash handler pop up?
<Kamion> Riddell: yeah
<Riddell> should be in the second tab of that
<Riddell> actaully you would need to install gdb to get it
<Riddell> I'll try a chinese install
<Kamion> Riddell: oh, err - it broke on second login too (after ctrl-alt-backspace), but I just tried logging in again and it now works with no crash
<Kamion> yay heisenbugs :-/
<pitti> bddebian: well, if someone comes along and does it, fine for me :)
<Kamion> Riddell: where  an I file bugs on the Kubuntu release notes?
<bddebian> pitti: Well I would, but we are closed up shop...gah
<Kamion> or is anyone from the doc team here that could have a look? they have some serious problems
<bddebian> pitti: I would do it but uploads are frozen now aren't they?
<Riddell> Kamion: KubuntuDapperKnownProblems
<iwj> mdz, riddell: More info in DapperReleaseNotes/Kubuntu/UpgradeProblems
<iwj> But I have to go catch a train.  I'll be back in some hours (see mail to warthogs).
<pitti> bddebian: they can go into d-security
* dholbach gets himself some tea... 
* ogra proposes to rename "expert" to "baby" this install variant is so demanding ...
<mdz> iwj: have you completed any of your other test cases?
<pitti> yay, grepping for my password yielded no result :)
<ogra> heh
<Kamion> Riddell: thanks, I've added a comment there
<Keybuk> Riddell: so, err, I'm being thick
<Keybuk> Riddell: adept doesn't seem to want to upgrade using a cd
<Riddell> Keybuk: you're not being thick, it doesn't have that option unless you run apt-cdrom first
<LaserJock> Kamion: does it say on the Kubuntu release notes who wrote it?
<LaserJock> Kamion: nvm, found the svn log
<mvo> can some native speaker please have a look over http://people.ubuntu.com/~mvo/bzr/update-manager/update-manager--dapper/DistUpgrade/ReleaseAnnouncement ? this is what the user sees before the dist-upgrade
<seb128> mvo: is there a way to translate that? :)
<LaserJock> mvo: that second paragraph sound like Edubuntu
<LaserJock> mvo: i.e. "Ubuntu is a Linux distribution aimed for educators to easily deploy
<LaserJock> and maintain a learning environment"
<ogra> yeah, who made that up ?
<mvo> seb128: not for dapper unfortunately :/ 
<mvo> LaserJock: thanks, I took that from the DapperReleaseNotes in the wiki. I'll remove it again
<ogra> mvo, i think they gopt copied from a template jsgotangco made for edubuntu :)
<janimo> ogra, where's the link to edubuntu release notes?
<doko_> Kamion: please see bug 47725
<Ubugtu> Malone bug 47725 in oem-config "timezone dialog pops up (no content), then the login screen appears" [Normal,Unconfirmed]  http://launchpad.net/bugs/47725
<mvo> ogra: fixed now, thanks
<pitti> doko_: that's merely cosmetical for German; it works fine for English
<ogra> janimo, https://wiki.edubuntu.org/EdubuntuDapperReleaseAnnouncement (we didnt use that template btw)
<janimo> ogra, thanls
<pitti> doko_: in Germany we only have one TZ, so it has nothing to ask :)
<fabbione> Riddell: ping? i just got kde-media-notifier window popup on ubiquity ppc
<fabbione> Riddell: what do you want me to look?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Dapper frozen | TEST TEST TEST!
<LaserJock> mvo: reads nicely
<doko_> pitti: hmm, ok, but what do you do when installing in the UK?
<pitti> doko_: then you should choose UK as country :)
<Riddell> fabbione: just plain ppc?  not in a vmware like thing?
<pitti> doko_: I did an install with country == USA and one for Russia, and there it asked me for the TZ 
<fabbione> Riddell: plain ppc
<doko_> pitti: we only have language and keyboard, not country, so I cannot install my laptop to work in the UK ;-P corner case, but I think that's over-optimized
<fabbione> Riddell: is there anything you need otherwise i will keep going with the install test
<Kamion> doko_: oem-config is known-to-be-crap in dapper. sorry - I just didn't have time to fix it up
<pitti> doko_: strange, I was asked for both language and country in the 1st dialog, and keyboard in the 2nd
<Riddell> fabbione: what disk is it reporting?
<Kamion> I appreciate the bug reports but I do not think it is sensible to worry about them as dapper showstoppers
<Riddell> fabbione: and whats the contents of media:/ in konqueror
<pitti> doko_: well, for me it doesn't actually *respect* the keyboard setting, but it asks :) (I filed a bug)
<Kamion> doko_: it's not deliberate optimisation, it's a side-effect of moving to tzsetup as part of d-i reorgs
<Kamion> and yes it should be fixed, but it's not exactly a one-liner
<doko_> Kamion: yes, it's German only, so not rc. just reporting
<fabbione> Riddell: media:/ has 37G Media (the hd) and other stuff.. the prompt is about the 37G Media (hd repartioned basically)
<Kamion> tbh it would take a lot to persuade me that any oem-config failure is RC
<Riddell> fabbione: ok, thanks, that's fine
<fabbione> Riddell: no problem
<Kamion> simply because it has had about one day of development time allotted to it in dapper; anything else it's got has been sneaked in the side
<pitti> Kamion: for that it worked surprisingly well :)
* doko_ watches with horror that a left USB stick gets a lower SCSI ID than the 3ware controller; the installer message "installing GRUB on the first HD (without saying it)" becomes a new meaning :-/
<bddebian> heh
<lastnode> silbs, ping?
<\sh_away> Ladies, Gentlemen, I wish you good luck this night for the release of Dapper Drake aka Ubuntu 6.06 LTS...I will go now and celebrate the release already ;) all the best, good luck, Ubuntu :)
<bddebian> w000t, later \sh_away!
<HiddenWolf> bgertzfield: dapper doesn't have a "system tools" menu by default, you might want to consider putting vmware's .desktop in accessories like the terminal.
<tritium> sivang: you have a T43p, correct?  Did you compile your own 2.6.16 kernel to get around the SATA-to-PATA bridge problems with the drive, particularly on resume from suspend?
* doko_ curses the new fglrx driver making it completely unusable on 92xx cards ...
<mjg59> What bridge problems with the drive?
<Keybuk> since when does one need a SATA/PATA bridge?
<pitti> yay, all amd64 and ppc desktop/alternate/dist-upgrade tests succeeded
<pitti> wearning my ubuntu t-shirt today must have helped a lot :)
<pitti> wearing, even
<infinity> pitti: Laugh.  Yeah, it was totally the t-shirt. :)
<infinity> s/Laugh./*laugh*/
<mdz> janimo: are you happy with your CD images?
<janimo> mdz, yes
<janimo> the 386 ones got tested only but hope the others are fine too
* highvoltage will buy more hardware in the next few months specifically for testing... just owning i386 hardware is boring
<janimo> highvoltage: got around to seeing if ltsp clients boot off the installed xubuntu server?
<highvoltage> janimo: nope. didn't have another machine present, although, the services is starting correctly
<janimo> highvoltage: yeah I have another machine here but does not know pxe apparently
<highvoltage> and there were no error messages, I can assume that it would work, although I still can't say 100% for sure. it does seem fine though
<janimo> so I could not test it either
<highvoltage> janimo: you can download a etherboot boot image with PXE emulation at http://rom-o-matic.net
<janimo> highvoltage: ok the wording in the announcement remains then ' can easily install an ltsp server'
<highvoltage> then you can boot from floppy / CD / grub to network
<janimo> will not go into the details weather thin clients can connect to it :)
<janimo> no spoilers in the release announcements!
<highvoltage> janimo: well, i have a spare PC, so I can install and test now, if you want to be sure for the purposes of accurate announcement
<ogra> janimo, https://wiki.edubuntu.org/EdubuntuDocumentation/BootingClientsWithoutPxe :)
<highvoltage> i can then tell you in +/- 45 mins?
<janimo> highvoltage: I thought of pxe for that machine since it has broken floppy/CD :)
<highvoltage> (have to burn cd first, etc)
<Keybuk> Riddell: kde upgrade went VERY badly wrong
<highvoltage> heh
<janimo> highvoltage: no hurry, but thanks :)
<Keybuk> like, the desktop actually crashed afterwards
<infinity> Keybuk: Yeah, that matched iwj's experience too.
<infinity> Keybuk: Segfault-o-rama and reset switch to complete the upgrade.
<janimo> highvoltage: you still intend to deploy real xubuntu ltsps?
<Keybuk> infinity: this was after the reset switch
<infinity> Keybuk: Oh, special..
<Keybuk> ah, no, it was just after I pushed "reboot" _in_ KDE
<Keybuk> I assumed it had rebooted
<highvoltage> janimo: well, that's a tough question, but we intend to use xubuntu desktop environment for sure
<infinity> Seveas: Hey, slacker, you've not subscribed your feed mangler to edgy-changes yet. :)
<Seveas> infinity, is edgy changes alive?
<janimo> highvoltage: so if not via this methid then over edubuntu?
<infinity> Seveas: https://lists.ubuntu.com/mailman/listinfo/edgy-changes
<highvoltage> janimo: we have lots of pressure on us for local device access, and things like network swap need to work. so we might have to use ltsp.org for another 6 months, something i'm not keen on...
<Seveas> infinity, note that the feed won't work until the first mail is sent
<janimo> ogra: is pxe entirely network card dependent, nothing to do with the system bios?
<Seveas> I should do something about that
<Seveas> but NOT NOW - report deadline in 3:55
<infinity> Seveas: No big deal if liferea whines about a broken feed until it magically starts working.
<janimo> highvoltage: aha, work for ogra for edgy ;)
<highvoltage> janimo: we're definetly using XFCE though, we don't have much of a choice in terms of our older server's capacities... let's move this to #edubuntu or #xubuntu
<ogra> janimo, thats top on my todo :)
<janimo> highvoltage: ok, that's enough details for now, was just curious. But if you have any xfce questions/requests ping/mail me
<ogra> pxe is card dependent but indeed you have the settings for it incorporated in the BIOS...
<Kamion> ogra: fixed the Edubuntu install CD description for you for the final publish
<ogra> thanks :)
<Kamion> (although not in the current daily HEADER.html)
<ogra> thats ok
<Kamion> it's just s/alternate install CD/install CD?
<Kamion> it's just s/alternate install CD/install CD/
<janimo> Kamion, xubuntu remains on cdimage only?
<Kamion> (ahem)
<ogra> yep
<highvoltage> janimo: thanks :)
<Kamion> janimo: yes, releases would overflow if we added xubuntu I'm afraid
<AlinuxOS> reinstalled Dapper, standart mode, everything is ok. no problem for me. Great!
<Kamion> there are physical restrictions on how much disk can fit on those machines in the datacentre with the recent networking upgrades
<Kamion> I didn't ask for details but I believe elmo
<janimo> Kamion: np with that at all, it's  just so I write the url's correctly in the ann
<Kamion> right
<highvoltage> disk space is cheap!
<Kamion> highvoltage: not when it won't fit in the machines :P
<elmo> highvoltage: high end SCSI disk across multiple machines isn't cheap.  if you think otherwise, you know where to send your cheque to
<highvoltage> elmo: I'll trust you on that
<highvoltage> elmo: if i may ask, how much disk space is needed?
<ogra> highvoltage, dont forget the mirrors will have to cope with it too
<Tonio_> mdz: may I send you the debdiff for kubuntu-default-settings reguarding the Real streaming and audio streaming issues ? (for dapper-updates upload)
<mdz> Tonio_: sure
<mdz> Tonio_: I won't be around too much longer, though; I'll be going back to bed I think
<mdz> Tonio_: (i.e., email rather than IRC would be best)
<ogra> mdz, get well
<Tonio_> mdz: sure
<Tonio_> mdz: should be sent
<Gloubiboulga> janimo, around?
<janimo> Gloubiboulga: yes
<janimo> I hope you did not find a bug
<Gloubiboulga> janimo, xfce4-menueditor has erased my menu
<janimo> oh, ok :)
<Gloubiboulga> is it a known bug ?
<janimo> started it from command line?
<Gloubiboulga> yep
<janimo> menueditor is not too fucntional
<Gloubiboulga> I see :)
<janimo> i fyou start it from the menu it wants to edit system wide menu
<crimsun> that's cool, just caution in the release notes making a backup prior to using it :-)
<janimo> otherwise it seems to do this
<ReMink> Hi !
<janimo> I did not get it to eat my menu so far, just segfaulted
<Gloubiboulga> it segfaulted the first time I launched it, and erased the menu the second time
<janimo> Gloubiboulga: so you already had a menu on your ~/,config ?
<Gloubiboulga> a third time will regenerate the menu maybe ? :)
<janimo> or erased meaning it does not show up?
<Gloubiboulga> the default menu, I've never edited it
<janimo> oh, that cannot be erased it's in /etc
<janimo> no permissions
<Gloubiboulga> I have the "application" icon, but cliking on it doesn't open a menu
<janimo> but xfce4-menueditor creates a 0 length menu file before segfaulting
<janimo> so the menu picks that and it's empty
<janimo> I just discovered this the other day
<Gloubiboulga> ok, so if I remove it, the default menu will show up ?
<janimo> to un-eat the menu go to it's properties menu then close the dialog
<janimo> I think so
* janimo tries again
<highvoltage> janimo: can that be fixed in -updates?
<janimo> highvoltage: I filed a bug upstream so depending on what goes in updates it coudl be fixed
<janimo> so it does not erase the menu or any data, it's just annoying in not using it until told to reread it
<highvoltage> yep
<Seveas> infinity, http://www.ubuntulinux.nl/files/edgy.xml
<infinity> Seveas: Was already subscribed an hour ago. :)
<Seveas> infinity, (with attached note that ubuntulinux.nl will be down from 16:00-ish tomorrow until 12:00-ish friday)
<infinity> Seveas: Thanks.
<Seveas> infinity, but it works since about a minute or so ;)
<infinity> Seveas: You deleted warty?
<infinity> I guess it /is/ dead now.. *shrug*
<Seveas> yes
* infinity removes it from liferea.
<janimo> Gloubiboulga: yes if you remove it the old one should show up after the properties dialog dance
<janimo> hmm things are still uploaded to dapper?
<highvoltage> warty will live forever in our hearts and souls
<janimo> oh dapper-updates alreday
<crimsun> highvoltage: it's totally living through this dist-upgrade series...
<janimo> is there a policy written on what can go in dapper-updates?
<bigcx2> hey all
<Seveas> highvoltage, very true
<janimo> the ones I just saw are regular bugfixes
<bigcx2> i would like a package in debian unstable to go into ubuntu....
* highvoltage remembers the first time a colluege brought me a cd he downloaded a cd from 'no-name-yet.com' and said i should try it. i asked him what it's called and he said 'its from the warthogs, you'll like it'. *goosebumps*
<bigcx2> would the best way to go about getting it into ubuntu to become a motu?
<crimsun> bigcx2: if it's already in sid, it'll be synced into edgy automatically.
<crimsun> bigcx2: if you'd like to help maintain it, of course, then yes, -motu is the route
<bigcx2> fair enough...well what about dapper
<bigcx2> the package that i'm interested in is ikiwiki
<bigcx2> btw
<crimsun> dapper's frozen, release is < 24 hours away. There's no possibility.
<bigcx2> k
<ogra> sure there is ...
<bigcx2> i wasn't sure if i could get it in after the release
<ogra> get it into edgy and ask for a backport ;)
<crimsun> ogra: ok, fine you win, but that would be -backports. :-)
<ogra> indeed :)
<bigcx2> k so how would one go about that?
<elmo> build/buildd/pointless-0.5/debian/pointless/usr/share/pointless/README universe/misc/pointless
<elmo> build/buildd/python-4suite-0.99cvs20050418/4Suite/build/share/Dashboard/4ss-netscape.css universe/python/python2.4-4suite
<elmo> someone might want to sort out that package
<elmo> python2.4-4suite confirmed at least, haven't check pointless
<mdke> Znarl: ping?
<Znarl> mdke : Hello.
<mdke> Znarl: hi! query...
<bigcx2> anyone?
<janimo> bigcx2: #ubuntu-motu is the best place to ask
<bigcx2> alright thanks
* janimo realizes he did not visit #u-m in months maybe
<elmo> remem.el                                                    universe/misc/remembrance-agent
<elmo> crystalsvg/32x32/apps/siraj.png                             universe/kde/kbfx
<elmo> debian/gtk-engines-mist/usr/share/themes/Mist/gtk/gtkrc     universe/x11/gtk-engines-mist
<elmo> ^-- those too, not checked
<infinity> elmo: Ouch.
<Kamion> right, warty and hoary moved from releases.u.c to cdimage.u.c/old-releases/
<Riddell> elmo: what's up with those files?
<Kamion> Riddell: those paths are relative to/
<Kamion> to /
<elmo> Riddell: ... I'm pretty sure /crystalsvg isn't in the FHS
<Keybuk> but /remem.pl should be
<Riddell> investigating
<Keybuk>     __                                       _
<Keybuk>    / / __ ___ _ __ ___   ___ _ __ ___    ___| |
<Keybuk>   / / '__/ _ \ '_ ` _ \ / _ \ '_ ` _ \  / _ \ |
<Keybuk>  / /| | |  __/ | | | | |  __/ | | | | ||  __/ |
<Keybuk> /_/ |_|  \___|_| |_| |_|\___|_| |_| |_(_)___|_|
<Kamion> it's been a long releases
<Keybuk> (wow, zsh can tab complete figlet font names ... that rocks!)
<Seveas> (there is a bug open op python-4suite for this too)
<Seveas> Keybuk, bash can do that too ;)
<Keybuk> Seveas: comparing bash to zsh is like comparing a Honda Civic to a McLaren Mercedes SLR 55
<Keybuk> you, just, don't
<Seveas> heh
<_ion> keybuk: Indeed. :-)
* mdke chooses the civic
<mdke> (hoping for some more custard)
<Keybuk> mdke: what is it with you and custard?
<mdke> i just like it. All english people do, surely
<dieman> hrm
<dieman> odd
<dieman> the alternate installer doesn't like the example-preseed.txt file
<Keybuk> mdke: I don;t
<Keybuk> can't stand the stuff
<mdke> Keybuk: you must be forrin
<highvoltage> janimo: i have a serious problem with my xubuntu installation. gdm keeps restarting over and over and over :(
<Keybuk> mdke: nope, English
<janimo> oh, the ltso one?
<mdke> Keybuk: well... I know you're English
<janimo> highvoltage: ltsp I mean?
<highvoltage> janimo: the one on the server, i'm about to start up a thin client now (actually this laptop i'm working on, so i'll brb)
<highvoltage> janimo: i chose the ltsp installation option, yes. but this is happening on the server.
<janimo> highvoltage: oh, maybe gdm should not be installed since ldm is the one supposed to be started
<janimo> xubuntu-desktop has gdm and ltsp adds ldm to it
<highvoltage> janimo: ldm should start on the thin clients, gdm should start on the server
<janimo> highvoltage: oh, maybe ogra knows ?
<janimo> I have no idea what it can be.
<highvoltage> i don't know, brb.
<Kamion> dieman: that's probably an oops, please file it on installation-guide
<Kamion> (reckoning that chances are it's the documentation that's wrong)
<dieman> it seems to be horking on multiline entries
<dieman> but im testing that right now
<highvoltage> janimo: *sigh* the thin client doesn't boot. it drops me into busybox after failing to mount the nfs share: Permission Denied
<janimo> highvoltage: hmm, sorry. No idea what it can be  then :(
<janimo> highvoltage: is gdm supposed to start at all on the server?
<highvoltage> janimo: yes
<highvoltage> janimo: ltsp-client and ltsp-client-setup is installed on the server, as far as I know, it's not supposed to be
<highvoltage> janimo: as much as I hate to say this, you might have to remove the LTSP install option, if at all possible.
<janimo> highvoltage: oh, are those _not_ supposed to be on the server?
<highvoltage> oh no
<highvoltage> janimo: it's not gdm that keeps restarting on the server, it's LDM that keeps restarting on the server :(
<highvoltage> janimo: ldm isn't supposed to be there either, it's just supposed to go into the ltsp chroot
<highvoltage> janimo: no, they're supposed to be installed in the ltsp chroot
<highvoltage> the server machine is basically configured as a client and a server at the same time. :/
<janimo> highvoltage: I got the impression that those need to be installed
<janimo> so on the server we should have ltsp-server-standalone installed
<highvoltage> janimo: we can hear for sure from ogra, but I am quite convinced that ldm should definitely not be installed on the server's system
<janimo> but have ldm and ltsp-client on the CD nit not installed?
<highvoltage> ldm and ltsp-client should be installed, but only in the installation in /opt/ltsp/<arch>
<highvoltage> not /
<janimo> highvoltage: it was bug 41322 that describes what I asked for that CD option
<Ubugtu> Malone bug 41322 in gfxboot-theme-ubuntu "add LTSP server option for xubuntu install CD" [Normal,Unconfirmed]  http://launchpad.net/bugs/41322
* highvoltage looks
<janimo> hmm, I wonder why I filed it on gfxboot
<janimo> oh, that's just a new bug for getting it translated, I see
<janimo> highvoltage: so from what you say, ltsp-client and ldm should have been ommitted from the install right?
<bddebian> Stupid sleaze-bay
<highvoltage> janimo: for the server part, yes. but on the client installation (the chroot, /opt/ltsp/i386), it should be installed
<janimo> highvoltage: so if you connect to this server and unintstall ldm and ltsp-client and reboot should it work in theory?
<highvoltage> janimo: for ltsp, you get two installtions on the server: the usual ubuntu one in /, and the one the thin clients boot from /opt/ltsp/<arch>
<janimo> highvoltage: so ldm and ltsp-client still need to be apt-get installed at some point?
<highvoltage> janimo: i think so, i can test now...
<janimo> highvoltage: the other one happens in a chroot right?
<cbx33> janimo, they live in the chrrot don;t they highvoltage ?
<janimo> but still can use (uses?) the packages on the CD
<highvoltage> janimo: yes, the ldm and ltsp-client packages needs to be installed in the 'building chroot' part
<cbx33> well, we hope they don't live in a ch rot :p
<highvoltage> janimo: yes, it must use the packages from the CD, so the bug was right that the packages should be on the cd
<highvoltage> janimo: but it didn't mention where these packages should be installed. ltsp-server-standalone should be installed to the main system
<highvoltage> and the rest to the chroot
<bgertzfield> HiddenWolf: Thanks for the suggestion (Accessories instead of System Tools).  I used System Tools because that's where the standalone VMware Player will install itself on non-Ubuntu systems.  I think it makes sense to use the same place (whether or not there are a lot of other Ubuntu packages that go there).
<janimo> it may have been a misunderstanding on the bug as to what is installed and what is only on the CD (ship seed)
<HiddenWolf> bgertzfield: your call. ;)
<janimo> highvoltage: is openssh-server required too? on theserver
<cbx33> janimo, i believe so
<janimo> so would  making the CD option install just the two of the 4 packages be better?
<dholbach> janimo: so where's the release party in romania?
<highvoltage> janimo: yes, it is. the thin clients uses ssh -X to get the desktop from the server
<janimo> highvoltage: if you could confirm that uninstalling ldm and ltsp-client from the server improved the situation we may still fix it
<cbx33> dholbach, is there on in the UK?
<janimo> dholbach: I saw a mail on ubunto-ro proposing one in the capital city
<janimo> but nothing else
<dholbach> cbx33: I do one in Berlin :-)
<dholbach> http://wiki.ubuntu.com/DapperReleaseParties
<janimo> dholbach: I know no ubuntu fan in the area
<dholbach> janimo: that should be changed :-)
<janimo> apparently people are immune to me distributing CDs to them
<tseng> hah
<dieman> heh
<tseng> are there pressed xubuntu cds for dapper?
<dieman> we've got an installfest here this weekend :)
<dieman> i might show up
<janimo> tseng: nope
<infinity> Someone needs t ocome party with me in Melbourne on release day.
<janimo> I dist ubuntu/kubuntu
* highvoltage needs to reboot again, brb
* janimo crosses fingers for highvoltage
* cbx33 distributed 25 cd's in 3 days :D
<bgertzfield> infinity: Go to bed!  ;)
<bgertzfield> infinity: I had a bunch of folks download the vmware-player and give it a go.  Got some good feedback, no showstoppers.
<bgertzfield> Thanks again for all your help.
<infinity> bgertzfield: No bed for me.  Need to set up dapper-security and other fun things.
* cbx33 hands infinity a gold star
<cbx33> highvoltage2, how goes it ?
<bgertzfield> infinity: ...
<highvoltage2> janimo: I can confirm that the thin client does boot up when those services are uninstalled
<janimo> highvoltage2: good
<janimo> let's see if it's too late to change the boot option
<infinity> bgertzfield: No rest for the wicked, I'm afraid.  The release may be almost over, but that just means we get to think about all the things post-release. :)
<bgertzfield> infinity: And thus the dance begins again.
<janimo> Kamion: is it too late for a xubuntu alternate rebuild? there was a misunderstanding around bug 41322 
<Ubugtu> Malone bug 41322 in gfxboot-theme-ubuntu "add LTSP server option for xubuntu install CD" [Normal,Unconfirmed]  http://launchpad.net/bugs/41322
<janimo> two of the 4 packages do not have to be installed or the ltsp server will not serve
<janimo> this requires no upload but the modification of that entry to only inlcude ltsp-server-standalone and  openssh-server
<janimo> as seen in the scrollback
<infinity> janimo: How's Xubuntu look other than that?  You generally happy with your release?
<janimo> infinity: yes, besides a little cosmetic issue
<infinity> janimo: (Not that you have much choice at this point, but it's a learning process... You'll get better at dealing with the deadlines and release crunch)
<highvoltage> janimo: there are still some issues, although not critical. for example, the ltspenvironment shows ubuntu usplash, and a user from thin client can shut down the server
<janimo> mixer icon is actually the office icon (I like it better than the actual mixer icon btw)
<janimo> infinity: yup, sure I have vowed that for edgy I'll actually stick to a schedule ;)
<janimo> highvoltage: the user can shutdwon server may be solved by using xfce's kiosk features
<highvoltage> janimo: great.
<janimo> highvoltage: so does this make xubuntu/ltsp install really easier? is it much different from a xubuntu workstation then apt-get install ltsp-server?
<janimo> I think the advantage is that it is on the CD so it can install disconnected, but does not seem to go much further as out-of-the-boxness is concerned
<dholbach> WTF?! I thought in edgy we wouldn't have a release schedule :-p
<sladen> highvoltage: that's going to be related to the libforeground checking
<highvoltage> janimo: this will basically be the same as an apt-get install ltsp-standalone-server on xubuntu. but users like a 'one button install'
<janimo> dholbach: xubuntu should have one. Dapper is warty for xubuntu. So edgy will have to be the dapper
<janimo> highvoltage: yup, agree with the one button install as well
<highvoltage> sladen: i understand. xubuntu can show ubuntu usplash until next release. i don't think it's a trainsmash :)
<dholbach> janimo: then you're quicker then the rest around you  :-)
<lotusleaf> I've got a fever... and the only thing that can cure it is DAPPER!
<dholbach> give this man his medicine! ^ :-)
<infinity> dholbach: My edgy release schedule will be "upload as much crap as I possibly can in the first two months, triage bugs for two months, take a 3-week vacation"
<janimo> infinity: only Kamion is spinning alternate CDs?
* cbx33 inserts a dapper iso into lotusleaf's mouth
<dholbach> infinity: that sounds like a perfect plan
<lotusleaf> cbx33: keep it coming
* cbx33 is working on his first package for edgy :D
<lotusleaf> cbx33: i need a steady drip
* cbx33 sets up an IV with some iso goodness
<infinity> janimo: Several of us can build them, but I'd want confirmation from him that it's still "okay" to respin Xubuntu.
<cbx33> all for one and one for all :p
<janimo> infinity: sure
<infinity> janimo: Given that you're not going to be published on releases.u.c (which means you won't be mirrored by quite as many people), the damage done by respinnig your CDs might not be too bad.
<infinity> janimo: We can't respin anyone on releases, cause releases is being mirrors all over the damn place right now.
<janimo> was not trying to circumvent him, just planning my sleep cycle  in case he does not appear in an hour :
<janimo> ;)
<infinity> (pre-publishing)
<infinity> s/being mirrors/being mirrored/
* janimo is glad xubuntu is not on releases.u.c
<janimo> and that scsi disks across machines are expensive
<lotusleaf> happy dapper eve!
<msikma> When will Dapper officially be released?
<AlinuxOS> lotusleaf, ;)
<AlinuxOS> hehe
<AlinuxOS> msikma, I hope in some hours
<Coyctecm> msikma: tomorrow?
<lotusleaf> msikma: /join #ubuntuforums where we wait in prayer
<ogra> janimo, highvoltage is right, ltsp-client and friends should never be installed on the server
<janimo> ogra, should have told me that two weeks ago ;)
<janimo> hope it still can be fixed
<ogra> janimo, i didnt know you would hanmdle it differnt from the edubuntu seeds
<ogra> ldm nad ltsp-client are only in ship
<janimo> ogra, yes there was a lot of confusion surrounding this issue
<janimo> in no small part due to the fact that I had no clue how ltsp really works
<janimo> now I have a faint clue
* netjoined: irc.freenode.net -> brown.freenode.net
<ogra> ltsp-server holds the scripts needed to setup and maintain ltsp and depends on the core services (nfs, tftp), ltsp-server-standalone is a metapackage that pulls in dhcpd additionally to these 
<ogra> ltsp-client has a very clear package description i think
* ogra is off for more ppc testing
<mdke> cbx33: ping?
<cbx33> pong
<cbx33> hi mdke what can i do ya for :p
<mdke> cbx33: query
<cbx33> shoot
<sfllaw> pitti: Ping?
<pitti> sfllaw: hello
<sfllaw> pitti: We're missing a DVD, d-i OEM for Ubuntu PowerPC test.  Could I ask you to do a run of that?
<sfllaw> fabbione doesn't seem to be  here.
<sfllaw> Pretty please?
<pitti> sfllaw: hm, sorry, it will take me 10 days to download it
<pitti> sfllaw: I have 3 GB/week quota here
<sfllaw> Ah.
<sfllaw> :(
<sfllaw> Pity.
<pitti> jigdo will help a little, but not quite enough
<sfllaw> Fair enough.
<sfllaw> I'll try to catch him when he wakes up.
<pitti> sfllaw: my bw sucks here, and once I move to another flat (in a few months, I hope), I'll watch out for a good dsl connection
<sfllaw> That would be good.
<sfllaw> Good DSL is a blessing.
<pitti> sfllaw: when I moved here, I didn't care that much; it was in my 3rd uni semester, and uni had enough bw for my purposes :)
<sfllaw> Heh.
<pitti> sfllaw: if it helps you in any way, CD OEM on ppc went smooth as silk
<AlinuxOS> pitti, 1&1
<pitti> AlinuxOS: ?
<AlinuxOS> internet provider.
<pitti> AlinuxOS: if you refer to the telecommunication provider: ENODSLHERE
<pitti> AlinuxOS: I'm hanging on a cascade of WLANs tied to 4 central SDSL lines, called 'citizen net'
<AlinuxOS> ah
<AlinuxOS> great...
<pitti> AlinuxOS: ~ 1000 people share these 4 big pipes, so they have to impose a quota
<AlinuxOS> so no need of phone.
<AlinuxOS> ah undertand :D
<pitti> AlinuxOS: the irony is that we have the world's most modern telephone network and not able to provide a fast internet connection through them to the end user
<AlinuxOS> pitti, TESTING TESTIN TESTING ?:)
<pitti> AlinuxOS: see https://wiki.ubuntu.com/Testing/Current, I did all I could :)
<AlinuxOS> pitti, yes + Telecom's 15 Euro
<pitti> If I see one more d-i today, I'll start crying
<AlinuxOS> :D
<AlinuxOS> I've tested 4-5 hours ago..
<AlinuxOS> no problems here :)
<infinity> pitti: Blue's not your favourite colour?
<pitti> infinity: stop confusing me any further
<pitti> infinity: if you refer to that ML thread, I didn't read it
<pitti> infinity: oh, I understand. nevermind :)
<pitti> (as it happens, blue *is* my favourite color :) )
<AlinuxOS> but, I really like Humans colord :)
<AlinuxOS> woddy/orange color :)
<infinity> pitti: Dude, have you completely lost your mind?  What thread? :)
<mdke> sounder thread
<pitti> infinity: https://lists.ubuntu.com/archives/sounder/2006-May/007069.html
<infinity> We're going to ADD a question to the installer for the sake of themeing?
<infinity> LIES.
<mdke> i find it unlikely
<infinity> Also, I rather like the brown.
<infinity> I'm totally down with the brown.
<mdke> but it may be one to add to the mass-rugby-tackle-sabdfl spec
<jdub> branding > installer questions!
<crimsun> sorry, but baby jebus is weeping here
<jdub> ha ha
<infinity> jdub: Whoah, where'd you come from?  Do you have "down with the brown" on nick hilight? :)
<mdke> lol
<jdub> crimsun: perhaps we should just say "BJC" in these kinds of circumstances
<jdub> crimsun: add it to the project lingo
<crimsun> mm yes
<jdub> <sabdfl> *crack*
<_ion> It would be a good idea to also add the question "would you like me to install an Atari ST emulator?" to the installer.
<iwj> mdz: (if you're still there)  Yes; I'm filling them in the table.
<jdub> <hackeurs> ... BJC
* jdub sucks down desktop daily at 160K/s
<thom> _ion: no dude, everyone wants ST love by default
<thom> even the amiga weenies who don't know that they do
<LaserJock> hmm what about "Would you like me to make you a latte while the install progresses?"
<jdub> we should just boot into hercules
<_ion> Well, the fact that Atari suxor and Amiga rules _was_ the joke in that line. ;-)
* _ion rubs his Amiga gently.
<infinity> thom: Hey, watch it, I'm an Amiga weenie.
<Burgwork> _ion, dude, there are more private places for that ;)
<mdke> ah, the pre release tension
<thom> infinity: i know :-)
<tritium> mjg59: I see you asked about the drive earlier.  Here are some details: http://linux.spiney.org/debian_gnu_linux_on_an_ibm_thinkpad_t43p_harddisk
<sladen> tritium: it turns out those bridges are buggy.  IBM have actually patched the firmware on the IDE drives they've shipped with the machines...
<sladen> tritium: I hit it today when I popped in another HDD to do some testing ...Bingo:  1020: Your harddrive does not have suitable firmware.  Please remove it.
<tritium> sladen: yeah, I've definitely noticed the bugginess.  I get bus errors on resume.
<tritium> wow
<sladen> tritium: http://www.thinkwiki.org/wiki/Problem_with_non-ThinkPad_hard_disks
<mdke> tritium: doesn't everyone have errors on resume?
<mdke> I'm full of em
<tritium> sladen: ooh, thanks.  I'll check.
<sladen> mdke: hope not.  what's your machine?
<tritium> mdke: this is the first machine I've seen bus errors on resume with
<mdke> sladen: a T43, without the p.
<sladen> mdke: and more to the point, what's the bug-number you filed?  ;-)
<mdke> sladen: I'll dig it out
<sladen> mdke: lucky you, me and tritium.  See the page above too
<mdke> sladen: with breezy I didn't have any errors
<sladen> mdke: that's called a regressions then.  All the more reason for filing a bug report!
<mdke> sladen: dude, stop insinuating I didn't file one ;)
<mdke> https://launchpad.net/distros/ubuntu/+source/linux-source/+bug/39449
<Ubugtu> Malone bug 39449 in linux-source "Error messages "over-current change on port 1"" [Normal,Unconfirmed]  
<fabbione> that's not a regression
<crimsun> that was in hoary and breezy.
<fabbione> the overcurrent message is in the USB specs
<fabbione> if you didn't get it before is because the kernel was not 100% compliant to the specs
<tritium> that's good info.  Thanks again, sladen 
<mdke> I didn't say it was, I just said I didn't see them resuming
<fabbione> usuall that error comes out only on first connect of the device
<fabbione> not if it's already connected
<fabbione> phisically'
<mdke> it's usb? I think I've seen it when I haven't been using usb
<mdke> i'll have to check
<mdke> so that's a dupe I take it?
<fabbione> rejected
<fabbione> it's not a bug
<mdke> well, the feedback when resuming is a bug, although probably not that one
<fabbione> another user reported it in hoary
<iwj> Riddell: do you have an opinion about bug 47780 (just filed) ?
<Ubugtu> Malone bug 47780 in Ubuntu "example odt does not open after kubuntu breezy -> dapper" [Normal,Unconfirmed]  http://launchpad.net/bugs/47780
<fabbione> and i had to dig into the USB hw specs to understand where the hell it was coming from
<mdke> fabbione: lucky you were here now, thanks
<fabbione> mdke: basically, if you get that errror, stop buying cheap hw
<mdke> fabbione: it was free from your employer
<fabbione> not the host
<mdke> how could I refuse
<fabbione> the devices you plug to it
<mdke> ipod/camera
<fabbione> that error is basically generated when a plugged device return too much current on the port
<mdke> ah, could be the usb mouse actually
<mdke> that was cheap
<fabbione> whatever is connected on port 1
<fabbione> the host doesn't suffer of the issue
<fabbione> the host detects the issu in the plugged device
<fabbione> mdke: goggle for that error and adds USB hardware specification
<fabbione> there are even hw schemas with examples
<mdke> ok, thanks
<mdke> anyhow, recently I've been getting loads of feedback on resume, not just that
* sivang assumes it's still makes sense to test, release has not yet been out
* sivang just came back from some urgent personal errands.
<tritium> hi sivang 
<sivang> Is it know that the desktop-cd takes ages to boot / load ?
<sivang> (I already tested the live cd, and everything else on the graphical boot menu that did not require installation)
<sivang> the boot and setup phase took much longer then it did for the breezy live cd)
<sladen> seb128: none.  just crossing it off the list of bugs I had
<seb128> "none" to what?
<sladen> seb128: "what is the interest of the new comment?" in 34492
<seb128> ah ok
<seb128> yeah, it looked like a "I insist on my bug being a priority" comment
<seb128> which is a sort of comment we don't really need, especially if the bug has been acknowledged and forwarded upstream
<desrt> malone #34492
<Ubugtu> Malone bug 34492 in gnome-utils "keybindings-properties: DoS by screenshot" [Unknown,Confirmed]  http://launchpad.net/bugs/34492
<sivang> seb128: in any event we are not going to fix anything like that now, only for updates right?
<seb128> sivang: we are not fixing anything now, CD are rolled and will probably not be rolled again
<mako> Burgwork: you around?
<sivang> seb128: cool, would it make sense to give more testing now?
<sivang> (cd testing, that is)
<mako> Burgwork: we should talk here.. i have only a little bit of time left on this net connection :)
<ajmitch> morning all
<seb128> sivang: cd testing are always useful
<sivang> seb128: k
<janimo> Kamion, as there's no final xubuntu release yet on cdimage, I hope it's not too late to rebuild xubuntu alternate. last comment on bug 41322. thanks
<Ubugtu> Malone bug 41322 in gfxboot-theme-ubuntu "add LTSP server option for xubuntu install CD" [Normal,Unconfirmed]  http://launchpad.net/bugs/41322
<janimo> back in the morning
<pitti_> wb mdz
<pitti_> mdz: reappearing at midnight for an early release? :)
<doko_> pitti_: yesterday that was the time where "MiniBar" was called ;)
<mdz> pitti_: just checking that all is quiet on the battle front before I sleep
<pitti_> mdz: did you hear about any major breakages today?
<pitti_> doko_: mmm, DrinkingBoF
<mdz> BenC: I got a kIrDAd panic during my last boot
<mdz> pitti_: none
<kermitX_> hey guys. i just tried removing the xubuntu-desktop meta package via aptitude, and it automatically selected it's "contents" for removal -- it didn't used to do that.
<pitti_> mdz: \o/ it worked surprisingly smooth for me, too
<BenC> mdz: There's a bug report about it aswell, not on boot, but related to usage on some oddball case
<Seveas> kermitX_, please use #ubuntu for support
<kermitX_> seveas: this is not a devel issue? something changed on "your end" regarding this.
<BenC> mdz: were you booting from a suspend?
<Seveas> kermitX_, aptitude has always done that
<pitti_> kermitX_: see #ubuntu, I answered
<kermitX_> seveas: NO it has not.
<Seveas> kermitX_, and for bugs there is the bugtracker
<mdz> BenC: no, from a cold start (my first in a while)
<mdz> BenC: the boot continued OK from there, though usplash timed out
<BenC> mdz: Are you using irda in any way?
<mdz> BenC: nope
<BenC> maybe you had your tv remote aimed at it or something :)
<mdz> BenC: my trace looks like the one in bug #46947
<Ubugtu> Malone bug 46947 in linux-source-2.6.15 "Oops with IrDA in 2.6.15-23-686" [Normal,Unconfirmed]  http://launchpad.net/bugs/46947
<infinity> kermitX_: If you installed xubuntu-desktop via aptitude, it will, by default, record its dependencies as being "indirectly requested", and mark them for removal when nothing "directly requested" depends on them anymore.
<infinity> kermitX_: This is aptitude behaviour you can disable, but it's always been like that.
<mdz> BenC: exactly the same eip in fact
#ubuntu-devel 2006-06-01
<BenC> mdz: so a ccrash in nsc-ircc?
<BenC> nsc-ircc has some bugs related to probing, I think I may end up backporting to fix that up
<BenC> mdz: I'll mark it for dapper-updates
<mdz> BenC: I've attached the full dmesg to the bug
<BenC> mdz: Ok, thanks
<crimsun> BenC: I can confirm that 46947 is nonfatal, occurs on this thinkpad x41-2527
<mdz> there were some odd serial8250 messages later on too
<mdz> could be related
<BenC> crimsun: Can you sub to the bug report too please?
<BenC> that sort of fix is something I want tested before I push it out to dapper-updates
<crimsun> BenC: done.
<BenC> thanks
<BenC> crimsun: BTW, work has already started on the first post-release dapper kernel, so if you have any patches that missed the release, just shoot them on over
<doko_> mdz: dapper-updates is already open?
<mdz> doko_: yes it is
<mdz> we have the technology
<crimsun> BenC: k, I'll git pull this evening
<mdz> thanks to cprov
<ajmitch> mdz: what will the rules be for universe? all debdiffs get checked by you for -updates?
<doko_> nice
<mdz> in particular, we can get upgrade fixes into -updates before we go gold
<BenC> mmm...gold
<Seveas> what's the ETA of gold?
<mdz> ajmitch: they'll be reviewed by the archive team
<BenC> mdz: will we have gold cd's in paris to take home? :)
<ajmitch> ok
<mdz> hmm, possibly
<mjg59> tritium: We have all those patches in our 2.6.15
<mdz> ajmitch: is there something in particular you're planning for -updates?
<ajmitch> f-spot patches from upstream
<mdz> Seveas: tomorrow
<mdz> UTC
<Seveas> mdz, I was hoping for a bit more specific timestamp ;)
<mdz> any particular reason?
<BenC> a day and a TZ, what more could you ask for? :)
<Seveas> #ubuntu gets swamped with that question over and over
<Seveas> something like "not before noon" would already be useful
<ajmitch> Seveas: then say the end of the day or something, so they don't get their hopes up
<mdke> tell them to update now
<Seveas> ajmitch, hehe
<mdke> and grab the cd on friday
<mdz> Seveas: and you think that if one of them gets an answer, the rest will go away? ;-)
<mdz> Seveas: morning or midday, most likely
<Seveas> Fridge says 0:00 UTC so lots of people think it'll be in 48 minutes
<Seveas> 
<sivang> hehe
<ajmitch> Seveas: excellent, put that forward 24 hours :)
<sivang> I think this is one of the nicest things in Ubuntu, we release when we feel it's right :)
<AlinuxOS> sivang, I agree... it's true.
<BenC> wasn't that inherited from Debian? ;)
<sivang> well,
<sivang> it's a bit better :)
<infinity> "When it's ready -- within a 24 hour window"
<Seveas> BenC, no, that would be "We may release..."
<AlinuxOS> :)
<sivang> we do not need to wait for the "signs".. :p
<mdz> sivang: Debian releases based on fixed criteria; we release on a target date and select our criteria accordingly
<BenC> or a GR
* BenC snickers
<mdz> they're both "when it's ready"; we just have different definitions of "ready"
<Seveas> "When sabdfl presses the ceremonial button"
<mdz> there is a magic button in Launchpad now
<sivang> mdz: that's what makes it so cool, we have a middle point between top quality and sensible release periods
<sivang> magic button for the release? :)
<AlinuxOS> mdz, really ? which one ?
<AlinuxOS> :D
<sivang> anyway, back to backup before disk wipe out
<mdz> the one which changes the status of Dapper from pre-release freeze to current stable
<mdz> I'll press it for the first time tomorrow; this will be the first release we've done on Launchpad
<AlinuxOS> :) I thougt it's manual change :)
<mdz> it is
<AlinuxOS> ah
<mdz> there is a button to be pressed
<sladen> remember not to click it twice!
<sivang> lol
<sivang> launchpad has grown so beautifully the last year :)
<AlinuxOS> mdz, when will possible to update some packages ? I mean the period of first updates ?
<crimsun> sladen: hmm, I wonder if that was a test case... ;-)
<mdz> AlinuxOS: there are already updates for dapper
<AlinuxOS> ah :D
<sivang> I have even one patch pending
<AlinuxOS> critical I think.
* sivang waits while hubackup backs up his home
<infinity> mdz: Did someone actually design a giant red button for you to make it a bit more fun?
<iwj> There's an off-by-a-character-or-two error in the centering of the textmode dialogue during cdrom check.
<iwj> Do we know about that ? :-)
<infinity> Do we care? :)
<mdz> iwj: the one in d-i, presumably?  not the usplash/casper one?
<iwj> Yes.
<sivang> mdz: btw, boot and auto config of the desktop-cd takes ages on my t43p machine. is it known / wontfix for this release?
<sivang> (that is the time from the boot, to when I Have the live desktop working)
<sivang> and by ages, I mean nearing the 6-7 minutes or so
<infinity> mdz: Oh, you're just talking about the drop-down box and submit button in "distros/ubuntu/dapper/+admin"... Damn... That's not the giant red button I was hoping for.
<iwj> It seems to be trying to predict where the dialogue ought to be by counting characters in the string it's printing but the algorithm it's using for centering and the one for wrapping evidently disagree.  Not really RC perhaps ...
* infinity avoids pressing it all the same.
<mdz> infinity: buildd admin != launchpad admin anymore ;-)
<infinity> sivang: Dirty cd-rom drive or bad media.
<infinity> mdz: Possibly true, but I still have a little yellow ducky...
<iwj> What are we doing about kubuntu ?  I'm really unhappy about the results of the upgrade tests I've been doing from breezy ...
<infinity> mdz: I'll want to confirm with cprov that the buildd-admin stuff is completely fixes before they take the ducky away. :)
<mdz> infinity: so you do!  I thought they were fixing that
<sivang> infinity: ah
<infinity> s/fixes/fixed/
<iwj> (Test cycles for that take ages, too.)
<mdz> iwj: from the sound of it, it's widespread upstream breakage that we're not in a position to do much about, though it's possible that it's simpler than I think
<mdz> iwj: firefox implodes in interesting ways when upgraded while running as well, as you know
<iwj> mdz: Absolutely, which is why we have that thing for telling you to restart it.
<infinity> iwj: I think it's an endemic issue in all d-i dialogs.  It's just more noticeable in some than others.
<mdz> does hoary->breezy not break in the same way?
<iwj> I'm not saying we should fix KDE.  That's too hard.
<iwj> hoary->breezy> dunno; I don't have a hoary kubuntu.
<mdz> iwj: we shipped firefox for 2 years before we got that ;-)
<iwj> But I think we should change the release notes to document a work{around,ing} method.
<iwj> mdz: It caused endless bug reports :-).
<mdz> iwj: or fix adept to reboot at the end?
<iwj> That might help.
<infinity> mdz: Though, "my web browser broke" is a bit less scary than "my computer won't even let me reboot it, and I had to kick the power switch"
<iwj> But there's the difficulty of editing the sources.list too.
<mdz> infinity: kdm crashing in that scenario is pretty spectacular, I agree
<iwj> Also, in my most recent test, which I did in konsole, I managed to produce a system which can't open .odt files ...
<mdz> iwj: perhaps in edgy, someone will port mvo's upgrader to KDE
<kermitX_> the F3 text (server, expert, etc) on the alternate cd's is incorrect, given the new boot menu.
<iwj> mdz: That would be nice.
<mdz> which has the right sorts of hooks to deal with this stuff
<infinity> kermitX_: What does it say?
<iwj> But for now I would like release notes which document a working procedure.
<mdz> infinity: it presumably wasn't updated when we renamed the menu items
<infinity> kermitX_: It's still "correct" if it says you can add "server" to the command line to do a minimal install, etc.
<infinity> Anyhow, too late, most people don't read help text anyway, etc, etc. :)
<mdz> adding that to the checklist for next time
<iwj> working procedure> and at the moment I haven't found one.
<mdz> iwj: is there a bug report open about this yet?
<mdz> seems hard to believe that no one stumbled on this upgrading to a pre-release dapper
<iwj> mdz: I agree it's strange.
<iwj> The .odt problem has a bug, yes.  Err, I don't have the number to hand ...
<kermitX_> i don't read the F3 text that way. it reads like breezy. where exactly would you type in something like "server-expert"? at the start or end of the boot line?
<iwj> Oh, there it is, bug 47780.
<Ubugtu> Malone bug 47780 in Ubuntu "example odt does not open after kubuntu breezy -> dapper" [Normal,Unconfirmed]  http://launchpad.net/bugs/47780
<mdz> iwj: I meant the fact that KDE implodes after being upgraded while running
<iwj> Oh, that.
<iwj> Err, I don't know of one, no.
<mdz> anyway, to bed with me; need to kick this cold for tomorrow
<mdz> night all
<iwj> Goodnight.
<iwj> It was clear we weren't going to fix that for dapper.
<iwj> And it seems pointless filing things as bugs when they're huge and well-known.
<AlinuxOS> mdz, thank you...and good night!
<iwj> mdz: Thanks for your hard work.
<sivang> night mdz 
<sivang> and ian :)
<kermitX_> sticking "server-expert" on the boot line did not start up d-i in the expected "expert" mode.
* infinity tests here, for kicks.
<sivang> infinity: is there a scenario (on a laptop) that might be good to test? I mean , something most poeple would not attempt? (/me still waits for backup to finish then going to test desktop-cd)
<infinity> sivang: The most interesting laptop cases are all the funky removeable devices (hotplugging batteries and hard drives and such), power management (cpufreq, sleep, hibernate), and if you have one, docking stations.
<kermitX_> infinity: f3 screenshot http://paste.ubuntu-nl.org/14935
<infinity> kermitX_: Hit escape.
<infinity> When you exit gfxboot, then "server-expert" works.
<kermitX_> infinity: "type it at the prompt". when you hit f6 to get the prompt, it is prepopulated with whatever menu item is selected. the f3 text does not indicate *where* amonst that you would type those parameters. past versions *only* required that one word, but doing so on dapper results in kernel panic on boot.
<infinity> kermitX_: But if you hit esc, to get to the actual boot: prompt which F3 is documenting, it magically works.
<infinity> kermitX_: yes, the F3 text should be updated to say "If you're in gfxboot, exit first before trying these"
<infinity> (note that it's the exact same text you get if you hit F3 at the boot: prompt, but all GUIfied)
<kermitX_> infinity: the ESC keypress to exit the "graphical boot" is not documented anywhere in any of those help screens.
<infinity> kermitX_: yes, hence my above comment.
<infinity> kermitX_: It should be.  it won't be for release.  Oh well.  Most users will never do any of those "scary" things anyway.
<kermitX_> infinity: hard to keep track of a few little text files with 15k or so packages to worry about, i guess. 
<kermitX_> question -- are there plans for periodic updates to dapper iso's to incorporate security fixes, etc.. similar to how debian re-issues stable?
<infinity> kermitX_: Not currectly, but that possibility may be revisited and discussed.
<kermitX_> infinity: just wondering. considering the number of updates there may be in 12 months or so. be nice to have for systems not on the public net, plus keeps it dapper fresh and "in the news" so-to-speak.
<Burgwork> infinity, we can have a 6.06 Service Pack 1!!! think, we can be just like the other guys!
<kermitX_> burgwork: at least ours would be tested. ;)
<HiddenWolf> Burgwork: well, it wouldn't be a bad idea to roll updates to the install cd's a few times over the next few years, to save new users the bunch of security fixes.
<jdub> Burgwork: i think it's extremely likely that we'll do that
<jdub> we're shipping at a WONDERFUL time for free software stability and so on
<jdub> but a terrible time for hardware refresh
<Burgwork> jdub, yep. Plus then we can throw dapper in the face of vista and  10.6
<ajmitch> Burgwork: but.. but.. dapper doesn't have shiny!
<HiddenWolf> ajmitch: works or shiny, works or shiny, hmmm
<Burgwork> how about tested vs shiny?
<HiddenWolf> Burgwork: I'm sure vista is tested, that doesn't say that the stuff actually works.
<Burgwork> HiddenWolf, to me tested == been the real world and been used by real users just like me
<HiddenWolf> Burgwork: I can test, find a bug, try teo report it to microsoft and be charged for it. That doesn't fix that bug I found. ;)
<Burgwork> hmm, charged for bugs
<HiddenWolf> Burgwork: yeah, you get a refund if the bug is confirmed
<Burgwork> at $30 a pop, canonical could make a hansom profit
<Burgwork> but this is OT, so we should go elsewhere
<HiddenWolf> I should go to bed. ;)
<HiddenWolf> Good night. :)
<tritium_> mjg59: ok, thanks.  That's interesting that we have those patches, given my errors.
<mjg59> tritium_: Bug number?
<tritium_> mjg59: I've not filed yet, as this is my personal work laptop, and I've been giving priority to the Canonical laptop
<mjg59> tritium_: Argh grah
<mjg59> tritium_: Without bug reports, we *don't fix bugs*
<mjg59> If something breaks, report it. Don't start talking about using custom kernels.
<tritium_> mjg59: yes, I know.  I recently encountered these.  I will report it.
<tritium_> I shall not utter such heresy again ;)
<dieman> mjg59: btw, will i see you at the paris summit?
<infinity> dieman: No, he's not coming because he HATES US.
<dieman> hahaha
<dieman> bastard
<mjg59> That PhD sure makes me hate
<infinity> bgertzfield: Around?
<jdub> http://perkypants.org/blog/2006/06/01/apt-get-install-vmware-player/
<jdub> he better be
<jdub> i just said nice things about him
<infinity> Aww, I got a perkypants mention.,
<infinity> I'm a somebody!
<infinity> Hrm, is the LegacyHuman theme in my theme selector really what we shipped in breezy?
<infinity> That brown's a lot darker than I remember.... Or I just got used to the current theme being a lot brighter.
<ToadZzZztool> just before going to bed... when will dapper-updates repository open and moreover edgy? has it been decided yet?
<ToadZzZztool> .oO(hi/'night/'evening/'morning by the way :))
<infinity> ToadZzZztool: dapper-updates is already open.  edgy will open soon.
<Burgundavia> infinity: it was a bit of shock for me when I moved back to my then breezy box as well
<ToadZzZztool> thanks infinity :)
<ToadZzZztool> g'night dev's
<ToadZzZztool> and thanks for the *huge* work on Dapper
<infinity> You're welcome. :)
<infinity> Burgundavia: Well, I remember being very shocked by the brightness of the new theme.  And to be honest, I'm still not entirely used to it.  But, unfortunately, I seem to be used to it enough that switching back is also uncomfortable.  Bah.
<infinity> Rock, meet hard place.
<infinity> I guess I'll just have to do my own theme and get it into edgy.
<infinity> "Adam's Middle Ground Theme, for people not entirely satisfied by breezy or dapper"
<bddebian> Hello
<Burgundavia> hey bddebian
<bddebian> Heya Burgundavia
<bgertzfield> infinity: I'm around now.
<davyd_> hey guys
<davyd_> has anyone else found ia32-libs uninstallable?
<davyd_> dpkg-divert: rename involves overwriting `/usr/bin/ldd' with
<davyd_>   different file `/usr/bin/ldd.amd64', not allowed
<bddebian> Hmm, I thought that got resolved?
<infinity> bddebian: It got half fixed, the other half of the fix got vetoed for being too intrusive.
<infinity> davyd_: rm /usr/bin/ldd, then install ia32-libs.
<infinity> s/install/upgrade/
<bddebian> infinity: Ah, OK, thx
<infinity> bgertzfield: Do you happen to know the guys who do the docs that ship with VMware Workstation?
<sfllaw> jdub: Say, how does one get a hackergotchi on planet.ubuntulinux.org?
<Burgundavia> sfllaw: you mean planet.ubuntu.com?
<sfllaw> Isn't that the same?
<Burgundavia> sfllaw: yep, but ubuntulinux.org is deprecated
<bgertzfield> infinity: I can get in touch with them.
<sfllaw> Burgundavia: That's crazy talk.  Are you also saying that I shouldn't be using http://no-name-yet.com?
<Burgundavia> sfllaw: yep!
<Burgundavia> they still work, however
<sfllaw> Crazy!
<mgalvin> haha, the dapper release announcement is on no-name-yet :)
<sfllaw> I'll have to admit that jbailey looks really asian in this photograph: http://www.ubuntu.com/htdocs/uweb/menu/img-support.png
<jsgotangco> lol
<sfllaw> http://www.ubuntu.com/ubuntu is out of date.
<sfllaw> Ubuntu _does_ have a pretty graphical installer now.
<bddebian> haha
* jsgotangco used to look like that in his support desk days
<wasabi_> Nice. vmware player on Dapper.
<wasabi_> Releasing with vmware-server in it too would be amazing, actually.
<sfllaw> wasabi_: That's still in Beta.
<sfllaw> And blew up on my computer.
<wasabi_> Ahh true.
<wasabi_> Sure works good. ;)
<sfllaw> wasabi_: aj and Erinn have proposed that we add debugging symbol support into apt, much like sources currently are.
<sfllaw> It's a pretty good idea, if you ask me.
<wasabi_> Whatcha mean by that?
<bddebian> I think we need a repo of all packages (at least main) that includes unstripped binaries
<wasabi_> I'd be interested in some sort of optional dependency classing system.
<wasabi_> Not sure how better to describe that.
<wasabi_> Oh geeze, it's similar to USE variables on Gentoo. Taboooo haha
<wasabi_> Such as something you can set... "debug"...  Recommends: package-dbg [debug] 
<infinity> bgertzfield: In the "Guest OS Install Guide" that ships with VMware, the Ubuntu docs don't really have much of anything useful to say, but what they *do* tell every user to do is to su to root and set a root password "so they never have to sudo again"
<infinity> bgertzfield: That sort of defeats the purpose of us setting up sudo, disabling the root password, and trying to get users used to that. :/
<infinity> bgertzfield: Would be nice if third party docs didn't try to impose their ideas of "correct root usage" on our default setup.
<bddebian> That's why I am saying why not have a seperate repo?  archive.ubuntu.com dapper debug or some such?
<Burgundavia> infinity: are you serious?
<Burgundavia> bgertzfield: if you need help with your docs, come talk to the doc team
<infinity> Burgundavia: Quite serious.
* Burgundavia grumbles about this
<Burgundavia> infinity: I cannot tell you the effort the doc team makes to keep the wiki consistent
<bgertzfield> infinity: that is lame.
<bgertzfield> infinity: hold one moment, on phone
<bgertzfield> infinity: I can file a bug.  Can you email me a snippet of exact text so I can find the offending page and get it fixed?
<bgertzfield> Burgundavia: I appreciate the offer!  I'll let the docs folks know
<Burgundavia> bgertzfield: we are fairly large and quite active and don't really mind absorbing something like that
<infinity> bgertzfield: Sent.
* infinity goes to the store, then nap.
* ajmitch returns home
<Burgundavia> mako: you around?
<bddebian> Is he ever? ;-)
<Burgundavia> bddebian: not really. Makes it hard to write a book with him
<dieman> hah
<dieman> hows the book going?
<Burgundavia> last edits now
<dieman> rock
<dieman> i was one of the proposal reviewers
<elmo> uh, pitti
<elmo> 30x16.png                                                   translations/language-pack-kde-mn-base
<elmo> 60x40.png                                                   translations/language-pack-kde-mn-base
<bgertzfield> infinity: Got the text.  Thanks!
<Kagou> hi
<lifeless> morning
<ajmitch> hi lifeless 
<Mithrandir> sladen: why do you think 47732 is a bug in casper?
<Mithrandir> Riddell: 47743, does this suggestion make sense and can you provide a patch?
<pitti> Good morning
<Seveas> hi pitti
* infinity considers napping through the release...
<Burgundavia> 'ello Seveas, pitti
<infinity> I've been up for a day, I suppose sleep might not be such a bad idea...
* dholbach hugs infinity
<dholbach> "I think a beta ISO has leaked somewhere" *snort into coffee*
<Burgundavia> dholbach: where is that from?
<Seveas> forums
<Burgundavia> ah
<Burgundavia> uhh, welcome to development in a fishbowl
<dholbach> and #ubuntu is going nuts as well
<Burgundavia> well, it is now the 1st here
<Fujitsu> #ubuntu is going crazy!
<Mithrandir> dholbach: like, we released it onto teh intarweb.
<Mithrandir> dholbach: I wonder if any warez sites has picked it up or anything.
<highvoltage> Mithrandir: i'm sure it has
<Fujitsu> Mithrandir, haha.
<dholbach> Mithrandir: that must be a 0-day release or something :-p
<Mithrandir> yeah, I'd think so
<highvoltage> Mithrandir: i've even seen some files go around with OOo keyz :p
<Fujitsu> Hahahahahah.
<Mithrandir> highvoltage: uh. :-)
* Fujitsu creates a version of OOo requiring a key.
<imbrandon> someone was asking about an activation crack for dapper in #ubuntu earlier too ;)
<jsgotangco> lol
<Mithrandir> while funny, it's more sad.
<Kagou> lol
<bgertzfield> jdub: !!!
* imbrandon starts to write gActivation and kActivation just to see the look on someones face  .....
<highvoltage> imbrandon: it will spread on the warzes sites like wild fire, saving bandwidth on the mirrors
<imbrandon> hahah or better yet , just make the winderz one work in wine ;)
<Gloubiboulga> imbrandon, could you write xActivation for Xubuntu too please ? ;)
<imbrandon> lol @ Gloubiboulga
<bgertzfield> I just saw http://perkypants.org/blog/2006/06/01/apt-get-install-vmware-player/ .  I'm so pleased. :)
<jsgotangco> highvoltage: yeah start splitting the current image then upload them to newsgroups
<infinity> bgertzfield: We're FAMOUS.
<crimsun> honestly I've never seen people spidering the release site by hand to try and locate a "final" iso.
<infinity> I guess .pool is hard to find.
<infinity> Oops, did I say that out loud?
<infinity> *cough*
<bgertzfield> infinity: Congrats for you. :)
<imbrandon> lol @ infinity 
<infinity> bgertzfield: Well, I was already famous on teh internets, so I'll let you have this moment of glory to yourself. :)
<imbrandon> teh intarweb infinity ;)
<bgertzfield> I'm famous on the inside.
<infinity> bgertzfield: That's just what non-famous people say to make themselves feel better. :)
<bgertzfield> Hey, were you in _Code Rush_?  I don't think so!
<infinity> "Oh, the other famous people are just jealous of you, because you make VMware packages."
<bgertzfield> I was a nerd on TV!
<Kamion> janimo: gah
<Burgundavia> infinity: are we waiting on mdz to wake up or something?
<Fujitsu> Burgundavia, haha.
<Kamion> Burgundavia: at minimum we're waiting on me having breakfast and getting into the office.
<Burgundavia> Kamion: ah, ok
<Fujitsu> How long'll that be?
<Burgundavia> Fujitsu: longer if you ask him
<Kamion> I'm not answering that question
<bgertzfield> ok, I'm off to bed. good night all
<Fujitsu> True.
<Fujitsu> Goodnight, bgertzfield.
<infinity> Burgundavia: mdz wants to push the big red button.
<Burgundavia> infinity: I figured as much
<infinity> Burgundavia: (A few of us have access to the button, but he does my performance reviews, so I'll not steal the honour)
<Fujitsu> Yay for big red buttons.
<Burgundavia> heh
<Fujitsu> Or would it be green?
<Kamion> janimo: I'll start off a rebuild for you, I guess
<jnjb> hhi
<infinity> Kamion: If I'd known you would approve it, I would have done it last night. :/
<infinity> Kamion: But I wasn't sure what policy we had or hadn't cobbled together for non-release ISOs.
<Kamion> well, I needed to fix the code too ...
<jnjb> i had a bug which freez my computer on dapper xubuntu, my config it's ibm thinkpad x24
<Kamion> but I figure we can always release yesterday's images if need be
<Kamion> infinity: policy> making it up on the fly
<Kamion> right, breakfast
<imbrandon> jnjb, try #xubuntu or #ubuntu
<infinity> Kamion: I could have fixed his bug, I'm not completely useless. :)  But yes, had no idea about the on-the-fly policy, didn't want to overstep.
<shawarma> jnjb: do you have a atheros card in it?
<jnjb> i had try but now i'm return on debian
<jnjb> whith beta3 freez at 2or 5 mins on x
<jnjb> shawarma no
<Riddell> Mithrandir: yes I think I agreee with it, you can do rm -f /usr/share/services/kded/kwalletd.desktop in casper to stop it running
<\sh> moins
<sladen> Mithrandir: was wondering if it was something like nvram being rmmod'ed
<Mithrandir> Riddell: 'k, thanks.  Could you add that to the bug?
<Riddell> yes
<Mithrandir> sladen: casper doesn't rmmod anything, so that's a bug somewhere else
<Riddell> done
<Mithrandir> Riddell: thanks
<Burgundavia> does smurfix ever come on irc anymore?
<Fujitsu> Burgundavia, I don't think so... Haven't seen him in several eternities.
<Burgundavia> Fujitsu: hmm. Does he still run the -CC.org domains?
<davyd_> infinity: you win the prize!
<Fujitsu> Burgundavia, yes.
<Seveas> Burgundavia, yes, but mitsuhiko co-admins those
<Fujitsu> Burgundavia, I had great trouble getting -au.org redone.
<Burgundavia> ok
<mdke> Burgundavia: #ubuntu-locoteams!!!!
<Burgundavia> mdke: hmm, how many of !
<Burgundavia> ?
<sabdfl> Happy Release Day everybody!
<jsgotangco> yay
<Fujitsu> Hi sabdfl :)
<Fujitsu> Hmm.
<Fujitsu> That was short...
<janimo> Kamion, thanks for the new CDs
<infinity> davyd_: I do?
<davyd_> infinity: you told me how to install ia32-libs
<janimo> highvoltage: ping
<highvoltage> janimo: pong
<janimo> highvoltage: there are new cd images which hopefully correct the ltsp install
<janimo> I am now trying it in qemu
<highvoltage> qemu is ok, but slow without acceleration.
<janimo> highvoltage: will take a while, but if it boots up afterwards without the ldm restarts you have seen yesterday I'll conclude it works
<janimo> highvoltage: I found that it's slow with kqemu as well 
<fabbione> janimo: ping?
<janimo> fabbione: pong
<fabbione> janimo: oh you are here
<fabbione> the cd images should been finished
<highvoltage> janimo: ok :)
<fabbione> Kamion wants to know if you are testing them
<janimo> fabbione: yes, if you mean today's builds yes I am already testing them
<fabbione> if not, please prioritize them
<fabbione> yeah today's build
<janimo> fabbione: only i386 alternate since desktop CDs are the same as yesterday
<fabbione> janimo: i didn't catch all the details, but whatever you and Kamion agreed :)
<janimo> fabbione: we did not agree on anything afaik but I suppose I need to test the latest build, so I do that :)
<fabbione> ok
<janimo> ogra, Riddell sending out separate announcements? if so where?
<janimo> it would be really nice if the new vmplayer package contained a plain empty hdd image just fit for trying to install new ubuntu iso's on
<morgs> janimo: I'm sure images with k-, x-, ed- and ubuntu preinstalled will be easily available soon...
<mvo> janimo: its the player, its not supposed for installing, just playing :)
<janimo> mvo, yeah I want to use it not play :)
<jdub> janimo: *hint* qemu-img
<janimo> jdub: uuuh
<janimo> jdub: hmm, but that'd still only be the image, I'd need to write the various vmX files no?
<pitti> mvo: btw, will update-notifier pick up the new release, too? or just u-m?
<mvo> pitti: just u-m
<pitti> mvo: oh, then I made false promises to a friend of mine :)
<mvo> pitti: :)
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | NO, DAPPER IS NOT RELEASED YET
<Kamion> infinity: heh, yeah :-) I guess I'm used to the baz era where you physically couldn't write to that file ...
<highvoltage> wow, that ivoks to hollowlife1987 joining looks cool :)
<Kamion> janimo: at some point after release I'll put together an image similar to the breezy one currently on http://cdimage.ubuntu.com/vmware/
<hollowlife1987> ?
<ivoks> :)
* Kamion takes archival copies of the dapper rc
* infinity runs off to the pharmacy to fill his release celebration prescriptions.
<ivoks> :)
<ivoks> so, do we know exact time? :)
<infinity> Nothing says "I helped make that OS!" like broad spectrum antibiotics!
<Fujitsu> !dapper
<Fujitsu> ie, no.
<Seveas> ivoks, yes we do: "When sabdfl hits the big red button"
<ivoks> Seveas: ok
<Fujitsu> sabdfl or mdz?
<ogra> mvo, ping
<mvo> ogra: pong
<ogra> mvo, do you have a link to your upgrade notes i could put into the edubuntu announcement ? 
<mvo> ogra: what do you mean in particular? this one http://changelogs.ubuntu.com/DapperReleaseAnnouncement
<mvo> ?
<Kamion> Seveas: mdz
<Fujitsu> Kamion, I thought so.
<ogra> mvo, oh, i thought that was intended for a separate page ... it will get merged into the emain announcement ?
<ogra> -e
<mvo> ogra: I'm not sure what you mean, this is what the user seens when he upgrades using the upgrader
<ogra> oh, ok
<ogra> so the only official upgrade procedure we have is "install u-m from breezy updates" ?
<jsgotangco> mvo: we don't need the gksudo switch anymore right?
<mvo> jsgotangco: when I hit my (smaller) red button, then not
* jsgotangco fires up his breezy laptop
* ogra makes a note to buy mvo a bigger red button for next release
<ivoks> jsgotangco: for the last time? :)
<jsgotangco> arghhh i forgot i erased it 2 days ago
<\sh> ogra: mvo needs a new gigabit wlan router ;)
<ogra> \sh, so you'll invent a gigabit wlan card that doesnt cook your lunch ? 
<ogra> hey mdz 
<pitti> mdz: good morning Mr. Ubuntu!
<Fujitsu> Hi mdz!
<mdz> morning
<Kamion> Contents updated, apt-file appears to be working
<pitti> Kamion: it sounds as if that is something we should add to https://wiki.ubuntu.com/ReleaseChecklist
<seb128> hey mdz
<jsgotangco> morning
* mvo is pretty happy with his wlan router :P
<Kamion> pitti: won't matter for future releases once Soyuz does it
<mvo> good morning mdz
<Kamion> we only had to manually drive it this time because the feature wasn't properly implemented in the archive yet
<Keybuk> seb128: you need to seek approval before uploading to dapper-updates
<seb128> Keybuk: infinity sort of approved that one some days ago :p
<seb128> he said the fix is trivial but he would prefer to have it going to dapper-updates, which I did now ;)
<seb128> Keybuk: who should I ping next time?
<pitti> mdz: ok if I upload/have synced tetex-base with the hyphenation fix we talked about earlier?
<seb128> Keybuk: we have around 40 GNOME 2.14.2 tarballs that will need approval :p
<mdz> how is everyone doing this fine morning?
* pitti fights his cold, but is otherwise fine
<mdz> I SAID HOW IS EVERYBODY DOING THIS MORNING?
<dholbach> mdz: lovely - how do YOU feel?
<highvoltage> mdz: excited
<Riddell> groovy
<Kinnison> mdz: I'm doing good thanks
<ogra> mdz, GREAT !!
<highvoltage> mdz: VERY EXCITED WHOHOOO!
* Fujitsu is excited this evening.
<Burgundavia> it is great to be alive
* seb128 is slightly tired and could do with a good sleeping night but is fine 
* mdz works the crowd into a frenzy
<dholbach> YEAH!
<ogra> YAYAYAY
<imbrandon> ;)
* Fujitsu dies of a frenzy.
<pitti> mdz: HAVE THE DRAGONS^WDUCKS CONQUER THE WORLD!
<seb128> :)
<imbrandon> heh /me thinks the frenzy has been in #ubuntu the last few hours ;)
* Fujitsu looks for the red button.
* sladen watches the Mexican-wave go around the room
<Fujitsu> imbrandon, it's been riotous.
* ogra pushes dholbach to the turntables in the corner to put up some release dancemusic
<imbrandon> Fujitsu, to say the leaste
<jsgotangco> drum and bass
<Riddell> pitti: dragons!
<Keybuk>  o    o   \o/   o    o
<Fujitsu> Hmm.
<pitti> Riddell ++
<dholbach> ogra: good idea :-)
<ogra> :)
<imbrandon> Riddell, DRAGONS!! ;)
<Fujitsu> My brother is telling me to `badger' mdz to press the red button.
<Fujitsu> What a bad pun.
<sladen> Keybuk: that looks like your new-style usplash throbber
* TheMuso decides to join in the festivities with a little pano music to get things going.
* pitti cranks up Pink Floyd
<jsgotangco> there is no red button
<highvoltage> the time has come to... push the button.
<TheMuso> ...and can improvise with whatever music is plyaing. Free and easy. :)
<jsgotangco> just an enter key
* imbrandon fires up Limp Bizkit - Break Stuff.ogg and hopes nothing breaks when released
<mdz> Fujitsu: all in good time
<dholbach> ogra: I just talked to a streaming expert - next time I'll have it set up :)
<Fujitsu> Of course, mdz.
<ogra> hehe
<ogra> dholbach, "ubuntu release radio" ?
<dholbach> yeah
<fabbione> AWTY?
<Fujitsu> Hahah
<dholbach> ogra: Doing the Berlin Party was the best thing I could do - get to know all the crooks in Berlin
<imbrandon> ;)
<jsgotangco> dholbach: do an icecast :D
<ogra> hehe
<dholbach> jsgotangco: I tried setting that up, but gave up after 30 min and put up .ogg files ;)
<ogra> UBUNTU GETS YOU EVERYWHERE !
<imbrandon> dholbach, icecast ? its easy ;)
<jsgotangco> heh
* imbrandon wonders howmany *buntu posd casts there are
<imbrandon> pod*
<highvoltage> ogra: ubuntu release radio actually sounds like a great idea
<TheMuso> Damn right it does!
<dholbach> jdub TV! :-p
<imbrandon> highvoltage, or just "ubuntu radio" 
<Seveas> "This is Ubuntu radio, featuring Jeff 'Pantsless' Waugh!"
<imbrandon> sabdfl and mdz weekly radio show ;)
<highvoltage> hehe
<Seveas> dholbach's bug of the week 
<jsgotangco> it should have an ubuntu food of the week segment
<dholbach> mdz live gigs on radio would be great :-)
* jsgotangco looks at JaneW
<highvoltage> the ubuntu cook show
<JaneW> jsgotangco: :)
<Seveas> Soupbuntu!
* pitti grabs JaneW for the Dapper Dance
<imbrandon> hmmmm *thinks about it serouisly*
* TheMuso pulls out a set og bongos and kongas for the occasion.
<JaneW> pitti: you lead!
<dholbach> haha
<pitti> JaneW: of course!
* TheMuso starts playing in 5/4 time to see if the dancers pick up on it.
* Kinnison gets a horrible idea that the dapper dance will be very very similar in style and accompaniment to the birdie song
<JaneW> 'let's talk about spec baby!'
<imbrandon> hahah
<ogra> lol
<TheMuso> lol
<Seveas> rofl
<JaneW> highvoltage: and that's SPECS I am talking about, don;t claw out your eyes ok? :P
<imbrandon> ROFLMAO
<TheMuso> JaneW: That would have worked better for UBZ.
<TheMuso> Lets talk about spec baby, lets talk about UBZ
<sladen> imbrandon: State of the Ubunion
<Seveas> "Tonight on 'Specs with mdz': Ubuntu French Kiss"
<imbrandon> sladen, nice 
<Burgundavia> sladen: sounds like a disease
* JaneW will be looking out for the the Paris photos
<mdz> sladen: with sauteed ubonions
<imbrandon> sladen, i have an highbadwidh icecast server too on buntudot.org , hmmmmmm *thinks about putting togather a buntu radio show*
<TheMuso> imbrandon: Yes yes yes! I'm up for helping. :) But not tonight.
<Keybuk> We'll have to think up an edgy dance
<imbrandon> right on, yea lets get the release out the door then work on it
<Keybuk> perhaps something "modern" with much leaping off tall buildings and walking up walls
<TheMuso> Has anybody consideredputting to gether an Ubuntu song?
<apokryphos> For anyone who doesn't know, #ubuntu is officially the largest channel on Freenode now ;-)
<TheMuso> As in actually recording, and producing it?
<imbrandon> nice apokryphos
<ogra> TheMuso, we could ask RMS ...
<sladen> imbrandon: it's actually something that's worth doing.  Red Hat and Google both have very good internal communications (eg. a weekly downloadable tv-show to keep everyone informed along with tidbits and humour)
<highvoltage> JaneW: k :)
<ogra> or probably not :)
<TheMuso> ogra: No thanks.
<Burgundavia> apokryphos: where are the stats on that?
<TheMuso> I think we can do better than his frale attempt any day.
<ogra> hehe, yes
<apokryphos> Burgundavia: #gentoo is the only other competitor
<Burgundavia> imbrandon: even a small company of 30 people that a friend works for has a monthly newsletter
<imbrandon> sladen, yea i was very serious about it ..... anyone interested SEROUISLY join #buntudot  we can talk aobut it after release ;)
<imbrandon> its not doing anything atm anyhow ;)
* TheMuso is there.
<imbrandon> apokryphos, i'm afraid to do a /list ;)
<apokryphos> imbrandon: if you do get ready to killall ;-)
* TheMuso ponders...
<imbrandon> ;)
<morgs> 978 people in #ubuntu
<ogra> hey silbs !
<infinity> mdz: Enjoy the big red button, I think I'm going to end up passing out before you get it pressed.
<imbrandon> aww infinity its worth the wait ;)
<infinity> imbrandon: If you've seen one release, you've seen 'em all. :)
<jsgotangco> let him get his sleep :)
<fabbione> infinity: good night dude
<Keybuk> it's not so much a big red button
<Mithrandir> it's a big button, takes a bit of time to push it.
* dholbach hugs infinity
<ogra> infinity, but given that its probably only one or two cigarettes away ...
<Keybuk> more of a steam pump that requires all hands on deck to get up to speed
<infinity> Keybuk: I know, it's more of a white button with a blue border.
<silbs> infinity: good night. Congrats, and thanks for the great work!
<fabbione> 3 minutes
<Mithrandir> infinity: brown button!
<Mirv> is the URL for the final announcement known? I'm doing final touches to a Ubuntu Finland press release
<thom> night ifni
<infinity> Oh, okay, I'll wait for the damned button.
<imbrandon> hehe yea , gnight infinity
* infinity taps his foot.
<TheMuso> Has the button got tactual markings on it? :)
<jsgotangco> lol
<TheMuso> So those of us who can't see it know which one to push?
<infinity> TheMuso: I don't think CSS allows for braille.
<jsgotangco> it has one big post-it note beside
<Mithrandir> TheMuso: there are buttons beside it which eats your fingers if you push them.  We call it tactile feedback. :-)
<JaneW> woohoo
<Mirv> maybe I'll just wait too, the press release is otherwise done
<TheMuso> Some feedback. :)
<ajmitch> evening
<TheMuso> If I happen to fall into that eaten fingers trap, and I find out who it was, they may get a big surprise come Parris.
<Lure> <philipacamaniac> It's released - http://releases.ubuntu.com/6.06/
<pvanhoof> if there's still a vmware player installed ... 
<pvanhoof> the vmware-player package wil not ask me to uninstall it
<pvanhoof> will conflict with it
<pvanhoof> and the dpkg --configure will fail
<pvanhoof> because the services are not shut down
<imbrandon> Lure,  whom pressed it ..... !?! j/k
* morgs sees releases.ubuntu.com is populated...
<sladen> Mithrandir: it should be a pair of buttons on opposite sides of the screen, that you have to *click* simultaniously
<infinity> pvanhoof: That can be sorted sometime when we're not PARTYING.
<Lure> imbrandon: that is just from #ubuntu ;-)
<imbrandon> oh i know, was just jokin
<pvanhoof> root@lort:~# /usr/bin/vmware-config.pl.
<pvanhoof> -su: /usr/bin/vmware-config.pl.: No such file or directory
<pvanhoof> root@lort:~#
<eXistenZ> How can I open a new translation group for ubuntu?
<pvanhoof> another problem
<pvanhoof> *reinstalling my original vmware, grmbl*
<infinity> pvanhoof: That's not a problem, since it's unrequired with the packaged versoin.
<pvanhoof> the script tells me to run that script
<pvanhoof> because some failure
<Riddell> eXistenZ: ping carlos 
* eXistenZ pokes carlos 
<pvanhoof> infinity, and because the script fails, I also can't uninstall the packages
<carlos> eXistenZ: please, read wiki.ubuntu.com/RosettaFAQ
<infinity> pvanhoof: Ahh, that's a packaging bug.
<infinity> pvanhoof: rm -f /etc/vmware/not_configured
<pvanhoof> same problem
<eXistenZ> carlos, Where can I find the code of my language?
<infinity> pvanhoof: And please file a bug on the vmware-player package in launchpad.
<pvanhoof>  Virtual ethernet                                                   failed
<pvanhoof> invoke-rc.d: initscript vmware-player, action "stop" failed.
<pvanhoof> dpkg: error processing vmware-player (--remove):
<pvanhoof>  subprocess pre-removal script returned error exit status 1
<Riddell> how do I do a CD check on powerpc?
<carlos> eXistenZ: what's your language name?
<infinity> pvanhoof: Rather than trying to discuss your bug right here, right now, while people are in the middle of a release.
<pvanhoof> infinity, how many bugs do you want on it?
<JaneW> ok, so time to start on Edgy specs...
<eXistenZ> carlos, well, I talk several, but I want open a group for Arabic.
<imbrandon> Riddell,  pearpc as a last resort would work
<JaneW> and how's the SoC going?
* JaneW runs and hides ;P
<carlos> eXistenZ: it's 'ar'
<ajmitch> JaneW: just wonderful!
* ogra looks at his socks
<Riddell> pitti: you put a pass in the powerpc desktop CD check, how do you do that?
<infinity> pvanhoof: The fact that the stop target fails if a previous installation is on the system is your fault.  Packages can't GUESS what you installed manually.
<pitti> Riddell: boot the 'check' image on yaboot prompt
<infinity> pvanhoof: The fact that a failing init script triggers the stupid "run vmware-config.pl" thing is a bug.
<pitti> Riddell: just as with 'oem', 'server', and so on
<Riddell> hmm, let me try
<sladen> pvanhoof: https://launchpad.net/distros/ubuntu/+source/vmware-player/+filebug please
<infinity> And now I am going to go to bed, since I stayed up to celebrate the release, not deal with "people who always feel the need to file bugs on IRC".
<jdub> ogra: was hoping very much to do a global stream for this release, but there were a bunch of technical challenges in the way (including annoying proprietary software)
<pvanhoof> well, the package is imho so not ready that it's not worth filing bugs on it ... 
<jdub> ogra: had jono and whiprush set up as euro and usa anchors...
<Seveas> hmm, launchpad says both 6.06 and 5.10 are current 
<ogra> jdub, no fluendo love ? 
<jdub> ogra: will do it next time :)
<pvanhoof> you know .. fix it and test it, and then I'll file bugs
<infinity> pvanhoof: If you don't file bugs, they don't get fixed.  We're not pyschic, and you're not so special that you get to be the only person who files bugs via IRC.
<jdub> ogra: that's not the problem end :)
<ogra> aww
<pvanhoof> infinity, I don't really care about being or not being special. the package is so unstable that I don't think it was ever tested. But then again, it's dapper, it's the test, right?
<apokryphos> Seveas: the big red button was pressed 8)
<imbrandon> red button done
<infinity> pvanhoof: It was tested repeatedly, just not on a system that already had a previous manual install.
<mvo> pvanhoof: please, the package certainly was tested
<infinity> pvanhoof: You'll find that LOTS of packages will blow up in that case.
<ogra> apokryphos, the big red button sends out an announcement mail if it was pressed *and* released again
<infinity> pvanhoof: Compile apache from source and tell me how well installing the deb goes afterward.
<infinity> pvanhoof: Etc...
<pvanhoof> ...
* apokryphos checks mail
<pvanhoof> fixing my vmware install now
<jdub> pvanhoof: dude, turn the positivity back on. it's good practice.
<apokryphos> ok, damn, not pressed yet
<sladen> pvanhoof: the packages isn't going to get fixed unless you file a bug.  So please, pretty please, file a bug and stop killing everyone else's fun in the middle of a release celebration
<pvanhoof> jdub, it's good that it's going to be packaged
<pvanhoof> jdub, but imho this is not a ready package
<Kamion> well file a bug and it can be updated in dapper-updates
<infinity> (which it will be)
<pvanhoof> I can start filing bugs on it, but then you'll all hate me for filing 80 obvious bugs
<Burgundavia> pvanhoof: packages only get ready by people filing bugs and then getting fixed
<apokryphos> 1000! in #ubuntu :)
<infinity> pvanhoof: No, I won't hate you for filing 80 bugs that I obviously DIDN'T SEE.
<infinity> pvanhoof: File them.
<seb128> pvanhoof: nobody will hate you for filling valid bugs on a package
<pvanhoof> fixing my own stuff first
<Mithrandir> pvanhoof: uh, no, we don't hate people for filing bugs.  We like people to check they're not filing duplicates, but a bug report is not an insult.
<seb128> pvanhoof: that's the only way we can fix issues on it
<infinity> pvanhoof: The bugs are only obvious to you because you had the player installed via other means.  I, however, did not.
<Mithrandir> so we like people to file bug reports.
<pvanhoof> argh, --force-all also doesn't work
<sladen> pvanhoof: then.  file.  a.  bug.  report.
<Kamion> force just overrides dpkg, not maintainer script behaviour
<jdub> Seveas: why did you put #ubuntu on moderate?
<Seveas> because they're going too crazy
<Seveas> just a cool-down
<janimo> anybody want to eyeball/edit https://wiki.ubuntu.com/XubuntuDapperReleaseNotes ? thanks
<jdub> Seveas: you realise that moderating them will just make it worse, right?
<Burgundavia> janimo: can I edit it?
<janimo> Burgundavia: sure, thanks!
<apokryphos> jdub: putting it on +m a couple of times has definitely helped
<sladen> Seveas: thanks for unmoderating it.
<amac-laptop> the peasants are rejoicing
* apokryphos chuckles
<pvanhoof> putting an exit 0 in the /etc/init.d/vmware-player script :)
<Kamion> janimo: I'll get it out to mirrors shortly - just backed up behind dvds
<Burgundavia> janimo: done
<janimo> Burgundavia: thanks
<Burgundavia> apokryphos: why is Gentoo so high?
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY!
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY!
<ivoks> yay! :)
<ajmitch> oh good
<janimo> Kamion: no hurry, I am still not finished with the qemu run. Although the results won't change anything at this point
<amac-laptop> that means its released?
<ajmitch> time to have a drink or two
<Kamion> janimo: we've tested it here and it doesn't install ltsp-client or ldm
<janimo> Kamion: oh cool, thanks
* jdub hits the u-a button
<apokryphos> Burgundavia: because they need a lot of help ;-). Not really, though I guess Gentoo as a distribution requires a lot of walking through, and it's very heavily more community-based
<apokryphos> that's why (I hate to say it) they have a pretty awesome wiki
<Kamion> gar publish-release gar
<Kamion> (creating wrong filenames for dvds)
<apokryphos> since you have to set so many things up by yourself, it's just as easy to break almost every single thing
<sabdfl> Happy Dapper Release Day!
<Mithrandir> Kamion: ew. :-/
<ivoks> congratz everyone
<sabdfl> what an amazing effort - thanks and well done everybody
<apokryphos> sabdfl: :D
<Kamion> https://lists.ubuntu.com/archives/ubuntu-announce/2006-June/000083.html
<sabdfl> mdke: phenomenal work on the doc team
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY! | https://lists.ubuntu.com/archives/ubuntu-announce/2006-June/000083.html
<apokryphos> sabdfl: check #ubuntu 8)
<Ubugtu> Ubuntu bug 8 in texinfo "Contains /usr/share/info/dir.old.gz if rebuilt on current sid" [Normal,Resolved: fixed]  http://bugzilla.ubuntu.com/show_bug.cgi?id=8
* highvoltage does the Edubuntu has been launched dance
* ogra joins highvoltage 
<sabdfl> Ubugtu: <jedi wave> there are no dapper bugs </jedi wave>
<ogra> LOL
<ivoks> :)
<siretart> congrats for the release!
<ajmitch> great work
<sladen> sabdfl: you could get the guys to add a button to launchpad to acutally make that happen!
<highvoltage> sabdfl: you're probably tired of this, but thank you!
<dholbach> sabdfl: haha :-)
<TheMuso> Well done all. A well deserved rest is called for I think.
<morgs> sabdfl and all: Well done!
* Burgundavia hugs everybody
<pitti> me jumps for joy
<pvanhoof> I simply pasted my terminal in the bug report
<pvanhoof> have fun
<maswan> Yay!
<pvanhoof> https://launchpad.net/distros/ubuntu/+source/vmware-player/+bug/47823
<Ubugtu> Malone bug 47823 in vmware-player "If an existing vmware installation was installed, the vmware-player package breaks" [Normal,Unconfirmed]  
<ogra> GROUP HUG !
<janimo> pvanhoof: thanks for reporting it
<sladen> pvanhoof: thank you!
* dholbach hugs everybody :)
<rob> I switched to Kubuntu during the last release (from Ubuntu), it rocks too (so congrats Kubuntu guys too)!
<Kamion> no, edgy will not be opened today :-)
<jsgotangco> GO EDUBUNTU!\
<TheMuso> lol
<ivoks> Kamion: oh, but we live on the edge :)
<sladen> Kamion: dapper-updates?
<mdke> sabdfl: thanks a lot.
<mdke> well done everyone
<pitti> mdz: can you please add your blessing to bug 47822?
<Ubugtu> Malone bug 47822 in tetex-base "Please sync tetex-base 3.0-16 to dapper-updates" [Normal,Confirmed]  http://launchpad.net/bugs/47822
<Riddell> thanks rob 
<seb128> sladen: if you look on dapper-changes you will notice that some dapper-updates uploads already happened
* hunger hopes the bugfixing will start soon again:-) All the stuff that matters to me was not RC:-(
<Kamion> sladen: is already open
<jdub> FRIDGED
<seb128> Kamion: now might not be the best time to ask, but we decided to update GNOME to 2.14.2 on dapper-updates right? We can start on it with dholbach if we want? :)
<Mithrandir> seb128: you're insane.
<jdub> seb128: crazy mofo!
<Mithrandir> but then, you haven't packaged new upstream versions for _days_ so you must be hungry.
<rob> the download page is still 5.10?
<seb128> Mithrandir: that's rather that I'm on VAC next week, then there is only few days, then Paris summit and then GUADEC
<seb128> Mithrandir: so I prefer to get that done before my VAC if possible or it'll have to wait a month
<Mithrandir> seb128: we still have the crazy daniel, though
<Kamion> seb128: give us a little while to cope with the tail-end of getting dapper out here first
<Keybuk> seb128: the incoming queue, publisher, etc. are all still off
<seb128> I prefer to be around so I'm sure he doesn't break the world :p
<imbrandon> who gets to update http://www.ubuntu.com/download
<dholbach> seb128: ...
<Keybuk> and will probably remain off for a day or two
<Kamion> imbrandon: it's in progress
<seb128> dholbach: you must be rusty after some months of icons stuff instead of desktop, no offense ;)
<dholbach> pfffft, you wish
<rob> Kamion, great :)
<dholbach> seb128: I think it was years, actually.
<seb128> :p
<Kamion> as is xubuntu now that I've unbroken publish-release
<dholbach> YAY XUBUNTU LOVE!
<Kamion> in one of its modes, it found it hard to cope with the concept of a CD image whose version didn't have something like "-rc" on the end so it produced double dashes
<highvoltage> dholbach: YAY!
<Kamion> that code only gets tested once every six months ...
<Mithrandir> Kamion: are you suggesting we should release more often?
* Mithrandir hides
<Kamion> heh
<dholbach> good idea :)
<Mithrandir> the 4.5 month ride is going to be wild, I think.
<TheMuso> Twill be a very interesting release cycle, thats for sure.
<Kamion> janimo: can you add "release/" to the end of your URL?
<Kamion> it'll be http://cdimage.ubuntu.com/xubuntu/releases/6.06/release/
<janimo> Kamion: sure
<Kamion> due to a quirk of the cdimage layout
<Kamion> thanks
<Mithrandir> give a new meaning to the word "sprint", I suspect.
<sabdfl> Mithrandir: whatever we can do to make it more fun, we should
<sabdfl> this is supposed to be a crazy-but-fun cycle
<Mithrandir> sabdfl: yeah.  It'll be _reallly_ hectic, though.
<sabdfl> we can discuss substantial variations in the release schedule bof's in paris
<sabdfl> to try to ease the pain
<sabdfl> scott has some good ideas
<dholbach> no uvf for example :-p
<ajmitch> heh
<ajmitch> that would be a bit crazy
<sabdfl> s/good/interesting/
<sabdfl> it's the EDGY EFT!
* ajmitch regrets not getting to paris :)
* sladen grins
<Keybuk> mdz is going to teach us all how to walk up walls for the edgy dance
<sabdfl> ajmitch: we are going to do as good a job of virtualising the BOF's as possible
<sladen> ajmitch: you should never regret anything, until it actually hasn't happened
<Mithrandir> Keybuk: ooh.
<sabdfl> we'll use VoiP to get you at the table, from the other side of the world
* Kamion updates the /distros/ubuntu/dapper description to be in the present tense
<Kamion> cool, didn't know I could change that
<ajmitch> sabdfl: that's great
<Mithrandir> sabdfl: so we'll have bandwidth this time? :-)
<ajmitch> Mithrandir: you reckon there wasn't enough at UDU & UBZ? :)
<ploum> Congratulations to all :-)
<Mithrandir> ajmitch: UBZ wasn't too bad.  UDU was _horrible_, bandwidth-wise.
<ajmitch> UDU was appalling
<ajmitch> in terms of bandwidth, but that couldn't be helped :)
<seb128> ploum: thank you ;)
<TheMuso> Thats what you get in Australia. We lag behind the rest of you guys broadband wise.
<ajmitch> .au is a bit like that sometimes
<highvoltage> how do i dist-upgrade to edgy?
<TheMuso> Kinda sucks sometimes.
* highvoltage ducks
<ajmitch> TheMuso: I wouldn't dare to comment further on that, being a kiwi :)
<ploum> seb128: you did good work. I think you can have some hollidays.  I give you two or three hours
<ploum> ;-)
<TheMuso> heh
<seb128> ploum: ah ah
<pitti> ploum: holihours?
<ploum> pitti: I don't think seb128 is able to "not work" for more than a few hours
<seb128> ploum: you are wrong, I'm on VAC next week :p
<ploum> Anyone knows if http://www.ubuntu.com/download will be updated soon ? (I'm linking to it in my announce)
<ploum> seb128: you told me ...  Will you be one week without a computer ? really ?
<Mithrandir> seb128: that only means you'll drop by twice daily to see how we're doing. :-P
<seb128> ploum: yeah ;)
<ploum> oh happy man
<jdub> hey ploum 
<ploum> Mithrandir: exactly
<ploum> hello jdub
<seb128> Mithrandir: no, I'm going to the sun actually and I don't think I'll have an internet access, so that will be a real non-working week for a change :p
<Mithrandir> seb128: amazing! :-)
<seb128> isn't it? :p
<jsgotangco> wow
<jdub> seb128: oh, you have sunny holiday destinations in france?
<ploum> seb128: when your hands are shaking, it's time to find an internet cafe
<seb128> jdub: who said I'm staying in France? ;)
<jdub> seb128: good point
<morgs> I didn't know there was internet access on the sun...
* seb128 slaps jdub anyway
<seb128> yeah, we have sunny destinations in France!
<jdub> seb128: you said it!
<seb128> vuntz_: I think jdub will have to pay that during GUADEC, what do you think? ;)
<ploum> Is Sun this big shiny ball in the sky that some people are talking about in some country ?
* ploum lives in Belgium
<vuntz_> seb128: you know, jdub will have to pay for many things anyway :-)
<seb128> hehe
<vuntz_> we don't need good reasons ;-)
<seb128> :))
<vuntz_> he has to learn french
<sabdfl> Mithrandir: elmo says we should have at least 2mbit
<sabdfl> i'd like to have a bit more
<jdub> vuntz_: ah ah ah
<seb128> jdub: coming to the Paris summit BTW?
* TheMuso would love to stick around and soak u the vibe, but he must go and be musical, which is not a bad thing anyway. :) Enjoy the fun of the release! :)
<jdub> ^ see, french!
<jdub> seb128: yeah
<vuntz_> jdub: seriously, how can you live without being fluent in french?
<sabdfl> we'll see
<seb128> jdub: excellent
<Mithrandir> sabdfl: if we want to do voip and stuff, we want more, yes, or we'll have to QoS the whole shebang.
<thom> vuntz_: you get to live with a sensible keyboard... ;-)
<Lathiat> Hrm, how can one organise larger cd orders?
<vuntz_> thom: hehe
<vuntz_> seb128: btw, since jdub is coming to paris, I hope you'll make him learn all the basic expressions in French
<seb128> thom: I'm sure you secretly dream to have an azerty keyboard
<seb128> vuntz_: yeah, he'll be ready by the GUADEC time, don't worry ;)
<Mithrandir> seb128: I'm sure it's nice to slap people with.
<vuntz_> seb128: great
<vuntz_> he has to pass an exam there
<vuntz_> seb128: btw, what happened to the gnome-session patch that set LANG and LC_ALL to fr? :-)
<seb128> vuntz_: shushhh, that's supposed to be a surprise
<dholbach> vuntz_: haha
<jdub> vuntz_: dude, french *so* isn't enterprise ready
<Lathiat> haha
<dholbach> yeah, it's going {hoary,breezy,dapper}-updates
<vuntz_> jdub: you know, it's very enterprise 2.0 and 3.0
<Lathiat> but does it comply with web 2.0?
<jdub> maybe enterprise 0.1 (Narky Napoleon)
<vuntz_> ahah
* vuntz_ uses his azerty keyboard to slap jdub
<jsgotangco> lol
<sladen> somebody should respond to Sun with "well, actually, our Software is already 3.141591265.."
<fabbione> sladen: ?
<sladen> fabbione: seen the Sun press release?
<fabbione> sladen: nope..
<vuntz_> hi moberg_
<fabbione> url?
<moberg_> vuntz_: hello
<sladen> fabbione: I think jdub has the except on the elfridge
<vuntz_> seb128: btw, the gnome-session patch won't be needed for GNOME 2.15.3 since there was no objection for this change after the previous announcement
<seb128> good
<sladen> fabbione: "[Ubuntu]  is based on the rock that is Debian and best of all the company behind it has a very Software 3.0 approach to business."
<fabbione> sladen: yeah found it
<ajmitch> sladen: lovely marketing BS
<seb128> one extra step to the world domination ;)
<sladen> fabbione: if you manage to decode it, let me know...
<vuntz_> seb128: next step is to put the fr language packs on the ubuntu cd ;-)
<fabbione> sladen: well it's PR talking.. i already spotted Ubuntu GNU/Linux
<seb128> vuntz_: that's already done ;)
<seb128> vuntz_: F2 on the boot, select french and you have a fully french liveCD ;)
<vuntz_> seb128: oh, then we just need to enable it by default
<seb128> right
<vuntz_> and remove the other language packs
<sladen> fabbione: the number of "GNU/"s in there is impressive.  They must be paying homage to somebody
<fabbione> sladen: yeah SUN has a huge PR machine behind.. clearly it's their first Linux approach
<looksaus> congratulations, all
<highvoltage> janimo: ping
<jsgotangco> fabbione: congratulations on -server
<jsgotangco> infinity: congrats too
<fabbione> jsgotangco: thanks, but i was only the manager.. infinity was my strong handworker there ;)
<fabbione> *manager*
<fabbione> well whatever :)
<janimo> highvoltage: pong
<jsgotangco> it works great
* shenki says hello to ben
<highvoltage> janimo: #xubuntu misses you :)
<jsgotangco> heh
* pschulz01 raises a glass in Adelaide
<JaneW> sladen: hahaha
* JaneW throws a pie at sladen 
<sladen> mmm, free pie!
<janimo> jdub, mdz: where shall I send the xubuntu announcement when ready?
<ploum> hey looksaus !
<JaneW> ploum: nice bed time story :))
<ploum> congratulations for ubuntu-be :-)
<ploum> JaneW: thanks :-)
<jsgotangco> JaneW: congratulations too
<looksaus> ploum, you're welcome
<looksaus> it's cost more effort than you would think
<sladen> mvo: is there anyway to get https://launchpad.net/people/vmware-build attached to an email address so that bugs can be subscribed to it?
<looksaus> <5 hours sleep for the last 4 days
<looksaus> but it was worth the effort
<ploum> looksaus: wow !  That's just like me with my university work
<Kamion> sladen: ask bgertzfield to do it
<ploum> indeed, it's great
<looksaus> hope press picks it up
<ploum> jdub: thanks to looksaus, we have now a real ubuntu-be.org website
<mvo> sladen: in launchpad? I guess only a admin can do this
<looksaus> and a press release
<looksaus> and 80 volunteers all over the country
<looksaus> who will work as public demo & install points
<looksaus> see http://map.ubuntu-be.org/nl and http://map.ubuntu-be.org/fr
<looksaus> and an official endorsement by the Flemish ministry of education
<looksaus> and a team that knows each other a lot closer
<ploum> and that speaks a mix of french/dutch/english
<looksaus> sorry if this sounds like bragging
<sladen> Kamion/mvo: ta, done
<looksaus> I'm just quite happy things have gotten to where they are out here
<ploum> ubuntu-be is rocking ! 
<Kamion> mvo may be right that it needs an admin rather than just somebody behind the imported e-mail address; not sure
<sladen> Kamion: ah right, bgertzfield is a vmware person
<infinity> Did I miss anything?  Should I be drunk yet?
<Mithrandir> sladen: re 47721, it'd be useful if you provided timing information as I requested.
<sladen> Mithrandir: stop-watch style?
<Mithrandir> sladen: yeah.  I'm just wondering if it's timing out or not.
<Kamion> sladen: right
<infinity> sladen: Assign the vmware bugs to me for now, I'll ping Ben about them later and get a team setup.
<jsgotangco> it seems release is more sensible now compared to last year
<ajmitch> jsgotangco: less chaotic?
<jsgotangco> yeah
<sladen> jsgotangco: much more organised.  There's even a *big red button* to press now
<ajmitch> yes, it's been quite an achievement this time round, everything seems to have gone very well
<jsgotangco> yeah
<Kamion> sladen: well ... several buttons that must be pressed in the correct sequence
<sladen> jsgotangco: and it's all hooked up to simultatious fireworks on 5 continents.  Amazing.  
<ajmitch> sladen: you mean they skimped on fireworks in antarctica?
<sladen> ajmitch: animal-rights issues.  It might have frightened the penguins---would have been really bad PR.
<ajmitch> how sad
<ajmitch> I'm sure the guys spending the winter on the ice would have appreciated it
<Kamion> sladen: and actually publishing CD images is not really at the "big red button" stage yet
<Kamion> so I guess it's kind of "feed Kamion coffee and then press several big red buttons". :-)
<jsgotangco> heh
<jdub> hrm
<jsgotangco> Kamion: congrats on ubiquity too
<thom> s/press.*/take cover/
<jdub> can gnome-bittorrent start from an existing, incomplete file?
<ogra> it pretends to
<Kamion> jsgotangco: thank you
<sladen> jdub: assuming it works like the rest;  give it the .torrent, and it'll check in the current directory and scan anything of the correct name for downloaded chunks
<infinity> jdub: Works well for me...
<Kamion> next time we'll make the partitioner not suck ;-)
<jdub> ok
<AlinuxOS> Happy Dapper Day! ;)
<jdub> mjg59: ping?
<mjg59> jdub: Hi
<highvoltage> ploum: how can you blog about flying cars at a time like this!!!???
<highvoltage> :P
<jdub> mjg59: does the x40 table have a wacom interface for the tablet screen?
<mjg59> jdub: Yes
<jdub> mjg59: what do you think of the screen hinge?
<jdub> (someone here asking about ubuntu compat)
<thom> jdub: i like my x41 tablet...
<mjg59> jdub: Not auto-detected
<mjg59> Haven't figured out how it's signalled
<jdub> thom: oh, rad
<jdub> mjg59: oh, i mean, strength
<mjg59> But just apt-get install wacom-tools for screen love
<mjg59> jdub: Oh, right. Seems fine,
<sladen> ploum: you forgot to link to the Dapper Car:  http://www.netsplit.com/blog/work/canonical/new_theme.html
<thom> mjg59: you can probably have mine to play with for a few days since $newjob will be giving me shiny...
<mjg59> Hurrah
<jdub> yay
<jdub> more alptops for mjg59 
<jdub> just what he needs!
<Mithrandir> jdub: he needs them to build his new home.
<Mithrandir> it'll be the first building in the world to be made entirely of laptops
<jdub> it will be full of awesome
* jdub bags not staying in the toshiba room
<MysteriousGEGL> with compiz powered doors and windows
<imbrandon> heh
<Gervystar> jdub: I've just installed vmware-player to give it a try, but it doesn't start and it prints a lot of errors. Seems like it has been compiled with wrong references to some shared libs. Here's the output: http://pastebin.com/750996
<sladen> thom: proper xrandr in the next release too, so the screen will be rotateable
<doko> does dapper-updates and dapper-security exist for ia64?
<Gervystar> nice job for everything and thanks for your work, indeed :)
<pitti> doko: http://ports.ubuntu.com/ubuntu-ports/dists/breezy-security/main/binary-ia64/
<ogra> sladen, and we'll have a Xgl based scree magnifier for the a11y team ... yay, wobbly zooming
<jdub> ogra: so, i don't really get that SoC thingy - compiz already has a magnifier...
<ogra> jdub, i dont get many of these SoC projects :)
<jdub> Gervystar: uh, weird - can you file a bug?
<Lure> Gervystar: works here - you shoudl submit the bug
<ajmitch> jdub: you'd deprive a student of a chance to learn & earn $4500? :)
<ogra> jdub, especially ubuntu welcome center :)
<Gervystar> jdub: of course. I'll do it right now
<pitti> Keybuk: how much beer/pie/neck massages would it take to do bug 47822? :) (I just want to make sure that people who upgrade to dapper today will get it right)
<Ubugtu> Malone bug 47822 in tetex-base "Please sync tetex-base 3.0-16 to dapper-updates" [Normal,Confirmed]  http://launchpad.net/bugs/47822
<Kamion> pitti: I can do it - have you test-built/installed it?
<pitti> Kamion: yes, of course
<pitti> Kamion: install from scratch, upgrade from breezy and dapper, and verified that it fixes the bug
<Kamion> ok
<pitti> Kamion: thank you!
<Kamion> access to the DC is ... a little on the slow side just now
<Gervystar> jdub: seems like someone else has already reported it, the bug is #47792
<jdub> Gervystar: if you could comment that you've seen the same, that would be handy
<Gervystar> jdub: done :)
<jdub> rad, thanks :)
<Kamion> hmm, sync-source doesn't actually understand pockets (dapper-updates)
<Kamion> but I can just edit the .changes
<Kamion> pitti: erm, the current version in unstable is older
<pitti> Kamion: I can also upload manually if necessary
<Kamion> er, newer
<pitti> Kamion: older?
<Kamion> 3.0-18
<pitti> Kamion: yes, that's why I asked to sync -16 from snapshot.d.n
<pitti> Kamion: the newer revisions are inappropriate for dapper
<Kamion> oh, I see. not sure I can do that with sync-source; please upload manually
<pitti> alright
<infinity> No, don't.
<Kamion> ?
<infinity> It's easy to do with sync-source.
<infinity> Same way I do incoming syncs.
<jono> incidentally, congrats on the Dapper release folks :)
<infinity> Kamion: Download the source, dpkg-scansources it, use that as your source distro.
<jono> a good job, well done :)
<Kamion> infinity: oh, ok - doesn't sync-source need it to be in its hardcoded table
<infinity> Kamion: sync-source will see that it's already downloaded, and won't go looking for it to download again.  And you win.
<Kamion> ?
<Kamion> aha
<pitti> infinity: so you can't point it to an arbitrary .dsc URL?
<infinity> Kamion: It may still need to use the lookup table to find the foo_bar_Sources file on disk.  If so, "incoming" was already hardcoded.
<infinity> Kamion: And if that's the case, just use "incoming". :)
<infinity> Cheating, for the win.
<janimo> jdub: do you think esd could go away for gnome 2.16?
<pitti> jdub, janimo: the only thing still holding it are sound events in libgnome
<pitti> that should disappear, totally
<seb128> I'm not convinced it'll be done for 2.16 though
<Kamion> aha, calling it Debian_20060323_main_Sources works
<seb128> 2.15 cycle is already started for a while and freeze will come fast
<mdz> janimo: fire when ready, yes
<janimo> so what is with polypaudio coming back again? wasn't alsa good enough by itself?
<mdz> janimo: I just tested out a xubuntu ltsp setup in vmware, nice and snappy
<jdub> alsa is penis
<pitti> seb128: it's that hard to operate out of libgnome? (I don't know)
<mdz> janimo: do you highlight that in the release announcement?
<janimo> mdz, to u-a? 
<jdub> ^ does that breach the CoC? if i say penis, does that breach trhe CoC?
<pitti> janimo: I never said I was fancy of adding it back, and I doubt we will. Alsa gets better every day
<mdz> janimo: yes
<janimo> mdz https://wiki.ubuntu.com/XubuntuDapperReleaseNotes
<mdz> janimo: I'd like to review the announcement before you send it out
<janimo> mdz, yes I mention ltsp
<seb128> pitti: it's not trivial but it should not be too hard neither, just need somebody knowing libgnome and gstreamer to spend some time on it
<mdz> janimo: is it in the wiki?
<jono> jdub: saying 'penis' breaches something
<janimo> mdz, ^^ :)
<Kamion> pitti: +-<li><a href="amstex/amsguide.dvi">amsguide.dvi</a>
<Kamion> ++<li><a href="amstex/amsguide.dvi.gz.">amsguide.dvi</a>
<mdz> janimo: release notes = announcement?
<Kamion> is that . intentional? also later on
<janimo> mdz, ah good question
<pitti> Kamion: uh, that looks fishy; I'll check it in detail
<mdz> janimo: we should highlight the fact that this is the first official Xubuntu release
<janimo> mdz, ok I'll make a real announcement as I was not sure 
<mdz> janimo: mind if I make some edits?
<janimo> mdz, please go ahead
<gathers> about the DapperReleaseNotes, is #47537 really the right bug? "Systems that are upgraded since hoary (or earlier) may have to manually delete linux-image-2.6.10 packages before the upgrade (#47537)."
<Kamion> pitti: thanks
<Kamion> pitti: it's possible it magically works, I guess
<pvanhoof> infinity, why again did you ask me to waste my time on filing the bug? Adriaan Peeters immediately rejected the bug
<pvanhoof> please never again ask me to waste my time on filing bugs
<pvanhoof> that way we can all be productive
<Kamion> pitti: if not, it is a pretty enormous diff, and perhaps backporting is more productive
<pitti> Kamion: yes, I can do that, too
<Kamion> pvanhoof: sometimes people reject bugs incorrectly. I don't know this Adriaan Peeters person and I don't believe he's responsible for the vmware-player packaging
<pvanhoof> can any person decide to reject a bug?
<Kamion> blaming infinity for something somebody else did is foolish
<Kamion> yes
<pvanhoof> in that case, wipe what I just said
<Kamion> your response is certainly overstated
<pvanhoof> Kamion, it's that I basically said that I would waste my time filing the bug, and people here insisted I did file it
<pvanhoof> s/did/do
<Kamion> I've reopened the bug. Please make your responses a little more measured in future
<mdz> janimo: you've checked the hardware requirements I assume?
<infinity> pvanhoof: Who?
<janimo> mdz, sure
<seb128> pvanhoof: maybe you could calm down? there is no need to be rude with people like that
<sladen> Kamion: snap.  Not only simultanious, but also both dead on 12:00:00
<Kamion> sladen: ?
<mdz> janimo: ok, I've revised, how does that look to you?
<Kamion> oh, heh
<jdub> pvanhoof: turn the positivity back on please
<pvanhoof> done, its on
<janimo> mdz, looking now
<sladen> Kamion: I reopened, assigned and replied to #47823 at the same moment
<pvanhoof> I didn't knew anybody can reject bugs
<mdz> janimo: oh, we should add a link to the release notes page in the wiki, so that you can update it later on
<janimo> mdz, any chace xubuntu gets linked from the main ubuntu.com page under related distros?
<mdz> janimo: should be, yes.  I'll check into it
<janimo> or we could wait itll the xubuntu site is in a better shape in a few days
<janimo> mdz, yes the notes look much better now, thanks ;)
<Kamion> lamont: do you want Kubuntu ports published? (have they been tested at all?)
<Riddell> Kamion: only report I've had is a fail on kubuntu sparc
<ploum> sladen: just saw your link about the dapper car !
<ploum> :-DS
<ploum> :-D
<Kamion> Riddell: sparc may well be failing for other reasons I suspect; fabbione asked me not to publish that for Ubuntu yet
<fabbione> Riddell: does your user realize that we do not support kubuntu?
<Riddell> fabbione: yes
<fabbione> ok
<fabbione> nobody ever even tested sparc/kubuntu
<fabbione> at least i didn't
<Riddell> so lets not publish that one yet :)
<fabbione> it's not published afaik
<Riddell> no
<Kamion> I don't mind publishing Kubuntu hppa/ia64 if they've at least been tested at some point relatively recently
<Kamion> although it would be kinda nice if the release images had been tested
<mdz> janimo: fire when ready (I'd change "these release notes" to "this announcement" in the email, but leave it the same in the wiki page)
<janimo> mdz, ah ok, I'll do that then. I was editing your announcemt so far.
<mdz> janimo: if you have more changes, that's fine.  I'm happy to read over them as well
<janimo> mdz, no it was just what's in the wiki but trimmed down, so the 'for details go to the wiki' make sense
<mdz> janimo: oh, that's fine too, if you want to craft a separate announcement
<nomed> janimo, could u Forward it to xubuntu-devel ?
<mdz> janimo: the release notes and announcement can be very close for Xubuntu ,though, since it's the first release
<mdz> janimo: more so than for {K,Ed,}Ubuntu
<janimo> mdz, right it will be what's on the wiki
<janimo> nomed, https://wiki.ubuntu.com/XubuntuDapperReleaseNotes
<nomed> k thanks
<Kamion> ok, I think just about all the trailing release images on cdimage.u.c are published now
<Kamion> lunchtime
<janimo> mdz, sent you the announcement for final review
<janimo> mdz at u.c
<dholbach> Riddell: can you set bug 11573 on your 'special' list?
<Ubugtu> Malone bug 11573 in gnome-utils "GNOME Dictionary program/applet preferences error" [Normal,Fix released]  http://launchpad.net/bugs/11573
<dholbach> oops
<dholbach> wrong bug
<dholbach> Riddell: bug 11753
<Ubugtu> Malone bug 11753 in Ubuntu "Arabic support severely broken" [Major,Needs info]  http://launchpad.net/bugs/11753
<dholbach> Riddell: it has a patch attached
<Riddell> dholbach: thanks, will do
<dholbach> cool
<netgrabber> hi, what is proposed for? do i need it? should i enable it? sorry for asking here on ubuntu noone knows this
<zul> heylo...congrats folks
<pitti> ogra: uh, bug 47834 sounds weird
<Ubugtu> Malone bug 47834 in xubuntu-meta "LTSP Users are allowed to shut down LTSP server" [Normal,Unconfirmed]  http://launchpad.net/bugs/47834
<ogra> pitti, thats a prob with xfce-session
<pitti> janimo ?
<ogra> pitti, gnome-session apparently asks gdm if the user is logged in locally ... xfce doesnt do that
<janimo> pitti, I need to look into it. default xubuntu install was not done with ltsp in mind 
<pitti> alright, thanks
<pygi> ivoks, another CUPS bug? :)
<ivoks> pygi: ?
<pygi> ivoks, bah, ignore
<ivoks> as allways :)
<mvo> can a python guru please look over http://people.ubuntu.com/~mvo/upgradeQuirks.diff ?
<Fujitsu> Aha.
<Fujitsu> Thank goodness you've fixed the nvidia-glx issue...
<pygi> ivoks, indeed
<moberg_> can someone point me to an example of how to use GConfChangeSet ?
* pitti curses at tetex-base which builds forever...
* Fujitsu wonders how people without broadband are going to upgrade.
* _ion wonders whether the LaTeX stuff has to be so huge.
<Fujitsu> TeTeX is really large...
<_ion> Couldn't the same stuff really be implemented in a smaller space?
<pitti> well, it's just that I suck and didn't manage to type some variables correctly in the first attempt...
<pitti> but debdiff'ing 230 MB of stuff takes long
<Fujitsu> Hahahah.
<zul> pitti: building cant be that bad
<pitti> zul: no, but building the source package is (well, the debs take an equal amount of time due to sheer number and hugeness of files)
<zul> pitti: building the kernel debs take a long time as well
* pitti hugs zul for doing hoary and breezy updates
<zul> heh...thanks...dapper soon as well
<zul> i think
<pitti> Kamion: yay, I finally got it right: http://paste.ubuntu-nl.org/14954
<stratus> mvo: is your patch buggy or what?
<pitti> Kamion: (the debian/rules hunk was generated automatically; it looks a bit weird, but I rather not touch it now)
<lamont> Kamion: given the announced support level for ports, I don't see any harm in publishing them - although if we wait until the weekend, I might be able to test them and know if they're broken or worth publishing....
<mvo> stratus: hello. just wnated some review before I commit it to my sourcetree
<stratus> mvo: unfortunately, i can't test that now. The dapperQuirks looks ok, but i dunno about how you call that in the 4 lines above. Are you sure that func() will be dapperQuirks in breezy->dapper upgrade?
<stratus> mvo: to turn debug easier, why not move that logging.debug from dapperQuirks() to above func() call?
<stratus> mvo: hopefully getattr() will take care about weird stuff like fooQuirks() call attempt, but..
<stratus> bbl
<pitti> jdub: so you didn't convert to a French after all?
<Kamion> pitti: that tetex-base patch looks fine to me
<pitti> Kamion: it took a while to get it right, but now installs and upgrades work fine
<pitti> Kamion: I uploaded it a while ago, can you please approve it?
<ivoks> pitti: so, should we package cups 1.2.1 for dapper?
<pitti> ivoks: I'm inclined to, but it needs testing
<sladen> mvo: https://wiki.ubuntu.com/DapperUpgrades  this should say  'update-manager -d' right?
<ivoks> pitti: i think we have lots of people who will be ready for testing
<wasabi_> there has got to be a way to turn off the log out fading.
<wasabi_> it just started taking 15 seconds Per Step on my ibook.
<Kamion> pitti: accepted
<Kamion> lamont: let's wait until you can test them at the weekend, then; we won't start building edgy CDs until edgy d-i is merged to the point of workingness anyway
<Kamion> s/won't/can't
<bddebian> Morning!
<bddebian> CONGRATS EVERYONE AND THANK YOU FOR ALL THE HARD WORK!!
<sfllaw> Whoooo!!!!!!!!!!
<bddebian> Hi sfllaw
* sfllaw hugs bddebian.
<Kamion> seb128: bug 47847 is a "WTF?" bug
<AlinuxOS> ;)
<Kamion> GError: Unable to load image-loading module: /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so: /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so: invalid ELF header
<AlinuxOS> bddebian, :D
<Kamion> is that just going to be a squashfs/unionfs error?
* bddebian likes WTF bugs :-)
<Kamion> I figure it's not actually gtk, we'd have noticed that immediately during testing
<seb128> Kamion: right, I would bet on file corruption, incorrect CD or something like that
<Kamion> ok - I've asked for more info - thanks
<janimo> Kamion, maybe in the stack trace ubiquity should include it's version number. He might have used an older cd?
<janimo> s/it's/its/
<giftnudel> sladen: as far as I understood, it should not (it's supposed to automatically show the new dist to the users)
<Kamion> janimo: I'd been thinking that for other reasons, but there is no known version of ubiquity that exhibits that problem anyway
<Kamion> so I'd want to look at it anyway
<Kamion> Keybuk's confirmed that the file's fine in at least the i386 squashfs
<Keybuk> http://news.bbc.co.uk/1/hi/england/norfolk/5037794.stm
<Keybuk> (OT)
<bddebian> Nice
<_ion> "Aina voi hvit"  an old Finnish proverb
<_ion> (One can lose every time)
<xice> shenki:its sort of unusable unstable
<xice> any way of toneing it down
<xice> soz wrong one
<mvo> Kamion: can you approve upload to dapper-updates?
<Kamion> mvo: yes
<mvo> Kamion: I have a brown paperbag fix for the 3rd party channel stuff in g-a-i, preparing a debdiff now
<Kamion> mvo: ok, sounds reasonable
<mvo> Kamion: well, to be fair the first applications started to come in only a few days before the release, but still it is pretty embarrassing
<jsgotangco> mvo: it can't be helped a fix is stil a fix :)
<nuzzy> congrats Ubuntu team!
<Kamion> nuzzy: thank you :-)
<nuzzy> one thing, a VERY minor one...the file /etc/debian_version still states "testing/unstable"...did you want that changed?
* Kamion tries to get into the habit of explicitly typing 'queue -R dapper' since dapper will no longer be the default queue once edgy opens ...
<Kamion> nuzzy: ye
<Kamion> yes
<Kamion> nuzzy: we've always had that, and it's deliberate; it reflects that we branch from Debian unstable. If you want the Ubuntu version, use lsb_release.
<nuzzy> aah!!
<tseng> lsb_release -a
<sivang> happy dapper day!
<seb128> Kamion: http://people.ubuntu.com/~seb128/evince.debdiff ... ok for a dapper-updates upload?
<sivang> seb128: are we uploading the nautilus fix as well or is it too early to ask? :)
<Kamion> seb128: that bug number is wrong - what's the real one?
<nuzzy> guys (and ladies)...I can't tell you how FANTASTIC this release looks!!  It runs like a top on my systems!  I work for Palm and know what it's like getting those bugs fixed and finally seeing the fruits of your labor come release time!
<jsgotangco> nice maybe we can work for good sync tools for eft =)
<nuzzy> ;-)
<seb128> Kamion: bug #47201 (I used the GNOME one)
<seb128> bug #47201
<Ubugtu> Malone bug 47201 in evince "Evince fails to open PDF files in FTP locations" [Unknown,Unconfirmed]  http://launchpad.net/bugs/47201
<seb128> the server must be loaded with dapper :p
<Kamion> seb128: thanks - ok to upload if you correct the changelog reference
<seb128> Kamion: ok, thank you
<Keybuk> Wow, six hours of silence, everyone is clearly enjoying dapper ...
<Keybuk> not a single "is edgy open yet?" :p
<tseng> Keybuk: I'm holding it in
<bddebian> IS EDGY OPEN YET?
<bddebian> :-)
<jsgotangco> lol
<jsgotangco> crack fiend
<_ion> Btw, is edgy open yet?
<Keybuk> edgy is open, but only for special people
<Keybuk> (note: it isn't)
<ivoks> anyone with fresh dapper install?
<Kamion> no, we're all running warty
<ivoks> no, seriously...
<ivoks> dist-upgrade from breezy works great
<ivoks> but fresh install has few glitches
<Keybuk> such as?
<seb128> Keybuk: if you want some questions like that, I've the "is that ok if we upload GNOME 2.14.2 to dapper-updates now" :p
<ivoks> nm-applet crashes on start
<jsgotangco> hmm??
<Keybuk> seb128: no ;)
<ivoks> but if started later, it works, but never shows up
<ivoks> it's missing icons/pixmaps
<Keybuk> ivoks: meh, dunno why that appears every now and then
<seb128> Keybuk: no, that's not ok, or no you don't want any question? ;)
<Keybuk> it's not in the default install, and I decided not to care anymore ;P
<ivoks> Keybuk: :)
<Keybuk> seb128: the latter
<ivoks> Keybuk: but it's in main :)
<Keybuk> seb128: though I'm buggered if I'm running queue that many times -- it'd take a week to process!
<seb128> Keybuk: fair enough :p
<ivoks> and with nvidia driver there are consoles (ctrl+alt+f1->f6) but not displayed - screen is off
<sivang> ah, edgy is open? interesting. /me wonders if to change sources.list and see what's there already :)
<jsgotangco> lol
* jsgotangco hugs sivang happy dapper day
* sivang hugs jsgotangco back 
<sivang> happy dapper day!
<Hobbsee> hehe
<Hobbsee> sivang: it is?
<Keybuk> ivoks: that's a known nvidia-glx bug
<jsgotangco> good night
<Keybuk> if we had the source, we'd investigate :)
<Yagisan> ivoks: nvidia works for me. just tested it
<ivoks> Keybuk: i know :)
<Keybuk> sivang: it isn't
<ivoks> Yagisan: care to share xorg.conf with me?
<sivang> Keybuk: ;)
<Yagisan> ivoks: sure. dcc ok ?
<ivoks> Yagisan: umm... i think yes
* sivang goes to check the spec list for edgy
<ivoks> thanks
<ivoks> Yagisan: this is upgrade from breezy, right?
<Kamion> please ignore the three dapper-changes mails that refer to breezy-updates; the uploads did go to the right place, the mails were just wrong
<sivang> JaneW: do you have a spec list like we had for daper, that we needed to register it into launchpad ?
<Yagisan> ivoks: no
<Yagisan> ivoks: from flight 7
<chris^> Hi
<Yagisan> ivoks: look like yours ?
<ivoks> Yagisan: no
<chris^> when will the Edgy Repos open? :D
<Yagisan> chris^: 2008
<chris^> -.-
<Kamion> chris^: two days after the last person asks ... ;-)
<Hobbsee> the more people that ask for them, the longer they'll take to open
<chris^> hrhr
<Hobbsee> haha @ Kamion 
<Yagisan> chris^: let them enjoy their release
<Kamion> mdz's comment last night was along the lines of "I don't want to poke Launchpad with sharp sticks on Thursday"
<Hobbsee> hehe - it'll get poked anyway, with all the new people...
<Kamion> new people are trivial; new distroreleases somewhat less so, as far as Launchpad's internals go
<Keybuk> whereas mdz's last comment today was "I'm going to bed" :)
<Hobbsee> Kamion: you underestimate the number of people who will file bugs, mostly with little information, and not having searched first.
<Keybuk> and, more importantly
<Keybuk> we've tested adding new people to launchpad
<Hobbsee> Keybuk: hehe, very wise of him
<nomed> isn't it possible to rsync from releases.u.c ?
<nomed> i'd like to rsync the file i already have :/
<nomed> but it seems i have to dwld the whole iso again ..
<Kamion> Hobbsee: no, I don't, I'm just saying that they're not likely to cause Launchpad to behave in unexpected ways.
<Hobbsee> ah okay
<Kamion> nomed: it is; rsync module 'releases'
<Hobbsee> hmmm.  i was sure i put a question mark at the end of my sentence before...maybe i didnt.
<Kamion> nomed: but rsync necessarily has fairly low use limits, so it may take you a while to get in
<Kamion> the rsync server can't deal with hundreds of people hitting it
<nomed> ahh k
<nomed> thanks for the infos
<ivoks> lol ok...
<ivoks> Keybuk: fwiw, nm-applet shows up in 24bit colorspace, but not in 16bit
<doko> hi tmarble
<ivoks> still no consoles :)
<Keybuk> ivoks: probably lack of icons then
<tmarble> doko: hello!
<dieman> oh that sucks on nm-applet
<Keybuk> WATCH ME CARE!
<Keybuk> Look, WATCH ME!
<ivoks> :)
<Keybuk> THERE I GO!  CARING!
<Keybuk> :p
<sivang> heh
<Hobbsee> oh dear.  who gave Keybuk permission to go insane?
<bddebian> hehe
<sivang> Keybuk: shouldn't you be taking a rest or something?
<bddebian> Hobbsee: I did
<Hobbsee> bddebian: ah.  
<Keybuk> I'm renaming network-manager to something beginning with 'g', so seb128 and dholbach can maintain it <g>
<ivoks> Keybuk: thank you for everything
<sivang> Hobbsee: nobody. he always have been.
* Hobbsee throws a koala at bddebian 
<bddebian> Keybuk: ;-)
<dieman> i wish i could convince th emirror to do more than 500mbps
<sivang> Keybuk: HA HA
<Hobbsee> sivang: hmmm...if you say so
<Hobbsee> lol!
<dieman> but for 5-6 year old hardware, thats not bad
<Keybuk> (in return, I'll guess I'll have to rename glibc to ulibc ...
<Hobbsee> Keybuk: and that leaves you with X?
<Hobbsee> :P
<Keybuk> oh, wait, we already have ulibc!  excellent
<sivang> hehe
<Keybuk> edgy will ship with ulibc, not glibc! :p)
<dholbach> Keybuk: forget it
<bddebian> doh
<Hobbsee> haha
<ivoks> Keybuk: merge it :)
<seb128> :)
* sivang apt-cache searches for ulibc
<Keybuk> sivang: it's an ickle one for embedded people
<Keybuk> oh, that's uclibc
<Keybuk> meh
<Hobbsee> cant believe how quiet and not-developmental this channel is now - i'm usually getting dark looks for talking by now...
<dholbach> "Ok fellas, we dropped glibc. See how you can handle it! Love. xx"
* sivang dicts for ickle
* Keybuk knew he shouldn't have had a drink before lunch
<ivoks> Keybuk: don't let on c distract you :)
<dholbach> Mail from Keybuk before being 2 weeks in holidays
<dieman> perhaps he wants to pick up libc from opensolaris
<dieman> or something
* sivang is curious what hair color will Keybuk have this conf.
<Keybuk> ivoks: or, indeed, an e
<Keybuk> sivang: I haven't decided yet ... I had a mohawk for the distro sprint
<sivang> again?? :-)
<Keybuk> sivang: http://www.urbandictionary.com/define.php?term=ickle
* sivang takes a look
<Hobbsee> Keybuk: orange?
<Keybuk> I could do orange to celebrate
<sivang> Keybuk: I need to hook up udict to my dict , it has far better explenations for all your brits slang :-)
<Hobbsee> Keybuk: or a combination of orange and yellow - mabye orange and yellow stripes?  :P
<\sh> congrats to the Ubuntu 6.06 Release :)
* sivang hugs \sh 
<Keybuk> sivang: the whole world will know two years time
<Keybuk> when we announce the "ickle iguana"
<dholbach> I wonder what happened of the Funky Ferret or the Sneezy Snail
<sivang> heh, a replacment for Grumpy ?
<\sh> Keybuk: when is "Smelly Smaug" coming?
<sivang> oh, I like this "...Seems to originate in England"
<sivang> (from urbandictionary)
* sivang is listening to "The Dark Side of The Moon" Pink Floyd et al
<Keybuk> \sh: 13.10
* \sh is listening to "Another kernel compile will kill my brain"
<Keybuk> (October 2013)
* Hobbsee is listening to her computer purr, and considering the keyboard as a pillow
<\sh> Keybuk: good date...so we can all read "The Hobbit" ;)
<sivang> anyway, time to go and re-install with the desktop-cd , it is so cool!!
<pitti> sivang: ubiquity is fun, isn't it? :)
<ivoks> :)
<sivang> pitti: not only fun, amazing is the word I had in mind when I first saw it yesterday :)
<pitti> mdz: did you enjoy your fried duck for lunch? :-P
<sivang> pitti: plus this layout of the livecd allows it to be a good container for all sort of rescue/backup tools ;-)
<mdz> pitti: fried duck?  I had salmon
<sivang> pitti: if someone lost his system, and had a backup he had done with hubackup, then he can take a desktop-cd , re-install his system from there, then using hubackup that could be shipped with the desktop-cd restore his home content.
<sfllaw> Roast duck would be pretty good though.  Maybe I should pop by Chinatown and have lunch there?
* dholbach was at a vegetarian burger place
<pitti> sfllaw: ask for a fried drake :)
<dholbach> pitti: they'll bring you a dragon
<pitti> mdz: don't take me too seriously today :)
<sfllaw> A mad one.
<Hobbsee> a fire breathing one :P
<Hobbsee> enjoy the release guys - i'm going to go sleep!
<sivang> night Hobbsee 
<dholbach> Hobbsee: good night
<\sh> ok...only for your information: kernel 2.6.15 and areca sata raid6 controller doesn't work properly :( 2.6.16 works without any problems
<\sh> I asked a company here from germany which is building our servers with this controller for a sponsored machine...I hope we can get such a machine for testing
<\sh> 2 dual core opterons 2.2GHz, 16GB RAM, 16x 500GB SATA disks
<segfault> hi
<segfault> :-)
<Keybuk> Kamion: ping
<Kamion> Keybuk: hi
<dieman> hah
<dieman> i went from 1.5k connections to 284 just by turning on 1 download per ip
<dieman> same amount of bw
<sivang> hmm, nice
<sivang> bash seems to know what paramters an executables receives
<sivang> how to hell does it do that? :)
* pitti points sivang to /etc/bash_completion.d/
* sivang pokes
<pitti> sivang: and /etc/bash_completion, of course
<sivang> I had dreamed about this feature, since when is it here?
<sivang> :-)
<pitti> sivang: whoa, since ages, really
<Burgwork> uhh, did Riddell and Kamion mean to upload to breezy-updates and not dapper-updates?
<pitti> sivang: you just have to enable it, it might be that doko enabled it by default in dapper
<sivang> pitti: probably
<pitti> Burgwork: according to the version numbers that was fine...
<sivang> pitti: I recalled it worked once and then disappeared, and now cam back - yay!
<mdz> Burgwork: the kubuntu-docs was definitely intended for breezy-updates
<mdz> and I expect Colin knew what he was doing also
<Burgwork> ok, just wondered
<Burgwork> I can see that being the kind of mistake tired people right after a release make
<sivang> pitti: you should probably add something for cdbs-edit-patch , I see dpatch has something
<pitti> yeah
<sivang> :)
<pitti> patches welcome :)
<sivang> pitti: yeah, I might even surprise myself and do something like that :)
<pygi> hey sivang 
<sivang> hey pygi 
<sivang> pygi: happy dapper day!
<pygi> sivang, same to you :)
<pygi> sivang, done any work on "edgy scope"?
<pygi> Btw. I can't remember do we have a product registered with LP, I know we have team
<sivang> pygi: not yet, RF been too demanding again, plus a national holiday, will get to it probably next week or on sunday
<Keybuk> Kamion: s'ok, was just seeing whether you'd left the office yet so I knew whether to leave the door on the catch or not
<pygi> sivang, oki, just so I know :)
<Keybuk> mdz: Colin knew what he was doing, sadly our queue tool didn't ;)  it put the package in the right place, but sent the mail to the wrong place
<Tonio_> hi
<wasabi> Congrats all.
<sivang> tritium: hey, just now saw your ping :-(
<sivang> tritium: I did not have to do nothing to make dapper work woth the SATA-PATA bridge
<sivang> tritium: worked out of the box with one of the ancient dailies I have installed from
<Kamion> Burgwork: as Keybuk said it was purely that the mail went to the wrong place
<seb128> carlos: do you use a spanish desktop? do you have that issue:https://launchpad.net/distros/ubuntu/+source/gnome-applets/+bug/47870 ?
<Ubugtu> Malone bug 47870 in gnome-applets "Incorrect date layout" [Normal,Unconfirmed]  
<Kamion> Burgwork: also note the dates on the uploads; they were uploaded quite some time ago, well before this release
<Burgwork> Kamion, ah, ok
<carlos> seb128: confirmed
<carlos> seb128: I guess it's an issue with the translation
<seb128> carlos: ok, thank you. Do you think it's a translation issue?
<carlos> seb128: yeah, the arguments need to change its order
<seb128> they should be using %x
<seb128> that would avoid that sort of error :p
<seb128> date_format = _("%a %b %e");
<desrt> i love when people do insane stuff like that
<carlos> seb128: I'm looking for the string to fix it
<desrt> isn't there a separate LC category for date format?
<carlos> desrt: yes
<carlos> LC_TIME
<desrt> and doesn't that effectively let LC_MESSAGES decide your date format?
* desrt throws hands in air and runs from room dramatically
<carlos> desrt: IMHO, is a bug with the application that adds it to the .po file instead of use directly LC_TIME
<desrt> carlos; i agree
<desrt> carlos; you should see gweather applet.  it's sheer comedy
<carlos> some translators argue that there are some broken locales
<desrt> it translates things like _("NEAREST_AIRPORT")
<carlos> and is easier to fix it using the .po file that get their locale data fixed....
<desrt> so gweather defaults to ottawa for me because my LC_MESSAGES is en_CA
<seb128> desrt: bugs like https://launchpad.net/distros/ubuntu/+source/gnome-applets/+bug/36392 ? :)
<Ubugtu> Malone bug 36392 in gnome-applets "weather applet gives incorrect "updating..." feedback." [Unknown,Unknown]  
<seb128> "Hitting "details" from context menu shows that my city is: "DEFAULT_LOCATION""
<desrt> hahah
<desrt> yes.  exactly.
<desrt> someone didn't translate DEFAULT_LOCATION in that locale
<carlos> desrt: well, I think that's a good use of .po files... but I guess it lacks a good description so translators stop using 'DEFAULT_LOCATION'
* seb128 asks the locale
<carlos> well, or the developer should change DEFAULT_LOCATION with another thing if it's not translated
<desrt> carlos; we have a nice translator comment for it
<desrt> iirc, the code checks if DEFAULT_LOCATION comes back from _() and defaults to some american city, ....
<carlos> desrt: then?
<carlos> how is that possible?
<desrt> i'm not sure.  something is broken, i guess :)
<desrt> maybe someone translated DEFAULT-LOCATION to DEFAULT_LOCATION or something :p
<carlos> then that's a problem of the translator
<carlos> ;-)
<desrt> pitti; g'morn
<desrt> pitti; g'night
<desrt> pitti; g'morn
<zul> pitti: ping...whats your email addy?
<pitti> hi desrt 
<pitti> zul: pitti@ubuntu.com
<desrt> seb128; the code has been changed _a lot_ recently....
<seb128> desrt: what? gweather?
<desrt> ya...
<seb128> I doubt of that ;)
<desrt> philipl has been going nuts
<seb128> or you mean "really recently"
<desrt> the file that that code used to live in doesn't even exist :p
<seb128> because I don't think he changed a lot during dapper cycle
<seb128> ah, k
<dieman> man
<dieman> the amount of downloaders using those 'open a bazillion connection' download managers is bothersom
<seb128> some crazy new cycle we have to catch with now than dapper is done ;)
<dieman> e
<desrt> the DEFAULT strings don't even appear in the code anymore :p
<zul> pitti: thanks
<desrt> (gnome-2-14 branch)
<desrt> seb128; my guess is as follows -- the default thing got (or rather, didn't get) translated, stored in gconf
<desrt> then read back from gconf from new code that didn't do the checking
<desrt> this is just wild guessing, though
<lucasvo> I have problem with a tetex package, I can't download it (http://pastebin.com/751756)
<lucasvo> It gives me a 404 error
<lucasvo> Failed to fetch http://au.archive.ubuntu.com/ubuntu/pool/main/t/tetex-base/tetex-base_3.0-15ubuntu1_all.deb  404 Not Found
<ogra> lucas, au. ???
<ogra> err lucasvo 
<ogra> lucasvo, from switzerland you shouldnt pull from au. ;)
<lucasvo> ogra: oh crap
<lucasvo> yes 
<lucasvo> ogra: it was ubuntu which selected the mirror
<lucasvo> I wanted english lang
<lucasvo> LANGUAGE=en_AU:en
<lucasvo>  :)
<ogra> well, thats your own fault then :)
<lucasvo> ogra: yup, but the 404 certainly not
<lucasvo> poor au people can't download the package
<lucasvo> (it is on the ch mirror)
<ogra> well then the mirror might be outdated ...
<lucasvo> you mean in a state with up to date package lists and not fully updated packages??
<lucasvo> how can one ask for support in edgy atm?
<kmon> hi everyone, thanks for dapper :)
<kagou> hi
<kermitX_> with the introduction of the server edition iso. should the "server" menu item in the alternate iso's been named something else to avoid confusion?
<jdong|coreduo> congrats on the release, everyone
<jdong|coreduo> elmo: you got a sec to talk about Backports?
<wasabi> https://launchpad.net/distros/ubuntu/dapper/+bug/1    Haha nice.
<Ubugtu> Malone bug 1 in Ubuntu Dapper "Microsoft has a majority market share" [Critical,Confirmed]  
* desrt marks that 'easy fix'
* desrt gets out the nukes
<_ion> I packaged picard. It's a great tool for fixing audio files' metadata. http://hassers.fi/ubuntu/dists/dapper/
<Burgwork> _ion, #ubuntu-motu and REVU are the places for tha
<_ion> burgwork: Ok, thanks.
<crimsun> pitti: ping(unlikely), some debdiffs at security-review
<sladen> sfllaw: did you see bug #47703 aswell?
<Ubugtu> Malone bug 47703 in gfxboot "No way to exit F6 <extra options> without reboot" [Normal,Confirmed]  http://launchpad.net/bugs/47703
<pitti> crimsun: pong, I saw them
<crimsun> pitti: ok, thanks
<pitti> crimsun: sorry, I'll look at it tomorrow morning, promised
<seb128> pitti: stop working and go get some dapper drink ;)
<pitti> seb128: I'm hacking PostgreSQL again, which I consider free time :)
<seb128> pitti: ahah :)
<bddebian> heh
<ajmitch> pitti: you never stop, do you? :)
* bddebian wouldn't either if he had a clue what to do :-(
<pitti> ajmitch: well, I do, but not yet :)
<ogra> seb128, what are you doing here btw ?  :)
<pitti> ajmitch: after all these days of testing and installing I want to code again
<pitti> :)
<ajmitch> pitti: makes sense
<ogra> seb128, stop working and go get some dapper drink ;)
<pitti> even if it's only Perl :)
<ajmitch> pitti: nasty
<ajmitch> ogra: shouldn't you be doing the same?
<seb128> ogra: I went to do some sport, had diner and started my IRC in case dholbach was around but he's not :p
<ogra> he's gone drinking
<ogra> i think :)
<seb128> ogra: but right, I will get some drink and watch some TV soon ;)
<ogra> good plan
<HiddenWolf> I'm suprized that there is anyone here at all. Aren't there parties everywhere?
<sfllaw-tv> sladen: I did see that bug.  And reproduced it here.
* mvo hugs seb1
<mvo> too late
<LaserJock> mvo: hehe, got any free time?
<sfllaw-tv> HiddenWolf: It's the middle of the week.  The Montreal party is on Sunday.
<HiddenWolf> sfllaw-tv: ah, i'm on a student schedule, weekend runs from thursday to monday. :)
<HiddenWolf> ;)
<sfllaw-tv> Crazy!
<ajmitch> heh
<ajmitch> HiddenWolf: and recovery is tuesday/wednesday?
<HiddenWolf> ajmitch: sometimes. ;) Although I must admit I'll be pulling an allnighter to finish a project tonight.
<ptlo> guys, congratz for the release and the hard work you've put in it, and a big thank you from yet another happy user
<pitti> \o/
<sladen> sfllaw-tv: already, okay.  it just that you didn't subscribe
<sladen> sfllaw-tv: could you possibley subscribe to it and say that you've managed to reproduce it;  otherwise it just looks like triage
<dieman> so like, was 915resolution to be banished with this x release, or the continued need to use it isn't surprising?
<sfllaw> sladen: Uhm.  That _was_ triage.
<crimsun> dieman: if it was to be banished, that'd be news to me
<sfllaw> sladen: I reproduced it trivially and switched it over.
<sfllaw> sladen: Does that not happen to you?
<dieman> crimsun: ok
<dieman> i was jsut surprised since 915resolution is only in unverse
<dieman> and i just installed a new laptop that required it
<dieman> thought it was weird
<bddebian> Later folks, Congrats again!
<ProN00b> do you realize that a worm that spreads to linux desktops is would be a threat to linux at the moment ?
<LaserJock> ProN00b: I would think "worm that spreads to linux desktops" would imply "threat to linux" by definition
<ProN00b> then why do you open ports by default
<Burgwork> ProN00b, ubuntu has not open ports
<ProN00b> tcp        0      0 127.0.0.1:58732         0.0.0.0:*               LISTEN     4433/python
<ProN00b> tcp        0      0 127.0.0.1:36884         0.0.0.0:*               LISTEN     4427/hpiod
<ProN00b> tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN     4489/cupsd
<pitti> ProN00b: localhost only :)
<ProN00b> hmm
<ProN00b> hmm
<ProN00b> ok
<ProN00b> udp        0      0 0.0.0.0:68              0.0.0.0:*                          3717/dhclient3
<ProN00b> how do i disable the dhclient3 ?
<dieman> ProN00b: you may want to ask these questions on #ubuntu
<dieman> (ie: see the topic)
<ProN00b> dieman, too much spam there
<ProN00b> ^___^
* dsas mutters something about Alanis Morisette
<KaiL> hmm....
<KaiL> so finally 12 hours after heise.de posted the news, it's time for first results...
<KaiL> Bugs: rather a few people having problems - no really common issues. Way more people are impressed how it works
<KaiL> Stability: it isn't perfect but works much better, than most I've seen before
<KaiL> Lokalisations: there something went REALLY wrong with dapper. Overall the localisations are imho not really good
<HiddenWolf> KaiL: localisations are the responsibility of the local team, in this case ubuntu-de
<HiddenWolf> KaiL: there have been issues with unskilled translators for some locales
<HiddenWolf> KaiL: unfortunate indeed
<KaiL> HiddenWolf, well, there was a VERY late change in gnome-session, which really sucks
<KaiL> afaik even after the language-pack-Freeze
<KaiL> ..which explans the "Quit" in the System-Menu...
<jdong|coreduo> well, we're gonna be refreshing translations via dapper-updates, right?
<mdke_> yes
<mdke> monthly
<KaiL> but the CD has the incomplete translation... imho not a very good solution
<mdke> KaiL: that's life
<mdke> the translation infrastructure came into place very late for dapper
<KaiL> oh, and VERY impressive work from the Serbian localisation team
<KaiL> 44 people, who moved their language from 45% to 95%
<KaiL> would be great, if such teams could be found for other languages too...
<mdke> i'm sure it will happen
<mdke> there are lots of ideas around
<KaiL> chances, that there will be more time for i18n work for edgy?
<mdke> what do you mean?
<KaiL> as you said, the very late infrastructure
<KaiL> I don't know, if there will be any changes with edgy?
<mdke> well, the infrastructure is now in place
<mdke> i would have thought it will be easy for edgy
<dsas> It'll just be dependant on the time issue, being the whole cycle is only four months.
<KaiL> would be cool, if we could get some 100%-languages ;)
<mdke> KaiL: quality is more important
<KaiL> make it 5 and release in 2006-11-09 ;)
<KaiL> mdke, shure, but I don't think, this shouldn't be a problem for languages, which are currently above 2/3
<KaiL> uhm.. one "not" to much ;)
<mdke> yeah, quality is the biggest problem we have to look at at the moment, I think
<mdke> quantity isn't so important because most of the user interfaces are translated in many languages
<mdke> anyway, this is a -translators topic
<KaiL> another issue are the desktop-guides, which are very often only partly translated and even worse sometimes outdated
<KaiL> other technical issue: graphical config tools for every kind of dialup connections
<KaiL> ISDN, DSL (pppoe) and such
<KaiL> and a nice idea, I just had: a "post-install-Wizzard", which guides the user through all this little things to do, to make ubuntu perfect
<ogra> ARGH
<doko> KaiL: translations in Ubuntu/dapper are updated on a regular basis. just wait for the next update
<KaiL> ogra, ? ;)
* mdke consoles ogra 
<ogra> KaiL, you said post install wizard
<KaiL> ..back to my idea: this tool could ask the user, if he wants the unfree 3D drivers and if only install them with one click. Or complete the language-packs if installing from desktop-cd, or ask to enable universe...
<dsas> heh
<KaiL> just all this little things, which very much users will want or even need to do right after install
<mdke> KaiL: amazingly, you're not the first to have had this idea
<KaiL> mdke, guessed so ;)
<ogra> probably the 78126585th
<mdke> the EasyUbuntu developers also shared it, and automatix, and a 1000 sounder posters who never did anything about it
<ogra> even if someone does it, i doubt we'd include it
#ubuntu-devel 2006-06-02
<KaiL> those tools so into that direction, but this could be done way more intelligent
<KaiL> s/so/go/
<crimsun> doesn't g-a-i enable repos automatically?
<ogra> yep
<mdke> the proper way to implement these things in my opinion is not via a program which does everything you think users might want, but ensuring that the users are given the choice to install/activate things when they actually need it.
<KaiL> crimsun, if you click that icon, yes
<mdke> catch-all programs are just not the way forward
<ogra> and first run wizards in particular here
<crimsun> sorry, but I think I'm missing the gist of what KaiL's suggesting
<crimsun> afaict, at least the repos and the video drivers issues are moot
<KaiL> really?
<crimsun> well, yes, doesn't g-a-i address the repos?
<KaiL> I guess arround 80% of the work in the support chats is about how to enable 3D drivers (esp. the damn ATI one)
<crimsun> and l-r-m has most non-free drivers
<KaiL> and don#t ask me, how many questions are to be answered with "enable universe"
<KaiL> l-r-m has them, that's not the problem - but they aren't enabled
<crimsun> and they shouldn't be by default if they're non-free, at least imo
<KaiL> and the users really need to be informed, that they are there, BEFORE browsing to nvidia.com or ati.com...
<crimsun> is that really something Ubuntu can change? Regardless of how often one says "we include $foo", people are still going to run off and prefer $foo from location $bar
<KaiL> with most other systems, you need to dl the driver from the chip vendor, so the users do this "automatically" ;)
<KaiL> for that an icon on the desktop "enable proprietary 3d driver"
<KaiL> clicking on that also removes this icon
<ogra> thats bad UI design 
<crimsun> I agree
<crimsun> that and it adds unnecessary complexity to first-run or whatever
<ogra> you force the user to click it, regardless if he wants the drivers or not, just to make that icon go away
<KaiL> of just add an X-config-tool, which could also be used for multiscreen config and to give monitor timings manually ;)
<ogra> i think thats in the SoC queue
<KaiL> ..and this tool gets a simple "enable proprietary driver" switch (might be even required for some cards to have multiscreen - ATI X1xxx...)
<KaiL> ogra, yes, one of the usefull SoC ideas
<KaiL> "expose without hardware accelleration" is one of the useless ones ;)
<KaiL> putting gstreamer0.10-fluendo-mp3 into main or restricted (don#t know about it's licence) might also be something to think about - just to stop the begging for MP3...
<KaiL> it's one of the very very rare situations, where saying "it's unfree, so we won't use it" only scares of users imho
<mirak> is there a way to run the ubuntu dekstop iso installer from an already installed ubuntu ? I want to install to another partition of my hard drive
<mdke> alternatively, adding an option to the music player which asks the user if they want to install the codec when they try and play an mp3, that would work.
<mdke> mirak: you just reboot with the cd in the drive. But ask on #ubuntu if you need help
<Burgwork> have you guys seen the CommonHooker on the wiki (not my name)
<mirak> mdke: I don't want to reboot nor burn a cd
<mirak> that's why I ask
<mdke> mirak: as I say, ask in #ubuntu if you need help
<mirak> mdke: nobody answer
<KaiL> mdke, asking might be a solution, where the codec can't be shipped, yes
<mirak> I just need to now if that's a particular application, or if I could install the .deb
<KaiL> maybe that could be even used for rare codecs, you won't need to have installed normally
<mdke> mirak: I'm afraid that if nobody answers, there is nothing else we can do. You could try the forums or mailing lists
<mirak> mdke: I know I can use special kernels to boot on iso
<mirak> I will do that probably
<KaiL> mdke, specific for mp3, fluendo could also help to reeable features like "burn mp3 files as audio cd"
<KaiL> afaik there's currently no really good option for that
<mdke> dude, all those features are available
<mdke> you just need to install the plugin, that's all
<mdke> both rhythmbox and serpentine will do that
<mdke> and banshee... etc
<KaiL> ah, ok
<KaiL> I thought, there was something... 
<KaiL> ah, it was only a problem to create mp3 files - not really something, we want to support ;)
<jono> hey
<BenC> so is edgy ready for uploads?
<pitti> BenC: no, it's not open yet
<pitti> BenC: dapper-security awaits fixes :)
<BenC> is it the 4th or 6th that it opens?
* pitti doesn't know
<BenC> pitti: did zul send you the hoary changelog?
<pitti> BenC: yes, he did
<BenC> pitti: Yep, preparing dapper upload right now actually
<BenC> pitti: I checked the diff/dpatch's/build, so if it's ok with you, give him the go ahead and he can upload it
<ajmitch> BenC: you'll be switching your git tree over to 2.6.17 quite soon then?
<BenC> ajmitch: soon? It's already done and building on all our architectures
<pitti> BenC: erm, sorry, I meant dapper-updates is open; dapper-security is still in progress
<BenC> all my machines are running 2.6.17-git now
<pitti> BenC: yep, wil do
<ajmitch> hm, ok
<BenC> pitti: Should I upload to -updates or -security?
* ajmitch didn't see that on the kernel.org/git page
<pitti> BenC: -security, but please don't upload yet
<ajmitch> but got clone is still running here, so I'll find out soon :)
<pitti> BenC: elmo is working on getting d-security going; I'll ping you when the first test is successful
<BenC> ajmitch: ubuntu-2.6 is 2.6.17-git synced now, and ubuntu-dapper.git is the dapper tree of course :)
<ajmitch> BenC: right :)
<BenC> pitti: ok
<BenC> ajmitch: as soon as edgy opens, I'll have it uploaded with linux-restricted-modules and linux-meta
<ajmitch> great
<BenC> I want to be the first to unleash chaos on edgy
<ajmitch> darn
<ajmitch> I wanted to be the first with a sysvinit upload
<ajmitch> but the kernel should come first
<ajmitch> then we can break the rest
<pitti> good night everyone
<Burgwork> ajmitch, that a SELinux fix for sysvinti?
<ajmitch> Burgwork: sure
<ajmitch> I might as well start on it now
<ajmitch> at least until sysvinit is dropped & replaced with something completely different :)
<Burgwork> ajmitch, bring on the crack!
<LaserJock> or the new Edubuntu term "boo"
<jsgotangco> boo?
<jsgotangco> hmm
<jsgotangco> would a static 32bit skype work on an amd64 install
<ajmitch> jsgotangco: it should
<HrdwrBoB> yeah
<ajmitch> other 32-bit apps like games, vmware, etc work fine
<jsgotangco> alright
* jsgotangco burns the amd64 iso
<BenC> jsgotangco: even a dynamic 32-bit skype should work
<HrdwrBoB> if you instal ia32-libs
<BenC> right
<jsgotangco> thanks i should try that
<HrdwrBoB> you may run into random problems though (eg vmware tries to load the 64bit pam libs
<BenC> hmm, haven't had that problem with vmware
<ajmitch> neither have I
<ajmitch> BenC: no joy with sparc64 & 2.6.17 yet?
<BenC> ajmitch: sparc64 is working, it's just my e3k type machine that isn't
<ajmitch> right
<BenC> 6 cpu's with non-zero based id's tends to cause problems every so often in the kernel
<ajmitch> similar to what was happening with the T1?
<BenC> programmers always expect the boot cpu to be id=0 :)
<BenC> don't think so, I think that was different
<ajmitch> sigh, might be quicker for me to tar up the git tree & copy it to my home box
<ajmitch> rsync is taking an age
<Evaso2> hi guys, is anybody working on the pptp network-manager plugins packaging?
<dieman> the mirror storm is subsiding
<ajmitch> dieman: got any stats yet?
<dieman> ive got logs
<dieman> i could make up some stats
<dieman> any suggestions on stats applications
<dieman> aside from having awstats chew on it?
<dieman> Server uptime: 6 hours 40 minutes 55 seconds
<dieman> Total accesses: 117548 - Total Traffic: 888.2 GB
<dieman> theres info since the last tweak i made
<dieman> it was doing about 500mbps all day
<dieman> its not as heavy duty as the releases.u.c setup
<ajmitch> not bad
<ajmitch> I wonder how the .se mirror fared this time
<dieman> probally better
<dieman> i know that machine is like 2-3x more beefy
<dieman> im doing this with a dual 933 p3 and 1gb ram
<dieman> and a pile of disk
<ajmitch> for breezy it was running at about 2.5Gbps for awhile
<dieman> yeah
<crimsun> if se. was hosting the leaked beta iso, it probably got hammered
<ajmitch> heh
<ajmitch> crimsun: 0-day?
<dieman> heh
<crimsun> those wacky kids
<dieman> im guessing whoever runs lighttpd
<dieman> rather than apache
<dieman> depending on config, too
<dieman> those *damn* download managerts though
<dieman> i set our box up for 1 connection per ip
<dieman> and limited connections for 10/min/ip
<ajmitch> poor kids who can't spawn 20 connections at a time
<dieman> i was getting 80 connects per second
<dieman> until i did that
<dieman> then it was like 8 connects/sec
<jsgotangco> heh
<dieman> win 2
<maswan> ajmitch: only about 2Gbit/s, the rest was non-mirror university traffic. but clise. :)
<maswan> http://www.acc.umu.se/technical/statistics/ftp/monitordata/
<maswan> http://farbror.acc.umu.se/stats/monitordata/index.shtml
<maswan> that was today. the second graph delivered two isos out of ram. :)
<ajmitch> not bad :)
<maswan> it took some work, but we did manage to get our 2Gbit/s pretty full after a while.
<ajmitch> the bottom graphs on the first url show the peka when breezy was released quite nicely
<ajmitch> I wonder how it'll look after a week or two for dapper
<maswan> yeah, and before that you can make out sarge. the hoary peak is smaller though, but that's partially rrd's fault
* jsgotangco wows at saimei
<maswan> farbror is the most impressive one, this round. :)
<jsgotangco> yeah
<maswan> I wish I would someday have enough to meet demand, so one coudl see how high that peak would be.
<crimsun> fabbione: ping (unlikely)
<fabbione> crimsun: ?
<fabbione> i am heading to bed right now..
<fabbione> so better be fast
<crimsun> fabbione: sorry, was going to ask if you can eyeball a free_irq/iounmap issue on sparc for me
<crimsun> s/issue/fix/
<crimsun> I can paste in -kernel
<fabbione> crimsun: not now. i am too drunk
<fabbione> tomorrow.. maybe
<fabbione> or file a bug in malone, even better
<crimsun> oh, ok. Thanks, sleep well!
<fabbione> assign it to me and tomorrow we will look at it
<crimsun> thanks
<bddebian> Howdy
<GameOver69> hey can someone help me with network manager
<GameOver69> it seems to no longer find any of my wirelness hardware, thus no networks to choose from
<Burgundavia> GameOver69: please try in #ubuntu
<Burgundavia> this is not a support channel
<GameOver69> Burgundavia, i did but no one responded
<Burgundavia> I would try the forums or the mailing list
<axisys> hi all eversince I upgraded to dapper my gnomenaker does not work.. i get this error message.http://pastebin.com/752583
<axisys> gnomebaker rather
<zul> hey
<Burgundavia> axisys: this is not a support channel, please use #ubuntu
<bddebian> heya zul
<zul> hey bddebian 
<ajmitch> zul!
<axisys> Burgundavia: ubuntu chnl suggested i bring it up to this chnl
<axisys> i also see this issue in the forum 
<Burgundavia> axisys: that is a bug, please file a bug
<Burgundavia> axisys: who suggested it to you?
<axisys> delire
<jsgotangco> axisys: it won't get noticed if you do it in a channel, it will have better coverage in a bug list
<jsgotangco> because it'll appear in the maintainer's inbox
<zul> ajmitch!
<bddebian> Heya tseng
<tseng> hi
<ajmitch> hi tseng 
<tseng> hi ajmitch 
<Burgundavia> does anybody have an rsync line to get my rc image to final?
<zul> nope..
<ajmitch> Burgundavia: rsync to the latest daily build, perhaps
<ajmitch> since that's what I grabbed
<Burgundavia> ajmitch: daily-live no longer seems to be wokring
<ajmitch> ah
<delire> Burgundavia: has there been any talk of bug-submission-automation from Gnome applications, where if a related process has segfaulted/failed, captured output is submitted at the users consent? IIRC Kde has something of this ilk.
<Burgundavia> delire: yes, and it is in the works for edgy
<delire> great, it is very hard to convince new users to submit bugs. they get as far as malone and shy away.
<LaserJock> delire: do you give them the specific url for a new bug?
<delire> LaserJock: i have in the past but only on the odd occassion does it reach submission.
<delire> anyway, it's extremely late here. i'm off. congratulations. a stellar release ;)
<Burgundavia> oh joy ff and tb 1.5.0.4
<jdong|coreduo> yeah, wonderful isn't it?
<jdong|coreduo> poor security team
<dholbach> good morning, party folks! :-)
<TheMuso> Hey dholbach.
<dholbach> heya TheMuso
<dholbach> orca as default for 2.16.x, eh?
<TheMuso> Indeed.
<dholbach> sounds like a good idea, we got it in already :)
<TheMuso> Yep.
* TheMuso is itching for edgy so he can update orca in universe. :)
<dholbach> main! we should try to move it to main :-)
<Burgundavia> TheMuso: is it worth my time to form some contacts with disabled groups here in Victoria for sustained testing?
<Burgundavia> ie: over the course of a release
<TheMuso> Burgundavia: Yes please.
<TheMuso> dholbach: Lets get it updated first. :)
<dholbach> yeah
* ajmitch wants f-spot in main! :)
<Burgundavia> ajmitch: I would go for that
<Burgundavia> f-spot and tomboy
<ajmitch> yeah, they're on mdz's ideas list
<ajmitch> so I think they;re good candidates
<Burgundavia> also upstream is debating them
<Burgundavia> beagle might be a good target for edgy
<Burgundavia> and NM
<Burgundavia> actually, I thinkt he dapper release is going to carry a lot of really good people to us
<dsas> wasn't nm a target for breezy and dapper? <ducks>
<HiddenWolf> Burgundavia: please, beagle in the default install? we just got memory consumption down a few MB...
<Burgundavia> dsas: yes, it was
<Burgundavia> it still has issues
<Burgundavia> HiddenWolf: well, we did for an obivious reason :)
<dsas> Burgundavia: Yes, it still doesn't work for me :(
<Burgundavia> it works for me, it just breaks with static IPs and few other corner cases
<LaserJock> Burgundavia: corner case?
<dsas> Well, it works for me until I try and use WEP etc. So it's probably more of a wpasupplicant issue.
<LaserJock> Burgundavia: I don't have any computers that don't have static IPs
<Burgundavia> yep
<ajmitch> LaserJock: you're a special case though :)
<ivoks> very special case :)
<Burgundavia> I ran into it at a client site, where they had no DHCP
<Burgundavia> very annoying
<LaserJock> ajmitch: I have a hard time believing that, but whatever
<LaserJock> :-)
* bgertzfield zzz
<LaserJock> I'd have a hard time with DHCP, "what the heck? what is my IP?"
<ivoks> LaserJock: create reservations for IPs
<ivoks> urgh... laptop battery
<Burgundavia> TheMuso: doesn't have to be GPL
<TheMuso> Burgundavia: Right.
<TheMuso> I just don't like forks in an area where everybody is trying to unify development as much as possible.
<TheMuso> And, he has done some work for IBM.
<Burgundavia> LSR is an IBM thing?
* TheMuso may be too sinical.
<TheMuso> Yep.
<Burgundavia> hence why they are unwilling to work on the Sun backed Orca
<TheMuso> And as far as I have read elsewhere, it is free for non-commercial use.
<TheMuso> Thats true.
<TheMuso> I guess I am just getting annoyed at the fact that there is more fragmentation in the accessibility for GNOME/KDE.
<TheMuso> Where does the CPL stand in terms of re-distribution anyway?
<Burgundavia> no idea
<TheMuso> hmmm ok
<hendry> is Ubuntu also moving to oftc?
<dholbach> no
<pitti> Good morning
<ajmitch> morning pitti 
<hendry> oh great
<ajmitch> and good morning pitti_ :)
<hendry> freenode and oftec
<kagou> hi
<HiddenWolf> btw, how are the download servers holding up?
<Burgundavia> https://wiki.ubuntu.com/KubuntuOEMRedistributionTools <-- hmm, interesting
<ajmitch> a SoC spec?
<Burgundavia> yep
<Burgundavia> I like the 2nd part
<jsgotangco> interesting
<Burgundavia> would be nice if the 2nd part was toolkit agnostic
* ajmitch gets back to writing some more spec
<jdub> Burgundavia: we could do that by launching sabayon during the oem install process :)
<jsgotangco> oui?
<Burgundavia> jdub: that would be very cool. The part that really grabbed was the idea of building an iso at the end of the process
<jdub> that's not the meaning of 'disk images'
<Burgundavia> ah
<jdub> the OEM installer is for setting up an HDD image
<jdub> which is then replicated for inclusion in each device
<jsgotangco> ahhh
<Burgundavia> ok, cool
* jsgotangco wasn't able to check this release's OEM methodology
<jdub> mildly insane: installing in vmware from ubuntu-alternate image while the image is being downloaded :-)
<seb128> hey jdub
<jdub> morning seb128!
<ajmitch> evening jdub 
<jdub> morning ajmitch!
* Hobbsee winces.  morning?
<seb128> jdub: any news about GUADEC?
<jdub> oh poo, i totally forgot to mail quim
<jdub> i'll do that right now
<seb128> so it was somewhat useful to ask ;)
<jdub> yeah!
<seb128> infinity, Kamion, mdz: I've just uploaded pessulus 0.9.2 to dapper-updates, don't get scared by the new version, we ship it to universe but that's a GNOME component since 2.14 and that version is a tarball with translations updates only for GNOME 2.14.2
<Fujitsu> Yay for pessulus...
* vuntz|work hugs seb128
* seb128 hugs vuntz|work
<ajmitch> yay, planet ubuntu^Wmdke
<seb128> vuntz|work: you like when we talk about pessulus, don't you? ;)
<vuntz|work> seb128: yes. It gets highlighted :-)
<Fujitsu> pessulus is a really Good Thing :D
<seb128> ah ah
<jsgotangco> ajmitch: horay for his pybloxom hehehe
<kagou> do we know how large is ubuntu dapper by section (main / universe / ...) with or without sources ?
<jsgotangco> vuntz|work: you'll get locked in a room by ogra for pessulus in edubuntu soon =)
<vuntz|work> jsgotangco: thanks for telling me. Now I know I have to run :-)
* vuntz|work looks at ogra
<sivang> re all
<mdz> mvo: how are we doing with the dist-upgrader? ready to switch it on?
<Fujitsu> Heheh.
<Fujitsu> The big red switch, this time?
<mvo> mdz: its uploaded and waiting for approval
<mdz> it remains to be seen how big and red it is; we've never thrown this particular switch before
<mdz> mvo: oh, ok
<mvo> mdz: it did a lot of testing last night, it looks all good
* mvo is ready to press is small red button then :)
<mvo> s/is/his/
<dholbach> mvo: judging by the amounts of new comments on the blog post about it ( http://daniel.holba.ch/blog/?p=14#comments ), everybody has upgraded already :)
<mdz> mvo: hmm, I don't see it in the queue output
<jsgotangco> i'd try out that red switch later
<mvo> mdz: I got:
<mvo> Accepted:
<mvo>  OK: dist-upgrader_20060601.1853_all.tar.gz
<mvo> This upload awaits approval by a distro manager
<mdz> oh, right, it'll be in the unapproved queue
<mvo> dholbach: is everybody happy too ;) ?
<mdz> EEK
<mdz>     assert self.sources or self.builds
<mdz> AssertionError
<jdub> norty big red switch!
<mvo> dholbach: woah, that are a lot of comments - are those the most comments so far? or did the "everybody should come to my party" blog generate more?
<mvo> mdz: *ick* 
<Fujitsu> Hi jdub.
<dholbach> mvo: the "come to the party" folks mailed me personally but they're a huge lot as well
<ajmitch> dholbach: 90% support requests? :)
<jdub> morning!
<sivang> morning jdub , how you been doing?
* sivang wishes happy the day after dapper day
<sivang> *everyone
* Fujitsu wishes sivang the same.
<jdub> ok, though suddenly i'm not having much luck with networking in vmware-player
<mvo> jdub: uhhh, what happend?
<jdub> i'm set up for bridged, but i'm not getting dhcp love in the installer
<Fujitsu> :(
* jdub wonders if it's a vicious atheros/bridging fascism issue
<infinity> jdub: Is the interface up?  (doesn't need to have an IP)
<Aegir_> Is the interface you're bridging it with up? I had a lot of problems with that on my roaming laptop.
<infinity> jdub: The vmnet bridge doesn't like binding to downed interfaces.
<Aegir_> Bah, you beat me to it, infinity, Damn TV...
<jdub> yeah
<mdz> mvo: did you get an email from it?
<jdub> ath0 == default route
<mdz> I think it blew up before processing it
* mvo checks mail
<mdz> mvo: it's dying because it's trying to print the source package name
* jdub quickly tries eth0
<mvo> mdz: no mail :/
<infinity> mdz: I've summoned Kinnison from our other conversation. :)
<Kinnison> mdz: Can you /msg me the queue cmdline you used?
<mdz> Kinnison: queue accept 40661
<mdz> mvo: do you normally upload this differently?
<Kinnison> ooh shiny
<Kinnison> that's a good bug
<infinity> mdz: Normally, the queue tool would never have to touch it, so it would have been fine until now.
<mvo> mdz: I don't think so
<mdz> Kinnison: queue fetch fails in similar fashion
<jdub> bah
<Kinnison> mdz: Yes, because there's no source package or build for it to work out what's going on
<jdub> bridged works with eth0
<Kinnison> mdz: It's a bad assumption in the queue tool
<infinity> jdub: Oh, were you bridging the wireless?
<mdz> Kinnison: that's how it looked to me as well
<infinity> jdub: That doesn't work so well, IME.
* Kinnison is looking at it now
<jdub> infinity: yeah, most don't do promisc (or very well)
<jdub> bum, i was asked to confirm disk changes and enter a root password :|
<jdub> http://people.ubuntu.com/~jdub/random/ks.cfg
<Kinnison> mdz: Right, I think I can come up with a fix, I'm just preparing a tree to try it in
<mdz> Kinnison: cool
* Pig|2old is back (gone 00:04:14)
* Pig|2old is away: I'm busy
* Pig|2old is back (gone 00:00:09)
<dholbach> Pig|2old: please turn off that script
<Hobbsee> hehe.  i was counting the seconds till someone said that...
<Kinnison> mdz: Fix written, running test-suite now
* mvo hugs Kinnison
* Fujitsu hugs the channel.
* Kinnison snuggles mvo
* Kinnison kicks emacs and it saves this time
* Kinnison re-runs the test suite
<Kamion> kermitX_: server menu item> yes, it should, there's been a bug filed about that for a while; I imagine I'll rename that for edgy
<Kinnison> mdz: tests look good, generating diff for review
<infinity> Kamion: The F3 text should be ammended to say something like "If you're currently trapped in the evil known as gfxboot, hit 'Esc' to exit before running these special boot options"
<Kinnison> mdz: This changes the messages from queue slightly
<infinity> Kamion: Or, make gfxboot DTRT with them.  Whichever.
<Kinnison> mdz: instead of "Accepting foo" you'll get "Accepting foo/1.0-1 (source)" and similar
<mdz> Kinnison: that's fine
<mdz> Kinnison: ready to test with mvo's upload then?
<Kinnison> mdz: Once I've had stevea glance over the diff, sure
<jdub> the graphical installer is pretty zippy under vmware
<Kinnison> jdub: aye, it's so cute isn't it?
<infinity> jdub: That's because it does very little screen updating.
<infinity> jdub: Ironically, this makes it faster than d-i in vmware.
<siretart> I don't know if anyone already noticed, but http://archive.ubuntu.com/ubuntu/dists/dists/ doesn't make too much sense, no?
* highvoltage thinks it's just perceived to be faster than the text-mode installer
<jdub> awesomeness has no irony!
<infinity> jdub: (Though, d-i with "debian-installer/framebuffer=false" speeds up quite a bit)
<Kinnison> siretart: ooh thanks
<Kinnison> infinity: fancy fixing that hiccough?
<Kinnison> infinity: probably an interrupted publishing run?
<infinity> highvoltage: No, text-mode in vmware really is painful, because the constrant screen redraws make vmware's VGA emulation a sad panda.
<infinity> Kinnison: Err..
<Kinnison> infinity: we appear to have grown a dists/ in dists/ :-)
<Kamion> infinity: it all needs to be adapted for gfxboot, modern reality, etc.
<Kamion> there's an open bug about all that, I think
<infinity> Kinnison: Yeah, I see that, but how would an interrupted publisher run have done that?
<siretart> looks rather like a botched rsync call..
<Kamion> highvoltage: it's actually faster anyway - try with a stopwatch; it's doing less work overall
<infinity> siretart: No, the main archive looks like that.
<infinity> siretart: No rsync involved.
<siretart> hm. I see..
<Kamion> yeah, but it looks like somebody rsynced dists into dists on drescher a while back; we noticed it yesterday too
<Kamion> (cprov commented on it)
<Kinnison> Heh
<Kinnison> oops
<Kamion> it's a couple of days old
<highvoltage> Kamion: wow, that's quite cool :)
<Kamion> wow, dapper/unapproved is getting full
<Kinnison> Kamion: of -UPDATES stuff?
<infinity> Kamion: Why on eartch would anything have ever been rsynced TO drescher?  Eek.
<infinity> earth, too.
<infinity> Kamion: That kinda frightens me.
<Kamion> Kinnison: yeah
<Kamion> infinity: I'm guessing it was while we were making Contents work
<jdub> hmm! under vmware, the ui is pretty zippy too, despite the installer running (iso on disk, not CD though)
<infinity> Oh, that's possible.
<infinity> I can just delete it wholesale, if we're sure it's stale content and no one wants to investigate further...
<Fujitsu> Hehehe. Better not be wrong...
<infinity> Well, s/delete/move/, then compare with the current dists.
<infinity> Whatever.
* infinity decides to do that now.
<Kinnison> That pulse will have annoyed the mirrors
<infinity> No more so than a new OpenOffice upstream.
<Kinnison> I guess :-)
<infinity> dists is big, but it's not THAT big.
<Kamion> infinity: diff -ru a day or two ago suggests that it was stale
<Kamion> 3482788 /home/lp_archive/ubuntu/dists/dists/
<infinity> Oh, I guess it is.
<infinity> 3.4G    dists/
<Fujitsu> Destroy it, then...
<Kamion> Fujitsu: obviously
<infinity> Kamion: Well, I'm happy to get my rm -rf on.
<Kamion> but we generally want to be a tad careful when pissing about with the archive by hand
<Fujitsu> I guess so.
<Kamion> um, that's odd
<Kamion> 3489792 /home/lp_archive/ubuntu/dists/
* infinity will move it to lp_publish's home directory for now.
<Fujitsu> I was speculating this morning what would happen if somebody accidentally rm -rf'ed the primary mirror...
<infinity> Kamion: Oh, you just moved it.
<Kamion> full of hardlinks?
<infinity> Or deleted it?
<Kamion> infinity: no I didn't
<sladen> iwj: did you bribe Mozilla to hold off the Firefox release until the day after Dapper?
<infinity> Oh, it's there.  I'm losing track of where I ls.
<Kamion> it *does* seem to be full of hardlinks
<jsgotangco> lol
<Kamion> did somebody do a cp -al or something?
<infinity> Yeah, it's a hardlink tree.
<Kamion> but not entirely, as diff -ru shows
<Kamion> -Date: Wed, 31 May 2006 18:59:08 UTC
<Kamion> +Date: Fri, 02 Jun 2006 10:18:22 UTC
<Kinnison> mdz: I have r=stevea on the patch, preparing drescher now
<infinity> Do we break links when we rsync from drescher to the push mirrors?
<Kamion> stuff like that in Release files
<Kamion> dunno
<infinity> Cause if not, then the mirrors that also don't break links wouldn't have even noticed the pulse. :)
<Fujitsu> Hobbsee, you seem to be having issues tonight.
<Hobbsee> Fujitsu: tonight?  more so last night.  ndiswrapper and knm seem to lose my connection every once in a while...
<infinity> Kamion: It's in ~lp_publish/dists.wtf now.
<infinity> And it's pretty clearly a hardlink tree, except for Release/Release.gpg and {dapper,breezy}-updates/.*
<infinity> Whack.
<iwj> sladen: Fun, eh ?
<Fujitsu> Any idea who put it there?
<Kamion> infinity: I'm guessing that the stuff that generates Release/Release.gpg breaks hardlinks in the process
<infinity> Kamion: Yeah, and breezy-updates would break the hardlinks when regenerated, so that explains that.
<infinity> Kamion: I'll still leave it in lp_publish's ~ for a while, in case someone feels the urger to trace back why it happened (if it turns out to be a bug rather than someone's poor shell usage)
<infinity> I assume it's the latter, though.
<infinity> s/urger/urge/
<infinity> (And I typed that as s/urger/urger/ before I noticed... I wonder why that one's on finger autopilot..)
<Kamion> infinity: nod
<infinity> Oh, feh, I moved that in the middle of a publisher run, didn't I?
<infinity> So it'll COME RIGHT BACK IN 15 MINUTES.
<infinity> Woo.
<Kinnison> infinity: you could have removed it from dists.new :-)
<sivang> man thi is so cool
<sivang> I am using ubuntu and installing it at the same time :-D
<simira> tihi
<sivang> Kamion: where does ubuiguity has a vt for debug, or keeps log while installation is done form the desktop-cd ?
* sivang also wonders why ubuiguity seems to be removing lots of unrelated languages packs after he had chosen hebrew as kbd layout and english is default lang.
<sivang> (in the phase of the package clean up)
<Fujitsu> Ubiquity, you mean?
<mdke> jdub: any idea why my blog is spamming planet? the dates and times in the xml feed look fine to me
<jdub> mdke: what kind of changes have you made to it recently?
<mdke> jdub: I moved it to another server, just updated the dns now
<jdub> mdke: were redirects involved?
<mdke> jdub: what do you mean?
<jdub> at any point, were http redirects involved?
<mdke> jdub: possibly, i don't know I'm afraid
* jdub deletes the cache
<infinity> sivang: ubuquity installed the read-only livefs, then removes the differences between ubuntu-desktop and ubuntu-live (more or less).  That's the langpack removals you're seeing.
<mdke> jdub: the other thing I did was to give all the posts a #postdate metatag to avoid problems caused by the mtime changing when I moved the files to the new server
<jdub> tjat
<jdub> ah, now you tell me :)
<Kamion> sivang: /var/log/installer/syslog
<mdke> jdub: also, I moved to --static
<jdub> mdke: better to just move the files in a more appropriate way ;)
<mdke> jdub: well, i wanted the #postdate thing anyway so that I can edit the posts without the date of them changing
<mdke> but afaics, the feed seems to have the correct dates in it
<sladen> mvo: there seems to be a case where ~breezy2 in breezy isn't presenting the option to upgrade to dapper
<mvo> sladen: can you elaborate please?
<sladen> mvo: I've been debugging a case with somebody since yesterday.
<sladen> mvo: apparently it was also mentioned here:  http://slashdot.org/comments.pl?sid=187187&cid=15445849
<sladen> mvo: how is it checking for the new release?
<zul> heylo
<mvo> sladen: it downloads the meta-release file from http://changelogs.ubuntu.com/meta-release-development
<sladen> mvo: does it save that anywhere on disk after downloading it?
<mvo> sladen: but it is only active when you run it with "update-manager -d" until I pushs the red button (and that is waiting for a final update)
<mvo> sladen: yes, /var/lib/update-manager/meta-release
<sladen> mvo: so that I can get them to check if it actually did
<mvo> sladen: is he runing with "-d"
<mvo> ?
<sladen> mvo: I've asked hn to but... communication is patchy
<sladen> mvo: and hn claims to have
<mvo> sladen: hm, I would be interessted if he has the file
<sladen> mvo: AFAICT, the '-d' isn't mentioned in the releases notes that do mention the "seemless upgrade"
<mdke> jdub: so, is this a problem my end? do you want to remove my blog for the time being?
<sladen> mvo: is it waiting to spread-out the mirror traffic, or to check that dapper is in a sensible sate
<mvo> sladen: we had a last minute fix to get into and it got all hold up by everyone busy with the release. we will activate it today most likely
<mvo> sladen: but we could claim mirror traffic speading as well :P
<mvo> as a reason :)
<sladen> mvo: I like it ;-)
<mvo> its a bit unfortunate that the bug (upgrade probelm for people with nvidia-glx and nvidia-settings) was not discovered earlier :/
<jdub> mdke: i killed the cache, should be fine later
<mdz> Kinnison: ready to roll?
<Kinnison> mdz: We have a problem
<Kinnison> mdz: I can't apply this patch because drescher is behind the times
<Kinnison> mdz: my patch fails in various hunks
<mdke> jdub: ok, i'll check later. Thanks
* Kinnison wants to talk with cprov before committing to blatting the codeline
<infinity> mvo: So, how did you end up working around it?  Just checking for the package combinations in question, and explicitely marking -settings and -xconfig for removal and -glx for upgrade?
<mdz> Kinnison: it might be more prudent to adapt the patch for that codeline as a temporary fix
<Kinnison> mdz: it's a nontrivial patch which touches zcml
<Kinnison> mdz: I can just comment the offending lines out of a codeline on drescher for now if you want
<Kinnison> mdz: that'll work, just remove some output from the queue tool
<mdz> Kinnison: i had a look over the patch, didn't look too scary
<mdz> Kinnison: but sure, can we do that temporarily?
<Kinnison> mdz: I'll do a comment patch as a temporary fix
<mdz> Kinnison: ok
<infinity> Kinnison: You could install your copies for the 2 minutes required to the this upload in, then revert, and commit your changes to RF...
<infinity> s/the this/get this/
<mdz> infinity: that's what we're discussing, I think
<Kinnison> I wasn't
* Kinnison was going to just comment out the offending lines in a copy on drescher so that we can do this accept
<Fujitsu> Drescher == primary mirror-source?
<infinity> Kinnison: The benefit of my suggestion is that it gets real-world testing before you commit to RF and we get "surprised" in the next rollout. :)
<infinity> Fujitsu: Yes.
<Kinnison> infinity: true
<Fujitsu> infinity, aha.
* Kinnison will rsync a merged tree to drescher, it'll be faster
<mdz> Kinnison: that's what I meant
* Kinnison is underway :-)
<mdz> er,  I meant just commenting temporarily
<mdz> I don't much like the idea of swapping in a whole new code tree on drescher at the moment
<Kinnison> urgh, Right, I'll hand-comment it and we can accept it. remind me of the queue item nr?
<mdz> Kinnison: 40661
<mdke> jdub: yay, fixed. Thanks a lot
<Kinnison> mdz: Okay I can accept it now, shall I?
<Kinnison> mdz: It's in a side-tree not what is current/
<mdz> Kinnison: yes
* Fujitsu finds Hobbsee.
* HiddenHobbsee does not exist!
<mdz> Kinnison: that will go in the next publisher run, yes?
<Kinnison> yep
<Kinnison> done
* infinity wonders idly why we have -proposed pockets, since we don't seem to use them.
<fabbione> infinity: sab idea
<Kinnison> Because we were told to put them in
<Fujitsu> heno, are you around?
<Kinnison> mdz: it's sat in accepted waiting for the publisher in 3 minutes
<mdz> Kinnison: excellent
<mdz> mvo: ready with the Big Red Switch?
<heno> Fujitsu: yes, Hi
<Fujitsu> heno, do you know anything about mekong? It's down, and Mario Meyer isn't around.
<mvo> mdz: yes, ready
<Fujitsu> This inconveniences a few LoCo teams...
<Fujitsu> Hi, G0SUB_.
<heno> Fujitsu: yes, I'm emailing with the hosting people
<G0SUB_> Fujitsu: hello
<Fujitsu> heno, thanks. Any idea what's up?
* mvo needs to switch network soon
<heno> They have gotten it to boot, but need to complete the dapper upgrade on-site for it to come back
<Fujitsu> heno, so I was right... It was related to the Dapper upgrade?
<heno> Fujitsu: I've sent them some login details
<Fujitsu> Was it a planned upgrade?
<heno> Fujitsu: yes, Nafallo had the same problem last week :)
<G0SUB_> heno: but Mario & me had decided about upgrading to dapper after a few weeks
<pitti> Hi G0SUB_ 
<G0SUB_> Mekong I mean
<G0SUB_> pitti: hello!
* mvo switches network, bbiab
<heno> G0SUB_: I wasn't informed of the upgrade until after it ws attempted and broke 
<G0SUB_> pitti: I am sorry, I was down with high fever in the last couple of days ... the monsoon has b0rked my system
<Fujitsu> Terrific.
<G0SUB_> heno: who attempted the upgrade?
<Fujitsu> It would have been nice if they'd told us.
<Fujitsu> Would Mario Meyer have told them to do it?
<pitti> G0SUB_: ouch; I hope you'll get better soon
<heno> G0SUB_: Maario I think
<G0SUB_> pitti: yes, I am taking antibiotics, will be fine soon
<G0SUB_> heno: that's strange, he himself told me that we'd wait for it to settle down before upgrading
<Fujitsu> Hmm... I think we should probably be notified before it's upgraded to Edgy...
<heno> G0SUB_: that would be more sensible too :)
<Fujitsu> How b0rked is it?
<heno> Fujitsu: and you should organise some backup system ...
<G0SUB_> heno: very strange
<Fujitsu> heno, probably.
<heno> Fujitsu: I expect it will be up again today
<Fujitsu> heno, today in which timezone?
<heno> We're just waiting for the US to wake up I think
<Fujitsu> Goodo.
<Fujitsu> Somebody'd better file a bug on the breaking :P
<G0SUB_> Fujitsu: lol
* heno -> lunch
<Fujitsu> Bye, heno.
* Fujitsu -> shower.
<sivang> Kamion: thanks
<sivang> infinity: I see, cool
<Kamion> infinity: with what looks like an initramfs-tools bug (bug 35819), is it useful to ask the reporter to attach their initramfs?
<Ubugtu> Malone bug 35819 in debian-installer "ubuntu-server dapper 20 Mar 2006: grub-install failed" [Critical,Unconfirmed]  http://launchpad.net/bugs/35819
* sivang is now using his new shiny dapper
* Fujitsu polishes sivang's Dapper.
<sivang> hmm, could it be that the default repo mirror is now in austrelia ?
* sivang notices his /etc/apt/sources.list was default configured with thise
<sivang> *those
<Fujitsu> sivang, you are Australian?
<ajmitch> heh
<sivang> Fujitsu: nope, I'm from Israel.
<Fujitsu> Hmm.
<Fujitsu> Somebody from Austria noted that the mirrors defaulted to Australia.
<Fujitsu> I wonder if that's a bug to be looked into...
<ogra> i had a similar prob with someone in #edubuntu yesterday
<Fujitsu> Hmm.
<Fujitsu> Anybody want to check>
<Fujitsu> *?\
<Fujitsu> **?
<sivang> is there a bug report about that already? infinity , Kamion ?
<ogra> its caused by the fact that the first en locale you get is simply en_AU
<Fujitsu> Yay! We win!
<_ion> I think somebody said that choosing the English language during the installation selects the en_AU locale and the au mirror.
<Fujitsu> We're #1!
<ogra> so if you select english and dont pay attention you get the en_AU locale
<ogra> seems to only happen in mixed environemnts where en is used together with some other locale
<_ion> That might be because from all the en_* locales, en_AU is alphabetically the first.
<ogra> thats what i said above :)
* Fujitsu heads off to bed.
<sivang> interesting issue
* _ion should read everything three times when he's this tired. :-)
* sivang wonders if at least he gets a good round drip to the .au mirros :p
<ogra> sivang, unlikely :)
<sivang> ogra: heh
<infinity> Kamion: Which part of that looks like an initramfs bug?
<infinity> Kamion: The "no /dev/i2o" thing?
<infinity> Kamion: Cause that's a module load order thing. :/
<infinity> Kamion: d-i and udev disagreeing about which module owns the card, one module creates devices in /dev/i2o, the other as /dev/sd*
* sivang goes to reconfigure his locales
<Kamion> sivang: yes, there is already a bug report about that
<Kamion> _ion: it's only if you select a country that doesn't have an en_* locale of its own
<_ion> kamion: Ok.
<mdz> mvo: lrwxrwxrwx  1 lp_publish lp_publish   13 Jun  2 13:04 current -> 20060601.1853
<mvo> mdz: yes, I noticed  - I'll push the red button now :)
<mdz> mvo: well, let's test first, shall we? :-)
<mvo> mdz: I'm confident ;) but I agree
* mvo goes to do testing
<mdz> mvo: it still seems to say 'dapper'
<mdz> mvo: that will not be fixed until we throw the switch?
<mvo> mdz: do you have update-manager...~breezy2  installed? the latest from "-updates"? it shows "6.06 LTS" for me
<mdz> mvo: no, I didn't
<mdz> but I was upgrading it before trying the test
<mvo> mdz: thanks
<mdz> confirmed, 6.06 LTS now
<mvo> :)
<mdz> mvo: the fere space checking code is buggy :-(
<mdz> s/fere/free/
<mvo> mdz: EEEEHHH how so?
<mdz> mvo: Not enough free disk space: ....Pleaes free at  least 91.8M of disk space on /usr
<mdz> mvo: this is a 3G root with 926M free
<mdz> surely that is enough?
<infinity> mvo: How do you check free space?
<mvo> mdz: it take 500mb to download and an additonal 400mb on a typical system
<mdz> mvo: freed up some space and it does indeed continue
<mvo> mdz: if you have "/" and "/var" on the same partition
<mdz> mvo: sorry, I guess it was right :-)
<mvo> infinity: it gets the data from apt (additonal required space and required download)
<infinity> Ahh.
<mvo> mdz: you almost gave me a heart-attack ;)
<mvo> infinity: it tries its best, but it is hopeless when /usr, /boot, /, /var are all on different paritions
* infinity decides that 10:30pm on a Friday is as good enough a time as any to declare the weekend beginning, and leaves his computer.
<mdz> infinity: good night
<infinity> 'Night.. *tips hat*
<mvo> infinity: bye!
<sivang> night infinity 
<ajmitch> night infinity :)
<pitti> infinity: bye
<Kamion> crap, kickstart is broken in dapper, will need an installer update at some point
<sladen> I don't remember seeing that on the test-list
<Kamion> it wasn't
<pitti> Kamion: before CDs are started to be pressed, or later? :)
<infinity> Kamion: Good thing we're doing an installer update for sparc anyway.
<Kamion> pitti: netboot is the primary use case for kickstart anyway
<pitti> ah, *phew* :)
<infinity> (That was a bot, not me)
<zul> pitti: let me know when i can upload btw
<pitti> zul: yes, I will
<infinity> Kamion: Sneak it into the sparc update, and we're golden.
<Kamion> I plan to
<mdke> elmo: Znarl: there are two emails from "mdke@ubuntu.com" in the filter for ubuntu-doc and ubuntu-devel, but I didn't send them. Do I need to take some kind of action about that?
<jadaz87> hello all
<jadaz87> :-)
<mdz> mdke: you could discard them
<pygi> mdke, you have spies :)
<mdke> mdz: sure, I'll do that, but I was slightly concerned
<mdke> nothing to worry about you think?
<smoosh> hi, where i can find a ubuntu gpg public key?
<pitti> smoosh: this question is underspecified
<bddebian> Howdy folks
<smoosh> pitti: i want chech the gpg signature of MD5SUM.gpg for ubuntu oso, but i don't have i ubuntu gpg public key? 
<smoosh> pitti: where i can find it?
<pitti> oh, hm, good question
<infinity> smoosh: If you have a running ubuntu system, try ubuntu-keyring.
<infinity> At least, I think the cdimage key is in the ubuntu keyring...
<infinity> Kamion: ^^^
<infinity> (base)adconrad@cthulhu:~/foo$ gpg --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg --verify MD5SUMS.gpg MD5SUMS
<infinity> gpg: Signature made Wed 31 May 2006 01:18:22 PM EST using DSA key ID FBB75451
<infinity> gpg: Good signature from "Ubuntu CD Image Automatic Signing Key <cdimage@ubuntu.com>"
<infinity> That appears to work fine, yes.
<infinity> Kamion: un-ping.
<Kamion> yeah, or just fetch FBB75451 from the keyservers if you have a trust path to it (it's signed by me, and I'm in the strongly-connected set)
<Kamion> who is Manfred Lichtenstern and why has he signed the cdimage key?
<jdub> haha
<smoosh> pitti: thanks
<smoosh> infinity: thank you! it works!!
<sfllaw> Kamion: Maybe he wants the world to know he trusts us?
<sfllaw> ;)
<Kinnison> No, he wants the world to know to never trust his signatures
<Kinnison> because he's asserting that he's met the ubuntu CD image autosigner and has verified that that "person" owns that key
<mdke> Znarl: around?
<sfllaw> Kinnison: You mean that we don't have a small indentured servant boy personally verify and sign all our CD images by hand?
<sfllaw> What kind of distribution is this?
<Kinnison> Well, I wouldn't call kamion a servant boy, he might kick my arse
<Kamion> I don't sign them by hand ;-)
<bddebian> heh
<Kinnison> Kamion: you don't? You mean you cheat and use hackspit a program to do it for you?
* Kinnison hands kamion a small magnet on a spike
<Kinnison> do it yerself, lazy git
<Kamion> my RSA-by-hand skills aren't what they used to be
<sfllaw> You can't trust _programs_.  They're _machines_.
<Keybuk> Kinnison: or perhaps he's certified that he's done a security review of the process used to build CD images and is happy that the signature is accurate
<Keybuk> Kinnison: or, perhaps he's just signed it to indicate that he's confirmed that a CD with that signature did indeed come from Ubuntu
<Kinnison> Keybuk: that'd imply he'd broken into our DC to do the check
<Keybuk> Kinnison: "I have met and verified the identify of" is only something _you_ infer from a signature
<Kinnison> in which case he shouldn't have signed it because he could break in
<Keybuk> you can infer anything from a signature
<dieman> or perhaps he has no clue?
<Keybuk> it's an arbitrary device
* Kinnison infers that all signatures indicate sex between two people except for his own sigs
<Kinnison> now tbm has got some
<Kinnison> :-)
<Keybuk> in particular, gpg simply infers that a signature on a key indicates that you trust that key
* Kinnison tickles keybuk
<Keybuk> he's probably signed it to indicate to gpg that he trusts the key and doesn't want it bitching
<Keybuk> and used sign rather than lsign
<Kinnison> troo
<Keybuk> so Manfred Lichtenstern is simply someone who trusts the cdimage key
<Kinnison> and then uploaded the key by mistake
<Keybuk> that's all you can really infer from that
<\sh> but now Mandred Lichtenstern is quite famous
<Keybuk> the fact you chose to infer the concept of meeting and checking as the indication of trust is purely your personal preference
<Keybuk> ya know, I might just create a key and use it to sign those people I've had sex with :)
<sfllaw> We should thank Mandred Lichtenstern in release notes or something.
<Keybuk> just for amusement
<sfllaw> Maybe an easter egg?
<\sh> Kamion: why is ubiquity setting en_AU as default locale when choosing english as language?
<Kamion> \sh: known bug when you pick a country that doesn't have its own en_* locale
<\sh> Kamion: ah ok
<mdke> that is a serious bug if ever I saw one
<Kamion> no it's not
* mdke slides off in the knowledge that yet again, no one knows when he's joking
<Kamion> heh
* bddebian hugs mdke
<\sh> well, I just thought this morning, that jdub managed convince the queen to set en_AU as default english language even in good old britain ;)
* mdke can see that
<sladen> Gu'day maate, your majesty.  That's a nice pozzy you got there, mind if I rock up and park me arse down?
<bddebian> pozzy? Hmm
<\sh> hehe
<imbrandon> lol
<Hobbsee> hehe @ sladen 
* desrt thinks that en_AU should actually start translating this way
<jadaz87> is there something like launchpad but opensource?
<desrt> trac?
<desrt> bugzilla, perhaps
<jadaz87> oh ok
<jadaz87> what is the website for trac?
<desrt> google trac
* desrt gets annoyed when people ask questions that could very obviously be solved very easily with google :p
<jadaz87> :-(
* jadaz87 gets annoyed when people say that, who says i am in tty and cannot go to google?
<_ion> Who says one can't use google from tty?
<jadaz87> _ion most website are not built for w3m
<jadaz87> IE
<_ion> True. They are built for HTML.
<desrt> if you can't use google then the rest of the web isn't likely to be very useful for you
<desrt> Err http://security.ubuntu.com edgy-security/main Packages 404 Not Found
<desrt> shucks.
<jdub> heh
* desrt craves excitement
<Keybuk> desrt: that would probably be linked to the "http://archive.ubuntu.com edgy/main Packages 404 Not Found" error :p
<desrt> Keybuk; ya.  i seem to be getting an awful lot of these errors, now that you mention it
<jdub> you are not ready for edgy
<desrt> are you kidding?
<desrt> edgy is not ready for me!
<desrt> i think i broke mugshot.  nice.
<desrt> i list all people in the gnome group and it stops sending the page half-way through
<desrt> in the middle of a <div> <table> <tbody> <tr> <td> <div>
<HiddenWolf> tables? ew. :)
<mdz> seb128: is there an upstream fix for bug 39482 in 2.14.3 by any chance?
<Ubugtu> Malone bug 39482 in nautilus "nautilus tries to move when dragging and dropping from read-only folders, instead of copying" [Normal,In progress]  http://launchpad.net/bugs/39482
<seb128> mdz: no, but sivang has sent a potential patch for it on the upstream mailing list, I'm waiting on alex (upstream maintainer) to comment on it and will upload to dapper-updates, it's on my "to fix to dapper-updates" list
<mdke> seb128: is it known that when double clicking on an .odt file in nautilus, the resulting window isn't focused? and the "Opening Filename..." window in the panel hangs around for a while after it opens
<seb128> mdke: I don't read openoffice bugs so no idea
<mdke> seb128: ah, I assumed it was a nautilus/Gnome thing
<seb128> nop
<mdke> ok
<seb128> there is no reason it would work for some app and not other
<seb128> if you don't have the issue with gedit by example then it's an openoffice issue
<mdke> ah, I get the issue with gedit too
<mdke> good point
<mdke> not with evince though
<seb128> hum
<seb128> I think I'm not in the mood of discussing bugs today :p
<seb128> mdke: how do you start it? what do you have on screen? what get focus?
<mdke> seb128: double click in nautilus on the file. Nautilus keeps the focus
<seb128> works for me
<seb128> what focus mode do you use?
<_ion> Wow. 1) mv huge_directory /nfs_mountpoint/foobar, 2) during the transfer, mv some_other_directory huge_directory, 3) after the first mv process is complete, it prints "Cannot delete huge_directory: directory not empty"  oh, it doesn't. Instead it removes huge_directory, including huge_direcotry/some_other_directory (which hasn't been moved to foobar, naturally).
<seb128> do you click from the desktop or a window?
<seb128> spatial or browser mode? icon or list?
<mdke> seb128: window. Looking for focus mode
<mdke> seb128: click/smart
<seb128> works for me ...
<mdz> seb128: thanks
<seb128> mdke: is nautilus running with your user?
<seb128> mdz: np
<mdke> seb128: as far as I know, yes
<pitti> happy happy joy joy - bug 48043
<Ubugtu> Malone bug 48043 in firefox "New Release 1.5.0.4 with multiple security fixes" [Normal,Unconfirmed]  http://launchpad.net/bugs/48043
<seb128> mdke: spatial or browser? single or double click? list of icon?
<pitti> mdz: so now we're officially screwed with firefox 1.0.x
<seb128> s/of/or
<mdke> seb128: browser, double, icon
<pitti> (not even mentioning mozilla)
<mdke> seb128: could it be related to bug #44710 (i don't really understand the bug report)
<Ubugtu> Malone bug 44710 in metacity "raise_on_click is disabled in 'click_to_focus' mode" [Normal,Needs info]  http://launchpad.net/bugs/44710
<seb128> mdke: to be honest I don't understand neither your bug or the one you point ;)
<seb128> double clicking on a .txt open gedit
<seb128> and if I press a key the char go to the gedit window
<seb128> which seems to work fine to me
<mdke> not here :/
<mvo> mdz: ok, my testing is positive. ok for the "big red button"?
<mdke> seb128: I'll file a separate bug, and we can discuss another time via the bug report. Thanks for your help, as always
<seb128> mdke: no please
<seb128> too much bug, graa
<seb128> too many bugs, graaa
<mdke> heh
<seb128> mdke: comment on the other bug if you think you have the same issue
<seb128> or send upstream
<sladen> if all these buttons are big and red, it must be getting confusing about which one to press
<seb128> mdke: sorry but I just feel it's too much of them atm ;)
<mdke> seb128: I have no idea if it is the same issue as that bug.
<seb128> to be honest I'll do nothing on your bug since I don't get the issue
<mdz> mvo: my test succeeded as well
<mdz> mvo: let's do it
<mvo> mdz: rock, thanks
<seb128> and I've no idea on what could be wrong
<seb128> but right, open a bug if you want
<mdke> seb128: oh, that's a shame. I'll try upstream too then
<mdz> mvo: we've missed cron.daily for US and Europe, so I expect nothing will start happening until tomorrow
<dieman> well, that sucks. this laptop loses its hard drive after suspend
<dieman> (to ram)
<dieman> even though its sata and supposedly the patches are in the kernel, pout.
<mjg59> dieman: What machine?
<mvo> mdz: its updating the meta-release file, the effect is immediate
<dieman> mjg59: dell latitude d620
<mvo> mdz: its active now *PHEAR*
<bddebian> heh
<dieman> mjg59: its got an intel 82801GBM/GHM
<dieman> mjg59: supposedly it sometimes works under 2.6.16 for some suse user with a website
<mjg59> Bleah.
<dieman> looks like the same disk controller as the thinkpad x60s
<seb128> mdke: is /apps/metacity/general/raise_on_click activated for you?
<mdke> looking
<mjg59> dieman: Yeah, that makes less difference than you'd expect
<mdz> mvo: yes, but no one will notice until they get an automatic notification
<mdz> mvo: please update the instructions on DapperUpgrades
<dieman> mjg59: heh
<mdke> seb128: yes
<mvo> mdz: will do
<seb128> mdke: does it happen with an another user? what window manager do you use?
<mdke> seb128: metacity, will try another user
<sladen> mvo: does that mean that the http://changelogs.ubuntu.com/meta-release-development file should have changed to say  "Supported: 1" for dapper?
<sladen> mvo: still says  "Supported: 0" 
<mvo> sladen: yes, thanks - but -development is not that important anyway (that is only used when the -d switch is active)
<seb128> mdke: works fine on my laptop with a stock install of dapper from some days ago too
<seb128> mdke: my best bet is that you or something you played with changed a setting which does that but I've no idea of why one
<_ion> I filed a bug report: bug #48066.
<Ubugtu> Malone bug 48066 in coreutils "mv(1) may delete more than it should" [Unknown,Unknown]  http://launchpad.net/bugs/48066
<mvo> sladen: updated, thanks again :)
<sladen> mvo: oh right.  I'd assumed that meant "-distro-updatable"
<sladen> mvo: the Release  Date:  is different  12:00 UTC  vs.  09:00 UTC  (this is so minor...)
<mdke> seb128: having deleted ~/.metacity it now works properly. didn't happen with a fresh user. So, probably no bug
<seb128> mdke: did you keep the ~/.metacity for debug?
<mdke> seb128: I have it backed up
<mvo> sladen: right, I'll update that too (but it is currently unused :)
* mvo checks the right release time
<Kamion> 09:00
<mvo> thanks 
<Kamion> (officially; we may have been a few minutes off ;-))
<seb128> mdke: bah, forget about it, we have too many bugs, realisticly we will not work on that before ages ... feel free to bug upstream if you want, other way let's consider as a local hick on your box
<mdke> seb128: fine by me. Sorry about that
<seb128> np
<seb128> sorry for complaining today, I feel slightly tired and I've read too many bugs recently, I think I'll enjoy doing something else tonight and a good night then ;)
<jsgotangco> you deserve it!
* mvo pushes seb128 away from the computer so that he can relax a bit
<mdke> seb128: good idea
* HiddenWolf thinks seb128 deserves a hug
<jsgotangco> yeah
* bddebian hugs seb128 :-)
<jsgotangco> group hug
* jsgotangco hugs seb128 
* mvo hugs seb128
* seb128 hugs everybody
* mvo hugs seb128 again (just to be sure)
<seb128> ;)
* Hobbsee hugs everyone as well
* _ion hugs self
<bddebian> heh
* jsgotangco hugs Hobbsee tightly
<jsgotangco> lol
<jsgotangco> kidding
<Hobbsee> hehe
<Hobbsee> dont squish me!  i'm breakable!
<mdke> Znarl: reping?
<Znarl> mdke : Pong?
<mdke> Znarl: just chasing you on the wiki move
<Znarl> mdke : About the two emails from mdke@ubuntu.com?  There is nothing you can do about that.  It's not a cause for worry.
<mdke> Znarl: cool
<Znarl> mdke : fabbione has stolen me, I have no idea when I'll be finished.  I can't do anything until then.
<mdke> Znarl: ah, right. If you can't do it by today, lemme know and I'll put the static stuff up on the old server
* Hobbsee wonders if group hugs occur in places like paris dev meetings :P
<Znarl> mdke : Might be best to put the static stuff up.
<mdke> Znarl: al right, I'll start building it
<mdke> Znarl: thanks
<LaserJock> Hobbsee: do you really want to know the answer to that?
<Hobbsee> LaserJock: hmmm...yes...
<Hobbsee> i think so...
<LaserJock> Hobbsee: you'll just have to come to Paris to find out then
<Hobbsee> LaserJock: i cant come to paris dammit :P
<Hobbsee> i have exams, and i dont have a passport.
<Hobbsee> LaserJock: those are the main reasons
<zul> why dont you get a passport?
<Hobbsee> zul: because if i wait till i turn 18, i can get one for 10 years - and my old one lapsed.
<bddebian> They won't let her out of the country.  She's dangerous ;-P
<zul> ah..
<Hobbsee> besides, is it really a good idea for an under-18 year old to be traipsing around the world with a group of men?
<Hobbsee> on second thoughts, dont answer that.
<Hobbsee> bddebian: hehe.  you bet.
<crimsun> pitti: right, I'll reroll a new debdiff for moodle, thanks!  (Figured it wouldn't be much use to have a security update if the thing didn't install ;-)
<Hobbsee> LaserJock: zul:  the main problem is that i have exams, and we have to stay there to do the exams, no exceptions.
<Hobbsee> the rest would probably be otherwise solvable, but not that.
<mdz> seb128: so about 2.14.3, feel free to go ahead and upload anything which is trivial and safe (translations, stuff we've already merged, trivial bugfixes); if there is anything you consider non-trivial, please run it by me
<LaserJock> Hobbsee: whatever, you just hate us
<mdz> seb128: automated upgrades from breezy will be starting over the next 24 hours or so
<Hobbsee> crud, i'm in -devel - i thought i was in -motu
<Hobbsee> haha
<mdz> well, automated notifications anyway
<seb128> mdz: we did that today
<seb128> mdz: I cursed evolution guys though, but I'll not bother you with that today
<seb128> s/cursed/curses
<mdz> seb128: oh, there's no mail notifications. so they're waiting in unapproved?
<InfraRed1> hello
<seb128> mdz: probably, I got mails saying so but I don't know where unapproved is and if everything behind the scene works fine ;)
<desrt> man i love reading the latest sco news
<desrt> it's so inspiring
<seb128> mdz: evolution guys changed some evolution-data-server soname between GNOME 2.14.1 and 2.14.2 because they apparently broke the ABI some time ago and didn't notice until the Debian maintainers complained ...
<jdub> seb128: ha ha!
<jdub> btw, federico is going to get ABI checkers into gnome's tinderbox
<jdub> that'll be nice
<seb128> mdz: that will need to discuss, since the ABI didn't change between 2.14.1 and 2.14.2 we technically don't need to change the soname and we should probably undo that move if we want to update to dapper-updates 
<pitti> seb128: erm, there are *30* rdepends on that
<seb128> jdub: yeah, that would be nice
<seb128> pitti: since the ABI changed ages ago and not after GNOME 2.14 I would say to undo the soname change simply
<pitti> seb128: right
<pitti> seb128: will make us incompatible with the rest of the world, but...
<seb128> pitti: what rest of the world? FC5 shipped with GNOME 2.14.0 and have the same soname as dapper then
<pitti> oh, right
<jdub> seb128: we should punch the evo guys for changing the soname
<pitti> seb128: forget about me, it's been a long week
<seb128> Suse didn't do anything with GNOME 2.14 yet, nor did mandriva
<seb128> jdub: yeah, I've planned to talk to harish when he will be around
* seb128 wonders if mdz had an attach while reading about the soname change
<mdz> seb128: ...
<jdub> attack?
<jdub> seb128: he was already a little unstable earlier, due to the sun in london
<mdke> it's gone now
<seb128> jdub: right
* Kamion tries to figure out the build-dep chain for edgy d-i
<seb128> mdz: joke aside, any opinion on that? Anyway, I don't plan to work on that upgrade before my week of VAC, so we have to think about it 
<Kamion> I think it'll need libselinux and friends, dpkg, debhelper before even starting
<mdz> seb128: I don't think we should change the soname in -updates, no
<seb128> mdz: do you think that undoing the soname change is fine or should we rather not update eds?
<seb128> mdz: I'll have a look on the bug fixed list and ping you back later on the topic
<mdz> seb128: I accepted your last batch of uploads; any more coming soon?
<mdz> seb128: if the other changes are safe and worthwhile, we should update it, yes
<Kamion> drat, and dpkg isn't just a sync; it was looking good until I got to the linktosameexistingdir stuff
<seb128> mdz: ok. Updates? Daniel uploaded a bunches of GNOME updates too I think, you probably noticed them. Other way nothing queued yet, probably monday for next batch
<mdz> seb128: yes, I processed everything which was pending
<seb128> ok, thank you
<Kamion> iwj: will you be able to merge dpkg early next week? from what I can tell, it looks like it can very nearly be a straight sync, but not quite
<iwj> Kamion: I should be able to.  I haven't looked at it.
<Kamion> libselinux/libsepol need to be synced first I think
<iwj> Oh FFS
<iwj> Damn the NSA for adding more shonky crap to the world.
<Kamion> it's a trivial sync though, so won't hold stuff up
<Kamion> then debhelper will need to be merged; I guess I'll look at that
<Kamion> then with any luck it's just a matter of walking through d-i in build-dep order ...
<LaserJock> iwj: got a sec?
<iwj> LaserJock: sure.
<LaserJock> iwj: I wanted to ask about the Ubuntu Developer's Reference. I know you were really busy with Dapper but did you get a chance to work on it?
<LaserJock> iwj: I saw from the developer reports that it was "started" but am unsure of what that meant
<iwj> Not since we last spoke.
<iwj> It means I got about 10% of the way through hacking the DDR with a chainsaw.
<LaserJock> iwj: is it just you working on it? do you need/want help?
<iwj> need/want help> are you offering ? :-)
<iwj> Because if you are then yes please!
<mdke> does it have a different scope from the packaging guide?
<LaserJock> yes, I'm offering to do what I can
<LaserJock> mdke: yes
<mdke> ah
<LaserJock> mdke: I think ;_0
<LaserJock> :-) I meant
<iwj> mdke: Yes, I think so.  It covers all of the stuff that's not how to make your package.
<mdke> if it's not that different, maybe you could merge the projects
<mdke> ah
<LaserJock> I think they are complimentary
<iwj> So the DDR covers stuff like how to become a DD, NMU procedure, etc. etc.
<mdke> oh right
<iwj> Lots of it wants ripping out and replacing in the UDR.
<dieman> holy crap, the linuxant people already have dapper packages up
<mdke> what format are you doing it in?
<iwj> LaserJock: Would you like me to give you what I have and you can pick it up ?
<iwj> I'd be happy to explain my thinking and what I was doing about it, etc.
<iwj> Maybe a phone call would be a good idea, after you've had a chance to look at it.
<LaserJock> iwj: if you don't think you have time for it
<LaserJock> iwj: I would at least like to help pout
<iwj> mdke: It's going to be a modified-for-Ubuntu developer-reference package.
<iwj> LaserJock: I think it would be good for you to hold the master since I don't seem to be doing much with it and you might actually upload it.
<LaserJock> iwj: k, do you have a url for it? or can you send me what you have?
<iwj> LaserJock: http://www.chiark.greenend.org.uk/~ian/d/Udr.tar.gz.
* jsgotangco is familiar with the DDR
<iwj> Contains: my working tree; the ddr I based it on.  dpkg-source -x the ddr inside and you'll get a diff that might be informative.
<iwj> That is, dpkg-source -x the ddr 3.3.6 inside it and then diff it against the working tree.
<iwj> You'll see I didn't chop out the sections to be hatcheted; I've been commenting them out.
<LaserJock> k
<iwj> That way when the DDR changes in those parts we won't get a rejected diff when we merge.
<LaserJock> ah
<LaserJock> ok, well I'll try my best but I imagine I'll need to pick your brain every once in a while
<LaserJock> I've gotten fairly good feedback about the Ubuntu Packaging Guide so far so I think having the UDR done too would be a real plus for Ubuntu
<iwj> Absolutely.
<iwj> It's a real shame I was too swallowed up by firefox to really do much about it.
<LaserJock> yeah
<jsgotangco> okay so the UPG had lots of accolades and the UDR is the natural path, bring it on yo!
<pitti> iwj: can we get ffox 1.5.0.4 into dapper-security next week?
<pitti> iwj: I can prepare a changelog entry again
<iwj> pitti: Yes, and yes please.
<iwj> What are we going to do about breezy ?
<mdke> heh
<fabbione> and hoary...
<imbrandon_zZz> and sid .... err yea
<jdub> pitti: could you please get that compreg fix in with it? :) seb will love you forever.
<iwj> LaserJock: Well, do let me know however I can help.
<LaserJock> iwj: will do, thanks.
<iwj> jdub: What compreg fix ?
<jdub> https://launchpad.net/distros/ubuntu/+source/firefox/+bug/30791
<Ubugtu> Malone bug 30791 in firefox "firefox 1.4.99 upgrade still have compreg.dat, creates issue" [Normal,Needs info]  
<jdub> new poll on fridge
<sladen> mjg59: have you hand-hacked a mactel-specific i386 image yet?
<mjg59> Nope
<Tonio_> hello
<sladen> mjg59: do you have plans to?  I don't have access to a Mac OSX box
<iwj> jdub: That bug was last touched in January and there seems to be no information about what the fix might be ?
<mjg59> Yeah, but probably with Colin and not in the next few days
<jdub> iwj: removing comprej.dat on upgrade
<iwj> jdub: The problem isn't that it's not removed.  It is.  The problem is that something recreates it.
<jdub> hrm
<iwj> We don't know what.
<jdub> suck!
<iwj> If we knew what then we could hit it over the head.
<iwj> You'll see my latest contribution (2006-01-06) provides a thing you can do to trip up the responsible program.
<iwj> But no-one seemed to want to do this.  Furthermore, I haven't seen any reports of this particular problem recently.
<iwj> That could be because (a) it was a bug in something in earlier dapper or (b) it's a latent bug in something in breezy that happens during the breezy->dapper upgrade.
<seb128> iwj: the issue is not than nobody wants to do it, it's rather than nobody manages to trigger it to debug it
<iwj> seb128: Well, yes, that too.
<iwj> It seems quite a rare problem.  Either the package that's causing it is unusual, or there's something odd about the upgrade process of the people that have the problem.
<dieman> arugh
<dieman> looks like hsfmodem from linuxant will not work with the hda driver in dapper
<dieman> they didn't notice some of the alsa 1.0.11 stuff pulled in earlier this month
<dieman> i think
<mvo> iwj: I suspect that it was created by gtkmozembed when the gnome-app-install tool was run as root (that was the default in breezy)
<mvo> iwj: but that is just a theory
<mjg59> Closed source driver in "not working" anti-shocker
<bddebian> heh
<zyga> hey guys
<pitti> jdub: compreg fix? into what? ffox?
<zyga> I managed to crash ubiquity 
<dieman> mjg59: yeah
<dieman> mjg59: it just seems to be the hda modem driver
<dieman> mjg59: its their problem, but in case you start getting gobs of bugs
<dieman> they claim they wont fix it until 1.0.11 is rolled into 2.6
<mjg59> Sucks to be them
<dieman> yeah
<dieman> definately sucks for them
<iwj> mvo: So do we think packages are running gnome-app-install in their *rm scripts ?
<dieman> sucks for me because a professor wants his modem working, now.
<dieman> ;)
<dieman> i'll tell them to buy a pcmcia card
<jdub> pitti: see discussion with iwj :(
<pitti> jdub: ok, I let you two sort that out
<mvo> iwj: err, no. 
* iwj finds (at least one) cause of dependtry assertion in dpkg.
<iwj> If you make a package depend on itself, dpkg won't configure it and will crash instead.
<dieman> its more fun when the package escapes dpkg by having the fs its on end up being unmounted
<dieman> thats quite easy to do with autofs :)
<iwj> What on earth are the expected semantics of this ??
<iwj> Package: blt
<iwj> Provides: blt-common
<iwj> Conflicts: ... blt-common
<iwj> Depends: ... blt-common ....
<dieman> nice
<iwj> Collect the full set !
<imbrandon_zZz> lol
<Kamion> zyga: everyone else files bug reports about that ;-)
<zyga> Kamion: phone
<lifeless> is there a london release party planned ?
<sladen> mvo: where does  update-manager/synaptic  put upgrade-logs 
<sladen> mvo: eg. the decisions about what to remove/add
<mvo> sladen: /var/log/dist-upgrade*.log
<sladen> mvo: thanks
* InfraRed pokes sladen 
<sladen> InfraRed: yup
<InfraRed> sladen: i forgot to post the card
<sladen> InfraRed: okay.  tell me that in a channel that isn't  #ubuntu-devel
<InfraRed> will post it tomorrow so they'll have it monday/tuesday latest
<InfraRed> ok :)
<InfraRed> eof
<ogra> pfft, sladen wants only a higher win count in irssi, so he can pretend he typoed "win 247" again to show off :)
<sladen> business and pleasure don't mix.  and #ubuntu-devel is pleasure ;-)
<ogra> :)
<InfraRed> oooh ya
<jdong|coreduo> elmo: you got a moment?
<j^> how can i switch off all screen blanking? i disabled it in gnome-power-manager and disabled the screensaver, still the sreen turns of after 30minutes
<InfraRed> bios?
<iwj> Yay, fixed it.
<sladen> j^: dimming, or blanking?
<iwj> Also found and removed the scars of some idiot's attempt to fix it previously.
<j^> sladen its a desktop and the projector that is connected gets no signal
<sladen> j^: g-p-m -> Running on AC -> Switch display off: Never  and  -> Running on Battery -> Switch display off: Never  (drag both sliders to the right hand side)
<j^> sladen did that, did not help
<sladen> j^: what's the bug number?  Can you try running   sudo vbetool dpms off   and then waiting 
<j^> that switched it off
<j^> will stop now to many people watching...
<sladen> j^: sudo vbetool dpms on
<sladen> j^: oops
<iwj> I'm really glad now I kept a copy of dpkg 1.4.0 hanging around.
<sladen> j^: can you file a bug and attache your /var/log/Xorg.log
<j^> sladen will check this out once the presentation is over trying xset -dmps now
<iwj> Gah, that's _two_ broken fixes for the same bug, and counting.
<janimo> Kamion: with the seeds in the new place you no longer mirror the old xubuntu ones right?
<iwj> Come on, BTS, ...
<iwj> (The Debian one.)
<iwj> I want to put the Debian bug number in my email to Malone.
<glatzor> ping Riddell
<Riddell> glatzor: hi
<glatzor> Hi Riddell, I've got one little question about KDE: are there currently any string changes in the ubuntu packages of KDE?
<Riddell> glatzor: a few, about 5 I think
<Riddell> maybe less
<Riddell> mostly for sudo support in kdesu
<Riddell> and we might have bugs in some .pot file generation for all I know
<glatzor> Riddell: fine. the reputation of (K)Ubuntu in the German KDE translator community isn't the best at the moment :/
<Riddell> untranslated strings or rosetta translators changing strings without good reason?
<glatzor> Riddell: I think that we collect obsolete messages of previous versions in Rosetta 
<glatzor> Riddell: of course both :)
<Riddell> the strings in rosetta are from kde 3.5.2
<Riddell> or the strings I sent to rosetta are, they could have been changed of course
<glatzor> Riddell: I don't know much about Rosetta. But does it merge the strings of later version or does it remove all obsolete strings that don't appear anymore in the later version?
<Riddell> it'll remove ones that aren't used any more and merge new translations in, I'm not sure if the merge process gives status to upstream strings or those from rosetta though
<glatzor> Riddell: I think that I have to take a closer look at the future plans for Rosetta. if it also covers universe the situation could get even worse.
<Riddell> glatzor: I think the situation can only improve as rosetta teams learn how to respect and work with upstreams
<Riddell> hi mvo_, I see mornfall is planning on uploading app-install-data to debian
<mvo_> Riddell: interessting - I hope he refreshs it with the debian specific data
<thesaltydog> #ubuntu-it
<neuRo] > from where exactly can I download ubuntu's source-code (please dont say www.ubuntu.com because i've been looking for a while)?
<LaserJock> neuRo] : from the source packages
<LaserJock> neuRo] : use deb-src lines in /etc/apt/sources.list and apt-get source
<neuRo] > that didn't help.
<LaserJock> neuRo] : why not?
<neuRo] > because it doesn't make sense to me.
<crimsun> this is better addressed in #ubuntu-motu, probably
<neuRo] > that's like speaking in chinese to someone who just spoke to you in english and expecting them to understand you.
<stratus> neuRo] : http://archive.ubuntu.com/ubuntu/pool/
<LaserJock> neuRo] : yeah, lets take it to #ubuntu-motu, we can talk you through it there
<mgalvin> jdub: so what are the names that did *not* make the cut? :)
<Burgwork> mgalvin, did not make the cut?
<mgalvin> the "other" names rather
<Burgwork> mgalvin, for edgy?
<mgalvin> Burgwork: his blog post... what Ubuntu might have been called if sabdlf didn't suggest Ubuntu
<Burgwork> ah
<ohoel> Coca Cola Linux
<LaserJock> "Just Works" Linux?
<ohoel> I'd have to find myself another planet ;)
<\sh> can someone confirm, that ibm t43's hibernate is not working,too? but suspend to ram is?
<DShepherd> what is thelandscape-client package do? or supposed to do
<Riddell> DShepherd: apt-cache show will reveal all
<DShepherd> Riddell: i did
<Riddell> then you'll know as much as anyone does :)
<DShepherd> Riddell: is that something? :-D
<Burgwork> DShepherd, it is a big secret that the Canonical people cannot tell us
<DShepherd> Burgwork: :=P
<DShepherd> Burgwork: ok... just dont go microsoft on us now... we still love ubuntu's sense or transparency
<DShepherd> or =  of
<jdub> the package description is pretty clear :)
<DShepherd> I know what it says.. i want to see what it does :-D
<pygi> crimsun, o joy, so many patches :)
<kermitX_> http://www.cetico.org/tech/2006/05/ubuntu-landscape-somewhat-announced.html
#ubuntu-devel 2006-06-03
<Burgwork> kermitX_, hmm, that be some optics problems
<LaserJock> optics?
<Burgwork> optics is how something appears. Marketing term
<LaserJock> oh
<LaserJock> I was thinking optics as in laser optics :-)
<Burgwork> something like landscape-client may actually be a godo thing and be gpl'ed, but lack of information means that there is a lot of FUD flying around
<Burgwork> personally, I don't see why they don't just announce what it is, now that they have effectively announced it via dapper-changes
<Fujitsu> Oh for goodness sake...
<Fujitsu> Somebody in #ubuntu is complaining that there is no easy facility to downgrade.
<Burgwork> no, dpkg doesn't support it
<LaserJock> Fujitsu: that's a long standing problem with dpkg, i think
<LaserJock> not that anyone would really want to downgrade. Dapper is so awesome ;-)
<Fujitsu> He's doesn't want to accept that he can't downgrade...
<Fujitsu> How silly.
<Burgwork> it is a legit use case, just a hard one to implement
<kermitX_> rolling back upgrades to packages would be tricky to implement.
<infinity> We don't support it because it makes packaging instantly 500% harder.
<Fujitsu> Very difficult to implement...
<infinity> dpkg DOES support downgrades.
<Fujitsu> And very silly.
<infinity> Individual maintainer scripts don't.
<Fujitsu> apt-get dist-downgrade...
<infinity> (And Debian Policy clearly tells us we don't have to)
<Fujitsu> Heheh.
<infinity> Whe nyou have maintainer scripts doing whacky transitional stuff in maintainer scripts (moving files and directories, converting directories to symlinks and vice-versa), your job gets infinitely harder when you have to cope with all possible cases of doing that BACKWARDS.
* LaserJock throws the Debian record player in reverse
<LaserJock> yep, I here breakage
<LaserJock> *hear
<neuralis> hey ptlo
<ptlo> heya neuralis! long time no see :-) 
<ptlo> 'sup, how's the olpc python thingy working out?
<neuralis> ptlo: i'm in your general area; we should find time to hoist a few pints
<ptlo> you're on the same continent again? cool :) yeah, i'm looking forward to it
<bddebian> Howdy
<ajmitch> hi
<mdke> hello
<desrt> does anyone have software-controlled brightness?
<desrt> for their laptop LCD
<infinity> desrt: My Thinkpad does.
<desrt> how does gnome handle it?
* desrt just wrote a C program to control brightness on macbook but doesn't know the "proper" way to tell gnome about it
<infinity> Look at gnome-power-manager's source.
<infinity> I assume it uses hal.
<infinity> Since there's no standard way at the kernel level.
<infinity> (Mine, for instance, is in /proc/acpi/ibm, I think.
<infinity> )
<desrt> how does g-p-m grab the keyboard keys?
<infinity> It doesn't... That's lower-level... hotkey-setup, probably.
<desrt> neat.
<infinity> I just happen to know that g-p-m twiddles brightness for other reasons, hence the suggestion to look there for how to do it via hal.
<desrt> thanks for the pointer
<bddebian> Heya infinity
<bddebian> Good work man! :-)
<infinity> With anyhting in particular, or just in general?
* mdke passes on another generic pat on the back for infinity 
<infinity> Meh, if you all loved me, you mail me some screwdrivers that don't strip the heads on the first use.
* infinity grumbles.
<Fujitsu> Haha,
<infinity> My kingdom for a hardware store in Australia that doesn't sell third-world crap.
* Fujitsu gives infinity some screwdrivers.
* Fujitsu hails infinity.
<desrt> oh wow
<Fujitsu> Hmm.
<desrt> hal itself watches the buttons
<Fujitsu> You're Adam Conrad, aren't you?
<desrt> elite!!
<Fujitsu> In Melbourne?
<infinity> Fujitsu: Last time I checked.
<Fujitsu> infinity, aha. Right near me...
<mdke> infinity: why do you find yourself in melbourne anyways?
<Fujitsu> :O
<Fujitsu> Did mdke just insult Melbourne!?
<mdke> no, it looks nice on the tv
<mdke> but I was just wondering
<bluefoxicy> hey nice release with dapper.  Looking forward to Edgy devel.
<bluefoxicy> Anyway.
<bluefoxicy> I'm looking to take Dapper right now and run some sort of program that magically tells me where %eip goes during execution and graphs it, without doing much more work than install-run-graph
<infinity> mdke: I moved here from Canadia because my girlfriend is Australian.
<Fujitsu> ...
<Fujitsu> Wow, I'm from Canada as well.
<Fujitsu> Hi, licio.
<bluefoxicy> It occurs to me this is the only place I'm likely to get a hint on where to look for profiling stuff on Ubuntu.  Any ideas?  or is this more "rebuild the whole system, patch the kernel, run this analysis software, gather these output files, look at these in this way, run this parser"
<mdke> infinity: ah. I googled you yesterday and found your girlfriend's site. it's scary
<licio> hi Fujitsu 
<infinity> mdke: It doesn't scare me so much. :P
<bluefoxicy> (in particular I want to see how much time is spent in shared objects versus the main executable; this could be VERY SIGNIFICANT in making an argument on building Edgy with position independent executables or working on that for Edgy+1)
<mdke> infinity: glad to hear it
<bluefoxicy> infinity:  my boyfriend is from canada :o
<bluefoxicy> he just moved back to alberta :(
<bluefoxicy> from ottawa, so besides 2 timezone difference not much has changed
<mdke> infinity: i take it that isn't your still beating heart in her hand then
<mdke> you'll need that
<infinity> mdke: *laugh*... No, we're past that stage now.  3.5 years together means we're just boring old people now.
* mdke nods
<mdke> that's the best way
<ajmitch> heh
<infinity> I won't deny that "comfortably boring" is generally nicer than "OMG, excitement, WOW"
<infinity> Though some of the latter isn't all bad.
<infinity> Also, holy crap is this ever offtopic.
<infinity> Shall we go babble in #ubuntu-offtopic?
<Fujitsu> Is any development actually going to happen here, though>
<Fujitsu> *?
<infinity> I wouldn't put it past people to attempt some.
<mdke> alright
<infinity> I'm happy to take the weekend to "have a life" (and catch up on some Debian stuff), but to each their own.
<bddebian> infinity: For everything :-)
<bluefoxicy> wow
<Fujitsu> ?
<mdke> haha
<infinity> Fujitsu: Do you know, off the top of your head, where I could buy canned air?
<infinity> Fujitsu: It doesn't seem to be a popular product here...
<Fujitsu> No, it doesn't.
<infinity> (To blow dust/dirt out of components, etc)
<Fujitsu> It's annoying.
<ajmitch> dick smith electronics store?
<Fujitsu> And, as you say, the complete expensiveness of anything electronic, and the patheticness of most tools, is really annoying.
* Fujitsu runs away from Australia.
<infinity> ajmitch: Dick Smith is useless.
<Fujitsu> Hmm.
<Fujitsu> I gave up on DSE ages ago.
<ajmitch> infinity: usually, but that's about the only place I know of here that would have it
<Fujitsu> Jaycar I often use...
<ajmitch> hey zul  :)
<Fujitsu> Morning, zul.
<bddebian> Hi zul
<zul> hey
<bddebian> :-)
<zul> are we that bored?
<bddebian> Yep
* infinity idly wonders why this 4-port SATA controller came with *3* SATA cables...
<Fujitsu> Heheh.
<infinity> I mean, sure, I'm not much good at counting past 3 either, but c'mon...
<mdke> 1, 2, 5
<mdke> (3 sire)
<Fujitsu> Yay... Two weeks until Dapper is deployed on our mail/web server at school.
<Fujitsu> The Holy Hand-grenade!
<infinity> mdke: Brits aren't allowed to quote that...
<mdke> explain yourself
<mdke> it's all we do
<Fujitsu> :O
<infinity> mdke: It destroys the illusion that only foreigners like Monty Python.
* Fujitsu throws the hand-grenade at mdke.
<zul> chicken of bristol?
<bddebian> heh
<infinity> (Much like, only foreigners like Degrassi Jr High, which is so painfully true)
<zul> heh my wife likes degrassi jr high
<Fujitsu> Yep, very true.
<infinity> mdke: I would consider the quoting of slighty-less-commonly-exported humour to be acceptable, like Black Books, perhaps.
<Fujitsu> Black Books is great1
<Fujitsu> *!
<zul> black adder is funny
<mdke> infinity: I'll go and order myself a box set immediately
<infinity> mdke: Excellent.
<infinity> mdke: I get a comission on each DVD sold.
<mdke> heh
* mdke goes to buy the complete works of monty python and faulty towers
<zul> heh...dont mention the germans
<zul> or the war either
<Fujitsu> *Fawlty Towers
<infinity> Is there nothing more horribly ironic (and sad) than installing Windows 2 days after the Ubuntu release? :/
<Fujitsu> ?
<infinity> (reinstalling my girlfriend's Windows/Pornoshop beast)
<Fujitsu> D:
<infinity> Now with a terrabyte RAID.
<mdke> :(
* Fujitsu throws the hand-grenade at infinity's girlfriend's house.
<infinity> Yessir, that's love.
<Fujitsu> NO more Windows problem.
<ajmitch> I used to think that a terabyte was quite a bit
<ajmitch> but now we can buy single drives about that size already
<Fujitsu> Like Seagate's 750GB.
<infinity> ajmitch: Yeah, I'm installing the 4 300GB drives at the same time as reading reviews for 750GB drives.  Suck.
<ajmitch> same old thing
<ajmitch> my 3x250GB RAID seems small now
* Fujitsu shall be deploying 3x 300GB SATAII drives in a RAID 5 config at school in a couple of weeks.
<infinity> OTOH, Australia won't see thoe 750GB drives at a reasonable price for, like, 5 years, so whatever.
<Fujitsu> Big server revamp, including partial Ubuntu conversion.
<Fujitsu> infinity, only 5 years!?
<ajmitch> Fujitsu: dapper?
<Fujitsu> ajmitch, yes.
<infinity> Fujitsu: I just buy hardware and sneak it home everytime I visit North America.
<Fujitsu> Hehhe.
<infinity> Fujitsu: Sadly, it's the only way to get anything new without spending half my salary.
<Fujitsu> Yay for being a student admin on a ~200 workstation network.
* Fujitsu throws the school's Exchange CDs away.
<Fujitsu> (yes, we're using Exchange at the moment)
<infinity> My purchased-in-America Thinkpad still retails here for what I paid for it a year ago.
<Fujitsu> Yeah, Australia is silly.
<ajmitch> and NZ is determined to follow
<infinity> OTOH, this gives me high hopes for being able to eBay it at a good price when I upgrade.
<infinity> Fujitsu: Unless you're in the market for a "guaranteed to work with Ubuntu, cause a core-dev owned it and made sure of that" laptop? :)
<Fujitsu> infinity, no. I've got my Dell Inspiron 630m here. Almost works perfectly, only a couple of open bugs.
<Fujitsu> infinity, it's good to have a proper Ubuntu dev. in Melbourne :)
<ajmitch> maybe I should flog off my laptop that way..
<mdke> me too
<mdke> and anyone else with the same laptop as infinity 
<Fujitsu> Heh.
* Fujitsu goes back to helping in #ubuntu.
* infinity suspects that with the Thinkpad ownership in Canonical, you just plain can't go wrong buying IBM/Lenovo, if you want it supported.
<Fujitsu> Heheh. Good.
<infinity> Though not enough of us have managed to get our hands on T60/X60 hardware to guarantee anything there yet.
<infinity> (A T60 is high on my list of "stuff to buy when I get around to it)
<Fujitsu> So, how long until Edgy development starts moving properly?
<ajmitch> really moving? after paris, I guess
<infinity> It'll slowly start trickling in around Tuesdayish.
<TheMuso> My R50 works perfectly. Can't complain. :) And this was before Ubuntu came out.
<crimsun> Fujitsu: see https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-June/000144.html
<Fujitsu> That's one list I'm not on...
* Fujitsu joins.
<Fujitsu> Thanks, crimsun.
<infinity> There will be some mass syncs happening next week, but Ubuntu-specific feature devel likely won't happen until post-Paris.
<Fujitsu> Aha.
<infinity> We should have a large chunk of sid synced into edgy before Paris, though.
<infinity> Modulo some outstanding merges here and there.
<ajmitch> so don't bother trying to upgrade then
<infinity> ajmitch: MOTU should have a much easier time, with our X coming into sync with Debian's.
<ajmitch> thankfully
<infinity> ajmitch: You should be able to drop changes on most of the stuff in universe.. Hopefully.
<Fujitsu> Damnit.
<ajmitch> and we'll be able to drop the python2.3/2.4 mess soon
<Fujitsu> Mekong has been down for almost 24 hours now.
<infinity> ajmitch: If you run into any snags along those lines, let me know, and I'll make sure to push whatever transitional changes we need into sid/etch.
<Fujitsu> It's really annoying.
<infinity> ajmitch: python2.4 in sid should be happening in the next week or two.
<ajmitch> we agreed to drop zope2.8 from sid last night, iirc
<infinity> ajmitch: Of course, doko may decide that he wants to try python2.5 in edgy. :)
<infinity> (Probably not, though)
<ajmitch> even if doko wants 2.5, the python-support stuff should avoid having lots of python2.5-* packages
<infinity> Hopefully.
<ajmitch> zope2.8 is the last big user of python2.3 specific packages in dapper, we can drop it for edgy
<ajmitch> I had to add a couple of python2.3 packages to universe, taking source from main
<ajmitch> a nasty mess :)
<Fujitsu> Why?
<ajmitch> zope2.8 requires python2.3-xml, for example
<infinity> zope2.8 should just die anyway.
* Fujitsu stabs zope2.8 with a silver stake.
<ajmitch> it will
<ajmitch> soon
<infinity> Then again, I think zope in general should just die, but others may disagree. :)
<ajmitch> heh
<mdke> haha
<ajmitch> the main use I have of zope is plone
<infinity> Which should ALSO die.
<mdke> and launchpad :)
<infinity> Of course, the main use for zope that I have is launchpad, so whatever.  I'm stuck with it.
<ajmitch> lucky
<Fujitsu> Heheh.
* Fujitsu goes and steps on some bugs
<LaserJock> infinity: so LP should die too? ;-)
<ajmitch> LaserJock: don't ask those questions in a publically logged channel
<Fujitsu> Are there enough ubiquity bugs?
<infinity> Fujitsu: If you touch ubiquity bugs, Colin *will* hurt you.
<infinity> (Unless you're touching them to include patches)
<Fujitsu> infinity, aha. I dealt with a few yesterday, asking them to attach the appropriate logs.
<LaserJock> ajmitch: hmm, hadn't thought about that
<Fujitsu> And Colin modified all of them shortly afterwards.
<Fujitsu> How many Canonical-based Ubuntu devs are there?
<infinity> Fujitsu: Oh, asking people to attach logs is fine.  Just don't go duping or rejecting or whatnot.
<Fujitsu> infinity, I thought so.
<infinity> Fujitsu: 99% of d-i/ubiquity bugs that looks like dupes aren't.
<Fujitsu> infinity, I know :)
<infinity> Fujitsu: (Because "stuff doesn't install right" always looks the same to most people)
<Fujitsu> Because they all look practically the same.
<infinity> I have the same problem with initramfs-tools. :/
<Fujitsu> It'd be nice if they didn't die with what looked like the same error...
<infinity> "Hey, it can't find MY root filesystem either, this is totally the same bug!"
<infinity> ARGH.
<infinity> I just wish people would file new bugs instead of commenting in ones that they think are "the same bug"
<infinity> Makes it impossible to sort out when one of the 30 bugs in the comment list has been fixed.
<Fujitsu> Yes, it's irritating.
<zul> infinity: very irritating
<Fujitsu> Although it must be bad for the people that actually have to deal with them.
<crimsun> my favourite is inlining huge pastes of semi-relevant information.
<Fujitsu> YEs.
<infinity> I like the ricer kids that need to tell you every piece of hardware in their system.
<Fujitsu> Like, multi-hundred line ones in the root.
<Fujitsu> Hmm
<infinity> "I have an ASUS whizzbang motherboard and an Athlon64 4000+, is my CPU too fast for Ubuntu?"
<Fujitsu> Are reports that things don't install icons valid bug reports?
<Fujitsu> Heheheheh
<infinity> Fujitsu: Sure, icon and desktop file reports are valid wishlists.
<Fujitsu> OK.
<Fujitsu> I shall mark them as such (there are two new ones).
<bddebian> No they aren't :-)
<infinity> Fujitsu: Okay, to ME they're wishlists.  Alternately, you could make them critical and assign them to bddebian. :P
<Fujitsu> YES!
<Fujitsu> Hmm.
<Fujitsu> Why do we have to use Launchpad?
<Fujitsu> It's got no `Grave' severity.
<bddebian> infinity: Well as many as I have done you can if you want :-)
<infinity> I think the debbugs severities were deemed unfriendly.
<bddebian> Unless of course they are for main packages
<infinity> bddebian: You're welcome to provide .desktop and icon (and icon transparency, and, and) patches in bug reports for main packages.
<infinity> bddebian: I'm pretty sure I've done a few that other people left patches in.
<bddebian> Why, so they don't get uploaded like my kscd one? :-)
<infinity> bddebian: (And done a few without patches when they really irritated me, like the gnome-bluetooth stuff)
<bddebian> Sorry, that was pissy
<infinity> bddebian: You'd have to whine to Riddell about that one.  I don't touch KDE, except when it's FTBFS.
<ajmitch> bddebian: you assume that developers have time to look at bugs for every main package
<bddebian> Aye, I know
<bddebian> ajmitch: I don't assume anything
<bddebian> I did ask a couple people to take a look.  But when I ask too much I become a pain in the ass :)
<Fujitsu> Great.
<Fujitsu> Bug #48150
<Ubugtu> Malone bug 48150 in linux-kernel-headers "2.6.15-23 headers are not in the repositories" [Normal,Unconfirmed]  http://launchpad.net/bugs/48150
* Fujitsu rejects
<infinity> That's special..
<Fujitsu> Of course, he searched for kernel-headers.
<ajmitch> probably following a howto
<infinity> Fujitsu: That's actually a dupe of bug #35186
<Ubugtu> Malone bug 35186 in glibc "linux-kernel-headers should be renamed to linux-libc-headers for clarify" [Normal,Confirmed]  http://launchpad.net/bugs/35186
* bluefoxicy is still having trouble getting oprofile to profile individual binaries and list library usage in them ><
<infinity> Fujitsu: Well, sort of. :)
<infinity> Fujitsu: The fact that he filed it on "linux-kernel-headers" confirms 35186's assumption that we should really rename that package.
<Fujitsu> Hmm. Yes.
<Fujitsu> #35186 isn't /that/ hard to fix, is it?
<infinity> Lacks round tuits.
<infinity> I'm sure I'll do it for edgy, but I'd like to get the same change in etch/sid, to avoid even more confusion.
<Fujitsu> Heheh.
<ajmitch> next you'll end up as glibc maintainer..
<infinity> ajmitch: Too late.
<bddebian> heh nice
<ajmitch> my condolences
<infinity> ajmitch: I already joined the Debian glibc team, and jbailey and I are co-maintaining it in Ubuntu.
<bddebian> Then get to work on the hurd bits of glibc will ya? ;-P
<infinity> bddebian: Uhm, no.  That's not my thing. :)
<ajmitch> didn't realise you'd joined that team
<infinity> bddebian: I have my own useless port (m68k) to worry about, thanks.
<bddebian> heh
<Fujitsu> Heheh.
<ajmitch> today would be a good day to fix some of my debian bugs
<infinity> Okay, the guy at Sony/Ericsson who decided to put a really bright white LED on my phone was a GENIUS.
<infinity> (It's the only flashlight I own, and works great in tight spaces)
<bluefoxicy> hm
<Fujitsu> Hehe. Not bad.
<bluefoxicy> system wide total it seems 10% of code is executed in actual elf fixed position main executables.
<bluefoxicy> 8.2% of that so far is X
<bluefoxicy> does anyone think it's unreasonable to place a 6% performance hit here (on x86)?  Total impact appears to be (at a glance) 0.6%
<bluefoxicy> however I need to figure out htf to get oprofile to work better and do more fine-grained tests >:|
<ajmitch> bluefoxicy: pax?
<zul> bluefoxicy: let me guess you used gentoo at one point?
<bluefoxicy> ajmitch:  mm, actually just doing PIE
<bluefoxicy> ajmitch:  compiling a program as position independent executable imposes a 0.99% performance overhead.  Compiling with -fomit-frame-pointer gives a 5% performance increase; however, this is ineffective with PIE on x86.
<bluefoxicy> ajmitch:  assuming we rely on the 5% performance gain from -fomit, that's total 6% slow-down from PIE; but it only affects the main executable
<TheMuso> c
<TheMuso> sorry...
<bluefoxicy> The result of using a position independent executable is that the main executable .text segment and heap become segments in a dynamic elf binary, identical to a shared object.  This allows the base of the main executable AND the heap to take full advantage of existing mmap() randomization in vanilla linux since 2.6.12, as well as higher-entropy PaX randomization if a grsecurity kernel is used (which there is discussion of on
<bluefoxicy>  the wiki)
<bluefoxicy> in other words you get added security for free
<bluefoxicy> I'm trying to quantify 'free' by determining how much code actually executes in the main executable; so far, Xorg's main executable accounts for 8% of my CPU usage here for the whole system.  Using oprofile it seems that total (grepping out any image with .so in it) every main executable including Xorg uses about 10% of the CPU
<Fujitsu> Hmm.
<bluefoxicy> the next most intensive thing was The Battle for Wesnoth (0.54%), oprofiled (0.477%), gtk-gnutella (0.2581%), and metacity (0.0757%)
<bluefoxicy> however
<bluefoxicy> I have nfc how to really use oprofile
<Fujitsu> If a bug was caused by a dodgy BIOS, and was fixed by an update, is it invalid?
<bluefoxicy> I just started it up and then ran oreport to see wtf is going on :P
<bluefoxicy> zul:  Yes, I used gentoo with full PaX, PIE, and propolice.  Fedora Core 5 includes full FORTIFY_STACK, ProPolice (gcc 4.1 merged), light address space randomization via mainline and exec shield (with heap randomization not in mainline-- this breaks things occasionally), and a few daemons like Apache built as PIE
<bluefoxicy> zul:  I believe this may be a good direction for Ubuntu to take, with Edgy or Edgy+1; PIE is a hard argument because Theo de Raadt, Ingo Molnar, and Arjan van de Ven will all tell you that it's extremely expensive and makes the system unbearably slow without providing any use cases or numbers to back this up
<bluefoxicy> Theo, Ingo, and Arjan are all respected names in the community so everyone takes their statements as gold.
<bluefoxicy> (Theo's actual argument against me when I challenged him on the real overhead of PIE was, "I don't even know who you are.  Everyone knows who I am, I created openbsd, we invented this stuff")
<whiprush_> jdub: ping
<desrt> is there a similar mechanism to the replaces: header that allows the overwritten files to remain installed when the 2nd package is removed?
<desrt> (so that the overwritten files are only removed by removing the package to which the original file belonged)
<infinity> desrt: You mean, you want package B to say "when I'm installed, package A's files should go away, but they should come back when I'm removed"?
<desrt> no. that's impossible
<infinity> No, that's not, that's diversions.
<desrt> i mean i want a package to effectively upgrade a single file of another package
<desrt> actually
<desrt> that's quite fine, i guess
<desrt> how do i do this?
<infinity> man dpkg-divert
<desrt> thanks
<infinity> If you're just looking to upgrade package A, though, do that. ;)
<desrt> i want to replace a single file
<infinity> dpkg-divert is only sane if you really need package B to ship a file that shouldn't be in package A, but is needed by package B.
<desrt> what happens if A gets upgraded in the meantime?
<infinity> (See, for install, nvidia-glx and fglrx using dpkg-divert to use their own libGL.so.1.2)
<desrt> divert puts the new version of the stock file in its little storage cabinet for safe-keeping?
<infinity> That's the point of a diversion.  If you divert libGL.so.1.2 to /usr/lib/fglrx/libGL.so.1.2, the next time libgl1-mesa is upgraded, it's copy goes to the bogus location.
<desrt> nice.
<infinity> When the diversion is removed, the right file is moved back into place.
<infinity> It's a sketchy process, and best avoided in most cases, but useful when unavoidable.
<desrt> i like to learn.
<desrt> infinity; woo.  go dpkg-divert.
<bluefoxicy> here's a question
<bluefoxicy> 1.8% execution performance overhead
<bluefoxicy> For every 60 minutes of continuous maxed 100% CPU usage without a break, 1 additional minute of execution time is needed to complete the task.
<bluefoxicy> Honestly, do we care?
<sfllaw> bluefoxicy: It depends.  It's a bit of a loaded question you're asking.
<sfllaw> Foreground or background task?  Interactive or batch?  Latency or bandwidth constrained?  I/O or CPU driven?
<bluefoxicy> sfllaw:  system wide, compiler modification that allows a security guarantee to be made on the probability that any given instance of an attack can actually result in exploitation of a known security hole.
<bluefoxicy> sfllaw:  CPU driven.
<sfllaw> You mean you're adding in code to compiled applications?
<bluefoxicy> no
<sfllaw> Or is this static analysis?
<desrt> ok.  next task
<desrt> learn how to install an initscript
<bluefoxicy> sfllaw:  open a shell and do:  /lib/libc.so.6
<bluefoxicy> sfllaw:  (just trust me on this one, it'll work)
<sfllaw> I know it does.
<bluefoxicy> ok
<bluefoxicy> You know why that works right?
<bluefoxicy> libc.so.6 has a _main(), and is thus an executable program, but is position independent and all because it's a library
<sfllaw> Yes.
<bluefoxicy> well on IA-32, doing this to a program causes a 0.99% decrease in execution speed of the code in the main executable of the program; also, using -fomit-frame-pointer normally gives a 5% increase in execution speed, but this is completely ineffective with position independent code.
<bluefoxicy> 6% total decrease in execution speed of the code
<Burgundavia> crimsun: you around?
<bluefoxicy> However, system-wide, according to oprofile only 10% of the code executed on my system in a half hour was in any main executable; 8% of that was in Xorg (spends a lot of time in the main executable huh?) and the rest were all around 1/2 percent except battle for wesnoth
<bluefoxicy> Overall, that's a 0.6% decrease in execution speed (10% of the time you're in code that's 6% slower?)
<bluefoxicy> sfllaw:  However, I am guessing that the time spent in the main executable ranges from 1% to 30% and saying this is 0.06% to 1.8% performance hit
<bluefoxicy> (percent of time spent in affected code times slowdown on execution of said code)
<bluefoxicy> sfllaw:  Randomization of the stack and mmap() base is nice, but a really crafty attacker can inject his stack frames in the heap (at a known base address) and return to a 'call system()' instruction with SFP putting the pointer somewhere appropriate in the heap
<bluefoxicy> this would give a pretty damn workable method of completely nullifying the protection afforded by mmap()/stack randomization with 100% efficiency
<sfllaw> Are you proposing that we take out -fPIC for IA-32?
<bluefoxicy> uh hell no.
<bluefoxicy> Opposite way
<bluefoxicy> (and also you can't take -fPIC out for IA-32, libraries break massively)
<bluefoxicy> By making the main executable a PIE, it suffers the noted performance slow-down; however, it also makes the described attack impossible, as the main .text segment is randomized via mmap() and the heap is an anonymous mapping randomized via mmap() (I *THINK* you need extra kernel code to actually randomize the heap though... I'm not sure it gets stuffed into the GOT)
<bluefoxicy> thus you can make a security guarantee that security attacks based on buffer overflows, double free()s, etc are likely to succeed 1 in every 2^27 times (134 million fail states, 1 success state)
<bluefoxicy> in theory
<bluefoxicy> I'm proposing that the main executables be built -fPIE (-fPIC for main executable) on all architectures, I just want to get a heads up on what the reaction to the predicted performance impact will be like :)
<bluefoxicy> sfllaw:  too much shit to think about at 1am?  :)
<sfllaw> Hmm.
<sfllaw> I think it will be slightly controversial.
<sfllaw> But not very.
<bluefoxicy> likely.
<bluefoxicy> I have had trouble with this in the past, tried to convince Arjan and Theo on it and they're.. well
<bluefoxicy> Arjan just evaded the issue
<bgertzfield> Theo is Theo.
<bgertzfield> What can you do?
<bluefoxicy> Theo insisted that PIE is 'very expensive' and that the system would become excessively slow
<bluefoxicy> and when I began to explain to him how encoding algorithms, compression libraries, plug-ins for anything, rendering engines, painting, etc are all in libraries and not affected (they're PIC anyway but it doesn't matter either way)
<bluefoxicy> his retort was that he didn't know who I am, and that he is the project lead for OpenBSD and "we invented this stuff" so he knows more about it than me :P
<bluefoxicy> Needless to say I'm expecting a lot of resistence
<sfllaw> Draw up a spec.
<bluefoxicy> I KNOW RedHat has papers out (penned by Arjan) that say PIE has excessive, non-managable overhead; I don't know about OpenBSD.  As for me, i've run the stuff before (Gentoo)
<sfllaw> Edgy is cutting-edge.
<Burgundavia> bluefoxicy: please focus on the good and not on Theo
<bluefoxicy> Burgundavia:  he's not ALL bad, just a little egoey :)
<bluefoxicy> sfllaw: https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/ProactiveSecurityRoadmap  This is from back in Breezy, I didn't pen this one.
<Burgundavia> bluefoxicy: regardless of who he is, this is not the place to disucss it. But good work
<bluefoxicy> I added to it in a bunch of places and restatused it from BreezyGoal to EdgyGoal although I am sure only a few things can possibly make Edgy.
<bluefoxicy> Burgundavia:  nod.
<bluefoxicy> I need sleep soon anyway
<bluefoxicy> I'll stop cluttering #-devel in a few minutes
<bluefoxicy> I also have to at least get something written about memory protection policies before I can hit send.
<bluefoxicy> so g'night all.
* bluefoxicy has to be up early tomorrow
<desrt> ow.  mine eyes.
<ajmitch> heh
* desrt just cooked up 3 .deb's that he doesn't even want to know what lintian would say about
<Burgundavia> what for?
<desrt> macbook brightness control
<Burgundavia> ah
<Burgundavia> is there not a sane place for all these little pieces of code?
<desrt> ya.  it's called hal :)
<Burgundavia> ah
<bluefoxicy> <desrt> macbook brightness control
<Burgundavia> so have you submitted your code to HAL?
<bluefoxicy> desrt:  And for desert we have fried testicles.
* bluefoxicy knows somebody who placed a macbook on his lap.  45 seconds later he had burn marks on his knees, they were still there the next morning.
<desrt> Burgundavia; nope.
<desrt> Burgundavia; hal extension
<desrt> Burgundavia; hal is a bloody mess right now.  davidz told me to stay away :)
<Burgundavia> ah
<desrt> Burgundavia; but he's going to merge it into CVS once he gets it back under control
<Burgundavia> lots of little ifdefs for specific hardware?
<desrt> no.  structurally messy
<Burgundavia> ah
<desrt> and not generally working from the sounds of it
<Burgundavia> that being fixed?
<desrt> i hope so :)
<desrt> muh
<desrt> g-p-m is giving me grief
<desrt> now i have to patch the kernel
<desrt> what a riot that will be.
<jdub> whiprush_: pong
<whiprush_> jdub: is it my feed that's busted or planet? I wanted to inline some pics from our release party.
<jdub> whiprush_: i am going to ahve to look into it more deeply; it was okay for a bit, now it's back to poo
<whiprush_> yeah
<whiprush_> no problem, I just made a link.
<ajmitch> morning fabbione 
<fabbione> morning
* sivang came to see what's cracking hre, seeing all quite, goes back to watchign futurama
<ploum> Hello,
<ploum> I've heard that canonical will soon need to hire a lot of people
<ploum> But I don't see anything new on the Ubuntu jobs page
<ploum> anyone has informations ?
<sivang> ploum: where did you hear this? :)
<ploum> sivang: on planet.ubuntu probably
<ploum> cannot well remember
<ploum> But a few days ago, it crosses my mind that I will need a job in september. And why not trying to live from my passion ?
* sivang pokes planek
<sivang> planet , even
<ploum> I remember somthing like "24 new open positions"
<ploum> Hope that it wasn't a dream
<ploum> http://www.markshuttleworth.com/archives/35
<G0SUB> ploum: I like your humorous posts
<ploum> G0SUB: thanks :-)
<ploum> it's new to me to make this kind of posts in english
<G0SUB> ploum: I see, but you doing very well
<G0SUB> you are
<ploum> Don't say too much or everyone will understand that I'm paying you
<G0SUB> ploum: heh, nothing like that
<ploum> ;-)
<G0SUB> ploum: you are our very own jester ... the jester in the court of sabdfl
<ploum> hmm... don't know if it's good or bad ...
<G0SUB> ploum: not bad really :)
<sivang> jester?
<sivang> ploum: what kind of post?
<ploum> sivang: like my last post about flying cars.
<G0SUB> sivang: most of his posts are funny
<sivang> ah, cool
<hunger> When will the edgy repositories open?
<G0SUB> hunger: 06 June - 07 June
<Fujitsu> hunger, I believe it's a couple of days of.
<Fujitsu> Yes, what G0SUB said.
<hunger> Great. I just hope that somebody will fix suspend for my laptop there soon:-(
<Fjodor> G0SUB: I heard that kernel 2.6.16 breaks dapper's udev. Would that also be true of the kernels for edgy? When I was on breezy, I used dapper kernels, and would like to do the same with dapper/edgy
<G0SUB> Fjodor: some fix will be found out :)
<Fjodor> G0SUB: Great. I'll look forward to it :-)
<gouchi> hi
<gouchi> is there some stat about network activity of mirrors ?
<HiddenWolf> gouchi: I don't think so, but my torrent is not seeding at max capacity anymore, so downloading is fast enough
<hile> Fjodor: wel I'm using 2.6.16.19 and I haven't seen any udev problems
<hile> I just took the vanilla source package, copied dapper's default config from /boot and built a package with make-kpkg - no problems at all
<Fjodor> hile: Thanks for the info. I do like to have ubuntu kernels, though, so I'll wait for edgy, but thanks
<hile> yeah, the reason I wanted 2.6.16 originally was CONFIG_SERIAL_8250_RUNTIME_UARTS - now it seems it's not even needed, since we have CONFIG_SERIAL_8250_NR_UARTS=48 in default kernel
<Fjodor> hile: Ah :-)
<hile> well, in addition I'm using madwifi-ng... could of course use standard packages as well but since I already have 2.6.16 configured ... 
<Fjodor> hile: Yeah, I use madwifi-ng too. I build my own kernels, but as stated before, preferably from ubuntu sources (might have stated it a bit unclear earlier)
<G0SUB> Fjodor: I don't know how 2.6.16 breaks udev, I am on 2.6.16-ck11 and my custom config
<Fjodor> G0SUB: Fair enough. I might have been misinformed
<G0SUB> Fjodor: I would recommend that you GOOG a bit and try out yourself
<Fjodor> G0SUB: Ok. And thanks
<G0SUB> Fjodor: you can take my config but it's very lean
<Fjodor> G0SUB: Well, I don't need anything in particular, just want to have fairly new kernels as a principle ;-) Perhaps I should just let it rest for now, and get on with my exams :-) But thanks for offering
<G0SUB> Fjodor: same here, I don't remember when I was the last time that I used a distro kernel
<G0SUB> agh
<Fjodor> Well, I mainly like ubuntu kernels because they let me suspend my laptop. I heard it could be a prob otherwise
<ploum_> Is seb128 already gone ?
<HiddenWolf> he should be, if he knows what's good for him. :)
<ploum_> anybody knows who is hidden behind hr@canonical ?
<lifeless> ploum_: people
<ploum_> lifeless: I will send my CV to them.. Have you any advice for me ?
<lifeless> all the general applying-for-job-advce
<ploum_> nothing special then..
<ploum_> well, so I just have to hit "send"
<LinuxJones> ploum_, janew
<ploum_> Thanks 
<HiddenWolf> wow, ubuntu.com looks different
<HiddenWolf> sweet!
<makko> INSTALLER CRASHED :((
<makko> http://pastebin.com/755357
<makko> please help me
<makko> is it a known issue?
<\sh> makko: file a bug pls...and tell us where it crashed..
<Fujitsu> makko, file a bug. It's the easiest way to get it fixed.
<makko> \sh: anyway, how relevant is my pastebin quote?
<Fujitsu> makko, please include /var/log/syslog and /var/log/installer/syslog as well.
<\sh> makko: without a context? I can only determine that it's kde-ui :)
<makko> \sh: oh, i see
<\sh> makko: so you need to give us a hint where and when it happened (locale selection, partitioning etc.) something like this, and better a procedure how to reproduce it
<makko> all default, except i also passed through manual partitioning (where i left everything default too)
<makko> what is the gnome alternative to kde-ui?
<makko> gnome-ui?
<makko> (gnome-ui doesn't work)
<\sh> makko: on kubuntu desktop cd you will have ubiquity with kde-ui and on ubuntu desktop cd the gnome ui...
<makko> how can i use ubiquity with gnome ui when i am on kubuntu?
<Fujitsu> gtk-ui, I think.
<Fujitsu> makko, it's not a UI issue.
<Fujitsu> makko, it's an internal issue. Please file a bug.
<makko> Fujitsu: i am on a live cd session right now and i already erased my old ubuntu... all i have is the home partition
<makko> Fujitsu: i don't even feel like filing bugs atm
<Fujitsu> makko, that's the only way you're going to get it fixed.
<makko> Fujitsu: but i will certainly do that later
<makko> Fujitsu: and btw how can i make sure somebody else hasn't already done it?
<Fujitsu> makko, anything special about your setup?
<makko> Fujitsu: no, really not
<Fujitsu> makko, don't try. A lot look like duplicates, but aren't really.
<makko> Fujitsu: kubuntu, almost everything default
<makko> Fujitsu: but is ubiquity really so... unpredictable?
<Fujitsu> Can you please pastebin your /var/log/syslog and /var/log/installer/syslog?
<makko> Fujitsu: sure
<Fujitsu> makko, it's buggy in some situations at the moment.
<makko> Fujitsu: please wait
<Fujitsu> I'll look at them and try to work out what's up.
<makko> Fujitsu: thank you very much
<makko> wow! all of it??
<Fujitsu> Yes.
<Fujitsu> Hi, voltage.
<makko> Fujitsu: http://pastebin.com/755387 (installer)
<Fujitsu> Thanks,.
<makko> Fujitsu: i thank you!
<makko> http://pastebin.com/755394 (general syslog)
<makko> Fujitsu: http://pastebin.com/755394 (general syslog)
<makko> Fujitsu: and... any first impressions?
<Fujitsu> Hmm.
<Fujitsu> Did anything odd happen around language selection?
<makko> Fujitsu: nothing at all
<makko> Fujitsu: i chose american
<Fujitsu> Hmm.
<Fujitsu> There are some odd filesystem errors.
<Fujitsu> And it eventually crashes when trying to create a directory that already exists.
<makko> Fujitsu: any workaround?
<makko> Fujitsu: i will delete it!
<makko> Fujitsu: what is the dir?
<Fujitsu> However, you'll have to wait for somebody more qualified than me to work out what the source of the problem is.
<Fujitsu> makko, don't try.
<makko> Fujitsu: then?
<Fujitsu> makko, you'll probably break something else.
<Fujitsu> Your best bet is to file a bug, unfortunately.
<makko> Fujitsu: what is there more to be filed than the two files?
<Fujitsu> Just attach those two to the bug report.
<makko> Fujitsu: could you *please* do this for me?
<makko> Fujitsu: i never filed bug reports
<makko> Fujitsu: before
<Fujitsu> OK.
<Fujitsu> Can you just give me the output of `sudo fdisk -l'?
<Fujitsu> Hi, ogra.
<makko> Fujitsu: http://pastebin.com/755403
<makko> Fujitsu: this is the output
<Fujitsu> Thanks.
<makko> Fujitsu: i know i have quite some partitions
<makko> Fujitsu: i thank you
<makko> Fujitsu: any one of them that looks strange?
<Fujitsu> Not really.
<makko> Fujitsu: do the logs specify which partition should be the problem?
<Fujitsu> No, it just complains that one of them is a bit odd.
<makko> Fujitsu: do it doesn't mention which one....
<makko> Fujitsu: SO it doesn't mention which one....
<makko> sorry
<makko> ok
<makko> Fujitsu: what else would be necessary?
<Fujitsu> That should be enough.
<makko> Fujitsu: how am i gonna take advantage of the fix?
<Fujitsu> THat's a good question.
<makko> Fujitsu: do i simply need to apt-get install ubiquity on the live cd before installing on the hdd?
<Fujitsu> It might be an idea to get hold of the alternate CD for now.
<Fujitsu> The alternate CD will let you install now, although it's text based.
<ogra> guys, can you take that to #ubuntu please ?
<makko> ogra: sorry
<abattoir> Kamion: hello :) . I am working on the Kubuntu OEM Installer as part of SoC. I was asked to show you the spec.
<abattoir> https://launchpad.net/distros/ubuntu/+spec/kubuntu-oem-installer
<HiddenWolf> abattoir: as far as I know all developers are taking a few days off, or they should be :)
<pygi> abattoir, that is supposed to  be approved by Monday ;)
<\sh> paris is coming
<\sh> (no not the paris hilton)
<pygi> abattoir, looks great, congrats ;)
<abattoir> pygi: good afternoon :)
<pygi> abattoir, you too ;)
<abattoir> pygi: thanks. :D 
<abattoir> nah, its late evening here 
<abattoir> ;) 
<pygi> ok, good evenin' ;)
<abattoir> lol, thanks
<pygi> "Make Image" would be what?
<pygi> A backup? :)
<abattoir> HiddenWolf: oh, i didnt know that.... they deserve it too...
<abattoir> pygi: creation of a hard disk image
<pygi> abattoir, for that you might be able to use HUB ;)
<abattoir> this would then be replicated on N no. of hard disks
<abattoir> pygi: heh, i am not sure that application is needed, that's why i need to ask Kamion.
<abattoir> pygi: thanks for the suggestion, i'll look into it :)
<abattoir> pygi: and are you not taking a break? ;) 
<\sh> abattoir: for mass installation? 
<pygi> abattoir, who gives me any kind of break? :P
<abattoir> \sh: yes
<abattoir> pygi: you should take it yourself :D 
<\sh> abattoir: better to do it with kickstart or fai ;)
<pygi> abattoir, it's not really needed as part of OEM installation, tho
<pygi> abattoir, heh
* abattoir googles for kickstart and fai ;)
<\sh> abattoir: use kickstart first, that's easier...and FAI http://www.informatik.uni-koeln.de/fai/
<abattoir> pygi: yes, i know, but it would simplify the process wouldnt it? if i have the time
<abattoir> \sh: thanks :) 
<\sh> abattoir: fai is more datacenter mass installation...kickstart is more redhat style ;)
<pygi> \sh: o joy, redhat :P
<abattoir> \sh: oh, ok, thanks again :) 
<LinuxJones>  \sh for mass installation/software upgrades system installation suite is the way to go :)
<\sh> pygi: i think whiprush_ was doing a presentation of mass ubuntu desktop roll outs and kickstart..
<\sh> LinuxJones: that's what I'm doing with fai
<LinuxJones> \sh, oh let me have a look
<\sh> LinuxJones: one machine in less then 60 seconds (debian, ubuntu or suse) and later doing the company application configuration via cfengine...works very good...
<\sh> bah...it's 15:28 already and I need to go shopping .. bbl in 2
<LinuxJones> \sh, 60 seconds ?
<jpatrick> LinuxJones: too late
<LinuxJones> :(
* ogra lols about bug 48212
<Ubugtu> Malone bug 48212 in ltsp "ltsp's dhcpd fails after server is hibernated" [Normal,Unconfirmed]  http://launchpad.net/bugs/48212
<StevenK> ogra: Reply back with "Intended behaviour." ? :-)
<StevenK> Actually, it seems to be a real bug.
<ogra> StevenK, well, its one line in the acpi scripts 
* StevenK nods.
<ogra> to make it shut down and start up again, but i'd never ever have remotely thought of such a case :)
<StevenK> ogra: Meh. That's what users are for. :-)
<ajmitch> users can be very creative
<ogra> yeah ;)
<highvoltage> ogra: i don't understand what's funny about that bug :(
<highvoltage> ogra: is dhcpd supposed to stop working after coming out of hibernation?
<StevenK> Apparently.
<StevenK> dhcpd is well, crap to say the least.
<highvoltage> heh.
<ogra> highvoltage, well, its a server, i wouldnt expect anybody to hibernate servers :) 
<ogra> but its easily solved by adding dhcp to the acpi scripts that shut down services
<highvoltage> ogra: yes, i can see why that part is funny. it would be even more funny if the user complained that dhcpd didn't work while the server was hibernated :)
<ogra> heh#
<StevenK> highvoltage: That was what I thought when I saw the subject line. :-)
<ogra> indeed its a bug and needs fixing
<StevenK> Hence my comment: [23:41]  < StevenK> ogra: Reply back with "Intended behaviour." ? :-)
<ajmitch> ogra: maybe the server hibernates at night :)
<ajmitch> they have to have their rest sometime
<ogra> heh
* StevenK is very hard on his servers.
<StevenK> No hibernating for them.
<bddebian> Howdy
<ajmitch> hello bddebian 
<ajmitch> StevenK: I don't even let my laptop sleep
<bddebian> Hi ajmitch
<StevenK> If they start pandering for equal rights, I'll consider it.
<StevenK> ajmitch: I find waking up my laptop from hibernating is quicker.
<StevenK> ajmitch: Also, my previous laptop wouldn't hibernate in Linux, so I like it.
* Hobbsee wonders what the point of having a server on a laptop is.
<StevenK> Some desktops can hibernate.
<ajmitch> Hobbsee: why not?
<Hobbsee> good point.  again, why?
<ajmitch> development work :)
<StevenK> If it breaks, you have a screen and keyboard right there.
<Hobbsee> ajmitch: well, if you're never going to turn it off, then why have it being portable and relying on batteries?  servers dont usually move, i thought!
<ajmitch> StevenK: I just leave my laptop running anyway
* Hobbsee cant really sleep with her laptop on - although i did once.
<ajmitch> Hobbsee: because I can drag my laptop closer to the heater
<StevenK> Heh
<Hobbsee> hehe.  i forgot about that.
<highvoltage> Hobbsee is s 'her'? /me didn't realise :)
* Hobbsee has no luxury of a heater.
<StevenK> Aww
<Hobbsee> highvoltage: quite possibly.
* StevenK warms Hobbsee up.
<ajmitch> highvoltage: yes, we have some of their kind around
* highvoltage checks the hobbsee launchpad page
* Hobbsee does not have her gender listed there.
* Hobbsee does not have her picture there, for the same reason.
<StevenK> Heh
<highvoltage> yeah, i'm hoping it links to a blog or web page or something
<ogra> Hobbsee, edubuntu ltsp servers are a bit different, you use them in a classroom and hibernating might be faster than shutting them down
<StevenK> It's nice to hope.
* Hobbsee does not blog, and it does not link to a website that i used to run.
<Hobbsee> ogra: ahh...i see....
<StevenK> It just may not work.
* Hobbsee is ignorant :P
<ogra> Hobbsee, why all this shyness ? you should push ubuntu-women :)
<Hobbsee> ogra: you *really* want me to answer that?
<ajmitch> ogra: have you seen what -motu goes like at times?
<ogra> ajmitch, i didnt follow -motu much recently
* StevenK chuckles quietly.
<Hobbsee> hehe
* StevenK bashes two rocks together and proudly exclaims "Ugg!"
* StevenK proceeds to set up a Windows 2003 Server, since it's the next logical step.
<Hobbsee> ogra: well, let me put it this way.  If a girl walks into a room containing a whole group of males, what's the first thing that the males think and/or do?
<StevenK> Hobbsee: "Where's the beer?"
<ajmitch> s/males/sad, desperate male geeks/
<StevenK> Hah
<Hobbsee> heh
<ogra> well, at least i'd expect them to respect the CoC :)
<ogra> (in an ubuntu channel)
<Hobbsee> well...yeah...true...
<ogra> we have some females in #edubuntu and i'd kick guys that behave overly chauvinistic ( highvoltage as well i'm sure) :)
<Hobbsee> true
<KaiL_> Hobbsee, ask, is this girl is really a girl and after that, if she looks good? ;)
<Hobbsee> most of the guys are decent - but there some who are just disturbing - which is why i tend to be pretty quiet about my gender.  and age, come to think of it
<highvoltage> yes, i'll punch them, hit them, throw them off a cliff, electricute them... survivors will be kicked
<Hobbsee> hehe
<Hobbsee> KaiL_: hehe!
<HiddenWolf> highvoltage: I doubt that is CoC-approved behavior
<HiddenWolf> highvoltage: ;)
<highvoltage> HiddenWolf: i'll do it out of ubuntu ;)
<StevenK> I don't remember the CoC mentioning that throwing off a cliff is not allowed.
<highvoltage> "shall we take this outside of this room?" :)
<ogra> lol
<zul> StevenK,: you missed the super secret one
<Hobbsee> rofl!
<ogra> better "lest take it to #ubuntu-beatup"
<StevenK> highvoltage has this simplified, and has his lounge room facing onto a cliff.
<StevenK> "Come inside, and tell me your views on ..." *wait* *throw*
<highvoltage> StevenK: and, when they fall off the cliff, they fall into a pool, conveniently next to industrial toasters (plugged in of course)
<Hobbsee> ah, thanks guys for giving me a laugh.  i needed that.
* StevenK buggers off to bed.
<highvoltage> goodnight StevenK 
<Hobbsee> night StevenK 
<Hobbsee> so does that mean that throwing people off a cliff is CoC approved behaviour?
<ajmitch> undecided
<ajmitch> bring it up at a CC meeting
<highvoltage> Hobbsee: i think if you're not wearing your ubuntu shirt, it's outside of their jurisdiction (sp?)
<ogra> its not literally forbidden in the text
<highvoltage> we can file it under 'correctional behaviour'
<highvoltage> sorry if that doesn't make sense. my engrish is just gone today.
<Hobbsee> hehe!
* Hobbsee wouldnt fit into one of those tshirts :P
<Hobbsee> ogra: can i quote you on that?
<Hobbsee> :P
<ogra> sure, its true, isnt it ? 
<Hobbsee> :D
* Hobbsee goes racing around saying that ogra said that she could throw people off cliffs!
<highvoltage> Hobbsee: now, he didn't say that either ;)
<ogra> i didnt say that :)
<Hobbsee> well...
<Hobbsee> close enough :P
<Hobbsee> you inferred it...
<spacey> i think throwing people off cliffs is already covered by law
<ogra> well, might depend on the country :)
<spacey> in the netherlands we don't have cliffs
<spacey> i know
* ogra remembers seeing some concrete made artificial cliffs in rotterdam
<Hobbsee> hehe
<spacey> ogra: :p
<HiddenWolf> ogra: next time you get to rotterdam, allow me to buy you a beer. :)
<ogra> sure :) but the last time i was there is ~20 yrs ago
<HiddenWolf> oh, i'll have time to save up for the beer. :)
<ogra> so it might still take some time ...
<ajmitch> night all
<bddebian> Night ajmitch
<ogra> ciao ajmitch 
<Hobbsee> night ajmitch 
<eXistenZ> There is a bug in ubuntu dapper which hasn't been fixed from the beta
<G0SUB> eXistenZ: which one?
<eXistenZ> G0SUB, The cups one
<eXistenZ> G0SUB, I pasted the problem, let me give you the link
<G0SUB> eXistenZ: what's the bug id?
<sivang> ohm this became a bit noisy now :)
<sivang> what caused all the awakening ? :)
<eXistenZ> G0SUB, https://launchpad.net/distros/ubuntu/+bug/48173
<Ubugtu> Malone bug 48173 in Ubuntu "I keep getting that error in the cups error_log. There is something wrong." [Normal,Unconfirmed]  
<Hobbsee> sivang: i'm not sure...i think there was an impromptu irc post-release party or something :P
<eXistenZ> G0SUB, http://www.ubuntuforums.org/showthread.php?t=160041&highlight=foomatic-rip+status  , same problem here. 
<bddebian> heh
<Hobbsee> sivang: team building, i believe it's called :P
<G0SUB> eXistenZ: does the printing work or does that fail too?
<eXistenZ> G0SUB, It doesn't print at all
<sivang> Hobbsee: nice :)
<eXistenZ> G0SUB, It stops
<sivang> I just logged into the channel 2 hours ego and it was silent 
<G0SUB> strange
<eXistenZ> G0SUB, it says "Printing: /usr/lib/cups/filter/foomatic-rip failed"
<Hobbsee> sivang: yes, it seems that way - must be while there's no development going on.  pity.  mind you, this is kinda fun :)
<eXistenZ> G0SUB, same error here: http://www.ubuntuforums.org/showthread.php?t=165993&highlight=foomatic-rip+status
<sivang> Hobbsee: hehe, Well, I'm not totally against off development chatter, if it has some developmental value :-)
<eXistenZ> G0SUB, In short, I've seen many posts about users complaining about this problem
<KaiL_> ubuntu-server fr Sparc not yet released?
<Hobbsee> sivang: ah yes.  and some people are good at rubbishing, to twist things into what they want them to say :P
<G0SUB> eXistenZ: this bug got overlooked probably because of its unconfirmed status
<eXistenZ> G0SUB, seemingly
<eXistenZ> G0SUB, I have to go to windows everytime I want to print something. This is breaking down my nerves ;-)
<ogra> well, given the fact that it was filed today, its hard to fix it before release
<eXistenZ> ogra, I've seen many bugs for this problem
<eXistenZ> ogra, all unconfirmed
<eXistenZ> ogra, let me give you some links
<G0SUB> eXistenZ: why did you file it again then?
<giftnudel>  make a list of those and we will mark them duplicates then
<eXistenZ> G0SUB, Just now I figured out that it was posted many times
<KaiL_> btw. there was somebigger rant about cups on ubuntu on pro-linux.de - ogra do you know something about that? ;)
<G0SUB> eXistenZ: hmm
<Hobbsee> KaiL_: there was in #kubuntu earlier
<Hobbsee> too
<ogra> KaiL_, i dont read pro-linux.de
<KaiL_> you didn't miss that much ;)
<ogra> (in fact i dont have much time to read any online news anymore since my workplace is the net)
<KaiL_> http://www.pro-linux.de/cgi-bin/NB2/nb2.cgi?send-edit.9774.3010.80000010044. - maybe you understand, what he wants?
<eXistenZ> G0SUB, Do you think this bug will be fixed?
<ogra> KaiL_, thats a pretty random rant
<G0SUB> eXistenZ: provided the developers notice it
<eXistenZ> G0SUB, Aren't you a developer
<G0SUB> eXistenZ: not that package
<ogra> KaiL_, he obviously doesnt understand/know our security concept of "no open ports by default"
<G0SUB> eXistenZ: i don;t even have a printer to test it
<Hobbsee> ack.  it's german.  i wonder if that was the same guy from earlier.
* Hobbsee translates vaguely in the background
<eXistenZ> G0SUB, look at this post, all have the same problem: http://www.ubuntuforums.org/showthread.php?t=64876&highlight=foomatic-rip
<G0SUB> hmm
<Hobbsee> sounds like it.  ugh. poor Ivoks got the blame from that.
<makko> what about the bugfixes for the desktop cd?
<makko> will there a new dapper desktop cd be released at a latter time?
<eXistenZ> G0SUB, It has been confirmed: https://launchpad.net/distros/ubuntu/+bug/45099
<Ubugtu> Malone bug 45099 in cupsys "client 1.2.0 to 1.1.2x server over IPP: cupsdAuthorize: Local authentication certificate not found" [Normal,Needs info]  
<shawarma> Let me just get this straight. In order to suggest something for discussion at the dev summit, I add the spec to some meeting... Which meeting? The only thing on the list that even vaguely makes sense is UBZ..
<highvoltage> shawarma: where are you looking?
<shawarma> https://launchpad.net/distros/ubuntu/+spec/easyvpn/+linksprint
<shawarma> highvoltage: I created the Wiki page, the spec and now I want to add it to the meeting. Am I missing a step somewhere?
<shawarma> I don't see the summit at https://launchpad.net/sprints either..
<highvoltage> shawarma: i'm not sure. i thought all we needed to do was create the spec in launchpad
<robitaille> pitti:  do you have a rough estimate of when the updates from firefox 1.5.0.4  will make it into dapper?
<pitti> robitaille: early next week, I think
<robitaille> ok, thanks
<bluefoxicy> ah shit
<bluefoxicy> I posted on the devel list with a major error  *o.o*
<bluefoxicy> pitti:  hi!
<\sh> whiprush_: ping
<HiddenWolf> does anyone have an idea about server load for the download sites?
<ogra> HiddenWolf, maswan has stats
<HiddenWolf> ogra: Just interested. I uploaded 20gb from my desktop since release
<maswan> http://www.acc.umu.se/technical/statistics/ftp/monitordata/ <- se.releases
<HiddenWolf> maswan: nice spike you've got there. :)
<maswan> HiddenWolf: Yeah, too bad we don't have more bandwidth. Next year perhaps. :)
<HiddenWolf> *cough* I'm seeing almost 600mbit/s
<HiddenWolf> maswan: you feel you need more? :)
<infinity> Hrm, that spike was a bit short-lived.  That's a bit disappointing.
<HiddenWolf> infinity: well, a lot of mirrors came online since breezy
<infinity> I guess after the initial "oo, it's out!" from the fanboys, interest wanes.
<maswan> infinity: It always drops in the evening
<maswan> Same for hoary, sarge and breezy
<infinity> Also, test0 needs a better name.
<maswan> infinity: It is a temporary machine loaned from work to serve a couple of isos out of ram.
<maswan> infinity: On wednesday we turn it off and return it.
<infinity> What, you mean you're not serving all of releases.u.c out of RAM on all the machines?  Pshaw.
<infinity> And I thought you had mad hardware hookups.
<HiddenWolf> heh
<maswan> No, and unfortunately we were a bit tight on time to try our new setup out, so yesterday we redid it. That's why we had to borrow the machine.
<HiddenWolf> I'm only pushing 100kb/s on the torrent here. I should be upping 120. :)
<maswan> We're not even at half a gigE now.
<infinity> I should probably be a good citizen and seed the desktop-i386 torrent for the good of all Australians, but I value my latency too much.
* HiddenWolf looks crossly at infinity
<ajmitch> there are probably enough seeding that one
<HiddenWolf> ajmitch: I'm still upping at my max, or close to my maximum. ;)
<infinity> ajmitch: Define "enough"... Not many users in .au have >= 1Mbit upstream, so every bit's helpful.
<infinity> ajmitch: Grabbing from a bunch of overloaded 256k Telstra users could be painful.
<ajmitch> true
<ajmitch> having only a 20GB data cap means that I can't leave it running for long, sadly
<HiddenWolf> ajmitch: ouch. :)
<ajmitch> yeah
<HiddenWolf> ajmitch: is that in our out?
<infinity> ajmitch: I'm only capped on download, not upload.  Their loss is my gain, I guess.
<ajmitch> 20GB for both
<ajmitch> as in, combined
<infinity> ajmitch: So, I'm okay to run webservers and stuff, but my pr0n downloading is limited.  Weird, I know.
<ajmitch> heh
<jdub> meanwhile
<jdub> what are you guys doing up?
<HiddenWolf> ajmitch: ouch. I'd be over that data limit already. 
<infinity> I guess the answer is to start hosting pr0n...
<infinity> jdub: Pot.  Kettle.
<ajmitch> jdub: I ask myself that same question
<jdub> infinity: then you can buy more downstream!
<HiddenWolf> jdub: not everyone is an aussie you know. ;)
<infinity> jdub: Or are you in the UK?
<jdub> nono, here at home
<HiddenWolf> jdub: we just want to be. ;)
<infinity> jdub: Right, then.  "What are you doing up?"
<jdub> though it was londonny on friday
<ajmitch> HiddenWolf: speak for yourself
<maswan> I had a 1 gig/day data cap on 100Mbit. That was kind of painful to run torrents on. :)
<jdub> JNST is a bit weird at the moment. i slept almost all day yesterday.
<HiddenWolf> ajmitch: the cute accent, sunny tan and the resistance to huge amounts of alcohol don't appeal to you? :)
<maswan> At home that is, not at the university
<infinity> maswan: Oh, that's just teasing.  "have a bunch of bandwidth that you CAN'T DO ANYTHING WITH"
<jdub> maswan: how's the mirror doing?
<ajmitch> HiddenWolf: I'm not allowed to like australia, I'm a kiwi
<maswan> jdub: Getting bored. :)
<maswan> http://www.acc.umu.se/technical/statistics/ftp/monitordata/
<maswan> We're not even hitting half the bandwidth we did thurs+fri
<HiddenWolf> ajmitch: good point. :)
<jdub> maswan: nice spike though
<maswan> jdub: yeah
<maswan> http://farbror.acc.umu.se/stats/monitordata/index.shtml
<jdub> fc4 was october?
<maswan> that's the coolest spike
<infinity> ajmitch: Anyone who can't correctly pronounce "fish and chips" can't poke fun at others.
<maswan> jdub: breezy!
<jdub> s/fc4/fc5/
<jdub> maswan: oh
<ajmitch> infinity: exactly, so the aussies shouldn't make fun of us
<jdub> http://www.acc.umu.se/technical/statistics/ftp/monitordata/img/Year.800.png
<jdub> ^ that one
<maswan> jdub: the one before is sarge, and then you can barely make out hoary on the "years"
<infinity> ajmitch: *splutter*
<infinity> ajmitch: Damnit, there's no "U" in "fish".
<jdub> fc5 was march
<jdub> mot much of a dent in your mirror
<ajmitch> you would have liked the GNOME tshirts for LCA this year
<maswan> jdub: We don't mirror it. :)
<jdub> ;)
<maswan> ubuntu, debian, mozilla, gnome
<jdub> you guys are All Class
<infinity> maswan: No kernel.org mirror?
<maswan> infinity: nah, ftp.du.se has one that's fast enough
<maswan> infinity: also within sunet (the swedish NREN)
<infinity> Ahh.
<infinity> I still remember back when I had enough disk space (and kernel.org was small enough) that I could mirror it at home.
<infinity> Good times, good times.
<infinity> Actually, I probably have enough space now, but not enough bandwidth to make it worthwhile anymore.
<jdub> WELCOME TO AUSTRALIA
<infinity> :/
<jdub> yeah 
<maswan> You guys should import some swedish or dutch bandwidth
<jdub> were you here when the southern cross line was cut?
<jdub> maswan: it tastes funny
<infinity> jdub: When was that?
* jdub takes his tongue off the cat 5
<ProN00b> hmm, can't you add something to auto detect dualscreens ?
<infinity> jdub: It may have been when I was in Cairns, dunno.
<jdub> infinity: hrm, a few years back.., i forget now!
<jdub> infinity: if it weren't so sad, it would have been funny;
<infinity> jdub: I've lived through enough bandwidth pain here to make it a major motivation for wanting to move back home.
<jdub> someone anchored through it or something
<jdub> and pretty much the entire country noticed
<jdub> "millions of voices all crying out at once"
<jdub> but, not just the geeks that time
<jdub> "is the internet slow today?" -> secretaries and so on
<infinity> No, everyone would notice as traffic was diverted and bounced off sattellites.
<jdub> infinity: what brought you / keeps you here?
<infinity> And latency went through the roof.
<infinity> jdub: Girl.  Is there ever any other reason for doing something silly like leaving cheap electronics and plentiful bandwidth behind?
<infinity> And snow.  God, I miss snow.
<jdub> no, and stop calling me girl!
<highvoltage> jdub: hey babe
* highvoltage ducks
<jdub> lucky i was kicking instead of slapping
<jdub> *thump*
<infinity> jdub: So, how often do you get called "Jeff Woff"?
<jdub> rarely these days
<infinity> I'll be sure to do it the next time I see you.
<infinity> All those silent letters at the end of your name offend me.
<jdub> i still get "wow" and "wog" sometimes
<jdub> it's often worth paying sharp attention to announcements at foreign airports
<ajmitch> those people obviously don't follow cricket
<jdub> one person still calls me jeff weff
<maswan> people follow cricket?
<infinity> maswan: My thoughts exactly.
<ajmitch> it's been known to happen
* mdke shakes his head sadly at infinity and maswan 
<infinity> People only foloow cricket when they're no good at any real sports.
<mdke> !!
<maswan> Sure those weren't englishmen? They can make for a pretty convincing people-imitation at times.
<mdke> yeah
<highvoltage> jdub: are you related to the cricket player? you know that south africans don't quite like him? :)
<jdub> highvoltage: not related, no
<jdub> infinity: 20/20 seemed pretty good
<mdke> anyone know anything about fonts?
<mdke> I'm trying to find the file that provides the OpenSymbol font
<_ion> luotain% dpkg -L ttf-opensymbol | grep '\.ttf$'
<_ion> /usr/share/fonts/truetype/openoffice/opens___.ttf
<mdke> wow that's clever, thanks _ion 
<mdke> _ion: can you do dingbats too?
<jelkner> is there a font file that will always be on a dapper installation?
<_ion> mdke: luotain% grep -i dingbat /usr/share/fonts/**/*.cache*
<_ion> /usr/share/fonts/type1/gsfonts/fonts.cache-1:"d050000l.pfb" 0 "Dingbats:style=Regular:slant=0:weight=80:width=100:foundry=urw:index=0:outline=True:scalable=True:charset=  !!!!#      !!#3H    !(Uc[   !!#>K   !!!1%    !!#AL     (1S};!2fYk !!#DM>0}v}  !!!#9    !!#GN|>] fO|>^+~Ow1gH|>^0~{~h@FP0fQP  :lang=:fontversion=0:fontformat=Type 1"
<jelkner> _ion: were you answering my question on a know font?
<_ion> jelkner: No.
<jelkner> thanks
<mdke> thanks _ion 
<jelkner> we are trying to work around a bug in pygame involving fonts
<_ion> jelkner: Dapper might be installed without any fonts except for the ones you see in the Linux console.
<jelkner> _ion: which ones are in the Linux console?
<jelkner> we only need 1 known font
<_ion> jelkner: The ones that come from the BIOS or something. :-)
<jelkner> what if we assume x (pygame won't run without it)
<jelkner> but i want it to work on xubuntu, ubuntu, kubuntu
<highvoltage> bitstream vera sans is generally a safe bet with xubuntu/kubuntu/ubuntu/edubuntu
<_ion> jelkner: Well, apt-cache depends x-window-system-core | grep font  but the user might not have even x-window-system-core installed on a barebones installation with X. Why not simply add a dependency to some font to the games or perhaps pygame?
<jelkner> _ion: thanks, that's a grand idea ;-)
<HiddenWolf> dear god, it seems google loves python. :)
<HiddenWolf> 25 projects for SoC under python software foundation, only three for perl.
<_ion> Someone sould tell Google about Ruby.
* _ion ducks
<jdub> jelkner: look at the DejaVu fonts, they're in all three
<jelkner> jdub: thanks!
<mgalvin> there have been some dapper-updates uploads, is there a reason they have not hit the archive yet (or is it just me?)?
<mdke> no, same here
<infinity> Which ones haven't?
<pygi> mdke, mgalvin, use archive.ubuntu.com
* mdke guesses it is launchpad related
<mgalvin> pygi, i am
<pygi> mdke, perhaps sync to local servers has not been doen?
<mdke> pygi: i am
<pygi> done*
<mgalvin> infinity, evince for example
<pygi> hm :-/
<infinity> I've certainly seen some.
<mdke> none here, checked now
* infinity pokes drescher about evince.
<crimsun> pcmcia-cs, tetex-base at least are available in binary
<mgalvin> hmm and deskbar, the source packages are in the archive just not the binaries
<mgalvin> http://archive.ubuntu.com/ubuntu/pool/main/d/deskbar-applet/
<infinity> Oh, SPECIAL.
<infinity> Okay, it's a bug.  Thanks, guys.
<infinity> Will sort.
<roaet_> Anyone here have any luck getting dapper on a MacBook pro?
<mgalvin> seems all of seb128's and dholbach's latest uploads from https://lists.ubuntu.com/archives/dapper-changes/2006-June/thread.html
<mgalvin> infinity: cool thanks
<crimsun> heh, I was thinking the archive guys needed to push some big red button{,s}
<infinity> No big red buttons.  Just an overzealous REJECT policy, so the binaries are getting bounced.
<infinity> Will be fixed by Monday, I'm sure.  Just need to raise a flag with the right people.
<bddebian> NO, not the red button...
<HiddenWolf> anything, anything but the red button? ;)
<_lemsx1_> hello all
<_lemsx1_> how do i get libgcc_s.so.1 to be included in /etc/ld.so.cache ? adding /lib to /etc/ld.so.conf used to do the trick before (sudo ldconfig afterwards)
<_lemsx1_> i'm trying to solve:
<_lemsx1_> $> libgcc_s.so.1 must be installed for pthread_cancel to work
<_lemsx1_> (!) [10972:    0.000]  --> Caught signal 6 (unknown origin) <--
<crimsun> hmm? it's required and installed by default in libgcc1
<crimsun> libgcc1: /lib/libgcc_s.so.1
<infinity> _lemsx1_: What problem are you seeing exactly?  libgcc_s.so.1 (when installed) is definitely in my /etc/ld.so.cache
<_lemsx1_> infinity: the problem is that i have a program (splashy) that select()s a file handle waiting for it to change (same as usplash does)
<_lemsx1_> infinity: if 2 min pass and no changes are done, i get that error i pasted above
<_lemsx1_> crimsun: yes, i see the lib is in /lib in all my systems
<_lemsx1_> infinity: no, lib/libgcc_... is not in ld.so.cache... try it: cat /etc/ld.so.cache | strings | grep libcc
<_lemsx1_> $> echo $?
<_lemsx1_> 1
<infinity> (base)adconrad@cthulhu:~$ strings /etc/ld.so.cache | grep libgcc_s.so.1
<infinity> libgcc_s.so.1
<infinity> /lib/libgcc_s.so.1
<infinity> I did that before I answered you, honest.
<_lemsx1_> infinity: ahhh, so how do i get my ld.so.cache to include this?
<infinity> And it doesn't need to be in ld.so.conf... /lib is in the default search path.
<infinity> (The only thing in my ld.so.conf is /usr/X11R6/lib)
<_lemsx1_> i changed /etc/ld.so.conf (created it since it doesn't exists!) and added /lib\n/usr/lib\n/usr/local/lib\n and ran ldconfig
<crimsun> (those should all be in the default ld path)
<_lemsx1_> infinity: so ldconfig should create ld.so.cache even if ld.so.conf is not there... but why none of my dapper systems have it? i have a new dapper install in vmware as well as 2 old installations
<_lemsx1_> i just did the same grep command on the vmware installation i installed yesterday and ld.so.cache doesn't have libgcc
<_lemsx1_> ah, sorry. that does have it
<_lemsx1_> i mispelled it: libcc instead of libgcc
<infinity> Now, if I had to guess, I'd say your real problem isn't the contents of ld.so.cache.
<_lemsx1_> infinity: ummm... i agree
<_lemsx1_> infinity: i hate these problems... they never end
<infinity> Your real problem is that if splashy relies on libgcc_s.so.1, but doesn't link directlty to it (as most apps that use it don't), then it's not getting copied to the initramfs.
<infinity> If it's not in the initramfs, splashy can't find it on boot.
<infinity> This is my guess, anyway.
<_lemsx1_> infinity: no, this is running from the system after boot (not initramfs)
<infinity> Oh, if this isn't during boot, then... Hrm..
<_lemsx1_> infinity: it only needs libgcc for pthread_cancel to work (usually at exit)
<_lemsx1_> i googled it before and i get a post saying that libgcc_so wasn't in my ld path. i added it and it worked
<_lemsx1_> there is no libgcc-dev package or anything... pthread is part of libc6 anyway
<infinity> "libgcc-dev" is "gcc". :)
<_lemsx1_> ummm but what does 'libgcc_s.so.1 must be installed for pthread_cancel to work' could mean then?
<crimsun> I presume you have libgcc1 installed via gcc-4.0 ?
<_lemsx1_> http://www.thedumbterminal.co.uk/php/knowledgebase/?action=view&id=42
<_lemsx1_> crimsun: yes
<_lemsx1_> $> dpkg -S /lib/libgcc_s.so.1
<_lemsx1_> libgcc1: /lib/libgcc_s.so.1
<_lemsx1_> ii  libgcc1        4.0.3-1ubuntu5 
<_lemsx1_> same in the other systems
<_lemsx1_> but that last post says the same. that LD_LIBRARY_PATH is screwed
<_lemsx1_> ahhh, i see
<_lemsx1_> gcc --print-file-name=libgcc_s.so.1
<_lemsx1_> /lib/../lib/libgcc_s.so.1
<_lemsx1_> is that correct? why not /lib/libgcc_s.so.1 ?
<crimsun> they're identical
<_lemsx1_> yep.... 
<_lemsx1_> head spinning here
<_lemsx1_> the only thing that i can think of is that at some point an older version of gcc was installed and this file belong to that?
<_lemsx1_> http://sources.redhat.com/bugzilla/show_bug.cgi?id=439
<Ubugtu> sourceware.org bug 439 in nptl "libgcc_s.so.1 must be installed for pthread_cancel to work" [Minor,Resolved: invalid]  
<bluefoxicy> libgcc_s.so.1 must be installed for a lot of shit to work, it's kind of important.
<_lemsx1_> lol
<_lemsx1_> could it be because i'm launching the program using "sudo" the this being very picky about env vars?
<_lemsx1_> using "sudo -i" instead
<_lemsx1_> bah, same
<desrt> is there a tutorial anywhere on how to read DSDT?
<desrt> http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
<desrt> mm.  good starter.
<infinity> http://acpi.sourceforge.net/dsdt/index.php may be useful as well.
<desrt> 3. Error notes: File does not exist: /home/groups/a/ac/acpi/htdocs/dsdt/index.php
<desrt> 4. Error type: 404
<infinity> Seems to be 404 off an on.  Bad server in rotation, maybe.
<desrt> http://acpi.sourceforge.net/dsdt/ works though
<infinity> Refresh a few times and it comes back.
<sladen> desrt: note though that you don't have to do any kernel patching
<desrt> weird.  i keep getting different versions of the page :p
<sladen> desrt: funky
<desrt> sladen; i know.... our initramfs system allows us to provide custom DSDT's, right?
<infinity> desrt: And yeah, no kernel patching.  Just toss the compiled DSDT in /etc/mkinitramfs/DSDT.aml
<desrt> i don't suppose there's a decompiler for asl/aml
<infinity> iasl -d
<desrt> oh.  wicked.
<desrt> iasl was used to build the DSDT on this box
#ubuntu-devel 2006-06-04
<desrt> this is hilariously cool
<desrt> acpi is rapidly ascending my list of cool things
<jdub> okay
<jdub> we need to send desrt away on holiday
<infinity> ACPI would be pretty cool if there was a single hardware manufacturer that actually got it right.
<desrt> i agree.
<infinity> Getting it "almost right" and then having Microsoft fix it via software updates doesn't count.
<mjg59> Most vendors get it fine nowadays
<infinity> Though I would kill for Microsoft's big database of DSDT fixes.
<mjg59> Linux, on the other hand, really still doesn't
<desrt> mjg59 is here
<infinity> mjg59: My impression seems to be that we follow the spec well enough in most cases, but we don't have nearly enough workarounds in place to compete with Windows.
<infinity> mjg59: But I'm willing to believe we also break spec occasionally.
<mjg59> We demonstrably break spec in a couple of ways that probably don't matter
<mjg59> But then we come up against issues like the fact that Windows has just adopted the ACPI world while Linux tries to work without it when possible
<mjg59> So we get weird interrupt routing conflicts
<mjg59> VIA interrupt routing is still slightly fucked on ACPI systems
<mjg59> Because their APIC behaves slightly different to Intel ones
<infinity> Well, in Windows, it's an all-or-nothing thing.  You either have an "ACPI PC" or a "Legacy PC", and everything is defined from there.
<\sh> infinity: in windows it's: "I have a windows pc"
<infinity> Which cause no end of issues when ACPI was still shiny and new, and I was constantly holding down F7 (I think?) during windows installs to say "nu uh, don't use ACPI"
<infinity> \sh: No, very not true.
<mjg59> Suspend/resume is (generally) broken because our drivers are fucked
<\sh> infinity: for the plain windows user it is] 
<infinity> The "plain" windows user gets their machine shipped with Windows pre-installed by an OEM who should know what the sanest configuration is.
<infinity> When doing it yourself, Windows is just as fragile as Linux, if not more (says the man who's just spent ~24 hours reinstalling Windows on a system, because it's grumpy with his hardware configuration)
<\sh> infinity: right...but then, one day, she gets an ubuntu cd and no one is there to help her...
<zul> get more oems then
<infinity> Indeed, the solution to the "non-technical user" isn't to make our installer EVEN BETTER (I can tell you from the past day's experience, ours IS better), it's to get more OEMs shipping Linux pre-installed.
<infinity> No amount of simple installation can replace an OEM pre-configuring a system "just right", so you don't have to.
<desrt> ok
<desrt> so i can't find anything in this DSDT about sleeping
<desrt> the ACPI spec says i should see SLP_EN or SLP_TYP....
<desrt> all i have is SLPB
<mjg59> desrt: No, those are just registers
<mjg59> They're defined in the fadt
<desrt> but nothing in the code references them....
<mjg59> No
<mjg59> The kernel writes to them directly
<\sh> Oh Lord, please send Michael Dell a message that he has to pre-install Linux on Desktops and not this 666 Redmond OS.
<desrt> oh.
<desrt> so ACPI specifies a register region where writes mean certain things
<desrt> like sleep is done the same way on every laptop ever
<mjg59> You call the _PTS and _GTS methods, and then the kernel writes to those registers
<mjg59> Yeah
<desrt> prepare to sleep?
<mjg59> The registers aren't necessarily in the same place
<mjg59> Prepare to sleep and going to sleep
<\sh> who is in charge of the kernel these days (ubuntu-server)?
<desrt> i have PTS but not GTS
<mjg59> GTS is optional
<desrt> i wonder what would happen if i booted a system with practically no drivers installed....
<desrt> i seriously get the impression that some driver is screwing up
<\sh> s/pc/apple IIe/ ?
<desrt> i assume _WAK is what happens when it comes back
<infinity> \sh: BenC, with occasional input from others. (mjg59 for all things ACPI and otherwise desktop shiny, Fabio for sparc, me for occasional server input and vga16fb breakage, crimsun for all things audio..)
<mjg59> desrt: Yup
<desrt> i wonder if PTS is what makes the light on the case start woobing
<desrt> or if this is HW
<\sh> infinity: ok...do you think it's possible to fix a problem in the scsi area, which let the areca controller not doing their work correctly? as well, the configuration management software for areca is segfaulting with the actual kernel of dapper (server)
<\sh> infinity: to be more precise, 2.6.16 is fixing this problem and it's known by the areca patch maintainer afaik from our hardware oem support :)
<infinity> \sh: File a bug, and explain it better that "not doing their work correctly", since I have several anecdotal reports that areca works just fine.
<desrt> woh.
<desrt> there's an OSYS field (operating system, i assume)
<infinity> \sh: And put a pointet to the patch in the bug.
<desrt> it gets initialised in _INI to different numbers depending on the OS
<mjg59> desrt: The name OSYS is Apple specific, but yeah
<mjg59> DSDT code can be platform specific 
<Chipzz> hrrrm
<mjg59> On the Macs, the only difference seems to be a small amount of HPET setup. No idea why.
<desrt> if (darwin) 0x2710, if (linux) 0x3e8, else 0x7d1
* Chipzz just found a gnome-power-manager bug
<\sh> infinity: ok, i'll try...
<infinity> Chipzz: If you only found one, you're not looking very hard.
<desrt> and an OSDW() function which gets called on wake up which checks this register
<desrt> the check is LEqual(OSYS,0x2710), though... which assuming LEqual means what i think, darwin linux and 'else' match.
<Chipzz> infinity: pretty nasty one in my case
<Chipzz> but an easy fix I think
<mjg59> 0x3e8 is a weird choice
<desrt> oh.  logical equal.  ok.
<desrt> so it does different things on wake up if the running OS is darwin
<desrt> OSDW() must mean 'OS is darwin'
<desrt> if osdw  \_sb.pci0.sbus.enab()
<mjg59> Sounds smbus related
<desrt> think it might be causing me to not wake up?
<mjg59> If it is, probably only because of Linux bugs
<desrt> you're becoming more jaded about linux :)
<infinity> Linux is far from perfect.
<Chipzz> infinity: the GUI allows "When laptop lid is closed" to be set to "nothing", but the gconf description of those keys doesn't have that value in it's list...
<zul> heresy
<Chipzz> I had those keys set to "nothing", and as a result, when opening the lid after closing it, X went in an endless crash-loop
<sladen> Chipzz: can you file a bug please
<Chipzz> I will
<Chipzz> sladen: you the gnome-power-manager maintainer?
<Chipzz> sladen: file the bug in launchpad or upstream? I noticed on one of the gnome-power-manager bugs that ubuntu has quite some changes wrt upstream, and upstream isn't very happy about that...
<desrt> hmm
<desrt> mjg59; what are these smbus _Qxx methods?
<sladen> Chipzz: urm. Given how much time that g-p-m upstream (Richard Hughes) spends answering bugs on launchpad, we might have to disagree about that
<mjg59> Not sure
<desrt> mjg59; and what exactly happens if there's an error in the ACPI code?
<sladen> Chipzz: please stop making up 'conflict' when there isn't one
<mjg59> _ prefixed stuff is supposed to be standards
<desrt> two _Qxx methods under Device (SMB0) call this PNOT() function which references undefined variables
<mjg59> Erm, standardised
<desrt> 5.6.2.2.2
<mjg59> They may be defined in an SSDT
<desrt> it has to do with getting a query number from the hardwre
<desrt> "Embedded Controller Query and SMBus Alarm control method"
<Chipzz> sladen: I read one of his comments where he expressed his frustration about chasing a bug that turned out to be ubuntu-specific
<sladen> Chipzz: well yes.  But that's not "isn't very happy about" the changes
<desrt>  // following is a method that OSPM will schedule after
<desrt>  // it receives an SCI and queries the EC to receive value 7
<desrt>  Method(_Q07) {
<infinity> Chipzz: That particular grumpiness is has been long since sorted
<infinity> s/is has/has/
<Chipzz> then I'm probably making to much of an issue about it; it was just something that stuck in my mind
<mirak> is there a way to run the installer from a runing ubuntu installation ?
<infinity> mirak: Not "the installer", per se, but you can just bootstrap a chroot with "debootstrap", which may be what you're looking for.
<mirak> infinity: I know deboostrap but don't like it
<mirak> I fell it gives a partial installation
<mirak> infinity: why couldn't I run the installer ?
<infinity> Well, d-i just does debootstrap + install a bootloader + set up user/pass + install extra package selection (say, ubuntu-desktop) + reboot
<mirak> I mean since it's runnable from a live cd, it must be runnable from a normal installation
<desrt> infinity; if i inject my own DSDT into the initramfs is there a kernel commandline i can give to have it not load it?
<mirak> infinity: it won't ask for timezone etcetera
<desrt> infinity; just incase :)
<infinity> mirak: ubiquity (the livecd installer) has some very specific requirements for what it installs from, requiring access to the read-only filesystem of the livecd, etc.
<Chipzz> mirak: it is meant to give only a base install (or "partial installation", like you call it)
<Chipzz> I can see nothing wrong with that?
<infinity> desrt: Better off haking sure you have two kernels installed, and only mucking with the initramfs of one. :)
* desrt makes initrd.safe :)
<mirak> Chipzz: no but I did it for my actual system and I feel like it's broken
<infinity> I debootstrap installs all the time, and they're never "broken".
<mirak> infinity: ok about ubiquity.
<mirak> so what's the exact procedure ?
<mirak> as far as I remember I must install the kernels too
<mirak> "Installing this package on a normal system is unlikely to be useful."
<mirak> ok I will try anyway :)
<infinity> debbostrap + install kernel and bootloader + install langpack (optional, obviously) + set up a user
<mirak> and what about timezone plus locales etcetera ?
<Chipzz> heh
<infinity> tzconfig for timezones.
<Chipzz> why doesn't https://launchpad.net/distros/ubuntu/dapper/+source/gnome-power-manager/+bugs list any bugs?
<infinity> locales come from installing the langpack(s).
<Chipzz> I just submitted one so there must be bugs
<mdke> Chipzz: because launchpad bugs are targetted at the whole distro, not on dapper
<mdke> for some crazy reason
<Chipzz> also I see most recent bugs to the right after submitting my report
<infinity> s,dapper/,,
<infinity> And it's not particularly crazy to assume that a bug filed on dapper probably also applies to other releases.
<Chipzz> this is silly :)
<infinity> It would certainly apply to edgy, for instance. :)
<Chipzz> just clicking on the wrong link may be causing a lot of users to submit duplicate bug-reports
<mdke> infinity: i think there should be a better way of handling that, it's pretty crazy that the url for translations involves the "dapper/" while the url for bugs doesn't
<infinity> mdke: I think it was a mistake to have the release in the URLs at all, TBH.
<infinity> mdke: Bugs apply to package versions, not distro releases.
<mdke> this is true
<infinity> (ie: apache2 2.0.55-4 will have the same bugs in both dapper and edgy)
<Chipzz> but package versions are unique across releases
<Chipzz> even if the upstream version is the same
<infinity> Chipzz: No they're not.
<infinity> Chipzz: We don't rebuild the whole archive with new version numbers for each release.  Plenty of packages have the same version in dapper as they had in warty.
<Chipzz> debian has -sarge1 for security updates to packages in sarge
<Chipzz> so even if the upstream version would be the same, sarge would have -sarge1 while testing/unstable would have -1
<infinity> Chipzz: Security updates are UPDATES.  When nothing changes, the packages aren't revved.
<Chipzz> hrrrm you are right about that
<infinity> Chipzz: False.  I have packages in sarge that are the same version as in potato.  (really)
<Chipzz> probably because the maintainer doesn't care about them anymore
* desrt dpkg-reconfigure linux-image
<infinity> Chipzz: Or because they're reasonably bug-free and don't need to be gratuitously rebuilt.
<infinity> Chipzz: Though in the case of potato->sarge, yes, they should have been updated for policy changes if nothing else.
<Chipzz> there's still several transitions, like the c++ ones
<infinity> I don't maintain anything that uses C++. :)
<infinity> The only transition I've ever been subject to was the old /usr/doc -> /usr/share/doc transition.
<Chipzz> what I was trying to point out is that it's probably pretty rare to have the same versions across releases
<infinity> Not really.  And certainly not in Ubuntu.
<infinity> Since we release frequently, we have plenty of packages that don't change.
<infinity> Like i said, there are lots (LOTS) of packages with the same version in warty, hoary, breezy, AND dapper.
<infinity> And far more for just, say, breezy/dapper.
<\sh> apaapa
<\sh> infinity: 
<\sh> adsasd
<\sh> grmpf
* desrt wonders what Loki is doing in his ACPI tables
<mgalvin> jdub: should we use the ubuntu-traffic list for the ubuntu weekly newsletter (or some other list) or should we create a proper ubuntu-newsletter list maybe?
<\sh> what was that,,,3 minutes no keyboard input and then again?
<mdke> mgalvin: ubuntu-news exists already
<mdke> mgalvin: is perfect for your newsletter
<mgalvin> mdke: oh right, duh
* mgalvin *blushes*
<mirak> infinity: I think I will use debootstrap, because I don't really trust what will do ubiquity. I want to install on a second partition that is on LVM
<mdke> mgalvin: it's very underused
<mgalvin> i see, one or two posts a month :)
<Chipzz> \sh: the cat walking across the keyboard? ;)
<\sh> Chipzz: no..keyboard just didn't reply..and I was hammering on the keyboard like a cat walking across the keyboard ;)
<mirak> infinity: ok, ubiquity is useless since I use LVM
<Chipzz> oh I see :)
<sladen> mirak: use the alternate install CD
<mirak> I will use the netinstal.iso I think
<mirak> sladen: I wanted to know if there is a way to run the installer script that is on the alternate install CD but from a running distro
<sladen> mirak: debootstrap ?
<jdub> mgalvin: ubuntu-news
<mgalvin> jdub: yup, thanks, we will use that
<mdke> jdub: is planet still getting a 404 from my blog? I'm wondering if there is something wrong on my end
<sladen> mirak: out of interest, what are you actually trying to achieve?
<mirak> sladen: it's a piece of the puzzle. I would find intersting to have all the steps
<mirak> sladen: I just want to  install to another partition a clean dapper. in fact I already deboostraped, but I really wonder why I can't just have all the steps and a guide like with the installer on the alternate installer
<mirak> I just wasting my time in fact ;)
<sladen> mirak: apt-get source debian-installer 
<mirak> sladen: ah !!! thanks
<sladen> mirak: ultimately it calls debootstrap
<desrt> is there any way to put my root filesystem on a ramdisk without using initrd?
<mdke> desrt: #ubuntu might be able to help
<desrt> good call
<sorush20> hi ugys just wanted to know if this bug would be fixed soon or later? 
<crimsun> "this" being...?
<sorush20> https://launchpad.net/distros/ubuntu/+source/cupsys/+bug/43824/+index
<Ubugtu> Malone bug 43824 in cupsys "HP Laserjet 1000 doesn't work with cups2" [Normal,Confirmed]  
<crimsun> sorush20: "sooner or later" is a good approximation, yes
<sorush20> crimsun: you develop too? 
<sorush20> did I tell you about the amarok bug too? 
<crimsun> not cups*, but I'm involved.
<crimsun> which one?
<sorush20> well is there anyway that I can print? 
<crimsun> and the bug is better addressed in -bugs
<sorush20> is martin pitt here? 
<sorush20> Martin Pitt
<crimsun> pitti is not present; it's the weekend
<sorush20> okay.. 
<sorush20> I have not idea why I upgraded to dapper knowing there would be these problems.. 
<Daemon> GDI printers annoy me, cheap and nasty
<sorush20> but runs fine in breezy
<sorush20> how would I downgrade to breezy cupsys? 
<ompaul> sorush20, you reinstall breezy - walking back is not the way forward, you could try to change the sources but would it work I have no idea
<ompaul> sorush20, doing it like a dist upgrade
<Chipzz> sorush20: this is not a support channel; either ask on #ubuntu, or read apt-get's man-page to find out how to downgrade a package
<Chipzz> sorush20: (if at all possible of course; but I think it would involve something like apt-get install -t breezy ...)
<Chipzz> sorush20: no pvt messages please
<\sh> any way to get rid of those processes? root      6086  0.0  0.0      0     0 ?        S    01:57   0:00 [mmcqd]  
<Chipzz> \sh: I may be mistaken, but looks like a kernel process from a driver?
<\sh> Chipzz: it should be the mmc card reader...and I have two of them now, and I'm not able anymore to mount a sd card ;)
<Chipzz> have you tried stopping the process accessing the card reader?
<Chipzz> I have similar processes like that when using /dev/video from ivtv
<Chipzz> they go away when I quit mplayer
<\sh> Chipzz: hmm...
<\sh> automounting is what process? udev? hal? dbus??
<Chipzz> just try unmounting it?
<\sh> it's not mounted
<\sh> but it was mounted
<\sh> and I removed it to fast it seems
<Chipzz> hrrrm
<\sh> let's leave it for now..
<\sh> I'll go to bed just now.
<Chipzz> nn :)
<\sh> thought i can build quickly a SD gpg key container with dm-crypt support
<\sh> but it looks like that I'm screwed with automount in the moment ;)
<Chipzz> it's possible it's a bug in the driver too
<Chipzz> (I guess)
<Chipzz> like, you unmounted correctly, but that process failed to quit
<\sh> Chipzz: if removing the card is a correct unmount, but I doubt it ;)
<Chipzz> if it's still mounted, you can always try putting it back in and unmounting properly
<\sh> Chipzz: but if I'll try to reproduce it, to let mount a not formatted sd card ;)
<Chipzz> (like a floppy disk)
<Chipzz> *g* :)
<\sh> cryptsetup -y create gpgkeys /dev/mmcblk0pl1 \n mkfs.ext2 /dev/mapper/gpgkeys and then remove it 
<\sh> et voila screwed up
<Chipzz> \sh: is this you? http://www.uni-koeln.de/bin2/maillist/linux-fai/20060531.095843/171988 :)
<\sh> Chipzz: yes
<\sh> Chipzz: how did you find it?
<Chipzz> \sh: fai homepage
<Chipzz> just browsing the archive
<\sh> Chipzz: ah :)
<bioeng> Hi everyone
<bioeng> I'm having some programming related problems that I could use some help with
<infinity> bioeng: -> #ubuntu
<infinity> bioeng: This isn't a support channel for development on Ubuntu, it's a channel for the developing *of* Ubuntu.
<bioeng> ok
<bioeng> I'll try that channel
<LinuxJones> infinity, he will probably get more help in here.
<desrt> welp.  it just sucks.
* desrt compiled a kernel with no drivers (seriously... no drivers)
<desrt> it still does not sleep
<desrt> or rather, wake up from sleep
<bioeng> My question was to ask if it would be a good idea to do a CS minor while finishing my EE degree
<mjg59> desrt: Fun
<mjg59> So the kernel's blowing up somewhere in generic code
<bioeng> but I'll go to another room if necessary
<mjg59> You're under boot camp, right?
<desrt> i had another thought
<desrt> ya.  bootcamp
<mjg59> Ok
<desrt> what if it was failing to set the proper parameters on the DRAM before going to sleep
<desrt> and by the time it woke up again it had forgotten who it was
<mjg59> That's possible, but unlikely
<mjg59> (That is, I've found one machine ever that appears to do that)
<desrt> think i'll have better luck with efi?
<mjg59> The Intel datasheets are public - you're looking for "self refresh"
<mjg59> No, you'll have no luck at all with efi
<desrt> no acpi there i assume
<desrt> in your opinion what is the next most likely problem?
<mjg59> Oh, acpi, but completely absent testing of it ever in the slightest
<desrt> (btw... i tried the s3_ flags and i also enabled USB and HID support in my kernel to see if i could at least see capslock working -- no love)
<mjg59> It's utterly broken
<mjg59> Anyway.
<mjg59> Next thing to try is shoving reboots in arch/i386/kernel/acpi/wakeup.S
<desrt> that's the entry for coming back from sleep?
<desrt> is there a kernel sponsored way to reboot or should i just try and trash my cr2 and hope for a triple fault?
<mjg59> Just cut and paste the triple fault code from include/asm-i386/mach-default/mach_reboot.h
<mjg59> Oh, hang on, that's not where it is
<desrt> oo. pre-programmed triple fault :)
<mjg59> Might be under arch/i386 somewhere
<desrt> ok
<mjg59> The fallback reboot code is to do a triple fault
<desrt> nod.  that never fails :p
<mjg59> So then see if it's ever getting into the wakeup code in the first place
<desrt> do x86 chips still come up in real mode at 0xf0000 these days?
<mjg59> Seemingly so
<desrt> wow
<infinity> it's in kernel/reboot.c
<mjg59> Well, not /quite/
<infinity>                 case 'h': /* "hard" reboot by toggling RESET and/or crashing the CPU */
<mjg59> Coming back from acpi sleep, it immediately jumps to the address put into the wakeup code register
<infinity>                         reboot_thru_bios = 0;
<infinity>                         break;
<desrt> mjg59; i bet it does that by going to 0xf0000 first
<mgalvin> Riddell: around?
<mjg59> desrt: Yeah
<desrt> mjg59; there's a special memory address you can set in the PC bios (in the 0000:0400 range) which causes the power-on BIOS code to jump to some address VERY quickly
<mjg59> But at that side of things, the hardware is supposed to be dealing with it
<mjg59> It's not something an ACPI OS needs to care about
<desrt> so.....
<desrt> because this isn't really a real PC
<mjg59> So if it gets all the way through the wakeup code, you get to stick reboot calls in the C code
<desrt> i assume the firmware copies some bios boot block code into the f000 segment....
<desrt> and we have to hope that nobody tries to modify it
<mjg59> ACPI /sortof/ works on the minis and MBPs
<mjg59> (Reportedly)
<mjg59> desrt: Giving 2.6.17-rcwhatever might be worth a go
<mjg59> Just to make sure it's not something that's been fixed already
<desrt> that's a good idea
<desrt> i'm using 16 now
<mjg59> Or even -mm
<desrt> i have to admit i'm confused.  apple must have ROM blocks at 0xf0000
<desrt> or else when the hardware came up (really came up, at first)....
<desrt> i miss the good old days of serial and parallel ports
<desrt> back in the day when you could toggle some external pin on the machine with a single instruction
<desrt> debugging was more fun
<mjg59> Oh, yeah, I've done ACPI debugging with a panel of LEDs on the parallel port
<desrt> this laptop screams when it comes to building kernels
<nokko> Fujitsu: still there?
<Fujitsu> Yes.
<Fujitsu> I'm always here :)
<nokko> Fujitsu: could we please go private? (i am the person with the bug)
<nokko> Fujitsu: i see that people here don't like us talking about bug reports
<Fujitsu> OK, nokko.
<desrt> uh
<desrt> how is one supposed to make a call to a .c file from real mode?
<shackan> from real mode ?
<Fujitsu> Is this on topic?
<shackan> are you tinkering with the boot code or what ?
<infinity> desrt: You don't?
* desrt is left wondering how to reboot the system....
<infinity>                         __asm__ __volatile__("int3");
<desrt> that'll triple-fault me?
<infinity> Read machine_emergency_restart() from kernel/reboot.c
<desrt> oh.  you need an empty IDT for that to work
<desrt> and you also need to be in protected mode
<desrt> i don't think realmode supports the idea of triple-faulting
<shackan> why not?
<infinity> desrt: machine_real_restart may provide some hints..
<shackan> desrt, may I ask what you're doing ?
<infinity> shackan: Tripping a reboot during kernel setup, to see where his resume is failing.
<desrt> infinity; intense....
* desrt just jumps to bios :)
<shackan> kprintf'ing something more verbose and then do __asm__ __volatile__("cli; hlt;") and halt the machine ? :)
<sorush20> hi guys any development on this bug
<sorush20> https://launchpad.net/distros/ubuntu/+source/amarok/+bug/45487/+index
<infinity> Dude, you were just in here an hour or two ago, asking about cups bugs, AND you brought that one up.
<\sh> sorush20: #kubuntu-devel
<infinity> sorush20: This is not a support channel.  Bugging people about YOUR pet bugs does not get them fixed faster.
<\sh> sorush20: and it's not a supported package...
<desrt> infinity for dpl!
<infinity> upl?
<desrt> that's an appointed position :)
<makko> Fujitsu: i think the main problem with ubiquity is that it doesn't show intelligent errors: for instance, now i moved all the data into just one folder on the same partition (for backup purposes) and it crashed much later, with similarly strange errors. then i ran a df -h and it showed me "use% -- 100%" (which means partition is full).
<shackan> desrt, descriptor privilege level ? :D
<makko> Fujitsu: it should simply say: partition full. right?
<makko> Fujitsu: i mean, it should even check for this from the beginning!
<Fujitsu> makko, yes, it's not particularly good at the moemnt.
<makko> Fujitsu: i think checking it from the beginning is simple to implement and i simply don't understand why it doesn't.
<makko> Fujitsu: i mean... how can you begin to install if you can very easily make sure you don't have enough space on the partition?
<desrt> SCORE
<desrt> my system reboots on wakeup from sleep now
<desrt> good thing we decided to teach that assembly class last term about oldschool DOS x86 stuff :)
<\sh> desrt: hmmm....oldschool dos x86 stuff? teach them z80 ;)
<bddebian> heh
<bddebian> Hmm, we don't have xulrunner in the archive?
<infinity> bddebian: We will somewhere shortly after Tuesday.
<\sh> bddebian: apt-cache search xulrunner says no
<infinity> bddebian: It hit Debian too late to be useful for dapper.
<bddebian> infinity: OK, thx
<\sh> good night folks
<makko> Fujitsu: maybe you could tell ubiquit devs about implementing better error messages and checking space available. i guess ubiquity only checks partition size and assumes it's being formatted.
<makko> ubiquity
<Fujitsu> makko, they are going to fix it a lot, I guess.
<bddebian> infinity: Do you happen to know much/anything about it?
* desrt just did something comically stupid
<desrt> wow.
<desrt> step 1: be sure to make a backup copy of your MBR
<desrt> step 2: blow the MBR away
<desrt> step 3: realise that you saved the backup copy of the MBR on the harddrive itself
<infinity> bddebian: It?
<infinity> bddebian: Oh, xulrunner?  A bit.
<infinity> desrt: But you can boot from CD, so it's all good.
<desrt> infinity; but... my harddrive....
<bddebian> infinity: Any idea why there is no i386 build log on p.d.o?
<infinity> desrt: MBR != Partition table...
<infinity> desrt: Unless you zeroed a LOT of sectors...
<desrt> infinity; ok.  "the first 512 bytes of my disk"
<desrt> which contain both the mbr and the partition table
<infinity> desrt: First 512 bytes is just the MBR.  No reason you can't mount that disk from a CD boot.
<desrt> you are wrong
<infinity> I are not.
<desrt> first 512 bytes also contains the partition table
<desrt> explain to my why, then, the boot CD doesn't seem to think i have partitions :)
<infinity> Probably because I'm wrong. ;)
<makko> desrt: maybe it's just teasing you
<makko> Fujitsu: wow, already 87 updates?
<Fujitsu> makko, yes.
<makko> Fujitsu: that's what adept notifier says
<makko> Fujitsu: from now on i guess it's much better for canonical to release a community edition (like mandriva) and then, after one month, a final version. that way we'll get more beta testers.
<bddebian> makko: Dapper has been available to the "community" for months
<makko> bddebian: then i don't understand why so many bugs are being detected so late
<makko> bddebian: really... it frustrates me
<crimsun> makko: that's not a reflection of the development, that's a reflection of people testing it at a given time
<makko> bddebian: maybe most of them download the live cd only when it's "official" enough
<bddebian> makko: I don't recall seeing your nick around prior to very recently?
<makko> bddebian: i changed it, why?
<makko> bddebian: oh, and i am new to #ubuntu-devel
<makko> crimsun, bddebian, Fujitsu: so i think it would be very helpful if we advertized two "official" releases, like mandriva. what do you think?
<bddebian> makko: I don't see the difference.  And if you live Mandriva, go to Mandriva
<Fujitsu> The Ubiquity disaster has been a bit bad.
<tseng> "disaster"?
<Fujitsu> I would categorise it as a disaster.
<bddebian> Aye what disaster?
<makko> bddebian: why do you say i like mandriva?
<makko> bddebian: did i offend you?
<bddebian> makko: Because you keep bringing it up.  ANd regardless, this is not the purpose of this channel
<tseng> makko: he said if
<makko> tseng: no, i mean why did he even bring it up like that and why he put it like that
<makko> tseng: i just thought that would be helpful
<bddebian> Fujitsu: I installed personally Ubuntu, xubuntu, and kubuntu on 4 different machines myself
<bddebian> With 0 issues
<tseng> you are the first person to mention mandriva, i think
<bddebian> s/xubuntu/edubuntu/
<makko> tseng: because i am a "convert" from mandriva
<makko> tseng: and i like that idea
<tseng> this is very silly
<tseng> but we made 2 beta and an rc release
<makko> tseng: what is very silly?
<tseng> and none of you tested it
<makko> tseng: make it more official, and much more people will test. i am sure. that's how they do on mandriva.
<Fujitsu> makko, that'd be right.
<tseng> i dont know how much more official you can make it
<tseng> than posting to every ubuntu list, making slashdot, digg, osnews
<bddebian> What makes it more "official"?
<tseng> i mean, jeez
<Fujitsu> I would never use Ubiquity, because my config is rather odd.
<makko> tseng: when there are too many "flights" most people are confused and prefer to say "ok... i will wait until this flood ends"
<tseng> you can't get any more publicity if you tried.
<makko> bddebian: i don't know... "singular". give people the impression it's something "final"!
<Burgundavia> makko: publicity is not something Ubuntu needs more of
<tseng> why would yo make a final beta
<Burgundavia> well, it does, but it is not somehting we need work on
<bddebian> This is a pointless discussion that I will take part in no longer.
<tseng> I am starting to agree.
<makko> tseng: not a final beta
<tseng> it definately doesnt belong in this channel, in any case
<tseng> if you'd read the topic
<makko> ok
<Burgundavia> makko: if you really want to help testing, file and triage bugs
<tseng> file and triage bugs before the final release
<tseng> don't be a Eugenia
<makko> what is an eugenia?
<shackan> what did she do?
<tseng> if you missed it, I am not going to go into it here
<tseng> you can figure out where to look if you are so inclined
* desrt folds another computer into things to streamline the workflow
<desrt> does this channel piss people off or do people piss this channel off?
<Burgundavia> desrt: what do you mean?
<tseng> desrt: people cant read a topic
<tseng> desrt: and use their best judgement
<Burgundavia> we should probably just renamed this channel #ubuntu-escalation-support and be done with it
<desrt> yuh....
<Chipzz> shackan: former "head" of osnews, queen of garbage-journalism
<Chipzz> not that the word "former" matters, as thom is just as bad
<bddebian> Burgundavia: :-)
<desrt> seriously.  WTF
<desrt> my laptop rebooting or not seems to be more of a random whim of the kernel i build than it is of the changes i make to it
<mjg59> Hardware is fun!
<desrt> i hate you
<desrt> i wonder if ; is not a comment
<desrt> if i comment lines with ; they appear to still be run
<mjg59> In .config?
<desrt> in .S files
<mjg59> Oh
<desrt> i think that's my problem
<mjg59> It ought to be, I think
<desrt> i'd make a change, see that it do what i want
<desrt> then comment it with ;
<desrt> and see that the change remains in effect
<mjg59> Ha
<desrt> insanity.
<mjg59> # is certainly a comment
<desrt> ; is "ignore this character and keep on parsin'"
<mjg59> So I'd recommend #, really
<desrt> oddly, vi syntax hilights ; as a comment and # as nothing
<desrt> *shakes fist at vi*
<bddebian> So use an editor from this century :-)
<desrt> i'll make you regret those words
<desrt> i think this is the most useful my usb key has ever been to me
* desrt has an initrd that sleeps on boot and a kernel image and syslinux
<bddebian> desrt: Are you actually doing something or are we just getting running commentary? :-)
<desrt> bddebian; i'm debugging the code that runs very very early after the machine comes back from sleep
<bddebian> desrt: What I meant was.  Are you actually fixing an Ubuntu bug? :-)
<desrt> the "my macbook fails to wake up" bug?
<infinity> "Ubuntu doesn't work for crap on MacTels" sounds like a bug to me.
<infinity> (FSVO "doesn't work for crap" that means "it works pretty well, modulo the bits that don't")
<desrt> FSVO?
<infinity> For some value of.
<desrt> right.
<bddebian> Ah
<izm99> When you plug in a digicam memory card, a window appears asking if you want to import photos.  How do I get my own program to do that?
<izm99> Clicking "import photos" opens gthumb.  I'm assuming the hook is implemented with dbus or hotplug or something... but where/how I'm not sure.  anyone know?
<mjg59> izm99: #ubuntu is a better place for this, but check out the removable drives and media preferences
<izm99> mjg59, ok, thanks.  :)
<izm99> mjg59, out of curiosity, how does "ubuntu" know when a digitcal camera source has been connected?
<Lathiat> gnome-volume-manger ?
<infinity> Good ol' gnome-nolongerhasanythingtodowithvolumes-manager
<infinity> Always entertaining to watch it fiddling with my sound cards.
<infinity> Cause you can almost pretend the "volume" means something else.
* izm99 mans gnome-volume-manager
<StevenK> infinity: Where volume is the space taken up by devices. :-)
<infinity> <laugh>
<Lathiat> hrm it seems apt isnt asking questions, e.g. the java license & the flash "do you want to download" stuff, known?
<infinity> Lathiat: Did you install that system with ubiquity, pre-release?
<Lathiat> yeh i think so
<Lathiat> was a bug then?
<infinity> Then your debconf frontend is set to noninteractive (oops, my fault)
<Lathiat> kubuntu upgraded from ubiquity RC install
<infinity> sudo dpkg-reconfigure debconf
<Lathiat> ah ok
<Lathiat> cheers
<infinity> (For the record, the defaults are "dialog, high, don't ask again and again"
<infinity> )
<jadaz87> infinity what is comething i could use to build metapackages?
<infinity> -ETOOVAGUE
<jadaz87> infinity: i see
<infinity> But you may want to see the "equivs" package, if your questions was what I think it was.
<jadaz87> infinity: thank you
<crimsun> hmm, I'm delivering a dapper talk to trilug next thursday, and I'm receiving numerous requests to cover the steps after debootstrap to configure the base system in a chroot now that base-config has gone away.
<Hobbsee> crimsun: and write us a howto on it please? 
<crimsun> Hobbsee: yeah, that will be done since I have to demonstrate it live. :)
<Hobbsee> :)
<Kliment> hi, I've found a regression
<Kliment> the panasonic acpi driver (pcc) no longer generates key events
<Kliment> looks like there is a newer version that fixes things for the .15 kernel, but it's not in dapper
<Kliment> who should I notify?
<crimsun> please file a bug in malone and attach a link to the fixed version, preferrably a diff against whatever Dapper has
<Kliment> I am not familiar with malone, where do I start?
<crimsun> Kliment: https://launchpad.net/distros/ubuntu/+filebug
* crimsun wonders whether he should be looking at casper or ubiquity source to answer the above question regarding base-config's "replacement"
<Kliment> https://launchpad.net/distros/ubuntu/+bug/48325
<Ubugtu> Malone bug 48325 in Ubuntu "Panasonic ACPI driver (pcc) does not generate key events" [Normal,Unconfirmed]  
<Kliment> is this good enough, anything I should add?
<crimsun> Kliment: can you verify that 0.8.4 indeed fixes the regression from breezy?
<desrt> doot.
<Kliment> I can try
<Kliment> grr, forgot that this update does not pull the kernel source in with it
<Kliment> well, this will take a while then
<Kliment> hmm, seems like the driver developer's server is having some trouble
<Kliment> I'm getting truncated files
<Kliment> could someone else verify it's not just my connection messing things up
<Kliment> http://www.da-cha.org/letsnote/hotkey-handler-1.4.tar.gz
<Kliment> adding the hotkey handler fixes the problem, but I only have an older version of it as the downloads on that site are broken for some reason
<crimsun> all useful info for the bug report.
<sivang> hey crimsun , what's cracking? :)
<crimsun> sivang: me, so sleep time :)  yourself?
<sivang> crimsun: well, just preparing some lunch and going see where I need to do work afterwards. it's a beautiful morning here
<crimsun> sivang: excellent :)
<sivang> crimsun: sleep time? aren't we at the same time zone?
<desrt> i think i just fixed a bug in the linux PCI code.
<sivang> desrt: oh cool
<crimsun> sivang: I'm EDT (GMT -0400)
<sivang> crimsun: ah, so it's morning for you ?
<sivang> crimsun: where in?
<crimsun> sivang: yep, almost 5 AM. East coast USA (North Carolina).
<sivang> crimsun: ah, nice did not sleep throug the night I suppose? :-)
<kagou> hi
<crimsun> sivang: nope, going to do that now. 'night/'morning :)
<vlad> sladen: Hello, yesterday I posted a bug comment about acpi-support + i810 xorg driver and you seem to be much involved with it. Can I ask some questions?
<sladen> vlad: yup
<sladen> vlad: what's the bug number?
<vlad> Great, the lucky number is 40621
<sladen> bug #40621
<Ubugtu> Malone bug 40621 in acpi-support "R50e fails to resume: Green moon constantly blinking" [Normal,Unconfirmed]  http://launchpad.net/bugs/40621
<vlad> right, my first question... you make a reference to bug #28326 which is marked as Fix Released. Does that mean that it should work in the current Dapper?
<Ubugtu> Malone bug 28326 in xserver-xorg-driver-i810 "i810 Xv crashes after suspend -> infinite resprawn" [Major,Confirmed]  http://launchpad.net/bugs/28326
<HrdwrBoB> yes
<vlad> unfortunaell
<vlad> oops
<HrdwrBoB> erm.. I didn't mean yes to that
<HrdwrBoB> I mean yes, it happens to  me too
<vlad> I experience it in Dapper too and I would like to know if anything can be done to fix it.
<sladen> vlad: I thought I'd nailed it;  but I've had it once since.  Did you attach the Xorg.log from after one of those
<sladen> (the machine is still up, so you can SSH in, or Sync, Unmount, reBoot it
<vlad> sladen: yes, you can see it at the very bottom of the bug page.
<Lure> sladen: which process in gnome handles laptop hotkeys defined by your hotkey-setup package?
<Lure> sladen: I would like to address this also for KDE and would help to know how Ubuntu does it...
<ogra> Lure, hal and gnome-power-amanger should be responsible for that
<ogra> *manager
<sladen> Lure: they listen via HAL now.  do   lshal -m  and press some hotkeys
<sladen> Lure: and gnome-setting-daemon does some evil remapping of its own
<Lure> ogra: ok, I see
<ogra> wasnt klaptopdaemon adjusted to use hal nowadays ? 
<Lure> just need to find right place in KDE to put this in (kmilo, klaptop, kpowersave...)
<sivang> wow, nice. glom has so much potential
<Lure> ogra: klaptop only uses pmi command line to suspend/resume, but still has plenty of ACI/APM cruft
<Lure> ogra: just had report that it does not work on the desktop as some ACPI functions are missing (while Ubuntu works) :-(
<ogra> well, thats how g-p-m worked in breezy, just make the same switch in the code and you are done ;)
<Lure> ogra: probably yes, I am just doing investigation in order to prepare spec for Paris meeting
<ogra> cool
<vlad> sladen: well, can I do anything about the i810 bug? would be some more info helpful?
<InfraRed> sladen: msg
<sivang> Lure: you're coming to paris to work on laptop support ? :)
<Lure> sivang: no, but I plan to work on Kubuntu laptop support for Edgty
<Lure> sivang: I just hope spec get reviewed in Paris
<sivang> Lure: I feel there's great lack of complete IBM thinkpad support currently, I would wish to see it comes with all software help and support as it is in Windows
<sivang> some of it we already have in the form of NetworkManager,
<sivang> but would be also nice to see the Access connections there,
<sivang> and ofcourse, out of the box support for the motion detector and fingerprint reader
* sivang is going to prepare a spec about that soon
<sivang> hopefully to be reviewed in Paris as well :-)
<Fujitsu> sivang, you do realise that Lenovo officially dropped Linux support?
<sivang> Fujitsu: link?
<sivang> Fujitsu: what made them take such a non sensical decision?
<Lure> sivang: MS probably... :-(
<Lure> sivang: http://www.crn.com/sections/infrastructure/infrastructure.jhtml?articleId=188701277
<Fujitsu> sivang, saw it on Slashdot and other places not long ago.
<Lure> sivang: for your needs, you would probably need proper kernel drivers to support it (fingerprint, motion detector...)
<sivang> oh man :-/
<sivang> Lure: yes, I already know some of this has problems for re-distribution as well
<HiddenWolf> Well, there go my plans to buy an X60
<InfraRed> X60 ?
* sivang regrets buying a t43p from Lenovo and not going for a compaq/hp which officially support linux
<HrdwrBoB> I love my X40
<sivang> was also quite expansive, and does not seem to return the investment completly
<HrdwrBoB> oh shit
<HrdwrBoB> lenovo :(
<InfraRed> T43p cost silly money
<sivang> InfraRed: so I leanred , yes
<sladen> sivang: three buttons, nipple
<sivang> sladen: ? :)
<sladen> "Lenovo will still supply advice to 'customers who _insist_ on deploying Linux'"
<vlad> sladen: I have to leave now, if I could help somehow solving the mentioned bug, please mail me at vladimir.lapacek@gmail.com. thx and have a nice day
<sladen> Microsoft has offered them a good deal (eg. this, or else)
<sladen> vlad: thanks
<sivang> sladen: ah, right I saw that , I ownder how much of this stands in .il ;-)
<sivang> sladen: up till now I had terrible IO issues with Ubuntu on my thinkpad, mostly the machien is able to do one task at the time type of problems, and well , fglrx perforamnce issues. (although the prop driver is supposed to be faster then the FOSS onw)
<sladen> sivang: remember that they just got barred from supplying .gov.us with Lenovoware.  And the security services and miltary are probably their biggest customer of Linux thinkpads
<sivang> sladen: I'm already using elevator="deadline" but this had minor effect if any
<HrdwrBoB> everyone i know who uses linux on laptops swears by ibm (and lenovo)
<HrdwrBoB> oh well, things change I guess
<InfraRed> ya
<sladen> sivang: there seems to be a weird DMA issue;  it occasionally goes in (what appears to be a swap storm) that can take ~30 minutes to get out of.  (Even with out swap running).  I reckon it's more likely the duff SATA<->PATA bridge in the R52 and T43
<sivang> sladen: indeed, so without those in demand, they're looking mostly at a MS oriented market? (given those securoity agencies probalm prefer linux out of quality)
<HrdwrBoB> well, they'll soon find out if a significant portion of their market wants linux
<Fujitsu> HrdwrBoB, hopefully.
<Fujitsu> Boycott Lenovo.
<sivang> sladen: oh man, any way  to make it not act like an old PIII 4200rpm machine? :)
<sladen> sivang: not that I've found yet.  most of the time it doesn't.   Ctrl-Alt-F1  seems to be a good way to get out of it (wait a couple of minutes...)
<sladen> sivang: I only found this out because I tried to put in a different hard-disk for testing  (one without the HDD firmware patch designed to work around the bug)
<sivang> sladen: funny, it's probably is that PATA-SATA brige and not specifically an os issue, I managed to somewhat reproduce that in WinXP as well, more then one dir /s in more then one console just brings it down to GUI latency and dropped responsiveness
<sivang> sladen: ah, so what bug is the fimrware patched HDD workoaounds ?
* sivang wonders if he could request a refund on account the machine is not acting as stated, and has very poor performance
<sladen> sivang: http://www.thinkwiki.org/wiki/Problem_with_non-ThinkPad_hard_disks
<sladen> sivang: you may actually be able to.
* sivang read in thinkwiki
<sivang> sladen: according to the description, and the fact I don't get the warning (I never tried to replace the drive) I shoudl not have any performance issues. 
<sladen> sivang: quite;  however, I haven't seen the 'swap-storm' issue on other machines... and the result is fairly similar (but less exagerated) to when I did put another disk in and the IDE bus hanging caused the machine to lock solid for 3 seconds every 15-20seconds
<sivang> sladen: wow
<sladen> when it's in the swap-storm mode, it feels more like the machine is frozen for X milliseconds out of every Y
<sivang> sladen: so the "approved" HDs only circumvemnt the issues, to a smaller degree.
<sivang> sladen: this is EXACTLY what I am experiencing. why didn't I got for anything else but Lenonvo...;-)
<sladen> sivang: yes, the "approved" HDDs are ones that have had the firmware on the drive patched in an attempt to mitigate the bugs in the PATA bridge
<sivang> sladen: god, I have exepcted abit more from Lenovo mahcine which still carries the IBM logo :-(
<sladen> sivang: these were the first batch of 50%/50% IBM/Lenovo's.  The *60* are the first batch of true Lenovopads
<sivang> sladen: is there anything official press release I can come with to the srvice cetner to backup my anger and shouts? :)
<sladen> sivang: I filed a bug something like  "machine freezes under high I/O load"  But I can't find the bug report
<mirak> debootstrap have failures when installinf with dapper
<sivang> sladen: do you think that ni view of this, there is a still a plce for a spec to make Ubuntu on a thinkpad closer in support to how it's on a preloaded WinXP ? (without Lenovo support we'll have to do everything ourselves)
<mirak> it unpacks everything five times ...
<sladen> mirak: https://launchpad.net/distros/ubuntu/+source/debootstrap/+filebug along with the error messages please
<sivang> sladen: (I was gonna start working on aspec like this before we talked ;-) )
<ogra> mirak, then no edubuntu install would work out there (edubuntu and ltsp rely heavily on debbootstrap)
<mirak> ogra: I say some packages fails when unpacking
<ogra> mirak, see above ... if packages would fail, the edubuntu installs would all fail
<mirak> I do a deboostrap debootstrap --include=ubuntu-desktop,ubuntu-minimal,ubuntu-standard,language-pack-fr dapper linux2
<mirak> ogra: then it fails
<sivang> sladen: any idea if one could put a real SATA drive to overcome the bridge on that machine?
<mirak> wasabi: Failure while installing base packages.  This will be re-attempted up to five times.
<sladen> sivang: the solution alluded to is that if you put a PATA disk in the ultrabay everything will work
<mirak> ogra: the base install work, but other packages seems to have problems
<sivang> sladen: the ultrabay is only pata?
* sivang would prefer to exploiut the SATA capabilities so exapnsively paid on this lptop
<ogra> mirak, do what sladen said, file a bug and attach a full log of the failed debootstrap
<mirak> ok
<sladen> mirak: if you read the mirak man-page, you'll notice that you have to resolve the dependancies for any packages which you --include
* ogra looks for the mirak manpage *G*
<ogra> yes, the easier way is  debootstrap dapper linux2 && sudo chroot linux2 apt-get install ubuntu-deskto
<ogra> p
<mirak> ok thanks
<ogra> (you wont need minimal and standard, minimal is installed by debootsrap by default iirc and -desktop should depend on -standard)
<mirak> I am not sure of that
<mirak> iwj: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Found additional base dependencies:
<mirak> ogra: but what I did was to put all the .deb on the iso inside var/cache/apt/archives
<sivang> sladen: I wonder if I can find anything other then http://www-3.ibm.com/pc/support/site.wss/document.do?&lndocid=MIGR-60169 as an excuse to get a replacement machine without a bridge and with true SATA drive
<mirak> sladen ogra I think the problem comes from the configuration dependencies
<mirak> debootstrap configures everything alphabethically
<mirak> I have just read the log and almost everything is broken
<sivang> sladen: so I think I will restore the machine to it's factory settings ( created the product revoery CDs before I installed Ubuntu)
<sivang> sladen: and then go and show them how it's brought ot it's knes with 3 cmd.exe dir /s windows
<ogra_> grmbl
<ogra> mirak, why didnt you mount /cdrom and use file:///cdrom as mirror ? 
<ogra> milli, (mount it as loop device if you dont have it on CD)
<HiddenWolf> sivang: what model of thinkpad do you have?
<mirak> ogra: yes I should have done that
<ogra> saves a lot of time and diskspace :)
<mirak> ogra: or mount the iso
<ogra> yeah ... err s/milli/mirak indeed :)
<mirak> anyway I burnt the iso meanwhile
<mirak> I think I would do something clean from boot
<mirak> I am afraid to miss something in the configuration
<mirak> my system is already a bit wrecked probably from debootstrap previous install. I want something as clean as possible
<sivang> HiddenWolf: T43p , 1.8GHz , 7200rpm , 1GB RAM FireGL V3200 
<HiddenWolf> sivang: problematic beast, I assume? :)
<sivang> HiddenWolf: read the backlog , it's amazing what tricks computer verndos play these dasy :)
<HiddenWolf> sivang: heh, yeah, I just missed the model number. :)
<sivang> HiddenWolf: also, http://www.crn.com/sections/infrastructure/infrastructure.jhtml?articleId=188701277 for my joy of choosing IBM :-)
<HiddenWolf> sivang: I am/was in the market for a thinkpad. 
<highvoltage> thinkpad was a favourite for linux users for a long time, afaik. that will probably change now :/
<sladen> sivang: worth a try
<sivang> sladen: I also have issues with the touchpad sensitify I Was unable to resolve, and those weird "bell" sounds whenever the mahcine is under heavy IO could probably serve me at the service center.
<sivang> (I think they can also be attribute to the bridge thingy)
<sladen> sivang: ah okay.  I never use the touchpad.  I don't know what the bell sounds are, but there is high-pitched noise during C-state changing
<sivang> sladen: C-state ?
<HiddenWolf> I wonder how useful dapper will be in three years
<HiddenWolf> Since it might only work out of the box on current hardware.
<sladen> sivang: CPU power saving states.  See  cat /proc/acpi/processor/*/power
<sladen> HiddenWolf: why don't we wait and find out
<HiddenWolf> sladen: heh, we sure will. ;)
<mdke> HiddenWolf: it'll work great on your current hardware.
<HiddenWolf> mdke: it already does. ;)
<mdke> HiddenWolf: exactly.
<herzi> but only if you still have your current hardware running in three years
<mdke> herzi: yes, obviously dapper can't actually fix hardware
<ogra> and the next LTS release will be there by then, people can upgrade
<mirak> it's like certifying memory for fifty years
<herzi> ogra: is there a concrete plan for the date of the next LTS release? (12, 24, 36 months)
<mdke> ogra: potentially even another 2 LTSs
<mirak> that's just commercial argument
<ogra> herzi, iirc it was planned every 2 years
<Hobbsee> ogra: you're the one who's good with screensavers, arent you?
* Hobbsee cant remember.
<ogra> Hobbsee, well... 80 open bugs (in xss and gss together) wouldnt justify me as "good" with it, but i'm responsible for it, yes
<Hobbsee> ogra: right.  i'd love to kill off those bugs sometime - seems to need a very specific selection of packages to make rss-glx work, and i'm not sure why it's so tempramental...
<ogra> you need only xscreensaver-gl 
<ogra> oh, damned and it indeed misses a dependency on xss-gl
* ogra makes a note for dapper-updates
<ogra> Hobbsee, thanks for pointing !
<Hobbsee> ogra: for kde, you seem to need kscreensavers-xsavers too
<Hobbsee> ogra: hehe.  not a problem :)
<ogra> hmm, i havent looked at the KDE side of things yet
<ogra> i always thought KDE uses its own implementation, isnt kscreensaver that ? 
<Hobbsee> ogra: there's one package that you *cant* have installed for it to work.  i'm not remembering this second whether that's xscreensavers, or xscreensaver-gl-extra
<ogra> -extras are only additional screensavers
<Hobbsee> ogra: rss-glx doesnt need kscreensaver to run at all - but it does need the kscreensavers-xsavers too...
* Hobbsee checks what she has installed
<ogra> and xscreensaver has only the xscreensaver binary, nothing else
<Hobbsee> ogra: there's something weird there - i'll check that out a bit more.  but if we could get a dep on kscreensavers-xsavers somehow if the people use kde...or whatever equivalent that is, that'd be cool - and that would stop a whole lot of kde bugs.
* Hobbsee comes from the kde side, see :)
<Hobbsee> ogra: the kscreensaver-xsavers is just the hook so that the screensavers work under kde.  that's not the same as kscreensavers
<ogra> a dep on: kscreensavers-xsavers | xscreensaver-gl probably ... depends if kscreensaver-xsavers provides the GL tools
* highvoltage wishes he could get his 3d working again :/
<Hobbsee> ogra: and if it doesnt, the screensavers either wont work, or will work poorly, right?
<ogra> some of them 
<Hobbsee> the rss-glx ones are the ones that i'm interested in :)
<ogra> i.e. most of the ants GL savers need the xss-getimage program
<Windkracht8> Hello all, I wrote a small program with qt for ubuntu, and now I want to package it so I can share it with other people using ubuntu.
<Windkracht8> Is there a program/tool that can create the .deb for me? It's a very small program a single executable nothing more.
<sivang> anyone from distro-team going to guadec ?
<ogra> if rss-glx has anything that grabs the pics or grabs the screen, you will need these tools
<ogra> Windkracht8, see the helpfiles installed in your ubuntu, there is a simple packaging guide
<sivang> Windkracht8: there actually soemthing like this tool planned as a SoC project, but I don't think there is anything currently other then maybe using cdbs kde targets to ease the packaging
<ogra> Windkracht8, and the better channel for such questions is #ubuntu-motu
<ogra> :)
<Hobbsee> ogra: testing that...
<pygi> sivang, there is no something like that as SoC...we didn't accepted it ;)
<pygi> Otherwise hey ;)
<sivang> pygi: ah ! :-)
<Windkracht8> thanks ogra and sivang, going over to the motu after checking your suggestions \.
<sivang> pygi: I will work on the spec today, put in order, add teh scope part with the plans and the planned backup use cases as well
<pygi> sivang, oki, say when you do so I can look into it ;)
<sivang> pygi: sure, but it might not be ready until evening even, but I will ping you when it's done if you're still here
<pygi> sivang, just poke me by mail :)
* sivang has to call the bank, credit card compnay, run some (Argh) more errangs relating to his previous workplace , get cellular company website password fixed etc.. :-)
<sivang> pygi: to name a few :)
<pygi> sivang, no worries :)
<\sh> sivang: previous workplace?
<sivang> \sh: heh :)
<pygi> \sh: strange things happen :P
<\sh> sivang: don't tell me you quit the job at private homepage processor company?
* sivang hides
<sivang> me hides AND lols at \sh's recalling of this ancient acronym
<mirak> what is supposed to mount sysfs ? I don't have it in fstab but it's mounted
<\sh> sivang: I think only old farts still know this term 
<sivang> \sh: hehe
<sivang> \sh: well, I actually did. for good or worse. it had to be done.
<Hobbsee> ogra: ping?
<ogra> Hobbsee, :)
<ogra> Hobbsee, so what did you find ? 
<Hobbsee> ogra: just tested that out - KDE absolutely *has* to have kscreensaver-xsaver for the rss-glx screensavers to work. no excuses.  it works with both kscreensaver-xsavers and xscreensavers-gl though.  I cant test for what happens if you've got kde and another dm installed though - not sure if it's the same there.
* Hobbsee needs to be able to type quicker!
<ogra> take your time, its sunday ....
<Hobbsee> :P
<ogra> ok, sounds like a good bet then to add the above dependency
<Hobbsee> it's sunday night, i must be ready for monday morning.  anyway, i work weekends :P
<Hobbsee> ogra: but what about the users who dont run kde?  is there a way to set that that's only required if the user has kde?
<ogra> yes thats done through the |
<ogra> "<ogra> a dep on: kscreensavers-xsavers | xscreensaver-gl probably ... "
<Hobbsee> ogra: | means or doesnt it?   so if the user happens to install xscreensaver-gl, runs kde - then it still doesnt work
<ogra> hmm
<Hobbsee> is there a way to say "if this user runs...oh i dont know...kdelibs4c2a, then they must have kscreensaver-xsavers installed?
<ogra> not really ...
<Hobbsee> because that would be the ideal situation
<Hobbsee> hmmm...
<\sh> Hobbsee: what's the problem?
<Hobbsee> \sh: on kde, the rss-glx screensavers require kscreensaver-xsavers to run.  but if we had a dep on that...then a whole lot of non kde users would get that on their systems.
<\sh> Hobbsee: is rss-glx screensaver so important, or could we remove it?
<Hobbsee> \sh: well...bear in mind that i *am* a girl, and those are very pretty screensavers :P
<Hobbsee> and i expect that other people use it as well
<ogra> yes, if its there to install, the deps should be right 
<\sh> Hobbsee: I'm sorry, I'm just not using any screensavers at all, in times of tfts ;)
<jsgotangco> lol
<Hobbsee> hehe @ \sh 
<ogra> \sh, it saves a lot of heating costs in the winter, you really should try it
<jsgotangco> never deny a woman her vices!
<Hobbsee> hehehehe
<sivang> ogra: ha ha ha
<\sh> ogra: believe me, a nice bed and this r200 laptop on my hips is just enough to keep me warm and protect me from the winter in germany 
<ogra> on your hips ... aha
<Hobbsee> \sh: i thought that was a bad idea, and which was why they renamed them as notebooks :P
* sivang theorizes at "hiptops"
<\sh> ogra: with my blanket beneath the latop ;)
<ogra> "this laptop is right *and* left wearable!"
<\sh> prust
<ogra> s/laptop/hiptop/ (indeed)
<Hobbsee> ogra: hmmm...why just not stick a dep on kscreensavers-xsavers | xscreensaver-gl for the moment, then we can go back and look at it later - that will certainly cut down on the problems (kde) people have with the rss-glx screensavers.
<Hobbsee> a mostly working version is better than a not working one, after all :P
<Hobbsee> i cant see any other solution from my end, at the moment.
<\sh> Hobbsee: because this | is just for "install xscreensaver-gl when kscreensavers-xsavers is not there"
<Hobbsee> \sh: right.  which is the aim.
<ogra> \sh, seems like the best solution so far, i bet kscreensavers-xsavers is a kubuntu-desktop dependency, no ?
<Riddell> no
<ogra> hmm
<Hobbsee> oh hi Riddell 
<Riddell> salut Hobbsee 
<\sh> ogra: no...kscreensavers is a dep of kubuntu-desktop
* Hobbsee read that as "shut up hobbsee" the first time round.  i must be becoming paranoid :P
<pygi_> sivang, sorry, dc :-/
<thesaltydog> ?
<ivd> Ben Collins, are you there?
<mdke> ivd: his irc nick is BenC 
<ivd> thanks. :)
<BenC> ivd: I'm here
<ivd> Hi, I am one of the rt2x00 developers. And was reading the bugzilla report https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/34902
<Ubugtu> Malone bug 34902 in linux-source-2.6.15 "Ralink Wireless USB/PCMCIA/PCI hangs PC" [Critical,Confirmed]  
<ivd> Exactly that one. :)
<siretart> ivd: thats our bugbot :)
<ivd> Oops. :)
<ivd> I am not really used to IRC. ;)
<ivd> The problem with that rt2500 bug is that there are at the moment no new releases for the legacy drivers planned.
<ivd> ANd the SMP bug is only fixed in rt2500. Not in rt2400, rt2570 or rt61.
<ivd> So with a ubuntu kernel which has SMP on by default (not sure if it is, I am just assuming this) the legacy drivers will not work in ubunto
<ivd> ubuntu
<siretart> ivd: thats sad. SMP is enabled by default. how invasive would be a patch to fix that?
<ivd> which actually brings the point, that perhaps untill rt2x00 2.0.0 is released ubuntu should not ship with the legacy drivers.
<mjg59> Do they work on any hardware?
<ivd> Well only rt2500 is fixable by using the latest code.
<mjg59> The default install kernels aren't SMP
<ivd> rt2400 and rt2570 are not fixed at this time, and we are missing the developers & time to make it work.
<BenC> mjg59: On amd64 it is
<BenC> ivd: What about my bug report with rt2x00 and my rt2500 cards? :)
<mjg59> Oh, right
<BenC> ivd: problem is, we arleady released with rt2400,rt2500,rt2570,rt61 legacy in dapper
<mjg59> Why must drivers be so mean
<BenC> ivd: Good news is that even though the kernels are SMP, on a real UP machine, the locks and stuff are nop'd out
<BenC> so I really don't think that SMP has a lot to do with most of it (except on real SMP machines)
<ivd> BenC: Well looking at the problems the rt2500 are causing they are really similar to the SMP bugs.
<BenC> what exactly is the issue on SMP?
<ivd> There have been reports before that SMP kernels on a UP machine is still causing problems.
<BenC> ivd: Our SMP on UP is a different situation
<ivd> deadlocks, and a lot of races
<BenC> it really is more like a UP kernel when run on SMP, than the stock kernel would be
<BenC> deadlocks would be impossible considering that all the lock's are nop'd out
<BenC> more like a UP kernel when run on a UP system
<ivd> True again. But there is something in the SMP enabled kernels that is causing problems. Even on UP machines.
<ivd> Multiple users have tested this and it always resulted in problems.
<BenC> ok
<ppd> hi. where is openobex.pc in the dev package?
<BenC> ivd: So CVS contains a fix for rt2500?
<BenC> because we don't get a lot of reports on many other ralink cards besides rt2500
<ivd> Yeah, latest cvs works on SMP sustems.
<BenC> I may end up syncing the CVS version for a dapper update...I have two cards so I can atleast test it
<ivd> Only rt2400, rt2570 and rt61 are still problematic.
<_ion> ppd: This is probably what you're looking for: luotain% apt-file list libopenobex-1.0-0-dev
<_ion> libopenobex-1.0-0-dev: usr/bin/openobex-config
<ppd> _ion: hm. how shall I use that openobex-config?!
<ivd> BenC: If you have any problems with the rt2500 on SMP with latest CVS let me know.
<_ion> ppd: My guess would be "openobex-config [flags] " instead of "pkg-config [flags]  openobex"
<BenC> ivd: will do, thanks
<ppd> _ion: but this is the libsyncml configure script
<ivd> BenC: rt2x00 beta4 will be released within a few weeks but altough that is not yet ready for distros either, it will be a major step forwards since I expect it to be one of the last beta releases before stable
<ppd> _ion: it just complains about missing openobex
<BenC> ivd: I'm using current CVS and my rt2500 cards still don't work
<BenC> ivd: Anything I can do to help track that down?
<ivd> BenC: lockups? freezes? Or something else?
<BenC> ivd: I sent email to the list about it a few days ago
<BenC> sent reg output for both legacy and rt2x00
<BenC> it just wont associate
<BenC> rt2500 works perfectly on x86 and x86_64 for me, but rt2x00 wont work at all on either
<BenC> ivd: We release in november, any chance rt2x00 will be stable by then?
<ivd> BenC: (Lol, and I couldn't find your email anywhere... :) )
<ivd> BenC: I give that chance 75%
<BenC> ivd: that's funny because you replied to the email I sent :)
<ivd> Or at least it should have entered the Beta release where everything is working, but no hardware encryption yet.
<BenC> Subject: 	[Rt2400-general]  Problem rt2500pci with rt2x00 CV
<BenC> and any chance you will be using stock kernel ieee80211 instead of dscape?
<ivd> BenC: yeah, but I quickly forget names. Especially when I it is matching a name between forums and mailinglist. ;)
<ivd> BenC: Nope
<BenC> isn't dscape the cause of some of your missing functionality?
<BenC> I mean softmac is atleast in the kernel and it seems to be working well (for bcm43xx atleast, which I use too)
<ivd> BenC: No, that was the stock kernel ieee80211 stack. That stack was used in Beta3 and it was not usable for us.
<mjg59> BenC: It's likely that dscape will be merged to the stock kernel at some stage
<ivd> BenC: Ah that one. That has been added not too long ago. We had moved from the IPW stack to dscape stack by then. And it would take a lot of time to switch back.
<BenC> aslong as rt2x00/dscape is on track for kernel inclusion I have no complaints then :)
<ivd> BenC: And indeed softmac is already on the list for removal.
<ivd> BenC: rt2x00 is in the wireless-dev kernel tree together with dscape. When they merge they will be together. :D
<mjg59> BenC: Yeah, we probably ought to look at pulling from the dscape branch of wireless-dev in future
<BenC> yeah, that sounds like a good plan
<ivd> BenC: I am following the development of dscape closely to make rt2x00 always compatible with the latest dscape version.
<ivd> BenC: bcm43xx has 2 trees. 1 for softmac and one of dscape. The dscape version is also located in wireless-dev
<BenC> well bcm43xx+softmac is in 2.6.17-git
<infinity> BenC: Given the ltmodem problems on our SMP kernels on UP machines, I'm willing to belive that something's "not quite right" there.  That's why, at the last minute, I had to disable ltmodem building on anything but -386.
<BenC> infinity: yeah, I saw that
<ivd> Correct, but they are also maintaining the dscape version for when dscape will be merged with mainstream
<BenC> there may be some SMP related things that aren't getting nop'd out of modules, and I hadn't thought about that
<BenC> I need to revisit the smp-alt nop tables for modules in edgy
<BenC> I think I can wedge something in the relocation code to help with it
<bluefoxicy> wtf
<bluefoxicy> Arjan is telling me the code I'm trying to write in the kernel is fundamentally impossible
<bluefoxicy> and I'm looking at what I just wrote and it does all these things he just got done telling me can't be done o_O
<mjg59> bluefoxicy: Which Arjan?
<tseng> you know what happened last time you argued with arjan, linus
<bluefoxicy> mjg59:  van de Ven
<tseng> mjg59: van den
<mjg59> He generally knows what he's talking about...
<bluefoxicy> tseng:  I'm showing code this time
<bluefoxicy> mjg59:  He's telling me I can't have one arch_align_stack() that works on all architectures because architectures may have different alignments and may have varied alignments for different userspace (i.e. 32/64 bit multilib userspace); I already solved those problems, it works.
<ivd> BenC: I gtg now. I'll take another look at the logs you send previously. Since apparently I either missed a register initialization thing or there is another problem happening.
<bluefoxicy> tseng what do I do, hide my code or show it to him?
<BenC> ivd: Ok, thanks
<mjg59> Code speaks wonders
<BenC> ivd: btw
<tseng> bluefoxicy: you can show it if you'd like
<tseng> bluefoxicy: did you do one for hppa
<ivd> BenC: I hade made several fixes for the registers yesterday, so it should have worked now..
<BenC> ivd: If you are willing to help with bug reports from launchpad, I'm willing to force rt2x00 on folks during edgy devel to maybe whip it into shape by our release
<BenC> more users can possible help shake down things a bit
<bluefoxicy> tseng:  one for hppa?  The code is not per-arch, and the main randomize_stack_top() already accounts for stacks that grow up rather than down (someone else wrote that code)
<tseng> (oh)
<BenC> ivd: I haven't tried in a few days, I can try again
<tseng> bluefoxicy: might as well show him I guess
<BenC> ivd: At worst, I just switch off to legacy in the later days of devel
<ivd> BenC: I can take a look at the bugs in lauchpad about rt2x00. But I have little time for legacy driver maintenance.
<bluefoxicy> tseng:  oh, though thanks, you just reminded me I need to take the same stack-grows-up check and stick it in arch_align_stack(); mine currently moves %esp down, it needs to move up if the stack grows up (I think... I honestly don't know, it just seems logical)
<tseng> bluefoxicy: I would think
<BenC> ivd: No, I mean help with bugs on rt2x00 if I force ppl to use it :)
* BenC has that power
<ivd> BenC: lol. :)
<ivd> BenC: Thats a deal then. :)
<ivd> BenC: if you could inform me about bugzilla reports I would happy to take a investigate those problems.
<ivd> *launchpad reports
<BenC> excellent
<ivd> BenC: I gtg now. Cya
<HiddenWolf> who is the ubuntu webmaster? 
<ogra> HiddenWolf, heno
<ogra> (one of them)
<HiddenWolf> ogra: There is a screenshot of oo-welcome on the "desktop" page which refers to the installer as espresso
<ogra> ouch
<ogra> i think there is a website component in malone since a week or so ... 
<HiddenWolf> http://www.ubuntu.com/include/img/openoffice.png
<HiddenWolf> it might be applicable to example-content as well
<HiddenWolf> and there doesn't seem to be a website component
<ogra> ah, yes, there was only a discussion about re-adding itr
<kagou> hi
<ProN00b> wmv3 worked in vlc in badger but it doesn't work in drake anymore
<kagou> ProN00b: you have made a bug report ?
<ProN00b> no, i regard this as one, but where can i post formally ? (and its not really a bug, i think the package maintainer just decided to not enable external codecs anymore)
<kagou> ProN00b: https://launchpad.net/distros/ubuntu/+source/vlc/+bugs for existing bug and https://launchpad.net/distros/ubuntu/+bugs for report one
<kagou> ProN00b: see #ubuntu for help.
<ProN00b> +source ?
<HiddenWolf> ogra: can you make sure that someone looks at that screenshot?
<mgalvin> jdub: do you also do the actual moderation of ubuntu-news?
<mdke> mgalvin: "ubuntu-news list run by mako at ubuntu.com"
<mdke> mgalvin: (I think Riddell is a moderator too)
<mgalvin> mdke: ok thanks
<BenC> has dapper-security opened yet?
<infinity> BenC: Not yet.
<infinity> elmo needs to mess with some fiddly launchpad->dak import stuff, then we'll be good to go.
<infinity> Monday, hopefully.
<desrt> heh
<desrt> new kernel already?
* desrt has a handful of fixes for you :)
<infinity> BenC: I assume we're holding off on dapper security updates until we can sneak in Sparc tg3 fixes anyway, no? (or is there something critically urgent that we have to release for YESTERDAY)?
<BenC> infinity: yeah, still waiting on that one
<desrt> BenC; did you get the email i sent?
<BenC> desrt: what was it about?
<desrt> pci_restore_state
<BenC> yeah, I got that
<desrt> gregkh and andrew morton have already signed off on the mentioned change, fwiw
<BenC> the reverse order one?
<desrt> ya
<BenC> can you forward the patch to me?
<desrt> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-03-pci/pci-reverse-pci-config-space-restore-order.patch
<desrt> it won't work for ubuntu unless you turn the fuzz level up pretty high
<desrt> since we already have a patch in that part of the code
<desrt> but it's just basically for (i = 0; i < 16; i++) --> for (i = 15; i >= 0; i--)
<BenC> Ok, I'll get it into the dapper-security upload
<desrt> are you generally open for requests?
<BenC> if they make sense, yeah
* desrt has a fix for the intel HD audio driver to make it work on intel macs
<desrt> also, a fix for a device table in usbhid to enable the Fn key on my macbook
<BenC> I'm going to be more open for dapper-updates than I was for breezy-updates since I already have an edgy kernel ready, and the workload wont be so high
<desrt> also -- if possible, could you enable mac_hid on intel?
<HiddenWolf> BenC: wow, what happened to taking a few days off? :)
<desrt> it's the thingy that does the mouse button emulation
<infinity> BenC: Speaking of your edgy kernel, can you let me give LRM a once-over before you upload the first edgy revision?
<BenC> desrt: provide patches, and I'll review them
<infinity> BenC: There are a few gotchas that I want to make sure didn't... getcha.
<desrt> BenC; is .dsc format ok?
<BenC> infinity: Sure, it's pretty smallish in changes from the dapper version
<infinity> BenC: (And I'm really bad at letting things go)
<desrt> bah
<infinity> BenC: And, it should be larger in changes from the dapper version than you've made it, I suspect. :)
* desrt just breaks the patches out :)
<BenC> desrt: .dsc, no, I need patches in git format preferably, or just diff -u if not
<desrt> k.  i'll get back to you with them
<BenC> HiddenWolf: No one else is taking days off, so I can't afford to look lazy :)
<BenC> "edgy's been open for 2 days ben, and there's no new kernel crack...we need to talk"
<HiddenWolf> BenC: lmao
<BenC> desrt: pci-reverse patch is in git now
<desrt> BenC; rocking :)
<desrt> if possible, changelog cred me for finding that it makes sleep work on the macbook :p
* desrt is feeling a little bit insecure about the fact that someone came up with the exact same idea slightly before he did >:|
<infinity> desrt: Haha.  "There are no original ideas" and all that. :)
<desrt> infinity; i was up until 6:30am!
<desrt> crikey.
<desrt> for a one-liner
<infinity> desrt: At least you got confirmation from others that your fix is sane.
<desrt> infinity; true story.  and as a result,  it'll land in the next kernel
<desrt> ++
<desrt> BenC; #1: http://desrt.mcmaster.ca/random/intel-hda.patch
<desrt> BenC; ubuntuified version of a patch from the mactel-linux page
<desrt> (were some small conflicts)
<desrt> BenC; what's your policy about changing kernel config?
<zul> hey
<desrt> BenC; specifically - i have a patch in my macbook-modules package which #define's a CONFIG_ variable to avoid having to change the kernel config...
<HiddenWolf> desrt: after release?
<desrt> #define CONFIG_USB_HIDINPUT_POWERBOOK
<desrt> HiddenWolf; ya.  in dapper.
<BenC> desrt: that one should be ok
<BenC> desrt: pass that intel-hda patch by crimsun (better yet, send it to kernel-team@l.u.c
<BenC> )
<desrt> BenC; the #define thing should be OK?
<BenC> yeah
<desrt> ok.
<looksaus> is there anything I can still do to help https://launchpad.net/distros/ubuntu/+source/firefox/+bug/40067 get fixed?
<Ubugtu> Malone bug 40067 in firefox "firefox freezes after a few secs on ppc" [Normal,Confirmed]  
<desrt> the patch is pretty trivial then.  lemme post it
<BenC> Ubugtu: odd, I'm using firefox daily (all day) on my G4
<BenC> hrm
<BenC> s/Ubugtu/looksaus/
<looksaus> it's a bit ironic that I'm leading ubuntu-be.org without a working gecko engine...
* BenC needs sleep
<desrt> benc; http://desrt.mcmaster.ca/random/hid.patch
<looksaus> someone tried to reproduce it, but failed
<BenC> desrt: kernel-team@l.u.c please
<desrt> ok.
<BenC> so I can just chuck the whole mbox into git-applymbox
<looksaus> (some ubuntu dev, I mean)
<desrt> :)
<looksaus> another user confirmed it
<desrt> BenC; attach the files to the email, then?
<BenC> inline
<BenC> no attachment
<desrt> i hope the tab/spaces don't get messed up.
<looksaus> BenC, would it make sense for me to set up an ssh connection into this machine?
<BenC> short description at top, and subject should be like: [UBUNTU:foo]  short desc
<BenC> desrt: what are you using for a mail client?
<desrt> evo
<BenC> preformatted should work
<looksaus> I mean, to provide you or someone else ssh access to this machine?
<BenC> looksaus: I'm no firefox dev, so I can't help
<desrt> so like [UBUNTU:snd-hda-intel]  fix routing on macbook
<BenC> yeah, perfect
<desrt> k
<looksaus> BenC, I don't mean you per se
<looksaus> who could I try to talk to? or is there anything else I could do?
<BenC> looksaus: I don't know how the firefox dev likes to handle that
<BenC> likely a good gdb backtrace would help
<looksaus> see the bug report
<looksaus> it's already there
<BenC> then there's not much else to do other than maybe go to the mozilla folks directly
<looksaus> ok :(
<looksaus> BenC, would it be useful for me to drop by the Paris conference?
<desrt> BenC; about patchlevel... should the toplevel path compoent be linux/ or drivers/ ?
<BenC> looksaus: yeah, can't hurt
<BenC> desrt: -p1 type level
<desrt> k
<looksaus> ok, so now my job is to find out who's doing firefox bugs in ubuntu...
<BenC> looksaus: can't guarantee anyone will have time to look at it
<looksaus> thx
<BenC> np
<looksaus> is there also less technical work at this meeting (think stimulating local use & press coverage stuff)?
<infinity> looksaus: Not really, it's not that kind of meeting.
<infinity> looksaus: it's just a bunch of developers getting together to plan edgy.
<Chipzz> ah looksaus zit hier ook :)
<looksaus> Chipzz, hey!
<BenC> we will be working hard on writing a lot of overly technical documents in the hopes that someone else will have to implement them :)
<looksaus> :)
<zul> like infinity 
* Keybuk starts off his "rewrite the kernel from scratch" spec
<HiddenWolf> Keybuk: lmao. :)
<HiddenWolf> Keybuk: how about making init faster. ;)
<looksaus> Chipzz, seen http://map.ubuntu-be.org/nl already?
<Keybuk> HiddenWolf: actually, that _is_ what I'm planning to do for edgy
<HiddenWolf> Keybuk: yay, you'll save me another 20 seconds once a month. ;)
<Keybuk> HiddenWolf: though largely I'm planning to make init more reliable and useful
* HiddenWolf imagines that was a bit too cynical
<HiddenWolf> sorry Keybuk :)
<Keybuk> the upshot of which is that we won't need to start lvm, evms, hpiod, etc. on most machines
<Keybuk> thus saving memory too
<HiddenWolf> oh, now we're talkin'
<infinity> HiddenWolf: No, your cynicism, as it relates to boot time is well-founded, IMO.  I get rather irritated by "if my machine boots 10 seconds faster, YOUR OS WILL STOP SUCKING" stuff too.
<Keybuk> apparently Marga did a talk at debconf that Debian boots faster than Ubuntu
<Keybuk> as if this were surprising
<infinity> HiddenWolf: Keybuk's new init proposal has little to do with speed increases, though (though it will likely yield several), it's all about completely rethinking how we do userspace even scheduling, really.
<sivang> re all
<HiddenWolf> infinity: still, I'm talking to people I can't see, can't judge what mood they are in, or even culture they come from, yet who I do respect, so I should be more careful.
<infinity> Keybuk: Err, but Debian configured HOW?... Ubuntu's default setup has a lot of stuff.
<Keybuk> e.g. "mount the usb disk on /usr when it's ready" ... not "mount it 25s after boot whether it's ready or not...oh, wait, can't mount it :p"
<Keybuk> infinity: allegedly "the same as Ubuntu" ... I think it was just Debian standard plus GNOME though
<sivang> Keybuk: I also get this argument, and try to ask people what's their setup that seem sto boot so quickly.
<sivang> they usually need to go extra milage for stuff that comes ootb in ubuntu, then their debian boots just as "slow" ;-)
<Keybuk> sivang: remove pcmciautils, brltty, mdadm, lvm, evms, pcmcia, ppp, hplip, festival, apmd, et. al. if you don't need them
<Keybuk> it's faster, but not useful from a distrbution PoV
<sivang> exactly
<Keybuk> if you want the fastest possible boot, compile your own kernel and build in all the drivers you need and leave out absolutely everything else (not even as a module)
<Keybuk> prepare a static /dev with just those nodes, then you don't need udev
<sivang> right
<infinity> Amen, brutha, death to udev.
<sivang> heh
<infinity> Err, that might be the server guy in me talking.
<Keybuk> if you want it _really_ fast, replace init with a small shell script that just starts what you want
<Keybuk> infinity: udev is still useful on the server - Solaris has had similar for years, after all
<sivang> Actually with my new laptop boot times are best then ever, I just wish I could find the guy how decided ot have a SATA-PATA bridge in t43 models... what I thought was a kernel / ubuntu specific + this exact laptop model problm,
<Keybuk> though I realise it doesn't fit in with the BSD-derived "a server must only do exactly what it was supposed to, and no more"
<infinity> init here just starts postfix, then kicks off a while loop involving mailx and some guy named "Scott"... Not sure that that's about.
<sivang> appears to be lying in the bugs in this bridge
<Keybuk> which leaves you stuck when you have to change the network card, and the evil vendor changed the chipset in a minor revision ;)
<infinity> Keybuk: Real servers don't use Netgear cards. :)
<Keybuk> infinity: or 3com? :p
<Keybuk> sivang: what _is_ a SATA-PATA bridge?!
<sivang> Keybuk: you don't really want to know
<infinity> Keybuk: What 3Com changes chipset in a monor revision?  They always used to be so good about product separation.
<infinity> Keybuk: Did this happen in the gigabit line, which isn't their own silicon for once?
<Keybuk> infinity: the 'v' one, can't remember which that is
* infinity suspects 3Com's just getting lazy now, and has become "yet another 3rd party board vendor"
<sivang> Keybuk: according to sladen 's research , an what thinkwiki says, this is a method to under exploit a perfectly good SATA controller, and control a PATA HD with it
<Keybuk> sivang: all SATA controllers can control PATA hard drives
<Keybuk> they usually all have PATA ports on them
<Keybuk> though, admittedly, they usually expose them _as_ PATA rather than SATA
<infinity> Keybuk: The vortex's all have different model numbers to match this chipsets. (3c590, 3c595, 3c900, 3c905, 3c950, 3c450, etc)
<infinity> s/this chip/their chip/
<sivang> Keybuk: so , on this machine, I get /dev/sda and the SATA stack is used, but the undelying HD is PATA
<Keybuk> infinity: hmm, I honestly can't recall, I just remember tripping over it once :-/
<infinity> Thoug, in Linux, they all use the 3c59x driver, since they're similar enough, except for some initial register futzing.
<sivang> Keybuk: ah, I see. Then I Wonder why a specoial "bridge" was needed as even Lenovo themselves state that this bridge is used
<Keybuk> sivang: are you sure that's the hardware, and not a prematurely libata'd PATA controller in Linux?
<Keybuk> all PATA will show up as /dev/sda in time
<sivang> Keybuk: is there a more accurate way to test this?
<Keybuk> though it would not surprise me if new ATA controllers simply exposed the PATA ports as SATA ports -- it'd me much less silicon
<Keybuk> indeed, I'd probably say that's a good thing
* desrt seeks infinity's help with doing something evil
<infinity> desrt: I'm always open to evil.  'Sup?
<thom> desrt: keybuk is a better choice for evil usually
<desrt> infinity; i want to enable the mac mouse button emulation hack on x86
<sivang> Keybuk: however, it turns out that there are some bugs with this bridge, which the so called "approved" HDs by Lenovo/IBM only workaround a bit
<desrt> infinity; preferably in a way that doesn't involve the ABI shifting, ....
<sivang> Keybuk: sladen tried with a different HD and it has an enormous performance impact,
<infinity> desrt: I refuse to ackowlege that there are computers with less than 2 mouse buttons (unless the number is zero, due to having no mice)
<desrt> infinity; unfortunately, the emulation thingy exports a symbol which needs to be called from char/keyboard.c
<sivang> Keybuk: but propotional to what I am experiecning with the "approved" drive
<desrt> infinity; 1) fewer than
<desrt> infinity; 2) i have 2 mouse buttons, but i want to use the emulation for middle mouse
<sivang> infinity++
<infinity> desrt: Why not just use X's 1++2=3 hack?
<desrt> chording is for pussies
<infinity> s/++/+/
<HiddenWolf> wtf
<Mithrandir> desrt: why do you need it in the kernel?
<desrt> Mithrandir; because that is where it lives
<HiddenWolf> gnome-cups-icon is taking up 30mb ram....
* HiddenWolf wonders
<infinity> desrt: Only if you deeply care about having a 3rd mouse button in the console..
<desrt> Mithrandir; it's a driver that for some strange reason is only enabled on PPC
<infinity> desrt: You could just as easily remap your keyboard a bit in X.
<desrt> (admittedly, there's a high correlation between PPC and not having enough mouse buttons, but otherwise there's no good reason for this)
<Mithrandir> desrt: you know you can do it using XKB, right?
<infinity> desrt: In which case, you want Mithrandir, not me.
<desrt> Mithrandir; oh, really.
<desrt> Mithrandir; i can make keys act as mouse buttons?
<Mithrandir> I poked at it slightly earlier today, but not enough to find out what the syntax was, but it's certainly doable.
<desrt> please keep poking :)
<sivang> Keybuk: so now I Have to put up with reproducable halts of the system, especially under high IO load ( 2 find running it 2 gnome terminals brings the system to its knees)
<desrt> is it some xmodmap thing?
<sivang> Keybuk: or restore windows from product revoercy cds and demand they repace it with a SATA drive to be SATA fully
<sivang> Keybuk: another workaround seems to be putting the HD In the ultra slim bay, which then puts it into a native PATA controller, which solves the issue
<sivang> Keybuk: (this is official by IBM's KB)
* sivang ARGSH AGAIN about the IBM/Lenovo expansive to the user PoV
<desrt> ugh
* desrt showers
<Keybuk> sivang: sweet :)  don't buy Lenovo <g>
<desrt> bbiab.
<sivang> Keybuk: I wish someone had told me that before I did that :-/
<infinity> sivang: I thought your issue was a vendor that sold you a Thinkpad with a non-approved drive?
<infinity> sivang: Hardly Lenovo's fault.
<sivang> infinity: oh, that was long long ago :-)
<sivang> infinity: I returned that one with a full refund (that was a US dealer, so I could get a full refund)
<infinity> Oh, I don't keep up with your laptop sagas. :)
<sivang> heheh, yes I do have quite some of them
<sivang> infinity: this one I Purchases legite from an .IL approved and known IBM partner
<Keybuk> surely you want a known Lenovo partner? :p
<Keybuk> given Lenovo != IBM
<sivang> infinity: at least it has no dead pixels anymore, and no beeps on the HD being incompatible ;-=)
<sivang> Keybuk: same in .IL ;-) even suppport is still run by IBM for Lenovo's boxes
<sivang> Keybuk: but yes, a Lenovo partner probably
<tale_> can somebody point me to documentation about building cvs gnome projects on dapper?  I need to get the environment configured correctly.
<sivang> tale_: seach for jhbuild
<tale_> k
<sivang> err, search even
<Keybuk> tale_: #ubuntu
<sivang> tale_: also what Keybuk said :)
<tale_> ok.  I looked there, but they seem to be mostly newbie questions not interested in compiling.  I'll give it a try.
<HiddenWolf> tale_: there is a page on the live.gnome.org site about it too
<sivang> tale_: http://live.gnome.org/JhbuildOnUbuntu
<tale_> thanks
* HiddenWolf high-fives sivang
<HiddenWolf> nice timing. ;)
* sivang high fives HiddenWolf 
<desrt> Mithrandir; do you have any pointers for me?
<desrt> Mithrandir; ok.  i got it.
<desrt> Mithrandir; download a utility called xkbset
<desrt> Mithrandir; then use xmodmap -e to set the keycodes of the keys you want to Pointer_Button1, 2, 3...
<desrt> Mithrandir; then run 'xkbset m' to enable mousekeys
* desrt slowly removes his dependency on his custom moduleset
<sivang> sladen: ping, you aware of the stick point behavior such that when pressed with the same pressure at the same direction , it will eventually stop moving the curosr, "freeze" and when pressure removed and you don't touch it afterwads will make cursor go in the opposite direciton for some milisecs ?
<infinity> sivang: That's intentional, and it's a hardware feature.
<sivang> infinity: ah, good, I thought I was starting to get crazy.
<infinity> sivang: The pointer is adjusting itself to drift, so that when you wear it out, it won't drift forever.
<sivang> infinity: ah, I see interesting life facts of the stick point
<sivang> infinity: you also have a think pad right?
<infinity> Yeah, and a Toshiba laptop with the same type of pointer.
<infinity> And I've owned older Toshibas before "drift correction" was invented, which would get stuck in a corner of the screen when they gold older.
<infinity> Very annoying.
<infinity> Trust me, drift correction is a Good Thing. :)
<infinity> s/gold/got/
<infinity> Odd typo, that.
<sivang> I see, can you spot the curosr movement in dapper is "jerky" , that is not smooth while used with the stick point ?
<sivang> infinity: gold older :)
<sivang> you've just made me think more positvely about aging
<sivang> indeed, odd typ
<sivang> typo
<infinity> Jerkiness depends on how you have your acceleration configured, among other things.
<infinity> It behaves for me more or less how I want it to.
* sivang tries to think what would be the ideal settings for the cursor to not be jerky
<infinity> I just set an acceleration and velocity (both rather high) that seemed "about right", and got used to it.
<infinity> Wit hthe acceleration cranked as I have it, it does "jerk" a bit, but I know exactly where it'll land, so I don't really mind.
<sivang> same here, I have high acceleration
<sivang> interesting, that in the same acceleration, using hte touch pad it does not jerk
<sivang> or, "jerk"
<sivang> I guess the touchpad provides smooth motion naturally
<sivang> while the stick point hardware has to emulate it
<infinity> The touchpad has no native acceleration.  It's just linear movement.
<infinity> The stick has native acceleration based on how far you push it from center.
<infinity> So you mix the native acceleration with GNOME's acceleration and you get a bit of jerk.
<zul> y
* sivang wishes he was not so sensitive to these visuals
<infinity> z
<zul> a
<sivang> x
<sivang> I wonder how XP make it not "jerk"
<infinity> Better post-processing filtering.
<infinity> Well, "better".
<sivang> heh
<infinity> XP's cursor movement has little to do with what you're actually telling the stick to do, which is generally what people want, I suppose.
<infinity> It filters input from mouse devices and smooths them out, so jerky movements become smoother.
<infinity> X just passes it through and says "you wanted that last huge jump, you got it"
<sivang> I see
<sivang> thanks for the clarifications. I wonder if it's worth effort to have something like this in ubuntu / linux in general
<infinity> I'm sure people would be happy to take patches for better mouse event filtering.
<infinity> For all I know, evdev (the wave of the future for input devices in X, in theory) may already handle some of this stuff, but we don't use it by default.
<sivang> do we have packages to experiment and test with?
<infinity> xserver-xorg-input-evdev -- No idea how well it works.  Never used it.
<sivang> I will give it a try
<sivang> ah, already installed , then probably only settings change
<sivang> infinity: re touchpad, if it does not have native acceleration, then it uses GNOME's acceleration right?
<infinity> sivang: The touchpad is still subject to GNOME's acceleration settings, yes.
<infinity> sivang: So is the stick, it just has its own ideas about acceleration too.  So it's accelerated twice.
<crimsun> infinity: are you familiar with configuring dapper chroots via deboostrap? I know at least tzconfig and locale-gen need to be executed.
<crimsun> debootstrap, rather
<crimsun> (and that should probably read "post-debootstrap")
<infinity> crimsun: Well, neither needs to be run for a chroot for compiling and other such fun.
<infinity> crimsun: But if you're intending to turn that chroot into a desktop system, then yeah, tzconfig should be run at some point, shadow should be configured, a langpack should be installed (which will generate locales for you)...
<crimsun> infinity: thanks. I'm receiving quite a few questions about turning a chroot into a desktop system.
* sivang notes this chroot question is intresting for him as well
<sivang> and you proper mounts for the X socks should be available to run GNOME etc..
<infinity> sivang: Your question's a different one. :)
<infinity> sivang: None of the above is required to use a chroot, just to turn it into an "installed desktop".
<HiddenWolf> who will be maintaining X for edgy?
<infinity> sivang: To run an X application in a chroot, just bindmount /tmp to /chroot/tmp
<infinity> HiddenWolf: Several people.
<mdke> HiddenWolf: infinity is maintaining all of edgy
<infinity> mdke: Die.
<sivang> heh
<mdke> everyone else is going to start on edgy+1
* sivang can confirm this
<HiddenWolf> ;)
<HiddenWolf> Piece of cake, he'll only have to fix like 2500 bugs per month
<sivang> infinity: and also bindmount home for completness :-)
* HiddenWolf hugs everyone
<infinity> sivang: Well, that's assumed.  :)
<infinity> sivang: I bindmount /home in all my development chroots.
<infinity> sivang: Also a good idea to make sure to "mount -t proc proc-chroot /chroot/proc"
<sivang> ah rig
<sivang> right, even
<crimsun> infinity: yeah, I've followed Colin Walters's debootstrap guide for some time but wasn't familiar with needing to reconfigure passwd, install a langpack, tzconfig, etc. for a Dapper chrooted desktop
<sivang> infinity: only one issue still elluded me (and even pitti when we did some DB2 GUI tools testing) what do you do to make the X app inside the chroot to be able to open an X connection? (this seems to be ellusive, and works find on a non chroot system, using ssh -X )
<LaserJock> crimsun: you seen https://wiki.ubuntu.com/DebootstrapChroot ?
<crimsun> LaserJock: I thought I contributed to that ;)
<infinity> sivang: Erm, do you mean specifically over SSH, or just local-to-local X?
<infinity> sivang: Bindmounting /tmp (and not blowing away your environment when you chroot) will allow local-to-local.
<LaserJock> crimsun: well, I just wondered since it describes post-chroot and fstab
<sivang> over ssh it would work, I want it work to local-local
<sivang> how do I not blow away my env? is ther ean equivalen to sudo - for dchroot ?
<infinity> sivang: If using dchroot, use "dchroot -d" to not destroy the environment, if using plain old chroot, "chroot /chroot su" and not "chroot /chroot su -", since the former is a login shell and will kill your env.
<infinity> s/former/latter/
<crimsun> LaserJock: it covers many, but not Dapper-specific ones like installing a langpack (i.e., it still says to reconfigure locales)
<LaserJock> crimsun: right, hmm I should probably fix that in the Packaging Guide
<infinity> crimsun: The only difference between older systems and dapper should be the locales move out of glibc.
<infinity> crimsun: Everything else should be the same.
<crimsun> infinity: great, noted. Thanks again.
* HiddenWolf just turned 21
<sivang> HiddenWolf: happy birthday
<infinity> (And that's a non-issue if, like me, you don't mind living in C/POSIX...)
<LaserJock> infinity: one question that I dpkg-reconfigure passwd and it asks me for a root password. Do you know if it is possible to skip that part?
* sivang wished he could be 21 again ;-)
<infinity> LaserJock: Don't dpkg-reconfigure passwd.  Why are you doing that?
<HiddenWolf> sivang: I feel kinda old, actually. ;)
<LaserJock> HiddenWolf: happy birthday
<infinity> LaserJock: The only thing that needs to be configured it to enable shadow, so do that explicitely.  "shadowconfig on"
<LaserJock> infinity: when I set up a dchroot to use sudo
<sivang> HiddenWolf: then feel glad you're not 27
<HiddenWolf> *chuckle*
<infinity> LaserJock: Err, my dchroots don't have passwd/shadow configured in them at all.
<infinity> LaserJock:
<infinity> (base)adconrad@cthulhu:~$ grep adconrad /chroot/dapper/etc/passwd
<infinity> adconrad:*:1000:1000:Adam Conrad,,,:/home/adconrad:/bin/bash
<LaserJock> infinity: hmm, maybe I should modify DeboostrapChroot to just do "shadowconfig on"
<infinity> LaserJock: That lovely "*" for a password makes password stop looking for a shadow entry, and you win.
<HiddenWolf> Good night everyone
<infinity> LaserJock: You only want shadow passwords if the chroot is going to become a "real, installed system" at some point, like crimsun is doing.
<infinity> LaserJock: For dchroot, it's kinda pointless, since you don't need to authenticate in the chroot, ever.
#ubuntu-devel 2007-05-28
<lifeless> Keybuk: hi, just got off the plane
<shaya> any idea why a setuid root program will run with a euid of the user running it?
<shaya> when it never calls seteuid or the like
<shaya> on gutsy
<shaya> seems to be static vs dynamic oriented
<shaya> weird
<shaya> I'm an idiot
<shaya> libtool was doing some funky script
<shaya> can't setuid scripts
<Hobbsee> morning all
<ion_> Night.
<jmg> hey all
<jmg> who should i pester about problems with a 2gb sd card under feisty?
<jmg> im not sure where to file the bug or if a bug is even nescessary
<Burgundavia> it is a kernel bug
<Burgundavia> the proper time for reporting such issues is before release
<jmg> well, it was a bug under edgy. the 2.6.20 changelog had an entry for adding sdhc support, I assumed that would fix it. Are you saying its too late and i should just foad?
<jmg> how do I know its a kernel bug and not libusb/gnome-volume-manager?
<jmg> answer, I dont.
<jmg> thats not a very helpful response.
<minghua> jmg: it's probably more helpful if you test gutsy and see if the problem is still there
<minghua> jmg: and if yes, report it so that it can be fixed before release this time
<jmg> minghua: right, i just distupgraded to feisty.
<jmg> i dont particularly want to upgrade to gutsy to see if a bug is fixed there. I dont think generic users will want to either, they'll just go back to winxp.
<RadiantFire> jmg: use a vm like qemu
<ajmitch> that's not going to help much with a hardware problem
<RadiantFire> it won't work if it is in userspace, it will if its a kernel bug?
<RadiantFire> at least thats what i would think
<minghua> jmg: then at least you can update the bug (I assume it's already reported) and say it's not fixed in feisty
<RadiantFire> i do not know much about such things
<minghua> jmg: comments on IRC will eventually get lost
<jmg> minghua: i had a poke through lp looking for a bug report (fat16, sd), couldnt find one
<jmg> minghua: but im trying to establish where the bug is and where to file it first
<minghua> jmg: as Burgundavia said, report it against kernel
<minghua> jmg: the developers will reassign it to the correct package if needed
<jmg> minghua: 88147 has some clues
<jmg> #88147
<jmg> what is the kernels name in launchpad?
* Hobbsee checks if planet ubuntu has blown up yet
<Hobbsee> seems not
<Burgundavia> why so?
<Hobbsee> Burgundavia: was wondering if \sh's post was inappropriate for planet
<Burgundavia> right
* Hobbsee shrugs
<Hobbsee> figured i'd wait to see if anyone else mentioned it
<Burgundavia> \sh is frequently borderline
<Burgundavia> anyway, need ot sleep
<Hobbsee> i know...
<Hobbsee> night!
<Lure> Mithrandir: can you give-back kdegraphics to pick up new poppler package dependancies?
<bonii> j #fedora-devel
<Treenaks> bonii: wrong channel ;)
<bonii> Treenaks: Not exactly, I was joining that channel as well for the / :-)
<bonii> Treenaks: *forgot
<Riddell> Lure: it's a holiday today in most places
<Lure> Riddell: oh, right...
<tepsipakki> I guess no package that build-deps on non-free java gets built and included in the distro (because it tries to ask a question, which fails)?
<tepsipakki> I was looking for fop, but it's waiting on libbatik-java which doesn't build because of that
<shawarma> fop's in its way in? Nice.
<tepsipakki> shawarma: doesn't look like it
<tepsipakki> it's been in debian for ages
<keescook> hunh.  is this actually a free license?  http://bastard.cvs.sourceforge.net/*checkout*/bastard/libdisasm/LICENSE?revision=1.1
<keescook> while it would allow debian/ubuntu to redistribute it, I'm not sure that would get past NEW
<geser> is it the same licence text as in /usr/share/common-licenses/Artistic?
<persia> keescook: I'm not an authority, but section 4 looks worrying to me: there's no provision for only including instructions on getting modified source with the package, so 4d might apply.
<keescook> geser: except for the initial paragraph, it matches Artistic
<keescook> specifically "however it cannot be incorporated into a commercial product --aside from OS distributions and other collections of user software-- without the express permission of the developer."
<geser> is that an additional clause or a human understandable summary of the licence?
<keescook> geser: afaict, it's an additional clause.  :(
<geser> besides the commercial product part is sounds like paragraph 5
<maswan> kylem: Did you have a kernel for me to test?
<keescook> oh... and they dropped Artistic item #8 too.
<keescook> (and then renumbered stuff)
<Fujitsu> Why do people have to invent their own licenses?
<StevenK> Because they wish to be thpecial.
<ompaul> Fujitsu, because they are broken?
<Fujitsu> ompaul: Probably.
<ompaul> it is a design flaw to remake the wheel ;-) file a bug :)
<st3> hi everybody, i'm a maintainer of bcm43xx
<st3> some ubuntu users are reporting a broken bcm43xx driver, so i'd like to know what driver version you put into ubuntu kernel "2.6.20-15-generic #2 SMP x86_64"
<persia> st3: You might have better luck in #ubuntu-kernel (although someone may also answer here)
<st3> thank you
<cprov> siretart: ping
<Hobbsee> heya all
<mdke> hiya Hobbsee 
<Hobbsee> hey mdke!  how's it going?
<mdke> well thanks. a much needed public holiday
* Hobbsee notes that there are too many people with short nicks starting with M on this channel.
<Hobbsee> :)
<Hobbsee> i hear we get one in 3 weeks or so.  shudder.
<StevenK> Two weeks. The 11th of June
<Hobbsee> two.  even worse.
<StevenK> And what's so bad about public holidays?
<Hobbsee> StevenK: because i usually end up having to work them.
<StevenK> Hobbsee: Ahhh.
<Hobbsee> StevenK: and we get a higher number of COH's than usual, which is particuarly good, as almost always, our computer systems will completely break down too
<StevenK> Neat.
<kylem> maswan, yeah
<kylem> sorry, just started the day here.
<maswan> kylem: no problem, just let me know when we can try it. we recently managed to find a test case that triggers the page allocation failure in .55 but not .53.
<Hobbsee> mdz_: elmo ping.
<mdz_> Hobbsee: hmm?
<\sh> mdz, please can you remove my launchpad account, thx
<Hobbsee_> GRRR @ BIGPOND.
<mdz> \sh: no, I can't.  I believe launchpad-users is the place to ask for that if you want it
<Hobbsee> [23:33]  <Hobbsee> mdz: could you step into #ubuntu-motu please?
<Hobbsee> [23:34]  --> Demitar has joined this channel (n=demitar@c-212-031-190-120.cust.broadway.se).
<Hobbsee> [23:34]  <Hobbsee> mdz: we've having a discussion on the inappropriateness of posts for planet, and it'd probably help to have someone official there
<Hobbsee> [23:34]  <Hobbsee> mdz: i can give you a backlog if you like
<mdz> Hobbsee: I'm there, backlog would be helpful
<\sh> mdz, well, fyi, I removed my rights, and my CoC...please remove my blog from planet, just because I can't anymore...I'll step back from all my duties
<StevenK> Hobbsee: You missed what \sh said in -motu.
<mdz> \sh: that's your choice, but seriously, I don't administer planet either
<\sh> mdz, hmm.but yoiu have a ssh key for it ;) and are in the right place of LP...so you can adjust the planet.config
<jikanter> ls
<Hobbsee> StevenK: no i didnt - LongPointyStick 
<tkamppeter> pitti, hi
<jikanter> oops, sorry wrong place to type that
<Hobbsee> mdz: grabbing it now.  internet dropped out, had to physically go and reset the cable & router.  http://rafb.net/p/zyjUBn76.html
<StevenK> Hobbsee: Oh, right
<Hobbsee> StevenK: that's part of the reason for me keeping it there - for when the ISP screws up...
<shawarma> \sh: You're still member of ubuntu-members... You should be able to do it yourself.
<jikanter> ls
<\sh> shawarma, nope...I disabled my CoC and my ssh key
<pitti> hi tkamppeter 
<tkamppeter> pitti, the hplip package dis not make it into Launchpad/archives.
<pitti> weird
<pitti> tkamppeter: did you get a mail about it?
<pitti> tkamppeter: I uploaded it again; let me know what happens
<ogra-classmate> pitti: are you aware of any jadetex breakage atm? i seem not to be able to use my puilder, after setting up 100 tex language packages it fails on the jadetex postinst
<pitti> ogra-classmate: no, I'm not
<ogra-classmate> hmm, weird
<ogra-classmate> whats going on with these tex language packs ? do we really need them 
<ogra-classmate> (i havent seen them before gutsy)
<pitti> ogra-classmate: hm, its tetex|texlive dependencies should really be reversed, or tetex be dropped altogether
<persia> ogra-classmate: I'm seeing the same thing.  I think it's because I had tetex-extras installed (still resolving).
<pitti> ogra-classmate: the transitional tetex-extra package pulls in the entire texlive world, which is absolutely unnecessary as build-deps/depends
<ogra-classmate> persia: well, its a pbuilder, i dont install stuff in there
<ogra-classmate> yeah
<pitti> ogra: Depends: ... tetex-extra | texlive-fonts-recommended
<ogra-classmate> well, its not a g-p-m dep i think
<pitti> ideally no package would have a prefered dependency on tetex any more
<ogra-classmate> it hasnt
<pitti> jadetex has
<ogra-classmate> just checked
<ogra-classmate> there is no tex at all in gnome-power-managers build deps
<ogra-classmate> ah, wait
<ogra-classmate> docbook-utils
<pitti> ogra-classmate: docbook-utils or gnome-doc-utls perhaps?
<pitti> right
<ogra-classmate> gah
<pitti> ogra-classmate: in Debian it's fixed; so someone should merge jadetex
<ogra-classmate> well, apparently nobody noticed it(which is very weird, i saw it before i started classmate hacking on monday and just thought my pbuilder was outdated and didnt bother)
<ogra-classmate> seb128 didnt see it in his pbuilder 
<pitti> BenC: ugh, I just looked at /proc/kcore out of interest
<pitti> -r-------- 1 root root 256T 2007-05-28 16:21 /proc/kcore
<pitti> 256 TB??
<Mithrandir> mine's 2GB here
<BenC> kcore is virtual
<kylem> pitti, amd64?
<mjg59> pitti: That's your entire address space
<BenC> hmm, mines same size as physical mem too
<mjg59> Oh, hmm.
<mjg59> Yeah, mine's physical rather than virtual
<pitti> kylem: yep
<mjg59> But 40 bits sounds right for amd64 physical address space right now
<kylem> 64bit arch with a huge discontiguous space.
<kylem> what's the memory map look like?
<kylem> e820-map or whatever they call it?
<pitti> ls: /proc/*map*: No such file or directory
<kylem> iz in dmesg.
<kylem> right at the top.
<pitti> Mithrandir: yep, on my i386 server (2.6.20, too) it is 897 MB, which is the physical memory minus vmlinux size (or so)
<Mithrandir> you don't have 1GB on the box?
<pitti> Mithrandir: I actually do have a gig
<pitti> kylem: http://paste.stgraber.org/1187
<pitti> BenC: so I guess we really do need some mmap() magic on this rather than just copying it entirely to a .crash report
<mjg59> pitti: ...
<Mithrandir> pitti: use a kernel with HIGHMEM enabled and you'll be able to use another 100-odd MB.
<mjg59> pitti: I think so :)
<pitti> Mithrandir: I'll try that, thanks
<BenC> pitti: For you test maybe, but for real vmcore, it wont look like that, it you'll be using the makedump command that will be in kexec-tools
<pitti> BenC: ah, great; I'll use that in the test as well then
<BenC> pitti: Right, the makedump command will pull the bits for kcore that it needs, so you can use that for testing
<tkamppeter> pitti, you answered me that you uploaded it (on Friday or so), but it never arrived.
<sbalneav> cjwatson: Thanks for the hint.  Got it going over the weekend with openpty() and login_tty().
<pitti> tkamppeter: it worked this time
<ogra-classmate> sbalneav: ???
<ogra-classmate> REALLY ?
<sbalneav> Yep.
* ogra-classmate humps sbalneav's leg
<ogra-classmate> whoops sorry :)
<sbalneav> lol
<maswan> kylem: well, let me know when you find it so we can test it tomorrow then. :)
<kylem> maswan, which email would you like?
<CarlFK> what package should I report a bug against that is a problem wiht : alt install's proxy setting and apt-cacher
<Arby> are there any kernel people around?
<Arby> how do I go about triaging bug 117314?
<ubotu> Launchpad bug 117314 in linux-source-2.6.20 "latest kernel(2.6.20-16.28) update gives boot problems" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117314
<siretart> cprov: pong
<cprov> siretart: hey, sorry for the "ping-on-holiday"
<cprov> siretart: it's not anything urgent. Anyway pvt.
<tkamppeter> It seems that something is not consistent on the build server. See https://launchpad.net/ubuntu/+source/hplip/1.7.3-0ubuntu2
<Mithrandir> tkamppeter: no, it has nothing to do with the buildds.
<Mithrandir> libsnmp9-dev, which you build-depend on (directly or indirectly) isn't working atm.
<tkamppeter> Do I have to replace it by something else for Gutsy or do I simply have to wait until the libsnmp9 maintainer fixes it.
<tkamppeter> Mithrandir, what about the libsnmp9-dev issue?
<maswan> kylem: this is workstuff, so maswan@hpc2n.umu.se would be great. :)
<kylem> ok.
<jovan> is there a daily build iso or whatever of gutsy?
<Mithrandir> not yet
<jovan> how can i test it otherwise?
<Mithrandir> install 7.04 and upgrade
<jovan> hhm
<jovan> ok
<CarlFK> should I bother reporting bugs in the gutsy installer? (it tries to mount proc before /proc is created)
#ubuntu-devel 2007-05-29
<silvertip257> I'm trying to customize a LiveCD, but I'm having trouble with the documentation I found
<desrt> so
<desrt> you can buy a laptop running ubuntu from dell for $100 cheaper than the model that comes with windows vista
<desrt> (the base config for ubuntu is 512MB of ram whereas vista requires 1GB... but even if you upgrade the ubuntu machine to 1GB it's still $50 cheaper than windows)
<Fujitsu> desrt: If you're in the US.
<desrt> well
<desrt> i wouldn't actually buy a dell laptop anyway
<desrt> but it's really nice to see that they're actually taking this seriously this time around
<jmg> guys i notice today dist-upgrading to gutsy breaks under vmware
<jmg> initramfs cant find the disk
<jmg> does anyone have a downloadable vmdk of gutsy?
<jmg> i neeeeeeed to test a bug
<persia> jmg: Download the feisty vmdk, and dist-upgrade.
<jmg> persia: i tried that, it breaks 
* jmg gives up
<Hobbsee> morning all
* desrt wonders where Keybuk is these past few days
<pitti> Good morning
<LongPointyStick> morning pitti 
<pitti> Hey Hobbsss... Stick
<LongPointyStick> heh
<LongPointyStick> pitti: did you have a good holiday?
<pitti> LongPointyStick: yes, reasonably; lots of flat cleaning and general household things that were long overdue :)
<LongPointyStick> hehe
* Mithrandir sighs at the technical board's email address being just about impossible to find.
<LongPointyStick> Mithrandir: have you found it yet?  i should have it here somewhere
<LongPointyStick> i assume its' technical-board@l.u.c anyway
<Mithrandir> yes, I've found it now
<LongPointyStick> cool
<pitti> hi Keybuk 
<Keybuk> morning pitti *hugs*
<Mithrandir> good morning, Scott
* Keybuk hugs Mithrandir too
<Mithrandir> yay hugs
<hunger> I reported a #117493 today on cryptsetup not working properly with udev anymore (gutsy). Shall I move that to udev instead?
<Keybuk> hunger: unlikely to be a udev bug
<Keybuk> it could be a devmapper problem
<hunger> keybuk, so I'll leave it with cryptsetup.
<Keybuk> failed to rendezvous with udev?  that sounds like you have a strange mix of packages
<Keybuk> the gutsy devmapper doesn't have any code like that
<hunger> Keybuk: That is a message by the cryptsetup executable afaikt.
<Keybuk> it used to be a message from libdevmapper?
<hunger> Keybuk: It seems to wait for /dev/mapper/temporary-something-PID.
<hunger> Keybuk: possible. I just straced cryptsetup.
<Keybuk> can you attach the strace
<hunger> keybuk: I'll try...
<Keybuk> keescook: ping
<hunger> Keybuk: I can not reboot right now (takes about 45min to start up due to cryptsetup timeouts), so I'll need to find some free space to put a crypted partition on:-)
<Fujitsu> hunger: Did some upgrade break that?
<hunger> Fujitsu: It worked fine till tuesday.
<hunger> Keybuk: Can't reproduce since cryptsetup luksFormat /dev/something fails without giving a reason.
<siretart> Keybuk: are you aware that root on lvm is currently broken in gutsy? a small 'lvm vgchange -ay ; logout' makes the system boot again
<Keybuk> right, but do you have the strace?
<Keybuk> if so, is ioctl() returning -EINVAL?
<Keybuk> siretart: no
<siretart> I'll fetch the lp bugno
* Fujitsu is glad he hasn't upgraded recently.
<siretart> bug #87745
<ubotu> Launchpad bug 87745 in lvm2 "Root fs on LVM fails to boot" [High,Confirmed]  https://launchpad.net/bugs/87745
<Keybuk> siretart: mdadm hasn't been merged yet
<hunger> Keybuk: strace of cryptsetup luksFormat contains only "write" statements after the read for "yes" to get this started.
<siretart> Keybuk: this confuses me now. my md devices come up properly, just the lvm devices need a kick. how is the mdadm merge related here?
<ompaul> hunger, attache it to lp 
<Keybuk> siretart: your lvm devices are built on your md devices
<crimsun> as a possibly interesting datum, I've got ext3 / on LVM in gutsy, and it seems to boot fine with no manual intervention (under 2.6.22-5-generic).
<Fujitsu> crimsun: That's what I thought.
<Fujitsu> I also use LUKS, and it works fine.
<hunger> crimsun: I am still on 2.6.20-15-generic. Maybe that is part of the problem.
<siretart> Fujitsu: root on luks?
<Fujitsu> siretart: Not root, unfortunately.
<hunger> keybuk: strace is on bug #117502 (about luksFormat failing).
<ubotu> Launchpad bug 117502 in cryptsetup "[gutsy]  cryptsetup luksFormat fails." [Undecided,Unconfirmed]  https://launchpad.net/bugs/117502
<Fujitsu> I never could get that working well, though I'll try again in a few weeks when school holidays occur.
<Keybuk> hunger: how odd, doesn't look like it's doing anything, does it?
<hunger> Keybuk: Yes, that is what I told you before:-)
<hunger> Keybuk: Same thing happens when I give an invalid device...
<Keybuk> almost certainly a cryptsetup bug then
<hunger> Keybuk: I tried to use the /dev/dm-XY directly, but that did not help.
<dholbach> hello
<shawarma> Goodmorning, dholbach.
<dholbach> heya shawarma
<pitti> hi shawarma 
<shawarma> hi, pitti
<highvoltage> morning dholbach 
<dholbach> heya highvoltage
<siretart> did anyone else than me notice strange linewraps in po files of debconf translations?
<siretart> any idea why .po files in ubuntu packages tend to be linewrapped, while the debian ones don't? shall we keep the ubuntu ones, or take the debian ones?
<Keybuk> am I the only person who thinks that reCAPTCHA is a great way of getting users of your system to help you bypass other CAPTCHAs? :p
<siretart> I mean for packages in main
<Keybuk> siretart: msgmerge damage, usually
<pitti> siretart: don't worry for .po files in main; we have Rosetta for that
<pitti> siretart: IOW, there should not be any Ubuntu delta for .po files in Ubuntu main
<siretart> pitti: so just revert to the debian .po files to minimize the diff. okayt
<Riddell> pitti: could you look at bug 73384 sometime for SRU?
<ubotu> Launchpad bug 73384 in kubuntu-docs "Localized Kubuntu documents missing" [High,Fix committed]  https://launchpad.net/bugs/73384
<pitti> Riddell: hm, let's just hope that there will never be a .1 CD image for edgy and feisty
<pitti> Riddell: diffs look ok, but I'm not sure whether you'd want to inflict this huge download to Kubuntu users
<pitti> Riddell: right before Feisty release I changed ubuntu-docs to downsize the package a bit, btw (bzip2 compression and removing all translations with < 30% coverage)
<pitti> well, s/a bit/9 MB -> 2 MB/
<siretart> Keybuk: FYI, I've just prepared an mdadm merge, which I just uploaded to upload.dogfood.ubuntu.com's test ppa. I cannot easily build nor test it atm, since a) lvm snapshots are broken now, and b) I'm not at home atm
<siretart> in case you're interested, I can publish my bzr branch for that
* StevenK raises an eyebrow. upload.dogfood.ubuntu.com ...
<siretart> StevenK: yes, cprov asked my to stress test it. :) 
<StevenK> Heh
<sladen> ah, the wonders of Euro-time
<Keybuk> siretart: it needs a patch applied as well to work
<Keybuk> I already have a finished merge
<siretart> oh. ok
<Keybuk> I'm waiting until we've understood and fixed the issues with pure devmapper, and with LVM, before complicating the matter by throwing in mdadm
<Keybuk> one step at a time, etc.
* StevenK sighs. I need to stop reading debian-project.
<pitti> Mithrandir: can you please give-back gimp?
<Mithrandir> pitti: given-back
<pitti> Mithrandir: merci
<Mithrandir> bitte sehr
<geser> does anybody know why all merges on MoM are in red?
<Keybuk> how odd
<Keybuk> Priority missing from the source?
<pitti> hardly, it changed over the weekend for merges that haven't been touched since then
<Keybuk> hmm, Priority is missing from Sources for everything ?
<Keybuk> today is Tuesday, no?
<siretart> Keybuk: yep
<Keybuk> LP roll-out last night, by any chance?
<Keybuk> yup
<Keybuk> Priority field has been lost from Sources.gz on LP
<Fujitsu> They've all been red for at least two or three days.
<Keybuk> dunno when the last roll-out was
<elmo> err
<Hobbsee> boo
<Fujitsu> xyy
<siretart> Keybuk: do you happen to develop devmapper in a bzr branch?
<Keybuk> siretart: no
<Keybuk> I haven't yet found a workflow of bzr-branch-for-package that I'm happy with
<siretart> I personally like this mode: http://wiki.tauware.de/misc:vcs-packaging#importing_upstream_releases_only
<Keybuk> yeah, that's a huge amount of work for no benefit though, no?
<siretart> the benefit is that I can use 'bzr merge' for merging new upstream releases
<seb128> siretart: you can also copy the debian directory to the new source
<Keybuk> siretart: how is 'bzr merge' different to just applying the previous diff.gz to the new upstream release?
<Keybuk> in both cases, some stuff applies, and some stuff rejects and needs manual fixing
<pitti> siretart: I guess that only pays off if you manage patches directly rather than in debian/patches?
<Keybuk> I fully agree with "*REPLACE* the source packages with a bzr archive"
<siretart> pitti: yes, patch systems are really annoying for this. I'm currently looking for a way how to convert dpatches to inline and vice versa for that
<Keybuk> but I don't agree that staging source packages through a bzr archive is useful
<Keybuk> since the source package archive also has all of the properties of an RCS
<seb128> having the source stored to bzr is extra work
<siretart> seb128: this doesn't get me anything for merging new upstream versions when I have done changes to the upstream source
<seb128> you have to keep them in sync
<pitti> I still find it useful for several people working on a package (like hal), or merging with Debian's svn
<pitti> but those are limited cases
<seb128> siretart: you have to merge patches which don't apply by hand anyway
<siretart> Keybuk: I'm more confident if I can track the changes while resolving conflicts
<Keybuk> yeah, it does make some sense if you have a team working on each release
<seb128> you can as well use dpatch-edit
<Keybuk> or upstream/Debian use an RCS as well
<Keybuk> siretart: emacs provides me that workflow
<Keybuk> but for a drive-by patching affair like devmapper, it's minimal tweak changes, upload, round of testing, you or someone else tweaks again, upload, round of testing
<siretart> Keybuk: It's hard for me to review your changes. I surely want to understand and learn the devmapper/mdadm/lvm chaos, and I wanted so see what steps you have done in the past
<Keybuk> why is it hard?
<Keybuk> you can look at the debdiffs, no?
<siretart> I'm currently downloading all past devmapper uploads
<siretart> a ready bzr branch and bzrk would have helped me here
<seb128> that's lot of extra work for little win though
<Keybuk> http://patches.ubuntu.com/by-release/ubuntu/d/devmapper/
<siretart> oh. I didn't know that url. that's indeed helpful.
<Keybuk> actually
<siretart> thanks
<Keybuk> http://patches.ubuntu.com/by-release/atomic/ubuntu/d/devmapper/
<Keybuk> even more helpful
<Keybuk> since if you look at the 1ubuntu4 patch, it's only the changes made from 1ubuntu3 -> 1ubuntu4
<shawarma> Wow...
<shawarma> that sure beats the crap out of extracting the old versions from launchpad and debdiff'ing them.
* shawarma feels really silly now
<siretart> too bad that I missed the announcment of the by-release directory :/
<Keybuk> *cough* err, it's one of Keybuk's secret little toys that he's not got around to documenting
<Keybuk> just like the e-mail interface that lets you subscribe to uploads per-package/per-distro
<Keybuk> e.g. subscribe to all Debian changes to a particular package
<shawarma> Sounds shiny!
<siretart> I'm looking forward to see that e-mail interface advertised :)
<Keybuk> involves my CFT
<siretart> CFT?
<thom> copious free time
<Hobbsee> now that's cool
<Mithrandir> seb128: what do you think about https://lists.ubuntu.com/archives/ubuntu-mobile/2007-May/000182.html ?
<Lure> Mithrandir: can you give-back kdegraphics to pick up new poppler (and make kubuntu-desktop installable again)?
<Mithrandir> Lure: no, it's not FTBFS
<pitti> Lure: that requires a no-change upload
<Lure> pitti: ok, did not know that. will talk with Riddell then
<Lure> thanks
<seb128> Mithrandir: I'm not sure of why it's useful. What do they change to the fileselector? the interface?
<Mithrandir> seb128: they reimplement it, since the default one isn't too suited on a small screen
<seb128> Mithrandir: patch looks fine, we can apply it only to the new arch anyway, no?
<Mithrandir> seb128: we could, but I'd like people to be able to easily develop hildon-based apps natively on their desktop.
<Mithrandir> so if you don't mind too much, I'd like us to apply it on all arches.
<Mithrandir> it "only" exports some private headers into "semi-public", which means no ABI/API guarantees
<seb128> I don't like much changing the public API over upstream but since it's prefixed correctly hildon_ that's ok
<seb128> Mithrandir: well, it adds hildon_gtk_file_chooser_install_properties to the API no?
<Mithrandir> it should go away eventually when we get gvfs and upstream is comfortable exporting the API
<seb128> which means not this cycle
<seb128> patch is fine with me, I'll try building GTK+ with it now
<Mithrandir> seb128: true, it adds that function
<Mithrandir> sorry I didn't see it before
<Mithrandir> and it's guarded with defines so you have to tell the system "I know this might/will break".
<seb128> right
<carlos> seb128: Hi, is there any special reason that justifies libgtop2 removal from Gutsy?
<carlos> seb128: we detected it while testing Gutsy translation opening and Danilo told me it's still a GNOME 2.19 dependency
<mrsn0> ot: http://www.flickr.com/photos/thevoyagers/518750492/ google in 20 years ;] 
* Hobbsee pokes pitti 
<pitti> Hobbsee: eek
<Hobbsee> pitti: were you going to look into https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/117388 and https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/114186?  I believe you did the last poppler upload
<ubotu> Launchpad bug 117388 in poppler "missing header file in libpoppler-qt-dev" [Undecided,Unconfirmed]  
<pitti> Hobbsee: can do, a bit later
<iwj> Ah, that's better.
* mpt scratches his head at bug 117256
<ubotu> Launchpad bug 117256 in Ubuntu "Thats What She Said!" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117256
<Hobbsee> pitti: thanks.  then i can fix koffice and such :)
<iwj> Retrieving message nnn (of 357) from ....    oh dear.  And that's not including what's still queued up at my MX.
<Hobbsee> iwj: introduce a data loss bug.  problem solved.
<seb128> carlos: it has been renamed "libgtop"
<carlos> seb128: oh, cool!
* carlos moves old translations to the new package
<seb128> carlos: can translation be migrated?
<seb128> cool
<seb128> carlos: do you want to be pinged when a package is renamed? control-center has been renamed gnome-control-center
<carlos> seb128: I will discover it while approving manually translations, but if you notify us, that's more easy
<doko> Riddell: fyi, http://merges.ubuntu.com/main-manual.html has some outstanding kde merges, including new upstream versions
<Riddell> doko: ack.  today it going through e-mail backlog day but I'll get to those soon
<StevenK> Riddell: If you want to throw one to me, feel free.
<Riddell> StevenK: take them all if you want :)
<StevenK> Heh
<StevenK> I dealt with kio-apt a few days ago, that was painful. :-)
<Hobbsee> not knetworkmanager though
<Hobbsee> what does one do with http://librarian.launchpad.net/7834592/buildlog_ubuntu-gutsy-i386.freemind_0.7.1-6_FAILEDTOBUILD.txt.gz ?  It's failing as j2re1.4 and j2sdk1.4 are build-deps, and the licence file isnt being accepted on the buildds.
<Mithrandir> Hobbsee: it should have been preseeded on the buildds.
<Mithrandir> I'll ask Adam to fix it.
<Hobbsee> okay, thanks
<dholbach> shawarma: thanks for getting in touch with charlie
<shawarma> dholbach: No problem. I was a bit afraid to open the tarball I got, but it's looking really good, actually.
<dholbach> nice :)
<shawarma> the only major problem was copyright stuff that needs to be settled. The technical side of things were 92% done. :)
<dholbach> rock and roll - maybe Charlie can help with documenting that
<shawarma> Definitely.
<mruiz> hi, anyone know why debootstrap is broken in Gusty?
<pitti> mruiz: you mean debootstrapping gutsy doesn't work, or debootstrap itself is broken?
<persia> pitti: debootstrapping feisty in gutsy doesn't work today.
<mruiz> pitti: I was creating my gusty environment to process a merge, but I had this error: W: Failure trying to run: chroot /var/cache/pbuilder/build/16442/. mount -t proc proc /proc
<mruiz> pbuilder: debootstrap failed
<Keybuk> I actually quite like LVM
<Keybuk> I must be unwell
<StevenK> Bwahaha
<kylem> Keybuk, heh, i like not having a gazillion partitions on disk...
<Keybuk> ZFS FTW!
* StevenK twitches.
<maswan> Yes, now if someone could just make a zfs for everyone without solaris love. ;)
<kylem> Keybuk, rock on!
<StevenK> Hopefully, ZFS doesn't need the pox of Sun disklabels.
<Keybuk> we could call it the Filesystem That Works
<kylem> StevenK, heh, it doesn't care about partitions
<kylem> StevenK, you have to feed it whole disks.
<StevenK> Ahh
<Keybuk> then we could "mount -t ftw ..." :p
<maswan> kylem: strictly speaking, I think you can feed it anything, it just prefers whole, single, disks
<thom> aye
<kylem> maswan, ah, i've only used disks.
<StevenK> Keybuk: And then we get bug reports saying "File system name tells lies!"
<maswan> StevenK: Easy to fix, just add a alias for Filesystem That Lies. :)
<Hobbsee> Keybuk: i thought that was reiser?  :P
<Hobbsee> racarr will tell you!
<ion_> hobbsee: Haha
<Fujitsu> Hahah
<kylem> Hobbsee, aw, don't be mean.
<Keybuk> the evmsishness of ZFS is really appealing
<Hobbsee> kylem: but...but...
<kylem> Keybuk, indeed.
<Keybuk> "here are my disks; now give me a 4GB"
<kylem> Keybuk, the temptation to NIH something better is strong.
* desrt sees a keybuk
<Keybuk> it's like evms, but without the soul-crushing pain
<ion_> Does its license prevent it from being used in Linux?
<kylem> Keybuk, it's a pity you took off to the airport early, we met Jeff Bonwick that friday
<Keybuk> yeah :-(
<Fujitsu> ion_: CDDL is GPL-incompatible, unfortunately.
<Keybuk> bit of luck I did too, by the time I'd got checked in and through customs, I didn't have long
<kylem> yow.
<Mithrandir> Fujitsu: but there's a gpl-ed port, I thought?
<kylem> we had a good 2 hour wait at SFO
<Keybuk> taxi took an age to arrive
<Fujitsu> There's a FUSE port.
<kylem> Mithrandir, no, it's FUSE based.
<highvoltage> Sun said they mihgt license the whole of opensolaris as gpl in some point in the future. I hope that includes zfs.
<Mithrandir> kylem: oh, ok.
<StevenK> Speaking of evms, is it going to get it's comeuppance and get demoted to universe?
<mjg59> There's a very basic GPLed read-only implementation for grub
<maswan> kylem: Oh, you've met him too, he's quite interesting to talk to. Him and Bill Moore was at a storage workshop I went to a couple of months ago
<mjg59> So someone /could/ go from there
<Keybuk> StevenK: upstream refuse to support Linux 2.6 ... morgue could be a destination <g>
<kylem> maswan, yeah, bill moore was there too.
<StevenK> Keybuk: Oh, even better.
<StevenK> Actually, wait a sec?
<Fujitsu> What does EVMS have over LVM?
<StevenK> evms has an upstream? I thought it sprang from hell, fully formed?!
<desrt> Fujitsu; enterprise support
<Mithrandir> Keybuk: eh?  It works just fine with 2.6.
<thom> Keybuk: eh? 
<Keybuk> Mithrandir: tried it on gutsy?
<desrt> Fujitsu; lvm doesn't work on enterprises :)
<ion_> fujitsu: From what ive heard you tell it e.g. please resize this to 10GiB and it does all the steps involved correctly, whereas with poking plain filesystems, LVM and md, you might have to do multiple steps and you might be able to break something along the way.
<Mithrandir> Keybuk: my machines still boot.
<maswan> kylem: oh, btw, did you send anything yesterday?
<Keybuk> Mithrandir: do you have any non-evms block devices?
<kylem> maswan, ah, shit, i forgot.
<kylem> maswan, 1sec.
<kylem> maswan, it's already uploaded, just need to untar & mv
<Mithrandir> Keybuk: yes.
<Keybuk> thom: evms attempts to make a devmapper device for every block device on the system, whether it intends to do anything with them or not
<thom> ugh
<Keybuk> thom: this fails if any of them are in use, e.g. mounted
<thom> aye
<Keybuk> upstream's approach to this is to patch out the kernel features that cause this
<StevenK> Yowch!
<Lure> StevenK: since you have done exiv2 sync, do you have any plans with digikam (note: 0.9.2 beta2 was just released, but not yet in debian)
<StevenK> Lure: I didn't, I can.
<Mithrandir> Keybuk: or rather, to tell you to not run evms and non-evms volumes on the same physical device.
<Lure> StevenK: since allee (debian packager) is on vacation, we could to Beta2-0-ubuntu1 and then he can merge back in debian after he is back
<StevenK> Lure: We could, yes.
<Lure> StevenK: ok, I can prepare package, but will need core-dev for upload ;-)
<StevenK> Lure: You can file a bug and subscribe u-m-s.
<StevenK> Alternatively, you can pick on me, if you wish.
<Hobbsee> Lure: why not get a DD to upload it to debian, if allee's fine with that, then sync it?
<Keybuk> Mithrandir: it still fails because evms still tries to make the devices
<StevenK> There's that, too.
<Hobbsee> or can you not abuse NMU like that?
<Keybuk> it's default configuration is to assume all volumes are for evms
<StevenK> Hobbsee: You can, it's just frowned upon.
<Hobbsee> StevenK: even if the maintainer says it's fine?  :P
<Mithrandir> Keybuk: don't tell my machines, since they work fine. :-P
<siretart> IIRC, it was strongly encouraged by evms upstream to not mix evms and non-evms managed devices on the same disk
<Lure> Hobbsee: yep, we can try fabo or somebody to sponsor debian upload
* Hobbsee points Lure to StevenK 
<StevenK> Ssshh!
<Hobbsee> oh.  wait.  i didnt say that.
<Lure> Hobbsee: oh, did not know he is DD too ;-)
<Hobbsee> sorry steve :P
<StevenK> digikam is maintained by "Debian KDE Extras Team" - this implies more than one person.
<StevenK> Hobbsee: Hmph.
<Hobbsee> Lure: might push pusling/ana to upload it, then.
<Hobbsee> or their sponsors.  although i thougth ana was a DD
<mdz> Keybuk: should we think about having evms be removed by the upgrader if it isn't in use?
<Keybuk> mdz: we've never been able to define "in use" :-/
<Hobbsee> Lure: #debian-qt-kde on oftc - just dont get them onto ubuntu policies.
<Hobbsee> and they wont bite
<Hobbsee> much
<mdz> Keybuk: the existence of any evms volumes other than compatibility volumes
<Keybuk> mdz: if there's a way to detect that, it would be a great idea
<Keybuk> since this appears to bite the people who have evms installed because we once installed it by default
<Keybuk> and the people who actually use it, seem completely happy and unaffected
<Mithrandir> kinda a corner case, but that will break systems where people only have evms on hotplugged drives.
<mdz> if they don't have any /dev/evms mount points in fstab, i think we can probably get away with removing it on upgrade
<mdz> (it does still use /dev/evms, right?)
<Mithrandir> mdz: no, you can't do that.  I use cryptsetup on evms, for instance.
<Mithrandir> evand: do you know what the current state of the installer is?  Does it make sense to start building daily cds again?
<mdz> Mithrandir: do you even use the release upgrader? :-P
<Mithrandir> mdz: no, it refused to upgrade to gutsy two weeks ago.
<Mithrandir> so yes, I tried, but it failed since it didn't know about gutsy yet.
<evand> Mithrandir: Negative, I do not know the answer to that, unfortunately.
<Mithrandir> evand: ok.
<evand> I'll be happy to test it in a short while though, if you have not already.
<Mithrandir> evand: I haven't, no.  Usually, we've hold off dailies until they make sense, but I haven't spoken with colin in a little while so I'm not sure about the status.
<Hobbsee> Mithrandir: is there any point anyway until the desktop packages are actually installable?
<Mithrandir> Hobbsee: we build server CDs, and it helps highlight the problems.
<Hobbsee> ahhhh
<Keybuk> the evms failure mode right now seems to be 1) install evms 2) reboot 3) computer fails to mount root filesystem because it's "in use"
<Keybuk> or 1) being "have evms already installed"
<Hobbsee> oh damn that poppler bug.
<Mithrandir> Keybuk: we could switch evms into only claiming the devices it actually uses?
<Mithrandir> or is that hard?
<Keybuk> Mithrandir: that would be the ideal solution, however no idea how hard that is
* Hobbsee waits for pitti to fix it.
<pitti> Hobbsee: yeah, yeah, I'm still Mithrandir's slave ATM; but you are high on the list now :)
<Hobbsee> pitti: hooray!
<Hobbsee> pitti: just dont make me get out the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!!!  :P
<pitti> Hobbsee: "Oh no, not again!"
<Hobbsee> pitti: (all of the kde packages are failing due to this, it seems, so i'm kinda interested in it)
<Hobbsee> hehe
<pitti> Hobbsee: ready with NEW; so, it's only those two bugs?
<Hobbsee> pitti: i think so.  i havent seen more.  check for poppler bugs in the package though, i guess
<Hobbsee> pitti: maybe https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/74366 too.  Hobbseeparser is dying on that one
<ubotu> Launchpad bug 74366 in poppler "Missing dependency" [Undecided,Unconfirmed]  
<pitti> Hobbsee: I just dup'ed that to #114186
<Hobbsee> pitti: even better.  i thought ti might be
<tepsipakki> doko: do you wan't to look at the syslinux debdiff before I upload it?
<tepsipakki> s/'//
<doko> tepsipakki: did you test it?
<tepsipakki> yes
<tepsipakki> colins test suite worked fine
<tepsipakki> with the new gfxboot-patch from suse
<doko> then go ahead and upload
<tepsipakki> ok, thanks
<pitti> tepsipakki: out of interest, did it still need fixes for -fno-stack-protector?
<tepsipakki> pitti: upstream has those
<pitti> tepsipakki: sweet
<tepsipakki> where needed
<tepsipakki> so I dropped the patch
<tepsipakki> ok, uploaded..
* pitti hugs tepsipakki for relieving him of a TIL package he doesn't understand well
* tepsipakki hugs pitti back
<StevenK> I hate the TIL rule at work.
<pitti> StevenK: well, it's still the one that makes most sense without introducing a lot of bureaucracy
<StevenK> pitti: Yeah, that's true.
<Hobbsee> pitti: were you doing binary NEW or source NEW?
<pitti> Hobbsee: both (specifically for the Mobile project, since it's not my archive day)
<Hobbsee> ah right.  no problem
<pitti> anything that's urgent for you?
<Hobbsee> pitti: there's kde-tweak, the guy's uploaded a new version on it.  so only urgent to kick another thing off revu.  poppler stuff is more important
<Hobbsee> pitti: ie, no
<StevenK> doko: Thanks for the offer, I've joined pythoneers.
<pitti> Hobbsee: poppler uploaded
<Hobbsee> pitti: yay, thankyou
<StevenK> pitti: Will/Have parts of it cleared binary NEW?
<pitti> StevenK: 'it'?
<pitti> StevenK: https://launchpad.net/ubuntu/gutsy/+queue FYI
<StevenK> Yeah, I just checked.
<StevenK> It looks like libpoppler-glib1 graces there no more.
<pitti> yep, I NEWed that on Friday
<pitti> (for everyone not yet knowing the trick, https://launchpad.net/ubuntu/gutsy/+queue?batch=500 is much nicer)
<Spads> cjwatson_: gutsy ppc is on ports now
<StevenK> Oooh. /me files that one away.
<glatzor> hello mpt, I would like to discuss the displayconfig-gtk interface with you.
<mpt> glatzor, sure
<glatzor> mpt: fine. Have you already used the current gutsy version?
<mpt> No, I'm not smart enough to run pre-beta Ubuntu versions
<mpt> :-)
<Keybuk> keescook: ping (hopeful)
<glatzor> mpt: No problem. I can make you a feisty package
<glatzor> mpt: In the meantime here are some older screenshots https://wiki.ubuntu.com/DisplayConfigGTK
<glatzor> mpt: are you familiar with bzr?
<mpt> glatzor, I use it every day :-)
<glatzor> mpt: fine. here is a different approach in the user interface design: http://glatzor.de/bzr/displayconfig-gtk/gfxbase/
<glatzor> mpt: http://glatzor.de/filesink/displayconfig-gtk_0.2+20070523ubuntu2_i386.deb
<glatzor> mpt: you have to install this package. afterwards also the bzr branch will work
<afflux_> siretart: I'm having a problem with cryptsetup in gutsy, I'm not sure wether it's a bug.
<glatzor> mpt: one of the main problems in the user interface is to represent the relation between graphics card and screens.
<mpt> glatzor, I'll be on the phone for a while and not within reach of a copy of bzr, sorry
<glatzor> mpt: hey, I could also discuss it via the ubuntu-desktop mailing list
<glatzor> we could :)
<afflux_> siretart: when using luksOpen it asks me for the password, after that it does nothing for about 3 minutes. Then it says "endezvous with udev timed out for 'temporary-cryptsetup-4684'; stat failed: No such file or directory". After that it maps the volume but this is far too long for booting.
<mpt> glatzor, that would work
<chand|> hi
<chand|> anyone using encfs on gutsy, here is a bug with openssl 0.9.8e, you can't read data  encrypt with feisty
<chand|> there is a bug in openssl 0.9.8e http://www.mail-archive.com/openssl-users@openssl.org/msg48671.html
<chand|> i don't know if i add a bug or wait for an upstream openssl update
<Keybuk> afflux_: dpkg -s libdevmapper1.02 ?
<mpt> glatzor, one thing that jumps out at me from the wiki page illustrations is that it would be much easier to see how the screens related to each other if they were visually represented
<siretart> afflux_: which version of cryptsetup do you have installed?
<mpt> i.e. a picture of the screens
<mpt> next to each other
<afflux_> siretart: 2:1.0.4+svn29-1ubuntu1
<afflux_> siretart: I just that you uploaded -1ubuntu3
<afflux_> siretart: (i'm still a bit slow with console only :))
<glatzor> mpt: we don't support many different screen relations. it is only allowed to configure one relation, that can be cloned or extended by
<siretart> afflux_: yes. please try a newer version
<glatzor> mpt: the larger problem is what happens if you have got two cards? currently it is quite hard to find which output belongs to which card
<afflux_> siretart: I guess -1ubuntu3 won't be in the archives yet, would it?
<mpt> glatzor, I mean the "Extend primary screen:" menu would be better as a picture of two screens that you can drag around
<Keybuk> siretart: did you locate the problem?
<glatzor> mpt: you would have got to the devices screen and hopefully choose different model names. but if both of them are e.g. 1280 LCDs you would have a problem
<siretart> afflux_: the source has been already published, the build's didn't start yet. and I've just uploaded -1ubuntu4 a few minutes ago
<glatzor> mpt: I think that this feature is overrated. all dialogs that implemented this do not fit on 640x480
<siretart> Keybuk: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/117459
<ubotu> Launchpad bug 117459 in cryptsetup "luksOpen takes ages" [Undecided,Fix released]  
<Keybuk> siretart: ah, heh
<Keybuk> of course, there was a SONAME bump
<glatzor> mpt: and using dump numbers as screen identifiers is also not a good way (windows=
<glatzor> )
<siretart> Keybuk: can we do something to prevent such issues in the future?
<afflux_> siretart: thank you for your help
<glatzor> mpt: the ideal solution would be to have all options on one dialog. I don't like to have three notbook pages
<Keybuk> siretart: the archive admins tend to notice such things pretty easily
<Keybuk> obviously we're still early in the gutsy release process, so the eye isn't quite so sharp
<glatzor> mpt: and furthermore you would have to provide a non drag and drop configuration option too. since I am not sure that all user would discover the fancy method.
<Keybuk> siretart: it would be nice to work out a magic udev rule for cryptsetup, so any luks block device is automatically dealt with
<glatzor> mpt: so more and more space would be required
<glatzor> mpt: wait I will make a screenshot of the different approach
<mpt> I don't know what a "dump number" is
<glatzor> mpt: 1 and 2
<mpt> oh
<glatzor> mpt: a number without any further meaning :)
<glatzor> mpt: Using the Monitor model name seems to be a better approach, but would also consume more space.
<siretart> Keybuk: indeed. 
<siretart> Keybuk: for keyfiles, we could perhaps work something out, so that the user has the possibility to place it on the harddriver or on some usbstick or something
<glatzor> mpt: If you connect a different screen, you have got to tab 3 change the model, go back to tab 1 and change the resolution and if you haven't yet configured dual head go to tab 2
<siretart> Keybuk: however for passwords entered via terminal I think we would perhaps need some external password-agent tool or something
<Keybuk> yeah we'd need that
<Keybuk> but it should be now possible to
<Keybuk> 1) make sure vol_id can detect luks partitions
<Keybuk> and thus
<siretart> ideally, that would use usplash if running
<siretart> vol_id is able to detect luks just fine
<Keybuk> 2) have a udev rule that activates them (getting a password, excluded)
<Keybuk> ok, cool
<siretart> it doesn't work with 'plain' dm-crypt devices, since they lack an meta-information header. but luks is just fine
<Keybuk> so SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="crypto_LUKS", RUN+="..." in an 85-*.rules would work
<siretart> we can perhaps modify cryptsetup to spit out some warning if the user tries to create a non-luks device or something
<glatzor> mpt: http://glatzor.de/filesink/dcg-gfxbase.png
<Keybuk> don't dm-crypt devices show up as ENV{DM_TARGET_TYPES}=="crypt" ?
<glatzor> mpt: I tired to combine the device chooser and the display mode selector on one tab
<glatzor> mpt: every graphics card would be represented by a single tab
<siretart> Keybuk: but how do you imagine this passphrase agent? It should be able to run in a) usplash, b) text/console, c) serial console (?), d) X11/Gnome/KDE session 
<glatzor> mpt: so the screen/gfxcard relation would be clear
<glatzor> mpt: if there is only one screen I can hide the left chooser
<Keybuk> siretart: I think it makes sense to combine that with the "progress output" agent, which needs to send its output to a) usplash, b) text/console, c) serial console, d) X11/Gnome/KDE session, e) text-to-speech
<Keybuk> ie. the "Starting Apache Web Server" thingy
<siretart> Keybuk: http://paste.debian.net/29174 <- example output of what vol_id says about luks
<glatzor> mpt: the dialog is resizable and the model chooser button uses ellipsis so that it does not force a wide window
<Keybuk> siretart: don't suppose you have a dm-crypt fs around?  if so, what does dmsetup export NAME say on it?
<siretart> Keybuk: my laptop is running debian/lenny atm, since feisty wasn't in too good shape for LVM/dm-crypt experiments :/
<siretart> what does NAME stand for?
<Keybuk> yeah, it wasn't great
<siretart> hda6?
<Keybuk> whatever the /dev/mapper thing is
<Keybuk> the theoretical final step for all this is that the device-mapper ioctl() to make or change a device won't actually complete until the uevent has been processed by udev and the device node created
<siretart> dmsetup export says 'Unknown command'
<siretart> do you perhaps mean 'dmsetup info'?
<Keybuk> siretart: ah, use "info" on Debian
<siretart> Keybuk: http://paste.debian.net/29175
<siretart> why is debian different here?
<siretart> upstream change?
<Keybuk> "export" is a patch from SuSE to output all of the info in a format udev can import
<Keybuk> could you try "table" instead of info, I think that's the right one
<siretart> ah, sounds useful
<Keybuk> we have a similar patch for mdadm as well, so udev can grok the array states, etc.
<shawarma> Where do core dumps end up these days?
<siretart> Keybuk: http://paste.debian.net/29176
<siretart> shawarma: in apport
<mpt> glatzor, that's got very good padding and capitalization and everything, but I don't understand how to use it
<shawarma> siretart: er... Not on the filesystem somewhere?
<Keybuk> siretart: ok, cool
<Keybuk> so we can match those with ENV{DM_TARGET_TYPES}=="*crypt*"
<shawarma> There's not way to get a regular core dump?
<siretart> shawarma: doesn't ulimit -c unlimited help?
* desrt yawns
<shawarma> siretart: Well, it said "core dumped", but I couldn't find it anywhere. I expected it in my $CWD..
<Mithrandir> shawarma: you need to echo "core" | sudo tee /proc/sys/kernel/core_pattern
<mpt> glatzor, but that's not necessarily worse than the previous design :-) Anyway, I'll have a more thorough look in the morning
<shawarma> Mithrandir: even though 'cat /proc/sys/kernel/core_pattern' already says core?
<Mithrandir> shawarma: hm, then you should indeed have it in cwd.
<shawarma> Mithrandir: Ah, there we go.
<shawarma> Mithrandir: Odd. 
<shawarma> Mithrandir: I did /etc/init.d/apport stop, but I triggered the core dump since then and it didn't work then.
<shawarma> Mithrandir: But now it works. Yay!
<siretart> Keybuk: tell me more about the "progress output" agent. is there a spec for it? who is working on that/
<siretart> ?
<Keybuk> siretart: no spec, nobody working on it
<Keybuk> it's something we need though, obviously
<afflux_> siretart: building of -1ubuntu3 on my own solved the issue. thank you!
<siretart> Keybuk: well, anyway. if we want to integrate crypysetup with udev, we need to have some kind of user intervention. which is strange here, because cryptsetup generally expects to be run from the user context. with udev, it runs from a 'system' context
<siretart> Keybuk: and getting from udev back in some user context is, well. interesting at least
<siretart> afflux_: thanks for confirming
<siretart> afflux_: does luksformat work for you?
<Keybuk> I was looking at the initramfs-tools script you have, you see
<Keybuk> which is, err, massively complex and overweight
<Keybuk> and probably causes all sorts of problems
<Keybuk> since it tries to run lvm, evms, etc.
<siretart> afflux_: (it doesn't for me, I cannot open created devices)
<siretart> yes, it sucks for obvious reasons
<siretart> Keybuk: may udev scripts block and ask for passwords?
<siretart> in that case we could get along with integrating cryptsetup with udev in initramfs only
<siretart> this way we would leave out the X11 part, and only deal with console and usplash (which would cover the serial console use case as well)
<siretart> for gnome, we have hal and gnome-vfs
<Keybuk> they could, but after 3m wait, udev would assume they'd hung and kill them
<siretart> that's a sane assumption
<Keybuk> initramfs only would break for /home under cryptsetup, no?
<afflux_> there is a problem for me too in the initramfs script. A minor one since I know how to fix it. I have my cryptroot partition on /dev/sda10, this is a s-ata drive. It seems to be enabled later than expected from the script, so it would be good to have some sort of loop that checks if the device gets listet in the next X seconds. Can provide a patch in about 10 minutes.
<siretart> if the user doesn't manage to enter his password in less than 3 minutes, we can perhaps safely abort
<siretart> Keybuk: why would it break?
<Keybuk> siretart: those aren't mounted in initramfs
<Keybuk> you'd need the same setup for pre-X boot 
<siretart> good point
<siretart> Keybuk: how would udev know which devices to open? - assuming we have 3: /, swap and /home, which one should get opened in initramfs?
<Keybuk> it actually does them all
<siretart> afflux_: Keybuk and I are basically discussing a solution for that problem. There are already at least 2 open bugs with proposed patches for that
<Keybuk> restricted on which drivers are available
<siretart> which would break semantics, wouldn't it?
<Keybuk> you should certainly support someone plugging in a USB key halfway through the boot sequence
<Keybuk> semantics?
<siretart> well, ATM, we only mount /, and not /home in initramfs. with cryptsetup run from udev, all devices would get opened in initramfs, no?
<afflux_> siretart: oh, didn't see the connection. have no idea about udev. ;)
<Keybuk> siretart: what's wrong with that?
<siretart> Keybuk: well, think about cases where you have keys on your /root partition, which is crypted by a keyfile on usb. udev won't be able to mount /home, and the user can't provide a password, since he has only a keyfile, which is on /
<siretart> so udev would bug the user unnecessarily
<Keybuk> the keyfile would fail to open, and cryptsetup would terminate unsuccessfully, surely?
<Keybuk> I'm trying to eliminate all "Point Of No Return" from the boot sequence
<siretart> from udev, you don't see if a device needs a password or a keyfile
<Keybuk> "you must have your USB key plugged in by this point or it won't get mounted" is bad
<siretart> it might work with both
<siretart> or with just one of the two
<siretart> Keybuk: I rather think it wouldn't be unreasonable to mandate using a /etc/crypttab, which explains the parameters for unlocking /
<siretart> Keybuk: and udev would then only open that device in initramfs
<siretart> Keybuk: later in the boot process, the other filesystems listed in /etc/crypttab are mounted (like /home, swap, etc)
<Keybuk> that's certainly doable
<Keybuk> of course, if / is mounted by UUID, how do you know which crypted filesystem is the one to unlock? :p
<siretart> I know from /etc/crypttab?
<siretart> udev would grep it and compare it's UUID/something to check if that's the root device
<Keybuk> that kind of extra configuration makes me feel sad
<glatzor> mpt: a tired usability engineer is perhaps a good indicator for if the dialogs work or not :)
<Keybuk> glatzor: how will that interact with xrandr ?
<glatzor> Keybuk: depending in which state XRandR will be at the Gutsy release.
<siretart> Keybuk: indeed, I don't feel to happy about it as well; however I don't see really any other sane approach to manage it
<bryce> morning
<kylem> morning bryce
<glatzor> Keybuk: The idea was to base the configuration on the traditional xorg.conf and only use xrandr to apply changes instantly
<Hobbsee> Mithrandir: or another archive admin:  please give back kdegraphics and krita
<desrt> Keybuk; going to school now
<glatzor> Keybuk: mvo started hacking on xrandr 1.2 python bindings. would be nice if he would be given more time for this :)
<glatzor> Keybuk: the problem is that there are still many cards that will not have got xrandr 1.2 support in the near future
<glatzor> Keybuk: And we have got not idea about the AMD and NVIDIA plans. Also taking the legacy cards into account.
<Keybuk> glatzor: but for those cards that do support xrandr properly, you don't really want to write them an xorg.conf "hard-coding" that layout
<glatzor> Keybuk: If we would live in a better world I would like to base it only on XRandR too.
<Keybuk> it'd be nicer to leave them conf-less, and instead restore their last layout and give them the option to change it on the fly
<glatzor> Keybuk: that is not an exclusive approach.
<siretart> can archive admins sync from any .dsc file or just from debian?
<Keybuk> siretart: see, I'd kinda like to support somebody who wanted /, /home and /usr each as encrypted LVM LVs, combined from a MD RAID-5 selection of disks, with each underlying disk encrypted as well.
<glatzor> Keybuk: but one problem is the assigned memory for the maximum resolution.
<Keybuk> siretart: the passphrases for each of these elements obtained from a USB key, the filesystem of which is encrypted with my fingerprint as the passphrase
<Keybuk> siretart: that's somewhat complex to express in crypttab? :p
<siretart> Keybuk: where is the problem with that?
<glatzor> Keybuk: X seems to be quite conservative. so you cannot access all available resolutions with xrandr
<Keybuk> siretart: it requires a lot of elements, no?
<siretart> Keybuk: the format could be "<devmappername> <blockdevice> <keytype> luks"
<siretart> where keytype is either a pathname to a keyfile, 'none' for passphrase, or other magic think you want to support
<glatzor> Keybuk: If I don't use any xorg.conf on my t60 with an intel card I am stuck to 1280x1280. which is really not enough for two desktops. 
<Keybuk> siretart: s/devmappername/UUID/ no?
<Keybuk> glatzor: have you tried the -intel driver in gutsy?
<glatzor> Keybuk: no debian unstable.
<siretart> Keybuk: you'll need a devmappername for practical reasons. cryptsetup works with the devicenames from /dev/mapper, not with uuids. but we can perhaps add the uuid as well
<glatzor> Keybuk: I tried gutsy some days ago, but xrandr didn't work
<glatzor> Keybuk: and I haven't tested it again since that time.
<glatzor> hello bryce, by the way
<bryce> heya glatzor
<glatzor> bryce: I implemented the dump and read pci table function of the guidance backend in displayconfig
<bryce> glatzor: cool
<glatzor> bryce: this is a quite nice feature, since it allows us to reproduce errors very exactly
<glatzor> bryce: have you been in contact with anyone from Intel, AMD or NVIDIA?
<glatzor> bryce: would be nice if we could get some more information for the xorg.conf options of every card
<bryce> yes to Intel; I know AMD's open source lead (but he hasn't interacted too much with ATI so far); from nvidia I've traded bug reports with a person from there but don't really know him
<glatzor> bryce: I made some patches to support the intel i810 driver (or better said my laptop) better
<bryce> agreed; however many cards simply have nvidia or whatever chipsets, but the actual hardware implementation is from other vendors
<glatzor> bryce: I now use displayconfig-gtk on a daily basis :)
<bryce> is it enough in every case to simply have the chipset's details? 
<bryce> cool, yeah I was playing with it a bit friday.  I've been setting up new test hardware and using it to check that I can manipulate the drivers and rez on them
<glatzor> bryce: For example I don't know which Intel cards require the MonitorLayout option. It is needed to get dual head working on my computer. but there seem to be other cases since this was not yet implemented in the backend. (or the backend made a bad show on Intel systems :)
<bryce> hmm
<glatzor> bryce: how was your overall experience with the proprietary drivers?
<glatzor> bryce: I don't have got any NVida/ati systems to test here.
<bryce> pretty seamless, although I didn't spend much time on them and didn't test beryl or anything nontrivial
<bryce> no prob, I've got several nvidia/ati systems.  I'm actually short on intel
<glatzor> bryce: Furthermore in my patch I made the perhaps most conservative assumption and set the MonitorLayout to internal screen and external vga.
* bryce nods
<glatzor> bryce: but I have got no idea what the impact on systems with a tv out are :/
<glatzor> bryce: Oh, I am only interested in changing the resolution and extending and cloning desktops :) beryl is out of scope for me :)
<bddebian> Heya
<glatzor> bryce: if you want, you could send my some pci table dumps :)
<glatzor> bryce: it would be nice to have a good feeling about getting nvidia systems detected correctly by displayconfig
<glatzor> feeling
<glatzor> bryce: do you plan to do a feature matrix for beryl?
<glatzor> bryce: if so, we could also add works with displayconfig
<glatzor> bryce: perhaps it would be a good idea to setup a wiki page and ask the users in a blog post and on the forums to add information about working dual head configurations there.
<glatzor> bryce: steve harms seems to be interested in getting a working x configuration tool tool. I haven't meet him yet online, but I think that he is more next to your time zone :)
<bryce> for the pci table dumps, just lspci -n ?
<glatzor> no it's a dump of the internal pci table of displayconfig
<bryce> I'll plan on playing around with displayconfig on nvidia.  I haven't seen problems on radeon so far
<bryce> ah, how do I retrieve that?
<glatzor> bryce: just update the ubuntu branch of displayconfig-gtk
<glatzor> I merged it today
<bryce> I think having an area where users can post working multi-screen configs would be excellent
<bryce> ah cool, okay
<glatzor> bryce: yesterday I started working on the actual user interface again, since I am not very happy with the current approach. it has got some problems in the workflow
<glatzor> bryce: http://glatzor.de/filesink/dcg-gfxbase.png
<glatzor> this is another approach. but it seems to be a bit messed up.
<bryce> yeah
<bryce> I've been thinking about the dual/multi monitor gui layout, and one thought I've had is it feels like there should be a tab per screen
<bryce> so then adding a third or fourth monitor would involve simply creating another copy of the base panel in a new tab
<bryce> however since cards often have multiple monitor outputs, that could make things a tad more complex
<glatzor> bryce: each graphics card is represented by its own tab in this design approach
<glatzor> bryce: so you only the outputs of the corresponding card on each tab
<glatzor> but perhaps I have only to find better way for including the selector
<glatzor> the thing on the left side
<glatzor> http://glatzor.de/bzr/displayconfig-gtk/gfxbase/
<glatzor> bryce: If you want to test here would be the branch
<glatzor> just ./displayconfig-gtk --data-dir=data
<bryce> yeah I've just wondered from a usability point of view, most non-technical people won't have much clue what a "video card" is, but they'll know what a monitor screen is
<bryce> so tabs of video cards may appear to be geek to them
<glatzor> bryce: yes. you are right.
<glatzor> bryce: but most people only have got one card :)
<glatzor> bryce: and the people that use two cards for their dual screen setup would know about the used cards
<glatzor> since they perhaps had to add a second card.
<glatzor> bryce: I agreed with mpt to take this issue to the ubuntu-desktop list and discuss it there
<glatzor> bryce: but I can still point you to another problem I mentioned earlier with the workflow (as a daily user of displayconfig-gtk I got annoyed by this too :)
<glatzor> if you for example connect a new monitor to your laptop, you go to the devices tab and select the monitor model, then you go to tab 2 and set e.g. extend my primary screen.
<glatzor> mostly you will forget to also set the correct resolution on the first tab :)
<glatzor> most times
<bryce> yeah I ran into that too
<bryce> having to shift between multiple tabs to do one activity (get a monitor/card set up), is probably not great usability
<Keybuk> asac: firefox needs a "restart" option ;)
<glatzor> bryce: and this will be perhaps the most needed task
<glatzor> bryce: and the location chooser is really a must have 
<Treenaks> argh.. I shouldn't have upgraded to gutsy
<simira> :)
<simira> hmm, maybe it's time soon...
<Treenaks> simira: I miss my evince
<asac> Keybuk: for what?
<Mithrandir> Treenaks: you should have let it keep back poppler, then
<Treenaks> Mithrandir: I know, I know
<Treenaks> Mithrandir: oh well, I gues it'll be fixed before release ;)
<Treenaks> +s
<asac> Keybuk: https://addons.mozilla.org/en-US/firefox/addon/3458
<seb128> Treenaks: what arch do you use?
<Treenaks> seb128: i386
<seb128> Treenaks: what is the problem with evince on i386?
<Mithrandir> Treenaks: "not unlikely"
<Treenaks> seb128:   libpoppler1-glib: Depends: libpoppler1 (= 0.5.4-0ubuntu8) but 0.5.4-4ubuntu2 is to be installed
<asac> Keybuk: ... and there is even choice for that simple usecase ;) ... see https://addons.mozilla.org/en-US/firefox/search?q=restart&status=4
<seb128> Treenaks: I've accepted the binaries (they were to NEW due to the new evince-gtk)
<Treenaks> seb128: ah, great
<seb128> Treenaks: the rebuild should be available next run
<Treenaks> seb128: great, thanks :)
<seb128> you're welcome
<Keybuk> asac: for when I've updated an add-on, and it wants me to restart firefox to be able to use it
<Keybuk> asac: right now I kill -9 it
* Hobbsee looks forward to when kde builds again.
<Hobbsee> can someone tell me why it's 3am, and im still up?
<Keybuk> (closing it normally doesn't prompt me to restore my session <g>)
<seb128> Hobbsee: because you try to build KDE? ;)
<seb128> Hobbsee: you should try GNOME, it builds faster and could be to bed already :p
<Hobbsee> seb128: no.  i asked for a giveback on a couple of it, though.
<Hobbsee> s/it/bits/
<Hobbsee> seb128: that means i'd have to tolerate gnome.
<Hobbsee> and no one did the giveback.  darn
<Mithrandir> Hobbsee: you did?
<Mithrandir> Keybuk: you can change that
<Hobbsee> [02:05]  <Hobbsee> Mithrandir: or another archive admin:  please give back kdegraphics and krita
<Mithrandir> Keybuk: edit - preferences - main page - start page - when firefox starts: "show windows and tabs as they were when I quit"
<asac> Keybuk: ... and you are not offered the option to restart firefox after extension install/update ... sounds like its worth a bug. You do manual updates, right?
<Hobbsee> Mithrandir: ie, yes.
<Mithrandir> Hobbsee: seems I missed them, then
<Hobbsee> seems so
<Mithrandir> Hobbsee: anyway, krita isn't a source package.
<Hobbsee> Mithrandir: oh, koffice sorry
<Lure> Mithrandir: giveback kdegraphics too
<Hobbsee> Lure: see first statement
* Hobbsee is getting slightly sleepy, cant you tell?
<Mithrandir> Hobbsee: btw, you need a buildd admin, not an archive admin.
<Mithrandir> but, both given-back
<Lure> Hobbsee: I am not sleepy, but still cannot properly read your paste ;-)
<Keybuk> asac: the update turned up while I was running firefox; I clicked Find New Updates, and it said it had been updated and I needed to restart firefox, but never gave me the opportunity to do that
<Hobbsee> Mithrandir: ahh.  i thought they were the same.
<Keybuk> Mithrandir: I don't want it all the time ... since that's erm, likely to cause embarassment :p
<Hobbsee> Lure: heh.  try again :)
<Mithrandir> Keybuk: hehe, ok
<Keybuk>  * Scott is looking at porn, and closes the browser quickly when his Mother pops round.  She runs Firefox to look at something.  Scott would prefer not to be embarassed.
<Hobbsee> you let your mother access your computer?
<Mithrandir> Hobbsee: s/your computer/your account/, you mean?
<Hobbsee> either.
<kylem> Keybuk, *HAH*
<Hobbsee> but yes
<seb128> Hobbsee: "archive admin" != "buildd admin" btw, you need a buildd admin to give a build retry
<Hobbsee> when you have the only user account on your computer, these two are directly substituable.
* kylem gives Keybuk points for best usecase ever.
<Hobbsee> seb128: so Mithrandir said.  noted.
<Hobbsee> thanks.
<seb128> np ;)
<Hobbsee> seb128: requires knowing who the buildd admins are though
<seb128> Mithrandir
<Mithrandir> Hobbsee: you clearly have too few personalities if you just have your own account on the machine.
<Hobbsee> seb128: ah, so just Mithrandir?
<seb128> infinity also
<Hobbsee> Mithrandir: heh.
<Hobbsee> point
<Mithrandir> Hobbsee: doko and scott can give back packages too, but I'm fine with taking those requests.
* Hobbsee clones self, and has trippleHobbsees running around
<Hobbsee> ah, gotcha
<seb128> but usually Mithrandir is the one reading the chan I think
<benkong2> hello all. How can I learn why a particular feature was chosen and how it was implemented in Ubuntu?
<Hobbsee> now there's quadruple trouble from the girls from au!
<benkong2> as an example using a modprobe.d/ instead of a modprobe.conf file
<Keybuk> benkong2: that feature was neither chosen for or implemented for Ubuntu
<Keybuk> rather that's the way it comes from upstream
<Keybuk> (the general answer would be to look at https://blueprints.launchpad.net/ubuntu for the specifications; and read them)
<benkong2> and upstream means what or who?
<Hobbsee> gnome, kernel,...
<Keybuk> module-init-tools upstream
<benkong2> Keybuk, ok thanks
<Keybuk> authors of modprobe
<Keybuk> that's how it comes "out of the box"
<benkong2> checking now
<benkong2> I am building a LinuxFromScratch build and was just curious. Trying to understand the underbonnet stuff
<Keybuk> generally a ".d" directory is preferred to a ".conf" file
<Keybuk> since any package can place files in the directory, and modify them, or remove them
<Keybuk> whereas the conf file requires manual editing, and dealing with user changes, etc.
* Hobbsee wonders how many scott's there are working for canonical.
<Keybuk> Hobbsee: just me
<Mithrandir> seb128: you just implied I don't have a life, but that's ok. :-P
<Hobbsee> oh right
<benkong2> I agree and I wanted to try and change that in the LFS build] 
<Hobbsee> Mithrandir: we all knew that anyway.  :P
* Hobbsee gets confused between here and work.  the scott's seem to keep multiplying...
<seb128> rofl
<Hobbsee> it's fucking confusing when the only other employees in the store are called scott!
<seb128> Mithrandir: no, that's just your are the one replying to most of the "could somebody give a retry to" on the chan ;)
<Hobbsee> sure, i can put you thru to him...just WHICH ONE????  
<bryce> pick at random?
<Hobbsee> bryce: i tend to, yes.  "whichever one answers" is usually a good solution.
<keescook> Keybuk: delayed pong
<Hobbsee> sbalneav: apologies
<Mithrandir> seb128: what was your decision on the gtk patch we talked about?
<seb128> Mithrandir: I think we can use it, I didn't do much today (was on VAC) but I'll upload tomorrow morning if that's ok with you
<Mithrandir> seb128: that sounds great with me.
<seb128> good ;)
<Mithrandir> I didn't realise you weren't really here, sorry about that.
<seb128> no problem don't worry ;)
<Keybuk> keescook: just having dinner, will get back to you later
<keescook> Keybuk: okay.  what topic, btw?
<Keybuk> devmapper, lvm, etc.
<keescook> cool, ttyl
<glatzor> mpt: bryce: I wrote a quite lengthy mail to ubuntu-desktop
<bryce> glatzor: cool
<bryce> glatzor, btw one thing we should think about is some unit tests for displayconfig-gtk
<glatzor> bryce: when we have got collected some configs and pci table dumps this would be really a good idea.
<glatzor> Changing something in the backend and perhaps breaking all nvidia cards is really scary :)
<bryce> yup
<glatzor> bryce: sometimes I ask myself what I have done picking up this project :)
<bryce> glatzor: :-)
<robertj> is there a way to run through dpkg-buildpackage without trying to patch again?
<keescook> cjwatson: did you get a chance to double-check the final debdiff for bug 106887 ?  I'd like your ACK before I upload it.
<ubotu> Launchpad bug 106887 in grub ""ALERT! does not exist" at boot with ICH7" [Undecided,Confirmed]  https://launchpad.net/bugs/106887
<glatzor> bryce: oh, I've forgotten to push my local changes to the ubuntu branch
<glatzor> bryce: the pci table feature should now be included
<glatzor> bryce: furthermore I asked the guidance guys if they have already worked on an unit test yet.
<bryce> good - have they?
<Keybuk> keescook: I'm not sure, but I may have reverted your fix
<Keybuk> I'm not sure whether it was the device node going missing you were worried about
<Keybuk> or the vol_id issue
<afflux> keescook: You wanted me to keep you informed on my progress in the wordpress CVE bug. I noticed that the debian version that fixed these bugs also fixed about 7 other security vulnerabilities and I think it gets quite complicated to fix them all. I'd suggest to update to 2.0.10 (or newer?).
<keescook> afflux: doing a full-version update seems like a dangerous thing.  for that to happen, we should get sign-off from the motu council, likely.
<keescook> Keybuk: I made two uploads over the weekend; one to udev to add missing documentation, and one to devmapper to fix an over-aggressive udev rule
<keescook> I'll go check devmapper
<keescook> Keybuk: hm. based on what I've seen, the "snapshot" and "snapshot-origin" DM_TARGET_TYPES are actually the _final_ state of the devices.  It seems sensible to run vol_id on those.
<keescook> oh! no, wait, I understand
<keescook> the issue is having the various snapshots fighting over the fs UUID.  I get it.  Cool.
<keescook> one issue I see here is that as-is, the fs UUID map will vanish when I create a snapshot (since the "origin" device switches from "linear" to "snapshot-origin"), leaving _no_ device associated with the original fs UUID.  Is that desirable?  Perhaps not ignore "snapshot-origin" and just ignore "snapshot"?
<Keybuk> keescook: actually that's not the issue
<keescook> Keybuk: yeah, I wasn't able to reproduce my fear.  uuid link remains
<Keybuk> there is indeed some confusion about how we identify the "exception clearing" node that LVM creates as part of lvcreate -s, that we absolutely do not want to run vol_id on
<keescook> er, no, it moves
<Keybuk> hmm, how do you mean the UUID map shifts?
<keescook> pastebin coming..
<Keybuk> better question
<Keybuk> which one should the UUID point to?
<Keybuk> which of the following would you ever attempt to mount, and which would you absolutely not?
<Keybuk> vg-original
<Keybuk> vg-snapshot
<Keybuk> vg-snapshot-cow
<Keybuk> vg-original-real
<keescook> -cow and -real are not mountable ever
<keescook> -original and -snapshot are both valid
<Keybuk> heh, amusingly -cow and -real are the ones with the linear map
<Keybuk> -original has snapshot-origin table type, and -snapshot has a snapshot table type
<keescook> right, from what I can see, all the lv are initially created as "linear" and then lvm goes and tweaks their internal settings?  I'm not sure.
<Keybuk> from tracing LVM, we don't think there's a problem running vol_id on any of the "final" nodes
<keescook> right, but it changes during their creation lifetime
<Keybuk> the problem comes of running vol_id on the -snapshot node when it's linear, and not snapshot
* keescook nods
<keescook> but there doesn't seem to be any information about it to detect that it will "become" a snapshot type.  :(
<Keybuk> At the point (1) udev already run vol_id on vg-snapshot. This LV is only
<Keybuk> created to delete the exception table of the snapshot to be created. So
<Keybuk> lvcreate tries to remove the still open vg-snapshot.
<Keybuk> (from Kay)
<Keybuk> that's from a SuSE EL bug
<keescook> hm
<Keybuk> which is consistent with the bug we're seeing
<keescook> here's the uuid moving, btw: http://paste.ubuntu-nl.org/23143/
<Keybuk> we vol_id the first device node, and race lvm needing to change it
<keescook> the fs uuid moves to -real (which is wrong).  It should either stay on the snapshot-origin, or it should follow the most recent snapshot (kind of insane)
<Keybuk> ok
<Keybuk> that follows
<Keybuk> we'd need some way to match the -real and -cow devices to avoid them ever taking the UUID
<Keybuk> are they hardcoded to those names?
<keescook> they seem to be, yes.
<`23meg> glatzor, regarding bug 117429, did update manager use to display total size of installed files for metapackages?
<ubotu> Launchpad bug 117429 in update-manager "Does not show new dependencies of updates" [Undecided,Confirmed]  https://launchpad.net/bugs/117429
<Keybuk> can I make a device of my own with those names?
<Keybuk> actually
<Keybuk> easier way
<keescook> I haven't tried trying to intially collide with the reserved names.
<Keybuk> just increase the link_priority of a device with table type snapshot or snapshot-origin <g>
<Keybuk> can you try something for me
<keescook> I know lvcreate won't let you use "snapshot" as a name, though
<keescook> sure
<Keybuk> edit /etc/udev/rules.d/65-dmsetup.rules
<keescook> I think only snapshot-origin should get the bump; I don't think it's sensible to move the fs UUID to the "most recent snapshot"
<Keybuk> remove the *snapshot*| bit
<glatzor> `23meg: the total download size is not calculated by adding all sizes of the displayed updates but by apt in the background.
<Keybuk> then at the bottom, you'll see it set the link_priority
<Keybuk> that should read
<glatzor> `23meg: apt only takes a look what needs to be changed to install all these updates.
<Keybuk> ENV{DM_TARGET_TYPES}=="snapshot-origin", OPTIONS+="link_priority=-90"
<Keybuk> ENV{DM_TARGET_TYPES}!="snapshot-origin", OPTIONS+="link_priority=-100"
<glatzor> `23meg: meta packages as meta packages are only visible to humans. Apt treats them as normal packages.
<`23meg> glatzor, I understand; I agree with displaying metapackage size in the current state of things, but it seems the bug ended up pointing to something other than what it intended :)
<keescook> Keybuk: testing now
<keescook> Keybuk: yup, that works.  the uuid stays mapped to the origin
<glatzor> `23meg: that is what makes bug triage fun :) sometimes ...
<`23meg> agreed, sometimes..
* `23meg looks for possible duplicate
<Keybuk> keescook: shiny
<Keybuk> ok, have uploaded a devmapper to fix up the rules to behave that way
<keescook> Keybuk: cool.  I'm glad I gave myself a crash-course in udev debugging this weekend.  I finally feel like I can help with this goo.
<Keybuk> hopefully upstream will get back to me on the "ignore the first node" fix soon
<keescook> instead of just opening bug reports.  ;)
<Keybuk> when udev works, it actually does work really nicely
<keescook> so, as I understand, we still have the vol_id race, right?
<Keybuk> the udevmonitor output with all the dmsetup info in it is really nice
<Keybuk> yeah, we still have the "in use: not deactivating" race
<keescook> ironically, I haven't run into it since updating devmapper.  :P
<Keybuk> that's because devmapper is a bit more likely to win the race atm
<Keybuk> previously it span until dev made the device, which means it was likely to hit vol_id
<keescook> cool.
<Keybuk> now devmapper returns immediately having made the device node itself, and some time later, udev twiddles the permissions on the node
<Keybuk> (actually, right now it replaces the node with a symlink, but that's for debugging)
<keescook> I'm thinking about setting up a gdb breakpointer to be able to reproduce the race.
<keescook> I've got a gdb bash script harness for doing this to things in general (for testing security races)
<Keybuk> this is temporary though
* keescook nods
<Keybuk> upstream want the devmapper ioctl()s to not return until the udev event has finished processing
<Keybuk> race: stop the devmapper library call as it returns; stop vol_id as it runs
<keescook> yeah, that seems sane.  are there problems with that from a kernel perspective?
<Keybuk> step through vol_id until the device is open
<Keybuk> continue the proecss that calls devmapper
<Keybuk> kernel currently doesn't have any notification from udev that it's done
<keescook> ah
<Adri2000> I wonder why my last upload appeared on LP exactly one hour after I actually did the upload, it used to be really faster
<Keybuk> Adri2000: did you do the upload on the hour?
<Keybuk> we've had hour-long days ever since we used LP
<Adri2000> "on the hour" what do you mean?
<Keybuk> uploads are processed once an hour
<Keybuk> if you do the upload a second after it starts processing, it won't happen until the next hour
<Adri2000> ahh ok, I thought it was something like 5 minutes
<Adri2000> or at least we receive the accepted mail within 5 minutes, but then it's longer to show up on LP ?
<Keybuk> exactly
<robertj> can someone please mark #109250 as confirmed?
<robertj> bug #109250 is a regression as well
<ajmitch> robertj: you can change the status, just not importance
<ubotu> Launchpad bug 109250 in apache2 "/etc/init.d/apache2 doesn't do "chown www-data /var/lock/apache2" after directory creation" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109250
<ajmitch> if you're logged in, somehow I got logged out again
<robertj> I'mlogged in, but don't see the option
<ajmitch> under "Affects", click on apache2 (ubuntu)
<robertj> ahh
<ajmitch> not completely obvious
<svu> what happened to alternate images of feisty? they are not there for ubuntu
<ccm> svu: http://www.ubuntu.com/getubuntu/download
<mrsn0> svu there are alternate images
<ccm> svu: "Check here if you need the alternate desktop CD. This CD does not include the Live CD, instead it uses a text-based installer."
<svu> ccm, thanks. for some reason I do not see it in cdimage.ubuntu.com...
<ccm> svu: no problem
<ccm> svu: you should better refer to www.ubuntu.com in the first place
<mrsn0> svu its on cdimage, but a different date candidate was used than normal ubuntu livecd
<Mithrandir> svu: they're on releases.ubuntu.com.
<mrsn0> http://cdimage.ubuntu.com/daily/20070529/
<svu> ccm, it seems you're right. thanks again
<svu> mrsn0, oh please no daily stuff:)
<Mithrandir> current dailies are, or should be, broken
<svu> Mithrandir, I see now. What's the differernce between cdimages.u.c and releases.u.c?
<elmo> could someone add some text to the top of cdimage.ubuntu.com pointing users at releases.u.c?
<Mithrandir> elmo: yes, I can do so
<svu> wise action
<Mithrandir> svu: cdimage.u.c contains stuff which either changes rapidly (dailies) or which we don't believe will have a too big audience, like DVDs and ports.
<ccm> svu: you could of course think about maintaing a jigdo copy for yourself, this is not "daily" stuff, but always a cd image an a very recent patch level
<elmo> Mithrandir: bonus points if you can do it for every directory
<svu> Mithrandir, I see... it was not clear from the names ...
<elmo> Mithrandir: (which make require apache magic, so let me know, but I suspect/think y'all have .htaccess anyways)
<svu> ccm, sure I won't :)
<elmo> s/make/may/
<ccm> svu: ;)
<Mithrandir> elmo: yes, it'll probably require some magic.  I'll put it on my todo list for tomorrow since hacking apache configs close to midnight will make my wife angry when I crash at 0400.
<svu> wifes always conflict with professional duties. that's desperate
<elmo> Mithrandir: heh, ok - thanks.  I can file a bug instead if you'd prefer; it's not urgent, but it sounds like something obvious we should do at some stage
<Mithrandir> svu: I prefer not to have professional duties around midnight. :-P
<Mithrandir> elmo: yup, agreed.  I'm just tired so doing it now's not a good idea.
* svu bows to Mithrandir 's wisdom
<svu> Mithrandir, btw, would it be better to use x64 image for core2duo?
<svu> (with the perspective to setup xen)
<mrsn0> svu feisty images didnt change after release so they are the same images (md5 to confirm)
<Mithrandir> svu: if you have gobs of ram, it would be, but in most cases it won't make much of a difference.  Some apps are a fair bit faster in 64 bit mode, some are a bit slower, but most will be slightly faster.
* Mithrandir goes to nuke feisty from the daily directories
<svu> mrsn0, ghm. 29.05 is not exactly feisty's release day, is it?
<mrsn0> :)
<svu> Mithrandir, 2G of RAM should be enough, I hope. Is xen ok with 64bit kernel?
<Mithrandir> svu: it works for me, at least.
<mrsn0> uh whoops that was gutsy
<svu> good. I will give it a run too. I'll put vista inside if I manage to
<svu> mrsn0, :)
<mrsn0> 20070418/ was alternate image i think
<mrsn0> in ports/daily/
<mrsn0> but yes very  confusing to find the alternate, unless using ubuntu.com :p
<Mithrandir> mrsn0: while in this particular case you happen to be correct, there's no guarantee of an image of a later date actually being the release image on cdimage.  For release images, please use releases.ubuntu.com (or a closer mirror)
<svu> mrsn0, yes, that makes sense, 0418. anyway, it is already found...
<dholbach> evince ftbfs on 64bit due to "relocation R_X86_64_32S against `kpse_format_info' can not be used when making a shared object; recompile with -fPIC"  (http://librarian.launchpad.net/7866732/buildlog_ubuntu-gutsy-amd64.evince_0.9.0-1ubuntu2_FAILEDTOBUILD.txt.gz)
<mrsn0> Mithrandir indeed, for iso testing i used cdimage so thats why imentioned really while the finished images were on different dates they were all moved to the correct download site
<Mithrandir> mrsn0: yes, I know.  It was I who did it. :-P
<svu> anyway, thanks a lot to everybody for a lot of useful info
<mrsn0> :-)
<Mithrandir> dholbach: a library isn't compiled with -fPIC then
<mrsn0> your welcome svu/ sorry for confusion
<dholbach> mandriva builds tetex with -fPIC 
<dholbach> should we do that with texlive-bin then?
<Mithrandir> for any libs, yes.
<dholbach> i'll take a look at it
#ubuntu-devel 2007-05-30
<sits> hi?
<sits> Do any of the kernel folks know of a problem with intel SATA in the latest Ubuntu kernel?
<sits> ata_piix / ICH4&ICH5 boards
<sits> Bug #116996
<ubotu> Launchpad bug 116996 in linux-source-2.6.20 "sata disk in ide mode with kernel 2.6.20-16-generic (ata_piix broken?)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116996
<abo> sacater, hi again
<sacater> abo: hi
<sacater> abo: tell these nice people whats happened
<abo> ok 
<abo> hi all... after upgrading to the latest kernel, my camera isn't automounting when plugged, booting into the previous kernel fixed the problem
<abo> after upgrading the kernel ...  my camera isn't automounting when plugged, booting into the previous kernel fixed the problem
<abo> do you need any more info?
<pochu> abo: please, file a bug. This channel isn't for support :)
<abo> pochu, sacater asked me to report what happened here.. for me i'm fine now my camera is working, thx
<sacater> pochu: eep
<pochu> abo: is that Feisty?
<abo> yes
<pochu> Then https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+filebug is the link.
<TheMuso> C
<TheMuso> ugh typing
<BTZ> I've been looking for a package that provides kernel development manpages without much success. Is there such a thing in feisty?
<johanbr> BTZ: linux-doc-2.6.20 has some kernel docs.
<BTZ> johanbr: I noticed some linux distros have manpages for stuff like cdev_init, printk, kmalloc, etc. linux-doc-2.6.20 does not seem to provide them.
<Hobbsee> oops.  now, if i'm going to leave my computer on while sleeping, i really should plug it in...
<johanbr> BTZ: Those don't seem to be in ubuntu, no.
<hile> siretart: sent you mail about cryptsetup changes. While the new udevsettle patch is not my patch, it does it's job (and is cleaner), thank you very much
<hile> still think we should get rid of activate_evms and activate_lvm, those are done by udev now, but if we share package with debian, it might be debian's ramdisk still needs those...
<hile> at least 'activate_lvm' is bogus which I can confirm (have been running modified initramfs without it for months, with encrypted LVM setup)
<hile> and I see no reason why the evms part would be any less bogus, if udev handles evms as well
<hile> still, booting to 2.6.22-15 with encrypted root on LVM fails, but this is not related to my earlier errors, it seems to be a crypto module loading issue
<hile> happened with edgy as well, iirc, crypto modules were just renamed ... 
<Burgundavia> nixternal: https://wiki.ubuntu.com/WriteYourRepresentative
<nixternal> heh
<nixternal> you are a couple of channels off
<Burgundavia> indeed, I am
<nixternal> lol
<Hobbsee> siretart: ping
<Hobbsee> siretart: sorry, bad ping
<reitblatt> ping kylem: ok to go ahead and confirm bug #87262 ?
<ubotu> Launchpad bug 87262 in linux-source-2.6.20 "Virtual PC and feisty fawn" [Undecided,Needs info]  https://launchpad.net/bugs/87262
<reitblatt> you're still assigned on it, so I don't want to step on your toes
<calc> Hobbsee: hi
<calc> still no word on my condo loan closing :\
<Hobbsee> hey calc!
<Hobbsee> aww
* calc kicks his banker
<Hobbsee> heh
<calc> i have to be totally moved out of my apt tomorrow, so i had to move in with my gf's parents until i can move into the condo
<Hobbsee> they wont do what you want, if you do that :P
<Hobbsee> urgh
<calc> heh
<ccm> good morning *moan*
<ion_> Good night.
<poningru> going to sleep
<poningru> err sorry worng channel
<siretart> hile: I agree that we really need to discuss this with the debian cryptsetup maintainers. 
<Mithrandir> pitti: any chance you could review sexy-python for main, so we can get -desktop installable?
<pitti> Mithrandir: sure, will do right now
<Mithrandir> thanks.
<pitti> Mithrandir: promoted
<Mithrandir> cheers.
<hile> siretart, anyway thanks for finally fixing the device waiting issue - does feisty have exactly same udevsettle commands? I think we could add the same udevsettle line there 
<hile> this other laptop where I'm writing from has feisty and LVM encryption, I can easily test adding the udevsettle line to unmodified hook script there
<hile> oh, udevsettle _is_ there, what have I missed...
<Mithrandir> mmm, removals.
<doko> pitti, Mithrandir: m2crypto, python-fuse, orsa aren't synced (-buildN version number)
* Mithrandir just removed about 340-ish binary packages.
<pitti> doko: they will on the next autosync run
<pitti> Mithrandir: cruft-check?
<Mithrandir> yeah
<Mithrandir> and I'm not really done with it either.
<Mithrandir> and I skipped those with scary rdeps lists
<Mithrandir> like, libsnmp9
<Mithrandir> pitti: I ran autosync this morning, so it should be good now.
<siretart> hile: we can provide updated (testing) deps in a PPA (personal package archive)
<hile> well, actually feisty default package already works, last revision (cryptsetup 2:1.0.4+svn26-1ubuntu2) fixed this
<hile> I just did not notice it ... and had my own pkgs overriding 
<siretart> oh, even better. so we don't even need to do anything for feisty :)
<hile> I can confirm  encrypted LVM PV under root fs problems are solved!
<pitti> thekorn: hello
<siretart> hile: you've written me about a README?
<hile> yeah, it was with the big patch, but you can get it from http://ner.dy.fi/deb/cryptsetup/feisty/README.patch
<thekorn> hi pitti
<pitti> thekorn: is it planned to add a python-launchpad-bugs API for deleting attachments? that's really important for the apport stuff
<thekorn> pitti: I think it's not planned yet,
<thekorn> but i'm happy adding it to my TODO list,
<thekorn> should not be so difficult
<pitti> thekorn: no, it's just another 'emulate clicks' thingy; the most difficult thing is to bolt it into the API in a consistent way
<pitti> thekorn: and I don't know what the current plan for API redesign is
<thekorn> pitti: my plan is to start working on the redesign this week,
<thekorn> so adding this won't be a problem
<hile> siretart: the text maybe should go to CryptoRoot.HowTo, I'm not really sure ... whatever
<siretart> hile: I've committed your patch to README as revision 11, which will appear soon at https://code.launchpad.net/~siretart/cryptsetup/ubuntu
<hile> ok, thanks
<pitti> thekorn: ah, nice; I'm happy to participate in the design discussion
<siretart> hile: feel free to work further on the READMEs. they are welcome!
<hile> yep
<siretart> hile: however, perhaps we should start a separate file, and not use the existing files from debian to make merging easier
<hile> hmm I started thinking, does partman-crypto already support encrypted LVM ... it would be quite trivial for it to setup after all
<dholbach> good morning
<hile> well, have to write documentation for new servers ->
<dholbach> pitti: somehow my texlive-bin fix does not fix the evince ftbfs (it builds normally, but not in pbuilder) - could it be that libkpathsea-dev should depend on libkpathsea4?
<pitti> dholbach: oh, indeed, it doesn't; yes, of course it needs to, to resolve the /usr/lib/libkpathsea.so symlink
<doko> Riddell (or another kubuntu guy): could you sync/merge wlassistant from universe-manual ?
<dholbach> pitti: ok, I'll do another upload and test if that fixes it
<dholbach> hey doko
<doko> dholbach: hey!
<dholbach> doko: how's it going? how is your hand/arm?
<dholbach> doko: did you consider using workrave?
<pitti> bdmurray: would you have some time to verify bug #113508, so that we can push it to -updates and silence feisty crashes?
<ubotu> Launchpad bug 113508 in adept "adept notifier still notifies kubuntu users of apport crashes" [High,Fix committed]  https://launchpad.net/bugs/113508
<doko> dholbach: still splinted
<siretart> hile: yes, we need to test and adapt partman-crypto for gutsy. 
<doko> dholbach: for rowing?
<dholbach> doko: oh, so you reckon it was caused by rowing and not by typing 24h a day? :)
<pitti> ooooh, FFS, I suck
<pitti> somewhere in ddeb-retriever's version domination there's a bug, so that feisty ddebs got killed
<pitti> no wonder that so many retraced bugs have failed stack traces
<pitti> s/failed/unusable/
<dholbach> happy HUG DAY!
<pitti> hi seb128
<seb128> hey pitti
<cjwatson> Spads: thanks; I'm adjusting various small things for that now.
<cjwatson> (powerpc on ports)
<dholbach> good morning cjwatson
<cjwatson> keescook: I can't claim to understand the patch, but I'm happy for it to be given a try in gutsy
<cjwatson> morning
<cjwatson> ok, who ate base-files' Priority field?
<pitti> cjwatson: yesterday we noticed that since the latest Soyuz rollout there are no Priority fields any more; this also makes all packages in MoM red
<cjwatson> yes, override.gutsy.main is blank
<cjwatson> this buggers up the installer very comprehensively
<cjwatson> has anyone raised this with the soyuz team? it's critical
<cjwatson> I really hope the data has not disappeared from the db
<cjwatson> ok, it does seem to still be therre
<cjwatson> there
<cjwatson> pitti: not all Priority fields, though, only some
<cjwatson> lp_archive@drescher:~$ zcat ubuntu/dists/gutsy/main/binary-i386/Packages.gz | grep-dctrl -P -nsPackage -r . | wc -l
<cjwatson> 5380
<cjwatson> lp_archive@drescher:~$ zcat ubuntu/dists/gutsy/main/binary-i386/Packages.gz | grep-dctrl -FPriority -nsPackage -r . | wc -l
<cjwatson> 3623
<seb128> siretart: bug #117703, any reason we don't sync emacs22?
<ubotu> Launchpad bug 117703 in emacs-snapshot "please sync emacs-snapshot from http://emacs.orebokech.com/" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117703
<siretart> seb128: as explained in the bug, it is in experimental for a reason
<siretart> seb128: maintainer has indicated that he wants to do further changes with impact before uploading to unstable
<seb128> k
<seb128> you didn't indicate the reason
<siretart> seb128: romain's packages are more similar to what we already have
<siretart> I didn't?
<seb128> "(there is on in experimental, but for a reason)"
<siretart> ah, sorry
<seb128> no problem ;)
<siretart> seb128: one obvious benefit of romain's packages: they come with documentation
<siretart> and emacs without documentation is nearly useless :/
<seb128> Lure: could you get the sync request on bug #117153 validated by a MOTU?
<ubotu> Launchpad bug 117153 in strigiapplet "sync strigiapplet 0.5.1-1 from debian unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117153
<Lure> seb128: I am MOTU ;-)
<seb128> Lure: not according to https://launchpad.net/~lure/
<seb128> gra, the page is confusing
<seb128> it doesn't list all the team
<seb128> that's alright ;)
<Lure> seb128: yep, I was confused a couple of times too ;-)
<pitti> seb128: ah, too bad; I asked Debian to add the Conflicts: libpoppler1-qt4 to libpoppler-qt4-1, but they didn't; so we cannot sync just because of this
<StevenK> seb128: Should I be able to see the libkexiv2 sync you processed an hour ago in LP?
<StevenK> (Since I can't)
<seb128> StevenK: no, I just run the command to process the syncs now
<seb128> we batch them
<seb128> s/run/ran
<StevenK> Ah, right.
<siretart> seb128: do I need to monitor romains emacs-snapshot packages manually, or will they get autosynced?
<seb128> siretart: monitor
<siretart> k
<doko> seb128: nothing else to do so that you can process sync requests with lightning speed ... ;-P
<seb128> doko: I was doing sync but every time I refresh the page to look if I'm done with them there is a new bug from you :p
<seb128> doko: looks like python-dbg changes are going to Debian, that good ;)
<seb128> doko: is that a Debian announce mail or somebody that we could point if we send a patch to Debian?
<doko> seb128: on my list ...
<seb128> k
* Mithrandir grrs at ekiga being broken.
<seb128> crimsun: do you get that rhythmbox crash when ejecting and ipod on gutsy?
<mdz> Mithrandir: you mean it works for you sometimes?
<dholbach> Mithrandir: is that on gutsy or on feisty?
<dholbach> Mithrandir: for gutsy siti started taking care of opal+pwlib+ekiga and we're closer to upstream again (finally) - so it'd make sense to report a bug and forward it upstream
<dholbach> awesome! - I announced http://lists.ubuntu.com/mailman/listinfo/ubuntu-motu-mentors an hour ago and we already have 24 subscribers
<pitti> dholbach: nice that there's so much interest
<dholbach> expect more ubuntu-dev members soon :-D
<dholbach> if you need help with bugs you marked as 'mentoring available' you could post a link on that list
<ccm> what i am a bit puzzled about is that there seems to be no easy way to mark bugs as belonging to a specific ubuntu version or am i wront?
<ccm> erm wrong
<dholbach> ccm: usually we fix bugs in the current development version
<ccm> dholbach: well there are currently dapper (lts), edgy, feisty and gutsy to keep in launchpad, am i wrong?
<ccm> all of them ar either supported or in development process
<dholbach> ccm: using "target to release" on the left hand side can be used to nominate a fix for a backport
<dholbach> ccm: yes, but we only backport fixes that fall under a certain category: http://wiki.ubuntu.com/StableReleaseUpdates
<ccm> dholbach: okay, i will read that, thank you
<dholbach> anytime
<cyber> hello everybody
<Mithrandir> dholbach: opal broke the ABI without bumping the soname, so yes.
<Mithrandir> dholbach: and gutsy, yes.
<Mithrandir> mdz: yes, it usually works for me.  Doesn't it for you?
<dholbach> Mithrandir: grngrngrngrn :-(
<mdz> Mithrandir: no :-/
<Mithrandir> mdz: consistently, or just in gutsy?
<Mithrandir> ekiga: symbol lookup error: ekiga: undefined symbol: _ZN11SIPEndPoint8RegisterERK7PStringS2_S2_S2_S2_i
<Mithrandir> downgrading libopal-2.2.0 to the feisty version fixed it.
<mdz> Mithrandir: typically
<mdz> not as in "doesn't run", but that I'm not able to successfully make/receive calls
<Mithrandir> ugh, ok.  I'm using my own asterisk setup, unsure if that's relevant or not
<Mithrandir> dholbach: do you want a bug about it?
<dholbach> Mithrandir: that'd be nice - I'm not taking care of ekiga and friends any more, but I sponsor siti's uploads (I hope we'll have a ubuntu-voip team soon)
<Mithrandir> ook
<agoliveira> Mithrandir: Hi. Did seb128 send that patch for hildon-fm?
<seb128> agoliveira: you mean "upload gtk+ patched"? not yet, I'm working on it right now
<seb128> why?
<agoliveira> seb128: Well, because it would help us go ahead with the hildon components :)
<Mithrandir> agoliveira: you can just apply it locally and build a local gtk+
<seb128> agoliveira: I know, I'm on it, will be uploaded soon
<agoliveira> Mithrandir: Am I missing anything? I tought it was not avaliable yet.
<agoliveira> seb128: Thanks.
<seb128> agoliveira: the patch has been sent on the list
<agoliveira> seb128: Ah, sure. Sorry I misunderstood it.
<Riddell> StevenK: ping, are you working on main-manual merges?
<StevenK> Riddell: I have been.
<StevenK> Riddell: libkexiv2, libmtp and scim-qtimm are dealt with. I was just about to pick another.
<Riddell> StevenK: ok great, thanks.  I'm through my e-mail backlog now so let me know what you pick and I'll go with the other one
<StevenK> Riddell: Of yours, only ksystemlog and knetworkmanager are left. Hobbsee said to not touch knetworkmanager, which leaves only ksystemlog. Do you want to do it?
<Riddell> StevenK: you go ahead, I'll move on to http://merges.ubuntu.com/universe-manual.html
<StevenK> Riddell: Great, thanks.
* StevenK shivers. wlassistant is on the universe manual list.
<maswan> kylem: Having worked alot on this, we can't seem to reliably trigger anything other than a tendancy to get more frequent and severe page-allocation failures in .55 than .53. The lockups etc seems to be not reproducable. :/ Any suggestions, or should we just cancel it as a false alarm?
<Hobbsee> evening all
<highvoltage> hi Hobbsee 
<Hobbsee> heya highvoltage :)
<siretart> has anyone seen pitti lately?
<seb128> siretart: he's away for lunch
<siretart> ah, ok
<Hobbsee> siretart: i ate him.  i was hungry.
* siretart hides
* Hobbsee munches on siretart for desert
* siretart runs screeming
* Hobbsee wonders what screeming is.
* Hobbsee also wonders how one runs while being eaten.
<StevenK> "SCREEM is a tag-based Web page editor ..."
<StevenK> So it seems siretart is going to write a web page using screem.
<siretart> screaming, even,
<Hobbsee> :P
<cjwatson> debootstrapping gutsy works again, for those who noted that it was broken
<StevenK> Yay!
<Hobbsee> woo!  people in #ubuntu+1 were whining about it for the last couple of days
<cjwatson> it was a soyuz bug
<siretart> the bug about lost priorities?
<cjwatson> yes
<cjwatson> when base-files isn't spotted as being Priority: required, you have no /proc ...
<StevenK> Oh, neat.
<Hobbsee> very neat
<cjwatson> dholbach: were you working on https://launchpad.net/+builds/+build/340909 ?
<cjwatson> (evince build failure)
<dholbach> yes
<dholbach> I uploaded evince - it should build now - I just submitted the fix to Debian too
<cjwatson> ah yes, it's in accepted, thanks
<dholbach> np
* Hobbsee ponders if swapping her keys around would make her be able to type any better.
<StevenK> Hobbsee: Set your keymap to Dvorak. That ought to help, or something.
<Hobbsee> StevenK: heh.  or just unbandage my finger, if i'm not going to bleed everywhere again.  either would work.
<thom> fsvo help
<Hobbsee> thom: ?
<thom> i'm somewhat sceptical that dvorak would be a short term help, per mr kowalik's suggestion :-)
<Hobbsee> ahh
<Hobbsee> @schedule sydney
<ubotu> Schedule for Australia/Sydney: Current meeting: Edubuntu | 31 May 06:00: Xubuntu Developers | 01 Jun 02:00: Ubuntu Development Team | 01 Jun 07:00: Kubuntu Developers | 06 Jun 05:00: Technical Board | 07 Jun 06:00: Edubuntu
<Hobbsee> oof.
<Hobbsee> 5am
<kylem> maswan, it's probably worth an email to andrew morton about (in the general sense, not for ubuntu help)
<maswan> kylem: yeah, I'll respond to the bug and suggest closing it. it does not seem to be a regression, just that we triggered it just after upgrading.
<kylem> it shouldn't really fall over like that one way or another.
<maswan> Yeah, it shouldn't. But it isn't (much, .55 seems to get page-allocation failures quicker/more than .53) related to that particular upgrade though.
<Hobbsee> siretart: he's found.
<siretart> Hobbsee: thanks. 
<Hobbsee> :)
<siretart> pitti: I need to bug you in a few hours ;)
<pitti> hey siretart, what's up?
<siretart> oh, it's about ffmpeg
<iwj> pitti: FAOD I'm about to do the dpkg merge as promised.
<pitti> iwj: ah, thanks
<iwj> Oh.  It looks like I may need some magic merge script of Colin's.
<iwj> Most of the clashes are in .gmos.
<iwj> #include <i18nrant.h>
<cjwatson> drop .gmos, they're binary and generated (and shouldn't really be in source packages IMHO)
<pitti> iwj: hm, in general we drop all the .po/.gmo changes relative to Debian, but since dpkg is blacklisted from stripping, it's a bit special
<pitti> iwj: the question is why they are in the orig.tar.gz in the first place
<pitti> right, what colin said
<cjwatson> .po --msgfmt--> .gmo
<iwj> cjwatson: OK.
<maswan> kylem: it would have been convenient with an lts-supported ubuntu with an 2.6.20 or newer too. ;)
<iwj> There's some .po's too but I can probably merge those by hand.  Let me look at how bad they actually are.
<Mithrandir> maswan: the plan is for gutsy+1 to be LTS
<bhale> that is a year away
<Mithrandir> it is
<maswan> Mithrandir: Yeah, I know. 
<StevenK> Mithrandir: And have the longer release cycle, or is that undecided?
* Hobbsee throws icecubes at StevenK 
<StevenK> Hey! It's cold enough without you helping.
<Mithrandir> StevenK: gutsy is having a slightly shorter one and gutsy+1 will have a slightly longer one.
* Hobbsee throws more icecubes at bhale 
<Mithrandir> less than the six weeks we had for dapper, but a couple of weeks at least.
<bhale> Hobbsee: ?
<bhale> Hobbsee: hugs.
<Hobbsee> bhale: heya
<Hobbsee> bhale: isnt throwing icecubes a greeting?
<pitti> iwj:out of interest, which parts of dpkg did we touch, string-wise?
<StevenK> Mithrandir: How much was taken from Gutsy? I didn't notice the release being shorter.
<cjwatson> last I checked the dpkg string diff was Breaks
<Mithrandir> StevenK: just a week, I think.
<StevenK> Ah
<Mithrandir> StevenK: since the original plan would have put it back-to-back with UDS which would have been utter insanity.
<StevenK> Especially for the distro team...
<StevenK> I wonder if that makes Gutsy+1 the first odd numbered release.
<StevenK> Adding a few weeks presumably takes it from April to May.
<Mithrandir> yes, and the "what if something goes a bit wrong".  Having the whole distro team jump on a plane the day after release is.. not wise.
<StevenK> Ah, that's a point.
<Hobbsee> meh.  depends how long the plane flight is
<Hobbsee> and if there's wifi
<Lure> any archive-admin on duty today: would need strigi through binary NEW to be able to make strigiapplet build
<Hobbsee> pitti: ^
* pitti points to seb128
<pitti> ... and gets a segfault
<Hobbsee> haha
<StevenK> Heh
<pitti> Hobbsee: ok
* Hobbsee restarts pitti 
<pitti> Hobbsee: that helped, seb128 is back :)
<Hobbsee> pitti: ahh, now you can delegate
<StevenK> Oh look, the pointer is no longer NULL
<seb128> Mithrandir: k, I've GTK+ ready to upload now, do you have an opinion on shlibs update or not?
<Lure> seb128: [16:01]  <Lure> any archive-admin on duty today: would need strigi through binary NEW to be able to make strigiapplet build
<Lure> seb128: [16:01]  * pitti points to seb128
<Lure> ;-)
<seb128> k, will look at it next
<Lure> seb128: thanks
* pitti fixes ddeb-retriever to fetch from stable-{security,updates}
<pitti> seb128: due to a limitation of ddeb-retriever and silly me not flipping it to gutsy early enough we lost some ddebs of feisty, in particular libc6
<pitti> seb128: that would explain why so many feisty crash retraces are broken
<seb128> oh
<pitti> just FYI
<seb128> I didn't notice since we got almost no desktop crashers since we stopped apport
<seb128> but good to know ;)
<pitti> I sat down today (and am still sitting) to fix this once and for all
* pitti wonders whether we still care about edgy debug symbols
<seb128> no
<seb128> there is no real reason to use edgy rather than feisty
<seb128> I expect most of users have upgraded
<seb128> we get an edgy bug every now and then, no need to keep the whole ddeb set only for those imho
<pitti> also, no auto-retracing magic and such
<seb128> right
<seb128> Lure: any reason to have "libcluceneindex.so -> libcluceneindex.so.0" rather than to the real lib (libcluceneindex.so.0.5.1)?
<Lure> seb128: I do not soo good reason for it, but should talk with debian about it
<Lure> s/soo/see/
<seb128> Lure: strigi NEWed
<Lure> seb128: thanks
<seb128> np
<seb128> Mithrandir: I've not changed the GTK+ shlibs (I don't want to increase the requirement from 2.10.3 to 2.10.12 only for this hildon function) you will need to force the hildon-fm Depends version, let me know if you disagree
<sits> hi I'm having issues with ubquity on Feisty
<sits> When I tell it to do a guided install it gets as far as setting up an ext3 partition
<sits> it then seems to get confused and redetects an old ntfs partition
<sits> which halts the install
<sits> (and goes on to prevent sfdisk -R /dev/sda from working)
<sits> I have the machine available for testing now
<sits> but if no one's interesting then I think I will just dd zero the start of the partition and forget about the problem...
<sits> s/interesting/interested
<Hobbsee> cjwatson: ^
<sits> I can post logs and what not now
<sits> and I'm willing to reboot and reproduce the problem a few times before giving up completely
<sits> Hobbsee: ah ok how do I get hold of cjwatso?
<cjwatson> sits: I'm here
<sits> cjwatson: oh hi
<cjwatson> sits: could you put /var/log/syslog and /var/log/partman somewhere?
<sits> cjwatson: ok bear with me
<cjwatson> not pasted into channel :)
<sits> ;)
* Hobbsee gets the twitchy op fingers...
<heno> mdz: you are down as approver for https://blueprints.launchpad.net/ubuntu/+spec/installer-for-windows Can you have a look today or tomorrow?
<mdz> heno: yes, will do
<sits> cjwatson: http://cs.swan.ac.uk/~cssits/ub/
<mdz> heno: I was just looking for you; do you have time for a phone call today?
<heno> mdz: yes, and thanks
<sits> cjwatson: if this proves too cumbersome I can probably arrange for you to ssh into the machine directly (since it's all running off a livecd)
<iwj> Oh FFS they've REORGANISED THE DIRECTORY STRUCTURE.  Why oh why oh why etc.
<mdz> heno: how about at 1500 UTC (about 30 minutes from now)
<cjwatson> sits: I'll be a moment - helping somebody else at the same time
<sits> ok
<heno> mdz: sounds good
<Mithrandir> seb128: that's fine with me; thanks a lot.
<seb128> Mithrandir: you're welcome
<cjwatson> sits: just so I'm certain, which particular flavour of guided partitioning did you select?
<sits> cjwatson: er the top one (i.e. the automatic guided I think)
<cjwatson> which one is the top one varies depending on what's on the disk
<sits> cjwatson: bear with me
<cjwatson> it might be resize some partition and use freed space, or it might be use a whole disk
<sits> cjwatson:  Guided - use entire disk
<sits> cjwatson: partition table was blanked beforehand with fdisk /dev/sda
<sits> o
<sits> cjwatson: any clues?
<iwj> cjwatson: They've reorganised the .po files in dpkg into one .po per language rather than one per (language,manpage).  Do you have a magic tool that will help with this merge or shall I just concatenate the files before diffing and fix it up by hand ?
* seb128 takes a work break
<bryce> heya glatzor
<glatzor> hello bryce
<cjwatson> sits: something very weird is going on; I'm trying to work it out
<cjwatson> iwj: sounds like a sensible reorganisation. I'd try to find out what they used to do the job and mirror it; they probably used some combination of msgcat and/or msgmerge
<cjwatson> iwj: do we actually have any translations of the Ubuntu-specific strings?
<cjwatson> iwj: if not, you could just drop everything but the .pot ...
<cjwatson> or in fact drop that too and just regenerate it
<Mithrandir> looking at the ubuntu patch and trying to apply that hunk by hunk might work
<sits> cjwatson: I thought it might be worth investigating : )
<sits> cjwatson:  I have a feeling it might be kernel related because after the error occurs sfdisk -R /dev/sda stops working
<cjwatson> Mithrandir: I'm not sure that wouldn't just be unnecessary work in this case
<sits> even when I unmount all partitions on that disk
<cjwatson> sits: I'm reserving judgement for now
<sits> cjwatson: ah ok I'll shut up and let you look before spouting off...
<cjwatson> iwj: (thinking out loud) I'm starting by getting a more intelligent diff, by running msgcat over some of the allegedly changed .po files on the Debian side first
<cjwatson> a lot of the hu.po diffs seem to be essentially spurious
<cjwatson> msgcat turns a .po file into canonical form as far as line-wrapping is concerned
<iwj> cjwatson: Hmm.  I'll investigate.  Thanks.
<glatzor> bryce: I had some ideas during today's train ride.
<cjwatson> iwj: ok, I've confirmed that the .po diffs contain no actual translations
<bryce> glatzor: cool.  
<glatzor> bryce: for the unit testing it could be enough to feed displayconfig backend with the xorg.conf and the pcitable, apply the changes and then compare it to the correct xorg.conf?
<bryce> glatzor: I spent some time testing it last evening.  I sent in some bug reports for issues I found testing on nvidia and on a dual-screen system
<cjwatson> iwj: I did this by using msgcat to get rid of a bunch of the line-wrapping diffs, eyeballing the result, and also checking with things like "for x in man/po4a/dpkg.1/po/*.po; do msggrep -K -F -e 'B<breaks>' $x | msgattrib --translated --no-fuzzy; done" for each added string and manual page
<bryce> glatzor: yup
<cjwatson> iwj: so my advice would be to throw away the .po file diffs and let whatever it is regenerate them
<iwj> OK :-).
<bryce> glatzor: that's a very good, traditional approach for unit tests
<glatzor> bryce: this should be doable :)
<iwj> cjwatson: Thanks muchly.
<bryce> glatzor: :-)
<bryce> glatzor: also I had a question - how do I get the pci tables?
<bryce> I loaded the latest version from bzr (I think), but didn't see anything that suggested pci table capturing
<glatzor> bryce: you should update the bzr branch and then run ./displayconfig-gtk --data-dir=data --w FILENAME
<sits> cjwatson: ok I need to shut the machine down because I need to use the install disk to reimage another machine. If there's anything you need pronto let me in the next five minutes and I'll copy it off before I shut the machine down
<glatzor> bryce: ./displayconfig-gtk -w FILENAME should be enough
<bryce> hmm, I get a "no such option: -w" error
<bryce> I must not be on the right branch or something
<cjwatson> sits: hang on ...
<cjwatson> sits: any chance I could get a dd of the first 64K or so of /dev/sda1?
<sits> sure thing
<glatzor> bryce: https://code.launchpad.net/~displayconfig-gtk/displayconfig-gtk/ubuntu
<sits> one other thing while I remember
<cjwatson> sits: oh, could I also have the output of 'mount'?
<cjwatson> sits: was /dev/sda1 perhaps mounted before starting the installation?
<sits> when this happens a cancel window appears but clicking either button does not dismiss the cancel window or ubiquity
<cjwatson> sits: IIRC that's a known bug, but less of an immediate concern
<cjwatson> May 30 15:03:37 ubuntu hald: mounted /dev/sda1 on behalf of uid 0
<sits> cjwatson: unlikely - partition was blanked previously
<sits> hmm
<sits> ok lets get this dd to you
<cjwatson> that's supposed to be suppressed
<cjwatson> sits: you said you blanked the partition table, but did you blank the whole disk?
<cjwatson> it looks like there was an NTFS partition there before, maybe
<ogra> cjwatson, you will be pleased to hear that we found a better way for unencrypted X traffic in ltsp so we wont need cipher=none anymore ...
<cjwatson> very pleased :-) what was it?
<ogra> well, instead of using -X in ssh we export the DISPLAY ...
<sits> cjwatson: http://cs.swan.ac.uk/~cssits/ub/
<sits> cjwatson: no not the disk
<jdub> "Tested to work fine with Ubuntu-based Linuxes" -- from auspcmarket.com.au motherboard listing
<ogra> which gives us encrypted password handling from ssh but the same X transport as XDMCP
<ogra> so its even better than cipher=none :)
<sits> cjwatson: however it seems extreme that hal is picking up old partitions inbetween repartitiong and formatting though
<sits> cjwatson: if it is (perhaps it sees the "new" partitions striaght after the partition table is reloaded) then I guess that behaviour needs to be surpressed until the formatting is complete
<cjwatson> sits: it's supposed to be already :-/
<cjwatson> pitti: help
<pitti> cjwatson, sits: hal is triggered whenever udev detects a new partition
<sits> ok
<cjwatson> how do I stop it? I'm already suppressing gnome-volume-manager
<pitti> it'll run volume id and stuff, so it shouldn't yield an usable partition (that's a race condition, of course)
<pitti> cjwatson: there is no way to do that ATM short of stopping hal completely (but that shuold be avoided, too)
<pitti> cjwatson: I can teach hal to suppress picking up new volumes 
<sits> Doesn't hal have a "suepend for X seconds" option?
<pitti> cjwatson: either with a file-based flag, or a hal-set-property call in the computer object
<sits> I guess it could be used to DoS but what if it were only callable by root?
<pitti> sits: not that I know of
<sits> ok
<pitti> sits: hal-set-property can only be called by root anyway
<sits> ok
<bhale> ogra: can i pm you?
<pitti> cjwatson: if we had that, we wouldn't need to stop g-v-m and the KDE/XFCE mount daemons any more
<cjwatson> is there any way to temporarily set volume.ignore for everything?
<cjwatson> I guess not, but ...
<ogra> bhale, sure
<pitti> cjwatson: there might be actually
<pitti> cjwatson: you could drop a temorary FDI into /usr/share/hal/fdi, but I have to verify whether they are only parsed at hal startup or for every device (I think the former, though)
<pitti> cjwatson: let me try this
<cjwatson> pitti: sounds risky
<sits> the idea of zeroing the starts of partitions before repartitioning seems extreme but...
<sits> (just wait until the wrong partition gets zeroed...)
<cjwatson> sits: disabling hal would be a lot simpler and safer, I think
<cjwatson> sounds like you were just unlucky enough to run into a race condition
<sits> Isn't it dangerous to stop hal
<pitti> cjwatson: verified, FDI are parsed at startup (makes sense, since that's expensive); so WDYT about the 'computer' property to disable volume detection temporarily? (hal-set-property call)
<pitti> sits: /etc/init.d/hal stop would be indeed wrong, yes
<sits> ok
<pitti> sits: I just propose to inhibit volume detection
<cjwatson> pitti: sounds fine to me
<sits> cjwatson: do you want me to archive the first 1Mbytes of this disk?
<cjwatson> sits: sure
<sits> cjwatson: ok do you need anything else off this machine?
<cjwatson> sits: I think that's all, thanks
<sits> ok
<keescook> mornin'
<bryce> heya keescook
<Hobbsee> morning keescook 
<bryce> thanks for the xorg-docs upload
<bdmurray> howdy keescook 
<keescook> hiya bryce, Hobbsee, bdmurray :)
<pitti> it's a Kees!
<keescook> bryce: sure thing!  do you have time right now to work on beating beforelight into shape?
<keescook> hey pitti :)
<pitti> good morning!
<bryce> keescook, sure
* keescook switches to x channel
<bryce> glatzor: I got it working; I'm gathering pci tables presently; will upload in a few minutes
<glatzor> bryce: cool
<bdmurray> bryce: can you look at 117631 when you have a moment?
<bryce> bdmurray: ok, will do a bit later
<pitti> so, ddeb-retriever works correctly now with all feisty pockets and gutsy
<bryce> glatzor: http://people.ubuntu.com/~bryce/PciTables/
<glatzor> pitti: apport is really hot stuff!
<glatzor> bryce: fine
<pitti> glatzor: does your hook work?
<glatzor> pitti: I am writing it at the moment, but will test it in a minute.
<bdmurray> cjwatson: doesn't the oem install method cover most of bug 117084?
<pitti> glatzor: grab me if you want some help
<ubotu> Launchpad bug 117084 in Ubuntu "Ubuntu needs a "sysprep"-like tool, like Windows has" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117084
<cjwatson> bdmurray: yeah, sounds like he just missed it, although there are a few bits in there that could be useful enhancements for oem-config
<cjwatson> I'll reassign, thanks
<bdmurray> cjwatson: thank you
<sits> :(
<sits> Evesham just shipped out a "replacement" machine that seems to be of a worse spec than the broken one originally sent in
<mjg59> sits: IBM just shipped me back a laptop with a hole in it
<sits> mjg59: ah but where was the hole?
<mjg59> The back of the screen
<sits> ok now getting out of that one
<sits> s/now/no
<sits> mjg59: did they even know who you were? I'm sure they wouldn't have done that if they had.
<mjg59> Haha
<mjg59> They have other things to worry about
<ogra> mmh, a spy laptop ... like the newspapers where you rip holes in the pages to look through :)
<bryce> bdmurray: on bug 117631, that's interesting, I didn't know the installer picked out pci slots to use.  I don't know what inserts that but can take a look into it when I get some time.  
<ubotu> Launchpad bug 117631 in Ubuntu "Dell Optiplex GX50, Cannot Install From CD" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117631
<bryce> bdmurray: I'd guess that removing it might make this guys' system work, but break other people's systems
<bdmurray> bryce: okay, I wasn't sure if you had heard of it before
<sits> (one last point against evesham - their BIOSes routinely fail to fill in all the fields)
<bryce> bdmurray: nope, it's new to me
<slmnhq> I'm working on an ethernet driver, developing on dapper, kernel 2.6.17
<slmnhq> I am seeing the following message: "BUG soft lockup on CPU #1"
<glatzor> pitti: hm. I crashed my app, a crash file was created but without my extra files and apport does not want to send a report?
<slmnhq> (it's a dual core intel machine)
<glatzor> pitti: I am on feisty
<slmnhq> the syslog has a traceback ... do you think if I pasted that, some one could help me figure out what might be going on?
<pitti> glatzor: right, the hooks are not called before apport-gtk
<pitti> glatzor: touch /var/crash/*; /usr/share/apport/apport-gtk  -> does that work?
<pitti> glatzor: (the 'touch' because you seem to have already looked at the .crash file)
<glatzor> pitti: it complained that the package was not supported
<glatzor> pitti: does it check for modifcations?
<glatzor> pitti: I added a raise statement to my script
<pitti> glatzor: it does check for mods, yes, but the crashed file needs to be packaged
<pitti> glatzor: where is that script?
<glatzor> /usr/bin/displayconfig-gtk
<keescook> hmmm, is there a simple way to calculate the delta between 6.06.1 and "current"?  I'm having trouble figuring out where to find the 6.06.1 versions of things.  the seeds just list packages, not versions.
<pitti> glatzor: right, so the initial report is written because that looks like packaged; but it is not?
<glatzor> pitti: I finally found a way to crash the script shipped in feisty :)
<sits> wow
<sits> 9 minutes to install Ubuntu
<sits> (and that includes the time I speant typing stuff and waiting for it to boot)
<glatzor> pitti: hm it ignored my hook :/
<glatzor> pitti: https://bugs.launchpad.net/ubuntu/+source/displayconfig-gtk/+bug/117791
<ubotu> Launchpad bug 117791 in displayconfig-gtk "[apport]  displayconfig-gtk crashed with TypeError in on_treeview_gfxcards_cursor_changed()" [Undecided,Unconfirmed]  
<pitti> glatzor: oh, btw, you can see at the result of the hook information adding in the 'Details' expander
<pitti> glatzor: no need to actually file a bug
<QG> hello all
<pitti> glatzor: what's the path of the hook and what does dpkg -S /usr/bin/displayconfig-gtk say?
<pitti> glatzor: -> /query
<vprints> Bug #117783 - Openoffice crash
<ubotu> Launchpad bug 117783 in openoffice.org2-amd64 "presentation offer for a document recovery on close" [Undecided,Confirmed]  https://launchpad.net/bugs/117783
<glatzor> pitti: http://paste.ubuntu-nl.org/23282/
<QG> I am dedicating the next one hour of my life to bugsquading
<QG> I've read all the recommended reading material
<QG> Can someone guide me to an easy bug to start with. Never done this before
<Hobbsee> QG: i think you wanted #ubuntu-bugs?
<glatzor> pitti: renate@renate-laptop:~$ dpkg -S /usr/bin/displayconfig-gtk
<glatzor> displayconfig-gtk: /usr/bin/displayconfig-gtk
<Hobbsee> hmmm.  or it pointed here.  #ubuntu-bugs is where people are talking about bugs atm
<QG> isn't the bug-day on #ubuntu-bugs?
<glatzor> pitti: it is the default package from feisty
<glatzor> I just added the hook
<QG> I mean on #ubuntu-devel?
<pitti> glatzor: did you see my /query?
<Hobbsee> QG: it's either.  usually it's #ubuntu-bugs.  this channel is slightly noisy now with development talk, so the bug talk is in -bugs
<QG> hobbsee: thank you
<Hobbsee> no problem
<ogra-classmate> Keybuk: do you plan to merge initramfs-tools from debian or are we to far off for a merge ?
<ogra-classmate> (there is one fix in 0.88 i'd need in ltsp)
<cjwatson> keescook: unfortunately 6.06.1 is only really recorded in the CD builds and in a massive hardlink tree I have on drescher
<cjwatson> when Launchpad's data model is capable of capturing it, we plan to feed all that data back in somehow
<keescook> cjwatson: okay, thanks
<ubuntulover> hey all - when you install a new kernel in feisty, where does the package pull the uuid from to add to menu.lst -- its incorrect and i want to change it
<Lure> Mithrandir: can you giveback strigiapplet (now that strigi hit the repo)?
<bdmurray> ubuntulover: try using vol_id /dev/partiitonhere
<ubuntulover> bdmurray: i understand that - just when i install a new kernel it updates it with an old UUID
<ubuntulover> i migrated to a new harddrive but on every kernel install the menu.lst is all wrong
<AndyP> ubuntulover: could be the # kopt= line in menu.lst (it's commented out but update-grub still uses it)
<glatzor> bryce: thanks to the help of pitti we now have got a working apport package hook, that also submits pcitable and xorg.conf. perhaps it gets time for a new release :)
<bryce> glatzor, excellent!!
<bryce> yes I still need to finish adding the apport hook for xorg-server
<adam0509> hi, do someone knows why xorg is sooo slow on old computer (PII/PIII ans SDRam) ?
<adam0509> even with xubuntu or fluxbox... :/
<ubuntulover> are there any ubuntu scripts / packages to reconfigure that would regenerate an fstab file?
<ubuntulover> with new uuid's, etc?
<ogra-classmate> ubuntulover: a) see topic, no support here b) have a look at vol_id
<ogra-classmate> ;)
<ubuntulover> ogra-classmate: thanks! -sorry bout the topic
<rrivasdiaz> Does anybody knows if the spec NoMoreSourcePackages will be implemented? any plans?
<rrivasdiaz> I think that this specification not only will help package management, I think it has the potential to atract a lot of developers
<ogra-classmate> rrivasdiaz: thats rather an ongoing process than a spec
<rrivasdiaz> Any time I have tried to read all the information required to make a package I have ended quitting. If all this boilerplate is generated and maintained authomatically, I will be a lot easier to contribute
<rrivasdiaz> I'm a good coder with skills in C/C++ and Java. And I really want to contribute, but sadly I haven't enough time to read all the documents required to make a package, the process looks too complicated.
<rrivasdiaz> I just want to checkout something, make the changes and submit a patch. This process is well known to me. But making a debian source package is not.
<robertj> rrivasdiaz: it looks pretty dead to me
<ogra-classmate> well, but you can do the same with an existing debian source package with no problems
<ogra-classmate> apt-get source blah
<robertj> (btw, how do you run debuild without patching again?)
<ogra-classmate> cp -a blah-version blah-version,orig
<ogra-classmate> cd blah-version
<ogra-classmate> hack around
<ogra-classmate> cd ..
<ogra-classmate> diff -ruN blah-version blah-version.orig >mypatch
<ogra-classmate> attach mypatch to a bug
<ogra-classmate> rrivasdiaz: its just a different process and ends with a link to a bzr branch instead of a patch on the bug
<ogra-classmate> but it makes reviewing the patches way easier and merging as well indeed
<robertj> ogra-classmate: is there some kind of vcs-agnostic library that is in-the-works?
<rrivasdiaz> I have submited a simple patch once (for dapper), but the maintainer didn't had time to review it. It was very simple, but anyway it is not included yet. I think that using the source control will be a lot easier for the maintainers to review and include a patch
<ogra-classmate> not that i know of ... but then i'm no resident in #bzr :)
<ogra-classmate> rrivasdiaz: right and many of us already maintain a lot in bzr
<robertj> ogra-classmate: I was just thinking it might be hard to get say...svn to put their source code in bzr
<ogra-classmate> but there are a lot of packages and only so many developers
<ogra-classmate> so unless we have an automated import to launchpad for upstream or debian NMSP wont happen as a whole only where ressources arre available
<rrivasdiaz> Automatically importing from upstream, atomated testing of submited patches, a lot of new stuff could be implemented using a version control system
<robertj> is grumpy still a long-term goal?
<rrivasdiaz> orga-classmate: do you know how can I help to achieve this?
<robertj> rrivasdiaz: realistically I would think it would take man-decades to get that working
<rrivasdiaz> orga-classmate: really?? that's too bad :-(
<rrivasdiaz> orga-classmate: anyway the current scheme is too complicated for people to contribute. I have suffered the problems with today's state of managing distribution code.
<ogra-classmate> well, NMSP will happen eventually, we're working on it :)
<ogra-classmate> but dont expect it to be tomorrow ;)
<robertj> so what is the plan for non-bzr packages?
<ogra-classmate> there wont be any ?
<robertj> so the bzr packages aren't neccecerrily upstream?
<ogra-classmate> thats why the spec is called no more source packages :)
<robertj> err not packages/repos
<ogra-classmate> not if you have an importing mechanism that makes them bzr branches
<glatzor> bryce: xrandr does not seem to like xinerama :) I can break my dual screen layout on a regular basis by changing the size
<bryce> yeah
<glatzor> bryce: furthermore we are going to see a separated guidance backend very soon
* robertj clings to his single display for dear life and waits for xorg and xrandr hawtness to mature
<bryce> glatzor: excellent
<glatzor> bryce: the on screen displaying of the monitor names could be done for xinerama mode, but only in a very hackish way
<glatzor> bryce: I can get the monitor resolutions and positions from the gtk display
<glatzor> bryce: but the combination with the xorg.conf settings can only be done by guessing :/
<mathiaz> I'm trying to understand the init/rc scripts. What is the role of rcS ? Are these scripts run before any runlevel scripts ?
<cjwatson> rrivasdiaz: I don't think no-more-source-packages would really solve the problem of developers not having time to review and apply changes, anyway
<cjwatson> it might help a bit, but I think it's a mistake to view it as a magic bullet there
<rrivasdiaz> cjwatson: yep, you are right. But with this system you can have in the future an automated way of testing patches, for example. At least in Java that's very feasible and not at all dangerous.
<rrivasdiaz> cjwatson: also if with that system you can get more developers, ubuntu comunity will have more resources to test patches.
<cjwatson> (most of our code is not in Java and can only be entirely safely sandboxed by running a complete virtualised system)
<cjwatson> I'm not saying it wouldn't help, just saying it's not a panacea
<enrico> Hi.  I wanted to take small bits of libapt-pkg and reuse them in a library of mine which is LGPLed.  libapt-pkg is GPL, so I'd need to ask the devels about it.  Turns out it's more likely I'll find them here than in #debian-devel
<enrico> It mostly boils down to the pkgTagFile class in tagfile.{h,cc}
<enrico> I'd like to ship a modified version of it
<Toxicity999> rawr wvdial/pppd are not respecting my DNS choices =] 
<Toxicity999> And I said that in the wrong channel by mistake, My griping skills are highly unleet.
<rrivasdiaz> cjwatson: Anyway I think this scheme could attract more developers. Athough I work with software all the time, I still feel scared with debian source packages. And I think a lot of developers are like me. It's much easier to use a source control. So I'm all for this spec.
<rrivasdiaz> cjwatson: That's way I want to help with this. Could you tell me how can I?
<crimsun> seb128: yes, I do get said crash (hence setting to Confirmed)
<seb128> crimsun: that was not clear since you didn't comment on the bug ;) I was going to ask for a backtrace but the submitter already sent one so that's alright
<rrivasdiaz> Also the branch support in source control systems allows you to work on more complex patches. I wanted to change the way Java virtual machines are configured in ubuntu and I proposed a list of changes but no one followed me so I couldn't get support form my idea.
<crimsun> seb128: sorry, was in a rush this morning to the airport
<seb128> no problem
<cypherbios> Riddell: Hi. Do you know if KDE follows the FreeDesktop guidelines for icon names?
<rrivasdiaz> cjwatson: I wanted to develop it, but I would be a big patch and I lost interest 'cause it would be dificult for me to push this as a big patch. But if I had a way to develop in an alternate branch it could be easier for others to test it.
<cypherbios> have a standard to describe a icon for the application-x-deb mime? I'm writing a application (in gtk) which in gnome I use the icon name 'gnome-mime-application-x-deb' or just 'deb' but when in a fresh Kubuntu installation (without the gnome-icon-theme) it looks very ugly (without any icon).
<Riddell> cypherbios: KDE 3 doesn't, KDE 4 does
<Riddell> cypherbios: is this an icon for your application (e.g. in the application menu?)
<cypherbios> Riddell: No. Inside the application I show the icon of a package (a debian package, in this case) to represent each package in the treeviewlist
<Riddell> cypherbios: well if it's a gnome app then it'll load the gnome icon theme regardless of which desktop you run it under, so it should depend on the gnome icon theme
<cypherbios> Riddell: yes, that's right. But I don't want to add the gnome-icon-theme as dependency for the Kubuntu users
<cypherbios> I'd prefer to use a KDE icon instead
<Riddell> cypherbios: well /usr/share/icons/crystalsvg/32x32/mimetypes/deb.png is the KDE 3 icon, but then you'd have to depend on kdelibs to ensure that exists
<cypherbios> Riddell: but in this case I must to point the fullpath to the png file?
<cypherbios> Riddell: just to let you know the way the image is used: http://img79.imageshack.us/img79/5610/screenshotaptoncdll2.png
<Riddell> well yes, you either use the icon theme stuff and accept what the library gives you or you use a full path
<Riddell> adept has its own icon of course :)
<cypherbios> Riddell: ah sure. But as it's not installed in my computer, the application icon is showed only if the package is installed ;)
<cypherbios> Riddell: if it's not installed, then show the generic icon ('deb')
<Riddell> cypherbios: you might be able to find a lot of app icons from app-install-data
<cypherbios> Riddell: I'm trying to give the KDE users a less painful experience with aptoncd as possible
<cypherbios> Riddell: sure, I'll take a look on it.
<cypherbios> Riddell: I already removed the yelp and nautilus-cd-burn dependencies and now aptoncd checks if its exists before trying to use it (I can't find a way to replace yelp by khelpcenter to show .xml files =(
<mantiena> Hi all
<cypherbios> Riddell: sorry for bugging, but could you say if is possible with adept add a cdrom as apt source (graphically) just like synaptic does (synaptic --ask-cdrom). Currently I use synaptic to do this operation, but if adept is able to do the same I will use adept if the user is running KDE
<cypherbios> I mean, aptoncd calls synaptic this way, not me ;)
<pitti> yay changelog-closes-bugs!!!
<ion_> Its implemented now?
<LaserJock> pitti: looks like texlive-bin can be synced again
<pitti> ion_: mdz just annouced it on the list
<pitti> LaserJock: yay, did they take all our patches? nice
<LaserJock> pitti: 2007-10 closes your bug and dholbachs as well
<ion_> pitti: Rock
<pitti> LaserJock: not sure why we need the -fPIC; it sounds important
<pitti> LaserJock: if the .so is really built without -fPIC, that would be a bug
<mantiena> I don't know where I should report a bug about incorrect mapping of lt.archive.ubuntu.com (it should redirect to official Lithuanian Ubuntu mirror - ftp.litnet.lt/pub , but redirrects to some very slow, non-lithuanian server)
<glatzor> cypherbios: you can take a look at software-properties for the add-cdrom dialog
<LaserJock> pitti: dholbach's changelog indicates it was causing a FTBFS for 64bit evince 
<glatzor> cypherbios: I think that the kde port already has got a cdrom import dialog
<cypherbios> glatzor: Actually I need to do it in a single command-line call method to keep it transparent
<mantiena> this bug exists more than 2 years, maybe from the Ubuntu start and couses a lot of problems, because all Lithuanians get a mirror with ~20kb/sec speed after installation :(
<glatzor> cypherbios: you could just add a command line option to software-properties :)
<cypherbios> glatzor: The software-properties-kde have a button that does it, I'll look at the code what it calls to add a cd
<Lure> pitti: if code was just moved from main package in new library, does this simplify MIR
<pitti> LaserJock: right, it's easy to check
<Lure> pitti: I have prepared MIR anyhow: https://wiki.ubuntu.com/MainInclusionReportLibKdcraw
<pitti> Lure: it usually doesn't need an MIR at all, just a quick package review from me
<pitti> Lure: good
<Lure> pitti: ok, great 
<cypherbios> glatzor: the software-properties-gtk users synaptic to add the cd, and software-properties-kde uses what?
<glatzor> bryce: I now show a single button on every monitor that allows to move the config dialog to it. furthermore I ask the window manager to please always center the dialog. metacity now places it on the center of the screen it was launched from. but I don't know what compiz does ... :)
<glatzor> cypherbios: Sorry, I am not so familiar with the kde frontend, since I only worked on the backend and GTK frontend
<glatzor> cypherbios: but wasn't the GTK frontend using python-apt?
<cypherbios> glatzor: I think the part of adding a CD as APT source is done by Synaptic (with --ask-cdrom)
<cypherbios> it, of course, in the gtk front end -- I guess
<bryce> glatzor: good to hear it's centering, that was a big bug
<bryce> bbs (lunch)
<glatzor> cypherbios: take a look at on_button_add_cdrom_clicked in softwareproperites/gtk/SoftwarePropertiesGtk.py
<cypherbios> softwareproperties/kde/SoftwareProperties.py:707 
<cypherbios> glatzor: hum, I see. Indeed it doesn't uses synaptic as I thought
<cypherbios> glatzor: so a command-line paramether wouldn't be bad for both software-properties-{kde|gkt} --add-cdrom :)
<cypherbios> glatzor: thank you for the attention
<cypherbios> I'll use part of the code from s-p-{gtk|kde} in the implementation of this
<glatzor> cypherbios: the dialog is still a bit ugly. but I would be happy to merge a patch from you
<cypherbios> glatzor: Thanks. I'll do my best and if I have any progress I'll be glade to share it in a patch
<cjwatson> rrivasdiaz: I think it really needs an expert in the existing source package format to get it started, but you could talk to Keybuk
<rrivasdiaz> cjwatson: thanks
<cjwatson> (and I do think attracting more developers is very important; this is just one of the several things we should be doing along those lines)
<glatzor> night
<Seveas> Keybuk, poke
<tepsipakki> Seveas: any news of falcon for feisty?
<tepsipakki> s/for/which works on/
<Seveas> tepsipakki, I found a few nasty bugs so I wasn't abl to release it on Monday
<Seveas> but it's getting real close, I use it already to manage my own repo
<tepsipakki> excellent :)
<Seveas> this wekend should be doable
<tepsipakki> is it compatible with the old version?
<tepsipakki> the generated repo, that is
<tepsipakki> not that it's a big deal for me
<Seveas> it is compatible with the old pool structure 
<tepsipakki> ok, cool
<Seveas> but the config is different and the command line arguments as well (not to mention rewriting the entire core, but that's not too visible from the outside)
<tepsipakki> right, I'll just wait a few days then :)
#ubuntu-devel 2007-05-31
<ashok> hi friends
<ashok> anyone here
<mneptok> nope
<ashok> oh
<ashok> i am a new developer
<ashok> want to contribute to ubuntu
<ashok> can u help me where to start with
<mneptok> https://wiki.ubuntu.com/MOTU
<ashok> seen it
<`23meg> ashok, https://wiki.ubuntu.com/NewDeveloperProcess
<Hobbsee> hi all
<Burgundavia> hey Hobbsee
<ion_> Hi
<Hobbsee> :)
<Hobbsee> Keybuk: ping @ MOM
<pitti> Good morning
<Hobbsee> morning pitti!
<pitti> hey Hobbsee 
<viviersf> Mithrandir, ping
* Starting logfile irclogs/ubuntu-devel.log
<Mithrandir> viviersf: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
<Hobbsee> bitten by contentlessping.pl...
<viviersf> lol
<viviersf> Mithrandir, i spoke to you about uswsusp a while back and i was just wondering if it was goign to be standard on gutsy ?
<Mithrandir> viviersf: nobody has picked it up and run with it, so I would be surprised if that happens.
<viviersf> Mithrandir, okay cool thx
<Hobbsee> seriously, why cant windows software just work?  that includes labview.
<Hobbsee> grrr.
<stdin> umm, because it's windows?
<viviersf> Hobbsee, cos then you wouldnt need to buy updated versions ?
<Hobbsee> mmm. *grumbles a bit more*
<Hobbsee> i think i'm actually using a more updated version than what's on the lab computers anyway
<StevenK> viviersf, Mithrandir: I've been merging it for Gutsy, but that's about it.
<viviersf> StevenK, i know ive filed sum bugs on it with patches for you
<viviersf> StevenK, i got an issue with it when upgrading kernels :(
<StevenK> Don't suspend if you're going to boot a new kernel.
<LaserJock> Hobbsee: you working on Labview today?
<Hobbsee> LaserJock: yeah.  attempting to.  but the ppt that i was working from doesnt seem to wish to open
<Lure> Mithrandir: can you give-back strigiapplet on i386 (not sure why only i386 got old version of libstrigihtmlgui-dev)
<Mithrandir> Lure: given-back
<Lure> Mithrandir: thanks
<viviersf> StevenK, i know that :)
<hunger> I got a strange effect: I can log into my box in X, all the apps from my session start up fine. But I can not have new apps connect to the X server anymore...
<hunger> DISPLAY is set, I am running gutsy.
<hunger> Sorry... my mistake: Mounted /tmp over the X server named pipes:-)
<mitsuhiko> doko: got a second?
<cjwatson> dholbach: gnome-orca's uninstallable on the CDs because it depends on libgnome-speech3 rather than the current libgnome-speech7. I had a look at the source but the control file has weird hardcoded dependencies and I wasn't sure I could safely touch it. Could you sort it out?
<dholbach> cjwatson: sure
<cjwatson> thanks
<doko> mitsuhiko: sure
<mitsuhiko> doko: i recently encountered some problems with pycentral. really, really strange ones
<doko> bug number?
<mitsuhiko> i then contacted Piotr Oarowski who maintains my python packages in debian and he had no idea
<mitsuhiko> i haven't filed a bug because i don't have any information to offer
<mitsuhiko> the only thing i know is that it broke completely after i installed a python 3000 build
<mitsuhiko> i can file a bug if wanted, but the only thing i know is that most of the prerm scripts now break because they are unable to locate the python version
<mitsuhiko> symlink of python points to python2.5
<mitsuhiko> and also this:
<mitsuhiko> $ pycentral showdefault
<mitsuhiko> in/python2.5
<doko> pycentral showdefault is deprecated; pyversions -d should replace it
<doko> I haven't tested the support tool with python3000 yet 
<doko> where is python3000 installed?
<mitsuhiko> doko: i have removed it in the meantime
<mitsuhiko> it was in /usr/local
<mitsuhiko> doko: i know that it's deprecated, but it shouldn't fail tough
<mitsuhiko> is there some database pycentral has?
<mitsuhiko> because even reinstalling pycentral hasn't fixed the problems
<doko> no state information
<doko> ls -l /usr/bin/python ?
<mitsuhiko> lrwxrwxrwx 1 root root 18 2007-05-13 16:11 /usr/bin/python -> /usr/bin/python2.5
<mitsuhiko> (interesting permissions Oo)
<cjwatson> symlinks are always like that
<mitsuhiko> okay
<mitsuhiko> doko: also pyversions -i only shows python2.4 and python2.5 although i have python2.3 too
<mitsuhiko> alright. i have more information now
<cjwatson> lrwxrwxrwx 1 root root 9 2007-05-24 17:29 /usr/bin/python -> python2.5
<cjwatson> looks like pycentral doesn't like the /usr/bin/ on the front
<mitsuhiko> http://beta.paste.pocoo.org/show/168
<doko> mitsuhiko: you did change things manually?
<mitsuhiko> doko: i changed the python symlink a couple of times i guess
<mitsuhiko> and my python3 installation of course. but i now use that only in my local folder
<mitsuhiko> s/local/~/p3yk/
<doko> mitsuhiko: pycentral could be a more robust, but changing anything in /usr, which is not in /usr/local or /etc may break your system
<doko> so this should make it work again: ln -sf python2.5 /usr/bin/python
<mitsuhiko> doko: yeah. that works indeed
<mitsuhiko> doko: awesome. thanks :D
<jdub> Keybuk: yay, esr hot potato for you!
<Keybuk> jdub: he's been hanging out on #upstart for a few days
<Keybuk> his chkconfig thing does look useful
<highvoltage> Keybuk: just be careful, you might just end up on ELER ;)
<Keybuk> I love petunias, don't you?
<siretart> Mithrandir: there is something fishy with ffmpeg, the source is in main, but the binaries are in universe. could you please move libavcode-dev, libpostproc-dev, libavformat plus their dependencies on the respective library packages to main and give back xine-lib on all archs?
<Mithrandir> doko: your ia32-libs upload seems to be missing a replaces on ia32-libs-gtk, or it should not include libXcursor.
<doko> Mithrandir: I didn't merge that, or is this an earlier upload?
<Mithrandir> doko: hm, I thought it was you
<Mithrandir> ah, pitti is the uploaded.
<doko> heh, it's universe now :-)
<Mithrandir> uploader, even
<Mithrandir> doko: that doesn't help when it's still installed on lots of systems.
<Hobbsee> Mithrandir: yes, that was pitti.  i've been meaning to bug him about that, as it meant one of my packages ftbfs
<pitti> Mithrandir: oh, will fix
<Hobbsee> there's a few related bug reports for those packages
<pitti> siretart: ^ maybe you can incorporate this small change into your prepared upload which merges the games stuff?
<pitti> Mithrandir: so, I'll coordinate this with siretart to avoid two uploads of that huge beast in a row
<Mithrandir> pitti: sure, thanks.
<Mithrandir> I just noticed it's been like that for a few days, and getting it fixed would be good
<pitti> Mithrandir: I think we'll just fix it for good and merge ia32-libs and -gtk
<Keybuk> Hobbsee: you ping'd?
<Hobbsee> Keybuk: indeed.  
<Hobbsee> Keybuk: MOM appears not to have picekd up that i merged sword a while ago.  i've recently been notified that the new patch is not on patches.ubuntu.com.  I'm not sure where the proceedure is breaking down, but it being broken isnt so great.
<Hobbsee> and i've got no idea who to poke about it not beign on p.u.c - perhaps you could deal with it and/or pass it on?
<Keybuk> patches.ubuntu.com is MoM
<Hobbsee> point.  then it's your domain, i believe.
<Keybuk> which sword package?
<Keybuk> (full source package name)
<Hobbsee> er, sword.
<Keybuk> no such source package
<Hobbsee> it is the source package name.
<Keybuk> try again :)
<Hobbsee> it's listed on MOM as sword
<Keybuk> hmm
<Keybuk> oh
<Keybuk> it's blacklisted
* Hobbsee stops herself before trying to put "madison sword" into cmd.exe
<Hobbsee> ah right
<Keybuk> removed it from the blacklist, it'll show up soon
<Hobbsee> great :)
<Keybuk> tollef blacklisted it because it caused a sync problem
<Hobbsee> ahhh
<Hobbsee> yes, differing tarballs
<Hobbsee> one day, hopefully upstream will release a new tarball, and it can stay synced forever more.
<StevenK> Keybuk: Is MoM able to show something is blacklisted?
<Hobbsee> same to kguitar.
<Hobbsee> i just look forward to that day.
<Keybuk> StevenK: it's a general archive blacklist
<Keybuk> http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt
<StevenK> Ah
<Mithrandir> I should find some free time to nuke the top of the blacklist
<StevenK> hotplug # all hail udevd
* StevenK chuckles
<StevenK> Hah, there's one worse.
<elmo> I'm glad someone cleaned up that file before publicizing it - the version in the dak tree had err, much more interesting comments
<StevenK> elmo: Actually, you're in it with "elmo, comment lost" a little bit
<elmo> yeah, I know
<elmo> the original version of that, f.e. was:
<elmo> # old MOTU removals - use to have reasons, but I trashed the blacklist file by mistake.  go me. [JT] 
<StevenK> Muahaha
<StevenK> I'm curious about some of these much more interesting comments, though. :-)
<Mithrandir> they'
<Mithrandir> argh
<cjwatson> it is possible that we artificially lost some of those reasons
<Mithrandir> they're actually lost, not just put in revision control.
<Mithrandir> cjwatson: *cough*. :-P
<Hobbsee> haha
<Hobbsee> cjwatson: data loss bug.  totally coincidental.
<Hobbsee> and the backups failed.
<Mithrandir> we use the Linus Backup Strategy, didn't you know?
<Mithrandir> publish your stuff on an ftp site and let the world mirror it.
<zakame> lol
<cjwatson> speaking of madison, anyone fancy porting rmadison to Ubuntu? madison.php is available from debian-qa CVS, and I'm sure it could be run easily enough on rookery or somewhere else with a full mirror
<StevenK> Must it be PHP? :-)
<cjwatson> I'm no PHP fan, but it's what's there; at least it should have a compatible interface
* Keybuk thought "elmo, comment lost" was "CENSORED"
<cjwatson> rmadison already supports multiple backends
<Keybuk> there was certainly a pert turn of phrase we used in some cases
<Mithrandir> hm, what does rmadison do again?
<cjwatson> remote madison; talks to a CGI
<Mithrandir> ah, ok.
<cjwatson> debian-qa CVS> I mean svn these days
<Mithrandir> my ~/bin/madison is ssh merkel.debian.org madison "$@"
<cjwatson> ooh, there's a perl implementation
<cjwatson> I might just spend ten minutes deploying that this afternoon
<Keybuk> you have 10 minutes of CFT?  you clearly don't have enough to do <g>
<cjwatson> you just work for ten more minutes in the evening :P
<StevenK> Finally. Memory usage isn't 100%
<Keybuk> cjwatson: David knows where the circuit breakers are
<Mithrandir> Keybuk: 10 hours of battery life and neighbour with wifi. :-P
<StevenK> I have one, but not the other. Pity.
<Keybuk> my neighbours use *my* WiFI
<StevenK> Figure out which neighbours and bill them?
<Hobbsee> heh, another good removal message...
<Hobbsee> ltsp-utils # ogra wails like a girl if this gets sync'd
<lathiat> heh
<siretart> pitti: right, I think we should just merge all three of ia32-libs{,-gtk,-sdl}
<pitti> siretart: I agree; easier to maintain and update
<ogra> Hobbsee, how did you know :)
<ogra> Hobbsee, but its a) blacklisted and b) i talked to the DD who agreed to drop it from debian
<Mithrandir> ogra: Hobbsee was reciting from the sync-blacklist.
<Hobbsee> ogra: haha
<pitti> siretart: hmm, you already added some GTKish bits to your version, didn't you? does -gtk actually contain anything on top of that?
<ogra> Mithrandir, ah
<siretart> pitti: I've added the packages that where comment out in the previous version of the package
<siretart> pitti: the comment was that they were in universe. most probably some of them are in ia32-libs-gtk as well
<pitti> siretart: ah, ok; do you feel like merging -gtk, too, or do you want to send me your current patch and I finish it for -gtk?
<siretart> pitti: If you have time now, I'd prefer to send you my patch
<siretart> (/me at work now and has to fight a lot with perl :/)
<pitti> siretart: not now, probably on Monday
<siretart> ah, ok. 
<pitti> siretart: tomorrow might work too if archive stuff doesn't keep me busy all the day
<siretart> so either I find the time tomorrow or I'll send you the patch
<pitti> siretart: good luck with Perl :)
<pitti> siretart: so, if you can send me the patch, then I'll look into it ASAP unless you IRC-ping me about it and beat me to it
<siretart> pitti: you said that running fetch-source.sh with BUILD=0 was okay, right?
<pitti> siretart: fetch-and-build.sh, yes
<siretart> err, yes. okay
<pitti> siretart: those are perfectly valid buildd generated .debs, so I don't see a reason to not use them
<siretart> okay
<siretart> I'll add a note to the readme about that
<Keybuk> cjwatson: http://merges.ubuntu.com/stats.txt
<StevenK> Keybuk: Should you comment out events that fall off the front of the graph like Edgy Release and Edgy's archive being open?
<Mithrandir> the code should remove them, IMO
<fabbione> Seveas: ping?
<fabbione> so it is safe to upgrade gutsy with the new lvm/raid stuff?
<fabbione> or can i expect the world to explode?
<cjwatson> $ scripts/rmadison.pl -u ubuntu -s gutsy -c main -a i386 man-db man-db |    2.4.4-3 |         gutsy | i386
<cjwatson> excellent
<cjwatson> (ignoring stupid irssi line-wrapping; anyone know how to turn that off?)
<cjwatson> $ scripts/rmadison.pl -u ubuntu -s gutsy -c main -a i386 man-db
<cjwatson>     man-db |    2.4.4-3 |         gutsy | i386
<cjwatson> better; /set paste_join_multiline off
<StevenK> cjwatson: Oh neat. I've been wondering how to stop irssi doing that.
<StevenK> cjwatson: How many lines is rmadison.pl ?
<cjwatson> 233
<pitti> mjg59: can we trade merges? I'd like to avoid breaking laptop-mode-tools and hand this off to you, and in return grab dhcdbd from you
<Hobbsee> mergebay again!
<pitti> yay
<Lure> pitti: if you can let exiv2 and libkdcraw past binary NEW it would make new digikam build ;-)
<pitti> Lure: looking
<Lure> pitti: thanks
<pitti> Lure: there's no exiv2 in NEW
<pitti> neither is kdcraw
<pitti>      exiv2 |     0.14-1 |         gutsy | source
<pitti>      exiv2 |     0.14-1 | gutsy/universe | amd64, i386, ia64, powerpc, sparc
<seb128> pitti: I accepted them before lunch, why?
<pitti> looks current
<pitti> seb128: ah :)
<pitti> seb128: because Lure asked
<seb128> ah, k
<elmo> why does our tzdata package ask me questions  in it's postinst ?
<elmo> like, not even with debconf
<pitti> elmo: erm, it's not supposed to; we fixed the debconfishness right at the beginning of gutsy 
<pitti> elmo: what does it ask?
<elmo> pitti: ok, this is feisty
<elmo> Your current time zone is set to Unknown
<elmo> Do you want to change that? [n] :
<pitti> elmo: right, it didn't have any debconf stuff in feisty yet
<fabbione> if [ "$USER" = "*elmo*" ] ; then debconf_ask_random_question; fi
<elmo> pitti: ok, as long as it'll go away at some point
<pitti> elmo: is that true? I. e. did you really not have a TZ set before? or is that an upgrade bug?
<elmo> pitti: it's a chroot
<elmo> pitti:  I probably didn't have a TZ set
<pitti> ah, I see
<elmo> (ronne's feisty-amd64 chroot to be precise)
<pitti> elmo: in gutsy that's properly debconfified now
<elmo> cool
<Lure> pitti: sorry, seb128 was too fast
<Lure> pitti: so libkdcraw is fine for main inclusion?
<pitti> Lure: I didn't look at it yet
* StevenK waits for exiv2 to hit archive.u.c
<StevenK> (I need to upload a build1 of a rdepends)
* Lure waits for libkdcraw to hit main ;-)
<Lure> StevenK: great - I was just preparing the list for Riddell ;-)
<StevenK> Lure: And what did main ever do to it?
<StevenK> I didn't think that was much that depends on exiv2
<pitti> BenC: FYI, I don't NEW the new kernel as long as it's FTBFS on powerpc, to avoid unnecessary ABI bumps in case the powerpc build fix needs to change ABI
<BenC> pitti: sure things, I have another upload ready
<pitti> BenC: oh, good morning. Early bird :)
<fabbione> hey BenC 
<fabbione> BenC: upload? please pull the gfs2 stuff from kernel.org pretty please?
<fabbione> BenC: and add the 3 extra symbols?
<fabbione> BenC: and re-enable gfs1? :P
<fabbione> (don't pull from my tree.. it's borked)
<BenC> fabbione: I'll see what I can do, I didn't want to have to go through another round of build/boot tests...but for you, I might :)
<fabbione> BenC: ok.. if it's not this one, can you please make sure it's queued for the next?
<fabbione> BenC: i can't build userland without the new headers
<BenC> definitely
<fabbione> and i need to start doing some QA on that stuff before we find that the world crashes 2 days before release
<BenC> need to get some coffee, just rolled out of bed
<fabbione> ehhe
<fabbione> enjoy
<pitti> yay Priority: headers! /me hugs cjwatson; gutsy debootstrap works again
<cjwatson> yeah, it's healthier now
<dholbach> MOTU Q&A session in 3 minutes in #ubuntu-classroom
<fabbione> Keybuk: ping?
<fabbione>  /etc/udev/rules.d/75-persistent-net-generator.rules <- rewriting config files, isn't that a policy violation?
<Keybuk> no
<Keybuk> rewriting conffiles is a policy violation
<ogra> conffiles is :)
<Keybuk> rewriting config files is entirely valid <g>
<ogra> even though the definition in the policy is not very precise there, i often have that discussion with DDs as well
<fabbione> anyway that script is buggy...
<fabbione> a lot :)
<fabbione> it's breaking my decnet setup...
<fabbione> how can i live without decnet ?
<fabbione> :P
<Keybuk> hmm?
<Keybuk> what's the bug?
<fabbione> Keybuk:  i am kidding.. it's not serious..
<Keybuk> it's an upstream script, so we should probably fix it if it's broken for something
<fabbione> decnet protocol changes mac address on the interface in a very consistent way to define the "node address" (similar to the ip address)
<fabbione> that creates 2 entries in the rules
<nosrednaekim> hello,does anyone know what language the restricted manager is written in? I would like to port it to kubuntu
<fabbione> and the interface that was named eth0 all of a sudden becomes eth1
<fabbione> decnet setup can break and so does the ip because there might be no entry for eth1 in interfaces
<Keybuk> fabbione: they're named eth* ?
<fabbione> decnet breaks because you can specify what interface to use
<ion_> nosrednaekim: Python, and its core functionality is separate from the UI, so it should be somewhat trivial.
<fabbione> Keybuk: yes..
<Riddell> nosrednaekim: we already have someone working on that
<nosrednaekim> ion_: cool, I know Python!
<fabbione> Keybuk: there is no reason to change iface name.. just the mac address
<Keybuk> fabbione: we can add a rule to skip the script if we know a little more about it
<nosrednaekim> Riddell: great minds think alike.. oh well
<Riddell> nosrednaekim: although there are other programmes to be ported if you feel the urge
<fabbione> Keybuk: second.. let me gather enough info...
<Keybuk> or we can add decnet support to the script
<nosrednaekim> Riddell: ok,like what? I really only know python
<fabbione> Keybuk: dnet-common or dnet-progs use /etc/default/decnet.
<fabbione> Keybuk: in that file there is: DNET_INTERFACES=""
<Riddell> nosrednaekim: ltsp-manager for example https://wiki.kubuntu.org/EdubuntuKDE
<fabbione> if empty .. decnet won't run
<Keybuk> fabbione: oh, it's a software thing and not a kernel thing?
<fabbione> all = get all interfaces in decnet mode/mac
<fabbione> nope.. it's all userland.. well the part that interest us at least
<fabbione> or a list of iface/ifaces
<Keybuk> so you can do decnet on any ethernet card?
<fabbione> yes
<fabbione> it's enough you can change the mac address
<fabbione> i am no decnet expert.. really. what i found was by mistake
<fabbione> i thought it was worth mentioning it
<Keybuk> I'll raise it upstream :)
<fabbione> there might be other protocols doing stuff like this
<fabbione> yup.. fair enough..
<Keybuk> best fix would be to identify the cards participating in decnet by some other means than their mac address
<fabbione> well you have that config file
<fabbione> and the initscript for decnet to look at
<Keybuk> that config file takes interface names <g>
<Keybuk> which aren't stable unless you have this config file
<fabbione> right...
<Keybuk> which would change the names assigned by that config file
<Keybuk> chicken
<Keybuk> egg
<Keybuk> cluck
<fabbione> bzzzt
<fabbione> no.. they solved that problem a while ago
<nosrednaekim> Riddell: I was also thinking about adding a wattmeter to guidance-power-manager
<fabbione>  /. for it
<Keybuk> hmm
<fabbione> :)
<Keybuk> you use decnet?
<fabbione> not yet.. i installed the packages to do some testing
<Keybuk> unless I'm mistaken here (tracking workflow)
<Keybuk> this will work just fine
<Keybuk> 1) kernel adds network interface
<Keybuk> 2) udev renames it according to its hardware mac address
<Keybuk> 3) decnet picks up interface from DNET_INTERFACES according to its udev-fixed name
<fabbione> yes...
<Keybuk> 4) decnet changes mac address
<Keybuk> udev won't change the name again, because it's already set
<Keybuk> that's what the NAME!="?*" thing is for
<fabbione> 5) network manager takes down the interface and reset it...
<cjwatson> ooh, ooh, debmake is up for demotion since dmapi stopped using it
<Keybuk> fabbione: network manager only downs the interface
<Riddell> nosrednaekim: interesting idea, although I do wonder if the best place for it is ksysguard
<cjwatson> *clicketyclick*
<Keybuk> it doesn't pull out the card
<fabbione> 6) udev picks an up/down and rename it
<Riddell> nosrednaekim: but I'm sure if you did that we'd include it
<StevenK> cjwatson: Yay!
<Keybuk> no, udev picks up hardware insertion/removal
<Keybuk> not interface config changes
<Keybuk> that's HAL-land
<fabbione> Keybuk: well something is renaming it and once i cleaned the 70*.rule i got my eth0 back
<Keybuk> you'd have a suspend/resume issue, since the hardware does get removed and re-inserted
<fabbione> [   51.927759]  skge eth0: addr 00:13:d4:85:0f:a4
<fabbione> [   90.967360]  skge eth1: enabling interface
<fabbione> notice this in dmesg
<fabbione> 39 seconds in between
<fabbione> this is a clean boot
<Keybuk> but after the resume, the card would have its hardware mac again, so you'd need to reapply dnet again
<Keybuk> sure
<Keybuk> it'll get renamed to a persistent name
<Keybuk> that just means that last time you booted, some other card had eth0
<nosrednaekim> Riddell: it only works on very new machines which have acpi 2, but I have the python framework which prints out the readings to the command line. If you are interested
<Keybuk> so that card is "eth1", and should be referred to as such in DNET_INTERFACES
<Keybuk> it won't get renamed after dnet tarts
<fabbione> in the rule file I had eth0 with the decnet mac address
<fabbione> and eth1 with the real address
<Keybuk> rule file?
<Keybuk> oh
<fabbione> the 70-generated...
<Keybuk> that probably *is* a postinst bug
<Keybuk> in that the postinst ran while you were using decnet, and seeded the initial copy of the file
<fabbione> oooooo...
<Keybuk> that's just a temporary hack anyway
<fabbione> yeps.. ok.. then we are at the same page
<Keybuk> I meant to copy iftab in, and let the others fix at reboot time
<fabbione> ok.because i had iftab.. and it was ignored
<Keybuk> but didn't get around to fully testing the perl, so went with the hack for now
<fabbione> ok..
<fabbione> fair enough
<fabbione> at the next update i will see how it explodes :)
<Keybuk> the actual proper udev rule stuff shouldn't break
<Keybuk> if you rmmod and insmod the module, the software mac address will be forgotten anyway
<fabbione> i will test that at the next reboot
<fabbione> yes and that's fine..
<Keybuk> interestingly, dnet should probably have a udev rule to run every time a network interface is inserted, no? :p
<fabbione> Keybuk: sounds like a good idea...
* fabbione reports the bug to one decnet upstream
<pitti> Mithrandir: can you please give-back hplip?
<Mithrandir> pitti: backgegubt.
<pitti> :)
<Lure> nosrednaekim: does it get info through HAL? we would not like to add too many interfaces beside HAL to it...
<Lure> nosrednaekim: and you may want to join #kubuntu-devel
<nosrednaekim> Lure: will do.
<nosrednaekim> Lure: sent you a message over there
<dholbach>  dpkg-source -b libgdamm3.0-2.9.5
<dholbach> Undefined subroutine &main::warn called at /usr/bin/dpkg-source line 349.
<dholbach> debuild: fatal error at line 1239:
<dholbach> ^- anybody had that problem too?
<pitti> dholbach: I suspect it's from yesterday's dpkg merge
<dholbach> hrm
<pitti> dholbach: that looks like a function that my Mainainer: check calls
<dholbach> right
<StevenK> pitti: use Carp instead?
<StevenK> I love doing use Carp; cluck("");
<pitti> StevenK: I don't know; the previous dpkg had that function
<StevenK> pitti: Bug iwj where it went?
<pitti> looks like a simple s/warn/warning/
<pitti> dholbach, iwj: I'll fix it
* dholbach hugs pitti
<dholbach> you ROCK
<dholbach> ...but you know that already
* pitti hugs dholback
<kwwii> dholbach: the way things are now, to use the automaticartworkbuilder and artist needs to take an existing theme (like oransoda) and edit everything yet some things are pretty technical (like oransun-look.sh)...is there a way to remove parts of the theme without borking everything?
<kwwii> dholbach: btw, I am working on the documentation for that stuff :-)
<dholbach> kwwii: I read that you were working on that and was very pleased
<dholbach> kwwii: what about example-theme?
<robertj> hrmm patch 98_automake from gnome-system-tools won't revert...is that considered a bug?
<kwwii> dholbach: well, it means that I'll be asking you lots of questions :p (and I could not find the example-theme package on launchpad)
<dholbach> kwwii: http://code.launchpad.net/example-look
<kwwii> lol, that is easy
<kwwii> well "devel(+n)]  [Act: 2,4,5,7,8] 
<kwwii> oops
<kwwii> bzr: ERROR: Not a branch: https://code.launchpad.net/example-look/
<kwwii> ok, I get it, sorry
<ogra> oooh, someone fixed jadetex, my pbuilder works
* ogra dances
<pitti> dholbach: do you already know whether the -fPIC fix to texlive-bin was really necessary or just a fallout from the missing dependencies? I. e. did you get the same FTBFS locally?
<pitti> dholbach: Debian applied all other changes, this is the only one left
<dholbach> pitti: sorry, I didn't try it yet - let me try
<cjwatson> stgraber: I'm just reading over https://wiki.ubuntu.com/IsoTestTracker
<iwj> Oh, no wonder I'm so sleepy.  I have forgotten to drink any coffee today.
<cjwatson> stgraber: my biggest concern at the moment is providing a way for release managers to sign off on problems, so that we can look through at the end and say "yes, all these problems have been noted but we're not concerned about them for release" or "oh dear, this problem is a blocker although these other 17 aren't"
<cjwatson> stgraber: do you think that's something that could be added? I'd be willing to approve the spec with that addition
<cjwatson> heno: ^--
<elmo> cjwatson: so, I'm installing windows and it's playing music, like an actual song at me - when's ubiquity getting that feature? :-P
<seb128> elmo: you have a full desktop you can use while ubiquity is running ;)
<StevenK> elmo: When you run Rhythmbox while installing? :-)
<seb128> that includes totem and rhythmbox ;)
<robertj> elmo: after sitting through Apple's introductory song 100 times, hopefully never
<pitti> elmo: Around the same time when ubiquity is ported to beryl, I think
<robertj> (10.2 had the best one)
<kylem> pitti, woah, that's a fantastic idea.
* evand runs away screaming
<cjwatson> elmo: there's a really old community spec for that ...
<pitti> kylem: we totally need 3D shuffling in the partitioner
<kylem> pitti, when it's finished, the installer window could catch fire!
<robertj> pitti: and multiple-cursor support
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/music-while-installing
<StevenK> pitti: That's about the only place I can see beryl being useful.
<dholbach> ubiquity-sudoku-integration
<siretart> imagine burning windows as metaphor for segfaulting applications.. brrr
<robertj> StevenK: nahh, you just have to think about watching all the document icons fly from one drive to another during user migration ;)
<cjwatson> bryce: any progress on the X spec changes I asked for? the deadline is today
<dholbach> pitti: seems we can sync texlive-bin again
<dholbach> pitti: thanks for prodding me again
<pitti> dholbach: hm, so is the .so still built with -fPIC? if not, that'd be a bug
<dholbach> the real bug seems to have been the missing depends
<ogra> gah, g-p-m moved all hal code away, crap
<pitti> dholbach: ah, yes, it is
<pitti> dholbach: so I guess you tried adding -fPIC and it succeeded because you had libkpathsea4 installed
<dholbach> pitti: yes, that must have been it
<pitti> dholbach: I just checked http://buildd.debian.org/fetch.cgi?pkg=texlive-bin;ver=2007-10;arch=amd64;stamp=1180550786
<pitti> dholbach: kpathsea uses -fPIC, so all is well
* pitti syncs
<dholbach> yoooho
<pitti> dholbach: thanks for checking!
<dholbach> np
<hjmf> hi pitti 
<hjmf> Just read your email 'Collection of useless top functions in Apport stack traces'
<hjmf> what I usually do are *mozilla retraces* so I look for the string '<signal handler called>' and the next 9 - 10 stacks
<pitti> hey hjmf 
<hjmf> last examples of it are bug 117951 home-retraced and bug 117827 from apport retracing service output
<ubotu> Launchpad bug 117951 in firefox "[FEISTY]  firefox crashed [@IM_get_input_context]  [@nsWindow::IMELoseFocus]  (dup-of: 85627)" [High,Needs info]  https://launchpad.net/bugs/117951
<ubotu> Launchpad bug 85627 in firefox "MASTER firefox crash [@ IM_get_input_context] " [High,Needs info]  https://launchpad.net/bugs/85627
<ubotu> Launchpad bug 117827 in firefox "firefox crashed [@??]  [@~nsCOMPtr_base]  [@nsSoftwareUpdate::InstallJarCallBack] " [High,Needs info]  https://launchpad.net/bugs/117827
<pitti> hjmf: thanks; you were one of the key persons ;)
<hjmf> :)
<hjmf> If you want I can email the related functions I use
<pitti> hjmf: that would be very helpful indeed
<hjmf> are for personal use thoug
<hjmf> pitti: Ok then, I'll translate the comments, and I'll email you
<pitti> hjmf: hm, how do you mean 'personal use'? I shouldn't put them into apport (or a .d directory which packages fill themselves or so)?
<pitti> hjmf: thanks a lot!
<hjmf> oh, I meant by that that was coded w/o to much care :)
<pitti> hjmf: oh, I only need the function names and patterns, no code
<pitti> hjmf: <signal handler called> is indeed very common, if I can rely on that for Mozilla, that would be sufficient
<cjwatson> seb128: what are we going to do about desktop-volumes-representation? I assume you saw my comments on it
<hjmf> pitti: it mozilla it is common for almost all the retraces, so that's all I guess
<pitti> indeed
<hjmf> pitti: what I do is check for that string and then the next 10 sacks, 
<pitti> hjmf: this <signal handler called> is certainly something that should be in apport itself rather than a package specific pattern file
<heno> cjwatson: that was the intention with marking a bug as 'Serious'. The release manager can change the seriousness of a bug and only keep the release blockers at 'Serious'. In practice it wasn't used that way, so I can see the case for adding another knob.I'll do that now.
<hjmf> if the string is not indeed the just pick up the first 10 stacks :)
<pitti> hjmf: My idea was to unwind Stacktrace down to that line and then generate StacktraceTop starting from that; that should give us what we want wrt. https://wiki.ubuntu.com/ApportCrashDuplicates
<pitti> hjmf: yep, same approach here :)
<hjmf> ah OK, the for mozilla will be OK :)
<hjmf> the/then
<mjg59> pitti: Sure
<pitti> hjmf: also, I made various improvements to the retracer and the ddeb archive now, let's hope that the auto retraces are much less crappy in the future
<pitti> mjg59: thanks, I'll appreciate
<hjmf> pitti: good! 
<hjmf> pitti: bye then :)
<seb128> cjwatson: yes I read your comment, I've updated the implementation part to list only the things we want to do (ie, not change ubiquity nor gparted)
<pitti> hjmf: bye, and thanks a lot
<hjmf> pitti: yw
<cjwatson> heno: thanks, yeah, I don't think the seriousness knob worked all that well partly because some of the people who should have been able to set it had no idea how to. :)
<Mithrandir> heno: I'm looking at the mobile-onscreen-keyboard spec.  The mockups there are meant as examples, not necessarily what we will want to end up with?
<heno> Mithrandir: examples of what is possible, yes
<heno> I should make that clear in the spec
<Mithrandir> heno: yes, that would be good, since it's very easy to look at the screenshots and go "I like this"/"I don't like this" and think the screenshots are binding for the spec.
<heno> Mithrandir: agree. done.
<cjwatson> heno: looking at installer-for-windows; do you think wubi could be taught to use the CD as an alternative to loop-mounting the install image?
<heno> cjwatson: you mean run from the CD or make an ISO image in Windows first?
<cjwatson> heno: either, but run from the CD seems more efficient?
<heno> it has been raised, certainly saves a download
<cjwatson> and we know we can boot Ubuntu from the CD :-)
<cjwatson> in fact, it's clear this is doable; why don't I just go ahead and change it
<heno> cjwatson: I'm sure Wubi could be taught to do one of those
<heno> cjwatson: please do
<Mithrandir> heno: do we know who'll implement the mobile onscreen keyboard?
<heno> Mithrandir: Chris Jones (the maintainer) has said he'll work on it after his exams
<heno> Mithrandir: being a community contribution, it's not guaranteed of course
<heno> (nor is anything really)
<cjwatson> mdz: could you re-review installer-for-windows? I've addressed your comments
<mdz> cjwatson: could you send me email so I remember after the meeting?
<cjwatson> mdz: will the mail from LP do?
<mdz> cjwatson: yes, if I haven't received it yet
<mdz> yep, just came in
<Mithrandir> pitti: but, esc is just, esc?
<pitti> Mithrandir: vim user :)
<pitti> Mithrandir: I told my keyboard to swap esc and caps lock
<Mithrandir> then make esc a compose key. :-P
<pitti> (which is why I screw up on pretty much every other keyboard I sit at :) )
<ogra> pitti, gpm-button.c:329: error: 'udi' undeclared (first use in this function)
<ogra> do you know if there is something in hal now that provides udi ?
<pitti> ogra: no idea, there's too little context for me; however, that looks like a local variable
<ogra> seems all hal related code was moved out of gpm now ....
<pitti> thus nothing to do with hal
<BenC> offtopic> Anyone know a video/audio encoder that actually _uses_ threads for multicore/smp systems?
<BenC> converting videos for my blackberry, and it seems a real waste of hw to do it on a 8-way 2.6ghz xeon and only have it use one thread
<kylem> multithreaded codecs are difficult, i don't know of one offhand.
<ogra> pitti, gah, silly me, it was from one of our patches
<BenC> supposedly xvid does it, but it doesn't seem to be working
<BenC> maybe mencoder isn't using the API right
<pitti> BenC: hm, maybe just convert 8 videos in parallel?
<bryce> cjwatson: re X spec changes, yes I have some further info to add; I'll get it finished up today
<BenC> pitti: I'm going dvd->mpeg4/mp3, so the dvd extraction is the thread bottle neck for that
<BenC> not sure why I'm so worried about it, since it only takes 20-30 minutes to convert in in single thread, but I just hate seeing it go to waste :)
<bryce> cjwatson: same with the bulletproofX spec; I have some code for that too
<cjwatson> bryce: ok, please let me know when you're done and I'll look over it again
<bryce> ok great
<Seveas> fabbione, pong
<Seveas> Keybuk, I spec-i-fied the usplash design yesterday
<Seveas> ah, you approved it already (just reading mail), gracias!
<nnonix> Please excuse the OT question, but what do you guys think of the Dell E1505n notebook?
<nnonix> I'm considering it due to the dell/ubuntu deal.
<bryce> nnonix: I ordered the E1505n.  Scheduled to arrive tomorrow :-)
<xivulon> Keybuk are you around?
<Keybuk> xivulon: yup, what's up?
<xivulon> hi I am ago
<xivulon> One of Wubi devs
<xivulon> I had a conversation with cjwatson and he referred me to you
<xivulon> www.wubi-installer.org
<Keybuk> ok ...
<xivulon> Some of the functionality of wubi will be incorporated into gutsy
<xivulon> At the moment there is a problem in the shutdown sequence
<xivulon> https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/87763
<ubotu> Launchpad bug 87763 in sysvinit "killall5 in /etc/init.d/sendsigs should not kill ntfs-3g and other fuse filesystems" [Wishlist,Confirmed]  
<xivulon> colin mentioned that it could be addressed via session support
<xivulon> and that is how your name came about
<xivulon> I just heard about session support today
<xivulon> I had a very nasty hack to go around the problem and would like to use a proper one
<Seveas> I sent keybuk a patch for killall5 -x, could be useful as well xivulon :)
<xivulon> Seveas will that address the bug above?
<Seveas> (-x for excluding pid's)
<Seveas> xivulon, it helps
<xivulon> nice
<Seveas> I need it for usplash :)
<xivulon> so I'd need to patch sendigs so that it finds processes that rely on fuse and add pass them -x
<xivulon> How does session support come into the picture?
<Seveas> I don't know what cjwatson had in mind
<Seveas> probably something better, since this is a hack :)
<Keybuk> I don't know what cjwatson had in mind either
<Keybuk> but excluding processes from killall is trivial, since it's just a for() loop :p
<xivulon> <cjwatson> sure, though it doesn't sound to me like sendsigs itself should be changed at all
<Seveas> kylem, shouldn't filsystems (except /) already be unmounted before sendsigs is called?
<xivulon> <cjwatson> perhaps it would be better to get the fuse processes into the same session as sendsigs
<Seveas> err, Keybuk*
<xivulon> <cjwatson> the session support is there to make that kind of thing unnecessary
<Seveas> xivulon, I'm not sure that is true
<Seveas> ah, it is
<Seveas> that would indeed help
<xivulon> Could you explain pls?
<xivulon> I know nothing about session support
<Seveas> apt-get source sysvinit, read src/killall5.c, line 639-646
<Seveas> actually, those line numbers may be off
<xivulon> Not on a ubuntu machine atm
<xivulon> Will have a look toonight
<Seveas> 611-613
<Keybuk> Colin is clearly barmy
<Seveas>         for (p = plist; p; p = p->next)
<Seveas>                 if (p->pid != pid && p->sid != sid && !p->kernel)
<Seveas>                         kill(p->pid, sig);
* Keybuk throws the complete Stevens set at him to learn about sessions
<Keybuk> the only way for killall and fuse/ntfs-3g to be in the same session is for them to have been spawned by the same process
<Seveas> ah
<Keybuk> that code is literally just there to stop killall killing the shell that ran it
<Keybuk> (or the shell script that it's running from)
<Seveas> ah, setsid isn't used to set the sid but to create new ones
<xivulon> So I guess that -x is my best shot
<Keybuk> right
<Keybuk> setsid() creates a new session, with the sid equal to your pid
<Seveas> bummer
<Keybuk> it also creates a new process group (pgrpid == sid)
<Keybuk> and your process becomes the leader of that process group
<Keybuk> (which is to do with terminals and stuff, mostly)
<Seveas> Keybuk, what is this stevens set you talk about? Useful programming books?
<Seveas> http://www.computerboek.nl/boekeninfo.asp?CODE=nhqmmncqbqihr&RefererID=NHP_int
<Seveas> looks useful :)
<glatzor> mpt: I redesigned the dialog and just wrote an email to the ubuntu-dekstop list
<Keybuk> W. Richard Stevens
<Keybuk> Advance Programming in the UNIX Environment
<Keybuk> UNIX Network Programming vol 1 + 2
<Keybuk> TCP/IP Illustrated
<Keybuk> those four books are pretty much essential bibles for programming
<Keybuk> they're also very useful for reaching high shelves
<Seveas> yeah, found them all
<Seveas> ordering the first one now
<Keybuk> I've not seen the Rago re-work of APUE yet
<cypherbios> glatzor: I made a small patch to software-properties adding the --add-cdrom command-line call method
<glatzor> oh cool cypherbios
<cypherbios> glatzor: I'll work on a --hide-main-window later
<cypherbios> glatzor: it works for both -gtk and -kde
<Riddell> cypherbios: how does it work under kde?
<cypherbios> Riddell: it's just a small path that add the parser option --add-cdrom, which call the on_button_add_cdrom_clicked()
<glatzor> Riddell: you wrote the KDE frontend :)
<Riddell> cypherbios: that button doesn't do anything on the kde frontend, since we don't have a gui way to add CDs
<cypherbios> :)
<glatzor> cypherbios: how do you plan to detect the correct frontend?
<cypherbios> Riddell: yes, we have a KDE gui for add cds
<cypherbios> Riddell: you made the GUI :)
<cjwatson> Keybuk: heh, ok
<cjwatson> Keybuk: I think I must have thought that init had its own session that got used for init scripts or something
<cjwatson> although this doesn't stand up to the cold light of day
<bryce> cjwatson: ok this one is ready to go:  https://wiki.ubuntu.com/Xorg7%2e3Integration
<cypherbios> glatzor: I didn't take a look how to detect yet. But I plan to check if the software-properties-gtk is installed first, if yes use it (software-properties-gtk --hide-main-window --add-cdrom) if isn't installed use the -kde version instead
<cjwatson> Seveas: sendsigs is called before umountfs and umountroot
<Keybuk> cjwatson: sysvinit gives each entry in inittab a new session
<Keybuk> upstart gives each job a new session
<Riddell> cypherbios: does it work for you?
<cjwatson> which is pretty much required since you need to kill off processes that might have things open on those fses
<Keybuk> Seveas: since otherwise you can't unmount /usr cause processes are using it
<cjwatson> it's just a bit unfortunate for userspace filesystems, which need to be excluded
<cypherbios> Riddell: in the s-p-kde you have the button 'Add CDROM' right?
<cjwatson> would it be possible to identify processes that are implementing userspace mounts at the killall5 level
<cjwatson> ?
<cjwatson> I don't really like the idea of having sendsigs have to go round identifying those processes
<Keybuk> dunno
<Keybuk> I don't think it shows up anywhere
<Riddell> cypherbios: yes
<Seveas> Evrrything's possible, identifying them in sendsigs seems easier though
<cypherbios> Riddell: in the third-party software tab
<Keybuk> it's not as if there's something as elegant as a pid in /proc/mounts
<Riddell> cypherbios: it doesn't seem to work adding a dapper CD
<Keybuk> (cause that'd be useful)
<Keybuk> there might be something in /proc/fuse, if such a thing exists
<Seveas> fuser /dev/fuse
<cypherbios> Riddell: so what my patch does is just add a call method (--add-cdrom) tho use s-p-{kde|gtk} to call the function def on_button_add_cdrom_clicked()
<Seveas> gives you the pids of fuse things
<Keybuk> Seveas: relying on fuser scares me
<Keybuk> since you can have two /dev/fuse
<ogra> not with our udev rule
<ogra> (but indeed that might change)
<Seveas> lsof | grep /dev/fuse any better? (don't know much about how either works) 
<Keybuk> ogra: cp /dev/fuse /tmp
<Keybuk> Seveas: same problem
<Keybuk> cp -a
<cypherbios> Riddell: What the s-p does is just use python-apt to add the repository-medium as apt source, so the GUI for doing this doesn't matter, I think the GUI just show a progress dialog (gtk or qt) showing the progress and asking for a medium
<Seveas> grep /usr/lib/libfuse.so /proc/*/maps
<ogra> Keybuk, heh, right, didnt think of that
<Keybuk> oh,
<Keybuk> there's a fuse filesystem
<ogra> yep
<ogra> since recently
<ogra> pre last upload to feisty brought it
<Keybuk> it bogusly wants to mount under /sys though
<Keybuk> tsk
<Keybuk> don't suppose anyone has active fuse mounts right now?
<ogra> i can create one in a second
<Seveas> I have
<Seveas> sshfs#blackbird:/tmp on /home/dennis/p type fuse (rw,nosuid,nodev,max_read=65536,user=dennis)
<Riddell> cypherbios: ok, still doesn't work for me though
<Riddell> but that's my problem
<ogra> ltspfs /tmp/.ogra2-ltspfs/edubuntu fuse rw,nosuid,nodev,user_id=1002,group_id=1002 0 0
<Keybuk> Seveas: could you try for me
<Keybuk> mount -t fusectl none /sys/fs/fuse/connections
<Keybuk> and then look in that directory
<Riddell> glatzor: I still think s-p should include commercial and backports
<ogra> Keybuk, that dir should be there if the module is loaded
<Seveas> mount failed indeed, it existed 
<Seveas> nothing useful though
<ogra> Keybuk, but by nature for fuse you cant rely on being able to read the subdir contents
<cypherbios> Riddell: actually I didn't tried the Add CDROM option of software-properties. Until now I've just used the synaptic --ask-cdrom to do it graphically
<ogra> s/for/of/
<Riddell> cypherbios: yeah, that's the one we're missing (in adept)
<glatzor> Riddell: it already includes backports and if commercial is added to the third party tab is not my decision.
<Seveas> root@mirage:~# ls /sys/fs/fuse/connections/
<Seveas> 1
<Seveas> root@mirage:~# cat /sys/fs/fuse/connections/1/*
<Seveas> cat: /sys/fs/fuse/connections/1/abort: Invalid argument
<Seveas> 0
<glatzor> cypherbios: if there is a problem, it is a bug
<Seveas> (the 0 is the contents of a file called waiting)
<Riddell> glatzor: where does it include backports?
<glatzor> Or does it not?
<glatzor> Riddell: i have to check :)
<glatzor> Riddell: "Not supported updates (feisty-updates)"
<cypherbios> glatzor: I have a lot of repository CDs and DVDs here, I'll test the s-p Add CDROM function and see what happens, but I think it works
<glatzor> (feisty-backports)
<ogra> Seveas, 
<ogra> ogra@laptop:~/packages/gnome-power-manager-2.19.2$ mount |grep fuse
<ogra> ltspfs on /tmp/.ogra2-ltspfs/edubuntu type fuse (rw,nosuid,nodev,user=ogra2)
<ogra> ogra@laptop:~/packages/gnome-power-manager-2.19.2$ sudo ls /tmp/.ogra2-ltspfs/edubuntu
<ogra> ls: /tmp/.ogra2-ltspfs/edubuntu: Permission denied
<glatzor> Riddell: it is on the updates tab
<ogra> fuse has some weird features :)
<Seveas> ogra, I know
<cypherbios> Riddell: what doesn't work for you when adding a CD with s-p-kde?
<Seveas> ogra, I implemented my own fuse fs once, wrapping gnomevfs. Didn't really work
<Riddell> cypherbios: progress dialogue just sits there doing nothing
<glatzor> Riddell: Canonical only has to add their disabled apt line somewhere in the sources.list with a comment and it would show up.
<Keybuk> ogra: why can't you guarantee it?
<glatzor> Riddell: I even bloged about this some days ago.
<Seveas> Keybuk, because the userland fs implementation can do what it wants
<ogra> Keybuk, sorry i was misled, i thought the Permission denied issue for rrot also applies to the sysfs data
<ogra> *root
<cypherbios> Riddell: you are trying using the alternate ubuntu cd?
<Keybuk> sure
<Riddell> glatzor: so I just need to convince cjwatson :)
<cypherbios> *are you
<Riddell> cypherbios: ah, no, that could help 
<Riddell> duh
<cypherbios> :)
<ogra> but apparently i can still access the sysfs data as root (even i cant see the fs contents)
<cypherbios> heheh
<Keybuk> ok ...
<Keybuk> what is in the sysfs data?
<Keybuk> (trying to get back to answering the original question)
<ogra> ogra@laptop:~/packages/gnome-power-manager-2.19.2$ sudo ls /sys/fs/fuse/connections/1/
<ogra> abort  waiting
<ogra> waiting contains a zero
<Seveas> abort has mode 200, waiting mode 600 and contains 0
<ogra> ah, thats why i cant read it :)
<Seveas> actually, waiting has mode 400
<Seveas> echo 1 > abort --- seems to have no effect
<Keybuk> ok
<Keybuk> what do the files contain?
<ogra> 0
<ogra> nothing else
<Seveas> ah, wait
<Keybuk> bugger
<Seveas> after echo 1 > abort, i get this:
<Keybuk> so nothing useful like the pid of the daemon
<Seveas> dennis@mirage:~$ ls p
<Seveas> ls: p: Transport endpoint is not connected
<ogra> what does mount think ?
<Seveas> mount still thinks it's there (that misled me)
<cjwatson> Riddell: I'm ok with it being added commented out; file a bug on apt-setup?
<Riddell> cjwatson: ok, cool
<Keybuk> ogra: so is there any way to determine the list of fuse processes
<cypherbios> Riddell: I just tested the s-p-kde to add a CDROM (also using the --add-cdrom) and it works for me (very well I'd say). But seems it needs some error handle -- for example when add a invalid media (such a live cd ;))
<Riddell> cypherbios: does the gtk frontend have that error handler do you know?
<ogra> Keybuk, not to my knowledge
<ogra> they run as users ...
<ogra> so there is no central point apart from probably the fusectl fs (which doesnt contain anything)
* Keybuk wonders
<ogra> best would likely be to patch fusermount to drop the pid into /sys/fs/fuse/connections/
<cypherbios> Riddell: For me it works (both kde and gtk), even if I add a invalid media its says: Error sanning the CD\n Unable to locate any package files, perhaps this is not a Debian Disc
* cjwatson pokes about in the kernel
<xivulon> Keybuk, Seveas, ogra can I assume you'll try to take care of the sendsigs/fuse issue? 
<Keybuk> cjwatson: don't poke where I'm poking, we might tear a hole
<cypherbios> Riddell: I mean, if is a valid media it works well, if it's not says that the media is invalid -- A good behavior at all
<Riddell> cypherbios: it seems to sometimes work and sometimes leave progress dialogues doing nothing (for invalid media)
<cypherbios> Riddell: what version of s-p are you trying?
<Seveas> xivulon, don't count on me :)
<Riddell> cypherbios: feisty version
<cypherbios> Riddell: me too, the 0.59.4 version. But I'm testing using directly the source package (runing python software-properties-kde --add-cdrom), but it shouldn't matter
<glatzor> Riddell: how does apt-cdrom behave on the broken medias?
<Keybuk> ok
<Keybuk> so the tricky thing is that a fuse filesystem is valid as long as any process holds open the file descriptor that opened /dev
<Keybuk> (I wonder how many fuse daemons remember to close-on-exec that fd <g>)
<cypherbios> glatzor: it usually says: "E: Unable to locate any package files, perhaps this is not a Debian Disc" indeed
<Riddell> glatzor: complains normally and quits.  the problem will just be in the creating and deleting (or not) of dialogues
<Keybuk> so it's valid for a fuse daemon to open("/dev/fuse"), set up a filesystem, and then spawn unrelated children passing that file descriptor to them
<Keybuk> it's also valid for unrelated daemons to pass the fuse file descriptor between each other using a unix domain socket
<Keybuk> (and thus the filesystem stays open and is valid)
<cjwatson> so you really want lsof("/dev/fuse"?
<cjwatson> )
<cjwatson> oh, but those might have /usr open ...
<Keybuk> cjwatson: no, since that only tells us who's opening that inode
<Keybuk> and yeah, then we're into tricky territory
<Keybuk> what happens if the fuse filesystem daemon is in /usr/sbin and being used to mount /usr/local ? :p
<cjwatson> so IMHO there's only one thing we really care about here, and that's if a fuse filesystem daemon is used for /
<Keybuk> right
<Keybuk> well
<Keybuk> no
<Keybuk> actually I think it's still valid to not kill them
<Keybuk> since they'll be killed by unmounting the fuse filesystem anyway
<Keybuk> it just means we have to unmount the fuse one first ?!
<Keybuk> bah
<Keybuk> -TERM them :)  they should cleanly unmount the filesystem damnit
<Keybuk> yeah
<Keybuk> we only care about /-on-fuse
<cjwatson> it means we have to go round and round until everything dies, in umountfs
<Keybuk> Dear Kernel Developers,
<Keybuk> THIS is why these things belong in kernel-space, not userspace
<Keybuk> fortunately they realised the same thing about splitting out the partition code before they went ahead with it!
<kylem> ssh does not believe in the fecking kernel.
<kylem> ;-)
<kylem> er, belong
<cjwatson> -TERM should do, I guess
<Keybuk> kylem: killing ssh doesn't normally trash your root filesystem <g><
<cjwatson> I'd be curious to know if ntfs-3g cleanly unmounts on -TERM
<Keybuk> hmm
<cjwatson> that's the concrete use here
<Keybuk> do we care about /-on-fuse right now?
<cjwatson> yes, installer-for-windows
<Keybuk> why is that fuse?
<Keybuk> surely that's just loop?
<cjwatson> loop on ntfs
<cjwatson> stable ntfs support => ntfs-3g => fuse
<Keybuk> oh
<Keybuk> that makes things even worse
<Keybuk> since / isn't fuse
<cjwatson> ntfs-3g installs a SIGTERM handler which appears to exit cleanly
<Keybuk> so "is / fuse?" won't work
<cjwatson> point
<Keybuk> since the answer is N, / is loop
<Keybuk> I really can't say a way around this right now
<cjwatson> this is beginning to sound like the initramfs code that mounts the ntfs bit should leave a note for sendsigs
<cypherbios> Riddell, glatzor: all CD/DVD I've created using aptoncd and also some Ubuntu (alternate) and Debian ones works well with sofware-properties's Add CDROM -- I think everything is fine
<Keybuk> kernel engineering to export the list of pids using a particular file descriptor associated with each /dev/fuse connection
<Riddell> cypherbios: groovy
<cjwatson> which I guess leads us back to changing sendsigs
<Keybuk> yes, I think we're back to a "don't kill THIS pid" file
<cjwatson> sigh. oh well, it's doable
<Keybuk> we have a patch to change sendsigs anyway, for usplash
<cjwatson> is killall5 -x reasonable?
<Keybuk> so if we're taking the hit, we may as well go for full guts and gore
<Keybuk> it's not unreasonable
<cjwatson> sendsigs --shaun-of-the-dead
<Keybuk> it's kinda "I promise these pids are only in / and don't have anything opening for writing"
<sladen> using lsof style stuff it should be possible to check that
<Keybuk> err
<Keybuk> I think we're into "contract" here, rather than "check"
<kylem> cjwatson, LOL.
<cjwatson> [ job kbd_1.12-18ubuntu1_source from kbd_1.12-18ubuntu1_source.changes
<cjwatson> yay for untested weirdness
<glatzor> cypherbios: Oh, I can relax now again :)
<cypherbios> glatzor: you guys have done a good work, there is nothing to fear about it ;)
<glatzor> Riddell: it would be nice if the guidance python packages would be part of module
<glatzor> Riddell: e.g. guidance.displayconfigabstraction
<ogra> cjwatson, how am i supposed to get usplash installed currently ? 
<ogra> ltsp-build-client fails on it
<bryce> cjwatson: ok, this spec is updated too:  https://wiki.ubuntu.com/BulletProofX
<glatzor> bryce: could you sponsor a new upload of displayconfig-gtk?
<glatzor> bryce: it now uses the guidance-backends instead of shipping our own copy
<bryce> glatzor, unfortunately I don't currently have upload privs.  We could ask kees or kylem
<glatzor> bryce: oh, I can also drop an email to dholbach
<glatzor> bryce: he is my nanny as long as mvo is on vac :)
<bryce> ok cool.  :-)
<bryce> btw, I'd appreciate your comments on that bulletproof-x spec too - there's a few items there we'll need from displayconfig-gtk to support it, so I'd like to get your input on them
<cypherbios> glatzor: my patch is ready to review. I added the --add-cdrom and when using it doesn't show the main window -- works for both gtk and kde. Could you review and let me know what you think?
<cypherbios> Riddell: are you interested in take a look too?
<glatzor> cypherbios: for sure. just drop me an email. but I am in the kitchen now.
<glatzor> cypherbios: it is getting quite late in GB. So I am not sure if Ridell is still around
<cypherbios> glatzor: no hurry. I'm going to a meeting right now, then to home. If you want to tell me something drop me an email ;)
<cypherbios> here it's about 5pm, time to go home :D
* ogra hugs bryce 
<ogra> that new X is awesome
<bryce> heya ogra
<bryce> good to hear :-)
<ogra> all my thin clients boot without xorg.conf it seems
<ogra> and to the right resolution
<ogra> that will gain us over 20 seconds bootspeed
<ogra> (in ltsp)
<bryce> awesome
<ogra> eah, you really rock 
<ogra> :)
<pygi> auto-magic sometimes isn't good :)
<bryce> also, I hear we can run with incomplete xorg.conf's, although I haven't tested that myself - in theory you can specify keyboard layouts, but leave out the Screen, Device, and Monitor sections
<ogra> well, i can script that as well to be done at rutime ...
<ogra> *runtime
<bryce> ah, cool
<ogra> xmodmap and xrandr should do here ... so we can get the greeter up even earlier but unresponsive and greyed out until the setup is done ... so the user has something to look at
<bryce> glatzor: I've updated the displayconfig spec:  https://wiki.ubuntu.com/DisplayConfigGTK
<cjwatson> ogra: usplash installs fine in a clean chroot for me. What's the problem?
<bryce> glatzor: mostly I just folded the user and UDS comments into the main, and added a test plan section, but it would be good to review it in detail in case there are any other corrections needed
<ogra> it wont install without artwork here and the artwork doesnt want to get onfigured without usplash installed
<ogra> it will take me a while to get the exact error again (i dropped usplash for now during testing here and need to rebuild the chroot first)
<ogra> hmm
<cjwatson> I just installed it here without artwork
<glatzor> bryce: oh, fine. I haven't found the time to do this
<ogra> just apt-get'ing in the installed chroot works fine
<ogra> how strange
<cjwatson> happy to help once you have a better idea of what's going on ;-)
<cjwatson> if you can, perhaps try building the ltsp chroot with DEBCONF_DEBUG=developer to see if it's usplash's debconf interaction that's going wrong
<bhale> has anyone renewed their coredev membership yet?
<bhale> i imagine it is the same as the new member policy
<ogra> cjwatson, i'll rebuild the chroot ... must be related to ltsp-build-client's settings somehow
<cjwatson> I certainly wouldn't rule out a usplash bug, just don't know what it is yet ...
<glatzor> bryce: could you set the sub dialog thing to should be decided later
<glatzor> bryce: system > administration > screen and graphics  seems to be a better place
<bryce> I wonder if it wouldn't hurt to have it both places?
<bryce> which sub dialog thing?
<glatzor> bryce: the advanced button
<bryce> hmm, mdz was fairly specific to do it that way though
<cjwatson> bryce: "Tools which need to override portions of xorg.conf (Kickstart, displayconfig-gtk, etc.) should be modified to cause a full xorg.conf to be written out before they add their overrides."
<cjwatson> bryce: that can't be done in the case of Kickstart - that code runs at the very start of installation
<bryce> hmm
<glatzor> bryce: mdz said that he would not like to fight with me :)
<glatzor> bryce: but having feedback on this won't be the worst idea
<cjwatson> bryce: the way it works is that the person doing the installation provides an installation script which may include various X settings, and our Kickstart implementation translates those into preseeded values in the debconf database which are (much) later honoured by the X maintainer scripts while generating xorg.conf
<cjwatson> so Kickstart is very different from displayconfig-gtk in this regard - it's just telling the X maintainer scripts what to do
<bryce> cjwatson: ok; would Kickstart be able to deal with an incomplete xorg.conf?  I think for moving ahead with enhanced use of config autodetection, we're going to need it to accept that?
<cjwatson> bryce: I'd say that if there are preseeded values in the debconf database in the fresh-install case then X should honour them and skip autoconfiguration
<cjwatson> bryce: when Kickstart runs, xorg.conf is a distant dream
<cjwatson> this is in the alternate installer, pre-X
<glatzor> bryce: furthermore we provide the same features as the GNOME dialog. and even more.
<bryce> glatzor: ok, why don't you make that change, and then if there is still strong feelings in favor of that, you can discuss it further at that point
<cjwatson> it is certainly possible (and common enough) to omit X configuration in a Kickstart file, which should cause autodetection to be used
<cjwatson> but if it's explicitly configured there, it seems that it should be honoured ...
* Hobbsee_ ponders big periods of blankness that she cant account for.
<bryce> cjwatson: ok, sounds good
<glatzor> bryce: I am going to bed. See you!
<bryce> glatzor: sure, cya tomorrow
<bryce> cjwatson: I guess my one concern is if this may narrow the situations where autoconfig is used to only a very small set of cases (but maybe that's good?)
<cjwatson> bryce: I shouldn't think so; Kickstart is used by a relatively small number of people doing large deployments
<bryce> ah ok cool
<cjwatson> the set of people doing that sort of automatic installation are generally expected to be relatively clueful
<bryce> ok maybe I misinterpreted "preseeded values in debconf database"
* ogra moans about "Error: 'C' is not a supported language or locale"
<bryce> I take it this means, preseeded prior to installation by the user?
<cjwatson> bryce: may be worth reading https://help.ubuntu.com/7.04/installation-guide/i386/appendix-preseed.html
<cjwatson> right
<cjwatson> the effect of preseeding is to set a value for a question in the debconf database, and generally also to set the 'seen' flag on that question that indicates that it's been asked
<bryce> okay, gotcha
<cjwatson> unfortunately (?) this is indistinguishable from the question already having been asked in a previous dpkg run - sort of by design
<bryce> I've added a 5. in Autoconfiguration support for this
<cjwatson> but xserver-xorg's maintainer scripts already check whether they're doing a fresh install or doing an upgrade, which is sufficient to disambiguate
<cjwatson> because on upgrades I imagine you'd often want to convert to autodetection
<tepsipakki> some of the xserver-xorg debconfage has been removed by debian, but only the uninteresting ones (like modules, fontserver)
<cjwatson> tepsipakki: the stuff nobody bothered to preseed anyway? :)
<tepsipakki> cjwatson: right, and where the defaults cover 99,999% of cases :)
<alex-weej> Xorg CPU usage spikes to 100% when i move my mouse - only started happening today. Any idea how to debug?
<bryce> alex-weej: there's been several 100% CPU Xorg bugs reported
<bryce> so I'd start by searching for them in LP
<alex-weej> ca you give me a hint to their content so i can take a look?
<alex-weej> any words to search for
<bryce> sure, one sec
<alex-weej> i thought it was a problem when dragging windows at first :(
<tepsipakki> alex-weej: feisty or gutsy?
<alex-weej> feisty
<bryce> here's a search that seems to pull many of them up:  https://bugs.launchpad.net/ubuntu/+source/xorg?field.searchtext=100+CPU&orderby=-importance&search=Search&field.status%3Alist=Unconfirmed&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Needs+Info&field.status%3Alist=Fix+Committed&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<alex-weej> ok thanks
<alex-weej> was there an Xorg update over the last few days?
<alex-weej> 'cause like i said i only started noticing it today
<tepsipakki> alex-weej: nope
<alex-weej> weeks? :E
<bryce> I haven't run across ones that display 100% CPU on mouse movement, so that could be new.  But I haven't gone through the mouse-related bugs yet
<bryce> alex-weej: yeah xserver 1.3 went through a couple weeks ago
<alex-weej> i'm still on 7.2.0 apparently?
<bryce> also mesa got upgraded recently, although I doubt that'd result in this
<bryce> you mean xserver 1.2?
<alex-weej> i guess, i just ran Xorg -version
<bryce> oh sorry, these changes were for gutsy not feisty
<alex-weej> ok
<bryce> there hasn't been any x changes for feisty in a while
<alex-weej> hm
<ogra> cjwatson, ok, the exact error is "Keine Alternativen fr usplash-artwork.so." (sorry there is no easy way to override ltsp-build-cliet using the system locale)
<tepsipakki> sigh, this crappy gprs/3G connection has too much latency for IRC :I
<Mithrandir> tepsipakki: it's often better to run the IRC client locally on GPRS connections
<ogra> cjwatson, i'll see how to inject the DEBCONF_DEBUG=developer in there to get more details
<alex-weej> oh damnit
<alex-weej> stracing Xorg and then doing it caused it to go mental
<cjwatson> ogra: ok, I'll fix that, ignore the debconf comment
<alex-weej> damn, bonobo-activation-server still refuses to quit on logout
<cjwatson> ogra: it was dpkg --compare-versions lt rather than lt-nl for upgrade checks
<cjwatson> dunno why it didn't break for me though
<ogra> ah
<ogra> well, it doesnt break if i manually apt-get it in the chroot
<ogra> only from ltsp-build-client 
<tepsipakki> Mithrandir: yep, probably so
<Rinchen> Greetings.  Has anyone run across a situation where some system process on Feisty Linux c14n 2.6.20-15 and -16 smp continually writes to the harddisk? Every 30 seconds or so my harddisk starts grinding on my notebook. My desktop, same general config (diff hw) doesn't exhibit the problem.  
<cjwatson> ogra: it's a behaviour change in update-alternatives and only happens with new dpkg
<cjwatson> thanks for spotting that
<Rinchen> I've shutdown almost every process (even klogd) and it still happens
<cjwatson> you can't update-alternatives --auto an alternative that doesn't exist any more
<ogra> oh, then i'll have to check edubuntu-artwork :)
<Rinchen> I've also posted to the forum with no luck. I had hoped to find a clever way spying on the hd writes but haven't found one.
<cjwatson> ogra: why?
<cjwatson> I know it uses update-alternatives, but surely only on alternatives that exist?
<ogra> i think i might use --auto in there, not sure its a while ago i had to touch the maintainer scripts there
<pkl_> j #ubuntu-kernel
<cjwatson> --auto is fine as long as the alternative can be guaranteed to exist
<cjwatson> otherwise use || true
<ogra> yeah
<alex-weej> ok... linux-2.6.20-16 reintroduces a bug that stops it booting without "irqpoll" on my hardware :(
<ogra> thats what i'm doing anyway in maintainer scripts... 
<alex-weej> it's all going wrong for me today
<Rinchen> fwiw, I though it was hal harddisk polling but with hal stopped it still does it
<ogra> Rinchen, my disk is quiet here in the laptop
<ogra> well, on half upgraded gutsy but with feisty kernel ...
<Rinchen> Yeah that's what's annoying.  I'm on a system76 darter and others on feisty don't seem to have this problem.  My harddisk runs almost continuously.
<Rinchen> I'm at a loss as to how to continue to diagnose it.
<ogra> but it didnt use to do that in festy either
<ogra> *feisty
<ogra> does something continously write logs ? 
<Rinchen> ogra, yeah that's what I was thinking. I'll have a look at /var/logs again. I didn't see any updates when I had kill everything I could kill
#ubuntu-devel 2007-06-01
<Rinchen> ogra, I had tried to sort through lsof with as many of the processes stopped as possible but even then the output was enormous
<cjwatson> bryce: I've approved xorg7.3; not got to the other two yet, but it's OK, I think they're in reasonable shape now and I'll do them tomorrow
<bryce> ok cool, thanks
<bryce> ok, I need to hit the post office before they close; be back in a bit
<Chipzz> tepsipakki: I actually used one of those settings for preseeding :P
<Chipzz> but nothing major
<tepsipakki> Chipzz: heh
<Chipzz> (using the modules setting to prevent certain modules from being loaded, when setting up an ltsp chroot)
<Chipzz> 23:43 < tepsipakki> some of the xserver-xorg debconfage has been removed by debian, but only the uninteresting ones (like modules, fontserver)
* Rinchen goes off to pkill more things. 
<Chipzz> (I wanted to prevent to monitor from turning itself off)
<tepsipakki> bryce: we won't compile libX11 against xcb for gutsy either? (reading the spec)
<Neliath> Could somebody comment on this, please: http://lists.gnu.org/archive/html/gnewsense-users/2007-05/msg00136.html
<mjg59> Neliath: No, it's not in the slightest bit on-topic here
<Neliath> mjg59, how can you say that while we are on the affected network?
<mjg59> Neliath: Because, as the topic states, this channel is for the discussion of Ubuntu development - not Ubuntu policy, Freenode policy or anything else
<Neliath> mjg59, imagine you have a disagreement with christel and she posts your private data to people who hate you
<mjg59> Neliath: Still not on-topic
<Neliath> "this is not on-topic" means you dont care about the topic
<mjg59> Nice timing
<Hobbsee> i'd imagine he was in multiple channels
<ajmitch> Hobbsee: yes well he spammed #debian-devel on here with it
<Hobbsee> fun
<ajmitch> which is a fairly quiet channel
* mjg59 tries to work out how the gnewsense people decided http://www.gelato.unsw.edu.au/lxr/source/sound/oss/maestro3.h wasn't firmware
<ajmitch> isn't that your preferred form of modification?
* ompaul goes to look
<mjg59> Yeah, I enjoy hacking binary DSP code with no indication of what the instruction set is
<mjg59> Actually, I chatted to the Maestro driver author last month - ESS had no idea of what the DSP instruction set was either, as far as I can tell
<ompaul> mjg59, line 698 afik] 
<mjg59> ompaul: Yeah. That's DSP code.
<mjg59> The comment above makes it sort of clear :)
<ompaul> hmm will we ever reinclude it
<ompaul> I'll pass it back :)
<mjg59> Also pretty sure starfire_firmware.h is, well, firmware
<mjg59> Actually, a lot of stuff on the FalsePositive list is sourceless firmware
<mjg59> It'd be interesting to know what the checking process was
<mjg59> Though a lot of it is also just conversion tables
<bryce> tepsipakki, I may not have stated it correctly, but I think the intent we decided on was to provide both a libx11 with xcb, and a legacy version for binary apps
<bryce> tepsipakki, however I'd like to see evidence that we definitely need it (I assume we do but don't know for certain yet)
<keescook> anyone have any idea how ubuntu has unlimited lock memory (ulimit -l)  the kernel default is 32k.
<elmo> /etc/security/limits.conf ?
<elmo> (I'm WAGing)
<keescook> elmo: nope.  I can't find any trace of it.  not in limits.conf, not set by upstart.  very odd
<elmo> is the default soft or hard?
<keescook> the unlimited is soft, but I would like it to be 32k hard
<ashok> hi
<ashok> i need a ubuntu mentor on how to start developing in ubuntu
<ashok> can u people guide me how the process goes
<Riddell> depends on what you're developing
<crimsun> where in https://wiki.ubuntu.com/UbuntuDevelopment are you starting?
<ashok> i would like to develop java applications in ubuntu
<ashok> yeah i've registered
<Riddell> ubuntu itself doesn't use java for applications
<Riddell> if you just want to develop java stuff that happens to be on ubuntu, you want a java community to help
<ashok> than how can i contribute to ubuntu
<ashok> i am not attached to java only
<ashok> just develop some applications maybe in python
<Riddell> bugfixing, packaging, we have a limited number of applications we maintain ourselves almost all in python, doc writing etc etc
<ashok> can u give me basic idea of python
<Riddell> best way to start is to find a bug that annoys you and fix it
<Riddell> but most of our code comes from upstream projects
<ashok> upstream projects??
<ashok> can u elaborate
<Riddell> kde, gnome, linux, X etc
<`23meg> projects that produce the code of the components that make up Ubuntu
<ashok> ok
<`23meg> here are some relevant links: https://wiki.ubuntu.com/NewDeveloperProcess , https://wiki.ubuntu.com/MOTU/#head-ec7a97d5af67e96747b4f36993232ff434f4486c
<ashok> ok
<ashok> what are the starter bugs which i can start with
<ashok> just to get along
<ashok> i mean some smaller bugs
<scoobydoo28139> Are the developers in here
<scoobydoo28139> If the developers are in here i would like to thank you personaly(chatwise anyway)
<scoobydoo28139> Thank you for giving me a novice operatable verson of an OS, its verry nice
<scoobydoo28139> And I want to thank you for your time that you have put into it.
<bryce> heya scoobydoo28139
<scoobydoo28139> I hope some one sees this , have a good night
<scoobydoo28139> hello bryce:
<bryce> yeah right now is sort of a quiet time, but I'm sure the ubuntu team will see your comments.  Good to hear you're enjoying it.  :-)
<scoobydoo28139> bryce: do you help with the development of ubuntu?
<scoobydoo28139> ok that was a delay
<bryce> yes, although I joined after feisty, so can't take any credit :-)
<scoobydoo28139> well I can still appriciate a good OS that has novice people in mind
<scoobydoo28139> and to the people taking a chance on an os these days is hard to do 
<bryce> you know, if you're ever interested in joining in on development (even in non-coding areas), folks would love to welcome you
<scoobydoo28139> If i could i would, I am still trying to figure out terminal. I am however passing out cd's. around 300+ so far in this hick town.
<bryce> awesome, marketing's a great contribution :-)
<scoobydoo28139> Most are still wondering what a computer is here
<bryce> I set up a ubuntu box for my mother a while back, and it's worked well - no popups, spyware, etc. means very little IT work for me :-)
<scoobydoo28139> my bigest complain is finding someone with the patience to deal with a total newb like me
<bryce> we were all newb's once ;-)  As long as you're polite, do homework before asking questions, and stick to tasks, people seem happy to help get newbs up to speed
<scoobydoo28139> I will continue to help spread the ubuntu OS all over,If money would just grow on trees , i could do my own ship it
<bryce> cool, increasing the userbase is always a big help.  :-)
<bryce> also keep your eye out for other smart young folk who might be interested in doing development, and help steer them in the right (open source) direction
<scoobydoo28139> Ya know what makes microsoft so apealing and hard to over come is...
<scoobydoo28139> It is easy to install everything- its mostly a no brainer. That is hard for people to over come. And the ink jet suport like for my dell photo 944, is scarce
<scoobydoo28139> so when i pass out this ubuntu os its hard for me to explain about some things. I even have a tv card i can't use and the game thing is weard to understand. But i have hope that i am promoting a os in progress:)
<scoobydoo28139> any way i am going to get back to scoping out how to open installer.sh file :) good chatting with ya, and again thanks for ALL that you all do. From NC rutherfordton good day
<scoobydoo28139> bryce: one more thing.. how did you learn to write code?
<bryce> hmm, as a kid 20-some years ago, I copied it out of books and magazines into my vic20 and poked at it a lot
* netjoined: irc.freenode.net -> kubrick.freenode.net
<fabbione> morning guys
<Hobbsee> morning fabbione!
<fabbione> hey Hobbsee 
<Burgundavia> hey fabbione
<fabbione> yo
<tepsipakki> bryce: ok, I think java is the one that matters, and hopefully Sun  will fix it soon
<pitti> Good morning
<LaserJock> morning pitti 
* StevenK wonders if -java-gcj packages are still required.
<Hobbsee> morning pitti!
<pitti> BenC: for the record, rejecting 2.6.22-6.13 kernel binaries due to i386 FTBFS
<dholbach> good morning
<mdke_> morning dholbach 
<dholbach> hi mdke_
<sacater> damnit
<sacater> that was not me who did that quit message
<sacater> my stupid brother
<sacater> please ignore it
<pygi>  Hobbsee !
<Mithrandir> pitti: might be worthwhile mailing him + cc to ubuntu-archive@lists too
<pitti> Mithrandir: right
<Mithrandir> the whole IRC isn't a very good permanent record thing. :-P
<pitti> mailed
* desrt pokes pitti
<pitti> hi desrt
<desrt> how're you this morning?
* dholbach hugs desrt
<Hobbsee> hi desrt 
* desrt hugs dholbach 
<desrt> 'sup Hobbsee?
<pitti> desrt: hayfever *sniff*, but good otherwise
<pitti> and you?
<desrt> pitti; ick
<Hobbsee> desrt: i'm getting shot by my uni.  it's all good.
<desrt> pitti; i'm feeling fairly ok, i suppose :)
<desrt> pitti; how's the guadec thing looking? :)
* pitti won't attend
<desrt> Hobbsee; shot... like... with a gun?
<desrt> pitti; :(
<desrt> pitti; what made up yr mind?
<Hobbsee> desrt: nah.  just like "we've done all this, and you havent lived up to your end"
<Hobbsee> "yeah, i know, i suck, i've not been well"
<pitti> desrt: too much travel, I guess; LT, gutsy sprint, honeymoon...
<desrt> "cut me some slack! being in spain makes it hard!"
<desrt> pitti; yr (getting?) married?
<Hobbsee> desrt: somethinig like that
<pitti> desrt: yep, in August; lots of prep until then, too
<desrt> Hobbsee; fail a few classes or worse?
<Hobbsee> desrt: actually, it's mroe "cut me some more slack, i'm working on it"
<desrt> pitti; i had no idea.  congrats.
<Hobbsee> desrt: havent failed yet.  its' labs and such that i've missed, assignments not handed in, classes that i havent attended.
<desrt> i guess UDS was in the middle of the term?
<pitti> desrt: thanks
<Hobbsee> desrt: yep
<pygi> Hobbsee, but you *must* attend them :P
<desrt> Hobbsee; eh.  you make choices.
* pygi hides =)
<Hobbsee> desrt: yeah, i know.  i didnt expect to get *this* far behind though.  i thought i'd be OK
<desrt> Hobbsee; imo, if you can deal with this uni stuff, you made the right choice
<Hobbsee> heh
<Hobbsee> we'll see, we'll see
<desrt> good luck, in any case
* pygi has similar problems :P
<pygi> that's why I'm hiding :P
<Hobbsee> desrt: thanks.  i be needing it.
<desrt> Hobbsee; you wouldn't be a true hacker if you weren't in trouble at school :)
<desrt> Hobbsee; and after all... IRC = i repeat classes.
<Hobbsee> desrt: but i was always a good student!  :P
<Hobbsee> heh
<desrt> Hobbsee; eh... there comes a point when you're learning more outside of school than inside of it
<Hobbsee> desrt: that's true.  but still.
<desrt> Hobbsee; but that doesn't make the little piece of paper they hand you at the end any less valuable
<Hobbsee> i just hate letting people down
<Hobbsee> ture that
<desrt> are you in compsci?
<Hobbsee> optoelectronics
<Hobbsee> so it's not quite related, either.
<desrt> oh ya.  i think you mentioned that before
<desrt> makes it a bit harder to justify jetting off to ubuntu confs :)
<Hobbsee> exactly
<desrt> hello 4am.  it's disgusting to see you.
* desrt slinks away
<siretart> hi pygi 
<desrt> Hobbsee; best of luck
<pygi> hi siretart :) How are you ? ^^
<Mithrandir> night, desrt
<seb128> desrt: "hello pillow, nice to see you"? ;)
<siretart> pygi: fine! thanks
<pygi> siretart, just looking over what (if anything) I broke
<pygi> doing some major changes to libisofs
<pygi> 4000 lines changed so far
<siretart> pygi: how;s work going on with libburn?
<pygi> in a week. 
<pygi> siretart, perfect :)
<pygi> more on libisofs lately, since I didn't got a lot of time before to work on it... but it's advancing :)
<siretart> pygi: I subscribed you to bug #117948 - did you notice it?
<ubotu> Launchpad bug 117948 in libisofs "libisofs4-dev has no .so for linking" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117948
<pygi> no, but I will look now :)
<pygi> oh ,very descriptive
<pygi> will look at it as soon as I can
<pygi> it's weird
<pygi> ah, ah, seb :)
<pygi> ok, assigning to me
<pygi> testing to see if svn produces .so
<pygi> or it won't compile :P
<pygi> knew I broke something
<pygi> testing 0.2.4
<pygi> 0.2.4 does produce .so files
<pygi> must be something weird with the deb
<pygi> I'll look it after today. Important exam. Ok?
* pygi wonders if siretart is alive :P
<pygi> or anyone else for that matter
<pbn> firestarter ? 
<pbn> bug 118204 ?
<ubotu> Launchpad bug 118204 in kdeartwork "kfiresaver.kss chewing up 154% CPU" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118204
<pbn> no that's kfiresaver :)
<siretart> pygi: sure (I'm at work right now)
<pygi> siretart, oh, oki then ^_^
<pitti> siretart: woot! ffmpeg has a shared lib now?
<siretart> pitti: the debian one ships it for quite some time now
<siretart> pitti: could you perhaps move the ffmpeg library binary packages to main and give back xine-lib? xine-lib is waiting for them
<pitti> siretart: hm, so they are good for main now, but shouldn't go on the CDs, right?
<siretart> right
<siretart> none of them
<pitti> that makes me nervous...
<cjwatson> erm
<cjwatson> that's been deliberately blocked on germinate work for a while now
<cjwatson> per a TB decision
<Mithrandir> cjwatson: wouldn't a big red blinking note on the testing/ pages work as well?
<cjwatson> I suppose, but I'd really rather have germinate do it
<siretart> cjwatson: err, the last time I called the TB for this, I was told the packages were fine for main, as long as they don't get on the CD
<cjwatson> siretart: yes, which requires germinate work to enforce the latter
<cjwatson> how about '!ffmpeg' or whatever to blacklist a binary package from everything in the containing seed or inside?
<cjwatson> I think that syntax is free
<pitti> cjwatson: all binaries from that source? or listing the binaries explicitly?
<pitti> for ffmpeg the former would be easier
<pitti> but the latter is more precise
<cjwatson> !%ffmpeg
<ubotu> Sorry, I don't know anything about ffmpeg - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<cjwatson> just stack the syntaxes :)
<rohan> the 2.6.20-16 kernel build for feisty disabled libata ?
<siretart> cjwatson: the binary package 'ffmpeg' is for universe anyway
<siretart> cjwatson: actually, only the binary package 'libavcodec.*' (regexp) are 'dangerous' and need to stay off. the other ones (libavutil, libavformat, libpostproc) are harmless patentwise
<crimsun> rohan: git commit 51d8d888cdc05e426af4cbb93d5c3aea9f6b7b01
<sabdfl> anybody have a quick answer to: how many files are in the ubuntu kernel source package?
<sabdfl> and how much space do they take up?
<rohan> crimsun: thanks
<cjwatson> siretart: I couldn't remember the exact binary package name; it was just an example
<fabbione> sabdfl: about 22K files..
<cjwatson> <cjwatson@cairhien ~/src/ubuntu/linux/ubuntu>$ find -name .git -prune -o -print | wc -l; du -sh --exclude .git
<cjwatson> 23917
<cjwatson> 304M    .
<cjwatson> sabdfl: ^-- current-ish gutsy tree
<Mithrandir> : tfheen@xoog ..inux-source-2.6.22-2.6.22 > find -type f | wc -l
<Mithrandir> 22513
<Mithrandir> not out of git, but the actual source package
<fabbione> yeah 304MB confirmed here too :)
<siretart> cjwatson: pitti: so whats the plan with ffmpeg/xine for now?
<pitti> I'd rather wait with the promotion for the germinate fix TBH
<siretart> xine-lib currently just dep-waits for the ffmpeg packages to be able to build
<siretart> hm
<pitti> siretart: depends on the ETA; I guess; dep-wait for a few days is fine, for a few weeks is not
<rohan> crimsun: that is for the linus' git tree ? i can't find any commit no. "51d8d888cdc05e426af4cbb93d5c3aea9f6b7b01" there 
<crimsun> rohan: no, see ubuntu-feisty.git
<pygi> rohan, gutsy tree
<pygi> ah, feisty :p
<rohan> ah, thanks crimsun 
<crimsun> rohan: http://preview.tinyurl.com/36y7rm
<rohan> wow, beautiful .. libata driver was causing too many  Emask/Exceptions on my cdrom drive :)
<cjwatson> siretart: I'm attempting the germinate work now
<siretart> thanks!
<rohan> and i know this was the wrong channel to ask in, so sorry 
<cjwatson>  Germinate/germinator.py |   31 +++++++++++++++++++++++++++++--
<cjwatson>  man/germinate.1         |    6 ++++++
<cjwatson> it's not looking too hard
<sabdfl> thanks fabbione, cjwatson, that gives me a good estimate of bzr performance on that kind of tree
<sabdfl> about 3s status with the the next release of bzr, i expect
<fabbione> sabdfl: are you importing the history as well?
<sabdfl> no, but i don't think status is affected by history size
<sabdfl> commit, branch etc are
<sabdfl> but the bzr guys just landed a nice couple of performance bumps
<sabdfl> and have a pyrex version of some core routines which should take that time down to 2s
<fabbione> i get about 2 secs on git status with cold cache and 0.7 secs on hot cache
<sabdfl> which IMO is very impressive
<sabdfl> my numbers are hot cache
<fabbione> ok
<sabdfl> i.e. regular use, hack hack hack status hack hack status commit
<fabbione> yeps..
<pitti> depends on whether you compare sabdfl's small laptop against fabbione's supa-powah toys, I guess
<sabdfl> bzr commit is still slower than the others, but they have been optimising status and it's come out very impressively
<fabbione> pitti: that's also true.. let me import a kernel tree in bzr on my machine
<sabdfl> sigh. pitti. size is SO not important.
<sabdfl> http://www.scienceblog.com/cms/men-worry-more-about-penile-size-women-13347.html
<fabbione> ROFL
<sabdfl> hard science, so to speak
* pitti chuckles
<fabbione> well i guess it's more due to the fact that a man is "stocked" with his penis.. women can change and decide...
<crimsun> I haven't used bzr over this 56kbps dialup in some time.
<Treenaks> I need to sit down and write that sourcepuller dump importer for bzr :)
* fabbione sighs...
<fabbione> running constantly out of disk space and after 3 months you realize that you still have 80GB unused LVM space kind of sucks
<shawarma> fabbione: Sucks to be you?
<fabbione> shawarma: yes indeed
* Kigh wonders, why ubuntu has a 127.0.1.1 entry in /etc/hosts
<Kigh> it confused my X11 totally after i upgraded the kernel on 7.04 2 days ago. (terminal windows needed 10 seconds! to appear)
<Kigh> resolution: replace 127.0.1.1 with 127.0.0.1
<fabbione> sabdfl: bzr status + hot cache + same machine as before takes about 3.5 secs
<Keybuk> Kigh: it comes from Debian
<fabbione> sabdfl: do you have a devel version of bzr with those optimizations?
<Keybuk> Kigh: it's exploiting a kernel bug to seperate the IP of localhost from that of the machine name
* Kigh wonders, why debian has a 127.0.1.1 entry in /etc/hosts
<Keybuk> Kigh: afaik all kernels should reply on any 127/8 address for lo
<fabbione> hmm no
<fabbione> 127/8 is a routable network
<Kigh> Keybuk: i already thought that. but it lead to issues with X11. 
<Kigh> fabbione: its not.
<Keybuk> fabbione: no, it's not
<fabbione> ihih RFC says that you are not allowed to route it on the internet
<Keybuk> the fact Linux replies to any packages sent *down* the lo network device, rather than *to* its address is a "bug"
<Kigh> fabbione: well it is, but read the RFCs. one should never route 127/8
<fabbione> it doesn't say you can't route it internally
<Keybuk> or at least "an odd feature"
<fabbione> Kigh: internet routing is not the same as local
<fabbione> be careful there.. the difference is small
<Keybuk> Kigh: I don't see why this would break
<Keybuk> which kernel did you upgrade to?
<Kigh> youre right fabbione 
<Kigh> mom
<Keybuk> 2.6.22 still exhibits the "lo replies to any packet routed to it" feature
<Kigh> "2.6.20-16-generic" per "apt-get upgrade"
<Keybuk> can you nopaste the output of "ifconfig lo" somewhere
<Kigh> after that update my gnome-desktop needed ~3mins do show up and i needed ~1 hour to locate and resolve that issue
<Kigh> Keybuk: i can ping every 127/8 correctly on lo
<Keybuk> ok
<Keybuk> then I suspect the issue is unrelated
<Keybuk> you should have in /etc/hosts:  127.0.0.1 localhost
<Keybuk> and 127.0.1.1 hostname
<Keybuk> and *nothing* should be using "hostname"
<Kigh> http://nopaste.biz/16619
<Keybuk> (all local communication, including X, should be to "localhost" anyway)
<Kigh> Keybuk: that was my /etc/hosts before i resolved the issue. now "localhost" and "hostname" do both point to 127.0.0.1 and voila: X11 reacts blazing fast.
<Keybuk> http://lists.debian.org/debian-boot/2005/06/msg01047.html
<Keybuk> hmm
<Kigh> i didnt change anything, all DIST
<Keybuk> that sounds like things in X are trying to use your hostname
<Keybuk> that's a bug
<Mithrandir> Kigh: what is DISPLAY set to?
<Keybuk> in the long term, there won't even be an entry in /etc/hosts for your hostname
<Kigh> declare -x DISPLAY=":0.0"
<Kigh> Keybuk: i know. i didnt have a hostname entry on my archlinux or slackware before i switched to comfortable ubuntu
<Keybuk> Kigh: since this configuration works for everybody else, we need to understand what's different about your machine to understand why it breaks for you
<Kigh> if i only knew that :)
<Kigh> i didnt change any config manually, except etc/hosts to resolve this X11-issue
<Kigh> everything is installed via apt-get
<Kigh> no self-compiled apps
<Kigh> any guess what could be different?
<Kigh> i have a lot of interfaces, but this should not affect "lo"
<Keybuk> no idea, sorry
<Kigh> k. if nobody else had this issue, then its not important. i know how to resolve it for myself
<Kigh> but for what reasons should "hostname" never be an alias of "localhost"? (127.0.0.1)
<Kigh> it works just fine
<Keybuk> Kigh: http://lists.debian.org/debian-boot/2005/06/msg00938.html
<asac> pitti: edgy and feisty should be building now ... do you need the version that will fix things in gutsy?
<Kigh> Keybuk: this does not explain why 127.0.0.1 should not be used. he just suggests hostname should point to 127.0.1.1 (for no specific reason)
<asac> pitti: for gutsy its 2.0.0.4+2-0ubuntu1
<pitti> asac: no, we don't do that for Ubuntu USNs
<pitti> asac: but thanks anyway
<asac> pitti: ah ok
<asac> pitti:  i will test things till lunch ... if you haven't heard a thing you can push
<Kigh> Keybuk: mh okay, i better think about "reverse dns" :-)
<sabdfl> fabbione: bzr branch lp://bzr 
<sabdfl> or maybe http://launchpad.net/bzr
<sabdfl> i.e. bzr branch that url
<fabbione> got it
<fabbione> bzr branch lp:///bzr foo
<fabbione> it's 3 ///
<ion_> gcc has been compiling a single C++ file for 8 hours or so. It has been able to use 27 CPU minutes; the rest has been spent waiting for IO, namely swapping. :-D
<dholbach> holy cow
<mrsn0> :I what are you compiling ion_ ? gentoo?
<ion_> cimg-dev
<ion_> inrcast.cpp in it.
<asac> pitti: builds went fine? if you haven't pushed yet, please wait a bit ... have to verify something for feisty.
<pitti> asac: edgy built fine
<pitti> asac: still waiting for feisty anyway
<asac> pitti: ok ... feisty should be fine too
<ogra> Keybuk, i see constant ewarnings from udev-event: rename_netif trying to rename my eth0 on a thin client, is there a way to tell udev to not try to rename it ?
<Keybuk> release?
<ogra> gutsy
<ogra> fresh installed
<ogra> (the chroot)
<Keybuk> what are the warnings?
<ogra> that its in use and cant be renamed
<ogra> which is indeed true on an nfsroot :)
<ogra> its not doing any harm either, but its ugly
<Keybuk> oh, hmm
<Keybuk> interesting ;)
<Keybuk> I wonder why it's trying to rename it though
<Keybuk> it should have the same name
<Keybuk> what's it trying to rename it to/
<ogra> hmm, wait, the chroot is built on another machine indeed
<ogra> eth2
<Keybuk> aha!
<Keybuk> yeah, that's the same postinst bug that fabbione had
<Keybuk> there's a temporary hack in postinst that seeds the file, which won't be in the final release
<ogra> ah, ok
<ogra> as i said, it does no harm, just cosmetical stuff ... as long as udev behaves i'm fine
<ogra> Keybuk, another thing i stumbled across is that udevsettle doesnt seem to do anything if you use it in initramfs
<ogra> i was trying to fix the persistent lvecd mode and make it wait until the device is there, but it sems to be ignored .... checking other scripts it seemed to be the same
<Keybuk> what are you expecting udevsettle to do?
<Keybuk> tip:
<Keybuk> never, ever, run udevsettle
<ogra> i didnt dig deeper since i worked around the initial problem by adding the same loop as the other / mounting modes have, so it jus retries until the / device is there
<Keybuk> udevsettle is not the binary you are looking for
<ogra> Keybuk, well, its run in several scripts in initramfs and as i understood its the commad to run to make sure udevtrigger is done
<Keybuk> right
<Keybuk> what do you think that means?
<ogra> which apparently doesnt work in initramfs
<Keybuk> no
<Keybuk> I suspect you just don't know what you're doing
<ogra> since i see udev still working while the script moves on
<ogra> (udevtrigger i mean, sorry)
<Keybuk> you never need to run either command
<Keybuk> if you're running them, then you're attempting to do something wrong
<ogra> why is it run then ?
<Keybuk> it's run once by the udev initramfs script
<Keybuk> it needs to be run no other times
<ogra> right
<Keybuk> and you'll notice that udevsettle is never run
<Keybuk> so
<ogra> ah, well its run in the nfs-top udev script ....
<shawarma> Really? How does that work, then? Are the events just queued until udev starts to listen?
<Keybuk> what do you want to happen?
<Keybuk> ogra: there should be no nfs-top udev script
<ogra> # We need to wait for the network card drivers to be loaded
<ogra> /sbin/udevsettle
<Keybuk> there should only be an init-premount and init-bottom script
<ogra> from usr/share/initramfs-tools/scripts/nfs-top/udev
<Keybuk> ogra: what package supplies that script?
<ogra> for the nic drivers it seems
<ogra> root@laptop:/# dpkg -S usr/share/initramfs-tools/scripts/nfs-top/udev
<ogra> udev: /usr/share/initramfs-tools/scripts/nfs-top/udev
<Keybuk> oh, hmm
<Keybuk> that's probably my bad then
<Keybuk> it doesn't really help you
<ogra> well, but thats not the one i had the prob with
<Keybuk> all udevsettle does is ensure that the udevd daemon is "up to date" with kernel uevents
<ogra> but i saw the comment and thought i could use udevsettle
<Keybuk> udevtrigger causes missed uevents to be resent
<ogra> in my classmate initramfs script ...
<Keybuk> thus bringing udevd up to date
<Keybuk> after that, udevd will receive them from the kernel directly, so there's no need for either binary to be run
<ogra> ah, s if i would run udevtrigger a second time it would just do a noop
<Keybuk> the reason that udevsettle doesn't work for the network driver case, is that it only ensures that udev has reacted to the existance of the pci device (since that's all that will exist in sysfs before modules are loaded)
<Keybuk> the reaction to the pci device is to load a module
<ogra> err, it works for the network driver case
<Keybuk> there is an indeterminate amount of time between "udev has reacted and loaded a module" and the network interface actually being useful
<Keybuk> (or even existing)
<Keybuk> it may happen to occur quicker than it takes the initramfs to get to the command that uses the network
<Keybuk> but it's still a race condition
<ogra> it didnt for the persistent mode from casper (which m classmate script is based on) since the usb disk wasnt there whne it tried to mount /
<Keybuk> exactly
<ogra> adding a loop around the / mounting function solved it
<ogra> but thats indeed not the proper fix
<Keybuk> udev will react to the existance of the pci device representing the usb hub
<Keybuk> that does not guarantee the usefulness of any usb device somewhere down the device tree
<ogra> the usb hub is very slow
<ogra> ah
<ogra> so the loop is the only option then ... 
<ogra> uless i fix the HW
<ogra> *unless
<Keybuk> the time between "udev being up to date with the kernel (it's seen that there is a usb hub)" and devices somewhere in the usb tree having been probed, negotiated for power requirements/speed/etc., kernel knowledge created, udev being aware of the existance of those devices, modules being loaded, modules initialising the device, device responding, udev creating /dev nodes as appropriate
<Keybuk> is longer than the (simpler) network card case
<Keybuk> they're both race conditions
<ogra> indeed
<Keybuk> the USB one is a race with an american who likes to eat at McDonalds every day
<ogra> it also has to load the filesystem and usb storage stuff
<ogra> haha
<Keybuk> right
<Keybuk> there are two common solutions
<Keybuk>  1) loop until what you expect to exist/work does exist and work
<ogra> right, thats what we seem to do anyway in all other scripts, just not in casper
<Keybuk>     - we use this in the initramfs local mountroot(), we loop until the $ROOT device exists and vol_id works on it
<Keybuk>  2) react to the events telling you that it does work
<Keybuk>     - we're gradually moving to this where we can (e.g. devmapper, LVM, etc.)
<Keybuk> (2) is clearly better, but also harder than (1)
<ogra> yeah
<ogra> well, as long as 1) is used everywhere i'm not much concerned even though i dont really like it ...
<Keybuk> all this talk about udev and events has made ian explode
<ogra> heh
<Keybuk> actually, there is a 3) I should talk about for fairness
<Keybuk>  3) do everything in a predictable order, and don't move on to the next step until you know the previous step is finished
<Keybuk>     - we don't like this because it's slow, and introduces "points of no return" (if you don't plug your USB key in by now, it won't be used)
<ogra> upstart philosophy :)
<cjwatson> Keybuk: (would you mind fixing casper to do this right for persistent USB sticks? :-))
<ogra> cjwatson, i have the loop fix here if we dont come up with aything better
<Mithrandir> cjwatson: that'd be sweet.
<cjwatson> I tried udevtrigger/udevsettle, but I now understand why that didn't work
<ogra> (works fine and saved my ass on the classmate image)
<Keybuk> cjwatson: as I understand it, the cow problem is that in order for the root filesystem to be set up, the cow has to be configured first
<cjwatson> yes
<Keybuk> e.g. if you find the cow, you need to build the root filesystem with it in
<ogra> you do an unionfs mount
<Keybuk> you can't be halfway through booting, discover the cow, and modify the root filesystem so it's now writable to that instead of ram
<cjwatson> fortunately there is a boot argument to say "please go and look for a cow"
<Keybuk> right
<cjwatson> it's not just done on-spec
<cjwatson> so a loop would be workable
<Keybuk> you can't say "if I have a cow, don't use the ram"
<ogra> i'll add that then 
<Keybuk> you can say "I have a cow, don't use the ram"
<Keybuk> and wait for the cow
<cjwatson> casper --animal-farm
<Keybuk> (because the question "Where's my cow?" takes a while to answer ...
<Keybuk>  "That's not my cow!  It goes NRRRRGH!  That is a hippopotamus!"
* Mithrandir knew people would start making jokes when he started using the cow name.
<thom> it worries me that keybuk had that pterry quote quite so close to hand ;-)
<elkbuntu> Mithrandir, just tell them to apt get their own ;)
<Keybuk> thom: I'm not sure it's an accurate quote; but it's certainly correct in gist
<Mithrandir> Keybuk: can we have a point of no return where we look for cow devices and if none are found, continue as usual?
<Keybuk> Mithrandir: arguably that's the point where we reach init-premount; which doesn't take very long at all
<Keybuk> certainly takes a lot less time than starting the few things in between
<Keybuk> we could add a 10s delay, but that penalises cow-less people
<Mithrandir> yes, which is bad.
<Mithrandir> but we could do it after the cdrom has been mounted, since that always takes time.
<Keybuk>  "That's not my cow!  It goes 'Buggrit, Millennium, Hand and Shrimp!  That is Foul Ol' Ron!"
<Keybuk> how long does an integrity check take? :p
<Mithrandir> too long
<Keybuk> bah
<Mithrandir> say you get around 5MB/sec from your drive, so around two minutes.
<shawarma> There's not another Dapper point release planned, is there?
<cjwatson> shawarma: it's possible
<cjwatson> but no explicit plan at the moment
<shawarma> cjwatson: Ok. I've got an issue that pertains to the installation, so it doesn't make much sense to put any effort into it unless such a release is planned, so it's not really a candidate for an SRU. 
<shawarma> It's about a commonly used raid driver missing from the standard initramfs.
<shawarma> Not sure what to do about it..
<StevenK> cjwatson: gutsy_probs.html only covers main, right? ultrastar-ng has been demoted to universe, and yet still appears in it.
<cjwatson> right - I've tried running it on universe and it takes way too long to contemplate
<cjwatson> ultrastar-ng |    0.1.4-1 |         gutsy | all
<cjwatson> ultrastar-ng |    0.1.4-1 | gutsy/universe | source
<cjwatson> apparently only the source was demoted
<StevenK> Ahh.
<cjwatson> btw, 'rmadison -u ubuntu ultrastar-ng' works if you have ultra-current devscripts
<cjwatson> the archive it uses is only updated every six hours, so may sometimes be a bit behind
* StevenK might throw the rmadison script from it into ~/bin
<pitti> Hobbsee: welcome to -core-dev, and congratulations! well-earned
<Hobbsee> pitti: thankyou :)
* Hobbsee o.{ now i can go break things!!! }
<Hobbsee> oh wait, i'm not supposed to say that!
<thom> Hobbsee: congrats!
<Hobbsee> thom: thankyou :(
<Hobbsee> * :)
<ajmitch> well done :)
<ajmitch> yay, 3-day weekend
<StevenK> For me too, sort of.
<StevenK> And then a 4 day weekend
<ajmitch> public holiday?
<StevenK> I have uni presentation on Monday, so I have the day off $WORK.
<StevenK> Friday is my birthday, so I'm also taking it off.
<ajmitch> lucky, I think
<ajmitch> hah
<StevenK> The following Monday is a public holiday.
<StevenK> Oooh, I wonder if tc could be anymore esoteric to use.
<StevenK> # tc qdisc del dev eth0 pfifo_fast
<StevenK> Segmentation fault
<StevenK> Yeah, it could.
<Keybuk> Hobbsee: there's a reason that the LP emblem for core-dev is a hammer <g>
<Hobbsee> Keybuk: hahahha, i havent looked yet
<pitti> BenC: do we still need the 2.6.20 kernel in gutsy?
<StevenK> Keybuk: HAh
<Keybuk> (it's amazing how many people have never noticed that; it's always been a hammer since the day emblems were rolled out back at UBZ)
<StevenK> Keybuk: Is that the same reason the emblem for ubuntu-dev looks a little like a target?
<Keybuk> StevenK: that was supposed to be the MOTU logo from He-Man
<StevenK> Oh geez. Well, considering I last watched He-Man when I was like 8 ... :-P
<Keybuk> we still haven't found a He-Man costume for dholbach
<Hobbsee> awww
<StevenK> Not so much a costume, more like conviently placed articles of clothing and armour
<Keybuk> http://www.costumania.net/galleries/costumes/heman/big/heman01.jpg
<Keybuk> lol
<Keybuk> I see your point
* StevenK grins
<ajmitch> that's worrying
<fabbione> ahhaha
<cjwatson> my eyes
<Fujitsu> Eeeergh.
<fabbione> now.. gimp dholbach face in there
<Fujitsu> It burns.
<fabbione> and you are done
<Fujitsu> fabbione: Hahahah.
<cjwatson> siretart: so I'm looking at blacklisting libavcodec0d and libavcodec-dev, yes?
<cjwatson> actually, a regex would even work - awesome
* Hobbsee looks strangely at Keybuk 
<Hobbsee> Keybuk: now, i know you'd love to dress in that kind of stuff...but you really shouldnt.
* ajmitch should probably catch up on merges tomorrow
<Hobbsee> Keybuk: making dholbach wear it isnt going to make you feel like you're any closer to wearing it...
<Keybuk> Hobbsee: there are, sadly, far worse pictures of me
<Hobbsee> :P
<Hobbsee> Keybuk: pictures are evil
<Hobbsee> Keybuk: surely you've seen the ones of me at UDS - makes me look like i'm on drugs.
<Fujitsu> Hobbsee: These I must see.
<BenC> pitti: No, it can go away
<Keybuk> though if there was an Ubuntu Fancy Dress Party, I know exactly what costume I'd make :p
<Hobbsee> Fujitsu: haha.  nope
<Hobbsee> if there was an Ubuntu Fancy Dress Party, i wouldnt come.
<Hobbsee> although maybe that's something for the last night, too.
<Mithrandir> Keybuk: we should have one for next UDS.. or allhands. :-O
<ajmitch> how disturbing
<fabbione> Keybuk: we do NOT want to know
<fabbione> there is a need to know... and a wish to know
<Hobbsee> pictures must be provided
<Keybuk> fabbione: I'd come as my Launchpad picture <g>  which is somewhat easier for me, admittedly, than some people <g>
<Hobbsee> yes, all hands sounds good
<fabbione> Keybuk: ehehe
<Mithrandir> Keybuk: wouldn't be that hard for me either.  I'd need to buy a blue jacket and darken my face a bit.
<StevenK> Keybuk: And how would you look that pixelated?
<Keybuk> Mithrandir: don't forget the yellow biro
<Keybuk> StevenK: I'd have to start drinking again
<StevenK> Hah
<Treenaks> Keybuk: Look! Behind you! A three-headed monkey!
<Keybuk> Treenaks: How appropriate, you fight like a cow!
<mjg59> a
<BenC> pitti: did you reject 2.6.22-6.13?
<mjg59> Oops
<pitti> BenC: yes, I mailed you about it, due to the i386 ftbfs
<BenC> pitti: did you notice i386 ftbfs was caused by ghostscript failure to install for build-deps?
<BenC> No alternatives for gs.
<BenC> dpkg: error processing /home/buildd/build-342472-782743/chroot-autobuild/var/cache/apt/archives/ghostscript_8.60.dfsg.2-0ubuntu1_i386.deb (--unpack):
<BenC>  subprocess pre-installation script returned error exit status 1
<pitti> BenC: oh, oops :) so, let me unreject them
<BenC> thanks :)
<Mithrandir> pitti: unreject = accept, you know that?
<pitti> Mithrandir: yep
<cjwatson> <cjwatson@cairhien ~/src/ubuntu/seeds/gutsy>$ bzr commit -m 'blacklist libavcodec* from CDs (syntax from germinate 0.27)'
<pitti> Mithrandir: I didn't plan to do it now, just mentioning that we don't need another kernel upload
<cjwatson> drescher's germinate will whine, but shouldn't crash or do anything harmful
<cjwatson> lithium's germinate is up to date
<cjwatson> with any luck that should do it for ffmpeg
<pitti> BenC: I uploaded a fixed ghostscript which should install again
<pitti> BenC: after it's in the archive, we can give-back the kernel on i386
<StevenK> pitti: The question is, have another failed to build like the kernel did?
<pitti> StevenK: sorry, parse error
<StevenK> Yes, sorry, my brain skipped ahead.
<StevenK> pitti: The question is, have other packages failed to build like the kernel did?
<pitti> StevenK: entirely possible, I didn't check
<pitti> cjwatson: great
<pitti> cjwatson, siretart: does that mean it is possible to promote the ffmpeg libs?
<pitti> doko: can you please fix python2.{4,5} to build against libbluetooth-dev instead of libbluetooth2-dev?
<cjwatson> pitti: that's the intention, though I haven't checked the patent comments
<pitti> cjwatson: we discussed these with elmo at UDS; the primary issue was to make *damn* sure that those will never land on CDs, but in main they are fine
<siretart> cjwatson: right, libavcodec* is the evil bit
<pitti> Hobbsee, Riddell: digikam, digikamimageplugins, and gwenview need to be rebuilt against a newer libexiv;libexiv2-0.12 is not built any more; who can I bother about that? 
<Hobbsee> pitti: i could be persuaded
<pitti> (and some universe packages as well)
* pitti gives Hobbsee a big hug
<Hobbsee> better test the shiny upload powers out
* Hobbsee gives pitti a hug back :D
<robertj> is there any sort of general advice you give to one who has a depatch that won't reverse? gnome-system-utils build clean the first time only
<Hobbsee> pitti: er, according to my apt-cache, libexiv2-0.12 still exists.
<seb128> robertj: fix the bug? ;)
<seb128> robertj: or rm the dir and unpack the source again
<robertj> seb128: well I was hoping to take a stab and poking somethingin the src
<Hobbsee> pitti: presumably it's supposed to be built against libkexiv2-1 (well, the required dev package)
<robertj> is there a way to get more info as to why it wouldn't apply?
<pitti> Hobbsee: it does, but it is NBS
<pitti> Hobbsee: i. e. it's about to be removed
<Hobbsee> NBS?
<seb128> robertj: it's likely an autotools patch changing config.guess,sub or something similar
<robertj> yeah, it was an autotools patch, don't remember what it was patching though
<StevenK> Hobbsee: Not Built from Source
<Hobbsee> ahhh
<StevenK> Hobbsee: I merged exiv2, the -dev package name didn't change.
<Hobbsee> ahhh
<pitti> Hobbsee: 'Not Build from Source' anymore
<Hobbsee> gotcha
<cjwatson> pitti: right, the germinate and seed changes I made ensure that germinate will now refuse to include them anywhere logically inside the ship, ship-live, or server-ship seeds
<cjwatson> whether they're explicitly seeded or pulled in by dependencies or build-dependencies
<pitti> awesome
<cjwatson> it is possible that uninstallable packages on CDs may result from this
<cjwatson> it doesn't go back up the tree when it hits a blacklist entry
<Riddell> pitti: Lure knows all about those
<Lure> pitti: right, SteveK said he will upload -build packages for all rdepends of exiv2
* Hobbsee just did digikam*
<siretart> Tonio_: can you have a look at pitti's latest ghostscript upload to gutsy?, looks like that's what we need for xine-lib's backport in feisty!
<Lure> pitti: I have seen one upload only though
<pygi> Hobbsee, congrats ;)
<Hobbsee> thanks pygi :)
<pygi> knew you can do it^_^
<pygi> and you deserve it ;)
<Hobbsee> :)
<Riddell> Hobbsee: I think digikamimageplugins doesn't exist any more
<Tonio_> siretart: will have a look
<Hobbsee> Riddell: it hasnt been removed from the archive yet, at least.
<Lure> Riddell: correct - when digikam 0.9.2-beta2 builds, we can remove imageplugins
<Hobbsee> oh neat
<Tonio_> siretart: what about backport ? it also ftbfs on gutsy.... did I missunderstand you ?
<Lure> Riddell: but digikam is waiting for libkdcraw promotion to main
<Lure> pitti: ^^^ just a reminder
<StevenK> Hobbsee: gwenview uploaded
<Hobbsee> cool
<Riddell> Lure: since it shouldn't need a main inclusion report we can probably ask any archive admin just to promote it
<Hobbsee> Riddell: which is you, right?
<Riddell> Hobbsee: not yet
<Hobbsee> oh
<Hobbsee> i thought they gave you power
<Lure> Riddell: pitti said he will just do a quick check (it is library now, before it was part of core digikam)
<Riddell> Hobbsee: needs sysadmins to do their thing
<Hobbsee> blerg.
<Riddell> Lure: right
<Hobbsee> Riddell: surely the entire world is covered by launchpad now
<Riddell> archive admin is mostly command line stuff
<siretart> Tonio_: didn't you send me a buildlog of xine-lib in feisty?
<Hobbsee> as in, that launchpad would now give you access to the archive admin stuff, being part fo the team
<pitti> Lure: promoted
<Lure> pitti: thanks!
<StevenK> I expect it's a case of they don't want LP to run adduser and edit sudoers when someone joins/leaves the -archive team.
<Lure> pitti: for digikamimageplugins removal, I just open bug and subscribe archive-admin, right?
<seb128> Lure: correct
<seb128> ubuntu-archive
<Lure> seb128: thanks, will do when new digikam get in the archives
<pitti> Lure: yep
<pitti> Lure: can we get rid of dcraw with that? otherwise we'd have duplicate source code
<Tonio_> siretart: no that was for gutsy
<Lure> pitti: not really, as some other SW depends on it
<Lure> pitti: I agree it is bad, but dcraw in libkdcraw was introduced due to constant breakages of dcraw command line interface
<siretart> Tonio_: oh, then it seems that pitti fixed the problem :)
<Lure> pitti: good thing is that most kde sw is moving to libkdcraw
<pitti> Lure: then dcraw shuold use that new library
<Lure> pitti: but we might want to reconsider this if license issue is not resolved with new dcraw
<Tonio_> siretart: hehe perfect :)
<Lure> pitti: latest releases of libkdcraw did not pass debian license check, ie. is non-free
<Lure> pitti: new library (libkdcraw) is just a wrapper around "known-to-work-well" dcraw
<Lure> pitti: and it is c++, so I doubt gtk/gnome photo programs will be thrilled
<elmo> I'm repeatedly seeing netboot installs running an fsck on fresh installs that require a reboot (fsck is 49170 days old) - known bug?
<ogra> elmo, TZ rpoblem
<ogra> *problem
<StevenK> Neat how it labels the filesystem as being created in 1872.
<elmo> ogra: err?
<elmo> ogra: what timezone accounts for a shift of 135 years?
<ogra> the installer is switching the timezone after you partitioned or something, i forgot the precise error 
<pitti> asac: can I ask you to rebuild cman against the new libnspr4?
<ogra> we dug into that in feisty
<asac> pitti: sure ... let me see
<ogra> there is no easy fix
<StevenK> elmo: -1180080, obviously. :-P
<mjg59> elmo: I suspect that the time has been set to the future, but fsck always interpretes it as being in the past
<ogra> elmo, mvo had a bug about it we worked on for this
<ogra> not sure i can find it
<pitti> asac: cool; then I can remove libnspr4 and libnss3 & friends, since they are NBS
<StevenK> pitti: I can point out other NBSes if you wish.
<asac> pitti: its already rebuild
<asac> pitti: i have just to drop the manual depends
<asac> pitti: doing so now
<asac> pitti: e.g. currently depends on libnspr4-0d and libnspr4 :=
<ion_> Is gimp-plugin-registry going to be synced from debian to gutsy automatically, or should i request a sync?
<ogra> elmo, its related to the order of asking about UTC, partitoning and actually setting the timezone 
<pitti> StevenK: I have all of them in vi now and wade through the easy ones
<StevenK> pitti: Fairy 'nuff. Hopefully, it'll stop britney complaining so much.
<mjg59> We could just fix fsck to assume that insane dates shouldn't be checked
<StevenK> ion_: It should be done semi-automatically.
<ogra> elmo, bug 63175 and bug 43239
<ubotu> Launchpad bug 63175 in e2fsprogs "Edgy Beta -- fsck on every (re)boot" [Medium,Needs info]  https://launchpad.net/bugs/63175
<ubotu> Launchpad bug 43239 in e2fsprogs "fsck should check against a timestamp "49710 days" old" [Medium,Confirmed]  https://launchpad.net/bugs/43239
<ogra> we should just blindly dump th eright value in tune2fs 
<ogra> since we know we just formated in the installer
<StevenK> ogra: I just read the manual page, it's a simple matter (for ext3, at least) of tune2fs -T now <fs>
<ogra> right
<ogra> thats what i mean
<ogra> and we know the fs is clean (at least if we are in the installer)
<StevenK> The other problem might be we can't do that while the filesystem is mounted.
<pitti> asac: erk, I just noticed that firefox does not build mozilla-firefox any more; we need that transitional package until the next LTS
<ogra> well, its still /target so we can unmount it 
<ogra> its not that we are chrooted into it or something
<ogra> so the cleanup step that also does the unmounting shold just get tihis line of code
<asac> pitti: it has been discussed with mvo
<StevenK> ogra: It's a little more than one line.
<ogra> why ? we should have the device name from the unmounting code
<ogra> what else do you need than putting tune2fs -T now ${DEVICE} behind the umount ?
<StevenK> Firstly, because there might be more than one filesystem to run it across, and secondly, because there might be other filesystems being used in the new install, such as xfs.
<ogra> hmm, righ
<ogra> t
<StevenK> I don't want to try tune2fs against a xfs partition. :-)
<cjwatson> furthermore d-i doesn't actually set the UTC value itself - it just dumps it into /target so that it's correct at first boot
<ogra> ah
<ogra> set a firstboot flag we delete and make fsck respect that ? 
<StevenK> Actually, I'd be curious if this affected all filesystems or just ext[23] 
<ogra> i ddint test with anything else back then
* StevenK stares at his machine.
<StevenK> What do you mean, the CD has music and data on it. There is no CD!
<pitti> StevenK: it means the one on the kitchen shelf
<StevenK> There isn't one there either, so nyah.
<pitti> asac: if you allude to 'the dist-upgrader will handle it': why should we deliberately break apt-get upgrades if it's so cheap to keep them working?
<StevenK> I'm curious how to get the CD off my desktop, though. I can't eject it, there's no CD to eject.
<ogra> prssed the button on the cD drive ? 
<ogra> afaik we dont lock it anymore (or was that reintroduced)
<asac> pitti: i can't remember for sure, but I think its because one step dist-upgrade from dapper to gutsy+1 will break anyway ... so we don't break anything by breaking apt-get upgrades for firefox
<StevenK> ogra: I've opened it twice, just to check I'm not going crazy.
<asac> pitti: but i open a bug to keep track of the discussion now
<asac> pitti: subscribed you (and mvo) to bug 118247
<ubotu> Launchpad bug 118247 in firefox "reenable mozilla-firefox* transitional packages in gutsy" [Undecided,Needs info]  https://launchpad.net/bugs/118247
<pitti> asac: thanks
<iwj> If I'm editing the seeds to add something (sl-modem-daemon, from restricted) to ship and ship-live, do I need to edit the seeds for kubuntu and xubuntu and edubuntu separately ?
<ogra> iwj, we'Re usually supposed to care for merging ourselves, but its indeed appreciated if someone else does the work :)
<cjwatson> no, just edit the Ubuntu seeds and then either (a) bzr merge into each of the other branches or (b) let the release team or the {K,Ed,X}ubuntu lead merge it for you later
<cjwatson> don't commit four independent identical changes, though
<iwj> Right.
<ogra> right, the ubuntu seeds are the master branch
* iwj runs for foo in k x ed; do ...
<iwj> I've done a bzr merge and there are other changes - should I just commit my merge results or leave it ?
<iwj> As in, just commit the results of   for foo in k x ed; do (set -e; cd ${foo}ubuntu.gutsy; bzr merge ../ubuntu.gutsy); done
<cjwatson> if it looks sensible ...
<cjwatson> 'bzr status' should show the merges since the last time anyone merged into each
<cjwatson> should be a small number
<ogra> also dont wrooy to much about it for now, i'm pretty sure every tec lead will touch and sort his seeds before tribe 1
<ogra> *worry
<ogra> so we can clean up what we dont like
<iwj> It looks good to me so I'm committing it now.
<iwj> for foo in k x ed; do (set -e; cd ${foo}ubuntu.gutsy; bzr ci -m 'merge from ubuntu.gutsy'); done
<iwj> :-)
<iwj> This should be automated in a less ad-hoc way perhaps ...
<ogra> good point
<iwj> Aha!  I've found the power brick for this winmodem test laptop; it was in the living room's box of `cables and junk (misc)'.
<pitti> siretart: ffmpeg libs promoted
<siretart> pitti: cool, thanks. can you please give back xine-libs on all archs now?
<pitti> siretart: no, we need Mithrandir's powers for that
<siretart> ah, ok
<siretart> Mithrandir: could you please give bach xine-lib on all archs?
<pitti> if you do it now, it should go to dep-wait, since the main promotion will not actually happen until the next publisher run
<siretart> ah, i see
<elmo> Unpacking ghostscript (from .../ghostscript_8.60.dfsg.2-0ubuntu1_amd64.deb) ...
<elmo> No alternatives for gs.
<elmo> dpkg: error processing /var/cache/apt/archives/ghostscript_8.60.dfsg.2-0ubuntu1_amd64.deb (--unpack):
<seb128> elmo: you want  ghostscript (8.60.dfsg.2-0ubuntu2) gutsy; urgency=low
<pitti> elmo: I fixed that about an hour ago
<seb128> elmo: pitti uploaded it 2 hours ago
<pitti> still NEEDSBUILD, though
<elmo> meh, ok
<Mithrandir> siretart: somebody already did
<Mithrandir> siretart: apart from i386 where it claims chroot problem
<pitti> Riddell: someone put strigiapplet into the kubuntu seeds, but the package is in universe
<pitti> Riddell: ah, it's a recommends, so it's not uninstallable
<cjwatson> it wouldn't be uninstallable anyway
<cjwatson> update-metapackage won't add it to -meta binaries' Depends unless it's in main/restricted
<siretart> Mithrandir: oh, thanks anyway
<iwj> Ug, this CD drive is sooo slooooow.
<cjwatson> s/this CD drive is/CD drives are/
<ogra> bryce, displayconfig-gtk doesnt work without existing xorg.conf ? 
<iwj> cjwatson: This one is particularly bad.
<keescook> pitti: just so I'm on the same page.  for the apparmor changes mathiaz sent, the preinst is not needed, is that right?  (i.e. dh_installinit should already do all the right things?)
<pitti> seb128: thanks for the gnome stack trace patterns
<pitti> keescook: it is needed
<seb128> pitti: you're welcome
<pitti> keescook: as I wrote, dh_installinit won't touch the symlinks as long as any symlink to the init script still exists
<keescook> aaah, you wrote "update-rc.d won't do anything if there is any symlink..." so I wasn't sure if that was dh_installinit's invocation or a manual one.  I'm sorted now, thanks
<pitti> asac: FOAD, no feisty-security firefox in the queue yet
<asac> pitti: no?
<pitti> asac: ah:
<pitti> firefox_2.0.0.4+1-0ubuntu1_source.changes
<pitti> REJECT
<pitti> Rejected: Uploads to feisty are not accepted.
<pitti> asac: feisty-security :)
<cjwatson> pitti: err. did you mean FAOD? :)
<asac> pitti: ouch
<elmo> yeah, I was wondering if FOAD had a different meaning in German or something
<pitti> cjwatson: indeed, sorry
* pitti hopes that FOAD isn't something offensive
<cjwatson> "f*** off and die"
<elmo> or if Evil Pitti really did come through from the mirror universe
<Hobbsee> hehe
<Hobbsee> it's likely the evil Hobbsee having an effect.
<pitti> oops
<pitti> asac: sorry, that wasn't my intention at all
<Hobbsee> pitti: you used an acroynm without knowing what it meant?  unwise...
<pitti> Hobbsee: I wanted 'FAOD', and I know what it means
<Hobbsee> cjwatson: what's FAOD?
<pitti> I just tpyoed
<keescook> Hobbsee: congratz on your new badge.  :)
<pitti> Hobbsee: for avoidance of doubt
<asac> pitti: i didn't recognize it :)
<Hobbsee> keescook: both of them?  :P
<kylem> pitti is so innocent :)
<Hobbsee> pitti: ahhh.  didnt know that one
<elmo> disturbingly the first hit of FAOD on google is 'Furry Army of Doom'
<elmo> I also hope that's not what pitti meant :-P
<keescook> Hobbsee: ah, just saw the core-dev announcement.  :)
* Hobbsee knows about FAOD, due to her retail job
<Hobbsee> elmo: hahahahhaa
<iwj> pitti: Oh, sorry about not spotting that dpkg-source &warn thing.
* Hobbsee tries not to picture pitti as the leader of the furry army.
* pitti decides to simple erase that acronym from his brain then
<Hobbsee> er, s/FAOD/FOAD/
<pitti> iwj: no problem, it's all goo dnow
<asac> pitti: do i need a version bump or the other upload forgotton now?
<pitti> asac: the latter
<asac> fine
<Hobbsee> pitti: when you do finish with that brain eraser, please give it to me.  i've got work tomorrow, and the crazies are likely out.
<desrt> saturday morning crazies?
<desrt> the ones that line up half an hour before the store opens so that they can be the very first person on earth to have the privilege of buying a can of beans at the new price?
<Hobbsee> desrt: saturday afternoon crazies
<desrt> what's crazy about saturday afternoon?
<Hobbsee> desrt: last week we had some guys on crack or something at night.  usually the afternoon is worse, with people wanting insane things.
<Mithrandir> Hobbsee: like, food?
<desrt> Hobbsee; is ketchup on your danishes really an insane thing or are you just closed-minded?
<Hobbsee> Mithrandir: like refunds on stuff they didnt buy in the store, etc.
<Hobbsee> desrt: heh.  we dont have ketchup.
* Hobbsee should really get out of retail, at some point.
<desrt> as in "australia doesn't have ketchup"?
<Hobbsee> yep
<Hobbsee> it's tomato sauce, isnt it?
<ogra> desrt, they have vegemite
<desrt> not really
<Hobbsee> or is it just sauce?
<Hobbsee> haha
<desrt> it's make out of tomatos but it's not tomato sauce
<Spads> http://zork.net/~sneakums/fortunes/gar/110 <-- Hobbsee 
<desrt> it has vinegar and some other stuff in it
<Hobbsee> vegimite is *not* a substitute for sauce
<desrt> ketchup isn't "sauce"
<Hobbsee> Spads: hahaha
<desrt> it's more in the same category as mustard or something
<ogra> ketchup is slightly sweet and sour and surely not sauce :)
<desrt> condament
<desrt> *condiment
<ogra> glatzor, hey
* Hobbsee should have brought you all some vegimite, and fed you some at UDS.
<desrt> yuck
<Hobbsee> yummy!
<glatzor> servus ogra!
<ogra> glatzor, so displayconfig doesnt like if i dont have any xorg.conf ... is it planned to stay like that ? 
<ogra> s/doesnt like/doesnt like to start/
<glatzor> ogra: depends on the plans of bryce.
<ogra> ah
<ogra> well, currently you get a traceback 
<MappyPants> anybody know of a free windows C++ profiler?
<Hobbsee> try #c++
<ogra> what kind of windows are that ? 
<Hobbsee> that's hardly on topic here
<cjwatson> MappyPants: I'm afraid an Ubuntu development channel isn't the right place
<MappyPants> i know, sorry heh.  there arent many chans for this question on freenode
<pitti> Mithrandir: can you please give-back linux-source-2.6.22 on i386?
<cjwatson> tepsipakki: huh, the current gutsy CD images don't seem to do gfxboot
<bryce> ogra, yeah currently it requires an xorg.conf, however I hope to make it run without one, if we can find a good way of handling that situation
<asac> pitti: keescook ok uploaded to feisty-security now
<glatzor> ogra: you can currently start displayconfig with a stripped down xorg.conf that does not include any monitor or graphics card sections
<keescook> asac: great, thanks!
<pitti> asac: confirmed, it's on jackass
<glatzor> ogra: and displayconfig-gtk should guess your configuration.
<asac> i will look later tonight ... but am out for now
<asac> pitti: cu tomorrow :)
<pitti> asac: Berlin!
<glatzor> ogra: but there are some problems with detecting dual screen layouts currently. but this seems to be fixable
<ogra> pitti, you too ? 
<ogra> bryce, feel free to abuse me as guineapig
<pitti> ogra: yep
<ogra> cool
* ogra is still not sure what we'll do there though :)
<ogra> but i'll bring some ketchup for the grill :)
<adilson> ogra: ketchup and gril are 2 words that *never* should be used in the same sentence ;)
<pitti> darn, I cannot log into my LT account
<bryce> ogra, since we will still need keyboard and font sections, for integration purposes I'm thinking we'll be focusing on partly-empty xorg.conf's, rather than no xorg.conf at all
<bryce> but xorg is also adding input hotplug, and redoing fonts such that font paths won't be needed
<bryce> so at some point, maybe gutsy+1, we will be able to realize xorg.conf-less default installation
<cjwatson> tepsipakki: you seem to have dropped old changelog entries from syslinux too, which is generally bad form
<ogra> adilson, yeah, i wouldnt dare to do that in brazil to prevent being lynched :)
<ogra> but then you guys have the best meat ... ketchup is to hide the taste ;)
<glatzor> morning bryce
<bryce> heya glatzor :-)
<ogra> bryce, why not leave keyboard to the desktop ? 
<ogra> and whty for do we need the font stuff ? my fonts work just fine without xorg.conf
<bryce> ogra, how do you mean?
<ogra> bryce, well, when i wiped my xorg.conf 1h ago gnome asked me if i want the X or the gnome keyboard config ... 
<cjwatson> leaving keyboard to the desktop will make console-setup's life more difficult
<cjwatson> and also means that the keymap will be wrong at the gdm login prompt
<cjwatson> please don't do that
<ogra> cjwatson, not if we get a freedesktop standard for it
<ogra> even gdm could use that
<cjwatson> if that happens, we can talk about it then
<ogra> heh
<cjwatson> but we have reality to contend with
<ogra> right
<ogra> well, in gnome it would be just a gconf key ... sad we have so many other things to regard
<bryce> ogra, well fortunately things are moving in the right direction :-)
<cjwatson> tepsipakki: I think you also made a mistake in dropping my localboot-gfxdone patch
<iwj> seb128: I was wondering if I could have your help again with gnome-system-tools and the default modem dial type (tones vs. pulses).  I'm trying to change the default and I'm lost in a twisty maze of thousands of lines of pointless boilerplate in g-s-t, s-t-backend, liboops, etc.
<iwj> I've found what looks like the default but it's set to tones and manifestly the default is pulses.
<agoliveira> Am I reaching this? freenod is disconnecting here from time to time.
<Hobbsee> agoliveira: yes.  servers are dying occasionally
<cjwatson> tepsipakki: I wonder if it just needs a new gfxboot package - looking at that now
<superm1> Are any archive admins around?  I wanted to poke around as to why a package uploaded hasn't shown up to launchpad yet (It was uploaded a week ago on 5/23)
<ogra> superm1, is it in the queue ? https://launchpad.net/ubuntu/gutsy/+queue
<superm1> ogra, now that i look, yes it is.  Should have checked!  
<ogra> get someone to review it :)
<superm1> i didn't realize that another review was required once it was past -motu...
<ogra> if its a NEW package an archive admon has to review it 
<ogra> *admin
<superm1> oh that would make sense
<ogra> even for main developers thats the case
<superm1> well this being the case, any archive admins up for looking it over?
<Keybuk> superm1: NEW is processed roughly in order
<superm1> ah okay. thanks Keybuk.
<superm1> usually uploaded changes not NEW packages, so didnt hit the delay
<iwj> Keybuk: Re your comments on BootLoginWithFullFilesystem, the `Demo plan' includes filling the disk and then rebooting.  Is that the kind of test you were thinking of ?  In which case perhaps I should clarify by moving the comments about Testing/Long to `Demo plan' and or add `Test' to the `Demo plan' title ?
<iwj> Ttracing the system to find which daemons try to write stuff isn't going to help because we know there are lots of them and the issue isn't whether they write but what they do if they can't and whether the system can be used well enough to make space without them (if they break).
<iwj> Which is why I suggested testing that directly.
<iwj> As in, fill disk, reboot, how does it go ?
<Keybuk> iwj: sure, but at least finding out which ones try to write is going to help, no?
<iwj> I don't think so, no.  There'll be loads.
<Keybuk> "fill disk, reboot" is a bit "yeah, looks like it kinda works, let's ship it"
<iwj> And it'll be quite uninteresting.
<Keybuk> needs to be done on a step-by-step way
<Keybuk> you could fill the disk and examine what happens when hal starts, for example
<Keybuk> or even not fill the disk, but wrap it with something that always fails on write() to a disk file
<Keybuk> etc.
<iwj> You could but I think that's out of scope.
<iwj> `Examples of problems we consider out of scope: ... It is possible that some parts of the system or of the user's session will come up in a suboptimal state if the disk was full; this is fixable by making space and then rebooting'
<Keybuk> the scope is "rigorously test the distribution"
<Keybuk> (and fix any problems found)
<iwj> That seems too ambitious to me.
<Keybuk> it should be a few weeks of work, certainly
<iwj> I don't think in practice we can make every default-install user app work if the disk is full at boot.
<Keybuk> app; no
<iwj> I agree that it would be nice but if we try to do this we'll be trying to shovel water uphill.  For every bug in this we fix some upstream will introduce ten more.
<Keybuk> every process that we start by default should operate though
<iwj> I agree that server installs ought to work if the disk was full during boot.
<Keybuk> the desktop should as well
<iwj> But that's largely already the case and I think making servers more robust against that is a rather different task.
<Keybuk> the user should be able to clean up some files, and carry on
<iwj> Yes, I agree that it _should_ but in practice we're not going to be able to make it.
<Keybuk> we should try
<iwj> You might as well say `the desktop should keep working after we've upgraded the system under it'.
<Keybuk> it should
<iwj> I agree but it's not going to happen.  If we put in two months of effort making it work in gutsy then it'll be broken in gutsy+1.
<iwj> Since upstream don't think it's important.
<Keybuk> we have an automated package testing framework, no?
<iwj> All that thorough testing will do is tell us that it's broken.  It won't fix it for us.
<Keybuk> knowing that it's broken is more than half of the battle
<iwj> For example, probably the single most important application is firefox and trying to make firefox work when your disk is full is a hopeless struggle.
<Keybuk> I don't think it's unreasonable for firefox to need to be restarted
<iwj> It's hard even to stop upstream making it catastrophically lose data.
<Keybuk> this is why it's "boot and login with full filesystem"
<iwj> `We will aim to make the system work well enough for a user to be able to log in and delete files using the normal graphical file manager'
<iwj> Is achieveable.
<iwj> I don't think `make whole system work' is.
<Keybuk> I didn't say "whole system"
<Keybuk> <Keybuk> every process that we start by default should operate though
<iwj> And we can test `can log in and check and delete files' without needing to know whether this or that breaks.
<Keybuk> the work asked for in the spec was to perform a *comprehensive* test
<iwj> I don't see why `process that we start' is a relevant criterion for this spec.
<Keybuk> I don't see any plan for this test
<Keybuk> and I don't see any evidence in the spec of the test results
<Keybuk> iwj: relevant processes are all those run during the boot sequence, and login sequence; a subset of those being all those that are running when the user is at their desktop
<iwj> AIUI the purpose of the spec is to improve the system's usefulness to users with specific references to the use cases and existing problems identified, right ?
<Keybuk> none of these should fail in the case of full filesystem
<iwj> I mean, that's the purpose of all specs.
<iwj> Development activities listed in the spec should further that goal.
<iwj> It's not clear to me how (for example) discovering whether or not hal breaks during boot with full filesystem furthers the goal of making the user able to delete files.  Although actually we should extend the scope to removeable media since that's important for cleanup.
<Keybuk> it may not
<Keybuk> but if HAL isn't operating, the user can't continue using their PC after deleting the files
<Keybuk> since a major component will not be working
<iwj> Indeed, but we expect them to reboot afterwards.  Since we know that the system may not operate properly and we don't think we can make all of the user's applications survive this problem, we should tell them to reboot.
<Keybuk> no
<Keybuk> we do not want them to have to reboot afterwards
<iwj> `t is possible that some parts of the system or of the user's session will come up in a suboptimal state if the disk was full; this is fixable by making space and then rebooting.'
<Keybuk> that part of the spec is wrong
<iwj> Are you saying you disagree with that part of the scope ?  OIC
<iwj> I think the effort/reward ratio for making this work and keeping it working is not going to be worthwhile.
<iwj> If the user is going to be expected to restart firefox we might as well ask them to reboot.
<nnonix> News: You cannot (according to Dell) buy an E1505n (or any non-server Linux option) under your small business lease program. Residential credit only.
<nnonix> I just tried.
<cypherbios> glatzor_: ping
<glatzor_> pong cypherbios
<cypherbios> glatzor_: hi. What do you think about having a --sources-list=FILE in software-properties -- to let the user specify a custom sources list and do not mess up with their default one?
<glatzor_> cypherbios: generally it's nicer to not cover all kind of extra cases in the core of the application, but making the core as flexibel as possible and use it in different contexts
<glatzor_> cypherbios: so you could just add a manager.window_main.hide() after the init, instead of checking the options inside of the core
<glatzor_> cypherbios: why?
<cypherbios> glatzor_: are you talking about the patch I sent yesterday?
<glatzor_> cypherbios: yes
<glatzor_> sorry, I started typing as soon as you pinged me :)
<cypherbios> glatzor_: np ;)
<cypherbios> glatzor_: about the patch, what you think is better? I didn't catch you point :)
<cypherbios> *your
<imbrandon> Keybuk, hrm i have an upstream thats wanting to use the http://sam.zoy.org/wtfpl/ license, is that acceptable, its free but seems a but tacky imho
<imbrandon> err Keybuk dident mean to direct that to you individualy
<imbrandon> anyone*
<glatzor_> cypherbios: "if self.options.add_cdrom:" inside of SoftwarePropertiesGtk.py is not needed
<cypherbios> glatzor_: oh, I got
<cjwatson> imbrandon: as you say, it's tacky but acceptable
<cypherbios> glatzor_: that's right, I didn't noticed that
<Keybuk> what has the author of that licence ever achieved?
<Keybuk> apart from becoming the Debian Project Leader, of course
<Keybuk> :p
<cypherbios> glatzor_: btw, I'm wondering if would be nice if we have a new option --sources-list=FILE, what you think about?
<imbrandon> heh , he was a DPL ?
<imbrandon> lol
<elmo> is
<imbrandon> is?
<Keybuk> yes
<imbrandon> err
<Keybuk> is the current DPL
<imbrandon> wow
<imbrandon> i realy must come out of my cave once in a while
<desrt> i wouldn't say "not knowing who the current DPL is" is indicative of life in a cave
<desrt> i'd actually suspect the opposite to be true :)
<imbrandon> heh
<avoine> someone know what package is responsible of creating and populating /dev in ubuntu?
<desrt> avoine; in what sense?
<desrt> these days, udev
<Keybuk> avoine: udev
<avoine> ok
<mc44> I wonder if doing WTFYL is acceptable legal terminology :)
<Keybuk> avoine: why?
<avoine> I try to modify debian-installer
<cypherbios> glatzor_: a use case would be when the user do not want to touch in his default sources.list (/etc/apt/sources.list) but want to add a reporitory or a third-party source or even a cdrom without messing the system's sources.list
<avoine> for install a backup instead of ubuntu
<glatzor_> cypherbios: why would you do this? I could only think of a developer
<glatzor_> who wants to test his cd
<avoine> the problem is when I try to install grub with grub-install I have a error because /dev is empty in the target
<glatzor_> bryce: have you seen, that the Nvidia configuration tool is open sourced?
<bryce> no I hadn't; is that a recent change?
<pitti> good bye
<glatzor_> bryce: I don't know. it does not include a NEWS or Changelog file
<bryce> I was just now looking at the ati driver - looks like they put out a new release (8.37.6 vs. our 8.34.8)
<glatzor_> bryce: have you already read: http://www.phoronix.com/scan.php?page=article&item=735&num=1
<cjwatson> avoine: standard solution is 'mount --bind /dev /target/dev'
<bryce> hmm, looks like the last update for our nvidia driver was Mar 23
<cjwatson> avoine: probably same for /proc and /sys
<cypherbios> glatzor_: actually I have a application called aptoncd, the objective of this tools is to create a removable repository with the apt-cached packages. After creating this medium, the user wants to add it as apt source, so they can do that by using the apt-cdrom add, synaptic, software sources or something, but the user also can do it by using the aptoncd interface,
<glatzor_> bryce: the article mentions Ubuntu being part of the beta tester programme :)
<cypherbios> glatzor_:  currently aptoncd calls "/usr/sbin/synaptic", "--hide-main-window", "--non-interactive","-o=dir::etc=" + sourcesdir","-o=dir::etc::sourcelist=aptoncd.list"
<cjwatson> avoine: actually, I think 'mount -o bind' rather than 'mount --bind' - the mount in the installer doesn't understand --bind
<cjwatson> or maybe I'm wrong :)
<bryce> glatzor_: in fact that's why I was just checking out the ati driver ;-)
<cypherbios> glatzor: with the --ask-cdrom, but I'd like do the same using the software-properties, so it will work in a kubuntu box without synaptic
<cypherbios> glatzor: so software-properties-{kde|gtk} --add-cdrom --sources-list=/etc/apt/sources.list.d/aptoncd.list would do the trick
<glatzor> cypherbios: But I don't understand why you want to write into a different sources.list. Isn't enabling or disabling a repository using the software-properties or an editor the better way instead of copying sources.list files? 
<cypherbios> glatzor: it will not copy the sources.list, it will add the medium in the specified file, in a stand-alone mode, so I can remove, or edit the file in any way I (or user) want to, just to keep everything safe from mistakes
<cypherbios> btw, it's not essential, just an additional option would turn things nicer
<glatzor> ah I am a fool, cypherbios
<glatzor> I haven't seen the sources.list.d :)
<cypherbios> heh ;)
<cypherbios> glatzor: currently I can use software-properites $FILE, so it will use $FILE as sources.list, but if $FILE doesn't exist or it haven't any valid entry I will get an error, so in this case what we need to do is continue without a error
<glatzor> cypherbios: Hm, I am unsure about doing this by the using a command line switch. If it is available there will be users using it for other purposes :)
<glatzor> cypherbios: But I will implement it.
<cypherbios> glatzor: I understand.
<cypherbios> glatzor: oh thanks, it will be really useful 
<glatzor> cypherbios: We already added the --enable-component option for gnome-app-install. And I was quite surprised seeing bug reports and feature requests on Launchpad.
<glatzor> glatzor: but there are often bug reports that are written because users think that s-p behaves like a normal text editor.
<cypherbios> glatzor: unhappy new features usually brings new bugs =/
<cypherbios> glatzor: and what about a more 'hidden' option?
<cypherbios> glatzor: like an apt arbitary option (such the -o=$APT_PARAMETHER of the synaptic)
<cypherbios> glatzor: so we would use s-p -o -o=dir::etc::sourcelist=mycustomsources.list
<cypherbios> ops, too many '-o' ;)
<cypherbios> software-properties -o=dir::etc::sourcelist=mycustomsources.list
<glatzor> cypherbios: what kind of script do you use to run software-properties?
<glatzor> cypherbios: perhaps it would be nice to even use a python script and just import softwareproperties
<cypherbios> glatzor: it's python, it's a python application
<glatzor> cypherbios: then this could be a nicer approach.
<cypherbios> glatzor: indeed!
<cypherbios> glatzor: I was just afraid to implementing some 'feature' that wouldn't arrive the upstream
<cypherbios> glatzor: I need to go out. Thanks for the attention :)
<bryce> is anyone using kubuntu?  Could someone do a dpkg -S /usr/bin/hwdb-kde for me?
<glatzor> bryce: packages.ubuntu.com provides a file search function
<bryce> ahh, excellent, thanks
<keescook> hm, anyone know a way to find out what file maps to a fd without using /proc/$pid/fd ?
<Lure_> bryce: hwdb-client-kde: /usr/bin/hwdb-kde
<bryce> Lure_: thx
<superm1> keescook, can you possibly use fdlist?
<Lure_> bryce: apt-file might also help
<keescook> superm1: ah, also lsof, got it
<superm1> lsof will easily hang though in the case of an nfs server not being located
<superm1> not sure if there is a way around that
<bryce> Lure_: cool I didn't know about that
<bokey> hi with samhain package in sys admin universe, is lkm checked in default install ? 
<bokey> i see that samhainrc has lkm rootkit detection off by defualt
<bokey> anyone know why ?
<bokey> I am talking about version samhain (2.2.0)
<bokey> ~edgy sys admin universe
<bokey> Javier Fernandez-Sanguino if here please tell me
<cypherbios> Riddell: would adept have a --set-selections or --set-selections-file option?
#ubuntu-devel 2007-06-02
<Hobbsee> morning all!
<Burgundavia> hey Hobbsee
<Burgundavia> congrats on core-dev
<Hobbsee> hey Burgundavia :)
<Hobbsee> thankyou :)
<LaserJock> hi Hobbsee 
<Hobbsee> hi LaserJock :)
* Hobbsee curses sucky australian ip's
<mneptok> Hobbsee! Sarah Hobbsee! she's the strangest gal on IRC! from the ... town of Sydney ... she's been accepted to the core-dev teeeeeeeam!
<Hobbsee> mneptok: indeed!
<Hobbsee> mneptok: how do you feel about the fact which i can upload stuff that you have to support, unassisted?
<tonyyarusso> lol
<mneptok> Hobbsee: how do you feel about the fact i hnow have access to your home phone number for people pissed at your uploads? >:)
<mneptok> *now
<mneptok> "Please hold as I transfer you ..."
<mneptok> actually, that would violate the CoC in some way, so i guess i'll just keep hanging up on people.
<tonyyarusso> Hobbsee: Or even worse, mneptok has now gotten past the step of "getting your number".
<mneptok> but congrats, Hobbsomatic
<LaserJock> heh
<LaserJock> Hobbsomatic, that's funny
<bhale> oh
<bhale> so Hobbsee can sponsor me when my core membership expires in 6 days
<bhale> wee
<LaserJock> doh
<LaserJock> bhale: you better get that fixed
<bhale> LaserJock: meh.
<bhale> i dont upload often
<Hobbsee> mneptok: er, no you dont :P
<Hobbsee> mneptok: none of you has my home phone number
<Hobbsee> er, unless you found it on the conference call, i guess
<Hobbsee> tonyyarusso: i try not to think on that :P
<Hobbsee> mneptok: :)
<Hobbsee> bhale: nah....you should get that fixed.
<johanbr> Too bad Ubuntu doesn't have a separate set of devs that work on Ubuntu for Macs. In that case you could have called them the "Apple Core" team.
<bhale> Hobbsee: i wanted kevin to take over beagle, but he reguarly disappears
<bhale> Hobbsee: so it would be irresponsible to stop maintaining it, i guess
<Hobbsee> awww
* bhale tickles Hobbsee 
* Hobbsee tickles bhale back
* bhale squirms
<Hobbsee> :P
* Hobbsee --> lunch
* Hobbsee wonders if they really do have her home phone number now..
<mneptok> Hobbsee: i do not. it was 100% in jest.
<mneptok> Hobbsee: and you may be assured that if anyone does, abuse of that would meet with swift and irreversible vengeance.
<LaserJock> hmmm
<LaserJock> I wonder how much I'd have to pay to get Hobbsee's number
<LaserJock> it would be so much fun to do 3am "How's Gnome today?" calls
<mneptok> "GNOME"
<mneptok> :P
<Burgundavia> you people are disturbing :)
<Burgundavia> and I am in pain from getting my wisdom teeth out
<mneptok> there's always discussion of going with the name over the acronym, but nothing ever happens
<LaserJock> wha? surely you jest?
<bhale> Burgundavia: percoset is calling
<Burgundavia> had some less than 3 hours ago
<mneptok> Burgundavia: with vodka?
<LaserJock> Burgundavia: how many did you have taken out?
<Burgundavia> all 4
<LaserJock> yeah, that's no fun
<Burgundavia> mneptok: do not drink drugs with alcohol
<Burgundavia> it is actually pretty good
<LaserJock> I had mine 2 at a time over 2 weeks
<Burgundavia> the pain is just low grade and very annoying
<Burgundavia> prevents me from being able to concentrate, basiclaly
<LaserJock> yeah
<AndyP> wisdom teeth are just feature bloat
<LaserJock> my dental work is always in the morning and I'm just not much good at work all day
<LaserJock> AndyP: lol
<Burgundavia> AndyP: they didn't use to be
<AndyP> yeah, my orthodontist said jaws are getting smaller
<Burgundavia> nope
<Burgundavia> wisdom teeth exist because we would wear out our old teeth on hard food
<Burgundavia> basically, it was your third and final set of molars
<mneptok> the feature was made obsolete with the addition of libagriculture.so calls in v1.3
<Burgundavia> and then you died at 30
<AndyP> mneptok: :)
<Burgundavia> and dentist 2.0
<AndyP> so the moral of the story is chew more rocks
<Burgundavia> pretty much
<bhale> i like to eat ice
<bhale> i cant leave a cup with ice in it
<Burgundavia> try ice with grit in it
<bhale> yummy?
<mneptok> or a frozen v1.3
<Burgundavia> that will help the weardown of your old molars, leaving room from your wisdom teeth
<bhale> my wisdom teeth came out years ago
<Burgundavia> of course, this is all advice given by a man in pain and hopped up on drugs...
<Burgundavia> ok, new topic
<mneptok> Burgundavia: that's my epitaph
<Burgundavia> did anybody notice the total lack of press attention give to Fedora 7?
<bhale> yes
<evand> Obviously, it's not Ubuntu. :)
<Burgundavia> indeed
<LaserJock> I tried getting it downloaded today
<LaserJock> the instrument manager at the uni needs RH/Fedora systems for the Java app we have
<Burgundavia> ahh
<LaserJock> seems like most of the mirrors are pretty  hammered
<LaserJock> not as bad as Feisty by any means
<LaserJock> but seems like people are getting it
<Burgundavia> redhat has already had problems at release time
<AndyP> i had a go at yum upgrading to it from an FC6 install a few days ago... not a scratch on dist-upgrading a debian box
<Burgundavia> I think canonical just throws more resources at it
* minghua used BT to get FC 6
<LaserJock> Burgundavia: I used some of my usual mirrors
<LaserJock> UC Irvine had a sweet connection
<LaserJock> was getting 6MB/s
<LaserJock> but after 200MB it'd dump me
<Hobbsee> mneptok: heh.  true that.
<Hobbsee> LaserJock: a lot :P
<Hobbsee> i dont actually have a problem giving out my mobile - because only i asnwer it.  but i'm sure you all dont want to speak to my parents and such, who tend to answer the home phone.
<LaserJock> oh I don't know
<LaserJock> "Mr. and Mrs. Hobbsee, do you know where you daughter is?"
<LaserJock> "Well, I do"
<Hobbsee> hehe
<LaserJock> "She's been online all day with a bunch of nerds. And I bet she didn't even get her homework done/"
<Hobbsee> hehe
<Hobbsee> they've kinda figured that out
<Hobbsee> and i do try to keep doing my homework
<tonyyarusso> Hobbsee: I might - it could be entertaining
<Amaranth> pfft, you're core-dev now
<Amaranth> kiss homework goodbye, we own you
<Amaranth> who else will upload our stuff to main? :)
<Hobbsee> :P
<Hobbsee> tempting, tempting...
<Hobbsee> but i would fail uni that way
<Hobbsee> if i dont already, due to UDS and the aftermath
<AndyP> today's cartoon on pcweenies.org is very relevant to the homework conversation
* AndyP decides to get some sleep to cure his offtopicness, g'night
<Hobbsee> night welshbyte
<StevenK> Silly LeeJunFan ${whoami} expands to nothing.
<Hobbsee> StevenK: whoami is used in supybots, and other irc bots.  does seem a little odd there though
<StevenK> I was interpreting 'passwd -l ${whoami}' as a shell command.
<Hobbsee> indeed
<pygi> good morning
<Hobbsee> evening all
<bhale> hi Hobbsee 
<Hobbsee> :)
* pygi hunts down Hobbsee 
* pygi hides
* LongPointyStick attacks pygi 
<pygi> you do know that doesn't work, right?
* Hobbsee attacks pygi too, and roasts the remains
<Hobbsee> hi Spads 
<Spads> howdy
* Hobbsee wonders why it's so quiet everywhere
<pygi> people are working :P
<pygi> unlike some :P
* Hobbsee has been at work.
* Hobbsee has just gotten home.
<pygi> oh, ok :p
<bhale> Hobbsee: its 7:50am here..
<bhale> and earlier to the west
<Hobbsee> bhale: ah, point.  we're strangely short on europeans though
<Hobbsee> and australians, come to think of it
<ajmitch> hello Hobbsee 
<Hobbsee> hi non-aussie
<ajmitch> possibly due to the weekend, and people wanting to have a semblance of a social life
<bhale> speaking of social life, yesterday i somehow came upon a tab in firefox with "bars of kings cross"
<bhale> i havent the slightlest clue how i came to open that
<Spads> hmmm
<Spads> are there any good ones?
<bhale> I wasnt interested in bars in kings cross when i was IN kings cross
<bhale> Spads: not in my limited experience
<Spads> didn't think so
<Hobbsee> bhale: assuming you mean the kings cross in au?
<bhale> a bunch of nasty old fat guys trying to suck you into their strip club
<Spads> Oh.
* Spads was about to comment on chinese restaurants by St. Pancras
<Hobbsee> or offer you drugs
<bhale> I walked down that way at night with AndyFitz a few times for laughs
<ajmitch> it's an interesting area
* Hobbsee has never been there
<bhale> Hobbsee: perhaps an asian girl an lingerie will ask you if you want to "go upstairs"?
<ajmitch> the hotel for UDU was right nearby, it was the quickest way to get through to the city area
<Hobbsee> bhale: heh.  cant say that'd be tempting in the slightest - i'm straight.
<bhale> Hobbsee: I wasnt either, considering the circumstances
<Hobbsee> of course, had i been otherwise, i could have probably had plenty of fun with quinn...
<Hobbsee> *twitch*
<Fujitsu> Haha.
<Hobbsee> oh wait.  i'm not "big and curvy enough"
<bhale> wait a second..
* bhale boggles
<Hobbsee> hm?
<bhale> quinn has a beard
* elkbuntu_ joins in the twitching
<Hobbsee> not anymore
<elkbuntu_> bhale, not last month she didnt
<Hobbsee> quinn got rid of it for UDS.
<bhale> elkbuntu_: oh goodness
<elkbuntu> bhale, she lost that and gained something(s) else
<bhale> now i dont feel bad for being confused all this time
<ajmitch> heh
<Hobbsee> heh
<pygi> hey jsgotangco 
<jsgotangco> pygi: hi! how are things?
<Hobbsee> hi spam
<Hobbsee> hi pygi 
<jsgotangco> hey Hobbsee how's the night going
<pygi> Hobbsee, ^_^
<pygi> jsgotangco, pretty good. What about you/
<Hobbsee> jsgotangco: good, i escaped work :)
<jsgotangco> pygi: not bad, this week was promising, hoping for something to bear fruit next week
<mneptok> hrm.
<mneptok> Transmission is not a bad torrent client. a little too GUIfied for my tastes, but it will probably appeal to the Windows converts.
<Hobbsee> hi mneptok 
<mneptok> heya Hobbsee 
<Hobbsee> you've gotten over your horror, then?
<mneptok> my what now?
<mneptok> or, rather, *which* horror? every day is a new horizon! :)
<Hobbsee> over me being able to upload directly to what you have to support.
<Hobbsee> lol
<kylem> heya kurt.
<mneptok> oh, like i said, i can just continue to hang up on people.
* Seveas missed the 'on'
<StevenK> Surely he doesn't support Gutsy, so the pain won't hit until October ...
<mneptok> kylem: any MTL plans in the near future?
<Seveas> StevenK, that doesn't matter. He'll still hang up (on) people
<kylem> mneptok, heh, everywhere in the world but, unfortunately.
<StevenK> Seveas: He
<StevenK> Heh, even
<Hobbsee> heh
<mneptok> especially after checking $MAINTAINER since Hobbsee's core-dev acceptance
<mneptok> "Oh, you're having problems with ..... *click*"
<Hobbsee> mneptok: wont help.  see the debian maintainer field spec.
<Seveas> "Oh, that was uploaded by some weird aussie girl. Can't support that"
<Hobbsee> Seveas: purely evil bitchy psycopathic from au, tyvm.
<Seveas> Hobbsee, you forgot the pokey and cuddly :)
<Hobbsee> Seveas: purely evil sexy pyscopathic bitch from au, tyvm.
<Hobbsee> heh
<jsgotangco> "sexy"
<mneptok> Hobbsee: can we expect your unfailing adherence to the letter of the CoC now? ;)
<Seveas> mneptok, maybe the C
<Hobbsee> mneptok: no.  i'm afraid i'm still me.
<mneptok> I GOTTA BE ME, BABY!
<Hobbsee> Seveas: pokey as in me poking other people, or them poking me?
<mneptok> this. is. not. happening.
<Seveas> both
<Hobbsee> heh, right
* Hobbsee is glad there arent pictures from the airport, incidently.
<Seveas> there are :P)
<Hobbsee> oh?
<Hobbsee> where?
<Seveas> in my stash of blackmail pics
<Hobbsee> hah
<Hobbsee> like janew's of elkbuntu?
<Seveas> :)
<Hobbsee> well, wherever she's gotten that from
<jsgotangco> Hobbsee: well...
<Hobbsee> yes, spam?
<Seveas> speaking of blackmail, dinda still has to send me the video
<Hobbsee> whihc video?
<Seveas> me and markvandenborre singing
<jsgotangco> Hobbsee: you'll be dunked in the pool soon for sure
<Hobbsee> jsgotangco: nooo.  anyone who does will be in a *lot* of pain afterwards
<Hobbsee> as will popey.
<Hobbsee> besides, i did actually go in the pool
<Seveas> why popey? What did he do now?
<Hobbsee> there's even a picture of it
<Hobbsee> popey was evil
<Seveas> he still is
<Hobbsee> i know
<Hobbsee> he needs large amounts of punishmnet
<Seveas> but that's not enough to cast the Hobbsee spell on him
<Hobbsee> with a baseball bat.
<Hobbsee> heh
<jsgotangco> a baseball bat covered with barbed wire
<Hobbsee> a baseball bat with enough force can do lots of damage.
<StevenK> How about a chained mace?
<Hobbsee> that'd work
<jsgotangco> why settle for lots when you can do lots and lots more
<StevenK> Big metal spiky ball on a chain.
<Hobbsee> jsgotangco: because killing people tends to be against the COC.
<StevenK> (Also called a flail, for you pedants)
<Hobbsee> StevenK: yeah, that's starting to sound reasonable.
<StevenK> Hobbsee: I suspect airport security would have taken it off you. :-P
<Hobbsee> StevenK: who says i needed to use it at the airport?
<Hobbsee> any day on popey would have sufficed.
<StevenK> You needed someone to get it to Spain.
<StevenK> Er, some way
<StevenK> Sigh
<Hobbsee> i'm sure some guadalinux person could have brought it
<StevenK> Heh
<Seveas> s/could/would/
<StevenK> "I'd like you to bring a flail."
<StevenK> "
<racarr> I'm not sure how you manage to get through airport security with your fingers
<Seveas> hahaha
<StevenK> I bet they get that question at least twice a day.
<Hobbsee> hahahha
<StevenK> racarr: Hah
<Hobbsee> theyw ere more interested in my shoes than my fingers.
<racarr> Yes. Those hurt too.
* Hobbsee ponders that...
<Hobbsee> i guess popey could be made an example.
<pygi> the spinach guy?
<racarr> My toenails are still messed up from your vicious assault
<racarr> I'm not even kidding.
<Hobbsee> awww, sorry about that.  you'll have to blame Seveas for that, iirc.
<racarr> ...Yeah...he's definitely the person to blame there
<Seveas> Hobbsee, nope
<Hobbsee> as he had my wrists
<Hobbsee> or was it Mithrandir then?
<Seveas> I didn't stomp on his feet :)
<racarr> No, I'm talking about the other time
<Hobbsee> i only got your toes once.
<racarr> ...no...twice
<Seveas> maybe that was in the night you can't take responsibility for?
<racarr> Yeah, it was
<Seveas> :)
<Hobbsee> Seveas: i was about to say that
<Seveas> that night you even kissed popey
<Hobbsee> like i say, i dont remember much of that night
<racarr> That's awfully convenient for you
<Hobbsee> hah.  bullshit.
<Hobbsee> that i certainly didnt.
<Seveas> hhe
<elkbuntu> eh? who is talking about me?
<racarr> You did try to kiss/bite hans
* Hobbsee wonders what actually happened that night
<Hobbsee> yeah...well, he was in my face.  biting worked well.  works for fingers, too.
<jsgotangco> lol
<racarr> and nothing actually happened, we just sat on the couches (for a change!)
<racarr> oh wait.
<Hobbsee> i know i attacked you, but i cant really remember more detail than that.
<Keybuk> cor, NM worked today
<Hobbsee> yay!
<Hobbsee> morning Keybuk :)
<Keybuk> afternoon
<racarr> Three times actually. 
<Hobbsee> perhaps we make Keybuk carry the mace for next time.
<Hobbsee> then elkbuntu and i can use it on popey
<Keybuk> mace?
<Hobbsee> Keybuk: large implemetn used for hurting people.
<racarr> Err, just to clarify, are we talking about pepper spray mace or mace mace
<racarr> ah
<racarr> mace mace
<Seveas> Keybuk, now that Hobbsee is core-dev she wants to torture people
* Hobbsee pft
<elkbuntu> Seveas, and how is this different to before?
<Keybuk> Seveas: why else do you think she was approved? :)
<Hobbsee> haha
<Seveas> Keybuk, can't really think of something else :)
<Hobbsee> Keybuk: wouldnt shut up until i was?  :P
<mjg59> You mean she wants to keep people in line?
<racarr> No.
<mjg59> Sounds excellent
<racarr> Like, she wants to rip off their limbs
<Seveas> mjg59, more like in pieces
<Hobbsee> depends on what they do.
<mjg59> That would be a CoC violation
<mjg59> So I'm sure it won't be a problem
<Hobbsee> mjg59: that's entirely dependant on symantics.
<racarr> semantics too
<Keybuk> mjg59: not if she did it respectfully
<mjg59> At least, I really hope we don't have to explicitly add "Physical violence" to the list of things that aren't allowed
<Hobbsee> and who we're talkinga about pulling apart
<Hobbsee> racarr: yes, thankyou
<Seveas> mjg59, there is a loophole in the CoC - we figured that one out when talking about a certain person :)
<Hobbsee> Seveas: hahahhaha.  yep
<Hobbsee> mjg59: then i'd get shot at UDS.  mind you, Seveas did try to break my wrist.
<Keybuk> Seveas: you mean apart from the fact it doesn't say "I agree..." anywhere in it?
<racarr> poor non-violent Sarah attacked
<Hobbsee> indeed.
<Seveas> Keybuk, heh :)
* Hobbsee looks sweetly and innocently around
<Hobbsee> surely i wouldnt bash anyone up?
<Seveas> fail
<Keybuk> zshing people up is more fun
<Hobbsee> unless they deserved it, of course.
<kylem> crestline is awesome.
<Hobbsee> which popey does, hence the need for the mace.
* desrt is fairly sure that he didn't read anything about dismemberment in the CoC
* Seveas tcshs Keybuk  
<racarr> I only deserved it one time :/
<mneptok> racarr: "Rip off people's limbs and beat them with the wet end." tyvm ;)
<Hobbsee> desrt: exactly
<Hobbsee> desrt: so it must be pending a CC decision, which hasnt occured yet.
<Keybuk> "'tis but a flesh wound!"
<Hobbsee> so it must be fine.
<mneptok> Keybuk: you a zsh user?
<Hobbsee> exactly!
<desrt> Hobbsee; they can't fault you on that which has not yet been decided
<Keybuk> mneptok: yes
<Hobbsee> desrt: exactly
* Hobbsee must then bash popey quickly.
<Hobbsee> and anyone else who deserves it
* Seveas hides
<mneptok> Keybuk: suave! we need to identify others in the company so we can start feeling superior!
<Keybuk> mneptok: getent passwd | grep zsh
* jsgotangco is lurking the chan
<elkbuntu> Hobbsee, can I add people to your list? :D
* Keybuk wonders what he has to do to earn a beating
<Hobbsee> elkbuntu: sure.  who were you thinking of?
<Hobbsee> elkbuntu: you could just join me
<elkbuntu> Hobbsee, half the commenters to my blog ;)
<Hobbsee> Keybuk: i dont think you'd like the type of beating i'd give
<desrt> Keybuk; i've got you covered, if you like.
<racarr> Keybuk: Basically, you spend time around her
<Keybuk> Hobbsee: maybe I'm into S&M?
<Seveas> elkbuntu, stab-over-ip :)
<desrt> Keybuk; and bible studies?
<racarr> Keybuk: And it just kind of happens after that
<Hobbsee> Keybuk: i'd guessed as much, but presumably not into being bashed in the head.
<mjg59> Keybuk: Dude.
<elkbuntu> Seveas, i'm yet to hear the result of that project
<desrt> Keybuk; not everyone's cup of tea....
<mjg59> I think that's -offtopic fodder
<racarr> Hobbsee: Or shoved off a balcony.
<Seveas> mjg59, unlike the rest of this talk :)
<Hobbsee> Keybuk: i suspect being smashed out isnt your idea of a good time.
<mjg59> "Topicdiff: Added "Discussion of sexual preferences is not on-tpoic"
<Hobbsee> haha
<elkbuntu> mjg59, only if you care to join us to lart the ones that get a bit too excited
<desrt>  /topic Dev of ubuntu (no help, no gutsy, no app dev, no fetishes)
* Hobbsee makes a note to coat herself in metal the next time she meets you people.
<Hobbsee> that way, i cant be broken.
* desrt makes a note to bring an MRI machine
<jsgotangco> you'll sink in the pool though
<mneptok> Hobbsee: we'll just pee on you until you rust
<Hobbsee> jsgotangco: i wont be going in the pool.
<racarr> ...
<elkbuntu> mneptok, eeeewwwwwwww
<racarr> that was just a strange threat
<mneptok> racarr: it was no threat.
<Hobbsee> racarr: mneptok's strange.
<jsgotangco> that is really strange
<elkbuntu> racarr, you haven't met mneptok before?
<Seveas> racarr, mneptok is the definition of strange
<racarr> I don't think I have?
* desrt likes mneptok :)
<Hobbsee> Seveas: i thought he was the definition of batshit insane
* mneptok is the village bicycle!
<Hobbsee> although maybe that's some of the customers.
<mjg59> Hm.
<Seveas> mneptok, macho man :p
<Hobbsee> mjg59: hm?
<mjg59> Seriously, I think this should probably go elsewhere :p
<Hobbsee> meh.  there's nothing else going on
<elkbuntu> mjg59, as humourous as it is, i agree
<Hobbsee> and i still need to figure out how best to injure popey :P
<Seveas> it's caturday. Who's doing serious work?
<mjg59> Well, I'm hung over
* Hobbsee was.  but that was earlier.
<Seveas> heh
<Hobbsee> awwww
<mjg59> Otherwise I would be
<Hobbsee> so you're on irc
<Seveas> hangover + mneptok == bad idea
<Hobbsee> so that's why you werent at the meeting yesterday...
<Keybuk> mjg59: I'm surprised you're up!
<mneptok> oh dear. when i've crossed the mjg "inappropriate threshhold" it *really* means i'm over the line.
<desrt> Seveas; er.. isn't there something about "the dog that bit you"?
<desrt> Seveas; it might work
<ompaul> Seveas, and anything that might induce that state for mneptok might also be an issue :)
<mneptok> don't hate me because i'm beautiful.
<Hobbsee> desrt: why a MRI machine, btw?
<mjg59> I woke up to find a beer next to my bed
<mjg59> So I did the right thing
<ompaul> mjg59, are you going to share that information with us?
<desrt> Hobbsee; 3..7T magnetic fields
<Hobbsee> desrt: heh, right.
<desrt> Hobbsee; if you have a quarter in your pocket a few metres away you're gonna feel it
<Hobbsee> mmm....beer.
* Hobbsee doesnt deal in quarters
<desrt> Hobbsee; if you're dressed in metal you're gonna be somewhat worse off
<Hobbsee> cue Hobbsee flying across the room.
<Seveas> hmm
<Hobbsee> besides, i doubt Keybuk ever saw me being violent.
<Keybuk> I don't believe so
<Hobbsee> so you shouldnt give him other ideas now.
<ompaul> Hobbsee, hang on to the pointy stick of doom as you fly across the room ;-)
* Seveas brings an extra MRI machine for more flying
<Hobbsee> heh
* Hobbsee always wanted to fly.
<Hobbsee> maybe that should go on my todo list.
<ompaul> Hobbsee, you swam to spain?
<Keybuk> I find that feeling wears off about 1/3 the way on a LHR/SYD hop
<Hobbsee> ompaul: i meant without a plane
<Hobbsee> Keybuk: haha, yeah.
<Hobbsee> Keybuk: that far in, hey?
<desrt> Keybuk; if you're flying *from* LHR, the feeling wears off standing in the various lines
* Hobbsee wasnt insane enough to fly thru LHR.
<Keybuk> Hobbsee: flying without a plane
<Keybuk> I believe that's technically known as "falling"
<Hobbsee> Keybuk: in which direction, though?
<Keybuk> downwards
* Hobbsee would like to be able to fly without falling
<mneptok> or "time for rehab"
<Hobbsee> awww
<elkbuntu> Hobbsee, or without unionised pigeons
<Hobbsee> who's doing the rehab session?
<Hobbsee> heh
<Hobbsee> mmm...pidgeons
<Hobbsee> elkbuntu: you do realise that if we hadnt been delayed out of singapore, we would have been delayed due to fog in sydney, most likely?
<Seveas> Hobbsee, flying's not that hard. You let yourself go and be distracted just in time so you miss the ground 
<Keybuk> Hobbsee: that usually involves a Cessna
<Hobbsee> heh
<Hobbsee> Keybuk: hmm?
<elkbuntu> Hobbsee, still, it's worth demonising the pigeons
<Hobbsee> hehe
<Hobbsee> then there could have been mroe plane flights!  woo!
<Hobbsee> twitch.  shudder.
<elkbuntu> Hobbsee, then we could have topped ajmitch's record!
<Hobbsee> indeed!
<Hobbsee> you could have, anyway
<elkbuntu> instead of equalled
<elkbuntu> yeah, i could have
<Hobbsee> heh
* Hobbsee ponders
* Hobbsee wonders why people have such an obsession with throwing her in the pool.
<racarr> Because you keep on bringing it up.
<desrt> Hobbsee; don't take it personally.  i got it at UDS too :(
<Hobbsee> racarr: i didnt originally though
<racarr> "Why do you always want to throw me in the pool!" "Oh yeah, we forgot about it, go for it!"
* Hobbsee points at Seveas 
<desrt> never trust the french :(
<racarr> Well
<Hobbsee> desrt: heh.  or the dutch.
<racarr> yeah, but that's Seveas
<Hobbsee> especially the mad dutchmen.
<desrt> :)
<racarr> and even he got over it
<Seveas> indeed
<racarr> Plus, I think I was the only one that came close to being thrown in the pool
<Hobbsee> eventually.  maybe.  before he got bashed with a large metal object, anyway
* Hobbsee isnt violent.  really1
* Hobbsee isnt violent.  really
* Hobbsee isnt violent.  really!
<Hobbsee> gah.  third time lucky.
<elkbuntu> SPAMMER!
<Hobbsee> guilty as charged.  what will you do?
<mc44> Hobbsee: protest too much?
<Hobbsee> actually, dont do that.
<elkbuntu> Hobbsee, tickle you mercilessly next time you're within reach
<racarr> mc44: Expect her to deny it three times
<Hobbsee> elkbuntu: oh dear.
<Hobbsee> elkbuntu: but we had an agreement!
<Hobbsee> so we'd survive on the plane...
<elkbuntu> Hobbsee, who said it would be on a plane
<Hobbsee> "oh dear, the two aussie chicks on the plane to UDS died due to excessive tickling and poking"
<Hobbsee> what other reason would you have to be in sydney?
<Seveas> AUSTRALIANS ON A PLANE!
<Hobbsee> OH NOES!!!
<Keybuk> you can always tell the Australians at Heathrow
<Keybuk> they start giggling when the tube train arrives to take them to the city
<Hobbsee> Keybuk: well, we did go down to BA by accident.  so we almost went to heathrow :P
<Hobbsee> we dont have tube trains here.
<elkbuntu> yeah, stupid frankfurt
<Hobbsee> unfortunately
<Hobbsee> hehe
<Hobbsee> NO MY SHOES DO NOT CONTAIN EXPLOSIVES.  kthxbye.
<Seveas> *boom*
<elkbuntu> at least we got to part ways with the screaming toddler
<Hobbsee> haha
<Hobbsee> yes
<Hobbsee> Seveas: yeah, well.  elkbuntu didnt explode due to lack of smoke
<Seveas> "MY SHOS DON'T CONTAIN EXPLOSIVES, BUT IF YOU DON'T STOP BEING ANNOYING *I* WILL EXPLODE"
<Hobbsee> haha
<racarr> elkbuntu: I'm hurt that you would say that.
<elkbuntu> racarr, no, you're the baby :
<Hobbsee> racarr: because you're jealous of the screaming todler?
<Hobbsee> and wanted to be the screaming todler at UDS, being the youngest?  :P
<racarr> ...err. No? The joke was
<racarr> eh
<racarr> nevermind
<elkbuntu> racarr, first day onestone was there "whelp.. better go wake the baby"
<racarr> elkbuntu: ...
<elkbuntu> i cant remember who else heard that, probably tonio
* Hobbsee rofl's
* Hobbsee didnt...
<Hobbsee> why didnt you tell me this?
<Hobbsee> i could have teased him with it all week!  :P
<elkbuntu> racarr, if it makes you feel better, i think it was s/the/my/
<Hobbsee> as well as being a crazy american tourist.
<racarr> elkbuntu: Err...
<Hobbsee> elkbuntu: i think you traumatised him now.
<Hobbsee> elkbuntu: what were you saying about "think of the children"?
<elkbuntu> Hobbsee, ;)
<ompaul> racarr, s/tourist/hacker/g - she don't know the diff :-)   
<ompaul>  /me runs
* ompaul runs (even)
<racarr> If she used emacs it has a mode for comparing tourist hacker diffs.
<racarr> See what you are missing out on Hobbsee?
<ompaul> racarr, :-)
<Hobbsee> racarr: haha
<Keybuk> oh, wow
<Keybuk> the GNOME Typing Break thing supports compiz/beryl
<Keybuk> and dims the background without evil pixmap copying
<Keybuk> that is so awesome
<wasabi> if only the logout button and upgrade manager did that
<Hobbsee> nice!
<Hobbsee> does it do kde?
<Hobbsee> :P
<Keybuk> wasabi: *looks pointedly at racarr* I'm sure they can <g>
<wasabi> yay latest kernel breaks vmware... again
<Keybuk> wasabi: ?
<racarr> It's just a matter of checking for a composite manager selection and setting an XProp, so yeah easy
<racarr> it would be nice for the screensaver too so there is not that flicker
<wasabi> I'd like to see the screen saver actually take advantage of it in some cool way.
<wasabi> FOr instance, draw the screen saver BEFORE blacking the background, gradually.
<wasabi> So fish start swimming across as the background darkens.
<Keybuk> I use the glslideshow screensaver
<Keybuk> I thought it'd be really cool if the first thing it did was pan the desktop about, then fade into a picture
<Keybuk> :p
<wasabi> heh yeah
<racarr> *shrug* If the screensaver didn't black the background when there was a composite manager
<racarr> then the composite manager could fade it in like everything else
<wasabi> I'd like to see Nautilus do it for desktop background too.
<wasabi> OS X has this thing where you can run screensavers as desktop backgrounds: slide show being one.
<Keybuk> I guess compiz gets rid of the need to do cheesy gamma slides too
<wasabi> And it will do the fading transitions on the background, with the icons staying put
<Keybuk> ooh, Recent Documents got fixed too
<racarr> You could do that with xwinwrap if you were using Xgl
<racarr> With the background, I would kind of like to see the composite manager draw the background, and the desktop manager draw the icons on to a transparent window.
<Keybuk> yeah
<wasabi> yeah totally
<racarr> Because if you want different wallpapers per viewport, then you need to have one desktop window for each viewport (it's not practical to create a window that spans them all obviously), and if you had say 3*3 viewports, and half of them were using the same wallpaper
<Keybuk> nautilus has this weird window it draws across the root, doesn't it
<wasabi> Yeah, i've always wondered why it does that... can't it just draw to the root?
<Keybuk> wasabi: iirc, it's so it can draw the icons on top of it
<wasabi> Can it not somehow take control of the root? :)
<Keybuk> oddly enough, this makes it easier to fix
<Keybuk> since we wouldn't want it drawing to the root anyway
<wasabi> Oh, that's true... it can draw a transparent root
<racarr> that's a complete waste of RAM, because the desktop manager will have to create multiple windows for each with the same wallpaper, but the composite manager can just have one texture and draw it on a quad :P
<Keybuk> it just needs to leave the window transparent and let the composite manager do the merging
<Keybuk> and then leave the background to the manager
<racarr> it would be really easy to patch actually I don't know if GNOME would want it...
<Keybuk> this would likely be a trivial patch
<Keybuk> *shrug*
<Keybuk> Ubuntu would like it <g>
<Keybuk> different desktop backgrounds per screen seems like a bling feature to me
<wasabi> This would let you run xscreensaver -root too
<Keybuk> you could have 4 in a row, with a panorama
<wasabi> Which would solve the entire thing
<elkbuntu> Keybuk, it's a common question, for sure
<Hobbsee> Keybuk: and if shoved hard enough, GNOME might like it too?  :P
<wasabi> I don't see why Gnome wouldn't want it
<elkbuntu> wasabi, *cough*linus*cough*
<Keybuk> Linus doesn't use GNOME
<wasabi> yeah heh
<wasabi> metacity has composite support no
<elkbuntu> Keybuk, but he submitted patches to it, and they rejected them
<Keybuk> patches to do what?
<racarr> wasabi: Err, no, the composite manager is drawing to root....
<elkbuntu> Keybuk, some part of gnome, cant remember which
<wasabi> racarr: oh yes... hmmm
<Keybuk> probably changing metacity to behave differently
<Keybuk> or adding an option
<Keybuk> GNOME really hate it when you give them patches to do that
<elkbuntu> Keybuk, i think the latter
<racarr> Anyway, I will make the patch for nautilus
<racarr> Later today or something
<racarr> and err, the patch was to make the third mouse button configurable in metacity?
<racarr> patches
<racarr> I think
<wasabi> So what you really need to do, to accomplish what I want, is for xscreensaver to introduce a new fullscreen window.
<wasabi> just on top of root, but under everything else
<wasabi> including nautilus
<elkbuntu> racarr, that or printing.. my brain keeps saying printing, but i dont trust it
<racarr> elkbuntu: I am sure it was related to a third mouse button, I just don't remember in what regard
<racarr> wasabi: Yeah, or err
<racarr> wasabi: For the composite manager to render the desktop
<racarr> we would have a Pixmap for the contents obviously, and bind a texture to it to actually render it
<Keybuk> so the composite manager would grow a background plugin?
<racarr> so we could expose the Pixmap via an X property (and obviously this is cheap because it is all server side)
<racarr> and then your screensaver program could use XRender to composite on to the Pixmap
<wasabi> I don't see why the background can't be handled exactly like it is now... a big full window.
<racarr> to draw on the background
<wasabi> It can just be ANOTHER big full window, under nautilus
<racarr> Well, it could be
<Keybuk> wasabi: you'd need a window per viewport?
<racarr> but this would save you another big window
<wasabi> Yes. Which would give you the multi background thing.
<racarr> Err, wait, are you talking about screensaver on desktop, or the actual background?
<wasabi> Both.
<racarr> the reason you want the composite manager to draw the background
<wasabi> You could write a program to do the background, any background. Moving or not.
<racarr> is because you NEED a window per viewport, so if you have 5 desktops that are the same, and 5 that are different
<racarr> you need 10 times fullscreen sized windows, you don't with the compositor 
<racarr> plus if you give the compositor a 3000x3000 image
<racarr> and it draws it on to your 1280x1024 background
<racarr> then it's scaled by GL obviously, so with say the zoom plugin
<racarr> when you zoom in, you wouldn't lose quality
<racarr> no pixelatin I mean
<wasabi> hmmm
<racarr> on
<wasabi> yah but you lose quality on the rest of the desktop
<wasabi> so we should fix that. :)
<racarr> Yeah, but either way, it saves resources, and has a potentially nice effect
<wasabi> Well, my only desire is to use xscreensaver for hte background.
<wasabi> And I don't use viewports or nothin.
<racarr> again, you can use xwinwrap to do that but it relies on XGL specifically 
* Keybuk wants a 5120x3072 background image <g>
<wasabi> either way, I could just ignore the composit manager's background.
<racarr> Um, you could put a window under the transparent nautilus window as well
<racarr> right
<wasabi> Yeah
<racarr> Or, the composite manager could set an X property on the desktop window that contains the Pixmap being used for the background
<racarr> so that other apps can draw in to it
<racarr> You obviously can't do that reliably if you have a window as the background (because it gets repainted when you interact, etc)
<wasabi> I'm not even sure how viewports work at that level.
<racarr> Pixmaps*
<racarr> Keybuk: And yeah, the compositor would get some sort of wallpaper plugin.
<racarr> Err, a second too late :P
<wasabi> Explain that again, I missed it. Why is it better for the compositor to do this?
<racarr> We actually already sort of have it built in to cube but eh
<racarr> wasabi: Ok, so if you have 3*3 viewports
<wasabi> okay
<racarr> and say a hypothetical 100x100 resolution
<ion_> Id like a *slowly* changing nice-looking animation as a background. A composite manager collaborating with the desktop would achieve that trivially.
<racarr> and lets say you want a different wallpaper on each viewport, or anything besides the same wallpaper on every viewport (even with 8 with 1 background, 1 with another)
<wasabi> ion_: So would xscreensaver running as a window right above root.
<racarr> then you need 9 100x100 windows
<wasabi> racarr: Okay?
<wasabi> racarr: And how is 9 windows any worse than  9 viewports?
<racarr> Because 9 fullscreen windows sitting in video ram is a lot
<wasabi> Would they be there if you weren't viewing their screen?
<racarr> But lets say in reality you only had
<racarr> 2 backgrounds, 
<racarr> and were tiling them on your 9 viewports
<racarr> then with the composite manager drawing it, you can get away with having only 2 pixmaps
<racarr> as opposed to 9
<wasabi> All 9 are in video ram even when you aren't viewing them?
<ion_> wasabi: It wouldnt be very easy to have antialiased desktop icons and text against that.
<racarr> yes, that's what you have to do with viewports
<ion_> wasabi: Without compositing, that is.
<racarr> as opposed to workspaces
<wasabi> ion_: We are talking aout compositing.
<ion_> wasabi: Yes. :-)
<wasabi> racarr: Could the viewports reference the same texture in the server?
<wasabi> err, the 9 windows.
<wasabi> Not the viewports
<racarr> wasabi: Err, there is not a texture from the perspective of the windows
<wasabi> Well, pixmap then
<racarr> Not...really 
<Keybuk> compiz is crashing!
* Keybuk cries
<wasabi> oh noes!
<racarr> they could reference the same image for the background, but they still have to have their own windows to draw the background on
<racarr> and the window has a pixmap
* Keybuk blames Amaranth 
<Hobbsee> Keybuk: blame racarr 
<racarr> Keybuk: Err, I said this a second or so after you left
<racarr> yes the compositor would have a background plugin added, but we already sort of have one
<wasabi> So what are viewports? Something created by the compositor itself?
<wasabi> Without help from the X server?
<racarr> no...there is help from the X server...mm. but the compositor can reuse the same 2 pixmaps
<racarr> because from the perspective of the compositor, drawing the desktop background
<racarr> is just drawing a quad with a texture before it draws the other windows
<racarr> Hobbsee: Thanks :)
<wasabi> Hmm. So, In the 9x9 situation, why would there have to be 9 windows?
<Hobbsee> racarr: no problems, crazy american tourist.
<wasabi> Why can't you have one window per desktop, and show it on the viewports it belongs one
<wasabi> on
<wasabi> err, one window per diferent picture
<racarr> Err, you mean 3x3 ?
<wasabi> yes, or 9x9 =)
<wasabi> Windows can span viewports...
<racarr> And, you sort of could with a protocol to tell the compositor "This window covers these viewports, this window covers these other viewports"
<racarr> etc
<Keybuk> so today turns out to be a bad day to have dist-upgrade'd
<racarr> but that's also kind of strange, because if you right clicked on the window, and a menu popped up, in some situation where you can see more than one viewport
<wasabi> racarr: Can't you have one window on many viewports?
<racarr> then it would only show on the ones that had the same desktop background :P
<wasabi> the popup menu wouldbe it's own window
<wasabi> on the single viewport that existed when it was right clicked on
<racarr> No
<racarr> well
<racarr> yes
<racarr> but it would be drawn in various places, just like the desktop window (under your scheme)
<wasabi> Okay, first question, can a single window exist in multiple viewports at the same time?
<wasabi> I was under the impression that it could
<racarr> Yes. 
<wasabi> And the program creating the window can control what viewports.
<racarr> In that it can move it in to a viewport, yes
<wasabi> Hmm, but it can't be seen on both?
<racarr> It can...like when you move a window over the edge in cube
<racarr> and you can sticky a window, i.e. in all viewports
<wasabi> compiz gives me a selection which lets me decide what viewports the window shows on
<racarr> Yes
<racarr> But, for desktop windows
<racarr> desktop windows are right now painted in every viewport, so like I said
<wasabi> actually compiz crashes today. heh
<racarr> there would have to be a way to tell the compositor "make me the desktop window for viewports 2 3 7 and 9"
<wasabi> Why the "desktop window?"
<wasabi> Why not just another application owned window, that happens to be one z-index above root
<wasabi> Why does the compositor care?
<desrt> wasabi; 'sup
<racarr> the desktop window is just another application owned window with certain hints set
<wasabi> desrt: nothin. you?
<racarr> so that say it doesn't show up when you use alt tab so you can't move it over all your other windows
<wasabi> sre...
<wasabi> sure... and these application owned windows can't set that?
<desrt> wasabi; my arm hurts
<racarr> ...they can
<wasabi> ... desrt, why?
<racarr> but right now there is no way to say "make me the desktop window for viewports 2 3 7 and 9"
<racarr> just "make me the desktop window"
<wasabi> Hmm. I guess I still don't follow. You speak about the "desktop window" like it's some special thing... but I don't see why. Seems to me it's just a window that's big and has some hints that say keep below everything else.
<desrt> wasabi; too much hacking!!
<racarr> and that says "draw me in every viewport"
<racarr> imagine if the desktop were a giant table, divided in to 2x2 viewports
<racarr> then the desktop window is only as big as one of the viewports
<wasabi> But I thought windows could be set to draw on multiple viewports.
<racarr> Yes, but right now when you set a window as the desktop window it's assumed it draws on ALL viewports
<wasabi> So don't set that. =)
<racarr> so, again, you would have to implement a way to say "I only want to be the desktop window for 2 3 7 and 9"
<racarr> well, that would break things
<desrt> this is all IICCCCMMMMMM stuff
<desrt> you could change it -- but then you'd have to change every window manager ever
<racarr> wasabi: What I mean is, things would have to be changed, so that you can still say "Hi I'm a desktop window"
<racarr> without saying "Hi! draw me on every viewport"
<racarr> desrt: No, it could check for NET_WM_NAME = compiz before behaving like this
<wasabi_> So the basic problem is it has to be hinted as a "destop window", but that carries consequences that you don't want.
<desrt> so compiz-only features?
<wasabi_> And what does being hinted the "desktop window" actually do other than draw it on all desktops?
<desrt> wasabi; there's a "sticky" option
<desrt> wasabi; that causes the window to be visible on all desktops
<racarr> things like
<racarr> if you click on the desktop window
<racarr> it's not raised
<racarr> etc
<racarr> (that
<wasabi_> but you can make any window that doesn't get raised when you click on it, no?
<racarr> 's all handled in the window manager obviously)
<wasabi_> heck, the gnome panel does that
<racarr> Yes, with the Panel type 
<wasabi_> Oh, so there is no setting for "do not raise me" other than this "type" thing
<desrt> "dock"
<desrt> wasabi; read the spec
<racarr> Yes...there is, but it's a collection of settings, and various things check for the desktop window in effects
<desrt> wasabi; it's like a cookbook of tricks that you can use
<racarr> etc
<racarr> if you have a desktop window, you really need to be saying it's a desktop window rather than misrepresent it as something else
<racarr> but it would be trivial to add something to tell the composite manager
<wasabi_> hmm.
<desrt> wasabi; you'll probably find either exactly what yr looking for or some combination of things that you can abuse for the desire effect and flame the maintainers of various window managers when it doesn't work like you expected
<racarr> "I don't want to be drawn on all viewports just 1 3 7 8 and 9"
<wasabi_> okay, so I see your point. You'd have to alter compiz to let the desktop window be on arbitrary viewports
<racarr> yes, and it would be easy
<wasabi_> And then you could have multiple desktop windows, done by a program other than compiz.
<wasabi_> For instance, I could alter xscreensaver to open a desktop window on a specific viewport.
<racarr> Sure
<desrt> you know that viewports don't actually exist, right?
<wasabi_> desrt: Sure, they are just hints to the window manager, no?
<desrt> wasabi_; not even that
<desrt> wasabi_; the window manager just treats each window it knows of as if it were part of a particular viewport
<racarr> No...that's workspaces :)
<desrt> wasabi_; and when the viewport changes (an operation that is contained solely within the wm) it unmaps/maps windows to "show" the correct set
<racarr> again, no
<racarr> that is workspaces
<desrt> oh
<wasabi_> pwnt
<desrt> yes.  i do mean workspaces
<desrt> what are you talking about viewports?
<racarr> viewports are entirely different
* desrt just assumed you were abusing terminology
<racarr> Ah, no, heh
<racarr> this problem wouldn't exist with workspaces (just because it wouldn't be relevant as something desirable)
<Riddell> Keybuk: able to give back xine-lib?
<racarr> Err, anyway wasabi  it would be easy to extend Compiz to let per viewport wallpapers work well with a normal desktop manager (we used to have this in Beryl with a desktop manager I wrote that made one window per viewport), but there are a few reasons I would like to have the composite manager draw the viewport under a transparent desktop window that contains the icons instead...
<racarr> Mostly, the fact that it lets us make it work with desktop managers with very non obtrusive changes (patching a desktop manager to draw icons on a transparent desktop window rather than one with a background will be really trivial)
<racarr> whereas patching nautilus to make multiple windows would be much more so, and the same would have to be done for all desktop managers
<racarr> and then when you get in to effects like fading the backgrounds without touching the icons, you would again have to modify all the managers, etc
<racarr> whereas if we do it in the compositor we get it for free, and because we have OGL to draw with we can do more interesting effects
<racarr> Then there is the nice side effect that if you give the composite manager an oversized desktop background, you can avoid pixellation when zooming
<wasabi_> Well, we should be able to do that for all windows, some day
<racarr> Err, do what for all windows?
<wasabi_> zoom without quality loss
<racarr> Oh
<racarr> that's a ways off :P
<wasabi_> yeah. vista does it.
<racarr> Err...I haven't used Vista much, but that would be news to me
<wasabi_> It does it over remote desktop too.
<wasabi_> Their "window server" thing (much like X), has vectors uploaded to it.
<wasabi_> It's basically a retained graphics model out of process.
<racarr> Do you mean just for fonts, or what?
<wasabi_> No, for everything.
<wasabi_> Well, all NEW things.
<wasabi_> Buttons, lists, whatever. All new widgets.
<wasabi_> Animations and stuff too.
<wasabi_> They upload their drawing operations (basically vectors, and instructions) into the display server.
<racarr> Yes, that's what we do
<wasabi_> So the display server can zoom, and replay the operation to obtain a perfectly zoomed version
<racarr> then the display server draws them to a pixmap
<wasabi_> No pixelation
<racarr> and the composite manager renders them
<racarr> so when it zooms, the texture/pixmap is scaled
<wasabi_> Yeah, vista redraws when zoomed.
<wasabi_> No scaling
<etank> pygi: ping
<racarr> Mm, that's new to me, but interesting I guess.
<pygi> etank, you're fast if I may add ^^
<etank> why yes i am
<wasabi_> It's interesting because they have it working in RDP (remote desktop)
<pygi> glad to hear you wanna become a motu etank ;)
<wasabi_> If you remote from one box to another, it doesn't actually move final composited images across teh wire.
<pygi> I'm here to assist you with whatever questions you might have :)
<wasabi_> It moves the vector tree.
<racarr> Keybuk: Do you think I should put some stuff in to the composite by default spec about the desktop stuff we just discovered ?
<racarr> err
<etank> pygi: cool
<racarr> Keybuk: discussed, not discovered
<wasabi_> And animations happen on the display server.... like moving a button from position X to position Y.... happens on the RDP client
<racarr> It's not really clear to me if you are talking about stuff we have had on X since it was created (network transparent protocol...)
<racarr> or something new
* Hobbsee --> bed.  night all
<pygi> night Hobbsee 
<racarr> Bed as well, somethings slightly wrong about the fact that I am going to sleep at the same time as someone 12 timezones away... (or is it 10?), but eh
<wasabi_> racarr: in X clients draw to a bitmap. The drawing instructions live on the client. In the new Vista stuff, clients upload SVG's and animation sequences to the server, and the server renders them.
<wasabi_> But not really SVGs, their own stuff
<Chipzz> Keybuk: actually the reason for nautilus drawing the background is to be able to have anti-aliassed text
<TomaszD> Can anyone tell me when the next translation update takes place for feisty?
<TomaszD> I'm a translator for Ubuntu and I'd like to know this, will it ever take place? Martin Pitt told me it would happen in May, but it didn't.
<mpt> TomaszD, pitti will likely be back on Monday
<mpt> if you want to ask him directly
<TomaszD> mpt, is he the only person who knows that?
<TomaszD> :] 
<mpt> I don't know, sorry
<pochu> TomaszD: maybe carlos too, but he's not around atm.
<TomaszD> ok
<TomaszD> thanks
<mneptok> TomaszD: have you asked on ubuntu-translators@lists.ubuntu.com ?
<TomaszD> I haven't. 
<mneptok> might help. *shrug*
* mneptok is marginally helpful! :/
<minghua> I remember reading about the translation update plan somewhere
<minghua> can't remember exactly where though
<LaserJock> me too
<minghua> LaserJock: I remember you said that you couldn't reproduce the octave2.9 wrong result bug on feisty i386, is that right?
<LaserJock> yep
<LaserJock> I got the "correct" result according to the link in the bug report
* minghua wonders why LaserJock only hang out in -devel, but not -motu, today
<minghua> LaserJock: would you please add that to the bug report?  it's bug 117517
<ubotu> Launchpad bug 117517 in octave2.9 "octave is linking incorrectly BLAS/ATLAS libraries" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117517
<sits> Could someone point me to the right IRC channel to discuss a kernel bug?
<LaserJock>  #ubuntu-kernel I'd guess
<sits> LaserJock: thanks
<Keybuk> Chipzz: that's what I was attempting to say :p
<Keybuk> icon shadows, text, etc.
<Keybuk> of course, this is pre-Xrender
<Keybuk> cause you can have anti-aliased text without doing that now
<Keybuk> racarr: no real opinion; it could be a separate spec (and a feature goal), but if it's more trivial to implement than describe, patches are better ;)
<Chipzz> Keybuk: you need (more-than-1-bit)-transparency though
<Keybuk> Chipzz: yes, Xrender
<Keybuk> that gives you 8-bit transparency (iirc, it may be 16 or 32)
<BenC> Keybuk: mind processing linux-source-2.6.22 6.13 out of NEW for me, please?
<BenC> got lrm and lum dep-waiting on it, and linux-meta awaiting upload
<Keybuk> the perils of logging in on Saturaday
<Keybuk> is there any special procedure for linux-source atm?
<kylem> nyet.
<BenC> Keybuk: not that I know of
<Keybuk> accepted
<BenC> Keybuk: thanks
<Burgundavia> hey Keybuk, BenC, kylem
<kylem> hi.
<BenC> Burgundavia: hey
<jdong> Could I get a main sponsor on bug 110881?
<ubotu> Launchpad bug 110881 in ktorrent "[SRU]  Citical bug cherrypicks from SVN" [Undecided,In progress]  https://launchpad.net/bugs/110881
<jetscreamer> how do you get the installer to install / to a pre-existing filesystem and not 'format' the partition
<jander99> Good evening from Atlanta, Ga.
<Burgundavia> hey jander99
<jander99> I'm looking forward to testing Gutsy, just updated from Feisty and already found a few things that need some polish :)
<Burgundavia> file bugs
<Burgundavia> or are you able to help with the coding?
<jander99> Well I'll be starting with the bug filing, but its possible I could do some code review to get started.  I've been reading about ways to contribute to ubuntu, kde, and linux as a whole so hopefully I can bring myself up to speed and dive right in soon ;-)
#ubuntu-devel 2007-06-03
<jander99> I've only really done programming in the academic setting, with Java no less. So I still have alot to learn so to speak
<Burgundavia> right
<Burgundavia> are you a kubuntu or ubuntu user?
<Riddell> one of us one of us
<Burgundavia> Riddell: stop drooling :)
<jander99> kubuntu. something about gnome just doesn't set right with me, plus I've been a windows user for years.
<Burgundavia> then I recommend #kubuntu-devel if you want to help with the DE
<Riddell> it's were all the cool kids hang out
<Riddell> where
<Burgundavia> you mean the kool kids?
<Riddell> no, I refuse to have anything to do with gratuitous K's
<jander99> haha. k00l kidz
<Burgundavia> sadly you use KDED
<Burgundavia> it is inevitable
<jander99> hey it wasnt my intention to start a gnome vs kde debate. I have those on a regular basis in real life lol
<Riddell> I'll win eventually, every day the non gratuitous K's side grows
<Riddell> nobody mentioned gnome, we're just slagging off stupid K's
<Kmos> Riddell: can you take care of bug 104848
<ubotu> Launchpad bug 104848 in hwdb-client "Bad english translation on hwdb-client" [Undecided,Confirmed]  https://launchpad.net/bugs/104848
<marek> somone with coreutils-6.9 running, please?
<crimsun> 6.9? um, it's not even in Debian.
<marek> crimsun: well, 6.9 is quite old.
<marek> ok :( thanks anyway.
<marek> have a nice day ubuntu! :)
<parmindergupta> hi everyone,
<parmindergupta> can someone point me to some documentation regarding ubuntu boot process and the way kernel is compiled, loads modules etc
<Burgundavia> the boot process uses upstart
<Burgundavia> for the kernel, do you want to new way for gutsy or the way for 7.04 and earlier?] 
<poningru_> Burgundavia: whats the new way?
<poningru_> for gutsy
<parmindergupta> i have 7.04 on my system and want to try and customize that. but sure i would like to know about the new way too
<Burgundavia> just a sec
<Burgundavia> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-April/000286.html
<parmindergupta> Burgundavia: thanx :)
<parmindergupta> Burgundavia: is there a way i can upgrade to this new system on my fiesta system, or is there some document that i can check out for fiesta
<parmindergupta> sorry i got disconnected 
<parmindergupta> join #ubuntu
<stuNNed> mmmmk so no SELinux in Ubuntu?  let me chop off both my balls and call it pride.
<stuNNed> if in usa then nsa, oh well
<stuNNed> brb, the FBI is knocking on my door
<stuNNed> oh, got to go, i'll idle a bit, they have questions that need a answerin`
* Hobbsee waves
<LaserJock> morning Hobbsee 
<Hobbsee> hiya LaserJock :)
<geser> Hi Hobbsee
<Hobbsee> hi geser 
<stuNNed> FBI says Ubuntu can...i cannot repeat it...it's pretty fowl....
<crimsun> uh, what are you blabbering about?
<BenC> I know that Ubuntu has selinux, you just have to install the right packages
<Burgundavia> stuNNed: there is SELinux in Ubuntu, just not installed by default
<LaserJock> there's also apparmor, right? wasn't there some plan to have that default in Ubuntu?
<Burgundavia> no idea
<Burgundavia> apparmour rubs me wrong, with all the marketing Novell does
<stuNNed> Burgundavia: how to enable it
<Hobbsee> that's a #ubuntu type question
<stuNNed> Burgundavia: brb need to give a neighbor and ride and reboot
<Burgundavia> indeed
<Burgundavia> I love attitude
<Burgundavia> it gets people so far in the world
<Fujitsu> That was nice.
<mneptok> sadly, attitude and intelligence often seem to have an inverse relationship.
<StevenK> I can think of a few people who have both, which is even sadder.
<Hobbsee> JUST SHOOT THE STUPID PEOPLE!
<Hobbsee> ahem.
<StevenK> *cough* Theo *cough*
<Burgundavia> be nice Hobbsee
<Burgundavia> if you start shooting the stupid people, you might end before the CC, which increases my stress lelve
<mneptok> StevenK: i'd agree with you if you had a point. or maybe if i was a moron. when you start your own BSD fork let us know so we can take shelter while laughing. p.s. your license choice sucks.
<Burgundavia> so please, think of me
<Hobbsee> Burgundavia: i've been to work today.
<mneptok> oh ... excuse me ...
<Burgundavia> I just quit my job
<crimsun> now now, I'm pretty stupid, and I don't like being shot.
<Hobbsee> Burgundavia: i've dealt with enough stupid to last me the week.
<LaserJock> Burgundavia: maybe you should give Hobbsee some of your pills to mellow her out a bit
<Hobbsee> heh
<Hobbsee> Burgundavia: that depends as to whether shooting people is against the CC.
<Hobbsee> no you're not, crimsun 
<Hobbsee> just give me the crack.....
<LaserJock> Burgundavia: really? you finally made it?
<Hobbsee> mmm...crack...
<Burgundavia> LaserJock: I finally quit
<Burgundavia> http://www.google.ca/search?ie=UTF-8&oe=UTF-8&q=code+of+doncut <-- funny typo
<LaserJock> Burgundavia: got other worked lined up?
<Burgundavia> nope, not yet
<Burgundavia> Hobbsee: you know, I don't think the CoC covers shooting people
<LaserJock> well, congrats and hope you find something :-)
<Hobbsee> Burgundavia: it depends.  we were discussing this at UDS.
<poningru> Burgundavia: WHAT?
<Burgundavia> just think, I won't pester you about desktop-multiplier any more
<poningru> you what?
<LaserJock> well, as long as you are being respectful while you were doing it
<poningru> WAAAH?
<ajmitch> Burgundavia: finally
<poningru> Burgundavia: what happened?
<Hobbsee> in some cases, shooting certain people is actually being respectful to the other people in the community, hence it's a CoC violation *not* to shoot them.
<LaserJock> Burgundavia: hehe
<poningru> the fedora crap got to you?
<LaserJock> Hobbsee: hmm, that's a bit of a stretch ;-)
<mneptok> Hobbsee: i sense my impending death
<poningru> Hobbsee: I like the way you think, I would like to subscribe to your magazine
<Hobbsee> LaserJock: depending on who it is.
<Hobbsee> mneptok: nah...just arnieboy's
<Burgundavia> poningru: no, the management crap got to me
<Hobbsee> poningru: i think in many interesting, lateral ways :)
<Hobbsee> i wouldnt be doing this if i didnt
<mneptok> Hobbsee: OMG YOU *KNOW* HIM!? get me an autograph!
<Hobbsee> would have given up tech long ago
<Hobbsee> mneptok: he's queried me before, but not beyond that.
<poningru> rofl
<poningru> so wait a sec
<mneptok> Hobbsee: "I can automate a lot of our sex." *wink*
<poningru> arnieboy != governator of California?
<poningru> ...
<Hobbsee> mneptok: no, no, i'm not going to have sex with you, sorry.
<LaserJock> hmm, "Hobbsee Magazine: Tales of DOOM". sounds interesting
<mneptok> i mean, what *is* his come-on line?
<mneptok> "I have extra repositories."
* poningru points mneptok to the giant thread on one of the lists started by edubuntu
<Burgundavia> mneptok: I don;t want to know about your suppositories
<poningru> err elkbuntu 
<elkbuntu> o.O
<Hobbsee> now where's that mace...
<LaserJock> mneptok: "Everything Ubuntu can't offer" ?
<poningru> elkbuntu: bug: fix your nick, can be confused with a distro
<poningru> ;p
<elkbuntu> poningru, :
<mneptok> poningru: trust me, elky wasn't talking about me in that thread
<Hobbsee> not for most of it, an;yway
<poningru> pwnt
* mneptok is as threatening as an attack hamster
<Hobbsee> mneptok: when will you kill some people?
<mneptok> Hobbsee: that assumes i haven't
<poningru> mneptok: see reddit post about man almost dieing from his hamster's attack
<Hobbsee> mneptok: okay, when will you go on another killing spree?
<poningru> anyway back to fonera hacking
<LaserJock> hmm, so that's how you deal with support requests
<poningru> almost have it PoE only
<mneptok> Hobbsee: "not soon enough."
<LaserJock> 1. People complain
<LaserJock> 2. Eliminate complaintants
<LaserJock> 3. Profit
<mneptok> brb. need more quicklime in the crawlspace. a bit humid today ...
<Hobbsee> mneptok: damn.
<mneptok> the entire backyard smells of tandoori. it's 1am.
<poningru> awesome
<poningru> oh wait
<spasticteapot> Does anyone know if I can go "sudo aptitude remove gnome-desktop" and remove all traces of GNOME from my system?
<Hobbsee> spasticteapot: #ubuntu for support
<Hobbsee> but no
<LaserJock> spasticteapot: I don't think so
<spasticteapot> Fnord.
<Hobbsee> spasticteapot: you'd have to remove libgtk2.0-0
<spasticteapot> And a whole long list of other things.
<Hobbsee> no, no, just libgtk2.0-0
<spasticteapot> Is XFCE4 in the repository? Latest version?
<spasticteapot> I'd like XFCE, not Xubuntu-modified XFCE.
<LaserJock> spasticteapot: you can look at packages.ubuntu.com
<spasticteapot> http://www.psychocats.net/ubuntu/purexfce
<Hobbsee> spasticteapot: #ubuntu for support
<crimsun> or in this case, #xubuntu.
<Hobbsee> yes, that
* poningru hugs crimsun 
<poningru> thanks for helping out my friend
<poningru> sorry he was being an arse
<stuNNed> how do you spell Kylie Minogue?
<Hobbsee> ...
<Hobbsee> !offtopic
<ubotu> #ubuntu is the Ubuntu support channel, #ubuntu+1 supports the development version of Ubuntu and #ubuntu-offtopic is for random chatter. Welcome!
<stuNNed> jk...
<stuNNed> sry
<stuNNed> obot
* mode/#ubuntu-devel [+o mneptok]  by ChanServ
* mode/#ubuntu-devel [+b *!*n=lance@unaffiliated/stunned]  by mneptok
* stuNNed was kicked off #ubuntu-devel by mneptok (same here)
* Hobbsee cheers
* mode/#ubuntu-devel [-o mneptok]  by mneptok
<mneptok> he started trolling #ubuntu
<Fujitsu> Heh.
<mneptok> irssi's /kb has a problem with channels as big as #ubuntu
<mneptok> 03:16 -!- Irssi: Channel not fully synchronized yet, try again after a while
<mneptok> greeeeeat
<Hobbsee> oh lovely
<Hobbsee> i hadnt been watching there...
<Burgundavia> what did he do is #ubuntu
<Burgundavia> ?
<mneptok> well, i don't attend church regularly, so for penance ...
<mneptok> 03:15 < stuNNed> i am bipolinear and in need of desperate scientifics to curb my spending for the minority groups in america
<mneptok> wow. it *really* annoys Corey.
<Hobbsee> mneptok: deal with teh moron in #kubuntu please
* mneptok has no ops there
<mneptok> well, AFAIK
<Hobbsee> awww
<Hobbsee> we'll see if eh behaves now
<Hobbsee> mneptok: can fix :0
<mneptok> uh oh
<YokoZar> How do I tell configure to look into /usr/src/linux-headers-`uname -r`/include  for my package?
<YokoZar> It's not finding a couple of the header files (in this case, linux/ipx.h and linux/compiler.h)
<cjwatson_> is your package a kernel module?
<YokoZar> No.  It's Wine.  But it's looking for linux/ipx.h
<Hobbsee> evening cjwatson 
<cjwatson> then it should be using /usr/include/linux/ipx.h instead
<cjwatson> which is in gutsy's linux-libc-dev, though maybe not in earlier versions
<YokoZar> Is that not in feisty?
<cjwatson> if a kernel header you need isn't in linux-libc-dev, best practice is (a) file a bug (b) copy the header file into your package
<cjwatson> haven't checked feisty, sorry, though linux-libc-dev certainly is in feisty's build-essential
<YokoZar> Yeah
<YokoZar> Ok so you're right about them being there in gutsy, which is good
<YokoZar> Although usr/include/linux/compiler.h isn't there in gutsy
<YokoZar> http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=compiler.h&searchmode=searchfiles&case=insensitive&version=gutsy&arch=i386
<cjwatson> at the risk of finding out the answer, why do you need linux/compiler.h from userspace?
<YokoZar> I really don't know.  Wine's configure is looking for it
<cjwatson> sometimes the answer is to patch that out :)
<YokoZar> I'll ask on the Wine mailing list
<YokoZar> Still, what bothers me is that configure isn't finding linux/ipx.h on feisty
<YokoZar> But it should obviously be there
<YokoZar> checking for netipx/ipx.h... yes
<YokoZar> checking for linux/ipx.h... no
* Hobbsee "dear head, please stop spinning, kthxbye"
<YokoZar> Ok so the partial answer about compiler.h is that it's being included by the file dlls/winedos/int13.c
<cjwatson> hmm, why does usplash apparently reset the console font?
<cjwatson> interesting, X saves and restores the console font - probably means the kernel is blatting the console font in graphics mode and usplash has to save and restore it too
* cjwatson is gradually unpicking console-setup bugs
<Zic> Mithrandir: ping ?
<Zic> I need an archive admin of Ubuntu for help with my "special" package of MenAreAnts (http://revu.tauware.de/details.py?upid=5281) : It use a font which is already in archive.ubuntu.com, so I created a .link in debian/ directory. But with the font of archive.u.com (FreeMonoBold), the game (MenAreAnts) don't start and crash immediately.
<Zic> anyway, MenAreAnts use FreeMonoBold which are in its sources
<Zic> and with it, it works
<Zic> (2 fonts have differently md5sums)
* Keybuk pokes Amaranth in a "compiz is SEGVing" kinda way
<Zic> so, I need an archive admin to tell me if MAA will be rejected or not
<Zic> MAA == MenAreAnts
* Fujitsu pokes Keybuk in a "haha, serves you right. metacity is better" kinda way
<Mithrandir> Zic: *shrug*; I don't think we'll reject it for that, but it sounds like a bug which should just be fixed.
<sladen> there was a train going from Gotenburg-Oslo.  tempting.  Though I booked to Stockholm in the end
<Zic> Mithrandir: however, upstream don't want to fix it ...
<Zic> Mithrandir: thanks for your help, I will try ...
<StevenK> Mithrandir: I know you don't like working weekends, but would you mind checking something for me?
<Mithrandir> StevenK: I don't mind if it's just a minor thing, I just don't want to end up spending an hour.
<StevenK> Mithrandir: Ah, right. I don't think so. I'm looking at gutsy_probs.html, and gnunet is listed as having some uninstallable binaries. My problem is that gnunet is in universe, LP says it is so, and it has never been promoted, and britney only runs over main. So, I'm confused.
<cjwatson> when LP says something is in universe, it means the source.
<Mithrandir> I'll take a look
<StevenK> If the source is in universe, the binaries can't be in main.
<cjwatson> in theory
<StevenK> Oh.
<cjwatson> use 'rmadison -u ubuntu -s gutsy -S gnunet'
<Mithrandir> gnunet-tools |   0.7.1c-2 |         gutsy | i386
<StevenK> gnunet-client |   0.7.1c-2 |         gutsy | i386
<cjwatson> the binaries may not be in main by policy, but that doesn't mean that it is impossible for them to be.
<StevenK> gnunet-client |   0.7.1c-2 | gutsy/universe | amd64, powerpc
* StevenK high fives Mithrandir
<cjwatson> I'll demote those noww
<cjwatson> now
<Mithrandir> cjwatson: I just did
<StevenK> cjwatson: Way cool, thanks for sorting it and me out.
<StevenK> Mithrandir: ^
<cjwatson> ok
<Mithrandir> np, happy to help
<cjwatson> somebody evidently screwed up while processing NEW
<StevenK> Ahh...
<Mithrandir> there's a fair chunk of stuff on the binary-to-demote list
<Mithrandir> and some crap on the to-promote list which shouldn't be there.  Like, apache.
<StevenK> Interesting ...
<Mithrandir> looks like a busted merge, but apache1 is going away in Debian too.
* StevenK raises an eyebrow.
<StevenK> A nastygram to kick it out has been filed?
<Fujitsu> A message was sent to debian-devel a month ago about it being removed soon.
<Mithrandir> I think so.
* StevenK looks through the archives of debian-devel
<Fujitsu> 2007/05/01
<StevenK> 30th April, actuallty
<StevenK> actually
<Fujitsu> I guess if you're talking UTC, yes.
<StevenK> I was, since I was using the web archive.
<Fujitsu> So I now realise.
<Hobbsee> hey all
<aspro> howdy
<pygi> hey Halcy0n 
<pygi> Hobbsee, 
<Hobbsee> :)
<mpt> Hobbsee, congratulations!
<Hobbsee> mpt: thankyou :)
<Amaranth> Keybuk: you pick bad times to ping me
<Hobbsee> Amaranth: dont give him your mobile number then.
<Amaranth> heh, i don't have a mobile :)
<Hobbsee> easily fixed then
<Amaranth> oh, my website says i do still :)
<Hobbsee> may i make a public service annoucement that the australian customs people get quite pissed when your phone rings, as they're talking to you?
<bhale> Hobbsee: QUARANTINE!
<Hobbsee> bhale: i thought that sectoin said customs
<Hobbsee> mind you...i dunno what was going on then - my brain wasnt working
<bhale> Hobbsee: (i accidentally snuck a ton of tea and biscotti past them)
<bhale> i thought i had dumped it all
<Hobbsee> bhale: *snort* - australian security, coming in, or going out?
<bhale> Hobbsee: coming in
<Hobbsee> yeah, well, coming in...
<Hobbsee> going out's more strict than coming in
<bhale> i didnt really pick anything up going out
<Hobbsee> coming in they didnt check my backpack at all, as they felt that there was a laptop in there by the weight of it
<bhale> but they act like coming in is a big deal
<bhale> with food products
<bhale> anything organic
<Hobbsee> so they just said "oh, we'll scan your other bag, and we dont need to see that one"
<Hobbsee> heh, yeah
<Keybuk> Amaranth: you pick bad times to break our future default window manager <g>
<Amaranth> works great here :)
<Amaranth> best package yet ;)
<Keybuk> ***MEMORY-WARNING***: [5110] : GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon...
<Keybuk> Segmentation fault (core dumped)
<StevenK> Keybuk: Inkscape?
<Keybuk> StevenK: compiz
<ion_> Pretty much every glib program seems to be saying that.
<StevenK> Ah. I saw the same error in inkscape and tried to fix it.
<Amaranth> hehe, _every_ single application spits out that warning
<Keybuk> Amaranth: they don't core dump though
<ion_> Yeah, they seem to be fairly stable.
<Amaranth> reset all settings to defaults and see if it still happens
<Keybuk> #0  0xb761e8ae in expoOptionsInitDisplay (p=0x8171ce8, d=0x8076840)
<Keybuk>     at build/expo_options.c:317
<Keybuk> 317         d->privates[displayPrivateIndex] .ptr = od;
<Amaranth> or just give me a backtrace :)
<Keybuk> #1  0x0806c515 in pushPlugin ()
<Keybuk> #2  0x08054bd4 in eventLoop ()
<Keybuk> #3  0x080515a2 in main ()
<Amaranth> oh, bleh
<Amaranth> CLOSED, INVALID
<Amaranth> ;)
<Amaranth> you're using expo
<Keybuk> ?
<Keybuk> yes?
<Amaranth> not packaged :)
<Keybuk> it's in the spec as a default plugin <g>
<Amaranth> and when i package it i'll make sure it works :)
<Keybuk> why isn't it packaged yet?
<Amaranth> well, right now it's because our core package is out of sync with their stuff
<Amaranth> and the core changes are no where near done/stable
<Keybuk> how do we get it in sync?
<Keybuk> I understood that our compiz packages includes their core changes?
<Amaranth> wait to see if something breaks and then update the compiz package
<Amaranth> it does, this is something that changed 4 days ago
<Amaranth> so all their plugins where updated for it
<Amaranth> and it's a good change so i want it but i want to make sure it doesn't break lots of things first
<Keybuk> how do you mean?
<Amaranth> also, rebuild expo and it'll probably work
<Amaranth> unless you've updated to latest compcomm git
<Keybuk> just tried that, and expo doesn't build
<ion_> What does the expo plugin do?
<Amaranth> you've updated to latest compcomm git then :)
<Keybuk> yes ?
<Amaranth> ion_: it does the zoom out of your viewports
<Amaranth> so you can see them all at once, move windows between them, etc
<ion_> Alright, nice.
<Amaranth> Keybuk: as i said, our package and their code are out of sync
<Keybuk> I thought you said they were in sync since 4 days ago?
<Amaranth> but this stuff is brand new, i don't even think everything is converted to use it
<Keybuk> what is the stuff?
<Amaranth> no, i said they went widely out of sync 4 days ago
<Amaranth> multiscreen fixes
<Keybuk> since we are aiming for compiz + compcomm, wouldn't it make sense to keep us in sync?
<Amaranth> sure but not bleeding edge
<Amaranth> i planned to update everything to latest git and present you 54 binary packages (from like 4 source packages) on thursday or so
<Amaranth> i believe thursday is my day off
<StevenK> launchpadlibrarian.net? Wah, where did librarian.launchpad.net go?
<__keybuk> oops
<__keybuk> don't run gdb on your active window manager if it's not in the active window
<__keybuk> Amaranth: what did I miss?
<StevenK> Keybuk: compiz reacted badly?
<Amaranth> <Amaranth> i planned to update everything to latest git and present you 54 binary packages (from like 4 source packages) on thursday or so
<Amaranth> <Amaranth> i believe thursday is my day off
<Amaranth> StevenK: gdb stops it
<Keybuk> ok
<Amaranth> so nothing updates
<StevenK> Ahh
<StevenK> So you log in on a console and kill -CONT it?
<StevenK> Or ssh in?
<Amaranth> ssh yes
<Keybuk> Amaranth: my concern is simply that the longer we don't have our desired final result packaged, the less testing we'll get of it
<Amaranth> but you can't do a VT switch either
<Keybuk> StevenK: meh, more effort than c-a-bkspace and login again
<StevenK> Keybuk: Heh
<Amaranth> Keybuk: right but i'm more concerned with each step of the way there being usable
<Keybuk> Amaranth: still got white borders instead of shadows
<Amaranth> eh?
<Keybuk> Amaranth: today's step broke for me <g>
<Amaranth> /apps/compiz/plugins/decoration/allscreens/options/shadow_radius
<Amaranth> that should be 9
<Amaranth> or at least != 8
<Keybuk> oh, I had a bug about that
<Keybuk> it changed from a float to an int
<Keybuk> so I did "Unset Key" and it went to 8
<Keybuk> 9 does indeed fix it.  you may want to fix Unset Key then :p
<Amaranth> heh
<Amaranth> compiz-gnome.gconf-defaults doesn't make it the default in the schema?
* Amaranth thought that's what it did :)
<Keybuk> Amaranth: I noticed something in the changelog about window snapping - which doesn't seem to work for me
<Amaranth> about window snapping?
<Amaranth> oh, right, it should be on by default in wobbly
<Keybuk> oh, it's a wobbly feature?
<Amaranth> yeah
<Amaranth> has been for ever
<Keybuk> can I have wobbly without the wobble?
<Amaranth> there is also a snap plugin in compcomm
<Amaranth> no
<Keybuk> is that snap like metacity does it (hold Shift) or just Snap-by-default?
<Amaranth> metacity is by default
<Keybuk> it is?  I always had to hold Shift while moving windows
<Amaranth> but metacity actually does edge resistance, beryl's snap plugin doesn't quite match up
<Amaranth> luckily metacity is somewhat sane here and has all the logic for that in one file on it's own :)
<Keybuk> can we pluginify that logic?
<Amaranth> which reminds me, that code is fun
<Amaranth> they do a binary search for closest match with a boolean argument for whether you want over or under
<Amaranth> which iirc is to find window edges
<Amaranth> but yeah, i had planned to make that logic into a plugin
<Amaranth> but -ENOTIME
<Keybuk> sweet
<Amaranth> so dunno if we'll get it
<Amaranth> snap is close enough though
<Amaranth> really just needs to ignore window edges that are hidden and not hold windows together after you've snapped them
<BenC> Keybuk: mind processing the other 4 architectures for linux-source-2.6.22? :)
<Keybuk> BenC: nothing in NEW
<minghua> is there any buildd admin that I can ask to give-back uim now?
<Mithrandir> Keybuk: it's in rejected
<persia> Mithrandir: Please give-back cyrus21-imapd on all architectures.
<Mithrandir> persia: uh, no?  It needs to move to libsnmp-dev
<cjwatson> BenC: accepted
<BenC> cjwatson: thanks
<persia> Mithrandir: My misunderstanding of the build failure then.  Thanks.
<minghua> Mithrandir: can uim be given-back on all arches?  it seems to be build failure due to kde not ready
<Hobbsee> Mithrandir: just give back the entire archive, will you? :P
* Hobbsee runs away before Mithrandir can hunt her out and kill her.
<Mithrandir> Hobbsee: we do actually do mass-givebacks once in a while
<Hobbsee> Mithrandir: yeah, but entire archive ones?
* Hobbsee thought that was like...50 packages or something at a time
<Mithrandir> just all thefailed once.
<Mithrandir> all the failed ones, even
<Mithrandir> minghua: given-back
<Hobbsee> ah, true that
<Hobbsee> blerg.  someone find me a new wrist please.
<minghua> Mithrandir: thanks.  so Ubuntu doesn't have binNMU, I should upload a -Xbuild1 to pick up the new SONAME of libuim, right?
<Mithrandir> minghua: yes, you need to do that
<ccm> is there an easy way to find out who uploaded a package to universe?
<Hobbsee> ccm: lists.ubuntu.com/gutsy-changes or aptitude changelog foo
<ccm> I think this is to few information: Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
<Hobbsee> or look in launchpad
<Hobbsee> maintainer != uplaoder
<ccm> okay
<ccm> Hobbsee: well I dont know what is the best way to continue with bug #112521
<ubotu> Launchpad bug 112521 in hardinfo "[apport]  hardinfo crashed with SIGSEGV in strcmp()" [Undecided,Confirmed]  https://launchpad.net/bugs/112521
<ccm> Hobbsee: this application has several duplicate crash reports (reproducable) and I am looking for someone to assign to
<Hobbsee> ccm: looking at that version number, and the maintainer for gutsy, you should report that one to debian
<ccm> i see
<Hobbsee> seeing as ubuntu doesnt change that package at all
<ccm> what do you mean be "seeing as ubuntu"?
<Hobbsee> s/seeing as/because/
<Hobbsee> hi pkl_ 
<ccm> i see,
<ccm> Hobbsee: let me continue about this, just to understand: the error occurs in a version that is already updated but of course won't get updated in feisty. So if nobody is willing to backport the patch for this very error it won't get fixed until gutsy right?
<Hobbsee> something like that
<Hobbsee> you can request a backport of the entire package, too, but it will go to feisty-backports, nto feisty-updates
<Hobbsee> but you're right, yes.
<ccm> can you point me to a backport request page?
<Hobbsee> !backport
<ubotu> If new updated Ubuntu packages are built for an application, then they go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<ccm> tahnk you
<Hobbsee> no problem
<Hobbsee> uh oh, i'ts sabdfl_.  everyone behave!
<sabdfl_> is there a standard command to add a source of debs to /etc/apt/sources.list?
<sabdfl_> hey Hobbsee
<Hobbsee> hiya
<sabdfl_> am writing a script which greps to see if one it needs is there
<sabdfl_> and if not, it needs to add it
<sabdfl_> initial attempt was just:
<sabdfl_> sudo echo "\ndeb http://lpdebs.canonical.com/${DISTRIB_CODENAME} ./" >> /etc/apt/sources.list
<sabdfl_> but that don't work
<bhale> sabdfl_: that is because the sudo is running the command as root, but the shell is still you
<bhale> sabdfl_: so a shell redirect (>>) doesnt have permission
<bhale> sabdfl_: sudo -s and try again.
<sabdfl_> ah, any way to work around that?
<Hobbsee> there's another command.  i used to know what it was, too.
<bhale> tee?
<cjwatson> echo "blah" | sudo tee -a /etc/apt/sources.list >/dev/null
<Hobbsee> that's the one.
<sabdfl_> thanks colin :-)
<Hobbsee> didnt realise my brain was that shot.
<cjwatson> there is no standard command to add a source afaik
<Hobbsee> no...using tee is the only one i've ever seen given out in #ubuntu though...so that's the most common
<MmikeMRMA> Where do I get info/help with gutsy? 
<superm1> MmikeMRMA, #ubuntu+1
<MmikeMRMA> superm1, 10x
<thedeviantone_> Hello everyone, I'm looking to install Ubuntu 6.06 on a generic mobo with amd 650. but the issue I'm having is with the PERC2/SC SCSI controller.. someone mentioned that I need to rebuild the kernel
<thedeviantone_>  can anyone help?
<mrsn0> thedeviantone_ this channel isn't for support really, try in #ubuntu but be sure to check wiki.ubuntu.com > search > kernel and you should find information on rebuilding the kernel
<spasticteapot> Anyone here?
<spasticteapot> I recently tried Ubuntu again - I've pretty much exclusively been using Xubunu for reasons of "GNOME is bloaty."
<spasticteapot> Makes my Thinkpad run very, very slowly.
<spasticteapot> I must say, however, that you (the developers) have done a bang-up job of making an easy-to-use operating system.
<spasticteapot> Honestly, it might even be MORE intuitive than either windows or mac.
<spasticteapot> What I'd like to know, however, is why Ubuntu by nature requires a speedy machine. I would like to install Ubuntu on a few machines and give them to some local nonprofits that could use them, but Xubuntu is, well, headache-inducing.
<mjr> sounds like you want LTSP :] 
<spasticteapot> LTSP?
<mjr> linux terminal server project; thin clients, you know
<spasticteapot> LTS = Long Term Support. LTSP = ?
<spasticteapot> I don't want thin clients. I just want something that will let Toys for Tots do spreadsheets.
<spasticteapot> Like DeLi Linux.
<etank> spasticteapot: we (Kentucky LoCo) are looking at doing the same type of thing.
<spasticteapot> If Linux can be made to run on ultra-cheap computers like the EFIKA single-board computer - which is dirt cheap - then $100 desktops are a reality today.
<etank> spasticteapot: and our plan is to use Xubuntu
<spasticteapot> etank: Xubuntu is....incomplete.
<spasticteapot> It crashes quite a bit. 
<spasticteapot> Things freeze. 
<etank> i dont run Xubuntu so i dont know about the freezes.
<spasticteapot> It needs work. A LOT of work.
<spasticteapot> The application launcher is kinda sketchy, too - a lot of programs and packages don't show up in it.
<spasticteapot> XFCE was designed to be used somewhat differently than GNOME. The people in #XFCE can explain it better than I can, but the whole windows-style "start menu" thing is NOT the way the XFCE dev team is going.
<spasticteapot> Also, it needs a minimum of 256mb of RAM. Anything less is a pain in the butt.
<spasticteapot> http://kmandla.wordpress.com/2007/04/22/howto-set-up-feisty-for-speed/
<spasticteapot> Something like the above - it's got an agglomeration of a few different window-manager bits, and runs on a PII/333 with 192mb of RAM.
<spasticteapot> Or you could just go with fluxbox, and tweak it so that it's easier to use (similar to all of Ubuntu's additions to Gnome.)
<spasticteapot> Or IceWM. IceWM would work very well indeed.
<wasabi> spasticteapot: Gnome isn't really *that* bloated. I run it on 500mhz machines with 128mb ram no problem. If you want to go lower, well, start hacking. ;)
<spasticteapot> wasabi: HOW?
<wasabi> How what
<spasticteapot> A base Ubuntu install on my "test machine" (1.2ghz/512mb) lags nastily.
<wasabi> Define lag.
<spasticteapot> Click on Synaptic...wait ten seconds...enter password...wait ten seconds....
<wasabi> Don't use synaptic?
<wasabi> Also, most of that is probably dpkg.
<wasabi> Not anything "gnome"-related
<spasticteapot> ?
<spasticteapot> My laptop has a slower processor, and yet, under XFCE, magically works much faster.
<wasabi> synaptic works faster?
<adam0509> XFCE roxx tbh, thunar rox, and xfce4-panel is very good ! (but not perfect thus...)
<adam0509> I wonder why I am still on GNOME... maybe because I make HOW-TOs for french wiki...
<adam0509> well, since am I here, how do you make big menu in XFCE ? It's too small by defaut :/
<wasabi> The same synaptic runs whether you log in using Xfce or Gnome.
<wasabi> Gnome is nothing magical. It's just a set of programs: the panel, nautilus, the session manager.
<RadiantFire> spasticteapot: the dpkg database is massive, it will take a while to scan
* cypherbios hates to say that, but thinks it's off topic for -devel
<wasabi> I do think it would be nice if the dpkg database could have some sort of speed up cache thing as an option.
<wasabi> (pre scanned, dumped, representation of what the scanning produces, obsolted by mod dates)
#ubuntu-devel 2008-05-26
<emgent> heya cody-somerville :)
<cody-somerville> emgent, hey
<pochu> good night
<dbmoodb> hi ah just a question regarding the man pages .... why are they less detailed than on debian ?
<dbmoodb> like under man shutdown the fsck on reboot information is not there...
<persia_> dbmoodb: That'd be accidental.  Probably worth a bug, if it isn't made clear by the changelogs.
<dbmoodb> sure but .... it is very irritating
<dbmoodb> according to ubuntu fsck on reboot is a bug
<dbmoodb> it is an undocumented feature
<dbmoodb> persia where do i find the changelog for this man file in particular ?
<persia_> dbmoodb: `dpkg -S $(file)` will tell you which package.  Changelogs are by package.
<dbmoodb> ok so the file ?
<persia_> dbmoodb: Probably somewhere in /usr/share/man/...
<dbmoodb> there ia lot ...
<persia_> dbmoodb: Which manpage has the issue?  shutdown(1)?
<dbmoodb> yeah
<StevenK> dbmoodb: man -w shutdown
<dbmoodb> ok got it
<persia_> So, /usr/share/man/1/shutdown.1.gz (if I remember correctly).  I forget the exact mapping, but it ought be easy to find.
<dbmoodb> and now ï»¿`dpkg -S $(file)` on that ?
<StevenK> /usr/share/man/man8/shutdown.8.gz
<dbmoodb> /usr/share/man/man8/shutdown.8.gz
<persia_> dbmoodb: Right.
<persia_> StevenK: Thanks
<dbmoodb> taking some time
<dbmoodb> ok so it is upstart-compat-sysv:
<StevenK> dbmoodb: dpkg -S reads through the entire file list for the installed system
<dbmoodb> still isn't there...
<dbmoodb> although it just accept what i put in
<StevenK> Sorry?
<dbmoodb>  shutdown -k -F 10:00Broadcast message from X@X
<dbmoodb> 	(/dev/pts/0) at 14:53 ...
<dholbach> good morning
<geser> dholbach: good morning
<dholbach> hey geser
<dholbach> geser: when will you apply for core-dev? :-)
 * dholbach grudgingly takes care of bug 230016
<ubottu> Launchpad bug 230016 in ossp-uuid "[intrepid] Rebuild with perl 5.10" [Undecided,Fix released] https://launchpad.net/bugs/230016
 * dholbach hugs geser
<dholbach> hi warp10
<warp10> hey dholbach!
<pitti> Good morning
<pitti> siretart: cryptsetup> oh, thanks
<dholbach> hiya pitti
<pitti> Riddell: ok; I just don't understand how the MIRs can be a blocker at this time of intrepid?
 * pitti hugs dholbach
<geser> Hi pitti
<dholbach> pitti: is there anything left to do on bug 202460?
<ubottu> Launchpad bug 202460 in lshw "Hardware Testing app hangs" [High,Fix released] https://launchpad.net/bugs/202460
<pitti> dholbach: it needs to be fixed in intrepid, too
<dholbach> OK
 * pitti checks intrepid version
<pitti> dholbach: ok, I can copy-package it over, it's the same as in hardy
<dholbach> ROCK
<dholbach> gracias
<pwnguin> aww
<pwnguin> asac just left =(
<pwnguin> https://bugzilla.mozilla.org/show_bug.cgi?id=435712
<ubottu> Mozilla bug 435712 in Places "Implement automatic places backup" [Enhancement,Unconfirmed]
<pwnguin> a patch to fix fsync on ff3
<dholbach> pwnguin: it's 8:07 in Germany - not sure asac is up yet
<pwnguin> ...
<pwnguin> well, his client reset
<dholbach> his client is almost always online :)
<emgent> morning
<dholbach> hiya emgent
<emgent> hey dholbach :)
<emgent> do you know who can active ubuntu.com mail alias? (seems not work auto)
<dholbach> emgent: if you have trouble with that, best ask in #launchpad
<Koon> hey emgent + dholbach
<emgent> cool
<dholbach> hi Koon
<emgent> hi Koon
<Riddell> pitti: because I can't upload kde until the depends get into main (unless I do the load of changes to kde 4 packages we did in hardy, then undo them again when i can go into main, that would take a long time)
<pitti> Riddell: ah, I see
<tseliot> pitti: check your mail when you have the time ;)
<pitti> tseliot: I saw your upload request
<tseliot> ï»¿pitti: great
<siretart> pitti: I hope I didn't break too much
<pitti> siretart: looks fine :)
<pitti> siretart: I was just curious about those two things
 * pitti hugs siretart, thanks
 * siretart hugs pitti  back :)
<siretart> there is still quite some bug triaging work to do on cryptsetup. not as  bad as on usplash, but still
<siretart> do we have an usplash maintainer atm?
<pitti> not really ATM; I fixed a couple of bugs in Hardy, but not extensively
<emgent> morning
<pitti> desrt: did you ever get any feedback for bug 183411? I'd like to move this to gutsy-updates, but only after I get at least one confirmation that the package still works
<ubottu> pitti: Error: Could not parse data returned by Launchpad: The read operation timed out
<pitti> doko: did you get any feedback about sun-java5  1.5.0-15-0ubuntu0.6.06 in dapper-proposed?
<norsetto> rockstar pitti?
<pitti> ?
<pitti> hi norsetto
<emgent> lol
<emgent> hi norsetto
<norsetto> pitti: hey, was good to meet you
<pitti> norsetto: likewise!
<norsetto> pitti: I was told you were one of the rockstars at the party on Friday night ;-)
<pitti> norsetto: I played 'wish you were here', but only one song
<norsetto> pitti: ah ... pink floyd ...
<pitti> norsetto: you really missed a great party, DJ Holy Holbach was awesome, too
 * norsetto sheds a tear
<norsetto> pitti: Daniel is unstoppable when it comnes to rocking
<norsetto> pitti: do you know if I need to ask for a give back for this: http://launchpadlibrarian.net/14708212/buildlog_ubuntu-intrepid-amd64.findlib_1.2.1-4build1_CHROOTWAIT.txt.gz
<norsetto> emgent: are you always here!?
<pitti> norsetto: I can try
<emgent> norsetto: sure
<pitti> norsetto: kicked
<norsetto> pitti: thx, I need that to be built before I can upload a bunch of other packages
<doko> pitti: sorry, no feedback, I'd suggest accepting it, I didn't see any problems, and the package in debian is ok as well.
<pitti> doko: did you test the actual .debs yourself?
<pitti> doko: the ones from -proposed, not the locally built ones, I mean
<doko> pitti: not much more than starting the runtime
<doko> emgent: no idea why you message me; please ask on #ubuntu-motu for general stuff
<asac> pitti: langpack update. how to go on?
<asac> i am currently QAing a test run
<pitti> asac: translations are sorted out on LP now?
<asac> pitti: yes. i am currently using the 24-5 update tarball
<asac> pitti: the tarballs i have produced are at /tmp/out.trans.rc1a/
<asac> pitti: its bug 233922
<ubottu> asac: Error: Could not parse data returned by Launchpad: The read operation timed out
<asac> pitti: riddel agreed that its ok to move them to language-pack-XX
<asac> Riddell that is ;)
<pitti> asac: I guess that was fixed only recently, i. e. http://ppa.launchpad.net/ubuntu-langpack/ubuntu/pool/main/l/language-pack-gnome-de/ is not recent enough?
<pitti> asac: oh, heck, that one has May 05 only
<asac> pitti: most likely not. i had to tune the blacklist
<asac> so do a rerun if possible and move to language-pack-XX from gnome-XX
<pitti> the former will be done automatically, the latter requires a lot of manual action
<asac> pitti: ? afaict the replaces are in place
<asac> language-pack-de => Replaces: language-pack-de-base, language-pack-de-base (<< 1:6.06+20080303), language-pack-gnome-de-base (<< 1:6.06+20080303), language-pack-kde-de-base (<< 1:6.06+20080303), language-pack-de (<< 1:6.06+20080303)
<pitti> asac: right, but if someone installs the new gnome-base packages after the new default -base ones, he'll get the old version again
<asac> pitti: hmm ... cant we drop them from gnome-XXX ?
<pitti> asac: IOW, I recommend to just reupload all the affected -base ones from scratch, instead of just the update ones
<pitti> asac: yes, we can
<asac> pitti: can we do this reupload through langpack-o-matic?
<pitti> asac: yes
<asac> what do you need?
<pitti> just the list of affected languages
<pitti> asac: ok, if/when your local test is working, give me a ping; I'll kick off a PPA build then
<pitti> which we can use for testing; if it works, we can copy it to hardy-proposed
<asac> pitti: http://paste.ubuntu.com/14753/ <= beta 5 locales
<asac> pitti: http://paste.ubuntu.com/14754/
<cprov> pitti: very nice that you are exploring PPA copying ;)
<asac> pitti: <= RC1 locales (list will be finalized after my testing)
<pitti> cprov: I have done that for months already, but source-only so far
<asac> pitti: ok
<pitti> asac: ah, it's so many, I think I'll just rebuild them all
<pitti> asac: we need to do it in two steps anyway
<cprov> pitti: that's fine, saves your time.
<asac> pitti: i think there are a few languages that have a mozilla.tar.gz in update packages
<pitti> (1) build using the current export delta tarball and test it
<asac> pitti: should be es, zh, pt, en
<pitti> (2) request a new full export, wait until it's done, rebuild all pacsk from scratch, upload to -proposed
<asac> pitti: bug 233922 is the tracker bug. i have uploaded everything except midbrowser and those language packs
<ubottu> asac: Error: Could not parse data returned by Launchpad: The read operation timed out
<asac> pitti: we could punch them in now or all in a batch
<cprov> pitti: although, for lang-packs PPA copying the binaries would be harmless since it only contains lang-packs.
<asac> (e.g. approve to -proposed)
<pitti> cprov: right, I filed a bug about that ages ago, to save a lot of buildd power
<pitti> asac: does the new ffox work with the translations from hardy final?
<pitti> (that was usually the case with ffox2, but asking to be sure)
<asac> pitti: no, but i took measures that it isn't broken in case the user doesn't catch the locales at the same time. but if possible lang packs would go out in sync with xul + ffox
<pitti> asac: for 'out' being -proposed, too or -updates?
<asac> pitti: this one is the last upload where upstream changed strings
<norsetto> hi asac ... got my last email :-)?
<asac> pitti: mostly -updates. but to reduce confusion we might wanna wait till the rc1 translations get into -proposed
<pitti> asac: right, that's what I figured, too
<asac> norsetto: only have the gecko-mediaplayer ones in my inbox :(
<asac> norsetto: did you use a different email address?
<norsetto> asac: ok, I was spammed again, its about the new contributor
<asac> norsetto: what email are you using?
<norsetto> asac: asac@ubuntu.com, should I use a different one?
<asac> if you disable HTML i should get the mail
<asac> norsetto: well you gave me the gmail one only ;)
<norsetto> asac: no HTML, I sent it using kmail
<asac> norsetto: err ... what From: email did you use
<asac> i have whitelisted your gmail thing
<norsetto> asac: from: norsetto@ubuntu.com
<asac> yeah ... thats a different one ... last email you send also had HTML
<norsetto> asac: yes, I never use gmail, that was the first (and hopefully) last time, it wasn't my PC
<asac> let me whitelist that too
<asac> done
<norsetto> asac: should I resend it?
<asac> norsetto: hmm ... yeah maybe. wasnt even in my spam folder
<asac> lets retry
<norsetto> asac: ok, will do. Anyhow, it was good meeting you and the mozilla gang!
<asac> norsetto: the pleasure was on my side!
<asac> norsetto: gecko-* is in my queue :)
<norsetto> asac: take your time, I'm sure you have much better things to do ;-)
<asac> hehe
<norsetto> asac: btw, I had a look at bug 224611
<ubottu> norsetto: Error: Could not parse data returned by Launchpad: The read operation timed out
<norsetto> ubottu: I love you neverthless
<ubottu> norsetto: Error: I am only a bot, please don't think I'm intelligent :)
<norsetto> https://bugs.edge.launchpad.net/ubuntu/+source/firefox/+bug/224611
<ubottu> Launchpad bug 224611 in firefox "firefox-2-dev lists wrong directory in .pc files" [High,Triaged]
<asac> norsetto: if you have a patch go ahead ;)
<norsetto> asac: well, I wanted to talk with you, because the only solution I found would be to hardcode the correct path in the *.pc.in, which looks ugly
<norsetto> asac: so, perhaps symlinks would be better
<asac> norsetto: i think hard-coding is better.
<asac> there are configure scripts that use that path to set rpath for instance
<asac> the firefox-2 thing is a hack anyway, so fixing this in a patch shouldnt be too bad
<norsetto> asac: right, hack for hack I will attach a patch then
<norsetto> doko: what do you think of bug 224847?
<ubottu> norsetto: Error: Could not parse data returned by Launchpad: The read operation timed out
<norsetto> https://bugs.launchpad.net/ubuntu/+source/python-central/+bug/224847
<ubottu> Launchpad bug 224847 in plucker "package update-manager 1:0.87.24 failed to install/upgrade: ErrorMessage: SystemError in cache.commit(): E:Sub-process /usr/bin/dpkg returned an error code (1)" [High,In progress]
<doko> norsetto: just a rebuild should be fine
<norsetto> doko: ah, thx, I'll check it
<emgent> hi gaspa
<pitti> Riddell: libsoprano4_2.0.98-1_i386.deb is quite broken -- it installs a lot of non-SONAME specific files into /usr/share/soprano and /usr/share/dbus-1; IOW, you cannot install multiple libraries with differnet SONAMEs
<pitti> Riddell: also programs in /usr/bin/
<Riddell> pitti: you think they should be in a separate package?
<pitti> Riddell: filed as bug 234952
<ubottu> Launchpad bug 234952 in soprano "libsoprano4 installs non-SONAME specific files" [Undecided,New] https://launchpad.net/bugs/234952
<pitti> Riddell: yes, if we don't want to completely break upgrades
<gaspa> hi emgent.
<asac> pitti: test finished (24 may)
<asac> pitti: let me know when we have a new tarball. i can take a quick look
<pitti> asac: ok, building PPA packages then
<norsetto> pitti: could you perhaps sync bug 234833 and bug 234831? Sorry for asking here, but I would like to finish the ocaml transition for cduce (bug 234581) and I need these two asap
<ubottu> Launchpad bug 234833 in camlp5 "Please sync camlp5 5.08-2  (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/234833
<ubottu> Launchpad bug 234831 in lablgtk2 "Please sync lablgtk2 2.10.1-2  (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/234831
<ubottu> Launchpad bug 234581 in ulex "Cduce Depends On Non-Existant Package `ocaml-nox-3.10.0`" [Undecided,In progress] https://launchpad.net/bugs/234581
<pitti> norsetto: I'll do a complete -a run
<norsetto> pitti: danke!
<pitti> norsetto: (that means, sync everything from Debian which we did not modify)
<norsetto> pitti: yes, I got that ;-)
 * norsetto -> lunch
<siretart> glatzor: around? - You still have my head set! ;)
<glatzor> siretart, I know. you disappeared suddently
<siretart> glatzor: as said, I had to catch a plane
<siretart> glatzor: could you mail it to me perhaps?
<glatzor> siretart, would you like to send me your post address in an email?
<glatzor> siretart, I will send it to you tomorrow
<siretart> see query
<glatzor> fine. thanks for sharing.
<siretart> aah, you are not authenticated, so I don't see your answer in query
<siretart> silly freenode :/.
<glatzor> siretart, you made your way back home well?
<siretart> yes, it was fine
<glatzor> siretart, you really missed something on friday evening!
<siretart> I was a bit tired on saturday and overslept badly, but the trip was fine
<siretart> how was your trip home? when did you arrive?
<glatzor> I extended my stay to sunday since I met with my girlfried there
<siretart> ah, nice :)
<glatzor> siretart, but the center of the city is really evil in the night
<glatzor> siretart, a lot of drunken english men, drugs and professionals
<siretart> oh
<glatzor> siretart, but we had a nice backyard in our pension :)
<siretart> we were on thursday evening in the city, and it was lovely :)
<siretart> ah :)
<glatzor> luckily all the drunken ones sleep during daylight :)
<fabbione> hi guys
<Hobbsee> heya
<zul> hey fabbione
<pitti> hey fabbione!
 * fabbione wonders who is the archive admin of the day
<fabbione> so how is life guys?
<pitti> fabbione: nice to be back home, although the conf, the party, the city, and the beer in Prague were very nice :)
<fabbione> pitti: eehhehe
<norsetto> asac: patch attached to bug 224611
<ubottu> Launchpad bug 224611 in firefox "firefox-2-dev lists wrong directory in .pc files" [High,Triaged] https://launchpad.net/bugs/224611
 * fabbione ponders a cluster release....
<fabbione> pitti: are you on archive admin duties today?
<pitti> fabbione: no, my shift is on Fridays; today is slangasek's
<fabbione> ok thanks
<pitti> I did an autosync run, though
<fabbione> that's ok.. it's not urgent
<fabbione> also because next week release/upload will have yet another shared library added
<fabbione> new'ing now or next week matters not
<fabbione> i am going to name 3.0: "The shared libraries inflated release"
<pitti> hehe
<pitti> bdmurray: regarding your recent editmoin comment: I just tried "editmoin -t SpecTemplate ubuntu/DesktopTeam/Specs/Intrepid/DevicePermissions", that works fine for me; what was your problem again?
<Laney> When calling "apt-get build-dep", is there any reason why one dependency wouldn't be pulled in? I have a package (ygraph) which build-deps on docbook-utils. This then depends on docbook-dsssl which in turn depends on (docbook | docbook-xml). The problem is that neither of the last two are being pulled in by apt-get. Something to do with the alternatives, maybe?
<pitti> asac: PPA langpack update complete
<pitti> asac: http://launchpad.net/+builds is munching through them full steam
<asac> pitti: ok. let me know when they built. I will take a preview look at the most important ones; then push everything to -proposed?
<pitti> asac: no, I won't upload those, since they are still in -gnome
<asac> hmm
<pitti> asac: if they work fine, I request a full export, and rebuild them from scratch
<pitti> the full export will happen tomorrow night
<asac> pitti: why do you need a full export to do the gnome -> pack move?
<pitti> (AFAIR)
<asac> the xpis are all in the current update pack
<pitti> asac: well, I could also manually merge the last full export and the delta
<pitti> but hte current delta is 200 MB, which is 70% of the full export
<pitti> with regard to that, a full export and fresh -base packages make sense anyway
<asac> no all fine. just wonder why you need a full in order to move those bits. at least i already QAed the 24th may bits
<asac> ok. please ping me when the full export is there - before pushing the update. i will pre-QA them so we dont miss a blacklisting or something.
<pitti> ok, will do
<asac> gratias
<Riddell> pitti: debian don't want to change soprano for bug 234952, since it would create a circular dependency, do you still think it worth me changing it in ubuntu?
<ubottu> Launchpad bug 234952 in soprano "libsoprano4 installs non-SONAME specific files" [High,New] https://launchpad.net/bugs/234952
<pitti> Riddell: d'oh; even for Debian it's not a question of whether they want it...
<pitti> Riddell: it's equally broken in Debian
<pitti> Riddell: why is a circular dependency a problem?
<pitti> for a new SONAME, the -bin package would flip dependency from libfoo4 to libfoo5, that's fine on upgrades
<Riddell> does a circular dependency create upgrade problems?
<pitti> I don't see why?
<ScottK> pitti: We've had clamav 0.92.1 and all the rdepends in feisty-/gutsy-backports for ~ 1 month now with no complaints.  We've got some open CVEs in the current versions that I've not had much luck getting someone to develop patches for.  I'd like to push the -backports stuff to -updates like we did for Dapper.  What do you think?
<pitti> ScottK: if it was good for dapper, it should be fine for feisty/gutsy IMHO
<Riddell> what's the advantage of splitting?  since both binaries and libraries need to have the same version installed
<emgent> ScottK: what CVEs ?
<pitti> ScottK: however, "no complaints" is just one side of the metric -- how many people use and tested the backports version?
<ScottK> pitti: Sounds good to me.  I'll prepare bugs with the details and get back to you.
<pitti> Riddell: just think about what happens if the SONAME needs a bump
<pitti> Riddell: you can't install version 4 and 5 in parallel, since they conflict
<pitti> but with a separate -bin, you can
<ScottK> emgent: Just a moment.
<pitti> ScottK: great
<Riddell> pitti: you can't with a separate bin, since the -bin depends on the same version of the library
<pitti> ?
<pitti> Riddell: the old version depends on 4, the new on 5; both are installable if the libraries are
<pitti> thus the -bin package can be upgraded independently, and without problems?
<Riddell> pitti: I can check with upstream, but I think that would be very unreliable
<ScottK> emgent: See Bug #217256
<pitti> Riddell: why should that be any different than any of the other 1000 source packages which produce libraries and executables?
<ubottu> Launchpad bug 217256 in clamav "ClamAV Upack Processing Buffer Overflow Vulnerability" [Medium,Fix released] https://launchpad.net/bugs/217256
<emgent> ok thanks ScottK
<emgent> woow more CVEs, backport sounds good for me
<pitti> Riddell: postgresql-client and libpq5, openssl and libssl0.9.8, libtiff4 and libtiff-tools, etc.
<pitti> Riddell: if the Debian guys are more comfortable with it, they could make the libsoprano5 Recommends: libsoprano-bin (which would probably be more correct anyway)
<pitti> but I still fail to see why a circular dependency would fail to upgrade
<mh21> warp10: in launchpad bug #195407, you removed the subscription of ubuntu-universe-sponsors because of the debdiff. What is the problem with it?
<ubottu> Launchpad bug 195407 in mingw32 "mingw-4.2 requires shared lib{gcc,stdc++} for cross-dll exceptions" [Undecided,New] https://launchpad.net/bugs/195407
 * pitti waves to mh21
 * mh21 waves back
<mh21> warp10: for me it applies cleanly to the latest source package, so I was wondering what needs to be done to get the bug fixed in Intrepid...
<persia> mh21: Mostly what you're doing.  If you don't get a response in 6-8 hours, just resubscribe the sponsors with a comment asking for more explanation if it is again removed from the queue.
<mh21> persia, thanks
<Hobbsee> mh21: looks like warp10 made an error there, and didn't even read the last comment :-\
<mh21> Hobbsee, I will just resubscribe u-u-s again tomorrow if nothing happens...
<narcarsiss> anybody here linked up with extreme tux racer i'm intrested in helping with the development i'm great in detecting errors in code, or any other program for ubuntu/debian
<lamont> meh.  why does ubuntu's rmadison not show ports architectures?
<narcarsiss> ask the developers :P
<persia> lamont: If you can find a solution, you'd not be the only happy person...
<lamont> persia: heh.  it's almost certainly a trivial solution
<persia> lamont: Well, assuming access to the right machines, yes :)
<lamont> persia: there is access, and there is access... :-)
<persia> lamont: So true
<soren> lamont: Also, there is trivial, and there is trivial. :)
<lamont> soren: I'm told it's pretty trivial - I'll file an RT sometime soonish
<ScottK> pitti: I've filed the clamav bugs.  It comes in 3 parts: Bug #235010 backports one rdepend I missed on the first round. Bug #235014 is for feisty-backports -> feisty-updates.  Bug #235021 is for gutsy-backports -> gutsy-updates.
<ubottu> Launchpad bug 235010 in gutsy-backports "Please backport gurlchecker 0.10.2-1 from Hardy to Feisty/Gutsy" [Medium,In progress] https://launchpad.net/bugs/235010
<ubottu> Launchpad bug 235014 in clamav "Please copy 0.92.1~dfsg2-1.1~feisty1 and rdepends from feisty-backports to feisty-updates" [Medium,Confirmed] https://launchpad.net/bugs/235014
<ubottu> Launchpad bug 235021 in clamav "Please copy 0.92.1~dfsg2-1.1~gutsy1 and rdepends from gutsy-backports to gutsy-updates" [Medium,Confirmed] https://launchpad.net/bugs/235021
<pitti> ScottK: whoops
<pitti> ScottK: does clamav need gurlchecker? i. e. do I need to wait with the copying until gurlchecker is built?
<ScottK> pitti: Yep.  My thought is do the missing backport and then pick it up later in the week.
<ScottK> pitti: No.
<pitti> ScottK: (and does gurlchecker need to be copied, too?)
<ScottK> pitti: gurlchecker does need to be copied, but it can be done after.
<ScottK> pitti: The lowest risk way to do this is to do the gurlchecker backport now and wait on the copying unti after it's built (e.g. tomorrow).
<crimsun> ogra: any objections to obsoleting libflashsupport (in favour of libasound2-plugins) for intrepid?
<pitti> yay
<Nafallo> hmm
<Nafallo> how can I use a SOCKS with apt-get?
<jdong> Nafallo: I'm guessing tsocks/socat is not the right answer?
<Nafallo> jdong: might be. just need to get the thingies to go through my ssh proxy. abusing Internet from a train :-P
<jdong> Nafallo: yay :)
<jdong> Nafallo: I was doin the same at an airport :)
<jdong> (this statement cannot be used as legal evidence against me in a court of law...)
<johanbr> Nafallo: openssh can tunnel through socks.
<jdong> johanbr: that's what he's doing I presume
<jdong> johanbr: he's asking how to get APT to use the tunnel
<johanbr> ahh. sorry. :)
<jdong> in which case I don't think socat/tsocks is a bad answer :D
<Nafallo> hehe
<jdong> probably the most utterly hackish answer
<jdong> but you guys have learend to expect that out of me :D
<Nafallo> proxychains looks kind of interesting :-)
<Nafallo> dockesn't do what I want :-/
<siretart> Nafallo: yes. use it with tsocks
<Nafallo> I only get E302 :-/
<Nafallo> W: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/dists/hardy-proposed/multiverse/binary-i386/Packages.gz  302 Moved Temporarily [IP: 91.189.88.46 80]
<Nafallo> oh well. works for evolution :-P
<Nafallo> I like that they kept my keep-alives running after the 30 minutes ;-)
<ScottK> Because apt doesn't know how to follow redirects.  There's an open bug on that.
<Nafallo> hmmm
<Nafallo> in other news... is something up with scandium?
<N00B> hi i need you help
<N00B> ??
<N00B>    	 	 	 	 	 	   Prince Harry
<N00B>  Scandals: Prince Harry often made experience with drugs. He also attacked a reporter, who was standing in front of a night club. Because of this he was called âDirty Harryâ. After that Prince Charles decided to send his son to Argentina.   There he was caught having sex on the toilette after a coktail party in the hotel.   In January 2005 he wore a uniform of the former Nazi regime at a carneval party. Because of this scandals the royal family and
<N00B> is this good english
<jpds> ##english would be the correct place but ......
 * lamont wonders what, if anything, he is supposed to understand as a bug report from bug 225608, or if that's just another example of "close the content-free apport bug" class?
<ubottu> Launchpad bug 225608 in postfix "Upgrade to 8.04" [Undecided,New] https://launchpad.net/bugs/225608
<mathiaz> lamont: usually I ask the reporter to post the content of the upgrade log files (found in /var/log/dist-upgrade).
<lamont> hrm.. bug 228439 should be reassigned to whatever package does the automounting now
<ubottu> Launchpad bug 228439 in util-linux "USB pen drive are not automatically mounted when plugged" [Undecided,New] https://launchpad.net/bugs/228439
<emgent> uhm
<emgent> why gradm2 is in ubuntu archivie?
<emgent> we dont have grsecurity yet.
<crimsun> emgent: likely because it was simply synced.
<emgent> crimsun: but we reject kernel-patch-grsecurit2
<geser> and nobody catched it till now that it's useless
<emgent> I'm working to it now
<ajmitch> that's because kernel-pacth-* stuff is blacklisted
<emgent> oh thank ajmitch
<emgent> s/thank/thanks/
<emgent> so, i should edit gradm2.
<ajmitch> edit it to do what?
<emgent> ajmitch: depends
 * lamont wonders what the new grand replacement is for xmms, now that he notices that gtkpod is b0rked
<pwnguin> rhythmbox?
<pwnguin> beep
<pwnguin> ?
<Robot101> lamont: beep media player is an xmms-alike
<lamont> Robot101: rather, what do I tell gtkpod to run
<lamont> ?
<bigon> infinity: ? are you around?
<lamont> and it'd be really nice to figure out why consolekit decided that it doesn't want to start on my desktop...
<lamont> not automounting things, but rather just giving a dbus error, isn't exactly nice...
<lamont> I suppose I could just reinstall hardy, but one would think that upgrading (via update-manager) would produce a working machine...
<lamont> or at least useful error messages.
 * lamont wanders off for a while
#ubuntu-devel 2008-05-27
<superm1> lamont, what's broke about gtkpod?
<superm1> i used it recently with no troubles
<lamont> superm1: what's broke is that it's config says to run xmms to play a song...
<lamont> so rather, it's my gtkpod config that's b0rked.
<dbmood2> hi ah you guys have a google problem
<dbmood2> put ubuntu logo into google
<dbmood2> the first logo is fine the bother two really should not be there
<ScottK> We don't really control what Google does.
<dbmood2> ScottK: you can inform them about it
<dbmood2> that is a real image problem
<dbmood2> oh wait it is fine now ... weird
<woli> how do i rsync 2 folders?
<woli> is that part of ssh?
<ScottK> rsync is a separate pacakge.
<ScottK> You need to install it and then if you look at the man page, it should be reasonably clear.
<ScottK> woli: #ubuntu is the channel for help.
<woli> yes but nobody knows the answer
<woli> ScottK, i already have rsync
<ScottK> That doesn't make this a help channel.  I've already given you a pretty strong hint.
<ScottK> Did you read man rsync?
<woli> but when i do rsync motherFolder childFolder it returns 'skipping motherFolder'
<woli> oops, i didn't know its existance. currently reading
<woli> but can i rsync locally without specifying machine-name?
<woli> well now i know how
<woli> sorry for the channel noise
<pitti> Good morning
<StevenK> Morning pitti
<pitti> hey StevenK!
<Hobbsee> pitti!
<Mithrandir> Hobbsee!
<Hobbsee> Mithrandir!
 * Hobbsee stomps on Mithrandir's feet in greeting
<Mithrandir> good thing I levitated first.
<Hobbsee> aww
<superm1> pitti, i was talking to tseliot briefly about the last thing I need to add for fglrx's source package.  He mentioned that there is a modaliases list that comes with it normally so that jockey knows when it can activate things.  Currently it is shipped somewhere in /usr/share I believe in a kernel specific directory (since it comes with every LRM package).  Is there a generic place I can drop one instead and have the same effect?
<Tm_T> hi kids
<stgraber> moin
<tjaalton> lamont: audacious is the xmms lookalike
<tjaalton> and descendant
<dholbach> good morning
<Tm_T> indeed
<pitti> superm1: yes, it is
<pitti> superm1: /usr/share/linux-restricted-modules/`uname -r`/modules.alias.override/
<mdke> dholbach: morning
<dholbach> hi mdke
<asac> pitti: did the lang pack builds go well? whats the ppa so i can test?
<pitti> https://edge.launchpad.net/~ubuntu-langpack/+archive
 * pitti tests now, too
<pitti> asac: German and English ones are there, yes
<pitti> asac: hm, updated language-pack-gnome-de, now my ffox is English
<pitti> asac: the langpack does have the .jar and friends, though
<asac> pitti: do you have RC1?
<asac> xul+ffox?
<pitti> asac: no, whatever is in hardy
<asac> otherwise thats expected
<pitti> beta5, I think
<asac> pitti: yeah. thats fine then ... install RC1 from mozillateam ppa
<asac> or let the batch into proposed
<tseliot> pitti: would you pull your hair if we had more nvidia-modealiases packages (one for each driver flavour) e.g. ï»¿nvidia-new-modealiases, etc. and perhaps different modealiases files in different folders?
<tseliot> err... ï»¿pull your hair out
<asac> pitti: ok gnome-de works fine here
<pitti> tseliot: sounds like a lot of clutter
<pitti> tseliot: why should they go into different directories?
<pitti> tseliot: /usr/share/linux-restricted-modules/`uname -r`/modules.alias.override/ was meant to be that one place
<pitti> tseliot: they should go to different files in that directory
<tseliot> ï»¿pitti: we are going to have separate source codes and separate packages for the different flavours
<pitti> tseliot: until we have an online db, this would be a reasonable compromise
<tseliot> ï»¿pitti: wouldn't /usr/share/modealiases/nvidia be a better place?
<pitti> ("this" -> separate -modalias package)
<pitti> tseliot: no, because then you need another meta-thing again which collects all those differnet directories
<pitti> tseliot: I'm fine with renaming the dir, but it should be *one* common dir
<tseliot> ï»¿pitti: so ï»¿using something like /usr/share/modealiases/ for any driver would be ok?
<tseliot> and we would have something like ï»¿ nvidia-new-modules.alias.override, etc.
<pitti> tseliot: s/mode/mod', yes
<tseliot> yes, mod stands for modules
<pitti> tseliot: it probably doesn't need to be kernel abi specific any more then
<tseliot> this is why I want to change the path to the modaliases
<tseliot> pitti: if you agree with the use ï»¿/usr/share/modealiases/ I can tell Mario about it
<pitti> tseliot: modalias, not modealias
<tseliot> sorry I copied and pasted the previous path
<pitti> :)
<tseliot> I won't mispell it in the package
<tseliot> I promise :-P
<pitti> superm1: just sent a reply with some more questions wrt. wl
<asac> pitti: ok i tested fi es pt de fr ... look fine
<pitti> nice
<pitti> asac: I requested a full langpack export, I should have it tomorrow around noon
<asac> pitti: ok. just wanted to ask if we want to roll them like they are now and do the move later. let me know what suites you better
<pitti> asac: I'd prefer one update instead of two; can it wait until Thursday, or do we need it right nwo?
<pitti> asac: the entire lot needs to be built on the non-PPA buildds anyway, so the diff is actually just one day
<asac> pitti: ok. just wanted to tell you that i would be fine if we'd do the move in the next regular "fulL" update
<pitti> ah, I see
<asac> the benefit of pushing the move back to next regular update would be that we could let the RC1 batch in now and start SRU verification
<pitti> well, given their current huge size, a -base refreshment makes sense now
<asac> pitti: the things that would need to go in are http://paste.ubuntu.com/15026/
<pitti> right, they are in the queue; I'll accept them tomorrow, together with the new langpacks
<asac> good
<asac> thanks
<pitti> asac: why two devhelp uploads?
<pitti> asac: or, rather, versions? the second one (0.19-1ubuntu1.8.04.2) should still be 0.19-1ubuntu1.8.04.1
<pitti> since 8.04.1 was never accepted
<pitti> (just a nitpick, though)
<asac> pitti: cant remember the exact issue. can you see the changelog?
<pitti> asac: rejecting the older broken one
<pitti> http://launchpadlibrarian.net/14709944/devhelp_0.19-1ubuntu1.8.04.2_source.changes
<asac> yep
<pitti> 'fix glue code' was the addition
<asac> right
<asac> the other embedders i tested worked properly without a rebuild. But Ill try harder during verification to track regressions
<asac> ArneGoetje: i installed language-packs for de, es, pt, fr, fi ... now i have this annoying SCIM thing again
<soren> Could some apply some archive admin love to ubuntu-vm-builder in the hardy unapproved queue?
<ArneGoetje> asac: should not happen
<asac> ArneGoetje: what info do you need?
<asac> ArneGoetje: maybe i have some old configuration?
<ArneGoetje> asac: probably
<asac> that was never automatically cleaned up?
<ArneGoetje> asac: it should have been cleaned up
<asac> ArneGoetje: yeah. so what info do you need?
<asac> i had -de installed and it didn't show up... then i installed http://paste.ubuntu.com/15031/
<ArneGoetje> asac: ls ~/.xinput/
<asac> ArneGoetje: i only have .xinput.d
<asac> there is en_US
<ArneGoetje> asac: which locale do you use?
<asac> ArneGoetje: i installed those packages and didn restart gnome
<asac> ArneGoetje: i am on en_US by default
<ArneGoetje> asac: as none of those packages depend on scim related software, I don't know why it triggered the problem again...
<fabbione> seb128: ping?
<ArneGoetje> asac: what is the output of im-switch -l ?
<fabbione> seb128: a very generic gnome question.. i am trying to debug gdm.. and it looks like gdm+glib2.0 are really strictly requering kernel inotify support
<fabbione> seb128: is there a way to disable it?
<asac> ArneGoetje: http://paste.ubuntu.com/15035/
<asac> hmm ... what is -th doing there
<seb128> fabbione: hey, gdm requires inotify are you sure? that's weird, what version are you looking at there?
<fabbione> seb128: i am looking at 2.22.
<fabbione> seb128: there are tons of levels of indirections via g_io_add_watch(..) that boils down to a bunch of calls in glib2
<fabbione> seb128: it seems that it uses inotify to create the user list to show at login
<fabbione> seb128: or update it realtime if you add/remove a user
<seb128> fabbione: I didn't look at gdm 2.22 yet, only redhat is using this one
<fabbione> seb128: ok.. i thought you might know :) thanks
<seb128> fabbione: do they use g_file_monitor?
<fabbione> seb128: i am not.. i am debugging the filesystem underneath :)
<ArneGoetje> asac: im-switch -z all_ALL -a and then paste the output of im-switch -l again
<fabbione> seb128: basically gdm keeps restarting if /home is on gfs2
<fabbione> seb128: and so far i found out that gdm/glib2 fail to set an inotify watch and then segfault a bit later
<fabbione> seb128: so basically i am trying to collect info to understand why it craps out and prepare a decent bug report for gnome upstream and you are still my best source of gnome info :)
<asac> ArneGoetje: http://paste.ubuntu.com/15040/
<seb128> fabbione: the glib monitoring should just fall back to something else (dnotify, fam, etc) if inotify is not supported
<ArneGoetje> asac: ok, try the same with sudo
<fabbione> seb128: ok.. it might be the fallback is buggy....
<fabbione> seb128: thanks a lot dude.. i really appreciate
<asac> ArneGoetje: so its an alternative bug?
<asac> ArneGoetje: e.g. status set to manual?
<ArneGoetje> asac: yep
<seb128> fabbione: you are welcome
<asac> ArneGoetje: hmm
<ArneGoetje> asac: the latest packages of scim and scim-bridge-agent should fix it
<asac> ArneGoetje: latest as in 8.04 or -proposed?
<ArneGoetje> asac: 8.04
<ArneGoetje> asac: does calling it with sudo fix the problem?
<asac> ArneGoetje: i think so its gone now :)
<ArneGoetje> asac: then the issue on your system was, that we changed language-selector during hardy developent to store the im-switch setting in the user's home directory and not system wide anymore. Seems there was some leftover from the system wide setting on your system
<asac> ok
<davmor2> Guys quick query on sound juicer.  As Rhythmbox is now the default player and it rips cd's into it's library is sound juicer going to be phased out?
<gnomefreak> davmor2: rythmbox isnt the same as sound juicer. rythmbox doesnt rip cds
<pitti> davmor2: yes, we'll drop it from main and the default install
<pitti> gnomefreak: RB rips CDs just fine, and much better integrated with music collection, etc.
<davmor2> gnomefreak: rhythmbox does.  I've ripped all my cd's to hd using rhythmbox
<gnomefreak> i didnt see an option for it
<davmor2> gnomefreak: click on the cd it opens the cd dialogue window then click on add to library
<davmor2> I think just drop in a cd and see :)
<seb128> pitti: we will not drop it from main
<seb128> pitti: will we?
 * cjwatson uploads a dpkg merge and hopes the world remains unexploded
<pitti> seb128: if you want to keep it in main, fine for me; but it should disappear from the default install at least IMHO
<pitti> cjwatson: good luck!
<seb128> pitti: I've not though about this one but usually we have official GNOME components to supported no?
<pitti> seb128: right
<davmor2> pitti: seb128: As far as I know RB uses serpentine libs to burn cds and SJ libs to rip them so pass.
<pitti> I didn't know that it still was an official component
<seb128> pitti: right, we agreed on that during uds
<seb128> pitti: rhythmbox is not an official GNOME component
<seb128> pitti: so they have no reason to deprecate s-j
<seb128> davmor2: sound-juicer has no lib
<seb128> davmor2: and rhythmbox doesn't use serpentine no
<ogra> s-j is only about 100-200 lines of pygtk code iirc (but i didnt look for more than 1.5 years though)
<stgraber> so rhythmbox is directly using sound-juicer to rip CD ?
<davmor2> seb128: Ah okay :)
<stgraber> or rhythmbox has a recommend I don't understand :)
<seb128> ogra: sound-juicer has been written in C from the start
<ogra> seb128, ergh, really ? i thought i remembered it to be pygtk ... but as i said thats 1.5years ago ... to much code has passed my eyes since  :)
<seb128> ogra: you are speaking about serpentine, aren't you?
<ogra> ooohh, right !
<ogra> thanks
<ogra> indeed
<davmor2> RB does depend on sound-juicer
<seb128> stgraber: rhythmbox used to open rhythmbox when you wanted to copy a cd, the recommends has likely not been cleaned
<gnomefreak> davmor2: from here it recomends it
<stgraber> seb128: ok, makes sense
<seb128> davmor2: it doesn't
<davmor2> gnomefreak: you are correct it's me looking in the wrong place sorry
<gnomefreak> :)
<davmor2> need caffeine
<gnomefreak> it depends on a bunch of other things though
<tjaalton> rhythmbox does not integrate that well with musicbrainz, there's no option to submit the data if the information is missing from mb
<tjaalton> but, maybe that'll change
<emgent> morning
<davmor2> tjaalton: your right have you reported it as a bug?
<davmor2> if not then I can
<seb128> siretart: we are using team assignment for all the desktop bugs for information (just reading your mail on the list)
<tjaalton> davmor2: no I haven't, please do :)
<davmor2> tjaalton: Np's
<davmor2> I'll bug it upstream do we want it adding to LP too ?
<tjaalton> musicbrainz is very cool, hope people will use it more :)
<tjaalton> davmor2: either way is fine by me, let me know the bug #
<siretart> seb128: I don't understand why you choose assignments over subscriptions for allocating a bug to a team, mostly because I see quite some limitations with that approach. Could you perhaps elaborate on the merits?
<seb128> siretart: it allow to define a set of bugs that the team will fix for a milestone without deciding on the individuals who will do the work
<siretart> seb128: that part I did understand. I don't understand whats superior to just subscribing the team
<seb128> siretart: then people can claim bugs when they start working on those and change the assignement
<seb128> siretart: subscription doesn't appear on the milestone bug lists, etc
<siretart> so you need to see what team is going to work on a bug on the milestone bug list?
<seb128> yes
<siretart> what if a bug could be allocated to two teams?
<seb128> I know we had other cases too, that's one I'm thinking about now
<siretart> e.g. it is not sure if it is a compiz or xorg bug?
<seb128> you don't assign when you don't know
<seb128> or you assign to the most likely team and it can be reassigned if required
<davmor2> tjaalton: http://bugzilla.gnome.org/show_bug.cgi?id=535065
<ubottu> Gnome bug 535065 in User Interface "If a cd is not listed in musicbrainz it can not be added." [Enhancement,Unconfirmed]
<siretart> seb128: I need to think about this argument a bit more. maybe you could raise this point on the mailing lists? Perhaps some other people could elaborate further on this thought.
<seb128> siretart: I need to think about it, but we are using this workflow for years, not sure why you consider it as wrong
<siretart> I currently have a feeling that this is mostly an UI issue. changing assignments is currently easier exposed in the UI than subscription, which might be a reason why some people prefer that
<siretart> seb128: we are currently discussing bug handling extensively, both at UDS and now post-UDS on the bugsquad mailing list. My current observation is that bug assignments are used inconsistently which does cause quite some confusion on different sides
<siretart> seb128: and I do consider this confusion as problematic and am currently thinking about how to reduce it
<seb128> ok
<siretart> assigning a bug to a team has always confused me a lot for several reasons
<siretart> like if a team is assigned, then there is still no responsible person for this task. this is likely to give a false sense about what is going to happen with the bug.
<siretart> or the fact that you cannot assign to multiple teams
<siretart> I think on ubuntu-devel@l.u.c are some more arguments against
<seb128> assigning to a team means a group of people is responsive for the issue
<siretart> which in practice means no one is responsible
<seb128> subscription give you no information about who is going to work on something
<siretart> at least to my observation
<seb128> well, it means that you have a point of contact to discuss the issue
<seb128> and that the team members have a todo
<siretart> the archive administrators demonstrate that a todo list can be implemented as good with subscription as with assignments
<siretart> s/good/well/
<tjaalton> davmor2: thanks, subscribed
<siretart> my point is that these two techniques are used inconsistently, which causes confusion. let's settle on the better method to reduce that, I'd say
<seb128> siretart: archive admin has an easy job, they have a low number of bugs than they bring to almost 0
<seb128> siretart: so you can go through the list easily
<seb128> siretart: which is not true when you have some thousand bugs
<siretart> which team takes desktop bugs?
<seb128> desktop-bugs
<siretart> https://bugs.edge.launchpad.net/~ubuntu-bugs/+assignedbugs shows 2 bugs
<siretart> oh
<siretart> wrong team
<davmor2> tjaalton: also bug 77346 was open referring to the same thing so I tagged the upstream bug to it :)
<siretart> https://bugs.edge.launchpad.net/~desktop-bugs/+assignedbugs shows 3515 bugs
<ubottu> Launchpad bug 77346 in rhythmbox "No method for submitting CD track listings" [Undecided,Confirmed] https://launchpad.net/bugs/77346
<seb128> siretart: right ;-)
<siretart> I'm suprised why you claim that assignment works better than subscription. I guess I need to take that.
<tjaalton> davmor2: oh cool, subscribed to that too :)
<ScottK> pitti: I'm going over the clamav backports -> updates copies and it a appears that claws-mail 2.10.0-3ubuntu3+gutsy1 did not get copied. The rest all look good.  Thank you very much.
<ScottK> pitti: Do you think we should remove them from backports?
<pitti> ScottK: seems that slipped; for feisty, too, I suppose?
<pitti> StevenK: we can remove them to reduce confusion, yes
<ScottK> pitti: No.  It's a new package for Gutsy, not in Feisty.
<ScottK> pitti: One less set of things to worry about security updates for.
<pitti> ScottK: copied
<ScottK> pitti: Thanks.
<cjwatson> slangasek: is bug 234901 interesting for you in samba?
<ubottu> Launchpad bug 234901 in samba "Please apply upstream patch for dpkg-buildsource" [Undecided,New] https://launchpad.net/bugs/234901
<luisbg> how can I compare the list of packages in the gutsy cd to the packages in the hardy cd?
<tjaalton> luisbg: try 'dpkg --get-selections'
<pitti> luisbg: download the .list/.manifest files on releases.u.c. and run diff -u on them
<luisbg> pitti, I see the .lists but not the manifests
<luisbg> at http://releases.ubuntu.com/hardy/
<pitti> luisbg: .manifest is only for desktop CDs
<pitti> (contents of live fs)
<luisbg> very true
<luisbg> pitti, thanks!
<pitti> ScottK: removed from -backports
<ScottK> pitti: Thanks.  This is a good day.  I started working on this 11 months ago ....
<emgent> hello people
<mvo> cody-somerville: could you please check LP #235113 and let me know what you think?
<ubottu> Launchpad bug 235113 in update-manager "Update Manager fails Xubuntu 7.10 to 8.04 LTS if universe is not enabled" [Medium,Confirmed] https://launchpad.net/bugs/235113
 * cody-somerville dies.
 * mpt blinks
<mpt> Did anyone else receive, less than an hour ago, a message that was sent to ubuntu-devel-discuss@ on 1st June last year?
<Festor> O.o
<Ng> I did :)
<cody-somerville> What was it about?
<mpt> Not just a wonky datestamp, either, it's all about 7.04
<cody-somerville> "Do we need a new 'Welcome to Ubuntu'?"?
<cody-somerville> hehe
<cody-somerville> I replied to that :P
<cjwatson> mpt: sounds like it was stuck in a moderation queue
<mpt> Did you say "Greetings from the distant future"?
<Spads> Ng reckons it was in the moderation queue for a year
<cjwatson> presumably since it triggered a spam check or something - ubuntu-devel-discuss isn't normally moderated
<cjwatson> hence why its moderation queue doesn't get looked at a whole lot, probably ;-)
<mpt> Once a year is often enough :-)
<evand> probably my fault.  ubuntu-devel-discuss has a large queue from before I started admining it, I imagine I accidentally clicked approve on one of the older messages when processing the new ones.
<sebner> elmo: around? I heard I have to annoy you to get my @ubuntu.com mail activated ;)
<emgent> sebner: canonical sysadmin working to it, dont worry
<sebner> ember: =)
 * ScottK hands sebner some tab completion.
<sebner> ScottK: lÃ¶l. thx
 * sebner wishes that users would use more significant nicks :P
* raeLLL changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | Ubuntu 8.04 LTS released! | Development of Ubuntu (not sff upport, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
* thom changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<thom> (fix the word support)
<raeLLL> I just happened to try to changed the topic, why a normal user here have the permission to change the topic?
<stdin> because people generally don't try to change the topic here
<stdin> "trust"
<cjwatson> raeLLL: it's more convenient to deal with the odd breach than it is to administer topic change requests
<mario_limonciell> pitti, since the source package will be NEW, I should be able to directly upload the fglrx source package to the archive without needing a core-dev right?
<cjwatson> mario_limonciell: NEWness is applied after GPG checks
<cjwatson> oh, but you mean since it wouldn't know what component it was meant for
<mario_limonciell> exactly
<cjwatson> I could check the code, but it might be easier just to try it. :)
<mario_limonciell> okay :)
<mario_limonciell> yup that worked.  well guess that's the only upload I'll be able to do for it directly myself once it's all overridden and such, at least until the archive reorg stuff goes through. :P
<ScottK> mario_limonciell: That or kick in to gear and get core-dev.  It'd probably be faster.
<mario_limonciell> ScottK, good point, but that is dependent on how much stuff I'll be able to do for core-dev worthy things these next few months.  We'll see
<ScottK> mario_limonciell: They took me.  How hard can it be?
<Tm_T> raeLLL: you don't need to be an idiot just because noone is stopping you before you start ;)
<raeLLL> Tm_T: start what?
<mario_limonciell> ScottK, yeah you already had a lot of focus on items with main implications (Kubuntu related).  this would be more territory for myself.  All of my main implications have been indirect thus far
<Tm_T> raeLLL: being an idiot ;(
<raeLLL> I just feel it strange.
<ScottK> raeLLL: We do a lot of things differently in Ubuntu.  One of them is generally expecting people to behave nicely and responsibly.
<cjwatson> mario_limonciell: archive reorg wouldn't magically let you upload to things in the core anyway
<cjwatson> if you aren't already core-dev
<mario_limonciell> cjwatson, i'm meaning that I would be asking for permissions on that particular package
<cjwatson> mario_limonciell: I see that as sort of an add-on to the main thrust of archive-reorg
<cjwatson> mario_limonciell: in fact that could be done completely independently
<ScottK> cjwatson: Since I didn't manage it personally before I left, I wanted to thank you for the developer docs session Friday AM.  I wasn't able to make it, but from reading the gobby page and talking to those that were there it seems like a very needed, good idea.
<cjwatson> ScottK: siretart mentioned some conversations he'd had with you; thanks, indirectly
<cjwatson> I'll get that onto ubuntu-devel once I have a little more to show
<mario_limonciell> cjwatson, are you meaning that independently of the reorg, it would be possible to adjust permissions on a per package basis?
<pochu> mario_limonciell: hi :) bug 134456?
<ubottu> Launchpad bug 134456 in soyuz "Soyuz needs package-specific uploaders" [Medium,Fix committed] https://launchpad.net/bugs/134456
<pochu> This will allow us to have a Dell engineer, or team, maintain a
<pochu> Dell-specific package even if it is in main. It will allow an upstream
<pochu> engineer from product foo to get involved in the foo package in Ubuntu.
<pochu> that's you! ;)
<cprov> pochu: very well explained :)
<mario_limonciell> hi pochu :).  oooh.  This is very good to see.  I wonder how it will be exposed though?  Does there have to be a LP interface to match it, or will it end up in in the source package itself?
<pochu> mario_limonciell: no idea, but cprov probably knows :)
<pochu> cprov: hi! I wonder what bug 207680 means exactly... I guess it's not that MOTUs will be able to accept packages from NEW :)
<ubottu> Launchpad bug 207680 in soyuz "Community Admin: Require MOTU queue access for universe/multiverse" [High,Fix committed] https://launchpad.net/bugs/207680
<cprov> mario_limonciell: the infrastructure will in place tomorrow, the changes will be done by request.
<mario_limonciell> cprov, by request to whom particularly, LP admins, or archive admins?
<cprov> mario_limonciell: get in touch with the distro-team, once they approve we will adjust the data.
<Amaranth> ooh, maybe i'll be able to upload compiz soon then :)
<pochu> heh
<cprov> mario_limonciell: first talk with archive-admins / cc
<pochu> Amaranth: luckily I use metacity ;-)
<cprov> mario_limonciell: I think that's the way it's supposed to work.
<mario_limonciell> cprov, very cool.  glad to see this happening
<pochu> Amaranth: I read that metacity message from you on "3 things you don't know about me" and I believed it o_O
<Amaranth> hehe
<Amaranth> I really was most of the time while I was there, the laptop I was using was buggy
<StevenK> I don't recall that one, what was it?
<Amaranth> "I use metacity"
<cprov> mario_limonciell: yes, I will certainly shake ubuntu-community organisation.
<zul> mvo: ping
<cjwatson> cprov: err, please don't just say "get in touch with the distro-team", we don't have a process for dealing with such requests yet and having everybody turn up on our doorstep tomorrow won't be immediately helpful; and furthermore it should be the Ubuntu Technical Board or some group delegated by it, absolutely not the Canonical distro team
<cjwatson> the best approach is probably for people who want to upload packages outside their normal permissions to apply at a TB meeting, and once the TB is swamped then they can delegate
 * Amaranth applies :)
<cjwatson> cprov: please don't take requests for this from people not on the TB or authorised by it though, even if they're on the distro team (for example I shouldn't be authorised to make such a request, right now)
<mvo> zul: pong (about to leave for the evening)
<zul> mvo: can I take net-snmp off your hands?
<ScottK> The TB might even want the MC to pre-screen requests much as it handles MOTU and core-dev applications.
<cprov> cjwatson: okay, I apologise for the misleading suggestion.
<mvo> zul: sure
<zul> mvo: thanks
<cjwatson> cprov: no problem, gives me the opportunity to explicitly disclaim responsibility ;-)
<mvo> zul: I have no idea why I touched it, probably some sort of upgrade issue
<cjwatson> (makes a change)
<cjwatson> ScottK: quite possibly, though not for me to say. The TB still has veto over ubuntu-dev applications, doesn't it (at least in theory)?
<ScottK> Yes they do.
<ScottK> Off the top of my head I was thinking MC could authorize individual uploaders for Universe and recommend to TB for Main.
<ScottK> TB still gets a veto of course.
<cjwatson> hmm, merges.ubuntu.com is slothful to update again
<raytruz_>     Anyone know why padlock_aes.ko went away with today's kernel upgrade?
<Tophat> how do i get started on the ubuntu kernel ?
<Tophat> i've read over the wiki but there isn't much of a how-to get started for the average windows developer.
<pochu> Tophat: I don't really know, but #ubuntu-kernel may be a better place to ask :)
<Tophat> oh snap.  sorry mate
<pitti> superm1: right
<raytruz_> I get this error after the update today: http://pastebin.org/38946
<raytruz_> Anyone have any insight
<pitti> hm, WFM on amd64
<pitti> BenC: ^ any idea?
<emgent> someone remember in what file mozilla-thunderbird read mailbox user/pass of accounts?
<geser> pitti: any ETA on when bug #229901 and bug #229906 get processed? both are needed to get further with the perl 5.10 transition
<ubottu> Launchpad bug 229901 in libreadonly-xs-perl "Please sync libreadonly-xs-perl 1.04-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/229901
<ubottu> Launchpad bug 229906 in libreadonly-perl "Please sync libreadonly-perl 1.03-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/229906
<Mirv> if someone who knows me is awake, please add some cheers to my wiki page at https://wiki.ubuntu.com/TimoJyrinki for the Ubuntu membership meeting (in case they'd help)
<pitti> geser: can do
<geser> thanks
<mario_limonciell> hmm well why would these fail to upload? https://edge.launchpad.net/ubuntu/+source/fglrx-installer/2:8.493.1-0ubuntu3  they built successfully
<tjaalton> Mirv: done!
<Mirv> tjaalton: thanks :)
<mario_limonciell> is this related to ogre model messiness since the source package is in multiverse?
<mario_limonciell> or is it because a new LRM upload needs to be done still without fglrx in it so there are no conflicts?
<mario_limonciell> tjaalton, would you be able to do that LRM upload with the fglrx stuff commented out?
<tjaalton> mario_limonciell: hmm, I don't think that's why. do you have the error message?
<mario_limonciell> tjaalton, "#   intrepid amd64   Failed to upload "
<mario_limonciell> same thing for i386
<pitti> seb128: argh, gnome-desktop went straight to hardy-updates
<seb128> pitti: ups, I got a cold when coming back and did some mistakes in those updates apparently
<mario_limonciell> tjaalton, the failed to upload seems to be referring to the binary packages I  think
<seb128> pitti: I'm pretty sure it'll not screw anything though, the changes are in gnome-about which is a side application
<tjaalton> mario_limonciell: so fglrx-installer is the source package generated from the upstream blob?
<seb128> pitti: and the libgnome-desktop change is a few lines to use unsigned int rather than int and fc9 is using it
<mario_limonciell> tjaalton, yes
<mario_limonciell> all of the stuff that happens in these first few uploads i'll sync up with that package.
<pitti> seb128: *hug* get well soon!
 * seb128 hugs pitti
<fde> Hello, sorry to bother you, when you hit ESC in recovery mode, what is ran?
<fde> ie, what tool or service performs the magic?
<mario_limonciell> fde, recovery mode uses the friendly-recovery package
<fde> mario_limonciell: thank you!
<tjaalton> mario_limonciell: ok, it could be something like you suggested after all, but I can't really tell for sure
<mario_limonciell> tjaalton, okay i just posted in #launchpad.  maybe a soyuz dev can chime in
<norsetto> pitt, seb128: re. gnome packages to -updates, just installed, so far so good
<seb128> norsetto: thanks
<seb128> as said gnome-desktop should be no issue
<seb128> siretart: subscribing doesn't tell you who is going to work on the bug, there is a zillion of people subscribed to some GNOME packages who never work on those
<tjaalton> mario_limonciell: btw, you are using the module version number and not the catalyst version?
<mario_limonciell> tjaalton, internal version number of the package is what ATI had wanted people to use
<mario_limonciell> so it was consistent
<mario_limonciell> via ./ati-package-helper.sh --version
<tjaalton> ok
<detrolex> does ubuntu provide any support for mp3/ntfs ?
<norsetto> !support | detrolex
<ubottu> detrolex: The official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org
<norsetto> detrolex: the short answer is yes
<detrolex> k
<detrolex> thx
#ubuntu-devel 2008-05-28
<pitti> Good morning
<ajmitch> hi pitti
<dholbach> good morning
<soren> Any chance of a bit of unapproved queue love today?
<pitti> soren: yes, I'll get to it; I spent two hours on it yesterday, until I had to run out
<pwnguin> neat
<pwnguin> i wrote to a guy about mindscript's license (posted a few days ago) and he agreed to publish it under gplv3
 * soren hugs pitti
<soren> pitti: Sounds great!
<pitti> bdmurray: wrt our hal-info discussion yesterday, I just sent an SRU proposal to TB, CC'ing u-devel@
<seb128> hum, upgrade to intrepid doesn't work
<soren> Wow.
<soren> I was literally seconds away from saying:
<seb128> xargs assertion error
 * soren takes the red pill and installs intrepid on one of his servers
<soren> Maybe I should wait a bit. My workstation seems to be chugging along just fine, though.
<seb128> xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed
<seb128> I get that on debconf installation
<seb128> https://bugs.edge.launchpad.net/ubuntu/+bug/232416
<ubottu> Launchpad bug 232416 in ubuntu "debconf upgrade: xargs Assertion `bc_ctl.arg_max <= (131072-2048)' failed." [Undecided,New]
<seb128> https://bugs.edge.launchpad.net/ubuntu/+source/findutils/+bug/234345 too
<ubottu> Launchpad bug 234345 in findutils "xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed." [Undecided,Invalid]
<soren> Yeah, infinity was working on that problem on the buildd's when we were at UDS, I think.
<soren> I thought it was resolved.
<seb128> ok
<seb128> upgrading findutils to the intrepid version and restarting the dist-upgrade worked
<seb128> something should pre-depends on the new version then
<Keybuk> why findutils?
<Keybuk> oh, because that's where xargs is
<seb128> Keybuk: because that's where xargs is
<Keybuk> I had it in my head as in coreutils
<cjwatson> the only thing I can imagine is that the new libc6 trips it
<cjwatson> (somebody should test that)
<cjwatson> in which case libc6 should Breaks: findutils (<< whatever)
<Keybuk> it was the new libc
<Keybuk> I assume that it increased the maximum argv length
<Keybuk> and broke xargs assert
<StevenK> \o/
<StevenK> We saw that on the buildds at the start of UDS/Fosscamp
<StevenK> Actually, that would explain why pitti's build fixed it.
<cjwatson> so Breaks seems appropriate then
<cjwatson> indeed, if it picks it up at compile-time
<StevenK> They changed the define, xargs was built against the old libc, the new one is installed, and xargs goes bang.
<StevenK> pitti uploads a no-change upload that infinity hand-held, and it is built against the new libc
<StevenK> So no assert error
<cjwatson> somebody should report that to findutils upstream too; it's a corner case, but nasty
<StevenK> Indeed
<soren> Why would findutils want to make that assertion anyway?
<geser> pitti: Hi, please give-back: libparams-validate-perl. Thanks.
<soren> I could understand why it'd make sure that arg_max was *more* than what it used internally. Not less.
<soren> Oh, or is bc_ctl.arg_max perhaps its internal max_argv?
<soren> That would make sense.
 * soren makes a note to think more before he types
<pitti> geser: nudged
<pochu> some core-dev could decline the edgy nominations from https://bugs.edge.launchpad.net/ubuntu/edgy/+nominations, as edgy is out of support now
<pitti> pochu: done
<pochu> thanks pitti
 * pitti fixes the bug number parsing in http://people.ubuntu.com/~ubuntu-archive/pending-sru.html to match current LP HTML
<pitti> seb128, bdmurray, ogasawara_: ^ FYI, they are reasonable now, no upstream bugs, all LP bugs
<seb128> pitti: ah good, I looked at it this morning and it was lacking some bugs, seems alright now ;-)
 * seb128 hugs pitti
<pitti> seb128: it changed recently, it's LP: <a href="/bugs/220805" ... now
<seb128> ok
 * ion_ fails to understand why apt-get dist-upgrade installed dbus and dbus-x11 to his virtual intrepid system. Nothing that is installed seems to depend on it.
<geser> ion_: recommeds-by-default perhaps
<geser> doko: do you know when you will find some time to review/comment/sponsor bug #229877?
<ubottu> Launchpad bug 229877 in cpio "[intrepid] cpio build-depends on mingw32" [Undecided,New] https://launchpad.net/bugs/229877
<ion_> geser: No metapackages that are installed seem to recommend it either.
<geser> ion_: aren't recommends installed now for all packages and not only metapackages?
<gnomefreak> dbus is installed by default and i thought ubuntu-desktop has it as dep
<ion_> Oh. That i didnât know. libdbus-1-3 indeed recommends dbus.
<gnomefreak> or not
<gnomefreak> ah
<geser> ion_: see the changelog for apt 0.7.13ubuntu1: * enable installation of recommends by default
<ion_> Yeah, i read it after you mentioned it.
<Riddell> pitti: split soprano and decibel should be available if you are able to take a look
<pitti> Riddell: ok, thanks
<siretart> asac: is there still something to do for bug #141233?
<ubottu> Launchpad bug 141233 in wpasupplicant "MASTER network-manager crashes when wpasupplicant ctrl socket is not available" [Medium,Confirmed] https://launchpad.net/bugs/141233
<asac> siretart: its worked around on network manager side, but it still exists iirc
<asac> e.g. just shutdown sometimes will not release control socket
<siretart> what do you mean with 'releasing' the control socket. 'unlink'-ing?
<siretart> I'm inclined to propose marking it as invalid for wpasupplicant for now. I don't think this is a problem if wpa_supplicant is used standalone
<siretart> and for the interaction part NM vs wpa_supplicant, a workaround is found. so what's left to do?
<james_w> If I have a usb key formatted as vfat then it gets mounted so that my user owns it and can write to it. If it is formatted with ext2 then it is mounted with root as the owner and no write permissions for anyone else.
<james_w> This is with nautilus taking care of the mounting. Is this intentional, a bug, or should I configure what I want somewhere?
<james_w> oh, and the filesystem is actually within a luksformat created partition, which may make a difference.
<seb128> james_w: that's a gnome-mount thing, start gconf-editor, system, storage, default_options
<seb128> james_w: there is default options specified for vfat there
<james_w> ah, thanks, I see it.
<james_w> is there a reason that ext2/3 are not there?
<seb128> james_w: the behaviour for ext* might be wanted, not sure, you should ask pitti about that
<james_w> I guess it shouldn't interfere with system volumes, and they typically wouldn't be vfat.
<pitti> james_w: it's half-intended, I'd say
<pitti> james_w: the underlying problem is that ext2 & friends do not support mount options "uid" and "gid"
<pitti> james_w: primarily because they have a clear idea about multiple users/groups and thus just changing root:root files would be inconsistent
<james_w> ah, I didn't know that.
<pitti> james_w: for those you either need to create a folder for you, or chown the drive's / to you, or use vfat
<james_w> thanks pitti, I should be able to get what I want from here.
<pitti> geser: I had to reject your apache-itm upload, the changelog had a wrong bug number (lp: #xxx)
<calc> slangasek: hi
<cjwatson> calc: he's been on holiday so far this week, FYI; back tomorrow
<calc> cjwatson: ah ok :)
 * calc is on vacation still as well, just waiting for his wife to get ready
<YokoZar> Apparently you can use tinyurl with apt-url: http://tinyurl.com/2bhmdp  <--- installs Wine
<geser> pitti: argh, will upload a fixed one
<cjwatson> YokoZar: I'm sure it can't be a good idea for the browser to support that; although I suppose it still prompts
<calc> OOo 2.4.1 rc1 is out now and might end up being the final one released early next week, still watching the lists to see what happens
<cjwatson> calc: kinda moot if it doesn't make it into the archive for the deadline, though
<mvo> if there is anyone with a powerpc, I would appreciate testing for the fix for bug #220890
<ubottu> Launchpad bug 220890 in software-properties "[hardy] software-properties-gtk doesn't recognize (nor know about) ports.ubuntu.com" [High,Confirmed] https://launchpad.net/bugs/220890
<calc> yea, i can upload the rcX whatever is available in time for the deadline, it will most likely just get renamed
<calc> i will see what i can find out on monday at the release meeting
<cjwatson> I think I had assumed from your mail that it had already been uploaded
<cjwatson> I understand the deadline to be Sunday, BTW
<calc> cjwatson: m14 has been the final 2.4.1 is scheduled for official release on june 3
<calc> oh argh, i will be in the air at that time :(
<cjwatson> just in case that wasn't clear
 * calc had forgotten the deadline was june 1 the same as his fly home date
<calc> ok well i'll get rc1 into proposed once m14 is done building everywhere to make sure there aren't any problems
<calc> shouldn't take too long to do that update
 * calc checking the diff between m14->m16 upstream
<tjaalton> deadline? for .1?
<lucas_> how can I check if a package is shipped on the ubuntu CDs?
<lucas_> (the package is libruby1.8)
<tmmoyer> I would like to try and package a program called TrustedGRUB, but looking at the way its source tree is structured, it doesn't really follow the conventional Makefile at the top-level idea.  It has a custom shell script to build the binaries and requires user interaction.  What would be the best method of packaging it?  My first thought is to add a Makefile that handles everything (i.e. calling the build script and then running the commands that t
<ompaul> lucas_,  /msg ubottu info libruby
<lucas_> ompaul: I know it's in main, but it doesn't say if it's shipped
<cjwatson> tjaalton: yes. June 1
<cjwatson> https://wiki.ubuntu.com/HardyReleaseSchedule has it (in fact documents something slightly earlier due to week alignment)
<cjwatson> tmmoyer: there's no reason upstream build scripts have to be Makefiles; they just have to be callable from debian/rules
<cjwatson> debian/rules can do whatever it likes, not necessarily $(MAKE)
<tjaalton> cjwatson: ok, thanks for the heads-up.. need to get busy then ;)
<cjwatson> you could even use expect to deal with user interaction if there was no other way
<cjwatson> lucas: look at the .list and .manifest files distributed alongside the CDs
<lucas> cjwatson: thanks
<tmmoyer> cjwatson: what about the user interaction.  I think i may have mis-spoken about "interaction" what i really mean is that the script just builds the binaries then the user has a list of commands to run to actually install the binaries
<cjwatson> tmmoyer: even easier then
<cjwatson> just have debian/rules copy stuff into the filesystem hierarchy (under debian/$PACKAGENAME/) as necessary
<cjwatson> or use dh_install
<tmmoyer> okay thanks... i will play around and see what I can come up wth
<bdmurray> pitti: thanks for letting me know about hal-ifno
<pitti> bdmurray: you're welcome
<tmmoyer> when a package uses autoconf and automake, is there a way to ensure that the generated Makefile installs to DESTDIR instead of / as instructed my dh_make
<tmmoyer> nevermind after digging into the documentation a bit more, i found that automake respects DESTDIR staged installs
<asac> bryce: could you follow up on bug 211569 (milestoned)
<ubottu> Launchpad bug 211569 in hal "xsane won't start unless run as root (Epson Perfection 1240)" [Medium,Incomplete] https://launchpad.net/bugs/211569
<bdmurray> pitti: some of the SRU verification for 8.04.1 requires a new iso correct?
<pitti> bdmurray: right, the installer bits
<bdmurray> pitti: rescue too - bug 218549
<ubottu> Launchpad bug 218549 in rescue "Choosing "Reboot" in rescue menu jumps to main menu" [Medium,Fix committed] https://launchpad.net/bugs/218549
<cjwatson> I was waiting until the kernel was definitely final
<cjwatson> since it needs a debian-installer upload
<pitti> linux -18 is around the corner
<bdmurray> pitti: could / should we start identify those SRUs which require an ISO?
<pitti> bdmurray: that's relatively easy
<pochu> what's an ISO?
<bdmurray> I was thinking something similar to hw-specific
<pitti> bdmurray: apt-setup, base-installer, grub-installer, rescue
<bdmurray> Is new CD image better?
<pochu> ah, packages which go into the CDs :)
<pochu> I thought it was another process
<bdmurray> pitti: kickseed?
<pitti> I'm not sure what this is about, but yes, it's a d-i module
<cjwatson> kickseed will require it, yes
<bdmurray> pitti: my concern is we have a list of 4 or 5 packages and a tag might be easier to track
<bdmurray> cjwatson: speaking of bug 221501 doesn't have a test case
<ubottu> Launchpad bug 221501 in kickseed "grub-installer failing on Hardy kickseed when "bootloader --md5pass" is set" [Medium,Fix committed] https://launchpad.net/bugs/221501
<bryce> asac: ok
<cjwatson> bdmurray: fixed
<bdmurray> cjwatson: great thanks!
<bdmurray> cjwatson: is bug 218975 still an issue for you?
<ubottu> Launchpad bug 218975 in yelp "refuses to follow http: links from toc.xml" [Undecided,Incomplete] https://launchpad.net/bugs/218975
<cjwatson> bdmurray: will follow up on the bug
<bdmurray> thanks
<pitti> Keybuk: FYI, sysvinit merge upload now works fine; upload pending merge of devmapper, though, since it conflicts to the current version in intrepid
<Keybuk> what changed in devmapper?
<pitti> no idea, I didn't check that closely why it conflicts
<pitti> Keybuk: Debian/upstream accepted two of our big patches, though \o/
<pitti> unfortunately not the third one
 * pitti sends some sysvinit patches Debianwards in the meantime
<Keybuk> what was the third one?
<pitti> +    - Call dmsetup from udev rules to name the device, so udev creates them
<pitti> +      if they do not already exist, and fill in information about the
<pitti> +      filesystem on the device afterwards.
<pitti> +      (forwarded to Debian #455746)
<ubottu> Debian bug 455746 in devmapper "udev support" [Wishlist,Open] http://bugs.debian.org/455746
<pitti> they accepted the 'export' option and the 'create devices atomically' patches
<Keybuk> heh
<Keybuk> so the main patch, then ;)
<Keybuk> did they use the same atomic patch as us?
<Keybuk> upstream wailed like a bitch to me about that one
<pitti> changelog says 'slightly modified'
<Keybuk> *cough*
<Keybuk> interdiff might be nice to see there ;)
 * pitti just parrots the changelog, he didn't look at the patches at all
<pitti> Keybuk: http://merges.ubuntu.com/d/devmapper/devmapper_2:1.02.25-1.patch :)
<Keybuk> since I'm vaguely arguing that LVM-by-default is good, it might be nice to not break it
<Keybuk> that is, until Casablanca happens
<pitti> . o O { Casablanca? }
<Keybuk> pitti: ZFS-in-Linux
<Keybuk> patch looks ok
<Keybuk> I think
<Keybuk> by upstream you mean Debian, right? :)
<pitti> some upstream, yes :)
<norsetto> asac: any news about my last email?
<pitti> Keybuk: is patches.ubuntu.com greppable somewhere? I'd like to know how many/which packages still use update-rc.d with 'multiuser'
<smarter> multiuser is deprecated?
<Keybuk> pitti: casey.ubuntu.com
 * danshearer is away: whoops have to rush off home
<pitti> Keybuk: ah, EPERM on that :/
<Keybuk> pitti: -> elmo ;)
<tmmoyer> where might I find information/source for the installer that handles bootloaders?Â  I would like to see how grub is installed and create a custom version that will installer TrustedGRUB from a package that I have created?
<infinity> tmmoyer: apt-get source grub-installer
<tmmoyer> thanks
<ceekay> anyone able to point me in the direction of some documentation for kernel panic dumps in ubuntu? there seems to be evidence of some effort out there, but not a lot of "how to" papers, making me wonder if the implementation is complete
<Keybuk> damn
<Keybuk> where's cjwatson when you need him ;)
<Keybuk> I have an obscure detail of the C language to ask him about
<Robot101> Keybuk: try #d-uk? :)
<cjwatson> Keybuk: yo
<Tm_T> evand: hi, you around?
<evand> Tm_T: indeed
<Tm_T> evand: hi, should I branch whole ubiquity or what? and, should it have branch in where in launchpad?
<Tm_T> I'm bit new with this bzr and all
<emgent> heya people
<Tm_T> hmm, prolly whole ubiquity anyway
<evand> Tm_T: you shouldn't need to branch ubiquity.  The migration-assistant code, with the exception of the UI, lives in http://bazaar.launchpad.net/~evand/migration-assistant/trunk, feel free to branch off of that (https://code.launchpad.net/migration-assistant)
<Tm_T> thanks
<Tm_T> local branch or should I push it to launchpad somewhere?
<evand> please push it to LP
<Tm_T> roger
<Tm_T> evand: branch registered, I'll start pushing as soon as I get some real changes done
<Tm_T> evand: thanks
<evand> Tm_T: much appreciated
<evand> feel free to bounce any questions you have off me
<Tm_T> I will, don't worry ;)
<evand> heh
 * cody-somerville pokes evand in the tummy.
<Tm_T> I'm moving to new home currently and other family issues AND school issues going on but I'll try to get this thing rolling
 * evand doubles over, pokes cody-somerville back
<evand> Tm_T: no worries, take your time
<Tm_T> thanks sir
<kees> soren: say, in your magic irssi/screen configs, is there a way to get the [Act: ] section to not overwrite the [N:#channel-name] section?  I can't always remember a channel based on the visible topic.  :P
<Mithrandir> just have the channel name before the Act bit?
<Mithrandir> like it is by default.
<kees> Mithrandir: right, but when my Act section gets giant, it overwrites the channel name
<Mithrandir> hm, it does?  I don't think it does for me.
<Tm_T> Mithrandir: it does, when you have them enough
<Tm_T> kees: you don't remember what channels you have in where? ;)
<kees> alternatively, if Act didn't show join/part, that would work.
<kees> Tm_T: I have a few that have very similar members and topics (ubuntu-server, ubuntu-devel, e.g.)
<Tm_T> kees: same here
<Tm_T> but meh, I'm used to live with ~50 channels
<Mithrandir> kees: /set activity_hide_level ALL -PUBLIC -MSGS -DCCMSGS -HILIGHT -ACTIONS
<kees> oooooh
<Mithrandir> how do you survive with more than two channels and not having that set?
<Tm_T> well
 * cjwatson just ignores the grey ones
<kees> precisely.  ;)
 * Mithrandir likes M-a
<kees> yeah, I'd generally ignore the grey ones, but I've got too many channels now thanks to bltbee+jabber
<Lightkey> bitlbee?
<kees> Lightkey: yeah.  typo on my part.
<Tm_T> evand: ok, for gui, what I should be looking at, ubiquity/trunk/ubiquity/components ? or frontend/ ?
<cjwatson> the GUI code is in frontend
<cjwatson> you may like to read doc/README
<Tm_T> ah, thanks
<cody-somerville> elmo, ping
<Tm_T> cjwatson: FYI I'm trying to bring KDE love for migration-assistant :)
<Tm_T> so you know who to bash and blame
<cjwatson> Tm_T: been lacking for a long time, good luck
<Tm_T> thanks
<soren> kees: My prompt in irssi shows the channel name.
<kees> soren: weird.  I wonder why mine over-writes when the Act list gets long.
<soren> kees: Er... No.
<soren> kees: I mean..
<kees> soren: oh! the prompt.  right.
<soren> kees: Hang on, I'll make a screenshot.
<soren> kees: Oh, you got it :)
<kees> I turned that off because I don't like it.  :)
<soren> DDTT.
<kees> hehe.  I guess I'll turn it back on.  ;)
<munckfish> Is there a special LP tag for packages which require update to a new upstream version?
<munckfish> I see 'update' is used but doesn't seem to have a standardised meaning
<munckfish> I see 'needs-packaging' is standard for that situ
<cjwatson> munckfish: needs-packaging refers to initial packaging
<munckfish> cjwatson: yes I understand that
<cjwatson> i.e. new package needs to be packaged and introduced
<munckfish> :)
<cjwatson> ok
<cjwatson> your comment was ambiguous, so :-)
<munckfish> I was looking for the equivilent updates
<cjwatson> I can't think of one
<munckfish> cjwatson: ok that's my trade mark I guess :D
<cjwatson> there may exist one, but it's managed to escape my attention if so
<munckfish> ok np
<ScottK2> I think it's upgrade
<cjwatson> huh, ok
<munckfish> ScottK: ok I'll look at that
<ScottK2> Someone told me that.  Dunno if it's right.  I don't tend to follow such bugs very closely.
<munckfish> does it not get abused for issues which relate to upgrading to a new OS version?
<munckfish> anyway it doesn't matter too much I just want an easy way to refer to a list of such issues, 'update' will do.
<munckfish> cjwatson: I see you're leading an initiative to reduce memory usage
<munckfish> do you have any estimate how successful that's likely to be?
<munckfish> Or any target?
<ScottK2> cjwatson: You wanted ubuntu-devel revitilized, IIRC.  Are you feeling the volume is high enough the last couple of days? ;-)
<mdke> I have been thinking that ubuntu-devel was a bit quiet over the last few months too
<mdke> now it's looking great :)
<cjwatson> ScottK2: *cough*
<cjwatson> now I just need to find time to finish off the things I want to drop on it
<cjwatson> munckfish: not sure I want to give a target at this point
<ScottK2> Excellent.  People should be paying attention now.
<cjwatson> well, I definitely want to get the live CDs back under 256MB
<cjwatson> I hope we can get further but I don't have a figure
<munckfish> cjwatson: well I'm certainly interested from a PS3 point-of-view it'd be great to be able to run LiveCD on PS3, and now there's this ps3vram driver upstream
<munckfish> which unlocks the vram as swap, it's all looking quite bright and hopeful IMO
<cjwatson> munckfish: oh, that would be good
<cjwatson> you used to be able to run the live CD on PS3 at least, though it was always very slow
<munckfish> yeah it unlocks roughly 256MB - FB size for use as swap
<tormod> looking forward to seeing applets like update-manager use less than 100MB
<pochu> update-notifier you mean?
<tormod> pochu: no, that one uses only 32MB to show an icon
<pochu> there was a memory leak in update-notifier, should be fixed now AFAIK
<tormod> I don't think it's all leaks, but the problem is some developers think 32MB is reasonable.
<pochu> update-notifier is using 4.5 MB
<pochu> 00:06:35 up 14:10,
<pochu> and I've never seen it grow up
<pochu> same for update-manager
<tormod> pochu: how do you measure it?
<Amaranth> pochu: it'd probably be like 1MB if it was written in C though :P
<Amaranth> tormod: don't read RSS, it lies to you
<Amaranth> my update-notifier is actually only using 1.5MB
<pochu> tormod: "memory" column in gnome-system-monitor
<Amaranth> 17:13:41 up 1 day,  1:26
<Amaranth> pochu: why does yours use more than mine?
<soren> pochu: Quick! Say: "Because mine is bigger than yours."
<soren> It'll be fun!
 * Amaranth wonders why devhelp needs 50MB
<pochu> lol
<Amaranth> oh yeah, gecko
 * pochu waits for the webkit massive transition
<Amaranth> not sure why they use gecko, gtkhtml is more than enough for the simple html it uses
<Keybuk> gtkhtml is a bit ... crufty though
<Amaranth> Keybuk: gecko is worse
<Amaranth> gecko is always worse
<Keybuk> well, yes
<Keybuk> webkit is better
<Amaranth> but then we have two engines in main
<Amaranth> wait, we already have khtml in there
<Amaranth> so three
<tormod> ok, update-manager is "only" 62MB and update-notifier 4.9MB. tell me that is needed :)
<pochu> update-manager shouldn't be running unless you are updating something
<tormod> pochu: sure it's just an example of basic applications. now add firefox...
<Keybuk> update-notifier should only run to check, the notification should stay after it exists
<Keybuk> but that's a design flaw in GNOME :)
<sharms> update-manager for me is at 69MB, update-notifier is at 14MB for RSS
<Amaranth> sharms: RSS is pretty worthless
<sharms> Amaranth: which stat would you compare then?
<Amaranth> private rss + shared rss / number of apps sharing it would be ideal, i think
<sharms> is there a program that does that already or a pretty awk line or some common method that I am missing?
<Amaranth> otherwise you count every library for every app that uses it even if they share most of the cost
<Amaranth> gnome-system-monitor does that
<sharms> anything from console?
<Amaranth> don't think so
<Amaranth> why would people only using console care about memory usage other than "how much do I have left?" :)
<sharms> I don't really care, just for arguments sake I would like to have accurate numbers
<ion_> Substitute console for a terminal, and it would become useful. :-)
<ion_> s/for/with/
#ubuntu-devel 2008-05-29
<alex1> hi. are there some guidlines for submitting patches? I've submitted a patch to launchpad, but am not sure where to go from there...
<norsetto> alex1: is it in debdiff format?
 * norsetto wonders why he is talking to the wall
<TheMuso> lol
<TheMuso> Obviously he wasn't that concerned about the patch.
<norsetto> TheMuso: a touch-and-go patch :-)
<emgent> hello people.
<norsetto> emgent: go to bed!
 * norsetto is ...
<emgent> hahha
* mthaddon changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | Launchpad is going down in from 01:00 UTC until approx 03:00 UTC for a code update | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.
<BigPick> For anyone interested, I got around to posting up my workaround for getting boot logging fully operational until upstart's logd gets figured out.
<BigPick> http://ubuntuforums.org/showthread.php?t=811005
<lifeless> meh, stopping quagga during upgrade is one thing(correctness ftw), but -asking- - wtf.
<persia_> Well, conceivably something could break if it was stopped, such as the controlling ssh session.  On the other hand not stopping/restarting could be bad.  Which is correct?
<lifeless> persia_: the stop is mandatory
<lifeless> persia_: but it tossed up a full screen prompt saying it had to stop it or abort the install
<lifeless> persia_: on a headless unattended server upgrade.
<lifeless> persia_: so I only found out when I came back to it some hours later :(
<pwnguin> if you're not careful, you'll be a packagekit convert
<BigPick> It should have just dropped the baby on its head and asked questions later.
<persia_> lifeless: Hmm..  I can still see cases where restart now and restart later might be interesting, but either would be better than that.
<lifeless> persia_: exactly
<lifeless> anyone running a router *knows* the implications of updates
<lifeless> if they don't, they shouldn't be running a router :)
* mthaddon changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.
* mthaddon changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com
<Hobbsee_> afternoon all
<TheMuso> Hey Hobbsee_.
<Hobbsee_> TheMuso: how goes it?
<dholbach> good morning
<Hobbsee_> dholbach!
<dholbach> hi hobbsee
<pitti> Good morning
 * pitti throws a gummybear at Hobbsee_
<Hobbsee_> \o/
<pitti> yay, a new full Hardy langpack
 * Hobbsee_ throws the gummy bear to someone who will enjoy it
 * Hobbsee_ looks for chocolate instead.
 * pitti gives langpack-o-matic something to do
 * pitti tosses a Ritter Sport to Hobbsee
<StevenK> But then you'll langpack the buildds again
<StevenK> Naughty pitti
<pitti> asac will hurt me seriously if I don't do that soon
<StevenK> He's closer than I am. Listen to him
<Hobbsee_> hah
 * pitti weeps at the OO.o FTBFS in hardy-proposed
<Hobbsee_> pitti: you're surprised?
<pitti> "ERROR: error 65280 occurred"
<pitti> yeah, I hate error 65280 as well, it sucks
<pitti> calc: ^ that needs bug fix 88432, right?
<StevenK> calc didn't kill enough kittens before uploading again
* cjwatson changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pitti> argh, new LP broke python-launchpad-bugs again
 * stgraber goes try the QA Tracker bug auto-syncer ...
<stgraber> seems to update correctly
<stgraber> pitti: what bit's broken in p-l-b ?
<pitti> ValueError: Unknown error while subscribe sru-verification to  ...
<pitti> and, in the retracers
<pitti> launchpadbugs.bughelper_error.LPUrlError: "'Unknown error while loading https://bugs.launchpad.net/ubuntu/+bugs?field.tag=need-amd64-retrace'"
<stgraber> ok, so that's when trying to get a list of bugs
<thekorn> pitti, can't confirm this errors, could it be that his happened during last night's downtime?
<pitti> thekorn: the retracer ones could be, just restarted and watching
<pitti> thekorn: I'm currently tracking down the subscriber thing, I just ran it now
<pitti> thekorn: ok, I have a reproducer, and tested with bzr head; I'll file a bug
<thekorn> pitti, thanks, I'm able to reproduce it here too
<pitti> ok, bug 235681 has the details
<ubottu> Launchpad bug 235681 in python-launchpad-bugs "new LP rollout broke subscription" [Undecided,New] https://launchpad.net/bugs/235681
<pitti> argh, "launchpadbugs.bughelper_error.LPUrlError: 'login failed https://launchpad.net/bugs/122123"
<ubottu> pitti: Error: This bug is private
<pitti> ^ retracers
<thekorn> I'm working on a fix
 * pitti hugs thekorn
 * thekorn hugs pitti 
<dholbach> thekorn for the win! :)
<Hobbsee_> pitti: well, apparently API's are coming soon, so hopefully that will be a thing of the past...
<pitti> yeah, I yearn for that day :)
<pitti> hm, I cannot reproduce this login failure locally
<thekorn> launchpad API for the win!
<thekorn> pitti, something is wrong with my bzr here. I added a patch, feel free to commit it to the .main branch or I will do it later
<thekorn> pitti, nm, it now worked, pushed to .main
<erUSUL> hi; not sure if this is the correct place to raise this... i have proposed enabled today updates left me without openoffice programs. if i do a dist upgrade to force the instalation of ne oo packages what i loose are language-support-<isocode> is this problem known. should i file a bug report?
<pitti> re
<pitti> thekorn: oh, you rock!
<pitti> thekorn: oh, new p-lp-bugs needs sqlite now?
<asac> pitti: did you already kick off the language pack build?
<thekorn> pitti, yes for the FF3 cookies, as cookielib does not support them yet
<asac> thekorn: are you working on a cookies.sqlite -> cookies.txt dumper?
<pitti> asac: yes, running now; they will be placed into the standard langpacks now, too (not -gnome any more)
<pitti> asac: http://people.ubuntu.com/~kees/scripts/cookies-sql2txt
<asac> pitti: great. can you approve the xulrunner patch in the meantime?
<thekorn> asac, no, kees wrote one some time ago
<asac> oh cool
<pitti> asac: ok, so I'll release the lot then
<asac> thats handy
<asac> yeah ;)
<asac> do you still have the list?
<pitti> asac: sure,everything which is in the queue :)
<asac> oh :)
<asac> ok
<asac> that should be enough :-P
<pitti> thekorn: hm, I still get this nasty "login error" in the retracers; no idea why; anyway, I'll track that down later
<pitti> doko: bug 27184 is horribly confusing; what does that soyuz bug have to do with gcc-defaults? it's in gutsy-proposed, but I don't know what to do with it
<ubottu> Launchpad bug 27184 in ubuntu "Live-Boot fails: cannot.../bin/bash" [Medium,Fix released] https://launchpad.net/bugs/27184
<thekorn> pitti, maybe an expired cookie?
<pochu> good morning
<pitti> thekorn: it's the same cookie I used locally
<thekorn> hmm, no idea then
<pitti> asac: I assume the new ffox & friends have strict enough build deps for the new xulrunner? or do they need to be approved in order?
<asac> pitti: the idea is that depends are right
<pitti> ok, thanks
<seb128> pochu: somebody blacklisted gtk-vnc because it was not syncing correctly apparently, not sure what the issue was though
<seb128> pochu: I'm working on some SRUs right now but I'll look at that in a bit
<pitti> seb128: if it's in the 'sync failure' section, and it works now, please kill it from the blacklist
<seb128> pitti: right, I'm going to try if it's working, just finishing this sru first
<seb128> pitti: btw I sent some other updates yesterday, I'm almost done with GNOME 2.22.2 updates and pending changes
<seb128> pitti: next is to fix the gvfs issues which is going to be harder
<pitti> seb128: I'm munching through the queue full steam ATM
 * seb128 hugs pitti
<seb128> pitti: thanks for all the work you put in reviewing all those uploads
<pitti> haven't found time for the photo bits yet, I hope I can do that today
<tonfa> gug
<pitti> seb128: thanks for the updates! :)
 * seb128 hugs pitti ;-)
<tonfa> asac: ping
<asac> tonfa: ?
<tonfa> asac: I've got some problems with you nm-0.7 ppa
<pitti> asac: oh, for audacious-plugins -- you actually *want* to drop the debian/dirs? then I rejected the wrong one
<asac> tonfa: hmm
<asac> tonfa: that one is really outdated
<tonfa> can I query you ? is there a channel more appropriate ?
<tonfa> asac: hum ok
<asac> pitti: doesnt matter.
<asac> pitti: i think its just the Pre-Depends
<pitti> asac: I'm just confused which version I should accept
<asac> oh, did i bump the version again? bad me. the last version i uploaded
<pitti> ok, so .2 without debian/dirs
<tonfa> asac: but I've seen a bzr branch for 0.7 which is still updated is it unrelated ?
<pitti> I unreject it then
<asac> yes, the one without debian/dirs should be the one
<asac> tonfa: thats better ;) ... did you try it?
<tonfa> asac: how do you build from it ? (I'm a noob in debian packaging) dpkg-buildpackage -uc -B ?
<asac> tonfa: use bzr branch lp:~ubuntu-core-dev/network-manager/ubuntu.0.7
<pitti> asac: why does the hardy-proposed xulrunner speak about intrepid workarounds?
<asac> if you have that branch you can either build it using bzr bd ... or just debuild -b
<tonfa> ok
<tonfa> thanks
<asac> pitti: let me read
<pitti> http://launchpadlibrarian.net/14709759/xulrunner-1.9_1.9~rc1%2Bnobinonly-0ubuntu1~8.04.1_source.changes
<pitti>    * Drop LDFLAGS workaround now that jemalloc is no longer a static lib.
<pitti>      We still ship jemalloc as a shared lib
<pitti> such kinds of changes in stables seem a bit weird?
<pitti> it certainly didn't change between hardy final and now, or did it?
<asac> pitti: jemalloc is an upstream thing
<asac> pitti: it was broken as it shipped statically in libxul.so
<pitti> asac: ok, so that's not related to changes in intrepid
<pitti> asac: the intrepid bits confuse me a bit
<asac> pitti: let me check. iirc those dont apply for gcc 4.2
<pitti>   * Workaround multiple crashes in Intrepid (at least 3 in realpath()) caused
<pitti>      by Intrepid shipping gcc 4.3 with -D_FORTIFY_SOURCE=2 by default.
<pitti> oh, that's just -U_FORTIFY_SOURCE, it seems
<pitti> well, that should be alright, it's not on in hardy anyway
<pitti> it shouldn't be in an SRU anyway, though
<asac> pitti: i agree on that in general. i tried to keep the branches in sync for as long as possible. if you want i can remove them now.
<pitti> asac: well, don't rip it apart again just for this, since you already tested that uplaod
<tonfa> asac: checking for POLKIT... configure: error: Package requirements (polkit-dbus) were not met << I couldn't find the package providing this :/
<asac> tonfa: libpolkit-dbus-dev
<pochu> tonfa: libpolkit-dbus-dev I guess
<asac> :)
<pochu> woops
<pochu> asac: you're FAST!
<tonfa> ok thanks
<asac> ï»¿pitti: yes, intentional. midbrowser needs to be released first :) ï»¿the merge is ready, waiting for cwong or jimmy to apply two more patches i sent.
<asac> pitti: ï»¿unfortunately i lost commit rights as my new ssh keys are not yet in.
<pitti> asac: ah, ok
<StevenK> Does anyone know what settings controls the zooming icons as you launch something off the panel?
<StevenK> I want to see if I can turn it on for desktop icons
<seb128_> StevenK: what do you mean by settings? the animation? that's a gnome-panel thing
<StevenK> seb128_: It looked compiz-ish
<seb128_> it's not
<StevenK> Aww
<seb128_> StevenK: http://svn.gnome.org/viewvc/gnome-panel?view=revision&revision=10822
<StevenK> Ahh ..
 * pitti yays at the emptyness of https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=1&queue_text=
<seb128> pitti: you rock!
<seb128> pitti: does it mean we will get language pack updates too?
<pitti> seb128: building ATM
<seb128> rock on
<pitti> (in langpack-o-matic, not yet uploaded)
<pitti> oh, finished
<\sh> good morning :)
<pitti> asac: langpacks finished building; can I toss you the new German one for a local upgrade/install/functional test with the new ffox?
<tonfa> asac: ok, it works now, I still have the same issues as with the debs from the ppa
<tonfa> namely /usr/bin/nm-tool doesn't work
<tonfa> it's not a binary
<pitti> asac: http://people.ubuntu.com/~pitti/tmp/
<tonfa> # nm-tool - temporary wrapper script for .libs/nm-tool
<tonfa> # Generated by ltmain.sh - GNU libtool 1.5.26 Debian 1.5.26-1ubuntu1 (1.1220.2.493 2008/02/01 16:58:18)
<pitti> asac: the upgrade works for me (package-/Replaces: wise), and language-pack-de-base has the Mozilla stuff
<pitti> asac: but those translations don't work with my firefox (b5), so I'm interested in a test from you before I upload the lot
 * pitti hovers over the trigger, waiting for asac in suspense
<Treenaks> c
<asac> pitti: downloading ...
<pitti> do we have anyone here running hardy-proposed who has an USB mass-storage camera? (i. e. which is mounted as a drive, not talking through libgphoto)
<Mithrandir> I have it at home, at least.
<Mithrandir> (so, can't check for another five-ish hours)
<TheMuso> pitti: I can put my hands on one if that is of any help.
<pitti> DON'T TOUCH IT!!!!111!!
<pitti> TheMuso: :)
<asac> pitti: installed (i need two dpkg -i runs) ... works. remove packages again, verified that there is no cruft left; installed again and works
<TheMuso> pitti: Roger that.
<pitti> Mithrandir: if you plug it in, do you get a nautilus window with (a possibly broken) "open f-spot" button, or does it open the f-spot importer right away?
<asac> so the de package appears to be ok feature/translation wise
<pitti> Mithrandir: I tried it with a "fake" camera (DCIM/ on an usb stick), and it DTRT for me (open f-spot importer)
<pitti> asac: \o/
<pitti> TheMuso: ok, seems we can pull the trigger now :) do you want to have the honor?
<TheMuso> pitti: Any way I can help...
<pitti> TheMuso: "GIVE ME A \n!"
<TheMuso> pitti: Ok if you need a tester, sure.
<pitti> TheMuso: oh wait, seems I was confused; sorry
<ogra> pitti, what do you need tested
<pitti> TheMuso: you meant, "try camera", not "put your hand on the langpack trigger"
<ogra> ?
<TheMuso> pitti: lol
<pitti> TheMuso: I though you were joking...
<ogra> apprently my cam gets mounted fine on the desktop
<TheMuso> pitti: I meant while I don't use the camera myself, I know it uses nautilus/is a drive, so can get it for testing.
<pitti> TheMuso, ogra: so, I'm interested in what happens if you plug in a camera with mass-storage on current hardy; it should open the f-spot importer right away, and it should work; and if you open nautilus for the cam, you should get a working "open f-spot" button
<ogra> it doesnt
<Mithrandir> pitti: remind me in six hours and I can test.
<pitti> Mithrandir: thanks
<pitti> asac: ok, uploading the lot
<ogra> nautilus mounts it on the desktop, no f-spot in sight (opposite to me plugging in the SD card directly to the laptop which does open f-spot just fine)
<TheMuso> pitti: Right, I would test, but I've been informed that the non-standard USB cable is not here right now. :S
<asac> pitti: rock!
<pitti> ogra: do you get the button?
<ogra> pitti, yup, i do
<ogra> but it behaves differently on plug in
<pitti> does it work?
<ogra> hmm
<ogra> clicked the button
<ogra> no trace of f-spot
<seb128> ogra: nautilus, preferences, media, what application is selected for camera import?
<seb128> ogra: is your camera mounted, do you have a DCIM directory on it?
<ogra> yes i do
<ogra> as i said it did open the f-spot dialog before if i use the card in the builtin reader of my lappie
<ogra> f-spot is the default for photo
<seb128> and the camera mount has a DCIM directory?
<ogra> yep
<seb128> weird
<seb128> what are the hal capabilities for the camera?
<ogra> SANVOL/DCIM/100CASIO
<seb128> SANVOL is the mountpoint?
<ogra> yep
<seb128> or a dir in the mount?
<ogra> SANVOL is lying on my desktop atm
<seb128> ok
<ogra> as blockdevice
<seb128> and the capabilities?
<ogra> which one do you want to know
<ogra> device manager has a lot here
<seb128> the ones for the camera
<seb128> maybe lshal > log before and after plugin the camera
<seb128> and attach the diff to paste.ubuntu.com
<ogra> that are over 50, let me script that
<seb128> diff should be easy and efficient
<seb128> it does the filtering for you
<ogra> http://paste.ubuntu.com/15502/
 * seb128 reads gvfs code
<pitti> that's just a "block" "storage" one
<pitti> but the heuristics should be based on seeing DCIM/*.jpg
<pitti> my own fake uSB stick has info.capabilities = {'volume', 'block'} as well
<ogra> but i have a subdir there
<pitti> and f-spot opens right away
<ogra> and i''m sure my other cam has that too
<ogra> (have no access to the ther one atm though)
<seb128> pitti: well, he has SANVOL/DCIM/100CASIO
<pitti> ogra: ah, so what's the layout again? DCIM/somedir/ffoo.pic?
<ogra> what seb128 said
<ogra> 100CASIO hods the jpegs
<ogra> *holds
 * pitti changes his USB stick accordingly
<ogra> just checked, f-spot standlone works (hjust to make sure its not f-spot's fault)
<pitti> hm, just works for me
<pitti> /media/PittiUSB/DCIM/100CASIO/01 - Fruehstueck.jpg
<pitti> ogra: you are running hardy-proposed du jour?
<pitti> gvfs (0.2.4-0ubuntu1) hardy-proposed; urgency=low
<pitti>  -- Sebastien Bacher <seb128@canonical.com>  Tue, 27 May 2008 10:57:13 +0200
<pitti> in particluar, that?
<ogra_> sorry disconnect
<ogra_>  i get the button, but no f-spot if clicking it
<seb128> I can confirm that on an another box
<seb128> which is not uptodate
<seb128> upgrading gvfs now to try
<pitti> seb128: in particular, this bug would be quite independent from using the gvfs-gphoto backend, right?
<pitti> seb128: ogra's is recent, hm
<pitti> so I wonder how I can reproduce that with an USB stick
<ogra> storage.model = 'DIGITAL_CAMERA'   ... might that be something you need ?
<seb128> ogra: did you restart your session using gvfs 0.2.4?
<seb128> pitti: upgrading to gvfs 0.2.4 made it work on the box where it was not working
<ogra> hmm, i didnt restart my session since prague i think, let me try
<seb128> I still had 0.2.3 there
<pitti> aah
<seb128> there is one issue though
<ogra> it should have a reboot notification or so
<seb128> there is 2 f-spot actions listed in the nautilus properties
<seb128> one is working, the other is not, but that's an another bug
<pitti> right, I get these, too
<ogra> me reboots
<pitti> seb128: are there two .desktop files, or why are there two entries?
<pitti> seb128: so if it works for ogra as well, I think we can set the f-spot button bug to 'fix committed'?
<seb128> pitti: I think so
<pitti> bug 208467
<ubottu> Launchpad bug 208467 in nautilus "Camera Device button "Open F-spot Photo Manager" doesn't work" [High,Confirmed] https://launchpad.net/bugs/208467
<ogra> no go, sorry
<seb128> hum
<ogra> i also wonder why i dont get a nautilus window popping up
<doko> pitti: no clue about #27184
<pitti>  ogra: but it is mounted automatically?
<ogra> i have to click the icon on the desktop, shouldnt tht open a window as well ?
<ogra> yes
<seb128> ogra: strace -e execve -f -p $(pidof nautilus)
<seb128> and click on the "open f-spot" button
<ogra> http://paste.ubuntu.com/15506/
 * ogra wonders about SIGPWR
<pitti> ogra: hm, but f-spot isn't actually opening?
<seb128> ogra: does selecting the "other f-spot" in the nautilus properties make it work?
<seb128> that's what I get when using the wrong one
<pitti> I have the first one selected (if that's constant at all)
<seb128> me too
<pitti> confirmed here
<pitti> if I select the other f-spot, I don't get f-spot
<pitti> seb128, ogra: not opening a nautilus window is intended behaviour, since you are supposed to get f-spot *isntead* (not in addition)
<pitti> so seems the actual issue is just to remove that broken f-spot from the list
<seb128> I'm wondering why the heck f-spot is listed, it doesn't use the special mimetypes
<seb128> maybe the code doesn't handle well 2 desktop have the same names or something
<pitti> seb128: do you know which desktop files it looks at for assembling the list of possible applications?
<pitti> seb128: e. g. I also have gthumb installed, would be nice to get this as an option in tha tlist, too
<ogra> yeah, "the other" works :)
<seb128> pitti: just add "x-content/image-dcf" to the MimeType list in gthumb.desktop to get it listed
<pitti> ogra: yay
<seb128> pitti: we should get the new gthumb version in hardy btw, it fixes quite some crashers and issues
<pitti> seb128: right, that's still on my list
<pitti> should work on this today
<seb128> pitti: add "x-content/image-dcf", run sudo update-desktop-database and it's listed in nautilus
<seb128> I just tried
<ogra> now i get the f-spot popup as well ...
<ogra> thats a quite scary window with lots of technical crap in it though
<ogra> my mother would be scared
<ogra> cant it just say "camera detected, do you want to import ?" instead of showing me usb device paths and numbers ?
<seb128> ogra: it already does run the import, this dialog is f-spot which finds several camera available and do a poor job at asking which one you want to use
<ogra> hmm
<ogra> seems it found my builtin webcam from the laptop as device
<ogra> thinking its a PTP one
<ogra> and it found the PTP one twice
<seb128> that explains why
<pitti> seb128: nice, that works in principle (gthumb); it would need a separate .desktop for the gthumb importer, though
<ogra> http://people.ubuntu.com/~ogra/f-spot.png
<seb128> right
<ogra> the second entry is strange
<pitti> seb128: i. e. open gthumb with the right path
<seb128> that's what we did for f-spot
<pitti> I'll try to accomodate that into the gthumb update
<pitti> seb128: anyway, I still have no clue where the second f-spot comes from
<pitti> defaults.list:x-content/image-picturecd=f-spot.desktop
<seb128> pitti: I'm looking at it, it's due to f-spot.desktop (moving it away make the entry go away too) but no idea why
<pitti> seb128: coudl it be that one?
<seb128> pitti: arg
<seb128> no :-(
<seb128> pitti: in fact yes
<pitti> seb128: ok, so AFAICS this is basically the only real big bug now which we should fix for .1; gphoto gvfs could wait for .2 if it's too late, right?
<seb128> pitti: right
<seb128> pitti: fixing the double entry issue now
<seb128> stupid bug
<pitti> oh, you got it?
<seb128> do we have a bug number for it?
<seb128> pitti: yes, that's indeed the default.list which should use f-spot-import for those
<pitti> aaaaaaaaaah
<pitti> *headdesk*
<pitti> desktop-file-utils: /usr/share/applications/defaults.list
<pitti> that's a static file
<seb128> pitti: right, that's the default list
<seb128> pitti: ie, what we define as system default is several applications are installed
<pitti> bug 208467 seems to be closest, I think
<ubottu> pitti: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/208467/+text)
<pitti> I updated the bug
<norsetto> hi asac, news on my last email?
<pitti> seb128: any idea how I can reset the values in the nautilus pref dialog? I don't find it in gconftool --dump nor gconf-editor
<norsetto> asac: ok, re. gnome-mplayer and gecko-mediaplayer, let me know how you want to proceed
<asac> norsetto: mplayer is in debian main right?
<norsetto> asac: I think in non-free
<asac> norsetto: anyway, we definitly need the ITP documented in changelog i guess
<calc> pitti: probably, looking at it
<calc> pitti: the problem with the build logs is it is running in parallel mode so has to be rebuilt without, i looked at the i386 build already (rebuilt at home without parallel)
<asac> norsetto: http://www.debian.org/distrib/packages
<asac> norsetto: if i search there for mplayer in unstable/non-free i get zero results
<asac> norsetto: for unstable/main i get mplayer
<asac> norsetto: looks like it was promoted to main in unstable
<calc> pitti: not sure about the bug number you mentioned though, it doesn't seem to pertain to OOo?
<norsetto> asac: yes, its in main now
<pitti> calc: that was just a joke in response to "Error 65xxx occurred"
<calc> pitti: ah ok
<calc> pitti: the i386 build fails claiming -fexceptions needs to be enabled
 * calc isn't sure why that would be disabled
<norsetto> asac: ok, what about the gnome-mplayer itp? Its from somebody else and he already uploaded a package 1 year ago.
<calc> pitti: ah there is a bugfix in rc1 for that
<asac> norsetto: what happened to that package?
<calc> pitti: i will try to spin a new build using rc1 today, was going to anyway, but appears the i386 build failure is solved by that already
<norsetto> asac: sitting in Mentors ever since from what I could see
<pitti> seb128: ah, great
<calc> pitti: the sparc failure is most likely a buildd issue it works on debian (aiui) but hasn't built ooo in ubuntu for many months
<pitti> calc: yeah, I was mainly concerned about i386, since amd64 worked, and now dist-upgrading on hardy-proposed is broken on amd64
<calc> pitti: probably needs the language packs as well i would guess
 * calc can upload those as well
<pitti> right, but also -common etc.
<calc> oh yea, i386 builds the indep packages
<asac> norsetto: ever tried to get in contact with the initial uploader?
<asac> ITP owner?
<asac> norsetto: i have no clue whats going on ... didn't get the mail yet - not even in gmail :(
<norsetto> asac: yes, but the last one was few months ago
<norsetto> asac: perhaps I'm spammed by your ISP
<asac> norsetto: i am looking at gmail web-interface right now
<norsetto> asac: I can try to contact him again and tell him that we would like to bring it to debian, if he doesn't mind. If he minds than we forget about it
<asac> norsetto: well. we should invite him to contribute if he still cares
<pitti> seb128: gosh, I'm beginning to think that the options and selection of that photo app in nautilus is not stored in gconf; gthumb is still there, although I reset all my changes in the .desktop file, and ran update-*; very confusing
<calc> pitti: i'll try to get it updated by tonight and built on i386/amd64 to make sure the bugs are shaken out
<norsetto> asac: to say the truth, I tried to get him interested in Ubuntu but he left after a while
<seb128> pitti: did you close and reopen the properties?
 * calc is on vacation too so has to keep his wife happy ;-)
<pitti> seb128: yes, and killall nautilus, etc.
<seb128> pitti: weird
<asac> norsetto: ok. just drop a short mail to ITP that we have a package ready for upload and would like to proceed. Lets look after a week. if nothing comes up we upload
<norsetto> asac: will do
<seb128> pitti: editing the desktop, running sudo update-desktop-database and reopening the properties is enough for me to get the list updated
<pitti> seb128: gconftool --dump / > /tmp/old; change app in preferences; gconftool --dump / > /tmp/new; diff -u /tmp/old /tmp/new is empty
<seb128> pitti: look in .local/share/applications
<pitti> seb128: right, gthumb appeared that way; but it won't go away again
<pitti> aaaaah
<pitti> that's it
<seb128> pitti: that change the default handler for the mimetype
<pitti> yup, that works
 * pitti hugs seb128
<pitti> seb128: ok, now I can test the fix properly, thanks
<seb128> pitti: should I upload the desktop-file-utils change then or do you want to do it since you figured where was the bug? ;-)
<pitti> seb128: if you have it ready, please go ahead; I need to run out for a bit (see #d)
<seb128> pitti: ok, I've it ready for upload, doing that now
 * pitti hugs seb128
<pitti> seb128: you ref'ed bug 208467?
<ubottu> Launchpad bug 208467 in nautilus "Camera Device button "Open F-spot Photo Manager" doesn't work" [High,In progress] https://launchpad.net/bugs/208467
<seb128> pitti: yes
<pitti> great
<seb128> pitti: uploaded and bug updated
<norsetto> asac: email sent with you in bcc (just in case you will ever receive it ...)
<asac> norsetto: i received the gecko- mail ... what are you doing with the other mail?
<norsetto> asac: sent it already, well before the gecko one !?
<norsetto> asac: resent it again, stripped to the bare minimum
<norsetto> asac: dbts:483551 is the gecko-mediaplayer itp
<norsetto> http://bugs.debian.org/483551
<asac> norsetto: still no more mail. you sure your mail setup works :)?
<norsetto> asac: well, you got the gecko one
<asac> norsetto: yes. is it the same mail account?
<asac> norsetto: ok the ITP for gecko-mediaplayer looks good. Please document that in the changelog
<norsetto> asac: yes, same account sent to same addresses
<asac> norsetto: thats really strange.
<norsetto> asac: I just redid another forward now (as attachment)
 * norsetto <- food
<blue-frog> hi, I am at a loss as to find where the list of directory(media) that will be listed on the desktop is kept. could you help please?
<Keybuk> pitti: you don't have a bzr tree for dbus?
<seb128> blue-frog: what is the question exactly?
<seb128> blue-frog: the mounts under media and the user directory are listed
<blue-frog> the gconf key volumes_visible when enabled shows icons of mounted folder in /media on the desktop, where can I define an extra directory?
<blue-frog> so that things mounted in /extra would show as well
<seb128> you can't
<seb128> you need to do code changes to glib2.0 to do that
<blue-frog> was afraid of that, ty for the answer
<Gnontghol> I have fixed bug #235713 and made a new source package. How to upload it into Ubuntu?
<ubottu> Launchpad bug 235713 in ntfs-3g "Update NTFS-3G driver to version 1.2506 (at least)" [Undecided,In progress] https://launchpad.net/bugs/235713
<cjwatson> pitti: does bug 232175 seem like a reasonable SRU candidate to you?
<ubottu> Launchpad bug 232175 in parted "parted gets partitions wrong" [High,In progress] https://launchpad.net/bugs/232175
<Festor> Gnontghol, upload the diff.gz
<cjwatson> Gnontghol: only existing developers can actually upload to Ubuntu
<soren> cjwatson: The edd option to pass to the kernel is just "edd=on", right?
<cjwatson> Gnontghol: note that policies for maintenance of stable releases do not generally allow updating wholesale to a new upstream version
<cjwatson> soren: yes
<soren> cjwatson: Thanks.
<cjwatson> Gnontghol: the individual change that fixed that bug should be extracted and backported
<cjwatson> (yes, I know upstreams do not typically like that approach)
<cjwatson> Gnontghol: once you've extracted the relevant patch, attach it to the bug report
<Gnontghol> cjwatson: OK
<seb128> Gnontghol: https://wiki.ubuntu.com/MOTU/Contributing has some informations on what to attach to the bug, how to subscribe the sponsors, etc
<cjwatson> the exception might be if there are *no* other changes whatsoever since the version in hardy; however that doesn't seem to be the case here
<asac> cody-somerville: does xubuntu use gconf to configure preferred applications (e.g. for mailto:, ftp: etc. schemes )?
<seb128> Gnontghol: seems to be bug ##229000 btw
<pitti> Keybuk: dbus is not in bzr, no
<Keybuk> pitti: ok, I uploaded a bug fix release
<Keybuk> all the patches are in their bugzilla
<pitti> nice
<Keybuk> also, I'd like to upload the following, but can you check it first? :)
<Keybuk> http://people.ubuntu.com/~scott/dbus_1.2.1-2ubuntu3.debdiff
<seb128> Keybuk: you don't want to upload to "hardy" ;-)
<elmo> Keybuk: I thought you said upstart wasn't going to depend on the daemon?
<Keybuk> seb128: ignoring that bit ;)
<Keybuk> elmo: there's a useful bit of punctuation in the changelog called "a comma" :)
<pitti> cjwatson: yes, very much so; misdetected partitions are nasty
<pitti> Keybuk: ah, patch looks good; I guess that'll be neccessary soon enough for DeviceKit anyway :)
<Keybuk> pitti: exactly
 * pitti wants an IceCreamKit as well
<pitti> and a KittenKit
<Keybuk> the resulting debs match the layout of fedora's rpms
<Keybuk> elmo: upstart doesn't depend on the daemon, it has its own dbus server internally
<Keybuk> but userspace tools are expected to only communicate through the daemon
<Keybuk> and since many other things like DeviceKit (and thus, udev) will be increasingly expecting the daemon to be around, it makes lots of sense to start it early
<pitti> seb128: processed, merci
<Keybuk> also means we can start gdm really early ;)
<Hobbsee> pitti: you can't have a kittenkit.  we know you people like killing kittens.
<pitti> but KittenKit is for people who love kittens!
<Keybuk> libkit
<soren> kitkit?
<soren> kitkatkit?
<Keybuk> sadly, Lennart didn't like libkit, and renamed it libmu
<pitti> libmoo?
<Ng> soren: we definitely need a kitkit to take care of the proliferation of other kits ;)
<Mithrandir> and a KitFactory
<lukehasnoname> kitmu
<Keybuk> Ng: nobody's come up with a better name for them yet
<mpt> BoxOfStuff
<lukehasnoname> you must like your job, soren
<soren> lukehasnoname: What makes you say that?
<soren> I'm not disagreeing, I'm just curious :)
<lukehasnoname> paid work on Ubuntu. Canonical is a small shop with big needs, so they only get the best (pure assumption). So you must enjoy your work
<lukehasnoname> I'm here at a large subcontractor of the US govt. pinging printers
<lukehasnoname> ofcourse this is internship.
<soren> lukehasnoname: Yeah. My wife thinks I enjoy a bit too much :)
<lukehasnoname> heh
<Keybuk> "Honey, are you coming to bed?" ... "Just one more merge" ... <fx: slamming door>
<cjwatson> damn, must get rid of that camera Keybuk installed here
<pitti> Keybuk: you can't possibly have overheard me from your place!
<lukehasnoname> Is $55,000 - $60,000 USD an unreasonable estimate for out-of-college pay for an MIS/CS job? I know this is off-topic, but it seems slow right now anyway.
<pitti> pedro_: would you have some time to verify bug 228534? I tested it myself carefully, but I'm the uploader, so I need a second "thumbs up"
<ubottu> Launchpad bug 228534 in fakechroot "Does not wrap *at() functions which makes fakechroot fail badly with Hardy" [High,Fix committed] https://launchpad.net/bugs/228534
<pedro_> pitti: sure, let me check
 * pitti hugs pedro_
<pitti> pedro_: you are too fast, you just beat me with the evince verification, too
 * pedro_ hugs pitti back
 * nxvl slaps pedro_ 
<nxvl> :D
<nxvl> pedro_: finally you upload the pictures on time!
<pedro_> pitti: haha, i'm trying to do the more SRU's i can in order to have them included for .1 ;-)
<pedro_> hey nxvl!
<pitti> pedro_: right, me too; we still have a large unverified stack
<pedro_> nxvl: haha you're like the 10 person that said me that :-P
<pitti> persia: attacking that soon is highly appreciated
 * pochu slaps pedro_ too :P
<persia> pitti: tab miss?
<nxvl> it's pedro slaps party?
<pitti>  persiahm?
<pedro_> haha hate you guys
<pochu> pitti: there's a sync request for a package from Debian non-free which isn't in Ubuntu, is there any special procedure for non-free, or do I act as with any other sync requests?
<pitti> pochu: just say that it's from non-free, otherwise it's the same
<pochu> pitti: ok, thanks
<pochu> nxvl: how's been your trip for Europe?
<nxvl> pochu: i'm in Prague again, tomorrow i will fly to Madrid
<nxvl> for one night and then to peru
<lukehasnoname> o_o
<lukehasnoname> where do you hail from?
<lukehasnoname> peru?
<pitti> persia: "tab miss"?
<nxvl> i live in Peru, yes
<pitti> persia: oh; yes, indeed; sorry
<lukehasnoname> Rich people and their trans-Atlantic travel
<persia> pitti: "ï»¿(21:41:01) pitti: persia: attacking that soon is highly appreciated".  I'm guessing that was a nick-completion error, and thought it confirmed when you didn't hit me with more context.
<pitti> persia: yes, I meant "pedro"
<persia> pitti: No problem.  Just wanted to make sure I didn't owe you something :)
<sistpoty|work> may I ask an archive admin to process a few syncs?
<sistpoty|work> (as in the queue is quite big again *g*)
<pochu> sistpoty|work: better, ask an archive to process the queue ;-)
<pochu> (as in I'm waiting for some syncs too) ;)
 * pitti focuses on hardy today, archive day -> tomorrow
<sistpoty|work> pochu: actually that's what I'm trying to do. just with the wrong words probably *g*
<norsetto> nxvl: so, you survided ...
<pitti> tomorrow is hardy.1 freeze, so we better spend our time on hardy today
<nxvl> norsetto: yes
<nxvl> norsetto: i almost died
<norsetto> you got me and roak-whatever worried
<nxvl> norsetto: they wanted to send me a Coke for 4 euros
<nxvl> RoakSoax
<sistpoty|work> pitti: ah, good to know.
<nxvl> i almost get a Dehydration
<nxvl> but i walk accross almost all Rome in one day
<nxvl> :D
<norsetto> nxvl: yesterday wasn't so hot actually
<norsetto> nxvl: where did you sleep ( I mean, you slept?)
<nxvl> norsetto: david's flat
<nxvl> norsetto: a HORRIBLE B&B
<lukehasnoname> rofl
<ogra> pitti, urgh, tomorrow ?
<norsetto> nxvl: hehe
 * ogra totally missed that
<pitti> ogra: so I was told
<nxvl> it's know that some people use makeup for the photos on the web pages, but this guy is using photos from a different place
<nxvl> it was just crazy
<cjwatson> sistpoty|work: I'll do a bit of it at least
<sistpoty|work> cjwatson: thanks a lot :)
<norsetto> nxvl: at least you weren't robbed
<nxvl> norsetto: mmm depend of you mean by robbed :D
<lukehasnoname> So 8.04.1 comes out on my parents' 29th anniversery, and Intrepid comes out on my 20th birthday.
<Keybuk> cjwatson: I'm doing a rebuild test atm to see what breaks with libtool 2.2
<nxvl> norsetto: at the airport one gay just forgot to give me 5 euros back
<nxvl> norsetto: and i realize it too late to say anything
<Keybuk> hopefully only a few packages will require patching
<norsetto> nxvl: well, ok, lets say you weren't physically abused ...
<nxvl> heh
<nxvl> yes
<nxvl> at termini some "information" guy told me his office had a cheap hostal, start giving me indications, but when he said, "it's my office i can take you there" i just run
<norsetto> lol
<nxvl> to old lie for a sudaca
<norsetto> asac: there you go: bug 235675
<ubottu> Launchpad bug 235675 in firefox "firefox is not lightweight" [Undecided,New] https://launchpad.net/bugs/235675
<wgrant> Hmm, I'm sure that's a dupe.
<norsetto> wgrant: there must be a dozen like that
<cjwatson> doko: could you confirm bug 228724? it's replacing an openjdk change of yours with java-gcj-compat-dev, so I wanted to check
<ubottu> Launchpad bug 228724 in libhiglayout-java "Please sync 1.0-4 from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/228724
<wgrant> norsetto: Rightly so.
<doko> cjwatson: I think this is fine for now; we'll have to change this to default-jdk-builddep anyway in the future
<cjwatson> ok
<cjwatson> thanks
<Keybuk> wing-commander scott% xargs
<Keybuk> xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed.
<Keybuk> ...
<Keybuk> didn't we fix this party?
<seb128> Keybuk: upgrade your findutils
<cjwatson> emgent: bug 228870: could you please say something more verbose than "Debian sync to Ubuntu" in sync requests?
<ubottu> Launchpad bug 228870 in adonthell "Please sync adonthell 0.3.4.cvs.20050813-4 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/228870
<Keybuk> seb128: that's pretty much what I was trying to do ;)
<seb128> Keybuk: sudo apt-get install findutils
<Keybuk> bad apt ordering I guess
<seb128> right, that's what I was saying yesterday
<cjwatson> emgent: in particular, the Ubuntu changelog has "Fix build failure with python2.5.
<cjwatson> " which seems to have been dropped?
<seb128> something needs to Pre-Depends on the new version or Breaks the old one
<Keybuk> seb128: something about that dragged in debconf, which was what broke
<seb128> that's the issue I got yesterday, debconf was not installing
<cjwatson> it can't be Pre-Depends
<cjwatson> it's not possible
<seb128> after a sudo apt-get install findutils that was alright
<cjwatson> findutils already Pre-Depends libc6; if libc6 Pre-Depends findutils then the world will implode
<cjwatson> has to be Breaks
<seb128> ok, so libc6 needs to Breaks on the old one, not sure if apt is smart enough to handle that then
<Keybuk> pitti: did you do the sysvutils jig?
<seb128> because they get updated in the same run
<pitti> Keybuk: 'jig'?
<seb128> but I'm not sure if Breaks assure than findutils will be unpacked before other things
<cjwatson> I suppose it might need to be Conflicts although I have a bad feeling about Conflicts / Pre-Depends loops
<seb128> mvo: ^
<Keybuk> pitti: what we called sysvutils, Debian called something else
<pitti> Keybuk: I didn't upload it yet, due to the Conflicts: to the current devmapper; I didn't do that one yet, since I became aware of teh hardy.1 freeze yesterday (OMGkittens)
<cjwatson> it'd be OK until findutils' Pre-Depends needs to be bumped due to shlibdeps
<pitti> Keybuk: yes, I did that transition
<cjwatson> then upgrades from hardy would be absolutely wedged (if we used Conflicts)
<pitti> Keybuk: transitional sysvutils package, and sysvinit-utils C/R/P: sysvutils (<<) and all that
<Keybuk> I never really worked out _why_ they changed the name ;)
<Keybuk> just Debian being contrary I guess
<cjwatson> the Pre-Depends is at least theoretically necessary since findutils is Essential
 * pitti reads -changes@... c'mon Keybuk, bump dbus to ubuntu20!
<Keybuk> ubuntu20?
<Spads> Keybuk: presumably that's when dbus gets rounded corners and tag clouds, like in Web Twenty
<YokoZar> What's the current status of most of the blueprints drafted at UDS?  I'm trying to find a good way to tell launchpad to list them, but https://blueprints.edge.launchpad.net/sprints/uds-intrepid  lists none of them
<pitti> Keybuk: with the current upload pace you should get there by tonight :)
<mvo> seb128: a breaks will only deconfigure it. is it enough to upgrade from current dapper to intrepid to trigger the bug?
<Keybuk> lol
<cjwatson> mvo: deconfigure> bugger
<seb128> mvo: hardy to intrepid is enough
<seb128> mvo: the hardy xargs crash when using the intrepid libc6
<seb128> mvo: and basically libc6 is installed first and then random things try using xargs before having the intreprid findutils unpacked
 * mvo nods
<asac> norsetto: ok done
<cjwatson> oh, I know
<cjwatson> *thinks* oops, no I don't. Whoops
<cjwatson> I thought a stricter Pre-Depends in findutils would do it but I'm on crack
<StevenK> You can't use the hardy findutils with the intrepid libc6, since they have different assertions about command line length
<cjwatson> the problem is that at some point intrepid (or later)'s findutils may need some symbol in a newer libc6
<cjwatson> at which point a Conflicts will mean *neither* order satisfies
<Keybuk> gnargh
<Keybuk> annoying I can't get the new devscripts
<Keybuk> because that drags in the new Perl
<Keybuk> which drags in PAIN
<pitti> Keybuk: local rebuild? I don't think it actually needs the new perl?
<norsetto> asac: I guess you still haven't got my email?
<asac> norsetto:  *sigh* ... maybe you have another mail account? what kind of mail is it? did you send it to both email accounts from me?
 * norsetto hit the wall with his head ... repeatedly
 * asac scratches head
<asac> norsetto: maybe ftp the mbox file :) ?
<norsetto> asac: ip?
 * erUSUL already loosed oo.org in the morning now it has loosed firefox3. He knows that proposed is likely to break things but come on
<mvo> cjwatson: hm, wouldn't a simple depends: findutils (>= fixed-version) be enough? all we need is that findutils is unpacked and that should be guranteed. we have a dependency on findutils then of course in libc6
 * mvo tests this theory
<seb128> mvo: depends doesn't assure any unpack order, does it?
<cjwatson> strictly (per policy) Depends says nothing about unpack order, but you know more about how apt would treat it than I do
<mvo> they will be unpacked in the same dpkg run. that should be fine as apt will split it into unpack/configure and when xargs is required in configure all unpack was performed (that is the theory that I now need to test :)
<mvo> s/unpack/unpacking/
<cjwatson> provided xargs isn't needed in a prerm
<cjwatson> that was the problem here, I think; debconf.prerm used xargs
<mvo> meh, right
<YokoZar> seb128: if we need a specific order we have to make a chain of pre-depends right?  Eg pacakage 3 pre-depends on 2 which pre-depends on 1 etc
<seb128> YokoZar: <cjwatson> findutils already Pre-Depends libc6; if libc6 Pre-Depends findutils then the world will implode
<pitti> doko: so I should remove gcc-defaults from hardy-proposed?
<cjwatson> and findutils Pre-Depends libc6 because of the rule that Essential packages have to work when unconfigured
<pitti> doko: it says "Update release number for the binary gnat packages. LP: #227184.
<doko> pitti: no, why?
<cjwatson> in general Essential packages have to use Pre-Depends rather than Depends for things they need in order for their essential components to work
<pitti> doko: so if this is valid at all, the bug # is wrong, so I reject it
<doko> pitti: ahh, you did ask for 27184
<cjwatson> (though I don't think this is especially well-documented; it falls in the "ancient lore" category)
<pitti> doko: right, that's what the changelog says; but that bug is very confusing, having a soyuz and a gcc-defaults tasks
<doko> pitti: no, please accept it
<pitti> task
<pitti> doko: it's already in -proposed
<pitti> doko: I mean for verification and -updates
<pitti> it's sitting there for three weeks without anyone giving feedback, since it refers to the wrong bug, etc.
<smagoun> asac: Do you have a few minutes to discuss midbrowser bug #230994?
<doko> pitti: no, you did write 27184 in the first place, not 227184, therefore my confusion
<ubottu> Launchpad bug 230994 in moblin-browser "The default homepage is changed when set a valid proxy" [Medium,Triaged] https://launchpad.net/bugs/230994
<pitti> doko: ah, sorry
<asac> smagoun: is that a gconf issue?
<YokoZar> Sorry if this sounds like a silly question, but I can't seem to find any information about the blueprint lifecycle for intrepid (eg, when do they need to be drafted by?  When does the technical board meet to approve, etc.)
<smagoun> asac: I'm not sure. It's the problem in which the default homepage is the contents of midbrowserconfig.properties, i.e. "#Do NOT localize or otherwize change these values..."
<smagoun> asac: In the bug it's labeled as being a proxy problem, but we see it without configuring a proxy. I want to know whether you know what it is, and whether there's a workaround.
<asac> smagoun: i think the http proxy thing is done through system-prefs (aka gconf) ... i remember that jimmy added homepage to the set of settings synched from gconf.
<asac> smagoun: can you reproduce this right now?
<lukehasnoname> I don't know yokozar.
<smagoun> asac: I can, yes. I have xulrunner-1.9 1.9~b5+nobinonly-0ubuntu4~8.04.0mt1.ume804 and midbrowser 0.3.0b5a-7-0ubuntu1
<doko> pitti: the real fix is mentioned in https://bugs.edge.launchpad.net/soyuz/+bug/217661 which already is verified. 227184 is verified "by itself" because it did enter the archive without soyuz complaining
<ubottu> Launchpad bug 217661 in gcc-defaults "jv-scan is a dangling symlink - gcj-4.2 does not provide jv-scan-4.2" [Medium,Fix committed]
<asac> smagoun: ok, please open midbrowser when you see this bug and open about:config
<asac> is config.use_system_prefs enabled?
<pitti> doko: I don't see it's verified? we only got one comment, but at that point the package wasn't even built yet, so that can't possibly have referred to the hardy-proposed .debs
<smagoun> asac: config.use_system_prefs is enabled, yes
<smagoun> asac: btw I don't see any midbrowser gconf keys in gconf-editor
<asac> smagoun: please run
<asac>  gconftool-2 -S homepage
<asac> what do you get?
<doko> pitti: well, the symlink is gone ...
<smagoun> asac:  /desktop/hildon/htmlhomeplugin/homepage = flash_home.html
<smagoun>  /schemas/desktop/hildon/htmlhomeplugin/homepage = Schema (type: `string' list_type: '*invalid*' car_type: '*invalid*' cdr_type: '*invalid*' locale: `C')
<asac> do you have the /apps/firefox/general/homepage_url key?
<pitti> doko: I just want one written confirmation from anyone (can be you) that the actual .debs from -proposed install and work as intended
<pitti> (to guard against miscompilations, and other strange things...)
<smagoun> asac: I don't have /apps/firefox or /apps/midbrowser
<doko> pitti: done
<asac> smagoun: ok, what do you see in about:config for browser.startup.homepage ?
<mvo> cjwatson: we may get away with the versionized depends, so far it looks promising
<smagoun> asac: resource:///midbrowserconfig.properties
<pitti> doko: thanks
<asac> is that something modified or the default setting?
<asac> e.g. try right click and use Reset
<smagoun> asac: it says it's 'user set'. If I reset, it goes back to 'file:///etc/midbrowser/welcome.html'
<asac> ok
<asac> thats interesting
<asac> can you try if you ever get back to that bogus value?
<asac> e.g. by disabling proxy, and so on?
<asac> how old is your midbrowser profile?
 * calc is doing a preliminary OOo 2.4.1rc1 build on i386 to verify it fixes the build failure
<smagoun> asac: I will try. We don't use a proxy at all, it's never been enabled to my knowledge. My profile is about 12 hours old, I've trashed it a couple times trying to figure this one out.
<asac> smagoun: hmm
<ffm> Hey, who's in charge of XO devel on the XO?
<calc> negroponte?
<cjwatson> YokoZar: spec writing deadline is Thursday (next week)
<asac> smagoun: please run find /usr/lib/midbrowser/ -name \*.js | xargs grep midbrowserconfig.properties
<asac> is there anything like that in the system install?
<ffm> s/xo devel/ubuntu/
<smagoun> asac: That comes back with no results
<ffm> calc: I have an XO (i'm really deep into the OLPC project) and I'm wondering if I can help with the port.
<smagoun> asac: there is a midbrowserconfig.properties in /usr/lib/midbrowser
<calc> ffm: oh, sorry i have no idea about an ubuntu port
<asac> smagoun: yes. thats for sure. still its open why we end up using that one
<asac> smagoun: is that a language pack issue?
<asac> e.g. do you have language-pack-gnome-zh installed? did you ever run midbrowser in chinese?
<smagoun> asac: I have heard a rumor that it is a language pack issue, but I don't know any details
<smagoun> asac: I do have language-pack-gnome-zh and language-pack-gnome-zh-abse installed
<doko> asac: ping?
<asac> doko: yes?
<sistpoty|work> doko: can you take a look at bug #202869 please?
<ubottu> Launchpad bug 202869 in blas "ICAMAX/IZAMAX tests" [Undecided,New] https://launchpad.net/bugs/202869
<YokoZar> cjwatson: thank you
<ffm> Hey, is there a canonical channel?
<mvo> cjwatson: yes, I'm pretty certain the depends will be fine. apt behaves different for essential packages and ensures that they get configured immedately. this gives us in effect the ordering we want (because findutils and libc6 will be unapcked in different runs of dpkg and findutils will go first because of the dependency)
<cjwatson> ffm: what do you mean?
<ffm> cjwatson: Well, sabdfl said he'd want to support Ubuntu on the XO. So, I'f like to help.
<ffm> cjwatson: Since nobody here knows, I'm wondering where to go next.
<cjwatson> I'm not sure why that would need a Canonical channel rather than an Ubuntu channel
<cjwatson> I suspect nobody here knows because you might be the first one actively working on the XO in particular :-)
<cjwatson> there have been discussions about systems like the XO and ones with a similar form factor, but that doesn't mean there's an active development group yet
<cjwatson> ffm: to answer your previous question, there are Canonical IRC channels but they're generally on a private server; however I expect any XO development project would be done as part of Ubuntu and thus public
<smagoun> asac: do you know what the issue is with the language pack? Seems odd that it would break the homepage.
<asac> smagoun: thats what i would like to figure out
<asac> smagoun: can you uninstall those lang packs, then start midbrowser with fresh profile and see if you can still reproduce
<asac> if not, install lang packs and let me know if the issue reappears
<smagoun> asac: doing that now..
<asac> drop that info in the bug and let me know. if we know what is needed i can look closer
<mvo> seb128, cjwatson: I added the required line to bug #234345 - do you think a upload just with that change is required?
<ubottu> Launchpad bug 234345 in findutils "xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed." [Critical,Confirmed] https://launchpad.net/bugs/234345
<asac> thanks
<cjwatson> mvo: I don't see your comment in the log - but yes, I think it's worth fixing fairly soon in order to reduce confusion
<mvo> cjwatson: sorry, now my comment is added (slowness on my part)
<cjwatson> mvo: yeah, I think that's reasonable, if ugly :-)
<cjwatson> (but the least ugly solution apparently)
<cjwatson> can we have comments in control files?
<pitti> pedro_: do you have a dapper test system, too? I already tested bug 69510 (that gzip still works), but since I'm the uploader, my word is not good enough
<ubottu> Launchpad bug 69510 in gzip "gzip unlinks input before closing output, results in data loss" [Undecided,Fix committed] https://launchpad.net/bugs/69510
<pitti> cjwatson: yes, # works
<mvo> cjwatson: yeah, no question that its ugly :/ - comment in control files> no idea, I have never tried that :)
<pitti> I commented out packages in debian/control before
<mvo> nice
<mvo> cjwatson: do you want to upload it or shall I do it?
<seb128> mvo: looks good to me too
<BenC> Any archive admins awake, and can process linux-ports into intrepid, please?
<pitti> seb128: what do we do about bug 206227?
<ubottu> Launchpad bug 206227 in gtk-vnc "vinagre fails to connect" [High,Fix committed] https://launchpad.net/bugs/206227
<pitti> seb128: since the new version doesn't work worse than the previous one, we could copy it, but leave the bug open?
<ffm> Any plans to backport FF3 to dapper?
<seb128> pochu, soren: ^
<pedro_> pitti: sadly i don't, lack of space.. sorry
<seb128> pitti: I would copy, it seems to fix other issues and that would allow maybe to do an incremental update to fix this one next
<pitti> pedro_: no problem
<pochu> pitti: it fixes the other two issues?
<pochu> pitti: if so, we could remove the patch for #206227 and leave the other two
<pitti> pochu: one bug is verified, the other didn't get a comment
<pitti> pochu: we can copy it as a whole, or throw it away as a whole, not remove the patch and assume that verification results still hold for a new upload
<seb128> the patch might fix some issues but not all, I would just copy the update since nobody noticed a regression
<seb128> and try to ping upstream about the remaining case
<pochu> pitti: the one not verified is 207205 right? that's probably because apport is now disabled so people wasn't noticing it anymore...
<pitti> seb128: right
<pochu> pitti: as people reported it via apport
<cjwatson> ffm: probably only if we're forced to by death of security support for FF2 before desktop support for 6.06 ends
<cjwatson> ffm: it would be a lot of work
<pitti> pochu: right, but even if it was enabled, apport doesn't report absent crashes :)
<cjwatson> ffm: considering that there's only a year or so left to run
<pitti> pochu: for this I'm mainly interested in collecting some "still generally works for me"
<pochu> right
<cjwatson> BenC: not putting 386 in ports then?
<pochu> pitti: I'll see if I can get some more feedback about it then
<pitti> pochu: that would be good, thanks
<pochu> pitti: deadline tomorrow, right? so today for feedback...
<cjwatson> mvo: do you have the source handy?
<pitti> pochu: well, I don't think that we can't copy anything any more from tomorrow on
<pochu> right, but for 8.04.1 :)
<cjwatson> mvo: might want to commit to a branch of /~ubuntu-toolchain/ubuntu-toolchain/glibc-2.5-package
<pitti> we need to be able to fix bugs in -updates regardless of the .1 freeze
<pitti> I think the freeze mainly means "SRUs up to this date are guaranteed to make it to the .1 CDs"
<pitti> pochu: ^
<cjwatson> BenC: linux-ports accepted
<BenC> cjwatson: It should be in there
<pochu> pitti: ok. so as this is shipped in the CDs, if we make it for the deadline, great. Otherwise, let's just do it whenever we get more feedback
<cjwatson> BenC: it wasn't in debian/control
<cjwatson> nor apparently in debian/control.d/
<BenC> cjwatson: looks like I missed a config option to have it in debian/control
<BenC> cjwatson: I'll catch it on a follow-up upload, thanks
<cjwatson> ok
<mvo> cjwatson: I don't think I have commit access to this (I'm not part of ubuntu-toolchain) - but I can create a branch from it
<cjwatson> yeah, I can pull it for you
<pitti> pochu: also, since we'll build CDs from -proposed first, the deadline mainly applies to getting stuff into -proposed, not to -updates (from my POV)
<wasabi> So, there ever going to be an official ubuntu dvd?
<Pici> Whats wrong with the current dvd images?
<cjwatson> like the ones sold on shop.canonical.com, let's say
<cjwatson> not sure how they aren't official
<lukehasnoname> I'm pretty sure they have those on the site.
<cjwatson> (obviously the same as the downloadable version, it's just for when downloading a DVD-sized object is too painful)
<lukehasnoname> http://ubuntu.osuosl.org/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/
<lukehasnoname> I suppose that's an error?
<Mirv> pitti/asac: 20080527 language packs in hardy-proposed still broken unfortunately (bug #219655)
<ubottu> Launchpad bug 219655 in language-pack-gnome-fi "Firefox (xulrunner) printing problem when using Finnish (fi) translation" [Undecided,Fix committed] https://launchpad.net/bugs/219655
<cjwatson> not especially, just the sort of thing that happens when /releases is a symlink to .. for convenience
<cjwatson> we don't care because all you can do is make extra pain for yourself ;-)
<cjwatson> convenience> to cope with different people's mirror layouts
<asac> Mirv: darn. i was sure i tested that. i have to go for some errands now. will look into fixing this later. thanks
<Mirv> asac: yep, see you. rc1 in general works great, though.
<Keybuk> pitti: is dhcdbdbdbdbdbd broken in some interesting way?
<Keybuk> I'm getting dhcp, but NM never knows it
<mvo> cjwatson: changes pushed to my branch, I'm doing a test build now to see if it works or if I got lost in the interessting buildsystem
<slangasek> cjwatson: bug #234901> interesting in an "argh" sort of way, yes
<ubottu> Launchpad bug 234901 in samba "Please apply upstream patch for dpkg-buildsource" [Undecided,New] https://launchpad.net/bugs/234901
<emgent> heya
<pitti> Keybuk: in hardy? not that I know of, works fine for me
<Keybuk> pitti: maybe I just need a reboot
<bdmurray> I apologize for all the ubuntu-bugs team e-mail
<cjwatson> (defending against problems due to ChanServ going away, as per server notice)
<jpds> stdin: there you go^
<kirkland> bdmurray: jeez, mailbomb the messenger, huh?  :-)
 * Mez hands cjwatson the superman cape
<sabdfl> lukehasnoname: not so much an error as an attitude ;-)
<Keybuk> doko: broken ooo in -proposed?
<doko> Keybuk: -> calc, but I can have a look tomorrow if he's not yet back home
<pitti> Keybuk: calc is already working on it
<Keybuk> oh, right
<Keybuk> my brain knew that
<pitti> Keybuk: just takes two weeks for his test build to finish :-)
<Keybuk> but clearly is over a year out of date
<Keybuk> http://www.guardian.co.uk/technology/2008/may/22/internet.software
<Keybuk> wow, I missed that one ;)  --  nice shot out of the window too
<Amaranth> Keybuk: The view is not worth the hearing loss and pain going to that floor causes :P
<kdean06> I've got a question for anyone of the kernel packagers. In packaging the kernel for a release, does Ubuntu use vanilla sources and patch as needed, or do you guys based the kernel package off of the Debian version?
<Keybuk> Amaranth: going up isn't problem
<Keybuk> it's when going down, and the lift doesn't stop ;)
<Amaranth> Yeah, I went screaming all the way down
<Keybuk> kdean06: --> #ubuntu-kernel   (though the answer is vanilla and patch)
<Keybuk> Amaranth: you didn't visit the pool in Prague then?
<kdean06> Thanks. :)
<Amaranth> Keybuk: nope, didn't bring my shorts
<Amaranth> Keybuk: and the height scared me :P
<Keybuk> I used to be scared of heights
<Amaranth> It scared the crap out of me when I noticed the windows that high up open
<cjwatson> that photo at the top looks wrong somehow
<Keybuk> Amaranth: only one of the windows at millbank opens, and that's in the emergency exit
<cjwatson> look to the top left of Mark's laptop
<Keybuk> cjwatson: I think it's because Mark's tray happens to cut a perfect line with the window ledge
<Keybuk> so makes you think it's cut/pasted from two images
<cjwatson> ah yes, that's it
<Keybuk> (and isn't that Pete's laptop? :p)
<cjwatson> took me a minute of staring at it
<pitti> cjwatson, doko: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483399#10 is an interesting question; why did we do it that way?
<ubottu> Debian bug 483399 in initscripts "initscript: Support Cell processor spufs" [Wishlist,Open]
<cjwatson> I think it saved creating another init script, which isn't something that comes for free
<pitti> cjwatson: if it's the only thing that's special to the cell, I agree
<cjwatson> been a while though
<pitti> I just don't know which other bits we need for it
<cjwatson> there are other things, there's an SPU support package
<cjwatson> I don't actually recall for sure, doko might
<pitti> cjwatson: ok, thanks
<pitti> apt-cache search cell spu only gives the toolchain
<cjwatson> libspe2 or whatever it is
<cjwatson> I think maybe we didn't want to put an init script in a library package
<cjwatson> and elfspe2 isn't required
<doko> hmm, it was late in the release cycle, so we didn't want to touch many things. maybe libspe2 was not in main?
<cjwatson> could be
<pitti> right, they don't belong into SONAMEd lib packages
<pitti> if nothing else, it must be a separate spe-support package
<pitti> but if it would only contain the init script to mount /spu, that would be quite expensive
<pitti> doko: so if we don't have something like spu-support, I can write back with a qualified argument
<pitti> I just didn't know whether we do
<pitti> that's what you get when you forward patches from other people upstream :-)
<doko> pitti: you might want to ask arthur- how this is now solved in debian
<pitti> arthur-: ah, you are dealing with Cell stuff in Debian? any idea whether http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483399 is solved more elegantly in Debian somehow?
<pitti> doko: thanks
<ubottu> Debian bug 483399 in initscripts "initscript: Support Cell processor spufs" [Wishlist,Open]
<pitti> ArneGoetje: I mailed back and CC'ed you
<pitti> erm, arthur- ^, sorry
<Keybuk> pitti: it seems to be something wrong with dbus :)
<Keybuk> since bzr dbus-broadcast breaks too
<pitti> Keybuk: hah; I'd bitch the last uploader if I were you
<Keybuk> pitti: I haven't installed that package on here ;)
<neerfri> Hi guys ! Who should I talk to here about starting to contribute in ubuntu development ?
<geser> pitti: do you know why apache2-mpm-itk was rejected again?
<pitti> geser: yes, I commented in the SRU bug
<pitti> geser: there's a new apache in -proposed, so I guess it needs a new version number again?
<pitti> Keybuk: wrt. bug 89752, do you have any idea why the 'ac' module isn't udev-automagic-loaded already when checkroot.sh runs?
<ubottu> Launchpad bug 89752 in sysvinit "ACPI ac module not getting loaded before e2fsck runs" [High,Fix released] https://launchpad.net/bugs/89752
<zul> geser: for what its worth I dont think there wont be anymore apache uploads to -proposed for a while
<geser> pitti: as this is a no-change rebuild wouldn't it be enough to hold the apache2-mpm-itk upload until apache2 got build in -proposed so it would pick the new version during build?
<pitti> geser: ah, so it doesn't actually depend on the version of -itk itself, just on the version of the build dependencies?
<pitti> geser: in this case I can unreject it
<geser> pitti: during build the dependency on apache2.2-common gets added to apache2-mpm-itk
 * lamont glares at libnss
<lamont> valgrind id lamont on a stock hardy system --> ==21396== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 35 from 1)
<lamont> specifically, invalid read size of 4, times 3
<Keybuk> this "few minutes" is taking a long time ...: )
<Keybuk> pitti: hmm
<Keybuk> the bug number is very old
<Keybuk> old enough that it probably predates the acpi subsystem
<Keybuk> in fact, _I_ didn't find out about the acpi subsystem until last week ;)
<geser> pitti: it's really only a no-change rebuild so apache2-mpm-itk gets the right dependency on apache2.2-common with which it was build
<pochu> neerfri: hi! have a look at https://wiki.ubuntu.com/MOTU/GettingStarted
<Keybuk> pitti: ie. the module has never been automatically loaded in the past
<Keybuk> but probably is automatically loaded in hardy
<Keybuk> ironically the patch there is _WRONG_ for hardy, and right for the others :p
<pitti> Keybuk: heh, ok
<Keybuk> in fact, in intrepid, I really must look at that whole thing
<Keybuk> because we may be able to get rid of most of our manual modprobes
<Keybuk> and in fact, things like our pnp loading hack
<Ng> is pnp useful for anything in the post ISA world?
<geser> pitti: should I upload the last apache2-mpm-itk upload again or can you unreject it?
<pitti> geser: I can unreject it
<pitti> geser: done
<neerfri> pochu: thanks, I'm a programmer (mostly ruby but basically everything needed), do you think MOTU is the right starting point for me ?
<pochu> neerfri: I think so
<neerfri> pochu: OK, I'll have a look into it, thanks !
<pochu> neerfri: MOTU is mostly for packaging though
<pochu> neerfri: there's #ubuntu-motu if you have questions, and https://wiki.ubuntu.com/MOTU/TODO if you are looking for things to do ;)
<pochu> neerfri: or alternatively, ask in -motu and someone will probably tell you things you can do
<neerfri> pochu: I know, I thought there might be a work in the programming area that needs to be done, and I assume less people can handle it.
<neerfri> pochu: but if you say that's the best place to start I don't mind taking a shot at it
<mathiaz> neerfri: if you've got some ruby skills, there are some specs written up by the Server team dealing with Ruby on Rails.
<pochu> neerfri: there's also some Ubuntu specific apps (update-manager and ubiquity for example), if you prefer to code
<mathiaz> neerfri: you could help flushing out the best way to provide RoR in ubuntu
<geser> pochu: they are written in ruby? I assumed it was python.
<pochu> geser: nope, Python
<geser> neerfri: e.g. you could check if there are easy fixable bugs in the ruby packages
<neerfri> thanks, RoR should be my field, have any links who should I contact to collect my goals ?
<neerfri> ï»¿mathiaz: which specs ? where can I find them ?
<Amaranth> cjwatson, Keybuk: ChanServ is back
<mathiaz> neerfri: https://blueprints.launchpad.net/ubuntu/+spec/rubyonrails
<mathiaz> neerfri: the spec is handled by the Ubuntu Server Team - https://wiki.ubuntu.com/ServerTeam/
<neerfri> ï»¿mathiaz: thanks ! I'll have a look at that, I think it will get me started...
<mathiaz> neerfri: great! drop by #ubuntu-server if you have more questions or comments.
<Keybuk> holy crap
<Keybuk> they _really_ changed it ;)
<pitti> Keybuk: what's 'they' and 'it'?
<Keybuk> pitti: chanserv
<pitti> ah
<Keybuk> the way access is done has completely changed
<Keybuk> and it seems to have lost the "channel password" feature
<Amaranth> eep
<cody-somerville> what?
<Keybuk> it's gone all eggdrop ;)
<Keybuk> -ChanServ- You have access flags +votsriRfAF on #ubuntu-devel.
<cody-somerville> weirdness.
<pochu> anybody uses vinagre and is in hardy? :)
<Riddell> pitti: not able to MIR soprano/decibel?
<cjwatson> Ng: as Keybuk pointed out when I asked the same question at UDS, little things like PS/2 keyboards are wired up by PNP
<Keybuk> heh
<Keybuk> and AT keyboards
<Keybuk> and your serial controller
<Keybuk> and your parallel port
<Keybuk> THANK YOU MICROSOFT YOU TOOLS
<cody-somerville> Keybuk, I think I'm ready.
<asac> norsetto: cheers! i have a mail ;)
<calc> new ooo 2.4.1rc1 builds fine on i386 :) so i will be uploading it soon
<calc> need to rebuild on amd64 and do a few more minor things before upload though
 * calc bbl
<emgent> cool :P
<evand> Is there a rough standard for versioning native package hardy-proposed uploads?  For example, if I have 1.1 in hardy and 1.2 in intrepid, and I want to pull some changes from intrepid to hardy, should I version with 1.2~8.04.1 or something else entirely?
<geser> evand: how about 1.1ubuntu0.1?
<norsetto> asac: halleluia!!
<JamesG> Hi, I have a question about using valgrind which I have a feeling may be a bit beyond most of the people in the main channel. Is it appropriate to ask about it in here instead?
<norsetto> jamesG: this is not a support channel, but if there is somebody that can asnwer your question, they will most probably do it
<JamesG> Fair enough. The problem I'm running into is hopefully pretty simple. I'm doing performance testing with apache2, and I'm running it through valgrind using callgrind, but I'm not getting any output written to the log files. I've installed the debug symbols, so I'm really not sure what's going on.
<JamesG> Hm, I may have solved it
<evand> geser: that works
<evand> thanks
<kirkland> Keybuk: Hey, I just posted a debdiff that fixes an old bug, Bug #32216.  I'm looking for core-dev sponorship of the fix.
<ubottu> Launchpad bug 32216 in grub "GRUB won't boot if splash image is missing" [Low,In progress] https://launchpad.net/bugs/32216
<lool> YEAH for launchpad searches
<lool> I can find bugs way faster than with https://bugs.launchpad.net/bugs/+bugs?field.searchtext=foo for some reason
<gp> hi
<cjwatson> geser: please note my correction in bug 125837
<ubottu> Launchpad bug 125837 in neon26 "build against Heimdal Kerberos libraries" [Wishlist,Triaged] https://launchpad.net/bugs/125837
<|DuReX|> Is there a way to debug a complete system lock ?
<norsetto> Heimdal Kerberos seems almost like a sickness
<emgent> night people, i go to sleep
<norsetto> night emgent
<geser> cjwatson: thanks. Good to know. Does the order of the alternatives matter?
<|DuReX|> Starting HTTP Proxy Server...Please wait(MAX = 5 minutes)
<|DuReX|> then complete system lock :s
<kirkland> cjwatson: slangasek: evand: you guys seem to have uploaded grub relatively recently...  I have a debdiff looking for sponsor, fixes bug #32216
<ubottu> Launchpad bug 32216 in grub "GRUB won't boot if splash image is missing" [Low,In progress] https://launchpad.net/bugs/32216
<slangasek> kirkland: grub is maintained in bzr, please provide a mergeable branch we can pull from
<kirkland> slangasek: okey doke
<kirkland> slangasek: i'm fumbling around here https://edge.launchpad.net/ubuntu/+source/grub but I'm not finding a branchable bzr repo
<slangasek> kirkland: lp:~ubuntu-core-dev/grub/ubuntu
<kirkland> slangasek: cool, thanks
<cjwatson> geser: Debian's buildds always take the first; Ubuntu's buildds will take the first that's satisfiable
<kirkland> slangasek: okay, how's this?  lp:~kirkland/grub/grub.32216
<|DuReX|> mmm
<|DuReX|> When I run the httpd tool BEFORE x-windows/gnome loads, it seems to work, once I run it with gnome loaded, it crashes
<|DuReX|> but if I loaded it, shutdown it, load gnome, and then run it again, it works
<|DuReX|> wtf :X
<|DuReX|> getting errors :P
<|DuReX|> BUG: scheduling while atomic: archhttp64/7146/0x1000000001
<|DuReX|> BUG soft lockup - CPU#0 stuck for 11s! [archhttp64:7146]
<pochu> |DuReX|: please, report that at launchpad. this is not the right place
<pochu> !bugs
<ubottu> If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.launchpad.net/ubuntu  -  Bugs in/wishes for the bots can be filed at http://launchpad.net/ubuntu-bots
<|DuReX|> oki
<cjwatson> if you feel it's a kernel bug that you can help with solving (i.e. you're looking for patch review or similar), #ubuntu-kernel would be the right place then
<|DuReX|> btw, is there a way to stop that soft lockup
<|DuReX|> without resetting ?
<cjwatson> generally once you get a BUG entry in the log you might as well give up, reboot, and report it ASAP
<cjwatson> even if the kernel manages to recover its state is generally a bit screwed
<pochu> night all
<cjwatson> the second of those messages means that the special watchdog thread on the first CPU didn't manage to get scheduled for (in processor terms) a near-eternity; this usually means that the kernel has got thoroughly stuck doing something else
<cjwatson> presumably due to the first problem, but for that you want somebody who actually knows the scheduler rather than somebody who can read C code and guess at kernel semantics with a following wind ;-)
<LydianKnight> good night to all, could I make a question about the latest kernel upgrade available with ubuntu 8.04 LTS? that's... 2.6.24-17
<LydianKnight> I've been in the #ubuntu-kernel channel but nobody answered me, maybe this is a better place...
<LydianKnight>  what I would like to know is if the latest kernel update is equal to the 2.6.24.7 kernel or it's a lower version, I keep looking at both cat /proc/version and the Makefile in the /usr/src/ hierarchy, but the only number I get is EXTRAVERSION = .3... what does this mean?
<LydianKnight>  I need this piece of information to be able to make ubuntu serve as a compilation host for making a customized version of Linux, but I would like to use --with-kernel=current parameter, but I need to know if 2.6.24.7 and 2.6.24-17 are matching kernels or are different versions...
<cjwatson> it's based on 2.6.24.3
<cjwatson> (the information is in the changelog - /usr/share/doc/linux-image-2.6.24-17-generic/changelog.Debian.gz)
<cjwatson>   * Merged 2.6.24.3
<LydianKnight> oh, I see... thanks for the info :)
<cjwatson> it'll differ in various ways anyway; the Ubuntu kernel is patched to various extents
<cjwatson> distros generally don't ship completely vanilla kernels
<LydianKnight> yes, I know, the only thing I expected is to be able to compile glibc with the --with-kernel=current to not make for any kind of compatibility or workarounds related to lower versions compared to the latest ones
<LydianKnight> I'll have to compile a newer version, I'm afraid
<LydianKnight> thanks anyway :)
<cjwatson> I doubt you'll find much in the way of ABI differences between 2.6.24.3 and 2.6.24.7
<cjwatson> do you know of anything to contradict me?
<|DuReX|> https://bugs.launchpad.net/ubuntu/+bug/235889
<ubottu> Launchpad bug 235889 in ubuntu "BUG: scheduling while atomic: archhttp64/7146/0x1000000001" [Undecided,New]
<LydianKnight> no, not really, just wanted to be sure I actually could do it without relying on lower versions, because my method for producing a custom OS is using mixed instructions for the LFS & CLFS books, hence my need for the kernel piece of info
<cjwatson> --with-kernel=current only looks at the 2.6.24 part, as far as I can see
<LydianKnight> not exactly, when I pass the configure flags it checks for the kernel version currently in use, it says something like: checking for kernel version... 2.6.24.7 ok
<cjwatson> might be wrong, still digging my way through the m4 in glibc's configure.in
<cjwatson> right, but that's when you're running a vanilla 2.6.24.7 kernel
<LydianKnight> so under my current host, that's ubuntu, it will only do the search for the 2.6.24 part like you referred before?
<cjwatson> I'm checking
<cjwatson> right, I haven't actually test-run the whole thing, but from code inspection --enable-kernel=current should definitely be 2.6.24 on Ubuntu; also, while the message does say "checking for kernel header at least 2.6.24.7" (is that the one you meant?), it only actually cares about the 2.6.24 bit
<cjwatson> which makes sense because that's all that gets exposed in the LINUX_VERSION_CODE define
<cjwatson> /usr/include/linux/version.h just has:
<cjwatson> #define LINUX_VERSION_CODE 132632
<cjwatson> #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
<LydianKnight> seems very reasonable, I hope it actually works, as the testing ground it's the chroot phase, if the kernels don't match I'll get a precious: error - kernel too old
<cjwatson> and 132632 is (2<<16) + (6<<8) + (24)
<LydianKnight> so the extraversions only means subtle corrections to the source tree not effecting the overall compilation process?
<LydianKnight> well... I'll test tomorrow, let's hope for the best, thank you for your help :)
<cjwatson> right
<cjwatson> also
<cjwatson> the newest kernel that glibc actually cares about right now (at least on i386) is 2.6.17, for the fallocate syscall
<cjwatson> err, sorry, that should be 2.6.23 (hex != decimal)
<cjwatson> so 2.6.24 vs. 2.6.24.y wouldn't matter even if it could detect it
<LydianKnight> nice to hear :)
<LydianKnight> I'll try then using this kernel for chrooting
<LydianKnight> thanks ^_^
<cjwatson> Keybuk: bug 235892 will surely screw you up as well
<ubottu> Launchpad bug 235892 in dbus "dbus-1.pc has wrong include path for dbus-arch-deps.h" [Undecided,New] https://launchpad.net/bugs/235892
<Keybuk> hmm
<Keybuk> why does that break?
<Keybuk> and why doesn't Fedora get bitten by this, grr
<cjwatson> Keybuk: ${libdir}/dbus-1.0/include == /lib/dbus-1.0/include; dbus-arch-deps.h is in /usr/lib/dbus-1.0/include
<cjwatson> !=
<cjwatson> unless your question is less obvious than that :)
<Keybuk> sed -e 's@-I${libdir}@-I${prefix}/%{_lib}@' %{buildroot}/%{_lib}/pkgconfig/dbus-1.pc > %{buildroot}/%{_libdir}/pkgconfig/dbus-1.pc
<Keybuk> oh
<Keybuk> they sed it
<cjwatson> ah, I see
#ubuntu-devel 2008-05-30
<cjwatson> glad we (and Debian) aren't the only ones with that kind of horrible packaging hack ;)
<Keybuk> god
<Keybuk> now I have to figure out how to do this with cdbs
<Keybuk> I don't suppose you know off the top of your head?
<ion_> binary-post-install/foo ::
<cjwatson> sed -i in ... what ion_ said
<ion_>         sed -ire '...' debian/$(cdbs_curpkg)/foo/bar.pc
<Keybuk> doesn't work
<Keybuk> debian/tmp has been wiped by then
<cjwatson> debian/libdbus-1-dev/...
<cjwatson> it's been dh_install-ed
<Keybuk> it's not referenced by dh_install
<Keybuk> literally the whole of debian/tmp is gone, including the directory
<Keybuk> I hate CDBS
<cjwatson> $ fgrep .pc debian/libdbus-1-dev.install
<cjwatson> debian/tmp/lib/pkgconfig/dbus-1.pc usr/lib/pkgconfig
<Keybuk> yeah I removed that in an attempt to do the sed ;)
<cjwatson> put it back and do 'sed -i blah debian/libdbus-1-dev/usr/lib/pkgconfig/dbus-1.pc' in binary-post-install/libdbus-1-dev
<cjwatson> i.e. let it install and then sed in-place
<Keybuk> sed: can't read debian/libdbus-1-dev/usr/lib/pkgconfig/dbus-1.pc: No such file or directory
<Keybuk> nope
<Keybuk> still fail
 * Keybuk finds a place that works
<soren> I would just put it in install/libdbus-1-dev
<soren> When's binary-post-install?
<Keybuk> now I ended up with a .pce file ?!
<soren> o_O
<ion_> Oh, -i must be separated from -e etc.
<ion_> As in, sed -i.backup -re '...' something
<soren> Oh. Heh.. :)
<cjwatson> why bother with -e?
<cjwatson> you don't need it
<cjwatson> nor do you need -r in the example Keybuk gave
<ion_> True. I just have -e as a habit. And -r is kind of a default for me. :-)
<ion_> I didnât really take a good look at the actual sed expression.
<cjwatson> it has $ where it should have \$
<ion_> Actually, \$$ since itâs in a Makefile.
<cjwatson> oh yes
<Keybuk> ?
<cjwatson> this looks about right
<cjwatson> binary-post-install/libdbus-1-dev::
<cjwatson>         sed -i 's@-I\$${libdir}@-I$${prefix}/lib@' debian/libdbus-1-dev/usr/lib/pkgconfig/dbus-1.pc
<Keybuk> why use ${prefix} there at all?
<Keybuk> and why \$ ?
<cjwatson> \$ because sed thinks $ means end of line
<cjwatson> ${prefix} because the RH code did ;-) and seems neater
<Keybuk> install/libdbus-1-dev::
<Keybuk> 	mkdir -p debian/libdbus-1-dev/usr/lib/pkgconfig
<Keybuk> 	sed -e 's@-I\$${libdir}@-I$${prefix}/lib@' debian/tmp/lib/pkgconfig/dbus-1.pc > debian/libdbus-1-dev/usr/lib/pkgconfig/dbus-1.pc
<Keybuk> was what I went with in the end
<cjwatson> the version I had was sufficient to get openssh building, at any rate
<cjwatson> if yours produces the same .deb contents (as it looks like it should) then we ought to be fine
<Keybuk> openssh depends on dbus now? :)
<cjwatson> consolekit
<Keybuk> sshkit
<cjwatson> my Bad Idea light is going off
<ion_> At this rate, /bin/sh, init and finally the kernel will use dbus. ;-)
<Keybuk> ah, you've screwed it back in after spending a week in the same building as me? :)
<Keybuk> ion_: well, two out of three
<cjwatson> Keybuk: new filament in the bulb
<ion_> keybuk: dbus being actually useful for some of them was actually supposed to be part of the joke. :-)
<cjwatson> openssh upstream aren't too happy about the fact that dbus is GPL and openssh is rather aggressively not, which unfortunately I'd completely failed to consider
<cjwatson> so I think I need to figure out how to split that stuff out into a helper
<Keybuk> dbus is attempting to be MIT
<cjwatson> that would help
<Keybuk> it's also AFL
<cjwatson> the AFL is a bit impenetrable
<Keybuk> the MIT thing is held up by one of the companies that contributed having vanished
<Keybuk> apparently this is a major stumbling block, because they can't ok it
<Keybuk> to my mind, if they've vanished hard enough, they can't take legal action either :p
<ion_> Heh
<cjwatson> I think (on reading it) that the AFL is MIT-like enough for it not to be a legal problem for Ubuntu; it's literally 10 times the line length though
<cjwatson> (which tends to trip openssh upstream's WHATEVER meter)
<Keybuk> yes, but openssh is not on the rational side of the world
<Keybuk> it belongs in that special camp with other upstreams like glibc
<cjwatson> hmm. on re-reading, describing the AFL as MIT-like is definitely false - it requires source code provision
<cjwatson> (not that I object but it's one thing the MIT/BSD licences determinedly don't do)
<Keybuk> err
<Keybuk> not entirely true
<Keybuk> it only requires source code provision of the original work when distributing it
<Keybuk> it doesn't require source code provision _at_all_ for derivative works
<cjwatson> oh, true
<cjwatson> ugh, though, clause 9 is horrible
<cjwatson> you have to make a "reasonable effort" to obtain explicit assent to the licence
<Keybuk> yeah it's a sucky licence
<Keybuk> which is why they want to change it to MIT/X11
<cjwatson> is there anything I can quote on that, so openssh upstream don't just get fed up and close the bug? :-)
<Keybuk> on the relicense?
<cjwatson> yeah
<Keybuk> lots and lots of ML posts
<Keybuk> but the conclusion is that it's stuck still
<cjwatson> oh, it's on the website, I can quote that
<Keybuk> http://lists.freedesktop.org/archives/dbus/2008-February/009410.html
<Keybuk> the current status is that for almost all of the code, the authors have agreed to an MIT/X11 licence
<Keybuk> (including us! :p)
<cjwatson> ta
<Keybuk> random use of bzr #15
<Keybuk> import two version of a package
<Keybuk> and use bzr blame to figure out which lines haven't been changed
<cjwatson> like inverse diff?
<Keybuk> yeah
<Keybuk> patchutils doesn't have one ;)
<Keybuk> /usr/bin/same :p
<ion_> Heh
<alex1> hello. I've submitted a patch upstream (linux-kernel) for detection of macbook pro 4,1 and macbook air keyboards. It'd be nice if it made it into ubuntu sooner. Should I resubmit it for ubuntu, and if so, where?
<Keybuk> ubuntu-kernel
<alex1> is that a mailing list? what's the full address? Is there a page that details the patch format for ubuntu etc?
<Keybuk> mailing list
<Keybuk> same general method as lkml
<alex1> hm https://lists.ubuntu.com/mailman/listinfo/ubuntu-kernel says no such list
<Keybuk> grep for kernel ;)
<alex1> kernel-bugs?
<cjwatson> kernel-team
<alex1> ok. thanks guys
<alex1> new to this stuff... heh
<cjwatson> https://wiki.ubuntu.com/KernelGitGuide
<alex1> can I just resend the patch I sent upstream?
<Keybuk> probably
<alex1> done. thanks again :)
<cody-somerville> What does it mean when kill -9 won't kill an process? :P
<RAOF> It's probably in D state?  It'll be waiting in the kernel, and can't recieve signals at all.
<cody-somerville> doh, it is in D state
<cody-somerville> Stupid firefox :/
<RAOF> Yup.  Unkillable.
<cody-somerville> Weird... new applications won't start :/
<RAOF> D state makes the baby jesus cry.
<cody-somerville> Now all my applications are going into D state :/
<RAOF> Right.  Something has died horribly, and the world is ending.
<cody-somerville> Reboot is only option?
<RAOF> If you can get /sbin/shutdown to not D state, yeah :)
<kirkland> slangasek: thanks for merging ;-)
<slangasek> n/p
<cody-somerville> nooo!!! :(
 * cody-somerville just lost the Xubuntu Strategy document draft 2.
<DrVague> Good Afternoon.
<DrVague> I was sitting briefly, aghast 'n pondrance, and it became notable to one that there is no cron gui management tool, that one of course being me; if you could so explain some burdened parly to me in the form of a hairdresser in silk stockings, I'd be very delighted, or possibly intrigued to find a solution of some sort.
<DrVague> ?
<lamont> DrVague: that's probably because any gui-driven job scheduler does far more than cron, and the gui comes after the decision that cron is lacking
<DrVague> lamont: what?  you're suggest a replacement backend for cron?
<DrVague> you're kidding?
<lamont> no.  I'm saying that a gui for cron is the least of its issues
<lamont> if you expose cron to a gui-requiring user, then you also have to teach him shell scripting...
<DrVague> hurrrrr?
<DrVague> that doesnt follow for me
<lamont> well, what shell commands is he going to put in his crontab?
<DrVague> i was thinking he would just use the gui to schedule actual sh scripts to run and set the time with a mouse
<DrVague> 'add new job' ::file selection dialog:: 'time'  ::calendar::
<lamont> and then the first thing that anyone who's used an actual job scheduler on (say) a mainframe runs into is "how do I tell it to release job B when job A finishes??"  (answer? run a real job scheduler instead of cron, or hack together your own scheduler in the jobs)
<DrVague> 'save' 'cancel'
<lamont> right.  and someone has to write those shell scripts...
<lamont> and whoever writes those generally drops something to run them into /etc/cron.*
<DrVague> thats like saying the team who maintains geany should be responsible for teaching everyone perl
<lamont> my point is more that anyone who is satisfied with cron in the current world doesn't use a gui, and there is zero motivation to provide one for the developers
<DrVague> tbh, cron is used for the same, probably 2 dozen unique job scripts anywhere, a pulldown menu would cover most peoples' needs
<lamont> rather, no motivation for the developers to produce one, since the user community divides neatly into the group that doesn't see the need, and the group that would ask lots of questions of whoever wrote the gui.
<DrVague> oh, yeah, well that is def true
<lamont> which tends to discourage people from bothering with that, when there are far more interesting/significant things to work on that don't immediately become a support nightmare.
<DrVague> hrm.  i hate that community gap between devs and recreational users.
<dholbach> good morning
<lamont> morning dholbach
<DrVague> morn'
<Mithrandir> morning, lamont, Daniel
<lamont> hrm... I think that means it's about bedtime. :-)
<dholbach> hi lamont DrVague Mithrandir :)
<Mithrandir> lamont: hehe.
<lamont> well, given that the workday starts in just under 7 hours...
<lamont> hrm.. importing a 300MB, 5900 file cvs repo into a real VCS?   not so fast.
<Mithrandir> are you surprised?
<lamont> nope
<lamont> I just hope it finishes
<pitti> Good morning
<TheMuso> Morning pitti.
<Hobbsee> pitti!
<dholbach> hi pitti, TheMuso, Hobbsee
<TheMuso> Heya dholbach.
<ajmitch> hello pitti
<geser> Hi pitti, Hobbsee, TheMuso, ajmitch
<wgrant> Anybody got any idea why /dev/mapper contains all of my LVM volumes, but /dev/<VGName> doesn't?
<pitti> wgrant: /dev/vgname isn't even supposed to exist, AFAIK
<wgrant> pitti: sbuild seems to want it.
<wgrant> Well, schroot.
<slangasek> don't schroot, I'm unarmed
<pitti> Riddell: done now
<sdh> hmmm
<sdh> if you install slocate and run update-alternatives to select it as the preferred locate (over mlocate)
<sdh> then the slocate cron.daily script still doesn't fire because it has the following guard
<sdh> if [ -x /usr/bin/slocate ] && [ ! -x /usr/bin/mlocate ]
<pitti> sdh: that was done to avoid running slocate on gutsy->hardy (or dapper->hardy) upgrades
<pitti> since we don't want/can't automatically uninstall slocate completely
<sdh> pitti: interesting... why not consult alternatives and act based on that?
<sdh> i did a gutsy -> hardy upgrade, and got mails from cron like this:
<sdh> /usr/bin/updatedb.mlocate:/etc/updatedb.conf:4: unknown variable `FINDOPTIONS'
<sdh> /usr/bin/updatedb.mlocate:/etc/updatedb.conf:5: unknown variable `export'
<sdh> etc... which i assume is mlocate trying to parse slocate configuration
<pitti> noone went through that much trouble, I guess, since slocate is basically deprecated
<pitti> right, that would be it
<sdh> hmm
<pitti> sdh: can you please file a bug about it? it's worth it, at least
<sdh> pitti: i still have to work out exactly what happened ;-)
<sdh> but yeah, sure
<sdh> now i'm confused:
<sdh> % dpkg -S /etc/updatedb.conf
<sdh> mlocate: /etc/updatedb.conf
<sdh> i won't file a bug on that until i can understand what is going on
<sdh> but i note that somebody said "8.04 uses mlocate instead of slocate on desktops now" -- but it seems it is used on servers too, which imho negates the reasoning behind deprecating slocate in favour of mlocate
<sdh> (i.e. affecting user experience especially on laptops)
<pitti> sdh: both slocate and mlocate ship this configuration file
<pitti> on hindsight, we should have probably made the two conflict to each other
<sdh> sounds like a plan
<pitti> (we can still do that in -updates, at least)
<sdh> cool
<Mithrandir> sdh: may I ask why you prefer sloacte?
<Mithrandir> slocate, even
<sdh> Mithrandir: it's not that i prefer slocate - though i do think, in my case "if it's not broken, don't fix it" - it's that i dislike getting error messages from crond when the locate implementation is changed
<Mithrandir> sdh: oh, that I can agree with.
<sdh> i see that i've been using mlocate unknowingly on my hardy laptops for the last few months anyway and i have no problem with it :)
<Mithrandir> yeah, I can't see anything slocate gives us over mlocate so I was wondering why anybody would want to continue using slocate.
<sdh> sentimental reasons ;-)
<sdh> oh god the whole mlocate/slocate thing is a mess
<sdh> i have /etc/cron.daily/{mlocate,slocate,find}
<sdh> i think that's https://bugs.launchpad.net/ubuntu/+source/mlocate/+bug/197170
<ubottu> Launchpad bug 197170 in mlocate "cron daily runs updatedb twice" [Undecided,Confirmed]
 * sdh wonders why findutils has cron.daily/find doing an updatedb
<liw> sdh, so that the locate command is useful; there's been discussions of getting rid of that
<sdh> liw: i thought locate (1) was just an alternatives link into mlocate/slocate
<sdh> man i am confused now, i have mlocate installed and seem to have no locate (1)
<liw> sdh, locate is part of find, and the cron job runs regardless of what the alternatives say (which, as it happens, could be considered a bug: please file one :)
<sdh> liw: trying to get my box working first :) any chance you could dpkg -S bin/locate for me please? i appear to have lost mine
<sdh> findutils, apparently. odd that i don't have it, then.
<liw> I don't seem to have it either
<liw> hmm
<liw> this seems like a bit of a mess
<sdh> yes! b0rkage!
<sdh> did you do any mlocate/slocate manual tweaking?
<liw> no
<sdh> steve@ace:~% dpkg -l '*locate*'
<sdh> No packages found matching *locate*.
<sdh> steve@ace:~% dpkg -S bin/locate
<sdh> findutils: /usr/bin/locate
<sdh> actually ignore that, that's a gutsy box! :)
<sdh> but the problems i've been discussing are on a hardy (from gutsy) box
<sdh> right, having reinstalled findutils it definitely contains no locate(1)
<Mithrandir> > dpkg -S bin/locate
<Mithrandir> locate: /usr/bin/locate.findutils
<Mithrandir> on hardy
<sdh> *boggle*
<Mithrandir> /usr/bin/locate is handled as an alternative
<sdh> ah yes
<sdh> % update-alternatives --list locate
<sdh> /usr/bin/mlocate
<sdh> % locate
<sdh> zsh: command not found: locate
<sdh> sorry for the pasting btw, is it excessive yet?
<Mithrandir> nah, no problem when it's just a line or two at a time.
<sdh> ;>
<Mithrandir> hm, I think this machine was installed with hardy, not gutsy.
<sdh> % dpkg -L mlocate | grep 'bin.*locate'
<sdh> /usr/bin/mlocate
<sdh> /usr/bin/updatedb.mlocate
<sdh> % sudo update-alternatives --config locate
<sdh> There is only 1 program which provides locate
<sdh> (/usr/bin/mlocate). Nothing to configure.
<sdh> % locate foo
<sdh> zsh: command not found: locate
<Mithrandir> you might need to rehash
<sdh> that path is wrong
<sdh> steve@nemesis:~% rehash
<sdh> steve@nemesis:~% locate foo
<sdh> zsh: command not found: locate
<sdh> ;)
<sdh> it's the path in the alternatives
<Mithrandir> what does ls -l /etc/alternatives/locate say?
<sdh> or, hang on
<Mithrandir> lrwxrwxrwx 1 root root 16 2008-04-03 15:21 /etc/alternatives/locate -> /usr/bin/mlocate*
<Mithrandir> is what I have
<sdh> erk!
<sdh> % ls -l /etc/alternatives/*locate*
<sdh> lrwxrwxrwx 1 root root 16 2008-05-30 07:42 /etc/alternatives/locate -> /usr/bin/slocate
<Mithrandir> try update-alternatives --auto locate ?
<sdh> that seems to have fixed it
<sdh> but why is u-a telling me it points to mlocate when it points to slocate, i wonder?
<Mithrandir> it's not, it's just telling you there's nothing to configure
<sdh> good point >
<Mithrandir> I wonder if this is really an update-alternatives bug.
<sdh> i am inclined to agree
<Mithrandir> can you try installing slocate, changing the alternative to point to slocate, verify it's in manual mode pointing to slocate, then purge slocate?
<sdh> it shouldn't say "only 1 program, nothing to configure" if it is in fact handling it, badly :)
<Mithrandir> and then see what it points to?
<sdh> though i'm reluctant to keep screwing with my production boxes... sure! :)
<sdh> Mithrandir: step 2 using u-a --config locate, right?
<Mithrandir> yes
<Mithrandir> no manual hacking in /etc/alternatives. ;-)
<sdh> Using '/usr/bin/slocate' to provide 'locate'.
<sdh> lrwxrwxrwx 1 root root 16 2008-05-30 08:12 /etc/alternatives/locate -> /usr/bin/slocate
<sdh> now to purge
<soren> Mithrandir: Why not?
<sdh> % sudo update-alternatives --list locate
<sdh> /usr/bin/mlocate
<sdh> lrwxrwxrwx 1 root root 16 2008-05-30 08:13 /etc/alternatives/locate -> /usr/bin/mlocate
<sdh> seems good now
<Mithrandir> soren: in this case, because I want to see if u-a DTRT.
<soren> Mithrandir: Oh :)
<Mithrandir> sdh: hmm, ok.
<sdh> Mithrandir: strange though...
<sdh> Mithrandir: would you expect an apt-get remove, without --purge, to update alternatives?
<sdh> Mithrandir: let me try that again without purge.
<Mithrandir> sdh: sure, try.  I think it should.
<Mithrandir> since you should never be left with a dangling alternatives symlink.
<Mithrandir> but you said you were left without /usr/bin/locate at all, or was it just dangling?
<sdh> hmm that seemed to work too, odd.
<sdh> Mithrandir: hard to tell, now that i've messed about! it gave me no such f/d, but that could be either
<sdh> looks to me like it's just a gutsy/hardy upgrade quirk
<sdh> but it does feel like a can of worms, including *locate and even u-a
<Mithrandir> you don't happen to have a backup of the system you could take a look at a directory listing from?
<sdh> and i definitely think that mlocate/slocate should be mutex
<Mithrandir> yeah, it looks like it might be ordering dependent.
<sdh> Mithrandir: not in any kind of realistic timescale, afraid not
<Mithrandir> which is.. ugh.
<Mithrandir> ok.
<sdh> thanks for helping out
<Mithrandir> oh, happy to help; I still wonder how we can get it properly fixed though.
<sdh> yeah but it's at that awkward stage where i'm not sure how to reproduce the problem
<Mithrandir> it might be related to /usr/bin/locate being a proper file in gutsy.
<sdh> i'm not even 100% sure what the problem was
<sdh> i have to get to work soon... but i suppose i have time to break out a few VMs :)
<Mithrandir> if it's present on a stock install + upgrade, it should be fairly easy to see what's happening.
<sdh> i conveniently have a gutsy template vm
<sdh> right Mithrandir... i have a gutsy box ready for upgrade to hardy
<sdh> i'll install slocate then do the upgrade
<sdh> sound like a reasonable test to you?
<Mithrandir> sounds good
<sdh> just to confirm, on gutsy /usr/bin/locate is a symlink to /usr/bin/slocate
<sdh> (with slocate installed, obviously)
<Mithrandir> *nod*
<sdh> before that it was provided by findutils
<sdh> it's chugging away :)
<dolphin> how would i go about messing with [remapping] keys
<sdh> Mithrandir: well it came back with mlocate installed and slocate uninstalled, which i guess is right
<sdh> and the alternatives link points to mlocate
<sdh> ...so it all seems ok.
<Mithrandir> hmm
<Mithrandir> so it's.. something else or harder.
<pitti> seb128: WDYT about bug 182945?
<ubottu> Launchpad bug 182945 in gio-standalone "gio-standalone should be remove, gio is in glib now" [Undecided,Confirmed] https://launchpad.net/bugs/182945
<pitti> seb128: no reverse dependencies
<seb128> pitti: it should have been removed before hardy, that was a temporary package for gio before having it in glib
<pitti> seb128: merci; removing then
<seb128> thanks
<seb128> pitti: I just uploaded a new rhythmbox revision, I attached the debdiff to one of the zillion bugs it closes, is that good enough or should it be attached to all of those?
<pitti> seb128: one is enough
<dolphin> what's the best way to learn how to program?  i've taken a basic college course in C & C++, but I wanna look at real programs... even if they're mildly confusing at first
<dolphin> any suggestions?
<dolphin> what program has easy to read source code for a n00b??
<sdh> dolphin: there's a good book... let me find it
<sdh> http://www.spinellis.gr/codereading/
<dolphin> sdh:  aww, man... you gotta pay for the whole thing?!?  =-(
<sdh> dolphin: it's worth it
<liw> dolphin, pick a program in Ubuntu that interests you, then do "apt-get source foo" to get the source, and have at it; it's probably best to pick a simple command line utility to start with, they tend to be simpler
<sdh> fileutils or something is interesting
<sdh> and easy to see how code relates to runtime
<dolphin> yea, i was thinking graphical... but text is definitely a better start
<sdh> dolphin: if you want graphical then you have to get familiar with the intricacies of whatever graphical toolkit is being used, be it gtk/qt/etc
<liw> dolphin, the coreutils package might be a start, for example: cat, rm, cp, and such, although they have a lot of complexity by having to deal with all sorts of quirks in various Unix flavors
<sdh> dolphin: that is hardy, so i'd start with text
<sdh> err, s/hardy/harder/
<liw> findutils is a good choice
<dolphin> $51 isn't that bad, i guess i'll order that book to keep me from getting too bored this summer
<sdh> dolphin: it seems there is a sequel but i haven't read that
<dolphin> what is fileutils?
<sdh> dolphin: but code reading is a good book because it talks you through various idioms in real software (e.g. apache, netbsd) that means you can make the leap from understanding, say, C syntax, to being able to understand large chunks of code
<sdh> dolphin: sorry, i meant coreutils i guess
<dolphin> ahh... k
<sdh> the package with head/tail/wc etc
<dolphin> this is definitely the starting point i'm looking for... i'm tired of simple labs
<sdh> right
<sdh> so between apt-get source and that book, i'd say you could spend a lot of useful time understanding and then modifying code
<dolphin> thanks for the recommendations, ya'll!
<sdh> np
<dolphin> gonna catch some ZZZzz's for now.... lata
<dolphin> thanks again!
<liw> the nice part of going to apt-get source way is that you can easily modify code too, and try out your modifications for real
<liw> (running, say, your modified corutils in a virtual machine may give additional confidence)
<james_w> pitti: there's a packagekit discussion going on about offering to install relevant drivers when a piece of hardware is plugged in, does jockey take care of that for us?
<james_w> I mean does it get triggered by hal, or does it just scan at startup?
<pitti> james_w: not quite yet, but getting there
<pitti> james_w: ATM it just scans at session start
<james_w> so it's planned, and I can ignore trying to implement it for packagekit?
<pitti> james_w: but for 0.5 I plan to hook it into hal
<james_w> thanks
<pitti> james_w: yes, pretty much; we'll do it the other way round, we'll use PK to install the drivers from jockey :)
<james_w> heh, works for me :-)
<pitti> james_w: and jockey will go into Fedora soon, too
<pitti> so I'm not even sure whether they should do that in PK itself (one tool for one purpose, etc.)
<pitti> but *shrug*
<james_w> oh, cool. Apport as well, they're loving your code.
<james_w> pitti: <hughsie> james_w: atm, gnome packagekit has a GpkFirmware GObject that watches udev for missing firmware requests and prompts to install it if finds then in a source
<james_w> sorry to keep bothering you
<pitti> james_w: (no problem)
<pitti> james_w: that sounds nice; however, our packages don't support that ATM
<pitti> james_w: most firmware should already be present in l-r-m
<pitti> and if someone uninstalls l-r-m, he won't want the non-free firmware IMHO
<pitti> so that doesn't really work for/apply to us
<pitti> ATM, at least
<|DuReX|> https://bugs.launchpad.net/ubuntu/+bug/235889
<ubottu> Launchpad bug 235889 in linux "BUG: scheduling while atomic: archhttp64/7146/0x1000000001" [Undecided,New]
<|DuReX|> if somebody wants to look @ it :)
<james_w> pitti: sorry, last question I hope, hughsie is interested to speak to the Fedora folks that you have been in contact with to find out what their plans are, could I pass on a name to him?
<pitti> james_w: sure, that's Jon Masters (RedHat employee)
<james_w> thanks
<pitti> james_w: he and I are members of the LinuxFoundation driver backports workgroup, we work together on the tools in that context
<soren> wtf..
<soren> Are moves of packages between components logged?
<cjwatson> not really
<cjwatson> you can see that something happened
<cjwatson> e.g. https://launchpad.net/ubuntu/+source/db4.4 has both "Published" and "Superseded" for the same version (4.4.20-11)
<soren> Ah, interesting.
<cjwatson> (I think that indicates a publishing record change)
<soren> No such luck on https://edge.launchpad.net/ubuntu/+source/nagios2
<soren> in spite of https://bugs.edge.launchpad.net/ubuntu/+source/nagios2/+bug/211323
<ubottu> Launchpad bug 211323 in nagios2 "MIR for nagios" [Medium,Fix released]
<pitti> bryce: x-intel SRU upload does not have a LP # for tracking verification; can you please reupload and mention it in the changelog?
<bryce> done
<pitti> wow, that was fast :)
<bryce> pitti: yeah I realized I'd forgotten it right after uploading
<bryce> btw, the other quirk is a fix for bug 235155, which is a private bug
<ubottu> bryce: Bug 235155 on http://launchpad.net/bugs/235155 is private
<bryce> dunno if it's appropriate to list private bugs in srus or not
<pitti> bryce: bug 235643 is public
<ubottu> Launchpad bug 235643 in xserver-xorg-video-intel "Need a Pipe-A quirk for 1028:0163" [Undecided,Fix committed] https://launchpad.net/bugs/235643
<pitti> bryce: the diff itself looks fine, so if there's at least one bug to say "yes, this .deb still works for me", that's enough for SRU purposes
<pitti> bryce: the quirks themselves are probably fine
<bryce> ok great
<pitti> ogra: heh, ltsp fix-o-rama :)
<wgrant> soren: It was never promoted. https://edge.launchpad.net/ubuntu/+source/nagios2/+publishinghistory shows all publishing records ever.
<pitti> ogra_: can you please add hardy/intrepid tasks and pointers/attachments to the patches?
<ogra> pitti, ?
<ogra> oh ltsp you mean ?
<pitti> yes
<ogra> will do, one sec
<pitti> ogra: danke; please also say whether they are fixed in intrepid, etc (intrepid task status)
<soren> wgrant: Oh, that's handy. Thanks.
<wgrant> soren: Only nagios-plugins was promoted - I guess pitti misread something...
<soren> wgrant: They were handlede completely separately.
<wgrant> nagios-plugins was mentioned a comment or two before the end, and I've had this sort of thing happen once or twice before.
<pitti> wgrant: context?
<wgrant> pitti: nagios2 was never promoted, though you said you did it. Bug #211323
<ubottu> Launchpad bug 211323 in nagios2 "MIR for nagios" [Medium,Fix released] https://launchpad.net/bugs/211323
<liw> hrmph, reportsync isn't working for me
<liw> er, requestsync, rather
<soren> liw: Maybe because it's called..
<soren> oh.
<pitti> wgrant: hm; "oops"
<liw> I edit the message template. I save it. requestsync doesn't notice and signs the unedited file.
<pitti> wgrant: promoted in intrepid now; that doesn't really help hardy, of course :/
<wgrant> soren: ^^
<soren> pitti: I think the main problem (har har) is that component-mismatches is full of noise, so it's hard to notice when stuff like this pops up in there.
<pitti> soren: yeah :/
<pitti> seb128: voila, all gnome SRU stuff done
 * seb128 hugs pitti, you rock!
<liw> hm, it works with nvi, but not with my own editor... weird
<seb128> pitti: is that normal that the sru page has a language-pack-en entry without a bug number?
<liw> or at least it presented me the right file having been signed, but then it seems stuck after I press enter to actually file the bug
<liw> socket.error: (110, 'Connection timed out')
<liw> bah
 * liw goes to file bugs manually
<liw> hmm... actually, it's probably because outgoing port 25 is disabled
<liw> if requestsync would use my local MTA, it should work
<liw> and there is a way to do that, which is not documented in the manpage
<ogra> pitti, they all got hardy tasks ... i cant do much about the intrepid nomination yet as there was no ltsp upload to intrepid yet
<james_w> liw: there's a --lp option that files over http if you have python-launchpad-bugs installed.
<liw> james_w, yeah, but that's scary :)
<ogra> Pici, (and especially jwz's toy bug #199675 is a bit tricky here)
<ubottu> Launchpad bug 199675 in ltsp "configure-x.sh generates broken xorg.conf files from lts.conf" [Medium,Fix committed] https://launchpad.net/bugs/199675
<liw> james_w, I'll try it next time, though
<liw> and am putting fixing the manpage on my todo list
 * |DuReX| looks sweet to the devs -- https://bugs.launchpad.net/ubuntu/+bug/235889
<ubottu> Launchpad bug 235889 in linux "BUG: scheduling while atomic: archhttp64/7146/0x1000000001" [Undecided,New]
<pitti> ogra: I added the missing one to 224259, rest is fine; but still no patches...
<pitti> ogra: I'll read the debdiff first, and get back to you with questions if I can't figure it out
<pitti> but having patches/bazaar.lp.net URLs are a great help for fast processing
<ogra> ah well ... i was suppposed to hop on a train now ... but since i missed that anyway i can as well split the patches ...
<pitti> ogra: ah, debdiff is relatively small, so don't bother for now
<ogra> they are all separately in ltsp upstream bzr anyway
<ogra> (or will go there for the ones tat arent yet)
 * ogra hugs pitti 
<Mirv> calc: are you aware that the OOo in hardy-proposed breaks (deinstalls) a) OOo localizations b) openoffice.org-voikko extension (part of language-support-fi)
<Mirv> bug 236010 has been seemingly filed
<ubottu> Launchpad bug 236010 in openoffice.org "Broken packages with -l10n, -help and language-support" [Undecided,Confirmed] https://launchpad.net/bugs/236010
<norsetto> pitti: do the archive admins use a tool to check to which section (universe/multiverse/etc.) a package should pertain?
<cjwatson> norsetto: yes
<cjwatson> norsetto: packages are seeded, seed dependencies are expanded, discrepancies are reported in the component-mismatches.txt output
<norsetto> cjwatson: ah thanks! I'm asking because of bug 214727, I'm wondering if I should do something more (or less ...)
<ubottu> Launchpad bug 214727 in tovid "mplayer should be in universe" [Wishlist,Confirmed] https://launchpad.net/bugs/214727
<cjwatson> oh, we don't have any automatic tracking of universe vs. multiverse
<cjwatson> I'm afraid that's just done by bug reports
<cjwatson> nothing more needs to be done for that bug though
<norsetto> cjwatson: ok, thx
<Mithrandir> cjwatson: in hardy, the highlighting done when searching in man pages seems off; do you have a bug about this or should I report it?
<cjwatson> bug in whatever pager you're using
<cjwatson> I've seen that with less too, but not got round to reporting it
<Mithrandir> are you sure it's not man-db?
<cjwatson> yes
<Mithrandir> ok
<cjwatson> well, reasonably
<Mithrandir> it's less, yes.
<cjwatson> nothing relevant in man-db has changed
<Mithrandir> grep seems to highlight the right bit, so I suspect you're right.
<cjwatson> man does pass some funky options to less, so you might not see it in other documents
<cjwatson> those options last changed in 2002
<Mithrandir> heh, ok.
<emgent> morning
<bryce> http://www.oooninja.com/2008/05/openofficeorg-getting-faster-benchmark.html
<bryce> "In conclusion, OpenOffice.org is generally getting slower with each release. However, startup performance has made great improvements, the performance losses are relatively small, advances in new computer hardware are more than making up the loses, and OpenOffice.org continues to mature with new features."
 * cjwatson vomits all over http://bazaar.launchpad.net/~ubuntu-core-dev/net-retriever/ubuntu/revision/349
<cjwatson> how many impediments could there possibly have been to a simple bug-fix
<Mithrandir> cjwatson: why not just add --compare-versions to udpkg?
<cjwatson> don't feel like doing that for hardy-proposed ...
<Mithrandir> oh, good point.
<Mithrandir> I thought it was for i*
<Mithrandir> why vergt, btw?
<cjwatson> don't need a generalised vercmp there and I don't want to encourage anything else to rely on it
<cjwatson> I'll look at adding it to udpkg though
<lool> persia, mvo: update-manager-hildon needs python-vte; would one of you please confirm this is the only missing bit and add it to the u-m trunk?
<persia> lool: Looking now...
<lool> For some reason, sudo is borken in one of my envs, can't test directly
<ogra> hostname issues ?
<pitti> seb128: ah, seems I'm not the only one with this problem: bug 227994
<ubottu> Launchpad bug 227994 in gnome-screensaver "password not recognized after suspend" [High,In progress] https://launchpad.net/bugs/227994
<lool> ogra: Could be, not quite sure what the rules are; u-v-b seems to create a 127.0.1.1 ubuntu.$mydomain ubuntu in /etc/hosts and hostname reports ubuntu
<ogra> lool, try dropping ubuntu.$mydomain from that line and just keep ubuntu
<ogra> though sudo tells you if the prob is caused by gethostbyname() if its realy a resolving issue
<lool> Can one loopmount qemu qcow2 files?
 * lool lunch &
<ogra> pitti, i saw some complaints about keymaps not being properly re-initialized after resume on the ubuntu-users ML since we switched to pm-utils ... that might be related
<pitti> ogra: I tried both en and de layouts, that's not it
<ogra> even though its weird that they say "leave message" works as expected
<pitti> ogra: the same happens with src/test-passwd
<pitti> and I verified in gdb that the password is correct
<pitti> currently gdb'ing it
<ogra> weird
<pitti> ogra: you don't need a password for that
<pitti> ogra: 'login as another user' works, too (but that's gdm again)
<ogra> right, not gss
<pitti> ogra: so the g-s lock dialog works for you?
<ogra> let me try
<pitti> gnome-screensaver-command -l
<pitti> or ctrl+alt+l or so
<pitti> May 30 13:30:58 donald gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): conversation failed
<pitti> May 30 13:30:58 donald gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): auth could not identify password for [martin]
<pitti> is what I get
<ogra> yes, works fine after suspend
<pitti> ogra: ok, thanks for trying
<ogra> do you have an upgraded system ?
<ogra> this laptop was a new hardy install
<pitti> ogra: both my desktop and my laptop are fresh hardy installs, and it happens for both
<ogra> meh
<ogra> oh
<ogra> my auth log looks itrestingly different
<ogra> May 30 13:39:31 osiris gnome-screensaver-dialog: gkr-pam: unlocked 'login' keyring
<ogra> smells like a communication error between gss and gkr
<pitti> hm, it doesn't use unix_chkpwd??
<pitti> how the heck is it supposed to be able to verify my password then?
<pitti> it calls PAM directly, as my user
<pitti> without shadow privileges
<pitti> ogra: is /usr/bin/gnome-screensaver root:root 0755 for you?
<seb128> pitti: does it happen every time for you?
<pitti> seb128: yes, it has never worked in hardy
<pitti> first thing I do after login is 'killall gnome-screensaver'
<seb128> urg
<seb128> we would have received lot of complain if that was happening to everybody for sure
<seb128> do you configure something special in your boxes?
<pitti> right, that's why I didn't treat it as OMGPONIES
<pitti> seb128: not that I know of (pam-wise)
<pitti> still debugging
<seb128> pitti: I can get debug informations on my working systems if you need something to compare
<pitti> /* #undef PASSWD_HELPER_PROGRAM */
<pitti> ^ in my config.h
<pitti> unix_chkpwd can be passed as a configure argument
<ogra> ogra@osiris:~/Devel/packages/ltsp-5.0.40~bzr20080212$ ls -l /usr/bin/gnome-screensaver
<ogra> -rwxr-xr-x 1 root root 134532 2008-04-09 17:06 /usr/bin/gnome-screensaver
<pitti> but isn't
<mantiena> hello all
<pitti> seb128: I'm still stunned how g-s-s is supposed to verify passwords without using unix_chkpwd and without being sgid shadow
<pitti> seb128: do you happen to have a built gnome-screensaver tree? does src/test-passwd work for you?
<seb128> pitti: trying
<mantiena> cjwatson: I have some questions about ubiquity's netboot support - do you have some time to answer ?
<mantiena> I found, that blueprintï»¿ï»¿ https://wiki.ubuntu.com/Ubiquity/Automation is implemented already
<pitti> seb128: ah, nevermind; it does run execve("/sbin/unix_chkpwd", ["/sbin/unix_chkpwd", "martin", "nullok"], [/* 0 vars */])
<cjwatson> mantiena: depends on the questions, I'm trying to meet 8.04.1 deadlines at the moment
<seb128> pitti: the test-passwd thing works fine here
<mantiena> cjwatson: So, I'm asking: there is one important (for me) sentence in that blueprint: "To support netbooted installations, we will ensure that the existing casper support for netbooting works properly (it is believed to have some bugs)..."
<pitti> seb128: ok, thanks; mind to try something else?
<cjwatson> mantiena: I'm afraid I'm not up to date on that; I suggest asking evand
<seb128> pitti: I'm happy to debug it with you
<pitti> seb128: echo 'yourpasswd' | /sbin/unix_chkpwd yourlogin nullok
<cjwatson> he was responsible for that specification
<pitti> seb128: while watchign tail -f /var/log/auth.log
<pitti> May 30 13:54:15 donald unix_chkpwd[29021]: check pass; user unknown
<pitti> May 30 13:54:15 donald unix_chkpwd[29021]: password check failed for user (martin)
<pitti> so, unix_chkpwd itself seems to be broken
<mantiena> cjwatson: ok, so, you don't know if casper and ubiquity would work if booting from network (on computers without CD/DVD drivers) ?
<pitti> aaargh *headdesk*
<pitti> -rw-r----- 1 root root 1470 2008-05-30 13:55 /etc/shadow
<seb128> pitti: same error
<cjwatson> mantiena: not without trying it, no
<mvo> lool: added to trunk and uploaded to intrepid already :)
<seb128> pitti: it's root shadow 640 on my install
<pitti> right, as it should be
<seb128> pitti: any idea why it's different for you?
<elmo> hmm
<mantiena> cjwatson: thanks for info, I will talk with evand
<mantiena> evand: hi, are you online ?
<pitti> seb128: yes, indeed I have; I blame my 'restore my configuration from bzr after install' script, which probably doesn't restore the permissions
<pitti> seb128: bzr doesn't save group membership
<pitti> seb128: so, sorry for the noise
<seb128> ah ok
<seb128> iz pitti bug
<seb128> ;-)
<pitti> works fine now
<persia> mvo: The other thing I found looking it over is that it needs the versioned dependency on update-manager-core to get the more flexible DistUpgrader
<elmo> pitti: thanks very much, that just helped me fix one of the admin pcs
<pitti> elmo: hah, /etc in bzr, too? :-)
<pitti> in fact it's not due to bzr, it's due to my 'postinst-setup' script which only adds the real users from teh backup to shadow, but keeps the system bits
<elmo> pitti: no, someone messed up group ownership when they were r00ting it
<charliecb> ï»¿i want to download my photos from an canon ixus  80 with nautilus. since gnome 2.22, there should be an option for gphoto2. enter in nautilus gphoto2:// . but that doesn't work. i can import photos, but i can't use nautilus to see all photos from the camera. see http://library.gnome.org/misc/release-notes/2.22/index.html.de. is gphoto2 not compiled into nautilus?
<pitti> dpkg: ../../src/packages.c:265: process_queue: Assertion `!queue.length' failed.
<pitti> Aborted (core dumped)
<pitti> yay intrepid's dpkg
<seb128> charliecb: it's not compiled in the hardy gvfs no
<cjwatson> pitti: test case?
<cjwatson> though, er, maybe after 8.04.1 deadline
<charliecb> seb128: do you know why not?
<pitti> cjwatson: trying to construct one
<seb128> charliecb: the current applications doesn't understand the gphoto uris, so you can't open an image by clicking on it and the gvfs mount lock the access to the device so you can't use an another application to download those
<charliecb> seb128: ok. thx
<seb128> you are welcome
<pitti> cjwatson: ah, seems to happen on "dpkg: too many errors, stopping"
<ogra> Amaranth, hey
<Amaranth> hey
<pitti> cjwatson: filed as bug 236047; I try it in sid now, too
<ubottu> Launchpad bug 236047 in dpkg "dpkg: ../../src/packages.c:265: process_queue: Assertion `!queue.length' failed." [Undecided,New] https://launchpad.net/bugs/236047
<pitti> yup, it's in sid, too
<ogra> Amaranth, do you mind me taking over packaging etc for wilow during intrepid or do you prefer to be my upload bitch ? i added a branch to the upstream project which already carries a good bunch of changes
<cjwatson> pitti: that's a relief
<cjwatson> of sorts
<Amaranth> ogra: go ahead, do whatever you want with it
<pitti> cjwatson: ah, debian bug 483655; I'll send more information to that
<ubottu> Debian bug 483655 in dpkg "../../packages.c:265: process_queue: Assertion 'queue.length' failed." [Important,Open] http://bugs.debian.org/483655
<ogra> Amaranth, thanks, i thought so, just didnt want to just steal it away without asking :)
<lool> persia: Hmm not sure but did you push update-manager to ppa?  I don't see it
<Riddell> pitti, doko: whole bunch more MIRs for you there
<pitti> Riddell: yeah, just saw them
<pitti> calc: is bug 220911 actually a problem in writer2latex? If not, we should remove the milestone from the task and set it to invalid
<ubottu> Launchpad bug 220911 in openoffice.org "Maintainer scripts of openoffice.org-writer2latex fail" [High,In progress] https://launchpad.net/bugs/220911
<pitti> mvo: while I agree that bug 231805 is primarily a j2se bug, u-m should handle this a little more gracefully ideally?
<ubottu> Launchpad bug 231805 in j2se1.4-i586 "error reported during Hardy Heron update" [High,New] https://launchpad.net/bugs/231805
<pitti> mvo: oh, it doesn't actually crash u-m, it just reports the error
<pitti> so that's fine
<pitti> doko, mvo: bug 225927 is milestoned for .1, but has no assignee; is it important enough to deserve the 8.04.1 milestone?
<ubottu> Launchpad bug 225927 in python-central "python2.4-minimal fails on removal ;  chillispot upgrade fails to upgrade" [High,New] https://launchpad.net/bugs/225927
<pitti> seb128: do you think bug 206583 is really 8.04.1-worthy? I can reproduce it, but tricky to debug
<ubottu> Launchpad bug 206583 in gnome-system-monitor "System Monitor crashes when changing nice value of process" [Medium,Confirmed] https://launchpad.net/bugs/206583
<pitti> but it doesn't seem terribly important to me
<seb128> pitti: no, I just milestoned it as a target of opportunity in case there was an easy fix available, slangasek did open the hardy task
<pitti> seb128: so you're ok with unmilestoning?
<seb128> pitti: yes
<seb128> pitti: or delay to 8.04.2
<cpufreak> win 27
<cpufreak> meh sorry :)
<seb128> pitti: we should get a 8.04.2 milestone ;-)
<pitti> cjwatson: ^ can you create one?
<cjwatson> pitti: done, with a rather notional target date
<seb128> cjwatson: thanks
<pitti> cjwatson: thanks
<pitti> seb128: bug 196277 sucks, though
<ubottu> Launchpad bug 196277 in xserver-xorg-input-keyboard "[hardy] keyboard layout switching shortcut doesn't work after reboot" [High,Confirmed] https://launchpad.net/bugs/196277
 * pitti grabs two more milestoned bugs and sits in a corner for hacking
 * Hobbsee throws pitti a gummy bear so he hacks faster.
<pitti> yummy
<seb128> pitti: right, iz xorg bog though
<seb128> pitti: which ones are you working on?
<pitti> seb128: iz task inflation, too
<pitti> bug 229000
<ubottu> Launchpad bug 229000 in ntfs-3g "random file corruptions in ntfs-3g < 1.2506" [Undecided,In progress] https://launchpad.net/bugs/229000
<pitti> and bug 206790
<ubottu> Launchpad bug 206790 in dpkg "Deprecated call in dpkg-dev to init method in Dpkg::Changelog::Entry" [Medium,In progress] https://launchpad.net/bugs/206790
<seb128> pitti: I've decided that I hate bug tasks now
<pitti> seb128: lol
<Hobbsee> haha
<pitti> seb128: s/ task//, certainly? :-)
<Hobbsee> seb128: i'm sure you can write a greasemonkey script to rename them.
<seb128> thanks to people who open bugs having a zillion tasks
<seb128> ie, "not using correct ubuntu maintainer information" or "need rebuild for perl transition"
<ogra> yeah
<seb128> you get a mail every time somebody add a comment or change a task
<seb128> when your task as already been fixed and you don't care about the bug
<Hobbsee> seb128: you can actually get out of those.  you can change the project to 'ubuntu', rather than the package that you're getting mail for.
<seb128> Hobbsee: I did that but that's an ugly workaround
<seb128> Hobbsee: and can have several tasks on "ubuntu"?
<Hobbsee> seb128: i know.  there isn't a good solution, short of not filing bugs that way
<Hobbsee> seb128: unsure
 * ogra wonders why his bugs have suddenly a ton of "also notified" entries
<ogra> makes me feel observed somehow
<seb128> pitti: no, I've nothing against bugs, I don't get flooded by other people bugs activity ;-)
<cjwatson> yes, people just shouldn't file bugs that way with a zillion different tasks
<cjwatson> tasks are for multiple bits of the same problem
<seb128> maybe a motu workflow issue
<cjwatson> the way these are being used are different problems that happen to have basically identical fixes
<seb128> dholbach: ^
<cjwatson> I should have objected to this use when I first saw it, rather than now that it seems to be entrenched among a small subset of people
<pitti> I still prefer them for things like "these 5 packages need a rebuild for libfoo transition"
<pitti> it makes it so much easier to see the status
<geser> I need some help with the perl 5.10 transition, I found a build-dependency loop :( how to proceed?
<Amaranth> geser: ?
<geser> libmodule-build-perl build-depends on libextutils-cbuilder-perl which build-depends on libmodule-build-perl
<geser> and neither can currently be installed
<Amaranth> fun
<pitti> cr3, cjwatson: any idea how to reproduce bug 206790? alien works fine for me, and the example POD in /usr/share/perl5/Dpkg/Changelog/Debian.pm is absolutely, totally useless and wrong
<ubottu> Launchpad bug 206790 in dpkg "Deprecated call in dpkg-dev to init method in Dpkg::Changelog::Entry" [Medium,In progress] https://launchpad.net/bugs/206790
<cr3> pitti: err, didn't soren write patch that code?
<cr3> pitti: I initially encountered that problem while attempting to install the lsb suite, need a url?
<cjwatson> cr3: the bug log might help resolve confusion here
<pitti> cr3: anything that demonstrates the problem; I can't reproduce it
<pitti> and for a hardy SRU for dpkg I insist on something I can test :)
<cjwatson> pitti: joeyh's comment implied that asking it to parse a changelog that had old-format entries at the end would do it
<cjwatson> off the top of my head, man-db is one such
<pitti> right, finding that shouldn't be a problem
<pitti> so now I just need to find documentation how to actually use that beast
<pitti> /usr/share/perl5/Dpkg/Changelog/Debian.pm is from dpkg-dev, while the POD in that file uses use Parse::DebianChangelog, which is libparse-debianchangelog-perl
<cjwatson> aha
<pitti> (separate implementation)
<cjwatson> pitti: unpack man-db
<cjwatson> pitti: run 'dpkg-parsechangelog --all'
<pitti> aaaaah
<pitti> cjwatson: thanks a lot
<cr3> pitti: I'll append the steps to reproduce to the bug report, one moment...
<pitti> cr3: I did that already now; thanks
<dholbach> seb128: no, there's no MOTU process that says something like that
<cr3> pitti: excellent, need anything else from me then?
<pitti> cr3: that's fine, no
<seb128> dholbach: ok, some have just decided that's a good idea apparently then and decided to use it to organize transitions, etc
<dholbach> *nod*
<pitti> wow, http://ntfs-3g.org/pjd-fstest.html is really nice for testing patches to packages like ntfs-3g
<evand> nice!
<cjwatson> nice
<pitti> that's exactly what I was looking for for testing fakechroot
<lool> I wonder whether it would have catched the unionfs regression with hard links, probably
<ogra> i bet it would expose 20 new bugs in unionfs ... DONT RUN IT ON THERE, OMG ! :)
<geser> pitti: who do I need to ask to get libextutils-cbuilder-perl and libmodule-build-perl manually rebuild on the buildds? infinity?
<sistpoty|work> seb128: well, I did use tasks for a transition once (though that sucked, since LP rendered it very slowly). what's your problem with that?
<pitti> geser: infinity or lamont, yes; what's up with them? a no-change upload won't help?
<geser> libmodule-build-perl build-depends on libextutils-cbuilder-perl which build-depends on libmodule-build-perl
<geser> pitti: ^^
<lamont> geser: you ask infinity
<lamont> pitti: no clue...
 * norsetto now understands why infinity nick is infinity
<lamont> norsetto: to be fair, his work day starts in just over an hour..
<emgent> tseliot: o/
<tseliot> ï»¿emgent: hey
<lamont> geser: if there isn't a way to do multiple uploads and have it happy (please wait for all 7 architectures if you do that...), then you're stuck asking the ubuntu OSA (infinity) to "halp make better"
<martii> hi guys I got no answer on #ubuntu
<martii> so I hope I can ask one question
<martii> can I?
<norsetto> !ask | martii
<ubottu> martii: Please don't ask to ask a question, ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely answer. :-)
<lamont> martii: that was a very simple question, and yes, you could. :-)
<martii> http://library.gnome.org/users/user-guide/2.22/user-guide.html#nautilus-accessnetwork
<martii> hardy uses 2.22 right?
<martii> so where is NFS gone?
<lamont> did you install nfs?
<martii> as well nautilus doesn't recognize nfs://
<geser> lamont: thanks, will try that first
<martii> lamont: installed libs for nfs-client
<martii> lamont: don't tell me I need to become nfs server to access nfs shares :)
<lamont> martii: well, that expends my knowledge on the subject. :-(
<seb128> sistpoty|work: my issue is that your mail every people who are watching a component which has a task open there
<lamont> martii: you need to have /sbin/mount.nfs on the system
<lamont> which should be in nfs-common, iirc
<martii> lamont: I installed nfs-common and portmap
<seb128> sistpoty|work: which means if I fix the task I'm watching I get zillions of bugs about things I've no interest in every time somebody touch one of the zillion other tasks I don't care about
<martii> lamont: all according to docs
<seb128> zillion mails rather
<martii> which mount.nfs
<martii> /sbin/mount.nfs
<martii> lamont: so it's there
<sistpoty|work> seb128: ah, I see. I guess it shouldn't be called "task" then *g* (and maybe mails shouldn't be sent to people subscribed via packages, which are already listed fixed in a task, though I'm not entirely sure about that)
<cjwatson> sistpoty|work: tasks should be used when it's a single problem that just needs coordinated fixes in multiple places
<seb128> sistpoty|work: you might want get comments about a bug you fixed in case the fix is not correct, etc
<cjwatson> sistpoty|work: they aren't for when you've seen the same bug in 20 different packages
<cjwatson> (IMO anyway)
<seb128> sistpoty|work: there is no interest to list tasks in the transitions scenario, it's easier to file bugs and tag those
<lamont> cjwatson++
<cjwatson> to put it a different way: if the fixes required would be independent, they should be separate bugs
<martii> lamont: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/43363
<ubottu> Launchpad bug 43363 in gnome-user-docs "network: should list NFS shares too" [Low,New]
<martii> lamont: looks like this bug to me
<sistpoty|work> hm... good point. (though I guess a transition would equally qualify as a problem, that needs coordinated fixing in multiple packages)
<martii> lamont: but as well nobody interested to fix it?
<seb128> martii: nautilus doesn't do nfs
<cjwatson> for the mailbomb reason alone I think multiple bugs are a more practicably reasonable approach
<sistpoty|work> however, as I wrote already, the ui just renders really slowly for many tasks, so I definitely won't be abusing it for this :)
<martii> seb128: yep but It did
<martii> seb128: as well as gnome 2.22 docs show there is NFS support
<seb128> martii: not in ubuntu
<martii> seb128: I noticed ;)
<lamont> seb128: why'd we drop that?
<seb128> lamont: we didn't, I'm not sure any GNOME 2 version ever did that
<lamont> ah, o
<lamont> k
<martii> seb128: so why is it in docs?
<martii> seb128: I'm sure it worked
<seb128> because not a lot of people are interested in updating documentation
<ogra> wishful thinking of doc writers ?
<martii> seb128: as I have used it alot
<seb128> and some very old GNOME versions might have had crackish nfs support
<martii> seb128: nfs:// worked the same as smd:// in nautilus
<martii> seb128: nfs:// worked the same as smb:// in nautilus
<seb128> martii: that was GNOME1?
<martii> seb128: when ? year ago?
<martii> seb128: maybe that was gnome-vfs
<seb128> martii: http://bugzilla.gnome.org/show_bug.cgi?id=328107
<martii> seb128: and now you got gnome-vfs2
<ubottu> Gnome bug 328107 in Module: (other) "No nfs:// support" [Enhancement,Unconfirmed]
<ogra> martii, its called gvfs, gnome-vfs2 is the older one
<seb128> gnome-vfs2 and gnome-vfs are the same thing
<martii> ogra: whatever
<martii> ogra: I can't understand why new version is worse :)
<martii> ogra: you upgrade to net LTS and things not work :)
<martii> ogra: you upgrade to next LTS and things not work :)
<seb128> martii: you have one thing that almost nobody used and which was buggy which has been dropped and ton of other improvements
<martii> seb128: yep but as you can see
<martii> seb128: this bug is still unconfirmed
<martii> seb128: so many people confirmed a problem
<seb128> gnome-vfs is not maintained, they are working on gvfs now
<seb128> upstream doesn't care about confirming bugs, the doesn't make a difference, they know it's a wishlist but have other things to do
<seb128> and a nfs gvfs backend is a low priority thing, most people using nfs use system mounts for that
<martii> seb128: I understand I could do that as well
<martii> seb128: but it's nice to mount stuff only when you need it
<martii> seb128: as NFS tends to lock up my machine when I loose connectivity
<seb128> use automount?
<ogra> use sftp
<martii> seb128: yep that's an option
<martii> ogra: it's netapp filesever no sftp ssh
<ogra> less server overhead and supported in nautilus
<ogra> sad
<seb128> anyway the option was to work on improving ssh, ftp, smb supports or write a nfs backend
<martii> ogra: nfs only (there is smb but of course nautilus is unable to pass my LDAP username and password correctly)
<seb128> almost everybody prefer to have better support for the common backends
<seb128> but you are welcome to write a gvfs nfs backend if you think that's needed
<martii> seb128: I know and understand that
<martii> seb128: if it's C++ foreget it :)
<martii> seb128: if it's C++ forget it :)
<ogra> C
<martii> seb128: I can only do python :)
<seb128> it's C
<ogra> plain and simple actually
<martii> C is more likely I could remind myself
<martii> seb128: any links to docs?
<martii> seb128: if developers will be happy to apply my patch or extension
<seb128> http://library.gnome.org/
<martii> seb128: I had problems before
<seb128> you can mail the gvfs upstream list
<martii> seb128: they might start talking like you that people don't need nfs
<martii> ;)
<seb128> but I don't expect a nfs backend to be easy to write
<seb128> well, they will not likely put efforts into it no
<seb128> but if you send a work patch, that's going to be difficult though, that's not trivial coding
<martii> seb128: http://library.gnome.org/devel/references
<martii> no reference to gvfs
<lamont> just remember that NFS stands for Not a File System
<ogra> martii, they wont tell you nfs isnt needed if you send code :)
<lamont> (per posix, with interpretation)
<ogra> heh
<martii> ogra: many times developers did that
<ogra> well, ususally developers are happy if you send code and help you to improve it is what is my experience
<martii> ogra: moslty they say they don't want to brake their code with untested stuff when priority for extension is not critical
<geser> pitti: does it needs MIRs to get some perl modules from universe to main which are needed for build-dependencies?
<seb128> martii: no real documentation out of the source code for now, gvfs is pretty new and it's really a rush, people are busy trying to get it work right now and didn't stop to write documentation
<pitti> geser: at least MIR bugs; trivial ones don't need a full wiki page
<martii> seb128: OK I'll stick with autofs
<martii> sorry for wasting your time guys
 * geser hates the perl 5.10 transition already
<ogra> you expressed a need
<ogra> not wasted time, really
<martii> ogra: :)
<martii> http://www.acis.ufl.edu/~ming/gvfs/ so that's not the gnome thing?
<pitti> geser: can't say how grateful we all are that you deal with it *hug*
<hunger> Which version of the telepathy spec will be supported in intrepid?
<geser> pitti: http://launchpadlibrarian.net/14685812/buildlog_ubuntu-intrepid-i386.libfile-sync-perl_0.09-4build1_FAILEDTOBUILD.txt.gz Is this a bug in the package or in pkg-create-dbgsym?
<pitti> geser: it's a bug in the package, since debhelper compat 1 needs debian/tmp; it's a problem with pkg-create-dbgsym in the sense that it is not as forgiving as debhelper about packaging bugs
<geser> pitti: thanks, will fix the package then
<pitti> ideally we'd fix pkg-create-dbgsym to deal with those
<pitti> if it builds locally
 * pitti kicks rothera again to get back to work
<pitti> infinity, cprov: ^ FYI
<Kano> hi, is anybody using ICH9R with raid 5 successuflyl?
<Keybuk> ok, that's weird
<Keybuk> "People nearby"
<Keybuk>  O  Keybuk
<evand> heh
<ion_> keybuk: What says that? :-)
<Robot101> Keybuk: you can see yourself in Empathy?
<Keybuk> I can indeed
<Keybuk> I suspect the machine upstairs just woke up for something and logged in
<Robot101> ah ok, i was about to say sjoerd's here now so you can badger him on #tp if you've found a bug :)
<sjoerd> I usually use sjoerd on X as my nick in salut to prevent that kind of confusing :)
<Keybuk> if only we could set the status usefully ;)
<Robot101> Keybuk: what do you mean?
<Keybuk> doesn't jabber have an extended status bit?
<Robot101> like the "custom messages" thing in the status dropdown?
<ion_> Is intrepid beginning to be usable? That is, are there still some huge things like a new major release of glibc coming?
<ion_> I donât mind running an unstable distro on this box, but rather wouldnât upgrade yet if itâs expected to break badly. :-)
<geser> ion_: we are still in the middle of the perl 5.10 transition, but you could have luck
<ion_> That sounds like something i might even be able to help with.
<fde> Hello, several people in #ubuntu are having issues due to hardy-proposed currently... it appears that gnome-about depends an explicit version of gnome-desktop-data (2.22.2-0ubuntu1) but today it was upgraded... this removed gnome-panel for many... and I don't see this package in http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-desktop/ and don't have it locally to upload to a ppa...
<fde> What can be done about this situation?
<cjwatson> sounds to me like architecture desync
<cjwatson> gnome-desktop-data is built on i386 and the same package is used on all architectures
<cjwatson> gnome-about is built on each architecture separately
<fde> cjwatson: It is people that have hardy-proposed enabled due to virtualbox I think... seems to be unfortunate timing on their part.
<cjwatson> but they come from the same source package
<cjwatson> so when i386 builds out of step with the others, you'll get this happening transiently
<cjwatson> tell them to wait for a while and try later, and it will go away
<fde> cjwatson: Some have already lost their panels... just apologize to them?
<pochu> the question is, why people who don't check what is going to be removed use -proposed?
<cjwatson> https://launchpad.net/ubuntu/+source/gnome-desktop/1:2.22.2-0ubuntu2 shows that the new version hasn't quite built everywhere yet, though it should be OK for i386 and amd64 users
<cjwatson> fde: why did they allow the upgrader to remove packages in the first place?
<pochu> fde: first ask them to disable -proposed! :)
<cjwatson> fde: advise them to reinstall ubuntu-desktop
<fde> pochu: it is a documented work around for virtualbox, although apparently that documentation didn't mention disabling it when they're done.
<fde> cjwatson: alright, thanks. pochu definitely will do  :)
<pochu> fde: right, there should be some easy way to install packages from -proposed without enabling it completely...
<fde> Thanks for the assistance, wanted official word  :)
<cjwatson> fde: sounds like they used an option designed for advanced testers and got burned by the consequences; the documentation should definitely be fixed
<fde> pochu: maybe something like experimental on debian should be enacted?
<cjwatson> fde: hardy-proposed *is* a bit like experimental
<cjwatson> although not so much
<cjwatson> we have plenty of things that fill similar niches; however if people get told to use them then what can we do?
<fde> cjwatson: still, even when enabled, people don't need to be using it always unless they're aware of what that entails.
<pochu> cjwatson: yesterday we had the same problem with people removing firefox via update-manager, due to the "Partial upgrade" dialog in it
<pochu> so while I think they shouldn't be running -proposed at all, update-manager could be more verbose there
<cjwatson> hardy-proposed contains non-QAed updates that may break your system, because they have not yet been verified
<cjwatson> it's that simple
<pochu> of course
<cjwatson> so while we welcome people helping us with the QA process, we can't really also have them coming to us and complaining that things were set up wrong because their system broke :-)
<fde> cjwatson: I think it's safer to make people type 'sudo aptitude -t hardy-proposed install whatever' and document how to enable it always _no_where_... there's been a few issues like this, and people inevitably want things like firefox and virtualbox to work.
<cjwatson> I agree that there is room for improvement in update-manager
<cjwatson> I know that mvo knows about this, since he mentioned it yesterday (I think)
<ion_> After this operation, 2179MB disk space will be freed.
<fde> cjwatson: Even just having it deselect everything originating from hardy-proposed, and forcing users to select what they actually want would be better... if that is even possible?
<cjwatson> -> mvo
<cjwatson> though I was under the impression it already did that; could be wrong
<cjwatson> oh, actually, no, I'm thinking of something else
<cjwatson> remember that -proposed was instituted in response to a problem that slipped through QA that caused X not to start for some people
<pochu> I reported bug 152335 some time ago to try to reduce the number of users running -proposed
<ubottu> Launchpad bug 152335 in software-properties "Remove -proposed checkbox in Updates, or warn of 'not stable' updates" [Undecided,New] https://launchpad.net/bugs/152335
<fde> cjwatson: Yes, I actually discussed that at a LUG a couple nights ago  ;)
<cjwatson> regardless of whether you deselect things by default, people will try selecting them out of curiosity - isn't X not starting much worse than firefox going away?
<pochu> although that may not be a good solution at all :)
<ogra> the software sources dialog doesnt really tell you that its dangerous to enable it
<cjwatson> thus the most important thing is not to advise people to use -proposed who can't cope
<ogra> the wroding should be better
<ogra> *wording even
<cjwatson> even if that's the only location for a bug fix in progress, it's more important to have it go through QA before wide deployment
<fde> cjwatson: It's hard to ensure that in private mediums though... so maybe a technical solution is better...
<fde> Should I file a bug with some propositions real quick just to remind?
<cjwatson> sure, better than talking to me about it since I'm not the relevant developer ;-)
<cjwatson> should go on apt I think
<fde> cjwatson: alright, thank you for your recommendations... if that doesn't fix it for users (reinstalling ubuntu-desktop) then I'll likely be back... or maybe I'll break it and try to fix it locally  :P
<fde> On a more positive note: Thanks for all the hard work, you guys are awesome  :D
<cjwatson> it will depend on the architecture they're using
<cjwatson> powerpc doesn't seem to have caught up yet
<fde> cjwatson: I'll try to look into that too... luckily qemu can emulate a ppc system - although it'll be slow as molasses.
<fde> (only from a user perspective though... see if I can come up with another solution if that doesn't fix things)
<mvo> cjwatson: we could disable partial upgrades at all in stable, they are only required when things need to be removed and Ithat should never be the case for stable
<rom> hi
<alex1> hi guys. what does it mean when a bug's status is triaged in launchpad?
<Methoxypropan> Hello :)
<Methoxypropan> I've got a BCM94311 rev 2 wireless network card and read about a patch to get it working with the native bcm43xx-fwcutter. Where can I download the patched driver?
<Kopfgeldjaeger> bug #214386
<ubottu> Launchpad bug 214386 in linux "bcm94311 rev 02 not detected at boot time" [Undecided,New] https://launchpad.net/bugs/214386
<Methoxypropan> thanks Kopfgeldjaeger
<rom> hi, I reported a bug in compiz with a patch this morning : https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/235982 (my first patch \o/ )
<ubottu> Launchpad bug 235982 in compiz "/usr/bin/compiz : 1 bug and 1 missing setting" [Undecided,New]
<rom> do you think it could be applied
<Methoxypropan> where can i download the patch from bug #214386
<ubottu> Launchpad bug 214386 in linux "bcm94311 rev 02 not detected at boot time" [Undecided,New] https://launchpad.net/bugs/214386
<elmo> pitti: can I turn off the python apport stuff
<Methoxypropan> Hi dev's ;)
<speart> hi, can init.d rules, or udev entries prevent computer shutdown?
<mvo> rom: the fist part of the patch looks good, I'm not sure about the "-l" bits
<rom> mvo: why that?
<rom> nvidia-settings -l
<mvo> rom: it seems like this is something that we shouldn't enforce in the compiz script, I don't need it and it gives me a ugly flickering
<rom> to load the settings (if you don't, nvidia settings are not applied)
<rom> since a long time
<Methoxypropan> can anybody help me with bug #214386
<rom> (antialiasing, anisotropic, sync to vblank)
<ubottu> Methoxypropan: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/214386/+text)
<mvo> rom: isn't that only required if the nvidia-settings panel is used and shouldn't it be used in a place that is more generic that the compiz start script? like .xinitrc or something similar?
<Methoxypropan> i need that patch to get my wireless working :(
<rom> hmmm...
<mvo> rom: actually, if its something that should always be run, I think it should be part of the nvidia-settings package and go into /etc/X11/Xsession.d maybe
 * mvo is not a expert for the binary driver though
<rom> should not always be run, only before compiz lunch
<rom> I guess
<rom>  Load the configuration file, send the values  specified  therein
<rom>               to  the X server, and exit.  This mode of operation is useful to
<rom>               place in your .xinitrc file, for example
<rom> ok
<mvo> before compiz or anything that uses 3d I guess? like games etc?
<mvo> tjaalton: ---^ do you have a opinion on the right place to put nvidia-settings -l ?
<rom> so, it should be added in nvidia-settings package, no?
<rom> to add it to .xinitrc file
<mvo> yes, that looks like a better place to me (/etc/X11/Xsession.d probably)
<rom> where is .xinitrc?
<rom> I don't find it
<rom> locate .xinitrc doesn't give any result
<rom> l
<rom> and in which file compiz in launched when starting?
<rom> mvo?
<rom> ?
<mvo> rom: its in the users homedir, but that is not a place where packages can put stuff, this is why I mentioned /etc/X11/Xsession.d
<rom> ok, and do you know how compiz starts when system starts?
<rom> in which file
<rom> is it started?
<Pici> rom: It doesnt start when the system is started.
<Pici> rom: It starts after a user logs in.
<rom> in ubuntu, yes
<rom> ah
<rom> yes :)
<rom> where is it started?
<Pici> rom: Have you looked into mvo's suggestion?
<rom> I have no .xinitrc
<Pici> rom: No one but you mentioned that, see /etc/X11/Xsession.d
<rom> yes I searched
<rom> but this dir is for putting nvidia-settings -l, I didn't find compiz here
<rom> cat /etc/X11/Xsession.d/* | grep compiz â no results
<ion_> UUOC ;-)
<rom> no idea?
<mvo> rom: compiz is started via the gnome-wm script by gnome-session. but I it seems to me that the nvidia-settings -l run should be independant of the compiz one
<rom> mvo, yes, I agree nvidia-settings -l should be independant ;)
<rom> where is "gnome-wm script by gnome-session"?
<rom> ah, gnome-wm is in /usr/bin :)
<rom> thanks
<rom> but doesn't it slow down the boot time ?
<rom> to load metacity first, then when the user is logged
<rom> to load compiz...
<rom> ?
<Pici> I dont see that there.
<rom> what do you mean (sorry, I'm not english, I don't get it)
<rom> "I dont see that there"
<rom> ?
<Pici> rom: gmome-wm looks like it calls whatever window manager based on a set of rules, not both wms.
<Pici> anyway, I need to run.
<rom> ok, but before running compiz
<rom> when you have login screen
<rom> it's metacity, no?
<rom> to run nvidia-settings -l in /etc/X11/Xsession.d, I just have to make a script containing "nvidia-settings -l" with a special filename?
<rom> mvo? could you confirm how to add a script to Xsession.d?
<mvo> rom: that sounds right, it needs to be added to the nvidia-settings package
<mvo> rom: you may talk to the people in #ubuntu-x too
<simira> mvo: are you still responsible for the update-manager?
<rom> mvo: ok, but do you know how to add a script in Xsession.d? Just put the script "like this", no particular format?
<mvo> simira: yes
<simira> mvo: works very well now, I like it!
<mvo> simira: cool, I like that :)
 * mvo hugs simira
<calc> Mirv: yes, i need to make an upload of the openoffice.org-l10n packages that i will be doing in a few minutes
<calc> pitti: 220911 is a bug in openoffice.org not writer2later afaicr but i haven't added it in yet to the upload since i need to verify the patch works properly (its not a patch in ooo-build)
<ion_> keybuk: What was this about? :-) * At this rate, I'm going to prove pitti right!
<Methoxypropan> Hello
<Methoxypropan> Where do i get a patched bcm43xx driver ?
<ion_> Note to self: mention http://heh.fi/tmp/recovery-mode-dpkg.patch to mvo
<cjwatson> ion_: 'if [ -x $python -a -e $script ]' -> 'if [ -x "$python" ] && [ -e "$script" ]' please?
<cjwatson> (quoting is just good style, and the rules for -a and -o are so twisted and unintuitive they're best avoided)
<ion_> cjwatson: Will do. I usually do quote pretty much everything, but that case seemed so obvious, since there are â2.5 2.6â right above.
<Methoxypropan> Hello
<Methoxypropan> When will the patched bcm4311xx driver be in the ubuntu repo?
<ion_> cjwatson: Updated.
<Methoxypropan> no answer?
<cjwatson> Methoxypropan: which patch are you talking about here?
<cjwatson> Methoxypropan: and is there a bug filed about whatever it is?
<Gaming4JC> hi
<Methoxypropan> cjwatson, yes there is a bug report on launchpad...wait..i'm going to search it
<Gaming4JC> I need some one who can compile a modem driver (I got the source), so I can get online in Ubuntu. :)
<Mirv> calc: remember also the rebuild of openoffice.org-voikko, to be published at the same time so as not to force language-support-fi/ooo-voikko deinstallation
<Gaming4JC> If anyone could do it, I'd give you much thanks. http://linmodems.technion.ac.il/pctel-linux/pctel-0.9.7-9-rht-6_for_Ubuntu-2.6.15-23-386.tgz
<Mirv> (really should have automatic testing/stuff about the dependencies etc.)
<Methoxypropan> cjwatson, its bug #214386
<ubottu> Launchpad bug 214386 in linux "bcm94311 rev 02 not detected at boot time" [Undecided,New] https://launchpad.net/bugs/214386
<Gaming4JC> :) ...
 * Gaming4JC you can see I cannot get online to compile the tool, so I was wondering if anyone could do it. (would help so much) 
<Gaming4JC> I'm on Windows now.
<Gaming4JC> :'(
<Chipzz> Gaming4JC: the reason no-one is answering is because this is not a support channel
<Gaming4JC> it's development?
<Chipzz> yes, OF ubuntu
<Gaming4JC> so not drivers for Ubutnu?...
<Gaming4JC> :-/
<Chipzz> what you're trying to do is not even development
<Chipzz> it's compiling
<Gaming4JC> eww... so where should I go for that? (main support doesn't seem to know)
<Chipzz> forums or #ubuntu
<Methoxypropan> cjwatson, in the last post the guy sais something about a patch.... but when will the patch be in the repo?
<cjwatson> Methoxypropan: "a new patch has been submitted" but no link
<Gaming4JC> ok thanks
<Gaming4JC> byes ;)
<cjwatson> Methoxypropan: the name in that last comment isn't one I recognise; he's not a member of the Ubuntu kernel team
<cjwatson> (AFAIK)
<cjwatson> so somebody needs to actually provide the patch to the Ubuntu kernel team (or a reference to it or whatever) in order for it to have a hope
<cjwatson> I suspect he's perhaps a bcm43xx upstream guy looking at his subscribed bug list
<cjwatson> so perhaps what he meant was that a patch has been sent to bcm43xx upstream
<Methoxypropan> cjwatson, http://cantrip.org/bcm43xx-2619.patch
<cjwatson> a patch from October 2006? surely not
<cjwatson> whatever Larry is describing sounds much more recent than that
<Methoxypropan> so how long will i have to wait?
<cjwatson> the bug is in far too early a state to be able to say
<Methoxypropan> ok thanks a lot ;)
<cjwatson> if you want to help, track down whatever it is that Larry was actually referring to
<cjwatson> I do think you will need to look for something that's actually from this year
<Methoxypropan> cjwatson, they said that the patch that made it working has been removed because an othe card didnt work
<cjwatson> yes, I read that
<cjwatson> ah, he sent some patches to kernel-team@
<cjwatson> which Tim seems to have picked up
<Methoxypropan> cjwatson, so maybe it'll be in the next kernel?
<cjwatson> it looks like it
<cjwatson> see bug 197959
<ubottu> Launchpad bug 197959 in linux "[Hardy]Recent kernel update to 2.6.24-11 breaks b43 (with bcm4312)" [High,In progress] https://launchpad.net/bugs/197959
<cjwatson> "There is now a test kernel in my PPA with these 4 patches at http://ppa.launchpad.net/timg-tpi/ubuntu. Please give it a try and report the results."
<cjwatson> perhaps you could give that a shot and report results to 197959, assuming that's essentially your bug
<Methoxypropan> thanks a lot cjwatson
<cjwatson> I doubt that's targeted for 8.04.1 at this point (though I could be wrong); it's a bit late - but at least you'll have the PPA kernel to tide you over until then, and if it's working well then it'd be at least in the next round of hardy kernel updates after 8.04.1
<cjwatson> (and, as I suspected above, Larry does indeed seem to be a bcm43xx upstream guy, helping out)
<Methoxypropan> ;)
<Methoxypropan> cjwatson, so i'm going to reboot and hopefully be back again
<Methoxypropan> cjwatson, so its working perfectly ;)
<cjwatson> oh good; can you update the bug on that if you haven't done so already?
<cjwatson> (both the one you originally gave and the one I pointed out)
<Methoxypropan> cjwatson, mhm...can i do it tomorrow? i'm really tired
<Methoxypropan> Which bug numbers did the bugs have?
<Methoxypropan> cjwatson, can you remember the bug numbers?
<cjwatson> 22:21 <Methoxypropan> cjwatson, its bug #214386
<ubottu> Launchpad bug 214386 in linux "bcm94311 rev 02 not detected at boot time" [Undecided,New] https://launchpad.net/bugs/214386
<cjwatson> 22:36 <cjwatson> see bug 197959
<ubottu> Launchpad bug 197959 in linux "[Hardy]Recent kernel update to 2.6.24-11 breaks b43 (with bcm4312)" [High,In progress] https://launchpad.net/bugs/197959
<cjwatson> my IRC client can ;-)
<Methoxypropan> thanks ;)
<Methoxypropan> so i should say that it's working on my system and tell the guys from bug #214386 that they can use the kernel from bug #197959 ?
<ubottu> Launchpad bug 214386 in linux "bcm94311 rev 02 not detected at boot time" [Undecided,New] https://launchpad.net/bugs/214386
<ubottu> Launchpad bug 197959 in linux "[Hardy]Recent kernel update to 2.6.24-11 breaks b43 (with bcm4312)" [High,In progress] https://launchpad.net/bugs/197959
<cjwatson> I think so
<Methoxypropan> bbl [02:00 pm GMT+1] :P
<Methoxypropan> gn8
#ubuntu-devel 2008-05-31
<calc> Mirv: if you can please file a bug (if it doesn't exist) targeted to 8.04.1 to update voikko
<slangasek> s/targeted to 8.04.1/targeted to the hardy release/
<calc> slangasek: oh ok
<slangasek> well - in this case, probably both
<slangasek> but target it to the hardy release first :)
<wgrant> Uh, why is there a private bug referenced in the -intel changelog?
<cjwatson> nothing wrong with referencing private bugs from changelogs as such - what use are private bugs if you can never fix them? :-)
<wgrant> cjwatson: What use is referencing bugs in changelogs if people can't look at them?
<cjwatson> I assume it relates to hardware whose existence or codename or whatever isn't public yet
<cjwatson> it's useful for those people who do have access to the bugs to have a record of when they were fixed
<cjwatson> bug references are as much for archaeology as anything else
<wgrant> I guess, but I don't like this idea of SRUs happening completely in secret, with no information even after they occur and break everybody's systems.
<cjwatson> for an SRU, I think there ought to be a public counterpart bug
<cjwatson> with whatever information can be disclosed
<wgrant> Right, people might actually want to see what this change is doing to all of their systems.
<cjwatson> I still see no reason not to reference the private bug as well - you're no worse off than if the changelog hadn't referred to it at all
<wgrant> If there was a public one as well, that would be OK.
<cjwatson> though the changelog is fairly descriptive otherwise
<cjwatson> bryce: ^- just to draw your attention to the above conversation
<bryce> cjwatson: thanks
<cjwatson> in fact looking at it the changelog is almost more descriptive than the bug report in most ways ;-)
<cjwatson> (though there is legitimately private stuff in the report)
<bryce> yeah
<wgrant> But we're not to know that.
<cjwatson> indeed
<bryce> yeah I've been rather torn on how to handle these kinds of bugs
<bryce> so would welcome advice
<cjwatson> for intrepid, I'm not sure it's a big deal
<cjwatson> for SRUs, I think a public counterpart bug is probably a good compromise
<wgrant> For Intrepid, sure, people won't be wanting to watch every bug for every update.
<cjwatson> we used to do that for SRUs much more commonly - we'd file a new bug just for the SRU request
<cjwatson> nowadays we tend to reuse the original bug
<cjwatson> but for this case, we could go back to the older fashion
<bryce> I've gotten scolded for filing new bugs just for putting in sru's ... which is why I didn't do it in this case
<cjwatson> it's generally a waste of bug numbers :-)
<wgrant> bryce: This is a rather different case.
<bryce> (and time)
<wgrant> cjwatson: And it splits the useful information away from the SRU bug where users would look.
<cjwatson> indeed
<cjwatson> another reason to have a separate public report is so that the SRU verification team can see it without having to expose private information to them
<cjwatson> note that not all the sru-verification members are Canonical staff and so they are not subject to NDAs
<bryce> in this case it was a bit annoying in that I'd gotten the patch outside launchpad, and specifically asked them to file a bug as a necessary step to getting an sru
<bryce> so they finally did... but marked it private and a security issue (which I removed)
<slangasek> heh, win
<slangasek> :-)
<wgrant> bryce: One cannot file a private non-security bug.
<kees> much to my sadness
<wgrant> Poor security team :(
<kees> and one can't unsub ubuntu-security unless you're a member of it.
<bryce> eesh
<kees> but I'm used to identifying them and unsub'ing myself
<bryce> and if you file a public bug and then mark it private, it auto-subs two dozen people
<kees> yup
<bryce> ah, well at least now I've learned how to file private bugs from the start
<wgrant> bryce: It doesn't autosub anybody...
<cjwatson> bryce: auto-sub is sort of irrelevant there though, if you file public and then mark as private
<sistpoty> wgrant: hm? what about apport bugs? aren't these private by default?
<cjwatson> (or "also notified" or whatever)
<cjwatson> bryce: if you file a public bug, it sends bugmail out to a public mailing list :-)
<wgrant> bryce: Only explicit subscriptions are used in a private bug - implicit subscriptions are excluded.
<wgrant> sistpoty: I'm not sure how it does that. Not through the main web UI, at any rate.
<bryce> cjwatson: well I couldn't see any other mechanism for filing private bugs
<sistpoty> wgrant: heh, k
<cjwatson> bryce: right, I'm just explaining why making the subscription behave differently wouldn't help
<cjwatson> can't unsend the mail when you mark it private ;-)
<cjwatson> (and yeah, I'd seen the earlier conversation along the same lines)
<wgrant> cjwatson: LP normally batches bugmail 5-minutely. Does marking it private in the first 5 minutes not do it?
<cjwatson> wgrant: it might do, I wouldn't like to swear to it. For example is it every five minutes by cron or five minutes from each action? Not something I've ever bothered to verify
<bryce> it might be nice for further discussion... but really my complaint is just that it's not obvious how to file a private bug
<cjwatson> plus what if your ADSL line decides to die at that point?
<cjwatson> bryce: I agree; kiko seemed amenable to doing something about that
<cjwatson> but I have it on my list to raise for Launchpad planning purposes anyway
<bryce> at least I know the workaround though (not that I file many private bugs - first one ever was just the other day)
<wgrant> Bug #121859
<ubottu> Launchpad bug 121859 in malone "RFE: Url for posting private, non-security bugs" [Undecided,New] https://launchpad.net/bugs/121859
<bryce> cjwatson: so for future reference with private sru's, I should post a new public bug with the private info redacted?
<bryce> I've let the reporter know that they should post sru bugs public in the future, since I expect we may be getting more like this from them.
<cjwatson> bryce: I think that's the best option for the time being; maybe remind me on Monday to talk about it with pitti and we'll get the policy adjusted
<cjwatson> public> but of course not demanding that they post private information in public :-)
<bryce> yeah, also because I may not be a good judge of what info exactly is to be considered private
<slangasek> kirkland: looks like grub FTBFS now in intrepid, on amd64 only; could you try to reproduce this when you have a chance?
<calc> isn't google calendar supposed to be read/write in hardy now?
<calc> er inside evolution
<Daviey> calc: works in with opensync
<Daviey> calc: Bug #197972 was the problem before
<ubottu> Launchpad bug 197972 in libopensync-plugin-google-calendar "Doesn't handle recurring events in google cal" [Undecided,Fix released] https://launchpad.net/bugs/197972
<Daviey> or _a_ problem at least
<slangasek> well, evolution also knows about 'google' as a calendar type, not using opensync; I guess that's what calc refers to
<Daviey> my bad.. I don't use evo very often.
<Amaranth> http://www.ubuntu.com/getubuntu/download is broken, not sure where to report this
<wgrant> Amaranth: Bug on ubuntu-website in general, but this is probably a bit too important.
<Amaranth> i mean, it'll still download, but only from releases.ubuntu.com
<Amaranth> which can mess with people's quotas and generally cause slow downs
<wgrant> And it looks awful.
<Amaranth> that too
<Erick> anyone in here?
<Hobbsee> Erick: no
<Erick> Hobbsee hey i have a question i've been actived. on the launchpad.net for ubuntu how do i become part of the Project?
<Erick> I am a translater
<Hobbsee> Erick: #launchpad knows the details on translations, i think.
<Hobbsee> but it is a weekend, so i'm not sure who's around
<arthur-> pitti: I will have a look, thanks
<andrew_sayers> Would I get laughed out of launchpad for requesting that by default, openssh-server only allow password logins from users with a ~/.ssh/allow_passwords file?
<andrew_sayers> i.e. making password authentication contingent on an educated user choice, independent of administrators.
<Hobbsee> andrew_sayers: ask cjwatson sometime during european working hours.
<andrew_sayers> Yeah, I guess I should have dreamed the idea up yesterday :)
<cjwatson> andrew_sayers: not laughed out as such. I think something like that might be a useful feature, but I don't think it'd be appropriate for a default; too many sysadmins bootstrap new accounts using password auth
<andrew_sayers> cjwatson: Couldn't they put something in /etc/skel then?
<cjwatson> I'm sure they could but it would be another way in which Debian/Ubuntu deviated from upstream thereby causing confusion and requests for help (which I expect I'd have to field)
<cjwatson> I just don't think it's an appropriate default
<andrew_sayers> Hmm, fair enough.  So should I submit a feature request, and if so, where?
<cjwatson> perhaps file a bug on bugzilla.mindrot.org (upstream) asking for the basic feature of allowing users to turn password auth on or off for their own account
<andrew_sayers> Okay, will do.
<andrew_sayers> Incidentally, is there any way of making one username an alias for another in sshd_config?
<cjwatson> and presumably you mean without disabling *local* password auth?
<cjwatson> because if you want that too, just give the account no password
<cjwatson> (a locked password, I mean)
<andrew_sayers> Yeah, I'm thinking about clueless users installing SSHD then getting dictionary-attacked.
<andrew_sayers> Basically a way for users to enable/disable PasswordAuthentication for their own account.
<cjwatson> I don't think there's a way to alias users, no. Feels like something you should use PAM for
<andrew_sayers> Hmm, okay.
<andrew_sayers> I'm still working on a remote help assistant, and the solution I've come up with seems pretty secure to me, except that it increases the probability that helpers will set up bad ssh servers.
<andrew_sayers> Right, last suggestion on the topic: when installing openssh-server after installation-time, how about asking whether to allow password auth?
<andrew_sayers> (which I assume it doesn't right now)
<kestaz> ReschedulingInterrupts.. any success to fix ?
<Mirv> calc: done, bug #236248 , I guess I don't have other rights besides nominating for hardy
<ubottu> Launchpad bug 236248 in openoffice.org-voikko "Rebuild openoffice.org-voikko for the 2.4.1 upload of openoffice.org" [Undecided,New] https://launchpad.net/bugs/236248
<Mirv> (I should probably join the bugs team)
<asac> Mirv: could you please test and comment on 219655 ... thanks!
<Mirv> asac: yep, tested on two machines and seems to be great now
<asac> Mirv: thanks. please keep using it ;)
<asac> Mirv: there was another bug about finish URLs not working properly. you remember that?
<asac> finnish
<asac> ;)
<asac> Mirv: its 221376
<asac> do you still see that?
<Mirv> asac: yes, that one is still there. apparently the problem is that with language pack disabled search bar calls google search, but with language pack enabled it just tries to load www.[typedtext].com
<Mirv> I'm not sure but I don't think there's anything specifically related to scandinavian letters like stated in the bug report, since it does the same (does not google search) for any text I type in the location bar
<asac> wierd
<Mirv> disabling xulrunner translation doesn't change anything, but apparently something in the firefox translation disables google search from location bar
<asac> Mirv: could you post your thoughts to the bug? they sound promissing and might help to find the real problem
<Mirv> yeah, I posted already something
<Mirv> changed now also the description
<asac> Mirv: ok i reassigned it to new (non-gnome) package as well.
<renegade444> Hi, I apologize for asking here, but nobody in #ubuntu was able to give me an answer, and I thought someone here might be more likely to know the answer. I'm trying to find a guide to making ubuntu-specific binary .deb packages from source, but I can only find a guide for 6.10 on help.ubuntu.com. My question is: Does that guide fully apply to 8.04? If not is there an 8.04 guide out there I just can't find?
<jpds> !packguide | renegade444
<jpds> gah, bot down
<bimberi> renegade444: https://wiki.ubuntu.com/PackagingGuide/Complete
 * bimberi is not a bot btw ;)
<renegade444> ahh, perfect, thank you very much!
<RicardoPerez> pitti: has you received my email about firefox problems in proposed langpacks?
<math_b> Hi, I'm trying to package something which provide a python library, should I use pycentral or pysupport ?
<Festor> math_b, #ubuntu-motu
<math_b> Festor: thanls
<garnm> hi
<garnm> does ubuntu have a recovery option?
<garnm> its not universe and multiverse deb is it
<Festor> recovery option = recovery mode?
<garnm> yes
<Festor> then yes
<jpds> garnm: it's in grub when you boot
<garnm> oh thanks a bunch
<garnm> is it in grub?
<garnm> ok you guys cant be wrong here
<jpds> garnm: when you boot, press "Esc" and it's in the menu
<garnm> gotcha
<garnm> thanks, sorry
<sistpoty> hm... what build target does LP actually invoke? (as this one puzzles me, since build-depends-indep weren't installed, but only the indep part actually needs them, which gets somehow invoked: http://launchpadlibrarian.net/14622202/buildlog_ubuntu-intrepid-amd64.hs-plugins_1.2-1_FAILEDTOBUILD.txt.gz
<qaws> hi, do you know LTS has broken dependencies? (at least for my language)
<persia> qaws: There are likely quite a few.  These are best encoded as bugs.  If you have fixes, that would be welcome.  Be sure to nominate for your release as they likely qualify for a stable release update.
<emgent> heya
<jelmer> info
<calc> anyone know what happened to cinepaint? it seemed to be removed from hardy?
<calc> was it replaced by something else?
 * danshearer is away: Zzzz
<wgrant> calc: IIRC there is no replacement, and it was removed for being a dead, buggy thing.
 * wgrant checks.
<wgrant> '(From Debian) RoM ; obsolete, buggy, unmaintained, being abandoned upstream'
<ion_> danshearer: Thanks a lot for the information!
<ion_> A future version of Gimp will use GEGL and thus support >8-bit colorspace.
<wgrant> calc: Seems it was partly because it was a GTK1 rdepend, but there is now a GTK2 version so it may be making a reappearance.
<wgrant> ion_: That's happening RSN, isn't it?
<ion_> wgrant: AFAIK theyâre been hacking the development branch of Gimp to use it for a while now.
<ion_> So, the next major Gimp release probably has it.
<Lightkey> 2.5 has been released already
<Lightkey> err, 2.5.0
<ion_> Oh, neat.
<wgrant> ion_: That's what I thought.
#ubuntu-devel 2008-06-01
<mnabil_> hello guys, is there's a how to for creating a virtual ubuntu package ?
<persia> mnabil_: Not really.  Why do you need one?
<sladen> mnabil_: virtual ubuntu package?
<sladen> mnabil_: can you expand the question; what type of 'virtual'?
<mnabil_> persia, actually , i'm building a custom system based on ubuntu, so i wanna make an update scheme using apt , so i can grab some package under one name
<persia> mnabil_: I'd suggest making a meta-package rather than a virtual package.  It is more likely to meet your needs.
<mnabil_> sladen, actually , like ubuntu-desktop i think
<sladen> mnabil_: a meta-package ?
<mnabil_> persia, cool , link me to the how to :D , or i can google ?
<mnabil_> sladen, is this a meta package :D
<persia> mnabil_: Better to just look at the source of an existing one.  Start with apt-get source ubuntu-desktop.
<mnabil_> the packages, ubuntu-desktop, xubuntu-desktop are called meta packages ?
<mnabil_> persia, so this is called meta package then ?
<sladen> mnabil_: apt-cache search meta| grep -i meta.*package && apt-get source packageofyourchoicetouseasanexample
<persia> mnabil_: A meta-package is a package that only contains dependencies information: no content.  A virtual package is one that doesn't even exist, but is used by other packages for dependencies management.
<mnabil_> sladen, yea, i just ask about the category name ,  i think i have conflict between the meaning of metapackage , and virtual package :D
<mnabil_> persia, so, ubuntu-desktop is a meta package , right ?
<sladen> mnabil_: yes
<mnabil_> sladen, thanks alot, sorry i new to ubuntu , and debian like distros,   i didn't use any :D
<mnabil_> i'm a gentoo user
<sladen> eg.  "mail-transport-agent" is a virtual package.  exim/postfix/sendmail all Provide: it
<sladen> but there is no such package itself
<mnabil_> sladen, yea, i'm reading , thanks alot :)
<dazza> hi, is it possible to create a 3TB ext3 filesystem with the standard ubuntu desktop kernel?
<Hobbsee> lamont: any idea why you made changes to kinput2?
<lamont> Hobbsee: because it annoyed me???
<lamont> no clue./
 * lamont goes looking
<Hobbsee> lamont: oh, excellent, it's not even in intrepid anymore, apparently (makedepend)
<Hobbsee> oh *nice*.  it hasn't existed apart from dapper.
<lamont> Hobbsee: it's called "xutils-dev" :-)
<lamont> Provides: imake, makedepend, xorg-build-macros, xmkmf
<Hobbsee> lamont: ahhh, so that moved.  right
<lamont> you could certainly go with the "I bet it works, please sync 3.1-10.1 from sid, kthx" and then add the xutils-dev build-depend if it doesn't... :-)
<lamont> given that it's built everywhere in debian, I expect that you can just sync it and have success
<Hobbsee> lamont: yeah.  well, seeing as i just synced it, taht's what i'll be doing.
<lamont> heh
 * lamont bets we can't sync a package from sid/NEW though. :0(
<lamont> http://people.ubuntu.com/~lamont/ISDN.png <-- why I'm not sure about the reliability of copper some days...
<lamont> gotta love those hard flat tops where one channel goes *splat*
<Hobbsee> lamont: you cna sync from anywhere that has a .dsc address, it appears.
<lamont> OTOH, I'd trade $something for something from the current century
<Hobbsee> heh
<lamont> Hobbsee: NEW queue isn't readable.
<Hobbsee> i was thinking of sid, but yes.
<Hobbsee> oh, i see.  sid/new as in the one thing, not either of them
<lamont> right
<lamont> bind9_1:9.5.0.dfsg-1 is sitting in NEW, bound for sid
<lamont> stupid soname changes
 * Hobbsee trouts whoever put in the requiring a debian maintainer field as a multi-affects bug.
<lamont> if it takes too long, I'll just upload a ~0ubuntu1 version. :D
<lamont> ??
<Hobbsee> ah, damn.  now it's frozen my firefox.
<Hobbsee> bug 23035-
<Hobbsee> bug 230350
<lamont> 2008-05-14  by  Luca Falavigna
 * Hobbsee trouts him again
<Hobbsee> i thought it was.
<Hobbsee> i just couldn't load the bug again, to check.
<lamont> Hobbsee: just mass close it and open new ones... :-)
<lamont> or not
<lamont> anyway, iz bedtime
<lamont> g'night
<twb> Does Ubuntu have a document anywhere defining what requirements must be met before an upgrade will be allowed into a (already released) release?
<twb> I realize it'll basically amount to "only if it fixes critical security bugs", but I'd like to be able to refer to the full document.
 * lamont bets that a search for "stable release update" on the wiki would be fruitful
<lamont> twb: that's the rule for -security.  -updates is a bit easier.  though not my much
<twb> So the wiki is considered the official place for that document?
<twb> I want to know what the Ubuntu developers are *committing* to, not an explanation of the intent.
<twb> (I'm reading https://wiki.ubuntu.com/StableReleaseUpdates now.)
<lamont> those are the rules that are applied wrt updates to stable releases
<lamont> which direction are you coming at the question from?  trying to get something in, or trying to avoid upgrades that you don't want?
<twb> From the persepective of a corporation deploying LTS
<twb> And personally as a Debian user who likes policy to be written down in great detail.
<twb> I'm looking at the upgrade list of a fresh desktop LTS install, and there are a lot of upstream point releases being included (e.g. gnome-about [1:22.2.1-0ubuntu6 -> 1:2.22.2-0ubuntu1].  As a Debian user, I have a deep-seated fear of allowing upstream to introduce new code to a stable release, because new upstream = new regressions.
<twb> Althogh looking at apt-cache policy I can see that example has come from -updates not -security.
<lamont> the shortest answer to that is to just not include hardy-updates in sources.list
<twb> Nod.
<Chipzz> twb: for the gnome packages in ubuntu, that's perfectly normal
<lamont> OTOH, hardy has a 8.04.1 release (which lands in updates, almost certainly) scheduled for august, which is when the upgrade from dapper->hardy is supposed to be fully happy and such... hence the higher rate of churn in -updates right now
<lamont> and yeah, ubuntu tracks gnome very religiously
<twb> So -updates constitutes the upgrades from version Nr0 to Nr1, where 1 is the latest micro(?) release?
<twb> Oh sorry, https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions is something else
<TheMuso> Hobbsee: That is a very very weird sync.
<Hobbsee> TheMuso: sorry?
<TheMuso> Hobbsee: Those two packages that have your name against them on the intrepid changes list.
<Hobbsee> TheMuso: yes, i know.
<Hobbsee> TheMuso: i can't sign with the archive key, of course.
 * TheMuso nods.
<Hobbsee> TheMuso: it's using sync-source.py, which effectively downloads the package, resigns, then lets you upload it
<TheMuso> Wouldn't it be better to request a sync?
<Hobbsee> TheMuso: perhaps.  i just wanted to save work, and knock it off the MoM list
<Hobbsee> although i'm aware it's not off yet
<ernstp> where can I find documentation about all the details of the debian/rules file?
<bimberi> ernstp: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
<ernstp> bimberi: perfect!
<uga> guys, anybody can tell what's the difference between libssh-2 and libssh2-1 ?
<uga> it's very confusing, both support ssh2
<nxvl> libssh-2 seems to be the 2 debian version of libssh
<nxvl> and libssh2-1 must be the 1st debian version of libssh2
<uga> nxvl: it supports ssh2 though
<nxvl> dunno
<nxvl> but folowing the debian version rules
<nxvl> that must be the loginc
<nxvl> logic*
<uga> I thought at first that libssh-2 was ssh1, but the url in says they disabled ssh1 by default
<uga> and the maintainer of the package is the same guy :/
<uga> http://packages.debian.org/sid/libssh2-1
<uga> http://packages.debian.org/lenny/libssh2-1-dev
<uga> uh-oh...
<uga> sid and lenny. that may mean something
<uga> oh sorry, no wrong pastes I go nuts now ;)
<nxvl> those ones are libssh2 both of them
<nxvl> also
<nxvl> that's a question you should ask on debian-devel
<nxvl> since they are debian packages
<nxvl> not ubuntu ones
<uga> nxvl: errrm... that's because in my google search debian packs appeared, but it seems ubuntu took the names from debian
<uga> I'm on ubuntu, not on debian =)
<uga> and ubuntu.com seems timing out on me :/
<nxvl> packages.ubuntu.com
<nxvl> or check in launchpad
<uga> trying, but the server refuses
<nxvl> launchpad.net/ubuntu/+source/$PACKAGENAME
<uga> that doesnt' seem to work for me, unless package name needs more than the name
<uga> nxvl: sigh, it's not possible this way, unless someboy fixes packages.ubuntu.com... I tried from a different host with no luck
<uga> nxvl: but you can sure check apt-cache search libssh and you'll see both
<uga> whose names, have obviously been inherited from debian
<uga> here you are  http://rafb.net/p/vsTMei98.html
<nxvl> mm
<nxvl> there is the difference in the descriptions
<nxvl> one is the client side library
<nxvl> and the other a programmers library
<uga> nxvl: from a kde-dev guy:
<uga> [11:43] <pusling> uga: the first one is libssh2 soname1 and the other one is libssh soname2
<uga> [11:43] <pusling> uga: I guess you should blame the upstreams of those two difeferent projects for choosing so similar names ;)
<uga> that should explain what's going on
<uga> I wonder if the two packages are needed
<uga> anymore
<nxvl> ask the DM
<nxvl> or send and e-mail to colin
<uga> seems the right thing to do yes
<GnineX> whois GnineX
<GnineX> oops..
<geser> Hobbsee: could you please give back irssi on i386 (CHROOTWAIT)? Thanks.
<Kopfgeldjaeger> do we already know which kernel version will be in intrepid?
<Hobbsee> geser: given back.  poor rothera.
<Hobbsee> wait.
 * Hobbsee does it manually, and sacrifices a goat to launchpad to ensure that buildd.py works again soon
<cody-somerville> \o/
<geser> Hobbsee: buildd.py works for me. I use it to do give-backs for universe packages.
<Hobbsee>   File "/usr/lib/python2.5/urllib2.py", line 506, in http_error_default
<Hobbsee>     raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
<Hobbsee> urllib2.HTTPError: HTTP Error 500: Internal Server Error
<geser> hmm
<Hobbsee> repeatable.
<geser> I took the script from people.ubuntu.com/~pitti/scripts and adjusted only the path to my LP cookie.
 * Hobbsee yoinks new changes
<Hobbsee> nope.  still an internal server error.
<geser> really interesting why it works for me but not for you. You probably have to much permissions :)
<Hobbsee> perhaps so.
<geser> or simply LP doesn't like you anymore :)
<persia> Did LP ever?  I always imagined Hobbsee's stick taming LP for the rest of us.
<Hobbsee> LP doesn't like me for being australian.
<geser> move to europe
<Hobbsee> yeah well.  i wouldn't mind doing that.
<cjwatson> persia: FWIW equivs might be a better thing to point people at than ubuntu-desktop. ubuntu-desktop is designed for ease of maintenance in Ubuntu, not so much for comprehensibility by everyone else ...
<persia> cjwatson: Ah.  Thanks.
<persia> Wow!  a meta-meta-package :)
<cjwatson> it's kinda cool
<ion_> http://gitweb.heh.fi/?p=ion/ubuntu/ion-meta.git;a=tree
<smarter> Could someone please have a look at bug #236526 ?
<smarter> https://bugs.launchpad.net/ubuntu/+source/devscripts/+bug/236526 - "uupdate should appends -0ubuntu1 instead of -1 to the version number"
<sladen> smarter: ideally that would detect if you're on Debian, or Ubuntu and select the default postfix based on that
<sladen> otherwise we have to keep a patch against Debian
<a7p> hi everyone - I found a removal request on a certain Package an I'd like to have further information on that - can anyone give me a direction to look into?
<a7p> https://launchpad.net/ubuntu/intrepid/+source/vim-latexsuite/20060325-4.1
<a7p> is the package in question
<sladen> a7p: removal?
<sladen> a7p: from whom?  for what reason?
<a7p> sladen, I've got absolutly no idea, not that the package was especially important to me - there is written: Removal requested  on 2008-05-05.
<a7p> or does that mean something entirely differend?
<sladen> a7p: where did the message come from?  where did you see the messagE?
<sladen> ah, on that URL  "Removal requested  on 2008-05-05. "
<sladen> it was uploaded by the auto-syncer
<cjwatson> a7p: to perhaps clarify what sladen said, that "Removal requested" just means that internal stuff in Launchpad decided to remove *that version* of vim-latexsuite
<cjwatson> a7p: you can tell this because there's also a message about it being superseded by a later version
<cjwatson> a7p: https://launchpad.net/ubuntu/+source/vim-latexsuite shows that it's still in the archive
<a7p> cjwatson, ah, thank you very much for the information ...
<a7p> did not get that connection.
<smarter_> sladen: I've attached a new patch to https://bugs.launchpad.net/ubuntu/+source/devscripts/+bug/236526
<sladen> smarter: looks very good
<smarter> thanks ;)
<sladen> smarter: I wonder if there's a more reliable way than  grep Ubuntu /etc/issue
<sladen> there's /etc/lsb-release but I have a feeling that is only meant to be accessed via  the 'lsb-release' command
<smarter> lsb_release -i
<smarter> $(grep Ubuntu $(lsb_release -i)) maybe, but it doesn't look good
<sladen> if [ `lsb_release --short --id` = `Ubuntu` ] ; then ... maybe?
<sladen> it could even got inside a switch statement
<smarter> good idea
<smarter> I'll try to do that
<geser> smarter: you might look how dch does it, but it also uses the output of lsb_release -is
<Mithrandir> which is what sladen is suggesting.
<Mithrandir> oh, you were suggesting a way to look more at the code around it; just ignore me. :-)
<a7p> #225411 is fixed in Intrepid, and the commited patch works for hardy - I'm just bilding a diff for gustys package - how should I procede?
<sladen> bug #225411
<sladen> ubugtu...
<smarter> sladen: new patch: https://bugs.edge.launchpad.net/ubuntu/+source/devscripts/+bug/236526
<sladen> smarter: that's close enough I'd be happy with it
<sladen> smarter: I'd generally do   test -x /usr/bin/lsb_release && ...   as it's mandated where 'lsb_release' is and avoids PATH
<sladen> smarter: case "$(test -x /usr/bin/lsb_release && /usr/bin/lsb_release --short --id 2>/dev/null)" in  Ubuntu)
<cjwatson> sladen: prefer which or type to any use of hardcoded PATH
<sladen> cjwatson: can do.  Do you also want a --distribution override a la the other utilities?
<cjwatson> this is just a drive-by review, haven't looked that far ...
<cjwatson> (I don't use uupdate myself any more so I'm not really a good person to answer that)
<geser> wasn't one reason for the --distribution override that one can work on Debian package on a Ubuntu system and vice versa? so the same should apply for uupdate, shouldn't it?
<cjwatson> slightly more interested right now in why valgrind is failing on my openssh build :-/
<Keybuk> cjwatson: hang on, didn't this exact same thinking just cause the world a lot of hurt? :p
<cjwatson> that was failing in the usual way
<cjwatson> this is valgrind outputting nothing but:
<cjwatson> valgrind: mmap(0x0, 294912) failed in UME with error 13 (Permission denied).
<cjwatson> strace has:
<cjwatson> open("build-deb/ssh-add", O_RDONLY)     = 3
<cjwatson> [...]
<cjwatson> mmap2(NULL, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied)
<Keybuk> cjwatson: kees woz 'ere ?
#ubuntu-devel 2009-05-25
<Hydrant> Hey all... I'm trying to build ghc6 from source from karmic into jaunty... but it depends on haddock which depends on ghc6... any way to resolve this silly cyclic dependency ?
<snth> Could anyone explain how does ubuntu automatically mounts flash drives .. etc.
<snth> There has to be a service or something that runs based on kernel events .. equivalent to devd in FreeBSD .. but I don't know it in Linux
<geofft> snth: take a look at udev / uevent. Also, see how gnome-mount is implemented
<snth> geofft: udev is what I was looking for .. thank you very much.
<snth> So, I am new to contributing to ubuntu .. and would like to start with some simple bug fixes.
<snth> Looking at launchpad .. I may be interested to learn about Apport, hence I'd like to help in Bug #354188:
<ubottu> Launchpad bug 354188 in mysql-dfsg-5.0 "Add apport hook to gather relevant information" [Wishlist,Triaged] https://launchpad.net/bugs/354188
<snth> This report is public
<snth> But I don't know what's the steps to apply for a mentor (If I need any) .. etc. Can someone help me with this?
<foxbuntu> snth, you dont need to apply for a mentor, if your willing to jump in grab the latest source branch for the affected package, attempt to fix it, then you can push to your own LP branch and propose it to be merged to the upstream branch..
<soren> Is there an IRC channel for UDS?
<StevenK> soren: #ubuntu-devel-summit
<soren> StevenK: Ah.
<soren> StevenK: Ta
<soren> Ah. Turns out I never left since last UDS :)
<ScottK> soren and StevenK:  Thanks.  I had the same question.
<StevenK> soren: Bwaha
<stefanlsd> https://wiki.ubuntu.com/UDSKarmic/RemoteParticipation    - also useful
<robbiew> #uds-foundations is: Ubuntu Developer Summit - Foundations Track
<Usama> hello, I wonder how could I add mirro to the update mirror?
<Usama> Saudi Arabia mirror is listed here https://wiki.ubuntu.com/Mirrors
<Usama> but no choice to download from it in the server choce menu
<Usama> chose
<persia> Usama, Try#ubuntu-mirror
<Usama> #ubuntu-mirror
<persia> heh :)  As a channel.
<Usama> yeah but no one their
<Usama> there
<persia> My mistake.  It's #ubuntu-mirrors
<ion_> Darn, i missed mvo again.
<thiebaude> hi everyone
<Elbrus> infinity: ping. Could you help with bug 67544?
<ubottu> Launchpad bug 67544 in fpc "PPC build of fpc fails" [Undecided,Confirmed] https://launchpad.net/bugs/67544
<Elbrus> fpc needs bootstrapping on ppc and lpia
<LordMetroid> I am noticing that some presentations on the development summit is being videotaped, are they going to be released?
<thiebaude> LordMetroid: after UDS someone said earlier on here
<LordMetroid> cool
<thiebaude> yep
<ion_> http://videos.ubuntu.com/uds/ (but it seems to be down at the moment)
<thiebaude> thanks ion_ for the link
<andersk> Are there any plans to get Subversion 1.6 into Karmic?
<zMoo> is the debian/watch mendatory for Ubuntu packages?
<directhex> no, but it's damn useful
<zMoo> yes, but there is no version number in the filename of the upstream tar.gz :(
<zMoo> does anybody knows where I could find a text version of the Creative Commons BY (U.S 3.0) license... I can only find the legal code in .html format
<NCommander> ScottK, ping
#ubuntu-devel 2009-05-26
<vorian> er... alsa-base is borked
<owen1_> is there a problem with xubuntu cd? i get segmentation fault when trying to burn it.
<owen1_> i did a checksum and I tried burning with brasero and xfburn but get errors. any clue?
<anilg> is there a command to list all the packages available? dpkg -l only lists installed packages
<vorian> <tab>
<vorian> display all 36085 possibilties?
<vorian> NO!
<anilg> wanted something I can use in a script.. so o/p of some command would be helpful
<anilg> one workaround is 'apt-cache search a' .. since the letter a is in all the packages or it;s description
<Rail> apt-cache pkgnames?
<cyphermox> search a will be missing some
<anilg> Rail: pkgnames also shows non-existant packages, (but referred to by other packages)
<anilg> apt-cache search ""  game me what I was looking for .. all binary packages in the repo
<anilg> Thanks for the help
 * calc doing another build hoping that the ooo-l10n rosetta stuff is unbroken now
<calc> TheMuso: are you aware of the alsa-base failure to install in karmic?
<calc> TheMuso: for 1.0.20+dfsg-1ubuntu1
 * cjwatson looks around for an MIR reviewer
<infinity> cjwatson: I'm not an MIR reviewer, but I play one on TV.
<cjwatson> unionfs-fuse bug 379952 kthxbye
<ubottu> Launchpad bug 379952 in unionfs-fuse "Main inclusion request: unionfs-fuse" [Undecided,New] https://launchpad.net/bugs/379952
<infinity> cjwatson: I'm making doko do it, since he refuses to add me to the MIR team without pitti's approval. :P
<infinity> cjwatson: (Looks good to me, though)
<cjwatson> infinity: heh
<cjwatson> thanks
<joekluse> hello?
<joekluse> Is this a good place to ask about video drivers?
<doko> cjwatson: infinity won't have an excuse after this session anymore
<joaopinto> joekluse, if it's a support question, the proper channel is #ubuntu
<joekluse> thanks
<slangasek> hmm, why does "conffile move recipe" not give any useful google results
<infinity> slangasek: Result 1 of 1: steal from another package.
<slangasek> infinity: which package? :)
<infinity> slangasek: initramfs-tools might be okay.
<infinity> slangasek: (Moved stuff from /etc/mkinitramfs to /etc/initramfs-tools)
<seb128> slangasek: http://www.dpkg.org/dpkg/ConffileHandling
<slangasek> infinity: given that I don't see the handling being done in the preinst, I'd go with 'no'
<infinity> slangasek: I make no guarantees that it's correct, but I don't recall any horrible critical bugs being filed.
<slangasek> seb128: does dpkg.org exist again?
<seb128> slangasek: works here
<infinity> slangasek: I see mangling in the preinst...
<slangasek> ah, cool
<infinity> initramfs-tools.preinst:		if [ -d /etc/mkinitramfs ]; then
<infinity>  ....
<slangasek> infinity: mm - but no 'mv', so that's not what I would expect for a conffile handler
<infinity> slangasek: We move the directory, rather than the file, but after verifying files and avoiding spurious conffile prompts.
<slangasek> anyway, the dpkg.org one looks right :)
<slangasek> also, my use case seems to pathologically not be a conffile
<slangasek> so nevermind
<infinity> \o/
 * hyperair pokes dtchen 
<hyperair> dtchen: could you do something about alsa-base's preinst script?
<hyperair> ah wait
<hyperair> nevermind
<hyperair> looks like it's done
 * hyperair whacks his outdated mirror
<TheMuso> hyperair: a fix was uploaded an hour or so ago
<TheMuso> hyperair: ah you found it, ok then.
<slangasek> the irda-utils maintainer scripts are sapping my will to live
<Kano> hi, does anybody like to package httpfs to allow network booting from http server
<Kano> i already tested it, it boots even via internet
<directhex> sigh. okay, who do i poke to access something on the ubuntu bit of google docs?
<directhex> if i click login, it forces "@ubuntu.com"
<Laney> sekkrit docs?
<hyperair> directhex: but you're a motu, don't you have @ubuntu.com?
<directhex> hyperair, it doesn't openid it, i don't have anything googly with @ubuntu.com
<hyperair> launchpad?
<thiebaude1> hi folks
<dtchen> hyperair: should be fixed
<hyperair> dtchen: yes, i realized.
<hyperair> i'll just wait for the mirror here to update
<ogra> slangasek, poke
<directhex> hyperair, google docs does not authenticate using launchpad. it needs a google account with the appropriate email address/j #uds-desktop
<directhex> gah
<hyperair> heh
<calc> doko: ping
<pedahzur> Today, after resuming from a hibernate (Jaunty) I didn't have my usb devices. Upon plugging USB devices, syslog shows: vmap allocation failed: use vmalloc=<size> to increase size.  This is running the kernel in -proposed, 2.6.28-12-generic #43-Ubuntu.  The only bug I could find referencing that message had to do with ath5, so I take it this is not a known issue?
<pedahzur> Found one post related to Jaunty, but not having to do with USB: http://blog.unitedheroes.net/archives/p/3588/got-my-nvidia-card-working-under-ubuntu/
<pedahzur> bug filed
<LordMetroid> Yes, sometimes the external USB HDD doesn't mount on startup...
<LordMetroid> Easily fixed by cutting power to it and reinsterting it. Annoying though
<LaserJock> is there any policy about using PPAs for -proposed testing?
<hyperair> never heard of any such policy
<LaserJock> hmm, I've some SRUs I'd like to push through but I'm not sure if I can get testers to use -proposed
<tyvek> hey, i just upgraded to jaunty. i have a dm-crypt/luks drive on external media that gets prompted for unlocking at boot which is good, but i noticed that the boot console (ctrl-alt-f8) is echoing my password
<tyvek> i've tried googling to see if this is a known bug, but i cant find anything
<geofft> sounds tangentially related to bug #104602
<ubottu> Launchpad bug 104602 in sysvinit "root password visible at emergency console" [Medium,Triaged] https://launchpad.net/bugs/104602
<tyvek> yeah, it's not getting saved anywhere, but it is momentarily exposed on the boot console
<geofft> the bug basically being that something odd happens to stdin/stdout of things sufficiently early in the boot process
<tyvek> #288408 looks similar
<geofft> and therefor stty -echo or whatever doesn't work.
<tyvek> is there a known workaround?
<tyvek> or am i just going to have to mount these post-boot for a while?
<Justin10ec> Hi there, this is the developer channel, right?
<hyperair> for ubuntu development, yes
<Justin10ec> Alright, I have an idea for ubuntu that may help in the development project but I first need to know something. Is there a feedback system in place for betas/alphas? If it's just on IRC and Forums, I have a great idea.
<tyvek> geofft: thx for the help
<Justin10ec> Well, I think a lot of Ubuntu users come from Windows, right?
<Justin10ec> Those users, and apple users alike are used to sending support ticket type things.
<Justin10ec> If we had an offical form for them to fill out, we may get more information. Most likey, people in general are not familiar with IRC or forums?
<Justin10ec> If anyone likes the idea, I'd be more than excited to help with it?
<Laney> are people coming straight from windows the best people to be running alphas and betas?
<Justin10ec> No, and it wouldn't have to just be for the betas, just for general suggestions / questions?
<Laney> we have lots of support avenues already
<Laney> perhaps you would want to make a better interface to one of those?
<Justin10ec> Could you direct me to one of these? I'd like to see what could be improved?
<geofft> Justin10ec: there's Launchpad, and some interface for questions as opposed to bugs
<Justin10ec> I totally forgot about Launchpad!
<Laney> Launchpad Answers, forums, Brainstorm (for suggestions), IRC, ubuntu-users mailing list
<Justin10ec> Other than helping with problems with software and hardware, what could I do to help Ubuntu? I'm great with software, yes, but I much rather enjoy other things like forum management or something like that.
<Laney> http://www.ubuntu.com/community/
<Laney> see what takes your fancy
<Justin10ec> Documentation Team... Would this include rewritting things so that they make better since? Proofreading, grammar, spelling, etc?
<Justin10ec> sense*
<Laney> I guess so
<Laney> they probably have an IRC channel
<Pici> #ubuntu-doc
<Justin10ec> Thanks :)
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down from 22:00 UTC until 23:00 UTC for a code update | Archive: Open for development | Karmic alpha 1 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<NCommander> calc, ping, where is this KDE4 patch for OOo
<Riddell> NCommander: it's in the source package (which is a tar within a tar or something)
<Riddell> NCommander: shtylman is looking at it too
<NCommander> Ah
<NCommander> Riddell, I'd like to do something to help improve KDE this cycle :-/
<calc> NCommander: look in the source
<Riddell> NCommander: he may well not succeed, it's an elite task
<calc> NCommander: specifically under
<Riddell> NCommander: KDM guest session patch! :)
<calc> NCommander: ooo-build/patches/ooo300/apply (there is several KDE 4 patches in a KDE 4 target)
<calc> NCommander: its currently not set to be used but the patches are there
<TheMuso> dtchen: your alsa-driver changes uploaded.
<cellofellow> quick Q, not sure if it's the right place but figured I'd try. How do I enable the Bazaar Nautilus plugin? I installed bzr-gtk and nautilus-python, but nothing.
 * calc thinks the alsa guys broke it on purpose because karmic was too stable ;-)
<ScottK> cellofellow: #ubuntu for support or maybe #bzr.
<cellofellow> ScottK: yeah, just found #bzr, thanks
 * calc hates Sun
<calc> closed bug won't fix for conflicting shortcuts with gtk
 * calc will be glad once OOo is wringed from their control and is taken over by sane community people
<directhex> calc, careful, that kind of talk gets you tarred & feathered by boycottnovell
<calc> hehe
 * calc should keep a list of braindead bug closings for the next time Sun asks me what they should be doing to help out Ubuntu
<calc> they basically told me to fork OOo to make it work correctly, yet also want me to run vanilla OOo in Ubuntu
<calc> they are insane
<directhex> evand1, non-a11y banshee widget 1 of 5 is now patched (but untested) by upstream
<ajmitch> directhex: but boycottnovell always have responsible, accurate reporting
<directhex> ajmitch, and soft, soft t-shirts
<calc> my anti-redhat shirt violates the CoC so i can't wear it :\
<ajmitch> that's hardly fun
<evand1> directhex: AWESOME!
<ion_> calc: :-D
<Viper550> whoa whoa whoa...no english language support.
<Viper550> soren, kernel mode switching
#ubuntu-devel 2009-05-27
* mthaddon changed the topic of #ubuntu-devel to: Archive: Open for development | Karmic alpha 1 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<qwerty6523> helllo
<hyperair> does anyone notice that gnome-power-manager no longer recognizes the presence of notify-osd?
<druid_of_system> hi everyone
<techman2> hello
<chrisccoulson> hi mbiebl - you there?
<mbiebl> chrisccoulson: yeah
<chrisccoulson> mbiebl - i'm just looking at the changes in the tracker-store-queue branch of tracker at the moment, and now that all the crawling and monitoring is gone from tracker-store, do you intend to split tracker-indexer in to it's own separate package when the changes make it in to 0.7.0?
<chrisccoulson> it's possible to run tracker-store without tracker-indexer now
<mbiebl> chrisccoulson: it might be useful for people only wanting to use the metadata store
<mbiebl> without the indexer
<chrisccoulson> mbiebl - yeah, thats what i was thinking
<mbiebl> but imho it's to early to do the split on the packaging side already
<mbiebl> as things are moving too fast atm
<chrisccoulson> yeah, i agree. i was just thinking about the packaging though
<mbiebl> who knows, if it's still called tracker-store in a month ;-)
<chrisccoulson> mbiebl - yeah ;
<chrisccoulson> ; => ;)
<chrisccoulson> i think if the split stays as it is it would definately make sense to split the indexer and extractors off in to their own package, so people can run the metadata store without the indexing
<mbiebl> agreed
<dtchen> kees: ping, i see you merged cryptsetup for karmic. can we mark bug 324871 fixed? (currently in the encrypted swap session discussing LUKS keyslots)
<ubottu> Launchpad bug 324871 in cryptsetup "cryptsetup: Cannot delete a Keyslot from itselfs" [Unknown,Fix committed] https://launchpad.net/bugs/324871
<TheMuso> i/c
<bigon> could someone have a look at https://bugs.edge.launchpad.net/ubuntu/+source/gucharmap/+bug/375892 ?
<ubottu> Ubuntu bug 375892 in gucharmap "-dev package has been renamed in debian" [Undecided,New]
<chrisccoulson> bigon - yeah, i noticed that a few days ago when i rebased gnome-applets on debian
<chrisccoulson> i had to adjust the build depends to get it to work
<bigon> chrisccoulson: shouldn't be more intresting to rename the -dev package of gnucharmap?
<chrisccoulson> possibly - but isn't the debian package name bogus. why would it be libgucharmap2-dev?
<bigon> http://packages.debian.org/changelogs/pool/main/g/gucharmap/current/changelog
<chrisccoulson> where does the '2' come from?
<bigon> - Rename libgucharmap-dev to libgucharmap2-dev, as the pkgconfig file
<bigon>        has been renamed (and the /usr/include directory) and packages need
<bigon>        porting.
<chrisccoulson> ah, i see
<chrisccoulson> bigon - i suppose gucharmap should probably be rebased with debian. that hasn't happened for quite some time it seems
<bigon> chrisccoulson: ok I will have a look at that tonight or during the weekend
<chrisccoulson> bigon - i don't mind doing that if you don't get a chance to do it
<bigon> oh ok I'm quite buzy right now so no problems
<fakker> hey all i need some help with usb gadget and dummy_hcd can some one help me or let me know where can i find info about them ?
<siretart`> fakker: see topic, use #ubuntu for user support
<stefanlsd> wgrant: Using xserver-xorg-input-synaptics_1.1.1~git20090510-1ubuntu1~wgrant1_amd64.deb and it fixes my issue with syndaemon. Do you want me to report that anywhere?
<wgrant> stefanlsd: Here was fine.
<wgrant> stefanlsd: Are you having any movement issues? There's a slightly problematic patch in ~wgrant1 (that I've dropped in ~wgrant2) which was never in the primary archive, but I must have inherited from tseliot's PPA.
<wgrant> It tends to cut out quick movements.
<stefanlsd> wgrant: Not picking up any issues (just a basic user for stopping mousepad after typing)
<nyu> hi
<nyu> I'm afraid I couldn't make it to the GRUB 2 discussion.  I have some answers to the questions in https://blueprints.launchpad.net/ubuntu/+spec/foundations-karmic-grub2  please tell me who should I talk to
<directhex> nyu, cjwatson@debian was leading the talk
<nyu> directhex: don't see him here.  does he still IRC?
<directhex> nyu, yes, in here as cjwatson most of the time
<nyu> kay, I'll be around
<directhex> nyu, or he's generally around
<directhex> after lunch there's a session i want to go to - "Debian Relationship Healthcheck"
<directhex> gah, out of power, down i go
<nyu> directhex: is Colin around IRL?
<nyu> I'm not far from the hotel
<calc> ScottK: can we get boost1.38 into main and kick out 1.37 ?
 * calc uploaded OOo using 1.38 now that it works
<ion_> I really hope this finally happens. https://blueprints.launchpad.net/ubuntu/+spec/rsync-based-deb-downloads
<bedahr> Quick question: whatis the policy of ubuntu on package versions? can snapshots of libraries enter the main tree?
<bedahr> I am asking because portaudios last released version is about 2 years old and very buggy whereas current svn snapshots are quite good
<sgallagh> How does one find out the owner of a package in Ubuntu?
<loic-m> sgallagh: there's no real ownership in Ubuntu
<LaserJock> sgallagh: apt-cache show <package> | grep Maintainer
<sgallagh> LaserJock: thank you
<loic-m> sgallagh: there's also the changelog in case the package is maintained by a team (like MOTU) but you want to see who uploaded the pkg
<calc> ScottK: boost1.38 now in main :)
<calc> ScottK: time to migrate everything over to it and through out 1.34/1.35/1.37 ;-)
<calc> er throw
<ScottK> calc: Excellent.  I have to write the mail to ubuntu-devel-announce.
<calc> OOo is already done and just waiting for boost to be available (depwait atm)
<directhex> calc, what's wrong with maintaining 4 versions of boost?
<calc> directhex: heh funny ;-)
<calc> ScottK: is anything in main still using 1.35?
<ScottK> Yes
<ScottK> calc: KDE still.
<calc> ok
<calc> oh i see
<ScottK> I didn't want to move twice.
<calc> is there a way to show all reverse build-depends with apt-cache (or something similar?
<sistpoty|work> calc: build-rdeps of devscripts perhaps?
<sgallagh> jelmer: Are you the package maintainer for libldb-dev still?
<jelmer> sgallagh, hi
<jelmer> sgallagh, yeah
<jelmer> In Debian that is
<sgallagh> jelmer: I'm trying to assist someone in porting the SSSD to Debian/Ubuntu, but I'm having some trouble with the libldb-dev package. It includes an ldb_includes.h file that is looking for files from libreplace, but that doesn't seem to be packaged (or marked as a dependency)
<jelmer> sgallagh: We need to do a new release upstream I think before Simo's daemon can be packaged
<jelmer> sgallagh, Is it already packaged in Fedora?
<sgallagh> jelmer: Yes
<jelmer> sgallagh: So, we'll have to package a new upstream version but there's only snapshots atm
<sgallagh> jelmer: What do you need (from us, from samba, etc.) to do that?
<jelmer> sgallagh, time, mainly :-)
<jelmer> sgallagh, Ideally I should coordinate with Simo on a new ldb release upstream
<sgallagh> jelmer: The other question I wanted to ask was why there is a separate libldb-samba-4.0-dev package, and why it's both incomplete and has a .pc file that lies. :)
<jelmer> sgallagh: It's there because Samba 4 contains a different version of ldb
<jelmer> sgallagh, the stock version doesn't work with it
<jelmer> sgallagh, I think in Fedora that one is build statically
<sgallagh> ah
<sgallagh> ok, so is there anything I can do to help move along this upstream release (aside from pestering simo)?
<jelmer> sgallagh, the other two issues you mention are upstream bugs that we've since fixed but haven't been packaged yet
<jelmer> sgallagh, Simo and I worked together on this; we've done standalone releases for tdb, talloc and tevent but not for ldb yet
<jelmer> sgallagh, (I'm upstream as well)
<sgallagh> jelmer: Ok, thank you for your help. Let me know if there's anything I can do.
<calc> sistpoty|work: ok thanks
<sistpoty|work> np ;)
<baba_> hello
<baba_> there is someone that can help me modify some things in ubiquity?
<kblin> hi folks
<kblin> is here a tool to make ubuntu join a krb5-domain? I'm trying to come up with an automated way to make samba join an active directory
<sgallagh> kblin: winbind is meant for this purpose
<kblin> no
<kblin> I'm talking about setting up krb5.conf, nsswitch.conf and stuff
<kblin> winbind doesn't change config files
<Awsoonn> is there a way to tell pbuiler to use multiple cpus while building? it seems that it is only using one cpu currently.
<sgallagh> kblin: authconfig
<kblin> sgallagh: what I was wondering if there's an established (GUI) tool to take care of this
<Adri2000> kblin: likewise-open?
<siretart`> wrong channel, in any case
<Adri2000> right
<kblin> Adri2000: well, that's what I want to replace
<sgallagh> kblin: Try authconfig
<kblin> Adri2000: I want to use samba technology, not likewise technology
<kblin> sgallagh: looking at it
<kblin> sgallagh: what packet is that in?
<sgallagh> kblin: I take that back. It may not be available in Ubuntu
<kblin> ok, if there's no one way to do it (tm), I can just come up with my own.. just checking there wasn't an established way I wasn't aware of
<kblin> thanks
<sgallagh> kblin: Well, authconfig would be The Right Way(tm), but it looks like no-one's bothered to package it for Ubuntu
<kblin> sgallagh: well, I can do it the likewise-open way
<kblin> just overwrite the config files with my settings
<maxb> Before DebianImportFreeze, do syncs from Debian unstable happen by cron, or archive admins manually poking something every so often?
<geser> maxb: IIRC by an archive-admin using a script or so
<maxb> LP bug watch has just notified me of a bug fixed in debian, I need to remind myself to go back and verify the ubuntu task on a bug once the next sync happens
#ubuntu-devel 2009-05-28
<billisnice> When will the XPâs Shared Network Printer, and Nvidia non-root permissions be fixed, and the wifi password will not stop asking me for the darn thing? I figured ubuntu folks are trying to android ubuntu and not mess with these fixes. Casual users will get discourage and move on fast.
<bluefoxicy> why does invoking the GTK file picker dialog cause a stall?
<bluefoxicy> the whole application (or thread, probably) hangs for a minute
<hyperair> try changing the theme.
<hyperair> i had a theme that did that once
<hyperair> icon theme i mean
<liw> bluefoxicy, it probably wants to do a bunch of disk i/o and that's the explanation (the real reason would be there's a bug somewhere: it's supposed to do it in the background)
<bluefoxicy> liw:  it happens every time and in any folder that it's going to display.
<bluefoxicy> Pressing printscreen to take a screenshot even has a huge delay for some reason
<lifeless> is evince broken for anyone else?
<liw> lifeless, not on jaunty (I'm not yet running karmic)
<lifeless> liw: tsk tsk :)
<lifeless> I'm getting 'mime type application/pdf not supported' ;)
<liw> lifeless, that's... weird
<ajmitch> lifeless: yes, I saw that also, something with libpoppler & missing symbols
<lifeless> ajmitch: did you file a bug?
<ajmitch> I didn't file a bug given the churn we have at the moment
<ajmitch> & probably because I was in a rush :)
<lifeless> ajmitch: so you'll file one now ?
<lifeless> :)
<calc> NCommander: wow it just worked on sparc now
<calc> NCommander: hopefully it continues to do so
<NCommander> calc, indeed.
<NCommander> calc, and we built itanium livefs
<hyperair> i've a question. why does lib32asound2-plugins conflict with ia32-libs?
 * hyperair pokes TheMuso 
<hyperair> nevermind, i found the bug.
<hyperair> #305860
<hyperair> this is screwing arodun with flash.
<hyperair> or maybe not.
<hyperair> either way there's something going on with the 32-bit libs' pulse plugin for alsa.
<Riddell> kenvandine: able to come to Kubuntu social from the start session after the talks?
<Riddell> you and/or tedg
<TheMuso> hyperair: You pinged me?
<TheMuso> hyperair: In the future, please just ask your question and I will get to it when I am around.
<dtchen_> TheMuso: apparently regarding the lib32asound2-plugins Conflicts ia32-libs
<dtchen_> TheMuso: bug 305860
<ubottu> Launchpad bug 305860 in alsa-plugins "lib32asound2-plugins conflicts with ia32-libs" [Undecided,Fix released] https://launchpad.net/bugs/305860
<TheMuso> dtchen_: what needs doing?
<dtchen_> TheMuso: haven't followed up on the bug; he seemed to be confused with it. "this is screwing arodun with flash...either way there's something going on with the 32-bit libs' pulse plugin for alsa"
<hyperair> TheMuso: yes i pinged you, and i also asked my question, but i answered it myself shortly afterwards.
<slangasek> ScottK: I don't actually see your mail in the mod queue; did someone else approve it?
<ScottK> slangasek: Not that I've seen.  Odd.
<ScottK> I'll double check where I sent it ....
<slangasek> ScottK: sent to u-d-a, right, not u-a?
<ScottK> IIRC yes, but checking.
<ScottK> slangasek: Sent to ubuntu-devel-announce@lists.ubuntu.com
<slangasek> ScottK: hmm - not in the mod queue, perhaps someone did a spam sweep before I got to it
<ScottK> slangasek: I'll resend (as it's not been delivered to me).
<ScottK> slangasek: May 28 11:03:57 mailout00 postfix/smtp[13570]: B2A0738C143: to=<ubuntu-devel-announce@lists.ubuntu.com>, relay=lists.ubuntu.com[91.189.94.204]:25, delay=1.6, delays=0.29/0.08/0.5/0.71, dsn=2.0.0, status=sent (250 OK id=1M9h9A-00059h-W1)
<wip> we need a new release of the kernel-rt for ubuntu 9.04
<wip> unstable and a big bug when cpu1 using 100%: https://bugs.launchpad.net/ubuntu/+source/linux-rt/+bug/374026
<ubottu> Ubuntu bug 374026 in linux-rt "Kernel threads using 100% on one of the two CPUs" [Undecided,Confirmed]
<d-b> hi there i have a question about vim in ubuntu, why is it that installing vim-full doesn't remove /unlink the vim tiny... installed. (9.04 ubuntu).
<d-b> im going to file a bug, but i thought i might ask here as you devs would use vim more than i
<gigi> ciao
<gigi> !list
<ubottu> This is not a file sharing channel (or network). If you're looking for information about me, type Â« /msg ubottu !bot Â»
<bencrisford> BenC2:  =O, theres another BenC?!
<gtlz> who is in charge of jaunty's mysql?
<alex-weej> ( 11.0)           usplash : scan_async (ehci_watchdog)
<alex-weej> why isn't usplash just fast fast asleep while i'm up and running? :(
#ubuntu-devel 2009-05-29
<mib_7vyuq6a0> i couldnt get help in ubuntu channel maybe someone can help me here, does anyone know why i cant get xbindkeys to startup after i login?
<geofft> am I missing something, or is there no MD5SUMS.gpg for the netboot etc. images?
<dholbach> ryanakca: webmaster@ryanak.ca does not seem to work for me
<slangasek> dholbach: of course!  that's the UID on his key that's only there to trick people into signing email addresses he doesn't control
<dholbach> slangasek: super :)
<ryanakca> dholbach,slangasek: IPv6 mailserver. Don't sign it if you don't want
<dholbach> ryanakca: the email address did not work - I tried mailing it
<ryanakca> dholbach: *nod*, my ISP blocks incomming port 25 on IPv4. Do you have an ipv6 connection / mailserver?
<dholbach> no
<dholbach> at least not as far as I know
<dholbach> nevermind then
<ogra> mbiebl, asac would like to talk to you, he is sitting on the sofa in the main hall
<lamont> slangasek: sent
<lamont> slangasek: I'll let you approve it, if you'd be so kind
<yosch> ArneGoetje: what gobby document are you using for the second fonts round table?
<ArneGoetje> yosch: same as the first one. karmic-font-issues-roundtable
<yosch> ArneGoetje: got it, been adding some more stuff
<yosch> ArneGoetje: it's a bit hard to follow the audio discussion: I mostly hear the aircon
<ArneGoetje> yosch: aircon has just turned itself off
<yosch> ArneGoetje: great, better now
<ArneGoetje> yosch: copied the document to the blueprint
<yosch> ArneGoetje: great, thanks
<yosch> ArneGoetje: will followup later
<yosch> ArneGoetje: gotta go now, bye :-)
<ArneGoetje> yosch: thanks, bye
<slangasek> ryanakca: eh, my mail goes out through an IPv6-enabled host :)
<ion_> liw: I read âThe apt-sync package is now included in Ubuntu and will make upgrades fasterâ skimming through https://wiki.ubuntu.com/AptSyncInKarmicSpec only to realize itâs just a future release note. What a disappointment. ;-)
<liw> ion_, no worries, you can help make it true :)
<ion_> liw: Iâd like to help, actually.
<liw> ion_, good. see the spec and add any comments you have, and ping me after Jun 9 when I come back from vacation :)
<ripps> I'm trying to add an --extraversion variable to package with it's git version. I've stored the version information in debian/git-version. But when I try to parse it with 'cat debian/git-version' the pbuilder just tells me "cat: debian/git-version: No such file or directory" what am I doing wrong?
<ripps> I used to have this working when I had git-version in the source directory, but when I moved it to debian/ it stopped working. Why?
<mib_7t56th40> hello
<mib_7t56th40> i would like to help package eclipse 3.4.2
<mib_7t56th40> what may i do to help?
<maxb> mib_7t56th40: Are you experienced both in packaging and in the eclipse buildsystem? If not, please be aware that this is a deeply complex problem that has defeated many people already, and you may wish to pick an easier package to help with.
<ScottK> mib_7t56th40: Also #ubuntu-motu is a better place to look for someone to discuss that.
<mib_7t56th40> No, I'm not.  I'm willing to learn
<mib_7t56th40> Okay. Thanks, ScottK
#ubuntu-devel 2009-05-30
<Caesar> slangasek: I found the problem: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/381753
<ubottu> Ubuntu bug 381753 in dpkg "Handling of conflicting conffiles broken" [Undecided,New]
<billisnice> what is up with jerky youtube in full screen mode? I did not get this with 8.04.
<snadge> how do i force distcc on x86_64 to build with -m32 ?
<snadge> stuff it, i'll use a 32bit chroot its too annoying to figure it out
<quadrispro> hi! I tried to upload some pkgs, but I received this: "Connection failed, aborting. Check your network [Errno 111] Connection refused"
<quadrispro> anyone can help me?
<TheMuso> quadrispro: It could be a result of the launchpad downtime, in that they forgot to bring up the ftp server for uploads. You should check with the launchpad folks in #launchpad to be sure.
<TheMuso> I can't think of anything else that could be the problem.
<quadrispro> thanks TheMuso
<askand> Is it possible that the compiler in Jaunty has changed in a way that does not play nice with my hardware, and therefore I get >10 different apps segfaulting for me every hour compared to Intrepid where that never happened.
<askand> Or is this far-fetched?
<TheMuso> askand: You've checked that your hardware is ok, i.e run an earlier distro version, run memtest, etc?
<askand> TheMuso: Yep, it was the same hardware as in Intrepid and I ran memtest for 24 hours without errors
<askand> I find it hard to believe that all these apps suddenly have become extremly crashy since Intrepid.
<TheMuso> Well I have no idea I'm sorry
<askand> TheMuso: Ok, neither do I :( Anyone else in here have an idea?
<jussi01> askand: is it an upgrade or a clean install?
<askand> jussi01: clean install
<jussi01> hrm, Ive seen issues from users on upgrades...
<jussi01> no idea from me either.
<askand> thnks anyway :)
<jussi01> oh askand, I assume of course you checked md5 of the iso etc?
<askand> yep :)
<TheMuso> jussi01: If the md5 was wrong, I think things wouldn't have installed properly/the squashfs filesystem would have thrown errors on the live CD, assumging a live CD was used.
<ghindo> Where are all the documents on gobby.ubuntu.com?  I thought a bunch of documents were supposed to be up from UDS, but I'm not seeing anything.
<askand> ghindo: have you installed gobby?
<ghindo> askand: Yes.
 * TheMuso checks the server.
<ghindo> I'm probably just overlooking something, but I wanted to double-check
<ghindo> :p
<TheMuso> seems fine here
<TheMuso> I can see many a document on the server.
<stefanlsd> upload.ubuntu.com ftp seems to be down. Anyone able to check?
<elmo> stefanlsd: fixed
<stefanlsd> elmo: thanks!
<raboof> which package contains the default /etc/group? (dpkg -S and apt-file aren't helping yet)
<infinity> raboof: base-passwd
<ion_> grep /etc/group /var/lib/dpkg/info/*inst (and now please read the topic)
<infinity> ion_: Haha.  Nice.  That exposed a "grep that should be a getent" bug over here. :)
<ion_> infinity: Noticed two myself. :-)
<ion_> sysklogd and icecc
<infinity> Oh well.  I vaguely recall a "make sysklogd go die" session somewhere in the blur that is the last week.
<infinity> So, maybe I'll just ignore it and carry on with my day.
<ion_> I wasnât fortunate enough to attend UDS, but i did skim through all the interesting specs (read: most of them) linked from the schedule. :-)
<infinity> ion_: Hey, I was there, and I don't remember what most of them were, so you'e doing better than me. :)
<ion_> Hehe
<infinity> (To be fair, I remember most of the ones I participated in, at least)
<infinity> I suppose this is why we take extensive notes.
<infinity> So, when someone says "Hey Adam, you remember that stellar idea you had for the installer turning people's computers into paperweights?", they can back it up with evidence.
<ion_> :-)
<marcosRz> thanks for you guys for interfering into X project and turning into shit
<marcosRz> fuck ubuntu
<azeem> marcosRz: this is an development channel
<marcosRz> ubuntu devs interefed on the X project causing them to disable ctrl alt backspace
<marcosRz> for the n00bs
<azeem> whatever, this is off-topic here
<marcosRz> https://wiki.ubuntu.com/XorgCtrlAltBackspace/Discussion
<azeem> I am sure you are smart enough to patch that back in
<marcosRz> see
<marcosRz> :P Actually the disabled dontzap
<marcosRz> *they
<hyperair> please take this up with the people in #ubuntu-x
<hyperair> this is not the right channel.
<marcosRz> thanks
<jussi01> marcosRz: and please, watch the language
<marcosRz> I just so pissed that ubuntu is interferring in all open source projects
<marcosRz> I dont have anything against ubuntu, only the with the devs that made this interference
<infinity> marcosRz: We're not "interfering", we're customizing for our users.
<infinity> marcosRz: And please be civil.
<marcosRz> this interference propagates on all project that use X
<infinity> marcosRz: http://www.ubuntugeek.com/howto-enable-ctrl-alt-backspace-in-ubuntu-jaunty.html
<infinity> marcosRz: And, again, we didn't "interfere" with anything, we didn't force upstream to take the change (like we could), the hostility is not needed.
<marcosRz> infinity, actually the current X has disabled the dontzap trick, thats why I'm pissed
<marcosRz> I'm running Arch and they disabled the dontzap feature, so we cant restart X by ctrl-alt-bkspce
<marcosRz> infinity, http://bbs.archlinux.org/viewtopic.php?id=73064&p=2
<azeem> marcosRz: so ask the arch guys to fix this
<azeem> this is off-topic here
<ion_> Whatâs wrong with exiting X the normal way anyway? :-P
<marcosRz> azeem, I know we already did it a patch, but I'm pissed that this utility feature will not be available by default into most linux distros, and this is due to protect the newbies
<azeem> marcosRz: I think you've been told enough times now that this is off-topic
<marcosRz> ok
<cockroach> hi. no idea whether this is the right place to ask, but i'll try: i am maintaining a debian package (not in debian yet) using cdbs with pysupport. this works fine on debian but apparently not on ubuntu (a user just sent me this: http://yfrog.com/1566939906p) - any idea?
<cockroach> (packaging files can be found at http://episoder.svn.sourceforge.net/viewvc/episoder/debian/)
<pochu> cockroach: did he tried to install the Debian package directly, without rebuilding it in an Ubuntu environment?
<cockroach> pochu: yes, afaik
<pochu> it could be that it was built using a recent pysupport version in Debian, that is not compatible with his pysupport
<pochu> but that's just a guess
<cockroach> interesting point, didn't think of that. it was built on debian testing, i'll have a look at the changelog...
<azeem> cockroach: Debian packages should not be installed on Ubuntu and vice-versa, really
<cockroach> azeem: i figured a python package should work since it's not compiled & stuff :)
<cockroach> azeem: but i guess i'll have to create an ubuntu pbuilder environment and create *proper* ubuntu package...
<cockroach> (*a* proper package, even)
<pochu> does your package depend on ${python:Depends} ?
<cockroach> pochu: no, only ${misc:Depends} (and some hard-coded ones)
<pochu> so that's your bug
<pochu> see man dh_pysupport
<cockroach> pochu: oh, indeed. thanks!
<pochu> anyway, it's not a good idea to install packages built on different environments
<pochu> yw
<pochu> btw, if you want to get your package in Debian, there's #debian-python on OFTC (when it's in Debian it will reach Ubuntu too)
<cockroach> pochu: ah nice, i'll talk to them. i sort of doubt that anyone is going to sponsor this, but asking can't hurt :)
<ion_> Google Wave seems like an awesome tool. You know how people edit stuff in Gobby at UDS and then manually move the content to wiki.ubuntu.com? With Wave, wiki.ubuntu.com and the collaborative realtime editing application could be the same tool.
<ghindo> It's not even out yet though, right?
<ion_> Indeed. I only watched the demo.
<htrejh> hi
<htrejh> in my control file, when i use a different name for package it creates a deb with missing files (except NEWS...), but not when package and source are identical, why?
<htrejh> anyone?
<LaserJock> htrejh: do you have a debian/install file?
<htrejh> LaserJock: no
<LaserJock> htrejh: you might want to create a <binary name>.install file
<htrejh> empty file?
<htrejh> i dont understand
<azeem> why empty?
<htrejh> what must it contain?
<azeem> see the dh_install manpage
<azeem> basically a list of files you want to include in your package, and which is not otherwise included (e.g. via NEWS via dh_installdocs)
<htrejh> can you generate the list?
#ubuntu-devel 2009-05-31
<gauge> hey.  I'm having a kernel panic I beleive.  w/ my wireless on, my system will freeze after a few min, leavign the capslock light blinking
<gauge> I apt-get installed the iwl4965 drivers and I beleive i have the latest ones...
<gauge> I'd love to try and resolve this.
<cbo> hi
<cbo> I wrote a little patch for 2.6.28 kernel, it has been accepted by the lnux kernel team and is now part of 2.6.30. Is there any chance to have it already applied on Jaunty's kernel ?
<pwnguin> cbo: #ubuntu-kernel may be more appropriate for discussing patch inclusion
<cbo> ok, I already posted the same message to the #ubuntu-kernel channel but got no answer yet ;-)
<pwnguin> but what you're looking for is a Stable Release Update (SRU), and has rules to be satisfied before consideration
<pwnguin> first, it must be in ubuntu+1 (karmic)
<pwnguin> second, it should have a launchpad bug report
<cbo> The patch do just add one USB product id, there is no logic modification. So it's really safe.
<pwnguin> the kernel team is a smaller group of people, who may not watch IRC like a hawk
<pwnguin> if you tire of waiting for a response, I'd suggest mailing the ubuntu kernel team Mailing List
<cbo> ok, i'll be patient and fill a bug report.
<pwnguin> https://wiki.ubuntu.com/KernelTeam/KernelUpdates also applies
<cbo> I'll have a look at this
<cbo> If someone is interested in having a fully useable Logitech G25 wheel, you can have a look here : http://wiki.vdrift.net/Logitech_G25_support and http://wiki.vdrift.net/Enabling_force_feedback_in_kernel
<cbo> There is already a bug report for the G25 wheel (https://bugs.launchpad.net/bugs/181361). I'll post a comment.
<ubottu> Ubuntu bug 181361 in linux "Logitech G25 does not fully work with Ubuntu" [Undecided,New]
<cbo> ;-)
<htrejh> hi
<htrejh> i need some help packaging my program
<htrejh> so the name is gfire, the src dir is named gfire too, but we would like to see it named pidgin-gfire for the package system, how do you do that?
<htrejh> i see it creates a dir named "gfire" in debian/ so it should be pidgin-gfire, right?
<htrejh> so i tried with package: pidgin-gfire and source: gfire, but it fails
<iulian> htrejh: Please join #ubuntu-motu for packaging questions.
<htrejh> ok, my bad didn't know
<htrejh> but it's a personal package
<htrejh> not for inclusion in ubuntu
<iulian> It doesn't really matter whether is a personal package or not, packaging questions ought to go in #ubuntu-motu.
<Lutin> Riddell: I'm a bit curious about your eet 1.1.0+svn35608-0ubuntu1 upload ... 1.1.0 was released on r36234
<tgpraveen_> hi are there any plans to make patches for empathy
<tgpraveen_> so that it attains feature parity with pidgin
<tgpraveen_> before putting it in karmic ?
<azeem> tgpraveen_: are you talking about upstream development?
<azeem> maybe you should engage the empathy authors if you want to help
<tgpraveen_> azeem: well since karmic is going to replace pidgin and it still lacks some features over it
<tgpraveen_> i wanted to know if there were plans to add some patches etc
<tgpraveen_> i mean at uds was something like this discussed>
<tgpraveen_> ?
<azeem> dunno, I wasn't there
<azeem> I guess the desktop team will assess which features, if any, would be blockers if not implemented in empathy
<Lutin> Riddell: to me, it looks like you pretty much reverted eet 1.1.0 to eet 1.0.1, that seems really really weird
<askand> Is it possible to read from backtraces if the error is in the application or in the hardware of the user e.g ram-memory?
<persia> askand, Not really, although one can sometimes guess based on context.
<askand> persia: I see, thanks
<askand> Here are two traces I've collected http://launchpadlibrarian.net/27330457/trace.txt and http://pastebin.com/m17f6c698
<ripps> Are there any sed experts who can help me figure out how to replace a line "Author: Name LastName <email>" with "[ Name LastName ]". I've gotten close, but I can't figure out how to remove email and bracket the end.
<Lutin> ripps: sed -r 's,.*: (.*) (.*) <.*>,[ \1 \2 ],' might do the trick
<ripps> Lutin: the guys in #sed are helping me, and it turns out the bigger picture is more complicated
<Lutin> mostly depends on what you're actually trying to parse
<pwnguin> there is an actual email regex
<pwnguin> it is the stuff of nightmares
<pwnguin> just use antlr and call it a day
<jayandgina> Hi there
<jayandgina> Compiz Frustrations abound after upgrading to 9.04
<hyperair> jayandgina: you should have read the release notes. i believe the performance regression was a very major issue in 9.04. i'm not sure it's still around, but i'd reckon a guess that it is
<jayandgina> bummer :(
<jayandgina> hyperair: Any idea how i downgrade to the previous version?
<hyperair> jayandgina: there's a PPA containing the package xserver-xorg-video-intel-2.4
<hyperair> jayandgina: ify ou add that PPA and install that pacakge, it will uninstall the new and install the old
<hyperair> jayandgina: dig around in the ubuntu-devel archives for it.
<jayandgina> where do i find it?
<hyperair> google.
<persia> Well, since it's likely to be a post from april or may, lists.ubuntu.com might be just as good.
<hyperair> mmmhmm
<hyperair> i remember it appearing before jaunty's release
<hyperair> which means april
<jayandgina> Oh my... it's a little overwhelming trying to find this :(
<jayandgina> hyperair: what do i do when i find it?
<jayandgina> How do I downgrade to a previous graphics driver??
<persia> jayandgina, Firstly, this isn't a support channel (try #ubuntu).  Secondly, it's decidedly nontrivial, as the modern drivers sometimes have kernel interactions.
<jayandgina> Persia: Thanks
<bryce> jayandgina: https://wiki.ubuntu.com/ReinhardTartler/X/RevertingIntelDriverTo2.4
<loic-m> jayandgina: or you might create another partition, and install Ubuntu 8.10 on it, and use it till you can be sure your 9.04 suits you, or till 9.10 arrives (and I advise keeping 8.10 while testing either 9.04/9.10)
<ripps> Can someone help figure this out? I'm making a specialized debian changelog script, and I've got most of it finished, except I can't figure out to import my gather changelog information into dch. dch doesn't seem to allow file imports, so how can I get it work?
<persia> ripps, `dch $(echo $(cat foo))` might do it, or perhaps `sed 's/^/dch /' < foo`
<ripps> persia: nope, neither worked, the added the file, but it ignored formatting and added the names of every subdirectory. the sed method did nothing
<bluefoxicy> no gtk updates today?
<calc> i would be surprised if there are much updates today at all since many people are in the process of returning home from UDS
<calc> or are recovering from their flight home, heh
<bluefoxicy> calc:  it takes 27 seconds for the Open dialog to open
<bluefoxicy> the whole application stalls that long, then the window appears
<calc> the general gtk open dialog in anything, or what?
<bluefoxicy> Music->Import File in rhythmbox
<bluefoxicy> Add attachment in Thunderbird
<bluefoxicy> Browse for a file upload form in Firefox
<calc> oh hmm, it seemed to work ok for me before i started doing a reinstall
<calc> i had to do a reinstall because my drive appears to be failing
<bluefoxicy> :|
<bluefoxicy> i'm on a 64 bit install
<calc> i'm still backing it up at the moment then will be scanning the whole drive for bad sectors and trying to force a remap
<calc> i was too, until earlier today, will be reinstalling 64bit once i get my drive fixed
<calc> bluefoxicy: hmm do you have a loopback interface enabled, sometimes apps have weird issues if it is missing
<calc> not sure if that applies for this case
<bluefoxicy> yeah
<calc> ok, then i am not sure what would be causing the issue, you probably should file a bug if one isn't already filed about the issue
<calc> backing up 130GB over USB is really slow :-\
<calc> shtylman: hi
<shtylman> calc: hi
<calc> shtylman: how are things going :)
<shtylman> calc: quite good...waiting for OOo to build :)
<calc> cool, i'm having to test my laptop hd and reinstall, having bad sector issues with it
<calc> so i won't have email access for a while (maybe later today/tomorrow)
<shtylman> ouch
<shtylman> get a new drive?
<calc> i might i need to see if this one will just remap and work
<calc> if it doesn't i need to RMA it, its a seagate momentus 7200.4 500gb and was really new when i got it so might not have had all the bugs worked out yet
<shtylman> ahh gotcha
<shtylman> yea...I would RMA...wouldn't take the chance with my data :)
<calc> generally drive manufacturers require their app to report it needs RMA before they will accept one, which is why i am going to test it and see first, having to back it up over usb which just finished after ~ 3hr
<calc> luckily i only had 130gb on it
 * calc wishes his laptop had esata
<shtylman> heh
<dupondje> how to get a new version of a package into karmic ? :)
<directhex> calc, i wish my laptop had >1 usb instead of an esata port
<mohbana> i find that ubuntu fails to load up when i plug any sort of device into the usb slots of the monitor
<mohbana> it wuold happen to fedora as well, although i've stopped using it so i can't verift if it still exists
<mohbana> how can i debug it
<mohbana> anyoone?
#ubuntu-devel 2010-05-31
<blue_anna> libtool does :) compiled fine now
<LLStarks> hi. how do i tag a bug requesting a package update?
<crimsun> LLStarks: in .35? Should not be cause for alarm.
<psusi> damn.... finally... got the new extent based mapping code working in e2defrag so instead of needing a gig of ram to map a 400 gig disk, it only needs 255 megs
<psusi> only took me all week to get it working right...
<psusi> blasted double binary tree forward and reverse indexes...
<ion> :-)
<Chipzz> psusi++ :)
<psusi> testing on a 1.3 tb volume now ;)
<psusi> hrm... now the allocation bitmaps are becoming a problem... need to do away with those....
<pitti> Good morning
<ajmitch> ls -la
<ajmitch> oops :)
<\sh> moins
<\sh> pitti / doko: who is already awake and could point me to the changes in our default compile settings of maverick toolchain?
<pitti> \sh: I don't know, I'm afraid
<\sh> pitti, good morning :) well, then I'll wait for doko :)
<geser> \sh: I've read on planet that maverick optimizes for 686 (-m686) on i386 now.
<dholbach> good morning
<hrw> geser: yes, thats true
<pitti> hey dholbach
<\sh> geser, yes..but I wonder what changed on amd64 because of this bug #585291
<ubottu> Launchpad bug 585291 in giggle (Ubuntu) "Merge giggle 0.5-1 (universe) from Debian unstable (main) (FTBFS on maverick amd64)" [Wishlist,In progress] https://launchpad.net/bugs/585291
<dholbach> hey pitti
<\sh> or in other words, something strange happens on autotools front..because some values are not replaced correctly
<RAOF> \sh: Does it build on i386?  Is that fallout of pkg-config being broken?
<\sh> RAOF, just checking it...but I doubt pkg-config being broken, because all tests from configure regarding the libebook1.2{-dev} lib are correct..only the substituion of EBOOK_CFLAGS/EBOOK_LDFLAGS doesn't work somehow
<RAOF> \sh: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583473 is the relevant bug.  We don't seem to have one in Ubuntu yet.
<ubottu> Debian bug 583473 in pkg-config "cecil-flowanalysis: FTBFS: [csc] error CS2007: Unrecognized command-line option: `-r\:/usr/lib/cli/nunit.core-2.4/nunit.core.dll'" [Serious,Fixed]
<RAOF> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582995 being a better one.
<ubottu> Debian bug 582995 in pkg-config "pkg-config should not escape = and : in Cflags" [Serious,Fixed]
<RAOF> Is EBOOK_CFLAGS/EBOOK_LDFLAGS entirely unsubstituted, or does it contain improperly formatted stuff?  If the latter, blame pkg-config :)
<\sh> RAOF, it's entirely unsubstituted...I build an amd64 chroot with all build-deps from giggle...and tried to compile manually
<\sh> RAOF, same happens on i386
<\sh> giggle-personal-details-window.c:30:29: error: libebook/e-book.h: No such file or directory
<RAOF> I'd try building with pkg-config 0.25.
<RAOF> That's not necessarily going to be the problem, but I know pkg-config is broken, so it's an easy target :)
<RAOF> Would someone kindly kick off an autosync run?  It'd be nice for Xorg related packages to build, and the pkg-config 0.25 sync will accomplish that. ;)
<hrw> guys - which doc you would suggest to get up to speed with bzr? I miss colored diffs, paged log/diff etc which I have outof-box with git
<\sh> RAOF, hmm...0.25-1 in debian...we need a sync...I'll recompile 0.25 right now for me...and check if it help
<\sh> s
<\sh> ii  pkg-config                       0.25-1                    manage compile and link flags for libraries
<\sh> giggle-personal-details-window.c:30:29: error: libebook/e-book.h: No such file or directory
<\sh> it doesn't help
<ttx> pitti: hey, is there some freeze in sync requests ? (or shortage of sync queue processors ?) I submitted bug 582312 two weeks ago... and it blocks the combined SRU for https://bugs.launchpad.net/ubuntu/lucid/+source/tomcat6
<ubottu> Launchpad bug 582312 in tomcat6 (Ubuntu) "Please sync tomcat6 6.0.26-2 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/582312
<pitti> ttx: how does a maverick sync block an SRU?
<pitti> there's no freeze, no
<ttx> pitti: well, the fix is not in the development release yet, will be once the sync is done
<pitti> ttx: that's ok at this time
<pitti> ttx: the sync bug existence is sufficient for this
<ttx> pitti: the SRU wasn't processed and I thought that was the reason why
<pitti> SRU processing is a bit slow ATM, with Steve and me being in other teams now
<ttx> pitti: that explains it, thanks
<\sh> WTF...libunwind builds  with -U_FORTIFY_SOURCE on amd64...oh wow...I'm the road to success
<\sh> I'm on the road ;)
<pitti> \sh: the former too!
<\sh> lol...now creating debdiff and hopeing for a sponsor ;)
<\sh> dholbach, which sponsor team I need to subscribe for a main sponsor? ubuntu-sponsors or ubuntu-main-sponsors
<dholbach> \sh: there only is ubuntu-sponsors now
<\sh> dholbach, thx :)
<dholbach> :)
<\sh> so if some main uploaders are interested in giving me a hand, then bug #522106 is yours ;) thx
<ubottu> Launchpad bug 522106 in libunwind (Ubuntu) "libunwind ftbfs on amd64 and i386" [Undecided,New] https://launchpad.net/bugs/522106
<dupondje> When is the MoM page refreshed ?
<ncopa> hi
<ncopa> there was a web gui to browse the ubuntu kernel package build scripts
<ncopa> i forgot where it was
<sivang> morning all
<ricotz> seb128, hello
<ricotz> seb128, just want to point you to https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1154399/+listing-archive-extra, i have started gtk+3.0
<seb128> ricotz, hi, ok
<seb128> slomo, ^
<ricotz> seb128, but there are some upstream issues which needs patched, but i386 should be fine
<seb128> ricotz, ok
<ricotz> seb128, there are surely still some conflicts with files of a gtk+2.0 installation, but it's a start
<seb128> right
<seb128> is some archive admin doing syncs?
<seb128> I wanted to do some desktop ones but the queue is non empty
<pitti> seb128: I did a few earlier on, let me check
<seb128> pitti, danke
<pitti> seb128: right, sorry; flushed now
<seb128> danke
<ebroder> kees: When you talk about "adding a kernel message" when the PTRACE fails, what do you mean? Something in dmesg?
<sebner> pitti: ping
<pitti> hello sebner
<sebner> pitti: huhu :), just a quick question
<sebner> pitti: https://bugs.edge.launchpad.net/docky/+bug/574003 , this still needs a SRU ack?! Besides debdiff should point to lucid-proposed?
<ubottu> Ubuntu bug 574003 in docky (Ubuntu Lucid) "Clock context menu not indicating state of options" [Medium,Triaged]
<pitti> sebner: someone else just asked me about that, I already ack'ed it
<sebner> pitti: so *you* should upload it to proposed then?1
<pitti> no, he said Laney was going to
<sebner> pitti: laney is afk. So I'd do it. But I have to change it to lucid-proposed?!
<pitti> yes
<sebner> pitti: great, thx
<ricotz> sebner, so you are on it now?
<sebner> ricotz: you asked me to :P
<ricotz> sebner, alright thanks!!!
<sebner> ricotz: np, but your debdiff is b00rken. 2-3 things are targeted to 2.0.4 (directory-wise)
<sebner> patching file docky-2.0.4/NEWS
<sebner> bad ricotz :P
<ricotz> sebner, please use from here https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1156209/+listing-archive-extra
<sebner> ricotz: well, it's from 2.3.1 to 2.4 and not lucid version 2.0.2
<pitti> sebner: you shouldn't attach the debdiff as it is
<sebner> ricotz: nvm, give me some minutes
<pitti> you need the new orig.tar.gz and a debdiff with just the debian/ changes
<pitti> s/attach/apply/
<sebner> pitti: I just thougth so :D
<sebner> pitti: ricotz : Uploaded
<ricotz> sebner, thank you!
<sebner> ricotz: np, I hope I didn't break anything :P
 * sebner forgot the -v flag. bad sebner
<sebner> pitti: approve approve approve, mind giving a SRU for another app?
 * pitti points out that he's on rotation this cycle, and thus not working in platform/SRU
<pitti> at least not as main contributor
<sebner> pitti: it's a veeeeeery smal one
<sebner> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/themonospot/+bug/533747
<ubottu> Ubuntu bug 533747 in themonospot (Ubuntu) "themonospot file missing" [Undecided,New]
<pitti> if it's an appropriate SRU, please just get it uploaded to the queue for review
<pitti> and someone will get to it
<sebner> pitti: aye, thx
<ebroder> Where's the right place to ask questions about how indicator-applet works? I'm staring at source code and not really understanding what's going on
<\sh> stgraber, ping
<hrw> doko_: can you take a look at https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/587851 patch?
<ubottu> Ubuntu bug 587851 in binutils (Ubuntu) "merge cross build into "binary" target" [Undecided,New]
<\sh> stgraber, when you have time, I would like to talk to you about your changes inside initramfs and not using ipconfig for dhcp requests...
<ScottK> pitti: Would you please rescore kde4libs on powerpc?
<ScottK> pitti: Speaking of sru reviews, did you see the LP queue page provides a link to the package diff now?
<pitti> ScottK: bumped
<pitti> ScottK: ooh! no, I didn't
<ScottK> pitti: Thanks.
<pitti> nice; still missing the bug refs, but it's a step forward
<pitti> mr_pouit: how are patches handled in the XFCE team? I reported bug 587933, should I subscribe or assign to a team etc.? Or do you guys read all bug mail?
<ubottu> Launchpad bug 587933 in xfce4-utils (Ubuntu) "Please drop the xfconf 4.6 migration script" [Undecided,New] https://launchpad.net/bugs/587933
<ScottK> pitti: I suspect if you discuss the need with wgrant it would semi-magically happen.
<\sh> bah....initramfs.conf: DEVICE=all -> dhcp requests on all NICs...when at least 2 NICs get the DHCP IP from the DHCP Server, kernel crashes
<\sh> ipconfig is stupid
<quadrispro> pitti, would you help me to maintain python-gudev in Debian?
<pitti> quadrispro: can do, is there a request for it now?
<pitti> quadrispro: it only got one upload ever, and basically "just works", so it's not a real effort anyway
<pitti> so i'm happy to upload it to Debian if there's a demand for it (RFP?)
<pitti> quadrispro: but NB that it will hopefully go away entirely with gobject introspection
<quadrispro> pitti, there's an ITP bug -> #583863, I opened it today because a package of mine needs it as dependency
<pitti> quadrispro: if you want me, I can upload it to Debian NEW with that ITP bug right now
<quadrispro> pitti, I'm working on the packaging via git -> http://git.debian.org/?p=collab-maint/python-gudev.git and yes, I would be very happy, I've become DD just today but I'm waiting for getting my account works fine
<pitti> quadrispro: ooh, congratulations!
<zyga> mvo, hi could you please fix that apt bash_completion issue/
<quadrispro> pitti, thanks :) can I add you as co-maintainer?
<pitti> quadrispro: please do; I can sponsor it until you get your account
<pitti> quadrispro: is it based on the Ubuntu packaging, or did you change a lot (in particular, structure of the packages)?
<pitti> i. e. can we just sync this?
<quadrispro> pitti, I've changed something, I think we can sync it without any problem
<quadrispro> anyway
<quadrispro> pitti, BTW, testbuilding for sure right now, I'll let you know
<mvo> zyga: hello - which one?
<mvo> zyga: is it a issue in apt or in bash-completion?
<zyga> mvo, hi
<zyga> mvo, the one that spams bash completion script syntax issue on each terminal
<ebroder> mvo: bug #546794
<ubottu> Launchpad bug 546794 in bash-completion (Ubuntu) "[revert, causes errors] Smarter lib* aware autocompletion?" [Undecided,Confirmed] https://launchpad.net/bugs/546794
<zyga> http://pastebin.ubuntu.com/442337/
<zyga> mvo, I could do it locally but I cannot upload anything to the archive and I image it annoys everyone on maverick
<quadrispro> pitti, ready to go http://debomatic.debian.net/maverick/pool/python-gudev_147.1-1/
<zyga> O_o!!!!
<zyga> multiarch!?!?!
<zyga>  :D
<zyga> yeeeahhoooo
<mvo> zyga: I check it out
<zyga> mvo, thanks
<mvo> zyga: it seems that ev uploaded it, if its not super anoying I would prefer to wait until tomorrow when he is availalble for comment?
<mvo> zyga: I mark it as a alpha-1 target in the bug
<zyga> mvo, sure, no rush - I thought you deal with that part
<mvo> zyga: I do with the apt bits :)
<zyga> mvo, err, I cannot target this for anything
<mvo> thanks for brining it up, if ev does not come up with a nicer fix I will upload the revert
<hrw> have a nice rest of day
<hrw> doko__: I attached new version of patch to the bug
<pitti> quadrispro: ok, will sponsor in a bit
 * pitti waves good bye for toda
<ogra_cmpc> ciao pitti
<didrocks> have a good evening pitti
 * quadrispro leaving
<pitti> quadrispro: oh argh; debian/changelog says "maverick", so that sid upload will fail
<pitti> quadrispro: shall I change it in git and reupload?
<pitti> oh, it's already changed in git
<maco> as of 10.10, u/k/x all use pulseaudio. festival umm...falls over.. if you have pulse running but it hasnt been configured to use it. so i want to make festival's default config be pulse-aware in mav. does this mean i should add a pulse recommends too, since the pulse-aware default config *wont* be happy without pulse? (its not a compile issue, its a text file issue)
<mr_pouit> pitti: yeah, I read all bugmail
<maco> pitti: by the way, bug 550145 ... should i upload with a modified version string? if so, should that be 0.9.9.8.6-2~ubuntu1 ?
<ubottu> Launchpad bug 550145 in anki (Ubuntu Lucid) "Anki 0.9.9.7.8 in Lucid suffers irreparable loss of functions. sync with debian to 0.9.9.8.6-2 needed." [Medium,Confirmed] https://launchpad.net/bugs/550145
<\sh> is it possible to "echo foo" inside initramfs-tools shell scripts?
<dupondje> seems like we need some sparc build boxes :D
<micahg> dupondje: I think sparc is going away
<dupondje> 772 jobs (three days) in queue now ... :(
<pitti> quadrispro: I tagged debian/147.1-1 in git
<ScottK> micahg: Unless someone appears to take over toolchain maintenance.
<ScottK> If dupondje is volunteering for that, then build boxes can be made available, I'm confident.
<kees> ebroder: yeah.  "user foo attempted to PTRACE process bar but sys.kernel.ptrace_scope is set to 1" or something
<ebroder> kees: Ok, that's what I was figuring. I'm not a huge fan of that, because dmesg is not where I think to look when I get an EPERM
<pitti> maco: how about 0.9.9.8.6-2~lucid1?
 * pitti -> really off now
<maco> pitti: can do
<kees> ebroder: right, which is why I'm trying to solicit ideas.  this is a really awkward change in logic.
<ebroder> kees: How do you feel about my idea to patch gdb and strace and possibly any other popular users of ptrace?
<kees> ebroder: and it's possible everyone will hate it so much that it gets pulled from maverick.
<ScottK> kees: Please don't do the "If you have package foo installed you're a developer and don't want that" approach.
<kees> ebroder: yeah, that's another possibility.  (I'm on holiday today so I haven't read through the email thread yet)
<ebroder> kees: Ah, right - I keep forgetting today's a holiday. I'll wait to pick your brain until tomorrow, then :)
 * \sh hates initramfs and klibcs ipconfig crap
<kees> ebroder: heh, no worries.  thanks for the idea, it seems like another good thing to add.
<quadrispro> pitti, thank you very much!
<sebner> quadrispro: congratulations from me too!
<quadrispro> thanks sebner
<sebner> quadrispro: DktrKranz told me to shower you with sponsoring requests :P
<quadrispro> ahh lol
<quadrispro> DktrKranz was drunk :P
 * sebner pets hyperair 
<sebner> quadrispro: DktrKranz is always drunk (at least if wine is near)+
<quadrispro> sebner, you're right, take a look at this http://www.ipernity.com/doc/milo/8118610
<sebner> quadrispro: lame. Don't you know the ubuntu-it meeting photos from a few days ago? :P
<quadrispro> sebner, it's just of u-i-meeting, but this http://www.ipernity.com/doc/milo/8118618/in/album/189792 is my favorite one
<quadrispro> an ubuntu-it-meeting without DktrKranz doesn't make sense at all :P
<sebner> heh
<sebner> full ack
<quadrispro> eh eh eh
 * quadrispro tries to see if alioth gets him as DD
<iulian> quadrispro iz a deedee?
<quadrispro> iulian, yep
<iulian> Awesome.  Buy me a drink then?
<iulian> :-)
<quadrispro> of course!
<sebner> iulian: lol, shouldn't it be the other way round?
<ScottK> quadrispro: When you get it figured out how to change your alioth account, please let me know.  Congratulations.
<iulian> quadrispro: Congratulations!
<iulian> sebner: Hell no. :)
<quadrispro> ScottK, congrats to you too! I'm trying, and trying, and trying
<ScottK> Thanks.
<iulian> Scott's a deedee as well?
<iulian> Yikes!  New sponsors!
<quadrispro> ScottK, does alioth already have our new account, isn'it?
<iulian> ScottK: Congratulations to you to.
<iulian> s/to/too/
<ScottK> iulian: Thanks.
<ScottK> quadrispro: I think you have to do some procedure to get it converted.
<quadrispro> ScottK, have you already requested a new password?
<ScottK> No.
<ScottK> Didn't do anything yet, but this is also OT here.
<quadrispro> yes, it is
<sebner> ScottK: uhh, congratulations from me too. Trying to take over the world, hmm? =)
<taavikko> Just a quick guestion, it is intended that ffmpeg-extras doesn't ship with the .so files atm in maverick?
<ScottK> sebner: Thanks.
<ebroder> taavikko: I think it's bug #587424
<ubottu> Launchpad bug 587424 in ffmpeg-extra (Ubuntu) "libavutil-extra-49 is empty (except /usr/share/doc)" [High,Triaged] https://launchpad.net/bugs/587424
 * hyperair pets sebner
<taavikko> thanks, ebroder :)
<\sh> ScottK, DD? Oh man...you rock :) Congrats :)
<ScottK> \sh: Thanks.
 * sebner waves at \sh :D
<\sh> hey sebner
<dupondje> When does the MoM pages get refreshed ?
<dupondje> :)
<ScottK> dupondje: It's either every hour or every 6 hours, I don't recall.
<ari-tczew> dupondje: apart from MoM is exist lucas merges
<apachelogger> jcastro: ping, ScottK suggested that summit.ubuntu.com might have advanced scheduling magic and is $free_software, is that true, if so, where to find the source?
<sebner> beer + pink is a bad combination for apachelogger :P
<apachelogger> fortunately I am all out of beer :P
<sebner> heh
<ScottK> pitti: Would you please rescore soprano on armel.
<geser> apachelogger: https://edge.launchpad.net/summit
<apachelogger> geser: thanks
<apachelogger> jcastro: unping :)
<bdrung> mdz: regarding de-native-ization (email): i didn't ask for de-native-ization lintian. most of the listed tools are useful for debian-based system. having it in debian first will have them in the derived distros easily. so i see no value of de-native-ization unless someone convinces me with good arguments.
<psusi> how does one get autoconf to add a bloody -I to the cflags?
<ebroder> CFLAGS="$CFLAGS -I/my/path"?
<psusi> clfags is not defined in configure.in
<psusi> it's all these damn macros that the man page doesn't document
<hyperair> psusi: it should be automake, not autoconf.
<Chipzz> hyperair: actually no, I think
<hyperair> otherwise try using AC_SUBST with AM_CFLAGS or something.
<psusi> don't have a .in
<psusi> err, .am rather
<hyperair> Chipzz: ?
<Chipzz> hyperair: actually I *think* configure will pass on CFLAGS passed in to it to automake generated makefiles as default
<psusi> just have configure.in that seems autoconf turns into configure
<Chipzz> if I'm not mistaken
<Chipzz> but I may be
<hyperair> Chipzz: oh yeah, you're right, i forgot.
<psusi> hrm...
<hyperair> but the right place to be adding -I things is in automake
<hyperair> in the Makefile.am files, not using autoconf.
<Chipzz> true, but autoconf *can* be involved too :)
<Chipzz> if you want it too :P
<Chipzz> nasty sh**, auto* :)
<Chipzz> but well-tested and good-working crossplatform sh** ;P
<hyperair> lol
<hyperair> autotools is powerful, if you've actually bothered to learn it properly.
<hyperair> it's very easy to write a shitty build system using autotools.
<hyperair> in the same way it's easy to write a shitty program in any programming language out there.
<hyperair> and for that reason i'm saying -I should be in the Makefile.am files, and configure.in shouldn't be touching the CFLAGS.
<hyperair> or configure.ac for that matter.
 * psusi just wants to bloody stick with a Makefile
<hyperair> ?
<psusi> instead of using auto*
<hyperair> custom-written Makefiles are more often than not, terrible.
<psusi> damn annoying that you have to muck about with it
<hyperair> go and read a proper tutorial
<hyperair> adn learn it properly
<psusi> compile object, link... why's it so difficult that you need a dozen damn tools to translate through 3 layers of macros before you get to a makefile?
<hyperair> for cross platform things.
<hyperair> and for cross-compilation support
<hyperair> and for automatic dependency resolution (header files)
<Chipzz> and for out-of-tree compilation support
<hyperair> and it's not a dozen, mind.
<hyperair> it's just two: autoconf, automake.
<Chipzz> and libtool
<hyperair> libtool is optional.
<psusi> and pkg-tool
<Chipzz> so is automake
<hyperair> pkg-config is separate.
<psusi> which I'm NOT bothering to use since it looks like I'd have to add a custom macro file for autoconf
 * hyperair clubs psusi over the head and throws him into a ditch.
<psusi> seems that just adding the two -I flags that glib needs to CFLAGS near the start of configure.in did the trick
<psusi> hehe
<Chipzz> naughty psusi :)
<hyperair> i'm not touching any build system you write with a 10-metre long stick.
<hyperair> use the damn PKG_CHECK_MODULES, it's automatically handled for you goddamnit
 * psusi substitutes himself with a baby seal
<Chipzz> s/psusi/baby seal/g ? :P
<hyperair> sorry, i chattr +i'd psusi.
<psusi> I don't want any build system... I just want a makefile, but this seems to already be using autoconf 2.13 and I used glib for the binary tree implementation
<hyperair> a Makefile is a build system.
<hyperair> a terribly primitive build system that won't scale
<hyperair> and will not work with the next *nix platform.
<hyperair> or even the same platform, but different architecture.
<psusi> why not?
<hyperair> well it might, through some stroke of luck.
<hyperair> but it most probably won't, e.g. some distros have libs in /usr/lib64, some have it in /usr/lib
<hyperair> some have /usr/lib32
<hyperair> and so on
<psusi> why do they have to do stupid things that need automagic configuration?  like putting the gconf headers in two different directories that are not already on the standard search path...
<hyperair> namespace clashes.
<hyperair> duh.
<psusi> how many different gconf-2.0/xxxxx.h files are there? ;)
<hyperair> many.
<hyperair> and also to provide for the future.
<psusi> how?  there should only be one gconf-2.0...
<psusi> err, glib, not gconf...
 * psusi facepalms
<hyperair> it's glib-2.0/glib/xxx.h
<hyperair> fyi.
<hyperair> 2.0 is the API version
<hyperair> there can be a glib-2.1
<hyperair> or even a glib-3.0
<hyperair> and it should co-exist.
<psusi> I was in the wrong directory... built gparted instead of defrag... seems that defining CFLAGS in the configure.in did NOT get it
<psusi> hence the -2.0 in the path name
<hyperair> well duh.
<psusi> so why can't you just include <glib-2.0/glib.h> and be done with it?
<hyperair> i suppose you enjoy changing the pathnames of your header files when glib goes on to 2.1
<psusi> apparently I specifically want 2.0, otherwise I'd have not been specific in the path name
<hyperair> apparently you refuse to plan for the future.
<hyperair> anyway, enough of this. i'm going to bed. you can continue with your stupid habits, or you can take the time to learn exactly why things are the way they are before blindly criticizing them.
<psusi> I guess I'm going to have to since everyone uses it, I"m just sick and tired of having to jump through multiple hoops just to disable the damn optimizer so I can use gdb properly because of these things, and the man page is next to useless
<hyperair> make CFLAGS="-O0"
<hyperair> finish.
<wgrant> pitti: Yeah, I thought about the bugs problem. It's a bit harder, and may have some performance implications, but it's something I want to do.
#ubuntu-devel 2010-06-01
<LLStarks> cjwatson, who keeps pushing back apt-sync/delta-debs?
<Laibsch> pitti: are you going to assume reponsibility for the regression you introduced in bug 580961 or not?
<ubottu> Launchpad bug 580961 in unzip (Ubuntu) "unzip fails to deal correctly with filename encodings" [High,Triaged] https://launchpad.net/bugs/580961
<Laibsch> Is asking you to forward-port an existing patch really too much to ask?
<ion> laibsch: Judging from the bug comments, it seems to me heâll be happy to sponsor a patch. Have you made one yet?
<Laibsch> why is the burden to provide the patch on me?
<Laibsch> he dropped the patch (introducing the regression) assuming the patch was no longer needed
<Laibsch> I don't blame him for that
<Laibsch> Somebody will need to forward-port the patch to unzip 6.x
<Laibsch> I'm sorry that won't be me, not because I don't want to, but because I can't
<Laibsch> I think he should accept that he's the one that should do this unless somebody steps up to the plate and volunteers
<Laibsch> "I'm not being paid anymore to work in this area" is ultra-lame
<aSt3raL> hi
<aSt3raL> how do i compile with a makefile and redirect the output to a file in bash?
<RAOF> make > foo.  Just like any other redirection.
<aSt3raL> make > make.log 2>&1 actually
<aSt3raL> thanks though
<arand> Bug #588076 Is http://pastebin.com/128hP8jq (which I have confirmed to work) something which is sane to do?
<ubottu> Launchpad bug 588076 in rhythmbox (Ubuntu) "[FTBFS] rhythmbox tries to define "pause", which is already used by unistd.h" [High,Triaged] https://launchpad.net/bugs/588076
<arand> ââ Nevermind, someone fixed it in git already :)
<pitti> Good morning
<pitti> ScottK: seems someone beat me to it; soprano is built now
<pitti> wgrant: ah, fun; I had expected that the diff generation was the performance critical bit, and that a mere regex match over the .changes was cheap?
<Semperfi40> Hello
<Semperfi40> Is this a support channel?
<micahg> !support | Semperfi40
<ubottu> Semperfi40: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<Semperfi40> *Sad face* Bleh I'll just wait for more useful people to join that channel then. *Wanders back over to the ubuntu channel*
<wgrant> pitti: Well, the diff generation is done by a cron job.
<wgrant> pitti: +queue is notoriously timeoutish.
<wgrant> However, we store the .changes' changelog section in the DB, so I can access it quickly and do something like http://people.ubuntu.com/~wgrant/launchpad/changelog-in-queue.png
<wgrant> Or I could extract just the numbers, if I can find somewhere good to put them.
<pitti> wgrant: timeoutish> heh, I noticed; binNEWing kernels is fun
<pitti> wgrant: adding expanders to the queue items to see the .changes (similar to e. g. the PPA +packages view) is out of the questin?
<wgrant> pitti: That's what the screenshot shows, isn't it?
<pitti> oh, right; that'd be nice indeed!
<wgrant> It's a bit different on +queue, since at the moment all of the expandy bits are rendered as part of the main page, whereas in PPAs they're AJAX loaded.
* pitti changed the topic of #ubuntu-devel to: "Archive: soft-freeze for Maverick alpha1 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/Help
<wgrant> So there's only so much we can safely throw into +queue before we AJAXify it.
<pitti> wgrant: ah, I see
<wgrant> But this particular change requires no more DB queries, so it's safe enough.
<pitti> wgrant: well, I guess we'd keep our sru-review helper script either way
<pitti> it currently parses out the bugs from the .changes, creates the debdiff, and opens all the affected bugs in the browser
<pitti> and creates a command line for sru-accept.py
<pitti> I expect we want to keep those, and just change it to grab the diff from LP instead of having to download the two packages and run debdiff
<wgrant> sru-accept.py does the commenting on the bug thing as well, I guess?
<pitti> the diff is the expensive part from the client side, so with this existing now I'm actually really happy :)
<wgrant> And I guess it screenscrapes? :/
<pitti> wgrant: s-accept adds a "test me" comment, sets tags, subscribes folks, and updates task status, yes
<pitti> wgrant: sru-review screenscrapes the queue, right
<wgrant> Right.
<wgrant> I'm not sure how often the diff generation cron job is running, so it could take a few minutes to show up.
<pitti> that should be fine
<pitti> we aren't usually reviewing SRUs *that* closely :)
<pitti> zul: seems your last samba merge in maverick reintroduced the ctdb b-dep; this was already discussed before (bug 497035), can this be dropped again? samba currently doesn't build because of that, and causes some uninstallability
<ubottu> Launchpad bug 497035 in ctdb (Ubuntu) "MIR for ctdb" [Undecided,Invalid] https://launchpad.net/bugs/497035
<pitti> zul: I'll just drop ctdb again, if that's alright with you
<dholbach> good morning
<pitti> hey dholbach, good morning!
<dholbach> hey pitti
<pitti> apw: good morning!
<pitti> apw: I guess there's not much hope for bug 587888 to be fixed for alpha-1?
<ubottu> Launchpad bug 587888 in linux (Ubuntu Maverick) "aufs oops in au_do_open() on maverick live system boot" [Critical,Triaged] https://launchpad.net/bugs/587888
<pitti> apw: we can release alpha-1 without deskop images, it's not the end of the world
<pitti> Riddell, ScottK: so kdebase-plasma depends plasma-widget-folderview, but p-w-f conflicts kdebase-plasma; what's the solution here?
<pitti> JontheEchidna: ^ or maybe you know?
<mneptok> pitti: "use GNOME"
 * mneptok whistles innocently
<pitti> heh
<dholbach> pitti: I'll unassign ~kubuntu-dev from bug 588150 - else every core-dev will get an email
<ubottu> Launchpad bug 588150 in kdeedu (Ubuntu Maverick) "build-depends on avogadro, which is in universe" [High,New] https://launchpad.net/bugs/588150
<pitti> dholbach: ah, sorry about that
<dholbach> does core-dev need to be a member of kubuntu-dev?
<pitti> for bzr branch committing, I suppose
<dholbach> we should just use source package branches - that'd solve all those problems :)
<dholbach> our acl <-> team membership landscape gets more and more complicated
<dholbach> Riddell: ^ which team do you suggest for this bug?
<dholbach> or ScottK maybe ^
<dupondje> https://bugs.launchpad.net/ubuntu/+source/python-central/+bug/588156 => any comments on the merge ? :)
<ubottu> Ubuntu bug 588156 in python-central (Ubuntu) "Please merge python-central 0.6.16 (main) from debian unstable" [Undecided,New]
<pitti> mr_pouit: FYI, I'm removing a couple of langpacks from the xubuntu alternate to fix the oversizedness; for those early alphas that doesn't matter much, I suppose
<pitti> next build should be okay
<summers> i would like to invite everyone to my new ubuntu channel, #ubuntu-faggots
<summers> +o for everyone
<apachelogger> james_w: hullos! is there any documentation on launchpad recipes? or examples for that matter
<geser> Could a core-dev please give back: lftp libnice mdbtools transfig. Thanks.
<pitti> geser: doing
<LucidFox> So, there is no longer separate ubuntu-main-sponsors and ubuntu-universe-sponsors, but rather a single ubuntu-sponsors?
<seb128> correct
<LucidFox> So, I heard there are plans to enable GTK RGBA by default in maverick?
<RAOF> LucidFox: Not so much âplansâ as âit's currently breaking emacs-gtkâ :)
<LucidFox> heh
<LucidFox> Is there a special tag for software that breaks it?
<LucidFox> for bug reports, that is
<seb128> gtk-csd
<seb128> there is already a list of those
<seb128> banshee, emacs, flashplayer, etc, etc
<LucidFox> isn't gtk-csd for client-side decorations?
<seb128> LucidFox, client side decoration and rgba are in the same changeset
<seb128> LucidFox, csd requires rgba
<LucidFox> Ah.
<seb128> we don't need 2 different tags to track the same changeset issues
<seb128> the idea is to have those bugs listed, not to be strict about matching tags wording ;-)
<LucidFox> You see, the reason I'm asking is because I've had a patch lying for a while for xchat-gnome crash: bug #92028
<ubottu> Launchpad bug 92028 in xchat-gnome (Ubuntu) "xchat does not do composite transparency, crashes if transparency is enabled with GTK RGBA" [Wishlist,Triaged] https://launchpad.net/bugs/92028
<LucidFox> normally I'd upload it myself, but xchat-gnome happens to be in main (why, by the way?)
<seb128> because it's our recommended IRC client
<LucidFox> ah
<seb128> it's on the DVD I think
<seb128> I'm fine sponsoring a debdiff if you have one
<Riddell> dholbach: kubuntu bugs can go to kubuntu-bugs I guess
<seb128> apw, hi
<seb128> apw, you have alpha1 work items on
<seb128> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-in-mm
<seb128> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-easy-wayland-testing
<seb128> are those still going to happen?
<seb128> RAOF, ^
<dholbach> thanks Riddell
<dholbach> done
<zyga> ev, mvo: hello, any chance for that apt bash tab completion issue?
<ev> zyga: I've already uploaded a fix.
<zyga> ev: lovely, thanks :-)
<ev> do let me know if you're still having issues
<ev> once it's built and installed, that is
<RAOF> seb128: I'm unsure about apw's items there, but they still can be done by alpha-1; they don't require any archive uploads.  Perhaps apw's planning to do them during the freeze?
<seb128> RAOF, ok, I was just checking in case you knew since those specs are assigned to you
<seb128> RAOF, I will check with apw when he's around, thanks
 * apw looks blearily at seb128 and RAOF 
<apw> they are on my list to do, i think the ones you are referring to are small so there is definatly hope
<seb128> apw, if they are still on target for alpha1 that's fine, I'm just checking what should be moved to alpha2 now
<RAOF> It's: review the crazy intel GTT coherency patch (I think there's actually a newer version of that available), and a little wayland checking.
<apw> RAOF, a newer version ?
<seb128> apw, RAOF: thanks
<apw> RAOF, got a reference to that one
<RAOF> apw: I'll check on the bug.  There was recent activity there, and there have been at least 9 versions of the patch, so it's non obvious to track. :)
<apw> RAOF, heh sounds like a nightmare as normal, best if i review and package up the right one tho.
<RAOF> _Man_ that bug has a lot of duplicates.
<RAOF> Sucks to have an i845 card, too.  That bug's similar, but without anyone really working on it.
<stenten> Do you need a link to the latest upstream version of that patch?
<RAOF> apw: http://bugs.freedesktop.org/attachment.cgi?id=35548 is the v9 patch against drm-intel-next as of 2010/05/10.
<RAOF> It's missed the 2.6.35 merge window, and there appear to _still_ be reports of GTT incoherency even with that patch.
<RAOF> Yay hardware!
<apw> RAOF, and this is the fix meant to fix the 8xx intel h/w ... right ?
<Sarvatt> backporting things to intel 2.7.1 as a forked driver, turning off KMS for 8xx and adding the fork to the xserver autoconfig logic so it's automatically loaded for !KMS because -intel is KMS only really seems like the way to go at this point
<RAOF> apw: It's meant to fix i855. i845 has a similar problem, but no patch.  And then there are other i8xx cardsâ¦
<Sarvatt> apw: *one* specific 8xx
<hrw> intel 8xx... nightmare
<apw> Sarvatt, i thought we already had 8xx KMS disabled now, and it was causing issues for some people who used to work ?
<hrw> bb in few
<Sarvatt> apw: they're still using the newer xserver-xorg-video-intel, those GPU's were never made to work the way the modern driver is assuming and it's just getting worse and worse
<LucidFox> seb128> Debdiff uploaded
<apw> Sarvatt, so you are saying leave the kernel as is (disable KMS for 8xx) and fix the Xserver to use an older -intel drop for those cards only
<seb128> LucidFox, thanks
<RAOF> apw: Yup.  That was the outcome at the Xorg-in-Maverick overview session.
<apw> RAOF, so does it even make sense to look at this patch then?
<RAOF> apw: It'd be nice to apply to Lucid.
 * apw shudders ... i can hear martin and stefan screaming already
<RAOF> Where we *don't* have an old intel driver.
<Sarvatt> problem is the old driver could still be screwed up with the newer kernel, it's something that needs testing
<RAOF> Sarvatt: Should be much less likely, though; it won't be using the gem interfaces, right?
<RAOF> Or will be using a much more restricted subset.
<Sarvatt> >ubuntu-x :)
<ogra> could an archive admin let my x-loader-omap4 package into the archive (sitting in NEW)
<LucidFox> http://live.gnome.org/GTK+/ClientSideDecorations <-- Woo, wayland is a goal
<cjwatson> could somebody KDEish look into the uim FTBFS?  It ends up triggering a minor but irritating Soyuz bug during autosyncs for reasons too tedious to explain in full ...
<Riddell> uim?
<Riddell> mm, ok
<geser> cjwatson: could you please sync the new source package "git"? the source package "git-core" (in Ubuntu main) got renamed to "git" (it's not urgent)
<Riddell> geser: I'm on archive admin duty today, file a bug and I'll get to it
<geser> Riddell: ok
<dholbach> james_w: how can I move https://code.edge.launchpad.net/~arky/ubuntu/karmic/qemulator/fix-257233/+merge/11510 from "Needs review" to something else?
<pitti> cjwatson, slangasek, ScottK, Riddell: I just updated queuediff to use the LP generated debdiffs instead of building it itself; much less to download now
<pitti> (the old version also broke on 3.0 format with current edge)
<cjwatson> cool
<highvoltage> mdz: I thought that you might like this video about motivation: http://www.youtube.com/watch?v=u6XAPnuFjJc
<pitti> jdong: I just updated queuediff to use the LP generated debdiffs instead of building it itself; much less to download now
<LucidFox> So, is CSD/RGBA now enabled by default in Maverick? I see it was patched into GTK 11 days ago.
<wgrant> pitti: Note that it's only on edge at the moment.
<pitti> wgrant: yep, that's fine
<seb128> LucidFox, the patch is there but the theme doesn't use it
<LucidFox> ah
<seb128> LucidFox, the patch is there but the theme doesn't use it
<seb128> ups
<LucidFox> But RGBA can be forced with gnome-color-chooser, like with the Lucid RGBA PPA?
<wgrant> pitti: (also, good luck reviewing udev SRUs with that... we blacklist it since it causes debdiff to generate infinite output)
<wgrant> But I guess that's probably a problem locally anyway.
<seb128> dunno
<pitti> wgrant: hm, the uploaded orig.tar.gz's shouldn't; we filter out the test /sys tree
<wgrant> Maybe it's fixed now. This has been in place for a while.
<ion> I should get around to reporting a bug against whatever GUI library Vuze uses. Some horrible Java hack that abuses Gtk in a similar way to Firefox and OpenOffice. Since the Gtk patch, Vuze crashes on startup.
<mdz> highvoltage, thanks, I've read about this research but it's nice to have a concise summary like this
<seb128> thanks to whoever does sru reviewing
<pitti> seb128: de rien
<seb128> pitti, oh, it's you? ;-)
 * seb128 hugs pitti
<pitti> I've got some room in between alpha-1 juggling
<seb128> sorry it's sticking so much to you though
<seb128> somebody should perhaps do a call for extra members to join the sru team now?
<geser> Riddell: bug 588237; I'm not sure if it needs a sponsor ACK or not, therefore I decided for the safe side (sponsoring)
<ubottu> Launchpad bug 588237 in git (Ubuntu) "Sync git 1:1.7.1-1 (main) from Debian unstable (main) [replaces git-core]" [Wishlist,New] https://launchpad.net/bugs/588237
<pitti> seb128: as soon as we'll get a new release manager, it should get better
<james_w> dholbach: currently it is broken and you aren't able to do it, so I did it for you
 * dholbach hugs jam
 * dholbach hugs james_w
<dholbach> :)
<LucidFox> "Horrible Java hack"? SWT is a wrapper around GTK...
<LucidFox> As opposed to Firefox and OpenOffice, which use their own toolkits for rendering and only query GTK for widget appearance
<LucidFox> But I did run into problems with SWT and RGBA, to the point that I had to blacklist Eclipse.
<Chipzz> isn't being written in Java enough to qualify as a horrible hack as such? :P
<newubuntuusr> Hello, is therea developer online?
<soren> No. It's quite a phenomenon, really. All of the worlds hundreds of thousands of software developers all just logged off the internet two minutes ago.
<ogra> apart from soren indeed
<soren> I'm not a developer. I just play one on IRC.
<Chipzz> is soren a developer? :p
<ogra> he is dressed like one
 * soren chuckles
<ogra> but that might just be part of the playing :)
<Chipzz> with some ppl you just know up front that this is the wrong channel for them
<Chipzz> "newubuntuusr" is kind of a dead giveaway
<Chipzz> in such cases, I'm very inclined to urge ppl to pls read the topic before asking further questions
<Sarvatt> LucidFox: try the darkroom theme
<LucidFox> Sarvatt> I will, after I get home and install Maverick :)
<soren> pitti: About the check SRU: I approved the nomination for Lucid myself (someone else nominated it). After doing it, I couldn't help but wonder if I should have left that to ubuntu-sru? The wiki doesn't say.
<pitti> soren: approving tasks is fine, and appreciated
<pitti> so I don't have to do the extra clickery :)
<soren> pitti: Ok, good. So the SRU team's ACK is a nudge towards the archive admins to accept it?
<pitti> soren: right
<soren> pitti: Ok, lovely. That explains. Thanks.
<mvo> doko: what should we do with the powerpc SPU extension in crash? you introduced it in ~2007 and I was wondering if its still important to keep or if we can simply sync the debian package
<doko> mvo: well, lucid still runs on the ps3 ...
<mvo> doko: ok, just wanted to check before porting it over
<mvo> doko: thanks
<G> kirkland: oh, did you see, upstream submitted an updated patch, going to test it tonight
<G> kirkland: for the libvirt bug that is
<ttx> mvo: bug 223741 is due to people trying to do LTS->LTS before the .1 release, right ? If you confirm, i'll close it as invalid
<ubottu> Launchpad bug 223741 in update-manager-core (Ubuntu) "'do-release-upgrade' requires the '-d' flag to upgrade from dapper to hardy, and from hardy to lucid" [Undecided,Confirmed] https://launchpad.net/bugs/223741
<mvo> ttx: yeah, until .1 that needs either "-d" or "--proposed"
<ttx> mvo: ok, will clean up
<mvo> thanks ttx
<kirkland> g: i didn't see that yet, but that's excellent news
<ogra> Riddell, i'd appreciate if x-loader-omap4 and u-boot-omap4 couls get out of NEW some time today (no hurry though)
<G> kirkland: tbh, I think the new patch will work just fine
<G> kirkland: I've got a feeling it could also prevent the change issue that I couldn't reproduce
<h0ar3> hi devels
<h0ar3> https://code.launchpad.net/wubi
<h0ar3> how can I checkout its source?
<hrw> I would try "bzr clone lp:wubi"
<h0ar3> what is bzr
<h0ar3> I'm on windows
<hrw> You can browse the source code for the development focus branch or get a copy of the branch using the command:
<hrw> bzr branch lp:wubi
<hrw> that is on page there
<hrw> bzr is scm used by ubuntu
<ogra> hrw, only if you pick a branch and click it :)
<h0ar3> oh
<hrw> ogra: I went to page which h0ar3 gave
<h0ar3> works on windows?
<hrw> h0ar3: yes
<h0ar3> executable?
<ogra> http://wiki.bazaar.canonical.com/BzrOnPureWindows
<h0ar3> why do need this
<hrw> h0ar3: ?
<h0ar3> there is svn,git,mercurial
<h0ar3> seems reinvented the whell
<h0ar3> wheel*
<hrw> there is also perforce and zillion others
<hrw> but ubuntu uses bzr
<hrw> accept it
 * hrw wants bitkeeper
<ogra> eeek
<cjwatson> bzr predates git, for the recor
<cjwatson> d
<cjwatson> it predates mercurial too
<JontheEchidna> pitti: I want to testbuild to see if dropping the avogadro build-dep was the only thing I forgot to push to bzr, then I'll upload a fix
<pitti> JontheEchidna: nice, thanks!
<pitti> JontheEchidna: btw, I rebuilt the current alternates, they seem fine now
<pitti> JontheEchidna: dropping kdebase-plasma seems to have solved/worked aroudn both problems
<hrw> cjwatson: what about monotone?
<JontheEchidna> pitti: nice
<cjwatson> monotone was a slightly earlier generation - I think it was one of the things Martin looked at when he did the initial bzr design
<cjwatson> it was kind of more the tla generation I think
<hrw> cjwatson: I remember that in 2005 when OpenEmbedded devs tested existing dscms we moved to monotone from bitkeeper. bzr was rejected at that time
<G> kirkland: btw, not sure if you've seen 455832 but it might also be an option to include, not sure what policy you guys have to follow though
<ogra> pitti, can you reset the trend line on http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html at some point (not urgent)
<pitti> ogra: to which number?
<ogra> pitti, 46 if i'm counting correctly
<pitti> ogra: for alpha-1 as well?
<ogra> pitti, hmm, i have to check that, i dont think we have actual A1 targets
<ogra> its all A2
<pitti> ogra: ok, a2 will auto-reset past a1, so that's fine then
<ogra> great
<pitti> ogra: committed; just missed this hour's cron, though
<ogra> great, thanks
<cjwatson> JontheEchidna: is bug 517962 already fixed in maverick, or does it need an upload?
<ubottu> Launchpad bug 517962 in kdebase-runtime (Ubuntu Lucid) "nepomukservicestub crashed with SIGSEGV in Soprano::Plugin::pluginName()" [Medium,Fix committed] https://launchpad.net/bugs/517962
<JontheEchidna> cjwatson: ah, it's fixed in maverick now
<JontheEchidna> cjwatson: closed
<cjwatson> thanks
<jdstrand> seb128: hi! so, evolution has under Edit/Preferences/Composer Preferences the following: 'Top Posting Option (Not Recommened)'. While I would certainly not enable the option personally, it seems rather non-Ubuntu-like to have the '(Not Recommended)'. Maybe I am missing something, but it seems like a developer asserting his/her preference on bottom-posting
<jdstrand> seb128: rather than any 'real' issue with the functionality
<seb128> jdstrand, hey, indeed
<jdstrand> seb128: obviously not anything important, but thought it might be a string to consider stripping out
<seb128> jdstrand, could you open a bug on launchpad? (and to GNOME if you want, we will do it otherwise)
<jdstrand> seb128: sure
<seb128> thanks
<james_w> apachelogger: thanks to dholbach: https://wiki.ubuntu.com/DailyBuilds/GettingStarted
<jdstrand> seb128: done and done
<seb128> jdstrand, thanks and thanks ;-)
<jdstrand> he and he
<jdstrand> :)
<ogra> Riddell, thanks a lot !!
<geser> has someone an idea why building "steam" in maverick failed on i386 and powerpc (xslt.c:(.text+0x1bb4): undefined reference to `__stack_chk_fail_local') but succeeded on amd64 and armel? [https://edge.launchpad.net/ubuntu/+source/steam/2.2.31-6ubuntu1]
<Riddell> ogra: just doing my archive admin duties :)
<ogra> :)
<smoser> Keybuk, are you around?
<Keybuk> smoser: no, I'm asquare
<smoser> indeed L7
<smoser> you may or may not be aware that there are people interested in running ubuntu in lxc (containers).  The attempts to do so that i'm aware of look like: http://github.com/phbaer/lxc-tools/blob/master/lxc-ubuntu
<Keybuk> I am aware
<smoser> reportedly that works on lucid.  i'd like to get your impressions on how difficult it would be to get "proper" support in upstart
<smoser> and what you think of something like the above.
<Keybuk> that's a very long shell script that does a lot of changing of things
<smoser> i'm willing to type email so you can process when you have time.
<Keybuk> so technically speaking, that's not Ubuntu in the container
<Keybuk> and can never be something we can support
<smoser> yes, i agree. (its not *very* long), but yes.
<smoser> so those were my first thoughts
<smoser> also.
<smoser> but, the script basically gives some what of a recipe to fix the things that don't "justwork" with ubuntu boot.
<Keybuk> I would rather they fixed the things that make the ubuntu boot not work with lxc
<Keybuk> as clearly that's an lxc issue
<smoser> well, sort of.
<smoser> some things are "lxc issues" . some things are not really possible to change.
<smoser> its basically a bit of a more functional chroot.
<Riddell> ogra: E: u-boot-omap4: upstream-version-not-numeric L24.6-p1git20100520-0ubuntu1
<ogra> Riddell, yes, wanted
<smoser> so /dev isn't going to be there, you don't have block devices with partitions and filesystems, its much more like nfs root in that sense.
<ogra> Riddell, i'm using the TI upstream system
<Riddell> ogra: ok, accepted binary
<ogra> thanks
<smoser> so some things probably can be "fixed" in lxc, but others are probably going to need some adjustments in ubuntu boot process.
 * ogra digs for the FTBFS of x-loader-omap4
<Keybuk> smoser: the best way for that to happen would be for someone who knows and uses lxc to get interested in ubuntu boot
<Keybuk> and maybe sign copyright for upstart, etc.
<smoser> Keybuk, thanks for your time. i'll stop pestering for now.
<Keybuk> I don't mean to brush off, but there's only one of me, I have limited time and knowledge
<kirkland> bug 455832
<ubottu> Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/455832)
<smoser> Keybuk, completely understand.
<Keybuk> I'm really not, personally, interested in things like servers, cloud, containers, etc.
<Keybuk> so I'm the wrong person to work on that kind of thing in Ubuntu/Upstart
<smoser> unfortunately, at the moment, i dont think there is a better person.
<smoser> Keybuk, one other question, i nfs root generally supported?
<Keybuk> it's known broken
<ogra> damned
<ogra> is there any way to replace a broken symlink with a dir using patch ?
<ScottK> pitti: Nice (re queuediff).
<doko> asac, seb128: which library should I use, when libmozjs.so is needed?
<ogra_> Riddell, x-loader-omap4 in binary NEW now (sorry for the delay it had FTBFS)
<Daviey> kirkland: Off the top of your head.. do you know which bug WalrusRESTBinding.java refers to?
<kirkland> Daviey: hmm, no
<Daviey> kirkland: things like, -						putQueue = getWriteMessenger().getQueue(key, randomKey);
<Daviey> +						putQueue = getWriteMessenger().interruptAllAndGetQueue(key, randomKey)
<Daviey> kirkland: the diff i have, http://paste.ubuntu.com/442846/
 * kirkland checks loggerhead
<Daviey> kirkland: good luck with that :/
<kirkland> Daviey: hmm, where is this from?
<kirkland> Daviey: is this a patch we're carrying, or a diff?
<Daviey> kirkland: it's a reverse diff created from the difference between our lucid magic, and the current 1.6.2 head.
<kirkland> Daviey: http://bazaar.launchpad.net/~ubuntu-core-dev/eucalyptus/ubuntu/annotate/head:/clc/modules/wsstack/src/main/java/com/eucalyptus/ws/handlers/WalrusRESTBinding.java
<kirkland> Daviey: starting there?
<Daviey> kirkland: Yeah.. but i'm trying to work out if there is anything we need to carry from there, into the 1.6.2 head branch.
<Daviey> ie, lucid -> 1.6.2 branch doesn't cleanly merge on that file.
<Daviey> and the generated diff is that pastebin.
<kirkland> Daviey: in your pastebin, which is the - and which is hte + ?
<Daviey> - = lucid
<Daviey> + = 1.6.2 branch
<kirkland> Daviey: i think you can safely drop this
<kirkland> Daviey: drop our diff, i mean
<Daviey> kirkland: yup, thought so.
<Daviey> thanks.
<kirkland> Daviey: the new code looks to be a better code
<apachelogger> james_w: now that was too obvious, thanks :)
<james_w> apachelogger: not linked from /DailyBuilds though, so I'll let you off :-)
 * james_w fixes
<apachelogger> phew ^^
<james_w> oh, it is, right at the top
 * apachelogger hides
<apachelogger> james_w: http://imagebin.ca/view/xt3ktt6.html yet the wiki says "Source Package Name: if the package exists in Ubuntu, make the right connection here."
<james_w> apachelogger: I thought that box had been dropped. Did you enter the source package name that the recipe will create?
<apachelogger> james_w: doesnt work since the package is not yet in ubuntu :/
<james_w> apachelogger: so if you put it in there it says "This isn't an Ubuntu package"
<apachelogger> james_w: "Invalid value" it says
<apachelogger> If I search "No items matched "ubuntuone-kde"."
<james_w> apachelogger: that sucks
<james_w> apachelogger: please file a bug
<apachelogger> james_w: against soyuz or what?
<james_w> apachelogger: it may be that the option has already been removed in the code, and just not rolled out, but we should track it again
<james_w> apachelogger: um, launchpad-code I think
<apachelogger> oh-k :)
<apachelogger> james_w: can I enter any random package name for that? I suppose it is only for linking the data?
<apachelogger> james_w: bug 515581
<ubottu> Launchpad bug 515581 in Launchpad Bazaar Integration "Recipe requires sourcepackagename before upload" [High,In progress] https://launchpad.net/bugs/515581
<james_w> thanks
<james_w> apachelogger: I have no idea what it is used for
<apachelogger> oh, one can also upload to a PPA and it will show up as source package name
<asac> doko: try to get rid of it ... 2nd try to get rid of it ... 3rd. use xulrunner with xulrunner --gre-version hack to figure LD_LIBRARY_PATH at startup
<doko> asac: 1 and 2 won't work, 3 is ugly. it's dehydra which I try packaging
<doko> asac: what's wrong with libmozjs-dev in debian?
<asac> doko: no ABI stability
<asac> always send a mail upstream and say they should move asap to webkit javascript core
<asac> doko: and then use the ugly way until they have resolved it or block it from the archive if that would help getting it done upstream sooner
<asac> doko: alternatively, you could talk to chrisccoulson ... if we want mozjs we need to package it from independent source and then take care that noone who has insecure remote content exposure uses that
<doko> asac: that would be good. usually gcc doesn't have these problems
<asac> doko: why is gcc using mozjs?
<asac> cant we get rid of that?
<asac> actually i hoped that such a package could at least live in universe
<doko> asac: https://developer.mozilla.org/en/Dehydra
<micahg1> doko: will you be around a little later (2 hrs)?  I need to chat with you about openjdk in hardy
<lfaraone> If I post to ubuntu-devel with my personal email address (which I used to subscribe, and is listed in LP) will the email be moderated? (I'm an ~ubuntu-dev member)
<cjwatson> probably
<cjwatson> oh, if it's listed in LP, it should go through
<LaserJock> cjwatson: is there a non ~ubuntu-dev team that is whitelisted or is it just individuals?
<cjwatson> LaserJock: I thought it was ~ubuntu-dev
<cjwatson> LaserJock: but that stuff isn't under my direct control
<LaserJock> cjwatson: I just meant if there was some LP team that controlled the whitelist for people not in ~ubuntu-dev
<LaserJock> or if it was just in the mailman interface itself or something like that
<smoser> is there a blueprint that would cover dropping of udev ? something that i could subscribe to so I could knwo when it change?
<cjwatson> LaserJock: mailman
<apachelogger> james_w: what do you make of that: https://code.edge.launchpad.net/~apachelogger/+recipe/main/+build/26
<james_w> apachelogger: urgh, it's still broken
 * apachelogger falls back to doing own packages :P
<jcastro> robbiew: do you have a page that lists all the release schedules for N-P or do you just have them individually like PReleaseSchedule, etc.?
<james_w> apachelogger: I think that should be fixed when updated buildd packages are copied to the production PPA, which should happen soon.
<robbiew> jcastro: one sec
<robbiew> jcastro: https://wiki.ubuntu.com/ReleaseSchedule/LTStoLTS
<jcastro> thanks!
<cody-somerville> Does anyone know where I can find the number of packages in the Debian archive?
<pochu> source or binary packages?
<pochu> (UDD has it I guess)
<cody-somerville> pochu, source
<pochu> cody-somerville: unstable?
<cody-somerville> pochu, aye
<pochu> emilio@saturno:~$ grep Package /var/lib/apt/lists/ftp.de.debian.org_debian_dists_unstable_main_source_Sources | sort -u | wc -l
<pochu> 15028
<pochu> I think that would be accurate
<james_w> might want ^Package
<ion> ...or grep-dctrl ;-)
<seb128> pochu, the sort doesn't make any difference there :-)
<james_w> seb128: it does, as it is -u
<james_w> and dak may now include more than one stanza per-source
<seb128> james_w, do we have things listed several times in the Sources?
<seb128> oh ok
<pochu> cody-somerville, james_w: right, it's 15007 with ^Package
<pochu> seb128: it's like 900 less packages with sort -u ;)
<seb128> pochu, ok, we don't have that difference on Ubuntu ;-)
<cody-somerville> Launchpad say testing has 16275 packages.
<cody-somerville> *says
<james_w> including contrib and non-free perchance?
<ccheney> cjwatson, when is udev going away this cycle?
<cjwatson> ccheney: nobody promised it would be this cycle
<ccheney> cjwatson, ok
<smoser> cjwatson, so your expectation is that udev will live through maverick ?
<dupondje> udev gets removed ?
<cjwatson> smoser: Keybuk said that he was generally planning on making the daemon go away at some point.  As far as I know not much directly depends on it, it has no work item assigned for it, it's not a priority, etc.
<smoser> i've got some work items that i figured would sit atop udev, and had assumed (incorrectly) that udev was going away per Keybuk's talk at UDS.
<ttx> cjwatson: we have work on ebsmount that would suffer from a potential transition
<cjwatson> smoser: in any case, the configuration would remain
<cjwatson> smoser: it shouldn't affect you
<smoser> ok. that was the big thing.
<smoser> we're square then. thank you for clearing this up.
<cjwatson> this is a potential plumbing rearrangement, not (as far as I know) a major interface change
<dupondje> https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/584287 => can the importance gets a bit bumped ? this is like the crappiest bug in maverick atm :)
<ubottu> Ubuntu bug 584287 in metacity (Ubuntu) "Unexpected X error (BadDrawable) causing metacity to abort in maverick" [Undecided,Confirmed]
<cjwatson> smoser: do make sure, as ever, that you aren't using any constructs deprecated by the udev documentation
<smoser> ok. thanks.
<cjwatson> in particular you're now only supposed to add symlinks to the kernel's canonical device name, not rename the device
<micahg> doko: ping
<smoser> cjwatson, i'm more interested in the events and getting programs called based on add/remove
<smoser> kees, are you around ? i'm looking at https://code.launchpad.net/~kees/vmbuilder/use-ext4
<cjwatson> smoser: eventually, the latter will become upstart jobs; any transition to that will be clearly announced and will be some time before the removal of the daemon
<cjwatson> smoser: for the meantime, just don't worry about it
<smoser> sorry for the misunderstanding
<smoser> i will aptly not worry
<kees> smoser: the ext4 thing should already be in lucid
<smoser> yes. but that doesn't concern me.
<smoser> the uec images are built form 0.11 (which is where this is valid)
<kees> ah-ha
<smoser> i have your patch, but looking at it i dont know why i do not get ext4 filesystems on my karmic and lucid and maverick images
<smoser> the only thing i can come up with is that they specify a partfile
<kees> how is vmbuilder invoked for you?
<smoser> (ie, --part)
<smoser> http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/annotate/head:/build-ec2-image
<smoser> (note, partfile does not include filesystem type -- that would have seemed to be the best way to do that)
<kees> hm, i've only tried it with --dest
<smoser> http://paste.ubuntu.com/442941/
<kees> smoser: when i originally debugged this feature, i had to add prints all over the place
<smoser> which is what i was trying to avoid by asking you.
<kees> smoser: yeah, i don't know it much better than that :)
<smoser> i think that set_filesystem_types must be getting overridden by my partfile
<smoser> (which again, doesn't specify it).
<smoser> thanks for your time.
<kees> smoser: np, let me know if you don't figure it out. i can take a lot tomorrow
<soren> smoser: I'm expecting to fix up EC2 builds with vmbuilder 0.12, if that matters.
<smoser> soren, right now its not an effort that i would want to take on.
<smoser> to move the official builds over to 0.12
<smoser> even if i did i'd still want to leave the released versions working from the 0.11
<smoser> just to make sure they dont just change (or otherwise verify that they're identical)
<smoser> do you happen, soren, to know what would be causing me to not get ext4 filesystems ?
<smoser> my interest is in turning those on for maverick but not for less than that.
<smoser> https://code.launchpad.net/~ubuntu-virt/vmbuilder/0.11 is the branch i build from
 * soren looks
<smoser> invoked as http://paste.ubuntu.com/442941/ with part file looking like "root ${size} a1"
<soren> smoser: Yes.
<soren> smoser: Using a part file always makes the filesystem ext3.
<smoser> thats what i thoguht. suggestions on how to fix/work around ?
<smoser> my feeling is that the partfile should allow specification of the filesystem
<soren> The whole partfile thing is horrible.
<soren> smoser: ...but that particular bug is fixed in 0.12.
<smoser> oh ? i dont see how.
<soren> smoser: Do you see the bug to begin with?
<soren> smoser: Then look at the same place in 0.12 and behold.
<smoser> i'm confused
<soren> I can tell. :)
<smoser> ah. i see it.
<smoser> nah. never mind. default_filesystem.
<smoser> i guess i can cherry pick that back
<soren> Hardly.
<soren> Unless.
<soren> Well, you can try. :)
<smoser> well, not cherry pick, but take that logic
<seb128> ogra, asac: do you need a stable archive now for armel alpha1 builds?
<asac> seeker: we probably dont want to skip an alpha
<asac> so would be nice to have some time to settle
<seb128> asac, was that for me?
<seb128> asac, sorry got to restart my irc
<asac> seb128: ;)
<asac> yes
<asac> for you
<seb128> asac, ok, I will delay the gtk update
<seb128> asac, let me know when I can update it ;-)
<asac> seb128: i am not responsible for mobile images anymore ;) ... ogra has to give thumbs up or not. maybe the images are busted anyway atm.
<asac> then it wouldnt matter much :)
<seb128> right, that's why I asked ;-)
<seb128> I'm not even sure alpha1 is in working state anywhere right now
<blueyed> Is AlwaysLoginCurrentSession=false not supported/ignored by gdm? Cannot find the string in gdm sources anymore. Would like to login to wmii besides awesome.. - so no gnome-protecting-itself required (which changed the default to true).
<blueyed> or is just UPDATE_CONFIG not support anymore, via gdmflexiserver --command="UPDATE_CONFIG AlwaysLoginCurrentSession=false" ?
<bluefoxicy> okay seriously
<bluefoxicy> why the assballs do I need debugging symbols
<bluefoxicy> whatever program is using these things to pull debugging information for bug reports is terminally broken
<cjwatson> bluefoxicy: if you can't be polite, please go somewhere else
<cjwatson> it's not clever
<bluefoxicy> cjwatson:  neither is my ISP, which sputters to death when I try to download a 2 meg file for debugging symbols for a 17k binary package(?!)
<cjwatson> that doesn't justify turning up here with foul-mouthed outbursts.  control yourself, please.
<bluefoxicy> It should be possible to just yank the mappings and the stack, and run with that; put that with the package version, and then run that through some program along with the debugging symbols later, come to the same results
<bluefoxicy> Or if that's not possible, take a (larger) core dump on demand, and download the debugging symbols then
<cjwatson> that is how apport normally behaves; users do not normally need to download debugging symbols.
<cjwatson> I don't know what's wrong in your case.
<bluefoxicy> cjwatson:  I had thought as much when it first came out; however at the moment my system seems to insist on downloading debugging symbols, which makes me believe something is broken ~_~
<cjwatson> the point of the retracer arrangement is so that users only need to upload reduced traces, and a central system retraces the stacks with the debugging symbols installed.
<cjwatson> yes, apparently something is.  I suggest you file a civil-toned bug on apport
<bluefoxicy> as soon as I figure out how/why it's broken
#ubuntu-devel 2010-06-02
<kees> lool: hm, mplayer did not like the directfb bump...
<pitti> Good morning
<pitti> superm1, Daviey: do you care about the mythbuntu amd64 oversizedness for alpha-1? If so, can you chop off some langpacks or so (11 MB) and ask for a re-spin?
<pitti> or are you interested in mythbuntu alpha-1 at all?
<superm1> pitti, langpacks?
<superm1> we don't do langpacks at all :)
<pitti> oh
<superm1> pitti, i'd say a1 isn't interesting yet, so no worries
<pitti> superm1: understood
<superm1> we haven't made any changes of significance for a1 at least
<pitti> superm1: so I won't post them to the tracker then
<superm1> pitti, awesome, thanks
<pitti> superm1: I agree; we can test kernel etc. through ubuntu/kubuntu
<pitti> and there's not much else so far
<pitti> well, installer and merges of course
<mneptok> remove X. it will take a lot of other big packages with it. "Mythbuntu. Enjoy your favorite videos as ACII art."
<mneptok> *ASCII
<mneptok> as a proof-of-concept, telnet to towel.blinkenlights,nl
<dholbach> good morning
<hrw> morning
* mthaddon changed the topic of #ubuntu-devel to: Launchpad down/read-only from 11:00 - 14:00 UTC for a code update | "Archive: soft-freeze for Maverick alpha1 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/Help
<hrw> mneptok: towel is very low ascii... "aptitude install bb" is more ascii
<netshine> hey all.
<netshine> hello all, i want to be an ubuntu developer and want to be an "Ubuntu Prospective Developers", is this program still work?
<BlackZ> netshine: you could start to do that without any problem
<BlackZ> netshine: eventually you could apply for MOTU and then ubuntu core dev
<netshine> BlackZ, that be great, im a computer science student and a java developer and using ubuntu science warty warthog
<netshine> :)
<BlackZ> netshine: a good way is to start by doing the packaging of the applications, check out https://wiki.ubuntu.com/MOTU/GettingStarted and if you have any question packaging-related please ask in #ubuntu-motu
<netshine> and i was trying to do some command (bzr: ERROR: connection closed. unexpected end of message. please check connetivity and permissions
<BlackZ> netshine: what are you trying to push?
<netshine> bzr branch lp:ubnutu/seccure seccure
<netshine> just like here: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/GettingTheSource (2a)
<BlackZ> netshine: are you getting "Permission denied (publickey)." first?
<netshine> nope .
<netshine> first i get:
<chrisccoulson> launchpad is undergoing maintenance
<netshine> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<chrisccoulson> that probably explains it
<netshine> oh, so i cant connect to launchpad? :-0
<ogra> though its supposed to only block the web UI
<BlackZ> netshine: I think that's the problem, as chrisccoulson said
<chrisccoulson> http://identi.ca/launchpadstatus
<ogra> seems ot be a bug that bazaar.lp.net is locked
<chrisccoulson> "Change to Launchpad roll-out time: the web UI will be read-only, other aspects offline"
<netshine> oh. :-0
<netshine> too bad why now :! :)
<chrisccoulson> ;)
<netshine> anyway, im in the right way?
<netshine> (Sponsorship process)
<ogra> netshine, to make releasing the milestone of ubuntu maverick more exciting :)
<BlackZ> netshine: have you did something packaging-related ?
<netshine> ogra, how can i do it?
<netshine> BlackZ, no, :-(
<netshine> but i am a java developer, and c also.
<BlackZ> netshine: that's a good way, for the packaging isn't required an high level of development experience
<ogra> netshine, wait until LP is back in RW mode
<netshine> np.:)
<netshine> so theres another way to be a "offical developer"
<netshine> officially
<netshine> **
<BlackZ> netshine: please read https://wiki.ubuntu.com/UbuntuDevelopers
<netshine> i was reading it, because of that i am here.
<BlackZ> it's sure that you can't become a developer in 2 days but with the time I think you can
<netshine> of course, 2 days its impossible target.
<netshine> but i want to know, if "ubuntu prospective developers" is the right way, or there a different way to do so.
<BlackZ> e.g. 6 months are enough for become a MOTU, if you have demostrated your skills
<BlackZ> (merge, packaging work, bug fix ...)
<highvoltage> hey BlackZ
<BlackZ> hi highvoltage
<BlackZ> netshine: "prospective developers" is the first way
<netshine> BlackZ, i think i will be happy to be more then motu (no offense)
<BlackZ> netshine: if you're able to do why not?
<netshine> :-)
<BlackZ> but I'd join the MOTU team first
<ogra> you have to ...
<highvoltage> BlackZ: I saw your contributing developer application, glad that you're following through
<netshine> ok, so to looked more information about MOTU?
<ogra> you have to either be MOTU or a delegated team developer before applying for core-dev
<BlackZ> netshine: read all pages on the wiki
<BlackZ> they're very clear
<BlackZ> highvoltage: well, I will try to join that
<netshine> ogasawara, delegated team, require me to be a ubuntu member, and i think im not will fit to them.
<netshine> http://wiki.ubuntu.com/netshine
<BlackZ> netshine: if you join the MOTU team you will be an ubuntu member too
<netshine> oh yes, i can see now... better start working on that :-)
<BlackZ> also, for join the MOTU team the ubuntu membership isn't required
<BlackZ> as you can become an ubuntu member joining it, as I said
<netshine> i understand you, and i reading now the "getting started with motu"
<netshine> :0)
<highvoltage> netshine: there's a channel #ubuntu-motu which is a great place to get going and also has some important links in the topic you might want to look at
<netshine> highvoltage, thank you, will working it now.
<netshine> seems like a mute-channel over there
<netshine> :-0
<netshine> ogra, when you talked before about ubuntu maverick
<netshine> you talked about "preparing new revisions?"
<ogra> alpha1 is in the works, yes
<netshine> i dont know what to choose :_)
<netshine> Preparing Patches | Preparing new Revisions |  Preparing New Packages
<netshine> what the most recommended "class?"
<netshine> :)
<netshine> launchpad works fine now..
* mthaddon changed the topic of #ubuntu-devel to: "Archive: soft-freeze for Maverick alpha1 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/Help
<pitti> mthaddon: thanks for finishing early :)
<\sh> gnarf
<\sh> https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#Bonded network interfaces must use hotplug-style configuration <- this doesn't work in karmic, but lucid release note says it was introduced in karmic...
<mthaddon> pitti: no problem - glad to be able to get it all back up quicker than expected
<Riddell> ccheney: you mentioned that openoffice uses poor fonts if ttf-liberation isn't installed, is there a bug for that or could you report a one (against kubuntu-meta) with a quick explanation so we can do the SRU?
<ccheney> Riddell, ok will do
<ccheney> Riddell, 588723
<Riddell> thanks ccheney
<ccheney> Riddell, actually it probably happens for all of the fonts listed as 'Microsoft Fonts' falling back to 'PostScript Fonts' which are incompatible, eg Arial as well, etc
<ccheney> i think we need both nimbus for postscript and liberation for microsoft installed on all systems using fonts
<ccheney> at least from what i can tell
<smoser> cjwatson, are you aware of anything that changed in maverick that would have resulted in generation of ssh private keys during boot ?
<cjwatson> no
<Keybuk> doesn't the ssh init script generate them if they're missing?
<soren> Keybuk: No :(
<smoser> hmm... so in the UEC images, i remove the ssh server's private and public keys. then, on boot, they're generated by cloud-init.
<soren> Keybuk: bug 246558
<ubottu> Launchpad bug 246558 in openssh (Ubuntu) "ssh's init script should generate host keys if they're missing" [Low,Confirmed] https://launchpad.net/bugs/246558
<smoser> the test cases i have keyscan, save the output to a known hosts, and then ssh to the host
<smoser> in 1 instance out of 100+, i received a "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED"
<smoser> ie, it changed between when i keyscanned and when i subsequently sshed.
<showard> Hi I wanted to draw attention to bug #588714 . Debian's python-debian changed it's package name from debian_bundle to "debian," so every autoimport that uses javahelper and other tools that "import debian.deb822" failed.
<ubottu> Launchpad bug 588714 in python-debian (Ubuntu) "Please merge python-debian 0.1.16 (main) from Debian unstable (main)" [High,Triaged] https://launchpad.net/bugs/588714
<showard> I started working on it, but have to head off to work (another ubuntu package is causing a problem somewhere, I posted it on the bug report)
<showard> here's an example buildlog from one of the autoimports http://launchpadlibrarian.net/49513348/buildlog_ubuntu-maverick-i386.arduino_0018%2Bdfsg-1_FAILEDTOBUILD.txt.gz
<showard> the packages will build (and will need to be rebuilt) once bug #588714 is fixed
<ubottu> Launchpad bug 588714 in python-debian (Ubuntu) "Please merge python-debian 0.1.16 (main) from Debian unstable (main)" [High,Triaged] https://launchpad.net/bugs/588714
<smoser> TheMuso, are you around ?
<smoser> using mumble we've bound the windows key to "push to talk", but ever so often, some combination of keys results in a seriously zoomed display.
<smoser> we dont' know how to get out of that mode
<smoser> anyone able to help ?
<apw> smoser, its something like windows and a number
<arand> smoser: windowskey+scrollwheel
<smoser> arand, thank you!
<arand> smoser: It's the compiz zoom, if you hold down the superkey and click with the middle mouse button, you can drag a "zoom box" what happens is that if you just click, the zoom box is minimal, and you zoom in as far as at possibly goes.
<apw> smb, yeah and you can simply turn that off in the compiz-settings manager
<apw> under 'enhanced desktop zoom'
<apw> smoser, ^^ not smb
<smoser> apw, yeah, thanks.
<smb> *phew*
<arand> I wonder if it shouldn't be a papercut, since I've had a couple of people with similar issues...
<ion> Perhaps just a small box in a screen corner saying âto scroll out, hold down the Windows key and use the scroll wheelâ while zoomed in. And it could fade out over a period of, say, 10 seconds. :-P
<ion> zoom out
<Keybuk> I still haven't found anything I can use for mumble push-to-talk that doesn't do something else
<arand> ion: Well, the quickest solution is simply to disable the "zoom box" accelerator by default.. But I guess it could be done in a nicer way, if time be.
<smoser> Keybuk, so, you were hoping to find a key on your keyboard that did *nothing* else ?
<smoser> it really doesn't seem likely that at this point there wouldn't be a key that no one had ever said "hey, that doesn't do anything else, i'll bind to it"
<Keybuk> smoser: I even tried using the extra mouse buttons that I've never clicked - but it turns out they do other things too
<Keybuk> it's not so much a key that does nothing else
<Keybuk> but finding something that doesn't have a side-effect
<Keybuk> right now when I'm talking on mumble, I have to stop using my computer entirely and make sure no window is focussed, and make sure the mouse is pointing at the desktop
<Keybuk> just to avoid unintended side-effects
<Keybuk> that seems pessimal
<smoser> yeah, thats why we've used the windows key.
<Keybuk> I use the Windows key all the time for window management
<Ng> how about Pause? :)
<Keybuk> Ng: the BREAK key? :p  try pressing that in a terminal
<Ng> it's not Break until I hit Fn-Pause on this kb
<james_w> I'd quite like to be able to rebind caps-lock as a toggle
<cjwatson> right-control works well for me.  it probably does something else, but not much important
<Keybuk> cjwatson: I use right-control when typing
<Keybuk> for the keys on the RHS of the keyboard
<Keybuk> likewise right-shift, etc.
<cjwatson> I think my habits are otherwise so it works out
 * popey puts http://www.find-me-a-gift.co.uk/the-panic-button-usb-toy.html on Keybuks christmas list
<Keybuk> lol
<Keybuk> didn't slangasek have one of those? :)
<popey> i can only imagine shouting after pressing one of those.
<ion> Thereâs the Emergency Power Off circuit in my UPS. One could connect a big red button to it. That would be fun.
<smoser> well, i sorted out my issue with apparent ssh keychanging.  i had started 5 instances, shut them down, and started them back up. on restart, they get different IP addresses than the first time.  this is the first time that it has happened in my tests that an instance got an IP on restart that was used by a different instance on first start.
<ion> Huh. My Ubuntu desktop shows â¥ U+2665 as a pair of eighth notes instead of the heart symbol.
<ion> With the Monospace font alias.
<hrw> ion: switch to Terminus font
<taavikko> is it a bug in gst-plugins-good or in gst-bad when: The following packages have unmet dependencies: gstreamer0.10-plugins-good: Conflicts: gstreamer0.10-plugins-bad (< 0.10.18.2) but 0.10.18-2ubuntu1 is to be installed.
<hrw> popey: this toy does not work under linux
<popey> :(
<hrw> popey: it is recognized as input device but does not generate keycodes (at least did not when I got such one)
<hrw> but let me recheck
<popey> there are lots available of different types, maybe the canonical store could make one and sell it as a "mumble button"
<hrw> [105744.676595] generic-usb 0003:1130:0202.0005: input,hidraw4: USB HID v1.10 Device [Panic Button] on usb-0000:00:1a.7-4.4.4/input1
<hrw> popey: http://paste.ubuntu.com/443405/
<popey> booo
<hrw> same on event5
<hrw> ~curse xinput for 8bit keycodes
<gord> hrw, disable capslock in keyboard preferences and use that? or maybe use the middle mouse button
<\sh> http://www.ubuntu.com/desktop/get-ubuntu/download -> 64-bit - Not recommended for daily desktop usage ... who came up with this idea
<hrw> gord: ?
<superm1> \sh, until multiarch is in place and /stable/ flash perhaps
<gord> hrw, sorry, not you Keybuk
<\sh> superm1, come on... 64bit + chromium flash
<\sh> works very nicely
<\sh> that's all a simple user needs
<hrw> doko: are you able to crosscompile gcc-4.5/maverick?
<doko> hrw: haven't tried
<hrw> doko: gcc-4.4/maverick crossbuilds fine
<superm1> stable as in blessed from adobe, i mean, not 'works for me for the sites i visit reliably'
<hrw> doko: http://paste.ubuntu.com/443411/ - I should report that as a bug with attachment - right?
<hrw> doko: that change is needed to pass "echo armel >debian/target;fakeroot debian/rules control" step
<\sh> superm1, well...I can't confirm that statement...my wife works with 64bit Ubuntu since hardy and she's happy, which means I'm happy too ... ;)
<hrw> \sh: as long as she avoids adobe flash it is fine
<doko> hrw: sure, is this all what is needed?
<\sh> hrw, she uses it now on lucid just with chromium-browser
<hrw> doko: just to pass control target. "fakeroot debian/rules binary" fails with http://paste.ubuntu.com/443415/
<hrw> doko: http://paste.ubuntu.com/443417/ is full log
<ScottK> mvo_: Kubuntu is very usable right now .... (re #ubuntu-meeting)
<ScottK> ;-)
<slangasek> Keybuk: yes, it registers as a USB HID device supporting LED only
<mvo_> ScottK: heh :)
<\sh> ScottK, on monday I had the kde screensaver running for at least 3 hours...when I came back, everything scattered and somehow it looked like a CPU blast or mem leak...I have to repeat it at some time...:(
<doko> hrw: hmm, need to find out why the plugin support isn't detected for cross builds
<hrw> doko: ok
<hrw> doko: in meantime I will work with gcc-4.4/lucid
<hrw> doko: https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/588788 has patch for gcc-4.5/debian/patches/cross-fixes.diff
<ubottu> Ubuntu bug 588788 in gcc-4.5 (Ubuntu) "fix "control" target for cross builds" [Undecided,New]
<doko> hrw: I thought you were working on the cross builds?
<hrw> doko: I can look at the plugin problem
<Q-FUNK> re
<cjwatson> Q-FUNK: I can't find your bug number
 * hyperair wonders if anyone from motu-sru is around
<Q-FUNK> cjwatson: https://bugs.launchpad.net/bugs/587186
<ubottu> Error: Could not parse data returned by Ubuntu: list.index(x): x not in list (https://launchpad.net/bugs/587186)
<Q-FUNK> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186
<ubottu> Error: Could not parse data returned by Ubuntu: list.index(x): x not in list (https://launchpad.net/bugs/587186)
<Q-FUNK> argh
<Q-FUNK> ubuttu went belly up?
<cjb> Hi folks.  geode doesn't have NOPL, which is an long form of nop that isn't particularly documented, and not officially part of i686, but gcc has started emitting it anyway.
<Q-FUNK> cjb: thanks for joining.  we were discusing https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186 and I could not rememebr which instruction the Geode LX is missing to become a full 686.
<ubottu> Error: Could not parse data returned by Ubuntu: list.index(x): x not in list (https://launchpad.net/bugs/587186)
<doko> hrw: are you sure about http://paste.ubuntu.com/443411/plain? removing the #endif, but keeping the #ifdef?
<hrw> doko: checked file and it looks for me like matched endifs - will compare with 4.4
<Q-FUNK> cjb: or for that matter whether the GX2 and older GX1 and SC geodes also have the same instruction set.
<cjwatson> what did the gcc folks say when this was raised with them?
 * cjwatson trawls through what looks like the relevant lkml thread
<doko> hrw: hmm, doubt it, the file already starts with a '#ifndef inhibit_libc'
<hrw> doko: marked bug as invalid
<cjwatson> -mtune=generic32 is supposed to prevent the NOPL business
<hrw> will prepare better fix to get patch apply
<cjwatson> doko: ^- would it be worth setting the equivalent of that in our specs?
<cjwatson> cf. http://lkml.org/lkml/2008/9/8/296
<cjwatson> see also the description for X86_P6_NOP in linux/arch/x86/Kconfig.cpu
<cjwatson> doko: (shall I add a gcc-4.4 task to Q-FUNK's bug for this?)
<Q-FUNK> cjwatson: if we can fix it with this simpe -mtune=generic32, let's try it.
<Q-FUNK> cjwatson: I can report on the results, if the gcc-4.4 task is added and libc6 recompiled with it.
<Q-FUNK> cjwatson: I added the nit about -mtune to the bug.
<ccheney> what do i need to do to request a package from debian that isn't currently in Ubuntu? i need both mdds and mythes to be pulled in
<Q-FUNK> ccheney: requestsync with the new package option
<ccheney> Q-FUNK, ah ok, i was wondering if it was similar to a regular sync
<Q-FUNK> ccheney: requestsync -n
<ccheney> Q-FUNK, thanks for the help :)
<Q-FUNK> welcome :)
<blue_anna> hey, anyone here understand argyll ?
<hrw> doko: http://gcc.gnu.org/viewcvs/branches/gcc-4_5-branch/gcc/config/sh/linux-unwind.h?r1=138078&r2=145442 - I will drop that part from cross-fixes.diff then
<LucidFox> So, which theme in Maverick was it again that had CSD enabled?
<doko> cjwatson: will look at it tomorrow, leaving now
<cjwatson> thanks
<akgraner> robbiew, you around?  If so do you 5-or 10 mins
<robbiew> akgraner: yep
<Keybuk> http://tools.ietf.org/html/rfc4824
<Keybuk> I was doing ok until I saw the code for "Error", then I squeed
<lamont> evince (well, libpdf) is pissing me off
<lamont> there are these stupid pdfs on the web with a null password.  pdfcrack correctly finds it.  And yet evince has no way for me to provide a null password to the UI
<smoser> soren, fyi, regarding ext4 and --part: https://code.launchpad.net/~ubuntu-virt/vmbuilder/0.11
<smoser> its somewhat hacky, but commit 374 there has it.
<jono> is gwibber broken for you folks in maverick?
<arand> jono: there is some desktopcouch thingy...
<arand> jono: Bug #588478
<ubottu> Launchpad bug 588478 in desktopcouch (Ubuntu) "RuntimeError: Can not find port of couchdb. " [High,Confirmed] https://launchpad.net/bugs/588478
<ccheney> anyone around that can sync two packages for me? :)
<ajmitch> apparantly it can be done by that syncpackage script now, but I don't know if I should trust it yet :)
<ccheney> they are universe packages so shouldn't affect the alpha 1 freeze, and don't exist in ubuntu atm
<ajmitch> normal autosync has a bit of a queue still for new packages?
<ccheney> well its not syncing two i need for OOo in any case, not sure why though
<ccheney> i need mdds, and mythes for OOo 3.2.1
<ajmitch> probably because they get at least a bit of a manual review
<ccheney> ok
<ScottK> Actually not, it's because getting new packages is a different script then just a regular sync.
<ajmitch> ScottK: glad to know I'm wrong, either way an archive admin needs to look at them?
<ScottK> No.  We trust Debian ftp-master to get stuff right.
<ScottK> If they don't, we're already hosed on many levels.
<geser> AFAIK the archive admins check if syncing new packages doesn't re-introduce packages that got removed from Ubuntu in the past
<ScottK> That's true.
<geser> and this a cumbersome task with a long list of new packages
<Laney> If you need one specifically then just file a request or poke an AA with shell access
<tormod> should demoting/seed-dropping bugs have ubuntu-archive subscribed?
<cjwatson> yes
<cjwatson> well, if it's urgent
<tormod> cjwatson, not really urgent
<tormod> bug 588935
<ubottu> Launchpad bug 588935 in linux-wlan-ng (Ubuntu) "please drop linux-wlan-ng from ship-live seed" [Undecided,New] https://launchpad.net/bugs/588935
<doko> cjwatson: the -mtune=generic32 is an assembler switch, not a compiler switch, prepared an upload to pass this by default, will upload after the alpha
<cjwatson> doko: cool, thanks
<TheMuso> smoser: I am now.
<ccheney> doko, uploading OOo 3.2.1 tomorrow with -marm removed as you requested, let me know if it needs to be added back later :)
#ubuntu-devel 2010-06-03
<skypce> hi, can you add a extra functionallity to gnome, every time when i view a video the screen after of 3 minutos (my configured time) the screen change to black, can you add a rule that say when the process totem playback a video (by example), deactivate screen off function,. when totem stop activate again the screen off . i will be happy if you change this. thanks
<skypce> sorry view=watch
<skypce> uff
<smoser> TheMuso, thanks for responding, i got answers to my questions from others.
<smoser> (regarding windows-key-zoom)
<TheMuso> smoser: np
<TheMuso> ah ok
<robert_ancell> StevenK, can you have a look at pygi for me (in NEW queue)
<dholbach> good morning
<didrocks> good morning dholbach
<dholbach> hi didrocks
<ajmitch> didrocks: oh, I gave a talk at the local python user group about quickly, people were impressed :)
<didrocks> ajmitch: sweet! I hope you tell them to join #quickly in case of any trouble (0.4.3 will be out next week as an SRU for lucid btw ;)). Thanks :)
<LucidFox> You know, when I do a Google search for Wayland, the numbet of results incorrectly calling it an X server is shocking
<LucidFox> Granted, those are mostly news articles, and journalists aren't generally famous for doing their research.
<RAOF> LucidFox: The git repo summarises it best: âWayland: a tiny somethingâ
<LucidFox> Heh, indeed
<LucidFox> I wonder, however, if Wayland is merely the next "sooo much less bloated than X" server that will eventually be doomed to obscurity
<LucidFox> the last commit in that git is March 30
<RAOF> As I understand it, it's not likely to ever be more than a skunkworks âhow little do we need in a display serverâ project, although it's not unlikely that techniques & technology from it will end up in a future Xorg.
<LucidFox> Bwuh :(
<LucidFox> I really would like to see a move to a leaner windowing system, with a rootless X server for legacy applications
<LucidFox> (i.e. like what Mac OS X does, from what I understand)
<LucidFox> sadly, looks like X will remain in its place for years to come
<pwnguin> didnt someone patch Xorg to run rootless?
<pwnguin> or am i thinking of a different kind of rootless
<LucidFox> rootless means running X clients in another window system, basically
<RAOF> Yeah, X itself isn't going anywhere.  Legacy applications FTW!
<LucidFox> like Xming on Windows, which creates windows inside the native window manager
<LucidFox> Mac OS X has a similar approach, it renders X clients inside native windows. The problem is, for Linux, the native window system is... X.
<RAOF> The X protocol bits might end up being a loadable module of the server; there seems to be a broad âyeah, that's what I'd do if I had the time to hack on itâ feeling on the Xorg list.
<LucidFox> Well, as long as you support Xlib, you support all the ugly legacy protocol stuff.
<RAOF> Yeah.
<RAOF> But no one uses the original X protocol for drawing; you use RENDER.
<RAOF> There's a lot of that protocol stuff that is basically never touched.  Font servers, anyone?
<RAOF> In other news: yay!  sbuild works on Maverick again!
<LucidFox> Yes, but Xlib doesn't know that modern-age toolkits only use a small subset of the X functionality. So ultimately it will boil down to porting GTK and Qt (at least) to another backend.
<RAOF> What's the difference between âGTK uses a subset of Xlib + the modern extensionsâ and âGTK uses a different backend, and Xlib still existsâ?
<LucidFox> Because using Xlib will force the Next Gen Leaner Meaner Display Server into X compatibility mode?
<RAOF> I don't see why - the modern extensions can do whatever they want.
<LucidFox> Well, (in this completely hypothetical scenario) Xlib would still use the X protocol, correct?
<RAOF> Yes
<RAOF> I guess my question is: what's so terrible about the X11 protocol that iterative extensions can't fix :)
<LucidFox> That it's X. A bloated, 26-year-old monolithic mess of hacks and extensions designed to fit a square peg into a round hole.
<LucidFox> If something advertises itself as an X server, it means there's a lot of stuff that nobody uses yet the server must support.
<RAOF> That code can safely sit and mellow.  Or concievably be dynamically loaded.
<RAOF> Also, doesn't _quite_ describe current reality; there's some X stuff that Xorg doesn't actually support (Zaphod, for example)
<nzmm> just wondering, if i switch my source.list from lucid to maverick, i get maverick, i have seen few updates...
<nzmm> whats the 'official' way to upgrade to a dev version?
<nzmm> upgrade-manager -d?
<zyga> nzmm, yes
<LucidFox> update-manager -d, but yes
<nzmm> ok cool
<zyga> nzmm, do-release-upgrade -d
<nzmm> ta
<zyga> nzmm, it might not be enabled yet though ymmv
<RAOF> Except that won't work yet, because it hasn't been turned on :)
<nzmm> yep just saw
<nzmm> so doing a replace all in sources.list is ok?
 * ajmitch should probably try an upgrade to lucid from hardy now :)
<arand> nzmm: I think it actaully has been enabled, mvo mentioned it in +1 before...
<nzmm> arand: oh, well maybe the fact i already replaced_all kinda screwed my ability to do that now :(
<nzmm> but in prinicpal replace_all in sources list is ok?
<arand> nzmm: Well, that's what do-release-upgrade does, afaik, along with disabling your PPAs
<nzmm> oh...
<nzmm> ok
<nzmm> thnx
<mok0> package.ubuntu.com search sux big time
<mok0> It doesn't know ANY maverick packagse
<joaopinto> cjwatson, can you fix the bug about the wrong default timezone for Portugal ?
<cjwatson> joaopinto: not at the moment no, sorry
<geser> mok0: known problem
<cjwatson> joaopinto: busy with alpha-1
<joaopinto> uff, a trivial server side issue open for so long  :(
<joaopinto> the last time it was the final release, now it's alpha :P
<mok0> geser: I see, thanks
<dpm> hi cjwatson. Do you happen to know if there is anything needed to do to a package to enable translations of the long and short descriptions from the control file? I know translations are fetched from the Translations-$LANG files from the archive, but I'm not sure if just dropping translations in the right archive folder is enough or if there is additional work required on the package
<cjwatson> I confess I'm not entirely sure what the DDTP stuff involve
<cjwatson> s
<cjwatson> but I've never heard of any package-specific work being required
<cjwatson> I thought that there was a custom upload job somewhere that dealt with it
<dpm> cjwatson, ok, thanks. I'll wait until mvo comes back tomorrow to ask for more details, as he's the one doing the DDTP uploads. I couldn't find any documentation on how this works
<cjwatson> it's one of the bits of the archive I'm almost completely unfamiliar with :)
<cjwatson> although I think there are a couple of archive bugs open that will necessitate me figuring it out
<dpm> :)
<dholbach> dpm: mvo would know
<dholbach> oh ok, nevermind
<dpm> dholbach, :)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/libutempter/+bug/589103 => is this a correct mir report?
<ubottu> Ubuntu bug 589103 in libutempter (Ubuntu) "[MIR] libutempter" [Undecided,New]
<anon^_^> hi, is this the proper place to note errors for ubuntu.com and relevant subdomains
<dupondje> anon^_^: what errors ?
<anon^_^> http://packages.ubuntu.com/lucid-updates/
<BlackZ> anon^_^: what's wrong there?
<anon^_^> click on it
<anon^_^> "
<anon^_^> Error
<anon^_^> more than one suite specified for show_static (dapper dapper-updates dapper-backports hardy hardy-updates hardy-backports intrepid intrepid-updates intrepid-backports jaunty jaunty-updates jaunty-backports karmic karmic-updates karmic-backports lucid)
<anon^_^> "
<BlackZ> anon^_^: send an e-mail at frank[AT]lichtenheld[DOT]de
<cjwatson> the contact address is at the bottom of the packages.ubuntu.com front page FWIW
<BlackZ> also, sorry I don't know where's the problem, maybe it's on re-fresh
<anon^_^> easier to report on irc, anyone know if frank's on freenode
<cjwatson> he's not on this channel at least.
<cjwatson> I suggest respecting the requested contact method.
<cjwatson> (packages.ubuntu.com isn't a service run by Ubuntu, although it's useful - it's actually a rebadged packages.debian.org run by the same person who runs that service)
<Ng> 2010-06-03 11:16:51.442 17240 FATAL @src/pooler.c:179 in function create_net_socket(): cannot parse addr: ''
<Ng> doh
<ScottK> lool: Are you going to be able to work on the gpsd MIR?  Once we build KDE against gpsd it affects packaging in several of the packages and I'd rather get it done sooner than later....
<panda|x201> Keybuk, Hi, around?
<ScottK> ccheney: Could I please have a test case for #588723 for the SRU.
<ccheney> ScottK, ok will see if i can find the most recent bug/document i received about it
<ScottK> ccheney: Thanks.
<ccheney> any sufficiently complex document written in a microsoft font should work, but i have one i know shows up poorly on kubuntu if i can find it again :)
<ccheney> ScottK, found the original bug and noted it in the report
<ScottK> Thanks.
<ScottK> ccheney: ttf-liberation is added in Maverick and uploaded to Lucid Proposed for Kubuntu.
<ccheney> ScottK, wonderful :)
<ccheney> ScottK, thanks!
<ScottK> No problem.  Thanks for letting us know.
<ccheney> ScottK, oh we probably need it on the netbook version also for the same reason, i noticed ubuntu-netbook doesn't have it either
<ccheney> ScottK, do you think i should file a separate bug about the ubuntu-netbook issue or just add another task?
* cjwatson changed the topic of #ubuntu-devel to: Maverick alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/Help
<Gadi> hi, all. how does ubuntu preseed network manager on a livecd such that it automatically tries to set up the wireless network? I am having trouble finding where the magic is
<ScottK> ccheney: My fix covered Kubuntu Netbook Remix.  No idea about UNE.
<ccheney> ScottK, ok
<ccheney> davidm, would you like a separate bug from 588723 for UNE?
<davidm> ccheney, UNE is cared for by rickspencer3 so you might check in with him.
<ccheney> davidm, oh yea i forgot it moved
<didrocks> ccheney: well, I hoped you knew I was in charge of UNE :)
<ccheney> didrocks, yea somehow slipped my mind, heh
<ccheney> didrocks, see 588723
<didrocks> ccheney: can you open a new task on the same bug, please and assign to me?
<didrocks> I'll take care on Monday, time for early week-end :)
<ccheney> didrocks, ok
<didrocks> ccheney: thanks
<slangasek> kirkland: any chance I can assign bug #587858 to you, since it's your patch causing the delay? :)
<ubottu> Launchpad bug 587858 in pam (Ubuntu) "update-motd executed even in non-interactive sessions" [Undecided,New] https://launchpad.net/bugs/587858
<kirkland> slangasek: sure
<slangasek> kirkland: done, ta
<kirkland> slangasek: i won't be looking at this soon, but i'll keep it on my plate
<slangasek> I wouldn't be looking at it any sooner :)
<flupke> hello, I'm making my first package, could someone explain me the "Starndards-Version" field of control files ? Can I just leave the "3.8.333" that I found in another package and forget about it ?
<ebroder> flupke: That's the version of Debian Policy that your package is compliant with
<flupke> ebroder, yep I read that in the docs, however I'm not sure what version of Debian Policy my package complies with (and where to find these versions)
<slangasek> flupke: do you mean 3.8.3?  You should never see 3.8.333 in that field; when packaging you should use the current Debian Policy version number there, and make sure in the process that your package /complies/ with that version too :)
<slangasek> flupke: apt-get install debian-policy
<flupke> slangasek, ok thanks !
<jdub> doko_: you about? (q. about clang/dragonegg)
<arand> Do I need to use gpg in order to send to ubuntu-devel? I sent a post way before UDS about swap-to-file which still hasn't cropped up...
<arand> ...and I've had no response as to it being rejected (is there one? if not there should be I think, if simply automated).
<geser> arand: most likely it's still in the moderation queue
<ajmitch> I don't think there are many people who do moderation on u-d, sadly
<arand> Then that queue must be fairly long by now... I reckon.
<arand> I mean it would be simple enough to just state that ubuntu-devel is only for registered, and -discuss is for all else, if it's in practice "impossible" to post anything to -devel anyways it's likely better to inform that this is the case. I wouldn't mind it, just as long as it was clear. ( I guess CJW [listed as mod] has quite a lot of things on his hands otherwise...)
<LLStarks> slomo, is the gstreamer aware that -bad is busted in maverick and has been for almost 10 days?
<LLStarks> *team aware
<LLStarks> the directfb update killed it
<ajmitch> morning
#ubuntu-devel 2010-06-04
<slangasek> lifeless: hi, would you know why http://package-import.ubuntu.com/status shows 8 jobs running since Sunday, and 926 pending?
<lifeless> no I don't
<lifeless> but I can try to find out
<lifeless> I suspect they're all borked.
<lifeless> actually, this is ops, time to agitate a little ;)
<lifeless> losa ping
<spm> lifeless: I have no idea what system that even is. I shall investigate.
<lifeless> spm: ahha :)
<lifeless> spm: so, I do; I think I even have a login to debug things
<lifeless> but I think really, that we should be productising it, not fiddling. So I'd like to get whatever the failure is turned into a losa-filed-bug on udd
<spm> ah. coolio. hints appreciated :-)
<lifeless> spm: what was the first db server, ever :)
<spm> Oh I see. right. wonder if I still have a login there....
<spm> ew. that looks *badly* hung
<lifeless> ok
<lifeless> so issues:\
<lifeless>  - no alert to tell you that it was in trouble
<lifeless>  - no docs telling you where to go
<lifeless>  - and the hang itself
<lifeless> anything else you can think of? should we do an actual incident report here [I don't think so, its overkill, I think]
<spm> heh. no privs to do anything about fixing it. this is in one of those greyish areas of ownership I'd suggest.
<lifeless>  - no privs
<lifeless> ok
<lifeless> was it tungsten ? no.
<lifeless> darn, I've forgotten the actual machine name myself
<spm> jubany
<lifeless> thats right
<spm> istr this is a james_w special, but I'll ask paul to have a look. he may be able to see enough to effect a fix
<lifeless> actually, emperor was the first db server, FWIW
<lifeless> *I think*
<spm> haha. yes. james_w. "...please email James Westby."
<lifeless> right
<lifeless> except thats now stale
<lifeless> the handover-to-production step isn't complete though
<lifeless> odd
<lifeless> I can log into chinstrap, but logging in jubany is appearing to time out
<lifeless> spm: you logged in ok ?
<lifeless> spm: ok, so look up
<lifeless> do you agree with the list of issues
<lifeless> there's an implicit root cause we can think about later
<spm> in general terms? yeah. issues around who should have ownership may superceed some of that; but that's just usual politics. :-)
<lifeless> I know james_w wants more folk to help out
<lifeless> thats why I have a login
<lifeless> it doesn't make sense to me for losas not to, though
<lifeless> so I'll file some bugs
<lifeless> and raise some questions, and what comes out, comes out
<lifeless> what should I do, to these bugs, to say 'losa should care about how/when resolved' ?
<spm> just add us as subscribers, or point me at 'em and I'll do it
<ScottK> lifeless: Wasn't it discussed at UDS about transitioning the UDD stuff to be more 'production' and IIRC losa supported?
<lifeless> ScottK: I didn't get to all the udd sessions
<lifeless> ScottK: but meh, just doing it:)
<lifeless> its clearly the right thing to do
<spm> lifeless: slacker!!
<lifeless> bug 524173
<ubottu> Launchpad bug 524173 in Ubuntu Distributed Development "package-import uses james_w credentials" [Critical,Triaged] https://launchpad.net/bugs/524173
<lifeless> spm: hey, bzr sprint concurrent, balance in all things
<ScottK> Right, well I think it was actually agreed that this would happen, so you're DTRT...
<james_w> I can't seem to strace any process right now
<spm> james_w: shouldn't you be in bed!?!? :-)
<lifeless> james_w: if you're trying 29087 I'm stracing it
<lifeless> james_w: go sleep, I'll track this down and so on
<spm> lifeless: (bzr sprint concurrent) and here I was thinking you're a demi-god; turns out you're merely superhuman. shame.
<lifeless> james_w: in particular, please don't unbreak it.
<lifeless> james_w: because I want to get solid diagnostics and may end up roping in a gsa to install debug python stuff if needed.
<james_w> right, it can be got to work again by just killing all the import_package.py processes that are currently running and it should pick up again
<james_w> but if you can work out what socket it is hanging on that would be great
<lifeless> james_w: sure, will do my best
<lifeless> spm: bug 589521
<ubottu> Launchpad bug 589521 in Ubuntu Distributed Development "nagios monitoring of package imports needed" [Critical,Triaged] https://launchpad.net/bugs/589521
<lifeless> james_w: where did you say your docs where ?
<spm> subbed to 'em both
<lifeless> [if you haven't gone to bed yet :P]
<james_w> https://wiki.ubuntu.com/DistributedDevelopment/UnderTheHood/Importer/Operational
<james_w> fwiw there's an open RT for the last one
<lifeless> losa privs ?
<lifeless> whats the rt #
<james_w> (those docs can be found from following links from https://wiki.ubuntu.com/DistributedDevelopment)
<lifeless> spm: can you look at them and decide if you want them there, or a copy in your losa wiki area, or a pointer or whatever ?\
<james_w> hmm, can't find it, there's already a nagios script there for hooking up, and I'm sure I put it in an rt
<james_w> anyway, night
<lifeless> gnight
<lifeless> spm: bug 589523 - for when looking at hung jobs, to come along and say 'still happening'
<ubottu> Launchpad bug 589523 in Ubuntu Distributed Development "mass importer doesn't handle hung-inactive processes" [Critical,Triaged] https://launchpad.net/bugs/589523
<lifeless> spm: rt 39615
<lifeless> spm: but the other rt i filed seems to have gone awol - no reply from rt
<lifeless> spm: the other one was for bug 589521
<ubottu> Launchpad bug 589521 in Ubuntu Distributed Development "nagios monitoring of package imports needed" [Critical,Triaged] https://launchpad.net/bugs/589521
<spm> lifeless: (sorry was at lunch) given the docs are already wiki'd, it makes sense (to me, anyway) to leave 'em in place for now. with pointers from our collection to same, if we generate stuff that shouldn't be there, that can be dealt with if'n when it arrises
<lifeless> spm: right, I'm just saying, I'm not going to file a bug 'please document for losas'
<lifeless> as you know where it is right now, you can capture that now :)
<spm> heh
<lifeless> spm: and bug 589534
<ubottu> Launchpad bug 589534 in Ubuntu Distributed Development "imports can hang when talking to free.hands.com" [Critical,Triaged] https://launchpad.net/bugs/589534
<spm> kk
<lifeless> spm: and bug 589532
<ubottu> Launchpad bug 589532 in Ubuntu Distributed Development "imports hang from time to time when talking to the mass importer" [Critical,Triaged] https://launchpad.net/bugs/589532
<spm> ah. is that root cause?
<lifeless> My theory is this
<lifeless> free.hands.com locks up some imports
<lifeless> a bug in the control daemon causes it to stop handling stderr from other imports (fd 2)
<lifeless> then all the other imports lock up on progress bars or similar output
<lifeless> I've killed all the imports that were there and hung and its going again
<spm> coolio, sounds reasonable as a starter.
<dholbach> good morning
<Cynthia> Sorry about that. It seems this channel would be more suited for my question.
<Cynthia> I've been discussing a script for automatically optimising XML, SVG and PNG files on the Ubuntu LiveCD (and by extension, K/Xubuntu as well). Someone recommended that I code 3 debhelper scripts to perform these optimisations. I don't know Perl, and the dh_*'s in /usr/bin are made in Perl. What should I do?
<Cynthia> Whoops. I've been discussing... on the ubuntu-devel-discuss list* And scripts to perform these optimisations... on all packages*
<dholbach> yay, kvm works again with the new kernel!
<Cynthia> (Repeat from 20 min ago) I've been discussing, on ubuntu-devel-discuss, a script for automatically optimising XML, SVG and PNG files on the Ubuntu LiveCD (and by extension, K/Xubuntu as well). Someone recommended that I code 3 debhelper scripts to perform these optimisations on packages. I don't know Perl, and the dh_*'s in /usr/bin are made in Perl. What should I do?
<Cynthia> some 9 people joined since that repeat, sorry if that's too soon for repeating
<poolie> Cynthia, hi there
<poolie> that sounds useful
<Cynthia> Hi :)
<poolie> what languages do you know?
<Cynthia> I already have proof-of-concept code as a Bash script on the discuss list
<poolie> ok
<Cynthia> I know my way around Bash, Python, Java and uh... pretty much those
<poolie> so i don't know a lot about the internals of this but i would think that if you have code in bashe
<poolie> (bash
<poolie> *bash
<poolie> it would be pretty simple for somebody to add a line or two of perl to call them
<poolie> or are people specifically asking you to rewrite it?
<Cynthia> The problem is that the script I wrote acts on the LiveCD's iso, not packages
<Cynthia> And someone on -discuss said that the code would be better rewritten as dh_*'s so upstreams (Debian, etc.) could use them
<poolie> huh
<poolie> would i be right in thinking you can run "optimize_stuff *jpg *png" and it works?
<poolie> or is it more complicated?
<Cynthia> The second option was to "add this to package-mangler run by soyuz", which I'm unfamiliar with
<Cynthia> not really, poolie, because OptiPNG, Scour.py (for SVG) and xmllint each have their own calling conventions and the file types are completely different
<Cynthia> Plus, *.glade, *.ui and some more files also have an XML format, so dh_xmlopt would need to handle those with some debian/ file or command-line arguments
<poolie> ok but basically it takes in a file and spits out a smaller equivalent file?
<Cynthia> Yeah
<Cynthia> That's the gist of it
<poolie> so
<poolie> during debian packaging, there'll be a build directory containing the files that are about to be packaged
<poolie> this is controlled by some complicated machinery inside debian/
<poolie> what _I_ would try next if i was doing this is just patching those tools in to debian/rules
<Cynthia> Aye, I gathered this from the dh_* scripts already on my machine :) I can read Perl, just not write it :(
<poolie> to get the files squashed before the package is assembled
<Cynthia> hm
<poolie> and then put it into the dh_ scripts
<poolie> btw does it make much of a difference to the size of the iso?
<Cynthia> It trims 11.x MB
<poolie> out of 600-800MB?
<Cynthia> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-May/011504.html  Here's a thread from the archives if you'd like to skim what I've done so far
<Cynthia> 699 MB
<Cynthia> so my ISO is 687.x MB right now
<Cynthia> I'll actually download a source package before continuing about this, because I have no idea really what debian/rules is made of
<poolie> mm
<poolie> i think you should branch the source for some package you think is both reasonably simple, and likely to be helped by this
<poolie> without being broken
<poolie> and have a look at http://www.debian.org/doc/maint-guide/
<poolie> which explains how it works, but not necessarily in the most obvious way
<Cynthia> Oh... debian/rules is just a makefile! Guess I could just write 'find . -name "*.png" -print0 | xargs -P 2 optipng -o7' or something, right?
<poolie> as a first step
<poolie> it's not exactly right but it would get you going
<Cynthia> But the preferred way would be to code a dh_
<poolie> or perhaps to patch it into an existing dh used to install these files
<poolie> there's typically one per distinct class of thing to be installed
<poolie> roughly
<poolie> that will also give you a framework to say that some images can't be compressed
<Cynthia> Well, obviously I wouldn't optimise lossy files like jpegs, because that would look very ugly :)
<poolie> well, there may be some cases where the program doesn't like your changes
<Cynthia> I'll see what I can do. And I'll read the debian maintainer guide (your link) to get started. But I can't guarantee anything for a Perl dh_. Someone would need to pick up where I left off for that.
<Cynthia> I already know of some programs that don't like their XMLs stripped of whitespace, like gBrainy and gnome's theme thingy
<Cynthia> but PNGs pose no problem
<Cynthia> Thanks for the pointers :)
<Cynthia> Oh yeah, there was something else in that LiveCD optimisations thread. Basically, seeking to different files on a CD is very costly, so I reordered the files within the CD with `mkisofs`'s sort file option. What would be my best bet to have *that* included in the LiveCD?
<cjwatson> Cynthia: seems like the sort of thing that could perhaps reasonably be done as a patch to dh_compress
<cjwatson> Cynthia: file a bug on the debhelper package in Debian with a pseudocode description of what you want done, and the upstream author will probably be able to offer useful advice
<Cynthia> cjwatson: debhelper package... in Debian? does Debian use Launchpad, or would I need to post to a mailing list?
<cjwatson> http://www.debian.org/Bugs/Reporting
<Cynthia> thanks :)
<cjwatson> (you'll probably need to use the e-mail method - but it isn't a mailing list as such)
<cjwatson> basically mail submit@bugs.debian.org with "Package: debhelper" as the very first line of the message body
<Cynthia> Would you also happen to know how I would get my sort file for mkisofs included in the ISO build process for Ubuntu, and perhaps Debian?
<Cynthia> That's not a deb-packaging issue per se, but it's still a packaging issue... kinda :)
<Cynthia> Even better would be to 'readahead' the LiveCD and put all the files in sequence, but what I have is just '/bin at the end of the CD' and stuff.
 * hunger grumbles that maverick alpha1 does not boot here:-(
<cjwatson> Cynthia: is it a dynamically generated sort file?  if so how do you go about it?
<cjwatson> Cynthia: we actually already do some sorting
<cjwatson> Cynthia: um, but surely this wouldn't be for mkisofs, but rather for mksquashfs?
<Cynthia> Oh, that's nice then :D But my sort file is actually two, one for mksquashfs and one for mkisofs
<Cynthia> Sorry for the confusion
<cjwatson> Cynthia: in the latter case, we have the stub for sorting in place but it's never really been used
<Cynthia> I'll paste them on ubuntu's pastebin
<cjwatson> it really absolutely has to be generated on the fly somehow though - a hand-crafted sort file will just get out of date
<cjwatson> that's the tricky bit
<cjwatson> what mkisofs sorting are you doing?
<cjwatson> our handling at the moment only really deals with udebs and debs
<cjwatson> it would probably be worthwhile putting the live filesystem in front of that
<Cynthia> Yeah, I thought about using 'readahead' for this. But mine's just hand-crafted based on broad assumptions about the general directories that files are accessed from on-boot
<Cynthia> http://paste.ubuntu.com/444502/  Sort file for mksquashfs
<cjwatson> right, we can't do hand-crafting I'm afraid - if you can figure out some way to express it programmatically given having the live filesystem to hand, we could look at incorporating that into livecd-rootfs
<Cynthia> http://paste.ubuntu.com/444503/  Sort file for mkisofs
<cjwatson> Cynthia: for the mksquashfs bit, could you file a bug on the livecd-rootfs package in Ubuntu?
<Cynthia> Ok
<cjwatson> so, wait, I don't get it, why force all that stuff to the end of the media with huge negative weights?
<cjwatson> I thought that closer to the centre was generally fastere
<cjwatson> *faster
<Cynthia> On hard disks perhaps
<hrw> doko__: have a minute? I found why gcc-4.5 failed for cross build for me
<Cynthia> CDs are different
<Cynthia> About using readahead though, this couldn't really be automated unless you have a VM to run the ISO on, on your ISO build daemon
<cjwatson> I'm not considering hard disks
<doko__> hrw: sure
<hrw> doko__: http://paste.ubuntu.com/444508/ is ugly patch which solved problem for me. The reason for it is that gcc_cv_objdump is OBJDUMP_FOR_TARGET so it is ARM one but rdynamic check build host binary and then uses objdump to check for rdynamic support
<Cynthia> cjwatson: the testing I've done reveals that my ISO boots about 10 seconds faster, and all applications start faster than on the "vanilla" 10.04 CD. This is wall-clock time
<cjwatson> hard disks have higher throughout further away from the centre due to constant angular velocity - precisely the opposite of what I said above
<Cynthia> perhaps the pressed CD made by Canonical is made with constant angular velocity then - but my burner does constant linear velocity
<Cynthia> so when I burn it, it does a lot of noise at the start (centre) but then goes much quieter as it goes to the edge
<cjwatson> actually, with CDs, isn't the important bit really locality?
<cjwatson> minimise head movement and minimise the need to crank the velocity up and down
<Cynthia> yes, because seeks are very expensive
<doko__> hrw: hmm, would using using the binutils-multiarch binary help?
<Cynthia> so locality first, and putting things to the end of the media for CLV burners or to the start of it for CAV burners. right? I'll bring that up in my bug report
<cjwatson> ok, so moving the squashfs outwards tends to help because that means that it occupies less radial distance?
<Cynthia> yeah
<cjwatson> CAV => red herring I thin
<cjwatson> k
<cjwatson> it's not the burner that matters anyway, it's the reader :)
<hrw> doko__: I have to check
<cjwatson> so stuff like .disk and dists is probably not that relevant
<Cynthia> .disk is read by casper at boot
<cjwatson> I know
<cjwatson> but it'll be near where it's reading directory entries, which are in the centre, right?
<Cynthia> yes, the TOC is at the centre
<cjwatson> so I think it would be better to keep .disk and probably the kernel and such weighted high
<cjwatson> near the TOC
<Cynthia> with .disk's *files* far away from isolinux, though, I could see the "ISOLINUX DEBIAN" screen for like 20 seconds with lots of seeks
<Cynthia> that could work yeah
<cjwatson> certainly close to isolinux
<cjwatson> I agree it makes sense to try to cluster all the stuff together
<cjwatson> dists shouldn't be used until much later
<cjwatson> oh, wait, we run apt-cdrom during boot don't we
<cjwatson> that's a bit unfortunate
<Cynthia> That's the thing that creates the cdrom:[] entry for sources.list, right?
<cjwatson> right
<cjwatson> it's not in the live filesystem because we don't necessarily want it in the installed system
<Cynthia> yes I see logs for it in /var/log from the live CD
<cjwatson> ok, so this is the code that's dealing with mkisofs sorting right now: http://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/annotate/head%3A/tools/sorting_weights
<cjwatson> the kernel/initrd, .disk, and dists should automatically wind up right next to isolinux because the default weight is zero
<cjwatson> but possibly right now the squashfs sneaks in first because it's weighted zero too
<Cynthia> that's entirely possible
<cjwatson> so how about I change that to weight the squashfs dead last, and see what effect that has?
<Cynthia> be my guest :)
<Cynthia> Is there a script for the mksquashfs sort file as well?
<cjwatson> Cynthia: are you the poster of https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-June/011579.html?  I'd like to credit properly
<Cynthia> Yes
<cjwatson> Cynthia: apt-get source livecd-rootfs, livecd.sh would be where it needs to go
<cjwatson> at the moment, anyway
<cjwatson> but it's just a stub right now
<Cynthia> apt-get says something about bzr, should I get the very last version from bzr?
<cjwatson> probably won't make lots of difference in this case, but sure - lp:~ubuntu-core-dev/livecd-rootfs/trunk
<cjwatson> ok, so the next daily build should sort the squashfs last
<doko__> hrw: which stage is this?
<Cynthia> I know how to use Bazaar from my bout with Scour (Cleaning SVG Files), so maybe I could create a branch and edit the code. How about that? :) I'll file the bug and link the branch if I make code changes
<cjwatson> Cynthia: are you in a position to compare timings between the last daily build and the next one?  it would be nice to check the performance difference due to just that change
<hrw> doko__: it was first, but looks like binutils-multiarch helped (I am during build now)
<Cynthia> cjwatson: I have a CD-Rewritable I can use, and a stopwatch
 * cjwatson remembers to re-enable daily builds after alpha-1
<Cynthia> I'll download today's build right now, seeing as it might disappear tomorrow.
<hrw> doko__: if this one will finish then I will recheck without binutils-multiarch
<cjwatson> yeah, it might be old enough to get auto-purged, so good plan
<cjwatson> although today's build is just alpha-1, so you can get it from the URLs in the announcement, and that will stay around for a while
<Cynthia> oh :)
<doko__> hrw: yes, works around the problem. CC and gcc_cv_objdump have to match, maybe using CC_FOR_TARGET is the correct fix (but this doesn't exist in stage1).
<doko__> hrw: and there are two objdump calls
<cjwatson> Cynthia: thanks for looking at this, it's a tricky problem but worth solving
<Cynthia> cjwatson: You know that some banks allegedly give out Ubuntu LiveCDs to customers so they can bank safely online? I think that users will be glad to boot in the LiveCD faster, for such uses
<Cynthia> Plus, I think having 5 MB extra data in .pngs all over the CD is a waste :)
<hrw> doko__: CC in this test is gcc and in this moment it has to be host one
<doko__> hrw: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847
<ubottu> gcc.gnu.org bug 43847 in bootstrap "test for plugin is using wrong objdump for host != target" [Normal,New]
<hrw> hx
<hrw> doko__: thx, forgot to check gcc bugtracker
<cjwatson> Cynthia: oh, you don't need to persuade me of the usefulness of making it faster.  lucid should be really quite a lot faster than karmic due to the use-of-debconf optimisation work we did in casper, for one thing
<Cynthia> speaking of, I don't actually remember how fast or slow Karmic's CD was to boot
<hrw> shit
<hrw> sorry
<cjwatson> Cynthia: I forget what the speed improvement was - Jamie Bennett might remember.  IIRC we shaved off a third of the runtime or something like that
<Cynthia> awesome :D
<Cynthia> Oh btw the daily build for today is done downloading
<joaopinto> cjwatson, can you fix the PT timezone ?
<joaopinto> please
<Cynthia> cjwatson: Regarding our discussion of CAV versus CLV CD-ROM drives, you would be right. The burner doesn't matter, it's the reader that spins faster or slower at the centre. However, yes, locality of reference is still important. I'm filing that bug now.
<Cynthia> bug 589629
<ubottu> Launchpad bug 589629 in livecd-rootfs (Ubuntu) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629
<Cynthia> you might have a laugh at my poorly-drawn CD layout
<Cynthia> but it illustrates the point
<\sh> slangasek, would it be a big act to update the examples in ifupdown on karmic and do an SRU for that? and to update the release-nots on lucid for ifenslave-2.6 (bonding interfaces) because they are wrong now
<Cynthia> cjwatson: repeat from an hour ago, bug 589629
<ubottu> Launchpad bug 589629 in livecd-rootfs (Ubuntu) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629
<Cynthia> am I actually allowed to make a branch in the debian-cd and livecd-rootfs packages?
<cjwatson> Cynthia: you can always make personal branches - the bit straight after ~ should be your LP username
<cjwatson> (I'm not going to be able to look at that bug straight away, sorry, but that's what a bug tracking system is for, to make sure things don't get lost)
<Cynthia> cool, I just thought creating branches in those packages was restricted to ubuntu core devs
<Cynthia> mk, no worries
<cjwatson> the naming scheme is ~OWNER/PROJECT/BRANCHNAME - you can set a different OWNER freely
<Cynthia> I know how to create branches, I just didn't know if I had permissions to :D
<Cynthia> Thanks though
<Notch-1> hi, any known issues with networkmanager after the update from karmic to lucid? it keep sayng that it is not running and that the networking is disabled...
<Chipzz> Notch-1: lucid support is in #ubuntu
<hrw> one thing which I need to remember when I work on ubuntu packages - edit configure/makefile.in not configure.ac/makefile.am like it was with OpenEmbedded
<cjwatson> er!
<cjwatson> goodness me no
<cjwatson> you should edit the original files and re-autogenerate
<cjwatson> it's a real pain when it turns out that somebody has edited only the autogenerated files
<cjwatson> you do need to be careful about timestamps to avoid autoconf getting rerun during the build and banjaxing everything (or else build-depend on autoconf etc.)
<cjwatson> and yes it can be a bit fiddly, but editing only the autogenerated files is definitely the wrong solution to the problem
<hrw> cjwatson: in patches I include changes to both of them
<cjwatson> yes, that's reasonable
<hrw> cjwatson: debian/ubuntu do not run whole autotools-please-regenerate-all-files by default
<cjwatson> that depends on the package.  the core build system doesn't do it, no.
<cjwatson> but debian/rules can do whatever it likes
<hrw> cjwatson: I know that debian/rules can do anything. using debian since previous century
<cjwatson> didn't mean to offend
<hrw> I know, sorry for that
<hrw> ~curse debian/patches/hrw-make-debug-dir-before-copying.diff
<hrw> btw - packaging imports into launchpad are automated?
<cjwatson> yes
<cjwatson> https://wiki.ubuntu.com/DistributedDevelopment
<hrw> thx
<hrw> gcc-4.5 4.5.0-5ubuntu1 cross built
<hrw> doko__: http://paste.ubuntu.com/444614/ was needed on my system to get gcc 4.5 cross built. multiarch binutils did not helped
<hrw> ~curse LP webfront devs for lack of id in divs
<ccheney> how long does it usually take for a new debian package to be synced to ubuntu (automatically)?
<cjwatson> variable.  what package(s) are you interested in?
<ccheney> bugs 588812, 588813 - mdds and mythes
<ubottu> Launchpad bug 588812 in Ubuntu "Sync mdds 0.3.0-2 (universe) from Debian sid (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/588812
<ubottu> Launchpad bug 588813 in Ubuntu "Sync mythes 2:1.2.0-4 (universe) from Debian sid (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/588813
<cjwatson> E: libmythes-dev is in main but its source (mythes) is not.
<cjwatson> currently in openoffice.org; is it OK to overwrite that package with the one from mythes?
<cjwatson> (that's why that one hadn't been done already)
<cjwatson> and is that just a straightforward split-out of the code already in the openoffice.org source package?
<cjwatson> same question for mdds, is it just a straight split-out of code already in ooo or is it new?
<ccheney> cjwatson, yea mythes should be replacing the version in OOo
<ccheney> cjwatson, i think mdds is new, but is used by new OOo as well
<cjwatson> ccheney: mdds will need an MIR then; we can waive that for mythes since it's just a split-out
<ccheney> ok
<ccheney> yea i have 3 MIR to do for the new version of OOo, was waiting to write them up until I uploaded OOo and had those packages synced from Debian
<cjwatson> both done now
<cjwatson> modulo waiting for binaries
<ccheney> thanks :)
<blue_anna> is there a port of xf-video-nouveau somewhere on the powerpc?
<zver> hey
<zver> hey world!
 * jdstrand grumbles about launchpadlib and bug #344878
<ubottu> Launchpad bug 344878 in ecryptfs-utils (Ubuntu) "file name to long when creating new file (ecryptfs_lookup: lookup_one_len() returned [-36] on lower_dentry)" [High,Triaged] https://launchpad.net/bugs/344878
<micahg> doko__: ping
<nigelb> ahem, after quite a bit of groundwork, operation cleansweep is finally kicked off http://justanothertriager.wordpress.com/2010/06/04/operation-cleansweep-launched/ :)
<JFo> yay!
 * JFo celebrates Operation Cleansweep!
<slangasek> \sh: "the examples in ifupdown" - do you mean the examples in ifenslave-2.6?  I don't see any examples in ifupdown that talk about bonding
<ogra> jdstrand, could you move the jasper-initramfs package through NEW ?
<slangasek> \sh: I think an SRU for ifenslave-2.6 to fix the examples in karmic is probably overkill; lucid is far and away the better release if you want a stable boot
<jdstrand> ogra: ok
<ogra> thanks :)
<cjwatson> slangasek: if you get a chance, could you have a look at my cdrom-detect uploads to karmic-proposed and lucid-proposed?  they're customer support escalations
<james_w> ari-tczew: where is the fakesync policy documented?
<ari-tczew> james_w: not yet done
<james_w> ari-tczew: has the work been done to make it work?
<ari-tczew> james_w: the general fakesync procedures were decided on #ubuntu-motu in February. I see that nobody want to do fakesync policy on wiki. I'll do it.
<james_w> ari-tczew: yes, but were the necessary code changes done so that it doesn't break things?
<ari-tczew> james_w: I don't understand your question, sorry
<ari-tczew> package is the same like in Debian, just changed debian/changelog and debian/control by update-maintainer
<ari-tczew> if tarballs were the same, I'll process the sync
<james_w> ari-tczew: there was a discussion on the mailing list about this policy, and several code changes were identified that would mean that it would work the way it is supposed to. If those have not been done then using the policy will cause problems for others.
<ari-tczew> james_w: I don't know about problems with fakesync.
<james_w> ari-tczew: did you read the mailing list discussion?
<ari-tczew> james_w: no
<ari-tczew> didn't
<james_w> http://thread.gmane.org/gmane.linux.ubuntu.devel/30305
<ari-tczew> oh, I'll read it, but later
<ari-tczew> thanks for link james_w
<james_w> see in particular Colin's response
<james_w> hi aganice
<aganice> hey, james_w
<james_w> how's it going?
<aganice> just ok. these first couple of weeks have been slow going (flu, unanticipated difficulty with fixing the problem in sample apps, and difficulty getting the hang of working from home) but i think i'm on the right track now
<slangasek> cjwatson: looking
<njin_> Hy everybody
<njin_> Can someone link me something explaining what are 'reverse dependencies'? thanks
<slangasek> cjwatson: not sure how cdrom-detect SRU is going to be verified in karmic when we have no more ISOs building there?  But, accepted
<uzver> what's hot?
<cjwatson> slangasek: good question, if need be I don't mind doing a one-off daily
<lifeless> slangasek: I kicked the importer for you after gathering data
<lifeless> slangasek: please continue pinging like that
<slangasek> cjwatson: ok
<slangasek> lifeless: alrighty - are you taking point on this alone, or are there others I should ping in other timezones as appropriate?
<slangasek> (I myself was proxying for jcrigby at the time)
<lifeless> so, there is now an rt asking for losa access to do it
<slangasek> cjwatson: can you refresh my memory on what you did to plymouth bzr to make the .pc directory be all happy?
<slangasek> cjwatson: I have another package in a similar situation
<cjwatson> goodness, not sure I remember
<lifeless> I'd suggest pinging losa first, and if they can't, then any of james_w, me, poolie, spiv, jam should be able to help, in principle.
<cjwatson> I think I blogged a while back something that included that information though
<lifeless> whats wrong with the .pc dir ?
<cjwatson> or rather, how I did it in a package I was running myself
<cjwatson> I generally put .pc in .bzrignore
<slangasek> lifeless: ack, thanks
<cjwatson> openssh is a fairly complex example of how I currently prefer to manage 3.0 (quilt) plus bzr
<slangasek> lifeless: well, I have an actively maintained bzr packaging branch; the .pc directory from 3.0 (quilt) doesn't end up in bzr by any usual means, but the importer will want to add it
<cjwatson> .bzrignore helps there, doesn't it?
<lifeless> not for the package importer
<lifeless> it takes the debian content and versions it directly
<cjwatson> plymouth isn't a good template if you're actually using separate patches
<slangasek> I'm not meaning to use separate patches
<slangasek> currently my only patch is a cherry-pick from upstream
<cjwatson> one thing I did for plymouth was to set single-debian-patch, so that we didn't get chaotic auto-created patch names
<cjwatson> slangasek: it looks like the above is about all I did
<slangasek> cjwatson: oh - so does the .pc stuff actually come from the importer after all, maybe?
<cjwatson> well, dpkg-source -x creates it
<cjwatson> I think we need to sort that stuff out at a level above individual packages
<cjwatson> I'm not sure the importer can do it on its own though
<lifeless> please make sure there is a bug on udd about this
<cjwatson> I filed a dpkg-dev bug a while back which is related
<slangasek> right, but my workflow doesn't ever have dpkg-source -x happening in the working dir
<cjwatson> Debian #572204
<ubottu> Debian bug 572204 in dpkg-dev "dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS" [Wishlist,Open] http://bugs.debian.org/572204
<cjwatson> if you turn the rune there into a script, you can get from bzr .pc-less checkout to usable quilt
<cjwatson> I'm not absolutely certain that's the right approach but I think it may be part of it
<cjwatson> perhaps something a bzr plugin should do on checkout of 3.0 (quilt) packaging branches, or something
<slangasek> well, if I have an existing branch and I'm doing a merge that will *add* the patch, that won't trigger locally?
<cjwatson> it's only a problem if you want to then use quilt directly
<cjwatson> but yes, there is awkwardness there
<cjwatson> I'm putting up with it because it's better than the old awkwardness :)
<cjwatson> looms will probably be better once fully assembled
<lifeless> FWIW I'm poking at looms next week
<lifeless> if you have specific thoughts about how these should interact, please toss them my way (email, or bug, or udd list)
<slangasek> I have no specific thoughts
<slangasek> :)
<Cynthia> while this may be off-topic, I wonder what you "officially" call the screen that comes up at boot on the Lucid LiveCD... I call it the "keyboard equals human" screen
<cjwatson> Cynthia: the CD boot loader splash screen
<Cynthia> cjwatson: mk :)
<dupondje> guys, is it a feature that boot stops when it can't mount a fs from fstab ? :)
<slangasek> dupondje: it's a deliberate design decision because the alternatives were worse
#ubuntu-devel 2010-06-05
<Notch-1> please guys, what happened to networkmanager in lucid? i need to update...
<Notch-1> but if i do the networkmanger explodes, i don't know what to do
<Cynthia> Notch-1: #ubuntu would be better suited for your question
<Cynthia> or perhaps #ubuntu-bugs, if you want to see how many people are also affected
<Notch-1> i think it's a major issue, i've tried in several channels, even locals, everyone gives up after a while
<Notch-1> but i saw other people with the same issue on the net, the suggestion was always a fresh install
<Notch-1> but i can't do it, please
<Notch-1> you are devel
<Notch-1> it' simple, the networking it's boroken after the reboot, i've tried everything...
<Notch-1> more timese and on different pcs, cloning my karmic system
<Notch-1> times
<Cynthia> The developers seem to be very busy right now. I'm not one per se.
<Notch-1> it always give me this strange message while updating, about some resources that networkmanager suddently cannot find, and that it is a no go, but the update continues and after the reboot i can only connect by typing "dhclient eth0"
<Notch-1> Cynthia: maybe someone...
<Cynthia> But it sounds like you should look for bugs on Launchpad, ask in #ubuntu every so often (timezones do affect things; the Euros at Canonical are asleep right now)
<Notch-1> kind hearted... :P
<Notch-1> i've tried, just some unanswered message on some forums, no bug filed anyway
<Notch-1> the top was a guy that explained that the update is not really meant to use, it's discouraged, you should always do a fresh install...
<Cynthia> That guy is clearly out of it
<Cynthia> Upgrades are fully supported by Canonical
<Notch-1> i know, it's insane
<Cynthia> If you have a bug on upgrades, bring it up by filing a bug report of your own
<Notch-1> but right now it seems just like that
<Cynthia> 'ubuntu-bug network-manager', fill out the form that appears
<Notch-1> you know how much open bug but do i have ?
<Cynthia> No
<Notch-1> very much, all unsolved
<Notch-1> sometimes chatting works...
<Notch-1> that's all i know
<Notch-1> so Cynthia please, you seem to know them, let me talk to someone for 5 minutes :P
<Cynthia> you're sorely mistaken, today is my first day in this channel
<Notch-1> i don't want to bother you, i just need somebody who knows what i'm talking about...unless i'm gonna be stucked in karmic
<Notch-1> ah fine, the 2 of us :D
<Cynthia> right now I'm looking at all the SVG files in the Ubuntu LiveCD to see which ones were bugged out by my use of Scour <http://www.codedread.com/scour/> on it
<Cynthia> because I see that the trash bin icon has some very large artifacts
<Notch-1> i don't know, i've always had lucid for max 1 hour, than retried the upgrade from karmic :D
<Notch-1> another gave up on #ubuntu... some days i'm gonna find the right guy for fixing this... for now i'm gonna go to sleep, c u tomorrow...
<LaserJock> anybody have problems with Swell Foop?
<LaserJock> hmm, bad channel for that question I suppose
<uzer> hello world!
<uzer> anybody in here?
<uzer> join #ubuntu
<Cynthia> I hate how Firefox and Eye-of-GNOME render the same SVG file differently. Makes it that much harder to debug SVG problems.
<Cynthia> cjwatson: Starting from what time (time + timezone) will tomorrow's daily build be available?
<Cynthia> If you're asleep ping me tomorrow about it. I'll test the two builds' startup times and report back in the evening (GMT-4)
<LaserJock> Cynthia: he's London time I think so probably asleep
<Cynthia> figures, thanks LaserJock :)
<ccheney> i'm trying to merge coreutils but it seems mom is on something
<ccheney> it pulled an ancient version of coreutils from debian (that i am surprised is still around) instead of the current one
<ccheney> its not even pulling the one from testing
<ccheney> it pulled 7.5-6 for some reason from sept 11, 2009 instead of 8.5-1 from apr 28, 2010
<ccheney> i think i will leave coreutils alone, maybe someone can determine whats wrong with mom (or if i am just too tired, heh)
 * ccheney heads to bed, bbl
<LucidFox> Hmm, question
<LucidFox> xvidcore in Ubuntu is synced from Debian git, but it's released on debian-unofficial.org rather than in Debian itself because of licensing issues.
<LucidFox> -0ubuntu1 and -0ubuntu2 are based on -0debimedia1, but now they have released -1 on debian-unoffiicial.
<LucidFox> So should the next Ubuntu version be -0ubuntu3 or -1ubuntu1?
<LucidFox> http://git.debian.org/?p=pkg-multimedia/xvidcore.git;a=summary
<cjwatson> LucidFox: since it won't be merged from unstable, it doesn't matter, so whatever makes it easier for whoever's maintaining it in Ubuntu to track it effectively
 * LucidFox nods
<m_anish> Hi, I'm trying to learn the ropes of ubuntu-packaging ... and have succeeded in creating a deb ... only it doesn't contain any useful files. I'm trying to make a deb out of "http://code.google.com/p/cannon-camp/" following the steps in "https://wiki.ubuntu.com/PackagingGuide/Complete".
<m_anish> Apparently I have been able to compile the source, (debbuild executed the Makefile) but the resulting deb doesn't contain the binary...
<m_anish> What am I missing/doing wrong...
<m_anish> http://dpaste.org/TLb0/ doesn't contain the binary 'cannon_camp_amd64'
<m_anish> this is the debuild log http://dpaste.org/JG0S/
<m_anish> contains ... "rm -f bin/cannon_camp_amd64 " why does the binary get removed
<m_anish> oops, wrong channel!
<jjardon> Hey, somebody knows the nautilus-elementary devels?
<hyperair> nautilus-elementary?
<hyperair> what's that?
<jjardon> hyperair, https://launchpad.net/nautilus-elementary
<jjardon> They implemented a editable toolbar recently
<jjardon> I think that would be good to work upstream to indluce that work in GTK+ directly
<jjardon> There is some work to add a toolbar editor to GTK+: https://bugzilla.gnome.org/show_bug.cgi?id=120645
<ubottu> Gnome bug 120645 in GtkToolbar "add a toolbar/menu editor" [Enhancement,New]
<hyperair> ah i see. editable toolbars. that's cool stuff.
<hyperair> jjardon: check the commit logs?
<jjardon> hyperair, yeah, but email != irc nick ;)
<arand> jjardon: TH LP profile usually will have the irc nick..
<jjardon> arand, yeah but the maintainer doesnt have any nick in his page: https://launchpad.net/~am-monkeyd :/
<hyperair> jjardon: launchpad account usually shows the irc nick, does it not?
<hyperair> jjardon: there's a kitkat on freenode, who happens to be from france as well =p
<jjardon> I'll try to email him. Thanks for the help ;)
<flupke> hello, where can I ask about packaging details ? (I'd like to know why QtMultimedia module is missing from python-qt4)
<ScottK> flupke: For that one #kubuntu-devel is probably the best place.
<flupke> thanks ScottK
<inal1993> hi developerz
<inal1993> I ve a question about WUBI-development
<inal1993> anyone th3re?
<inal1993> hey you faking ubuntu-developers
<inal1993> fak the system
<ScottK> !weekend | inal1993
<ubottu> inal1993: It's a weekend. Often on weekends the paid developers and a lot of the community may not be around to answer your question. Please be patient, wait longer than you normally would or try again during the working week.
<inal1993> oh snap
<inal1993> !weekday | buxy
<ccheney> anyone familiar with how MoM works?
<ScottK> ccheney: The code is in the merge-o-matic project on LP and it's not too horrible to look at.
<ScottK> Also, if you push changes in bzr, it gets automatically deployed, AIUI.
<ccheney> ScottK, for some reason it appears to be broken at least for coreutils, it claims an old version from sept is the most recent one to merge into ubuntu
<ccheney> or i've somehow lost my mind, heh
<cjwatson> ccheney: on my list to look at on Monday
<ccheney> cjwatson, ok, thanks :)
<ccheney> i wasn't sure if it was stuck by a bug or flagged somehow, none of the other packages i checked against the list seemed out of date though
<cjwatson> I don't know, but I have shell access to check
<ccheney> ok
 * ccheney bbl, have to run errands
<inal1993> I ve a question about WUBI-development. anyone interested?
<inal1993> I ve a question about WUBI-development. anyone interested?
<ScottK> inal1993: Come back on Monday.
<ScottK> Your odds of getting a positive answer are much better than.
<inal1993> oh why
<ScottK> Because the people that work on wubi do it as part of their work and aren't generally around on the weekend.
<ScottK> Also, repeating the same question over and over every few minutes is quite rude.
<inal1993> oh does ubuntu have official paid-developers?
<ScottK> Yes.
<LaserJock> yet somehow ScottK is always around ... :-)
<loneowais> hey everyone, I wanted to check the irc logs for ubuntu developer week. Can anyone tell me when it took place?
<loneowais> the date?
<arand> loneowais: The logs should be nicely formatted here: https://wiki.ubuntu.com/UbuntuDeveloperWeek/
<arand> loneowais: If you're after openweek: https://wiki.ubuntu.com/MeetingLogs/openweekLucid
<loneowais> arand: i got it already. Thanks anyway.
<loneowais> arand: hey.. was the writing beautiful code session ever taken?
<arand> loneowais: I don't know to be honest.
<loneowais> hmm
<loneowais> also.. a few days back somewhere I saw a session titled Ubuntu Packaging Training
<loneowais> When did/will it take place?
<loneowais> any idea
<arand> loneowais: there's some info at http://ubuntupackaging.wordpress.com/ but again, I don't really know (which does seem to be a general theme about these sessions -- few knows, unfortunately), most of the people involved should be either here or in -motu I reckon, dholbach should know, but he's not around atm..
<dob1> hi, i have an acer 5100 and with the new relase of ubuntu this problem https://bugs.launchpad.net/ubuntu/+source/linux/+bug/44627  again, with karmic the problem wasn't present, with juanty the problem was present, i know is very difficult to find the cause but there is something in common between the 9.10 and juanty that can generate this problem?
<ubottu> Ubuntu bug 44627 in xserver-xorg-video-sis (Ubuntu) "3d support for Sis 760 DRI OpenGL" [Wishlist,Confirmed]
<yoritomo> hello everyone
<aretrfre34> I wanna fake mic input by dumping in /dev/dsp my wav mp3s, how do fake mic, is it possible?
<aretrfre34> espeak 'test' --stdout > /dev/dsp gives a horrible noise, help
<aretrfre34> heloooooooooooooooooooooooooooooo
<aretrfre34> bump
<aretrfre34> bump
<aretrfre34> bump
<aretrfre34> bump
<aretrfre34> bump
<aretrfre34> bump
<aretrfre34> heloooooooooooooooooooooooooooooo
<aretrfre34> helooooooooooooooooooooooooooooo
<aretrfre34> heloooooooooooooooooooooooooooo
<aretrfre34> helooooooooooooooooooooooooooo
<aretrfre34> heloooooooooooooooooooooooooo
<aretrfre34> helooooooooooooooooooooooooo
<aretrfre34> heloooooooooooooooooooooooo
<virtuald> :D
<aretrfre34> helooooooooooooooooooooooo
<Tm_T> !ops
<wise_crypt> !weekend
<ubottu> It's a weekend. Often on weekends the paid developers and a lot of the community may not be around to answer your question. Please be patient, wait longer than you normally would or try again during the working week.
<aretrfre34> helooooooooooooooooooooooo
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<aretrfre34> heloooooooooooooooooooooo
<virtuald> aretrfre34: you're making a horrible noise
<cjwatson> aretrfre34: please cease this
<aretrfre34> developers having hangover or what?
<cjwatson> support -> #ubuntu
<aretrfre34> why this channel?
<cjwatson> this channel is for development of Ubuntu itself
<cjwatson> it is not for support, and it is not for application development on top of Ubuntu (as it says in the topic)
<yoritomo> i am actually working on a new algorithm which consist in a kind of vectorial graphics but i would like to apply it to any files, for exemple   110111001100111001100111111 the  algorithme check in a database and identify 1100110011001100110011 .... then it extract the identified bits  and keep the unused ones in place in the code
<cjwatson> it particularly isn't for flooding with "hello" type things when you don't get an answer in under a minute
<yoritomo> it would specify the lenght of the cycle and so on , but my problem is the way to build a suitable scanning loop to work correctly on this identifications :)
<aretrfre34> what is ubuntu then? applications on top of kernel?
<cjwatson> at a very simplistic level, I suppose you could describe it like that.  https://wiki.ubuntu.com/UbuntuArchitecture goes some way to describing it
<cjwatson> (but incomplete)
<dob1> well there is no one that can help me with the problem on the acer 5100?
<cjwatson> dob1: evidently not, perhaps #ubuntu-kernel would know better and perhaps you'd have a better chance on a weekday
<dob1> i try on that channel thanks
<yoritomo> i think the engine should seek for the most complicate combinations to finish by the most simple,  that may be slow with about 200 differents cycles
<yoritomo> anyone is accurate about compression or encryption algorithms here ?
<mneptok> aretrfre34: you asked your question on #ubuntu. -devel is not a support channel.
<mneptok> aretrfre34: and your channel spamming here is ost unwelcome and quite disruptive.
<mneptok> *most
<cjwatson> yoritomo: it doesn't look like it.  your question doesn't seem particularly related to the development of Ubuntu (note the bit in the topic saying that this channel isn't for application development, but rather for development of the OS itself); perhaps a channel devoted to compression or encryption might be of more use?  (I don't have a specific suggestion, though)
<aretrfre34> how to espeak raw file?
<cjwatson> aretrfre34: please take it to #ubuntu; this is not a support channel
<cjwatson> (last warning)
<mneptok> aretrfre34: this is *not* a support channel
<yoritomo> anyone know a linux compression related chan ?
 * LucidFox pokes gilir
<gilir> LucidFox, yes ?
<LucidFox> mkvtoolnix 4.0.0 has been released, planning to update? :)
<gilir> LucidFox, not right now, but feel free to do it if you want :)
<LucidFox> is orig.tar.bz2 only available with the 3.0 format?
<LucidFox> ah apparently yes
<h0ar3> any wubi developers here?
#ubuntu-devel 2010-06-06
<slangasek> lifeless: if I happen to have fixed the underlying cause of a UDD import failure, will a retrigger be attempted automatically or do I need to ask someone to poke it? (laptop-mode-tools)
<CynthiaG> cjwatson: Just to let you know that, as promised, I downloaded today's daily CD build, and will test timings tomorrow. There was a delay of 13 hours due to a power failure at my ISP.
<lifeless> slangasek: depends on the underlying failure, I think
<lifeless> slangasek: all branches are reattempted, AIUI
<lifeless> slangasek: but if the fix was 'land fix XYZ in bzr-builddeb', we'd need to deploy that first
<slangasek> lifeless: it was a missing tag; I don't know what the underlying cause was, but I added the tag while trying to get bzr merge-package to work (didn't know it had also caused an import failure)
<lifeless> that should not have caused an import failure
<lifeless> rather the importer should have stomped on the current history and proposed the old history as a merge
<slangasek> well, there are a number of other packages with that failure listed at http://package-import.ubuntu.com/status/
<slangasek> (27 of them)
<slangasek> 27 packages failed with key bzrlib.errors.NoSuchTag:<module>:main:handle_collisions:clean_collision:import_package:_do_import_package:upstream_parents:revid_of_upstream_version:lookup_tag
<lifeless> so, please make sure thats an open bug in UDD
<lifeless>  / bzr-builddeb
<kobrien> hi, any core devs around?
<kobrien> anyone explain how I get a blueprint approved for maverick?
<ari-tczew> kobrien: https://blueprints.launchpad.net/ubuntu/maverick and click on column called "Design"
<kobrien> ari-tczew: thanks
<ari-tczew> you're welcome
<kobrien> I've registered one. just wondering the next steps is all :)
<kklimonda> kobrien: it can be accepted by a member of the ubuntu drivers team
<soren> kobrien: Which team does it fall under?
<kobrien> team. I dunno...it's a java app
<kobrien> "devel" i think is most appropriate
<kklimonda> kobrien: you can get a list of teams from https://wiki.ubuntu.com/
<kobrien> cool
<kobrien> kklimonda: oh, well maverick then
<kklimonda> kobrien: no, when you scroll down you will find a paragraph called "Getting Involved" which has a subparagraph called "Teams"
<Chipzz> "It's a java app" doesn't tell what your blueprint intends to do though
<kklimonda> like Accessibility or Community or Desktop... and it's obviously not complete as there is no Desktop ;)
<Chipzz> kobrien: if you just want to get an app included, blueprints are not appropriate
<Chipzz> in that case you should file a bug report against ubuntu I think, and talk with the ppl in #ubuntu-motu
<kobrien> Chipzz: my blueprint is that I'm porting something
<kobrien> it's a development environment
<ari-tczew> wgrant: could you check status for bug 74458 why it's Fix Committed since 3,5 years?
<ubottu> Launchpad bug 74458 in lighttpd (Ubuntu Dapper) "logrotate with lighttpd graceful shutdown and restart failed." [Undecided,Fix committed] https://launchpad.net/bugs/74458
<gam3> http://pastebin.org/312775
<gam3> can anyone help me with that
<kklimonda> ari-tczew: hmm.. it got superseeded by the security upload and no one has uploaded it again? that's what I get from comments. 74458 not being closed nowhere in 1.4.11-3ubuntu3.8 changelog fits
<ari-tczew> kklimonda: that I ping wgrant for this, for check this bug
<ansgar> gam3: Please try aksing in #ubuntu.
<gam3> i did
<gam3> and linux
<gam3> and java
<aakef> Hello all
<aakef> Any one here who could help me with launchpad ppa uploads?
<aakef> I registered a ppa page, upload to it with dput, but nothing happens
<aakef> Or what would be the appropriate mailing list to ask on?
<Chipzz> gam3: this channel is not some kind of overflow channel when you don't get an answer elsewhere. your question is not appropriate here
<ScottK> aakef: Try #launchpad.  It's off topic here.
<aakef> ScottK: Thanks! Will ask there.
<un214> what's it gonna take to get https://bugs.launchpad.net/ubuntu/+source/module-init-tools/+bug/584814
<ubottu> Ubuntu bug 584814 in module-init-tools (Ubuntu) "blacklist tileblit gets ignored" [Undecided,New]
<un214> what's it gonna take to really kill fbcon? In the days where I used slackware I'd compile it out but that doesn't work to well with dpkg.
<debfx> micahg: kmozillahelper has been renamed, you can change the firefox Suggests now
<debfx> bug #559154
<ubottu> Launchpad bug 559154 in kubuntu-firefox-installer (Ubuntu) "KDE users installing Firefox from archive don't know about kmozillahelper" [Low,Triaged] https://launchpad.net/bugs/559154
<h0ar3> hi guys
<h0ar3> anyone knows about grub4dos
<micahg> debfx: k
<cjwatson> h0ar3: die grub4dos die.  grub2 supersedes the need for it
<CynthiaG> cjwatson: What timings are you interested in for your mkisofs reordering? (the one where you put the squashfs file at the end) Is it worth testing on all the computers I have access to?
<cjwatson> whatever you think is reasonable to get an assessment of whether it actually improved matters and by how much
#ubuntu-devel 2011-05-30
<ScottK> kees: apachelogger is complaining he's not in ubuntu-sponsors, but too lasy to switch channels at 3:50 AM in .at.  Since you're a team admin, would you please add him.
<TheMuso> Whaaa? Linux 3.0-rc1?
<ScottK> TheMuso: Would you please add apachelogger to ubuntu-sponsors.
<TheMuso> ScottK: Sure.
<ScottK> Thanks.
<TheMuso> Done.
<ScottK> Thanks.
<ScottK> kees: Unping.
<TheMuso> np
<RAOF> TheMuso: Yeah.  The release numbers are âgetting too highâ, so it's time for 3.0 :)
<TheMuso> Fair enough.
<TheMuso> I just wonder whether 3.0 is bringing anything *significant*.
<micahg> TheMuso: no, http://www.phoronix.com/scan.php?page=news_item&px=OTUwMg
<ajmitch> looks like it's nothing nig, just a nice shiny version number
<ajmitch> s/nig/big/
<TheMuso> Right.
<TerminX_> it would be nice to see crap like support for MFM and RLL hard drives go away in 3.0
<TheMuso> Thats a good read.
<TheMuso> c
<pitti> Good morning
<pitti> slangasek: fixed now (seems Debian dropped the python:Provides)
<pitti> kees, jdstrand: releasing lucid kernel to -updates/-security: linux linux-backports-modules-2.6.32 linux-meta linux-ports-meta
<pitti> argh
<micahg> pitti: you do realize they're off today, right?
<pitti> they usually read backscroll, though
<micahg> pitti: no, I mean Monday :)
<pitti> right
<micahg> k
<micahg> wasn't sure if a USN had to go out at the same time
<pitti> (I didn't know that they are off, but now I do)
<micahg> US holiday today
<pitti> ah, I see
<pitti> it's nice if the USN gets out timely, but *shrug*, too late now :/
<micahg> mdeslaur: ^^
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<pitti> james_w: hm, the package importer spits out branch diffs for feisty, edgy, gutsy, etc. like mad :/
 * pitti plays whack-a-mole to set them to rejected
<pitti> like https://code.launchpad.net/~ubuntu-branches/ubuntu/gutsy/cyrus-sasl2/gutsy-201105300151/+merge/62828
<pitti> (empty diff)
<didrocks> good morning
<dholbach> good morning
<pitti> james_w: seems I can barely keep up with the closing :/
<geser> good morning
<micahg> pitti: re bug 766559, shouldn't it just be changed from an depends to enhances?
<ubottu> Launchpad bug 766559 in icedtea-web (Ubuntu) "Forcing installation of firefox" [Undecided,Triaged] https://launchpad.net/bugs/766559
<pitti> I'm not sure whether software-center looks at "enhances", but I'm not fussed about suggests vs. enhances
 * micahg thought enhances makes it show up as a "plugin"
<soren> micahg: That's the intent, but I think support for it in the various package managers is somewhat lacking.
<micahg> ah, I'll chat with someone tomorrow about that :)
<RAOF> I think software-centre actually looks at that, but I'm not sure.
<dholbach> broder, thanks for the backport
<broder> dholbach: np
<Sweetshark> Hi guys!
<Sweetshark> pitti: do you agree that https://bugs.launchpad.net/df-libreoffice/+bug/709778 would deserve a SRU? OTOH I guess we will be releasing LO 3.3.3 in some form to natty, right? I that case we can keep it in the ppa until then.
<ubottu> Ubuntu bug 709778 in LibreOffice Productivity Suite "Libreoffice base form design doesn't show toolbars, can't show them" [Critical,Confirmed]
<Sweetshark> (that bug makes base completely unusable)
<pitti> hey Sweetshark
<pitti> Sweetshark: yes, that's SRU worthy indeed
 * Sweetshark is a bit scared that not only Ubuntu, but at least also Debian and OpenSUSE did ship this and nobody seemed to have cared about it.
<Sweetshark> pitti: http://wiki.documentfoundation.org/ReleasePlan/3.3#3.3.3_release upstream release 3.3.3 is around the corner too though. Shall we wait for it?
<Sweetshark> I dont know it debian even packages a 3.3.3
<Sweetshark> s/it/if/
<pitti> Sweetshark: I'd say it depends on how realistic it is to get 3.3.3 into -updates fast; I remember previous microrelease updates which caused regressions and which never made it past -proposed
<Sweetshark> pitti: does all the microrelease code change have to be reviewed?
<pitti> not every line, but we do review the changelog for sanity at least
<Sweetshark> pitti: alas
<Sweetshark> pitti: a) there is no changelog b) there are 20 repo logs to look into c) it could well be that all changes are by me.
<infinity> Sweetshark: If (c) is true, that makes is easy to audit, via draconian interrogation techniques.
<geser> or write a changelog
<Sweetshark> infinity: I am happy to report that that is not the case.
<Sweetshark> there are 35 commits in total over all repos
<Sweetshark> pitti: given that, SRU is the way to go IMHO. And 3.3.3 release to ppa.
<pitti> Sweetshark: ah, that sounds fine; I was afraid it was more like 3000 :)
<Sweetshark> pitti: no, after 3.3.2 there are not many patches anymore, as people are more interested in breaking the next release
<debfx> cjwatson: could you please update the kubuntu packageset so it picks up kamoso? it's seeded on the dvd
<jibel> mvo, Hi
<jibel> mvo, there's definitely a problem with apt and MergeList in Natty, there are 2 new reports today
<jibel> mvo, and bug 346386 is accumulating duplicates.
<ubottu> Launchpad bug 346386 in apt (Ubuntu) "[MASTER] Update fails with invalid package files with "Encountered a section with no Package: header"" [High,Triaged] https://launchpad.net/bugs/346386
<jibel> see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627642
<ubottu> Debian bug 627642 in apt "apt installed bad Packages files and is unable to replace them on update" [Normal,Open]
<juliank> jibel: Invalid package files do simply not work, and we can't really check them after download, as that violates abstraction layering and is just to slow.
<juliank> Most of those bugs are wrongly configured networks sending 200 OK messages with wrong content
<jibel> juliank, I don't think leaving the user with an unresolvable situation does work either.
<pitti> how come that apt accepts them anyway? They should certainly not match the md5sum from the releasea file?
<jibel> juliank, and this situation regressed in natty.
<juliank> pitti: that's a good question.
<juliank> jibel: It does not regress, the number of public hotspots using such schemes increases
<juliank> pitti: If it does not verify those files, we actually have a serious security bug
<Sweetshark> pitti: I had a look at the commit, they all look rather sane. so back to the plan to get 3.3.3 to -updates, right?
<pitti> juliank: *nod* -- but I suspect it also downloads a bad Release file then?
<pitti> Sweetshark: sounds good to me
<juliank> pitti: Release files are downloaded of course, but verified using gpg, so there is no problem from a security perspective. And they are always re-downloaded completely AFAIK, so the other problem is not that critical either
<mvo> thanks jibel
<mvo> jibel: i will work on reproducing this today
<juliank> mvo: The Release file must be missing for this to happen, as otherwise it should check the signatures
<mvo> juliank: yeah, I suspect that is the case, I need to look at the various reports to figure out what is happening exactly
<juliank> mvo: I'm writing a test server for it.
<mvo> juliank: and how to reproduce it, it may well be that its just more visible now
<mvo> juliank: I have a fault-injecting-proxy for this if you want to try it
<juliank> mvo: I just sent 200 OK messages from a nodejs server containing HTML, as in the Debian bug
<mvo> juliank: ok, that should be fine as well, lp:~mvo/+junk/fault-injecting-proxy  fyi
<mvo> but your approach should be fine too
<mvo> juliank: I need to go for lunch now, I will check afterwards
<jibel> juliank, for info, the actual content of the faulty files are, in most of the cases, a router/proxy error page when a remote file doesn't exist (the device probably returns a code 200 instead of a propagating the 404) or a hotspot landing page. You're approach to reproduce should be fine.
<jibel> juliank, thanks for helping on this.
<juliank> jibel: I reproduced it already.
<doko> stgraber: why is bug #781516 assigned to you?
<ubottu> Launchpad bug 781516 in rpcbind (Ubuntu Oneiric) "[MIR] libtirpc, rpcbind" [High,New] https://launchpad.net/bugs/781516
<juliank> jibel: mvo: Posted a patch at https://launchpadlibrarian.net/72655592/lp-346386.diff
<juliank> This makes it reject indexes (Packages,Sources,Translation) without a 'Package' field in the first section, and Release files without hashes
<juliank> That's not the final patch, though
<TheMuso> cjwatson: Do you have a bzr branch of your live-build migration work somewhere, or are you still analysing live build-livecd-rootfs?
<bdrung_> tumbleweed: around?
<juliank> jibel: mvo: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/346386/+attachment/2147672/+files/lp-346386v2.diff should now reject all invalid files (Packages, Sources, Translation, i18n/Index, InRelease, Release, Release.gpg)
<ubottu> Ubuntu bug 346386 in apt (Ubuntu) "[MASTER] Update fails with invalid package files with "Encountered a section with no Package: header"" [High,In progress]
<tumbleweed> bdrung_: yeah, back at my desk for the first time in a month :)
<juliank> I'll be back in about 10 to 20 minutes
<juliank> and finalize and commit this thing then
<bdrung_> tumbleweed: why do you use try assert instead of a simple if construct?
<tumbleweed> bdrung_: partly because it was there, partly so it'll still throw an exception when there's no error output
<mvo> thanks juliank!
<bdrung_> tumbleweed: but you just catch the AssertionError
<tumbleweed> no it's raised again if there's no error output
<juliank> mvo: It could actually break some repositories shipping an unsigned Release file not containing hashes. Is that actually supported?
<bdrung_> tumbleweed: please fix the build failure
<cjwatson> TheMuso: I have a private git branch, but I've pushed all the changes in it as Debian bug reports
<hrw> can someone from TB grant me PPU which I got week ago?
<tumbleweed> bdrung_: sorry, will do. I couldn't test because my local mirror is borked
<bdrung_> tumbleweed: a local build is sufficient
<tumbleweed> bdrung_: I didn't have a local environment with an up to date devscripts installed.
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cdbs> pitti: I'm a second late, but could you kindly sponsor a merge that's blocking gnome-shell from building? Thanks
<pitti> hrw: yes, can you please send me a pointer to the confirmation email?
<hrw> pitti: sure
<pitti> cdbs: sure, which one?
<cdbs> pitti: bug #789748
<ubottu> Launchpad bug 789748 in libxfixes (Ubuntu) "Please merge libxfixes 1:5.0-2 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/789748
<hrw> pitti: but should I get any for it? when I got 'ubuntu contributor' status I got email that I got added to LP group. After last week DMB meeting I did not get any emails regarding PPU stuff.
<pitti> hrw: there should be a voting about your application on the dmb list
<hrw> pitti: so far the only place where I see that I got them is log from last DMB meeting
<pitti> maybe they didn't prepare/send out the minutes yet
<hrw> pitti: http://irclogs.ubuntu.com/2011/05/23/%23ubuntu-meeting.html - end of log
<geser> hrw: usually the chair of the meeting sends a mail to the TB requesting it (as only TB can add PPU to LP)
<hrw> so will have to catch persia first probably
<pitti> hrw: ah, can do now if it's blocking you
<hrw> pitti: few things less on todo list - upload of whole cross toolchain for oneiric with gcc 4.6 as default instead of natty's versions
<pitti> hrw: done
<geser> hrw: alternatively you could ask pitti to sponsor your uploads :) (although a little bit late for his piloting today)
<mvo> juliank: I think its ok to break for that case, I doubt its supported anymore
<pitti> geser: nah -- sponsor a man, and he's got enough uploads for a day; edit_acl for a man, and he's got enough uploads for a lifetime!
<hrw> geser: I know. I went this way for >100 versions of cross toolchain packages
<juliank> mvo: I removed it for now, as I created such repositories from time to time IIRC
<pitti> hrw: happy uploading!
<hrw> pitti: danke
<juliank> mvo: revno 2126 and revno 2127 of debian-sid
<cdbs> hrw: Rock with Linaro! (/me's a linaro fan)
<tumbleweed> bdrung_: looks like a bug in pylint
<pitti> cdbs: done
<cdbs> pitti: Thanks a lot, that was fast!
<pitti> well, it builds fast, and my computer reboots fast, too :)
<pitti> (for testing)
<cdbs> pitti: Boots fast? My oneiric's boot time is now at par with windows :(
<pitti> well, for this computer it's still slow (some 20 s)
<cdbs> Due to the plethora of changes that trickled in
<pitti> I had 7 s in maverick
<cdbs> pitti: Its over a minute for me
<mvo> juliank: thanks, I will merge into the ubuntu branch and if its all looking well in oneiric backport as a SRU
<geser> mine oneiric boots slow too (slower than natty), sometimes it even doesn't find the md-device for my /home
 * cdbs faces the same issue as geser 
<geser> not to mention the issues with auto-login (the 1st login tells me on one screen that something has gone wrong and I've to log out while I seem to be able to use Gnome on the other one; but the 2nd (manual) login works)
<geser> and logouts are also taking long (don't know what happening in the background that a logout takes so long)
<azeem> anybody know what creates /etc/php5/apache2/php.ini and what's the default value for session.gc_probability in lucid?
<cdbs> azeem: libapache2-mod-php5 creates that
<cdbs> azeem: in oneiric, its 1, I dunno about lucid.
<azeem> thanks
<stgraber> doko: because slangasek wanted me to write the MIR. I should have removed that once it was written.
<dholbach> can somebody else please take a look at https://code.launchpad.net/~andrewsomething/ubuntu-packaging-guide/debian-dir-overview/+merge/62803 too?
 * dholbach just gave it a review
<ScottK> If only all this effort was going into improving existing documentation instead of making Ubuntu docs that duplicate existing Debian work, it would be more interesting to review.
<dholbach> ScottK, I think part of it was taken from the old packaging guide
<ScottK> I think it's a mistake to have a completely separate set of Ubuntu documentation for things that are largely common to Debian.
<ScottK> It's a real missed opportunity for collaboration.
<dholbach> right
<hrw> Successfully uploaded packages.
<hrw> now waiting for build results ;D
<dholbach> on the other hand is it a bit tough to draw the line - there are parts (infrastructure, processes, some packaging bits) that are different
<dholbach> ... if you want to give somebody who reads the guide a feeling for some kind of semi-complete document
<hrw> dholbach: make one doc for debian/ubuntu with some extra ubuntu sections?
<dholbach> it's not a completely separate set of Ubuntu documentation - as you can see in the article that Andrew wrote, there's quite a few links to debian documentation
<dholbach> nobody wants to replace that :)
<ScottK> cjwatson: kphotoalbum may be some kind of record.  12 minutes from sync request filed to fix released with no prodding anyone to get it done.
<hrw> [ubuntu/oneiric] armel-cross-toolchain-base 1.64 (Accepted)
<hrw> yay!
<cjwatson> ScottK: lucky :-)
<ScottK> hrw: First upload?
<pitti> hrw: congrats!
<ogra_> oh my ! hrw can upload to the archive now ?
 * ogra_ ducks and covers :)
<ogra_> hrw, congrats :)
<ScottK> hrw: Congratulations.
<hrw> thx guys
 * hrw -> lunch
<highvoltage> hrw: whohoo!
<hrw> ogra_: PPU for cross compilers for now
<hrw> ogra_: too many people told me 'motu is dead, apply for universe contributor' so motu has to wait a bit
<ScottK> Rumors of MOTU's death are greatly exaggerated.
<geser> The dead (MOTU) are still alive
<Satoris> Zombies of the Universe.
<qchn> Does anyone know where the difference in the initramfs between Debian and Ubuntu is?
<qchn> I need to hook something there in Ubuntu which works under Debian.
<Laney> I want to know who all of these 'too many people' are
<dpm> hi doko, I'm looking at the translations imports queue in LP, and there are a couple of .pot templates coming from gcc which I'm not sure what to do with. They are the same template but come from different paths. My guess is that I should approve one (the one from src/) and block the other one (the one from src-spu/), could you please confim? They're these:
<dpm> src/libcpp/po/cpplib.pot
<dpm> src-spu/libcpp/po/cpplib.pot
<doko> dpm: ignore the src-spu one (only built on powerpc)
<dpm> doko, ok, cool, thanks
<stgraber> cjwatson: Hi! I'm currently looking at dhcpv6 support in d-i. I did my initial test with the mini iso and noticed that it doesn't contain the isc-dhcp-client udeb but instead uses busybox's udhcpc.
<stgraber> cjwatson: as udhcpc doesn't support dhcpv6, I was wondering how difficult it'd be to use isc-dhcp-client in the mini.iso image instead?
<stgraber> (apparently we use the isc-dhcp-client udev for our other images, downloading one of them now to verify that it's indeed the case and that the -6 option works)
<didrocks> doko: I was promoting the at-spi2 to main, I was puzzled why it was already done
<didrocks> same for atk
<doko> well, that's why I added a comment. didn't know that you were archive admin
<didrocks> doko: ok, I was puzzled for a minute as I didn't get the bugmail meanwhile, you'll know for next time then :-)
<slangasek> pitti: thanks for the python-gnome fix :)
<fta> doko, http://paste.ubuntu.com/613946/ (from the chromium devs)
<doko> fta: thanks. could you attach it to the bug report?
<fta> sure
<fta> doko, against binutils?
<fta> doko, btw, i filed 2 already last week, and i Cced you
<doko> fta: works in oneiric. please could you check with the binutils from the ubuntu-toolchain-r ppa?
<fta> doko, they need it in the LTS...
<doko> not sure I want to do that ...
<fta> doko, too bad :( they are forced to recommend all devs to build their own binutils from trunk, for lucid :(
<doko> fta: 2.21 did need fixes in a lot of packages. can't just update from 2.20 to 2.21
<doko> will upload 2.21 to ubuntu-toolchain-r/test
<doko> which bug report did you update?
<fta> i didn't do it yet
<fta> doko, i'm wondering if it's worth it now that you said it won't happen
<fta> my problem is with the ubuntu chromium builds for which ld-fbd is now so slow builders timeout, and ld-gold is either not usable or unreliable.
<doko> this is bug #673893
<ubottu> Launchpad bug 673893 in binutils (Ubuntu) "10.04: binutils-gold is out of date" [Undecided,New] https://launchpad.net/bugs/673893
<doko> fta: write your own standard output while you see progress on the output file
<doko> fta: uploaded to ppa:ubuntu-toolchain-r/test (this one already has 2.21)
<roel-> I'm working with preseeding the ubuntu installation here, and it works fine so far
<roel-> but:
<roel-> I would like the installation to prompt for two things: the ip address and the hostname of the new ubuntu installation
<roel-> but the installer defaults to hostname 'ubuntu' without asking for it
<roel-> can I force it to ask for a hostname?
<roel-> where can I find the code for this so I can analyze it?
<fta> doko, thanks
<cjwatson> stgraber: there's already a netcfg branch for that, and I have a work item to integrate it; it uses wide-dhcpv6-client-udeb
<stgraber> cjwatson: any reason it uses wide-dhcpv6-client-udev instead of isc-dhcp-client-udev (that handles both v4 and v6 and is already on our CDs)?
<cjwatson> stgraber: I don't know off the top of my head, it would be worth going back to the debian-boot@ discussion if you're curious
<cjwatson> we might well be able to use isc-dhcp for it, sure
<cyphermox> hi, would someone be so kind as to ACK network-manager from NEW?
<vmlinuz> after I upgraded my Lucid to the latest kernel today, my compiz is freezing from time to time... is there any way to run compiz in debug mode and troubleshoot that? maybe file a bug
<micahg> doko: BTW, it seems the s/xulrunner/firefox/ change was dropped again for icedtea-web (currently in depwait)
<micahg> doko: re chromium and lucid, can we upload a new binutils with new source/binaries that could be used on demand?
<doko> micahg: sorry, will fix it later this week
<micahg> doko: k, thanks
<stgraber> cjwatson: Just finished doing some tests with isc-dhcp-client-udeb (as I had a WI for that in the ipv6 spec). Seems like we ship it by default but it's not installed by default. Installing it manually gives a working dhcp client for ipv4 and ipv6 (obviously netcfg only knows about the -4 mode)
<stgraber> (updated the spec with the test results)
<stgraber> I also tried to find that IPv6 branch of d-i but it looks like the instructions in the ML post aren't working anymore :(
<cjwatson> stgraber: right, changing netcfg to depend on isc-dhcp-client-udeb would be sufficient to cause it to be pulled into CD images, mini.iso images, etc.
<cjwatson> we actually only switched to udhcpc recently, AIUI ;-)
<hemin> Hi guys, I want to contribute in development ubuntu operating system.. where should I start from?
<iulian> hemin: http://www.maths.ox.ac.uk/files/study-guide/index.shtml
<iulian> Oups.
<iulian> I meant https://wiki.ubuntu.com/MOTU/Contributing.
<hemin> iulian, thanks!
<tumbleweed> hemin: and you are welcome to ask lots of questions :) #ubuntu-motu is a good place for that
<hemin> ok.. sure i will join #ubuntu-motu
<tumbleweed> hemin: there's also a new guide in progress: http://people.canonical.com/~dholbach/packaging-guide/html/
<hemin> ok
<micahg> hi ahasenack
<ahasenack> hi micahg
<ahasenack> so in natty we have smart-1.3-1.3build1, what version/release should I use for an SRU?
<micahg> so, for something like 1.3-1.3build1, the version would be 1.3-1.3ubuntu0.1 if it's the only release with that version, if it's a no change rebuild SRU, then 1.3-1.3build2
<ahasenack> micahg: it will have a code patch
<micahg> so, 1.3-1.3ubuntu0.1 for natty and 1.3-1.3ubuntu1 for oneiric
<ahasenack> micahg: no distro name in it?
<micahg> ahasenack: no, since they will have different versions, the only time to use a distro name in an SRU if for a full version backport
<ahasenack> micahg: the released natty and oneiric builds have the exact same version/release
<micahg> and even then, it's a matter of preference to use the codename or the number
<ahasenack> 1.3-1.3build1
<tumbleweed> ahasenack: but you fix it in the devel release before SRUing
<ahasenack> well, oneiric wasn't relesaed, ok
<micahg> ahasenack: right, but the oneiric one will follow the standard dev conventions which will make the suffix ubuntu1 and natty will follow SRU conventions with an ubuntu0.1 suffix
<ahasenack> tumbleweed: yeah, I have to upload it to oneiric too, ok
<ahasenack> ok, and maverick? It has "1.3-1"
<ahasenack> so, 1.3-1ubuntu0.1?
<micahg> ahasenack: correct!
<ahasenack> and lucid, which has 1.2-5, will get 1.2-5ubuntu0.1?
<micahg> ahasenack: yep
<ahasenack> ok, I better save these logs
<ahasenack> micahg: tumbleweed: thanks
<cr3> how can I prepare a package and all its dependencies on a usb key so that it can be installed offline, knowing the target release for example?
<soren> cr3: apt-offline
<cr3> soren: thanks dude, checking it out
<soren> cr3: Sure thing.
<hallyn> hm, quilt upgrade not working with trees created under previous quilt?
<hallyn> oh, no.  that's not it.  i guess my crash yesterday cost me some file integrity.
#ubuntu-devel 2011-05-31
<RAOF> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: RAOF
<TheMuso> Are there any QT/KDE folks around who could point me to the QT 4.7 git repo? Thanks.
<TheMuso> And not for Ubuntu, I've found the bzr branch for that.
<TheMuso> nvm found it.
<lucidfox> Any reason the gtkpod binaries have been staying in NEW for longer than usual?
<TheMuso> lucidfox: Probably because nobody has got to them yet?
<lucidfox> ahh
<RAOF> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<RAOF> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<RAOF> Time to have lunch and make dinner!
<LaserJock> does anybody know of a tool to create a manpage from python optparse code?
<sladen> LaserJock: http://andialbrecht.wordpress.com/2009/03/17/creating-a-man-page-with-distutils-and-optparse/  was the first hit
<LaserJock> thanks goog... I mean sladen
<pitti> Good morning
<LaserJock> pitti!!
<LaserJock> just the man I was looking for
<LaserJock> pitti: if I wanted to submit a patch to python-mkdebian in python-distutils-extras, what would be the best way of doing that?
<pitti> LaserJock: I'm not fussed about the form; send a patch with some verbiage, a debdiff, a merge proposal, etc.
<pitti> LaserJock: I'm more concerned about adding appropriate test cases than the patch format :)
<pitti> LaserJock: got it, thanks
<LaserJock> ok, great
<didrocks> good morning
<dholbach> good morning
<jaromil> good morning
<ohsix> man, what could stop job control? nothing in one terminal (or more) in this session will succeed running anything in the background with &, it just says "Stopped" next time i hit enter
<akheron> ohsix: maybe some terminal attribute?
<akheron> ohsix: try invoking reset
<ohsix> if i use ^Z then bg it works, hm
<ohsix> weird, a reset fixed it
<ohsix> and it was only happening with a script i had in my home dir that just ran rdesktop with some switches
<akheron> IIRC, processes reading stdin will get "Stopped" once they're backgrounded
<akheron> cat &
<akheron> [1]+  Stopped                 cat
<alkisg> I'd like to file a bug report about "package linux-image-generic-lts-backport-natty missing in Lucid" - where do I file that? Under ubuntu-meta?
<cjwatson> no - perhaps linux-meta, but I thought that was being taken care of anyway
<alkisg> Ah, I don't have any info on this other than checking the archives - if it's being taken care of no need to file a bug, thanks
<cjwatson> you could check with #ubuntu-kernel in case I'm wrong
<alkisg> Thank you
<cjwatson> I just saw some conversation go by about it a couple of weeks ago
<pitti> hm, since yesterday the live fs fails to build due to "Failed to fetch bzip2:/var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_oneiric-security_main_binary-i386_Packages" -- new apt?
<pitti> mvo: ^ might coindice with 0.8.14.1ubuntu4, which was uploaded yesterday
<mvo> pitti: yeah, that sounds like it, let me check the build log
<pitti> mvo: does it try to apply checks to local files which it means to apply only to http:// files or so?
<mvo> pitti: it shouldn't, its mostly sanity checking that the release file/package file is correct
<pitti> mvo: http://paste.ubuntu.com/615218/
<pitti> mvo: not very verbose, I'm afraid
<pitti> it does seem to work quite fine locally, though
<pitti> mvo: does it unpack the file before the sanity checks?
<mvo> pitti: it should, let me double check and also check why the error is not more verbose, its supposed to have  proper error strings. what is the best way to reproduce? is the sources.list public?
<pitti> hmm, good question
<pitti> setting up cdimage is not exactly trivial
<pitti> mvo: fortunately we don't have an alpha-1 to do on Thursday, so it doesn't matter much
<pitti> oh, wait :)
<pitti> mvo: still puzzled how to reproduce this :/ but I don't think there's any magic in the sources.list, it's by and large just a debootstrap, add standard oneiric sources, update, and then install the desktop task
<pitti> well, there's obviously a lot of magic after that
<pitti> mvo: let me try building a chroot here and setting up apt there
<cjwatson> setting up cdimage is non-trivial, but running livecd-rootfs is not hard
<cjwatson> take oneiric system, install livecd-rootfs, change to a scratch directory, run 'livecd.sh -doneiric -ai386 ubuntu'
<cjwatson> as root
<pitti> ah, there's the sources list
<mvo> cjwatson: thanks
<pitti> hah
<pitti> W: Failed to fetch bzip2:/var/lib/apt/lists/partial/de.archive.ubuntu.com_ubuntu_dists_oneiric-security_main_binary-amd64_Packages
<mvo> pitti: with the method that colin outlined?
<pitti> mvo: it seems to happen with oneiric-security or oneiric-updates
<pitti> as these have empty package files
<pitti> mvo: no, in a normal install
<pitti> I also tried in a fresh chroot, same issue
<pitti> mvo: I think it doesn't consider an empty file as valid
<pitti> +deb http://archive.ubuntu.com/ubuntu/ oneiric-security main
<pitti> I merely added this, and then apt-get update
<pitti> this should make an easy test case in apt's test suite?
<mvo> pitti: nice catch, I fix this now \o/
<pitti> thanks mvo!
<mvo> the fix is ready, uploading now
<pitti> mvo: you rock, thanks!
<mvo> thank you for the debugging :)
<sleon> hi
<sleon> which printing subsystem library does ubuntu use to conenct gnome applications to cups?
<sleon> is it gutenprint_
<sleon> or something?
<sleon> or do you communicate other dbus or something?
<hrw> can someone take a look at my gcc-4.6-armel-cross 1.48 package? It is same as gcc-4.5-armel-cross (already in archive) and builds gcc-4.6 cross compiler. It is NEW package which I maintain for Ubuntu. Once uploaded I will ask for PPU for it (got it granted during DMB meeting).
<hrw> package is at http://home.haerwu.biz/~hrw/ubuntu/
<pitti> mvo: hm, did your apt upload fail for some reason? (just to avoid misunderstandings)
<pitti> mvo: ah, there now, nevermind
<mvo> pitti: let me see, I did not see a error from dput
<mvo> aha, ok
<mvo> yeah, just got the mail
<cjwatson> could an MIR team member look at bug 790547 as soon as possible, please?  ubiquity 2.7.0 is blocked on it
<ubottu> Launchpad bug 790547 in python-xklavier (Ubuntu) "[MIR] python-xklavier" [Undecided,New] https://launchpad.net/bugs/790547
<doko> looking
<cjwatson> thanks
<doko> 40000 lines of packaging for 49 lines of code. interesting ratio
<soren> O_o
<cjwatson> oh, by packaging you're counting autotools, right
<cjwatson> I think you should count xklavier.defs and xklavier.override as code too, though
<doko> agreed
<doko> ev: what's the python3 status of python-xklavier?
<ev> doko: looks like it's fairly quiet upstream, and would need to be ported to python3 (which I'm happy to do as part of the ubiquity port): http://devel.randomink.org/projects/python-xklavier/repository
<doko> ev: hmm, the package currently ftbfs
<doko> https://launchpad.net/ubuntu/+source/python-xklavier/0.4-2
<ev> lovely
<ev> I'll have a look in a bit
<seb128> ev: there was a cdbs issue that looked similar to that iirc, maybe just retry the build, it has been fixed since
<ev> seb128: will do, thanks for the heads up
<seb128> yw
<pitti> seb128: http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html still has some uninstallables for gnome-python-desktop, I look into this
<ev> seb128, doko: yep, that did the trick.
<seb128> ev: great
<seb128> pitti, thanks
<doko> ok, will wait until it's in the archive
<pitti> seb128: ah, it's due to libbrasero-media1 being uninstallable
<seb128> pitti, it's a NBS lib
<seb128> pitti, we should probably drop those bindings, are they used?
<pitti> so, working on that then
<pitti> seb128: one rdepends (pybackpack)
<seb128> pitti, the new lib uses GTK3 so that will require porting
<pitti> seb128: right, so no python-brasero then; I guess we drop it then and break pybackpack
<seb128> pitti, we will need to break quite some things this cycle imho
<seb128> pitti, I will write an email to the lists in a bit about that
<seb128> i.e all the transitions going on for gtk3, dconf, gnome-panel-applets on dbus
<seb128> g-i
<seb128> pitti, we can't really port the world so we should just take it as an opportunity to clean some old unmaintained things are the end of the cycle
<pitti> *nod*
<pitti> brasero doesn't yet build a .gir, though
<pitti> or at least we don't package it
<chrisccoulson> talking of cleaning old and unmaintained stuff, i'll probably have some package removals for you this week pitti
<pitti> chrisccoulson: bring'em on
<chrisccoulson> so make sure your axe is nice and sharp ;)
<seb128> chrisccoulson, oh, you want to play who can clean the highest number of cruft this cycle? ;-)
<seb128> bring them on! ;-)
<seb128> pitti, brasero> it's just a matter of turning it on it seems, I will have a look to it
<pitti> ah, nice; we can do that in Debian, too, I figure
<seb128> pitti, debian turned it off to not tangle 2 transitions when they uploaded the new version
<pitti> hm, it's just a binNEW package?
<seb128> pitti, it's an extra stack to migrate to testing at the same time
<seb128> but yeah they could probably turn it on in experimental
<seb128> "  * Disable introspection support to avoid blocking the totem
<seb128>     transition.
<seb128> "
<seb128> in the changelog
<pitti> ah
<pitti> not that easy to get gnome-python-desktop build in the first place
<seb128> pitti, we should start dropping the bindings that don't have rdepends or a few if needed
<pitti> yeah, got it
<pitti> I need to drop python-evince
<pitti> will also get rid of two more NBS
<pitti> sugar-read-activity is the only rdepends, but tomeu said it's being ported upstream
<seb128> ok great
<pitti> hah, built
<pitti> rhythmbox-plugin-cdrecorder just needs a rebuild on amd64, doing that
<seb128> pitti, you are sure?
<ev> so before I go ahead and start porting ubiquity to gtk3 as I port it to pygi, are we definitely going to have a gtk3 theme this cycle?
<doko> pitti, seb128 : rhytmbox faild to build on amd64
<seb128> pitti, it seems like it ftbfs due to the new libdmapsharing version
<pitti> ah
<seb128> not sure a rebuild will work
<pitti> just have spotted it on nbs.html, haven't checked details yet
<seb128> pitti, we might need http://git.gnome.org/browse/rhythmbox/commit/?id=8ab9e5d08fd0bdfae25de00c225308d575736d50
<seb128> well http://git.gnome.org/browse/rhythmbox/log/?qt=grep&q=libdmapsharing
<seb128> some of those
<seb128> we got 2.9.12
<pitti> will have a look after lunch then
<seb128> pitti, we have a git snapshot so it's likely just the 2 most recent commits from the previous url to backport
<pitti> *nod*
<seb128> hum, why is gnome-panel, alacarte etc still on the CD?
<seb128> or at least on http://cdimage.ubuntu.com/daily/20110531/oneiric-alternate-amd64.list
<seb128> they have been dropped from the desktop seed (http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.oneiric/desktop) and I can't see a rdepends or something that would bring those back in
<didrocks> the gnome-session present is the right one, weirdâ¦
<didrocks> apt-get remove wants to remove indicator-applet*, let's see if we recommend one by error
<didrocks> indicator-applet-session is recommended by indicator-me
<didrocks> which brings indicator-applet-session, which dep on gnome-panel
<cjwatson> shown in http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/rdepends/ALL/gnome-panel
<didrocks> hum, no there is an alternative: | indicator-render, nevermind
<cjwatson> if you want indicator-render to be preferred, it needs to be the first alternative
<didrocks> ah, g-c-c then
<cjwatson> germinate (and, for that matter, apt) will normally pick the first one
<didrocks> cjwatson: right, and we are not sure unity/unity-2d is already there
<didrocks> making the change
<cjwatson> but I see that indicator-render is virtual anyway ...
<didrocks> cjwatson: yeah, it's provided by unity/unity-2d
<didrocks> so, that won't fix itâ¦
<cjwatson> unity provides indicator-renderer, not indicator-render
<cjwatson> if the former is meant, you have a typo
<didrocks> yeah, seems that the indicator part doesn't use the right term for a few release
<seb128> didrocks, what needs fixing?
<didrocks> cjwatson: but that won't fix it, as if indicator-me is processed before unity/unity-2d, it will pick indicator-applet-session? or all seeded are first processed before checking the dep?
<didrocks> seb128: indicator-me recommends indicator-applet-session | indicator-render. Should be renderer at least
<seb128> didrocks, do you want me to fix it?
<seb128> let's make it unity | indicator-renderer
<cjwatson> didrocks: "seeded" -> you're thinking purely in terms of what germinate will do, which is almost always a mistake.  germinate is largely just trying to mirror what apt will do
<cjwatson> seb128: agreed
<didrocks> cjwatson: ok, so yeah, we need to provide unity again in the recommends:
<didrocks> seb128: yeah, looks good
<seb128> didrocks, ok, doing that
<seb128> didrocks, cjwatson: thanks
<didrocks> thanks seb128, cjwatson :)
<didrocks> seb128: I didn't check other indicator, it would maybe nice to check all of them?
<seb128> didrocks, I will do
<cjwatson> as it happens, germinate does process all explicitly-seeded entries before trying to resolve broken dependencies; but it's still better to list the correct preferred alternative first rather than relying on that
<didrocks> seb128: indicator-messages should be changed at least
<didrocks> cjwatson: ok, so to sum up, with the typo fixed, it should be fine, but better to list the preferred alternative first still
<cjwatson> I think so, yeah
<didrocks> thanks cjwatson for the explanation :)
<apachelogger> who would be best to talk to about libcanberra?
<pitti> apachelogger: TheMuso I think
<apachelogger> thx
<apachelogger> TheMuso: pingy
<TheMuso> apachelogger: Please just ask, and I'll get to it when I am around. I am now, but am about to go to bed.
<apachelogger> TheMuso: Does bug 790608 sound sane to you? Also, we perhaps shoud have a virtual package libcanberra-plugin or similar that is provided by libcanberra-pulse and libcanberra-gstreamer.
<ubottu> Launchpad bug 790608 in libcanberra (Ubuntu) "libcanberra needs to depend on sound-theme-freedesktop" [Medium,New] https://launchpad.net/bugs/790608
<apachelogger> We use a similar virtual package approach for Phonon, which enables users to switch output plugins as they like without us having to depend on all available plugins.
<apachelogger> Rumor has it that someone wants to create a Phonon plugin for Canberra.
<fta2> mdeslaur, yt?
<fta2> mdeslaur, you updated pam in maverick, it totally killed cron
<mdeslaur> fta2: yes, I'm working on it now...bug #790538
<ubottu> Launchpad bug 790538 in pam (Ubuntu) "cron gives "Module is unknown" in syslog, stops working" [Critical,Confirmed] https://launchpad.net/bugs/790538
<fta2> mdeslaur, oh, great. thanks.
<fta2> mdeslaur, i'm reverting for now.
<mdeslaur> fta2: you can just restart cron
<mdeslaur> fta2: until a fix is pushed out
<fta2> mdeslaur, oh, ok. I'll try
<fta2> good, it worked
<lool> I got dropped into an initramfs prompt on reboot (hadn't rebooted in some days); is this is a known issue?
<lool> (I switched to an older kernel to complete boot, I don't mind investigating if it's not a known bug)
<cjwatson> fta2: https://wiki.ubuntu.com/IncidentReports/2011-05-31-pam-security-update-breaks-cron
<fta2> cjwatson, thanks. fortunately, i blocked it after it killed a service on the 1st server i updated
<jibel> lool, same here, I'm investigating
<smb> pitti, Hi Martin, have you been doing the recent copy to updates for the linux package in lucid?
<pitti> smb: hey; yes, as it got QA signoff and QA set it to v-done
<pitti> something wrong with it?
<smb> pitti, Nothing with that, though... smoser was wondering why the linux-ec2 package is lagging
<pitti> smb: that one didn't get QA signoff yet
<pitti> oh, it did
<pitti> smb: ok, publishing that, too
<smoser> pitti, smb thanks.
<smb> pitti, Thanks... thought it had in Lucid but getting confused with many directions/releases lately
<jibel> lool, amd64 or i386 ?
<smoser> pitti, smb there will be a linux-ec2-meta update for that also ?
<pitti> smoser: yes, that comes as a bundle
<smoser> linux-meta-ec2.  ok. .. so -proposed https://launchpad.net/ubuntu/+source/linux-meta-ec2 has had 2.6.32.316.17  for 5 weeks, but the linux-ec2 has only been for 13 days in -proposed
<smoser> smb pushed something in 13 days ago to linux-ec2, would that require a linux-meta-ec2 update ?
<smb> smoser, Only if the abi number changed and I think that did not
<pitti> kees, jdstrand: published linux-ec2 linux-meta-ec2 to lucid-{updates,security}, on top of the main linux/-meta stuff from yesterday
<pitti> smb, smoser ^
<smoser> pitti, smb, thank you again.
<lool> jibel: amd64
<jibel> lool, thanks. you can try downgrading udev to 170
<dholbach> thanks ev - I'll try it out
<dholbach> do you know if somebody is looking into fixing the issue?
<ev> sure thing
<ev> yeah, pitti is
<dholbach> awesome
<pitti> I need to reproduce it first
<pitti> seems that everyone's boot fails except mine :/
<pitti> 1:20 minutes left for alternate download
<pitti> (was said to be reproducible in kvm)
<dholbach> I upgraded a natty vm to oneiric (very early on), default desktop i386 install
<dholbach> since I rebooted with 171 I run into the issue
<pitti> dholbach: ah, this is kvm, not your real system?
<pitti> lool: what about your's?
<dholbach> kvm, yes
<evfool> what is the criteria to propose an application to be ported to PyGI for oneiric? I see the GTK/GNOME3 blueprint has a long list of those
<pitti> evfool: "everything we can get"
<pitti> evfool: i. e. all rdepends of python-gtk2 are welcome
<pitti> (and have to be ported at some point)
<StevenK> pitti: How many of those are on the CD?
<StevenK> (Roughly)
<pitti> hmm, some 15 perhaps?
<pitti> we have already ported 6 or 7 during natty
<pitti> and usb-creator in oneiric
<pitti> gnome-about is gone
<evfool> just asking because Update-Manager isn't listed at all
<pitti> so perhaps it's a lot less these days
<pitti> evfool: oh, that's a good target indeed, and shouldn't be too hard to port
<evfool> pitti: I've tried to do that, it runs, but the interface is not displayed at all... so maybe someone with a bit more experience should try to do that :)
<evfool> and no error message is displayed
<pitti> evfool: perhaps you can add a link your branch to the whiteboard, with a status note?
<pitti> I can't look at it right now, sorry
<pitti> but I'm interested in general
<evfool> ok, I'll do that later than
<evfool> so it's OK to list update-manager in the blueprint :)
<pitti> absolutely, yes
<pitti> FWIW, I get a boot failure in kvm with merely upgrading the kernel and initramfs and grub, leaving udev at 167
<pitti> (alternate install still running; kvm doesn't like my virtio drive any more, so taking even longer than it used to, sorry)
<mvo> pitti, evfool: bear in mind that for u-m the "release-upgrader" part will need to stay gtk2 for a bit because we need to support lucid->P upgrades
<pitti> mvo: oh, I thought it would download u-m from the target release
<pitti> mvo: i. e. lucid's u-m must be able to upgrade to P?
<mvo> pitti: indeed, but if the oneiric version is gtk3 but lucid has no gtk3 instaled lucid->P will not work
<mvo> pitti: the release-upgrader part of it need to work on lucid
<jibel> pitti, I can reproduce on real hardware as well (and now I need to recover :( )
<pitti> jibel: just exiting from the busybox shell doesn't work?
<pitti> mvo: i. e. it doesn't fetch new dependencies?
<jibel> pitti, I dont know, the keyboard doesn't respond :)
<mvo> pitti: we would have to backport them to lucid. its possible to make this work, but it will be more fragile. one of the principles is to chnages the system as little as possible before the final "upgrade now" button is hit.
<pitti> mvo: right, understandable
<mvo> pitti: if we would fetch P version of gtk etc then half the system would be upgraded already before the upgrader really is run :)
<mvo> which makes those transitions unfortuantely a bit cumbersome for it
<pitti> mvo: so pygtk and gtk2 will need to stay on the CD for P?
<mvo> pitti: hm, let me think about it for a second. so we only need it in oneiric because for oneiric -> P the oneiric version of pygtk2 will be used and once the upgrade is over its no longer needed. so P itself would not need it
<mvo> pitti: in order to get rid of pygtk2 in oneiric we will have to have two UIs for the release upgrader actually, that is already supported and should be pretty straightforard
<pitti> mvo: but we want to support direct lucid->p upgrades, too?
<mvo> pitti: so it will try to import DistUpgradeViewGtk3 if that fails falls back to DistUpgradeViewGtk. then we are on the safe side and it will just work for lucid->p and oneiric (without pygtk2) to P)
<pitti> mvo: (I don't think its a major problem to have pygtk on the P CDs)
<mvo> pitti: yeah, for the P upgrade we need to support both lucid -> P and oneiric->P
<pitti> it's 3 or 4 MB extra of course, but at least in P+1 we have something up our sleeves to save :)
<mvo> pitti: ok, but I thnk we can get away without it by just adding the Gtk3 fontend.
<mvo> and keeping the gtk2 as a fallback
<mvo> means more testing, but the gtk2 code is pretty stable and does not really change much
<pitti> mvo: btw, what was the last pygi port you did a couple of days ago? how did that go?
<smoser> anyone know who is responsi ble for updating http://releases.ubuntu.com/jigit/ ?
<mvo> pitti: gdebi, went very smooth
<pitti> mvo: ah, right; that's not in oneiric yet, right?
<mvo> not yet, I should upload it
<cjwatson> smoser: that would be me
<pitti> mvo: or "sid" that is
<cjwatson> smoser: oh, huh, yeah, should add natty
<mvo> pitti: is sid ready for gtk3/GI yet? I'm not 100% up-to-date here
<pitti> mvo: sid has pygobject 2.28, g-i 0.10.8, and gir1.2-gtk-3.0 3.0.8; looks fine
<smoser> cjwatson, yeah, thats all.  I was looking at bug 789219 . I sent message to upstream, and he is willing to incorporate the patch in comment 1, so we can eventually drop our ubuntu specific package there.
<ubottu> Launchpad bug 789219 in jigit (Ubuntu) "Please merge jigit 1.18-1 (main) from debian unstable" [Wishlist,Fix released] https://launchpad.net/bugs/789219
<pitti> mvo: some GNOME 3 stuff is still in experimental, but the basic libraries are in unstable
<mvo> pitti: vte is the only exotic depenency that gdebi has
<pitti> mvo: you are using vte 2.90?
<mvo> yes
<pitti> ah, bummer
<pitti>  gir1.2-vte-2.90 | 1:0.28.0-1+b1 | experimental | amd64 [...]
<zul> who do i talk about broken udd imports?
<pitti> mvo: so, for experimental I guess :/
 * mvo nods
<pitti> mvo: uploading it to unstable is blocked on libgladeui-dev, which is blocking on nautilus, IIRC
<smoser> cjwatson, also, i just now notice that lucid doesn't work. (http://releases.ubuntu.com/jigit/ubuntu-10.04-server-amd64.conf says "lucid/ubuntu-10.04-server-amd64.jigdo" but it needs "ubuntu-10.04.2-alternate-amd64.jigdo"
<mvo> ok, I upload the gtk3 version as a ubuntu version then for now and resync once unstable is ready
<seb128> who is doing syncs?
<seb128> cjwatson, ?
<smoser> er... without the 'alternate'.  the point was it needs "10.04.2" not "10.04"
<pitti> seb128: I synced the keyring stuff, calibre, and a few others
<seb128> pitti, can you add gtksourceview3?
<pitti> seb128: I'm already flushing, but I can sync that, sure
<seb128> oh it already is
<pitti> seb128: hm, I updated that, didn't I sync it?
<seb128> you did, I didn't see the email on -changes
<seb128> ignore me
<pitti> :)
<seb128> pitti, thanks
<seb128> (I was just going to do the keyring syncs ;-)
<ev> build depends of a main package also have to be in main, right?
<StevenK> ev: Correct.
<ev> rubbish :)
<StevenK> ev: Then your build will hit MANUALDEPWAIT. :-)
<ev> yay
<cr3> is germinate the right tool to determine the list of packages that need to be installed from a default ubuntu-desktop installation to the same installation with an extra package which might have some dependencies?
<pitti> ev, jibel, lool, dholbach: so I installed today's alternate (20110531) with udev 170, upgraded to udev 171 (no other packages), still boots
<pitti> jibel: ^ is that how you tested?
<apw> cjwatson, as we don't merge module-init-tools from debian, i assume we should be calling it x.y-0ubuntu1 ie. with the 0
<pitti> others: does the boot failure actually show any error message?
<pitti> apw: why don't we, OOI?
 * pitti does a full dist-upgrade now
<dholbach> pitti, AFAIR it showed a UUID that wasn't available
<apw> pitti, now that i am unsure of, a scott thing originally i assume
<ev> pitti: I upgraded from Natty this morning.
<pitti> ev: also wrong UUID?
<ev> pitti: correct, though root=/dev/sda1 didn't fix things either
<ev> presumably the devtmpfs wasn't mounted yet
<cjwatson> apw: might be worth looking at whether we can resync with Debian
<apw> cjwatson, yeah i guess so ...
<pitti> still boots after full dist-upgrade
<cjwatson> cr3: yes; the --seed-packages option may help you
<cjwatson> see the man page
<cr3> cjwatson: will do, thanks for the pointer!
<jibel> pitti, that's how I tested.
<pitti> hmm
<pitti> dholbach, jibel: do you still have a machine that fails like this?
<dholbach> pitti, let me upgrade again and see what happens
<pitti> perhaps you can compare the UUID in /etc/fstab, and in grub?
<pitti> but root=/dev/sdaX instead of UUID= should really work
<pitti> if not, then it's not the UUID, but something else
<jibel> pitti, yes, booting
<hrw> do we have a tool which can fetch few packages with dependencies and unpack them? kind of debootstrap but without anythin other then just those packages (so for packages=libc6-dev I do not get busybox-initramfs)
<lool> pitti: I have one machine with the issue here
<jibel> pitti, uuid are the same in fstab and grub
<lool> pitti: The search --no-floppy --fs-uuid --set=root UUID matches the one in fstab here too
<tkamppeter> sabdfl, hi
<jibel> pitti, replacing root=UUID=... by root=/dev/sdaX doesn't work
<pitti> jibel: ok, thanks; so it's not a changed UUID (which would have been quite horrible indeed)
<ev> ugh, this GTK3 transition seems to have been horrendously managed.  There's no script to convert GTK2 GtkBuilder files to GTK3, for example.
<cjwatson> smoser: fixed now
<pitti> ev: there is
<cjwatson> smoser: (natty, lucid, hardy, dapper)
<pitti> ev: hang on, need to remember where it was
<pitti> ev: ah, gtk-builder-convert should do it?
<seb128> oh
<apw> cjwatson, ok so this does look vaguely re-mergable, unfortuanatly they don't have the version i want yet
<seb128> gnome-games stopped building gnome-sudoku so we should perhaps drop it from the seeds
<seb128> (seems it's still installable though so that's not a real issue yet)
<ev> pitti: that only does Glade to GtkBuilder. I'm looking to update an existing GtkBuilder to account for GTK3 dropping things like GtkComboBoxEntry
<ev> right now it just helpfully deletes the widget
<dholbach> pitti, same as the others said - it's still reproducible
<pitti> ev: ah, in my ports it was usually only that and dropping some obsolete separator thing; but I thought that gtk-builder-convert would do it, hmm
<ev> mind you, it's not just that.  The complete lack of documentation for the pygi stuff, or even an API reference / integration into python docstrings, leave me wondering if they considered third-party application developers at all
<pitti> ev: the lack of a python specific GTK API doc is indeed known; it's on the agenda for the June hackfest
<pitti> for now we need to use the GTK 3 docs
<pitti> ev: https://live.gnome.org/PyGObject/IntrospectionPorting might give some help
<ev> this amateur-hour stuff leaves me laughing hysterically at the "gnome is the platform" rubbish. You're not going to attract application developers by throwing obstacles in their path like this.
<ev> apols for the rant
<pitti> *nod*
<cr3> cjwatson: thanks a lot for the tip about --seed-packages, I could not have imagined a better solution!
<ev> thanks for the references
<cjwatson> cr3: glad you like it
* skaet changed the topic of #ubuntu-devel to: Oneiric Archive: Soft Freeze for Alpha 1 in effect | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<smoser> cjwatson, have you ever used the generic 'jigit' ?  do you know what possible things use the /jigit data at releases.u.c ? i'm trying to use it, and it doesn't seem like it could possibly work in its current state.
<cjwatson> smoser: I used it some years back; I have my own wrapper these days
<cjwatson> smoser: feel free to suggest fixes?
<smoser> so you're not aware of anything else that uses that data there then?
<cjwatson> no
<smoser> i'm conversing some with the jigit upstream about it. it seems fairly broken at this point, yet we carry an ubuntu modified source for it.
<cjwatson> we worked with Steve a bit some years back on it
<cjwatson> it may date from that
<cjwatson> I'm entirely happy to fix up the server side if there's something wrong with it
<smoser> server was some broken as i pointed out, but client is broken too.
<pitti> dholbach, lool: can you confirm that libudev 171 plus udev 170 makes things work again? this would help for bisecting the changes in it
<cjwatson> smoser: libjte, OTOH, is used in various places
<dholbach> pitti, let me try
<pitti> dholbach, lool, jibel: I'll probably build a bunch of test packages then, and ask you which ones work and fail, to bisect the change
<cjwatson> or will be, I assume it isn't yet since I'm only just NEWing those binaries, but copies of that code are around elsewhere
<apw> cjwatson, where we have diverged for some time, is there a normal algorithm for merging the changlog entries order wise ?
<jibel> pitti, k, ping us when there's something ready for testing
<apw> cjwatson, i am sort of expecting you to say, just pull in the last version from debian to which you are resyncing
<cjwatson> apw: either chronological or by version, pick one ...
<cjwatson> apw: if we can get to the point where we can just do a verbatim sync from Debian, then the question becomes moot
<cjwatson> I don't know if that's feasible heree
<cjwatson> *here
<apw> cjwatson, yeah thats unclear currently, we have a heap of extra files right now
<pitti> jibel: confirming that it's not in libudev would help enormously, as it would rule out 4 of the 18 changes already (and I can already rule out 8 others)
<dholbach> pitti, libudev 171 plus udev 170 does NOT make things work again
<pitti> dholbach: thanks for confirming
<seb128> dholbach, what sort of error do you get?
<dholbach> seb128, something like "giving up on waiting for root device: uuid <...> not found"
<seb128> ok, that's a different issue from what some people mentioned in #ubuntu-desktop before where xorg was not starting because of a /run/udev they had
<dholbach> no, not xorg
<pitti> I think I've got something, hang on
<calc`> chrisccoulson: one thing that might annoy users in the switch from evolution to thunderbird, if they are using imap mail stored on server tbird can't (or didn't for many years) sort properly based on 'non-standard' headers, i don't have the bug number atm but its been in bugzilla for a long time
<calc`> chrisccoulson: if it still is an issue it might warrant a note in the release notes, istr the bug report noting it would be extremely hard for them to fix the bug due to how tbird was written
<pitti> dholbach: oh, hang on
<pitti> dholbach: ISTR that jibel(?) said that merely downgrading udev and not libudev would work for him
<pitti> ok, I give up for alpha-1; I'll just revert to 170
<jibel> pitti, I said "<jibel> pitti, still broken with udev at 170 and libs at 171"
<pitti> jibel: oh sorry, then I misunderstood
<dholbach> jibel++
<pitti> jibel, dholbach: what about udev 171 and libudev 170?
<dholbach> let's see
<pitti> I have 4 commits for libudev, and 3 for daemon
<pitti> so apparenlty it's not the ones for daemon rule processing
<jibel> pitti, udev 171, libgudev 171, libudev 170 does not work
<pitti> weird
<pitti> gudev isn't involved that early
<pitti> if it's not libudev and not udev, then what else..
<pitti> anyway, prep'ing a reversion for now
<dholbach> jibel, pitti: installing libudev 170 and updating the initramfs makes it work
<pitti> ah, interesting!
<dholbach> let me double check the versions
<pitti> right, merely downgrading libudev won't rebuild initramfs
<pitti> udev will do that
<dholbach> yes, just downgraded libudev to 170
<jibel> pitti, I confirm what dholbach said. running initramfs after downgrading libudev 'fixes' the problem
<dholbach> jibel, everybody loves 'fixes' :)
<pitti> ok, test-booting my reversion now, and hoping that it'll fix stuff for you guys, too
<pitti> dholbach, jibel, lool: I uploaded udev 171-0ubuntu2 which is pretty much a reversion to 170; it should work, but confirming appreciated
<pitti> I'll dissect the libudev patches tomorrow then
<dholbach> on it
<ubuntu_> i was wondering when the daily-live .isos for xubuntu 11.10 would be out
<pitti> dholbach: needs to build first :) but you can grab the .debs from https://launchpad.net/ubuntu/+source/udev/171-0ubuntu2/+build/2538535 (amd64) or https://launchpad.net/ubuntu/+source/udev/171-0ubuntu2/+build/2538537 (i386) when they are ready
<cjwatson> ubuntu_: please use a less generic nick
<cjwatson> ubuntu_: the Xubuntu CD builds are failing due to a conflict between xfce4-notifyd and notification-daemon (http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/xubuntu/20110530/livecd-20110530-i386.out); the Xubuntu developers need to fix that
<cjwatson> bah
<cjwatson> suppose I should have given the useful answer first
<luk> he's not coming back :-)
<charlie-tca> he also cross-posts to at least three channels
<pitti> lool, jibel, dholbach: amd64 binaries ready for testing: https://launchpad.net/ubuntu/+source/udev/171-0ubuntu2/+build/2538535
 * dholbach waits for i386 :)
<pitti> they work here, but then again 171 did as well, so I'm not a good test case
<ricotz_> pitti, is the plain 170 again?
<pitti> yes, except that the diff.gz looks horrible :)
<ricotz_> pitti, ok, i just reverted to 170 package which solved it for me
<pitti> bbl
<jibel> pitti, thanks, have a nice evening
<dholbach> i386 built too: https://launchpad.net/ubuntu/+source/udev/171-0ubuntu2/+build/2538537
<dholbach> let's see if it works
<charlie-tca> why does gdm now depend on ubuntu-desktop? it makes it pull in all of gnome for Xubuntu again
<dholbach> charlie-tca, are you talking about oneiric gdm?
<dholbach> I can't find it in the dependency list
<seb128> charlie-tca, it doesn't?
<charlie-tca> I read it wrong then?
<seb128> charlie-tca, what do you read?
<charlie-tca> I read the wrong thing, looked at apt-cache rdepends gdm instead of depends
<seb128> ok
<dholbach> pitti, issue 'fixed' on i386 with 171-0ubuntu2
<cjwatson> charlie-tca: http://people.canonical.com/~ubuntu-archive/germinate-output/xubuntu.oneiric/rdepends/ALL/notification-daemon is probably more useful
<pitti> dholbach: danke!
<charlie-tca> Thank you
<dholbach> de rien
<cjwatson> charlie-tca: (I assume that xfce4-notifyd is desirable)
<charlie-tca> yes, it seems so
<charlie-tca> Thanks very much for the help. We will keep looking.
<cjwatson> debfx: please just request syncs rather than re-signing .dsc files from Debian and reuploading them (qtzeitgeist)
<cjwatson> debfx: I'm going to reject this and replace it with a verbatim sync, since I'd rather have the exact same source file from Debian
<debfx> cjwatson: okay
<cjwatson> debfx: how does this interact with libqzeitgeist?
<cjwatson> ah, you uploaded both so I presume OK ...
<debfx> cjwatson: libqzeitgeist should be removed after it's synced
<cjwatson> OK - it's making its way through now, thanks
<cjwatson> (why does syncpackage re-sign the .dsc file, anyway?  it seems completely pointless)
<cjwatson> hmm, maybe LP does care if it's being uploaded the usual way
<micahg> cjwatson: if xfce4-notifyd provides/conflicts notification-daemon, why would it be pulled in if the -desktop package depends on xfce4-notifyd?  Would something in -standard or -minimal get to pull stuff in "first"?
<cjwatson> micahg: I assume that something depends on only notification-daemon
<micahg> cjwatson: well, that package is virtual and real
<cjwatson> you're going to make me do a proper analysis aren't you :)
<micahg> cjwatson: no, trying not to, I'm just lacking some understanding on how the dependency resolution works
<micahg> cjwatson: libnotify4 seems to pull it in, but I'm wondering why xfce4-notifyd isn't fulfilling the requirement
<TerminX_> micahg: maybe something is depending on notification-daemon with a specific version and xfce-notifyd isn't providing that
<Laney> aptitude why notification-daemon might tell you
<micahg> no and no
<micahg> cjwatson: do build depends affect the seeds for the live env?
<seb128> micahg, no
<cjwatson> micahg: have you looked at the germinate output?
<micahg> cjwatson: yes, but it's like gibberish to me, I don't know what to look for, it's a virtual package so it makes sense that it would have a lot of rdepends
<cjwatson> so it's being pulled in by Recommends from libnotify4 in the desktop-common seed
<cjwatson> that's expanded completely before considering the Xubuntu desktop seed, so it makes sense that a specific seed entry for xfce4-notifyd there wouldn't have any effect
<micahg> right, so desktop-common takes precedence over xubuntu-desktop?
<micahg> ah
<cjwatson> precedence is the wrong way to think about it ...
<cjwatson> anyway, stuff that depends on / recommends desktop-environment-specific things like a notification daemon should not be in desktop-common
<cjwatson> the proper fix is to isolate those dependency chains and move them to the DE-specific desktop seeds
<micahg> so, it's libnotify-bin that's in the seed
<micahg> desktop-common that is
<cjwatson> I think it's just a matter of moving that, yes
<cjwatson> it'll have to be moved to all the things that use desktop-comomn
<cjwatson> ^T
<cjwatson> do you want me to take care of that?
<cjwatson> I have all the branches checked out already
<micahg> cjwatson: yes, please, I don't have access to the seeds
<cjwatson> OK
<cjwatson> you aren't core-dev yet?
<micahg> cjwatson: no, not yet
<cjwatson> bah :)
<cjwatson> clearly should be
<micahg> cjwatson: thanks :)
<cjwatson> ah, libnotify-bin in desktop-common was a recent changes
<cjwatson> *change
<cjwatson> for bug 616028
<ubottu> Launchpad bug 616028 in bash (Ubuntu) "add an "alert" alias, which can optionally be added after long running commands" [Wishlist,Fix released] https://launchpad.net/bugs/616028
<seb128> cjwatson, libnotify-bin shouldn't force a server though
<seb128> Depends: libc6 (>= 2.3.6-6~), libglib2.0-0 (>= 2.26), libnotify4 (>= 0.7.0)
<cjwatson> libnotify4 Recommends: notification-daemon
<cjwatson> it will work once it's moved to the desktop seed
<seb128> cjwatson, but xfce4-notifyd provides notification-daemon
<cjwatson> having it in the desktop-common seed means that germinate is forced to pick one before it knows what desktop environment it's working on
<seb128> so it should be enough for the recommends
<cjwatson> not with it in the desktop-common seed it isn't
<cjwatson> it will be fine when it's moved to the desktop seed
<seb128> oh, ok, gotcha
<cjwatson> the desktop-common seed has to be common *when expanded*, as well as just having common seed entries
<seb128> right, makes sense
<seb128> how do we fix it then?
 * micahg now knows to look for seed entries in germinate output :)
<cjwatson> seb128: by moving it to desktop in all the flavours.  I'm doing that now
<seb128> cjwatson, thanks
<cjwatson> micahg: seed changes done; I'll go and respin -meta now
<micahg> cjwatson: thanks!
<apw> cjwatson, ok i've had a go at resyncing with module-init-tools with debian, i wonder if you might have time tommorrow to look it over as a sanity check ... i've compared the binary packages for content but not yet tested them: lp:~apw/module-init-tools/resync
<cjwatson> I'm on holiday tomorrow to Friday
<cjwatson> probably best to find somebody who's more around :)
<apw> cjwatson, will do, enjoy :)
<cjwatson> (though shouldn't it wait 'til after alpha 1, really?)
<apw> cjwatson, oh i am not intending to upload anything till after A1 indeed
<micahg> cjwatson: I wanted to ask you, where you're the TIL person only for a no-change rebuild, can I request syncs for those packages?
<cjwatson> sure
<micahg> k, thanks
<cjwatson> I assume that's a no-change rebuild on top of a real Ubuntu modification
<micahg> yes
<cjwatson> some day it might be nice if MoM could work out TIL-except-for-rebuilds
<cjwatson> never been worth the bother though ...
<micahg> in theory, haven't looked for anything real yet,but I know you touched several hundred packages for the rebuilds and  are now TIL where there might be no diff
<cjwatson> yeah, there are a few
<micahg> s/rebuilds/transitions/
<infinity> Used to happen to me all the time.
<cjwatson> ah, good, xubuntu-meta doesn't need to be changed
<cjwatson> ... which implies that we just need to wait for a couple of publisher run
<cjwatson> s
<micahg> jelmer: I saw the bzr-rebase package was dropped for oneiric, don't we need it for Lucid -> P upgrades/
<jelmer> micahg, hi
<jelmer> micahg, yeah, we'll need to worry about that - we should probably diverge from Debian because of that
<micahg> jelmer: why not keep it in Debian (what does it hurt, at least until wheezy is a bit closer to release)
<broder> slangasek: ping? is there a recommended way to discover what the multiarch-friendly directory for pam modules is? i'm working on fixing up the google-authenticator package, and i'll likely try to set it up as multiarch-enabled
<slangasek> broder: "discover"... well, it's /lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/security
<slangasek> you'll need to make sure you have a versioned pre-dep on libpam0g (>= 1.1.2-2ubuntu4) for that
 * broder nods
<broder> hmm...i guess this is actually a bit complicated, since the package also ships with a binary, and i don't actually want to create a new package as an ubuntu delta. oh well
<slangasek> broder: why would it need to create a new package?
<broder> i can't mark two packages as multiarch: same if they both ship a binary in /usr/bin, right? (i'd need to split off the binary and mark it as multiarch: foreign)
<broder> err, one package, rather :)
<broder> (libpam-google-authenticator has a /usr/bin/google-authenticator that you use to setup the shared secret for the 2-factor token)
<slangasek> oh right
<slangasek> is /usr/bin/google-authenticator actually an internal interface?  Could it move to /lib/$triplet/ ?
<slangasek> or is it a user-facing executable?
<broder> it's user-facing
<slangasek> ok
<broder> you run that, and it spits out a QR code that you scan on your phone to synchronize the OTP generation
 * slangasek nods
<broder> i'll try to get it cleaned up on the debian side, and i'll settle for just making it build on ours for the moment :)
<mikey_> Hello. I'm wondering if I can get a little help with understanding ubuntu's take on X and its security policy?
<mikey_> Basically a while ago I made a little tool to start up applications in a second X session as a way of circumventing the issues of running games under compiz.
<mikey_> http://code.google.com/p/xgamer/
<mikey_> I did this in frustration with these issues, and at the time I wrote to the compiz developers to ask if they were working on a solution to these issues. They told me they were but 2 years on and there's nothing forthcoming.
<mikey_> Unity is now standard so compiz in unavoidable. My tool was used by a few as a work around. Ubuntu has changed the security policy for X so that user applications cannot independently modify sessions in the way that mine seeks to.
<mikey_> So is there anyone who understands X and security issues in ubuntu who can help me form a better strategy?
<lifeless> mmm, kees might, or RAOF or bryce
<TheMuso> apachelogger: It does. My only concern is that we will be hearing sounds from the freedesktop theme that we don't want, however we do have this cycle to fix that up. The only other issue is that the freedesktop sound theme is in universe.
<apachelogger> TheMuso: MIR for the theme is filed, and on the way to main.
<TheMuso> apachelogger: As for having a package for plugins, you may want to talk to debian about that.
<apachelogger> ok
<apachelogger> TheMuso: As for the hearing of sounds from freedesktop theme, that is what it is meant to do. Just like hicolor for icons, if the requested sound is not available in the default theme, then it searches the fallbacks of that theme and if that too fails it looks in the freedesktop theme. Equally if an application deployes its own sounds, they would get installed to the freedesktop theme (applying the same fallback logic).
<TheMuso> apachelogger: Right, some in design/Mark may question such sounds.
<TheMuso> As in their quality.
<TheMuso> i.e too windows esc or some such
<TheMuso> apachelogger: But I guess we can resolve that as it comes up.
<apachelogger> TheMuso: Agreed.
<apachelogger> TheMuso: I'll prepare an upload to introduce the dependency then.
<TheMuso> apachelogger: ok thanks
#ubuntu-devel 2011-06-01
<mikey_> <lifeless> thank you
<lool> pitti: I bisected udev; thanks for the idea!  it was rather painful as I've hit many different races during boot, but the revision which caused me to be dropped in an initramfs prompt was "libudev: monitor - use SOCK_NONBLOCK"
<lool> pitti: Unfortunately, I've build 171 ubuntu1 + this patch reverted, and my system wouldn't boot, one error message on screen related to dmsetup
<lool> pitti: I wanted to mention that I use LVM
<lool> pitti: During tests, I've hit races with mountall and fsck checks, it was hard to tell whether it was another regression from 171 or an already existing bug which just got more visible
<lool> pitti: after looking at the other commits, I can't see another one in 171 which would introduce more races (except the above SOCK_NONBLOCK); the rest is mainly changes to symbols and to the systemd configs
<lool> pitti: Ok; fixed my system now: both your ubuntu2 with the reverted 171 changes and my 171 ubuntu1 + reverted broken commit from bisect were failing to boot in strange ways; only some LVM volumes were brought up, /home was missing; I disabled the /home volume and enabled it again, and everything worked with both your ubuntu2 package and with my 171ubuntu1 + reverted broken commit
<lool> pitti: So the bisected commit was the right one can be patched on top of latest udev
<lool> I'm pushing a package to my PPA for others to test
<Keybuk> I wonder why that breaks things
<cdbs> lool: So the udev fix is now in the archive?
<cdbs> Even I get an initramfs shell at boot
<cdbs> okay, pitti reverted those
<Gacy> http://www.blogtalkradio.com/billywalshe/2011/06/01/youre-too-chicken-shit-to-call-into-this-radio-show?ie8c=0
<micahg> !offtopic | Gacy
<ubottu> Gacy: #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please use #ubuntu-offtopic for other topics (though our !guidelines apply there too). Thanks!
<micahg> that wasn't what I expected that to do...
<Gacy> oh
<micahg> second part applies though
<pitti> Good morning
<stgraber> morning pitti
<StevenK> Hai pitti
<pitti> lool: ah, thanks for bisecting
<TheMuso> c
<pitti> lool: I changed the udev bzr back to 171 plus SOCK_NONBLOCK reverted, but I'll upload it after a1 only; once Kay is up, I'll discuss with him
<micahg> if I"m going to have an armel specific  version of a source package, should I append -arm or -armel?
<infinity> micahg: Ideally, you shouldn't have one at all...
<infinity> micahg: What's the scenario that's preventing you from shipping a patch in the regular source package and only applying it for ARM?
<micahg> infinity: I know, it's a special case :)
<infinity> micahg: Or having ARM-specific rules in debian/rules, etc?
<StevenK> micahg: And if you're having an armel specific version of the source, are you going to Conflict with the non-armel, or change them too? What about the rdepends?
<StevenK> This is a rabbit hole.
<micahg> no, it's for chromium, since the arm build takes over a day and we have no advanced notice, I split the source in the stable release so we can get the non-arm binaries out faster
<infinity> micahg: Err, but we release everything at once anyway.  I'm failing to see how this helps...
<infinity> micahg: If glibc and gcc get to suffer, so does chromium?
<micahg> I didn't really want to start the why debate...but in short, there's no USN so they can be published as they're ready
<infinity> micahg: Which is true even if you release while ARM is still building...
<micahg> infinity: no, you can only copy a source once
<infinity> micahg: Yes, and?
<infinity> micahg: You can then release the binaries later.
<infinity> micahg: We've been doing that for years.
<micahg> infinity: no, the binaries + source can only be copied once
<infinity> micahg: I suspect I'm not the person you want to argue with about this.  At all.
 * micahg didn't want to argue with anyone
<infinity> micahg: You can release binaries for architectures whenever you feel the urge.
<infinity> micahg: A USN could, in theory, be source-only, if someone thought that was a sane thing to do (which it isn't), and you could trickle the arches down one at a time.
<micahg> soyuz doesn't work like that AFAIK
<infinity> It really does.
<sbeattie> infinity: that's not what the security team's been told.
<infinity> sbeattie: They were lied to.  Or there was a miscommunication.
<infinity> sbeattie: Either way, I don't see us splitting other long-building packages for the sake of one slow arch.  Still not seeing the unique snowflake case.
<infinity> sbeattie: But at the level we're dealing with here, BPRs are all tied to SPRs, yes, but there's no reason you need to move/copy all the BPRs with an SPR.
<dholbach> good morning
<wgrant> infinity: Due to the current way that security updates are unembargoed, that's not really possible at the moment.
<wgrant> We should be able to.
<wgrant> It's easy enough to do.
<wgrant> Just need to expose the interface.
<wgrant> But we've not been asked with any significant importance.
<wgrant> micahg: So, please ask for LP to be fixed before you start implementing such hacks!
<infinity> wgrant: I suspect the above is significant enough, before people get unique snowflakey more. :P
<wgrant> infinity: Probably.
<infinity> wgrant: What's the issue?  I only vaguely recall the security-on-PPA hackery (I was doing security when it was a proper pocket)... Are the SPRs moved/wiped with a release?
<wgrant> Basically, delayed copies are a vile hack.
<infinity> wgrant: Thus leaving the BPRs effectively orphaned?
<micahg> wgrant: I thought I talked to the relevant parties, I guess I forgot to chat with you about it :)
<infinity> wgrant: Cause that's about the only way I could see it breaking.
<micahg> wgrant: they're not in the private PPA
<wgrant> micahg: Unless you talked to bigjools or me or possibly Stevenk, you were probably misinformed.
<wgrant> infinity: So, there are two ways this breaks:
<wgrant> 1) The copy checker will forbid copies when the source has pending builds, because multi-stage copies don't work very well. This can be easily fixed once multi-stage copies are.
<infinity> wgrant: (1) isn't an issue, it's a tool that needs unbreaking. :)
<wgrant> 2) Delayed copies (used for private copies) create a fake PackageUpload, and more than one of those for a single source won't be accepted into a particular suite.
<wgrant> 2 will go away once StevenK deletes delayed copies in a few weeks.
<wgrant> 3) The copy APIs provide no facility to copy binaries, only sources. And they're not set up to copy only missing things.
<wgrant> Well, for binaries it already mostly works. It won't create duplicate publications.
<wgrant> But it will republish the sources and break a few worlds.
<infinity> Republishing source is a non-issue, IIRC.
<infinity> It just no-ops at the level that any human cares about it.
<wgrant> It will create a new publication.
<wgrant> It might not break much, but it's undesirable.
<wgrant> and easily fixable.
<infinity> Well, see the "any human" bit. :)
<wgrant> Heh.
<infinity> Pretty sure we used to do it all the time.
<infinity> And if it made Soyuz cry, Celso never slapped me.
<wgrant> infinity: Pre-s-i-s, maybe.
<wgrant> Or back when the copier was less pedantic.
<wgrant> It was made more bullet-proof to stop PPA users from killing themselves.
<micahg> wgrant: so, should we have a longer chat later today?
<infinity> Hahahaha.
<StevenK> You mean back when the package copier was er, Celso?
<infinity> But yes, I'd love to see people not attempting these crazy hacks.
<wgrant> micahg: I think so.
<micahg> wgrant: what time do you start (UTC)?
<wgrant> micahg: This is a reasonable thing for a maintenance squad to take on in a post-critical era (probably Septemberish)
<infinity> StevenK: Well, okay, there was a time when copying packages was actually some SQL hacks that I'd do.
<infinity> StevenK: But no, I vaguely recall having something more fancy.
<wgrant> micahg: 2300-0800 are my coreish hours.
<wgrant> micahg: But I'm often floating around several hours later
<wgrant> infinity: Sure you're not recalling the wonderful dak hack?
<micahg> wgrant: ok, feel free to grab me when you start tomorrow, I should be around
<infinity> wgrant: No, that would be entirely different.
<wgrant> micahg: Will do.
<micahg> wgrant: thanks
<infinity> wgrant: With DAK, it was a series of real uploads.
<wgrant> infinity: Yeah :/
<infinity> wgrant: But I'm talking pocket copying, versus PPA->pocket insanity which SiS uses.
<infinity> wgrant: And I'm pretty sure pocket copying, and triggering source republishing, and other fun arch-skew issues were a non-issue, in practice.
<wgrant> infinity: Ah, that must have been before the pedantry.
<infinity> wgrant: Though I can see how they're irksome in theory.
<wgrant> infinity: Now it will outright forbid those copies, because there are builds in the wild.
<wgrant> (somewhat draconian, but the copier is a mess and doesn't handle duplication perfectly)
<infinity> wgrant: I'd respectfully claim that's broken. :P
<wgrant> It's all being cleaned up at the moment.
<wgrant> Which will make it feasibleish to fix in a few months.
<infinity> wgrant: Since BPRs have no relation to SPRs as a whole unit, only as a related child.
<wgrant> infinity: Right.
<wgrant> infinity: But it's a bit messy.
<infinity> wgrant: Story of Soyuz's life, yes. ;)
<wgrant> infinity: Because normally on a copy we create missing builds in the target.
<wgrant> infinity: For multi-stage copies we'd have to suppress that.
<wgrant> Basically, binaries are messy, everyone should just use source :)
<infinity> wgrant: Copies creating builds in the target should probably be the exception, not the rule.  Source-only copies (say, in PPAs), and new-release mass copies.
<StevenK> wgrant: Who do you think we are, Gentoo?
<infinity> wgrant: (And yes, that's an argument I probably should have made years ago)
<wgrant> infinity: I was about to say ENOT2006
<StevenK> infinity: i-f-p does not use the package copier, thank $DEITY
<infinity> wgrant: Because the "copy-creates-build" semantic is just as broken if you have an FTBFS in security and then copy to updates and create an updates build, for instance.
<infinity> wgrant: Which you really don't want.
<wgrant> infinity: Yes.
<wgrant> infinity: I have long argued that this needs to be rethought.
<wgrant> But it's hard, particularly in the new structure.
<wgrant> (there is no Soyuz team)
<infinity> I'll bottle some essence of cprov and mail it to you.
<wgrant> Heh
<infinity> StevenK: Except, note the irony that i-f-p is one of the few times when you DO want builds created. ;)
<StevenK> Heh
<wgrant> infinity: ... and it doesn't!
<wgrant> queue-builder used to.
<infinity> Yup.
<wgrant> But we destroyed queue-builder.
<wgrant> Because it is evil.
<infinity> I remember painful q-b runs after opening a new release.
<wgrant> Heh.
<StevenK> Oh, that took many hours?
<infinity> It would take a whole day at UDS.
<StevenK> Ugh
<wgrant> queue-builder took 30 minutes even in a good case.
<infinity> I'd keep popping open a screen session to tell people "no, not there yet".
<infinity> Good times.
<infinity> FSVO "good".
<StevenK> Haha
<wgrant> Hmm, using karma for search works pretty well.
<didrocks> good morning
<pitti> $ sudo rm -r /home/dchroot/dapper/
 * pitti sheds a tear
<pitti> dragon vs. duck anyone?
<wgrant> Oh, already? I thought it was next week.
<wgrant> Sad.
<infinity> Poor Dapper.
<wgrant> Means we can upgrade the buildds, yay.
<pitti> wgrant: yes, but as we don't have a pending tzdata update, I don't need it any more
<infinity> To?
<infinity> wgrant: Unless CAT has an urge to start supporting their own kernels again, I imagine the thing stopping buildds from being upgraded is the lack of Xen dom0 kernels in newer releases.
<infinity> (But that's just speculation)
<wgrant> infinity: Yeah, dom0 will stay on hardy, but I don't care about dom0.
<wgrant> launchpad-buildd doesn't have to work there.
<infinity> wgrant: Fair point.
<jaap_> goodmorning
<jaap_> i'am trying to install FTjam
<leoquant> goodmorning jaap_
<jaap_> i don't can use the software center of install by apt-get
<jaap_> i  need to changes some string in the software
<leoquant> so you are modifying software to improve it
<jaap_> yes to compile argyll
<leoquant> ok seems difficult  ã
<jaap_> hello??
<hrw> pitti: https://launchpad.net/ubuntu/+source/gcc-4.6-armel-cross exists now. can I get PPU permissions for it (as it was given me by DMB)?
<hrw> pitti: package got uploaded into NEW queue
<hrw> cjwatson: archive administration page lists you as today's admin. can I get gcc-4.6-armel-cross from NEW to archive? I can answer any questions about package.
<lool> dholbach, jibel: https://launchpad.net/~lool/+archive/ppa/+build/2539347 (amd64) https://launchpad.net/~lool/+archive/ppa/+build/2539348 (i386) has udev 171 + reverted patch; it fixes the boot with real 171 for me
<lool> pitti: You mentioned udev' bzr this morning, but yesterday it was failing to import http://package-import.ubuntu.com/status/udev.html#2011-05-16 09:17:00.101675
<cjwatson> hrw: I'm on holiday today
<hrw> cjwatson: sorry then
<pitti> lool: I meant the ubuntu package branch at https://code.launchpad.net/~ubuntu-core-dev/ubuntu/natty/udev/ubuntu
<pitti> hrw: added
<hrw> pitti: thank you
<dholbach> lool, confirmed
<lool> dholbach: cool, thanks
<lool> pitti: ^
<pitti> lool: do you have any idea what actually happens in the initramfs? is udevd running? does udevadm info --export-db work, for example?
<pitti> it certainly seems to be a race condidtion, as it doesn't happen everywhere
<lool> pitti: No, I didn't know how to debug this much; I saw that some devices by UUID had been created, I'm getting messages from udev that it can't open /dev/null and such, so it's definitely being started
<lool> pitti: if you like, we can try investigating together
<pitti> I'd still love to be able to reproduce this
<pitti> I still didn't try installing the faulty udev on my mini 10
<pitti> kvm and my laptop work
<lool> pitti: are you using lvm?
<pitti> lool: no, just plain ext4 /
<lool> dholbach, jibel: You folks using LVM?
<pitti> I think jibel reproduced it with the faulty desktop iso
<soren> Where can I find a list of things that changed in python 2.7.2? I have a test case that fails under 2.7.2, but works under 2.7.1.
<soren> Err.. /me tries in #python instead
<jibel> lool, pitti , right, default desktop install with the faulty iso.
<alkisg> Hi, in bug #737728 I put a "verification-done" tag but it was removed and "verification-needed" was inserted without explanation. Why? Is it some kind of meta-bug which needs some special form of verification? If so, how can I identify such bugs so that I don't put tags on them?
<ubottu> Launchpad bug 737728 in linux-meta-lts-backport-maverick (Ubuntu Lucid) "linux-lts-backport-maverick: 2.6.35-28.50~lucid1 -proposed tracker" [Undecided,Fix committed] https://launchpad.net/bugs/737728
<pitti> alkisg: kernel is special, only the QA team signs them off
<alkisg> pitti: so when I see verification-needed in kernels, I shouldn't put verification-done, right? Thanks.
<pitti> feedback is still appreciated, of course
<pitti> alkisg: well, for "real" kernel bugs you are welcome to
<pitti> just not for the tracking meta-bugs
<alkisg> Got it. Thanks for the explanation.
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Archive: Soft Freeze for Alpha 1 in effect | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<pitti> mterry: happy flying
<mterry> pitti, :)
<sladen> my goodness. soft freezes already
<sladen> development moves fast
<Laney> still looks like a long way if you look at the release schedule :-)
<dholbach> lool, kvm
<lool> dholbach: kvm or lvm ? :-)
<\sh> moins
<dholbach> lool, whatever natty qemu-kvm gives me
<lool> dholbach: ok
<achiang> chrisccoulson: what does the ~mfs mean in this version string? 4.0.1+build1+nobinonly-0ubuntu0.11.04.1~mfs~lucid1
<EtienneG> Looking for the release schedule of the lts-backport kernel, wondering whent he natty one will show up in lucid.  Anybody know?
<pitti> ScottK: what kind of shrinking did we use to do in pkg-kde-tools' cdbs rules?
<pitti> ScottK: we recently moved the remaining ubuntu specific bits of gnome.mk/debhelper.mk to pkgbinarymangler, seems we should just add the KDE bits there as well?
<JontheEchidna> pitti: lzma compression
<JontheEchidna> might need to be added to the new dhmk magic from Debian
<JontheEchidna> pitti: Yeah, this chunk is in the old debian-qt-kde.mk but not in the new one: http://paste.ubuntu.com/615911/
<JontheEchidna> oh, but it also uses the kde.pm sequence, which should include lzma compression there....
<ScottK> JontheEchidna: I think we need to look and make sure.
<ScottK> pitti: Is the changelog symlinking in the pkg-binarymangler now?
<sladen> doesn't each symlink still take up a full block on the disk?
<pitti> ScottK: yes, it is
<pitti> sladen: depends on the file system; but certainly not in .debs or the squashfs
<ScottK> pitti: We may be OK then if the lzma situation is good.  Fortuitous that you moved stuff.
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Archive: Soft Freeze for Alpha 1 in effect | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<JontheEchidna> ScottK: we seem to have pulled GTK in to the CD via libcanberra0
<JontheEchidna> that is at least part of our space problems
<ScottK> JontheEchidna: Ah.  Well that would do it.
<ScottK> So we can work on that for Alpha 2.
<ev> mvo: can you point me in the direction of this GIR wrapper you were talking about earlier?
<JontheEchidna> apachelogger: ^
<mvo> ev: bzr+ssh://bazaar.launchpad.net/~kamstrup/%2Bjunk/giraffe/
<ev> mvo: thanks!
<mvo> yw
<apachelogger> JontheEchidna: oh good
<apachelogger> JontheEchidna: you should split the gtk stuff out :P
 * apachelogger will likely not have time until tomorrow afternoon
<JontheEchidna> it's not a priority for alpha1, so there should be plenty of time for you to fix it :P
<apachelogger> JontheEchidna: oh, ok
<apachelogger> JontheEchidna: I have an upload pending for libcanberra anyway
<JontheEchidna> cool
<apachelogger> I'll do the changes on my way to randa and upload past alpha
<JontheEchidna> apachelogger: technically I think the GTK stuff is already split out, but libcanberra0 depends on the gtk package
<apachelogger> IIRC it should only depend on glib
<apachelogger> it was particularly designed to not depend on arguable stuff :P
<JontheEchidna> well somehow libcanberra-gtk0 made it on to the CD :P
<apachelogger> JontheEchidna: maybe it likes us
<smoser> ok. i'm looking at build output of a ubuntu cloud image: http://uec-images.ubuntu.com/lucid/20110531.1/
<smoser> this image was built yesterday, but did not receive 1.1.1-2ubuntu5 from lucid-updates.
<smoser> instead it received 1.1.1-2ubuntu2 (release).
<smoser> it *did* get other things from -updates. looking at https://launchpad.net/ubuntu/+source/pam it looks like maybe there was just a bad-timing snafu in correlation with security update 1.1.1-2ubuntu5.3 .
<smoser> anyone else able to explain that ?
<geser> doko_: is the "python3.2-config --ldflags" behaviour correct with including the libs to link too? ("python3.2-config --libs" just lists the libs as expected)
<slangasek> smoser: there was a severe SRU regression in pam yesterday that led to 1.1.1-2ubuntu5.2 being marked unreadable to block the damage from spreading
<ScottK> So that means 'feature.  not-a-bug.'
<slangasek> smoser: as a result, apt would probably have fallen back to the release pocket during that window, since 1.1.1-2ubuntu5.2 was unavailable, 1.1.1-2ubuntu5.1 was superseded, and 1.1.1-2ubuntu5.3 was not yet available
<smoser> slangasek, thank you. bad timing then for me :-(
<mdeslaur> smoser: sorry for that. my bad.
<lifeless> smoser: hi
<lifeless> smoser: jkakar says you've worked with / build a highly component-based thing before
<lifeless> smoser: in Launchpad we're just starting down a migration to such a setup, and I'd like to tap your knowledge, if I may :)
<elmo> lifeless: i thought that was smagoun?
<smoser> "highly component based thing"
<lifeless> hahhha
<lifeless> smoser: sorry.
<smoser> whew
<lifeless> smoser: E-EARLY-MORNINGS
<lifeless> elmo: thank you
<sebner> persia: I'm wondering if you ever become DD (thinking about your #1 bug) :P
<psusi> persia: could you get around to adding me to universe-contrib per last week's DMB?
<geser> psusi: done
<psusi> geser: yay!  thanks!
<Laney> we have been naughty on the minutes
<geser> Laney: we (DMB) should perhaps update the team description for https://launchpad.net/~ubuntu-dev a little bit
<Laney> geser: yeah, and rename https://launchpad.net/~universe-contributors to UCD probably
<geser> Laney: if I didn't miss anything only the bzr package set and PPU for John Rigby needs to be done from the last meeting
<Laney> not sure, I haven't been following the outcomes
<dart> Hello, I am experiencing some regression after a new natty SRU but I am not 100% sure
<jdstrand> dart: what is the regression?
<dart> after a fix to this bug --> Bug #774938, My pointer has started behaving oddly. I have also commented on the bug report.
<ubottu> Launchpad bug 774938 in xorg-server (Ubuntu) "Erratic cursor movement when using "Coordinate Transformation Matrix"" [Medium,Fix released] https://launchpad.net/bugs/774938
<dart> I am not sure if its related to this update or not but i started experiencing this problem only two days back.
<ScottK> !regression
<ScottK> Sigh.
<dart> Downgrade to earlier xorg-server will be safe?
<ScottK> !regression-alert
<ubottu> cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<slangasek> hoboy
<ScottK> It's probably a bit late for blacklisting, but here you go ...
<slangasek> dart: can you try downgrading the package to the natty release version, to verify that the problem is resolved?
<dart> Ok. I will do it. It is safe right?
<slangasek> dart: please also file a bug with 'ubuntu-bug xserver-xorg-core' and attach /var/log/apt/term.log
<dart> I got some data should i take a backup
<slangasek> dart: nothing in this world is provably safe; downgrading that package won't eat any data from your system, however
<ScottK> Downgrading the package should be safe.   You should always have current backups, I don't think you particularly need them more because of downgrading the package.
<dart> ok...I am doing it now
<ScottK> You'll need to restart X after the downgrade.
<dart> ok wait
<dart> The exact package is xserver-xorg-core or anything else?
<ScottK> xserver-common as well
<dart> ok
<slangasek> cnd: hey there!  dart is reporting cursor misbehavior after upgrading his X server; has commented on the bottom of bug #774938
<ubottu> Launchpad bug 774938 in xorg-server (Ubuntu) "Erratic cursor movement when using "Coordinate Transformation Matrix"" [Medium,Fix released] https://launchpad.net/bugs/774938
<cnd> slangasek, thanks
<slangasek> ah, dart has just disconnected, presumably to test his X server downgrade
<cnd> ahh
<slangasek> I've asked him to file a new bug as well, so we get the apport goodness
<cnd> good
<cnd> thanks
<ScottK> If we killed his computer and don't have to deal with it, that's a form of win too.
<ScottK> ;-)
<cnd> heh
<cnd> any luck?
<dart> hello, I downgraded xorg server and the problem seems to have gone but I need more time to confirm this
<cnd> dart, is this with a trackpad?
<cnd> or a touchscreen?
<cnd> or?
<dart> I am mostly using external mouse. No touchscreen.
<cnd> dart, can you do the steps noted here: https://wiki.ubuntu.com/Multitouch/Testing/uTouchEvEmu#Debugging
<dart> There is a difference between touchpad and mouse sensitivity on my system. Its more noticeable with external mouse
<cnd> skip steps 3, 4, and 9
<cnd> and instead of looking for a touch device node, use the node for your mouse
<cnd> let me know if you need help figuring out what event node it is
<dart> ok  m doing it now
<cnd> once you have the device.prop and device.record files, upload them to the new bug you created
<dart> its /dev/input/event7 for optical mouse
<cnd> ok
<dart> how long it takes for evemu-record?
<cnd> dart, it should time out after about 10 seconds
<cnd> 10 seconds of no motion
<dart> no motion? I moved my pointer around
<cnd> yeah, move your pointer, then stop and wait 10 seconds
<dart> not sure if i did like this...should I do it again coz i moved pointer all the time
<cnd> dart, I just need a recording exhibiting the bug
<cnd> it can be 5 seconds of motion
<cnd> or it can be more
<dart> ok, one last thing...I am currently doing this with stock xorg server in natty repos and not the SRU one. That would be fine?
<cnd> yeah
<dart> ok
<dart> where are these prop and record files are stored?
<cnd> if you copy and pasted the commands, they should be saved in the directory in which you ran them
<cnd> probably your home directory
<ScottK> cnd: Should he do it against with the xserver from -updates?
<dart> ok got them
<cnd> ScottK, we are recording events from the kernel, so it doesn't matter what the x server is
<ScottK> Ah.  OK.
<cnd> dart, which bug have you created for this issue?
<dart> I have yet to create...its 3 am here I am a bit slow in doing things : )
<cnd> ahh
<cnd> np
<cnd> dart, when you create the bug, please subscribe me
<cnd> my launchpad id is chasedouglas
<dart> ok
<cnd> in fact, instead of subscribing just assign it to me
<cnd> I have to go to an appointment now, but I'll be back later to check on things
<cnd> thanks!
<dart> in apport  should i select this -->  the problem started after system software update or I don't know would be fine
<ScottK> Either is fine, but after update would be better.
<dart> ok thanks
<dart> all right done -- Bug #791596
<ubottu> Launchpad bug 791596 in xorg-server (Ubuntu) "Odd Pinter Behavior After Recent Xerver SRU in Natty" [Undecided,New] https://launchpad.net/bugs/791596
<dart> ScottK, Plz check bug. Do I need to add some more information?
<RAOF> dart: I've assigned that bug to cnd as he asked; he's got the most insight into X input behaviour.  You should probably attach /var/log/apt/term.log to the bug as well, but it looks like you've got all the info cnd asked for.
<nemo> Hey guys, I ran into a ubuntu forum article that fixed suspend/hibernate on my Sony VPC-F11 - is there an ubuntu wiki page where I can check to see if this problem is reported?
<nemo> I'd just like to make sure it gets picked up for future releases.  Fix from forums was adding acpi_sleep=nonvs to boot params
<nemo> Other issue was it was totem (not mplayer) having a black screen until I set output to No Xv in gstreamer
<nemo> Oh, and it seems helpless to pick up the built in microphone, but since I haven't found a fix for that yet, no point in reporting it anywhere
<RAOF> nemo: For the suspend issue you'd be wanting to check the bugs against the kernel on lanchupad.net.
<nemo> RAOF: I was hoping there was maybe some laptop compatibility database I could just dump these issues in :)
<nemo> but 'k. I'll stick with "check for existing bugs and report as necessary"
<RAOF> I'm not sure why you'd think that just because you can't fix it you shouldn't report it!  Launchpad is full of bugs that people reported but couldn't fix :)
<nemo> RAOF: 'cause I was hoping to add to some list of known fixes - I certainly do report bugs I don't know how to fix on launchpad
<RAOF> There's an ad-hoc collection of pages on wiki.ubuntu.com.  There's also an effort to get more structured reporting happening, but I'm not sure where that is :)
<nemo> I'm playing around with /usr/share/doc/alsa-base/driver/HD-Audio-Models.txt.gz hoping I can find a magic profile that fixes the mic
<nemo> RAOF: ah, yeah. that's what I'd more be looking for. something like the Linux on Laptops writeups, but more rigorous and ubuntu version focused
<dart> RAOF, I have attached term.log
#ubuntu-devel 2011-06-02
<RAOF> dart: Excellent, thanks.
<astraljava> RAOF: Perhaps you were thinking of this: https://wiki.ubuntu.com/UbuntuFriendly ?
<nemo> Is it ever appropriate to just file a generic compatibility bug for this laptop model and detail the issues and workarounds?
<nemo> astraljava: hm. that looks interesting, but doesn't really have a way to submit test data :)
<nemo> looks like more an evang operation
<astraljava> nemo: Maybe. I thought this to be interesting, though: https://blueprints.launchpad.net/certify-planning/+spec/cert-o-community-testing
<RAOF> nemo: No, not really.  In an ideal world, a bug is a single actionable defect in the software.  âSome stuff on this laptop isn't workingâ should be a single bug iff it's got a single cause (although you obviously can't actually tell until you've fixed it âº).
<nemo> RAOF: ah.  Mozilla's process is a bit more flexible. they have tracking bugs for various initiatives and whatnot
<nemo> big ol' bug hierarchies
<nemo> but 'k. guess what I'd be looking for is more some sort of Ubuntu on Laptops where I could fill in an entry for my laptop model - much like Wine has a software database where success can be filled out
<RAOF> Yeah.  Launchpad doesn't support bug hierarchies in that way, so we don't use them :)
<broder> nemo: i think that's what Ubuntu Friendly is supposed to be working towards
<broder> though possibly with a little more rigor around what "working" and "not working" mean
<nemo> launchpad is annoying in quite a few ways.  one that bugs me most, is no id for each comment, so I can't link to a comment in context
<broder> that's not true
<RAOF> nemo: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/774938/comments/4
<ubottu> Ubuntu bug 774938 in xorg-server (Ubuntu) "Erratic cursor movement when using "Coordinate Transformation Matrix"" [Medium,Fix released]
<nemo> RAOF: right. that's the annoying bit
<nemo> you can link to a specific comment
<nemo> but if you want to see it relative to the comments around it, you have to scroll through the list
<nemo> there is no <div id="comment54323"> as virtually every other blog and bug db out there has
<nemo> so even if I look at the HTML I can't make a #comment54323 link
<RAOF> Ah, yeah.  That makes sense.
<nemo> of course it really should have an anchor for that purpose
<nemo> oh well. has been that way for years, and I think I did complain in a bug once, so isn't likely it'll be fixed any time soon
<nemo> broder: well. thanks for the link. I'll keep an eye on that page, and if it ever gets to the point where it accepts user submissions, I'll post my laptops :)
<nemo> aaand, guess I'll stick w/ issue-specific bugs for now
<cnd> RAOF, bryce, slangasek: I can't reproduce the bug in xorg-server, and it's a fairly simple traditional mouse
<slangasek> ok
<cnd> since there are no other reports, I'm inclined to think something is awry with his particular setup somehow
<cnd> I've asked for some more data in the bug
<slangasek> maybe he should try the upgrade again?
<cnd> I asked him to upgrade, then play back his own recording
<cnd> see if it reproduces
 * slangasek nods
<cnd> it could be something simple like dying batteries :)
<slangasek> cnd: thanks; please keep us posted, but I'm not going to take any precipitous action wrt the published SRU at this point
<cnd> I am off tomorrow :(
<cnd> but I'll try to monitor it
<slangasek> is there someone else who can take it over from you?
<cnd> I would say anyone of the top dogs of ubuntu-x would be best equipped
<cnd> tjaalton, bryce, or RAOF
<cnd> it's not multitouch related, so it's not really in the realm of anyone else on the touch team
<cnd> forgot about Sarvatt :)
<RAOF> Ok.  I'll monitor it today and pass off to bryce or tjaalton in the evening.
<RAOF> cnd: Have a good day off tomorrow!
<cnd> RAOF, thanks!
<tjaalton> actually, I'm off for the rest of the week ;)
<cnd> tjaalton, then have fun too!
<tjaalton> but yeah, sounds like a dead battery or such
<tjaalton> cnd: thx!
<bryce> ok
<slangasek> hallyn: closing bug #773891 as invalid; you don't appear to be subscribed, so thought I'd let you know
<ubottu> Launchpad bug 773891 in libaio (Ubuntu) "package libaio-dev (not installed) failed to install/upgrade: trying to overwrite '/usr/include/libaio.h', which is also in package libaio:i386 0.3.104-1" [High,Invalid] https://launchpad.net/bugs/773891
<hallyn> slangasek: drat, i thought i'd subscribed by habit.  Thanks much!
<hallyn> looks like i need to look at a multi-ach converted library so I know what to look for
<broder> https://wiki.ubuntu.com/UbuntuEmail
<broder> err, wrong window
<sivan> hi all
<sivan> Is there anybody from the Montreal office?
<sivan> *here
<lifeless> kees: hi
<lifeless> hmm perhaps too late for you
<lifeless> micahg: I seem to recall you're in the security team ?
<micahg> lifeless: yes
<lifeless> micahg: oh cool
<lifeless> micahg: bug 791652 may interest or terrify you
<ubottu> Error: Launchpad bug 791652 could not be found
<micahg> lifeless: fun :)
<micahg> lifeless: are you sure that /tmp isn't in $PATH?
<lifeless> /home/robertc/local/bin:/home/robertc/bin:/home/robertc/local/bin:/home/robertc/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
<lifeless> micahg: its not there in the environment I run from for sure
<lifeless>  set | grep LD
<lifeless> $
<micahg> lifeless: BTW, I failed to note it was private until after I posted the first reply to you, I guess I'm not used to the bar on top yet :-/
<lifeless> hmm
<lifeless> :(
<micahg> the benefit on the bar on the side was that you could see it all the way down the page, my eyes went straight to the description
<lifeless> thats worth noting on the bug I think
<lifeless> micahg: found it
<micahg> lifeless: the solution to your problem?
<lifeless> no
<lifeless> the utterly insane code.
<micahg> ah, cool
<lifeless> https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/791652/comments/2
<ubottu> Error: Launchpad(https://launchpad.net) bug 791652 not found
<lifeless> I expect at least an OMFG in about 5 seconds
<micahg> lol
<ScottK> This bug not found thing.  I've hit it before, but never when I had a chance to investigate at all.
<micahg> ScottK: it's a private bug
<lifeless> ScottK: security / private bugs
<lifeless> ScottK: also bug numbers we don't allocate
<lifeless> which happens if a file-a-bug transaction rollsback
<ScottK> I see.
<ScottK> So maybe mine was something different.
<lifeless> anyhoo
<lifeless> having found that, I'm off to do something completely different :)
<StevenK> ScottK: 403 and 401 both give the idea that something is there, but you can't see it. 404 doesn't.
<ScottK> Right.  In the case I had I got bugmail that said I'd been mailed because I was subscribed to a duplicate bug.  Then when I went to the primary bug and clicked on the named dup, I got the 404 reply.
<StevenK> Right, that is a bug
<lifeless> no
<lifeless> its deliberate
<ScottK> Ah.  So I'm trapped in bugmail hell forever?
<StevenK> We shouldn't say "Duplicate of private bug" ?
<lifeless> oh
<lifeless> let me rephrase
<ScottK> The primary bug wasn't private.
<lifeless> the 404 is deliberate
<lifeless> the behavior of apport duping bugs onto a private bug is a bug
<lifeless> and launchpad permitting that is also a bug
<ScottK> Agreed.
<ScottK> This wasn't that case.
<lifeless> let me get some references
<lifeless> well, dups across privacy boundaries are problematic
<StevenK> Agreed
<lifeless> ScottK: we shouldn't be linkifying those dupes now, and arguably we shouldn't even show them to you if you can't see them
<lifeless> we kindof have to when bug A that you can see is a dup of bug B that you cannot see.
<ScottK> Right, but I could see the primary and was subscribed to the dupe.
<lifeless> ScottK: then you should have been able to see the dupe
<ScottK> Agreed.
<lifeless> ScottK: so something else happens
<ScottK> That's why I think it was a bug.
<lifeless> maybe someone unsubscribed you from the dupe between you looking at the master and clicking on the link
<ScottK> Possible in theory, but highly unlikely I think.
<lifeless> anyhow, bugs in this sort of space - bug 764414 bug 434733 bug 136570 bug 262280
<ubottu> Launchpad bug 764414 in apport (Ubuntu) "private master bugs are confusing and lead to more duplicate filings" [Wishlist,Triaged] https://launchpad.net/bugs/764414
<ubottu> Launchpad bug 434733 in Launchpad itself "marking public bug as duplicate of private bug leads to confusing UI" [High,Triaged] https://launchpad.net/bugs/434733
<ubottu> Launchpad bug 136570 in Launchpad itself "bug mail explaining cause of message has an inaccessible link when the the master is private and the subscription is is via duplicates" [Medium,Triaged] https://launchpad.net/bugs/136570
<ubottu> Launchpad bug 262280 in Launchpad itself "forbidden error trying to unduplicate a public bug from a private one" [Low,Triaged] https://launchpad.net/bugs/262280
<lifeless> I realise these don't match your exact situation
<ScottK> I may have to just apply my Rosetta mail policy to bug mail.  I'm getting a bit tired of stuff I can't keep out of my inbox.
<lifeless> ScottK: are you in the new bug mail beta ?
<ScottK> lifeless: I'm not.
<lifeless> ah
<lifeless> well it should be live in a few days
<ScottK> Does it deal with the case when I'm subscribed to a bug due to a team and I want to make the mail from that bug stop without affecting other team members?
<ScottK> That's the one I primarily need.
<lifeless> yes
<lifeless> you click on 'mute'
<StevenK> ScottK: Did you see jml's lightning talk at UDS?
<ScottK> I saw about half of it.
<StevenK> ScottK: I'd suggest re-watching it, it explains the new bug subscription stuff quite well.
<ScottK> Well I think lifeless answered my immediate question.  If it can do that it's at least an 80% solution for me.
<broder> hmph. dch changes broke backportpackage. bdrung, i'm blaming you :-P
<broder> ah, he fixed it already, my daily builds are just a few days behind. carry on :)
<kees> lifeless: gee, that's delightful. upstream silently fixed it in 3.3.0.
<lifeless> woo
<syn-ack> you the same lifeless from Undernet?
<lifeless> many many many years ago I was
<syn-ack> Oh, my god.
<syn-ack> lifeless, How's it goin' dude?
<lifeless> its someone else these days
<syn-ack> You're the one I thought you were.
<Sensiva> Hello, When will Karmic get moved to old-releases.ubuntu.com ? And where should I ask about that?
<didrocks> good morning
<hrw> morning
<hrw> StevenK: do I assume correctly that you are archive admin today?
<StevenK> hrw: I can be.
<StevenK> hrw: What do you need?
<hrw> StevenK: my package gcc-4.6-armel-cross is in NEW queue. I can answer any questions related to it
<hrw> StevenK: lack of it makes whole armel cross toolchain not installable (gcc 4.4/4.5 cross, binutils cross are already in archive)
<Sensiva> Does anyone know when will Karmic get moved to old-releases.ubuntu.com ? And where should I ask about that?
<StevenK> hrw: Accepted.
<hrw> thank you StevenK
<bdrung> broder: backportpackage was broken, but the newer dch reveals it. it's fixed in u-d-t trunk
<el7r> hi
<dantti_> cjwatson: hi, I'm trying to use debconf to display conffile questions in packagekit, but subst() does not allow newlines (so I can show a diff), is there any other command that I can use to set the extended description?
<ScottK> dantti_: cjwatson is on holiday this week.
<dantti_> ScottK: k, thanks :)
<jdstrand> hallyn: hi! I haven't forgotten about libvirt-- though am I right in remembering that you wanted to supply a new package? anyway, I have another question: do you have any scripts for testing qemu-kvm?
<hallyn> no i don't.  i (or someone) need to get the kvm autotests going
<hallyn> it always gets stalled on not having dedicated hw for it
<jdstrand> hallyn: fyi, I came across this: http://wiki.qemu.org/Planning/0.14/Testing
<hallyn> jdstrand: i do need to redo the package, just for -v, but nothing major
<jdstrand> hallyn: don't bother then, cause I need to add a patch
<hallyn> did you get my qa-regession_test patch?
<hallyn> ok
<jdstrand> hallyn: I like your patch to qrt btw (untested). I think I'd like to make it release specific though
<jdstrand> hallyn: I'll handle that too, as I will be fiddling with the script
<hallyn> cool thx
<nemo> based on what RAOF and astraljava said yesterday, I filed bug #791898 and bug #791900
<ubottu> Launchpad bug 791898 in linux (Ubuntu) "Sony VPC-F11 (VPCF11GGX) requires acpi_sleep=nonvs for suspend/hibernate" [Undecided,New] https://launchpad.net/bugs/791898
<ubottu> Launchpad bug 791900 in Ubuntu "Sony VPC-F11 (VPCF11GGX) Totem and other gstreamer apps have a black screen unless No Xv is selected in gstreamer-properties under Video Default Output" [Undecided,New] https://launchpad.net/bugs/791900
<nemo> oh and bug #791904
<ubottu> Launchpad bug 791904 in Ubuntu "Sony VPC-F11 (VPCF11GGX) Internal microphone does not function" [Undecided,New] https://launchpad.net/bugs/791904
<nemo> the mouse problem is probably bug #771716, so I just left a comment there.
<ubottu> Launchpad bug 771716 in xserver-xorg-input-evdev (Ubuntu) "middle click emulation not working" [Undecided,New] https://launchpad.net/bugs/771716
<nemo> it'd be nice to be able to link to all 4 in some sort of laptop database though
<nemo> just so others would know what to expect with this model
<nemo> hopefully ubuntu has one, someday
<dFshadow> anyone know their way around the twitter and facebook APIs?
<dFshadow> nvm...found their dev chans on freenode
* maco changed the topic of #ubuntu-devel to: Oneiric Archive: Soft Freeze for Alpha 1 in effect | Development of Ubuntu (not support, not app development) | #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:
<maco> dapper's eol...time to take it out of the support list
<hrw> doko: sent eglibc merge request to fix armhf cross build
<hrw> have a nice rest of day people
<micahg> hi doko__ , I was wondering if you intended the libreadline5-dev rename to be a full transition to either the new package or libreadline6 depending on licensing or if you just wanted the DM/DD to fix it themselves on demand (in which case we should remove the binary libreadline5-dev so that the Provides in the new package works)
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Archive: Soft Freeze for Alpha 1 in effect | Development of Ubuntu (not support, not app development) | #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: barry
* slangasek changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: barry
<mdz> cjwatson, slangasek, kees, Keybuk, TB meeting shortly
<Keybuk> mdz: ack
<slangasek> mdz: am I on the agenda today?
<mdz> slangasek, no, my mistake, sorry
<slangasek> ok :)
<smoser> offlineimap recently broek for me in natty (i think this week sometime). I can "fix" it by invoking it with python2.6.
<soren> smoser: In Natty? Really? It works fine for me.
<soren> smoser: How does it fail?
<smoser> i'm guessing somethign recently changed /usr/bin/python -> /usr/bin/python2.7 but it seems like python-defaults is the same in oneiric as in natty
<smoser> s/natty/oneiric/ above, soren, sorry.
<soren> Ah.
<soren> Yeah, python changed.
<soren> 2.7.1->2.7.2rc1.
<soren> I have a couple of other things that broke that I haven't completely untangled yet.
<smoser> so should i open bugs against python?
<soren> Depends.
<soren> I'd probably start by filing it against offlineimap and go from there.
<smoser> well definitely something broke this week, surely that was not expected in a minor release bump
<soren> It might be depending on an implementation detail of earlier python versions. That's certainly the case in at least one of the places where I've seen breakage.
<smoser> fair.
<soren> smoser: Do you have a traceback?
<smoser> no.. offlineimap catches them for me :)
<smoser> and gives error messages. but its easily recreatable. i've just not dug at all until now.
<ScottK> smoser: File a bug and ping barry.
<barry> hi smoser.  we'd definitely like to track those problems down asap.  if they are related to upstream 2.7.2 we have about a week to address them before 2.7.2 final (currently scheduled for 11-june)
<smoser> nice. i just noticed my apport windows says I "Upgraded to oneiric on 2010-11-15 (198 days ago)"
<smoser> barry, bug coming.
<soren> barry: I have one for you.
<soren> barry: bug 791221
<ubottu> Launchpad bug 791221 in python-mox (Ubuntu) "Test suite fails with python 2.7.2rc1" [Undecided,New] https://launchpad.net/bugs/791221
<barry> smoser, soren cool.  i'm patch piloting today so it's perfect timing :)  let me finish this upload and i'll take a look
<micahg> smoser: that's bug 788936
<ubottu> Launchpad bug 788936 in apport (Ubuntu) "UpgradeStatus date is wrong when system is upgraded through sources.list change" [Low,Triaged] https://launchpad.net/bugs/788936
<smoser> wait...
<smoser> $  dpkg-query --show python-minimal
<smoser> python-minimal	2.7.1-0ubuntu5
<soren> What about python2.7?
<smoser> barry, bug 792043
<ubottu> Launchpad bug 792043 in offlineimap (Ubuntu) "offlineimap crashes with python 2.7" [Undecided,New] https://launchpad.net/bugs/792043
<barry> smoser: ack
<smoser> soren, why did you say '2.7.1->2.7.2rc1.' ?
<smoser> my apt-cache policy shows nothing of that sort.
<soren> It's lying to you or severely out of date.
<soren>  python2.7 | 2.7.2~rc1-2 |       oneiric | source, amd64, i386
<smoser> hm...
<soren> forget about python-minimal.
<smoser> yeah
<smoser> $ dpkg-query --show python2.7-minimal
<smoser> python2.7-minimal	2.7.2~rc1-2
<smoser> where that provides /usr/bin/python2.7
<soren> Right.
<soren> barry: Would it help if I set up a test system where you could see the failure?
<barry> soren: think that would be easier than setting up a vm to test it in?
<soren> barry: Not if you can do that easily. It's just a few steps to make it happen.
<barry> soren: okay cool.  i can do it fairly easily.  i'll ping you if i run into trouble (finishing up something else here first)
<soren> barry: On an oneiric system, do "apt-get build-dep nova; apt-get install bzr ; bzr branch lp:nova ; cd nova ; bash run_test.sh -N" and you should see it happen.
<barry> soren: cool.  i have an oneiric vm all set up that should be easy to test on
<soren> barry: Wicked. In the mean time I'll see if I can untangle this and come up with a simple test case just for this.
<barry> soren: cool
<kirkland> is the Oneiric desktop live image working for anyone inside of KVM?
<kirkland> hallyn: ^ ?
<hallyn> haven't tried
<hallyn> trying to figure out why Package.gz doesn't seem to match the contents of pool/main/
<hallyn> (presumably i'm misreading the kernel package names/versions)
<soren> hallyn: What's the (supposed) discrepancy?
<hallyn> linux-image-2.6.39-3-generic_2.6.39-3.10_i386.deb  vs pool/main/l/linux/linux-image-2.6.38-9-generic_2.6.38-9.43_i386.deb
<hallyn> i'm sure i'm looking at the wrong thing, somewhere
<soren> linux-image-2.6.39-3-generic_2.6.39-3.10_i386.deb is oneiric. pool/main/l/linux/linux-image-2.6.38-9-generic_2.6.38-9.43_i386.deb is natty
<hallyn> doh!
<hallyn> i forgot about oneiric :)  thanks
<barry> soren: this entry in 2.7's Misc/NEWS file looks suspicious.  there's no bug number so i need to track this down to find out exactly what changed:
<barry> - Correct lookup of __dir__ on objects. Among other things, this causes errors
<barry>   besides AttributeError found on lookup to be propagated.
<barry>  
<soren> barry: Yep, found that too.
<soren> barry: It looks intentional, so I sort of got the impression it was more of a bugfix than anything else.
<barry> soren: then, bad python developer!  you didn't include a issue #!
 * barry -> #python-dev
<hallyn> kirkland: firing off testdrive
<kirkland> hallyn: i tried cirrus, vga, and vmware
<kirkland> hallyn: cirrus is completely broken
<kirkland> hallyn: sorry, ubuntu desktop is completely broken on cirrus
<kirkland> hallyn: gets slightly further with std and vmware
<kirkland> hallyn: but still not functional
<kirkland> hallyn: i suspect its unity 2d issues
<micahg> kirkland: unity2d should work with vga
<micahg> at least it does in natty
<kirkland> micahg: right, i'm talking oneiric
<soren> barry: http://paste.ubuntu.com/617043/ reproduces it
<ScottK> soren: Is rpc.CnnsumerSet in line 10 a typo?
<ScottK> Cnn/Con maybe?
<soren> ScottK: Sorry, yes. But that's not the problem :)
<soren> Hang on, I have a better test.
<ScottK> Sure.  Just wanted to make sure the test case was good.
<soren> ScottK: Thanks :)
<soren> There:
<soren> http://paste.ubuntu.com/617048/
<soren> A completely novaless test case.
<soren> pymox makes my head spin.
<soren> If I add a __dir__ method to the MockAnything class (simply returning an empty list), everything is fine.
<soren> barry: ^
<soren> barry: Again, I just don't have the expertise to say if pymox is depending on cpython specifics or if this is a bug introduced in Python 2.7.2.
<barry> soren: don't worry.  just update the lp bug with what you know and i'll track it down in pythonland
<soren> *hugs*
<barry> :)
<soren> barry: Updated the bug on Launchpad and on Google Code with the test case.
<barry> soren: thanks!
<soren> barry: Oh, thank *you*!
<jdstrand> hallyn: fyi, I am working on a test-qemu.py qrt script. I should have something to check in tomorrow
<jdstrand> hallyn: it isn't complete, but is a good start
<TheMuso> barry: Are you still piloting?
<hallyn> jdstrand: awesome
<barry> TheMuso: i'm about to get some dinner, but if there's something easy you need i can help out afterward
<TheMuso> barry: No thats fine, I was looking to start my shift, just wanted to make sure we didn't clash.
<TheMuso> on items in the queue.
<barry> TheMuso: ah, nope, in fact i'll pilot out now
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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:
<maco> i have something easy if one of you want to sponsor an sru upload
<TheMuso> Ok thanks.
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: TheMuso
<TheMuso> maco: I'm on duty now so shute.
<TheMuso> shoot even
<maco> https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/790960/+attachment/2149841/+files/lintian_2.4.3ubuntu3.debdiff    debdiff for lintian in maverick so debuild -S on maverick for a package-to-be-uploaded-to-oneiric doesn't bomb out on lintian not knowing what the hell oneiric is
<ubottu> Ubuntu bug 790960 in lintian (Ubuntu) "Maverick's lintian doesn't know about oneiric in changelogs" [Undecided,Triaged]
<TheMuso> maco: Thanks, will look at it now.
<maco> thank you
<TheMuso> maco: You haven't filled out the paperwork? i.e updated the bug with rationale, possible regression potential etc in the bug for SRU purposes?
<micahg> TheMuso: can you ack the packagekit sync?
<TheMuso> I don't doubt that the change is small and minor, but I'd say the upload will be rejected without that info.
<TheMuso> micahg: Next in line.
<micahg> TheMuso: thanks
<TheMuso> maco: And the version should probably be ubuntu2.1 as well/
<maco> TheMuso: the lintians in natty & oneiric are a different upstream version, so it cant clash with anything anyway
<maco> (filled in the SRU points now too)
<TheMuso> maco: Fair enough re version.
<TheMuso> maco: Ok looks good to me, will test build and upload if all looks good.
<maco> k thanks
<micahg> TheMuso: maco; that version is already in the archive, please use 2.1
<maco> micahg: it is? rmadison says 2.4.3 is only in maverick
<micahg> maco: https://launchpad.net/ubuntu/+source/lintian/2.4.3ubuntu3
<maco> well and lucid backports with ~lucid1
<micahg> maco: it's not just what's in there currently, but everything
<TheMuso> micahg: Good catch, I was about to check that myself but you beat me.
<maco> doh. ok.
<TheMuso> maco: Nvm will change locally.
<maco> TheMuso: want me to re-gen, or want to just change it?
<maco> ok
<TheMuso> Don't worry about another diff.
<maco> that was already the second diff. first one didnt have "-proposed"  .... and this is why im not a core-dev
<TheMuso> Whenever I deal with SRUs, I stic to a hard and fast .1 version rule, usually safest.
<maco> this either means i need to do more SRUs (for practice) or fewer SRUs (so i mess up less) :P
<TheMuso> maco: Uploaded, thanks for your work.
<maco> thanks luke
<TheMuso> micahg: Is the packagekit sync in the sponsors queue? If so, I'll dig it out from there.
<TheMuso> seems so
<TheMuso> i.e packagekit sync in queue./
<micahg> TheMuso: yeah, I did a test build and verified the changes, but am not core-dev
<TheMuso> micahg: np wilp verify myself to be sure.
<TheMuso> will
<micahg> TheMuso: of course :)
<slangasek> TheMuso, maco: the security team has some guidance on SRU versioning, linked from the SRU wiki page: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging
<TheMuso> micahg: Just noticed something in the debian changelog for packagekit, something to do with depending on xulrunner or firefox. Is that likely to break anything for us if we take that wholesale?
<micahg> TheMuso: it should be an alternate depends (which is needed for the browser plugin) (xulrunner-dev | firefox-dev)
<TheMuso> Ok will check that once test built.
<micahg> it works since only firefox-dev is in main
<micahg> although, now that I think about it, I think that invalidates my test :-/
#ubuntu-devel 2011-06-03
<dennis_> hi at all
<dennis_> i have a programming problem in c++
<dennis_> someone can help me?
<dennis_> ?
<micahg> TheMuso: sure enough fails in sbuild since the default resolver can't handle the alternate build-dep
<TheMuso> Right.
 * TheMuso only uses sbuild so would have probably caught that sooner or later anyway.
<TheMuso> dennis_: You are probably best asking in #ubuntu-app-devel if its for an app you are writing on Ubuntu. Otherwise I am pretty sure there are channels dedicated to c/c++ on freenode where you could ask your question.
<micahg> TheMuso: so, in theory it should work in LP, but I should probably verify that (the last upload had the change, but that was before xulrunner dropped to universe)
<TheMuso> micahg: Ok, well I am running it in sbuild now and it is currently building.
<TheMuso> 8/c
<TheMuso> I'll try installing in a oneiric chroot and see what happens.
<micahg> TheMuso: orly?  did you limit the component to main only?
<TheMuso> micahg: No.
<micahg> TheMuso: then it's not a good test
<TheMuso> Probably shoudl have.
<TheMuso> yup just realised that.
<TheMuso> micahg: Yeah ok it does fail.
<TheMuso> micahg: So it seems this is a merge after all.
<micahg> TheMuso: idk, in theory it should work in LP, I'll ask wgrant a bit later
<RAOF> wgrant: Are you subscribed to bug 791596 because you are affected by it?
<ubottu> Launchpad bug 791596 in xorg-server (Ubuntu Natty) "Odd Pointer Behavior After Recent Xserver SRU in Natty" [Critical,Confirmed] https://launchpad.net/bugs/791596
<wgrant> micahg: What's up?
<micahg> ah, will xulrunner-dev | firefox-dev DTRT in oneiric main (only firefox-dev in main)
<wgrant> RAOF: I thought I was, but now I'm not so sure.
<wgrant> RAOF: Since I'm using xorg-edgers, so I should have had the patch for a month.
<wgrant> RAOF: But when I rebooted yesterday for the first time in a couple of weeks, my cursor started going strange in the bottom right corner of the screen.
<wgrant> Doesn't seem to be hardware.
<RAOF> And you're still using edgers?
<wgrant> Yes.
<wgrant> There it goes again.
<RAOF> Hm, that makes you a less than perfect test subject.
 * TheMuso moves onto something else for the moment.
<wgrant> Indeed.
<wgrant> So I just subscribed to see how it progressed.
<wgrant> It may be entirely unrelated.
<RAOF> Would you like to try an X server without that patch, for science?
<micahg> wgrant: did you see my question above about the alternate build-deps?
<wgrant> micahg: I did, but got distracted, sorry (on a call).
<wgrant> micahg: That should work OK.
<wgrant> micahg: I think.
<wgrant> micahg: What doesn't work well is when the first is versioned, and the package is there but the version is wrong.
<TheMuso> wgrant: Failed in a local sbuild with main/restricted enabled only.
<micahg> wgrant: oh, sorry, right I have an open bug for the versioned build-deps
<micahg> TheMuso: are you on natty?
<TheMuso> micahg: Yes, but I was building in a oneiric chroot.
<wgrant> TheMuso: Huh.
<micahg> TheMuso: right, I think sbuild in oneiric might fix it
<wgrant> TheMuso: Which resolver is sbuild using?
<TheMuso> The default.
<TheMuso> wgrant: ^^
<micahg> which is internal on natty
<wgrant> Ah.
<wgrant> Possibly not, then.
<micahg> the version in oneiric now uses the apt resolver which I think will work
<TheMuso> Yes but what are the buildds using?
<micahg> wgrant: is there any way to test what LP will do aside from an archive upload?
<wgrant> micahg: You could configure a PPA to use components, and try there. But otherwise not really.
<micahg> wgrant: k, thanks
<micahg> we'll find out soon
<TheMuso> Ok.
<micahg> Unpacking firefox-dev (from .../firefox-dev_5.0~b2+build1+nobinonly-0ubuntu2_i386.deb) ... \o/
<maco> slangasek: i know they do, but i also thought since it was for avoiding collisions and i didnt see a reference to that version in rmadison, it didnt really matter in this case. didnt think about previous versions
<TheMuso> micahg: Is https://code.launchpad.net/~dev-nigelj/ubuntu/oneiric/zabbix/721707-v2/+merge/61855 on your radar, or should I go ahead and look at it?
<micahg> TheMuso: it's on my radar, but if you're out of things to do, feel free to do it
<TheMuso> micahg: there is plenty more in the queue, so I will leave for now, thanks.
<micahg> TheMuso: https://launchpad.net/~micahg/+archive/ftbfs-test/+build/2543125
 * micahg adds to sync request
<TheMuso> micahg: thanks
<TheMuso> micahg: ACKed, thanks.
<micahg> TheMuso: cool, thanks
<chrisccoulson> is there anyone around who can accept these binaries for me: https://launchpad.net/ubuntu/+source/thunderbird/5.0~b1+build2+nobinonly-0ubuntu1/+build/2543042 ? :)
<chrisccoulson> i can reward with beer....
<RAOF> wgrant: Would you be willing to try https://edge.launchpad.net/~raof/+archive/aubergine/+packages ? I can't see how thta patch could be causing this problemâ½
<wgrant> RAOF: I guess I should run with natty-updates' xserver-xorg-core for a couple of hours first, since it's not easily reproducible.
<RAOF> That would be better, yes.
<broder> TheMuso: you saw that there are two branches you'll need to grab for the mediatomb merge, right?
<TheMuso> broder: Yes, got them both.
<broder> (and thanks for dealing with it - I just hadn't found the time to pull everything together yet)
<TheMuso> broder: Actually used your branch as a base.
<broder> ah, cool
<TheMuso> broder: Np, kind of a pain that it was accross 2 branches, for packaging it makes more work IMO.
<TheMuso> Code, I can accept, multiple branches for different fixes, but packaging... Well Not decided yet, but it certainly took more time to unravel everything.
<micahg> that package actually needs a merge as well, I've been meaning to do it
<micahg> but if the patches work, that's fine, run with it
<TheMuso> I wasn't even aware that it needed a merge.
<micahg> I missed it last cycle
<micahg> it needs porting to mozjs185 which is why I've been pushing it off, it should work though with xulrunner-1.9.2 while it's still in the archive
<TheMuso> ah.
<TheMuso> I don't envy you guys working on browser stuff. My head aches enough from having to tackle audio.
<micahg> TheMuso: I'd rather tackle browsers than audio ;)
<TheMuso> heh
<TheMuso> The biggest headache is the tons of hardware, and manufacturers liking to cut corners/not do things right in their BIOS/allow bugs to creap into their chipsets.
<TheMuso> Although accessibility presents its own headaches sometimes as well.
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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:
<broder> TheMuso: fyi, giving a branch an "approved" review doesn't remove it from the queue
<broder> but changing the status at the top of the page to "merged" would :)
<TheMuso> broder: oh right thanks.
<TheMuso> I have dealt with so many branches today, my head hurts.
<poolie> TheMuso: hi, could/did you file a bug against lp about that zope error?
<smartass> Can anyone here give me some background on how the OS will handle mouse coordinates when multiple monitors are setup?
<smartass> Will the mouse move to the 2nd screen if I send coordinates for example 35000 to the OS?
<RAOF> You're after X protocol documentation here.
<RAOF> And the answer is âit dependsâ :)
<smartass> I tried to find something useful but without much success
<RAOF> Well, it depends on what you're actually trying to do.  I'm off for lunch now, and this isn't really the place for X protocol discussions.  #ubuntu-app-devel might be better, or #xorg-devel.  âapropos pointerâ will give you a reference to âXWarpPointer (3)     - move pointerâ, which is the documentation you probably want to start with.
<TheMuso> poolie: Not yet, what project should I file it against?
<TheMuso> Sorry, was away for a shortish break.
<smartass> What I need to know is how the coordinates are managed when multiple monitors are setup. My utility needs to manage multiple touchscreens so that if you touch touchscreen1 the touch should be displayed on the monitor being setup. Thanks anyway, I'll give the other rooms a shot and I need to do this for mac as well.
<poolie> TheMuso: if you get an oops or zope error pushing to launchpad, file against lp
<TheMuso> poolie: ok thanks.
<poolie> ta
<StevenK> hrw: Can you please STOP including ddeb's in your armel-cross packages?
<slangasek> StevenK: they're not meant to get included, but if we want them to be produced at all it takes fiddly handling in the rules because of the nested package builds involved...  what's broken this time?
<StevenK> slangasek: They get included and then process-accepted blows up
<slangasek> which source package is including them?
<StevenK> gcc-4.6-armel-cross
<StevenK> I rejected the two binaries from accepted so process-accepted would start working again.
<slangasek> ah - if this hadn't been a NEW package, wouldn't they have been rejected straightaway?  That's what I recall seeing before
<StevenK> slangasek: But they weren't in the NEW queue, they were in the ACCEPTED queue
<slangasek> yes, because I accepted them out of NEW, not noticing the .ddeb issue... :)
<StevenK> Ah ha
<slangasek> StevenK: while you're here... do you know why ggz-client-libs in Ubuntu has a patch from you from 2008 that's never been forwarded to Debian? :)
<StevenK> You know, 2008 was a long time ago ... :-)
 * slangasek can't figure out what the patch is for, and it's the only delta
<StevenK> slangasek: However, ggz-client-libs hasn't been touched in Debian since at least then anyway :-)
<slangasek> yes, it's been NMUed
<StevenK> I think it fixes an install failure, but the patch is obtuse.
<StevenK> Oh! I think it's a build failure, since it wanted to write to /?
<slangasek> hmm, but the NMU built fine in Debian without this patch
<slangasek> If the Debian package builds in oneiric, should I sync it?
<StevenK> If it builds and install on oneirc, yes, do so.
<dholbach> good morning
<ara> Hello! Do we know when we will have daily Oneiric images?
<seb128> ara, hey, not sure I guess they should be on from now on but cjwatson and pitti are off since before a1 so maybe check with them next week
<ara> seb128, sure, I will, thanks seb
<seb128> ara, yw
<hrw> StevenK: sorry. will not happen again
<dholbach> can somebody review my ubuntu-packaging-guide mp? http://pad.lv/mps/ubuntu-packaging-guide
<Laney> noooooooooooooo I hate that division
<dholbach> Laney, can you elaborate?
<dholbach> if you have a better idea how to make scanning the list of topics easier, I'm all ears
<Laney> all of that stuff should be integrated into the main document(s) IMHO
<Laney> rather than having a big division: "traditional" and "UDD"
<dholbach> there's no "traditional" in there
<dholbach> the task-based articles on the front page all contain UDD bits that are relevant to them
<dholbach> the articles in the knowledge base dive deeper into the topics
<dholbach> I think there's value in short task-based articles that give new contributors a result, even if they don't work in 100% of the cases or might need some other tool that they can find out about in the knowledge base
<dholbach> Laney, would you agree that the list of knowledge base articles is a bit hard to read and it might get worse over time and that we should start categorising things?
<dholbach> I personally could imagine that renaming "UDD" on that page to "Development Tools" (or some such) could do a bit to avoid confusion about "UDD vs. traditional techniques"
<Laney> ah I thought there was 'traditional' in there â my bad (and yes, I like the task based approach)
<Laney> I think that UDD should be renamed indeed, because it reinforces (or at least opens the door to) the division
<Laney> Development Processes or something
<Laney> but it /is/ interesting that we'll not be training people in how to use the traditional tools
<Laney> how do they give back to Debian then? :-)
<dholbach> there's an article in progress about working with Debian and other upstreams
<dholbach> I think mok0 is working on it
<dholbach> Development Processes might work
<dholbach> I'll update the mp
<dholbach> we can still change it to something cleverer later on
<Laney> 'tis probably more than one article but I guess we could give a short intro 'how to build your package for Debian' or something and then link to the Debian packaging guide
<Laney> and apologies for my confusion
<dholbach> don't worry - I assume a lack of caffeine ;-)
<Laney> not consumed enough kola cubes yet
<dholbach> ok, updated the branch
<Laney> looks good
<dholbach> thanks
<ScottK> dholbach: I don't see the mp anymore, so I can't comment on the specifics, but based on the discussion here, I am concerned.  I don't think the UDD based toolset is mature enough yet to be 'the way we do things'.  If that's all that's covered in the new packaging guide, it shouldn't be called a packaging guide and it doesn't cover the normal tools for doing so.
<dholbach> The mp was more about restructuring the listing of articles
<showard> Hi - don't want to be impatient, but just want to make sure bug #755641 has not slipped through the cracks
<ubottu> Launchpad bug 755641 in sandboxgamemaker (Ubuntu Natty) "[SRU] package sandboxgamemaker 2.6.1 dfsg-3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 9" [Undecided,New] https://launchpad.net/bugs/755641
<showard> I need an archive admin to approve the upload to -proposed. Duplicates are reported daily for it.
<ScottK> showard: Before an archive admin can approve it, someone from ubuntu-sru has to say it's OK for -proposed.
<ScottK> dholbach: OK.  Where can I find the current document?
<hyperair> any technical-board member here?
 * hyperair wrote a microrelease exception addition request (for banshee), but it looks like it's stuck in the moderation queue.
<tumbleweed> ScottK: http://people.canonical.com/~dholbach/packaging-guide/html/
<ScottK> tumbleweed: Thanks.
<ScottK> hyperair: Almost certainly.  I'd suggest either email to their list or just ask your question.
<hyperair> ScottK: that's exactly what i did.
<ScottK> OK.
<ScottK> There's TB members on vacation so I imagine it might take a bit longer than usual.
<ScottK> dholbach: Where do I file bugs about the guide?
<tumbleweed> ScottK: as I appear to be the day's caching dholbach-proxy: lp:ubuntu-packaging-guide
<ScottK> tumbleweed: Thanks.
<dholbach> thanks tumbleweed
<dholbach> I hope it's not perceived as "my guide" - it will move to a more official home soon enough
<hyperair> ScottK: alright, thanks for the information.
<ScottK> dholbach: I think it needs to be clarified what it is before it moves anywhere more official. (just mailed ubuntu-devel and the udd list to discuss)
<showard> ScottK: thanks for clarifying
<ScottK> showard: It turns out most ubuntu-sru memebers are also archive admins, so the distinction is a subtle one.
<Laney> It's difficult. Having both workflows would probably be confusing. Having traditional-only would require a rewrite when we decide to advocate UDD (which is supposed to be The Future), and having UDD only means you promote an immature toolset.
<ScottK> Laney: I think renaming it is the best plan.
<ScottK> Laney: But you need to cover traditional stuff anyway or you're stuck as soon as you hit an out of date branch.
<Laney> part of the idea was to replace the out of date wiki mess though
<ScottK> Right.  I think better docs for UDD is a good and important thing, but to represent it as the Ubuntu way is getting ahead of things.
<apw> is there any documentation on how one handles source 3.0 (quilt) when commiting with bzr, particularly how to maintain the .pc poop
<ScottK> apw: I think barry gave a link on ubuntu-devel in the thread on this subject.
<barry> apw: http://people.canonical.com/~dholbach/packaging-guide/html/udd-patchsys.html
<broder> apw: as long as you're not trying to merge, i think the answer is mostly "do a quilt push -a before you commit and bzr add all of the .pc poop"
<apw> broder, i am trying to merge
 * apw whines about the importer pulling in .pc, stupid
<broder> i feel like i've heard cjwatson mention a flow where he quilt pops, then merges the unpatched trees, but i forget how he said he did that...
 * mdeslaur learns about bzr loom for the first time
<barry> one key thing i've learned is that you basically want to bzr revert any changes in the .pc directory before you commit.
<mdeslaur> barry: whaaa? but...won't that break when you try and unapply quilt patches that haven't applied cleanly?
<barry> mdeslaur: i haven't seen that, but i have seen conflicts in the .pc directory after a merge, and it's pretty much worked for me to just revert those and carry on
<barry> mdeslaur: but of course, when you're talking udd+quilt, ymmv ;)
<mdeslaur> hehe
<ScottK> I think it'd be better if the importer did it with patches not applied.  It seems like that would make a whole world of pain go away.
 * barry channels maco now
<maco> hi barry
<apw> can anyone shed any light on the Architecture: linux-any appearing in a debian package, and whether we understand it
<barry> ScottK: i thought the same thing too, but jelmer (i think) had some good arguments as to why that's not the right thing to do.  i think the intent there is that people should be able to just branch and hack.
<barry> hi maco
<ScottK> barry: Yes and with the .pc issues they can't do that.
<arand> apw: Won't build for kfreebsd or hurd?
<barry> ScottK: not without pain today, true
<apw> will the ubuntu archive grok it ?
<arand> apw: That I do not know..
<barry> for me, the benefits of bzr/dvcs outweigh that pain, but not for everybody.  maco for example doesn't use udd for quilt packages.  certainly that's a reasonable strategy.
<maco> barry: i made a script the other day to fetch a source package for a given release, check if its using cdbs for patchsys, and then apply the patch, dch -i, *the only piece of user interaction happens here*, debuild -S, and create a debdiff.  that wiki page you linked is way more head-hurty than the script i handed akk to make a debdiff out of a patch she was submitting
<maco> and once that script has a --help and some error checking, i'll push it toward u-d-t
<maco> (its aimed at non-upload-rights people needing to make a debdiff to hand to a sponsor)
<barry> maco: yep, no disagreement there
<smoser> barry, stupid question...
<smoser> how do i get the python upstream 2.7 branch in hg?
<broder> apw: soyuz can deal with linux-any, afaik
<barry> smoser: i'm not sure what the url is for non-core committers.  let me see if i can find it
<broder> maco: that sounds a lot like edit-patch. have you looked at that?
<smoser> yeah, yeah, yeah, barry, you're a core committer, the rest of us are slime... :)
<barry> smoser: no, no, no.  dvcs democratizes everything :)
<barry> btw, smoser: http://docs.python.org/devguide/
<infinity> barry: Why which you mean "it creates the illusion of power with local branches until people realise they can't get them merged back into mainline without a hefty donation of cookies and kittens"?
<barry> mmm, kitten cookies, yum!
<maco> broder: nope. didnt know it existed. it's not listed in apt-cache show ubuntu-dev-tools
<broder> maco: it may slide into devscripts at some point; i haven't been following that stuff too closely
<barry> infinity: of course, you can always publish your own branches, and rant about the oppressive thumb of the establishment and its evil cabal of gatekeepers
<maco> broder: i think sponsor-patch was the closest i saw in the list at the time
<broder> maco: but edit-patch/add-patch have been around for a while. if they're not listed in the package description, a bug would probably be helpful
<tumbleweed> it's in devscripts now
<barry> smoser: http://docs.python.org/devguide/setup.html?highlight=mercurial
<infinity> barry: And rename my fork "diamondback"?
<tumbleweed> maco: add/edit-patch just does the "determine patch system, patch, generate changelog entry" bits
<maco> http://pastebin.com/gNGdjqse this is what i had
<barry> infinity: i prefer to use names from the deadly viper assassin squad, but ymmv
<tumbleweed> maco: bad link
<maco> oh expiry
<maco> http://pastebin.com/X2VAZRFV
<tumbleweed> maco: hrm, I wonder if sponsor-patch doesn't already cover that (it uses edit-patch)
<maco> can you tell it to not upload it somewhere?
<ScottK> Call maco's script sponsoree-patch.
<maco> heh
<tumbleweed> maco: yes
<maco> ScottK: bonus points if it can attach the debdiff to a bug report?
<tumbleweed> yeah, sponsor-patch is a bad name for that usecase
<broder> maco: look at what the -s option to sponsor-patch breaks down to and tweak accordingly
 * maco looks at -b and puzzles
<maco> DIST? i just have a crackload of aliases....  pbn build ../foo.dsc,  pbo build ../foo.dsc, etc.
<tumbleweed> maco: standard pbuilder config is to use DIST=natty pbuilder ...
<tumbleweed> it also supports pbuilder-dist
<Laney> ScottK: can you think of a non-confusing-to-newbies-yet-realistic-about-the-situation to present this stuff? "Ignore UDD/have it as an appendix"?
<maco> tumbleweed: huh. ok. i just have symlinks in ~ to pbuilder-dist and aliases to call those symlinks
<tumbleweed> maco: try -B pbuilder-dist then
<maco> as an argument to what command?
<maco> (i also dont have a pbuilderrc, so i dont know what this standard config is)
<tumbleweed> maco: sponsor-patch
<maco> well, /etc/ has a pbuilderrc, but it just gives a mirrorsite
<tumbleweed> maco: yeah, standard non-default config :) https://wiki.ubuntu.com/PbuilderHowto
<maco> little b you mean? manpage doesnt have a big B
<tumbleweed> hrm, it should have had it for a while now. What release are you on?
<maco> maverick
<tumbleweed> ah, yeah it may have come after that
<broder> yeah, i think that's too old - i'm pretty sure i added the -B stuff in the natty cycle
<maco> will have to try when i'm home...which is conveniently also where any source package i may have sitting around are located
<tumbleweed> unfortunatly you can't just grab the latest u-d-t trunk, because of the devscripts migration, we'd probably have to do decent backports
<broder> tumbleweed: that's been fixed, at least for natty
<broder> somebody uploaded a devscripts backport to the dailies ppa
<tumbleweed> broder: cool, that doesn't help maverick though :)
<maco> at some point i should upgrade this system
<broder> tumbleweed: there's a backport in there for maverick, too
<tumbleweed> yeah, just saw that
<maco> my team lead at work upgraded to natty because the update manager told him to. then all my coworkers told him he shouldnt have and laughed at his confusion with unity. i think the other kde user went into recruiter mode
<tumbleweed> unity seems to cause a day or two's pain for most people
<maco> i told him how to get back to gnome. he checked how much ram he had to answer the initial question he was asked, then shut down ubuntu and went back to his mac. this was the first time id ever seen his ubuntu machine turned on since i started working here in january
<tumbleweed> maco: so, when you do get home, grab u-d-t from the ~udt-developers PPA
<broder> (ppa:~udt-developers/daily)
<maco> tumbleweed: does natty's u-d-t have the thing you're saying? my dev machine at home is on natty
<Laney>  
<maco> im going to have to reinstall to get my netbook to natty. not enough space to download the packages
<tumbleweed> maco: yes it does
<maco> ok then
<smoser> barry, so my feeling right now is that offlineimap is to intrinsically familiar with IMAP_SSL.
<smoser> it has some wrappers that it uses "UsefulIMAPSSL"
<smoser> i think i have a fix in offlineimap at http://paste.ubuntu.com/617647/ (tested a bit here)
<SpamapS> broder: omg, backportpackage is amazing. :-D
<broder> :)
<broder> i was pretty happy with how it turned out, and i use it all the time now
<SpamapS> Its something I find myself doing about once a week.. debcommit.. dch .. bzr bd -S .. bzr revert ... repeat..
<broder> though you should also thank bdrung for harassing me into making it do more more than the first version i wrote
<SpamapS> bdrung: thank you for harrassing broder
<SpamapS> we couldn't do it without your harrassment
<bdrung> you're welcome. i am a happy backportpackage user too
<bdrung> only one bit is missing: backporting from debian
<bdrung> that's bug #703099
<ubottu> Launchpad bug 703099 in ubuntu-dev-tools (Ubuntu) "[backportpackage] support backporting packages from Debian" [Wishlist,New] https://launchpad.net/bugs/703099
<bdrung> broder: can i harass you to fix ^?
<broder> bdrung: yeah, probably
<bdrung> or should i ask more frequently ;)
<bdrung> ?
<broder> remind me some time this weekend
<broder> actually, remind me on sunday if you don't see an mp by then
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: bdmurray
<kees> cjwatson: I've just adjusted platform.oneiric/standard for apparmor (to drop the Perl bits). do I need to do anything beyond just committing that change?
<kees> (https://wiki.ubuntu.com/SeedManagement seems to imply I just need to commit)
<tumbleweed> bdrung: sponsor-patch doesn't seem to like DEBCHANGE_RELEASE_HEURISTIC=changelog, maybe it should use dch --release instead of --edit
<bdrung> tumbleweed: that seems to work too. feel free to change it.
<bdrung> tumbleweed: what do you think about time based releases for u-d-t?
<tumbleweed> bdrung: don't have anything against them, but I also don't think there's anything wrong with the current release rate
<tumbleweed> +  * mark-irq9-active-high-in-DSDT.patch: fix system_shutdown not working in
<tumbleweed> +  * mark-irq9-active-high-in-DSDT.patch: fix system_shutdown not working in
<tumbleweed> grr
<bdrung> tumbleweed: i was thinking about a biweekly release schedule for not critical bugs. so that we don't accumulate too many changes
<tumbleweed> that's not a bad idea
<bdrung> releasing 0.109 took to long
<bdrung> tumbleweed: second thing: a 1.0 release when all unwanted scripts are moved elsewhere
<tumbleweed> well, there were some big changes in that (which haven't actually been completed yet :/ )
<tumbleweed> persia seems to be aiming for nothing left
<bdrung> tumbleweed: that's unrealistic
<tumbleweed> I tend to agree
<bdrung> tumbleweed: on the get rid list: mk-sbuild, check-symbols, reverse-build-depends, *distro-info, bug #708886 - anything forgotten on this list?
<ubottu> Launchpad bug 708886 in ubuntu-dev-tools (Ubuntu) "move LP tools from ubuntu-dev-tools to lptools" [Wishlist,New] https://launchpad.net/bugs/708886
<tumbleweed> looks like we're about to add backportpackage to that list, if broder does something the debian backporters like
<bdrung> maybe
<smoser> cjwatson, do you have thoughts on merging rsyslog from debian ? debian is at 5.8.1-1, oneiric at 4.6.4-2ubuntu4 . 4.6.4-2 was the last of debian's 4.X.  http://paste.ubuntu.com/617682/ rsyslog Changelog since 4.6.x
<ScottK> Laney: If you want to write newbie docs, it's got to be done using the mature tools.  I think ignore UDD (for now) would be the right approach.
<broder> tumbleweed: i think backportpackage will still be more of a u-d-t than a devscript, since the end result will be ubuntu-targeted packages
<broder> hmm...though i wonder if there's anything in the script right now that would keep you from backporting with -d wheezy or similar
<ScottK> broder: You might want to talk to Rhonda about that.  Rhonda is heavily involved in Debian backports.
<tumbleweed> broder: well, for a start it wouldn't use the correct version format :)
<bdmurray> Does anybody know where https://wiki.ubuntu.com/DistributedDevelopment/Documentation/SettingUp went?
<barry> i want to do a no-change rebuild.  `dch -R -D oneiric` is almost, but not quite, right.  when the last changelog entry is this: "jinja2 (2.5.5-5) unstable; urgency=low" the next one will be this: "jinja2 (2.5.5-5build1) oneiric; urgency=low".  yes, i can manually fix that, but i'm wondering if dch has an option to use `ubuntu1` instead of `build1`
<barry>  
<barry>  
<akgraner> highvoltage, got time for a call or pm?
<barry> bdmurray: i think it mostly got rolled into http://people.canonical.com/~dholbach/packaging-guide/html/getting-set-up.html
<debfx> barry: buildX is actually right for rebuilds
<barry> debfx: ah, because autosyncs will continue?
<bdmurray> barry: and the same is probably true for the other links on https://wiki.ubuntu.com/SponsorshipProcess ?
<debfx> barry: yes
<broder> tumbleweed: sure, it would be an "ubuntu-style" backport, and not uploadable to debian, but i don't think we actually verify the destination releases
<barry> bdmurray: i think the other links will point into subpages of http://people.canonical.com/~dholbach/packaging-guide/html/knowledge-base.html
<barry> debfx: thanks
<bdmurray> barry: and if something is wrong in the packaging guide?
<barry> bdmurray: best to open a bug on lp:ubuntu-packaging-guide
<bdmurray> if it only it were a wiki page ;-)
<barry> bdmurray: :)
<jikanter> micahg: what's new bud?
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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:
<barry> james_w: ping
<james_w> hi barry
<barry> james_w: hi, hope all is well.
<barry> james_w: i'm working on getting rid of python3.1 and need to rebuild python-bsddb3, but have run into this udd error:
<barry> http://package-import.ubuntu.com/status/python-bsddb3.html#2011-05-19 20:55:56.006213
<barry> james_w: wondering, can this be manually fixed?
<james_w> barry, I'm not sure
<james_w> probably a bit late for #bzr too
<barry> james_w: yeah, that's what i was afraid of ;)
<james_w> I'm not too sure what that is trying to tell us
<james_w> I think it might be a broken branch though
<james_w> possibly due to stacking
<barry> james_w: ok, no worries.  i was hoping it might be easy, but i don't want to shave too many yaks today.
<james_w> barry, something weird seems to have happened in the history of that branch that has left some dangling tags
<james_w> I suggest you file a bug
<barry> james_w: there's already https://bugs.launchpad.net/udd/+bug/653312
<ubottu> Ubuntu bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged]
<james_w> ok
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: bdmurray
<broder> hmm..."time in sponsorship queue" is starting to creep upwards :(
<micahg> broder: that's due to UDS still, should go back now shortly
<micahg> s/now/down/
<broder> hmm, probably true
<broder> it does look like it's cresting, but it's kind of hard to tell with the resolution we have
<slangasek> nvidia-common in oneiric seems to be of an entirely different provenance than the one in natty; does anyone know if this was intentional, or if the Ubuntu version was accidentally clobbered when Debian started shipping one?
<Keybuk> I know where I'd put my money ...
<robbiew> heh
<bryceh> Sarvatt, ^ know what's up with nvidia-common?
<bryceh> slangasek, not an intentional change on our end afaik
<Sarvatt> oh yuck, no that wasn't intentional
<slangasek> bryceh, Sarvatt: ok; I think someone will need to epoch it and reupload then
<slangasek> and either put 'ubuntu' in the version number, or have the archive admins blacklist it for syncing
<bryceh> Sarvatt, sounds like a tseliot job?  Shall I send him an email about this?  Or do you want to square it away?
<bryceh> lp #792576
<ubottu> Launchpad bug 792576 in nvidia-common (Ubuntu) "nvidia-common in debian is different than nvidia-common in ubuntu" [Undecided,New] https://launchpad.net/bugs/792576
<micahg> can we just do 20110426+1+really0.2.x instead of an epoch?  that way if we manage to consolidate in the future, it's easier to reconcile
<bryceh> Sarvatt, thanks
<slangasek> micahg: I suppose so
<bcurtiswx> who maintains planet ubuntu?
<slangasek> in that case we should definitely add it to the sync blacklist, since we don't want it to show up on the merge list either without specific action
<micahg> +1
<bryceh> bcurtiswx, it's open maintenance, I don't think it has a specific maintainer
<bryceh> slangasek, agreed
<slangasek> and in general, if people are maintaining packages in Ubuntu with non-Ubuntu version numbers... please ask for them to be added to the sync blacklist, even if there's currently no package of that name in Debian :-)
<bcurtiswx> hum, i moved my blog to my local comp, and im confused as why the rss feed link works, but not the link on my name.. and today's blog didn't show.  im lost for answers
 * micahg is still for adding ubuntu to the version string as well
<slangasek> micahg: I'm indifferent to that... but even with an ubuntu version it should still be blacklisted if our version numbers are going to imply a merge is wanted
<micahg> slangasek: true
<micahg> slangasek: blacklists still show up in MoM though
<slangasek> they're not supposed to
<slangasek> if they do, I think that's a regression
<micahg> chromium-browser and flashplugin-nonfree are blacklisted and still show up
<slangasek> we ought to fix that then :)
<micahg> indeed
<micahg> bug 671556 could probably be hijacked to track that
<ubottu> Launchpad bug 671556 in Merge-o-Matic "Blacklist merges" [Undecided,New] https://launchpad.net/bugs/671556
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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> ugh even getting 10Mbit clamav takes way too long to bzr branch. :-P
#ubuntu-devel 2011-06-04
<ohsix> hm any idea why this machine would be connecting _back_ to my router? Jun  3 15:50:48 lez tcp-env[31501]: connect from adelie.canonical.com
<ohsix> oh nevermind
<ohsix> heh, guess that happens when you're moving mail around
<ScottK> SpamapS: apt-get source is probably way faster.
<sladen> ohsix: email?  IRC ident?
<ohsix> yea forgot that machine moved mail; my lp id mail is forwarded there
<nigelb> ScottK: Killer email to ubuntu-devel.
<nigelb> :)
<ScottK> Thanks.
<yao_ziyuan> http://imageshack.us/photo/my-images/705/ubuntum.png/
<yao_ziyuan> is the menu background in this screenshot a bug?
<dpolehn> what is the best way to find somebody to do a review for you?
#ubuntu-devel 2011-06-05
<anilg> Lo all.. is this the right room to ask a questin about appindicator devel?
<anilg> Specifically how to go about adding a menu item into the sound-menu indicator?
 * bdrung pokes broder 
<bdrung> maco: i couldn't wait: http://anonscm.debian.org/gitweb/?p=collab-maint/packaging-dev.git
<bdrung> maco: please compare that with your package and copy your long description
<bcurtiswx> i'm trying to understand the logic behind g_signal_connect_swapped, so for example if i have g_signal_connect on a button and the callback will print "hello world", if i use g_signal_connect_swapped I could also have that same "clicked" signal destroy the window.  SO the logic behind using that would be to have multiple actions perform on the same signal?
<bcurtiswx> can a GTK grid container have multiple children?
<bcurtiswx> wait nvm, can it have children of differing sizes ?
#ubuntu-devel 2012-05-28
<geser> mdeslaur: Hi, is bug #1004845 interesting for the security team?
<ubottu> Launchpad bug 1004845 in python-keyring (Ubuntu) "python-keyring CryptedFileKeyring is insecure (was: doesn't work with python-crypto 2.6-1 (ValueError: IV must be 16 bytes long))" [Undecided,Confirmed] https://launchpad.net/bugs/1004845
<doko> cjwatson, graphviz
<doko>  - debian/patches/linkage: Add more explicit library linkage to cope with
<doko>       'ld --no-copy-dt-needed-entries'.
<doko> wondering why this is still needed
<diwic> TheMuso, still up?
<diwic> Or - for anyone who listens - I'm having the trouble that "dpkg-buildpackage -S" complains about "the diff modifies the following upstream files" and then lists the entiere .bzr directory
<diwic> ah wait
<tumbleweed> what's the .bzr directory doing in your orig tarball?
<cjwatson> doko: I didn't look very hard since the dh_python2 patch is still needed; I'm about to look at the build failure
<diwic> tumbleweed, I used "dpkg-buildpackage -S" instead of "bzr builddeb"
<diwic> inside a merge-mode branch
<tumbleweed> right
<diwic> problem solved
<cjwatson> dpkg-buildpackage -S -I.bzr would probably have fixed it too
<cjwatson> or indeed just -I
<cjwatson> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I -uc -us"  in ~/.devscripts, debuild -S
<cjwatson> may as well use the available tools :)
<doko> cjwatson, thanks. maybe the changelog entry is wrong, and it should be --as-needed
<cjwatson> I thought I was fairly careful about writing that entry
 * diwic is about to upload to the Ubuntu archive for the first time in his life, feels a little scary :-)
<StevenK> diwic: The upload processor does not bite.
<StevenK> diwic: Hard, at least.
<diwic> StevenK, but the bug reports will if I did something wrong ;-)
<diwic> StevenK, but not that many use quantal yet I assume
<Laney> most of them are probably in here :-)
<diwic> Laney, :-)
 * diwic anxiously waiting for the upload processor's reject or accept
<diwic> accepted :-)
<xnox> diwic: on my laptop, my mic now disappeared
<diwic> xnox, please clarify "now" :-)
 * xnox wait.... diwic's package is not build yet. Prank fail!
<diwic> xnox, haha
<Laney> zul: Daviey: Are you aware of the nova-common upgrade failure? There is a typo in nova-common.postinst on line 26.
<Laney> /var/lib/dpkg/info/nova-common.postinst: 33: /var/lib/dpkg/info/nova-common.postinst: Syntax error: "fi" unexpected (expecting "then")
<Laney> actually even if I fix that it bails trying to parse my config file
<Laney> bah humbug
<directhex> Laney, nova-common?
<directhex> oh, cloud lala
<l3on> some core developer here? I need a sru sponsor for bug 921430
<ubottu> Launchpad bug 921430 in qwt (Ubuntu) "Package libqwt-dev wants to upgrade every time" [Undecided,Fix released] https://launchpad.net/bugs/921430
<zul> Laney: please open up a bug and ill get to it today
<mdeslaur> geser: yes, thank
<mdeslaur> thanks
<Laney> zul: did, bug #1005479
<ubottu> Launchpad bug 1005479 in nova (Ubuntu) "Upgrades to 2012.2~f1-0ubuntu1 fail due to syntax error in nova-common.postinst and error in config migrator" [Undecided,New] https://launchpad.net/bugs/1005479
<zul> Laney: thanks
<Laney> np
<Laney> zul: Don't forget the nova-manage half of the bug. The commit I see only fixes the syntax error.
<zul> Laney: yeah
<Laney> cool, thought you might have missed it due to the Fix Committed. :-)
<Daviey> Laney: i was no.. no.. thanks for identifying it
<ahasenack> hi guys, could I interest a sponsor in #1004678? :)
<Daviey> ahasenack: have you seen the lintian output? http://pb.daviey.com/DhW0/
<ahasenack> no, I haven't
 * ahasenack checks
<ahasenack> Daviey: should I add overrides for the ones that don't apply?
<ahasenack> Daviey: or just explain them in the bug?
<Daviey> ahasenack: well, it's only guidance really.. i just saw a large volume.. where most or normally easily resolvable.. which ones are not?
<geser> ahasenack: which ones do you intend to override?
<ahasenack> Daviey: I have to check them all, but for example the one about dh_python isn't, because the rules file checks the ubuntu release and then decides which python system to use
<ahasenack> this package builds on lucid, natty, oneiric, precise and quantal
<Daviey> ah!
<ahasenack> that probably also explains the "ancient standards version"
<ahasenack> since we can't (easily) adjust the control file depending on the target release
<Daviey> nah, that one can be ignored.. that is Standards: in debian/control.. we don't really follow that.
<ahasenack> about the diff, I will have to check, since we build from branches, I guess it's looking for the 12.04.X previous orig file or something
<ahasenack> substvar we need
<ahasenack> it's the only way to adjust dependencies depending on the target release
<ahasenack> (that I know of)
<Daviey> Ubuntu policy is wedged at 3.8.2 :)
<ahasenack> what is the one for lucid? How do I find that out?
<Daviey> ahasenack: what about the patched files? Are they needed?
<Daviey> ahasenack: lucid is 3.8.2
<Daviey> anyway, that isn't an issue.
<ahasenack> ok, I can bump that to 3.8.2 then
<ahasenack> about the patched files, I'll have to check
<ahasenack> I basically just did a dpkg-buildpackage -S
<ahasenack> actually, hm, that didn't generate a diff file here
<ahasenack> but a landscape-client_12.05-0ubuntu1.tar.gz
<ahasenack> like a native package
<ahasenack> what is the base tarball your build used? 12.04.3?
<Daviey> ahasenack: bzr bd -S
<ahasenack> so, this "Looking for a way to retrieve the upstream tarball"
<ahasenack> it looks for a specific "make" target, right? Something like get-upstream-source
<ahasenack> which I don't think we have
<ahasenack> so it does "Using pristine-tar to reconstruct landscape-client_12.05.orig.tar.gz."
<ahasenack> how does that bit work? What is pristine-tar?
<ahasenack> sorry if these are basic questions, we can take this elsewhere, or just point me somewhere
<geser> ahasenack: for the substvar warning: check if you need ${source:Version} or ${binary:Version} instead of ${Source-Version} which is deprecated (see also http://manpages.ubuntu.com/manpages/lucid/en/man5/deb-substvars.5.html and http://lists.debian.org/debian-mentors/2006/09/msg00230.html)
<ahasenack> geser: ah, thanks. I'll see also if those work in lucid, our minimum version
<geser> the linked manpage is from lucid, so it should work there too
<ahasenack> thanks
<Daviey> ahasenack: you really should apply for per package upload for this :)
<ahasenack> Daviey: with all these mistakes?
<ahasenack> Daviey: and I will, but after our june release
<Daviey> ahasenack: hah, there isn't anything significant here.. I only raised it because there were a fair few.  There are many packages in the archive in a worse state.  What matters more is the interest to incrementally improve it, which is what you are doing :)
<ahasenack> Daviey: ok, so let me address some
<ahasenack> Daviey: I should unsubscribe sponsor while I do this, right?
<Daviey> ahasenack: ok.. Yes, unsubscribe.. i'll follow this through.
<ahasenack> Daviey: ok, thanks for the review
 * apw has just scratch installed a precise system without the 'third party' box ticked and now rhythmbox fails to see mp3s and the button to 'installed the required ...' just fails, clearly not intended behaviour; its looking for a python2.7 id3 muxer, any idea what its called?
<Daviey> apw: ubuntu-restricted-extras ?
<apw> Daviey, will give it a go, so i know what to report in the bug
<Daviey> apw: scrub that, bug 888847
<ubottu> Launchpad bug 888847 in gnome-codec-install (Ubuntu) "rhythmbox can't find ID3 tag muxer for MP3 support" [Undecided,Confirmed] https://launchpad.net/bugs/888847
<apw> Daviey, gah thats a real sucky user experience indeed, install bad then ugly will install from the button in rhytmbox ... ick
<ScottK> xnox: We use version specific build-deps for boost much more than Debian, so it ends up being a bit different.
<xnox> ScottK: ok, thanks. good to know.
 * xnox open browser window, type into the address bar `apt-cache search package<RET>`, stare at the google results, experience the utter confusion of not seeing terminal output.
<geser> did google find anything useful?
<tumbleweed> cjwatson: care to merge fonts-tlwg? it being out of date is responsible for at least 2 FTBFS packages
<cjwatson> tumbleweed: I think I've tried but it was tediously hard; I'll have another go ...
<tumbleweed> yay :/
<cjwatson> or maybe that was the indic font cluster
<tumbleweed> it's responsible for cjk not building on i386 which creates other tex uninstallability problems
<cjwatson> oh, hey, I think this can be a sync actually
 * cjwatson test-builds to check
<cjwatson> tumbleweed: yep, it was a sync after all - done, thanks for the prod
<tumbleweed> thanks
<ahasenack> hi, any idea why lintian (invoked by debuild -S) would be complaining about the original-maintainer field?
<ahasenack> W: landscape-client source: unknown-field-in-dsc original-maintainer
<ahasenack> and it's in fact XSBC-Original-Maintainer in the control file
<ahasenack> (no clue what XSBC means, other than maybe a bank in Hong Kong ;)
<broder> ahasenack: you can safely ignore that
<broder> XSBC- means that the field is an extension ('X') and should be copied to the .dsc ('S' - source), .deb ('B' - binary), and .changes ('C') files
<broder> when it gets copied it's without the XSBC- prefix
<broder> so the dsc file ends up with "Original-Maintainer"
<ahasenack> ok, and lintian is wrong then?
<broder> yeah. the version of lintian in quantal shouldn't complain anymore
<ahasenack> so a bug was filed already I assume?
<ahasenack> or, is unneeded
<ahasenack> broder: thanks, I added a lintian override for now
<Laney> there's no need to override for that
<ahasenack> well, I didn't know about this "bug", and my colleagues who are going to review my branch probably also don't
<ahasenack> so I added an override with a comment
<ahasenack> better than having this question pop up again in the future when someone new comes along I think
<ahasenack> ah, found the bug
<ahasenack> #158667
<ahasenack> but
<ahasenack> that's old
<Laney> anyone uploading the package will be used to seeing it
<hallyn> hey - seabios until now has been tracked separately in debian and ubuntu.  i'm syncing from debian.  do i use the ubuntu changelog with debian entries with newer entries above that?  Or is that not good enough because older debian entries are not really reflected?
<hallyn> i.e. ubuntu version is at 0.6.2-0ubuntu3, debian had jumped from 0.6.1-something to 1.6.3.
<hallyn> so i was thinking i would just have the 1.6.3+ entries prepended to the ubuntu changelog, and that's it
<geser> hallyn: "sync" like taking the Debian package without any additional Ubuntu delta or are you merging?
<hallyn> geser: well we'll see, but so far it looks like a sync will work
<geser> if it's a sync then all Ubuntu delta (including the changelog entries) get dropped
<hallyn> geser: oh really?  I didn't know that.  cool.  thanks.
<geser> for a sync the package gets copied as is from Debian
<geser> we merge only the old Ubuntu changelog entries when merging
<hallyn> that makes sense.  i'd just never sync'd :)  thanks
<hallyn> geser: I'm googling, but not seeing a howto (only for merging).  Do I do a 'dch -i' and say sync from debian, or not even that?  Do I just pull-debian-source; debuild -S; dput ?
<geser> hallyn: "syncpackage --force seabios"
<hallyn> geser: thanks again
<geser> I usually do a test build to check that it builds before syncing
<geser> test build in a quantal pbuilder
<hallyn> right.
<goddard> my program won't build because I think some libraries changed location after my upgrade or something.  How do I keep my development enviornment from breaking?
<geser> can you be a little more precise?
<goddard> i am using find_package to find the GL header files and other required files
<goddard> http://pastebin.com/yG8DWTwc
<goddard> it isn't working
<goddard> it says I have the package installed but when I do apt-file glu.h or gl.h it finds nothing
<goddard> im new to all this stuff so it would be cool to know some tricks so this doesn't happen
<goddard> one of the most annoying parts of c/c++ is library linking at least for me especially after an OS upgrade
<Daviey> ahasenack: Hey, any progress?
<ahasenack> Daviey: finished a branch against our trunk addressing several of those
<ahasenack> Daviey: it will need to go through the review process we have
<ahasenack> Daviey: I'm a bit confused with native vs non-native packages, our trunk has debian/* in it, so it's a native package in that regard
<ahasenack> Daviey: but ubuntu has a diff and an orig.tar.gz, so it's non-native there. And the diff is about debian/changelog, debian/control and some po files
<ahasenack> Daviey: I'm thinking about releasing a tarball without the debian/* stuff
<ahasenack> Daviey: and in this branch I also made it explicit that our upstream build is native, let's see how that goes (debian/source/format with "3.0 (native)")
<ahasenack> just pushed, btw: lp:~ahasenack/landscape-client/client-package-lintian-fixes
<Daviey> ahasenack: yeah, a native package shouldn't have a *debian*.tar.gz
<ahasenack> Daviey: it wasn't even version 3
<Daviey> ahasenack: Okay, i'll take a look in the morning, unless you are in a hurry?
<ahasenack> Daviey: oh, no, it's fine, and that's not even the upload proposal yet, it's just to address these issues in our trunk first
<ahasenack> Daviey: then I will redo the branch in that bug asking for the upload
<Daviey> ok, super.
<stgraber> cjwatson: can you let the TB minutes through? (devel-announce)
<cjwatson> stgraber: done
<stgraber> cjwatson: thanks
<sladen> stgraber: +1 for the minutes
<RAOF> SpamapS: Doing/done an SRU sweep?
#ubuntu-devel 2012-05-29
<pitti> Good morning
<slangasek> pitti: <blink>  isn't this a bit early, even for you? :)
<pitti> yeah, I usually sleep another hour or so after my wife gets up, but couldn't any more
<pitti> we have a thunderstorm here
<RAOF> A morning thunderstorm?
<RAOF> Curious
<pitti> RAOF: it got high time for some rain, anyway :)
<larsduesing> Good morning!
<larsduesing> could be anybody so kind, and have a look after https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-apport-fix/+merge/107351, please?
<rickspencer3> good morning pitti ... yet more beer!
<pitti> almost :)
<pitti> rickspencer3: good morning to you!
<rickspencer3> now we need to get the daily tests going
<rickspencer3> good morning pitti :)
<rickspencer3> nice to wake up to a cup of coffee irl, and a beer on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<StevenK> rickspencer3: That could be because precise is released ... :-)
<pitti> rickspencer3: oh, precise -- you should be looking at http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html :)
<rickspencer3> d'oh!
<pitti> hence pitti | almost :)
<rickspencer3> stupid browser history
<rickspencer3> that omap4 linux is still there, I see
<rickspencer3> well, *close* to a beer ;)
<pitti> yeah, seems the ti-omap kernel guys don't like that package, it ceases to exist at every other upload
<dholbach> good morning
<dholbach> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<tsdgeos> dholbach: I have a upstream patch that's been accepted in Qt that i'd like to get in Ubuntu's Qt https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/999522 Any hint on how to proceed?
<ubottu> Launchpad bug 999522 in qt4-x11 (Ubuntu) "[SRU] Fix problems in Qt dragging when all of the window target has been shaped out for input" [Undecided,New]
<dholbach> tsdgeos, do you know why it hasn't been accepted upstream?
<tsdgeos> dholbach: upstream=Qt?
<tsdgeos> dholbach: it *has* been accepted upstream
<dholbach> ahhhh
<dholbach> ok
<dholbach> sorry, I misread
<dholbach> is it in Q already?
<tsdgeos> nope, there hasn't been a Qt release with it yet, so it isn't part of any ubuntu package as far as i know
<dholbach> ok, I see
<dholbach> I can help you get it into Q, which is one of the first steps of https://wiki.ubuntu.com/StableReleaseUpdates
<dholbach> tsdgeos, would you mind adding some information to the bug report according to the documentation?
<tsdgeos> i can try
<dholbach> cool, thanks a bunch
<tsdgeos> not sure what's missing though :D
<dholbach> impact of the bug, test-case, possibility of regressions, etc.
<cjwatson> test case is the most important one
<dholbach> just some more information for those who want to assess and test it, who haven't been following the unity-2d bugs closely
<tsdgeos> there's a link to the bug and there's a test case there
<cjwatson> it must be in the Ubuntu bug
<tsdgeos> i can copy & past if that's what you want
<cjwatson> SRU verification is a bottleneck and it's important for uploaders to cooperate in keeping it smooth
<tsdgeos> c&p done
<dholbach> tsdgeos, is there a way to get the resulting patch from https://codereview.qt-project.org/#change,24361 easily? :)
<tsdgeos> You actually only want https://codereview.qt-project.org/#patch,unified,24361,12,src/gui/kernel/qdnd_x11.cpp
<tsdgeos> since we don't ship the unittests
<tsdgeos> well, qt doesn't ship the unittests
<tsdgeos> so we don't etiher
<dholbach> ok, thanks
<tsdgeos> If it helps
<tsdgeos> there's http://qt.gitorious.org/qt/qt/commit/c3eb2e63425c47b8e3eeb7416e225fab10c5c15a too
<dholbach> perfect
<dholbach> I don't use git very often, nor the codereview.qt page :)
<dholbach> does anybody know what might be crashing in https://launchpadlibrarian.net/106359743/buildlog_ubuntu-quantal-i386.sphinx_1.1.3%2Bdfsg-4ubuntu1_FAILEDTOBUILD.txt.gz? is it xvfb?
<tsdgeos> dholbach: updated https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/999522
<ubottu> Launchpad bug 999522 in qt4-x11 (Ubuntu) "[SRU] Fix problems in Qt dragging when all of the window target has been shaped out for input" [Undecided,New]
<dholbach> thanks tsdgeos
<debfx> dholbach, tsdgeos: I want to merge and update Qt in quantal anyway so I don't mind adding the patch from bug #999522 on top of it
<ubottu> Launchpad bug 999522 in qt4-x11 (Ubuntu Quantal) "[SRU] Fix problems in Qt dragging when all of the window target has been shaped out for input" [Undecided,Triaged] https://launchpad.net/bugs/999522
<dholbach> debfx, that'd be awesome
<dholbach> tsdgeos, does this only need to be fixed in quantal and precise?
<tsdgeos> dholbach: well, it does affect precise, and since it's an LTS i'd really appreciate if it was fixed there too
 * dholbach nods
<dholbach> ok, I just saw that somebody added bug tasks for precise as well, so we're all set
<tsdgeos> great :) tx
<Laney> broder: could it be that backportpackage doesn't pass -v0 when the package is NEW in the destination release?
<pitti> ev: hey Evan, how are you?
<pitti> ev: I'd appreciate a quick look at https://code.launchpad.net/~pitti/ubiquity/ubuntu-drivers-common/+merge/107744
<ev> I'm good, how are you?
<ev> sure
<pitti> ev: I'm great, thanks! had a nice weekend, and you?
<ev> yeah, loving this sunny weather
<pitti> ev: in particular, I'm interested how ubiquity gets the jockey-text -a auto-install drivers into teh target system
<pitti> ev: by copying the installed bits from the live system, or running the plugins again in /target
<pitti> ev: will respond to your retracing mail ASAP
<ev> thanks
 * ev looks over the merge
<pitti> ev: I have the full install syslog, in case you want to take a look
<ev> pitti: debconf doesn't like multiple things talking to it
<ev> since ubiquity is already talking to it, you need to do something like DEBCONF_DB_REPLACE=configdb DEBCONF_DB_OVERRIDE="Pipe{infd:none outfd:none}"
<ev> err
<ev> DEBCONF_DB_REPLACE=configdb DEBCONF_DB_OVERRIDE="Pipe{infd:none outfd:none}" ubuntu-drivers autoinstall
<pitti> ev: ah, that's why you restart the jockey-backend with those
<ev> precisely
<pitti> ev: ok, that explains the man-db error; I'll fix that
<ev> cheers
<pitti> ev: so is it expected that my /target doesn't have bcmwl-kernel-source?
<ev> pitti: you'll also need to replicate jockey/debian/jockey.ubiquity
<ev> so that the packages get installed in the /target as well
<pitti> ev: ah, that was my question
<pitti> ev: so the plugins don't run again in /target
<ev> pitti: nope, there's no guarantee that /target exists when a plugin is run
<ev> especially for ubi-prepare, which occurs before partitioning
<cjwatson> plugins can define stuff that happens post-install
<pitti> ev: I mean, the targets run only once, and we don't run ubuntu-drivers/jockey again in /target later on
<cjwatson> (i.e. subclass plugin.InstallPlugin)
<ev> ah indeed
<pitti> ev, cjwatson: ack, so I'll provide the counterpart of jockey/debian/jockey.ubiquity
<pitti> I forgot about that one
<cjwatson> dunno if that's what's wanted here, haven't looked at the diff
<pitti> cjwatson: right, I just needed to refresh my memory how drivers got into /target
<cjwatson> yeah, if jockey.ubiquity is a target-config hook, that's preferable to code directly in ubiquity
<pitti> cjwatson: right, jockey-common ships a /u/l/ubiquity/target-config/31jockey_packages
<pitti> I'll put a corresponding script into ubuntu-drivers-common
<pitti> ev: just to be sure, /u/l/ubiquity/target-config/31jockey_packages runs in the live system, not in chroot /target, does it?
<pitti> ev: it calls apt-install, which will install the given package into /target, I presume
<ev> that's my understanding, yes
<pitti> good, thanks
<pitti> I'll give it another full test run with both changes then (debconf env and hook)
<ev> cheers
<ev> I've updated the MP with this discussion
<dholbach> can somebody please reject https://code.launchpad.net/~logatron/ubuntu/quantal/imagemagick/fix-for-993041/+merge/107156? (patch sent to debian instead)
<pitti> dholbach: done
<dholbach> thanks pitti
<dholbach> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Benkinooby> hi, i want to turn off my laptops' backlight in order to use it with strong sunlight. i tried to fiddle with /sys/class/backlight and later with /proc/acpi/video and the xset command (with dpms option) but on luck finally i found out, that /proc/acpi/video/GFX0/DD04/brightness specifies the levels to be set for the backlight and that in can only adjust to the given levels in that file - but the lowest level is 20 and not 0. how can i
<Benkinooby> get to zero?
<Benkinooby> this site supports my findings https://wiki.kubuntu.org/Kernel/Debugging/Backlight
<Benkinooby> i'm on ubuntu 10.04
<ogra_> sounds like a kernel issue
<Benkinooby> ogra_, i think it is more ubuntu related...
<ogra_> Benkinooby, well, that file contents are controlled by the kernel
<Benkinooby> ogra_, when reading the website what does "disassembled DSDT" mean?
<Benkinooby> ogra_, ok, didn't know that
<Benkinooby> ah, ok found some hints on google
<ogra_> DSDT is part of your bios
<ogra_> its the table defining what HW your machine  has
<Benkinooby> ogra_, i'm on http://powersave.sourceforge.net/powersave/DSDT.html ... so i need to find these tables, disassmbel them, edit them (adding the level 0 as supoorted level) recompoile them and then go?
<ogra_> no idea, i dont use intel hardware :)
<ogra_> but that might or might not help, i would ask some ACPI/kernel-powermanagement expert ;)
<Benkinooby> ogra_, where can i find them, do you know?
<ogra_> probably in #ubuntu-kernel
<Benkinooby> ogra_, maybe a mailing list would be more useful than irc... not sure.. also i'm not much of an expert... more like a blind man hitting a bee nest with his stick
<Benkinooby> ogra_, but i'll go for that kernel channel for now :)
<ogra_> try ubuntu-devel-discuss then
<Benkinooby> ogra_, thank you for helping me on
<pitti> ev: got back to this now; odd, I still get the "bad fd" error even with that debconf env (I added a print to ubuntu-drivers to verify it's there)
<ogra_> or the ubuntu-kernel ML :)
<mterry> ev, hello!  So I submitted a crash in quantal, but don't see it in errors.u.c (extended time to a year and still don't see it).  Is there another way to see the data?
<larsduesing> short question: until when can I get a debian-package into quantal-universe?
<Laney> larsduesing: you want to be considering Feature Freeze as the deadline
<larsduesing> ok
<geser> larsduesing: easy till FeatureFreeze (around Aug 23rd), after that you need a freeze exception
<larsduesing> (I have the problem that it is in state "won't compile" - in kfreebsd... )
<larsduesing> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667755
<ubottu> Debian bug 667755 in src:aiccu "aiccu: FTBFS[kfreebsd]:" [Serious,Open]
<geser> larsduesing: quantal syncs from unstable now, but as aiccu has Ubuntu delta it needs a merge to get new Debian revisions of that package into quantal
<larsduesing> yes
<larsduesing> I'm aware of that
<larsduesing> but it won't get to debian unstable - because it won't compile on kfreebsd
<Laney> it already is in unstable
<larsduesing> oh
<larsduesing> wait
<cjwatson> "won't compile on kfreebsd" is the sort of thing that impedes migration to testing, not to unstable.
<larsduesing> sorry...
<pitti> ev: hm, it seems calling apt-get in simple-plugin just doesn't work -- /proc/self/fd/3 is a link to /proc/5146/fd (i. e. to its own directory), which seems to be what apt-get/man-db are stumbling upon
<cjwatson> You should probably use apt-install rather than apt-get directly, unless you need the package to be installed immediately.
<pitti> ev: do you know of any plugins which install packages?
<pitti> cjwatson: ah, that'll work for the live system, too?
<cjwatson> No, apt-install is "queue for installation in target"
<pitti> cjwatson: right, but simple-plugins installs driver packages (such as bcmwl-kernel-source) into the live system, in ubi-prepare
<cjwatson> I don't quite get what you need in the live system - isn't your plugin in the very package you need installed?
<cjwatson> Oh
<pitti> that currently calls jockey-text -a, and has some custom code to launch the d-bus backend with some magic debconf env
<cjwatson> You would have to be careful to do anything like that before the main business of copying stuff starts, I think
<cjwatson> Maybe
<cjwatson> And even then it would need a separate debconf db
<pitti> yes, it's done after checking "3rd party drivers" and finishes before the partitioning screen
<cjwatson> The only stock plugin that installs packages is, I think, usersetup (oem-config-*)
<larsduesing> Ok, another question... how to debug apport-plugins? (at the moment I do a kill -SIGFPE <pid> to get apport to run...)
<pitti> cjwatson: the current code that uses jockey just launches the d-bus backend with DEBCONF_DB_REPLACE=configdb and DEBCONF_DB_OVERRIDE='Pipe{infd:none outfd:none}'
<cjwatson> Right, which is "temporary throwaway db"
<pitti> larsduesing: unless your hook depends on a crash, you can use "apport-bug packagename"
<larsduesing> and I can halt any transfer to launchpad there, too?
<pitti> cjwatson: when I run the apt-get command manually while ubiquity runs, it works; but when ubiquity launches it through simple-plugins, man-db keeps breaking on "3: bad file descriptor", which I can't replicate
<pitti> larsduesing: yes, just don't click on "submit"
<pitti> larsduesing: you can use the expander to see the data, or use "apport-bug --save /tmp/myreport package" to get a file with the data
<larsduesing> I see... being too cautious
<larsduesing> thanks
<pitti> cjwatson: I guess the bad fd is due to fd 3 pointing to its own directory for some reason
<cjwatson> 3 would be the file descriptor that's expected to be usable for writing to the debconf frontend
<pitti> right
<cjwatson> Perhaps you have managed to arrange for it to think there's a debconf frontend running but for it not to be connected, or something
<cjwatson> I'm afraid the best way to debug this is usually to get an strace -f of everything and slog through it
<cjwatson> I've done it before, I can probably have a go if need be
<pitti> cjwatson: it does have DEBIAN_HAS_FRONTEND=1
<cjwatson> Which means that the debconf confmodule won't launch its own
<pitti> cjwatson: strace -x is http://paste.ubuntu.com/1013051/
<pitti> err, sh -x
<pitti> getting strace now
<cjwatson> You might need something along the lines of ubiquity.install_misc.debconf_disconnect
<cjwatson> Oh, yeah, that doesn't look right
<cjwatson> Can you paste the script that you're -x-ing there?
<pitti> cjwatson: http://paste.ubuntu.com/1013056/
<pitti> cjwatson: (the old one called jockey-text -a)
<pitti> erk, strace says "operation not permitted"; I guess something is already tracing it
<cjwatson> Try adding 'env -u DEBIAN_HAS_FRONTEND -u DEBCONF_REDIR DEBIAN_FRONTEND=noninteractive' to the start of that DEBCONF_DB_REPLACE=... command; you need it to start a new frontend
<cjwatson> And to reconnect to it properly
<pitti> cjwatson: yay, that works
<pitti> -u DEBCONF_REDIR was the trick apparently
<pitti> cjwatson: many thanks!
<cjwatson> pitti: It'd probably have been all three (well, at least the first two).  You're welcome.
<cjwatson> I wouldn't recommend paring that down to any fewer sets/unsets.
<pitti> cjwatson: I meant, ubuntu-drivers already sets DEBIAN_FRONTEND and removes DEBIAN_HAS_FRONTEND (that was copied from the old jockey code); but I'll now keep all three of them together
<cjwatson> Oh, it does?  OK.  Just as long as you do that before loading the confmodule.
<pitti> right, that wasn't the case (and part of the problem presumably)
<cjwatson> Personally I prefer to do this outside whatever scripts load the confmodule, to avoid confusion with the confmodule re-execing the calling script.
<cjwatson> Though that's only a problem with the shell confmodule.
<pitti> I just moved it all to simple-plugins, so that the env setup is in one place, before loading confmodule
<pitti> doing it in ubuntu-drivers is both too late, as well as confusing/wrong, as you might want to use it outside of ubiquity, too
<cjwatson> Right; this is an integration problem, rather than something intrinsic to ubuntu-drivers.
 * pitti does a fresh boot/test run now
<seb128> is anyone on precise using proposed who could ack that software-center 5.2.2.1 still works fine for them on bug #1002271?
<ubottu> Launchpad bug 1002271 in software-center (Ubuntu) "REGRESSION: crash in cell renderer" [Medium,In progress] https://launchpad.net/bugs/1002271
<seb128> (5.2.2 moved to -updates with a regression and the regression fixes is blocked on verification)
<seb128> (better if you have the bug mentioned and confirm the update fixes it)
<hallyn> slangasek: would you have any objection to moving the qemu-utils package to qemu-linaro?
<hallyn> hm, i guess that might not work :)  i'm being silly
<hallyn> just trying to think how best to line up with what debian is doing (with separate qemu source package providing qemu-utils)
<mdeslaur> seb128: sure, one sec
<seb128> mdeslaur, thanks
<apw> cjwatson, was just using bzr merge-package and it is now telling me it is deprecated, does that imply use of bzr merge lp:debian/<package> is now the approved way
<xnox> apw: yes
<pitti> ev: https://code.launchpad.net/~pitti/ubiquity/ubuntu-drivers-common/+merge/107744 is tried and tested now; thanks for your help!
<apw> xnox, thanks
<xnox> apw: also note about 'smart quilt handling' it will unapply patches before merging.
 * ev looks
<apw> xnox, handy indeed
<slangasek> hallyn: I don't think I would, no
<vsingh165> need help building a test package for nautilus, please
<vsingh165> I'm following these instructions:  http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
<apw> slangasek, got a sec to look at a branch for me?  i was just merging pciutils from debian and 1) i wanted to make sure what i did made sense, and 2) if it does i think that means there is no longer a delta (they did merge your changes by the look of things) and what does one do then: lp:~apw/ubuntu/quantal/pciutils
<xnox> apw: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~apw/ubuntu/quantal/pciutils/".
<apw> slangasek, xnox: damn lp:~apw/ubuntu/quantal/pciutils/debian-merge
<cjwatson> I can't speak for 1); if 2) is true, then 'syncpackage -f -d unstable pciutils'
<apw> stupid namespace restrictions which just hurt my head
<cjwatson> (i.e. we don't use bzr to do syncs)
<apw> cjwatson, yep ... makes sense, as steve did the last set of changes hopefully he can confirm we do indeed have no delta
<xnox> apw: no delta
<xnox> $ bzr diff --old lp:debian/pciutils --new lp:~apw/ubuntu/quantal/pciutils/debian-merge | diffstat
<xnox> Most recent Debian version: MISSING
<xnox>  changelog |    6 ++++++
<xnox>  1 file changed, 6 insertions(+)
<xnox> apw: why is there no maintainer field update? =)
<apw> xnox, _assuming_ i did the merge right
<Laney> there should be more diff than that in the changelog, if merged using bzr
<apw> Laney, the only thing in the changelog is the 6 lines saying i did the merge
<apw> Laney, and when i compared the two trees i found nothing to report as 'remaining changes'
<apw> xnox, i think the bzr vis output also says that i'd expect no delta, so i think i am right
<Laney> how did you do the merge? I just mean that if you used 'bzr merge' then it would have merged all of the old changelog entries in too.
<Laney> and if not, then a by hand merge might have gone wrong :P
<xnox> apw: when I do merge locally I have a few conflicts.
<apw> Laney, well i'd agree except that for the most recent upstream update, they merged our tree in
<xnox> how did you resolve pci.ids update-pciids.sh
<Laney> i see, if they took our changelog then this would happen too
<apw> xnox, pci.ids i took wholesale from debian as its actually an imported file, so merging it makes no sense and theirs was newer
<apw> xnox, update-pciids.sh i compared in its unpatched state and they do not differ
<apw> xnox, i think the delta there is actually false, its a fileid missmatch _i_think_ but ... i am here to make sure i did it right, and may well not have done
<barry> join #ubuntu-desktop
<xnox> apw: I wold sync.
<xnox> I would sync.
<apw> xnox, thanks, i think i agree with that too :)
<apw> xnox, i assume that appropritate even if you are going to get a delta back shortly
<cjwatson> apw: yes
<cjwatson> we like syncing where it's possible to do so without losing Ubuntu patches
<apw> cjwatson, and i assume once i run this syncpackage it will get seen by someone who can call me stupid
<Laney> if you can't upload then you want to use 'requestsync' instead
<Laney> syncpackage may direct you thus
<apw> ahh ...
<cjwatson> If you have upload rights, syncpackage is entirely self-service
<cjwatson> So in that case it won't get seen except after the fact
<cjwatson> I see you have upload rights to pciutils
<apw> cjwatson, yes indeed.  right one last sanity check and i am hitting it
<pitti> ogasawara: hey Leann, how are you?
<ogasawara> pitti: Hi martin, just saw your email about the apport hook for the backport kernels
<larsduesing> could anybody competent have a look at my try of a merge from debian-sid to quantal of aiccu?
<larsduesing> http://bazaar.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/revision/17
<pitti> ogasawara: would it be ok/desirable to treat all the packages in https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport as semi-official wrt. apport-bug? In that case I can just declare that PPA a "native origin", i. e. a package source that apport accepts
<ogasawara> pitti: yes I think we want to consider them semi-official and would want to allow bug reporting for all the packages appearing there
<pitti> ogasawara: i. e. I can do that, or just accept the kernel from that PPA, or accept a kernel package with any particular naming pattern
<ogasawara> bryce_: ^^ I'm assuming you want ubuntu-bug style bug reporting for the backported X packages in the PPA?
<bdmurray> pitti: could you look at bug 1004029?
<ubottu> Launchpad bug 1004029 in apport (Ubuntu Precise) "apport-collect does not work for bugs with only a linux task" [High,Triaged] https://launchpad.net/bugs/1004029
<pitti> bdmurray: yes, that's on my list (nice description BTW!)
<bdmurray> pitti: thanks ;-)
<pitti> ogasawara, bryce_: I followed up to bug 1004101; please let me know there what you prefer
<ubottu> Launchpad bug 1004101 in apport (Ubuntu) "[RFE] Allow Bug Reporting When Running Backport Kernel" [Medium,Incomplete] https://launchpad.net/bugs/1004101
<ogasawara> pitti: ack, I'll add a comment for the kernel preference there
<vsingh165> Hi, I'm trying to test a fix for nautilus and I can't build the test package.  I'm following the wiki's instructions but with no luck:  http://pastebin.com/sv3CKS35
<asomething> vsingh165, the key line there is "dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/nautilus_3.2.1-2ubuntu12.diff.Ns16hs"
<asomething> run dpkg-source --commit and it will format your changes for you in a nice patch under debian/patches
<vsingh165> but will that submit the change to the package on the repos?
<vsingh165> sorry, I'm new.
<asomething> nope. I can see why commit sounds scary though.
<vsingh165> yeah...I just recently started contributing.  I do know my programming, and love Linux, but am unfamiliar with all this package build stuff.  Thanks for your help.
<vsingh165> trying it now
<tsdgeos> anyone knows which piece of code reacts to cursor-theme changes in org.gnome.desktop.interface ?
<vsingh165> asomething: it failed again http://pastebin.com/jHJgsDyN
<vsingh165> asomething: apparently, it can't even read the file that dpkg-source --commit had me create
<asomething> vsingh165, hmmm... I'm not sure about that one. I'm actually in a meeting in another channel so I can't really look too closely. Maybe someone else can help you out. Sorry
<vsingh165> asomething: ok.
<larsduesing> wahh
<larsduesing> can anybody help me: why is .pc in my patch?!? https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/+merge/107823
<larsduesing> I did all like http://developer.ubuntu.com/packaging/html/udd-merging.html
<sil2100> Hi!
<sil2100> I would need some info regarding quantal and the packages that are to land in quantal PPA's
<sil2100> Since during investigation of a build problem in unity on quantal, I noticed that the boots library that's the default (1.46) is a bit too old for the gcc toolchain we are using
<sil2100> We would essentially need boost 1.48 on quantal
<sil2100> The new g++ toolchain is more standard compliant it seems and breaks, for instance, shared_ptr
<cjwatson> quantal has boost 1.49
<sil2100> cjwatson: exellent - but the default is 1.46 still?
<cjwatson> not AFAICS
<cjwatson> it *has* boost 1.46, but libboost-dev points to 1.49
<cjwatson> perhaps you're explicitly build-depending on libboost1.46-dev or some such
<sil2100> Ah!
<sil2100> Need to check unity packaging for that
<cjwatson> in which case, don't do that :)
<sil2100> Since on my quantal chroot after doing build-dep for unity, I got boost 1.46 installed
<sil2100> But this might indeed be the case
<cjwatson> Yeah, that's the fault of unity's Build-Depends
<cjwatson> ..., libboost1.46-dev, libboost-serialization1.46-dev, ...
<sil2100> Ok, but now it all makes sense - I wonder actually why it's not just libboost-dev
<cjwatson> probably should just s/1\.46//g there
<cjwatson> maybe with >= 1.46
<sil2100> cjwatson: thanks!
<cjwatson> (or whatever)
<cjwatson> you're welcome
<ev> pitti, apw, seb128: hi :)
<seb128> ev, hey ;-)
<pitti> so, bug 984944 was fixed in quantal only
<ubottu> Launchpad bug 984944 in apport (Ubuntu) "Reject crashes that happen right after upgrade" [Medium,Fix released] https://launchpad.net/bugs/984944
<seb128> pitti, is whoopsie using the same "don't report" rules than apport?
<pitti> i. e. for precise you may still get crash reports that apply to a running binary which is already fixed
<pitti> seb128: yes
<pitti> well, it's supposed to, anyway
<ev> is the motivation for this just because we can't accurately tell the version, or is there concern about things like firefox
<ev> where upgrading underneath it breaks the universe
<pitti> see the bug
<ev> ah
<apw> pitti, presumably /proc/$$/exe points to the real binary if we replace it?
<ev> indeed, just did :)
<ev> right
<pitti> seems we got quite a lot of crashes where the user already upgraded to the new version
<pitti> but the previous binary was still running
<pitti> then it crashed
<ev> okay, I'm happy then
<pitti> and apport claimed it would still affect the new version
<pitti> and thus generating new duplciates for the newer version
<pitti> which doesn't make sense
<ev> right
<ev> thanks for fixing that
<pitti> right, so mark_report_upload() (which triggers whoopsie) is called after UnreportableReason check
<pitti> so whoopsie should not see those either
<apw> lrwxrwxrwx 1 apw apw 0 May 29 17:33 /proc/4175/exe -> /home/apw/tmp/test (deleted)
<pitti> apw: I compare that time stamp against the mtime of the actual binary, AFAIR
<apw> pitti, ok sounds good ...
<pitti> http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2296
<pitti> exe_mtime = os.stat('/proc/%s/exe' % pid).st_mtime
<ev> pitti: check_unreportable happens after mark_report_upload as we still want to upload crashes that would normally be rejected on launchpad because of outdated packages
<pitti> process_start = os.lstat('/proc/%s/cmdline' % pid).st_mtime
<pitti> ev: actually, it's not even using UnreportableReason; it's checked right in the "apport" program, i. e. it won't even write a .crash file
<ev> ohhhh, right
<ev> okay nevermind then
<pitti> meh, this is my pet project, and I don't know the whole code by heart any more..
<pitti> apport clearly grew way too big :)
<ev> or it grew contributors
<apw> ev, ok so we're back to that bug not being fixed :)
<ev> apw: and work not having to go into errors.ubuntu.com. Win.
<ev> well, for certain definitions of win
<ev> I need to stop rooting for the crashes
<pitti> so should we backport this to precise?
<ev> seems harmless enough
<seb128> apw, this apport change is in q only
<seb128> apw, not in precise
<apw> oh poop ... hmm
<pitti> I have two other bugs to work on which apply to precise, so I'll do an SRU by EOW anyway
<ev> pitti: rockstar, cheers
<pitti> added a precise task
<apw> pitti, i assume that ExecutableTimestamp: 1333654544
<apw> pitti, that that is an accurate timestamp on the binary we are running right ?
<apw> ev, the installed binaries carry the timestamp in the .deb, so we ought to be able to work it out
<pitti> apw: yes, it's st_mtime of what /proc/pid/exe points to
<pitti> i. e. the value of ExecutablePath: in the report
<cjwatson> apw: if we still have the .debs around ...
<apw> cjwatson, yeah if ...
<pitti> good night everyone
<henrix> RAOF: not sure if you're the right person to ask... we have a bunch of pkgs that landed on the wrong component in -proposed
<dupondje> SpamapS: updated the remmina bug
<SpamapS> dupondje: thanks!
<PaoloRotolo> Hi all!
<JonEdney> Howdy PaoloRotolo
<PaoloRotolo> JonEdney, hi
<bdmurray> dupondje: the freerdp bug would benefit from the same description modification
<dupondje> bdmurray: i'll do after food :)
<bdmurray> dupondje: great, thanks!
<seb128> bdmurray, hey, not sure how you accepted the gnome-control-center SRU the other day but the bugs didn't tagged verification-needed
<bdmurray> seb128: which numbers? I'll take a look at the code and them
<seb128> bdmurray, that SRU, https://launchpad.net/ubuntu/+source/gnome-control-center/1:3.4.2-0ubuntu0.2
<seb128> bug #1004384
<ubottu> Launchpad bug 1004384 in gnome-control-center (Ubuntu Precise) "[soundnua]: segfaults when selecting bluetooth input device" [High,Fix committed] https://launchpad.net/bugs/1004384
<seb128> bug #980317
<ubottu> Launchpad bug 980317 in gnome-control-center (Ubuntu Precise) "details -> overview disk size includes network mounts" [Low,Fix committed] https://launchpad.net/bugs/980317
<seb128> bdmurray, thanks
<bdmurray> seb128: weird the same tool is adding the tags to bugs I've done today
<seb128> bdmurray, not sure if you use the same tool as the other SRU team members are using or if you changed it but that's the first time I see SRU bugs non tagged in a long time
<bdmurray> seb128: the same tool and I'll look into it some more
<seb128> ok, if that only happened once maybe don't bother much, I will ping you if I see that happening again
<bdmurray> seb128: thanks, and I'll verify they get tagged for a while
<seb128> bdmurray, SpamapS, RAOF, slangasek: one of you might want to send an email to ubuntu-devel(-announce) about SRU rules being stricted, that would probably spare work compared to having to go through 90% of the uploaded packages to add comments saying that
<dupondje> bdmurray: description updated!
<cyphermox> eep, sorry, I uploaded the wrong .changes for freecad; this was meant to be a sync
<cjwatson> henrix: if it's what I think you mean (linux*/oneiric), I'm dealing with it now
<henrix> cjwatson: yep, that's it! :)
<henrix> cjwatson: thanks
#ubuntu-devel 2012-05-30
<nemo> *sigh*  who writes these depressingly wrong reviews in the Ubuntu Software Centre :(
<nemo> In the past I had admired the ones we had for prior versions of Ubuntu...
<nemo> http://m8y.org/hw/ubuntu.png
<nemo> Well written, nice appreciation of the game, detailed
<nemo> Sooo, I go to Ubuntu 12.04
<nemo> And I get Brendon King saying that you should install and run it under Windows instead because it is a little more stable
<nemo> Sooooooo totally wrong!
<nemo> We have way more problems with our Windows users
<nemo> Qt problems, OpenGL problems
<nemo> It was only recently that we even managed to get fullscreen to *work* in windows
<nemo> and we still have IFDEFs to work around issues
 * nemo sighs
<lifeless> well, $users :)
<nemo> lifeless: so it *is* users? It isn't microsoft astroturfing spreading to top entries in your software centre?
<nemo> lifeless: I wonder 'cause there's been increasing Microsoft astroturning on /.
<nemo> Admittedly the SNR on /. is not great, but the astroturfing for major companies is kind of obvious.  Long posts that appear the instant an article goes up
<nemo> eh. guess I'm being paranoid. still. sad.  hopefully quality of the reviews improves over time. I guess 12.04 has only been out for a month
<lifeless> I think there is a voting system :)
<nemo> lifeless: what I really want is a way to e-mail him to talk some sense
<nemo> but unfortunately google wasn't forthcoming :)
<nemo> lifeless: hm. something else I just noticed. total size on disc is totally wrong too
<nemo> looks like it isn't including hedgewars-data
<nemo> weird I thought it was correct before
<nemo> 8.5MiB instead of closer to... 150MiB I guess - the ogg files really take up space
<nemo> $ du -hs /usr/share/games/hedgewars/
<nemo> 122M	/usr/share/games/hedgewars/
<nemo> aaand 8.0M/usr/lib/hedgewars/
<nemo> ok. just 130MiB - still :)
<ion> Base-2 unit prefixes arenât very useful for us humans. :-P
<nemo> ion: eh? is all relative anyway. and 2^10 ~ 10^3
<nemo> anyway. nowhere near 8Â½MiB :-p
<pitti> Good morning
<doko> you're late this morning ;p
<pitti> hehe
<pitti> doko: are you still in Taipei, or also up early?
<doko> pitti, no Hongkong now
<pitti> ah
<pitti> doko: time for a quick python question?
<doko> sure
<pitti> doko: has it ever been discussed to provide a python version with --enable-valgrind?
<pitti> doko: e. g. could we at least build -dbg with it, if the runtime check is considered unnecessary overhead?
<pitti> without it, it's practically impossible to use valgrind to debug leaks in your extension, as python itself throws hundreds of those due to its own allocator
<doko> pitti, afaik, no. sure, that sounds doable. otoh, I would like to know how much it slows down the execution
<pitti> doko: I'm perfectly fine with only building -dbg with it
<pitti> doko: it incurs an extra check if the program is running under valgrind (not much, but might cost a few thousand cycles), and an extra "if" check on a boolean for every object allocation
<pitti> doko: do you know a standardized test for this? if not, I could just run the pygobject test suite with the two builds and compare the times
<pitti> doko: so if that hasn't been discussed, I guess I'll open a bug and do some performance comparison; would you prefer a Debian or LP bug?
<doko> pitti, let's do LP first. won't be for the next debian release anyway
<pitti> no? ok
<pitti> doko: danke
<larsduesing> Guten Morgen - Good morning :-)
<dholbach> good morning
<mvo> ev: hey, good morning! is there a way for errors.ubuntu.com to show me only report for the "last-seen" version? the top bug there should be fixed with 5.2.2.1 and I would love to see a stacktrace from the 5.2.2.1 version (if its really not fixed there)
<mvo> hey dholbach, good morning!
<dholbach> hey mvo
<ev> mvo: getting a stacktrace for a binary program for a specific version is impossible right now. We only ask for one per stacktrace address signature. However, it's definitely something to look at in the future.
<ev> mvo: I could make it so clicking on the "last seen" version takes you to a report for that version. mpt, what do you think?
<ev> mvo: we chatted about 5.2.2.1 last night. In precise, we still get reports from users where the running binary does not match the installed version (they upgraded while running). This is fixed in quantal (thanks pitti!) and being backported to precise.
<pitti> I'm preparing the SRU right now
<mvo> ev: oh, awsome
<pitti> unfortunately someone else than me still needs to verify bug 989698, to unblock precise-proposed for apport
<ubottu> Launchpad bug 989698 in apport (Ubuntu Precise) "Data collection progress window is still appearing post-release" [High,Fix committed] https://launchpad.net/bugs/989698
<mvo> ev: yeah, it would rock to be able to click on the latest ver and get taken to the stracktrace
<mvo> ev: and thanks pitti for this fix, that is a relief :)
 * mvo was a bit worried about a overlooked case in this fix
<pitti> mvo: actually, the fix only applies to signal crashes, not to Python stack traces -- is that a signal crash?
<mvo> its a python stack trace
<pitti> oh -- I'm afraid that's not fixed yet then
 * mvo nods
<pitti> just curious that people keep s-c open for such a long time
<pitti> this fix was actually aimed at things like gnome-settings-daemon, which run all the time
<pitti> and you might still have a 30 day old process running after upgrading twice in between
<mvo> yeah, indeed
<mvo> but for 5.2.2.1 the update is just 17h old, so that would explain why the frequency is still relatively high
<didrocks> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
 * dholbach hugs didrocks
 * didrocks hugs dholbach back
<dholbach> :)
<dupondje> didrocks should join https://launchpad.net/~dholbach-huggers/+members :p
<didrocks> dupondje: heh, kind of old good time ;)
<sladen> hug mob Prague?
<dholbach> :-)
<sladen> the interweb provides:  http://www.youtube.com/watch?v=4jzGIaZcGcM
<doko> micahg, ping
<mvo> ev: errors.ubuntu.com is already collecting quantal crashes I assume, right?
<mvo> ev: aha, unquestion, just found it I think
<didrocks> jamespage: hey, FYI, https://code.launchpad.net/~gleichsnerd/ubuntu/precise/mountall/fix-for-805509/+merge/107908 has been resubmitted, I guess you directly want to take it upstream, isn't it?
 * jamespage looks
<jamespage> didrocks, wrong james - you want jodh :-)  but I agree that it should go upstream
<jodh> didrocks: actually, no - mountall is a native package.
<vibhav> Could anybody nominate https://bugs.launchpad.net/ubuntu/+source/shogun/+bug/1006039 for natty ?
<ubottu> Launchpad bug 1006039 in shogun (Ubuntu) "missing libatlas-dev dependency for libshogun-dev" [Undecided,Fix released]
<pitti> that doesn't sound like a good SRU
<vibhav> HAVE_ATLAS triggers <atlas/clapack.h>
<vibhav> Which is in libatlas-dev
<vibhav> pitti: why?
<pitti> that's only necessary to build packages
<xnox> because you can easily fix it by doing $ apt-get install libatlas-dev
<pitti> and we won't start a mass rebuild in natty now
<xnox> vibhav: is missing that dependency causing other SRU's to FTBFS? Has the dependency been removed in Natty, since Natty was released? (Regression)
<pitti> if that was a problem, it would have come up by now
<vibhav> But a program using HAVE_ATLAs could get this problem
<pitti> again: trivial workaround, not a run time bug problem -> very far away from SRU criteria
<pitti> it's not worth spending anyone's time on this really
<jodh> didrocks: the mountall change looks good to me.
<vibhav> fine, thanks
<didrocks> jodh: do you want me to sponsor it?
<didrocks> jamespage: sorry for the wrong ping :)
<didrocks> hum, I can't push to lp:ubuntu/precise/qwt weirdâ¦
<jamespage> didrocks, np :-)
<pitti> didrocks: precise-proposed?
<didrocks> ah, the branch name as well, yep, didn't notice thanks pitti
<didrocks> pitti: can you mark https://code.launchpad.net/~l3on/ubuntu/oneiric/qwt/fix-921430/+merge/107534 and https://code.launchpad.net/~l3on/ubuntu/precise/qwt/fix-921430/+merge/107533 as merged or reject? I'll add a comment and push to the right branch
<pitti> didrocks: done
<didrocks> thanks pitti :)
<didrocks> pitti: it seems to only have worked on the precise MR, not the oneiric one: https://code.launchpad.net/~l3on/ubuntu/oneiric/qwt/fix-921430/+merge/107534
<pitti> didrocks: perhaps I mis-clicked; done
 * didrocks hugs pitti
<micahg> doko: pong
<didrocks> pitti: can you reject as well https://code.launchpad.net/~gleichsnerd/ubuntu/precise/mountall/fix-for-805509/+merge/107908 please?
<micahg> doko: I saw the E-Mail, I haven't gotten as far as a test build for Chromium 19 (having some issues with source generation), about to go to sleep, will try to have a look later toady
<micahg> *today
<jodh> didrocks: thanks for the offer, but I'd like to give that one a go if you don't mind?
<jodh> didrocks: oh - is there a problem with that mp?
<didrocks> jodh: no, I just merged into lp:ubuntu/mountall (it's your trunk, right?)
<didrocks> jodh: the target is wrong: lp:ubuntu/precise/mountall
<didrocks> jodh: but the manpage is now merged, I won't upload it and let you this pleasure ;)
<jodh> didrocks: ah, right. thanks! :)
<didrocks> yw ;)
<pitti> didrocks: done
<doko> micahg, ok, thanks
<mpt> pitti, sorry to bother you with administrivia, but could you reset the slope lines on the quantal burndown charts? The current lines start from before most work items were approved.
<mpt> (or tell me who I should badger about it instead:-)
<pitti> mpt: I can't, sorry; I have no access to status.u.c.
<pitti> mpt: cjohnston knows how the process works now
<mpt> pitti, ok, thanks. Will bug 1002828 be similarly a configuration problem rather than a bug?
<ubottu> Launchpad bug 1002828 in work-items-tracker "All ubuntu-precise burndown charts are squashed and the target date is wrong" [Undecided,New] https://launchpad.net/bugs/1002828
<cjwatson> mpt: cjohnston told me that we'd do this at FeatureDefinitionFreeze; the release schedule says that's tomorrow
<pitti> right, was just going to suggest taht
<pitti> we should just trash the db
<pitti> it's rather late in the cycle to do that, but better than starting with totally wrong WIs
<mpt> I don't see anything wrong with the WIs, just with the slope lines
<mpt> oh, if you mean start from a new zero date for Quantal
<pitti> right
<mpt> makes sense
<pitti> well, trash the db so that we discard all the history
<cjohnston> I'm slightly confused.. I'm trashing the quantal db for feature def freeze...
<geser> do we get dpkg >= 1.16.2 for quantal?
<cjohnston> I don't think doing that with precise will provide the desired output
<cjohnston> The precise issue, I believe, is because we are still running the scripts for the precise release cycle
<cjohnston> and so it picked up the further milestones
<pitti> righth, that'll require some db surgery to remove again
<cjohnston> we have to fix the process by which we run the scripts to where we arent doing all releases prior to doing anything with precise
<micahg> geser: as soon as someone sorts out how to not break the world with the upgrade
<pitti> and I think we can just stop this; it's taking many hours a day for little (or even negative) purpose
<cjohnston> pitti: there are some backups, so I will maybe be able to figure out how to get back close to what it should be
<cjohnston> pitti: the issue is because we want to be able to change the config files at will, IS wrote a script that pulls the bzr branch with the configs, then runs the all script
<cjohnston> so the script needs to be rewritten to where the config files that it runs are defined somehow
<pitti> right, the precise config should be renamed to .disabled or so
<infinity> micahg: Not much to sort out except migrating dpkg.cfg multiarch configs to the New World Order...
<cjohnston> that wouldnt have any effect on the site or the data that is already there pitti ?
 * infinity wonders if he just volunteered to do this.
<pitti> cjohnston: in addition to the db surgery
<micahg> infinity: right, but someone has to do it (and I thought you already volunteered)
<infinity> micahg: Oh, did I?  In that case, I should do that. :P
<cjohnston> pitti: right.. but not a negative effect on the actual site as it sits today
<cjohnston> if so, would you mind making that change to all of the config files in the branch except quantal and summit-2012?
<penguin359> hello
<infinity> geser: I guess the answer is that we get a new dpkg when I do the migration. :P
<penguin359> I'm looking to work on an issue in network-manager, but I am getting lost in the various branches on launchpad.net
<mpt> penguin359, cyphermox is the person to ask about that
<cjwatson> infinity: *applause*
<penguin359> It looks like lp:network-manager represents a branch of the upstream version
<pitti> penguin359: if you want to work on the upstream branch, I recommend using http://cgit.freedesktop.org/NetworkManager/NetworkManager/ instead
<pitti> penguin359: that way you can use format-patch for upstream submission, and have the current version
<penguin359> pitti: no, it's a file only in Ubuntu.
<penguin359> I'm trying to figure out what the packaging branch is
<pitti> penguin359: if you want to work on the package, use "debcheckout network-manager" to get the right branch
<pitti> penguin359: see Vcs-Bzr: field on apt-cache showsrc (that's what debcheckout uses)
<cjohnston> pitti: are you ok with that?
<pitti> cjohnston: you mean disabling all non-current files? sure, I think that's what I used to do back in the days
<cjohnston> ok.. great.. thanks.. I'm off to dinner in a few minutes.. :-)
<pitti> cjohnston: committed
<cjohnston> thanks pitti
<cjohnston> I'll try working with IS to see if there is a good db backup
<cjohnston> any idea when the change happened so that I can try to find one after release but before the change that broke the charts?
<pitti> I'd use the release date, April 28
<pitti> cjohnston: i. e. end of april/may 1 or so would do fine
<cjohnston> ok.. I don't think they are doing daily backups, so I'll look around but after that time..
<pitti> if not, we can apply a little sql
<cjohnston> :-)
<cjohnston> I'd also be quite interested in seeing how much of a change there is to the update time
<penguin359> Doesn't Vcs-Bzr: represent the most current version that is on it's way to become Quantal?  What would I checkout if I was working on a patch for Lucid that no longer applies in more recent Ubuntu releases?
<infinity> penguin359: If in doubt, apt-get source on lucid.
<infinity> penguin359: (There may or may not be lucid branches for everything, but the archive is authoritative regardless)
<penguin359> I do regularly use apt-get source for modifying packages for my system, but that has always been for private use and hasn't involved source control.  I'm trying to better understand the various release patterns and branches now that I am working on patching a bug that might affect others in my situation.
<penguin359> I can just produce a patch with that, but I recently tried using Bazaar and I got a disapproval mentioning that I applied it to the wrong branch.
<didrocks> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> penguin359: we don't really have a good story for old stable branches so far; debdiffs should always work and be appreciated for sponsoring
<pitti> penguin359: if you find someone who tells you "I won't sponsor that debdiff, do a branch instead", there's something wrong
<pitti> (particularly for an SRU)
<penguin359> ok, thankx
<penguin359> Could you take a quick look at http://bit.ly/Kb5DpC and tell me what he's referring to as the packaging branch?
<penguin359> I thought he meant lp:~network-manager/network-manager/ubuntu, but that looks like what I used in the first place
<pitti> penguin359: yes, that comment seems wrong
<pitti> penguin359: I suggest to ping cyphermox about it, that MP looks fine
<penguin359> ok
<infinity> ogra_: So, regarding f-k... If you're willing to clean up the mess, let's just sync it.
<infinity> ogra_: But clean fast. :P
<ogra_> well, i planned to at least have omap, ac100 and omap4 for A1 ...
<ogra_> in the realese meeting we said arm is a nice to have for A1, so everything extra would be fine but missing it wouldnt be a disaster
<infinity> Yeah, I wasn't sure we'd make the live switch by A1 anyway.
<ogra_> i just dont want to inverst a minute in the old f-k after switching to live ... that would be waste
<infinity> But syncing/merging f-k is a good first step.
<ogra_> yeah
<infinity> Alright.  Sync away, then.  I'll just become remarkably silent here in HK if it explodes. ;)
<ogra_> k, i'll try to have it in by EOD
<ogra_> HK uses quantal images ?
<infinity> If you're just syncing, we can have it in by.. Now.
<ogra_> well, i cant sync, can just file a bug :)
<infinity> ogra_: No, I just mean that I'll ignore you when it breaks. ;)
<infinity> ogra_: Sure you can.
<ogra_> oh, thats fine ...
<ogra_> i can ? you mean i can do more than running requestsync ?
 * ogra_ wasnt aware 
<infinity> ogra_: syncpackage --force -d unstable flash-kernel
<ogra_> oh my
<ogra_> how did i miss that
<ogra_> oh, probably because i never use ubuntu-dev-tools :P
 * ogra_ installs 
<infinity> Pretty sure that works off of upload rights, not queue permissions.  You can tell me if I'm wrong. :P
<cjwatson> You're correct.
<cjwatson> ogra_: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-January/000923.html
<ogra_> cjwatson, yeah, i remember having read that, but u-d-t has such a lot of messy deps i never use
<infinity> Even with --no-install-recommends?
<cjwatson> Meh, most of the heavy ones are Recommends.
<infinity> I didn't think it was that bloated...
 * infinity looks.
<ogra_> 43M here
<cjwatson> The Depends are sane enough.
<ogra_> better than devscripts for sure
<cjwatson> Mostly stuff you'd have on a development system (at least one with launchpadlib) anyway.
 * ogra_ doesnt want an MTA on his ac100 ...
<cjwatson> ubuntu-dev-tools Depends: devscripts ;-)
<infinity> devscripts is also really lightweight with --no-install-recommends.
<ogra_> argh !
<ogra_> so let me install devscripts first omitting recommends
<cjwatson> But yeah, with --no-install-recommends I wouldn't expect either to pull in an MTA.
<ogra_> it wouldnt be that annoying if the apt option wouldnt be half a novel to type :)
<infinity> It's muscle memory here.
<ogra_> if it actually becomes muscle memory i would start using a config option
<ogra_> ;)
<ogra_> though we dont have the inverse of this option, do we ?
<infinity> Nah, I like to try without the switch first, see what it wants, then do the opposite. :P
<ogra_> heh
<infinity> --install-recommends may well exist to invert configs.
<cjwatson> It does seem like a good case for a short option.  I think -r is unused.
<infinity> Dunno, never tried.
<cjwatson> infinity: I think it does, yes.
<cjwatson> cmdline/apt-get.cc:3464:      {0,"install-recommends","APT::Install-Recommends",CommandLine::Boolean},
<ogra_> aha
<ogra_> phew, what a changelog
<geser> and there is also "apt-get install --fix-policy --install-recommends" to fix it afterwards
<ogra_> heh, even more typing
<Laney> and you can apt-get install foo bar- to negate a specific recommends
<infinity> Laney: Or apt-get remove foo+ bar JUST TO CONFUSE YOURSELF.
<ogra_> haha
<Laney> that works?!?!?!
<ogra_> anyway, time for an announcement mail, i wonder if ubuntu-devel is enough
<infinity> ogra_: More than enough.
<ogra_> k
<infinity> ogra_: As is usually the case with such announces, the people who read it won't care, and the people who need to know won't read it. ;)
<geser> Laney: of course that works, apt has super cow powers
<ogra_> heh, indeed, i even doubt they are subscribed to u-d
<ogra_> but at least i have something to point to if someone complains
<xnox> ogra_: "But Mr Dent, the plans have been available in the local planning office for the last nine months."
<xnox> -- Quotes From Hitchhiker's Guide To The Galaxy
 * ogra_ has his towel 
<ogra_> so dont panic ;)
<dupondje> Hi, when do we create a -dbg package? Are there some defaults for this ?
<hallyn> jdstrand: as far as you know is there anything under /proc/device-tree that qemu under libvirt shouldn't read?  (bug 1006149)
<ubottu> Launchpad bug 1006149 in libvirt (Ubuntu Quantal) "PowerPC needs access to /proc/device-tree/ in apparmor perms" [Medium,Triaged] https://launchpad.net/bugs/1006149
<cjwatson> dupondje: It's up to each package.
<cjwatson> dupondje: I'd recommend only doing so when the -dbg package is built in a different build pass with some different configure or compiler options.  Otherwise, the automatically-generated -dbgsym packages on ddebs.ubuntu.com are usually adequate.
<dupondje> cjwatson: oh ok, didn't know there were auto-generated
<dupondje> thats fine enough indeed
<jdstrand> hallyn: no, I don't. the 'davis' porting machine has /proc/device-tree
<jdstrand> hallyn: if libvirtd needs access to /roc/device-tree, that is fine, but the bug is asking for libvirt-qemu to be updated, which is every guest
<jdstrand> hallyn: we have quite restricted files for guests, so I would prefer that only specific entries or limited globs to libvirt-qemu be added
<jdstrand> hallyn: in other words, demonstrated denials
<hallyn> jdstrand: ok, thanks
<hallyn> i wonder if device-tree will ever show up on x86 (if not i guess this minimizes the worry at least a bit)
<jdstrand> I doubt it. I see /proc/device-tree/openprom
<jdstrand> but that is just a hunch
<mterry> didrocks, heyo.  Can I bug you for a review of that quickly branch sometime this week?
<mterry> pitti, does apt-cache rdepends not cover build-depends?
<xnox> mterry: no. use reverse-depends from ubuntu-dev-tools
<mterry> xnox, ah, thanks!
<didrocks> mterry: yeah, it's in my TODO :)
<didrocks> mterry: sorry, just had a meeting
<mterry> didrocks, no probs!  thanks!
<didrocks> mterry: probably tomorrow will be the day!
<henrix> cjwatson: sorry to bother you again, but it looks like there are still some kernel pkgs in universe...
<cjwatson> henrix: let me recheck
<henrix> cjwatson: thanks
<cjwatson> henrix: I can't find them - can you give me examples?
<cjwatson> Or a list
<henrix> cjwatson: 1 sec
<henrix> cjwatson: for example: block-modules-3.0.0-21-generic-di 3.0.0-21.35~lucid1
<henrix> cjwatson: you can have the complete list on bug #1005456
<ubottu> Launchpad bug 1005456 in linux-lts-backport-oneiric (Ubuntu) "linux-lts-backport-oneiric: 3.0.0-21.35~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1005456
<cjwatson> Oh, lucid
<henrix> ah, right... yesterday i may have referred oneiric only :-/
<cjwatson> henrix: Fixed, sorry about that
<henrix> cjwatson: thanks a lot
<bdmurray> pitti: where is the code for the pending-sru page?
<cjwatson> bdmurray: sru-report in lp:ubuntu-archive-tools
<cjwatson> In fact it says that in the HTML
<bdmurray> cjwatson: heh, thanks
<bdmurray> cjwatson: is there no API way to get the queue count?
<cjwatson> >>> ubuntu = lp.distributions["ubuntu"]
<cjwatson> >>> quantal = ubuntu.getSeries(name_or_version="quantal")
<cjwatson> >>> len(quantal.getPackageUploads(status="New"))
<cjwatson> 4
<cjwatson> Like that you mean?
<bdmurray> cjwatson: exactly, thanks
<PaoloRotolo> Hi all!
<cjwatson> bdmurray: wow, I had no idea it was screen-scraping that
<bdmurray> cjwatson: I'll have a branch in a bit
<bdmurray> cjwatson: the count also includes backports which I'd like to exclude
<Laney> you can supply pocket too
<cjwatson> bdmurray: hm, not sure about that, we should be able to process all the backports more or less immediately and if we aren't doing so that's kind of rubbish
<cjwatson> separate table or something maybe?
<bdmurray> but is the SRU report not backports report
<cjwatson> true but we have so many reports as it is ...
 * cjwatson isn't going to look at another one, realistically
<bdmurray> okay, it should be easy to separate them out anyway
<cjwatson> I dunno, it's kind of cheesy I know but it's handy
<jdstrand> @pilot on
<udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<jdstrand> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<jamespage> doko, when you are around please could you review the openjdk-7 debdiff on bug 888129?
<ubottu> Launchpad bug 888129 in xmlgraphics-commons (Ubuntu Quantal) "xmlgraphics-commons version 1.4.dfsg-3ubuntu1 failed to build with openjdk-7" [High,In progress] https://launchpad.net/bugs/888129
<jamespage> I've tested it locally and it fixes this bug and bug 888123
<ubottu> Launchpad bug 888123 in openjdk-7 (Ubuntu Quantal) "erlang version 14.b.2-dfsg-3ubuntu2 failed to build with openjdk-7" [High,In progress] https://launchpad.net/bugs/888123
<stgraber> kees: heya, just noticed that hardening-includes uses readelf but doens't depend on binutils (lxc containers really don't contain much by default ;))
<slangasek> why are you using hardening-includes without build-essential?
<stgraber> for hardening-check
<stgraber> I'm doing a quick sru verification of bug 986314
<ubottu> Launchpad bug 986314 in squid3 (Debian) "squid3 missing pie and bind-now hardening options" [Unknown,New] https://launchpad.net/bugs/986314
<slangasek> ah
<stgraber> and the test case uses hardening-check which I installed in my test container but failed because it tries to call readelf which I don't have :)
<mterry> mvo, hello!  Got a moment to talk about "update-manager --no-update" ?
<bdmurray> pitti: your precise apport -proposed upload doesn't mention bug 1002535 which is included in the changelog
<ubottu> Launchpad bug 1002535 in apport (Ubuntu Precise) "'not a debian format' package install failures should be Unreportable" [Medium,Triaged] https://launchpad.net/bugs/1002535
<mvo> mterry: I'm about to call it a day, is it urgent? could we do it tomorrow your morning maybe?
<mterry> mvo, sure, no rush
<mvo> thanks!
<mvo> mterry: please ping me when you go online, I should be around and have time then
<mterry> mvo, ok
<mvo> ta
<mterry> mpt, what is your opinion of the badge on the update-manager launcher icon that shows the number of updates?  The new design seems to de-emphasize the specific number elsewhere
<mvo> mterry: no opinion, I'm fine killing it
<mvo> mterry: if mpt thinks that is the right way forward
<mterry> mvo, cool
<slangasek> lool: timezones notwithstanding, would you be able to verify the correctness of my SRU change for bug #986183?
<ubottu> Launchpad bug 986183 in update-notifier (Ubuntu Precise) "Broken timedate handling for failed hook runs" [Medium,Fix committed] https://launchpad.net/bugs/986183
 * xnox today I learned $ man dh-exec
<slangasek> it's total crack, but it's tasty crack :)
<seb128> slangasek, other SRU people: did you read my comment about emailed about the (new) SRU rules?
<seb128> (that was yesterday)
<slangasek> seb128: yes, I am drafting a mail
<seb128> slangasek, thanks
<seb128> slangasek, I got several other people a bit puzzled about the change again today, it will be good to have some public email out ;-)
<slangasek> well
<seb128> slangasek, will spare work on both sides
<slangasek> it's a change to enforce the rules that were always documented
<slangasek> so I'm not too sympathetic towards people not knowing these were the rules - but yes, a mail will save us all time in the end :)
<seb128> slangasek, right, well the rules were not enforced for years so people are surprised that what they have been doing for ages get bounced back from one day to the next one
<seb128> slangasek, I've to admit I prefer less paperwork, I liked better when we were focussed on getting things done rather than on writing but I guess we need a balance there ;-)
<bdmurray> seb128: the test cases make the getting the verification done easier
<seb128> bdmurray, right, the "[Stable Fix] section pointing out a minimal patch applicable to the stable version of the package" just doesn't make sense to me though for example
<seb128> is that "attach the debdiff to the bug"?
<seb128> if so it's weirdly formulated
<slangasek> seb128: that section is going away
<slangasek> as part of the mail I'm drafting :)
<seb128> slangasek, well it's being asked on bugs which get commented on this week
<slangasek> it is?
<seb128> well the comment point to that wiki
<seb128> https://wiki.ubuntu.com/StableReleaseUpdates
<slangasek> well, yes
<slangasek> but the comment doesn't say that you need to add that section, does it?
<slangasek> I will fix the wiki and send out mail
<seb128> let me read it again ;-)
<bdmurray> and if the comment needs fixing after the email I'll fix it
<seb128> " To be more succinct, make sure the bug description lists these
<seb128> fields: "Impact, Dev Fix, Stable Fix, Regression Potential, Test case"."
<seb128> slangasek, ^ that's what the comment says
<seb128> so yes, it does
<slangasek> ah
<seb128> well those were comments from SpamapS
<bdmurray> right and I don't think he made the UDS session where this change was discussed
<slangasek> right
<bdmurray> we should all be on the same page real soon now
<seb128> slangasek, and to fair I've no clue wat to write in "stable fix" out of copying the diff inline ... good to know it's being addressed ;-)
<slangasek> SpamapS: ^^ so we should probably brief you on the changes to ubuntu-sru, rather than you reading about it on ubuntu-devel-announce ;)
<seb128> bdmurray, slangasek: thanks
<seb128> it's a bit backward that those rules are randomly applied before the SRU team got the documentation updated
<seb128> or its things together
<seb128> seems a bit backward
<seb128> doh, I already said that :p
<seb128> well anyway enough on the topic from me, thanks for addressing the issues ;-)
<SpamapS> slangasek: that would be great. :)
<SpamapS> I'm just going by the wiki page. 
<SpamapS> The dev/stable fix is only necessary if the bug has to be fixed in different ways.
<SpamapS> I would love for there just to be a "Fix" section which just asks the developer fixing the issue to explain what their intended fix is.
<slangasek> SpamapS: the changes are to drop the 'development fix' / 'stable fix' sections in favor of release tasks; clarify 'regression potential' so that it's focused on giving testers information about what parts of the package might warrant additional regression testing; relaxing the requirement for a distinct 'impact' header since this should be the bug description
<slangasek> also, based on cjwatson's feedback, I think we're going to relax the requirement for uploader & verifier to be separate people, so long as there's a solid test case write-up
<SpamapS> slangasek: Fantastic. So basically, everything that I use to make decisions, has been sprayed out to different parts instead of put in a succinct place in the description?
<slangasek> this is mostly of concern to cjwatson due to the complexity of testing installer SRUs, but probably benefits SRUs for other packages too
<slangasek> SpamapS: hmm, walk me through how these help you make decisions, please?  The SRU team members who were in the room didn't think these changes were a problem
<SpamapS> The requirement for fixer/tester to be different has never been specified in strong wording anyway, so that part makes sense.
<slangasek> indeed, most of the time we don't have this information *anyway* in SRU bug descriptios
<SpamapS> slangasek: I use the fields to decide whether or not the diff is even worth looking at.
<SpamapS> slangasek: low impact bugs with a poorly specified test case or high regression potential should be rejected.
<slangasek> SpamapS: oh, I agree - and the test case is the one absolutely mandatory section
<SpamapS> The description is often "It 'sploded when I poked it"
<slangasek> the regression potential section, there was concern that having the uploader write this may often not be useful
<SpamapS> Impact is clear, users affected by this will be in state X until the fix is made.
<SpamapS> Really? I think thats the most useful field for me during SRU review.
<slangasek> right - AIUI the agreement was that we would require clear bug descriptions, but not enforce an "impact" header
<SpamapS> It helps me evaluate that the uploader actually understood the diff
<slangasek> hmm
<slangasek> so you find good [regression potential] sections being written?
<SpamapS> slangasek: basically I don't want to have to understand *everything* about the package before I evaluate the diff .. all of those fields give me an idea of what the uploader is thinking.
<slangasek> anyway, we're not proposing to drop that one
<slangasek> merely clarifying the language to say that the *purpose* of the section is to give guidance for testers
<SpamapS> Its also about making the uploader stop and think about it.
<slangasek> agreed
<SpamapS> If I stopped and started writing regression potential "Well I'm not really sure how many things use this API call but probably not many" .. I'd feel like an idiot and go figure out how many things make that call.
<slangasek> I just think we get better results if we frame the question in terms of what areas should be focused on for regression-testing
<slangasek> I've certainly seen SRUs where people claimed "regression potential: none"
<SpamapS> hah yeah
<SpamapS> so did nobody get my message to ubuntu-devel where I said I'm going to start holding people to these fields?
<SpamapS> because that was like, 2 weeks ago and I basically said "I'm going to hold people to the standard that was mostly thrown away at UDS" ;)
<SpamapS> hm I don't see it in the archives
<slangasek> anyway, I think the net outcome here is that we should get better SRUs, by a combination of enforcing the requirements up front and trimming the fat from these requirements to focus on the things that aren't just paper-pushing (i.e., development fix/stable fix)
<SpamapS> maybe it got eaten
<slangasek> heh, apparently not ;)
<slangasek> are you ok with dropping the development/stable fix sections?  I don't think it adds anything at all to have people write this up
<slangasek> instead of having bug tasks
<SpamapS> I am ok with folding them into one thing.
<slangasek> why should there be a thing for it at all?
<SpamapS> I'd still like for the bug to state clearly "The intended fix is X"
<slangasek> well
<SpamapS> so if the patch does something else, I can quickly reject and move on. ;)
<slangasek> this hasn't been enforced in practice because there's not a consensus in the SRU team that this is useful
<slangasek> I think we do have consensus that the other sections are useful
<SpamapS> Basically, I think we need to crowd-source a lot of the "orienting yourself around the fix", rather than making the SRU team members grok every bit of every patch
<Daviey> awesome.
<SpamapS> Yes I *can* understand a debdiff without any of those fields
<SpamapS> and I can sit and think about the regression potential
<SpamapS> and even figure out a test case on my own
<SpamapS> but there aren't many of us
<SpamapS> slangasek: I wasn't available for the discussion, so I defer to those who hashed it out. I'm fine with the changes, but I think it will put a tiny bit of extra burden on the SRU team that is not necessary.
<slangasek> dropping the 'regression potential' field is not on the table
<slangasek> SpamapS: well, those who were in the room felt that this will *remove* burden from the SRU team compared to where we are today, because of the poor enforcement of the requirements to date... so I'm hoping to prove you wrong and show that we've found a good balance :)
<SpamapS> slangasek: indeed, I think the only thing that actually needed to happen was just to enforce more.. but removing fields is fine
<vsingh165> anyone here know how to branch to source without using bazaar?  I'm trying to fix a bug in Nautilus (#822993 in Launchpad), and bazaar is not grabbing the latest source (it's many versions behind).
<vsingh165> I'm quite new to all this packaging stuff.
<jtaylor> apt-get source nautilus?
<jtaylor> or if for a different distro, pull-lp-source package distro
<jtaylor> s/distro/series/
<vsingh165> I'm working on precise...is there a way to force bazaar to get the latest source?
<jtaylor> what are you currently trying?
<jtaylor> bzr branch lp:ubuntu/nautilus should get the newest source
<vsingh165> I'm trying just a simple bzr branch ubuntu:nautilus
<vsingh165> but it's saying that it's out of date
<micahg> vsingh165: http://package-import.ubuntu.com/status/nautilus.html#2012-02-17%2010:22:13.701084
<vsingh165> micahg:  yes,  I saw that earlier and didn't know what to make of it.  I kind of wish there were non-bazaar bug fixing instructions on the wiki.
<micahg> anyways, that's not the canonical branch for nautilus, it's https://code.launchpad.net/~ubuntu-desktop/nautilus/ubuntu
<vsingh165> jtaylor: it's still fetching out of date.
<micahg> vsingh165: you want debcheckout nautilus
 * micahg wonders if that would DTRT even though
<vsingh165> micahg:  so now I just use the ubuntu-desktop:nautilus branch?
 * micahg has no idea if that'll work, but that's the branch for quantal
<vsingh165> hmm let me try it.
<vsingh165> that's not what I wanted...now I don't see any of the source files I got earlier using ubuntu:nautilus branch.
<vsingh165> I wonder if I could just debcheckout and somehow add a diff to a bug.
<kees> stgraber: ah! good catch, I'll fix that.
<stgraber> kees: thanks
 * kees wonders if it should dep on binutils or build-essential
<stgraber> kees: well, for hardening-check I don't see a reason to have the rest of build-essential, though maybe there are other tools in there that do require build-essential
<kees> hardening-check itself should be just the compilers. hardening-includes ... yeah, just binutils. cool. Will upload to unstable.
<seb128> slangasek, SpamapS: reading the backlog, I would welcome one of you explain me what "regression potential" is supposed to be ... I basically use it as "it's a gtk upload, it can virtually break your entire desktop if the lib is broken"
<seb128> slangasek, SpamapS: but I'm not sure it's an useful info in a SRU with 3 patches backported
<jdstrand> james_w: hi! can you mark https://code.launchpad.net/~jtaylor/ubuntu/precise/python-tornado/CVE-2012-2374/+merge/106863 as done? (the fix was in a security update last week)
<ubottu> CRLF injection vulnerability in the tornado.web.RequestHandler.set_header function in Tornado before 2.2.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via crafted input. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2374)
<jtaylor> done ^
<slangasek> seb128: what's most helpful is some analysis of what kinds of problems are likely to occur if there *is* a bug in the patch
<jdstrand> jtaylor: thanks
<bdmurray> slangasek: does this seem right for an re regarding update-grub failures?
<bdmurray> ug_failure = 'User postinst hook script \[(/usr)?/sbin/updaate-grub\] exited with value [1-9]+'
<hallyn> hey - i'm looking at bug 994212 . users who don't use /etc/network/interfaces have autofs failing to start, bc it starts on runlevel [2345].  Do we call that abuse, or is there a way to work around it?
<soren> bdmurray: "updaate"
<ubottu> Launchpad bug 994212 in autofs5 (Ubuntu) "ldap fails to start when /etc/network/interfaces not used" [High,Confirmed] https://launchpad.net/bugs/994212
<bdmurray> soren: thanks fixed when testing but not in code - odh
<hallyn> is static-network-up emitted when networkmanager starts up a nic?  (i assume not)
<hallyn> jodh: ^
<stgraber> hallyn: no
<stgraber> hallyn: with NM static-network-up is emitted when the loopback interface is up IIRC
<hallyn> is anything?
<soren> hallyn: Yes.
<soren> net-device-up
<soren> hallyn: NetworkManager calls /etc/network/if-up.d/*
<soren> hallyn: See /etc/NetworkManager/dispatcher.d/01ifupdown
<stgraber> hallyn: basically any time an ifup call is made, the ifupdown upstart script checks whether all "auto" interfaces defined in /etc/network/interfaces are up, if they are, then it sends static-network-up
<stgraber> on a desktop system, the only interface you have in /etc/network/interfaces is the loopback interface, so as soon as the loopback is brought up, you should get static-network-up
<slangasek> bdmurray: it won't match any failures when update-grub is triggered from the old /etc/kernel-pkg.conf, but that should never happen nowadays; it also won't catch cases of update-grub invocations from other maintainer scripts; but if there are any of those they're probably in the minority
<stgraber> cjwatson: I'm told we're some interesting things in the TB mailing list queue, can you let them through?
<hallyn> I dunno, maybe the bug is just that automount should adapt to a nics-go-up-and-down world
<hallyn> soren: thanks, I guess I knew the base net-device-up, but was looking for a 'default route is up' signal
<bdmurray> slangasek: ah, postrm makes sense too
<hallyn> but really that doesn't seem like the right fix anyway
<hallyn> do we have anyone babysitting automount?
<slangasek> hallyn: well, provided that the bug isn't that the system is configured with user-level NM profiles (in which case you might have a circular dependency), yeah, it's probably autofs's problem
<slangasek> we do not
<slangasek> bdmurray: ah, sure
<hallyn> ok, thanks
<bdmurray> pitti: to be fair regarding apport and precise -proposed I think I fixed it and then reported the bug for precise
<nemo> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/795038/comments/10 - "integrated menus in the titlebar"  - does that actually exist in 12.04 ?
<cjwatson> stgraber: just the one after I'd ditched MP spam and actual spam, but yeah, moderated
<ubottu> Launchpad bug 795038 in unity (Ubuntu) "Using GIMP in Unity is troublesome & unintuitive " [Low,Invalid]
<larsduesing> jamespage: may I ask you for help with merging aiccu from debian-sid to ubuntu-quantal?
<jamespage> larsduesing, sure
<larsduesing> I tried it word for word after documentation: https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/+merge/107823
<larsduesing> but: in the ubuntu-bzr there are many file in directory .pc - which I do not think should be there...
<larsduesing> files
<larsduesing> (and merge killed them...)
<cjwatson> presence of .pc is correct
<larsduesing> ouch
<cjwatson> (modulo design disagreements; but it's the intended behaviour right now)
<larsduesing> so my merge is incorrect?
<cjwatson> if you deleted .pc, then yes it is
<larsduesing> I did not
<larsduesing> but bzr merge did
<larsduesing> apparently
<larsduesing> i did bzr merge debianlp:sid/aiccu
<geser> .pc/ is created/used by quilt
<larsduesing> yes
<cjwatson> ok, I'm not going to look this up on my phone.  but the intended invariant is that the bzr branch should match the result of creating a source package from that branch and then unpacking it (dpkg-source -x) somewhere else, including dotfiles, possibly excluding .bzr* differences
<larsduesing> cjwatson: nobody asks you for wonders :-)
<jamespage> larsduesing, if you apply all the quilt patches and add the .pc folder to bzr it should be OK
<dobey> bzr merge removing the .pc makes sense to me
<cjwatson> if it's a 3.0 (quilt) format package then it's possible you'll have to quilt push -a after the merge
<jamespage> I think that when you bzr merge it unapplies the patches
<jamespage> but does not re-apply them
<larsduesing> Oh
<jamespage> ah - I see we all think the same
<cjwatson> dobey: I am aware that there are design disagreements here, but that's not helpful
<dobey> right
<dobey> cjwatson: i'm not arguing about the design disagreement issues :)
<larsduesing> So the bzr-branches are fully patched.. *learn*
<dobey> cjwatson: i think the patches get unapplied when merging in bzr, as jamespage said
<cjwatson> it's a bug that bzr merge doesn't put the branch back into a state where you can commit something that can validly be merged
<larsduesing> ok, so I kill that branch
<larsduesing> do another merge
<larsduesing> and qult push -a
<dobey> cjwatson: but it does, unless it also deletes the patches themselves, which as i understand, it does not
<slangasek> larsduesing: 'bzr merge' unapplies patches; you then need to 'QUILT_PATCHES=debian/patches quilt push -a'
<larsduesing> and then bzr push
<slangasek> then bzr add .pc/* .pc/*/*
<cjwatson> my understanding of jelmer's changes was that they were supposed to cause merge to leave things as it found them
<jamespage> larsduesing, I think that if you just apply the patches in the current branch and then re-push it will be OK
<slangasek> (this is unfortunate and something to fix for this cycle)
<cjwatson> i.e. unapplied if that's how things started, applied if that's how things started
<larsduesing> Guys, I didn't want creating religious wars :-)
<cjwatson> if it's not doing so, I think that's a bug, because it's misleading people
<slangasek> I don't think there's any religious war here, just vehement agreement that there's a bug
<cjwatson> the intent of that set of changes was to *reduce* confusion ...
<jelmer> cjwatson: that is intention, if it doesn't do so that's definitely a bug
<jelmer> *the
<jelmer> I'd love to hear more about it :)
<larsduesing> Fine, who's filing a bug against quilt, bzr or whatever is the bad guy? *g*
<cjwatson> jelmer: maybe larsduesing can provide you with a test case then :)
<dobey> jelmer: would the merge then fail, if the patches failed to apply against the newly merged changes?
<slangasek> jelmer: right, there's definitely a bug then, because 'bzr merge' always leaves the quilt patches unapplied
<slangasek> and then if you apply them by hand, it shows the .pc files from :other as removed + added :(
<cjwatson> dobey: that's a conflict of some kind, surely - at least logically
<larsduesing> if I would be an author, I should write a book "learing ubuntu-devel - pitfalls and super community" or such :)
 * micahg would think that would make a nice appendix to the packaging guide
<dobey> cjwatson: perhaps, but the workflow introduced, or rather, enforced, by such a behavior, doesn't seem logical to me. :)
<larsduesing> Ahem, short questionaire: Anybody wants this merge as test-case?
<cjwatson> dobey: given the on-disk format is quilt, I'm pretty sure I'd want it to stop and let me walk my way up the stack, whether that be presented in terms of raw quilt operations (which I'm quite happy with personally) or bzr looms or whatever
<larsduesing> If not, I will do re-push with quilt in the same bzr-tree
<jdstrand> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> larsduesing: you don't lose the test case - just remember the URLs and revision numbers of the branch you started with and the branch you attempted to merge in
<cjwatson> the test case doesn't get invalidated by pushing more revision on top
<cjwatson> *revisions
<larsduesing> ah, yes... there was some sense for a versioning system *head->desk*
<larsduesing> :)
<dobey> s/remember/stick in the bug report/ :)
<larsduesing> dobey: Whoever does this report - I don't think I'm deep enough in the problematic parts here :)
<xnox> slangasek: cjwatson: larsduesing: my favourite bug in the new handling is 1.0 packages with quilt patches - bug 999586
<ubottu> Launchpad bug 999586 in bzr-builddeb "should not do any quilt patching for 1.0 source format" [High,Triaged] https://launchpad.net/bugs/999586
<dobey> larsduesing: well surely you can file a bug report about the problem you're seeing. you don't need to explain the deep technical parts or where the problem is exactly in code
<dobey> larsduesing: you can file a bug against udd and just say "The patches are unapplied, but not reapplied, when i merge branch X into a local copy of branch Y."
<larsduesing> dobey: My problem begins at against which package should I file a bug? quilt? bzr? bzr-builddeb?
<jelmer> larsduesing: bzr-builddeb
<larsduesing> ok
<dobey> ah ok, that works. i was going to say udd :)
<larsduesing> udd?
<cjwatson> ubuntu distributed development
<cjwatson> but jelmer's authoritative here
<larsduesing> oh
<larsduesing> https://bugs.launchpad.net/bugs/616791
<ubottu> Launchpad bug 616791 in bzr-builddeb (Ubuntu) "merge mode should automatically apply patches for 3.0 (quilt) sources" [Medium,Fix released]
<hallyn> I suppose a hacky way to fix the automount bug woudl be to just make it 'start on runlevel [2345] or net-device-up', so it quietly restarts if it failed at runlevel 2
<larsduesing> bug filed:
<larsduesing> https://bugs.launchpad.net/bzr-builddeb/+bug/1006611
<ubottu> Launchpad bug 1006611 in bzr-builddeb "quilt patches are not reapplied after merge with debian" [Undecided,New]
<larsduesing> https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge
<larsduesing> it keeps telling review diff without .pc - but branch is with
<cjohnston> pitti: we are able to go back to hourly status updates
<cjohnston> skaet: ^
<larsduesing> so, going to bed... <6 hours of sleep in front of me... Good night everyone, and thanks!
<cyphermox> larsduesing: will review aiccu later on (or tomorrow morning my time), unless somebody beats me to it
<david> may i speak with an ubuntu devoloper?
<larsduesing> cyphermox: take your time... thanks
<larsduesing> david: what's your problem? Here are divisions of developers :)
<david> i am a visually impared user trying to use ubuntu 12.04
<david> my problem is that the orca screen reader and magnifyer  is really no good
<david> i was wondering if their was an easy way to get compiz enhanced zoom desktop to work in unity
<larsduesing> david: A quick look says to me, in 12.04 this problem should be already fixed...
<larsduesing> https://bugs.launchpad.net/unity/+bug/684925
<ubottu> Launchpad bug 684925 in compiz-fusion-plugins-main (Ubuntu) "remove Super + scroll shortcut in enhanced zoom" [Undecided,Fix released]
<david> thanks but i was wondering if maybe compiz config settings manager could be intigrated with ubuntu 12.10 or something
<david> that way users like me would not have to go through a lot of trouble trying to get it working
<cyphermox> david: I think you might to be filing bugs for each specific issue you're encountering, though I suspect that might be difficult
<cyphermox> david: ccsm is evil, we explicitly want to avoid pointing people to it, because it's so easy to break your system with it
<larsduesing> <- night :-)
<david> um okay could ubuntu incorperate something like zoom desktop somewhere?
<cyphermox> david: that would be something to bring up as a bug report ;)
<cyphermox> david: or you might want to talk to TheMuso who knows a lot more about accessibility than I do; but I'm not sure if he's around just yet.
<david> i don't know how to file bug reports without an application crashing
<cyphermox> david: 'ubuntu-bug unity' or 'ubuntu-bug compiz' for this type of thing, I guess
 * cyphermox has to log off
<david> i'm even considering trying to call canonical about it
<david> i'm currently running mint for the accessibility issues i've mentioned
<david> really the only accessibility linux has is the gnome 3 magnifyer orca(sucks) and ccsm enhanced zoom desktop
<Daviey> david: I'd suggest not calling canonical.. but the desktop manager would no doubt love to hear your feedback, jasoncwarner_ :)
<david> where could i find him
<Daviey> david: #ubuntu-desktop is probably best
<david> k thanks
<barry> dobey: still around?
#ubuntu-devel 2012-05-31
<Shinobi> perl module Curses::UI::Grid errors out. Could not load Curses::UI::0 from Curses/UI/0.pm   Any ideas?
<lool> slangasek: Just saw your ping, I'm in HK for Connect and have a couple of days off after returning; I also miss a testcase for it because I found the bug by reading the code, I didn't really face any symptom; that said, I'll try testing this end of next week by running pieces of the new code manually
<pitti> Good morning
<pitti> bdmurray: ah thanks; NB that you committed this to the quantal branch :)
<pitti> bdmurray: I'll reject and reupload
<pitti> bdmurray: ok, reuploaded
<pitti> cjohnston: hourly updates - niiice!
<cjohnston> :-)
<pitti> cjwatson: remove-package> \o/, thanks!
<cjwatson> very slowly we approach sanity
<StevenK> Oooh, where's that?
<cjwatson> lp:ubuntu-archive-tools
<pitti> StevenK: see the ubuntu-archive@ announcement
<pitti> cjwatson: wow, I hadn't actually expected you to be awake at this hour..
<cjwatson> I woke up at 1:30am and couldn't get back to sleep until I'd dealt with some of the stuff in my head.  I'm about to go back to bed
<cjwatson> StevenK: I have an MP up with the obvious nuke-from-orbit, too :)
<StevenK> cjwatson: Ah, I was wondering about that.
<cjwatson> (hardly a rush, but why not)
<StevenK> cjwatson: Approved.
<StevenK> cjwatson: One thing to jot down somewhere is you can probably kill SoyuzScript at some point too.
<pitti> cjwatson: reverted https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/queue-tables/+merge/108073 FYI (see my followup)
<pitti> just in case you wonder where it was gone
<toabctl> does anybody have an example how i can get the codename for a specific package with python-apt ? i had a look at http://apt.alioth.debian.org/python-apt-doc/ but found nothing.
<pitti> toabctl: what is a "code name"?
<toabctl> pitti, afaik "precise" is a codename. i use reprepro to setup some private repositories and try to get the codename of a package.
<pitti> oh, the release name
<pitti> toabctl: there really is no way to tell from a .deb
<toabctl> pitti, eg here is the codename set: http://archive.ubuntu.com/ubuntu/dists/precise/Release
<pitti> toabctl: right, usually you set up debmirror, reprepro and other mirroring by release, which will use the dists/.../Pacakges.gz indexes
<toabctl> pitti, imho apt should know the codename.
<pitti> toabctl: you can, by looking at the .origins property
<pitti> e. g.
<pitti> cache['coreutils'].candidate.origins
<pitti> there can be multiple origins, potentially from multiple releases
<pitti> but that really sounds backwards
<toabctl> pitti, i did this but there is no codename
<pitti> you want to ask your mirroring script "give me all precise packages"
<pitti> not iterate over all pacakges and pick out the precise one
<pitti> s
<pitti> toabctl: sure there is
<pitti> >>> c['coreutils'].candidate.origins[0]
<pitti> <Origin component:'main' archive:'quantal' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com' isTrusted:True>
<pitti> >>> c['coreutils'].candidate.origins[0].archive
<pitti> 'quantal'
<pitti> but really, this is not what you are looking for for mirroring..
<toabctl> pitti, i don't want to mirror. i use this for private stuff
<pitti> toabctl: ok; so the origins are the place to look for then
<pitti> either the .candidate or .installed, depending on what you are looking for
<toabctl> pitti, where is the codename in your example? there's an archive. is that the same?
<pitti> yes
<toabctl> hm. that's not set in my repository. maybe there's something wrong with reprepro then.
<pitti> toabctl: it's taken from the "Suite:" field in e. g. http://archive.ubuntu.com/ubuntu/dists/precise/Release
<pitti> toabctl: you need the Release file, perhaps you don't have this?
<toabctl> pitti, i have one, but Suite is missing. there is only a "Codename" field.
<slangasek> lool: ok; I'll ask for the package to be promoted in the meantime because the other bugs are high-impact, so maybe we'll drop the un-verified fix from the SRU
<pitti> toabctl: just checked the source; it only looks at Suite:, not Codename:
<toabctl> pitti, where's the upstream source? imho that should be fixed.
<pitti> Vcs-Bzr: says http://anonscm.debian.org/bzr/apt/python-apt/debian-sid/
<toabctl> pitti, i added the Suite-Field to the Release file and i the the archive now. thanks!
<pitti> works now? yw
<dholbach> good morning
<infinity> doko: Stop doing toolchain uploads from conferences.
<doko> ?
<infinity> ;)
<infinity> doko: I was just checking on the buildds after I uploaded eglibc to see that you'd done gcc-4.7 just before that.
<infinity> If both break the world, can we blame the tropical heat?
<micahg> infinity: will your eglibc upload fix all the broken armel bits? :)
<infinity> micahg: Which bits are those?
<infinity> micahg: It fixed the last broken bit on armel that I know of... If you know of more, speak up.
<micahg> infinity: I'm not sure if it's stuff still trying to do armv7 stuff or something else (and the porter boxen for armel are currently unhappy, rt open)
<infinity> micahg: Stuff doing stuff or other stuff isn't all that specific.  What issue were you seeing?
<micahg> {standard input}:135: Error: selected processor does not support ARM mode `smulbb r9,r9,r3'
<infinity> micahg: libc.so and ld.so on armel were both armv7 by accident (fixed now), but that's perhaps unrelated to your issue.
<infinity> micahg: What build was that in?
<micahg> that was firefox, ghc seems to have some similar does not support errors
<infinity> Oh, right, GHC was pointed out to me earlier.  Probably won't be fixed by my upload, no.  I'll have to look at it later.
<infinity> Unsure about firefox too, but when I find some round tuits, I can help investigate.
<doko> firefox builds should be fixed with the recent upload
<doko> chrisccoulson, ^^^
<micahg> firefox can wait for later, ghc is more important as I'm not sure if we should start the rebuilds until it's built on all archs
<micahg> doko: chrisccoulson will be relieved to play angry birds again
<doko> I wouldn't like to play happy birds ...
<infinity> micahg: I'll be looking at ghc shortly.
 * infinity runs off now.
<micahg> infinity: thanks, we'll rebuild firefox soon enough anyways and see if it cures itself
<micahg> doko: sorry, I didn't get to chromium yesterday, hope to look at it today, are you blocked on anything?
<doko> micahg, no
<cjwatson> StevenK: Yeah, I grep for stuff in it every time I kill something.  Killing change-override.py will probably manage to drop a method or two from it.
<cjwatson> pitti: Ah, hmm, I'll see if I can find a workaround
<pitti> cjwatson: I already had a workaround for the non-working len()
<pitti> cjwatson: but it still didn't work, all the queues reported 0, at least back in the days when I tried it
<pitti> perhaps LP got fixed in the meantime to deal with lucid's lplib
<pitti> ogra_: hey Oliver
<pitti> ogra_: FYI, I gave you a WI on https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-third-party-driver-installation for pvr-omap4, mostly because you know best how to detect whether the driver is necessary, and you can check "modinfo omapdrm_pvr"
<pitti> ogra_: if that doesn't have any modaliases, we can add a custom detection plugin, like we had in jockey; but if it can be detected with modaliases, that'd be a lot more flexible
<pitti> ogra_: of course I can help you wit this, but I'll need the initial investigation
<skunk> I want to start developing for ubuntu.. can someone walk me through it??
<skunk> is anyone even here??
<elky> skunk, sure. Most of them are probably asleep, at work, or doing other daily routine things. People tend to read scrollback though.
<elky> skunk, I can't walk you through it, but perhaps pointing you to the http://wiki.ubuntu.com/UbuntuDevelopment link in the topic would be a good starting point?
<dholbach> http://developer.ubuntu.com/packaging/html/ probably too :)
<skunk> kk one more question
<skunk> I have a java background.. should just touch up on it before learning Vala and C? i mean.. I do have to relearn how all these algorithms works eh??
<dholbach> that entirely depends on what you want to do - there's java work to be done in Ubuntu as well :)
<skunk> I want to be working with pixel perfect scrolling.. and improving that
<skunk> as well as work to better develop multitouch
<skunk> especially with synaptics touchpads
<ogra_> pitti, i plan to do some work on the panda anyway today, will get you the bits, np
<pitti> ogra_: danke
<skunk> what can i do if i have a synaptics touchpad, but ubuntu doesn't recognize it as one
<cjwatson> pitti: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/464 - you may vomit now
<cjwatson> (note you still can't actually index the members of getPackageUploads() without authenticating)
<pitti> haha
<pitti> cjwatson: ah, that was it then -- this should work with login_anonymously(), and queue access doesn't work with that
<cjwatson> No, that's incidental
<pitti> cjwatson: thanks for fixing
<cjwatson> This code doesn't attempt to index the members, just to get the length - I'm just noting that indexing the members still won't work
<cjwatson> The wadllib monkey-patch is what fixes getting the length
<cjwatson> Though that said one of my near-term work items involves creating a bot account on lillypilly, so all this can be authenticated; the LP team isn't actually desperately keen on anonymous access for various reasons, mostly monitoring/load-related
<pitti> cjwatson: right, but my previous attempt on a workaround used len(list(getPackageUploads()), which requires accessing the members
<cjwatson> Right
<pitti> so that failed
<cjwatson> This one's tested
<pitti> screenscraping-b-gone
<cjwatson> And deployed now
<cjwatson> Maybe I should do that bot account now actually, after the next cup of coffee; we need that to move copy-report off cocoplum, and other suchlike things
<cjwatson> I did check with the LP team about it; it's a bit alarming 'cos it's a privileged account, but it's essentially no worse than the alarming privilege of cocoplum
<cjwatson> and at least oauth tokens are revocable
<pitti> the old levels (such as "readonly") are gone now, right? (too bad, it was handy for things like that)
<pitti> or do you want to automatically copy anyway?
<cjwatson> copy-report doesn't want readonly
<cjwatson> I want to preserve the automatic copy, it at least used to save Canonical roughly my salary per year in bandwidth :-P
<pitti> *nod*
<pitti> cjwatson: I still wonder whether it wouldn't be easier to just integrate this into whatever release script the security team uses (i. e. also copy to -updates, instead of mass-copying from cron)
<micahg> pitti: you would need to give the security team access to -updates then ;)
<cjwatson> We need the bot account for other reasons anyway
<pitti> micahg: don't you?
<micahg> nope, just -security AIUI
<pitti> micahg: I wasn't aware that you need special upload privileges for -updates
<cjwatson> The privilege around -security is specially hardcoded in LP
<pitti> ah
<cjwatson> Other reasons> for example it would allow auto-syncs to be actually automated
<cjwatson> Rather than cron.cjwatson
<xnox> Can I rely on update-manager / do-release-upgrade to remove `oldlibs`, i.e. dummy transitional packages? Or shall I write a hook for update-manager because I am reverting the transitional package rename which was done in Lucid.
<skunk> cjwatson, are you still here?\
<skunk> well, cjwatson. I don't know if you're gonna see this message. But out of the six years i've used ubuntu the work you've done with the installer is incridble
<cjwatson> skunk: thanks, and you're welcome
<seb128> xnox, check with mvo but I don't think it does magically clean old stuff
<skunk> 15 minute install, then im surfing the web, writing documents.. this kinda sound like Mac territory
<skunk> cjwatson, who do I contact for uTouch issues??
<cjwatson> skunk: I'd start with cnd
<xnox> seb128: i distincly remember the 'Remove old unneeded packages: Y/n' question from do-release-upgrade, But I usually dist-upgrade to +1 release, and end up not using the upgrade-manager.
<cjwatson> (though it's not a field I know much about)
<seb128> xnox, right, I just don't know if that list is computed in a smart way or if you need to teach update-manager about it
<xnox> mvo: ^^^ can you check my message at :46 above.
<skunk> cjwatson: honestly I want my synaptics touchpad to work like one.. instead of a standard touchpad
<xnox> seb128: ok. I will test the upgrade in chroot =)
<mvo> xnox: its not looking at transitional packages specifically, it does look at unused dependencies though, that might (or might not) help you
<ev> pitti: am I reading this correctly that we do not have the ability to retrace VmCore files yet?
<ev> in apport-retrace, that is
<mvo> xnox: it could do heurisitc like looking at "transitional" or "dummy"in the description summary, but that is not deal, ideally there would be something formal identifying the transitional pkg
<xnox> mvo: 'Section: oldlibs' is standard way to identify transitional packages, unless i am wrong. let me check the policy.
<xnox> mvo: and they should be cruft to be removed.
<cjwatson> Yeah, though we could do better about actually moving transitional packages there in Ubuntu in practice.  But that's eminently fixable.
<xnox> hmm policy says 'kept for legacy'
<xnox> and some are not actually transitional nor dummy
<mvo> xnox: right, iirc oldlibs was overloaded with multiple meanings
<xnox> yeap
<xnox> looks like so
<mvo> I whish there was "section: transitional" or something similar or a debtag
<xnox> I will do a test and hopefully I will be ok with depends/replaces/conflicts etc.
<mvo> thanks
<ev> pitti, apw: also, we don't seem to have a close to unique identifier for KernelOops failures. Any objection to parsing the call trace out of OopsText (https://launchpadlibrarian.net/79771442/OopsText.txt) and generating a signature in the same manner as crash_signature (so concatenate the first few)?
 * ev lunches
 * xnox read * ev launches
<ogra_> but where to ?
 * xnox To the cloud! And beyond!
<ogra_> :)
<ogra_> charming :)
 * xnox loves ToyStory
<apw> ev, that doesn't sound like a bad plan, though in theory ignore the ? entries in the list ... also include the type of OOPS, the top line hints at th type, and the IP: as part of it
<ogra_> isnt that a requirement to become a DD ? :
<Daviey> xnox: launching stuff at poor infinity.. that is just mean.
<apw> Daviey, worse leaving him behind ... "and beyond"
<ogra_> nah, that just means infinity+1 :)
<xnox> Daviey: I was certian that infinity is deployed with juju these days
<doko> chrisccoulson, bug #1003733 is fixed, you can't verify when building with 4.6 :-/
<ubottu> Launchpad bug 1003733 in gcc-4.7 (Ubuntu Quantal) "Angry birds does not work (test failures in js/src/jit-test/tests/jaeger/testSetTypedFloatArray.js with gcc4.7)" [Medium,Triaged] https://launchpad.net/bugs/1003733
<xnox> oh my angry birds =)
<xnox> that must be critical priority =)
<pitti> ev: that's right
<pitti> ev: sure, if the succession of addresses in OopsText is reasonably reliable
<astraljava> xnox: Our offices are within 300 feet to their HQ, should I pay them a visit? :D
<ogra_> how would you pay this ... in icecream ?
<astraljava> I dunno, but I could sell them an ERP at the same time. :D
<xnox> astraljava: yes, plese. show up and say that `doko is not happy and wants an angry bird stuffed animal shipped to germany`
<ev> xnox: lol
<astraljava> xnox: some of their employees walk around in pig caps, would that do?
<ev> pitti: awesome
<ev> apw: cheers for that - once I have an algorithm I'll run it by you
<xnox> astraljava: yeap, don't forget another one to be shipped for me to uk offices =)
<astraljava> :)
<apw> ev, excellent thanks
<doko> micahg, ping
<chrisccoulson> doko, the new gcc appears to fix the issues btw (just did a test build here)
<doko> \o/
<chrisccoulson> thanks! :)
<jamespage> doko, any chance you could take a look at https://bugs.launchpad.net/ubuntu/+source/xmlgraphics-commons/+bug/888129/+attachment/3169273/+files/fix_icc_handling.debdiff before I upload?
<ubottu> Launchpad bug 888129 in openjdk-7 (Ubuntu Quantal) "xmlgraphics-commons version 1.4.dfsg-3ubuntu1 failed to build with openjdk-7" [Undecided,In progress]
<doko> jamespage, looks fine. sorry for the delay
<jamespage> doko, ack - thanks
<mpt> mterry, I have no strong opinion either way. But if the badge is kept, maybe it should count the top-level groups of updates, not the individual packages.
<mterry> mpt, hmm, k
<mpt> mterry, but on the other hand, that seems a bit weird
<mterry> mvo, let me ask you the other question from last night in this quieter channel
<mterry> mvo, so update-manager --no-update.  What is it supposed to do?  I see the code it affects, but still not sure what exactly it means
<mvo> mterry: my memory is not the best, but I think this got added for automatic testing via mago
<mvo> mterry: I think its ok to kill it off
<mterry> mvo, I want to recycle it.  The new spec requires doing an apt-get update when a user opens update-manager, but we need a way to turn that off, for testing and for when we pop up automatic updates.  --no-update seemed logical
<mvo> mterry: yeah, that sounds reasonable
<mterry> mvo, also, what's the story with the DBus API that update-manager exposes?  Who consumes that?
<mvo> mterry: update-manager itself to implement a poor mans singleton window
<mvo> mterry: see setupDbus() but meh, its pretty rusty, need proper dbus names for example
<mterry> mvo, OK, so it uses whether the name is claimed or not, much like modern GtkApplication.  But does anyone consume the actual calls like "update()" or "upgrade()" that you know of?
<mvo> mterry: those were added for mago as well
<mterry> mvo, ah OK
<mterry> mvo, (in the branch where I'm doing the update-on-start, I'm removing the ability to initiate updates elsewhere in the UI and was wondering about the dbus method to do so.  Sounds like I should drop it too)
<mvo> brendand: hi, iirc you added the update dbus stuff, is that actually being used these days in the test environment?
<brendand> mvo - i'd have to check
<brendand> mvo - i do know we have an apt-get-update test in our SRU suitew
<brendand> mvo - whether it actually uses that functionality i can't recall
<brendand> mvo, probably not
<mterry> mvo, brendand: well regardless, if the purpose of the tests is to mimic the UI, if the UI is dropping the ability to kick of an update willy-nilly, the dbus API should to I suppose
<brendand> mvo - what's the ui doing?
<mterry> brendand, how do you mean that?  The UI is moving to a "do an apt-get update on startup" and dropping the buttons to initiate one manually
<brendand> mterry, oh right, i see
<brendand> mvo, mterry - so i can say that *i* won't complain if it's removed. i can't promise no-one else will. i seem to recall that stuff was put in at the request of the QA team as well
<stgraber> NCommander: 12.04.1 meeting in #ubuntu-meeting
 * ogra_ sighs about linux-base
<ogra_> that postinst is a pain
<ogra_> slangasek, FYI support for the arm server arches is in flash-kernel now, the only thing i'm struggling with is linux-base atm which needs to be MIRed (its postinst tries to rewrite all config files that could use UUIDs though, and there is no debconf option to switch that off)
<slangasek> ogra_: hmm, if we don't need/want that rewriting (which should be obsolete for years now), why not drop the dep?
<slangasek> is linux-base needed for something else?
<ogra_> slangasek, it ships linux-version (which is actually the only binary in there after tgardner dropped perf from it), which flash-kernel uses to determine the laters kernel version
<ogra_> *latest
<ogra_> i'm incliend to just put an exit 0 at the top of the postinst
<pitti> ogra_, slangasek: I filed a MIR for linux-base this morning, FYI
 * ogra_ hugs pitti 
<pitti> it seems fairly harmless
<ogra_> pitti, what else does use it ?
<pitti> but I subscribed you and infinity to the bug for further comments
<pitti> ogra_: just flash-kernel
<pitti> bug 1006717
<ubottu> Launchpad bug 1006717 in linux-base (Ubuntu) "[MIR] linux-base" [Undecided,New] https://launchpad.net/bugs/1006717
<ogra_> it would be if the postinst wouldnt fiddle with hdparm.conf or udev rule rewriting
<ogra_> or bootloader configs
<slangasek> ogra_: so anything that would still be using /dev/[hs]d[a-z]* style names in any of these config files is already buggy, and *should* have been rewritten long ago (like, before we started having an armel port)... so I wouldn't worry about disabling it
<pitti> erk, yes
<ogra_> slangasek, well, the prob is that the script doesnt take any arm bootloaders into account, so it will always show a debconf error that you have to rewrite your configs by hand
<ogra_> we need to get at least this bit quiet
<ogra_> (and i really dont like the idea that it touches your grub config if you manually forced it to i.e. /dev/sdx1)
<cjwatson> it was sane for transitional purposes, but as slangasek says it sounds obsolete now
<slangasek> ogra_: really?  The code looks like it's not supposed to trigger on first install
<slangasek> is_fresh_installation()
<ogra_> well, i just had that message on both, precise (using --force-overwrite to overcome the perf conflict)  as well as on quantal
<slangasek> oh, sorry, the definition of is_fresh_installation() keys on whether there are linux-image-* packages installed
<slangasek> rather than on whether this is the first installation of linux-base
<slangasek> phooey
<ogra_> and if fstab exists :)
<ogra_> sigh, my perl is so rusty ... thats what years of ubuntu work do to you
<ogra_> funnily i indeed have an fstab file as well as a linux-image-* package installed on both test systems i tested on
<ogra_> which somewhat indicates it doesnt even work
<slangasek> well, no, the check is to not migrate if you *don't* have an fstab (or don't have linux-image-* packages)
<slangasek> so that makes sense.. I just made a bad assumption based on the function name :)
<ogra_> oh
<ogra_> yeah, and i read it vbackwards :)
<slangasek> ogra_: yeah, I would just disable this then
<ogra_> you mean the whole postinst ?
<slangasek> yeah
<slangasek> it's definitely not worth porting it to other bootloaders
<ogra_> right, i'll just remove it from the package completely then
<stgraber> stokachu: hi. I'm currently looking at your isc-dhcp SRU. I merged the pid bug with the one I used for the other SRUs (bug 985417) and am now looking at bug 588635
<ubottu> Launchpad bug 985417 in isc-dhcp (Ubuntu Oneiric) "dhcpd cannot write /var/run/dhcpd.pid" [Undecided,New] https://launchpad.net/bugs/985417
<ubottu> Launchpad bug 588635 in isc-dhcp (Ubuntu Oneiric) "apparmor profile for sbin.dhclient3 not compatible with wicd" [Undecided,New] https://launchpad.net/bugs/588635
<stgraber> stokachu: for that second bug, can you update the bug report with the required SRU tags? (rational, test case, regression potential)?
<stgraber> stokachu: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<stgraber> stokachu: I have the SRU ready for upload here, so as soon as the bug is updated I'll upload it
<ari-tczew> one question: does quantal have the same toolchain like unstable right now? e.g. does it have gcc 4.7 default?
<stokachu> stgraber: yea ill get that updated shortly for you
<ikonia> ari-tczew: could you please check your pm when you get a moment
<bregma> I need to upload an SRU change for 12.04 that has the same package version as the latest package in quantal -- should I add ~precise to the SRU package version, er sumpin'?
<cjwatson> bregma: I would probably recommend appending ~ubuntu12.04.1
<cjwatson> or something like that
<cjwatson> (assuming that the delta from current precise to this meets the SRU guidelines)
<Laney> jcastro: yo, I don't see a tenant or account ID on the page you linked from HPCloud. Just "Access Key ID"
<Laney> do I need to do anything else?
<jcastro> refresh the wiki page
<jcastro> I just added it
<jcastro> "Note that the Tenet ID doesn't show up on that page until you've clicked on "Activate Now: for one of the availability zones in the Dashboard."
<Laney> hah, you did /just/ add it indeed.
<Laney> thanks.
 * Laney wonders how to make that choice
<jcastro> Laney: anything you can add from the "I started with nothing on hp cloud" to the instructions would be appreciated
<jcastro> a bunch of us were already on it so it's difficult to figure out what starting from zero is like
<Laney> sure
<Laney> the account ID is on a different page, so I'll add a link to that
<jcastro> <3
<stokachu> stgraber: re: SRU 588635 is done
 * xnox can't find my USD credit card
<xnox> for hp cloud thing =)
<Laney> I just used my UK one
<stgraber> stokachu: thanks
<stokachu> stgraber: anytime
<stokachu> stgraber: now im off to wrestle autofs :D
<stgraber> have fun ;)
<xnox> stokachu: i have been merging autofs today, what's up?
<xnox> or is it for stable release? =)
<stokachu> xnox: hey, im working an issue where automount is hanging on reloading 11k mounts
<stokachu> :X
<stokachu> yea its for lucid atm
<xnox> ... enjoy =)
<stokachu> haha taking the hands off approach wish i was you :D
<penguin42> 11k mounts?!
<stokachu> penguin42: thats just a rough estimate i haven't actually looked at the mount table yet
 * penguin42 has plenty of sympathy for the automounter in that case
 * stokachu agrees
<micahg> doko: pong
 * xnox Ladies and Gentlemen, Minions and Overlords 2 hours left until FeatureDefinitionFreeze
<ScottK> StevenK: I just did my first package removal.  Feels good.
<highvoltage> nice
<xnox> ScottK: I got a feeling =) that tonight gonna be a real good night =)
<ScottK> ;-)
<xnox> ScottK: can you remove stale binaries of bitcoin on powerpcc only?
<dobey> bdmurray: hey, can you remove one of the requested reviews on https://code.launchpad.net/~brian-murray/lptools/grab-descriptions/+merge/106469 ? then i can review it and get it landed (i added lptools to a tarmac instance to land the branches)
<xnox> although it will be dealt as part of powerpc port cruft
<bdmurray> dobey: either one of them?
<dobey> bdmurray: yeah
<bdmurray> dobey: there is only a possibility to reassign not remove.  should I resubmit then?
<dobey> hmm, weird. nah
<ScottK> xnox: I can.  Please file a bug explaining what you want removed and why and subscribe (not assign) ubuntu-archive.
<xnox> Ok.
<xnox> ScottK: ok, thanks.
<tjaalton> why does sbuild fail with "E: Can't determine architecture of chroot:" these days, on precise?
<tjaalton> only thing i've chagned is the kernel (3.4 from quantal)
<xnox> pae kernel?
<tjaalton> amd64
<xnox> hmm. no clue. pass.
<geser> and when you boot the old kernel it works again?
<tjaalton> i'll try, but it's too unstable to use
<tjaalton> geser: exactly
<geser> if my perl foo is good enough this error happens if "dpkg --print-architecture" fails
<tjaalton> I'll try with a backport kernel, this one was built on quantal
<tjaalton> dpkg --print-architecture worked fine though
<barry> stgraber: could i ask a favor of you to bump this build: https://launchpad.net/~barry/+archive/python/+build/3539392
<stgraber> barry: done
<barry> stgraber: thanks!
<hallyn> all right.  my struct has (more than) two fields, 'char *name' and 'char *error_string'.  when i set 'c->error_string = NULL;', the previously correctly set c->name becomes "".  Does this ring any bells with anyone?
<hallyn> I can't reproduce it with a minimal testcases
<geser> you sure that setting error_string destroys your name?
<hallyn> i print it out right before, and right after
<hallyn> well, clearly i'm corrupting my stack somewhere
<hallyn> i'll look tomorrow, need to clear my head.  thanks
<YokoZar> Is there a set group of Ubuntu Ruby folks like there is for Python or do we just inherit from Debian?
<slangasek> what do you mean by "set group"?  I'm not aware there's a set group of Ubuntu Python folks either
<YokoZar> slangasek: What I mean is when I think of python packages I tend to think of folks like scottk and doko
<YokoZar> even though it's informal
<slangasek> ah, well, the ruby packages seem to be in sync with Debian at the moment, so I don't know
<ScottK> No.  There isn't.
<barry> stgraber: one more favor ;)   https://launchpad.net/~barry/+archive/python/+build/3539477
<stgraber> barry: done
<barry> stgraber: thx!
<psusi> cjwatson, how does d-i locate the installation cdrom?  in particular when it's actually a usb flash drive?  it works fine for me on real hardware, but when I boot a qemu vm from my flash stick, d-i says it can't find the cdrom... the desktop image works fine though, it's just a problem with d-i
<micahg> roaksoax: you seem to be forgetting to pass -v when creating the .changes files
#ubuntu-devel 2012-06-01
<micahg> doko: did you need something from me?
<ScottK> Some days are better than others: https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.6/+bug/992941/comments/5
<ubottu> Launchpad bug 992941 in wxwidgets2.6 (Ubuntu) "Remove wxwidgets2.6" [Low,Fix released]
<ajmitch> excellent!
<micahg> awesome, now if we can just get rud of sqlite
<micahg> *rid
<pitti> Good morning
<kees> infinity: you around?
<infinity> kees: Nope.
<kees> infinity: dang. I was gonna ask you about eglibc coordination.
 * slangasek marks infinity absent
<kees> infinity: I have a patchset that cleans up the existing patches (making them not ubuntu-specific)
<infinity> kees: email would be better, I'm only sort of here.
<kees> infinity: okidoky.
<kees> infinity: alternatively, I could just upload it to quantal. ;)
<infinity> You don't want a review of any sort? :P
<kees> hehe
<kees> emailing you the debdiff now.
<pitti> SpamapS: I now added test cases and regression potential to all apport SRU bugs
<pitti> rickspencer3, cjwatson, slangasek: FYI, just sent the May stable+1 status to u-devel@
<rickspencer3> hi pitti
<rickspencer3> thanks!
<slangasek> pitti: thanks much :)
<dholbach> good morning
<larsduesing> good morning together
<pitti> hello larsduesing
<jibel> mvo, hey
<jibel> mvo, is upgrade to quantal still blocked on py3 port of the release-upgrader ?
<mvo> yes, afaict its still not working, but we need to make it work for a1
<jibel> mvo, ta
<brendand> what can i use in place of gobject.Mainloop in Python3?
<pitti> brendand: use python3-gi, and GLib.MainLoop
<xnox> If anyone knows autofs or likes cryptic patches, could you please take a look and tell me (1) what does this do (2) and why: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/autofs5/quantal/view/head:/debian/patches/16group_buffer_size.patch
<brendand> pitti - from gi.repository import Glib?
<brendand> pitti - i know for sure i have python3-gi installed
<brendand> pitti - btw, i'm on precise
<pitti> GLib, not Glib
<brendand> pitti - ahem
<xnox> Never mind found it: https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/591100
<ubottu> Launchpad bug 591100 in autofs5 (Ubuntu Lucid) "autofs5 eats the cpu if you have large groups" [Undecided,Fix released]
<brendand> another question. what are we meant to use instead of pygst? am i correct in thinking some gi binding?
<pitti> brendand: that's the general idea, but gstreamer 0.10 is not yet introspectable; gstreamer 1.0 will mostly be
<pitti> (it's in universe now)
<pitti> brendand: if you need gst 0.10, then you can't use python3 yet
<brendand> pitti - will that be in precise?
<pitti> no, it won't
<pitti> precise -> python 2
<pitti> (and pygst)
<brendand> pitti - so i can't install gstreamer 1.0 on precise to test?
<brendand> pitti - just want to know if i need to be updating to quantal
<pitti> brendand: oh, you certainly can backport/build/install it, but it is not in precise prpoer
<brendand> pitti, ok
<pitti> brendand: I figure the gstreamer1.0 etc. packages will build on precise just fine
<xnox> my piuparts is not up to date. Is there a latest / greatest way to set up piuparts for multiple ubuntu and debian distributions, considering i have switched to using pbuilder-dist?
<smb> cjwatson, Sorry to ask again, I am just not sure whether this may be just a just about acceptable thing: would a 3-4 minute delay on each boot justify a SRU to initramfs-tools which looks to be low risk and testable (back into Lucid/10.04)? The alternative would be to document the workaround (I assume in the release note?).
<cjwatson> mvo: I thought I'd fixed the upgrader; it's still not fully py3, but it shouldn't have those import bugs any more[6~
<cjwatson> smb: All other things being equal, that looks like a reasonable SRU candidate
<mvo> cjwatson: I haven't looked into details yet, but sudo ./dist-upgrade.py fails for me with import errors, I'm at r2435
 * mvo actually looks closer
<smb> cjwatson, Ok thanks. I tested a modified version in a vm and found it doing as claimed (so only adding the non-obviously depending module when the one that depends on it is requested to be in). So I will proceed to bring the report into proper state for SRU. Thanks again
<cjwatson> mvo: I was sure I'd fixed that in revisions 2430 to 2432.  What's the exact error?
<cjwatson> Oh
<cjwatson> Ddamnit, it had worked
<cjwatson> OK, give me a minute, I'll fix that
<mvo> cjwatson: thanks! once that is done, I look at the merge from mterry and do a new upload for a1
<cjwatson> Oh, wow, it's using __import__, what could possibly go wrong
<mvo> *cough*
<mvo> cjwatson: if its a hassle I'm happy to have a look at it myself, I just wanted to avoid digging into something that potentially was already done
<cjwatson> It's OK, I broke it, I'll fix it
<cjwatson> ... somehow
<cjwatson> mvo: Try r2436
<mvo> cjwatson: using importlib?
 * mvo checks
<mvo> cjwatson: oh, interessting!
<cjwatson> Possibly ought to have passed locals() as well, but the docs say that the standard implementation only uses globals()
<cjwatson> I'm fairly sure this won't work yet with Python 3, but that's for another day
<mvo> cjwatson: thanks a bunch! I look at the py3, I think we can use importlib for this
<mvo> cjwatson: I check that out and if its good commit
<cjwatson> py3 can probably use __import__ too, with some extra fiddling - not susre
<cjwatson> but yeah, importlib should be a possibility
<cjwatson> The rest of update-manager isn't finished for py3 yet (I still have a stack of patches to sort out), so don't worry about it too much
<mvo> ok
<seb128> ev, pitti, ogra_: "* moving of the Launchpad retracers onto the crash database system" ... does that concern only errors.ubuntu.com or also the launchpad retracers?
<ogra_> seb128, that was from ev's weekly report, he can probably elaborate
<ev> seb128: pitti and I are discussing how we can reduce the duplication of effort around retracing. The functionality would remain the same, but behind the scenes the duplicate db that crash-digger uses would live in Cassandra and the Launchpad retracers themselves would run from the same server that the error tracker retracers are on.
<ev> So this wouldn't remove Launchpad bug duplication. It would just mean that we have a single location for the apport duplicate db.
<seb128> ev, ok, that's fine, so it means I should stop sshing to the retracers (I used to grep logs to get stats and help restarting them when they get stucked, that sort of things)
<seb128> ev, but I feel like if you change the setup and I'm out of the loop I better step out to not create issues
<ev> seb128: Eventually, yes. Stats will be available via a web API (let me know if there are specifics you need there). Restarting them and handling issues will fall on me and webops - so you wont have to worry about that anymore.
<seb128> less work, I will not complain ;-)
<seb128> ev, thanks!
<ev> :)
<seb128> I'm glad that ogra pointed that to -release and that I read it
<ev> seb128: sure thing. Still in the planning stages, but I'll keep you in the loop.
<seb128> thanks
<seb128> ev, @stats: nothing specific, I used to build "bug which get the most duplicates" lists from the log before we had errors.ubuntu.com
<ev> ah, glad I could automate that task away for you :)
<seb128> ;-)
<seb128> ev, is there a way to see the issues you submit on errors.ubuntu.com?
<seb128> pitti, so, re. making easy to still report bugs to launchpad, we get an increasing number of users who report useless bugs about segfaults because they don't manage to use ubuntu-bug anymore
<seb128> i.e they run it on the .crash and get a .upload and nothing else and they get confused on what happened
<seb128> so they go on launchpad and open a bug saying they get a segfault and can't report it
<pitti> hm, what kind of users? i. e. the "kenvandine" kind, or the "my mother" kind?
<seb128> I'm not sure how we solve that and if we should wait on errors.ubuntu.com to improve
<pitti> the whole point of disabling this was that we stop getting reports for stables, after all?
<seb128> pitti, people who run quantal
<pitti> seb128: oh, quantal; we can just re-enable LP bugs for quantal again
<kenvandine> i was on precise though
<pitti> there's no reason why it's disabled there other than "we did not get around to do it"
<kenvandine> but that isn't the norm
<seb128> pitti, do we have retracers for q yet?
<pitti> seb128: sure, since day 1 :)
<pitti> they are now trivial to set up
<seb128> right, your new setups make that trivial ;-)
<pitti> just copy the precise config file, s/precise/quantal/, done
<seb128> pitti, ok, can we get apport turned on again in quantal soon then?
<seb128> I think that's most of the issue I faced recently
<ev> seb128: yes - http://errors.ubuntu.com/user/$your_sha512_hashed_system_uuid
<seb128> users who jumped on quantal, have segfaults and struggled to report them
<seb128> ev, how do I compute "your_sha512_hashed_system_uuid"? ;-)
<ev> seb128: I'll have an upload of activity-log-manager soon that puts this into a button in the diagnostics tab of the privacy page
<seb128> cool
<seb128> ev, btw errors.ubuntu.com seems to regressed on something that worked the other day for me
<seb128> ev, if I do
<pitti> seb128: uploaded
<seb128> "Error reports for "12.04" gnome-control-center "all installed version"" on a month
<seb128> I get nothing listed
<seb128> i.e "No data to display"
<seb128> oh
<ev> seb128: oh? (working on a one-liner for the compuation)
<seb128> is "month" a "since the month start"?
<seb128> i.e today?
<ev> yes
<seb128> ok
<seb128> that's why :p
<kenvandine> hehe :)
<seb128> I though it was a month timeframe
<kenvandine> good, no bugs yet today :)
<ev> yeah, I'll fix this when we do the date range stuff
<seb128> i.e sliding win
<ev> indeed
<ev> exactly that
<seb128> ev, thanks
<ev> sure thing
<larsduesing> Hmpf... Short question.. I now have 3 different patches for aiccu, 2 of them possibly SRUable, one merge with debian sid... What should I do? Some ranking?
<seb128> ev, and is there a way the repartition of a specific issue by versions?
<ev> seb128: can you elaborate please?
<seb128> ev, like the s-c listed first on first on e.u.c is supposed to be fixed in 5.2.2.1, can we see if the reports we still get are from users who didn't upgrade yet?
<seb128> -on first
<larsduesing> all 3 are completely independent
<seb128> ev, we have "last seen" in 5.2.2.1 but my guess is that because we don't have the "was the running version the current one"
<hallyn> is there some nifty way to test apport hook triggers?
<larsduesing> hallyn: yes :-)
<larsduesing> hallyn: apport-bug
<seb128> ev, I would like to see if on those 486 reports 480 were running 5.2.2.1 and 6 a false positive from users who still had the old binary running
<larsduesing> hallyn: apport-bug <packagename>
<hallyn> larsduesing: doesn't work well without x or without giving my lp id
<ev> seb128: hmm, okay. I'll have a chat with mpt and see if we can come up with a good UI for that.
<hallyn> oh wait, maybe that gets me far enough
<hallyn> thanks :)
<larsduesing> hallyn: it works in commandline-mode...
<seb128> ev, well maybe my usecase is just created by the fact that we have that issue with "is the running version current", but I still think it would be somewhat useful to know the stats by version, it can give an indication of if the update worked most most user, some users, none of the users
<larsduesing> hallyn: apport-bug --save <bugreportfilename> <packagename>
<ev> I'll do that when we're back on Wednesday
<hallyn> larsduesing: perfect.  thanks.
<larsduesing> hallyn: np
<larsduesing> hallyn: to be fair, I had these troubles a few days ago, and was helped here :)
<hallyn> larsduesing: the libvirt apport hooks have been wrongly isntalled forever.  I needed a somewhat simple test case for SRU justification.  :)
<hallyn> (that did not include "force libvirt to segv")
<seb128> ev, I'm done with questions, thanks for the replies ;-)
<seb128> pitti, thanks as well for the replies and for re-enabling apport in q ;-)
<ev> seb128: noted. I have a branch that (at Matthew's suggestion) greys out lines that we reasonably believe to be fixed (either there are no instances of the crash in the latest version, or the attached bug is marked fix released). But I had not until now thought about separating out the frequency counts by version, so we could show the stats you mention.
<ev> I've added that to my todo item for talking to Matthew
<ev> seb128: sure thing. Always looking for ways to make this thing more useful for you guys.
<seb128> ;-)
<ev> seb128: printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum
<ev> that should give you the other part of the URL
<ev> so http://errors.ubuntu.com/user/$that
<ev> without the dollar sign, of course
<seb128> ev, excellent, thanks again ;-)
<ev> seb128: I take it that worked?
<seb128> ev, yes
<ev> yay
<hallyn> is there a way to force apport-cli, when doing --save, to give me output even though I'm running a custom built package?
<hallyn> I don't see a '--override' option
<seb128> ev, is there any way to go from those report to the "master" or to see if they have associated launchpad bugs?
<ev> seb128: not as yet. Adding to the list. :)
<seb128> ;-)
<ev> seb128: I should've just created another blueprint/UDS session for "things Seb wants/needs" ;)
<seb128> lol
<ogra_> ++
<PaoloRotolo> Hi all!
<jamespage> how does apt determine the order in which packages are configured? does the Priority field get used in any way?
<htorque> jono: hi! do the accomplishment descriptions use tabs or are spaces fine as well (for listing the steps)?
<jono> htorque, tabs please :-)
<htorque> jono: alright
 * Sweetshark dances to the left ..
 * Sweetshark dances to the right ..
 * Sweetshark jumps and turns around.
<Sweetshark> libreoffice-3.6.0~alpha1 succeeded building in 1h52min on precise.
<Sweetshark> now only have to lob that over to quantal.
<xnox> that quick! =)
<jamespage> sbeattie, are the new openjdk-6 packages ready for < 12.04 yet?
<Sweetshark> xnox: ccache+16GB RAM+SSD. Half an hour of that is tar/xz compressing the 2GB libreoffice-dbg package.
<xnox> heh =)
<Sweetshark> xz need multithreading.
<Sweetshark> *nods*
<stokachu> xnox: do you know if sunrpc's max_shared parameter was ever accepted upstream?
<mvo> mterry: do you feel good about your software-updater branch to land in a upload for today?
<xnox> stokachu: no clue. should check. this is with regards to nfs, right?
<mterry> mvo, the move-changelogs one?  Sure
<mvo> mterry: excellent
<xnox> stokachu: or something else?
<stokachu> xnox: yea
<xnox> stokachu: I was under impression that sunrpc's max_shared is separately configured / enabled. but I do not know if it is upstream on linux. and which upstream of nfs. As far as I remember there were multiple implementations.
 * xnox has vague and out-of-date nfs knoweledge, but I could pick up on it.
<stokachu> xnox: i lowered the sunrpc.min_resvport=200 and can allow these 13k mounts to succeed
<xnox> well done! =)
<stokachu> but i dont want it to interfere with other services like samba
<xnox> stokachu: cryptic. i am not even sure where to ask this to get wide exposure about this. try ubuntu-kernel mailing list or even ubuntu-devel to get more information on this.
<stokachu> ok will do, thanks!
<xnox> stokachu: try jelmer, he might know a lot.
<xnox> https://launchpad.net/~jelmer
<xnox> he is deep into samba and might now quirks like that
<Laney> zul: you didn't actually make the change in nova-common.postinst ...
<zul> Laney: fix is coming now
<Laney> zul: I'm looking at 2012.2~f2~20120531.14249-0ubuntu1 now (the one you just uploaded), unless you mean that there is a second upload incoming
<zul> Laney: second upload is coming
<Laney> sweet
<bdmurray> wasn't there a kernel team member asking about package install failures and postinst earlier this week?
<cjwatson> bdmurray: apw possibly
<apw> i was asking about postinst indeed, though not about errors
<apw> i may have been asking about errors separatly, as there was an uptick but we didn't know if that was cause of an uptick in installs
<bdmurray> okay, I'm just looking at bug 991282
<ubottu> Launchpad bug 991282 in initramfs-tools (Ubuntu) "package linux-image-3.2.0-24-generic 3.2.0-24.37 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1" [High,Confirmed] https://launchpad.net/bugs/991282
<bdmurray> and that bug seems to be a duplicate of bug 996373
<ubottu> Launchpad bug 996373 in initramfs-tools (Ubuntu) "package linux-image-3.2.0-24-generic 3.2.0-24.38 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1" [Undecided,New] https://launchpad.net/bugs/996373
<jono> mterry, hey
<mterry> jono, hello
<jono> mterry, dpm mentioned that the Quickly flash template and /opt bug have been fixed in quickly trunk
<mterry> jono, yup.  I pushed to precise-proposed too
<jono> awesome! that was going to be my next question
<mterry> jono, (and quantal)
<jono> I will check proposed, thanks!
<jono> I plan on upgrading to Quantal at A1 next week
<jono> thanks
<mterry> jono, please do, let me know of any issues so I can fix them before it actually hits users!  :)
<jono> mterry, will do, will test now
<slangasek> mhall119: swing global menu> !! wicked
<highvoltage> what in the world is swing global menu?
<jono> mterry, when did you push it to proposed?
<slangasek> highvoltage: global menu integration for apps using swing java toolkit
<highvoltage> aah
<mterry> jono, oh right, it hasn't been accepted yet by an archive admin
<jono> ahhh np
<jono> mterry, did you manage to take a look at the qt-quick template?
<jono> I am not sure if it has been submitted
<mterry> jono, no I haven't looked yet
<mterry> jono, was it ready for review?
<jono> I am not sure, I am checking into it
<jono> I just wasnt sure if he had submitted it yet
<jono> I know there is the qt-quick one and the HTML5 template
<bdmurray> oh that's fantastic all the dupes of bug 991282 are from the same person
<ubottu> Launchpad bug 991282 in initramfs-tools (Ubuntu) "package linux-image-3.2.0-24-generic 3.2.0-24.37 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1" [High,Confirmed] https://launchpad.net/bugs/991282
<mhall119> slangasek: if we can get that into OpenJDk and make it available by default for all Swing apps, that would be a big win
<mterry> jibel, oh neat.  I was about to split the auto-upgrade-tester out of update-manager, but I see you already made a project (auto-upgrade-testing) that has done that?
<mvo> mterry: yeah, jibel is made of awsome, it just needs a proper source package now and upload and we should be good :)
<mterry> mvo, yar, I can do that
<mvo> ta
<mvo> mterry: one of my whishlist items there would also be to allow the upgrade tester to directly pull from a bzr branch instead of doing do-release-upgrade -d
<mterry> mvo, you mean like bug 956175 ?
<ubottu> Launchpad bug 956175 in Auto Upgrade Testing "Add an option to pull update-manager from bazaar" [Wishlist,Triaged] https://launchpad.net/bugs/956175
<mvo> mterry: yeah
<mterry> mvo, patches welcome...  ;)
<mvo> hahahaha
<mvo> thats not what you tell upstream, its the other way around ;)
<mterry> mvo, isn't that what every feature request is?  A "patches welcome" to upstream?  :)
<mvo> I shouldn't argue with you, you are too smart ;)
<mterry> mvo, flattery will get you no patches, sir.  :)
<mvo> *damm*
<mvo> ;)
 * mvo tries to offer some tea and cookies next
<mterry> heh
<maco> >< might be time to update my server precise. i can't apt-get build-dep the dependencies for a package added in oneiric on a lucid box
<mterry> jibel, is lp:auto-upgrade-testing in a releasable state?  Like, can I package it up and put it in quantal?
<larsduesing> Sorry, can anybody explain to me, what Mathieu wants me to do? https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/+merge/108302
<micahg> cyphermox: ^^ what you're asking isn't possible in LP
<dobey> cyphermox: ^^
<cyphermox> the what?
<micahg> cyphermox: it's yet another problem with UDD :)
<cyphermox> isn't the merge done somehow?
<cyphermox> what do you mean it's not possible, I've done it before ;)
<micahg> cyphermox: oh, you mean in the changelog?
<micahg> or in the LP diff?
<cyphermox> yes
<cyphermox> no, changelog should have the diff from what's left as a delta :)
<larsduesing> Sorry, can anybody explain to me, what Mathieu wants me to do? https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/+merge/108302
<micahg> cyphermox: ah, ok, yes
<cyphermox> or actually, a description of what is left as changes
<micahg> larsduesing: ^^ see above conversation, update the changelog with the list of changes over Debian
<cyphermox> I must have written it in an unclear way :)
<larsduesing> micahg: sorry, I got nothing here
<larsduesing> netsplit or such
<cyphermox> larsduesing: you're merging from Debian; which implies there are still changes left as differences from how the package is in Debian
<cyphermox> these remaining changes should be listed in changelog :)
<larsduesing> hmm
<larsduesing> ok
<micahg> larsduesing: something like this https://launchpad.net/ubuntu/+source/fox1.6/1.6.45-1ubuntu1
<cyphermox> right
<cyphermox> it should as a minimum be listing the upstart job file added
<cyphermox> micahg: I'm curious as to what you said wasn't possible though?
<micahg> cyphermox: having LP show the diff in the merge proposal from Debian :)
<larsduesing> oh, so I should add all changes from ubuntu since the last merge from debian?
<micahg> *diff from Debian in the merge proposal
<cyphermox> larsduesing: yes
<larsduesing> ok... I'm doing
<cyphermox> micahg: no, indeed LP wouldn't show it, but that's fine as I should be able to generate that myself
<cyphermox> and indeed it's just the upstart job that isn't listed
<larsduesing> yes. That should be all.
<larsduesing> sorry, I'm learning and learning
<larsduesing> :)
<larsduesing> thanks
<cyphermox> larsduesing: no problem at all; I just didn't think I should be fixing this particular thing myself for your merge; it was a good opportunity to show bzr diff --old ;)
<cyphermox> larsduesing: not sure how you committed your merge though, bzr commit or debcommit?
<larsduesing> At least I have only a small package
<larsduesing> debcommit
<cyphermox> but a very useful one
<larsduesing> All I saw was nobody is really caring for it, and so I try my best
<cyphermox> larsduesing: (really just personal preference there) I'd use bzr commit for merges, to avoid having the commit list Debian changes; just the actual merge revision changelog
<cyphermox> larsduesing: thanks for looking at it
<larsduesing> simple learning how to do it in real world :)
<larsduesing> (with more than 10-15 committers as normal...)
<larsduesing> ok, so I should delte this branch, do a new one, and this time real correct :)
<larsduesing> away for 10-15 minutes, got to fetch shopping out of the car from my wife :)
<cyphermox> larsduesing: no real reason to delete the branch, you can just apply your fixes on top of it
<bdmurray> mvo: I'm looking at bug 991282 and thinking about how to stop duplicates from the same reporter coming in
<ubottu> Launchpad bug 991282 in initramfs-tools (Ubuntu) "package linux-image-3.2.0-24-generic 3.2.0-24.37 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1" [Low,Confirmed] https://launchpad.net/bugs/991282
<bdmurray> mvo: what do you think of search DpkgTerminalLog for the same 'DuplicateSignature' and stop reporting if it exists?
<bdmurray> I guess that assumes they reported it before
<mvo> yes, that sounds reasonable
<mvo> we would have to SRU that, right?
<bdmurray> well, doing it in Quantal alone would be fine with me
<mvo> in this case feel free to just add it to trunk
<cjwatson> larsduesing: in fact you should generally actively *not* delete branches when you get needs-fixing reviews; it's easier for your reviewer to see what you've fixed if you simply commit the fixes on top
<cjwatson> LP merge proposals are much more useful when people do that
<bdmurray> dobey: so is lptools not supposed to be Ubuntu specific?
<dobey> bdmurray: not sure i understand that question
<dobey> bdmurray: it is for tools that use the launchpad API
<bdmurray> dobey: okay, I've a tool that parses the description for apport information not every project has bugs that are reported by apport
<bdmurray> dobey: however, it'll do none apport specific things too
<bdmurray> er non-apport
<dobey> ok
<bdmurray> lptools still seems like an okay place for it?
<dobey> yeah, i don't see why not
<bdmurray> cool, thanks
<dobey> that doesn't seem ubuntu specific to me.
<dobey> for things that are truly ubuntu specific, i guess ubuntu-dev-tools is where they'd belong though.
<kees> infinity: did you get the eglibc patch?
<slangasek> did ya get that THING I sent ya
<dobey> can someone accpet ubuntuone-client into precise-proposed now please? i've gone through and added [Test Case] and [Regression Potential] headers to bugs. thanks
<stgraber> cnd: looks like the SRU from bug 973297 is a fail, can you confirm?
<ubottu> Launchpad bug 973297 in xserver-xorg-input-evdev (Ubuntu) "Xorg recognizes Logitech Headset USB dongle as input device then segfaults in XIChangeDeviceProperty" [High,Triaged] https://launchpad.net/bugs/973297
<ahasenack> hm, is bzr merge-upstream known to do something to po files? Like, wrap long lines?
<slangasek> ahasenack: I thought my wishlist bug requesting that bzr merge do intelligent .po handling was still outstanding
<ahasenack> slangasek: not sure what is happening, but I'm using merge-upstream with a new tarball, and in both the tarball and local branch some entries in the po are very long lines
<ahasenack> slangasek: so no difference bar one real change, a typo
<ahasenack> slangasek: yet the resulting po file has all long lines wrapped, resulting in a big diff
<slangasek> interesting
<ahasenack> if I just replace the po file with the one from the tarball, this is the diff: http://pastebin.ubuntu.com/1018636/
<slangasek> ahasenack: bug #884270?
<ubottu> Launchpad bug 884270 in Bazaar "bzr should do smarter merging of .po files" [High,Fix released] https://launchpad.net/bugs/884270
<slangasek> apparently it is fixed :)
<ahasenack> if I run merge-upstream with the tarball, I get this diff: http://pastebin.ubuntu.com/1018638/
<ahasenack> slangasek: let me check that bug
<slangasek> so it's configurable and overrideable
<slangasek> but yeah, with that code enabled, by default your .po files are going to be in a normalized format after merge
<ahasenack> ok, that explains it
<slangasek> basically, because it's using the gettext merging tools that understand .po format, instead of bzr's default line-based merge
<ahasenack> so, po_merge
<ahasenack> I do have it
 * ahasenack keeps on reading
<cjwatson> I occasionally do bzr remerge --no-plugins when it annoys me
<cjwatson> well, on the specific files
<slangasek> good to know
<cjwatson> that said, if your .po files aren't already run through msgcat before committing them to bzr, you're doing it wrong
<slangasek> though honestly, everyone should normalize their .po files anyway, to reduce noise in the VCS diffs :)
 * slangasek nods
<cjwatson> you can do that once in one separate commit before merging
<ahasenack> in this case both the previous and the current one are not normalized
<ahasenack> and to normalize them I will have to add a package patch
<slangasek> heh, yeah, not the thing to do in this case then
<ahasenack> because the upstream tarball has them like that
<slangasek> but I guess upstream is in poking distance, so they can fix it for next time ;0
<slangasek> ;)
<ahasenack> yeah, I could cheat even for this one I guess
<ahasenack> anyway, good to understand what is going on
<ahasenack> thanks
<ahasenack> good to know about remerge too
<ahasenack> since bzr merge-upstream --no-plugins wouldn't work :)
<cjwatson> Indeed :)
<SpamapS> hrm, this is an odd nut here..
<SpamapS> https://launchpadlibrarian.net/106616529/apt-get-install.log
<SpamapS> install zookeeperd on a fresh quantal box...
<SpamapS> the dep chain is  zookeeperd->zookeeper->default-jre-headless->openjdk-7-jre-headless ...
<SpamapS> but somehow, default-jre-headless is configured *before* openjdk-7-jre-headless
<cjwatson> any Recommends or circular dependencies involved?
<SpamapS> then zookeeper is  configured, and then zookeeperd, which then fails because start-stop-daemon: unable to stat /usr/bin/java (No such file or directory)
<SpamapS> the java world is one big circular dependency .. so its quite likely
<cjwatson> Doesn't seem likely that e.g. openjdk would depend on zookeeper though
<SpamapS> ahh, --no-install-recommends produces a different order
<SpamapS> the "correct" order
<slangasek> SpamapS: I'm confused, I don't see the error you're describing in that log (zookeeper start/running, process 9007)
<SpamapS> slangasek: thats just the script
<SpamapS> slangasek: it fails shortly thereafter
<dobey> hi SpamapS
<slangasek> so the package configuration doesn't guarantee a working package?
<slangasek> anyway, ca-certificates-java is almost certainly part of the lovely dependency loop... not sure why zookeeper turns up in the middle though
<dobey> also, can someone accept ubuntuone-control-panel into precise-proposed ? i've added the test/regression headings as requested on its bugs as well.
<slangasek> possibly because zookeeper only depends on default-jre-headless, which *is* configured, so dpkg/apt have no reason to think zookeeper can't also be configured?
<SpamapS> slangasek: yeah not sure, start-stop-daemon should be returning 0, meaning that the job shouldn't show 'started' .. but maybe it returns non-zero *after* forking
<slangasek> that's a buggy assumption of course, it should entirely solve the dependency loop before proceeding
<SpamapS> slangasek: but default-jre-headless depends on openjdk-7-jre-headless
<slangasek> yes, but there's a dependency loop
<slangasek> it has to be broken *somewhere*
<SpamapS> slangasek: so default-jre-headless shouldn't be configuring until after openjdk-7-jre-headless
<slangasek> we appear to be going in circles about loops ;)
 * SpamapS agrees and tries desperately to avoid crossing the streams
<SpamapS> slangasek: something in the Recommends path changes the problem :p
<slangasek> oh actually, I hallucinated that loop
<slangasek> default-jre-headless isn't part of the loop
<slangasek> SpamapS: this seems to not be the ca-certificates-java in quantal though, which is still -6-?
<SpamapS> slangasek: right, seems to dep only on 6
<SpamapS> slangasek: but openjdk-7-jre-headless does Provide: java6-runtime-headless
<SpamapS> don't we have tools for finding circular deps?
<slangasek> circular deps are not a bug
<slangasek> ah, so the problem is that default-jre-headless *also* Provides: java6-runtime-headless
<slangasek> so apt/dpkg get confused and decide that the circular dependency is between default-jre-headless, openjdk-7-jre-headless, and ca-certificates-java
<slangasek> when it's supposed to only be between openjdk-7-jre-headless and ca-certificates-java
<slangasek> SpamapS: I think the workaround is to drop the provides from default-jre-headless
<slangasek> SpamapS: but it's still a bug in the package manager's configure ordering
<SpamapS> slangasek: so, should I open a dpkg task on bug 1007433 ?
<ubottu> Launchpad bug 1007433 in zookeeper (Ubuntu) "zookeeperd not running after installation of zookeeperd" [Medium,In progress] https://launchpad.net/bugs/1007433
<hyperair> why is upower refusing to allow me to hibernate? =\
<slangasek> SpamapS: seems like it
<hyperair> it seems to be a polkit issue.
<hyperair> aha, found it: http://askubuntu.com/questions/94754/how-to-enable-hibernation-in-12-04
<larsduesing> cyphermox: if you are still here, i fixed the changelog
<ahasenack> Daviey: around?
<ahasenack> Daviey: fwiw, #1004678 is back in sponsorship, I also just subscribed ubuntu-sponsors
<ahasenack> Daviey: just pinging you because you took a look before
<bdmurray> slangasek: do you have an idea of what is wrong in bug 991282?
<ubottu> Launchpad bug 991282 in initramfs-tools (Ubuntu) "package linux-image-3.2.0-24-generic 3.2.0-24.37 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1" [Low,Confirmed] https://launchpad.net/bugs/991282
<slangasek> bdmurray: a wrong successful exit from mkinitramfs?  Maybe a wrong mkinitramfs on the path that's not from Ubuntu?
<bdmurray> a modified mkinitramfs should show up in the bug description
<slangasek> bdmurray: right, but it could be in /usr/local/bin or something
<bdmurray> ah, sure
<maco3> is there some sort of rule that says "the more you learn about how something works, the weirder the error conditions you hit become"?
<penguin42> maco3: You do normally manage to make more complex configs and work past the simpler errors to points where less knowlegeable people won't have reached
<penguin42> maco3: The other theory is the code  is just out to get you
<maco3> penguin42: i learned today that doing a dist upgrade inside of byobu is a bad ide
<maco3> *ideda
<maco3> *idea
<maco3> grawr
<penguin42> the boyobu died during the upgrade?
<maco3> yep
<maco3> ps tells me dpkg is still running and trying to ask me questions
<maco3> i just can't *answer* the questions
<penguin42> is that a valid bug in byobu?
<maco3> probably not? i think python is was mid-upgrade
<maco3> you're technically supposed to close all applications before going to a new release
<penguin42> hmm - I wouldn't expect screen to die in those circumstances
<maco3> its just not the sort of thing i think of as an "application"
 * penguin42 doesn't know enough about python to know if it's supposed to be able to cope - it's a mess if it can't
<maco3> JanC just pointed out that when running an upgrade remotely is when you *really* want screen
<JanC> I think the server upgrade notes recommend that actually
<JanC> I'm sure Debian recommends it
<penguin42> yeh it's good for when the network disappears during the upgrade
<Laney> yeah it's known when screen gets upgraded
<Laney> for example http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644788
<ubottu> Debian bug 644788 in screen "screen 4.1.0 can't attach to a running or detached screen 4.0.3 session" [Important,Open]
<JanC> ah, so screen is still running, but you can't attach?
 * maco3 raises an eyebrow
<Laney> if it is this bug
<JanC> that's ugly  :-/
<JanC> does tmux have the same issue?
<maco3> that bug only talks about if you get disconnected from the ssh session
<maco3> i was connected the entire time. screen stopped
<JanC> Laney: I guess that's why Debian makes you upgrade some essential packages first, then the rest?
<maco3> https://bugs.launchpad.net/ubuntu/+source/screen/+bug/1007658 <- my bug
<ubottu> Launchpad bug 1007658 in screen (Ubuntu) "Screen crashed during do-release-upgrade, won't resume" [Undecided,New]
#ubuntu-devel 2012-06-02
<tremolux> slangasek: hello! are you still around? I just wanted to let you know that I've verified the fix in software-center 5.2.2.2 ...
<tremolux> slangasek: going to grab some dinner, but I will check scrollback in case you are around..and thanks!
<slangasek> tremolux: ok, going ahead with publishing - thanks
<vibhav> Could anybody nomiante https://bugs.launchpad.net/ubuntu/+source/pcmanfm/+bug/853507 for oneiric?
<ubottu> Launchpad bug 853507 in pcmanfm (Ubuntu) "pcmanfm crashed with SIGSEGV in fm_nav_history_get_cur()" [Medium,Fix released]
<sladen> vibhav: done
<vibhav> thanks sladen
<oyost> hey guys
<oyost> i needed help in using Quickly, any dev here?
<tremolux> slangasek: thank you so much!!  :D
<jtaylor> what should be done with fftw3? it now depends on mpi in debian, I guess thats not suitable for main?
<apachelogger> do we actually have an ical file for the release schedule?
#ubuntu-devel 2012-06-03
<Bluefoxicy> why the heck does mountall require plymouth
<Bluefoxicy> haha 2009 "this is a temporary tool"...
<izx> Is this the right place to ask about setting up debian/rules for a specific scenario?
<micahg> cjwatson: when you get a chance, your update-manager build seems to have gone haywire: https://launchpad.net/ubuntu/+source/update-manager/1:0.161/+build/3542556
<Roshan> Hello
<trijntje> Hi all, I'm very new to doing any kind of development work, and I'm trying to put a local bzr branch on launchpad, as per http://doc.bazaar.canonical.com/bzr.2.5/en/mini-tutorial/index.html#publishing-your-branch-on-launchpad
<trijntje> however, I get this error (http://paste.ubuntu.com/1021043/) and I dont know what to do about it. I've tried searching for that error message, but nothing usefull came up
<Roshan> I have two questions to ask of which one is not about developing and the other is about developing.
<Roshan> First one, which is stable 11.10 or 12.04 ?
<Roshan> Second one, Is it possible to alter the location of the password field in Ubuntu login screen ?
<trijntje> 12.04 is stable, and I think it should be possible to change the location of the password field for lightdm, but I'm not sure
<Roshan> I asked about the stability because, I made a clean install of 12.04, and what i felt in the login screen is that, there is a heavy lagging of the mouse pointer there...
<trijntje> Roshan: If you have problems with 12.04, you should probably ask for support in #ubuntu
<Roshan> Okay, sorry for that, I wioll do that. Can you answer my second question ?
<Roshan> Also, what is the difference between lightdm and gdm2
 * trijntje is afk, will read back if anyone knows the solution
<roshan> Do I need to edit loginprompt.ui for changing the location of the password field in ubuntu login screen ?
<roshan> Hello
<larsduesing> roshan: please ask in #ubuntu-desktop
<roshan> ok thank you
<larsduesing> np
<cjwatson> micahg: yes, I know about it but I'm away from my development environment until Tuesday.  I sent mail to mvo and slangasek yesterday morning explaining the problem and my thoughts on it, and asking for help
<cjwatson> my best thought is to remove the -h option to tar in build-tarball.sh, but I didn't have time to check whether that would break anything else
<vibhav> https://bugs.launchpad.net/quickly/+bug/1007006 --> Is it worth an SRU for precise?
<ubottu> Launchpad bug 1007006 in quickly (Ubuntu Precise) "Fresh ubuntu-cli 12.04 project warn about PyGI" [Undecided,Confirmed]
<vibhav> mterry: ^^
<vibhav> !sru
<ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<vibhav> https://bugs.launchpad.net/quickly/+bug/1007006 --> Is it worth an SRU for precise?
<ubottu> Launchpad bug 1007006 in quickly (Ubuntu Precise) "Fresh ubuntu-cli 12.04 project warn about PyGI" [Undecided,Confirmed]
<elky> vibhav, i wouldn't think so.
<vibhav> elky: why?
<elky> It looks like it doesn't actually break anything, just prints an annoying message. That doesn't sound like a high-impact bug to me.
<vibhav> elky: I was too thinking that but it was nominated by a MOTU, hence the question
<elky> Then wait for mterry to appear and answer your query from an hour ago. There's no need to be asking hourly.
<PaoloRotolo> Hi all!
<micahg> cjwatson: can I at least have the build killed later?
#ubuntu-devel 2013-05-27
<pitti_> Good morning
<pitti> bdmurray: FYI, I fixed the eternal sru-report crash on missing "published" attribute in r713 and (in a better way) r717; I hope the sorting will be alright with that
<pitti> @pilot on
<udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<pitti> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<dholbach> good morning
<mlankhorst> g'day
<bl4de> hi to all! :)
<bl4de> Guys, I've an idea (I've a dream ;) ). I'd like to write a Qt opensource SublimeText editor, 100% compatible with the original plugin packages, with same characteristics etc, but there is too much work for only me. I'd not experience for creating a brand new editor widget for qt, so I want to create a team. Who can join and help me?
<bl4de> *I've not
<bl4de> Languages are C++ for editor and Python for plugin system
<mitya57> bl4de: you probably want #ubuntu-app-devel
<bl4de> mitya57, thank you, I'll try also there :)
<pitti> yolanda: please forward your autopkgtests to Debian; e. g. your quagga one introduces an Ubuntu delta, and thus will require merging from now on
<yolanda> ok, i saw the new approved branches, i'll do it
<pitti> thanks
<pitti> yolanda: great to see so many new tests!
<pitti> many of them are just "daemon running", and no functional behaviour, but that alone already covers quite a bit
<pitti> yolanda: are you transitioning the old qa-regression-tests over to autopkgtests?
<yolanda> pitti, i'm just copying tests from qa-regression-test branches to autopkg in the case that there are some, but nothing more. What do you mean with transitioning?
<pitti> yolanda: yes, that's what I meant
<pitti> "moving over"
<yolanda> well, i copied the tests, is there something else i should do for it? should i inform someone, maybe the authors of that branch?
<pitti> yolanda: no, that's fine; well, they should be forwarded to Debian
<yolanda> i'm normally moving the approved ones, i have some to forward today
<yolanda> pitti, i saw a failure for ganglia
<yolanda> did you see it?
<pitti> no, I didn't -- it's not yet on https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/
<pitti> oh, you mean the powerpc build failure?
<pitti> yes, that needs to be addressed; the previous version built
<pitti> I guess it's enough to retry the build once librrd-dev becomes installable again on ppc in saucy-proposed
<yolanda> yes, the powerpc
<cjwatson> That'll be fixed after the next publisher run
<cjwatson> pangox-compat was a bit behind in building
<pitti> yolanda: I'll retry the ppc build in a bit
<yolanda> great
<cjwatson> Or I'll do a mass retry of affected stuff after the next publisher run - I have a script to help me out a bit
<pitti> even better (gnome-control-center also failed due to this)
<pitti> hey sabdfl, how are you?
<sabdfl> well thanks pitti, how about you?
<pitti> sabdfl: quite fine, thanks!
<sabdfl> got the phone up and running near you?
<pitti> no, I only have an n7
<pitti> so using wifi :)
<sabdfl> looking good, huh
<pitti> until we get a build for the Sony xperia :)
<tvoss> pitti, seems like some images are available for sony xperia: https://wiki.ubuntu.com/Touch/Devices
<tvoss> pitti, although not from cdimage.u.c
<pitti> yeah, for the neo; I have the mini pro
<pitti> (mango)
<tvoss> pitti, ah :)
<pitti> btw, are we going to have daily saucy builds for the n7 at some point? or do you guys prefer to stick on raring for now? (moving target vs. not picking up fixes)?
<didrocks> pitti: it's going to be saucy in the next few days (hope by end of the week AFAIK)
<pitti> \o/
<cousteau> https://bugs.launchpad.net/ubuntu/+source/freehdl/+bug/291075
<ubottu> Launchpad bug 291075 in freehdl (Ubuntu) "Digital simulation in qucs don't work" [Undecided,Confirmed]
<cousteau> this bug has been around since 2008 and still not fixed (at least for Precise).  The fix seems to consist in changing a line from a Perl script.  Could somebody do something to fix this?
<cousteau> (the patch has been there since 2008 as well)
<cousteau> found this bug when running gvhdl manually, not through Qucs
<pitti> cousteau: that ought to be fixed in raring?
<cousteau> well, the freehdl version of raring and precise are the same
<cousteau> that should have been fixed in freehdl 0.0.6-something, actually; and 0.0.7 has been there since lucid
<pitti> cjwatson: do you have an opinion about https://code.launchpad.net/~diwic/dpkg/original-maintainer/+merge/165107 ? it seems fine to me, as we introduced that field
<cjwatson> pitti: IMO should be sent to Debian for comment; it's not urgent so can afford to go through review there
<pitti> cjwatson: ack, thanks
<diwic> cjwatson, to me it's ubuntu specific
<cjwatson> Original-Maintainer is mentioned in the upstream code, since Dpkg::Vendor::Ubuntu is carried there
<cjwatson> So please forward it first even if you think it's Ubuntu-specific
<cjwatson> We want to get to zero delta in dpkg eventually if we can possibly manage it
<diwic> cjwatson,  hmm, ok
<cjwatson> (Dpkg::Vendor::Ubuntu is the result of an earlier attempt to get to zero delta, and made a big dent even if it didn't get us all the way there)
<diwic> want me to upstream it or is it better that pitti or cjwatson  does it if you know the dpkg people better?
<cjwatson> I think you can go ahead and upstream it yourself
<cjwatson> Just file a bug against Debian's dpkg package
<diwic> cjwatson, ok, will do. Thanks
<pitti> thanks diwic
<cjwatson> I do think it's a reasonable change, but since it's cosmetic I'd like to avoid it resulting in an extra delta to maintain, that's all
<diwic> even dpkg itself has this build warning in Ubuntu :-)
<tvoss> didrocks, ping
<didrocks> tvoss: pong
<pitti> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> pitti: Hmm, I'm trying to work out what's going on with an image build failure; currently only Mythbuntu but I suspect it'll bite other flavours / upgrades shortly
<cjwatson> cp: cannot stat '/module-files.d/libpango1.0-0.modules': No such file or directory
<cjwatson> cp: cannot stat '/modules/pango-basic-fc.so': No such file or directory
<cjwatson> pitti: Do you know where those files have moved to?
<pitti> hey cjwatson (back from lunch)
<pitti> cjwatson: not out of hand, I don't seem to have these files anywhere; is that a  failure during package installation, or from the live-build scripts?
 * pitti reviews recent changes
<pitti> cjwatson: oh, is that for the udeb? ./debian/libpango1.0-udeb/usr/lib/x86_64-linux-gnu/pango/1.8.0/modules/pango-basic-fc.so and ./debian/libpango1.0-udeb/usr/lib/x86_64-linux-gnu/pango/1.8.0/module-files.d/libpango1.0-udeb.modules
<pitti> ah no, it's from /usr/share/initramfs-tools/hooks/plymouth apparently
<seb128> pitti, we probably need changes to plymouth from the discussion I saw on #debian-gnome about the new pango
<pitti> ah, so that was from http://anonscm.debian.org/viewvc/pkg-gnome?view=revision&revision=36846
<pitti> cjwatson: ^ so the separate files are included in the .so's now, part of the split/multiarchification
<pitti> seb128: right, seems we can drop all this
 * pitti verifies that the pango library itself is in the initramfs
<pitti> yes it is, and I can reproduce the error with update-initramfs -u
 * pitti uploads fix
<cjwatson> pitti: it's from update-initramfs in a livefs build
<cjwatson> pitti: right - thanks
<pitti> cjwatson: ok, verified that plymouht still displays text correctly now (I added a bogus block device to wait for into /etc/fstab)
<pitti> argh, /me uses the actual source this time instead of the outdated UDD branch
<pitti> cjwatson: ok, verified that plymouht still displays text correctly now (I added a bogus block device to wait for into /etc/fstab)https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/ \o/
<pitti> yolanda: ah, your tests are trickling into https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/
<pitti> yolanda: most of them succeed, except clamav
<yolanda> :(
<pitti> dsc0t-clamd          FAIL non-zero exit status 52
<pitti> there's no output at all from this
<pitti> bbl, need to head out for some errands
<yolanda> locally works for me, do you have any idea why it fails?
<mitya57> pitti: wow, you managed to reduce the queue by half â very nice!
<pitti> bdmurray: bah, with the "today" datetime fallback I now get "TypeError: can't compare offset-naive and offset-aware datetimes"
<pitti> bdmurray: would you have any idea how to make this work properly?
<fhf> Hi all I created new bazaar branch but I cant compile program using bzr builddeb -- -us -uc it gives following error: bzr: ERROR: Unable to find the needed upstream tarball for package; but there is no upstream I created package myself. Could any1 help?
<bjsnider> how does the multiarch directory structure get implemented? should it work in ppa packages?
<cjwatson> It doesn't care about the package's origin
<cjwatson> http://wiki.debian.org/Multiarch/Implementation
<bjsnider> ah, i think i know what was wrong. compat 7 instead of 9
<cjwatson> bjsnider: Do review the entirety of that wiki page, or at least the section relevant to your style of packaging; converting to multiarch requires care
#ubuntu-devel 2013-05-28
<pitti> Good morning
<dholbach> good morning
<cjwatson> ubuntu-mir: please have a look at bug 1184927
<ubottu> bug 1184927 in libnet-smtp-ssl-perl (Ubuntu) "[MIR] libnet-smtp-ssl-perl" [Undecided,New] https://launchpad.net/bugs/1184927
<yolanda> pitti, tested clamd locally and works, do you know why it can be failing?
 * pitti runs it in a VM
<pitti> whoa, this takes a long tie
<pitti> time, even
<brendand> it looks to me like touchpad's used to have a 'Touch mode' attribute in xinput --list, but now they don't? but touchscreens still do
<cjwatson> didrocks,doko: could either of you have a look at bug 1184927?
<ubottu> bug 1184927 in libnet-smtp-ssl-perl (Ubuntu) "[MIR] libnet-smtp-ssl-perl" [High,New] https://launchpad.net/bugs/1184927
<didrocks> cjwatson: just answered on it, promoting now
<cjwatson> ah, thanks
<didrocks> yw :)
 * cjwatson gives it a bug sub as well
<pitti> yolanda: succeeds here too (I already ran it yesterday); perhaps this needs network access?
<didrocks> (done)
<pitti> yolanda: the DC has restricted network access; there is a proxy
<yolanda> pitti, this just tests that the daemon starts, but let me try without internet access anyway
<pitti> yolanda: the test runs awfully long, perhaps the daemon itself is downloading stuff at first startup?
<pitti> yolanda: in that case, perhaps the test can put in a tiny dummy DB
<yolanda> pitti oh, yes, the freshclam
<yolanda> that's the issue, yes
<yolanda> without that, clamd doesn't start
<xnox> doko: when are you planning to have first archive rebuild? after Debian Import Freeze?
<doko> xnox, when binutils is updated to the trunk, hopefully next week
<xnox> doko: ok, awesome.
<tvoss> ogra_, ping
<ogra_> tvoss, jau
<pitti> could anyone sponsor my systemd upload in http://people.canonical.com/~pitti/tmp/ (systemd_202-0ubuntu8_source.changes)
<pitti> I lost my GPG key an hour ago, and it's kinda nontrivial to retrieve it :(
<cjwatson> moment
<pitti> cjwatson: ^ FYI, this adds the /sbin/udevadm symlink to the initramfs
<cjwatson> ta, was hoping for that :)
<cjwatson> pitti: done
<asac> so i am not sure whats going on :)
<asac> i am stuck at runlevel N 2 ... with / being ro mounted
<asac> but can't find any error in dmesg etc.
<asac> i can mount / -o remount to get a writeable FS
<asac> and use irrsi now :)
<asac> any ideas?
<asac> this is raring
<tseliot> cjwatson: do you mind if I remove ${misc:Depends} from nvidia-persistenced? It's because of this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709482
<ubottu> Debian bug 709482 in debhelper "dh_installinit: permit file-rc for upstart jobs" [Serious,Open]
<cjwatson> tseliot: uh, file-rc doesn't exist in Ubuntu, so there's no need to take account of that bug in Ubuntu
<cjwatson> So yes, I mind :)
<tseliot> cjwatson: oh but we don't have that version of sysv-rc either
<cjwatson> Sure we do
<cjwatson>    sysv-rc | 2.88dsf-41ubuntu1 |         saucy | all
<tseliot> cjwatson: what about Precise? I'm supposed to backport this to Precise
<cjwatson> tseliot: precise has a different dh_installinit
<cjwatson> And it doesn't add that dependency - if it did we would be in trouble!
<pitti> cjwatson: cheers
<cjwatson> tseliot: You know that pretty much every other package in the distro that ships upstart jobs relies on dh_installinit, right?
<cjwatson> If it works for them, it ought to work for you
<cjwatson> I don't mind if you need some tweaks, but dh_installinit should be the baseline
<tseliot> cjwatson: ok, it's the first time I use it and I'll keep it in mind for any other packages that install upstrart jobs
<ogra_> xnox, if you feel like taking a look, i just uploaded android-tools with an adbd patch
<ogra_> (surely needs more cleanup)
<xnox> ogra_: cool.
<hrw> ogra_: looks like it is around time for me to take a look at ubuntu changes ;D
<ogra_> hrw, yeah, we're at ubuntu4 already :)
<hrw> ogra_: ;)
<hrw> ogra_: and I can do changes only though Debian now ;)
<ogra_> well, you dont want my latest patch directly in debian i guess
<ogra_> it largely duplicates core/adb
<asac> xnox: hey ... any idea how i can find out why my system mounts / in ro?
<hrw> ogra_: it adds new binary package so I would not be able to upload it anyway
<asac> xnox: i cant find anything interesting in dmesg/syslog
<asac> have run fsck in recovery ... no errors
<ogra_> i guess you rather want to build twice in core/adb and have it spit out adb annd adbd in succession
<asac> etc.
<ogra_> hrw, oh, now i get it
<asac> xnox: also nothing about mount in /var/log/upstart ... no clue what is going on :)
<xnox> ogra_: to be honest your way is cleaner than doing two vpath builds & dealing with clashing objects. Why did you commit the tree instead of doing "cp adb/ adbd/" in debian rules as first step, and "rm -rf adbd/" in clean?
<xnox> (s/commit/add to the patch/)
<hrw> +1 to xnox note
<xnox> or are the two trees different?
<ogra_> xnox, because it isnt completely identical
<mitya57> xnox, doko: hi, what's the status of qt4-x11/gcc fixes?
<mitya57> do you want a patch from me that disables pch?
<xnox> ogra_: i thought it was mostly conditionals + some extra files for the other one.
<ogra_> well, diff the two dirs :)
<xnox> mitya57: yes, that is the way forward at the moment.
<xnox> ogra_: ok, I should.
<xnox> ;-)
<ogra_> most can likely be #IFDEFed
<xnox> asac: /var/log/boot.log?
 * mitya57 copies some lines from debian
<ev> stgraber, ogra_: I don't suppose either of you know where we stand on the chroot flip on ubuntu mobile, and if there is a bug or ML thread or something that I can use to track progress?
<ogra_> dunno, ubuntu mobile is dead since a few years :P
<ogra_> ev, but joking aside, we should have something by end of the week
<ev> hahaha
<ev> cool
<mitya57> xnox: lp:~mitya57/kubuntu-packaging/qt-no-pch (not tested, obviously)
<ogra_> ev, https://blueprints.launchpad.net/ubuntu/+spec/client-1303-containers-host-client-ubuntu-android
 * Laney meeps at mitya57 
<Laney> I saw you were looking at getting vte.sh sourced somehow - where does that stand?
<xnox> mitya57: thanks, will run a test build on arm here.
<ev> ah! That's exactly what I was after. Thanks ogra_
<ogra_> ev, i should be done with the initrd stuff today and will start working on the lxc bits
<mitya57> Laney: after your update in Debian it stopped working for me
<Laney> you should just have to source it
<Laney> that works for me anyway
<mitya57> I also asked doko to see if we can create something like /etc/bash.rc.d, but he didn't say anything yet
<asac> xnox: doesnt complain about anythging there
<asac> let me reboot one more time
<doko> ugly
<mitya57> Laney: but we aren't going to make all users source it from their ~/.bashrc, right?
<Laney> no
<Laney> but I don't know what a good solution looks like
<mitya57> doko: maybe we can follow Fedora (i.e. source /etc/profile.d/* in both login and non-login shells)?
<doko> apw, ogasawara : did you have a chance to have a look at the binutils in ubuntu-toolchain-r/test ?
<Laney> mitya57: A parallel solution will have to be done for zsh too
<Laney> (since vte.sh supports it)
<mitya57> Laney: yes, and that sounds like the least hacky solution to me (following Fedora)
<Laney> I don't know anything about the arguments for/against that, but I bet people have opinions
<mitya57> Laney: "after your update in Debian it stopped working for me" â please ignore, works fine now
<xnox> asac: not sure how to get more logs, as well filesystem is readonly and we need to output logs somewhere.... have you tried booting in to live CD and doing fsck / mounting the filesystem to see if everything is ok with it?
<apw> doko, now i did start, but i can nolonger remember how far i got
<yolanda> hi, i'm looking to install clamav-freshclam database files locally, but i'd like to have a set of smaller files to embed them, anyone knows about it? clamav-freshclam files are more than 30mb each
<tvoss> mmrazik|afk, ping
<mmrazik> tvoss: pong
<tseliot> cjwatson: if the diff looks good to you I'll reupload nvidia-persistenced
<cjwatson> tseliot: it's fine with the modification I sent by mail
<psusi> cjwatson: the bzr branch of grub2 appears to be buggered... trying to build a clean bzr branch of lp:ubuntu/grub2 gets me a bunch of dpkg-source errors about upstream files changed, a number of which it thinks are binary files even though they are not.
<cjwatson> psusi: wrong branch anyway
<cjwatson> apt-cache showsrc grub2 | grep ^Vcs
<psusi> cjwatson: I thought that lp:ubuntu/grub2 was an alias to that ( at the appropriate release )?
<cjwatson> It is not
<cjwatson> Sorry
<cjwatson> If I make it an alias then the automatic importer will start mucking around with it and I don't want it to
<zul> mterry:  ping
<psusi> ugh... sucks having multiple branches especially when the canonical one is bad
<cjwatson> Honestly I'd rather finish getting everything synced up with Debian and then completely ignore any Ubuntu branches
<mterry> zul, pong, about the MIRs?  I'm going to look at them today
<zul> mterry:  cool thanks
<psusi> whether they are actively used for development or not, you should still be able to branch from them and get the correct and working sources
<psusi> even if it is just an auto import of the source deb
<cjwatson> Sorry, not a problem I'm going to spend any time on
<cjwatson> I'm sure it can be made to work with some fiddling
<cjwatson> But it's not worth any of my time, because any branches people create based on that won't be mergeable into the branches I care about anyway
<psusi> cjwatson: lp:~ubuntu-core-dev/ubuntu/raring/grub2/raring also fails to build.. quilt patches won't apply because they are already applied... I am guessing you did a merge from the debiaan branch that already had them applied into the ubuntu branch, which keeps them unapplied?
<psusi> maybe I'll have better luck with apt-get source...
<iBelieve> Is there any requirement for the language and toolkit chosen for working on new Ubuntu apps? I worked on Contributor Console a while back (https://wiki.ubuntu.com/ContributorConsole) using Gtk and Python, but I would prefer to use Qt and C++ or Python. Would this be okay?
<xnox> iBelieve: yes.
<iBelieve> xnox, Yes, meaning yes it is okay? I know Ubuntu apps can be written in any language & toolkit, but I wanted to double check on this since it is an Ubuntu-designed app for inclusion in Ubuntu.
<xnox> iBelieve: we often have preferred technologies and toolkits, but it's not very constrained. Something GUI targetting desktop can be written in Gtk/Qt in any of languages those support. For touch friendly UI on Ubuntu Touch platforms QML/Qt is the only one supported at the moment.
<xnox> iBelieve: all of above toolkits are in "main" and are good dependencies, that will be provided on Ubuntu for a long time.
<brendand> xnox, thanks for the pyqt5 info :)
<iBelieve> xnox, Okay, thanks for clarifying that for me.
<xnox> brendand: =)))) hehe.
<brendand> xnox, do you know anything about how to add bindings?
<brendand> xnox, or someone who does?
<xnox> brendand: i have a branch & ppa somewhere with best efforts. Not sure where mitya57 hosts his at the moment. But yeah, there are not enough bits to have Declarative2.0 nor even attempt running Ubuntu Touch components.
<xnox> brendand: well riverbank uses "sip" to generate bindings from C++ libraries, so if you look into pyqt source package you will notice all the files that are used to create the bindings from the c++ Qt libraries. But I don't have more info/knoweledge in writing those.
<brendand> xnox, having a look at your best efforts might be informative
<brendand> xnox, yeah i saw about sip, but no idea how to use it
<xnox> brendand: i'm guessing we'll need bindings for QtQuick + any other qtubuntu-* libraries we wrote.
<xnox> but I'd rather wait for riverbank to wrap QtQuick, it's getting closer.
<brendand> xnox, yeah, but we somewhat don't have the luxury of time
<xnox> brendand: what's the story with python? I would rather thought that python uses too much memory and battery to run UI apps.
<xnox> brendand: oh. we need python?! I see. when do you want it by? july? october?
<tseliot> cjwatson: I think I've fixed it for good
<brendand> xnox, well this isn't quite what you think it is i guess
<brendand> xnox, we have the whole core of our application written in python
<brendand> xnox, and we have to implement a ui in the next 3 months
<brendand> xnox, so we need to decide the toolkit to use
<brendand> xnox, ubuntu sdk sounds good, but then there's the question of interfacing with the python core
<brendand> xnox, we aren't even neccesarily talking about running on the phone
<ogra_> long trem that will be the same :)
<xnox> brendand: i see.
<ogra_> *term
<ogra_> theoretically depending on the platform api should get you what you want
<xnox> brendand: it's a hard choice. And python-qt5 is not here yet. But using pyqt4 (without deprecated / removed in qt5 functionality) should be ok. You will not have QtDeclarative 2 (aka quick) today, but there is declarative 1 packaged with pyqt4.
<xnox> brendand: I am expecting that saucy will ship pyqt5 in one way or another. And there is a chance it will have declarative (aka QtQuick)
<brendand> xnox, i was of the understanding that the ubuntu sdk will not work with Qt4
<xnox> brendand: it doesn't. ubuntu-sdk = Qt5 + custom touch widgets for mobile/touch platforms + webkit (... and JS frameworks) + other libraries (e.g. android hw sensors)
<xnox> it's a meta-package =)
<xnox> brendand: at the moment python is not part of it, at all.
<brendand> xnox, ok, so if we narrow down to just the widgets - can we use that with Qt4?
<brendand> xnox, that's really all we want
<xnox> brendand: but if you are after python, using pyqt4 with expectation to migrate to pyqt5 once it's availabe. is the best bet.
<brendand> xnox, we mainly want to avoid writing our own widgets
<cjwatson> psusi: I strongly prefer keeping patches applied, yes.  Use http://paste.ubuntu.com/5710351/ if it helps
<xnox> brendand: well the desktop UI widgets is part of standard Qt and are available in both qt4 & qt5. (the ones to drive with mouse ;-) )
<xnox> brendand: the UbuntuTouch components are for Qt5 with QML and QtQuick only at the moment.
<cjwatson> psusi: You're mistaken that the Ubuntu branch keeps them unapplied - it's just that .pc isn't checked in
<cjwatson> So you can use that dpkg-quilt-setup script to initialise things properly
<xnox> brendand: maybe you should talk to ubuntu-sdk team. they might have better answers for you.
<yolanda> anyone with experience with clamav?
<Laney> yolanda: try ScottK
<yolanda> ScottK , i'm trying to generate a set of small cvd files just for testing, without connecting to net and executing freshclam, but i'm having some issues
<qengho> Hi all.  I'm talking with an upstream who is introducing a "helpful" step in their build system that bodily copies 'foo-dev' package's files into their source tree, overwriting ones there already, if you indicate that you don't want to use their bundled foo library.  There's no obvious "clean" step after this. I think I should argue with them that this is a bad idea, but I don't know all the rationalle in debian-policy for the clean step of rules.
<qengho> What problems does it solve?
<qengho> We compare the result of clean to the orig tarball, right?  Why?
<xnox> qengho: whilst it's unhelpful, you just have to make sure you use e.g. a bzr branch for packaging and do $ bzr bd to do out of the tree builds. If you do not intend to patch the libraries, then you can extend ./debian/source/options to ignore diff in the mangled directory.
<xnox> see dpkg-source manpage for more info.
<qengho> xnox: okay, yes, am using bzr u-d-d and it's 3.0 (quilt) format.
<xnox> qengho: the package should build twice in a row, as per debian policy. So clean; binary; clean; binary should work from the same unpacked tree. And there are plently of package that modify their original sources at build time.
<xnox> so yeah, just extend ignore diff option, and carry on.
<qengho> xnox: yes,  I do not intend to patch any of the files that they'd be copying in to their tree from the rest of the distro..
<smb> pitti, Do "we" know of any udev related issues in current saucy? (maybe related to previous udevadm mentioned)
<pitti> smb: until a few hours ago we didn't have the /sbin/udevadm compat symlink in the initramfs
 * smb sees Xen guest failing to mount/find /dev elements and there are missing lvm symlinks
<tvoss> mmrazik, ping
<pitti> aka bug 1184066
<ubottu> bug 1184066 in casper (Ubuntu) "Cannot boot usb live media: hardcoded paths to udevadm (2013.05.24 daily live)" [Critical,Fix released] https://launchpad.net/bugs/1184066
<pitti> smb: oh, I don't know about that one
<smb> pitti, Yeah, the guests probably have that issue
<smb> I mean not getting /dev/null and such
<pitti> so far I have https://launchpad.net/ubuntu/+source/systemd/+bugs under tight control (and am subscribed)
<cjwatson> 1184066 shouldn't affect xen guests itself, unless they have scripts that call /sbin/udevadm
<mmrazik> tvoss: pong
<pitti> even that, in the actual system the symlink has always been there
<cjwatson> ... in the initramfs, yes
<cjwatson> the only ones I found in my initramfs were casper and cryptsetup, and I fixed both
<cjwatson> hardcoded paths are evil even if they're correct :)
<smb> It feels like the mini-isos / pxeboot I use to install miss things in initramfs
<cjwatson> It would help me if you could explain a bit more precisely what you're seeing?
<cjwatson> e.g. which stage of installation / boot are things failing at, with what error messages, etc.
<smb> cjwatson, I try pxeboot installs which get a kernel panic when trying to kill init and the last messages before say /dev/null cannot be found (twice) and mounting /dev/pts fails
<cjwatson> smb: exactly which image?
<cjwatson> (url)
<smb> cjwatson, A second, I have to check what cobbler-ubuntu-import goes for
<cjwatson> pitti: fwiw, udev-udeb is missing the symlink too - that might not hurt
<cjwatson> rather, adding it there too might not hurt
<pitti> cjwatson: ack; do you want that uploaded now, or should I just stage it in git?
<stgraber> wgrant: FYI, I just "fixed" the lxc saucy branch in UDD. The old branch was completely messed up so I moved it to lp:~ubuntu-branches/ubuntu/saucy/lxc/broken-saucy, took the raring branch, re-imported all the .dsc for saucy and pushed to lp:~ubuntu-branches/ubuntu/saucy/lxc/saucy then changed the branch for the saucy-release to point to it
<smb> cjwatson, http://archive.ubuntu.com/dists/$REL/main/installer-$ubuntu_arch/current/images/netboot/mini.iso
<smb> cjwatson, But let me run the update again to make sure it really is current
<cjwatson> should be easy for me to have a look - one sec
<cjwatson> pitti: let me see how pervasive the problems are
<stgraber> wgrant: I expect the importer to be a bit grumpy about this, however since it hasn't been working for us for over a year anyway, it's not really bothering us that much :)
<smb> cjwatson, Ok not changed but the correct url is http://archive.ubuntu.com/ubuntu/dists/saucy/main/installer-amd64/current/images/netboot/mini.iso
<cjwatson> smb: something is very unhappy here (testing i386), but I'm not sure it's udev's fault
<cjwatson> smb: (bug 1185053, concurrently, from plars)
<smb> cjwatson, It could be something else causing /dev elements to be missing. I was just first-guessing udev because on the already installed host running saucy I got this weird thing of not all symlinks (/dev/mapper and /dev/<vgname>) showing up
<ubottu> bug 1185053 in debian-installer (Ubuntu) "Saucy server images do not boot for 20130528" [Undecided,New] https://launchpad.net/bugs/1185053
<cjwatson> pitti: this installer failure is udev's fault somehow, and it's something different, so certainly don't upload yet :)
<cjwatson> pitti: Shouldn't start-udev be mounting devtmpfs, not tmpfs?  It used to.
<smb> cjwatson, When looking again on the bare-metal boot (the one with many LVs) I see a segfault of systemd-udevd and several "cannot open /dev/null"s
<cjwatson> pitti: http://paste.ubuntu.com/5710472/ - part of diff between broken/working installer images
<pitti> cjwatson: I thought that moved to /lib/init/fstab ages ago
<cjwatson> pitti: not in the udeb
<cjwatson> smb: bare-metal boot of what stage?  the installer, or the installed system?
<pitti> oh, for udeb
<cjwatson> smb: these are completely different stacks and I really need clarity of which you're talking about
<smb> cjwatson, installed system
<cjwatson> smb: ok, that must be some different bug from the one I'm looking at, although it appears to share similar symptoms
<smb> cjwatson, Yes, sorry for throwing them into the middle
<cjwatson> specifically, "cannot open /dev/null" suggests an empty /dev rather than a devtmpfs
<pitti> ah, found the script; I'll update that to the previous version
<ogra_> now whats possibly wrong with that sentence :)
<cjwatson> well, it doesn't have to be the *entire* previous version, which e.g. assumes udevd on $PATH and has a hardcoded /sbin/udevadm path
<pitti> yeah, I mean the /dev and /dev/pts/ mounting
<cjwatson> I wonder how the version in Debian manages to work
<pitti> indeed, that seems ancient (make_extra_nodes..)
<cjwatson> well, that's the version you're using here
<cjwatson> but I don't understand how it works anyway, unless udevd is creating /dev/null manually
<cjwatson> the bug here is basically that you seem to have reverted start-udev to the Debian version, so I'm wondering how the Debian version works :_
<cjwatson> :)
<cjwatson> it might be more sensible to go back to the previous entirely different version we had in Ubuntu, but just update the udevd and udevadm calls
<pitti> yes, that's more or less what I'm doing now; I have the old and current script
<pitti> so, the script more or less looks like the old one now, except for the added "modprobe -q scsi_wait_scan && modprobe -r scsi_wait_scan || true" bits
<pitti> not sure whether d-i has some fake module with that, but it certainly doesn't exist in the running system
<pitti> we didn't have it before, so I'll just drop it
<pitti> cjwatson: after three cleanup commits, http://paste.ubuntu.com/5710512/ is the diff between the old and my current version of the script
<cjwatson> d-i has no such things as fake modules
<cjwatson> pitti: looks ok if you don't need the /proc/sys/kernel/hotplug bit any more
<pitti> cjwatson: it's an alias for /sys/kernel/uevent_helper, and that's a more modern name
<cjwatson> ok
<pitti> i. e. if you echo something to /proc/sys/kernel/hotplug, you get the same if you cat /sys/kernel/uevent_helper
<pitti> (and vice versa)
<pitti> cjwatson: ah, http://lwn.net/Articles/166954/ mentions this as well
<pitti> wow, that was 2006
<zul> mterry:  thanks for looking, i replied to your pbr question
<pitti> cjwatson, smb: ok, time for another upload then, I guess?
<pitti> I should be able to again
<cjwatson> pitti: yes please :)
<smb> At least that sounds like fixing quite some badness. Not sure it also does something with the other oddness but yeah
<mterry> zul, out of curiosity, why is it called pbr?
<zul> mterry:  python build reasonableness
<mterry> zul, :-|
<zul> yeah
<smb> pitti, I don't understand it yet. Somehow starting in xen mode systemd-udevd has some issues with device-mapper/lvm, and when I start in non-xen mode (at least on the amd server) it seems to hang trying to send some xen socket event
<pitti> smb: the former certainly sounds related to the missing devtmpfs (you wouldn't have most stuff in /dev/)
<cjwatson> But start-udev isn't called anywhere but the udeb, is it?
<cjwatson> So if it's a similar bug, it seems like it must be in some other place too
<zul> mterry:  im pretty sure when it hits debian it will come from us anywyays
<smb> pitti, Though after boot at least /dev is a devtmpfs
<pitti> cjwatson: right
<pitti> I thought we arrived at start-udev while debugging smb's problem (sorry, no idea how xen works, I assumed it was during installation)
<smb> pitti, Yeah, sorry the confusion is that I talked about two different issues
<tvoss> didrocks, ping
<smb> pitti, One is with the installation of guests which is what you likely solved
<tvoss> slangasek, ping
<smb> pitti, The other problem is on the already installed host during boot. There seems to be one fallback in initramfs if devtmpfs fails but I cannot say whether that is hit or not as I am not sure where that message would end up in
<slangasek> tvoss: pong
<pitti> cjwatson: as for bug 1185053, did that d-i rebuild include the new udev-udeb? i. e. were we still using the old version before?
<ubottu> bug 1185053 in systemd (Ubuntu Saucy) "Saucy server images do not boot for 20130528" [Critical,Triaged] https://launchpad.net/bugs/1185053
<cjwatson> Yes
<pitti> ah, that explains it then
<pitti> my plymouht change from yesterday really sounds unrelated
<cjwatson> plymouth cannot possibly have anything to do with it; that was misdiagnosis
<cjwatson> plymouth isn't even used at server installer boot time
<cjwatson> I was expecting you to close that bug with your systemd upload, TBH :)
<pitti> cjwatson: yeah, I saw it too late
<pitti> but we need a d-i rebuild for it to really be fixed then
<cjwatson> pitti: yes, I'm waiting for systemd to build everywhere
<cjwatson> (and publish)
<barry> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<ogra_> hmm
<ogra_> Setting up android-tools-adbd (4.2.2+git20130218-3ubuntu4) ...
<ogra_> All runlevel operations denied by policy
<ogra_> invoke-rc.d: unknown initscript, /etc/init.d/android-tools-adbd not found.
<ogra_> dpkg: error processing android-tools-adbd (--configure):
<ogra_> does the new world order require that my package ships a sysvinit script ?
<ogra_> (with the init_is_upstart stuff ... )
<ogra_> i was assuming if i only create a .upstart file debhelper takes care of the rest, isnt that the case ?
<ogra_> hmm
<ogra_> Setting up libpam-systemd:armhf (202-0ubuntu8) ...
<ogra_> All runlevel operations denied by policy
<ogra_> invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
<ogra_> seems to have the same issue
<pitti> cjwatson: seems we can rebuild d-i now; are you on it, or shall I upload a rebuild?
<ogra_> ah, libpam-systemd makes all other arches fail too
<ogra_> slangasek, ^^^ is having an debian/*.init script mandatory with https://wiki.ubuntu.com/UpstartCompatibleInitScripts ?
<slangasek> ogra_: cjwatson and I discussed this bug already; this is actually an unanticipated bug in invoke-rc.d
<slangasek> so I'm working on fixing that
<ogra_> (teh wikipage doesnt really say that)
<ogra_> ah, k
<slangasek> Debian policy does say that you shouldn't ship upstart jobs without corresponding init scripts; however, that's Debian, not Ubuntu
 * ogra_ will give up on image builds for today then
<jdstrand> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry, jdstrand
<slangasek> I'll have a fixed sysvinit package uploaded sometime today.  Basically, this issue only arises in chroots where initctl can't talk to upstart (so chroots on really old hosts, basically)
<barry> jdstrand: howdy.  let me know what you're working on so we don't step on each others toes
<jdstrand> barry: sure, thanks. I'm starting with some security sponsoring bugs
<barry> jdstrand: cool
<cjwatson> pitti: doing
<cjwatson> (interrupted by dinner)
<slangasek> ogra_: fixed sysvinit uploading shortly, fwiw
<geser> stgraber: is there a way to overwrite/modify upstart user sessions scripts with an own version? I just found out why my gpg card stopped working for ssh logins (the gpg-agent upstart session script is missing the option for it)
<stgraber> geser: yep, you can dump your own copy in ~/.init/ or just a .override file if that's simpler
<geser> stgraber: thanks, almost there. Can initctl set-env also set two variables or do I need two calls for this?
<alexbligh1> I have a replacement package modules-tools-init-z which Provides: and Conflicts: with modules-tools-init (same package with zlib enabled) in my local repo (together with the rest of Precise). Try as I might I can't get debootstrap to use it. I'm using --include modules-tools-init-z and --exclude modules-tools-init. Any ideas?
<stgraber> geser: I believe you need two calls for that
<alexbligh1> (source at https://github.com/abligh/modules-init-tools-z if anyone is interested)
<dobey> bdmurray: should i re-add verification-needed back to bug #1173249 as well?
<ubottu> bug 1173249 in aptdaemon (Ubuntu Quantal) "update-software-center AttributeError during upgrade from 12.10 to 13.04" [High,Triaged] https://launchpad.net/bugs/1173249
<geser> alexbligh1: not sure about it but as module-init-tools is priority required it might make you it more difficult to replace it
<geser> stgraber: yeah, using my gpg card for ssh authentication works again. Thanks
<dobey> bdmurray: oh, nevermind. i see it hadn't been removed
<alexbligh1> geser, hmm, perhaps I should set mine to priorty: required. I can also exclude module-init-tools from my repo I guess. I am really hoping debootstrap looks at Provides:
<alexbligh1> hmm, I suppose I could write my own debootstrap script
<geser> alexbligh1: Provides only works if there is no versioned dependency on module-init-tools. Is there a reason why you don't just provide a modified version in your repo and keep the package name?
<geser> Could someone please do a give-back of geoip-database in saucy-proposed. It builds now the the current geoip-bin package in saucy.
<alexbligh1> geser, hmmm - I suppose I hadn't thought of the ability to filter module-init-tools on pull from the precise-upstream (I'm trying to make it update automatically)
<alexbligh1> but you are probably right, that is the path of least resistance. I thought I was doing it properly :-/
<infinity> alexbligh1: There are tons of versioned deps on module-init-tools, you really should just build your own differently-versioned package, rather than changing the name.
<infinity> alexbligh1: More interestingly, is there an argument for why we might want/neet this in precise proper, rather than just your repo?
<alexbligh1> infinity, yes, it saves 100MB out of 150MB on initramfs
<alexbligh1> infinity, talk tomorrow - have company now!
<geser> barry (or any other familiar with building for Python 2 and 3): if you have some time: could you check if my patch in bug #1185170 looks sane or if there is a better way to solve this?
<ubottu> bug 1185170 in python-json-patch (Ubuntu) "setup.py stumbles about an umlaut in jsonpointer.py when running under Python 3" [Undecided,New] https://launchpad.net/bugs/1185170
<barry> geser: possibly, if i can finish this current package in time.
<geser> barry: no hurry
<jtaylor> barry: could you look at syncing cython? as a source generator its good to have it early to avoid surprises in rebuilds later
<jtaylor> or doko you probably know best if the patch is forwarded
<jtaylor> please add dep3 headers ._.
<slangasek> bdmurray: I've done some analysis on bug #1069019 and isolated the bug; I don't recall the right way to fix this particular class of python3 unicode problem though
<ubottu> bug 1069019 in python-apt (Ubuntu Saucy) "[software-properties-gtk] can not delete, enable or modify any software source with non-ASCII characters in the comment" [Medium,Triaged] https://launchpad.net/bugs/1069019
<slangasek> barry: ^^ I'm not doing enough bilingual python to remember the recommended approach for making sure the right encoding is used for I/O regardless of locale; can you remind me?
<geser> slangasek: might it be: open(filename, encoding='utf-8') (or whatever encoding you want)?
<slangasek> geser: that's not bilingual - it fails for the python2 case, which still needs to be supported here
<geser> ah, than that's the same case I tried to fix in a FTBFS (which I asked barry to review)
<slangasek> possibly io.open()
<geser> stackoverflow suggests also io.open()
<cjwatson> io.open is OK as long as it never gets passed bytes in Python 2
<cjwatson> slangasek: perhaps the runes in germinate.seeds would be helpful
<cjwatson> (if you need to tolerate being passed bytes)
<cjwatson> oh, that was for writing, not reading
<cjwatson> so, yeah, io.open is probably OK.  It was slow in 2.6 but I believe is OK in 2.7
<slangasek> cjwatson: right; we should be able to ensure that anything we're writing is unicode, and the code does guard against writing out a file that it's previously failed to read in
<slangasek> hmmm, though the code doesn't /currently/ ensure it's not doing bytes in python2
<barry> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<barry> geser: okay, i won't get to it today, but i've got the tab open for tomorrow
<barry> jtaylor: can you open a bug and paste me the #?  i won't get to it today, but possibly tomorrow
<barry> slangasek: totally different ways to do it if it's python2 or 3 :)
<geser> barry: no problem, I've added a 2nd debdiff which uses io.open() instead of my previous attempt (based on the recent discussion here)
<slangasek> barry: whimper
<barry> although codecs.open(..., encoding='whatever') is available in both
<slangasek> barry: so do you advise against using io.open() ?
<slangasek> barry: well, let me push what I have here for your review
<barry> slangasek: io.open() can work, but it will be slow in py2 and non-existent in py2 < 2.7.  codecs.open() is probably better if it has to work in both
<slangasek> barry: it's python-apt; so it doesn't have to be portable to anything except the current version of python2
<slangasek> (I would argue)
<barry> slangasek: i'd probably still use codecs.open().  io is pure python in py2.7 (iirc) so it can be slow.  it's nicely rewritten in c for py3
<barry> :)
<slangasek> barry: hmm, cjwatson seemed to think io.open() exists in 2.6 but is slow, and is improved in 2.7
 * barry has to utsl
<jtaylor> its implemented in C in 2.7 vs python in 2.6 I think
<slangasek> anyway, let me know if you think this is bletcherous (or just wrong): lp:~vorlon/python-apt/lp.1069019
<barry> jtaylor: yep, you're right
 * barry just wants to put a stake through the heart of py2 already!
<jtaylor> cythongs test suite is to excessive 40 minutes test and counting :(
<barry> anyway, i'm eod for now.  ping me tomorrow!
<slangasek> barry: sent you an mp for review instead :)
<geser> Could someone please do a give-back of geoip-database in saucy-proposed. It builds now with the current geoip-bin package from saucy.
<slangasek> geser: isn't that button available to anyone who can upload it?
<slangasek> (well, retried)
<geser> slangasek: as that package is in main, one has to be a core-dev to have this button
<slangasek> oh bother :)
<geser> slangasek: thanks for hitting that button, one FTBFS less now :)
<jtaylor> barry: bug 1185191, ran in a clean saucy chroot, so you can skip this one hour build :)
<ubottu> bug 1185191 in cython (Ubuntu) "Sync cython 0.19+git51-g3078752-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1185191
#ubuntu-devel 2013-05-29
<TheMuso> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso, jdstrand
<jdstrand> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
<igor> hi all
<igor> is this the rigth place to seek support with xubuntu?
<igor> I have a problem with very high power consumption on a laptop running xubuntu, that hasn't had this probem running ubuntu
<igor> the power consumption with xubuntu 12.04 is more than twice than with ubuntu 12.04
<igor> same hardware
<igor> perhaps one of the developers has an idea what could be the cause?
<cjohnston> igor: try #xubuntu
<igor> @cjohnson I did
<udevbot_> Error: "cjohnson" is not a valid command.
<cjohnston> That is where you would seek support, this is not a support channel.
<igor> I understand
<igor> thank you
<cjohnston> :-)
<igor> bye
<pitti> Good morning
<pitti> cjwatson: thanks
<TheMuso> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> smb`: hm, so I installed current saucy server with 4 PVs, 1 VG, and 8 LVs, with a separate /boot directly on sda1, and booted a gazillion times
<pitti> smb`: I also used break=top to investigate the initramfs, this looks quite fine to me :/ so I'm afraid I'll need a core dump
<dholbach> good morning
<smb> pitti, Ok, I'll try to come up with one
<slomo> doko_: are you aware of new 4.8 compiler errors since the last upload? /tmp/ccYcKg19.s:101: Error: expecting string instruction after `rep'
<xnox> slomo: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710142
<ubottu> Debian bug 710142 in gcc-4.8 "FTBFS "Assembler messages: Error: expecting string instruction after `rep'"" [Important,Open]
<smb> pitti, apw Some more info on my udev problem: when I add a "ps; sleep 20" to /usr/share/initramfs-tools/scripts/init-bottom/udev right after "udevadm control --exit ..." I can still see many systemd-udevd and blkid (as well as about 3 watershed processes doing the vgscan/vgchange, one vgchange being active).
<smb> pitti, Beside the blkid's which I thought you said should not be run anymore. This might explain the segfaults and missing /dev/null or other things, because normally /dev gets moved right after this
<pitti> yes, that's expected
<pitti> the initramfs does a trigger for all devices, the workers will take a while
<smb> With the large delay this also boots without issues
<pitti> smb: they should all be gone after 20 seconds, though; i. e. ps; sleep 5; ps ?
<smb> They seem to be after 20s, I can take a ps after 5s in another go
<pitti> smb: yeah, udev itself doesn't call blkid any more
<slomo> xnox: thanks
<pitti> but apparently our dmsetup/mdadm packages still do (that should still work, but it's much less efficient)
<smb> pitti, The symptoms look like something is not ended as you thing (so some systemd-udevd processes do not stop but /dev gets emptied while they run)
<smb> *think
<pitti> smb: after moving the /dev mount we add a compat /dev symlink, for this case
<pitti> smb: not ended> yes, very likely
<smb> pitti, apw was wondering about -TERM signals being propagated to childs of workers
<smb> pitti, Hm, so with the delay of the ps moved to "sleep 5; ps; sleep 15". (boot ok) the ps shows 3 systemd-udevd processes which match up with 3 watershed workers (likely still waiting for the one vgchange to finish)
<pitti> hm, I wonder if that's bug 802626 again
<ubottu> bug 802626 in udev (Ubuntu Precise) "vgchange may deadlock in initramfs when VG present that's not used for rootfs" [High,Fix released] https://launchpad.net/bugs/802626
<pitti> I ported the patch for that, but that was quite intrusive
<smb> It does not seem to deadlock as waiting the 20s there at least gives me all the lvs, but yes, my rootfs is not part of any vg
<pitti> ah, you don't have root on LVM?
<pitti> in my test install from this morning I put everything except /boot on lvm
<smb> right no
<pitti> smb: any chance you could build the current version without 0024-avoid-exit-deadlock-for-dm_cookie.patch, just to compare?
<pitti> smb: (i. e. disable it in debian/patches/series)
<smb> pitti, sure I can do that
<pitti> I'll do my test reinstall again, with root on a normal partition and lots of LVs
<pitti> smb: how many VGs do you have? I just created one
<pitti> (with 8 LVs)
<smb> pitti, Maybe one thing my /home is in a LVM VG (but a different VG)... and then there is another mount from the second VG into /home/isos...
<smb> That system evolved a bit. :/
<jamespage> jodh, I've read the manpage for the 'startup' event - but I'm still a bit unclear as to what type of job should kickoff that early
<pitti> smb: ack, I'll try to replicate this
<pitti> smb: so /boot and / on /dev/sda*, /home on VG1, some other LVs on VG2?
<jamespage> jodh, I think I need the openvswitch userspace daemons to start that early so that I can use ovs style syntax in /etc/networking/interfaces but wanted to get your opinion before i uploaded
<pitti> smb: I guess you don't need a separate /boot then, do you have that?
<smb> pitti, [/ on /dev/sdaX; /home on /dev/vg1/lv1; /home/isos on /dev/vg2/lv1] /boot is in /
<jodh> jamespage: startup is emitted as soon as upstart starts. You really don't want to use that event.
<smb> and vg2 has 30 other lvs that are not mounted directly (containing vms)
<jamespage> jodh, how about starting networking?
<jodh> jamespage: possibly (I know nothing about openvswitch).
<jamespage> jodh, well my requirement is that the ovs daemons are running prior to 'ifup -a'
<jamespage> so that when the ovs configuration is parsed in /etc/network/interfaces, the daemon is there for the ifup/down hooks to talk to
<doko_> slomo, bug report?
<slomo> doko_: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710142 already there :) just wanted to check if it's a known problem before spamming you and everybody else with bug reports
<ubottu> Debian bug 710142 in gcc-4.8 "FTBFS "Assembler messages: Error: expecting string instruction after `rep'"" [Important,Open]
<jodh> jamespage: I'd go for the start on condition in network-interface-security.conf in that case.
<jodh> jamespage: note that you'll need to use 'instance' as that job does.
<Laney> xnox: what is the rebuilds team?
<doko_> slomo, debian only?
<slomo> doko_: don't know, i'm not running any recent ubuntu anywhere
<doko_> slomo, so why do you post here?
<slomo> doko: good question, probably because it's the only channel we're both in. nevermind then, i'll just go the "official" way of bug reports then in the future
<pitti> smb: does that look reasonably similar? (sorry, had to do it twice, messed up teh first time) http://people.canonical.com/~pitti/tmp/lvm.png
<smb> pitti, Yes, looks similar enough to me
<pitti> smb: vdb has two partitions (both PVs), that scrolled off
 * pitti installs then
<smb> pitti, I mostly looked that there are two VGs and /home is on one of them and the other mount on the other
<smb> pitti, systemd seems to be one of those "evil" packages where I cannot shortcut of building the source package while ignoring builddeps
<pitti> smb: how so? debuild -S -nc should always work?
<pitti> and -d
<pitti> smb: did you unapply the patch before commenting it out of series?
<smb> pitti, it needs some stuff to do the make clean
<pitti> -nc :)
<smb> pitti, yes
<pitti> splendid
<smb> Bah
<smb> :)
<jamespage> jodh, hmm - I'll take a look
<pitti> smb: ok, 10/10 successful reboots
 * smb cries
<pitti> smb: if I do break=bottom, I see two handfuls of udev workers when I immediately do "ps", and they are gone after one or two seconds
<pitti> smb: I'll add some ps after the --exit to check which are still running (I think that's what said patch does)
<smb> pitti, I just wonder why my processing of vgchange is taking exceptionally long
<pitti> smb: where is that called?
<smb> pitti, indirectly through one of the udev rules
<pitti> smb: I could replace it with a shell script that sleeps 5 seconds and then calls the real one
<smb> I think 85-lvm*
<pitti> oh, in 85-lvm2.rules
<pitti> I don't have that on my workstation, sorry; but I see it in the VM
<smb> Comes through lvm2 I would guess
<pitti> ah, that rule is already shell; I'll just add a sleep
<pitti> smb: meh, still boots perfectly fine :/
<pitti> oh, I didn't update initramfs
<smb> Knowing my luck that does not change anything
<pitti> now it hangs (as expected) for several seconds, but still boots; argh
<mitya57> ScottK, xnox: do we (still) need python 2 packages for pyqt5?
<pitti> ok, so break=bottom interrupts before scripts/init-bottom/udev; so it's ok to see some udev processes still
<xnox> mitya57: it's very tempting to have them python3 only. A few people ported (python2 -> python3) together with (pygtk2 -> py-gi & gtk3), although some did choose to do it in locksteps.
<mitya57> yes, and py-gi & gtk3 porting was happening two years ago, so I don't want to contribute to making python2 life longer :)
<smb> pitti, So with the udev that has the lvm cookie patch removed, I did not see the /dev/null messages and systemd crash but later a message about failing to kill watershed (but this is just 1/1). The second vg has 25 of its 31 lvs with symlinks
<pitti> smb: I added the sleep 5 to the rules, and some ps output to udev's initramfs-bottom; no processes left for me after udev --exit
<pitti> smb: oh, is it just the symlinks that are missing or the actual vgchange setup (i. e. /dev/dm-NN)?
<ogra_> pitti, oh, btw, did you test what happens when booting without initrd after your removal of /dev/pts mounting in udev ?
<smb> pitti, Usually only the symlinks to the dm-xx devices
<ogra_> the initramfs /init script explicitly has ||true to handle that case
<pitti> ogra_: no, I didn't; but we haven't had that for years, it just slipped in for a few days due to the debian merge
<ogra_> pitti, we have quite a afew arm users that run without initrd
<pitti> ogra_: initramfs init comes before udev's top script, though?
<smb> pitti, dmsetup ls sees things and I can get a propper setup by dmsetup remove the lv and then calling vgchange -ay again (after boot)
<ogra_> ah, was it only the initrd content you changed ?
<pitti> ogra_: yes
<ogra_> great
<pitti> ogra_: for non-initramfs, it should be handled by /lib/init/fstab
<ogra_> then i misread
<ogra_> sorry for the noise
<pitti> ogra_: no worries; double-checking greatly appreciated!
<ogra_> :)
<pitti> smb: ah, I guess that triggers all the udev rules again, but this time uninterrupted by the --exit
<pitti> smb: I modified /usr/share/initramfs-tools/scripts/init-bottom/udev like this: http://paste.ubuntu.com/5713055/
<pitti> smb: similar to your's?
<pitti> smb: I see no udev processes after the --exit
<pitti> smb: so you still see some?
<smb> pitti, I now did 3 reboots with the self-compiled udev and all of them came up and complain about being unable to kill some watershed process. varying amounts of lvs are finished on setup
<smb> pitti, need to remodify the script after installation
<pitti> smb: so I guess the point of that patch was to fix that "varying"
<smb> right, but it seems to now have different issues
<smb> (in the way that some udevd gets a segfault and some seem to run on the emptying /dev)
<pitti> RIGHT
<pitti> sorry, caps lock
<smb> Its a useless keybinding. :)
<pitti> hm, I added ls -l /dev and ls -l /dev/null after the mount --move, and it looks ok
<pitti> (we install a compat symlink to /root/dev/ after the move)
<smb> pitti, Could be that a new ls gets the current mount namespace but a running process keeps looking at the old one
<pitti> smb: hmm, could be; that compat symlink is new, but I don't see how things should be worse off with it
<pitti> smb: but for opening a new file it should see the moved mount/symlink, and for an already opened /dev/null it shouldn't matter at all
<smb> pitti, I am not sure whether I may talk nonsense here (maybe apw can correct me) but I thought a child process keeps seeing the mounts as they where before...
<pitti> smb: I thought only if it sets unshare(CLONE_FS)?
<mitya57> cjwatson: do you know why your nginx upload didn't migrate to -release?
<pitti> smb: but either way, it ought to work? if children do see the non-moved /dev still, so much the better
<Laney> mitya57: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html - it's caught up with libgd2
<smb> pitti, But later there is that rm -rf /dev
 * mitya57 bookmarks that page
<Laney> mitya57: s/excuses/output/ is useful too
<smb> mah that s in the new layout
<smb> sorry
<Laney> if something is a "Valid candidate" on excuses but isn't migrating, check output to see why
<Laney> that's output.txt, sorry
<pitti> smb: so, some more ideas: (1) add a ps | grep ... wait loop into the hook until really all udev processes are gone
<pitti> smb: that would confirm that the child processes actually run into the /dev issue
<mitya57> Laney: http://people.canonical.com/~ubuntu-archive/proposed-migration/output.txt â 404
<pitti> smb: (2) some ulimit -c unlimited and copying core dumps to /run/udev/
<Laney> update_output
<mitya57> that's better, thanks
<pitti> smb: so that we can check what's actually going wrong there, and where (I'd like to fix that)
<pitti> smb: (3) move 60-persistent-storage-dm.rules from IMPORT{program}="/sbin/blkid -o ... to IMPORT{builtin}="blkid --offset..., to see whether it's the external program which causes trouble
<smb> pitti, Yep sounds good. Just need to move back to the version with that patch applied because currently I see no crash
<pitti> smb: and (4) it would be helpful if you could confirm that you have udev processes running after the udevadm control --exit (wiht http://paste.ubuntu.com/5713055/)
<pitti> smb: I need to leave in 5 mins, will be back on Monday; perhaps you can open a bug and attach results there, so that they don't drown in the mists of IRC?
<pitti> (I'll log out of IRC for that time, too)
<smb> pitti, ACK, I wont be around the next few days either
<smb> pitti, But have some time on today left
<pitti> smb: ah, right, Fronleichnam for you as well? :-)
<smb> pitti, yup, we lazy Germans
<pitti> smb: ok, thanks; with these four things we should have a clearer idea
<halfie> Hi, the security wiki page says that PIE will be made default at some point. Any ideas about what's the progress on this is?
<halfie> kees,  the security wiki page says that PIE will be made default at some point. Any ideas about what's the progress on this?
<Cimi> hi there, /me stupid has just run sudo rm /etc/default/*
<Cimi> you know of any way of getting them back?
<sladen> Cimi: sudo mount -o remount,ro /    and then you can try undeleting stuff at your leisure
<ogra_> a backup usually helps :)
<sladen> Cimi: your homedirectory will be encrypted, but / probably won't be
<Cimi> sladen, hey paul :)
<Cimi> sladen, how do I restore the deleted files?
<sladen> Cimi: you can try e2undel or recover on the partition, and if you're lucky it'll find them referenced via another superblock
<sladen> Cimi: however, if it's a fairly fresh machine, you may just find it easier to grab the contents of /etc/default/* off another machine
<Cimi> might indeed create a vm for that
<sladen> Cimi: they can also be repopulated from the .debs that are installed, but as they're conf files they maybe populated dynamically, in which case you want somebody like cjwatson for clarity on whether it's possible just to dpkg-reconfigure everything and have them repopulated
<geser> Cimi: "grep /etc/default /var/lib/dpkg/info/*.list" and "apt-get install --reinstall" the found packages (but wait till someone more knowledgable agrees that it's a good idea)
<Cimi> will wait with a good lunch in the meanwhile :)
<Cimi> I was on low sugar levels when I did that :)
<mitya57> xnox: did qt4 with disabled pch build?
<xnox> mitya57: didn't run it. let me run it now, before I forget again =)
<xnox> mitya57: running.
<mitya57> xnox: please let me know when^W if it fails
<sil2100> oSoMoN: ping!
<sil2100> oSoMoN: hello, were you able to resolve the AP issue?
<oSoMoN> sil2100: yes, now tests are failing but for a different reason, thereâs a regression in the UITK
<oSoMoN> sil2100, didrocks: the failing autopilot tests (at least those for the browser) are caused by bug #1185397
<ubottu> bug 1185397 in Ubuntu UI Toolkit "[regression] The panel doesnât hide when tapping outside it" [Undecided,Confirmed] https://launchpad.net/bugs/1185397
<sil2100> oSoMoN: ok, thanks, so a real regression
<oSoMoN> yup, a nasty one
<zul> can an archive admin promote d2t1o (#1183825) and python-pbr (#1183826) please we have a couple of packages that are dep-waited because of them
<hallyn_> stgraber: lxc bzr tree - already out of sync...  <sigh>
<hallyn_> cjohnston: bug 1185364 - is that due to debhelper again (not installing the fallback sysvinit job)?
<ubottu> bug 1185364 in lxc (Ubuntu) "dist-upgrade raring to saucy: package lxc 0.9.0-0ubuntu12 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 100" [High,Confirmed] https://launchpad.net/bugs/1185364
<stgraber> hallyn_: yeah, I'm not expecting the importer to work with it, we need to make sure to always push our changes (and tags) to it
<stgraber> but that's not different from what we had in raring IIRC (we broke the importer at some point)
<stgraber> except that I was maybe a bit quicker at manually importing any missing change so you never noticed ;)
<hallyn_> stgraber: no, it was always out of date so i always just worked with the package.  as i do with qemu-kvm and libvirt...
<stgraber> hallyn_: so it looks like you pushed 0.9.0-0ubuntu12 to the branch but didn't debcommit?
<hallyn_> oh does that piss it off?
<stgraber> hallyn_: usually with UDD branch you need to: do your changes, commit with a changelog entry but UNRELEASED, dch -r, debcommit, bzr push
<stgraber> hallyn_: yep, if you don't use debcommit we don't have the tag and without the tag it's out of sync
<hallyn_> i assumed it would diff the new and old and apply the (one-line or 0-line) diff
<hallyn_> stgraber: for my clarity - is "debcommit -r" the same as "dch -r; debcommit" ?
<hallyn_> or not?
<hallyn_> (i was doing all that for awhile but things still broke :)
<stgraber> hallyn_: ah right, you want "debcommit -r" for it to actually tag the branch, but you need "dch -r" before to change the UNRELEASED into the right release name and to update the changelog entry's timestamp
<stgraber> hallyn_: so actually, you usually want:
<stgraber>  - first change for a new version => dch -i + bzr commit
<stgraber>  - next changes for the same version => dch -a + bzr commit
<hallyn_> stgraber: i'll go bzr-import the newest .dsc and push if you haven't
<stgraber>  - when ready (no change pending to commit) => dch -r + debcommit -r + bzr push + bzr bd -S + dput
<stgraber> hallyn_: I fixed it
<hallyn_> stgraber: btw ^ do you know on bug 1185364 ?
<ubottu> bug 1185364 in lxc (Ubuntu) "dist-upgrade raring to saucy: package lxc 0.9.0-0ubuntu12 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 100" [High,Confirmed] https://launchpad.net/bugs/1185364
<hallyn_> stgraber: thx
<stgraber> hallyn_: that looks a lot like the bug slangasek fixed yesterday. I saw a few people mentioning similar errors and I vaguely remember seeing a sysvinit upload (or some other package) that was supposed to fix this
<stgraber> hallyn_: hmm, or not. The bug that was fixed is described in https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-41ubuntu2 but I see no evidence that the failure above was in a chroot
<stgraber> hallyn_: I think we had a few fixes over the past few days for cases like this one (package shipping only upstart jobs). I'll create a raring container and try an upgrade, see if this got fixed
<alexbligh1> infinity, are you about?
<barry> jtaylor: looks like you got your sync of cython, right?  all is good?
<stgraber> hallyn_: a dist-upgrade raring => saucy with LXC installed worked fine here, so maybe the bug has already been fixed
<mardy> kenvandine: hi! dpm was asking me about this: https://bugs.launchpad.net/signon-ui/+bug/1171853
<ubottu> Launchpad bug 1171853 in signon-ui (Ubuntu Raring) "Cannot log in to Google apps domain + Ubuntu SSO" [Undecided,New]
<mardy> kenvandine: do you know why it's not released?
<kenvandine> mardy, no.... we need to do that SRU
<kenvandine> i'll do it today
<hallyn_> stgraber: hm, but he was on the current version...  weird.  /me re-looks at the logs
<hallyn_> stgraber: and you have /etc/init.d/lxc ?
<hallyn_> Wondering whether some package other than lxc made a difference
<mardy> kenvandine: thanks!
<hallyn_> stgraber: yeah he installed an older sysvinit
<hallyn_> hm, that's the "in a chroot" fix.
<hallyn_> i'll ask
<xnox> mitya57: the build did pass the point where it fails on buildds. I actually need my machine for something else at the moment. I will kill the local build and upload your change on to buildds.
<ev> mpt: on https://wiki.ubuntu.com/ErrorTracker#A.2BIBw-What.2BIBk-s_unusual_about_this_error.2BIB0- is the "rate for {matching,all other} machines" the average rate per calendar day across all days, or just the current day, or some other value?
<mitya57> xnox: thanks, and please push it to kubuntu-packagers bzr then
<mpt> ev, I hadn't thought about that. I don't know. What do you think?
<ev> I was afraid you'd ask that.
<mpt> Iâm trying to ask it more often.
<ev> :)
<ev> I'm tempted to say the current day is a reasonable sample, but I'm giving it some thought.
<mpt> ev, maybe that is the best overall, but it wouldn't have illuminated the OpenOffice-doesn't-print-on-Tuesdays bug.
<mpt> ("Variables should include ... day of the week.")
<ev> yeah, so that would go to 0 on any day but Tuesday. Averaging out across all days would wouldn't work there either though.
<ev> this office needs more whiteboards
<davmor2> ev: or you need to move away from design so there is an empty one :D
<ev> mpt: the advantage of using the difference between "rate for matching machines" and "rate for all other machines" instead of just "percentage of instances that have this field and value" is what? I can see that it doesn't let a single machine overly influence the result, but beyond that I'm not sure. It wouldn't be any better at dealing with "everyone that has this crash has libc! Lets show that."
<ev> just trying to whittle this down to its most basic and build up from there
<mpt> ev, the point is to make a comparison. The reason you can tell that having libc installed isn't interesting is that the frequency is the same for machines with the error and machines without.
<mpt> Whereas if 100% of the machines with an error have overlay-scrollbar installed, and 99% of machines without it don't, that's a big clue.
<ev> so when you say "rate for matching machines" you mean the total error rate, for all errors that machine is seeing, not just the one on the problem page
<ev> sans a comma
<mpt> ev, no, the rate of that error in particular.
<mpt> Though, comparing overall error rate might be interesting for the case where an error is caused by a library.
<ev> mpt: I think I've finally got that part. So if 75% of the instances of the problem are using libc6 2.17 and 25% are using libc6 2.16, that might look like a bug in libc6 2.17. But if we look at the error rates for both of those versions, we'd see that they're roughly the same.
<ev> As they might both come out to about twice a day.
<ev> So much is hinged on getting that front page calculation right.
<ev> (still blocked on webops sprinting for that)
<mpt> ev, because it's just that 75% of machines-in-general are running libc6 2.17?
<ev> exactly
<mpt> What we need right now is a Bayesian.
<mpt> ev, but then it wouldn't show up in the table at all, *because* the error rates are roughly the same.
<mpt> Except for extremes to stop noise at the low end, it doesn't matter what proportion of machines are running each version.
<ev> hm
<ev> mpt: would it not be a good thing that the above example didn't show up in the table at all? If the error rates are roughly the same, the problem probably isn't in libc6. The percentage distribution of the versions for the instances of a problem might just map to how many machines in general are using a version, as you point out.
<mpt> ev, exactly
<ev> ah okay, for a moment there I thought you were calling into question using the rate of matching machines
<ev> but clearly not :)
<ev> mpt: why do you think a Bayesian filter would help us? Assuming Hadoop, we could lean on Mahout: https://cwiki.apache.org/confluence/display/MAHOUT/Algorithms
<mpt> ev, I meant a Bayesian statistician, not Bayesian filtering
<ev> mpt: oh, I think I know how to get one of those
<ev> all we need is a burlap sack, a van, and some time around England's prestigious universities
<ev> but yes, jcastro was asking if we still needed a mathematician the other day
<ev> I believe he was going to do a call out on the Stack Exchange podcast thing
<jcastro> I tried, but I never got around to it. :-/
<jcastro> I mentioned the errors. stuff though
<ogra_> could someone score up https://launchpad.net/ubuntu/+source/livecd-rootfs/2.142/+build/4623577 please
<stgraber> looking
<stgraber>  Start in 38 seconds
<ogra_> thx
<ogra_> it was 1h
<stgraber> so either someone beat me to it or it doesn't need rescoring :)
<ogra_> heh
<ogra_> it was already sitting 30min
<stgraber> ogra_: you really need to setup a few livefs buildds and a clone of nusakan at home so you can test that stuff without all those uploads ;)
<ogra_> stgraber, well
<ogra_> i would like the real env around me
<ogra_> but i guess you are right at least for generic stuff
<ogra_> i'm also failing in the cleanup stage ... i am not even sure i need to clean up (could well be thatthe tarball is already created)
<ogra_> if this next build doesnt work i'll just drop the whole chunk, that will definitely make it work
<jcastro> slangasek: here are the three bugs for MAAS SRU, and it's deps: http://paste.ubuntu.com/5713778/
<bdmurray> ev: that crash-in-postinst package should create an apport-package crash report?
<ev> bdmurray: apport-test-crashes consumes it during build to create a .crash file to include in the apport-test-crashes package
<ev> (hopefully)
<ev> that's then consumed by test/integration-test in lp:error-tracker-deployment
<bdmurray> ev: okay, I was just trying to install it for SRU'ing the new apport-package crash signature stuff
<ev> ah, then yes, you should have a /var/crash/crash-in-postinst.0.crash
<ev> if you installed it via apt
<ev> dpkg alone wont do it
<ev> I also had to set MaxReports - which may itself be a bug
<bdmurray> oh right, thanks
<bdmurray> I've seen some weird stuff with MaxReports and ubiquity / live media bugs
<bdmurray> I haven't looked into it yet
<alexbligh1> infinity, are you about?
<infinity> alexbligh1: Vaguely.
<alexbligh1> yesterday you eveninced an interest in modules-init-tools supporting compressed modules.
<alexbligh1> https://github.com/abligh/module-init-tools
<alexbligh1> your method works
<alexbligh1> It's a 2 line patch
<infinity> alexbligh1: Well, not so much an interest as a curiosity as to why this is a desirable feature.
<alexbligh1> It adds 3 x 76k to 3 /sbin binaries which are statically linked
<alexbligh1> and reduces the size of the initrd by 100MB (150MB to 50MB)
<alexbligh1> also supports uncompressed modules
<infinity> alexbligh1: You mean it reduces the unpacked size, I assume?
<alexbligh1> the reduction in size is irrelevant if you drop initrd
<infinity> alexbligh1: Since it shouldn't affect the compressed size at all.
<alexbligh1> yes
<alexbligh1> indeed
<alexbligh1> but if you run from RAM - i.e. your root IS initrd and in RAM, it's very useful.
<infinity> alexbligh1: And probably increases boot time, due to uncompressing twice.
<infinity> alexbligh1: Sure, okay, I can see the "run from RAM" case, but that likely doesn't affect us.  So, perhaps I'll stop being curious.
<alexbligh1> Well, most people would not compress the modules, so that's a NOP
<infinity> alexbligh1: Plus, statically linked is definitely not the way to go there.
<alexbligh1> It's a NOP bar a tiny amount of disk space for most people
<infinity> (or anywhere)
<alexbligh1> I think it has to be statically linked. insmod is used very very early IIRC
<alexbligh1> TBH I just changed the setting from disabled to enabled.
<alexbligh1> But I think debian/rules has something there to support dynamic linking
<alexbligh1> I just presumed the maintainer knew what they were doing ...
<alexbligh1> I presume it would help (e.g.) live CD
<alexbligh1> If LiveCD on a minimal memory system (e.g. Raspberry Pi) is even useful!
<alexbligh1> Anyway, it's about if you want it on github. It's a 2 line patch
<infinity> alexbligh1: There's no reason it would need to be statically linked, insmod itself isn't.
<infinity> alexbligh1: As for the livecd case, it would actually slow it down a tiny bit, as double-decompressing slows things down, and we then discard the initramfs root when we pivot.
<alexbligh1> except that the IO to read the modules themselves would be smaller
<infinity> alexbligh1: I/O in RAM tends to be quick anyway.
<alexbligh1> I am betting a CD reads slower than zlib can uncompress
<infinity> alexbligh1: Now, if it was dynamically linked, and if a default initrd already has zlib (which it might), turning on the ability to use the feature, but not using it by default in Ubuntu could be a win for everyone.
<alexbligh1> I thought livecd was ISO9660+AUGS
<alexbligh1> Let me have a poke around to see if I can get it dynamically linked
<infinity> And, indeed, my initramfs here has libz.so.1 in it already.
<infinity> alexbligh1: This isn't about reading from the CD.  You read the compressed initrd.gz (or initrd.lz, in our case, I believe) from the ISO into RAM, then you do your insmods from there.
<alexbligh1> Oh sure, for stuff you need to insmod at boot.
<infinity> alexbligh1: So, if you grow that initrd a tiny bit (which double-compressing has a tendency to do), you slow down the load time a teeny bit (not by any meaningful amount), and then you end up decompressing again when you read the modules.
<alexbligh1> Not stuff (e.g. iptables rules) that gets loaded post pivot root
<alexbligh1> double compressing actually shrunk initrd a bit (yes I was surprised too)
<infinity> alexbligh1: Oh, yeah, it could be a win to ship all our modules compressed.  Maybe.  If I/O is really a bottleneck there.  I doubt we'd do it, but giving people the option in the tools if it doesn't impact people who don't use it sounds like an alright deal to me.
<alexbligh1> yeah I wouldn't suggest you compressed by default without a pretty thorough performance check.
<alexbligh1> OK I will take a look at seeing if I can get it to link dynamically. You don't think there are any circumstances where initrd does not have zlib in /lib?
<infinity> alexbligh1: Hrm, it might only be in mine because I have plymouth in there, but I'll dig a bit deeper.
<infinity> alexbligh1: I don't have massive issues with pulling libz into the initrd by default even if it isn't there, though.
<alexbligh1> infinity,  If zlib is required, libz must be linked static, modprobe is in
<alexbligh1> # /sbin, libz is in /usr/lib and may not be available when it is run.
<alexbligh1> So says configure.ac
<alexbligh1> So I guess it's not just initrd, but about what's in /lib before /usr is mounted.
<alexbligh1> at least on my system libz is in /lib and configure.ac is wrong
<infinity> alexbligh1: Yeah, configure is wrong for at least Debian/Ubuntu there.  libz is in /lib
<alexbligh1> infinity, fortunately there is a --enable-zlib-dynamic option I didn't spot earlier. So this is still a 2 line patch :-)
<lifeless> stgraber: got a url for your current bindmount script ?
<stgraber> lifeless: it's currently a local hack I have in an lxc pre-start script here. I just have 4 files bind-mounted for my test setup, /etc/hostname, /etc/hosts, /etc/fstab and /etc/network/interfaces. I also mount tmpfs on /var/log and /tmp
#ubuntu-devel 2013-05-30
<dholbach> good morning
<ev> wgrant: woo! After the fix for bug 1179329 goes live, is there a further switch that gets flipped to enable ddebs in the librarian?
<ubottu> bug 1179329 in Launchpad itself "lp.soyuz.adapters.overrides doesn't respect ddeb override rules" [High,Fix committed] https://launchpad.net/bugs/1179329
<ev> thanks again for all the hard work on this
<ev> quite excited
<wgrant> ev: Just need an ubuntu-archive-tools change landed and a really thorough QA session tomorrow and then we can go live
<wgrant> I QAed things fairly roughly on DF today and found no bugs, but I want to be a bit more thorough before I break the world :)
<infinity> wgrant: And we need to get together with pitti and fix up ddebs-retriever.
<ev> yay!
<infinity> wgrant: When we flip this switch, are we just changing the flags passed to sbuild, so it does the same thing as PPAs with ddebs enabled, and we can tear out the copy-to-public_html code later?
<infinity> wgrant: Cause the smoother cutover would be to publish to both .changes and public_html and then let pitti fix his tools.
<infinity> wgrant: (Which was what we did with translations, long ago)
<infinity> wgrant: Though, I guess if there's a brief period where his tool breaks, it's not world-ending, at least they won't expire from the librarian, so nothing will be lost, just delayed.
<infinity> wgrant: Anyhow, I guess we'll talk about it when pitti's around.
<wgrant> infinity: Yes, it will publish to both AFAICR
<wgrant> But I wrote that code in like 2009, so I'll need to check
<infinity> wgrant: Oh, yeah, just looked, the ddeb stuff in sbuild isn't wrapped in an if.
<infinity> wgrant: In fact, we're still publishing translations to public_html too.  Lolz.
<infinity> wgrant: So, yeah, once we soft-transition ddebs, I'll tear all that code out.
<wgrant> infinity: Yes, I didn't bother ripping out the translations code because I was going to rip out ddebs soon
<wgrant> And do them at the same time :)
<wgrant> 4 years ago
<infinity> wgrant: Yeah, well all have curious definitions of "soon" around here. ;)
<wgrant> ddebs were also one of the main blockers for the sbuild upgrade, too
<infinity> wgrant: I suspect that was my reasoning too.
<infinity> wgrant: I might revisit the sbuild upgrade thing once this is all landed.
<wgrant> I have branches from 3 years ago that worked
<wgrant> But sbuild has been split into a thousand pieces since then.
<wgrant> So I'm not sure how relevant they are
<infinity> wgrant: I'm still not entirely comfy with replacing the devil we know, but I do like the idea of buildd and developer machine behaviour being closer.
<wgrant> https://code.launchpad.net/~wgrant/launchpad/use-system-sbuild and https://code.launchpad.net/~wgrant/ubuntu/lucid/sbuild/extended-result were my old branches
<infinity> wgrant: Yeah, I think I had those checked out before the Great Backup Fire of Earlier This Year.
<wgrant> infinity: Once we turn on ddebs, people will also need to be prepared to fix issues like IIRC systemd that you ran into in Oakland
<wgrant> Producing ddebs without a corresponding deb
<wgrant> But they should all be pretty trivial to fix as they are uncovered.
<infinity> wgrant: use-system-sbuild (well, the name of the branch) is probably optimistic anyway.  We'll likely have to maintain a separate branch like Debian does.
<wgrant> infinity: Yeah, but I hope it can at least be out of tree.
<infinity> wgrant: I imagine that systemd bug isn't something that will pop up often, but we'll see. :)
<infinity> wgrant: And a few of us know the cause, so fixing it shouldn't be a big deal.
<wgrant> Yeah
<infinity> I will miss the old sbuild when we get around to upgrading.  It may be a mess, but it's a mess I know inside-out.
<wgrant> It's a much simpler mess than the new one.
<infinity> I'm a committer to the new schroot and sbuild, and I've barely scratched the surface on those.
<infinity> -set_target_properties(poppler PROPERTIES VERSION 28.0.0 SOVERSION 28)
<infinity> +set_target_properties(poppler PROPERTIES VERSION 37.0.0 SOVERSION 37)
<infinity> Dear poppler upstream: Double-U Tee Eff.
<infinity> apw: Say, when are you doing some +1 for me this cycle?  I might have a poppler transition for you. :P
<Laney> seb128 is handling it
<infinity> Laney: That works for me too.
<Laney> eds is coming soon too. The two best transitions.
<infinity> Laney: I just wanted to give apw flashbacks to his previous poppler transitions.
<infinity> Laney: eds doesn't usually mangle the API as badly, IME.
<infinity> Laney: poppler seems to need porting every second upload, not just rebuilding.
<Laney> apparently this poppler one is free of porting too
<infinity> Oh, then no big deal.
<infinity> But man, that's some SOVER bump.
<infinity> I'm beginning to wonder if they just rev it every week even if nothing's changed in the tree.
<Laney> There was some argument recently about how it's actually a private lib and other things are naughty for using it
<infinity> ...
<infinity> Given the countless things we link to it, that seems a bit laughable.
<seb128> -glib and -qt are meant to be the public apis
<Laney> Well, yes
<infinity> Oh, actually, I guess we don't link THAT many things to it directly.
<apw> infinity, you are a sick sick man :)
<infinity> apw: I've been called much worse.
<asac> saucy kernel broke my computer :)
<asac> going back to last 3.8 that is instlaled makes it boot
<asac> apw: ?
<asac> known?
<asac> with 3.9 basically nothing happens after grub ... even with quiet and splash removed
<seb128> infinity, btw any chance that you or somebody from the sru team would review the unity stack SRU which is waiting for 3 weeks in the raring queue?
<infinity> seb128: Yeah, I promised Mirv I'd look at it.  Will get that done tomorrow.
<seb128> infinity, thanks
<infinity> asac: WFM.  Try the usual reinstalling and such (ie: blame your hard drive)?
<seb128> I'm using 3.9.0-3 without issue here
<asac> hmmm. have 3.9.0-2 if i parse dpkg -l correctly
<asac> heh ... ok seems half of the dist-upgrade didnt finish before i shut downthe computer :) - might be one reason
<seb128> lol
<asac> ok now i have an initrd :)
<asac> let me try
<asac> infinity: seb128: thx :)
<seb128> asac, yw ;-)
<geser> barry: thanks for sponsoring the python-json-pointer fix. Now python-json-patch needs the same fix too (#1185739 if you have time)
<Mirv> asac: I've seen a real life situation (on precise) as well where battery run out in the middle of upgrade, and no initrd. would be nice to have auto-try-older-kernel feature.
<asac> yeah
<asac> well... i wonder why the grub picks stuff up before its finished
<asac> guess maybe its doing the initrd before putting the vmnlinux in place
<asac> so if it doesnt finish its not seen
<seb128> shrug
<seb128> what's the best way to check that binaries are published/available to the builders?
<xnox> seb128: rmadison $packagename
<seb128> I watched the poppler binaries on the launchpad page for the upload to have their (Accepted) status dropped, but that was not enough apparently
<seb128> xnox,    poppler | 0.22.4-0ubuntu1 | saucy-proposed | source
<cjwatson> Accepted status dropped + publisher run finished
<seb128> yet the builders picked 0.20
<cjwatson> rmadison -S $packagename
<cjwatson> source of build-dependencies is of no interest to the builders :)
<mitya57> seb128: the LP page says they are still in -proposed
<cjwatson> mitya57: that doesn't matter
<seb128> mitya57, no, they are not yet in proposed (which is my issue)
<seb128> cjwatson, thanks, that doesn't list the new binaries, I guess the publisher is not done running then
<cjwatson> seb128: you MUST wait for the publisher run to finish; rmadison -S and look for the *binaries* is a slightly conservative way to check that
<cjwatson> it's typically no more than about five minutes out of date
<seb128> cjwatson, I (wrongly) assumed that launchpad's drop of "(Accepted)" would mean that ... thanks ;-)
<cjwatson> no, I'm afraid that means that the publisher run has started
<cjwatson> mitya57: (the builders necessarily build from -proposed, otherwise transitions would be impossible)
<mitya57> cjwatson: sounds reasonable
<chrisccoulson> does anybody want to step up and fix the firefox build failure on ppc that has been blocking the migration from proposed for a couple of weeks now?
<chrisccoulson> if not, i'm afraid that i'm just going to turn off the ppc build
<cjwatson> chrisccoulson: I can have a go if infinity could turn his porter box back on
<chrisccoulson> cjwatson, thanks. although, i think it might be quite a simple fix (i bet http://hg.mozilla.org/mozilla-central/rev/489ab986ea69 would do it, assuming there are no other failures)
<cjwatson> I'll start by giving that a try, sure.  Do incremental builds work reasonably?
<chrisccoulson> cjwatson, from the packaging? i'm not so sure about that. i generally always work from within a mercurial checkout (http://hg.mozilla.org/releases/mozilla-beta in this case), using patch queues (https://developer.mozilla.org/en/docs/Mercurial_Queues - very similar to using quilt)
<zyga> rsalveti: ping
<zyga> rsalveti: have you written any `pactl list` parsers in the last three years? maybe while working at linaro?
 * zyga breaks for lunch
<ogra_`> cjwatson, hmm, with your lightdm upload, what happens on systems where all plymouth jobs are overriden (like ubuntu-touch)
<ogra_`> (lightdm is used in the raring tablet version and has all plymouth jobs disabled)
<ogra_`> oh, ignore me, thats precise
<cjwatson> ogra_`: It wasn't my upload anyway; I just copied it to -updates after SRU verification.
<ogra_`> ah
<xnox> cjwatson: are you by any chance running cross builder for armhf for saucy with results published publicly? similar to http://people.canonical.com/~cjwatson/cross/armhf/
<cjwatson> xnox: Not quite yet, but I have a work item to set it up
<cjwatson> Probably next week
<xnox> ok. cool. would be interesting to see if packages regress and stop cross-building.
<cjwatson> Yes
<rsalveti> zyga: hey, no
<zyga> rsalveti: hmm
<zyga> rsalveti: thanks, I had a deja-vu
<rsalveti> :-)
<zyga> rsalveti: I was writing some parser and I recalled you having the same issues like I had today
<Laney> mardy: hey, I'm packaging eds and evolution 3.8 and was wondering if you could tell me how to test whether the UOA stuff is working
<Laney> It looks like it should integrate with google calendar but I can't see how
<seb128> Laney, did you try adding a google account to the system settings panel and see if you have your gmail account in evo?
<Laney> I have two google accounts in there
<Laney> no gmail account either
<seb128> and the corresponding gmail account don't show in evo?
<seb128> :-(
<Laney> it also doesn't say that the accounts will integrate with e-d-s or evolution
<Laney> but if I "Show accoutns that integrate with: evolution-data-server" it lists Google and Yahoo
<Laney> seb128: mardy: oho, I'd not restarted e-d-s - now it seems good
<seb128> great
<Laney> right, well I'll start off the transition then
<Laney> jamespage: Hey, since you seem to have updated hsqldb (:P), do you think you'd be able to bring hsqldb1.8.0 to saucy?
<Laney> The new series apparently breaks libreoffice, so the Debian maintainer forked the package
<cjwatson> Hm, how come that wasn't autosynced?
<Laney> Don't know, but if I read the hsql changelog correctly it makes Soyuz have some kind of sad.
<Laney> hsqldb*
<cjwatson> It shouldn't have made it sad at that level
<cjwatson> I might be able to tell you more next time I get my six-hourly mail from auto-sync; I typically read them and delete them, so I don't have the last one to hand
<cjwatson> s/read/skim/
<Laney> Actually, the relevant part of the diff looks trivial so I might just JFDI
<Laney> unless you would rather wait and find out?
<cjwatson> I'm sort of curious
<cjwatson> But feel free to prepare the diff, indeed
 * Laney spots a bit of RAS syndrome
<cjwatson> It doesn't even mention hsqldb in its output
<cjwatson> Hmm
<Laney> Will it be out of the way if I upload it to the queue for you/someone to accept at your leisure?
<Laney> cjwatson: ^? (got it ready to go)
<cjwatson> Laney: one sec
<lfaraone> Is there a preferred way for an application to signal to apport "please don't send this sensitive variable in crash reports"?
<Laney> cjwatson: seb128: Right, I've got to shoot off. I'll put it on chinstrap signed â please upload when ready.
<seb128> Laney, ok, thanks
<cjwatson> Ah
<cjwatson> [Skipping (not built on any target architecture)] hsqldb1.8.0_1.8.0.10+dfsg-3
<cjwatson> Laney,seb128: ^- So that explains it.  On Debian, hsqldb1.8.0 is only needed on kFreeBSD
<cjwatson> (which is clear from a close look at http://packages.qa.debian.org/h/hsqldb1.8.0.html)
<seb128> hum
<Laney> hmm?
<cjwatson> So I guess my question is why our LO thinks it's kfreebsd?  Is there something else going on, or was it a mismerge?
<infinity> Then why do we want it?
<Laney> What about the arch:all package?
<seb128> what did they do with libreoffice?
<seb128> infinity, libreoffice conflicts with >= 1.8.1
<Laney> libhsqldb1.8.0-java
<seb128> infinity, see build failure of today's upload
<cjwatson> Well, Debian's arch:all packages are built differently, remember; we wouldn't be able to build it that way
<infinity> Oh, silly.
<seb128> (we tested the build in a ppa on local boxes which didn't have proposed enabled)
<seb128> Sweetshark, I think we should go with "use the libreoffice copy", seems the easiest way out
<Laney> What way?
<infinity> That's arguably a bug/misfeature that we can't build all-only for something that doesn't include i386 in its arch list.  But the simple solution is a small delta that excludes the freebsd binaries.
<Laney> The maintainer uploaded just the _all package - that's what we'd do.
<Laney> Anyway. Doing.
<cjwatson> Hm, does that actually work in Soyuz?  If so, feel free.
<infinity> Laney: No, that doesn't work for us, see above.
<cjwatson> I'm not sure.  auto-sync excludes such cases, but I didn't really think too hard about the "other arches + all" case.
<infinity> If the arch list is all+something_we_don't_build, we skip it.  A bug, to be sure, but there it is.
<cjwatson> seb128,Sweetshark: Well, if we can work around this in a small package, I'd rather do that than changing libreoffice.
<infinity> It has to be either all, all+any, or all+i386
<infinity> Anyhow, the work around is simple.  Drop the freebsd packages from debian/control, and the source becomes all-only.
<cjwatson> Yeah.
<Laney> yes, I have the package ready. The solution is well-known. :-)
<Laney> (.)
<cjwatson> Oh.  Indeed, that's what was done in hsqldb.
<cjwatson> Fine, now I understand :)
<infinity> I should fix that bug, though.
<cjwatson> So yeah, go ahead and upload hsqldb1.8.0
<infinity> I wonder if it was an intentional behaviour, under the assumption that "all+weirdarch" would mean that we'd only want to ship foo-all.deb if we also had $weirdarch.
<Laney> yeah, done - now just get the LO build-dep/build-conflicts change uploaded and it can build overnight
<infinity> Which, actually, is a pretty fair assumption.  Maybe it's not a bug, but just a misfeature in this corner case.
 * Laney goes away
<Sweetshark> cjwatson,seb128: yes, my order of preference is: a/ upload 1.8 package b/ use internal copy c/ hack libreoffice and hope it works against the new version (BAD IDEA)
<seb128> Sweetshark, seems like debian went for a/ and that's what we will do as well
<cjwatson> infinity: I would argue misfeature-in-corner-case, I think.
<infinity> cjwatson: Of course, it *is* a bug that we can't build armhf+all or powerpc+all.
<Sweetshark> seb128: yep, thanks.
<infinity> cjwatson: (Well, we can, but we seem to fail to create the build records... See how linux-ppc in raring never had a build record on i386 until I ran create-missing-builds in saucy and it got one)
<infinity> cjwatson: So, that's curious.
<infinity> cjwatson: (A bug in linux-ppc that it claims to build arch:all packages anyway, but it illustrates the point)
<cjwatson> infinity: I'd say this is also related to the historical lack of support for build-arch/build-indep
<infinity> cjwatson: Goes deeper than that.  I wouldn't try to fix this until we fix arch:all affinity as well.
<infinity> cjwatson: Currently, we only create the record if it's all-only or all+(some set that includes i386), and that seems fair because a hypothetical armhf+all *could* rely on the armhf binaries in the build tree to make the all package.
<infinity> cjwatson: So, until we can build those all debs on the armhf builder it's likely fair to assume that we can't just throw an i386 build record out for it and hope.
<stgraber> ScottK: ping
<ScottK> stgraber: pong.
<stgraber> ScottK: would Kubuntu be interested in using the new upstart user sessions?
<ScottK> Maybe.
<ScottK> What's invovled?
<stgraber> ScottK: one file in /usr/share/upstart/sessions and one extra line in /etc/upstart-xsessions
<stgraber> ScottK: I did a quick test with today's daily build of Kubuntu and it appears to work properly
<stgraber> ScottK: dump http://paste.ubuntu.com/5717639/ into /usr/share/upstart/sessions/startkde.conf and add "kde-plasma" to /etc/upstart-xsessions
<stgraber> ScottK: then all you have to do is logout and log back in to have the session run under upstart
<stgraber> ScottK: the next steps would be to include that upstart job in kde-workspace-bin, have people test it by manually editing their /etc/upstart-xessions and if they don't find any regression, then we can add it by default
<stgraber> Laney and I did an archive wide scan for possible regressions (packages shipping Xsession scripts altering the STARTUP variable) and I believe we now added upstart jobs for all of those, so in theory this should be regression free and let you use the same extra features as Ubuntu Desktop (starting stuff depending on hardware events or system events mostly)
<stgraber> the main reason I'm looking into making this work for all our supported desktop environments is that xnox showed some interest in moving ubiquity from a system upstart job to a userjob, so if we don't want to end up duplicating the work on ubiquity's side, it'd be best if everyone was using the user sessions
 * stgraber stops talking ;)
<ScottK> stgraber: Sorry, got pulled onto the phone.
<ScottK> Back now.
<ScottK> I'd say it's something we ought to try.
<stgraber> ScottK: want me to commit that upstart job to the kde-workspace bzr branch or do you want to test it more yourself before that?
<ScottK> Go for it.
<ScottK> Feel free to upload it, then we can do a call for testing.
<xnox> \o/ awesome =)
<stgraber> ScottK: gah, I forgot how long and painful (for my CPU) a kde-workspace build is ;)
<stgraber> ScottK: I was hoping for a "quick" test build to check that I didn't mess up that extra dh_install override...
<ScottK> :-)
<stgraber> ScottK: doh, didn't notice that the packaging branch was out of date...
<stgraber> yofel: you forgot to commit 4:4.10.3-0ubuntu3 to the kde-workspace bzr branch
<stgraber> fixing that now and then uploading ubuntu4
<stgraber> yofel: or not, ignore me
<yofel> heh, I was just wondering ^^
<yofel> np
<slangasek> stgraber: hey, why does this nfs-utils merge have a tree full of binaries in it?
<stgraber> slangasek: that's a good question
<slangasek> they seem to have come by way of the Debian branch
<slangasek> let's see if they're in the upstream tarball (ugh)
<stgraber> slangasek: right, just checked, not my fault, it's coming from Debian
<slangasek> in the upstream tarball, in fact
<slangasek> cute
<stgraber> nice
<stgraber> surprising the Debian maintainer didn't notice. I only looked at the Debian/Ubuntu delta, but would have expected the Debian maintainer to notice a bunch of binaries showing up when merging the new upstream :)
<stgraber> so I guess that means we'll see a dfsg-ized source package show up in Debian pretty soon or a new upstream release (if upstream is re-active enough)
<slangasek> stgraber: well, I guess that all of the binaries included can be built from the provided source using the Debian toolchain, so strictly speaking I'm not sure we have to repack to strip them
<stgraber> hmm, true, we know the package builds and changes are that those binaries are for the same version as the source, so in theory that's fine
<slangasek> it did more than triple the size of the orig.tar.bz2, but I guess no one cared about that :)
<stgraber> surprisingly enough that same source has been packaged in a bunch of other distros and I can't see any bug report ;) only report I can find of the tarball containing binaries is lintian.debian.net
<slangasek> stgraber: ok, so after upgrade, all NFS operations are erroring out with 'Broken pipe'
<slangasek> stgraber: only the kerberized ones
<slangasek> stgraber: oh, there we are; gssd is segfaulting
<stgraber> slangasek: fun... let me see if we do any custom patching of gssd
<stgraber> slangasek: nothing that Debian doesn't ship as well, weird
<slangasek> stgraber: IIRC, Luk also does not have kerberos set up to test this
<stgraber> slangasek: can you easily test this on Debian to confirm it's broken there too?
<slangasek> stgraber: not very easily, but I can rig something up tonight.  In the meantime, let me see about a backtrace
<slangasek> stgraber: http://paste.ubuntu.com/5718290/
<slangasek> stgraber: so the actual segfault happens down in libgssglue, by the look of things
<guenther> ScottK: around?
<cjwatson> Laney: So, I just made deduplicate-packages about 40 times as fast
<cjwatson> Laney: http://paste.ubuntu.com/5718309/
<cjwatson> Laney: That takes it from about 3.5 minutes to about five seconds
<cjwatson> deb822 is *slow* on files that size :)
<cjwatson> (the effective encode/decode in the write there is probably unnecessary, but at this point I couldn't be bothered optimising further)
<slangasek> stgraber: ok, looks like it's probably a bug with limit_krb5_enctypes; I haven't pinned it down just yet, but that seems to be the function that's returning the bogus cred struct
<stgraber> and that didn't happen with the old gsssd?
<slangasek> stgraber: no
#ubuntu-devel 2013-05-31
<fishor> hello all, i currently rewriting gnome-sound-recorder and i got one idea which i wont to discuss with some one. I wont to remove all File parts from this program, so it will just save all records to some folder. Logical next step will be to add some sort of file browser. I do not see any sense to build a new one, i think it is best way to integrate it to nautilus or to use some sort of nautilus libs
<fishor> if i do it, i will autoamtically got everey thing i need: search, send file... and so on
<fishor> i need some comments or critics on it
<diwic> fishor, hi, have you tried talking to GNOME upstream about it?
<diwic> fishor, Ubuntu is unlikely to take a big change of gnome-sound-recorder if it's not coming from Gnome.
<fishor> well, there is no one who cares about it
<fishor> this project is dead
<fishor> i talked about it on gnome-media list
<fishor> one persen tried to start it from scratch, but filed due time
<diwic> fishor, okay...
<diwic> fishor, then you seem to have tried, at least
<fishor> diwic, currently i have recorder which works with ubuntu 13.04 and works with gstreamer-1.0
<fishor> gnome-recored installed on 13.04 is not working at all
<diwic> fishor, have you submitted those changes (transition from gstreamer 0.10 to 1.0) to upstream?
<fishor> diwic, i tried, but it was decided to suspend gnome-media. transition to gst-1.0 affects complete packet and makes most of it useless
<dholbach> good morning
<fishor> only good way was to split the packet and make gnome-recorder stand alone project
<diwic> fishor, interesting
<fishor> for example gst-mixer and profiles wont work with gst-1.0
<fishor> diwic, here is the source of my fork https://github.com/olerem/gnome-recorder
<diwic> fishor, I hope you manage to get it into distributions, that might be the biggest challenge
<fishor> i know...
<Laney> cjwatson: deduplicate-packages> haha, nice work
<seb128> Laney, what is deduplicate-packages?
<Laney> wasn't aware of the speed differences there :-)
<Laney> seb128: something the transition tracker uses
<xnox> cjwatson: imported lp:click-package into readthedocs to automatically build documentation from the trunk branch =) https://click-packages.readthedocs.org/en/latest/
<seb128> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<seb128> ups, not really an emergency
<seb128> but could any op block that guy who keeps exit/join? (he's on #ubuntu-mir/touch/unity as well at least)
<xnox> seb128: such requests usually go to #ubuntu-irc channel where there are also various freenode ops.
<seb128> xnox, thanks, asked there
<cjwatson> xnox: Please remove that; I'd already created https://click-package.readthedocs.org/en/latest/
<cjwatson> xnox: Which actually matches the project name ;-)
<xnox> cjwatson: oh cool. My google foo failed me. Is it linked from somewhere?
<cjwatson> Not sure
<cjwatson> xnox: It's linked from https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-click-package
<xnox> cjwatson: I was hoping for a link from https://launchpad.net/click-package =)
<xnox> e.g. Homepage / Documentation or whatever URLs launchpad can offer to display =)
<xnox> cjwatson: removed from readthedocs.
<cjwatson> xnox: I think just the description is probably better, since LP is the home page.  Thanks
<cjwatson> And thanks for the effort, even if you were late to the party ;-)
<xnox> cjwatson: hehe =) was reading the spec, to see how the app-containment (apparmor) policies could be integrated.
<xnox> i gather it will need to be some kind of a hook, but not sure.
<cjwatson> Yeah, I'm not sure the hooks spec is flexible enough for that yet, since it wouldn't necessarily correspond to a separate file in the package, just manifest contents
<xnox> cjwatson: well, sbeattie is after a json manifest with keywords (of what is allowed/not-allowed). I simply handed over everything that happened during copenhagen's dh_appcontainment session. About integration with click packages, I pointed to talk with you about it =))))
<dpm> hey all, could an archive admin have a look at uploading qreator on https://launchpad.net/ubuntu/saucy/+queue ? Thanks!
<xnox> the blueprint got postponed around raring's FF
<cjwatson> xnox: every click-package has a manifest.json, and I already said to the security team that they should just define a subtree of it
<xnox> thanks.
<cjwatson> xnox: What I haven't worked out yet is exactly what needs to be run after each click package is unpacked; I'd much rather that be a system hook defined by apparmor or whatever than something hardwired into click-package itself
<xnox> cjwatson: last I heard, we'd want upstart user-session to launch all apps and it will be upstart that will load up the apparmor profile(s) to launch an app.
<cjwatson> OK, which leaves the remaining question of how to tell upstart what to launch
<cjwatson> We don't actually have a defined "here is your entry point" in click-package yet *cough*
<xnox> yeah... and i guess api to click-packages to query: apps & it's manifest.
<cjwatson> If needed
<cjwatson> I'd prefer to do things using a hook that attaches each installed app to upstart
<cjwatson> Though I wonder if that means I need to think about hooks based on the user's home directory - hmm
<xnox> cjwatson: well the apps should somehow appear in the search / dash / home screens - which are all kind of scopes. I was expecting there will be "unity" hook that gets triggered on app install, and then displays launchers where it needs in the UI.
<cjwatson> Definitely need to hammer out the exact details there
<cjwatson> Because there are interesting interactions with requirements for per-user app installation
<xnox> (not sure how that translates to command-line and manually launching apps - something like xdg-open but rather unity-open ?!)
<ev> cjwatson: mornin'. Could you please approve my post to ubuntu-devel-announce?
<cjwatson> ev: done
<ev> cheers!
<ev> for those of you who don't subscribe to ubuntu-devel-announce, we've opened up access to https://errors.ubuntu.com: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-May/001039.html
<cjwatson> For those of you who don't subscribe to ubuntu-devel-announce, why not? :-)
<cjwatson> chrisccoulson: http://hg.mozilla.org/mozilla-central/rev/489ab986ea69 seems to be enough to fix the firefox build on powerpc.
<jacobw> My mailbox is big enough as it is :)
<cjwatson> chrisccoulson: Or at least it makes "make -j4 -C /home/cjwatson/firefox-22.0~b3+build1/./obj-powerpc-linux-gnu" pass.
<ev> cjwatson: :D
<chrisccoulson> cjwatson, excellent, thanks for testing that. if i add you to https://launchpad.net/~mozillateam , do you want to commit that to lp:firefox/beta? :)
<cjwatson> Can I do that and then immediately remove myself from the team? ;-)
<chrisccoulson> cjwatson, if you like ;)
<infinity> ev: Yay on the errors NDA coming to fruition.
<ev> inknowright
<cjwatson> Then sure.  Wouldn't want to promise any actual ongoing activity ...
<chrisccoulson> heh :)
<infinity> ev: Someone might want to make the oauth for that page check if I'm already in groups that allow me access and say "you don't need to use this form, doofus".
<cjwatson> Just that branch?
<jdstrand> xnox, cjwatson: upstart will be used to launch an app, but because these are part of user sessions, upstart will be running as non-root and cannot load the policy into the kernel. upstart will be used to change into the profile, which does not need root
<ev> infinity: I'll talk to Neil M about that
<cjwatson> jdstrand: Right, so we still need a rootly hook to load the policy?
<jdstrand> cjwatson: exactly
<infinity> ev: All in all, awesome news, though.  I hope people read it in the "we have to do this, because sensitive data" light, and don't tear it apart as us being secretive or some silliness.
<jdstrand> for handling loading policy before a reboot (just like we talked about at the sprint)
<cjwatson> jdstrand: We were talking about a non-root "software" user to unpack packages at various points.  I wonder whether that's more trouble than it's worth, because we'd only be able to use it for the unpack, not for hooks.
<ev> infinity: yeah, I originally wrote it fairly defensively, but EmilyMaher helped me turn it into a positive thing. I really like the idea that it's effectively a contract between the people signing it and the users.
<cjwatson> I guess we could, but click-install would need to know to drop privileges.
<ev> A way of codifying the users' expectations
<infinity> ev: I certainly don't read any obvious evil in it, so good job on the writing and editing.
<jdstrand> cjwatson: right, mdeslaur and I both feel that the 'software' user is valuable and safer-- everything except this one hook chould be able to run as it
<cjwatson> jdstrand: I think in practice many hooks would need root.
<jdstrand> cjwatson: have other hooks been identified?
<cjwatson> jdstrand: Since they will in general involve symlinking files into root-owned directories.
<cjwatson> jdstrand: Not specifically
<jdstrand> what directories would we be symlinking into?
<cjwatson> But "software" is only used by click-install, so I find it unlikely that it will be able to do much of any interest if other hooks are identified
<cjwatson> My working example would be something like a Unity scope
<cjwatson> Not sure if that's a good example, but for the sake of argument
<cjwatson> In any case, I don't want to put configuration in hooks that says which user they run as, and I don't want to special-case your hook
<cjwatson> So IMO either all hooks run as root or none of them do
<jdstrand> I had assumed that things like the /usr/share/... problem would be solved in other non-rootly ways
<cjwatson> Click packages don't get to control any hook code - that's all shipped in system packages
<cjwatson> So I don't see this as a particular problem
<jdstrand> for example, I figured that the apparmor profile wouldn't live in /etc/apparmor.d, but somewhere in /opt
<jdstrand> and apparmor would have to understand how to find the profile
<cjwatson> I think that's a big assumption, because it will often be inconvenient to change system packages to iterate over a bunch of directories
<cjwatson> I think it will be more sensible in the long run to have the click-package design integrate with system packages in a low-effort way, rather than requiring a bunch of moderately invasive patches that people will get wrong
<jdstrand> I was assuming that because I thought I read that as a requirement (I thought that was part of the whole "must be in /opt" part of the specification
<cjwatson> The app itself must be in /opt, but that doesn't preclude system hooks being poked to create symlinks/copies/whatever elsewhere
<cjwatson> Heh, I was about to go and write a to-do item for the privilege drop, and found I already had:
<cjwatson>  * drop privileges to software user when unpacking; retain root for hook execution
<jdstrand> cjwatson: yes, we discussed this at the sprint and you agreed to it :)
<cjwatson> Memory like a thing with holes in.  That's why I write to-do lists
<jdstrand> hehe :)
<cjwatson> I might call it something else though, probably something like clickpkg
<jdstrand> so, maybe there are other cases for other root-hooks, that's 'fine' I guess. from my pov, devs control everything in the click package. there will be limited review of these, therefore we should have anything that they they can control happen as non-root
<cjwatson> Indeed, I entirely agree on that
<cjwatson> Hooks are absolutely not under the control of the click package
 * jdstrand nods
<jdstrand> ok, it sounds like we are on the same page then
<jdstrand> I was just reiterating the priv drop is a good idea :)
<cjwatson> jdstrand: https://click-package.readthedocs.org/en/latest/hooks.html is my current skeletal spec FWIW
<jdstrand> mdz: fyi ^
<jdstrand> meh
<jdstrand> mdz: sorry
<jdstrand> mdeslaur: ^
<cjwatson> I should probably post a call for real-world examples
 * jdstrand imagines a flaw in font or icon processing software that can do code exec and a dev adding this to the click package such that the root-run trigger escalates privs
<cjwatson> While it's possible, that seems like the sort of thing that would have plenty of other (perhaps more profitable) avenues of attack
<cjwatson> Maybe hooks should be confined?
<cjwatson> Just with apparmor rather than by dropping to non-root
<jdstrand> re possible> I imagine what I described would be used to jailbreak
<jdstrand> confining root-run hooks with apparmor seems plausible
<jdstrand> those hooks should be extremely well defined
<jdstrand> and therefore easy to profile
<cjwatson> Yep
<jdstrand> seccomp would also be useful there
<jdstrand> not sure what language was planning on being used to implement the hooks
<mitya57> ev: \o/
<ev> :D
<cjwatson> jdstrand: The Exec interface I think has to be subprocess, since (if it's useful at all) it will probably involve running update-foo programs shipped with the package itself
<cjwatson> So I wasn't intending to nominate an implementation language there
<ev> just working on getting the necessary change to https://errors.ubuntu.com deployed
<cjwatson> chrisccoulson: Do you care which directory the patch goes in?
<cjwatson> chrisccoulson: And should I upload after commit, since there are no other staged changes?
<jdstrand> cjwatson: you are talking about the "An integrated-with system package" there, right? not a click package, or do I misundestand?
<cjwatson> jdstrand: Indeed, since the only influence click packages have over hooks is declaring their use for a given file in their manifest
<jdstrand> right
<jdstrand> so the hooks themselves *could* be C, and therefore leverage seccomp
<cjwatson> If appropriate, I guess, yes
<jdstrand> my gut feeling says apparmor is enough at first, and we could move over to C/seccomp as a hardening measure down the line
<cjwatson> I think that should be part of defence in depth rather than a core requirement though
<cjwatson> Agreed
<jdstrand> mdeslaur: once again, fyi ^
<chrisccoulson> cjwatson, the patch can just go in debian/patches. the other directories are only there to separate out all of the testing related stuff
<chrisccoulson> and feel free to upload it afterwards :)
<cjwatson> Though I am currently unfairly bitter towards seccomp for making me think about https://bugzilla.mindrot.org/show_bug.cgi?id=2107 :-)
<cjwatson> chrisccoulson: k
<ubottu> Error: Could not parse XML returned by bugzilla.mindrot.org: The read operation timed out (https://bugzilla.mindrot.org/show_bug.cgi?id=2107&ctype=xml)
<jdstrand> hmm
<jdstrand> cjwatson: on the other hand, that demonstrates it is quite effective at limiting what something can do :)
<cjwatson> Oh, indeed.  As I say, my bitterness is unfair
<jdstrand> hopefully the hooks what be nearly as complicated as openssh
<jdstrand> :)
<cjwatson> Though I must say it is a ghastly pain in the arse to debug
<jdstrand> I can imagine. I've not personally had to do that
<jdstrand> (yet)
<cjwatson> A seccomp confinement failure tends to kill gdb :-)
<jdstrand> heh
<cjwatson> Not to mention that the confinement failure in question is inherently multiprocess plus buried somewhere in a pile of Kerberos libraries
<jdstrand> :\
<cjwatson> I might just go ahead and apply that patch, since upstream haven't replied and gssapi is currently borked
<jdstrand> food for thought, the apparmor hook would ideally only run as root for the single 'apparmor_parser -r' command
<jdstrand> the generation of the profile (ie, parsing manifest.json) does not need to, and I would argue should not, happen as root
<cjwatson> Perhaps the apparmor hook could drop privileges for most of itself?
<jdstrand> yeah
<cjwatson> That seems simplest
<cjwatson> Committed revision 1000.
<cjwatson> chrisccoulson: ha
<ev> ScottK: are you able to log into errors.ubuntu.com and get to a problem page now?
<ev> tkamppeter_: same question ^ :)
<ev> tumbleweed: ^
<ev> hopefully that'll be enough that someone proves this thing works :)
<ScottK> Yes
<ev> yay!
<tumbleweed> ev: yes, thanks
<ev> tumbleweed: awesome!
<ev> cheers
<tumbleweed> this has come along a bit since I was last here
<ev> :D
<ev> let me know if you run into any trouble with it
<ev> or feel free to file bugs :)
<tkamppeter> ev, I can log in. I have clicked the link in the confirmation e-mail, got asked to log in, and after that, I am on "indicator-weather (AttributeError) on_apply â export_location_details".
<Laney> ev: trouble> "An error occurred while trying to load the most common problems" when I'm logged in ;-)
<Laney> https://errors.ubuntu.com/?user=laney&period=day that is
<ev> Laney: ah, I can reproduce that. Looks like we're taking too long to iterate through all your subscriptions: Failed to load resource: the server responded with a status of 504 (Gateway Time-out)
<tumbleweed> Laney: your auto-subscribe script?
<Laney> I'm probably subscribed to quite a lot of stuff
<Laney> tumbleweed: that shouldn't be too many, but haskell-* likely is
<Laney> or at least haskell-* the last time I ran the script to subscribe to them
<ev> Laney: https://bugs.launchpad.net/errors/+bug/1186215 - the table will load if you switch it off your personal view (users of: [ all binary packages ])
<ubottu> Launchpad bug 1186215 in Errors "Timed out while loading subscriptions for most-common-problems" [High,Triaged]
<Laney> ev: yeah, found that. Thanks!
<ev> unfortunately there's nothing I can do to get your personal view loading today though
<Laney> No worries
<ev> I'll try to get that resolved quickly
<ev> tkamppeter: thanks for confirming :)
<cjwatson> pk11merge.c:1075:5: error: unknown type name 'CK_ULONF'
<cjwatson> I *really* wish our builders suffered fewer one-bit errors
<cjwatson> (Quite a few in that case, actually)
<cjwatson> chrisccoulson: https://launchpad.net/ubuntu/+source/firefox/22.0~b3+build1-0ubuntu2/+build/4630546 \o/
<chrisccoulson> cjwatson, excellent, thanks!
<Laney> thanks to whoever gave my evo stuff back :-)
<mitya57> doko: any reason why you didn't file a bug about http://people.debian.org/~doko/logs-20130217/gcc48/gdcm_2.2.1-1.1_unstable_gcc48.log? looks that now we have this failure in saucy...
<stgraber> ScottK: so the new kde-workspace has published. Do you need any help for the call for testing?
<Riddell> stgraber: what is this upstart user session job lark?
<stgraber> Riddell: I wrote a startkde.conf user job yesterday that allows for the kde-plasma session to behave in a similar way as the unity session. That means that Xsession spawns upstart in usermode instead of startkde, then upstart starts dbus and then actually spawns startkde.
<stgraber> Riddell: the main advantage being that all the processes related to the session are now nicely grouped together under upstart (we use a magic prctl flag to ensure that) and you can have upstart jobs running as a user (and triggering on system or user events)
<stgraber> Riddell: if you want to try it on current saucy, just add "kde-plasma" to /etc/upstart-xsessions and logout/login for it to take effect
<stgraber> Riddell: my goal is to have every desktop environment that ships as a live CD to run under user sessions as the ubiquity developers are considering moving the whole ubiquity-dm mess to a simple upstart user session job (and we'd like to avoid having to maintain two implementations of that stuff)
<Riddell> stgraber: hmm interesting, probably won't be able to test it until monday though
<lordievader> Hello, I heard upstart needs testing in Saucy?
<BluesKaj> ditto
<stgraber> are you guys using Kubuntu on saucy?
<lordievader> stgraber: Yes, I am.
<BluesKaj> what are we looking for ? yes saucy kubuntu here
<stgraber> cool, so yeah, we'd like some testing of upstart usersessions with Kubuntu
<stgraber> first make sure you have the latest kde-workspace-bin installed (4.10.3-0ubuntu4)
<stgraber> then edit /etc/upstart-xsessions to add "kde-plasma" and finally logout and login again. That should give you a working KDE session but running under upstart.
<stgraber> if that works, confirm that you see "startkde" running when doing (as a user) "initctl list"
<stgraber> if the session doesn't start properly, simply remove "kde-plasma" from /etc/upstart-xsessions to revert to the old behaviour
<mitya57> doko: or maybe you know what could cause that error (^)?
<lordievader> stgraber: No need to reboot? For loggin out & in, the "startkde" is not listed when "initctl list" is run.
<stgraber> lordievader: can you confirm that /usr/share/upstart/sessions/startkde.conf exists on your system?
<lordievader> stgraber: Yes that does exist.
<stgraber> lordievader: hmm, and you have kde-plasma on its own line in /etc/upstart-xsessions?
<lordievader> stgraber: This is in the file: http://paste.ubuntu.com/5720012/
<seb128> lordievader, what Session= do you have in ~/.dmrc?
<lordievader> seb128: kde-plasma
<BluesKaj> all seems fine here after the changes
<seb128> lordievader, did you try without a blank line in /etc/upstart-xsessions?
<stgraber> BluesKaj: cool, and "initctl status startkde" shows you "start/running"?
<lordievader> stgraber, seb128 Ah now it is present, without the white line.
<lordievader> Without the blank-line in upstart-xsessions I mean.
<seb128> lordievader, initctl lists things?
<BluesKaj> stgraber, yup startkde start/running , is the first line among many :)
<lordievader> seb128: This is the output of initctl lists: http://paste.ubuntu.com/5720021/
<seb128> stgraber, ^
<lordievader> Same here now.
<stgraber> cool, that looks good
<stgraber> lordievader: can you also pastebin a "ps faux" output, I want to confirm that all the user processes are now under upstart.
<BluesKaj> stgraber, my above comment was about the "initctl list"command , the "initctl status startkde" command gives , startkde start/running, process ...
<lordievader> stgraber: Here you go: http://paste.ubuntu.com/5720040/
<xnox> Daviey: jamespage: I hear that maxb needs/wants to port python-libvirt to python3. Have you heard if that's wanted/needed/started for OpenStack as well?
<maxb> Hm? Not me
<maxb> bad tab complete?
<xnox> maxb: correct, got the wrong nick.
<xnox> I am after Max Brustkern which is nuclearbob
<Daviey> maxb: Feel free to be a stakeholder
<Daviey> xnox: Yes, all things python3, want, yes.
<xnox> Daviey: well nuclearbob said he has time to do it =)
<Daviey> zul: ^
<xnox> Daviey: he was pondering if anyone else was doing it already.
<Daviey> xnox: Perfect.  Thanks
<Daviey> xnox: zul is working on some deps right now.. but i don't think he touched that yet.
<zul> xnox:  havent touched it yet
<xnox> zul: yeah, it's ugly pit of auto-generated C bindings from custom xml sources.....
<zul> xnox:  be my guest ;)
<xnox> zul: what are you working on porting?
<zul> xnox: just make sure you push upstream
<zul> xnox:  just porting opentsack dependencies to python3
<xnox> zul: those that are pure-python?
<zul> xnox: so far yes
<xnox> ack.
<dholbach> hum... could anyone help me debug why the microphone I'm using probably doesn't work? hrm, it worked yesterday
<seb128> dholbach, tried to reboot?
<dholbach> yes
<seb128> dholbach, or to boot a previous kernel?
<dholbach> yes, I was too quick to delete the old one, just downloading it now :)
<seb128> always keep the n-1
<dholbach> yeah :)
<seb128> that can come handy :p
<dholbach> brb :)
<dholbach> seb128, no dice
<seb128> :-(
<seb128> dholbach, how/where do you test it?
<dholbach> skype and google hangout
<dholbach> tried alsamixer and gnome-volume-control (or whatever it's called now) settings
<seb128> do you see the level stuff move in the system settings panel?
<dholbach> no
<seb128> :-(
<dholbach> not sure where to go from here
<seb128> dholbach, do you see any error in the pulseaudio log (if you pulseaudio -k && pulseaudio --start)?
<dholbach> no
<dholbach> not sure if "(gnome-settings-daemon:1925): media-keys-plugin-WARNING **: Unable to get default sink" is supposed to mean anything or when it came up in .xsession-errors
<seb128> dholbach, drop the --start, just "pulseaudio" to get the output
<seb128> dholbach, weird, you shouldn't have logs in .xsession-errors to start since we have upstart user sessions and they log in .cache/upstart
<dobey> cjohnston: hi there. if you have a few seconds, i was wondering if you could poke at doing bug #1185988 please. thanks. :)
<ubottu> bug 1185988 in libubuntuone (Ubuntu) "Archive removal" [Undecided,New] https://launchpad.net/bugs/1185988
<dholbach> this is raring, not saucy
<seb128> oh
<cjwatson> dobey: ITYM me
<dobey> cjwatson: ITVM?
<cjwatson> "I think you mean"
<dobey> cjwatson: oh yes. sorry. i did mean you. :)
<dobey> cjohnston: ignore that :)
<seb128> dholbach, $ gconftool --get /system/gstreamer/0.10/default/audiosink
<zyga> andrewhaigh_cell: that's very odd, can you show me output of 'vagrant box list'
<seb128> though I'm not even sure skype/hangout use gstreamer...
<dholbach> seb128, autoaudiosink
<zyga> hmm
<seb128> dholbach, nothing in the pulse log if you stat without --start?
<dholbach> seb128, no
<seb128> dholbach, we would need diwic around :/
<seb128> dholbach, try to sudo apt-get install paprefs
<seb128> dholbach, wait
<dholbach> pavucontrol?
<cjwatson> My fingers *still* reach for lp-remove-package.py as their first instinct when removing a package
<seb128> dholbach, yes, rather
<seb128> dholbach, what does that list as input?
<cjwatson> Exactly a year after it was obsoleted
<dholbach> seb128, Analog Input
<dholbach> just one
<dholbach> and it's the "Internal Audio" device with "Analog Stereo Duplex"
<cjwatson> dobey: done
<seb128> dholbach, and the orange bar bellow it doesn't move?
<seb128> dholbach, the volume is not muted right?
<dholbach> no
<dholbach> unfortunately not - I've no idea what else it could be, I'm on the old kernel and this was never much of a problem
<seb128> dholbach, could be an hardware issue ...
<seb128> dholbach, you don't have a bluetooth headset, webcam or other?
<dholbach> no, nothing of the sort
<dholbach> but now I just plugged in a usb audiocard and the internal mic works now
<dholbach> :-(((
<seb128> wth
<dholbach> yes
<dholbach> wth
<seb128> dholbach, sorry I don't know enough about pulse to be useful, we would need diwic or TheMuso
<dholbach> will do
<dholbach> next week :)
<seb128> dholbach, well, at least you got it working
<dholbach> yeah, "working" ;-)
<dobey> cjwatson: thanks much!
<mitya57> seb128: fwiw, I had some progress with gdcm, it now builds up to 69 %, will continue debugging on WE
<seb128> mitya57, thanks, we didn't sort out libreoffice yet and Riddell didn't fix okular either
<Riddell> I didn't?
 * Riddell looks
<Riddell> hmm, so I didn't
<Riddell> seb128: uploaded
<seb128> Riddell, thanks ;-)
 * claudevandort 
<mitya57> bdmurray: re bug 1047424, it's already in the sru queue
<ubottu> bug 1047424 in software-properties (Ubuntu Raring) "[Additional Drivers] The Button "Restart" is triggering a shutdown" [Medium,Triaged] https://launchpad.net/bugs/1047424
<bdmurray> mitya57: The raring queue?
<bdmurray> I rejected an upload of software-properties to the raring queue earlier today because it really should have gone to saucy.
<slangasek> cjwatson: so the pango changes seem to have broken the cryptsetup initramfs hook; can you point me to what we should be doing there now?
<mitya57> bdmurray: oh yes, I saw it a couple of days ago there and thought it still is there
<cjwatson> slangasek: Follow the lead of https://launchpad.net/ubuntu/+source/plymouth/0.8.8-0ubuntu7, I think
<xnox> is that due to linking harfbuzz?! (me's laptop is booting fine with full-disk-encryption)
<xnox> ah.
<slangasek> cjwatson: oh, er, maybe I meant plymouth rather than cryptsetup actually
<slangasek> cjwatson: ah, apparently I have a local plymouth 0.8.8-0ubuntu7 here with different changes :P
<slangasek> yeah, that would do it! thanks :)
<cjwatson> Heh :)
<mitya57> bdmurray: do you want a debdiff from me then?
<bdmurray> mitya57: that'd be great
<mitya57> bdmurray: you can take https://bazaar.launchpad.net/~ubuntu-core-dev/software-properties/main/diff/842.1.1 then (I'm cheating, yes)
<Quintasan> stgraber: FYI, that upstart KDE magic worked for me too. At least on a VirtualBox machine
<stgraber> cool
<blitzkrieg3> what's the procedure if you wan to develop on top of a -proposed bzr branch that is verification-failed?
<tumbleweed> so it was deleted from -proposed?
<cjwatson_> infinity: Second opinion needed: I don't suppose you can work out why automake1.13 is failing (https://launchpad.net/ubuntu/+source/automake1.13/1:1.13.2-1ubuntu1/+build/4628811)?  For the life of me I can't reproduce it locally, and I tried to get more information with a PPA build (https://launchpad.net/~cjwatson/+archive/ppa/+build/4630398) but that inconveniently succeeded.
<cjwatson> I could keep throwing it against the wall in case it randomly works, but that seems an unfriendly thing to do with an 80-minute build.
<cjwatson> And I sort of feel bad about inserting instrumentation into distro uploads.
<cjwatson> Unless it's a subsecond-granularity-in-filesystem-mtimes thing, perhaps ...
<cjwatson> What filesystems do the buildds use?
<infinity> cjwatson: ext... Probably 3, given the age of some of the installs.  Though, I'd expect 4 on the newer x86 kit.
<cjwatson> Last procenv build seems to think ext4 on allspice.
<infinity> It could be a bit more verbose about HOW that test failed...
<cjwatson> But both my automake1.13 failures were on roseapple.
<cjwatson> Indeed.  Maybe my PPA hack wouldn't be too unreasonable for a distro upload anyway.
<cjwatson> Specifically http://paste.ubuntu.com/5721401/
<infinity> cjwatson: I'm all for fixing racy testsuites (and we should), but if it works almost all the time and is hard to diagnose, I'm also pragmatic.
<cjwatson> Aha, https://launchpadlibrarian.net/138643870/buildlog_ubuntu-saucy-i386.procenv_0.20-1_UPLOADING.txt.gz says roseapple is ext3.
<infinity> cjwatson: buildd time on weekends is virtually free, giving it back for !roseapple would be acceptablish.
<infinity> cjwatson: roseapple's the oldest x86 buildd, so it being ext3 makes sense.
<infinity> cjwatson: On the flipside, if we have a testsuite that blows up on ext3, that seems less than ideal.
<cjwatson> And ext3 doesn't have subsecond timestamps.
<infinity> cjwatson: Does the testsuite *depend* on subsecond timestamps, or it is just racy enough to sometimes fail without 'em?
<cjwatson> Looking at the code, I suspect it's racy.
<cjwatson> It's repeatedly running configure/make, prodding stuff, checking that configure gets automatically rebuilt.
<infinity> cjwatson: Well, I'm happy with either "dig deeper and fix" or "scream LA LA LA CAN'T SEE YOU as we requeue it on !roseapple"... Up to you.
<cjwatson> Which is going to depend on whether the runs in question take it across a second boundary.
<cjwatson> I think I might do both.  Requeue on !roseapple for now, in parallel attempt to reproduce on ext3 and report upstream.
<infinity> cjwatson: That works.  It wasn't an XOR. ;)
<infinity> (Though, I suppose the English word "either" preceding an OR implies XOR, doesn't it?)
<infinity> Boolean interpretation of conversational language is tricky.
<cjwatson> conventionally :)
<cjwatson> Whoops.  Dear cjwatson, try giving back the correct version.
<cjwatson> Bingo, that test fails first time on ext3.
<infinity> cjwatson: Probably fair to say, as a belt-and-bracers thing, that we should file a ticket to reinstall any remaining ext3 buildds as ext4.  Not for the testsuite, but just for not tripping on make races in general.
<cjwatson> I'll report it tomorrow
<cjwatson> Yeah, there's an argument for that, I guess
<cjwatson> Though you do have to be working at it to trip over this
 * cjwatson -> bed
<infinity> cjwatson: Well, it mostly only matters on sufficiently speedy hardware, which means that, in practice, roseapple may be the only affected machine, really.
<infinity> cjwatson: ia64 and sparc will be ext3, but I don't care, and ross and adare probably are, but are slow enough to not trip often on such things.
<infinity> Grr, forgot to accept the UEIF blobs for that kernel SRU.  Such an unintitive workflow...
#ubuntu-devel 2013-06-01
<slangasek> stgraber: so I have an answer (ish) on the rpc.gssd problem; there's an opaque pointer being passed between two libraries (libgssapi-krb5-2 and libgssglue1), and the two libraries don't agree about the pointer's internal structure. :-P
<slangasek> (libgssglue has a gss_init_sec_context() that assumes an argument of type gss_cred_id_t can be cast to a gss_union_cred_t, which is not the case because the libgssapi-krb5 gss_cred_id_t has a leading loopback pointer at the front of the struct)
<slangasek> stgraber: so!  fixed with the addition of a single configure flag
<slangasek> stgraber: I'll have a look at the Debian package; I suspect the bug is also present there
<psusi> so the ppa build daemons get hung up trying to build grub2 and the job has some odd output and never finishes... is there someone who can debug the build daemons?
<slangasek> stgraber: and that's Debian bug #707960.
<ubottu> Debian bug 707960 in nfs-common "rpc.gssd segfaults when mounting a nfsv4 volume" [Important,Open] http://bugs.debian.org/707960
<infinity> psusi: Example?
<psusi> infinity, https://launchpad.net/~psusi/+archive/ppa/+build/4631612
<psusi> I didn't even modify this build from the current raring sources
<infinity> psusi: And this has consistently happened more than once?
<psusi> yes
<psusi> happens on both archs, tried rebuilding 3 times, and today uploaded an unmodified version to rule out my changes doing it
<infinity> psusi: It could just that the testsuite hates running either under Xen, on kernel 2.6.32, or on LVM.  None of those are things I can "fix".
<infinity> s/32/24/
<psusi> what is different about how the main repo is built?
<infinity> All of those things.
<infinity> The main archive builds on bare metal, not Xen, isn't LVM-backed, and is on kernel 3.2.0
<infinity> psusi: Anyhow, I wish I could give you a more satisfying answer, but we're in the process of tearing out, redesigning and rolling out a new PPA infrastructure, so we are investing exactly zero resources into hunting weird behaviours in the old one.
<infinity> psusi: Your best bet is probably to test your builds locally to make sure they pass the testsuite, then upload to your PPA with the suite disabled and call it good enough.
<psusi> hrm... that was going to be my last resort... I was hoping to find a way to debug the issue thoguh
<infinity> psusi: Well, the way to debug it would be to run an LVM-backed hardy Xen DOMU on a hardy DOM0.
<infinity> psusi: Which, as you can imagine, isn't something most sane people want to do, since it's not 2008 anymore. ;)
<psusi> I can't imagine how the volume ultimately being stored on lvm outside the vm would matter, but the tests do appear to use qemu so maybe it has a problem running under xen?  my server I built it on locally is using lvm, but not xen currently... maybe I'll try booting it in xen mode
<psusi> wait, hardy?
<infinity> psusi: Ahh, if the tests use qemu, it could be a nesting issue.  Xen on qemu on qemu on Xen on qemu on Xen on Xen works pretty well these days, but it was slightly less friendly back then.
<psusi> wow, so the build daemons are still running hardy?
<infinity> psusi: Only the virtual PPA ones, but yes.  Long story.
<psusi> any eta on the new build system?
<infinity> psusi: Comes from us not having Xen support in lucid, so they never found a smooth upgrade path, and by the time we had Xen support in precise (which is quite good), we'd already decided to tear out our homebrew solution and replace it with openstack.
<infinity> psusi: But that replacement isn't quite done yet.
<infinity> psusi: I couldn't give you an ETA.  I know some stuff has progressed to a bit of a testing stage, but how far away we are from rolling it out and calling it production-ready is anyone's guess.
<infinity> psusi: (The hope is "soon", but certainly not soon enough to make you less sad about your grub builds :P)
<psusi> so if I disable the test suite and get it to build in my ppa and have the user verify the fix, then when it gets uploaded to -proposed, it should build fine with the tests enabled?
<infinity> psusi: That seems like a reasonable assumption, given that I haven't seen the grub2 testsuite fail on the archive buildds yet.
<psusi> say, why do the ppa builds use virtual machines?
<infinity> psusi: Because ANYONE can upload packages to build on them, which means we're giving the whole world root.
<infinity> psusi: They're designed to wipe clean and reset after every build.
<psusi> why not just build with fakeroot, like pbuilder does?
<infinity> psusi: Err, no.  You're missing the attack vector.  A PPA can build-dep on packages in a PPA.
<infinity> psusi: The initial phase of a build is installing build-deps, as root.
<psusi> ohh
<stgraber> slangasek: cool, thanks for tracking this down!
<NikTh> Hello everyone
<NikTh> Is here a good chanell to ask about Unity Next ? I've just downloaded per and builded per instructions here: http://unity.ubuntu.com/getinvolved/development/unitynext/ , but a problem occured..
<NikTh> I cannot running it because of this error : ./run: 56: ./run: ./builddir/qml-phone-shell: not found
<NikTh> Tried to mkdir builddir and cp qml-phone-shell.desktop.in file inside but to no avail. (other bunch of errors occured). Also tried ./build_unity  --clean (rebuilding) again to no avail.
<mitya57> BenC: Please check "Note about PowerPC support changes" section in bug 1186577. It will be nice if you verified if we should keep or drop that delta.
<ubottu> bug 1186577 in gccxml (Ubuntu) "Sync gccxml 0.9.0+git20130511-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1186577
<mitya57> (In other case we'll sync and re-add that if it still FTBFS)
<mitya57> jbicha: thanks for uploading metacity!
<gotwig> where can I get support for ubuntu lts
<penguin42> gotwig: #ubuntu for free help
<penguin42> gotwig: You can submit bug reports using the ubuntu-bug command
<penguin42> gotwig: http://www.ubuntu.com/support/
<gotwig> penguin42: the thing is, there is no right click support for ubuntu 12.04 for multitouch clickpads
<gotwig> I hope it gets fixed in the next LTS upgrade
<penguin42> I don't know anything about multitouch  - sorry
#ubuntu-devel 2013-06-02
<ajnr> Hi I am facing problem while shutdown my ubuntu 12.04 system, it just hang. and while booting also it took so much time , plz help me out
<sladen> ajnr: you've gone, but we'd need a few more details to assist
<ajnr> Hi I am using ubuntu 12.04 , I am facing problem "shutdown hangs"  and also booting is very slow. I have tried with various trics but not able to find. plz help me out
<sladen> ajnr: hello again
<sladen> ajnr: we'd need a few more details...
<sladen> ajnr: is it something that has happened suddenly?  Or even since you've installed it
<sladen> ajnr: is it a Hard disk, or SSD.  How much RAM.  Did you install any new software recently?
<ajnr> sladen, yes , since few days it shows this problem
<ajnr> sladen, its HDD
<ajnr> sladen, https://bugs.launchpad.net/ubuntu/+source/indicator-session/+bug/1186605
<ubottu> Launchpad bug 1186605 in indicator-session (Ubuntu) "12.04 ubuntu shutdown hangs " [Undecided,New]
<ajnr> sladen, initialy it was nice , but since few weeks this is really troublesome ! every time i have to manually press the powerbutton
<ajnr> sladen, while shutting down ubuntu system it shows some information on the screen , how to get those information, so that I can show you
<sladen> ajnr: what sort of information?
<sladen> ajnr: log file entries?
<sladen> ajnr: it may be at the end of /var/log/syslog
<ajnr> sladen, yes
<achernya> ajnr: I saw the same symptons yesterday on an Asus Zenbook, that were caused by the audio driver crashing on boot. Could you please check the output of "dmesg" and see if the words "BUG" or "Oops" appear anywhere?
<ajnr> 0.575652] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored achernya
<achernya> ajnr: That one is not relevant, luckily. Anything else?
<ajnr> achernya, 1.185638] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
<achernya> ajnr: That's also probably fine.
<ajnr> achernya, https://bugs.launchpad.net/ubuntu/+source/indicator-session/+bug/1186605
<ubottu> Launchpad bug 1186605 in indicator-session (Ubuntu) "12.04 ubuntu shutdown hangs " [Undecided,New]
<ajnr> achernya, I dint find any BUG
<achernya> Ah, I missed the link. Let me read the dmesg a bit.
<ajnr> achernya, and oops too
<ajnr> achernya, okey
<achernya> ajnr: hm, I don't see anything obvious.
<ajnr> achernya, So wht to do ? New installation !!!
<achernya> ajnr: When your laptop hangs on shutdown, does sending SysRq+[REISUB] cause it to reboot? (See http://en.wikipedia.org/wiki/Magic_SysRq_key#Uses)
<ajnr> achernya, Whats these? When it hangs wht I did is just press the power button !!
<achernya> ajnr: This is a way to instruct a seemingly-hung system to attempt to reboot safely. If it works, it means the system is still alive, but stuck somewhere.
<ajnr> achernya, hmm how to do that ?
<achernya> ajnr: Please read the WIkipedia page. You press Alt+SysRq+[each of R, E, I, S, U, B in that order]
<ajnr> achernya, okey let me try
<ajnr> achernya, nothng happen
<achernya> ajnr: Sorry, can you elaborate?
<ajnr> I press  Alt+SysRq+[each of R, E, I, S, U, B in that order] whn it hags
<ajnr> *hangs
<ajnr> achernya, I press  Alt+SysRq+[each of R, E, I, S, U, B in that order] whn it hangs
<ajnr> achernya, nothng happen
<achernya> ajnr: Hm, that sounds like a kernel panic on shutdown.
<ajnr> achernya, I have taken one screenshot , just uploading it on the bugs link , plz wait
<ajnr> achernya, plz see the last attachment in https://bugs.launchpad.net/ubuntu/+source/indicator-session/+bug/1186605
<ubottu> Launchpad bug 1186605 in indicator-session (Ubuntu) "12.04 ubuntu shutdown hangs " [Undecided,New]
<achernya> ajnr: Sorry, that's beyond my ability to debug. Perhaps you could try installing the new kernel from 13.04
<ajnr> achernya, command to update the kernel
<ajnr> will it be good to updat ethe kernel? achernya
<geofft> The fact that you're running VMware is (unfortunately) confounding this
<geofft> Although, I might ask if you're using the latest VMware version.
<ajnr> achernya, I think kernel upgrade
<geofft> Also this is vaguely the wrong channel -- we should move to commenting on the bug
<ajnr> geofft, is it for me ?
<achernya> ajnr: I agree with geofft, but I think the command you want is "apt-get install linux-image-generic-lts-raring"
<ajnr> geofft, how to get rid of this ?
<ajnr> achernya, ya I will upgrade my kernel. Is it the solution ?
<achernya> ajnr: I don't know. It's a possibility.
<ajnr> achernya, okey ! but geofft , any idea can you highlight?
<ajnr> achernya, right now my kernal is Linux 3.2.0-44-generic
<achernya> ajnr: Please move to #ubuntu, this is not a support forum, and we've completed the bug triage, and determined that it is above my level
<achernya> ajnr: for general support, please use #ubuntu
<achernya> ajnr: I am also in that channel.
<ajnr> achernya, okey Thanks
<YokoZar> Shouldn't apport not be reporting bugs like this?  https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/1186703  (user's PPA package is conflicting with a file in a system package, apport wants to file the bug against the system package)
<ubottu> Launchpad bug 1186703 in wine1.4 (Ubuntu) "package wine1.4 (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/wineserver.1.gz', which is also in package wine-etersoft 1.0.12-eter14ubuntu" [Undecided,Invalid]
#ubuntu-devel 2014-05-26
<psusi> anyone know anything about g_udev_device_get_sysfs_attr?  it seems to cache the attribute the first time it is read and never re-reads it
<pitti> Good morning
<Logan_> hey pitti
<Logan_> quilt patches that delete files make me (and bar) sad
<Logan_> *bzr
<mterry> stgraber, the lxc autopkgtests seem to be failing?
<stgraber> mterry: they sometimes do that but usually end up passing, if they're now all failing, that's because something somewhere regressed
<mterry> stgraber, I don't know about all failing.  I just noticed it holding up a cgmanager update: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html  - looks like the unpriv tests failed?
<mterry> stgraber, if that's the sort of thing that might pass if retried, I can do tht
<stgraber> mterry: hmm, no, retrying won't help with that one, we apparently switched to 3.15 and we need some upstream fix for that. I'll cherry-pick and upload in a bit
<mterry> stgraber, oh cool, glad it's a known issue  :)
<stgraber> mterry: yeah, the 3.15 kernel now prevents reading some files to non-root users...
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<timchen119> hi, I found lp:ubuntu/python-debian is not sync with lp:python-debian , anyone know how do I help? any wiki page describe this sync process?
<timchen119> last commit in lp:python-debian is 2012-10-08, but it still not in Utopic.
<zbenjamin> cjwatson: ping, is there any directory i can put a file that i can read from inside confinement? i get permission denied for /tmp
<sarnold> zbenjamin: hopefully this can help: https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest
<cjwatson> zbenjamin: yep, security team for confinement questions :)
<zbenjamin> sarnold: thx
<zbenjamin> sarnold: i'm working on debugging confined apps. What i need to do is run gdbserver inside a click package so i can connect to it
<sarnold> zbenjamin: I suspect the ptrace attach will fail; why not run gdb 'outside' the click package?
<zbenjamin> sarnold: how should i connect to the application running inside then?
<zbenjamin> sarnold: attaching is no option, it would make it impossible to debug the application startup
<sarnold> zbenjamin: that's a fine question.
<zbenjamin> sarnold: also we need a way to connect to the qmljs debugger which always runs inside the app and opens a port so the IDE can connect to it
<zbenjamin> sarnold: i guess we will need a debug policy that allows this stuff
<sarnold> zbenjamin: what kind of port? tcp would be currently unmediated, that ought to work fine today.
<zbenjamin> sarnold: i think its tcp
<zbenjamin> sarnold: thats basically the wrapper script that sets up the stuff inide the confinement : http://pastebin.ubuntu.com/7519903/
<sarnold> zbenjamin: ah, good. so that means qmljs ought to work ..
<zbenjamin> sarnold: thats how it fails: http://pastebin.ubuntu.com/7519911/
<sarnold> zbenjamin: I think that script would work alright from outside confinement though
<zbenjamin> sarnold: yeah but i was told we want to debug our apps in confinement because we need to be as close as possible to the real environment a app gets
<sarnold> zbenjamin: yeah, I can understand that desire. I'm not sure how well it'll work though.
<zbenjamin> sarnold: so gdbserver will listen on a tcp port as well, the only thing that needs to be sorted out is the ptrace call you mentioned. Any idea how we can get there?
<zbenjamin> i'm actually not really sure if the failure i see is because of that, i get permission denied but the exception still happens in python.
<sarnold> zbenjamin: yeah, that's a simple denied for exec(gdbserver), they'll get worse and scarier once that execute is allowed. :)
<zbenjamin> sarnold: can i allow that call somehow?
<sarnold> zbenjamin: if you edit the generated apparmor policy (in /var/lib/apparmor/profiles/) and then install that updated policy, you can probably get there
<zbenjamin> sarnold: how about providing a debug policy ? The store would need to reject that of course
<sarnold> zbenjamin: you -might- get lucky if you add /usr/bin/gdbserver Ux, permissions to your policy
<sarnold> zbenjamin: yeah, that's a really good idea
<zbenjamin> sarnold: can you help me put one together?
 * zbenjamin <-- app armor noob
<sarnold> zbenjamin: sure
<zbenjamin> for now we "only" need to execute gdbserver and be able to connect with tcp
<sarnold> zbenjamin: do you see a file in /var/lib/apparmor/profiles that cooresponds to your app?
<zbenjamin> sarnold: no the app is uninstalled after executing it :/ the adk-launcher script is doing that automatically  but i can disable it for now
<sarnold> zbenjamin: oh nuts. well, okay...
<zbenjamin> now i have that file
<zbenjamin> sarnold: best would be if i could just add "debug" to my policy list
<sarnold> zbenjamin: sure, that's a nice end goal :) but won't happen today, hehe
<sarnold> zbenjamin: if you can stand a bit of hackery in the meantime, try adding "/usr/bin/gdbserver Ux," to the file and reload it with apparmor_parser --replace /path/to/file
<sarnold> zbenjamin: -- this step will need to re-executed after package install but before the application is started
<zbenjamin> the problem the script does not run as root since we connect with ssh
<zbenjamin> and we install to the local click database
<sarnold> ahhh.
<zbenjamin> sarnold: gdbserver starts now, the app does not seem to come up and the ide does not connect ..
<sarnold> zbenjamin: woo, nice, can you grep DENIED /var/log/syslog  and pastebin those? (the pastebinit program can help here)
<zbenjamin> sarnold: http://pastebin.ubuntu.com/7520065/
<zbenjamin> sarnold: but looking at the timestamps they are not related
<sarnold> zbenjamin: some of them, indeed -- we shold probably file a bug or two for that, too
<zbenjamin> sarnold: meh the time on the phone is not correct ;)
<zbenjamin> sarnold: so they are related
<sarnold> zbenjamin: the [ dddd ] bits ar enormally 'seconds after boot'..
<zbenjamin> sarnold: i was able to connect from the gdb cli tool on the phone, but when i try to continue i get SIGTRAP'ed and then SIGABORT'ed
<sarnold> zbenjamin: did you get any new DENIED lines from that?
<zbenjamin> there are a few more http://pastebin.ubuntu.com/7520085/
<sarnold> jjohansen: is this one of those LSM calls that happens before the usual kernel security mechanisms? apparmor="DENIED" operation="mknod" ... name="/usr/lib/python3.4/__pycache__/shlex.cpython-34.pyc.3063768112" pid=5862 comm="qtc_device_debu" requested_mask="c" denied_mask="c" fsuid=32011 ouid=32011
<jjohansen> sarnold: yes
<Laney> bdmurray: could you upload ubuntu-release-upgrader?
<Laney> release upgrades are crashing with the bug you fixed in https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/revision/2808
<bdmurray> Laney: will do
<Laney> thanks!
<sarnold> zbenjamin: https://bugs.launchpad.net/ubuntu/+source/click-apparmor/+bug/1323233
<ubottu> Launchpad bug 1323233 in click-apparmor (Ubuntu) "debug policy group" [Undecided,New]
<zbenjamin> sarnold: fyi this is the debug script for the official ubuntu sdk ;)
<zbenjamin> sarnold: i'm part of the SDK team
<zbenjamin> sarnold: and this is part of RTM so we really need that
<zbenjamin> sarnold: because currently we use a bunch of hacks to provide debugging mechanism which fall apart every other day. We really need to replace this with something sane
<sarnold> zbenjamin: ah, I hadn't realized that was 'more official' :)
<zbenjamin> sarnold: yeah sorry i should have mentioned that ;)
<sarnold> zbenjamin: I just thought it was a nice script that'd been hacked together in desperation, hehe
<zbenjamin> sarnold: basically it is ;). I wrote it at the last week on the sprint. There is also the sdk launcher now that takes a click package as a argument and installs , executes and uninstalls after the application finishes running
<sarnold> zbenjamin: very nice
<zbenjamin> sarnold: i can confirm tcp connect works at least for the qmldebugger. Now we "just" need the c++ side ;)
<sarnold> zbenjamin: did you have to add anything to the apparmor policy to get the qmldebugger to work?
<zbenjamin> sarnold: i just added your gdbserver line
<sarnold> zbenjamin: was that necessary for the qmldebugger?
<zbenjamin> i can try to remove it
<bdmurray> pitti: libc6-dbg did not improve the crash files
<pitti> bdmurray: ah, too bad; so the badness is in gdb itself then :/
<pitti> xnox: lp:~upstart-devel/upstart/upstart-jobs doesn't yet have the init scripts from your unreviewed branch, but I guess that's expected
<slangasek> bdmurray, pitti: are we sure about the integrity of the core files themselves?
<pitti> slangasek: certainly not "sure", but I can't believe that we really get stack corruption on pretty much all the crashes, while they mostly work on x86
<zbenjamin> sarnold: ok the line is not required. But the connection is slow, but that comes from qtc its waiting for some output from the app which it can not get of course
<pitti> many that we looked at have two frames in libc (I suppose the usual "pass NULL pointer to string comparison" etc.), and then nothing else, just the "corrupted stack" error
<pitti> slangasek: ^
<slangasek> pitti: have we tried native backtracing with gdb on armhf?
<slangasek> (to rule out whether it's a gdb vs. gdb-multiarch problem)
<pitti> slangasek: that already was native, AFAIUI
<pitti> slangasek: i. e. it's gdb running *on* the phone at the time of the crash
<slangasek> mmm
<pitti> slangasek: so we ruled out foreign arch problems
<slangasek> does gdb get a useful backtrace if you attach it to a running process on armhf?
<zbenjamin> sarnold: would be nice if you could change the bug report so its clear that this is more official ;)
<zbenjamin> sarnold: or should i just  comment on it
<sarnold> zbenjamin: I can fix it up some :)
<zbenjamin> sarnold: awesome
<pitti> slangasek: I don't know right now, that's an interesting test; although it needs to happen on something which is actually busy, otherwise we'll just catch some poll()/select(); bdmurray, did you happen to try that already?
<GunnarHj> Hi pitti!
<pitti> hey GunnarHj
<GunnarHj> pitti: People are asking for langpack updates. Any chance that you can press the button?
<GunnarHj> https://lists.ubuntu.com/archives/ubuntu-translators/2014-May/006507.html
<pitti> GunnarHj: for trusty?
<pitti> GunnarHj: I can copy the current PPA to -proposed, yes
<GunnarHj> pitti: Yes.
<GunnarHj> pitti: Would that be an SRU?
<pitti> GunnarHj: yes, they've always been
<GunnarHj> pitti: Ok, I keep learning. :)
<pitti> GunnarHj: meh, https://launchpad.net/~ubuntu-langpack/+archive/ppa times out
<pitti> GunnarHj: does this actually have recent trusty updates?
<GunnarHj> pitti: Actually I haven't checked... Just saw the postings.
<seb128> pitti,  language-pack-de 	1:14.04+20140522
<seb128> one example
<seb128> you can try reloading, it didn't timeout here
<pitti> https://launchpad.net/~ubuntu-langpack/+archive/ppa?field.series_filter=trusty
<pitti> ah, that looks fine
<pitti> yeah, I'm fine with uploading that
<bdmurray> pitti: no, I have not
<pitti> GunnarHj: we need a wiki page where testers mark the tested languages; would you mind setting that up?
<pitti> GunnarHj: I think we haven't actually done that (updates) for a long time :/
<pitti> GunnarHj: ah, on https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA
<GunnarHj> pitti: Hmm.. I may take a look, but it will have to take a while.
<pitti> GunnarHj: so it's just a new entry on above wiki page and sending a call for testing AFAICS
<GunnarHj> pitti: Is the purpose of that page to document tests before SRUing translations?
<pitti> GunnarHj: the purpose is that people run these standard tests (desktop comes up, you can run updat-emanager, etc.) for a particular language
<pitti> GunnarHj: and after the timeout we release the languages which got tested
<GunnarHj> pitti: I see. Have to quit now. Talk to you later.
<zbenjamin> sarnold: any chance we can get that in in the next days?
<sarnold> zbenjamin: could be, depends how much of jamie's time I can get :)
<shadeslayer> ev: can usb-creator 0.2.57 be released for trusty too?
<xnox> pitti: correct. Cause it's not in the archive yet.
<pitti> xnox: http://paste.ubuntu.com/7520913/
<xnox> pitti: ^
<slangasek> seb128, pitti: is bug #1289031 assigned to the right component?
<ubottu> bug 1289031 in gnome-settings-daemon (Ubuntu) "touchpad re-enables itself after suspend/resume" [Undecided,New] https://launchpad.net/bugs/1289031
<seb128> slangasek, could be bug #1283863
<ubottu> bug 1283863 in unity-settings-daemon (Ubuntu) "disabling touchpad is not persistent" [High,Confirmed] https://launchpad.net/bugs/1283863
<seb128> but if you run unity, unity-settings-daemon is the right component
<seb128> (well, assuming the issue is with the settings daemon, and not xorg/synaptic driver)
<slangasek> right; I think I filed that bug before u-s-d was a separate thing
<seb128> slangasek, if you can reproduce, it would be interesting to see if that happens as well when unity-settings-daemon is not running
<slangasek> ok
<slangasek> it's intermittently reproducible
<seb128> :-/
<slangasek> if I killall unity-settings-daemon, does it stay dead?
<seb128> it's an upstart job, just stop it
 * slangasek nods
<dobey> seb128: hey, can you approve or whatever needs to be done to unity-scope-click to get it from u-proposed into the archive? seems it's held for migration as it added a dependency on ubuntu-sdk-libs
<seb128> dobey, "unity-scope-click/arm64 unsatisfiable Depends: ubuntu-sdk-libs "
<seb128> dobey, you need to make ubuntu-sdk-libs available on arm64, or to make unity-scope-click not build there (or not depends on the libs)
<pitti> xnox: bug 1323274
<ubottu> bug 1323274 in dovecot (Ubuntu) "Restore Debian's init.d script for insserv compatibility" [Undecided,New] https://launchpad.net/bugs/1323274
<dobey> seb128: oh, ugh
<tseliot> seb128: what are the plans on unity-settings-daemon? Are we going to rebase our changes on topo of the latest g-s-d? Also, where's the RCS?
<tseliot> *top
<seb128> tseliot, what is "RCS"?
<pitti> revision control system?
<tseliot> seb128: revision control system
<seb128> oh, VCS?
<seb128> lp:unity-settings-daemon
<tseliot> yes
<tseliot> sorry
<tseliot> seb128: or is it a permanent fork that we should develop separately?
<seb128> rebase ... we might, depends of how much work it is/the benefits/who has slots to work on that
<seb128> it's a fork
<seb128> but it doesn't mean we should backport commits that benefit us
<seb128> or rebase on newer versions if it makes sense
<tseliot> they fixed a lot of use cases for wacom tablets and touch screens
<tseliot> that is why I'm asking
<seb128> we are likely to update e.g the wacom code, not sure about the other plugins there
<xnox> pitti: http://paste.ubuntu.com/7521117/
<seb128> wacom needs to be updated in sync with the control center I think
<tseliot> seb128: they introduced a new device mapper that requires a fair amount of work to backport and to hook into the plugins
<seb128> in what cycle?
<tseliot> I had a look at git master
<tseliot> those are changes from 2013-2014
<tseliot> seb128: g-s-d 3.12 includes all the fixes, except for one
<dobey> seb128: can i make a binary dep be used on all archs except for arm64?
<seb128> tseliot, I'm not sure we are going to update that this cycle, somebody owning wacom hardware and having slots to work on that working on updating that code would be nice
<seb128> dobey, you need to list the archs manually
<dobey> ogra_: hi. what's keeping ubuntu-touch-meta from being built on arm64?
<dobey> seb128: but i can't do [!arm64] for binary deps?
<ogra_>  no idea, doesnt it build ?
<seb128> dobey, I don't think so
<dobey> ogra_: i guess ubuntu-touch-meta has explicit archs listed. it's only built on i386, amd64, and armhf
<dobey> ogra_: i'd expect it will build fine, but maybe all the binary deps don't build fine on arm64?
<ogra_> ogra@styx:~/Devel/packages/ubuntu-touch-meta-1.141$ grep amd64 update.cfg
<ogra_> architectures: i386 amd64 armhf
<ogra_> right
<tseliot> bdmurray: hi, can you have a look at LP: #1322212 please?
<ubottu> Launchpad bug 1322212 in xorg-server-lts-saucy (Ubuntu) "Switching to the Guest session results in a black screen" [High,In progress] https://launchpad.net/bugs/1322212
<ogra_> it is explicitly disabled atm ...
<tseliot> seb128: ok, I'll see what I can do...
<ogra_> dobey, why do you need it on arm64 ? and 64 bit phones in sight =
<ogra_> ?
<seb128> thanks
<dobey> ogra_: is there a list of what's keeping it from being built elsewehre?
<ogra_> dobey, it was never enabled on anything else but the three arches my grep above lists
<sarnold> ogra_: apple sells one :)
<ogra_> and i assume the seeds are set up similar
<dobey> ogra_: because unity-scope-click is architectue: any in the control file, and we just added a binary dep on ubuntu-sdk-libs, because it is what provides the list of frameworks
<ogra_> sarnold, oh, you are planning to purt ubuntu-touch to an iphone ?
<ogra_> :P
<ogra_> *port
<sarnold> ogra_: wouldn't that be a fun target? :)
<ogra_> doanac, hrm
<ogra_> err
<ogra_> dobey,
<dobey> so right now this makes the scope uninstallable on arm64, though otherwise it builds and installs fine there
<sarnold> it'd actually make more sense for us; apple sells content consuming devices. we've aiming for a converged computing device, and I haven't had < 4 gigs of memory on my computer in a very long time..
<ogra_> dobey, hmm, i would actually prefer to have an override for the autopkgtest stuff in that case ... i suspect blindly enabling arm64 in the seeds and metapackages will open a big can of worms and cause a lot of extra work
<ogra_> dobey, did you ask infinity or cjwatson if we could jet override it for now ?
<bdmurray> tseliot: is that supposed to superceed the existing package in precise-proposed?
<ogra_> s/jet/just/
<dobey> ogra_: and just have an uninstallable unity-scope-click on arm64?
<ogra_> dobey, right
<ogra_> until we have actually seeds for that arch
<dobey> i haven't asked, no.
<tseliot> bdmurray: yes. I also included the previous changes in the diff
<ogra_> switching the seeds on on this arch will likely mean we need to make the whole of ubuntu-touch ... or at least the whole of the sdk-libs installable in the end
<ogra_> (or alternatively make the scope use [!arm64] but thats more ugly imho
<dobey> ogra_: a good thing i think, but i do agree it might mean a lot of work. i wonder if there's an easy way we can test it
<ogra_> )
<dobey> well, it's ugly, but probably less ugly than a built package that can't be installed :)
<bdmurray> tseliot: okay, could you add saucy tasks?
<bdmurray> tseliot: I mean precise
<tseliot> bdmurray: I think xorg-server-lts-saucy is only available in precise, isn't it?
<cjwatson> ogra_: that's not autopkgtest
<cjwatson> dobey: you can do [!arm64] in debian/control as long as it's not for an Architecture: all package
<cjwatson> dobey: though in this context it would be more correct to do [amd64 armhf i386]
<bdmurray> tseliot: While that may be true I'm pretty all the sru tools / reports want a task for the relevant release.
<dobey> cjwatson: might be better to just not build on arm64 i guess, since unity8 isn't building there currently
<cjwatson> well
<cjwatson> let me check what rdeps are already there
<dobey> well, it's depwait
<cjwatson> but it built before?
<dobey> i don't know
<cjwatson> must've done
<cjwatson> otherwise it wouldn't be a proble
<cjwatson> m
<cjwatson> ok, there are no reverse-dependencies of unity-scope-click/arm64
<dobey> it shows depwait on trusty and saucy too
<dobey> so i guess it's always been that way
<cjwatson> no it doesn't
<cjwatson>  unity-scope-click | 0.1+14.04.20140410.1-0ubuntu1 | trusty/universe          | source, amd64, arm64, armhf, i386
<cjwatson> dobey: so, I can remove this, but you'll have to actually stop it building
<ogra_> great :)
<dobey> cjwatson: ok, that's great. i'll make a branch to stop it building on arm64. and you'll override it for now to get the current package migrated?
<cjwatson> not override, but remove
<cjwatson> (done)
<cjwatson> I wouldn't just override this because adding uninstallable packages can make proposed-migration take bad decisions
<ogra_> ah, i didnt know that
<cjwatson> dobey: to be clear, if your branch doesn't land, the next upload will have the same problem :)
<dobey> oh ok
<dobey> cjwatson: yeah, i will make a branch now(-ish)
<cjwatson> ta
<tseliot> bdmurray: ok, let me fix that then
<tseliot> yay, launchpad failed...
<bdmurray> tseliot: hmm it oops'ed for me too. I'll just accept it then.
<tseliot> bdmurray: good. I think we can add a task later
<mterry_> stgraber, is there a bug for the lxc/kernel issue so I can subscribe?
<mterry_> stgraber, ah I see you uploaded a fix.  But it still fails autopkgtest?
<mterry_> But only two failures rather than three this time!  :)
<tseliot> bdmurray: thanks
<stgraber> mterry_: yeah, there's another kernel bug, jjohansen is on it
<jjohansen> mterry_: if you revert to the 3.13 kernel from earlier, that should work until the 3.15 kernel with the fix lands
<mterry_> jjohansen, I'm not concerned with testing it myself so much, it's just blocking a cgmanager update in utopic
<jjohansen> mterry_: ah okay
<Laney> woah
<Laney> I've never noticed that quilt series colours patches based on applied/top/unapplied
<Laney> is that new?
<GunnarHj> pitti: still there?
<ev> shadeslayer: if you want to go through the paperwork for an SRU, I'm happy to sponsor the upload
<shadeslayer> ev: heh
<shadeslayer> that's like the most annoying part of it :P
<shadeslayer> ev: anyway, I'll file the paperwork
<ev> :-P
<ev> thanks!
<shadeslayer> np
<ev> I've got the branch queued up and ready for a bug number to inject
<shadeslayer> ev: 1289026
<ev> cheers
<ev> shadeslayer: is that right? It's a regular bug not following the SRU format: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
<shadeslayer> ev: yes, I'm fixing that
<ev> ah right
<ev> I'll feed that into the branch
<shadeslayer> ev: done
<shadeslayer> ev: it's the bug that errors.ubuntu.com had linked to all the error reports
<shadeslayer> thought I'd just repurpose it
<ev> uploaded
<shadeslayer> cheers
<n4uah> hello..
<n4uah> is anyone can help with the ubuntu touch?
<rww> tried #ubuntu-touch?
<n4uah> i think some of them works at canonical.
<rww> Yep, and they also tend to hang out in #ubuntu-touch, hence me pointing you there. Have you tried it? :)
<n4uah> no..
<n4uah> now at their..
<n4uah> :)
<LLKCKfan> Hello
<LLKCKfan>  How can someone who is almost 30 and never had a job get one? I have been applying just to be told I am not what they are looking for or they are not hiring.
<Noskcaj_> LLKCKfan, I think you're asking in the wrong place
<LLKCKfan> then what is the right place
<genii> Probably some channel to do with employment
<Noskcaj_> pitti, Is it ok if i merge flashplugin-nonfree-extrasound?
<LLKCKfan> There are none
#ubuntu-devel 2014-05-27
<pitti> Noskcaj_: merge flashplugin-nonfree-extrasound> am I touched-it-last? sure, please do
<Noskcaj_> pitti, You were the last to look at it. oneric i think
<pitti> apachelogger, ScottK: do you mind if I upload kde-workspace to put back the init.d script? (needed for insserv compatibility, it won't actually ever run on Ubuntu)
<pitti> for bug 1323274, blocking https://code.launchpad.net/~ubuntu-core-dev/ubuntu/utopic/sysvinit/unreviewed/+merge/219999
<ubottu> bug 1323274 in kbd (Ubuntu) "Restore Debian's init.d script for insserv compatibility" [Low,Triaged] https://launchpad.net/bugs/1323274
<dholbach> good morning
<pitti> apachelogger, ScottK: well, I'll just do and take the bullets (it's just reverting that particular delta to Debian)
<TheMuso> greyback: happy to meet up with you out where the coffee break is held.
<greyback> TheMuso: ok, see you there
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach, infinity
<apachelogger> pitti: I'll only mind if you break something, that's my job :P
<pitti> apachelogger: hehe; yes, of course
<pitti> apachelogger: if it ever finishes building :)
<mterry> jjohansen1, is there a bug for those lxc test failures?
<jjohansen1> mterry: 1323528
<ogra_> xnox, where are you hiding ?
<jjohansen1> mterry: btw I am testing and will submit the fix for it soon
<mterry> jjohansen1, cool, thanks
<Shock> pitti: can you take a look at bug #1247584 and tell me if there's anything else I need to do or I can consider it done?
<ubottu> bug 1247584 in systemd (Ubuntu) "[keymap] Since upgrade to Ubuntu 13.10, udev doesn't map middle mouse button." [Undecided,Confirmed] https://launchpad.net/bugs/1247584
<pitti> Shock: hey! yes, I saw your response yesterday
<pitti> Shock: thanks for your patch!
<Shock> pitti: sure
<pitti> Shock: I probably won't get around it this week (sprint), but it's on my TODO list now
<pitti> Shock: so from your POV it's "done"
<Shock> pitti: cool, thanks
<xnox> ogra_: studio 8 at the moment
<xnox> (on the sunset strip)
<xnox> wgrant: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.utopic/touch.sources ~ 226 source packages
<ogra_> xnox, we need to talk if you are not in a meeting anymore
<wgrant> xnox: Plus core, I suppose?
<xnox> wgrant: yeah.
<wgrant> Right, vaguely manageable.
<xnox> wgrant: yeah, i would have thought some of kde ppas are bigger.
<wgrant> They're a bit of a problem, but yeah.
<cjwatson> doko: Would you mind having a look at the wxwidgets3.0/arm64 build failure?  ICE, I'm seeing something that looks similar in redeclipse/arm64, but am in meetings and haven't had a chance to investigate properly yet
<cjwatson> xnox,wgrant: touch inherits from sdk-libs, so I think you need to count that too
<pitti> xnox: could you put a quick look at http://paste.ubuntu.com/7527535/ ?
<cjwatson> little things like qtbase there
<pitti> xnox: in particular, for the "shim" nfs-common upstart job I supposed I should add a "stop on" for maybe runlevels 0 and 6?
<cjwatson> So more like ~600 ...
<pitti> xnox: stop on runlevel [016] ?
<xnox> pitti: no, no stop on needed.
<xnox> pitti: let me double check.
<xnox> pitti: actually it should be "stop on (stopped idmapd and stopped gssd and stopped statd)" no?
<wgrant> cjwatson: That'll be in the top 10, and might end up kicking me into making NMAF suck slightly less, but shouldn't be fatal. Thanks for the details.
<pitti> xnox: ah, I think an "or" in that case
<pitti> xnox: stop on (stopped idmapd or stopped gssd or stopped statd)
<cjwatson> wgrant: ok, sorry to accidentally blindside you
<pitti> xnox: cause if either is down, nfs-common is not "fully" running any more
<xnox> pitti: ack.
<cjwatson> wgrant: I think I tacitly assumed "will probably fit within default quota => not a problem"
<wgrant> It's number of packages rather than size of packages.
<wgrant> NMAF index generation is unbelievably terrible.
<xnox> pitti: i'm ok with that, and that's a good state approximation.
<pitti> xnox: ack, thanks; testing now
<cjwatson> wgrant: yeah, that's obvious now you say it
<cjwatson> hmm.  struggling to think of an alternative, all the same
<wgrant> Nah, it's easy to make it not suck.
<cjwatson> derived distros obviously wouldn't work, and I don't think we should be creating extra distroseries for vendor-specific RTM projects
<wgrant> But if you were looking at more than a couple of thousand packages I would have died :)
<cjwatson> yeah, I think it will be impractical to make the PPA build entirely standalone for that reason
<zyga> ara: my desktop died
<wgrant> Imight get bored on the plane and fix it.
<evfool> does anyone know about docs on how to do ubuntu online accounts integration?
<cjwatson> (i.e. full germinate-speak depends+build-depends closure)
<zyga> ara: I managed to log in to see a stream of kernel errors related to NMI and USB
<zyga> ara: I need to have a look at it, maybe the fan is stuck or something
<cjwatson> wgrant: benefit of living in .au, lots of plane time to get bored in?
<wgrant> I attempted it back in '09, but that was before anybody cared about performance, so it was never acceptable to people who could land it.
<wgrant> Indeed.
<seb128> evfool, try asking mardy maybe, he can probably point you to the right direction
<evfool> thanks seb128, I'll ask mardy
<mardy> evfool: hi! There aren't many docs at the moment, but I can hopefully help you :-)
<pitti> slangasek: do you have a minute to review http://paste.ubuntu.com/7527609/ ? that's a nontrivial (but not too complicated either) diff for nfs-utils
<mardy> evfool: do you want to add support for a new service, or are you developing an application?
<evfool> mardy: I have found an html5 tutorial
<pitti> slangasek: I tested it in a VM (upgrade, various start/stop), and it works fine here
<evfool> mady: would like to add uoa integration for an existing app
<evfool> mardy^
<mardy> evfool: OK. What application is it? Is it a HTML5 one?
<evfool> mardy: that would be straightforward based on the HTML5 tutorial, it's Vala, but C code would also help me
<evfool> mardy: just found your signong-glib-google-demo, trying to decipher it :)
<mardy> evfool: there's a patch for shotwell (it's written in Vala) to add support for Online Accounts
<mardy> evfool: you could do "apt-get source shotwell" to get it
<evfool> mardy: found it on launchpad already, in the deb folder, I assume 06_uoa.patch is the thing to look at ;)
<mardy> evfool: yep :-)
<evfool> mardy: thanks, I'll try some stuff, and will ping you if I get into trouble
<doko> cjwatson, arm64 recently has issues with precompiled headers, not reliably reproducible.  as a workaround build without pch. would like to wait until 4.9 is the default and see if this persists
<darkxst> dholbach, infinity while your piloting would be nice if you could look at the mega cleanup of g-s-d! seems no one else wants to!
<darkxst> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1318539
<ubottu> Launchpad bug 1318539 in gnome-settings-daemon (Ubuntu) "Vanilla gnome-settings-daemon 3.8" [Undecided,Confirmed]
<zyga> 4~/exit
<dholbach> darkxst, I'll have a look, but I could imagine that I won't know enough about it to make a good decision
<pete-woods> mardy: hi, I'm trying to add a SSO provider for vimeo
<pete-woods> but the process doesn't quite complete
<pete-woods> I have logging output from the signon-ui: https://pastebin.canonical.com/110741/
<pete-woods> it seems to get most of the way through the process
<pete-woods> but the https://wiki.ubuntu.com/?=&code=4ee3705aabf48607fb237a925f9fd68b4a0f2d7a URL looks a bit weird to me
<pete-woods> I can provide the provider / service files if that will help
<jamesh> jdstrand: hi.  Would you know how to debug why dbus on my laptop doesn't seem to be handling apparmor?
<mardy> pete-woods: hi! It's not clear from the logs what's happening; do you get to enter your username and password?
<mardy> pete-woods: yes please, so I can try here
<pete-woods> mardy: yes, I enter the credentials on the first page, it then does the usual "would you like to authorise this app" stuff
<pete-woods> mardy: but then when I click accept it dumps me out with no error
<mardy> pete-woods: it actually seems that the process completed successfully, I can see an authentication token in line 89
<jamesh> mardy: I passed on your debug tips to pete-woods.  It is handling the authorize workflow, but never converting the access code into a token
<cjwatson> doko: this one seems pretty reliable, FWIW ...
<doko> cjwatson, ok, will try a local build
<cjwatson> doko: I don't see a gcc option to disable precompiled headers - am I missing it?
<pitti> cjwatson: would you happen to know why this isn't in -proposed yet? it got uploaded yesterday: https://launchpad.net/ubuntu/+source/autopilot-gtk/1.4+14.10.20140526-0ubuntu1
<thomi> pitti: the langing hasn't completed yet
<pitti> it seems LP doesn't want to publish it?
<thomi> *landing
<pitti> thomi: oh wow, you can upload something to Ubuntu and then kind of hold it back in limbo somehow?
<thomi> pitti: check silo 19 on the SS
<thomi> pitti: it didn't get uploaded to ubuntu
<thomi> yet
<pitti> ah, so that LP page is just utterly confusing then
<thomi> hmmm, yeah, it's odd that LP shows it has been uploaded
<cjwatson> pitti: The build was 22 hours old, but it was only very recently copied to -proposed
<thomi> surely that doesn't include PPAs?
<cjwatson> pitti: https://launchpad.net/ubuntu/+source/autopilot-gtk/+publishinghistory makes it clearer
<cjwatson> thomi: Sure it does :)
<thomi> oh, ok, cool
<cjwatson> The buildd still has to upload builds for PPAs
<pitti> cjwatson: aah, that makes much more sense now; thanks!
<cjwatson> And indeed in this case it was uploaded by the jenkins bot
<mardy> jamesh, pete-woods: the token is there, but somehow after receiving it, the authentication plugin gets an error serverReply : "{"error":"application/vnd.vimeo.auth"}"
<cjwatson> You have to get the source into LP somehow at some point
<jdstrand> jamesh: I am going to point you at tyhicks
<cjwatson> Though you can then copy it around as much as you like later
<pitti> cjwatson: yeah, I was confused by "uploaded by ps-jenkins bot 22 hours ago"
<cjwatson> Right, that was the original source upload to the PPA
<cjwatson> But yeah, I tend to reach for +publishinghistory pretty quickly
<cjwatson> Since that's comprehensible :)
<jdstrand> jamesh: though, I'm curious what you mean by 'handling apparmor'
<jamesh> jdstrand: I'm getting errors when trying to execute org.freedesktop.DBus.GetConnectionAppArmorSecurityContext
<jdstrand> jamesh: is this on utopic or trusty?
<jamesh> e.g. "dbus-send --session --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionAppArmorSecurityContext string::1.1" returns an error
<jamesh> jdstrand: utopic.
<jdstrand> jamesh: and you said on desktop?
<jamesh> that command returns "unconfined" on my phone hardware, and an error on desktop
<jdstrand> actually, I don't think tyhicks is needed after all
<sarnold> how up-to-date is your utopic desktop? apparmor hasn't been adapted to the changes in the new 3.15.x kernel yet
<jdstrand> jamesh: the utopic desktop kernel does not yet have all the apparmor patches (it has what is upstream, not the additional stuff we are in the process of upstreaming)
<jamesh> ahh.
<jamesh> and the phone has a completely different kernel
<jdstrand> jamesh: that coming. if you boot a trusty kernel, that should unblock you
<jdstrand> jamesh: yes
<jdstrand> s/that/that is/
<jamesh> thank you.
<jamesh> jdstrand: fyi: we should have the mediascanner QML bindings going through D-Bus shortly.  I'm now working on adding the apparmor hooks to it
<jamesh> the next step is to get every client of the mediascanner going through d-bus
<jdstrand> jamesh: nice! that sounds great :)
<jamesh> jdstrand: I'm a little concerned about encoding security policy directly into the daemon though (in particular, making decisions for particular security context labels)
<jdstrand> jamesh: that is a workaround until there is trusted session support
<jamesh> okay
<jdstrand> jamesh: in mir. that isn't intended to be there forever. we don't now have a way to prompt the user if the access is ok (ie, you can't use trust-store) and we don't want to break the music-app, so we just do this
<jdstrand> it is icky, but temporary
<doko> cjwatson, it should be in the packaging. configure.in: bk_use_pch=no
<doko> but I'll try to reproduce it first
<jamesh> jdstrand: I was thinking more about the way media-hub encodes knowledge that an app has access to ~/.local/share/$package and ~/.cache/$package
<jamesh> which presumably wouldn't invoke a trust-store dialog
<jdstrand> let me look at the code real quick
<slangasek> pitti: hmm, so, nfs-utils is a mess.  Are you readding the nfs-common init script because something depends on it?
<pitti> slangasek: yes
<xnox> slangasek: yeah.
<slangasek> pitti: because we need to split this init script for proper systemd integration too, so I'd greatly prefer to move the other direction
<slangasek> ah, what depends on it?
 * pitti tries to find the pastebin again, hang on
<xnox> slangasek: but pitti only created a dummy upstart job (ala mountall.sh)
<slangasek> right
<slangasek> but IIRC, idmapd may not always start?
<slangasek> ditto statd
<xnox> slangasek: should it be just or'ed ?
<pitti> utopic/etc/init.d/umountnfs.sh:# Should-Stop:       $network $portmap nfs-common
<pitti> utopic/etc/init.d/nfs-kernel-server:# Required-Start:    $remote_fs nfs-common $portmap $time
<pitti> utopic/etc/init.d/nfs-kernel-server:# Required-Stop:     $remote_fs nfs-common $portmap $time
<pitti> slangasek: ^
<slangasek> ah, nfs-kernel-server, hah
<xnox> slangasek: (sure the dependnecy will fire earlier then.....)
<slangasek> so we at least could fix that in one place ;)
<pitti> slangasek: so, not that much, but these could still creep in with syncs/merges from other packages, so I thought it'd be cleaner to keep Debian's and shadow it
<cjwatson> doko: oh, you meant turn off pch in the gcc build, I thought you meant turn it off in the wxwidgets3.0 build
<slangasek> pitti: right, but as nfs-utils comaintainer ;P, I'm planning to move this in the other direction in Debian
<jdstrand> jamesh: ok, right. the point of media-hub and mediascanner is that they are trusted helpers. they are purposefully there to enforce access controls beyond the static apparmor policy. since media-hub and mediascanner2 allow access to other files, they need to be careful about how they do so
<pitti> slangasek: other direction sounds even better, of course
<jamesh> jdstrand: http://bazaar.launchpad.net/~phablet-team/media-hub/trunk/view/head:/src/core/media/player_skeleton.cpp#L153 <- that's the code
<pitti> slangasek: do you plan to do that "soon", or can/should we use this to unblock the insserv transition (it
<pitti> 's the last affected package)
<slangasek> pitti: I was certainly planning on doing it "soon", and think it would be easier if we didn't then have to unpick another Ubuntu-specific upstart job in the process
<jamesh> jdstrand: It just seems a bit weird to be repeating these parts of the security policy in each daemon (determining package names based on apparmor contexts, what files those contexts automatically have access to, etc)
<jdstrand> jamesh: every trusted helper will be a little different. some, like location service, won't need to have more logic because they don't give out more access
<jamesh> because if we change details of the policy, we'd need to go through each of these services and update it
<jdstrand> jamesh: most trusted helpers don't have to do this
<jamesh> okay
<jdstrand> jamesh: and we don't expect the paths to change, cause the specification is using standard XDG directories
<pitti> slangasek: so the other option which wouldn't introduce blocking right now is to drop that shim upstart job and just drop the dependency in nfs-kernel-server?
<slangasek> pitti, xnox: anyway, I'm not exactly sure which of the components of nfs-common is a prereq for nfs-kernel-server, but each of these is possibly not going to start on boot and could block
<slangasek> pitti: I wouldn't want to just drop the dep either
<pitti> slangasek: ATM we only have an init.d for nfs-kernel-server and upstart jobs for nfs-"common"; how is that dependency being enforced right now?
<doko> cjwatson, no, turn it off in the wxwidgets build
<slangasek> pitti: because the nfs-kernel-server init script starts in runlevel 2 and the upstart jobs 'start on local-filesystems'.  If you have both nfs mounts and nfs-kernel-server there's guaranteed ordering, if you don't have nfs mounts there's a race but nfs-common has a head start
<pitti> slangasek: ah, ok; so isn't that the same with changing nfs-kernel-server to either drop the nfs-common dep or drop it to should-start?
<pitti> slangasek: (to avoid having to clean up nfs-common.conf later on after you do the split)
<cjwatson> doko: oh, ok.  let me know if you want me to upload that then
<cjwatson> (--disable-precomp-headers apparently)
<slangasek> pitti: as long as you're on upstart, yes; will do the wrong thing on systemd, but that's a deeper problem which I suppose we can deal with a little bit later
<pitti> slangasek: *nod*
<slangasek> hmm, so did you already upload this?
<pitti> slangasek: yes, but with block-proposed, so easy to change
<slangasek> mmk
<pitti> slangasek: so the total delta to what's currently in utopic would just be th drop the LSB header dep of kernel-server
<pitti> s/th/to/
<pitti> thomi: "Jenkins Fixed - utopic-adt-autopilot-gtk 13" \o/
<slangasek> pitti: makes sense
<thomi> pitti: virtual high-five!   o/
<pitti> slangasek: ack
<pitti> thomi: ^5s
<thomi> :-/
<pitti> thomi: I think that warrants a :-)
<thomi> ...
<mterry__> ogra_, any objections if I make /var/lib/lightdm (the greeter user's HOME dir) persistent?
<mterry__> ogra_, in touch
<ogra_> is there much stuff in it ... ?
<ogra_> mterry__, (also do we need to wipe it for factory reset ? if so, please tell sergiusens )
<mterry__> ogra_, just some typical cruft from being a user (some junk in .cache/.config)
<mterry__> ogra_, for factory reset...  hmm  I guess -- I had assumed we just wipe disk and reinstall base system image?
<xnox> stgraber: how does system image update
<xnox> stgraber: does shutdown?
<xnox> (reboot)
<doko> cjwatson, please do. is not reproducible, and segfaults on a different file each time
<GunnarHj> Hi pitti
<pitti> hey GunnarHj
<GunnarHj> pitti: Did you see this:
<brendand> anyone come across this error before? dpkg-source: error: cannot represent change to trunk/.bzr/repository/packs/9245e3e3055bac62bf0c407a72389cbc.pack: binary file contents changed
<GunnarHj> https://lists.ubuntu.com/archives/ubuntu-translators/2014-May/006512.html
<brendand> why does debuild care about what's in .bzr?
<cjwatson> use the exclude option
<cjwatson> debuild -S -i -I
<stgraber> or call bzr bd if it's that kind of branch
<cjwatson> $ grep BUILDPACKAGE .devscripts
<cjwatson> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I -uc -us"
<cjwatson> or that yeah
<Wellark> doko: which room are you in?
<Wellark> there is something weird going on with gcc -dbg package dependencies
<jamesh> jdstrand: thanks for your help.  I've got an MP for mediascanner here: https://code.launchpad.net/~jamesh/mediascanner2/dbus-apparmor/+merge/221058
<dholbach> hey seb128 - I'm sure you're busy sprinting, but do you think somebody could take a look at https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1318539? attente seems to have ACKed it already, but I personally can't judge if it should be uploaded or not
<ubottu> Launchpad bug 1318539 in gnome-settings-daemon (Ubuntu) "Vanilla gnome-settings-daemon 3.8" [Undecided,Confirmed]
<seb128> dholbach, go for it
<seb128> dholbach, it's basically up to the GNOME remix team and it has been acked by attente
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<seb128> +1 on the principle from me, but I didn't do a detailed review
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> seb128, we could probably take a look and see what still depends on gnome-settings-daemon
<dholbach> seb128, I had to "dpkg -P gnome-settings-daemon gnome-packagekit-session gnome-session ubuntu-system-settings gnome-control-center gnome-packagekit ubuntu-system-settings-online-accounts  account-plugin-ubuntuone  unity-scope-click" - I probably still had it installed from some older installation
<ScottK> pitti: That's fine, the only thing is to please commit the changes to our bzr repo.
<ScottK> (didn't check if you did already)
<mterry__>  sergiusens, talk to me about factory reset when you get a chance
<mterry__> sergiusens, on the phone
<sergiusens> mterry__: sure, just come by 2c... I have only one meeting today; everything else is adhoc
<seb128> dholbach, sorry, I got disconnected, not sure you got my reply (guess so from your upload)
<pitti> ScottK: ah, will do
<ScottK> pitti: Thanks.
<xnox> slangasek: nexus 5 works
<xnox> slangasek: bregma is not online =)
<pitti> infinity: argh, I just noticed that I didn't bump the copy limits of eglibc, which explains the timeouts
<infinity> pitti: Meh, it'll be "fixed" after I merge from Debian anyway.
<pitti> infinity: while I'm at it, if I give the VM 4 CPUs, does the build make use of that?
<infinity> pitti: Yeahp, the build will happily eat more cored.
<infinity> pitti: cores, too.
<pitti> infinity: ack, config pushed (with 4 cores)
<pitti> infinity: current build cancelled and restarted, I think/hope it'll succeed now
<pitti> argh, I thought we already had an override; for that it held up surprisingly well..
<pitti> ... or I would if jenkins wouldn't be nasty again
<mardy> pete-woods: hi! According to https://developer.vimeo.com/api/authentication, it should be possible to find the authorization header on the application webpage
<mardy> pete-woods: could you please tell me the code? I'm generating it according to the instructions, but vimeo stills gives me an error, so maybe I'm doing it wrong
<Mirv> hmm, I'm getting chroot error on amd64, i386 and ppc64el builders: https://launchpadlibrarian.net/176409150/buildlog_ubuntu-utopic-amd64.qtbase-opensource-src_5.3.0%2Bdfsg-2ubuntu1~utopic1~test1_CHROOTWAIT.txt.gz
<jamesh> jdstrand: the d-bus AppArmor stuff doesn't seem to work in Jenkins builds.  Do you have any suggestions on how to handle that?
<jamesh> jdstrand: allowing everything when the AA check fails would work, but sounds like something that could be used in an exploit.
<sarnold> jamesh: are they perhaps using the 3.15-ish kernels?
<jamesh> sarnold: I don't know.
<jamesh> IIRC, it runs the tests in a chroot so I don't know what the host system is
<shadeslayer> pitti: re autopkgtests , what happens if a autopkgtest fails? Does it block package migration from proposed to release?
<tyhicks> jamesh: can you give me more detail on why you think dbus mediation isn't working with jenkins?
<pitti> shadeslayer: if it ever succeeded, i. e. it's a regression, then yes
<shadeslayer> aha
<pitti> shadeslayer: if it always failed, we consider the test broken and ignore it
<shadeslayer> cool, thanks
<GunnarHj> pitti: Did you forget about the link I posted?
<shadeslayer> pitti: and just so I understand correctly, autopkg tests are run separately from the actual build on launchpad correct?
<pitti> shadeslayer: yes
<shadeslayer> ack, thanks
<pitti> GunnarHj: sorry, probably drowned (sprint/discussions here)
<GunnarHj> pitti: https://lists.ubuntu.com/archives/ubuntu-translators/2014-May/006512.html
<pitti> GunnarHj: yep, got your mail, just didn't find time to respond yet
<GunnarHj> pitti: Ok.
<GunnarHj> pitti: One thing I wonder about is who is supposed to initiate translation updates. I haven't found any schedule for when things are copied to -proposed for testing.
<jamesh> tyhicks: https://jenkins.qa.ubuntu.com/job/mediascanner2-utopic-amd64-ci/19/consoleFull <- right at the bottom one of the erros is "Error getting apparmor context: org.freedesktop.DBus.Error.AppArmorSecurityContextUnknown: Could not determine security context for ':1.1'"
<pitti> GunnarHj: there's nobody right now; it used to be dpm, but he works on other stuff now
<GunnarHj> pitti: Just as I feared, then.
<jamesh> tyhicks: which is the error I was getting locally with the Utopic kernel (I reverted locally to the trusty kernel at jdstrand's suggestion)
<infinity> xnox: Where are you?
<shadeslayer> looks like something went kaput https://launchpad.net/ubuntu/+source/kde4libs/4:4.13.0-0ubuntu4
<infinity> xnox: Making everything in the archive have a versioned upstart dependency seems like exactly the opposite of what we want.
<shadeslayer> seems like what I'm facing ^^
<infinity> shadeslayer: Oh, fun.
<stgraber> xnox: thanks for breaking the archive
<tyhicks> jamesh: I suspect that securityfs is not mounted (or bind mounted) in the chroot
<tyhicks> jamesh: the apparmor dbus mediation sees that and can't determine if it should enforce rules so, by default, it disables the apparmor checks
<tyhicks> (there is an option in the bus config file to not fall open like that, but that's not the issue here...)
<tyhicks> jamesh: the only issue is when you're asking for the apparmor confinement context of a given connection
<tyhicks> jamesh: IMO, it is currently doing the right thing by returning a DBUS_ERROR_APPARMOR_SECURITY_CONTEXT_UNKNOWN error
<tyhicks> jamesh: I think the best fix here would be to get securityfs mounted in the chroot
<xnox> infinity: sorry........... =)
<tyhicks> jamesh: but... it is completely possible that the jenkins kernel is the 3.15 utopic kernel that doesn't have the necessary apparmor patches
<tyhicks> jamesh: I just don't know enough about that environment or how to find more info on it
<jamesh> tyhicks: okay, I'll try following up there.  Thanks for the help.
<jjohansen1> tyhicks, jamesh: the 3.15 utopic kernel is missing the necessary patches, that will be fixed soon
<pitti> xnox: oh, you still want to block sysvinit? kde-workspace went in
<dpm> GunnarHj, pitti, exactly. A community member used to help creating the schedule in later times, but he got busy with other stuff too. Here's an example of the release schedule we set up for releases a while ago: https://wiki.ubuntu.com/Translations/NattyLanguagePackReleaseSchedule
<GunnarHj> dpm, pitti: Thanks, that's exactly what I had in mind. Would you recommend that we basically copy it for trusty?
<pitti> infinity: https://launchpad.net/ubuntu/utopic/+source/systemd/204-10ubuntu5 -> "Broke the world from the new upstart dependency" ?
<pitti> infinity: do you have some details on that? I've run this for 2 days now
<pitti> or did that interact badly with the dh_installinit upload or something?
<infinity> pitti: See the build log for https://launchpad.net/ubuntu/+source/kde4libs/4:4.13.0-0ubuntu4 for instance.
<rbasak> What do people use to get the source package name of a binary package? chdist bin2src is crashing on me.
<infinity> pitti: Dep loop that triggered an apt bug.
<infinity> pitti: But, apt bug notwithstanding, having everything with an upstart job have a dep on upstart is just plain wrong.
<infinity> pitti: So, we're moving that lsb init snippet to lsb-base, and moving the dep there instead.
<pitti> infinity: ah, perhaps we could turn this into a Breaks: upstart (<<)
<infinity> pitti: And rebuilding everything with the upstart dep.
<infinity> pitti: We thought about a breaks, but can't quite sort out WHAT would break upstart.
<pitti> infinity: ah, even better
<pitti> infinity: with breaks: we'd need sourceful changes, so depends: indeed would be better
<pitti> infinity: are xnox and you already at it? anything I should do now?
<infinity> pitti: stgraber and I are on it.
<infinity> pitti: How did you notice the systemd deletion, BTW? :P
<infinity> pitti: Oh, I guess you nogticed me copying in the old one.
<pitti> infinity: I got a "released to utopic" mail for ubuntu4, and wondered where ubuntu5 went to
<diwic> hmm, I thought we were all going to ditch upstart for systemd but now it seems things are going the other way around...
<pitti> diwic: how so?
<pitti> diwic: it's just a rather long dependency chain
<diwic> pitti, you were adding empty upstart scripts and infinity talks about systemd deletion? :-)
<pitti> diwic: fixing our packages to comply to Debian init.d/upstart/systemd policy â moving from legacy init.d ordering to insserv â merging sysvinit â adding systemd equivalents to upstart jobs
<pitti> diwic: ah, I didn't see the implied :)
<pitti> it's kind of weird that we have to fix sysvinit first, but overall that's the path of least resistance/work/delta to Debian
<pitti> (in fact it's mostly "remove some Ubuntu delta")
<diwic> pitti, okay, looks like you have it all under control then ;-)
<pitti> kind of, except for details like breaking all builds (thanks infinity for quick action!)
<pitti> diwic: so, let's say we know the path now :)
<diwic> pitti, all right then :)
<pitti> infinity: I suppose we can retry https://launchpad.net/ubuntu/+source/debhelper/9.20140228ubuntu3/+build/6045112 now :)
<shadeslayer> so is the brokenness fixed now?
<pitti> shadeslayer: AFAICS, yes
<pitti> udev | 204-10ubuntu4   | utopic          | amd64, arm64, armhf, i386, powerpc, ppc64el
<pitti> and nothing in -proposed
<shadeslayer> hm
<pitti> i. e. the apt dependency loop should be gone
<pitti> and debhelper is happily installing its build deps now
<shadeslayer> rebuilding kdelibs, lets see
<shadeslayer> because it doesn't work locally
<pitti> shadeslayer: wait
<shadeslayer> oh
<pitti> https://launchpadlibrarian.net/176413792/buildlog_ubuntu-utopic-i386.debhelper_9.20140228ubuntu3_CHROOTWAIT.txt.gz still failed, hmm
<shadeslayer> pitti: http://paste.ubuntu.com/7529745/
<dpm> GunnarHj, sorry for the delay. I'd say yes, but let me find you a more recent template than the one for natty
<pitti> Unpacking udev (204-10ubuntu5) over (204-10ubuntu1) ...
<pitti> shadeslayer: ^ your build log still has the ubuntu5 version which infinity removed
<shadeslayer> pitti: yeah, trying to figure out why
<pitti> shadeslayer: probably just mirror lag; the LP buildds use ftpmaster.internal
<shadeslayer> yeah
<shadeslayer> pitti: https://launchpadlibrarian.net/176413830/buildlog_ubuntu-utopic-amd64.kde4libs_4%3A4.13.0-0ubuntu4_CHROOTWAIT.txt.gz  < plymouth issue
<pitti> yes, same as debhelper
<shadeslayer> yep
<dpm> GunnarHj, here's the raring one: https://wiki.ubuntu.com/Translations/RaringRingtail/ReleaseSchedule
<GunnarHj> dpm: It says raring in the URL, but it's actually precise. ;)
<pitti> probably this:
<pitti>  initscripts depends on upstart (>= 1.12.1-0ubuntu6); however:
<pitti>   Package upstart is not configured yet.
<dpm> GunnarHj, I guess it was copied from Precise and we never actually used that one :)
<pitti> thus we need to rebuild the latest sysvinit upload against the reverted debhelper, and need the rebuilt sysvinit to build debhelper; yay loops
<GunnarHj> dpm: I see. So there hasn't been any systematic translation updates since 12.04?
<dpm> GunnarHj, most probably no. I know we've done some updates, but as you're saying, not systematically
<GunnarHj> dpm: Ok. Anyway, thanks for the link. I'll make a proposal for trusty based on it.
<dpm> GunnarHj, sounds great, thanks!
<shadeslayer> pitti: hah :D
<xnox> pitti: sysvinit must depend on new upstart though....
<xnox> pitti: if that's bad, we'd need to move the hook elsewhere.
<xnox> pitti: sysvinit is currently blocked from migrating.
<pitti> xnox: the hook is being moved to lsb-base AFAIUI
<pitti> xnox: hm, it did migrate already
<pitti> I can't reproduce the upgrade failure in a schroot
<Elv1313> I got this while accessing errors.ubuntu.com for a little while http://pastebin.com/2s4ud5rk as an error message, it look as a hack, might not be the brightest idea ever
<xnox> pitti: ok, i hread that mentioned, but it was not definitive at the time, i don't think.
<xnox> slangasek: infinity: stgraber: what's the current plan for unbreaking & steps that we need to do to land insserv?
<xnox> pitti: cause e.g. adding in sysv-rc breaks upstart << (version with hook) was also offered.
<xnox> which shouldn't have any side-effects if upstart is not installed to begin with, and triggers the update otherwise.
<pitti> infinity, stgraber, xnox: so I'm trying to understand the current failure, did you already reproduce this somehow?
<pitti> [-upstart,-] {+upstart (>= 1.12.1-0ubuntu6),+}
<pitti> I figure it's somehow related to this change initscripts, but I don't understand why
<xnox> pitti: that's manual change in the debdiff.
<infinity> pitti: It's actually probably the sysv-rc/initscripts loop, I'm doing some reversions.
<infinity> xnox: stgraber and I are sorting this out.
<xnox> infinity: ok. thanks.
<xnox> pitti: let's wait for inifinity & stgraber to unwind this =)
<mdeslaur> infinity, pitti, stgraber, slangasek: are we still having a tech board meeting in an hour?
<pitti> mdeslaur: yes, I think so; we can have it IRL, maybe at the nice patio in front of the coffee area?
<mdeslaur> pitti: sounds good to me
<Laney> is the whole tb here?
<pitti> infinity: wow, I didn't know we could do this now (revert ubuntu13 to ubuntu12 in the release)
<pitti> Laney: yes
<pitti> mdeslaur: and I expect today's meeting to be < 15 mins :)
<infinity> pitti: We can't.  You didn't see anything.
<pitti> infinity: /me performs self-lobotomy
<infinity> pitti: Good job.
<infinity> xnox: Was there a reason you decided sysv-rc needed a dep on initscripts?
<infinity> xnox: Before I tear that right out again? :P
<xnox> infinity: yes, cause insserv in sysv-rc may not be enabled without the update initscripts.
<xnox> infinity: initsctipts & sysv-rc can instead both break "upstart (<< magic-version number)" (the version that first introduced the hook)
<infinity> xnox: Well, that introduces a dep loop, so won't do what you wanted even if it worked.
<xnox> infinity: would the two breaks do what I want?
<infinity> xnox: initscripts will depend on the lsb-base where we moved the hook.
<xnox> infinity: ok, that works fine then.
<infinity> xnox: But what does sysv-rc have to do with it?
<xnox> infinity: that mean that initscripts can be upgraded independant of sysv-rc.
<pitti> so breaks: then?
<infinity> xnox: Right, so sysv-rc breaks initscripts << foo.
<infinity> I'll give that a spin.
<xnox> infinity: yes.
<xnox> (which should result in the same desired final outcome)
<xnox> cyphermox: can you take this patch into urfkill http://paste.ubuntu.com/7529928/ ? to potentially remove two races.
<cyphermox> xnox: sure
<cyphermox> xnox: where did you see these issues?
<xnox> cyphermox: this is by inspection, not from real problem.
<cyphermox> ok
<xnox> cyphermox: awe_ and I were inspecting things trying to find a race, and these are two minor but potential issues.
<cyphermox> well, I have them applied here, will include in the next upload
<xnox> cyphermox: tah.
<zbenjamin> sarnold: any luck yet? :)
<cyphermox> I'm testing some other fixes that could correct races
<cyphermox> xnox: awe_ should know, I have a package ready to test in my PPA
<sarnold> zbenjamin: no, sorry :)
<zbenjamin> sarnold: ok thx
<zbenjamin> sarnold: would it be different if i would ship gdbserver inside the click package? Or would the ptrace still fail?
<zbenjamin> sarnold: not that i want to do that because with fat packages it would be a mess. But would be interesting to know
<sarnold> zbenjamin: the ptrace operations should still fail, yeah
<sarnold> zbenjamin: probably the 'right' approach would be to create a new child profile for gdb or gdbserver. it might be worth going down that road a little bit to see what's required inside the child profile.
<sarnold> zbenjamin: http://wiki.apparmor.net/index.php/QuickProfileLanguage#Child_profiles
<zbenjamin> sarnold: that means gdbserver would run unconfined but the click app would not?
<sarnold> zbenjamin: well, I got to thinking that perhaps the gdbserver Ux, might actually run the whole thing unconfined.
<zbenjamin> ok that would make the whole effort pointless
<sarnold> yeah
<sarnold> zbenjamin: creating a child profile for gdbserver would let us keep it in a profile and keep the 'main' profile clean -- if we added the needed privileges right to the profile, the program may not behave the same when the debug group is added
<zbenjamin> sarnold: true, that sounds good to me.
<rbasak> What do people use to get the source package name of a binary package? chdist bin2src is crashing on me.
<rbasak> (before I go and write my own grep-dctrl wrapper...)
<xnox> rbasak: is it crashing because source has been removed.... ?!
<rbasak> xnox: I just filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749504
<ubottu> Debian bug 749504 in devscripts "[chdist] bin2src fails with "chdist: bad apt-cache : 13"" [Normal,Open]
<xnox> rbasak: such package does not exist in debian?! $ rmadison -S apache2-bin -u debian
<xnox> rbasak: however, it exists in at least saucy, trusty and utopic.
<sarnold> rbasak: I've got an 'lpsrc' shell function: apt-cache showsrc "$*" | grep --color=auto '^Binary: ' | sed -e 's/Binary: //' -e 's/ //g' -e 's/,/\n/g' | sort -u
<sarnold> rbasak: it's far from perfect but I can usually spot the source pcakage I need with it..
<infinity> xnox: Eh?  It's a binary package.
<infinity> xnox: You might be rmadisoning incorrectly. :P
<xnox> infinity: oh, rmadisoning against ubuntu and debian is different. =)))) on ubuntu -S is like a modifier (iff source, also print all binaries). Cause against ubuntu "rmadison libc6" & "rmadison -S libc6" for example return the same thing.
<infinity> xnox: That would be a bug in the Ubuntu madison.cgi
<xnox> infinity: =(
<pitti> slangasek, infinity, kees, mdeslaur, stgraber: reminder that TB meeting is in #ubuntu-meeting-2 (collision with server meeting in #u-m)
<stgraber> pitti: oh, is that going to be happening every week? we probably should have considered that when doing the doodle :)
<pitti> stgraber: well, we already had few enough options without considering meeting channel colissions :)
<sarnold> pitti: mdeslaur may have taken the physical meeting suuggestion literally :)
<ogra_> slangasek, bug 1323732 for you
<ubottu> bug 1323732 in adduser (Ubuntu) "adduser should support managing additional password/shadow/group files from libnss-extrausers" [High,New] https://launchpad.net/bugs/1323732
<sarnold> mdeslaur: #ubuntu-meeting-2
<mdeslaur> sarnold: thanks!
<jdstrand> jamesh: hey, so I got the MR, I'll look at it when I have a moment
<jamesh> jdstrand: thanks.
<jdstrand> jamesh: I did want to mention that I was thinking about your question about the policy in the trusted helper, and I remembered that we are introducing the apparmor query interface
<jamesh> jdstrand: in case I have more questions, which room are you in this week?
<jdstrand> jamesh: we have a bit of it now, but when it is done, we will have libapparmor api such that you can ask 'hey can this process running under this profile access this file?"
<jdstrand> jamesh: once we have that, we can clean up mediascanner and media-hub. however, that isn't going to be fixed super soon
<jdstrand> jamesh: just fyi
<jdstrand> jamesh: I am in 2C when I am not in meeting
<jamesh> jdstrand: sounds good.
<jdstrand> meetings
<tyhicks> jamesh: fyi, I'm in 2C this week, too
<mhall119> slangasek: ping
<ogra_> hallyn, we see a new cgmanager crash during image tests ... http://ci.ubuntu.com/smokeng/utopic/touch/mako/50:20140527:20140523/8241/click_image_tests/ (scroll to the bottom)
<hallyn> "pass rate 100%"  /me doens't know how to interpret that
<slangasek> mhall119: hi
<hallyn> oh that one
<ogra_> hallyn, well, the test itself passes but alongside that .crash file appears
<mhall119> slangasek: hey, every track but Platform Dev has at lest one non-Canonical track lead, do you have any recommendations for who in the community (Ubuntu's or Debian's) would be a good candidate for that?
<mhall119> I'd very much like to get more community participation in the call for and scheduling of sessions
<hallyn> ogra_: there is a new version in utopic-proposed.  i'm hoping that''ll fix that (though no guaarentees)
<hallyn> it looks like genuine stack corruption...  hm
<hallyn> ogra_: can you run a set of tests with the -proposed version?
<slangasek> mhall119: what's "platform dev"?
<hallyn> (I assume this is not 100% reliably failing, so it wouldnt guarantee anything, but...)
<ogra_> hallyn, well, we'll just wait til it lands then
<slangasek> mhall119: has the core track been renamed, or is this something else?
<ogra_> hallyn, our nightly automated image build will pick it up anyway
<hallyn> ogra_: ok, thanks  (i also need ot sru that to trusty today, though it'll be a tough one to write a testcase for :)
<ogra_> :)
<ogra_> hallyn, oh, does that also include the fix for mterry__ ?
<mhall119> slangasek: it's a combination of foundations, client and server tracks
<hallyn> ogra_: yeah that's his in fact
<ogra_> yay, thats grat
<ogra_> *great too :)
<mhall119> slangasek: so basically everything from past vUDS except community and appdev is now "Platform Development"
<hallyn> i have a feeling there's another bug which may be responsible for yours - i'm guessing similar to the one mterry__ fixed
<hallyn> i.e. due to my mis-use of nih
<ogra_> heh, k ... we'll see
<slangasek> mhall119: hmm. and where can I see a list of the other tracks (to understand who from the community might relevantly fit under this umbrella, vs. being on a different track)?
<mhall119> slangasek: http://summit.ubuntu.com/uos-1406/tracks
<mterry__> hallyn, we need lxc/kernel fixes to unblock cgmanager  :(
<mhall119> slangasek: anything that's historically  been considered "Ubuntu development" would fall under this track
<hallyn> mterry__: hm?
<hallyn> why would cgmanager be blocked on lxc?
<mterry__> hallyn, cgmanager has been in the proposed queue for days
<slangasek> mhall119: ok; off the top of my head, maybe ScottK?
<hallyn> mterry__: exactly waht is it blocked on?
<mterry__> hallyn, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<mterry__> hallyn, lxc's autopkgtest fails
<mterry__> hallyn, due to some kernel issues
<mhall119> ScottK: would you be interested in being a track lead for Platform Development in the next UDS? It'll be June 10-12, but your main responsibility would be in asking people to propose sessions and getting them approved & scheduled
<hallyn> hm there's an open bug for that right?  i guess that should move to the top of my queue then
<ogra_> ++
<mterry__> hallyn, ogra_, bug 1323528
<ubottu> bug 1323528 in linux (Ubuntu Utopic) "apparmor3 patches not available on 3.15 kernel" [Undecided,In progress] https://launchpad.net/bugs/1323528
<mterry__> hallyn, ogra_, additionally there was a needed lxc update (but that's sitting in proposed too)
<hallyn> mterry__: d'oh.  ok i can't do anything about that one
<mterry__> hallyn, yeah  :(  me neither
<hallyn> back to packaging netcf then - thanks, ttyl
<ogra_> mterry__, you actually can ... pay beers to the kernel team till they agree on fixing it asap
<ogra_> beer always works
<ogra_> at least on them
<mterry__> :)
<brendand> ogra_, just remember to do it during happy hour :)
<ScottK> mhall119: Sorry. No time in the near term for something like that.
<mhall119> ScottK: even just recruiting sessions and approving them?
<mhall119> ScottK: anybody else from the Kubuntu devs you think would be good for me to ask?
<ScottK> Kubuntu has already had its planning session for the cycle.
<ScottK> I think the only thing we really care about is getting moving on Qt5 5.3.
<ScottK> mhall119: Even that. I expect to be offline more than on between now and then.
<mhall119> ScottK: how about presentation-style sessions like how to get involved
<ScottK> Ask Riddell.
#ubuntu-devel 2014-05-28
<Chipmadness> anyone here?
<xnox> pitti: adt tests are feeling sad, it seems.
<pitti> xnox: morning
<xnox> pitti: insserv: warning: script 'S02autopkgtest' missing LSB tags and overrides
<xnox> insserv: Service udev has to be enabled to start service nut-server
<xnox> insserv: exiting now
<xnox>  =))))
<xnox> pitti: morning. =) where is autopkgtest init script comming from?! =)
<pitti> xnox: yep, just saw; looking at mdadm now (breaking udisks2)
<xnox> pitti: i guess autopkgtest is in $ debcheckout -a ?!
<pitti> xnox: that's from adt-virt-qemu
<xnox> oh, ok.
<pitti> xnox: on my list, but the warning is less urgent
<pitti> xnox: nut's autopkgtest show unhappyness with udev's
<pitti> insserv: Service udev has to be enabled to start service nut-server
<pitti> xnox: so I suppose we are missing some corresponding update-rc.d calls?
<pitti> xnox: or rather, we need to fix bug 1312836 in debhelper and rebuild the packages
<ubottu> bug 1312836 in sysvinit (Ubuntu) "[systemd] dh_installinit does not create /etc/rc*.d/S??foo if there is an /etc/init/foo.conf" [Undecided,In progress] https://launchpad.net/bugs/1312836
<xnox> pitti: true.
<pitti> xnox: ah, mdadm-raid is also just from udev.init (Provides:)
<dholbach> good morning
<dholbach> larsu, HAPPY BIRTHDAY! :-)
<xnox> pitti: ok. let me upload debhelper, and then we'd rebuild systemd, check postinst is sane (and calls update-rc.d) and depends on the right version lsb-base.
<pitti> xnox: so we already call dh_installinit -R --no-start
<pitti> xnox: in theory that ought to craete an /etc/rcS.d/Snnudev, but it seems it doesn't; that's exactly this bug, right?
<xnox> pitti: it doesn't, because of above bug, yes. Uploading now.
<pitti> xnox: right, just cross-checking that I'm understanding this right
<xnox> pitti: not bug, but intentional change in debhelper.... but yeah, now it became a bug.
<pitti> xnox: I'm building systemd now with the change reverted locally
<TheMuso> c
<pitti> xnox: FYI, I added block-proposed again; even if we fix it for udev and the few others which are spotted by autopkgtests, we probably still need to rebuild a few other packages
<xnox> pitti: ack.
<xnox> rebuilding systemd.... slowly.....
<pitti> xnox: my first attempt was broken, I forgot to change postinst-init-norestart too
<pitti> now I changed them all, like in https://patches.ubuntu.com/d/debhelper/debhelper_9.20140228ubuntu2.patch
<pitti> mvo: halp
<mvo> pitti: holp!
<pitti> mvo: what was the magic option to apt-get to say "force refresh through proxy"? this is totally not googleable :(
<sarnold> pitti: Acquire::http::proxy::192.168.122.1 DIRECT;
<pitti> sarnold: wow, I've never seen that one
<sarnold> replace IP as needed :)
<pitti> I rememvered something like acquire::http:blaproxybla=refresh or similar, not with IP numbers
<sarnold> pitti: it's the only way to test packages from a local repository and still use a local caching proxy sanely. :)
<sarnold> oh :) there might be something better then? hehe
<mvo> pitti: oh, this is the one you are look for ? yeah, what sarnold said, but you may need -o Acquire::http::No-Cache=1 for transparent proxies
<pitti> I mean, the proxy has broken/outdated _Packages, and I want to circumvent it / tell the proxy "refresh your files, d***it"
<sarnold> pitti: ahhh. no idea there, sorry.
<rbasak> sarnold: I do that sort of thing at proxy level. You can tell squid.conf to always refresh.
<pitti> mvo: thanks; still didn't help, but I'll experiment further
<rbasak> (only for Packages|Release etc)
<sarnold> rbasak: that would make creating new VMs a little easier :)
<mvo> pitti: hm, the no-cache sends a cache-control: no-cache header, so if the cache is not honoring this its â¦ broken
<xnox> pitti: actually, with such a change rebuilding systemd i get strange postinst.
<pitti> sarnold: so your command wouldn't work for the transparent proxy on the canonical network supposedly?
<xnox> pitti: http://paste.ubuntu.com/7534673/
<rbasak> sarnold: http://paste.ubuntu.com/7534674/
<mvo> rbasak: squid-deb-prroxy  uses that too
<pitti> xnox: oh? it looks quite alright here; and if I ever get rid of the hash sum mismatches I could even test it..
<pitti> xnox: ah, I get the same
<rbasak> pitti: does that help you?
<sarnold> rbasak: oww my eyes glaze over a bit :)
<xnox> pitti: it should (a) only one section added by dh_installinit (b) only one call to update-rc.d with the right arguments, i believe.
<rbasak> Just lines 28 and 29 are what matter.
<pitti> rbasak: sorry, what is "that"?
<rbasak> They cause squid to always check for updates to Release and Packages.
<mvo> pitti: *cougt* there is a plan to fix the hashsum mismatches that involves rbasak :)
<rbasak> pitti: my squid.conf in above paste
<pitti> rbasak: (and I don't know what the canonical network uses, presumably squid?)
<rbasak> Doing this completely prevents hash sum mismatches from propogating through a proxy.
<pitti> rbasak: ah, I suppose it's out of my powers to fix that; I'll try the hotel network
<pitti> brb
<mvo> pitti: or talk to is maybe?
<rbasak> IS also altered the way the files are packaged, so hash sum mismatches should never get cached anyway.
<sarnold> rbasak: oh, I've already got that. I wonder why I needed the DIRECT apt-get configuration..
<rbasak> Err...s/packaged/published/
<pitti> xnox: I know why
<pitti> xnox: /usr/share/debhelper/autoscripts/postinst-upstart-replace
<pitti> xnox: that needs to go
<pitti> xnox: for testing we can just empty the file, for the upload it shold also be dropped from dh_installinit
<xnox> pitti: \o/ yes!
<pitti> xnox: as in the current diff
<pitti> mvo: hotel network also didn't help, so I suppose it's something else; I'll try a different mirror
<sarnold> pitti: it might be worth reporting in #ubuntu-mirrors -- they can sometimes poke a refresh
<pitti> sarnold: well, I'm still sceptical -- it happens on de.archive and archive alike
<sarnold> pitti: oh, interesting
 * pitti tries it.archive
<pitti> \o/
<pitti> ok, that and local apt-cacher-ng == â¥ again
<pitti> xnox: my diff -u /var/lib/dpkg/info/udev.postinst /tmp/x/DEBIAN/postinst looks good now
<pitti> xnox: where /tmp/x is dpkg-deb -R udev_204-10ubuntu6_amd64.deb /tmp/x
<pitti> xnox: and installing that I now have /etc/rcS.d/S02udev -> ../init.d/udev and /etc/rcS.d/S03udev-finish -> ../init.d/udev-finish
<pitti> xnox: mdadm and nut install fine
<pitti> xnox: so this is looking good \o/
<xnox> cool.
 * xnox is still building
<xnox> (my laptop is slow, i should fix my connection to my server)
<LocutusOfBorg1> Hi, can anybody please explain why of a build failure and retry it?
<LocutusOfBorg1> tomcat8 ---> missing libeasymock-java (>= 3.0)
<LocutusOfBorg1> easymock --> missing libobjenesis-java
<LocutusOfBorg1> objenesis in the archive since one month or so
<LocutusOfBorg1> why easymock didn't find it?
<pitti> xnox: do you understand http://paste.ubuntu.com/7534786/ ?
<pitti> xnox: it's apparently because of the new Provides: mdadm-raid
<pitti> xnox: ah no, due to Provides: lvm lvm2
<xnox> pitti: i still don't like the postinst.
<pitti> xnox: what's wrong now?
 * rbasak agrees with LocutusOfBorg1
<rbasak> Can someone hit the rebuild button on https://launchpad.net/ubuntu/+source/easymock/3.2+ds-2/+build/5937740 please?
<rbasak> I can do tomcat8 but not easymock.
<pitti> rbasak: done
<rbasak> Thanks!
<rbasak> LocutusOfBorg1: hmm. It failed again.
 * rbasak looks deeper
<pitti> rbasak: easymock is in main, libobjenesis-java in universe
<pitti>  easymock | 2.5.2+ds-1       | utopic/universe | source
<rbasak> Oh
<pitti>  easymock | 3.2+ds-2         | utopic-proposed | source
<pitti> apparently someone promoted it to main in -proposed
<pitti> which looks odd
<pitti> GunnarHj: copied PPA to -proposed FYI
<LocutusOfBorg1> so rbasak pitti how can we fix this?
<rbasak> I think an archive admin will need to untangle it
<rbasak> Oh..pitti is one :)
<mardy> pitti: hi! I'm trying out https://code.launchpad.net/~pitti/ubuntu-system-settings-online-accounts/py3tests/+merge/221118 on the desktop
<xnox> pitti: meeting at the moment.
<mardy> pitti: it works fine, but if I pass the "-v" option to autopilot3-sandbox-run, then it complains
<mardy> (getopt: invalid option -- 'v')
<pitti> mardy: oh, hang on, that's odd -- is that in my MP?
<mardy> pitti: yes, in debian/tests/autopilot
<pitti> LocutusOfBorg1, rbasak: I figure we need to find out why it was promoted to main, whether it was an error or an ongoing MIR
<pitti> mardy: checking
<pitti> mardy: ah, I probably mixed that up with autopilot3 -v
<pitti> mardy: right, needs an extra -a; re-running test now
<pitti> mardy: odd that the whole test didn't fail; that sounds like a mis-handling of exit codes, thanks for pointing out
<pitti> xnox: found it
<GunnarHj> pitti: Thanks! ( as regards the langpacks :) )
<rbasak> doko: looks like moving to lua5.2-dev regressed apache2: bug 1323930
<ubottu> bug 1323930 in apache2 (Ubuntu) "mod_lua.so missing from 14.04 install (apache2-bin, 2.4.7-1ubuntu4))" [Undecided,New] https://launchpad.net/bugs/1323930
<rbasak> Seems to me that not much supports lua5.2 yet. I think nginx was the other one. From my perspective, anyway.
<rbasak> Googling around it looks like other distros have had this issue too.
<pitti> mardy: branch updated, confirmed to work now
<pitti> mardy: I'll see to fix the wrong ap3-sandbox-run exit code
<sarnold> rbasak: I think what you're remembering is that nginx didn't support lua 5.2: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710
<ubottu> Launchpad bug 1262710 in nginx (Ubuntu) "[MIR] nginx" [Undecided,Fix released]
<rbasak> sarnold: right
<rbasak> So neither does apache2 AFAICT.
<doko> rbasak, jamespage: please fix it
<rbasak> doko: er...please don't regress packages? You want me to upload a new apache2 to build against liblua5.1-0-dev again, since that's still in main?
<rbasak> Looking at https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710/comments/25 here - strikes me that this is the same.
<ubottu> Launchpad bug 1262710 in nginx (Ubuntu) "[MIR] nginx" [Undecided,Fix released]
<pitti> xnox: ok, I fixed udev's dependency loop with the lvm2 error; standing by for adding a versioned debhelper build dep and uploading the fix
<pitti> xnox: can you ping me when you are done with your meeting? I'll join you
<LocutusOfBorg1> pitti, https://bugs.launchpad.net/ubuntu/+source/easymock/+bug/589193
<ubottu> Launchpad bug 589193 in easymock (Ubuntu) "Sync easymock 2.4+ds1-4 (main) from Debian unstable (main)" [Wishlist,Fix released]
<LocutusOfBorg1> is this the reason?
<pitti> LocutusOfBorg1: that's not a MIR; let me demote it for now, if it's needed it'll reappear in component-mismatches
<LocutusOfBorg1> don't know what a MIR means :) sorry
<pitti> main inclusion report
<pitti> request
<LocutusOfBorg1> ah ok yeah
<pitti> done
<sarnold> easymock has been in main from lucid-trusty, in universe in utopic...
<pitti> needs a publisher cycle, then the build should auto-start (it's depwait)
<LocutusOfBorg1> so the next tomcat8 will be in universe?
<sarnold> I think that'll be the default disposition unless someone files a MIR and steps to up be a bug subscriber
<pitti> mardy: thanks for approving; do I need to do anything, or will the landing happen magically?
<pitti> mardy: where "magically" means "the landers will pick it up at some point" (it's not urgent of course)
<mardy> pitti: we'll land it ourselves, soonish :-)
<pitti> dpm: do we know that the current PPA langpack fixes that? (for -sv)
<dpm> pitti, I don't know, let me clarify that on the e-mail and ask them to test it
<pitti> dpm: I'll search the current .deb from the archive and ask on the bug
<dpm> awesome, thanks pitti
<cyphermox> xnox: bottom device is your usb dongle, top one is the integrated chip in my laptop: http://paste.ubuntu.com/7535167/
<pitti> dpm: .. if LP wouldn't keep timing out
<dpm> pitti, I know, I've pinged wgrant about it, but it seems it's not a trivial fix
<wgrant> dpm, pitti: Which timeout?
<pitti> I reloaded https://launchpad.net/~ubuntu-langpack/+archive/ppa?field.series_filter=saucy about 15 times, it seems it's finally working now
<dpm> wgrant, it's not possible to finish any translations in LP without getting a timeout at some point
<wgrant> dpm: Yeah, a lot of that will go away with the new DB servers in a couple of weeks, and we're actually planning on working on the stuff that *won't* be fixed later this afternoon.
<wgrant> We haven't worked on it in a couple of years, as there are fundamental flaws in the schema which make it impossible to perform well on HDDs
<wgrant> We'd have to spend either 9 months on reengineering rosetta from the inside out, or moving to SSDs
<wgrant> And the new DB servers have SSDs.
<wgrant> There are other issues on top of thse DB performance problems, but it wasn't worth spending time on them until we had a solution to the underlying DB problem.
<wgrant> And now we do, so we're spending time this week on sorting it out.
<wgrant> *Hopefully* most of the timeouts will be gone in a month ish.
<pitti> dpm: ah, we never actually built saucy langpack updates, it seems
<dpm> wgrant, that sounds great, looking forward to that, thanks for the details!
<pitti> dpm: for swedish, any way
<pitti> http://ppa.launchpad.net/ubuntu-langpack/ubuntu/pool/main/l/language-pack-sv/
<dpm> wgrant, not sure you saw the ping in lp-ops, but do you have any updates re: opening the utopic translations?
<pitti> dpm: so we need to identify the particular fix, and manually SRU the package for saucy
<dpm> pitti, what do you mean by "identify the particular fix"? Would the last exported .po file for software-properties-gtk not include the fix already?
<stgraber> xnox, pitti: where are we with fixing nut so we can get all those packages finally migrating from proposed?
<wgrant> dpm: I tried to get webops time for that yesterday, but failed. I'll try again this afternoon.
<dpm> thanks wgrant
<shadeslayer> pitti: https://jenkins.qa.ubuntu.com/job/utopic-adt-kde4libs/ARCH=amd64,label=adt/lastBuild/console < could you tell me what the error is? I can't quite figure out what went wrong
<shadeslayer> the hook works locally here
<dobey> dpm: do you know when a new version of calculator will go into the image btw?
<dpm> dobey, some time this week. I need to release all core apps to include the new translations done for the MAE image
<dobey> dpm: great. i've been waiting for translations to show up :)
<dpm> dobey, cool :) - btw, I noticed a side effect whereby if the .desktop file is in /usr/share, the Name is shown translated as well. You can see it in action switching to the zh_CN locale and looking at the System Settings and Media Player icons in My Apps
<dpm> in 'es' they appear translated too
<dobey> dpm: yes
<dobey> dpm: those are not click packaged apps though
<dpm> yeah, I know, I just thought I'd mention it
<dobey> dpm: it would be nice to get the translations into the .desktop files for those too, but we are currently using the gettext domain for them (we can, because they're debs and more predictable)
<xnox> stgraber: yes, there will be ~25 more uploads to go together.
<xnox> stgraber: we want to rebuild those, such that they gain update-rc.d call, cause they are dependencies of other packages and insserv might break if one has those installed.
<xnox> stgraber: (that's part of the fix for nut as well, plus 24 others....)
<pitti> stgraber: sorry, my network hung for a while, I missed your ping; but I'm sitting next to xnox, we are doing the rebuilds
<stgraber> pitti: ok, do we need all of them to go in at once or can we start with nut so adt is happy and we stop building broken packages in PPAs?
<stgraber> pitti: also, where are you sitting? :)
<pitti> stgraber: we have all 25 prepared now, but we can bump the score of nut of course
<xnox> stgraber: we can land it as soon as debhelper & systemd rebuilds.
<xnox> stgraber: to unbreak the world/ppas
<pitti> stgraber: because potentially all of them can break upgrades
<xnox> stgraber: waiting for debhelper at the moment.
<pitti> stgraber: (in -proposed; we have a block there)
<xnox> stgraber: we are in 3C or something.
<pitti> stgraber: in studio 2b
<xnox> stgraber: 2b
<pitti> stgraber: once debhelper is published, we can upload the lot
<ogra_> mterry, https://lists.ubuntu.com/archives/kernel-team/2014-May/043153.html ... so now the next beer is due for apw and/or rtg to fast-path this ...
<mterry> ogra_, awesome
<pitti> stgraber: we'll most probably need to ignore the openvswitch failure, that started failing on infinite hangs a few weeks ago
<shadeslayer> pitti: any idea?
<pitti> shadeslayer: about what? sorry, I missed some parts of IRC due to disconnect
<shadeslayer> pitti: https://jenkins.qa.ubuntu.com/job/utopic-adt-kde4libs/ARCH=amd64,label=adt/lastBuild/console
<shadeslayer> pitti: all it says is adt-run: unexpected error: test dependencies are unsatisfiable , but I don't know what it could not satisfy
<pitti> shadeslayer: that looks like a conflict between iputils-ping and inetutils-ping?
<dpm> pitti, not sure you saw the question earlier, you were saying you got disconnected -> <pitti> dpm: so we need to identify the particular fix, and manually SRU the package for saucy
<dpm> <dpm> pitti, what do you mean by "identify the particular fix"? Would the last exported .po file for software-properties-gtk not include the fix already?
<pitti> shadeslayer: http://paste.ubuntu.com/7535513/
<shadeslayer> hm, true
<shadeslayer> thanks, didn't see that
<pitti> dpm: well, I hope; that's what my question was
<shadeslayer> pitti: it's odd that it worked in my pbuilder
<dpm> pitti, so I guess we'll have to scan through the deltas here to find out the one with the fix: https://translations.launchpad.net/ubuntu/saucy/+language-packs
<dpm> let me see if I can find it...
<dpm> pitti, ah, luckily the latest delta export includes the fix already :)
<dpm> pitti, updated the bug with the info
<dpm> hi GunnarHj, around?
<GunnarHj> dpm: Yes
<dpm> GunnarHj, hey, thanks so much for getting the langpack schedule and the workflow back in shape!
<GunnarHj> dpm: You're welcome. It was the question from the Swedish team that made me wonder...
<dpm> yeah, we're trying to get that sorted
<GunnarHj> dpm: I suppose we don't need that much of organizing with respect to the releases between the LTSs.
<dpm> GunnarHj, I think it'd still be good to plan a couple of updates, but we can keep it light
<GunnarHj> dpm: Right.
<dpm> GunnarHj, also, you were saying you were looking for some feedback: so everything looks perfect, the only thing I'd suggest is to do the call for testing after the uploads to -proposed have been finished, so that folks can start testing straight away.
<GunnarHj> dpm: Yeah, actually it has already been on the main server for a while; I'm not sure about the mirrors, which is why I said "soon".
<dpm> GunnarHj, ah, perfect
<rbasak> infinity: around? May I have an opinion on bug 1323930 please, from the perspective of https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710/comments/25? Is it OK for Apache to depend on lua 5.1 also, for the same reason as nginx?
<ubottu> Launchpad bug 1262710 in nginx (Ubuntu) "[MIR] nginx" [Undecided,Fix released]
<ubottu> bug 1323930 in apache2 (Ubuntu) "mod_lua.so missing from 14.04 install (apache2-bin, 2.4.7-1ubuntu4))" [Undecided,New] https://launchpad.net/bugs/1323930
<rbasak> doko or anyone else: ^^
<rbasak> I've tested a fix with lua 5.1 locally - it fixes the regression.
<rbasak> I'm also wondering about SRUing Trusty
<infinity> rbasak: Without reading the bug, I'd say that's fine.
<rbasak> OK, thanks.
<infinity> rbasak: Yeah, after reading the bug, my opinion hasn't changed.  I think we need to sort out a way forward for lua between now and 16.04, but since we're supporting it in 14.04 already, that's fine for apache2 in 14.04 as well, and for the next few short-support releases, if we don't have a better solution right away.
<infinity> rbasak: But let's no forget about this before 16.04, cause supporting lua 5.1 forever seems ungood.
<rbasak> infinity: OK. Perhaps I should file a bug for lua 5.2 support with tasks for apache2 and nginx.
<rbasak> I get the impression that lua 5.2 is a bit more like python 2.7->3.0 than python 2.6->2.7, IYSWIM
<infinity> rbasak: On the C side, it certainly has some "fun" API changes, but nothing world-ending.  It just needs someone with both time and carefactor to port things.
 * rbasak filed bug 1324062
<ubottu> bug 1324062 in nginx (Ubuntu) "No lua 5.2 support" [High,Triaged] https://launchpad.net/bugs/1324062
<rbasak> (with apache2 and nginx tasks)
<rbasak> doko: ^^ I guess you'll want to track this?
<doko> rbasak, jamespage: this is called +1 maintenance, so please forward this to the person in the server team doing +1 maintenance
<doko> for now, assigned to the server team
<seb128> dholbach, hey, can you commit your gnome-settings-daemon upload from yesterday to the vcs?
<dholbach> seb128, urgh, ok
<seb128> dholbach, danke
<dholbach> seb128, done
<seb128> dholbach, danke
<mardy> rsalveti: hi! Does the emulator work in Utopic? I can't install it ("ubuntu-emulator-runtime:i386 : Depends: libgl1-mesa-glx:i386 but it is not going to be installed")
<mlankhorst> mardy: so figure out what is going on there ;-) try apt-get install libgl1-mesa-glx:i386 ?
<mardy> mlankhorst: it depends on libudev{0,1}:i386, but neither are installeble (the "0" does not exist, the "1" seems to be wanting to remove libqt5gui, and consequently half of the system)
<mlankhorst> ugh :/
<mlankhorst> but it needs libudev to do anything useful.. probably some multiarch issue then?
<mlankhorst> are you running -proposed by any chance?
<TheMuso> S/quit
<seb128> RAOF, thanks
<pitti> stgraber: hm, I think the openvswitch block didn't work: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lsb
<pitti> stgraber: what's interesting there is that this shows the previous version of openvswitch (smells like another britney bug)
<pitti> that might explain why your ignore doesn't work?
<pitti> stgraber: that's now holding up the entire stack as it seems
<stgraber> pitti: you should be in #ubuntu-release ;)
<stgraber> (britney appears confused, cjwatson suggested a workaround which I know just pushed, we'll see with the next run)
<pitti> stgraber: merci
<wgrant> dpm: utopic translations are importing
<dpm> \o/
<dpm> wgrant, so what's the next step? Opening the translations in the LP UI?
<brendand> anyone know what this really means? insserv: Service dbus has to be enabled to start service <x>
<brendand> i've had a rough upgrade and getting that for several packages
<brendand> lightdm
<brendand> avahi-daemon
<brendand> etc
<brendand> this is probably clearer: http://paste.ubuntu.com/7538356/
<genii> Might be missing symlink to /run from /var/run
<LLKCKfan> Hello
<LLKCKfan>  How can someone who is almost 30 and never had a job get one? I have been applying just to be told I am not what they are looking for (We have reviewed your application for this position and will be proceeding with other candidates at this time.) or they are not hiring.
<genii> LLKCKfan: Please stop spamming the same stuff about not finding a job in every channel you go to. It's annoying and usually offtopic for the channels you're doing it in.
#ubuntu-devel 2014-05-29
<darkxst> pitti, xnox, cjwatson: any idea what suddenly caused ppp to fail installing in ubuntu gnome livecd builds? http://pastebin.com/QcAZAZxC
<Logan_> why don't we have locales-all in eglibc?
<Logan_> nvm, found the answer
<Unit193> xnox: I'd presume you'd like me to file a bug about zram-config needing a init script or systemd service?
<xnox> Unit193: there is one already.
<xnox> Unit193: systemd zram-config units should be added.
<Unit193> xnox: I don't see them in bzr, but I'll trust you.  Sorry for the bother, then.
<xnox> Unit193: i mean, there is a bug already =)
<xnox> Unit193: i don't believe it's been implemented yet.
<Unit193> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/zram-config/utopic/files/head:/debian/ Oh good, so I'm only silly for ignoring all bugs. :P
<xnox> cjwatson: stgraber: pitti: so in ^ ubuntu-gnome case, ppp is configured before gdm is. And pppd-dns init.d script has Required-Start: gdm. Thus, the package should depend on gdm..... which seems wrong. Should the gdm move to X-Start-After instead?
<xnox> (Should-start ?!)
<xnox> oh, debian dropped gdm
<xnox> let me merge / upload ppp
<stgraber> that dependency seems wrong to begin with, why would pppd care about gdm?
<ogra_> debian dropped gdm ? wow
<ogra_> oh, the dependency you mean ... heh
<xnox> stgraber: actually infinity added the gdm dep.... and change default start levels...
<xnox> http://paste.ubuntu.com/7541969/
<xnox> which seems a bit silly, given that dependencies have not been used in ubuntu, until now.
<cjwatson> I wonder if that was a mismerge
<cjwatson> It's not mentioned in the changelog, and perhaps it just hit when some files moved around
<cjwatson>     - debian/ppp.pppd-dns: Update LSB header.
<cjwatson> could easily have got stale
<stgraber> looks like it, I don't see why anyone would voluntarily introduce that delta in Ubuntu
<xnox> i uploaded dropping "gdm" dep only, for now (to unbreak every image type.... cause ppp seems to be seeded everywhere)
<xnox> and will chat to infinity about merging ppp (or possibly syncing)
<xnox> cjwatson: it also looks like it started to link against OpenSSL, yet there are gpl v2 plugins in ppp.
<cjwatson> lalala
<pitti> darkxst: gdm only got promoted to utopic this (early) morning, so I guess that image build didn't see that yet
<xnox> cjwatson: well, openssl was a delta introduced in ubuntu?!
<pitti> xnox: hm, why would ppp depend on gdm? that sounds like the wrong way around?
<xnox> pitti: it's order dependant.
<xnox> pitti: gnome image build is failing, because ppp is configured before gdm, yet ppp init.d script depends on gdm to be already enabled..... when it at all shouldn't really.
<pitti> xnox: yeah, that init.d gdm dep sounds fishy
<pitti> even if it *had* a reason to depend on a DM (can't think of any), it shouldn't hardcode a particular one
<pitti> but ugh, this is network setup
<infinity> xnox: That doesn't sound like the sort of thing I would have done on purpose.
<pitti> Noskcaj, seb128: so gnome-icon-theme-symbolic 3.12 got synced yesterday, which is incompatible with our g-i-t 3.10; do we want to update g-i-t to 3.12 or delete the g-i-t-s from proposed?
<seb128> pitti, is it really incompatible or is it the packaging enforcing the same serie?
<pitti> seb128: I suppose it's mostly just the dependencies
<seb128> or asked differently, can we tweak the depends
<seb128> who did sync it?
<seb128> Noskcaj?
<cjwatson> xnox: if there are GPL plugins, then I can certainly see a case for either converting to GnuTLS, or for reverting the change in 2.4.5-5.1ubuntu2 and reopening bug 643417; but I haven't investigated
<pitti> seb128: dholbach, sponsored for Noskcaj
<ubottu> bug 643417 in Debian "[needs-packaging] ppp-2.4.5-eaptls-mppe" [Unknown,New] https://launchpad.net/bugs/643417
<infinity> xnox: Or at all...
<pitti> seb128: but anyway, my question was rather if we generally move 3.12 wards
<seb128> pitti, we do the usual "safe updates are fine, updates that are disruptives should be hold on in a first time"
<infinity> xnox: When are you claiming this change crept in? :P
<seb128> pitti, not sure how much they changed the icons, I know they are merging symbolic in the main theme, but that might be 3.13 only
<mlankhorst> xkill
<mlankhorst> oops
<xnox> infinity: well, you were last merging it (and kept lsb-headers change that introduces gdm dep). the openssl build-dep was added after.
<stgraber> xnox: you broke Ubuntu!
<RAOF> pitti: colord tag debian/1.2.0-2 in collab-maint git should be ready to upload to sid.
<infinity> xnox: Fair enough that I didn't drop the delta, but it's been there since jaunty, looks like.  Blame Keybuk. ;)
<xnox> infinity: haha =)
<brendand> Trying to boot and stuck on 'Stopping Click system level hooks'. Though i get the feeling this isn't the real problem
<brendand> Any way i can get more verbose?
<seb128> heh, I was about to ask about that as well
<brendand> I already removed quiet from grub
<seb128> xnox, pitti, infinity: have you bricked utopic? ;-)
<brendand> :)
 * brendand takes heart that it's not just him
<pitti> right, being worked on
<seb128> pitti, any workaround to boot my machine again?
<brendand> seb128, safe mode
<seb128> I want X
<pitti> seb128: ironically, init=/lib/systemd/systemd
<seb128> I'm in safe mode
<brendand> seb128, start lightdm
<seb128> brendand, my fs is ro in safe mode
<seb128> pitti, danke
<brendand> or do what pitti says
<seb128> yeah, that's what I'm doing
<brendand> Usually the right answer :)
<brendand> seb128 - where do i set that option?
<seb128> brendand, grub I guess
<pitti> boot with holding the shift key, then edit Ubuntu
<brendand> pitti - on the 'linux' line?
<pitti> yes
<brendand> brilliant!
<seb128> pitti, works, danke!
<brendand> Pitti - if i were in Malta i'd buy you all the beers
<pitti> you mean kill us all because we broke utopic :)
<brendand> pitti, well if you want to take the blame
<brendand> pitti - then maybe there can be some poison in the beers :)
<brendand> pitti, now i'm curious what happened
<pitti> seb128, brendand: found an easier trick
<brendand> pitti, seems pretty easy to me :) but tell me anyway
* pitti changed the topic of #ubuntu-devel to: Utopic boot broken: touch /etc/init.d/.legacy-bootordering (in rescue mode) | Archive: Open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pi
<seb128> pitti, danke
<brendand> pitti, ah rather than changing to systemd
<pitti> either works
<brendand> pitti, is one 'safer' than the other?
<pitti> brendand: let's say I can't fully guarantee that the .legacy-bootordering trick does not have less obvious side effects, like starting some init.d scripts twice
<brendand> pitti, i'll stick with systemd then
<brendand> until that breaks too :)
<darkxst> pitti I have no idea what you mean by gdm only got promoted to utopic? gdm has been there all along
<pitti> darkxst: I mean from utopic-proposed
<seb128> it's pitti's secret plan to push us to start using systemd!
<Unit193> pitti: That pushed "Patch Pilots:" off the end, FYI.
<darkxst> seb128, yes the merging of symbolic icons is only for 3.13
<seb128> darkxst, is g-i-t-s working fine with g-i-t 3.10? are the 3.12 update changing anything obvious visually/likely to create issues?
<pitti> Unit193: I know; -EDONTCARE for now :)
<pitti> so, sysvinit uploaded with panic fix
<Unit193> Sounds great. :)
* pitti changed the topic of #ubuntu-devel to: Utopic boot broken; wait for sysv-rc 2.88dsf-41ubuntu15, boot with init=/lib/systemd/system in the meantime | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/l
* pitti changed the topic of #ubuntu-devel to: Utopic boot fixed in sysv-rc 2.88dsf-41ubuntu15, boot with init=/lib/systemd/system until then | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch
<darkxst> seb128, I haven't actually tested the 3.12 icon themes against 3.10, but I don't think there were any major changes for 3.12
<pitti> seb128, brendand: please remember to remove /etc/init.d/.legacy-bootordering after you got the new sysv-rc
<pitti> stgraber set the fast-track flag for that so that we don't have to wait for $WORLD autopkgtests
<seb128> pitti, I didn't do that, just changed the init line ... do you want me to test that upload to see if it restores boot for me?
<pitti> seb128: if you wish, sure
<apw> pitti, can you check the current topic as /lib/systemd/system is a directory, and the kernel cannot boot that
* pitti changed the topic of #ubuntu-devel to: Utopic boot fixed in sysv-rc 2.88dsf-41ubuntu15, boot with init=/lib/systemd/systemd until then | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patc
<pitti> apw: thakns
 * pitti tosses apw a "d"
<apw> pitti, :)
<brendand> pitti, i didn't touch that. init= did the trick for me
<pitti> brendand: right
<pitti> I changed the topic to avoid people having to clean up that file
<pitti> not quite the way I intended people to try systemd though :)
<apw> pitti, so you _claim_
<brendand> pitti, well the test passes !
<pitti> so we already broke everyone by just re-syncing to Debian's sysvinit, which isn't even close to upstart/systemd
<seb128> pitti, that sysvinit update fixes my boot, thanks!
<pitti> I just sent an u-devel@ mail about it
<ypwong> can't checkout unity-lens-files from bzr, anyone knows what's wrong? http://paste.ubuntu.com/7542487/
<darkxst> pitti, seems like my main machine refuses to boot with systemd init :(
<pitti> darkxst: so use the .legacy-bootordering workaround?
<darkxst> pitti, I installed the sysv update which fixed things
<darkxst> pitti, but I couldnt even get as far as a VT when booting with systemd ;(
<ogra_> pitti, slangasek, i think we need to talk about the custom upstart helpers we have on the phone ... i.e. we have an upstart bridge that talks to the container to read/set android properties ... can systemd offer us the same ? who will have to port it etc ...
<slangasek> ogra_: yes, and that is not on the roadmap for 14.10
<brendand> is there any sort of documentation on actually using click (as a command line tool). like for creating click packages, installing them, etc
<slangasek> brendand: 'man click'? :)
<brendand> slangasek, sort of
<ogra_> slangasek, oh, i thought there were plans to switch the default ?
<brendand> slangasek, i'll see how far i can get with that
<slangasek> ogra_: not for the phone
<ogra_> would we have too special case the phone to keep upstart ?
<ogra_> *to
<ogra_> (we currently just inherit ubuntu-minimal)
<slangasek> ogra_: we're only switching to systemd by default opportunistically in 14.10 if it's stable, and not for the phone because it would be disruptive to RTM
<ogra_> ah, super then ...
<ogra_> thanks !
<LocutusOfBorg1> can anybody please retry this one? https://launchpad.net/ubuntu/+source/sandboxgamemaker/2.7.1+dfsg-2build2/+build/6044192
<LocutusOfBorg1> seems blocking the libenet7 transition
<LocutusOfBorg1> https://launchpad.net/ubuntu/+source/cube2/0.0.20130203+dfsg-1build1/+build/6044206
<Saviq> pitti, THANK YOU! (re: sysv-rc)
<goarilla> can someone tell me what I need to do to recreate the /isolinux/bootlogo gfxboot archive
<pitti> RAOF: hmm - I just see 1.2.0-1 in colord git, but that's already in exp?
<cjwatson> goarilla: That's built by the gfxboot-theme-ubuntu source package - "make installdir" there
<BluesKaj> ok, here's a list of the problem dependencies on 14.10, http://privatepaste.com/794db390e0, wonder if any devs are looking at this?
<pitti> RAOF: uploaded
<RAOF> pitti: Huh. Experimental?
<pitti> RAOF: oh sorry; the previous one I looked at was against experimental and I didn't look hard enough at the new changelog
<pitti> RAOF: so, -3 then? :-/
<RAOF> pitti: I guess so :)
<RAOF> Would you like to do that?
<pitti> RAOF: can do
<BluesKaj> pitti, I'm looking at your post in the devel forum https://lists.ubuntu.com/archives/ubuntu-devel/2014-May/038333.html, but i'm not having boot problems, only upgrade problems, this what gets written to /var/lib/insserv/run-20140529T0840.log ,  http://privatepaste.com/ac2b0e2233 , any suggestions?
<BluesKaj> pitti, this the dependency error, http://privatepaste.com/794db390e0
<pitti> BluesKaj: that was fixed in udev 204-10ubuntu7, do you have that?
<pitti> BluesKaj: right, your second pastebin shows it's ubuntu6
<BluesKaj> pitti, muon shows I have 204-10ubuntu5 installed, but upgradeable
<pitti> xnox: pad.ubuntu.com/init.d-task-check
<BluesKaj> pitti, upgrade it or will it fail ?
<pitti> BluesKaj: upgrade shold be fine
<pitti> RAOF: -3 uploaded FTR
<RAOF> pitti: Much ta
<BluesKaj> pitti, it won't mark for upgrade, fails
<BluesKaj> pitti, looks like I'm caught in dependency hell
<pitti> BluesKaj: hang on, I'm just fixing someone else's box with that problem
<BluesKaj> ok pitti np, thanks {)
<pitti> BluesKaj: so what I did here was to apt-get download libudev1 udev, then sudo dpkg -i those, then run apt-get -f install a few times
<BluesKaj> pitti, not installing dpkg: error processing package initscripts (--configure)
<BluesKaj> same with sysv-rc systemd and libpam-systemd:amd64 , ran -f install several times after dpkg install
<xnox> infinity: hey, is procps installed in the buildds?
<pitti> xnox: killed from -proposed
<xnox> pitti: tah.
<BluesKaj> looks like I'm jammed up in the dependency vicious cycle :\, pitti afraid the udev and libudev1 wouldn't install
<pitti> BluesKaj: you need to do apt-get download / dpkg -i, apt won't help :/
<BluesKaj> I used dpkg -i
<shadeslayer> pitti: is utopic broken again ? :(
<shadeslayer> pitti: http://paste.kde.org/phcz8yo9s
<pitti> shadeslayer: not as long as you have udev >= ubuntu7
 * shadeslayer checks
<pitti> shadeslayer: that's -proposed, procps ubuntu4 just got removed
<pitti> shadeslayer: yes, ubuntu4 is known-broken
<shadeslayer> ok
<shadeslayer> pitti: ok, I'm using proposed in my pbuilder
<pitti> shadeslayer: should clear up in some 20 mins
<shadeslayer> cool :)
<rsalveti> pitti: xnox: wgrant: chroot problems again https://launchpadlibrarian.net/176554996/buildlog_ubuntu-utopic-amd64.hud_13.10.1%2B14.10.20140529.1-0ubuntu1_CHROOTWAIT.txt.gz
<rsalveti> is that known?
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#procps
<xnox> rsalveti: we know, it's fixed, waiting for archive.
<rsalveti> xnox: great, thanks
<xnox> rsalveti: "fixed" procps is removed from the archive, waiting for publishing cycle.
<BluesKaj> pitti, http://privatepaste.com/ea827304ed
<xnox> wgrant: well, pitti removed the package from the archive already
<wgrant> We're getting good at that :)
<xnox> wgrant: =))))
<wgrant> Testing obscure Soyuz corner-cases!
<wgrant> It's just QA.
<xnox> wgrant: adt testing has caught it, so it wouldn't migrate to -release and break either system or buildds permamentaly.
<wgrant> Aw :(
<xnox> wgrant: no surgeries required this time around
<wgrant> :(
<xnox> slangasek: it wasn't dependency problem, it was the fact that in TARGETS the name of the "script/job" was listed, even though it has no dependencies and it's a task in upstart.
<slangasek> xnox: ah.  Well, insserv knows nothing of upstart
<xnox> slangasek: upstart-tasks with no reverse-dependencies should be in TARGETS, since unlike debian we do not support sysv-init boot.
<slangasek> insserv and startpar are two separate pieces
<xnox> (reverse-initd-dependencies)
<xnox> slangasek: hm. ok.
<xnox> slangasek: let me look into startpar.
<BluesKaj> yup, and I'm stuck in between
<xnox> slangasek: the alternative is to remove upstart-task jobs, if there is an init.d script..... and just use init.d script </troll>
<mdeslaur> xnox: so...when a package only has an upstart job, and the user is using systemd, the debhelper stuff explodes when invoke-rc.d is run...
<xnox> mdeslaur: fixed in ubuntu6 debhelper upload + needs rebuilds.
<xnox> mdeslaur: e.g. kernel needs rebuild because of linux-cloud-tools-common
<mdeslaur> xnox: that fix won't work
<mdeslaur> well wait, let me look at it again
<xnox> mdeslaur: if, and only if init.d script is exucatable -> run update-rc.d
<xnox> mdeslaur: invoke-rc.d can be run against any of upstart/sysvinit/systemd
<xnox> (and well should be run)
<mdeslaur> xnox: if there's only an upstart job, and systemd is running, invoke-rc.d gets called with start, but then fails because there is no systemd job
<xnox> mdeslaur: yes.
<xnox> mdeslaur: that's intentional.
<mdeslaur> uhm, why?
<slangasek> mdeslaur: the package shouldn't be considered configured until the service is started; the service cannot be started because it's not supported on the running init
<xnox> mdeslaur: well, not intentional. but current status quo, with the fact that systemd migration has not been complete and ubuntu, unlike debian, has allowed adding upstart jobs without shipping an init.d script.
<slangasek> so it needs to be fixed to integrate
<xnox> mdeslaur: the fix is to either ship init.d script + upstart job, or to ship init.d script + systemd + upstart
<mdeslaur> slangasek, xnox: ah, ok, thanks
<xnox> mdeslaur: currently we don't support shipping just systemd units or (systemd unit + upstart job)
<xnox> rsalveti: shadeslayer: chroots should be fine now.
<sarnold> love it. to move from one init to another init we need to support a third init that we dropped absolute yonks ago..
<slangasek> I'm confused why that's a requirement
<slangasek> it's a requirement for Debian; shouldn't be for Ubuntu
<xnox> sarnold: we never dropped it absolutely..... upstart execs rc at both boot, each of the runlevel, and shutdown.
<xnox> slangasek: at least dh_installinit doesn't support it at the moment.
<mdeslaur> sarnold: we can ship upstart + systemd
<xnox> slangasek: although maybe it's achieved with dh_systemd, not sure.
<xnox> mdeslaur: i didn't try doing that yet.
<slangasek> xnox: which piece is unsupported?
<mdeslaur> oh, sorry, yeah, that's what xnox said
<slangasek> update-rc.d not being called?
<xnox> slangasek: invoke-rc.d start is not called by dh_installinit alone.
<xnox> slangasek: unless one must use dh_systemd, which i am not familiar with, and maybe that does something else.....
<shadeslayer> xnox: still waiting for sync to mirror :)
<slangasek> mm
<xnox> sarnold: rather we try to support both upstart & systemd at the same time. And then involves extra work to integrate startpar.
<mdeslaur> *grumble*
<sarnold> xnox: I'm sorry, I wasn't trying to be mean, I surely haven't looked at it as much as you, it just caught my fancy that we've got to add an old sysv script to make this transition happen..
<ogra_> mdeslaur, why do you grumble ? at least there are no security issues on a system that does not boot
<xnox> sarnold: it is hallarious. In a way migration to upstart never actually was completed =) thus it's all just one big multi-year transition =)))))))))))))))))))))
<mdeslaur> ogra_: I'll just symlink my init.d script to /sbin/halt
<ogra_> +1
<xnox> mdeslaur: emacs; /sbin/halt =))))
<pitti> BluesKaj: well yes, dpkg -i takes a .deb file, not a package name; so sudo dpkg -i libudev1_*.deb
<ogra_> xnox, you sure that shouldnt be systemd-emacs ?
<mdeslaur> ogra_: you better be touching wood right now
<hallyn> ok, only took me 3 hours to give up on trying to get normal login to work by hacking upstart scripts, and just hack tty[2-5].conf to start on local-filesystems
<hallyn> ah goodie, so now that i can log in i can read email and see pitti's email :)
<hallyn> really i don't know why /etc/ttyn.conf don't always start on local-filesystems.  think i'll keep it that way here
<BluesKaj> pitti, thanks for your help, there were some rc.d warnings, but all sems fine now :)
<BluesKaj> on 2 machines btw
<hallyn> so is the fact that today lxc upgrades keep complaining that /etc/init.d/lxc-instance does not exist also related to the utopic init scrits change?
<hallyn> or did i just mess myself up somehow
<hallyn> oh, perhaps related to what xnox said above
<slangasek> hallyn: yes, lxc needs a no-change rebuild w/ current debhelper
<hallyn> do i need to push that as a new source version, or can that be triggered another way?
<hallyn> oh actually i get mine from the ubuntu-lxc ppa anyway.  stgraber can you force a rebuild there?
<hallyn> i'll see if the version in archive actually dtrt
<rbasak> hallyn: if binaries have been published in the archive (doesn't matter which pocket), then you need to do a new upload with a bumped version number. "dch -R" does the right thing I think.
<rbasak> (if you need to)
<rbasak> The same applies in a given PPA, too. You can't have new rebuilt binaries with the same version as previously published binaries in a given archive.
<hallyn> yeah i know how to do it tha tway, seemed plausible there'd be some switch which a few people could pull when it needed to be done at scale :)
<hallyn> though actually -R doesn't seem to dtrt...  (will do it manually)
<rbasak> At scale: "dch -R" in a for loop is what I think everyone does :)
<hallyn> rbasak: you ppl trusting your gpg agnets... :)
<hallyn> rbasak: i do wonder why dch -R didn't work for me.  it just bumped the version # as usual
<hallyn> i mean, i prefer to choose by hand anyway, just wondering...
<rbasak> hallyn: AIUI, for a no change rebuild of a synced package, it should append build1 (or bump to build2, etc). And for a package with an Ubuntu delta, then the ubuntu1 will get bumped to ubuntu2 etc.
<rbasak> Then everything else (eg. autosyncs) behave right
<rbasak> So maybe it needed to just bump the version, if you already had an Ubuntu delta?
<hallyn> hm
<hallyn> i guess that makes sense, except it's not as informative...  but thx
<Noskcaj_> My 14.10 install is now stuck at the
<Noskcaj_> "checking disk" part of startup
<Noskcaj_> Is this a known issue?
<sarnold> Noskcaj_: seen this? https://lists.ubuntu.com/archives/ubuntu-devel/2014-May/038333.html
<Noskcaj_> sarnold: Yeah, I've already tried the first workaround, wasn't sure it was related
<sarnold> Noskcaj_: ah, okay :)
<Noskcaj_> It says boot into resuce mode. How do you do that?
<slangasek> shift at the grub menu, choose the rescue option from the advanced menu
<sarnold> if your grub doesn't have it, add recovery nomodeset to the kernel command line
<Noskcaj_> ok
<Noskcaj_> recovery mode?
<Noskcaj> jpds, There's a new upstream git change for efitools, is it worth packaging? http://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/commit/?id=c33fc28e6be00ac0bfae7fcff48170830a4730d8
<Unit193> Forgot to put a dest in dput again, I need to change 'ubuntu' from being default. >_>
<fdafweaf> The Stats page for myapps.developer.ubuntu.com indicates that i have 17 downloads of my app, and it shows a pie chart breakdown by country, but the line graph at the top of the page doesn't have any data in it
<fdafweaf> Is that correct behavior?
<Logan_> Unit193: I'm disappointed in you
#ubuntu-devel 2014-05-30
<siretart> Logan_: thanks :-)
<Logan_> for what? :P
<Logan_> oh, my PM?
<siretart> yes :)
<pfsmorigo> hi, what source this message came from? "An installation step failed. You can try to run the failing item again from the menu" I though that was from debian-installer but I did't find it.
<siretart> infinity: libav built everywhere now. I think we're good to start the transition
<alkisg> Hi, in Ubuntu 14.04, gedit depends on libzeitgeist-2.0-0. If I keep that library, but remove the zeitgeist app which happens to be preinstalled,
<alkisg> then gedit won't start until I disable the "zeitgeist gedit plugin"
<alkisg> Error message: ** (gedit:3187): CRITICAL **: zeitgeist_log_insert_event_no_reply: assertion 'self != NULL' failed
<alkisg> Should I file a bug in upstream gedit to have the gedit zeitgeist plugin not crash gedit when zeitgeist isn't installed,
<alkisg> or file a bug against debian/ubuntu to depend on zeitgeist, and not just its library?
<siretart> alkisg: the former sounds appropriate in any case
<alkisg> siretart: depending means that sysadmins that want zeitgeist off globally, can't remove it from their systems... is that a requirement for using gedit?
<alkisg> Ah
<alkisg> Really sorry, misread
<alkisg> True, about the former, I was mostly asking if it's ubuntu specific or not
<alkisg> If it's not ubuntu specific, then a bug should be filed, of course...
<alkisg> Hmmm, the ubuntu-settings package seems to force enablement of zeitgeist plugin: /usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override:active-plugins = ['docinfo', 'modelines', 'filebrowser', 'spell', 'time', 'zeitgeistplugin']
<alkisg> org.gnome.gedit.gschema.xml on the other hand says: <default>['docinfo', 'modelines', 'filebrowser', 'spell', 'time']</default>
<alkisg> So I guess reverting the Ubuntu defaults to match the upstream defaults, would solve the issue, until it's fixed upstream, if they ever want to fix it...
 * alkisg files a bug report about that...
<Logan_> why isn't texlive-bin automatically syncing from unstable?
<Noskcaj> How can i force dput to include a .orig file? MY ppa uploads are being rejected because the .orig isn't able to be found
<rsalveti> pitti: ogra_: quite a few new error messages today when booting the emulator: http://paste.ubuntu.com/7549208/, not sure yet what caused that
<rsalveti> probably in any touch image
<ogra_> rsalveti, likely systemd transition fallout
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/54.changes .... cgmanager, systemd/udev and sysvinit changed
<Unit193> Noskcaj: -S -sa
<Noskcaj> thanks
<Unit193> -sa            uploaded source always includes orig.
<ogra_> rsalveti, at least my flo still boots after upgrade ... phew
<rsalveti> haha, yeah, emulator booted fine as well, but with some additional error messages
<ogra_> you shocked me for a moment :P
<xnox> rsalveti: mostly harmless, temporary until a reliable solution is available to re-enable parallel boot/shutdown again.
<rsalveti> xnox: alright :-)
<pitti> rsalveti: yes, known; I'll file a bug about this now, we couldn't fix it yesterday
<rsalveti> pitti: thanks
<pitti> RAOF: did you see that colord is depwait on argyll?
<Noskcaj> rsalveti, I'm trying to make a ppa for the upower 1.0 transition. Any idea why powerd is FTBFS? https://launchpadlibrarian.net/176601456/buildlog_ubuntu-utopic-amd64.powerd_0.15%2B14.10.20140428-0ubuntu1ppa1_FAILEDTOBUILD.txt.gz I ask since you had the most recent commit to it
<RAOF> pitti: In Ubuntu? Yeah.
<RAOF> pitti: I'll need to disable that bit for Ubuntu.
<pitti> RAOF: hm, conditional build deps sound tricky
<Noskcaj> pitti, Do i need to do anything to make python-dbusmock build for upower 0.99?
<RAOF> pitti: Actually, no; it only generates extra files to ship alongside existing ones in colord-data
<pitti> Noskcaj, rsalveti: that souds like fallout from the platform-api API change of returning floats in out args instead of return vallues
<pitti> Noskcaj, rsalveti: (as float returns are weird on arm with Android, it's using a differetn calling convention)
<Noskcaj> um...
<Noskcaj> I think i'll leave that till last then
<pitti> Noskcaj: in principle not; the test suite calls upower --version and based on that decides whether to expect/emulate the 0.9 or 1.0 API
<pitti> Noskcaj: I tested it against upower 0.99 back then; so unless the API changed again in 1.0 it sohuld still work
<Noskcaj> 1.0 isn't out yet, just making a ppa to help (at the request of ubuntu-gnome)
<infinity> xnox: procps is in the buildd chroots because initscripts (and its deps) is, because initscripts should be essential, except we screwed up. :P
<ogra_> infinity, enough that we cant make the touch images writable anymore :P
<ogra_> which breaks pretty much all testing in the lab
<infinity> ogra_: Hrm?
<ogra_> infinity, mountall remounts the fs readonly since today ... regardless if it is supposed not to
<infinity> xnox: procps is neither essential or build-essential, though, if that was what you were asking in a roundabout way.
<infinity> ogra_: How does the content of a buildd chroot have anything to do with that?
<ogra_> i assume thats related to the initscripts/procps/sysvinit changes from yesterday
<ogra_> infinity, "except we screwed up" ... i was referring to that part of the line ;)
<xnox> infinity: thanks for details, luckily we didn't need procps chroot surgery as it didn't manage to slip into -release pocket and we deleted in from -proposed early enough.
<infinity> ogra_: Totally unrelated screw up.
<xnox> infinity: working on a patch to startpar at the moment, to make it become aware of upstart tasks, instead of modifying all upstart jobs which are tasks and have an initd script.
<Noskcaj> pitti, https://launchpadlibrarian.net/176602234/buildlog_ubuntu-utopic-i386.python-dbusmock_0.10.1-1ppa1_FAILEDTOBUILD.txt.gz
<pitti> Noskcaj: ok, so apparently it changed a bit more; can you please file a bug about this with a pointer to your PPA? can't do that right now (sprint)
<Noskcaj> ok
<pitti> thanks
<xnox> pitti: http://paste.ubuntu.com/7549587/ of which 'rc' is false possitive, 'udev-finish' is fixed, 6 - to go.
<xnox> pitti: or we can do a startpar patch to consider tasks as always done and ready.
<pitti> xnox: oh, that looks manageable
<pitti> xnox: I'd prefer a solution in upstart to track whether a task ever ran, but we need something today to unbreak the phone builds
<pitti> xnox: ogra says they are completely broken
<xnox> pitti: well, i have this solution -> (let me pastebinit)
<xnox> pitti: http://paste.ubuntu.com/7549610/
<pitti> xnox: WEXITSTATU"S" -- and erk system() :)
<xnox> pitti: =) didn't compile yet
<xnox> pitti: in that code, it does 'initctl status' but it should also check for 'not a task'
<xnox> pitti: cause we should be resiliant to people who happen to have 3rd party things that have both an upstart job and init.d script.
<ogra_> stgraber, poke ... could we rip out image 54 from the server ? people are not able to make the image writable anymore which will block quite a few peoples work i suspect (not to talk about the lab just exploding in flames)
<pitti> xnox: so this will basically assume that upstart is always fast enough to execute task dependencies before startpar gets to it?
<xnox> pitti: it assumes that events do happen, ahead of executing rc, yes. That is true on boot, in ubuntu, because we mostly do udev-based boot (instead of initscript based assembly of raid/lvm2 etc.). And also true on shutdown/stop -> all tasks are stopped.
<xnox> pitti: (there is a small amount of upstart tasks which kick in on shutdown, but there is very little of those with no init.d scripts, i believe)
<pitti> xnox: so yes, even if it might not be entirely correct it still sounds like progress over the current situation
<pitti> xnox, ogra_: let me try what happens if we empty out all the affected init.d scripts
<ogra_> ++
<xnox> pitti: one simply shouldn't call update-rc.d on them, or we fix startpar/sysv and test&land it.
<xnox> ogra_: when is the next image build?
<ogra_> xnox, when we have a fix ;)
<xnox> ogra_: ack
<pitti> ogra_: just to avoid panic for everyone who reads u-phone@: that's got nothing to do with systemd :)
<ogra_> pitti, it doesnt ?
<pitti> ogra_: no, that's about catching up with Debian's sysvinit/insserv/upstart policy
<ogra_> pitti, and thats not part of the systemd transition ?
<pitti> ogra_: it's a pre-pre-pre-requisite, but something which we have to do anyway
<ogra_> right, indeed :)
<pitti> non-insserv for sysvinit has been deprecated by Debian a long time ago, so at some point we need to follow unless we also want to start maintaining init.d script runlevels ourselves
<pitti> ogra_: the fun thing is that none of this is a problem when you actually do boot with systemd :)
<pitti> ogra_: but anyway, be assured that we won't switch the phone to systemd anytime soon
<ogra_> pitti, yeah, i annoyed slangasek enough with this question this week already ;)
<slangasek> ogra_: weren't you /in/ the UDS session where we decided this? ;)
<ogra_> slangasek, heh, yeah, i guess :)
<ogra_> pitti, sent a followup mail to clearify a bit
<pitti> ogra_: this seems to help quite a bit:
<pitti> for f in checkroot.sh checkroot-bootclean.sh checkfs.sh mountkernfs.sh mountdevsubfs.sh mountall.sh mountnfs.sh mountnfs-bootclean.sh mountall-bootclean.sh; do echo '#!/bin/true' | sudo tee /etc/init.d/$f; done
<pitti> ogra_: but NB this is not something which we ever want to put in our packages, but it might be a quick'n'dirty workaround for the image builds
<pitti> ogra_: this essentially disables the init.d scripts which now get called although they shouldn't
<pitti> but touching conffiles and stuff
<ogra_> cant we just rm them ?
<ogra_> pitti, we dont care about conffiles on system-images ... (well only at build time)
<pitti> ogra_: that'll break updare-rc.d, so any package you try to install will cause failures from insserv
<pitti> ogra_: right, hence my proposal to change them to /bin/true
<pitti> xnox: inline comments in MPs!
<slangasek> I realize this is a quickfix, but that sounds really horrible
<ogra_> pitti, works fine ...
<ogra_> slangasek, we wont promote any image before a reaal fix lands ... thats just to get developers usable development systesm again
<pitti> slangasek: yes, I never want that to get near any .deb, just as a post-install fix in image builds
<ogra_> *systems
<pitti> slangasek: I'm reviewing xnox' MP now, but I have a feeling we won't land that in an hour
<slangasek> pitti: I don't understand how you expect that to help anyway, these are the same scripts that already source /lib/lsb/init-functions so are a no-op on upstart
<ogra_> i'll stuff it in a live-build hook script
<pitti> slangasek: they aren't; the LSB hook only helps for "sudo /etc/init.d/..."
<pitti> slangasek: but rc/upstart call them as /etc/rc?.d/Snnfoo, which isn't being recognized by the hook
<slangasek> um
<slangasek> then that lsb hook is broken and does not do what I understood it was meant to do
<pitti> slangasek: initially I thought that was a bug, but xnox convinced me it's on purpose
<xnox> slangasek: the hook was to fix, users/puppet/etc calling /etc/init.d/
<ogra_> seems we find truckloads of wormy cans this week :)
<slangasek> xnox: except our insserv transition also relied on this lsb hook providing us cover
<pitti> slangasek: I tried to "fix" the LSB hook to do a readlink first, then it actually ignores the script; but I got a hung boot with that
<slangasek> xnox: for the window between running update-rc.d for the do-not-run init script, and converting to insserv
<slangasek> since that's the order it has to happen in
<slangasek> sorry, I assumed that this is what the lsb init hook was doing
<pitti> yes, so was I
<slangasek> (despite having read the code earlier, I forgot it didn't)
<pitti> slangasek: and I still think we should do that somehow; if not through the LSB hook then at least some moral equivalent
<slangasek> it should just be in the LSB hook, we shouldn't add even more moving pats
<slangasek> parts
<xnox> slangasek: what do you think about the patch against sysvinit to consider task jobs as done?
<xnox> well starpar component.
<pitti> slangasek, xnox: one idea would be to disable startpar again until we fixed the handling of tasks properly, and instead ignore init.d scripts in /etc/init.d/rc if there is a corresponding upstart job
<slangasek> xnox: so I understand that the current LSB hook *doesn't* make them no-ops when called directly; but what's the reason to *not* make them no-ops?
<slangasek> xnox: i.e., pitti said you convinced him it's "on purpose"
<slangasek> xnox: startpar patch> well I hope you aren't expecting me to tell you it's beautiful ;)
<xnox> slangasek: calling via /etc/rc* -> can & should be no-ops. calling via /etc/init.d* -> should do what the user asked to do
<slangasek> xnox: we talked earlier about startpar timeouts; wouldn't a timeout fix the problem without introducing a slowdown for users whose systems aren't broken?
<jpds> Noskcaj: Probably.
<jpds> Noskcaj: Feel free to update it, otherwise I'll look into it later.
<xnox> slangasek: hahaha. Let me read more about the timeouts.
<slangasek> xnox: ok.  In that case, you agree that the lsb hook should be fixed for this?
<Noskcaj> jpds, I don't really understand the change, i'm just hoping it fixes the ftbfs. I'll leave it for you
<xnox> slangasek: yes. As in, init.d behaviour stays the same (call the real action), rc*.d/[SK]\d* -> is a no-op.
<jpds> Noskcaj: Oh, that's good to know, thanks.
<ogra_> cjwatson, mind takeing a quick look at http://paste.ubuntu.com/7549809/ ?
<ogra_> -e
<slangasek> xnox: ok.  Can you put that together and I'll review?  And is that sufficient to unbreak the phone image?
<ogra_> slangasek, xnox, so should i hld back the above hack ?
<ogra_> *hold
<xnox> slangasek: let me confirm both of those.
<slangasek> ogra_: I estimate 1.5h before we can land this (proper) fix
<ogra_> hmm, 1.5h + upload + propagation + image-build ... thats most likely the whole day we will block landings ...
<ogra_> OTOH we would only be 1.5h earlier if i upload now ...
<pitti> xnox, slangasek: added a blurb to the MP
<ogra_> sil2100, thoughts ? ^^
<pitti> xnox: calling via /etc/rc* -> can & should be no-ops. calling via /etc/init.d* -> should do what the user asked to do
<sil2100> ogra_: let me think
<pitti> xnox: so the LSB hook is behaving exactly opposite now
<plars> sil2100: ogra_: are we still considering pulling the image out of s-i? there's still a risk I guess at the moment that someone updates to it
<ogra_> plars, we cant really fix people that already upgraded ... going forward with a fixed image fast would be better
<pitti> xnox: but I don't think that running /etc/init.d/foo should actually do that; I think running the upstart job instead is the right thing to do, no?
<pitti> slangasek, xnox: I'll re-try with adding the missing readlink to the LSB hook; it hung yesteday
<slangasek> pitti: we shouldn't drive execution of the upstart job, at boot time, from startpar
<slangasek> (or from rc)
<sil2100> ogra_, plars: I wouldn't worry about it that much, as people should be aware of that devel images can be broken by principle
<pitti> slangasek: yes, fully agreed
<ogra_> proposed you mean :)
<slangasek> it's better to skip it entirely in this case than to risk running two copies of a daemon, or worse
<sil2100> ogra_: I must say that I'm not particulary fond of landing a quick-fix to gain like only 1.5h
<sil2100> ogra_: right ;) Typo
<sil2100> (big one)
<pitti> slangasek: WDYT about skipping init.d scripts in the non-startpar portion of /etc/init.d/rc if there's an upstart job?
<ogra_> sil2100, right, but seeing that there is still a discussion about the proper way of fixing it here it might probably be more than 1.5h
<pitti> slangasek: and keep startpar disabled for now (as in current utopic)
<sil2100> ogra_: let's meet on the landing meeting and talk about it then
<pitti> slangasek: that should essentially do what we always did
<sil2100> It's like in 7 minutes
<cjwatson> ogra_: err, what.  is it really quicker to do this madness than to fix the init scripts in question?
<sil2100> ogra_: how does your workaround fix look like?
<slangasek> cjwatson: the init scripts aren't "broken"
<cjwatson> this is out of the blue for me
<pitti> the upstart jobs are fine, so are teh init scripts; it's startpar not knowing about upstart tasks (nor upstart having a way to tell startpar) which is the problem
<slangasek> cjwatson: we reintroduced the init scripts, relying on the lsb init-functions hook to make them all no-ops
<pitti> hence my proposal to keep startpar disabled until we fix that properly
<slangasek> (or pass-throughs)
<pitti> can we meet in person somewhere?
<slangasek> pitti: people have been looking for you and not finding ;)
<pitti> ballroom
<pitti> I can come someplace else
<pitti> where are you?
<slangasek> we're in studio 3, but xnox just went again looking for you; let's come there
<pitti> ack, on my way
<slangasek> pitti: no, we'll come to you
<pitti> ack
<xnox> pitti: i'm in studio 3.... where abouts are you?
 * xnox is also attached to a power socket at the moment.
<slangasek> xnox: can you come to the ballroom?
<xnox> slangasek: yes
<pitti> xnox: ballroom
<slangasek> pitti: he's here
<pitti> xnox: I'm testing an LSB hook update, then we can compare ideas
<xnox> pitti: oh. ok.
<sarnold> pitti,xnox: 1322296 init.d file for procps
<pitti> sarnold: hm, procps already has an init. script?
<ogra_> xnox, FYI i uploaded the livecd-rootfs hack right now so take your time, will be enough if it lands today and without hurry
<infinity> pitti: The log in the bug report shows it was with the broken procps that was removed from proposed.
<sarnold> pitti: oh, interesting, the bug report is about 1:3.3.9-1ubuntu4 but launchpad says 1:3.3.9-1ubuntu3 is the newest for utopic..
<sarnold> did 4 make it to -release or was it only ever in -proposed?
<infinity> sarnold: Only proposed, AFAIK from backscroll.
<infinity> A fresh upload to supersede it should probably still be done, if the thing that broke it is no longer broken.
<infinity> Oh, the thing that broke it was xnox. :P
<sarnold> lol
<pitti> infinity: not necessary any more
<pitti> it's really wrong to un-task all our upstart tasks
<xnox> ogra_: please no.
<ogra_> xnox, no what ?
<xnox> ogra_: uploading livecd-rootfs.
<xnox> pitti: http://paste.ubuntu.com/7550129/
<ogra_> xnox, already happened ... (and agreed on by all involved parties)
<xnox> ogra_: slangasek, pitti and myself?!
<xnox> ogra_: and cdimage team?
<xnox> ogra_: please stop ignoring !landing
<ogra_> xnox, yes
<pitti> ogra_: yeah, I thought you had a way to modify the images that doesn't involve uploads; but *shrug* that's ok for now
<pitti> once the the fixed lsb lands we can take out that hack again
<ogra_> xnox, colin and steve were in the landing team meeting
<ogra_> where we decided that
<xnox> ogra_: cool.
<pitti> it's really moot to discuss that now..
<ogra_> xnox, i'll revert it immediately if your fix is in ... no worries
<ogra_> xnox, the point is that we need test results for a certain set of landings in 54 and the archive moves underneath us ... that was the base of this decision
<RAOF> infinity: Are you around anywhere?
<pitti> xnox: http://paste.ubuntu.com/7550154/
<slangasek> xnox: sorry, I did agree with ogra+LT that they should proceed with the interim fix - don't worry about it, just make the interim fix irrelevant ;)
<infinity> RAOF: Not really.  I seem to be broken, and am therefor hiding in my room.
<RAOF> infinity: Sorry to hear that.
<xnox> ev: yes, my merge proposal has inline comment.
<pitti> ogra_, slangasek: FYI, this will fix the phone without the crazy livefs-build hack: https://launchpad.net/ubuntu/+source/lsb/4.1+Debian11ubuntu8
<pitti> I'll also do a sysvinit upload to remove some noise, but that's mostly cosmetical
<pitti> sil2100: you want that for the next image build: https://launchpad.net/ubuntu/+source/lsb/4.1+Debian11ubuntu8
<pitti> sil2100: and if you so please, we can revert the temporary hack from https://launchpad.net/ubuntu/+source/livecd-rootfs/2.215
<infinity> pitti, xnox: I might nitpick that that now runs "initctl version" twice for no good reason sometimes.
<pitti> infinity: when?
<infinity> pitti: Oh, wait, no, I guess not.
<pitti> it sucks enough that we have to call it for every init.d script already
<infinity> pitti: I didn't read the tests right.
<infinity> pitti: So, it's just ugly code duplication, but not actually running twice.
<pitti> wishlist: provide a test for "am I running upstart" which just involves a stat
<pitti> that'll go away again once we made startpar friends with upstart tasks, but that still seems to be disputed, and not trivial to do
<sil2100> pitti: thanks for the info!
<pitti> sil2100: yw; what a mess :/
<slangasek> pitti: would really prefer we focus on sunsetting upstart and its related compatibility code instead of trying to optimize the per-init-script upstart check that is only relevant when *not* using startpar
<slangasek> (which we should enable soon)
<pitti> slangasek: yes, agreed
<pitti> slangasek: until then it shouldn't matter that much whether we use startpar or not, but like that we'll probably see some boot time regression
<pitti> but for enabling startpar we'll have to adjust upstart (unless anyone has a better idea?)
<pitti> or the upstart starpar bridge (I don't fully know how that works, I just understood that it doesn't run all the time right now)
<slangasek> pitti: I'd like to understand why we have as many task jobs as claimed that are also init scripts
<pitti> slangasek: we have ~ 100 tasks; I didn't yet check which of those are also being used as dependencies of init.d scripts, but presumably not that many
<pitti> slangasek: certainly 10 or less
<slangasek> right - most tasks should not have corresponding init scripts
<pitti> the problem is not that, but init.d scripts which *depend* on an upstart task
<slangasek> yes
<slangasek> well, both are problems
<slangasek> because *any* init scripts shadowed by tasks would result in startpar waiting forever
<slangasek> (the procps problem)
<slangasek> init.d scripts really should not be depending on an upstart task, and I'd rather we fix this by exposing a non-task upstart interface in the package
<slangasek> because this affects shutdown too, not just startup
<pitti> slangasek: i. e. what we started with http://launchpadlibrarian.net/176539305/systemd_204-10ubuntu7_204-10ubuntu8.diff.gz ?
<pitti> slangasek: it feels like a workaround to me, but indeed it's the only other way that I see aside from telling apart "never run" from "ran at least once"
<slangasek> pitti: it's a workaround, it's a bit more work on different packages but this is all a one-off and requires much less design than trying to change upstart behavior or making deep changes to upstart/startpar interaction
<pitti> slangasek: ok; WFM
<xnox> slangasek: we can reorganise our jobs, but 3rd parties that ship both init.d script and upstart task can doom boot & shutdown still.
<slangasek> pitti: and as for third-party jobs, I mentioned to xnox this morning that properly supporting startpar's timeout functionality for these jobs would handle that
<xnox> slangasek: right.
<xnox> slangasek: i didn't look into timeout yet, but it appeared that it was timeout for interractive jobs only, of which all upstart jobs are not.
<xnox> but maybe i'm wrong.
<slangasek> task+init.d would be a "local configuration error", but the failure scenario would just be that startpar delays the boot, then the system boots up, then the task is considered "already stopped" at shutdown (which is correct)
<slangasek> xnox: ah
<pitti> stgraber: would you mind fast-tracking lsb? enough tests have succeeded now to show that it should be ok, and we tested it on iron, tablet, VM, and chroot
<BluesKaj> 'Morning
<pitti> or cjwatson ^
<xnox> pitti: nut is failing... http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lsb
 * xnox check if it has a hint.
<pitti> xnox: yes, bug 1291378, retried
<ubottu> bug 1291378 in nut (Ubuntu) "test_CVE_2012_2944 autopkgtest is racy" [High,Confirmed] https://launchpad.net/bugs/1291378
<pitti> that's the one I always have to retry umpteen times
<pitti> I hope it's just a bad test, not a bad vuln fix
<infinity> pitti: Hinted.
<stgraber> infinity: gah, you're too fast :)
 * stgraber goes for some food instead
<infinity> pitti: I'm not sure what to make of http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-tetex-brev/7/
<infinity> pitti: It looks like amd64/i386 are done, but the job still seems to be "running".
<infinity> pitti: And, odder still, there's a reference to a ppc64el host in the corner?
<ogra_> xnox, how is the migration looking ?
<xnox> ogra_: migrated 41 minutes ago.
<ogra_> perfect !
<ogra_> let me revert the hack then
 * xnox feels like personal service rmadison =)
<xnox> sergiusens: cjwatson: rsalveti: bug #1324889
<ubottu> bug 1324889 in click (Ubuntu) "click chroot should use -gles qt packages in the i386 chroot" [Undecided,New] https://launchpad.net/bugs/1324889
<sergiusens> thanks
<rsalveti> xnox: thanks
<xnox> sergiusens: checked the code, it installs the stock variant only, which is gl on i386 =(
<xnox> tedg: https://code.launchpad.net/~jamesodhunt/upstart/cgroups-mergeable-with-upstart-async
<pitti> infinity: the reference to the ppc64el host is a jenkins stupidity; it's running the "meta-job" which binds i386 and amd64 on an arbitrary node (but then doens't actually physically run stuff there)
<pitti> infinity: thanks for hinting
<Chipaca> https://wiki.ubuntu.com/Chipaca/PPU \o/
<Chipaca> sergiusens: are you an ubuntu dev?
<xnox> stgraber: are you in the unified mobile & desktop session now?
<sergiusens> Chipaca: no; I'm not; just a ppu
<xnox> stgraber: room 3, questions about lxc are raised...
<Chipaca> sergiusens: so not that much point in you endorsing my ppu, i guess
<Chipaca> hmmm. dobey? ev?
<stgraber> xnox: ok, I'll come then
<infinity> siretart: FWIW, there's a mention in that ppc64el bug that "qemu doesn't support it yet"... qemu in trusty-updates can happily boot and install (and run) ppc64le in full emulation (ie: on x86).
<infinity> siretart: s/bug/patch/
<xnox> sergiusens: i need to talk to you about ubuntu-emulator and how we wan it to handle booting normal or recovery, and how to communicate from the emulator to suggest what the next boot should be.
<xnox> i have a few options now.
<sergiusens> xnox: let's do that now
<sergiusens> xnox: where can I find you?
<xnox> i am outside studio 3 now.
<xnox> sergiusens: you?
<sergiusens> I'll go there
<dobey> mvo: what is the path for the file i need to change for packagekit?
<mvo> dobey: /etc/PackageKit/PackageKit.conf
<dobey> i don't have that. is it not from a default-installed package?
<pitti> bdmurray: apport 2.14.3 uploaded
<xnox> Saviq: hey, you about?!
<xnox> Saviq: looking at cgo and i would want to try a few things with you.
<xnox> Saviq: i think it's trivial to enable it crosscompilation.
<goarilla> anyone here that navigated the ubuntu gfxboot inc configuration files ?
<goarilla> how to I disable the F1,F2,F3 buttons and language overlay ?
<goarilla> I have gfxboot-theme-ubuntu unpacked
<brendand> cjwatson, is it just me or is click buildsource pretty broken?
<brendand> cjwatson, i get varying exceptions, depending on what i try
<Noskcaj> jdstrand, Could you merge telepathy-mission-control-5 sometime soon? The new debian release stops the use of upower
#ubuntu-devel 2014-05-31
<siretart> wbs, who provided the patch, mentioned that he isn't entirely sure if the code actually works on ppc64el, running the fate testsuite would be great but none of us has access to some porter machine for that
<siretart> infinity: ^^
<Logan_> rsalveti: are you going to merge in zoneminder from Debian experimental for the libav10 transition?
<siretart> sorry for the alsa mess. I have just cleaned it up
<Logan_> xnox: are you planning on merging qutecom?
<Logan_> xnox: also, do you think we can try syncing paraview and seeing how the buildds handle the parallel build? c.f. http://changelogs.ubuntu.com/changelogs/pool/universe/p/paraview/paraview_4.0.1-1ubuntu1/changelog
<darkxst> cjwatson, is there an easy way to avoid "Cannot handle more than one kernel for generic (3.13.0-24-generic
<darkxst> 3.13.0-27-generic)!" when live-building trusty images?
<darkxst> cjwatson, fwiw I am trying to build with livecd-rootfs, using PROJECT=ubuntu-gnome
<cjwatson> darkxst: sounds like maybe -updates isn't added early enough or something ... would need to see the full log to make a better guess (FWIW I won't be around too much this weekend)
<darkxst> cjwatson, ok, no rush, I will file a bug with the full logs
<BluesKaj> 'Morning folks
#ubuntu-devel 2014-06-01
<teward> question: is there a reason libc6-dev-i386 is an amd64 package, and libc6-dev-amd64 is a i386 package, and not the other way around?
<teward> (in Trusty)
<Logan_> teward: because they're for developing for the other architecture
<teward> Logan_, ahhh, that explains it, thanks.
<Logan_> Riddell: could you please merge k3b for the libav10 transition?
<teward> Logan_, okay, next question: how come there's no /usr/include/sys/ symlink or otherwise on i386 or amd64's libc6-dev package(s)?
<teward> based on #ubuntu i'm seeing that that lack of a symlink or folder is causing some source-code-compiling problems
<teward> psusi, Logan_: if either of you have any insight... ^
<BluesKaj> Howdy folks
<cjwatson> teward: It's in /usr/include/x86_64-linux-gnu/sys/ etc. (and similarly for i386).  /usr/include/x86_64-linux-gnu/ (etc.) is on the default include path so if this breaks anything it's generally the fault of a broken build system that wrongly thinks it knows better than the compiler.
<cjwatson> It's that way as part of multiarch support.
<mapreri> stgraber: I packaged pencil2d in debian, and now it's in ubuntu. My first intention was to remove pencil from ubuntu and keep only pencil2d, but pencil is seeded in edubuntu. could you test pencil2d to see if it fulfil your needs and in the case change the edubuntu seeds? (see #1306960) if you want I can send you an email
<mapreri> bug #1306960
<ubottu> bug 1306960 in pencil (Ubuntu) "update to pencil2D" [Undecided,In progress] https://launchpad.net/bugs/1306960
<stgraber> mapreri: ok, I'll take a look. Feel free to nag me again if I haven't done so in a week :)
 * highvoltage tries out pencil2d
<stgraber> highvoltage: ah, even better if you can do that :)
<highvoltage> stgraber: looks good, should I through it in a merge request or do you want to do it directly?
<stgraber> highvoltage: I'll update the seed directly, thanks
<highvoltage> stgraber: cool
<stgraber> highvoltage, mapreri: seed updated. Refreshing edubuntu-meta now and that should be all we need to drop pencil.
<highvoltage> great. thanks for checking your package(s) in ubuntu, mapreri!
<mapreri> stgraber: highvoltage: thank you for a so quick reply. I mind if I should upload pencil as a dummy package... what do you think?
<orbisvicis> ubuntu doesn't spindown external usb-powered hard drives on shutdown. leads to drive damage. should I file a bug, is it in upstart ?
<orbisvicis> so, which folder in /etc/initramfs-tools/scripts is responsible for the shutdown script ?
<teward> cjwatson, that fails with some third-party sources, where the instructions and build scripts refer to /usr/include/sys/something.h
<teward> cjwatson, as observed in #ubuntu at the time of my question.
<teward> cjwatson, that being said, I understand the reasoning for it as-is, but it seems confusing for non-devs and non-power-users why that's the case
<infinity> teward: Things that reference header locations absolutely are pretty much broken by design.  But it would be more helpful to see the actual problem code, maybe it's a third-party application we could, like, help and send a patch for?
#ubuntu-devel 2015-05-25
<hyperair> what's the standard practice for ubuntu-sru these days? do we just upload, or do we still have to ask for permission first?
<infinity> hyperair: You never had to ask for permission.  But if it's a complex or possibly controversial change, it can save you some effort to get a "no" before you do something that will just get rejected.
<hyperair> infinity: oh, i thought there was some kind of ubuntu-sru clearance i needed before uploading to -proposed
<hyperair> okay, i'll just upload it there then
<infinity> hyperair: Well, your upload doesn't go to proposed, it goes to a queue, where we then review it.
<hyperair> infinity: right
<hyperair> infinity: by the way, can i have one upload get copied to newer stable releases?
<infinity> hyperair: Depends.
<hyperair> this is sigx
<hyperair> https://launchpad.net/ubuntu/+source/sigx
<infinity> hyperair: If the previous package was the same version in, say, T, U, V, then I'm okay with an SRU to T also being copied forward.
<hyperair> the versions for trusty upwards are all the same except wily
<hyperair> infinity: alright, i'll do just the T upload then
<hyperair> thanks
<infinity> hyperair: No one will automatically do that, though, so when it's released, you'll want to remind someone.
<hyperair> okay
<hyperair> who, though? archive admin or ubuntu release?
<infinity> hyperair: Actually, easier to remind someone when it's accepted.  Can copy forward to *-proposed at that point.
<hyperair> alright
<infinity> hyperair: Me, I guess.
<infinity> hyperair: But, technically, ubuntu-sru or ubuntu-archive could do it.
<infinity> (Well, technically, you could do it yourself too, but it would get caught in the queues again, which is a bit confusing)
<hyperair> ah
<hyperair> alright
<pitti> infinity: apport autopkgtest> it fails on amd64 (i. e. the nova cloud runner) on some weird apt confusion; I couldn't yet reproduce this locally yet, and ssh'ing into the machines seems to be "hard" :(
<cyphermox> good morning!
<mdeslaur> hi cyphermox
<menace> Hi, how will Snappy handle debconf-parameters?
<menace> or where can i ask questions about snappy? :)
<infinity> doko__: Has anyone bugged you about gccgo being broken on powerpc in wily?
#ubuntu-devel 2015-05-26
<Logan> is there any reason why my MP [1] isn't showing up in the Sponsoring Overview [2]?
<Logan> [1] https://code.launchpad.net/~logan/ubuntu/wily/python-idna/2.0/+merge/260031
<Logan> [2] http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html
<pitti> Good morning
<Mirv> Logan: just time, now it's there
<Logan> ah, thanks :)
<dholbach> good morning
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily 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: didrocks
 * dholbach hugs didrocks
 * didrocks hugs dholbach back
<didrocks> Mirv: do you need an ubuntu-touch.wily upload now or prefer to wait?
<Mirv> didrocks: the two MP:s would be good to land now already
<Mirv> didrocks: thanks for merging them
<didrocks> Mirv: yw! ok, uploading
<Mirv> excellent!
<Laney> cjwatson: Does archive_base/default in germinate-update-metapackage's update.cfg support multiple archives like /arch does (per g-u-m(1))?
<cjwatson> Laney: Yes.
<Laney> cjwatson: Ta. Wasn't entirely clear to me from the manpage
<Laney> ogra_: Maybe this is useful to you
<ogra_> Laney, you mean to the phone people :)
<Laney> teflon hands
<ogra_> hah
<Laney> who wants this information?
<ogra_> cjwatson, what Laney wants is a seed for the vivid+overlay phone PPA ... i wonder if that actually makes sense now that we will use that setup long term
<ogra_> Laney, if only i knew :) i guess for the interim thats still me
<Laney> Well you've just seen confusion with the seed branches; I was wondering if we could avoid that
<ogra_> long term the phone team needs to grow some core-devs or we need to make it easy for sponsos
<ogra_> +r
<cjwatson> ogra_,Laney: I'd suggest just treating that as a continuation of ubuntu-phone.vivid
<cjwatson> Laney: manpage> bug welcome
<Laney> nod
<cjwatson> (or git mp if you want to be experimental)
<cjwatson> I can find out if I get useful mail! :-)
<Laney> I'll put it on the list, got a few things to do first though
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily 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:
<rbasak> pitti: I'm stealing the apache2 merge. I trust that's OK?
<pitti> rbasak: it's okay, plus "thank you!" :-)
<pitti> rbasak: I earned tons of merges from drive-by systemd fixes, some library transition rebuilds and other stuff, always happy to lose some of them :)
<mitya57> Mirv: do you know if Stephen's suggestion in https://codereview.qt-project.org/112053 (the last comment) will fix LP: #1457840?
<ubottu> Launchpad bug 1457840 in qtbase-opensource-src (Ubuntu) "5.4.1+dfsg-4ubuntu1 causes dependencies to complain about the -fPIC required for reduce-relocations" [Critical,Fix released] https://launchpad.net/bugs/1457840
<jamespage> please could an  archive admin bump python3-cryptography and python3-hacking to main for wily - they are binary only movements - cheers!
<pitti> jamespage: yep, will do, they are on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
<jamespage> pitti, indeed they are - just nudging as working an SRU that I'd like to land into wily first - but I'm blocked on dependency chain right now
<jamespage> (and thanks)
<pitti> lputils.PackageMissing: Could not find binaries for 'python3-cryptography/None' in wily-proposed
<pitti> le huh?
<pitti> oh, nevermind -- these binaries themselves aren't in -proposed
<pitti> jamespage: done
<jamespage> pitti, ta
<xnox> doko_: gcc's 5.1 -fno-semantic-interposition causes testsuite failure in libvirt
<xnox> were you considering to enable it by default?
<doko_> xnox, is there an open issue? no, I'd like to avoid diverting from upstream
<xnox> doko_: ok. at the moment only discussing it on libvirt mailing list.
<xnox> the option seems very nice. but not sure about the fallout amount, especially since it appears to manifest at runtime, rather than build-time warning or some such.
<xnox> doko_: also created mailing list.
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily 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: mdeslaur
<mpt> diwic, hi. Is the HDMI audio situation still as you described in <http://voices.canonical.com/david.henningsson/2012/04/14/audio-over-hdmi-and-displayport-in-ubuntu-12-04/>, where you canât tell whether audio should go to an HDMI-connected display?
<doko_> xnox, well, turning this on by default would be wrong
 * dholbach hugs mdeslaur
<xnox> doko_: yeah, also binutils breaks.
<diwic> mpt, most of the stuff still holds
<diwic> mpt, even for newer stuff like haswell and broadwell, there are usually several audio ports
<diwic> mpt, but I guess slightly more often the vendors are polite enough to mark two out of the tree as unused
<diwic> mpt, I'm not sure that answers your question - could you be more specific?
 * mdeslaur hugs dholbach
<sladen> nd the other 16 square metres,...?
<sladen> meh
<rbasak> pitti: you might be interested in bug 1457957. I tagged it systemd-boot as it's a consequence of the switch, but it's perhaps an upstream issue to keep up.
<ubottu> bug 1457957 in puppet (Ubuntu) "puppet uses upstart for service status checks in vivid" [Undecided,Confirmed] https://launchpad.net/bugs/1457957
<pitti> rbasak: thanks for the heads-up. I followed up
<mpt> diwic, for the pocket PC, when you connect a phone to an MHL display, normally youâll want audio to be played through that displayâs speakers. If that isnât automatic, weâll need more settings UI than if it is automatic.
<ogra_> mpt, and how do you know that MHL display is a display with physical speakers attached ?
<ogra_> a normal monitor with MHL wont tell you ... and will most likely not have any speakers
<ogra_> (a TV with MHL wont tell you either but that will at least have builtin speakers)
<rbasak> pitti: thanks. Also bug 1457886 - probably invalid since kernel commandline is used (and permitted to be used) for anything, including for plymouth(?) to pay attention to the "splash" argument?
<ubottu> bug 1457886 in init-system-helpers (Ubuntu) "Init program start with unknown arg splash " [Undecided,New] https://launchpad.net/bugs/1457886
<mpt> ogra_, yay, itâs nice to know that new hardware interfaces repeat the mistakes of their predecessors :-]
<rbasak> pitti: I'm not confident enough in the internals there to triage that though, although I think I know what's going on.
<ogra_> mpt, heh, yeah ... well, i dont think the designers of the EDID specification thought about routing audio through video cables when they designed EDID back when VGA was a thing :)
<ogra_> but even if the EDID info could tell you that the display is audio capable you wont know if there are actual pysical speakers
<mpt> Yeah, itâs not like any displays had built-in speakers in 1994
<diwic> mpt, to sum up, the problems are two-fold here - one is that we have some "unused" HDMI ports that the driver reports as being there but unconnected. That can likely be fixed on a per-hardware basis, so if we do a pocket PC we can put in a driver patch for that.
<pitti> rbasak: this looks like serious PEBCAK; I followed up and subscribed, but probably non-sense
<diwic> mpt, what ogra_ is talking about is harder, i e, figuring out whether or not there are speakers on an HDMI (or DP, or MHL) connection.
<diwic> mpt, that said I'm not very familiar with MHL at all.
<ogra_> i thionk you shoould keep audio on the phone spakers for now
<mpt> diwic, so, we will need UI for whether to use the displayâs speakers or not
<ogra_> and rather offer a UI to the user to switch back and forth
<ogra_> or a popup pn MHL connection asking if you want to re-route the sound to the display
<rbasak> pitti: I was under the impression that the kernel gave /sbin/init the kernel commandline in argv too? Maybe not. Anyway, my uncertainty is why I referred to you. Thanks :)
<pitti> rbasak: it looks like he tried something like init="/sbin/init splash"
<diwic> mpt, like the unity-system-settings in v14.04 desktop already does, so I'm assuming your talking about something else?
<pitti> rbasak: ah, it indeed seems to do that (everything after init=)
<pitti> rbasak: but then I still fail to understand what the problem is
<mpt> diwic, yes, ubuntu-system-settings on the phone
<diwic> mpt, ok
<rbasak> pitti: what the problem is> yeah - inits are designed to get random stuff from the kernel commandline, and random stuff uses the kernel commandline. So traditionally not-understood arguments are just ignored and that should be fine.
<cyphermox> good morning!
<mdeslaur> hi cyphermox
<cyphermox> hey mdeslaur
<smoser> Laney, gnome-terminal "Apply fix from Ed Catamur to wait on the server instead of the client in --disable-factory mode. This is compatible with previous versions of gnome-terminal." .
<smoser> that changed the default behavior of gnome-terminal to block. was that intended ?
<Laney> only if you pass --disable-factory
<Laney> yes
<smoser> for me it blocks always
<Laney> it shouldn't go into that path then, if it does then that's a bug
<Laney> will look shortly
<smoser> ie, just with 'gnome-terminal'
<Laney> smoser: ah right, I think I messed up a conditional, thanks for noticing!
<smoser> Laney, thanks for bringing 'disable-factory' back.
<smoser> i do like it.
<Laney> smoser: np - I'm surprised that quite a lot of people seem to use it
<Laney> I thought it would just be pleasing like 5 geeks :)
<Laney> can you try lp:~ubuntu-desktop/gnome-terminal/ubuntu ?
<larsu> smoser, Laney: gnome-terminal (without arguments) is supposed to block until you close that terminal, no?
<Laney> not upstream
<larsu> same with gedit
<Laney> I only intended to override their behaviour when you give --disable-factory
<Laney> We could do it always but I didn't think about that yet
<larsu> I was pretty sure that this is what it does upstream. Discussed this with desrt countless times
<larsu> let me see
<smoser> larsu, that would be sane behavior. but 'disable-factory' became necessary probably in the 12.04 time frame.
<smoser> otherwise 'gnome-terminal' would talk to the factory, create a window, and return immediately.
<smoser> then, upstream removed 'disable-factory'.
<larsu> smoser: it seems to do that upstream, but that's totally wrong. It should block until the tab/window it opened is closed
<smoser> larsu, well, arbitrarily changing back and forth in ubuntu is not helpful to people.
<Laney> OK, I'm not trying to fix that now though, we can work that through upstream
<larsu> smoser: ya, Laney is working hard on keeping compatibility, but it's not easy. Lots of upstream changes and *many* use cases
<smoser> and differing with upstream isnt either. i personally think the behavior of "block unless otherwise told to" is better. but that is different than it is in 14.04, 14.10 and upstream.
<smoser> just for random bit of information... https://gist.github.com/smoser/1ee3f2b223717625c5f4
<smoser> that is my garbage "xvim" which launches ggnome-terminal -e vim. and blocks even without --disable-factory (ie, you have to have that in 14.10 if you want pentadactyl ctrl-i to work or something like that).
<larsu> crazy. I'll look into it upstream
<doko> infinity, gccgo, did we have any successful builds in wily?
<infinity> doko: Not a lot of go packages to test that theory with, but the tree I can spot (nuntium, lxd, and docker.io) haven't built successfully since vivid, no.
<Mirv> mitya57: I think modifying that patch alone didn't help alone as the other patches make the switch from pie to pic and our core problem was the reduce relocations breaking unity8. but I can't now remember whether I tried to enable the two other patches only while not setting the reduce relocations option. and I guess I should try gcc5 too even before it's made the default so that it's known whether we'll need some linker expert
<Mirv> mitya57: sorry for the delay, my afternoon got quite swamped suddenly
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily 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:
<ptrz> how would I go about getting the libnice package updated?
<ptrz> it's going to have to be newer for the next major Pidgin release. The current libnice repo head builds and checks on 15.04.
<infinity> pitti: TB meeting?
<pitti> infinity: whoops, thanks
<pitti> that late already
<ptrz> how would I go about getting the libnice package updated?
<ptrz> it's going to have to be newer for the next major Pidgin release. The current libnice repo head builds and checks on 15.04.
<mitya57> Mirv: ok
<mitya57> Yes, testing with gcc5 will be nice. If it remains broken, maybe we should bother upstream.
<elopio> I'm having this problem with bzr: https://bugs.launchpad.net/bzr/+bug/1458946
<ubottu> Ubuntu bug 1458946 in Bazaar "bzr branch failes with: got an unexpected keyword argument 'private'" [Undecided,New]
<elopio> any idea what that means?
<smoser> elopio, i just came here to complain about same thing.
<smoser> i think it only occurs if you're launchpad-login'ed
<elopio> it's good I'm not alone.
<pitti> slangasek, stgraber: just FYI and a chuckle: debian bug 786902
<ubottu> Debian bug 786902 in wnpp "O: ifupdown -- high level tools to configure network interfaces" [Normal,Open] http://bugs.debian.org/786902
<smoser> elopio, but it seems its likely on server side rather than package
<smoser> elopio, it seems that canonical IS is working on this.
<smoser> should be fixed soon-ish.
<elopio> thanks for the update smoser.
<smoser> elopio, seems "fixed for me" at the moment.
<elopio> smoser: works here too. I'll update the bug.
<slangasek> pitti: yeah, are you chuckling about the orphaning in general or about the suggestion that we switch to one written in python? ;-P
<infinity> Oh dear lord, pleast not a python rewrite.
<ogra_> lol
<slangasek> infinity: too late! http://cumulusnetworks.com/blog/ifupdown2/
<infinity> slangasek: Oh, I'm well aware of it, I was not aware that anyone took it seriously.
<cyphermox> in theory there is code for it.
<pitti> slangasek: more like "no time any more to maintain one implementation, so let's make two!" :/
<slangasek> ;)
<pitti> more seriously, this actually does sound a bit worrying
#ubuntu-devel 2015-05-27
<psusi> so snappy core doesn't have a gui desktop, or... man installed?  why ext4 for the r/o root instead of squashfs?
<rottened> hello
<pitti> Good morning
<hyperair> in an sru'd bug, do i do the verification-{needed,done} tag change myself or is that for ~ubuntu-sru to do?
<RAOF> hyperair: Please set those tags if you've done the necessary verification. That puts it on our todo board.
<hyperair> oh okay
<dholbach> good morning
<seb128> hey dholbach
<dholbach> salut seb128
<seyeongkim> hello, any plan to backport or something for CVE-2015-4000 Issue for each releases?
<ubottu> The TLS protocol 1.2 and earlier, when a DHE_EXPORT ciphersuite is enabled on a server but not on a client, does not properly convey a DHE_EXPORT choice, which allows man-in-the-middle attackers to conduct cipher-downgrade attacks by rewriting a ClientHello with DHE replaced by DHE_EXPORT and then rewriting a ServerHello with DHE_EXPORT replaced by DHE, aka the "Logjam" issue. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4000)
<seb128> pitti, is running "autopilot3 run autopilot_tests" from debian/tests supposed to work?
<seb128>     "Unable to instantiate any backends\n%s" % '\n'.join(failure_reasons))
<seb128> RuntimeError: Unable to instantiate any backends
<seb128> X11: DisplayConnectionError(':0', b'Invalid MIT-MAGIC-COOKIE-1 key')
<seb128> grumpf
<doko> pitti, did something change with the autopkg test env? python2.7's autopkg tests now fail, trying to connect to an https sever on localhost
<pitti> seb128: should be autopilot-sandbox-run
<doko> URLError: <urlopen error Tunnel connection failed: 403 Forbidden>
<pitti> seb128: but it was working before, it can't possibly be just autopilot3 without any xvfb or so (autopilot-sandbox-run makes that really easy)
<seb128> pitti, but then I don't see what it's doing
<pitti> doko: success on i386, fail on amd64?
<pitti> doko: amd64 was recently moved by CI to running in ProdStack; they fixed the $*_proxy environment variables several times, but perhaps there's still something wrong
<doko> pitti, according to https://jenkins.qa.ubuntu.com/job/wily-adt-python2.7/lastBuild/ both fail
<pitti> doko: hm, no, they fail on i386 too
<pitti> i386 didn't change
<pitti> doko: we can re-run the vivid one to check, maybe something else changed somewhere
<doko> where to report these issues?
<pitti> doko: running now: http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-python2.7/
<pitti> so we have something for comparing distro changes vs. test env changes
<pitti> doko: https://bugs.launchpad.net/auto-package-testing/+bugs is an okay place
 * pitti cleans up the bugs while I'm there
<pitti> doko: FYI, http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-python2.7/ARCH=i386,label=adt/ succeeded
<pitti> (amd64 still running, nova is much slower)
<pitti> doko: so, this could of course still be an issue with the data center's proxy, but the env vars haven't changed in a long time on i386
<pitti> maybe the newer python has a new test which exhibit a problem with them
<doko> pitti, no, at least for 2.7, this test didn't change
<pitti> doko: ah, amd64/vivid now shows the same 403 forbidden error; still odd why i386/wily fails as well
<pitti> doko: ah no, that fails differently:
<pitti> error: [Errno 104] Connection reset by peer
<pitti> SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:590)
<pitti> (from http://d-jenkins.ubuntu-ci:8080/job/wily-adt-python2.7/10/ARCH=i386,label=adt/artifact/results/testsuite-stdout)
<seb128> pitti, k, I fixed that shotwell test, it works locally now, but failed on jenkins/with the new libgphoto in proposed (doesn't find 2 photos to import)
<pitti> seb128: ah, you already uploaded? cheers!
<pitti> seb128: will look at that part
<seb128> pitti, yes, since it worked locally I though it was going to work on the archive as well
<seb128> thanks
<pitti> seb128: haha @ the patch; I didn't quite like the down/down thingy, but I didn't see a better way (maybe someone more proficient with autopilot can robustify this)
<pitti> seb128: right, it's not really CI vs. local, it's wily vs. wily-proposed
<seb128> pitti, yeah, I can try having a look to robustify, just went for the easy solution today to unblock things
<pitti> right, appreciated
<wgrant> tedg: We're upgrading Launchpad's sbuild from a 2004 fork to one based on vivid's, and indicator-sound is the only build regression in main. A test fails, as seen in https://launchpad.net/ubuntu/+archive/test-rebuild-20150521/+build/7451774. Do you have any idea what might be going on there?
<wgrant> It succeeds on the bare metal ancient sbuild builders, fails on the OpenStack moden sbuild ones.
<pitti> FTR, succeeds locally in sbuild too
<pitti> eh, where is my mouse cursor..
<pitti> it still "works"  but is invisible
<pitti> we used to use "unclutter", but that's long gone -- is that built into unity or so?
<xnox> pitti: there is a kernel option to "never hide mouse pointer" i think.
 * xnox enabled that, or rather disabled the hide on inactive, and can't remember where it was
<xnox> found it on askubuntu
<ogra_> pitti, use an "edding"
<ogra_> be creative ;)
<pitti> well, I generally like the behavior of hiding it while typing, so that it doesn't get in the way
<seb128> pitti, we never preinstalled/recommended "unclutter", it has side effect/issues, we don't have a solution for that afaik, it's just that some gtk widget like the text ones hide the cursor
<pitti> ogra_: ok, that helped, but now I have 23 mouse pointers drawn on my screen and they don't go away any more
 * pitti wipes harder
<ogra_> lol
<seb128> bdmurray, Laney, pitti: do you know what's going on with the trusty gtk+3.0 SRU? http://people.canonical.com/~ubuntu-archive/pending-sru.html lists a bunch of regression in autopkgtests but those don't seem really related to gtk, there are what looks like jenkins issues for most
<seb128> same for the gvfs SRU
<seb128> did those tests used to run on that serie?
<seb128> the deja-dup fails on "env: dbus-launch: No such file or directory"
<Laney> I was under the impression that the SRU team only uses those results for advice, since the baseline isn't clean
<seb128> Laney, the gtk one is marked as validated and is 25 days old, so I've the feeling they are blocking it
<Laney> Well, then have developers been told they need to watch out for and fix autopkgtests for SRUs?
<seb128> Laney, dunno, that was sort of my question, you uploaded that gtk sru, did you get news from them after it
<tedg> wgrant, Nothing obviousâ¦
<Laney> I don't think so
<tedg> Ironically I'd say the testing in indicator-sound isn't great, funny it'd be the only failure.
<wgrant> Heh
<tedg> Let me take a look through the tests and see if I can see anything funky.
<seb128> Laney, btw seems like you didn't push your release commit to the vcs, did you forgot to push?
<Laney> could be
<Laney> done
<seb128> thanks
<seb128> I'm stacking another SRU
<wgrant> tedg: You can reproduce by uploading to a normal PPA, as all the virtual builders are using the new sbuild. If you can't see anything suspicious in the test suite, I'll try to narrow down why it works locally but not on an almost identical sbuild on scalingstack.
<pitti> seb128, Laney: right, the mechanics to run SRUs in trusty were different, so the tests still have some bugs/hidden assumptions
<pitti> failures there can't be a reason to reject an SRU
<seb128> k
<seb128> I guess that's a question for bdmurray&co then
<seb128> danke
<pitti> I think SRUs just haven't been processed for a week or so
<pitti> might be just that
<pitti> seb128: hm, http://d-jenkins.ubuntu-ci:8080/job/wily-adt-shotwell/29/ARCH=i386,label=adt/console still failed on "button not found", and that's ubuntu3
<pitti> anyway, will run locally
<pitti> ah, perhaps because it didn't find any pics
<seb128> pitti, well, it failed on a different one
<seb128> "{'label': '2 Photos'}."
<seb128> and that works locally/with old libgphoto
<seb128> so I assumed that the photo count is wrong with the new lib
<pitti> {'label': '2 Photos'}
<pitti> right, I see
<pitti> seb128: sorry for the noise
<seb128> nw!
<pitti> seb128: meh, shotwell (both wily and wily-proposed) just keeps hanging when trying to import..
<seb128> pitti, :-/
<seb128> wfm
<pitti> both with wily and wily-proposed libgphoto
<pitti> seb128: PtP camera, or direct sd-card?
<seb128> pitti, android phone
<roaksoax> pitti: howdy! I wsa wondering if you may have an idea of an issue we are experiencing. After we committed http://paste.ubuntu.com/11391993/ , we started seeing http://paste.ubuntu.com/11222479/ . The funny thing is that this only happens in Utopic, so I'm wondering if this has something to do with systemd related changes or how the handling happens?
<roaksoax> pitti: the issue is not present in Trusty nor Vivid
<pitti> import               PASS
<pitti> seb128: ^
<seb128> pitti, how did you fix it?
<seb128> pitti, did you manage to run the autopilot test locally? they wouldn't for me
<seb128> just under the sandbox, but then you don't get to the see the UI interactions on screen
<pitti> seb128: ah, the hang was because apparently something between my camera/libgphoto/shotwell didn't like the two mini "synthetic" pictures I put on the card
<pitti> seb128: (worked fine with gvfs) -- so I just took two tiny real ones
<pitti> roaksoax: right, bug in utopic's invoke-rc.d
<pitti> roaksoax: i. e. if a package only ships an upstart job/systemd unit without an init.d script, then invoke-rc.d bails out
<pitti> roaksoax: while this is not technically a valid Debian package, it's valid "enough" for Ubuntu, so we fixed that in vivid
<pitti> roaksoax: so perhaps you have an /etc/init.d/maas-regiond, but no /etc/init.d/maas-regiond-worker?
<pitti> roaksoax: you can work around this by: dh_installinit --no-start --name maas-regiond-worker
<pitti> roaksoax: if you can deal with the worker not being started automatically by package installation (if you need that, you need to add it manually to postisnt)
<micahg> is anyone looking at the lintian "regression" for perl in wily, if not, I'll try to poke at it today
<roaksoax> pitti: ok, cool, I can definitely do that work around!
<pitti> seb128: to clarify, we can drop block-proposed from bug 1456965 now, right?
<ubottu> bug 1456965 in Shotwell "Shouldn't use CSD under Unity" [Medium,Confirmed] https://launchpad.net/bugs/1456965
<seb128> pitti, yes, how does that work? I assumed it wouldn't stop migration since it was listed as to close in the changelog, but maybe the system is not smart enough to figure that out?
<Laney> indeed, you need to delete the tag
<pitti> seb128: right, chicken-egg -- the bug only gets closed once it hits wily, which it can't because of that open bug :)
<Laney> (or close the bug)
<seb128> pitti, I though it was maybe parsing changelog and substracting closed bugs
<seb128> but yeah, then needs to be untagged
<pitti> ack, done
<seb128> pitti, thanks
<tarpman> hi, is this the right place to ask about having autopkgtests retried? openldap is blocked by a couple of fails that I don't think are my fault: one looks like the bzr issue that I think was already fixed, the other seems to be network related
<pitti> tarpman: yes, it is; which pacakges?
<pitti> tarpman: although the amd64 ones (adt-nova) seem to have some networking problems due to proxy config, this is usually not just a glitch but needs fixing properly
<pitti> tarpman: but I can retry either way
<tarpman> pitti: squid3 (amd64 only -- guess that's what you're talking about) and boottest failed
<tarpman> pitti: rather, excuses still says "Test in progress" for boottest... after 36+ hours... don't think it's going anywere
<pitti> tarpman: squid3 will fail again, retry won't help
<pitti> tarpman: retried boottest
<tarpman> thanks!
<roaksoax> pitti: what is the correct way to check whether systemd is being used?
<strikov> roaksoax: juju looks for /run/systemd/system (see: https://github.com/juju/juju/blob/master/service/systemd/service.go#L31)
<strikov> roaksoax: pitty may know a better way though
<didrocks> strikov: roaksoax: it's the way we implemented with pitti in most services to decides if systemd is running or not
<didrocks> decide*
<strikov> didrocks: good to know, thanks!
<didrocks> yw
<pitti> roaksoax: what didrocks said
<pitti> (sorry, was in meeting)
<roaksoax> pitti: great! thanks
<roaksoax> strikov: thanks :)
<infinity> xnox: I'll send you buckets of maple syrup if you fix upstart's test_job_process to stop failing the "with single line command writing lots of data fast and exiting" test.
<infinity> xnox: The entire testsuite is effectively useless for regression testing because that one's almost always red.
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily 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: mterry
<stgraber> doko: hey, are you aware that powerpc gccgo is bused in wily?
<stgraber> doko: lxd builds fine on all arches except powerpc (the 32bit kind): https://launchpadlibrarian.net/207637499/buildlog_ubuntu-wily-powerpc.lxd_0.10-0ubuntu1_BUILDING.txt.gz
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily 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 2015-05-28
<psusi> so I have noticed that boot time is delayed due to friendly-recovery.service... it is conditioned on recovery being in the kernel command line, which it usually isn't so it doesn't run at all, but it is After=systemd-udev-settle.service and Before=systemd-fsck-root.service, so it delays fscking the root fs until after udev-settle, which takes quite some time
<psusi> could this be resolved by splitting it into two services, one that is wanted by sysinit, and has the condition, and a second that has the ordering requirements, but is only Wanted by the first service, so if its conditions are evaluated early in boot and found to be false, won't pull in the second service at all, and thus its transitive ordering requirement won't be enforced?
<sarnold> psusi: probably best to file a bug and add the tag systemd-boot, that'll get it to pitti's queue
<psusi> filed bug, will add tag, thanks
<psusi> are there plans to move to systemd for user session management ( instead of upstart ) and in the initramfs in wiley?
<micahg> I'm hoping adequate was the last one to fix for perl to migrate from proposed, if not, I'll take another look later
<pitti> micahg: oh, you fixed lintian? nice, thanks!
<pitti> Good morning
<micahg> pitti: good morning, it seems that the fix was in the new version in Debian, just undocumented, I figured to pull the pieces in and get perl migrated and then worry about merging
<pitti> wgrant: do we have anything like build recipes for git already? I suppose not directly, but can that be faked with putting some shell commands into the recipe or so?
<pitti> ah no, that's just bzr-builder commands
<wgrant> pitti: No recipes for git yet (they're currently implemented as a bzr plugin), and you can't execute arbitrary shell commands.
<wgrant> For some Git repositories you could register a code import to get them into a Bazaar branch, though.
<pitti> wgrant: yeah, that'd be a fallback; I still need to mess around with the patches somehow, but I think that can be done in debian/rules too; I would mostly just need to change debian/source/format
<pitti> ... and hope that I can get bzr imports of upstream and Debian packaging of systemd
<wgrant> https://code.launchpad.net/~registry/systemd/master
<wgrant> imports fine
<pitti> nice!
<pitti> wgrant: other question, PPA buildds have all non-ancient kernels as they are in VMs, right?
<wgrant> pitti: Yes, the virtual builders are all trusty with vivid sbuild
<pitti> wgrant: cool, thanks
<pitti> micahg: "Jenkins Fixed - wily-adt-adequate" \o/
<pitti> micahg: ah, so that missing pkg-config depends affect Debian too, right?
<Unit193> Debian #787043
<ubottu> Debian bug 787043 in adequate "adequate: Adequate needs dependency on pkg-config for new missing-pkgconfig-dependency tag" [Important,Open] http://bugs.debian.org/787043
<pitti> doko_: FYI, filed bug 1459526 and subscribed you
<ubottu> bug 1459526 in adt-cloud-worker "python2.7 test regression: Tunnel connection failed: 403 Forbidden" [Undecided,New] https://launchpad.net/bugs/1459526
<dholbach> good morning
<dholbach> larsu, HAPPY BIRTHDAY! :-)
 * dholbach hugs larsu
 * dholbach hugs larsu
 * dholbach hugs larsu
<larsu> thanks dholbach :)
 * larsu feels very hugged and hugs back
<dholbach> :-)
 * seb128 hugs larsu as well :-)
<larsu> thanks :)
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
 * dholbach hugs Laney
<Laney> \m/
<Laney> still have some procrastination to do first, but the intention is there
 * Laney hugs dholbach back
<seb128> Laney, let's see if didrocks let you some easy ones after his shift on tuesday ;-)
<didrocks> seb128: I took them ALL! :)
<seb128> hehe
<seb128> Laney, you are out of luck there, sorry ;-)
<didrocks> only hard ones remaining for Laney
<didrocks> he deserves this! :p
<Laney> I can take it!
<didrocks> *challenge accepted*
 * Laney starts from the bottom :-)
<didrocks> ahah
<pitti> I'm piloting tomorrow, don't just leave the sucky ones to me :)
<doko> stgraber, known, however I'm still unable to find the issue. not seen in unstable, only in vivid/wily. last known working version is the 5.1 release candidate. for now, I would suggest removing the powerpc binaries
<rbasak> infinity: around? I'm merging apache2. We've been carrying some changes you uploaded in http://launchpadlibrarian.net/124947541/apache2_2.2.22-6ubuntu3_2.2.22-6ubuntu4.diff.gz for a while. I have a suspicion these are not needed any more, but I don't know how to verify that.
<rbasak> Why did we need cross build for apache2 anyway?
<infinity> rbasak: Because it was on someone's list of "packages that should be cross-buildable".
<rbasak> infinity: I think it's all bitrotted now anyway.
<infinity> rbasak: What proof do you have for that statement? :P
<infinity> rbasak: I should have forwarded that to Debian (and I thought I did), but there's no reason any of it would have suddenly stopped working.
<rbasak> infinity: "Fix cross-building by passing DEB_{HOST,BUILD}_GNU_TYPE to configure" no longer adds the environment variables you defined to the configure line.
<infinity> rbasak: Hrm, indeed, looks like some bad merges along the way.
 * infinity looks at the whole source instead of the delta.
<rbasak> infinity: I can re-fix the configure line blindly if you'd like me to, and continue to maintain the delta if you wish. I don't recall ever seeing a merge conflict so it's not particularly awkward. I don't see anything relevant from a quick glance at Debian BTS though.
<rbasak> infinity: but if nobody wants it or is using it and it has rotted, maybe that's a reason to save us the trouble and drop the delta?
<infinity> rbasak: It's not just the configure line.  Someone dropped pretty much my entire delta on a merge at some point.  Probably a blind "well, the hunks don't apply, drop 'em!"
<infinity> rbasak: Oh, I guess that mpm/module bit got removed entirely...
<infinity> rbasak: So, just maintaining the 'pass HOST/BUILD to configure' bit should be simple enough, but someone should probably test a cross build to see if it still works.
<infinity> rbasak: Also a bit confused that debian/patches/086_svn_cross_compiles still applies, given how long ago I backported that from trunk...
<rbasak> infinity: 086_svn_cross_compiles still applies> yeah - given it was upstreamed I'd expect it to have arrived by now
<infinity> rbasak: Anyhow, bad merges notwithstanding, we shouldn't drop the configure bit.  I'll (re-)forward that to Debian, but not until after I've tested that it actually still crosses.  Which I might not get to today, but we'll see.
<rbasak> infinity: OK. So for now, shall I fix the configure line and upload my merge?
<rbasak> infinity: anyway, I'll do that. Fancy writing a dep8 test to test your cross to stop future rot?
<infinity> rbasak: I'm not sure DEP-8 tests in every single package to make sure it crosses is the right way to track that. :P
<infinity> rbasak: A cross-build farm that attempts to cross the entire archive and watch for regressions is the right answer, but needs some tuits of varying roundness.
<rbasak> infinity: sure. You can do that instead if you like :)
<pitti> stgraber: Ã§a va !
<pitti> stgraber: so I naÃ¯vely tried this:
<pitti> lxc-create -n wily-ppc64el -t download -- -d ubuntu -r wily -a ppc64el
<pitti> lxc-start -n wily-ppc64el -F
<pitti> stgraber: and it fails; but ISTR that LXC had some clever "run under qemu" integration? how do I make that work?
<stgraber> pitti: oh, you tried that on x86?
<pitti> stgraber: yes, amd64
<stgraber> yeah, not gonna work :)
<stgraber> the only one that vaguely works is armhf and that's when using the good old ubuntu template
<pitti> stgraber: ok; maybe I mixed that up with mk-sbuild or so? I know that we had some way of running a schroot or container or so under qemu
<pitti> stgraber: ah, ok
<pitti> stgraber: ok, so back to looking for a porter box I figure :)
<pitti> (if only we had sensible schroots on them, but let's see..)
<stgraber> qemu-user-static sort of works for armhf, so long as you don't use ptrace or netlink (which is already pretty restrictive)
<stgraber> other arches tend to segfault earlier on
<pitti> stgraber: no, just want to reproduce a build failure
<pitti> $ sudo apt-get build-dep umockdev
<pitti> AttributeError: 'apt_pkg.SourceRecords' object has no attribute 'Lookup'
<pitti> meh, porter box hates me today
<pitti> (and it builds fine under Debian)
<LocutusOfBorg1> what did happen to the ppa builders? all "cleaning" state
<LocutusOfBorg1> are they cleaning the room? :p
<pitti> stgraber: ok, nevermind; abusing a temp container on the ppc64el CI machines; thanks for the explanation!
<seb128> hum
<seb128> what should we do when packages are blocked proposed migration on "Boottest result: Regression"
<seb128> where the error is "EnvironmentError: Unsupported device, autodetect fails device"
<seb128> e.g https://jenkins.qa.ubuntu.com/job/wily-boottest-address-book-app/lastBuild/console
<pitti> seb128: I think step 1 is to retry, step 1/2 yell at CI to fix it, step 3 to override
<seb128> pitti, who in CI do you know?
<pitti> seb128: ah, that would be "cihelp:" matter
<seb128> thanks
<pitti> seb128: just talk to the vanguard (they have rotational shifts)
<seb128> pitti, thanks
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Laney> oops!
 * dholbach hugs Laney
<LocutusOfBorg1> dholbach, do you think I have chances to get sponsored curl and cmake?
<LocutusOfBorg1> I had some spare time to look at them
<LocutusOfBorg1> :)
<LocutusOfBorg1> (if you have free time I can do some merges in the next few days)
<dholbach> LocutusOfBorg1, not right now
<dholbach> I'm in meeting until 20:00 my time
<LocutusOfBorg1> no problem at all :)
* lamont changed the topic of #ubuntu-devel to: Critical components of launchpad are down. | Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<smoser> infinity, what needs to be done to make a vivid-netboot appear at http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/
<smoser> and then ultimately at all arches and then -updates ?
<zyga> ev: hi
<zyga> ev: canonical irc is down for me
<zyga> ev: have a look at the email I sent
<infinity> smoser: I need to upload it.
<zyga> ev: and if you want we can have a quick hangout if you have some questions but don't want to talk on irc
<smoser> infinity, can you do that ? and to -updates even ?
<infinity> smoser: I can't, since LP is broken. :P
<smoser> oh yeah. that.
<infinity> smoser: But yes, I had planned to finish it off this week.
<zyga> oh, lp is down too?
<sarnold> much of LP is down, among other services
 * zyga takes note not to trip over those cables the next time
<sarnold> irc.canonical.com was listed amont the affected services, but it has continued working for me and many others
<sarnold> perhaps just new connections are affected, ldap lookups and so forth
<zyga> sarnold: it doesn't work for me, so perhaps there's some round robin in the loop?
<infinity> smoser: The proposed upload will probably happen this afternoon/evening, then like any SRU, it should get some validation before moving it to updates.
<smoser> k
<infinity> smoser: I'll subscribe you to the SRU bug, so you know when it's accepted, and can perhaps test an arch or two for me.
<smoser> infinity, yeah. i can.
<Unit193> So what would it take to get another ISO built from a seed?
<zyga> how can I talk to is while the IRC is down?
<Unit193> robert_ancell: Re: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1295207 I've been running with those gst1.0 patches since posting my comment there, no crashes.  All else that would need be done is a patch for pidgin-sipe.  This would be a great effort in getting gst0.10 gone! ;)
<ubottu> Ubuntu bug 1295207 in pidgin (Ubuntu) "Migrate to farsight 0.2* / gstreamer 1.0" [Undecided,Confirmed]
<wgrant> zyga: #canonical-sysadmin
<wgrant> zyga: What issues are you seeing connecting to IRC?
<robert_ancell> Unit193, is there a patch / branch for that?
<zyga> wgrant: I want to add a record to the incident report
<Unit193> robert_ancell: There is, I linked to the Fedora one, and it's been merged into the unreleased upstream 2.x branch (who knows when they'll release), and I have a mostly-merged .11 with it from March(?): https://launchpad.net/~unit193/+archive/ubuntu/test/+sourcepub/4862307/+listing-archive-extra
<wgrant> zyga: You should still be able to connect to irc.c.c
<Unit193> robert_ancell: Need to go now though. :3
<robert_ancell> Unit193, ok
<zyga> wgrant: I cannot, since wednesday
<wgrant> zyga: Uh
<wgrant> Have you reported this?
<zyga> wgrant: I was super busy (demo day today) so I ignored the problem
<zyga> wgrant: then this happened and I assumed it was the cause
<zyga> wgrant: (no, I have not)
<robert_ancell> Unit193, I can't seem to download your pidgin changes https://launchpadlibrarian.net/201273988/pidgin_2.10.11-1~vanir1~15.04.debian.tar.xz
<Unit193> robert_ancell: Launchpad is/was having issues.
<robert_ancell> Unit193, do you have the patch files? Can you attach to the bug report or send them to me / pastebin them?
<Unit193> It's been a while, it's all now only on LP. :/
<Unit193> I can refresh the Fedora one, but it applies with only offsets.
<Unit193> Dang this is annoying.
<robert_ancell> Unit193, I just pushed pidgin 2.10.11 so I just need a patch file that appies against that. The one from Fedora has some conflicts
<wgrant> robert_ancell, Unit193: It should be working now.
<Unit193> wgrant: Fantastic, thanks.  Yes it does now. \o/
<robert_ancell> wgrant, works here, thanks!
<robert_ancell> Unit193, your package doesn't seem to have any patch for farsight 0.2 - does that seem correct?
<robert_ancell> ah, it is in the gstreamer1.patch. Sorry, missed that.
<Unit193> robert_ancell: Right, not the best merge ever, but at the time I was doing a quick one to try it in a PPA.
<wgrant> Launchpad should be completely OK again. Let me know if anything looks awry.
#ubuntu-devel 2015-05-29
<Unit193> robert_ancell: -sipe too?
<robert_ancell> Unit193, sipe?
<Unit193> robert_ancell: http://pkgs.fedoraproject.org/cgit/pidgin-sipe.git/commit/?id=e367f2172c5d37bfedbc2d1a27c6e551a7b0f76d something like that.  To enable it to build with gst1.0 and pidgin 2.x.
<Unit193> It already supports it, it's just not checking for gst1.0 with pidgin 2.x yet.
<robert_ancell> Unit193, can you file a bug for that?
<mwhudson> infinity: you about?
<mwhudson> i want to talk shared libraries again
<Unit193> robert_ancell: But thanks, this'll be handy.
<pitti> Good morning
<zyga> good morning
<dholbach> good morning
<seb128> hey dholbach
<dholbach> salut seb128
<LocutusOfBorg1> tjaalton, hi you there?
<tjaalton> LocutusOfBorg1: more or less
<LocutusOfBorg1> does your xserver-xorg-lts-vivid needs some rebuilds?
<tjaalton> not that I know of
<LocutusOfBorg1> because with the new trusty installed from scratch I can't install the development package
<LocutusOfBorg1> and this is bad, since I can't fix any virtualbox bug (can't install the dependencies)
<tjaalton> the vivid lts stack is in limbo, you want infinity for that :)
<tjaalton> huh?
<LocutusOfBorg1> trusty installed from scratch, sudo apt-get install xserver-xorg-dev
<LocutusOfBorg1> ^^^ failure
<LocutusOfBorg1> (libcheese, libclutter gives troubles)
<tjaalton> how does it relate to lts-vivid
<tjaalton> ?
<LocutusOfBorg1> mmm I see...
<LocutusOfBorg1> you are right
<tjaalton> if you installed using 14.04.2 image you're on lts-utopic
<tjaalton> and aiui it should still allow building whatever
<LocutusOfBorg1> tjaalton, it doesn't work
<LocutusOfBorg1> don't know why :(
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Critical components of launchpad are down. | Archive: wily 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: pitti
<tjaalton> LocutusOfBorg1: is there a xserver-xorg-dev-lts-utopic then?
 * dholbach hugs pitti
 * pitti hugs dholbach back
<pitti> hallyn_: I'm confused by our delta in libcgroup, in bug 1445036
<ubottu> bug 1445036 in libcgroup (Ubuntu) "Please merge libcgroup 0.41-6 (universe) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/1445036
<pitti> hallyn_: adding the dependency is our only delta in libcgroup, and there is no other change in the package which would justify this dependency
<pitti> nor an explanation in the changelog why it was done
<knocte> can someone tell me what's the gtk version used in ubuntu 15.04?
<brendand> knocte, seemingly 3.14.12
<brendand> well gtk-2.0 is on here as well
<brendand> and that's 2.24.27
<mitya57> 3.14.13 will arrive soon
<knocte> thanks, and by any chance do you know if 3.16 is used already in v.next?
<Laney> You can check for yourself https://launchpad.net/ubuntu/+source/gtk+3.0
<Laney> (or rmadison gtk+3.0)
<pitti> meh, every sponsoring bug that I look at today is broken, except the cmake one from LocutusOfBorg1
<knocte> ok thanks
<pitti> mvo: is https://code.launchpad.net/~jamesodhunt/ubuntu/wily/ubuntu-core-upgrader/call-upgrader-directly/+merge/259481 something you could/would review?
<pitti> Laney: ah, I just double-sponsored https://code.launchpad.net/~logan/ubuntu/wily/pinentry/0.9.2/+merge/260092 -- can you please set MPs as merged when you upload?
<Laney> I usually rely on that happening when it goes in
<Laney> but in this case it went to NEW
<pitti> (or at least follow up)
<pitti> Laney: ah; but  it would still not auto-close the MP even without new
<Laney> Hmm, then it would never have merged because I thought we have magic for that
<Laney> should have commented either way, sorry
<pitti> arges, jamespage: bug 1381450 - that's a bad SRU, neutron is now uninstallable in vivid main
<ubottu> bug 1381450 in libnetfilter-queue (Ubuntu) "[MIR] conntrack, libnetfilter-queue, libnetfilter-cttimeout, libnetfilter-cthelper" [Medium,Fix released] https://launchpad.net/bugs/1381450
<pitti> I just promoted the lot in wily, but we can't do that in vivid
<wgrant> Wellll
<wgrant> You can
<pitti> we could do a no-change SRU of these four and promote those, I figure
<ricotz> hello, is someone here able to manage the ubuntu-translators mailing-list and can approve a pending mail?
<dholbach> ricotz, I'm afraid dpm is on holidays
<dholbach> ricotz, but you could either sign up for the list to get the mail through, or ping folks in #ubuntu-translators
<dholbach> or was it #ubuntu-translations?
<ricotz> dholbach, I see, there must be more people able to do it ;), ping over there
<dholbach> good luck
<ricotz> dholbach, thanks
<mvo> pitti: I will have a look
<LocutusOfBorg1> thanks pitti , I would like to also understand if the https://launchpadlibrarian.net/207707184/debdiff multiarch patch is really still needed
<LocutusOfBorg1> xnox, ^^^ :)
<LocutusOfBorg1> pitti, cmake needs a MIR of libjsoncpp ?
<xnox> LocutusOfBorg1: yes it is.
<xnox> LocutusOfBorg1: otherwise cross compilation of qt5 things is broken without it....
<xnox> and like most of the debian packages
<pitti> LocutusOfBorg1: right, needs a MIR
<seb128> cjwatson, hey, do you think we could get https://code.launchpad.net/~ubuntu-desktop/ubuntu-cdimage/ubuntu-next-system-image/+merge/257057 merged?
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Critical components of launchpad are down. | Archive: wily 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:
<LocutusOfBorg1> xnox, how can that patch be ubuntu-specific then?
<xnox> LocutusOfBorg1: by not being in debian, yet....
<xnox> LocutusOfBorg1: "debian packages" as in .dsc / .deb, not "Debian" packages as in those that are Debian Project specific.
<LocutusOfBorg1> thanks xnox :)
<teward> smoser: ping, if you're around
<gQuigs> hi there, I'd like to unstick this so we can get finish getting it SRUed.. apt has been stuck at "In Progress" for 8 days now - http://people.canonical.com/~ubuntu-archive/pending-sru.html
<gQuigs> (for 12.04, is there any way to reset it?)
<teward> gQuigs: i bet the autopkgtests failing has something to do with the stuck state
<gQuigs> teward: how do you fix them ?
<teward> gQuigs: i'm not an expert, i simply made that observation from the pending sru pages
<gQuigs> teward: hmm.. yea guess I didn't mention that.. I'm trying to figure out how to unstick that test :P
<Unit193> infinity: Hey.  What would it take for us (Xubuntu) to add another image build?  There's already a meta/seed, fwiw.
<infinity> Unit193: Which image would this be?
<Unit193> xubuntu-core.
<infinity> Unit193: What sort of image is that?  Something like ubuntu-core (snappy or rootfs, or other?), or just a smaller ISO, or...?
<Unit193> infinity: The second, just a smaller ISO.
<infinity> Unit193: Anyhow, the short answer is proposed patches to livecd-rootfs, ubuntu-cdimage and, if it's an ISO, debian-cd.
<Unit193> Welp, sounds like "fun".  Thanks!
<infinity> Unit193: On the other hand, if it's a subset of the current xubuntu, my recommendation (though it's a bit more work, it's way spiffier a result) would be to mangle your current CD to do stacked squashfses.
<infinity> Unit193: As in, build a core squash, then build the desktop squash on top, then the installer could be made to install skinny or fat.
<infinity> Unit193: But that's definitely more work in both livecd-rootfs and ubiquity.
<Unit193> infinity: It is, though part of the point would be a smaller ISO download as well.  Indeed, as xubuntu-desktop actually seeds off of xubuntu-core.
<infinity> Unit193: Third option being to just shrink your current CD, and have the full desktop be a downloadable option during the install.  Studio has some examples of how to mangle ubiquity to do that sort of thing.
<infinity> Unit193: Mostly, just trying to talk you out of exploding your testing/validation matrix.  It's more pain than people first think. ;)
<Unit193> infinity: An idea would be that -core is there, downloadable, but considering it's just a slimmed down version it doesn't need quite as much testing.  We've talked about it as a team (with our QA guy), but may be nice to offer those alternatives though, thanks.
<infinity> Unit193: Yeah, I won't stop you from doing it, just giving you options.
<Unit193> An outside view that knows the system better than we do would never be ignored. :)
<infinity> Unit193: Also, from a pure marketing perspective, if you don't want people thinking it's a New Age IoT snappy thingee, you might want to pick something other than "Core".  Minimal, Small, Basic, etc.
<rbasak> pitti: see bug 1458630. We deliberately moved apparmor-profile-load into init-system-helpers because it isn't necessarily upstart-specific. So I'm not sure why you say "Temporarily"? In any case the Breaks/Replaces needs to continue to be present.
<ubottu> bug 1458630 in init-system-helpers (Ubuntu) "broken package init-system-helpers: attempt to rewrite other package files" [Undecided,New] https://launchpad.net/bugs/1458630
<Unit193> infinity: Right, bit late for that perhaps though.  We built off the Lubuntu idea which has been around forever, and it just barely missed the mark for trusty so made it into utopic.  Changing the ubuntu-upgrader and all that for a transition also doesn't sound fun. :3
<infinity> Unit193: Well, no need to change the seeds or the meta, just perhaps the product name for the ISO.  But again, just a suggestion.  Canonical doesn't own a trademark on the word "Core" or anything, it's just a confusingly overloaded term.
<Unit193> http://xubuntu.org/news/introducing-xubuntu-core/ tried to note they were vastly different.
<Unit193> infinity: Ah right, that'd be great if it's just the name.  Slightly confusing perhaps, but not a big deal.
<Unit193> And yes, I quite agree!
<infinity> rbasak: That change should have stayed in until 16.04 indeed.  Pretty please reintroduce?
<infinity> Ideally, with a comment in debian/control, so it doesn't go away again. :P
<rbasak> infinity: ack, but I'd like to sync with pitti first. But also, I'm EOD. Added to my TODO for next wek.
<jrwren> Windows Server Core !
#ubuntu-devel 2015-05-30
<jrwren> can anyone tell me equivalent of git add -up with bzr ?
<wgrant> jrwren: Only git has the concept of the index, so there's no direct analogy in other VCSes.
<wgrant> jrwren: Other VCSes just commit whatever's in the working tree.
<jrwren> wgrant: thanks.
<wgrant> The bzr equivalent is to run 'bzr shelve' to store away the changes from the working tree that you don't want.
<wgrant> Then bzr commit, then bzr unshelve to get them back.
<jrwren> so, my editor "fixed" some source I was editing. I don't feel I should commit those fixes. I'd like to commit ONLY the lines I intended.
<jrwren> shelve worked well. thank you wgrant
<wgrant> (shelve is basically stash)
<jrwren> I don't know if any software-properties folks are around. I find this valuable. https://code.launchpad.net/~evarlast/software-properties/support-update/+merge/260640
<wgrant> jrwren: It looks like you've proposed an Ubuntu packaging branch into the upstream trunk, which isn't going to work very well.
<wgrant> jrwren: You probably want to make a fresh branch of lp:software-properties, then commit on top of that and push.
<jrwren> wgrant: so I branched the wrong then?
<wgrant> jrwren: Looks to me like you branched lp:ubuntu/software-properties
<jrwren> wgrant: i did, but afaict they are the same thing.
<jrwren> how can you even tell that from the MP?
<wgrant> They're unrelated branches of the same codebase.
<wgrant> Have you seen the MP diff? :)
<jrwren> WTF?!?!
<jrwren> hahaha
<wgrant> Unless your change was actually 112000 lines, I think there's a problem.
<jrwren> i really do not understand LP and the way this stuff is done.
<jrwren> maybe someday.
<wgrant> Well, this isn't really LP-specific.
<jrwren> wgrant: and bzr.
<jrwren> wgrant: if it were git, I'd not be so confused :)
<wgrant> It's just that in this case the upstream project is also on LP, so it's slightly confusing.
<wgrant> It'd be the same if you grabbed a repo from Debian and then pushed it to the upstream developer.
<jrwren> i see.
<jrwren> yes, that is clear now.
<jrwren> thanks.
<wgrant> Remember that LP isn't Ubuntu-specific. If it's not under /ubuntu, it's probably an upstream project.
* wgrant changed the topic of #ubuntu-devel to: Archive: wily 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:
<jrwren> i guess I thought there was bzr+lp magic making the repos the same
<Unit193> (Though it is heavily geared towards Ubuntu.)
<jrwren> i'm so bummed about this. I wrote a nice MR message and deleted the MR. Can't remember what I wrote. I should sleep instead.
#ubuntu-devel 2015-05-31
<bigdissaved> Morning, I am wondering what how I can recomend a kernel driver be added to the dist? It is for the rtl8812AU AC 1200 wireless chip. I have it working on my system, but it is very anoying that I have to recompile and install it every kernel/system update. It is in my garage, and wifi is the only connection that it has.
<bigdissaved> https://github.com/abperiasamy/rtl8812AU_8821AU_linux  this is the source code tree that I am using, and it works flawlesly for my self with 15.04
<bigdissaved> and 14.04.2
#ubuntu-devel 2016-05-30
<cpaelzer> good morning
<Skuggen> elbrus: I'm MySQL upstream by the way, so you could poke me about anything mysql-specific
<Skuggen> And yeah, we started the transition much too late. Sorry :|
<pitti> Good morning
<Unit193> Heya, pitti.
<Skuggen> Morning :)
<nhaines> Hmm, I'm missing avidemux in xenial.  Question: how can I check when and why it was dropped from the archives?
<popey> nhaines: odd.. https://launchpad.net/ubuntu/+source/avidemux/+publishinghistory
<popey> back in yakkety
<nhaines> popey: yup, I noticed.
<nhaines> Huh, x264 lib transition problem.  Huh.
<nhaines> Wish I'd known!
<nhaines> I wonder where that was discussed...
<popey> bug 1585504 probably needs updating
<ubottu> bug 1585504 in avidemux (Ubuntu) "Avidemux is not available for Xenial" [Medium,Confirmed] https://launchpad.net/bugs/1585504
<nhaines> popey: if I can get it working again, can it go into xenial-updates?  Or is that off-limits once a release has been sealed?
<Tm_T> this isn't yet in ubuntu security tracker? https://security-tracker.debian.org/tracker/CVE-2016-5118
<popey> nhaines: I suspect backports is the way to xenial from yakkety
<pitti> infinity: ATM we seed "init" into "required"; once we make it non-essential, what do you think would be the correct seed? minimal, I suppose?
<nhaines> popey: Ooh, thanks.  I'll have to... I guess I'll have to look into that.
<pitti> infinity: i. e. something that does not end up in the buildd chroots, but on every actual image/product
<pitti> RAOF: the mir mainâ universe demotions on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -- ok/intended, or do some seeds need to be updated?
 * RAOF looks
<RAOF> pitti: One or more of mir-graphics-drivers-android or mir-graphics-drivers-desktop should be seeded somewhere, I think.
<RAOF> Presumably mir-graphics-drivers-android should be seeded for the touch image, and -desktop for a desktop image.
<nhaines> That's crazy talk!
<six86> Hello. I'm packaging software which depends on java. Our software is tested with 1.6, 1.7 and 1.8 but has problems with java 1.9. To be flexible in the future we want to depend on the virtual packages java7-runtime and java8-runtime. But this leads to installation of java 1.9 jre... how can we prevent this?
<six86> Or simpler: how can i depend on java <= 1.8 with using the virtual package abstractions?
<LocutusOfBorg> can anybody please run gdal autopkgtest against vtk6/proposed? thanks
<pitti> smoser: that cloud-init python hash seed issue is a real nuisance; do we have a workaround for that yet?
<LocutusOfBorg> hi, does anybody know what is wrong with this build? https://launchpad.net/ubuntu/+source/python-tornado/4.3.0-2ubuntu1/+build/9818460
<LocutusOfBorg> I can't reproduce the build failure on debian, ppa, local
<LocutusOfBorg> pbuilder, sbuild etc
<LocutusOfBorg> something is preventing sockets to be reused from python, but only on armhf and buildd system (Ubuntu)
<infinity> pitti: minimal == Priority:important, which seems correct, yes.
<Saviq> pitti, hey, during the arm64 enablement we're encountering quite  a bit of "uninstallable ... missing runtime dep */arm64" - slangasek mentioned that this felt overly stringent on things that were not available/installable for that arch in the first place, think we could allow those through automagically?
<Saviq> adding "artificial" B-Ds to avoid building for an arch feels weird
<Saviq> maybe we would not copy the arch, but that'd feel detrimental to the process of enabling the missing dependency, because would require you to hunt for packages that are not in the archive - but if the archive can only have installable packages, then maybe that's what we do?
<infinity> The goal is certainly for everything in the archive to be installable.
<infinity> Saviq: Where are you seeing the issues?
 * infinity doesn't see anything suspicious in excuses.
<Saviq> infinity, right now it's fine in excuses I think, but we had that before with the upstart s390x deletion - also we've just enabled unity8 arm64 in a silo, but that didn't pass britney because of oxide-qt not having arm64 yet
<infinity> Well, if unity8 depends on oxide-qt, it's somewhat useless to publish it?
<Saviq> infinity, "somewhat" - would go a fair way to allow people enabling oxide-qt to verify their work
<Saviq> I think my worst complaint is the need to add artificial B-Ds to avoid that
<infinity> Artificial B-Ds are one option, arch-restricting is another.
<infinity> Having uninstallable packages in the archive doesn't really help anyone.
<infinity> Having them in a PPA can help, certainly.
<Saviq> infinity, ack, I wonder if proposed migration could just skip them (only if they were not available for that arch before), then? so we can still get to them through LP?
<infinity> Saviq: "skip" them how?
<infinity> Saviq: You mean delete the arm64 binaries?
<infinity> Saviq: That's not something we're going to do automatically.
<Saviq> infinity, well, not migrate them
<Saviq> ack
<infinity> We migrate based on source packages, not binary.
<infinity> So, the whole source is ready to go, or none of it is.
<Saviq> infinity, ok, was just asking - we'll manage - not like this will be a constant source of trouble
<infinity> Certainly, when enabling an arch, we have hacks to let an arch be a bit broken for a while, but enabling arm64 happened years ago, you missed that boat.
<Saviq> :)
<infinity> (And I will point out that I got annoyed even back then about people making assumptions like "we'll never make an arm64 desktop/phone product, so meh". :P)
<Saviq> ;)
<six86> How can I define in a deb to install stable java 8 and not 9? When depending on java8-jre, openjdk-9-jre is installed :(
<six86> How can I block java 9?
<LocutusOfBorg> Trevinho, hi, can you please upload a compiz without libpng12-dev build-dependency?
<LocutusOfBorg> ginggs, ^^^
<cpaelzer> pitti: if there is a package that has no dep8 test adt-run after the build obviously just says SKIP, is there a way to get into the adt-run session anyway - like --shell?
<cpaelzer> pitti: reason: laziness - I just would like to (mis-)use that env as test-env without having to set up an own one :-)
<pitti> cpaelzer: you are using qemu?
<cpaelzer> pitti: yes
<pitti> cpaelzer: if there's no actual test, then there also won't be any specific setup like isntalling packages
<pitti> cpaelzer: so you could just as well boot the VM with QEMU directly
<cpaelzer> pitti: so I could just qemu into the image
<cpaelzer> pitti: ok
<cpaelzer> pitti: thanks
<pitti> cpaelzer: I do that all the time indeed, to get a throaway VM for experimentatino
<cpaelzer> pitti: that is just what I wanted in my case :-)
<pitti> cpaelzer: i. e. I boot it with ssh forwardning and -snapshot
<pitti> cpaelzer: I usually call "vm adt-yakkety-amd64-cloud.img -snapshot" where vm is http://people.canonical.com/~pitti/scripts/vm
<cpaelzer> pitti: works like a charm for me!
<pitti> cpaelzer: oh, and you might want -nographic too
<cpaelzer> that allows me to throw away some of my semi-persistent uvt-kvm instances
<cpaelzer> pitti: I'm fine adding random qemu options as I need them, great
<pitti> cpaelzer: I don't put -nographic into my "vm" script as I also use it to boot desktop VMs, but if you only use it for that purpose, it's more convenient there of course
<cpaelzer> I copied your vm script into my ~/bin
<cpaelzer> wouldn't there be a use for that "in" the autopkgtest package as little helper script?
<cpaelzer> or do you think that is too special
<pitti> cpaelzer: if at all, then more like in qemu itself
<pitti> that script has nothing to do at all with autopkgtest
<cpaelzer> true
<pitti> I guess pretty well everyone who regularly boots VMs has their own little set of scripts
<Trevinho> LocutusOfBorg: mh, what's the problem?
<LocutusOfBorg> Trevinho, libpng12 needs to die, using libpng-dev only is the solution
<LocutusOfBorg> I want to remove it from the archive :)
<eoli3n> hi, just want to know where is located files of this loading screen -> http://img15.hostingpics.net/pics/703002201605301501361298x972scrot.png
<eoli3n> i manage clients with ansible, and i created a service which is launched before lightdm.service
<ginggs> Trevinho: if you are uploading a new compiz, would you change libjpeg8-dev to libjpeg-dev as well, please?
<eoli3n> i want to see if i can edit this screen to add some graphics information about ansible-pull process
<Trevinho> ginggs, LocutusOfBorg: ok... You can also propose that if you can/want: just do a MP against lp:compiz
<LocutusOfBorg> Trevinho, https://code.launchpad.net/~costamagnagianfranco/compiz/compiz/+merge/296044 ?
<pitti> infinity: you'll lose not one, but two init systems soon :) http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
<LocutusOfBorg> is it ok? (note, it is my first try)
<Trevinho> LocutusOfBorg: fine
<Trevinho> LocutusOfBorg: thanks
<pitti> infinity: sysvinit-utils is too soon though (debian bug 810018), I'll seed that
<ubottu> Debian bug 810018 in procps "procps: Please (re)consider shipping procps pidof" [Wishlist,Open] http://bugs.debian.org/810018
<mapreri> Laney: can you kick AS for scribus/xenial-proposed?
<pitti> infinity: i-s-h and seed changes done for making init not essential/required any more; let's see what breaks :)
<pitti> infinity: so the first three sections in http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt are now as  I'd like them -- does that look reasonable to you? but I'm not sure where the two others ({standard,optional} â important) come frmo
<pitti> infinity: oh, because init moved to "minimal", and systemd recommends libpam-systemd, which needs dbus
<pitti> infinity: thus previously when init was in required, we didn't install the recommends; hmm
<Bluefoxicy> needs more readyboost-config
<Bluefoxicy> http://man7.org/linux/man-pages/man7/lvmcache.7.html
<Bluefoxicy> I guess this is n/a to btrfs
<Bluefoxicy> https://www.rath.org/ssd-caching-under-linux.html bcache
<Bluefoxicy> I wonder how long this will stay relevant.  You can get a 6TB HDD for like $150, or a 0.5TB SSD for that now, so SSD is 12x as expensive
<Bluefoxicy> there's new technology closing that gap, though.
<Bluefoxicy> sucks to implement complex caching only to have this lug of ridiculous floatsam bogging up your system 5 years later when the high-speed caching device is cheaper than the high-capacity backing device
<roadmr> Is there a bug about the non-actionable "Software Updates Available" bubble?
<infinity> pitti: Those changes look fine to me, they already match the minimal task, the priority being wrong was a bug, IMO, not a feature.
#ubuntu-devel 2016-05-31
<cpaelzer> good morning
<pitti> infinity: right, I remember again -- we made the libpam-systemd a recommends instead of a depends to keep out dbus etc. from being quasi-essential
<pitti> infinity: but now that the entire init dropped out of essential, that's actually okay and desirable
<pitti> Good morning
<infinity> pitti: I made all the changes, FYI.  I'm going to look at fallout for "weird" images (people who don't ship minimal/standard, because reasons) when I wake up and fix any oddities.
<pitti> cyphermox: this morning when I tried to boot my laptop, EFI refused to boot because it could not verify the signature; I disabled secureboot for now, but I suppose that Should Not Happenâ¢; how can I debug this?
<pitti> cyphermox: (yakkety du jour)
<pitti> mdeslaur, jdstrand: IIRC you started working on loading apparmor profiles in systemd directly, like it does with SELinux, to get rid of the apparmor rcS init.d script and the associated race conditions, right?
<pitti> mdeslaur, jdstrand: I was curious what the status of that was, as Debian is trying to get rid of rcS init.d scripts (they tend to cause problems)
<RAOF> Hm. *Some* update appears to have broken the Mir build. With weird template linker errors!
<pitti> urgh, what happened to prodstack swift
<Laney> mapreri: was away for a few days; will look soon
<six86> Hello. I can't manage to create a bootable stick with my preseeded *.iso file... It works fine in a VM and Also creating a bootable stick from the orginal ubuntu image works fine
<pitti> tjaalton: please see my followup/question in bug 1577735
<ubottu> bug 1577735 in libdrm (Ubuntu Xenial) "Add missing SKL/BXT PCI-ID's" [Medium,Fix committed] https://launchpad.net/bugs/1577735
<rbasak> pitti: I see systemd 230 is in Yakkety. What are the plans for KillUserProcesses? Does the server team need to consider our view on the screen/tmux use case? That is, will there be a behaviour change in Yakkety?
<pitti> rbasak: the change is already reverted in the packaging git, so 230-2 will be back to the 229 behaviour
<rbasak> pitti: ah, thanks.
<infinity> pitti: Can we get that out sooner rather than later, to avoid the impending whine-fest (and people like me who've been sprinkling config snippets around already...)
<pitti> infinity: yeah, can do; it'll be stuck in -proposed for a while though, as autopkgtesting is currently blocked on swift being down
<pitti> but people could get it from -proposed then
<infinity> pitti: Whee.  But yeah, better than nothing.
<infinity> pitti: Is there ongoing upstream discussion about the madness, or are downstreams just expected to fork that bit forever?
<pitti> infinity: there are upstream discussions, yes
<pitti> e. g. upstream bugs for screen/tmux
<pitti> but until that has settled down, we'll just revert to the old behaviour
<pitti> infinity: it's just a ./configure option, not that much of a fork
<pitti> and given how much opposition it met, I wouldn't be surprised if the default flips back in 231 upstream too
<infinity> pitti: So, in the new world order, how does a user intentionally detach a process so it doesn't get whacked?
<lifeless> infinity: there's a systemd thing you can call
<infinity> Ick.
<pitti> infinity: that's still being discussed actually; IMHO it'd be cleanest to start a PAM session, or use systemd-run to start a new scope (like a "mini" session)
<rbasak> You have to enable lingering first AIUI? Or is that not necessary?
<pitti> but I haven't seen a really satisfying answer to that
<pitti> yes, but lingering is global
<pitti> if you enable it, all other leftover processes from your session will survive too
<rbasak> I see. So one or the other will suffice?
<pitti> this is still a problem at the conceptual level, before we even can discuss technical solutions
<infinity> pitti: None of that would satisfy the simple use case of "./long-job > log 2>&1 &" oh crap, need to logout "disown && logout".
<infinity> pitti: But I guess we'll see where it goes.
<infinity> Breaking UNIX, one use-case at a time.
<pitti> we either accept tons of leftover processes, or change the ones that are deliberately long running
<pitti> infinity: e. g. I wouldn't expect ./long-job & to survive on logout
<pitti> that'd go straight against my idea of logging in and out
<rbasak> Or we fix the bugs so processes exit when they should?
<pitti> screen and tmux I can understand
<pitti> but, as said, we first need to define what we actually want before discussing implementation
<infinity> pitti: I suppose one could write a souped-up disown that moves the process out of the cgroup instead of just unparenting it?
<pitti> and everyone seems to want something different
<pitti> infinity: yes, that's more or less what systemd-run or a new PAM session would do
<infinity> pitti: Well, but post-run is the key.
<infinity> pitti: Having to think of this in advance is a massive behavioural change for old farts. :P
<pitti> this is a prime example for https://xkcd.com/1172/
<infinity> I disagree entirely.
<pitti> I think it's a bug and counter-intuitive that session processes survive logout, you consider it a feature, one of us will always be unhappy :)
<rbasak> pitti: do you consider an ssh disconnect a logout?
<infinity> rbasak: Yes.
<infinity> Anything that will result in killing your shell (or base process) is a logout.
<pitti> rbasak: I'd say yes
<infinity> disown exists specifically to unparent processes from the controlling shell, so the HUP sent on disconnect isn't propagated.
<infinity> It's a feature, not a misfeature.  It's not spacebar heating. :P
<pitti> yes, I can close the terminal and the process goes on
<infinity> And HUP has a very specific meaning, and has done for decades.  Again, I don't think it's sane to say "actually, that should have been KILL all along".
<pitti> anyway, 230-2 building, and I'll upload it to sid then; should get autosynced to y in half a day or so
<infinity> As in, some things intentionally deamonize on HUP, so they don't get rudely interrupted by a remote disconnect.
<infinity> In fact, even apt does that. :P
<infinity> (To avoid half-done dpkg runs)
<infinity> pitti: Anyhow.  I agree that making tmux/screen spawn new login sessions would be a workaround for the problem, but I disagree that remapping HUP to KILL for disconnects is in any way POSIX/UNIX friendly. :P
<infinity> And, honestly, it'll just lead me to set my shell to /usr/bin/tmux
<infinity> Which then gives me the same behaviour I had before, and renders the new world order a no-op.
<pitti> infinity: I don't actually expect it to become a new world order anytime soon
<pitti> this was an idea, it failed, it gets reverted, maybe the next concept and iteration works better
<tjaalton> pitti: adding a handful of missing pci-ids so that compiz works properly shouldn't break anything
<pitti> tjaalton: maybe, but it still needs to be confirmed that the package upgrades and runs correctly, and that X still works with the -proposed package
<pitti> tjaalton: we've had SRUs of binutils and gcc, for example
<tjaalton> pitti: well I copied a comment from the private bug
<pitti> tjaalton: that comment makes little sense
<tjaalton> huh?
<pitti> tjaalton: 2.4.67 *is* the version in t/x-proposed
<pitti> if it's only fixed by .68, then that needs to be SRUed as well, that's only in y
<tjaalton> well yes the version in the comment is wrong
<pitti> and it also doesn't say whether that's t or x
<tjaalton> no, it just needs the pci-id's that the rest of the stack already has...
<tjaalton> (kernel, mesa)
<tjaalton> sigh
<tjaalton> if you insist, I'll ask chih to comment himself
<pitti> well, I insist on someone testing the actual package from -proposed and confirming the version and that it still works
<tjaalton> pitti: and the only diff between t/x is the version number
<pitti> tjaalton: doesn't matter -- we are looking for regressions here; confirming that it fixes the bug is nice, but not actually the first priority
<pitti> but if the xenial-proposed one misbuilt because of our gcc or binutils SRU, we want to know this
<pitti> just trusting "the diff is simple" isn't sufficient, and has led to catastrophes more than once
<tjaalton> have you even looked at the diff?
<pitti> the diff is *completely* irrelevant
<tjaalton> it's completely relevant
<tjaalton> this is not gcc
<tjaalton> or binutils
<pitti> (well, it's not in geneal, but the diff doesn't change the fact that we need to test teh proposed package)
<tjaalton> and it was tested, I don't have the hw for that
<pitti> testing for regressions on any intel hardware is fine
<pitti> it's more important that it doesn't regress on existing systems than that it actually fixes the bug
<pitti> we can always do a followup SRU if we missed a PCI ID, but we don't want to leave existing systems with a broken X
<pitti> sorry, but just saying "it'll work without testing" for a compiled library is not acceptable
<Saviq> xnox, hey, could you help with bug #1585517 please - between vivid and xenial we can no longer cross-build unity8 again - I've tried :any, :native for the two B-Ds, but I suppose that's wrong (and it didn't work anyway...)
<ubottu> bug 1585517 in python-setuptools (Ubuntu) "Can't install for cross-building" [Undecided,New] https://launchpad.net/bugs/1585517
<mapreri> Laney: ok, don't worry :)  Thanks for prodding the thing!
 * mapreri now waits for the mirror to updates
<mapreri> -s
<mdeslaur> pitti: jdstrand can confirm, but I don't believe we ever started that work, as the init script worked ok and we got busy  doing other stuff
<pitti> mdeslaur: thanks, what I thought; the usual fate of makeshift solutions which work well enough :)
<pitti> *cough* ddeb-retriever *cough*
<mdeslaur> heh, yeah :)
<Mirv> I think qtchooser  qt4-x11 qtbase-opensource-src could migrate to release pocket, together, but some hinting would be definitely needed still.
<Mirv> there are also "Test in progress" ones that seem to be ghosts - kactivities under qt4-x11, ktnef under qtbase-opensource-src (others are always failed ones)
<Mirv> some KDE update remaining autopkgtest breakage is there, but they don't completely go away too soon.
<xnox> Saviq, commented.
<Saviq> xnox, thanks
<xnox> but it's been a while since i did multi-arch fixes
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<xnox> so maybe barry and/or slangasek would be best to doublecheck the assertions I stated on bug #1585517
<ubottu> bug 1585517 in python-setuptools (Ubuntu Xenial) "Can't install for cross-building" [Undecided,New] https://launchpad.net/bugs/1585517
<smoser> pitti, "cloud-init hash seed issue" ? you mean bug 1584147 right ?
<ubottu> bug 1584147 in cloud-images "cloud-init hangs on boot as Python waits for sufficient randomness to start" [High,Confirmed] https://launchpad.net/bugs/1584147
<tyhicks> pitti (FYI mdeslaur & jdstrand): the hard work is done - the parser code that handled policy loads has been moved into libapparmor with a nice simple interface for systemd to use
<tyhicks> pitti: what we didn't get to are the systemd changes to use libapparmor
<mdeslaur> tyhicks: oh, cool
<mdeslaur> that should be reasonable trivial
<mdeslaur> reasonably
<pitti> smoser: right, that; that causes looong boot times (and adt-run timeouts; I could bump them, but it's still a nuisance)
<smoser> pitti, o'
<smoser> i'm open to suggestions
<pitti> tyhicks: ah, thanks; that sounds a lot better indeed
 * pitti still in meeting, sorry for lag
<pitti> yay, swift is back, re-enabling the autopkgtest minions
<infinity> pitti: Is this a misconfiguration in scalingstack, by not providing virtio_rng to the guests?
<pitti> infinity: could very well be, yes; the RNG takes aaages to initialize
<infinity> pitti: (Not that I'm agreeing with the new python behaviour, it seems a bit daft, but not starting instances with zero entropy certainly wouldn't hurt)
<pitti> *nod*
<infinity> pitti: Well, s/a bit daft/completely daft/ really.  Given the irresponsible people tend to fork hundreds of python scripts as if it were as cheap as POSIX shell, sucking your RNG dry when you might not even end up using it seems batty.
<pitti> infinity: I also don't quite see why one needs cryptographically secure hash randomization
<infinity> s/Given the/Given that/
<pitti> in most programming languages hashes have a reproducible order
<pitti> I did read the upstream report about the resource exploits with CGI arguments, but this appears to be a bit silly
<infinity> pitti: There's certainly that argument too, yes.  Though, I can certainly firmly place myself on both sides of that fence.  But I'd prefer, as a programmer and sysadmin, to make that decision per call, not have it made for me.
<pitti> if your CGI program allows me to specify a thousand GET arguments, then making that more efficient rather than just preventing so many args in the first place isn't a good fix
<infinity> pitti: I have zero hope of influencing python upstream, however, but nudging IS/LP to see if you can get some virtual rng might at least get you past the hump.
<infinity> I do wish we lived in a world where reliable randomness was a thing all computers had in abundance.  Can't quite sort out how we've failed so miserably to do that by now.
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> infinity: at first the upstream bug report sounded like a wontfix, but I think they were pondering adding a NOBLOCK flag to the getrandom call
<infinity> pitti: Yeah, I read the whole thread.  Still seems a bit up in the air, and the behaviour still seems incorrect (to me), even with the NOBLOCK, but meh.
<infinity> If I want cryptographically awesome randomness, I should ask for it, I think assuming it (and, indeed, draining my RNG to seed it on every python call) is silly.
<infinity> But, whatever.  One more reason for me to not be a Python fan.  As if I didn't have enough of those.
<pitti> I actually am, all the more reason to fend off insanity :)
<infinity> I suppose it could be worse, they could make /usr/bin/python3 dial-up Amazon and order a hardware fuzz dongle, and block until you plug it in.
<pitti> "throw a dice 200.000 times and type in the results"
<infinity> "No cheating, we've turned on your webcam to make sure."
<infinity> Hey neat, I just tore open my stomach.
<infinity> For some value of "neat".
<infinity> Also, ow.
<infinity> (afk)
<cjwatson> eek?
<mdeslaur> infinity: are you ok?
<rbasak> "reliable randomness was a thing all computers had in abundance."
<rbasak> That exists. It's called flaky hardware :-P
<smoser> anyone else seeing ubuntu connection failures ?
<dobey> everyone is yes
<smoser> k
<smoser> thanks
 * smoser out
<jbicha> why is https://launchpad.net/debian/+source/vlc missing the stretch branch (2.2.2-6 or the current 2.2.3-2) ?
<nacc> jbicha: https://launchpad.net/debian/+source/vlc/+publishinghistory
<nacc> jbicha: i'm guessing that pacakge isn't actually using lp for development, so it might be that someone just hasn't made a tracking branch appropriately
<nacc> jbicha: i'm not sure how those work in lp.net/debian, maybe ask on #launchpad
<jbicha> I believe it has the result that Ubuntu isn't auto-syncing vlc from Debian
<cjwatson> nacc: no that's not a "using LP for development" thing
<cjwatson> will check after call
<nacc> cjwatson: oh ok
<cjwatson> but stretch also isn't pertinent to auto-sync
<nacc> jbicha: yakkety is synced?
<cjwatson> sid is
<nacc> well, with a rebuild
<nacc> 2.2.2-6 from unstable, it seesm
<cjwatson> https://launchpad.net/debian/+source/vlc/+publishinghistory has it as deleted for some reason
<nacc> weird, and without an attribution as to who did it?
<cjwatson> it's entirely automatic
<cjwatson> checking logs
<nacc> ok, i thought even then it said by the bot or something
<cjwatson> nacc: not for /debian, that's more like reflecting external status than a deletion as such
<cjwatson> it could be deleted by ~janitor I guess but it wouldn't add any useful information
<cjwatson> jbicha: so in this case the problem is apparently that the dpkg-dev we're using can't unpack sid's vlc
<nacc> cjwatson: ok, i must be misremembering
<cjwatson> dpkg-source: error: unrecognized file for a v2.0 source package: vlc_2.2.3.orig.tar.xz.asc
<cjwatson> damnit
<cjwatson> https://lists.debian.org/debian-dpkg/2016/05/msg00041.html and thread
<jbicha> I hit that with bzr earlier today, bug 1587659
<ubottu> bug 1587659 in bzr-builddeb (Ubuntu) "bzr-bd chokes if tarball .asc in directory" [Undecided,New] https://launchpad.net/bugs/1587659
<cjwatson> separate issue
<jbicha> right
<cjwatson> I'm pretty cross at the excessively rapid introduction of this feature
<cjwatson> jbicha: can you file a bug against Launchpad itself about this?  we're clearly forced to do something
<jbicha> yes
<cjwatson> it'll probably also require some other changes to LP beyond the dpkg backport
<cjwatson> SourcePackageFileType for starters
<cjwatson> in fact we might need those first, would need to check
<cjwatson> ... yup, that sure looks like it'd be an IntegrityError or similar if we try to insert it without knowing its file type
<jbicha> filed bug 1587667
<ubottu> bug 1587667 in Launchpad itself "Import from Debian fails for source packages with included tarball .asc" [Undecided,New] https://launchpad.net/bugs/1587667
<cjwatson> thanks.  will try to get to it ASAP
#ubuntu-devel 2016-06-01
<cpaelzer> good morning
<sarnold> pitti: 1587727 (man that was quick :)
<karstensrage> #1587727
<pitti> sarnold: yep, known already :)
<pitti> sarnold: I clearly don't visit the right web sites :) (I get a crash with www.facebook.com which I never use, for example)
<sarnold> pitti: aha, good :) I thought you mentioned getting errors for it, wanted to make sure
<sarnold> pitti: hehehehehe
<pitti> Good morning
<sarnold> good morning ;)
<apw> pitti, i am not mad in thinking that we (at least) tried to make python3 the one and only python for xenial and up?
<pitti> apw: correct, we've been trying for a loong time
<pitti> apw: I think we actually succeeded on the server image? (at least for some time, maybe it came back)
<pitti> ah no, python2.7 is still on http://releases.ubuntu.com/xenial/ubuntu-16.04-server-amd64.list
<apw> pitti, but it would be a reasonable statement that it would be wrong introducing new python2 dependancies, that they should be python3
<apw> pitti, for xenial/yakkety
<pitti> right
<pitti> every such case throws us back
<sarnold> did desktop make it?
<sarnold> I thought something did :)
<apw> yeah i did too :)
<pitti> I think we managed to get rid of it on the cloud images
<pitti> no py2.7 there
<pitti> desktop still has it
<sarnold> I thught cloud-init was still python 2.. http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/bin/cloud-init uses #!/usr/bin/python   anway...
<apw> pitti, on systemd ... who supplied the resolvconf integration service ?
<pitti> apw: for networkd you mean? that was me
<pitti> and yes, it's horrible
<apw> pitti, yeah for networkd ... ok i think it may be flawed
<apw> it seems (and i may be doing it wrong) if i tell networkd about a DNS server which is specific to a domain
<apw> we shove that domain into /etc/resolv.conf and that then feeds back into resolved which sees /etc/resolv.conf updated
<apw> so it becomes a (indeed the) primary DNS
<pitti> apw: indeed, good point; so we need to look at whether the entry has Domains= as well, I figure, and then not supply it?
<pitti> apw: networkd already sends its DNS info to resolved anyway
<pitti> apw: this was mostly a shim for people using networkd without resolved
<apw> pitti, it is utterly unclear how that file is to be interpreted (other than telling you it should not :)
<apw> pitti, cirtainly it _is_ reporting in there that there is DNS but there is ROUTE_DOMAINS= in there as well, but i don't have enough configuration via networkd to know what it would look like if my primary DNS was configured in here
<apw> pitti, do you know how to do that so perhaps i can at least fake it
<pitti> apw: hang on, I'm trying in a VM (not using networkd on my desktop, or anywhere permanent)
<apw> pitti, oh you meany, making me use it :-p
<pitti> when did I? :-)
<apw> when you uploaded it to yakkety :)
<apw> well the resolved bits anyhow
<apw> as resolved gets half its config from networkd because thats not a layering violation
 * pitti doesn't understand these three comments, sorry
<pitti> apw: so for a global DNS server, you just get DNS= and OPER_STATE=, no other fields
<apw> i am trying to configure resolved which we switched to using, to do that i _have_ to configure networkd because that part of resolved configuration is stored only in files networkd also reads
<apw> pitti, and if you have both ?
<pitti> apw: so I think we must make /lib/systemd/system/systemd-networkd-resolvconf-update.service ignore files which have ROUTE_DOMAINS
<pitti> as these just can't be handled via glibc
<pitti> /etc/resolv.conf simply lacks syntax for this
<apw> that seems appropriate to me
<pitti> apw: do you want to file a bug about it to track it, or want me to?
<pitti> (we might eventually need to port this fix to xenial, if anyone decides to start using networkd there)
<sarnold> pitti: btw what are we going to do with the KillUserProcesses thing? it apparently didn't go over well on fedora when upstream flipped it..
<pitti> sarnold: it's reverted in 230-2, which is sitting in y-proposed
<pitti> this first attempt clearly didn't go well
<sarnold> pitti: woot :) thanks
<pitti> now we're getting flak from the other side for disabling it again :)
<pitti> sarnold: but I think this needs to be re-thought
<sarnold> figures
<pitti> sarnold: one recent proposal that I've seen is to use SIGHUP instead of SIGKILL
<sarnold> it's a nice feature to have available but to turn on by default seems a pretty drastic change
<pitti> which DTRT with tmux and screen (they stay running), but should still clean up gnome leftovers
<sarnold> that's way more unixy :)
<sarnold> nohup exists for applications that just inherit, applications which care can handle it ..
<apw> pitti, i'll file a bug now and have a look
<cpaelzer> pitti : is there a ppa for autopkgtest to get adt-buildvm-ubuntu-cloud for yakkety images working on a Xenial system?
<pitti> cpaelzer: not a PPA, but it's in xenial-backports (and trusty-backports too)
<pitti> cpaelzer: but it's still not working very well, I filed bug 1587188 yesterday
<ubottu> bug 1587188 in cloud-init (Ubuntu) "[yakkety regression] does not grow partition any more" [Undecided,New] https://launchpad.net/bugs/1587188
<pitti> i. e. the generated images have a horribly small root partition, so only small tests actually work
<cpaelzer> pitti: ah, your update is so recent I just don't have it got yet via backports - thanks for making me aware of the follow on issue
<pitti> not entirely sure if that's actually in cloud-init, or a regression in how we build the cloud images themeselves, though
<pitti> cpaelzer: oh, wait, which fix do you mean?
<pitti> cpaelzer: oh, the renamed images, I see
<cpaelzer> pitti: I was looking for the one with the name change loosing -disk1
<pitti> that fix is in 3.20.7
<cpaelzer> yeah that is why I started looking for a ppa, but backports is fine
<pitti> cpaelzer: I'm going to upload 3.20.8 to sid now, and as soon as this autosyncs, I'll backport it to t and x
<pitti> 3.20.7 just landed in testing
<apw> pitti, bug #1587762
<ubottu> bug 1587762 in systemd (Ubuntu) "systemd-networkd-resolvconf-update.service incorrectly published domain limited DNS servers to /etc/resolv.conf" [Undecided,New] https://launchpad.net/bugs/1587762
<pitti> cpaelzer: in the meantime, just locally apply http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=6676ed6ea
<pitti> cpaelzer: and the next time you'll get a package upgrade that will include the fix
<cpaelzer> pitti: I almost edited that lone myself before starting to think you likely fixed that already
<cpaelzer> pitti: thanks, I'll give the cloudinit bug at least a few minutes - maybe I can find something there for us
<cpaelzer> the probably easiest way to get fixes early until released is pull-lp/debian-source and then run with full path like /tmp/autopkgtest-3.20.7/tools/adt-buildvm-ubuntu-cloud
<cpaelzer> somewhat nicer than to patch the real system :-)
<pitti> cpaelzer: just run it out of git :)
<pitti> cpaelzer: that's what I do in production
<cpaelzer> +1 evil overlord points for pitti for "run it out of git in production"
<pitti> well, if I do a fix I don't want to wait a day before I can roll it out, people need it NOW :)
<pitti> and while autopkgtest's tests are annoying (they take ~ 30 mins), they are also rather effective at guarding against regressions
<pitti> and even then, git reset --hard HEAD^, and life goes on
<apw> pitti, cna i use awk in this context, rather than sed?
<pitti> apw: sure, as long as it gets along with mawk
<pitti> apw: btw, it might be easier to actually not run this horrible thing at all if resolved is being used
<pitti> apw: this is a shim for using networkd without resolved, but with resolvconf and software that uses /etc/resolv.conf directly
<pitti> it's not needed for anything else
<apw> yeah that makes sense, is there an easy way to tell that ?
<mwhudson> i'm trying to use sbuild to build an i386 package on my laptop and it's complaining about
<mwhudson>  sbuild-build-depends-core-dummy:amd64 : Depends: crossbuild-essential-amd64:i386 but it is not installable
<apw> mwhudson, are you building that in a amd64 chroot or something ?
<mwhudson> i'm confused, i don't think i need or what any cross building nonsense here
<pitti> apw: first iteration is to add "ConditionPathExists=!/run/systemd/resolve" to /lib/systemd/system/systemd-networkd-resolvconf-update.path
<mwhudson> apw: i made it with mk-sbuild --arch i386 yakkety so i hope now
<mwhudson> *not
<mwhudson> and $ schroot -c yakkety-i386 --directory / -- uname -m
<mwhudson> i686
<apw> yep that looks believeable
<mwhudson> ah passing --build i386 --host i386 is happier
<mwhudson> or indeed --arch i386
<apw> pitti, so without the other fix or with that together
<apw> pitti, as i am assuming that will fix my issues completely
<mwhudson> does anyone happen to know the incantation to get the filet to make --extra-repository-key=file.asc work for a ppa?
<mwhudson> i'm sure i can figure it out but...
<pitti> apw: right, if you don't run this unit at all, it'll fix things for you
<pitti> apw: I'm just not sure whether we can get away with this
<apw> pitti, well i have done the other bit too, i'll add a diff to the bug
<apw> pitti, then we can think about the test
<pitti> apw: cheers
<pitti> apw: I'll write that (before applying the patch)
<pitti> apw: still battling with armhf lost autopkgtests and infra, getting to this later
<apw> pitti, no rush at all
<apw> pitti, and this way i can hand apply the fix and see if it works in practice
<mwhudson> hm apparently that option just doesn't work?
<mwhudson> or doesn't do what i think
<mwhudson> hacked around, anyway
<juliank> pitti: bug 1569099 got a verification-needed, but that does not make much sense, it's a duplicate of bug 1560797 which is already closed in xenial with the same commit.
<ubottu> bug 1560797 in apt (Ubuntu Wily) "duplicate for #1569099 apt does not configure Pre-Depends: before depending package" [High,Fix released] https://launchpad.net/bugs/1560797
<ubottu> bug 1560797 in apt (Ubuntu Wily) "apt does not configure Pre-Depends: before depending package" [High,Fix released] https://launchpad.net/bugs/1560797
<apw> pitti, ok patch attached and cowboy'd onto my machine ... seems to be working at least for now
<juliank> Anyway, what is missing for the apt SRU to be moved to -release? From what I see in bug 1538438, that one should be fixed, but still verification-needed. And bug 1580952 has verification-needed, but no test case, as it's a new-micro-release-type-SRU
<ubottu> bug 1538438 in apt (Ubuntu) "apt-helper crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [High,Triaged] https://launchpad.net/bugs/1538438
<ubottu> bug 1580952 in apt (Ubuntu Xenial) "[SRU] Update apt/xenial to 1.2.12" [Medium,Fix committed] https://launchpad.net/bugs/1580952
<pitti> juliank: for xenial you mean? nothing, but until yesterday it didn't age for 7 days yet; today it's fine
<juliank> Ah OK
<pitti> juliank: sorry, that was for wily
<pitti> juliank: which refers to bug 1575877 which is v-done and 7 days now
<ubottu> bug 1575877 in apt (Ubuntu Wily) "no_proxy ignored if https_proxy set" [Medium,Fix committed] https://launchpad.net/bugs/1575877
 * pitti releases
<juliank> Yeah, xenial was uploaded 2016-05-12
<juliank> so it's far beyond schedule
<pitti> juliank: look at http://people.canonical.com/~ubuntu-archive/pending-sru.html
<pitti> juliank: the dupe bug is striked through, so irrelevant; but the two other bugs weren't verified, and it's not fixed in yakkety
<juliank> Eww, and some autopkgtest regressions
<pitti> i. e. bug 1538438 (not fixed in y, not verified), and bug 1580952 (missing test case, not verified)
<ubottu> bug 1538438 in apt (Ubuntu) "apt-helper crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [High,Triaged] https://launchpad.net/bugs/1538438
<ubottu> bug 1580952 in apt (Ubuntu Xenial) "[SRU] Update apt/xenial to 1.2.12" [Medium,Fix committed] https://launchpad.net/bugs/1580952
<juliank> pitti: Oops,  the first is fixed in yakkety
<juliank> 1.2.12 is the bugfix cherry-pick of 1.3~exp1 in yakkety
<juliank> The autopkgtests are strange, but unrelated it seems: sbuild fails with "E: Unable to find a source package for procenv" and apport with "https://launchpad.net/ubuntu/+archive/primary/+files/libacl1-dbgsym_2.2.52-3_i386.ddeb gnutls_handshake() failed: The TLS connection was non-properly terminated."
<rbasak> pitti: I'm sure I've asked you this before, but I can't find a reference right now. systemd is hiding errors from postinst invoke-rc.d, and as a result it doesn't end up in bug reports. Can we amend apport to provide it in the general case?
<rbasak> pitti: example: bug 1587695
<ubottu> bug 1587695 in amavisd-new (Ubuntu) "package amavisd-new 1:2.10.1-2ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete] https://launchpad.net/bugs/1587695
<rbasak> pitti: perhaps on invoke-rc.d failure, invoke-rc.d should automatically dump "systemctl status" to stderr?
<rbasak> Or else, I'd like some other way for apport to pick it up.
<pitti> juliank: right, the apport one is a glitch, I'll retry
<juliank> pitti: Yes, and the sbuild one also happens in the most recent build with apt 1.2.10ubuntu1
<pitti> juliank: sbuild, this also apparently happesn with the xenial-release apt, as it also failed for the proposed dpkg: http://autopkgtest.ubuntu.com/packages/s/sbuild/xenial/amd64/
<juliank> yeah
<pitti> so something definitively broke this, but not the new apt
<juliank> pitti: What to verify about bug 1580952? I don't think this makes a whole lot of sense there.
<ubottu> bug 1580952 in apt (Ubuntu Xenial) "[SRU] Update apt/xenial to 1.2.12" [Medium,Fix committed] https://launchpad.net/bugs/1580952
<pitti> I suggested "Please add an SRU test case which exercise the code paths that changed here."
<juliank> It's a "New upstream microrelease" with test cases in it.
<pitti> maybe at least some small test plan with installing/upgrading various packages, downloading a source, etc.
<pitti> to make sure it'snot completely broken
<pitti> right, that too
<juliank> I mean, the autopkgtests check all those things in an automated integration test case fashion, and users apparently use it successfully (at least the one who checked that no_proxy worked correctly), so...
<pitti> juliank: ok, agreed
<pitti> juliank: I updated the two bugs
 * pitti releases
<juliank> Yay!
<pitti> juliank: thanks for the updates
<juliank> pitti: I already started queuing (currently 2) commits for 1.2.13! :) - should arrive in a few weeks. Especially fancy ones like "fail instead of segfault on unreadable config files" and the easy "Provide complete apt bash completion"
<juliank> I'm trying to get more translations in as well, but the merge gets confusing (anyone knows a .po merge helper?)
<pitti> juliank: msgmerge ?
<pitti> rbasak: hm, no amavis messages in https://launchpadlibrarian.net/262668434/JournalErrors.txt, so I'm not sure if that'd actually help
<juliank> Hmm, yeah, https://stackoverflow.com/questions/16214067/wheres-the-3-way-git-merge-driver-for-po-gettext-files says we can build a 3 way merge driver with that
<pitti> rbasak: might be that this is a forking service which only outputs to log files, not to stdout/err?
<pitti> rbasak: ah, wait, this only shows messags with priority >= warning, so maybe that's why
<pitti> rbasak: yeah, I guess we can amend the ubuntu hook for package failures to include the status
<pitti> apw: nice fix! (I'd just do s/routable/route_domains/)
<rbasak> pitti: thanks. I could see you were busy on something else so I filed bug 1587791 so as not to forget.
<ubottu> bug 1587791 in apport (Ubuntu) "apport hides systemd postinst service start failure error messages" [Undecided,New] https://launchpad.net/bugs/1587791
<pitti> thanks
<pitti> rbasak: yeah, sorry; still working on some test infra fallout
<rbasak> pitti: np. I'd like to see this fixed (will save us bug triaging time) but it's hardly urgent.
<apw> pitti, yeah makes more sense feel free to hack her up ;)
<pitti> tinoco, xnox: aupkg02 (10.100.0.13) is down again; can you please prod it?
<tseliot> pitti: aptdaemon can't be installed in yakkety, any ideas? https://launchpadlibrarian.net/262720256/buildlog_ubuntu-yakkety-amd64.ubuntu-drivers-common_1%3A0.4.19_BUILDING.txt.gz
<pitti> tseliot: because of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#packagekit, the proposed version is incompatible
<pitti> see bug 1496292
<ubottu> bug 1496292 in packagekit (Ubuntu) "Needs to be ported to packagekit 1" [High,Confirmed] https://launchpad.net/bugs/1496292
<tseliot> pitti: ok, so it is a known issue. I need to backport some code from u-d-c to xenial (to give back about 1 second on boot), so I'll just ignore yakkety for now
<cpaelzer> pitti: the resizing issue you reported is actually in cloud-utils, I created a MP for smoser to consider - details in the bug
<cpaelzer> that said back to what I actually wanted to do ... or lunch :-)
<pitti> cpaelzer: yay, you figured it out? thanks!
<caribou> Locu
<caribou> oups, sorry
<cpaelzer> pitti: just verified, 'til the fix hits the archive booting into the adt guest with your vm script and running "sudo resize2fs /dev/vda1" gets you images to work with for now
<pitti> cpaelzer: greaet
<cpaelzer> pitti: I was happy too early about the yakkety adt now being fine a few hours before
<cpaelzer> the disk size is good now but something (tm) crashes it now
<cpaelzer> do you have any notes / best practise on debugging adt-run / adt-virt-qemu?
<cpaelzer> with all debug enabled I see it booting fine, but then kill the qemu by a sig 15 when executing "adt-virt-qemu: DBG: execute-timeout: /tmp/adt-virt-qemu.7vsnggp9/runcmd true"
<cpaelzer> if it is a timeout it is rather fast - like 2 seconds :-)
<pitti> cpaelzer: should be 5 s
<pitti> cpaelzer: hm, and that's with the PYTHONHASHSEED=0 hack already?
<pitti> as this has this very symptom
<cpaelzer> pitti: I'll build from git as you do and let you know if anything in there fixes my issue
<cpaelzer> pitti: do I need to recreate the guest images to pick up the change?
<pitti> cpaelzer: shouldn't be necessary really
<cpaelzer> pitti: yeah - out of git is good, thanks
<pitti> cpaelzer: which version do you have installed? 3.20.7?
<mitya57> sil2100, hi, do you have any thoughts @ https://code.launchpad.net/~mitya57/appmenu-qt5/lp1574699/+merge/294381 ?
<pitti> cpaelzer: aside from the image rename I don't see a relevant change since 3.20.6
<cpaelzer> pitti: started with 3.20.4, then used 3.20.7 for the image create, but back to .4 for run
<cpaelzer> pitti: now I just switched to git to stay ahead just as you do
<pitti> cpaelzer: .4 won't work, that doesn't have the PYTHONHASHSEED hack
<pitti> cpaelzer: you need >= .5 for running yakkety images
<pitti> cpaelzer: this hack applies to adt-run time, not to image creation time
<cpaelzer> which is why the adt-run out of git now got it working
<cpaelzer> good
<pitti> right
<pitti> 3.20.8 is uploaded to sid, but it'll take another half day or so to land in yakkety;  I'll backport it tomorrow
<pitti> infinity, sarnold: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd is just landing
<pitti> with the unkill change
<tumbleweed> cjwatson: I've hit something that feels very much like https://bugs.debian.org/708123 in an upgrade from 12.04 to 14.04 (and then we went to 16.04)
<ubottu> Debian bug 708123 in grub-pc "[grub-pc] grub2 (2.00-14) fails to install on RAID arrays (rescue, boot is broken)" [Important,Open]
<tumbleweed> I'll grab an image of it and muck around in qemu
<cjwatson> cyphermox: ^- can you deal with that?
<cyphermox> ack
<cyphermox> tumbleweed: filed a bug?
<tumbleweed> I was wondering what you'd want to look at
<tumbleweed> I'm going to start by trying to upgrade the metadata in a VM copy of it
<tumbleweed> symptoms are: rescue prompt shows no md devices, one has to boot it off a raid member
<tumbleweed> and the raid modules all seem to be present
<tumbleweed> also, rescue mode seems racy :P
<ginggs> sil2100: hi, can you rebuild mtp for yakkety please? it still depends on boost from xenial
<sil2100> ginggs: hey! Ok, no-change rebuild on its way
<ginggs> sil2100: thanks!
<sil2100> ginggs: hm, strange that it deps on the old boost still, I did a no-change rebuild of it on the 20th of May already
<ginggs> sil2100: mtp (0.0.4+16.04.20160413-0ubuntu2) xenial; urgency=medium  <= distribution is xenial
<ginggs> Copied from ubuntu xenial in Stable Phone Overlay PPA by Ubuntu Archive Auto-Sync <= this sounds weird to me
<sil2100> ginggs: ah, right, my bad - I guess the rebuild didn't happen in the end
<sil2100> Thanks :)
<pitti> hallyn: demoting cgmanager to universe for now, as per http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<pitti> hallyn: only the binary for now; we still have a few rdepends of the library in main, like upstart and ubuntu-core-libs
<pitti> hallyn: is cgmanager still actually a thing which we want to support, or is that being phased out in favor of lxcfs etc?
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<flaiks> is there a way to get kernel 4.6 running on 16.04 ? i need it for a required fix for my t460s
<ikonia> flaiks: we just discussed this
<mapreri> what usually people do in ubuntu when a package ftbfs in one arch for reason nobody can't get? â are partial removals a thing?
 * mapreri is looking at cowdancer
<ikonia> thats not what this channel is for,
<ikonia> flaiks: the support channel is #ubuntu
<jrwren> ikonia: try #ubuntu-kernel you migth also ask if the patch that you see in 4.6 has been backported to the ubuntu 4.4 kernel
<ikonia> jrwren: not for me, but thank you, it's not been backported for the record for flaiks
<dobey> mapreri: i usually fix the problems, in my packages
<jrwren> ikonia: sorry. I meant to direct taht to flaiks
<mapreri> dobey: "for reason nobody can't get" implies we 1/ can't figure out the problem 2/ can't reproduce it 3/ in debian just builds.
<mapreri> would be awesome if you can look at it and see if you can make it out! â¥
<ikonia> jrwren: not a problem at all
<mapreri> not having porterboxes available doesn't really help either (the actual maintainer tried in qemu but no luck)
<hallyn> pitti: phased out
<dobey> mapreri: well i don't know enough about the code and its memory model, but it would appear that the memleak test is failing for some reason. i see in the shell script for that test a comment about LD_PRELOAD causing a memleak, so perhaps related?
<cjwatson> mapreri: Partial removals are certainly possible, though we prefer to avoid the cop-out option if at all possible :)
<cjwatson> mapreri: worth trying with -O2
<cjwatson> mapreri: (the "obvious" difference between Debian and Ubuntu that's ppc64el-specific is that Ubuntu's toolchain defaults to -O3 on ppc64el)
<cjwatson> so DEB_MAINT_CFLAGS_STRIP := -O3 and DEB_MAINT_CFLAGS_APPEND := -O2 or equivalent
<mapreri> interesting.
<mapreri> (didn't know it)
<cjwatson> mapreri: you can try it in a PPA
<mapreri> ya
<cjwatson> err s/DEB_MAINT_CFLAGS/DEB_CFLAGS_MAINT/g
<dobey> ah yeah, that makes sense given that it's memory related
<mapreri> i wanted to try, before that, a no change rebuild in a ppa: https://launchpad.net/~mapreri/+archive/ubuntu/ppa/+build/9845065 â it bult..
<mapreri> could be related for it being virtualized?
<cjwatson> mapreri: virt/non-virt makes no difference for ppc64el
<cjwatson> so let's try just retrying that build
<cjwatson> of course it could be non-deterministic
<mapreri> - failed
<mapreri> cjwatson: any other suggestion? :)
 * mapreri would be very happy to have it building!
<mapreri> i have to go out for some hours now, but please do feel free to dump ideas (or even try out stuff!)
<cjwatson> mapreri: -O2 would definitely be my next suggestion
<cjwatson> also diff build logs and see if that throws up anything (though I don't immediately spot anything very obvious)
<mterry> seb128, so are we OK with switching packages to geoclue-2.0?  Did we ever find an actual solution for them?  (I see that empathy got switched to 2.0)
<seb128> mterry, yeah, see the migration bug, seems like robert_ancell fixed our geoip server to talk the same api that google/mozilla use
<dobey> mterry: is this where you end up having to write a backend for geoclue-2.0 that uses ubuntu-location-service?
<seb128> which makes it compatible with geoclue2
<seb128> mterry, https://code.launchpad.net/~robert-ancell/canonical-is-puppet/geolocation-api/+merge/296077
<mterry> cyphermox, in bug 1585863, $4 suggested modifying a network-manager patch of yours -- basically dropping your changes to src/supplicant-manager/nm-supplicant-interface.c -- can you comment there?  I was about to sponsor it, but wasn't sure I knew what the deal was there
<ubottu> bug 1585863 in OEM Priority Project xenial "WiFi malfunction after suspend & resume stress" [Critical,New] https://launchpad.net/bugs/1585863
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<brainwash> is pkexec broken? pkexe whoami  gives me:
<brainwash>  polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
<brainwash> pkcheck --list-temp --> Error getting session: No session for pid <PID>
<mapreri> cjwatson: is the version of sbuild used for the primary archive builds and for the ppa builds the same?  I see weird differences in the output like this (just curiosity):
<mapreri> [-PWD=/Â«PKGBUILDDIRÂ»-] {+PWD=/Â«BUILDDIRÂ»/cowdancer-0.80+ppa0+}
<mapreri> (this is the diff, for completeness: https://volatile.mapreri.org/2016-06-01/821944dc8105ba888c8857b2cacb7737/diff.html )
<mapreri> (actually, is the full logs dwdiffed)
<cjwatson> mapreri: Yes, it's the same; congratulations, you've found an sbuild bug to do with + handling
<mapreri> ahahahah \o/
<mapreri> cjwatson: bug in which it can't correctly compute PKGBUILDDIR and sed it over the build log?
<cjwatson> indeed
<cjwatson> probably needs to quote a regex harder
<pitti> hallyn: ok, thanks; I figure ubuntu-app-launch and ubuntu-core-libs will need some work then, but systemd-shim is gone already
<mwhudson> does anyone have a script for doing a no-change rebuild of a package in a ppa?
#ubuntu-devel 2016-06-02
<hallyn> pitti: mind you i think it's a shame :)
<pitti> Good morning
<didrocks> good morning pitti
<pitti> bonjour didrocks !
<brainwash> pitti: hi. does pkexec work for you? running "pkexec whoami" gives me:
<brainwash>  polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
<brainwash> bug 1288786
<ubottu> bug 1288786 in policykit-1 (Ubuntu) "pkexec does not launch graphical authentication" [Undecided,Confirmed] https://launchpad.net/bugs/1288786
<brainwash> same error message in comment #7
<mwhudson> doko: ping, did you see https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1586872
<ubottu> Launchpad bug 1586872 in gcc-6 (Ubuntu) "gccgo: -buildmode=shared and cgo don't work together" [Undecided,New]
<mapreri> cjwatson: really not totally sure how this could be possible, but indeed using -O2 instead of -O3 (at least, that's the only relevant change I see) made cowdancer build on pcc64el.
<mapreri> https://volatile.mapreri.org/2016-06-02/d177d0ca47a32d7e2a8a05675de28948/0.80_0.80u1.html â if you are fancy looking the diff of the 2 logs and figure it out :|
<mapreri> Thank you very much for the precious hint!
<cjwatson> np
<Odd_Bloke> What package creates/manages /etc/nsswitch.conf?  (And how can I work this out for myself in future?)
<brainwash> Odd_Bloke: try  dpkg -S /etc/nsswitch.conf
<rbasak> Odd_Bloke: failing that (which it will as it isn't a conffile), "grep nsswitch.conf /var/lib/dpkg/info/*" is a quick hack to find maintainer scripts on your system that reference it.
<rbasak> Odd_Bloke: looks like the answer is base-files.
<Odd_Bloke> brainwash: rbasak: Thanks! :)
<Unit193> rbasak: Don't forget apt-file 'nsswitch.conf'
<ubuntu577> Hello all,  need help  .. how to rebuild the ppa to another architecture.
<ubuntu577> sorry .. I mean  how to build  Archives  to another architecture  through ppa
<cjwatson> ubuntu577: PPAs automatically build packages for all architectures they're configured to build for, but you can enable some additional architectures that aren't enabled by default using the "Change details" page on the PPA
<xnox> ogra_, do you have time at all to look into initrafs-ubuntu-touch thing? it has not been rebuild for a while. I've tried dropping adbd (apperantely doesn't work and not available on arm64) and enable arm64 build and no dice.
<xnox> it build locally, but fails in a launchpad ppa.
<xnox> ogra_, https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/9844912
<ogra_> xnox, hmm
<ogra_> + fakechroot chroot ./build apt update
<ogra_> /usr/sbin/chroot: failed to run command âaptâ: No such file or directory
<ogra_> why would it not run apt-get
<zander> I'm trying to upload a packaged version of my software to launchpad. It gives me "rejected" with no useful error message. Is there anyone that can help out?
<xnox> ogra_, it did run apt-get before, and resulted in similar error messages "apt-get not found" changed to apt, no dice.
<xnox> ogra_, somehow debootstrap log shows loads of errors too.
<xnox> locally it builds fine.
<cjwatson> zander: Can you provide your dput command line?
<ogra_> weird
<zander> cjwatson: dput ppa:bitcoinclassic/bitcoinclassic  bitcoinclassic_0.12.1-trusty1_sources.changes
<cjwatson> zander: Are you sure you didn't get a useful error message?  Our logs show that we sent you one indicating that dpkg-source failed to extract the source package
<cjwatson> starting with "dpkg-source failed for bitcoinclassic_0.12.1-trusty1.dsc [return: 2]"
<cjwatson> it's slightly cryptic I'll grant ...
<zander> The full text is http://paste.ubuntu.com/16918003/
<zander> I can't find the actual error.
<zander> Nothing I can use to fix it, anyway.
<cjwatson> zander: So one thing that this can sometimes be is that our production systems (unfortunately) still run on precise, and it's occasionally possible to construct a source package that precise's dpkg-source obscurely fails to unpack like this.
<cjwatson> zander: Can you put the source package somewhere I can see?  I recognise most of the usual causes of this by now
<zander> sure
<ogra_> xnox, i think the deboostrap.log looks fine though (the pre-dep moaning is notmal IIRC)
<ogra_> *normal
<zander> cjwatson: http://thomaszander.se/foo/
<cjwatson> zander: Right, the problem is that debian/patches/series lists a patch that doesn't exist.  In fact dpkg-source in xenial fails to unpack the package in a similar way.
<zander> isn't series supposed to list the release? Trusty in this case?
<cjwatson> No.
<cjwatson> Not even a little bit :)
<cjwatson> It's a quilt patch series.
<zander> ok, I guess I misread a tutorial somewhere :)
<zander> My intention was to host several 'versions'. For the different ubunutu releases.
<cjwatson> You could probably just delete debian/patches/ entirely, as it is.  But if you need patches in future, then each line in debian/patches/series should be a file in debian/patches/ which is a patch file applied to the upstream source code.  You'd normally manage those with quilt or with some more sophisticated tooling around it.
<zander> Since I develop on debian, I would just change the actual sourcetree. I'll delete the dir.
<zander> cjwatson: its building now \o/
<zander> So, how can I get it build for more than one version of ubuntu?
<cjwatson> zander: Often it's entirely unnecessary to have multiple builds, and you can just upload to the oldest series you want to support and then copy it forward to all the other ones using "Copy packages" in your PPA and telling it to copy existing binaries.
<zander> ah
<cjwatson> zander: But if you really need to build separately for different Ubuntu series, then you can just build source packages with different versions (usually just changing the bit after the last "-") and a different target in the top entry in debian/changelog.
<zander> That makes sense. thanks
<zander> Another question. Is there a simple way to append the filelist to the .dsc file?  I now manually run things like sha1sum.
<pete-woods> pitti: thought it had been a while since I nagged about python-dbusmock, so here's a little PR for you (https://github.com/martinpitt/python-dbusmock/pull/21)
<cjwatson> zander: Err, you should never have to edit the .dsc by hand.  What are you finding that you need to add to it?
<zander> cjwatson: 'add to it'... I need to *create* it.  Since I have not found any tool to do so for me.
<cjwatson> zander: debuild -S
<cjwatson> zander: really really do not write the .dsc by hand :-)
<cjwatson> debuild is a wrapper around dpkg-buildpackage, and you can use that too, but debuild is a little more convenient
<zander> I tried to run that a couple of times. Never got any useful output from it.  For instance; http://paste.ubuntu.com/16919442/
<cjwatson> zander: Was that before or after you removed the nonsense debian/patches ?
<zander> thats just now. I removed the patches dir.
<cjwatson> zander: can you post 'find -ls' from there so that we can orient ourselves?
<cjwatson> debuild -S is what basically everyone else uses so you have some weird corner case here
<cjwatson> zander: It sounds like perhaps you have "debian" as a symlink, which isn't allowed
<zander> http://paste.ubuntu.com/16919488/
<zander> Hmm, I'll move the debian dir...
<cjwatson> Right, the debian directory must always be at the top level of the package's ordinary source tree, and not a symlink
<zander> but its Ok to not have it inside the .orig.tgz ?
<cjwatson> Indeed, it's normal not to have it in the orig.
<zander> Well, i guess I got bitten by lots of little rules :)
<zander> But it seems to work now. Which makes me quite happy.
<cjwatson> Excellent
<mgedmin> would be nice to improve the error message about 'debian' not being a directory
<mgedmin> e.g. "add_directory() only handles directories at /usr/share/perl5/Dpkg/Source/Package/V2.pm line 556." doesn't even mention what the not-directory was
<pitti> xnox, infinity, tinoco: aupkg02 (10.100.0.13) is still down (since yesterday), could one of you please torture it with the right stick?
<xnox> pitti, it has a stalled task on the CPUs
<xnox> with kthreads starved for 17227361 jiffies
<xnox> force poweroff, rebooting
<xnox> pitti, booted
<tuxinator> hi all, since some time (only have time to investigate now, my mirror does not sync from cdimage.ubuntu.com::cdimage/
<pitti> xnox: cheers!
<tuxinator> the error message is only  change_dir "/daily/current" (in cdimage) failed: No such file or directory (2)
<tuxinator> at my site the directorys exist
<arges> bdmurray: can you sru-review kpatch/xenial today? Thanks
<bdmurray> arges: sure
<nacc> rbasak: so i had to remove one of our optimizations from the algorithm -- the one that looks for launchpad versions 'greater than' the tip's version when doing an import to an existing repository. Because of the case of versions going backwards potentially ... so i'm now using the publishing date and asking for published history after a committed date (this also minimizes our lp traffic). Does that
<nacc> seem sane? I'm thinking I may fudge it a little bit to make sure we don't 'miss' any publishes (still considering corner cases)
<rbasak> nacc: I think going by publishing date is fine. That's what I thought we were doing already!
<nacc> rbasak: launchpad_revs_greater_than(debian, last_debian_version) (and similar for ubuntu)
<nacc> rbasak: so we were (in my old undrstanding) using the versions, not the dates
<rbasak> nacc: fair enough. We've changed plans so many times I lost track, sorry. I think publishing dates is fine as long as it doesn't interfere with import ordering in some unexpected way.
<rbasak> (I don't see why it would).
<rbasak> And in fact, going by publishing date is probably more accurate for the pocket parent in this new world order.
<nacc> rbasak: ack, that's what i'm thinking too -- i just need to make sure we're capturing and passing the date properly as far as the JSON goes (so we don't miss stuff published, e.g., the same day let's say)
<nacc> rbasak: a new interesting case, python-pip (https://launchpad.net/ubuntu/+source/python-pip/+publishinghistory?batch=75) -- 8.1.2-1 was in debian/sid (first seen there) then yakkety-proposed then yakkety-release. Our history indicates the version from debian/sid was copied to yakkety-proposed and yakkety, as opposed from debian/sid to yakkety-proposed and then from yakkety-proposed to yakkety-release.
<nacc> This turns out to be true based upon the publishing logs (both indicate copies from debian/sid). But is that always the case?
<nacc> ogasawara_: is there a reason there aren't xenial directories in http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D ? Apologies in advance if you're not the right person to ask :)
<rbasak> nacc: I'm not sure why that happened. Something to do with archive opening perhaps? It'll create some slightly different history in our import but is otherwise OK, right?
<nacc> rbasak: yeah, i'm not 100% either -- to clarify, the algorithm as written now, for a version that has already been imported previously, will mark as the 'changelog parent' the commit corresponding to the first import of that version. I'm just trying to think if that is correct or not :)
<rbasak> nacc: if it does affect us then I'd have to ask someone like Colin to explain.
<rbasak> nacc: would a parent minimisation function help us here? If the commit has two parents A and B, and A is an ancestor of B, then eliminate A.
<rbasak> I'm not sure if that makes sense or not for us. Not thought it through.
<nacc> rbasak: we probably should add something liek that, but i don't think it applies to this particular case. The two parents are distinct (the pocket parent is the old yakkety release version, correctly)
<nacc> rbasak: from a code content perspective our algorithm is correct; i'm just not sure we have enough information from any source to know where something gets copied from, let me see if launchpadlib says
<ogasawara_> nacc: I see we have xenial for 4.4.9, .10, .11, and .12...is there a specific version you were hoping to find?  I don't believe we have anything earlier than that because xenial hadn't been officially released until end of april, so build after that would use xenial's config.
<nacc> ogasawara_: i might just be misunderstanding hte layout of the directories, but there is a 4.6-rc6-wily, but not a 4.6-rc6-xenial ?
<nacc> ogasawara_: in fact those 4 you found are the only xenial, but there are many more for wily and (now) yakkety
<nacc> ogasawara_: someone in #ubuntu was asking how to test mainline on xenial for a bug report, and i wasn't sure if we'd normally advise them to just use latest-yakkety (and if that would work properly, i'd worry about deps)
<rbasak> nacc: do we need to know where the code was copied from? Since the trees are identical and a previous uploader (or archive admin) could have copied from a different pocket (but the same version), then from a source package perspective, is it fundementally part of the data we're trying to capture at all?
<nacc> rbasak: no, we probably don't. But I want to make sure we don't accidentally lose some publishing information. So let's say that in this case, the yakkety version had gone debian -> y-proposed -> y-release. There would be no link in our git tree from the y-release commit to y-proposed, because the first import was in debian and that's where we'd point the 'publish parent' commit to.
<rbasak> nacc: I understand how that loses some information about publication ordering, but my initial feeling is that it's OK. We're interested in the history of the code, and the code hasn't changed. One might consider all of the commits sharing a version to be bundled together, and as a whole the graph edges to and from the bundle would be correct.
<nacc> rbasak: yep, absolutely
<nacc> and in theory, the one in any other pocket *did* come from the first one, by definition, aiui
<nacc> so we're bsaically doing a bit of optimized parent following :)
<rbasak> Yeah. Sort of like git and renames again :)
<ogasawara_> nacc: I'm reaching out to apw for clarification as I actually was only expecting to see 4.6-rc# builds against yakkety
<nacc> ogasawara_: ack, thanks! yeah, i think that's what is confusing the user (and me) :)
<cjwatson> nacc: the copy-from information in fact tells you where it was originally uploaded to, not the previous hop in the chain; so what you're seeing is expected.
<nacc> cjwatson: ah ok, thanks for clarifying -- that makes me happy that our algorithm will match that :)
<nacc> cjwatson: even if accidentally...
<RobertDupont> hello guys
<RobertDupont> I found a bug in an iptables module and I was wondering if I have to report it to iptables or kernel
<RobertDupont> rule is inserting just fine
<RobertDupont> it is just not matching when it should be on 16.04 (works fine on 14.04)
<RobertDupont> does anybody know
<RobertDupont> or you're just not interested in bug reports?
<cjwatson> People aren't very likely to respond to bug reports on IRC, especially if they're a bit ambiguous or difficult to diagnose immediately.  Just report it to wherever you think most sensible, that's better than nothing
<RobertDupont> I'm just asking which package I should file it to
<cjwatson> (I don't know the answer to exactly where it belongs, though I'd suspect the kernel.  But I reject your false dichotomy that either somebody here knows or nobody is interested in bug reports)
<RobertDupont> well, I've filed a couple of reproductible bug reports and nobody has fixed them
<RobertDupont> some bugs have been present since 2008 and haven't been fixed
<cjwatson> Sure, but also lots of bugs are fixed all the time.  Human effort is sadly finite
<cjwatson> Speaking of which, end of day and dinnertime
<RobertDupont> apparmor, snort and a few other big ones
<Logan> nacc: hey, have you been working on the phpunit-mock-object merge? phpunit is still uninstallable because it depends on phpunit-mock-object >= 3.1, and we have 3.0.6-1+ubuntu1
<nacc> Logan: let me do that right now
<Logan> thanks!
<nacc> barry: https://code.launchpad.net/~usd-import-team/ubuntu/+source/python-pip/+git/python-pip
<barry> nacc: cool!
<nacc> barry: i took a quick look, it seems correct, and didn't provide any warnings, errors, etc., but do please take a look when you can and let me know if anything looks odd
<barry> nacc: will do
<nacc> barry: thanks! also just uploaded the helper script for merges at https://code.launchpad.net/~usd-import-team/usd-importer/+git/usd-importer
<nacc> and that's the current importer's code too (same repository)
 * barry nods
<rbasak> nacc: looking at usd-import-reconstruct-merge, it looks good, just a couple of comments.
<rbasak> Only from a quick read of the code, so maybe I've got it wrong.
<nacc> rbasak: ack, it might need some love, i just cobbled it together last night
<rbasak> 1) dsc_commit_tag looks like it might match too much, for example ubuntu1.1 when ubuntu1 is being looked for.
<nacc> rbasak: ah you're right, i'll anchor it
<rbasak> 2) Never mind, I missed something. Looks good :)
<nacc> rbasak: or i could just use -F right?
<nacc> oh but that would still need anchoring
<nacc> i guess `grep -F -w` ?
<nacc> or -x, not sure, i'll read :)
<rbasak> I'd use a regexp. Because you're looking for /^(import|upload)\/<version>$/, right?
<rbasak> nacc: BTW, we should probably pull together my ubuntu-git-tools repo with the usd-importer repo at some point. No point having them separate.
<nacc> rbasak: ack, you're right, becauseall i have is the version, sorry
<nacc> rbasak: yep, they are starting to be more related
<hallyn> smb: hrmph.  you're telling me my libvirt upgrade/transition stuff was wrong?
<smb> hallyn, no, in the end the problem is that we upgraded before it was done completely, so was not executed. I just finishing up some upload that is more persistent
<bdmurray> happyaron: How is bug 1297849 related to the network-manager-openconnect upload in xenial-proposed?
<ubottu> bug 1297849 in network-manager-vpnc (Ubuntu) "[SRU] Virtual private network connection fails after distribution upgrade due to outdated Network Manager configuration files" [High,Triaged] https://launchpad.net/bugs/1297849
<smb> hallyn, That systemd suddenly got more picky about a still lingering /etc/systemd/system/libvirtd.service alias to libvirt-bin might be another problem. I decided that I just check and if found remove various files which may still be present when doing 1.3.4 to 1.3.4 upgrades (or fresh install but then its unlikely to find anything)
<hallyn> smb: my ego thanks you :)
<smb> hallyn, :D
<hallyn> makes sense too
<hallyn> \o
<nacc> rbasak: smoser: pushed updates, thanks to you both!
<nacc> caribou: corosync imported, and the helper script dtrt, i think, as far as building you a reconstruct/<version> commit
<nacc> rbasak: so the bash script *could* tag the commit too, would that be useful? as I can get the version out of dpkg-parsechangelog given the commit, apply the renaming rules to it, etc.
<rbasak> nacc: yeah, that'd probably be useful. Maybe tag it reconstruct/<version> unless that tag already exists, in which case warn?
<nacc> rbasak: yep, will work on that now
<nacc> rbasak: i probably could dig and find it, but i didn't see a good way of doing cherry-pick without checking out first
<rbasak> nacc: you need a working tree I think. The only way to not clobber the user's tree would be to do it like git-dsc-commit and use a temporary directory for the tree I think.
<nacc> rbasak: yeah, i was hoping to avoid that route
<nacc> rbasak: i think it's "ok" as-is? if someone hates it, we can modify it
<nacc> rbasak: and git-tag already does that detection and will emit an appropriate warning, i think
<rbasak> nacc: yeah I think it's fine as-is and we can change it later if it's an issue. Generally the user will want to check it out anyway I think, or at least have a clean tree before doing so.
<nacc> rbasak: yep
<nacc> rbasak: that's a good point, i should probably handle the error case on checkout
<rbasak> nacc: perhaps just insist on a clean tree first. I think git-dsc-commit does that.
<nacc> rbasak: yep
<nacc> rbasak: pushed
<nacc> caribou: --^ so the helper script for corosync should generate the reconstruct tag for you now
<nacc> rbasak: I really appreciate all the feedback so far! Thanks!
<elbrus> rbasak: would you recommend me to try for MOTU (or even ubuntu developer as I'd like to help with my own package dbconfig-common which is in main)
<elbrus> and would you endorse my application
<elbrus> ?
<pitti> infinity: I'm confused about https://launchpadlibrarian.net/262897168/buildlog_ubuntu-yakkety-amd64.autopkgtest_3.20.8_BUILDING.txt.gz -- don't buildd chroots have "deb-src" apt sources?
<pitti> (builds fine in my sid and yakkety schroots)
<pitti> I can reproduce it if I drop deb-src, but that seems strange for a buildd chroot
 * pitti will add a @skipUnless() if there are no deb-src, not much that I can do then
<cjwatson> pitti: The default setup for buildd chroots doesn't much matter, since Launchpad blats out its own preferred sources.list anyway
<cjwatson> (doesn't matter for builds, that is)
<cjwatson> pitti: So in this case it's the one that Launchpad blats out that matters, not what's in the chroot; and Launchpad doesn't write out deb-src lines, because buildds fetch the source straight from the librarian
<cjwatson> (except in the private PPA case which currently does a somewhat weird thing, but even that doesn't rely on deb-src)
#ubuntu-devel 2016-06-03
<nacc> rbasak: in retrospect, should it not be reconstruct/<version> as that, in our current workflow, indicates the deconstructed one :) where each version has been broken into its individual changes, one per commit
<rbasak> nacc: good point.
<nacc> rbasak: how are you still awake? :)
<nacc> rbasak: i do like reconstruct/ and deconstruct/ but that's just because it's funny to me
<rbasak> nacc: I can't think of anything better :)
<nacc> rbasak: when you drop a change from the logical sequence because it was added and removed, do you document that in the final changelog? Just mention its an add/remove and that's the reason to drop it?
<rbasak> nacc: no, I don't mention it at all. That it was added and removed is still in the changelog against the uploads where that happened. From the point of view of the merge, the logical delta didn't contain it (any more), so it is neither a remaining change nor one that is dropped as a result of the merge. It was dropped before, and changelogged at the point where that happened.
<rbasak> nacc: in a way, I don't "drop a change from the logical sequence" either. I squash the add and remove together and end up with nothing.
<nacc> rbasak: yep, that makes sense, just wanted to verify it :)
<nacc> rbasak: i guess if we really want to use our workflow via that tool, i could tag old/debian new/debian and old/ubuntu in the process, too
<nacc> since they are defined relative to the invocation basically
<rbasak> Yes, but those tags would collide with a subsequent merge. I'm not sure if that's OK or not, since now we expect people to follow the importer tree a little bit more.
<rbasak> OTOH it is trivial to delete or overwrite those of course.
<nacc> rbasak: ah true -- i guess what i can do is provide it as a paramter to the helper script (and if so, it can use -f)
<nacc> rbasak: or provide some user opportunity to say override the existing tag if found
<rbasak> I have no objection either way
<nacc> rbasak: ack, not a priority, wsa just realizing we have all the data (esp. old/debian which can be potentially hard to track down otehrwise)
<nacc> Logan: i just sent a message to the debian maintainers on if they want me to send the debdiff up or if we can just drop the delta (as in they'll never take it) -- if i don't hear back, worst case i'll merge it for now and we'll hopefully be able to sync again during 16.10 sometime
<Logan> nacc: thanks so much!
<Logan> there are a lot of those bootstrapping deltas for PHP packages, not sure how Debian will address them
<nacc> Logan: yeah, my intention (the best of them) was to get them all pushed up by now
<nacc> Logan: clearly not achieved
<nacc> and well, they also ended up not being 100% necessary as the php5/php7 binary packages became coinstallable
<nacc> like the day i finished bootstrapping all the deps :)
<pitti> cjwatson: thanks, so this is intended; I skipped the test in 3.20.9 now (without deb-src)
<pitti> Good morning
<pitti> xnox, infinity: meh -- aupkg02 (10.100.0.13) is AWOL *again* -- what on earth is wrong with that box :/
<tjaalton> hum, there's a race with bind mounts and zfs.. zpool can't be mounted if the directory is not empty, and bind mounts populate the directory before zpool gets mounted
<rlaager> tjaalton: What are you bind mounting?
<tjaalton> rlaager: a directory behind the zpool to somewhere else
<cpaelzer> before I open up a bug (none found on LP), I still wanted to ask first if anybody else has seen "tar --exclude" being broken on Yakkety (and Stretch as it is the same)?
<rlaager> tjaalton: I'm not quite following the setup.
 * cpaelzer is checking debian bugs atm ...
<tjaalton> so the zpool is mounted to /srv, then I'd bind-mount /srv/foo elsewhere, but when the machine boots up the bind mount is created (and /srv/foo in the process) so the zpool doesn't get mounted because /srv isn't empty
<rlaager> tjaalton: Would symlinking /srv/foo meet your needs, instead of a bind mount?
<sarnold> how did you define the bindmount?
<tjaalton> /srv/builds     /n/builds       none    bind    0       0
<tjaalton> rlaager: it's for nfs
<tjaalton> so not really
<tjaalton> easier to just drop the bind mounts, it's not critical for me
<tjaalton> just wondering if this is filed or should be
<tjaalton> not a zfs bug..
<rlaager> In that case, I'd probably add a systemd override (or whatever those .conf files are called) for zfs-mount.service that sets a Before= for the auto-generated unit for that bind mount. (I'm new to this systemd stuff, so that's more a suggestion than a known-working fix.)
<tjaalton> well it has Before=local-fs.target
<tjaalton> which probably should cover this
<rlaager> Wouldn't "srv-build.mount then zfs-mount.service then local-fs.target" be an order in which zfs-mount.service is still Before local-fs.target, but you'd experience this problem?
<tjaalton> it would
<tjaalton> because it should be later than zfs-mount
<sarnold> systemd-analyze dot  may be useful
<rlaager> I'd try adding a Before=srv-build.mount (assuming that's the name of the autogenerated unit) and see if that resolves the race. I don't think there's a way to fix this generically (and completely) short of implementing a ZFS mount generator or something.
<sarnold> it seems like a difficult problem
<sarnold> I could just as easily imagine wanting the filesystem set up by /etc/fstab before doing any of the zfs things..
<tjaalton> jeebus, what a spaghetti it is (systemd.svg)..
<pitti> PSA: I need to take down the http://autopkgtest.ubuntu.com/ web UI for a while for maintenance (disks running out of space)
<pitti> this won't affect proposed-migration, just the web presentation
<ginggs> are we experiencing an unintentional debian import freeze?
<pitti> hm, I thought the same yesterday; I manually synced autopkgtest, but I thought I was just being impatient
<pitti> then again the imports themselves seem to be rather slow, so maybe it's just that
<Unit193> 'limnoria' hasn't made it over at all.
<Laney>   File "/home/ubuntu-archive/ubuntu-archive-tools/auto-sync", line 500
<Laney>     src.startswith("haskell-"):
 * Laney fixs, runs manually
<Laney> meh it's hitting errors downloading from launchpad
<mapreri> pitti: http://autopkgtest.ubuntu.com/ => 403?
<pitti> 10:47:18    pitti | PSA: I need to take down the http://autopkgtest.ubuntu.com/ web UI for a while for maintenance (disks running out of space)
<pitti> 10:47:29    pitti | this won't affect proposed-migration, just the web presentation
<pitti> mapreri: still ongoing, moving the gazillion files around is slooooow
<mapreri> pitti: ah, I see.  too much backlog i didn't read it, sorry.
<mapreri> pitti: do you think you can make src:biniou migrate by ignore botch tests?  (botch is just broken atm)
<LocutusOfBorg> BTW I see too many entangled transitions: poppler gdal gl2ps vtk6, and I fail to understand why all of them aren't migrating
 * LocutusOfBorg is really bad at parsing update_output.txt
<cjwatson> Laney: ah, sorry, my bad
<cjwatson> (for the blatant syntax error)
<Laney> cjwatson: No worries (but see #launchpad for me not being able to actually run it to completion)
<ginggs> LocutusOfBorg: i think suitesparse is entangled with most of them, and it now depends on metis.  I file an MIR LP: #1588407
<ubottu> Launchpad bug 1588407 in metis (Ubuntu) "[MIR] metis" [Undecided,New] https://launchpad.net/bugs/1588407
<LocutusOfBorg> oh, wrt suitesparse, did you see glpk and octave shown as red?
<LocutusOfBorg> I didn't investigate yet
<LocutusOfBorg> they seem false positive
<ginggs> LocutusOfBorg: yes, I saw that, I think false positive too. (auto-suitesparse)
<LocutusOfBorg> yes, but still unsure about where the ben file failed ;)
<Laney> LocutusOfBorg: you can use my awesome (not awesome [but does the job]) script to help untangle transitions like this https://paste.debian.net/713720/ and https://paste.debian.net/713723/
<LocutusOfBorg> thanks Laney !
<LocutusOfBorg> question about the script output you pasted above
<LocutusOfBorg> laney@raleigh> apt-get -oDir=/home/laney/.cache/brapt/aptroot -oDir::State::status=/home/laney/.cache/brapt/aptroot/status --dry-run install dynare liboctave3 libgl2ps0                            ~
<LocutusOfBorg> obviously wrong, and indeed it can't work
<Laney> that's not a script
<LocutusOfBorg> apt-get install dynare liboctave3v5 libgl2ps1 <-- this works instead
<Laney> that's a sample of me using it
<Laney> the script is the first one...
<LocutusOfBorg> I mean, I guess you ran it now, and I'm not sure why it tries to install the libraries from -release instead of -proposed
<Laney> that is telling you that octave needs to be rebuilt and become a candidate for migration
<Laney> because liboctave3 depends on a library which is going away
<rbasak> slangasek: any news on reviewing https://github.com/ltangvald/mysql-5.7/commit/fa6ea034692
<rbasak> 9584373aee3b373cba0751fb81830 for me please?
<LocutusOfBorg> liboctave3 is called liboctave3v5 on proposed
<LocutusOfBorg> so, it is going away too
<Laney> ...
<rbasak> elbrus: I think you should apply for dbconfig-common as you're maintaining it in Debian anyway. I don't know if there's any special requirement for a package in main. I'm not aware of one.
<rbasak> elbrus: for MOTU I think we'd expect to see a need or a recent history of sponsored uploads to that set of packages.
<rbasak> I guess that applies in general, but you de-facto upload to dbconfig-common regularly.
<Mirv> pitti: I notice you overrode qt4-x11 autopkgtest failures, did you consider qtbase-opensource-src too? the remaining failures seem related to the new KDE release and its dependency problems or other problems. qt4-x11 can't migrate to release pocket without doing it together with qtchooser and qtbase-opensource-src, due to Debian changes.
<pitti> Mirv: I didn't wade through the qtbase-opensource-src regressions yet; if you checked them, fine for me
<pitti> this would untangle at least some of the stuck stuff indeed
<pitti> Mirv: hinted
<akkonrad> hello. I have some old C knowledge and would like to write simpe time tracking app that appears in the top bar tray. where I should start to with it? Is quickly good for that? I would like to have something like hammster, but a littlbe bit different
<ikonia> akkonrad: #ubuntu-app-devel
<Mirv> pitti: thanks, yes I went through all them
<ikonia> akkonrad: probably the best place to start a personal app discussion for ubuntu
<pitti> mapreri: need to wait until debci is back; ATM I can't decide if it got broken because of biniou, or dose3, or something else
<akkonrad> tx ikonia !
<elbrus> rbasak: such as the cacti-spine updates ...
<ChrisTownsend> mterry: Hey!  I replied to your comments in https://bugs.launchpad.net/ubuntu/+source/libertine/+bug/1588050.
<ubottu> Launchpad bug 1588050 in libertine (Ubuntu) "[MIR] libertine" [Undecided,Incomplete]
<mterry> ChrisTownsend, oh yeah, sorry got distracted
 * mterry replies
<ChrisTownsend> mterry: Sure, no worries.
<rbasak> elbrus: yes but that's a reason to have PPU for cacti-spine.
<smoser> can i get an archive admin or sru team member to NAC the curtin uploads that are in xenial and trusty and wily ?
<pitti> smoser: just in the unapproved queue, or are they already accepted?
<pitti> no curtin in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1 at least
<rbasak> stgraber: around? Could you help with https://lists.ubuntu.com/archives/devel-permissions/2016-May/000930.html please? I did some research. It looks like these packages are only seeded in edubuntu/dvd, but it's excluded in packageset-report because "This would cause ubuntu-netbook to be sucked into Edubuntu, which has complicated effects."
<smoser> pitti, xenail and trusty in -proposed wily in unapproved
<rbasak> stgraber: I presume there are no reasons to not put ltsp etc into the edubuntu packageset because that's where it would be by the automatic generation rules anyway if it weren't for that disablement?
<rbasak> stgraber: and if so, then should I add an exception, or can we add edubuntu/dvd to the list now that ubuntu-netboot isn't (I presume) relevant any more?
<pitti> smoser: wily rejected
<rbasak> stgraber: (but if I add edubuntu/dvd to the list, I see many other changes too)
<smoser> and i can re-upload for xenial and trusty then, right ?
<pitti> smoser: yes; still at removing them, but you can reupload (needs a higher version number, though)
<smoser> pitti, yeah, i'll just re-upload with new version and use -v to denchanges ?
<smoser> genchanges.
<pitti> *nod*
<pitti> smoser: removed
<pitti> although that wouldn't really have been necessary, if you have a new uplaod that'll trump the previous version anyway
<smoser> pitti, thanks!
<stgraber> rbasak: can you paste the list of changes when whitelisting edubuntu/dvd?
<rbasak> stgraber: http://paste.ubuntu.com/16948158/
<rbasak> stgraber: I'm not sure how to present that better. It'd be nice if packageset-push could work from a local source but I don't see an option for that.
<stgraber> rbasak: are all of those kde additions to the edubuntu set or to something else?
<stgraber> rbasak: not too sure what's going on with all those kubuntu bits in there... looks like the script thinks a bunch of them are somehow part of ubuntu-server too which is clearly wrong (that or I'm not reading that diff properly)
<ogra_> are you sure ... who knows, probably -server is nowadays KDE based without all of us knowing ;)
<jfi> Hi, is there some problem with the uploading of package to ppa currently? dput command is working, but I don't get the mail (I double checked by sign key)
<cjwatson> jfi: Can you provide the dput command so I can check logs?
<jfi> cjwatson, dput  ppa:jfi/ppa ./psensor_1.1.4-1ppaxenial2_source.changes
<cjwatson> jfi: Logs say your key on the keyserver has expired
<jfi> cjwatson, Oo
<jfi> cjwatson, weird and a very bad idea, if I reached the expiration date of my key
<jfi> cjwatson, thanks for the information
<cjwatson> jfi: Yeah, I checked the keyserver and it has an expiration date of about 7 months ago
<rbasak> stgraber: will look but otp for an hour or so.
<jfi> cjwatson, according to pgp it is set as 'never' expires, should I reupload the key or I am wrong and the key has really expired?
<cjwatson> jfi: try reuploading it to the keyserver then
<cjwatson> I forget what it does with keys that it thinks have already expired
<cjwatson> you presumably removed the expiration date at some point but didn't send that to the keyserver
<jfi> cjwatson, there is really something weird
<jfi> cjwatson, I have desactivited my key
<jfi> cjwatson, then redo an import
<jfi> cjwatson, and it fails with the key XXXX cannot be validated because it has expired.
<jfi> cjwatson, but:
<jfi> pub  2048R/XXXXX  created: 2010-11-14  expires: never       usage: SCA
<jfi>                      trust: ultimate      validity: ultimate
<jfi> (output of gpg --edit-key jeanfi@gmail.com)
<nacc> rbasak: would it make sense to create a public wiki page under https://wiki.ubuntu.com/UbuntuDevelopment/Merging for our process & tooling?
<teward> nacc: it would be better served in the packaging guide, which still references I think the bzr method that is outdated
<teward> my two cents
<nacc> rbasak: i'm also going to add a couple helper scripts, presuming i can script them: usd-import-commit-merge <commitish> (which will do the parenting) and usd-import-tag-merge (which will take a -f flag to force the tagging). Ok with that? I'd like to document them in the public page for the git-workflow.
<smoser> pitti, if you're still around and wanted to let my xenial , wily, trusty uploads for curtin into -proposed i'd appreciate it.
<nacc> teward: link? this isn't yet official
<teward> nacc: sorry, IRCing from my phone
<teward> don't have eone
<nacc> teward: it's ok, i'll find it
<nacc> http://packaging.ubuntu.com/html/ ?
<teward> nacc: yeah, specifically http://packaging.ubuntu.com/html/udd-merging.html
<teward> but starting in the wiki is a better spot
<teward> let the doc team analyze and decide to update the packaging guide
<nacc> teward: yeah, udd was more 'official' than this is ... although i'm being told it's going to the direction
<nacc> *that direction :)
<teward> nacc: :P
<nacc> sort of accidentally :)
<teward> nacc: problem is that udd guide doesn't work for Xenial+
<nacc> teward: but i'll use that page as a reference too, thanks!
<nacc> teward: ack
<teward> nacc: case in point the nginx merges, though not even the git workflow worked for that one (nasty nasty merges!)
<teward> s/nginx merges/pending nginx merge/
<nacc> teward: since i lack the knowledge already, what was nasty about the merge that made the git workflow not work?
<teward> nacc: nfc, all I know is that the git workflow skipped over the addition of the dynamic module packages by Debian
<teward> but that was every merge workflow I've used in the past
<teward> solution: redo the delta, by hand, using Debian as a base :P
<nacc> teward: hrm, i'd need to see the git tree to figure that out, i think
<nacc> teward: i can do that locally :)
<nacc> as, if there is a case where it simply doesn't work, i'd like to use it as an example of how to do the merge 'manually' still
<teward> nacc: edge case most likely, but i think it works in most cases
<rbasak> nacc: public wiki page> sure!
<rbasak> nacc: usd-import-commit-merge makes sense. I'm not sure I follow what usd-import-tag-merge does.
<teward> urgh i need lunch >.<
<teward> (back later)
<rbasak> nacc: thank you for the writeup to the ubuntu-server ML BTW. Perhaps it's time to take it wider and send also to ubuntu-devel?
<rbasak> nacc: UDD has a mailing list too, so we could move all discussion there if we wish.
<nacc> rbasak: it would do the prep work of old/debian new/debian old/ubuntu tagging
<nacc> rbasak: possibly needs a different name :)
<nacc> figured they'd start out as 3 and then eventually get combined into one script with parameters
<rbasak> nacc: ah, I see. Yeah, sure.
<rbasak> nacc: if they're user tools we might want shorter names, too.
<nacc> rbasak: yeah, i was hoping to write up some stuff on the wiki first, so i can use that as a reference, and send a summary to ubuntu-devel and i'm happy to include the udd list
<nacc> rbasak: yeah :)
<nacc> rbasak: i think it'd become `usd-merge (tag|reconstruct|merge)`
<nacc> rbasak: to parallel `usd-import`
<rbasak> nacc: sounds good
<teward> I have a question about package hooks and apport - would it be sane to try and get information during a package installation failure of a webserver package such as whether default ports are currently bound to, etc. by executing other commands as part of the hook?
<teward> as well, would it be sane to gather information about the system such as CPU core information (number of processor cores seen by the system, etc) and such?  Asking because there may be a race condition with regards to systemd and things
<sarnold> netstat or ss to find out if the port is free makes sense; I can't imagine processor information being useful but it's collected for other hooks
<teward> sarnold: was asking for processor because of a confirmed systemd/initscript race condition when starting nginx on 1CPU systems
<teward> sarnold: i'd love to be able to grab netstat data, but also nginx error.log if it exists
<teward> but, i need a little guidance to what's sane or not
<teward> (if i had my way, i'd grab all error logs from everywhere heh)
<teward> (for nginx)
<JanC> heh, you get a race condition on 1 CPU but not on more CPUs?
<teward> JanC: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1581864
<ubottu> Launchpad bug 1581864 in nginx (Ubuntu) "nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument" [Low,Confirmed]
<JanC> usually it's the other way around  ;)
<teward> non-critical race condition
<teward> 'cause it fixes itself
<teward> supposed race condition, but it still chokes?
<teward> s/fixes itself/doesn't break startup/
<teward> with that not on my radar, though, knowing current listening ports is a plus, but getting error.log for nginx would be beneficial too in many cases
<teward> problem being, that's not always 'clean' to include
<teward> (sometimes, sensitive request data gets dumped there)
<sarnold> yeah sanitizing that feels likely to overlook a lot..
<JanC> I doubt if it happens on 1-CPU systems it can't happen on multi-CPU systems, although for that user it might only show with 1
<teward> sarnold: a secondary problem is anything that doesn't use pure english characters and has multibyte characters is choking up the main apport hooks
<teward> sarnold: but that's something I can't fix :/
<teward> oops forgot to plugin my laptop back in a few
<sarnold> teward: heh yeah more than a few apport hooks were useless when xenial was released..
<teward> sarnold: because of the same reason I just stated?
<sarnold> yes
<sarnold> teward: I filed at least 1582992 and 1582950 -- I think I filed a third but it's since been fixed
<teward> sarnold: these need to be extended to 'apport'
<teward> not just libvirt or similar
<teward> because i'm seeing this in global hooks too
<teward> not just the local hooks
<teward> what's the third one?
<sarnold> I may have been thinking about 1580412
<nacc> teward: reproduced!
<nacc> teward: in a lxc xenial container
<teward> nacc: the no-output thing?
<nacc> teward: fully fresh `lxc launch ubuntu:xenial`
<nacc> teward: the bugs you just linked
<nacc> nginx failed to install :)
<teward> nacc: so its only in lxc?
<teward> nacc: mind doing further debugging?
<teward> because I don't have an lxc-capable system just here
<nacc> teward: well, i use lxc for my reproductions cuz it's easy
<nacc> i guess technically lxd :)
<teward> nacc: close enough, can you stab it to see why it's failing?
<nacc> teward: yeah what do you need?
<teward> nacc: whatever the hell you can provide
<teward> specifically:
<teward> reproduction steps
<nacc> let me paste what i just got first, so you can eyeball
<nacc> http://paste.ubuntu.com/16965632/
<nacc> reproduction: lxc launch ubuntu:xenial; lxc exec <container> bash
<nacc> apt-get update; apt-get install apache2; apt-get install nginx; blammo
<teward> nacc: wait
<nacc> so in that case, i know nginx wasn't already running, as it wasn't installed...
<teward> nacc: that's a conflict
<teward> nacc: apache and nginx both use the same port
<teward> 80
<teward> for default
<nacc> teward: then it shouldn't have allowed me to install?
<teward> nacc: that's why it fails, we didn't get logic ACK'd to test
<nacc> or do you mean it's a configuration conflict?
<teward> nacc: default config conflict
<teward> let me show you the master bug on that
<nacc> teward: ack, so ... 1588972 is simply that, no?
<nacc> as they installed apache2 -> php -> nginx
<nacc> afaict
<teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1512344
<ubottu> Launchpad bug 1512344 in nginx (Ubuntu) "[Master Bug] Package nginx-* failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (due to "Address in Use" issue)" [Undecided,Invalid]
<teward> nacc: that's the logical step, yes, but I want confirmation of that being the case
<teward> nacc: sarnold: any way to determine if it's running in an lxc/lxd container?
<teward> as in, within apport hooks
<nacc> teward: well, i mean in both cases, they installed apache2 then nginx
<teward> nacc: ok, then that's the issue
<nacc> are you sure they aren't both just this known master case?
<teward> want to help me triage?  :P
<teward> nacc: well
<nacc> teward: ack, i'll respond
<teward> nacc: this known master case is autodetected in apport dupe detection
<teward> AND all such cases show in systemctl -l
<teward> nacc: AND all such cases wouldn't start nginx
<teward> it'd just [emerg] crit error
<teward> and die
<nacc> hrm
<teward> nacc: so unless you can inquire on both cases asking if it's in a container and if apache2 was installed first and is running on port 80
<teward> and they respond as such
<teward> then i can't confirm it's a dupe of the master case
<nacc> yep, i'll ask
<teward> (though, after getting that added to the list of known duplicate signatures, the number of new "bugs" dropped significantly)
<teward> nacc: thank you kindly
 * teward now needs to scrounge together $650 to get his parents' internet upgraded to a sane setup/environment
<nacc> teward: lxc maybe totally false positive, i just use it as my fast reproduction env, i doubt it is the underlying cause
<teward> nacc: hrm
<nacc> lxc/lxd that is
<teward> right
<nacc> my gut feeling is these are dupes, just based upon the output and such
<teward> nacc: i'm not sure how my VMs aren't reproducing this though, maybe containerization is important?
<teward> or does something odd?
<nacc> teward: right, but in your VMs, did you install apache2 first?
<teward> nacc: no, but when I install apache2 first, then install nginx, it crits as shown in the bug
<teward> not the latest bug, the known one
<teward> and apport filing will trigger dupe detection
<nacc> oh i see
<nacc> right, but mine didn't, so what's different about being in a container ... hrm
<teward> nacc: my question exactly
<nacc> mine failed the same as these two newer bugs
<teward> nacc: lxc/lxd usable inside a VM?
<nacc> teward: to be sure, you started off with a fresh 16.04 VM?
<teward> (containerization/virtualization ception!)
<nacc> teward: it should be, yeah
<teward> nacc: every time
<sarnold> hah, /bin/running-in-container is from upstart. thus not on xenial.
<teward> nacc: scratch-install base Ubuntu Server 16.04 x64
<nacc> teward: should just be an `apt-get install lxd` and you should be able to be up and running pretty easily
<teward> nacc: ack, i'll hunt that
<nacc> teward: i'm presuming, i've not tried it in a VM :)
<teward> maybe stab Docker in a 14.04
<nacc> nested bridging, i guess :)
<teward> first, i have to fix DNS on my network
<sarnold> funny, i've only used lxd from within vms :)
<teward> sarnold: heh
<nacc> sarnold: :)
<nacc> we're just all dogfooding little bits, it's good :)
<teward> :p
<teward> sarnold: security/privacy wise, wouldn't getting netstat output be a cause for concern in terms of sanitizing IP addresses?
<teward> in cases of public-facing machines, IPs may be 'sensitive'
<teward> (whereas internal private IPs wouldn't be)
<sarnold> teward: I think there's loads of IPs in the logs..
<nacc> teward: i guess, worst-case, we know that in my specific lxc reproduction, the crit doesn't catch
<teward> nacc: i think i'll stab it myself
<teward> but if containerization doesn't catch the apport data right
<teward> then that's a HUGE issue
<teward> unless it's a known documented issue with lxc/d
<teward> nacc: thanks for the assist though on hunting this
<teward> it's been something plaguing me for a few weeks
<teward> with "WTH is with these bugs?!?!?"
<nacc> teward: can you explain what catches the port-in-use? is it strictly apport's bug dupe detection?
<teward> nacc: I have to dig up the signature
<nacc> teward: because in my paste, i see: "No apport report written because the error message indicates its a followup error from a previous failure."
<nacc> so if it relies on apport, then maybe that's why it didn't trigger?
<teward> ubuntu bugpatterns
<teward> nacc: possibly, but if the previous failure wasn't caught either, then you still have the issue
<teward> nacc: http://bazaar.launchpad.net/~teward/apport/ubuntu-bugpatterns-nginx/revision/552
<ubottu> Error: launchpad bug 552 not found
<teward> silence you
<nacc> teward: http://paste.ubuntu.com/16966119/
<teward> nacc: that's the merged revision to the bugpatterns for nginx
<nacc> not crit, but emerg?
<teward> nacc: synonymous
<teward> [emerg] is nginx's log level for critical failures
<nacc> k, that's what's in my lxc's journalctl
<teward> nacc: OK, we pull the journalctl data too
<teward> I should probably add a separate bugpattern for that
<teward> nacc: but that doesn't apply in the cases shown in the bugs either
<teward> because the other file on journalctl data would show it
<teward> and it doesn't show
<nacc> yeah good point (and the same output is in my systemctl)
<teward> "Journalctl_Nginx.txt.txt"  <-- also captured by apport hook
<teward> as the failures in dpkg have recommended, i pull in both
<teward> because that way we get both sides
<nacc> yeah
<teward> so to do for me: extend the bugpatterns slightly to add in the second nginx pattern for journalctl detectino...
<teward> but that doesn't explain why that data's not showing up, nor why the program is actually listed as 'running'
<teward> nacc: only thing I can think of is systemctl fubar'd in the process and couldn't kill an older process
<teward> which *could* be the case if it's an upgrade bug
<nacc> teward: ack, in my case, it's not listed as running at all, so it's different
<teward> yep
<nacc> so i guess there are two issues to track down :)
<teward> :/
<nacc> i think for the two bugs you linked earlier, it's totally reasonable for them to be in incomplete while the submitter gives more complete information,a nd you've don your due diligence
<nacc> and for this bug, if you are able to setup lxd, it should be easy to figure out why the dupe isn't getting detected (it could just be some ordering condition)
<teward> nacc: do me a favor and file a crash bug on it?
<teward> from inside the container
<teward> you can add in the details i asked
<teward> see if it catches
<teward> if apport isn't broken, it should catch
<nacc> teward: although, if nginx is already running, and they installed apache2, wouldn't it have failed to install apache2?
<nacc> very confusing state
<teward> nacc: i haven't poked the apache2 configs
<nacc> teward: sure, .... how do i do that? :)
<teward> but theoretically? yes
<nacc> file a crash bug that is :)
<teward> sarnold: what's the command to file an apport bug on a crash report?
<nacc> apport-bug ... somethign something?
<teward> ubuntu-bug /var/crash/blah.crash?
<teward> where blah is the packagefailure
<nacc> ack, found it
<nacc> ugh
<nacc> teward: one sec, something worrisome
<teward> "apport has died, killing init..."  [Kernel Panic]
<teward> loljk
<nacc> no, but i had restarted the container and nginx came up fine ... i wonder if that's why systemctl says it's running? that is, it failed to install, mabye they rebooted and then reported the bug? let me start a fresh container :)
<teward> nacc: thanks, if you can prove that's the case, all hail you :P
<teward> nacc: that brings up a second race condition:
<teward> which binds first apache or nginx at boot
<nacc> well, and what's weird/unfortunate is that apt is still unhappy even after reboot
<nacc> as the packages aren 't done installing
<nacc> but nginx happily starts :)
<teward> brb
<nacc> teward: ok, apport-bug did mark mine as already known
<nacc> and sent me to the master bug
<nacc> *but* only when i manually ran apport-bug
<nacc> not as part of the apt-get install itself
<nacc> so maybe the apport-avoidance detection i pasted earlier is wrong for this case, i'm not sure where it comes from
<nacc> rbasak: much much more to add, but I've started at: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow
<nacc> rbasak: on monday i'll start pulling over the details of the workflow from the serverteam page
<nacc> Logan: it sounds like debian is ok with me pushing directly to the git repository. I'm not sure when that will result in a new version (or if it will anytime soon) -- so would you prefer i just merge what we have now in the meanwhile?
<FredUbuntu> Hello
<FredUbuntu> It seems that thre's is the same bug when opening MUSESCORE on Ubuntu studio 16.04
<FredUbuntu> https://musescore.org/en/node/86971
<FredUbuntu> i saw there that this bug has been foxed in version 2.03, see answer #54 here: https://musescore.org/en/node/86971
<FredUbuntu> but i can't manage to install version 2.03
#ubuntu-devel 2016-06-04
<Logan> nacc: that sounds good to me
<Logan> it'll fix a lot of packages that are stuck in proposed or failing to build
<Logan> FredUbuntu: it looks like it's a simple fix that we may be able to bring down to 16.04
<Logan> would you be willing to test an updated package with the patch if I build one for you?
<FredUbuntu> yes sure
<Logan> okay, please follow Bug 1574432 and await a .deb file :)
<ubottu> bug 1574432 in musescore (Ubuntu) "window load crash on starup" [Undecided,New] https://launchpad.net/bugs/1574432
<Logan> if it works, I can work on getting it pushed into the repository
<FredUbuntu> ok, thank you !
<FredUbuntu> where will i dowload the .deb file ?
<Logan> I'll attach it to that bug once I've built it
<FredUbuntu> ok, i understand, thx
<nacc> Logan: ack, will do
<Logan> can someone kill this? https://launchpad.net/ubuntu/+source/libxml2/2.9.3+dfsg1-1.1/+build/9855440
<Logan> PowerPC builds are being held up due to a lack of builders, and this stuck build isn't helping :P
<Logan> this appears to be quite stuck as well: https://launchpad.net/ubuntu/+source/haskell-dimensional/1.0.1.2-1/+build/9857611
<Logan> oh wait I can kill that one :3
<sarnold> where's the "kill" button?
<Logan> you should be able to cancel the first one if you're a core dev
<sarnold> i'm not a core-dev; I've got an interesting set of privileges which made me wonder if I could kill it if only I knew how :) but I don't see anything obvious
<Logan> I'm pretty sure the rule is that you can only cancel the build of a given package if you had the privileges to upload it in the first place
<sarnold> that makes sense. since those are yakkety and I've got no privileges in -devel I can't kill them..
<hallyn> <sheepish> ... cancelled
 * hallyn wonders who he just piseed off
<FredUbuntu> Hello
<FredUbuntu> I would like to try a bugg fix on musescore
<FredUbuntu> https://launchpad.net/~logan/+archive/ubuntu/arb/+sourcepub/6486195/+listing-archive-extra
<FredUbuntu> but i don't know wich file to download
<FredUbuntu> i'm on Ubuntu Studio 64bits
<FredUbuntu> when i go there : https://launchpad.net/~logan/+archive/ubuntu/arb/+build/9860098
<FredUbuntu> i see 3files at the end of the page
<FredUbuntu> Hello, I would like to try a bugg fix on musescore https://launchpad.net/~logan/+archive/ubuntu/arb/+sourcepub/6486195/+listing-archive-extra  but i don't know wich file to download ( i'm on Ubuntu Studio 64bits). when i go there : https://launchpad.net/~logan/+archive/ubuntu/arb/+build/9860098 , i see 3files at the end of the page
<cjwatson> FredUbuntu: use dget (from the devscripts package) on the .dsc file on https://launchpad.net/~logan/+archive/ubuntu/arb/+sourcepub/6486195/+listing-archive-extra
<cjwatson> .dsc is the top-level bit of the source package; it refers to some other files, and dget knows how to follow those links for you
<cjwatson> give dget the URL to the .dsc file though rather than downloading the .dsc separately first
<cjwatson> so in this case "dget https://launchpad.net/~logan/+archive/ubuntu/arb/+files/musescore_2.0.2+dfsg-2ubuntu1~test1.dsc"
<mapreri> ccan someone check why src:limnoria is not getting auto-synced from debian?
<b4r> sure, what's the procedure?
<mapreri> erm?
<b4r> how would someone verify src:limnoria is getting auto-synced?
<jbicha> mapreri: that's bug 1587667
<ubottu> bug 1587667 in dpkg (Ubuntu Xenial) "Import from Debian fails for source packages with included tarball .asc" [Undecided,New] https://launchpad.net/bugs/1587667
<mapreri> oh, right, I wanted to try the new .asc thingy with it, i forgot about that!
<mapreri> umh, the dpkg backports are still to do.  well, guess there is still time before yakkety.
<mapreri> jbicha: ta!
<michael_> hi
<michael_> someone here?
<teward> michael_: better to just ask your question
<teward> and have patience
<michael_> if yes, how to enable widi (wifi-display/miracast) on ubuntu? i get nuts with that connman and https://github.com/01org/wds
<teward> I think that's a better question for #ubuntu rather than here?
<teward> support questions like that are better suited for #ubuntu (or #lubuntu where you originated from)
<michael_> here is devel. miracast/widi is not supported im ubuntu, ubuntu is using an old wpa_supplicant and connman
<michael_> i am on the wrong channel?
<michael_> teward, where can i find help about ubuntu, miracast, widi, sink-server and p2p? i thought this is the right channel?
<michael_> teward, it is not worth to ask in #ubuntu, just beginners questions. the question is connman 1.32 and latest wpa_supplicant in Xenial/Yakkety 1.32 is only supported in Yakkety, why?
<mapreri> michael_: this channel is about developing ubuntu itself, so no, this is not the right channel.
<mapreri> that said i wouldn't know where it is better suited.
<michael_> mapreri, what are you developping? no implemantation of wds?
<michael_> if not, where can i find help about how to implementate wds on ubuntu?
<teward> This isn't a support channel for this.  #ubuntu, #lubuntu, etc. for support but NOT here; you could try posting on Ask Ubuntu or the Ubuntu Forums the question as well
<michael_> there is no help for that
<michael_> seems nobody made ever a sink-server for widi on ubuntu
<michael_> as i said wpa_supplicant and connman are too old for that
<teward> then you're out of luck, because we're still not the correct channel for this discussion.  You're welcome to compile those softwares from source instead of using the ones in Ubuntu, but that's an unsupported approach in general
<michael_> i compiled it, but still no luck to get "connmactl technologies" to get the p2p service on an ath9k available :(
<Unit193> mapreri: It wasn't on DDA, is *asc support interesting?
<michael_> i was reading p2p is avialable on ath9k but how?
<michael_> i am using latest wpa_supplicant
#ubuntu-devel 2016-06-05
<mapreri> Unit193: it'll be in the next DevNews, there is a paragraph named 'Source packages can include upstream signatures'
<mapreri> still only 4 out of 5 news, so it's not yet out.
<Unit193> Heh, alright.
<mapreri> https://wiki.debian.org/DeveloperNews#Source_packages_can_include_upstream_signatures
<teward> stupid question but is there a guide for packaging python packages anywhere?  Have to ask since pymssql is unusable in the repositories because of a freetdx incompatibility
<teward> and it looks like this has been in Debian for several years without being addressed (E:Unmaintained?)
<rlaager> teward: You may have already seen these, but if not: https://www.debian.org/doc/packaging-manuals/python-policy/ https://wiki.debian.org/Python/LibraryStyleGuide
<teward> rlaager: thanks.  Basically, going to try and do the Debain maintainer's job of packaging a newer version, but since hte issue affects Ubuntu too, well...
<teward> (unusable means you can't fetch data from the results of a query with pymssql)
<teward> may be in Universe, but it affects a lot of things
<teward> :/
<rlaager> I think I might use that package, actually. I guess I better finish killing off MS SQL in our environment before I upgrade the server with the Python code. :)
<teward> rlaager: I opened a dupe of the issue, whoopsies, but https://bugs.launchpad.net/ubuntu/+source/pymssql/+bug/918896 and https://bugs.launchpad.net/ubuntu/+source/pymssql/+bug/918896
<ubottu> Launchpad bug 918896 in pymssql (Ubuntu) "returns no data from SQL server" [High,Confirmed]
<teward> oops
<teward> and https://bugs.launchpad.net/ubuntu/+source/pymssql/+bug/1589295  <--
<ubottu> Launchpad bug 1589295 in pymssql (Ubuntu) "pymssql fetch functions return nothing, traces back to freetdx and 1.0.x incompatibility" [High,New]
<teward> rlaager: a nice Google search led to stackexchange, which led to 'Use the updated version" :P
<teward> hrm
<rlaager> teward: You can click 'Mark as duplicate' on your bug report to mark it as a duplicate of the other, earlier bug report.
<teward> rlaager: 'cept the older one doens't have the workaround
<teward> but yes i know how to bug triage
<teward> i do it frequently for nginx, of which I maintain
<teward> CBA to do it right now, because E:TooMuchWork
<teward> gotta get other things done, but took a 5 minute break between tasks :P
<teward> will do so "soon"  (tm)
<teward> hmm, I need an MSSQL server
<teward> for testing that package and a patch I think I found...
#ubuntu-devel 2017-05-29
<FourDollars> Hi, could you help to check the SRU for https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1100546?
<ubottu> Launchpad bug 1100546 in indicator-power (Ubuntu Xenial) "Power indicator favours 'not present' mouse over laptop battery level" [Medium,New]
<cpaelzer> nacc: no it is not an official dep3 field, but it helps a lot especially if the patch needs to be maintained
<cpaelzer> nacc: it is just a way to attribute it to the right author, while putting the burden to be contacted to keep it in shape to who wrote the patch for the package
<cpaelzer> nacc: spec-wise you'd do multiple Author lines, but then it turned out to often be misleading
<cpaelzer> nacc: allso it is close to bikeshedding :-) I'm happy to find patches which have headers at all - what we discuss here is minor optimization
<cpaelzer> nacc: but lets open up this topic next week
<cpaelzer> good morning btw
<sil2100> smoser: hey! I was looking at the cloud-init SRU just now and sadly I noticed most of the bugs don't have the required SRU information in their description...
<sil2100> smoser: could you fix that or poke people to add those?
<sil2100> smoser: there's a lot of bugs so I guess we need to make sure each of them can be easily validated and reviewed
<sil2100> cpaelzer: hey! Could you take a look at the two autopkgtest failures for the new postgresql-9.5
<sil2100> in yakkety?
<sil2100> cpaelzer: http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#postgresql-9.5
<sil2100> cpaelzer: I see that the armhf one for postgresql itself also happened for packages like openssl
<sil2100> cpaelzer: ah, I see your bug comments now
<cpaelzer> sil2100: hi, was busy in a call - now I'm with you
<sil2100> cpaelzer: it's all good, your comments had all I needed
<cpaelzer> sil2100: yeah I tried to outline the known issues in the comment
<cpaelzer> sil2100: to at least slightly believe we will one day have less o fthose transient issues I even opened two bugs :-)
<cpaelzer> yet I know that working on these is unlikely given usual priorities
<cpaelzer> I just don't like writing every quarter "known issue" :-)
<sil2100> hah, very good indeed! Yeah, I saw some of those failures being around since ages now, would be nice to get those fixed up one day
<cpaelzer> sil2100: Trusty will need to age more in proposed to be considered, thanks for accepting the others
<sil2100> cpaelzer: yeah, I know, since I almost accidentally accepted it
<sil2100> ;)
<sil2100> Ctrl+C'd my way out of it in the right moment though
<Alfro> Where can I see how the gnome-control-center changes the default audio source? I thought it was similar to using pactl, but I am getting different behaviour in a particular case.
<jtaylor> is firefox in ubuntu built in some form of debug mode?
<jtaylor> I get real bad performance and the assembly used is horrible
<jtaylor> no inlining of tiny functions un libyuv
<jtaylor> oh no mystery ... -Os is used
<jtaylor> seems to also affect debian bug 863672
<ubottu> Debian bug 863672 in firefox "performance critical libyuv built with Os" [Normal,Open] http://bugs.debian.org/863672
<ddstreet> cyphermox hey, sorry again...my change to vlan for bug 1573272 was not quite correct, I put details in the bug and attached v2 devdiffs, which apply on top of the current -proposed code...can you review and upload to artful if it looks correct?
<ubottu> bug 1573272 in vlan (Debian) "default gateway route not installed for bond interfaces through reboot" [Unknown,New] https://launchpad.net/bugs/1573272
<ddstreet> slashd uploaded the SRU releases, he can handle re-uploading the SRU releases again if you can upload to artful
<cyphermox> sure
<slashd> cyphermox, thanks
<ddstreet> thanks!
#ubuntu-devel 2017-05-30
<nacc> slangasek: infinity: I think I found another case of LP: #1685672, src:freedombox-setup. excuses shows it as passing on amd64 and not other arches, but attempting to retrigger says it's not published in artful. rmadison says it's in proposed, though.
<ubottu> Launchpad bug 1685672 in Launchpad itself "Copies with binaries between artful pockets fail if package was built in older release" [Undecided,New] https://launchpad.net/bugs/1685672
<infinity> nacc: Hrm?  Definitely not that bug.
<infinity> nacc: That just looks like a bug with the autopkgtest trigger stuff to me.
<infinity> nacc: Triggered from the CLI instead for you.
<nacc> infinity: oh ok, sorry
<infinity> nacc: The symptoms of that bug are the source in question "disappearing".
<nacc> infinity: it's odd, because the amd64 pass isn't in the history either -- the failures for other arches are all testbed (dep) failures
<nacc> infinity: oh ok, i confused it
<infinity> nacc: ie: Because proposed-migration decides the source is ready to migrate, copies to -release, then deletes from -proposed.  And the copy never gets there.
<nacc> infinity: right, i reread the bug now and was definitely wrong on that count
<infinity> nacc: FWIW, the installation failure is due to https://launchpad.net/ubuntu/+source/mod-gnutls/0.8.2-3
<infinity> freedombox-setup : Depends: libapache2-mod-gnutls (>= 0.7.4-1) but 0.7.3-0ubuntu1 is to be installed
<infinity> nacc: Entirely valid failure to block on.
<nacc> infinity: agreed, but why would it ever have passed on amd64?
<nacc> infinity: oh i see it (mod-gnutls) built on amd64 in zesty
<infinity> nacc: Right.
<infinity> nacc: Retried mod-gnutls everywhere else.  Last builds were before gnutls was merged, maybe it'll be happier with the current version.
<infinity> Fingers crossed, cause otherwise it's a fun game of "WTF DOES THIS WORK IN DEBIAN".
<nacc> infinity: thanks -- yeah, was hoping to avoid having to figure that out tmrw :)
<nacc> infinity: yeah, no good still (i think) -- it's a failure in apache somewhere, will debug it tmrw if i can
<schje> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: dupo
<schje> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Phar
<schje> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Hirp
<schje> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: ahon
<schje> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: ubot
<schje> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: fabo
<ubottu> Launchpad bug 1674838 in linux-hwe-edge (Ubuntu) "kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129" [Undecided,In progress]
<schje> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: sarn
<Mariel> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: vila kward imcleod ejat
<Mariel> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: lfaraone stub directhex
<Mariel> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: dannf jsing shuduo ilma
<Mariel> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: pdeee marlinc cpaelzer 
<jason4316> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Spads nelhage ale
<jason4316> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: tkamppeter nobuto
<Mariel> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: ddellav rsalveti anthon
<jason4316> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: FourDollars antho
<Roo_8999> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: nitesh bdrung_work 
<Roo_8999> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: bigon tedg lfaraone
<Roo_8999> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: pitti kees mthaddon
<Roo_8999> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: lionel smb kees inf
<Roo_8999> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: maswan p_teen_girl6
<Roo_8999> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: broder manjo niedba
<Roo_8999> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: mcasadevall maxb pe
<Roo_8999> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: mthaddon dobey bmw 
<Roo_8999> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Dmitrii-Sh rbalint 
<dobey> wtf is up with all thsese stupid spambots
<tsimonq2> ...
<tsimonq2> wtf?
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: sunweaver fli
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: jjohansen bdr
<ubottu> Launchpad bug 1674838 in linux-hwe-edge (Ubuntu) "kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129" [Undecided,In progress]
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: FJKong l
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: ratliff 
<Kyla_7855> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: directhex cimi zu
<Kyla_7855> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: lifeless yosafbri
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: elopio r
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: rharper 
<kmbynm> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: nelhage 
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: LocutusO
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Noskcaj 
<kmbynm> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: ikonia h
<giirl762> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: wolsen mako jsing im
<Mariele> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: nobuto ahasenack TheMu
<giirl762> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: TheMuso kirkland tai
<Mariele> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: elopio fabo persia dan
<Kyla_7855> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: zhangxin_ tedg RA
<Kyla_7855> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Mez alex-abreu ti
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: tai271828_ sl
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: beuno zul nie
<Allan4195> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: 
<Allan4195> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: 
<kmbynm> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Riddell 
<Kyla_7855> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: bjf jacekn karste
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Ampelbein iko
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: rbalint cpu1 
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: g2 karst
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: wolsen i
<Mariele> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Mez underyx manjo tedg
<giirl762> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: nobuto ogasawara hap
<Mariele> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Unit193 jgrimm mwhudso
<giirl762> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: ilmaisin mapreri smo
<UsaBoy187197> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/669
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Riddell ahase
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: debfx Orphis 
<Kyla_7855> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: marlinc tianon ah
<Kyla_7855> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: czchen scottASL48
<siqyrs> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: wgrant i
<UsaBoy187197> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/669
<siqyrs> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: ratliff 
<Allan4195> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: 
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: hiboma sbeatt
<sxdjhx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: niedbalski Adri2000 
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: luis30 alai g
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: musician
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: jugo und
<kmbynm> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: jtaylor 
<ubottu> Launchpad bug 1674838 in linux-hwe-edge (Ubuntu) "kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129" [Undecided,In progress]
<Mariele> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: sakrecoer lfaraone kno
<giirl762> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: cpaelzer ahasenack b
<giirl762> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Lutin hloeung boiko 
<Mariele> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Noskcaj sbeattie tkamp
<UsaBoy187197> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/669
<UsaBoy187197> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/669
<siqyrs> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: knome ci
<siqyrs> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: ltrager 
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: cpaelzer sire
<tsimonq2> bloody hell
<sxdjhx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: ahoneybun ScottK cim
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: pjdc niedbals
<Allan4195> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: 
<kmbynm> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: jvw mhal
<sxdjhx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: coreycb danjared Odd
<kmbynm> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: tedg ret
<sxdjhx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Riddell sforshee mar
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: lool vtapia s
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: tsimonq2 aisr
<sxdjhx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: Logan cpu1 rmk G hlo
<Kyla_7855> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: torkel jjohansen 
<Kyla_7855> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: bswartz freyes un
<UsaBoy187197> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/669
<siqyrs> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: andersk 
<UsaBoy187197> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/669
<siqyrs> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: mwhudson
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: led1 freyes p
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: alexlist wook
<Allan4195> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: 
<sxdjhx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: herb smoser tianon a
<kmbynm> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: hggdh ss
<sxdjhx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: marcoceppi karlthane
<Allan4195> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: 
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: karstens
<kmbynm> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: rharper 
<UsaBoy187197> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/669
<siqyrs> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: yofel lt
<UsaBoy187197> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/669
<siqyrs> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: ilmaisin
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: ubuntulog_ di
<sxdjhx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: infinity stokachu he
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: maxb Sarvatt 
<kmbynm> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: dupondje
<Allan4195> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: 
<sxdjhx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: bladernr` Long_yanG 
<Allan4195> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: 
<Kyla_7855> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: tkamppeter sakrec
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: wgrant t
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: czchen a
<Kyla_7855> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: pdeee scottASL48 
<kmbynm> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: gusnan t
<UsaBoy187197> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/669
<siqyrs> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: mako vta
<UsaBoy187197> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/669
<siqyrs> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: StevenK 
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: maxb mneptok 
<sxdjhx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: alexlist anthonyf ma
<deiphobus1600> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: hiboma flixr 
<Allan4195> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: 
<kmbynm> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: boiko ej
<Allan4195> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: 
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: apw life
<jiowzx> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: cpu1 yos
<kmbynm> bug ticket issued 03-21-2017 ===>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838...yea you heard that right fucking months ago!! supposed to be fixed june 05, 2017..basically it just randomly freezes your screen without notice like a mother fucker!!! who said windows was better than linux pffffff you should fucking enjoy your pc freezing without notice for months and like it motherfucker!! quicktalkeh676te.onion/6697: ajmitch 
<ubottu> Launchpad bug 1674838 in linux-hwe-edge (Ubuntu) "kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129" [Undecided,In progress]
 * tsimonq2 hugs ubottu 
<tsimonq2> and Unit193 <3
<Pharaoh_Atem> does this mean I won't get spammed anymore?
<tsimonq2> Pharaoh_Atem: I believe so, yeah. *hugs to ops*
<Pharaoh_Atem> I was getting random ass DMs too
<tsimonq2> So was I
<Unit193> Just for now, I stepped in due to the massive spam, I'm not an OP.
<Unit193> Laney, cjwatson, infinity: Ping.
 * tsimonq2 hugs Unit193 anyways
 * Pharaoh_Atem hugs Unit193
<Son_Goku> is it safe?
<tsimonq2> Son_Goku: Yes. :)
<Son_Goku> phew
<Son_Goku> I don't even *do* anything in Ubuntu
<Son_Goku> hell, my cloak says Fedora :)
 * tsimonq2 hugs Son_Goku for being here anyways :)
<Son_Goku> fwiw, I'm confused why a kernel bug is worth doxxing us for
<tsimonq2> I don't know either
<cyphermox> well, also, omg, a two-month-old kernel bug...
<Son_Goku> I mean, come on
<Son_Goku> I have bugs that have been open for literally years
<Son_Goku> two months is nothing
<Son_Goku> (in LP, for Ubuntu :) )
<tsimonq2> It looks like it would have been uploaded tomorrow anyways
<Unit193> Anywho, likely could move on now since he's hardly worth talking about.
<tsimonq2> Because the kernel people are probably on holiday because today is Memorial Day...
<tsimonq2> Unit193: Yep :)
<Son_Goku> Indeed
<luis30> Unit193, your not an op?
<Orphis> .done
-ChanServ:#ubuntu-devel- Unit193 (UbuntuIrcCouncil) unquieted $~a
<cpaelzer> good morning
<cpaelzer> interesting log of the night :-)
<krytarik> Loooooong. :P
<cpaelzer> I'm happy that all the auto-highlight beeps didn't  wake me up
<cpaelzer> I'd have been kind of angry to get here for "this"
<cjwatson> Unit193: ?
<Laney> infinity: can I merge debhelper 10.4?
<bigon> 22:28 < jtaylor> oh no mystery ... -Os is used << -Os is not only used for libyuv I see, it's used everywhere isn't it?
<jtaylor> bigon: it is used in a lot of places yes
<jtaylor> pretty ad
<jtaylor> b
<jtaylor> odd thing is firefox does not build from source for me so I can't even fix it myself :/
<bigon> I cannot build it on my laptop due to the memory and disk needed...
<Laney> mapreri: was it you that did the bzr -> git conversion for ubuntu-dev-tools?
<Laney> what happened to the changelog?
<bigon> jtaylor: In ./browser/config/mozconfigs/linux64/release I see that MOZ_PGO=1 and BUILDING_RELEASE=1 are set
<bigon> doesn't seems to be the case in debian/rules (at least on debian)
<mapreri> Laney: just that I'm used to generate the changelog at the end before uploading, instead of appending items each time, especially because I wanted to release it soon, but then I was stuck at somebody who wanted to submit some tests for a thing of him, and somebody else who broke the testsâ¦
<jtaylor> who does firefox packaging in ubuntu?
<Laney> mapreri: ok, a README.source or something would be useful then
<Laney> and emptying bzr
 * Laney just pushed a change there :/
<mapreri> Laney: yes, emptying bzr was on the todo, to do as soon as the git one was released
<mapreri> I can apply your change to the git tree, it's not a problem
<Laney> i've done it
<jtaylor> bigon: even mozillas own ppa uses Os ._.
<Laney> mapreri: k, I'm going to release the git version
<Laney> done some hax to make the tests pass
<bigon> jtaylor: official build is -O3
<jtaylor> bigon: is there one for linux?
<jtaylor> I just found the ppa
<bigon> getfirefox.com
<jtaylor> ah thanks
<jbicha> jtaylor: chrisccoulson and ricotz work on Ubuntu's Firefox pkg
<bigon> it's the same in debian
<jtaylor> jbicha: thanks, I'll wait a bit to see what the debian maintainers do, I guess it will trickle to ubuntu anyway
<jbicha> jtaylor: I believe Ubuntu and Debian's Firefoxen are really maintained independently of each other
<jtaylor> so it is worth filing another bug in ubuntu?
<jbicha> yes
<jtaylor> hm there was a dev-tools command for that right?
<jtaylor> right import-bug-from-debian
<bigon> tjaalton: https://pastebin.com/KTvjwytA fedora as well...
<tjaalton> bigon: huh?
<bigon> that's the about:buildconfig page on fedora
<bigon> notice the -Os
<bigon> fedora 25
<tjaalton> why does it concern me?
<bigon> jt<tab> vs tj*
<tjaalton> right
<bigon> nevermind...
<tjaalton> :)
<bigon> jtaylor: ^
<jtaylor> bigon: it seems to be the upstream default so all distros are probably affected
<mdeslaur> jtaylor: affected by what?
<jtaylor> mdeslaur: firefox is mostly built with -Os
<jtaylor> so size optimization which in parts is really bad for performance
<mdeslaur> jtaylor: I think that's the only way for us to get it to build on i386
<mdeslaur> chrisccoulson: ^
<jtaylor> maybe, but why do it on amd64?
<bigon> debian does the same
<bigon> and looking at the logs
<bigon> calls to gcc are -Os and calls to g++ are using -O2
<jtaylor> mdeslaur, chrisccoulson: it is bug 1694425
<ubottu> bug 1694425 in firefox (Ubuntu) "performance critical libyuv built with Os" [Undecided,New] https://launchpad.net/bugs/1694425
<mdeslaur> infinity: I'm stealing your imagemagick mere
<mdeslaur> merge
<mapreri> Laney: thanks!
<nacc> doko: have you looked at all at the mod-gnutls breakage? it seems that a specific test fails on non-amd64
<nacc> dobey: test-24_pkcs11_cert.bash
<nacc> dobey: sorry!
<nacc> doko: --^ :/
<nacc> ah there is LP: #1597450
<ubottu> Launchpad bug 1597450 in mod-gnutls (Ubuntu) "mod-gnutls FTBFS: test failure: apache2 seg fault" [High,Confirmed] https://launchpad.net/bugs/1597450
<slangasek> juliank: I am getting a frustrating segfault from python3-apt while trying to iterate over apt_pkg.SourceRecords(), and it's resisting debugging because the address of the clobbered struct changes each time, making gdb watchpoint useless. Do you have any advice on debugging?
<juliank> slangasek: Just iterating, or accessing properties? In any case, I'd try to get a stack trace. That usually is enough for me to find the issue (unless it's a binary cache issue, but I don'
<slangasek> juliank: accessing properties (package, binaries, build_depends)
<Beret> anyone tried booting the artful daily lately?
<Beret> doesn't boot here
<slangasek> juliank: stack trace: http://paste.ubuntu.com/24718290/
<slangasek> juliank: if I go up a few frames: http://paste.ubuntu.com/24718293/
<juliank> slangasek: Is that a package with no build-depends?
<slangasek> juliank: and .Package suspiciously spells 'ython-c'
<slangasek> let's see
<juliank> or no, it must be different, but the loop in python-apt is weird.
<powersj> Beret: looks like server hasn't promoted an ISO for almost a week, hasn't passed smoke test.
<Beret> powersj, this is desktop but I suspect it's the same issue
<slangasek> juliank: seems to fail on Package: dq which does have build-depends
<Beret> powersj, what's failing?
<Beret> powersj, and what do you do with the knowledge that it doesn't work?
<juliank> slangasek: confirmed (on debian).
<powersj> Beret: need to see what exactly is failing, all the tests say is boot timeout
<Beret> ah yep
<powersj> Beret: downloading now and will spin something up shortly
<Beret> thanks
<juliank> slangasek: Looks like a off-by-one error
<juliank> slangasek: patch: https://paste.ubuntu.com/24718367/ - might want to fix this in APT, though
<juliank> slangasek: Basically, APT sets the OR flag for the left side of  libnacl-dev [amd64] | libnacl-dev [i386], indicating that more items are in the or group; but then ignores the right side because it does not match the architecture.
<slangasek> right :)
<juliank> slangasek: The same problem also happens with stuff like a [right] | b [wrong], c which gets passed as a | c
<juliank> I think I have a patch for APT to fix that.
<slangasek> indeed
<juliank> slangasek: The patch is https://paste.debian.net/953788/, but it seems broken in case there are multiple elements in an or group. Not yet sure how to handle that.
 * slangasek nods
<slangasek> of course, in the case of dq this could be expressed as ANDed b-d instead of ORed
<slangasek> and I'm just ignoring the package for my own purposes ;)
<powersj> Beret: LP: #1694531
<ubottu> Launchpad bug 1694531 in ubiquity (Ubuntu) "17.10 Install Fails to Start" [Undecided,New] https://launchpad.net/bugs/1694531
<Beret> powersj, thanks
<Beret> powersj, I don't even get to choose anything
<Beret> the kernel doesn't even boot
<powersj> oh wow
<powersj> Beret: you were using desktop ISO? Ubuntu? or specific flavor?
<Beret> desktop iso
<juliank> slangasek: https://github.com/Debian/apt/compare/master...julian-klode:bugfix/fix-or-in-build-dep-parsing?expand=1 is running CI now, let's see if I did not break anything.
<juliank> slangasek: The off-by-one error should be fixed too, though, especially given the already fairly long APT SRU queues.
<juliank> slangasek: I guess there's no bug report in launchpad yet, you just found that out? I want to add a bug to reference in the commit / changelog
<juliank> Although probably one bug for the off-by-one in python-apt, and one for the apt bug
<juliank> (not sure how that works with SRU verification if I have multiple packages in the same bug report...)
<slangasek> juliank: correct, no bug because I just stumbled over it
<juliank> I'll write the bugs and test case for apt tomorrow when I wake up again. It's close to midnight now.
<Beret> powersj, my issue was a failing usb key
<powersj> Beret: good, because my desktop install finished a bit ago :)
<tsimonq2> maxy: ack :)
<tsimonq2> Argh
#ubuntu-devel 2017-05-31
<jamespage> xnox: morning
<jamespage> xnox: quick q for you - which boost version are we going to default for artful?
<jamespage> if there is an archive-admin around - please could vine be promoted to main (approved under bug 1688091)
<ubottu> bug 1688091 in vine (Ubuntu) "[MIR] vine" [High,Fix committed] https://launchpad.net/bugs/1688091
<jamespage> that will help with unblocking the proposed migration of openstack pike1 updates before I start on pike2 this week
<ogra> since when is this channel +r ? thats quite annoying
<cjwatson> ogra_: spammers ruin things for everyone, probably
<ogra_> yeah
<cjwatson> we had a *lot* of junk over the last few days
<ogra_> i noticed and i guess i'll live with +r ... just annoying
<mdeslaur> is there a way to make hexchat wait until after identification before trying to join?
<Laney> you can authenticate during connection
<Laney> https://freenode.net/kb/answer/hexchat
<mdeslaur> Laney: oh! cool, thanks
<mdeslaur> Laney: that worked, thanks
<Laney> mdeslaur: â¥
<juliank> OK, so I opened both bug 1694702 and bug 1694697 for tracking the issue slangasek reported yesterday. We can SRU both, but validation might get a bit complicated because the patch for apt also works around the off-by-one problem in python-apt
<ubottu> bug 1694702 in python-apt (Ubuntu) "off-by-one error when translating source records build depends" [High,In progress] https://launchpad.net/bugs/1694702
<ubottu> bug 1694697 in apt (Ubuntu) "build-depends keeps OR flag if end of or group is ignored" [High,Fix committed] https://launchpad.net/bugs/1694697
<juliank> That is, you'll have to test python-apt without the coming proposed apt, otherwise you don't see the issue at all
<mdeslaur> cpaelzer: hi! think you could merge strongswan to get the security fixes?
<cpaelzer> mdeslaur: hi did they update Debian - let me check
<cpaelzer> mdeslaur: you don't mean the 5.5.2-1 in experimental but the 5.5.1-4 in unstable right?
<mdeslaur> right, -4 in unstable has the security fixes
<cpaelzer> yeah I can look at it mdeslaur
<mdeslaur> cpaelzer: thanks!
<cpaelzer> next time when libvirt is compiling an hour ...
<Laney> sword fight time
<cpaelzer> Laney: https://xkcd.com/303/ ?
 * Laney nod
<Laney> :)
<Laney> infinity: Stealing the debhelper/exp merge
<cpaelzer> mdeslaur: the cve patches are not the nicest
<cpaelzer> mdeslaur: would this cause you any headache http://paste.ubuntu.com/24726825/ ?
<cpaelzer> I mean buildpkg is happy, yet I wanted to ask you at least
<mdeslaur> I don't mind if that's how they are in the debian package
<mdeslaur> cpaelzer: ^
<bmw> rbasak: I just wanted to check on the status of certbot packages
<bmw> do you know if Peter submitted the documents you need?
<rbasak> bmw: o/
<rbasak> bmw: not that I know about
<bmw> hmm okay
<bmw> he'll be somewhat MIA for the next week or two, but I'll get a hold of him and ask him to do it or write it up myself
<rbasak> bmw: I've started pushing SRU branches to alioth. So far I've done python-acme for all three stable Ubuntu releases, and the special python-letsencrypt to cover the rename in Xenial.
<rbasak> bmw: thanks!
<bmw> is the document from Peter a blocker for pushing the SRU packages live or just necessary for updates in the future?
<rbasak> Good question.
<rbasak> It's not technically a blocker, but it will duplicate work I think - because we'd have to lay out our justifications twice.
<bmw> ah that makes sense
<bmw> we'll get it written up to avoid duplicating work
<bmw> the other thing from my end is finding someone to build the packages in the future
<bmw> I've gotten some interest from coworkers, but no commitment yet
<bmw> I'll keep badgering people and I'm sure we'll find someone to do it
<rbasak> Thanks!
<infinity> Laney: Given the changelog, I didn't have a lot of confidence in debhelper/experimental...
<nacc> rbasak: hrm, something is wrong with the import of python-acme that you pushed, i think
<nacc> rbasak: i think true for src:gosa as well -- it's like you weren't current to launchpad
<nacc> rbasak: we should sync up on this, as something is funky. your gosa import is really weird. the tags exist, but the branches weren't moved for later versions
<nacc> rbasak: yeah, python-acme is fubar. It would appear you pushed / committed the queue syncs? e.g. https://git.launchpad.net/~racb/ubuntu/+source/python-acme/commit/?id=2de942f7a60d7a04900eedacbf68d8e736fd9b1a
<nacc> bah, nm, that's me looking in the wrong repo!
<nacc> https://git.launchpad.net/~usd-import-team/ubuntu/+source/python-acme/commit/?h=debian/experimental&id=cc8febe8e4f44e9d582fed976cace9c1d26c8358 seems odd, though, there's no tag for that version
<nacc> which then breaks the patches-applied import
<rbasak> nacc: got to run, but if it helps, http://paste.ubuntu.com/24729486/ is my gosa tag list in my local tree from the importer run.
<jdstrand> tyhicks: hey, curious on your thoughts about click-apparmor and apparmor-easyprof-ubuntu in artful
<jdstrand> tyhicks: they used to be in main and have been demoted to universe this cycle
<jdstrand> tyhicks: the security team is listed as the maintainers. the only thing keeping them is a recommends from click. my preference would be to remove them or somehow get them off our plate
<cjwatson> it may make sense to remove click
<jdstrand> tyhicks: so removal or move to another owner. motu?
<jbicha> why would anyone use click in 18.04?
<tyhicks> jdstrand: good question - I'd think that click could go away
<jdstrand> jbicha: precisely. I just don't know if someone is going to do a unity8 flavor or something
<jbicha> is click needed for unity8?
<jdstrand> aiui, there is an open click store and other projects (free phone?) are using it. but I don't know if they're built from the archive
<jdstrand> jbicha: not strictly. but that's where the apps are
<jdstrand> I mean, I'm fine with removing click and click-apparmor. they aren't used in Ubuntu by anything I know of and there is nothing saying that a flavor couldn't bring them back
<jbicha> I believe unity8 stuff is being removed from Ubuntu, but they could be reintroduced if someone steps up to maintain them
<tyhicks> that'd be my preference
<tyhicks> remove it and then allow anyone else to jump in and restore the package
<jdstrand> I just know that if it is in the archive, regardless of universe or main, we'll feel obligated to fix issues, but that isn't the best use of our time
<tyhicks> agreed
<jdstrand> cjwatson: what are your thoughts on that? ^
<cjwatson> I agree
<cjwatson> I guess I'd say that it can be removed together with unity8, if and when it is removed
<jdstrand> that probably makes the most sense. I'll talk to the desktop team about their plans
<jdstrand> tyhicks: in the meantime, I'm going to adjust LP to show the upstream projects are not active and break the link from the ubuntu project to the upstream
<tyhicks> jdstrand: good idea
<tyhicks> jdstrand: think we should do an upload to update the Maintainer? IMO, that's not needed unless someone else takes over maintenance and/or the package is to remain in the archive for 17.10
<jdstrand> tyhicks: I could probably do a quick upload. I'll talk to the desktop team and get more details
<tyhicks> thanks
<nacc> rbasak: ah interesting -- so i was able to import gosa, but the empty directory fix makes `git ubuntu merge` not work -- let's sync up on it tmrw
<nacc> rbasak: also, could you peek at LP: #1693954  -- is /etc/mysql/debian.cnf a generated file normally? I can't tell if it's a configuration issue (apt-file doesn't indicate it's owned by the package)
<ubottu> Launchpad bug 1693954 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 (not installed) failed to install/upgrade: subprocess new pre-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1693954
#ubuntu-devel 2017-06-01
<Unit193> nacc!
<nacc> Unit193: what's up? :)
<Unit193> nacc: I saw you alive!  Do you think you could take care of https://bugs.launchpad.net/bugs/1694864 and Bug 1692074?
<ubottu> Launchpad bug 1694864 in variety (Ubuntu) "Sync variety 0.6.4-1 (universe) from Debian experimental (main)" [Wishlist,New]
<ubottu> bug 1692074 in parsedatetime (Ubuntu) "Sync parsedatetime 2.3-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/1692074
<nacc> Unit193: i can look -- although EOD for me already (might be tmrw). Is there a reason we want to sync from experimental specifically for these two?
<Unit193> I figured it was getting close, yeah.  variety is only in experimental due to the freeze, changelog lists a LP bug, and Debian maintainer is very good with the sync.  Latter because it gives a py3 module.
<nacc> Unit193: got it, i'll review it tmrw first thing
<Unit193> nacc: Thanks very much!  (And the py3 module is useful because gcalcli had a beta release that goes python3, and recommends that.)
<nacc> Unit193: np
<Skuggen> nacc: /etc/mysql/debian.cnf is generated, yes
<Skuggen> Though I actually have a change in review that will stop using it
<Skuggen> Looks like it's using /etc/init.d/mysql to try to shutdown any existing server, which is a bit odd https://anonscm.debian.org/cgit/pkg-mysql/mysql.git/tree/debian/mysql-server-5.7.preinst?h=mysql-5.7/ubuntu/zesty#n41
<juliank> xnox: OK, so apparently the apt systemd jobs are wrong, I accidentally passed -d to unattended-upgrades for download, but that enables debug mode - and nobody noticed it. Seems this needs more work.
<juliank> I wanted --dry-run according to --help, but in reality that also has some debugging output, so we really need to patch unattended-upgrade to have a download-only mode :(
<jamespage> xnox: around? I have a boost query to which I can't google the answer
<jamespage> xnox: specifically I need boost_container for the latest ceph release, but afaict boost in Debian and Ubuntu does not build this component?
<jamespage> but my knowledge in this pkg is limited so I may be missing something
<jamespage> xnox: raised some bugs to track - https://bugs.launchpad.net/ubuntu/+source/boost/+bugs?field.tag=ceph
<jamespage> have a second problem with no s390x packages for context or coroutine as well
<jamespage> any help mucho appreciated
<infinity> juliank: +1 for a --download-only that does what it says on the tin.
<infinity> juliank: Amazed that none of the people involved in said changes noticed that -d doesn't really do a thing. :P
<juliank> infinity: Yeah
<juliank> I was wondering if we want to play with phased updates in apt? That would be fun
<infinity> juliank: Let phasing percentage affect priority, or...?
<juliank> Holding back updates that are not currently rolled out for the current machine in the current phase.
<infinity> juliank: The problem is that, so far, "apt-get dist-upgrade" has been the published way to get updates *now*, if you don't want to deal with update-manager's phasing.
<infinity> juliank: So, we'd have to re-teach that as "use some pinning", or "apt-get --ignore-phasing".
<juliank> Well, we can make it optional.
<juliank> and non-default.
<infinity> Or that.
<juliank> I think it might be useful to people who manage their systems with ansible or stuff
<infinity> Having the logic in apt so that frontends like update-manager can be dumber certainly seems like a win.
<juliank> infinity: and as a bonus point, this (can) also makes phased upgrades work with PackageKit.
<infinity> I kinda wish PackageKit would just go away, but I realize I'm fighting a losing battle there.
<juliank> And of course unattended-upgrades if configured to install SRUs too
<infinity> It's all fine and dandy for people to tell me PK is the new hotness and aptdaemon is unmaintained crap, but aptd does what we want and PK (so far) doesn't.
<juliank> aptd is still unmaintained, though :)
<infinity> And, from my POV, still is PK if it doesn't have feature parity.
<infinity> "Maintained, but isn't useful" is pretty much "unmaintained".
<infinity> s/still/so/
<infinity> But I guess we need to reinvent every wheel every few years or we might accidentally make progress at some point.
<infinity> And then the machines would take over.
<juliank> infinity: Yeah, but we'll eventually reach the point where enough stuff is there, so the "unmaintainedness" reached parity.
<infinity> And then Terminator and/or The Matrix happens.
<infinity> And no one wants that.
<juliank> And once both options are basically equally bad, dropping the one that needs more attention will be the smart move :)
<infinity> juliank: Sure.  And, conceptually, a single API into all package managers is a noble goal.  But until it can replace the things we've historically done with aptd, I just don't see the motivation to care.
<juliank> Need to track the list of missing things somewhere
<juliank> Currently I only have "phased updates" and "not reboot for upgrades"
<infinity> "I'm sorry your fully-functional Honda sedan is out of warranty and might need occasional service, please switch to this trout-drawn red wagon."
<juliank> infinity: re phased updates in apt, maybe it makes sense to compromise on apt (the friendly frontend) doing phased updates, and apt-get doing unphased.
<infinity> juliank: Maybe it's come a long way since the last time I looked.  Historically, it was pretty much useless at doing anything remotely complex.  Whereas aptd was literally just a way to escalate "apt-get <command> <arguments>" to a priveleged backend, so could literally do anything apt could do.
<infinity> juliank: Maaaaybe?  I kinda hate the place where apt and apt-get commands produce different results.
<infinity> juliank: This is why, for instance, people whine when 'apt-get upgrade' doesn't install new deps, because 'apt upgrade' does.
<infinity> (Though, in that case, I think apt-get just needs upgrade redefined)
<juliank> I think the differences are not really a good thing, but it's sometimes the best we can get without breaking existing scripts.
<Unit193> Amusingly, I was surprised the other way round, where `apt upgrade` wanted to.  I had to fall back.
<juliank> I think some stuff should eventually migrate over to apt-get after 2 years
<infinity> I think it's a mistake (and has been since day 1), that "apt-get upgrade" doesn't install new deps.  Refusing removals is good, refusing new installation is obtuse.  But that's going to be a long debate.
<infinity> Mostly I believe this due to the way we abuse new installs for kernel packages, but it's equally true that you wouldn't want a security upgrade held back because it needs to pull in a new benign dep, etc.
<infinity> And after some longwinded bug reports that proved we have many users who think that "apt-get upgrade" is keeping them up to date, I'm now terrified that we have thousands of machines out there that have never had a kernel upgrade since GA. :P
<infinity> Don't know if this is because of "apt upgrade", or yum/dnf semantics being different, or bad advice on forums/stackexchange, or just because "upgrade" should probably upgrade your machine, but the damage is done, and I don't think we can reeducate.
<infinity> juliank: So, yeah, I think changing behaviour of "apt-get upgrade" for 18.04 and stretch+1 (cause that's definitely not somewhere where Ubuntu should gratuitously differentiate) would be a very worthwhile thing to debate for about 10 minutes and then JFDI regardless of dissent. :P
<infinity> juliank: As for phased versus not.  Maybe apt could behave differently.  It would need to be very well called out in the docs how to turn it on for apt-get and off for apt and what the defaults are.
<infinity> juliank: Though, if the supposed intent is that "noobs" use apt and long-bearded fuddy-duddies use apt-get, I'm not sure that'll ever really come to pass, because when someone like me tells people how to do a thing, I do it in my language (apt-get), and that gets cargo-culted all over until someone copies and pastes it blindly. :P
<infinity> juliank: So, at the end of the day, I'm not sure behaviour difference between identical invocations should ever exist, as the "noob" won't even really know they're different commands or why, except that one is prettier.
<infinity> juliank: I mean, inconsequential behaviour differences like automatically cleaning up and whatnot are fine, but different outcomes are probably unwise.
<infinity> juliank: Cause I say "run apt-get install foo bar-" and they run "apt install foo bar-" and wonder why it's different (if it is, but you get my point).
<infinity> juliank: This isn't without precedent.  We had the same issue when people socialised the incorrect meme that "aptitude install <foo>" == "apt-get install <foo>", and it really wasn't.  It was sometimes a debugging nightmare.
 * infinity decides to try to nap.
<kyrofa> Hey apw, I need some SRU advice. Got a sec?
<apw> kyrofa, ask i may (or may not) have a clue
<kyrofa> apw, you're familiar with the snapcraft click SRU blockage
<apw> kyrofa, i am aware of the "fun" you are going to be having yes
<kyrofa> apw, well, the world just got bit by setuptools v36
<kyrofa> bug #1694945
<ubottu> bug 1694945 in Snapcraft "setuptools v36.0.0 breaks the python plugin" [Undecided,New] https://launchpad.net/bugs/1694945
<kyrofa> apw, everyone building python snaps is now blocked until we can ship the fix for that
<apw> kyrofa, lovely ...
<apw> kyrofa, do we even have an upload fixing click ?
<kyrofa> apw, in the fairy tale in my head, we just boot the pending SRU that uses click to get it out of the way
<kyrofa> apw, no, click change is still in review
<apw> kyrofa, so you want to rip the current snapcraft and replace it with a 2.29.1+* sort of thing ?
<kyrofa> Yes
<kyrofa> Thoughts?
<apw> kyrofa, give me a sec to check ...
<kyrofa> apw, 2.29.2 I suppose
<apw> kyrofa, ok ... so yes, if i rip 2.30* you can then upload a 2.29.x with the python3 fix to unblock people
<sashok> hello
<apw> kyrofa, that _does_ kill 2.30* so you would need to go to 2.30.1 or something when it comes back
<kyrofa> apw, excellent. But what about artful?
<kyrofa> Ah, we can apply the patch in two places
<kyrofa> And just release 2.30.1 in a
<apw> kyrofa, well there is nearly noone up there right?  and the two people who have click installed will have already been in the poo (such as me)
<apw> kyrofa, so as long as you 2.30.1 that fix say then i think we are copestetic
<kyrofa> apw, okay good deal. Can you please pull 2.30, then?
<apw> kyrofa, so is that an official request for snapcraft/2.30* sru to die
<kyrofa> apw, indeed it is
<kyrofa> We'll re-propose once the click fix is in
<kyrofa> apw, this will be the only change between 2.29 and 2.29.1: https://github.com/snapcore/snapcraft/pull/1339/files
<kyrofa> apw, think we can turn that around pretty quickly?
<apw> kyrofa, ok removed (modulo publisher)
<apw> kyrofa, yes, that is a serious regression aiui right, as in nothing snaps right now if it has python3
<kyrofa> Or python2
<kyrofa> Indeed, thank you for your help :)
<apw> kyrofa, heh, that is likely 99% of snappers ...
<apw> kyrofa, so you have an SRU exception which lets the release hold
<apw> kyrofa, be shortened if you test it, and i assume you will do that quickly
<apw> kyrofa, so ... if you could get those into the queue asap and ping me on #ubuntu-release as soon as they hit please
<kyrofa> apw, you got it, thanks again!
<cpaelzer> rbasak: (and others) I still wonder about one thing on conffile handling - when looking e.g. at the following what is the reason/beneift of having line 5&6 ? https://anonscm.debian.org/cgit/pkg-libvirt/libvirt.git/tree/debian/libvirt-daemon-system.maintscript
<cpaelzer> I want to complete my understanding of that, but that piece of the puzzle didn't reveal itself yet
<cpaelzer> sorry line 6 & 7
<infinity> cpaelzer: As opposed to any of the other similar lines?
<infinity> cpaelzer: (Not sure I know what you're asking)
<infinity> cpaelzer: But, in a nutshell, when a conffile is no longer shipped by a package, it's not removed until the package is purged.  So, on upgrade, you accumulate cruft if you keep removing conffiles from the package without doing something about it.
<infinity> cpaelzer: In the bad old days, that "something" would just be an rm -f ... rm_conffile makes some attempts to preserve the file if it was modified by the end user, so they can preserve their changes elsewhere, or translate them to the new world order.
<infinity> cpaelzer: Though, in the case of a "shipped by accident" file, like 6&7, I could see an argument for just unconditionally whacking it, it also doesn't hurt to use the rm_conffile facility on the off chance someone *thought* it was a useful file and made changes to it, so they can consult those changes and put them in the right file(s).
<rbasak> nacc: git ubuntu merge sync> ack
<rbasak> nacc: LP: #1693954> I marked Incomplete. Seems likely that the user deleted that file locally, or has otherwise hacked things up. Or if not, then we need a proper bug report really, rather than a "I have an error message" report.
<ubottu> Launchpad bug 1693954 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 (not installed) failed to install/upgrade: subprocess new pre-installation script returned error exit status 1" [Undecided,Incomplete] https://launchpad.net/bugs/1693954
<cpaelzer> thanks infinity, I think I got the general need for conffile removal - what I asked in particular on line 6 & 7 is that it is the SAME line but with different package names
<cpaelzer> what does that achieve in addition to listing it once
<cpaelzer> In that case the file "ownership" moved in the past, I assume it might be about removing it "from both packages" - but the file goes away on either invocation, so why listing both lines
<rbasak> cpaelzer: IIRC, dpkg-maintscript-helper will only act on a conffile if it is owned (as seen by dpkg) by the package listed.
<rbasak> So the two lines mean that the conffile with that name will be removed if owned by either package.
<rbasak> Perhaps both packages dropped in that conffile in the past?
<infinity> cpaelzer: Yeah, what rbasak said.
<infinity> cpaelzer: If it's owned by one package and you call if for another, it should blissfully ignore your request to remove it.
<cpaelzer> so the double line is a safety like "whoever owns it atm" in the mind of dpkg
<rbasak> That's the effect it has, yes.
<cpaelzer> hrm, ok so in my case I know who owns it so I can list only one
<cpaelzer> thank you both rbasak and infinity
<cpaelzer> this issue I'm on was just messy enough that I wanted to make sure I understand that bit as well
<infinity> cpaelzer: You shouldn't need to list <package> at all, if you're doing the rm_conffile bits in the right package's maintainer scripts.
<infinity> cpaelzer: And, in fact, it's better if you don't, cause then you also don't have to think about if you should or shouldn't have an arch qualifier, etc.
<cpaelzer> yeah that is what dpkg-maintscript-helper told me as well
<infinity> cpaelzer: The libvirt case above was super special because he was using one package's maint scripts to remove a conffile that was potentially in a different (and no longer existent) package previously.
<cpaelzer> which is just where I am in now, but that solves it
<cpaelzer> the maintscript function ensure_package_owns_file e.g. on a mv_conffile will check source and target
<cpaelzer> so if at the same time it renamed + moved between packages
<cpaelzer> then I need the double lines
<cpaelzer> which is slightly different to the examples rm_conffile example, but still makes sense now
<cpaelzer> thanks
<nacc> rbalint: thanks on the sql bug
<nacc> rbasak: --^ rather!
<nacc> Skuggen: ah thanks for the context, I was trying to figure that out without installing mysql myself in a test env :)
<slangasek> Laney: fwiw debhelper 10.4 appears to cause cdbs to FTBFS
<slangasek> (and possibly misbehave at runtime?)(
#ubuntu-devel 2017-06-02
<jtaylor> bigon: I got mozilla to change their firefox optimization default :D
<bigon> yeah \o/
<bigon> you have a bug#?
<jtaylor> https://hg.mozilla.org/integration/autoland/rev/8fdb9e30b6a7
<abeato> infinity, hey, I registered a bug in debian for klibc: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863761
<ubottu> Debian bug 863761 in klibc-utils "klibc-utils: klibc does not support the reboot syscall argument" [Normal,Open]
<abeato> ogra_, ^^
<ogra_> wheee!
<Laney> slangasek: fixed
<slangasek> Laney: cheers :)
<bigon> jtaylor: "
<bigon> We however keep -Os as default for debug builds for now, because -O2
<bigon> triggers -Werror=strict-overflow failures somehow. "
<bigon> shouldn't that be -Og for easier debugging?
<bigon> or no -O option at all?
<jtaylor> probably compatibility with older gccs
<jtaylor> and Og is not very good
<jtaylor> though probably not worse than Os
<bigon> do you know in which version that patch will land?
<jtaylor> version 55
<bigon> thx
<pdeee> rbasak, bmw I've drafted an SRU justification for Certbot 0.14.0, and a template for future SRUs
<jamespage> slangasek: hi!
<jamespage> slangasek: so... what's the position on a package electing to not support 32bit architectures?  ceph as a project are not actively testing 32 on arm or i386
<nacc> cjwatson: perhaps you would have the context, is it appropriate to drop the same changes you did in LP: #1334916 for consolekit, in trusty?
<ubottu> Launchpad bug 1334916 in openssh (Ubuntu Trusty) "sshd-ConsoleKit integration patch causes abrupt termination of multichannel sessions" [Undecided,Confirmed] https://launchpad.net/bugs/1334916
<slangasek> jamespage: for future releases, it's ok to drop the package; for existing releases, we would want to continue providing the package if at all possible despite upstream not testing
<slangasek> jamespage: do we have autopkgtests?
<cjwatson> nacc: I'm afraid I don't have the context for that any more - it would involve working out whether the desktop uses consolekit, and whether e.g. you can ssh to a trusty desktop without that patch and with X forwarding and run programs that do policykit checks that the user is an admin
<cjwatson> (which IIRC was the original use case)
<nacc> cjwatson: ok, I'll put it on the backlog then :)
<nacc> mdeslaur: there might be a security regression in LP: #1690380 -- upstream adjusted the change they did (with the commits mentioned in my last comment)
<ubottu> Launchpad bug 1690380 in nagios3 (Ubuntu) ""Cannot open log file '/var/log/nagios3/nagios.log' for reading" error from nagios web UI when view alert history etc." [Undecided,Confirmed] https://launchpad.net/bugs/1690380
<mdeslaur> nacc: thanks, I'll look on mondayt
<nacc> mdeslaur: thanks!
<Unit193> nacc: Did you get a chance to look at parsedatetime?
<nacc> Unit193: argh, sorry! doing it now
<Unit193> Thanks.
<jamespage> slangasek: limited - however it is possible to test i386 with the charms for ceph
<jamespage> slangasek: we're ok for 10.2.x (current stable); next stable (12.0.3) is not so 32bit friendly - that said it is probably fixable
<jamespage> slangasek: so this is >= artful only
<slangasek> jamespage: right, it's perfectly fine to drop architecture support for a package between releases
<jamespage> slangasek: ok I've raised on the upstream ML - lets see if users are actually using armhf or i386 :-)
<slangasek> I mean, we want to support packages on every architecture we can, but you're not expected to make a herculean effort to support something that upstream doesn't
<infinity> I think we're approaching the point where we need to have a large public discussion about possibly dropping armhf and i386 entirely (post-18.04, perhaps).
<infinity> Though I might prefer pre-18.04, it's perhaps a bit late to suggest that.
<jbicha> I don't think we have to provide installers for i386 and armhf for 18.04 LTS
<mardy> Mirv: hi! At ubports there's an ongoing discussion on whether to move to qt 5.9. Do you have any wise things to say? :-)
<jbicha> a compromise idea: what about restricing support lifetime for i386 and armhf to 3 years to match 16.04 LTS?
<sarnold> i386 I think you're right, but arm still has a huge amount of enthusiasm from hobbyists
<sarnold> i386 feels like it only exists at this point to cause guitarpro6 users insane amounts of trouble with their sudo packages
<mardy> Mirv: like, do you know if Debian or KUbuntu will package it?
<Unit193> sarnold: My netbook doesn't do amd64 either though. :/
<jbicha> mardy: part of Qt 5.9 is in Debian exp.
<mardy> jbicha: mmm... good to know, thanks!
<jbicha> mardy: I thought ubports was only working on vivid and xenial?
<sarnold> Unit193: oh :(
<infinity> jbicha, sarnold: We already don't provide any non-d-i images for armhf, turning off d-i images would be trivial, but probably also pointless.
<infinity> jbicha: Agree with dropping i386 ISOs, though.
<sarnold> infinity: the usual debian/ubuntu problem of you only see the installer once and just upgrade for the next twenty years? :)
<mardy> jbicha: correct, but we are discussing which qt version to use. If debian has already packages for qt 5.9, building them on a PPA for xenial will be easier (than do the whole packaging ourselves)
<infinity> sarnold: Right, while dropping an installer image will remove some new users, I'd argue that i386/armhf really aren't seeing a mess of new users anyway (ubuntu-core and rpi2 might be a sticky "but" there), it's old users we need to eventually convince to throw away their hardware or reinstall lm-compatible hardware with amd64.
<mardy> jbicha: looks like qtbase and qtdeclarative are there at least! That's plenty to work with :-)
<jbicha> mardy: are you saying that ubports does not use the Ubuntu archive version of Qt?
<sarnold> infinity: I swear I'm going to upgrade my pandaboard to trusty one of these days. honest.
<infinity> sarnold: Pandaboards are pretty aerodynamic.
<infinity> sarnold: Just sayin'.
<mardy> jbicha: it does for now, but xenial has Qt 5.5, which is rather old
<sarnold> infinity: hehehe
<mardy> jbicha: in case you are interested: https://forums.ubports.com/topic/273/june-1-2017-app-developer-os-developer-meeting/6
<infinity> sarnold: I have a whole graveyard of ARM dev boards here that I have no idea what to do with.
<jbicha> mardy: I believe mitya57 would definitely appreciate some help in getting Qt 5.9 into Ubuntu, updating qt-creator, etc.
<jbicha> mardy: I don't want to speak for Mirv but maybe he's not currently working on Qt in Ubuntu?
<mardy> jbicha: I'm afraid you are right; I just thought that he might know better. But I'm happy to bother mitya57 as well ;-)
<cjwatson> infinity: or sidegrade, for the smart/adventurous/mad ones
<cjwatson> i386> I'll still campaign for keeping it in the archive, for the usual reason William and I quote (i.e. containers running a half-million lines of Python take noticeably less memory that way)
<sarnold> do they still run a useful load with only ~2.5 gigs address space per process?
<cjwatson> they run the LP test suite just fine
<sarnold> aha :)
<Unit193> mwhudson: Right, so Debian 863998 was just filed (Linking to https://github.com/golang/go/issues/13191), which looks like Debian 849662 but yet I believe it still doesn't compile on arm?
<ubottu> Debian bug 863998 in src:golang-defaults "golang-defaults: Getpagesize() always returns 65536 on arm64" [Normal,Open] http://bugs.debian.org/863998
<ubottu> Debian bug 849662 in src:gocryptfs "gocryptfs: FTBFS on arm64: panic: page size incorrect: 65536" [Important,Open] http://bugs.debian.org/849662
#ubuntu-devel 2017-06-03
<Unit193> Ah OK.  New testbuild makes arm64 pass, but ppc64el still fails.
#ubuntu-devel 2018-05-28
<nicolas17> looks like packages.ubuntu.com is broken
<nicolas17> https://packages.ubuntu.com/dpkg where are trusty and xenial?
<nicolas17> https://packages.ubuntu.com/xenial/dpkg package not available
<rbasak> nicolas17: agreed
<nicolas17> https://packages.ubuntu.com/xenial/gcc-4.7 internal server error
<rbasak> Looks like it knows about Trusty but has nothing indexed for it.
<nicolas17> looks like many packages (like dpkg) are missing from https://packages.ubuntu.com/xenial/allpackages, and those that *are* listed give internal error
<rbasak> nicolas17: file a bug maybe? There's a report link at the bottom of the page.
<rbasak> Already reported
<rbasak> https://bugs.launchpad.net/pkg-website/+bug/1773488
<ubottu> Launchpad bug 1773488 in pkg-website "Website only lists packages for Cosmic" [Undecided,New]
<rbasak> And https://bugs.launchpad.net/pkg-website/+bug/1773646
<ubottu> Launchpad bug 1773646 in pkg-website "packages.U.C does not show packages for trusty" [Undecided,New]
<rbasak> And some other duplicates
<cpaelzer> juliank: hi, I saw you recently retrying gearmand on armhf @xenial
<cpaelzer> juliank: I hit the same, seems like an unrelated issue, did you debug that in detail?
<cpaelzer> as there was no britney hint yet, how did you get past - just askind the SRU Team to force it through?
<juliank> cpaelzer: no
<juliank> I don
<juliank> ugh
<juliank> I did not debug it in detail. I just retried against release and verified it's not a regression that way.
<juliank> and noted that in the SRU bug for util-linux
<cpaelzer> ok, I will take a short look at least but might end up the same
<cpaelzer> I was wondering about a britney hint, but for that I'd want to understand what exactly breaks :-/
<mitya57> doko: hi, did you see bug 1771044? What are your plans about it?
<ubottu> bug 1771044 in redshift (Ubuntu) "sysconfig-debian-schemes.diff patch causes Python packages to FTBFS" [High,Triaged] https://launchpad.net/bugs/1771044
<mitya57> (The bot chose a wrong task, in fact it is a bug in python3.6.)
<juliank> apw: looking at kmod merge, I guess it's safe to drop module-init-tools now?
<juliank> it says remove before 18.04 :D
 * juliank assumes yes and uploads
#ubuntu-devel 2018-05-29
<bluesabre> slangasek: thanks for the merge! :)
<bluesabre> who should I reach out to for updating nusakan? Following along with https://wiki.ubuntu.com/Germinate/ConvertingToGit step 10...
<tsimonq2> bluesabre: Anyone Canonical-employed that is in https://launchpad.net/~ubuntu-cdimage is the "rule of thumb"
<tsimonq2> bluesabre: (He probably already did it.)
<bluesabre> Neat.
<bluesabre> Time for bed now, thanks slangasek and tsimonq2 for the help
<tsimonq2> o/
<slangasek> bluesabre: yeah, it's done
<acheronuk> tjaalton: has been brought up in #plasma that xorg-server 1.20 causes freezing/gltches  on some things due to yet unresolved mesa issue
<acheronuk> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900316
<ubottu> Debian bug 900316 in kde-plasma-desktop "[kde-plasma-desktop] KDE plasma taskbar icons corrupted with graphical glitches on mouse over" [Important,Open]
<acheronuk> https://bugs.freedesktop.org/show_bug.cgi?id=106351
<ubottu> Freedesktop bug 106351 in Mesa core "Freezes with plasmashell and steam client" [Normal,New]
<acheronuk> https://lists.freedesktop.org/archives/xorg-devel/2018-May/056829.html
<acheronuk> maybe you are aware of that, but FYI if not
<tjaalton> acheronuk: I know
<acheronuk> tjaalton: ok. thanks :)
<m4t> hi, does anyone know if there are plans to update gcc-8 on 18.04 to the actual 8.1 release? or will it remain as the 8.0 devel version?
<m4t> i've got it from the ppa but i just saw breakage w/rt "libobjc4 : Depends: gcc-8-base (= 8-20180414-1ubuntu2) but 8.1.0-1ubuntu0.1"
<xnox> m4t, i believe doko mentioned doing something like that. But it is yet to be determined if that will happen.
<m4t> ok thanks
<Odd_Bloke> I have an autopkgtest image I built using autopkgtest-buildvm-ubuntu-cloud a while ago that always has to apply a bunch of upgrades when I use it; is there a good way to update that image, or shall I just build a new one using that command?
<nacc> Odd_Bloke: if you invoke autopkgtest-buildvm-ubuntu-cloud with the same arguemnts, it should update the image in place, iirc
<nacc> that's how the lxd builder works
<Odd_Bloke> nacc: Hmm, it does not appear to work that way.
<Odd_Bloke> Oh well, no big deal.
<tjaalton> LocutusOfBorg: if you have pending changes to vbox, maybe upload soon to build against the new xserver
<tjaalton> "soon" being relative, and I can do that too if there's nothing else
<nacc> Odd_Bloke: ah it's documented for -build-lxd, but not buildvm
<nacc> seems like it should be feasibly to extend buildvm to build and/or update
<coreycb> hello sru team, bug 1750121 has completed verification and is ready to promote
<ubottu> bug 1750121 in neutron-dynamic-routing (Ubuntu Bionic) "Dynamic routing: adding speaker to agent fails" [High,Fix committed] https://launchpad.net/bugs/1750121
<nacc> coreycb: it is marked as failed on bionic?
#ubuntu-devel 2018-05-30
<pitti> cpaelzer: thanks for trying to reproduce the qemu failure; don't worry too much though, I doubt many people will install tuned
<pitti> and if it doesn't always reproduce (on a different host), then don't waste too much time on it
<pitti> cpaelzer: initially I was concerned that it was a regression from the 7.2 qemu security update, as that sounded related; but I'm glad that it's not
<cpaelzer> pitti: I understand, thanks for letting me know
<cpaelzer> but it sounded that it is a 100% hit for you even on Debian
<cpaelzer> so I wondered what tuned might switch that breaks it
<pitti> cpaelzer: yes, it is
<pitti> cpaelzer: I can 100% reproduce it on my thinkpad x230, and it also happens on our openshift CI cluster (RHEL host)
<cpaelzer> that makes me concerned
<cpaelzer> if you happen to find what is different for you than for me please let me know
<pitti> but I suppose the iron it runs on shouldn't matter so much as long as it provides kvm, maybe more like the emulated "outer" VM guest type?
<cpaelzer> yeah, this is why I described my full stack
<pitti> not sure what libvirt defaults to
<pitti> but at least it's interesting that it doesn't happen universally
<cpaelzer> usually all default to a i440fx type of the latest qemu
<pitti> -machine pc-i440fx-2.11,accel=kvm,usb=off,dump-guest-core=off -cpu host
<pitti> indeed
<LocutusOfBorg> tjaalton, I did upload a no change rebuild instead :)
<tjaalton> LocutusOfBorg: that should do it
<LocutusOfBorg> I don't plan any vbox upload for some weeks I hope
<TJ-> Could we get mcelog back into Bionic? Bug #1752251
<ubottu> bug 1752251 in mcelog (Ubuntu) "No mcelog in bionic." [Undecided,Confirmed] https://launchpad.net/bugs/1752251
<roaksoax> f/win 8
<teward> is there a solution to fix mk-sbuild in Xenial when trying to make a cosmic chroot so that it *doesn't* choke on pkg-create-dbgsym not existing anymore?
#ubuntu-devel 2018-05-31
<cousin_luigi> Greetings.
<cousin_luigi> Is gnome-mpv an ubuntu project?
<wxl> cousin_luigi: no. it's a gnome project.
<cousin_luigi> wxl: k, thanks
<Unit193> bdrung: Hello, pyhunspell seems to be out of date by a few years.  Was there any chance you'd be able to update that?
#ubuntu-devel 2018-06-01
<Asuran> hi i got some issue with caught with wavemon on 18.04 with wifi. something seems to loop over my wlan card, even the activity diode blinks. but tcpdump didnt showed  any supisscous. i tried mobile wifi hotspot to see if its my router, but it seems its a ubuntu bug
<Asuran> problem is i cant determine what it is
<Asuran> it appered after using firefox but it went away. today it continues doing so, it doesnt go away
<Asuran> it got triggered when i was using firefox (the installed version of it)
<Asuran> in main ubuntu channel i cant get help for this
<Asuran> and if its bug you may be interested also in fixing it
<Asuran> so basicly i just want to know how i can get the problem inspected. it seems for this i would have to put card into monitor mode? but it seems it comes from ubuntu, maybe some wifi thing which is broken with the driver maybe
<Asuran> on other distros this issues wasnt there with this card and card seems to work fine
<tomreyn> the channel topic seems to state "Devel of Ubuntu (not support or app devel) [..] #ubuntu for support and discussion of Trusty-Bionic"
<Asuran> yea saw that too late
<Asuran> i guess it should be fine i dont ask for support like fix my problem, i try to figure out if there even is a problem and the main channel cant help or idk
<Asuran> if its bug its definitly devel related
<nacc> Asuran: did you file a bug?
<Asuran> nope because i dont got any data except wavemon
<Asuran> i need more imformation in troublshooting this but i cant do it alone
<Asuran> it seems some ubuntu misconfig is maybe present or the driver for rtl2800pci is broken
<Asuran> but idk since i cant get any informations due to the fact im not familiar with this kind of troubles
<Asuran> if i would open a bug with just: wavemon shows unexpected packets then i would get discussion for nothing
<Asuran> and i got already one in main chat which was helpful
<Asuran> thats why i even came this far
<Asuran> but now it seems to be too low level for me because my card doesnt support monitor mode
<nacc> Asuran: you should file a bug, and it should be triaged by someone who can help there
<Asuran> and thanks to the wavemon tip it seems something from ubuntu is sending to gateway and prodcues RX
<Asuran> can you maybe tell me if you know what i could try to find any informations like a logfile
<Asuran> i tried journalctl for networkmanager but it isnt low level enough
<rbasak> #ubuntu is the right place to ask that kind of question.
<Asuran> definitly no
<Asuran> cuz this question is too hard it seems for there
<rbasak> That doesn't make this the right place to ask that question.
 * Faux winces.
<Asuran> i already discussed with them there about this half an hour
<rbasak> You might try somewhere that doesn't rely on people being instantly online.
<rbasak> Eg. askubuntu.com
<Asuran> you are developers who contrinbute to ubuntu?
<Asuran> rbasak i dont ask you for find my issue, i asked if you could give me a tip what i should look into
<rbasak> See https://community.ubuntu.com/t/community-support/709 for where to go to get help.
<Asuran> and i did this cuz i thought devs know this stuff more then in #ubuntu
<rbasak> This channel is for development.
<rbasak> Some developers also participate in community support channels.
<Asuran> rbasak: are you a developer?
<rbasak> By asking here, you're eliminating a large number of people who may be able to help.
<rbasak> Please use #ubuntu, or any other option listed at https://community.ubuntu.com/t/community-support/709
<Asuran> nah i let this bug be then i thought switching to ubuntu but if people dont care bugs its ok to me sorry for bothering
<wxl> Asuran: you can go to terminal and file a bug `ubuntu-bug wavemon`, you know.
<Asuran> wxl: didnt knew nice
<Asuran> but i doubt its useful making such a ticket
<Asuran> cuz they will ask whats the problem
<wxl> well this discussion certainly isn't any more useful XD
<Asuran> and i dont got it cuz in main channel no one could help me further than this
<wxl> but that will collect information from your system that could help diagnose the problem
<Asuran> and if devs are no willing todo its ok for me no problem
<Asuran> before i get banned from here i better be quiet
<wxl> no bug report means nothing's going to happen on ANY OPEN SOURCE PROJECT
<rbasak> Ubuntu developers usually prioritise bugs that affect many Ubuntu users. Unfortunately we don't have time to fix every bug.
<rbasak> But it doesn't even sound like you have a valid bug reoprt.
<rbasak> You really want the wider set of Ubuntu community users who might be able to help.
<rbasak> I suggest you follow the link I pasted.
<nacc> Asuran: i think you are confusing "I didn't get help right now this exact second in #ubuntu" with "I didn't get help"
<Asuran> its okay guys let this bug be then there
<nacc> Asuran: that is *your* choice, not ours.
<Asuran> i dont want to continue this sorry for breaking the rules
#ubuntu-devel 2018-06-02
<fnatter> hi ubuntu-devel, I created an SRU:
<fnatter> https://bugs.launchpad.net/ubuntu/+source/libjsyntaxpane-java/+bug/1770809
<ubottu> Launchpad bug 1770809 in libjsyntaxpane-java (Ubuntu Bionic) "[bionic SRU] Port libjsyntaxpane-java 0.9.6~r156-7 java9 crash to bionic" [Undecided,New]
<fnatter> but did not receive any updates for almost two weeks, wanted to ask about the status
<fnatter> thanks
<fnatter> is anybody from ubuntu-sponsors listening here? Did I do sth wrong / am I in the wrong channel?
<ginggs> fnatter: please put [Impact], [Test Case] etc in the bug description, and it is still on their radar http://reqorts.qa.ubuntu.com/reports/sponsoring/
<ginggs> fnatter: ubuntu-motu is a good place to look for sponsors
#ubuntu-devel 2018-06-03
<LargePrime> hi.  looing to install a snap of vlc.  do i need to purge first?
<tomreyn> LargePrime: quoting the channel topic: "#ubuntu for support and discussion of Trusty-Bionic "
<LargePrime> tomreyn, right.  on bionic.  just want to switch to a snap, and not sure what i need to do
<LargePrime> since the ubuntu packages are always old
<tsimonq2> LargePrime: Actually, Bionic is keeping pretty consistent with the VLC point releases, and Xenial updates are planned to.
<tsimonq2> *too
<tsimonq2> I wouldn't be too quick to jump ship unless you absolutely, always, need the latest.
#ubuntu-devel 2019-05-27
<LocutusOfBorg> Unit193, did I smell debhelper backport?
<LocutusOfBorg> I think we should do it! :)
<LocutusOfBorg> care to open a bug against debhelper? happy to discuss/sponsor, we really need compat level 12 for bionic, now that Debian is widely using it
<infinity> LocutusOfBorg: I don't see how it follows that Debian using 12 in unstable means our stable release needs it.
<LocutusOfBorg> infinity, because some developers are using bionic as their base os...
<LocutusOfBorg> and you can't even create a dsc or changes without the required compat 12...
<LocutusOfBorg> so, not even able to create something to upload in a ppa or pbuilder
<LocutusOfBorg> I manually backported it in my laptop, but still, I need it for e.g. backbox ppa and somewhere else
<LocutusOfBorg> and when many people need the same thing, for different reasons... maybe an SRU is worth
<infinity> LocutusOfBorg: Wat?
<infinity> LocutusOfBorg: You don't need debehlper at all, regardless of version, to create a "dsc or changes".
<infinity> LocutusOfBorg: If you're running full no-op clean targets on source builds, those should always be done in target chroots.  If you're not, you need no debhelper.
<infinity> LocutusOfBorg: Anyhow, "I can't figure out how to develop for the devel release" is never a reason to backport the devel toolchain to stables.  (using your argument, DDs that don't Debian stable should be petitioning for debhelper 12 in stretch, and I'm assuming you don't think that's a good idea)
<juliank> LocutusOfBorg: There are a lot of options for you: (1) use a devel lxd (2) upgrade to devel (3) build source package with -nc
<juliank> Oh, infinity I think it did get harder to build without a debhelper due to Build-Depends: dh-compat (= 12)
<juliank> but I'm not sure
<juliank> no, -nc ignores b-d too
<juliank> So ignore that bit, I was stupid
<juliank> I usually build packages for releases like this
<juliank> lxc exec $release -- sudo -i -u ubuntu bash -c "cd $PWD && <gbp buildpackage/debuild> -S -uc -us"
<juliank> and then debsign on the host
<juliank> and have $HOME mounted into $release container
<juliank> Well, mostly applies to apt/xenial
<juliank> I try building on host (which runs devel), and then do debdiff of .dsc for non-devel upload to see if there are any spurious changes
<infinity> juliank: Yeah, I do all my builds -nc where I know it's safe, and if it's not safe, it's because the package does Weird Stuff in clean, in which case it should be in a target chroot anyway (so as to not skew autotools versions, etc), so...
<ahasenack> hm, question about the d/<package>.symbols file. Ubuntu backported a certain feature, which added new symbols, and added them to the symbols file
<ahasenack> at the version of the backported package: 1.5.7-2ubuntu1~
<ahasenack> later, debian adopted a new upstream version which had that feature, and updated its symbols file at that version: 1.6.2
<ahasenack> so the question is if we should keep setting it to 1.5.7-2ubuntu1~, which is when ubuntu introduced it
<ahasenack> but that means keeping a delta with debian
<ahasenack> I'm inclined to drop the delta
<ahasenack> the 1.5.7 package will still have that versioned symbol, but now we are ahead
<infinity> ahasenack: Dropping the delta is fine, just means that packages built against the new library will pick up a newer versioned dep if they use those symbols, which isn't a big deal.
<infinity> ahasenack: The versioned dep will be a bit of a lie for Ubuntu, but we also don't actually want people running eoan binaries with bionic libraries (or whatever), so eh.
<ahasenack> I will have to rebuild everyting, though
<infinity> No you won't..
<infinity> Why would you?
<ahasenack> or else the reverse-deps won't be installable? let me check what that dep looks like
<infinity> Current deps will be >= 1.5.7-2ubuntu1~, and last I checked, 1.6.2 is bigger than 1.5.7
<ahasenack> right, it's >=
<infinity> Things will organically pick up the higher dep as they're rebuilt for other reasons, but no need to force the issue.
<ahasenack> cool, thanks
#ubuntu-devel 2019-05-28
<seb128> acheronuk, hey, could you remove the libnm-util-dev Build-Depends from kdelibs4support? it was added in 5.47.0-0ubuntu1 and isn't in Debian, it's probably not needed but it's not clear to me why it was added in the first place. That lib is deprecated and NBS now in Eoan
<acheronuk> seb128: let me look
<seb128> acheronuk, thx!
<LocutusOfBorg> infinity, first, I know how to develop for devel release, but sometimes for just my packages that I source upload in Debian, and have no strange things in clean target, I do dpkg-buildpackage -S -d and dput, and meh, I'm not an Ubuntu developer in my daily job, so I have to stick with at least one LTS, because I'm not a student who can upgrade because meh new stuff. Moreover, I can figure out, and I already use chroots, but
<LocutusOfBorg> sometimes its just an overkill when you know the stuff you are working on, so I prefer to have a never debhelper on my bionic machine, e.g. if I want to compile the latest vbox in my laptop, I have to 1) lower compat requirements or 2) use a custom built debhelper version. Right now I'm following 2, and I'm not the only one who does this. if you want to provide updates to an LTS for 10 years, I think a backport is worth the
<LocutusOfBorg> effort.
<amurray> seb128: do you expect evolution-data-server currently in cosmic-proposed from LP #1813268 to migrate soon?
<ubottu> Launchpad bug 1813268 in evolution-data-server (Ubuntu Cosmic) "connection issues with Kopano IMAP servers" [Low,Fix committed] https://launchpad.net/bugs/1813268
<seb128> amurray, hey, not unless someone test/mark the bugs verification-done, at this point I expect more that it's not going to be verified and sit there or end up being delete from proposed
<seb128> amurray, which is sort why I made that point on the list a while ago about doing SRUs on non LTS/non-current-stable is a waste of efforts
<LocutusOfBorg> juliank, 1) I use already chroots, but sometimes I just need to create something quick for test or ppa, the chroot solution doesn't scale efficiently on 100% of the use cases 2) upgrade to devel is a no-go for $dailyjob 3) what if I want to also test the built deb file on my laptop?
<seb128> amurray, in practice no-one use cosmic now and we don't have people to do the verifications
<LocutusOfBorg> and using -nc is source of troubles, I don't want the risk of something in the tarball I don't want, I prefer to not use nc and chroot when clean doesn't work (or backport tools when I find them useful in my daily life)
<juliank> I mean, you are supposed to use -nc anyway, to avoid spurious changes from a broken clean target
<juliank> Maybe not for devel, but certainly for SRUs
<seb128> amurray, anyway, sorry for the sort of ranting ... did you need that update in for a specific reason? if so I guess we can find some time to do the verification and unblock you (I need to reinstall a cosmic system for that though, since I don't have one at this point)
<acheronuk> seb128: this is why: -- The following OPTIONAL packages have not been found:
<acheronuk>  * NetworkManager (required version >= 0.7.0), The NetworkManager headers, <http://projects.gnome.org/NetworkManager>
<acheronuk>    Needed for kded's networkstatus module
<acheronuk> seb128: I assume the files that were in libnm-util-dev will move to the normal -dev package?
<seb128> acheronuk, the non deprecated ones yes
<seb128> acheronuk, what .pc does it try to use?
<acheronuk> seb128: not sure. its optional though, and the Qt5/KF5 kded doesn't use kdelibs4support, so I think safe to drop
<seb128> good
<acheronuk> seb128: uploading...
<seb128> acheronuk, thanks!
<LocutusOfBorg> juliank, I usually debdiff changes files to be sure about my changes :) I prefer to do that anyway, and in case cruft is there, I create a custom chroot and run clean there :)
<LocutusOfBorg> I admit, I don't SRU that much!
<LocutusOfBorg> in any case, a custom chroot is also useful to verify the fix, so since I have to do it anyway... better use it from the begin
<juliank> I have not used chroots in ages
<LocutusOfBorg> I find them really useful!
<LocutusOfBorg> with xhost + I can easily test even graphic applications...
<LocutusOfBorg> just for curiosity, what do you use to setup an old Ubuntu version to confirm if an SRU is good or not? docker?
<cpaelzer> hi, I have a package which runs build time tests that need a $HOME to be sort of valid (existing dir)
<cpaelzer> but in the build env this is set to /sbuild-nonexistent/
<cpaelzer> is there a common best practise to that?
<cpaelzer> I currently think of mktemp + export $HOME in override_dh_auto_test
<rbasak> I think that sounds reasonable
<amurray> seb128: re e-d-s on cosmic - the version in -proposed happens to already fix CVE-2018-15587 - so if that gets out then I don't have to manually patch it
<ubottu> GNOME Evolution through 3.28.2 is prone to OpenPGP signatures being spoofed for arbitrary messages using a specially crafted email that contains a valid signature from the entity to be impersonated as an attachment. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15587)
<rbasak> cpaelzer: or something in the build tree, and then you can have an easier time writing the clean target?
<amurray> seb128: also from what I could see that is marked verification-done in the bug report
<seb128> amurray, bug #1815882 isn't verified, I will test that now
<ubottu> bug 1815882 in evolution-data-server (Ubuntu Cosmic) " Update evolution-data-server to 3.30.5" [High,Fix committed] https://launchpad.net/bugs/1815882
<amurray> seb128: I was looking at bug #1813268
<ubottu> bug 1813268 in evolution-data-server (Ubuntu Cosmic) "connection issues with Kopano IMAP servers" [Low,Fix committed] https://launchpad.net/bugs/1813268
<seb128> amurray, right, that one is verified :)
<Odd_Bloke> LocutusOfBorg: I use lxd for testing on old Ubuntu versions; a full system container means less Docker weirdness to work around.
<seb128> cyphermox, hey, on that new japanese era SRU bug, are you/someone from foundations looking at the desktopish packages on the list as well (poppler-data, gucharmap, gnome-characters)
<seb128> wasn't launchpad letting you see full comments on the web without downloading them before?
<cjwatson> Depends on the length
<seb128> well, it has always been cutting to some length with "..."
<seb128> but I though you had a "see full comment" or similar before
<seb128> which would open that comment in its own page
<cjwatson> You do
<cjwatson> Example?
<cjwatson> Nothing has changed there
<seb128> cjwatson, https://bugs.launchpad.net/ubuntu/+source/xdg-dbus-proxy/+bug/1811824/comments/3
<ubottu> Launchpad bug 1811824 in xdg-dbus-proxy (Ubuntu) "[MIR] xdg-dbus-proxy" [Undecided,New]
<seb128> or maybe firefox changed, now it pop the download dialog, I'm pretty sure I was able to open those "inline" before
<cjwatson> I think that must be a browser change
<cjwatson> That said, we're sending Content-Disposition: attachment; ...
<seb128> chromium does the same
<cjwatson> Anyway, the last change to that code was nearly a year ago and that was just to quote the filename properly in the response header; before that the last change was in 2012
<seb128> maybe my memory is wrong :)
<seb128> thx for checking/replying cjwatson!
<seb128> (well in fact the item to download the comment always existed, but I though there was also a link to view the full comment in a page... anyway, not important)
<seb128> k, it's still fine on other bugs, e.g https://bugs.launchpad.net/ubuntu/+source/usbguard/+bug/1816548/comments/10 so maybe it has to do with the size after all
<ubottu> Launchpad bug 1816548 in usbguard (Ubuntu) "[MIR] usbguard" [Undecided,Incomplete]
<cjwatson> lib/lp/bugs/browser/bugcomment.py:        """View redirects to +download if comment is too long to render."""
<seb128> cjwatson, that explains, thx again and sorry for the noise (and I learnt something new about launchpad today ;)
<cjwatson> Threshold is currently 3200 bytes if I'm reading the configs right
<cjwatson> Err characters not bytes
<seb128> that feels a bit low, but there is probably a reason for it
<cjwatson> I'm guessing performance but it was before my time
<bdmurray> connor_k: bug 1828615 doesn't need fixing for the development release right?
<ubottu> bug 1828615 in v4l2loopback (Ubuntu) "v4l2loopback 10.0-1ubuntu1 ADT test failure with linux 5.0.0-14-generic" [Medium,In progress] https://launchpad.net/bugs/1828615
<connor_k> bdmurray, no, those changes should already be there for development since they were fixed for disco
<bdmurray> connor_k: okay, I'm going to set the task to Fix Released then and a new bionic task will be added
<connor_k> bdmurray, thank you :)
<bdmurray> LocutusOfBorg: bug 1535045 is missing a test case and "regression potential" is supposed to be about how a regression could / would manifest, not what the chances of a regression are. Additionally, please add information to the bug about the status for disco and cosmic.
<ubottu> bug 1535045 in biosdevname (Ubuntu Bionic) "[SRU] Biosdevname does not provide interface naming information for ConnecX4 Devices" [Undecided,In progress] https://launchpad.net/bugs/1535045
<seb128> bdmurray, hey, could you review epiphany-browser/bionic? That's a standard GNOME bugfix update which we didn't pick for a while and got upstream angry at us, I would like to be able to get back to them with "update is in proposed ready for testing" :)
<bdmurray> seb128: sure
<seb128> bdmurray, thanks!
<ryuguns> Hey, is the Ubuntu SDK still worked on? It's just a Qt Creator plugin isn't it? And is there any benefit to using it other than working on the (AFAIK discontinued) Ubuntu Touch platform?
<sarnold> ryuguns: if you like ubuntu touch I understand there's still a community working on it https://ubports.com/
<ryuguns> sarnold: Wow, that's awesome, do they have any official relationship with Canonical?
<ryuguns> Just checked, looks like they don't, but that's still cool
<ryuguns> Thanks a lot
#ubuntu-devel 2019-05-29
<LocutusOfBorg> thanks bdmurray, updated!
<FourDollars> How to use git-build-recipe locally? Does it have some step by step guide?
<cjwatson> FourDollars: https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted at least mentions it a little bit
<FourDollars> cjwatson: In the "Testing the recipe" section, there is "bzr dailydeb --allow-fallback-to-native wikkid.recipe working-dir" for bzr, but none for git.
<cjwatson> FourDollars: "Things are similar for git, but use git-build-recipe instead of bzr dailydeb"
<cjwatson> right there in the text
<cjwatson> git-build-recipe was derived from bzr-builder and has more or less the same interface
<FourDollars> cjwatson: So "git-build-recipe --allow-fallback-to-native wikkid.recipe working-dir" should work, right?
<cjwatson> Yes, if the recipe is written for git
<FourDollars> OK. Thx a lot.
<cjwatson> np
<FourDollars> cjwatson: Could you help me to check https://code.launchpad.net/~fourdollars/+recipe/edid-decode-daily? I don't know what is wrong.
<cjwatson> FourDollars: lp:~fourdollars/edid-decode/+git/debian doesn't have a "master" branch.  Try changing "master" to "debian/master" on the second line of the recipe?
<cjwatson> FourDollars: Ah, but you will also run into https://bugs.launchpad.net/git-build-recipe/+bug/1683913.  Go to https://code.launchpad.net/~fourdollars/edid-decode/+git/debian/+edit and set a default branch for that repository (probably "debian/master")
<ubottu> Launchpad bug 1683913 in git-build-recipe "git-build-recipe assumes that HEAD exists in the source repositories" [Undecided,New]
<FourDollars> cjwatson: Yes, you are right. This issue is the root cause.
<FourDollars> cjwatson: It works now. Thank you very much.
<cjwatson> Good.  Let me see if I can do something about that bug since it's annoying
<acheronuk> jbicha: would you want to fix LP: #1830860 in debian soon, or is it ok for me to just do it for now in Ubuntu?
<ubottu> Launchpad bug 1830860 in pipewire (Ubuntu) "Building against pipewire fails with: invalid conversion from âvoid*â to âspa_pod*â" [Undecided,New] https://launchpad.net/bugs/1830860
<Laney> acheronuk: can you file a merge request on salsa?
<acheronuk> Laney: I think so. not right now, as I have to go to dentist, but sure I can in the next few days
<Laney> thanks, if you ping me I'll review it
<Laney> bonus points if you can point to a build failure that happens in Debian
<acheronuk> ok. thanks
<ddstreet> rbalint what's the plan for systemd in eoan-proposed?  i have an upload of systemd for eoan
<ddstreet> ah, it's late there :-/
<Odd_Bloke> ddstreet: I think rbalint is also on vacation this week (though I'm not on his team, so I may have got the wrong end of the stick).
<ddstreet> ah, well that's unfortunate...
<ddstreet> rbasak not actually sru related, but you're the sru vanguard on the schedule so i'll ping you first; as rbalint is out this week (it appears) and his systemd upload to eoan has been in -proposed for 11 days and caused a regression, can i have someone sponsor my eoan systemd upload without rbalint's patch?  i'd prefer not to wait until next week when he gets back, and the regession appears serious enough (kbd stops working)
<ddstreet> for reference, lp #1803993 and github regression bug is https://github.com/systemd/systemd/issues/12616
<ubottu> Launchpad bug 1803993 in systemd (Ubuntu) "Password appears on the VT1 screen" [High,In progress] https://launchpad.net/bugs/1803993
<ddstreet> xnox sil2100 do either of you have an opinion ^
 * rbasak looks
<rbasak> ddstreet: are you confident that it is his upload that caused the regression?
<ddstreet> rbasak upstream systemd appears to think so, and rbalint asked for his c/d uploads to be rejected because of it
<rbasak> ddstreet: based on http://autopkgtest.ubuntu.com/packages/s/systemd/eoan/amd64 it looks like 240-6ubuntu5 is generally failing too?
<ddstreet> rbasak systemd on amd64/i386 has been failing like that intermittently for a couple weeks now
<ddstreet> someone with access to the scalingstack instances needs to see why autopkgtest-virt-ssh can't ssh into the instance after a reboot
<rbasak> Ah OK, so that's separate?
<ddstreet> yes
<ddstreet> rbasak re: failing systemd autopkgtest.u.c on amd64/i386, upstream has been a bit upset about it also, lp #1829829
<ubottu> Launchpad bug 1829829 in systemd (Ubuntu) "Ubuntu CI has been flaky for a week" [Undecided,New] https://launchpad.net/bugs/1829829
<rbasak> ddstreet: do you think rbalint would agree it's a regression in Eoan caused by that upload?
<ddstreet> rbasak lemme find the freenode logs where he asked for his other uploads to be rejected, one minute
<ddstreet> rbasak https://irclogs.ubuntu.com/2019/05/21/%23ubuntu-devel.txt
<ddstreet> [12:01] <rbalint> xnox, seb128: the regression still seems to be better than leaking passwords and breaking keyboard on gdm after a few logouts, but i'm also open to reverting it until everything is sorted out
<ddstreet> [12:03] <rbalint> xnox, with or without the revert i think it would be be beneficial to have ddstreet's autopkgtest fixes in eoan and in old releases even going in ahead of the VT fix
<ddstreet> i'm ok either way, really, in eoan - i'd just like for it to get out of -proposed so i can ask someone to upload my systemd to eoan
<rbasak> ddstreet: it sounds OK to me then. What I suggest you do is prepare an upload for sponsorship which explicitly reversts (with a changelog message) and then adds your changes.
<ddstreet> rbasak will do, thnx
<Odd_Bloke> xnox: Can you remind me where that reboot time script of yours is?
<xnox> Odd_Bloke:  git clone lp:finalrd ?
<Odd_Bloke> Aha, yep, that's it; thanks!
<ddstreet> rbasak can you sponsor systemd to eoan for me for lp #1825378
<ubottu> Launchpad bug 1825378 in systemd (Ubuntu Eoan) "systemd-networkd doesn't set wireguard peer endpoint" [Medium,In progress] https://launchpad.net/bugs/1825378
<ddstreet> bdmurray are you able to access the autopkgtest.u.c systems?  i would love to know why systemd tests for amd64/i386 keep failing because the testbed isn't reachable by ssh after a reboot... been going on for a couple weeks now, including for upstream system tests.  lp #1829829
<ubottu> Launchpad bug 1829829 in systemd (Ubuntu) "Ubuntu CI has been flaky for a week" [Undecided,New] https://launchpad.net/bugs/1829829
<ddstreet> i don't know which people actually have access to the scalingstack infrastructure to see what's wrong with it
<vorlon> ddstreet: that's primarily Laney, juliank, myself running it
<ddstreet> vorlon do you know what release the host systems are?  trusty or xenial maybe?
<ddstreet> compute nodes, i mean
<juliank> Woohoo somebody mentioned my name
<vorlon> ddstreet: I don't, we just consume compute as users of the cloud
<ddstreet> ah ok
<Laney> xnox has been pinged about 100 times about that
<vorlon> but these are the lcy01 and lgw01 scalingstack regions
<Laney> waiting for some kind of initial analysis from that end
<ddstreet> Laney from xnox's end you mean?
<Laney> yes
<vorlon> ddstreet: why are you asking rbasak for systemd sponsorship, instead of going through xnox (Foundations maintains the package)?
<ddstreet> i discussed it with rbasak earlier, and included xnox in the irc pings
<ddstreet> xnox if you want to sponsor plz feel free to
<ddstreet> i assume he's gone
<ddstreet> vorlon do you mean that nobody except xnox should upload systemd to eoan?
<vorlon> xnox and rbasak are in the same tz
<ddstreet> ok, xnox, ping, you around?
<vorlon> ddstreet: it's a heavy and complicated package and no one should be uploading it without /coordinating/ with foundations since there is often work in flight
<ddstreet> vorlon sorry, so do you mean for systemd srus, i should not upload those myself, i should get xnox to upload systemd srus?
<ddstreet> or do you just mean for the devel release
<vorlon> ddstreet: I more mean for devel release
<vorlon> and again, this is not about who uploads
<vorlon> it's about coordinating to make sure no one's stepping on toes wrt other in-progress work
<ddstreet> im pretty sure xnox is aware of my work here, it involves a few bugs he's opened, and i've pinged him in irc now enough times even today to be annoying ;-)
<ddstreet> anywho
<rbasak> ddstreet: ah, just seen this. I'm not confident enough to upload systemd without a +1 from a core dev on the foundations team, sorry!
<xnox> ddstreet:  yes.
<xnox> i am around
<ddstreet> xnox hi, can you sponsor lp #1825378 for me, bugfix as well as quite a few test fixes
<ubottu> Launchpad bug 1825378 in systemd (Ubuntu Eoan) "systemd-networkd doesn't set wireguard peer endpoint" [Medium,In progress] https://launchpad.net/bugs/1825378
<ddstreet> once that's in i have even more to sru back
<ddstreet> let me know if there's anything that annoys you.  thanks.
<Laney> ddstreet: tkamppeter had a patch to SRU for systemd, if you're planning to upload soon could you maybe coordinate and grab that one too pleeeease?
<xnox> reviewing
<ddstreet> Laney that was for x/b only right?  the network-manager dns bug?
<Laney> I think so but you best check with Till
<ddstreet> IIRC that bug had reports of still not being fixed on the n-m side...i'll go find it and look at the systemd part tho
<Laney> yeah, but the systemd bits will be needed when NM is re-fixed
<seb128> rbasak, hey, unsure if you are over your SRU team shift hours but it would be nice if you could look at software-properties in bionic-proposed and migrate it to updates? It doesn't have a full week staging but the changes are safe error handling ones to fix regressions from the SRU that recently migrates to -updates
<rbasak> seb128: looing
<rbasak> *looking
<rbasak> seb128: does that mean that some of these bugs should be tagged regression-update? Which ones?
<vorlon> seb128: network-manager 1.18.0-1ubuntu2 dropping gir1.2-networkmanager-1.0 now breaks debian/tests/nm.py which depends on it (the autopkgtests only passed because the NBS binary package in the eoan release pocket was still installable; now it's been removed)
<vorlon> seb128: how should this be fixed? the test does use exports from gi.repository.NetworkManager, I don't know what those should be replaced with
<cyphermox> gir1.2-nm-1.0
<cyphermox> (I'll be pushing the button in a second...)
<vorlon> cyphermox: ok
<cyphermox> hrm, actually, scratch that
<cyphermox> it's more complicated than I thought, I'm starting to think gir1.2-networkmanager-1.0 shouldn't have been dropped
<seb128> vorlon, cyphermox, ups..., the NBS report was not enough to flag that :/
<vorlon> indeed
<vorlon> nor should this have been a blocker for deleting the NBS package
<seb128> rbasak, yes, bug #1830348 and bug #1830353
<ubottu> bug 1830348 in software-properties (Ubuntu Bionic) "/usr/bin/software-properties-gtk:TypeError:msg_reply_handler:_enabled_reply_handler:__call__:call_async" [Undecided,Fix committed] https://launchpad.net/bugs/1830348
<ubottu> bug 1830353 in software-properties (Ubuntu Bionic) "/usr/bin/software-properties-gtk:AttributeError:_update_availability:<lambda>:get_status:_get_raw_snap" [Undecided,Fix committed] https://launchpad.net/bugs/1830353
<seb128> rbasak, I tagged them now, if that helps
<seb128> vorlon, cyphermox, tomorrow is an holidays here but I've a look on friday if no-one beats me to it
<cyphermox> seb128: vorlon: the autopkgtests needed porting, really
<cyphermox> it's not even new changes, it's been years :/
<seb128> n-m has been basically unmaintained in Ubutu for ages, which we keep raising as an issue but hasn't really be resolved yet
<seb128> cyphermox, vorlon, I expect porting those tests is going to take a while since we don't have anyone knowing about those bindings atm, unsure what to do meanwhile
<vorlon> seb128: restore the deprecated binary packages?
<vorlon> so we don't have to drop test coverage in the near term
<seb128> I guess :/
<cyphermox> give me a day?
<seb128> cyphermox, if you want/could have a look that would be great
#ubuntu-devel 2019-05-30
<xnox> Wimpress:  may I upload refreshed ubuntu-mate-meta? note that it needs update.cfg adjustment to look at -proposed packages too when germinating https://paste.ubuntu.com/p/JBQ3rYDMrX/
<Wimpress> xnox: Yeah, I spotted that the ubiquity panel hadn't migrated from proposed.
<xnox> and it will not, until we fix metas =) chicken-egg =)
<Wimpress> Ah, OK.
<xnox> plus it's nice to have all the pockets in update.cfg anyway, for SRUing new deps / updates.
<Wimpress> So -proposed should be remove from update.cfg once everything has migrated?
<Wimpress> Or safe to leave?
<Wimpress> Thanks for sorting that, I'll let the Ubuntu Budgie guys know what to do.
<xnox> safe to leave
<xnox> ie. ubuntu-meta has it always
<Wimpress> Thanks.
<xnox> uploaded
<Wimpress> Wonderful. I'll get the QA guys to test the next daily.
<xnox> Wimpress:  well not gonna migrate yet.
<Wimpress> OK
<xnox> Wimpress:  for budgie the question is, if they want to show a panel at all during 'maybe-ubiquity' and 'only-ubiquity' modes. cause it looks like they seed indicators just for that.
<xnox> the principal need for panel there, historically was to mimick unity7 UI and to provide add-hoc ability to change keyboard layout at any page of the installer.
<Wimpress> Yes, Budgie is different in that regard. The indicators are for Ubiquity only.
<Wimpress> bashfulrobot: See the discussion above. Can you ask David to join this channel so he can answer xnox questions.
<xnox> in essence we are splitting the panel out of ubiquity-frontend-gtk into a separate universe package, and if panel is desired it should be seeded. Or if panel is not part of the desired installer look & feel, one can drop it.
<tmhoang> Hello, for Arch, Debian, Fedora, I can find their build "scripts" and patches at : https://src.fedoraproject.org/rpms/gcc, https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gcc, https://salsa.debian.org/toolchain-team/gcc/tree/master/debian/rules.d. Where could I find the same for Ubuntu ? Is it at : https://code.launchpad.net/gcc ? (I pick gcc as an example).
<tmhoang> many thanks
<Laney> dear hive mind: would it be acceptable for autopkgtest to write ${RELEASE}-security entries here using the configured mirror? https://salsa.debian.org/ci-team/autopkgtest/blob/master/setup-commands/setup-testbed#L141
<Laney> I feel a bit uncomfortable about forcefully inserting security.u.c there
<Laney> but I can't remember what the situation is with mirrors carrying -security
<sladen> cking: have sent a ubuntu-devel@ reply re: the compression
<cking> sladen, ok, i'll try and get that done sometime in the next week or so
<sladen> cking: it's more than my hunch is that there's likely to be a better solution that adding-more-code
<xnox> tmhoang:  that url for gcc is for the "upstream" rather than ubuntu packaging. You probably want something like this: https://code.launchpad.net/ubuntu/+source/gcc-8
<tmhoang> xnox: thanks ! Are 'Ubuntu packaging' packages start at prefix https://code.launchpad.net/ubuntu/ ?
<xnox> tmhoang:  most but not all.
<xnox> tmhoang:  some projects where ubuntu is upstream are at top-level, or even at github. or both!
<tmhoang> ah interesting
<xnox> tmhoang:  e.g. launchpad.net/ubiquity
<tmhoang> good point. many thanks
<xnox> github.com/CanonicalLtd/subiquity
<xnox> etc.
<xnox> sladen:  hmmm.... are you implying that the order of cpio members matters? =)))) as in, initrd will boot faster if busybox is first, init second, and the rest of things are in the exec order?
<sladen> xnox: think one needs data ... but if the CPIO can be ordered, and files made available as soon as they are ready (rather than waiting for $everything to be decompressed), there would be the potential for a win there too---but *only* if the code is setup for returns files/object when they are ready
<sladen> xnox: the stream decoders do not parallise well;  bzip2 is a block decoder: so when can decode multiple blocks in parallel on separate CPUs
<sladen> xnow: so there is probably a local maxima for Bzip2 using eg 100kB blocks and 30 CPUs in parallel
<xnox> i wonder if i can experiment with like shuffling init to be the last cpio archive member and like for it to be the very first one.
<xnox> to see if there is a significant difference.
<xnox> cause it would be behind all the kernel modules, and firmware blobs
<sladen> xnox: there are two potential wins: (1) re-ordering similiar file content to be <32kB distant gives compression benefits;  (2) if the code was adjusted to 'stream'/return partial results; then it would unblock lots of downstream processes
<xnox> vorlon:  Laney: is new systemd killing virtual machines, or is lcy cloud not nice? i see kernel traceback unable to mount rootfs on reboot.... but then it does show login prompt.... https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/s/systemd/20190530_115729_6065d@/log.gz
<xnox> ditto i386 https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/i386/s/systemd/20190529_215838_00b24@/log.gz
<Laney> xnox: i dunno, looks like the restart doesn't go very well though
<Laney> there's still recent passes on other releases, e.g.: http://autopkgtest.ubuntu.com/packages/systemd/bionic/amd64 http://autopkgtest.ubuntu.com/packages/systemd/bionic/i386 http://autopkgtest.ubuntu.com/packages/systemd/cosmic/i386
<Laney> does it happen on your system with qemu? if not, you should still have access to the cloud to run things there
<tmhoang> I'm building a package using CMake. Does debian/rules has an option to build with debug info or I have to add something like -DCMAKE_BUILD_TYPE=RelWithDebInfo in debian/rules ?
<xnox> tmhoang:  normally, debug symbols are built and stripped into .ddeb
<tmhoang> I'm running : dpkg-buildpackage -j4 -uc -us and see that CXXFLAGS=-g -O2 by default. I wonder where that debugging option is set
<xnox> tmhoang:  you can keep the debug symbols intact, it's normally done with DEB_BUILD_OPTIONS=nostrip debuild
<xnox> to keep all debug stuff attached
<tmhoang> xnox: I think I would stick with 2nd option instead of .ddeb. I have not used them before :(
<xnox> tmhoang:  we strip debug symbols into .ddebs such that anyone can install all debug symbols for all the packages
<tmhoang> understood
<xnox> https://wiki.ubuntu.com/Debug%20Symbol%20Packages
<xnox> for more details
<tmhoang> so, I guess something like : DEB_BUILD_OPTIONS += nostrip should work
<xnox> tmhoang:  in debian/rules ?! no, not allowed to do that
<xnox> DEB_BUILD_OPTIONS is explicitely build-environment controlled.
<xnox> it's for end-users to rebuild things
<xnox> tmhoang:  instead one would override dh_strip to not strip them
<xnox> but that's non-standards compliant / non-suitable for ubuntu/debian
<xnox> i.e.
<xnox> override_dh_strip:
 * xnox just that ^ will be enough to short circuit dh_strip
<tmhoang> ah I saw it now. Many thanks. Also this is for dev so I'd ignore standards :D
<ddstreet> xnox your boot-smoke addition of --wait should remove the while loop, and also will make the test hang forever (until adt timeout) if is-system-running never becomes true
<ddstreet> xnox Laney re: unable to mount root, it's also booted with panic=-1 so something seems to be booting the kernel without the initrd with the intention for it to panic and reboot, at least that's my best guess, i don't know why else it would be booting with panic=-1
<xnox> vorlon:  ^
<vorlon> "something seems to be booting" - yes, all the cloud images disco and later have this
<vorlon> and as we expect the cloud images to be using linux-generic which is not guaranteed to boot initramfsless in KVM, the normal boot path includes 2 reboots
<ddstreet> makes sense, assuming the first initramfsless boot works some of the time, i suppose.  note that upstream systemd (or at least whoever opened the bug from upstream) doesn't appear aware of that, you might want to mention in lp #1829829 that the first panic=-1 boot is expected and ok
<ubottu> Launchpad bug 1829829 in systemd (Ubuntu) "Ubuntu CI has been flaky for a week" [High,Confirmed] https://launchpad.net/bugs/1829829
<xnox> ddstreet:  no, not expected and not ok
<xnox> ddstreet:  expectation for cloud images is to successfully boot initrdless
<xnox> vorlon:  well
<xnox> vorlon:  we build a custom image for autopkgtest..... and we do expect it to boot.....
<xnox> vorlon:  so clearly our autopkgtest image building is wrong?!
<vorlon> xnox: we expect it to /boot/.  but we also expect it to boot the kernel twice before it gets to userspace, based on the fact that it will fail to boot initramfsless
<vorlon> unless I'm forgetting something
<xnox> vorlon:  well, but over nova api that trips the state up of autopkgtest, no? cause "yeap booted", "oh no, no network", "meanwhile it booted the second time fine"
<vorlon> xnox: AFAIK autopkgtest doesn't depend on nova api to determine whether a system is booted
<vorlon> we might issue a reboot command via nova, but then it's polling for the system to come up
<vorlon> and a double-reboot should have no impact on networking
<xnox> hmmm
<xnox> vorlon:  i don't understand the point of a cloud image that always boots twice.
<xnox> and always will......
<vorlon> xnox: we will have KVM-specific cloud images that use linux-kvm and don't boot twice.  I'm unsure if we would want that in the autopkgtest instances though
<vorlon> xnox: and "always boots twice" is certainly not a feature
<vorlon> but having initramfs+fallback by default is
<xnox> right
<xnox> how do i opt out of that?
<vorlon> xnox: something something grub.d
<xnox> cause we  customize cloud image for autopkgtests, i thought
<xnox> let me check the somethings
<vorlon> :)
<xnox> GRUB_FORCE_PARTUUID=
<xnox> i think
<xnox> vorlon:  tyring initrdless boot should a properly of a kernel.
<xnox> vorlon:  it makes sense for flavours, it doesn't make sence for generic
<xnox> and i do understand that we have more flavour type of kernel.
<Eickmeyer>  We (the Ubuntu Studio team) now have two packages that need sponsoring.  (bug 1829562 and bug 1831154)
<ubottu> bug 1829562 in Ubuntu Studio "[Needs Packaging] DPF-Plugins for Eoan" [Medium,In progress] https://launchpad.net/bugs/1829562
<ubottu> bug 1831154 in Ubuntu Studio Menu Add "[needs-packaging] ubuntustudio-menu-add" [Medium,In progress] https://launchpad.net/bugs/1831154
<Eickmeyer> Somebody PLEASE take a look at these.
#ubuntu-devel 2019-05-31
<ogra> xnox, yo ... i'm currently looking at the panic() function of the initrd ... on Ubuntu Core we set panic=-1 on the cmdline ... which the kernel typically hadles fine ... now we have an issue with a customer where the initrd drops you into a console with the panic= value set ... according to the code it should sleep for $panic seconds and then reboot instead of dropping to a shell ... https://paste.ubuntu.com/p/mswD8Cd869/
<ogra> now ... that "sleep -1" (resulting from the "panic=-1" on the cmdline) seems to cause us to still end up in a shell, seemingly the error from the sleep command makes us jump ahead to the /bin/sh at the bottom of that function
<ogra> (i assume initrd scripts dont use set -e ?)
<ddstreet> ogra that initrd script certainly doesn't match the kernel's panic usage
<ogra> ddstreet, that might be ... it is what we have by default in the 16.04 initramfs-tools though (i'm working on Core16 which uses exactly the above code)
<ddstreet> ah
<ddstreet> ogra unrelated to that but re: panic=-1, i hope you are restoring /proc/sys/kernel/panic to 0 (or whatever the user's configured) after booting?  not leaving the system with panic=-1?
<ogra> i need to avoid dropping to the shell (which i can surely by simply setting panic=1 (that should only delay the kernel panic a bit when not in initrd) ... but in general it looks like a bug in initramfs tools
<ogra> ddstreet, it is a constant default ... Core is mainly used in non-user setups ... headless remote managed devices etc ... so the panic value should cause an immediate reboot
<ogra> (Corer has a builtin rollback mechnaism and the reboot will cause you to go back automatically to the last known good kernel)
<xnox> ogra:  it would be interesting to see the full boot log with: set -x
<xnox> ogra:  to see exactly what has happened.
<ogra> the -1 is fine in all cases except the initrd panic
<xnox> ogra:  maybe none of panic() is called at all?
<xnox> ogra:  also, do you need sleep here?
<ogra> xnox, well, it properly prints the "dropping to a shell yadda yadda" stuff and all ...
<ogra> i dont need the sleep at all
<ogra> what i need is no shell when the fs is corrupt on a device that has secureboot enabled
<xnox> ogra:  you did see "Rebooting automatically due to panic=" right ?
<ogra> nope
<xnox> ogra:  also it is odd to have a variable named same as a function =)
<ogra> it just drops into the initrd shell
<xnox> ogra:  so ${panic} is not set?
<ogra> (i dont have the exact logs from the customer)
<ogra> panic is set to -1
<ogra> $ LC_ALL=C sleep "-1"
<ogra> sleep: invalid option -- '1'
<ogra> Try 'sleep --help' for more information.
<ogra> sleep thinks it is an option due to the minus
<xnox> sleep -- -1
<xnox> sleep: invalid time interval â-1â
<xnox>   
<xnox> but still kind of useless
<ogra> yes
<ogra> well, before i start hacking up my own panic() function for this customer project i thought we should also fix it upstream ;)
<xnox> ogra:  so obviously just this snippet of code is not enough, without reproducer or full logs
<xnox> ogra:  so do you have reproducer or full logs?
<ogra> well, obviously that code snippet cant handle negative values and this should be fixed
<ogra> regardless of logs/reproducer
<xnox> ogra:  but also not critical for the customer, right?
<ogra> well, given they sell secureboot protected devices, they dont really want people to gain root access to these systems just because of an FS corruption on potentially unrelated plugged in USB drives or whatever
<ogra> so it is kind of critical :)
<ogra> (i guess i'll get along with panic=1 for that particular case .... but i also think we need a fix in the existing upstream code ... this is why i pinged)
<ogra> i assume the original sleep code there is in place so that you can actually see the console message before it reboots
<xnox> ogra:  secureboot does not imply locked down device.
<xnox> ogra:  i'm not sure what is the intention of -1
<ogra> well ... its an expectation that you cant easily gain root access though
<ogra> xnox, https://github.com/torvalds/linux/blob/v4.17/Documentation/admin-guide/kernel-parameters.txt#L2931
<ogra> (as i just said in the interhnal channel, that initrd functio doesnt take panic=0 into account either)
<ogra> *internal
<xnox> ogra:  right, so the code should handle that too.... ie what you mentioned earlier i.e. on zero call `sleep infinity` and on negative numbers, skip calling sleep
<ogra> right
<ogra> i think the original implementation of that function simply pre-dates that kernel feature ...
<ogra> xnox, oh my ... digging deeper i see that /usr/share/initramfs-tools/init actually filters out negative values completely for panic= ... (unless my regex understanding is wrong)
<ogra> xnox, https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831252
<ubottu> Launchpad bug 1831252 in initramfs-tools (Ubuntu) "panic=-1 is completely ignored by the initrd causing unexpected behaviour" [Undecided,New]
<xnox> ogra:  hehe. I did say "are you sure panic is even set?!"
<ogra> yeah, now i'm sure it is not because of this :)
<ddstreet> vorlon xnox fyi, not sure if you noticed yet but it's not only systemd failing during test reboots, dbus test just failed as well: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/d/dbus/20190531_164159_d3a1e@/log.gz
<bdmurray> sarnold: Have you had a chance to test bug 1820676? Maybe you could test it with a new laptop install. ;-)
<ubottu> bug 1820676 in ubiquity (Ubuntu) "Something has gone seriously wrong: import_mok_state0 failed" [Undecided,Incomplete] https://launchpad.net/bugs/1820676
<connor_k> lol
<sarnold> bdmurray: it's funny you mention that, I just a few moments ago saw https://www.zdnet.com/article/dell-releases-more-high-end-ubuntu-linux-laptops/
<sarnold> bdmurray: I tried a new image on the machine that was wedged and it *did* boot past that point -- I however forgot to test what happens if you hit the cancel button in the installer
<bdmurray> sarnold: dpm
<bdmurray> sarnold: don't you have a new laptop lying around somewhere...
<sarnold> bdmurray: yes
<bdmurray> sarnold: here's one more reason to play with it!
<sarnold> yes :)
<connor_k> sarnold, most expensive paperweight ever
<sarnold> connor_k: you should meet my server..
#ubuntu-devel 2019-06-02
<fossfreedom> xnox, wim press asked me to ping you with regards to ubiquity-frontend-gtk-panel split - I've made the change to our seeds.  I've also tweaked our Budgie meta package to have the eoan config and uploaded into eoan proposed.
<sea-gull_>   
#ubuntu-devel 2020-05-25
<vorlon> RikMills, xnox: ugh, nasty; I didn't check the file size.  any idea why the 'make font' command succeeded and output garbage?
<lathiat> seems there is no amd64 (only arm64) for focal daily-live current.. http://cdimage.ubuntu.com/focal/daily-live/current/
<jibel> lathiat, it is not promoted automatically due to bug 1877575
<ubottu> bug 1877575 in linux (Ubuntu) "kernel crash with 0010:ovl_open_realfile+0x4a/0x150 [overlay] in Qemu with focal daily" [Critical,Confirmed] https://launchpad.net/bugs/1877575
<lathiat> ack thx jibel, i guess it would be ideal to not have the directory created as current if one of the builds fail.
<lathiat> or well dont promote, you get my meaning
<paride> jibel, are you still seeing that bug? I am not in the server images
<jibel> paride, desktop are still failing. I'm doing a manual review at the moment.
<AsciiWolf> kenvandine, hi, I have prepared a merge request to snap-store-stable, it just backports the Snap Store name fix for cs.po that is already fixed in other branches, feel free to review and merge it: https://gitlab.gnome.org/Community/Ubuntu/gnome-software/-/merge_requests/22 :)
<RikMills> oSoMoN: waht is the status of the firefox unity/global menu patch now? I see forum reports it is gone or if not gone does not work?
<oSoMoN> RikMills, it's gone in 20.04 and subsequent releases
<oSoMoN> and it's supposed to work up until 19.10, if it doesn't please file a bug
<RikMills> oSoMoN: Then I suspect people saying not working in < 20.04 probably are using something other than the archive build. sadly people are not always clear
<RikMills> thanks :)
<jibel> lathiat, desktop smoke tests are back to normal and next build should be promoted automatically. There were some leftover from the removal of python2
<jibel> paride, ^ also I'll close the kernel bug.
<paride> jibel, good news! so the kernel crash was actually gone already?
<jibel> yes
<siretart> hi folks. it's been a while...
<mwhudson> rbalint, doko: any hints as to where the perl transition is?
<doko> mwhudson: no
<RikMills> vorlon: **shrug** on why that font was 11 generated as junk 11 bytes, but FYI xnox's upload to fix that FTBFS
<RikMills> *was generated
<mwhudson>     got: 495+0: a-7:a-7:a-8:i-2:p-7:r-456:s-8
<mwhudson> ugh
<xnox> RikMills: vorlon: I think I uploaded something bogus that I was working on intermittently on.
<RikMills> xnox: that makes sense with the LP diff :P
#ubuntu-devel 2020-05-26
<cpaelzer> hi, question around the context of auto-sync. If we have a package as a sync but need a rebuild - yet want to keep it being a sync we could make the current "29.0-1" a no change rebuild like "29.0-1build1"
<cpaelzer> that would do the trick, but what happens if Debian (unlikely but possible) decides to do "29.0-1build1" themselve or soemthing in between the two versions ?
<cpaelzer> I wonder if there is a better version avoiding this problem yet keeping it as a auto-sync package
<wgrant> cpaelzer: That's the right way to do it. A version like that isn't compliant with Debian's archive policies (they have binNMUs which usually use a suffix of "+b1"), so I don't think a collision has ever occurred.
<cpaelzer> thanks
<cjwatson> And any other scheme you might invent would have exactly the same kind of possible collision problem anyway.l
<cjwatson> So might as well stick with the known one.
<xnox> vorlon:  hm, about mountfail hooks vs local-block. When ben hutchings and I, introduced local-block it was meant to replace all the mountfail hooks. Because we realized that a single pass of failure hooks is insufficient.
<xnox> and if any one of the failure hooks "progresses things" (i.e. mounts something degraded) then all the hooks need to be rerun to retrigger udev events, and retry mounting stuff.
<xnox> at the moment, at least in lvm2, I see that we have "udev triggered mounting", "broken mountfail hook", "local-block lvm2" hooks. Which seems redundant, and not working correctly.
<xnox> I do like "local-block" as it does things similar to how e.g. systemd-shutdown works - iterrate all the things, if anything makes progress
<xnox> vorlon:  i also don't quite understand how wait-for-root works, given that it doesn't allow for cryptsetup to kick in and ask for passphrase after raid was assembled, but before lvm2 is scanned.
<xnox> which local-block loop does correctly.
<xnox> thus the comment that "local-block" should never be reached in the initramfs-tools cannot be true.
<xnox> vorlon:  i.e. I think we should stop using failure-hooks, and use local-block instead.
<guidocalvano> hey, I've been playing around with the ui shell and want to try and make workspaces savable to better fit my workflow
<guidocalvano> in order to do this I would like to store which files I have open with say a code editor or some graphical application
<guidocalvano> i.e. save workspace goes through the list of applications on the workspace, then creates files, that then allow to reopen all the applications including the files/urls they had open
<guidocalvano> and load workspace creates a new workspace, and starts the applications with the files urls they had open when saved
<guidocalvano> I was thinking of using criu for this
<guidocalvano> but when I have a browser open or a text editor it can remember its own open files as well
<guidocalvano> so I was wondering how it does this
<guidocalvano> where does it store what files it has open?
<guidocalvano> and can I somehow create separate contexts the same application?
<cpaelzer> paride: from your +1 duty is anyone on libfile-desktopentry-perl ?
<cpaelzer> that shows up in component mismatches like a tree (many subdependencies)
<paride> cpaelzer, not afaik. I am currently trying to sort out the regression preventing mysql-8.0 from migrating
<paride> cpaelzer, as you mention a tree, is there anything better than https://people.canonical.com/~ubuntu-archive/component-mismatches.txt to look at component mismatches?
 * paride saw the SVGs
<sarnold> xnox: am just frustrated that my old habits of eg dpkg -S `which foo` are useless now :(
<sarnold> xnox: doubly so since I never understood what problem is being solved by adding symlinks
<gpiccoli> vorlon, xnox - can I ask your opinion on LP #1879980 ?
<ubottu> Launchpad bug 1879980 in mdadm (Ubuntu) "Fail to boot with LUKS on top of RAID1 if the array is broken/degraded" [Medium,Confirmed] https://launchpad.net/bugs/1879980
<gpiccoli> I found various duplicate issues from the last 8 years or so about the same problem..it's a long-term issue
<gpiccoli> I have an user that tested my proposed solution on Bionic with success
<xnox> sarnold:  i wonder if we can fix -S to try both ways
<sarnold> xnox: ooh ooh apt-file too please :)
<xnox> sarnold:  what is apt-file?
<sarnold> xnox: it's a simple wrapper around the contents files from the archives, eg you can find all packages that ship an apparmor profile via apt-file search /etc/apparmor.d  https://paste.ubuntu.com/p/D5pcTCMzjk/
<xnox> sarnold:  ack
<Eickmeyer> xnox: Were you ever able to find that gfxboot code for Ubuntu Studio?
<xnox> nope, the thing i thought it was, was not it
<xnox> vorlon:  what shall we do about gfxboot-theme-ubuntu? remove our attempts and publish back the binary that was there?
<RikMills> Eickmeyer: the .pcx and .pngs in this? https://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/files/head:/data/groovy
<RikMills> xnox: I assume that is what is used in production/iso builds? ^
<Eickmeyer> RikMills: Yeah, that's the one. *cringes at the oldness*
<Eickmeyer> 12 years old, goes back to first release of Studio (gutsy).
<RikMills> "This branch is an import of the Bazaar branch at https://people.canonical.com/~cjwatson/bzr/debian-cd/ubuntu"
<RikMills> o_O
<Eickmeyer> Woooow.
<RikMills> but looks like you can propose merges against the LP one all the same. odd
<Eickmeyer> Yeah. I'll probably just do that.
<RikMills> cjwatson: is that the correct route to get changes into the ISO build there?
<RikMills> Eickmeyer: wow. your logo is retro!
<Eickmeyer> RikMills: That's what I've been saying! lol
<Eickmeyer> RikMills: I showed my son and he said, "Ok, that is SO bad!" LOL!
<vorlon> xnox: so you're saying gfxboot-theme-ubuntu is still broken, even with your non-empty font?
<xnox> vorlon:  yeap
<vorlon> xnox: reference?
<xnox> vorlon:  i booted pending ubuntu-live-server iso in bios mode, hit ESC, and the gfxboot menu had no readable labels on any buttons (as per screenshots from the bug report)
<xnox> RikMills:  Eickmeyer: oooooh that could be it.
<xnox> RikMills:  Eickmeyer: no idea how that is copied in, or when. But yeah, you can make merge proposals.
<vorlon> xnox: which bug report?  I didn't see a bug link in scrollback
<Eickmeyer> xnox: MP is done, awaiting merge.
<xnox> vorlon:  https://bugs.launchpad.net/ubuntu/+source/lubuntu-artwork/+bug/1880394 https://photos.google.com/share/AF1QipOalqGwK-nonwRFp9T3VwQ2V1Yji3SpVAENeMjixTWb-CTCbo6gQ8jqeesaAOQoiA?key=eDMzTF9RTXpXY21CSkFpZmVFZEpsd1NMX3dXM2dB
<ubottu> Launchpad bug 1880394 in syslinux (Ubuntu) "20.10 iso syslinux menu screen unreadable" [Undecided,Confirmed]
<xnox> vorlon:  i see the same, but with ubuntu logo
<cjwatson> RikMills: err, tbh it's been five years and I've basically forgotten.  IIRC the release team follows https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup
<cjwatson> I think it's committed on nusakan and then there's a mirror that goes via my home directory.  It should really be turned into proper LP-hosted branches
<cjwatson> But all this stuff is super-old, it predates bzr even existing never mind LP code hosting
<cjwatson> I would very much support a current cdimage person sorting it out
<xnox> RikMills:  Eickmeyer: do make a launchpad merge proposal against lp:~ubuntu-cdimage/debain-cd/ubuntu on launchpad and it will be sorted
<sarnold> hello :) how does this directory have only .deb packages and no tarballs, no dsc files, etc? http://archive.ubuntu.com/ubuntu/pool/universe/u/uucp/
<tumbleweed> the source is in main
<sarnold> ahhh
<sarnold> http://archive.ubuntu.com/ubuntu/pool/main/u/uucp/
<sarnold> I was just getting to that. funny. I never expected uucp to have main sources so I didn't look there until after asking on irc..
<tumbleweed> it's there for "cu"
<sarnold> tumbleweed: cool, thanks
<mwhudson> bryce: are php-horde packages reappearing in groovy something we want or an accident?
<bryce> mwhudson, the intention was for them to go away for good; what's causing them to reappear?
<mwhudson> bryce: they are being synced from debian i assume
<mwhudson> e.g. https://launchpad.net/ubuntu/+source/php-horde-argv/2.1.0-5
<mwhudson> i guess if they are being maintained in debian again we might be happy to have them back
<bryce> https://bugs.launchpad.net/ubuntu/+source/php-horde/+bug/1868281
<ubottu> Launchpad bug 1868281 in php-horde (Ubuntu) "Please remove php-horde and php-horde-* from focal" [Undecided,Fix released]
<bryce> mwhudson, hmm, last I checked the stack had been abandoned in Debian.  Even if it's been re-adopted, it comprises over a hundred packages that pop up stuck in proposed migration frequently.
<mwhudson> bryce: seems a bunch of them got uploaded again about a week ago
<mwhudson> bryce: so we should work them back into release or delete them again and blacklist them so they stop syncing
<bryce> mwhudson, delete and blacklist.  Intent was to blacklist them, although looking at the bug I guess maybe this wasn't done last cycle
<mwhudson> bryce: want to file a bug for that and subscribe ~ubuntu-archive then?
<bryce> mwhudson, can do
<mwhudson> bryce: thanks
<bryce> I'm recovering from an X crash I just had a bit ago, will do so post-reboot
<bryce> (aka with a 6-monitor layout, vtswitching is an adventure)
#ubuntu-devel 2020-05-27
<bryce> mwhudson, https://bugs.launchpad.net/ubuntu/+source/php-horde/+bug/1880776
<ubottu> Launchpad bug 1880776 in php-horde (Ubuntu) " Please blacklist and remove php-horde and php-horde-* from groovy" [Undecided,New]
<mwhudson> bryce: thanks
<cpaelzer> paride: on +1 maintenance if you could check with the others if one is looking at qtbase-opensource-src that would be great
<cpaelzer> it entangles a few other things, it looks desktop'ish but I'm unsure - so checking if one is looking at it would be kind
<cpaelzer> all tests are good but https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt reports some uninstallabilities if I read that correctly
<cpaelzer> well actually that might be part of a full kde transition reading the pkg names
<cpaelzer> wgrant: from your experience on update_output is riscv listed so often because it is actual issues on riscv - or is it just because it reports just one arch (avoiding duplication) and riscv happens to be the one picked?
<cpaelzer> hmm "Arch order is: amd64, arm64, armhf, i386, ppc64el, riscv64, s390x"
<cpaelzer> does that mean if risc islisted it would have worked on the others before it?
<wgrant> cpaelzer: The problem with e.g. yara looks riscv64-specific, unless I'm misinterpreting the output
<wgrant> start: 111+0: a-7:a-7:a-8:i-2:p-7:r-72:s-8
<wgrant> orig: 111+0: a-7:a-7:a-8:i-2:p-7:r-72:s-8
<wgrant> skipped: yara yara-python (0, 0, 32)
<wgrant>     got: 138+0: a-7:a-7:a-8:i-2:p-7:r-99:s-8
<wgrant> But I'd expect that to be broken on all arches; libguestfs needs a rebuild for libyara4 afaict
<mwhudson> transform: couldn't project point (-81.4728 36.2344 0): No such file or directory (2)
<mwhudson> how can this possibly happen
<mwhudson> cpaelzer, paride: i haven't looked at  qtbase-opensource-src specifically but my impression is that everything is horrendously tangled together
<paride> mwhudson, I will try to have a look today
<RikMills> mwhudson et al. : yes, the Qt transition is entangled via qgis (depending on proj etc). also entangled with re2/perl transition due to a QtWebEngine rebuild in proposed for re2, while QT was still not migrated.
<RikMills> webengine could perhaps be rolled back by an AA to the unentangled version for a brief time if that helped the rest (Qt + proj) migrate
<mwhudson> heh i have my head in proj right now
<doko> paride: better fix the failing proj test
<doko> or r-cran-lwgeom, triggered by proj
<paride> ack doko
<RikMills> mwhudson paride: FYI, in case you had not seen, the original r-cran-lwgeom s390x issue with version 0.2-3-1 was reported as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961211
<ubottu> Debian bug 961211 in src:r-cran-lwgeom "r-cran-lwgeom: autopkgtest failures on s390x" [Serious,Open]
<RikMills> I don't know which is the worst evil. that or the 0.1-7-1ubuntu1 we have now
<mwhudson> yeah i'm not sure either
<mwhudson> i think i can see why the autopkgtest is failing with  0.1-7-1ubuntu1
<mwhudson> (master)mwhudson@anduril:~/src/pkg/plus_one/r-cran-lwgeom$ git diff upstream/0.1-7 upstream/0.2-4 | wc -l
<mwhudson> 47401
<mwhudson> yay!
<doko> cpaelzer: deepin-terminal is the same category/error as terminator, a package providing x-terminal-emulator
<cpaelzer> yes doko
<cpaelzer> a false positive, but we should find a way to get it out of the reports
<cpaelzer> I haven't looked at the code yet (not even which code it exactly is), but I have a feeling this will go into the guts of things and not be nice&easy
<mwhudson> RikMills, paride, doko: ok uploaded a fixed r-cran-lwgeom
<mwhudson> it's a bandaid though
<RikMills> \o/
<mwhudson> the tests will probably fail initially, can someone retrigger them with all-proposed=1 when they get the chance?
<RikMills> mwhudson: will do if I am by a PC when results come
<mwhudson> ty
<RikMills> mwhudson: poked the tests, and so far retries seem to be passing. proj is now a valid candidate
<RikMills> also poked a couple that were stopping perl being a valid candidate (stuck in test in progress status, but never did get run)
<mdeslaur> I need to package a new upstream version of something as a security update, it's going to be newer than what debian has, but it's a dfsg package, so I'll likely collide with debian's tarball when it comes out...is there any good practice for this, or do I collide away and sync back up with the next upstream release?
<rbasak> I'm not aware of anything apart from trying to coordinate with the Debian maintainer
<mdeslaur> I thought about just not adding the dfsg suffix to the package version, but it will need to be removed from the symbols files too, so I don't really want to do that
<rbasak> Yeah not worth it IMHO
<rbasak> Too much potential for confusion
<cjwatson> if the Debian maintainer is active then sometimes you can manage to agree a tarball
<cjwatson> which I guess is what rbasak said
<mdeslaur> ok thanks rbasak, I'll send him an email see if he responds
<mdeslaur> cjwatson: thanks, I'll try that
<cjwatson> also I don't suppose that uscan's mangling is reproducible?
<rbasak> Even if it is, it seems unlikely it pass through tar and the compression reproducibly?
<mdeslaur> he just refactored all the code that does that, so I'm not even sure we'd be using the same code
<mdeslaur> I'll ask the maintainer
<cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807270   rats
<ubottu> Debian bug 807270 in devscripts "mk-origtargz: create reproducible tarballs and --mtime option" [Wishlist,Open]
<cjwatson> that would seem like the ideal option
<cjwatson> but since it doesn't exist ...
<rbasak> bryce: I've injected a reimport request for logwatch. Let's see if that works OK. Assuming it does, I'll do the same for coreutils and php7.4.
<rbasak> ^ FYI to anyone else interested, the git-ubuntu branches for these packages will be rewritten shortly.
<rbasak> I'll announce more widely when I start doing bulk reimports.
<rbasak> If all goes well, we'll reimport everything just once, and then the branches (and tags) for the unapplied part of the imports will be stable.
<bdmurray> marcustomlinson: I'm working on another update-manager bug so let's coordinate our uploads / SRUs.
<marcustomlinson> bdmurray: sure Iâll ping you tomorrow
#ubuntu-devel 2020-05-28
<xnox> doko:  we are no longer building debian-installer in groovy, why did you try to rebuild it? was it holding up anything for you? it should not have
<xnox> mdeslaur:  rbasak: cjwatson: what i have done in the past, is use obscure compression algo. I.e. i forced to use bz2, this way when debian's gz or xz dfsg orig tarball comes out, it is syncable.
<xnox> because dfsg.bz2 is a different filename/artefact/unique
<xnox> doko:  also the way you adjusted those build-depends is not how they are generated normally
<xnox> doko:  hopefully i figured out what you needed to get done in d-i, and i think i uploaded something that will build now
<Logan> when is it appropriate to skip tests in a package that are failing on certain architectures? I've been working on getting nomad building against our Docker packages and got it to build on all arches except arm* due to certain tests failing: https://launchpad.net/ubuntu/+source/nomad/0.10.5+dfsg1-1ubuntu1
<xnox> Logan: well, you can request removing binaries for those arches thus making package migrate and keeping arm* builds failing to build.
<xnox> Logan: are those builds usable on arm* at all?
<marcustomlinson> bdmurray: hey, when you have some time could you have a look at this: https://code.launchpad.net/~marcustomlinson/update-manager/update-manager/+merge/384709
<mdeslaur> xnox: oh! that's a good workaround, thanks
<bdmurray> marcustomlinson: will do
<rbasak> bryce: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/384756 is ready for your review please
<rbasak> Last blocker for mass reimports I hope.
<rbasak> Well, "blocker"
<rbasak> Easier to do the server team's immediate reimports with this landed I guess
<bryce> rbasak, great, looking
<bryce> rbasak, finished going through it, lgtm.  My review feedback is entirely just my own notes; the things I thought you could change from the initial commits are indeed what you changed in later commits. ;-)
<rbasak> bryce: thanks!
<rbasak> bryce: logwatch reimport finished with the new branch - looks good
<rbasak> cpaelzer: I'm going to start the dpdk reimport now. Hopefully it'll be done by morning.
<bryce> rbasak, thanks, been looking at the logwatch bug paride mentioned today, I'll probably tackle that tonight.
<bryce> rbasak, do I remember correctly coreutils is reimported?
#ubuntu-devel 2020-05-29
<mwhudson> agggghhh why does cargo 0.44.1 ftbfs on s390x
<wgrant> mwhudson: Ugh, how?
<wgrant> That seems like really weird breakage.
<mwhudson> wgrant: https://launchpad.net/~mwhudson/+archive/ubuntu/rust-stuff/+build/19366472 i don't really get it
<mwhudson> wgrant: it could be a rustc problem maybe
<mwhudson> oh wait yes, rustc is segfaulting
<wgrant> Does look likely :(
<wgrant> Yep
<mwhudson> maybe lto?
<wgrant> Is this with the new rustc that upgrades from LLVM 9 to 10?
<wgrant> Or is it still back on 9?
<wgrant> I forget when that switch happened.
<mwhudson> (merge-1.43)mwhudson@anduril:~/src/pkg/rustc$ git diff merge-1.42 merge-1.43 -- src/llvm-project/ | wc -l
<mwhudson> 24
<mwhudson> so i don't think it's that then
 * mwhudson gets his canonistack on
<mwhudson> blargh hope this instance has enough disk for this
<sarnold> the whole point of a supercomputer is disk io, right? :)
<mwhudson> no
<mwhudson> as in, it does not have enough disk
<sarnold> aww :(
<mwhudson> haha what https://pastebin.canonical.com/p/pnNx7Rsfyr/
<sarnold> zounds
<sarnold> mwhudson: is there a way to specify plaintext passwords in user-data config snippets? private keys? the set-passwords module looks a bit like it requires hashed passwords, but I'd hate to misread it..
<mwhudson> sarnold: it is possible to do that, yes
<mwhudson> unhashed_password: or something
<sarnold> oh bother "a regex (r'\$(1|2a|2y|5|6)(\$.+){2}') is used to determine if a password value should be treated as a hash."
<sarnold> mwhudson: how many people are going to hate me if I file a bug report on this? :)
<mwhudson> sarnold: where did you see that?
<sarnold> mwhudson: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-passwords
<mwhudson> oh i see it
<mwhudson> that's not the usual way of setting paswords
<mwhudson> i think?
<mwhudson> yeah pretty sure not
<sarnold> the comments in this suggest it's not https://cloudinit.readthedocs.io/en/latest/topics/examples.html
<mwhudson> sarnold: i don't know how much people would hate you if you filed a bug about that :)
<sarnold> mwhudson: jfyi, https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1881225 -- thanks
<ubottu> Launchpad bug 1881225 in juju-core (Ubuntu) "do these error messages leak secrets?" [Undecided,New]
<mwhudson> sarnold: i would be pretty amazed if juju ever supplied user data that contained passwords but it is worth asking the question i guess
<sarnold> mwhudson: yeah it's entirely possible the outcome is "yeah, don't do that, retrieve secrets another way"
<mwhudson> hnnngh this build is going to succeed on this builder i think
<mwhudson> hm or maybe it's hanging in a different test
<mwhudson> wgrant: how much RAM do the builders have again?
<mwhudson> wonder if it's reacting badly to oom
<wgrant> mwhudson: 4 vCPU, 8GiB
<wgrant> At present
<mwhudson> hmm same as this bos01 instance i think
<mwhudson> ah well this is only 1 cpu
<mwhudson> so i guess peak memory usage on a 4 cpu builder would be higher
<mwhudson> and it definitely seems to be hung ;(
<mwhudson> nope that builds too
<mwhudson> oh using rustc 1.42 though
<mwhudson> is ports out of date??
<mwhudson> ah no, rustc 1.43 is in NEW
<Unit193> !info rustc groovy
<ubottu> rustc (source: rustc): Rust systems programming language. In component universe, is extra. Version 1.41.0+dfsg1+llvm-0ubuntu2 (groovy), package size 1693 kB, installed size 5069 kB
<mwhudson> ugh https://paste.ubuntu.com/p/Ckykd9Mvz7/
<mwhudson> core::intrinsics::copy_nonoverlapping (src=0x1 <- yeah that doesn't look right
 * mwhudson files https://github.com/rust-lang/rust/issues/72723 and runs away
<tinwood> Hi. Is there going to be an alpha for Goovy?  Or has that concept been dropped?  (I noticed there wasn't one for foccal either, looking back).
<tjaalton> tinwood: right, use the dailies
<tinwood> tjaalton, thanks for confirmation!
<LocutusOfBorg> jamespage, hello, any reason for this change?
<LocutusOfBorg> +openstack-pkg-tools (107ubuntu6) focal; urgency=medium
<LocutusOfBorg> +
<LocutusOfBorg> +  * build-tools/pkgos-dh_auto_test: Don't use subunit when executing
<LocutusOfBorg> +    tests with stestr.
<LocutusOfBorg> I'm upstreaming to debian the python->python3 move on debian-openstack channel, but they ask me the reason for this
<LocutusOfBorg> rbalint, https://salsa.debian.org/debian/flatbuffers/-/merge_requests/3 can you please rebase, merge and upload?
<LocutusOfBorg> flatbuffers is fixed since some time
<LocutusOfBorg> and I uploaded the RC bug fixes right now
 * LocutusOfBorg does it
<LocutusOfBorg> tkamppeter, hello ghostscript merge please? I would like to understand the reason for openimageio ftbfs
<LocutusOfBorg> I have a merge ready btw
<LocutusOfBorg> uploading sorry for stealing it :)
<rbasak> cpaelzer: the dpdk reimport finished without errors. It didn't adopt upload/17.11.5-0_ubuntu18.04.1 though (one out of four upload tags that were there). I suspect the empty directory issue. Does this seem normal to you?
<LocutusOfBorg> (openimageio builds fine now yay!)
<rbasak> ahasenack, sergiodj: reimport requests submitted for clamav, python-oauth, python-oauthlib, cifs-utils and apache2.
<sergiodj> rbasak: thanks
<ahasenack> rbasak: just to remember, these would have their hashes changed then, right?
<rbasak> ahasenack: correct
<ahasenack> ok
<tkamppeter> LocutusOfBorg, I did not upload any Ghostscript after Focal release yet. the only reason why we do not sync Ghostscript with Debian as we build all packages with -O3 and one architecture (I think ppc64) does not build Ghostscript. It is a gcc bug and no regression-free solution got found yet.
<tkamppeter> LocutusOfBorg, what is this  openimageio ftbfs?
<LocutusOfBorg> tkamppeter, I uploaded the new ghostscript, keeping the gcc workaround for now
<tkamppeter> OK, thanks.
<LocutusOfBorg> it turned out openimageio was FTBFS because of openimagesomething else I don't recall
<LocutusOfBorg> something like yaml-cpp sadness due to it being syncd and making c++ symbols sad
<xnox> vorlon:  can we tell which arch:all packages are seeded into i386 and needed, and which ones are not?
<rbasak> rafaeldtinoco: what use case do you have in mind that would need an argument to ignore the environment variable? Couldn't you just invoke the command with the variable unset?
<rafaeldtinoco> rbasak: regular user might tend easier to execute df -a
<rafaeldtinoco> lets say
<rafaeldtinoco> and see it all
<rafaeldtinoco> (like the user that replied just now about their need on tmpfs)
<rafaeldtinoco> that is what came to my mind
<rbasak> Oh, I see
<rbasak> That makes sense - good point
<sforshee> Laney: I'm trying to run autopkgtests against a kernel package in a ppa but I'm getting this message - "You submitted an invalid request: Package linux-5.7 does not have any test results"
<sforshee> is there something I can do to get the test to run?
<Laney> sforshee: Can't be done via request.cgi atm :(
<Laney> get apw or someone to run it using run-autopkgtest
<sforshee> Laney: ack, thanks!
<sforshee> apw: ^
<vorlon> xnox: which ones are seeded, you can look at the germinate output?
<vorlon> or the packageset
<xnox> vorlon:  right, it's just i fear that an arch:all package might be holding up openmpi on i386, specifcally this odd arch:all thing i don't see anymore!
<xnox> vorlon:  wait, it's there. this thing xmds2
<xnox> is it published in i386, and does it hold up removal of openmpi on i386?
<vorlon> xnox: what removal are you talking about? I have no context for this
<vorlon> xnox: what removal are you talking about? I have no context for this
<vorlon> sorry
<sarnold> how does ddebs.ubuntu.com get the dbgsym packages? https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1881314
<ubottu> Launchpad bug 1881314 in openssl (Ubuntu) "libssl1.1-dbgsym 1.1.1-1ubuntu2.1~18.04.6 missing from ddebs.ubuntu.com for 18.04" [Undecided,New]
<sarnold> https://launchpad.net/ubuntu/+source/openssl
<sarnold> http://ddebs.ubuntu.com/pool/main/o/openssl/
<sarnold> it does indeed look like 1.1.1-1ubuntu2.1~18.04.6 debug packages haven't been copied into the ddebs yet
<cjwatson> sarnold: lp:ddeb-retriever
<cjwatson> I'll look
<cjwatson> Hm yes, bother
<cjwatson> 16342   May 19 /bin/sh -c ~/ddeb-retriever/ddeb-retriever --verbose >>/srv/ddebs.ubuntu.com/logs/ddeb-retriever.log 2>
<cjwatson> 16343   May 19  \_ /usr/bin/python3 /srv/ddebs.ubuntu.com//ddeb-retriever/ddeb-retriever --verbose
<cjwatson> Killed, it should catch up in a bit
<cjwatson> There was a network outage that day
<cjwatson> (updated the bug too)
<sarnold> cjwatson: excellent, thanks! I haven't seen this one yet :)
<cjwatson> I guess my attempt to add timeouts there wasn't totally effective.  Fixing https://bugs.launchpad.net/launchpad/+bug/1856774 and making ddeb-retriever use that is almost certainly the way forward - as well as fixing a privacy edge case, it would reduce the number of network requests that need to be made there
<ubottu> Launchpad bug 1856774 in Launchpad itself "Export source_package_name and source_package_version on BPPH" [High,Triaged]
<sarnold> cjwatson: thanks! :)
<xnox> ddstreet: rbalint: Laney: do you know how to "retrigger systemd-github-autopkgtests? i.e. how do i retrigger https://github.com/systemd/systemd/pull/15905 ?
<cjwatson> 2020-05-29 22:12:48,822 INFO    Installing 111/21396: osgearth-dbgsym 2.10.2+dfsg-2build4 in groovy s390x
<cjwatson> so it's about that far along (high startup time before it gets into that progress "bar").  We'll see
<sarnold> oh wow
<sarnold> is it this bit here?
<sarnold> # pub.distro_arch_series and das.distroseries is expensive.
<cjwatson> no
<cjwatson> it just takes quite a long time to iterate over ten days' worth of all publications in Ubuntu
<cjwatson> since that's how far backlogged it was
<sarnold> ooooof :)
<sarnold> I'm surprised no one spotted this earlier, if it was ten days out of date :/
<cjwatson> quite
<cjwatson> it needs some kind of alerts, but it's an oldish system
<sarnold> admittedly ddebs isn't the easiest thing to use..
<cjwatson> Anyway, rough extrapolation suggests it should catch up in ~10h
#ubuntu-devel 2020-05-30
<Logan> xnox: hard to say if the arm* builds are usable because I don't have an arm* machine :( How would you go about deciding that?
<Logan> I guess I could try running in an emulator?
<ogra> waveform, should the 8GB pi work with the current core 18 images ? my device only seems to emit some morse codes from the heartbeat LED but nothing else ...
<Laney> xnox: not me, sorry, I don't have the code thing (AFAIK), get ddstreet to do it
