#ubuntu-devel 2004-12-13
* mjg59 spreads more acpi love
<mjg59> Scott's going to be the only one without any at this rate
<jdub> mjg59: spread some love by convincing mdz/fabbione to accept the dsdt-initrd patch ;)
<mjg59> Haha
<stuNNed> jdub, schweet
<jdub> i'm going to be forever building kernels :|
<stuNNed> jdub, disabling agp, installing custom acpi script from wiki and editing a bit fixed acpi here (for the last 3 days)
<jdub> i need a custom dsdt
<stuNNed> does ubuntu installer have ntfsresize and vfatresize utils for users deciding to install but not wipe?
<mako> you will be in mataro and want to participate in the keysinging: http://people.ubuntulinux.org/~mako/ksp-mataro/
<mako> the keySIGNing will be directly before the singing i think
<mako> or directly after, i can never keep it straight
<mdz> need to shut off power to the whole house for a bit
<mdz> need to do this while there's sunlight :-)
<jdub> heh
<mdz> back in hopefully under an hour
<jdub> ciao
<Matt|> guys what is the difference between the linux-kernel-headers package, and the linux-headers packages?
<mako> mdz: so what were you doing that required unplugging your whole house?
<mdz> mako: replacing a circuit breaker
<mdz> call me funny, but I have this hangup about poking about with a screwdriver inside a live panel
<jdub> seriously dude
<jdub> what could go wrong?
<jdub> the worst that could happen is that you turn into a superhero
<jdub> like ELECTRODE MAN
<mako> mdz: jdub is right
<jdub> or THE BLUE SMOKE
<mako> i saw just that happen in ernest goes to jain
<mako> sorry, jale
<mako> jail
<mako> damnit
<jdub> through cargo cult logic, whenever someone has an outlandish accident, they turn into a superhero
<mdz> Kamion: hoary/powerpc installation with 20041201.1 was a success
<lamont>   evolution: Depends: libgtkhtml3.6-12 (>= 3.5.0) but it is not installable
* lamont grumbles at evo
<lamont> (it's libgtkhtml3.6-13 now...)
<melazyboy> VLC is out of date, they have a new packages that fixes numerous bugs
<jdub> hahahahah
<jdub> Most of the distributions built on top of Debian, such as Linspire, Xandros, Skolelinux, LinEx, or Ubuntu, apply some discretion in the packages they select. They are unlikely to include tools like hot-babe, and, thus, may be considered safer versions to use in situations where somebody may get offended.
<jdub> Well, OK, perhaps we can't be too sure with Ubuntu. 
<jdub> ^ from this week's lwn
<jdub> 
<fabbione> morning guys
<Keybuk> mdz: around?
<Kamion> stuNNed: the hoary installer includes ntfsresize, and the partition manager knows how to call out to it to resize NTFS partitions; parted supports FAT natively
<Kamion> stuNNed: the warty installer doesn't include ntfsresize
<Keybuk> definite need for apt-get install pxeboot-loving
<loogaroo> hi
<loogaroo> is somewhere a guide for developing configuration tools for ubuntu?
<Kamion> gnome-system-tools is probably the place to start
<loogaroo> But, I prefer python
<azeem> loogaroo: you also /might/ want to look at the debian-desktop archives. They seem to work on something connection debconf, config4gnu and g-s-t
<Kamion> g-s-t has python integration I thought
<ross> g-s-t is C frontend and perl backend
<loogaroo> and what is/are the prefered languages/toolkits of the ubuntu devs?
<ross> python and gtk are blessed
<bob2> {py,}glade is 31337
<loogaroo> hmm, sorry what do you mean with 31337, should this be leed?
<Kamion> he's joking
<Kamion> slang for "elite", parody of script-kiddie talk
<loogaroo> :( and I do not understand it
<loogaroo> oh, ok
<bob2> = it's quite a nice way to write gui code in python
<loogaroo> then my next questition, are there any libs for python which handles the linux config files?
<ross> loogaroo: "the"? they are all formatted differently :)
<ross> python will let you parse most files natively
<loogaroo> ok
<loogaroo> is it possible to render a gtk gui at the console?
<loogaroo> like curses
<ross> there is a hack, but no
<ross> if you want to do curses, use curses
<azeem> or debconf perhaps
<Kamion> I would avoid debconf outside the installer and packages' maintainer scripts
<azeem> I didn't say it was a good idea
<azeem> at least, not until there is something like the GNOME HIG for debconf-UI
<loogaroo> I like gtk, but I think gtk config tools are not so handy for remote work
<bob2> that's when you use an editor :)
<loogaroo> hmm
* Mithrandir feeds Kamion some custom widgets crack. (:
<ross> loogaroo: or remote X :)
<loogaroo> VNC :)
<ross> why export a desktop over the network when the application you want will do the job?
<loogaroo> ok, X is better
<loogaroo> but you are right it makes not much difference, if curses or gtk forwarted
<loogaroo> so gtk is nice
<Keybuk> gtk is sex
<ross> this isn't sex: http://gemal.dk/misc/nsb05.png
<ross> "How Not To Make A Web Browser"
<Keybuk> Whoah!
<jdub> isn't that astoundingly bad?
<thom> holy mother of god
<jdub> i wonder who they got to do that
<Kamion> my God, that's a busy-looking screen
<Kamion> <Kinnison> My eyes couldn't actually stay on it, which is why it took me so long to realise how bad it was.
<ross> rofl
<ross> everyone seen the ubuntu comment in this weeks LWN?
<jdub> yeah :)
<jdub> haw haw
<jdub> that's going to stick
<Keybuk> Ubuntu, it's a little bit wooo, a little bit wayyy
<ross> haha
<ross> jdub: get the ubuntu models to do some more artwork for hot-babe
<thom> ubuntu-hotter-babe
<smurfix> ross: ubuntu'll never live that down anyway, so go with it ;-)
<daniels> Kamion: MUST ADD MORE SHINY
<ross> i'm still wondering what all the buttons on the tab bar actually do
<thom> i have closed the screenshot because it made my brain close
<robatylor|away> mako: happy birthday, btw :)
<jdub> does anyone have bluetooth input hardware?
<jdub> keyboard, mouse, etc.
<Treenaks> didn't edd have that?
<azeem> on a related note, is it safe to buy just any bluetooth USB dongle, or should I be careful about the model WRT Linux/Ubuntu compatibility?
* edd has plenty of it
<daniels> azeem: seems to be fairly easy to just grab random crap
<azeem> daniels: great, thanks
<edd> azeem: you're unlikely to buy one there's no drivers for these days
<ross> azeem: i bought the cheapest i could find and it works fine
<jdub> edd: coming to matar?
<Treenaks> ross: ubuntu comment on LWN? (I don't have a subscription..)
<edd> jdub: no. family time this month, etc.
<daniels> i just got a 100m-range belkin one and it worked fine
<jdub> ahr.
* azeem is planning to buy one for his dad for christmas
<daniels> edd: btw, my k700i magically kinda fixed itself, so sweet dela
<daniels> deal, also
<edd> daniels: sick
<edd> (i heard that on radio 1, it means 'good')
<Mithrandir> Treenaks: They [Debian derivatives]  are unlikely to include tools like hot-babe, and, thus, may be considered safer versions to use in situations where somebody may get offended.
<Mithrandir> Well, OK, perhaps we can't be too sure with Ubuntu.
* jdub rephrases, "someone with bluetooth input hardware coming to matar?"
<daniels> edd: ill
<azeem> Mithrandir: heh, yeah
<Mithrandir> jdub: my phone and hopefully my shinyshinyshiny x40.
<daniels> Mithrandir: word
<jdub> Mithrandir: input hardware, like keyboards/mouse
<sjoerd> jdub: i've got a bluetooth mouse
* jdub has laptop and phone :)
<Mithrandir> jdub: oh, that kind of hardware.
* Treenaks will bring a 4-year old Asus laptop :)
<bob2> jdub: lu has a bt keyboard, iirc
<thom> certainly a bt mouse
<jdub> cool
* Treenaks 's countdown is at T-48 hours :)
<Treenaks> What about GPS integration btw? :)
<Treenaks> I have a USB GPS device.. shouldn't the weather applet etc. derive the 'default location' from that? :)
<jdub> heh
<Mithrandir> Treenaks: patches accepted :)
<Treenaks> Mithrandir: hmm.. we'd first need to separate gpsd from the gpsdrive package, probably
<Keybuk> Treenaks: interesting way to seed /etc/timezone
<Treenaks> Mithrandir: and then autodetect GPS dongles
<Mithrandir> Treenaks: wouldn't be against me :)
<Treenaks> (which can be Hard because they're just serial convertors..)
<Mithrandir> Treenaks: autodetecting USB stuff is a bit icky, yes.
<Treenaks> oh well, I guess I can use it to learn python :)
<Mithrandir> uhm, s/USB/GPS/
* sjoerd has a bluetooth gps dongle :)
<sjoerd> Treenaks: you probably want ngpsd btw (if it has it's dbus interface by now)
<jdub> what on earth do you guys use gps for?
<Treenaks> sjoerd: if dbus and HAL? :)
<Mithrandir> Keybuk: that should work fine, if you can detect that you have a GPS.
<Mithrandir> jdub: play.
<Treenaks> jdub: wardriving/cycling/walking :)
<sjoerd> jdub: geek toys :)
<sjoerd> and time 
<Treenaks> jdub: and as toys :)
<sjoerd> a gps device delivers extremely acurrate time information if it has a fix
<Treenaks> sjoerd: accurate time + bluetooth delay + usb delay = inaccurate time :P
<sjoerd> bluetooth delay isn't that big
<Mithrandir> Treenaks: USB delay shouldn't be too bad, should it?
<Treenaks> Mithrandir: depends on the amount of hubs involved
<jdub> i tend to carry about four or five hubs when cycling, yeah
<sjoerd> Treenaks: none (apart from the root)
<Treenaks> jdub: You are jdub of borg?
<sjoerd> and my laptop has bt built in.. so dedicated usb controller
<Mithrandir> jdub: but you're weird.
* Kamion suspects a tiny bit of sarcasm
<sjoerd> jdub: why the interest in bluetooth input devices btw
<jdub> sjoerd: bluetooth integration in hoary
<sjoerd> ah
<Treenaks> jdub: /all/ kinds of bt devices? :))
<edd> jdub: you'll my tracking my recent frenzy of uploads then :)
<jdub> Treenaks: sure
<sjoerd> i can bring an bt headset too, but there is no good code for it yet..
<jdub> edd: :-)
<Treenaks> sjoerd: there is time to hack..
<jdub> sjoerd: that hardware in particular?
<Treenaks> sjoerd: I have a BT headset as well, but it doesn't even integrate nicely with my phone
<Treenaks> sjoerd: (nokia headset + nokia phone..
<sjoerd> jdub: no general bluetooth audio stuff
<Treenaks> I have a Nokia HS-3W I could bring..
<jdub> Treenaks: bt incompatibility seems endemic now, particularly with phones
<Treenaks> jdub: I need to get new firmware on my phone.. it should fix some of the BT problems
<jdub> hrm
<jdub> i haven't even thought to see if there were upgrades for mine
<Treenaks> jdub: which one?
<jdub> t630
<sjoerd> jdub: if you know how to put new nice firmware on that, lemme know 
* sjoerd has the same phone
<Treenaks> http://www.mobiledia.com/forum/topic7181.html ?
<Treenaks> http://www.esato.com/archive/t.php/t-68451 sorry
* smurfix 's t630 phone will no doubt be an interesting compatibility test subject too :-/
<Treenaks> sjoerd: like my 3650..
<Treenaks> smurfix, sorry
<smurfix> Treenaks: what for?
<Treenaks> smurfix: oh, it tends to disconnect after some AT command on BT
<smurfix> Ah, the wrong nick. I first thought you were sorry about my phone. ;-)
<Treenaks> smurfix: well, that too :P
* Treenaks hacks some very evil-looking perl code [work] 
<jdub> hrm
<jdub> i have latest non-developer firmware according to that page
<smurfix> Anyway it also has infrared, so the BT-challenged can do some stuff too.
<Treenaks> my 3650 has 2.50.. latest released version: somewhere around 4.17
<Treenaks> 4.13
<Treenaks> no 4.17 :)
<bob2> does linux tend to usefully support talking to phones via ir?
<azeem> depends on how you define 'talking'
<bob2> can I send sms? read them?
<azeem> I do that for my Siemens S45 via scmxx
<azeem> if you have a phone which supports IrMC (like the S45*i*, drat), you can easily sync contacts and calendar, too
<bob2> bah, nokie.
<bob2> er, nokia.
<azeem> there are apps for nokia phones as well, but I don't know them
<azeem> gnokii or somethign
<bob2> yeah
* jdub suspects seb128 secretly uses windowmaker
<stratus> heh
<seb128> ah ah
<sjoerd> bob2: most are just serial ports, so you can send normal AT command to them
<smurfix> azeem: define "easily". Between my old Psion and the phone, for instance, *somebody* messed up the timezones. All my all-day events now start at 2am instead. :-/
<jdub> smurfix: multisync has some funny timezone options
<stratus> seb128, FYI #3634 is reproducible with evolution 2.1.1
<azeem> smurfix: "easily" as in: "You do not have to download stuff from the phone and sync maunally via vi" :p
<azeem> anyway, off for lunch, laters
<seb128> stratus: that why it's not closed :)
<stratus> seb128, hmm have you reproduced this bug? AFAIK it's just a problem here.
<thom> ahr, readahead package
<smurfix> jdub: Ah, thanks
<seb128> stratus: it doesn't crash here, but the bug is still open upstream and has 7 dups
<jdub> thom: hrrrmmm?
<thom> for great justice^Wspeed
<thom> jdub: packaging readahead, currently
<jdub> thom: i looked at doing that the other week -> we don't have glibc support for it, though
<thom> yeah we do
<thom> i'm just ignoring nfs
<stratus> seb128, ah i didn't read the 7 dups...reported at upstream or ubuntu ?
<seb128> upstream
<stratus> thanks.
<seb128> np
<thom> jdub: in our typical case, i don't think it's a problem
<jdub> mmm
<thom> i'm warning all and sundry in README.Debian anyway
<Treenaks> smurfix: Psion + timezone trouble.. I have that now on my 3650 :(
<Treenaks> ok.. to the nokia center! let's go!
<daniels> Kamion: er, what's responsible for creating /etc/default/rcS?  appears to be neither sysvinit nor base-config AFAICT
<daniels> Kamion: er, nevermind me
<Kamion> prebaseconfig fiddles with it
<Kamion> may be something else too
<Treenaks> ARGH
<daniels> Kamion: initscripts has this beautiful little stanza where it says 'if /etc/default/rcS doesn't exist, then copy it from /usr/share' in postinst
<daniels> HELLO CONFFILES
<daniels> so I had my way with it
<daniels> RCSMD5="$(md5sum /etc/default/rcS | awk '{ print $1; }')"
<daniels> if [ "$RCSMD5" = "9d2fb3f6d13039109c02de2092f880f5" -o \
<daniels>      "$RCSMD5" = "68ed0d1fdeee47c682f66c335f58b65e" -o \
<daniels>      ! -f /etc/default/rcS ] 
<thom> it even appears to work, shockingly
<Kamion> daniels: is that your code or existing code?
<jdub> he found it on dailywtf
<Kamion> if it's your code, could you change '-o' to ']  || ['?
<daniels> Kamion: my code
<daniels> Kamion: oh, is this an XSIism?
<Kamion> yep
<Kamion> or some other kind of non-POSIXism anyway
<Kamion> XSI I think
<daniels> brer
<daniels> ber, also
<ross> holy crap
<ross> today's dailywtf is great
* jdub still wonders what happened to mark pilgrim
* Treenaks kicks the nokia service center
<thom> ross: the indexed arrays done manually one is genius too
<ross> it surely is
<edd> jdub: what do you mean, "what happened" ?
<jdub> edd: diveintomark.org
<edd> ah, i see. sounds like some big argument or other.
<jdub> it's been like that for quite a while now
<azeem> "Why specs matter
<azeem> Most developers are morons, and the rest are assholes."
<azeem> heh
<zul> heylo
<Treenaks> zuul?
<zul> yep
<lupus_> is it just me
<lupus_> or is evolution in hoary broken?
<Treenaks> a bit
<lupus_> hehe
<lupus_> no workaround?
<azeem> lupus_: use mutt
<lupus_> thunderbird it is :p
* sid77 hi!
<pitti> sjoerd: thx for packaging the new hal
<pitti> sjoerd: btw, any interest in tarball.mk for this? :-)
<sjoerd> decided not to do that, because the amount of patches isn't really worth it imho
<pitti> okay
<pitti> yeah, it's more important for gvm
<sjoerd> and to package it it was basically get new tarball, remove merged patches, build, upload :)
<pitti> so again I will steal it from incoming, merge and have it in Ubuntu earlier than in Sid :-)
<sjoerd> next time i'll upload just before the archive run stuff :)
<pitti> hehe
<sjoerd> and commit after the upload ...
<bob2> lupus_: if no one has filed a bug yet, please do
<pitti> sjoerd: don't bother, I see upload messages earlier than your commits :-)
<sjoerd> k
<lupus_> bob2, k filled in
<bob2> lupus_: thanks!
<bob2> omg
<bob2> that is actually netscape?
<daniels> Kamion: ping
<bob2> I thought it was some horrible hack a 3 year old had knocked up
<Kamion> daniels: pong
<daniels> Kamion: what's the best way to migrate runlevels for an init script?
<daniels> i.e. dbus-1 used to be S20, I'd like to make it S12
<Kamion> does the old prerm do update-rc.d remove?
<Kamion> (or postrm - something called on upgrade anyway)
<daniels> Kamion: only on purge
<Kamion> hm, in that case I don't know, I'm afraid
<Kamion> I've never done this ...
<gicmo> sladen, ping (I assume your are not here .. but its worth a shot :)
<daniels> Kamion: ok, so just testing for rc2.d/s12dbus-1
<daniels> Kamion: and removing if so, and unconditionally adding with 12 later
<daniels> Kamion: sound decent?
<sladen> gicmo: I am here :-)
<gicmo> sladen, ha .. :) .. I cant believe it :)
<gicmo> sladen, I am totaly keen on coding on that graphical stuff .. any chance you can send me that code .. or tell me where to help/start
<lupus_> daniels, working on making gdm start earlier? :)
<thom> yeah, he is
<daniels> lupus_: sure am
<lupus_> nice :)
<Kamion> daniels: can't test for rc2.d/S12* I'm afraid, breaks with file-rc
<daniels> Kamion: arse
<daniels> Kamion: any ideas on how to migrate it there?
<daniels> bbiab
<mxpxpod> has anyone tried to run beagle on ubuntu?
<zul> yeah didnt compile for me
<mxpxpod> zul: how did you get the dbus mono bindings?
<zul> followed the instructions in the wiki
<daniels> Kamion: for now, I'm just uploading sysvinit/dbus/alsa-driver/gdm with migration logic for sysvinit, we can sort out file-rc later
<Kamion> daniels: I'm sure there must be a better way; maybe update-rc.d remove and update-rc.d (whatever, to re-add) with a dpkg --compare-versions check
<daniels> Kamion: dpkg --compare-versions is no good if it doesn't make it back to debian
<daniels> Kamion: i'm using the update-rc.d remove/update-rc.d (readd) thingy, but the problem is telling how it's already at 20 with file-rc
<Kamion> aren't you the Debian maintainer anyway? just do it there ...
<daniels> er, neuro maintains gdm in debian :P
<daniels> this touches alsa/dbus (-> 12) and gdm (-> 13)
<Kamion> oh, I see
<Kamion> ask debian-policy@ ?
<daniels> yah, think I will
<mdz> morning
<daniels> mdz: 'morning
<fabbione> what a day
<Treenaks> what about it?
<fabbione> Treenaks: have been really sick all day 
<fabbione> 2 computers broke down
<fabbione> my gf broke down the car
<fabbione> the washing machine exploded
<fabbione> not bad for less that 24 hours
<daniels> ugh :(
<Treenaks> ok.. that qualifies as a Bad Day
<fabbione> and i still feel shitty
<mako> robtaylor: thanks :)
<mdz> fabbione: ouch
<fabbione> i am going back to sleep
<fabbione> perhaps something will autofix itself during the night
<mdz> fabbione: hopefully the bed will not collapse beneath you
<fabbione> SHHH
<fabbione> don't even think about it!
<mako> someone is asking me how to do ubuntu OEM, i don't think i understand what that means
<Treenaks> mako: Pre-installed ubuntu?
<Treenaks> maybe?
<mako> yeah, i think so
<Treenaks> Like I can't buy "OEM windows" without buying a complete PC
<mako> that is pretty cool i suppose :)
<mako> well, i'm not sure what he wants my help with :)
<mako> "yes, you install it on a computer before you sell it"
<Treenaks> yeah, but we'd probably need a special installation mode that drops you at the "create a user" screen
<mako> i guess it's culture shock coming to free software
<Treenaks> :)
<zul> mako: for most people it is
<Treenaks> I had that shock when I first read the GPL back in '96 :)
<mako> Treenaks: yeah, i guess i did too.. :)
<mdz> mako: what's the word on ubuntu traffic?
<Treenaks> "WTF? This is a COOL idea! I want this!"
<mako> mdz: UT13 will be done in an couple hours i think.. i'm going to try to get the remaining one out today or tomorrow
<mako> mdz: i've read everything for UT13 but haven't finished writing it
<Kamion> mako: Jeff and I were talking about that, some kind of "do everything but the user-customisation bits of the install"
<mdz> Kamion: yeah, so that on the first boot, you get a few questions and then gdm
<Kamion> right
<mako> Kamion: yeah, totally that would be interesting
<Treenaks> and of course it should be "imageable" or something
<Kamion> well, only onto identical disks, but sure
<Treenaks> so you can make 600 disks with the same almost-ready-to-use Ubuntu on it
<Kamion> not as if we do product activation ;)
<Kamion> although ... hmm, hostname
<Kamion> that's gonna suck, no netcfg.deb
<Kamion> so, depends on post-reboot network config, sigh
<Treenaks> do dhcp by default, /change/ the hostname and net config in the "first boot" screen?
<Kamion> still depends on post-reboot network config one way or another :-)
<Treenaks> uh yes
<zul> why not do a wizard when you are doing a first boot, the wizard can do things like detect your soundcard network, users etc
<Treenaks> which is needed anyway I think?
<Kamion> basically we need to be able to do netcfg-a-like functionality in base-config when it wasn't done pre-reboot (e.g. not netboot)
<Kamion> Treenaks: depends on your point of view
<Kamion> zul: sound card should be detected by hotplug; if that doesn't work we should just fix hotplug
<Treenaks> Kamion: well, say I have my ubuntu PC connected to my (DHCP) cable modem, and I decide I want DSL (PPPoE)
<Treenaks> Kamion: then I need to change..
<Treenaks> Kamion: so I need a post-install network configurator
<Kamion> Treenaks: oh, sure, for reconfiguration you want gnome-system-tools though
<Kamion> Treenaks: I'm talking about base-config kinda level here
<zul> Kamion: sound card is just an example
<Kamion> zul: applies to all hardware
<Kamion> zul: note that we already have base-config which is run at first boot and deals with stuff like adding users
<Kamion> zul: for OEM, we'd just do most of base-config and leave the job incomplete
<Kamion> that's one approach, anyway
<Treenaks> the easiest one, probably
<Kamion> could even do it with the GNOME frontend come grumpy
<Treenaks> (what a name.. grumpy)
<mako> only 23 keys for the party in mataro.. i need more!
<daniels> elmo: ping
<mdz> mako: where did you announce it?
<mdz> mako: is it linked from the conference agenda?
<mako> mdz: announced on -devel, -users, warthogs
<mako> it is on the conference agenda but not linked (yet).. doing that now
<lamont_r> so is it safe to upgrade to current hoary?
<stratus> daniels, i'll reboot with gdm at S13 can i kill you if it break my ubuntu?
<daniels> stratus: you can try if you like ...
<daniels> works fine for me
<stratus> daniels, i see that you've uploaded ubuntu6 i'll wait for it...
<stratus> daniels, was needed only change S99 to S13 ?
<daniels> stratus: and dbus and alsa to go to S12 and to change DELAYLOGIN to no in /etc/default/rcS
<stratus> oh, i see previous uploads.
<stratus> thanks.
<bronson_> What are the chances of getting some mountpoints for CF cardreaders added to /etc/fstab?
<azeem> bronson_: zero, I'd guess
<Treenaks> bronson_: you don't need those
<Treenaks> bronson_: unless you boot from them
<bronson_> Really?
<Treenaks> bronson_: hal/pmount/gnome-volume-manager/nautilus mount them automatically
<bronson_> Then I'm doing something wrong...
<bronson_> https://www.ubuntulinux.org/wiki/CardReaderHowto
<bronson_> Treenaks: wasn't working for me.
<Treenaks> bronson_: it is for me.. and lots of other people
<bronson_> So I added my cardreader to udev.  Now I get the /dev files.
<bronson_> How do I find out what's going wrong?
<bronson_> Does udev automatically create the /dev nodes for you?
<azeem> bronson_: check hal-device-manager, whether your reader is mentioned there
<bronson_> azeem: yes it is.
<Treenaks> bronson_: yes
<bronson_> Treenaks: can you point me to the rule that creates them?
<bronson_> My card reader was being ignored until I added a rule for it.
<Treenaks> bronson_: uh.. it's automatic
<Treenaks> with the default setup
<bronson_> udev requires a rule for everything it creates.
<bronson_> How about this question: what node does it create for the CF reader?
<bronson_> From that, I could grep the rule.
<Treenaks> it's broken atm because it has restarted while booted
<bronson_> Does it just create the default /dev/sda1?
<bronson_> Or does it create something like /dev/cf1?
<bronson_> Since it's USB mass storage, I would guess that it just uses the /dev/sd* nodes...?
<bronson_> Does anybody here have a CF reader that works?
<bronson_> I'd like to know how it's automounted since most USB CF readers don't issue a media inserted event.
<bronson_> Without that, how does the udev node get created?
<sjoerd> bronson_: check if you have a /sys/block/sd*
<Treenaks> bronson_: I have it working now..
<bronson_> sjoerd: yes.
<sjoerd> do you also have a sd* subdir in that dir
<bronson_> sjoerd: sda1, yes
<sjoerd> what happens if you run pmount /dev/sda1 as your user
<Treenaks> bronson_: what does "lshal" say?
<Treenaks> bronson_: (about linux.sysfs_path_device = '/sys/block/sda')
* lamont_r heads back home.
<bronson_> sjoerd: I don't have a /dev/sda1.
<bronson_> Treenaks: looking...
<Treenaks> bronson_: it shuold give you a huge list
<Treenaks> bronson_: important parts:
<Treenaks>   storage.automount_enabled_hint = true  (bool)
<Treenaks>   storage.media_check_enabled = true  (bool)
<sjoerd> bronson_: what's the output of udevinfo -q all -p /sys/block/sda/sda1  
<sjoerd> Treenaks: your looking much too high on the stack if that device doesn't exist
<bronson_> sjoerd: not much...  3 lines.
<Treenaks> sjoerd: if /sys/block/sda exists, it shuold be in lshal
<bronson_> pasc: /block/sda/sda1
<bronson_> N: cf
<bronson_> seb128: 
<sjoerd> ah so could you do pmount /dev/cf
<bronson_> I'm afraid that's my custom udev rule triggering.
<bronson_> /dev/cf is my own invention.  :)
<sjoerd> that should just work (tm)
<bronson_> I should probably change my rule to get it to create sda1.
<sjoerd> bronson_: did the pmount work though ?
<bronson_> yes.
<bronson_> Excellent.
<bronson_> I'll change my udev rule to create the sd* nodes.
<sjoerd> bronson_: no, don't
<sjoerd> could you tail your .xsession-errors and show the output when you plug in cf stuff
<bronson_> sjoerd: nothing.  Did you mean /var/log/messages?
<bronson_> Doesn't matter.  Nothing appears in /var/log/message either.
<sjoerd> is gnome-volume-manager running ?
<bronson_> no?!
<sjoerd> :)
<bronson_> but gnome-volume-manager still needs a /dev node to do its magic doesn't it?
<sjoerd> yeah, but you have /dev/cf right ?
<bronson_> Only due to my hacked up udev rule.
<sjoerd> doesn't matter
<sjoerd> hal knows 
<bronson_> So gnome-session is supposed to start gnome-volume-manager?
<sjoerd> to get it working extra nice, make it readable by group plugdev
<sjoerd> bronson_: btw, this is ubuntu stuff, not ubuntu-devel imho
<bronson_> sjoerd: you're right.  It started with a question about /etc/fstab.
<bronson_> Sorry bout that.  :)
<bronson_> Even with gnome-volume-manager running, nothing happens when I plug/unplug cards.
<sjoerd> what does it say in your .xession-errors ?
<bronson_> nothing.
<sjoerd> is this warty or hoary ?
<bronson_> hoary
<Treenaks> is dbus-daemon running?
<bronson_> 3 of them are.
<Treenaks> maybe that's the problem
<Treenaks> I have only 1
<sjoerd> you should at least have two (one for the system one for the user)
<bronson_> At the risk of a flood, here are the 3 lines...
<sjoerd> but gvm && hal use the system one, so it doesn't matter
<bronson_>  4036 ?        Ss     0:01 /usr/bin/dbus-daemon-1 --system
<bronson_>  4867 ?        Ss     0:00 dbus-daemon-1 --fork --print-pid 8 --print-address 6 --session
<bronson_>  8990 ?        Ss     0:00 dbus-daemon-1 --fork --print-pid 8 --print-address 6 --session
<bronson_> So it appears I have one too many...
<Treenaks> 2 session-daemons is a bit much I think..
<sjoerd> doesn't matter
<bronson_> Criminy.  Something's really wrong on my machine.
<bronson_> Does gnome-volume-manager poll?  I'm pretty sure my CF reader doesn't offer media-inserted events.
<sjoerd> no, but hal does
<sjoerd> try dbus-monitor --system and replug your card.. Should give a lot of output
<bronson_> nothing.
<sjoerd> that's odd
<sjoerd> what does replugging the whole device do ?
<bronson_> erm, that's going to be somewhat difficult...  gotta get the screwdriver.
<bronson_> Plugging an unrelated USB device showed a bunch of stuff.
<bronson_> Is there any way of getting hal to tell us what it's polling?
<sjoerd> it polls stuff with storage.media_check_enabled = true
<sjoerd> bronson_: btw if sda1 == /dev/cf, then what is sda ?
<bronson_> Something just broke.  I can't run lshal anymore.  I'm going to get rid of my udev rule, mv ~/.* dotfiles/ and reboot.
<sjoerd> bronson_: is your hal process D ?
<mxpxpod> who can I talk to to get pbbuttonsd and powerprefs updated to where debian is?
<bronson_> It appears that using the home directory from my old debian system is causing some trouble.
<mdz> mxpxpod: https://bugzilla.ubuntu.com/show_bug.cgi?id=3785
<bronson_> mxpxpod: https://bugzilla.ubuntu.com/show_bug.cgi?id=3785
<mdz> bronson_: :-)
<bronson_> Jinx 12345678910
<mdz> mxpxpod: there are instructions there so that you can help review the merge, which is the work which needs to be done
<mdz> mxpxpod: for powerprefs, it should be synched soon
<mxpxpod> mdz: cool
<mdz> no merge necessary
<mxpxpod> mdz: well, the new powerprefs needs the new pbbuttonsd
* Kamion mutters in the general direction of libparted
<mdz> Kamion: what's your feeling on the proposal to seed totem, rather than totem-gstreamer?
<Kamion> it would make a lot of user problems go away, I suspect; you'd have to seed both totem and totem-gstreamer to make it unambiguous of course
<Kamion> but you've caught me just before going out
<mdz> if we seed both totem and totem-gstreamer, it defeats the purpose
<seb128> Kamion: totem = totem-gstreamer | totem-xine 
<seb128> we can't seed both, they conflict
<Kamion> uh-huh, but how's germinate supposed to know which you want?
<mdz> the one in main
<Kamion> I guess it can randomly pick the first but that seems a bit unstable
<seb128> Kamion: the first in the | ?
<Kamion> mdz: er ... that's circular, germinate defines main
* mdz runs around in circles
<Kamion> seb128: yeah, I think it does that anyway
<Kamion> it just feels ambiguous to me :)
<mdz> me too
<Kamion> anyway, I'm going out for now
<seb128> better solution ?
<seb128> have a good evening Kamion :)
<mdz> the ideal solution is to have the ubuntu-meta packages use Recommends rather than Depends
<Kamion> lamont: I know about the various parted-related build failures BTW
<bronson> Wow that was scary.  My home dir just vanished.  Mount showed nothing out of the ordinary, df -h showed normal usage, but /home was empty.
<bronson> Banged on reset, booted to single, and everything appears OK agian.
<bronson> I'm erasing all my dotfiles and starting afresh.
<bluefoxicy> does anyone know what compiler options ubuntu is built with?
<pasc> bronson: ?
<bronson> pasc: yo
<pasc> bronson:  /block/sda/sda1 ?
* pasc scrolls all the way up, and finds out it was just typo
<lamont> Kamion: do I just need to give-back d-i?
<mdz> bluefoxicy: it's in the FAQ
<mvo> hey mdz
<mdz> mvo: hi
<mvo> I got a replay from daniel burrows today. he said he may have time to work on apt-secure support for aptitude in feb/march 
<mvo> he's working on his thesis right now
<bluefoxicy> mvo: http://www.ubuntulinux.org/support/documentation/faq/optimised-packages is not sufficient information.
<mdz> mvo: ok, so I guess we'll need to do it
<bluefoxicy> err
<bluefoxicy> mdz, not mvo
<mvo> mdz: all right, I'll have a look
<bluefoxicy> I'm on amd64, and I use (aside from proper -march) "-O2 -pipe -ftracer  -fweb -funit-at-a-time -fomit-frame-pointer -mfpmath=387 -mno-sse" (Gentoo, gcc 3.4)
<bluefoxicy> I'm curious about what optimizations are used aside from just optimizing for a specific CPU
<mdz> -O2
<bluefoxicy> k
<mdz> lamont: ping
<bluefoxicy> -fweb and -funit come from -O3, but I avoid -O3 due to the way it interacts with stack smash protection (it optimizes the protection out)
<bluefoxicy> hmm
<bluefoxicy> "A comprehensive experiment to evaluate the effectiveness of more aggressive processor optimisations for all Ubuntu packages is planned after the Warty release."
<lamont> mdz: yo
<bluefoxicy> I'm interested in detailed results from this experiment
<lamont> mdz: actually, the only flag we force is -pipe
<lamont> and we allow -O0 through -O3
<lamont> -O6 will get you -O3
<lamont> -march=486 -mcpu=pentium4
<bluefoxicy> ah
<mdz> lamont: Debian policy is -O2
<mdz> and we inherit that
<lamont> mdz: unless the package overrides that
<lamont> we don't force that
<lamont> broke too many things.
<bluefoxicy> lamont: Lorenzo has been working on altering the debian tools and such to allow building things with stack smash protection, among other things, to produce a more secure distro.  Much of this is suitable for general consumption (i.e. suitable for Ubuntu), but requires some extra considerations
<bluefoxicy> for example, -O3 will still break SSP AFAIK
<bluefoxicy> (it optimizes away the code that checks for buffer overflows)
<mdz> lamont: right
<bluefoxicy> lamont:  in the future, would it be possible to force -O2 on -O3 packages if Ubuntu had taken such enhancements as SSP?
<mdz> I've updated the FAQ entry to be a bit more specific in that regard
<mdz> bluefoxicy: it would be inadvisable
<mdz> oh, you mean force it down to -O2 if the package tries to use -O3?
<mdz> yes, that would be possible
<bluefoxicy> yes
<mdz> very little builds with -O3, though, and where it does, it's probably the right choice
<trulux> hey guys
<bluefoxicy> hey
<bluefoxicy> mdz, lamont:  this is the guy that's been working on the modified debian tools
<trulux> bluefoxicy, i'm doing some jobs with the libssp, give me a few minutes to make a debian sarge-ready pkg
<trulux> and provide some more stuff
<bluefoxicy> ok
<trulux> the rest of things are done and ready
<lamont> trulux: does it handle both up and down stack growth checking?
<bluefoxicy> trulux:  as a proof of concept, a glibc package should be workable, but if you can get libssp up in a timely manner, that's good :)
<lamont> that's been a shortfall of many of the stacksmash checks...
<bluefoxicy> lamont:  http://www.trl.ibm.com/projects/security/ssp/main.html
<lamont> bluefoxicy: trivial to force -O3 to turn into -O2
<Sturzflut> it does not support that
<bluefoxicy> lamont:  *nod*
<bluefoxicy> I must go now
<bluefoxicy> being called out.
<trulux> bluefoxicy, timely manner means less than 20/30 minutes? sure ;D
<Sturzflut> like you have on hppa
<bluefoxicy> side note
<lamont> the only wierdness there is that (for purposes of checking) -Os is treated identicallyo -O2
<bluefoxicy> growing up is a trivial issue security wise
<bluefoxicy> since stack smashes can't affect important data in *most* (there ARE CASES!) cases
<trulux> lamont, i'm have some patches for GCC that would be nice to be used inside ubuntu gcc packages
<bluefoxicy> at least, to my understanding.
<Sturzflut> stacks that grow up can't overwrite the return address can they?
<lamont> bluefoxicy: buffers in the current frame passed to a function that then overruns the buffer will result in arbitrary return points from the called function
<lamont> that is, it's not really any different from the stack growing down.
<Sturzflut> actually, I guess you could
<Sturzflut> lamont: do you have access to such hardware?
<lamont> Sturzflut: I've only ever written two exploits for hppa, overwritting the stack with code and rp.
<lamont> Sturzflut: have hardware
<Sturzflut> I don't think the SSP patch does hppa yet but I could be wrong about that
<lamont> I'm also aware of a case where hp-ux was exploited writing only the return pointer, not executing code from the stack... (they found a useful chunk of code already in place...)
<Sturzflut> right
<lamont> Sturzflut: of course, that's not an ubuntu discussion.  yet... :-)
<Sturzflut> heh
<Sturzflut> I would think Ubuntu would focus where the money is first :)
<lamont> both exploits I wrote were in response to R&D labs saying "no one could exploit that vul"
<lamont> the first one took me about 3 hours, since I wrote some tools.  The second one took about an hour.
<lamont> Sturzflut: that's a low blow... :[)
<Sturzflut> that's why you should never say never
<lamont> :-)
<lamont> yeah - the discussion then went "but you have an exceptional knowledge of the architecture" to which I replied, "yes, that's why it only took me an hour - remember that the folks writing the attacks have _NOTHING_BETTER_TO_DO_.."
<lamont> "oh".
<Sturzflut> ha
<Sturzflut> SSP is a good idea for things like IRC and IM clients
<lamont> then they got mad when I wouldn't give them the exploit code.
<Sturzflut> since they seem to have lots of exploits :)
<|trey|> Hey, who deals with site accounts?  I don't recall my password, but its saying the account is not valid, however is saying that it does exist... lunitik@gmail.com, if possible, please send me my account info...
<Sturzflut> and for many daemons too
<lamont> Sturzflut: yeah.  shoddy coding is the real issue.
<mdz> seb128: gnome-volume-manager just crashed on me after a hal/dbus upgrade; is this a new bug, or did the old one get un-fixed?
<Sturzflut> the only cure for bad programmers is a pink slip, but that doesn't work for OSS
<seb128> mdz: old one not fixed imho
<mdz> oh, I thought that bug was fixed back in Warty
<lamont> Sturzflut: actually, embarassment helps more with OSS.
<Sturzflut> I think I agree with that
<|trey|> No one can help with the site issue?
<lamont> |trey|: I can't remember which person is the vicitm for site issues...
<|trey|> s/the/my/
<Sturzflut> I wish Debian had more focus on security than they have now
<Sturzflut> they seem to be too focused on dealying sarge release
<lamont> but if my guess is correct, he should be around in a couple of hours or so...
<lamont> or do you mean bugzilla?
<Sturzflut> delaying
<|trey|> lamont: ugh... are you able to look through the accounts and send a request for info at least?
<Mithrandir> Sturzflut: that's a holdup which is due to a small number of people being able to do the magic needed for the freeze to start.
<Sturzflut> Mithrandir: the security stuff, isn't it?
<Sturzflut> security infrastructure
<|trey|> lamont: like I said, when I request, it says the account isn't valid... but when I try to re-sign up, it says the account already exists... what would the issue be do you think?
<Sturzflut> Mithrandir: the DPL should get the whip going, imho
<|trey|> lamont: I will be leaving soon... I suppose I could wait till later...
<Mithrandir> Sturzflut: I'm not sure, it's both the security infrastructure and the autobuilders for testing-proposed-updates.. I know a lot of people would just like to release as soon as possible, even without security support in place for testing.
<lamont> |trey|: I have no admin access
<Sturzflut> Mithrandir: I don't understand why those with access haven't delegated these tasks to the willing
<bluefoxicy> <lamont> bluefoxicy: buffers in the current frame passed to a function that then overruns the buffer will result in arbitrary return points from the called function
<bluefoxicy> lamont:  true, I said it was less likely, not impossible
<bluefoxicy> lamont:  protection is possible though, by guarding functions that are passed char* pointers.  I don't think SSP does this; but I'll ask etoh
<Sturzflut> if it's possible, it will be done
<bluefoxicy> (once one function is not passed a pointer to a buffer, no further called function can get that buffer, unless it's stored in a global variable, which is already brainfuck)
<bluefoxicy> <trulux> bluefoxicy, timely manner means less than 20/30 minutes? sure ;D
<bluefoxicy> trulux:  I meant more like within the next few weeks but the next few minutes is good too  :D
<trulux> bluefoxicy, libssp is done
<trulux> gcc needs to be recompiled, and here i can talk a bit to ubuntu devs if they are proud ;-)
<lamont> trulux: "if they are proud"?
<trulux> it's just a joke
<trulux> lamont, in order to use the SSP first you must decided what to changem the glibc, the libgcc or use a libssp
<trulux> libgcc is crappy
<Sturzflut> heh
<trulux> ssp inside glibc has some advantages, better performance and also backwards compatibility if you change to libssp
<Sturzflut> __guard symbols used for SSP can be in three places
<trulux> libssp has some advantages like more soft implementation and easier use
<trulux> stuNNed, yep
<Sturzflut> the default for the protector patch is inside of libgcc
<trulux> oops, nick autocompletion
<trulux> Sturzflut, yes
<Sturzflut> libc is best place for it
<lamont> ah, ok
<Sturzflut> having it in libgcc can cause problems
<trulux> lamont, but make it inside glibc is difficult if maintainers are not "open" for this stuff
<trulux> Sturzflut, s/can/will/
<Sturzflut> heh, but glibc is already a bloated mass, I don't see why one more thing is going to hurt :)
<trulux> yep
<trulux> Sturzflut, pappy said one thing that is truth and important: think before doing things
<Sturzflut> they should add addition fixes to glibc too
<trulux> imagine we used ssp inside libgcc since the project start, now we could be fscked up
<trulux> Sturzflut, i maintain my own glibc with all of that stuff
<Sturzflut> not really, a simple recompile of all packages fixes that
<trulux> hopefully waiting for somebody to test and package it
<Sturzflut> all C packages that got SSP that is
<lamont> trulux: the rules are: (1) never get involved with someone more messed up than you are, (2) think _BEFORE_ you act, and (3) if it shakes the house (and you don't own the house) get permission before doing it.
<Sturzflut> heh
<trulux> lamont, yeah
<Sturzflut> you forgot (4) Always have an exit plan
<Sturzflut> when the ship goes down, I won't be on it
<trulux> and also the 5) Ignore the rest of rules and disappear
<lamont> Sturzflut: s/exit/backup/
<trulux> &) if you can't disappear just change your name into something else more difficult to guess: Dead Beef
<trulux> :)
<Sturzflut> naw, I really did mean exit plan
<lamont> heh
<Sturzflut> applies to the corporate world well
<Sturzflut> when you see things are about to go bad, give yourself a bonus and retire :)
<trulux> http://www.research.ibm.com/vali/
<trulux> Sturzflut, that's for my regression tests suite
<Sturzflut> Vali sounded familiar, but I don't think I've seen that project before :)
* lamont must run for a bit.
<bluefoxicy> well I must go to spanish class
<trulux> bluefoxicy, suerte ;-)
<bluefoxicy> If possible, i'd love to see a developer's release of Hoary (before public release time, not side by side ;) that has SSP in it so that I can throw it at my laptop and check for regression :)
<bluefoxicy> trulux:  suerte?
<trulux> good luck
<bluefoxicy> ah thanks
<trulux> bluefoxicy, i'm going to add SSP regression test to my rts
<bluefoxicy> trulux:  the regressions I was most worried about are programs that overflow buffers by 2 or 3 bytes (not fatal, but they DO set ssp off) on their own
<bluefoxicy> and things like someone accidentally using -fstack-protector-all instead of -fstack-protector (-all has bugs that break things like Mozilla)
<trulux> i see
<trulux> i can implement that easily in my regression t. suite
<bluefoxicy> not really; it's per-program specific (except the -all one, which if you can find what causes it would be great; etoh could fix it then :)
<trulux> i was meaning about a simple SSP regression test
<trulux> did if SSP is alocated in the toolchain
#ubuntu-devel 2004-12-14
<pitti> night
<mdz> fabbione: I tracked down the stability problem I had with 2.6.9-1; it is unrelated to the UB problem and filed as https://bugzilla.ubuntu.com/show_bug.cgi?id=4332
<mako> so this poor macedonians are having all kinds of trouble with getting these CDs it seems
<mako> the custom officials open the package and see 10 copies of the same cd and just freak out
<jdub> heh
<jdub> mdz: so, we don't have a component for linux 2.6.9 yet
<jdub> mdz: i need inotify kernel headers on the buildds
<mdz> jdub: "linux" should be used for all kernel stuff, generally
<jdub> mdz: should i make a new component, linux-source...?
<jdub> ah, okay
<mdz> jdub: you do not need kernel headers on the buildds
<trulux> bluefoxicy, ping
<trulux> lamont, hey
<mdz> jdub: whatever it is, it shouldn't rely on kernel headers on the build system
<jdub> hrm
<jdub> i don't think it *relies* on them
<jdub> no, has a local header for it
<lamont> jdub: kernel headers should never be included in user space
<lamont> trulux: yo
<jdub> it's okay, it has a local copy
<trulux> lamont, do you the hardened debian project?
<mdz> jdub: perfect
<trulux> lamont, i have some documentation you could find interesting, it's at http://wiki.debian-hardened.org/Main_Page
<lamont> trulux: I think I may have heard something about it
<lamont> will look at the docs
<trulux> lamont, fine
<trulux> lamont, what job/activy are you taking at Ubuntu?
* trulux has finished the libssp, but still debian package fails building, needs further checking
<lamont> trulux: I'm the buildd and general fix-broken-things guy
<trulux> lamont, great, if you want i can send you now the tarball with the 0.2 revision, but don't distribute it yet, use it for yur own fun, we will release it after we do some docs and also clean some of the ssp.c routines
<lamont> trulux: you going to be in mataro?
<trulux> lamont, i think not :( i want to, but i'm 15 years old and it's difficult to say "hey, i'm going to matar, i take my lapto and a few money, see you soon!"
<lamont> yeah - that could be a bit of a challenge... :-)
<trulux> lamont, yep :(
<trulux> lamont, i was in another con with my father, he just left me alone when i was in it, i've the presentation of hardened debian there
<trulux> (undercon 8th edition)
<trulux> it's the spanish version of the defcon, our hackmeeting is more about political and philosphical terms, the undercon is only about the stuff we work on ;-)
<trulux> lamont, i can dcc you the tarball, do you want it?
<trulux> i must go to sleep
<trulux> too late here
<lamont> no dcc here.
<trulux> lamont, let me upload them in a sec
<lamont> I won't get any chance to look at it until at least mataro
<lamont> but wouldn't mind having a copy to look through if I manage to make time for it.
<trulux> lamont, ok
<trulux> i'm uploading it
<trulux> done
<lamont> to where?
<trulux> lamont, http://lorenzo.debian-hardened.org/debhard/libssp-0.2.tar.gz
<trulux> there ;-)
<trulux> now i must go to sleep
<trulux> hope talk to you tomorrow
<trulux> good night!
<lamont> later
<Sturzflut> it's still beta code
<lamont> yeah
* bluefoxicy back from school
<tseng> bluefoxicy: public away sucks
<Sturzflut> yep
<Sturzflut> it's homosexual!
<tseng> well, blue is
<tseng> but ill leave him be before he starts ranting here too
<bluefoxicy> tseng:  someone pinged me
<Astharot> good evening
<tseng> wait a second, Sturzflut trulux and blue?
<tseng> are you guys trolling up hardened debian again
<Sturzflut> no :)
<Sturzflut> no official support from me :)
<bluefoxicy> tseng: I dragged trulux in here to discuss the potential to add -fstack-protector to ubuntu :)
<bluefoxicy> since he claims to be close on that
<tseng> ok
<tseng> id discourage any of the build-by-default patches
<bluefoxicy> he's a smart kid; him, flut, and lv have together managed to put the ssp symbols into an external library
<tseng> is that working?
<bluefoxicy> I have no idea
<Sturzflut> tseng: it works
<tseng> it was giving duplicates when in libgcc
<Sturzflut> I think I'm the first person to actually try it :)
<bluefoxicy> tseng:  build-by-default I like
<mirak> I got a problem, I can't install grub
<mirak> anymore
<tseng> bluefoxicy: it doesnt fit outside of gentoo
<bluefoxicy> tseng:  There's a specs patch that gets the specs from the environment variable GCC_SPECS
<bluefoxicy> tigger^ wrote it
<mirak> it says stage1 is corrupted
<bluefoxicy> trulux is adding that to hardened debian's GCC
<Sturzflut> that's what I'm using now
<tseng> yes, that is still not it
<Sturzflut> gcc profiles would be nice
<tseng> do you guys have a channel we could go to
<bluefoxicy> tseng:  vanilla specs can be "default," but the debian maintainer's tools can default to a hardened spec
<bluefoxicy> tseng:  #debian-hardened
<tseng> thanks
<lamont> *(^()*_(^+*^  metacity
<lamont> when &*%)%^*( mplayer goes into a loop popping up error boxes, it becomes very problematic to kill it, since it )*&%*^_%*(^%*(^*&  steals focus.
<lamont> give me my damn NEVER *&)%*^_(^ STEAL FOCUS option, please
<lamont> hrm... seb128 probably wasn't here for that venting...
<lamont> jdub?
<jdub> yo
<Mithrandir> lamont: C-A-F1 ; pkill mplayer
<lamont> Mithrandir: if it didn't steal focus, I wouldn't have to bounce out to a vty
<Mithrandir> lamont: true enough
<jdub> lamont: things have to break before they get better :)
<jdub> lamont: file bugs in bugzilla.gnome.org
<lamont> jdub: thanks
* Mithrandir wonders why DMA seems not to be enabled when reading from the DVD
* Mithrandir turns it on, and CPU load drops immediately.
<jdub> lamont: the focus stealing stuff has been in devel for a while now
<jdub> lamont: but is only turned back on during devel branch :)
<lamont> jdub: they've been doing lots of work to make it smart about when it steals.  All I want is an option that says "never steal focus from the current window".
<jdub> in many cases it doesn't
<jdub> if you've found a stupid case where it does
<jdub> that should be fixed
<jdub> if that option is there, it will never be fixed
<jdub> ask me to tell you about the window button switcher horrors sometime :)
<Fubar> hello
<Fubar> how is ubuntu coming along ? :)
<lamont> jdub: yeah, all I want is the 'be stupid' option
<jdub> lamont: otherwise known as the "never actually fix the problem" option :)
<lamont> jdub: when I run an xterm from inside another window, who's to say that I _WANT_ it to take focus.  In fact, I have a case or 3 where I specifically _DON'T_ want focus given to the child window.
<lamont> and there is _NO_WAY_ for metacity to know what I'm currently thinking.
<lamont> so it's not "never fix the problem", it's "quit trying to read my )*&%*&^P mind"
<jdub> lamont: depends on your activity in the former window
<lamont> no.
<jdub> heh
<lamont> in the use case in question, I just ran a script.
<lamont> it launches 12 xterms.
<lamont> I want focus to stay in the current window
<lamont> because I'm not done there
<jdub> so if you're not done, and there is activity, hooray for doing the right thing
<jdub> also, xterm makes life harder
<jdub> so perhaps things that don't grok the standards can be special cased
<mdz> Kamion: I don't suppose you're still around
<jdub> there are lots of options here beyond reading your mind
<lamont> did I mention the sleep 1 after each of the 12 xterm launches?
<jdub> you need to write down the use case so someone has a chance of analysing it
<lamont> I _WANT_ focus to be under the mouse. period.
<lamont> if I _WANT_ it somewhere else, I want to have to move the mouse.
<lamont> that use case is specifically and diametrically opposed to metacity's current design
<jdub> dude, people have said the same thing about "I _WANT_ the window switcher button applet to be X pixels wide!"
<lamont> window switcher button applet?
<jdub> suddenly, when it "just works", they stop complaining because they don't even realise there's a problem
<jdub> 10:03 < lamont> that use case is specifically and diametrically opposed to
<jdub>                 metacity's current design
<jdub> ^ "current behaviour"
<jdub> that's why we fix things to just work
<jdub> if you don't provide use cases, that can't happen
<jdub> if we keep making options so we don't have to actually fix the software, that can't happne
<lamont> I guess the real issue is that I fail to see that it's a problem. :-)
<jdub> sure, the answer might end up being, "we don't believe this use case is important" or "we can't deal with that when you're using xterm"
<jdub> dude
<jdub> you have a problem with the current behaviour
<jdub> that is what we're talking about
<jdub> if it weren't a problem, you wouldn't raise it
<lamont> I meant I have some difficulty understanding why stealing focus is actually _solving_ a problem.
<jdub> dude
<jdub> the whole point of the work being done on metacity is "focus stealing avoidance"
<lamont> jdub: which is based fundamentally on the decision that stealing focus is a good thing (under the right circumstances)
<jdub> yes, absolutley
<jdub> when i run an application
<jdub> i expect to be able to type into it
<jdub> without changing the focus
<jdub> however, when i run an application and am still doing things elsewhere,
<lamont> so my read of it is "we've decided to break things in the general case because we think this is a neat feature, and now we're going to special case the hell out of things for where we have to agree that it's a bad thing"
<jdub> i don't really want it stealing the focus
<jdub> no
<lamont> ah, therein lies the difference.
<lamont> when I run an application, I expect to move the mouse into that window before I type.
<lamont> That's why I have FOCUS=MOUSE.
<jdub> okay, so imagine you have a bug in a piece of software
<jdub> like ls
<jdub> it works under strace
<jdub> but never works on its own
<jdub> so you decide that it's easier for people to run it in strace
<jdub> instead of fixing the bug
<jdub> when it comes to behavioural bugs
<lamont> jdub: I decided that it's easier for _ME_ to run it that way.
<jdub> it is better to fix the problem than provide an option to 'unbreak me'
<lamont> the whole thing is about letting the user _DECIDE_ how he wants it to behave/
<lamont> and I can'
<lamont> t
<jdub> oh man
<jdub> right
<jdub> now i have to tell you about the window switcher buttons
<jdub> during the gnome 2.0 development process
<jdub> all the options for the window list were removed
<jdub> and work began on making it 'just work'
<jdub> there was a massive, massive flamewar
<jdub> because people used the options to make it work correctly
<lamont> I can see that
<jdub> in various use cases
<jdub> after about two months
<jdub> the flamewar died down
<jdub> this was before there was a general understanding of how to do 'just works' development
<jdub> so no one actually realised that it had improved to such an extent that it did the right thing
<jdub> and wasn't punching them in the face
<jdub> so they didn't think to complain
<jdub> so if the focus issues in metacity are punching you in the face,
<jdub> you need to explain your use cases
<jdub> so they can be taken into account
<lamont> right.
<jdub> even if you think they're totally impossible to handle
<lamont> my use case is 15? years of having whatever window is under the mouse be the one that has focus.  period.
<lamont> yeah - it's not what the new user wants.  But it's what my brain is trained to.
<lamont> and hands
<jdub> because seriously, those window list option removals made "using gnome impossible" for so many people... until it just worked.
<jdub> lamont: i'm not going to solve your problem, but consider a change in behaviour in sloppy focus mode.
<lamont> so when an app pops up a window and that suddenly has focus clear across the screen until I either (1) leave and reenter the current window, or (2) left click, then it messes with my head
<jdub> lamont: this is not impossible.
<jdub> if you think it's impossible, your brain is closed to clever ways to fix it.
<lamont> jdub: I still move the mouse across the screen to the (now focused) window.
<sivang> jdub,lamont : what bug# are you discussing?
<lamont> I expect that with time, I'll untrain 15 years of training, but that's a productivity pain in the meantime
<jdub> there's no bug#
<jdub> lamont: i don't think you're listening. :)
<lamont> sivang: the bug is that I expect focus to remain under the mouse at all times, and metacity is being smart.
<jdub> no dude
<jdub> that's not the bug
<lamont> jdub: you're saying that metacity could/should be taught to better understand when it should move focus to the new window.  I understand that.
<sivang> jdub : Oh, you mean where ever you put the moust there should be the focus set?
<jdub> by explaining it that way, you're ignoring behaviour
<lamont> sivang: that's how I've operated since X10.
<lamont> jdub: OK.  metacity should better understand when it should not move focus to the new window.
<eruin> you guys ever tried rightclicking the desktop, opening a terminal, then doing the same thing again?
<eruin> none of the windows have focus.
<lamont> eruin: under metacity, the last terminal launched has focus
<eruin> the first terminal gets focus, but when you open the second one - none of them get it
<lamont> not here
<jdub> the terminal is not getting focus here
<jdub> only when i move the mouse over it
<eruin> mine doesn't get focus until I click it
* lamont hasn't quite upgraded the desktop machine (this one) to hoary.  That's inplan for tonight
<jdub> lamont: ... so you're talking about warty's metacity?
<lamont> jdub: is the second phrasing more consistant with what you want me to say?
<lamont> yeah
<jdub> sheeeeesh
<jdub> dude
<lamont> jdub: but either way....
<jdub> no
<jdub> not either wya
<lamont> When metacity should better understand when it should not move focus to the new window? never. (my use case)
<jdub> it is specifically not enabled in warty's metacity
<lamont> huh???
<lamont> it==??
<jdub> the focus stealing prevention changes
<lamont> ok.  I'll bitch after I upgrade.
<eruin> what metacity should do (imo anyway) is give focus to user-opened windows by default, _unless_ the user started using another window while the opened window was still being opened
<mirak> anyone know where I can find the 2.6.8 kernel that was used before beeing updated ?
<lamont> (apt-get -udy dist-upgrade finally finished... that is to say, the local mirror finally came current.)
<mdz> mirak: there never was a 2.6.8 in Ubuntu; we started with 2.6.8.1
<mirak> it was updated with dis-upgrade but I have troubles with it
<mirak> mdz, 2.6.8.1 yes
<mirak> mdz, 2.6.8.1-3
<Fubar> question for ubuntu developers:  Does Ubuntu have any plans to coordinate issues with the hardware manufacturers if they provide their own drivers? 
<eruin> I'm sure I saw my 2.6.8.1-kernel get upgraded last week or so
<mdz> Fubar: yes
<mirak> mdz, it was just changed two days ago
<mirak> I need the old version
<mirak> lilo can't boot the new one, and I have problems with grub
<Fubar> mdz:  See i had an issue for my video system, and im not sure if its an x or driver bug 
<mdz> mirak: unless you're on sparc, it hasn't had any significant changes since 2004-11-02
<mirak> mdz, or I could use warty 2.6.8
<eruin> well there be an athlon(xp)-specific kernel or is that pointless (ie there wouldn't be any gain from k7)
<eruin> will*
<mirak> mdz, it was updated two days ago
<Fubar> mdz:  i reported it and daniel thought it was due to the video card drivers... 
<mdz> mirak: <mdz> mirak: unless you're on sparc, it hasn't had any significant changes since 2004-11-02
<Fubar> said he was making changes to upstream
<Fubar> but that there was nothing he could do
<mirak> mdz, significant dosn't mean no change
<Fubar> so all these issues i take it go back into the system to see if they can be fixed later on right ?
<mirak> mdz, I told you it was dist upgraded two days ago
<mdz> mirak: for i386, it was a recompile
<mdz> zero code changes
<mirak> mdz, then something changed
<mirak> I don't know what
<Fubar> ubuntu very nice on balance for linux distro
<mirak> maybe some options where changed
<mdz> probably an issue with your initrd; this really isn't the place to discuss it
<mirak> mdz, if you don't use lilo you probably not noticed it
<mirak> why not
<mdz>  /topic
<mirak> i didn't got another answer than reinstall the system
<eruin> is there a mailing list I could follow to know things like why nvidia 6629 isn't in restricted yet, etc?
<mirak> on #ubuntu
<mdz> eruin: ubuntu-devel
<eruin> cheers
<mirak> mdz, I just need to know what changed that's all
<mdz> mirak: I've told you, and you don't believe me
<Mithrandir> eruin: it has issues; stability among them, iirc.
<mdz> there is nothing more I can do to help you
<mirak> mdz, the initrd problem ?
<mirak> pfff
<mira1> mdz: ok, I managed to boot with lilo
<mira1> I don't exactly what make it work
<mira1> I have increased the ramdisk size option, used text mode for lilo and reduced frame buffer resolution
<mira1> what's the best bet ? :)
<sivang> btw, has anyone seen the segfault with unmounting fs when power off? this happens to me every time I shutdown both on hoary in the laptop and the desktop machine.
<eruin> would using offical nvidia packages be problematic in hoary?
<eruin> sivang: yes, i get that too
<eruin> or rather "egmentation fault" <-- cute ;)
<eruin> started happening pretty recently
<sivang> eruin : yeah, hehe,  on my desktop it somehow shuts down the HD and restart it about 2 times before actually managing to shutdown
<jdub> sivang: #4333?
<sivang> jdub : checking :)
<eruin> looks the same
<eruin> I get a message about "none busy" before the segfault, and no "/ is busy" though
<jdub> might want to add a comment saying it's happening in ubuntu too
<Mithrandir> is it possible to get gnome to always save the configuration when logging out?
<sivang> jdub : exactly.
<jdub> Mithrandir: gnome-session-properties
<Mithrandir> ah, great.
<Mithrandir> now I just need to clean up a bit and this will be all happiness
<jdub> also, gnome-session-save --gui
<jdub> run that from the applications menu
<jdub> when you're set up nicely
<lamont> jdub: so what all am I breaking with this upgrade, anyway?
<sivang> jdub : when choosing "save settings on logout" that also saves sessino settings right? at least it did on sarge..
<eruin> that saves nicely here
<jdub> yes it does
<jdub> lamont: to hoary? not a huge amount
<jdub> lamont: i don't imagine you use evo :)
<lamont> what's that?
<lamont> :-)
<jdub> heh
<sivang> evo has become more stable the past couple of days,
* lamont runs to a fire call
<sivang> however mutt supersedes it alot
<eruin> right, off to upgrade nvidia.. I might just be back ;)
<mirak> ok, the problem was probably the menu mode in lilo
<sivang> jdub : btw, just wanted to tell you - hoary is superbo in this machine ever since I remaoved hal , as just disabling the media detection option did not always work. :) it's plain pleasure at 1400x1050
<jdub> sivang: try installing the new version
<sivang> jdub : on the latest upgrade?
<jdub> yeah
<jdub> 0.4.2
<sivang> jfub : k, I'll check, is there comments on the bug fix somwhere? our bugzilla/gnome's ?
<sladen> sivang: you removed hal?!
<jdub> sivang: see the changelog
<sivang> sladen : yes :) But I have already installed 0.4.2 by now :)
<sivang> jdub : let's see if this works this time on single IDE busses machines..:)
* Mithrandir ponders switching from openbox to metacity, this time making it act properly.
<Mithrandir> does metacity do emacs-style chains of shortcuts?
<Mithrandir> So C-M-p leftarrow grows to the left, while C-M-p rightarrow grows to the right?
<eruin> 6111: glxgears~2100.. 6629: glxgears~2600 :D
<srbaker> yo
* lamont reboots for the maximum hoary-experience
<lamont> istr the old metacity actually dropping windows back in the correct workspace...
<lamont> or am I misremembering?
<Mithrandir> it did
<lamont>   dimensions:    1792x1344 pixels (361x271 millimeters) at 126 dpi.  just plain strange.
* lamont bbiab
<bluefoxicy> anyone know if you need to put in your phone number to shipit?
<mdz> some shipping companies require it
<mdz> you won't get phone calls from us, that's certain
* bluefoxicy didn't put his phone number in, someone else is asking if he has to
<bluefoxicy> mdz:  do you know if shipping to the US requires it?
<mdz> bluefoxicy: no, I don't
<bluefoxicy> will updating the info update previous orders that weren't yet shipped?
<mdz> if it's required, I imagine mako would have shipit reject requests which didn't include a phone number
<bluefoxicy> k
<bluefoxicy> well it didn't reject me but of course can't track individual order status
<bluefoxicy> any ideas how long this is gonna take to ship?  I ordered yesterday, rough estimate or 'We do 'em in fixed size batches and you're qued"?
<jdub> calc: nice blog entry. :)
<calc> :)
<calc> i think i annoyed some kde people reading planetkde ;)
<calc> it was the top headline on there for over 12hr
<bluefoxicy> can I see?  :P
<calc> http://www.cheney.cx/site/blog/
<bluefoxicy> heh
<bluefoxicy> I want to see a desktop environment like MediaPortal
<bluefoxicy> i.e. it takes over your screen XD
<mdz> bluefoxicy: they're done in batches of course, but I'm fairly sure the batches include some padding, so I really can't say
<bluefoxicy> i just think it'd be neat to have windows docked every which way
<bluefoxicy> mdz:  ok
<mdz> my order (queued before the Warty release) arrived this week
<bluefoxicy> so, month or two?
<mdz> I can't say
<calc> i got mine last week also
<bluefoxicy> when hoary comes out I should talk to my college and show them a warty live cd
<bluefoxicy> and ask them if they want to hand them out free
<bluefoxicy> if they say yes I'mma order 1000 :P
<bluefoxicy> (of hoary)
<bluefoxicy> I wonder if they'd actually ship them, or if they'd reject the order, or contact me and ask wtf
<calc> heh
<bluefoxicy> "1000?!  DUDE we do this FREE >:("  ". . but my college said they'd hand them out. . . "  " o_o  oh, nm then"
<bluefoxicy> of course
<bluefoxicy> the CDs are very pretty
<bluefoxicy> so you'd get people thinking it was AOL 10.0
<bluefoxicy> and they'd try to install it
<mdz> we will ask for confirmation if you request a huge number of CDs
<bluefoxicy> and call AOL, complaining that AOL erased their hard disks
<mdz> some people do it just to see what will happen
<bluefoxicy> mdz:  to prevent against typos and. . yeah, and idiots :P
<bluefoxicy> dun worry
<bluefoxicy> I ordered ~20 because I figured it'd be within limits of "Shipping costs more than the CDs so order a lot"
<bluefoxicy> I'll try to hand them out though
<bluefoxicy> if they vanish I'm ordering more next time; if I can get a school or college to hand 'em out I might make a fairly large order
<tseng> i asked our lug coordinator to get a batch
<tseng> since it still seems to be open
<bluefoxicy> but I'm not ordering excess I don't think I can get distributed.
<calc> sets in low quantity are about $1-2/ea hopefully they are getting discount
<bluefoxicy> calc:  hopefully they can get tax breaks for it
<calc> they have no profit to tax break for do they? ;)
<bluefoxicy> eh.
<bluefoxicy> I thought canonical was a for-profit organizatoin
<mdz> correct
<calc> hmm maybe so, i didn't see anything that would make them money though
<mdz> it's explained on the website
<mdz> on the front page, even
<bluefoxicy> well
<bluefoxicy> they're for profit
<bluefoxicy> which means they either make money, or they die.
<bluefoxicy> you don't stay around for-profit and not make profit
<bluefoxicy> then again, I'm fairly business minded
<bluefoxicy> but I'm fairly certain that businesses that are created to make money don't stay long if they lose money . . .
<bluefoxicy> anyway
<calc> on the front page of the canonical site?
<jdub> calc: yes
<jdub> calc: support and professional services
<calc> ah ok :)
* calc bbl
<bluefoxicy> http://www.ubuntulinux.org/support/documentation/usn/usn-1-1  does this relate to http://www.us-cert.gov/cas/techalerts/TA04-217A.html (which included an exploitable buffer overflow CAN-2004-0597)?
<lamont> pornview now segv's.  such a pitty
<fabbione> morning guys
<lamont> morning fabbione 
<lamont> fabbione: why does pornview segv on hoary/xorg?
<fabbione> lamont: dunno.. i actually need to change the fan on server cpu and probably i will crash again because i still don't feel too good today
<lamont> heh
<fabbione> but today is tha last chance to get it fixed
<fabbione> otherwise it will have to stay in degraded mode until i am not back from mataro
<fabbione> bbl
<fabbione> re
<Treenaks> wb
<fabbione> let's hope this one will last
<fabbione> let's give a big spin to the cpu
* ironwolf crosses fingers for fabbione
* Treenaks goes to work -- back in 1 hour
<Treenaks> stupid bus :)
<mdz> lamont: mail received, good luck
<mdz> fabbione: when do you leave for Spain?
<fabbione> mdz: sunday afternoon
<fabbione> i should be in Mataro around 19:45 local time
<fabbione> mdz: did you test the kernel?
<fabbione> i didn't see anything from you in my inbox
<fabbione> mdz: is there anything urgent you need me to do before coming down?
<fabbione> i am still not sure i can handle an entire day
<mdz> fabbione: take it easy, you don't want to travel ill
<mdz> rest if you need it
<fabbione> mdz: yeah i know..
<fabbione> it
<fabbione> it's just that i get bored as hell in bed
<mdz> fabbione: I mentioned to you on here that I tracked down the problem I was having
<fabbione> and now i have wireless at home :-)
<mdz> fabbione: it was unrelated to the UB problem
<mdz> but is a regression from 2.6.8.1
<fabbione> mdz: i don't read irc backlog
<fabbione> mdz: what problem is that?
<mdz> fabbione: https://bugzilla.ubuntu.com/show_bug.cgi?id=4332
<fabbione> mdz: cool... nice track down
<stuNNed> re
<fabbione> mdz: i have usb here and i can give it a shot
<fabbione> it might be strictly driver related, because i didn't notice it
<mdz> happens to me with my DVD writer
<mdz> happens to the upstream bug reporter with a camera
<mdz> I'm using ehci_hcd
<fabbione> i have a usb harddisk
<fabbione> ahhh no
<fabbione> i am using "usb1"
<fabbione> the other driver
<mdz> uhci_hcd?
<fabbione> yeah i think it's called that way
<fabbione> i will give it a shot on the other box where i have usb2
<fabbione> and see how it goes
<mdz> you may need to plug it in a couple of times
<mdz> it happens to me i I turn it on and then off
<fabbione> ok
<mdz> that guy's camera probably isn't usb2
<mako> bluefoxicy, mdz: shipping everywhere is *better* with the phone number. high priority orders do, at nominally, require numbers
<fabbione> mdz: i will check later
<fabbione> right now i am stressing the server cpu to see if it crashes
<fabbione> i need to be sure that fucker can survive 15 days without me
<fabbione> bah
<fabbione> now.. 2 fan in serial + 2 in parallel
<fabbione> if that's not enough to cool down that cpu, i really have no idea what to do
<pitti> fabbione: do you happen to have an USB stick?
<fabbione> pitti: no. i gave mine to Mithrandir 
<fabbione> i have a usb harddisk
<pitti> fabbione: kernel 2.6.9 now doesn't produce sda1 devices any more, but uba1 (e. g. )
<fabbione> yes we knoe
<fabbione> know
<pitti> fabbione: in general this works fine, but I cannot do mkfs.vfat on them any more
<pitti> fabbione: it says "cannot determine disk geometry"
<pitti> fabbione: does that happen with your usb hd as well?
<fabbione> pitti: and i am not going to make mkfs.vfat on that harddisk
<pitti> fabbione: no spare partition? Okay :-)
<fabbione> pitti: we know that there are bugs in usb with 2.6.9
<pitti> fabbione: worth filing a bug?
<fabbione> mdz tracked down one of them
<fabbione> pitti: no. they are already in kernel bugzilla
<pitti> okay
<fabbione> i can do a read only test
<fabbione> that's all i can help with
<fabbione> anyway.. i am back to sleep
<fabbione> i still don't feel too good and i need to recover before Mataro
<Treenaks> fabbione: good luck
<fabbione> thanks Treenaks 
<pitti> Hi Keybuk 
<Keybuk> morning
* sid77 hi!
<Keybuk> seb128: so, Evolution's mail compose window is missing most of its toolbar icons
<Keybuk> is this a known bug?
<seb128> somebody else has reported it
<seb128> and I've no problem here and no idea on the bug atm
<Keybuk> hmm
<Keybuk> http://descent.netsplit.com/~scott/look-no-toolbar.png
<Keybuk> ^ that's what I get
<seb128> http://bugzilla.ubuntu.com/show_bug.cgi?id=4253
<Keybuk> oddness
<Keybuk> looks like a bonoboui bug to me
<seb128> to me too
<seb128> but bonobo* has not changed for a while now
<seb128> Keybuk: you only have this bug since evo 2.1.1 ?
<seb128> the previous libbonoboui upload is almost 3 months old
<Keybuk> yah, noticed it this morning after upgrade
<Keybuk> so probably not bonoboui then :)
<pitti> Hi mvo
<mvo> hi pitti
<seb128> Keybuk: do you have any kind of error in the console ?
<Keybuk> (evolution:5006): Gdk-WARNING **: GdkWindow is too large to allow the use of shape masks or shape regions.
<seb128> weird
<seb128> do you have the composite extension on or something (just try to think on what could be different) ?
<Keybuk> not that I'm aware
<seb128> ok
<seb128> no idea on the problem right now, perhaps a gtk+ problem
<Keybuk> I have "Text beside icons" set
<Keybuk> if it were GTK+, I'd expect it to affect other apps
<Keybuk> or even the evolution main window
<seb128> http://bugzilla.ximian.com/show_bug.cgi?id=68321
<seb128> was a similar issue due to gtk
<Keybuk> in fact, it's *only* the "compose" window too
<Keybuk> all the other evo windows with toolbars work
<seb128> and which resolution are you using ?
<Keybuk> 1024x768
<seb128> no problem in 1024x768 here ...
<seb128> let's package the new gtk+, perhaps it'll fix the problem :p
<Keybuk> maybe
<Keybuk> could be a behaviour-dep
* daniels kicks thom.
<daniels> thom: any chance I could convince you to update your dbus packages with the current packaging?
<pitti> jdub: inotify rocks!!!
<Treenaks> is there an inotify kernel somewhere in ubuntu then?
<pitti> Treenaks: 2.6.9-1, yes
* Treenaks upgrades :)
<pitti> Let's thank fabbione  for this wonderful piece of work
<Treenaks> he's asleep, trying to get better before mataro
<jdub> pitti: :-)
<pitti> Treenaks: the kernel has bitten him seriously, I'm afraid
<Treenaks> still
<Treenaks> hm
<Treenaks> apt tells me restricted-modules is not available yet?
<jdub> pitti: you might like this bug
<jdub> https://bugzilla.ubuntu.com/show_bug.cgi?id=4270
<daniels> Treenaks: no, i did it for 2.6.8.1 (along with a few patches to linux-source), so i got landed it for 2.6.9.  looking at it now, just waiting for bandwidth to be freed up again.
<Treenaks> daniels: ah ok
<pitti> jdub: how ugly...
<Treenaks> daniels: same with the "dummy package that always depends on the latest version" stuff?
<fabbione> daniels: what do you mean you are doing -2 with the asm stuff?
<daniels> fabbione: remember how I told you that we needed to ship asm-*, not just asm-$(ARCH)?
<daniels> fabbione: and gave you the updated find stuff
<daniels> fabbione: i can't upload l-r-m until that's in
<fabbione> daniels: yes i remember, but hold on a sec
<daniels> ok
<fabbione> are you modifying debian/post-install ?
<fabbione> daniels: ?
<daniels> yes
<daniels> so it grabs asm-* rather than asm-{generic,$(ARCH)}
<fabbione> what else do you have in the changelog?
<daniels> right now, nothing
<daniels> but might be grabbing a patch to fix futex hangs
<Kamion> how much of a size increase is there to grabbing asm-*?
<fabbione> i think i did add something about futex...
<fabbione> daniels: i have some other changes pending.. like including the last 2 patches you gave to me
<daniels> Kamion: a reasonable amount, I'd imagine
<fabbione> daniels: and possibly changing one config option about USB_BLK_DEV
<daniels> Kamion: (how many people have l-h installed tho?)
<Kamion> daniels: it's on the CD
<Kamion> (hence why I care)
<fabbione> daniels: in any case 2.6.9 won't be the default kernel for a while
<daniels> Kamion: so, um, between all the architectures and flavours -- a lot
<Kamion> fabbione: uh ... the installer has already switched
<fabbione> Kamion: it has a bunch of regressions that we need to sort out first
<fabbione> usb storage is basically foobar
<jdub> fabbione: if it's not default, it won't be tested
<daniels> Kamion: i'll tell you when I have debs built
<fabbione> jdub: please agree with mdz on this, not with me
<Kamion> fabbione: oh. does that mean that my attempts to make USB installations work now are toast?
<fabbione> jdub: he decided so.. not me
<fabbione> Kamion: possibly
<Kamion> fabbione: or does it depend on my hardware?
<fabbione> Kamion: it depends what driver your hardware needs
<fabbione> Kamion: mdz has problems with ehci_whatevername
<fabbione> and he is not the only one
<Kamion> oh, so maybe USB 1.1 is OK
<fabbione> probably uhci is working fine
<carlos> seb128: ping
<fabbione> daniels: if we ship asm-* for kernel-headers, wouldn't be possible to make it arch: all? or do we still need some arch specific bits in it?
<daniels> i suppose we could have linux-headers-2.6.9-1-asm as arch:all
<daniels> Kamion: out of curiousity, why's it on the cd?
<Kamion> daniels: so people can build third-party modules they need to access the network
<daniels> Kamion: ahr
<Kamion> it's for convenience; it's been quite popular
<fabbione> hmmmm
<elmo> I thought l-k-h had arch specific stuff that was generated at build time?
<fabbione> elmo: that's what we need to check
<daniels> elmo: talking about lh, not lkh
<daniels> but yes, that's what I'm looking at now, is whether asm-* gets stomped on at build-time
<daniels> istr asm-* being safely arch:all, but linux/ being specific
<Kamion> linux/ contains stuff like config.h
<daniels> right
<elmo> a tar.gz of asm* is only 3Mb - is that a big deal?
<fabbione> daniels: it would require a bunch of changes
<daniels> fabbione: go on
<daniels> elmo: ah, that's pretty good
<fabbione> daniels: yes i am checking...
<fabbione> linux-headers-2.6.9-1 contains asm-generic
<fabbione> and all the common files for linux-headers-2.6.9-1-$flavour
<daniels> so we could presumably shuffle asm-* into there
<fabbione> linux-headers-2.6.9-1-$flavour contains the specific $flavour bits
<fabbione> with symlinks to linux-headers-2.6.9-1
<Kamion> elmo: not bad
<fabbione> hmmm no
<fabbione> just a second...
<daniels> fabbione: if you don't want 1642, i'm going to close it
<fabbione> lrwxr-xr-x root/root         0 2004-12-01 17:57:11 ./usr/src/linux-headers-2.6.9-1-686/include/asm-i386 -> ../../linux-headers-2.6.9-1/inc
<fabbione> daniels: you can include all the asm into linux-headers-2.6.9-1
<fabbione> and create the proper symlinks in linux-headers-2.6.9-1-$flavour
<fabbione> that would increase the package of 1/2MB
<fabbione> in only one package
<fabbione> Kamion: would that be acceptable?
<daniels> fabbione: that's what I'm suggesting
<fabbione> daniels: sorry.. i understood that you were going to stick them into -$flavour
<fabbione> daniels: since they are $flavour indipendent it's ok with me
<fabbione> size wise too
<Kamion> fabbione: as far as CD size goes, sure, haven't really thought about the rest
<Kamion> although I might hold you down in Mataro until you find 2MB of savings elsewhere :-)
<fabbione> daniels: let's make -2 with only that change and please show me an interdiff before you upload (since for a few weeks i will be the kernel maintainer)
<fabbione> Kamion: ehhehe this is only thanks to that r3str1ct3d-m0dul35
<daniels> fabbione: do you want me to do the two modules as well?
<daniels> after all, i did them for .8.1 ...
<fabbione> daniels: no because i have them merged here already
<fabbione> daniels: and i want to prepare a -3 with other stuff too once we are in mataro
<daniels> if you say so
<Kamion> lamont: nah, I need to upload another debian-installer to fix that it seems :(
<daniels> fabbione: btw, I don't think we get enough information out of xorg
<daniels> to do configure
<Kamion> too ... many ... revision ... control ... repositories
<fabbione> daniels: uhm?
<daniels> fabbione: to do configuration with X -configure
<daniels> i don't think it gives us enough information
<Kamion> elmo: can I have iso-scan and load-iso in main? need them for bootable USB installation; seeding now
<fabbione> daniels: probably not, but you can still cross check some of the results to see which one appears to be better
<daniels> fabbione: like, it won't give us DDC results
<daniels> DDC/panel data/whatever
<jdub> Kamion: have you looked at the skole SNS stuff much?
<Kamion> jdub: SNS?
<fabbione> daniels: we should ask people to give it a shot in mataro
<fabbione> daniels: and collect logs and results
<elmo> Kamion: python-parted was rendered uninstallable by the promotion of the experimental parted, btw
<elmo> kamion: done
<Kamion> elmo: yeah, I know, it's one of the things I'm looking at today
<Kamion> there's a bunch of ABI change stuff :(
<elmo> ok, cool
<Kamion> elmo: thanks
<Kamion> elmo: needs source changes in fact :-/
<jdub> Kamion: skole network setup or whatever
<Kamion> jdub: no ... I thought pretty much all of Skole was in d-i though
<jdub> Kamion: their changes to d-i to do automated network/server/client setups
<elmo> kamion: ah, not so cool
<Kamion> if I know Joey, that's going to be a big preseed file. :-)
<Kamion> elmo: shouldn't be hard, but ... sigh
<Matt|> jdub, just got another random /proc unmount
<doko> elmo: I'm unable to reproduce #4147 and #4141 anymore on current hoary. the tclsh doesn't segfault anymore. requeue for build?
<elmo> no
<elmo> it's very reproduceable on the buildds last I checked
<elmo> I'll check again
<doko> thanks, maybe #4141 as well, which is ok for me as well.
<Matt|> jdub, is it ok if I file a bug for this /proc and /home unmounting thing?
<jdub> Matt|: there's a bug already
<Matt|> jdub, i can't find it
<Matt|> jdub, you know the #?
<elmo> /bin/sh: line 1: 27764 Segmentation fault      tclsh ./www/lang.tcl >lang.html
<elmo> make[1] : *** [lang.html]  Error 139
<jdub> Matt|: #4300
<Matt|> jdub, oh. i figured that couldn't be it :)
<Matt|> ok yeah that's it
<Matt|> thanks
<robtaylor> carlos: do you want to schedule a time to talk about accessd in mataro, or should we play it by ear?
<carlos> robtaylor: I don't know how will I have my schedule
<carlos> robtaylor: I suppose it will be better the second week
<robtaylor> carlos: well, i'm only there from 9th to 13th. on the 10th i have LiveCD and debian-women bof, but apart from that not much..
<carlos> hmm
<robtaylor> also, who else would be intersted?
<carlos> robtaylor: will try to give you an answer on Monday, after we do some plans about the work there, ok?
<robtaylor> carlos: ok :) np
<robtaylor> i've been making up some diagrams to show possible modes of use, its slow going tho =)
<carlos> robtaylor: ok
<eruin> latest mount fixes #4333?
<eruin> nm
<Kamion> elmo: python-parted patch written, but it's an API change so I'm contacting upstream first
<maswan> Mithrandir: Ok, doing a new install test with a random daily amd64 iso. It suddenly became a priority to get a disk free.
<elmo> god damn it, it's segfaulting on exit
<fabbione> elmo: what is segfaulting?
<elmo> #4141, #4147
<fabbione> amen
<fabbione> si bhe
<fabbione> ops
* lamont grumbles about plumbing, stalls before preparing to meet his day
* maswan grumbles about no disks available in that either and tries another way of getting a newer kernel than 2.6.5 onto that host
<fabbione> hey lamont
<fabbione> lamont: are you in a hurry?
<lamont> fabbione: I have about -3 minutes.
<lamont> sup?
<lamont> fabbione: I'll poke my nose back in before I leave, but will be gone before the hour, probably for 4-5 hours or more.
* lamont must deal with some plumbing this morning.
<lamont> back in a few, then gone - feel free to spew here or in private.
<fabbione> lamont: ok nothing important
<fabbione> i found a little bug in the env_cmnd feature
<fabbione> but generally it is working
<elmo> doko: okay, so in fact it is reproduceable both in hoary _and_ Debian unstable, however, I strongly suspect it's like the gzip bug, and you need to be running a 2.6 kernel on an SMP box to be able to reproduce
<doko> hmm, sorry I don't have a SMP box, but I'm running a smp kernel on a P4.
<elmo> doko: you can use macaroni
<doko> elmo: would prefer tagliatelle, but for now I take what I can get ;)
<elmo> http://www.siec.k12.in.us/~west/proj/penguins/mac.html
<fabbione> doko: lol
<fabbione> doko: but it's macCheroni
<doko> fabbione: welcome to make you happy :)
<haggai> daniels: just tried an dist-upgrade from warty to hoary and lost resolution on my LCD panel.  Do you want anything else in the bug report other than Xorg.log & xorg.conf?
<fabbione> elmo: after my honeymoon  i will send you pictures of me swimming with the galapagos penguin :P
<fabbione> haggai: do you happen to have Horiz and VertSync entries in xorg.conf?
<haggai> fabbione: no
<haggai> (II) SAVAGE(0): Generic Monitor: Using default hsync range of 28.00-33.00 kHz
<fabbione> haggai: open a bug with both xorg and xfree86 config and logs
<haggai> (II) SAVAGE(0): Generic Monitor: Using default vrefresh range of 43.00-72.00 Hz
<haggai> fabbione: ok thanks
<fabbione> haggai: please make it a blocker bug
<fabbione> or major
<haggai> fabbione: ok
<fabbione> haggai: as a temp workaround please use the usual dpkg-reconfigure xorg
<fabbione> hem
<fabbione> dpkg-reconfigure xserver-xorg
<lamont> fabbione: what's the bug?
<fabbione> lamont: in the specific case:
<fabbione> my normal env_cmnd = something
<fabbione> because it needs to override for all packages
<fabbione> for the package specific foo, i don't need the override
<fabbione> so either is '' or something else that disable the override
<lamont> and you want to specify a blank for the specific package
<fabbione> exactly
<lamont> bummer. :-)
<fabbione> lamont: really.. it's a detail
<lamont> =":;"  works?
<fabbione> lamont: hmm i dunno.. i will check at the next kernel upload
<fabbione> but just that you know :-)
<lamont> fabbione: it won't.
<lamont> oh. that's evil.
<lamont> "sh -c" might work.
<fabbione> lamont: i think the point is "use external cmd_env if external cmd_env"
<lamont> " " should work too.
<fabbione> lamont: eheheh ok
<lamont> fabbione: all the config variables are equally broken.
<fabbione> lamont: hmm interesting
<lamont> see also buildd's handling of $should_build_msgs :-(
<lamont> anyway, I'm gone for a while.
<fabbione> later
<gicmo_> heya everybody
<seb128> jdub: ping ?
<jdub> pong
<seb128> do you think that the pixbuf engine should be in libgtk2.0-0 ? or should we create a gtk2-engines-pixbuf ?
<jdub> seb128: don't we already have a gtk2-engines-pixbuf?
<seb128> jdub: gtk 2.5.6 includes the engine, you don't suggest to drop if from the package, do you ?
<jdub> seb128: replace the engine pacakge, surely?
<seb128> hum
<seb128> I'm not clear
* gicmo is tired
<jdub> seb128: the pixbuf engine has moved from gtk-engines to gtk itself
<seb128> /usr/lib/gtk-2.0/2.4.0/engines/libpixmap.so was in gtk2-engines-pixbuf from gtk2-engines
<seb128> it's in gtk+2.0 now
<jdub> so shouldn't gtk just build the gtk2-engines-pixbuf package now?
<seb128> the question is: do we want to include the .so in libgtk2.0-0 which replaces/conflicts/provides gtk2-engines-pixbuf ?
<seb128> or do we want to create a binary gtk2-engines-pixbuf in gtk+2.0 for it ?
<jdub> the latter
<seb128> ok, I think so
<azeem> slashdot reports IBM wants to sell the PC/notebook division
<seb128> but still good to have a second opinion
<seb128> thanks jdub 
<jdub> azeem: interesting
<zul> did they say why
<azeem> http://www.nytimes.com/2004/12/03/technology/03ibm.html?ex=1259816400&en=c60a66b7afa86173&ei=5090&partner=rssuserland
<jdub> they should sell it to sun
<jdub> that would confuse the crap out of everyone
<zul> yeah i would be living a nightmare...thanks
<Treenaks> jdub: what about sco
<zul> even worse
<azeem> Treenaks: uhm, it costs 2 Billion or so
<azeem> I don't think SCO has that much money left
<Treenaks> azeem: hm.. wait
<daniels> haggai: oops.  yes, please.
<daniels> haggai: xorg.0.log+xorg.conf+lspci+lspci -n
<jdub> seb128: btw, where are all the silly XDG and GNOME environment variables set in our gnome?
<elmo> oh dear Lord, the SF bug tracker is HORRIBLE
<seb128> jdub: I don't think so, but we use the standard paths so we don't need to set them
<Kamion> elmo: isn't it just
<jdub> seb128: even for gnome-menus?
<seb128> I've tried to find a gaim bug yesterday, no way
<seb128> jdub: works fine here yes
<daniels> elmo: the patch tracker's even worse
<jdub> cool
<jdub> nice to avoid that damage
<jdub> i couldn't think where they'd be set ;)
<daniels> jdub: /etc/profile?
<jdub> daniels: ick
<daniels> Kamion: 
<daniels> COPTS+= -DAH_BYTE_ORDER=AH_BIG_ENDIAN -DAH_REGOPS_FUNC
<daniels> COPTS+= -mbig-endian
<daniels> COPTS+= -msoft-float -ffixed-r2
<daniels> do those make sense on power*?
<Kamion> hm, I aggressively avoid remembering which endianness my processor is
<Kamion> but yes, Linux/powerpc is big-endian
<Kamion> -msoft-float is valid though I'm not quite sure why you'd use it; bug avoidance?
<Kamion> -ffixed-r2 is valid in theory but I've no idea what effect it has
<daniels> it's apparently only been tested on some ibm machine
<Kamion> RS/6000s and Macs shouldn't differ at that kind of level
<Kamion> where is this, anyway?
<Kamion> l-r-m?
<daniels> madwifi, yah
<Kamion> daniels: ah, yes, you definitely want -msoft-float then
<Kamion> (no fp in the kernel)
<Kamion> sounds plausible at least
<daniels> cool
<daniels> dear s3 savage driver,
<daniels> you are a total piece of crap.
<daniels> warm regards,
<daniels> daniel
<haggai> heh
<daniels> i see the problem
<haggai> yeah?  I see the wierd message in the log
<haggai> (II) SAVAGE(0): Not using mode "1024x768" (no mode of this name)
<daniels> (--) SAVAGE(0): 1024x768 TFT LCD panel detected and active
<daniels> (--) SAVAGE(0): - Limiting video mode to 1024x768
<daniels> (II) SAVAGE(0): Generic Monitor: Using default hsync range of 28.00-33.00 kHz
<daniels> (II) SAVAGE(0): Generic Monitor: Using default vrefresh range of 43.00-72.00 Hz
* daniels applauds.
<haggai> ooh that's a bit tight
<daniels> basically, it's going 'let me use some crappy range that won't fail on any moonitor ever, despite the fact I should be pulling this stuff out of the BIOS'
<daniels> so, if you dump HorizSync/VertRefresh from XF86Config-4 into xorg.conf, it should Just Work
* daniels grabs a small axe and stomps off in the direction of the savage driver.
<daniels>          * Instead, I'll abandon any attempt to automatically limit the
<daniels>          * clock, and add an LCDClock option to XF86Config.  Some day,
<daniels>          * I should come back to this.
<haggai> daniels: yeah, adding those two back in worked
<daniels> *sigh*
<daniels> haggai: could you please grab http://people.ubuntu.com/~daniels/tmp/savage_drv.o, dump it in /usr/X11R6/lib/modules/drivers, start sudo Xorg :1 -ac -novtswitch, ctrl-C the server, and throw me the output of grep 'Detected clock range' /var/log/Xorg.1.log?
<daniels>  * On many machines, the attempt to read DDC information via VBE puts the
<daniels>  * BIOS access into a state which prevents me from reading mode information.
<daniels>  * This is a complete mystery to me.
<daniels> someone needs to get S3 docs.  badly.
<fabbione> elmo: why did you take down the max rsync connections to 15?
<daniels> haggai: does Option "LCDClock" "49" work for you, if you remove HorizSync/VertRefresh?
<haggai> daniels: (II) SAVAGE(0): Detected clock range: 10000-220000
<daniels> haggai: actually, sorry, I misread that -- don't try the LCDClock thing
<elmo> fabbione: beause the load was spiking to 30 and killing the cd sync
<haggai> daniels: ok
<fabbione> elmo: ah ok...
<elmo> doko: dumped some more info in 4141.. just noticed you weren't cc'ed
<daniels> oh god, s3 got bought out by via.
* robtaylor watches the s3 codebase go rapidly downhill
<daniels> haggai: i'll mail s3 devrel about it, but i'm not expecting much good.  i'll probably end up massively kludging it.
<haggai> daniels: ok.  Thanks for the help.  I'll be at the con from Sun so you can play with it then, if it would help :)
<jdub> BEER FOR HAGGAI
<jdub> i'm glad spanish beer is cheap and good
<jdub> :)
<fabbione> jdub: oh yeah. you will have to offer quite a lot around.. oh btw,.. speaking of inotify....
<fabbione> ;)
<jdub> haha :-)
<jdub> fabbione: but you are unwell :)
* jdub is also unwell, so won't be drinking too much beer
<daniels> haggai: yeah, I'll check it out :)  itmt, I've emailed s3 devrel, so we'll see how it goes.  worst case is that we just kludge a sensible set of sync ranges in if we detect an LCD.
<fabbione> jdub: true... we will see during the week
<daniels> SANGRIA
<jdub> daniels: mmm
<haggai> jdub: oooh :) lots please :D
* sjoerd thinks he's gonna see a lot of drunk developers next week
<tseng> nothing more fun that a wasted daniels 
* kylem disagrees with tseng.
<daniels> elmo: could I please get linux-headers-2.6.9-1-* on concordia?
<tseng> ive never heard more interesting ways to string together obscenities
<daniels> i'm honoured :P
<sjoerd> sivang: your friend with the toy laptop, was that a dell thing ?
<sivang> sjoerd : yes dude :)
<sjoerd> sivang: the new hal packages should automagically hanlde those (by not polling)
<sivang> sjoerd : I've installed the new one (0.4.2) as jdub adviced , it seems to be ok 
<elmo> daniels: done
<sjoerd> cool
<daniels> elmo: cheers
<sivang> sjoerd : I am going to test it some more with playing cds and using cd simultanesously accessing the hd, and then I'll close the bug
<doko> elmo: thanks, subscribed
<sivang> sjoerd : what seemed to be the problem with it? I mean, what did it do that caused the HD to slow so bad?
<sjoerd> sivang: the problem is not solved (it's hw), but it's automagically worked around now
* thom wonders why daniels was kicking him
<sivang> sjoerd : ok, is the workaround complicated to explain in few words? Or use the source  ? :)
<sjoerd> it's an entry in the default fdi that sets storage.media_check_enabled to false on that specific drive model
<sjoerd> see /usr/share/hal/fdi/20freedesktop/ide-drives.fdi
<sivang> sjoerd : ah I See, so now when I insert a media nothing happens automatically?
<sjoerd> correct
<jdub> Keybuk: proposed panel menu changes mail on u-d
<Kamion> DAMNIT
<Kamion> is anyone going to have a spare USB stick with them in Mataro that I could borrow for a bit?
<bob2> yup
<Kamion> Open Firmware really isn't interested in talking to this one, for some unknown reason
<Kamion> ah, that'd be great, thanks
<Kamion> might be able to get USB installations on powerpc going then
<Mithrandir> Kamion: sure, yes
<Mithrandir> my x40 won't boot off it, though
<Kamion> lamont: any clue why none of the buildds seem to have tried debian-installer 20041118ubuntu6 yet?
<daniels> Kamion: yeah, you can have mine
<Kamion> maybe out of three I have a chance of one that OF will like
<mxpxpod> have any of you had the problems described in bug #4333
<Kamion> mxpxpod: yes, it's fairly common
<mxpxpod> Kamion: any quick fix?
<Kamion> disable udev-mtab I *think*, but check what it does before blindly doing that
<mxpxpod> how do I disable that?
<Kamion> it's an init script ...
* Mithrandir complains about his 2.5Mbyte/sec download speed.. hoary upgrades takes a while..
* daniels stabs Mithrandir.
<mxpxpod> Kamion: so, rm /etc/rcS.d/S36udev-mtab?
<Kamion> mxpxpod: I think so; that'll make it come back at the next upgrade but that's probably what you wanted; by the next upgrade I'd hope it'll be fixed
<Mithrandir> daniels: it's only at about 1.2 now.
<mxpxpod> Kamion: basically, it binds /dev to /.dev and mounts the tmpfs if it's not in /etc/mtab
<Kamion> mxpxpod: right
<mxpxpod> Kamion: but shouldn't the tmpfs be mounted already once udev starts up?
<bob2> Mithrandir: I h8 u.
<Kamion> mxpxpod: that's not the problem; best guess in the bug reports so far is that as the system is shutting down umount unmounts /dev and then gets confused and crashes
<bob2> and trashes mtab?
<Kamion> not sure
* Kamion points to lamont
<mxpxpod> bob2: check out #4333
<Kamion> the other Debian bug linked to from that is a bit more useful; http://bugs.debian.org/283323
<bob2> mxpxpod: am
<Mithrandir> daniels: where's the x40-l33tness package?
<bob2> Mithrandir: ~daniels/x40/
<Mithrandir> why not in hoary?
<mxpxpod> Kamion: ahhh, I get it
<mxpxpod> Kamion: so, I don't get why we need udev-mtab
<Kamion> mxpxpod: I'm still just guessing though
<Kamion> mxpxpod: don't ask me
<mxpxpod> Kamion: the bug you posted confirmed what you said
<Kamion> mxpxpod: I'm assuming it isn't useless because Md is not in the habit of introducing useless things
<mxpxpod> Kamion: Md?
<daniels> Mithrandir: p.d.o/~daniels/x40/, not in hoary because it needs genericness and love
<Kamion> the udev maintainer
<mxpxpod> Kamion: ah, ok
<Mithrandir> daniels: are you going to love it in Mataro?
<mxpxpod> Kamion: check out the last entry on that bug you posted
<mxpxpod> Kamion: doesn't seem to be that big of a deal to disable that script
<Kamion> mxpxpod: I already have. let's not act hastily eh? plenty of time until hoary releases
<mxpxpod> Kamion: hehe
<Kamion> mxpxpod: better: help lamont to find out why umount is segfaulting.
<daniels> Mithrandir: i suspect so
<mxpxpod> Kamion: there we go, that fixed it :)
<lamont> Kamion: I'd love a patch for umount. :-)
* lamont returns with parts, stalls on actually doing plumbing.
<lamont> I hate plumbing
<lamont> Kamion: d-i is d-w libparted1.6-0 - is that related to the partman failures, or will I need to clear the d-w after a d-i upload?
* lamont goes to gather tools and such.
<Kamion> lamont: can that be cleared? I've changed the build-dep to libparted1.6-12
<fabbione> lamont: Log for successful build of linux-source-2.6.9_2.6.9-1 (dist=hoary)
<fabbione> that's thank to the patch :-)
<mako> DUDES!
<mako> i just gave tons of ubuntu cds to eben moglen :)
<mako> evidently, he already had tried an install
<mako> he wants more
<bob2> wooo
<Kamion> mako: heh, dude :)
<bob2> good shit
<mako> jdub: eben moglen <3 ubuntu
<mako> i think he's going to give them to the other law profs at columbia :)
<jdub> mako: oh?
<jdub> mako: that's awesome!
<mako> jdub: yeah, he expressed interest in meeting mark next time he's in the neighborhood.. he's totally into it
<jdub> heh
<jdub> rad
<mdz> morning
<bluefoxicy> lamont:  Plumbing sucks
<bluefoxicy> you loosen the wrong screw, the pipe turns out to be the wrong pipe
<bluefoxicy> and you get a spray of shit in your face
<mako> i think eben moglen is the person who i look up to most in this world.. the fact he's into the project i work on makes me *very* happy
<bluefoxicy> mako:  what project
<mako> he was also concerned by the ibm pc division sale because he was afraid the thinkpad keyboards might start sucking
<mako> bluefoxicy: UBUNTU!
<bluefoxicy> oh
<bluefoxicy> I thought you meant some other project :P
<mako> bluefoxicy: i just got back from his office and i gave him a bunch of cds and he wants more
<bluefoxicy> heh
<bluefoxicy> who is eben moglen?
<bluefoxicy> is it bigger than a breadbox?
<mako> bluefoxicy: prof. of law at columbia university, FSF gen. counsel, author of GPL
<jdub> bluefoxicy: FSF lawyer
<bluefoxicy> ah
<mako> well the legal bits of the GPLv2 at least
<thom> mako: that totally kicks ass
<bob2> basically, eben > you
<mako> eben > me*10000
<mako> eben is all the things i love about RMS without the parts that annoy me
<bluefoxicy> heh
<sladen> jdub: are you the man to talk to about BOFs ?
<jdub> sure
<jdub> mail me
<jdub> on phone atm
<ggi> I'm noticing that if I do, say, 'mv file ~/Desktop', then the file doesn't actually show up as it would if I had used Nautilus to copy it over. Is this a gamin thing?
<sladen> jdub: I'm down to do one about 6hours before I arrive in barcelona, can I rearrange it :)
<sladen> jdub: k
<jdub> heh
<sladen> jdub: I arrive last thing on Tuesday, so I should have woken up by Wednesday afternoon
* mako got a direct flight from new york to barcelona
<mako> i'm amazed they even exist
<mako> but it's someone less than direct back
<thom> mako: you should that's not barcelona, new mexico or something? :P
<mako> thom: no....
<mdz> heh
<thom> uh, s/should/sure
<mako> if it's too good to be true, it probably is
<mako> uh oh
* thom is assuming that there's a town called barcelona somewhere in the US
<mako> i'm *sure* there is
<thom> did you hear about the english OAPs who bought a flight to sydney?
<mako> i didn't even hear what an OAP was
<thom> oh, right. Old Age Pensioner
<mako> alright
<mako> ok
<mako> so no
<thom> so, they were really excited about their cheap flights...
<thom> shame they didn't check *which* sydney they'd bought flights for, because sydney, canada is a touch colder than sydney, australia in december
<mako> haha
<mako> i'm surprised the tickets were that much cheaper
<thom> 7 hours v 24 hours?
<mako> yeah, but it's a small airport.. fine.. you're right :)
* mako does the eben likes ubuntu dance a little more then goes back to work
<lamont> Kamion: cleared
* lamont disappears to do plumbing for a few hours.
<Kamion> lamont: thanks
<mdz> Kamion: regarding 2.6.9, the known bug is probably fairly harmless for the installer, from what we know so far
<mdz> seems to only affect usb-storage at the most
<Kamion> mdz: that might kind of kill installations from USB though. :)
<mdz> Kamion: we don't support those yet anyway, no?
<Kamion>  debian-installer (20041118ubuntu6) hoary; urgency=low
<Kamion>    * Enable hd-media (bootable USB) builds on amd64 and i386.
<mdz> Kamion: please update HoaryGoals
<Kamion> (not that they *work* yet unless you stick an ISO on the hard disk somewhere, but still ...)
<Kamion> mdz: it's not done yet :)
<Kamion> but sure, I'll update it to say in progress
<mdz> Kamion: I've been trying to keep it updated with a vague status
<trulux> hey guys
<trulux> hey lamont
<tseng> mdz: whats the vauge plan on the NX item?
<mdz> tseng: needs to be fleshed out; I think MIthrandir has ideas
<thom> man, NM is super fucked right now
<fabbione> only 199 packages to go for sparc + 5/6 FTBFS and what will queue up in the meantime
<fabbione> but we have a big big big advantage over ia64
<fabbione> we already have a kernel :-)
<jdub> thom: i'm not holding out much hope for NM in hoary
<trulux> hey tseng
<thom> jdub: no
<sladen> jdub: what's missing, functionality, or bugs?
<tseng> stability for one
<jdub> sladen: workingness
<jdub> and sanity
<tseng> it has about a 70% workingness factor here
<tseng> 10% sanity
<jdub> by hoary release, they'll have reimplemented most of the userspace network stack
<tseng> and thats after thom fixed a few things
<sladen> what's the prospects on something expanded around the netapplet stuff;  or forking an earlier (simpler) version of NM and fixing that up
<tseng> the earlier NM you go, the lower the workingness
<jdub> sladen: netapplet's a possibility
<jdub> sladen: if we do something temporary, would prefer to go with it
<sladen> jdub: go with netapplet?
<jdub> thom: was just saying that if we do something temporary, it should probably be a modified netapplet
<thom> agreed
<jdub> without the gtkbutton
<jdub> just make it replace the wifi applet in our current configuration
<jdub> in fact
<thom> i'll have to look at netapplet again soon, it's been a while
<jdub> perhaps we should just commit to that now
<jdub> and watch the NM damage from afar
<mdz> jdub: have you tracked down that odd/scary unmounting problem?
<haggai> is there someone coming to the conference who is bringing a powerpc machine that can build openoffice?  I have a bug to fix
<jdub> mdz: not really
<jdub> mdz: but it seems to be intel driver related, perhaps
<mdz> jdub: e100, e1000 or ipw2200?
<thom> jdub: umount segfault?
<mdz> not that it makes any sense whatsoever for it to be driver-specific
<mdz> I don't think the kernel is unmounting filesystems via a network driver
<thom> it happens on ppc, too
<jdub> thom: no, the "unmount all filesystems when you bring the network down" one
<jdub> 4330 i think
<thom> jdub: ahr, yes
<thom> bob2 was seeing that on ppc
<jdub> i'm using the mjg driver, too
<jdub> ber
<jdub> kernel
<thom> umounting /proc is pretty special
<daniels> yeah
<jdub> it also crashes the system monitor applet
<jdub> (the unmounting of /proc)
<thom> jdub: yep
<thom> and gnome-cpufreq-applet
<mxpxpod> speaking of the system monitor crashing... when I load up gnome for the first time, the system monitor in my panel crashes and asks to be reloaded... then it doesn't have a problem after I reload it
<jdub> mako: around?
<jdub> http://danilo.segan.org/blog/gnome/ubuntu-here.html
<jdub> mako: i want to hide a bunch of fonts with fontconfig, but let them be used as fallbacks for characters
<mako> jdub: hey there
<mako> jdub: the label stuff is nasty
<mako> jdub: our shipping company doesn't allow us to use any non-ascii characters
<mako> jdub: so the way we're guessing has improved but still sucks
<jdub> heh
<mako> i mean, the point is basically to make "correct enough so that it gets there" :)
<mako> jdub: thanks for the pointer, i've replied though
<mako> and emailed danilo
<jdub> cool
<jdub> mako: was actually mostly interested in his l10n/i18n bugs... ;)
<mako> jdub: well me too.. some are low hanging fruit.. some are more problematic
<jdub> "involves OOo" -> problematic :)
<mako> jdub: in the email i said i'd work with him to file and follow-up on the bugs
<mako> yeah, basically
<mako> excellent, i was going to check to see if there was a non-latin input method bof.. and there is! and i'm leading it!
<mako> dude, hoary input is going to *rock*
<jdub> you wanna do iiiiiim?
<mako> we need to someone get iiiiiim to work with dsssssssssl
<jdub> heh
<mako> i need to play with it more.. i've been seeing awesome things with uim lately in gnome
<jdub> there certainly seems to be a lot of uim support
<mako> my non-latin languages (japanese and amharic mostly) basically rock
<jdub> from the various l10n projects
<jdub> the koreans have some nice ones
<mako> *2* amharic input methods(!)
<mdz> whoa
<jdub> they also have a korean dictionary client
<mako> and a tigrinya input method!
<jdub> which they called "gdick"
<mdz> a cloop-compressed ext2 filesystem came out smaller than a cramfs filesystem
<mako> right, i've heard of gdick
<mdz> I guess the block size makes a big difference
<mako> i know enough hindi to input it and see if it's working
<mako> and i *used* to be able to read korean script
<mako> it was only 5-6 years ago so i think i could catch up again
<mako> at least enough to test and such
* mako should hold a "teach mako cyrillic" nightly bof
<mako> i've always wanted to learn and i've heard it's pretty easy
<thom> yeah, i wanna learn cyrillic too
<mako> mark and i could pass notes in class
<mako> thom: i'll bet we could learn in an evening
<mako> a few beers, some cyrillic flashcards
<mako> MY KIND OF PARTY
<jdub> s/beers/vodka kegs/
<thom> it'd have to be vodka and lard, yes
<mako> YES
<mako> DA!
<mako> !
* Treenaks pokes wikipedia for a cyrillic alphabet
<Treenaks> ooh.. they have the Starship Enterprise as a letter: 
<Treenaks> will anyone here be arriving _tomorrow_ instead of Sunday btw?
<thom> Treenaks: i've been here since yesterday
<Treenaks> thom: ah cool
<mako> i arrive sunday at like 7am
<mako> i think that basically counts
<thom> lol
<mako> well actually, timzone wise
<Treenaks> my plane arrives at BCN around 14:30 tomorrow
<mako> it *will* be tomorrow for me
<mako> just like midnight
<jdub> i get in at 1100 on sunday
<Treenaks> ok.. packing bluetooth stuff & GPS unit :)
<thom> oh, and just walk from the train station to the hotel, it's totally easy
<mako> or perhaps, at thom is suggesting, i'm arriving in barcelona new mexico at 7am
<Treenaks> though I doubt they'll let me use the GPS on the plane :)
<Treenaks> thom: I have a printout of the map from the wiki
<thom> mako: *g*
<thom> Treenaks: yeah. 
<mako> either will be warmer than new york
<mako> so i'm ok with that
<thom> FUCKEN. 
<mako> ?!
* thom adds an rsync account for the mataro mirror
<thom> max connections my ass
<sladen> jdub: groovy, ta
<Treenaks> mako: how long before ksp-mataro.txt is available?
* Treenaks won't have access to a printer after tomorrow :(
<Treenaks> or after tonight, rather
<zul> how come
<Treenaks> zul: i don't have a printer at home, and I'm going to my parents tonight
<zul> ah
<Treenaks> zul: and my plane leaves tomorrow around noon
<thom> Treenaks: there's a printer here, if you trust it
<Treenaks> thom: I can eyeball-compare my screen to my printout.. and verify the md5 of the one on my screen
<Treenaks> thom: or is that considered "insecure" ?
<Treenaks> (I've only done "small" keysignings, with 2-3 persons at at time..)
<mako> i meant: 
<Treenaks> oh well, I'll Find a Way
<Treenaks> mako: and what about stuff like: 
<mako> me needs to remember to type  instead of ?! or !? (or, in suppose  and  )
<mako> the interrobang is a *great* invention
<mdz> seb128, jdub: my trash and mixer applets segfault every time I log in.  is this known?
<seb128> no
<thom> mako: giggle
<Treenaks> mako: is it easily composable?
<jdub> mdz: haven't seen it
<mdz> seb128: do you want a stack trace?
<Treenaks> mako: without editing /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose
<seb128> mdz: yes please
<mako> Treenaks: not in the input method i duse.. it is if you know the unicode codepoint :)
<seb128> mdz: since when do you have this ? 
<mako> there is also the venerable: 
<mako> when space is an issue but *really* can't afford two glyphs
<mako> and it's not just a question, but REALLY a question
<mdz_> seb128: correction, it's not segfaulting
<mdz_> I get a "The panel encountered a problem whil loading "OAFIID:...TrashApplet".  Details: Failed to resolve, or extend "!prefs_key=//apps/panel/profiles/default/applets/trashapplet/prefs;background=none;orient=up;size=x-small;locked_down=false
<mdz_> "Do you want to delete the applet from your configuration?
<Treenaks> mako: what about the ever-popular ,  and 
<Treenaks> mako: I mean.. for all those times you want to talk about communism being deadly and/or nuclear..
<mdz_> seb128: and for the mixer, the same but with prefs_key=/apps/panel/prefiles/default/applets/applet_2/prefs;background=none;orient=down;size=x-small;locked_down=false
<mdz> seb128: this started about two days ago, but I had not logged out for some time before that I don't think
<seb128> mdz: and if you add the applets after the login, does it work ?
<mdz> seb128: I don't see them in the "add to panel" menu
<mdz> neither trash nor mixer
<seb128> do you have gnome-applets installed ?
<mdz> er
<mdz> no, I don't
<mdz> how did that happen?
<seb128> libgtop2-4 -> libgtop2-5 transition perhaps
<seb128> perhaps you dist-upgraded before getting gnome-applets built
<mdz> it's possible
<mdz> mvo: we need to get that logging feature into apt
<mdz> seb128: thanks for the clue bat
<seb128> np
<mvo> mdz: great, I'm all for it :)
<mdz> mvo: though when I think about adding new features to apt, I start to think about Smart :-)
<mdz> mvo: I don't suppose we can get Gustavo to come to Mataro
<thom> guys, anything we want mirrored on the server here? (warty+hoary already coming down the wire)
<mvo> mdz: I still haven't seen any code :(
<mvo> mdz: we might. do you think we could sponsor his flight and all? I can ask him :)
<mvo> he is concered about the amount of package we support though. it will probably not scale (yet) to the 16000 packages in debian (or universe)
<mvo> I need to leave now and play some hockey ... (I'll be back in ~2h)
<Kamion> thom: releases.ubuntu.com, current daily
<thom> Kamion: nod
<thom> Smart?
<IRCMonkey___> Hi sorry to bother you
<IRCMonkey___> to change mkboot config on floppy
<IRCMonkey___> I edit /mnt/floppy/lilo.conf then do lilo -C /mnt/floppy/lilo.conf ?
<IRCMonkey___> sorry to ask here but nobody answer me on #ubuntu 
<IRCMonkey___> good way or not ?
<carlos> fabbione: are you working on a sparc port for Ubuntu?
<carlos> fabbione: I got a question about Ubuntu for Sparc in ubuntu-es mailing list
<carlos> fabbione: could I redirect it to you?
<mdz> carlos: yes, he is working on it
<carlos> ok, I'm going to forward this guy to fabbione then.
<fabbione> carlos: re
<carlos> fabbione: hi
<fabbione> carlos: what is the question?
<carlos> fabbione: He just asked for a sparc port
<carlos> perhaps he wants to help you
<fabbione> carlos: we are working on it...
<fabbione> carlos: any help will be appreciated as soon as some packages will enter the archive to test the installer
<fabbione> carlos: right now there is not much that they can do without being able to bootstrap a hoary chroot on sparc
<carlos> ok
<carlos> fabbione: perhaps a Debian installation ...
<fabbione> carlos: no.. trust me.. he needs a hoary chroot at this point in time
<fabbione> i am almost done rebuilding hoary on top of hoary
<carlos> ok
<fabbione> carlos: basically once i am done with it (probably less than a week)
<fabbione> carlos: the packages can enter the archive
<fabbione> carlos: Kamion can start germinating around them
<fabbione> carlos: and create the seeds
<fabbione> after that only 2/3 packages need a fast fix
<fabbione> and we can start testing the installer
<carlos> fabbione: are we going to support it from Canonical? (just my own curiosity)
<fabbione> no
<fabbione> this is an unofficial poer
<fabbione> port
<carlos> ok
<trulux> hey lamont 
<trulux> lamont, what's the plan for the conference in Matar?
<zul> fabbione: i have hardware that can help
<zul> or have i mentioned that before :)
<sladen> fabbione: sledge has a 5-way sparc box
<haggai> sladen: I think I saw that box going to Kinnison on Sunday
<gicmo_> sladen, ! (I am getting on your nerves, do I)
<Treenaks> *phew*.. just in time 
* Treenaks pets his bottle of printer refill ink
<mdz> jdub: which bit of GNOME has shit itself when I'm stuck with a window-resizing mouse cursor and can't switch focus?
<mdz> also no mouse events work
<mdz> though the keyboard does
<Treenaks> mdz: something grabbed it
<mdz> yeah, workrave I tihnk
<Treenaks> try killing the grabbing app
<mdz> already did
<mdz> at least, I killed workrave, which is what seemed to have grabbed it
<Treenaks> kill the wm?
<mdz> tried it
<mdz> also gnome-settings-daemon and bonobo-activation for good measure
<mdz> killing the panel has gotten me focus back
<mdz> it seemed to be stuck at the "this applet just died" dialog
<mdz> but the mouse is still unresponsive
<mdz> guess I'll need to log out
<mako> keys for the keysigning anyone
<mako> anyone, anyone
<Treenaks> mako: will there be one before the planned one on friday?
<mako> Treenaks: there will be more ad-hoc keysignings all throughout
<edulix> hey!
<mako> edulix: hey!
<edulix> here someone having real problems with grub and warty... instrad of a grub menu, I get a grub prompt "grub >". what could it be mako ? :)
#ubuntu-devel 2004-12-15
<enrico> www.gocc.gov.  Tell ${limi} that they may have a problem with the default settings for the page footer :)
<Matt|> Is there a problem with the Nimbus Roman font? There is no bold option, and also I have got appalling performance from the pdf converter in OOo. Does anyone know anything about this?
<Matt|> example is here: http://mdke.mine.nu/images/pdf_problems.png
<Matt|> might that be related to #3138?
<Matt|> if anyone has any advice on this I would really appreciate a /msg or /memo. Thanks X
<Matt|> nite
<sm> hi all
<sm> I'm having trouble getting /dev/cdrom symlinks working.. have searched bugzilla
<sm> I had to add ide-cd to /etc/modules, since I upgraded from debian
<sm> so the hd device is there.. tried restarting udev.. but cannot get cdrom symlinks nohow
<sm> any ideas ?
<jdub> sm: one for #ubuntu i think
<sm> no luck there
<sm> ok
<fabbione> morning guys
<Rene_S> Close enough
<stuNNed> evolution doesn't have d/l public key from keyserver like moz-thunderbird has
* lamont declares victory over plumbing.  bed time
<fabbione> eheh
<fabbione> night lamont
<lamont> fabbione: it does feel good to be triumphant, you know. :-)
<fabbione> lamont: oh yeah
<fabbione> i discovered that i am very good at painting jobs
<fabbione> but i suck at plumbing
<lamont> painting is much more fun
<fabbione> i will win that too one day :-9
* lamont used to do that professionally
<fabbione> well it depends...
<fabbione> the preparation of the walls is a royal pain
<lamont> houses and such.
<fabbione> but i am good at that too
<lamont> what sort of prep?
<fabbione> spartling i think is the english name
<fabbione> put up the filt
<fabbione> refiller
<fabbione> sandpapering
<fabbione> all that kind of things before paiting
<lamont> "slinging mud."
<lamont> or "taping"
<fabbione> eheh
<lamont> that's not too bad.
<fabbione> nah it just takes a lot of time mostly due to the drying time
<fabbione> between each different thing
<lamont> but it does get boring.  Of course, if you know the right tricks, you can fill nails in 1 coat, sand, and be done with that.  Much better than 2-3 coats...
<lamont> yeah.  lots of drying time.
<fabbione> yeah i know.. but i don't know the tricks..
<fabbione> so it's like all doubled
<lamont> first time we painted our house, my wife was very fabbergasted that my idea of prepping a room to paint was throwing a drop cloth on the floor.  no taping off windows or anything.  really perplexed her.
<fabbione> + the house is quite old and the walls are really uneven
<lamont> I've just found it's less work if I just don't put paint on the windows.
<fabbione> ahha
<lamont> ask me in mataro, and I'll tell you how to patch stuff faster.
<fabbione> i use a big piece of paper for the floor
<fabbione> sure i will
<lamont> I need visual aids for this one..
<lamont> :-)
* lamont is part italian, you see.. :)
<fabbione> but i still tape the windows because they are brand new :-)
<fabbione> ahhaa
<fabbione> we had to change the old ones because the wood was rotten
<lamont> fabbione: taping windows takes too much _work_..  But then,  keeping paint off of them does require some practice first...
<fabbione> lamont: yeah.. or to be very fast with a wet cloth
* lamont gets great joy out of drawing a straight edge with a paint brush.
<lamont> night for real.
<Matt|> hi guys. I've had some problems with the nimbus roman font. When converting it to pdf in openoffice it comes out really badly. example is here: http://mdke.mine.nu/images/pdf_problems.png Does anyone have any advice?
<amu> Matt|: if you print the file, it looks also bad?
<Matt|> amu, not sure
<Matt|> amu, i don't have a printer
<Matt|> :(
<amu> if you change your desktop fonts to nimbus, the look in a same way compared to the doc?  
<amu> s/the/they
<Matt|> not really: the problem with the doc is the inconsistency
<Matt|> there is something weird about the nimbus font in ubuntu
<Matt|> there is also no bold of that font
<amu> Matt|: what hapen if you change the font to an bitstream?
<Matt|> amu, lemme try it
<Matt|> amu, it seems reasonable
<amu> the font's at your desktop are the bitstream, and they look fine?   
<Matt|> i've tried putting the document in bitstream and converting it to pdf
<amu> you have a crt or lcd display?  
<amu> i'm not sure if oof use now his own fontconfig, probably run a dpkg-reconfigure fontconfig and enable subpixeling from the computer-desktopsettings-fonts
<Matt|> amu, ok i'll try that
<Matt|> amu, how about the "autohinter module"?
<amu> Matt|: Depending on your display and on which fonts you use, they can look better or worse when using the autohinter module. Enable it if you happen to prefer the look it gives to your fonts.
<Matt|> amu, same deal after enabling subpixeling
<Matt|> amu, i have an idea
<Matt|> amu, ok solved. The problem was that that part of the document was actually flagged as bold, although it didn't appear when i looked at the document as the nimbus roman font has no bold. Thanks for your help
<pitti> Hi carlos
<amu> Matt|: hehe, np
<carlos> pitti: hi
<trulux> hey guys
<trulux> lamont, hey, my gcc  pkgs are almost ready
<trulux> (compiling)
<trulux> what gcc version is using ubuntu?
<trulux> is it 3.3-3.3-4-13 ?
<thom> gcc version 3.3.4 (Debian 1:3.3.4-9ubuntu5)
<thom> (on warty)
<trulux> thom, thanks
<trulux> is/are the maintainer/s of gcc packages here?
* thom points trulux towards doko
<trulux> thom, thanks again ;-)
<trulux> doko, hey
<trulux> doko, do you have a few minutes?
<trulux> seems away
<kagou> I have a "Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)" it seem's that ubuntu load the "8390  11424  1 ne2k_pci" module but i can't get it working at 100 (just at 10)
<kagou> how can i force the 100 speed
<tseng> man ifconfig
<tseng> search for media type
<kagou> thanks tseng
<trulux> tseng, hey
<tseng> hi
<trulux> tseng, the pkgs take long time to finish
<trulux> but it's on the enf right now
<Mithrandir> the build log for ooo is 53MB..
<Mithrandir> that's just wrong.
<kagou> where can i put parameters for modules loaded automatically by ubuntu (i mean i wan't to add :  full_duplex=1 to the ne2k_pci module)
<amu> kagou: /etc/modules.conf
<haggai> Mithrandir: you are more than welcome to split it up (c:
<haggai> Mithrandir: I already got a proof of concept to do it, and approved by the Sun developers, but like all things OOo it needs a lot of time..
<haggai> Mithrandir: ..and I have a lot of bugs to sort out before I do things like that
<fabbione> Mithrandir: you around?
* amu thinks Mithrandir plays with evil ibm hardware 
<fabbione> ehhe
<fabbione> probably
<fabbione> Mithrandir: i will see you tomorrow in BCN
<fabbione> Mithrandir: let's meet up immediatly outside where you grab the lagguages
<fabbione> and i am off
<fabbione> cya tomorrow
<amu> have fun fabbione this night 
<fabbione> amu: thanks
<fabbione> i am planning get some good amount of danish beer ;-)
<amu> hehe  
<haggai> doko: please bring my jacket :)
<doko> trulux: pong
<trulux> doko, hey!
<trulux> doko, i suppose you already know about all the proplice/ssp stuff, so, let me talk to you about the final implementation i've made
<trulux> it's smooth, first :)
<amu> if i make a kde-ppc live CD you'll kill me right ? 
<trulux> my gcc pkgs have only 3 patches: protector (updated and re-compressed) from IBM (SSP/ProPolice), a patch to make gcc able to read specs fles from an environment variable
<doko> the work by Etoh?
<trulux> yeah
<trulux> the third is the libssp one
<trulux> how it works?
<trulux> simple, it makes gcc able to use standard -fstack-protector option, but reads and uses ssp symbols from a shared library 
<trulux> libssp
<trulux> so, we use -fstack-protector -lssp
<trulux> and we will have the SSP, adn also we can modify SSP and its functions without having to recompile the whole bucnh of glibc or gcc (if ssp is there)
<trulux> so, we have this:
<trulux> lorenzo@dunruin:~/LIBSSP/libssp-0.2$ gcc -fstack-protector -lssp vuln-stack.c  && ./a.out 1234567890123456
<trulux> a.out: stack smashing attack in function main()
<trulux> ----
<trulux> main=0x80000914 __guard_setup=0x4001daf0 __guard=0x22324fa2
<trulux> ppid=10622 pid=12190 uid=1000 euid=1000 gid=1000 egid=1000
<trulux> ----
<trulux> Abortado
<trulux> lorenzo@dunruin:~/LIBSSP/libssp-0.2$
<doko> my concern is, that the patch is only available for 3.4, and we loose the option to switch to gcc-4.0 as the default compiler, if we introduce a patch like this. Etoh did update the patch for 3.4, I'll ping him about 4.0 and put you on the CC.
<trulux> doko, i've backported it also to 3.3
<trulux> lorenzo@dunruin:~/LIBSSP/libssp-0.2$ ls /lib | grep ssp && ls /usr/lib/ | grep ssp
<trulux> libssp.so.0
<trulux> libssp.so.0.2
<trulux> libssp.a
<trulux> libssp.so
<trulux> lorenzo@dunruin:~/LIBSSP/libssp-0.2$
<trulux> doko, ok, thanks
<trulux> i think we could have this done in a really small time manner
<doko> could you open a bug report for it and/or send me the updated patch?
<doko> trulux: what's your email address?
<trulux> lorenzo@gnu.org or lorenzo@debian-hardened.org
<trulux> doko, sure
<trulux> doko, where's ubuntu bug tracker/ bugzilla?
<doko> http://bugzilla.ubuntu.com/
<trulux> ok, thanks
<martink> doko, should openoffice.org (debian dir and ooo-build from cvs) be buildable on hoary?
<Riddell> amu: no
<doko> martink: yes according to http://people.ubuntu.com/~lamont/buildLogs/o/openoffice.org/1.1.3-2.3ubuntu4/
<haggai> martink: what's up?
<martink> haggai, doko, it didn't find libXinerama_pic (formerly in xlibs-static-pic). (This is on powerpc)
<martink> I'll look at the build log
<amu> Riddell: *g* you can help to force the mepis guy to release his sources, he compiled his cool stuff against qt-free, my mailrequest and question where i can get the source of it. are refused :(     
<haggai> martink: hmm, that hasn't been changed and probably needs to be changed
<haggai> martink: I thought its time we introduce an Ubuntu patchset target
<trulux> doko, what pkg to choose for the report? gcc, gcc-3.3 either gcc-3.4?
<doko> haggai: no, that's changed. how would you syncronise the debian and ubuntu changeset?
<doko> trulux: gcc-3.4
<trulux> doko, ok
<martink> haggai, I'm sure an Ubuntu patchset will be handy, but this xinerama stuff is supposed to be autodetected, isn't it?
<haggai> martink: hmm, not sure how _rene_ did it
<doko> haggai: no, it's a changed patch in ooo-build/
<haggai> doko: easy, at the top of the apply file we have a list of distros and corresponding patches.  We pass the name of the patchset in from debian/rules, and we already know (using lsb_release) what we have there
<haggai> doko: look in ooo-build/patches/OOO_1_1_3/apply and be in awe of the magic ;)
<enrico> Hello.  I have a tiny nuisance to report with the live cd
<enrico> a friend run the ubuntu live CD, then booted back on his sytem and he couldn't mount /home anymore
<enrico> I told him to fsck his home; fsck did its job and now he has his home again
<doko> haggai: known, but who assures, that you add a patch to the ubuntu set as well as the debian set?
<enrico> Appearently, he turned of the live CD system with EXit on gnome, and his machine turned off
<amu> enrico: he mounted his home, and turned off the computer? 
<enrico> No: he used the "exit" command in gnome, and let the system shutdown and turn off
<enrico> He mounted the partition with "automount in nautilus"
<sladen> enrico: so, the situation is;  ext2 on /home, which is not mounted automatically and is not listed as fsckable in fstab?
<amu> enrico: problem is with the init, it should unmount the filesystem, and than eject the CD, but it doent do that 
<Riddell> amu: what isn't he releasing the source to?
<enrico> . /home is not mounted automatically by ubuntu livecd
<amu> Riddell: unfortunately not, ralf has this year a lot of fun, now ralf is lost in space, and he continue :(  
<enrico> appearently, his system mounts it as ext2, but nautilus mounted as ext3.  fsck said it found a journal on it.
<enrico> However, I seem to be going into sci/fi.  Unfortuntately, the report can't get any better than this vague
<enrico> That is, he's 100Km from here and I have no access to his machine to investigate, and so on.  So, this can happily be dropped until it's reported by someone else
<amu> enrico: the only solution atm is, umount the filesys manually before rebooting
<haggai> doko: as I said, have a look at the magic :)  You have several sections, and you add an UbuntuOnly section for just ubuntu's patches, and you share the rest, just like Debian does with RH, SuSE, etc
<Mithrandir> fabbione: ack, ok.
<enrico> amu: right.  However, being it the ubuntu live CD, if it has a problem like that it should definitely be looked into (since it's a test system, it shouldn't allow to do mistakes, even by mistake).  Telling nautilus to mount read-only by default, for example, could be a good idea
<martink> haggai, found the answer in the ubuntu diff.gz. In ooo-build/patches/OOO_1_1/xinerama-pic-on-all-archs.diff the s/-lXinerama/-lXinerama_pic/ change was removed
<haggai> martink: hmm, that should be fine
<haggai> martink: it's definately not auto-detected, looking at that patch :)
<haggai> martink: there is a Build-Depends: libxinerame-dev in control, so it should have been ok if that part of the patch has been removed
<amu> enrico: worth to discuss, a liveCD is something critical, and should be upgraded time by time. At least, if pitti release a USN
<martink> haggai, yes, definitely not autodetected. And debian-only.
<Treenaks> OK, I'm in the hotel
<Treenaks> now whwrnow where do I find ubuntu people? :)
<Mithrandir> Treenaks: you're in BCN?  fun! :)
<sivang> Treenaks : how was the trip from barcelona to mataro?
<Treenaks> sivang: the train smelled like piss, but the rest is nice :)
<Treenaks> anyway, what I was asking.. how do I find Ubuntu people here?
<sivang> Treenaks : eh growse, this is the train from barcelona to mataro?
<Treenaks> sivang: yes, but it could'vebeen somebody's kid
<RubenV> are there any known problems with ndiswrapper?
<trulux> doko, hey
<trulux> doko, https://bugzilla.ubuntu.com/show_bug.cgi?id=4374
<doko> trulux: thanks
<trulux> doko, ask me about anything you want related to that issue
* lamont tries to decide if he wants to deal with bringing the access points.
<lamont> probably just one.
* Treenaks decides to walk around a bit
<Treenaks> to find Ubuntu people
<trulux> lamont, check http://software.newsforge.com/comments.pl?sid=42361&cid=102743
<Treenaks> though I have NO idea what they look like
<trulux> lamont, sorry, wrong link :P
<trulux> lamont, https://bugzilla.ubuntu.com/show_bug.cgi?id=4374 <- this is the right one
* Treenaks wanders around aimlessly
<Kamion> elmo,thom: any chance that little could have an exception from archive's rsync limit somehow?
<Kamion> elmo,thom: can't build new CDs at the moment because I can't rsync the archive
* lamont goes to pack
<trulux> doko, what do you think about the report?
<trulux> when do you think it could be handled?
* lamont points Kamion at the other window, goes off to pack
<trulux> i want to collaborate in ubuntu development in that terms , but i don't anything about the policy applied to development candidates
<mdz> Treenaks: most folks don't arrive until tomorrow, I think
<Treenaks> mdz: I know thom is here somewhere :)
<mdz> yes, should be
<Treenaks> I'm connected through the UBUNTU network though.. and it gets better if I move towards my window
<Mithrandir> jump out the window and follow the beacon?
<Treenaks> Mithrandir: *aaaaaaaaaghh* *splat*
<Mithrandir> haggai/rene: for some reason, it builds with libgnomevfs, then without, then with again.
<haggai> Mithrandir: that's _rene_'s hack
<Mithrandir> haggai: shifting blame, eh? ;)
<_rene_> Mithrandir: it should only build the gnomevfs stuff on the "normal" build and then immediately build the non-gnomevfs one
<_rene_> I have no idea why it would build a gvfs version again...
<Mithrandir> _rene_: it does, but it builds the gnomevfs one afterwards again
<Mithrandir> timeskew problems?
<Mithrandir> do you build on 2.6 boxes?
<_rene_> yes, I do
<haggai> _rene_: why don't you make sure the output goes into a different directory instead of overwriting the original version?
<_rene_> uh?
<_rene_> the second build nees to overweite the gvfs one
<_rene_> since the first build is the gnomevfs one
<_rene_> and instsetoo takes its stuff from the solver
<Mithrandir> uhm, no, it doesn't, it builds in another solver directory
<_rene_> it builds in another tools/ directory
<_rene_> the library is then cp'ed into the solver in its normal name
<_rene_> and the gvfs one renamed .gvfs before
<haggai> _rene_: ouch :( I thought you did it the other way around
<Mithrandir> right
<Mithrandir> but when it then makes in solver again, it gets overwritten
<haggai> _rene_: that's asking for trouble
<_rene_> haggai: the problem is how to make it in ooo-build. either we don't apply the patch and then apply all those stuff manually or we do it this way
<_rene_> hmm. we could copy it over and build the gvfs stuff in tools/gvfs and apply the GnomeVFS section manually there...
<_rene_> erm, that patch
<haggai> _rene_: with your soln, you have to do some patch application manually, so you mayaswell not apply the patch, and then apply the patch later and do a special build
<_rene_> the problem is that we need to apply the whole section
<haggai> _rene_: so make a new patch target
<_rene_> where are patches not touching tools/
<_rene_> haggai: hmm?
<Mithrandir> _rene_: can't the patch be split, then?
<haggai> _rene_: apply.pl --patchset=debianWithGnome or something
<_rene_> Mithrandir: it already are some patches. we just unapply the one changing libtl
<_rene_> hmm. will look
<haggai> _rene_: even better, make those patches dependent on a preprocessor var
<_rene_> uh? how?
<haggai> #ifdefing stuff
<_rene_> -DUSE_GNOMEVFS?
<haggai> yup
<trulux> #ifdef
<haggai> and an envvar for the makefiles
<_rene_> that would mean to a) need conditionalzing the whole stuff and then running configure thrice
<_rene_> Hmm
<trulux> _rene_, try a GCC wrapper
<haggai> _rene_: I wasn't thinking about adding stuff to configure
<haggai> _rene_: just to the makefiles and code
<trulux> that reads special flags from a file, created with another tool who reads simple human-readable configuration labels
<_rene_> ah, and then export in the environment?
<trulux> like gentoo eclasses and so on
<trulux> :)
<_rene_> but that will break full-gnomevfs builds
* _rene_ ignores that sentence
<haggai> _rene_: that way, you have a new target which goes  source $ENVFILE; USE_GNOMEVFS=TRUE; OUTPUT=unxlngi4.gnome ; cd tools; build.pl
<haggai> _rene_: and you get your output in a seperate directory
<_rene_> yeah, I see
<haggai> _rene_: and nothing gets overwritten so you can use make's magic filestamping to keep everything working
<_rene_> but that will break "normal" builds
<haggai> _rene_: no.  that's why I said to conditionalise it
<_rene_> ooo-build builds that is
<_rene_> and when you don
<_rene_> ''t define USE_GNOMEVFS?
<haggai> _rene_: oh, ok reverse the variable meaning
<haggai> _rene_: add to the makefile.mk: USE_GNOMEVFS*=TRUE
<_rene_> ok, I'll look
<haggai> _rene_: that way you can unset it from the environment
<_rene_> trulux: rule of thumb: a setence containing gentoo is good for me ignoring this sentence ;)
<haggai> trulux: and is overengineering for the problem in this case
<trulux> haggai, yep, just dreaming ;-)
<trulux> _rene_, that  hurts me a bit, i'm a concerned gentoo user
<trulux> and debian also
<trulux> in fact -> Ubuntu
<trulux> ;-)
<wasabi> Hum. Would everybody poopoo me if I suggested making -dbg packages of most Big Gnome packages? Evolution, Nautilus, etc.
<wasabi> Things that tend to crash a lot with no explanation. :)
<haggai> wasabi: we tried to make -dbg packages for OOo and discovered there is a bug somewhere - you may hit it perhaps
<wasabi> hmm?
<_rene_> we tried to use --dbg-package= form dh_strip
<_rene_> binutils somehow didn't like the libs
<wasabi> Hmm.
<_rene_> but only *sometimes*
<haggai> _rene_: oh, ok
<Mithrandir> _rene_: so you'r making the changes which should fix my problem? :)
<mdz> _rene_: that's very interesting; I would expect the resulting stripped binary to be exactly the same, regardless of whether the debug info was saved to a file
<_rene_> mdz: no, that was not the problem. it was binutils choking during dh_strip
<_rene_> mdz: i.e. strip failing
<quitte> i want to make xorg packages for debian. as xorg is in hoary i figured it was bestto get te source of the ubuntu packages to start with. can you tellme were i can find it?
<mdz> ah
<chrisa> quitte: I think several people have already done that individually, there were a bunch of debs last time I looked
<mdz> quitte: the source for everything is in the archive
<mdz> quitte: but talk to fabbione; I imagine he is planning to make official X.org packages for Debian
<kylem> shaya did a set of them.
<daniels> mdz: i imagine that would be a fair way off, by the time everyone from every architecture has sorted it out
<mdz> daniels: for unstable, sure, but not for experimental
<kylem> that reminds me to take a look at xorg on hppa.
<daniels> mdz: IIRC, Branden didn't put 4.3.x into experimental until it was working on basically every architecture except hurd-i386 and sh.
<daniels> kylem: if you want to throw me over a MANIFEST.hppa.in, and, for bonus points, *.install.hppa, I'll throw it in our packages
<kylem> ok... err, does ubuntu intend to port to hppa or something?
<daniels> not really
<mdz> lamont is likely to do it at some point
<daniels> but since they're currently basically the sole source for debian/ubuntu packaging, i figure having the hppa bling there would be neat ;)
<kylem> fine, fine, heh.
* kylem adds to his .todo :P
<daniels> good man.
<daniels> your leg is safe, at least for the time being. ;)
* kylem thanks $deity for the atlantic ocean. :>
<elmo> rookery (aka people.u.c)'s going down
<elmo> back
<chrisa> hrm, jeff said on planet that people who ordered a lot of Ubuntu cds received display packs
<chrisa> I seem to have missed out on those
<winkle> seb128: I think pygtk just broke due to new gtk or something.
<seb128> yep
<daniels> chrisa: >50
<chrisa> daniels: I have 200 next to me
<chrisa> well, about 180 left
<daniels> hm
<Mithrandir> hmm
<chrisa> ah, I just searched the box. Some of the cases I haven't opened do have them
<Mithrandir> I can reproducibly break nautilus
<chrisa> Carry on :)
<Kamion> python-parted's in the desktop seed?!
<Kamion> sheesh
<Kamion> guess I'd better fix it then, but I don't think it needs to be there
<daniels> Kamion: yo, dude
<daniels> Kamion: ide modules are in the bios, yeah?
<daniels> Kamion: sideshow has an x40 here, and he can't install because it hasn't picked up his ide controller
<daniels> Kamion: drivers/ide is suspiciously empty
<daniels> Kamion: (this is a pxe install, mind)
<daniels> Kamion: er
<daniels> Kamion: imagine I never said 'ide modules are in the bios'
<daniels> Kamion: are the ide drivers in the kernel (i.e. non-modular) in the installer?
<Kamion> daniels: they're modular
<Kamion> daniels: drivers/ide/ will be empty from the start of a netboot install; ide-modules is pulled in later over the network
<daniels> Kamion: right, ta
<daniels> Kamion: this doesn't seem to have happened
<Kamion> daniels: what stage of the install has it got to?
<elmo> Kamion: it was part of the python-world phase
<daniels> Kamion: partitioning
<Kamion> daniels: oh, also, what version of the installer is he using? if it's hoary and <= day or two ago, it won't work
<daniels> Kamion: warty, yo
<Kamion> hmm
<Kamion> do me a favour, switch to tty2 and 'debconf-get mirror/suite'
<Kamion> daniels: I'll confess that I haven't netbooted warty since like forever, but fabbione tested it pre-release I believe
* chrisa should set some of these ubuntu displays up in the Univ cs buildings and such
<Kamion> mkay, new python-parted uploaded, ubuntu-desktop/hoary should become installable again in a bit
<daniels> Kamion: yeah, 'show I installed mine
<daniels> Kamion: (sideshow is re-netbooting now, so we'll see if it's still arse when he boots from mine; if it is, diagnostics will be on the way)
<Kamion> daniels: ta. I'm around for maybe another hour and a half
<daniels> Kamion: rad
<trulux> doko, i want to create an ubuntu-hardened livecd, what's the man in charge of livecds?
<Kamion> it has just struck me how totally trivial it is to churn out bootable USB images that work the way I want
<daniels> Kamion: it's working now
<Kamion> hmm
<Kamion> daniels: if it happens again I need /var/log/syslog
<Kamion> gah, this sucks, can't build Ubuntu d-i images on Debian any more
<Kamion> bloody parted
<daniels> Kamion: will do, cheers
<daniels> Kamion: oh, bugger.  abi change?
<Kamion> uh-huh
<daniels> sheez.
<Kamion> ah well, I have a million chroots lying around
<mdz> Kamion: we ought to get the installed system booting from USB correctly, too
<daniels> mdz: yeah
<Kamion> mdz: very painful on powerpc unfortunately
<Kamion> mdz: (but yes)
<mdz> Kamion: oh? why particularly on powerpc?
<Kamion> mdz: IIRC joeyh has had debian-installer successfully booting from one USB stick and installing to another, so it shouldn't be too hard
<mdz> installing to it is fairly straightforward, but getting it to boot afterward needs some work
<Kamion> mdz: because ofpath (yaboot) doesn't have a clue how to find the Open Firmware path to the USB stick, and even when I looked at it by hand it required a certain amount of guesswork
<mdz> either adding the necessary modules to the mkinitrd list, or moving hotplug into the initrd
<Kamion> (and therefore I don't see an easy way to modify ofpath to fix that problem)
<mdz> hotplug-in-initrd really should happen anyway
<Kamion> hotplug-in-initrd sucks; found that out in d-i
<mdz> oh?
<Kamion> having udevd start up before you've got around to running pivot_root is not good
<Kamion> if udevd weren't there it might just about be sane, although the race conditions still concern me
<Kamion> I think hotplug would need to be disabled around the pivot_root
<Kamion> and you'd have to wait for any running scripts to go away
<mdz> I think hotplug-in-initrd is the way forward, though it has some issues to work out
<Kamion> my solution in d-i was to install hotplug as /sbin/hotplug.real and only enable it once the system is in a roughly sane state
<Kamion> I think you'd want to do something like that for hotplug-in-initrd; basically just use it as coldplugging, don't attempt true hotplug
<trulux> lamont, ping
<mdz> right
<mdz> trulux: he's left for the airport
<trulux> mdz, ok
<mdz> it's just a nice way of centralizing the logic and getting rid of all that guesswork in mkinitrd to figure out what to load for the root filesystem
<mdz> and as a bonus being able to pull the disk from one machine and put it into another, and have it still boot
<trulux> mdz, how easy is to rebuild the whole ubuntu pkgs tree? wanna-build?
<mdz> trulux: not very esay
<mdz> easy
<mdz> assuming you're talking about bootstrapping a new architecture
<mdz> rather than just recompiling things for an existing one
<mdz> recompiling for an existing one is fairly simple
<daniels> (and if you are recompiling, why?)
<trulux> mdz, why you say not "for an existing one" ?
<Kamion> mdz: pull the disk> assuming that grub does the right thing ...
<daniels> trulux: if you are recompiling for i386, amd64, or powerpc, it's very easy
<daniels> trulux: if you are recompiling everything on an architecture where ubuntu doesn't already run, it's hard
<amu> *gaehn* 
<trulux> daniels, i mean i386
<trulux> recompiling for i386
<daniels> trulux: why are you recompiling for i386?
<trulux> i'm doing a hardening improvement for Debian and mainly (now) Ubuntu
<haggai> trulux: amu is the livecd man
<trulux> kay
<trulux> i'm going to make some noise on ubuntu bugzilla about the things i work on
<trulux> i'm starting to love the ubuntu development "policy", Debian goes slower
<Kamion> gah
<Kamion> FABBIONE 
<Kamion> fabbione: what happened to sk98lin-update.dpatch?
<Kamion> oh, bleh, it's in the changelog ... but I'm missing the MODULE_DEVICE_TABLE
<Kamion> this is the problem with hotplug, some complicated kernel merge leaves you with no hardware detection :(
<trulux> mdz, what's the best way to recompile the pkgs?
<haggai> hmm, the Wiki says Mataro is zone 3 but looking on the map it looks like it is in zone 4.  Anyone know for definite?
<amu> oOo matrix3 on tv 
<trulux> daniels, any idea about my last question?
<Kamion> but, theoretically, sticking d-i netboot on a USB stick seems to work; will test further in Mataro
<daniels> trulux: it's not easy -- you need to set up wanna-build and buildd with sbuild
<carlos> haggai: yeah, it seems like it's zone 4
<carlos> haggai: just ask for a ticket to Mataro
<carlos> and that's it
<trulux> daniels, our use debian-builder for each package
<trulux> daniels, any documentation about that?
#ubuntu-devel 2004-12-16
<trulux> lamont, is James (binutils pkg maintainer) online?
<lifeless> trulux: which James?
<trulux> Troup
<lifeless> not around at the moment
<lifeless> lamont is travelling... won't hear from him till he hits mataro I tihnk
<trulux> lifeless, kay
<daniels> trulux: no, sorry
<trulux> ok
<haggai> carlos: thanks
<bob2> hm
<bob2> should suspend-to-ram be logged anywhere?
<bob2> my paranoia circuit is having trouble beleiving a) it works at all, and b) that it wakes up so damn quickly
<Mithrandir> bob2: look at a sleep indicator?
<bob2> the little moon?
<bob2> it's not coming on
<Mithrandir> then the baby's not sleeping; try just echo mem > /sys/power/state
<fabbione> morning guys
<Mithrandir> hi fabio
<fabbione> hey Mith
<bob2> hrm, sounds like something to try when I'm not rsyncing my homedir, but thanks :)
<Mithrandir> bob2: well, you're probably right.
<Mithrandir> bob2: it should sleep if you unload the USB modules
<bob2> ah
<bob2> hm
* Treenaks made a photo series of the walk from the station to the NH hotel
<Treenaks> *uploading*
<Treenaks> fabbione: you here yet? :)
<Mithrandir> Treenaks: fabbione and I are arriving this afternoon
<Treenaks> cool
<Treenaks> I'll upload the photo series so you can see how to walk on your PDAs :P
<fabbione> i don't have a PDA :-)
<Treenaks> laptop then
<Treenaks> mobile phone
<sjoerd> Treenaks: we can study them in the train from bcn :)
<Treenaks> sjoerd: 8)
<daniels> Treenaks: URL? :)
<Treenaks> daniels: copying from flash. but they'll be on foodfight.org/fotos/2004/ somewhere :)
<Mithrandir> fabbione: I have an x40, it's almost a pda. :P
<Treenaks> btw, I like the UBUNTU wireless network here :) much cheaper than Eurospot :)
<sjoerd> Treenaks: i'm getting ``not found'' on your pages ?
<Treenaks> I know
<Treenaks> fixing
<sjoerd> :)
<Treenaks> should be fixed now
<Treenaks> tr/// doesn't work well with things like UTF-8 :(
<sjoerd> 500 on the marina and pier page
<sjoerd> same on the walk from blabla page
<Treenaks> I know
<Treenaks> the thumbnailing thingy crashes on unfinished jpgs
<Treenaks> and as I'm still uploading... :)
<sjoerd> ahah :)
<sjoerd> nice connection ?
<Treenaks> no :)
<Treenaks> 45 minutes remaining 
<Treenaks> ah, I have an 1mbit connection to the AP
<Treenaks> that explains it
<Treenaks> oh, and across the street there's a thing called "UNIX", but I don't know what it is
<Treenaks> I've found:
<Treenaks> - 3 computer hardware stores
<Treenaks> - at least1 nice coffee bar (great coffee!)
<Treenaks> (they also serve bread with cheese/meat)
<thom> Treenaks: if you're in the hotel, come to the second floor, follow the signs to the "salones" and mako and i are in the belagua
<Treenaks> thom: second floow being "2" or "1"? :)
<Treenaks> (american or european numbering system? :))
<thom> european
<thom> uh, um.
<Treenaks> so "press 2 in the elevator", OK
<thom> the floor numbered 2, i mean :-)
* Treenaks is on his way, and will bring laptop :)
<thom> yeah, we have an 8mbit or so connection here ;-)
<mako> Treenaks: ciao
<Treenaks> http://foodfight.org/fotos/2004/12-05%20Walk%20from%20Matar%C3%B3%20train%20station%20to%20hotel/
<Treenaks> http://foodfight.org/fotos/2004/12-05%20Matar%C3%B3%20marina%20and%20pier/
<ironwolf> Treenaks: great photos! thanks for sharing!
<ChrisH> The Warty CD does not boot on a server here. Knoppix does. Is there a way to boot the first stage from Knoppix and then switch?
<magnon> hm, where's gaim's header files hiding+
<magnon> ?
<magnon> *devel files in general
<bob2> gaim's headers aren't packaged, iirc
<bob2> there's an outstanding wishlist bug about it
<magnon> ah, thanks.
<bob2> (I think)
<magnon> seems like a reasonable explanation to me :)
<magnon> I'll have to source it, then
<sivang> mdz : do you know if mako already computed the keyring md5sums? it was said it wold be available by yesterday :)
<sivang> mdz : (I'm talking about the ksp)
<mjg59> Is it just me, or is the kernel package build system on crack?
<mjg59> Are there any docs on how to move to a new upstream version without sedding files by hand?
<sivang> mjg59 : what do you mean "new upstream version" a kenrnel recompilatio howto?
<mjg59> sivang: No, I want to adapt the ubuntu kernel source package to a 2.6.10 prerelease for testing purposes
<sivang> mjg59 : ah I see:) I don't recall I've seen a howto for this then.
<thom> yes, the kernel build system is awesomely crackful
<mjg59> Oh, WURGH.
<mjg59> tg3.c is an empty file in the Hoary 2.6.9?
<mjg59> Oh, I see...
<mjg59> Argle.
<sladen> mjg59: make-kpkg debian  ?
<mjg59> Oh, is that how it's done?
<zul> morning
<Treenaks> why is it so quiet in here? I mean.. everyone seems to have a laptop + IRC :)
<lamont_r> lol
<lamont_r> you in mataro Treenaks ?
<sjoerd> Treenaks: probably because some people don't need irc to talk to eachother :)
<Treenaks> lamont_r: yes ;)
<thom> sjoerd: it's not stopping those two, they're about a foot apart
<lamont_r> thom: more like 6
<sjoerd> thom: hehe
* Kamion feeds kernel bugs to fabbione
* lamont_r hands Kamion more fuel
<trulux> hey guys
<trulux> hey lamont & doko 
<trulux> having good time at Matar?
<lamont_r> trulux: yeah
<trulux> :D
<trulux> here there's no sun at all
<sjoerd> thom: oh is there ipv6 over there or just ipv4 ?
<trulux> lamont, i've sent some bug reports regarding my toolchain enhancements to the ubuntu bugzilla
<thom> just v4
<thom> i think
<trulux> doko received the gcc related ones quickly
* trulux is having good feedback ;-)
<sivang> pitti : Hi !
<pitti> Hi sivang!
<pitti> sivang: greetings from Matar :-)
<sjoerd> pitti: had a nice trip ? 
<sivang> pitti : Yeah, how was the trip?
<Treenaks> pitti: could you shout your name so I know who you are? :P
<Treenaks> sjoerd: when were you arriving? wednesday?
<sjoerd> Treenaks: tuesday
<sjoerd> in the afternoon
<sjoerd> plane lands at 11:15 in bcn
<Treenaks> sjoerd: ah, mine landed 14:20 and I was here around 1700
<sjoerd> uhm, 11:45 thatis
<Treenaks> sjoerd: http://foodfight.org/fotos/2004/12-05%20Walk%20from%20Matar%C3%B3%20train%20station%20to%20hotel/
<Treenaks> sjoerd: walk from train station to hotel ;)
<Treenaks> sjoerd: to download to your PDA/laptop
<sjoerd> saw them
<trulux> will be the next ubuntu conference celebrated in Matar too?
<pitti> sjoerd, sivan: a bit exhausting, but it went all well
<sivang> pitti : good to hear that :)
<pitti> pitti: ping to myself
<sivang> pitti : I heared you travlled with lamont
<pitti> sivang: yes, I met him in Frankfurt
* ..[topic/#ubuntu-devel:thom] : Ubuntu development -- general discussion and support on #ubuntu | Want to help Hoary? see https://www.ubuntulinux.org/wiki/HoaryGoals | Mataro server is mataro.ubuntu.com - local mirror, smtp smarthost
<mako> i'm downloading the last set of keys that people sent and then i'm going to compute the md5sum, do a few tests and then send it
<sivang> mako : great
<sivang> anybody know how to use dh_scrollkeeper? the man page is , a bit cryptic :)
<mjg59> sivang: Just call it in your debian/rules after the package has installed into debian/tmp (or whatever)
<mjg59> You may need to do some extra stuff if you have your own postinst
<sivang> mjg59 : am using cdbs
<mjg59> Oh, right
<mjg59> Try #gnome-debian on irc.gnome.org
<sivang> mjg59 : I have called it in my rules, but it seems to not having done anything :) 
<sivang> ok, I'll try there.
<sivang> mjg59 : thanks!
<lupus_> k I noticed that if you change an option in gnome-volume-manager properties this will have no effect till you restart it.
<lupus_> shouldn't gnome-volume-manager be restarted when you click on close then?
<lupus_> I don't want to wait till next reboot :p
<wasabi_> it should apply instantly.
<wasabi_> i thought it did.
<sivang> tseng : ping
<tseng> hi sivang 
<sivang> tseng : hey :) I have started with cdbs, it's a workhorse :) However , I thought of asking you about a trouble I have with dh_scrollkeeper, I am not sure how to use it under cdbs.
<lupus_> wasabi_, I changed the cd audio entry to goobox
<tseng> well cdbs has a method to override a function
<tseng> like in OOP
<lupus_> but it still starts the old player
<tseng> basically you can add custom methods to any function that cdbs already defines in an include
<sivang> tseng : where can I paste you my rules file? 
<lupus_> can someone test to verify
<tseng> sivang: grab my tomboy package
<tseng> sivang: and look at the rules file
<tseng> its a good example of overriding to call dh_blah
<sivang> tseng : you are also installing documentation into scrollkeeper there?
<tseng> no, im calling dh_netdeps
<tseng> overriding a predefined function
<tseng> im sure someone here knows an example of a cdbs package using scrollkeeper, however
<sivang> anyone ? :)
<sivang> tseng : I have the 2 standard includes, for makefile and debhelper, and I added:
<tseng> there is a gnome include
<tseng> it actually calls dh_scrollkeeper
<tseng> have a look.
<tseng> it should "just work" for basic stuff
<sivang> tseng : I know, already tried it - it looks for the whole set of auto tools in the pkg source folder, and it's a plain doc pkg so nothing like that in it yet.
<sivang> tseng : how do I create it a set of autotools file ?
<tseng> in a new project?
<tseng> or from cvs
<sivang> tseng : in a new , completely fresh package tree I created.
<tseng> no idea about autotooling from scratch, sorry
<tseng> im sure there is a good FM in that area
<sivang> tseng : ok, I will check , thanks anyway :)
<trulux> lamont, it would be a good idea to run a poll about what devs think about improving more security enhancements in Ubuntu
<trulux> like the one at http://d-sbd.alioth.debian.org/www/?page=survey
<sivang> does anybody know if we can use h323: (gnomeeting) from mataro?
<sivang> or could please have a test for it
<trulux> yep, is it re-transmitted?
<sivang> trulux : what?
<sivang> I am not sure about that...
<sjoerd> sivang: all the people from mataro seem to come from one ip addy.. So probably natted
<sjoerd> sivang: so it probably won't work
<sivang> sjoerd : I see
<sivang> sjoerd : then gaim it is :)
<sivang> I use voip from a NATed lan :)
<sjoerd> voip ? h323  or sip
<sjoerd> i'm doing the same, but my gw does portforwarding for a portrange, so it works with gm
<sjoerd> an most of the time i use ipv6, so all stupid limitations are gone
<sivang> sjoerd : well, could you show a bit ipv6 when I'm there ? :) would be willing to learn to set up.
<sjoerd> ipv6 network is trivial.. connection to the outside world is somewhat harder currently
<sjoerd> being behind a nat makes it more difficult again, but just ask me about it if you want to know
<sjoerd> or fabionne, he knows a lot about it too iirc
#ubuntu-devel 2004-12-17
<Matt|> hiya all, I have noticed a strange thing about my sound on ubuntu. When I fire up rhythmbox after booting, the sound production is really quite distorted, and this disappears if I go into the gnome-mixer and select the OSS device, and then move back to the ALSA device. Can I solve this?
<chrisa> That's more of a #ubuntu question I presume
<Matt|> have tried
<Matt|> i always check here before filing a bug because i'm paranoid about filing bogus bugs
<gilligan_> hi
<gilligan_> anyone here related to hoary gnome packages?
<jdodson> any developers in the house?
<stuNNed> hi i will make my presence brief have one ques:  why isn't gparted in hoary when ntfsresize will be included in official hoary iso in april/may?
<zul> you maybe want to open a bug in bugzilla
<stuNNed> zul, me?
<zul> stuNNed, yes
<stuNNed> zul, will do thanks :)
<calc> hmm the gnome menu is structured in such a way that it causes vino desktop file to not be displayed at all
<calc> since it is of type Application and Settings
* calc may be looking in the wrong area though since it seems the menu isn't being made from the /etc/xdg/menus stuff that is in hoary
<wasabi> anybody around? what makes Ubuntu's initrd load a specified SCSI module?
<wasabi> I need to change it.
<pasc> most people are in spain
<pasc> where it's early morning
<jbailey> wasabi: I don't have an ubuntu system handy, but assuming it's the same initrd-tools as in Debian, you can easily add a module to load to the list.
<jbailey> wasabi: Usually it just detects it off the running system.
<wasabi> well, im trying to do something a bit abnormal.
<wasabi> Boot my ubuntu system from inside vmware running on windows.
<jbailey> Oh.
<wasabi> It's trying to load the wrong scsi module... the one that it usually loads
<jbailey> So you just need it to load an additional module.
<wasabi> yeah.
<jbailey> Add the module name to /etc/mkinitrd/modules
<jbailey> Then rebuild the initrd
<wasabi> Okay... I do not have a custom kernel.
<wasabi> So how the heck does it know to load my current one?
<wasabi> it'd have to be stored in grub or the initrd someplace.
<wasabi> *mystified*
<jbailey> initrd-tools is a bit of black magic that way.  Mostly it looks at your currently installed module set.
<wasabi> Does ubuntu build an initrd at install or something?
<wasabi> I had thought it was packaged.
<jbailey> The usual trick is to build the initrd when you install the kernel.
<jbailey> It's very custom per system.
<wasabi> So linux-image-* must build one at install/
<wasabi> So i should just be able to add my new module to the appropiate list, and reinstall the stock kernel?
<jbailey> Yeah, or run mkinitrd by hand.
<wasabi> odd. ;0
<wasabi> hah success
<wasabi> X totally dies of course 
<wasabi> everything else looks ok
<wasabi> So when is X going to stop needing a config file? =/
<jbailey> wasabi: Wha?  You're insane, right? =)
<wasabi> No way.
<wasabi> It needs to detect the hardware.
<wasabi> Find the right drivers, and the right res, automatically.
<jbailey> I know that discover is planning on generating X config files.
<wasabi> Like you know, windows.
<jbailey> But dual-monitor setups so far don't even come close to being detected correctly.
<wasabi> I got ubuntu booted in vmware, but of course I have to swap out the X config to get X to work
<wasabi> guess i could script that
<jbailey> Is /proc/cpuinfo different enough to detect if you're in VmWare or running on the hardware?
<wasabi> no.
<wasabi> i can find it elsewhere though.
<wasabi> not sure where, but that shouldn't be hard.
<wasabi> So, i've got my dual boot PC. Windows on one partition, Ubuntu on the others.
<wasabi> When im in ubuntu, I can boot windows in vmware.
<wasabi> And now, when im in Windows, I can boot Ubuntu in Vmware too!
<wasabi> So, wherever I am, I can access the other OS
<wasabi> Xorg -configure crashed nicely
<Treenaks> anyone awake? :)
<fabbione> elmo_away: ?
<Treenaks> ...
<fabbione> hey Treenaks 
<Treenaks> hey fabbione :)
<fabbione> lamont_r, elmo_away:  uname -a   
<fabbione> Linux vultus5 2.6.8-1-sparc64 #1 Sun Oct 17 20:12:41 EDT 2004 sparc64 GNU/Linux
<fabbione> sparcbuildd@vultus5:~$ wanna-build --list=needs-build
<fabbione> Total 0 package(s)
<fabbione> sparcbuildd@vultus5:~$ 
<lamont_r> fabbione: is that just main, or main+universe?
<fabbione> main
<fabbione> but they are gold packages
<fabbione> there are a bunch missing becuase x ubuntu4 broke on sparc
<fabbione> but not that many
<fabbione> ubuntu4 fixed ia64 and fucked sparc
<Mithrandir> fabbione: just slap daniels and get him to fix it. :)
<fabbione> Mithrandir: the little kid already knows
<daniels> it already is fixed
<daniels> just not uploaded
<fabbione> daniels: and what are you waiting for? ;)
<fabbione> daniels: you are not gonna get a bj here
<thom> good thing, that's not something we want to see
<daniels> hah
<calc> hows the conf?
<Keybuk> the juice at breakfast was somewhat sharp
<calc> be careful not to cut yourself ;)
<Mithrandir> could somebody please whack the wiki into not hijacking M-d in firefox?
<Treenaks> Mithrandir: M-d?
<Treenaks> oh cool
<Mithrandir> Alt+d if you prefer that notation.
<Treenaks> Mithrandir: yeah, I didn't know that. I like it :)
<Mithrandir> it's so wrong that a web page can hijack like that.
<Treenaks> Mithrandir: hack firefox to bind it to Ctrl+Meta+Super+<accesskey> ...
* ..[topic/#ubuntu-devel:thom] : Ubuntu development -- general discussion and support on #ubuntu | Want to help Hoary? see https://www.ubuntulinux.org/wiki/HoaryGoals | Mataro server is mataro.ubuntu.com - local mirror, smtp smarthost, squid on 3128
<Mithrandir> what is the heuristics used for choosing translations?  I have gpg talking to me in both Swedish and Danish.
<lamont_r> Mithrandir: you are such a lucky guy...
<Treenaks> lamont_r: I have Evolution speaking a mixture of Dutch and English (and my LC_MESSAGES is set to English..)
<Treenaks> uh Mithrandir 
<fabbione> lamont_r: do you think is it ok to build universe only once on top of a golden main?
<Mithrandir> fabbione: no, universe might build-dep on universe stuff
<fabbione> Mithrandir: but we can use dep-wait for that
<fabbione> if foo build-dep on bar from universe
<fabbione> foo will go in dep-wait until bar is built
<fabbione> the problem can come with circular build-dep
<fabbione> but over 12K packages i don't think there are that many that needs that kind of love
<fabbione> and perhaps we can push them manually
<Mithrandir> go ahead, then
<fabbione> after we get main in the archive
<fabbione> universe isn't a priority for me right now
<fabbione> but since main is basically sinced, we can spare cpu time on it
<lamont_r> fabbione: universe is known to have dep-wait loops.
<lamont_r> but I've manually bootstrapped those...
<fabbione> lamont_r: so i guess it is a reasonable amount of work for it
<lamont_r> ubuntu-main + a couple random debian-debs of the right vintage, build once, and then build the next one using the ubuntu-built debs (just built), and then upload that..
<lamont_r> it's not too bad really, just have to remember which debs are which and only upload pure ones.
<fabbione> lamont_r: yeah clearly...
<fabbione> lamont_r: but since this is my "first" big buildd operation, i tend to be slightly more anal than usual
<lamont_r> yeah
<seb128> jdub, Beowulf asks if you are going to upload howl 0.9.8 in Debian one day :)
<thom> pitti: dude, if i just turn off udev-mtab for the time being, do you see any problems with that? or should we just suck up the pain and beat lamont till he fixes mount?
* lamont_r is uploading umount now
<lamont_r> mind you, the change log says: "New upstream version" :-=)
<lamont_r> but 2.12j has the umount fix in it apparently
<Kamion> cool
<thom> ok, so i won't bother. sweet
* thom sets up an upload queue
<Mithrandir> how do I convince dput to use active and not passive FTP?
* lamont_r loves 5 minute hours.
<pitti> thom: I have no problem with throwing out udev-mtab for the moment
<pitti> thom: it's not really crucial anyway
<thom> pitti: sure
<thom> but lets see if the new umount fixes us
<lamont_r> 2.12j-1ubuntu1
<pitti> lamont: already uploaded?
<elmo> Mithrandir: change the value of passive_ftp in the config file?
<lamont_r> or snatch it from incoming.d.o, 2.12j-1 there, and accept the b0rkage of init scripts that follow
<lamont_r> pitti: uploaded lo these 3 minutes
<Mithrandir> elmo: I don't have it set, I think dput's broken atm, but using -P made it working.
<thom> Mithrandir: manual claims that it's active by default
<Mithrandir> s/ing//
<Mithrandir> thom: manual is wrong.
<elmo> they changed the default recently
<elmo> and probably forget to update the manual
<lamont_r> eta to new util-linux/mount/etc for hoary: 53 minutes
* enrico was wondering if there is a place where t upload pictures  taken at the conf
<elmo> lamont: err, how's that work?
<Treenaks> lamont_r: is that a working/non-segfaulting one? :P
<Treenaks> enrico: I upload my pictures to my own page..
<elmo>    * Migrate DELAYLOGIN unconditionally, instead of md5sum hack.
<elmo> err - how does that not stomp all over the golden rule?
<lamont_r> elmo: 2.12j-1ubuntu1 accepted, will enter archive at :33.  binaries take < 25 minutes to build :-), so they'll be there before the :00 run, and hit the archive at :03.  modulo mirroring to archive.u.c, should be about :05-ish and can expect to see them there...
<lamont_r> Treenaks: rumor has it that 2.12j fixes the segv in umount
<elmo> lamont: oh right, forgot about little detail of buildds
<lamont_r> yeah
<lamont_r> :-)
<Treenaks> lamont_r: but: will it be mirrored on the mataro mirror in time :)
<lamont_r> Treenaks: do I care?
<lamont_r> I said "for hoary", not "for the conference"... :)
* Treenaks mumbles something about dogfood :P
<thom> it mirrors every hour...
<lamont_r> thom: but _when_ each hour... :-_
<lamont_r> :-)
<Kamion> elmo: probably needs a --compare-versions thing
<thom> @HOURLY :P
<lamont_r> "The only remaining issue which needs to be dealt with before enabling it by default is to implement a policy for key management:"
* lamont_r chuckles
<seb128> jdub, !!
<seb128> did you see the question about howl in Debian ?.
<jdub> seb128: nup, but i know i haven't don it yet :)
<seb128> Beowulf jordim: GnomeMeeting 1.2 is released, so I need a new howl to make pacakges
<seb128> jdub, they are waiting on your packages ...
<jdub> ok
<enrico> Treenaks: is there already a wikipage where to link the photos on each one's pages?  If not, I can create one
* enrico created the ConferenceGalleries wiki page to post links to personal picture galleries
<enrico> So, everyone please add your gallery link to http://wiki.ubuntu.com/ConferenceGalleries
<fabbione> Kamion: the kernel is ready for testing. What flavour do you need?
<lifeless> thom: whats the archive location for the conf ?
<Mithrandir> lifeless: $topic?
<lifeless> kthnx
<lifeless> irssi doesn't show me that much
<lifeless> unless I know to ask
<Treenaks> enrico: go right ahead (www.foodfight.org) -- you can't link to the pictures though (I do referer checks...)
<mjg59> Are you guys getting tbm this time?
<fabbione> mjg59: do you want us to rape him? ;)
<fabbione> mjg59: do you have any new acpi patch you want in 2.6.9?
<fabbione> i am planning an upload pretty soon
<mjg59> fabbione: Heh, no, I just want to know if he's going to be harassing me in person for the next couple of weeks :)
<mjg59> fabbione: I'm working on swsusp stuff with upstream
<mjg59> Once that's sorted, I'll push you a couple of things
<fabbione> mjg59: ok, if there is any bit you want backported please send me the dpatch for it, ok?
<jdub> hey mjg59 
<mjg59> fabbione: Will do
<gilligan_> hi
<bob2> mjg59: ever heard of x40's not waking up?
<mjg59> bob2: Not waking up in what way?
<bob2> mjg59: sleep light stays on, keys + power buttons have no effect.  eventually end up holding down power until it shuts down hard.
<mjg59> bob2: That's weird. No, I haven't seen that. Which kernel is this?
<bob2> mjg59: your magic one
<mjg59> Hrm.
<mjg59> Has it ever worked?
<bob2> yes
<mjg59> With the same kernel?
<bob2> yeah.  lid-closing doesn't seem to put it to sleep, if that's related
<enrico> Treenaks: added!
<mjg59> Yeah, it won't do with the default acpi scripts (too many things would break)
<bob2> oh
<mjg59> Can you check the contents of /proc/acpi/wakeup?
<gilligan_> hm.. anyone into networking stuff here ? I am having some probs with a driver here...  normaly pause frames should be ignored right?
<bob2> 'sudo /etc/acpi/sleep.sh' is ok to sleep it?
<bob2> Device  Sleep state     Status
<bob2>  LID       3            *enabled
<bob2> SLPB       3            *enabled
<gilligan_> because i get "eth0: Pause is enabled... " and afterwards link goes up again
<bob2> (all else is dissabled)
<mjg59> bob2: Ought to be
<mjg59> Hm. How weird.
<gilligan_> is there any way to force that? the network driver module itself does not accept any arguments (sungem)
<mjg59> Try dropping back to 2.6.8.1?
<bob2> will do later
<mjg59> bob2: Can you run dmidecode and pull out the BIOS version?
<Kamion> fabbione: Linux cittagazze 2.6.8-9-amd64-k8 #1 Sun Oct 3 18:22:21 CEST 2004 x86_64 GNU/Linux
<Kamion> fabbione: one of those please
<bob2> mjg59: is daniel's x40-acpi-support complete crack or neccessary?
<bob2>                 Version: 1UET92WW (1.42 )
<Treenaks> mjg59: can I _write_ to /proc/acpi/wakeup ?
<mjg59> Ok, that's much more recent than mine
<mjg59> Treenaks: Yup
<mjg59> bob2: If you've got all my crack, it ought to be unnecessary
<Treenaks> mjg59: stuff like echo -n "LID disabled" >
<bob2> mjg59: hrm
<mjg59> Treenaks: I can't remember the exact format - just the name should toggle it, I think
<jdub> mjg59: are you going to redo your changes on top of fabio's 2.6.9?
<mjg59> jdub: At the moment I'm working on targetting upstream, so I'm patching against 2.6.10+
<mjg59> One that's done, I'll backport it
<mjg59> 2.6.10 ought to be out by Christmas, incidentally
<Treenaks> mjg59: maybe turning off "wakeup on lid" will fix the bug where my laptop boots again when I close the lid after shutdown
<mjg59> Treenaks: Oh, that bug's fixed now
<mjg59> GPEs weren't being disabled at the right time
<fabbione> Kamion: p.u.c/~fabbione/kernel/ pick the one you prefer ;)
<Treenaks> mjg59: this is 2.6.9 -- so 2.6.10 fixes that?
<mjg59> Yeah
<fabbione> mjg59: do you have a backported patch for that fix?
<mjg59> fabbione: Nope. Hang on, give me a sec and I'll try to pull it out of bk
<fabbione> thanks
<mjg59> http://bugzilla.kernel.org/attachment.cgi?id=4105&action=view
<fabbione> danke
<mjg59> Should apply to 2.6.9
<Mithrandir> mjg59: aren't you coming to BCN?
<fabbione> yup
<mjg59> Mithrandir: Doesn't look like it. I've got too much to get done by next week.
<mjg59> Mithrandir: If a miracle happens, I might be able to manage a few days next week, but who knows?
<mjg59> Most of the distributions built on top of Debian, such as Linspire, Xandros, Skolelinux, LinEx, or Ubuntu, apply some discretion in the packages they select. They are unlikely to include tools like hot-babe, and, thus, may be considered safer versions to use in situations where somebody may get offended. Well, OK, perhaps we can't be too sure with Ubuntu.
<Mithrandir> mjg59: :/, would be nice to see you here.
<mjg59> Mithrandir: Heh. Encourage me to go to work and get stuff finished in time for my deadline, then :)
<fabbione> mjg59: compiling the patch now
<fabbione> but it didn't apply clean
<fabbione> something else changed in acpi in the meanwhile
<Mithrandir> mjg59: I'm not here next week. :P
<fabbione> (one include has been removed, so it shouldn't be too dangerous)
<mdz> http://www.ubuntulinux.org/wiki/SeedManagement
<mjg59> fabbione: Bleah
<mjg59> Mithrandir: Oh. Bah. No, no chance I can get there this week, really
<Mithrandir> mjg59: so better have you around on IRC, then. ;)
<mjg59> I should stop reading OsNews
<mjg59> It's even worse than debian-devel
<Mithrandir> they have hot OS of the day articles?
<mjg59> Haha
<mjg59> Mostly it's just Eugenia bitching about ACPI
<__daniel> hai
<fabbione> elmo: can you kindly install patchutils on concordia hoayr chroot pleaase? (nothing really important... just to make my life easier)
<elmo> fabbione: done
<fabbione> elmo: thanks a lot
<Keybuk> BATTLESTAR CONCORDIA
<elmo> I reckon concordia would be a cylon base ship, not a battlestar
<Keybuk> heh, it's a big mother, whatever it is
<Mithrandir> what's the policy of closing bugs which both seems to be fixed and don't have any information from the submitter?
<elmo> well, I don't know about policy, but I've always just closed them, leaving a message to the submitter asking them to reopen if they can reproduce and have more info
<bob2> 'whois' needs to be in base
<mjg59> Is anyone looking at getting OpenBSD's Free HAL module working with madwifi?
<pitti> bob2: your stick works fine, thanks again
<thom> i'm more interested in OBSD's ntpd
<thom> actually
<elmo> what's so great about OBSD's ntpd ?
<daniels> it has no security holes
<lamont_r> daniels: and no features
<thom> dunno, i'm just saying i'm more interested :-)
<elmo> daniels: daniel, openssh security history.  openssh security history, daniels.
<daniels> elmo: james, humour.  humour, james. ;)
<lifeless> thom: garh!
<jamesh> you could use djb's time synchronisation protocol/daemon instead
<bob2> hahaha
<bob2> djbqntp
<daniels> or tom lord's upcoming one
<sladen> good to see we're all agreed on the probability of /that/ happening
<lifeless> it really shows there is no such thing as bad publicity
<Mithrandir> why isn't baz in hoary?
<lifeless> it his. bazaar.
<Mithrandir> I can't eat unavailable dogfood
<lifeless> *is*
<pitti> lifeless: it's not in hoary right now
<lifeless> pitti - I was told that it is.
<pitti> lifeless: indeed I remember reading it on u-changes
<pitti> lifeless: but it's just not there
<lifeless> look for bazaar.
<Mithrandir> it's not there
<lifeless> elmo: ping
<lifeless> ^^^^^^^^
<Mithrandir> : tfheen@thosu ~ > grep -i baz /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hoary_main_binary-i386_Packages
<Mithrandir> : tfheen@thosu ~ >
<thom>     bazaar |    1.0.1-1 | hoary/universe | source
<thom> that would be a 100% build failure
<bob2> hah
<thom> have a nice day
* lifeless groans
<bob2> unless elmo marked it 'not for us' on all the buildds just to annoy us
<daniels> thom: you forgot hth
<lifeless> universe ?!
<thom> yeah, it's unseeded
<thom> but that's the least of your worries
<bob2> where do the bulid logs live?
<daniels> ./unit-chatter...passed
<daniels> ./unit-inv-idsarch: no arch user id set
<daniels> ...failed
<daniels> make[4] : *** [tests-timestamp]  Error 1
<bob2> ~lamont?
<daniels> OH MY GOD
<lifeless> oh garh.
<lifeless> thats fixed in 1.1
<bob2> hahaha
<daniels> http://people.ubuntu.com/~lamont/buildLogs/b/bazaar/
<daniels> that is *pathological*, dude.
<bob2> so is world hunger
<lifeless> I was sure I'd fixed it for 1.0 though. hmm.
<thom> go lifeless, it's your birthday... etc
<lifeless> :|
<bob2> it's differently fucked on amd64
<daniels> and ia64
<lifeless> yah, know that, patch done on concordia, not merged yet.
<bob2> ah
<lifeless> https://bugzilla.ubuntu.com/show_bug.cgi?id=3107
<daniels> man
<daniels> glibc is so crap
<Kamion> I'm glad tla's moving to something PORTABLE
<daniels> clearly it must be rewritten
<daniels> and the obvious candidate is THIS MAN
* azeem waits for further explanation or an url from daniels 
<Kamion> thom: it is seeded ...
<Kamion> supported: * bazaar
<bob2> azeem: (tla has it's own libc-alike)
<azeem> ah
<daniels> (and tom lord wants to rewrite glibc)
* azeem hopes it doesn't have a boot manager as well#
<thom> "alike in as much as it sucks, but not much else"
<daniels> azeem: don't give him ideas.
<thom> azeem: it probably has a download ui and an irc client
<daniels> ... shell ...
<bob2> and a CL interpreter
<Kamion> emacsarch!
<lifeless> guys guys guys, NIH is hardly new in the open source world. *cough djbb*
<Kamion> ... and we all love djb so much :-)
* azeem prefers djpig
<elmo> uh, who thought it'd be a good idea to use .bz2 compression?
<elmo> hello, katie.. running warty...
<Kamion> we didn't get .bz2 decompression into warty?
<Kamion> we can't use it at all in hoary then
<Mithrandir> Kamion: scott claims that predepending on dpkg is enough
<elmo> ii  dpkg                       1.10.22ubuntu2             Package maintenance system for Debian
<elmo> ^-- dpkg in warty
<Mithrandir> lifeless: so, when do we see a working baz in hoary?
<elmo> and WRT bazaar being in supported, the seed syncage stuff relies on binaries existing ...
<Kamion> Mithrandir: uh ... I guess that's technically true but it's kind of user-hostile
<Keybuk> elmo: since when did katie actually look at the data tar?
<elmo> since, for ever?
<lifeless> Mithrandir: I'd say, if someone applies that bugfix I linked to.
<Keybuk> ahh, you'll need to upgrade to the bzip2-supporting version then; I guess
<bob2> lifeless: don't you just need to do another upload?
<daniels> ARasfaweroiu32.,m431~0~9kldc cdbs
<elmo> Rejected: diveintopython_5.4-1ubuntu1_all.deb: debExtractControl() raised exceptions.SystemError.
<elmo> Rejected: diveintopython_5.4-1ubuntu1_all.deb: deb contents timestamp check failed [exceptions.SystemError: This is not a valid
<elmo> DEB archive, missing 'data.tar.gz' member] 
<lifeless> bob2 I didn't do the first upload
<Kamion> fabbione: your new kernel works for me
<Keybuk> \o/
<Kamion> bob2: mdz did it
<Kamion> (IIRC)
<bob2> oh
* lifeless is not a ubuntu maintainer
<Kamion> don't think lifeless' key is in the allowed list for Ubuntu anyway :)
<lifeless> AFAIHK
<bob2> lifeless: see, if I joined the distro team...
<Keybuk> pre-depend is sufficient from a distro POV, as it means by the time it's unpacked, a supporting version of dpkg-deb is installed :o)
<elmo> bob2: the distro would become a wasteland of unprecedent proportions?
<Mithrandir> Kamion: we're talking about selective bzip2-ing, AIUI
<daniels> cupsys is SO PSYCHOPATHIC
<Kamion> Mithrandir: yeah, I know
<Mithrandir> Kamion: and why would that be so user-unfriendly?  Because you force people to upgrade?
<Kamion> Mithrandir: no, because you can't use the dpkg in the previous stable release to examine the contents of a .deb before you upgrade it
<Mithrandir> that's true
<Keybuk> control, yes; contents, no
<Kamion> Keybuk: you mean dpkg -c works? how?
<elmo> dpkg-deb: file `diveintopython_5.4-1ubuntu1_all.deb' contains ununderstood data member data.tar.bz2    , giving up
<Kamion> or dpkg -x
<Keybuk> "ununderstood"
<elmo> go whichever  special person wrote THAT error message
<Keybuk> Kamion: no, I said contents doesn't work :)
<Kamion> Keybuk: oh, sorry, yeah
<bob2> elmo: I could finally upload glibc with that fix I've been waiting for...
<elmo> yeah, that's what we need - a man with sideshow's talents uploading critical infrastructure packages
* bob2 sprinkles some more sarcasm on elmo 
<daniels> elmo: i could give it a go if you wanted
* lifeless watches teh sarcasm boil off
<Keybuk> "freeze?  oh, sorry, I missed it ..."
<bob2> bah
* Keybuk sets mode +b *!*@bob2.user
<daniels> elmo: we could have thom maintaining critical infrastructure, OTOH ...
<daniels> elmo: glibc would gain a lot from bzip2!
<mjg59> daniels: Can you force people over there to try out the ACPI test stuff?
<daniels> mjg59: er, thom volunteers
<mjg59> Bah
<mjg59> I know it'll work for him
<daniels> we all have x40s now
<mjg59> We need more entries in http://www.ubuntulinux.org/wiki/PMTestingResults
<haggai> mjg59: I can try it on my T20 if you like
<mjg59> haggai: That'd be good
<haggai> mjg59: k, I'll let you know
<mjg59> My inclination at the moment is to push for swsusp as standard, and have str as an option that defaults to off
<azeem> mjg59: I could do it for an R51, provided I could just use your packages on testing/unstable
<azeem> daniels: monoculture is bad :)
<sladen> mjg59: hibernate still switches the vt to console before and afterwards/
<sladen> mjg59: ?
<mjg59> sladen: Yeah
<daniels> sladen: all of them do
<daniels> suspending from X is just so horrifically broken
<daniels> and not just on savage ;)
<mjg59> daniels: So, it turns out that VBERestore /is/ supported by most drivers
<sladen> mjg59: and if you get that /proc/unsuspend patch in for initrd, we get a  nice framebuffer on unhibernate too?
<daniels> mjg59: cool
<mjg59> sladen: I'm not quite sure what you mean there...
<mjg59> daniels: Is Xorg.conf regenerated on upgrade? Or only when a manual reconfiguration is tried?
<sladen> mjg59: wanting framebuffer during thaw... I'll test it and see what happens when I get there
<mjg59> sladen: It'll go initrd->resume->no more userspace->whatever userspace there was when you suspended
<mjg59> If you have framebuffer in the initrd, you'll be able to splash up something saying that it's resuming
<mjg59> But you won't be able to update that during the resume process
<sladen> mjg59: what it needs is the opposite of 'DONT_FREEZE' or whatever it's called.  So that a process started after initrd can continue to live after the rest of the frozen userspace is pulled back in
<mjg59> sladen: That's... awkward
<mjg59> I'm not sure how you could get that to work sanely - swsusp pretty much assumes that userspace does /nothing/ after a resume has been triggered
<daniels> mjg59: left alone if it's already there, so we can't enforce it, really
<mjg59> daniels: Hrm. Even if it hasn't been user-modified?
<daniels> mjg59: well, we could force remangling in that case
<sladen> mjg59: it might be doable with conditions attached like no-open-file-handles (which makes it pretty useless, but...).  The justification is that it can enable the User interaction/feedback Nigel Cunningham was suggesting/hacking into his kernel patch, without the cuntingness of it
<mjg59> sladen: Unf. Hrm. It's sufficiently warped that I'm not too keen to spend time looking at it, but do go ahead :)
<sladen> mjg59: is the current patch handy somewhere, I'll grab it on the netbook before I leave.  Which is, um, 2hours.  Must get out of bed.
<mjg59> sladen: Posted to l-k
<mjg59> It'll change a bit before inclusion
<sladen> hmmm.  suspend to USB key.  that is sick
<Mithrandir> sladen: that's brilliant!
<Mithrandir> so you can have saved sessions
<daniels> sladen: also, beautiful
<mjg59> Also: not going to happen
<mjg59> (not in the immediate future, anyway...)
<mjg59> Actually, there's no reason why you /couldn't/
<mjg59> Except that people would try to resume on different bits of hardware and break everything
<mjg59> And if someone booted your machine in the meantime, it'd go horribly wrong
<fabbione> Kamion: cool.. thanks
<fabbione> daniels: are you anywhere around?
<daniels> pitti: dude, has cupsys ever cleanly built for you twice in a row?
<daniels> fabbione: quiet room
<fabbione> daniels: the patch for the kernel?
<daniels> fabbione: hold on
<pitti> daniels: not really
<daniels> pitti: um, cool
<daniels> would you particularly mind if I made it do so?
<pitti> daniels: no, why should I :-)
<pitti> daniels: as long as you don't break the patches ... :-)
<pitti> daniels: I organized the patches to make it easy to merge to a new Debian revision
<daniels> more than they already are? :P
<daniels> ubuntu-nowebadmin.patch just totally breaks
<pitti> daniels: you should have seen the package before I reorganized the patches
<pitti> daniels: it was a PITA and took an hour to merge to a new revision
<pitti> daniels: if you manage to reorganize the japanese translation patch, it will get a lot easier
<daniels> mom should do most of it
<daniels> but, er, patching other patches
<daniels> Trying reversed patch debian/patches/ubuntu-nowebadmin.patch at level 0...1...2...failure (ignored).
<daniels> whoohoo cdbs
<daniels> pitti: um, so afaict jp-nowebadmin.ptch is never actually used (given it gets created after cdbs runs).  is it ever used?
<pitti> daniels: that's the tricky part of it
<pitti> daniels: look at debian/rules
<pitti> daniels: I checked, it works in the final package
<daniels> ... wow
<pitti> daniels: the mere fact that the japanese translation is patched in debian/rules and not by the patch system is the cause of the weird patching
<pitti> daniels: it uses uudecode in rules IIRC
<daniels> debian/local or something
* fabbione starts pointing the sodomotron towards daniels
<daniels> if you want to make my builds faster, great
<fabbione> daniels: where are you building?
<fabbione> and the major thing is.. are you using ccache?
<daniels> concordia, and not until now
<pitti> daniels: you can try to convert the japanese uuencoded thingy into a proper patch
<daniels> pitti: debian/local should do it
<pitti> daniels: however, this effort might be gone after the next debian release
<lamont_r> ew.  db4.3_4.3.21-3 build failure on ppc
<pitti> elmo: is there any reasonable fast machine where I could do some glibc test builds on?
<pitti> elmo: i. e. with the glibc build-deps?
<elmo> pitti: what arch?
<Mithrandir> pitti: use the print server? :P
<pitti> elmo: I don't really care
<pitti> elmo: I want to test an alternative gettext hierarchy
<daniels> fabbione: how exactly do you use ccache with the kernel?
<daniels>   # For some reason, this causes all modules to fail
<daniels>   #$command .= " CC=\"$cc\" HOSTCC=\"$hostcc\"";
<daniels>   $command .= " $Targets";
<pitti> elmo: I should be able to actually test it using LD_PRELOAD, so I don't need root
<elmo> daniels: export PATH=/usr/lib/ccache:$PATH
<pitti> elmo: s/LD_PRELOAD/LD_LIBRARY_PATH/
<daniels> elmo: thanks
<elmo> pitti: use concordia
<pitti> elmo: okay, thx
<elmo> [you're familiar with dchroot, I assume ?] 
<pitti> elmo: never used it, do I need to?
<elmo> yes
<elmo> dchroot -c hoary
<elmo> or do you need warty?
<lamont_r> Mithrandir: I'm going to upload enigmail
<pitti> elmo: hoary is okay
<elmo> okay, well I installed the build-deps in both chroots in any event
<pitti> elmo: thanks a lot
<fabbione> daniels:
<fabbione>   CC [M]   drivers/net/wireless/ipw2100/fsam7400.o
<fabbione> drivers/net/wireless/ipw2100/fsam7400.c: In function `fsam_bios_routine':
<fabbione> drivers/net/wireless/ipw2100/fsam7400.c:132: error: impossible constraint in `asm'
<fabbione> make[6] : *** [drivers/net/wireless/ipw2100/fsam7400.o]  Error 1
<fabbione> KTHXBYE
<pitti> elmo: pitti@chinstrap:~ $ host concordia
<pitti> Host concordia not found: 3(NXDOMAIN)
<pitti> elmo: ?
<elmo> pitti: concordia.ubuntu.com, sorry
<elmo> and don't forget to add the ssh rune
<thom> concordia.ubuntu.com
<thom> gar, too slow
<Mithrandir> lamont_r: huh?  I did a couple of hours ago, or did it fail?
<elmo> see MachinesOverview on the s3kr1t wiki
<daniels> fabbione: worksforme
<lamont_r> needed /Build-Depend/s/$/, gcc-3.4 [amd64] / :-(
<Treenaks> Who do I go to to get an ubuntu-nl mailinglist for Dutch-language support?
<Mithrandir> lamont_r: ah, of course.
<fabbione> daniels: ppc
<thom> Treenaks: jdub
<lamont_r> uploaded
<daniels> fabbione: don't try to build i386 drivers on powerpc, then.
<Treenaks> thom: ok, I'll drop him a mail
<lamont_r> elmo: what do we need to do to get binutils happy on i386?
<fabbione> daniels: that's because the patch isn't arch clean as i was telling you before ;)
<fabbione> s/before/a few days back/
<elmo> lamont: someone needs to decide what to do about that tcl8.4 bug - personally, I think forwarding the problem upstream, then  reverting the patch until they fix it, is a viable way forward
<lamont_r> 'k.  is that on your list, or should I deal with it?
<daniels> fabbione: dude, it's pretty easy, just don't put it into the powerpc config
<lamont_r> np either way, of course.
<daniels> fabbione: it's not powerpc hardware, it's only on i386
<elmo> lamont: I'd rather a distro person ran with it from here...
<lamont_r> right
<fabbione> daniels: kid.. i know the solution already... it was just show you what i meant with "non clean patch".
<daniels> fabbione: what do you mean, non-clean patch?
<daniels> fabbione: my sources never, ever, touched the powerpc config
<Mithrandir> is somebody smoking in the bofh room or something?
<daniels> so I honestly don't see how you can claim the patch is unclean when there was no problem until you attempted to build a very i386-specific module for powerpc
<daniels> it's utterly nonsensical, and that's why I didn't do it
<mjg59> daniels: To be fair, the kconfig should probably prevent it from being selectable
<Mithrandir> Kamion: did you need any USB sticks?
<fabbione> daniels: patches that allows Kconfig to select a i386 driver on a ppc are not clean. What is difficult to understand about it?
<fabbione> daniels: i don't ge prompted for wireless stuff on sparc..
<fabbione> + the patch you have done changed the config via dpatch that is basically wrong
<daniels> if it's so difficult, you can throw the patch straight back to me and i'll do my own k-s upload with fsam7400 and the asm stuff
<fabbione> daniels: dude.. you are out of your way
<fabbione> daniels: 100% out..
<fabbione> i am just showing you something
<fabbione> to explain to you what i meant 3 days back with "non- clean patch"
<fabbione> and you go all high up
<fabbione> the patch is merged. <- full stop
<fabbione> it's there and it compiles
<Kamion> Mithrandir: yeah, would be nice thanks
<fabbione> why do you want me to send back stuff to you
<daniels> fabbione: the patch seems to make you pretty upset
<Mithrandir> my emacs is on crack:  it thinks my battery is at 102%.
<Treenaks> isn't that a feature of emacs.. it being on crack and all
<_rene_> heh. just wanted to say that, too ;-)
<Mithrandir> pfft, it's on crack in a good sense of the word
<Treenaks> Mithrandir: on your way back, stop by in Amsterdam ;)
<fabbione> daniels: me? upset? ahahaha you have never seen me upset :P
<Keybuk> Kamion: merge-o-matic previous paths are now more Colin-friendly
<Mithrandir> Treenaks: I was there on my way here, I'll be there on my way back, I was there a month or so ago on my way to and back from Italy.
<Treenaks> Mithrandir: hm ok.. I left from there as well (living almost next to it...)
<Kamion> Keybuk: bonus, thanks
<Mithrandir> Treenaks: it's a nice city.
<whiprush> has anyone ever brought up ubuntu on alphas? (as a potential platform I mean)
<Treenaks> aren't alphas close to dead?
<whiprush> unfortunately. :-/
<thom> alpha is cool
<thom> sadly mine is way underpowered to try and do a port on
<whiprush> I have like 11 here and I'd hate to see them go to waste.
<thom> and i don't have time, either
* lamont_r needs some fontconfig-literate person to look at #3442
* thom aims lamont at daniels and pulls the trigger
<daniels> no
<daniels> fonts hurt my head
<lamont_r> he says that, but he's reading the bug..
<daniels> ... and now my head hurts
<fabbione> where is mdz?
<thom> sleepin'
<jdub> lamont_r: we should not be setting anything in local.conf
<fabbione> oh
<lamont_r> jdub: taht's re 3442?
<jdub> yeah
<lamont_r> jdub: ok
<lamont_r> btw, your bof??
<lamont_r> that was to start 36 min ago...
<jdub> yeah, mdz is asleep
<lamont_r> ah, opk
<thom> daniels: do you have a new i810switch?
<daniels> thom: 'new'?
<lamont_r> pitti around?
<pitti> lamont: right here f**ing up libc6 :-)
<lamont_r> heh... in the bof room?
<pitti> lamont: yeah
* lamont_r walks over
<daniels> thom: ideally we should just set up clone and devicepresence per default
<daniels> so you can plug in and get working clone
<bob2> oooh
<daniels> thom: this is one of the things my i-can't-believe-it's-not-discover1 tool is designed to solve
<lamont_r> elmo: bof on..
<mjg59> daniels: Doesn't that result in the VGA port being driven even without hardware attached?
<daniels> mjg59: pretty much, yeah
<daniels> mjg59: is power consumption an issue there?
<thom> daniels: ok, so my question was really: "How do i make video come out of my vga port"
<thom> since currently i have no projected love
<Mithrandir> thom: where di you find coke?  New supplies arrived downstairs?
<thom> yeah
<thom> my slave^W^Wdaniels brought me some
* lamont_r realizes that he left his supplies in the other room. grumbles.
<mjg59> daniels: I haven't actually tested, but I'd assume it'd draw more power
<mjg59> We need unified hotkeys and HAL love
<daniels> thom: not sure I have enough sugar in my system to set up VGA for you though ...
<daniels> mjg59: i doubt it would run too much more, but yeah, fair point
<Mithrandir> lifeless: any reason why there's no TLAEDITOR or ARCHEDITOR environment variable?
<lifeless> because EDITOR exists.
<lamont_r> lifeless: does it use EDITOR if the others exist?
<lamont_r> er, don't exist?
<lifeless> it only uses EDITOR
* lamont_r re-reads.
<lamont_r> doh
<lifeless> :)
<daniels> Kamion: * 901_debchangelog.vim.diff: Add warty and hoary to debchangelogTarget.
<daniels> Kamion: beverage-of-choice is yours tonight
<mjg59> thom: You want i855crt, anyway
<mjg59> i810switch doesn't have a whole lot of 855 love
<Kamion> daniels: Chris reminded me about it
<daniels> mjg59: yeah, he's going to come over here with Coke and his laptop when the BoF is over and I'll VGA him up
<mjg59> Is the mataro schedule up anywhere?
<daniels> the only thing that is shitting me about my multi-screen setup at the moment is that I keep losing my schedule
* Mithrandir should probably do the same for devscripts-el
<daniels> mjg59: w.u.c/wiki/ConfAgenda
<mjg59> Ta
<thom> mjg59: crap. that might explain it :-)
<mjg59> daniels: Why is dri so hard with xinerama?
<daniels> mjg59: don't know, tbh
<daniels> mjg59: seems that most implementations play funny buggers with how they allocate memory and stuff, or maybe they decided that locking was Just Too Hard
<daniels> mjg59: either way, the only ones to have fixed it are ati, really
<daniels> (mergedfb)
<daniels> thom: for simple clone stuff, i855crt swcursor on 1024x768@70, should suffice
<daniels> thom: else, 192.168.0.93/~daniels/xorg.conf
<lamont_r> I _HATE_ zsh, I do.
<mjg59> Doing xinerama for the 855 CRT out makes sense - you can have your next slide on the LCD
<Mithrandir> lamont_r: it probably hates you too, given that it reads your mind.
<mjg59> But having to kill X in order to switch between having DRI or not is a pain
<thom> daniels: ah, neat
<daniels> mjg59: yeah
<daniels> mjg59: it's pretty crap
<Mithrandir> lamont_r: could you run linux32 uname -a on an ia64 box for me?
<mjg59> Things not to do with an X40:
<mjg59> Jam headphones into the USB connector
<daniels> mjg59: ...
<daniels> apart from bzzt bzzt zap
<chrisa> Impressive
<mjg59> Immediate power down, needed to remove the battery and AC
<daniels> oops.
<azeem> jdub: dude?
<Mithrandir> mjg59: I saw the same thing when playing around with live wires connected to my PSU.  Very Fast Shutdown.
<Mithrandir> azeem: he's BOFing
<azeem> ah
<azeem> thanks
<lamont_r> linux32 uname -a
<lamont_r> Linux hooker 2.4.25-hpe-9-mckinley-smp #1 SMP Wed Aug 11 11:59:05 UTC 2004 ia64 GNU/Linux
<lamont_r> # uname -a
<lamont_r> Linux hooker 2.4.25-hpe-9-mckinley-smp #1 SMP Wed Aug 11 11:59:05 UTC 2004 ia64 GNU/Linux
<Mithrandir> thanks
<fabbione> lamont_r: is that a "normal" debian kernel?
<lamont_r> fabbione: I think it is
<lamont_r> dunno - that's an elmo question
<Mithrandir> fabbione: looks like one.
<fabbione> ok
<lamont_r> fabbione: any progress on the ia64 kernels?
<fabbione> lamont_r: gimme a hoary chroot and i will give you a kernel :-)
<fabbione> lamont_r: i was just checking while sparc and ppc are finishing
<fabbione> we don't need any arch specific patch from 2.6.8 or higher that makes it very simple
* lamont_r gently lifts libunwind7, and repeatedly smashes it into the floor and wall.
* lamont_r hands fabbione a token that he can give elmo in exchange for a hoary chroot.
<lamont_r> and that token is: floe:/usr/lib/debootstrap/scripts/hoary.buildd
<lamont_r> er... s/floe/hooker
<lamont_r> Kamion: we have a debootstrappable ia64 archive...
<lamont_r> wanna do the magic to generate hoary.buildd for it?
* lamont_r has a working hoary.buildd, but not the source to auto-build it.
<Kamion> lamont_r: I don't autogen hoary.buildd, only hoary
<Kamion> but I'll do hoary, sure
<lamont_r> ok
<Kamion> is it germinatable?
<Kamion> oh, we'll find out :)
<lamont_r> probably...
<lamont_r> still kernel-less, of course.
<Kamion> yeah, that should be ok
<lamont_r> chinstrap:~lamont/hoary.buildd is a good buildd script.
<lamont_r> which would be good to deliver in either case...
<Kamion> mkay, will try to merge
<lamont_r> interesting font... ~ and - look almost the same.
<lamont_r> - is a bit shorter is all
<lamont_r> Kamion: libelfg0 is in the archive for ia64...
<lamont_r> which is to say, why didn't it show up?
<lamont_r> ah, probably due to ltrace
<lamont_r> ltrace is !ia64
<fabbione> lamont_r: same thing on sparc
<jdub> azeem: dude?
<Kamion> lamont_r: ah, ok, fine
<mxpxpod> jdub: is gnome-bluetooth in universe or main yet?
<lamont_r> Kamion: so anything build-depending on libreadline-dev should get libreadline4-dev?
<pitti> elmo: if you find a second, please sync powerprefs from sid
<lifeless> Keybuk: did you ahve a good gpg[v]  python wrapper? I need to determine the author of a clearcsigned thing.
<Keybuk> no
<jdub> mxpxpod: universe
<mxpxpod> jdub: ok
<mxpxpod> jdub: who do I talk to to get it compiled for powerpc?
<thom> mdz - "I AM GOING TO FIX RHYTHMBOX: IT IS NOT AN ERROR FOR AN HTTP STREAM TO END"
<Treenaks> thom: vim signatures.fortune
<chrisa> mxpxpod: psst, there's a 'source' argument to apt for a reason
<mxpxpod> chrisa: yeah, but if someone else wants to use it as well... we're not gentoo...
<lamont_r> mxpxpod: looks like missing build-depends
<mxpxpod> lamont_r: ah, ok
<lamont_r> patches welcome
<lamont_r> :-)
<lamont_r> http://people.ubuntu.com/~lamont/buildLogs/g/gnome-bluetooth/0.5.1-1ubuntu5/gnome-bluetooth_0.5.1-1ubuntu5_20041202-1107-powerpc-failed 
<lamont_r> elmo: please sync pwlib
<elmo> powerprefs |    0.4.6-3 | hoary/universe | source
<lamont_r> -5.1
<elmo> pitti: it's already synced
<pitti> elmo: oh, sorry. Then the merge bug is moot, I close it. Thx
<elmo> lamont: done
<lamont_r> pitti: btw, I figured out why we can't sync like we were discussing on the plane. and uploaded my package
<elmo> pitti: you have locales
<pitti> lamont_r: I already fixed hpsockd in warty-security
<pitti> lamont: I hope you didn't upload it again?
<pitti> elmo: thx
<lamont_r> Kamion: it's worse than you thought (readline5)
<pitti> lamont_r: what breaks? wrong distribution in debian/changelog?
<lamont_r> pitti: only one thing.  any library/etc that you Depend on that is newer...
<daniels> Kamion: 
<daniels> The following lines in the control files differ (wdiff output format):
<daniels> ----------------------------------------------------------------------
<daniels> Version: [-2.6.9-1-]  {+2.6.9-2+}
<daniels> Installed-Size: [-24544-]  {+47764+}
<daniels> Kamion: (that's with asm-*)
<lamont_r> Kamion: all of the packages built on the other 3 architectures _before_ libreadline5 showed its face.
<lamont_r> any upload that happens now will use libreadline5 (to satisfy libreadline-dev)
<lamont_r> I'm fixing that...
<Kamion> daniels: uh ... huh. 23MB is not entirely to be sneezed at :(
<Kamion> even on installed systems disregarding CD space, that sucks :-/
<daniels> Kamion: aye
<daniels> fabbione: concordia:~daniels/kernel/l-i/install-all-asm-headers.diff
<fabbione> daniels: good!
<fabbione> daniels: it is enough to remove these lines? what about the symlinks?
<daniels> hm, we need symlinks for each of l-h, I suppose
<daniels> right, hold on a sec
<daniels> kernel-package is frigging obtuse
* Keybuk wants galactica.ubuntu.com
* Keybuk suddenly realises he's missing Battlestar Galactica at the moment :-/
<jdub> mxpxpod: probably just my (and edd's) continuing build-dep lameness
<jdub> mxpxpod: i'll check the logs later
<mxpxpod> jdub: heh, thanks
<fabbione> food time 
<pitti> fabbione: ++ ++ ++
<Treenaks> fabbione: yeah, great plan ;)
<pitti> fabbione: shall we meet in the reception hall?
<pitti> fabbione: seb128 will come too
<seb128> jdub, http://mail.gnome.org/archives/ is b0rked !
<Treenaks> pitti: do you guys mind if I join?
<pitti> Treenaks: no, why should we :-)
<Treenaks> pitti: well.. ;)
<Treenaks> pitti: see you downstairs then?
<Treenaks> or wait for the BOF to end?
<pitti> Treenaks: sure, in a few minutes
<pitti> Treenaks: the BOF has runned for several hours now
<pitti> Treenaks: I'm not sure how long it will still take
#ubuntu-devel 2004-12-18
<mjg59> fabbione: Around?
<mjg59> fabbione: I've sent mail about 2.6.9 patches
<lexhider> can anyone confirm a bug I'm experiencing. Compose a mail in evolution with a word not in dictionary [e.g. Ubuntu]  and try to add it to dictionary. Right-click add-to-dict causes an evolution crash. Right-click check-spelling and then adding to dictionary causes all of gnome to lock up and so I have to drop back to console and kill evolution for things to work OK again.
<trulux> hey lamont 
<lexhider> i'll post to list, bye
<usual> the wiki mentions inotify being added to hoary, has it been added? if so I can't seem to find it.
<usual> nm i found it
<justdave> Thunderbird 1.0 is out.  When do we get it in Hoary?  ;)
<calc> 1.0 is out already?
<justdave> yep
<calc> i just installed 1.0rc gotta upgrade ;)
<justdave> they decided they didn't feel like staying up late tonight, and it was ready to go, so they did midnight eastern instead of 1am pacific
<justdave> they'd been advertising it would be out 1am pacific on the 7th
<Mithrandir> thom?
<thom> Mithrandir: ?
<Mithrandir> thom: the dhcp server advertises a non-existent DNS server
<thom> yes
<thom> nada i can do
<Mithrandir> set up a DNS server on the ip address?
<thom> it's given me correct info
<Mithrandir> it just gave Karianne wrong info
<thom> 192.168.0.2 ?
<Mithrandir> yeah
<thom> hrm, i can possibly hack round it, not sure
<Mithrandir> would be nice; it's not the first time it's happened and she's not the only victim.
<thom> easier than i thought, fixed
<Mithrandir> thanks a lot
<thom> elmo/mdz/jdub: shall i commit the seed additions?
<jdub> thom: hrm, wait for mailing udevel, i think
<thom> kk
<seb128> grrr, is that only me or people star using the devel list as an user one ?
<jdub> yeah
<fabbione> the bof room is open
<thom> fabbione: yeah, but we're supposed to be using the main room for hacking
<fabbione> thom: shushhhhh
<fabbione> ;)
<Mithrandir> thom: aren't we supposed to use the hack room for hacking?
<thom> Mithrandir: there are gonna be bofs in it
<fabbione> Mithrandir: he is english.. he has a distorted view of the world :P
<thom> i can get jane to come and beat you up
<Mithrandir> can you make her bring tea while doing it?
* fabbione hugs thom
<fabbione> ahahah
<Mithrandir> are there any evolution hackers about, whom I may beat up?
<mdz> lifeless, http://people.ubuntu.com/~lamont/buildLogs/b/bazaar/1.0.1-1/ ?
<lifeless> https://bugzilla.ubuntu.com/show_bug.cgi?id=3107
<carlos> enrico: http://www.loc.gov/standards/iso639-2
<enrico> carlos: cool!
<haggai> elmo: ehhm, I had main=hoary and universe=warty in my sources.list.. \o/
<Keybuk> elmo: I don't guarantee that mom won't get the category of patch wrong, I just guarantee that when it gets it wrong it will get it /amusingly/ wrong
<lamont_r> haggai: interesting...  how'd it do?
<haggai> lamont_r: surprisingly well, I only noticed because the available apt-proxy was the testing, not unstable version
<haggai> lamont_r: although meld was broken and I guess that was the reason why
<lamont_r> ah
<Mithrandir> seb128: what's the chance of bugs I report in evo actually being fixed?
<fabbione> mjg59: you around?
<seb128> Mithrandir, depending of the bug ...
<Mithrandir> seb128: mostly UI issues.
<seb128> Mithrandir, so pretty low
<seb128> there is a lot of crasher and big issues to deal with first
<Mithrandir> stuff like enter not doing the right thing when editing an appointment, superflous buttons, the fact that if you select a read-only calendar, suddenly anything you type in is interpreted as menu shortcuts.
<Mithrandir> should be simple enough to fix if you know the structure and _really_ annoying when you use it
<seb128> right
<seb128> opening a bug doesn't hurt
<seb128> but not sure on quick it'll be fixed
<lamont_r> Keybuk: what became of the +b1 binNMU thing?
<elmo> fabbione: done
<Mithrandir> seb128: I guess using upstream's bugzilla makes sense, then.
<Keybuk> we're having a BOF about that I think here?
<seb128> Mithrandir, yes
<lamont_r> Keybuk: ah, ok
<fabbione> elmo: what's the name of the porting box?
<elmo> oh, meh, it'd help to bind mount home wouldn't it
<elmo> fabbione: halley.u.c but one sec
<fabbione> elmo: please remember ccache as well :-)
<fabbione> sure..
<elmo> yeah, ccache is there
<elmo> and home and proc are there too
<fabbione> 1337!
<fabbione> elmo: echo hoary > /etc/debian_chroot
<elmo> I don't think that works because of the sarge base system
<elmo> oh, no, it does, I'm a muppet
<elmo> done
<fabbione> thanks
<lamont_r> seb128: ??
* lamont_r walks
<daniels> elmo: could you please install davis:~daniels/binutils/*.deb in the hoary chroot?
<daniels> fabbione: new kernel diff in concordia:~daniels/kernel/l-i/install-all-asm-headers.diff
<fabbione> daniels: ok
<daniels> fabbione: (debdiff shows just the asm-* stuff changing)
<daniels> fabbione: for i in linux-image-2.6.9-1-amd64-{generic,k8{,-smp},xeon} linux-headers-2.6.9-1{,-amd64-{generic,k8{,-smp},xeon}}; do echo -- $i; echo; echo; echo; debdiff ${i}_2.6.9-{1,2}_amd64.deb; done | less
<daniels> fabbione: run that in concordia:~daniels/kernel/l-i if you like
<thom> NetworkMagic BOF in the BOF room now
<thom> heel!
<daniels> elmo: (you might want to diff the testsuite, etc; the build tree is lying around in there)
<fabbione> daniels: ok i will in a few.. i am giving ia64 port love to the kernel right now
<daniels> fabbione: cheers
<lifeless> ~.
<lifeless> garh
<fabbione> daniels: the patch seems to work :-)
<fabbione> daniels: nice job.. let me apply it
<daniels> fabbione: thanks
<daniels> the binutils testsuite is running on concordia atm
<seb128> daniels, so, where are the stuff I need to get a decent resolution on my laptop ? :)
<fabbione>   Changes by Daniel Stone:
<fabbione> 
<fabbione>   * Modify debian/header-install and debian/post-install in order to ship all
<fabbione>     the asm headers in the linux-header package and produce proper symlinks
<fabbione>     from the specific flavour. This circumnvent a problem on powerpc (mainly)
<fabbione>     that uses a bunch of m68k asm includes.
<fabbione>     This fix will allow also the build of the new linux-restricted modules.
<fabbione> elmo_away: is there any problem with halley?
<pitti> lamont: you uploaded hpsockd 0.13.0.14
<pitti> lamont: however, I already fixed hpsockd in 0.12ubuntu0.1
<daniels> seb128: try this - http://perso.wanadoo.fr/apoirier/
<pitti> lamont: does this version fix anything else than the recent DoS?
<daniels> fabbione: 'This fix will also allow the new linux-restricted-modules to build on powerpc.'
<pitti> lamont: if not, it needs to be removed from the queue
<seb128> daniels, ok, thank
<seb128> thanks
<daniels> no worries :)
<pitti> lamont_r: ^
<fabbione> elmo_away: can you ssh to halley???
<fabbione> i can ping it from within the dc
<fabbione> but ssh hangs
<fabbione> mdz: what about that USB_BLK_UB thingy? 
<fabbione> are we sure 100% that we have to kill it?
<fabbione> the 2 errors i found around where not related to usb but to the scsi layer on top of usb
<Kamion> 09:28 < svenl> Damn, unmounting the usb stick freezes this 2.6.9 kernel, i suppose this is considered an RC bug ...
<Kamion> (if that's the same thing ...)
<fabbione> Kamion: nope.. that's another bug
<fabbione> Kamion: they are both tracked on kernel bugzilla
<fabbione> but i am not going to spend time to explain to sven how to search
<Kamion> of course :-)
<fabbione> seb128: can you push mdz on irc?
<fabbione> mdz: read above
<mdz> fabbione: unset CONFIG_BLK_DEV_UB
<fabbione> ok
<mdz> confirmed to fix my problems
<azeem> jdub: I just wanted to point you to the multisync packages for hoary yesterday evening, but then had to go and decided to mail ubuntu-users
<pitti> elmo: can you please remove hpsockd 0.13.0.14 from the warty-security queue?
<pitti> elmo: don't beat up me, I didn't upload it :-/
<fabbione> elmo: halley is dead
<fabbione> elmo: i can't ssh to it anymore
<jdub> azeem: saw your mail :-)
<jdub> azeem: good stuff :)
<elmo> pitti: ?? who did?
<elmo> fabbione: works for me?
<fabbione> elmo: i can ping, but not ssh
<fabbione> now i can again
<fabbione> weird
* Treenaks throws #4452 and #4453 at seb128 
<seb128> what about them ?
<Treenaks> oh nothing special
<seb128> so why throwing them on me ? :)
<Treenaks> seb128: I am :)
<seb128> "why" is the question ? :p
<Treenaks> seb128: oh, just for fun
<seb128> ok ;)
* Mithrandir scratches head.
<Mithrandir> something is dropping loads of packets on the floor.
<bob2> it was kinnison
<Mithrandir> nneeeeewwww freeeesshh craaaccckkk
<thom> http://www.elmundo.es/navegante/2004/12/07/softlibre/1102413723.html
<Treenaks> Mithrandir: even more?
<Mithrandir> Treenaks: yeah, I'm working on ia32-libs.
<Mithrandir> and have a new, big, fresh supply of crack
<Treenaks> Mithrandir: I _only_ have ia32 libs here 8)
<Treenaks> (but then, I don't have an amd64 laptop)
<Mithrandir> neither do I, but I have access to real machines.
<elmo> can I add bazaar-doc to supported under the 'Obvious' rule ?
<seb128> lamont, do you know why gnome-panel doesn't build ? it doesn't find libgnome-menu-dev which is in main ...
<elmo> seb128: I only recently promoted
<elmo> +it
<seb128> "recently" like "10 min ago" ?
<elmo> uh, dunno, last hour or so
<elmo> it's in Building state now anyways
<seb128> ok, thanks
<lamont_r> elmo: bazaar-doc sounds right and good.
<daniels> elmo: could you please install binutils on davis and concordia and also try the test suite? ~daniels/binutils/
<lamont_r> %bazaar fits into that category, no?
<elmo> huh?
<elmo> how could binutils not be installed?
<mjg59> fabbione: You called?
<elmo> do you mean upgrade?
<daniels> elmo: yeah
<fabbione> mjg59: yup.. i got the patches, thanks. i will apply them in -3.
<mjg59> fabbione: Rock. They look ok?
<fabbione> mjg59: i need to get -2 out today with ia64 love
<fabbione> mjg59: i reviewed them with mdz and they look ok 
<elmo> Kamion: do we have seed  mod notification yet?
<fabbione> mjg59: mind to enlight me about the initrd changes that needs to be done?
<fabbione> mjg59: are we safe to upload the kernel without these changes?
<fabbione> mjg59: or the 2 needs to be alligned?
<mjg59> fabbione: Uploading without the initrd-tools changes is fine, but swsusp won't work
<mjg59> I've filed a bug against initrd-tools in bugzilla with a patch to it
<lamont_r> pitti: it's on its way
<mjg59> Bug #4444
<fabbione> mjg59: thanks
<fabbione> mjg59: of course the patch doesn't need to ensure that the module is loaded, right?
<fabbione> and it doesn't break with older kernels...
<mjg59> fabbione: Yeah - swsusp can't be modular
<mjg59> Oh, hrm. It probably wants to check that the file exists before echoing into it.
<daniels> fabbione: will -2 have asm-* love?
<fabbione> daniels: yes. already applied
<fabbione> daniels: do you have time to upload xorg ubuntu5 with the sparc support back?
<fabbione> mjg59: mind to review the patch so i can upload * today?
<Kamion> elmo: hm, no, not yet
<mjg59> fabbione: Sorry, which patch?
<Kamion> elmo: do you need it?
<fabbione> mjg59: the one to initrd?
<fabbione> <mjg59> Oh, hrm. It probably wants to check that the file exists before
<fabbione>           echoing into it.
<mjg59> Oh, right. Yeah, will do.
<daniels> fabbione: brilliant
<daniels> fabbione: yeah, sure
<mjg59> It just wants a if [ -f ]  around the echo
<elmo> kamion: no not particularly, just curious
<mjg59> Pavel wants a couple of minor changes to the swsusp code, but nothing significant
<fabbione> mjg59: i am dealing to require a higher version of initrd tools to ensure that swsup works as it should.. but i need to be 100% sure that there are no regressions with older kernels. 2.6.9 is not the default yet.
<mjg59> fabbione: Ok, no problem
<fabbione> mjg59: i still have to apply the patches, so if you want to change stuff around go ahead.
<thom> fabbione: http://planetarytramp.net/linux-2.6.3-printopen.patch KTHXBYE ;-)
<Kamion> Resolving planetarytramp.net... failed: Host not found.
* Kamion prepends www.
<thom> hrmph, that should work
* thom fixors dns
<thom> cack, i can't from here
<Mithrandir> thom: you tramp! :P
<thom> hohum
<mjg59> thom: Dude, what does that actually do?
<mjg59> Oh, and is the laptop BOF today?
<thom> mjg59: exactly what it says on the tin
<thom> yes
<fabbione> Kamion: WORKSFORME
<fabbione> thom: weird patch... but we can work on it i guess
<mjg59> thom: Ok - do you have time for a quick chat about it?
<Kamion> planetarytramp.net: warning: glueless NS dns0.positive-internet.com ([80.87.128.65]  dns0.positive-internet.com, in glue from [192.43.172.30]  i.gtld-servers.net, server for net)
<Kamion> planetarytramp.net: warning: glueless NS dns1.positive-internet.com ([80.87.128.65]  dns0.positive-internet.com, in glue from [192.43.172.30]  i.gtld-servers.net, server for net)
<Kamion> that might not help, although it could just be chiark-named-conf being ultra-picky
<thom> prolly chiark
<thom> mjg59: sure
<Kamion> well, gluelessness can be a real problem
<thom> Kamion: it can be
<Kamion> depends whether it's circular or not I guess :)
<fabbione> mjg59
<fabbione> mjg59: i asked thom if it is possible to apply that patch, but make it "active" only on a boot parameter
<fabbione> i am pretty sure that will be handy while you guys monitor the hd activity
<fabbione> and it would allow people to test and track without having to recompile a kernel
<thom> it's for readahead, mostly. there are already kernel interfaces to find out what tries to write to disk
<mjg59> Ah, right
<mjg59> thom: Probably need to discuss what sort of PM is going to be the default in Hoary
<mjg59> thom: I think StD can probably be on by default. StR ought to be supported but disabled. APM ought to be loaded if acpi isn't running.
<thom> apm is loaded correctly as of yesterdya
<pitti> elmo: scponly is fixed and published now
<mjg59> thom: Rocking
<mjg59> Also, force more people to test these things
<mjg59> fabbione: Oh, the kernel possibly needs to pre-depend on the newer initrd-tools, thinking about it...
<elmo> pitti: sweet, thanks
<mjg59> Or is depend sufficient?
<mjg59> thom: Issues with suspend are primarily how it gets exposed to the UI
<mjg59> Not everyone who has working StR has a sleep button, so there needs to be some sort of UI element to get them there
<Mithrandir> mjg59: "lid" :)
<thom> so we need some way of exposing that in gnome similar to windows' shutdown menu
<thom> we also need some way of letting peoople choose whether they want to suspend on lid closure etc
<mjg59> Mithrandir: Yeah, but then people bitch that they don't want the machine to sleep on lid closure
<Mithrandir> mjg59: they are wrong. (:
<mjg59> thom: Indeed. Knocking up something g-s-tish shouldn't be hard
<thom> aye
<mjg59> Other laptop issues: cpufreq (sladen's been working on that), hotkey support (every machine has different ways of doing hotkeys, all of them differently broken)
<mjg59> For machines which have support for switching on the LCD, we probably want to do that. But that's dependent on which module they use.
<fabbione> mjg59: i think Depends should be more than enough
<mjg59> fabbione: Does that guarantee that it's unpacked before the kernel is unpacked?
<mjg59> Oh, actually, that doesn't matter
<mjg59> It'll be unpacked before postinst is run, right?
<elmo> yes
<mjg59> Ought to be good, then
<thom> daniels: 
<thom> thom@jackass:~ $ madison libxinerama1
<thom> libxinerama1 | 6.8.1-1ubuntu4 |         hoary | amd64, i386, ia64, powerpc
<thom> thom@jackass:~ $ madison libxinerama-dev
<thom> libxinerama-dev | 6.8.1-1ubuntu4 |         hoary | amd64, i386, ia64, powerpc
<thom> thom@jackass:~ $
<fabbione> mjg59: as elmo said
<daniels> thanks
<elmo> thom: madison takes arbitrary numbers of arguments, or just 'madison -r xinerama'
<thom> the things you learn
<thom> elmo: thanks :-)
<elmo> seb128: err, don't listen to that bong smoking hippy Waugh - how big are -dbg packages for *gnome* going to be?
<Mithrandir> elmo: smaller than ia32-libs-gnome-make-elmo-go-bong-bong
<lamont_r> Mithrandir: is there anything larger than ia32-libs?
<Mithrandir> lamont_r: ooo-amd64?
<lamont_r> heh
<Mithrandir> lamont_r: source or binary size?
<lamont_r> binary
<lamont_r> then again, source can be interesting too...
<daniels> o/~ in the ning nang nong, where the cows go bong
<Mithrandir> ia32-libs is smallish installed-size
<thom> "ish"
<Mithrandir> only about 18MB
<Keybuk>  and the monkeys all say boo!
<Mithrandir> thom: we're talking about _computers_, not pocket calculators.
<Mithrandir> lamont_r: it's the source size which is _bad_ for ia32-but-amd64 packages.
<daniels> Keybuk: in the nong ning nang, where the mice go clang, and you just can't stop them when they do!
<mjg59> fabbione: New patch on #4444
<fabbione> mjg59: cool
<mjg59> fabbione: daniels: Ok, it turns out video_post blows up on some machines. This is /probably/ due to the code jumping to chunks of video BIOS that have been unmapped after video boot. Any ideas on how to work around this?
<daniels> mjg59: let me check out the source
<fabbione> mjg59: is that X specific?
<fabbione> mjg59: if so daniels is your bitch :P
<daniels> video_post != X
<daniels> but yeah, I'll look at it
<mjg59> The problem is, that there tend to be at least two jumps (jump from c000:0003 to wherever the code actually is, do some code, jump somewhere else, finish up)
<mjg59> And the first set of code is often there, but the second set is sometimes missing
<mjg59> So it gets part way through init and then crashes out
<smurfix_> Klar, kein Problem.
<smurfix_> Ich glaube, das ist
<smurfix_>  noch etwas zu frh, *sigh*
<smurfix_> *sigh* even
<elmo> smurfix: -EWIN?
<fabbione> elmo: sparc-ping?
<smurfix_> elmo: something like that. :-/
<bob2> bah, unplugging power made my screen go dim, and function-brightness-up doesn't help
<mjg59> bob2: Yeah, maximum brightness is lower on battery
<Mithrandir> mjg59: unless you change that in the BIOS
<daniels> oh my god that code is so much crack
<mjg59> daniels: Well, yeah
<mjg59> We could do it in vm86 instead, which is less code, but doesn't work on amd64
<daniels> mmm, yeah
<Mithrandir> aaammmmdddd666644444 ccccrrrraaaccckkkk
<Mithrandir> mmmmmmmm
* daniels reassigns to Mithrandir.
* Mithrandir eats daniels and mjg59
<daniels> mjg59: hmmm
<daniels> mjg59: might be worthwhile stealing chunks of drivers/vesa and vbe from xorg
<mjg59> daniels: The problem is that re-POSTing isn't a VBE thing
<daniels> mjg59: right, but those at least have a pretty sane int10 implementation
<mjg59> The int10 code in that is ripped straight out of xfree
<mjg59> (That's why everything starts XF...)
<daniels> yeah
<daniels> seems to have been horrifically hacked tho
<daniels> bbiab
<lamont_r> definite shortage of tin foil here.
<Mithrandir> that's because you're all throwing it away
<Mithrandir> daniels: linux-restricted-modules needs some x.org love, and while you're at it, could you look at 2500?
<bob2> fabbione: do you happen to know how to force hotplug (or whatever) to use usb-storage on usb removable disk things instead of uba?
<fabbione> bob2: yes.
<stockholm> hi
<stockholm> i am looking for mdz
<stockholm> when would he surface?
<thom> he's in hiding
<bob2> fabbione: and the way to do it is?
<fabbione> mjg59:  disable-lapic-in-acpi-power-off.dpatch 
<thom> due to crimes against humanity
<fabbione> is this one of your patches?
<fabbione> bob2: waiting for me to upload -2
<bob2> fabbione: oh, aesome
<stockholm> thom: tell him to come out, i try to improve his package.
<thom> he's asleep
<thom> seriously
<stockholm> thom: i *do* believe you. when do you think will he come out of coma?
<stockholm> thom: is he in europe allready?
<stockholm> what do i have to do to be invited to some place like spain or the bahamas?
<smurfix_> stockholm: Nothing. Everybody's invited. Just come here.
<stockholm> i would wait for the bahama meeting, then
<mjg59> fabbione: That's not one of mine
<fabbione> mjg59: does it make an sense to you?
<fabbione> becuase it is non portable code
<fabbione> and it makes mess on ia64
* fabbione wants to kill
<mjg59> It seems to be needed to get poweroff to work on some laptops
<mjg59> There's a cleaner fix in 2.6.10, I think
<fabbione> mjg59: humpf...
<fabbione> mjg59: do you have an alternate patch for it?
<mjg59> fabbione: Hang on, just finding it
<trulux> hey!
<fabbione> these undocumented patched ARE A FUCKING PAIN IN THE BUTT
<mjg59> http://bugzilla.kernel.org/show_bug.cgi?id=3643
<trulux> lamont, i'm finishing the hardened debian presentation slides
<fabbione> mjg59: you rock!
<mjg59> fabbione: I know
<daniels> fabbione: apparently the phrase is 'shit hot
<daniels> '
<mjg59> So shit hot I don't notice cute blondes checking me out in bars, it seems
<mjg59> No, hang on. I put in a compact flash card. No g-v-m popup. I fdisk it. g-v-m popup.
<mjg59> WTF?
<fabbione> mjg59: usb mass storage?
<mjg59> Nope
<mjg59> Compact flash in PCMCIA adaptor
<daniels> mjg	to be fair, I didn't notice cute blondes checking you out in bars, either
<mjg59> daniels: How the christ did you just get a literal tab in that?
<mjg59> To be fair, this is sid rather than Ubuntu
<mjg59> (the craptop doesn't have PCMCIA...)
<elmo> I thought the craptop pre-dated PCMCIA
<elmo> ;)
<mjg59> But 4 USB SOCKETS
<daniels> mjg59: take irssi, apply a liberal amount of burstlag, add a dash of tab and enter arriving in the same read
<mjg59> Oh, eww
<bob2> she was totally checking you out
<mjg59> So that's how it happens
<bob2> she even had all her teeth, afaic
<bob2> t
<mjg59> bob2: I got back to Cambridge and then dreamt about all my teeth falling out
<stockholm> btw: joey took steve kamp into the security team
<stockholm> bah
<daniels> mjg59: the midlands will do that to you
<stockholm> wrong channel
<stockholm> thom: what do you think, when will mdz be available?
<bob2> mjg59: still doesn't beat kinnison's dream about a british justin timberlake
<thom> dude, he's asleep
<thom> how should i know? :-)
<stockholm> thom: you did know *that* he slept, i figured you had an ETOA from experience, too. (c:
<elmo> stockholm: he's ill
<stockholm> never mind.
<elmo> (and not in the daniels, I'm a wapper-from-the-80s sense, either)
<stockholm> elmo: ah, uh. poor bastard.
<stockholm> ok, then i wont wait for him.
* pasc waits for someone to submit elmo's comment as a bug against fortunes
<daniels> elmo: i'm a fookin wapper and i might kill yoo
<bob2> cops don't kill people...
<daniels> bob2: racks at level3 do (or at least just cut them up)
<Treenaks> daniels: You've seen it happen?
<azeem> daniels: hey, did you see that one?
<azeem> "Winning the Motor Trend Car of the Year award is huge for us," said Dieter Zetsche, Chrysler's president and chief executive.
<Treenaks> daniels: (You've made it happen?)
<azeem> "As Snoop Dogg would say, it's the shizzle," he added.
<daniels> Treenaks: ask thom!
<daniels> azeem: HAHA
<bob2> haha
<fabbione> elmo: <bitching>g1bb0r m3 s0m3 sp4rc l0v3</bitching>
<gilligan_> could someone give me some help by telling me where i can get the source to the network-profile-util in Computer-->System Configuration-->Networking ? (what module to check out from cvs or whatever.. )
<mjg59> gilligan_: That ought to be gnome-system-tools
<gilligan_> mjg59: ah,thanks
<jdub_> mjg59: so we've decided to ship a modified netapplet with hoary, not networkmanager
<azeem> ohhhhh
<mjg59> jdub_: Haha
<mjg59> It's still that broken?
<thom> short term decrack goal
<mjg59> Modified in what way?
<thom> it's still taht broken :/
<thom> ui fixes, and making it a real applet
<mjg59> Rock
<jdub> making the menu less arse
<mjg59> I'm happy on merging those into the Debian one
<lamont_r> daniels: is working on windows!
<jdub> ahr
<thom> we have translucent windows!
* jdub crashes daniels 
<elmo> just C-z him
<thom> nah, that'll just stop his windows rendering, the arctic wind will still come in
<Mithrandir> thom: there's no artic wind down here by the equator
* mjg59 gets promised casual sex in return for helping someone buy a laptop
<daniels> mjg59: he's unhappy with his x40?
<mjg59> daniels: Haha
<Keybuk> you can have casual sex for getting suspend working on mine, if you like :p
<mjg59> Keybuk: Tell tbm to get his docking station fixed, and I can start debugging it
* mjg59 also discovers that someone he was an undergrad with is in #ubuntu
<bob2> so, my x40 only wakes up "sometimes"
<Kamion> that'd be the water
<bob2> it was tobacco bong juice, tyvm
<Kamion> mmm, sip from that bong
<mjg59> bob2: Much sucking
<mjg59> Try downgrading the BIOS?
<bob2> is that safe?
<mjg59> Dunno
<mjg59> It's very weird, though. This is with my kernel?
<bob2> yup
<mjg59> Try Hoary's 2.6.9 once fabbione has uploaded -3
<bob2> it'a on sleep-when-I-close-the-lid, and sometimes it half comes-back
<bob2> the sleep and battery lights are on
<mjg59> Ah. Hrm.
<mjg59> Try unloading the sound driver before suspend.
<bob2> ah, ok
<mjg59> I've seen that behaviour, but only with 2.6.10
<bob2> it's.."often" fucked after resume
<mjg59> Sound?
<Kamion> bob2: actually, your x40 sounds like it's entered daf mode
<mjg59> Weird
<bob2> this was with your 2.6.9
<bob2> Kamion: haha
<jdub> bob2: fucked after resume?
<jdub> bob2: perhaps keeping it dry would help
<Mithrandir> uhm, from glibc:
<Mithrandir> +Send bug reports directly to Ulrich Drepper <drepper@gnu.org>.  Please
<Mithrandir> +do *not* use the glibcbug script for reporting bugs in the snapshots.
<Mithrandir> +glibcbug should only be used for problems with the official released versions.
<Mithrandir> +We don't like bug reports in the bug database because otherwise the impression
<Mithrandir> +of instability or lack of quality control of glibc as a whole might manifest
<Mithrandir> +in people's mind.
<Mithrandir> especially the last part is comforting.
<mjg59> Hahahahahahahahahahahahahaha
<mjg59> We should totally switch to BSD libc
<thom> KICK ASS
<thom> we should use hackerlab
<fabbione> ahha
<mjg59> Hrm
<mjg59> I'm halfway through a long upgrade. It's run the acpid preinst and stopped it, but hasn't got round to postinst yet
<mjg59> Suckitude
<Mithrandir> mjg59: acpid should predepend on itself or something
<bob2> jdub: bah
<mjg59> Mithrandir: Hahaha
<Mithrandir> preferably the next version
<fabbione> ahhaha
<fabbione> RIDE THE NETSPLIT!
<fabbione> OH YEAH
<zul> heh
<thom> dude, you need less free time :P
<mjg59> thom: When's the laptop BOF starting?
<Mithrandir> elmo: could you please sync glibc?
<elmo> err, really?
<thom> mjg59: hour and a half
<Mithrandir> elmo: really.
<mjg59> thom: Ah, are wiki times GMT?
<thom> nope
<mjg59> Oh. I thought it said 16:30
<Mithrandir> elmo: I've hand-checked and we should be fine.
<mjg59> Maybe I'd already converted it in my head...
<elmo> Mithrandir: done
<Mithrandir> thanks a lot
<thom> mjg59: 17:30
<elmo> do we have a testing bug?
<elmo> or can someone please make a comment on a bug, or in some other way cause bugzilla to send mail?
<Mithrandir> two secs
<Mithrandir> ta
<elmo> meh, nothing broke, how disappointing.  must try harder.
<Mithrandir> elmo: please sync mozilla-firefox-locale-it
<elmo> done
<Treenaks> hey sivang
<Treenaks> sivang: I see you made it to the hotel? :)
<sivang> Treenaks : Hi Martin :)
<sivang> Treenaks : yeppers, thank to your wonderful phootage 
<Treenaks> sivang: cool :)
<Treenaks> sivang: where are you now
<sivang> Treenaks : I just saw you on the BOF room, we are downstaris
<ogra> sivang: thats what i'd also like to know
<sivang> hey ogra, I think I noticed you also :)
<ogra> ahh
<Treenaks> sivang: ah ok :)
<ogra> i didnt :(
<ogra> i'll come down for a cigarette
<sivang> ogra : were you on the BOF also? or in the area?
<ogra> yep....directly at the door
<ogra> i'm coming down now....
<thom> hey fabio, where's my kernel? ;-)
<daniels> dude, where's my kernel
<bob2> woo, room wireless
<mjg59> catdog: Any joy with that?
<catdog> mjg59: Yeah. Suspend-to-disk seems to be working okay. I need to plug the usb mouse back in to get it working again.
<mjg59> catdog: Hrmph.
<mjg59> That stuff's supposed to be fixed. Ah well.
<lamont_r> it's all mdz's fault
<mjg59> Possibly we should unload USB on suspend and reload it on resume.
<catdog> Suspend-to-ram not. It just boots up as normal again.
<mjg59> catdog: Ah. Yes, I've got a machine here that does that. What sort of laptop is it?
<catdog> mjg59:A multivision - based on a Uniwill chassis N251C2
<catdog> it's crap :)
<catdog> Also, when booting (whether a normal boot, or from suspend-to-disk) I get about 25/30 messages like "ERROR: Removing 'xxxxxx': Device or resource busy". 
<Treenaks> Quick link to close all firefox windows at once:
<Treenaks> http://maas-online.nl/security/poc-mozilla-crash.html
<mjg59> catdog: Yeah, thats normal
<mjg59> catdog: Hrm. AMD CPU?
<catdog> mjg59: "mobile AMD Athlon(tm) XP 2500+"
<mjg59> Yeah. It seems to be non-Intel chipsets that cause it.
<mjg59> I've never seen it on an Intel
<catdog> What, cause suspend-to-ram to not work?
<mjg59> Couple of AMDs, every VIA I've tried
<mjg59> Yup
<mjg59> It's a Linux bug, but it's down to hardware interaction and basically impossible to debug without a logic analyser
<mjg59> (or, alternatively, entirely reimplementing the ACPI layer and seeing if it has the same problem...)
<fabbione> thom: on the way soon
* catdog nods knowingly...
<fabbione> thom: for that patch we need to find a way to "optionalize" it
<fabbione> i am waiting the 2 turtles to complete the build
<fabbione> also known as ia64 and ppc
* mjg59 trolls Macedonians
<thom> indeed
<thom> mjg59: macedonian keymap thing on freedesktop
<mjg59> It's so funny (in a completely terrifying sort of way)
<thom> ?
<mjg59> thom: Yes
<thom> that mail was quite scary
<mjg59> The one about reporting us to the UN?
<Treenaks> mjg59: reporting to the UN/
<mjg59> Treenaks: Some insane Macedonian (or possibly Greek) guy threatening to report Debian to the UN because of the name used for FYOM in the installer
<mjg59> And claiming that we'd be found guilty of supporting terrorism
<Treenaks> nice one
<Mithrandir> elmo: mpich sync, please.
<elmo> Mithrandir: done
<kylem> Keybuk's fanboy thing is neat...
<Treenaks> kylem: doesn't it Depends: fans ?
<mjg59> fanboy?
<kylem> mjg59, it's on his blog.
* spotter laments the regression of his gnome-panel :(
<mjg59> laptop BOF on now?
<Mithrandir> is it possible to invoke the gnome run dialog from the command line?
<elmo> mjg59: com counc meeting atm
<thom> mjg59: yes, laptop bof starts now according to the schedule
<mjg59> thom: Could someone harass me if there's anything I can give input on?
<Mithrandir> Treenaks: do you use nl_NL as your locale, and do you have a unstable box running?
<Treenaks> Mithrandir: uh ish :)
<Mithrandir> Treenaks: if so, could you verify that the current thunderbird is totally on crack and not translated to Dutch?
<Treenaks> Mithrandir: I'm only running hoary here.. my unstable box is uhm.. say like.. uh.. a few 1000km away
<Mithrandir> I'm looking at merging, but I'm not going to merge if it's on crack (which I think it is, since it seems to just have copied the german translation.)
<Treenaks> Mithrandir: show me :)
<Mithrandir> mjg59: we will harass you, sure.
<aj> Kamion: around?
<Kamion> aj: yep
<aj> Kamion: tarballs of ubuntu debootstraps since 0.2.39ubuntu19?
<Kamion> aj: coming up. they're all entirely Ubuntu-specific changes though
<Kamion> aj: is there some way you'd like me to get these to you as I build them?
<aj> put 'em up on some website and give me a url is good
<aj> i'm setting up my darcs repo, will see if that's usable for jhm, if so i'll point you at whatever that ends up being later
<Mithrandir> Treenaks: http://err.no/tmp/mozilla-thunderbird-locale-nl_0.9.dfsg-1_all.deb
<lamont_r> Kamion: netkit-ftp built for you.
<Kamion> aj: they're all on http://people.ubuntu.com/~cjwatson/debootstrap/ now; will try to remember to keep uploading new tarballs there
<Mithrandir> that's a plain built m-t-l-n from unstable.  I'd be surprised if it's not on crack.
<Kamion> aj: want mailed/otherwise-pinged, or will you poll when you're interested, or which?
<aj> i'll poll for the moment
<Kamion> ok, will be a new version soon for Ubuntu/ia64 anyway
<Kamion> lamont_r: hooray, no more libreadline5
<Treenaks> Mithrandir: everything looks pretty Dutch to me...
<Mithrandir> hm
<Mithrandir> weird
<Mithrandir> or mom is on crack
<Treenaks> mom?
<Mithrandir> mergeomatic
<Treenaks> Mithrandir: ah ok.. not anyone's mother :)
* Kamion wonders if debootstrap will break if libc6 goes last in the required list ...
<Mithrandir> Treenaks: just the patches' mother.
<Treenaks> Mithrandir: the MOAP
<aj> Kamion: shouldn't
<Kamion> about to find out, I guess :)
<aj> Kamion: i occassionally get confused when it does things not in alpha order, but that's not debootstrap's problem...
<Kamion> might be nice to sort those lists
<elmo> argh
<elmo> Kamion: why doesn't debman cache?
<Kamion> elmo: it's too stupid
<Kamion> :-)
<Kamion> wow, somebody other than me uses debman
<Mithrandir> what's debman?
<Kamion> # debman - read a man page from an uninstalled Debian package file (.deb)
<Kamion> elmo: what are you using it on?
<Treenaks> Kamion: BaseSeed!
<elmo> Kamion: how do you mean?  I'm trying to read a bunch of postfix manpages (and not have to trash my exim4 install), if you mean what os/distro, hoary
<Kamion> elmo: ah, was just wondering why performance was a problem, ok
<Kamion> file a bug on debian-goodies, cc me?
<elmo> sure
<elmo> bugzilla or debbugs?
<Kamion> debbugs
<elmo> k
<Kamion> (do we have debian-goodies in Ubuntu?)
<Kamion> wow, we do
<Kamion> cool
<mxpxpod> wow, the foot menu looks way different
<Kamion> Setting up ntpdate (4.2.0a-11ubuntu2) ...
<Kamion> I: Configuring ntpdate...
<Kamion>  * Synchronizing clock to ntp.ubuntulinux.org...
<Kamion>  *ror : Servname not supported for ai_socktype                           [fail] 
<Kamion> can we make ntpdate not do anything when it's being debootstrapped?
<mjg59> Why does it give *ror ?
<Kamion> because /lib/lsb/init-functions is on crack
<mjg59> Ah
<Kamion> it overwrites the error in an awkward way; we were talking about ways to fix that the other day
<Kamion> hi Mark
<sabdf1> hi all
<Kamion> we are currently in the hothouse (literally) known as the laptop BOF
<sabdf1> master garrett conducting from afar?
<Kamion> lamont_r: why did passwd need to be added to hoary.buildd's required?
<Kamion> lamont_r: and can we add libunwind7 and libunwind7-dev only on ia64?
<Kamion> sabdf1: on call in case of emergency or confusion :-)
<mjg59> Hello
<mjg59> Is there a better channel for this?
<sabdf1> is it a hothouse because you havent got lifeless' hoverbook in stealth mode yet?
<Kamion> this seems about right
<Kamion> sabdf1: too many people and too little AC, I think; opening the windows caused fun arctic winds :-)
<Kamion> I think lifeless' hoverbook needs to engage submarine mode, that would be funnier
<mjg59> sabdf1: Though the hoverbook /does/ now have working ACPI...
<sabdf1> nice
<lamont_r> libunwind7{,-dev} only exist on ia6
<lamont_r> 4
<Kamion> let's install them only there then
* fabbione kicks ia64
<lamont_r> passwd is a dep of something... second
<fabbione> that cpu is pure crap
<elmo> CPU DEATHMATCH
<lamont_r> bash Depends: passwd
<lamont_r> have a nice day
<Kamion> lamont_r: d'oh
<Kamion> lamont_r: ok
<fabbione> elmo: even my slow sparc running buildd in parallel was faster to build the kernel (no ccache on both of them)
* fabbione sends ia64 to hell
<jdub> i blame the projector for the hothouse
<jdub> and the AC not really appearing to be on
<elmo> fabbione: IIRC ia64 builds like 20x the amount of drivers sparc does
<elmo> but yeah, they're not great, esp. for the $$
<Mithrandir> and they do VLIW, which is painful
<elmo> oh, yeah, gcc sucks for ia64
<Mithrandir> it's also a hard problem
<seb128> elmo, are some of the GNOME packages in NEW ? I've added -dbg to gnome-panel, gnome-applets, nautilus
<elmo> 9.8M    nautilus-dbg_2.9.1-0ubuntu3_powerpc.deb
<fabbione> elmo: ok... but we are not talking like 1 hour difference.. we are above 5 HOURS difference
<Kamion> lamont_r: debootstrap for ia64 uploaded, HAND
<elmo> 9.3M    gnome-applets-dbg_2.9.2-0ubuntu4_powerpc.deb
<elmo> oh, yeah, and ia64 builds 4 variants?
<seb128> elmo, pointing the size ? I know, but Jeff said you talked about it and that's ok for a few packages
<Kamion> aj: 0.2.45ubuntu10 there for you now too
<fabbione> elmo: yes. sparc64 2
<elmo> seb128: one sec, I'm just going to come and pour some coke over jeff
<Kamion> seb128: can't you use the binutils support for separated debug sections?
<jdub> seb is going to harm me for this
<azeem> elmo: I wanted to add an 'elmo is going to love me for this' to my -dbg-proposal on ubuntu-devel, but then refrained
<Kamion> rather than building a completely new -dbg variant?
<jdub> seb128: i thought we were going to check the sizes with elmo before uploading?
<seb128> jdub, you said to do applets/panel/control-center/nautilus and to check what to do with the other ones latter
<seb128> or I misunderstood
<seb128> Kamion, -dbg are just the symboles stripped by dh_strip
<seb128> Kamion, that's not the right way to do that ?
<Kamion> seb128: ah, you're already using dh_strip --dbg-package?
<seb128> yes
<Kamion> ok, good
<Kamion> yeah, that uses the binutils feature
<kylem> heh, i don't know how you guys managed it, but ubuntu doesn't want to network on my x30. :)
<Kamion> fabbione: can you confirm what the ia64 -itanium-smp kernel package is going to be called?
<fabbione> Kamion: Package: linux-image-2.6.9-1-itanium-smp
<fabbione> given that i didn't miss anything
<fabbione> it is still building
<fabbione> :(
* Keybuk read that as italian-smp and was about to go "meh!?"
<Kamion> fabbione: ok, good
<fabbione> ahahaha
<fabbione> Keybuk: i am already smp :P
<aj> Kamion: typical!
<Mithrandir> this is so bad.
<Mithrandir> when building swig, it invokes chicken-config in some cracky way.
<Mithrandir> so it spits the help message back.
<elmo>    * The "please do not create new packages using debmake" release,
<elmo>      also known as "this is the beginning of the end".
<Mithrandir> of debmake?
* Mithrandir cheers
<thom> rockity rock
<azeem> mjg59: so, for an IBM R51, PMTestingResults seem to be 'yes', 'yes', 'yes'
<mjg59> azeem: Rock
<azeem> mjg59: however, I did the testing on unstable
<azeem> after porting your stuff
<fabbione> Kamion: if you need: p.u.c/~fabbione/sparc
<eruin> what's going on with nautilus/burner?
<kylem> what are the odds of a hoary netinstall working for me?
<eruin> let's give it a 90%
<daniels> kylem: wfm
<kylem> ok. because i'm suitably enraged that warty wouldn't...
* kylem will give daniels the benefit of the doubt.
<eruin> whoa. is the new meny layout I'm getting on the last dist-upgrade a concious decision?
<eruin> ie things like the computer menu now being "actions", while settings, the menu with synaptic in it, etc has been moved to the applications menu?
<azeem> eruin: there was discussion about this on ubuntu-devel
<eruin> yeah, what I've read/heard of it didn't seem to illustrate the changes I now see
<azeem> eruin: I thought the conclusion was to drop the Ubuntu patches for now and introduce gnome-menu
<Kamion> eruin: it's temporary
<eruin> yeah, it's no big deal, just wondering ;) - I thought gnome was slightly leaning towards apps | places | system ?
<eruin> I guess I haven't been following this closely enough
* lamont_r tries to reproduce the umount-ing all filesystems bug, fails...
<lamont_r> and yet I have somewhat of an idea of what's going on...
<kylem> blargh. your nautilus is fudged. sigh.
<kylem> ah, needed universe. *slap*
<eruin> btw, any of you have an idea if gtk-filechooser is planned for either the firefox package or the firefox-gnome-support pkg?
<kylem> or not. son of a bitch.
<eruin> I've seen it in fedora, but no anywhere else, and I've seen you guys are actively tracking any fancy fedora patches... is it a part of firefox or is it a manual patch?
<eruin> probably the wrong place to ask that last question ;)
<eruin> in any case, shouldn't ubuntu-desktop depend on packages such as firefox-gnome, openoffice.org-gtk-gnome?
<fabbione> meaning within this evening
<fabbione> ops
<Kamion> eruin: we haven't put those into the desktop seed yet; they're proposals at the moment, I think at least mozilla-firefox-gnome-support was accepted so it should be there soon
<eruin> ok, thanks for clearing that up :)
<Kamion> lamont_r,fabbione: new debian-installer crack uploaded for you both; ia64 and sparc may or may not work now
* trulux is installing Ubuntu in his desktop box
<trulux> lamont, i will work with Ubuntu soon ;-)
<fabbione> Kamion: cool!
<trulux> (as soon as the installer ends)
<fabbione> Kamion: i will give it a try later this night or tomorrow
<thom> FEH
<lamont_r> Kamion: thanks
<lamont_r> interestingly, causing /etc/dev.d/default/unmount.dev to not do anything if $DEVNAME is empty seems to make the unmount-the-world go away
<Treenaks> lamont_r: and does it affect anything else?
<Treenaks> lamont_r: like, for example, unmounting when it's needed?
<lamont_r> doesn't seem to
<lamont_r> umount -l results in an error exit when there are no arguments...
<daniels> net/core/pktgen.c:603: warning: right shift count >= width of type
<daniels> net/core/pktgen.c:603: warning: passing arg 1 of `__div64_32' from incompatible pointer type
<daniels> i am filled with so much confidence
<seb128> hum
<seb128> I've added libnautilus-extension1 and libnautilus-extension-dev to nautilus ... can somebody promote them to main ?
<seb128> (nautilus-cd-burner need them to build)
<Treenaks> seb128: ah so YOU broke that :P
* kylem snarls at seb128 ;)
<seb128> I broke nothing
<seb128> upstreams did :p
<Treenaks> seb128: stupid upstream gnomes
<seb128> ah ah
<thom> yeah, damn them and their fishing rods
<fabbione> GET THE CRACK!
<fabbione> 2.6.9-2 is up
<zul> fabbione: whats new?
<lamont_r> Kamion: if glibc weren
<lamont_r> t ftbfs on ia64, it'd work.
<thom> hey, my kernel has leet printing every file it opens crack
<Kamion> lamont_r: haha
<fabbione> zul: a security fix for amd64, a bunch of bug fixes and ia64 support
<fabbione> i am off for food :-)
<fabbione> later
* daniels giggles maniacally and ponders l-r-m on ia64.
* lamont_r whacks Mithrandir with glibc
<daniels> thom: i hope your /var is large
<jdub> azeem: ping?
<mvo> jdub: can you send me your sources.list file please?
<Kamion> elmo: can you 'chmod g+w /home/warthogs/archives/ubuntu-devel@lists.ubuntu.com/seeds/seeds--hoary/seeds--hoary--0/patch-48' on chinstrap please?
<elmo> TLA CRACK
<Kamion> no idea how that happened, your umask seems right ...
<Clint> easier to use setfacl -d
<Kamion> cjwatson@chinstrap:~$ type setfacl
<Kamion> -bash: type: setfacl: not found
<elmo> done
<Clint> that's one reason not to use it
<Kamion> elmo: thanks
<eruin> http://appelsinjuice.org/bug.txt
<eruin> anything like that even worth submitting?
<eruin> something*
<eruin> I have no idea what could be causing this (though I'd bet it's the xorg-ish updates or udev/hal), and cedega isn't exactly opensource...
<trulux> lamont, i'm having trouble configuring Ubuntu
<trulux> no nvidia module for my card in XFree
<trulux> doko, ping
* trulux is fixing it
<trulux> lamont, are you there?
<trulux> hey tseng
<jon1012> hi everybody
<jon1012> hi
<jon1012> is there someone who is working on gnome-panel here ? :/
<jon1012> completly brokenthe release of today on hoary :(
<jon1012> just to know if I could work on it...
<jon1012> or if someone is already working on it :/
<jon1012> (and also I don't know how to submit my work if I decide to try to fix it)
<mjg59> Grah. Stuff is appearing as /dev/ub and udev isn't making device nodes.
<jon1012> arg :/
<jon1012> (MAKEDEV ?)
<jon1012> (lol)
<jon1012> someone working on gnome here ?
<jon1012> hi
<sid77> hi
<jon1012> do you know someone who work on gnome on ubuntu ?
<jdub> pants off
<jon1012> :|
<jon1012> hi
<seb128> hey hey hey jdub 
<jdub> seb128: you're well fed? :)
<jon1012> ofor the logs if someone reads :/ if you have informations about the gnome-menu and gnome-panel 2.9.2 being broken please email me at jonathan.schemoul@gmail.com thanks :)
<seb128> jdub,  yep, the dinner was fine (some tapas) !
<seb128> jdub, and you ?
<jdub> we had spanish chinese
<jdub> jon1012: 'broken'?
<seb128> there is some difference between chinese in differents countries ?
<jon1012> yup... the menu is rgoing really weird :/
<jdub> seb128: well, they served olives at the start ;)
<jon1012> everything is going on the applications menus, and all the translations have been reseted to english
<seb128> jdub, ah ah
<seb128> jon1012, that's normal
<jon1012> why ?
<jon1012> :/
<seb128> jon1012, hoary is a devel branche and this has been discussed on the ubuntu-devel list
<seb128> read the list for details
<jon1012> lol I'm not and this list
<jon1012> how can I read it ? :p
<seb128> and don't use a devel branch if you don't want get changes
<seb128> lists.ubuntu.com
<jon1012> (and also I want to start helping with the develop. of hoary, how can I do to enroll ? lol)
<jon1012> (I'm a C and C# developer)
<seb128> subscribe to the devel list first :)
<seb128> jdub, BTW libnautilus-extension1 and libnautilus-extension-dev need some main love, you can do this ?
<jdub> seb128: if nautilus builds them and depends on them, they'll just shift to main with some elmo interaction
<jdub> seb128: they don't need to be in the seed
<seb128> ok
<seb128> nautilus-cd-burning is ftbfsing for the moment
<seb128> just need to wait in elmo so
<jon1012> lol, but I was saying is that the places menu disapearred
<jon1012> and now there is Actions (like in fedora or standard gnome)
<jdub> jon1012: yeah, known issue -> see ubuntu-devel list :)
<jon1012> lool
<jon1012> ok
<jon1012> (is there a way to search in the archives of the mailing list ?)
<seb128> lists.ubuntu.com
<jon1012> lol yes I'm on it
<seb128> the thread about this is on the archive of december of ubuntu-devel
<seb128> should be easy to find
<jon1012> ok :)
<jon1012> humpf I think that I will simply put all the menu files from the .deb of warty directly on my filesystem :/
<jon1012> (and the french localisation since in this release there isn't french :/)
<jon1012> only the /etc/xdg so, and the messages in french for gnome menus
<jon1012> do you think that it can work without fucking up the things more than they are ? :)
<seb128> you can fix anything in hoary
<seb128> the gnomevfs method to do old menu has been dropped
<seb128> so you need to hack gnomevfs or to revert it
<seb128> so to downgrade a lot of stuff
<seb128> better to reinstall a warty system if you go in this way
<seb128> jon1012, hoary is not a release but a devel branche
#ubuntu-devel 2004-12-19
<jon1012> lol yes, but I will try to put my system at 2.9.1 instead lol
<seb128> good luck
<seb128> you need to change gnomevfs, nautilus, panel, nautilus-cd-burner at this point
<jon1012> yup
<seb128> and you'll not but able to install new GNOME packages after that
<jon1012> lol yes, but can I do the menu myself another way?
<seb128> you should better wait for the new panel changes 
<jon1012> yup
<jon1012> when will this be you think ?
<seb128> live with the stock menus like everybody else in hoary ?
<seb128> probably before the end of the month
<jon1012> ok :)
<seb128> dunno when exactly
<seb128> BTW time to sleep
<seb128> later
<jon1012> the thing is that I need the development branch for a lot of libs in my developments
<jon1012> see ya :)
<jon1012> and thank you :)
<mxpxpod> does anyone here use the netgear MA111 for wireless network?
<mxpxpod> I'm having a problem where when I unplug it, /proc disappears
<jon1012> hu ?
<jon1012> nop I don't use it :(
<chrisa> I need to find a wlan usb adapter that doesn't use wlan ng (ie: no ma111 or dwl-122)
<chrisa> So tired of that driver
<mxpxpod> chrisa: yeah, same here
<mjg59> chrisa: Currently, that's awkward
<mjg59> The CVS orinoco driver has support for some USB devices, but I think that's abou tit
<mxpxpod> chrisa: I think there's one in dongle form that uses prism54 that I've thought about getting
<chrisa> wlan ng wouldn't be so bad if the normal wireless tools worked with it
<mxpxpod> hmm, it unmounted my /home dir as well
<mxpxpod> but if I mount /proc and /home, everything is fine (I think)
<chrisa> What makes you think the driver did this?
<mxpxpod> chrisa: it's the only thing that does that when I unplug it
<chrisa> and of course you're watching syslog and messages, rrrrrriiiggght?
<mjg59> chrisa: We're seeing this with various wireless drivers
<mjg59> It's very odd
<chrisa> oh? Neat
<jon1012> yeahhhhhhhhhhhhhhhhhhh MY HACK OF THE GNOME-PANEL WORKS :D
<jon1012> oops excuse me :$
<jon1012> lol
<mxpxpod> mjg59: hmm, it only happens the first time I insert it
<mxpxpod> after I remount everything, it doesn't seem to do it anymoer
<mxpxpod> well, except that I can't remount swap, sysfs, tmpfs, or devpts
<mxpxpod> mjg59: any clue as to why it's doing this?
<mjg59> None
<mjg59> I can't reproduce it here
<mxpxpod> mjg59: that's strange
<jon1012> humpf why does the had to change the gnome menu systeme in hoary yesterday ? :(
<jon1012> all my apt database is broken and my gnome menu also :/
<TD> hi, are there any forum admins here? i don't mean to interrupt but i was browsing them, and i noticed that one of the moderators (!) is consistently posting links to pirate packages of commercial linux software
<TD> i was wondering who i should speak to about that
<mjg59> TD: Is that ubuntuforums.org?
<TD> yeah. not official?
<mjg59> Nope
<mjg59> Good thing to LART, though
<TD> ah ok, i see. sorry, the branding made it look like a part of the main ubuntu forum
<TD> s/forum/site/
<mjg59> They gateway the mailing lists
<jon1012> (what software did this administrator post links for ? :/)
<TD> crossover and cedega
<mxpxpod> chrisa: ok, so what am I looking for?
<jon1012> erf ok :/
<TD> russian warez sites
<mjg59> Grah.
<mjg59> Asking on #ubuntu might be a better bet
<TD> k
<mjg59> I'd expect some of them to hang out there
<mjg59> Sorry about that :(
<jon1012> bad, because if people want crossover, they can help and become advocate... :/
<jon1012> if they want it without paying i mean :)
<TD> yeah. we practically give it away these days
<jon1012> yup
<jon1012> I'm an advocate
<jon1012> (a proud advocate in fact :p)
<TD> it's 99.something% LGPL anyway. so it's kind of annoying to see people recommending that newbies warez it.
<jon1012> sure...
<TD> cool, what app?
<jon1012> Photoshop 7 mainly :)
<jon1012> I'm in a multimedia school, in graphic communication
<jon1012> crossover is really great :)
<TD> thanks
<jon1012> really bad that people want to go to pirate sites for it :(
<TD> it happens. some of them even try and get tech support.
<TD> using linux doesn't magically change (some) human nature, unfortunately
<jon1012> (they don't understand that they kill wine and crossover doing this)
<jon1012> yes :(
<lamont_r> sucky connectivity. :-(
<TD> i think we'll survive. have done for a fair few years now, and more corporate work is coming in these days. those dudes play it straight
<jon1012> td > if you want any help, contact me at jondesign@jondesign.net (my advocate adress is jondesign@altern.org, but it's my old adress ^^)
<Kamion> mxpxpod: lamont has been tracking down the unmounting problem and knows roughly where it is now; it's apparently in one of the udev scripts
<TD> thanks :)
<lamont_r> Kamion: or at least apparently so.
<mxpxpod> Kamion: oh really... so udev is being a brat
<Kamion> mxpxpod: /etc/dev.d/default/ somewhere
<lamont_r> that is, fixing the script to not generate an error from umount (and therefore exit with an error, appears to make the problem go away
<lamont_r>  /etc/dev.d/default/unmount.dev or so.
<lamont_r> wrap the whole thing in if [ -n "$DEVICE"] ; then ... fi
<lamont_r> or whatever the name is...
<mxpxpod> lamont_r: that works for me
<mxpxpod> just modified it and unplugged then re-plugged my usb device and it doesn't unmount everything
<lamont_r> woot
<mxpxpod> and it's $DEVNAME
<mxpxpod> lamont_r: have you figured out the problem with udev unmounting /dev before unmounting the drives yet?
<lamont_r> now, for extra credit, add an else clause that says 'exit 1'
<lamont_r> and see if it once again trashes everything... 
<lamont_r> that's fixed in 2.12j
<lamont_r> although you want -2, not -1 if you use cryptoloop devices
<mxpxpod> 2.12j?
<lamont_r> 2.12j-2
<mxpxpod> of what?
<lamont_r> fixed upstream - mount_2.12j-2_${arch}.deb
<lamont_r> er, for hoary that's mount_2.12j-2ubuntu1_${arch}.deb
<mxpxpod> lamont_r: ah, gotcha
<sid77> bye all
<lamont_r> I don't remember if that fix made todays dinstall run in debian or not, but -2ubuntu1 is certainly in hoary
<mxpxpod> lamont_r: adding that else doesn't trash everything
<lamont_r> very interesting
<mxpxpod> lamont_r: wait... where did you want that else?
<lamont_r> Kamion: you need things much beyond 1AM (9 minutes from now...)?
<lamont_r> actually, you'll still have connectivity, it'll just get more sucky.
<lamont_r> mxpxpod: when $DEVNAME==""
<lamont_r> that is, as an else clause for the if that you just added...
<Kamion> lamont_r: pretty sucks already ... ;)
<mxpxpod> lamont_r: ok, yeah, that's what I added...
<Kamion> lamont_r: nah, should go to sleep
* lamont_r sleeps
<lamont_r> Kamion: seems happy again.
<lamont_r> anyway, off to ned/
<lamont_r> bed even
<Kamion> yep, working here ...
<mxpxpod> nite lamont_r, thanks for the help
<jon1012> oh another thing
<jon1012> I've succesfully modified the ubuntu kernel to work wth my asus laptop
<jon1012> (it didn't work at all at first: no acpi, no sound, no usb...)
<jon1012> if the ubuntu kernel maintainers are here, maybe I can discuss about it
<sladen> ~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~
<chrisa> sladen just doesn't impress me
<jon1012> lol
* jon1012 :(
<sladen> f***^W fabulous wifi here
<jon1012> ? lol
<ogra> hehe
<ogra> sladen: which floor ?
<ogra> 1st is great :)
* trulux is running ubuntu
<farruinn> is there some sort of tracking system that shows which maintainer is working on what?
<ironwolf> lamont_r: your wife is looking for you, call her when you awake.
<Treenaks> is it intentional that "bazaar" and "bizarre" sound the same?
<Keybuk> you should try it in a NZ accent ... very confusing
<daniels> 'i gotta git muh nit!'
<fabbione> daniels: x is building.. i will let you know how it goes later
<Keybuk> 'igs, on tarst'
<Kamion> Treenaks: at least semi-intentional I think
<mdz> elmo: so what kind of coercion do you need in order to make ubuntu-keyring?
<Treenaks> btw, who said the "laptop turns on again after closing lid after shutdown" thing will be fixed n 2.6.10?
<Treenaks> (because I have a problem that I think is related)
<lamont_r> someone please throw things at thom
<thom> Kamion: dude, you coming? :-)
<thom> lamont_r: why?
<lamont_r> could we please have Options FollowSymlinks on p.u.c?
<Kamion> thom: oh yeah
<thom> i think we have SymlinksIfOwnerMatch currently, but i could be mistaken
<thom> Kamion: can you poke sladen on the way?
<Kamion> thom: too late
<Kamion> thom: we don't, just 'Options Indexes' and that disables all the others
<Keybuk> http://www.osnews.com/story.php?news_id=9098
<Kamion> dpkg-gencontrol: error: package linux-image-2.6.9-1-mckinley not in control info
<Kamion> make[2] : *** [real_stamp_image]  Error 255
<Kamion> d'oh
<fabbione> yup
<fabbione> already fixed in my tree
<fabbione> bad merge from halley to my local stuff
<fabbione> Kamion: look at the positive side... the ccache is populated :-)
<fabbione> ARGH
* lamont_r shoots his laptop, just for giggles
<fabbione> Kamion: you just trashed my initrd tool upload
<lamont_r> grumble.
<Treenaks> jdub: http://foodfight.org/fotos/2004/12-07%20Ubuntu%20Conference%20-%20evening/?img_0003.jpg
<fabbione> Kamion: since you have the initrd tools tree local.. can you apply the second patch from #4444 please?
<fabbione> the mirror is syncing or out-of-sync atm
<Kamion> fabbione: hah
<Kamion> fabbione: ok, will do, didn't realise you were working on it
<Kamion> sorry 'bout that
<fabbione> no problem mate :-)
<fabbione> i didn't know you were on it either :P
<fabbione> Failed to fetch http://mataro.ubuntu.com/ubuntu/dists/hoary/universe/binary-i386/Packages.gz  MD5Sum mismatch
<fabbione> mataros mirror master?
<lamont_r> I expect that's a thom question...
<Mithrandir> fabbione: just throw something at him
<Kamion> I just operate mataro.ubuntu.com by lftp personally :)
<fabbione> Kamion: wow :-)
<smurfix_> Gah. "Unpacking gnome-menus: trying to overwrite `/etc/xdg/menus/applications.menu', which is also in package kdelibs-data". My fault for still having some kde stuff installed, I know, but still ...
<Kamion> fabbione: done
<fabbione> Kamion: rocking
<daniels> fabbione: cheers
<seb128> smurfix, any idea on how to fix that ?
<jdub> Treenaks: ha ha
<Keybuk> Treenaks: heh, that's not unusual
<Keybuk> it's the photos of jdub where he's *not* pulling a silly face that are rare
<Treenaks> Keybuk: :)
<jdub> fabbione: http://www.saillard.org/linux/pwc/
<fabbione> applying patch dsdt-initrd to ./ ... ok.
<fabbione> applying patch swsusp-userspace to ./ ... ok.
<fabbione> applying patch wakeup_addr to ./ ... ok.
<fabbione> applying patch wakeup_gdt to ./ ... ok.
<fabbione> jdub: i am on it
<azeem> jdub: pong
<jdub> fabbione: sweet, thank you :-)
<fabbione> jdub: applying patch drivers-usb-pwc to ./ ... ok.
<fabbione> Keybuk: sorry but i am way faster than your merge-omatic :P
<jdub> haha
* Mithrandir overclocks fabbione 
* fabbione metls
* fabbione melts
<jdub> fabbione is metal!
<Mithrandir> *chuckle*
<fabbione> ahha
<Keybuk> yeah, and I'm pudding
<Kamion> you wish
<daniels> keybuk aspires to be pudding
<thom> elmo: do you have l33t bzip2 support for katie, yet? 
<elmo> no - it's not katie that's the problem, it's python-apt
<fabbione> mjg59: ping
<thom> ahr :/
<Keybuk> nah, I aspire to be pudded
<mjg59> fabbione: Hi
<fabbione> mjg59: hey. all your patches aplly perfectly
<mjg59> Woo
<fabbione> mjg59: CONFIG_SOFTWARE_SUSPEND is the one we need for swsup-userspace, right?
<mjg59> Yup
<fabbione> it's in for i386/amd64
<fabbione> :-)))
<mjg59> And there's an option for the DSDT in initrd stuff, too
<fabbione> initrd-tools is uploaded
<fabbione> mjg59: done that too :-)
<fabbione> i am alligning the config
<fabbione> once that is done i will upload
<fabbione> question of a few hours
<Kamion> and then we get a debian-installer/ia64 build attempt \o/
<fabbione> Kamion: yup.. that too
<fabbione> Kamion: i promised that we were going to push lamont to put d-i in dep-wait :P
<mjg59> thom: How was the laptop BOF?
<Kamion> seems to be that way
<thom> mjg59: went ok, it seems
<lamont_r> mjg59: almost everyone had one. :-)
<mjg59> thom: Any conclusions?
<calc> acpi sucks ;)
<thom> mjg59: mdz wrote some notes - https://www.ubuntulinux.org/wiki/LaptopSupportA
<thom> gar
<thom> https://www.ubuntulinux.org/wiki/LaptopSupportAndPowerManagement
<thom> even
<mjg59> I'm unsure about StR being default
<mjg59> ibm-acpi is needed for 2.6.9, but not for 2.6.10
<fabbione>   Default resume partition (PM_STD_PARTITION) []  (NEW) 
<fabbione> mjg59: ?
<mjg59> fabbione: Null
<fabbione> ok
<thom> mjg59: we took a quick strawpoll, and 90% of the room wanted it
<thom> if it's really bad, we can back off again
<mjg59> thom: It /is/ going to break on various machines, and people are unlikely to be happy if their machine breaks every time they close it
<mjg59> 2.6.10 only enables lapic if the BIOS enabled it. I'm not sure if that's in 2.6.9. It's a safe default, anyway.
<mjg59> (as I said before, I'm not keen on shipping dsdts. It's /difficult/ to get right, and we plainly have no legal right to do so)
<tuo2> is drinking red wine chilled a bad idea?
<fabbione> mjg59: isn't that the patch you gave to me yesterday?
<thom> tuo2: yes.
<mjg59> fabbione: the lapic one? Nope. That disables it on power-off if the user forced it on.
<tuo2> thom: any reasoning?"
<calc> most dsdt's don't really have anything unique in them, except for the chipset port locations, etc
<calc> at least on the ones i have disassembled in the past
<thom> mjg59: right. i think we got a bit handwavy when it came to DSDTs
<thom> tuo2: it makes red wine taste fucking disgusting
<tuo2> thom: depends on the initial quality of the wine, mate.
<mjg59> thom: Every time the user changes the amount of RAM, they need a new DSDT. Every time they upgrade their BIOS, they potentially need a new DSDT.
<tuo2> And this wasn't real good....
<thom> mjg59: yah
<tuo2> might be better off killing the palette
<calc> you could take all the data that has to be there and plug it into skeleton dsdt so that the code doesn't infringe copyright i suppose
<thom> tuo2: this is well off topic
<tuo2> thom: true. Sorry.
<thom> mjg59: like i said, handwavy
<calc> the dsdt is generated dynamically by the bios?
<calc> i didn't notice that part when reading the acpi spec, eyes must have glassed over
<mjg59> calc: It tends to be. The spec doesn't require it.
<calc> oh ok
<Treenaks> usplash with "wait & switch" is very nice, except for https://bugzilla.ubuntu.com/show_bug.cgi?id=1842 :)
<daniels> Treenaks: that's not a problem, because it was never switched
<daniels> so you never had access to the card
<daniels> try running your gdm with -novtswitch on your X server command line
<robtaylor|away> mjg59: dont suppose you fancy collecting together a bunch of diffs between fixed and original dsdts? ;)
<mjg59> robtaylor: About as much as I fancy plucking my eyes out, but yeah
<robtaylor> yeah, i suppose the only 2 sane opttions are either a) make dsdt interpreter more robust or b) store a diff for each bios version of each machine (and hope diffs help us avoid the ram issue.. ) :/
<robtaylor> a bunch of diffs would help in either case ;)
<calc> i think it got somewhat more robust after ~ 2.6.6
<mjg59> It did
<robtaylor> calc: still doesnt work on my laptop ;)
<mjg59> But there's a reasonable argument for making it bug-for-bug compatible with Windows
<calc> my laptop was completely broken in numerous ways and i filed a bunch of bug reports about it at osdl and len fixed them for me :)
<calc> eg now the acpi ports are reserved by default
<calc> instead of getting reused for various things like cardbus
<calc> mjg59: yep
<mjg59> But upstream won't do that
<calc> upstream is slowly doing it ;)
<calc> as each new device which is broken has bug reports filed about it
<mjg59> calc: No, they won't make it fully bug-compatible with the Windows stack
<calc> so they are refusing to fix bugs that are shown in particular hardware now?
<robtaylor> mjg59: well nothing to stop us making a 2.6.x-acpi bitkeeper branch....
<mjg59> calc: No, that's fine
<calc> ok
<calc> well being bug for bug compatible isn't really needed as long as all laptops work under linux ;)
<mjg59> But they won't alter the interpreter so it behaves brokenly
<mjg59> And that's the only way to be compatible with Windows
<calc> eventually linux will be bug for bug compatible to be able to attain that goal
* calc doesn't get it, oh well ;)
<elmo> mmph, alt-tab is broken for me
<seb128> broken in which way ?
* calc bbl, gone to bed
<robtaylor> calc: if you submit a bug. 1st thing you're told is to find a 'fixed' dsdt//
<robtaylor> it seems
<seb128> 'night calc 
<robtaylor> night calc
<elmo> seb128: I can't switch windows, it flashes up briefly but disappears again immediately
<seb128> weird
<robtaylor> ooh, broken X11 package flashback =)
<seb128> the alt-tab seems to send the right event in xv ?
<seb128> xev even
<calc> robtaylor: hmm they never mentioned that to me, linus even emailed me wrt the io port issue ;)
<mjg59> calc: But that was actually an acpi bug
<calc> yea, previously they solved the io port issue via quirks for every chipset (gag)
<mjg59> Whereas on lots of machines the dsdt isn't anywhere near spec-compliant
<calc> but my dsdt also was broken in various interesting ways which they worked around
<elmo> seb128: err, not sure xev seems a bit whack too.. i'll upgrade, then login/logut, and if I can reproduce, come and show you
<seb128> ok
<calc> i don't remember the exact details since it was about 6mo ago
<mjg59> calc: There's a limit to the dsdt workarounds you can do that are guaranteed to be safe
<calc> their were weird irq issues though
<calc> er there
<mjg59> The Windows interpreter allows accesses that are invalid, presumably hoping that the dsdt never actually does something bad with them
<calc> iirc the irq query returned invalid data or something like that
<mjg59> Linux forbids that
<calc> ah
* lamont_r considers opening a window
<amu> ack
<seb128> thom, is the internet connection broken ?
<Mithrandir> seb128: no
<seb128> I can't ping anything
<Mithrandir> seb128: but check your name server settings
<elmo> I can't seem to make new connections
<seb128> but my IRC is still working ...
<Mithrandir> worksforme
<lamont_r> what about by IP?
<seb128> works again
<elmo> yeah
<elmo> and gone again.  meh
<seb128> thom, fix the connection dude !!
<thom> i would love to if i could :P
<seb128> you're useless :p
<seb128> and that works again :)
<thom> screw YOU HIPPEH
<thom> so it does. cool
<Keybuk> seb128: fix gnome-panel, dude!
<seb128> daniels, I need an xorg patch out of the 855resolution stuff ?
<daniels> seb128: you shouldn't, no
<daniels> seb128: it's just a tiny binary that you run and it craps all over your video BIOS and hopefully makes it work
<rburton> jdub: poke poke
<seb128> hey rburton 
<rburton> hi seb128 
<seb128> are you going to complain about me breaking the panel ? :p
<rburton> i'm running warty on my ubuntu box, and my sid box has the 2.9 panel on
<seb128> ok ;)
<Treenaks> ah... don't you just _love_ Mac newlines...
* Treenaks pokes the python-serial examples into non-idiocy
<fabbione> dpkg-deb: building package `linux-image-2.6.9-1-itanium' in `../linux-image-2.6.9-1-itanium_2.6.9-3_ia64.deb'.
<fabbione> MUCH BETTER
<pitti> Hi sivang!
<Treenaks> hey sivang
<mjg59> So now we just need some more acpi love in acpi-support
* Keybuk smiles sweetly at mjg59
<mjg59> And a touch more acpi love in initrd-tools
<Treenaks> we need some acpi love for my laptop.. so it doesn't suspend right after coming back from suspend (nice feature..)
<fabbione> Kamion : dpkg-deb: building package `nic-modules-2.6.9-1-itanium-smp-di' in `../nic-modules-2.6.9-1-itanium-smp-di_2.6.9-3_ia64.udeb'.
<mjg59> Treenaks: Mm. That one is a bit odd.
<Treenaks> mjg59: could be a BIOS bug, the thing's 5 years old
<mjg59> Treenaks: It would be good if you could add stuff to /etc/acpi/sleep.sh and try to find out how it's being called
<Kamion> fabbione: nyahaha
<Treenaks> mjg59: I'm running with the "suspend howto" scripts from the wiki
<rburton> mjg59: it appears that when my x22 is using acpi, it won't auto-suspend when the battery is about to die (it did with apm). can i work around this with an acpi script?
<mjg59> rburton: Yes
<koke> is there any wiki page to look for sharing hotel rooms?
<koke> I just want to sleep there at 11th
<mjg59> Treenaks: Ah. Can you try the ones from my acpi-support package?
<Mithrandir> koke: it's at the bottom of the attendees page, I think
<Treenaks> mjg59: url?
<mjg59> Treenaks: http://www.srcf.ucam.org/~mjg59/laptops/
<mjg59> rburton: Well, ish. You need something to monitor battery state and trigger suspend. I think kinnison has something to do that.
<koke> Mithrandir: that's for hostels, I'd like a double room
<koke> but it's too big for me :)
<koke> and too expensive
* fabbione waits for 2 turtles to finish the build before upload -3
<fabbione> mjg59: everything compiled without any problem.
<mjg59> fabbione: Yay
<Treenaks> mjg59: does your script do suspend to ram or disk?
<mjg59> Treenaks: Both
<Treenaks> mjg59: on lid close?
<mjg59> Treenaks: Oh, right. RAM, though that's configurable.
<sladen> thom: http://seehuhn.de/comp/bootlog.html
<Treenaks> mjg59: it looks like lid.sh only does blanking
<mjg59> Treenaks: Oh, right. Just change /etc/acpi/events/lid to run sleep.sh
<mjg59> fabbione: So that stuff'll be uploaded soon?
<mjg59> thom: laptop_mode used to have a function to dump any pid that did a write to disk
<Keybuk> I can't find *anything* on these new menus
<Keybuk> arghhhhhhh
<Keybuk> someone feed seb amphetamines and make him code faster :p
<fabbione> Keybuk: i am sure he will accept patches..
<fabbione> ;)
<fabbione> drivers/input/cpad/cpadconfig.h:40:3: warning: #warning : Framebuffer disabled. Compile kernel with CONFIG_FB and CONFIG_FB_VESA to enable it.
<fabbione> daniels: ^^^^
<sivang> hey seb128
<sivang> seb128 : you in the big room? :)
<seb128> no
<seb128> in the BOF room
<sivang> seb128 : is there still  USPlash BOF?
<bob2> is cpad the crazy lcd-touchpad thing?
<fabbione> yeah
<bob2> ah
<mjg59> fabbione: Is -3 in the archive yet?
<fabbione> mjg59: no. i am still waiting the 2 turtles to finish the test build
<fabbione> it shouldn't take too long
<mjg59> Ah, ok
<bob2> 4
<daniels> fabbione: worship the crack
<fabbione> ah talking of crack
<fabbione> let me check xorg on sparc
<fabbione> it's building
<fabbione> but i am sure it will take a while
<fabbione> running make -j 8 on the kernel + buildd + xorg
<fabbione> on one single cpu
<fabbione> is NOT sane
<fabbione> Mem:    512648k total,   488840k used,    23808k free,    25376k buffers
<fabbione> Swap:  1027008k total,        0k used,  1027008k free,   185352k cached
<fabbione> and i can't manage to make it swap
<fabbione> it's amazing 
<daniels> ls
<daniels> erk, ww
<fabbione> sparc > *
<fabbione> CPU WAR
<elmo> WHAT IS IT GOOD FOR??
<elmo> ABSOLUTELY NOTHING!!
<fabbione> elmo: GO BACK TO YOUR PPC
<fabbione> seriously... i think it's a kernel bug
<fabbione> i need to check on 2.6.9
<fabbione> as soon as *cough*someone*cough* will free my testing harddisk
<fabbione> the sparc kernel needs some extra config love
<fabbione> *sigh*
<pitti> fabbione: I know a good program which makes much of free space
<pitti> fabbione: :-)
<fabbione> pitti: so do i :-)
<pitti> fabbione: this reminds me about the thing we used to say to students who sat in front of a Linux machine for the first time
<pitti> fabbione: "rm -rf *" -> read mail, really fast, all mails
<fabbione> ahha
<sivang> pitti : heheh
<sivang> fabbione : that's what I do , it works like a charm and I am able to read all my mails in time
<sivang> :)
<lamont_r> pitti: I typed that on a machine a few weeks back (as root, in /) just for fun.
<sivang> lamont_r : did you have the /boot partition under that also?
<pitti> lamont: ??? doesn't sound like much fun
<lamont_r> sivang: one partition.
<sivang> it is if you're into reinstalling your system :)
<fabbione> lamont_r: i did that when i left my first telco company on the 2 servers i was administering
<fabbione> they managed to run for a few hours without disks :-)
<lamont_r> was about to flatline the machine, so I was playing with it...
<lamont_r> was interesting to see what was left behind (busy text files)
<lamont_r> er, a.outs
<sivang> I once had my gf's Win32 partition mounted under /mnt , then I forgot to umount and rm -r -v -f /mnt :)
<sivang> luckily at least her uni docs were backed up in her mail account...
<lamont_r> sivang: and you were still together after that?
<seb128> sivang, no
<sivang> lamont_r : hehe, I had to buy her a dinner, take her on vacation, and take some "why do you have to PLAY with stuff all the time, ha?" and then it passed :)
<sivang> kidding
<sivang> :)
<sivang> she just wanted me to stop playing "liunux games" on her machine, I tried to explain her that what happened is a wonderful example for it's streangth :)
<sivang> anyway, people of the bof room, I'm coming up.
<mjg59> Damnit. mkinitrd doesn't have stubs to call stuff after it's generated the image
<Kamion> lamont_r: sbuild fixed, I think ...
<elmo> daniels: done
<Keybuk> ooh, new ITALIAN KERNELS
<Kamion> FICHISSIMO
<fabbione> AHHA
<fabbione> mjg59: eh?
<daniels> elmo: thanks dude
<mjg59> fabbione: The last thing mkinitrd does is send the image to stdout (or a file). But we need to be able to append the DSDT to that.
<fabbione> the strange feeling is that i don't feel addicted to the kernel as much as i felt for X
<jdub_> oh, -3 is uploaded?
<Treenaks> fabbione: not yet.. not yet... <evil laugh>
<mjg59> jdub_: Can you do something for me?
<fabbione> mjg59: good point
<fabbione> jdub_: yes.. with the pwc driver too
<fabbione> Treenaks. DIE!
<fabbione> :P
<fabbione> mjg59: in any case it will take a few hours to get the kernel up, if you prepare a patch we can upload the new initrd-tools
<fabbione> and i will bump again the version in -4
<Keybuk>  Yeah, you're gonna have to face it, you're addicted to X
<mjg59> fabbione: This bit's less important
<jdub_> mjg59: yo
<mjg59> It's only for people like jdub
<fabbione> Keybuk: i am going slowly out of that tunnel
<bob2> *totally* addicted to bass^wX
<fabbione> mjg59: jdub is special.. we know that.. (also ugly.. but.. hey..)
<mjg59> jdub: Edit /usr/sbin/mkinitrd and add to the end:
<mjg59> echo -n INITRDDSDT123DSDT123
<mjg59> cat /boot/DSDT.aml
<mjg59> echo -n INITRDDSDT321DSDT321
<mjg59> Except use proper quotes, not my funky ones
<jdub> heh
<Keybuk> irssi-plugins-of-doom
* fabbione starts reviewing thom's patch
<thom> mdz wants better crack
<mjg59> jdub: But make sure you have latest initrd-tools and 2.6.9-3
<Keybuk> fabbione: ah, that's what you're laughing so hard about
<Treenaks> mjg59: we should patch the shell to accept those quotes!
<daniels> crack me harder
<fabbione> thom: ?
<jdub> mjg59: at the very end?
* thom throws his orange of destiny at Keybuk 
<Mithrandir> mjg59: why use quotes at all?
<mjg59> jdub: Yeah
<jdub> ok
<mjg59> Mithrandir: Because I'm cutting and pasting off a website
<jdub> 2.6.9-3 doesn't seem to be in the archive yet
<mjg59> jdub: Haha
<mjg59> Wait for it to hit, then
* Keybuk is glad he's not the only one who thought the oranges were excessive
<fabbione> jdub: it will take 2/3 hours to be in the archive
<mjg59> Oh, and put your DSDT in /boot/DSDT.aml
<fabbione> jdub: probably less if ccache will hit harder
<mjg59> Hmm. Where should we ask users to put fixed DSDTs?
<fabbione> thom: what kind of crack does mdz wants?
<fabbione> want even
<mjg59> /boot doesn't seem great
<thom> fabbione: block optimisation and reading
<thom> ie, get the kernel to tell us what pages/blocks its reading from during boot, and then reuse that
<fabbione> thom: ok.. you need andrew morton for stuff like that
<Mithrandir> I've been thinking about doing a crack-optimization for ext3.. like what MOSX is doing.
<jdub> mjg59: /etc/mkinitrd...?
<fabbione> thom: i was more concerned to make that patch a bootoption to switch it on/off
<mjg59> jdub: Eww
* fabbione waves his crack to thom
<thom> fabbione: yeah, i wouldn't bother right now
<fabbione> thom: ok..
<fabbione> up to you 2 guys
<daniels> Keybuk: bring your laptop to the bof room and we won't hit you with an orange of destiny
<thom> sorry, shouldve said
<thom> Keybuk: alternatively, tell us where you are
* Keybuk hides
<Treenaks> thom: there are 4 rooms.. can't you search? :P
<Keybuk> I might be Lamonting
<daniels> Keybuk: your hp is so incredibly superior we need to steal it
<thom> Treenaks: LAZINESS IS A VIRTUE
<daniels> and its radeon mobility
<Treenaks> thom: only for Perl people
<thom> Keybuk: kamion was looking for lamont
<Kamion> yeah, he knows
<mjg59> daniels: You need to steal its flawless ACPI support?
<daniels> mjg59: vbe is not quick
<mjg59> daniels: No
<daniels> we want to see how quick boot is with my make-gdm-quicker crack
<mjg59> It's not
<daniels> and an actual video chipset
<mjg59> Haha
<daniels> i855 is like the american beer of chipsets
<mjg59> If users are switching back and forth from X, they deserve to lose
<thom> we wish to bestow bootchart love upon you
<daniels> mjg59: bootup, dude
<mjg59> Oh man
<Keybuk> but boot isn't slow?
<daniels> we can make it faster :)
<mjg59> With VBERestore on, switching to console takes well under a second
<Kamion> PRACTICALLY INSTANTANEOUS
<mjg59> Haha
<Keybuk> you're going to kick ALSA in the head and make it take less than 15s to modprobe the module?
<daniels> Keybuk: it sleeps for some reason
<mjg59> They're going to add & to the end of every modprobe
<thom> Keybuk: coincidentally, i'm just about to find jordi
* fabbione ponders changing nick
<thom> mjg59: *giggle*
<Mithrandir> Keybuk: that'll be solved by hotplug, won't it?
* mjg59 has no idea what happens if you try that
<thom> udevd for great justice
<Mithrandir> uhm, yeah, udevd.
<Keybuk> yo udevd, it's your birthday!
<mjg59> Keybuk: Stop or I will kill you
<seb128> elmo, zenity sync please
<elmo> seb128: done
<Mithrandir> am I the only one in the world who doesn't have an INBOX in my mail and think that any mail client that forces you to have one si insane?
<daniels> Mithrandir: no
<Keybuk> mail clients force you to have one?
<seb128> elmo, thanks
<Kamion> lrwxrwxrwx    1 cjwatson cjwatson       18 Jun  8  2004 INBOX -> /var/mail/cjwatson
<Kamion> lrwxrwxrwx    1 cjwatson cjwatson       18 Jun  8  2004 inbox -> /var/mail/cjwatson
<Treenaks> Mithrandir: what kind of evil and wrong client/server combination are you using?
<Mithrandir> Keybuk: I won't think how m-t is going to freak out if I remove INBOX.  And besides, it might very well start up in a folder, but make that be configurable, preferably with %Y and similar magic
<Keybuk> m-t?
<Keybuk> oh, THUNDERBIRD
<Keybuk> I still can't get over how they chose that as their mail client name, after fucking around trying to find someone that wasn't already used for Firefox
<Treenaks> Keybuk: you mean Moongorilla/
<Kamion> THUNDERPANTS
<sivang> hehe
<Mithrandir> it's one of the less insane clients.
<daniels> Kamion: you know that was an actual movie, yeah?
<Kamion> I just googled for it
<daniels> Keybuk: 'firethingy'
<Kamion> http://www.thunderwear.co.nz/go/home/index.cfm
<daniels> Kamion: it was a movie about some kid who couldn't stop farting
<daniels> seriously
<fabbione> anybody has a freshmeat account?
<Treenaks> fabbione: that depends, why? :)
<fabbione> Treenaks: downloading a wm theme. 
<Treenaks> fabbione: you can't download without an account?
<Treenaks> that's crack
<daniels> <keybuk>freshmeat in crack shocker</keybuk>
<fabbione> Treenaks: nope.. it tells you that it is a login only area
<fabbione> probably because it's a horror theme or something
<Treenaks> scary
<fabbione> violence and crap like that
<Mithrandir> jdub: you're wanted in s3kr1t channel.
<fabbione> i am just too lazy to: a) register, b) go in my room to pick up the dvd and do one myself
<fabbione> i guess i will opt for the second one later today
<lupus_> dpkg: error processing /var/cache/apt/archives/polypaudio-alsa_0.7-0ubuntu1_i386.deb (--unpack):
<lupus_>  trying to overwrite `/usr/lib/polypaudio-0.7/libalsa-util.la', which is also in package polypaudio
<lupus_> Preparing to replace polypaudio-x11 0.6-1ubuntu1 (using .../polypaudio-x11_0.7-0ubuntu1_i386.deb) ...
<fabbione> ahhh got it
<Kamion> anyone want to provide text for the comment above hoary-updates in the default /etc/apt/sources.list? (#3122)
<seb128> jdub, you broke polypaudio dude :p
<mjg59> Man, that jdub breaks everything
<lupus_> wasn't polyaudio at version 0.10?
<fabbione> Kamion: hmmm difficult problem...
<fabbione> Kamion: i am more for "let's add them"
<Kamion> fabbione: argue with mdz
<Kamion> :)
* Kamion goes for:
<Kamion> ## Uncomment the following two lines to fetch major bug fix updates produced
<Kamion> ## after the final release of the distribution.
<Kamion> fabbione: one problem is that hoary-updates doesn't actually exist right now, so just adding it is a touch problematic
<jdub> ahr
<jdub> badness
<fabbione> Kamion: don't we have our ftpmaster here around anyway? ;)
<rburton> mvo: ping?
<mvo> rburton: pong
<Kamion> sure, he's busy just now though
<Kamion> we can always change it later, plenty of time for base-config changes
<rburton> mvo: got an arch repos for gnome-app-install going online now if you want to hack
<fabbione> i would still prefer to have them commented out
<mvo> cool, can you send me the adress and stuff?
<Mithrandir> is there a howto on how to maintain debian packages in arch somewhere?
<rburton> mvo: whats your email?
<mvo> mvo@debian.org
<lifeless> Mithrandir: manoj has one.
<Mithrandir> lifeless: on p.d.o?
<mvo> rburton: thanks a lot!
<lifeless> Mithrandir: dunno
<seb128> thom, say to jordi that he's supposed to upload a new howl instead of hanging around
<daniels> seb128: no, he has to fix alsa first
<seb128> ah ah
<sivang> seb128 : has anything happened to the "Programming" menu entry on the applications menu? I can'f find it anymore, nor I don't get it when installing the devhelp-book stuff, or the glade authoring environment.
<seb128> sivang, same here
<sivang> seb128 : strange, at home I have also a hoary and I have this menu item, anything intentionally changed or a sid sync on the menus?
<trulux> hi
<trulux> lamont, hey
<seb128> daniels, grrrr, you have still not fixed the fd specifications !!
<seb128> hopefully google cache is nice :)
<trulux> hi mdz
<fabbione> parsechangelog/debian: warning: unknown urgency value crack - comparing very low, at changelog line 1
<fabbione> hmm
<fabbione> elmo: can we fix that?
<daniels> seb128: WEFRPOI#@$WQDFEWaesfiu
<daniels> seb128: which spec do you desire a copy of?
<seb128> menu-spec would be nice ;)
<daniels> seb128: (most of the generated HTML specs were broken in the old setup anyway)
<elmo> fabbione: huh?
<daniels> http://gabe.freedesktop.org/~daniels/menu-spec/
<seb128> daniels, thanks
<fabbione>  parsechangelog/debian: warning: unknown urgency value "crack"
<fabbione> ;)
<daniels> no worries
<daniels> hmm, I suppose I have to ia64ify l-r-m now
<daniels> elmo: could I please get concordia's chroot jiggy and higgy with the latest headers too?
<thom> ok, S99sysklogd ; lets see what happens
<elmo> daniels: done
<daniels> elmo: thanks
<daniels> MORE CRACK FOR THOM
<daniels> he is clearly deficient in that regard
<fabbione> i found an interesting way to break the kernel build system
<fabbione> fabbione@gordian:/usr/src/wartydevel/kernel/linux-source-2.6.10-2.6.9+10rc3$ fakeroot make -f debian/rules clean
<fabbione> debian/rules:79: *** first argument to `word' function must be greater than 0.  Stop.
<daniels> fabbione: awesome
<fabbione> i think it's the +rc3
<sivang> anybody know if there is or isn't a pkg maintainace workshop?
<sivang> it's 16:29, local time ;)
* sivang really expected this workshop
<thom> dude, it may be crack, but it shaved 12 seconds off the boot
<seb128> thom, what did you do ?
<thom> seb128: started sysklogd at S99 in rc2
<pitti> seb128: S99sysklogd :-)
<fabbione> thom: i am seriously against it
<seb128> oh, ok :)
<pitti> thom: but wouldn't that somewhat nullify the point of syslog?
<smurfix_> thom: Owch.
<thom> well, yes
<thom> i was just interested, i'm not planning on suggesting that we *do* it
<pitti> thom: don't start gdm, it will further improve boot speed
<thom> pitti: yeah, X sucks so hard
<fabbione> thom: thanks :-)
<pitti> thom: however, interesting that it gains _that_ much
<smurfix_> thom: So your next job is to figure out _why_ it slows down boot that much. ;-)
<thom> pitti: indeed
<smurfix_> My first guess would be excessive syncing
<thom> especially since most all the logs i have are async
<smurfix_> thom: there is that
<mdz> trulux: hi
<thom> i do wonder how much parallel init would win us
<trulux> mdz, when doko would get available? i need to talk with him about the toolchain patches
<mdz> trulux: he doesn't look terribly busy
* daniels looks at his solid disk light.
<thom> mdz: you have eyes in the back of your head now?
<lifeless> you looking on fdo?
<daniels> lifeless: nope, fd.o is holding up fine
<lifeless> :)
<daniels> just trashing an X bulid tree so I can get another one
<lifeless> bulid eh?
<daniels> sure is
<daniels> so I can timestamp all the logs
<daniels> PROFILE X
<bob2> mjg59: daniels when I close the lid and open it again (which afaict only turns the backlight off) the top..20th of the csreen or so goes multicoloured, with everything else shifted down.  switching to a vt and back again fixes it.
<daniels> bob2: yeah, known issue
<daniels> bob2: vberestore should fix that
<bob2> ah
<thom> and for my next trick, i shall replace depmod with a small shell script
<seb128> sivang, no, in fact it works fine here, the Programming category popup as soon as I install something using it
<daniels> (thom isn't joking.)
<mjg59> bob2: Yeah. That's why lid.sh has chvt 12; chvt fgconsole;
<mjg59> jdub: Around?
<Mithrandir> anybody use tla-buildpackage and friends?
<thom> Mithrandir: tla-buildpackage or arch-buildpackage? tla-bp is utter crap from what i can tell (and lifelless agreed)
<Mithrandir> what is it with those arch people forking and reinventing wheels?
<Mithrandir> I'll use arch-bp, then
<thom> tla-bp is goerzen shit, fwicr
<Mithrandir> it's hard to tell the crackheads apart in tla-world.
<Mithrandir> and arch-bp is asuffield crack
<robtaylor> wheee!!!
<thom> yeah, but is actually not shit
<Mithrandir> it's just crack?
<mjg59> Hoi
<mjg59> People with laptops
<mjg59> Can you test something for me?
<thom> yo
<mjg59> (Warning: may result in loss of unsaved work)
<Mithrandir> depends
<mjg59> thom: Haha
<mjg59> I've tested on X40 already
<robtaylor> mjg59: people with laptops near you, or people with laptops in general?
<thom> oh well
<Mithrandir> somebody has made Postgres 8.0rc1 live cds.
<thom> i shall go back to doing stupid things in the name of booting fast
<mjg59> In general
<mjg59> I need people to run http://www.codon.org.uk/~mjg59/tmp/vm86_video_post from a text console and tell me what happens
<mjg59> (Warning: may result in loss of video)
<Mithrandir> thom: does it have any docs?
<Keybuk> what kind of cards you after?
<mjg59> Keybuk: Any/all
<thom> Mithrandir: yeah, somewhere
<robtaylor> mjg59: will try it out as soon as i get home..
<Mithrandir> thom: how useful.  I'll go look somewhere, then.
<bob2> mjg59: worth trying on my apparently buggier x40?
<mjg59> Go for it
<thom> Mithrandir: in /usr/share/doc; iirc
<Mithrandir> heh, ok
<Mithrandir> thx
<bob2> mjg59: scott wants to know if he can unfuck his video now
<bob2> since he missed the disclaimer
<bob2> and is now whinging
<mjg59> How fucked is it?
<bob2> L lovely strip pattern
<mjg59> Hrm.
<bob2> I believe the goodies had trousers like it in the 70's
<mjg59> Tell him to switch to X again.
<bob2> no dice
<mjg59> Away from X and back again?
<Mithrandir> seems like he rebooted
<seb128> ah ah
<bob2> he hasn't he rebooted
<bob2> seems his kernel went down
<mjg59> Oh dear.
<bob2> mjg59: keys did nothing at all
<mjg59> That's slightly depressing.
* robtaylor hopes Keybuk doesn't go and kill mjg59 now..
<bob2> daniels: thom oi
<bob2> scott wants you to break his machine now
<mjg59> Oh, hang on
<thom> where is he?
<mjg59> I see why that might have happened
<bob2> quiet room
<bob2> but it's rather unquiet
<daniels> oh, cool
<thom> bob2: please ask him to come to the bof room so we can talk?
<daniels> the bof room is way cooler
<mjg59> Someone tell Scott I fucked up, and can I give him another one to try?
<bob2> he's slightly bitter but willing
<daniels> mjg59: what'd you put in ax?
<bob2> like english coffee
<mjg59> daniels: 0x100, not 105
<daniels> mjg59: oops
<mjg59> Oh, argh. Now I need to work out whether it's supposed to be 105 or 150
<mjg59> Right. 150.
<mjg59> Can someone get him to try http://www.codon.org.uk/~mjg59/tmp/scott_vm86_video_post
<mjg59> (and tell him that he's lovely and I'm sorry I screwed his screen)
<seb128> <Keybuk> thom's playing fucky-pants with it at the moment
<mjg59> Haha
<jdub> mjg59: back
<mjg59> jdub: Can you stick a lspci somewhere and then test something for me?
<mjg59> (note: may result in strange patterns on LCD)
<jdub> heh
<jdub> okay
<mjg59> Something entertaining has suddenly come to mind. Oh well.
<rburton> jdub: what's this i hear about gnome-app-install and instant apply
<rburton> crack i say!
<jdub> rburton: one sec
<jdub> mjg59: mailed
<jdub> rburton: what do you think about swapping the checkboxes with install/remove buttons?
<jdub> rburton: this was suggested at the bof - i'm not convinced.
<rburton> jdub: my argument against instant apply is what if the user installs OO.o?  
<rburton> they'll have to wait ageeees until they can also select another application, if they want to install two
<jdub> it was not so much instant apply as "press the install button per package"
<jdub> which results in an immediate install
<Keybuk> mjg59: ok fuckhead, what's your clever second binary URL? :p
<robtaylor> jdub: install/remove buttons sound saner
<Mithrandir>                http://www.codon.org.uk/~mjg59/tmp/scott_vm86_video_post
<jdub> i think it's going to require some convincing of ross and i
<jdub> or beer
<daniels> same thing
<mjg59> Arse
<rburton> jdub: sounds like instant apply to me. mvo thinks its crack too
<robtaylor> jdub: beer for you on thursday night then...
<mjg59> jdub: http://www.codon.org.uk/~mjg59/tmp/jdub_vm86_video_post ?
<Mithrandir> mjg59: new form of wallpaper
<mjg59> Mithrandir: Mm?
<thom> mjg59: that new one is still pretty wallpaper
<Mithrandir> mjg59: for Keybuk, that is.
<thom> (says scott)
<Mithrandir> thom: not very pretty.. more psychedelic
<rburton> waaa
<Mithrandir> like, vertical bright colored stripes.
<mjg59> Maybe it's supposed to be bus,device and not bus,device,function
* mjg59 wonders
<rburton> daniels: why can't i click on the links on fd.o to get to the .desktop specs! :)
<daniels> rburton: BECAUSE YOU WILL DIE SHORTLY
<daniels> that's why :P
<rburton> oh.
<mjg59> Interestingly, machines that break with video_post are almost exclusively machines which don't have video at 01:00.0
* mjg59 tries to find one of those around here
* fabbione points Kamion to http://people.ubuntulinux.org/~lamont/buildLogs/l/linux-source-2.6.9/2.6.9-3/
<fabbione> PUMP UP THE VOLUME BABY
<fabbione> MAKE IA64 SING MAN!
<mdz> elmo: can I get a copy of that bzip2 diveintopython deb as a test case?
<daniels> rburton: http://gabe.freedesktop.org/~daniels/desktop-entry-spec/
<daniels> mjg59: hmmm
<daniels> mjg59: 0000:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02)
<daniels> (no, I'm not going to tank my X session right now)
<jdub> mjg59: run this as root?
<rburton> daniels: you rock
<seb128> no, he sucks
<jdub> rburton: do you like gnome-menus?
<fabbione> daniels IS teh suck
<jdub> rburton: reckon we could do g-a-i stuff via gnome-menus?
<seb128> I'm stucked with a 1024x768 resolution
<elmo> mdz: it's in my home dir on chinstrap
<daniels> fabbione: and how!
<daniels> fabbione: what've I done now?
<fabbione> daniels: oh yeah.. more than a pornstar
<daniels> whoo
<fabbione> daniels: nothing ... yet...
<fabbione> :P
<mdz> elmo: thanks
<daniels> haha
<daniels> i'm PROFILING X, MAN
<mdz> elmo: I've got the changes to apt more or less done, needs testing
<daniels> (bad shot.)
<fabbione> daniels: should i try again?
<rburton> jdub: hell yeah
<daniels> only if you stay where you are now
<mjg59> jdub: Yeah
<rburton> jdub: actually i've got bits of 2.9 installed on my sid box, i'll give it a go later
<daniels> nice work
<fabbione> ahaha
<rburton> mallum says the default desktop wallpaper looks shit on 3072x768
<daniels> rburton: ... xinerama?
<mjg59> daniels: That's a very good point
<sivang> ogra : here? 
<mjg59> I wonder why it works here.
<elmo> mdz: neato
<daniels> or just multi-screen
<bob2> if mellum gives me his screens, I will volunteer to fix it
<rburton> daniels: xinerama
<daniels> his tfts are beautiful
<daniels> bob2: (mallum)
<jdub> rburton: rocking, that'll be very sweet
<rburton> daniels: dude, they are sucky tfts
<jdub> mjg59: is this going to crash, break, halt...?
<daniels> rburton: are they?
<daniels> they looked shiny, at least, and there were three of them
<daniels> that negates any suckage
<rburton> daniels: i thought they were cheap ones, but yeah, three screens rocks
<daniels> ahr
<daniels> yeah
* Mithrandir ponders getting two decent ones.
<rburton> i think ubuntu needs a super-widescreen version of all wallpaper
<fabbione> daniels: if you want to make X faster, just stick some gentoo options at build time
<fabbione> -o1337
<fabbione> or stuff like that
<mjg59> jdub: Might give weird screen effects
<rburton> maybe the blonde laying across them all
<daniels> fabbione: i'm settling for timestamping on the logs atm
<fabbione> daniels: what part of the code do you expect to optimize?
<fabbione> daniels: if you are luck you can manage to kill some startup sanity checks
<jdub> mjg59: hmm
<fabbione> once you know the previous startup was safe and no changes to the config have been done
<jdub> mjg59: smoother than normal suspend/resume
<jamesh> the wallpaper also looks shit at 2560*1024
<fabbione> same at home
<jdub> mjg59: now i don't have a mouse cursor
<Mithrandir> mice are for weenies
<mjg59> jdub: What you do it from a text console?
<jdub> what if or did i?
<jamesh> the fix is probably to get Nautilus or Eel to repeat the wallpaper for xinerama-style multiscreen
<mjg59> jdub: Oops. Did you?
<jamesh> multi-head, even
<jdub> mjg59: no, i didn't
<mjg59> jdub: Ah. Could you try?
<daniels> fabbione: well, if anything, we'll just find where the huge bottlenecks are
<daniels> we know where that is for i855: VBE
<daniels> but who knows, we might turn up stuff like the ICE sleep
<Treenaks> jdub: did you get my mail yesterday about the -nl mailinglist?
<Treenaks> (not sure I sent it to the right address)
<fabbione> daniels: yeah
<mjg59> Has jdub's laptop blown up?
<jdub> Treenaks: hrm, i don't think so
<jdub> mjg59: no
<jdub> mjg59: running around a bit :)
<mjg59> Heh
<jdub> it was just kinda weird
<Treenaks> jdub: well, could you create it? :)
<jdub> Treenaks: can you mail a summary and description of the list?
<jdub> mjg59: in both cases it flashed weirdly
<Treenaks> jdub: uh OK, what's the right address?
<jdub> mjg59: from X it came back to X
<jdub> Treenaks: jeff.waugh@canonical.com
<mjg59> jdub: But none of the screen melting that you got before?
<Treenaks> jdub: ok, thanks
<jdub> mjg59: no
<jdub> mjg59: good point :)
<jdub> mjg59: hrm, i'll have to try console again
<jdub> mjg59: it didn't return to the console properly
<jdub> mjg59: just about to start a bof though
* thom watches daniels rip random sleeps out of X
<mjg59> jdub: You'd need to at least hit enter again after running it
<Kamion> fabbione: rock
<Kamion> FABBIONE 
<Kamion> where have all my powerpc nic-modules gone?
<thom> *giggle*
<Kamion> specifically sungem, but there are several other missing ones
<Treenaks> Kamion: restricted-modules?
<Kamion> hell no!
<Kamion> I don't see why it isn't getting built, the list files are right
<fabbione> Kamion: ehhh???
<fabbione> Kamion: i didn't touch anything on ppc
<Kamion> fabbione: it's between 2.6.8.1-19 and 2.6.9-1
<fabbione> Kamion: the lists are the same
<fabbione> Kamion: we need to check the ppc logs
<fabbione> as soon as they will be available
<Kamion> they're available, 2.6.9-1 and 2.6.9-2 are both broken this way
* fabbione suspects something broken in kernel-wedge
<fabbione> Kamion: hold on
<Kamion> mmm, I tend to agree
<Kamion> which is SCARY
<fabbione> Kamion: i am checking on the port box
<fabbione> Kamion: can you tell me an exact package name that is missing
<fabbione> ?
<Kamion> missing module drivers/net/mv64340_eth.o
<Kamion> that's in the build log; it might well be giving up there
<Kamion> it's not packages that are missing, just some modules from nic-modules
<fabbione> ah ok
<fabbione> HMM
<Kamion> did that driver get renamed?
<fabbione> i understood that there were missing udebs from the lists
<fabbione> Kamion
<fabbione> not that i am aware of
<mjg59> That driver got renamed, I think
<Kamion> it's not in 2.6.8.1 either though
<mjg59> It's 643xx
<mjg59> (now)
<Kamion> kinda makes me wonder how it ever worked
<fabbione> Kamion: what are modules are missing?
<Kamion> fabbione: hang on a sec
<fabbione> Kamion: sure... take all the time you need
<fabbione> i am trying to figure out an easy path to package the kernel without too much crack
<Kamion> they seem to have disappeared in either 2.6.8.1-18 and 2.6.8.1-19
<Kamion> in fact mv64340_eth disappeared from the .deb at that time, for no reason that's explained in the changelog
<fabbione> Kamion: i am really sure i didn't change anything in terms of compilation
<fabbione> other than adding the udeb generation from linux-source
<fabbione> and adding sparc
<fabbione> but no config updates or anything took place in 2.6.8.21
<fabbione> hem
<fabbione> .1
<Kamion> -18_powerpc.deb seems to be missing from the morgue though
<fabbione> -18 never had the time to compile
<fabbione> -19 arrived in less than 20 minutes after
<fabbione> so -17 -> -19 diff is ok
<Kamion> ah, ok
* fabbione needs some crack
<mdz> elmo: have you grepped for data.tar.gz in katie?
<mdz> elmo: the python API is such that if you want data.tar.gz, you ask for it by name
<mdz> elmo: I've fixed the bit where it will abort if it isn't present, and fixed apt-ftparchive contents
<mdz> elmo: anything else would be a problem external to apt
<elmo> mdz: yeah, I know it does dude, but there was a bit of python-apt that needed fixed :P
<mdz> elmo: which bit?
<mdz> the only problem I found which I thought would affect katie was the check which bombed out if data.tar.gz was missing, in libapt-inst
<mdz> python-apt doesn't reference data.tar.gz
<elmo> Rejected: diveintopython_5.4-1ubuntu1_all.deb: deb contents timestamp check failed [exceptions.SystemError: This is not a valid
<elmo> DEB archive, missing 'data.tar.gz' member] 
<elmo> that bit in []  doesn't come from katie ...
<mdz> yep, that's the bit I fixed
<elmo> well okay, after the : ;P
<elmo> ok
<mdz> so if that's the only error you encountered, we're in good shape
<mdz> katie doesn't actually do anything with data.tar.(gz|bz2), right?
<elmo> "do" how?  it does checks on it
<elmo> actually, it's just the timestamps check that matters immediately
<elmo> I'll have to fix the NEW checking stuff too, but that's less critical
<mdz> ah, ok
<Kamion> fabbione: right, looks like it's just mv64340_eth; if you restore the CONFIG_MV64340_ETH* config entries from 2.6.8.1-19, s/MV64340/MV643XX/g on that, and s/mv64340/mv643xx/g on debian/d-i/powerpc/modules/powerpc/nic-modules, that should do it
<Kamion> fabbione: however, the fact that the build didn't fail is a pretty serious kernel-wedge bug ...
<daniels> (gdb) 
<daniels> 568             LogVWrite(-1, f, args);
<daniels> (gdb) print f
<daniels> $3 = 0x81cf1c4 "\nFatal server error:\n"
<daniels> (gdb) print args
<daniels> $4 = 0xbfffd6e4 ""
<daniels> (gdb) step
<daniels> Breakpoint 1, LogVWrite (verb=136387520, f=0x0, args=0x0) at log.c:256
<daniels> wtf?
<fabbione> Kamion: kernel-wedge didn't fail because of the || true
<fabbione> Kamion: since it was barfing on other unrelated problems
<mjg59> HRNGH.
* mjg59 discovers that video_post gets its PCI device ID calculations wrong
<Kamion> uh. you run kernel-wedge with || true?
<fabbione> Kamion: isn't the driver built on 2.6.9 at all? afaik it does, but i can double check that
<fabbione> Kamion: yes, we already discuss it a few days back.
<Kamion> it's not built at all; you need to change the config
<fabbione> Kamion: ok. that's easy to do.
<Kamion> hm, ok, don't remind me, I don't want to know :)
<fabbione> Kamion: i will remind you instead :-)
<fabbione> kernel-wedge is not designed to face that mess
<Kamion> looking at the diff the settings actually got deleted from the powerpc configs in 2.6.9-1
<fabbione> and it barfs on the debs
<fabbione> Kamion: if a CONFIG_* doesn't exist anymore, it gets automatically deleted, but the weird thing is why i wasn'
<fabbione> wasn't prompted for the new one
<Kamion> mkay
* Mithrandir grumbles at no gaim-dev
<mjg59> daniels: Ok, so it turns out that video_post has generally been initialising the wrong video card
<mjg59> Which explains a lot of the misery
<Mithrandir> heh
* Keybuk makes obscene gestures at mjg59 
<mjg59> Keybuk: I've still no idea why it doesn't work on yours, but if you want to try my latest version of it, feel free
<Keybuk> the screen goes black (dpms-style)
<Keybuk> then when you switch to the X display, X go bye-bye and shows a picture of my gran's wallpaper
<Keybuk> (tasteless green and white vertical stripes)
<mjg59> Keybuk: Oh, right!
<mjg59> That happens when you switch back to X?
<Keybuk> yes
<mjg59> Can you add Option VBERestore true to your device section?
<Keybuk> it doesn't restore at all otherwise
<mjg59> That's X getting horribly confused, then
<Keybuk> I can try, but can't test for a while
<mjg59> Rather than my code being broken
<mjg59> Rock
<daniels> to be fair, your video card usually isn't posted into an unknown state from under you
<Keybuk> which device section?
<mjg59> Keybuk: The ati one
<Keybuk> both?
<Keybuk> there's two
<mjg59> Keybuk: There are?
<Keybuk> yeh, laptop has two screens
<mjg59> Oh, right
<mjg59> The primary one, then
<Keybuk> right
<Keybuk> can't test for a bit though, I'm coding and don't want X dieing *again*
<mjg59> daniels: Hang on a sec. How about we do vbe save/restore from userspace on ACPI rather than have the X server do it all the time?
<mjg59> Would that improve your performance issues?
<daniels> mjg59: it would improve i855's performance massively, but I think I can get a reasonable performance boost with some other shit I'm working on
<mjg59> daniels: Ok, I'll look into that now
<mjg59> (It'll be x86 only, but...)
<daniels> unfortunately, if you declare a pointer in local scope in LogVWrite, its arguments go away
<daniels> which sucks, because it's shit right now
* daniels reboots.
<Treenaks> daniels: like, removing random sleep()s?
<daniels> Treenaks: partially, yah :)
<fabbione> isn't trukulo around?
<fabbione> i tought he was coming here today
* Kamion emerges from scary sbuild weirdness
<Kamion> do we want to start defaulting to new kernels soon?
<Kamion> I ask because I need to change rootskel to use 2.6.9 anyway on ia64
* lamont_r thanks Kamion for fighting the fearsome sbuild-monster.
<fabbione> Kamion: i am doing a testbuild right now
<fabbione> Kamion: go ahead and switch to 2.6.9
<fabbione> i don't think we have any more regressions other than the ppc bits
<fabbione> that i can easily upload this evening
<fabbione> since it's a simple thing
<Kamion> we should switch linux-meta as well to get the right packages on the CD
<Kamion> mdz: feel like doing that?
<fabbione> mdz: if so.. can you also add sparc please?
<Kamion> and at some point I should actually release a new Array CD. :)
<fabbione> ehehe
<Treenaks> oooh.... coolness.... http://www.syswear.com/
<fabbione> Kamion: i figured why it didn't build at all
<fabbione> Kamion: and i wasn't prompted for the new symbol
<fabbione> this is a pain to fix
* thom waves goodbye to depmod
<sladen> thom: according to mjg59 Scitech have already split the x86 emulator out from X and it's on their website
<mjg59> (scitech wrote the x86 emulator in X)
<fabbione> Kamion: i am going to readd that stuff, but you will have to test it
<fabbione> Kamion: not even google knows where the patch Herbert applied comes from
<Kamion> fabbione: sure; I can't test that driver though, the one I was missing on my hardware was sungem
<mjg59> Is this the Marvel driver?
<Kamion> fabbione: which got lost 'cos it was after mv64340_eth in the modules file
<mjg59> If so, it probably came from Sven
<Kamion> fabbione: I checked, nothing else was missing
<Kamion> oh, I wonder if my pegasos has it?
<mjg59> It's the gigabit ethernet on the Pegasos 2
<Kamion> $ ssh crydee
<Kamion> ssh: connect to address 192.168.124.37 port 22: No route to host
<mjg59> Haha
<Kamion> d'oh, maybe it fell over
<Kamion> well, I'll give it a go when I get home, can only plug 100mbit into it though
<fabbione> Kamion
<fabbione> i don't think sven can even code 2 lines of what is in that patch
<mjg59> fabbione: Sven won't have written it, but it'll have come through bplan
<mjg59> (or genesi, or whicever bit of the company is pretending to have money this week)
<fabbione> mjg59: i will rather rediff it than ask him for a new patch
<mjg59> Haha
<mjg59> But isn't it in the stock kernel now?
<mjg59> As mv643xx rather than mv64340
<fabbione> no the pegasos part
<mjg59> There's only something like 1000 Pegasoses in the wild, and most of those are with developers, so I wouldn't worry about it too much
<fabbione> mjg59: well.. Kamion has been asking for it :-)
<fabbione> in anycase the thingy is partially merged
<fabbione> the rejects are trivial to merge
<fabbione> there were 2/3 lines that were *scary*
<Kamion> fabbione: no I haven't?
<fabbione> but nothing impossible to do
<mdz> fabbione: you have a fix for the usb-storage bug?
<fabbione> Kamion: for the mv643xx ?
<Kamion> I want mv64340_eth to build so that it and everything after it alphabetically end up in the nic-modules udeb
<Kamion> sorry, mv643xx_eth
<fabbione> Kamion: we are talking about the same driver
<Kamion> I don't especially care whether or not it works :)
<Kamion> yes, I know
<Kamion> 18:37 < fabbione> mjg59: well.. Kamion has been asking for it :-)
<fabbione> Kamion: it doesn't build on ppc if the code is not merged :
<fabbione> :-)
<Kamion> ah, I see
<fabbione> + #ifdef __PPC__
<fabbione> +       dev->irq = 9;
<fabbione> + #else
<fabbione>         dev->irq = ETH_PORT0_IRQ_NUM + port_num;
<fabbione> + #endif
<fabbione> 
<fabbione> stuff like this :-)
<fabbione> mdz: i did change the config on your request. the ohter bug is in the scsi layer
<fabbione> mdz: if you can check bugzilla on kernel.org for a patch would help kthxbye :-)
<mdz> fabbione: we cannot use 2.6.9 as default until that bug is fixed. it is a serious regression from 2.6.8.1
<mdz> it is not clear whether the bug is in scsi or usb
<mdz> I am on the CC list for the kernel.org bug; there has been no activity that I saw
<Kamion> at the moment we are using 2.6.9 in the installer and 2.6.8.1 in the installed system, which is crack
<Kamion> it will result in hotplug desync
<mdz> but I have no idea whether the people who work on those subsystems actually look at bugzilla at all
<Kamion> if we are going to use 2.6.9 in hoary I'd rather that we defaulted to it now
<mdz> it makes me unable to do necessary development tasks
<fabbione> mdz: we did disable the usb_blk_ub thingy already
<Kamion> I thought Fabio had turned off the worst of it
<mdz> fabbione: yes, I know
<fabbione> mdz: and there are 2 bugs on bugzilla.k.o about the same stuff
<mdz> that is one out of two show-stopper bugs
<fabbione> one of the says that it is in the scsi layer
<fabbione> and that has been fixed
<fabbione> in some 2.6.10-crack version
<mdz> the comment that says it is in the scsi layer is from someone who has no idea what they are talking about
<mdz> oh, good
<mdz> so we can pull the patch and be done with it
<fabbione> mdz: if you know what to pull....
<fabbione> mdz: it's not a case that today i started a little crack branch
<mdz> er
<mdz> I am looking at the kernel.org bugs and I see no indication that it is fixed anywhere
<mdz> where did you see that?
<fabbione> it was in the bug report
<fabbione> it is written something like "this has been fixed a while ago"
<fabbione> or similar
<mdz> you must be looking at a different bug than I am
<mdz> http://bugzilla.kernel.org/show_bug.cgi?id=3787
<fabbione> mdz: possibly
<mdz> http://bugzilla.kernel.org/show_bug.cgi?id=3829
<fabbione> i don't have it handy now
<mdz> those are the two that I am aware of
<fabbione> i looked for a few days back
<fabbione> mdz: you will be my testing bitch :-)
<fabbione> because i already have this:
<fabbione> linux-source-2.6.10-2.6.10               linux-source-2.6.10_2.6.10-0rc3.dsc
<fabbione> linux-source-2.6.10_2.6.10-0rc3.diff.gz  linux-source-2.6.10_2.6.10.orig.tar.gz
<herzi> 'd
<fabbione> + this is kinda.. hmmm hoary?
<fabbione> so i mean.. it can break
<trulux> anybody here with usb 2.0? :P
<trulux> i can't get working an external ide-to-usb disk
<trulux> the typical usb-storage device
<mjg59> daniels: The good news is, I have code that can save and restore state from userspace
<mjg59> daniels: The bad news is, it dies if it's run under X
<mjg59> This isn't /necessarily/ a problem
<mjg59> But I'll look at that later on
<bronson_> Anyone know if there are plans to get the CVS xorg into Hoary?
* sid77 hi!
<ironwolf> bronson: daniels might know.
<moquist> hi sid77 
<daniels> mjg59: the posting stuff dies?
<daniels> bronson_: 6.8.2, yes, and I've already taken most of it back
<daniels> bronson_: but really, nothing interesting is otherwise happening in cvs, other than a pending reorganisation
<mjg59> daniels: No, VBE save/restore
<mjg59> POST+vbe state restore+X might be enough
<daniels> which won't be interesting from a user point of view
<mjg59> Mm?
<mjg59> If the user ever runs this stuff, they deserve what they get :)
<mjg59> Actually, it should check that it's running on a console and exit otherwise
<mjg59> So we switch away from X, save state, suspend, POST, restore state, switch back to X
<mjg59> Which ought to let you drop VBERestore from X
<mjg59> daniels: So vberestore save sends vbestate to stdout. vberestore restore accepts it from stdout.
<daniels> mjg59: heh, yeah :)
<daniels> mjg59: right, sounds sane
<daniels> cool
<daniels> mjg59: you could hac^H^Hook into xf86EnterVT() and xf86LeaveVT() if you were feeling particularly sick
* sid77 bye
<bronson_> daniels: taken most of it back?  what do you mean?
<mjg59> daniels: That just sounds... unnecessary
<bronson_> 6.8.2 turns off the backlight on my laptop.  I'm hoping I can wait a week and download new packages, rather than trying to compile x myself...
<mjg59> daniels: That functionality is centralised anyway, so I'm not sure why some drivers don't use it
<bronson_> I want to try it so I can close the bug filed on xorg bugzilla.
<bob2> thom: daniels discovered he was too soft to come back
<Treenaks> wow
<Treenaks> 11mbit in my room ;)
<Kamion> fabbione: let me know when you've done the linux-meta update for ia64 (lamont said you were doing it?), so I can update rootskel and base-installer
<thom> lamer
<Kamion> fabbione: what should I do in the installer if I spot sparc32? erroring out requires a string change ...
* Kamion is inclined to ignore it on the basis that you couldn't have got that far since we don't have sparc64 images
<Kamion> er, sparc32 images
<Treenaks> jdub is on slashdot again.. his name at least
<mjg59> daniels: Rocking
<mjg59> I can do vbesave and vberestore
<bob2> mjg59: daniels is suggesting that unloading ipw2100 before sleep might make it more stable
<mjg59> I do that, don't I?
<mjg59> Hrm. That's interesting. X is taking about 30% of CPU.
<bob2> not in /etc/acpi on my system
<bob2> maybe daniels' crack doesn't
<mjg59> Ah
<mjg59> Yeah, you want my crack
<mxpxpod> I compiled my own kernel and did make-kpkg kernel-headers and the resulting package has nothing in it
<mxpxpod> is there a reason for this?
<bob2> mjg59: hm, I have your crack, still no mention of ipw2 in /etc/acpi
<mjg59> bob2: Yeah, it automatically works out the list of network modules
<bob2> mjg59: oh, shiney
<bob2> no reboot needed, right?
<Keybuk> mjg: so, video-post ...
<mjg59> Nope
<mjg59> Keybuk: Yo
<Keybuk> it makes my screen switch off
<mjg59> Yeah
<Keybuk> and even with VBERestore, makes X.org very very unhappy
<mjg59> It seems to do that sometimes
<mjg59> Hm
<bob2> hm, woke up immediately
<thom> keybuk is singing the "mjg59 sucks" song
<thom> it's very repettitive
* lamont_r bitchslaps bob2
<Mithrandir> thom: where are you?
<bob2> lamont_r: eh?
<Kamion> fabbione: never mind, I'll just upload it, it's not like the installer works on ia64 yet anyway ;)
<lamont_r> bob2: or was that not a troll?
<mjg59> Keybuk: Hang on, shiny new crack coming right up
<Kamion> 22:22 -!- lamont_r [~lamont@213.151.107.243]  has quit ["Leaving"] 
<Kamion> 22:23 -!- lamont_r [~lamont@213.151.107.243]  has joined #ubuntu-devel
<Kamion> 22:25 < bob2> hm, woke up immediately
<Mithrandir> Kamion: you should be careful pimping for hardware like that.
<Treenaks> lamont_r: could you boost the power on those APs of yours? :)
<Kamion> Mithrandir: Mark keeps trying to fill my bedroom with computers even more than it already is
<Treenaks> lamont_r: I keep getting disconnects ;)
<Mithrandir> Kamion: get yourself a rack and tell him they need to be rackmountable and silent?
<mjg59> Keybuk: Grab www.codon.org.uk/~mjg59/tmp/vbestate and do FOO=`vbestate save`; vm86_video_post; echo $FOO | vbestate restore
<Treenaks> tie him to the rack!
<Treenaks> oh wait.. other rack
<lamont_r> Treenaks: what I need to do is get back in the main room
<lamont_r> and move things
<Kamion> Mithrandir: unfortunately none of my machines so far are such, so I still lose a big load of space :(
<mjg59> I don't think he had time to test that...
<Treenaks> you can go there.. it's dark.. but it's open
<thom> Mithrandir: hacking room
<Keybuk> mjg59: can you repost?
<Keybuk> I got attacked by your hibernate script
<mjg59> Keybuk: Grab www.codon.org.uk/~mjg59/tmp/vbestate and do FOO=`vbestate save`; vm86_video_post; echo $FOO | vbestate restore
<mjg59> Keybuk: Except, don't just yet. Give me a minute.
<Keybuk> the only affect of which is to unmount /proc and cause gnome to have a seisure
<Mithrandir> is the usb brokenness in 2.6.9 fixed in hoary?
<Treenaks> Mithrandir: ish
<mjg59> Mithrandir: Yeah
<Treenaks> mjg59: I'll test my if my suspend/resume cycle stuff is fixed tomorrow
<mjg59> Treenaks: rock
<Keybuk> mjg59: out of X?
<mjg59> Keybuk: Console. Really console. But give me a minute or two more.
<Treenaks> hm.. I have one dead green pixel (lighting up at like 50% all the time)
<Treenaks> but it's in the middle of the face of the calendar girl
<Keybuk> maybe she just has a zit
<Keybuk> as well as being cross-eyed?
<thom> and having her nipples cut
<Treenaks> Keybuk: a green one?
<Treenaks> Keybuk: that'd just be scary
* Mithrandir ponders sleep($((3600*8)))-ing
<Treenaks> Mithrandir: why not just do an alarm($((3600*8)))
<Kamion> bah, no mdz
<|trey|> Hey, sorry to bother here... would it be user error that I am getting default GNOME menu's in hoary? Just finished fresh install and upgrade... "saved session" once, but thats never resulted in this before  :(
<Mithrandir> Treenaks: well, that too.
<Treenaks> |trey|: it's known and will be fixed soon
<|trey|> Treenaks, alright, thanks  :)
<Treenaks> Mithrandir: mixing sleep() and alarm() is Bad
<Kamion> Mithrandir: nice mix of C and shell syntax there
* Kamion wonders if Mithrandir is a secret csh user
<Keybuk> Kamion: he's probably a csh freak
<Keybuk> heh
* Keybuk caught daniels doing cshisms the other day
<Treenaks> *shudder*
<Mithrandir> Kamion: zsh, zsh
<Kamion> bless you
<Mithrandir> thom: where have you got your BT crack from?
<thom> Mithrandir: BT?
<Mithrandir> bluetooth
<Mithrandir> you had something in your menus, iirc
<thom> ahr, jdub's bluetooth repo
<Treenaks> bittorrent over bluetooth!
<Mithrandir> apt line?
* Mithrandir knocks Treenaks out
<thom> #deb http://people.ubuntu.com/~jdub/warty/ ./
<Mithrandir> thx
<Treenaks> what's a good python+dbus example?
* mjg59 struggles to work out what the difference between his code and the working code is...
<thom> Treenaks: hal has some python apps
<Treenaks> thom: I can fnd only one
<Treenaks> yikes.. this is easier than I thought
<bob2> lamont_r: was talking about my laptop, foo'!
<bob2> mjg59: after unloading ehci_hcd, no more problem
<mjg59> Grr. I really don't understand this.
<mjg59> bob2: Really? Weird.
<mjg59> Ok, possibly we should unload those, then.
<mjg59> The USB suspend/resume still seems a touch dodgy
<mjg59> But it works here. Oh well.
<bob2> yeah, it worked sometimes before
<bob2> but just now it was saying this:
<bob2> Could not suspend device 0000:00:1d.7: error -5
<bob2> which according to lspci is the ehci controller thing
<mjg59> Hm
<mjg59> 2.6.9 or 2.6.8?
<bob2> 2.6.8.1-3-686
#ubuntu-devel 2005-12-19
<MacFergus> ?
<Kamion> jcole: we've never supported Ubuntu floppy installs because we've never managed to make them fit
<Kamion> jcole: I believe some people have got them to work using Smart Boot Manager
<Kamion> (and chaining to a CD install, though - dunno if it's possible with no CD-ROM at all, whether you can e.g. boot from a netboot image somewhere)
<jcole> Kamion: oh ok... it doesn't have to fit on just one floppy... it could be 10 floppies, lol... as long as i can get ubuntu on it through the floppy drive (and ethernet connection)
<Kamion> yeah, I know, but when the kernel doesn't fit on a floppy it just gets tedious
<Kamion> ah, it does actually fit, it was probably another problem
<Kamion> at any rate I could not make even the boot floppy fit
<jcole> Kamion: ah, ic... how does redhat/fedora do it?
<Simira> are there any easy way to remove a lot of duplicate files in a directory?
<jcole> Kamion: i've got fedora on it right now
<mdke_> Simira, #ubuntu might know
<Nafallo> elmo: please sync php4-mcrypt php4-ps from debian unstable (ubuntu override okey), thanks :-)
<Nafallo> Simira: Mithrandir might know :-)
<Nafallo> (or should) ;-)
<Simira> Nafallo : he's out beering with a friend. I am all alone tonight.
<Nafallo> Simira: hehe, call him then? don't take his word on rm -f * though :-P
<Simira> :p
<jcole> Kamion: i created a "Kickstart" floppy with their gui software
<dholbach> good night everybody
<Simira> Nafallo : he won't be any good now, anyway. I just did it manually. For some reason, my mail setup failed to sort out my mail, and downloaded everything from one of my accounts
<Simira> and I just realized I probably got all the lists as well... #%!#&"
<Nafallo> Simira: oh, sounds like joy :-)
<Nafallo> dholbach: gnight :-)
<\sh> jcole: doesn't download the kickstart floppy all stuff from the net?
<Kamion> jcole: I thought their floppy install used a rather older kernel
<Kamion> like, 2.4 only or something
<Kamion> I'm familiar with kickstart (implemented it for our installer) but that's somewhat orthogonal
<jcole> \sh Kamion: i used this ---> http://fedora.redhat.com/projects/config-tools/redhat-config-kickstart.html
<Kamion> yes, I'm familiar with it, it's irrelevant to floppy support
<Kamion> I'll give floppy d-i builds another go at some point, see if I can make them work
<ogra> you could do a netboot install 
<Kamion> Fedora use a totally different installer so techniques tend not to be easily portable
<ogra> (with a PXE etherboot floppy from rom-o-matic.net if your NIC doesnt support netbooting)
<seb128> Kamion: is there still some GNOME issue for the CD?
<Kamion> that tactic can work too if you have a handy server you can make be a TFTP/DHCP server
<jcole> ogra: that's an idea
<Kamion> seb128: http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html still lists brokenness
<seb128> Kamion: evolution has built, evolution-exchange needs a retry when it's available, nautilus-cd-burner Depends on cdrdao which has been accepted for promotion according to pitti's comment on the wiki page I guess somebody should promote it, nautilus-sendto ditto with gnome-bluetooth
<Kamion> seb128: I've just given-back evolution-exchange, which should help a bit
<Kamion> ok, I'll have a look through the promotion queue, thanks
<seb128> np
<Kamion> Mithrandir: here?
<Kamion> Mithrandir: your casper upload was rejected due to distribution=unstable
<Simira> Kamion : he's out beering
<Kamion> Simira: hopefully he won't mind if I fix it and upload for him, then
<Simira> Kamion : I guess not
* Kamion fishes it out of queue/reject/
<jcole> Kamion ogra: thanks, i'm going to attempt the PXE boot solution... have a good day
<ogra> jcole, good luck :)
<lucas> somebody familiar with libapt-pkg ?
<lucas> my problem: does it allow to select which "cache" an application wants to use ?
<lucas> I'd like to do what apt-rdepends do one a Packages file I just download manually, for example Debian's one.
<lucas> s/one a Packages file/on a Packages file/
* lucas would prefer to avoid having to understand the whole apt source code ;)
<Nafallo> elmo: please sync linuxdcpp from debian unstable (ubuntu override okey), thanks :-)
<Kamion> lucas: apt supports various configuration options to change where it gets files, including that sort of thing (you'd have to construct a temporary sources.list, point it at that with a temporary cache, and update); see apt.conf(5)
<lucas> yup, that's what I was reading
<lucas> what's your opinion about python-apt ?
<lucas> does it include everything apt supports ?
<lucas> or should I go directly with C++ ?
<Kamion> I don't have an "opinion" about it; I use it from time to time, seems fine
<lucas> ok
<Kamion> it's probably a hell of a lot easier than using C++
<Kamion> the apt_pkg module is closer to the C++ interface, but less pythonic
<Kamion> there's a new apt module in recent python-apt which I'm told is more pythonic, but I've never used that
<lucas> the apt module seems very far from being complete
<ogra> lucas, but what you try to do sounds a bit like what gdebi does already ...
<lucas> ogra: mmh, not sure
<ogra> probably wotrh a look at its source ...
<lucas> ogra: can you explain ?
<ogra> its the one click deb installer from mvo ...
<lucas> ah, it uses python-apt
<ogra> http://people.ubuntu.com/~mvo/bzr/gdebi--main/
<lucas> there are a lot of examples provided with python-apt, but none of them covers changing the configuration to download the pkg lists elsewhere, etc
<doko> infinity, lamont-away: please requeue gjdoc (on all archs)
<lucas> ah ah, very cool
<lucas> using the -o option of apt-*, it's very easy to fetch & debian's apt files on ubuntu
<slomo_> infinity, lamont-away: please give-back evolution-sharp, thanks :)
<johnl> hey, I tested the new 2.6.15 kernel on my breezy box
<johnl> opened a pandoras box of shit
<johnl> it's not so much the kernel, which worked on one box, it's more about trying to go back to the old breezy kernel
<mdke> jdub, what is the status with planet ubuntu and synching?
<BenC> johnl: old kernel should work as long as you don't update the old initrd with new udev
<johnl> firmware won't load now for my ipw2200, /dev/input missing, synaptics driver not working
<BenC> well, then there's that too
<BenC> yeah, there's not much for partial upgrades at this point
<BenC> you go, or you don't, there's no middle :)
<mdke> GO!
<johnl> doh.
<mdke> dude, you're testing dapper: this is no holding back time
<BenC> new udev, minus hotplug, just isn't breezy friendly
<johnl> thing is, now I've completely moved back to breezy, downgraded back to breezy packages and it's still dead
<johnl> reinstall hotplug (I noticed the new udev is doing that now)
<BenC> install hotplug
<johnl> I mean, I have done :)
<BenC> sorry, we don't support downgrading :)
<johnl> and dpkg-reconfigure'd the kernel image
<johnl> ok, fair enough
<BenC> oh, that was a bad idea
<johnl> tbh, I've got a pretty good handle on how all this usually works, but I'm stumped on this
<johnl> just wonder if I've run into other, as yet undiscovered problems
<johnl> I know this isn't #ubuntu :)
<johnl> sorry
<mdke> johnl, i guess #ubuntu, forums or a reinstall are the best options
<Nafallo> infinity, lamont-away: ping
<johnl> ok, thanks anyway guys :(
<Kamion> installing with dpkg --force-confmiss might help, there's a lot of stuff in /etc
<BenC> yeah, especially hotplug
<johnl> Kamion: ah yeah, that might explain the missing hotplug init scripts :)
<johnl> cool, I'll give that a go on them all
<johnl> nice one
<Nafallo> anywhere I can see if a package is in p-a-s?
<johnl> on hotplug I used dpkg --unpack, and manually mv'ed the initscripts back into place, hehe
<Kamion> argh
<Kamion> don't do that
<Kamion> at least use dpkg --configure afterwards if you do
<johnl> didn't know about force-confmiss
<johnl> ah, I just apt-get install --reinstalled after :)
<johnl> ok, I'm on it now.  ta
<Nafallo> infinity, lamont-away: unping
<Kamion> ok, {ubuntu,edubuntu}-desktop should be installable again in about half an hour
<ogra> yay
<daniels> Kamion: anything I can do to be useful today?
<ogra> daniels, fix the trident driver ? 
<ogra> daniels, btw,nv works fine for thin clients, it seems to be driver specific
<Nafallo> daniels: rebuild openal to get rid of libsmpeg0c2? ;-)
<Kamion> daniels: xserver-xorg-driver-via FTBFS which I suspect is what's breaking my test laptop (#20191)
<Kamion> daniels: I'll fix that one if you like since I've got the hardware here
<ogra> daniels, aother thing i (and mdz as well) would really apreciate (not today though) would be if you could take a look at http://people.ubuntu.com/~ogra/bzr-archive/ltsp/fixes/debian/ltsp-client.ltsp-client-setup.init and tell us what can and wat cant work at all from the debconf preseeding we do for xorg ...
<ogra> seems the majority of options is ignored ... :/
<Kamion> daniels: GL/glxint.h includes GL/gl.h; would the best way to fix the via FTBFS be to make x11proto-gl-dev depend on mesa-common-dev?
<Kamion> hm, or possibly mesa-common-dev | libgl1-dev
<daniels> ogra: what's wrong with trident, again?
<ogra> daniels, i filed you a bug some days ago ...
<daniels> Kamion: needs a dep on libgl1-mesa-dev | libgl1-dev
<ogra> havent gotten around to debug more yet ... 
<daniels> Kamion: m-c-d isn't a libgl1-dev alternative
<Kamion> ok - it's what provides GL/gl.h which is why I mentioned it
<ogra> its not important for life, Kamion has priority in any case here
<daniels> Kamion: want me to do that now?
<daniels> Kamion: (or you can if you like)
<Kamion> daniels: yeah, if you would
<daniels> Kamion: coming right up
<daniels> uploaded
<daniels> Kamion: anything else? :)
<Kamion> daniels: oh, why in via rather than in the package containing the include file?
<Kamion> that's all I have for now since my test laptop works once I build that package for it
<daniels> ogra: 20563> without a backtrace, there's really nothing at all I can do
<daniels> Kamion: mumble build loops mumble depends wrong way up the chain mumble handave mumble
<Kamion> heh
<daniels> 'handwave', even
<Kamion> oh, right, forgot that mesa build-depended on x11proto-gl-dev
<Kamion> lucky I didn't try to fix it :)
<daniels> heh
<Kamion> daniels: anastacia wants to demote xdmx-tools and xserver-xorg-input-magictouch; should they be seeded or demoted?
<daniels> Kamion: demote and seed respectively
<daniels> actually probably seed both
<Kamion> I just demoted xdmx-tools after noting that xdmx was in universe
<Kamion> I can put it back
<daniels> oh
<daniels> if xdmx is in universe, then -tools should be too
<Kamion> well, it's in universe because it isn't seeded :)
<Kamion> I personally don't care either way
<Kamion> hmm, none of the other xserver-xorg-* are seeded
<daniels> demote it for now, I'll deal with it later
<Kamion> perhaps this one should be added as a dependency somewhere
<Kamion> demote> done
<daniels> hm, if anastacia wants to kick it out, then I'd imagine it needs to be a dependency of xserer-xorg
<daniels> i'll fix that when I get around to making the first xorg upload for dapper
<Kamion> that would do, thanks
<Kamion> no rush
<Nafallo> daniels: didn't you upload that first thing when dapper was opened? ;-)
<daniels> Nafallo: the 'xorg' source package has never been uploaded to dapper
<daniels> right now, it still wants to build the entire monolith
<daniels> Kamion: ta
<Nafallo> daniels: ah, oki :-)
<daniels> luckily either our configuration infrastructure isn't screwed, or people aren't complaining about it being screwed
<Nafallo> hehe
<johnl> gah, fixed it.  after all that, it was just symlinks missing in /etc/udev/rules.d
<johnl> no amount of reinstalling udev or hotplug packages caused those to be recreated.  strangely
<johnl> not even udev.rules was symlinked.
<johnl> nnight folks.  thanks again
<Nafallo> elmo: please sync php4-interbase from debian unstable (ubuntu override okey), thanks :-)
<elmo> Kamion: ?
<Kamion> elmo: yo
<elmo> Kamion: I realise you probably care about most anything else right now, but fyi little hit red line on disk space.  however, don't delete stuff you don't want to, put it (or a list of it) somewhere for m e and I'll rsync it to the storage array of death
<elmo> (s/don't/when you do get round to fixing it - no rush -, \&/) - typing while swapping sucks
<Kamion> elmo: ~cjwatson/old-images would be perfect to archive off any time you're ready
<Kamion> 86296548        old-images/
<elmo> \sh_away: the problem with istanbul is that the orig.tar.gz's in debian and ubuntu don't match
<Kamion> I've been keeping stuff there for a while
<elmo> ok, syncing
<BenC> anyone using 2.6.15 kernel from dapper and ata_piix module?
<elmo> kamion: er, tho that'll do amusing things to little's IO - lemme know if that is/becomes a problem
<Kamion> elmo: hmm, ok, probably all right for now
<crimsun> BenC: lsmod seems to say that here
<crimsun> BenC: (presuming you mean 2.6.15-8.10)
<BenC> yeah
<BenC> it's working for you with drives then?
<crimsun> BenC: yep
<BenC> any messages in kern.log?
<crimsun> anything in particular I should grep for?
<BenC> if it's not full of ataX messages, then it's good :)
<infinity> BenC : I am, but I haven't upgraded the laptop to -8.10 yet.  Let me do that now.
<crimsun> BenC: only the one (for this x41-2527) on boot for "ata1: dev 0 configured for UDMA/100"
<Kamion> elmo: little's mirror-updating ssh to mirnyy hangs
<Kamion> magellanic doesn't seem startlingly fast to respond either
<Kamion> although gets there in the end, sometimes
<bmonty> elmo: thanks for processing my sync requests from the other night, but i think you might have missed bayonne
<Kamion> elmo: taking mirnyy out of the list for now, unless you shout and tell me it's vital
<Kamion> iirc it's just releases which isn't getting modified at the moment
<elmo> Kamion: mirnyy's out of rotation anyways - knock yourself out
<elmo> is flight-2 due to be released tonight?
<elmo> if so, oh dear, our ISP are going to cry
<Kamion> elmo: probably tomorrow morning rather than me actually killing myself. What's wrong with our ISP?
<maswan> http://ftp.acc.umu.se/mirror/cdimage.ubuntu.com/
<elmo>    bayonne |   1.2.15-1 | dapper/universe | source, i386, powerpc, sparc
<maswan> that's mirrored daily, only release-like directories though
<maswan> btw, what kernel is flight-2 based on?
<Kamion> maswan: if I can get a special trigger at a time roughly of my choosing tomorrow, I can link to that from the announcement
<Kamion> maswan: 2.6.15-8.10
<maswan> Kamion: sure, at least if I'm awake. :)
<maswan> Kamion: awesome, then I'll have to try an install. I have hardware that doesn't find the sata on <2.6.15
<Kamion> maswan: ta
<bmonty> elmo: oops, sorry...I must have missed the ACCEPTED email
<elmo> infinity/lamont: ?
<infinity> elmo : Yes?
<infinity> elmo : king drive space?
<infinity> (and weddell, looks like)
<infinity> I'll tidy.
<elmo> infinity: cute
<infinity> elmo : What's your yellow/redline on the livefs hosts? (king, weddell, royal, terranova)
<elmo> infinity: /etc/nagios/nrpe.cfg
<elmo> they haven't been well customized, some of them, esp. on non .5Tb hosts may not be especially suitable
<infinity> Yeah.  Only terranova is .5TB.
<infinity> Would have been nice if the other three were too, but oh well.
<infinity> Alternately, perhaps I should archive all livefs images to terranova, or something equally silly.
<elmo> most of them could have more if they need it, tho king would need a better machine to fit more disk
<stub> launchpad will be going down in 10 mins, which will also put the wiki's into read only mode. Estimated down time is 45 mins.
<daniels> hm, where's seb128 when you need him
<daniels> my panel just hung
<Kamion> please test http://cdimage.ubuntu.com/daily/current/ and http://cdimage.ubuntu.com/daily-live/current/ and report any failures to me, either here, in /msg, or by e-mail (cjwatson@ubuntu.com)
<Kamion> bonus points for causing safe, correct, and obvious fixes for said failures to be uploaded
<elmo> now you're just being greedy
<Kamion> powerpc live isn't there yet, but will be in under half an hour (it was bitten by a stupid build failure, rebuilding)
<mgalvin> already downloaded, burning cd now... :)
<Kamion> huh, no, don't bother with live I think I broke it; fixing
<mgalvin> i only grabbed the installer cd anyway
<Kamion> that should be fine
<Kamion> ok, better, try live CDs in about half an hour from now
<Kamion> I'm going to crash 'cos 18-hour days suck
<fabbione> morning
<calc_> shouldn't file roller appear in alacarte to be able to be reenabled?
<calc_> its not showing up for me, but nautilus does, not sure why though
<calc_> i mean nautilus shows in alacarte with the check box empty allowing you to enable it if you want it back
<dream> hi , anyone ?
<dream> anyone here?
<dream> anyone can help me ? : ( .
<desrt> ?
<dream> hi desrt
<desrt> hello dream
<dream> i have a question, would like to help me ? : ) /
<desrt> do you have a question?
<dream> yes
<desrt> have you read the topic?
<dream> topic?
<dream> what topic? 
<desrt> the channel topic.  what is your question?
<dream> oh
<dream> i wanna know in ubuntu installation CD, which script can detect my scsi device
<dream> and modprobe it ? .
<desrt> you're better off asking in #ubuntu
<desrt> it's more active with people who can help you
<calc_> jdub: liked your take on the interesting thread today :)
<calc_> jdub: at least in what you said in your reply to dave on the blog
<dream> oh , but someone suggest me ask question here : ( .
<dream> i wanna know in ubuntu installation CD, which script can detect my scsi device and modprobe it , where is the script in initrd of ubuntu installation CD? : ) .
<calc_> dream: look at it?
<dream> can you help me ? desrt
<calc_> its fairly trivial to load a correct module for a pci device
<calc_> i used to have one line of bash that did it
<elmo> what modules should I see for a BCM4318 (AirForce One 54G) wirless card?
<dream> calc_ but i wanna to develop a linux installation CD , so i wanna know 
<calc_> elmo: there are new open source drivers for them
<fabbione> dream: you have been answered already 2 times.
<calc_> elmo: otherwise you need to use the ndiswrapper stuff
<dream> so i wanna know  where is the script in initrd of ubuntu installation CD? : ) .
<fabbione> dream: please stop spamming this channel
<elmo> calc: ok, thanks
<dream> fabbione sorry : ) .
<calc_> elmo: aiui 2.6.15 may already have the broadcom driver
<elmo> bugger - I wonder if I even have a cat 5 anymore
<fabbione> elmo: we already have it in dapper, but i didn't get it to work on ppc yet.
<calc_> i yanked mine during the non supported time and installed an intel 2915abg :)
<elmo> fabbione: hmm, this is on an x86 laptop
<elmo> actually it's an amd64 laptop but I downloaded the wrong CD
<elmo> <-- winn0r
<fabbione> elmo: oh ok.. than it should do
<calc_> elmo: same here
<elmo> fabbione: yeah, but not in the installer right?  I mean I don't have the windows drivers :)
<calc_> i need to put my old nic back in and see how it works soon
<fabbione> no, it's not in the installer
<fabbione> elmo: and it's not the windrv
<elmo> fabbione: .. for ndis?
<elmo> oh, you mean the new one
<fabbione> i am talking about the free driver
<elmo> don't mind me, it's late here
<fabbione> i don't.. it's damn early here
<fabbione> if it is for your use only, you need dapper...
<fabbione> and be aware that's not exactly stable
<elmo> fabbione: this is dapper, pre-test of flight-2
<elmo> so should be latest kernel
<fabbione> ok
<fabbione> bcm43xx.ko <- the winner
<fabbione> it will mostlikely ask for the firmware
<elmo> hmm, "module bcm43xx not found"
* fabbione scratches his head
<fabbione> lib/modules/2.6.15-8-amd64-k8/kernel/drivers/net/wireless/bcm43xx$ 
<mgalvin> ok, so the 14.1 iso still does not detect the hard drives on my laptop 
<mgalvin> fabbione: that mini iso was able but this flight 2 candidate does not
<fabbione> mgalvin: meh... sorry i can't remember the details..
<fabbione> elmo: if you have the normal kernel, it's there...
<mgalvin> qosmio g25 laptop w/ sata raid, hard drives do not get detected
<fabbione> ok, how did we solve it?
<mgalvin> you had send me a link to a mini.iso that was able to detect them
<mgalvin> s/send/sent/
<fabbione> that was the netinstall from archive
<fabbione> wasn't it?
<mgalvin> http://archive.ubuntu.com/ubuntu/dists/dapper/main/installer-i386/current/images/netboot/
<fabbione> yes
<fabbione> can you try that one again?
<fabbione> it has been updated
<fabbione> so don't trash the old one
<yi> daniels: when can we get to play with xorg 7.0 rc3? :)
<mgalvin> ok, give me a sec to try it again, gotta run in a few min though
<mojo> daniels: ya, I am looking forward to it 2
<mojo> ubuntu documentation team forgot to put in details on 'About this Document' for About Ubuntu entry again
<mojo> it doesn't make much sense to have Epiphany relies on Firefox. Can't we come up with better package solution?
<mgalvin> fabbione: that new mino iso DOES find them
<mgalvin> sorry gotta run for now, later
<elmo> fabbione: fyi, I get "Invalid PHY Revision 7" trying the modprobe from the installed system
<fabbione> that's normal
<fabbione> ignore it
<fabbione> actually.. mjg59 gave me a hint to make that thing working. let me find it somewhere
<fabbione> elmo: Dec 06 17:56:09 mjg59   iwconfig foo essid bar; iwconfig foo channel baz; ifconfig foo up; iwlist scan; iwconfig foo essid bang
<fabbione> you might need to tickle the driver that way to make it working
<fabbione> also.. force it to 11Mb
<elmo> ah, ok, will play later, thanks - atm, still trying to get X :)
<fabbione> iwconfig foo rate 11M
<fabbione> no problem
<jsgotangco> haha heavy metal for human beings
<Aegir> Quick Q, is Dapper still using 2.6.15.7? I had to revert to 2.6.15.6 after some rather funky HDD errors (I thought my laptops hdd was getting shonky).
<infinity> 2.6.15-8 now.
<dholbach> good morning developers
<Aegir> infinity: Righto, thanks for that. I would check myself, but apt-get is held at the moment.
<infinity> dholbach : New gnome-terminal loves me.
<dholbach> ROCK!
<infinity> dholbach : Thanks, dude.
* dholbach hugs infinity
<pitti> Good morning
<dholbach> pitti: you happy too with gnome-terminal? :)
<dholbach> and then i only need to ask jbailey, if he's happy
<infinity> You might want to phrase it differently, or you're likely to get a sarcastic response like "I've never been happy..."
<infinity> Well, you would have if you'd asked ME that. :)
<dholbach> infinity: i'm to optimistic for that :)
<dholbach> s/to/too
<infinity> I've noticed.
<dholbach> haha :)
* infinity runs out to get some lemon-flavoured rocket fuel to power him through the evening.
<pitti> dholbach: yes, it works again, thanks!
* pitti hugs dholbach 
<StevenK> infinity: Does said rocket fuel have a name?
<infinity> StevenK : SOLO!
<StevenK> Oh, evil.
<dholbach> the funny thing about the fix is: the guy whose patch i reverted complained, that suddenly ubuntu's gnome-terminal had gone weird ;)
<StevenK> infinity: You're better off shooting up with sugar.
<infinity> Sucks to be him.
<infinity> Who says I'm not?
<StevenK> infinity: But ... Solo tastes like, well, crap.
<daniels> yi: it's broken as shit
<daniels> yi: server appears to be totally dead
<daniels> yi: but definitely not until after flight 2
<dholbach> daniels: did you hear anything weird about xdamage/xfixes in the last time?
<dholbach> daniels: i tried to build gnome-mag with xfixes/xdamage support. on breezy it worked nicely and on dapper it painted the whole part of the "magnified screen" grey :)
<daniels> dholbach: cool :) could be the fbCompositeGeneral breakage, since that seems to be pretty world-ending for most things really
<dholbach> oh i see. will you give the signal, when i should try it again? :)
<daniels> yeah, will do
<dholbach> merci beaucoup
<daniels> np
<pitti> Kamion: thanks for the analysis of the gfxboot issue
<pitti> Kamion: when you arrive, can we have a quick discussion about that cupsys-driver-gimpprint failure?
<elmo> pitti: Kamion went to bed at like 3 or 4 am, I doubt he'll be up anytime soon
<pitti> uh, ok; thanks
<Mithrandir> elmo: he was active on -boot 30 minutes ago.  Have to drive Kirsten etc, but he'll be back afterwards.
<Mithrandir> he might be mostly interested in getting flight out today, though.
<pitti> right, and that cupsys issue breaks livecd builds
<pitti> that's why I want to solve it today
<infinity> pitti : No, it doesn't break the builds.  I did a few uploads to fix that...
<infinity> But it doesn't make cupsys any less broken.
<pitti> infinity: fix the -driver-gimpprint issue?
<pitti> infinity: I just saw that you use invoke-rc.d now
<pitti> but does that make a difference?
<infinity> Yes.  It was breaking livefs builds, so I uploaded fixes for both gimp-print and cupsys, IIRC.
<infinity> (different fixes)
<infinity> Oh, right, the cupsys fix was just a linking issue, so gimp-print could build.
<infinity> Anyhow, invoke-rc.d fixes the livefs build, because we divert invoke-rc.d during the build (and invoke-rc.d is just The Right Thing To Do anyway)
<infinity> But obviously cupsys segfaulting is still Very Bad.
<pitti> I see
<pitti> oh, it segfaults?
<infinity> Or something.
<pitti> that wasn't obvious from the install log
<infinity> I forget.
<pitti>  * Restarting Common Unix Printing System: cupsd
<pitti> cupsd: Child exited on signal 15!
<pitti> dpkg: error processing cupsys-driver-gimpprint (--configure):
<StevenK> Whee, SIGTERM
<infinity> Oh, right.  Not a segv.
<pitti> infinity: I'm looking for the cause of that, but I can't reproduce it in a chroot
<infinity> It's TERMing itself.
<pitti> well, you force-reload it, so what else should it do?
<infinity> pitti : I could reproduce it sometimes, not at others.  I'll see if I can come up with a recpie.
<pitti> I tried in a current clean dapper with and without locales, but only amd64 so far
<infinity> Oh, looking at that also exposed another cupsys evil, IIRC... I think it's one of those nasty packages that, during upgrade, tries to kill EVERY cupsd it can find, including ones outside the chroot.
<pitti> bah, mvo, apt-get source sucks; it keeps downloading orig.tar.gzs that I already have... :(
<pitti> infinity: it does that as a last resort, when the daemon does not want to die
<pitti> I'll look into it
<infinity> "as a last resport" meaning "any time it sees processes still running"?
<infinity> Cause it killed my base system cupsd every single time.
<StevenK> infinity: "Feature"
<pitti> yes, seems so
* pitti will fix that
<infinity> A pidfile would be good there. :)
<pitti> ... and now that I have commit access to debian, I'll fix it there, too :)
<infinity> Compare running cupsd with pidfile, don't kill it if they don't match.
<infinity> (or complex walking around in /proc, if you're so inclined)
<pitti> infinity: well, that won't tell apart processes in and outside of the chroot, right?
<Kamion> pitti: it didn't break the last install CD test I tried so I'm ignoring it
<infinity> Somewhere in /proc/<pid>/*, there's some clever way to compare your current root with the process root or something.  I forget how.
<pitti> ok, great
<infinity> (I just use pid file comparisons, and call it "good enough")
<StevenK> steven@broken:~% sudo readlink /proc/1/root
<StevenK>  /
<pitti> infinity: right
<StevenK> Damn IRC, eating my slash.
<Kamion> Riddell: Kubuntu install CDs ready for you to test
<Kamion> ogra: Edubuntu install CDs ready for you to test
<pitti> Kamion: I fixed the language-support packages for the removed/new firefox locale packages; this should make the three suport packages mentioned in dapper_probs installable again
<pitti> Kamion: however, there are also some new ffox locales which require promotion love
<Kamion> ok, will check
<pitti> (I just uploaded them, will take a while)
<pitti> anything else that immediately breaks flight 2?
<pitti> Riddell: could you please fix kde-i18n-hsb to depend on kdelibs4c2a instead of c2?
<Kamion> pitti: dunno yet, I've had exactly one test report
<Kamion> elmo: hmm, was that definitely a current image? I could have sworn I'd fixed the localechooser thing
<Kamion> (and the fix worked for me elsewhere)
<elmo> Kamion: it was daily/current/ from cdimage
<Kamion> elmo: could you make installer/syslog world-readable?
<pitti> Kamion: oh, is it on purpose that the daily/current symlink is out of date?
<elmo> Kamion: done
<Kamion> pitti: MEH
<pitti> hm, works now, must have been a proxy problem; sorry
<Kamion> ah, no, it indeed isn't out of date
<pitti> jigdo didn't upload anything new
<Kamion> don't scare me like that :)
<pitti> Kamion: reloading in the browser did help; bloody proxy of my provider...; sorry again
<Kamion> elmo: can you boot that image again quickly and tell me which version of localechooser is in /var/lib/dpkg/status?
<Kamion> elmo: actually, don't bother, it's logged
<Kamion> 0.22ubuntu2, hmm, that's broken
<Kamion> elmo: current image has 0.22ubuntu4; what's the md5sum of the image you've got?
<Kamion> 0d9e641668e2235741b73645495fe1f4  dapper-install-i386.iso
<Kamion> ^-- current
<elmo> 87253debf01d9c2dae765b7bf7fb8403  dapper-install-i386.iso
<elmo> I got daily/current, I swear :P
<Kamion> that's the md5sum for 20051213.2
<Kamion> could be that daily/current *was* OOD for a while, if so probably until 4:00 UTC
<pitti> . o O {odd, that's the same version my daily/current pointed to this morning}
<Kamion> maybe an OOD mirror
<Kamion> ?
<Kamion> the daily/current timestamp on little is dated 4:00
<elmo> I probably hit mirnyy
<elmo> blah
<elmo> can you trigger mirnyy?
<elmo> I was wrong about it being out of rotation
<Kamion> done
<Kamion> and put back in sync-mirrors now that it seems to work
<pitti> infinity: I think I sanitized cupsys; do you want to look at the diff? http://paste.ubuntu-nl.org/5746
<mvo> Kamion: I'm just testing the current live-cd. very nice splah. is there a way to clean the screen before going to "boot from first harddisk"? it's a bit messed right now
<Kamion> mvo: I fixed that yesterday; I think you might have an old image ...
<Kamion> check whether you were bitten by the above mirror problem
<mvo> I have 20051214.1 
<Kamion> hmm, odd
<mvo> but it stops with a kernel panice "can't open /scripts/casper"
<Kamion> can you describe how it looks after you select that option?
<Kamion> yeah, that one's known, infinity's regenerating the filesystems
<Kamion> (live CDs are unfortunately b0rked b0rked b0rked at the moment)
<Kamion> amd64 rescue mode broken, gfxboot-theme-ubuntu bug, fixing
<mvo> ok, no problem. here is what it looks like: green font, in the background I still see "F2 Languages, F3 Other Options, .." and parts of the menu
<Kamion> hmm, very odd, I definitely added code to syslinux to tear down gfxboot so that must not be working
<Kamion> which arch?
<mvo> i386
<mvo> it's a radeon 7500
<mvo> (not sure that this matters)
<Kamion> ok, could you file a bug on syslinux and I'll try to investigate?
<mvo> should I wait for the next image first just to be sure? 
<Kamion> nah, don't think that'll help
<mvo> ok, thanks
<Kamion> although you'll need the next image anyway to make it work at all, of course
<mvo> sure, just announce it in the channel (when it's ready), I'll pick it up then
<mvo> the gfx stuff is really awsome already
<Kamion> fixes to that level of it tend to require me to dust off my memory of x86 assembly
<mvo> yeah, looking at the code the gfx_done call should really be fine
<mvo> anyway, bug submited
<pitti> Hi Yagisan 
<Yagisan> G'day pitti
<Yagisan> anything interesting happening pitti ?
<pitti> flight 2 is not that far away any more
<Yagisan> nice. I saw that a modified version of my multi-arch patch for ltsp made it's way in via ogra :)
<janimo> package licensing question:
<janimo> as part of xubuntu-settings I am packaging ivman config files
<janimo> and gdm themes
<janimo> is it ok to GPL it?
<janimo> the gdm package with the other themes is under GPL
<janimo> ivman says code is QPL but says nothing of config files (bunch of XMLs)
<janimo> do licenses usually apply to configs too?
<janimo> thanks
<Kamion> if it's not yours then you need to ask the copyright holder before arbitrarily relicensing
<janimo> you mean the config files right?
<Kamion> yes
<janimo> as the gdm themes are GPL I suppose
<janimo> ok I'll ask
<Kamion> I'd generally assume that config files were under the same licence as the code, presuming that they're copyrightable at all, but that's not a legal opinion
<janimo> or I can just say in debian/license bith QPL and GPL?
<janimo> that would be easier, I do not want to relicense
<Kamion> if one isn't a derivative work of the other, then you can do that
<Kamion> i.e. if you're just aggregating two unrelated things in the one package, that's fine, just say so clearly
<janimo> ok so mentioning specifically which files are under whic hlicense
<janimo> thanks
<Kamion> but if the GPLed work depends on the QPLed work or vice versa then you have a problem
<Kamion> that's a loose opinion off the top of my head; checking with the copyright holders (or more legally-experienced people) is always safest if in doubt
<janimo> not the case here, just pick various configs and aggregate them under same package
<janimo> there are already too many xubuntu-* package
<janimo> and I'd rather not patch gdm/ivman packages
<DiabloD3> Hey all.
<DiabloD3> http://bugzilla.ubuntu.com/show_bug.cgi?id=20622
<Riddell> ops needed in #ubuntu
<Kamion> meh, the linux-image-k7 component shouldn't exist
* Kamion goes to reassign everything to linux and delete it
<pitti> bah, seems that we need more ops in #ubuntu
<Diziet> IRC op> Often a thankless job unless you're a small-minded control freak.
<azeem> or care for the community.
<Diziet> I'm afraid my devotion only stretches so far :-/.
<DiabloD3> kamion in what way?
<Kamion> DiabloD3: all kernel bugs belong on the 'linux' component
<Kamion> linux-image-k7 was the only linux-image-* component in existence, and was evidently created by accident
<DiabloD3> what about 686?
<Kamion> 'linux'
<DiabloD3> there is -386, -686, and -k7. There used to be -smp ones too.
<Kamion> no, there isn't
* Kamion <-- was looking at the full component list about a minute ago
<DiabloD3> linux-image-386 - Linux kernel image on 386.
<DiabloD3> linux-image-686 - Linux kernel image on PPro/Celeron/PII/PIII/PIV.
<Kamion> I'm talking about in Bugzilla here, not packages in the archive
<DiabloD3> linux-image-686-smp - Linux kernel image on PPro/Celeron/PII/PIII/PIV SMP.
<DiabloD3> linux-image-k7 - Linux kernel image on AMD K7.
<DiabloD3> linux-image-k7-smp - Linux kernel image on AMD K7 SMP.
<DiabloD3> oh.
<DiabloD3> then I agree, why does it have its own component?
<Kamion> it doesn't any more, that's what I said above
<DiabloD3> Ahh.
* ogra hugs Kamion for http://cdimage.ubuntu.com/edubuntu/daily-live/
<ogra> yippie :-D
<Kamion> won't work, mind
<Kamion> Adam's rebuilding the live filesystems to fix a bug, then I'll rebuild those
<Kamion> but you might as well download them so that later rsyncs are faster
<ogra> doesnt matter, i *have* one :) 
<ogra> finally there is something to point all the asking people to ... even if i have to tell them its broken :)
<Kamion> how're Edubuntu install CDs looking?
<Kamion> I'll be rebuilding */amd64 to pick up a gfxboot-theme-ubuntu fix, but the rest will stay as-is unless people report problems with them
<ogra> havent tested yet ... still writing them to disk, but first i hve to run our meeting
<ogra> i'll report back during te day ... 
<ogra> something is wrong with initramfs wrt nfsmounting ... so this wont be a good one anyway before i found that bug
<ogra> at least for the ltsp side ....
<ogra> the rest looked pretty good yesterday already, stage 1 finished fine and if the postgres/locale prob is gone now i think they are fine apart from the above ...
<Kamion> locale fix should be in
<ogra> yup, you told so ...
<ogra> the sad thing is that nearly noneof peres ltsp fixes work, seems mdz only eyeballed them but didnt test ... 
<ogra> our xorg doesnt accept as many debconf preseeding options as debians does ....
<doko> infinity: are you going to sync ppp?
<lifeless> win 10
<jbailey> dholbach: Give me a couple of hours and I'll let you know.
<infinity> doko :?
<infinity> doko : It's not in my bug list.
<infinity> doko : And I have no urge to do it either.  So, go nuts.
<doko> infinity: no, but you did the last sync
<Kamion> mvo: whoa, ok, I see the localboot thing now too
<infinity> Kamion : edubuntu/powerpc is clooping.
<Kamion> sheesh, I'm just jinxed here
<infinity> And if you don't like that verb, too bad.
<infinity> "undergoing cloopification" could work too, I guess.
<Kamion> I'm going to put "broken rescue mode on some images" in the errata; running around fixing it everywhere is going to eat into my vacation time
<infinity> Who needs rescue mode anyway?
<Kamion> hm, of course now it's broken in the live CD because we don't have d-i there any more
<Kamion> Whoops. I'll just de-support it there probably.
<infinity> How spiffy does rescue mode need to be?
<infinity> Cause I can do a pretty good rescue mode in initramfs.
<Kamion> compare with current rescue mode from an install CD
<Kamion> I'm not sure just dropping to a shell counts ...
<infinity> Filesystem tools, MD tools, a crappy text editor..?
<infinity> (To be honest, I'm not sure what else d-i's rescue offers, since my use cases for it have been limited)
<Kamion> it offers you a menu of root filesystems to mount, mounts it for you, and then gives you a menu of things you can do (nowadays including recipes for things like reinstalling the bootloader, at least on powerpc)
<infinity> Oh, right.  The New and improved rescue mode with the menu.
<infinity> That annoyed me, cause it took forever to get to any rescuing. :)
<Kamion> before rescue mode people could drop to alt-f2 and do all the things you could do in an initramfs
<Kamion> the whole point of rescue mode was to stop me having to give them the six-command sequence all the time
<Kamion> (or whatever it was)
<infinity> This could probably still be shoehorned in for the livefs initramfs somewhow.
<infinity> Smahe to have to rewrite the d-i menuing bit, but no big deal.
<Kamion> yeah
<Kamion> or it's still technically possible to include the d-i initrd
<Kamion> I'd just have to rename it
<Kamion> takes more space, but would do in the meantime
<infinity> For now, though, I see no real harm in releasing Flight-2 without Live-rescue.
<Nafallo> infinity: could you check what's up with linuxdcpp please? same error as last time.
<infinity> Nafallo : Was that the scons failure?
<Nafallo> infinity: yes
<infinity> Nafallo : If so, that's probably the "same me not fixing it yet" as last time.
* infinity fixes it.
<Nafallo> infinity: well, new version since this morning so that's why I nag again :-)
<Riddell> Kamion: kubuntu install CD works fine but live CD give a kernel panic with "can't open /scripts/casper"
<mvo> Riddell: it's a known issue
<Kamion> Riddell: actually just rebuilding Kubuntu live now
<DiabloD3> I'm happy kubuntu actually installs now
<DiabloD3> riddell finally finished his giant several-month long task
<Kamion> Riddell: grab 20051214.1, should be better
<Kamion> DiabloD3: Kubuntu breezy installed fine ...
<Nafallo> Kamion: time to test livecds? :-)
<Kamion> as did Kubuntu hoary, for that matter
<Kamion> Nafallo: yes please
<DiabloD3> Kamion: I meant on dapper.
<Riddell> Kamion: will do, thanks
* StevenK curses. A lot.
* StevenK missed the TB meeting.
<Nafallo> hmm. no seeders on the live amd64 torrent?
<infinity> Are you surprised?
<Nafallo> yes
<Nafallo> I thought the datacenter would initiate the seeds :-)
<Znarl> Nafallo : All the live CDs including AMD64 are well seeded presently.  Check for yourself http://torrent.ubuntu.com:6969/
<Nafallo> Znarl: which one is current? :-)
<Nafallo> hmm, seems I can't connect in that case :-/
<Kamion> I wish the tracker could tell you the canonical URL
<infinity> Nafallo : Argh, your build failure is pkg-config's fault.
* Nafallo runs gnome-btdownload from terminal and hope to get some output.
<Nafallo> infinity: oh?
<Kamion> ogra: Edubuntu live ready for testing
<\sh> Nafallo: btlaunchmanycurses . --max_upload_rate 20 thats what you need...and screen :)
<dholbach> jbailey: ok
<Nafallo> \sh: baah. I want our default things to work rather ;-)
<Nafallo> \sh: I have torrentflux on the server if I really have to go there :-P
<Nafallo> infact... I should go there aswell :-)
<\sh> Nafallo: torrentflux? isn't it php?
<Nafallo> \sh: yes
<Nafallo> \sh: you COULD rewrite it in python for me? ;-)
<\sh> Nafallo: why? bittorrent is in python :)
<rob^^^> hrmm...any thoughts on reorganizing the flight splash from "Install to the hard disk, Install to the hard disk (expert mode), OEM installation, Server installation, Server installation (expert mode), Rescue a broken system" to "Install to the hard disk, Rescue a broken system, Advanced Installation Options"
<Nafallo> \sh: launchpad to :-)
<rob^^^> but I assume thats slated for change yet again once Ubuntu Express finds its way in
<jbailey> dholbach: Hmm
<jbailey> ?
<dholbach> jbailey: you said i should give you some hours :)
<dholbach> which is fine by me :)
<jbailey> dholbach: Right, okay. =)
<jbailey> ALthough it hasn't died yet, which is encouraging. =)
<Kamion> rob^^^: hmm, I'm not sure about having too many "advanced options", "more advanced options", "guru options" kind of things in the boot screen
<Kamion> there's not much room to explain complicated interface features or for people to get used to them
<Kamion> I'd be happy to reorder the menu items if that would help
<rob^^^> Kamion: I ment mainly to just take the additional options and split them off into a submenu
<Kamion> UE has little to do with this
<Kamion> rob^^^: I know, but as I said ...
<Kamion> I think there's a real danger of submenu overload there - would like to keep the structure as simple as possible
<rob^^^> yeah
<rob^^^> I figured one would do it though
<rob^^^> just main and advanced
<Nafallo> Znarl: baah. can't connect to a seed, so I wget and seed instead ;-)
<Kamion> it may be possible to put a separator in there
<rob^^^> although I guess there are i18n issues?
<rob^^^> because 99% of users are interested in Desktop or Rescue
<Kamion> no i18n on any of this yet although there's provision for it
<rob^^^> and it slightly bothers me having a non-expert server mode just in principle ;)
<Kamion> it doesn't bother me because I know what expert mode means :)
<Kamion> and what server mode means, and how the two are wildly different
<Kamion> the most awkward issue with menu restructuring is that I don't want any of this to be encoded into the gfxboot theme
<Kamion> so I'm using the syntax defined by the syslinux "simple menu system"
<Kamion> so that it can all live in isolinux.cfg
<viviersf> ok guys
<Kamion> I'm happy to support things that can be defined within that syntax, within reason, but am a bit more cautious about going beyond that
<viviersf> ubuntu + scsi + harware raid ? does it work
<rob^^^> Right now there are 6 options on the screen, adding an advanced mode would split it into 3/4
<Kamion> rob^^^: my alternate suggestion with regard to expert mode is that I'd much rather have that be a toggle switch
<Riddell> Kamion: new kubuntu live fails with "no record for /block/ram0 in database" repeated lots then "unable to find CD-ROM containing /casper/filesystem.cloop"
<Kamion> accessible by a function key; that would be way preferable to a submenu
<Kamion> Mithrandir: help Riddell? :)
<Mithrandir> hmm
<Kamion> Riddell: what arch?
<Riddell> Kamion: i386
<Kamion> /casper/filesystem.cloop is on that CD
<rob^^^> {"Install to the hard disk", "Rescue a broken system", "Advanced"}, { "Server installation", "Install to the hard disk (expert mode)", "Server Installation (expert mode)", "OEM installation", "Back"}
<Mithrandir> Riddell: you get dropped to a shell, don't you?  if not, please add break=premount to the syslinux command line and tell me when you have a shell
<rob^^^> the second menu is kinda ugly but anyoen trying to do any of those things will have seen worse
<Riddell> Mithrandir: I do get dropped to a shell
<Kamion> would rather {"Install to the hard disk", "Server installation", "OEM installation", "Rescue a broken system"}, and F5 => Normal/Expert mode
<Mithrandir> Riddell: what does ls /sys/block give you?
<Kamion> four choices is hardly overload, especially when the first is obviously-named and the default
<rob^^^> That's definately better
<rob^^^> most people don't know what OEM means though
<Riddell> Mithrandir: hang on, I need to reboot back into the live CD
<rob^^^> if that is a problem or not, dunno
<Kamion> rob^^^: I honestly don't think server should be an advanced option, and while OEM arguably is, a submenu with one item on it seems a bit daft :)
<rob^^^> Kamion: I think hiding OEM unless advanced is on is a good option
<rob^^^> why are you doing OEM installs if you can't find the README ;)
<Kamion> but you skipped my point
<rob^^^> oh
<Kamion> a submenu with one item on it seems a bit daft
<rob^^^> yes that does, but it would have the additional affect of changing Desktop to Desktop expert
<rob^^^> etc
<Kamion> huh?
* Kamion doesn't understand
<rob^^^> Go back to your F5 normal/expert idea
<rob^^^> in addition to toggeling expert mode it could add advanced options (or advanced option) to the current menu but because there are existing items just adding one doesn't look dumb
<Kamion> hmm, I suppose that's possible but it feels counterintuitive to me, and you don't actually want to do OEM/expert
<Kamion> (trust me on this)
<Kamion> expert mode in the installer is not a good analogue for other installation modes
<Kamion> so the two should not be conflated
<Kamion> expert => append DEBCONF_PRIORITY=low to kernel parameters
<rob^^^> yeah, I'm just saying having F5 add those two to desktop & server and show the other option, don't actually run it in expert mode
<jsgotangco> alright so the AsianTour is now set
<Kamion> rob^^^: I've wanted to have expert mode be a toggle switch for ages, so honestly I'd rather have that
<rob^^^> well your the man ;)
<Kamion> I take your points, but I honestly think this'll be preferable
<rob^^^> understood, I'm not questioning you
<Kamion> we're going to run out of space along the bottom if we add *too* many function keys ... we still need to add keymap support
<sabdfl> Mithrandir: any idea when we can get to play with the new live cd stuff?
<Mithrandir> sabdfl: now.
<Riddell> Mithrandir: I just burned it to a new CD and the problem has gone away, thanks for your help anyway :)
<Mithrandir> Riddell: ok, thanks.
<Kamion> sabdfl: it's landed for Flight 2, despite being incomplete, because getting the old stuff to work again in the new kernel/initramfs world order was more difficult than just going for it
<Mithrandir> Kamion: if I do keymap magick in casper now, any chance of it making flight 2?
<jsgotangco> hiya sabdfl 
<maswan> Kamion: you going to ping me for mirror sying in the next couple of hours, or should I try make some sync method not requiring me to be awake?
<maswan> s/sying/syncing/
<Kamion> Mithrandir: not really, I need to get it out in like an hour or two or it's going to eat into vacation time
<Kamion> maswan: yeah, next couple of hours
<Mithrandir> Kamion: ok, that's fine.
* maswan nods
<Kamion> whoa, my desktop on this live CD is insane
<Mithrandir> how so?
<Kamion> duplicate bottom and top panels about 20% from the bottom of the screen
<Mithrandir> ew
<Kamion> window droppings all over the place
<Mithrandir> on your powerbook or another laptop?
<Kamion> powerbook
<Kamion> I'll reboot and try again
<Kamion> I wonder if unionfs instability is causing problems
<Kamion> lack of network plugging really bites on live CDs
<Mithrandir> add n-m to the live seed? :-P
<jdub> fabbione: http://www.tecchannel.de/news/themen/server/433610/index.html
<Kamion> Mithrandir: I think devmapper as an alternative would be a very good thing to have soon
<fabbione> jdub: ehehhe
<Kamion> it seems likely to me that a lot of this flakiness is down to unionfs
<jdub> heh:
<jdub> "In October 2005  even IBM ennobled  the Ubuntu server, by certifying the data base software DB2 for it."
<jdub> IBM ENNOBLED UBUNTU
<fabbione> yeah right!
<Mithrandir> Kamion: I'm already working on it.
<fabbione> sooner or later we will be RedHat certified :P
<Kamion> yeah, I'm just wondering whether I want to release Flight 2 this way :-/
<Kamion> oh, hell, should release it so that we can find out about the unionfs bugs, I guess
* Kamion will do it after getting back from the school play
<mvo> sabdfl: you asked to ping you when the update-notificaton changes are ready. do you like this design: http://people.ubuntu.com/~mvo/update-notifier/lala.png
<sabdfl> Mithrandir: ok, so Flight 2 live-cd should look quite different? is there a daily build you could point me at for x86?
<jdub> mvo: perhaps put the close button to the right of the title
<Mithrandir> sabdfl: http://cdimage.ubuntu.com/daily-live/current/dapper-live-i386.iso is using simplifiedlive atm
<sabdfl> seb128: should gnome be using firefox again now? url-clicking still busted on my laptop
<ogra> sabdfl, thats a firefox bug, not a gnome ne 
<ogra> *one
<mvo> jdub: thanks, I'll re-arrange it a bit
<ogra> the alternatives setup seems to be broken
<jdub> $ sudo update-alternatives --list editor
<jdub> /bin/ed
<jdub> /bin/nano
<jdub> 
<jdub> ^ meanwhile ;-)
<jsgotangco> heavy metal
<ogra> jdub, do you mean to choose ed or nano instead if firefox ? 
<ogra> s/if/of/
<sabdfl> mvo: the box looks very stark
<ogra> :P
<sabdfl> would prefer a cleaner [x] 
<sabdfl> will mail a sample picture
<sabdfl> ogra: seb128 said it was the gnome default app setting that needed to be changed from mozilla-firefox to firefox
<Riddell> mvo: what's changed there with update notification?
<ogra> sabdfl, ls -l /etc/alternatives/x-www-browser
<ogra> it points to a non existing mozilla-firefox binary
<zakame> ooh
<ogra> afaik gnome uses x-www-browser if you dont configure anything
<mvo> Riddell: only the layout and that there is a small [x]  now
<ogra> but seb128 might know better indeed ...
<mvo> sabdfl: ok, thanks. the [x]  itself is a stock gtk close
<seb128> sabdfl: if you changed it once with the preferred app capplet it's an user setting and not changed nop
<sabdfl> seb128: how can I revert that to default?
<mvo> jdub: do you like http://people.ubuntu.com/~mvo/update-notifier/lala2.png better? (icon closer to text now)
<lifeless> sabdfl: ping
<seb128> sabdfl: system, preference, preferred app and pick firefox
<sabdfl> lrwxrwxrwx 1 root root 24 2005-11-03 19:32 /etc/alternatives/x-www-browser -> /usr/bin/mozilla-firefox
<seb128> sabdfl: there is also the alternative issue but that's a firefox issue, ping Diziet about this one
<Diziet> sabdfl: Yes, that's broken.
<Diziet> Let me just check it's on my `to fix in next upload' list.
<Diziet> It doesn't seem to be in bugzilla at all.  I'm sure I asked the last person to grumble about it to file a bug.  Oh well, I'll do it now.
<ogra> Diziet, oh, sorry, that might have been me
<ogra> (or even mdz ...)
<doko> Diziet: which kind of info do you need on #13308?
<Diziet> x-www-browser> 20992.
<Diziet> doko: The difficulty there is that I can't reproduce it here conveniently because I have no amd64.
<Diziet> So if it still does it with the 1.5beta then I think the only answer will be to valgrind it.  Or perhaps to trawl through upstream's bug reports, but it's a very random-sounding behaviour and will be hard to search for.
<doko> it hits me very regulary, will upgrade the desktop after christmas and check again
<Diziet> Thanks.  Sorry not be able to be more helpful.
<ogra> doko, never seen that here on my amd64 
<mvo> hm, it looks like if we add a close button we either a small/long box in vertial direction or a "stark" box in horizontal direction (depending on where the close button is placed)
<doko> ogra: it usually happens after running firefox for about two days. your batteries don't last that long ...
<ogra> doko, :P
<mpt> mvo, why not make the whole box clickable? that would be much faster to use
<ogra> i dont run on batteries at home ... even if i live in the middle of nowhere we already have warm water and power here
<ogra> hmm, rsyncing a install iso to a live one is not a real speedup :/
<pitti> ogra: I rsynced the current dapper live against breezy live, just a speedup of 1.19
<ogra> yeah ...
<SloMoSnail> shawarma: ping?
<ogra> i guess i'll need to take the pain one time 
<mvo> mpt: the whole box is clickable, but apparently not everyone know it. that's why we add a button as well
<pitti> slomo: ffmpeg/hoary is in the archive now
<mpt> mvo, the solution to that is to make the box look clickable, not to make it look as if it's not clickable :-)
<slomo> pitti: thanks... i hope to get everything done until sunday :)
<mpt> mvo, e.g. by adding a bevel around the edge
<jdong_> ok, there
<mvo> mpt: something like http://www.martianrock.com/?p=146
<mpt> mvo, yes, that's a good start
<mpt> perhaps even a slight gradient for the entire bubble
<mpt> if you wanted it to look really polished
<jdong_> changelogs are broken on packages.u.c
<jdong_> I e-mailed the webmaster about it a few weeks ago with no response
<jdong_> s/packages\.ubuntu/changelogs\.ubuntu/ works pretty well to fix it though :)
<mvo> jdong_: have you tried changelogs.ubuntu.com
<mvo> ?
<rob^^^> I wonder if more users would install updates if they were prompted on shutdown to "Install updates and shutdown"
<jdong_> mvo: yes, but it'd be a LOT more convenient if p.u.c's changelog links don't 404
<Amaranth> a good way to make something look clickable is to make it prelight
<mpt> Amaranth, sure, if you're in the habit of scrubbing your mouse over the entire screen every few seconds :-P
<Amaranth> mpt: i mean once they get there
<Amaranth> mpt: making it beveled helps, making it prelight makes them sure
<mpt> but part of the point of the notification bubbles is that they get in your way as little as possible, which means they're very unlikely to be under the cursor to start with, so pre-lighting them wouldn't make them look clickable until it was far too late (i.e. you'd already decided where to click)
<maswan> mpt: prelighting it might give a hint that will be remembered next time? that is, you only aim for the button the first [couple of]  time[s] .
<mpt> perhaps, but I'd prefer something which was *also* obvious the first time :-)
* mpt should get around to drawing those mockups for DapperDesktopPlan
<slomo> lamont, infinity: please let mod-mono compile on ppc/ia64... thanks :) at least ppc works, i've verified that
<kairo> Ive on latitude d510 and touchpad dont work for 'click and select'. Looking on the package documentation /usr/share/doc/xorg-driver-synaptics/readme.debian have a refer about kernel module config_mouse_ps2_synaptics. On Ubuntu Kernels this module is not pre-compiled. Possible error?
<Kamion> that's not a kernel module name, it's a kernel configuration option name - you won't find a module by that name
<Nafallo> infinity: no luck with linuxdcpp is looks like. it builds fine in pbuilder :-/.
<Kamion> kairo: I believe that that document is a bit out of date, and that CONFIG_MOUSE_PS2_SYNAPTICS is just part of CONFIG_MOUSE_PS2 these days (which is modular in our kernels, as the psmouse module)
<Kamion> I've never used one of these devices though so can't help further
<Kamion> Riddell: any more Kubuntu testing results? are you OK to release?
<Amaranth> btw, is it a duck or a dragon?
<HiddenWolf> Amaranth, halfbreed.
<Kamion> ogra: how's Edubuntu testing going?
<Amaranth> i don't think that's physically possible ;)
<Riddell> Kamion: i386 all good, amd64 just finished downloading I'm burning now.  no volunteers for powerpc yet
<HiddenWolf> Amaranth, body of a duck, with style, and the punch and the heart of a dragon. ;)
<ogra> Kamion, going on ... i'll report if i'm done ...
<Amaranth> HiddenWolf: I meant the breed part :)
<ogra> Kamion, my rsync and cdwriter machine is the same as the test machine .. i'm just reorganizing a bit here
<Diziet> ?Diziet
<Diziet> Oops :-).
<Kamion> Mithrandir: the unionfs flakiness seems confined to powerpc
<Kamion> I'm guessing it's endianness trouble
<ogra> Kamion, at least as long as dapper doesnt support CD writing its a bit of fiddling here ...
<Kamion> I thought you said growisofs worked
<Amaranth> ogra: Ever figure anything out for menus based on groups?
<ogra> Amaranth, nope, thats for dapper+1 :)
<Amaranth> ogra: It's not possible with the spec but a script that runs on startup could do something.
<ogra> Kamion, on breezy
<Kamion> ah
<Amaranth> s/startup/login/
<ogra> Amaranth, i think i'll move to preconfigured sabayon profiles at dapper 
<ogra> i dont want any scripts ...
<sabdfl> mvo: that's pretty nice and would look good on our default desktop too
<ogra> err dapper+1
<Amaranth> that would be nice
<sabdfl> (the martianrock example)
<Amaranth> you could just launch sabayon and use alacarte to edit menus there :)
<ogra> Amaranth, yep
<ogra> my prob is that sabayon doesnt work over ssh connections, so using it in our ltsp environment isnt possible... i have no idea how to fix that
<mvo> sabdfl: ok. this one is the current development stuff from the gnome guys, I'll ask how stable it is and test it here a bit (it's a api change, but it looks like it's not hard to make the switch)
<mvo> Kamion: current live works pretty well here, the startup is a big ugly (but you proably know this already :)
<Kamion> mvo: thanks, yeah, it's in the errata
<kairo> Kamion: in contact with another user (with another laptop) recive the identic error. I dont need recompile kernel for a test?
<Kamion> kairo: like I say, I don't know enough to help further, sorry; if I were you I'd file a bug
<shawarma> slomo: pong?
<slomo> shawarma: are you upstream for libmms? or did you only package it for ubuntu? i ask because your mail address is in configure.ac if i'm not mistaken ;)
<Nafallo_live> how can I get swedish keyboard on this livecd?
<shawarma> slomo: Both.
<shawarma> slomo: Why?
<Kamion> Nafallo_live: right now you'll need to use System -> Preferences -> Keyboard -> Layout in GNOME
<slomo> shawarma: ok... then you need to learn about sonames ;)
<shawarma> slomo: Probably so.
<slomo> shawarma: the API changed with the new release but the soname didn't ;)
<shawarma> slomo: Er... Ok. Then it's not me after all. I USED to be upstream, apparantly. I didn't know anyone still worked on it.
<shawarma> slomo: :-)
<shawarma> slomo: I never got any bug reports, so I never changed anything.
<Nafallo_live> Kamion, some weird thing, but atleast it boots </(
<slomo> shawarma: christian schaller (iirc) released 0.2 some days ago
<Nafallo_live> ehm, and that was an attempt of a smiliey >/P
<Kamion> Nafallo_live: yes, startup's pretty odd at the moment, will be in the release notes
<Nafallo_live> Kamion, and checkpoints you want me to do?
<shawarma> slomo: Oh, ok. I had no idea.
<shawarma> slomo: I just worked on the 0.1 release. Since then I haven't touched it. :-/
<slomo> shawarma: hmm, can you talk to him about this?
<Kamion> Nafallo_live: the high-priority stuff on https://wiki.ubuntu.com/TestPlans is good
<Nafallo_live> Kamion, oki. I'll have to go shopping *girlfriend is pulling my hair atm), but I
<Nafallo_live> 'll do the bits when I get back
* Nafallo_live hates american keyboard </(
<shawarma> slomo: I'm REALLY busy until this monday. If you can wait that long, then sure.
<slomo> shawarma: sure... thanks :)
<Kamion> Nafallo_live: ta
<jsgotangco> good night all
<Riddell> Kamion: kubuntu amd64 CDs are both good
<Kamion> and all Ubuntu CDs look good with the exception of various errata I've noticed
<Kamion> er, noted
<jbailey> Kamion: We're free to break the archive again now? =)
<Kamion> well, Edubuntu isn't done yet
<jbailey> 'kay.
<sabdfl> Kamion: i just pulled dapper-live daily, should i pull it again?
* jbailey goes back to pacing the room.. ;P
<zakame> good night all :D
<Kamion> sabdfl: last live build finished at 11:54 this morning, so if you pulled after that you should be good
<sabdfl> Kamion: perfect, thanks
<doko> seb128: what about replacing the gcc based cpp on the CD with the smaller/faster one?
<seb128> doko: GNOME uses mcpp atm
<seb128> at least gnome-settings-daemon
<maswan> Kamion: time soon? I'm jsut about to head to bed
<Kamion> maswan: hm, will be about half an hour I think
<maswan> Kamion: Ok
<Kamion> Riddell: ok, I'll publish Kubuntu along with Ubuntu then
<ogra__> Kamion: th elocale prob is still there
<ogra__> (tried a german install though, will test a default en_US one as well)
<Kamion> ogra__: didn't happen for me in a French install
<Kamion> ogra__: can you clarify exactly what problem you're seeing?
<Riddell> Kamion: great
<ogra__> perl warnings
<ogra__> wait, i'll get the laptop here
<Kamion> please look for localechooser in /var/log/installer/status and tell me the associated version
<ogra__> LC_ALL is unset
<ogra__> language and lang are set to the right one
<Kamion> just the information above will be fine
<doko> seb128: then liborbit0 and libidl0 should use that as well, that will save us 1.5MB on the CD
<ogra__> ok
<lucasvo> there are wrong dependencies in kanagramm, renaming of the  kdelibs4c2 is the problem
<seb128> doko: k, will try to work on that
<ogra__> Kamion: 0.22ubuntu4
<Kamion> ogra__: ok, can you put /var/log/installer/syslog somewhere for me to look at?
<Kamion> (that version should be good)
<ogra__> yup, as soon as its finished ... broken on postgresql ...
<Kamion> /var/log/installer/syslog will already be complete
<pitti> ogra__: still?
<ogra__> pitti: sure
<Kamion> the log file it's using now will be /var/log/base-config*
<ogra__> pitti: if the locale is still wrong
<pitti> ogra__: ah, ok
<Kamion> I only need the former
<ogra__> pitti: but i still think thats a bug to rely on locales with a cert 
<pitti> ogra__: cert?
<ogra__> pitti: you told me its generating a certificate based on the locale
<Riddell> lucasvo: Kamagram Depends: kdelibs4c2a 
<pitti> ogra__: oh, no, a cluster
<pitti> the SSL certificate is locale independent, of course
<lucasvo> Riddell: hm, really? since when? my apt sources are only 2h old
<ogra__> pitti: but still, relying on locales anywhere here is wrong imho ... i know admins that run their servers with LANG=C
<pitti> ogra__: that is fine
<ogra__> or dont even set it
<Riddell> lucasvo: for some time, is this dapper?
<lucasvo> Riddell: yes, 2h old :D
<pitti> ogra__: I don't rely on any arbitrary locale being present, just the one that is currently set
<Kamion> lucasvo: do you have anything else in /etc/apt/sources.list other than dapper?
<pitti> ogra__: i. e. if you tell the system that you want de_DE.UTF-8, but that locale doesn't exist
<ogra__> yup
<pitti> ogra__: then it is impossible to generate a cluster with de_DE.UTF-8
<ogra__> true
<pitti> ogra__: so if your server does not use any locales, postgresql will happily generate a C cluster
<ogra__> Kamion: 
<ogra__> i bet i know the prob
<ogra__> Kamion: just tried to scp, the langpacks are not on the CD and my eth1 isnt up ...
<ogra__> good old udev
<Kamion> ah, right
<lucasvo> Kamion: no
<lucasvo> ok, apt-get update solved this problem but:
<lucasvo>   kiosktool: Depends: kdelibs4c2 (>= 4:3.4.3) but it is not installable
<lucasvo>   synce-kde: Depends: kdelibs4c2 (>= 4:3.4.3) but it is not installable
<ogra__> i'll try a en install, these are on the edubuntu CD
<Kamion> yes, that makes sense, langpack-locales would allow me to fix this although it would involve installing langpack-locales in default installations or something like that
<ogra__> is that big ? 
<pitti> Kamion: you mean the 'locales' package with all locales? (langpack-locales is the source package of current locales)
<Kamion> not very, but we explicitly didn't want it to be included by default
<Kamion> pitti: locales doesn't include the actual locales though, does it?
<pitti> Kamion: not at the moment, according to the spec
<Kamion> in fact I'm pretty sure it doesn't because as it stands we already install locales
<Diziet> Um, the `new updates available' balloon has just popped up over the top of my (black screen) screensaver.
<pitti> Kamion: however, we can always change it back
<Diziet> Is this a known bug ?
<ogra__> o ok ... probably i can pull it in for edubuntu then, my set of langs will always be smaller than ubuntu ones
<Riddell> lucasvo: yeah, there's still packages needing a rebuild, poke us in #kubuntu-devel if you have dany paticular requests
<Kamion> ogra__: no, leave it for now and we'll solve it properly
<Diziet> And now it has gone away again.  How odd.
<ogra__> oki
<Kamion> I don't want to hack around hiding it for some languages in some derivatives, or we'll never bother to fix it right for Tagalog on Kubuntu or whatever
<lucasvo> Riddell: ok
<Kamion> pitti: don't really want to make a snap decision on it just now, but the current situation is beginning to look pretty unpleasant to support
<lucasvo> Riddell: or should I submit a bugreport?
<ogra__> Kamion: btw, i saw pcmcia-cs rushing by in stage 1 ... is that intentional ? 
<Kamion> ogra__: yes
<ogra__> oki
<Kamion> in the release notes to :)
<Kamion> too
<ogra__> thought it was gone
<Kamion> we still need pcmcia-cs for some configuration files
<Riddell> lucasvo: can do but just asking on IRC will be the same effectiveness
<ogra__> ok
<pitti> Kamion: what's the root of the problem? that the installer offers locales for langpacks we cannot ship?
<Kamion> eventually they'll move to pcmcia-common or similar, but they haven't done so yet
<Kamion> pitti: yes
<ogra__> bah,and we really should solve the fontcache generation one day
<ogra__> every single font takes 30sec
<lucasvo> Riddell: ok
<Kamion> pitti: it works fine as long as you're on the network and can download the language pack
<pitti> Kamion: it seems to cause pain for other usages, too, so maybe we should revert that 
<pitti> Kamion: ... or use a langpack that's on the CD, I assume?
<Kamion> what about the file overlap thing?
<Kamion> indeed
<Kamion> can we make locales and the language packs ship locales in different places? IIRC that coming up last time we discussed this
<pitti> Kamion: well, we can either ship it in locales in addition and Replace: locales in the langpacks, or just ship it in locales and be done with it
<Kamion> to solve this particular problem, we'd have to arrange for them to be generated from that different place
<Kamion> ok
<pitti> Kamion: two different places wouldn't be too difficult either, but I don't like such redundancy
<pitti> I mean, *if* we want to update locales post-release, then we can as well update the locales package itself
<ogra__> hey, usplash runs at the same resolution the installer used, thats incredible impressing :)
<pitti> now that it has its own source package, it doesn't make much of a difference
<pitti> but it would bring back our /etc/locale.gen conffile
<pitti> probably deserves some deeper discussion
<Kamion> I think I'm too tired to think about it properly ATM, too
<pitti> Kamion: I might not be fully aware about the reasons for splitting out the locales, so we should defer that discussion maybe
<kairo> Kamion: solved the problem. This is a related bug (solution posted in bug too) but not removied. Thanks.
<Kamion> maswan: syncing out to DC mirrors now, will be available for you shortly
<maswan> Kamion: whee
<dilinger> are you guys still using baz for stuff?
<dilinger> or have you switched over to bzr?
<Kamion> bit of both in my case
<Kamion> gradually switching over, blocked for some things on figuring out how to do configs in bzr
<ogra_test> hmm, gdm didnt start either ...
<dilinger> Kamion: what about the supermirror/archive stuff?
<Kamion> dilinger: that I don't know, TBH I've never used the supermirror much
<Kamion> whoa, somebody rearranged the launchpad UI
<Kamion> I'm probably giving away roughly how often I use Launchpad here
<Kamion> maswan: ready for you to mirror
<maswan> dapper/flight-2/dapper-install-amd64.iso
<maswan> ...
<dholbach> infinity: seems that the make bug killing cdbs was fixed
<maswan> it'll probably be a while, and I need sleep.
<maswan> http://ftp.acc.umu.se/mirror/cdimage.ubuntu.com/ <- stuff will appear there, and the archive-update-in-progress will disappear
<mgalvin> the various media apps have not all been built against gstreamer 0.10 yet, correct?
<maswan> feel free to link to it, or dump a few hundred megabits of http-redirects, if needed. 'night
<Amaranth> mgalvin: 0.10 is not compatible with 0.8
<Amaranth> mgalvin: apps have to be ported, not just rebuilt
<Kamion> maswan: thanks, dude
<mgalvin> Amaranth: do we know which ones do and don't work yet?
* mgalvin needs food
<Amaranth> banshee has limited support, rhythmbox has support in cvs (or whatever they use), totem has a port, and i think sound-juicer does as well
<jbailey> dholbach: I think gnome-terminal is fixed, thanks!
<dholbach> jbailey: cool
<slomo> doko: thanks for updating libvorbis and libogg :)
<Nafallo_live> dholbach, known bug that yelp doesn
<Nafallo_live> 't start?
<dholbach> which one?
<dholbach> i mean which yelp
<Nafallo_live> the one on current livecd
<dholbach> erm, do you have the version at hand?is it 2.13.2-0ubuntu2?
<dholbach> what does it say in the terminal?
<Nafallo_live> 2.13.2-0ubuntu2
<Nafallo_live> ubuntu@ubuntu:~$ yelp
<Nafallo_live> yelp: symbol lookup error: /usr/lib/mozilla-firefox/components/libdocshell.so: undefined symbol: PR_GetPhysicalMemorySize
<dholbach> arg
<dholbach> so the build-conflicts didn't help :/
<Nafallo_live> I have it on my regular system aswell
<dholbach> it works on all my systems
<dholbach> strange strange
<Nafallo_live> amd64?
<dholbach> amd64 and i386
<dholbach> but thanks for the heads up, i will try to find out what it is
<dholbach> and how to circumvent it
<Nafallo_live> kewl. I will probably be avaible for debugging tomorrow.
<dholbach> merci, nafallo
<Nafallo_live> de rien
<dholbach> :)
<seb128> Nafallo_live: do you have mozilla-browser installed?
<Nafallo_live> seb128, nope. this is the current livecd
<dholbach> libnspr4 maybe
<Nafallo-live> sorry, I'm not used to US layout
<seb128> dholbach: libnspr4 has to be installed
<Nafallo-live> did I miss something?
<Nafallo-live> evolution-alarm likes to eat my whole CPU-load btw
<Nafallo-live> about 75%, gconfd-2 uses the rest.
<seb128> Nafallo-live: on calendar?
<ogra_test> pitti, language-support-en tries to load a dtd from w3c.org
<PupenoL> I have created a kernel module package with module-assistant (zaptel-module), my problem is that it ends on /lib/modules/2.6.12 instead of /lib/modules/2.6.12-10-686/, any ideas ?
<ogra_test> Kamion, with en_GB the install runs fine here
<pitti> ogra_test: hmm? scary
<pitti> ogra_test: what in particular?
<ogra_test> xhtlm1-transitional.dtd
<pitti> no, I mean which package
<pitti> ogra_test: during installation, or when?
<ogra_test> language-support-en
<pitti> ogra_test: certainly not l-s-en itself, it's empty
<ogra_test> thats the last i see on the console, then base-install stops
<ogra_test> hmm, looikg at the log
<Kamion> (base-config not base-install)
<pitti> ogra_test: can you please check with netstat which program has the open connection?
<ogra_test> its a bit odd with wrong kezboard settings
<Kamion> (it's confusing because there's another thing called base-installer)
<ogra_test> oh, yes
<xhaker> Kamion, you're testing daily builds?
<Kamion> xhaker: frequently
<Kamion> xhaker: are you? :-)
<xhaker> so, how much till a flight 2
<xhaker> i wish i was
<ogra_test> Setting up language-support-en (20051010) ...
<ogra_test> I/O error : Attempt to load network entity http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
<ogra_test> I/O error : Attempt to load network entity http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
<xhaker> my connection is 512k :S not even rync will save my ass
<ogra_test> thats the last in /var/log/base-config-pkgsel.log
<Kamion> xhaker: Flight CD 2 is already going out to mirrors and will be announced as soon as the mirror with most bandwidth finishes getting it
<Treenaks> ogra_test: cool!
<Treenaks> Kamion: VERY cool :)
<xhaker> Kamion, any "release notes" you want to share?
<Kamion> xhaker: they'll be in the announcement
<xhaker> oh
<Kamion> too many to paste here
<Treenaks> Kamion: any earth-shocking ones?
<xhaker> i guess i'll make a visit (with my laptop) to my university today
* Treenaks needs to persuade $employer to become a full mirror of Ubuntu
<ogra_test> pitti, any idea ?
* xhaker my university too should
<Treenaks> we have the bandwidth, we have the diskspace..
<Nafallo-live> xhaker, I kept a complete ubuntu mirror and current daily and daily-live on 512/512k.
<mjg59> Diziet: New firefox breaks older epiphany, but doesn't declare a conflicts
<mjg59> Diziet: Any information I can usefully give you?
<Kamion> Treenaks: nothing really horrible, things like broken rescue mode under some circumstances and the already-known thing that network interfaces don't come up on boot; the worst is probably that the new live CD with unionfs seems very flaky indeed on powerpc
<Treenaks> Kamion: ok, cool
* ogra__ still has 2h to go with liveCD rsyncing :(
<xhaker> Treenaks some soundcards are in trouble too
<xhaker> ogra__ my problem too.. but i would have to wait more
<mjg59> Diziet: (1.8.2-ubuntu1 of epiphany-browser, 1.4.99+1.5rc3 of firefox)
<xhaker> Nafallo-live, you kept i didnt ;(
<Nafallo-live> xhaker, hehe
<Burgwork> Kamion, are you going to include the DapperFlight2 wiki page in the annnouncement?
<seb128> mjg59: firefox1.5 is not ABI compatible with 1.0.n
<Kamion> Burgwork: yes
<Kamion> (already in my draft)
<mjg59> seb128: I know
<Kamion> and if you look at the page history you'll see I've been fixing some minor things in it
<seb128> mjg59: since firefox has no soname or whatever for that ...  just upgrade epiphany as well
<seb128> (firefox could Conflicts on previous version of everything using it as well)
<mjg59> seb128: A system that satisfies dependencies shouldn't have broken software
<HiddenWolf> seb128, gstreamer0.10 is mentioned in the flight notes. Is it actually being used already?
<seb128> HiddenWolf: no
<HiddenWolf> seb128, might not want to give that impression then?
<seb128> mjg59: so firefox should Conflicts on everything using it with the right version
<seb128> HiddenWolf: I didn't write those note, I'm not the right guy to ping about that
<Kamion> HiddenWolf: mgalvin's primarily responsible for that page
<Amaranth> oops
<HiddenWolf> mgalvin, ^^
<mgalvin> HiddenWolf: I am fixing that now :)
<Amaranth> i guess he thought since apps supported gst 0.10 in upstream that they did in dapper too
<mgalvin> just got back from lunch
<seb128> Amaranth: they don't upstream
<mjg59> seb128: Everything we ship that depends on it, yeah
<Amaranth> seb128: in #gnome-hackers they said totem, s-j, and rhythmbox all had support for it
<HiddenWolf> Amaranth, but not the default yet. :)
<xhaker> so, i'm going to test flight2.
<xhaker> but, what about fixing the soundcards problem
<seb128> Amaranth: "support" is a fuzzy notion :)
<Amaranth> HiddenWolf: but that's a build problem :)
<seb128> Amaranth: there is a bunch of plugins not ported to start
<Diziet> mjg59: Hello.
<seb128> Amaranth: some have patches travelling around but no official commit of them, some other have CVS code
<Amaranth> seb128: true, but how many of those plugins can ubuntu ship anyway?
<seb128> ship like what?
<seb128> like we ship -dvd to universe?
<mjg59> Diziet: Should Firefox be conflicting on rdepends that are built against older ABIs?
<Diziet> Hrm.  Not sure I like Conflicts << really but I suppose it's the de-facto answer here.
<Amaranth> seb128: but not libdvdcss
<Diziet> The whole thing seems a bit borked really.
<seb128> Amaranth: installing something from universe is one thing, not beeing able to install it is another
<seb128> Amaranth: you can install that, I've it installed
<Kamion> xhaker: that's rather orthogonal to CD releases
<seb128> even if that's not from the main archive
<Diziet> Do the new packages say  Depends: firefox (<= the next version that's going to break)  ?
<mjg59> Diziet: No, since it's not really obvious what that's going to be
<seb128> Diziet: what is the next version going to break?
<seb128> 1.6? 2.0?
<Diziet> We're not likely to ship a 1.6 are we ?
<Amaranth> 2.0 is the next version
<Amaranth> appearently they'
<Amaranth> err
<Diziet> And 2.0 is going to break the ABI again.
<seb128> Amaranth: breaking ABI compatibility? not using xulrunner?
<Amaranth> appearently they're planning on 2.0 for this time next year
<Diziet> So 2.0 is that version.
<mjg59> Can we have a firefox provides: firefox-abi-1.5 ?
<Amaranth> 3.0 will be the one using xulrunner
<Kamion> <=|<< next-version is tricky too because people do things like 1.5.99-rc1 for 1.6rc1
<Diziet> mjg59: I think that's the best answer.
<mjg59> Which doesn't fix the current breakage, but helps us later on
<seb128> Diziet: that will not fix the issue of a partial update from 5.10
<Diziet> Right.
<mgalvin> https://wiki.ubuntu.com/DapperFlight2#head-1bd3de61b9f3b96bdd546d69e847ccafac4a33bb
<Kamion> seb128: it can coexist with Conflicts << easily enough, though
<mgalvin> sound ok?
<Amaranth> a partial update from 5.10 shouldn't be expected to work anyway, should it?
<xhaker> mjg59 it is my impression that there has been a regression in dapper from laptop-mode or something.. like.. changing my laptop brightness triggers SLEEP... i remember seing this happen in breezy and then there was a fix
<Kamion> Amaranth: er yeah, discounting the kernel/udev madness
<seb128> Amaranth: why shouldn't it?
<mjg59> Amaranth: If it satisfies dependences, why not?
<Diziet> So the plan is: my next upload has  Provides: something-suitable  and  Conflicts <<  on all the old packages for which I have details.  Then all packages should change to say   Depends: something-suitable-1.5
<mjg59> xhaker: hotkey-setup may need upgrading to deal with the new dmidecode
<Diziet> Err, sorry, I mean  Provides: something-suitable-1.5
<seb128> Diziet: I can make a list of GNOME stuff to Conflicts and put it to bugzilla if you want
<Kamion> mgalvin: fixed your spelling :)
<Diziet> `for which I have details'> seb128: Right, yes, please.
<mgalvin> i just did too :)
<Diziet> I need version numbers, not just package names, of course.
<seb128> Diziet: np. Do you already have a bug about that, or should I open a new one?
<Kamion> yeah, hit a conflict
<Amaranth> ok so for this one do the conflicts and the provides, then next time you don't need the conflicts part, right?
<seb128> Diziet: sure :)
<Diziet> seb128: No.
<Diziet> So open a new report.  Set it to P1 (if bugzilla will let you).
<seb128> Amaranth: correct
<mjg59> Amaranth: That's the idea
<Kamion> I strongly think it should be "DVDs" etc. not "DVD's"
<seb128> Diziet: k, will do
<mgalvin> k, fixing
<xhaker> mjg59 acer laptop
<Kamion> (already done)
<mjg59> xhaker: Yeah
<Diziet> ATM I'm buried in the libnss build system but I will definitely have an upload by the end of the week.
<Kamion> but yeah, otherwise looks good
<Diziet> seb128: Do I need to file bugs against stuff which  Depends: firefox  ?
<mgalvin> k, cool
<seb128> Diziet: for what? To Depends on the new Provides?
<Diziet> seb128: Yes.
<Kamion> Is that not done with shlibdeps?
<Diziet> Err, I suppose it might be.  I don't know how this embedding stuff works really.
<seb128> Diziet: no need to bother, I'll change them after your upload
<Kamion> Hmm, apparently not
* Kamion runs away from firefox again
<Diziet> Very wise.
<Diziet> seb128: OK, thanks.
<HiddenWolf> seb128, you could just lobby to use ephy as default for dapper. ;)
<seb128> HiddenWolf: that's not going to happen before having xulrunner
<seb128> HiddenWolf: we need firefox anyway for gtkembedmoz atm
<HiddenWolf> seb128, and that's version 3 of firefox, like 2 years away?
<Amaranth> 1 1/2 to 2, yes
<seb128> HiddenWolf: I'm not sure, Debian guys want to use xulrunned for etch and Suse already does atm
<Amaranth> epiphany and gtkmozembed need to have firefox installed anyway, so that's a bit of a wash
<seb128> Amaranth: not if you build epiphany with xulrunner
<Amaranth> version 2 might use xulrunner, i just know 3 will for sure
<Amaranth> but that's still 1 year from now
<HiddenWolf> I don't get why there is no solid alternative to gecko/mozilla save for khtml
<Amaranth> writing a web browser is hard
<HiddenWolf> The engine is good, but using it doesn't exactly give other browsers anything that firefox/moz don't have.
<HiddenWolf> using the same backend and chewing the same amount of ram, they have no solid advantages.
<Amaranth> "Ship Firefox 2 no later than Q3 2006 and Firefox 3 no later than Q1 2007"
<Treenaks> Amaranth: they're going the Sun/Java way?
<HiddenWolf> Amaranth, factor in delays. ;)
<Treenaks> Amaranth: 'Firefox 1.10 (but we'll call it 10!)'
<pitti> Kamion: would you be opposed to putting the current dapper pmount into breezy-updates? Tons of people complain that they cannot mount floppy disks in breezy, and 0.9.6 fixes it; it's in dapper for quite a while now and already in breezy-backports
<Kamion> pitti: can you mail me the diff? I'll have a look at some point over the next couple of days (about to go out to the pub and thereafter on vacation until beginning of next week ...)
<pitti> Kamion: that diff will look pretty scary, I'll prepare a downsized patch
* mvo heads offline for today
<pitti> good bye mvo
<Kamion> pitti: I would certainly prefer a reduced targeted change if possible
<mvo> bye pitti 
<Kamion> but I'm not opposed in principle
<pitti> ok, I'll backport the necessary changes and mail you
<pitti> Kamion: enjoy the pub :)
<dholbach> whiprush: ping
<dholbach> jdub: ping
<whiprush> yo
<Nafallo> jbailey: ping :-)
<jbailey> Nafallo: pong
<Nafallo> jbailey: bzr conflicts bzrtools?
<jbailey> Nafallo: Right.  You're caught partway through a transition.
<jbailey> Well, more like bzrtools hard depends on the version of bzr it was tested with.
<jbailey> I'm just working out the last bits, but the idea is that you'll never get a combination of bzr and bzrtools where both selftests don't completely pass.
<Nafallo> so I shouldn't remove either package but wait until both wants to be upgraded? :-)
<jbailey> Right.
<Nafallo> oki, nice :-)
<jbailey> Nafallo: Redo your update, and you should get both happy now.
<ogra_test> seb128, there is no option for focus follows mouse anymore ??
<Nafallo> jbailey: I'm happy, thanks :-D
* ogra_test hopes thats a bug
<seb128> ogra_test: gnome-window-properties
<seb128> ogra_test: it's just masked from the menu because that's not an standard user feature
<ogra_test> seb128, yes, but no menu item 
<seb128> MenusRevisited
<ogra_test> ugh
<ogra_test> so we doom the default user to click on his windows ? 
<ogra_test> how odd
<seb128> default settings should be sane
<seb128> click to focus is nice for most of users
<ogra_test> its the only thing me and all people around me change from the default, beside rolling up windows to the toolbar like apple does by default
<seb128> if you know what focus on click or mouseover is you know enough to start the app or use a menu editor or use gconf-editor
<ogra_test> sad, but i can live with it ...
<ogra_test> (i guess)
<seb128> why sad? that takes you like 5s to type the command I gave you
<seb128> why couldn't you live with that?
<ogra_test> sure
<seb128> that's a bit of exageration
<ogra_test> because clicking to focus is odd behavior ... worse is the maximize on title click
<seb128> I like both
<seb128> matter of taste
<ogra_test> yup
<HiddenWolf> ogra__, it's default for 90% of the worlds population
<ogra_test> but i know a lot of apple users that love gnome for these ...
* dholbach uses alt-f10
<HiddenWolf> ogra__, i've never used differently as far as I can remember.
<ogra_test> they will moan :)
<seb128> appler users are a special case
<ogra_test> heh
<ogra_test> i'll tell them :)
<seb128> alt-f10 is an insane shortcut
<seb128> you can't do it with one hand on a normal keyboard
* dholbach uses it anyway
* seb128 has a custom shortcut for it
<HiddenWolf> if anything, alt-f10 must be the most awkward and gymnastic shortcut on the boards. ;)
<dholbach> you're a bunch of sissies ;)
<HiddenWolf> dholbach, proudly so. :D
<ogra_test> i never used this shortcut ...
<dholbach> ROCK! that's the spirit!
* dholbach hugs HiddenWolf
* HiddenWolf hugs dholbach right back
<ogra_test> huggers
* HiddenWolf hugs ogra_test too
<ogra_test> heh
<ogra_test> wow, ltsp-build-client runs since 2h here and is still not even 1/2 done ... 
<dholbach> did anybody know http://packages.ubuntu.org.cn?
<ogra_test> to silly it uses the us mirror by default for the boostrapping ...
<HiddenWolf> dholbach, an ubuntu-spoofed url, with a debian theme, in chinese? Can't say I've had the pleasure. :)
<dholbach> i think it's just the software, that runs on packages.debian.org put on by the .cn loco team
<HiddenWolf> Probably. :)
<ogra_test> but its great to test the chinese fonts work :)
* HiddenWolf goes back to studying.
<HiddenWolf> Night guys.
<dholbach> night HiddenWolf
<ogra_test> night HiddenWolf 
<xhaker> Kamion any wiki page with the cdimage mirrorS?
<dholbach> you think, http://wiki.ubuntu.com/Testing should be in the flight2 release announce?
<mgalvin> dholbach: maybe in the Participate in Ubuntu section possibly
<dholbach> mgalvin: is that a section of the announce?
<ogra_test> i'd rather put it in big letters on the top of the announcement, since thats all a flight release is for
<mgalvin> well its on that wiki page i have been working on, i am not sure what the "official" announcement will include
<dholbach> yeah, i thought along the same lines as ogra, just asking for opinions
<jdong> interesting how MIT sends admission decisions in a tube....
<jdong> now, Ubuntu scholarships would be a cool idea :)
<lucasvo> is nfs working on dapper?
<zul> yep
<zul> for me at least
<Kamion> xhaker: Archive
<Kamion> dholbach: hmm, not sure how to phrase it in the announcement
<Kamion> dholbach: "if you'd like to help with some of the tests we've already done, please look here"? :-)
<Kamion> I'll see what I can do
<Nafallo> hehe
<Nafallo> they could always file bugs on things that doesn't work in the tests on their end? :-)
<dholbach> Kamion: hehe, maybe somehow differently :)
* Nafallo didn't have the right resolution, nor keyboard layout
<Kamion> The following area of the wiki suggests various tests that can be
<Kamion> performed on Flight CD releases to try to catch bugs far enough before
<Kamion> the final release that they can be fixed:
<Kamion>   http://wiki.ubuntu.com/Testing
<Kamion> that ok?
<dholbach> Kamion: "We appreciate any testing of the CDs. Please don't file bugs, please write nice mails stating what a nice job we do."
<Kamion> maybe s/following/Testing/
<dholbach> yeah, that looks good
<Kamion> dholbach: heh, maybe not so productive :)
<Nafallo> sounds good to me :-)
<dholbach> after flight2 is announced, i'll announce the next bug day :)
<Kamion> has anyone sent a reminder of tomorrow morning's distro team meeting yet?
* dholbach didn't receive one yet
<dholbach> shall i do it?
<Kamion> please
<Nafallo> I haven't received one either.
<dholbach> u-d-a@?
<Kamion> yes
<dholbach> ah yes, they went there before
<daniels> Kamion: 0800 UTC?
<Kamion> yes
<daniels> Kamion: aha.  ok, I probably won't be able to make it; family commitments, and the broadband hasn't been moved over to the new place yet.
<daniels> Kamion: i'll send janew a summary
<Kamion> ok, please send ... what you said
<dholbach> sent it
<Kamion> dholbach: I think some of that is misleading
<Kamion> I don't want to encourage people to spend time on merges this week, for example
<Kamion> dholbach: could you send another message without that bit, and also "I am producing" => "Jane is producing"?
<dholbach> oh yeah
<dholbach> sorry, sent again
<Mithrandir> Kamion: ok, "good".
<daniels> Kamion: \o/ flight :)
<dholbach> Kamion: you could have sent the announce to  fridge-devel@lists.ubuntu.com  too (assuming you didnt bcc them)
<lucasvo> am I the only person whoose terminal is not able to open deerpark after dapper upgrade?
<Kamion> dholbach: accepted now
<Kamion> dholbach: sorry, I've no idea how the fridge works, feel free to bounce it
<dholbach> Kamion: will do so
<Kamion> thanks
<dholbach> you normally just send the announce mail to that mailing list too, jdub and whiprush will take care of it
* ..[topic/#ubuntu-devel:Kamion] : 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 | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Dapper has new kernels and new world order, upgrading for the adventurous only (and those with another machine to use) | Fli
<Kamion> meh
* ..[topic/#ubuntu-devel:Kamion] : 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 | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Dapper has new kernels and new world order, upgrading for the adventurous only | Flight CD 2 released
<dholbach> ROCK :)
<dholbach> daniels: a new xdamage! maybe gnome-mag will be happy now? :-)
<daniels> nah, you need a new xorg-server for that
<daniels> i might upload it if I'm feeling spiteful
<dholbach> take your time :)
* mdke nudges dholbach 
<dholbach> hi mdke
<mdke> :)
<LaserJock> hmm, hope he doesn't come back as ogra_dead ;-)
* ogra_live applauds Kamion and Mithrandir extatically
<ogra_live> wow, the livecd is really impressive fast
<ogra_live> the missing language selection is a bit odd, and i had a kernel oops on boot on amd64 with the i386 CD, but it runs anyway
<fabbione> daniels: did you do an upload?
<sivang> wow, flight two released :)
<daniels> fabbione: a couple, yes
<fabbione> daniels: ah i see..
<daniels> fabbione: xorg-server and the sparc drivers are still pending
<fabbione> :P
<fabbione> daniels: no problem.. if you can get them to do before Xmas it would be very good
<fabbione> otherwise you can just tar them up for me
<fabbione> and i will work on them between xmas and new year
<daniels> nah, 'scool, got them here on my disk, just need to check that they build OK with the old xserver before I upload
<Kamion> ogra_live: intent is to move language selection to the bootloader, which you get on amd64/i386
<Kamion> powerpc kind of loses at the moment
<ogra_live> sad
<ogra_live> but i could live with it
<Kamion> we can probably figure something out, but it's more important to get this stuff basically working early
<ogra_live> sadly i didnt catch the oops
<Kamion> it'll be unionfs
<Kamion> oh, you said amd64
<Kamion> unionfs breaks on powerpc, not sure about amd64
<fabbione> daniels: so does that mean you did resurrect your sparc?
<daniels> fabbione: yeah, mostly
<ogra_live> i currently run i386 on amd64 .... will switch soon
<daniels> just need to get it networked
<fabbione> daniels: ah nice :)
<Mithrandir> ogra_live: the oops is known, and I know about the missing language stuff.  I guess I'll get around to that at the end of the week.
<Mithrandir> Kamion: I have an implementation of simplifiedlive with devmapper now.  Untested, though.
<ogra_live> oh, and a daniels thingie, my widescreen display isnt detected properly
<ogra_live> i run at 1024x768 here
* lamont screams at debootstrap
<daniels> ogra_live: bug report with xresprobe output and Xorg.0.log please
<ogra_live> will do, but now the next arch test first ... i'll come back to this
<Kamion> Mithrandir: hooray
<Mithrandir> Kamion: new-casper is really nice to work with.  A fair amount of cleanups still needed, but I like it.
<ogra_live> fine fine ....
<ogra_live> Kamion, edubuntu amd64 has the same bugs, fine too
<doko> elmo: please sync gjdoc, java-gcj-compat, pwlib, openh323, overwriting ubuntu changes
<ogra_live> Kamion, one thing i noted (didnt test on i386) was that i have no 1024x768 mode in the bootloader
<dholbach> good night everybody
<seth_k|lappy> night dholbach :)
<Nafallo> infinity, lamont: give-back gnome-phone-manager everywhere pretty please :-)
<ssam> daniels, you closed bug #20191 about via drivers yesterday, xorg still wont start for me with the fight2 live cd.
<ssam> daniels, did the fix not make flight2?
<Nafallo> daniels: ehm, dude! when did you give me Direct Rendering? :-)
* Nafallo didn't notice ;-)
* ..[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 | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | Flight CD 2 released
<eruin> Nafallo, on what? ;)
<doko> elmo: please "sync" cyrus22-imapd from experimental
<Nafallo> eruin: ATI Mobility Radeon 9700
<eruin> oh...? the ati driver?
<Nafallo> yea. with r300 support :-)
<eruin> that sounds lovely... that means I can run openttd without fglrx!
<Nafallo> I've never used fglrx ;-)
<mdke> anyone know Diziet's bugzilla id?
<tseng> try ian@ubuntu.com
<mdke> thanks
<mdke> no match :(
<Nafallo> try typing ian jackson? :-)
<mdke> aha
<mdke> thanks
#ubuntu-devel 2005-12-20
<mdke> it was iwj@
<veli_> alp
<jdub> golly, X uploads are entertaining now
<Keybuk> oh?
<Keybuk> what's broken today?
<jdub> oh, dunno, just entertained by buttloads of change mails instead of one lonely one ;)
<Nafallo> hehe :-)
<Keybuk> mmm, "butt loads"
<Nafallo> it's only 155+ no? :-)
<ogra> seb128, still here ? 
<seb128> ogra: pong
<Keybuk> is it bad when you laugh out loud at kernel changelogs?
<jdub> elmo: http://cdimages.ubuntu.com/ -> bizarre! (haw haw)
<mdke> Keybuk, you know the answer
<jdub> hahaha: http://geekz.co.uk/lovesraymond/archive/linux-doomsday
<mdke> hey jdub, did you make any progress on the planet ubuntu synching thing?
<jdub> not yet
<mdke> jdub, :( is it a tricky problem?
<jdub> last time i checked, yes
<mdke> argh
<mdke> jdub, you can't just get direct access to the server and work your stuff directly there?
<tseng> mdke: i am guessing youve never met elmo 
<mdke> tseng, well I know that people have write access to certain files on the servers
<mdke> but no, i haven't met him
<mdke> but it would only be write access to one file tbh ;)
<jdub> dude, i've explained before that it's not as simple as that, kthxbye, etc.
<mdke> jdub, ok chill i was just making a suggestion, don't forget it's been broken for several months now. i was just trying to help
<mdke> we set up a planet on ubuntu-it recently, and it was as simple as that
<mdke> but no more shall be said from now on, sorry
<Nafallo> infinity: ping
<infinity> Nafallo : Pong.
<Nafallo> infinity: did you say pkg-config was the fault and not linuxdcpp?
<Nafallo> infinity: and ehm, could you give-back gnome-phone-manager? :-)
<infinity> I was jumping the gun.  SOMETHING is to blame, but I'm not quite sure who.  The environment is getting an impossible variable set, which is upsetting the shell.
<Nafallo> if it's not scons, and not pkg-config. what could it be? :-P
<Nafallo> AND it builds fine in pbuilder ;-)
<infinity> Yeah, I'll need to strace it and see who's setting that variable and why.
<infinity> Patience.  This isn't the only thing I have to do today. :)
<Nafallo> hehe, no problem. I have it build already and it just segfaults all the time anyway ;-)
<Nafallo> infinity: thanks for give-back btw
<jdub> anyone have a nice picture of an egg?
<jdub> preferably with a plain white background
<jdub> ooh, machine locks up on boot now
<jdub> fun
* ajmitch spots the server team announcement..
<jdub> immediately after shpchp is loaded (according to verbose recovery boot)
<jsgotangco> ajmitch, HEAVY METAL
<jdub> hrm, even -7 halts at detecting and activating hardware
<jdub> d'oh
<jdub> guess it's boot'n'chroot time whenever this gets fixed ;-)
<jdub> or reroot the livecd..
<mojo> hmm, weird, I already removed OOo from my Dapper, and I install a new language using Language Selector and it install translation pack for OOo, Bugs? or Non-implemented issue?
<slomo_> lamont-away, infinity: please give-back mono on ppc
<infinity> slomo_ : Same segv failure the second time.
<pitti> Good morning
<pitti> infinity: the new make version in Debian seems to fix cdbs; shall we sync it?
<desrt> pitti; did you get that launchpad bug i assigned to you a bit back?
<pitti> desrt: Hi! not sure which bug you mean
<desrt> pitti; gpg
<pitti> desrt: I mostly neglected my bug mail this week, too much security stuff
<desrt> not pushing for a resoution... i just seriously don't know how launchpad works :p
<pitti> desrt: yes, I saw some gpg issue
<desrt> ah.  excellent.  that's all i wanted to know :)
<pitti> #570
<pitti> #5570 even
<desrt> yes.  that one.
<infinity> pitti : Up to you.  If you've tested this theory, go ahead.
<desrt> obviously no rush... pretty minor
<pitti> infinity: at least all *my* packages work now again
<pitti> infinity: flight-2 is out, let's challenge our luck :)
<infinity> You maintain CDBS packages?
<infinity> Eww.
<pitti> infinity: packages that use cdbs, yes
<infinity> I don't love you anymore.
<desrt> infinity; he maintains HAL.  the worst cdbs package of all.
<pitti> desrt: I doubt that; cups is definitively worse
<desrt> but i never feel the desire to hack cups so it doesn't affect me :)
<pitti> although I still want to refuse that I maintain cups, but reality teaches me another thing
<infinity> I deny maintaining everything with my name in the maintainer or uploaders field, it's easy.
<infinity> "Say Adam, do you maintai--" ... "NO!  Piss off!" ... "Uhh, ooookay... <slowly backing away>"
<infinity> Speaking of...
<infinity> pitti : I accidentally joined the Debian Berkeley DB team earlier today, so if you have any pet bugs in libdb* (other than their existance), let me know.
<pitti> heh
<pitti> infinity: I usually try to stay away from libdb as far as I can, and none of my packages use them, so I don't really have any particular ones
<infinity> Ahh, lucky you.
<pitti> infinity: but speaking of which, is 4.3 or 4.4 the true db we should go for in dapper?
<infinity> libdb and I have a long history with apache, php, and subversion, so it just made sense to take the lib too.
<pitti> seeing that there was yet another version made me cty
<infinity> pitti : I've just been discussing this in #debian-release.
* fabbione suggests to stay with 4.
<fabbione> 3
<pitti> wow, Debian's first kernel security update since sarge
<infinity> pitti : Trying to convince the world to switch to 4.4.. If I can get Debian buy-in, then we can switch easily.
<infinity> pitti : If Debian's not moving, I don't want to become gratuitously incompatible (for packages that use translation logs)
<pitti> infinity: right, packages that use transactions are hard to convert anyway? so we'll probably need to keep 4.3 and 3
<pitti> erm, s/4.3/4.2/
<infinity> Don't see why.
<infinity> Anyone with 4.2 installed from breezy won't have it magically removed on upgrade.
<pitti> infinity: is there any upgrade tool from upstream that can convert log files?
<infinity> Oh, except for aptitude users.  They lose, I guess.
<pitti> infinity: no, but if we build new packages against 4.3, then upgrading that package will break data compatibility
<infinity> Nothing I've found yet.  We have an icky README in subvesion.
<infinity> subversion, too.
<infinity> Very few packages actually use transaction logs.
<infinity> SVN is one of the few, but the bump seems less scary when you consider that FSFS (not BDB) has been the default repo format for ages now.
<pitti> infinity: evolution does at least in the code, but I haven't found log files on the disk, so we might be lucky
<infinity> If I had some spare time, I could probably write an upgrade tool that didn't suck too terribly much.
<infinity> Yeah, "use transactions" != "use transaction logs"
<pitti> infinity: oh, the number of packages that use 4.2 has dropped drastically
<infinity> BDB lets you do transactions in memory, which is a lot more common.
<pitti> drac, exim4, openldap2[.2] , OO.o, php5
<infinity> php5 is building here.
<pitti> right, that should be fine
<infinity> For about the 30th time.
<infinity> exim4 is pain-free to upgrade, we should just do it.
<pitti> oh, and apache2
<infinity> It already has logic to wipe out incompatible DB hashfiles on upgrade, IIRC.
<infinity> apache2 already switched.
<pitti> oh, it just appeared in melanie?
<infinity> ...
<pitti> ** libapache2-mod-perl2 has an unsatisfied dependency on amd64: libdb4.2
<infinity> Oh, mod_perl2 != apache2
<infinity> Scare me like that....
<pitti> ah, sorry
<infinity> mod_perl2 can be rebuilt easily enough.
<infinity> Uploading an Xbuild1 should magically fix it, in fact.
<infinity> It doesn't directly build-dep on libdb.
<infinity> (Which means it probably shouldn't link it either, but whatever)
<pitti> yeah, one of those excess dependencies vorlon complained about
<pitti> *sigh* XSS in mod_imap
<infinity> Yeah.  I'll sort that later.  For now, it can just be rebuilt.
<infinity> mod_imap as in ImageMap, not mail, right?
<pitti> yes
<infinity> Man.  I didn't think anyone even used server side image maps anymore.
<infinity> In fact, I'll bet no one does.
<infinity> Oh well.  Forward me the report, I'll fix up apache*
<pitti> infinity: let's do php first
<fabbione> pitti++
<fabbione> infinity: i need php5 for -server too
<infinity> It's a few dozen test builds into maybe being done.. Ish. :)
<infinity> PHP and I are having some philosophical arguments.
<infinity> Mostly about how much I should hate upstream.
<StevenK> Poor infinity. He changes distribution, and *still* can't get php off him.
<infinity> Now I just maintain it for two. :)
<infinity> It's okay.  I don't actually mind that much.  It gives me something petty to complain about.
<StevenK> Heh
<StevenK> For you that would be a plus side, wouldn't it? :-P
<infinity> beats complaining about things of consequence, which almost invariably leads to pissing off a lot of people in the process.
<infinity> Anyhow, back to my petty PHP problems.
<dholbach> good morning developers
<desrt> good morning, kind sir
<kagou> hi
<kagou> who can i contact here to delete a login in the wiki and in launchpad ?
<fabbione> kagou: ask in #launchpad
<fabbione> they might be able to help you
<kagou> oh thanks fabbione , sorry i didn't know this chan
<fabbione> no problem
<pitti> fabbione: oh, btw, I meant 'let's do the php security update first', not dapper stuff :)
<fabbione> pitti--
<daniels> ssam: it didn't make flight 2, no
<daniels> Nafallo_away: i've always rocked
<pitti> I'll quickly test the live CD before the distro meeting, brb
<sivang> infinity: what sort of philosophical arguments? :)
<sivang> morning ,btw
<pitti_live> daniels: here?
<daniels> X IS NOT BROKEN
<daniels> I REFUSE TO HEAR OTHERWISE
<siretart> morning daniels :)
<hunger_> daniels: Indeed: It works for me (TM)
<Mithrandir> daniels: it gives me shit on my 6600GT with the free driver. :-)
<daniels> Mithrandir: that's your fault for using a card that's not intel
<jbailey> daniels: Right.  My bug with it hanging appears to be a kernel bug. =/
<daniels> jbailey: score :)
<pitti_live> daniels: In earlier versions I always got a video mode question, now the current live cd didn't ask and set up 1024x768; but my TFT is 1280x1024
<daniels> pitti_live: uhm ... the xorg source package hasn't changed since breezy :)
<daniels> pitti_live: xorg.0.log and xresprobe output pls :)
<daniels> jesus, too many smileys :)
<Mithrandir> the current live cd doesn't have any interactive infrastructure at all.
<daniels> oh
<daniels> score, SEP
<Mithrandir> nah, you should just always guess the right resolution.
<dholbach> brb
<pitti_live> Mithrandir: ok, seems that this is just an arbitrary default then?
<daniels> Mithrandir: we would, if you would fix xresprobe already :P
<daniels> pitti_live: actually, I know what the problem is
<pitti_live> anyway, booting back to normal system, distro meeting starts soon
<pitti_live> daniels: great. what is it?
<daniels> for some reason, we don't pick up on the EDID input flag
<daniels> so we always pick LCDs as CRTs
<daniels> i can't debug it because tollef hasn't made ddcprobe work on amd64 yet :P
<Mithrandir> daniels: I'm waiting for mjg59 to upload the fixed vbetool so I can nab the emulation code.
<daniels> or maybe it's because I'm shit and forgot to port ddcprobe to vbetool
<daniels> oh, right
<daniels> either way
<pitti_live> ok, brb
<pitti_live> thanks
<daniels> np
<pitti> daniels: btw, do you plan to move the magic of xserver-xorg to -core? it is inconvenient to fix /etc/X11/X when I remove xserver-xorg
<daniels> pitti: no immediate plans, largely because I can't be fucked dealing with all that debconf template migration entails
<pitti> oh, he
<daniels> i have more pressing stuff, like fixing the configuration so people other than me can understand it ;)
<pitti> I just wondered about the purpose of splitting out drivers when I can't uninstall them
<pitti> well, now I did uninstall all but the ones I need, but maybe that should be supported better
<daniels> pitti: it was more for ease of mainenance and updates than for people to be able to uninstall stuff
<pitti> anyway, not urgent at all, thanks
<daniels> ubuntu-desktop would still depend on the full compliment anyway ...
<pitti> daniels: right, but that's generally first against the wall anyway :)
<daniels> heh
<Diziet> Urhg, another problem with getting up this early is that my mirror is running and will be for some hours yet ...
<daniels> (seriously, systemic flaws in automake are derailing us now.  i hate all build systems.)
<jbailey> daniels: How so?  Automake lets your override each rule if you feel like it/
<daniels> jbailey: distcheck builds with DESTDIR= prefix=_inst/ first
<daniels> which is completely SUCK, because any path not relative to prefix gets boned
<jbailey> daniels: You guys install to absolute paths?
<daniels> jbailey: absolutely
<daniels> jbailey: we get the app-defaults directory out of pkg-config
<jbailey> =)
<jbailey> Mmm, joy.
<daniels> (sort of defeats the purpose of having it there if you make it relative to $(prefix))
<daniels> in any case, that's what DESTDIR is *for* :P
<jbailey> Right.
<sivang> Diziet: you're using another nick for the meeting? :)
<daniels> sivang: multiple irc channels are hard, let's go shopping
<sivang> daniels: huh ? 
<Diziet> sivang: What daniels said.  But s/shopping/back to sleep/
<sivang> ok :)
<pitti> Riddell: do you have a demo PDF that breaks with the patch? I tested evince and xpdf with several different types of complex PDFs, and none of them choked
<pitti> Riddell: ah, wait, that change was in the gmallocn() function, right?
<pitti> Riddell: because at the places I fixed for the 3.00 code, 0 byte allocs didn't make sense
<Riddell> pitti: http://kubuntu.org/~jr/tmp/break-kpdf.pdf
<doko> infinity: please requeue openal on i386
<pitti> Riddell: that works fine here in evince/xpdf
<Riddell> was definatly give out "Bogus" before, not sure which "Bogus" it was breaking on
<pitti> Riddell: ok, as I mailed, changing to < 0 is fine
<pitti> I'm just scared of 0 byte allocations
<infinity> doko : Done.
* infinity -> dinner.
<pitti> seb128: btw, regarding tight arch: any <-> all dependencies
<pitti> seb128: this probably affects many -common packages for translations only?
<Kamion> ogra: if you don't get a 1024x768 mode in the bootloader, that's because your VESA VBE table doesn't list it (at least not with >= 16-bit colour)
<Kamion> (and with framebuffer support)
<Kamion> ogra: is Edubuntu good to release? I can do that before I run away
<ogra> Kamion, it works on install 
<ogra> Kamion, powerpc install isnt tested (still waiting for my iMac to be shipped), the rest is good to go
<Kamion> I'll release it, you can note that powerpc is untested
<Kamion> lives working?
<ogra> yup
<Kamion> ogra: release announcement is hereby your job, though :)
<ogra> yup, will do ...
<Kamion> (but wait a bit)
<seb128> pitti: -common tend to have the -schemas with the default settings too
<ogra> but now i need some sleep, getting ppc took me until 4am .... my line dropped all the time ... didnt get much sleep
<seb128> pitti: we don't use a Depends for translations only
<jsgotangco> ogra, do you need testing for amd64?
<ogra> jsgotangco, nope, thats done 
<jsgotangco> i can download it now and give you a report later
<jsgotangco> ahh k
<ogra> and ppc install will surely still have the same bug as in breezy
<Kamion> ogra: just before you go, I'm publishing it now and will ping maswan for mirroring
* jsgotangco doesnt have a ppc sorry
<ogra> Kamion, thanks :)
<Kamion> ogra: please wait for the Swedish mirror to update and link to it first in the announcement
<Kamion> ogra: we've been having some bandwidth problems in the DC, and maswan is more than happy to make our lives easier in that respect
<ogra> Kamion, i'll announce in the evening, should be safe
<Kamion> ok
<jsgotangco> ogra, just tested oem mode of flight2, i made a hardware test, I got stuck at Network test and it says "Is your mouse working properly"
<Treenaks> your networked mouse?
<jsgotangco> in my laptop
<ogra> jsgotangco, might be, hwdb is on my list for fixes, but i didnt care for it yet
<jsgotangco> ahh k
<ogra> it didnt work in breezy either
<jsgotangco> just to let you know
<ogra> yup
<ogra> i wasnt assuming it had changed :)
<ogra> thanks for the proof :)
<janimo> Riddell, is kubuntu-docs still using dpkg-divert for ff about page?
<infinity> janimo : It uses update-alternatives
<janimo> yay
<janimo> that's better i think
<janimo> thanks
<Riddell> janimo: yes
<jsgotangco> wow
<jsgotangco> is oem borked?
<janimo> Riddell, what infinity said?
<infinity> janimo : http://changelogs.ubuntu.com/changelogs/pool/main/k/kubuntu-docs/kubuntu-docs_5.10-0.9/changelog
<infinity> janimo : When \sh says "set symlink", he means "update the alternative".  I know, cause I had to fix the code. :)
<janimo> inifinity, ok thanks
<janimo> I was following the changelogs but nowhere did I see get rid of divert for good
<janimo> getting the source now
<infinity> janimo : The diversion should be removed when the old package is removed.
<infinity> janimo : Assuming the old package properly removed the diversion in it's removal scripts.
<janimo> I am trying to add another about page for xubuntu
<janimo> and am afraid 3 packages diverting eachother may lead to a mess
<infinity> Yes, hence why alternatives are better.
<janimo> so am trying to wrap my head aroubd divert and altenatives
<infinity> You can't divert the same file twice.  dpkg won't let you.
<Treenaks> janimo: but you keep getting diverted? :)
<infinity> But once kubuntu-docs is upgraded, the old diversion goes away.
<janimo> so will just do what kubuntu does and all is good?
<Kamion> ogra: Edubuntu Flight CD 2 publishing to mirrors; announcing in the evening's good
<janimo> Treenaks, haven't tried yet I thiught I'd ask here first :)
<jsgotangco> yay
<jsgotangco> Kamion, is oem install borked?
<Kamion> jsgotangco: almost certainly yes
<jsgotangco> I had to add my first user on the console
<Kamion> I haven't updated it for new tzsetup and user-setup
<jsgotangco> i see
<Kamion> at the moment it's low-priority; I'll fix it eventually
<Kamion> meant to mention it in the release notes but forgot, sorry
<Mithrandir> Kamion: is user-setup in the live seed yet?
<jsgotangco> np just been testing oem a lot lately
<Mithrandir> Kamion: and how am I supposed to use it?
<Kamion> Mithrandir: don't think so; there's no .deb yet
<Mithrandir> Kamion: ook.
<Kamion> Mithrandir: my loose plan is to rename user-setup to user-setup-ask and add a user-setup program that does user-setup-ask && user-setup-apply and is only in the .deb
<infinity> janimo : Err, oh.  I lied.  \sh didn't use an alternative, he actually sets the symlink by hand.  ARGH.
<infinity> janimo : Remind me to smack him for that later, and fix stuff up.  I'm off to dinner first.
<infinity> janimo : Ask me again later, and I'll tell you the RIGHT way to do it, which will involve co-ordinating an alternative with ubuntu-docs, etc.
<Kamion> Mithrandir: but I'm not going to look at it today. :-)
<janimo> infinity, ok I'll wait till it's sorted out in kubuntu, then I'll do exactly the same for xu ok? thanks
<infinity> janimo : Yeah, that should work fine. :)
* infinity assumed he was using update-alternatives, cause he couldn't fathom anyone doing tha by hand...
<Mithrandir> Kamion: sure, no hurry.
<infinity> \sh_away : When I get back from dinner, poke me so I can yell at you for a bit.  Thanks.
<Mithrandir> Kamion: I need to add a mechanism for on-first-boot-do-reconfigure which will be used by the live cd.
<Mithrandir> since the xorg configuration is entirely noninteractive ATM
<jdub> infinity: my machine halts at shpchp (according to verbose kernel output) during startup, with -8 and -7 -> seen that?
<Kamion> maswan: Could you please kick off a mirror run for Edubuntu flight-2? Thanks ...
<ogra> Kamion, thanks a lot :)
<maswan> Kamion: running
<maswan> and, whee, it installs, even if alsa doesn't work and stuff. :)
<jdub> infinity: usplash needs to depend on a new version of initramfs-tools
<Kamion> maswan: ta
<JaneW> seb128: ping
<seb128> JaneW: pong
<Kamion> maswan: has flight-2 noticeably affected bandwidth?
<JaneW> seb128: I am doing the report and just found "seb128 hide-admin-tools-to-users: has been implemented previous week but the summary of the previous meeting has no mention of what I wrote on it, should I mention it again?"
<JaneW> seb128: so is it implemented? LP doesn't say so
<JaneW> seb128: let me know what to put in there please...
<maswan> Kamion: nope, not yet: http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en
<maswan> Kamion: a bit too early to say how today is going to ramp up (or not) though
<seb128> JaneW: it was "implemented, waiting on mvo to make some .desktop changes to be 100% done", which he did ... so yeah, I've forgotten to change it
<mvo> seb128: are there any left?
<JaneW> seb128: can I set it for you?
<seb128> mvo: have you uploaded synaptic/g-a-i/update-manager
<seb128> JaneW: sure, thank you!
<JaneW> np :)
<JaneW> done
<seb128> cool
<mvo> seb128: yes and language-selector
<seb128> mvo: k; so it's alright :)
<StevenK> Blah.
<StevenK> wnn6-sdk is still broken.
<StevenK> The 1.0.0-13 source exists in the archive, but the packages are still 1.0.0-12, which are broken.
<pitti> bah - with mdz and Kamion being away, do we have anybody who can promote packages to main?
<pitti> elmo: do you promote packages?
<elmo> pitti: I can, sure - as long as they're reasonably obvious
<pitti> elmo: five language-support packages are uninstallable because some new firefox locales are still in universe
<pitti> elmo: I'd say this qualifies as 'obvious'
<pitti> ozilla-firefox-locale-ar mozilla-firefox-locale-bg-bg mozilla-firefox-locale-gu-in mozilla-firefox-locale-mk-mk mozilla-firefox-locale-pa-in
<elmo> pitti: yes - done
<pitti> elmo: thank you
* StevenK wonders what to do about wnn6-sdk.
<Nafallo> -ENOKEYBUK?
<Nafallo> morning btw
<StevenK> He quit seven hours ago.
<Nafallo> hm, he should be awake again any minute then ;-)
<Nafallo> thanks StevenK :-)
<dholbach> the new live cd ROCKS, it looks fancy - although ubuntu-livecd does some kde stuff and it doesn't find /etc/X11/xorg.conf (just a warning) and the kernel oops'es, it runs just fine :-))
<Mithrandir> dholbach: \o/ :-)
<dholbach> and it's fast
<dholbach> wow
* dholbach hugs everybody involved
* dholbach starts off with http://wiki.ubuntu.com/Testing/Short
<Nafallo> aha. if it doesn't find /etc/X11/xorg.conf that explains alot :-P
<dholbach> it's just a warning
<Mithrandir> Nafallo: nah, it's just the xserver-xorg reconfigure which complains
<dholbach> come on... who needs config files these days? :)
<Nafallo> I had 1024x768 instead of 1280x800 :-P
<Mithrandir> Nafallo: fix ddcprobe to work on amd64 and it'll work correctly, kthxbye
<Mithrandir> :-)
<Nafallo> hehe
<Mithrandir> Nafallo: or wait until I've fixed the rest of the cd to do all the crack it's supposed to do, like keymaps/languages
<Nafallo> Mithrandir: that's my plan indeed :-)
<Mithrandir> dholbach: the oops is known, I've asked BenC to investigate, but it's not in a place where it's easy to debug, AIUI.
<dholbach> ok
<dholbach> hmmmmm, networking doesnt work
<Nafallo> known
<dholbach> i see
<Nafallo> have you read the announcement? :-)
* dholbach whistles innocently
<Nafallo> hehe
<dholbach> apart from all that, Testing/Short passed :)
<StevenK> With what, 4 tests sucessful? :-P
<Mithrandir> I should probably speak with Keybuk about how we are to do live networking.
<StevenK> Try DHCP, try DHCP harder, give up and assign a static address of 192.168.0.1 ?
<Robot101> zeroconf! :)
<Mithrandir> 169.254 if so, but yeah.
* StevenK remembers 169.254.x.x from Windows 9x. *shiver*
<Nafallo> StevenK: networkmanager assigns 169.254. ;-)
<Nafallo> so it's just as relevant on todays gnome :-P
* StevenK bashes Nafallo with a spoon, since it's all he has to hand.
<Nafallo> hehe
<Mithrandir> StevenK: it's called link-local and is specified in the relevant RFCs
<maswan> dholbach: from http://wiki.ubuntu.com/Testing/Short what should you do when you find lots of errors?
* StevenK nods.
<StevenK> Mithrandir: I know, I know.
* StevenK ponders a push-model authenication method for his machines.
<dholbach> maswan: you could have a look at https://wiki.ubuntu.com/Testing/Introduction and https://wiki.ubuntu.com/Testing/Current :-)
<dholbach> maswan: or http://wiki.ubuntu.com/Testing in 
<dholbach> maswan: i need to make the testing thing more public
<dholbach> maswan: but thanks for caring enough for it :)
<maswan> dholbach: Do you care enough to get a testing protocol form Short and file bugs from that?
<dholbach> maswan: i think it'd make sense, if people would file bugs on their own and link them on that page. alone the fact, that stuff happens on *their* box.
<maswan> dholbach: ok
* maswan reports the few obvious bugs then
<dholbach> did anybody else suddenly have to add libxdmcp-dev as a build-dep?
<Nafallo> dholbach: yes. on gnome-power-manager and network-manager
<dholbach> hrmhrmhrmhrmhrm
<dholbach> had to do it on timer-applet now too
<pitti> BenC: do you have some minutes today to talk about that eject bug? (#5049) I made some further investigations and I think I came closer to the root of the problem
<pitti> BenC: today I also have borrowed a device that reproduces the problem
<maswan> dholbach: testing/Short might want to check keyboard layout as well as resolution in the default session
<dholbach> maswan: oh yes, that's a good point
<dholbach> thank you
* maswan goes to file a bug regarding that anyway :)
<ogra> Nafallo, huh? what ? when was that added to gnome-power-amanger ? 
<Nafallo> ogra: good catch. gnome-phone-manager I meant :-P
<ogra> ah
<Nafallo> dholbach: ^ ;-)
<ogra> k .... :)
<Nafallo> yesterday I wrote gnome-php-manager, so I'm advancing to packages that exists atleast ;-)
<dholbach> i'm going nuts in here... they have been drilling the whole morning now - i wonder how much of the walls are left in this place
<Nafallo> dholbach: I know _that_ feeling.
<StevenK> dholbach: None - it's being held up with love and good luck.
<Nafallo> they changed all the balconys last spring here.
* dholbach will move to the caf later on and work from there ;)
<Nafallo> good idea :-)
<Nafallo> I should go shower, screw my bed and some stuff. later.
<Mithrandir> screw your bed? :-)
* Simira prefers to screw _in_ the bed...
* dholbach is reminded of jdub saying "work it, baby" in Montral :)
<Treenaks> The LugRadio guys are asking for voicemails: +44 870 931 1730 -> <Xalior> everyone phone up and shout "ubuntu" and hang up, with no name. Okay?
<HiddenWolf> hahaha.
<StevenK> Ouch. STD call to England.
<Treenaks> (oh, yeah, it's an international call for everyone outside the UK)
<StevenK> The +44 gave that away. :-P
<Treenaks> StevenK: Not everyone might be awake enough ;)
<Mithrandir> what, you pay for calls to the UK? :-)
* Mithrandir hugs his voip provider
<ssam> i am sure if you email lugradio an ogg they use that. they just get bored of reading emails
<Treenaks> ssam: sure :)
* StevenK tries looking harder for tools that pull users out of an LDAP database and push changes to clients without using the abominations of lib{nss,pam}-ldap.
<Robot101> StevenK: er, isn't that what debian does?
<Robot101> userdir-ldap
<StevenK> Yup. But userdir-ldap's code is *HORRID*
<StevenK> So, uh, I don't want to use it.
<Robot101> me and robster wrote something to sit on a postgres trigger and slurp a query into a flatfile when it gets triggered
<Robot101> to get rid of crap like lib{nss,pam}-pgsql (you thought the LDAP ones were bad? ha!)
* StevenK nods - lib{nss,pam}-{my,pg}sql are much much much worse.
<StevenK> I have *vague* recolections of an ITP, but I can't remember any specifics. :-/
<dholbach> ok, why does half the world now have a missing dependency on libxdmpc-dev? :(
<ogra> we dont even support xdmcp by default
<ogra> you could as well drop it :)
<Mithrandir> ogra: apart from Xnest segfaulting at me, it suppported xdmcp just fine last time I tried.
<ogra> hm, xnest, didnt think of that ... the default X config has the nolisten tcp option enabled ...
<Robot101> ogra: it's 1 line in gdm.conf, works fine
<Mithrandir> ogra: yes, and? :-)  That's it's not enabled out of the box doesn't mean it's not supported
<ogra> sure, but still, why link half the world with xdmcp ... it should die imho in times of ssh -X :)
<ogra> Mithrandir, while youre here ... did you note the change in the dhcp 3.0.3 server ? 
<ogra> i'd like a opinion....
<ogra> (of someone familiar enough with networking stuff ...)
<Robot101> Diziet: how's the nameserver coming? :)
<Mithrandir> ogra: no, what was that change?
<ogra> they let the 'siaddr' field default to 0.0.0.0 now because of a silly interpretation of http://www.faqs.org/rfcs/rfc2131.html
<ogra> so the world of nfs mounted root filesystems breaks completely 
<ogra> i.e. ltsp
<ogra> ou now have to specify an IP for the next-server directive ....
<Mithrandir> that's an entirely reasonable interpretation, imo
<ogra> and i try to consider how evil it is to patch our dhcpd to have an option like "next-server self;" that restores the old behavior
<Mithrandir> that would mean it broke if you had a machine named self
<ogra> its evil if you rely on the tftpd being the nfs server like it was the last $n years
<ogra> i dont instist on "self" 
<Diziet> robot101: I've been a bit busy the last few months :-).
<ogra> might also be a completely different name for the option, the patch would be a 4 line if construct
<Mithrandir> I've routinely run setups where dhcp, tftp and nfs server have been three different servers.
<Robot101> Diziet: hmm, snap :)
<Robot101> argh
* Robot101 mauls Opodo with a chainsaw
<ogra> ah, k ... so you always had set the next-server anyway
<Robot101> why did you give me a session for the front page, so that after I put my flight details in, you give me an expired session page
<Robot101> bastards
<Mithrandir> I have, yes, but I see that your point makes sense in small setups.
<ogra> it breaks nearly all ltsp setups in the world :)
<ogra> not only ours 
<ogra> and the rfc doesnt talk anywhere about zeroing the value, so i dont understand the dcision to change it at all
<Diziet> Why not fix the dhcpd to DTRT again ?
<ogra> but i know the ltsp guys have heavily argued with dhcp upstream who insists it must be 0.0.0.0
<Mithrandir> can't we ask dhcp upstream to have something like next-server self?
<ogra> Diziet, because i didnt know how evil it would be, thats why i'm asking here ;)
<Diziet> I'm a bit of an RFC-laywer.  Where can I read the discussion with upstream ?
<ogra> Diziet, i'll ask jammcq if he'S up (US eastern)
<ogra> he had that discussion
<Diziet> Um, I don't want to have the discussion again.  I want to read it.
<Diziet> Please don't tell me it was on IRC.
<ogra> i dont think so, but i dont know on which ML it was
<infinity> A DHCP server may return its own address in the
<infinity>    'siaddr' field, if the server is prepared to supply the next
<infinity>    bootstrap service (e.g., delivery of an operating system executable
<infinity>    image).
<ogra> or if it was private mail traffic with them
<infinity> (bot not if it isn't) <-- My emphasis.
<infinity> dhcpd has no way of knowing it's also a valid tftp server, unless you tell it that it is.
<infinity> (ie: by setting next-server)
<Diziet> Right, so how do we tell the dhcpd ?
<ogra> DHCP clarifies the interpretation of the 'siaddr' field as the
<ogra>    address of the server to use in the next step of the client's
<ogra>    bootstrap process.  A DHCP server may return its own address in the
<ogra>    'siaddr' field, if the server is prepared to supply the next
<ogra>    bootstrap service (e.g., delivery of an operating system executable
<ogra>    image).  A DHCP server always returns its own address in the 'server
<Diziet> So the only change upstream is that they changed the default not to set siaddr.
<ogra>    identifier' option.
<ogra> from http://www.faqs.org/rfcs/rfc2131.html
<infinity> ogra : I just qupted that same paragraph, dude.
<infinity> quoted, too.
<ogra> infinity, nope, you missed the last sentence :)
<Diziet> `siaddr' != `server identifier option'
<infinity> ogra : "May (blah blah) if (blah blah)."  Your if statement isn't true (as far as dhcpd is concenred)
<ogra> :)
<infinity> ogra : What Diziet said.  siaddr and server identifier are two different things.  The latter ends up in the lease just fine with dhcpd3.
<ogra> but it doesnt say it must be zeroed
<infinity> May return it's own address IF...
<Diziet> Well what else should it be set to ?
<infinity> You can read that backwards as "may NOT return its own address if NOT..."
<ogra> the server address, like it was the last years
<Mithrandir> ogra: it would be worse if it was a random address, wouldn't it?
<Diziet> I'm afraid I think I agree with upstream.
<ogra> Mithrandir, sure, thats not my point
<infinity> ogra : Seriously, patch dhcpd3 to allow a keyword for "my-own-ip", and use that for next-server, and you're set.
<Diziet> OTOH you might well say that `usually in our installation the dhcp server is also the tftp server so we will set siaddr to our own host by default'.
<Mithrandir> what infty says.
<ogra> infinity, thanks, thats an answer i was looking for :)
<Diziet> But what infinity suggests is sane too.
<infinity> ogra : Telling upstream their interpretation of the RFC is wrong is.. Well.. Wrong.  Saying they can't fix implementation bugs on major version increases is also wrong, no matter how much it hurts you.
<ogra> i just wanted o know how evil it would be 
<Diziet> infinity: Note that the RFC just says how a specific server should behave.
<Diziet> It doesn't say what the default for an implementation should be.
<ogra> exactly ...
<ogra> and breaking behavior lots of people rely on is evil imho
<infinity> I read that as "if siaddr is set to your own IP, and you're NOT a valid bootstrap server, you're doing the wrong thing"
<Diziet> So I think making the default be the way it used to be would be justifiable if we think that it's usually (or nearly always) the case that `we' are the next-server.
<maswan> IMO the ltsp install/config stuff should explicitly set next-server
<Diziet> infinity: Indeed, yes.
<infinity> Which means dhcpd2 on all servers without tftp images is "wrong.
<Mithrandir> in other news, unionfs vs devmapper on the live cd is 326 vs 367 seconds before the system settles.
<ogra> maswan, sure, thats ok for new installs
<Diziet> But _who_ is doing the wrong thing ?  The dhcpd admin or the software implementor ?
<maswan> ogra: And if you do a major version upgrade, you're going to upgrade the config stuff too, right?
<ogra> nope
<ogra> why should  i
<infinity> Diziet : There are more dhcp servers out there that aren't tftp setups, so I'd say the defalt in 3.x is correct, not 2.x
<Diziet> The other question is: what harm does it do to put a value there if it should be 0.0.0.0 ?
<ogra> the ip and range for thin clients didnt change on an upgrade, i wont touch the admins config
<infinity> Diziet : Explicitely having to blank next-server to be "correct" seems more wrong than having to set it if you need it.
* infinity notes that he's always set next-server, not realising that dhcpd 2.0 would have done it for him anyway)
<Mithrandir> Diziet: system which uses it if it's set but acts differently if it's unset?
<Diziet> mithrandir: Well, yes, but, which systems are those ?
<Mithrandir> say, a thick client which can boot off netboot or local media, deciding based on if nextaddr is set.
<Mithrandir> next-server, sorry
<infinity> Well, most won't act without also having a filename to act on.
<Diziet> filename> Indeed so.
<Diziet> (Although I have some X terminals here that have their own idea of filename.)
<infinity> But some older UNIX workstations may have defaulted to a default filename (I think my Alpha system did)
<Mithrandir> sun sparcstations look for their hostaddr
<infinity> Right.
<Diziet> I think that particularly for old installations changing the behaviour is wrong.
<Diziet> Perhaps we should revert upstream's patch to the code but make the default config file set it to 0.0.0.0.
<infinity> Well, we're not forcing the upgrade on anyone, are we?
<infinity> ogra : Are you forcing the 2.0 -> 3.0 upgrade with edubuntu-meta?
<infinity> ogra : If so, you pretty much have to take care of tailoring the config.
<Mithrandir> grrr, why did nautilus change behaviour to spatial again?
<ogra> nope, but a a dist upgrade will bring you 3.0.3
<infinity> In general, I figure when you do major version upgrades and sometihng changes behaviour, you get to keep both pieces.
<infinity> But if we're forcing it...
<ogra> infinity, ubuntu never had 2.0
<infinity> ogra : Oh, is this a change in 3.x -> 3.x?
<ogra> the change was from 3.0.2 -> 3.0.3
<infinity> ogra : If so, that's a different matter.  I thought it was 2.x -> 3.x
<ogra> nope
<Diziet> The other advantage of putting the code back and doing it in the config file is that the config file has something in it telling the admin what's wron.g
<infinity> Then you can definitely argue for backward compatibility issues...
<ogra> yup
<Diziet> It's possible that upstream might even agree with our approach (even though they can't easily do it themselves).
<infinity> Although, there are other options.
<infinity> Like adding a '--quirks' switch to dhcpd to makes it behave like << 3.0.3, so you can update the init script and not touch the config. :)
<Diziet> Urgh.
* infinity grins.
<infinity> I knew you'd like that.
<ogra> lol
<infinity> I still prefer upstream's (current) reading of the RFC, that's my main problem.
<Mithrandir> heh
<Diziet> infinity: Yes, I agree with you about the RFC.
<infinity> Asking them to maintain backward compatibility with what I believe is a bug just goes against my principles.
<Diziet> But with my approach in new tftpless installations we'll be complying with it.
<ogra> i think a "my-own-ip" setting is the best for now ...
<Diziet> It's only a bug in some systems.
<Diziet> That is, if it's a bug it's at least as much a _configuration bug_ as a code bug.
<ogra> Diziet, it affects a whole category of systems 
<ogra> (ltsp)
<Diziet> ogra: No, those systems are exactly those where it's _not_ a bug.
<ogra> not only in ubuntu that is
<infinity> ogra : Yes, he was suggesting you put the old feature back (so old installations work), and in new non-ltsp setups, we set next-server to 0.0.0.0
<infinity> ogra : Achieving the same effect, but without breaking upgrades...
<Diziet> That is, if we use the new upstream behaviour in an LTSP server then the LTSP server's dhcpd is now not complying with the RFC properly.
<ogra> hmm, that would mean to divert from debian, config wise .... while the my-own-ip thing would just add an option on our side ...
<Diziet> The my-own-ip thing will still break old installs, surely ?
<infinity> ogra : I think the keyword would be useful anyway, to be honest.
<infinity> But yes, you'd need to sed old installs.
<Diziet> keyword useful anyway> That's true.
<ogra> ok, i think i'll go this path ...
<Diziet> Which path ?
<Diziet> ogra: Surely we can convince Debian that this is the Right thing to do ?
<Diziet> I note that my own dhcpd here will be broken by this change.
<ogra> for our ltsp there is nothing to sed, since we additionally source a different config on boot, so it can be set in the default config file if not modified
<Diziet> So if it breaks I'll file a bug in and 5-10 years it will be closed because it was only a compatibility problem :-).
<Diziet> ogra: Ah, right.
<ogra> mdz implemented that very legant :)
* Mithrandir thinks this is a NEWS.Debian candidate.
<ogra> *elegant
<ogra> Mithrandir, its in there ... in dapper ... indeed, if i revert or change it, i'll note it there
<infinity> ogra : If you're going to add a keyword, I'd discuss it with ISC folks, and see if we can settle on a keyword they'd like (or if there's one already you don't know about)
<Diziet> ogra: Well, don't forget to send your patches etc. to the Debian BTS with an explanation.  Spin it so that `this is the right way for us to comply with upstream's correct interpretation of the RFC'.
<infinity> dhcpd.conf allows for conditionals and some limited subtitution, so it sould already be there.
<ogra> Diziet, yup
<infinity> s/sould/could/
<ogra> infinity, its not, i just have the debdiff in front of me ...
<ogra>         /* Figure out the address of the boot file server. */
<ogra> -       raw.siaddr = from;
<infinity> For instance, you may find that plugging in something like "next-server server-identifier" Just Works.
<ogra> and 
<ogra> -       memcpy (&state -> siaddr, state -> from.iabuf, sizeof state -> siaddr);
<ogra> +       memset (&state -> siaddr, 0, sizeof state -> siaddr);
<ogra> thats all
<infinity> ogra : No, I mean the ability to substitute keywords may already be there in the config parser.
<ogra> at least is wasnt added when they changed to zeros ...
<ogra> i'll inspect some more
<Mithrandir> dholbach: your feeling that the new live cd is a bit quicker is confirmed.. look at the bootcharts on http://people.ubuntu.com/~tfheen/live-bootcharts/
<Kinnison> ooh, 30 seconds faster
<ogra> that really depends ...
<ogra> you had user input before .... so this depended n the speed you hit the keys :)
<Kinnison> true
<dholbach> Mithrandir: you guys rock!
<ogra> thats an argument i have with the ltsp guys all the time.... "why do you only measure with bootchart and not include the bios" .... ally my netboot machines have a menu ;)
<Mithrandir> ogra: no.  That's devmapper vs unionfs on the new setup in both cases.
<ogra> ah, k
<Mithrandir> ogra: http://err.no/tmp/dapper-classic-livecd.png is the classic one, but it stops where init starts
<Mithrandir> ogra: so, 22 secs off before getting to init, and I'm quick with cdebconf. :-)
<ogra> thats the time i need to boot an ltsp client here :)
<ogra> http://people.ubuntu.com/~ogra/edubuntu/dapper-20051212-1.png
<BenC> pitti: still around?
<Mithrandir> ogra: you're not completely logged in at the end there.
<ogra> nope, thats to the login screen ...
<Mithrandir> ogra: .. and you don't reconfigure X and similar stuff, so it's not a very fair comparison. :-)
<ogra> sure i do
<ogra> i do the same as you do ...
<pitti> Hi BenC, yes, I am
<pitti> BenC: good morning :)
<ogra> Mithrandir, ltsp does a complete hardware detection and X configuration on boot
<BenC> pitti: good moring :)
<pitti> BenC: I made some comments to #5049
<Mithrandir> ogra: I can't see any dpkg-reconfigure xserver-xorg in your bootchart?
<ogra> Mithrandir, S32
<pitti> BenC: I would appreciate your estimation whether this could/should be fixed at the kernel level or if we rather do an userspace workaroud
<BenC> pitti: ok, reading now...
<BenC> pitti: There's a third option, and that's to evaluate the scsi commands and see if it's an eject command, and if it is, bypass the priv check
<Mithrandir> ogra: ah
<BenC> pitti: brb (10 minutes)
<pitti> BenC: hm, but shoudl normal users be able to eject internal SCSI drives? can that be used for hotswappable drives, or so?
<Mithrandir> pitti: given an incomplete language specification, say de or nb, what's the easiest way for me to make that into a sensible keymap and locale?
<Treenaks> Mithrandir: there is none ('nl' uses US keymaps, for example)
<pitti> Mithrandir: hm, it's not actually possible to map 'de' to a locale
<Mithrandir> pitti: but I need to do that, for the live cd. :-)
<pitti> Mithrandir: only as a default? there must be questions about country and keyboard anyway
<ogra> Mithrandir, why incomplete, Xog uses only de and not the locale setting ...
<ogra> *Xorg
<pitti> Mithrandir: you could arbitrarily pick any locale, probably the one of the biggest country 
<Mithrandir> ogra: because it's what I get from the bootloader, and it's not a complete locale spec?
<pitti> Mithrandir: taking de_DE.UTF-8 for de is still somewhat reasonable
<pitti> Mithrandir: but it gets impossible for pt or zh
<Mithrandir> pitti: hmm, I guess there's no file with that information, is there?
<pitti> Mithrandir: the problem is not the lack of a file
<ogra> dont we have locale.alias ? 
<pitti> it's a conceptual impossibliity
<ogra> that should have a mapping
<pitti> a language simply does  not coincide to any particular locale
<Mithrandir> pitti: in a lot of cases, it does.
<pitti> Mithrandir: ok, a proposal:
<pitti> Mithrandir: when there is only one country for a locale, use  that
<pitti> Mithrandir: and if not, ask a second question, just as the installer does
<pitti> and you need a question for the keyboard layout anyway
<pitti> we alredy tried to eliminate the keyboard questions in the warty days
<Mithrandir> pitti: I can't ask any questions
<pitti> and were taught of that being wrong the hard way
<pitti> Mithrandir: I thought you already ask for the langauge?
<Mithrandir> pitti: no, the bootloader asks
<pitti> ah, I see
<pitti> well, then the bootloader needs to grow these questions
<Mithrandir> "I" am casper here.
<pitti> heh :)
<pitti> Mithrandir: so we won't use the reduced base-config on the live cd any more, as in breezy?
<Mithrandir> pitti: as of Flight 2, we don't have any d-i bits in the live cd.
<pitti> Mithrandir: well, then the only temporary kludge I can think of is to grep the first matching locale out of /usr/share/i18n/SUPPORTED, and use the keyboard layout that matches the language
<Mithrandir> pitti: this is why flight 2 works so differently and is scary.
<pitti> this is horribly wrong for many cases, but at least you can get the further bits going
<pitti> and we need to fix gfxboot later
<pitti> Mithrandir: just pretend for now that you would get the country and the keyboard layout from the boot loader
<pitti> hi jbailey 
<Mithrandir> pitti: I guess so
<jbailey> g'm Martin
<jbailey> I'm clearly still tired.  I looked at the topic, saw the "5.10 released" and thought "What?  Really?"
<pitti> Mithrandir: '$ grep ^de_ /usr/share/i18n/SUPPORTED | head -1' delivers de_AT.UTF-8 UTF-8
<Mithrandir> pitti: does that mean all you german german users will come after me? :-)
<pitti> Mithrandir: that's wrong for the majority of German speaking people, but it's not so horribly bad to make the test CD unusalbe
<pitti> Mithrandir: I think this grep approach is good enough for the next days until gfxboot grows country/keyboard questions
<pitti> Mithrandir: I'd rather be afraid of all the Taiwanese users who get a Chinese locale
<pitti> Mithrandir: this is something you can really piss of users with :)
<Mithrandir> they're farther away than you Germans. :-)
<pitti> lol
<Mithrandir> so I have more time to fix it
<pitti> Mithrandir: I'd rather haunt you for getting a German keyboard (I use an US layout)
<Mithrandir> pitti: there's no way for me to actually get locale definitions installed into the system now?  As in, without installing packages?
<pitti> but gnome makes it easy enough to switch, so I don't mind
<pitti> Mithrandir: no, unfortunately not
<pitti> Mithrandir: we will have a discussion about this on Monday 1500 UTC
<Mithrandir> pitti: I shall nag you then, I guess
<pitti> Mithrandir: AFAICS we will probably move them back to locales
<Mithrandir> that would be nice for the live cd
<pitti> Mithrandir: it requires to rebuild all language packs, that's why it is nontrivial ATM
<pitti> but let's wait for the discussion outcome
<Mithrandir> sure
<pitti> Mithrandir: maybe you can join next Monday?
<azeem> jbailey: I have a CDBS issue.  I want to not build one package which is referenced in debian/control, without fiddling with control, by just telling CDBS not to run the debhelper scripts for that package and not create the .deb.  Is that possible?
<Mithrandir> pitti: I'll be around, yes.
<infinity> DH_OPTIONS=-npackage
<infinity> (At a guess)
<infinity> (Not a CDBS user)
<infinity> Oh, but CDBS does everything per-package, doesn't it, with -ppackage..
<infinity> I suppose -ppackage -npackage could royally confuse debhelper.
<azeem> infinity: I'll try that, thanks
<azeem> I looked for a CDBS variable for that, and overlooked that debhelper has one already
<maswan> dholbach: thanks for the test protocol suggestions, found lots of bugs
<BenC> pitti: I'm trying to compare the scsi commands that eject -s sends compared to the commands that CDROMEJECT sends
<BenC> obviously CDROMEJECT is more geared toward cdrom type devices, so that probably explains the issue
<BenC> maybe we should have a DISKEJECT or GENERICEJECT ioctl aswell
<dholbach> maswan: cool :)
<BenC> eject -s sends 2 commands (one request first for ALLOW_MEDIUM_REMOVAL)
<BenC> I see the difference, cdrom eject only sends the second command that eject -s sends
<BenC> it doesn't send the first
<maswan> dholbach: How strict should I be in applying a Y/N for Current?
<pitti> BenC: oh, but internally they are actually similar/the same?
<pitti> BenC: that's interesting
<BenC> yes
<dholbach> maswan: those Y/N are more for the installation methods, but if you found grave bugs, just use an 'N'
<BenC> maybe I should make cdrom eject more like eject -s
<maswan> dholbach: installs with issues is a Y?
<dholbach> did the installation go wrong?
<seb128> what is Y and N?
<dholbach> seb128: http://wiki.ubuntu.com/Testing/Current
<BenC> pitti: one thing that confuses me about the bug report is somone actually said they needed eject -s for an IDE cdrom :/
<seb128> dholbach: oh, k
<maswan> The installation worked, most significant bugs were two of the known issues (resolution and network)
<maswan> dholbach: So I'm guessing Y
<dholbach> yeah
<dholbach> i substracted the known issues, when i wrote 'Y'
<dholbach> :)
* dholbach -> dogwalk
<azeem> infinity: right, that don't work, it says "dh_installdirs: I have no package to build"
<dholbach> maswan: thanks for doing this seriously
<BenC> pitti: unless they had ide-scsi enabled
<infinity> azeem : Yeah, I figured it might blow up, because of CDBS's love of doing each package on its own.
<pitti> elmo: can you please sync make?
<jbailey> azeem: You need to override the package list variable.
<jbailey> azeem: I suspect that ought to be enough.
<BenC> pitti: Would you be willing to test a kernel?
<pitti> BenC: sure
<BenC> pitti: if so, what arch-flavour do you run?
<pitti> BenC: but I have to return the device tomorrow
<pitti> BenC: amd64-generic
<BenC> I can have the build done in about 45 minutes, is that ok?
<pitti> BenC: that would rock :)
<azeem> jbailey: DEB_PACKAGES?  I tried, but either I did it wrong, or it did not take effect.  Duck said you need to frob it internally
<BenC> ok
<azeem> well, DEB_*_PACKAGES, really
<jbailey> azeem: It's possible.  Been a while since I've looked at that part of the code, and I've never wanted to just do this on its own.
<pitti> BenC: I have to leave in 2.5 hours, so that should be fine
<azeem> ok, I'll look deeper then, thanks
<maswan> dholbach: Oops. I just read that Current Test CD: Flight CD1, I've been testing flight-2. Or should that perhaps be updated?
<dholbach> maswan: the latter :)
<pitti> BenC: I agree, the eject failure for proper CD-ROMs is frightening
<pitti> BenC: From what I have heard, it affects 'multi-mode' or 'enhanced' CDs, whatever that is
<Mithrandir> maswan: flight 2 is out, yes.
<dholbach> changed it
* dholbach is out for a dogwalk now... see you later
<maswan> Mithrandir: Well, I know that, just worried about messing up the test protocol thingie for flight-1
* Nafallo just had to picture dholbach on all fours :-P
* dholbach strangles Nafallo with passion :)
<Nafallo> :-)
<seb128> infinity: could you give a retry to eds build?
<seb128> evolution-data-server
<Nafallo> I'll take that as a hug ;-)
<dholbach> take it as thou wilt
<Mithrandir> dholbach: licking his face and stuff?  :-)
<dholbach> :)
* dholbach is off now :)
<Nafallo> hehe
<mjg59> seb128: New nautilus just crashes repeatedly for me
<mjg59> seb128: (Again, partial upgrade)
<seb128> what version of nautilus/eel ?
<mjg59> Nautilus 2.13.3-0ubuntu2
<Amaranth> oh, that reminds me
<mjg59> eel didn't get upgraded
<seb128> eel never got an ABI stability garanty upstream which is a pain
<Amaranth> i think it was pango that needed the new glib but didn't depend on it
<mjg59> seb128: eel is currently 2.12.1
<seb128> mjg59: I guess we should make nautilus Depends on libeel2-2 (<< next-version)
<mjg59> seb128: Possibly libeel2-2=current-version
<seb128> there is no current-version
<mjg59> Oh - where's it built from?
<seb128> I mean, we have to specify the Debian revision if we do that, no?
<Amaranth> seb128: should the new libeel conflict the old nautilus?
<seb128> we don't want to rebuild nautilus every time we upload a Debian revision of eel
<mjg59> seb128: Oh, nngh. Yeah.
<mjg59> seb128: Ok, upgrading eel has got me to the point where nautilus opens a window and then crashes
<seb128> Amaranth: no, that is evil
<seb128> mjg59: does it crash 2 times in a row or it was still running previous eel?
<mjg59> seb128: Several times in a row
<seb128> other libs are supposed to be ABI compatible
<seb128> do you have a backtrace?
<mjg59> (nautilus:14070): libgnomevfs-WARNING **: Cannot load module `/usr/lib/gnome-vfs-2.0/modules/libmapping.so' (/usr/lib/gnome-vfs-2.0/modules/libmapping.so: cannot open shared object file: No such file or directory)
<mjg59> Is the only console output
<seb128> hum
<seb128> this is from ncb
<seb128> but it should not crash nautilus
<mjg59> ncb?
<seb128> a bt would be nice
<seb128> nautilus-cd-burner: /usr/lib/gnome-vfs-2.0/modules/libmapping.so
<mjg59> seb128: Ok, how can I generate one? Just from gdb?
<seb128> click on the "send upstream" dialog from bug-buddy
<seb128> or gdb
<seb128> thread apply all bt 
<mjg59> seb128: Ok. You want a bug, or shall I just C&P to you?
<seb128> copy on pastebin.com please
<seb128> so I can figure if the bug is known
<mjg59> http://pastebin.com/465198
* StevenK tries to figure out what is wrong with his web access.
<StevenK> But IRC works, which just makes me curious why nothing else does.
<seb128> mjg59: bug is not known ... could you get a backtrace with libgnomevfs2-0-dbg libglib2.0-0-dbg nautilus-dbg installed and open a bug?
<mjg59> Sure
<mjg59> seb128: Will our nautilus use the beagle search functionality, or does it just use the dumb indexer?
<seb128> we will try the first one
<seb128> by need to get libbeagle splitted properly to start
<mjg59> Is it a build-time thing?
<seb128> then pitti to promote it
<seb128> yep
<mjg59> Shame
<seb128> we don't have to Depends on beagle
<seb128> but we have to link with libbeagle
<mjg59> Ok
<mjg59> seb128: It looks like nautilus_file_get_volume
<seb128> I'm wondering if that can be a dbus/hal/gnomevfs versions mismatch on upgrade or something
<mjg59> Mm.
<mjg59> I've just upgraded g-v-m, so I have everything it dragged in
<seb128> yeah but since we don't restart dbus on upgrade
<Diziet> Aaargh.  Makefiles with    for file in list   instead of   set -e; for file in list    HATE HATE
<Diziet> It's almost tempting to suggest a change to /bin/sh to make it have set -e by default for noninteractive shells.
<mjg59> seb128: 21049
<mjg59> seb128: Restarting dbus didn't help
<mjg59> Let me log out and in again
<seb128> mjg59: and killall gnome-vfs-daemon nautilus?
<mjg59> Still broken
<jdub> heh, wow, usplash looks pretty bad at 1920x1200!
<mjg59> jdub: "Bad" as in "poor"?
<mjg59> seb128: Logged out, in, still broken
<ogra> bad as in t small i guess
<jdub> pixels like shipping crates
<maswan> jdub: default session looks pretty awful at 1024x768 software-scaled to 1280x1024 and the hardware-scaled to 1600x1200 in the tft. :)
<mjg59> jdub: Oh. Your laptop sucks.
<jdub> mjg59: desktop
<mjg59> jdub: Ah, in that case, definitely
<mjg59> jdub: That's the argument for flat colours...
<jdub> (are there laptops with 1920x1200?)
<Mithrandir> jdub: yes
<Mithrandir> jdub: Treenaks has one.
<ogra> the one from andyfitz had this iirc
<jdub> i would so dig a 14" widescreen 1920x1200 laptop
<jdub> that would be elite
<jdub> ;-)
<mjg59> jdub: I've got a 7" that's got 1280x768
<mjg59> So the technology exists
<jdub> ooooh
<jdub> what's that?
<Kinnison> mjg59: aye, but scaling it up costs a lot
<mjg59> Libretto U100
<mjg59> Keyboard is unusably small
<mjg59> But it's /very/ sweet
<Treenaks> jdub: I have a 15.4" 1920x1200
<Kinnison> mjg59: got any further with the tecras ?
<mjg59> Kinnison: Which bit of them?
<jdub> Treenaks: wow
* Treenaks wishes for desktop panels of that size
<Kinnison> mjg59: acpi
<jdub> Treenaks: what is it?
<mjg59> Kinnison: Seems fine
<Treenaks> jdub: HP NW8240
<Kinnison> mjg59: But no hotkeys?
<mjg59> Kinnison: Oh, right. No, haven't had a chance to look
<jdub> Treenaks: expensive?
<Treenaks> jdub: LaptopTestingTeam ;)
<mjg59> Probably need to check out the Windows driver
<mjg59> jdub: Canonical special
<jdub> Treenaks: ha ha! bonus!
<Kinnison> mjg59: aye, 'cos there's no W[DM] I in there
<jdub> you are the winner.
<Treenaks> jdub: I like it ;)
<Kinnison> mjg59: which tecra model was it?
* Treenaks is going to see if ATI is unb0rked in flight2
<Treenaks> tonight
<mjg59> Kinnison: A5
<Kinnison> mjg59: Do you happen to know if it has the latest bios on it?
<Kinnison> http://www.csd.toshiba.com/cgi-bin/tais/su/su_sc_modItemList.jsp lists 1.90 from the 23rd November
<mjg59> Kinnison: It's unlikely
<mjg59> But I can probably get it upgraded
<seb128> mjg59: are all the gnomevfs binary package uptodate? just trying to guess what could go wrong
<mjg59> libgnomevfs2-common and libgnomevgs2-0 are up to date
<seb128> what version of linux?
<mjg59> 2.6.15-7
<seb128> not that neither ...
<mjg59> Holy god why is the Toshiba hotkey utility a 5MB zip file?
<pitti> ogra: do you deliberately want to lock the screen whenever the screensaver activates or is that just an upstream default? I find that pretty annoying...
<jdub> mjg59: it is their christmas present to you
<ogra> pitti, i didnt change it ...
<ogra> pitti, so it must be upstream ...
<ogra> unless dholbach changed it 
<ogra> which i doubt
<ogra> pitti, i'll disable it in the next upload, or remid holbi to do it ;)
<ogra> *remind
<BenC> pitti: http://people.ubuntu.com/~bcollins/kernels/Bug-5049/
<pitti> ogra: that would be nice, thanks
<pitti> BenC: great, downloading now
<pitti> BenC: so you changed the CD-ROM ioctl to behave similarly to the scsi one?
<BenC> yeah
<BenC> added the first cmd
<BenC> I can do the same for ide
<BenC> (this is for scsi)
<pitti> BenC: hmm, ide, that could be relevant for internal card readers or ZIP drives?
<BenC> yeah
<BenC> it sends the same command, but, like scsi, only sends the second
<BenC> basically a START_STOP command, with argument of 0x2 is what the CDROMEJECT sends, and eject -s sends 0x01 then 0x02
<BenC> that's the only difference I saw
<BenC> eject -s also sends an ALLOWED_TO_REMOVE command, but I don't think that's relevant (though I could add it aswell to the ioctl)
<pitti> BenC: could that have any unintentional side effect, like disabling internal scsi drives?
<BenC> perhaps I should do the allowed-to-remove request
<BenC> ALLOW_MEDIUM_REMOVAL
<BenC> if that fails, then just error out of the ioctl
<pitti> sounds good
<pitti> I reboot now, brb
<pitti> BenC: eject: trying to eject `/dev/sda1' using CD-ROM eject command
<pitti> eject: CD-ROM eject command failed
* Diziet resorts to strace fakeroot debian/rules binary.  I'll be lucky if it works.
<pitti> BenC: still no luck :(
<BenC> pitti: hmm
<BenC> what about /dev/sda?
<BenC> shouldn't make a difference, but this thing is whacky
<pitti> BenC: same result
<BenC> pitti: thanks, guess it's back t the drawing board
<pitti> BenC: same with my small python script that just does the ioctl
<pitti> ioctl(3, CDROMEJECT, 0x2aaaaadf51c0)    = -1 EIO (Input/output error)
<BenC> who knows, maybe the ALLOW_MEDIUM_REMOVAL is needed
<ogra> seb128, why does evo out this little clock into the notification area since yesterday ? it didnt use to before and the cloak apparently doesn nothing ..
<ogra> s/out/put/
<ogra> s/cloak/clock/
<doko> pitti: please have a look at http://people.ubuntu.com/~lamont/buildLogs/p/pwlib/1.8.7-2/pwlib_1.8.7-2_20051215-1415-amd64-failed.gz (your last libsdl1.2 sync)
<seb128> ogra: ask upstream I just package
<seb128> ogra: it has already been bugged upstream though
<ogra> ah,k
<pitti> doko: this libglu1-mesa-dev failure is the same that killed the xine-lib build
<pitti> doko: something on amd64 broke libglu1-mesa-dev
<pitti> because the other arches work
<doko> hmm, ok
<elmo> how do you suspend when the option isn't in the menu?
<jbailey> elmo: sudo echo mem >/sys/power/state
<jbailey> elmo: If you can the file, you can see the options in there.
<ogra> elmo, install gnome-power-manager ... or se a hammer, but that makes resume difficult
<ogra> s/se/use
<mjg59> elmo: Edit /etc/default/acpi-support, uncomment the second line, reboot
<elmo> mjg59/jbailey/ogra: thanks
<ogra> mjg59, btw, do we plan g-p-m for main ? i'd prepare a main inclusion report if you think its mature enough
<seb128> infinity: do you know what's going on with evolution-data-server builds?
<mjg59> ogra: Yes, I think so
<ogra> mjg59, ok, will do then ..
<infinity> seb128 : No, but I'm off to bed.  I'll look into it first thing in the morning and see if I can apply a hammer to it for you.
<Mithrandir> ok, I rock.  Keyboard selection implemented in the live CD.
<seb128> infinity: thank you
* Gagatan gives Mithrandir a nice little rock
<seb128> infinity: 'night
<infinity> mjg59 : Pretty please, with sugar on top, can you fix acpi-support on ia64 to be installable (either by fixing vbetool, or removing it from the dep list)
<Mithrandir> Gagatan: is it shiny?
<Gagatan> Mithrandir: yes.. called hvafaenitt
<Gagatan> ;)
<Mithrandir> heh
<\sh> *cough* g
<\sh> 'evening
<\sh> daniels(virtual): when are you fixing this stupid "xvfb" font path problem? :)
<BenC> pitti: found out why the IDE thing isn't weird
<BenC> pitti: the commands being sent aren't scsi specific, they are standard MMC commands
<BenC> pitti: ping
<mvo> BenC: he is away for today
<BenC> damn, ok
<Riddell> does ubuntu have a fax tool installed by default?
<ogra> Riddell, nope
<Riddell> thanks
<ogra> Riddell, might be we consider efax one day
<Riddell> actually I was considering removing it from kubuntu :)  but I found a way to just stop it getting in the way
<ogra> i wonder who really still uses faxing from the pc in times of DSL ... which normal user has a modem at home nowadays
<ogra> ?
<BenC> can't say that I've faxed anything in quite a few years
<BenC> scanner + email works just aswell :)
<Robot101> I've only wanted to fax something as a result of inadequate software
<Robot101> (eg unable to fill in a PDF form using Evince)
<Robot101> or because of a requirement for a signature
<Riddell> hmm, faxed signature
<ogra> heh, common usecase *g*
* BenC has a scanned signature that he pastes into documents
<BenC> gpg encrypted of course
<Diziet> If OpenSSL ever gets to v3 we're going to have a soname conflict with libnss's libssl3.
<Kinnison> heh
<dholbach> ogra: i didnt change it
<ogra> dholbach, thought so
<dholbach> *nod*
<pef> hello
<Robot101> Diziet: what would you use as a nameserver? we're using powerdns at the moment, but we're migrating to something that pulls the records out from the database when triggered by changes, so we can write arbitary formats and swich to whatever backend we want.
<Robot101> s/backend/nameserver/
<neuralis> mdz: ping
<dholbach> neuralis: he's on vacation
<neuralis> dholbach: ah. i'll send him mail, then. thanks.
<dholbach> de rien :)
<Kinnison> BenC: Any clues as to what the status of this thread is? http://marc.theaimsgroup.com/?l=linux-kernel&m=110849686819876&w=2
<Kinnison> BenC: It's old, but seems to still be an issue in breezy
<Diziet> robot101: What would I use ?  Now there's a question.  What I _am_ using is BIND8 (urgh shudder yuk).
<Diziet> My nameserver has the internal structure to do just what you want but of course it's not finished.
<Diziet> And at current rate of progress it will `be a while', as they say.
<Robot101> Diziet: so the answer is, there isn't a good one... which is why you're writing one? :)
<Robot101> Diziet: bind8 is the least bad? :(
<ogra> seb128, does our rhythmbox already write audio CDs ? 
<dholbach> ogra: should, yes
<ogra> so about time to drop serpentine, isnt it ? 
<ogra> we said it should be the interim unil RB supports it at udu
<Diziet> robot101: Well, given that I'm already running BIND8 and its deficiences are only very annoying, I think so, yes.
<Diziet> IJLTS: Version: 2:1.firefox1.4.99+1.5rc3.dfsg-1ubuntu5
<seb128> ogra: yep
<ogra> :)
<seb128> ogra: before 5.10 already
<seb128> ogra: right click on a playlist
<ogra> oh
<ogra> i didnt know 
<seb128> there is a menu item to write the CD
<Diziet> Lots of people are running BIND9 and haven't died of apoplexy yet.
<Diziet> But the sheer size of it put me off.
<ogra> seb128, so for the sake of your simplyfied menu, droop serpentine then :)
<seb128> ogra: that's rather for the sake of main duplication
<ogra> additionally :)
<dholbach> ogra: and it isn't "his" :)
<ogra> our, sorry *g*
<Diziet> Anyone have any idea what /usr/lib/mozilla/libnssckbi.so is ?
<Diziet> Hrm, looks like a pkcs#11 library.  Bizarre.
<mx|gone> is mysql5 scheduled for dapper?
<Diziet> What does this mean:  debian/libnss3/usr/lib/libssl3.so: /usr/lib/libnss3.so: version `NSS_3.10' not found (required by debian/libnss3/usr/lib/libssl3.so)
<Nafallo> is Keybuk on leave or something? :-)
<Diziet> Are these usually his kind of topics ?
<Nafallo> no, it wasn't related to you question :-).
<Nafallo> I've just been looking for him all day ;-)
<Mithrandir> Diziet: that you have forgotten to tell dpkg-shlibdeps to look in debian/libnss3/usr/lib for libraries as well, most likely.
<Diziet> mithrandir: No, I don't think so, BICBW.
<siretart> jdub: around?
<Riddell> elmo: please sync k3b-i18n from debian
<elmo>   k3b-i18n |   0.12.9-1 | dapper/universe | source
<elmo> nothing to sync
<Burgwork> elmo, whom would I speak to about the spam settings on the mailing lists?
<seb128> BenC: around?
<BenC> yeah
<BenC> Kinnison: btw, read that thread. I'll check and see what N_TTY_* is set to for breezy
<seb128> BenC: do you need people testing your patched kernel for #5049 or is martin enough? 
<BenC> I think it should be ok, it was probably set back to 2k before 2.6.12 was released
<BenC> anyone can
<BenC> if you have amd64-generic :)
<seb128> hum, in fact I've an i386 install on an amd64, I guess amd64-generic doesn't fit?
<seb128> I also have a 5.10 amd64 on the same box, but I'm will the 2.6.15 boot with 5.10 udev/etc?
<BenC> seb128: it has to be upgraded to atleast partially
<seb128> BenC: k, I'll give it a try later, thank you
* desrt pokes pitti
* desrt falls over
<BenC> seb128: thanks for testing, I'd like to take care of that bug
<seb128> thank you for working on it, that's a "popular" bug for some time according to the number of dups bugzilla got
<doko> hmm, what do I do, if after a dapper upgrade firefox just opens a window: <window id="main-window"
<doko> ^    <menu id="helpMenu"
<doko> ----^
<Burgwork> doko, you restarted Firefox?
<doko> Burgwork: rebooted
<seb128> doko: remove the translation for your locale
<doko> yeah, I didn't like them anyway ...
<poningru> can someone link me to a page describing the portland project?
<mjg59> seb128: Upgrading the rest of my system made Nautilus work
<Burgwork> poningru, http://wiki.freedesktop.org/wiki/Portland
<poningru> thanks dude
<seb128> mjg59: I don't like that much, have you an idea of what could had made it work?
<mjg59> seb128: Not really I'm afraid, no
<seb128> mjg59: thanks anyway, we have the debug backtrace and we can try to do partial upgrade to notice if that's reproducible
* lamont tries to remember the process for getting a package promoted from universe to main
<lathiat> lamont: main inclusion report, security review, etc
<tseng> lamont: you need a wiki page called PackageMainInclusionReport linked from the queue
<tseng> lamont: pitti will review it for security/maintainability
* lamont creates PrctlMainInclusionReport
<lamont> linked from what queue?
<tseng> https://wiki.ubuntu.com/UbuntuMainInclusionQueue
<lamont> hrm.. it delivers no libraries, so I _guess_ it's complient with the debian library packaging guide... :-)
<tseng> haha
<tseng> i just hit a DD with that same guide
<tseng> go go "beagle-dev"
<lamont> tseng: is the queue normally append-to-end?
<lamont> "Hold any necessary discussion on `ubuntu-devel`"
<lamont> hrm... any discussion?
<tseng> lamont: you report to the bottom of "Unreviewed packages"
<tseng> pitti normally leaves you a note right on the page
<tseng> if there is a problem
<ajmitch> tseng: you've talked with him about beagle-dev now?
<tseng> i am waiting for bts to process my bug
<ajmitch> aha
<tseng> he takes too long to reply to my email
<tseng> and he doesnt irc afaict
<tseng> i talked to him on irc exactly once
<ajmitch> not often, anyway
<tseng> Bug#343542
<ajmitch> tseng: what severity?
<tseng> normal
<dholbach> heya jdub: what do you think about adding mdke's blog to planet?
* mdke cringes
<mdke> dholbach, i appreciate the effort, but planet is broken :(
<dholbach> you should be on it anyways, if it works or no :)
<mdke> dholbach, the mechanism for adding people is broken...
<dholbach> oh hm well, then, hm
#ubuntu-devel 2005-12-21
<mdke> dholbach, you're on it tho right?
<dholbach> yeah :)
<mdke> ah well you can post about ubuntu-docs :)
<dholbach> people are sick of me already, announcing this or that, .. :)
<dholbach> but maybe i should sit down at the weekend and write a BIG post :)
<mdke> you're the ubuntu love guy :)
<dholbach> thanks :)
<mdke> Kamion, around?
<dholbach> good night everybody
<Kinnison> BenC: thanks
<Burgwork> mdke, I think I heard that Kamion is going away for a few days
<Burgwork> something about us being all insane
<mdke> Burgwork, hehe, ok I've mailed him
<lllmanulll> Hey there, could anybody tell me where I can find bzr branches ? Are they stored on some URL, or should I just create a branch from a tarball (apt-get source) ?
<mdke> lllmanulll, for what project?
<mdke> many are at bazaar.ubuntu.com i think
<lllmanulll> well, any package in fact...
<lllmanulll> gnome-session in particular
<lllmanulll> hmm, is that for bzr or baz ? :)
<mdke> i don't know
<lllmanulll> Ok, I'll try, thanks a lot :)
<lllmanulll> Hmmm, none of them are newer than july 2005, I guess there must be somewhere else
<mdke> oh whoops sorry
<lllmanulll> no problem :)
<lllmanulll> Anybody else awake ? :)
<Fergus> lllmanulll, sure..
<lllmanulll> Nevermind, I was told that most packages don't have bzr branches online
<lllmanulll> right ?
<tseng> right.
<tseng> hct will fix that someday
<lllmanulll> thanks :)
<tseng> Kamion: flight 2 installer was alot more beligerent than usual :/
<mjg59> tseng: Hi - did you see my comments about beagle?
<tseng> mjg59: which
<tseng> mjg59: (no)
<mjg59> tseng: Fails with an old firefox
<tseng> yes that would be a problem
<mjg59> If it's built against 1.5, it probably needs to depend on it
<tseng> probably shlibs or clilibs sucking
<tseng> stuff that is invoked from managed code gets stuck in the twilight zone of depends:
* tseng adds a hard depend
<tseng> mjg59: firefox (>= 1.4.99), hows that catch you
<mjg59> tseng: Better, but then firefox can be upgraded and break it
<mjg59> tseng: Diziet is looking into solving that. Basically, firefox will provide: firefox-abi-1.5
<mjg59> Then you depend on that
<mjg59> When the ABI breaks, the provides changes
<tseng> I think ill cross that bridge when we come to it, then
<tseng> file a bug if that happens please
<mjg59> Heh. It will :)
<mjg59> But yeah, will do
<tseng> thanks.
<tseng> if beagle goes through new in debian, is rejected and reuploaded..
<tseng> is the revision incremented?
<lifeless> should not be
<lifeless> unless the dev made more changes before realising the rejection
<tseng> that sucks
<tseng> ill just sync it with the same revision in ubuntu, then
<tseng> MoM be damned
<tseng> (i jumped the gun and synced the version that went into NEW)
<tseng> i blame seb128 and dholbach for repeated badgering and related shananigans
<ajmitch> hopefully the orig.tar.gz is the same, at least
<tseng> mjg59: you wish is granted
<tseng> ajmitch: im sure it is
<mjg59> tseng: Rock, thanks
<tseng> nps
<mhz> hi all
<mhz> do you know if ubuntu/edubuntu should recognize 4GB of ram in a box?
<elmo> mhz: yes
<mhz> just by running 'free'? elmo
<elmo> mhz: yes
<mhz> okis, thx
<crimsun> elmo: ping
<infinity> elmo : Can libdrm2 get promoted to main, s'il vous plait?
<tux-rox> Quick question, anyone working on backporting or fixing Evolution-Exchange Connector for Breezy? It is pretty crappy and I am really trying not to use Windows at work to be an example that it is possible......
<seth_k> tux-rox, is there a new version in dapper? what's the package name?
<tux-rox> seth_k, of course there is a new version in Dapper, but I am worried about having to update the entire GNOME interface to update the evolution packages. It as a lot of deps, and I'd rather not break my system. The name is evolution-exchange I believe.
<seth_k> okay, I'll run a backport on it tux-rox, and we'll see what happens. It may be too greatly changed to install, but we can at least see :)
<seth_k> it'll be a few minutes building and then i'll upload it for you to try
<tux-rox> evolution-exchange_2.5.3-0ubuntu1_i386.deb is the latest in Dapper I think.
<tux-rox> OK, cool. 
<seth_k> yeah, that's the version that I'm building now
<tux-rox> That would ROCK, as I really want this to go off and work without a hitch. People are already saying things like, "What's that on your computer?" or my manager saying, "You have a license for that right?" :-)
<seth_k> hmm, it prefers libedataserverui1.2-dev >= 1.5.3 and breezy has only 1.4.1-0ubuntu3 :(
* seth_k will try with the old version and see what happens
<tux-rox> Actually, the list of deps when I tried the dapper package was 23...... :-(
<tux-rox> That's why it is totally understandable that we are not seeing a really motivated effort to backport large apps like this, I think.
<seth_k> well, loosening that build-dep made it satisfied, now it's just if it builds... which it may well not. But no harm in trying :)
<tux-rox> Cool
<seth_k> yup, no go. ftbfs if I loosed the build-dep
<seth_k> and now you're looking at backporting a library, which is angry stuff, sorry :(
<tux-rox> seth_k, I figured as much. No worries, but thanks a bunch for trying!
<seth_k> no worries, poke me if you ever want a backport (maybe one with fewer dependencies :P)
<tux-rox> seth_k, thanks, I'll keep it in mind! 
<dholbach> good morning developers
<Pygi> good mornin' dholbach
<dholbach> hey pygi
<pitti> Good morning
<Pygi> mornin' pitti
<pitti> Hi Pygi 
<maswan> dholbach: Hmm.. Perhaps clicking around on a couple of files in nautilus and fiddling with properties etc would be a good short test too? (just found a nautilus crash in flight-2 on right-click/properties/open with)
<dholbach> maswan: sounds like it
<dholbach> :)
<mvo> pitti: what do you think about moving to dbus 0.60? 
<dholbach> maswan: could you install nautilus-dbg and include the backtrace in the bug report?
<dholbach> maswan: (if it's reproducible)
<pitti> mvo: fine for me
<pitti> mvo: AFAIK it's already in Debian experimental
<pitti> Diziet: you rock! (nss/nspr from firefox) thanks a million
<mvo> pitti: yes, i have it runing here and beside the (usual) pain for the transition it seems to be working fine. I had to apply a amd64 patch though to make the debian/experimental version build. "long -> long long" otherwise qt4 complained loudly 
<pitti> mvo: so we need to change all dbus dependencies?
<pitti> hal, g-v-m, gvfs, g-p-m, etc.?
<mvo> pitti: yes, new api/abi
<pitti> mvo: hmkay, if you want to upload it now, I'll care for hal/gvm
<mvo> so far everything worked with a recompile, but we may have to change g-p-m and gnome-applets a bit (it uses the old libnotify interface)
<ogra> not true :)
<mvo> no?
<ogra> afaik its prepared for the new one already....
<mvo> oh, nice (and even better) :) both? or only g-p-m?
<ogra> i can only talk about g-p-m
<mvo> I would love to ask one of the release team before to be sure that I don't do the upload at a inconvenient time. but mdz and kamion are on vacation
<pitti> flight-2 is just out
<pitti> we won't get a better time than now
<pitti> mvo: and we'll also need the libsysfs2 transition
<pitti> mvo: so I'd upload both at the same time, then get it through NEW, then rebuild hal/gvm against the new stuff
<infinity> mvo : I'm pretending to be kamion while he's on VAC.  Go nuts.  Upload now, upload often.
<infinity> (Also, I'm having a weekend right now, so this wasn't me)
<mvo> pitti: ok, I do dbus, you do libsysfs2?
<pitti> infinity: can you NEW?
<pitti> mvo: yes
<infinity> pitti : No, but elmo should wake up in a few hours. :)
<pitti> mvo: I already have the sysfs packages prepared
<mvo> infinity: can we have you after colins vacation as well please :) ?
<infinity> mvo : You won't like me very much when I'm trying to do CD releases.  Colin's a much nicer person.
<mvo> infinity: heh :)
<dholbach> hellas vuntz
<dholbach> vuntz: look at ubuntu-dekstop@
<Mithrandir> dholbach: since you think the new live cd is faster, what do you think of http://people.ubuntu.com/~tfheen/live-bootcharts/unionfs-squashfs-dapper-20051216-1.png vs http://people.ubuntu.com/~tfheen/live-bootcharts/unionfs-dapper-20051212-1.png ?  The latter is approximately the current live (+bootchart), the latter is with squashfs
<Kaloz> Mithrandir: squashfs vanilla?
<Mithrandir> Kaloz: I just used squashfs instead of cloop
<ogra> Mithrandir, woah, why does the adduser take this long ?
<Kaloz> Mithrandir: if I can suggest smg, try squashfs-lzma
<dholbach> wow, Mithrandir, i'm thoroughly impressed
<Mithrandir> ogra: because it needs to read libc, perl etc, etc off the image.
<Mithrandir> ogra: it would look differently if I added a "chroot /target /bin/ls" before adduser, and you'd ask why ls needed ten seconds to do anything
<ogra> heh
<ogra> but it definately takes much longer in the second chart
<Mithrandir> also, this is without readahead or file system reordering.
<ogra> and i wonder why your x configuration takes much longer than mine in ltsp, i guess we're doing exactly the same at this point of booting
<Kaloz> oh, lzam would make smaller files and would be faster btw, too ;)
<maswan> dholbach: Ah, good plan. I'll update the bug report with that.
<Mithrandir> Kaloz: cool, I'll take a look a it.
<Mithrandir> ogra: because my file system is way slower, especially seeks?
<Kaloz> Mithrandir: use the patches from our svn if you want to
<dholbach> maswan: merci beaucoup
<Mithrandir> Kaloz: which "our"? :-)
<ogra> Mithrandir, i dont think so... my nfs mount is slow as well ...
<Kaloz> Mithrandir: OpenWrt
<Mithrandir> Kaloz: ah, excellent. :-)
<Kaloz> Mithrandir: https://dev.openwrt.org/file/trunk/openwrt/target/linux/linux-2.6/patches/generic/002-squashfs_lzma.patch
<Mithrandir> Kaloz: just didn't have any project connection on you in my head.
<Kaloz> Mithrandir: and https://dev.openwrt.org/file/trunk/openwrt/target/lzma/lzma-406-zlib-stream.patch
<Mithrandir> ugh, more kernel patching?  Well, I'll build images and see how much we save.
<ogra> Mithrandir, mdz's idea was that we collect all debconf stuff and calll debconf communicate only once to reduce the time it by about 10
<Kaloz> Mithrandir: yeah, I wanted to do nubuntu (eg. embedded ubuntu), just i was pretty busy with my own stuff
<Mithrandir> ogra: you don't have 100-150ms seek times, I hope.
<ogra> s/time/time for
<Kaloz> Mithrandir: well, about space savings.. prepare to be amazed
<ogra> that really depends on the network load here ;)
<Kaloz> Mithrandir: using lzma vs. bzip2 is about using bzip2 vs. gzip
<Mithrandir> Kaloz: I'm already in shock&awe about squashfs vs cloop.  Only sad thing is squashfs is read-only, so ppc might lose out a bit (since unionfs is oopsorama on ppc)
<vuntz> dholbach: I've seen the translation (he sent me a private mail first). That's cool :-)
<dholbach> vuntz: that's amazing
<Kaloz> Mithrandir: well, we had cramfs, then squshfs, then squshfs-lzma. we were shocked with the switch of squashfs, too, until we saw lzma
<Kaloz> Mithrandir: since then, I dream of someone implementing lzma for jffs2 ;)
<Mithrandir> Kaloz: that'd be nice, agreed.. :-)
<Kaloz> Mithrandir: http://www.linuxfromscratch.org/patches/downloads/linux/linux-2.6-lzma-1.patch
<Kaloz> for the kernel optionally
<Mithrandir> Kaloz: that's for lzma-compressing the kernel?
<Mithrandir> Kaloz: I don't think we want to do that, at least not initially.  We're tight on space, but I'd like to not potentially break people's boots
<Kaloz> Mithrandir: well, with squashfs-lzma you would gain at least 25-30%
<Mithrandir> that's 500k, which is nice, of course.
<Mithrandir> grr, where's keybuk when I need him?
<Kaloz> 500K on a full cd? ;)
<sivang> morning all
<Mithrandir> yes, but I just freed up 25MB by going to squashfs and you're saying that lzma will be even better, so.. :-)
<Kaloz> Mithrandir: well, using squashfs-lzma for the full cd should gain around 100M imho :p
<Mithrandir> Kaloz: over squashfs or cloop?
<Kaloz> over squashfs :P
<Mithrandir> wow
<Kaloz> .oO(now comes the "holy shit")
<Kaloz> :)
<Mithrandir> what's the svn-url to your repo?
<ogra> yay, that would be awesome, my edubuntu ppc live already needs the overburn feature to fit on a 700MB CD
<Mithrandir> ogra: ppc won't get this
<Kaloz> for the full repo? https://svn.openwrt.org/openwrt/trunk/
<ogra> gah
<Mithrandir> ogra: at least not until unionfs is fixed there
<ogra> ok, so some hope left :)
<sivang> anybody know of a reliable way to check how much have passed since a user installed his system? also, how to set a question in our d-i, for enabling some feature or not? (by "feature" I mean http://wiki.ubuntu.com/HomeUserBackup)
<sivang> *time
<Treenaks> sivang: including OEM, or excluding?
<ogra> sivang, adding d-i questions is a big nono
<sivang> Treenaks: hmm, good question :)
<shay|ubuntu> hi
<sivang> hi shay|ubuntu 
<Pygi> hi hi
<shay|ubuntu> what's up :-)
<sivang> hey Pygi 
<ogra> sivang, or do you mean adding a debconf question to the package ? thats possible, but needs to be prio=low to not show up on installation ...
<Mithrandir> Kaloz: hmm, the lzma-406-zlib-stream patch is needed for what?  That is, how do I generate the file system?
<sivang> ogra: well, we did thought about adding this to d-i at install time, so someone could "no" it by pre-seeding for mass installs...
<Kaloz> Mithrandir: ah, forget that one. tha tis for our kenrel only imho :)
<Kaloz> Mithrandir: well, there is a patche for mksqushfs in there
<ogra> sivang, thats suboptimal, and Kamion will surely oppose it ...
<Mithrandir> Kaloz: that sounds better. :-)
<sivang> ogra: I see
<Nafallo> infinity, lamont: give back screem on i386 powerpc ia64, thanks.
<jdub> sivang: check the creation date of a file created in both OEM and normal installations? not super reliable, but not terrible
<sivang> jdub: /me tomboys :)
<Kaloz> Mithrandir: sec, i point you the the original patches from Oleg 
<sivang> jdub: if we add HUB to main, does it mean it will be both in OEM and normal automatically? 
<jdub> sivang: only if it's in the desktop seed
<sivang> jdub: ok, so OEM means base + desktop seed essentially?
<ogra> sivang, if you want it installed, it needs to be seeded, thats what jdub meant
<Kaloz> Mithrandir: http://oleg.wl500g.info/lzma/ infos: http://sourceforge.net/mailarchive/message.php?msg_id=10612560
<sivang> ogra: ok, thanks
<Kaloz> Mithrandir: and use the 2.6 kernel patch from our repo
<ogra> sivang, adding stuff to main wont just install it ;9
<ogra> ;)
<sivang> jdub: thank as well ;-)
<Mithrandir> Kaloz: thanks
<sivang> ogra: sure, /me recalls.
<Kaloz> Mithrandir: afaik newer version of the lzma sdk are even faster, I will take a look at those today
* sivang wants to ask several question about implementation of notifications as well, maybe -desktop is a better place?
<jdub> yep
<Mithrandir> Kaloz: it seems to require me to have the lzma stuff installed, which isn't packaged, but I could do that.
<Nafallo> infinity, lamont: nm, seems to be in state building everywhere except amd64, where it's installed.
<Mithrandir> Kaloz: any idea if the 7zip patch has been submitted upstream?
<Kaloz> Mithrandir: dunno
<Mithrandir> Kaloz: it doesn't seem to build, though.
<Kaloz> well, works for us :) so the problem should be there somewhere
<Mithrandir> heh. :-)
<Mithrandir> I guess some changes have happened in p7zip in the meantime, then.
<Kaloz> p7zip? we are using the lzma sdk from 7zip.org
<Mithrandir> the code seems to be the same, though
<Kaloz> well, lzma406 works for us, as I've said, I will take a look later for the new versions
<Kaloz> now I'm testing gcc 3.4.5, as that fixes a compiler bug with -Os
<Mithrandir> ah, we're using 4.0
<Kaloz> Mithrandir: that had the bug, too
<Kaloz> Mithrandir: everything >= gcc 3.4
<Kaloz> Mithrandir: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22167
<Mithrandir> does it only bite mips/el?
<Kaloz> nope
<Mithrandir> I would think we'd dragged that in, given that it was committed to the gcc repo in july
<Kaloz> well, we didn't, yet :) and maybe all the madwifi problems we are facing will be fixed with this (and/or our 2.4 kernel will be bootable with gcc4 after this fix)
<drakeoutlaw> hi all, is there an Ubuntu update for the ipw2200 driver. I need the 1.0.8 (latest) please
<dholbach> drakeoutlaw: i guess you'd have more success with filing a bug report, stating where to get it, what the problem is with the old one and why it fixes it
<drakeoutlaw> I could use the source from debian testing can't I
<DocTomoe> What would it take to add alsaconfig to dapper?
<HiddenWolf> drakeoutlaw, at your own risk, yes. :)
<dholbach> drakeoutlaw: i suppose that doesn't change problems for ubuntu as a whole
<drakeoutlaw> would module assistant work?
<drakeoutlaw> i mean would module-assistant work in the downloaded .deb file?
<drakeoutlaw> dholbach: wher does one file a bug report
<dholbach> drakeoutlaw: http://bugzilla.ubuntu.com
<drakeoutlaw> dholbach: thanx
<mvo> hey seb128 
<seb128> hi mvo
<dholbach> hellas seb128
<pitti> Hi seb128 
<pitti> seb128: e-d-s still didn't build :(
<seb128> pitti: get infinity to look why
<pitti> ENOINFINITY
<seb128> he said he would do that first thing today
<seb128> EIMNOTBUILDDADMIN
<Robot101> surely EFINITE? :)
<pitti> heh
<ogra> seb128, he just said he'd throw a hammer at it ... iirc ... he probably did :P
<joe_oblivian> hi everybody, I've an issue with the ubuntu-installer on ppc that has been going on through breezy and the two dapper flights. Basically, the ubuntu-installer refuses to read the apple partition map, even if mac-fdisk (from the shell)reads it correctly. I think the problem *might* arise from the fact I have HFSX partitions
<joe_oblivian> If there is any ppc developer around, I'll be happy to send him a dump of my apple partition map
<fabbione> joe_oblivian: it's a known bug.
<fabbione> let me dig the number
<joe_oblivian> fabbione: ok if it's known, it's okay. I've seen something in the forums but was not able to find it on launchpad
<fabbione> it's in bugzilla
<Nafallo> isn't bugzilla imported to malone now?
<fabbione> Nafallo: would you hate me if i say i dunno?
<ogra> i hope it isnt visible if it is ...
<Nafallo> fabbione: nope, I just was under the impression. maybe staging or something :-P.
<fabbione> joe_oblivian: http://bugzilla.ubuntu.com/show_bug.cgi?id=20569
<ogra> would be odd to have it in two places before we switch
<joe_oblivian> fabbione: ok and scusa :-)
* Nafallo agrees somewhat with fabbione's Quake-comparison of launchpad ;-)
<fabbione> joe_oblivian: no problem :)
<ogra> hehe
<joe_oblivian> fabbione: it's a pity, I cannot install the dapper on my ibook :-/
<doko> elmo: please sync valgrind 1:3.1.0-2 from unstable, overwriting ubuntu changes
<jordi> pitti, or whoever looks at alsa. I think you're interested in alsa-driver/incoming
<jordi> it transitions to the new modprobe blacklists etc
<pitti> jordi: we should get that automatically, but thank you
<jordi> k
<ogra> joe_oblivian, install breezy and upgrade ? 
<fabbione> joe_oblivian: do you have the latest ibook from Apple?
<fabbione> joe_oblivian: the end of 2005 model?
<fabbione> ogra: it might not help at all
<joe_oblivian> ogra: no the problem waas in breezy
<ogra> hmm, hoary ?
<joe_oblivian> fabbione: no I do have a 1.2 Ghz ibook from aug 2004
<fabbione> joe_oblivian: you need to change the MacOS partition properties.. 
<joe_oblivian> ogra: well, I might try
<fabbione> joe_oblivian: your has journal+casesentive
<fabbione> you need to kill casesensitive
<fabbione> journal is fine
<joe_oblivian> fabbione: I need case sensitiveness
<fabbione> hoary won't help
<fabbione> joe_oblivian: how so?
<fabbione> it works even without.. it's an extra feature for something i couldn't even figure out 
<joe_oblivian> fabbione: I have some code thet would needd to be rewritten if I do not use case sensitiveness
<fabbione> hm ok
<fabbione> than i guess you will have to wait for a fix
<joe_oblivian> fabbione: I know.... I'd love to help testing any fix...
<fabbione> we have none..
<joe_oblivian> fabbione: ok, then maybe I'll wait for the AE driver to become stable enough and then I'll wipe tiger from my ibook
<joe_oblivian> or maybe I'll try to install sid instead
<seb128> is somebody working on gutenprint  (#19891)?
<pitti> elmo: can you please NEW sysfsutils 2.0.0, so that I can complete the transition today?
<lucasvo> when you click on an email adress like a@b.com in a terminal, does your evolution(if it is running) start up once again as well?
<siretart> pitti: ogra send me to you, since my upgrade to dapper, sound is broken. System->Settings->Audio does not let me choose my soundcard, the selector is empty. I have 2 cards, sblive and onboard nforce4 shit. I want sblive as card0.
<siretart> pitti: How do I debug the problem?
<pitti> siretart: do you have 5 minutes? I'd like to finish my current task before coming to this
<siretart> pitti: no problem. take your time
<segfault> whats the new splash screen uusing?
<Treenaks> SuSE ;)
<segfault> that gfxboot?
<ogra> yup
<segfault> nice
<ogra> not really, the theme markup seems to be very weird :)
<ogra> but the outcome is great, agreed :)
<segfault> im using dapper, but havent updated it for some days
<segfault> is it just in the install cd or after installed it will appear too?
<ogra> its in the install cd ...
<ogra> we didnt change from usplash for booting ...
<Nafallo> and livecd...
<ogra> indeed :)
<seb128> infinity: did you figure what's wrong with e-d-s build?
<segfault> where's the server team?
<pitti> Hi jbailey 
<jbailey> moin, Martin.
<mvo> hey jbailey 
<jbailey> Herr Vogt!
<usual> Not sure if this is the place to ask, does ubuntu plan on offering a directory services solution like the Fedora project has started? It looks very promising.
<OgMaciel> \sh, good morning (or afternoon for you)...  can I pvt for 1-2 minutes?
<\sh> OgMaciel: sure...but be careful I have a cold :)
<OgMaciel> hehehe
<mvo> Riddell: do you plan to ask for main inclusion of qt4 any time soon?
<Riddell> mvo: yes, it'll be brought in by avahi
* pitti runs away when hearing 'main inclusion report again'
<Riddell> mvo: who do you ask?
<mvo> Riddell: I was asking because dbus 0.60 needs it as well
<pitti> hm, seriously, that's just another upstream version
<pitti> I don't see a need to do a report for that
<Riddell> are we going to do dbus 0.60 in dapper?
<pitti> mvo: does it even have a different source package name?
<Riddell> pitti: qt4 does yes
<Riddell> there's already a qt4 main inclusion report
<pitti> Riddell: hm, that cries for 'RemovingDuplicates'
<pitti> Riddell: if we have qt4 in main, can we drop qt3?
<Riddell> pitti: no, not until we drop KDE 3
<pitti> bah
<Riddell> qt4 is quite different from qt3
<pitti> mvo: what's the point of building dbus against qt4 when KDE uses 3?
<pitti> mvo: could you please rather disable the qt4 bindings then?
<pitti> oh, wait, then we wouldn't have any dbus qt bindings at all any more
<Riddell> pitti: why?
<Riddell> there are still qt3 dbus bindings (I hope)
<pitti> me too
<pitti> otherwise we'd be screwed
<mvo> yes, we would have qt3 as well
<mvo> I can disable it, sure
<seb128> Binary: libdbus-glib-1-2, dbus-1-doc, monodoc-dbus-1-manual, libdbus-qt4-1-dev, libdbus-glib-1-dev, python2.4-dbus, dbus-1-utils, libdbus-qt-1-dev, libdbus-1-dev, libdbus-qt4-1-1, dbus, libdbus-1-2, libdbus-1-cil, libdbus-qt-1-1c2
<seb128> there is libdbus-qt4-1-1, libdbus-qt-1-1c2
<mvo> Riddell: is that ok with you too?
<pitti> I *strongly* object against having two different qt versions in main, and used by other programs
* seb128 wants the new cdbs
<pitti> that only cries for trouble
<pitti> seb128: buildds are offline
<seb128> what are the damn buildds doing, they are in VAC? :)
<pitti> indeed they are
<seb128> well
<seb128> all that is a plan to get me not working on my VAC day I guess :p
<seb128> fine, /me goes for some book reading :)
<jbailey> seb128: You can help me hack on cdbs then. =)
<Riddell> mvo, pitti: it's ok for now but at some point soonish people will be releasing programs that use qt 4 so it'll be needed in main before long 
<pitti> seb128: I started Potter 6 yesterday :)
<pitti> Riddell: hrm, that sucks
<seb128> pitti: I'm reading the 2 atm and I really enjoyed the 1 (I enjoy the 2 as well) :)
* seb128 hugs dholbach
<Riddell> pitti: it'll be quite some time before we can get rid of qt3 from main
<pitti> Riddell: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=qt -> expect some security updates with doubled effort in the next three years...
<\sh> seb128: bah I read them all :)
<\sh> seb128: already :)
<Riddell> pitti: qt4 is an almost complete re-write, I think most security issue won't affect both
<pitti> Riddell: do you know how long upstream will support 3?
<\sh> .oO(until all commercial clients switched to qt4?)
<Riddell> pitti: not sure but as \sh says they have several thousand commercial clients to support
<Riddell> so a few years yet
<azeem> but maybe they support them via contracts, not by releasing patches to the public?
<\sh> azeem: I don't think so...actually the applications in OSS are much more 
<azeem> ok
<\sh> azeem: and there are some OSS KDE Guys sponsored by QT which they don't want to push away..or towards GTK 
<Riddell> azeem: all qt is dual licenced, gpl and proprietry.  they make the same releases as free software as they do to their clients
<azeem> true
<ptlo> both gtk 1.2 and 2.x are in main, they are paralel installable; if qt3 and qt4 don't step on each other toes, they to can then be in main, no? (just my 2c, i'm a user, not a packager/dev)
<seb128> ptlo: we are trying to move gtk1.2 out of main
<seb128> it's just here because some apps trigger it
<jbailey> seb128: Just gnucash left, isn't it?
<seb128> I think so
<Treenaks> they still haven't ported that?!
<seb128> no :/
<Treenaks> omg
<seb128> jbailey: oh, xmms too
<seb128> but my opinion is that we could move xmms to universe
<jbailey> I think so too.
<jbailey> I don't think it's had any real security issues, so it's low risk to move it there.
<jsgotangco> jbailey, gtk1 rules!
* jsgotangco hides
<pitti> gnucash is in universe
<jbailey> Really?
<jbailey> Hmm.
<jbailey> I'd bet that gnucash probably has more users than xmms on Ubuntu systems.
<jsgotangco> yes
<rob^^^> jbailey: I'd bet not
<seb128> pitti: what requires gtk1.2 to main?
<pitti> seb128, jbailey: it's much worse: http://paste.ubuntu-nl.org/5823
<jsgotangco> dunno almost every newbie ubuntu site i see mentions xmms as the most awesome winamp clone
<rob^^^> I think xmms is forever a engrained
<jsgotangco> rob^^^, just like bluesteel!
<seb128> pitti: all the libs are a detail, that could come from one app
<pitti> kicker-applets is scary
<pitti> KDE uses gtk1.2
<rob^^^> honestly, I've had such a rotten experience with gstreamer that I think most people fall back to safe xmms
<jbailey> pitti: Sure, but alot of those would fall away all at once.
<seb128> pitti: bonobo libglade0 have no reason to be here if an app doesn't trig them
<Mithrandir> oh, this is cool, http://bootchart.err.no/ .  With the new bootchart package, adding bootchart=upload will upload the image as soon as the machine completes booting. :-)
<rob^^^> although I hope it's going to be greatly improved with .10
<seb128> rob^^^: you know there is a world between gst0.10 and xmms
<pitti> seb128: it's mainly unixodbc, evms, xmms, kicker
<\sh> Mithrandir: nice...but what about not having net access?
<rob^^^> seb128: I know that
<rob^^^> seb128: but xmms is "old" rhtyhmbox is "new"
<jbailey> \sh: Don't chose upload then. =)
<Mithrandir> \sh: then you can't upload, but will have to generate it locally, naturally.
<rob^^^> and when "new" doesn't work you go to "old"
<Mithrandir> \sh: like it is today.
<seb128> rob^^^: you can play audio file with xine based app, with bmp, with loads of gtk2 non-gst app
<ogra> Mithrandir, bootchart=upload,{normal|live|ltsp} to fiffernt dirs would be good
<ogra> *different
<\sh> Mithrandir: you know how people are playing with settings :)
<seb128> rob^^^: no, I mean that's not "either xmms or gst"
<rob^^^> seb128: I don't listen to music on my computer, and I know that Rhythmbox even has (or maby had) a non gstreamer backend
<Mithrandir> \sh: yes, but it'll still generate the graph and stuff it in /var/log/bootchart.
<seb128> rob^^^: you have ton of options that work as fine as xmms and doesn't force you to use gst
<seb128> had yep
<Mithrandir> ogra: hmm, good idea.
<rob^^^> seb128: I'm just asying that most people just don't care and go back to xmms because it works, that's all
<Mithrandir> ogra: apart from the fact that networking is broken on the cd so far, but that'll be fixed, eventually.
<jbailey> rob^^^: How are you measuring "most"?
<seb128> rob^^^: I doubt of the "most"
<\sh> Mithrandir: but the timeout 
<Mithrandir> \sh: what timeout?
<rob^^^> I really do think _most_ users end up going back to xine + xmms
<ogra> Mithrandir, at least i can guarantee working networking on thin clients (no internet, but networking) ;)
<Mithrandir> \sh: it's run as the last init script, long after gdm has started.
<Riddell> pitti: I think kicker-applets uses it for xmms controling
<rob^^^> well msot users who really want to listen to mp3s all day
<Mithrandir> ogra: it needs internet, due to hardcoding of the address
<rob^^^> and most users who want to watch DVDs
<ogra> yup
<\sh> Mithrandir: ok..so the user doesn't see it
<ogra> i was just kidding
<rob^^^> and that sucks and I hope it works really great with gstreamer in Dapper
<jsgotangco> not to mention it takes a small amout of screen real esteate
<Mithrandir> \sh: well, it will take a bit of bandwidth to upload, but apart from that, no.
<jbailey> rob^^^: Again, I only wonder how you're measuring most for those.
<Mithrandir> \sh: and I think that's fine, since people will have to enable it explicitly.
<jbailey> rob^^^: Certainly the phone calls that I've taken from people for support don't suggest that that's the case.
<rob^^^> jbailey: look, I'm not about to send out a random mailing to find out what people do but I really think it's practically unusable
<jbailey> But the number is statistically small.
<\sh> Mithrandir: ok..
<rob^^^> the fluendo folk's finally got together a test collection of media files though, so that's a big improvement
<\sh> jbailey: <sarcastic mode on>It's only Linus</sarcarstic mode off>
<seb128> rob^^^: xine is a different matter of xmms
* ogra doesnt know any xmms users anymore ...
<seb128> rob^^^: gstreamer0.8 works pretty fine for sound, not for video
<jbailey> \sh: That whole argument only bothered me because it missed the point that "everyone else does it this way" is a silly argument.  People obviously like gnome, and people obviously like KDE, because they still have communities and do releases.  It's sort of like how we know that slackware still has a community. =)
<jbailey> (And that fvwm95 doesn't...)
<rob^^^> seb128: i've still had some problems with audio, and it's definately a HUGE step over what .7 was and I'm hoping .10 will really nail it down
<jsgotangco> hah
<ogra> jbailey, it doesnt ??
<ogra> o_O
<jbailey> ogra: Yeah, I checked the other day.  Upstream has definetly orphaned fvwm95.
<ogra> bah
<jbailey> I can't remember why I was looking, but it was only a couple weeks ago. =)
<\sh> jbailey: I agree :) well...Linus should switch to a paperless office :) then kde and gnome can remove the printing dialog for once and in the future ,)
<rob^^^> seb128: I'm not knocking gstreamer or saying that its dumb or a waste of time, it's definately great and it's definately improving and I'm fine with that. But back to the original point I think alot of people use xmms because it just works
<rob^^^> I don't have it installed, I think its ugly and hard to use
<seb128> I think many people use totem-xine instead of totem-gstreamer
<spacey_ki> xmms is really unfriendly
<\sh> oh damn...it was all a fever nightmare...
<seb128> I'm really not sure that new user go to xmms
<rob^^^> but anyway we are all in agreement that gstreamer + totem + rhythmbox is the path of the futrue
<jbailey> seb128: totem-gstreamer was fine until I wanted DVDs. =)
<rob^^^> seb128: average joe doesn't but average joe doesn't have a 100gig collection left over from napster that they listen to all day either
<jbailey> seb128: So in that respect breezy was a huge step up from hoary. =)
<seb128> right :)
<\sh> seb128: to be honest...totem-{gstreamer,xine} never worked for me...I can't play embedded avi files, I can't play embedded mpg2 files nothing..and external the same...I use mplayer or xine
<seb128> gst0.10 will rock the dapper world :)
<seb128> \sh: totem xine is the same as xine, no?
<seb128> just with a different frontend
<\sh> seb128: normally it should be the same...but somehow totem screwed...but it can always be me 
<jbailey> seb128: I've found cases where xine is fine and totem-xine isn't.
<jbailey> None in the last 8 months, though.
<\sh> seb128: well I think it doesn't play together with my t64codecs
<jbailey> \sh: t64codecs?
<ogra> w32codecs*2 ?
<maswan> btw: xmms was the only sound player I got to play sound on this system (alsa broken, oss kind of working)
<\sh> jbailey: it's rot\sh for *censored*
<jbailey> \sh: =) 
<jbailey> \sh: I was more wondering if someone had ported w32codecs to amd64. =)
<\sh> jbailey: lol 
<jbailey> maswan: Breezy or dapper?
<maswan> jbailey: breezy with custom 2.6.15 or dapper flight-2
<jbailey> maswan: dapper recently got another alsa update, so if you're still having troubles, it would be awesome if you could file a report.
<jbailey> Yeah, do make sure you file a report.
<maswan> jbailey: Ok, i will. Yeah, I rebooted after the alsa update and still had no luck. I'll report it then.
<crimsun> which alsa update?
<jbailey> maswan: Thanks.  At this point in life, alsa ought to Just Work.
<crimsun> (and we're about to get another due to the /bin/sh issue)
<\sh> ok..another cigarette and then continuing my effords to clean my flat...even when I'm still sick
<maswan> jbailey: Ok, it might be somewhat lacking support for hardware too. It is a fairly new hardware (as in needing 2.6.15 to see the sata hdd etc)
<maswan> Oh, well. Off to that other computer for bug reporting with cut and paste instead of ircing.
<jbailey> maswan: Then OSS really shouldn't work. =)
<\sh> OSS = YouKnowWho Magic...dark, mysterious, and it will come back once in a while
<seb128> \sh, jbailey: anyway, as always is you guys have bugs and switch back to some other apps instead of putting them to bugzilla we are not going to fix those automagically
<jbailey> seb128: I dealt with upstream on the DVD issue.  As, I think, you asked me to at the time. =)
<\sh> seb128: I can't report bugs because I don't have any legal playable source for linux
<\sh> seb128: you will close the bug as "invalid because of t64codecs"
<seb128> jbailey: yeah, but you mentionned "I've found cases where xine is fine and totem-xine isn't." :)
<jbailey> seb128: Why do you assume I didn't file bugs? =)
<jbailey> seb128: Have you ever known me to just shut up about bugs I hit? =)
<seb128> because I'm subscribed to upstream bugzilla for totem (in fact was I changed that) and get Ubuntu/Debian bugs? :)
<jbailey> seb128: With the totem folks I usually go on IRC.
<seb128> I'm on the GNOME chans as well *g*
<jbailey> seb128: Then check your logs, dear. =)
<seb128> right, I sleep sometime :)
<jbailey> seb128: Or don't care, since we're talking almost a year ago. =)
<seb128> I'll pick this one
<\sh> oh wait...
* seb128 doesn't know why he asks for bugs, he have already enough without that :)
<seb128> s/have/has/
<jbailey> seb128: Besides, if you want more bugs, I've been pestering doko with OOo2 bugs.  I'm sure he'd love to give them to someone else. =)
<\sh> seb128: totem could not play fd://0
<jbailey> Is that file description zero or floppy zero? =)
<\sh> no decoders found to handle that stream
<\sh> which is mpg
<Treenaks> \sh: I get that all the time, too
<seb128> \sh: the totem-mozilla stuff is known to be crap
<seb128> I was speaking about totem himself, not used from mozilla
<seb128> we splitted the package so people can uninstall the mozilla part :p
<jbailey> \sh: Make sure you have gstreamer0.8-plugins installed.
<seb128> jbailey: no thanks ;)
<jbailey> \sh: It's in universe, and includes a bunch of pieces that you really really want.
<\sh> well..totem plays now the sound..but not the video
<\sh> jbailey: so...by default you can't watch mpegs
<jbailey> \sh: Sure.  But first let's figure out which problems are gstreamer, and which problems are Ubuntu packaging. =)
<\sh> jbailey: ok..with universe plugins this works...while xvid not which is normal
<\sh> totem http://mtaylor.be/photos/albums/userpics/10002/montgallet_sav_mpeg_lq.mpg
<\sh> very funny btw..
<\sh> and now..cleaning my flat
<jbailey> seb128: ^^  Should he file a bug about that?
<jbailey> seb128: Basically that the default gstreamer plugins don't cover everything that just installing xine does.
<seb128> playing this video works here
<seb128> with totem-gstreamer
<seb128> what is the issue?
<jbailey> Insufficient plugins by default.
<seb128> right, but EPATENTS
<jbailey> *shrug* If we can have xine in main, we clearly don't have that big of a problem with it. =)
<seb128> read ubuntu-devel list
<seb128> slomo has a xine package without ffmpeg and patented stuff ready to upload
<jbailey> Ah nice.
<jbailey> We're solving the problem by breaking the working one. =/
<seb128> right :/
<jbailey> ah well.  That will at least make it consistant.
<slomo> the correct solution would probably be to fix the goverments ;)
<Nafallo> hehe
<crimsun> as long as users can click something in Add Applications to get it working, it should be fine
<jbailey> Well, it's add the repo first at the least.
<ogra> g-a-i does that for you
<ogra> its just a matter of clicking ok
<pitti> BenC: here?
<BenC> pitti: yes
<BenC> pitti: I'm rebuilding a new kernel that ignores the return value (printk's it)
<pitti> BenC: oh, cool
<pitti> BenC: I just wanted to ask whether there was still hope, or whether I should start with an userspace workaround
<tseng> BenC: libata spewing garbage all over vts, well known?
<BenC> tseng: depends on the messages
<BenC> is it ata_piix?
<tseng> a bunch of status crap
<BenC> pitti: I think there is
<BenC> tseng: are you using the ata_piix module?
<maswan> jbailey: well, what can I say, xmms with OSS output works. I tried making mpg321 do oss output, but that just failed toio.
<tseng> BenC: that doesnt sound very familiar, they're dell/intel laptops
<jbailey> maswan: Make sure you only have one thing playing at once.  You might not have a hardware mixer.
<tseng> also at home, will have to look at module list later
<BenC> tseng: ata_piix is an intel ata module
<tseng> oh, then probably yes
<BenC> tseng: known then
<maswan> jbailey: Well, changing to alsa output in xmms makes it not work. Changing back to oss makes it work.
<jdub> Kamion: ping
<jbailey> maswan: Right, alsa might be separately broken.  But that's probably what was up with mpg321.  It might be conflicting with gnome or xmms if you still have it running.
<maswan> jbailey: well gnome (as in preferences/sound) can't find any sound device anyway. it it shoudn't hold it open. :)
<HiddenWolf> seb128, Would it be possible to patch the "filetype unknown" errors of rhythmbox, totem etc to suggest installing $plugins? 
<HiddenWolf> seb128, that'd at least make the issue clearer for new users, and help curb things like automatix and marillat.
<seb128> HiddenWolf: https://wiki.ubuntu.com/EasyCodecInstallation
<HiddenWolf> seb128, ok, nm.
<doko> jbailey: seb128 blatantly ignored you about the OOo bugs 
<jbailey> doko: 10:34 <seb128> jbailey: no thanks ;)
<seb128> :)
<\sh> so..the worst dust is just magically gone
<jsgotangco> ahh the business tour email is finally out
* netjoined: irc.freenode.net -> brown.freenode.net
<\sh> oh what's wrong with this archive mirror: 82.211.81.182?
<\sh> (points from archive.ubuntu.com) one of the RR ips
<mvo> \sh: ask Znarl about archive.u.c problems, he will know
<\sh> Znarl: ping what's wrong with 82.211.81.182? Looks like it doesn't answer correctly anymore or no more :)
<bddebian> Heya folks
<sivang> yo bddebian ! long time
<bddebian> Aye, hows it going sivang?
<Znarl> \sh : This has been solved now.
<pef> hello
<bddebian> Heya pef
<\sh> Znarl: cool thx :)
<pef> hey bddebian :)
<\sh> GOD^Wbddebian :)
<bddebian> Hi \sh!!  How you been?
<dholbach> infinity, lamont-away: do you have any idea, why libx11 has not been considered to build yet?
<jbailey> bddebian: Decided you *do* in fact love us again? =)
<seb128> dholbach: maybe because buildds were down for the whole afternoon?
<bddebian> jbailey: I have always loved you.. ;-)
<jdub> seb128: don't bring facts into the discussion
<dholbach> seb128: that's a clever answer
<bddebian> jbailey: Actually I just came back to make elmo, infinity, and others lives hell again.. ;-)
<siretart> does anyone know where the -transcoded fonts went?
<siretart> fonts gtk1 look UGLY without them
<seb128> dholbach: it has built now
<dholbach> ooh nice
<seth_k> bddebian, ahhh! you're back!
<bddebian> Kinda.  How have you been seth_k?
<seth_k> good bddebian, just finished up fall semester and am heading home today :)
<bddebian> Cool
<\sh> elmo: please sync gnotime , knemo , ksynaptics , partimage , survex , netmrg , libcapsinetwork , libicq2000 from unstable, dropping ubuntu changes, thx
<Diziet> Bah, looks like I'm defeated by ffox.  I'll just fix a couple of those easy bugs and think about the complicated ones after Christmas.
<dilinger> oh man, that's a riot
<dilinger> http://www.zwane.com/blog/?p=76
<mdke> The following packages will be REMOVED:
<mdke> [...]  ubuntu-desktop
<mdke> ??
<azeem> are you trying to remove a part of ubuntu-desktop?
<mdke> no, just a dist-upgrade
<mdke> it's removing gnomemeeting, that might be it I guess
<jdub> mdke: don't dist-upgrade unless you really know you want to
<mdke> it was only X stuff kept back from a normal upgrade, so i thought I might as well give it a go
<mdke> oh perhaps not
<mdke>   libgl1-mesa libgl1-mesa-dri libpt-plugins-alsa libpt-plugins-v4l
<mdke>   libpt-plugins-v4l2 libx11-6 libx11-dev
* mdke waits
<jdub> so the only thing that needs libopenal0 in desktop appears to be rss-glx
<xhaker> BenC, you there? do you know why ipw2200 in your kernels are not monitor mode'able
<BenC> xhaker: I just build the source that I download, not sure why it would not be enabled (if in fact it should be)
<BenC> maybe something to do with the firmware?
<xhaker> i was thinking that also
<xhaker> but the firmware is there, including the monitor mode ones
<xhaker> could udev be "forgetting" to load then too?
<BenC> does dmesg say it loaded it? and does it say it loaded the right one?
<xhaker> the firmware? i don't think dmesg spits anything about firmware
<BenC> ipw2200 should say whether it loaded firmware or not
<xhaker> it doesn't say
<xhaker> but it does say something i already told you before
<BenC> ah, you need debug enabled
<xhaker> Warning: PCI driver ipw2200 has a struct device_driver shutdown method, please update!
<BenC> that's a warning
<BenC> doesn't affect operation
<xhaker> i know, have you tryed compiling it without the struct?
<BenC> you can't compile it without the struct :)
<xhaker> ;)
<xhaker> i'll enable debugging a see what it says
<xhaker> brb
<BenC> it's the shutdown method that is attached to the struct
<hub> hi
* sivang is surprised to see dh_make supports cdbs
<BenC> xhaker: CONFIG_IPW2200_DEBUG
<jbailey> sivang: It does a horrid job of it.
<hub> apparently the latest kernel make my startup hang
<hub> on "Locating and activating hardware"
<xhaker> BenC, shouldn't i be able to just pass debug=1 to modprobe?
<BenC> no, because CONFIG_IPW2200_DEBUG is not set
<hub> kernel 2.6.15-8.10
<hub> I switched back to 2.6.12-9.23
<BenC> the compile time option has to be enabled for the runtime option to work
<sivang> jbailey: ok, then I'll refrain from using it :)
<BenC> hub: check bugzilla.ubuntu.com for similar reports for the "linux" component, and if you don't see one, file a bug
<xhaker> BenC, so it think i'll have to pass :/
<xhaker> s/it/i
<hub> benC I was logging in on Launchpad :-)
<BenC> bugzilla
<hub> ok
<BenC> I don't use launchpad yet, until they put everything over there
<hub> BenC: no problem :-)
<BenC> thanks
<sivang> jbailey: I see there another hacker besides Joey now, Craig Small
<sivang> jbailey: (in dh'd made rules)
<hub> BenC: bug 21127
<hub> BenC: what do you mean by "boot into recovery"?
<HiddenWolf> hub, select the second option in grub when booting
<hub> HiddenWolf: I don't have grub
<hub> because grub never worked on this machine
<hub> I have Lilo
<HiddenWolf> lilo then.
<hub> LinuxOLD is the other option
<hub> that is what I have booted with
<HiddenWolf> hm.
<HiddenWolf> kernel          /vmlinuz-2.6.12-10-k7 root=/dev/mapper/Ubuntu-root ro single
<HiddenWolf> that's the line for my rescue option
<HiddenWolf> adjust for your kernel version and root location.
<hub> boot in signle user? ok
<HiddenWolf> Why is dapper still getting new Firefox 1.49-RC3 uploads? Wouldn't 1.5 be more logical?
<HiddenWolf> Diziet, Thanks for fixing bug 17461, btw
<crimsun> 1.5RC3 _is_ 1.5.
<HiddenWolf> crimsun, if the package isn't called 1.5, people won't see it that way. :)
<crimsun> provide a patch for the cosmetics, then.
<Nafallo> Accepted firefox 1.4.99+1.5rc3.dfsg-1ubuntu6
<Nafallo> 1.5rc3 is the package
<HiddenWolf> Nafallo, nothing in that name says 1.5 final. :/
<HiddenWolf> at least, not to me.
<Nafallo> well, it's not final. it's rc3
<HiddenWolf> upstream is, right?
<HiddenWolf> but never mind
<Nafallo> is final even out?
<crimsun> 1.5rc3 is final.
<Nafallo> http://www.mozilla.org/projects/firefox/ says latest is rc3, which we have.
<Nafallo> crimsun: how silly not to name it 1.5 then? :-)
<HiddenWolf> Nafallo, http://www.mozilla.com/ does
<HiddenWolf> crimsun, firefox switched from .org to .com to give it corporate credibility
<Nafallo> lol, how... dumb :-P
<HiddenWolf> Nafallo, not really. You can't sell services, too much merchandise or whatever from a foundation.
<HiddenWolf> Nafallo, make the foundation own a company, and you can exploit yourself to the full extend of the law.
<HiddenWolf> Nafallo, and companies like dealing with other companies. :)
<Nafallo> HiddenWolf: huh? I was referring to mozilla.com/firefox, they've dropped /products in the url.
<crimsun> HiddenWolf: a simple search will confirm that 1.5rc3 is 1.5.
<HiddenWolf> crimsun, probably best to patch the name of the package then. I won't be the last that's confused.
<Tonio_> hum........
<Tonio_> found a little problem with the latest kernel....
<jpatrick> Hi Tonio_ 
<Tonio_> tun device doesn't seem to work...
<Tonio_> hi jpatrick  :)
<Tonio_> sudo morprobe tun && ifconfig -a
<Tonio_> gives me nothing
<Tonio_> as consequence my openvpn client doesn't work anymore
<Tonio_> was the kernel build with tun option ????
<Tonio_> tried on 3 machines, same problem....
<Tonio_> can someone confirm that he has the same problem ?
<mgalvin> Tonio_: you might what to ask that on #ubuntu-kernel
<Tonio_> mgalvin: k, thanks for the link ;)
<mgalvin> np
<lucasvo> jdub: is there any info about the ubuntu-on-tour, will it include Switzerland?
<Treenaks> lucasvo: is Switzerland in Asia? :)
<lucasvo> Treenaks: no
<jdub> lucasvo: the asian business tour won't, because switzerland has not yet annexed itself to, say, singapore. though that would be an interesting mix, and i would fully support it if you decided to do so.
<Treenaks> https://wiki.ubuntu.com/AsiaBusinessTour
<lucasvo> https://wiki.edubuntu.com/UbuntuWorldTour?highlight=%28ubuntu%29%7C%28on%29%7C%28tour%29 < lol produces internal server error
<Seveas> jdub, lol :)
<lucasvo> jdub: and the swiss buisness tour :D ?
<Treenaks> Swissness tour :)
<lucasvo> By "Importance" or specific criteria - For example, Top Ten Cities by population: Tokyo, Mexico City, Sao Paolo, Mumbai, New York, Shanghai, Los Angeles, Lagos, Calcutta, and Buenos Aires. < definately not CH
<jdub> lucasvo: i am coming to belgium soonish
<lucasvo> By LoCo Involvement -Visit strong LoCo communities or perhaps places with low LoCo turnout. < not yet
<Treenaks> jdub: FOSDEM?
<jdub> lucasvo: oh, the world tour is something a bit different
<jdub> Treenaks: YES
<lucasvo> jdub: it is not that far from CH
<jdub> my first fosdem
<jdub> lucasvo: yes! so you should come to fosdem :)
<lucasvo> jdub: hm, what's the difference?
<Treenaks> hmm.. 
<jdub> lucasvo: the world tour was an idea for something slightly bigger, but we're splitting it up between regions and topics of interest now
<lucasvo> jdub: a) I have school b) I don't know how to drive a car c) my parents wouldn't allow it
<Treenaks> lucasvo: Brussels is a major train hub; Planes work too;
<lucasvo> $$$
<jdub> lucasvo: hrm. same position as me. except swap parents for wife.
<lucasvo> what about 22c3?
<jdub> and s/school/work/
<jdub> lucasvo: so i will probably do some other things while i'm over there, and that could include switzerland - look out for another tour announcement, i might do another call for petitions :)
<lucasvo> What will people do at the Conference? Classes on how to do important types of advocacy including: Lobbying governments;
<lucasvo> *lol*
<lucasvo> jdub: you could hold a talk at lugs
<\sh> jdub: you're coming to FOSDEM? well I hope I can make it :)
<jdub> \sh: and linuxtag
<jdub> lucasvo: that's what the petition is for ;-)
<lucasvo> jdub: where is linuxtag?
<lucasvo> Karlsruhe?
<\sh> jdub: well...actually I have to check if I have the time for coming to fosdem..eventually together with ogra :)
<dholbach> Wiesbaden, I think
<\sh> wiesbaden...new locations
<lucasvo> ah, ok
<mvo> oh, wiesbaden? nice
<dholbach> good night everybody
<mvo> have fun dholbach 
<lucasvo> wiesbaden, it is quite near to CH isn't it? :D
<dholbach> merci
<lucasvo> good night dholbach... 
* mvo runs as well
<\sh> lucasvo: na...it's next to frankfurt/main
<lucasvo> \sh: hm :(
<\sh> lucasvo: from basel I think 2-3 hours drive
<lucasvo> ok
<lucasvo> so 4h from zurich
<Seveas> jdubuntu @ fosdem?
<Seveas> cool :)
<\sh> Seveas: Project "Dutch Weed for Jdubuntu in Beligium"? ;-)
<Seveas> rofl
<Seveas> I could arrange that :)
<Seveas> it'll just remind him of the huge buttplug :p
<\sh> Seveas: I mean jdubs "orange dress at ubz" was a message to the netherlands :)
<Seveas> hehe
<\sh> "This is Jdub Of Ubuntu, resistance is futile..we will assimilate you" (sorry jdub)
<jdub> s/assimilate/inhale/
<Seveas> hmm, that calls for a little gimp sideproject
<\sh> "dum dum de dum *ubuntu* de dum dum dum *ubuntu*"
<Simira> I'm alive again!!!
<Simira> humtidum.. my desktop still blipping... 
<Simira> has anyone got any idea why my new arctic cooling freezer 64 makes my mainbord go "bipp" at random times?
<\sh> "artic cooling freezer 64"?
<Simira> \sh : cpu cooler for amd 64
<Simira> or freezer :p or something. Really good anyway, except from that noise.
<\sh> Simira: hmmm..It can't be so loud as mine cheap one 
<\sh> but only god knows why my body temperature is increasing again....the whole day it was ok...and now...
<azeem> you're heating up for Friday night!
<\sh> azeem: there is a difference between "why I'm getting hotter" and "my body temperature is increasing"
<jdub> guys
<\sh> going to bed...
<tseng> badgers
<jdub> i'm putting together a list of powertools
<Simira> \sh : it's pretty low, it's just making a short "beep" from time to time. Like indicating a hw-error, which I can't find. 
<jdub> to revive the gnome powertools release suite
<jdub> which i'm going to re-kickstart
<tseng> im a powertool
<jdub> here's what i started with:
<jdub>  * brightside
<jdub>  * deskbar
<jdub>  * devilspie
<jdub>  * gnome-launch-box
<jdub>  * nautilus-actions
<jdub> 
<jdub> any suggestions for additions?
<jdub> i'm thinking maybe tomboy
<tseng>  * openbox
<jdub> tseng: penis
<Seveas> tomboy++
<\sh> jdub: powertools in what meaning?
<tseng> jdub: hm, resapplet?
<jdub> \sh: like, rad utilities that crank up the gnome experience for geeks
<jdub> tseng: hmm...
<Seveas> jdub revelation (which has a funky applet now too)
<jdub> tseng: bit boring. i haven't included netspeed for the same reason.
<jdub> tseng: if the authors propose them, i might
<azeem> jdub: deskbar-applet
<jdub> Seveas: was ist das?
<jdub> azeem: that's deskbar
<tseng> he said deskbar
<Seveas> password manager
<tseng> (which is totally elite)
<azeem> jdub: d'oh :)
<jdub> Seveas: oh, the not g-k-m thingy?
<Seveas> no
<\sh> jdub: oh yes..."comical" a cbz/cbt reader so I can read my fav. marvel comics while I'm compiling
<\sh> but I have to package it first 
<jdub> Seveas: hmm
<jdub> Seveas: i think that's more of an app than a powertool
<azeem> \sh: can you only read them whil compiling?
<azeem> :)
<jdub> \sh: more of an app than a powertool
<jdub> \sh: looks rad though
<jdub> powertools are kind of like extensions
<jdub> strap-on missile-launchers
<jdub> stuff like that
<jdub> batbelt stuff
<jdub> microcrack!
<\sh> well..i'm only using tomboy vi and a terminal...and pbuilder...even with gnome or kde...which makes me not your customer but I'm thinking
<Seveas> an apple dashboard like thingie would be nice
<Seveas> which would be relatively easy to implement as an extension to gdesklets I guess
<tseng> Seveas: ergh
<Seveas> tseng, dashboard is coo
<Seveas> l
<tseng> gdesklets are not
<Seveas> true
<mdke> widely used tho
<thierry> how can I take my gpg key, and get it in my chroot ?
<Seveas> cp ~/.gnupg /path/to/chroot
<jdub> thierry: cp -r ~/.gnupg /wherever/you/want/it
<Seveas> jdub, sshfs is a nice powertoof
<Seveas> tool even
<Seveas> i'm writing a similar thing for gnome-vfs
<azeem> isn't there one already?
<mdke> what does it do?
<Seveas> yeah, buggy as hell....
<azeem> somebody should write an interface between FUSE modules and gnome-vfs
<Seveas> mdke, imagine: mount ssh://server/path /remote/server
<Seveas> azeem, that's what I'm doing
<azeem> generic?
<azeem> cool
<mdke> Seveas, does that help?
<Seveas> mdke, sometimes
<mdke> oh remote/server
<Seveas> I use it a lot olready
<mdke> i was gonna say I use nautilus for ssh transfers
<Seveas> yeah, but not all apps speak gnome-vfs
<Seveas> with this you truly mount them
<mdke> aha
<Seveas> mount computer:/// /somewhere even works
<Seveas> it is of NO use whatsoever, but it works :)
#ubuntu-devel 2005-12-22
<Seveas> it's about time I finish that code
<\sh> ok...good night 
<Seveas> g'night
<Mithrandir> nautilus's ssh module is dog slow, though
<mdke> yeah sometimes it can be annoying
* mdke shouts at language-selector
<mdke> "fix broken packages" ??
<mdke> does language-selector barf if the system is not fully upgraded?
<Seveas> yes
<mdke> oh pants
<Seveas> update-manager and gnome-app-install too
<mdke> including packages being kept back?
<Seveas> dunno about that
<Seveas> poke mvo :)
<mdke> i will file a bug
<Seveas> that's one way of poking :)
<mdke> especially because i don't always get the error message, sometimes it just stops and doesn't do anything
<mdke> god gnome-app-install doesn't even open
<Seveas> poke mvo harder :)
* mdke searches bugzilla
<mdke> i think that might be a feature tho
* mdke open synaptic
<mdke> ok 3 bugs could be considered sufficient poking of mvo for one night, i'll go to bed
<slomo_> lamont, infinity: please give-back mono on ppc... it definitely builds fine here on my ppc
<lamont> slomo_: and what's the error in the log?
<slomo_> lamont: a segfault in mono somewhere... i wonder how we can debug this if it's not temporary... i can't reproduce it here :/
<ryanpg> argh... pitti's not around...
<ryanpg> http://bugzilla.ubuntu.com/show_bug.cgi?id=20564 still is buggy for me but I don't want to reopen it if I'm the only one
<tseng> jdub: hows your list coming?
<ryanpg> am I correct in thinking mplayer-686 cannot currently be installed in dapper due to broken libjack dependencies?
<jdub> tseng: whichwhat? oh!
<jdub> tseng: same
<Sepheebear> there is no more mplayer-686, they're all dummy packs now
<Sepheebear> jdub: since it's a separate package, how about nautilus-open-terminal, not quite a powerdrill but necessary in any geek toolbox
<jdub> Sepheebear: nautilus-actions usurps it
<Sepheebear> havent tried that
<seth_k|lappy> when using the DEB_INSTALL_MANPAGES_blah variable in debian/rules, how can I install two manpages? (the .deb contains two binaries)
<ryanpg> Sepheebear, yeah I know... I just didn't have sources.list configured properly, I got it fixed now thanks though
<crimsun> seth_k|lappy: did you mean that for -motu?
<seth_k|lappy> crimsun, meh, sorry
* seth_k|lappy switches tabs
<Sepheebear> i saw an cool app today Wallpapoz looks nifty but i think only a geek would go for that kind of novelty
<Sepheebear> would definately be an extension though
<ryanpg> Sepheebear, actually I think wallpapoz has a pretty broad appeal
<ryanpg> Sepheebear, aamof a guy new to ubuntu was struggling with installing it in #ubuntu a few days ago iirc
* ryanpg realizes the contradiction of using aamof and iirc in the same sentence :P
<Sepheebear> ryanpg: maybe but i dont know many non-geeks who use more than one desktop
<Sepheebear> using windows has most of them pretty well trained
<ryanpg> Sepheebear, hmm... yet ubunut defaults to four yes?
<ryanpg> ubuntu even
<ryanpg> :D
<ryanpg> wallpapoz is undergoing a rewrite soon though, least that's what I thought
<jdub> considered wallpapoz, but it needs some serious UI love
<Sepheebear> seriously, it has an interface only a mother could love
<ryanpg> hehe, it might satisfy the "gnome is too simple" crowd ;)
<jdub> even powertools should be slick and simple
<Sepheebear> i have some problems with that crowd
<ryanpg> well of course I was j/k hence the "hehe" and ;)
* ryanpg doesn't want to start trouble
<ptlo> speaking of powertools...., gnome could have a set of 'power toys' gui's which could be used to edit "hidden" gconf values - which aren't touched in standard preferences dialogs
<tseng> gtweakui
<ptlo> typical user get "just work", kde users get flexibility
<ptlo> oh, i meant that, power users, sorry
<ptlo> oh, that exists already. thanks tseng
<tseng> np
<ryanpg> not to go too crazy OT but svn gnome-launch-box looks really nifty
<ryanpg> cairo and compositor'ification
<Sepheebear> ryanpg: is g-l-b supposed to be a background app? i remember trying it but i couldnt figure out what it did
<tseng> Sepheebear: its based on quicksilver for macosx
<ryanpg> Sepheebear, I think it's a bit young to know quite what it's supposed to be
<tseng> also similar to deskbar-applet
<tseng> you type something in and it tries to guess what you want
<tseng> email a person, run a program, search for a file
<tseng> google desktop does a bit of the same as well
<ryanpg> tseng, are you one of the g-l-b devs?
<ryanpg> Sepheebear, http://developer.imendio.com/wiki/GNOME_Launch_Box
<zakame> morning all! :D
<tseng> ryanpg: no, i am omniscient
* tseng kids
<tseng> im neither
<whiprush> jdub: rodrigo's /etc/motd patch, gnome-launch-box (too immature maybe), istanbul. (My short list from work)
<whiprush> I think the rest have been mentioned.
<whiprush> oh, hardware-monitor is pretty spiffy also.
<jdub> whiprush: g-l-b is already in, patches aren't eligible ;-) and istanbul should be integrated into gnome-panel-screenshot for 2.14 (or i will yell!)
<jdub> hardware-monitor...
* jdub checks out
<whiprush> it's a nicer cpu/ram/temp monitor
<whiprush> *shrug*
<jdub> by ole!
<jdub> heh, gtkmm
<jdub> hrm, the sshot link is dead
<jdub> whiprush: you running it atm?
<whiprush> yep.
<jdub> got a moment to flickrise? :)
<whiprush> yeah gimme a minute
<crimsun> took me a moment to parse "flickrise"
<zakame> elmo: please libgettext-ruby, libgtk-trayicon-ruby, and ruby-gnome2 from Sid, overriding Ubuntu changes, on behalf of lucas.  Thanks! :)
<whiprush> jdub: I'm nx'ed in and screenshotting doesn't seem to work: http://knoppix.ru/img/140704-1.jpg
<whiprush> that's the general idea
<jdub> hrm, can't get there
<whiprush> http://www.secs.oakland.edu/~castro/140704-1.jpg
<jdub> hmm
<jdub> i think i'll leave that one to author proposal after powertools is announced
<whiprush> heh
<jdub> bit wary of duplication
<Sepheebear> that nautilus-actions thing is cool, i dont see a package for it though. is it going to be part of gnome?
<infinity> Hrm.  I there a simple unix command line tool to wrap lines?
<infinity> (Don't say perl and libtext-wrapper-perl)
<lamont-away> infinity: fold
<lamont-away> :-)
<infinity> Ahh.
<infinity> Too late, I already added unnecessary complexity.
<Sepheebear> anyone know what's the diff between vim-gnome and vim-gtk?
<infinity> They both suck differently?
<infinity> If I had to guess, I'd say -gtk uses GTK libs for rendering, but doesn't do all the wonderful GNOMEish things that -gnome does (like gnomevfs, for instance)
<Sepheebear> vim-gnome doesnt do gnomevfs here
<Sepheebear> they seem to be the same thing, im wondering the need of 2 different packages
<infinity> It's linked to all the gnome libs (including gnomevfs), so I'd say it's  abug if it doesn't use it.
<LaserJock> Sepheebear: I have often wondered the same thing
<LaserJock> I never know quite what to install but I usually do vim-python.
<Sepheebear> just noticed i've secretly been switched to vim-gtk since breezy's release. i haven't noticed the difference until just now
<Sepheebear> vim-gnome has no .desktop vim-gtk does
<Sepheebear> oh wait neither of them do
<LaserJock> yeah, I think there is a bug report somewhere about that
<Sepheebear> yeah http://bugzilla.ubuntu.com/show_bug.cgi?id=7059
<Sepheebear> nope infinity vim-gnome really doesnt do gnomevfs
<shadeofgrey> does dapper boot yet?
<shadeofgrey> i wanna see it really bad
<LaserJock> sure, why not
<Sepheebear> dapper wasnt booting?
<shadeofgrey> various friends told me a week ago that when they updated to it it refused to even boot properly
<LaserJock> well, there was a bit of a struggle when the new kernel and udev stuff got going
<shadeofgrey> is it safe for somebody linux-dumb like myself?  im physically handicapped andam trying to help out with accessibility
<shadeofgrey> if not ill wait
<shadeofgrey> i just really wanna see it
<shadeofgrey> i heard its pretty if you have a nice graphics card
<shadeofgrey> which i do'
<shadeofgrey> ...though i must confess im lusting for a 30" cinema display like, daily now
<LaserJock> well, it's hard to make a recommendation. I mean it works fine for me pretty much, but that doesn't mean it is going to work for you
<shadeofgrey> all i need is firefox, thunderbird, and openoffice to work
<shadeofgrey> thats it
<shadeofgrey> oh ...  andsomething that plays mp3s
<shadeofgrey> thats basically all i need
<LaserJock> all of those work well for me. Firefox is a beta version, but seems to work well for me (sometimes it takes a lot of cpu for a few seconds)
<shadeofgrey> please tell me they changed the really pussy startup screen ala winxp
<shadeofgrey> please please please
<LaserJock> hmm, not quite sure of what you are talking about. At boot? or at Gnome startup?
<shadeofgrey> at boot
<Sepheebear> dont like the usplash?
<shadeofgrey> well
<shadeofgrey> i would
<shadeofgrey> except it sucks
<shadeofgrey> like, rancid ardvark balls.
<infinity> The artwork hasn't changed (yet), if that's what you mean.
<shadeofgrey> pardon me for being blunt bout it
<Sepheebear> lol just disable it
<infinity> It's being worked on.
<shadeofgrey> i just thought we'd left 16 bit color when we all chose to not use windows
<infinity> 4-bit, you mean.
<infinity> 16-colours total.
<infinity> And that won't change, sorry.
<shadeofgrey> why not?
<crimsun> some clients don't have fancy displays
<infinity> Too many graphics cards have a hissy fit when you try to initialise them in other modes.
<shadeofgrey> ill PAY to have it changed
<Sepheebear> isnt that a limitation of the fb driver?
<shadeofgrey> i swear
<infinity> shadeofgrey : Pay for everyone to use the same video card, and we'll talk.
<shadeofgrey> dont have that much cash
<Sepheebear> that'd be nice
<infinity> Sepheebear : Well, yes and no.  We're using vga16fb specifically because other framebuffer initialisations (like vesafb) can leave people with machines that won't properly suspend/resume, etc.
<shadeofgrey> but in all seriouisness, if i went out and did something rash, like bought an Nvidia 7800 card and a 30 inch cinema display would ubuntu still work?
<infinity> Yup.
<infinity> Works fine on such shiny new hardware.
<infinity> You'll still hate usplash, but the rest will make you happy.
<crimsun> it also scales down to the lower end equipment, which is equally important.
<shadeofgrey> im considering selling my spare wheelchair to get the money for a cinema display
<floam> usplash doesn't look bad on high resolution framebuffer consoles
<shadeofgrey> ...trust me - for a disabled person - thats drastic
<floam> other than the obvious dithering on the logo
<infinity> floam : The artwork is in the process of being redone to use less (or no) dithering.
<floam> infinity: cool
<shadeofgrey> i have a 19 inch samsung right now
<shadeofgrey> but 30" of cinema goodness is enoughto make any of you drool
<infinity> The breezy artwork was fairly obviously not designed with 16 colours in mind, which is why it looks a bit icky.
<shadeofgrey> well
<shadeofgrey> most of you
<floam> infinity: it'd be intersting if usplash could figure out how many colors are available and have multiple images to used based upon that.
<infinity> floam : I can easily do that, but the more images we stuff in the initramfs, the more it bloats out for very little gain.
<shadeofgrey> so is the general consdcensus that i should wait on dapper?
<floam> infinity: well, I have a 16M color console, I'd be happy with the same stuff with more colors.
<floam> ah, true.
<infinity> floam : I've already been tossing around the idea of higher res images for people botting with vesafb.  But.. Not sure if it's worth it.
<infinity> I could make it some obscure config file option or something, so you only get one image by default, but that's sketchy.
<shadeofgrey> by the way - infinity -0 and everybody else i appreciate everything you do to make ubuntu possible.  and i mean this very seriously, its improved my quality of life
<shadeofgrey> i know that sounds dumb...  but its true
<Sepheebear> how does one switch to vesafb to test out these hi-res images?
<floam> infinity: the space issue was something I had not thought of
<shadeofgrey> and thanks for tolerating my presence here on occasssion.  i know im not supposed to be here
<infinity> shadeofgrey : Doesn't sound dumb at all.  There's a reason I've spent the last 6 years working on Debian (and now Ubuntu), and it's not all about personal satisfaction. :)
<floam> even still, a lot of superficial people care quite a bit about that stuff, especially first impressions
<floam> though XP looks like crap while it's booting too, so maybe no one really minds
<infinity> floam : Yes, well aware of the superficiality issue. :)
<shadeofgrey> im very willing to help out in any way i can...  except i cant code for shit
<shadeofgrey> i walk better than i code
<shadeofgrey> and ive never walked
<shadeofgrey> so
<infinity> floam : The other idea floated was just to make the boot screen so simple that it doesn't matter (like the MacOS boot logo, which is tiny, unintrusive, etc)
<floam> infinity: yeah.
<shadeofgrey> ...now... if you needed help with documentation, now your talking..
<shadeofgrey> cause i write for a living
<shadeofgrey> novels are my life
<infinity> shadeofgrey : We ALWAYS need help with docs.  It's the one thing programmers really, really hate doing.
<shadeofgrey> i love that kind of shit
<floam> infinity: is there any plans to make it easier for people to setup vesafb? right now, it seems the only way to do that is just setting vga= and looking up the code in the kernel tree
<shadeofgrey> where do i sign up?
<infinity> (and, as such, we never get around to doing it, unless we're really bored, or getting paid to do so)
<floam> which 99% of most people wouldn't know about
<shadeofgrey> also
<floam> it's not so much of a deal on analog displays, but LCDs can be hard to read at low resolutions because of interpolation
<shadeofgrey> i know this is going to sound REALLY dumb but...  is there ANY way you guys know of that would make ubuntu capable  of running dragon naturally speaking?
<infinity> floam : I hadn't made any plans to make it easier.  Heck, my vga= line isn't even in the kernel tree, I had to dig into the source, do some complex math, then guess a bit. :)
<floam> heh
<shadeofgrey> if that were possible you'd have disabled people in droves banging down your digital door
<floam> infinity: actually, I think the tree only had the hexidecimal codes
<floam> I think I looked mine up on google
<floam> 794, I think.
<shadeofgrey> seriously is there an opensource equivelsnt that works even 25% as good as DNS?
<infinity> shadeofgrey : If it doesn't run under WINE, I suppose you could bug the winehq guys to make it a priority.  Do we not ship anything useable for speech recognition?
<shadeofgrey> infinity:  not that i know of, but that doesnt mean much
<infinity> floam : You can boot with the hex codes... Mine's vga=0x343
<floam> infinity: I know.
<infinity> Which is 835, I guess.
<shadeofgrey> infinity: seriously how do i start helping withubuntu docs?  im ready...  sign me up
<floam> I'm just saying my particular mode I must not have gotten from the tree because it's decimal
<floam> I tend to have to do detective work to figure out what I was thinking, my memory sucks.
<shadeofgrey> ill do all the docs you want in exchange for a 30" cinema display
<infinity> shadeofgrey : To be honest, I have no idea.  Let me poke someone.
<shadeofgrey> i hope that doesnt piss off the accessibility people.  can i be part ofg both?
<floam> shadeofgrey: volunteer work tends not to get you free things
<Sepheebear> shadeofgrey: https://wiki.ubuntu.com/DocumentationTeam
<whiprush> shadeofgrey: #ubuntu-docs and https://wiki.ubuntu.com/CategoryDocteam
<whiprush> tons of links on that page
<shadeofgrey> floam:  yeah i know... but ubuntu has given me so much, that i honestly wouldnt mind donating a few hours on the weekend helping ouyt with the docs
<floam> shadeofgrey: I hope you grammar you use while working on the documentation is better than that you're using on IRC :)
<whiprush> oops, that should be #ubuntu-doc. No S on that
<floam> s/you grammar/the grammar/
<shadeofgrey> my grammar doesnt suck when its important
<shadeofgrey> besides, wouldnt there be like, somebody above me to insure my contributions dont suck?
<crimsun> if you mean teammates, yes, not anyone technically "above" you.
<floam> most likely yes, but that doesn't obviate the need to have good writing skills when you accept a position where you are writing
<Sepheebear> this isnt sex, i think i'd find another thing to do if i wanted people on above me all the time
<shadeofgrey> okay...  well....  I promise i wont let anything out the gate that sucks
<shadeofgrey> hows that?
<shadeofgrey> okay heres a question...  what are my options for creating a mail server using ubuntu
<shadeofgrey> i know hula - but i wont use that because its so...  not ready
<shadeofgrey> are there any other options?
<shadeofgrey> correction -- robust and stable options?
<Sepheebear> postfix is supported
<shadeofgrey> and by the way...  if i installed ubuntu in server mode that would mean NO X - no gnome no nothing right?
<shadeofgrey> is there a way to specify which packages you want when installing in server mode?
<shadeofgrey> i shouldnt be asking you guys this
<shadeofgrey> your going to get pissed.
<shadeofgrey> okay.. ill depart now -- thanks a lot for the guidance in starting to help with docs
<shadeofgrey> as soon as i get approved...or whatever... i promise ill jump right in
<shadeofgrey> and just for the record
<shadeofgrey> id get every last one of you something for christmas if i could afford it
<shadeofgrey> but unfortunately i make $10 an hour
<shadeofgrey> so my genuine thanks will have to do
<shadeofgrey> any of you can message me while im connected if theres anything i can do to help you
<shadeofgrey> ill drop whatever im doing to lend a hand...
<shadeofgrey> i owe you guys that much
<shadeofgrey> peace everybody.
<TerminX> why is libnspr-dev putting stuff in /usr/include/mozilla/nspr/nspr instead of /usr/include/mozilla/nspr?  packaging error?
<whiprush> hi jerome!
<jsgotangco> whiprush, dude!
<jsgotangco> whiprush, what's up?
<whiprush> jsgotangco: just doing the Asia tour thing for the fridge.
<jsgotangco> awesome
<whiprush> off to the dubster for final editing-love.
<whiprush> jsgotangco: are you also touring or what?
<jsgotangco> whiprush, probably just the nearby countries its not that expensive to go there really
<whiprush> cool.
<jsgotangco> and 3 of the cities near mine are just 2 hour flights
<whiprush> good good.
<whiprush> local advocacy is so underrated. :)
<jsgotangco> i've actually been helping out with them even before it was announced
<whiprush> excellent.
<jsgotangco> wonder if NA will have something similar
<jsgotangco> i might visit my folks in chicago around June
<jsgotangco> i'll make sure i drop by at detroit =)
<whiprush> let me know, only a 6 hour drive for me.
<dabaR> Hi. It says the breezy version of nvidia-glx is 7667, is that true?
<whiprush> for some reason chicago doesn't seem to have a strong OSS community as the rest of the midwest US. easily fixable though. the gnomejournal guys live close to there.
<jsgotangco> hmm i didnt know that
<whiprush> making your visit a local ubuntu event shouldn't be too difficult.
<dabaR> It says being that Ubotu reports that. 
<whiprush> jsgotangco: bed for me, keep up the good fight!
<jsgotangco> whiprush, later dude, i'm out for a party in a few hours (only 3pm here)
<dabaR> jsgotangco: you are such a party animal.
<jsgotangco> dabaR, dude, 9 days before christmas and its a weekend we should!
<dabaR> heh. OK, well, Im gonna let my question stay on the screen now.
<jsgotangco> dabaR, dude mine gives the same version
<jsgotangco> 1.0.7667-0ubuntu25.1
<dabaR> Ya, and this persistent dude on #ubuntu is trying to convince me that Ubotu is lying, which is impossible. The ubotu never lies.
<dabaR> OK, well, thanks for your time.
<jsgotangco> ahhh
<jsgotangco> he doesn't konw what he's saying then
<jsgotangco> =)
<dabaR> Ya, and he is giving his great advice to others...which is to install the nvidia drivers from nvidia.
<dabaR> And he has all this information... like, this driver number has issues with this...and this with that. And so on. Anyhow, Im just tired, I should ignore him.
<jsgotangco> oh well later then!
<dabaR> Im on the Internet!!!1
<crimsun> elmo: please sync xdb, turck-mmcache and kcheckgmail from Sid, overriding Ubuntu changes, thanks
<Pygi> wb sh
<\sh> moins
<crimsun> feeling better?
<crimsun> elmo: please sync libparagui1.0 from Sid, overriding Ubuntu changes, thanks
* #ubuntu-devel  [freenode-info]  If you're at a conference, please contact freenode staff to make sure we've made special allowance for many users coming into our network from a single internet address ( http://freenode.net/faq.shtml#gettinghelp ). Private messages from unregistered users are currently blocked, except to network staff, services and participating registered users ( http://freenode.net/faq.shtml#privmsg )... Thanks!
* mdke cries at the spam going to the mailing lists
* netjoined: irc.freenode.net -> brown.freenode.net
<mdke> anyone know what time the CC meeting is gonna be at next week?
<Pygi> probably 1:00 UTC or 2:00 UTC
<mdke> eh? how come?
<Pygi> I don't know...this is just my guessing....
<StevenK> The last one was 14:00 UTC, does that make the next one 20:00 UTC?
<StevenK> Er, doesn't
<mdke> it would do normally, yes
<mdke> but the time appears not to have been set
<shadeofgrey> could somebody please point me in the direction of a good sources.list file for upgrading to dapper
<shadeofgrey> im ready to take the plunge, damnit
<jdub> same as your breezy one, s/breezy/dapper/
<shadeofgrey> really?
<shadeofgrey> and i should comment out the other ones like backports and shit right?
<mdke> shadeofgrey, https://wiki.ubuntu.com/ExampleConffiles, then as jdub says, substitute breezy for dapper
<shadeofgrey> now okayt
<mdke> you can comment out backports, security, and updates
<shadeofgrey> heres my big question
<shadeofgrey> i upgraded my version of firefox to 1.5 manually
<shadeofgrey> the NON ubuntu version...  which is a thousand times faster
<fabbione> shadeofgrey: #ubuntu please..
<fabbione> this is offtopic here
<mdke> shadeofgrey, by the way, they will help in #ubuntu
<shadeofgrey> okayokay
<shadeofgrey> sorry
<mdke> hey jdub 
<zul> stupid oprofile..grumble grumble
<sivang> weird, I couldn't connect to freenode from one of the servers I'm using. had to switch to the one in .de
<Riddell> see freenode's news page
<sivang> Riddell: I was trying to connect from muse, have you had troubles as well?
<Riddell> sivang: freenode's news page reveals all
<mdke> sivang, everyone has, see freenode's news page
<Treenaks> doesn't make freenode less crap ;)
<sivang> yes, reading about the spambots now
<Treenaks> s/^/reading the news page 
<sivang> ok, I'll retry with chat.f.n
<Treenaks> chat.freenode and irc.freenode are _identical_ from my end...
<Treenaks> I had to switch to irc.eu.freenode
* infinity fails to see how changing the hostname protects against anything...
<infinity> (longterm, that is)
<Treenaks> infinity: Lilo-logic
<sivang> Treenaks: also from pitti's server, but from muse it's not. odd
<sivang> infinity: me as well
<sivang> ok, it worked.
<sivang> ah, that's better.
* sivang wonders if have imlib2 in dapper
<azeem> lifeless: http://people.debian.org/~mbanck/opensync/
<azeem> eh, ECHAN, sort of
<lifeless> pushing an update to the debian dir
<lifeless> for the libtool and debhelper deps
<sivang> hmm, dapper just hung up on me.
<sivang> it's also somewhat slower then it was 2 upgrades ago
<mdke> dapper is wicked fast for me
<mdke> if completely broken :(
<sivang> mdke: cool for you then...
<sivang> mdke: what about freezes ? has it went frozen for you yet?
<mdke> no
<mdke> but I have no browser or help :)
<sivang> mdke: ah, well, I'm mostly operational :)
<sivang> gues you can't have it all
<mdke> lol
<Tm_T> heh, alsa-source package doesn't install properly
<Tm_T> Setting up alsa-source (1.0.10-2) ...
<Tm_T> dpkg: error processing alsa-source (--configure): subprocess post-installation script returned error exit status 127
<Tm_T> known issue?
<siretart> err, in the new cups world order (dapper), how is the user supposed to let other computers in the network print on his printer?
<Pygi> siretart: samba?
<siretart> Pygi: I mean letting other ubuntu computers print on his printer. not necessarily windows computers
<Pygi> k, siretart, just a moment pls
<siretart> well, I managed doing it by hacking my cupsd.conf, but I cannot imagine thats the way it is supposed to work
<ogra> siretart, IPP ?
<ogra> as windows does nowadays 
<siretart> ogra: well, the default config makes cups only listen on localhost
<siretart> ogra: and I only found how to activate Browsing, so I can find printers from other computers, who do activly propagate their printers
<ogra> you dont want to listen... you want to share, right ? 
<siretart> I want the user to be able to have 2 computers, (laptop and workstation) with the printer at the workstation to be able to print from his laptop
<siretart> if my father asks me that, I'd like to give him simple instructions
<ogra> if i look at my usb printer's settings, its set as IPP network printer with address usb:/dev/usb/lp0
<siretart> as said, I managed it over here with fiddling cupsd.conf, but that cannot be the way to go
<ogra> works fine for other network systems, as well as windows
<ogra> no need to touch cups configurations at all
<siretart> but how can this work?
<siretart> I mean, cups listens on localhost by default!
<ogra> not if the printer is IPP 
<ogra> thats what IPP is for ...
<siretart> the printer is connected via usb to the workstation
<ogra> and on your client, if you switch on browse, it scans for IPP exported printers in the network
<ogra> yes
<siretart> hm
<ogra> but the driver is IPP network printer, with local address usb:/dev/usb/lp0
<siretart> aaah, now I got it..
<siretart> hm. still not that obvious. do we have this documented somewhere?
<ogra> i dont think so, but i didnt select anything special ...
<ogra> i just plugged in the printer back then and used the offered defaults
<siretart> hm
<siretart> will test this again, after I upgrade the next machine to dapper
<siretart> thanks for explanation
<ogra> btw, the config was made on hoary, i didnt change it since then ... so the defaults might be different today
<ogra> (but i doubt tht)
<ogra> *that
<siretart> hm. interesting
<lathiat> whos the apt guru?
<sivang> lathiat: mvo
<lathiat> http://bur.st/~lathiat/apt-broken.txt
<lathiat> minor cosmetic bug
<lathiat> but interesting
<lathiat> oh actually ignore me
<lathiat> reinstalls just plain dont show up
<mdke> is anyone around to approve/deny breezy-updates while mdz and Kamion are away?
<Pygi> \sh maybe? but he is away now
<ogra> he has no power for such stuff
<mdke> ogra, can anyone else, do you know?
<Pygi> ogra: oh,k
<ogra> nope
<mdke> ok thanks
<ogra> mdke, but they should both be back on momday 
<mdke> ogra, oh awesome, np then
<mdke> do unapproved packages in breezy-updates get dropped after a certain time?
<ogra> i think they idle in the queue until someoine does
<mdke> oh good
<shawarma> slomo: ping?
<slomo> shawarma: pong
<shawarma> slomo: It was you who asked me to look at the libmms soname thing, right?
<slomo> shawarma: yes
<shawarma> It's actually quite funny because they actually put the -version-info on the libtool command line, but left it at 0:0:0.. I looked at the interfaces and they are apparantly compatible, so it's only the age thing that should be fixed.
<shawarma> AFAICS that's not too important, is it? I'll fix it in CVS for the next release, but is the age part of the soname really very important?
<Checksi> hello
<slomo> shawarma: well... not too important but it would be nice to have it right ;)
<shawarma> slomo: How did you spot it?
<slomo> shawarma: objdump on the library ;)
* fabbione looks at slomo 
<slomo> fabbione? 
<fabbione> slomo: http://buildd.mmjgroup.com/buildLogs/x/xine-lib/1.1.1-0ubuntu4/
<fabbione> slomo: look at the sparc failure (46K)
<fabbione> and fix.. please :)
<slomo> give me a sparc to fix it ;)
<fabbione> you don
<fabbione> ARGH
<fabbione> you don't need a sparc to fix it :)
<fabbione> but i can build attempts to fix :)
<slomo> oh right... just a problem with an include... i already feared another assembler mess in ffmpeg ;)
<slomo> i'll take a look later... but on monday this problem will move out of xine-lib anyway
<fabbione> slomo: i am ok with timing :)
<fabbione> it was just to make you aware of that
<ogra> seb128, in a .desktop file, if i have a .xpm and a .png with the same name in .../pixmaps/, which is preferred ? 
<seb128> png
<ogra> seb128, (thinking aout the tuxpaint bug)
<ogra> *+about
<seb128> is the bug about using xpm?
<ogra> i suspect there is something broken with the image
<ogra> nope, but tuxpaint ships and installs both
<shawarma> slomo: ..well, of course, but what made you look in the first place?
<slomo> fabbione: it's also ftbfs on ia64 currently... but as ffmpeg/faad will move to another package on monday it will build again there :) but i guess i can fix it after it moved... so many ftbfs to handle lately :(
<slomo> shawarma: new upstream version of a library ;)
<ogra> seb128, the breakage occurs if you scale it apparently
<ogra> i.e. resize the panel
<shawarma> slomo: You always do an objdump on new libraries? 
<fabbione> slomo: as i said i am not in a hurry :) just be sure that all the splitting you are doing will still allow me to watch DVD :)
<seb128> ogra: I though it was about the menu item
<fabbione> slomo: since xine is my primary source of fun on my tivo box :P
<ogra> seb128, which uses a image 
<seb128> they are not dependant of the panel width
<fabbione> slomo: and yes.. i am running dapper on that toy :P
<slomo> shawarma: yes... when they use 0:0:0 at least ;)
<ogra> seb128, if i resize the panel, the image gets scaled ...
<seb128> the menu items?
<slomo> fabbione: oh nice, someone to test it later :P i don't touch anything dvd related but please report anyway :)
<shawarma> slomo: But you don't know that until you've done the objdump.. :-/
<ogra> seb128, the bugreporter talks about a menu item he added to the panel
<fabbione> slomo: did you ever see me being silent? ;) i suggest you get an helmet and dig a bunker.. just in case i decide to poweron the sodomotron :P
<slomo> shawarma: sure... the library is called libfoo.so.0.0.0 ;)
* fabbione declares time to install hppa
<slomo> fabbione: oh... but be carefull, when you kill me i can't fix anything ;P
<shawarma> slomo: Oh,right.
<ogra> seb128, see comment #6
<seb128> ogra: I don't know this bug, I don't really what you are talking about, let me open it
<seb128> I've tried like 10 seconds 3 months ago
<seb128> didn't get any crash
<ogra> me neither 
<ogra> but the last comment suspiciosly looks like a graphics problem ...
<seb128> obviously you know that the guy change the panel width and that there is 2 icons, that's something :p
<seb128> I've not read the comments
<ogra> oh, the prelast ..
<seb128> I've ~490 unred bug mails atm
<seb128> unread
<ogra> oh
<ogra> mine are all read ...
<ogra> but i might have 490 in sum over all releases :)
<seb128> I just read when I'm decided to do something on the bug
<seb128> I let unread the "must work on" bugs
<seb128> ie: I've no idea of this bug and I can't reproduce
<seb128> so I let it unread
<ogra> the 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2 error sounds like a image prob to me 
<seb128> right
<ogra> and since its only one launcher (tuxpaint) i suspect the png is broken ...
<ogra> i'll grab that bug ... so you have one less :)
<seb128> ogra: vuntz and lllmanulll are on it, that's why I didn't really bothered
<ogra> ok
<vuntz> I'm not really on it
<ogra> so i'll leave it to them .... 
<vuntz> ogra is on it :-)
<ogra> vuntz, to late, seb128's word rules ;)
<vuntz> if someone can attach the image file, btw...
<ogra> giggles evilish*
<mdke> does there happen to be a dpkg guru around who has 5 minutes to help me unblock my dapper system?
<seb128> I'm not a guru but may be able to reply
<seb128> why not just asking? :)
* fabbione points to #ubuntu
<fabbione> and topic
<mdke> that's why
<seb128> bah, according to the chan activity I guess nobody will kick you to ask something
<seb128> feel free to ask on #ubuntu-desktop if you want, we have no issue with a little noise :p
* fabbione heads for better activities
<mdke> great thanks seb
<BenC> anyone else seeing get_netlink_msg errors from udev?
<BenC> ENOBUFS error from the recv() call to be exact
<Riddell> elmo: please sync noteedit, licq, kvdr and packagesearch from debian overwriting ubuntu changes
<LaserJock> seb128: ping?
<seb128> LaserJock: pong
<LaserJock> seb128: you marked my yelp bug as a duplicate. #21015
<LaserJock> seb128: I am still not quite understanding it
<LaserJock> seb128: how come some people see it but others don't
<seb128> /usr/lib/mozilla-firefox/components/compreg.dat gets generated by something
<seb128> we didn't figure what
<seb128> it's not supposed to be created/shipped with 1.5
<LaserJock> but I have my dapper install and chroot dapper install both dist-upgraded from breezy at about the same time, yet one works and one doesn't
<LaserJock> seems kinda weird to me
<seb128> you have probably a difference in the package list
<seb128> like a l10n package
<seb128> or an extension installed
<seb128> or firefox were running during the upgrade for one and not the other
<LaserJock> oh, that's enough to do it ?
<seb128> or I don't know
<seb128> as said before we didn't figure what's causing it
<LaserJock> wow, that seems hard to figure out
<seb128> right
<seb128> those are random idea on the topic
<LaserJock> ok, I just wanted to get a better idea of what was going on. Is there any info I can give that would help?
<seb128> figure what creates the file? :)
<LaserJock> so would firefox extensions do it?
<seb128> you can guess from the file timestamp what you did around the time it get generated
<LaserJock> ahh, ok
<seb128> I doubt of it because you don't run firefox with sudo usually
<seb128> so it should not be able to write this file
<seb128> I would bet on something done by a package
<LaserJock> ok, I will try to see what the difference is between my installs
<seb128> thank you
<LaserJock> seb128: ok, on the day that the compreg.dat file was created I installed quite a few things but the one that sticks out is that I installed and removed mozilla
<seb128> mozilla-browser?
<LaserJock> yes
<tuhl> when will we get libenchant 1.2 inti Ubuntu?
<LaserJock> well, actually the whole mozilla meta package
<tuhl> this is necessary for compiling  current abiword verisons
<seb128> tuhl: when it'll be required :)
<mdke> seb128, LaserJock, I don't think I've ever had mozilla-browser installed here
<seb128> tuhl: I'll package it tomorrow or monday
<mdke> system was pretty much a standard dapper flight 1
<seb128> I've just installed/removed it
<tuhl> seb128: Requested 'enchant >= 1.2.0' but version of libenchant is 1.1.6
<seb128> doesn't do this
<tuhl> seb128: thanks
<seb128> tuhl: "we" beeing a package of the distro
<seb128> I mean
<seb128> "it"ll be" = "it'll be by a package"
<LaserJock> mdke: dpkg -S /usr/lib/mozilla-firefox/components/compreg.dat doesn't give me anything so I'm not sure what would have installed it
<Amaranth> pretty sure firefox generates it on first start
<Hieronymus> Isn't that a known bug?
<Hieronymus> #20183
<ogra> apart from Amaranth being wrong ? 
<Hieronymus> http://bugzilla.ubuntu.com/show_bug.cgi?id=20183
<ogra> ogra@honk:~$ ls /usr/lib/mozilla-firefox/components/compreg.dat
<ogra> ls: /usr/lib/mozilla-firefox/components/compreg.dat: No such file or directory
<ogra> thats a clean flight 2 with firefox being run several times already
<ogra> it must be a leftover from breezy installs ...
<ogra> additionally a user that starts firefox has no rights to write to /usr/lib/mozilla-firefox/components/, so there is no possibility it creates it on first start
<ogra> it could only happen from a package, but then you'd be able to find it somewhere in postinst or in the package itself, which s not the case
<mdke> mine came from a dapper flight 1 install
<mdke> must be the old firefox, before 1.5
<ogra> yup
<ogra> but there is no trace in the package that anything is related to it
<mdke> it's a mystery
<ogra> yup
<crimsun> elmo: please sync tse3, tellico, swh-plugins, wordtrans, wftk, strutilsxx, and stk from Sid, overriding Ubuntu changes. Thanks.
<sistpoty> elmo: please sync libprinterconf from unstable, ubuntu override ok. thx.
<Tm_T> any known xorg crash issues?
<Tm_T> with nvidia
<lucasvo> Tm_T: lots, but you can't change them :D
<Tm_T> hehe
<Tm_T> had two crashes tonight, just wanted to know if there's something to test / reproduce
#ubuntu-devel 2005-12-23
<Pygi> welcome matt
<mdke_> thanks
<BenC> anyone know of a util that will show the events on /dev/input devices? (not anything that goes through X)
<BenC> something that is in breezy, preferably
<Pygi> cat /proc/bus/input/devices  maybe this? ;)
<BenC> no, I need to see the events
<BenC> like when the mouse button is clicked, I want to see that event
<Pygi> maybe this can help....
<Pygi> http://www.ggi-project.org/documentation/libgii/current/input-linux-evdev.7.html
<Pygi> well, all mouse's send event's throught /dev/input/mice
<BenC> yeah, but I don't want to see raw data, I want it parsed into something meaningful
<Pygi> k, read this
<Pygi> http://opensource.idealcorp.com/evdev/README
<Pygi> hope it helps
<BenC> was hoping for something a user could install, but that may be my only option
<BenC> thanks
<Pygi> k
<Pygi> BenC, hm, maybe you could make some kind of python/shell script which will ease the process?
<Pygi> welcome clones of crimsun ;)
<BenC> Pygi: was also trying to avoid writing software to debug a user's problem :)
<Pygi> BenC: heh, maybe you could *force* someone to write it for you ;)
<Pygi> BenC: still here?
<Pygi> http://www.cpan.org/modules/by-module/Linux/Linux-Input-1.01.readme
<BenC> think I'll just use evtest.c
<Pygi> k
<sistpoty> elmo: please sync paintlib from unstable, ubuntu override ok. thx.
<eruin> where can I read about suspend to ram for dapper?
<eruin> all I can come up with is hoary and even warty-related wiki entries, etc
* lamont-away grumbles.
<lamont-away> if I have a machine with ubuntu-server installed, what magic glue is needed to make it mount usb drives when they are detected, I wonder...
<Lathiat2> hrm
<Lathiat2> they should?
<lamont-away> mind you, I'm only logged in over the network
<Lathiat2> oh, to auto-mount?
<lamont-away> yeah
<Lathiat2> i think gnome-volume-manager does the mounting part
<lamont-away> automount
<Lathiat2> usually
<lamont-away> hrmfp
<mojo_> hi every1
<mojo_> GNOME Login Photo in Preference is quite useless since we have About Me program, then can some1 report a suggestion for deprecation?
<zakame> hello all
<Cimmerian> yes, all and shit
<zakame> hey mhz
<mhz> hey zakame 
<zakame> er prolly stupid q, but what does a given-back in lamont's buildLogs mean?
<fabbione> zakame: that the package is going to be rescheduled for build later
<fabbione> but there are several reasons why you get there
<zakame> fabbione: oh, k :D  I got this from the i386 build for the ruby-related pkgs I asked for sync yesterday...
<lamont-away> zakame: but they all come down to "I tried to do the build, but I couldn't even get started because the source isn't fetchable or some such"
<lamont-away> if you see them given back regularly every 8 hours or so for several times, then you might squawk.
<zakame> lamont-away: yes, that's what I saw inside the .gz... I'll be keeping an eye on those then ;)
<zakame> thanks :D
<lamont-away> it's _supposed_ to be a transient error, you see...
<zakame> ooh
* fabbione starts installing the ia64
<fabbione> lamont-away: default serial on ia64 is sitll 9600 8N1?
<fabbione> still even
<lamont-away> actually, I think it's default is now autosense.
<lamont-away> but yeah, 9600 8N1 will work just fine
<fabbione> hm ok.. i must have plugged in the wrong serial than :)
<fabbione> yeps
<fabbione> here is is
<fabbione> it is
<lamont-away> heh
<lamont-away> hppa 90.78% 5848 of 6442
<lamont-away> sparc 88.76% 5755 of 6484
<lamont-away> oops.  echan
<lamont-away> powerpc 93.94% 6220 of 6621
<lamont-away> amd64 93.03% 6129 of 6588
<lamont-away> ia64 92.82% 6093 of 6564
<lamont-away> i386 92.81% 6278 of 6764
<lamont-away> hppa 89.45% 5848 of 6538
<lamont-away> sparc 87.49% 5755 of 6578
<lamont-away> holy-inversions batman.
<fabbione> cat /proc/cpuinfo 
<fabbione> processor  : 0
<fabbione> vendor     : GenuineIntel
<fabbione> arch       : IA-64
<fabbione> family     : Itanium 2
<lamont-away> ppc is leading?  and i386 is #4???
<lamont-away> wow
<fabbione> amen
<fabbione> i think it
<zakame> rocking
<fabbione> i think it's busy building Riddell's crack :)
<fabbione> so is sparc :)
<fabbione> lamont-away: what did you build to gain 70 pkgs in one day????
<fabbione> are you cheating or something?
<lamont-away> fabbione: I, uh, reenabled mail and ftp from the 2nd buildd. :-)
<fabbione> lamont-away: ah ok :)
<fabbione> This boot experienced the following problems:
<fabbione>   WARNING[10] : BMC System Event Log is full
* fabbione starts to discover another way of pleasure trough EFI boot loader chain
<fabbione> but you were right.. ia64 is on giga
* fabbione moves to #ubuntu-ports
<lamont-away> fabbione: yeah - there's a bmc log dumper in universe somewhere - ping me monday and I'll tell you the name.. :-)
<lamont-away> otherwise, it just gives you 30 extra seconds to override the autoboot. :-)
<lamont-away> the warning specifically means that you're not running anything to clear the log, since booting is a logged event.
<fabbione> i am ok with the 30 secondds
<zakame> bye
<Amaranth> do the dapper kernels have the new broadcom driver?
<jblack> Hello. I have a multitude of problems on my vaio. Is anybody available to assist me in triaging them to figure out whether or not they're already filed, dapper specific, what packages are appropriate to file against, etc? 
<fabbione> jblack: can you give me about 10 minutes?
<jblack> fabbione: Sure
<fabbione> re
<fabbione> jbailey: ok.. tell me :)
<jblack> This one? 
<fabbione> ?
<jblack> Lots of problems. Some are post going to dapper, some go all the way back to hoary
<jblack> The most recent thing I've noticed is that /dev/hdc has gone bye-bye
<fabbione> is that a cdrom?
<jblack> Yes
<fabbione> my hdc is actually a 400GB hd :)
<fabbione> ok
<fabbione> i am pretty sure it's a known problem
<jblack> Ok.
<jblack> Then that gets fixed some day. I can live without that for now. :) 
<jblack> The next one is that /proc/acpi/sony has gone away since moving to dapper as well.
<fabbione> you could check if the cdrom kernel modules are loaded
<jblack> I tried modprobing idecd, but I'll do that again now
<fabbione> let me check the acpi think
<fabbione> there are 2 modules to load
* fabbione looks
<jblack> ide_cd is loaded, cdrom is loaded, ide_generic and ide_disk
<fabbione> oh first thing.. are you sure you did a full dist upgrade?
<fabbione> because new kernel needs new udev
<fabbione> and hotplug goes bye bye
<jblack> Yeah, I did a apt-get dist-upgrade
<jblack> I've done it a few times in the last few weeks.
<fabbione> did you do it today?
<jblack> btw, dmesg tells me "hdc: ERROR, PORTS ALREADY IN USE"
<fabbione> there have been quite a log of fixes...
<fabbione> ah
<jblack> Yes. I did it this evening, about an hour ago
* fabbione hmms..
<jblack> I also see this a few lines later in /var/log/dmesg:
<jblack> [17179573.632000]  Badness in enable_irq at kernel/irq/manage.c:126
<fabbione> ok, it might be a driver problem.. you need to check that with BenC
<fabbione> jblack: uname -a ?
<jblack> Ok. Used to work fine back in breezy, btw.
<jblack> Linux pluto 2.6.15-8-686 #1 SMP PREEMPT Tue Dec 13 03:38:39 UTC 2005 i686 GNU/Linux
<fabbione> jbailey: cd /lib/modules/$(uname -r)/kernel/drivers/acpi
<fabbione> jblack: 
<fabbione> do you have the sony module there?
<fabbione> or at least loaded?
<jblack> No, no sony module
<jblack> I do have sonypi loaded though
<fabbione> ok
<jblack> I'm not sure where its loading from, if its not in that dir
<fabbione> not sure it's the same.. let me check
<jblack> oh, its in char/sonypi
<fabbione> obj-$(CONFIG_ACPI_SONY)         += sony_acpi.o
<fabbione> no it is simply not compiled.. 
<fabbione> the code is there tho
<fabbione> open a bug for BenC
<jblack> Hmmm. That's two for benc. :)
<fabbione> yup
<fabbione> next?
<jblack> Next... Hmmm. how about another probably kernel one.
<fabbione> go ahead :)
<jblack> resuming from sleep is very slow. Usually, shutting down and restarting is quicker
<fabbione> because for once.. IT'S NOT MY FAULT :P
<jblack> Oh, I've got some for you too. :)
<fabbione> i doubt
<jblack> You do synaptics?
<fabbione> resume speed.. dunno.. you need to ask mjg59
<fabbione> no i don't do synaptics.. i am more for classic drugs like eroin or cocaine...
<jblack> Ok. I'll talk to him for that one.
<fabbione> synaptics is still Xorg = daniels..
<jblack> Next, the mouse and touchpad are slow. I have to travel large distances for movement.
<fabbione> is that a regresion compared to breezy?
<jblack> The touchpad stuff doesn't honor any of the settings. So in breezy, everytime I used the touchpad, I would get movement + touch.
<fabbione> there could be several reasons for that
<jblack> Now, I get little movement + touch. 
<jblack> btw, all of this worked fine back in warty. 
<fabbione> that
<jblack> It went downhill in hoary, then more so in breezy. Desperate, I hopped to dapper.
<fabbione> that's tricky to debug and it will take sometime.. that i don't really have today, but i can help you tomorrow
<fabbione> jblack: the entire input layer has been rewritten between hoary and breezy
<fabbione> and there have been even more changes in dapper
<jblack> Yeah. Adam Conrad took a shot at it in ubz.
<fabbione> jblack: meh you could have told me there
<jblack> We thought we had fixed it. :( 
<fabbione> remote debugging of that stuff = the sucks
<jblack> I will happily limp to the next meet.
<fabbione> let's try to look at it tomorrow than
<fabbione> or during the next week
<jblack> And I'll give you all the beer that you can drink if you make this thing work as well as its counterpart did with hoary.
<fabbione> ehhehe
<jblack> I'm serious. :) 
<fabbione> if people keep paying me in beer.. i will not survive the next 3 months
<fabbione> speaking of which.. shawarma the beer is good :)
<jblack> yeah? 
<jblack> I think I've seen that before. Where is it? 
<fabbione> jblack: i got 5 lt of beer from shawarma :)
<fabbione> jblack: anyway.. this distro is all about free beer :)
<jblack> We have an american beer here called...I can't remember the name.
<fabbione> bud wiser?
<jblack> Oh god no.
<fabbione> ah ok
<fabbione> you did scare me for a second
<jblack> No. Thats soda water with a hop from time to time.
<fabbione> no idea of what you are talking about ;)
<fabbione> anyway.. next issue?
<jblack> no cdrom, broken touchpad, broken suspend and resume, that's the big ones.
<fabbione> ok, other than the synaptic one, that we need to debug.. the others have been addressed somehow...
<fabbione> i also think that suspend / resume is binded to the sony_acpi
<fabbione> missing from the kernel
<jblack> I suppose thats possible, but back in breezy, the suspend-resume problems were there, and I had sony_acpi
<jblack> The missing sony_acpi causes a number of problems. Poor battery life, processor speed, etc.
<jblack> Is it possible for me to build a kernel on ubuntu?
<fabbione> jblack: yes it is of course.. the problem is that i don't know why it's not built and building for amateur is a suicide 
<jblack> Back in the debian world I was accustomed to building kernels without a problem.
<fabbione> mainly it will burn your life for a few days..
<fabbione> oh the build system is similar
<jblack> I'm worried that I'll muck up the wireless though.
<fabbione> that's not the issue
<fabbione> the main problem is that i don't know why it's not built
<jblack> perhaps it causes a problem for nonsonys.
<infinity> Are the relevant patches even included?
<fabbione> i don't think that's the reason
<fabbione> infinity: yes they are
<fabbione> the code is in .15
<infinity> We definitely don't have CONFIG_ACPI_SONY in our .configs.
<fabbione> that might be why :)
<infinity> So, maybe it was just an "oops".
<fabbione> that's why i am saying it might be difficult to get there
<fabbione> if ACPI_SONY is not in Kconfig, it becomes a pain to do
<fabbione> much easier to ask BenC
<jblack> Just promise me that I won't loose any more hardware!
<fabbione> pain for people not familair with Kbuild
<jblack> No touchpad, no cdrom, no acpi... 
<jblack> if you take out the nic, keyboard or screen, I'm screwed! 
<fabbione> jblack: that's because we care about you.. working too much in front of a pc is NOT healty
<fabbione> so we preserve you
<infinity> jblack IS the CDROM on an SATA channel?
<fabbione> you should be grateful to us :)
<jblack> inifinity: Nope
<jblack> Speaking of the screen, irssi just went bonkers. 
<infinity> jblack : Oh, it's standard IDE?  Hrm.
<jblack> infinity: Yeah. Its apparently a known issue.
<jblack> PORTS ALREADY IN USE or somesuch
<infinity> That's a red herring.
<infinity> ide-generic always says that.
<infinity> (If it doesn't, it was loaded too early)
<infinity> I really should silence those printks in ide-generic.  People keep using them as debugging info, and they're just not meaningful.
<jblack> ok, in that case, I lost hdc somewhere between late breezy and contemporary dapper.
<jblack> I noticed tonight. The drive is there. I checked on wintendo
<infinity> Maybe replace them with something friendlier, like "A better IDE driver is already loaded, ide-generic not binding to any ports"
<infinity> Or just remove them completely.
<infinity> Wait, didn't i already DO that in breezy?
<jblack> I'm on dapper.
<infinity> Yeah, I know.
<floam> anyone know about libata's ATAPI support? will that be working by the time dapper comes out?
<floam> Jeff Garzik has been saying "real soon now" for almost a year
<infinity> floam : If it's not in tip-top shape when we get closer to release, we'll fall back to the older methods.
<floam> older methods?
<floam> as in ATAPI not working at all?
<floam> (as it is now)
<fabbione> floam: do you have patches to fix these problems?
<infinity> fabbione : Do you have an old breezy kernel tree on your hard drive?... I can't be bothered to download it to check something.
<fabbione> infinity: yes i do
<infinity> fabbione : Did my "drivers-ide_quiet_probe_failures.dpatch" remove the probe printk entirely, or just lower the severity to keep it off the screen?
<floam> fabbione: uh, no. it's major work
<floam> I'm just curious if anyone knew more than what's on the libata page
<fabbione> floam: than don
<floam> don't say don't complain, I certainly am not
<fabbione> floam: than don't complain.. it's a major work for Grek too
<fabbione> Jeff i mean
<floam> I know that
<fabbione> infinity: it lowers it
<fabbione> from ERR to INFO
<infinity> floam : BenC's been following it some.  The theory is that if libata ATAPI turns out to suck, we fall back to using ide-generic for ATAPI and libata for disks.  (which was basically how breezy's setup worked)
<fabbione> so it should still be in dmesg
<infinity> fabbione : Ahh.  Kay.  Then Ben probably didn't drop the patch.  I'd forgotten I left it in as INFO.
<floam> infinity: I don't get how that can work..
<floam> ide-generic certainly can't handle SATA CD/DVD drives
<floam> oh.
<floam> you must mean PATA stuff.
<infinity> floam : My CD drive is SATA, and it woks in breezy, where we certainly weren't using the libata/atapi mess we are right now.
<infinity> works, too.
<floam> infinity: interesting. can it burn?
<infinity> But yes, I thin kthe current broken state of affairs is with trying to use libata for pata atapi devices or some such.
<infinity> Yes, it'd a DVD burner, works fine in both breezy and dapper.
<infinity> (2.6.12-9 and 2.6.15-8)
<floam> weird weird weird. is it using the old "(DEPRECATED)" SATA modules for that or something?
<floam> I was under the impression that it couldn't work with libata at all at the moment
<infinity> It's ata_piix/libata+atapi in dapper.  No idea how it was working in breezy.
<infinity> (Well, +sr_cd+sg, obviously)
<floam> yeah, I know it's enabled on a few chipsets in dapper
<floam> I'm just curious now what it was doing in breezy
<infinity> I'd have to reboot and play to remind myself how it worked in breezy, but I know it did.  Testing release CDs would have been tough if it didn't work. :)
<floam> ide-generic certainly can't do SATA, maybe it was using the old non-libata SATA modules that were in the IDE layer for that or something
<infinity> fabbione : Would you object to me changing that printk to be a bit friendlier/more informative?... I'm sick of people (even clueful people) thinking it's a bug.
<jblack> Thats probably not a bad idea. It tricked me. 
<fabbione> infinity: i have no problems at all.. just send me the patch or point me to your git repo
<infinity> (Okay, to be fair, it's a "bug" that we need to try to load ide-generic at all, but one we can't fix any time soon)
<infinity> Yeah, I'll fix it later and have ben pull.
<floam> infinity: which drive do you have? the plextor one?
<fabbione> infinity: up to you.. makes no diff for me
<infinity> fabbione : Yeah, it wa more just a second opinion thing.
<fabbione> infinity: ehehe 
<infinity> floam : No, it's a Matshita drive in my Thinkpad.
<floam> hm. completely 100% certain it's really SATA?
<infinity> The drive, or the controller?
<floam> well, both
<infinity> The drives are PATA drives on a bridge, afaik, but the controller is definitely SATA, which is what should matter.
<floam> the only experience I have with a ATAPI SATA device is the plextor one, which my friend had on a VIA chipset
<floam> and I'm pretty sure we couldn't get it to work on breezy
<floam> perhaps piix works better
<infinity> I'd be willing to bet piix gets more love, but the via drivers should be getting a fair amount of love from the am64 crowd.
<floam> yeah.
<infinity> I was going to get one of the Plextors for my SATA VIA machine, but the PATA Pioneer drives were too well priced to turn down.
<exarkun> I came in halfway through, but I have a PIIX w/ and ATAPI SATA plextor, it does not work with Breezy.
<infinity> exarkun : Does it work in dapper?
<exarkun> haven't tried, I ended up buying an IDE drive to replace it.
<floam> I might be getting the PX-716SA as a gift over the holidays, so I'll be able to screw with that soon
<floam> it's finally available fairly cheaply. I saw it for $82 somewhere
<infinity> Yeah, I was shoppig about a year ago, and the Plextor was a bit out of range for someone like me who burns a few DVDs per year, and maybe 50 CDs.
<floam> yeah.
<floam> it was $160 when I first put my eye on it
* infinity wonders how evil it would be to lay into ATI's libGL.so.1.2 binary with a hex editor to fix a hardcoded path.
<floam> certainly not much more evil than ATI for only handing out binaries
<floam> though one is cleanliness-evil and another is moral-evil
<Treenaks> infinity: less evil than doing it in the nvidia-driver ;)
<infinity> Treenaks : Well, the nvidia driver WORKS, so that's a non-issue. :)
<Treenaks> infinity: The nvidia-driver _leaks_
<infinity> Well, okay, for some value of "works"... It works a lot better than fglrx at the moment.
<Treenaks> hmm
<Treenaks> I need to try flight2 + latest X
<Treenaks> see if it fixes my ATi-troubles
<infinity> The free ATI driver treats me very well.
<Treenaks> infinity: well, it does on my _other_ laptop, but on the canonical-supplied one, all hell breaks loose on 1920x1200
<infinity> But I should fix DRI in fglrx, I suppose.  And that will either take dirty symlinks I don't want to ship (stuff in /usr/X11R6, ugh), or a hex editor.
<floam> nvidia seems to be much better at distributing binary drivers that manage to work well in a hostile environment
<floam> every other week Greg-KH adds something to the kernel blocking off more non-GPL stuff
<Treenaks> floam: i.e. gentoo? :)
<floam> well, I mostly meant the A{B,P}I environment
<floam> Greg-KH is a nice guy, but I really liked it when my nvidia driver had working udev/sysfs stuff
<Treenaks> complain to nvidia ;)
<infinity> Can't.  That's the whole point.
<infinity> It's not nvidia's fault.
<Treenaks> ('why isn't it possible to work like wiif-drivers work: upload a blob of firmware to $device')
<infinity> (Wel, except that it's their fault the driver's not free)
<floam> other than telling NVIDIA to release all their IP to the world, there isn't anything to complain about to nvidia
<jblack> I cared a lot more about kernel tainting before I had a job
<Treenaks> floam: you've never used nforce-chipset motherboards :)
<floam> the kernel people don't like proprietary drivers, so they decided one day to set a bunch of EXPORT_SYMBOL stuff to EXPORT_SYMBOL_GPL in the sysfs code
<infinity> OTOH, udev/sysfs integration is of limited value, since modporbing 'nvidia' when the X driver loads is good enough.  You don't need it hot/coldplugging on boot.
<floam> and now that hasn't worked sense
<floam> infinity: meh, it was somewhat useful
<dooglus> where do I set up my 'workgroup'?
<Treenaks> dooglus: System -> Administration -> Shared folders?
<Treenaks> (or whatever it's called in English)
<dooglus> Treenaks: I saw that, but I'm not using samba or NFS.  I'm merely mounting a windows shared drive
<Treenaks> dooglus: you don't need a workgroup for that
<floam> mounting? literally? You'll need to use smbfs and set the workgroup in the -o parameter of mount
<dooglus> Treenaks: do I need to install anything to be able to "mount -t cifs" ?  Currently I see mount: wrong fs type, bad option, bad superblock on //server/dokumenty,
<floam> I assume you didn't mean actually using mount though.
<infinity> dooglus : "smbfs"
<floam> you should be able to find it in nautilus
<infinity> dooglus : The package, that is.
<floam> oh, man. awesome. Jorn finally gave someone else commit access to muine
<floam> it's no longer dead, woot
<floam> or less dead, at least
<dooglus> thanks guys.  you were both right.  I didn't need to set a workgroup, and I *did* need to install smbfs to be able to mount using 'cifs'
<floam> hmm, both nautilus and the gnomemeeting packages seem borked on amd64 here
<floam> neither can install
<dooglus> floam: I really meant 'mount', and I don't use 'smbfs' because that has a 4Gb (or 2Gb, I forget) file size limit
<dooglus> floam: and I didn't have to mention the workgroup name in the -o flags
<floam> yeah, you probably wouldn't
<floam> workgroup is default
<dooglus> floam: I uninstalled nautilus
<dooglus> floam: the workgroup used here isn't the default one.
<floam> dooglus: and it still found it? cool
<dooglus> floam: well, I installed this chroot a couple of months ago, when dapper was first made available, so maybe I set the workgroup then.  but I can't see where, if I did.
<infinity> The workgroup is meaningless except for browsing machines in nice little groups.
<infinity> When connecting to a share, you just need to know how to get to it (machine name or IP) and the share name.
<floam> oh.
<floam> I figured it was the same as the abstract way it's presented
<floam> (as machines under workgroups)
<infinity> Nope, workgroups are just to keep things tidy in GUI browsers.
<infinity> (And to allow machines that aren't actually domain members to appear in the same-named machine lists)
<lifeless> floam: a good way to think of it is: workgroups/domains == naming service; domains also add bidirectional verification and a user lookup service.
<floam> infinity: do you do the kernel releases? who should I bug to try to get a .config option turned on?
<infinity> floam : You should ask in #ubuntu-kernel.  BenC does the majority of kernel maintenance and releases.
<floam> oh. didn't know it had a channel
<infinity> Yes, well.  The last few hours here would seem to indicate we don't have a kernel channel, but that's cause it's a weekend, and I'm more slack about not bouncing people for being off-topic on weekends (since there's very little ON-topic conversation)
<jdub> hmm, wonder if my craptop boots now
<floam> 80% of what I was saying here would have been in there had I known about it :)
<jdub> probably not, haven't seen any core updates
<infinity> jdub : What sort of hate is it giving you?
<jdub> seems to halt at shpchp
<jdub> at least, that's the last thing printed during a verbose boot
<jdub> i'll try again now
<jdub> okay, so init=/bin/sh is fine
<jdub> so it's during hardware detection stage
* jdub boots single
<jdub> hmm, bit different now
<jdub> interesting dma timeout errors on hda
<jdub> let's see that again
<dooglus> what's this about: bash: ./small.sh: /bin/bash: bad interpreter: Permission denied
<dooglus> /bin/bash is executable by everyone - so why "permission denied"?
<jdub> hmm!
<jdub> looks like it worked this time, after killing a stupid hdparm config
<jdub> though it got further than it did before even then
<sivang> morning all
<Pygi> mornin' sivang
<sivang> hey Pygi , 'sup?
<Pygi> writing Server 
<Pygi> gah, wrong...
<Pygi> porting Miranda to Linux
<sivang> oh, miranda on linux :)
<dooglus> for the record:  the device holding 'small.sh' was mounted with option "user" which implied "noexec".  remounting with "defaults" instead fixed it
<Pygi> hehe ;)
<sivang> Pygi: but there's GAIM why do need to port it to linux?
<Pygi> sivang: I rather wouldn't talk about GAIM because it's lead developer might be hear, and I don't think he would like to hear what I think about him ;)
<Pygi> here, not hear* (first one)
<sivang> Pygi: I see, well, better not go that way.
<Pygi> heh ;)
<Pygi> so, what are you doin'?
<sivang> Pygi: I'm at work currently :-/
<Pygi> ah :-/
<sivang> lately leaves me no time for Ubuntu...
<Pygi> heh, will be better eventually....
<sivang> yes, I hope :)
<Pygi> Lately I've been playing around with writing some patches for the kernel
<Treenaks> hmmm
<Treenaks> flight2 fails to boot
<dooglus> is there an easy way to make the text smaller in GTK apps?
<Treenaks> dooglus: choose a different font in  SYstem -> Preferences-> Fonts
<infinity> Treenaks : Installer, live, or both?
<Treenaks> infinity: installer
<Treenaks> infinity: haven't tried live
<dooglus> as easy as that, eh?  thanks!
<Treenaks> the moment I press a key, a 'debug window' pops up
<Treenaks> pressing enter gives me a window saying 'Error reading CD-ROM'
<Treenaks> just waiting -> same
<Treenaks> I have a picture of the 'debug window'
<Treenaks> foodfight.org/zut/BOOT-ERROR.jpg
<infinity> Oh, that's still in gfxboot.  You're not even hitting a kernel yet.
<infinity> I'd assume bad burn or corrupt ISO.
<Treenaks> infinity: I burned it twice, checked the ISO in between, and md5summed the CD
<infinity> Anything that shows the menu but can't find the kernel sounds pretty "broken CD" to me.
<infinity> Hrm.
<infinity> Or a nifty gfxboot bug..
<dooglus> Treenaks: did "md5summing the CD" give the right sum?
<Treenaks> dooglus: yes
<dooglus> Treenaks: how did you do that?
<dooglus> Treenaks: when I tried it, "md5sum /dev/hdc" read more bytes off the cd than I had written to it, so the sum came back wrong
<Treenaks> dooglus: uh.. 'extra bytes'?
<Treenaks> never had that
<dooglus> Treenaks: just random junk by the look of it
<dooglus> Treenaks: not all zeros
<Treenaks> anyway, I tried with 2 discs, burned at different speeds
<infinity> Treenaks : Then file a bug on "gfxboot", and attach (a much smaller copy of) your image.
<Treenaks> infinity: ok
<infinity> And mention the "I did an md5sum twice, blah blah" stuff, or someone will just ask you again. :)
<Treenaks> ;)
<dooglus> when I boot, if I specify "vga=773" to get nice small text in the consoles, the consoles are all black.  if I miss out the "vga=" bit, the text in the consoles is far too big.  is there some way I can have small text which isn't black-on-black?
* dooglus just noticed what channel he's in (!)  sorry!
<dooglus> I thought it was very quiet in here - and now I know why!
<Q-FUNK> hm.  did pitti change nick recently or is he just plain not here right now?
<Treenaks> Q-FUNK: he's not here.
<Q-FUNK> Treenaks: ok.  thanks :)
<Q-FUNK> for the record, esound has just gone RC in Debian and Pitti's patches fixes it. However... this is an rmurray package...
<Q-FUNK> see Debian Bug #343861
<Pygi> greetings ;)
<greenpenguin13> morning
<Kamion> floam: on easy vesafb setup, I get to wave my blessed wand of retroactively satisfying feature requests again
<Kamion> floam: use the menu labelled "VGA" in >= Flight 2's boot menu; whatever mode you select there will be propagated as the default for the installed system
<Kamion> Treenaks: nifty - fortunately I know how to debug those screens, so I'll have a look, thanks
<Treenaks> Kamion: ok, cool :)
<Kamion> err 8 means "wrong arg types" and means I screwed up the theme somewhere
<Treenaks> even 'boot from harddisk' gives me a 'Error reading CD-ROM'
<Treenaks> "dialog box" thing
<Kamion> Treenaks: which arch is this? I need to check exactly which version of gfxboot-theme-ubuntu was being used
<Treenaks> Kamion: i386
<Kamion> elmo: please sync jlex, ok to override Ubuntu changes
<Treenaks> Kamion: (HP laptop, hda = harddisk; hdb = cdrom)
<Treenaks> same CD works fine on my Acer (also pentium-m; hda = harddisk; hdc = cdrom)
<Treenaks> (maybe 512M RAM vs 1GB RAM?)
<Kamion> you've probably got a losing BIOS, sorry
<Kamion> all gfxboot can do is guess and chain to BIOS 0x80
<fabbione> hey Kamion 
<Kamion> if that doesn't work, tough
<Kamion> hi
<Treenaks> Kamion: sure... chaining should work... but why does it try to read the CD for that in the first place?
<Kamion> it doesn't, unless your BIOS claims the CD is 0x80, AFAIK
<Kamion> I have no intention of trying to do anything cleverer at the moment
<Treenaks> Kamion: I can imagine
<Kamion> it's a useful feature if it happens to work; if it doesn't happen to work for you, oh well, it was just thrown in as a nice-to-have
<Treenaks> Kamion: but then, booting from CD also doesn't work.. that would be nice
<Kamion> seems pretty separate
<Kamion> let me work on it rather than arguing with you :)
<Treenaks> ok :)
<infinity> Kamion : Oh, can you avoid the default boot setting "vga=normal" in gfxboot?
<Kamion> infinity: that's debian-cd's defaults not gfxboot. ok - why?
<Mithrandir> Kamion: it breaks usplash
<infinity> Kamion : (bug in usplash that it doesn't properly deal with "vga=normal", which will be fixed in the next upload, but if you say that gfxboot's settings propagate to the installed system, IMO vga=normal is silly overkill)
<Kamion> from the sound of scrollback that was usplash's fault anyway
<Kamion> infinity: vga=normal doesn't propagate
<Kamion> it's only stuff after -- in the boot line that gets propagated
<infinity> Oh, just "anything but vga=normal"?
<Kamion> no
<infinity> Ah.
<infinity> Check.
<Kamion> vga=normal goes before --
<infinity> Right.
<infinity> Lag.  Your explanation came after I typed my stupid question.
<infinity> Anyhow, I'll fix usplash, I'm not too picky on what gfxboot decides to do then.
<infinity> (If a user types "vga=123" after the '--', I assume my /proc/cmdline will only show the latter, not both?
<infinity> )
<infinity> Or do I have to find the "best" one to interpret? :)
<infinity> (Yeah, tomorrow I can reboot my laptop and find out myself, just not right now)
<Kamion> infinity: vga=normal removed
<Kamion> infinity: it'll show both; use the last one
<infinity> Kay.
<Kamion> ok, that gfxboot trace is insane, it's dying on finding an undef value in timeout.areas, which is a hardcoded array containing no undefs
* Kamion wonders if he's working against the right piece of theme code
<infinity> Mithrandir : How do you feel about uploading a casper that actually works on my hardware, so I can build a livefs with it and test a daily over here?  (assuming I can get the *-{live,desktop} stuff installable again this year)
* infinity fears trouble with this whole "can't fix casper bugs without the livefs being buildable" thing...)
<infinity> I may just switch my job title to "Guy who makes sure the distro is installable at all times"
<Mithrandir> infinity: I can do that, I just need to fix asterisk a tiny bit.
<jdub> hey dudes
<Kamion> jdub: you pinged the other day?
* jdub invokes the white collar court answer - "i do not recall"
<Mithrandir> infinity: want me to add squashfs support as well, or just the scsi cdrom module?
<infinity> Mithrandir : Go ahead and add it, it's dormant code until we play with squashfs images, but it's nice to have it in there so we can.
* Kamion once again advocates including content with your pings so that you don't *have* to recall later. :)
<jdub> syeah
<jdub> i should get irssi to reject any attempt to say something that matches "^.*: ping$"
<Mithrandir> infinity/Kamion: what does uname -m say on ppc/ppc64?
<jdub> Kamion: do we need more testing for installs on openservers?
<jdub> openpower servers
<Mithrandir> I feel nice, so I'll unbreak the live cd on ppc
<Kamion> jdub: sure, always
<jdub> Kamion: did we get those yaboot patches?
<Kamion> Mithrandir: ppc on this older kernel but I strongly suspect it'll be powerpc in dapper
<Kamion> jdub: last time I looked they weren't published yet; I'll have another look
<jdub> fuqrs
<Mithrandir> Kamion: so I need to check for ppc, powerpc and powerpc64 or something?  This is so casper will use devmapper on ppc.
<Kamion> Mithrandir: ppc/ppc64/powerpc I think
<Kamion> Mithrandir: I could just have debian-cd pass casper-overlay=devmapper or something
<Mithrandir> Kamion: that would mean I'd have to parse /proc/cmdline. :-)
<infinity> It's all the rage.
* infinity ponders tossing the output of "dpkg --print-installation-architecture" in a variable in initramfs, so scripts that need to do things on a per-arch basis can stop guessing.
<infinity> The thermal stuff that just blindly tries to load modules that may or may not even exist on your arch is pretty special too.
<Kamion> infinity: yes please
<Mithrandir> infinity: that would be better, I think.
* infinity TODOifies it for tomorrow.
* infinity -> bed.
<jdub> infinity: SOFT!
<infinity> :P
<infinity> I thought it would be novel to wake up in the morning for once.
<infinity> Noon is getting old.
<Goshawk_> hi, toolchain-source package should be upgraded, it exits with gcc-3.4 and binutils-2.15 when breezy uses gcc-4 and binutils-2.16
<Goshawk_> should i report a bug about it?
<ogra> could some native english speaker check the edubuntu flight2 release announcement for typos and grammar on https://wiki.edubuntu.org/EdubuntuFlight2Announcement ?
* Riddell edits it
<ogra> thanks :)
<ogra> dont care about wiki formatting, it will go into an email anyway ;)
<Riddell> ogra: I can't make sense of this sentence: "Please install additional languages post install if your network device is up to download the locale and language packs."
<ogra> hmm
<Kamion> Germanglish grammar ;-)
<ogra> you cant install edbuntu in other languages currently, because the NIC isnt working during install and locales are missing
<ogra> Kamion, nope, plain german grammar ;) 
<pef> is it acceptable to backport something to breezy in order to correct a bug in another package ?
<Kamion> try "If your system is connected to the Internet, please use the Language Selector after installation to download language packs."
<ogra> with english words though
<ogra> thanks :)
<Kamion> could you capitalise Ubuntu, Edubuntu, and so on, please?
<ogra> yup
<ogra> as soon as Riddell is done ...
<Riddell> Kamion: doing
<Kamion> "are gone into this CD images" -> "have been included in these CD images"
<Kamion> ("are gone" is almost always wrong)
<ogra> oh, i didnt know this ...
<Kamion> well, "are gone into" is wrong, "are gone" in other senses might be OK
<ogra> yup, understood ...
<Treenaks> They were here, but they are gone now ;)
<Riddell> ogra: ok, done
<ogra> thanks a lot :)
<Kamion> quote 'sudo ltsp-build-client --arch i386' somehow so that it's separated from the text
<Kamion> Treenaks: right, that's one correct usage
<tseng> who can do test builds on the ppc64?
<tseng> or is there a process to get access while elmo isnt looking
<Kamion> I'd do "sped up" => "faster"
<Kamion> "boot splash" and "boot process" are each two words
<ogra> fixing
<jdub> Kamion: mind if i do a fontconfig upload to add dejavu fallbacks?
<jdub> Kamion: then can i get ttf-dejavu in the desktop seed?
<ogra> eeek, another font ?
<jdub> heh
<jdub> well, i don't really want to *replace* bitstream vera
<ogra> (my ppc live CD already needs overburn on 700MB media)
<jdub> Size: 804424
<jdub> Installed-Size: 1608
<jdub> :-)
<ogra> ok :)
<Kamion> jdub: sounds reasonable, I guess
* Kamion <- no font expert
* Kamion notes we can save 13MB or so on the live CD for free now by killing off the casper seed, but will do that on Monday
<Riddell> jdub: why not replace vera?  dejavu is just vera
<Riddell> although the z's are a little different in their spacing
<jdub> with a different name
<ogra> jdub, do you pick the announcement up from u-d-a ? or do i need to send it separately to fridge-devel ? 
<jdub> ogra: dude, you totally missed the release ;-)
<ogra> :P
<ogra> edubuntu is always a little later ... :)
<jdub> oh, suuuure :-)
<ogra> i dont want to break traditions :P
<jdub> Kamion: http://people.ubuntu.com/~jdub/2005/fontconfig-dejavu.diff
<jdub> oh
<jdub> obvious problem there
<jdub> will fix
<pef> ogra: have you time to answer a question about a bug in Breezy ?
<ogra> sure
<ogra> its sunday, i'm only slacking around here :)
<pef> ogra: thanks :) the problem is with phpmyadmin https://launchpad.net/distros/ubuntu/+source/phpmyadmin/+bug/5904
<pef> yada is used to generate debian/*stuff, and yada version on Breezy is buggy, and generate a buggy prerm script
<pef> Dapper's version of yada works fine
<pef> what can I do to correct that ? backport yada or write a patch for yada in Breezy so it can generates a correct prerm script ?
<pef> (writing the patch is very easy)
<pef> (i wrote it and asked to debian author to check it to be sure it's harmless and doesn't broke something else)
<pef> is it the right way ? :)
<fabbione> pef: breezy is not going to be updated.. tought
<ogra> askink a cluefull person is always good ;) 
<pef> fabbione: isn't it a serious bug ?
<ogra> fabbione, he asks about backorts
<ogra> *backports
<fabbione> pef: noooo?
<fabbione> ah backports...
<fabbione> whatever :)
<fabbione> just don
<pef> so an unremovable package isn't a serious bug ?
<fabbione> just don't backport the kernel and toolchain
<fabbione> pef it's in universe :)
<fabbione> it's MOTU's business
<fabbione> in main it would have been fixed before release probably
<pef> fabbione: i'm not sure MOTU are able to upload to breezy-updates
<ogra> pef, please check what might be affected by a backport, if you can make sure it doesnt require a transition and it doesnt break anything, talk to jdong_ about it ...
<pef> ogra: isn't a patch agains breezy-version a better way ?
<pef> against
<fabbione> to fix something like that, you need to fix yada and all packages that B-D on it
<fabbione> it's not something you can just do for one
<ogra> if its fixed in dapper and doesnt require a transition (as fabbione points out), then it should be fine
<pef> fabbione: but if yada is backported, all packages B-depends packages need to be rebuild too
<ogra> exactly
<fabbione> pef: that's exactly what i said
<ogra> thats what we call a transition
<fabbione> i personally don't think it's worth the trouble
<ogra> seems yada doesnt have any rdepends beyond its own -doc packages
<fabbione> ogra: B-D don't show in rdepends
<ogra> oh, yes
<ogra> silly me
<fabbione> you need to you use melanie i think
<pef> ok, ogra fabbione thanks for the info
<Lathiat2> melanie?
<ogra> the sister of britney and anastacia ... ;)
<Lathiat2> yeh but like, how do i use it?
<ogra> and all the other nice girls that ease your developer lifes
<Lathiat2> like, its not an apt-get or apt-cache command
<fabbione> Lathiat2: like all the other girls :)
<ogra> s/your/our/
<Mithrandir> you can grep-dctrl Sources.
<fabbione> Lathiat2: it can run only on a full archive
<fabbione> afaik
<sivang> Riddell: ping, has krusader made it into main Kubuntu already ?
<Pygi> hi hi
<Riddell> sivang: no, and it isn't seeded to do so
<fabbione> infinity: your attempt to make archive installable didn't succeed.. nautilus isn't happy yet
<Pygi> hi fabbione
<fabbione> hi Pygi 
<sivang> Riddell: I see, it's planned to make it into main or are there any issues with that? (/me looks from Inclusion Report if any(
<Riddell> sivang: there's a main inclusion report, the krusader guys sent me a pleading e-mail asking for it to be included
<Riddell> sivang: but the sources didn't even build with builddir != sourcedir and it pops up about 3 really nasty error dialogues on first run so I'm not convinced it belongs in main
<Riddell> sivang: what's your interest?
<sivang> Riddell: krusader guys sitting next me threatning to hit me with blunt objects if it doesn't make it into main :) I'll forwrad them your comment :-D
<sivang> Riddell: other then that, I am familiar with the tool , and liked ti when I was using KDE. I figured Kubuntu could make good use of it, if it's becomes main quality
<jdub> Kamion: when do you think the next ubuntu-meta spin will be?
<sivang> Riddell: (I am currently mostly using GNOME)
<ogra> jdub, just do it :)
<jdub> meh, no way
<ogra> why ? 
<ogra> if you changed the seeds ... make sure the metapackage matches it ;)
<jdub> didn't eat my spinach this morning
<ogra> aiee ... yes, thats a valid reason :)
<Riddell> any ubuntu users able to supply me with their /etc/xdg/menus/ directory?
<tseng> a dir listing, or a tarball?
<ogra> a flight 2 one ? 
<Riddell> tseng: tar
<Riddell> ogra: yes
<Kamion> jdub: dejavu> I think my main caveat would be to make sure to test it with CJK scripts
<ogra> Riddell, http://people.ubuntu.com/~ogra/xdg.tgz
<Riddell> muchos gracias
<jdub> Kamion: i don't believe it includes any CJK glyphs, so shouldn't have an impact
<Kamion> jdub: ubuntu-meta> any time you like; I can do one on Monday easily
<Kamion> jdub: on the gfxboot timeout countdown to doomsday thing, would just ripping out the graphical clock and displaying "Computer will boot automatically in %d seconds" (or some similar text) be OK?
<jdub> worth a try
<Kamion> Treenaks' bug is something to do with a strange race in the clock, I think, and it would simplify my life a lot if I could just kill all the complexity there
<Treenaks> Kamion: sounds scary
<Kamion> it's almost as if a timeout is triggering before the clock data structures have been properly set up
<Kamion> that should be impossible from my understanding of gfxboot, but it's difficult code
<Treenaks> Kamion: it _is_ a 2.13GHz machine.. but I guess some people are installing on faster systems
* jdub hates lack of solaris express torrent
<Treenaks> Kamion: (lots of people, actually)
<Kamion> I did a lot of the testing on a 1.8GHz amd64 box
<Kamion> so it must be a pretty tight race, if that's what it is
<Kamion> anyway, if I kill the clock, then the timeout handler will just be a bit of screen-painting, and there shouldn't be a problem no matter what it is
<Treenaks> so I should try tomorrow's daily?
<ogra> i tested on my 2.1Ghz lappie here ... no probs so far ...
<Kamion> no, today is Sunday and I have my stepson's carol service this afternoon
<Kamion> please don't expect me to work weekends, even if I do bits and pieces sometimes :P
<Treenaks> Kamion: ok, I'll wait for it :)
<jdub> geez
<jdub> it's 19th of december
<ogra> not here
<slomo_> is someone here who can test building mono for me on ppc64?
<jdub> i think we're being sucked into a black hole and time is appearing to speed up
<jdub> only our metaphysical consciousnesses aren't speeding up with it
<ogra> yeah, thats typical before christmas ...
* fabbione takes away the pipe from jdong_ 
<fabbione> ops
* fabbione takes away the pipe from jdub 
* zul takes away the pipe from fabbione 
<fabbione> hey zul
<zul> hey fabbione how goes it?
<fabbione> zul: fine thanks and you?
<zul> fabbione: good...just fiddling with grub as usual
<zul> amongst other things
<Amaranth> who do i have to poke to get http://gnome-look.org/content/show.php?content=32659 in dapper? :)
<ogra> Amaranth, ????
<ogra> thats in since weeks
<Amaranth> i don't see how
<Amaranth> he just released it
<ogra> we have the prerelease, but it will get updated
<Amaranth> err, this is the first time he released anything to anyone
<Amaranth> this isn't the engine, this is the metacity theme
<rewley> does anyone know anything about ssl certificates on the ubuntu.com webservers?
<Amaranth> they aren't official, they expired, etc
<rewley> yep, i'm wondering who needs to be (in your words) poked?
<Amaranth> they've always been like that
<rewley> it would be nice, though, not to have to tell people "ignore those warnings that your browser is spewing at you"
<Amaranth> true
<BenC> fabbione: still getting bug reports that claim broken 2.6.12-10, but work with 2.6.12-9...one was a amd64 bug about GPF's at random, another is hibernation randomly broken
<fabbione> BenC: yes.. reading on #u-k
<BenC> yeah, wrong channel :)
<hunger> Could somebody please rebuild beagle? It searches for libedataserver-1.2.so.4 and can't find it:-(
<tseng> beagle was last build 2 days after evolution
<tseng> hm no
<tseng> same day
<hunger> tseng: I wonder why it needs evo at all... damn gnome stuff... they don't stop coding till everything depends on evo:-(
<ogra> because it indexes your email ?
<tseng> it works for me dude
<tseng> besides that the evo backend is a seperate package now
<hunger> ogra: I had expected that to be done in beagle-backend-evolution.
<ogra> so you are probably installing the wrong package :)
<hunger> ogra: And even if it worked with evo it would still not find my mail:-(
<ogra> it does find mine... just use the right mail proggy ;)
<ogra> or write a backend for yours ;)
<hunger> ogra: You are right... once I remove beagle-backend-evolution it does index stuff for me.
<slomo_> lamont: ping?
<siretart> what is ryhtmbox using for playing audio?
<tseng> siretart: gstreamer
<siretart> und wtf does it not respect my ~/.asoundrc?
<siretart> it insists on playing on my onboard soundchip instead of using my nice sb live
<tseng> it could be using esd or oss
<slomo_> siretart: do you use alsa output sink or the default esd one?
<siretart> slomo_: where do I set the output sink?
<tseng> system - prefs - sound and system -prefs - multimedia
<tseng> you can set the sound card and the sink
<siretart> I dond find a 'sound and system' item
<slomo_> siretart: gstreamer-properties
<siretart> only 'audio', and I cannot set it there
<tseng> erm
<tseng> and means AND
<tseng> its two apps
<siretart> doen't change anything :(
<siretart> aah, sorry, it did
<siretart> thanks!
<siretart> weird
<siretart> thanks tseng and slomo
<slomo_> np :)
<zul> jbailey: ping
<aroman> anyone else having X problems sayiung "Failed to load module "GLCore"", basically bug #20582, https://bugzilla.ubuntu.com/show_bug.cgi?id=20582 ?
<aroman> saying*
<jbailey> zul: pong, just got home.
<Pygi> aroman: well, have you installed OpenGL and graphic card drivers?
<zul> jbailey: i made a couple of changes to grub ill send you the diff in an email to both you and colin
<aroman> Pygi, well, I suppose... I use the ati driver (not fglrx)...
<jbailey> zul: Cool.
<jbailey> zul: Are you an Ubuntu member yet?
<zul> yeah i am
<Pygi> arinab; use fglrx
<Pygi> it won't work other way
<jbailey> zul: 'kay.  So at the meeting in January, we should put you in the queue for main upload privs after we're done reviewing grub.
<aroman> Pygi, why not?
<zul> jbailey: according to launchpad i havent signed the coc yet which is bull
<jbailey> If you have a GPG key, you can just sign it again.
<Pygi> aroman: because ati drivers are very bad, and don't work nowhere
<zul> *sigh*
<jbailey> Mine had said that I hadn't signed it either, and it was simplest to just do it again.
<ogra> jbailey, zul is MOTU as long as i am ... 
<aroman> Pygi, really? they work fine on gentoo, better than fglrx ones for that matter
<jbailey> ogra: Cool.  I wasn't sure if he had bothered doing the whole motu thing.  I was running short of time, so stopped following the motu channels, lists and meetings.
<aroman> Pygi, notice the bug report I pasted here mentions the fglrx drivers
<zul> jbailey: that was more than a year ago i think
<ogra> jbailey, since he wnt off to the kernel team i dont think zul has done much motu work :)
<zul> i havent really..
<zul> im just a wannabe
<Pygi> aroman: I have ATI card too
<aroman> Pygi, and glxinfo | grep rendering shows Yes for dri?
<ogra> zul, ah, come on... we'd have a lot more kernel bugs without you ;)
<zul> heh...BenC is just doing fine himself ;)
<Pygi> aroman: if you by reffering to DRI mean to "direct rendering" then yes, it does show yes
<aroman> hmm
<aroman> odd
<aroman> with the latest dapper drake updates, I assume?
<Pygi> nop, breezy
<Pygi> I am running dapper on another computer, but I ain't really trying to help people with dapper ;)
<Pygi> read the topic on #ubuntu - no support for dapper ;)
<ogra> Pygi, ??
<aroman> Pygi, aye, no support, but -devel channel, we've gotta figure out why it's messing up right? :)
<Pygi> aroman: yup ;)
<aroman> Pygi, why would I ask about breezy on a -devel channel? :)
<aroman> hmmm I wonder if a package isn't installed....
<aroman> bah.. I need to go... gonna investigate this further tomorrow
<Pygi> k
<Pygi> ogra: why the question marks? ;)
<ogra> <Pygi> read the topic on #ubuntu - no support for dapper ;)
<ogra> #ubuntu is the proposed supportchannel for all versions we ship ...
<Pygi> well, I think there is no support for dapper....isn't that true?
<Pygi> yes, but dapper isn't ready just yet...
<ogra> still 
<ogra> all support should happen there
<ogra> even for dapper
<Pygi> ah, k
<Pygi> sorry for the mixup then
<ogra> as well as no support should happen here :)
<Pygi> k
<zul> jbailey: i should have something for you tonight but i have to write documentation for work
<jbailey> zul: Awesome, thanks!
<zul> later
<Pygi> *we* really have to fix the keyboard layout thingy
<Pygi> it's getting annoying
<Pygi> not to me, but to the others...
<LaserJock> seb128: ping?
<seb128> LaserJock: pong
<LaserJock> seb128: been trying to dig around trying to figure out where that compreg.dat file came from
<seb128> LaserJock: any luck?
<LaserJock> not really
<LaserJock> I did dpkg -S on it and got nothing
<seb128> it's not shipped by a package
<seb128> it's generated by something
<LaserJock> I greped /var/lib/dpkg/info for it and didn't get much of anything
<seb128> I guess I'm going to write a small monitor stuff than opens a dialog when the file is create
<seb128> created
<LaserJock> somebody suggested it might be in a posinst script
<LaserJock> seb128: good idea
<LaserJock> could it be possible that it was created by a package at one time but is no longer so it doesn't show up with dpkg -S and such
<seb128> nop
<seb128> dpkg is not that bugged
<seb128> if a package stop shipping a non-conffile it removes it on upgrade
<LaserJock> hmm, seems like an extension would be a likely culprit perhaps
<LaserJock> well, has anybody figured out what is wrong with the  compreg.dat file that gives the problem, or is it just its presence that is the problem
<seb128> second option
<LaserJock> really? that seems weird
<seb128> why?
<seb128> the file is not required
<seb128> you can remove it and firefox works fine
<seb128> and firefox 1.5 doesn't ship any such file
<LaserJock> but it just seem weird that the presence of the file causes a problem. Oh, well I'm not very knowledgeable about such things
<LaserJock> so in /var/lib/dpkg/info it says that the firefox.prerm script removes it. Why would it do that if it didn't install it in the first place?
<seb128> leftover of 1.0.n 
<LaserJock> ahh, ok
<LaserJock> well, is there any output that I can give that would be useful? I am at the end of my abilities of finding where the file came from :-)
<seth_k|lappy> compreg.dat is a component registry file
<seth_k|lappy> it's an Extensions thing; you only get it if you have Extensions installed
<LaserJock> so what is that a bug in if it breaks apps (like yelp)?
<daniels> right, which I think firefox's postinst regenerates in its install
<daniels> LaserJock: it's a bug in mozilla for being crap
<daniels> so, y'know, news at eleven
<seb128> LaserJock: not easy to reply to that without knowing what creates the file/when/how
<LaserJock> well, all I know is that I have extensions installed on the install that has the problem and no extensions installed on the one that works
<seth_k|lappy> compreg.dat basically keeps track of compatibility between components and interfaces in Firefox code, and external programs / extensions / whatever. According to http://www.mozilla.org/projects/firefox/extensions/restart.html it's trashed and recreated on Firefox startup if compatibility.ini has changed
<seb128> seth_k|lappy: how comes it get generated to /usr, seems to be an user file according to your description
<LaserJock> but many extensions ask to install as root in order to work properly
<daniels> christ that's broken
<seb128> firefox is such crap
<seth_k|lappy> right, and when it then tries to write to the file on the next startup, b/c it's been written somewhere that a normal user can't access, things go nuts
<seth_k|lappy> from what I can tell
<seb128> anyway the bug happens to some people who use epiphany and not firefox and have no extension installed it seems; so I'm not sure that's the issue
<daniels> iz epiphany bug
<seb128> iz GTK bug rather
<seb128> because it crashes yelp/debhelp/python-gnome too
<daniels> definitely :)
<daniels> just as long as it's not an XKB bug
<daniels> seb128: gecko bug?
<seb128> s/debh/devh/
<seb128> daniels: gtkembedmoz bug yep: http://bugzilla.ubuntu.com/show_bug.cgi?id=20183
<seb128> aka firefox bog
<seb128> anyway time for dinner
<seb128> bbl
<HiddenWolf> hey Yvonne 
<Yvonne> hey HiddenWolf :)
<HiddenWolf> I just checked the dapper package page, and it seems Mozilla-thunderbird-locale-el and -es are in universe. All others are in main.
<ogra> grrr, i'm about to kill someone ...
<ogra> has nobody told debian maintainers that you dont modify upstream tarballs ?
<Pygi> heh, don't kill people ;)
<ogra> kino_0.80-1ubuntu1_source.changes REJECTED: kino_0.80.orig.tar.gz has size 1512542 instead of expected 1498967
<daniels> sure you modify upstream tarballs
<daniels> you remove non-dfsg-free stuff
<ogra> why the heck do they remove stuff directly in the upstream tarball, even the package uses dpatch and it would be an easy task to use it
<ogra> there is no non-dfsg-free stuff being removed 
<ogra> there is stuff like includes to lqt instead of lquicktime being changed in configure and configure.in
<ogra> stuff that belons in a patch ...
<micke1234> Hi, I just dist-upgraded to dapper from breezy and now my xserver won't start, I am getting the error "lib
<micke1234> libc_wrapper invalid FILE passed to xf86printf?
<daniels> "lib"?
<daniels> at a guess, it can't open your logfile
<micke1234> sorry I hit Enter to soon
<micke1234> wait, I go check the permissions of the logfile
<Kamion> ogra: it has been Debian policy for some time that DFSG-free material must be entirely removed, not merely patched out
<daniels> and you are running the server as root, right?
<Kamion> but sure, random other stuff should be patched
<ogra> Kamion, but there are no dfsg changes ... its mainly includes etc ...
<micke1234> I run my server from the gdm scripts... (sudo /etc/init.d/gdm restart)
<ogra> Kamion, what really bothers me is that the package already has 8 dpatches... but they didnt use dpatch for this one ... :(
<micke1234> the message appears in my logfile also, so it cannot be the logfile
<Kamion> ogra: so it was almost certainly an accident
<ogra> is there a way to wipe our orig.tar.gz from the archive to be able to upload the debian one ? else we'll have to carry a silly patch for the whole 0.80 release
<daniels> 'silly patch'
<daniels> micke1234: if you could file a bug with the full Xorg.0.log, that would be ininice
<daniels> micke1234: bonus points if you're able to attach a sudo strace -e file Xorg :1 -ac vt8, showing which file it's failing to open
<floam> hm. is not all of Xorg 6.99.99.903 up?
<micke1234> daniels, I no going after the bonus points...
<daniels> floam: the server isn't
<daniels> but rc3 is old hat
<tseng> daniels: are we using dlloader now?
<floam> why is the server held back?
<daniels> tseng: the modular tree is incapable of elfloader support
<tseng> thats pretty rad
<daniels> floam: because it was fucked
<floam> hm
<daniels> tseng: (by design)
<floam> I guess that's why my mouse still acts weird, perhaps I need the RC3 server.
<micke1234> daniels, I get "strace: invalid system call +file when I try your command
<tseng> daniels: good riddance to that
<daniels> micke1234: works for me?
<daniels> floam: correct
<micke1234> "strace -e +file Xorg :1 -ac vt8" does not work for me? strace --version gives me: 4.5.12
<daniels> ... there's no + in file
<Kamion> ogra: no, under no circumstances do we *ever* replace a file in the pool with a different file having the same name
<ogra> Kamion, thats what i feared :/
<Kamion> this is a good thing
<ogra> not in this case though ...
<Kamion> doing otherwise would severely break a lot of mirrors
<daniels> dude, if it really seriously bothers you, bump the upstream version
<floam> guess I'll suffer with mousedev for another while
<ogra> daniels, never ... the i rather build a patch
<micke1234> daniels, sorry for that ircII is kind of new to me (it adds + to a wrapped line)
<ogra> even if its not necessary ...
<daniels> ogra: i'm sure there are worse things
<Kamion> it won't kill you
<Kamion> snap :)
<ogra> nah, its just annoying and eats extra time i didnt want to invest ...
<daniels> arguably you've spent more time talking about iton IRC than you would've fixing it :P
<ogra> and its a bit frustrating to be bitten by the merge policy, just because i took the unmodofied upstream and was faster than debian
<janimo> anybody know what this given-back is about? http://people.ubuntu.com/~lamont/buildLogs/x/xubuntu-default-settings/0.2/
<Kamion> it's not the merge policy, it's a requirement on the archive in order to actually work properly
<Kamion> complaining will not get it changed because changing it would be bad
<ogra> Kamion, the kino 0.7 series didnt work with the new gtk we use, and debian released 0.80 last week ...
<micke1234> daniels how to I pipe the output from strace to a file it's printing on stderr
<daniels> the lesson for this is, next time if you desperately need a new upstream for something, either donate it to debian or just deal when it's different
<daniels> micke1234: > foo 2>&1
<Kamion> ogra: I don't care about the details :)
<ogra> Kamion, so i had to package 0.80 before debian to get the merge done in time
<Kamion> ogra: I still don't care
<micke1234> daniels thanks
<ogra> which i call being bitten by our merge policy :P
<Kamion> 21:21 < daniels> arguably you've spent more time talking about iton IRC than you would've fixing it :P
<Kamion> what he said
<Kamion> seriously, it's not worth arguing about
<daniels> except possibly with a space between 'it' and 'on'
<micke1234> daniels, I just tried the "nv" driver instead of "nvidia", now it is working...
<eruin> I suffer hardlocks on ati, but fglrx works like a charm (apart from GLcore failing to load) :)
<daniels> micke1234: cool, someone else's problem ;)
<daniels> eruin: glcore failing to load is a 'don't do that' problem, i.e. don't load glcore from your xorg.conf explicitly
<micke1234> daniels, still it kind of stinks, because I cannot what stuff on my projector then (using TwinView)
<micke1234> daniels, the strace didn't give me any clue about which file is failing, everything looks fine
<lucasvo> janimo: I have problems with xfce, it doesn't use the keyboardlayout defined in xorg.conf
<micke1234> daniels, I brb, I'm switching into X...
<Kamion> daniels: default installations put GLcore in xorg.conf
<janimo> lucasvo, I am looking at the xkb plugin right now
<janimo> did you add the keyboard switch suggestion to the wiki btw?
<mikael_> Hi daniels, I'm back :)
<eruin> suspend now works with fglrx
<daniels> Kamion: shit, still does; i thought we explicitly excluded that
<micke1234> I just upgraded to dapper, no my sound is not working and the programs menu is empty...
<daniels> micke1234: please use #ubuntu for this sort of thing
<seb128> the menu stuff is to bugzilla already
<lucasvo> janimo: what, keyboardswitch?
<micke1234> seb128, do you know the bugnumber? or a quick workaround?
<janimo> lucasvo, ok so it wasn't you :)
<janimo> someone just added to xubuntu proposed apps a couple of keyboard swicthers and I thought it might have been you since you have a kb issue 
<lucasvo> daniels: how can I find out if the monitor is sending right ddc constants, when you only have an Xlog?
<seb128> micke1234: restart gam_server
<lucasvo> janimo: I have a kb issue with xfce and ltsp
<janimo> lucasvo, so in what way does it not use xork keymap?
<lucasvo> janimo: it is totally wrong, it is us instead of ch_de
<daniels> lucasvo: most of them dump the edid in human-readable form
<janimo> what I know about keymaps is what I read in the past 5-10 minutes with interruptions btw :)
<lucasvo> daniels: I am talking about this bug: http://bugzilla.ubuntu.com/show_bug.cgi?id=17232
<janimo> lucasvo, could have been korean, consider yourself lucky :)
<lucasvo> janimo: my sister is not lucky :D
<janimo> I'll have to test keymaps as I always use the US layout
<daniels> lucasvo: it's all there
<janimo> I'll look at it tomorrow
<daniels> starting at the line which reads (II) MGA(0): VBE DDC Monitor info: 0x85eab40
<daniels> it's deliberate policy to only use the second-highest resolution on CRTs
<daniels> since the highest often looks like crap
<lucasvo> daniels: so it is missing in Xorg, that it autodetects it wrong?
<janimo> lucasvo, breezy or dapper?
<daniels> no, it's a decision I made when I wrote xresprobe
<lucasvo> daniels: huh?
<daniels> lucasvo: xorg doesn't do the detection, strictly speaking, xresprobe does
<daniels> and on crts, we don't use the highest resolution
<lucasvo> daniels: aparently it is a tft
<lucasvo> daniels: 15 inch :D
<daniels> if your monitor advertises 1024x768@60 and 800x600@60, as yours does, we'll use 8000x600
<lucasvo> daniels: hm, but even if it is tft 15" ?
<lucasvo> daniels: because 800x600 on 15 inch is waste of space
<daniels> (II) MGA(0): Analog Display Input
<daniels> that's all we can go by
<daniels> lucasvo: 8x6 on 15" isn't that bad a waste of space
<daniels> lucasvo: your eyes are good and so are mine.  ask someone who doesn't have flawless eyesight what they think of 10x7.
<lucasvo> daniels: so they should then be able to set it, or do you use 800x600 for your 15" monitor?
* tseng offers up resapplet
<lucasvo> tseng: the problem is I am using it for ltsp, and there it autodetects it at startup
<daniels> lucasvo: i don't have a 15" monitor
<lucasvo> daniels: so how comes that every other 15" I have uses 1024x786, even with xorg autodetection?
<daniels> lucasvo: because they advertise 1024x768 at a higher refresh rate
<daniels> well, at more than one
<daniels> i didn't say the lagorithm was *good*
<lucasvo> daniels: and is there any table for "special" cases, where one doesn't calculate it from the refreshrate
<lucasvo> ?
<lucasvo> daniels: so it is basically a WONTFIX bug?
<daniels> well, patches are welcome
<daniels> but it's served us pretty well over the years
<daniels> especially within the limitations of xorg
<lucasvo> daniels: is there already something like a table for special cases
<lucasvo> I can't say anything about it, I don't know X
<daniels> there's no table for special cases, no
<daniels> i'm not inclined to add one, to be honest
<lucasvo> daniels: so how should I change the algorythm? or apply a patch?
<daniels> unless dell ships some monitor that half the planet buys, and its edid is so spectacularly broken that it makes the monitor explode into tiny little glass fragments which shoot into everyone's eyes
<lucasvo> lol
<daniels> lucasvo: look at /usr/share/xresprobe/ddcprobe.sh
<lucasvo> I know, such a table is crap but maybe the easiest solution
<daniels> tbh I don't see a real problem
<daniels> for you rfor your use, if you want 10x7 on 15", sure
<daniels> but when 'best resolution' is totally subjective anyway, it's not really useful for the common case
<lucasvo> 8x6 is so blurry, you can't read it
<daniels>           score
<daniels> (argh, worst irssi misfeature ever.)
<lucasvo> I don't think I aman uncommon case
<lucasvo> yes
<lucasvo> what's with score?
<daniels> score == 'awesome'
<lucasvo> yes
<daniels> and, er, hate to break it to you, but ltsp is still a pretty uncommon case
<daniels> it's also a case which by definition includes local admins
<daniels> as opposed to 'must must must must work out of the box on cd install'
<lucasvo> daniels: no, but xorg auto detection is not only on ltsp
<lucasvo> daniels: it is also on must must must must work out of the box ubuntu install
<greenpenguin13> greenpenguin13: hi
<daniels> correct
<daniels> i mean, if you want to send a patch with a special case for this exact monitor, including the patched edid, feel free
<daniels> but it's not high on my todo list, y'know
<lucasvo> no prob
<lucasvo> now I know the reason
<lucasvo> daniels: you mean something like: if $monitorname == "sdm": $resolutions="1024x768"
<lucasvo> daniels: I think it would be pretty much the only thing to do :D
<daniels> you'd want the match to be a little more strict than that
<lucasvo> daniels: sdm-(II) MGA(0): Monitor name: SDM-M51 so SDM-M51 should be enough?
<daniels> also match on manufacturer and model
<daniels> and the exact resolution list it spits out
<lucasvo> daniels: why, is there any other screen which name is sdm-m51
<lucasvo> sony would sue the company anyway
<daniels> lucasvo: what on earth?
<daniels> no-one else has the right to name a monitor sdm-m51?
<daniels> it's entirely conceivable that there is
<lucasvo> daniels: ok
<lucasvo> daniels: thanks for your help
<daniels> np
<lucasvo> daniels: if I will give you patch which meats all the requirements, will it be added to dapper ? :p
<daniels> probably
<daniels> but no guarantees
<lucasvo> daniels: np
#ubuntu-devel 2005-12-24
<Pygi> welcome crimsun
<crimsun> hi Pygi 
<Pygi> bye ;)
<daniels> hrngar
<jdub> Kamion: ping
<jdub> Kamion: ping (printing related)
<Kamion> jdub: I know very little about printing ...
<jdub> oh, you're here
<jdub> Kamion: yeah, wondering who's our "printer person" -> martin?
<tseng> pitti
<tseng> jsgotangco: yo
<Kamion> jdub: yes, he's a good first port of call at least
<jsgotangco> tseng, morning to you!
<jdub> Kamion: see mail
<Kamion> not really my call, but sure :)
<Kamion> will wait for pitti to respond
* Kamion adds a normal/expert mode option to gfxboot-theme-ubuntu, and goes to bed
<jdub> Kamion: did you like my ping content payload? :-)
<Kamion> better :)
<tseng> jdub: dude, when are you release dudes going to put your foot down on Clearlooks
<jdub> whichwhat?
<tseng> jdub: iz gtk boog
<tseng> clearlooks-cairo burning peoples eyes out of their skull
<jdub> what's wrong with it?
<jdub> it is so much love
<tseng> its 3 times brighter
<jdub> the blue one, yeah
<tseng> the "default" :)
<eruin> it's pretty!
<jdub> tseng: our default is human
<tseng> human is for hippies
<tseng> or something.
<jsgotangco> lol
<jdub> the only trouble with human atm is that i haven't bothered to respin it for local changes, such as removing the menubar gradient, etc (not even sure if current cl supports those yet)
<zul> heylo
<zul> jbailey: email sent with the grub stuff
<jdub> ooh, that reminds me
<jdub> we should kill that ugly grub output for dapper
<zul> jdub: with what?
<jdub> well, probably a text editor. but i wouldn't be the least bit offended if we used a bent pipe and a blunt chisel
<zul> :P
<zul> i mean replace it with what?
<jdub> nothing, just remove the ugly post-menu status output
<infinity> And re-format the pre-menu init to be one line, instead of 3?
<infinity> Sold.
<zul> patches accepted ;)
<infinity> -crap
<infinity> +
<zul> jdub: i just sent a diff that enables i2o support, cpqarray support, and makes the output of menu.lst a bit better
<cjb> Hello.  I think linux-image-2.6.15-8-amd64-k8-smp has been compiled without SATA support; I get a panic mounting the root fs, where the previous 2.6.15.x have been fine.
<infinity> It definitely has SATA support.
<infinity> After you panic to a shell, can you 'cat /proc/partition' and see if your SATA drive (/dev/sda, for instance), has magically moved to being an IDE driver (/dev/hda, etc)?
<cjb> I'll do that now.  Thanks.
<infinity> If so, the bug lives in how we do module load ordering in the udev setup.
* infinity runs to the corner store.
<infinity> Back in 5.
<cjb> I'm left without /proc after dropping to a tty.  How should I mount it?  
<cjb> (I suppose I could also just try root=/dev/hda3 and see if it works..)
<TheMuso> cjb: Don't forget that /etc/fstab has the original partition entry, which means teh boot will halt when it tries to remount the root filesystem read-write.
<cjb> Nope, /dev/hda3 fails too.
<mdke> sounds like a different bug
<cjb> TheMuso: Haven't got far enough to be able to see /etc yet.  :)
<crimsun> cjb: echo $ROOT
<cjb> infinity's correct about /lib/modules/2.6.15-8-amd64-k8-smp/kernel/drivers/scsi/sata_*.ko being present.  
<infinity> If you don't h /proc yet, you're definitely seeing a different bug than the one I was describing.
<cjb> crimsun: As passed to the kernel?  root=/dev/sda3 is what I usually pass, and I've now tried root/dev/hda3.  
* infinity ponders.
<cjb> Oh!  I have /proc this boot.  partitions is empty, though.
<infinity> Can you boot without "quiet" and "splash" and watch the kernel output?.. See if it's loading your drivers at all?
<infinity> Also, cat /proc/modules and see if the right drivers appear to be loaded.
<cjb> Just did that.  :)  sata_sil and scsi_mod are loaded.
<cjb> I see:  ata1: SATA link up 1.5Gbps .. ata1: dev0 not supported, ignoring.
<cjb> (There's only one hdd in the machine, and my IDE DVD/CD drives are up on hd{c,d} -- it must be the SATA hdd that it's talking about.)
<infinity> Oh, fun.
<cjb> So I wonder if "not supported" means that the SATA module I need isn't there.  Lemme boot back into the good kernel and see what it uses.
<infinity> I'd take that one to #ubuntu-kernel and complain to BenC, then... (or file a bug on the "linux" package
<cjb> Ah hah.  Thanks much.
<BenC> dev0 is a cdrom?
<infinity> No, it's his hard drive. :)
<infinity> root device, no less.
<BenC> cjb: is there an error line before ata1: dev0 not supported, ignoring?
<cjb> It's just using sata_sil under the (working) 2.6.15-6-amd64-k8-smp, which is the same module that's loaded but not working with 2.6.15-8.
<cjb> BenC: No, the previous line is the quoted one finding the channel.
<BenC> that message gets spit out thwn ata_id_is_ata() returns false, so something is saying that your harddrive is not actually an ATA drive :)
<cjb>  /proc/scsi/scsi under 2.6.15-6 disagrees with whatever is saying that :)
<BenC> s/thwn/when/, not sure how I got that from my keyboard
<BenC> I've seen this in one other bug report
<BenC> but it got fixed with -8, not broken with it
<cjb> And fixes never cause regressions, right?  :)
<BenC> it shouldn't cause the same regression that it fixes, that would make it not a fix :)
<cjb> I don't know if that's what's happened, though; I have been following each of the dapper kernels, so it seems fairly straightforward that something has changed that's breaking it for me.  I'm not doing anything more complicated than apt-get'ing the newer image.
<BenC> I'm not saying that it isn't broken
<BenC> I'm saying that the same error you have, I fixed for another use by reverting the driver back to stock source for -8
<BenC> hold on a second
<cjb> 'kay.  I'd be interested to see the diff.
<BenC> I need to make sure this is the same driver (it was sata, but maybe not the sil driver)
<BenC> nope, stock code
<BenC> so whatever is in 2.6.15-rc6 is what I have in my tree
<BenC> the patch I had was basically a pull from jgarzik's libata git tree
<cjb> Hrr.  Righto.
<cjb> Well, let me know if I can do anything to track it down.  I suppose for now I'll starting building my own kernels and keep trying your latest ones when they come out.
<lamont> daniels: ping
<dooglus> if I use the dapper build of firefox, it doesn't know any trusted certificate authorities.  running the official mozilla build on the same profile does see the authorities.  should I report this as a bug?
<dooglus> or is dapper in enough of a state of flux that it's not worth reporting?
<cjb> I'm running what is presumably the same build, and do have a CA chain.
<exarkun> if you had an old profile, or run an official firefox build with a profile created w/ dapper's firefox, it will add the CAs to the profile, and subsequent runs of dapper's firefox will have the CA chain.
<marcin> hi I see you guys are talking about firefox on dapper - on my dekstop firefox doesn't work at all - it shows a little window with "<window id.... " info and that's all
<marcin> is that a known issue or should I file the bug?
<cjb> Actually, I blitzed my profile this morning.  You're saying that the CA chain is stored in each user's profile, then, and not given to a new profile?  Why?
<cjb> marcin: Not seeing that here.  Try killing your profile.
<marcin> I removed almost everything from my ~/ and still no luck
<marcin> cjb: is there another way to kill profile?
<cjb> mv .firefox .firefox-bak should do it.
<marcin> cjb: epiphany is usable - but firefox isn't
<exarkun> unless your profiles are in ~/.mozilla :)
<cjb> You can also try firefox -ProfileManager
<marcin> removed old profile and created new... ffox still broken
<marcin> it says - starting 'deer park' and then... as I said before
<marcin> maybe I'll try to uninstall ffox and manually remove all ffox directories in /usr
<dooglus> I tried making a new profile with the dapper firefox.  It still shows no CA chain.
<dooglus> but then running the official mozilla build with the profile that the dapper build made shows the chain just fine.
<dooglus> I installed dapper in a chroot a long time ago, and now am booting it directly using LILO - I don't know if that resulted in me missing some essential setup
<exarkun> a dist-upgrade from breezy does the same thing
<exarkun> I am pretty sure the ff package is just broken.
<dooglus> I don't think it ever went though a full install procedure - like it never asked me what kind of keyboard I have - and so in virtual consoles it uses the USA layout.
<dooglus> exarkun: but cjb has it working...
<dooglus> exarkun: and I didn't do a dist-upgrade.  I ran some command which installed dapper in a chroot, and then I configured lilo to boot that chroot partition directly.
<dooglus> so it's never been "installed" other than by the script which set up the initial chroot
<dooglus> incidentally, if you run "sudo passwd", type your user password if prompted and then type control-d to both the password prompts, do you see a sigsegv?
<marcin> haaa finally - thanks guys - I manually cleaned profile and all firefox dirs in /var and /usr and now it's usable
<cjb> dooglus: Yes.
<cjb> #0  0x00002aaaab7d33c8 in pam_sm_chauthtok () from /lib/security/pam_unix.so
<bmonty> elmo: please sync privoxy from unstable, ok to drop ubuntu changes
<jdub> *cough*
<jdub> hahaha:
<jdub> > > This discussion is more appropriate on sounder (hint).
<jdub> >
<jdub> > No.  This is important.
<jdub> 
<jdub> (... that's why it's happen on -users?!)
<lifeless> yes. because uninformed opinion is useful
<jdub> i guess i should read this thread
<jdub> under attack!
<mjg59> It'll just depress me
<jsgotangco> heh
* ajmitch goes to watch the car crash on -users
<Tm_T> wivefabbid
<dooglus> cjb: me too.  only happens for root though.
<LaserJock> hmm, I don't understand this MTA issue. So mailx and postfix were removed from the Ubuntu install cd?
<mjg59> LaserJock: I don't think postfix has been installed by default for a while
<mjg59> LaserJock: And it seems to be part of the ship seed (still)
<LaserJock> excuse my ignorance but aren't they CLI email apps? Doesn't evolution and thunderbird like apps replace them.
<Tm_T> err
<Tm_T> gui doesn't replace cli
<Tm_T> atleast not in my use
<LaserJock> I understand that
<LaserJock> but if we are shipping evolution why would we need postfix/mail? for the common user anyway
<LaserJock> I just hear a lot about them but I don't use them so I don't really know what they do
<crimsun> there're nasty threads on u-u about that
<mjg59> LaserJock: postfix is a mail server
<LaserJock> crimsun: yeah, that is what I'm trying to figure out
<crimsun> most of them completely over-the-top and incoherent
<LaserJock> mjg59: why would a user need a mail server?
<mjg59> LaserJock: In general, you don't
<Tm_T> in general, you don't need thunderbird and evolution
<Tm_T> just one
<LaserJock> well, I know I don't need both I was just thinking that those two would cover most of the Ubuntu users email usage
<LaserJock> I'm just trying to figure out why people would be so mad about not having mailx/postfix on the install cd
<Tm_T> heh
<lamont> mjg59: postfix was default install in warty, can't remember about hoary, gone from base in breezy
<lamont> was in ubuntu-base in hoary
<lamont> still in breezy ship-seed, iirc
<mjg59> lamont: Yeah, that's what I thought
<lamont> and the effort had and has my full endorsement.
<lamont> (ship, not part of base or desktop)
<LaserJock> I mean I was kinda weirded out when I saw that Ubuntu doesn't install the ssh server by default but there are logical reasons so I'm ok with it. I install it first thing when I install Ubuntu, no problem
<LaserJock> seems like a similar situation with mailx/postfix
<lamont> LaserJock: that's the same reason I supported not installing postfix by default
<lamont> specifically, the desktop install must present _NO_ externally listening ports (127.0.0.1 is OK, but still discouraged)
<lamont> hence no ssh server, and (in warty/hoary) a crippled postfix install.  By dropping it from the base install, I get to ask the questions I need to properly configure things if you do choose to install it.
<lamont> --> good thing
<LaserJock> makes sense to me
<lamont> LaserJock: the other edict is "no questions unless you (1) can't configure without asking it, and (2) grandma will know the answer."  postfix's required questions fail (2)
<lamont> and frankly, an MTA on grandma's machine is just going to slowly fill /var/mail, and never get read, or understood if it is read.
<LaserJock> hmm, what goes into /var/mail? messages from the computer?
<lamont> cron output, for starters.
<lamont> and a few other things like to send email if it's available
<LaserJock> hmm, I never knew that. I thought apps used /var/logs/
<lamont> not all of them by any means
<LaserJock> ok, well I think I understand what's going on in you-you better now. Thanks mjg59 and lamont
<LaserJock> s/you-you/ubuntu-user/ stupid gaim
<shawarma> LaserJock: How does gaim turn ubuntu-user into you-you?
<lamont> u-u
<shawarma> Ah... LOL
<shawarma> Yeah, that's pretty stupid.
<lamont> (I expect_)
<LaserJock> yes, lamont is right
<LaserJock> I usually use irssi or xchat, but tonight I'm on my wife's Windows laptop so I'm using gaim
<shawarma> ssh to a proper machine with irssi on it?
<LaserJock> I was lazy tonight ;-)
<LaserJock> I sure wish xchat was free for Windows
<shawarma> Huh? It's not?
<LaserJock> $19.95
<exarkun> it is, if you build it yourself
<exarkun> building things on win32 is hard enough that people actually pay for the binaries though :)
<LaserJock> exarkun: hmm, I don't think it is quite worth the trouble to build it myself
<seth_k|lappy> LaserJock, http://silenceisdefeat.org/~b0at/xchat/win32/
<seth_k|lappy> other people took the trouble so you don't have to
<LaserJock> seth_k|lappy: oh, that's cool.
<LaserJock> k, brb
<LaserJock> oh, yeah. that is much better
<seth_k|lappy> :)
<LaserJock> thank you seth_k|lappy. I have been wanting that for at least a month now
<seth_k|lappy> np LaserJock, glad I knew the link
<LaserJock> yeah, I got so bummed out by the xchat website that I gave up
<fabbione> morning
<StevenK> Is there any hard and fast rule what to do about a library that still wants to use imake from the X packages? Do we kill them, or fix them, or what?
<StevenK> My digging has shown that it is deeply intwined with the imake template files that used to be provided by xutils, and I'm just unsure of where to go from here.
<fabbione> StevenK: try to kill them :)
<fabbione> or you will need to fall in love with Imake
<fabbione> sivang: ping?
<StevenK> fabbione: IE: Don't try and auto* it myself?
<fabbione> StevenK: that's what i would suggest.. 
<fabbione> Imake is easy to use.. really
<fabbione> but you get binded to an old obsolete way of building X ckages
<fabbione> packages
<StevenK> It's just going to be a large diff due to me having to pull a large number of imake files from the old xutils.
<fabbione> StevenK: not really
<fabbione> you don
<fabbione> you don't need to pull them
<fabbione> you need to install the proper B-D on dapper
<fabbione> there is Imake and all the config files as before
<fabbione> just in different pkgs
<dholbach> good morning
<fabbione> hey dholbach 
<jsgotangco> hey dholbach 
<dholbach> hey Fabio, Jerome, how are you guys doing?
<jsgotangco> dholbach, pretty good, just a week before christmas, making sure work targets are done
<fabbione> dholbach: still asleep :)
* dholbach feels with both of you :)
<infinity> elmo : libselpol1-dev is begging to get promoted to main, I'm assuming.
<dholbach> hi infinity
<pitti> Good morning
<dholbach> hellas martin
<infinity> HAH.  php.net can bite me.
<infinity> pitti : Remember my old curl open_basedir fix that upstream did differently in 4.4.0?
<infinity> pitti : Well, mine works, there's doesn't.  So, breezy needs an update for the "extra curl vuln", hoary and warty don't.
<pitti> infinity: heh
<infinity> s/there's/theirs/  I should start pretending I'm German, so I have an excuse for these things.
<pitti> infinity: did they take your patch now?
<infinity> No, they just made theirs even more complex in 4.4.1 to work around the problem. :)
<pitti> infinity: oh, I seldomly mix up things that merely sound similar (modulo typos)
* infinity shrugs.
<infinity> I'm following their codebase in breezy/dapper, since we have half their fix, but I'm not about to use their patch in the older releases, when ours works and is readable.
<pitti> infinity: well, since they made it very clear that they, by and large, are not interested in fixing that stuff at all, I wonder why they try to patch it...
<infinity> They've been fixing a LOT of safe_mode and open_basedir stuff recently.
<pitti> hmm, mood of the day? :)
<infinity> I can't help but think we may have been one of the groups that pushed them to do so by continuing to do security releases against their wishes. :P
<infinity> It definitely looks like a bit of a change of heart, anyway.
<maswan> infinity: Oh? php developers getting a quarter of a clue wrt security?
<infinity> Especially withupstream actually alerting vendor-sec to safe_mode/open_basedir fixes...
<infinity> Heck, they didn't used to tell vendor-sec about ANYTHING.
<maswan> This is indeed news. Perhaps one could even use php on a resonably secure hobby setting soon. :P
<fabbione> hey maswan 
<maswan> fabbione: $greeting_phrase
<pitti> Hi marilize 
<jdub> morning marilize 
<marilize> hi pitti :) jdub:)
<fabbione> hey marcin 
<fabbione> bah
<fabbione> hey marilize 
<marilize> fabbione! morning
<maswan> I wonder if I'll get time to fiddle around with that dapper machine again at work, or if I'm going to be busy doing actual work instead of filing bug reports. ;)
<infinity> pitti : Oh, and you can mark us not vulnerable for that PEAR CVE.. Our PEAR is too old to have the broken feature.
<pitti> infinity: the installer thing? good to hear :)
<marilize> fabbione: I'm going to change my name to just *M*
<pitti> security through obsolescence
<fabbione> marilize: good plan :)
<infinity> Word.
<pitti> infinity: (however that it spelt correctly...)
<infinity> Looks right to me.
<jdub> marilize: a good precedent would inspire _M_
<infinity> And dict agrees.
<jdub> like this:
* maswan waits for the /nick _J_ :)
<jdub> boh!
<jdub> _M_ is already in use
<_J_> la la la
<maswan> moo
<_J_> sydney is so great
<_J_> blue skies
<_J_> lovely sun
<infinity> pitti : So, anyhow, the patches are all pretty much sorted, I'll finish testing POCs and do some uploads later.
<_J_> haw haw haw
<marilize> jdub: heh
<marilize> jdub: we might get confused whos who!
<maswan> well, if _M_ is taken, how about _M-? :)
<jdub> ^M^ ;-)
<maswan> with _-=^ we could have 16 different M's around. ;)
* maswan ponders an IRCNickSpec ;P
<marilize> ok ok ok, I'm already confused who I am now
<maswan> with A-Z and 0-9 we could even handle entrie #ubuntu..
<maswan> hm.. I wonder if I should get dressed and head to work instead of pondering very silly nick schemes
<marilize> maswan: maybe :) a P for Pants
<jdub> pants off!!!
<marilize> jdub: Mr pantless
<maswan> Hmm.. I wonder if I should write a concerned letter to cannonical, with regard to dress code
<maswan> .. or, put on pants and head to work. righ.t
* maswan waves a bit and really heads off
<jdub> maswan: best bit of working for virtual company: no pants; worst bit: no christmas party and subsequent water cooler rumours.
<lifeless> jdub: dude. We should have an xmas party
<jdub> yeah, to piss everyone else off
<jdub> i just got my amazon delivery today
<jdub> finally have a copy of UGH
<jdub> er
<jdub> UHF
<lifeless> we could have an official one, employees 2 & 3
<infinity> dholbach : Care to be my desktop guru for the day?
<jdub> should have a party to watch that
<lifeless> UHF ?
<jdub> the weird al movie
<jdub> very funny
<lifeless> cool
<lifeless> sounds good
<jdub> has lots of before-they-were-stars comedians in it
<dholbach> infinity: desktop guru? :)
<infinity> dholbach : I need someone to fix firefox-dev/libnspr-dev/libnss-dev, and I tihnk Diziet's already on VAC.
<infinity> dholbach : Two problems I can see.  firefox-dev doesn't depend on libnss-dev/libnspr-dev (oops), and even if it did, the headers are probably in the wrong location to be found.
<infinity> dholbach : See the totem build failure on i386 to see what I mean. :)
<dholbach> i uploaded devhelp had the same problems :-(
<dholbach> "..., which...
<dholbach> "
<dholbach> funnily enough it built on amd64 and ia64 :)
<lifeless> ", which i uploaded devhelp had the same problems:-(" ?
<infinity> dholbach : All about timing, I think.
<dholbach> ok... once again: "i uploaded devhelp, which had the same problems :-(" :-)
<dholbach> why don't we just chuck out mozilla* :)
<jdub> yeah!
<dholbach> or rename its libnss-dev to libnss-crackpot-dev or something
<infinity> That's not the problem.
<infinity> The problem is twofold:  The new libnss-dev installs headers ot the wrong place.
<dholbach> what is the problem you see?
<infinity> And firefox-dev has no idea how to find them.
<dholbach> oh, i didn't see the first part of the problem
<jsgotangco> hey JaneW 
* dholbach cries silently
<jsgotangco> bah! be a man!
<dholbach> real men *can* cry :-p
<infinity> dholbach : Easy enough to fix, I'm just busy.  Fix the firefox source package to install the headers to the same location they were at in breezy.. (I think we just have an extra subdirectory in the path), fix firefox-dev to depend on libsnpr-dev and libnss-dev, and make sure the ffox headers can find nspr (some symlinks might do for now)
<JaneW> hi jsgotangco 
<infinity> ie : /usr/include/firefox/nspr -> ../../mozilla/nspr or so.
<dholbach> infinity: what about the two different libnspr* packages? Does (= ${Source-Version}) just work in this case?
<infinity> dholbach : And test a build with a known-failing package before uploading. :)
<dholbach> righto
<infinity> dholbach : The ones from mozilla will be removed.  But yes, the firefox-dev -> libnss/nspr-dev dependencies should be versioned.
<dholbach> (I just thought it might not work, because of mozilla's packages having epochs and everything.)
<infinity> The firefox versions have a higher version number.
<infinity> If they didn't, katie would have rejected them.
<infinity> 2:1.firefox1.4.99+1.5rc3.dfsg-1ubuntu6 versus 2:1.7.12-1ubuntu2
<infinity> (Wow, ewww...)
<infinity> Anyhow, if you cause your desktop wiles to fix firefox, that'd be cool.  If you can't, I'll have to attack it tomorrow when I'm back on the "archive installability" warpath.
<infinity> I'm taking a break from that for a day, though, to do other work. :)
<dholbach> oh, and firefox ftbfs on everything but ia386?
<dholbach> i386
<dholbach> nice
<dholbach> that explains, why devhelp built on amd64 and ia64
<infinity> Indeed.
* dholbach gets his crack pipe and starts to work
<floam> has there been any talk of the possibility of xchat-gnome replacing xchat?
<jdub> floam: -> ubuntu-desktop (list and channel)
<floam> oh, it's not even in main, probably not
<dholbach> floam: it's is being considered
<floam> geeze, I never knew there were so many channels.
<floam> is there a channel for each list?
* dholbach expects there are more channels than lists
<floam> whoa.
<floam> heh
<floam> I guess 90% of my traffic here has been spam then, I'm sure there was something everything could have been categorized as
<lucas> hi
<maswan> jdub: well, there are replacements for xmas parties when it comes to rumours, debconf springs to mind. :)
<dholbach> infinity: nice, firefox ftbfs on the other architectures in some crazy gtkmozembed test - this gives me confidence about fixing gnome<->firefox
<sivang> fabbione: pong
<sivang> morning all
<fabbione> sivang: hi, i just saw your request to be part of Ubuntu Server
<fabbione> you might want to add at least your interests in it on your wiki and how you plan to contribute?
<fabbione> join mailing list and irc channel?
<sivang> fabbione: will do. Already helped with DB2 certification (ask Malc) , interested in the dapper+1 out of the box server confs (hopefully writing GUI wrappers for CLI stuff) and did bits of testing on pSeries
<sivang> fabbione: and givign ideas
<fabbione> sivang: ok.. just add it to the wiki. I know about the DB2 stuff
<sivang> fabbione: sure, will do, sorry for the fuss.
<fabbione> it's no problem,,
<fabbione> i am applying the same policy to everybody
<pitti> Hi mvo
<mvo> hey pitti 
<Kamion> jdub: still up, re ttf-dejavu?
<jdub> yo
<seb128> hey hey jdub :)
<Kamion> jdub: I'm happy to respin ubuntu-meta for you, but I'd rather you made the seed change
<jdub> Kamion: so you can point at me and laugh when it breaks?
<jdub> morning seb128 
<Kamion> and in general that people requesting seed changes make them themselves so that we know who to contact
<Kamion> jdub: more or less, yes
<jdub> :-)
<jdub> archive location?
<Kamion> sftp://chinstrap.ubuntu.com/home/warthogs/archives/seeds.ubuntu.com/ubuntu/seeds/dapper
<Kamion> (bzr)
<jdub> oh
<jdub> ber
<jdub> Kamion: i am waiting for bzr to do... whatever it is that it's doing without telling me.
<pitti> Kamion: here?
<pitti> Kamion: I adapted pcmciautils to the new libsysfs; my branch is at http://people.ubuntu.com/~pitti/bzr/pcmciautils-libsysfs2/
<pitti> Kamion: could you please pull/merge and test this? I don't have pcmcia, so I can't
<Kamion> pitti: will do, thanks
<pitti> Kamion: I mailed you, btw
<Treenaks> Is there much 'future breakage' expected in dapper (on the scale of udev/kernel/X/etc)?
<Kamion> pitti: so libsysfs actually removed the old API?
<pitti> Kamion: well, not completely, they just made it much more consistent and orthogonal
<pitti> unfortunately that also killed some convenience functions
<Kamion> and are the functions you used in libsysfs1, or are they new in libsysfs2?
<pitti> Kamion: sysfs_read_attribute/open_attribute were already there in 1.3
<pitti> Kamion: however, I didn't try to build with 1.3
<Kamion> pitti: ok, works fine with 1.3; I've forwarded it upstream
<pitti> cool, thanks
<Kamion> jdub: have you pushed your changes?
<pitti> ba, go autotools
* StevenK sighs. Damn it imake, things don't live in /usr/X11R6/bin anymore!
<pitti> how can I disable automatic regenration of autocrap files during package build?
<azeem> make sure the timestamps are alright so make doesn't think some of the files need updating
<pitti> hm, 'touch configure' doesn't help
* pitti touches Makefile.in, too
<pitti> I so much hate autotools for this crap
<jdub> Kamion: so i branched - how do i push?
<jdub> Kamion: branched/changed/committed
<Kamion> jdub: you'll have to merge first, since I had something I needed to commit
<Kamion> jdub: then 'bzr push', assuming reasonably current bzr (>= 0.6.2, or with bzrtools)
<jdub> bum, i have 0.6.2 and push doesn't work
<jdub> just get bzrtools?
<pitti> jdub: paramiko?
<jdub> got it
<jdub> so i did a bzr merge, do i have to commit that?
<\sh> jdub: jepp
<jdub> $ bzr push chinstrap.ubuntu.com:/home/warthogs/archives/seeds.ubuntu.com/ubuntu/seeds/dapper
<jdub> bzr: ERROR: Local branch is not a newer version of remote branch.
<ogra> did you commit ? 
<mvo> jdub: did you get the same error after you commited your local changes? or commited the merge?
<jdub> hrm
<jdub> i branched
<jdub> committed my changes
<jdub> merged
<jdub> committed those changes
<jdub> now i'm trying to push
<ogra> hmm
<jdub> no diff atm
<Kamion> jdub: what does pull say?
<zul> Kamion: did you get my email?
<Kamion> zul: yes, thanks
<Kamion> probably can't look today but should have time tomorrow
<zul> no problem
<zul> later got to get ready for work..
<doko> pitti, Kamion: when is the locales talk today?
<pitti> doko: 1500 UTC?
<doko> thanks
<jdub> Kamion: 
<jdub> $ bzr pull
<jdub> Using saved location: sftp://chinstrap.ubuntu.com/home/warthogs/archives/seeds.ubuntu.com/ubuntu/seeds/dapper
<jdub> $
<Kamion> so *should* be fine ...
<Kamion> jdub: we can give up and have me commit it if you like :-PYTHONPATH=/home/cjwatson/src/packages/tailor/darcs/tailor python2.4 ~/src/packages/tailor/darcs/tailor/tailor --configfile sync.tailor
<Kamion> er
<Kamion> like :-/
<jdub> heh
<jdub> seems like it
<Kamion> pitti: I have to be at school by 1530 for a carol service, so I can only make the start of that unfortunately
<jdub> we can point our fingers and laugh at mbp in the morning
<pitti> Kamion: an hour earlier is fine for me, too (or any time before that), but jbailey wanted to attend
<Kamion> no it's ok
<jbailey> pitti: An hour earlier is still fine for me.
<Mithrandir> 1400 UTC WFM as well
<pitti> doko, mvo, Kamion: 1400 UTC for the locales meeting?
<Kamion> sure
<doko> ok
<Kamion> thanks
<tepsipakki> kamion: is the dapper netboot-installer still b0rked or should I file bugs?
<Kamion> feel free to file bugs if you've reproduced them with the current images
<mvo> ok
<tepsipakki> kamion: well, new ones (regressions) compared to breezy
<Kamion> tepsipakki: sure, just please check existing bugs first
<tepsipakki> yeah, sure
<jbailey> seb128: Around>
<jbailey> ?
<Kamion> jdub: do you have the diff handy?
<Kamion> for the seed change
<janimo> Riddell, infinity ping
<Riddell> janimo: hi
<janimo> is ubuntu-docs supposed to use update-alternatives soon?
<janimo> and kubuntu-docs as well
<janimo> infinity said someting about that, since it is better than dpkg-divert
<Riddell> janimo: I thought \sh had already changed it to that
<janimo> seems not, inifinity said it's just symlink by hand
<janimo> and to do that ubuntu-docs has to have that too I assume
<Kamion> for update-alternatives, all packages shipping the relevant file must cooperate
<infinity> Which isn't rocket science in this case.
<infinity> So we should just Do It.
<Riddell> hmm, postinst sets a symlink while postrm unsets dpkg-divert
<infinity> He probably forgot to remove that from postrm, since both used to divert.
<Riddell> if update-alternatives is the right thing to do I can just do it later today
<infinity> Anyhow.  We should switch to alternatives for all the packages shipping that file, since you can't divergt a file more than once.
<janimo> who has to be nudged for ubuntu-docs?
<infinity> (So, installing three doc packages will blow up)
<infinity> janimo : I can do ubuntu-docs now as the example package for you guys to follow.
* infinity grabs the source.
<janimo> infinity , nice thanks
<infinity> Is there just the one file in question here right now?
<infinity> (the firefox index)
<janimo> yes index.html
<Riddell> yes
<infinity> Kay.  I'll poke both of you when ubuntu-docs is up.
<Riddell> might need to be renamed for alternatives, index.html is too generic?
<infinity> Or I could do all three.
<infinity> Which might be easier.
<slomo> doko: ping? for xine-lib... i could choose debian-compatible names but what does it help us? the debian maintainer seems to be MIA... but siretart tried to contact him directly, i'll wait some further days for an answer... maybe we can find a solution for debian and ubuntu
<infinity> The alternative name will be something more obscure, yes.
<Riddell> infinity: I need to update kubuntu-docs today anyway, so I can do it
<infinity> Alright.
<infinity> janimo : Did you want me to do xubuntu-docs for you?
<infinity> Does edubuntu also install a file there?
* infinity will have to look.
<janimo> infinity, I can do that thanks
<janimo> especially since xubuntu-docs is not uploaded yet , I have been waiting on this issue exactly
<janimo> :)
<infinity> Oh god, ubuntu-docs uses CDBS, someone shoot me.
* fabbione shoots infinity 
* ogra shoots as well
<infinity> fabbione : Thanks.
<fabbione> infinity: no problem :)
<jbailey> infinity: What's the problem?
<jsgotangco> hey all
<dholbach> yeah infinity: what's the problem?
<infinity> jbailey : 3-line rules files scare me.
<dholbach> they look pretty
<pitti> they make sense :)
<Kamion> pretty> debian/rules files are not bonsai trees
<jbailey> *lol*
<infinity> Not if you want to go "okay, in this part of the build, I want to do -- DEAR GOD, WHERE IS THAT PART OF THE BUILD?!"
<infinity> (or any part of the build, for that matter)
<infinity> jbailey : Anyhow, since you're around, you want to do this instead? :)
<janimo> isn;t the update-alt stuff outside debian/rules?
<infinity> jbailey : Make the default firefox start page an alternative?
<janimo> only in the postinst & co
<infinity> janimo : Yes, but installing the index.html to another location isn't. :)
<pitti> janimo: right
<janimo> inifinity, true :)
<Mithrandir> pitti: are you one of those insane people who think xslt makes sense too? :-)
<pitti> infinity: mod'ing debian/package.install doesn't work?
<pitti> Mithrandir: yes, I am :)
<Kamion> pitti: dh_install can't change file names
<Kamion> it can only put them in different directories
<pitti> ah, I read that as 'different location', i. e. different dir
<janimo> rename it to index-ubuntu.html
<janimo> and the other do it similarly?
<infinity> pitti : No, different name, so we have ubuntu-index.html, xubuntu-index.html, etc.
<pitti> janimo: why not rename it in the source package?
<infinity> (Or whatever)
<jbailey> infinity: I'd rather not do it now, but perhas this afternoon.
* ogra raises had for etc
<ogra> *hand
<janimo> pitti, yes in source package I mean
<pitti> so, what's the problem?
<infinity> pitti : Renaming it in the source is fine, except in the case of ubuntu-docs, which is an SVN checkout of a repo I don't have write access to.
* infinity shrugs.
<pitti> anyway, sorry for the noise, you'll figure it out :)
<janimo> change firefox to point to another new index file you create ;)
* janimo ducks
<jbailey> infinity: I have write access, what do you want changed? =)
<ogra> janimo, oh, yeah, lets make xubuntu-firefox and edubuntu-firefox packages instead, thats way easier *g*
<janimo> ogra, my thought exactly ;)
<infinity> jbailey : Rename the default firefox start page from index.html to ubuntu-index.html or index-ubuntu.html, or something.
<Riddell> infinity: I can commit changes back to the svn
<infinity> Err, wait.  It's not index.html anyway, is it?
<infinity> At least, not in the source. :)
<infinity> Riddell : What's the file being alternatived here? :)
<Riddell>  /usr/share/ubuntu-artwork/home/index.html
<janimo> I think it is index.html
<ogra> yup
<jbailey> infinity: Are you working in a branch or on the trunk?
<janimo> ogra, you divert it in edubuntu as well?
<infinity> Oh, it's in ubuntu-artwork, not ubuntu-docs.
<janimo> in breezy too?
* infinity gets the right source package.
<ogra> janimo, nope, i did nasty cp's
<janimo> infinity the package _is_ ubuntu docs I think
<janimo> it;'s under the artwork dir for some reason
<infinity> Oh, so it is.
<infinity> jbailey : Neither, just in the source package for ubuntu-docs.  Err, which is probably being generated from some other format.
<infinity> Why am I working at 12:34am?
<infinity> No, really, why? :)
<Pygi> I think you need to answer to that one by yourself ;)
<siretart> slomo: re: sigge. I didnt manage to write the email yet, will do that later today.
<janimo> infinity, what are yoy talking about it's 15:35 :)
<Pygi> no, it's 14:35 ;)
<jbailey> dholbach: ping?
<slomo> siretart: oh ok, sorry :/
<dholbach> jbailey: pong
<jbailey> dholbach: Do you have an ubuntu-docs checkout of the trunk handy?
<dholbach> jbailey: no, not ready
<jbailey> dholbach: 'kay, no worries.
<doko> slomo: it's not necessary, just a proposal
<Kamion> Mithrandir: could you push your casper branch?
<Kamion> or have you moved it?
<Mithrandir> Kamion: there's a trunk now which is the trunk
<Kamion> ah, you've moved it, never mind
<slomo> doko: ok, but we're searching for a generic solution anyway... maybe by taking over maintainership in debian... we'll see...
<Kamion> you should probably s/unstable/dapper/ in the 1.19 changelog in the trunk
<infinity> Picky, picky.
<Mithrandir> done
* mvo goes for lunch
<pitti> mvo: waaait
<pitti> mvo: locales meeting in 5 minutes?
<Pygi> anyone here that have the "power" to make ubuntu bot come to #ubuntu-hr? ;)
<ogra> Pygi, speak to smurf, he's te master of the LoCoBot
<ogra> *the
<Pygi> k, thx
<ptlo> Pygi: why would you want the bot on #ubuntu-hr?
* Pygi at lunch
<pitti> Kamion, mvo, seb128, jbailey, doko, Mithrandir: shall we start? in #u-m?
<doko> yes
<mvo> pitti: ?
<infinity> ogra : ping.
<ogra> infinity, pong
<infinity> ogra : Not to be a dick, but how can you "fix orig.tar.gz differences with Debian" when you can't upload a new upstream version (hence, no new orig)?
<ogra> infinity, i used the debian source ... but apparently they use kino-0.8.0 as source dir, i packaged the orig.tar.gz with a kino-0.80 source dir... so while the contents are identical, the md5sum differs :/
<infinity> ogra : Yes, but you can't fix that in an upload is what I'm saying.
<infinity> ogra : Cause you can't re-upload a new orig.tar.gz.
<infinity> ogra : (overwriting files in the archive isn't allowed, for reasons that would be obvious if you thought for a bit)
<ogra> so what should i write in such a case in the changelog ?
<infinity> ogra : Erm.  Well, what did the upload change?
<ogra> see the rejected 1ubuntu1 ...
<infinity> ogra : The changelog made it sound like you replaced the orig.tar.gz with another.  Which is impossible, so obviously you did something else.
<ogra> i packaged 0.80 ahead of debian ... 
<infinity> ogra : No one sees rejects except for you and the ftpmaster (of which I'm not one)
<ogra> now they have 0.80 and i wanted to merge, but had a md5 mistmatch for the orig.tar.gz, since we use different dir names ..
* Pygi is back from lunch...
<infinity> Yes...
<ogra> (inside the orig.tar.gz they use 0.8.0 and i use 0.80)
<infinity> Yes, I caught that.
<ogra> so i took their diff and used our orig.tar.gz, since the contents are identical ...
<infinity> Ahh.
<infinity> If the changelog said that, I'd not be talking to you right now. :)
<ogra> thats what i mean with this sentence ... my last upload of he plain debian package with ripped out avcodec dep was rejected
<infinity> "Apply the Debian diff for 0.80-1 to our orig.tar.gz.  Other than the differeing orig tarballs, the packages are now identical"
<seb128> pitti: start what?
<pitti> seb128: oh, were you interested in the locales discussion? I thought you were
<pitti> seb128: #u-m
<infinity> ogra : Or sometihng along those lines.  Anyhow.  Carry on.  I was giving you crap for trying to do something you weren't trying to do, rather tha ngiving you crap for a misleading changelog entry. :)
<ogra> infinity, ok, i thught the entry would be sufficient ... will do better next time i'm caught by such a case ;)
<zul> heylo
<seb128> pitti: I am but I didn't read about this meeting
<seb128> pitti: I was out for some shopping, just went back
<seb128> pitti: is there an agenda/purpose of the meeting somewhere? just to catch up :)
<pitti> seb128: just look in the last 20 mins of Fabio's log
<pitti> seb128: we'll probably centralize locales again
<seb128> k
<jsgotangco> hmm who maintains dbus?
<seb128> daniels/pitti/mvo
<jsgotangco> right thanks seb128 
<seb128> np
<pitti> mvo fights with 0.60 atm
<seb128> jbailey: could you fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260173 ?
<jsgotangco> ahhh i was just talking to J5 a few minutes ago and reading over their stuff
<seb128> about what?
<jsgotangco> they're cleaning up documentation at the moment
<seb128> yeah, I've read that
<jbailey> seb128: Can you just NMU it please?  The fix looks correct.
<seb128> jbailey: sure, will do
<seb128> thanks
<jbailey> seb128: Thanks.
<maswan> btw, power outages suck.
<mvo> jsgotangco: I'm on dbus 0.60 atm. it is blocked by mono currently
<jsgotangco> mvo, blocked?
<mvo> jsgotangco: fails to build from source right now
<Riddell> seb128: what's the plan for applications.menu in dapper?
<seb128> Riddell: no plan, why?
<Riddell> seb128: I see that debian has moved it to gnome-applications.menu but I don't think ubuntu hsas
<Riddell> has
<doko> seb128: did you talk with Diziet about the firefox-dev / libnspr-dev split / move to /usr/include/mozilla?
<mvo> doko: I think dholbach is working on this
<seb128> doko: nop, dholbach is on it
<doko> seb128, dholbach: so the proper fix should be to remove the firefox-n*.pc files
<dholbach> doko: firefox-n*.pc files? why that?
<doko> dholbach: because they are lying
<dholbach> doko: i'm just making the last upload build on all archs again and place symlinks to includes - his last upload (which only built on i386) changed stuff in the .pc files - he's not removing them
<dholbach> doko: devhelp and totem build nicely again afterwards - but i leave the proper fix to Ian - i'm no firefox expert
<doko> the problem is: when you install firefox-dev, the firefox-n*.pc point to libs and headers which do no exist. we already had this dicussion for breezy, but apparently gnome so broken that seb128 didn't want a fix ...
<dholbach> the split happened in said last upload
<seb128> GNOME is not broken
<seb128> and they don't point to non existant file
<seb128> that's just a fud
<doko> seb128: please recall our last discussion. it's not fud. I'll wait on dholbach's fixed packages however
<seb128> I recall the discussion
<seb128> you were the only one standing on your opinion
* Kamion disables the CD timeout again just for the install CD
<seb128> pitti, me (dunno who else was discussing) was agreeing it was not perfect but not that buggy neither
<doko> seb128: dude, I gave you a concrete example what is broken. your *only* argument to that was "but the only way gnome works"
<seb128> we didn't agree previous time, I don't intend to speak about it again for hours, the issue was to have 2 version of libnspr that's all
<seb128> there is nothing broken
<doko> seb128: a call a .pc file pointing to nonexisting file broken
<doko> s/file/files/
<seb128> doko: there is no such .pc file
<doko> seb128: what do you want to bet on?
<seb128> doko: with the current firefox split done wrong? nothing
<doko> seb128: you're still wrong, and don't understand, why you are ignorant on that.
<doko> /usr/lib/pkgconfig/firefox-nspr.pc
<doko> Cflags: -I/usr/include/mozilla-firefox/nspr
<seb128> right I'm stupid
<seb128> you should stop speaking to me
<doko> that directory doesn't exist
<seb128> $ ls /usr/include/mozilla-firefox | wc -l
<seb128> 340
<seb128> oh
<seb128> that's the split
<doko> no, /usr/include/mozilla-firefox/nspr
<doko> that was before and after the split
<seb128> $ dpkg -L firefox-dev | grep nspr
<seb128> /usr/lib/pkgconfig/firefox-nspr.pc
<seb128> /usr/include/mozilla-firefox/nspr
<seb128> /usr/include/mozilla-firefox/nspr/nspr.h
<seb128> ...
<seb128> $ ls /usr/include/mozilla-firefox/nspr | wc -l
<seb128> 52
<seb128> 
<seb128> that's before the split
<seb128> right
<seb128> what the matter with you?
<doko> sorry, apparently that's the empty /usr/lib/pkgconfig/firefox-nss.pc (before the split)
<doko> seb128: ^^^
<seb128> that's bugged
<seb128> but epiphany-browser doesn't use nss.pc
<seb128> it uses nspr.pc
<dholbach> i uploaded my dirty fix now
<dholbach> totem and devhelp are happy now and i placed symlinks, which is not a proper fix
<dholbach> i hope diziet will bring a new world order and peace next year :)
<doko> dholbach: symlinks to directories?
<dholbach> yes
<seb128> doko: so firefix is bugged on that, I still fail to see why GNOME apps are bugged?
<seb128> doko: firefox-dev should change its .pc or ship the header for nss too
<doko> seb128: I don't know, but apparently you did revert my last change to firefox, so you should know
<doko> dholbach: so you manually remove the directories in the preinst?
<dholbach> no
<dholbach> what should i remove?
<seb128> doko: you changed the nspr stuff which is not bugged IIRC
<doko> dpkg doesn't replace symlinks with directories and vice versa.
<doko> so you end up with an empty directory.
<doko> on upgrade
<dholbach> diziet's last upload installed stuff to /usr/include/mozilla which should have been in /usr/include/mozilla-firefox
<dholbach> the nspr/ headers
<doko> dholbach: correct, so /usr/include/mozilla/nspr will be an empty directory after an upgrade
<Kamion> conversely, if you've installed a symlink and later we decide that it should become a directory, making the world right will involve nasty preinst trickery
<Kamion> s/will/will also/
<dholbach> that's a problem then :(
<Kamion> it occurred to me earlier but I assumed you knew; sorry, should've mentioned it then
<dholbach> in a conversation, adam and i agreed on doing this quick fix to make stuff build again
<doko> if [-d /usr/include/mozilla/nspr ]  && [ ! -h /usr/include/mozilla/nspr ] ; then
<doko>   rm -rf /usr/include/mozilla/nspr
<doko>   ln -s ../mozilla-firefox/nspr /usr/include/mozilla/nspr
<doko> fi
<doko> something like that should work in the preinst
<dholbach> i'll write Ian a mail and tell him, what I did.
<doko> dholbach: and firefox-dev should depend on libnss-dev and libnspr-dev
<dholbach> doko: it does now
<doko> dholbach: he's on vacation, isnt't he?
<dholbach> thanks for the heads-up
<dholbach> doko: yes, but i'm not happy to meddle with firefox, so he should know best, what and how to do it. as i said: i wanted stuff to build again - the new world order is his job. :-)
<seb128> dholbach: he said to revert to the previous versionned if that was too messed no?
<dholbach> seb128: dunno, did he?
<seb128> "If there is a problem and I'm gone, please feel free to revert my
<seb128> change by making a firefox 1.4.99+1.5rc3.dfsg-1ubuntu6 which is
<seb128> identical to 1.4.99+1.5rc3.dfsg-1ubuntu4.  I have a copy of my diffs,
<seb128> and there are no other changes in ubuntu5."
<seb128> "	Re: firefox/mozilla/libnspr packaging change" mail on the list
<dholbach> let's see how this works out, we can still revert then
<seb128> better to fix it if you can though
<mdke_> has anyone decided on a time for the CC meeting tomorrow?
<mdke_> Kamion, elmo, mako? ^^
<Kamion> mdke_: no, not yet
<mdke_> ok thanks
<Kamion> sorry, have had a stinking cold all day and not really feeling up to chasing people down
<mdke_> fair enough, hope you shake it off soon
<ogra> Kamion, probably something to hand over to the CC secretary ;)
<mdke_> there's a secretary?
<mdke_> must be seveas
<ogra> mdke_, just joking, but i thought of Seveas
<mdke_> :)
<slomo_> jbailey: ping?
<jbailey> slomo_: Pong
<slomo_> jbailey: just a short question or better two ;) the ppc buildds are ppc64 afaik... is it possible that something breaks (i.e. segfaults) on ppc64 running as 32bit binary but not on a normal ppc? and mvo told me you have access to a ppc64, could you test something for me?
<jbailey> slomo_: It's possible, yes.  Whenever you have a kernel emulating a different userspace, it has to have a set of thunks to make the non-native space work.  There's always room for bugs in there.
<jbailey> And depending on what it is that you want tested, yes I can.
<slomo_> jbailey: can you compile mono (as in 1.1.11-0ubuntuX) in a dapper chroot there and report me if it works fine or segfaults somewhere? it segfaults on the buildds but works on my ppc :/
<jbailey> seb128: Around?
<seb128> jbailey: pong
<jbailey> Silly question for you. =) Recent releases of Aisleriot hang on my box when I try to switch games.  Is this a general problem for Aisleriot?  I don't see it in bugzilla, and if it's ppc-specific, I'll debug it later.
<mpt> It's a conspiracy to get you back to work
<seb128> I've not noticed any hang but I don't play a lot to card games, do you reproduce it easily? Afaik we got no bug about it, do you have a backtrace of the hang?
<dholbach> jbailey: does it say something about sgid in the terminal?
<jbailey> I haven't tried debugging it at all yet, just a sec.
<jbailey> I usually try to ask you guys first when it's not in bugzilla, because sometimes you already know about it, or it's a ppc-only isssue, in which case I should just fix it. =)
<jbailey> *** glibc detected *** free(): invalid pointer: 0x1032c660 ***
<dholbach> jbailey: no, didnt hear of that one yet
<jbailey> 'kay, I'll hunt it down then.
* jbailey 's ongoing quest to make sure games are usable for his wife when Dapper releases. =)
<jbailey> dholbach: I get the sgid bug on mahjongg, but I think I saw that bug posted already.
<mdke> jbailey, course, course. you don't use the games...
<jbailey> mdke: Right.  Only as needed for testing.
<dholbach> jbailey: yeah, quite a lot, upstream is figuring it out and pitti denied me to make gnome-games' /var/games/* files world-writable in the meantime :)
<jbailey> =)
* sivang -> re
<jbailey> dholbach: Sure.  You just need to setup FUSE to watch for writes to the world-writable directory and only allow them if they validate ;)
<dholbach> jbailey: don't give upstream new ideas
<jbailey> dholbach: Yes, dear.
<dholbach> :)
<sivang> mpt: lol
<jbailey> Although in my defence, it's not my fault.  It's what happens when you spend years working on the Hurd.
<sivang> jbailey: what got you working on it in the first place?
<mdke> his wife wanted to use it
<jbailey> sivang: My wife occasionally uses my machine.  It has a slightly nicer screen.
<mdke> honey... can you get hurd working?
<jbailey> Although the X hangs have discouraged her from using my machine for nethack.
<jbailey> mdke: It's on my TODO list.  It's just under "die".
<mdke> lol
<mdke> relying on the afterlife eh
<jbailey> mdke: It needs that grade of help right now. =)
<sivang> jbailey: I asked aobut the HUrd :-=)
<jbailey> sivang: Oh, LOL.
<sivang> heheh, yeah that what I thought when I saw your answer :)
<jbailey> Mmm.  It was 1996 or so, and the Hurd actually had more active development on it than Linux did at the time.
<sivang> nothing related to the promise of microkenrnel architectures?
<jbailey> No, althought that's certainly why I stayed interested in it.
<sivang> (although, reading Robert Love's book - LInux claims to provide the same niceities of a microkenrel based arch, using a monolithic one)
<jbailey> sivang: It doesn't, but that's fine.
<jbailey> sivang: My theory is that Linux is doing the right thing.  It's slowly evolving until it turns into what the Hurd wanted to be, but tested by experience.
<sivang> jbailey: sorry, not "Linux claims" but at least that's what RL says in the book.
<sivang> jbailey: ah
<jbailey> sivang: As recently as today, I managed to get a process that kill -9 wouldn't take out.  It's a pretty strong hint that we still have user applications that can permanently tie up precious kernel resources.
<sivang> jbailey: wow
<sivang> I did had acouple of hangups of dapper lately
<sivang> and couldn't kill neither X or reboot, but that's probably not related..
<jbailey> Is swf-player generally the best flash player?
<jbailey> I wonder if we should have it in main and install it by default.
* jbailey curses flash-dependant websites.
<thesaltydog> is the "system tools" menu going to be purged in dapper?
<floam> hasn't it already?
<thesaltydog> dunno, I still have to install it..
<thesaltydog> didn't upgrade yet
<Pygi> welcome crimsun
<mdke> thesaltydog, yeah it has gone
<crimsun> hi Pygi 
<thesaltydog> ...
<Pygi> what's up? ;)
<sivang> hey Pygi 
<Pygi> hey sivang
<Pygi> first Ubuntu school at Croatia  -- launch -- 1 month of 2006 (I hope ;) )
<Pygi> hehe ;)
<sivang> hmm
<sivang> Errors were encountered while processing:
<sivang>  /var/cache/apt/archives/libdar3c2a_2.2.4-2_i386.deb
<sivang> E: Sub-process /usr/bin/dpkg returned an error code (1)
<exarkun> Is Python 2.2 going to be included in dapper?
<mdke> it's there now
<Kamion> not in main; it hasn't been in main since warty
<Kamion> I imagine it'll stick around in universe until Debian removes it
<lucas> is the source code of the scripts generating http://people.ubuntu.com/~scott/ongoing-merge/ available somewhere ?
<jbailey> slomo_: I also get a segfault.
<slomo_> jbailey: nice... at least it's possible now to reproduce it on something else than the buildds... can you retest on normal ppc? maybe it's only my ibook beeing confused...
<jbailey> slomo_: In tramp.c I get a whole lot of tramp.c:312: warning: pointer targets in assignment differ in signedness
<jbailey> slomo_: Actually.  Can you email me your .build log?
<jbailey> I cn quickly compare it.
<slomo_> jbailey: sure... just need to rebuild it as i haven't saved it
<jbailey> I'm also running out pretty soon, so to look at it more, I'll need to do so in a couple days.
<jbailey> I'm a bit behind on a couple other tasks.
<zul> slacker..
<Loiosh> Heh
<slomo_> jbailey: np... i'll send it to you via mail... just look at it when you have some time :) we really need to get this running again ;)
<slomo_> jbailey: but it would also help when you could run it somehow in gdb for getting a better backtrace... upstream asks for it :/
<jbailey> 'kay.  I'll need to work with someone for that.  I've never run a mono app before.
<dholbach> have a nice evening, i'm off :)
<slomo_> jbailey: hmm, can you give me ssh access there? no root access needed... only the b-d need to be installed
<jbailey> slomo_: No, sorry.
<jbailey> slomo_: I haven't made any real effort to secure this machine beyond the basics.
* jbailey really runs off now.
<slomo_> jbailey: ok, np :) have fun
<janimo> Kamion, do derivatives need to provide gfxboot themes in separate packages as with usplash?
<Kamion> janimo: no
<Kamion> gfxboot-theme-ubuntu is designed to handle derivatives with the only branding changes required being in debian-cd
<Treenaks> Kamion: do you have any clue on "my" bug yet?
<Kamion> and all that does is stick a splash.pcx image in /isolinux/ on the CD
<Kamion> Treenaks: I think I already said I'd "fix" it by killing the timeout clock
<Treenaks> Kamion: oh ok :)
<janimo> Kamion, great
<Kamion> but I tried to do that this morning and it was less trivial than you might imagine; I'll give it another go later
<Treenaks> Kamion: I saw a few uploads like that today -- does that mean it will be fixed in tomorrow's daily?
<Kamion> Treenaks: no
<Treenaks> hmm ok :)
<Kamion> as I say, I tried, but the initial approach I took produced a lot of screen flicker as the timeout fired
<Kamion> I'll try a slightly different approach next time which updates less of the screen each time
<Treenaks> Kamion: ok
<Treenaks> (I really want to test the new ati driver ... but I don't want to hose my breezy install :))
<Kamion> still don't know why it really occurs, which disturbs me slightly, but hey
<Loiosh> ati driver? fglrx?
<Kamion> Treenaks: hold down shift during boot and you can choose to bypass gfxboot
<Treenaks> Kamion: if I can do anything more to debug.. I've seen  the display switch from 1 error to another
<Treenaks> Loiosh: no, ati
<Treenaks> Loiosh: fglrx already works. ati never has on this machine
<Loiosh> Ahhh
<Kamion> unfortunately I think it's going to be too tedious - if I actually had the laptop in front of me, I might be able to do more, but it'd be really hard work to teleoperate somebody else
<Loiosh> I had to use fgl becaue my x600 wasn't supported yet in ati.
<Treenaks> Loiosh: X700 here
<Loiosh> So they have X--- support in ati now? =)
<Treenaks> Kamion: hm ok.. would a shot of the other error screen help?
* Loiosh wags!
<Treenaks> Kamion: (different numbers in the trace box)
<Kamion> Treenaks: sure, would do no harm I guess
<Kamion> when did it occur?
<Treenaks> Kamion: uh, that appeared automatically
<Treenaks> Kamion: another one pops up when pressing a key
<Treenaks> Kamion: brb
<Kamion> you mean pressing a key at the trace box?
<Kamion> Treenaks: come back :)
<Treenaks> Kamion: ok :)
<Kamion> Treenaks: if you press a key at the trace box, it single-steps
<Kamion> so no, the next one wouldn't be useful
<Treenaks> Kamion: If I boot from the CD, and wait for a bit, the trace box pops up; if I press a key before the trace box pops up, I get another error
<Treenaks> Kamion: hm if it single-steps
<Treenaks> I might have sent you a wrong screenshot... sorry
<Treenaks> Kamion: so I'm going to check
<Kamion> ok, thanks
<Kamion> yes, I'd need the first trace that appears
* sivang reboots to test dist-upgraded system
<Treenaks> Kamion: OK, I can make the timer tick... slowly.. if I single-step slowly
<Treenaks> Kamion: but if I single-step faster than the timer would tick (once every second?), I get the 'Booting from harddisk' + error message
<Treenaks> Kamion: I have a few images, uploading now
<janimo> lamount, around?
<janimo> any idea why xubuntu-default-settings is given back (both 386 and amd64)
<ogra> the i386 buildd had an outage yesterday ...dunno about amd64, but it might be caused by it ...
<janimo> ogra, thanks I'll wait till tomorrow then
<Kamion> Treenaks: I'm not really bothered about breakage after the first backtrace; by that point the stack state is broken and it's a complete waste of time trying to debug anything that happens later
<Treenaks> Kamion: ok
<Treenaks> Kamion: I'll just attach the first trace
<Kamion> thanks
<Treenaks> Kamion: http://bugzilla.ubuntu.com/attachment.cgi?id=5413
<ogra> wheee
<ogra> firefox ftbfs on amd64 ... 
<Treenaks> ogra: ouch
<ogra> yup
* Loiosh wonders what that means.
<Treenaks> ogra: but, I'm an amd64/dapper/pentium-d tester now ;)
<Treenaks> ogra: (I run it on my l33t dell box at work)
<ogra> and it looks evil ...
<Loiosh> Ahh
<Loiosh> Fails to build from source.
* Loiosh pets google.
<ogra> ldd segfaulting sounds not nice ...
<Treenaks> ogra: ouch
<Kamion> Treenaks: righto, same place, same IP, so I'll stay with my current place
<Kamion> er, current plan
<Kamion> thanks for rechecking
<Treenaks> Kamion: I have an isolinux error too
<Treenaks> in some l33t font :)
<Kamion> did you buy this laptop specially with a "hi, I have a broken BIOS" label on it? :P
<Loiosh> Heheheh
<Treenaks> Kamion: no, it just arrived in a box one day, after mailing with claire for a bit ;)
<ogra> so you asked claire for the most broken one ? 
<Treenaks> ogra: no... that was \sh
<ogra> heh
<ogra> but his is cool :)
<ogra> yours seems just broken ...
<Treenaks> ogra: mine has a leet screen res.
<jdong> so mako goes to MIT right?
<mvo> he already is AFAIK
<jdong> cool....
* jdong can't wait to meet him :)
<jdong> are there any other devs in the area?
<exarkun> mako's hostmask is hampshire.edu, though
<exarkun> hampshire's in western MA
<jdong> hmm
<jdong> I vaguely recall someone telling me that mako's in MIT
<Mithrandir> jdong: he is.
* jdong already is reading up on Athena documentation :)
<daniels> mako's at the mit media lab
<lunitik> I don't suppose anyone is working on getting gaim 2.0b1 uploaded to dapper?  :D
<jdong> talk about impatience :)
<jdong> gaim 2.0 ain't spectacular....
<jordi> jdong: is it out?
<jdong> jordi: I meant the beta
<seb128> lunitik: uploading something that will probably destroy users' config? no 
<seb128> we have enough bugs without that
<jdong> seb128: gaim 2 beta does have its way with eating profiles for breakfast
<lunitik> seb128: I just had it installed, but apparently I'm too dumb to get SSL (and thus MSN) working  :(
<seb128> that's what you get by beeing too impatient
<lunitik> seb128: It maintained a lot of settings, although some did go bye bye...
<seb128> gaim 1.5 works fine enough to use it a few extra days no?
<lunitik> seb128: I like playing with new things... its a disease
<jdong> lunitik: that's why you compile it yourself :)
<lunitik> seb128: I guess... gaim 2.0 brings a lot of niceties, and cleans things up a lot though  :(
<jordi> that gaim 2.0 screenshot looks exactly the same to me, a non-user
<lunitik> jdong: I just did... see above
<seb128> gaim 2.0 will be packaged no doubt
<seb128> but when upstream write on their website it may destroy users config
<jdong> jordi: no, no, everything takes up MUCH more room than before, and there's a smooth scroll effect for new messages :)
<seb128> no thanks, they can keep it
<jordi> jdong: *oooooooooooh*
<jdong> there's also a degree of instability, ESPECIALLY with the plugins (even bundled ones)
* jdong kopete user :)
<lunitik> jordi: prefs, contact list at the bottem, menu system, little features like doodle and stealth in yahoo (stealth is rather nice), nudges in MSN
<lunitik> jordi: things that I get bitched at a lot for not being able to do  :'(
<seb128> I don't understand half of the feature you are mentionning
<lunitik> jordi: jdong: http://gaim.sourceforge.net/ChangeLog  <-- hardly minor things... hence 2.0
<jordi> seb128: same here :P
<seb128> :)
<jdong> lunitik: not a convincing or significant list
<jdong> and I still find it insulting how they're removing more and more options
<lunitik> seb128: doodle allows you to draw things for the person you're chatting to, stealth allows you to appear offline to some people, nudge and buzz allow you to get the contacts attention....
<lunitik> jdong: blame the HIG imo... although most I don't play with...
<lunitik> In fact, most things I configure, they are making the default action...
<seb128> drawing can be nice
<lunitik> So it kinda works out  :P
<lunitik> seb128: it can be fun if you're bored  :)
<seb128> stealth seems to be the equivalent of ICQ invisible list
<lunitik> seb128: perhaps... I don't mess with ICQ much... its per contact though, not as per a list...
<seb128> getting attention ... I've already an effect on the window list
<seb128> ICQ stuff is by contact
<lunitik> seb128: not your attention... their attention  ;)
<seb128> you can have a list of people for who you are offline all the time, online all the time, etc
<lunitik> seb128: on the actual clients, it shakes the screen  ;)
<seb128> the attention of somebody who receive the message?
<seb128> or that's just an action?
<lunitik> Luckily, all we get is "you have been nudged"
<lunitik> seb128: the attention of the other person...
<seb128> like if jordi wants to annoy me he can do annoy stuff every 5s?
<seb128> annoying stuff
<jdub> Kamion: + * ttf-dejavu
<ogra> quicker with a script ;)
<lunitik> seb128: well, no... he has to hit "nudge" contact... so its as fast as he wants
<seb128> right
<seb128> that's like the worst idea ever
<lunitik> seb128: you'd be surprised how popular it is...
<seb128> somebody from your list can poke you as much as he wants so?
<seb128> I don't doubt of that
<lunitik> seb128: yup
<seb128> I'm just not that kind of user :p
<seb128> I write with full words most of the time too
<seb128> what I expect from an IM is to send/receive messages and to not make fuss about them while I'm working
<lunitik> seb128: haha... me too most of the time... but still... having a full like 10 minute discussion about why I can't do it isn't pleasant either  :(
<seb128> just the effect on the windows list is fine
<jordi> cinema time
<jordi> laters
<seb128> jordi: what movie?
<ogra> jordi, have fun :)
<Loiosh> King Kong!!
<jordi> Match Point, in English.
<jordi> no way.
<mdke> the penguin film!
* Loiosh stomps around.
<jordi> Woody Allen is a lot more interesting. :)
<mdke> it's all about penguins
<jordi> mdke: I hate that linux icon :)
<ogra> jordi, cool, match point !
<mdke> bah
<jordi> ogra: is it?
<ogra> dunno, i saw some previews on TV
<jordi> oh
<jordi> gotta go
<ogra> enjoy
<mdke> Kamion, still around?
<crispin> daniels: ping ?
<daniels> crispin: ?
<crispin> daniels: could you just have a quick look at bug 20414 and see if you need anymore info from gdb ?
<crispin> (this is an X crash without the -nolistentcp option)
<sivang> night all
<daniels> aha
<daniels> crispin: yeah, that's nailed it
<daniels> crispin: cheers :)
<crispin> np, I realised my original report was pretty useless :-)
<daniels> heh
#ubuntu-devel 2005-12-25
<ajreznicek_> hello
<Pygi> hi ajreznicek_
<Pygi> he left :/
<newlinuxd00d> A dapper update broke lvm and I have / on lvm. My system is unbootable. How can I put the stuff to load and activate a volumegroup in the initrd?
<benplaut> is the following patch in dapper's xorg?
<benplaut> http://www.mail-archive.com/devel@xfree86.org/msg03333.html
<TerminX> can anyone reproduce this?  if you resize a window to the smallest possible size horizontally on dapper, the app bites the dust with an X error
<zul> nope
<TerminX> I get "BadAlloc (insufficient resources for operation)", can reproduce with multiple applications
<infinity> Any specific app doing this to you?
<TerminX> Firefox, Gaim...
<infinity> Nope.  I've got a tiny pinprick of a firefox window now, but no crash.
<infinity> I'd recommend running it in gdb and check where it's dying.
<TerminX> I tried, but it was an X Window System Error, so I can't get a backtrace or anything because it's not a real "crash" I guess.
<daniels> TerminX: run it with --sync and attach to gdb to see where it's tanking
<TerminX> daniels: I ran it with --sync and attached gdb to it, but I'm not really sure what you want me to do after it bites it
<daniels> TerminX: get a backtrace, maybe?
<daniels> whatever you think would be useful
<TerminX> daniels: I, uh, can't get it to do it with gdb attached.
<TerminX> in fact, now it won't do it at all, even though it did it 5 minutes ago, repeatedly
<TerminX> I can paste you the useless X Window System errors it dumped into the terminal
<jdub> BenC: ping
<BenC> jdub: pong
<Jacobo221> Hi. i've been told ubuntu is working on some new init scripts. i'm looking through the wiki but i can see nothing related. can someone point me to the right direction? i want to read about it
<jdub> BenC: is the UP/SMP switching stuff in 2.6.15, or a patch we've pulled in?
<BenC> it's a patch I partly wrote
<jdub> ahar, cool
<jdub> got any descriptive text for people interested in the implementatino?
<BenC> found the initial patch on l-k archive, against 2.4
<daniels> TerminX: no thanks; they're, as you said, useless
<daniels> TerminX: the only thing it tells you is that somewhere along the line, the X server refused to allocate something the client requested
<daniels> this could be because it's too big, or because it's 0x0
<BenC> jdub: basically it just converts lock's to nops at boot
<BenC> saves a few cycles for UP machines
<Jacobo221> or maybe i'm wrong and there is not such "generation boot scripts" project going on?
<jdub> Jacobo221: nothing really directly related to init scripts
<jdub> Jacobo221: most of it is concentrating on hardware activation
<jdub> BenC: do you regard this as 'in early testing' or 'ready for dapper'?
<Jacobo221> jdub: is there any url where I can read about it? or any REDME or..?
<BenC> jdub: early stages
<jdub> Jacobo221: i forget what the spec is named, but you can look through the ubuntu/ubz specs on launchpad, or search the wiki to find it
<jdub> BenC: cool
<Jacobo221> jdub: i am working on a wrapper script for an application which should start at boot time, for debian/ubuntu/lsb-compliant distros and i've been told this might be of my interest. i'd like it to be compatible with any future ubuntu generation scripts, of course
<jdub> BenC: it is a funky feature
<BenC> jdub: I still need to get it %100
<BenC> the module lock/nop is perfect, so I don't have it enabled right now
<BenC> isn't perfect
<Jacobo221> jdub: ok, i'll do my best ;) thanks for yor time and help
<desrt> daniels; is fglrx known to be broken right now or is a bug report appropriate?
<daniels> er, could you be less specific?
<desrt> daniels; specifically, the X server seems to think that direct rendering is go but glxinfo disagrees (possibly libGL problem?)
<daniels> oh yeah, the paths still haven't been updated
<daniels> i think there's a bug already open on this
<daniels> infinity mostly handles l-r-m these days
<desrt> excellent.  thanks.
<daniels> np
<psusi> anyone know if the newer xserver-xorg-driver-ati driver in dapper is supposed to support newer radeon cards like the 9800 pro?  the messages when the driver is loaded indicates that it does, only
<psusi> it later says it is loading the r300 firmware... only the 9800 pro is based on the r350
<daniels> psusi: ... what makes you ask?
<daniels> psusi: noting that I've been running it on my x850 xt pe for around a year now
<daniels> well, probably more like ten months, but eh
<psusi> well, the new dapper version has a problem for me on my 9800 pro with totem and gxzine's overlays showing thorugh any black areas of a window placed on top... like transparancy
<psusi> I filed a bug last week
<psusi> but I just noticed in my xserver logs it is loading the R300 firmware... which seems wrong
<daniels> yeah, that's known upstream
<daniels> don't worry about the firmware
<psusi> also, a lot of times when I try to restart the x server, it hangs up HARD... caps lock doesn't even work... but the magic sysrq keys do
<psusi> and sometimes the card starts making a high pitch noise
<infinity> desrt : DRI is broken because of a hardcoded path in the libGL binary.  Fixing in the next upload.
<psusi> I'd say right around 20 khz
<daniels> infinity: don't sed the binary.  ati don't like that.
<infinity> daniels : My only other option is symlinks in /usr/X11r^, which I'd really like to go away.
<infinity> X11R6, too.  Yay, shift keys.
<daniels> infinity: i would love it to go away also
<psusi> daniels, is the xorg driver going to some day support 3d accel? ;)
<infinity> Meh.  I can do symlinks now, if it's more policially correct, and hope for an Xorg7.0 build before release.
* psusi doesn't want to run ATI's pain in the ass and proprietary driver
<daniels> psusi: what do you mean, 'some day'?
<psusi> daniels, it says it's 2d only
<psusi> and it seems to be...
<Mithrandir> daniels: any chance you could make nb and nn alternatives for the no keymap in xserver-xorg.config?  I think dk as an alternative for da (or the other way around) might be useful too.
<daniels> daniels@ephemera:~/canonical/xorg/lib/libx11/libX11-1.0.0% dpkg -L libgl1-mesa-dri | grep r300
<daniels> /usr/lib/dri/r300_dri.so
<psusi> daniels, and iirc, it mentions an experimental mesa driver you can pull the source for and build with 3d support
<daniels> Mithrandir: as in, language -> keymap?
<daniels> psusi: it's not experimental anymore
<Mithrandir> daniels: yes.
<psusi> ohh ohhh, is it in the repositories?
<daniels> psusi: that version of mesa has been in since *breezy*
<daniels> Mithrandir: nb_* and nn_*?
<Mithrandir> daniels: yup
<psusi> eh?  in what package?
<daniels> psusi: you're about five months late to the party
<daniels> psusi: look up like six lines, dude
<Mithrandir> daniels: that is, nb* and nn*, since you might not get a full, valid locale in.
<daniels> Mithrandir: hrngh
<psusi> then why is everyone still saying to use ati's drivers for 3d? ;)
<daniels> psusi: because people are stupid
<Mithrandir> daniels: just add it below the     *--no*) XMAP="no";;
<Mithrandir> line
<daniels> Mithrandir: actually, you're SOL
<Mithrandir> daniels: oh, why?
<daniels> Mithrandir: because I've ripped out the language 'smarts' in xserver-xorg.config
<Jacobo221> jdub: i could find nothing about it in the wiki. if you sometime remember the specs name, please tell me. i'll be here. waiting ;) thanks so much anyway
<SEJeff> BenC: ping
<Mithrandir> daniels: well.. could I have it back, please?  I need some way to get from language to keymap for keyboard configuration to work on the live cd.
<daniels> Mithrandir: we really, really need to push this down into d-i
<psusi> damnit... I'm so exicted trying to figure out how to get this working is killing me
<Mithrandir> daniels: new live CD doesn't use d-i.
<infinity> daniels : No d-i on the livecd anymore.
<Mithrandir> it's just an initramfs.
<daniels> Mithrandir: into something that's not X
<Mithrandir> and deep, scary magic.
<daniels> Mithrandir: basically, console keymap and xkb map need to be in alignment
<daniels> and the former is a subset of the latter
<Mithrandir> so configuring X keymap and then deriving console keymap makes sense?
<daniels> psusi: it should 'just work'.  if it doesn't, you probably need newer DRM bits for the kernel.
<daniels> Mithrandir: yep.  that's how we should be doing it in the installer.
<daniels> since there are like five console keyamaps
<Mithrandir> daniels: I care very little about console keymaps compared to X keymaps.
<daniels> and fifty hojillion xkb maps, each with seventeen obscure variants that no-one cares about until two days before the release when OH MY GOD IT'S BROKEN WTF IS GOING ON
<daniels> Mithrandir: think of the installer case, not just livecd
<Mithrandir> heh
<psusi> daniels, i seem to already have libgl1-mesa-dri installed... what do I need to put in my xorg.conf to tell the server to use it?  right now I'm using the 'radeon' driver
<psusi> and it doesn't look like that package installs drivers in the xorg directories... hrm...
<daniels> psusi: you don't need to put anything in xorg.conf
<daniels> psusi: just run glxinfo.   if it's telling you that dri is disabled and you've purged fglrx (not just stopped using it), then look in your Xorg.0.log to find out why, but this is getting into #ubuntu territory
<psusi> I can't quite tell from reading these descriptions... is mesa binary compatible with opengl or do apps have to be rebuilt to use mesa?
<infinity> mesa is an implementation of OpenGL.
<psusi> under breezy my xorg log used to have messages saying that the 9800 is not supported by this driver... under dapper, I see this:
<psusi>         *** Direct rendering support is highly experimental for Radeon 9500
<psusi>         *** and newer cards. The 3d mesa driver is not provided in this tree.
<psusi>         *** A very experimental (and incomplete) version is available from Mesa
<psusi> which is why I mentioned pulling the source
<daniels> ignore that message
<psusi> well, it says that drm is enabled... and playing dvds is nice and smooth with rather little cpu used... so it looks like I have 2d accel... yet glxinfo shows no dri
<psusi> isn't dri acceleration for both 2d and 3d?
<daniels> you have completely purged fglrx, right, not just stopped using it?
<psusi> yes... and made sure there are no references to in in my xorg.conf
<psusi> and of course, there is no kernel module now... upgraded kernels a dozen times since then
<psusi> wait a second...doh... looks like it got split out of the linux-restricted module and into xorg-driver-fglrx now... heh... the copyright and changelog in /usr/share/doc/xorg-driver-fglrx still claim to be linux-restricted-modules-2.6.15
<daniels> so you do have fglrx installed.
<psusi> it seems so... purging now... but if it isn't being loaded in xorg.conf, why would it matter?
<daniels> because it replaces libGL
<daniels> i wasn't just saying that for fun, it really does need to be purged if you want to stop using it
<lifeless> daniels: hey, I installed that new package, still got no side-of-trackpad scrolling
<psusi> hrm.... don't two packages that have conflicting files usually specify that they conflict with each other so you can't install both?  how do I get the old libgl back now?
<daniels> lifeless: xorg.0.log pls
<psusi> it's purged now
<daniels> psusi: purge fglrx and it will magically reappear
<lifeless> is that /var/log/gdm/:0.log ?
<psusi> interesting... how does that work?  dpkg notices there's another package that wants to install that file and installs it once that one is removed?
<lifeless> oh, capital X.
<lifeless> daniels: anything I should censor in it before uploading it to p.u.c ?
<infinity> psusi : "dpkg-divert"... Ugly hack.
<infinity> psusi : Required because we can't very well have xorg-driver-fglrx conflict with libgl1-mesa (which the world depends on)
<daniels> lifeless: nope
<lifeless> http://people.ubuntu.com/~robertc/Xorg.0.log
<psusi> interesting... ok... so I don't even have to reinstall libgl1-mesa?  just restart x?
<daniels> you don't have to restart X, either
<daniels> lifeless: *shrug*
<desrt> man
<desrt> fglrx is pwned
<desrt> infinity; sorry for that flood of bugmails :p
<psusi> hrm... glxinfo still says no direct rendering... I don't need libgl1-mesa-swrast do I?  that's just the pure software renderer it looks like
<desrt> daniels; psusi is right
<desrt> daniels; r300_dri.so is nowhere on the system
<infinity> Erm.
<infinity> (base)adconrad@cthulhu:~$ ll /usr/lib/dri/r300_dri.so
<desrt> so even if he's using the right libGL and it's looking in the right place ....
<infinity> -rw-r--r-- 1 root root 1962568 2005-12-16 21:10 /usr/lib/dri/r300_dri.so
<desrt> mind telling me what package that's in?
<infinity> (base)adconrad@cthulhu:~$ dpkg -S /usr/lib/dri/r300_dri.so
<infinity> libgl1-mesa-dri: /usr/lib/dri/r300_dri.so
<desrt> ah.  lovely how that's not part of ubuntu-desktop :)
<desrt> direct rendering: Yes
<desrt> woo.
<psusi> hrm... it's not part of ubuntu-desktop?
<desrt> certainly, i had ubuntu-desktop installed but not libgl1-mesa-dri
<infinity> it is.
<infinity> x-window-system-core depends on it.
<psusi> if it isn't I have no idea how I managed to have it installed... I built this system from the livecd with debootstrap, then installed ubuntu-desktop
<infinity> Oh, WTF.
<infinity> libgl1-mesa provides libgl1-mesa-dri.
<infinity> SWEET.
<daniels> useful.
<desrt> :)
<desrt> plz fix.
<daniels> oh, I know why that is
<desrt> man.  this makes me a happy camper.  to hell with fglrx.
* psusi wishes it worked for him
<infinity> because mesa-sri and mesa used to both provide a libGL, before the proper split happened?
<infinity> s/sri/dri/
<daniels> (debian calls libgl1-mesa, libgl1-mesa-dri.)
<daniels> and libgl1-mesa is libgl1-mesa-swratst
<psusi> infinity, it looks like they both still do
<daniels> and swrast
<daniels> but primarily swratst
<infinity> psusi : No, we have no libGL in our mesa-dri package, just the DRI modules.
<infinity> daniels : Any chance ot a mess of NMUs in Debian to get mesa in sync?
<infinity> daniels : Poeple keep begging for Debian's mesa situation to be sorted anyway.
<daniels> infinity: not from me, but I've been maintaining a Debian tree in parallel to my Ubuntu one
<psusi> oops, nevermind... you're right
<daniels> it'll get hijacked when modular gets uploaded
<infinity> daniels : Fair enough.  So, what do we do in the interim?.. That Provides is breaking seeds.
<infinity> daniels : I guess if x-window-system-core had a versioned dep on mesa-dri, that would "fix" it, since provides don't provide versions. :)
<daniels> infinity: Uploading via ftp mesa_6.4.1-0ubuntu2_source.changes: done.
<daniels> i just removed it.  it's a non-issue because -dri has a tight dep on libgl1-mesa anyway.
<infinity> Of course, the X metapackages all need to get split out anyway, since they still come from xorg right now.
<daniels> infinity: they'll still come from the xorg source package, it'll just be ... lighter
<infinity> Heh.
<infinity> And lacking in the massive orig, I assume.
<desrt> wow.
<psusi> blarg!  everything else looks fine except for direct rendering: no... xserver logs look like everything is working... glxinfo shows it's using the mesa stuff.... I'm going to try retsarting X
<daniels> no, I'll leave the orig in out of spite
<desrt> psusi; you're not missing much
<desrt> psusi; when they say the driver is highly experimental they're not kidding
<infinity> Mmm, spite.
* psusi is an early adoptor/tester/sometimes coder type ;)
<psusi> they told me I couldn't get ubuntu installed on my sata hardware fakeraid dual booting with windows... took me two weeks... but I won ;)
<desrt> psusi; i fired up Xglx and my computer crashed hard
<desrt> psusi; i think this is really something you should wait for
<psusi> hey, if it doesn't work, I can allways go back to the way things are now...
<psusi> and file bugs of course...
<desrt> psusi; you're pretty far outside the scope of this being a problem with ubuntu, though
<psusi> heck.. I may as well install todays' batch of updated dapper packages and reboot... 
<desrt> psusi; maybe get involved with upstream r300_dri development if you want to help?
<psusi> problem is... there's about a dozen projects I'd like to see advance more... and I'm only one person with a full time job ;)
<psusi> I love linux and open source because I CAN fix things... I love ubuntu because I don't have to ;)
<psusi> hrm.. that reminds me... I wonder if my lilo patch ever got accepted upstream?
<desrt> then you should stick to breezy :)
<psusi> desrt, got it on another partition in case things break and I don't feel like looking into it
<Burglaptop> does debian ship with build-essential installed by default?
<psusi> ok... reboot time... brb
<womble> Burglaptop: No, unless you choose to install development-related tasks
<Burglaptop> womble: ok, cheers
<desrt> infinity, daniels; thanks for the help but i think i'm gonna stick it out in 2D land for now :)
<Burglaptop> daniels: is dri for i810 borked currently?'
<infinity> desrt : Wimp. :)
<desrt> infinity; is r300 *expected* to be working in any way?
<infinity> desrt : I dunno.  Doesn't really do much of anything useful for me yet.
<infinity> I'm not following it closely, though.
* desrt is pretty close to going out and buying a 9250
<psusi> daniels, still no direct rendering... should I file a bug?  if so, against what module?  the mesa library?
<daniels> Burglaptop: install libgl1-mesa-dri
<Burglaptop> daniels: ah
<psusi> xorg log says direct rendering is enabled... is there a way to get more info from glxinfo about WHY it doesn't think it is?
<desrt> psusi; LIBGL_DEBUG=verbose glxinfo
<desrt> psusi; but seriously.... #ubuntu man
<psusi> they don't seem to talk much about dapper over there ;)
<infinity> Then start talking about dapper over there.  Seriously.  Please.
<infinity> -:- Topic (#ubuntu-devel): Ubuntu Development (not support, even with dapper)
<psusi> well I'll be... it isn't looking in the right place for r300_dri.so... it is checking several dirs in /usr/X11R6 but it is actually in /usr/lib/dri
<infinity> psusi : Then you still have xorg-driver-fglrx's libGL installed.
<psusi> I purged it and even reinstalled the mesa packages
<infinity> psusi : ls -l /usr/lib/libGL*
<desrt> md5sum /usr/lib/libGL.so.1.2
<psusi> 14152de53fb6c8dee1d1fb7d535f7434  /usr/lib/libGL.so.1.2
* infinity notes that he had the wrong on installed cause he brilliantly renamed it to libGL.so.1.2.fglrx, and ldconfig picked that up before the mesa one, so libGL.so.1 pointed to the fglrx one.
<desrt> that's not mesa libGL
<desrt> it's not the one i'd expect to see from fglrx either tho.... :)
<psusi> hrm...
<infinity> psusi : i386 or amd64?
<psusi> amd64
<desrt> ah.  of course.
<desrt> psusi; grep for that md5sum in /var/lib/dpkg/info/*
<infinity> psusi : ls -l /usr/lib/libGL*
<desrt> psusi; to find out what package it originally came from
<psusi> libgl1-mesa.md5sums:14152de53fb6c8dee1d1fb7d535f7434  usr/lib/libGL.so.1.2
<infinity> Yeah, that's fine.
<infinity> But it's also obviously not the library being loaded.
<psusi> thought so... yet it's looking in the wrong place for the .so
<desrt> psusi; check for other libGL's in /usr/lib.....
<psusi> that's the one that the libGL.so.1 symlink points to... and there's no others
<infinity> psusi : And "ldd glxinfo" shows it resolving to /usr/lib/libGL.so.1?
<psusi> yep
<desrt> psusi; grep /usr/X11 /usr/lib/libGL.so.1
<desrt> binary file matches?
<infinity> ("strings" works well there)
<infinity> Anyhow, I should get back to work.
<desrt> infinity; eh.  this is a case of either it is or it isn't :)
<infinity> Any chance I can convince you two to take this to -users?
<psusi> you lost me... grep what?  the glxinfo binary for /usr/lib/libGL?
<desrt> psusi; see /query
<psusi> k
<infinity> strings libGL.so.1.2 | grep '/usr'
<infinity> I'm curious.
<infinity> But it should return /usr/lib/dri
* desrt bets an old version...
<psusi> only one match:
<psusi> /usr/lib/dri
<desrt> w t f
<psusi> maybe I should just give it a symlink in the dir it wants to the real location? ;)
<infinity> No.
<infinity> glxinfo 2>/dev/null | grep vendor
<BenC> SEJeff: pong
<SEJeff> BenC: nvm. I was trying to figure out why older kernels freaked out and wouldn't mount my lvm filesystems
<psusi> infinity, sgi, sgi, mesa
<SEJeff> BenC: I thought it was a bug, but then I remembered how much udev and the likes were changed
<infinity> psusi : Oh, that is special.
<BenC> yeah, once you go dapper-kernel, you can't go back easily
<SEJeff> BenC: So I noticed...
<psusi> yea... dapper does not like being booted with the older kernels, and breezy doesn't like newer ones... at least newer than 2.6.13 that I build myself
<sistpoty> BenC: I saw a new linux-source-2.6.15 approaching... did it adress #20910?
<infinity> The general rule when using new kernels on older distributions is to build monolithic (or close to it) kernels.
<infinity> Features like udev and such are bound to break, and often module loading in general will break.
<BenC> preach it brotha infinity
<jblack> BenC: Hiya.. Fabbione suggested I talk to you
<BenC> sistopy: not directly, but it's very possible
<sistpoty> BenC: ok, will test it... thx
<psusi> hrm....
<desrt> psusi; ./configure;  make tea;  drink
<psusi> touch ; finger ; unzip ; gasp; yes; yes; yes; zip; done;
<psusi> yep... strace confirms, glxinfo IS using /usr/lib/libGL.so.1, which points to libGL.so.1.2, which matches the md5sum from the mesa package
<BenC> jblack: about what?
<jblack> I am a proud owner of a sony vaio. It seems the latest kernels removed sony acpi support
<jblack> Fabbio suggested I ask you if there was something bad going on in that module before I dive into kbuild
<BenC> jblack: not intentional
<BenC> jblack: for some reason the module deps on ACPI_INTERPRETER, but nothing provides it, so it's disabled
<jblack> Well, maybe the kernel guys will fix it some day.
<psusi> why would the module depend on a non existant service/package that is part of the kernel?
<psusi> oh.. nevermind... different dep
<BenC> jblack: no, I'll fix it today :)
<jblack> Thank you so much.
<jblack> can you do make-acpi-sleep-work magical stuff too?
<BenC> that's black magic :)
<StevenK> jblack: BenC would, but he doesn't have a spare virgin at the moment ...
* psusi wonders if you can use gdb to break on the attempt to dlopen the wrong path and backtrace from there
<jblack> I have a 11 year old daughter that I could contribute....
<BenC> jblack: get a sack of grain, and two left-handed mules, and I'll see what I can do
<psusi> rofl
<jblack> Hmmm. Does it count if she's stubborn and I donate the ex-wife as well? 
* jblack looks up how to purchase and ship grain
<psusi> does she have two left feet?
<jblack> Yeah. 
<jblack> And about five mouths and eyes in the back of her head. =)
<jblack> I kinda like the kid though.
<psusi> well... if I symlink /usr/X11R6/lib/modules/dri to /usr/lib/dri, direct rendering works fine... wonder what package I should file a bug against?
<infinity> psusi : The one you find that path hiding in?
<fabbione> morning
<psusi> infinity, I've searched and searched... can't find it... at least not hard coded in any binaries... and I don't see any conf files being open()ed that look like they might contain it
<psusi> but hell... with the symlink, I get 3000 fps in glxgears ;)
<infinity> psusi : Do you have a /usr/lib32/libGL.so.1.2?
<daniels> glxgears is not a benchmark.
<psusi> infinity, yes... I do... 
<psusi> daniels, but it is a good indicator of weather or not direct rendering is working ;)
<infinity> psusi : And "strings /usr/lib32/libGL.so.1.2 | grep '/usr'" tells you what?
<infinity> psusi : (and /usr/lib32/libGL.so.1 points to where?)
<psusi> well farg... tried shrinking the glxgears window to speed up the fps... it went faster... for a few seconds... then the xserver hard locked and it was magic sysreq time
<psusi> someone was saying something about lib32?
<infinity> <infinity> psusi : And "strings /usr/lib32/libGL.so.1.2 | grep '/usr'" tells you what?
<infinity> <infinity> psusi : (and /usr/lib32/libGL.so.1 points to where?)
<infinity> Also, the new r300 stuff on my X300 actually plays Quake3 smoothly.  Neat.
<eruin> I know! /usr/X11R6/lib/modules/dri 
<psusi> well, glxgears is a 64 bit elf image, so it should not be able to link to the lib32 version... and I can see from strace that it is, in fact, loading /usr/lib/libGL.so.1.2... but I'll check anyhow
<psusi> it shows /usr/lib/dri
<daniels> grep -r /usr/X11R6/lib/modules/dri /
<infinity> daniels : Heh.  That could take a little while. ;)
<daniels> well, this has taken like an hour so far
<psusi> blast... locked up again running glxgears... strange that the cursor still worked
<infinity> daniels : Fair point.
<infinity> psusi : Just grep your whole system for /usr/X11R6/lib/modules/dri and see what turns up. :)
<psusi> rofl
<infinity> (And you think we're kidding)
<psusi> ok... let's see... how to do that.... something with find -exec grep?
<psusi> maybe find -exec strings grep be better
<infinity> rgrep /usr/X11R6/lib/modules/dri /
<psusi> ok...
<infinity> Maybe with a 2>/dev/null on that, if you don't want to see a mess of errors about premissions and dangling links.
<psusi> hrm... it looks like it isn't doing anything... printed a few errors, then stopped... don't hear the disks, and cpu load is nil
<psusi> OMFG
<psusi> I limited it to /etc, and bingo:
<psusi> /etc/profile:    LIBGL_DRIVERS_PATH=$LIBGL_DRIVERS_PATH:/usr/X11R6/lib64/modules/dri/:/usr/X11R6/lib/modules/dri/
<psusi> /etc/profile:  LIBGL_DRIVERS_PATH=/usr/X11R6/lib64/modules/dri/:/usr/X11R6/lib/modules/dri/
<desrt> wow.  you're still on about this :)
<daniels> lib64??
<daniels> looks like that's your problem, man
<psusi> how on earth did that get there?
<infinity> That looks very much like something the ATI fglrx installer (not our packages) did to you.
<infinity> Or advice you got from a forum or from Gentoo.
* desrt votes 'vi' :)
<daniels> almost certainly fglrx installer
<psusi> I did install the ati driver from their web site at one point... a long time ago
<infinity> Well, there you go.
<infinity> Problem solved.
<infinity> Now we can go about our day.
<eruin> blasted! a symlink from /usr/X11R6/lib/modules/dri/ to /usr/lib/dri/ is all that was missing for me to enjoy 3d gaming bliss with fglrx on dapper!
<Robi-> who's got a min to troubleshoot a usb wifi driver?
<psusi> so...  how can I fix it? ;)
<`anthony> infinity: that's cos the ricers think that lib64 makes your system go faster, even on 32 bit systems ;)
<daniels> psusi: ... remove it.
<psusi> change it to point to the right place, or remove it completely?
<infinity> eruin : Err.  That and an fglrx module that works with kernel 2.6.15...
<daniels> `anthony: DUDE THERE'S TWO EXTRA NUMBERS ON THE END
<daniels> it goes 64% faster
<psusi> ok.... cool... thanks...
<daniels> psusi: remove it completely
<infinity> eruin : WARNING, YOUR MACHINE WILL CRASH.
<eruin> infinity, works like a dream here
<psusi> now... to figure out why the x server locks up hard
<eruin> infinity, in fact, only the ati driver crashes my machine, while fglrx is rock stable
<daniels> psusi: because r300 is screwed
<psusi> hehehe... I'd imagine so... especially when running on an r350 ;)
<infinity> eruin : You're lucky.  Kernel panics for everyone else who figured out how to unbreak it. ;)
<Robi-> lsusb shows Bus 001 Device 003: ID 124a:4023 AirVast, supposedly a prism2/2.5/3 card, so prism2_usb driver
<Robi-> loading it, no error, and nothing happens, no new device created
<Robi-> modinfo shows an alias for 124a:xxxx on two occasions but the numbers, dont match exactly
<eruin> infinity, well, X produces a kernel BUG and locks the system on exit, but that's my only woe ;)
<Robi-> this is the PN15 usb wufi card on a shuttle sff pc
<daniels> psusi: ignore r350
<infinity> eruin : I get the BUG/lock if DRI is disabled.  When I fix DRI, I get panics.
<daniels> psusi: r3xx is screwed
<daniels> as a general statement
<`anthony> eruin: So it's fine except that it crashes the system? ;)
<desrt> eruin; sounds like my problem but in addition to that any glx app that attempts to use DRI locks up :)
<Robi-> doesn't work in dapper fl2 either
<eruin> anthony: it only crashes when I want it shut down anyway :p
<psusi> daniels, why do you say that?  earlier you said it was working fine for you?
* desrt has learned a lot about all of this non-sense tonight
<eruin> desrt, I just ran enemy-territory fine :)
<desrt> eruin; fglrx?
<daniels> psusi: 3d has never worked for me
<eruin> yup
* desrt shrugs
<psusi> are you messing with me now?  I am a bit tipsy at this point in the evening...
<daniels> psusi: no, I don't say this shit to mess with random people on channel when I could be working productively instead
<Robi-> daniels, who might know usb drivers well? or where?
<psusi> I swear you said earlier the mesa libs had working 3d for 5 months... oh well, it is getting late... time to call it a night... thanks for the help... I knew those proprietary drivers had messed something up somewhere...
<desrt> O_o
<`anthony> daniels: Nah, you say this shit because it amuses you ;)
<floam> is the rc3 xorg server close at all to finally getting into dapper?
<daniels> no
<daniels> and it won't get into dapper
<daniels> `anthony: i think I need some more port
<floam> daniels: skipping it?
<daniels> Robi-: if you have a specific bug, try bugzilla.ubuntu.com
* StevenK recalls daniels saying R7 would be released in August.
* StevenK hides.
<Robi-> daniels , bug like this driver doesn't recognize this card? heh bit broad
<daniels> Robi-: name the specific driver and the specific card and you've got a workable bug report
<daniels> StevenK: yeah, well we all make mistakes
<daniels> StevenK: iirc our original estimate was january 2005
<desrt> Robi-; sounds pretty specific.  give the vendor/product codes of the card that's not being recognised
<daniels> floam: yes, I'm already most of the way through packaging rc4
<StevenK> daniels: Heh, that looks about right.
<daniels> 138 packages done, ~67 to go
<floam> I didn't realize rc4 was released
<Robi-> desrt well i cant be sure i have the right driver
<daniels> floam: http://xorg.freedesktop.org/releases/X11R7.0-RC4/
<Robi-> hence i want to get it workign first
<floam> s/didn't/hadn't/
<Robi-> then have them fix it
<floam> cool
<desrt> Robi-; is it a usb device not being recognised or the usb host controller driver not recognising your usb port?
<Robi-> device, i have an shuttle sff pc here with an internal usb wifi card
<Robi-> AirVast 124a:4023
<Robi-> google et a says prism2/2.5/3
<desrt> then go into the driver you think it is and add those tags to the list
<Robi-> prism2_usb
<Robi-> tried with ith a hex editor on the driver i have
<desrt> uhm
<desrt> it's opensource for a reason...
<Robi-> point taken
<desrt> search for 'struct usb_device_id'
<Robi-> k need to get the kernel-modules for this kernel
<Robi-> if i could find them
<desrt> you probably want linux-source-2.6.15
<Robi-> i have 2.6.12
<desrt> o
<Robi-> mainer , yes but that doens't matter as there is no wifi device yet
<Robi-> desrt, downloading
<Robi-> desrt, untaring
<Robi-> hmm, can't find the driver
<desrt> drivers/net/wireless/prism2
<Robi-> only prism54 found
<desrt> Robi-; probably easiest way to do one-shot module builds is to use linux-headers
* desrt shrugs
<desrt> maybe it's not in 2.6.12
<Robi-> could try to use that
<daniels> it'll be in a patch
<Robi-> well it comes with teh installed system so it better be
<desrt> daniels; linux-source comes with patches applied, no?
<daniels> no
<daniels> fakeroot debian/rules patch
<daniels> 2.6.12 is pre-git iirc
<desrt> i see.
<Robi-> ya i doubt its the prism54 driver it's seems all pci
<Robi-> even tho thid card does b/g
<Robi-> so now what?
<desrt> Robi-; did you do what daniels said?
<Robi-> that's a command?
<Robi-> root@3[linux-source-2.6.12] # cat version.Debian
<Robi-> 2.6.12-10.dcc3.0
<Robi-> there is no debian dir
<Robi-> desrt ?
<Robi-> desrt ?
<JaneW> who handles the ubuntu shutdown screen? And specifically the choice of progress bar going 
<JaneW> backwards?
<infinity> Me.
<infinity> Of course, it's no even uploaded yet, so I suppose you are free to argue with me now if you'd like.
<floam> I think backwards makes sense
<floam> since it goes fowards filling up as you boot
<JaneW> infinity heh
<JaneW> infinity: I have a mail whining^H asking about it...
<infinity> What specifically do they whine about?... Just that they think "backwards is dumb"?
* fabbione decides it's time to do some kernel security crack and fires up metallica at 300W at 8am
<infinity> Does Metallica help with security work?
* infinity should try this.
<fabbione> infinity: it keeps me a bit more awake
<JaneW> infinity: mail on the way, yeah they think it's dumb, and looks like there's a problem (esp cos of the red)
<infinity> Yeah, I was undecided on the red, but probably won't do it (cause red is "alarmist")
* fabbione suggests a bright fuxia
<jsgotangco> JaneW, re: email WOW
<JaneW> jsgotangco: nod
<JaneW> jsgotangco: but I didn;t really know what to make of it....
<JaneW> fabbione: fuchia?
<JaneW> infinity: think he has a valid point though?
<fabbione> JaneW: probably.. some kind of fancy women purple
<JaneW> fabbione: it's the name of a flower that's why I know it. I have several in my garden ;)
* fabbione is somewhat NOT surprised
<JaneW> heh
<JaneW> ok which one of you guys has stolen a penguin?! http://www.iol.co.za/index.php?set_id=1&click_id=29&art_id=qw113500332165B231
<infinity> JaneW : About the red?... Probably.  The "why backward" comment was more of an aside.
<infinity> JaneW : As for using a progress bar rather than throbber... <shrug>... Personal preference, I guess.  I wouldn't mind the latter, but I doubt we'll do it.
<JaneW> ok, I think if anything the red part is a valid concern...
<JaneW> the average person would think oh $$#@ what have I done!?
<JaneW> fabbione: http://www.denhoedt.nl/hans/031010_fuchia/source/3.html
<jsgotangco> JaneW, that guy is like 200% more qualified than me
<fabbione> JaneW: SCORE!
<JaneW> jsgotangco: but he wants money :P
<jsgotangco> JaneW, i've read lots about him, he could actually put order in our doc process....
<jsgotangco> JaneW, OH
<jsgotangco> i didnt see that in the email
<JaneW> jsgotangco: which is why I didn;t want to ignore him....
<jsgotangco> argghh
<jsgotangco> i didnt see the last line
<JaneW> yep, it was all good until that point...
<jsgotangco> jeezz
<jsgotangco> that just deflated my spirits
<JaneW> also why I decided to run it past you before silbs or someone else...
<jsgotangco> JaneW, i think we're doing good as a volunteer group IMHO
<jsgotangco> but if there's a need for a guy to be paid to do that, well that's a company strategy
<whiprush> hey infinity, at UDU we talked about ldap for a bit ... if you had to make a choice today would you be in the openldap camp or the fedora ds camp? (note, if you say neither then that kind of sucks for me.)
<whiprush> jsgotangco / JaneW: didn't mean to kill the channel!
<jsgotangco> heh
<dholbach> good morning developers
<seth_k|lappy> morning dholbach :)
<crimsun> 'lo daniel
<whiprush> hi daniel.
<dholbach> whoo guys! how are you?
<jsgotangco> JaneW, anyways, despite the background of the guy, its up to you guys based on your strategy
<JaneW> jsgotangco: k
<lucas> hi
<sivang> good morning all
<lucas> arg, still no time announced for the CC meeting
<sivang> nice, seems mono is fixed?
<vamsee> hey guys, this is my first time here... just wanted to give some thanks and leave.
<vamsee> I want to congratulate the laptop team. they have done an amazing job
<vamsee> my thinkpad works flawlessly with a default breezy install.
<vamsee> I had to jump through many hoops to get the same done in debian.
<dholbach> vamsee: nice to hear that - i think the laptop guys are on #ubuntu-laptop or something, but yeah - they did a great job :)
* jsgotangco struggling with dapper test on laptop
<jsgotangco> =)
<vamsee> jsgotangco: keep at it, there will be many thankful laptop users like me down the line
<jsgotangco> vamsee, if you got time to test out dapper, we'd love test data
<vamsee> wow. thanks for the offer, I'll think about it. right now, I'm just a web developer with too much on my plate. I'll surely think about it.
<vamsee> ok, bye all.
<ogra> ENOELMO ??
<pitti> Good morning
<ogra> morning pitti 
<ogra> i'm syncing a new gobby today (hint, hint :) )
<Treenaks> Who do I contact for Fridge bugs?
<ogra> Treenaks, fridge-devel@
<Treenaks> ogra: argh, mail.. ok
<ogra> or whiprush, or jdub directly
<Treenaks> whiprush: The fridge atom-feed links to 'glossary#term8', which is a relative link, which gets converted to 'http://fridge.ubuntu.com/atom/glossary#term8' -- which doesn't exist.
<Kamion> jdub: ttf-dejavu seeded
<jdub> Kamion: rocking, thanks :)
<paines> hi
<paines> i would like to add the emacs-snapshot package from debian-unstable to ubuntu. never done something like this before. are their any tutorials ?
<seb128> pool/universe/e/emacs-snapshot/emacs-snapshot_20051215-1_i386.deb
<seb128> already to universe
<paines> ups
<paines> <- blind !
<seb128> Kamion: do you do NEW approval for new source packages? gst-plugins-base0.10 gstreamer0.10-ffmpeg are waiting and I'm not sure if elmo is around this week
<Kamion> seb128: not normally, no
<Kamion> but I can, give me a second
<Kamion> elmo was around yesterday judging by activity on ubuntu-changes-auto
<Kamion> (the "autosync" is manually started each day by elmo ...)
<seb128> k, let them for elmo if he's around, I'll try pinging him
<Kamion> doesn't look like he did new yesterday though
<Kamion> seb128: gst-plugins-base0.10 and gstreamer0.10-ffmpeg done, although I accidentally sent the first to main
<Kamion> do I need to kick that back out to universe, or is it targeted at main RSN anyway?
<seb128> Kamion: thanks. Target is main, I want to switch rhythmbox/totem to gst0.10 soon
<jdub> (ROCK!)
<seb128> :)
<seb128> Kamion: we can argue that's a new gst-plugins0.8 version anyway
<seb128> should I make a wiki page for its promotion?
<siretart> seb128: does gstreamer0.10-ffmpeg include a new copy of ffmpeg?
<seb128> new like what?
<seb128> newer than ... ?
<Kamion> seb128: no need I think, it's obvious
<seb128> cool
<Kamion> basically existing source, just renamed
<seb128> right, part of existing source, they basically splitted to -base/good/bad/ugly
<siretart> seb128: I mean with 'new' 'another' copy of ffmpeg
<seb128> siretart: that's gst-ffmpeg 0.8 for gst0.10
<seb128> no difference
<siretart> ok
<Kamion> infinity: 2.6.15-9 kernels NEWed, so now's probably a good time for l-r-m
<janimo> do others experience given-backs? the error in my case is '/usr/bin/apt-cache failed'
<janimo> does giving back a package depend on it's structure too or is it just a build system internal thing
<Kamion> internal
<Kamion> it generally means your package was unlucky enough to build at a time when apt-ftparchive was running on the master archive; the buildd admin will sort it out
<Mithrandir> pitti: thanks for the prod about sane-backends, it had gotten rejected and I hadn't gotten around to doing anything about it.
<pitti> Mithrandir: heh, I just wondered about the total lack of an udev rule :)
<pitti> thanks for fixing
<zul> Kamion: ping
<Kamion> zul: hi
<Mithrandir> pitti: is it correct that rules are installed to /etc/udev or should they go to /etc/udev/rules.d?
<zul> Kamion: did you have a look at the diff yet?
<pitti> Mithrandir: they should go to rules.d without any symlink mess
<Kamion> ok, looking now
<pitti> Mithrandir: oops, did you use symlinks to /etc/udev?
<Mithrandir> pitti: no symlinks, but the file is installed directly in /etc/udev.  I can fix that easily enough, though.
<pitti> Mithrandir: quick, upload another one until sb notices and you need a proper conffile transition :)
<Kamion> zul: in future an interdiff would be easier
<zul> ok
<pitti> Mithrandir: it should be /etc/udev/rules.d/45-libsane.rules
<Kamion> ideally without enormous configure and Makefile.in diffs ... looks like you reran the autotools?
<pitti> Mithrandir: files in /etc/udev are not evaluated at all
<zul> yeah i did sorry about that
<Kamion> zul: oh, vomit, that Ubuntu version thing is FOUL
<Mithrandir> pitti: are you sure?  It seems to work on my laptop.
<pitti> Mithrandir: pretty sure, yes. And you are sure that you don't have a symlink in rules.d which points to /etc/udev/libsane.rules?
<zul> Kamion: how so?
<Kamion> I'd rather not include that, it's just too bad
<Kamion> +       if echo "$kernel_version" | grep -q ^2.6.8; then
<Kamion> +               ubuntu_version="(Ubuntu 4.10)"
<Kamion> +       fi
<Kamion> come on
<Mithrandir> pitti: oops, I do. :-/
<zul> Kamion: it was simple to do at the time and it worked
<pitti> Mithrandir: just remove both in the preinst and install the new one as normal conffile
<Kamion> IMHO it's too sucky to maintain
<pitti> carlos: hey, rosetta export is running again?
<pitti> carlos: I have a tarball from today (however, it's tiny)
<Kamion> I'd rather set up initial values in grub-installer using os-prober (which can extract the version properly) and update those for the current filesystem in update-grub
<Kamion> then we can fetch them from lsb_release output rather than messing with a big map of kernel versions to releases
<opi> Kamion, also, I was running different kernel on 4.10
<Kamion> zul: why the change to automake1.8?
<zul> sure...it worked though at the time
<opi> Kamion, so this script would fail
<Kamion> zul: for you
<zul> Kamion: yeah, i didnt automake 1.8 istalled and it couldnt find aclocal-1.8
<Kamion> automake1.9 |    1.9.6-1 |        dapper | source, all
<pitti> carlos: and it's still called rosetta-breezy; do you import dapper already?
<Kamion> ah, debian/rules just needs a one-line fix instead of that
<carlos> pitti, I was renabling it yes
<carlos> pitti, no, not yet
<zul> didnt have automake1.9 installed either
<pitti> carlos: any idea why it's only 22 MB?
<carlos> pitti, only changes
<pitti> carlos: ah, I see
<pitti> carlos: any chance to get a dapper tarball?
<Kamion> zul: it was already in the build-depends
<pitti> carlos: I need to build new langpacks today or tomorrow to rearrange locales
<Kamion> zul: there was already debian/patches/raid_cciss.diff for the cpqarray stuff; did you look at why that didn't work before adding another similar patch?
<zul> Kamion: ok but aclocal-1.8 is hard coded in the debian/rules
<carlos> pitti, for dapper?
<Kamion> yeah, fixing that would be a much much much simpler change
<pitti> carlos: yes
<carlos> pitti, I cannot give you that tarball
<zul> Kamion: it wasnt in the lib/device.c so i dont think it would work
<carlos> we need gina running on production
<carlos> for that
<pitti> carlos: ok, then I'll use the buildd output
<carlos> and my latest branch merged
<carlos> ok
<carlos> pitti, as soon as dapper is using Rosetta I will tell you it
<Kamion> --- grub-0.95+cvs20040624/lib/device.c  2004-05-23 18:45:35 +0200
<Kamion> +++ grub-0.95+cvs20040624.debian/lib/device.c   2004-10-06 13:43:44 +0200
<Kamion> bzzt
<zul> meh..
<Kamion> zul: on the "nitpicky" front, we should stick with upstream's indentation conventions rather than inventing our own
<zul> sure..
<Kamion> (i.e. two-space indents, GNU-style)
<Kamion> ++      for (controller = 0; i < 8; i++)
<Kamion> that just looks plain wrong
<zul> argh!!!
<zul> ok maybe it wasnt quite ready...ill go back to the drawing board
<Kamion> and your cpqarray.diff patches a line that was previously added by grub-i2o.diff, which seems redundant :)
<seb128> Kamion: could you promote gstreamer0.10 so gst-plugins-base0.10 can build? Thank you :)
<Mithrandir> pitti: thanks, uploaded.
<Kamion> zul: ok, thanks - the i2o stuff certainly seems necessary once it's fixed, although it clearly needs testing :) I'm less sure about the rest of it
<zul> ok well back to the drawing board then
<Kamion> seb128: promote which binaries?
* Kamion assumes libgstreamer0.10-{0,dev}
<zul> Kamion: thanks anyways
<Kamion> np
<seb128> Kamion: libgstreamer0.10-dev libgstreamer0.10-0 for now
<Kamion> seb128: done
<seb128> Kamion: other parts will probably need to be seeded or grabbed by Depends
<seb128> thanks
<jbailey> fabbione: Hey Fabio. =)
<jbailey> fabbione: That X driver you gave me doesn't seem to have hung so far.
<fabbione> jbailey: that's cool..
<fabbione> next upload will have that patch
<fabbione> already spoken with daniels
<jbailey> fabbione: Is that an expected side effect?  I couldn't remember if there was something more than just debug enabling in here.
<fabbione> yes it is expected
<fabbione> there is code change compared to the old patch i added a few weeks back
<jbailey> Cool.
<fabbione> the redrawing issue is something related to the server
<fabbione> it's not a driver fault at all
<jbailey> Right.
<jbailey> It'll just be so sweet if this works.
<fabbione> yup
<jbailey> You mentioned it was DRM related, does that mean they're growing hardware accell for this card?
<fabbione> jbailey: no idea about all details.. i just reported what benh told me
<jbailey> fabbione: No worries.  I just want to make sure that if I'm there's other things changing around me, that I'm testing all the needed pieces.
* StevenK would just like to mention that he is over Christmas.
<pitti> fabbione: btw, do you see any reason to keep linux 2.6.12 in dapper? it's not patched for security and works poorly with the new udev stuff anyway
<fabbione> pitti: not at all
<fabbione> we can kill it
<pitti> ok
<pitti> oh, elmo is not online
<fabbione> i want to talk with Ben before we kill it 100%
<fabbione> afaik it can't even build in dapper
* sivang reboots to test new kernel upgrade
<jbailey> pitti: ia64 and hppa might still need it for booting.
<jbailey> pitti: I'm lagged on a klibc upload that they need to boot.
<pitti> jbailey: ah, so it's still the default kernel on those arches?
<fabbione> jbailey: ia64 boots with .15
<fabbione> hppa i need to check .15-rc6
<fabbione> rc5 has a problem with the scsi driver and crashes
<fabbione> we also need to speedup initramfs for ia64..
<jbailey> fabbione: Err, how?
<jbailey> fabbione: klibc shared libraries don't seem to work on ia64.
<fabbione> it looks like that mckinley generated initrd keeps missing a module
<jbailey> BenC tracked down that using the static ones seemed to solve the problem there.
<fabbione> jbailey: they still use initrd-tools?
<jbailey> They can't with 2.6.15.  initrd-tools needs devfs.
* fabbione scratches his head....
<fabbione> dude.. i am sure as hell i did boot .15 on ia64
<fabbione> using itanium-smp kernel
<fabbione> mckinley no
<jbailey> fabbione: I'm not saying that you didn't, I just want to know how. =)
<fabbione> apt-get install $random kernel...
<fabbione> really.. i did nothing more than that
* jbailey boggles.
<fabbione> i can check again.. give the time to power them up
<sivang> ok, mere panel problems , nothing more :)
<fabbione> jbailey: Linux golion 2.6.15-8-itanium-smp #1 SMP Tue Dec 13 05:44:26 UTC 2005 ia64 GNU/Linux
<fabbione> Linux baldios 2.6.12-9-hppa32-smp #1 SMP Mon Oct 10 13:32:14 UTC 2005 parisc GNU/Linux
<fabbione> as i said.. .15 on ia64 works
<jbailey> fabbione: CAn you unpack the initramfs for me
<fabbione> i just really installed it from dapper...
<jbailey> ?
* Kamion removes 13MB from all live CDs
<fabbione> jbailey: of course i can.. what do you want me to check?
<jbailey> fabbione: mkdir /tmp/foo; cd /tmp/foo; zcat /boot/initrd.img-2.6.15-8-itanium-smp | cpio -i
<fabbione> file /boot/initrd.img-2.6.15-8-itanium-smp 
<fabbione> /boot/initrd.img-2.6.15-8-itanium-smp: Linux Compressed ROM File System data, little endian size 11010048 version #2 sorted_dirs CRC 0xc8990b8c, edition 0, 2125 blocks, 338 files
<fabbione> told you it is still using initrd-tools
<fabbione> hey sabdfl 
<jbailey> Do you have devfs in that kernel somehow?
<jbailey> It should really *not* work...
<sabdfl> hey hey
<fabbione> jbailey: no..
<jbailey> g'day Mark
<fabbione> there is no way to have devfs in .15
<fabbione> it has been removed from upstream in .13
* mvo waves to mark
<sabdfl> hiya mvo
<jbailey> The reports I had from all over the place were that it failed wildly.
<sivang> hey sabdfl 
<jbailey> Which makes sense, since there's no device tree.
<pitti> hi sabdfl 
<fabbione> jbailey: perhaps my ia64 is more clever than the others?
<fabbione> jbailey: i really can't say.. my experience on that machine can be counters in hours on the tip of my fingers
<jbailey> Feh.  I need to bring my ia64 home.  Having it in Toronto makes boot testing scary.
<fabbione> jbailey: i can give you some temporary access for the next week if you want. I will get full console setup between Xmas and newyear mostlikely
<jbailey> fabbione: Lemme try to find one more locally.  The lag to your place just kills me for interactive.
<jbailey> thanks for the offer, though.
<fabbione> jbailey: yes i know :/
<jbailey> fabbione: Do you get that sort of lag to the DC?
<fabbione> no
<zul> heylo
<BenC> jbailey: I boot initrd on my ia64 with 2.6.15
<BenC> still works
<zul> Kamion: ping...how does os-prober work?
<Kamion> zul: it runs in the installer, mounting each filesystem it can find in turn and poking about in it using a variety of methods to figure out the OS version
<Kamion> it shouldn't be used in a normal system
<zul> ok..
<zul> just trying to figure out a better way to do the version number stuff
<thesaltydog> what time is it the CC meeting?
<Pygi> welcome mxpxpod
<mxpxpod> hey Pygi 
<jbailey> fabbione: X hung again, no message in the X log at all.
<jbailey> fabbione: It did hold up *much* longer than the previous one, though.
<Pygi> welcome vuntz, mvirkkil, akatemik ;)
<Akatemik> Grah. Unbelievable brokedown at uni network
<zakame> heya Pygi 
<Akatemik> NFS-servers are still down, so no home-folders.
<pappan> i am tired looking for a project to work for
<pappan> where can i find some projects in ubuntu which needs some coders
<zul> pappan: #ubuntu-motu
<pappan> or atleast something thru which i can contribute to ubuntu
<pappan> zul: ty
<fabbione> jbailey: try disabling dri
<jbailey> fabbione: Well, I'm less worried about working around the problem than I am about making sure that I give you a decent bug report so that it's fixed in time for Dapper.
<fabbione> jbailey: i dunno how to. You need to talk with daniels and benh for that.
<fabbione> jbailey: but isolating the issue in the first place to a config option will help
<jbailey> How close is our X code to upstream?  Will talking to BenH be useful?
<jbailey> I don't usually like to annoy upstream directly with bugs that might be in Ubuntu and not elsewhere.
<fabbione> our code is the same upstream afaik
<fabbione> in the actual pkg -ati is rc3 + benh patch that's already in daniels rc4 tree and next ati package
<fabbione> so no difference afaict
<jbailey> Cool, thanks
<jbailey> I'll try and catch him online later, then.
<pitti> Kamion: what would be your preferred interface in the installer to set up and generate the default system locale?
<pitti> Kamion: a particular way of calling locale-def?
<pitti> Kamion: erm, locale-gen
<Kamion> anything vaguely similar to what localechooser's post-base-installer script does now is fine
<Kamion> if it gets simpler, bonus
<pitti> no idea about that - does it add the locale to /etc/locale.gen?
<Kamion> yes
<pitti> Kamion: would 'locale-gen xx_YY.UTF-8' be fine for you?
<pitti> since we don't have /etc/locale.gen any more
<Kamion> if validlocale says it isn't there yet
<Kamion> and then calls locale-gen --keep-existing
<Kamion> pitti: sure, that's fine
<pitti> Kamion: alternatively, adding to /var/lib/locales/supported.d/local would do the same, but that should be hidden probably
<Kamion> could it take one or more locales on the command line rather than just one, and also silently skip doing anything if the locale you give it already exists?
<Kamion> I definitely prefer just calling locale-gen to editing some random file
<pitti> Kamion: sure, it would imply --keep-existing
<pitti> and multiple locales should be easy to do
<pitti> Kamion: what's the installer's use case for multiple locales?
<pitti> Kamion: locale-gen already supports generating all locales for a particular language, do you need sth similar?
<Kamion> pitti: (a) mdz asked that we always generate English, no matter what the installation language
<pitti> ah, right
<Kamion> pitti: (b) in expert mode you can select exactly what locales you want
<Kamion> (as a multiselect)
<pitti> ok, thanks
<Kamion> any objections to me removing the casper seed, which IMO is now obsolete? speak now or forever hold your peace ...
<siretart> doko: I have a package, which needs 'just' python2.x-twisted-bin, not the complete python2.x-twisted (and the zopeinterface). I notice that there is no dummy package 'python-twisted-bin', but just a 'python-twisted'. 
<tepsipakki> great! you seem to have hit the nail here, I just installed dapper and noticed that I got a bunch of unneeded locales ;)
<Kamion> tepsipakki: depends on your definition of "needed"
<tepsipakki> kamion: most of the en_* -stuff
<Kamion> I doubt that will change
<tepsipakki> because I preseed them
<tepsipakki> duh
<ogra> that wont go away, see above
<siretart> doko: I think it would be sensible to introduce a 'python-twisted-bin' dummy package to depend on the 'default python' twisted-bin package, so I don't need to maintain a patch for my package in ubuntu
<Kamion> Mithrandir: any chance of probing the framebuffer modules relatively early in casper startup, so that if you select a video mode other than plain VGA in the bootloader, you get to still see the startup?
<tepsipakki> ogra: hmm, I came in the middle of the discussion.. but do you mean that regardless what I tell the installer, I'm still going to get the default locales as well?
<ogra> tepsipakki, see option (a) Kamion talked about ...
<tepsipakki> but there are like twenty of them..
<tepsipakki> and all I need is one, plus fi* and sv*
<ogra> yes, i know :)
<tepsipakki> bugger
<CarlFK> https://wiki.ubuntu.com/MarksHoaryGoals "Nice To Have ... fax support" - Is there any more to this?  If not, I'll make a wiki page or something of "how to fax"
<tepsipakki> a regression to breezy
<tepsipakki> from..
<ogra> nope
<ogra> its aleays been like this ...
<ogra> *always
<tepsipakki> yes it is, I can install a breezy for you to see ;)
<tepsipakki> preseeded netboot
<Treenaks> CarlFK: we need it to be easy, like in other Oss
<tepsipakki> -install
<ogra> tepsipakki, we're talking about the default install 
<tepsipakki> ogra: yes, well I'm not ;)
<CarlFK> Treenaks: I thought I had seen a "fax printer driver" in some distro - probably FC2...   
<tepsipakki> ogra: but still at the moment the result is the same
<tepsipakki> but if it is known, I won't bother you ;)
<Treenaks> CarlFK: http://www.linuxprinting.org/cups-faq.html#q_2_15
<CarlFK> Treenaks: is anyone working on a faxing in Ubuntu ?
<Treenaks> CarlFK: not that I know of, but have a look at that link
<ogra> there is gfax+efax ...
<CarlFK> I want to help, just not sure where to start.
<Kamion> tepsipakki: breezy had the same code
<CarlFK> searched around and that Mark page was the closest thing I could find to someone doing something
<Kamion> although you're right that it shouldn't override preseeding; that's a bug
<tepsipakki> kamion: yes
<Kamion> (the comment in the code says "Always support English (unless preseeded otherwise)")
<Kamion> file a localechooser bug
<tepsipakki> ok
<tepsipakki> otherwise netboot seems fine, but the problem that network is not started at boot is a bit annoying ;)
<doko> siretart: the pythonX.Y packages for twisted will go away soonish anyway
<siretart> doko: can you give I timeframe? I want to decide if I should rather wait with an upload or fix it right away
<doko> siretart: this year
<siretart> doko: ok, then I'll wait. cheers!
<ogra> Kamion, what do you think about a preseeding option for fonts that supresses the fontconfig call in postinst ... so we could run fontconfig once in the end of the install instead of 10 times 
<ogra> installing the fonts is still the most slowing down part in the installer ...
<janimo> I have a library packaging question
<janimo> libgoffice can be built with or without gnome libs
<janimo> if I have two different debs with the two options
<janimo> can they have the same lib names provided the API is the same and only the impl details differ?
<janimo> also, I make the packages conflict each-other? add update-alternatives in the mix?
<janimo> alternatively there can be a libgoffice.so and a libgoffice-gtk.so
<janimo> and they can coexist on the system
<janimo> the latter option means a package which uses goffice( gnumeric) should explicitely say it builds agains one or the other
<janimo> and cannot just pick up the available one provided in build-deps
<janimo> if you know source packages which provide binaries like I described I'd go and study what they do
* janimo is wondering whether such block messaging wouldn't be more suited for mailing to u-d
<seb128> janimo: no
<seb128> janimo: we are not going to do that for sure
<janimo> seb128, I am talking about debian upstream
<seb128> same
<janimo> anyway the question was purely technical at this point
<seb128> 2 packages shipping the same lib file with different API is not going to happen
<janimo> did you read what I wrote?
<janimo> same API different impl
<seb128> what is "impl"?
<janimo> AFAIK libgoffice exports same api in both cases
<janimo> implementation
<janimo> only some are stubs or less featureful in non-gnome case
<janimo> how do tyou think gnumeric runs on windows?
<seb128> that's not the same ABI if the functions don't return the same objects
<janimo> you said API
<janimo> I did not look that close to see what ABI is
<janimo> but I assume is the same
<janimo> it is C no?
<seb128> why di you need 2 variants if that's exactly the same API/ABI?
<janimo> return NULL instead of a valid gnome object or something like that
<janimo> because one brings in friggin bonobo&co
<janimo> while the other does not
<janimo> and still works
<seb128> it if brings extra stuff the AB I is probably not the same
<seb128> ABI/API
<janimo> one uses glib_uri_from_display the other vfs
<janimo> the same objects in and out just different inside
<seb128> k
<janimo> if it were different API's I don;t think gnumeric devs would have done it in the firts place
<seb128> different API works fine
<seb128> you just have to #ifdef GNOME
<seb128> #ifdef GNOME
<seb128> code_path1
<seb128> #else
<seb128> code_path2
<janimo> yeah I know
<seb128> works pretty fine for a limited set of functions
<janimo> upstream packager of goffice and gnumeric said if I make the pacthes he'd take them
<janimo> but he personally won't
<seb128> JHM?
<janimo> so I am trying to make those patches and asked for advice not flamage 
<janimo> yes Ray Dassen
<seb128> there is no flamage
<seb128> but using alternatives for that would be the ugliest stuff ever
<janimo> I think current gnome lib dependency hell is way uglier
<janimo> many apps bring in the whole thing just for calling gnome_program_init instead of gtk_init
<janimo> _that_ is ugly and wasteful too
<seb128> if you are sure there is 0 API/ABI difference you can make 2 differents packages conflicting each other and Build-Depends on the right one
<janimo> but YMMV :)
<seb128> and I'm the one starting a flame...
<janimo> exactly what I did before asking if they can provide the same lib names
<janimo> so I made two debs with different names conflicting on eachother
<janimo> but the question is, if API is the same can they provide libs with the same name? 
<janimo> so libgoffice-gtk.deb provides goffice.so and libgoffice.deb does the same
<seb128> if the ABI and the API are the same
<seb128> ie: if you are *sure* they return the same object
<seb128> and have the same working logic
<janimo> same _type_ of object
<seb128> same logic too
<seb128> if one never returns NULL and the other do that's a difference of ABI
<janimo> well the interface is that matters not the internal logic right?
<eruin> infinity, I spoke too soon.. fixing dri == regular crashes ;)
<seb128> because the app can expected never getting NULL
<seb128> right
<janimo> yeah, if it does not check for null that's a bug not an API question :_
<seb128> but if the possible return values are differents that's an ABI difference
<janimo> right
<seb128> s/ABI/API/
<janimo> anyway I want to send this to debian, so whether he tales it or not you/gnome are not affected
<janimo> s/tals/takes/
<seb128> yeah
<seb128> that's just going to make extra duplication
<seb128> but we start beeing used to that
<janimo> upstream provides configurability
<janimo> why shouldn't debian take advantage?
<seb128> yeah, rhythmbox has a zillion of option
<janimo> I do not propose providing debs for all possible permutations of configure flags though :)
<seb128> we don't do 15 packages one with tag writing, one with cd recording, one with no feature, one with podcast, etc
<janimo> just two options : bloat and light
* janimo ducks
<seb128> as said if the Debian maintainer wants to go on this path up to him
<jsgotangco> night
<janimo> I'd like to have gnumeric just like abiword part of the default desktop
<pitti> Kamion: ok, 'locale-gen' and 'locale-gen de fr_FR.UTF-8 en_US' will now DTRT
<seb128> janimo: the default desktop has all the libs you call "bloated"
<pitti> seb128: that should also satisfy the 'generate additional locales' case
<seb128> pitti: cool :)
<seb128> pitti: do we keep the ability to let translator fix their locales for stuff like "start of the week is monday" with the new system?
<Riddell> fabbione: a question from KDE, will extattr be in the dapper linux?
<desrt> Riddell; they're in breezy....
<pitti> seb128: sure, we just need to update the locales package
<ogra> isnt it already ?
<pitti> seb128: it's easy now since it is a separate source
<seb128> pitti: "just"
<seb128> ok
<ogra> Riddell, you need to enable it in fstab afaik
<pitti> seb128: my start of the day is broken, too (starts on Tuesday ATM)
<Riddell> ogra: dunno, I'm just passing on the question :)
<fabbione> Riddell: extatrr?
<seb128> because we "just" needed to do that before too, but nobody wanted to take the responsability to changes locales stuff :p
<desrt> fabbione; filesystem extended attributes
<pitti> seb128: as soon as we have Rosetta integration of locales, we need to think about it again
<seb128> ok
<pitti> seb128: but in general, updating langpack-locales source is easy
<ogra> fabbione, he maeans the user_xattr mount option ...
<fabbione> we already have them enabled..
<desrt> Riddell; just toss 'user_xattr' in t... ya.  what he said :)
<ogra> :)
<fabbione> i dunno.. 
<jsgotangco> good night
<Kamion> ogra: preseeding would be inappropriate there; there's another better option which I already know how to implement, and will do as soon as I have time to test it
<Kamion> ogra: namely diverting fc-cache during base-config
<Kamion> pitti: great, thanks
<ogra> Kamion, ah, great :)
<Riddell> infinity: no new ubuntu-artwork?
<pitti> Kamion: I explained the changes and the potential dist-upgrade breakage in an u-d-a mail
<dholbach> have a nice evening guys :)
<ogra> it always bothered me that it takes so much time :)
<ogra> dholbach, have fun playing with the ar :P
<ogra> *car
<dholbach> oh yeah, thanks - enough time to play :)
<ogra> heh
<sivang> ogra: dholbach got a new car?
<Kamion> tepsipakki: why do you set the owner of localechooser/supported-locales to be base-config? that's just bizarre :)
<Kamion> not that it actually matters, but
<tepsipakki> hum
<tepsipakki> wait
<tepsipakki> it was from some example, I think
<Kamion> "d-i" is the usual owner for anything in the first stage
<tepsipakki> seems that the "d-i" version gets preseeded by the one I'm using..
<tepsipakki> but I'll change it
<Kamion> it just sets the owner in the debconf database, it's not a different namespace or anything
<tepsipakki> okay
<tepsipakki> base-config is not yet obsoleted for dapper? I remember that Joey intends to get rid of that phase
<Kamion> not quite yet, no
<Kamion> I'm not yet sure whether it'll land for dapper, although I hope it will
<Kamion> I've been fairly involved with a lot of that upstream
<tepsipakki> cool
<tepsipakki> no news regarding preseeded LVM-setups ?
<Kamion> no
<Kamion> well, that's not quite true, Fabio's been doing some work on things that would be needed for that, but AFAIK it's not remotely all there yet
<tepsipakki> yes I saw the upstream changelogs, but couldn't quite parse all of it
<Kamion> it's been more about adjusting the existing recipes to play more nicely with LVM
<fabbione> Kamion: doesn't preseeding just pre-answer the debconf questions?
<fabbione> and set them in a way that won't be asked?
<fabbione> or the pkg itself needs to take care of that?
<Kamion> fabbione: it just pre-answers, yes
<fabbione> Kamion: ok, than i don't see what i need to do differently.. really.. i do ask debconf questions like any other d-i package in this world.
<fabbione> meh.. tepsipakki 
<fabbione> the same way you preseed partman-auto, you can preseed -lvm
<Kamion> fabbione: no
<Kamion> fabbione: the problem with complicated partman preseeding is that doing stuff like LVM and RAID in partman involves a control loop, where d-i asks the same question more than once and you need to provide different answers
<fabbione> ahhhhh
<fabbione> ok
<fabbione> i understood partman-auto-lvm
<fabbione> not just LVM
* fabbione shuts up
<Kamion> normal partman preseeding basically works around this, by providing a mechanism where you can specify a single recipe that describes in one go what partman needs to do
<Kamion> in order to make LVM preseeding work, we need to allow the recipe format to describe a full LVM partitioning scheme
<fabbione> yeah i understand what you mean
<fabbione> sorry i was out of context
<tepsipakki> I tried to debug this a month ago (?), and we talked about it then
<fabbione> no, there is no plan for me to work on making that to work
<fabbione> my target was only partman-auto-lvm
<tepsipakki> how hard would it be for me to make it?-)
<Kamion> tepsipakki: you'd have to fully grok the design of partman recipes
<tepsipakki> gah
<Kamion> and then work your way through some somewhat arcane shell code
<Kamion> but I'm sure it would be possible
<Kamion> it's not rocket science, just messy :)
<seb128> Kamion, infinity, lamont: could you give a buildd retry on dbus/amd64?
<janimo> seb128, when I meant default desktop 50 minutes ago I meant xfce desktop not gnome
<seb128> janimo: I figured :)
<janimo> :)
<slomo_> infinity / lamont: please give-back gst-plugins-base0.10 on x86 and after it built gstreamer0.10-ffmpeg everywhere... thanks :)
<janimo> infinity/lamont same for xubuntu-default-settings, thanks
<seb128> slomo_: how does base require ffmpeg?
<seb128> slomo_: other way probably no?
<seb128> oh, I misread
<seb128> :)
<ogra> hmm, dholbach didnt fix the broken firefox upload ? 
<slomo_> seb128: ok :)
<seb128> ogra: which one?
<ogra> seb128, amd64 is ftbfs 
<seb128> oh
<ogra> due to libssl it seems
<Kamion> hmm, ubuntu-desktop uninstallable on all arches again
<ogra> oops, why ?
<Treenaks> totem
<Kamion> you can find out about as quickly as I can
<ogra> i only see totem ...
<Treenaks> at least, on amd64 it's totem (= 1.2.1) vs 1.3.x
<ogra> but not on all arched
<Kamion> http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html, as usual
<ogra> arches 
<Kamion> people should bookmark that :)
<ogra> heh, i'm to lazy, i always look at cdimage, so i can check the CD sizes with one look
<ogra> phew, thats a lot
* ogra bookmarks
<Kamion> ah, hal needs to switch to the new dbus
<seb128> right
<seb128> it breaks half of the world
<seb128> pitti said he wants to try before uploading but new dbus hasn't built yet on amd64
<Kamion> doesn't help that it FTBFS on amd64/powerpc
<seb128> and he went to bed for today anyway
<Kamion> can a mono person please look at these build failures?
<seb128> Kamion: a retry on amd64 should do the try (I've asked so some time ago)
<seb128> s/try/trick/
<Kamion> ok, will do now
<Kamion> how about powerpc?
<seb128> according to slomo_ that's a mono issue
<seb128> slomo_: dbus/ppc? :)
<slomo_> dbus ppc will work soon
<Kamion> dbus/amd64 given-back; I'm off for dinner
<seb128> thanks
<slomo_> but for mono... no idea, upstream knows about it and rated the bugreport "minor" *sigh*
<ptlo> i don't know if its the right chan, but just a quick questions - if i'm translating breezy packages in rosetta now, will [or, can at all]  the translations be transferred to dapper, or should i just go ahead and translate just dapper?
<toresbe> ptlo: This is an unqualified guess, but I believe the strings that are identical are carried through
<toresbe> WHOA.
<toresbe> what just happened there
<eruin> ?
<toresbe> Sorry, had a kernel..happening all over my terminal
<ptlo> yeah....that's the [educated guess]  reply that i've got on other channel too. i'm just wandering, how and wen the transfer is done - since, for example, right now i can modify both breezy and dapper translations - so at some point, breezy ones will have to overwrite dapper ones
<toresbe> complete with a call trace etcetera. Thought I was in a different channel
<ptlo> i'm afraid the kernel cares little about on which particular irc channel you chat at the moment ./
<Kamion> ptlo: if you want an authoritative answer you'd need to ask #launchpad
<ptlo> oh, that's the place. thanks, i tried #rosetta, but i was pretty lonely there .-] 
<Kamion> hmm, I'm getting a segfault in the gtkmozembed python module; does it need to be rebuilt for firefox 1.5?
<seb128> no, it needs to be debugged
<seb128> I think mvo did some debugging on it and said it's a firefox bug
<seb128> mvo?
* mvo just returned from dinner
<mvo> Kamion: yes, firefox bug, happend after the ff 1.5 upgrade
<mvo> Kamion: #20338 has a test-case and backtrace etc
<slomo_> lamont / infinity: can you give me hardware details about the ppc buildds? mono upstream asks for it...
<mvo> slomo_: what do you need?
<infinity> Is it so difficult to figure out what changed between mono 1.1.10 and 1.1.11 that made it stop failing?
<infinity> Anyhow, the buildds are all Apple Xserve Dual G5s, running ppc64 kernels, but the builds happen in a "linux32" environment, so from the build perspective, it should appear as a normal ppc32 system.
<slomo_> infinity: it's between 1.1.10 and 1.1.10.1... they say there were only few changes, nothing that could cause it... and it works fine on osx with a smp g5 running 32bit userland
<slomo_> infinity: ok, thanks :)
<infinity> And no, we definitely will NOT hand-compile binaries (especially not stuff that's in main, it's just not supportable in the least)
<infinity> So, if it's a problem with the buildd configs, we need to figure that out, if it's a problem with upstream's code (more likely), we need to fix that.
<infinity> The fact that it just built fine on my ppc32 system isn't really all that useful to know. :)
<slomo_> infinity: mvo reproduced it on another ppc64 with 32bit userland
<mvo> slomo_, infinity: actually I reproduced it on "davis", one of our machines. not sure how much that counts :)
<janimo> infinity, can this be unstuck somehow? http://people.ubuntu.com/~lamont/buildLogs/x/xubuntu-default-settings/0.2/
<infinity> mvo : Counts fine, since it eliminates gcc-opt and other fun as the possible cause.
<infinity> mvo : So, it could still be a bug in our userland (gcc, glibc, who knows), but definitely not a bug specific to the buildds.
<mvo> infinity: right. I'm building 1.1.10 on the same machine/config that 1.1.10.1 segfaulted on now
<infinity> janimo : I gave it a whack just a while ago.
<Robi-> anyone have a shuttle sff pc with those usb wifi cards built in?
<janimo> infinity, thanks
<infinity> mvo : Thanks, dude.
<Robi-> the PN15 or AirVast card doens't get detected properly by prism2_usb
<infinity> Rob- : Haven't you been in and out, complaining about this for the last day or two?
<mvo> woah, segfault for 1.1.10 as well
<slomo_> infinity, mvo: thanks for your time :)
<infinity> Robi- : I'd recommend filing a bug.
<zul> Robi-: can you please open a bug..kthxbye
<mvo> ^--- slomo_ 
<slomo_> mvo: uh... so let's look what changed in that month...
<Robi-> no i've been trying to find a solution
<mvo> slomo_: http://paste.ubuntu-nl.org/5963
<infinity> mvo : dpkg -l gcc-4.0 libc6-dev linux-kernel-headers binutils
<slomo_> mvo: yes, seems to be the same...
<mvo> infinity, slomo_ http://paste.ubuntu-nl.org/5964
<infinity> That's davis?
<infinity> That chroot is way out of date.
<infinity> Which is helpful in this case.
<mvo> yes, davis
<infinity> The only thing different between that chroot and the chroot where 1.1.10 built successfully is libc6.  libc6-dev_2.3.5-1ubuntu15 versus libc6-dev_2.3.5-1ubuntu16
<infinity> Which would be a useful data point, if libc6's changelog mentioned anything at all about powerpc between 15 and 16... :/
<tseng> yay for clues
<slomo_> and 15 and 16 are nowhere anymore :/
<janimo> is dbus-1-1 going to stay around too or everything gets rebuilt
<mvo> janimo: everything will be rebuild
<tseng> slomo_: snapshot?
<janimo> mvo, and for apps which are still using 0.50 do we fix them?
<slomo_> infinity: no kernel changes between 24.11. and 15.12.?
<infinity> slomo_ : Nope.
<janimo> or is 0.60 backwards compat?
<mvo> janimo: yes, it's mostly a rebuild. only rhythmbox gave us a bit of trouble
<janimo> just want to know if it's time to rebuild/upload some packages
<mvo> but nothing can give you real trouble if seb128 is around :)
<seb128> ah ah
<slomo_> infinity: ok, glib has changed since then too... and mono uses glib (2.8.X to 2.9.0)
<seb128> don't blame GTK
<seb128> you .... freak!
<tseng> iz glib boog
<mvo> haha
<slomo_> seb128: i don't blame anyone :P i only search for relevant changes in that timeframe
<janimo> is this a mono/glib thing FTBFS or runtime breakage?
<tseng> ftbfs on ppc
<tseng> (64?)
<slomo_> tseng: on a normal ppc it works fine... at least for me
<janimo> link or exact package name?
<janimo> a mono 1.1.12?
<tseng> source is 'mono'
<infinity> slomo_ : Did glib change between 1.1.10 and 1.1.10.1?
<slomo_> infinity: yes
<infinity> slomo : Ahh, maybe we're poking too low-level then.  Might not be toolchain breakage at all, might be glib...
<janimo> oh, FTBFS but because of mono runtime errors
<infinity> mvo : What's the version of glib stuff on davis?
<janimo> i.e not a gcc error but a mono compiler thing
<tseng> i find it unlike that glib has odd arch specific breakage in a point release after all this time
<mvo> infinity: 2.9.0-0ubuntu1
<seb128> tseng: it's 2.8 to 2.9
<seb128> tseng: so not a point
<tseng> huh ok
<infinity> tseng : Also, weirder things have happened.
<infinity> Maybe glib is doing Very Bad Things in this release...
<tseng> this is true
<tseng> i would be pretty happy if it wasnt mono :)
<infinity> It could still be toolchain breakage, though (binutils breaking glibc, or somesuch), but I do like the "blame glib" idea better.
<jbailey> Strangely enough, so do I. =)
<slomo_> hehe
<infinity> I'll have to dig up some old glib sources and rebuild it to test the theory.
<jbailey> I think we have concensus.
<seb128> grrrrr
<jbailey> seb128: You're just bitter because it starts with "g"
<jbailey> =)
<seb128> not really, glibc would start with a g too
<seb128> and curiously I would not grrrrr to it :)
<jbailey> seb128: Right, but I thought you were taking that from me? =)
* jbailey hides.
<mdke> is there a new kernel coming?
<seb128> jbailey: nah
<mdke> a post on a bug report yesterday said to test with a new kernel, but one hasn't appeared...
<seb128> 5049 ?
<seb128> (aka eject bug)
<mvo> everyone knows that everything starting with "g" is a seb package
<Kamion> mdke: already in the archive
* mvo prepares a gapt upload
<mdke> Kamion, hmm *looks*
<Kamion> (since this morning)
<mdke> Kamion, i don't see it on gb.archive
* mdke tries another
<Kamion> gb.archive is master
<Kamion> and it's there
* mdke doesn't
<Kamion> 2.6.15-9
<mdke> perhaps I'm missing a metapackage
<Kamion> linux-meta hasn't been updated yet
<mdke> ahhh
<mdke> thanks Kamion 
<mdke> hope your cold is better!
<Kamion> marginally :-/
<mdke> jack the old vitamin C
<infinity> mdke : linux-meta wont's be updated until an amd64 header problem is resolved.
<mdke> infinity, no problem. Did you test the new kernel on that ata2 error?
<infinity> mdke : Not yet, no.
<infinity> mdke : it's 7am, give me a break. ;)
<mdke> lol
<mdke> fair enough
<seth_k|lappy> seb128, ping
<seb128> seth_k|lappy: pong
<infinity> Kamion : Care to NEW LRM on !amd64?
<mvo> ping Riddell 
<Riddell> mvo: hi
<slomo_> gn8 everybody
<seb128> 'night slomo_
<seth_k|lappy> hi seb128 :) I was wondering if you would poke libgpod 0.3.0 into main for me, because gtkpod 0.99 requires it and I was hoping to get that in. In case you don't want to do it yourself, I posted it here: http://revu.tauware.de/details.py?upid=1252 (it drops the patch you added earlier since it is incorporated upstream, but makes no other changes)
<seth_k|lappy> seb128, I thought I would talk to you since you seem to care for that package
<seb128> seth_k|lappy: I'll update, I didn't notice there was a new tarball
<seth_k|lappy> thanks :)
<seb128> yeah, rhythmbox uses it
<seb128> time for dinner now but I'll do that after it
<seth_k|lappy> i appreciate it
<Kamion> elmo: can you do l-r-m? you probably have more of the finger-macros for it than I d
<Kamion> do
<elmo> k
<Kamion> ta
<pitti> elmo: can you please sync sysfsutils from debian/incoming?
<elmo> pitti: no - not unless it got uploaded in the last 20mins; it's in limbo between incoming and the archive
<infinity> elmo : Oh, hi.  Not used to you being awake at the same time as I am, or I would have sent that NEW request to you. :)
<pitti> elmo: ah, ok.
<ogra> oh, Riddell, thanks for the edubutnu-artwork fix ...
<Riddell> ogra: I updated all of them, wonder if there's an xfce one to do yet
<ogra> i think so ...
<ogra> janimo will know
<janimo> yes, xubuntu-docs is still in NEW
<janimo> I am just dling kubuntu-docs to get an example of how u-a is done
<janimo> and when it get into dapper I'll fix it
<mdke> Riddell, did you do the joint source thing for (k)u-docs?
<Riddell> mdke: no
<mdke> ah, i saw some cool-looking stuff happening in there
<mdke> has anything changed for the purposes of the ubuntu-docs packaging?
<Riddell> nope
<Riddell> but I did the serverguide with froud's KDE stylesheet and xsltproc
<Riddell> so we'll just have to have it uncompressed and not looking the same as the rest
<mdke> Riddell, how different are they?
<Riddell> very
<mdke> oh dear
<mdke> Riddell, so how did you get it working without the external? you've moved some stuff into trunk/debian?
<Riddell> mdke: no I just move kubuntu/debian to a directory below for the packaging
<mdke> Riddell, ahh. but you have definitely added some stuff to trunk/debian in the repo
<Riddell> mdke: that's for the update-alternatives
<mdke> Riddell, hope you don't mind explaining this stuff to me, I'm a bit of a thick with this stuff: what is update-alternatives?
<Riddell> mdke: we have the issue of clashing index pages for firefox
<Riddell> so we're using update-alternatives to set up a symlink in /etc/alternatives to the one in {ubuntu,kubuntu,edubuntu}-docs
<mdke> Riddell, ah nice one!
<mdke> Riddell, is that a temporary or long-term solution?
<mdke> i was discussing with diziet recently the possibility of shipping translated firefox html pages with ubuntu-docs, along with the english one 
<Riddell> mdke: it's a solution until something better comes along
<Riddell> mdke: any ideas on how to do that?
<mdke> Riddell, the translations?
<mdke> https://wiki.ubuntu.com/DapperFirefoxStartPageTranslation
<janimo> Corsac, so you consider exo/terminal and xfmedia ready to upload by one of the DDs?
<janimo> mvo, if a package b-depends unversioned on libdbus-glib-1-dev it just needs a rebuild? no other changes in the control file?
<mvo> janimo: I added libdbus-glib-1-dev >= 0.60 as well to make sure the rebuild picks the right version
<janimo> ok so if package had no version I'd better change that too?
<janimo> so no build1 but ubuntu1 ?
<mvo> yes, I think that is appropriate
<janimo> ok
<seb128> jbailey: ping?
<mdke> Kamion, you didn't have a chance to have a look at the ubuntu-docs upload to breezy-updates did you?
<Kamion> mdke: oh, no, sorry :(
<mdke> Kamion, only an 8.5MB debdiff...
<Kamion> I wasn't planning on reading every line anyway. :)
<jbailey> seb128: pong
<Kamion> I'm scanning it now
<seb128> jbailey: you said to dholbach that totem should not force the current-version on totem-*?
<jbailey> seb128: No, I asked him why it did. =)
<seb128> I did that so apt-get install totem update the real package too
<Kamion> mdke: does it require any changes to kubuntu/edubuntu?
<jbailey> I was curious since i386's breakage keeps me from testing the upgraded version on ppc.  I was curious what the tight depends served.
<jbailey> seb128: Maybe make it >= ?
<seb128> would not make a difference
<mdke> Kamion, it shouldn't, but it wouldn't hurt for me to double check with Riddell 
<jbailey> Yes.  That would solve both our problems.
<seb128> you mean >= current_upstream?
<jbailey> No, the built package version.
<seb128> how would that solve it?
<Riddell> kubuntu-docs are separate from breezy and don't have any translations
<seb128> you would get totem arch all first
<seb128> requiring a totem-gstreamer you don't have yet
<jbailey> It would force upgrades when it got upgraded, and also let totem-gstreamer be newer when i386 FTBFS'd but ppc didn't.
<mdke> Riddell, would an update to ubuntu-docs (text and css changes to the firefox homepage) hurt?
<Riddell> mdke: what's the change to the firefox homepage?
<jbailey> seb128: It's not really a problem that's worthy of this much discussion.  It was just something that came up since totem-gstreamer hasn't been installable for me for a couple of days.
<jbailey> seb128: No big deal, really. =)
<Riddell> I believe that is broken is breezy, maybe we should change kubuntu-docs for that too
<seb128> jbailey: totem-gstreamer is not installable?
<jbailey> seb128: right, because totem is too old.
<seb128> jbailey: should be the other way, totem is arch all, it's built first
<mdke> Riddell, change to the body of the text, and the css, which is up a directory
<seb128> jbailey: I don't get how that can happen
<jbailey> seb128: Mm, no.  It's built by whatever arch the buildd admins feel like building it on.
<jbailey> seb128: Right now, that's i386
<jbailey> So when i386 FTBFSs, you don't get the updated arch: all package.
<Kamion> mdke: it'd be nice in dapper to ensure that all the HTML files were autogenerated at build-time, rather than huge clearly-autogenerated files being in the source package ...
<seb128> jbailey: right, that's the symetric of the common breakage
<mdke> Kamion, we ship the xml too, but yeah, clearing stuff out of the source package has already been partly implemented in dapper
<jbailey> seb128: Right.
<seb128> jbailey: usually i386 build fine so you get the issue on other arches :)
<ogra> Riddell, the switch to the alternatives system should avoid such breakage in the future
<jbailey> seb128: So in this case, it built on ppc, not on i386.
<Kamion> mdke: great
<seb128> jbailey: that doesn't prevent you to install current totem-gstreamer
<jbailey> seb128: Since I test ppc more than most people I looked to see why it wasn't installable.
<jbailey> seb128: totem won't install beside it.
<jbailey> seb128: And so it wants to uninstall totem, and uninstall ubuntu-desktop
<seb128> right
<mdke> Riddell, i don't see a reason it should cause a problem (that isn't already present), but if you think it's worth testing the package, it's at http://doc.ubuntu.com/debs/breezy-updates
<ogra> oh, its about a breezy-update ...
<mdke> yeah
<ogra> hmm...
<ogra> that will break edubuntu as well i think ... so i should push an update as well ? 
<mdke> ogra, why will it break?
<mdke> just the very fact of having an update?
<Kamion> it doesn't *look* like it'll break
<daniels> if it compiles, ship it
<ogra> Kamion, i didnt use dpkg-divert 
<mdke> the changes won't break anything, i'm pretty confident
<Kamion> unless you're relying on the file name /usr/share/ubuntu-artwork/home/aboutubuntu.css
<Kamion> (are you?)
<ogra> nope
<Kamion> since that moves to /usr/share/ubuntu-artwork/ubuntu.css
<mdke> Kamion, that's replaced by /usr/share/ubuntu-artwork/ubuntu.css
* mdke nods
<Kamion> ogra: what aren't you diverting? :-)
<mdke> it's called by -artwork/home/index.html
<Kamion> as in, how do your package and ubuntu-docs interact?
<ogra> Kamion, index.html
<Kamion> but that's in /usr/share/edubuntu-artwork/
<ogra> i moved the index.html to inde.html.orig (i know its wrong, dont rant) and linked the index.html to mine ...
<mdke> that file will still be there after the update though
<Kamion> you do? the package seems to use update-alternatives
<ogra> you said you change the contents in index.html ...
<Kamion> oh, that's in dapper
<ogra> Kamion, nope, its doesnt
<ogra> yup
<mdke> ogra, yeah the contents, but the place doesn't change
<Kamion> oh MY GOD
<Kamion> ok, that will fuck up in ways I cannot immediately imagine
<ogra> nozt if i also push an update ...
<mdke> eh? :(
<Kamion>       if [ ! -e /usr/share/ubuntu-artwork/home/index.html.orig ] ; then
<Kamion>         mv /usr/share/ubuntu-artwork/home/index.html /usr/share/ubuntu-artwork/home/index.html.orig
<ogra> mdke, you will overwrite my symlink with your file 
<Kamion>       else
<Kamion>         rm /usr/share/ubuntu-artwork/home/index.html
<Kamion>       fi
<Kamion>       ln -s /usr/share/edubuntu-artwork/home/index.html /usr/share/ubuntu-artwork/home/index.html
<mdke> oh bloody hell
<Kamion> does kubuntu have this brain-damage too?
<ogra> nope
<ogra> they use a broken dpkg-divert 
<daniels> hold on
<daniels> so you only ever copy it once
<ogra> yup
<daniels> so you keep a very old copy around
<ogra> but the symlink will be overwritten on update
<ogra> so people will suddenly see the ubuntu content
<Kamion> ogra: your alternatives hack in dapper is broken too
<Kamion> oh, hmm, need to check ubuntu-docs in dapper
<ogra> Kamion, i didnt do that 
<Mithrandir> Kamion: re loading fb modules in the casper startup, sure.
<Kamion> but at the very least it looks like it needs a bit more smooth upgrade handling
<mdke> so is there anything that can be done about this?
<ogra> Kamion, and edubuntu-artwork is still pending locally for dapper i didnt do an upload yet
<ogra> mdke, yes
<ogra> mdke, i need to push an update afetr yours
<mdke> use a different file for edubuntu?
<Kamion> ogra: before, not after
<Kamion> we need an edubuntu-artwork upload that removes this awfulness and does something less broken instead
<Kamion> a divert would do fine
<ogra> Kamion, but then i have to change the whole ...
<xhaker> can elmo do universe packages synch from debian (of course)?
<ogra> an update afterwards wont need any changes
<Riddell> xhaker: yes
<Kamion> ogra: we may want to make other ubuntu-docs uploads to breezy, and we cannot have them blocked on edubuntu-artwork changes in this way
<Riddell> Kamion: I've just done that upload
<ogra> xhaker, ask a motu for it in -motu
<ogra> Kamion, ok
<Riddell> in dapper
<Kamion> Riddell: sorry, which upload?
<xhaker> ogra, already tried that nobody seems to know who should do something
<ogra> Kamion, *-artwork
<Riddell> Kamion: make edubuntu-artwork use update-alternatives in dapper
<Kamion> Riddell: yes, but we need a divert in breezy
<xhaker> it looks like the packages are simply sinched from debian unstable
<Kamion> Riddell: we're discussing a breezy-updates upload here
<Riddell> right
<Kamion> xhaker: if the package hasn't been modified in Ubuntu, then there's no need to talk to anyone; syncs will happen semi-automatically
<ogra> Kamion, mdke is it enough if i do that tomorrow morning ? 
<Kamion> (until upstream version freeze)
<mdke> ogra, sure
<ogra> oki
<Kamion> ogra: fine by me
<Kamion> other than that the ubuntu-docs upload is fine by me
<mdke> thanks
<fabbione> night fellas
<mdke> ogra, lucky you were around :)
<ogra> Riddell, you should probably fix the broken breezy -artwork alongside as well 
<xhaker> Kamion, -1 in ubuntu -6 in unstable :( libswt3.1-gtk-java depends on mozilla-browser on dapper, on debian unstable it depends on mozilla-firefox | mozilla-browser
<ogra> mdke, i read breezy-changes, i'd have noticed it :)
<Riddell> ogra: that would mean changing kubuntu-docs and ubuntu-docs as well (which might not be a bad idea)
<mdke> ogra, hasn't it been on breezy-changes already?
<ogra> Riddell, they want to upload ubuntu-docs ...
<mdke> ogra, yeah, it arrived on saturday :D
<mdke> *friday
<ogra> yes, friday 
<ogra> oh, damned .. 
<Kamion> xhaker: libswt3.1-gtk-java | 3.1.1-1ubuntu3 | dapper/universe | all
<Kamion> xhaker: modified in Ubuntu, needs a manual merge, not a sync
<Kamion> unless the result of the merge is to ask elmo to sync it and overwrite the Ubuntu changes
<xhaker> gonna check the changes then
<Kamion> ogra: I don't want major structural changes to ubuntu-docs in breezy-updates, just fixes to the current arrangement
<ogra> Kamion, yup, i'll just remove the linking and moving and add a dpkg-divert
<xhaker> Kamion, should'nt that package have a changed-by line?
<ogra> xhaker, yes, in the changelog
<infinity> ogra : If you use dpkg-divert, you'll need to conflict with kubuntu-docs
<ogra> gah
<infinity> ogra : Two packages can NOT divert the same file twice, or dpkg will scream at you.
<ogra> thats bad 
<mdke> is it?
<mdke> people run kubuntu and edubuntu together?
<ogra> since some edubuntu users ant to install kubuntu-desktop
<mdke> argh
<ogra> *want
<ogra> sure
<sistpoty> elmo: please sync openrpg and lxml from unstable, ubuntu override ok. thx
<ogra> as users run ubuntu-desktop and kubuntu-desktop together
<infinity> ogra : This is precisely why things needed to be changed to use alternatives.
<xhaker> oh.. doko is the one
<ogra> infinity, but that wont help us in breezy :/
<Kamion> oh, argh
<infinity> ogra : The only way in breezy to make it all right is to switch to alternatives there too.  And test it very heavily before uploading.  With all possible package combinations and upgrade scenarios.
<Kamion> ok, I guess we have to go to alternatives then
<mdke> oh bloody hell
<infinity> ogra : If that's too scary, then leaving things broken is the best option.
<ogra> sigh
<mdke> can you use my source for ubuntu-docs if you need to amend that?
<ogra> mdke, is that using alternatives in breezy ? 
<ogra> i dont need -docs ... 
<infinity> No.  Nothing in breezy used alternatives.
<mdke> no
<ogra> its only this one file i have in breezy
<infinity> ubuntu-docs installed the canonical file, kubuntu-docs diverted it, edubuntu-docs did a horrible evil hack.
<ogra> yup
<jdong> Anyone have experience with audio programming?
<mdke> ok let's think this through
<mdke> is the amount of evilness needed to fix this worth the change to the aweful breezy css for the browser home page?
<mdke> the text changes are definitely not uber-important
<infinity> mdke : It's not so much the ubuntu-docs update that's a problem as the edubuntu-docs package being broken in general.
<Kamion> mdke: it doesn't matter whether you change the file or not - any ubuntu-docs upload will break it
<ogra> i dont care about the css ...
<mdke> oh hang on... any update is gonna break it
<ogra> yes
<Kamion> and I think that's unacceptable and needs to be fixed for supportability
<mdke> we definitely need _an_ update :)
<Kamion> so I don't think we can leave it the way it is
<Riddell> so lets update!
<Riddell> I'm happy to do it all if people want, or we can split the work
<mdke> as long as you use the new source for ubuntu-docs, I'm fine with whatever you guys want to do
<Kamion> might want to put the source package somewhere public
<ogra> switch to alternatives completely and be prepared for breezy->dapper in a clean way 
<infinity> The only other option (apart from switching to alternatives, which is correct, but intrusive) is to upload an edubuntu-docs that removes the horrible symlink hack, and leaves edubuntu-docs crippled, without a start page.
<mdke> Kamion, http://doc.ubuntu.com/debs/breezy-updates
<Kamion> good, thanks
<ogra> infinity, so it wouldnt need any update ...
<Kamion> infinity: regressing Edubuntu kind of sucks if we can avoid it, though
<infinity> ogra : Yes, it would, to get rid of the postinst-from-hell.
<mdke> lol
<infinity> Kamion : Agreed.  But testing "broken situation -> clean alternatives situation" is effort, that's all.  If people are up for it, yay.
<ogra> infinity, removing edubuntu-docs would only revert the ubuntu index.html file 
<infinity> ogra : Which would also be wrong.
<ogra> infinity, sure ... 
<Kamion> infinity: for a stable release update, I think we have to put in the time :-/
<sistpoty> infinity: could you eventually help me with bootstrapping fpc (freepascal)? 
<mdke> is there any other way I can help, or can I leave it with you til tomorrow evening?
<infinity> sistpoty : Maybe, but the way my TODO looks for the next few days, it may not be until after Christmas.
<sistpoty> infinity: ok, then I'll ping you again after christmas?
<infinity> sistpoty : Sounds fair to me.  Write yourself a note. :)
<sistpoty> infinity: will do... thx :)
<ogra> mdke, Riddell and me will sort our docs until tomorrow for you, then ubuntu-docs should be fine ...
<Riddell> who will do ubuntu-docs?
<infinity> ogra / Riddell : Can you two ping me when you have source packages prepared, and I'll have a look at them?
<ogra> infinity, yup
<ogra> Riddell, oh, good question ..
<infinity> Riddell : If you can do ubuntu-docs too, I'll look at what you have and mangle it further.
<seth_k|lappy> seb128, hmm, I noticed you updated libgpod to .20 ubuntu3, will you have time to do .30 today or should I hold off on gtkpod?
<Riddell> ok, I'll do it based on mdke's update
<infinity> Riddell : I've got about 12 days of work to do, and 3 days to do it in, so I'm delegating like a mofo.
<mdke> Riddell, rock thanks
<mdke> Riddell, if I can help on anything, mail me?
<seb128> seth_k|lappy: I uploaded this one before you pinged me, I said I will update today, a bit of patience please
<seth_k|lappy> seb128, np, I just wasn't sure if there was a miscommunication. sorry to bother, just was planning my day
<seb128> seth_k|lappy: I'm on it right now, I've just downloaded the tarball
<infinity> ogra / Riddell : Just keep in mind that I don't have access to the -updates queues (well, I do as buildd admin, but I don't REALLY, so ignore that), so while I'm playing Kamion on vetting these packages, you'll need to ping and make stuff downloadable for me.
<ogra> oki
<ogra> thats what rookery is for :)
<infinity> <nod>
<mdke> does someone need to bitch slap the current ubuntu-docs out of the updates queue?
<mdke> Kamion, ^
<Kamion> mdke: no, I think it can be left there until the rest is resolved
<mdke> ok
<mvo> janimo: thanks for uploading the xfce dbus packages
<janimo> mvo, np :)
<janimo> they are in universe
<janimo> I thought you take care for main only no?
<janimo> Kamion, does casper need to be removed form the live seed too?
<janimo> since the file itself is gone
<mvo> janimo: yes, usually
<seb128> infinity: could you give a retry to firefox on i386?
<Kamion> janimo: no?
<Kamion> janimo: the casper package still exists
<infinity> seb128 : If you ask nicely.
<Kamion> and is essential for the live CD build process
<Kamion> I nuked the casper *seed*, but that's different
<seb128> infinity: pleeeeease? :)
<janimo> Kamion, ok . I did not quite get from the seed bzr logs how much casper gies away
<janimo> goes
<Kamion> ah, need to update STRUCTURE though
<infinity> seb128 : ;)
<Kamion> janimo: entries in seeds don't include other seeds, which seems to be part of your confusion
<janimo> probably
<Kamion> janimo: the casper seed was the old d-i-based live CD infrastructure
<janimo> and the live seed?
<janimo> old as in hoary or breezy?
* infinity really needs to figure out this ldd segv on amd64/firefox builds.
<ogra> is it still there ? 
<ogra> i thought i saw a doko upload for it
<infinity> It's still there.  And completely unreproducible outside sbuild.  My favourite.
<ogra> heh
<xhaker> doko, you there?
<infinity> janimo : "old" as in "up until last week"
<janimo> :)
<janimo> night all
<infinity> janimo : The live seed is stuff that gets installed in the live filesystem (livefs is base+desktop+live+kernel)
<infinity> mvo : Have you decided to play MOTU for the day, or are you just a liferea user, and thus annoyed by it not transitioning yet? :)
<mvo> infinity: I wanted to see what it feels like to be a MOTU
* mvo hasn't noticed any superpowers so far
<mvo> also no fur or swords
<seb128> mvo: keep your superpowers for the hug day tomorrow
<mdke> use them for evil!
<mvo> SUPER HUG POWERS
* seb128 hugs mvo
<mdke> bah
<mdke> you guys can't be corrupted
<infinity> mvo : No giant cats in armour either?
* mvo superhugs seb128 
<Riddell> mdke: http://doc.ubuntu.com/debs/breezy-updates not working for me
<mdke> Riddell, i'll take a look
<ogra> yes, same here 
<mdke> Riddell, our server is not powerful enough for all the hits it gets i think, it goes down a fair bit
<mdke> Riddell, working now
<mdke> albeit ridiculously slowly
* StevenK wonders if libwwn6-{1,dev} are in NEW.
<StevenK> Since I have no idea where NEW is ...
<daniels> it's on jackass
<StevenK> But, being NEW, I suspect I have no access to it.
<mvo> infinity: I'm sure I look gorgeous in a leather armour :P
* mvo has played enough motu for today
<Kamion> StevenK: yeah, it's in NEW
<StevenK> I thought so. Neat how I don't get notified.
<Kamion> are you not whitelisted?
<jdub> morning StevenK 
<StevenK> I am.
* StevenK waves.
<infinity> StevenK : Didn't get notified for new source, or new binaries?
<Kamion> oh, new binaries you won't get notified
<infinity> StevenK : You won't get notified for binaries, since it's the buildd that uploaded them, not you.
<StevenK> Right.
<StevenK> Yeah, but I've been waiting for them, since then I can just build xemacs and the world can stop ending.
<StevenK> Or something.
<infinity> Upload xemacs with versioned build-deps, and let it sort itself out.
<Kamion> StevenK: could you use dpkg-{buildpackage,genchanges} -vLASTVERSIONINUBUNTU for merge uploads, please? that way I can see the whole intervening changelog
<StevenK> Kamion: I didn't upload.
<Kamion> ah, kick your sponsor then
<StevenK> With pleasure.
* StevenK looks for Mithrandir.
<Kamion> StevenK: processed
<StevenK> Kamion: Ah, thanks.
<Pygi> welcome sistpoty
<sistpoty> hi Pygi
<infinity> mvo : How do you feel about the state of our current draft of NetworkWideUpdates?
<infinity> mvo : If someone were insane enough to spend some "spare time" starting to build small bits of it...
<mvo> infinity: I have to admit that I haven't looked recently on it
<infinity> mvo : I assume it hasn't changed since the hideous braindumping we did at UBZ.
<infinity> mvo : Someone in #ubuntu-server is offering to attack the spec and try to make some of it reality.
<mvo> woah!
<infinity> mvo : Perhaps you should hop in and give him 5 minutes of your time.
<mvo> infinity: I will have a look at it again tomorrow morning
<mvo> infinity: I'm in, but it's late here, I would rather prefer tomorrow
<infinity> mvo : Yeah, no problem.
<mvo> infinity: bastard :P
* infinity bows.
* mvo chuckles
#ubuntu-devel 2006-12-18
<owh> sistpoty: How is this for a first draft? http://paste.ubuntu-nl.org/37653/
<sistpoty> owh: looks good (though I'm usually making my comments in a less professional style :P)
* owh suspects a better synonym for bowels of the os would be a good idea :-)
* owh proposes depths.
<HrdwrBoB> internal workings
<owh> Excellent, tah.
<owh> sistpoty: I'm intending to tag all those bugs across launchpad, any suggestions for a unique tag, or should I just mark them vfat dosfstools?
<sistpoty> owh: vfat dosfstools sounds sane
* owh types :-)
<owh> sistpoty: Do you know of any that I missed: https://launchpad.net/distros/ubuntu/+bugs?field.tag=dosfstools
<sistpoty> owh: no, not really
<owh> sistpoty: I'm just hunting through any bugs with vfat in them.
<owh> sistpoty: None that I can find, any point in contacting Debian reporters as well?
<sistpoty> owh: hm... I don't think that's necessary
<owh> sistpoty: I'm checking out the version of dosfstools on cvs.linux-m86k.org to see if I can get a handle on the changes that implemented FAT32.
<stefg> owh: interestingly enough, just 1 hour someone picked up my report https://launchpad.net/bugs/62831.. seems that stir some dust
<Ubugtu> Malone bug 62831 in dosfstools "fsck.vfat truncates files of 4294967295 bytes length to 0 bytes at boot-time" [Undecided,Unconfirmed]  
<owh> stefg: That was me :-) (And sistpoty)
<owh> stefg: What other information can you give us?
<owh> stefg: sistpoty has been trying to reproduce your report with not much success, any other information you can share?
<sistpoty> stefg: could it be that your FS was already corrupted, and dosfsck just fixed it in a wrong way?
<sistpoty> stefg: or rather broke it more ;)
<stefg> hmmm... what do you need? Aren't the facts clear? dosfsck takes 32bit fat as 16bit fat... 
<owh> stefg: No, it's not that simple :-)
* owh wishes it were so :-)
<sistpoty> stefg: nope, as I said, I tried to reproduce it (created same big file, but dosfsck didn't complain)
<owh> stefg: FYI, the other bugs that *appear* to be related are now tagged "vfat dosfstools", there are five of them in total.
<stefg> so i can't really tell, if the fs was broken before... i use TrueImage, which splits the backup file in 4GB slices, and it needs to be fat32 to be accessible from linux and win... i did a deadly boring dapper server-install, and the initial dosfsck after the first reboot decided to eat my backups
<cge> stefg: So the files were right up against the limit for 32 bit FAT, were they not?
<stefg> yes, they were
<stefg> this is why i wrote the length in the bug report
* owh notes comments in the change logs about a single sector at the end of a partition.
<cge> stefg: As a minor point, were they 4 GB or 4 GiB?
<owh> stefg: You wouldn't still have those images lying around would you?
<sistpoty> hm... /me wonders how to upload/download 4GB... *g*
<stefg> owh: i ran a chkdsk from win afterwards, which fixed the problem... 
<owh> ROTFL
<stefg> cge: i stated the size in bytes... to avoid any confusion :-)
<cge> ah
<cge> I wasn't here
<stefg> 4294967295 bytes length
<stefg> that's 4 GB /4096 MB)
<owh> Uhm, silly question, could this be a kernel limit, I recall having fun with 4Gb files on ext2 a couple of months ago.
<stefg> no... i have xfs and ntfs partitions on my system, which files bigger than 10 GB
<cge> owh: What kernel was that? I had thought those problems had been solved years ago?
<sistpoty> owh: I doubt that... dosfsck doesn't read through the file system, but directly through the block device... wouldn't work at all with partitions > 4 GB then
<owh> cge: That was from memory something like 2.6.9.
<owh> sistpoty: Hence my silly question disclaimer :-)
<jdong> owh: that's silly
<owh> stefg: Do any of these other bugs spark any memories: https://bugs.launchpad.net/distros/ubuntu/+bugs?field.tag=dosfstools
<jdong> owh: I unfortunately use ext2 as a compatibility FS between my XP and Linux, and store files >=4GB on a regular basis
<cge> jdong: I use ext2 as my partition for everything in Windows XP except for Windows itself.
<jdong> yeah, it works well
<jdong> the "unfortunate" part is having ext2 store 20GB+ DV streams
<jdong> which it definitely does NOT excel at doing
<jdong> I'd much rather hand that job to XFS... but silly Windows....
<owh> As the prodding increases, I recall now that it wasn't an ext2 fs, but a FAT32, because I wanted to get to it from somewhere else, /me cannot recall all the details, only that the resolution was to split the file to smaller than 4Gb.
<jdong> yeah, fat32 has a 4GB limit
<jdong> :)
<owh> Heh
<jdong> ext2 doesn't
<jdong> just be thankful it's not FAT16? :D
* stefg reads... and needs to brew a tea
* owh is recovering from a night without sleep :-)
<owh> Hold on, jdong, you just said that FAT32 has a 4GB limit, but then how does that relate to bug 62831 which is the one that stefg reported -- /me is a little confused.
<Ubugtu> Malone bug 62831 in dosfstools "fsck.vfat truncates files of 4294967295 bytes length to 0 bytes at boot-time" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62831
<stefg> Hmmm, no... so #59293 is 'brokenness by design' and the others may relate to same cause, but are different incarnations
<jdong> owh: it's not surprising
<owh> stefg: But the DOS/Windows fsck knows when a file system is "dirty".
<jdong> owh: the fize of his files are exactly the upper limit for FAT32
<jdong> I woudln't be surprised if there's a fsck.vfat bug at that point
<cge> owh: In other words, a really bad idea.
<cge> jdong: However, it seems that others have not been able to reproduce the problem.
<jdong> right, I noticed that
* owh points out that "others" is sistpoty :-)
<jdong> whom I'd trust to be able to create a 4.00GB file
<jdong> lol
<cge> sistpoty: What did you use for the source of data in the files? /dev/zero? or /dev/urandom?
<stefg> owh: what might be of interest is that it's a relativley small 25 G partition at the end of a 160 GB drive... starts beyond the 137 GB limit
<jdong> cge: you can't use /dev/urandom to make that big a file with dd?
<cge> jdong: No? I didn't know that.
<jdong> cge: /dev/urandom contained EOF characters the last time I tried
<sistpoty> cge: first I tried with /dev/zero, then I fired up xp and copied some game data until I got the very good error msg "disk full" (because I had reached the limit)
<jdong> apparently that's a part of the "randomness" :D
<cge> sistpoty: Perhaps that changed something.
<sistpoty> cge: I can hardly think of what would be changed then... 
<cge> Also, it might have to do with creating the file with the vfat drivers in linux as opposed to windows.
<cge> oops, never mind
<owh> stefg: Where did your file originate?
<owh> cge: Why does that not matter?
<sistpoty> cge: My best guess would be that some repair code is indeed broken. I guess I'll break my fat32 partition and look what dosfsck does
<cge> owh: Because I just noticed that sistpoty said that he copied it in XP.
<stefg> owh: Acronis True Image 8, the recovery version (which is a modified Redhat kernel with an embedded CS app on top)
<_ion> EOF isn't really a character. Programs may interpret ^D as EOF when stdin is a tty, but i'd be surprised if dd did that when reading from /dev/urandom.
<sistpoty> cge: I tried both variants, linux + xp
<cge> I see
<cge> _ion: I'm nearly certain that dd wouldn't
<owh> _ion: Other than that some apps treat /null as an EOF - the command "type" in DOS for example.
<sistpoty> hm... stupid idea: /me is interested to fix that bug because /me fears data loss as well, but in order to get a little bit closer to it, /me will break my fat32 *g*
<jdong> _ion: when I try dd'ing a file from /dev/urandom, it creates some couple-byte files every time....
<jdong> at least before it did
<jdong> maybe I was using cp and not dd, I don't remember now
* owh hands sistpoty a big shovel for the hole that he's digging on his hard-disk.
<jdong> oh look at that, it's working
<jdong> never mind about dd & urandom :D
<stefg> owh: but i experienced file corruption on other fat32 drives with other file-length, too... until i set all the vfat drives in fstab to 0 0 on col. 6/6  
<owh> stefg: Do you recall any details?
<cge> stefg: Why would the pass have anything to do with corruption?
<owh> cge: To stop the check at boot time.
<cge> ah
<stefg> owh: I have pretty much investigated what corrupts my data, because i need reliable backups... so what details would you need?
<sistpoty> stefg: anything that's uncommon with the files, the partition, fs encoding... whatever comes to your mind
<owh> Some reports talk about spaces and back slashes in names, hanging CPU, .lnk files, etc.
<sistpoty> hm... I didn't try backslashes yet
<owh> sistpoty: That was associated with a report in a Japanese file name IIRC.
<stefg> ok... let examine this... the consequence of the whole incidence (unfortunately) was that i altered my partitioning scheme, so the partiton on which it happened does no more exist. The most noticable thing is that it was 25 Gigs on very high sector numbers... last 25 GB on a 160 GB drive
<stefg> The files had the mentioned length... a corner case, too
<sistpoty> stefg: hm... shouldn't really matter... dosfsck reads the block device of the partition, so the offsets will start with 0 for the partition
<owh> sistpoty: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355903
<Ubugtu> Debian bug 355903 in dosfstools "dosfstools: Classifies an acceptable file name as invalid" [Important,Open]  
<stefg> and the file system was mostly written by a linux'ish kernel (True Image recovery system). win never complained about something, and since i have a good instinct when a fs is broken, i'd say it was ok before
<owh> sistpoty: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=198561
<Ubugtu> Debian bug 198561 in dosfstools "dosfsck doesn't like spaces in 8.3 filenames on VFAT" [Unknown,Open]  
<sistpoty> stefg: any clue if you had many files in this directory? 
* owh suspects that if the file was 4Gb, there was only one file there :-)
<stefg> the drive contained 4 folders, each holding 3-20 files (spanned backup images)
* owh doh's
<sistpoty> not really uncommon... :(
<owh> stefg: What kind of name did the folders have?
<sistpoty> stefg: what architecture, i386 or amd64 or s.th. else?
<stefg> amd-k7 , nforce2 system... 32bit well proven system :-)
<sistpoty> stefg: ok, I tried this only on amd64 (64-bit), maybe I'll have more success on i386
<stefg> sistpoty: as far as i remember, dosfsck complained about invalid directory entries and decided to add 0 byte length in the fat... win chkdsk corrected that back
<sistpoty> ok
<owh> Does that suggest to anyone else that the problem is still with the directory structure rather than the file itself?
<owh> Which is what the other reports also talk about?
<sistpoty> sorry to say, but I really need to go to bed now
<stefg> owh: this is my point... not the file gets corrupted, but the fat
<sistpoty> at least I've got some ideas to try tomorrow, I'll report back
<sistpoty> thanks for the further info stefg
<owh> I'm in Western Australia, so what time would be good?
<stefg> np... contact me if can help further
<owh> It's 10am here.
<sistpoty> I'm in germany (2 am), but will be in university the whole day... so I guess I'm home at 20 utc (maybe a little bit later in front of my box)
<owh> Hmm, seems like email is a good option then :-)
<sistpoty> owh: or appending further findings to the bug reports ;)
<owh> ROTFL
<owh> sistpoty: I'll stick them on the end of stefg's report.
<sistpoty> owh: great, thx
<sistpoty> good night everyone
<owh> Sleep tight.
<owh> stefg: You're also in Germany?
<stefg> yup, Berlin
<owh> Hmm, so you'll be heading off to bed soon too I suspect :_)
* stefg just decide to fire vlc to watch some TV
* owh goes hunting for corrupt FAT32 file systems.
<stefg> BTW, there were no sapces in the names of the corupted files (I knew that some time i'd have to acces them from dos or bash)
<owh> Hmm, the changelog has this entry: - dosfsck: remove directory entries pointing to start cluster 0, if they're not "." or ".." entries that should actually point to the root dir (pointed out by Thomas Winkler <twinkler@sysgo.de>)
<stefg> theory: a number too big for some variable flips it over to 0.... and get removed subsequently
* owh nods
* owh makes a cup of coffee...
<sistpoty> stefg, owh: ha, just did a quick test with a 32-bit livecd. I could reproduce it immediately :)
<stefg> bingo !
<sistpoty> should be a simple integer overflow issue... maybe the compiler will even find it for me. I'll try to fix it (but tomorrow *g*)
<sistpoty> but now /me is off to bed
<sistpoty> good night
<stefg> n8
<owh> Yah!
* owh sips coffee.
* stefg sips tea
* owh sends subliminal Gruesse und Danke to sistpoty :-)
* owh installs more stuff to make dosfstools build :-)
<stefg> yes... far better to fix dosfstools than doing fstab tricks...
<owh> Hell yeah!
* owh was just attempting to sort out the simple stuff while the big stuff went along in little steps :-)
<stefg> 'tho i still think it's silly to put dosfsck on as a default... ever unintentionally checked a 250 GB USB drive at boot-time?
<owh> stefg: No, but the equivalent is to boot a laptop on batteries that decided that it needed an fsck :-) So I guess I understand what you're saying...
<owh> stefg: I suspect that it's a fair argument for a wishlist item to change the default.
<owh> stefg: How do you like this: check.c: In function scan_dir: check.c:811: warning: comparison between signed and unsigned
<owh> stefg: There's a whole bunch of them :-)
<stefg> ... that's were the bugs feel at home... i observed file coruption even well below the 4 gb limit. plausible 
* owh is trying to make the compiler barf :-)
<cprov> BenC: ping
<BenC> cprov: pong
<cprov> BenC: can you see anything wrong with builds now ?
<cprov> BenC: I've re-established the service (as much as I could). Do you miss any important build ?
<BenC> https://launchpad.net/distros/ubuntu/+source/linux-meta/2.6.20.1
<BenC> should not show building
<cprov> BenC: and it doesn't ...
<BenC> it did when I pasted it :)
<BenC> looks good, thanks
<cprov> BenC: ohh, fine .. I will go to bed now. call me if anything odd happens again, ok ?
<BenC> sure thing
<cprov> good night folks
<cprov-ZzZ> forgot to mention, cron.daily was skipped this hour, so Don't Panic, your uploads will be considered within one hour.
* cprov-ZzZ really goes
* owh would like some advice. Sistpoty is now sleeping and I'm trying to assist in determining what might be causing a FAT32 corruption by dosfschk. I've got the source and I'm playing with compiler flags, but while I've been programming for some 20 years, I've managed to avoid C :-). What compiler flags should I use as a first pass to determine overflows?
* owh has found several signed vs. unsigned warnings, which is where my pointer arithmetic from days gone by would start looking, but would love some comment from the playing field.
<somerville32> I noticed that there was package accepted in Feisty named: sun-java5 1.5.0-10-1
<somerville32> err... wrong chanel
<wasabi_> When do Contents-*.gz files get updated?
<cjwatson> wasabi_: only manually at the moment, and therefore generally only just before release. This is something the Soyuz team need to work on ...
<mvo> cjwatson: could you please accept synaptic 0.57.11ubuntu12.1 into edgy-proposed?
<Hobbsee> cjwatson: ditto k3d please
<cjwatson> whoa, way to welcome an undercoffeed guy in the morning
* Hobbsee hands cjwatson a cup of coffee, and pokes him at the requests
<Mithrandir> cjwatson: I can do those if you want to grab your cup of coffee.
<Hobbsee> "drink up, the world's about to end"
* cjwatson goes to poke /people/ubuntu-sru/+subscribedbugs
<cjwatson> Mithrandir: synaptic wasn't approveed yet last I checked
<cjwatson> approved
* Hobbsee hugs Mithrandir in greeting
<Mithrandir> good morning, Hobbsee 
<Hobbsee> evening Mithrandir 
<Fujitsu> Hey Mithrandir.
<Mithrandir> hiya Fujitsu 
<mvo> cjwatson: thanks and good morning :)
<Mithrandir> cjwatson: you did both of them?  unapproved looks empty now.
* Hobbsee quickly looks to upload some crack so it doesnt look so empty
<hunger> Anyone got a firewalling script that works with feisty? firestarter and firehol both seem to interfeer with the NM there.
<cjwatson> Mithrandir: no, not yet
<cjwatson> Mithrandir: I think you forgot the -s option
<cjwatson> mvo: please subscribe the ubuntu-sru team to the synaptic bug so that I can find it
<cjwatson> Hobbsee: and yeesh, 23 minutes old. you're way back in the queue. :)
<Hobbsee> cjwatson: :)  i've been at work
<cjwatson> no, I mean there are 11 items in front of k3d
<Hobbsee> cjwatson: hence the late upload.  i would have uploaded it yesterday, but hadnt got thru the acks
<Hobbsee> cjwatson: ahhh well, approve quickly then, and you'll get thru them all in record time!  :)
<sivang> morning
<Fujitsu> Hi sivang.
<Hobbsee> hey sivang 
<Mithrandir> Listing ubuntu/edgy-updates (UNAPPROVED) 0/0
<sivang> hey dudes and dudettes :)
<Hobbsee> Mithrandir: edgy-proposed
<cjwatson> mvo: synaptic done
<Mithrandir> oh, point.
<Hobbsee> :)
<mvo> cjwatson: great, thanks a lot
* Hobbsee hands Mithrandir some more coffee
<mvo> cjwatson: I subscribed ubuntu-sru to the two bugreports too
<cjwatson> thanks
<cjwatson> Hobbsee: Mithrandir should be able to deal with k3d, since it's already approved
<cjwatson> (I think; didn't check very closely)
<Hobbsee> cjwatson: it is.  figured that an archive admin needed to do it, and you were there and talking :P
<Mithrandir> cjwatson: I'll do it
<Hobbsee> (and doing archive-y things)
<Hobbsee> thanks Mithrandir 
<cjwatson> Hobbsee: (actually, being asked to do archive-y things, but not yet actually doing so at that point)
<Hobbsee> cjwatson: point.  in the future, though....
<cjwatson> in future, I'm happy to be tapped for approvals; other archive admins are better targets for actually getting it into the archive
<Hobbsee> right
<cjwatson> though if there's something uploaded already when I approve it, obviously I'd punt it through at the same time
<mneptok> cjwatson: validate me! make me feel loved!
<mneptok> *ahem* sorry.
* Hobbsee drops mneptok into a lake of lava
<Mithrandir> Hobbsee: the source package is relibtoolised; I'll reject it.
<Hobbsee> Mithrandir: how the heck do i stop that?
<sivang> Hobbsee: drop the path maybe
<Mithrandir> don't test build, probably.
<Hobbsee> oh drat, it'll have relibtoolised against feisty, wont it
<sivang> Hobbsee: there is probably a relibtoolize patch no?
* Hobbsee has to build the source somehow
<Mithrandir> p'bly.
<Mithrandir> Hobbsee: just do debuild -S and unless it relibtoolises in clean, you'll be fine.
<Hobbsee> Mithrandir: it's still rerunning configure with that
<Mithrandir> Hobbsee: uh, wtf?  It shouldn't.
<Hobbsee> Mithrandir: exactly.  but it is
<Hobbsee> want to try it yourself?
<Hobbsee> i mean, i was using dpkg-buildpackage -sd -S -k<keyid> before, so that should have worked.
<Mithrandir> going to, yes.
<Hobbsee> thanks
<Mithrandir> Hobbsee: oh, busted upstream tarball \o/
<Hobbsee> Mithrandir: oh dear :(
<Mithrandir> tar tzf k3d_0.5.12.0.orig.tar.gz|grep Makefile$
<Mithrandir> it shouldn't give you any output, it gives you shitloads.
<Mithrandir> can you try building it in an edgy chroot?
<Mithrandir> if not, I'll review the relibtoolisation, it didn't look too bad
<Mithrandir>  libtool          |   30 +++++++++++++++---------------
* Hobbsee is off for a bit
<Mithrandir> (it's more the principle that we don't change build systems unless we need to)
<Hobbsee> yeah
<Hobbsee> gah,b eing yelled at
<Mithrandir> see you later, then
<sivang> Mithrandir: what's that Makefile$ notes for?
<Mithrandir> sivang: it's a package which uses autoconf and which ships Makefiles in the orig.tar.gz; those are created by configure and depend on where it's built.
<sivang> Mithrandir: ah right, I thought you were grepping for contents not file in the list of files ('t') :)
<Mithrandir> oh
<sivang> Mithrandir: so essentially, the upstream tarball should never contain a 'produced' Makefile, only .am(s) ?
<Mithrandir> sivang: if the package uses automake and autoconf, it should contain Makefile.am and Makefile.in
<Mithrandir> not generated Makefiles.
<cjwatson> mneptok: the Flying Spaghetti Monster loves you more than I will ever be able to
<sivang> Mithrandir: right, and how string are we in bugging upstream to change this if they mistakengly include it?
<sivang> (we had some discussions/arguments about tsomething similar on -motu a couple of weeks ago)
<cjwatson> mvo: please update the description of bug 75273 as described in the "Propose" section of https://wiki.ubuntu.com/StableReleaseUpdates
<Ubugtu> Malone bug 75273 in apt "Apt constantly sigsevs on edgy" [Unknown,Fix released]  http://launchpad.net/bugs/75273
<mneptok> cjwatson: you forgot the "PBUH" :)
<cjwatson> mvo: can you please try to get a patch without all the POT-Creation-Date changes?
<cjwatson> (they're noise)
<cjwatson> mneptok: ?
<Mithrandir> sivang: it's something I'd have repackaged an .orig.tar.gz for if I had it in one of my packages.
<Mithrandir> sivang: and told upstream "please use make dist to make your tar.gz releases"
* Hobbsee is back
<mneptok> cjwatson: "the Flying Spaghetti Monster (PBUH), first moved in the fastness of the void..."
<mneptok> cjwatson: "Peace Be Upon Him"
<cjwatson> ah :)
<cjwatson> mvo: otherwise the change looks OK, although I'm kind of unimpressed with the != operator segfaulting when its right-hand-side is NULL; perhaps there should be a check in the implementation of that operator instead
<cjwatson> mvo: though hmm, I see from the gdb trace that it's std::string::compare(), so I guess you lose there :-(
<Hobbsee> Mithrandir: uploading again - that was relibtoolised in a clean edgy chroot.
<Hobbsee> and rejected.  why?
<Hobbsee> Mithrandir: do i need to bump the version number again or something?  i thought you rejected the last one
<Mithrandir> Hobbsee: I only rejected the first one, there's one now which has been in the queue for ten seconds which I haven't looked at yet.
<Mithrandir> well, it's probably 40 seconds now, but still
<Hobbsee> right.  that's the one i just uploaded....
<Hobbsee> oh wait, the rejected mail must have been for the first one
<Hobbsee> gotcha
<Hobbsee> sorry...
<Mithrandir> correct
<Mithrandir> np
<Hobbsee> yep, here it is :)
<Hobbsee> sorry for the idiocy :)
<Mithrandir> grr, it still relibtoolised
<cjwatson> seb128: could you edit the description of bug 60277 to explain the impact etc., per https://wiki.ubuntu.com/StableReleaseUpdates? It's quite a long bug and it's easier for you to explain accurately than for us to try to work it out
<Hobbsee> Mithrandir: yes.  machine name was different
<Ubugtu> Malone bug 60277 in nautilus "Windows Network entries use a text icon instead of a computer one" [Unknown,Fix released]  http://launchpad.net/bugs/60277
<Mithrandir> Hobbsee: and architecture.
<Mithrandir> you need to name your machine bert and embrace the amd64 architecture
<Mithrandir> :-P
<Hobbsee> Mithrandir: haha :)
<seb128> cjwatson: I've explained it on the mail I sent to you and mdz about that SRU, I'll copy that on the bug
<Hobbsee> Mithrandir: well, i could.  StevenK has an amd64 machine, but i dont think he'd like it renamed :P
<Mithrandir> Hobbsee: anyway, it overwrites the file so it's probably not important, but if you could check 0.6 of k3d and lart upstream if it's not ok, that'd be lovely.
<Hobbsee> Mithrandir: how's attacking them with my Long Pointy Stick of DOOM!!!!!!!!!!!!!!!  ?
<Hobbsee> will that suffice?
<cjwatson> seb128: ok, please update the description with that then
<Hobbsee> :P
<Mithrandir> Hobbsee: excellent idea. :-)
<Hobbsee> yay!
<cjwatson> seb128: it's specifically better to update the description than just add a comment because comments tend to get lost in noise, whereas the description's right up there at the top
<Mithrandir> yay pointy sticks.
<seb128> cjwatson: good point
* Hobbsee really should rename her machine again
<seb128> cjwatson: description updated
<seb128> cjwatson: screenshoot attached to the bug give a good idea of the problem
<seb128> brb, trying gnomevfs 2.17.1 on feisty
<Hobbsee> thanks Mithrandir 
<mneptok> Hobbsee: name it Brenda!
<Hobbsee> mneptok: hehe, why?
<mneptok> i ... have no idea.
<mneptok> stream of consciousness.
<seb128> hi mneptok
<Chipzz> seb128: btw, the throbber in nautilus is way to big, dunnow if you noticed that
<Mithrandir> bert and brenda.  Perfect match. :-P
<mneptok> bienvenue seb :)
<seb128> Chipzz: I'm using spatial :p
<Chipzz> seb128: and that doesn't have a throbber? :)
<seb128> Chipzz: right, they synced the CVS code on epiphany version which fixes some bugs, let's see if today's update will fix that
<seb128> Chipzz: no, spatial has no toolbar, only a menu and the window content
<Chipzz> seb128: you'll only notice if you have icon size set to small, and text to none btw
* Hobbsee pokes mneptok a few times with her Long Pointy Stick of DOOM!!!!!!!!!!!!!!!  to make him more awake
<mneptok> ack!
<Chipzz> seb128: but I'm probably better of filing a bug anyway I suppose ;)
<seb128> Chipzz: wait for today's update
<Chipzz> seb128: will do
<cjwatson> seb128: thanks
<seb128> cool
<seb128> cjwatson: np
* mneptok curls back up in Hobbsee's lap and naps
<Hobbsee> hah
<mneptok> (you'll note i did not clean myself in your presence, per your request)
<Chipzz> seb128: though I do suspect the issue is the icon itself rather than the code
<seb128> Chipzz: I think that's the icon is scaling to the toolbar rather
<Chipzz> seb128: no, because the toolbar expands to fit the throbber
<Hobbsee> mneptok: oh dear.
<Chipzz> I can see the icons on the toolbar being smaller than the toolbar itself
<Chipzz> seb128: nevermind, I'm on crack
<seb128> ?
<Chipzz> I think what I saw was a nautilus window still open from before the upgrade
<Chipzz> new nautilus windows have correctly sized toolbars
<seb128> ok
<tsmithe> why do you use spatial?!
<seb128> tsmithe: because it's faster, cleaner and better? ;)
<tsmithe> no way!
<tsmithe> it may be faster
<tsmithe> not better
<tsmithe> it's so cumbersome!
* tsmithe is glad we don't have it by default
* Fujitsu questions the rationale for using Nautilus at all.
<seb128> that's your opinion
<tsmithe> indeed
<tsmithe> :)
<Fujitsu> True.
<seb128> no need to troll about it, that's not the right chan
<tsmithe> Fujitsu, cos it has gnome-vfs unlike thunar :)
<tsmithe> and it's in gnome
<seb128> and you have the choice so everybody should be happy
<tsmithe> indeed
<cjwatson> seb128: what's https://launchpad.net/distros/ubuntu/edgy/+source/gnome-vfs2/+bug/60277/comments/17 about?
<Ubugtu> Malone bug 60277 in nautilus "Windows Network entries use a text icon instead of a computer one" [Unknown,Fix released]  
<mneptok> cjwatson: that sounds like a refresher bug than a UI, Nautilus, or Samba bug. i've seen similar behavior a refresh cures.
<cjwatson> mneptok: I'm asking about that specific comment, which indicates that pressing refresh does nothing
<seb128> cjwatson: that looks a different issue, smb listing is known to not be perfect on network with firewall by example
<seb128> cjwatson: I would say it's not a regression from the patch, would be interesting to know if that worked fine for him on dapper by example
<cjwatson> seb128: the changelog from feisty was a lot better ("Allow operations on file handles that were created in another DaemonConnection"). Could you use that for edgy-proposed as well instead of the much less informative "fix browsing of a windows network"?
<cjwatson> or perhaps "Allow operations ..., fixing browsing ..."
<seb128> cjwatson: sure
<cjwatson> if you want to clarify the effect as well as what was changed
<seb128> cjwatson: 
<seb128>   * debian/patches/91_from_cvs_fix_smb_browsing.patch:
<seb128>     - Allow operations on file handles that were created in another
<seb128>       DaemonConnection. (This fixes e.g. smb browsing) (Ubuntu: #60277)
<cjwatson> yep, that's better
<seb128> ok
<Hobbsee> Mithrandir: getting my Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
<Hobbsee> upstream definetly needs larting
<Mithrandir> Hobbsee: thanks.
* Fujitsu clones said pointy stick, and joins Hobbsee on a larting excercise.
<Hobbsee> hehe
<Hobbsee> sarah@sarah:~/Desktop$ tar tzf k3d_0.6.5.0.orig.tar.gz|grep Makefile$ | wc -l
<Hobbsee> 233
<Hobbsee> impressive
<Fujitsu> Larting a KDE project with Hobbsee's permission... I never thought I'd see the day!
<Hobbsee> Fujitsu: :P
<Hobbsee> Fujitsu: some KDE projects do suck :)
<Mithrandir> Hobbsee: teach them about make dist.
<Hobbsee> Mithrandir: *nods*.  i cant just say "please use make dist in your tarballs, kthnksbye!" can i?
<Fujitsu> And why not?
<Mithrandir> Hobbsee: apparently, their release process is just poor.
<Mithrandir>   * I do not know why upstream let all the Makefiles and other cruft behind in
<Mithrandir>     the tarball, but after running a manual make distclean, the orig.tar.gz is
<Mithrandir>     1 MB smaller!  That also fixed the "X-File" problem of letting
<Mithrandir>     config.{status,log} files behind.
<Mithrandir> from debian/changelog for current feisty.
<Hobbsee> ouch
<Mithrandir> but yeah, "plz use `make dist`, kthxbye" is fine.
<mneptok> is Kthxbye the new KDE logout manager?
<Hobbsee> hahaha
* Hobbsee likes
<Mithrandir> mneptok: excellent suggestion. :-)
* mneptok bows
<elkbuntu> rofl
<elkbuntu> i really needed that giggle tonight
<Hobbsee> elkbuntu: heh, yeah....  *waits for the world to blow up a bit more*
<Hobbsee> elkbuntu: you know, i hope the CC doesnt get involved with this, when the CC hasnt even been decided yet.
<Fujitsu> Very good mneptok.
<Fujitsu> Hobbsee, aw, why not? Fun fun fun!
<elkbuntu> Hobbsee, yeah, watch where you poke that stick of yours :|
<Hobbsee> awww...i cant seem to find an email address
* Hobbsee doesnt really want to file a bug saying "your program sucks, fix it"
<Hobbsee> found one
<seb128> cjwatson: I've an another gnome-vfs patch candidate for edgy-updates (a bug which makes ekiga crash on closing, upstream get dups every day about it and that seems to drive them nuts), what is the procedure in that case. Can we stack 2 fixes to -proposed or should we wait to get the first one to -updates?
<cjwatson> seb128: they can be stacked if they're reasonably independent
<seb128> ok, good
<seb128> thank you
<Hobbsee> Mithrandir: upstream larted
<Mithrandir> Hobbsee: yay you!
<Hobbsee> :)
<bhale> yay Hobbsee !
<Hobbsee> :)
<sebest> seb128: hi
<seb128> sebest: hey, I got your mail, didn't have time to look at that yet but I'll today, thank you for the work on that ;)
<sebest> seb128: ok great, i think we should ask to mvo, about the changes in samba config
<seb128> sebest: why mvo? Usually infinity looks after samba I think
<sebest> seb128: ah sorry, i just found his email in the samba changelog
<seb128> he just fixed a bug afaik
<seb128> maybe the samba option changes should be discussed on ubuntu-devel mailinglist
<sebest> seb128: yes, you are right
<fernando> seb128: thank you by #60277
<sebest> seb128: on a side note, i found a "limitation" in nautilus while testing nautilus-share
<seb128> fernando: you're welcome :)
<cjwatson> Mithrandir: whoops, sorry I appear to have left cdimage broken for a week
<cjwatson> Mithrandir: it should be working a bit better now ...
<seb128> sebest: we can fix "limitation" too ;)
<sebest> seb128: nautilus doesn't want to move to trash files that doesn't belong to the user even if the parent directory belongs to him
<seb128> sebest: I think that's a known bug, maybe a gnomevfs one
<sebest> seb128: in fact it's not totally a bug
<sebest> because nautilus accept to delete it, but not to trash it
<sebest> and we run in this issue when we allow people to write in a share, because the created folder belongs to nobody:nogroup
<seb128> maybe Novell wrote a patch for that ;)
<Mithrandir> cjwatson: the seed location change?
<seb128> would need to look to their package
<sebest> seb128: he he :)
<cjwatson> Mithrandir: yeah
<sebest> seb128: i already backport all the patches from their nautilus-share package 
<cjwatson> what with all the organisational changes, I forgot to follow up on that
<owh> stefg: Ping
<seb128> ogra: new g-p-m available
<cjwatson> Mithrandir: I *think* I've fixed the persistent powerpc CD build failures now by telling cp not to preserve ownership
<cjwatson> Mithrandir: shout if it shows up again after today ...
<Mithrandir> cjwatson: yay
<stefg> pong
<stefg> pong, owh
<owh> Ah /me wakes up.
<owh> stefg: Did you see the update on your bug, another report, interestingly using the same software you told us about.
<stefg> owh... yes. it's funny. Just wrote a comment on that
<cjwatson> infinity: could you turn the livefs cron jobs back on, please? They seem to have been disabled since 20061204.
* owh found some code that is zeroing stuff, but I need to know how sistpoty was able to recreate your issue.
<stefg> But you don't get exactly 4 GB-files by chance... so it's plausible tht the problem shows with spanned backups first
<ogra> seb128, thanks, already on it :)
<owh> stefg: It may also be that there is more than one issue, but we'll go with one to start off with :-)
<seb128> ogra: np, cool
<ogra> cjwatson, could you promote openbsd-inetd ?
<cjwatson> ogra: only if you work out how to get anastacia to say that netkit-inetd should be demoted at the same time
<ogra> hmm, k
<stefg> owh: actuall all it needs should ba a vmx with a linux fs and a vfat partition of 8 GB or so. dd an empty 4 GB file on the fat32 part. and run a dapper/edgy server install... tht should reproduce it 
<cjwatson> ogra: it appears to be in the server-ship seed
<cjwatson> ogra: probably just replace that with openbsd-inetd
<ogra> in mine or ubuntus ? 
<cjwatson> ogra: all of them
<cjwatson> ogra: change it in Ubuntu, merge to the rest
<ogra> oh, ok
<cjwatson> (or get Riddell and janimo to do so)
<ogra> will do
<cjwatson> thanks
<cjwatson> germinate says that's the only thing keeping it there
<raphink> hi
<raphink> anyone good with sbuild?
<Mithrandir> Hobbsee: please mention the component when requesting sync, especially when it's not from main.
<Hobbsee> Mithrandir: which was this for?  was this for the lot i fixed?
<Mithrandir> Hobbsee: tuxguitar
<Hobbsee> or new debian packages
<Hobbsee> ah
<Hobbsee> requestsync doesnt seem to handle that
<Mithrandir> teach it to and send pitti a patch. :-)
<Hobbsee> or just get pitti to do it :P
<Lure> cjwatson, mdz: re kubuntu sru bug 75017 - can somebody comment on it (we have lot's of people seeing this as regression)
<Ubugtu> Malone bug 75017 in kubuntu-default-settings "SRU: remove /.hidden file " [Undecided,Unconfirmed]  http://launchpad.net/bugs/75017
<cjwatson> Lure: yeah, I saw that but was waiting until I had time for a quick chat with mdz about it
<Mithrandir> Hobbsee: why did you subscribe ubuntu-archive to https://launchpad.net/distros/ubuntu/+source/kvpnc/+bug/64961 ? It's nothing the archive admins can do about this (at this point)
<Ubugtu> Malone bug 64961 in kvpnc "kvpnc (0.8.5.1-1) does not work" [Medium,Fix committed]  
<Hobbsee> Mithrandir: a screwup, and not being able to take you guys out.  i thought i said that in the last comment?
<Hobbsee> Mithrandir: i went "oh dear, i've ack'd the wrong bug.  i cant undo it.  perhaps i shouldnt be doing this tonight"
<Mithrandir> Hobbsee: you didn't, but I'll unsubscribe us.
<Mithrandir> Hobbsee: heh, ok
<Hobbsee> Mithrandir: it seems that i cant :(
<Hobbsee> i tried to
<cjwatson> yes, you can only unsubscribe yourself or a team you're a member of
<Lure> cjwatson: ok, I just did not know if I did everything right to get it on the radar screen (and how quickly to expect the response/decision)
<Mithrandir> Hobbsee: I just did it, so no worries.
<Hobbsee> Mithrandir: what cjwatson said.  heh :)
<Mithrandir> Hobbsee: just got confused about why we were subscribed to it.
<cjwatson> Lure: it's correctly on the radar, but just a bit controversial. :)
<Hobbsee> Mithrandir: it was late, i got the wrong tab.  that's all :P
<Lure> cjwatson: I know that ;-)
<Lure> cjwatson: we had also hot discussion on uds-mtv and kubuntu meeting 
<pitti> Riddell, any other KDE user: does "webbrowser.open('http://www.ubuntu.com', True, True)" DTRT under Kubuntu?
<Hobbsee> pitti: dtrt?
<Hobbsee> sarah@sarah:~$ webbrowser.open('http://www.ubuntu.com', True, True)
<Hobbsee> bash: syntax error near unexpected token `'http://www.ubuntu.com','
<Hobbsee> sarah@sarah:~$ "webbrowser.open('http://www.ubuntu.com', True, True)" DTRT
<Hobbsee> bash: webbrowser.open('http://www.ubuntu.com', True, True): No such file or directory
<pitti> Hobbsee: open a new konqueror window
<pitti> Hobbsee: sorry, in python, after 'import webbrowser'
<Hobbsee> ahhhh
<Hobbsee> lol
<Hobbsee> >>> webbrowser.open('http://www.ubuntu.com', True, True)
<Hobbsee> run-mozilla.sh: Cannot execute /opt/firefox/mozilla-firefox-bin.
<Hobbsee> pitti: konq's not my default browser
<pitti> Hobbsee: urgh, WTF? /opt?
<Hobbsee> pitti: running a custom firefox
<Hobbsee> *grin*
<Hobbsee> (and thunderbird)
<pitti> Hobbsee: bah, is it easy/customary to change your system like you did? if so, then I shouldn't user the webbrowser module
<pitti> Hobbsee: but x-www-browser doesn't allow me to specify 'use a new window', so I need some more clever code
<Hobbsee> pitti: it appears that i've done that in kcontrol.  x-www-browser is still pointing a konq, for some reason
<Hobbsee> it's easy, dont know about how normal it is
<Mithrandir> doko: you might want to upload the ooo update to -updates when you have the time.
* Hobbsee runs the mozilla binaries as they're faster and work better
<pitti> Hobbsee: so you have a run-mozilla.sh somewhere which points to /opt/firefox/mozilla-firefox-bin which doesn't exist any more?
<Hobbsee> pitti: it seems so....
* Hobbsee wonders where /opt/firefox/mozilla-firefox-bin is
<Hobbsee> pitti: the run-mozilla.sh is in the upstream tarball, if you happened to want to eyeball it
<pitti> Hobbsee: I have it hee
<pitti> here, even
<Hobbsee> cool
<Hobbsee> pitti: cant figure out how i changed it
<Hobbsee> well, hwo to unchange it
<pitti> Hobbsee: hm, ok; thank you for trying!
<pitti> Hi Keybuk 
<Keybuk> heyhey
<Hobbsee> pitti: sorry i cant be more useful
<Hobbsee> hey Keybuk 
<Hobbsee> pitti: for the kde side - the default browser setting in kde doesnt set x-www-browser, FYI
<pitti> Hobbsee: hm, argh
<Hobbsee> pitti: hehe, yes, *exactly*
<pitti> Hobbsee: do you know what's the 'correct' way of calling konquerer to open a new URL in a new window?
<Hobbsee> there'd be a way with dcop, i expect
<Hobbsee> but you probably dont want to go there
* Hobbsee thinks
<pitti> the equivalent of 'firefox -browser https://www.ubuntu.com'
<Hobbsee> pitti: try konqueror <url>
<Hobbsee> kfmclient openURL %u
<Hobbsee> as well
<pitti> Hobbsee: that'll always open a new window, even if your default is to open a new tab?
<jelmer> quit
<Hobbsee> pitti: seems to
<Hobbsee> pitti: yep
<bhale> hi jelmer :)
<bhale> hi pitti 
<pitti> Hobbsee: *hug*, thanks
<pitti> Hobbsee: so I think I'll do the following: first try firefox, if that fails, try kfm, if that fails, call x-www-browser
<pitti> Hobbsee: I guess ffox won't be installed by default on Kubuntu?
<Hobbsee> sorry - the konqueror bit i tried
<Hobbsee> ffox isnt, no
<StevenK> pitti: Actually, 'firefox -browser https://www.ubuntu.com' does something interesting here on Edgy.
<pitti> StevenK: makes you a cup of tea?
<StevenK> pitti: It opens a new window, and a new tab in the existing window and www.ubuntu.com opens in the new tab.
<pitti> StevenK: oops, you are right. suck
<StevenK> pitti: Sorry. :-)
<pitti> bah, this apparently trivial task starts to become a real nuisance
<Hobbsee> pitti: kfmclient openURL <full url> also works
<bhale> firefox-remote can do it explicitly
<bhale> http://aquariusoft.org/page/linux/firefox_openinnewtab/
<bhale> like so
<Hobbsee> pitti: the advantage of the kfmclient is that it will use a preloaded one, if one exists.
* Hobbsee hugs pitti back
* Hobbsee contemplates work in the morning
<pitti> bhale: yay, firefox -remote "openURL(http://www.ubuntu.com, new-window)" DTRT
<pitti> Hobbsee: great, then I use kfmclient for Kubuntu
<pitti> Hobbsee: would you agree to prefer ffox under kubuntu if it is installed?
<pitti> since that's probably an explicit decision
<Hobbsee> pitti: i'd prefer to use whatever the default browser is listed in kcontrol, in kubuntu.  right now, i dont know what that settign is though
<Hobbsee> i suspect you'd have people whining if you made a decision one way or the other on that oen
<pitti> Hobbsee: (context: bug-reporting-tool and crash report user interface -> Malone window)
<Lure> pitti: kde has setting of default browser and it should just work with kfmclient
<pitti> Hobbsee: in edgy it uses your default browser settings
<Hobbsee> pitti: yep.  the reason to change would be?
<pitti> Hobbsee: but, if you configured your browser to open stuff in new tabs and have it on another workspace, then you'll never see the apport windwo
<pitti> Hobbsee: so I got a lot of complaints about that
<Hobbsee> ah yes, i see the problem
<pitti> Hobbsee: at UDS we figured that forcing a new window in this case would be better
<pitti> since it's more like a slightly odd new application window
<Hobbsee> it would.  can you force it on the current desktop?
<pitti> Hobbsee: if you open a new window, it would be on the current desktop
<Hobbsee> oh yeah, duh
<pitti> Hobbsee: it's not such a big deal for Kubuntu ATM anyway, since Kubuntu doesn't use apport right now
* Hobbsee is slightly slow tonight, it seems :P
<pitti> but it might in the future
<Hobbsee> true, but it needs to be thought about
<Hobbsee> oh yeah, i see the problem.  hmmm...
<Hobbsee> pitti: default kde browser is in ~/.kde/share/config/kdeglobals, it seems.  if BrowserApplication=kde-konqbrowser.desktop, use kfmclient..., for firefox check if the string contains firefox, i guess.
<Hobbsee> for anything else...dunno
* Hobbsee really should go to bed
<pitti> Hobbsee: sweet dreams!
* Hobbsee hasnt really seen any other decent kde webbrowsers.  x-www-browser defaults to konq anyway, on kubuntu, so you're pretty safe.
<Hobbsee> pitti: :) thankyou :)
<Hobbsee> pitti: you're aware that kde already has a bug reportnig feature, but not a crash one, presumably?
<pitti> Hobbsee: yes, I am
<Hobbsee> cool, just checking
<pitti> Hobbsee: but I'd still like to get the code right for Kubuntu too, just in case
<Hobbsee> pitti: sounds very sensible to me.  that only works for kde apps, after all.
<Hobbsee> and very few of us keep full kde desktops
<pitti> cjwatson: got 30 seconds to talk about apport/ubiquity?
<Hobbsee> pitti: I WIN!!!
<pitti> Hobbsee: wow, finished sleeping already? :)
<elmo> Burgundavia: ping
<Hobbsee> pitti: just use kfmclient openURL http://www.ubuntu.com
<Hobbsee> pitti: you dont need to grep the file at all - kfmclient handles that
<pitti> Hobbsee: 'that'?
<pitti> figuring out the default browser and such ?
<Hobbsee> (the only problem is if you've got the option in firefox set to force all new windows into a new tab)
<Hobbsee> yep
<pitti> Hobbsee: cool; that's much like gnome-open then
<Hobbsee> :)
<Hobbsee> yeah, it is
<Hobbsee> might even rock more than gnome-open, looking at this manpage
<pitti> http://developer.kde.org/documentation/other/kfmclient.html, nice
<Hobbsee> yep
* Hobbsee had previously only played with dcop stuff - now *that's* a nice lot of configuration
<Hobbsee> oh dear.  work starts in 7.5 hours :(
* Hobbsee really beds this time
<Hobbsee> night pitti, all
<pitti> night Hobbsee 
<doko> Mithrandir: yes, got approval from cjwatson
<cjwatson> pitti: yes, sorry for the delay (phone, then parents)
<pitti> cjwatson: I'd like to get rid of the apport_utils.py module and fan out stuff into the 'apport' python package (thus: import apport.foo) to get a proper namespace
<pitti> cjwatson: so I can either leave apport_utils.py and write stubs into it that call the new functions
<pitti> cjwatson: or just give you a patch for ubiquity to use the new methods
<pitti> cjwatson: I'd prefer the latter, are you fine with that?
<cjwatson> pitti: feel free to commit to the ubiquity branch on the supermirror
<pitti> cjwatson: (ubiquity is the only package that uses it ATM)
<pitti> cjwatson: alright, thanks
<cjwatson> sftp://bazaar.launchpad.net/~ubuntu-core-dev/ubiquity/trunk
<cjwatson> Breaks: ubiquity (<< whatever-the-new-version-is) would be appreciated in apport
<pitti> cjwatson: btw, last time I tried ubiquity, I just got ubiquity's standard exception dialog; does it only use apport under certain conditions?
<cjwatson> actually, no, you don't need to Breaks: ubiquity because it's conditional, so please ignore that
<pitti> cjwatson: wouldn't like to add it either; the python-apport-utils package is going to go away entirely anyway
<cjwatson> pitti: I disabled the use of apport in edgy because the workflow didn't seem as good to me as the previous code yet; the crash reporting improvements in feisty with the Malone cloakroom stuff should mean that it's worth using it
<pitti> it moves into python-apport which now has the complete package with the modules
<pitti> cjwatson: ah, right; so that worked just as intended
<pitti> cjwatson: I hope to get the cloakroom stuff working on the distro sprint with Bjorn; maybe we'll also find some time to integrate ubiquity as well
<cjwatson> pitti: it should write a crash dump, though
<cjwatson> that's merely conditional on the apport modules being importable
<mjg59> Mithrandir: Did you do anything with your uswsusp code?
<twb> Mithrandir: ping?
<_lemsx1_> hello all
<_lemsx1_> in Edgy at boot running a script from /etc/rcS.d/S01* the program "runlevel" returns "unknown" instead of S
<_lemsx1_> how can I go about this issue? should I open a bug?
<_lemsx1_> ah, i see, the bug is in /etc/event.d/rcS
<Mirv> is there a higher quality version of Experience ubuntu clip available? at least Canonical owns the copyright, so I'd guess there is. it'd be nice to try to encode a bit higher quality ogg aout of it.
<Mirv> (I'm sharing it to people at our LoCoTeam site, via Fluendo's Cortado Java applet and of course directly)
<Burgwork> elmo: pong
<_gpg_> hi all
<_gpg_> i've a question undirectly related to linux (hope it wont be enoying)
<_gpg_> does Ubuntu use any software to manage all ubuntu display screens ?
<apokryphos> mdke: thanks for your blog post and coupon :). Yours was the third mention of dreamhost I heard this week, so decided it was time to sign up.
<mdke> apokryphos: np
<Keybuk> mjg59: so, err, why is ondemand not being set at boot?
<mjg59> Keybuk: I've, er, no idea
<mjg59> Check that gnome-power-manager isn't doing something stupid to it
<mjg59> But I haven't touched powernowd
<mjg59> Oh dear.
<fabbione> Keybuk: http://people.ubuntu.com/~fabbione/udev_whole_disk.debdiff <- thanks :)
<mjg59> The HPLIP preferences applet wants pyqt.
<Keybuk> mjg59: nobody has :-/  I guess it must be g-p-m
<Keybuk> fabbione: it worked ok?
<mjg59> Keybuk: g-p-m needs saner preferences
<fabbione> Keybuk: yeps.. pushing the kernel patch now
<mjg59> Defaults, rather
<mjg59> Though I'm tempted to hide the cpu management as well
<mdke> the upstream maintainer seems quite receptive to ideas about defaults
<mdke> I left a comment on his blog about screen brightness dimming and he has changed it
<Keybuk> mjg59: yes, it is g-p-m setting the governor
<Keybuk> (checked via strace)
<Keybuk> and if you set "Do Nothing", it sets it to userspace
<Keybuk> OH JOY
<mjg59> Ok.
<Keybuk> ssseeeeebbbbbbbbb!
<mjg59> Let me nuke that.
<mjg59> Keybuk: Two ways of solving this:
<mjg59> Keybuk: (1) Remove all the cpufreq code from g-p-m
<mjg59> Keybuk: (2) Remove the UI from g-p-m, leave the code in the backend so people can set keys manually if they want
<Burgwork> mjg59: looking at the csv changelog, I thought hugshie already did 2
<mjg59> Burgwork: Oh? Last shot I saw, it still had the UI functionality
<mjg59> Let me check
<Burgwork> might be wrong, but I was browsing the cvs changelog last night
<mjg59> Burgwork: Closest I can find is a reference to removing the userspace governor
<Burgwork> that might be it
<mjg59> I'll grab the glade file and take a look
<fabbione> cjwatson: thanks for the installer
<mjg59> Burgwork: Still seems to be there
<cypher1> can anyone do the merges ?
<dpack> hi, could someone please explain why some changes in the *-changes lists are sent by "Ubuntu installer"?
<dpack> is the "Ubuntu installer" an automatic merging program of some kind?
<pitti> hi
<dpack> hi martin.
<Adri2000> dpack: I think it's for uploads which have been approved manually for example
<mdke> is the process for installing flash with browsers going to be different for feisty? We may have to change the docs
<dpack> The notification has a "Changed-By" field that I think might be who approved the upload, but the packages uploaded by "Ubuntu installer" are usually stock debian packages without any ubuntu modifications...
<dpack> So I'm wondering what process triggers the notification process by "Ubuntu installer" to the *-changes lists?
<dpack> is this a bad place to ask these kinds of questions?
<Adri2000> syncs are "changed-by" ubuntu installer
<dpack> Adri2000: do syncs happen automatically?
<Adri2000> they are requested by a developer
<dpack> Maybe whomever triggered the sync is put into the changed-by field in the notification sent by the "Ubuntu installer"?
<keescook> hiya pitt
<keescook> i
<keescook> :)
<ajmitch> hi pitti, keescook 
<keescook> hey ajmitch 
<dpack> guys, I'm doing some research on Ubuntu and its relationship to its sponsor Canonical. Is there any way to distinguish between an Ubuntu developer employed by Canonical and a volunteer?
<Adri2000>  <dpack> Maybe whomever triggered the sync is put into the changed-by field in the notification sent by the "Ubuntu installer"? < yes, maybe :) but I'm sure there are people more able to answer your questions than me :)
<mjg59> dpack: You can ask them, and if they say they work for Canonical, they're probably not a volunteer...
<mdke> dpack: those who work for Canonical have small red flames in the very centre of their eyes
<dpack> Matthew, would it be polite to ask?
<crimsun_> (note the @canonical e-mail.)
<mdke> also, there is an incomplete list on the wiki at CanonicalStaff
<ivoks> right... they get @canonial.com, spam-free mails
<dpack> Most of the Ubuntu developers just use @ubuntu.com...
<mjg59> dpack: I don't believe there's any flag in Launchpad that indicates whether someone is Canonical staff or not
<pitti> hey ajmitch 
* pitti hugs keescook 
<mdke> https://wiki.ubuntu.com/CanonicalStaff, for cliccability
<mc44> dpack: attend a distro team meeting. nearly all will be canonical :)
<ajmitch> mdke: I could just about believe that about the flames
<dpack> thanks, CanonicalStaff on the wiki is a nice start, but I don't think its complete.
<mdke> ajmitch: it's due to excessive coffee, I suppose
<mdke> dpack: no, of course it's not. Note: it's generally quite difficult to get complete lists of employees of companies
<jdub> dpack: the bags under their eyes.
<mdke> jdub: your bags are healing up?
<dpack> For example, michael vogt is not on the list, and I'm pretty sure he's working for Canonical on package management in Ubuntu.
<mdke> you can add him
<mjg59> dpack: It would probably help if we had some idea why you wanted to know
<mc44> dpack: yes, mdke pointed out it is an incomplete list
<dpack> Well Matthew, I'm trying to figure out how much of a community distribution Ubuntu is at the moment. That is, how much of the burden is carried by Canonical employees vs volunteers. 
<mjg59> dpack: At a rough guess, core-dev is probably 50/50. -dev is (as far as I know) entirely volunteers.
<dpack> Ubuntu is only part of my research though, I'm also researching the distribution of work load in Debian.
<dpack> mjg59: but many of the core-dev people are inactive...
<mjg59> Yes
<dpack> mjg59: half of them might be non-Canonical people, but their contribution is not as significant.
<mjg59> main is always going to be dominated by employees. That's what they're paid to do.
<thom> well, no. people who work full time on something are almost guaranteed to be more active than people who aren't
<dpack> there's also the problem that Debian is facing with dunc-tank, that having employees work alongside volunteers is a bit difficult sometimes.
<mjg59> dpack: I've been voluntarily working on Ubuntu since before Warty was released. I haven't seen any issues.
<mc44> dpack: http://paste.ubuntu-nl.org/37820/ is core dev divided up for you
<dpack> mjg59: it all comes down to the people involved. In Ubuntu its been that day from day one so I guess its less of an issue. Debian is having some real difficulties with it.
<Burgwork> mc44: lamont jones is HP, former Canonical
<mjg59> Where "some real difficulties" is "A small percentage of Debian developers"
<mc44> Burgwork: aha
<dpack> perhaps, a vocal minority.
<dpack> mc44: what is this list you sent me?
<dpack> y/n is yes no canonical employee?
<mc44> dpack: yes
<pitti> dpack: well, it's hard to compare -- one of Debian's main goals has always been 'completely freely developed', whereas Ubuntu was designed for corporate backing
<mc44> dpack: although not all Canonical are distro team members
<dpack> mjg59: according to the list mc44 sent me, you are not employed by Canonical. Is that accurate?
<pitti> dpack: so I can perfectly understand the guys who oppose dunc-tank (I'm not really happy about it either)
<mjg59> dpack: That's why I said that I've been voluntarily working on Ubuntu since before Warty, yes
<dpack> mc44: thanks, this is very useful.
<dpack> mjg59: heh, I had you pegged as a Canonical employee because of your previous involvement with Debian and early involvement with Ubuntu.
<dpack> what I don't yet understand is how Ubuntu can have a significant percentage of the activity of Debian with such a tiny work force...
<dpack> Debian average 2900 changes a month, and Ubuntu has roughly 60% of that. I'm not sure if I should filter out updates by "Ubuntu installer"
<zul> too much politicking in debian
<bhale> updates by Ubuntu installer means that change was automated
<bhale> or done by someone who is not whitelisted
<pitti> (yay langpack uploads ;) )
<dpack> Brandon, what do you mean by whitelisted?
<dpack> ok, so maybe I should discount uploads by "Ubuntu installer"
<dpack> BTW, why does ubuntu create a separate -changes list for each release instead of doing it like Debian that has stable-changes and devel-changes
<mdke> I've had some uploads sponsored which appear as "Ubuntu installer", but others have appeared as me, go figure
<dpack> mdke: could you give me specific examples? perhaps Ubuntu changed something in the infrastructure?
<mdke> I'll try and find some
<thom> can you please go to #ubuntu-offtopic
<thom> since this is utterly, well, offtopic
<dpack> Oh, another thing I couldn't quite figure out because its locked away in a restricted section at canonical.com's web site is what exactly is Soyuz. A web interface to a slightly modified dak?
<jdub> dpack: because ubuntu has releases, not just descriptors
<dpack> launchpad doesn't have reference to dak, but katie is mentioned, so I'm assuming Ubuntu uses the same infrastructure as Debian. Except for this Soyuz bit, which I'm not sure is anything more than a launchpad module, or something else...
<dpack> jdub: what is the difference? How are Ubuntu's releases different from Debian's?
<jdub> dpack: astoundingly more regular, which creates different demands
<jdub> dpack: there's not just "stable" and "devel"
<jdub> dpack: i would be annoyed if i got breezy, dapper and edgy updates on one mailing list (because i don't care about some of them)
<dpack> jdub: but technically is anything different? (other than management and mailing lists) Ubuntu keeps a unified pool I think and the releases are just pointers into the pool right?
<jdub> yep
<dpack> thom: sorry, but I doubt the nice people at ubuntu-offtopic are qualified to answer my questions.
<dpack> ok, back to the subject of Ubuntu syncs from Debian: what software actually does that in Ubuntu?
<dpack> nevermind, I just found merges.ubuntu.com
<Adri2000> sync != merge
<dpack> Adri2000: oh, what is the difference?
<Adri2000> sync a package = import the package from debian with no change. a merge is needed when the package has been modified in ubuntu, then we merge the last debian version with the ubuntu changes
<mdke> have you had a look at the developer pages on the wiki dpack? It might save you time asking here
<mdke> this info should be there
<dpack> mdke: yes, I am looking at them. I'm just a bit confused, but you're right, I should finish my home work first. 
<dpack> cheers guys, thanks for the information.
<mdke> there are sections on merges and syncs and such
<mdke> is dholbach on holiday?
<pitti> wb seb128
<seb128> re
<seb128> some days I hate linux
<seb128> network card broke with 2.6.20 and no way to stop the fsck on reboot (n mounts without fsck)
<mdke> yes, the latter is probably a bug for more users
<mdke> s/more/most
<jdub> morning seb128 
<jdub> seb128: which card?
<seb128> hey hey jdub
<seb128> an old realtek 8029 which was working fine until 2.6.17
<jdub> erk
<jdub> a classic!
* jdub sends seb128 care-drops of modern hardware.
<seb128> I've reboot with 2.6.17
<seb128> haha
<seb128> I had modern hardware, but it broke
<seb128> and I had that card not used
<bhale> hey jdub seb128 
<seb128> so I used it to get my network back
<seb128> and it's working fine since, so I didn't bother changing it :p
<seb128> hi bhale
<bhale> new nautilus is cute
<bhale> the cairo thing is super fast
<bhale> the whole thing feels faster really
<seb128> cool :)
<jdub> FAST AND CUTE
<jdub> i will have to upgrade.
<bhale> do it
* mdke grabs upgrade-manager
<pitti> jdub: go nuts :)
* jdub totally loves using his mirror
<seb128> jdub: how do I update a patch with quilt?
<seb128> ups
<seb128> pitti: ^
<pitti> seb128: export QUILT_PATCHES=debian/patches
<pitti> quilt push -a
<pitti> <fiddle with files>
<pitti> quilt refresh
<pitti> quilt pop -a
<pitti> seb128: or, if the patch is not on top of stack, replace '-a' with the patch name
<seb128> ok, thank you
<pitti> seb128: and if you need to modify files that weren't touched by the patch before, 'quilt add file' before editing file
<jdub> rhythmbox (0.9.7-0ubuntu1) feisty; urgency=low
<jdub>     - Use gnome-power-manager to inhibit suspend while playing
<jdub> doesn't that seem backwards?
<jdub> hrm
<jdub> i guess not
<jdub> as long as it gets an explicit suspend message
<jdub> so it can stop
<seb128> pitti: thank you
<jdub> at least it's smarter than windows!
<bhale> jdub: last.fm playback in rb is the most half baked thing i have ever seen in gnome
<seb128> I don't like quilt
<jdub> wmp being open at *all* stops suspend
<seb128> I'm switching that patch back to simple-patchsys, screw Debian guy :p
<bhale> jdub: http://tseng.ath.cx/~brandon/rbsucks.png
<pitti> seb128: takes some time to get used to, right
<seb128> for a small package like file-roller I don't get the interest
<bhale> jdub: double clicking an item in that list view does absolutely NOTHING
<j^> how should i talk to about missing php5 deb files in dapper-security?
<pitti> seb128: if it's just replacing the cdbs module, that's easy ;)
<seb128> yep
<bhale> jdub: i have gotten 2 different (useless) error dialogs
<jdub> bhale: good work going on there, though
<keescook> j^: what's missing?
<bhale> jdub: would love to see it...
<bhale> "Couldnt start playback: (null)"
<j^> keescook: current dapper-security has http://security.ubuntu.com/ubuntu/pool/main/p/php5/libapache2-mod-php5_5.1.2-1ubuntu3.3_amd64.deb
<j^> but that is missing, in http://security.ubuntu.com/ubuntu/pool/main/p/php5/ i can find a newer version
<keescook> j^: current php5 in dapper is 5.1.2-1ubuntu3.4
<keescook> j^: what are you trying to find?
<j^> keescook: in that case the problem might be on my side, apt-cache show php5 lists 5.1.2-1ubuntu3.3 here
<pitti> 'use apt-get update, Luke!'
<pitti> :)
<j^> haha
<j^> did that several times
<pitti> j^: apt-cache policy php5?
<j^> i removed /var/lib/apt/lists/*
<j^> now it lists the new version
<j^> strange
#ubuntu-devel 2006-12-19
<seb128> can we mark specs rejected or something like that?
<seb128> https://blueprints.launchpad.net/distros/ubuntu/+spec/ubuntu-secure-gdm by example
<seb128> that's a spec about building gdm with --enable-secure-remote
<seb128> which is not a spec topic, just a wishlist bug
<Keybuk> no, I believe that was removed
<keescook> oooh, sneaky, clamav 0.88.2 takes the upstream patch cleanly... but doesn't fix the problem.
<jdub> bhale: gosh, nautilus does *seem* faster.
<bhale> jdub: by a lot
<jdong> ooh, you can't say no to specs! yay!
* jdong puts on his evil grin
<shaya> Q. about changelog.Debian.gz, it doesn't seem to track ubuntu changes well
<shaya> as the ubuntu log is constantly dumped in resync'ing w/ debian
<shaya> why is that?
<keescook> shaya: if the current version of the program has no Ubuntu changes in it, then it won't show prior ubuntu changes that were made but more recently dropped.
<shaya> yes, but there are versions, such as gnome program (2.17~) that dont have any debian changes as there are no debian versions of them
<shaya> so the changelog history is lost
<keescook> shaya: I'm not sure I understand what you're describing.  do you have a example package?
<keescook> 2.6.20-1> has anyone tried to burn a CD with it?
<shaya> vino
<keescook> BenC: ^^ did you try cd burning?
<BenC> not yet, but I haven't heard anything about it not working
<keescook> shaya: I see vino's changes in /usr/share/doc/vino/changelog.Debian.gz
<keescook> BenC: okay, hm, once my two builds finish, I'm going to reboot to .19 and see if this comes back.  so many things have changed on my system... it's been a while since I burned a CD.  :)
<shaya> keescook: wat version do you see?
<shaya> I see 2.17.4-0buntu1 and 2.16.0-3
<shaya> but there were ubuntu versions between them
<keescook> shaya: I think the reason is because the prior version of vino was entirely packaged by debian.  So when the package got merged with the debian vino, all the only-in-ubuntu changelog entries went away, since only the changes from debian are relevant any more.
<mjg59> Right
<mjg59> The changelog is there to tell you about the history of the branch of code that ended up in that package
<mjg59> Not about every change made to every branch that we ever shipped
<shaya> except that ubuntu shipped 2.17.2....
<mjg59> And then dropped the Ubuntu branch and re-adopted the Debian one
<shaya> ok
<shaya> seems weird to me
<shaya> means bug closing gets lost
<mjg59> The alternative would be that whenever we re-merge with Debian, we need to carry around an extra Ubuntu changelog
<mjg59> Even if the package is otherwise identical
<shaya> would that be so bad?  use changelog.Debian to keep the changelog for the "branch" while changelog.Ubuntu would keep the ubuntu change history.  If none for a specific version, it be empty
<mjg59> It means that any package that's ever diverged in Ubuntu would be divergent forever
<mjg59> Which is less than ideal
<bddebian> shaya: It would kill us in Universe where we have few resources and TONS of packages
<shaya> hmm, mjg59 then perhaps (version)Ubuntu* should be extracted and stored somewhere?
<ajmitch> all the previous versions are still on launchpad, I believe
<ajmitch> so the history is there
<shaya> but easy to view?
<shaya> or version by version?
<shaya> which is somewhat annoying
<ajmitch> each version, and there are changelogs
<shaya> I understand
<ajmitch> not the most discoverable, but that's LP
<ajmitch> it's slowly getting some UI love
<keescook> BenC: yeah, on .19 I can burn again.  cdrdao disk-info on .20 reports CDRs have 0 bytes available for writing.  :)
<Solarion> any gnumeric people here/
<Chipzz> Solarion: highly unlikely
<LaserJock> Solarion: gnumeric people as in?
<Chipzz> I suppose he's referring to upstream?
<LaserJock> ah, I doubt it
<Solarion> no, I mean packaging people.
<Solarion> I'd like to know why edgy is stuck at 1.7.0
<LaserJock> Solarion: stuck?
<BenC> keescook: Is that 2.6.20-2.2?
<Solarion> LaserJock: is half a year old
<Chipzz> Solarion: not quite that old, yet :)
<Chipzz> 4 months, hardly
<Chipzz> ftp://ftp.gnome.org/pub/gnome/sources/gnumeric/1.7
<Solarion> May
<keescook> BenC: 2.6.20-1-generic, I will go update.  Also: burning actually works, it's just the information query that seems to fail.
<LaserJock> well, that's what it was when Edgy was released
<Chipzz> oh
<LaserJock> basically that's the way it goes
<Chipzz> that's MM/DD/YY
<Chipzz> how confusing
<Solarion> I guess I can live with that.
<Solarion> Chipzz: yeah.  It's teh suck
<BenC> keescook: Interesting, let me know the result of -2
<LaserJock> we can request backports
<Solarion> hey keescook
<_MMA_> I get some burning issue also. "(gnomebaker:6657): libglade-WARNING **: could not find signal handler 'gnomebaker_on_format_dvdrw"
<Chipzz> Solarion: oh btw
<Chipzz> it is not "stuck" on 1.7.0
<Chipzz> latest version is 1.7.5 in feisty
<Chipzz> gnumeric (1.7.5-1ubuntu1) feisty; urgency=low
<Chipzz>   * Merge with debian experimental:
<Chipzz>     - debian/control, debian/*-gtk-*, debian/rules,
<Chipzz>       debian/shlibs.local: Xubuntu changes for
<Chipzz>       gtk/gnome multibuild.
<Chipzz>     - run intltool-update in po*
<Chipzz>     - Build Depend on intltool
<Chipzz>  -- Gauvain Pocentek <gauvainpocentek@ubuntu.com>  Wed,  6 Dec 2006 13:55:23 +0100
<Chipzz> Solarion: basically, the definition of a release is that software that is "released" has a low tendency of changing.
<Chipzz> except for security updates and stuff like that
<derekS> fabbione: ping
<fabbione> derekS: pong
<derekS> fabbione: i noticed a while ago you filed bug 73425 and it was set to low priority... is there a fix that you found?
<Ubugtu> Malone bug 73425 in udev "warning at boot" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73425
<derekS> it makes my system almost non-useable
<derekS> (as a desktop)
<fabbione> derekS: no, i didn't check for a fix and it's just a warning.
<fabbione> it doesn't affect any functionaility
<derekS> fabbione: it makes the mouse not work :)
<fabbione> derekS: works here. the problem might be something else
<fabbione> and you see a warning for other reasons
<fabbione> added a comment to the bug
<fabbione> your problem is different
<derekS> fabbione: i am pretty sure it is the same bug :)
<fabbione> so don't mix any more info with that
<fabbione> i am pretty sure it's not
<derekS> alright, i will keep searching
<fabbione> file another one
<fabbione> check the data coming from the mouse port
<derekS> fabbione: i filed another one, but then set it to duplicate
<derekS> fabbione: well, i am not sure how to do that :)
<fabbione> i don't have time now to debug it with you
<fabbione> check if it works with a different kernel
<fabbione> for example
<fabbione> if that solves the problem, you know who to blame
<derekS> fabbione: it doesnt, problem has been around since like 2.17...
<derekS> kernel people said it was udev :)
<fabbione> derekS: that warning is new in feisty
<fabbione> if your problem is older than it's not udev
<fabbione> gotta go
<fabbione> later
<derekS> hmm, ok... i will look around on how to fix it...
<derekS> thanks for your help
<Solarion> Chipzz: you'll note the word "edgy" in my posting and "feisty" in yours.
<Solarion> Hence edgy *is* stuck at 1.7.0
<Chipzz> for your definition of 'stuck' ofcourse ;)
<Solarion> umm
<Solarion> is it going to go higher than 1.7.0?
<Chipzz> depends if the maintainer is willing to backport it
<Solarion> then until that point it is stuck at 1.7.0
<Chipzz> but since it also requires a higher version of goffice
<Chipzz> no, it is not
<Chipzz> read the definition of "release"
<Solarion> maybe for your definition of "stuck"
<Chipzz> releases don't get stuck, they get released :)
<Chipzz> subtile difference :)
<Solarion> bah, this is semantic wanking
<Chipzz> no it's not
<Solarion> it centers around the precise meaning of the word "stuck"
<Chipzz> if releases were to upgrade to the latest versions of everything after they are released, they wouldn't be called releases now, would they? ;)
<Solarion> umm, yes they would be.
<Chipzz> what I'm trying to say is that "stuck" is the wrong way of looking at it
<Chipzz> no they would not
<Chipzz> releases require a specific version in order to be able to give support on that release
<Chipzz> if you're constantly upgrading, you're unable to support it
<Chipzz> hence 'release'
<Chipzz> bottom line is, if you want a higher version of gnumeric, either file a bug report requesting a backport (kinda unlikely to happen IMVHO), or upgrade to feisty
<Solarion> I can build my own; I was just curious why it was so old.
<Chipzz> most likely it'll be easiest of you add deb-src lines for edgy
<Chipzz> Solarion: does the new version of gnumeric fix a severe bug?
<Chipzz> because if it does, the chances of getting a new release are significantly higher
<Solarion> I dunno
<Solarion> maybe? :)
<Solarion> Chipzz: I need to access it for my own nefarious purposes, so deb-src is insufficient
<Solarion> I was just curious why it was so old
<Solarion> I haven't looked to see if any major fixes were in.  I suspect so, but I'm not certain
<Chipzz> depends on your definition of building of course ;)
<Hobbsee> Chipzz: they add in a patch for the fix, FYI - not the entire new version
<Solarion> Hobbsee: problem is that lots of fixes go "upstram" into libgsf,goffice
<Solarion> so it's not quite so simple.  :)
<Chipzz> Hobbsee: depends; there was a discussion about a new version of evince several weeks ago in which a new version of evince was suggested instead of just that fix
<Chipzz> Hobbsee: but basically, you're right
<Hobbsee> ah
<Chipzz> depends on how big the delta is I suppose
<Chipzz> but I think (not sure), that 1.7.x is a development release
<Chipzz> given the odd minor number
<Solarion> yes
<Solarion> I was wondering why it was chosen over 1.6.x
<Chipzz> Good point; not sure really
<BenC> Solaris: Because if they went with 1.6.x you would have complained more about the age? :)
<Solarion> Solarion: it's a devlopment version, so no
<Solarion> I understand wanting stability
<Solarion> but if you go for broke.... :)
<keescook> BenC: hey, neato.  2.6.20-2.2 solved the CDR info issue.  :)
<BenC> keescook: Gotta love that :)
<cypher1> can anyone pls tell what is this december 21st deadline for "Outstanding Merges" ?
<lifeless> BenC: can we get a virtual package for linux-image-generic-debug, like we have for linux-image-generic ?
<dholbach> good morning
* elkbuntu hugs dholbach
* dholbach hugs elkbuntu back
<cypher1> dholbach: good morning ! :)
<dholbach> hey cypher1
<cypher1> dholbach: how are you ?
<dholbach> thanks a lot... I'm fine - how are you?
<cypher1> dholbach: fine here too although lot of work ;) .. thanks :)
<dholbach> I know the feeling ;-)
<cjwatson> seb128: rejecting specs> Change status -> Definition status: Obsolete
<cjwatson> seb128: (and a status whiteboard comment about why)
<seb128> cjwatson: ok, thank you
<seb128> ogra: new gnome-screensaver (2.17.4) to package
<mneptok> seb128: ooo! gnome-screensaver!
<seb128> mneptok: ooo! new GNOME ;)
<mneptok> seb128: i probably should have written a mini-spec, but how about making the default 'saver in Feisty "blank screen"
<elmo> flying pony module!11!
<seb128> mneptok: why?
<mneptok> seb128: because when it's set to an OpenGL saver (like it is by default) it completely crashes machines with poor drivers. also, it makes no sense on laptops to go into a mode that consumes *more* power when not being used.
<mneptok> seb128: my GF's machine uses the VIA video driver. the default screensaver completely kills X.
<Ng> a pure black screen might be a big confusing, but something very light (ubuntu logo skipping around the screen slowly) would be good
<seb128> mneptok: there is a spec about using opengl hacks only where it makes sense I think
<seb128> mneptok: ogra was supposed to work on that for edgy
<mneptok> k
<seb128> maybe he'll for feisty
<Ng> fyi, the glslideshow screensaver is both pretty and very light on resources afaics
<mneptok> Ng: agreed. a low-resource floating image would be great.
<seb128> mneptok: any problem using a non-opengl hack by default? ;)
<mneptok> seb128: only that in the case of laptops and servers the best screensaver is none at all.
<mneptok> (of course, servers shouldn;t have a GUI, but these are Ubuntu users ...) ;)
<thom> Ng: the BSD  ascii art daemon console screensaver?
<thom> something like that'd be keen
<seb128> mneptok: well, no screensaver is not nice, I like images slideshow by example
<mneptok> or the blinkenlights Star Wars :)
<mneptok> you know, i have never actually watched that all the way through.
<mneptok> having a girlfriend and other outside interests really puts a crimp on the uber0geek lifestyle
<seb128> mneptok: I don't use a screensaver here :p
<seb128> mneptok: I just think users will like something on screen better than a blank screen
<mneptok> seb128: i'll look into something that is both Ubuntu-quality good looking, and resource light.
* seb128 hugs mneptok
* mneptok shuts up about fixing stuff and instead just fixes stuff
<mneptok> what a concept. maybe if it catches on we could actually *do* something with this open source stuff.
<mneptok> ;)
<mneptok> lol. the Matrix screensaver has a "KNOPPIX.RU" ad in it
<Fujitsu> mneptok, of course!
<mneptok> classy.
* imbrandon pokes jono 
<infinity> cjwatson: Dailies back on.  And with only a 23 hour response time, too!
<jono> imbrandon: yo
* dholbach hugs infinity
<cjwatson> infinity: great, thanks
<cjwatson> heh
<cjwatson> you're on holiday, I can cope with long response times
<gpocentek> ogra: are ltsp-server{,-standalone} uninstallable on edubuntu daily builds, or is it a xubuntu issue?
<gpocentek> ok...
<gpocentek> ogra: hello!
<gpocentek> ogra: are ltsp-server{,-standalone} uninstallable on edubuntu daily builds, or is it a xubuntu issue?
<infinity> cjwatson: Hey, it was (barely) less than a day, I'm pretty happy with that. :)
<pitti> hello
<imbrandon> moins pitti 
<cjwatson> sivang: are you going to merge bittornado, moin, and libnotify? your name's listed against them on http://merges.ubuntu.com/main.html
<pitti> sivang, cjwatson: ^ I'm fine with taking libnotify if I shall
<cjwatson> libnotify is only an updated merge, so is less urgent than your other ones
<pitti> cjwatson: I did the apport API changes in ubiquity trunk; is there an easy way to call the gtkui from the source tree without booting a live CD and everything?
<pitti> cjwatson: the change is trivial and I'm fairly sure that it works, but still, I'd like to test it a bit
* Hobbsee waves to pitti 
<pitti> hi Hobbsee 
<cjwatson> pitti: not very easily, unfortunately
<cjwatson> pitti: you could build a package from it and install that, and then run it ...
<pitti> cjwatson: that's fine
<cjwatson> pitti: (remember to 'debian/rules update' first if you're building straight from bzr)
<pitti> oh, thanks, didn't do that
* dholbach hugs rodarvus
<dholbach> X love!
<cjwatson> pitti: you'll also need to bzr update right before committing, as I've been pushing a few changes this morning
<rodarvus> :)
<rodarvus> finally!
<dholbach> yeeeeha
<rodarvus> packages are mostly done, I'm hoping to upload all of them today
<rodarvus> (but I messed my .changes, so am carefully checking each of them as I go)
<cjwatson> rodarvus: thanks
<cjwatson> infinity: mind if I steal your bogl merge?
<cjwatson> infinity: and ndoc and scim?
<Hobbsee> cjwatson: isnt he away?
<infinity> cjwatson: Go nuts.  Feel free to give all my merges away.
<cjwatson> Hobbsee: so ner ;)
<cjwatson> infinity: ta
<cjwatson> mdz asked me to be actually-getting-merges-done czar, so I plan to spend a good chunk of today nagging people ...
<Hobbsee> infinity: you're on holidays!  go away!  stop proving me wrong!  :P
* Hobbsee :P 's at infinity 
* Hobbsee :P 's at cjwatson too, which was her original intention.
<mneptok> lick me too! LICK ME TOO!
* mneptok has a new, improved postage stamp flavor!
* Hobbsee spanks mneptok 
<Hobbsee> mmm...postage stamps....
<Hobbsee> tasty :)
* mneptok has a new, improved postage stamp flavor and red, chafed bottom!
<Simira> mneptok: hey, are you the "new" distro-guy?
<mneptok> uhhh ... no?
<mneptok> am i?
<Simira> mneptok: but you just started working for Canonical, right?
* mneptok checks for important e-mail he may have missed
<Simira> mneptok: trying to keep up on who's who....
<mneptok> if by "just" you mean "6 months ago" then yes :)
<Simira> mneptok: right :p I didn't attend Paris
<Hobbsee> mneptok: if you're getting paid by them, then you're probably working for them
* Hobbsee waves to Simira 
<Simira> hi Hobbsee, how are you?
<mneptok> Hobbsee: not on distro, though. AFAIK.
<Hobbsee> i'm doing OK :)
<Hobbsee> mneptok: ah.  what do you do, apart from hang around on IRC?
<Simira> mneptok: what, then?
* mneptok is senior support staff
<Simira> ah
<Hobbsee> so we blame mneptok when it all goes wrong?  excellent!
<Simira> Hobbsee: nonono, he's the one you can whine to and who will help you when all goes wrong
<Hobbsee> Simira: ahhh...
<mneptok> no, you blame me when it all goes wrong, the package is in Main, you have purchased a support contract, and we can't help you. :)
<Hobbsee> mneptok: why havent you fixed all the bugs yet!!!!
<mneptok> Hobbsee: because you still haven't pruned that hedge that blocks the view to your boudoir from the oak tree in the back yard.
<Simira> ah, I love my dog when he is sleeping... everything is much more quiet then.
<mneptok> i mean, i buy binoculars, and nothing. NOTHING! *sigh*
<Hobbsee> hehe
<Hobbsee> mneptok: get better glasses
<mneptok> Hobbsee: but then i'll have to acknowledge what i *really* look like! allow me my illusions.
<Hobbsee> heh
<pitti> cjwatson: apport API fix tested and committed (yay, my first ubiquity commit)
* siretart_ waves to pitti
<pitti> hey siretart_ 
<siretart_> :)
<Fujitsu> apport API fix... to Ubiquity? Am I missing something here?
<pitti> Fujitsu: yesterday I cleaned up apport's code/module structure
<pitti> Fujitsu: and ubiquity uses apport for crash reporting, too
<Fujitsu> Ah, that makes more sense now :)
<cjwatson> pitti: thanks
<\sh> sorry guys, could be that this was answered on some of our MLs but what is the work order for diffs between ubuntu and debian regarding firefix/iceweasel thunderbird/icedove?
<cjwatson> "work order"?
<\sh> how to change the build-deps e.g. is there any policy?
<cjwatson> \sh: nothing formal as far as I know, but as long as firefox satisfies the dependencies it should be fine
<cjwatson> (or thunderbird, or whatever)
<\sh> so changing build-deps from iceweasel to firefox...
<cjwatson> as usual, do the minimum necessary to make it work and reduce merge pain in future
<cjwatson> Keybuk: an indicator on merges.ubuntu.com for when the person listed as owning the merge isn't in the relevant LP team would be useful
<Keybuk> cjwatson: and impossible to find out
<Chipzz> \sh: doesn't debian use the standalone gecko rendering instead of firefox anyway?
<Chipzz> what's the bloody thing called again...
<cjwatson> Keybuk: why?
<cjwatson> Chipzz: xulrunner. yes.
<Keybuk> cjwatson: getting a list of e-mail addresses out of LP for a team is HARD
<Chipzz> yeah that one :)
<Keybuk> cjwatson: note that sysvinit is deliberately not merged, btw
<cjwatson> Keybuk: heh, sorry, I missed that you'd already posted a merge warning to ubuntu-devel and posted something similar to ubuntu-devel-announce
<cjwatson> Keybuk: what's up with sysvinit?
<Keybuk> cjwatson: we're replacing much of it for replacement-initscripts
<cjwatson> Keybuk: ok ...
<Keybuk> cjwatson: a large portion of the Debian changes are ...different... attempts at merging our changes
<Keybuk> so it's a very sticky merge
<Keybuk> I'd rather just write the startup-tasks job definitions by reading both, than trying to read a single merged shell script that may be broken
<Keybuk> it also has an extraordinarily questionable change to the behaviour of sysvinit!
<sivang> cjwatson: I'm happy to do libnotify as well if pitti hasn't already done it
<cjwatson> sivang: please coordinate with him
<sivang> cjwatson: will do, thanks
<pitti> sivang: go ahead
<ogra> BenC, 2.6.20 behaves very badly for me with bcm43xx
<BenC> ogra: Yeah, it's a known bug (if you mean an oops) that is patch pending
<ogra> ah, cool
<ogra> i resorted to 2.6.19 for now ...
<BenC> cjwatson: I'm going to look over kernel-{wedge,package}, but I'm sort of inclined to not merge them if there's nothing in there that we need
<BenC> they always give me so many problems after merge that never gets noticed till the kernel gets built against them, then I have to fix kernel-{package,wedge} and reupload kernels to get it fixed
<imbrandon> heh
<imbrandon> man i fsk fried my mb on my bday ( today ) , i guess i know what 'm getting today
<Chipzz> BenC: btw, is it known that drivers with firmware don't work on boot?
<BenC> Chipzz: You mean during the initramfs phase?
<Chipzz> BenC: I have a laptop with ipw2200 chipset, and neither 2.6.19 nor 2.6.20 kernels load the firmware on boot
<BenC> Chipzz: sounds like a udev issue, I'd file a bug there
<BenC> firmware works for me with ipw3945
<Chipzz> it does work wif I rmmod ipw2200; modprobe ipw2200 when my laptop is booted
<Chipzz> s/wif/if
<BenC> is ipw2200 getting loaded during initramfs for some odd reason?
<Chipzz> I have no idea really
<Chipzz> haven't looked at it in detail yet
<BenC> Chipzz: hold a sec...
<BenC> Chipzz: zcat /boot/initrd.img-`uname -r` | cpio -i -t  | grep ipw2200
<Chipzz> root@Reel:~# zcat /boot/initrd.img-`uname -r` | cpio -i -t  | grep ipw2200
<Chipzz> lib/modules/2.6.20-2-generic/kernel/drivers/net/wireless/ipw2200.ko
<BenC> Chipzz: grep ipw2200 /etc/initramfs-tools/modules
<Chipzz> BenC: I have:
<Chipzz> MODULES=dep
<Chipzz> in /etc/initramfs-tools/initramfs.conf
<Chipzz> could that be the cause?
<BenC> ah, that's why then
<Chipzz> hrrrm
<Chipzz> pebkac? :)
<BenC> Change it back to "most", and "sudo update-initramfs -u -k `uname -r`", that should fix it
<BenC> In future kernels, the module will be able to list what firmware it needs, and initramfs-tools will be able to copy needed firmware
<Chipzz> can I blacklist ipw2200 from getting in the initramfs?
* Chipzz check
<Chipzz> s
<BenC> You can probably do that, but unless you have a specific reason for not doing "most", I'd change that back
<cjwatson> BenC: I'm not too concerned about those, but if we don't merge them this time, do expect me to nag about getting them merged next time :)
<Chipzz> apart from wanting a smaller initramfs you mean? :)
<BenC> cjwatson: But next time I'll have precedence :)
<BenC> cjwatson: I'll most likely merge them, but if it gets to be too much of a headache, I'll just hold off
<Chipzz> BenC: anyway, is the fix for that going to take a long time or not? if not, I'll just live with it until it gets fixed...
<cjwatson> BenC: *nod*
<BenC> Chipzz: Fix is coming from upstream, and I think is scheduled for 2.6.21, so we wont see it in feisty
<Chipzz> BenC: or is that an upstream issue?
<Chipzz> oh ok
<pitti> cjwatson: can we promote apr and apr-util to main so that apache 2.2 and the reverse depends can build?
<pitti> cjwatson: it also holds up the php5 merge etc.
<cjwatson> pitti: certainly; do they have/need MIRs?
<pitti> cjwatson: they haven't, but they are just split-outs from the former apache source
<pitti> cjwatson: Mithrandir and I agreed that this wouldn't need an MIR
<pitti> do you?
<cjwatson> ok, if you're happy then that's fine with me and I'll promote them
<cjwatson> pitti: done
<pitti> great, thanks
<pitti> then it should be able to build now
<giskard> ogra, did you updated the *dont save session* gpm patch
<pitti> and I can fix php5 for apache 2.2 while I merge it again
<giskard> update*
<ogra> nope
<ogra> oh, i'm an idiot
<ogra> giskard, thanks for pointing, i'll merge it into the gconf-defaults file
* cjwatson goes to steal some of mdz's merges
<BenC> cjwatson: If a package to merge can be done sans all the ubuntu changes, what's the best way to handle that?
<cjwatson> BenC: sounds like a sync
<cjwatson> BenC: you mean, we should just take the Debian package verbatim?
<BenC> cjwatson: Ok, let me verify the build, and I'll let you know
<BenC> right
<giskard> ogra, :) 
<BenC> directfb was nothing but build fixes
<cjwatson> BenC: https://wiki.ubuntu.com/DeveloperResources#syncs
<BenC> cjwatson: Thanks
<doko> cjwatson: the syslinux merge is still outstanding; didn't make any progress yet
<ogra> argh, gcompris was updated ...
<fabbione> BenC, kylem, pitti: git is still uninstallable in main... any chance to get that sorted please?
<kylem> er, why don't you do it?
<BenC> fabbione: We need liberror-perl or something, right?
<fabbione> kylem: because i recall one of you was already looking at it?
<fabbione> BenC: probably
* kylem rolls his eyes.
<fabbione> BenC: i was looking at http://people.ubuntu.com/~cjwatson/testing/feisty_probs.html to kill sparc uninstallable crap
<fabbione> and i noticed git too
<kylem> BenC, i'll do it.
<BenC> kylem: You da man
<cjwatson> pitti: will you have time to look at Till's merges?
<pitti> cjwatson: if he's not around, I could make some time; but I cannot test stuff like hplip at all, and I don't know the foomatic stuff either
<cjwatson> who does? doko's on holiday now
<pitti> (/me too)
<cjwatson> oh
<pitti> cjwatson: that's the problem, apart from Till noone really knows the foomatic stuff
<cjwatson> I'm not sure if Till's around; it's just that it tends to be easier for core-devs to merge directly than to review somebody else's
<mjg59> There's a pretty obvious issue with the hplip-toolbox
<pitti> and he did a lot of modifications recently
<mjg59> It's QT
<mjg59> And needs python-qt3
<ogra> Riddell, would you mind merging the seeds to get the openbsd-inetd switch in ?
<mjg59> So probably shouldn't be in the preferences by default...
<ogra> hmm, no janimo ...
<doko> pitti: my OfficeJet is still defect
<doko> mjg59: which issue?
<pitti> cjwatson: so, I'll take a look at the foomatic stuff, but I'd really prefer to not blindly merge hplip
<cjwatson> pitti: hplip's only an updated merge, so that's a lot better than nothing; thanks!
<mjg59> doko: It appears in the Ubuntu preferences menu, but it won't run without python-qt3
<mjg59> Never mind that it's a completely different interface to print queuing
<mjg59> And ugly, confusing and inconsistent
<doko> mjg59: yes, that's fixed by the updated merge. I can look at it tonight
<mjg59> (I have to admit to not being entirely sure what hplip is for - why doens't cups handle this stuff?)
<cjwatson> doko: it is? the Debian changelog says nothing about that
<cjwatson> +  * dpatch 00_01_upstream-fix-libusb-bigendian (new): Do not hto* libusb
<cjwatson> +    stuff, it does so by itself (at least on the non-ancient versions),
<cjwatson> +    backport from upstream 1.6.12-rc3 (closes: #401530)
<cjwatson> +  * dpatch 00_02_upstream-fix-pragma-pack (new): Do not use pragma pack, use
<cjwatson> +    attribute packed instead, backport from upstream 1.6.12-rc3
<doko> cjwatson: ohh, he updated to a version directly from upstream. didn't notice that
<cjwatson> ah, this was the mail he sent?
<cjwatson> Till doesn't like merging from Debian, AFAICS
<doko> cjwatson: it's difficult, because the debian package is built from CVS directly. I only know about http://www.freestandards.org/~till/tmp/ubuntu/feisty/hplip/
<cjwatson> doko: that's just the version currently in feisty
<cjwatson> doko: the current Debian->Ubuntu patch doesn't seem substantial enough to suggest a different upstream; as far as I can tell the Debian maintainer just isn't using the proper -i options to avoid .cvsignore and such ending up in the source package
<Mithrandir> mjg59: yeah, I have it on my hard drive, I should upload it, sorry. :-/
<bddebian> heya
* thom hugs mvo
<thom> yay
* mvo hugs thom
<mvo> have fun testing it :)
<seb128> are packages prerm supposed to remove alternatives on "upgrade" or only on "remove"? 
<mjg59> Mithrandir: If you could, that would be great
<elmo> seb128: I tend to do it on !upgrade
<elmo> to catch the other possiblities for a prerm
<seb128> elmo: ok, thank you, looks a good idea to me :)
<seb128> There is a bug open about some packages removing the alternative on "remove" and I wanted some other opinion before changing it :) I'll change the package to use != "upgrade"
<cjwatson> seb128: there's a pathetic lack of standardisation about what to do there
<tepsipakki> cjwatson: partman-auto complains about expert recipe being too large. noticed that you made that change ;) When does it say that?
<cjwatson> seb128: e.g. Debian bug #71621
<tepsipakki> cjwatson: I've used basically the same recipe since dapper
<cjwatson> tepsipakki: if the minimum computed total size for the partitions exceeds the amount of free space on the disk
<cjwatson> tepsipakki: my change was just a bug fix; previously, it would have crashed and burned
<tepsipakki> heh, ok.. I think it miscalculates the disk size then
<cjwatson> tepsipakki: -> #ubuntu-installer ?
<tepsipakki> ah
<seb128> cjwatson: do you think that != "upgrade" makes sense?
<cjwatson> seb128: you should exclude failed-upgrade too
<cjwatson> (yeah, I know nobody appears to care about failed-*, but still ...)
<cjwatson> seb128: I'm not sure about prerm deconfigure
<seb128> if [ "$1" = "remove" ]  || [ "$1" = "deconfigure" ]  ; then
<seb128> that's what firefox does
<BenC> cjwatson: directfb still needed 2-of-3 patches, merge done and uploaded
<seb128> (random example picked)
<seb128> BenC: thank you!
<BenC> seb128: quite welcome :)
<cjwatson> seb128: I realise my analysis in that Debian bug is six years old, but it was pretty hideously inconsistent among packages then
<cjwatson> seb128: remove|deconfigure was one of the cases I couldn't unambiguously say was wrong, let's put it that way :-)
<seb128> :)
<pitti> cjwatson: foomatic-db-engine was an easy merge, uploaded; the other two foomatic packages turned into syncs (bugs filed); apart from hplip this covers Till's merges
<pitti> oh, can some archive admin guru please NEW apache2?
<pitti> (sorry for urging, but it blocks merges)
<ivoks> and please just sync atari-fdisk, ubuntu changes are applied in debian
<BenC> Keybuk: ping...got a question about udev
<cjwatson> ivoks: DeveloperResources#syncs
<ivoks> thanks
<fabbione> slomo: you got a fixed mono for sparc
<fabbione> slomo: please make sure to let me know if it breaks again
<cjwatson> pitti: done
<slomo> fabbione: already saw it... thanks :) could you add this patch to the upstream bugreport?
<fabbione> slomo: can you instead? i don't even an account on the bugzilla and so much don't plan to get one
<fabbione> slomo: sending you the original email/patch
<slomo> fabbione: sure... can you upload just the patch somewhere? :)
<slomo> thanks
<xerxas> is that normal that I cannot do apt-cache {search,show} on a feisty ? 
<xerxas> herd 1 , and then update to current 
<seb128> xerxas: how can't you do that? what error do you get?
<xerxas> no error 
<seb128> xerxas: your description is not clear
<seb128> what do you do exactly
<xerxas> root@xerxas-laptop:/home/xerxas# time apt-cache show rssh
<xerxas> real    0m0.016s
<xerxas> user    0m0.016s
<xerxas> sys     0m0.000s
<xerxas> root@xerxas-laptop:/home/xerxas# 
<seb128> and what happens then?
<seb128> sudo apt-get update?
<xerxas> nothing 
<xerxas> done an apt-get update 
<xerxas> and still the same ?
<xerxas> and still the same 
<seb128> do you have some apt sources configured?
<xerxas> yes 
<xerxas> I've added: 
<xerxas> Screenshot of Blaze Audio Voice Cloak 1.1
<xerxas> view screenshot 	Blaze Audio Voice Cloak 1.1
<xerxas> oops 
<xerxas> deb http://download.tuxfamily.org/3v1deb edgy 3v1n0
<xerxas> deb-src http://download.tuxfamily.org/3v1deb edgy 3v1n0
<xerxas> this is for flash9 
<seb128> do you have some Packages file to /var/lib/apt?
<xerxas> root@xerxas-laptop:/var/lib/apt# ls
<xerxas> extended_states  lists  periodic
<seb128> to the lists directory
<xerxas> 24 files within lists 
<seb128> BTW why do you want to use that apt source?
<xerxas> do you want me to list ? 
<xerxas> seb128:  because flash9 isn't in feisty, is it ? 
<seb128> no, that should work, maybe ask to mvo, looks an apt bug
<xerxas> seems so 
<seb128> or something
<xerxas> I can apt-get 
<xerxas> I also can apt-cache dump
<seb128> xerxas: dunno about flash9, that's non free anyway, no?
<xerxas> but no search neither show 
<xerxas> seb128:  yes, that's why I have this apt source 
<xerxas> mvo:  ? 
<xerxas> you there ?
<mvo> xerxas: so you can do apt-get update/install etc? but not apt-cache search/show ?
<xerxas> yes 
<xerxas> also dist-upgrade
<mvo> xerxas: can you please rm /var/cache/apt/pkgcache.bin and see if that changes anything?
<mvo> xerxas: do you use any special LANG setting?
<xerxas> probably 
<xerxas> not special 
<xerxas> but french 
<xerxas> not C 
<xerxas> I think so 
<xerxas> I removed the file 
<xerxas> apt-get update ? 
<xerxas> or apt-cache search ? 
<mvo> apt-cache search
<xerxas> # apt-cache search telepathy
<xerxas> nothing more 
<mvo> and if that doesn't help, please check if switching the languaguge makes a difference
<mvo> xerxas: does switching the language help?
<xerxas> root@xerxas-laptop:/var/lib/apt# echo $LANG 
<xerxas> fr_FR.UTF-8
<xerxas> root@xerxas-laptop:/var/lib/apt# LANG=C apt-cache show rssh 
<xerxas> root@xerxas-laptop:/var/lib/apt# 
<mvo> hmmmm
<xerxas> root@xerxas-laptop:/var/lib/apt# LANG=C apt-cache show rsshttt
<xerxas> W: Unable to locate package rsshttt
<xerxas> E: No packages found
<xerxas> root@xerxas-laptop:/var/lib/apt# 
<xerxas> if that helps 
<seb128> xerxas: strace -e open -f apt-cache show package?
<xerxas> -o log ? 
<seb128> do you get any error while doing that?
<xerxas> want me to send a log ? 
<seb128> no
<mvo> to a pastebin please
<xerxas> -e open , sorry 
<xerxas> -f is childs ? 
* mvo grumbels about his fingers
<Keybuk> BenC: what's up?
<BenC> Keybuk: What the hell is the bus_id that is supposed to be used for bind/ubind?
<BenC> Keybuk: I've tried everything I can think of, including the device name that udevmonitor shows
<Keybuk> same as the name under /sys/bus/*/devices afaik
<Keybuk> I've never got bind/unbind to work :p
<BenC> I always get a ENODEV
<BenC> the function in the kernel looks pretty simple, it uses strcmp(buf, dev->bus_id)
<Keybuk> right
<xerxas> http://pastebin.wikistuce.info/?423
<Keybuk> syndicate pci# ls drivers/tg3
<Keybuk> 0000:00:13.0@  bind  module@  new_id  unbind
<Keybuk> syndicate pci# echo -n 0000:00:13.0 > drivers/tg3/unbind
<Keybuk> syndicate pci# ls drivers/tg3                           
<Keybuk> bind  module@  new_id  unbind
<Keybuk> syndicate pci# echo -n 0000:00:13.0 > drivers/tg3/bind  
<Keybuk> syndicate pci# ls drivers/tg3                         
<xerxas> mvo:  that's the output of strace 
<Keybuk> 0000:00:13.0@  bind  module@  new_id  unbind
<Keybuk> -- 
<xerxas> mvo:  |grep "no such" 
<mvo> xerxas: can you run it again please without the -e trace=open?
<Keybuk> BenC: the -n is important when playing with sysfs :)
<BenC> Keybuk: Yeah, -n was killing me
<xerxas> mvo:  without the grep also ? 
<xerxas> the full output of strace
<BenC> Keybuk: works for me now, thanks
<xerxas> mvo:  want a malone bug ? 
<mvo> xerxas: yes, without the grep too
<xerxas> ok 
<mvo> xerxas: maybe a malone bug, lets wait for the next strace log
<xerxas> mvo:  # wc -l /tmp/log  
<xerxas> 994 /tmp/log
<xerxas> I won't paste that 
<xerxas> creating a bug 
<mvo> xerxas: the pastebin can't handle it? can you put it onto some webspace or mai lit to me?
<mvo> mail it
<xerxas> mvo:  mail yep 
<xerxas> I was creating the bug currently 
<xerxas> mvo:  I can paste , I think the pastebin manages it 
<mvo> xerxas: ok, cool. append it there then please
<mvo> xerxas: and let me know the bugnumber
<xerxas> but the thing is , copy paste 900 lines, I don't want to 
<xerxas> mvo:  what's your mail
<xerxas> ? 
<cjwatson> slomo: could you or somebody who speaks mono have a look at http://librarian.launchpad.net/5461908/buildlog_ubuntu-feisty-i386.ndoc_1.3.1-2_FAILEDTOBUILD.txt.gz ?
<cjwatson> please
<slomo> cjwatson: sure, one moment
<bhale> cjwatson: looking
<bhale> ooh
<cjwatson> thanks
<cjwatson> I was pretty sure all the Ubuntu changes were unnecessary now, so synced - the build failure doesn't seem to be related to any of them anyway
<slomo> no, there seems to be something really unhappy ;)
<bhale> a mystery crash
<slomo> bhale: no... just 150 minutes of no console output... i remember ndoc to build in less than a minute
<xerxas> mvo: synaptic seems to work 
<bhale> oh the buildd killed it
<bhale> slomo: you know muine is almost ready to release with managed dbus :)
<bhale> im not sure there is anything else with libdbus-1-cil
<bhale> (no feisty handy)
<slomo> bhale: there is... unfortunately it's one of the packages i maintain in debian too, gshare :/ i guess i have to port it myself
<bhale> slomo: :(
<bhale> i guess I need to work on muine and tomboy in Debian
<bhale> dajobe said he was going to give them up a awhile ago, and i havent seen him touch them
<bhale> beagle is behind too
<slomo> bhale: but we planned to simply replace dbus-sharp with alp's one shortly after etch release in debian... and i guess we can do it for feisty already too. there should be a gac'able version in the middle of january
<bhale> bye slomo :)
<slomo> bhale: but we planned to simply replace dbus-sharp with alp's one shortly after etch release in debian... and i guess we can do it for feisty already too. there should be a gac'able version in the middle of january
<slomo> bhale: can you reproduce ndoc build failure on x86? works fine on ppc
<fabbione> slomo: bingo...
<bhale> slomo: ENOLINUX :(
<bhale> believe it or not
<fabbione>  feisty sparc   Successfully built
<slomo> fabbione: yay :)
<bhale> slomo: mailing myself to test it
<bddebian> cjwatson: You about?
<LaserJock> I was going to go for Keybuk, but OK
<bddebian> Oh yeah, whoops, Keybuk
<LaserJock> either way
<bddebian> Apparently they're both hiding ;-)
<Keybuk> hmm?
<bddebian> Keybuk: WRT to your e-mail.  Are the Univserve/Multiverse syncs/merges to be done by Thursday also?
<slomo> cjwatson: was ndoc tried twice with the same error?
<LaserJock> we are a little confused about the "Merges must be done by Thursday"
<cjwatson> slomo: not to my knowledge
<cjwatson> bddebian: it's just main/restricted
<LaserJock> when was that decided?
<vdepizzol> can ubuntu feisty come with beautiful icons in gaim? http://img139.imageshack.us/img139/4732/capturadatelalistadeamilz6.png
<LaserJock> I don't see any discussion that merges had to be done by Debian Import Freeze, aren't they traditionally allowed until UVF?
<Keybuk> I thought universe was following the same freeze dates as main this time?
<Keybuk> LaserJock: it was discussed during the FeistyReleaseSchedule BOF at UDS-MTV
<slomo> cjwatson: so let's just retry it one time... might be just bad weather :)
<LaserJock> Keybuk: but I don't see where it is communicated to devs, I might have missed it.
* bddebian thanks LaserJock for confusing him :)
<Keybuk> LaserJock: wiki.ubuntu.com/FeistyReleaseSchedule
<Keybuk> it's very clear
<LaserJock> well, it's really not to me
<LaserJock> it looks like MoM will stop running on Thursday
<Keybuk> "Remaining upstream merges completed" ?
<Keybuk> that's not clear ?
<LaserJock> "Prior to this date, new versions of packages will be automatically imported from Debian where they have not been customized for Ubuntu. After, this will only happen by explicit request from a developer."
<Keybuk> see the note
<LaserJock> but it doesn't make much sense
<LaserJock> but all right
<Keybuk> why not?
<Keybuk> what doesn't make sense?
<LaserJock> because you still don't have UVF
<Keybuk> ?
<LaserJock> so we can have new upstream versions, but no merging?
<Keybuk> right, outstanding merges and automatic syncs stop on thursday
<Keybuk> but there's still a couple of months during which updates can be done without freeze exception approval
<LaserJock> well, ok
<vdepizzol> can ubuntu feisty come with beautiful icons in gaim? http://img139.imageshack.us/img139/4732/capturadatelalistadeamilz6.png
<LaserJock> it just isn't clear to me why you would allow new upstream versions (whether sourced from Debian or not) while not allowing merges
<Keybuk> LaserJock: oh, I remember
<Keybuk> it's the last safe point before etch releases
<LaserJock> ah
<Keybuk> and if we merge past this Thursday, we'll end up suffering huge changes as Debian upload all the crack they've been sitting on for months
<LaserJock> that makes sense
<mc44> is etch releasing then?
<LaserJock> it's like waiting for an earthquake, or a volcano eruption
<LaserJock> you know it's going to happen "soon" but you can't pinpoint it
<Keybuk> and getting rained on by liquid magma is one way to ruin christmas
<LaserJock> hehe
<Robot101> Keybuk: are you aware of any iftab breakage in etch?
<\sh> oh christmas...I think I need to s/2006 Dec 24/2007 Jun 10/ or so...
<Keybuk> Robot101: -v
<keescook> mornin'
<Robot101> Keybuk: -v on what?
<seb128> hey keescook!
* keescook hugs seb128
* seb128 hugs keescook back :)
<_ion> robot101: /lastlog robot101
<Robot101> I thought he was telling me to run a program with -v :P
<Robot101> otherwise it should've been: killall robot101; robot101 -v
<_ion> Not a program but a question. :-)
<Robot101> Keybuk: less specifically, my iftab applies reliably when I initially boot, but is totally non-deterministic when resuming from suspend. I either get wired and eth0, eth0 and wireless, eth0 and eth1, or eth1 and eth0
<Robot101> (iftab names them to wired and wireless)
<Keybuk> Robot101: I've heard that
<Robot101> Keybuk: how can I debug it?
<Keybuk> Robot101: dunno, never seen resume working, so don't know how it works
<Robot101> hm
<Robot101> but how can I see what's going on?
<Keybuk> running udevmonitor will show you what udev
<Keybuk> does
<Keybuk> udevcontrol log_priority=info will add more to syslog
<Keybuk> no idea whether that all works though
<Keybuk> as to what actually happens, no idea
<Keybuk> ask mjg59
<mjg59> Modules get loaded. udev is supposed to deal.
<mjg59> There's nothing about it that's suspend/resume specific
<mjg59> Keybuk: You could test by just removing the final call to /sys/power/state
<Keybuk> mjg59: removing from what?
<mjg59> /etc/acpi/sleep.sh
<Keybuk> as long as that doesn't kill udev, there's no reason it shouldn't work
<Keybuk> I think the problem is that some modules don't get removed
<Keybuk> yet, for some reason, they destroy and then reactivate their interfaces
<mjg59> That would seem unlikely
<Keybuk> perhaps its firmware and power-off related?
<Keybuk> when suspend, the device loses all state
<mjg59> They won't remove their interfaces unless they're removed
<Keybuk> and thus destroys its interfaces
<Keybuk> and on resume, has to have the firmware reloaded and gets new interfaces?
<Keybuk> why not?
<Keybuk> that's a huge assumption :p
<mjg59> Because that's not what drivers do
<mjg59> Nothing in the suspend path touches the netdev structures
<Keybuk> err, the suspend path in the kernel gives a driver an opportunity to do whatever it onces
<Keybuk> s/onces/wants/
<mjg59> Yes
<mjg59> And network drivers don't tear down their interfaces
<Keybuk> *shrug*
<Keybuk> a brief read of a random module I picked says you're wrong <g>
<pitti> question to our shell gurus: I want to find all empty .po and .pot files which are not contained in hidden directories; does this look halfway correct? find -mindepth 1 -name '.*' -prune -o \( -name "*.po" -o -name "*.pot" \) -empty -print
<mjg59> Keybuk: ?
<mjg59> Keybuk: The closest I can find are calls to netif_device_detach()
<mjg59> And those just prevent the network layer from queuing any more work on the device
<mjg59> The interface doesn't go away
<mjg59> (Easy check: echo -n 2 >/sys/class/net/eth0/device/power/state
<Keybuk> mjg59: how will that help?
<mjg59> Keybuk: Does it make the interface go away?
<Keybuk> mjg59: it just gave -EINVAL
<mjg59> Oh, that's interesting
<mjg59> Nnngh.
<mjg59> CONFIG_PM_SYSFS_DEPRECATED
<Treenaks> mjg59: sysfs deprecated?!
<mjg59> No, that can't be it
<pitti> Treenaks: AFAIUI only the general 'power' attributes in sysfs are deprecates
<mjg59> And we've got that enabled anyway
<mjg59> So that's not why this has stopped working
* mjg59 pokes further
<pitti> Treenaks: it was allegedly impractical to use in its generality, so they wanted to redesign it per bus
<mjg59> Not that they've redesigned it per bus yet
<mjg59> Ngh.
<tkamppeter> pitti, ping
<Keybuk> mjg59: it's a mystery to me, the vague reports I've had don't really make sense
<mjg59> Keybuk: Ok. If you want to test this, you'll have to go back to 2.6.17
<mjg59> Or do as I suggested earlier, and fake the entire suspend/resume cycle
<Keybuk> mjg59: I have faked it, didn't change the interfaces for me
<mjg59> Keybuk: It doesn't on every attempt
<Keybuk> it seems to only do it if a real suspend is involved
<mjg59> The code called in the network modules is identical
<mjg59> The only way there could be any difference would be for the modules to not get unloaded
<mjg59> Which is trivial to verify
<Keybuk> it definitly works if the modules are unloaded/loaded
<Keybuk> becauses that's how I test things
<mjg59> Well
<mjg59> Is there any mechanism by which modprobe -r can return without either having failed or the module being unloaded?
<Keybuk> shouldn'tbe
<tkamppeter> doko, ping
* mjg59 shrugs
<mjg59> The modprobe calls are there
<Keybuk> heh
<Keybuk> I wonder what ifconfig'ing wifi0 down does
<Keybuk> for x in /sys/class/net/*; do
<Keybuk>     if [ -e $x/device/driver ] 
<Keybuk>         then
<Keybuk>         MODULES="$MODULES $(basename $(readlink $x/device/driver) | tr [:upper:\
<Keybuk> ]  [:lower:] )"
<Keybuk>     fi
<Keybuk> done
<Keybuk> mjg59: there's a module symlink in device/driver
<Keybuk> so $x/device/driver/module is guaranteed to give you the module name
<mjg59> Keybuk: There may be now - there wasn't when that was written
<linnuxxy> im working on building a Arabic version of ubuntu... it is an Ubuntu Desktop CD with arabic support packages installed and configured by default... is there a similar projects... even for different languages?
<LaserJock> all it is is Ubuntu+arabic lang support?
<linnuxxy> + artwork
<linnuxxy> yes
<linnuxxy> i've used uck... and it worked ok as a first step
<mjg59> Keybuk: Might be 5 minutes late to tb
<LaserJock> linnuxxy: you might as some of the LoCo teams, I think they've been doing a fair amount of that sort of thing
<ajmitch> morning
<tkamppeter> pitti, doko, ping
<Keybuk> mjg59: the weird thing is that the reports I've got about misbehaving network names on resume come from people with "sensible" hardware
<mjg59> Yes
<mjg59> I'm really not sure what's up
<Keybuk> the only thing I could think of is that somehow udev doesn't get the messages
<Keybuk> which implies kernel badness
<mjg59> On resume, I'd expect there to be quite a lot of messages
<fabbione> Keybuk: can you please give back beagle on sparc?
<Keybuk> fabbione: is infinity not around?
<Keybuk> mjg59: hardly more than on boot though, no?
<fabbione> Keybuk: he is on vacation
<fabbione> Keybuk: so is Mith
<Keybuk> heh, so amI
<fabbione> i think you are the only one around :)
<bhale> fabbione: yay dmiller!
<fabbione> yeah i know.. i am trying to sort out stuff that doesn't install
<Keybuk> fabbione: given back
<fabbione> cjwatson: are you around?
<fabbione> Keybuk: thanks mucho
<fabbione> Keybuk: gnome-applets seems to need the same love... there might be more.. i am just digging into all the stuff
<pitti> Keybuk: can you please give-back shadow? I fixed pkgbinarymangler to not make it FTBFS any more
<fabbione> Keybuk: that should do it.. the others are in DEPWAIT
<fabbione> Keybuk: thanks a lot man
<Keybuk> done anddone
<fabbione> Keybuk: thanks.. this should make ubuntu-desktop installable again on sparc
<pitti> Keybuk: cheers
* pitti waves good night for the evening
#ubuntu-devel 2006-12-20
<keescook> Seveas: pitti mentioned you had an RSS feed of USNs somewhere, is that still true?
<Seveas> keescook, yes, but it is currently not updating (since ~12 hours)
<Seveas> and it will change location within the net days
<Seveas> next*
<a_thing> Does http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.15/linux-source-2.6.15_2.6.15.orig.tar.gz have any nonfree firmware?
<LaserJock> a_thing: I don't think so, but you could as #ubuntu-kernel
<fabbione> so who feels lucky with shell scripting today?
<somerville32> fabbione: I do but if you're asking for help then it must be something bad so most likely not :P
<fabbione> somerville32: no, i am just very tired to see what i am doing wrong
<fabbione> i am pretty sure it's trivial
<somerville32> fabbione: I can take a look but I warn you I'm pretty tired too
<fabbione> fabbione@rainy:~$ echo $partnum
<fabbione> 62
<fabbione> fabbione@rainy:~$ partalpha=$(printf '\x'$partnum)
<fabbione> fabbione@rainy:~$ echo $partalpha
<fabbione> b
<fabbione> fabbione@rainy:~$ dash
<fabbione> $ partnum=62
<fabbione> $ echo $partnum
<fabbione> 62
<fabbione> $ partalpha=$(printf '\x'$partnum)
<fabbione> $ echo $partalpha
<fabbione> \x62
<fabbione> bash gets it right
<fabbione> dash doesn't
<fabbione> i just can't get it
<Chipzz> fabbione: maybe a built-in vs external issue?
<fabbione> Chipzz: both built in
<fabbione> man pages claim same implementation options
<sfllaw> fabbione: Looking for POSIX documentation.
<Chipzz> # file /usr/bin/printf 
<Chipzz> /usr/bin/printf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
<fabbione> <fabbione> Chipzz: both built in <-------
<fabbione> the external errors on that call
<Chipzz> yes, but maybe dash is using the external one, or the other way around?
<fabbione> Chipzz: no, you are just guessing. I just told you.. read the man pages
<sfllaw> fabbione: dash's builtin behaves that way.
<Chipzz> ok, just trying to help
<fabbione> or try what i did and see it yourself
<fabbione> sfllaw: yeah but it shouldn't
<sfllaw> fabbione: Reading POSIX documentation now.
<fabbione> sfllaw: danke
<Chipzz> fabbione: I'm reading the dash manpage, and it doesn't mention \x
<sfllaw> fabbione: IEEE Std 1003.1 (2004) does not require \x.
<sfllaw> fabbione: It merely requires octal.
<Chipzz>                   \num    Write an 8-bit character whose ASCII value is the 1-, 2-, or 3-digit octal number num.
<Chipzz> (from man dash)
<fabbione> Chipzz:             diouXx      The argument is printed as a signed decimal (d or i), unsigned octal, unsigned decimal,
<fabbione> sfllaw: hmmm
<Chipzz> fabbione: no, that's something else entirely
<Chipzz> fabbione: the x is a modifier for % kinda things
<Chipzz> like printf('%d', 1)
<sfllaw> Chipzz: The \xHH is a GNU extension that takes the HH and turns it into a character.
<sfllaw> fabbione: So you have a bashism there.
<Chipzz> sfllaw: I never mentioned that ;)
<fabbione> sfllaw: ok, what's the right fix?
<somerville32> heh
<sfllaw> fabbione: Well, what are you trying to do in the first place?
<sfllaw> fabbione: You got a hex character numerically?
<fabbione> sfllaw: i can make it decimal.. basically i need to convert 1 to 8 -> a to h 
<sfllaw> Use tr
<sfllaw> tr/1-8/a-h/
<Chipzz> fabbione: 
<fabbione> sfllaw: with something that's in d-i
<Chipzz> printf '%x\n' 100
<Chipzz> 64
<Chipzz> that's the x you were pasting
<sfllaw> Or, if you don't want to fork, make it octal.
<Chipzz> unrelated to \x ;)
<fabbione> Chipzz: no. you took your route that's nothing to do with what i am asking...
<sfllaw> fabbione: You can definitely write:
<sfllaw> partalpha=$(printf '\'$partoctal)
<Chipzz> fabbione: 
<Chipzz> 08:18 < Chipzz>                   \num    Write an 8-bit character whose ASCII value is the 1-, 2-, or 3-digit octal number num.
<Chipzz> 08:19 < fabbione> Chipzz:             diouXx      The argument is printed as a signed decimal (d or i), unsigned octal, unsigned decimal,
<fabbione> sfllaw: what's the equivalent of a in octal ?
<Chipzz> you were referring to something different ;)
<sfllaw> fabbione: Looking...
<fabbione> Chipzz: read a few lines above that in the man page
<sfllaw> fabbione: lowercase a is 141.
<sfllaw> partoctal=$((140+$i))
<fabbione> sfllaw: great thanks
<sfllaw> fabbione: Most welcome!
<fabbione> let see if it works
<fabbione> sfllaw: thanks that works
* somerville32 is happy he could help.
<somerville32> :)
<sfllaw> fabbione: Hurray!  All those years hacking on portable shell scripts has finally been worthwhile.
<sfllaw> I can die a happy man.
<sfllaw> Or at least sleep.
<sfllaw> Good night, fabbione.
<fabbione> sfllaw: night dude.. cya soon in the nightmare world
<fabbione> i am about to die too
* fabbione just got OBP -> {SBUS,PCI} -> sysfs device mapping
<sfllaw> W00T!
<fabbione> fabbione@rainy:~$ ./bus /dev/sda2
<fabbione> obppath: /pci@7c0/pci@0/pci@8/scsi@2/disk@0,0:b
<fabbione> that means that we can set OBP and silo.conf for autobooting and extra OS'es
<somerville32> What should I do if I _think_ I may have provided the wrong patch for an SRU and the SRU got approved? lol
<fabbione> somerville32: did you already upload the package?
<somerville32> No.
<sfllaw> somerville32: File a bug and reference the SRU.  Then ping the right people.
<fabbione> somerville32: then there is nothing to worry... add stuff to the bug and ask for another review
<somerville32> kk
<sfllaw> Well, fabbione is right as well.
* somerville32 nods.
<hunger> The new kernel for feisty is getting stuck for me during boot. Is there any known incompatibility? Last time I had this mathew looked into it and he found some setting in /etc/network/interfaces that was to blame.
<Treenaks> the kernel got stuck on /etc/network/interfaces?
<Treenaks> that's weird :)
<hunger> Treenaks: Yeap, I thought so, too.
* hunger is pretty sure that it was /e/n/i... he might be wrong though.
<coopster> Just a thought - not sure why the 'safe graphics mode' X driver on the live cd changed from vesa to nv, but i'd request it be changed back, as nv hangs for me
<mdke> coopster: can you file a bug?
<seb128> morning
<Fujitsu> Hi seb128.
<seb128> hi Fujitsu
<cjwatson> fabbione: there's something that uses printf in d-i already
<cjwatson> coopster: there's an existing bug about that. It's not that safe graphics mode uses nv (for everyone), but it's that safe mode gets overridden by something later on in the xserver-xorg maintainer script
<cjwatson> coopster: bug 59618
<dholbach> good morning
<cjwatson> fabbione: ah yes, I was thinking of converting in the other direction, using e.g. printf 'a => 97
<mvo> hey dholbach
<dholbach> hey mvo
<sivang> morning
* cjwatson grabs the festival merge
<cjwatson> TheMuso: ^--
<TheMuso> cjwatson: Fine by me. I currently have my hands full with events of the current season.
<TheMuso> My speech-tools merge is open for anyone who wants it also
<cjwatson> TheMuso: ok, I'll take it
<cjwatson> morning Scott
<Keybuk> good morning Colin
* Hobbsee waves to cjwatson and Keybuk 
<Keybuk> cjwatson: I trust that you are well today?
<cjwatson> Keybuk: just spangly, thank you kind sir
* mvo takes bittornado 
<cjwatson> ha, that was a rather pointless merge
<cjwatson> $ dscdiff festival_1.4.3-17.1ubuntu5.dsc festival_1.4.3-17.2ubuntu1.dsc | diffstat
<cjwatson>  changelog |   18 ++++++++++++++++--
<cjwatson>  1 file changed, 16 insertions(+), 2 deletions(-)
<cjwatson> mvo: hmm, there's an outstanding sync request from you for bittornado; is that still valid? I'll do it now if so
<siretart> seb128 seems to have fun just reassigning totem-xine bugs to libxine1 ;)
<tepsipakki> cjwatson: 12:17  * mvo takes bittornado
<seb128> siretart: well, those crashes happen to xine-lib, but yeah, I've fun moving those away from totem, it has already enoughs bugs without adding those :p
<cjwatson> tepsipakki: yes, I know
<ogra> cjwatson, bug 76573 is for you :)
<Ubugtu> Malone bug 76573 in ttf-dustin "please sync ttf-dustin 20030517-4 from debian sid" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76573
<cjwatson> tepsipakki: that's WHY I'm reminding him that there's an open sync request and a merge is probably unnecessary
<cjwatson> ogra: will do
<siretart> seb128: heh - I can imagine
<seb128> siretart: totem upstream seems to be flooded by useless backtraces from totem-xine :/
<siretart> seb128: I still need to figure out how to get useful xine-lib backtraces from the crash reports. I'll do that as soon xine-lib 1.1.3 is uploaded, which is blocked by FFmpeg promotion to main
<seb128> siretart: do you have any idea why the Debian,Ubuntu package has almost no libxine symbol?.
<tepsipakki> cjwatson: oh.. sorry, sync != merge :)
<seb128> siretart: well, you can get useful backtrace by using the same xine-lib version to start
<siretart> seb128: the package already strips all debug symbols to  libxine1-dbg
<seb128> siretart: "apport-retrace crash" with the -dbg installed
<siretart> so it should just be a matter of having that package installed
<seb128> siretart: right, but even stripped
<siretart> seb128: not nice :(
<seb128> siretart: what is not nice?
<siretart> 11:33:29 < seb128> siretart: "apport-retrace crash" with the -dbg installed
<siretart> aah, I read that apport-retrace itself crashes
<seb128> it's one command to run
<seb128> ah, okj
* dholbach hugs pitti for that
<seb128> siretart: http://bugzilla.gnome.org/show_bug.cgi?id=387772, upstream bugs look like that
<cjwatson> ogra: your statement that the changes are included in Debian is not accurate, actually, if you look closely - but it doesn't matter because the change only matters for partial upgrades from warty to feisty :-) so I'll sync it anyway
<Ubugtu> Gnome bug 387772 in general "crash in Movie Player: playing a video" [Critical,Unconfirmed]  
<siretart> ok. will do that. right now, I rather focus on xine-lib 1.1.3. that one should fix quite some bugs
<seb128> siretart: usually stripped package still give some clue of the function calls, without details but function names by example
<Mithrandir> cjwatson: we don't _really_ care about partial upgrades from warty to feisty, do we? :-P
<cjwatson> Mithrandir: no
<ogra> cjwatson, heh
<seb128> siretart: according to upstream libxine stripped from other distro behave correctly compared to the Debian (and Ubuntu now) version
<siretart> seb128: in that backtrace, where did it crash in xine?
<mvo> cjwatson: yes, the sync is still valid
<seb128> siretart: well, no idea, the backtrace is pretty empty, that's the problem :p
<siretart> I see several threads, which block on a conditional variable
<siretart> well, at least an unresolved address should be there
<siretart> be there symbols or not, I don't see why that particular crash should come from libxine
<siretart> if you have suggestion how to improve this in 1.1.3, I'm happy to hear
<seb128> siretart: I don't say that one comes from libxine, I say that crashes from totem-xine look like that
<cjwatson> mvo: (done)
<seb128> siretart: and according to upstream on other distribution they have libxine symbols and are better
<mvo> cjwatson: moin needs a sync as well, shall I file a bug?
<seb128> siretart: not really, out of not stripping by default
<seb128> siretart: maybe it's stripped twice or something?
<siretart> seb128: well, most code of xine is loaded via dlopen() at runtime
<seb128> siretart: the crash from https://launchpad.net/distros/ubuntu/+source/xine-lib/+bug/76566 is not that useful neither
<Ubugtu> Malone bug 76566 in xine-lib "Totem crash" [Undecided,Unconfirmed]  
<siretart> this still doesn't explain why other distros have better backtraces
<seb128> lucky that we have apport :p
<seb128>  #0  0xb16a41b5 in ifilter_bank ()
<seb128>     from /usr/lib/xine/plugins/1.1.2/xineplug_decode_faad.so
<seb128>  No symbol table info available.
<seb128>  #1  0x000003ff in ?? ()
<seb128> etc
<seb128> yeah
<siretart> this looks better, looks like a bug in the faad library
<seb128> right, but still, that's only 1 function
<seb128> which is pretty minimalistic for a bt
<seb128> anyway, we have apport now so that should be better ;)
* mvo has done moin
* mvo looks at pan
<cjwatson> mvo: yes, bug reports are right; it's easier to do syncs in batches than individually
<mvo> cjwatson: thanks, added it
<ajmitch> looks like I requested a sync of ttf-dustin just at the wrong time
<ogra> ajmitch, why didnt you assign it to the ttf-dustin package ? i looked if there are bugs for it before i submitted the request ...
<ajmitch> ogra: you filed your sync request a few minutes before I did
<ogra> ah, k 
<cjwatson> ogra: he did
<ajmitch> since there weren't any when I looked earlier
<ogra> i guess i was caught by the LP mail delay ...
<ajmitch> doesn't matter, as long as the list gets shorter :)
<ogra> yeah
<ogra> is anybody doing squid ? 
* ajmitch looks at krb5
<ogra> seems not, i'll do it then ...
<cjwatson> I'll take the X fonts
* mvo does python-xml
<cjwatson> X fonts done
<cjwatson> I'm going to scan through libx* for syncs
<cjwatson> rodarvus: consider me to have stolen all those bits of X that are just syncs. I should be done by the time you get up.
<ajmitch> cjwatson: why is mysql-dfsg-5.0 on the list? I see it has a -1build1 version
<cjwatson> ajmitch: sync probably failed due to different .orig.tar.gz
<ajmitch> md5sum matches in .dsc
<ajmitch> looks like -2 was uploaded to debian in the last day or so
<ajmitch> so I guess MoM was run before the last sync run
<jelmer> 'morning cjwatson, ajmitch 
<ajmitch> hey jelmer 
<cjwatson> ajmitch: actually I think it's because -1build1 was uploaded six days ago and Keybuk hasn't done a full autosync run since then
<cjwatson> Keybuk: ?
<cjwatson> I synced it just now and it worked fine
<Keybuk> cjwatson: uh, yeah
<ajmitch> alright, thanks :)
<Keybuk> should do one of those :)
<Keybuk> 6 days seems excessive though
<cjwatson> -rw-r--r-- 1 lp_publish lp_publish 140957 Dec 14 19:03 /home/lp_archive/ubuntu/pool/main/m/mysql-dfsg-5.0/mysql-dfsg-5.0_5.0.30-1build1.diff.gz
<Keybuk> maybe I didn't do one on friday
<Keybuk> hmm, no, did one friday
<Keybuk> so 5 days :)
* Keybuk does one now
<cjwatson> give me a while to finish going through the X libraries, and then I'll unlock ~/syncs for you
<Keybuk> right
<Keybuk> just noticed that you had the lock
<Keybuk> ping me :)
<cjwatson> will do
<Keybuk> cjwatson: xbase-clients and xutils ... are those likely to be sync'able from Debian?
<cjwatson> probably not, from memory
<cjwatson> I think we Just Do Those Differently :(
<gebruiker_> why is that ubuntu still uses /dev/hd* or /dev/sd* while we can use /dev/disk/* ?
<Fujitsu> `we'?
<Keybuk> gebruiker_: we don't
<Amaranth> i thought everything used UUID now
<Keybuk> Ubuntu uses UUID=...
<Fujitsu> Amaranth, I thought so too.
<Keybuk> which is mapped to the most appropriate device
<gebruiker_> well entry still shows sda or hda in fstab
<Keybuk> gebruiker_: are you running edgy or feisty?  it should have been migrated to using UUID=...
<gebruiker_> edgy atm
<Keybuk> you installed with edgy fresh?
<gebruiker_> ie grub still uses root=/dev/hd* or /dev/sd*
<Keybuk> grub should also have been migrated to using UUID=...
<gebruiker_> edgy fresh
<Keybuk> that's odd; it should have been written as root=UUID=... and UUID=... by the installer
<rodarvus> Keybuk, cjwatson: Debian decided to merge all X.Org apps created by daniels into xbase-clients, but there is no need to sync it. We have all latest versions (with exception of luit, xfs, twm and <another one I forgot>)
<cjwatson> grub might not have been
<cjwatson> don't recall there
<cjwatson> http://bazaar.launchpad.net/~ubuntu-core-dev/grub-installer/ubuntu/ ;-)
* elkbuntu hates uuids
<cjwatson> rodarvus: libx* synced, more or less. I haven't dared to look at libx11 yet.
* elkbuntu has a really really fun quadboot because of it
<rodarvus> cjwatson: I have libx11 halfway done. (was supposed to be done, but failed miserably)
<cjwatson> rodarvus: what's your current state with regard to xserver-xorg-input-* and xserver-xorg-video-*?
<cjwatson> rodarvus: do those have to go after xorg-server? If so, what's the state of that merge/sync?
<rodarvus> cjwatson: there is no xorg-server merge from debian
<cjwatson> rodarvus: http://merges.ubuntu.com/main.html disagrees with you.
<rodarvus> debian has 1.1.1, we will use 1.2.0
<rodarvus> cjwatson: thats just version numbering :) (and they got their patches from us)
<cjwatson> rodarvus: we should merge the Debian packaging at least, even if we then move to a newer upstream
<cjwatson> this is important for other people's sanity
<rodarvus> oh, the packaging is merged already
<cjwatson> can you please upload that, then?
<rodarvus> (but I'll give it another review in a few hours, then)
<cjwatson> even if it's only a temporary waypoint
<rodarvus> sure
<cjwatson> what about the drivers?
<cjwatson> we need to get the merge list down to a sane number today
<rodarvus> *nods*, drivers are easier to do. They will be syncable after xorg is uploaded
<rodarvus> (that will happen after the libs are done, ideally)
<cjwatson> I thought you said the other day that they would each require a small control file change?
<cjwatson> the libraries are done
<cjwatson> aside from libx11
<rodarvus> cjwatson: yes, xorg will have the change I mentioned
<cjwatson> but the driver packages don't require that?
<rodarvus> they do
<rodarvus> the temporary will be uploaded before them
<rodarvus> (in a little while)
<sivang> cjwatson: It turns out that I'll be too busy with some RF stuff to care for those merges, so anybody can grab the stuff remaining on my list for the dead line.
<sivang> cjwatson: sorry
<sivang> slomo: ^^
<ajmitch> sivang: there's just 3 on the main list that I see, anyway
<sivang> ajmitch: indeed, so anybody is free to do them at will without notifying me :)
<ajmitch> I think mvo has looked at bittornado & moin already
<sivang> ajmitch: cool, so there's only libnotify then
<mvo> sivang, ajmitch: I can do libnotify too
<ajmitch> alright :)
* ajmitch will go & sleep then
<sivang> mvo: cool, thanks alot
<tepsipakki> is someone merging dcraw? I'll take a look at it if possible
<cjwatson> sivang: ok
<tkamppeter> pitti, ping
<mvo> cheers sivang
<tkamppeter> doko_, ping
<cjwatson> tepsipakki: please do
* StevenK idly wonders if doing a main merge is not pointless
<Hobbsee> StevenK: there seem to be many willing sponsors, currently, as they want the merges done.
<infinity> StevenK: You might even get me to sponsor a few, despite my supposed VACness.
<StevenK> Heh
<mvo> tkamppeter: doko_ is IIRC already on VAC 
<StevenK> cjwatson: Do you mind if I snarf squid?
<mvo> StevenK: I think ogra voiced interesst in it
<StevenK> mvo: Speaking of, did you get a chance to look at libept yet?
<tkamppeter> mvo, is pitti still here, or did he leave, too?
<cjwatson> StevenK: squid seems to be done
<mvo> tkamppeter: on leave too
* StevenK updates his madison-lite cache first
<cjwatson> reload the page
<mvo> StevenK: that was a FTBFS, not a merge, right?
<cjwatson> Keybuk: unlock syncs
<tkamppeter> mvo, who could upload some packages for me?
<StevenK> mvo: Correct.
<cjwatson> rodarvus: do you have xutils-dev merged? If not, I'll do it
<cjwatson> rodarvus: ditto xterm
<StevenK> mvo: But I think it was due to the apt Ubuntu changes.
<rodarvus> cjwatson: go ahead
<rodarvus> thanks!
<Keybuk> cjwatson: thanks
<mvo> tkamppeter: what package?
<mvo> StevenK: ok, looking now
<tkamppeter> mvo: splix, foomatic-db, gutenprint, hplip
<tkamppeter> mvo: splix is a new printer driver, fixes bug 59829
<Ubugtu> Malone bug 59829 in Ubuntu "No driver for Samsung ML-1610 printer" [Wishlist,Needs info]  http://launchpad.net/bugs/59829
<tkamppeter> Gutenprint due to bug 59324 and the Debian merge deadline
<Ubugtu> Malone bug 59324 in foomatic-db "Cups filters are not bundled with Ubuntu altough the PPD are present" [Medium,In progress]  http://launchpad.net/bugs/59324
<mvo> tkamppeter: where can I download the packages?
<tkamppeter> foomatic-db for a vast improvement of Brother host-based printer support
<tkamppeter> hplip due to the merge deadline
<StevenK> Keybuk: Do you mind if I look at the cyrus-sasl2 merge?
<tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/feisty/gutenprint/
<tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/feisty/splix/
<tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/feisty/foomatic-db/
<tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/feisty/hplip/
<Keybuk> StevenK: go for it
<StevenK> Keybuk: Thanks
<Keybuk> seb128: is gnome-gpg broken?
<seb128> cjwatson: could you have a look on bug #76301 when you have some time? That's a gnome-vfs SRU for edgy to fix ekiga crashing sometimes when closed, upstream already mailed me several time to complain about the bug flood they get and I would appreciate having the edgy-proposed update accepted before holidays if possible ;)
<Ubugtu> Malone bug 76301 in gnome-vfs2 "patch from CVS to fix crash triggered when closing ekiga by example" [Medium,Confirmed]  http://launchpad.net/bugs/76301
<seb128> Keybuk: dunno, I don't use it. Maybe seahorse breaking that too?
<seb128> slomo: do you know about gnome-gpg being broken?
<Keybuk> it's spinning in an infinite loop once it's signed the message
<Keybuk> I don't have seahorse installed, what is it?
<ogra> a gui for maintaining your keys
<Keybuk> how is that different from gnome-keyring-manager ?
<ogra> no idea, i use neither :)
<seb128> Keybuk: gnome-keyring-manager is for the GNOME keyring
<tkamppeter> I also did not hear anything about my Edgy SRU request in bug 65618.
<Ubugtu> Malone bug 65618 in foo2zjs "Firmware upload to LJ 1000/1005/1008/1020 broken (fix to be proposed as Edgy update)" [Medium,Fix committed]  http://launchpad.net/bugs/65618
<tkamppeter> Does not receiving an answer mean that it is rejected?
<seb128> Keybuk: seahorse is for managing your gpg key directly$
<seb128> ok, if it's not installed that's not it
<seb128> dunno about the gnome-gpg breakage
<cjwatson> tkamppeter: no, if it was rejected you'd have been told that
<cjwatson> seb128: ok
<Keybuk> isn't the GNOME keyring for storing things like your GPG passphrase?
<cjwatson> tkamppeter: it means we're behind :-(
<seb128> Keybuk: it is, apps have to use it though
<seb128> Keybuk: seahorse allow you to gpg crypt or uncrypt a file from nautilus context menu by example
<seb128> Keybuk: or to manage signatures on your gpg key
<seb128> or things like that
<cjwatson> seb128: approved
* seb128 hugs cjwatson
<seb128> cjwatson: thank you
<StevenK> Hrm. Since we don't support jumping releases, I can kill the rc{0,6} removal stuff in cyrus-sasl2.
<tkamppeter> cjwatson: OK
<Keybuk> StevenK: we'll still need that for dapper->NEXT-LTS
<tkamppeter> mvo: biff
<StevenK> Ah, point.
<mvo> tkamppeter: biff?
<Keybuk> "You've Got Mail"
<mvo> hihi
<cjwatson> tkamppeter: you also need a bit in foo2zjs's postinst to remove the old udev rules file on upgrade; the usual rune is something like 'if [ "$1" = configure ]  && dpkg --compare-versions "$2" lt VERSION-IN-WHICH-THE-CHANGE-WAS-INTRODUCED; then rm -f /etc/udev/rules.d/11-hplj10xx.rules; fi'
<cjwatson> tkamppeter: please adjust debian/changelog to direct the upload at edgy-proposed, not edgy
<cjwatson> tkamppeter: the rest looks OK
<slomo> seb128: no, i use seahorse ;) what is broken with it?
<tkamppeter> mvo, this means that you got e-mail.
<seb128> slomo: not seahorse, Keybuk was asking about gnome-gpg and I figured that might due to seahorse
<ogra> ARGH
<ogra> who purt ltsp-utils into the server-ship seed ?
<ogra> *put
<ogra> that package was removed months ago ... 
<mvo> tkamppeter: thanks, looking at the diff now
<ogra> cjwatson, iirc you removed it, didnt you blacklistz it as well ?
<ogra> *blacklist
<cjwatson> ogra: you never *removed* it from the seeds. It's been seeded since 2005 at least.
<ogra> no, but you removed it from the archive on my request in the beginning of feisty iirc
<ogra> so it didnt show up anywhere
<tkamppeter> cjwatson, thank you for the info, will do the changes.
<ogra> apparently the debian package was synced now ... which is wrong ...
<ogra> and now its on anastacia ...
<cjwatson> ogra: blacklisting wouldn't have made any difference, because blacklisting only affects source package names, and there is no ltsp-utils source in feisty, only a binary
<seb128> I'm away for lunch and some shopping, bbl
<ogra> ugh ... how can thqat be ?
<ogra> *that
<cjwatson> actually, I have no idea what's going on here; the archive looks inconsistent
<ogra> i'll clean the seeds now ...
<mvo> tkamppeter: gutenprint uploaded
<cjwatson> ogra: no, I did not perform the removals
<cjwatson> removal
<ogra> dunno how it ended up in server-ship at all, i never touched that seed until my inetd ...
<ogra> *my inetd change
<cjwatson> actually, I did once, then it must have got back in, and Keybuk removed the source again
<cjwatson> but did not remove the binary
<ogra> ah
<cjwatson> I'll fix it now
<ogra> thanks :)
<cjwatson> ogra: ltsp-utils was in the very first version of the server seed, which later got renamed
<Keybuk> python-xml needs a fake sync (someone)
<ogra> ah, ok
<cjwatson> ogra: I do think your "ARGH" was a bit excessive
<ogra> i always had my own server seed, thats why i missed it in the ubuntu server seed
<cjwatson> server was renamed to server-ship precisely to avoid clashing with the Edubuntu server seed
<ogra> well, if its in main and gets installed alongside with ltsp-server it will break ltsp completely 
<ogra> so i dont think my ARGH was excessive ...
<cjwatson> and obviously we promote stuff from universe without thinking </sarcasm>
<cjwatson> you simply need to tell us, not panic
<ogra> meh, thats not what i wanted to say 
<tkamppeter> mvo(gutenprint): Thanks.
<ogra> i was just shocked that it showed up again, ltsp-utils seems to be my nemesis since three releases ... 
<elmo> ogra: you really do need to calm down a bit
<cjwatson> the problem with you panicking is that it makes archive guys go "oh shit, why is the archive broken this time". It isn't good for anyone's blood pressure
<ogra> i'll try to keep that in mind
<cjwatson> usually it's just a one-line fix somewhere :)
<mvo> Keybuk: I filed a bug about python-xml already
<Keybuk> mvo: bug report?
<Mithrandir> if it was two minutes before release, going "aiee" would be fine, but now it's more like a yawn.
<mvo> Keybuk: sync request bug
<StevenK> + saslpasswd2 -c no:such:user
<Keybuk> mvo: sync request rejected :)
<StevenK> Segmentation fault (core dumped)
<StevenK> Yummy!
<Keybuk> mvo: let me know which bug it is, and I'll update the status
<Keybuk> mvo: it needs a fake sync (our orig.tar.gz is different to Debian's)...  download our orig.tar.gz from the archive, the Debian diff.gz, mash them together with a changelog of "Fake sync" for ubuntu1
<mvo> Keybuk: https://bugs.launchpad.net/distros/ubuntu/+source/python-xml/+bug/76580
<Ubugtu> Malone bug 76580 in python-xml "Please sync from debian/unstable (overwrite ok)" [Undecided,Unconfirmed]  
<mvo> Keybuk: ok, I can do this. do you happen to know why our orig.tar.gz are diffreent?
<Keybuk> mvo: no idea
<Keybuk> ask whoever uploaded it :p
<elmo> s/ask/beat/
<Hobbsee> imbrandon: do you mind if i do kwin-style-crystal?
<Hobbsee> hey mdz 
<StevenK> Oh I love libdb. If saslpasswd2 can't open the Berkeley DB, it segfaults.
<thom> kwalitee
<cjwatson> I think mdz's connection is just bouncy, rather than him really being here at 5am
<Hobbsee> heh
<imbrandon> Hobbsee, go for it
<Hobbsee> imbrandon: kwwii's patches are all merged upstream, presumably?
<Hobbsee> imbrandon: looking at this - he is the upstream?
<imbrandon> no idea, i doubt it though as they are artwork
<imbrandon> well kinda
<imbrandon> he is one of 3
<Hobbsee> hmmm okay
<imbrandon> i would make sure they are though, just to be save
<Hobbsee> imbrandon: might query that with ihim.  if they are, it's a straight sync
<imbrandon> safe*
<Hobbsee> yeah, he's pinged
<mvo> Keybuk: ok, I will upload python-xml then
<Simira> mvo: do you want to know that update-manager is not working i Edgy?
<mvo> Simira: in edgy? urgh! what is happening?
* gnomefreak just tested it the other day and seemed to have worked
<Simira> mvo: nothing at all... that is, when I start update-manager, X freezes totally. I manage to switch to console to kill it.
<mvo> Simira: do you use the nvidia driver (the non-free one)?
* mvo vaguely remembers something about this
<Simira> mvo: I have one of the tricky graphic cards, but no non-free drives as I can recall
<Simira> mvo: seems somewhat like an out-of-memory-bug, and I've had a few problems with that lately...
<mvo> Simira: how much memory do you have in the machine?
<cjwatson> rodarvus: xterm can be synced; I'll do that once Keybuk has finished with his syncs
<Simira> 768, I think
<mvo> Simira: hm, that *should* be enough :)
<mvo> Simira: could you please run top or the gnome-top-thing when opening update-manager?
<Simira> mvo: hmm... it might be Opera is to blame. I have had memory-problems due to Opera lately, and u-m seems to work now when I closed Opera
<Simira> mvo: um was pretty high on the top-list
<mvo> tkamppeter: all uploaded, thanks
<mvo> Simira: ok, I will watch out for this kind of problem
<Simira> mvo: but I do get a "could not initiate dbus"-warnin when I start from a terminal
<Laibsch> Keybuk: May I kindly request you upgrade https://bugs.launchpad.net/distros/ubuntu/+source/sysvinit/+bug/48517 from Wishlist to High Importance?
<Keybuk> cjwatson: unlock
<Ubugtu> Malone bug 48517 in sysvinit "Improper filesystem unmount order (swap on files)" [Unknown,Fix released]  
<cjwatson> Keybuk: ta
<Keybuk> Laibsch: no; as mentioned in that bug, we've never supported swap on files
<Laibsch> Keybuk: As mentioned in the replies, please read https://wiki.ubuntu.com/Bugs/Importance
<Laibsch> This cannot be anything but High.
<Laibsch> The fix you choose is up to you.  But I cannot see there is any doubt about the importance of this one.
* Hobbsee notes that the importance doesnt really matter - it's whether it gets fixed or not
<Keybuk> Laibsch: of course it can
<Keybuk> it's wishlist
<Keybuk> we have never supported this configuration
<Laibsch> Keybuk: Also, what about the patch that is supplied?  No good?
<Keybuk> we provide no tools to put your system into this configuration
<Keybuk> this configuration has never worked (unless by accident)
<Keybuk> it certainly does not work in dapper
<Keybuk> therefore this is not a regression either
<Laibsch> Keybuk: nano is not supported?
<Keybuk> Laibsch: you can nano /dev/hda1 and write garbage -- that doesn't mean we should support you when you can't mount your filesystem
<cjwatson> Laibsch: for future reference, patches should be submitted as unified diffs (diff -u)
<Keybuk> from the page you quote ...
<Keybuk> Wishlist: a request to add a new feature to one of the programs in Ubuntu
<cjwatson> the normal diff format is practically useless
<Keybuk> "new feature" => supporting swap files (instead of partitions)
<Laibsch> cjwatson: I would change the patch if I knew how.  I had trouble applying it myself.
<Keybuk> please don't get too religious about the importance of a bug
<Keybuk> the importance is a guide for the developer, rather than the user
<Keybuk> it doesn't actually mean your bug is getting any less consideration
<Keybuk> in fact, for feisty I'm attempting to fix more wishlist bugs than critical ones (yes, that sounds weird)
<Laibsch> Well, this one is easy to fix.  A user has said he would work in it to fix it.  Still it has been sitting around for ages.  (and it is important IMNSHO ;-))
<Laibsch> on it
<Keybuk> Laibsch: how easy a bug is to fix, or how long it has been open, have no bearing on things
<mjg59> Laibsch: This bug isn't the only thing blocking swapfile support
<mjg59> Using swapfiles currently breaks hibernate
<cjwatson> Laibsch: given that most of our initscripts are going to be thrown away and totally redone from scratch in an entirely different way in feisty ...
<Laibsch> Keybuk: Why not accept the input from the user who said he would help out?
<Keybuk> you'll note that release goals for the last three ubuntu releases have included major changes to the startup and shutdown sequences, as well as the method of mounting filesystems
<Keybuk> this is, as a whole, something that is being worked on (tm)
<Keybuk> Laibsch: because as Colin points out, we've pretty much throwing away all the init scripts for feisty -- spending time now to try and fix that in the current initscripts system would reduce the amount of time to write the new stuff
<tkamppeter> cjwatson: I have done the changes on the foo2zjs update package for EDGY now. See my new comment in bug 65618.
<Ubugtu> Malone bug 65618 in foo2zjs "Firmware upload to LJ 1000/1005/1008/1020 broken (fix to be proposed as Edgy update)" [Medium,Fix committed]  http://launchpad.net/bugs/65618
<tkamppeter> mvo, thanks for doing all the uploads.
<tkamppeter> mvo, doing Feisty version of foo2zjs now.
<cjwatson> tkamppeter: thanks. I don't see updated versions of the files on freestandards.org, though?
<cjwatson> doko_: can you point me at what you've got for syslinux and I'll see what I can do?
* cjwatson is running out of time before Christmas, but ...
<cjwatson> taking (and syncing) graphviz
<cjwatson> tkamppeter: hmm, I think you just forgot to update the .debdiff
<tkamppeter> cjwatson, sorry, typo, now I have uploaded the debdiff, too. If you look into the directory all files must be from today. Tell me if one is still older
<cjwatson> mvo: for libnotify, what about the DEB_DH_MAKESHLIBS_ARGS_libnotify0 change? that affects upgrades from dapper
<cjwatson> tkamppeter: you need to add this to the end of your .postinst:
<cjwatson> #DEBHELPER#
<cjwatson> exit 0
<mvo> cjwatson: I checked the pervious version of libnotify and they have identical symbols. or do I miss something here?
<cjwatson> tkamppeter: otherwise debhelper postinst fragments won't be included
<cjwatson> mvo: I didn't check the library itself - it's just a change that I noticed wasn't carried over
<tkamppeter> cjwatson: will do and re-upload
<cjwatson> tkamppeter: sorry, I hadn't checked to see that there wasn't a postinst already or I'd have mentioned that earlier
<mvo> cjwatson: ok, I will double-check
<cjwatson> tkamppeter: make sure that your sponsor uploads with the -v20060625dfsg-2 option to dpkg-buildpackage (or debuild) to ensure that all the applicable changelog entries end up in the .changes file
<cjwatson> (which in turn affects what gets mailed out to edgy-changes@lists)
<Mithrandir> s/edgy-changes/feisty-changes/
<cjwatson> Mithrandir: nack, tkamppeter's talking about an SRU
<Mithrandir> oh, ok.
<Adri2000> cjwatson: would it be possible that you look at the libdjconsole package in NEW before the christmas break please? I know I shouldn't ask that... but I need this package to update another one
<Mithrandir> I should go back to vacationing, then. :-)
<cjwatson> Keybuk: stealing your squashfs merge and syncing it
<Hobbsee> Adri2000: the packages depending on it will just sit in depwait on the buildds if it hasnt gone through
* Hobbsee waves to Mithrandir 
<Mithrandir> Hobbsee: hiya! :-)
<cjwatson> Adri2000: accepted, source anyway
<mvo> Keybuk: ok if I take your swig1.3 merge?
<Keybuk> sure
<Keybuk> I'm on holiday, so I'm not merging <g>
<Keybuk> cjwatson: what was remaining in squashfs previously?
<Hobbsee> Keybuk: rubbish.  you're not on holidays if you're not here :P
<Hobbsee> er, if you are here
<tkamppeter> cjwatson: All files for the SRU re-uploaded, with corrected postinst script.
<Adri2000> cjwatson: whow quick, thanks!
<cjwatson> Keybuk: bashisms
<Keybuk> cjwatson: ah, Debian took that? cool
<cjwatson> yeah
<cjwatson> well, did independently
<cjwatson> Keybuk: stealing cron and rsync from you
<Keybuk> ok
<Keybuk> Hobbsee: heh
<Keybuk> cjwatson: can I have the sync lock back? :)
<cjwatson> Keybuk: yes
<cjwatson> I was just chucking four more overwrites into the queue
<cjwatson> tkamppeter: approved; go ahead and find a sponsor
<cjwatson> mvo: er, oops, I sort of forgetfully synced libnotify anyway :) if it's still relevant you can always reupload
<tkamppeter> mvo, can you upload the SRU update of foo2zjs into the Edgy updates (see bug 65618).
<Ubugtu> Malone bug 65618 in foo2zjs "Firmware upload to LJ 1000/1005/1008/1020 broken (fix to be proposed as Edgy update)" [Medium,In progress]  http://launchpad.net/bugs/65618
<cjwatson> mvo: (make sure to use -v20060625dfsg-2 when doing so)
<doko_> cjwatson: http://people.ubuntu.com/~doko/syslinux/
<tepsipakki> hmm, I think dcraw can be synced
<cjwatson> doko_: thanks, will try to get time to look
<Keybuk> cjwatson: unlocked
<mvo> cjwatson, tkamppeter: looking at it now
<tkamppeter> mvo: Can you also upload foo2zjs for feisty, I have added the foo2zjs.postinst there, too.
<tkamppeter> mvo: URL is http://www.freestandards.org/~till/tmp/ubuntu/feisty/foo2zjs/
<mvo> tkamppeter: done
<tkamppeter> mvo: Thank you very mich.
<tepsipakki> ok, I'm positive dcraw can be synced. The debdiff between 8.38-0ubuntu1 and 8.39-1 contains only stuff that is either dropped or new in debian (or upstream)
<tepsipakki> +positive that
<tkamppeter> mvo (or someone else with appropriate rights): Can you make splix getting onto the desktop and server CDs (add to seeds or meta packages). Thanks.
<dholbach> tkamppeter: splix does not seem to be an ubuntu package
<dholbach> (yet)
* Keybuk gets freakishly annoyed that gdb is incapable of looking at errno
<Keybuk> who'd've thought it might be useful to be able to do that
<dholbach> tkamppeter: and the process for Main inclusion is described here: https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<mvo> dholbach: I just uploaded it, but a main inclusion report is still required
<tkamppeter> dholbach: mvo, did you upload splix into Ubuntu? Did you put it into main?
<dholbach> righto
<mvo> tkamppeter: I uploaded it, but it needs to be promoted. to get a promotion, it needs a MainInclusionReport
* mvo takes bogofilter
<cjwatson> BenC: Debian split out an efi-modules udeb (Debian bug #381584) to make it more sensible to ship efivars in a udeb on i386 - might be worth doing the same in Ubuntu
<Ubugtu> Debian bug 381584 in elilo-installer "module efivars for i386 to support elilo on MacBook Pro" [Unknown,Closed]  http://bugs.debian.org/381584
<BenC> cjwatson: ok
<BenC> cjwatson: BTW, directfb failed to build on i386/amd64, even though it clearly builds perfect in my chroots :/
<cjwatson> I'll back out the corresponding elilo-installer change for now
<BenC> I've no idea why
<cjwatson> hmm, nasty little FTBFS that
<cjwatson> BenC: I'm no wiser than you - have you tried on ronne?
<BenC> not yet, I will later today
<\sh> benc: do you know when hugeTBL FS was add to the kernel?
<\sh> (vanilla I mean ;))
<tkamppeter> mvo, I have made the report now: https://wiki.ubuntu.com/MainInclusionReportSplix
<tkamppeter> only thing missing is that the Splix files did not arrive in the archives yet (should appear in http://archive.ubuntu.com/ubuntu/pool/universe/s/splix/)
<cjwatson> tkamppeter: i.e. waiting for NEW processing
<tepsipakki> oh, there already was a sync-request of dcraw
<tepsipakki> duh
<cjwatson> tepsipakki: yours is better-formed, so I'll dup
<tepsipakki> took a while to get requestsync to work :)
<tepsipakki> but easy
* cjwatson steals grub from Keybuk
<BenC> directfb is now officially just broken on the buildd's
<BenC> builds fine in ronne's chroot's
<elmo> BenC: link to the build logs?
<BenC> elmo: Failed on i386 and amd64
<BenC> http://librarian.launchpad.net/5473039/buildlog_ubuntu-feisty-i386.directfb_0.9.25.1-5ubuntu1_FAILEDTOBUILD.txt.gz
<BenC> similar issues
<BenC> I checked the build log, and libc-linux-dev is the same version I have in my chroot
<BenC> same with libc6-dev
* cjwatson steals nvidia-settings from mdz
<bddebian> Heya
<elmo> BenC: I just dist-upgraded ronne and it now FTBFS there too, FWIW
<elmo> BenC: amd64, that is
<elmo> (dist-upgrading i386 too)
<BenC> odd that my chroot, which I dist-upgraded just before upload, didn't show it
<BenC> elmo: Any idea what version libc-linux-dev was before the dist-upgrade?
<elmo> BenC: no, but /var/log/dpkg.log in the chroot should tell you
<BenC> just updated my chroot and it still builds...guess I'll work on it in ronne's
<BenC> I must have magical chroots
<cjwatson> fabbione: http://librarian.launchpad.net/5490435/buildlog_ubuntu-feisty-sparc.graphviz_2.8-2.6_FAILEDTOBUILD.txt.gz looks sparc-specific and probably not graphviz's fault?
<bddebian> cjwatson: What did I miss in kbd-chooser that needs to stay?
<BenC> cjwatson: Any chance of getting a dmesg on that box to make sure it wasn't a kernel caused sigbus?
<elmo> BenC: err, actually sorry, I lied. it does FTFBSbut it's different error on ronne/amd64 than the i386 log you posted
<cjwatson> bddebian: an enormous shedload of stuff
<BenC> elmo: Can you change the defauly chroot to feisty? :)
<cjwatson> look at the diff
<cjwatson> BenC: I can't
<elmo> BenC: yeah, done
<BenC> thanks, I almost pulled the crack card on you because it just built, but I was on edgy
<BenC> elmo: The amd64 one has problems with multiple declerations of types, and i386 has missing types
<elmo> ah, ok, sounds like the same error in the chroots then, you should be good
<elmo> (to be able to investigate it anyway ;-)
<cjwatson> rodarvus: how about the mesa merge? that seems substantial - if somebody else needs to take it, they'd need to start about now
<ogra> elmo, could you use your CC super powers and disable jsgotangco's admin rights from edubuntu-members ? he left the council ...
<BenC> elmo: Ok, now I'm pulling the crack card
<cjwatson> crimsun_: do you know the status of the remaining XFCE merges?
<BenC> it just built in the feisty chroot
<BenC> elmo: Are you using dpkg-buildpackage, or "fakeroot debian/rules binary"?
<elmo> BenC: dpkg-buildpackage -us -uc -r -B
<elmo> BenC: ~james/scratch/32/build.log
<BenC> elmo: I was doing a direct debian/rules, I'll try dpkg-buildpackage
<elmo> ogra: done
<ogra> elmo, thanks, i'll ping you in january after we elected someone new ... :)
<cjwatson> dholbach: (as seb128 substitute) looks like libcairo can be synced once (or maybe before) BenC gets directfb fixed?
<dholbach> cjwatson: seb128 said that he's working on it and has something prepared. I *think* he said, that once directfb is done we can sync it - let me check
<BenC> WTF!
<BenC> why is dpkg-buildpackage failing to build directfb, and "fakeroot debian/rules binary" working!?
<BenC> I can reproduce it on my machine now
<cjwatson> BenC: try 'debian/rules build && fakeroot debian/rules binary'
<BenC> cjwatson: Did that too
<cjwatson> mvo: will you merge synaptic by tomorrow?
<siretart> grrr. is anyone already working on the directfb FTBFS on i386?
<BenC> siretart: yes
<siretart> oh. reading backlog actually helps
<mvo> cjwatson: sure
<bddebian> I need diacanvas2 fixed too and it seems to be over my head :-(
<siretart> sorry BenC 
<bddebian> Oh crap, wrong channel, sorry
<dholbach> cjwatson: 
<dholbach> Dez 19 17:09:31 seb128  libglade2 and gconf2 should be sync
<dholbach> Dez 19 17:09:38 seb128  libcairo too when directfb is updated
<siretart> BenC: the buildlogs looks really strange
<dholbach> that was in #ubuntu-desktop
<cjwatson> pitti: stealing base-files from you
<pitti> cjwatson: with pleasure
<cjwatson> dholbach: thanks
<BenC> cjwatson: "debian/rules build; fakeroot debian/rules binary" works
<BenC> I want to blame quilt
<cjwatson> BenC: try debian/rules build; fakeroot debian/rules binary-arch
<cjwatson> I think that's slightly closer to what the buildd does
<BenC> cjwatson: Pre-emptive, just tried it, and it works aswell
<cjwatson> sh -x /usr/bin/dpkg-buildpackage ? ;-)
<elmo> buildd does what I said
<elmo> i.e. dpkg-buildpackage -B
<elmo> at least on amd64
<elmo> on i386 is does -b
<fabbione> cjwatson: looking at the FTBFS
<elmo> (even in soyuz - it's still using sbuild, underneath all the xml-rpc lp goo)
<elmo> and -b is clean, build, binary, -B is clean, build, binary-arch, IIRC
<cjwatson> elmo: sorry, I missed your dpkg-buildpackage line
<BenC> nothing special about sh -x dpkg-buildpackage
<BenC> -         --with-gfxdrivers=all --enable-video4linux2 \
<BenC> +         --with-gfxdrivers=none --with-inputdrivers=ps2mouse \
<BenC> the build changes with dpkg-buildpackage though
<BenC> stupid rules file
<BenC> It doesn't use dpkg-architecture directly, it assumes the env vars will be set
<cjwatson> aha
<fabbione> cjwatson: looks like groff is broken... 64 bit allignement fuck up
<cjwatson> fabbione: really? pass me a diff and I'll get it fixed
<cjwatson> first I've heard of it
<fabbione> cjwatson: can you reproduce it on faure?
<fabbione> the BUS ERROR is either some 64bit allignment or the ssp going banana
<fabbione> i will need to check,,,'
<fabbione> cjwatson: i am still in Seattle and just woke up...
<cjwatson> ssh: faure.debian.org: Name or service not known
<cjwatson> not so much
<cjwatson> it's not clear it's groff from that build log; it could also be ps2pdf
<cjwatson> not sure exactly how the shell displays that
<cjwatson> fabbione: anyway, it's a porter team problem as far as I'm concerned for the time being :-)
<BenC> Ok, I have a fixed directfb to upload
<fabbione> cjwatson: eh dude.. faure.ubuntu.com ?
<BenC> had to disable the i830 gfx driver, it cannot be built with current linux headers
<fabbione> cjwatson: yeah i will look at it.. just give me sometime please..
<cjwatson> fabbione: hmm, faure used to be an alpha port box in Debian so was in my .ssh/config as such
<fabbione> cjwatson: eheh
<cjwatson> yay name clashes
<fabbione> i blame our sysadmins :P
<cjwatson> fabbione: faure's feisty chroot doesn't have all the build-deps right now, but I tried just the one command that SIGBUSses on the buildd, and it works fine
<fabbione> cjwatson: i am powering on stuff here now..
<fabbione> bah
<fabbione> the us mirror is behind again
<fabbione> cjwatson: i am building now...
<glatzor> mvo: here I am
<mvo> haha
<glatzor> g-a-i only shows supported applications by default
<glatzor> oh
* mvo hugs glatzor
* glatzor starts whining since the older guys play tricks on him (especially mvo)
<keescook> hiya seb128
<seb128> hey keescook!
<fabbione> cjwatson: it did build fine here. Can you please give it back? if it still fails i will need to get som extra info from adam. We might be tripping on some specific CPU kernel code somehow
<Chipzz> jdub: ping?
<cjwatson> fabbione: I'm still not a member of launchpad-buildd-admins, so no, I can't :P
<fabbione> cjwatson: oh ok...
<fabbione> who is awake that can?
<cjwatson> Mithrandir: can you give-back graphviz/sparc, please?
<fabbione> cjwatson: there are some diffs in the build environment that i can't reproduce locally, like glibc optimized packages and CPU.. i am not sure i have one here.. will have to check with davem when he is awake
* cjwatson steals and syncs xarchiver
<bddebian> Theif
* fabbione -> breakfastr
<cjwatson> oh, damn, can't, different .orig
* jdong adds ffmpeg commands for 640x480 H264 to iPodVideoEncoding
<jdong> muahaha
<bddebian> Holy crap cjwatson, sorry about that.  I don't know how I missed all that.. :-(
<cjwatson> like I say, I'm entirely happy to merge it, just not right now :)
<cjwatson> it's not all that urgent since we don't use it in the installer any more - I want to keep the diffs for now though in case there are folks building custom installers with kbd-chooser or something
<cjwatson> and just on general principles that we shouldn't throw away unmerged diffs without a good reason
<cjwatson> similarly console-data
<bddebian> cjwatson: Well a couple were picked up in the debian package I just don't know how I missed some of the old ones :-(
<cjwatson> no, essentially nothing was picked up in the Debian package
<cjwatson> the only thing that was picked up was in fact something I backported from Debian to Ubuntu
<cjwatson> (and was a change I made myself in Debian, anyway)
<robepisc> cjwatson: just sent here by sfllaw from ubuntu-bugs.  When you have time, can you (or tollef) look at bug 62868, please?  It started as a swap automounting problem, but turned out to be an insidious PATH problem in casper.
<Ubugtu> Malone bug 62868 in casper "swap partitions not automounted by the LiveCD" [Undecided,Confirmed]  http://launchpad.net/bugs/62868
* bddebian leaves in shame
<cjwatson> robepisc: ugh. I'd much rather leave that to Tollef
<cjwatson> robepisc: I just hack on casper when I need to in order to make ubiquity work properly - I try not to get sucked into more general maintenance :)
<robepisc> cjwatson: ok, thanks.  I'll ping him then.
<cjwatson> robepisc: I tend to agree that using binaries from /root directly is bad; I forget why that was added
<cjwatson> robepisc: I suspect there's something pretty non-trivial hiding in there
<cjwatson> for instance if it needs the mount binary from /root then chrooting probably won't cut it
<robepisc> cjwatson: thanks for looking at it. The mount binary from the initrd seems to work just fine.  And I checked and tested all the scripts, looking for something requiring /root/ in PATH, but couldn't find anything.  Maybe Tollef knows why /root/ was put there in the first place.  Thanks again!
<Chipzz> heh
<Chipzz> launchpad--
<Chipzz> why can't I just file a bug instead of having to go through a whole series of forms?
<Chipzz> bleh
<Adri2000> Chipzz: you can
<Chipzz> hrrrm apparently just one form
<Chipzz> kinda silly for a bug that I *know* hasn't been reported yet
<Adri2000> Chipzz: "You may prefer the complicated bug filing form."
<cjwatson> robepisc: bzr annotate might help, I guess
<cjwatson> it may predate Tollef's maintenance
<Adri2000> Chipzz: https://launchpad.net/distros/ubuntu/+filebug-advanced
<Chipzz> anyway, bug filed
<cjwatson> Chipzz: this really isn't the place for complaints about Launchpad
<Chipzz> that's why I was about to shut my mouth ;P
<Chipzz> can I downgrade the importance of a bug I reported myself?
<Adri2000> Chipzz: only if you are in the QA team
<Chipzz> nm then
<Chipzz> I know the bug is just cosmetic/wishlist, and I thought maybe downgrading the importance would help, but whatever ;)
<Adri2000> Chipzz: I can do it if you want, but let's move to #ubuntu-bugs
<Chipzz> Adri2000: cfr pvt ;)
<Adri2000> yep
<seb128> ogra: gnome-screensaver is broken on feisty
<seb128> ogra: doesn't accept the user password
<fabbione> cjwatson: how much would you hate me if i upload a nochange d-i to pick up a new kernel if Ben uploads for me?
<cjwatson> fabbione: that's fine
<fabbione> cjwatson: thanks
<jonh_wendell> will gtkUnique get in feisty (if not in gtk upstream) ?
<jhasse> I have no drives on my desktop with feisty. Is that normal?
<Chipzz> jonh_wendell: I'm not a developer, but I figure the chances of that would be pretty high, yes
<ademan> i know this is a gnome thing and not an ubuntu thing, but i think it would be nice if in nautilus if you tried to drag a file to a folder with different permissions (for example /usr/include) that it would prompt you to sudo first and then allow it, rather than forcing you to start nautilus as root.  Of course there are security implications, and it might foster more users borking their own system, but it would be convenien
<ademan> t.  (and maybe it would only do that for sudoer accounts, and wouldn't do the same prompt when you're attempting to modify a different user's files)
<seb128> ademan: there is a feature request open since probably warty for that, patches are welcome ;)
<fabbione> cjwatson: do you happen to remember where or how you did use printf to go back from letter to num? my connection to home where i have d-i checkout is useless atm
<ademan> well lemme think about it for a bit, would a prompt be good?  "Modifying system files is potentially dangerous, only do this if you know what you're doing"  with a checkbox that says "never show this again" and an ok/cancel  which then would lead to a gksudo prompt?
<ademan> gconf could probably just store a boolean key that represents that checkbox, whether or not to display the message next time
<ademan> but would it be best like that? or all in one? ie the warning and the gksudo are part of the same dialog?
<cjwatson> fabbione: partman-base/definitions.sh (mentioned elsewhere too, but for the record)
<BenC> fixed directfb uploaded
<fabbione> cjwatson: ok thanks
<BenC> what's the URL for the merges again?
<kylem> merges.ubuntu.com?
<bddebian> yep
<BenC> thanks
<cjwatson> http://merges.ubuntu.com/main-trend.png has an interesting little jump over the last couple of days ...
<cjwatson> (between the top two segments)
<LaserJock> cjwatson: universe seems to have it too, although it's a bit hard to see as our percentage of ubuntuX is lower
<bronson> I started taking notes on building debs and maintaining package repositories.
<bronson> http://wiki.u32.net/Dpkg
<bronson> Is there any interest in moving this to the Ubuntu wiki?
<LaserJock> bronson: yeah, I think so
<cjwatson> it should have a less generic name though
<LaserJock> yes
<LaserJock> bronson: can we take this to #ubuntu-doc
<Mithrandir> cjwatson: given-back
<cjwatson> thanks
<ogra> seb128_, gnome-screensaver works for me ...
<lifeless> ogra: does not for me
<lifeless> ogra: just times out
<lifeless> I was going to ask about it when I read the backlog :)
<ogra> hmm, thats weird ...
<ogra> its fine on two laptops and one thin client here with the same version
<lifeless> I had to kill it to login
<lifeless> s/login/unlock
<ogra> do you see any feedback to your input ?
<ogra> (dots for keystrokes)
<bronson> LaserJock: be there in a sec...  Breakfast to contend with.
<lifeless> ogra: yes, it accepts the password fine, you hit enter, it stops responding,
<lifeless> mouse is in 'busy' mode
<ogra> hmm
<lifeless> after 5 minutes, it goes back to locked
<cjwatson> hah
<cjwatson> <cjwatson@cairhien ~/src/ubuntu/ubiquity/new-partitioner/ubiquity>$ bzr commit -m 'implement committing results of new partitioner'
<cjwatson> nearly there ...
<cjwatson> aside from the hideous performance suckiness
<lifeless> lvm support ?
<cjwatson> that comes well after basic functionality ;)
<lifeless> heh
<cjwatson> eventually, but not yet
<lifeless> cool
<cjwatson> haven't done the fancier bits of the UI yet which I suspect will also have to come earlier
<lifeless> cjwatson: can it be used outside the installer ?
<cjwatson> lifeless: no
<cjwatson> at least not without some very substantial rewiring
<jdong> whoa, lvm for ubiquity?
<cjwatson> no
<cjwatson> don't get excited :)
<jdong> aww
<cjwatson> some time in the semi-distant future ...
<jdong> lol
* jdong notes there's been hacks floating around for system-config-lvm running on dapper/edgy
<jdong> and apparently it "works"
<jdong> with large quotation marks around works
<cjwatson> not very useful for ubiquity though
<jdong> right
<jdong> but it gives Joe User a lvm gui
<cjwatson> oh, true, I guess
<cjwatson> is it actually any good now? we looked at it early in the breezy cycle (IIRC) and it wasn't really
<jdong> cjwatson: it looks pretty decent to me
<jdong> cjwatson: it does most lvm tasks competently and represents visually in a way regular users would understand
<jdong> it has improved tons since its original introduction
<cjwatson> the lack of a decent UI to manipulate LVM was one of the reasons we chose not to do LVM by default in breezy
<jdong> agreed
<jdong> I kinda wish gparted handled the lvm stuff though
<cjwatson> so once ubiquity can do LVM (er ... maybe feisty+1) we could revisit that
<cjwatson> I'm ditching gparted :)
<jdong> yay!
<cjwatson> assuming I can make this pile of complex weirdness work ...
<jdong> does that mean there'll be a way to launch just the partitioning mechanism without the installer?
<cjwatson> no
<cjwatson> 20:34 < cjwatson> at least not without some very substantial rewiring
<cjwatson> might keep gparted around for that use case
<jdong> :(
<jdong> it'd be better if it were 'very substantially rewired' :(
<cjwatson> I dunno, I suppose you could theoretically have a very custom ubiquity frontend that did that
<jdong> well, a partitioning/LVM gui would be very valuable to users
<cjwatson> it's only really interesting on the live CD anyway because otherwise you tend not to be able to fiddle with the partition table
<lifeless> well, tchau, aikido time
<cjwatson> jdong: I'll try to take account of that possibility in the implementation, but it won't be in the first cut
<jdong> that's cool to hear
<cjwatson> but nor will LVM, so :)
<jdong> thanks for listening :)
<cjwatson> it should be a lot more practical than in gparted though
<cjwatson> LVM is in the design
<Keybuk> and on my hit list tonight, seb128 and BenC!
<Keybuk> COME ON DOWN!
<ogra> ?
<Keybuk> buggy wuggies
<ogra> seems i introduced one as well in the screensaver ... and as usual i cant reproduce it :(
<Keybuk> heh, oh yes, I knew I wanted to kill you too :)
<Keybuk> the screensaver won't unlock, yes?
<ogra> yep
<ogra> and i have no idea why it works here ...
<ogra> but it does, on all machines
<Keybuk> yeah, I've seen that one
<Laibsch> hi, should bugs fixed in edgy but present in still-supported dapper be marked closed?  They are easy to fix in dapper (just add dependency and recompile)
<cjwatson> we don't in general fix bugs in dapper unless they're eligible for stable release updates (http://wiki.ubuntu.com/StableReleaseUpdates)
<cjwatson> if they are eligible for an SRU, then the proper procedure is NOT to reopen the bug, but to open a new dapper task on the bug using "target fix to releases" or whatever the link is in launchpad
<cjwatson> but contact the responsible developer before doing that unilaterally, please; they're the ones who'll have to take on the not inconsiderable work of getting it pushed through
<Laibsch> Talking about bug 53244 which is easy to fix but not even remotely security relevant or anything.
<Ubugtu> Malone bug 53244 in uim "Wrong link or dependency" [Low,Confirmed]  http://launchpad.net/bugs/53244
<cjwatson> stability (i.e. don't change) is more important than most other considerations in stable releases
<sistpoty> can a motu do a main sru as well?
<cjwatson> sistpoty: not without a sponsor
<sistpoty> cjwatson: permanent sponsor for whole sru? or just the individual uploads
<cjwatson> Laibsch: that's unfortunate, but unless it's a regression from the previous release, it's probably not a candidate for an update; either way the main bug task should be closed if it's fixed in edgy
<cjwatson> sistpoty: not important
<sistpoty> ah, k... thx
<Laibsch> cjwatson: well, the fix is quite easy for the user and documented now.
<Laibsch> Will check if it has been a regression from breezy
<Laibsch> no, no regression.
<n00bzer> could someone please help me set up an smb share on a ubuntu box?
<n00bzer> I have been at it for hours, and no luck
<Laibsch> n00bzer: Wrong channel, I guess.
<Laibsch> n00bzer: Try #ubuntu
<n00bzer> k thx
<holycow> would anyone be able to tell me the status of support for i945gm video chips and gma950 chipset by intel in dapper/edgy?  i'm not digging up information that answers this clearly
<BenC> Keybuk: what bugs?
<Keybuk> BenC: ath_pci oops on boot with .20
<Keybuk> hangs machine hard
<BenC> Keybuk: yeah, reported already
* Keybuk reports it harder
<fabbione> hey Keybuk 
<Keybuk> hey fabio
<fabbione> Keybuk: do you think you can upload udev today with that sparc fix? BenC should manage the kernel by the end of his day
<Keybuk> fabbione: won't get a chance this evening
<Keybuk> tbh, there's a lot of udev stuff piling up
<Keybuk> will likely do it January
<fabbione> Keybuk: do you have anything in the queue?
<fabbione> ok
<fabbione> can i just upload with that debdiff?
<Keybuk> go ahead and do it
<Keybuk> sure
<fabbione> ok thanks mucho
<fabbione> Keybuk: FYI: http://zeus2.kernel.org/git/?p=linux/kernel/git/davem/sparc-2.6.21.git;a=commitdiff;h=8e6f19ad3126c4eb650f2c5a9897cd3b9c72c146
<fabbione> and writing to the sysfs files.. now i know how to do it, but it's an expensive operation for just a flag that should be on/off
<Keybuk> it's just a call to sysfs_create_file, isn't it?
<fabbione> no
<fabbione> sysfs_create_file does indeed create the file itself
<Keybuk> btw, I can immediately spot a bug in that code <g>
<fabbione> then you need to associate a method that is called each time you read that file
<Keybuk> the uevent is sent before you add the whole_disk file
<fabbione> ehm.. no it's not...
<Keybuk> it isn't ?
<fabbione> that's the code that scan the partitions to create them in the kernel
* lamont gets popcorn
<Keybuk> yeah, there's a call to kobject_uevent a couple of lines above the sysfs_create_file call
<Keybuk> admittedly, I'm not reading this in context
<fabbione> i wasn't able to have /dev/sda3 mounted as boot anymore on machines that were doing it constantly..
<fabbione> so i assume that either the kernel path is waaaaay faster than udev
<Keybuk> doing which constantly?
<fabbione> or it doesn't matter
<Keybuk> kernel path is faster
<fabbione> i had machines that were mounting the wrong partition constantly
<fabbione> with that fix they don't anymore
<fabbione> so i assume it works
<Keybuk> gregkh will assumedly notice if it's wrong
<fabbione> partition_sysfs_add_subdir(p);
<fabbione> ^^ this is when the partition /sys/block/sda/sda3 is created
<Keybuk> yeah
<fabbione> so the call for whole_disk is done before the dir appears in /sysfs
<fabbione> hence no race
<fabbione> i win :P
<fabbione> but yeah we will see
<fabbione> for now i am happy as it is
<Keybuk> oh
<Keybuk> I see
<Keybuk> while it's scanning the first time, it sets that part_uevent_suppress thing
<Keybuk> so that implies a bug when rescanning partitions
<fabbione> ok, i didn't find anything in that direction.. will look at it again
<Keybuk> I'll bitch that directly to greg :)
<Keybuk> nothing to do with the Solaris path
<fabbione> eheh ok
<crimsun> cjwatson: (just reading backscroll at the airport) I've asked gpocentek if the question regarding merges for Xubuntu hasn't been addressed
<Zdra> is there known bugs with recent glib update ?
<Zdra> something like that: http://bugzilla.gnome.org/show_bug.cgi?id=388072
<Ubugtu> Gnome bug 388072 in General "Warning when opening a chat window" [Normal,Unconfirmed]  
<Zdra> ok the bug comes from a patch applied in the ubuntu package
<Zdra> If there is a glib packager for ubuntu, the patch shouldn't be applied, or be updated: http://bugzilla.gnome.org/show_bug.cgi?id=388072 
<Ubugtu> Gnome bug 388072 in general "Warning when opening a chat window" [Normal,Unconfirmed]  
#ubuntu-devel 2006-12-21
<bronson> Anyone mind looking over http://wiki.u32.net/Dpkg/Versions and telling me if I'm wrong anywhere or missing something?
<bronson> Oy, looks like dreamhost is suddenly having issues.
<cjwatson> crimsun_: thanks
<darwin188> can somebody help me out with ubuntu on a powermac g4
<HrdwrBoB> #ubuntu for support
<darwin188> x11 wont start
<darwin188> nah
<darwin188> here is where the good people are
<HrdwrBoB> that may be the case
<darwin188> it is indeed
<HrdwrBoB> but you won't get help here
<Burgwork> but #ubuntu is for support, not here
<darwin188> come on
<Burgwork> darwin188: you will be removed if you continue
<Burgwork> this is for development, not support
<_ion> burgwork: Btw, i quite liked the link https://wiki.ubuntu.com/UbuntuWeeklyNewsletter being in the beginning of Ubuntu Weekly News emails earlier.
<_ion> It would be nice to have it back in the future newsletters.
<Burgwork> _ion: hmm
<jdong> anyone know who Endersshadow is on the wiki?
<mdke> jdong: did you try a search in launchpad?
<jdong> no, actually didn't
<jdong> was looking on the wiki
<mdke> that's the only way
<jdong> ah
<mdke> you can get an email address that way, although not his name
<jdong> found him , https://launchpad.net/people/hewitte
<jdong> ok, good
<jdong> hmm, bc.edu.... is that Boston College?
<jdong> yep
<jdong> look at that, I'll be across the street from him in a few weeks :D
<jdong> mdke: maybe I'm not seeing it, but is it possible to attach files to the wiki?
<xerxas> why is ubuntu not setting PAGER to /usr/bin/less ? 
<mdke> jdong: sure, More Actions -> attachments
<xerxas> is there any good reason ? 
<jdong> ah cool
<fabbione> xeros: what's a good reason to change it?
<fabbione> hem
<jdong> xerxas: because it seems to use alternatives  instead
<fabbione> xerxas: ^^
<jdong> /usr/bin/pager
<jdong> update-alternatives --config pager
<xerxas> fabbione: because less does more than more 
<xerxas> :)
<jdong> huh? more was default?
<xerxas> because less isn't annoying when using completion 
<xerxas> jdong: I think so 
<jdong> less has always been selected as the pager on my machine...
<jdong> is this a Feisty thing?
<fabbione> xerxas: 
<fabbione> fabbione@daltanius:~$ which more
<fabbione> /bin/more
<fabbione> fabbione@daltanius:~$ which less
<fabbione> /usr/bin/less
<fabbione> that's why
<fabbione> in case of crash/recovery there is no guarantee to have /usr
<xerxas> fabbione: good :)
<fabbione> so it's user freedom to break what they want
<fabbione> the system by default needs to work
<xerxas> fabbione:  less won't never be in /bin ? 
<xerxas> more could be a link to less , or is that a too intrusive change ? 
<fabbione> xerxas: i don't personally know why less is in /usr/bin if not because there is more in /bin
<fabbione> a symlink is like hammering your testicles
<jdong> lol
<xerxas> a symlink ? 
<xerxas> to ? 
<xerxas> in /bin to /usr/bin ? 
<fabbione> (that's the best description i can think of)
<xerxas> surely not ! 
<fabbione> <xerxas> more could be a link to less , or is that a too intrusive change ? 
<fabbione> ^^^
<jdong> linking something from /bin to /usr/bin is pretty... iffy at best :D
<xerxas> I didn't want to say that :) 
<xerxas> tired 
<xerxas> less could be in /bin 
<xerxas> I wanted to say 
<mdke> even so, I bet hammering your testicles would be worse
<fabbione> xerxas: you said 2 things.. less in /bin AND more a link to less
<fabbione> (at the same time)
<fabbione> my answer was hammering
<xerxas> or less in /bin and more a link to less 
<fabbione> there are things that depends on more behavious
<fabbione> xerxas: we are saying the exact same thing
<xerxas> like colors for example probably ? 
<fabbione> my answer didn't change since
<xerxas> fabbione:  yup :)
<xerxas> ok 
<fabbione> you will keep hammering some parts of your body
<fabbione> mdke: be aware.. some people do actually LIKE that..
<xerxas> $ find /bin -type l  |wc -l
<xerxas> 10
<xerxas> lol
<xerxas> :)
* fabbione -> coffee break
<xerxas> jdong: does your completion uses less ? (or you using edgy ? ) 
<jdong> xerxas: man and most of the other commands that use a pager all use less on my boxes from Warty to Edgy :D
<jdong> I don't know about anything else though :)
<xerxas> jdong:  I think it's ok for man 
<jdong> ah, ok
<xerxas> but my shell completion seems to use more 
<jdong> then I havent' noticed it yet...
<xerxas> I'm reading man bash 
<jdong> maybe that's true
<xerxas> just open a gnome-terminal and hit 2 times [TAB] 
<mdke> fabbione: this is true. Whether you prefer that or a dodgy symlink depends on the individual, I suppose
<cjwatson> $ update-alternatives --display pager
<cjwatson> pager - status is auto.
<cjwatson>  link currently points to /usr/bin/less
<cjwatson> xerxas: that's built into the shell - it's neither less nor more
<xerxas> cjwatson:  seems so 
<xerxas> so it can't be changed ? 
<cjwatson> it can't be an external problem
<cjwatson> er
<cjwatson> program
<cjwatson> what in particular bothers you?
<xerxas> I would like to have a less like completion for commands 
<xerxas> for command completion I mean 
<cjwatson> you mean you would like to be able to scroll up and down in the list?
<xerxas> yep 
<cjwatson> xerxas: that's not possible in bash (unless you patch it to add that feature)
<cjwatson> it's not a matter of Ubuntu's configuration
<xerxas> cjwatson:  ok 
<fabbione> cjwatson: do you happen to know why we prefer gs-esp to gs-gpl ?
<fabbione> cjwatson: gs-esp is the trouble maker
<cjwatson> fabbione: I believe it's more up to date for other purposes
<cjwatson> fabbione: ask iwj
<fabbione> cjwatson: ok
<fabbione> thanks
<fabbione> iwj: ^^ if you happen to read...
<cjwatson> he's on holiday - I'd send mail if I were you
<fabbione> yeah i know.. it's not urgent or important
<fabbione> if he reads the scrollback good.. otherwise i will send him a patch
<fabbione> i have reduced the test case
<fabbione> so it shouldn't be impossible to debug once gdb is fixed :)
<keescook> fabbione: what's wrong with gdb?
<fabbione> keescook: it's broken on sparc... davem is fixing it on the other side of the room
<fabbione> it tends to explode easily
<keescook> ah, okay.  missed the sparc part.  :)
<fabbione> ehhe no problem
<zul> hey fabbione 
<fabbione> hey zul
<cjwatson> xerxas: possible workarounds: (a) just keep saying yes to "--More--" until you get to the end of the list, then use Shift-PageUp/Shift-PageDown to page up and down; (b) try zsh and see if you like its completion better
<cjwatson> (note that zsh is really quite a different shell, though)
<xerxas> cjwatson:  I've already had the idea to switch to zsh but never made the step :)
<_ion> /u/s/d/upst/RE<tab><tab>  /usr/share/doc/upstart/README.Debian.gz 
<mdke> cjwatson: what will be the best took in Feisty for manipulating and mounting partitions? We need to replace the gnome-disks-manager references in the documentation. gparted springs to mind, but something called pyGTK has been mentioned
<cjwatson> mdke: uh, pygtk is unlikely to be what whoever it was really meant
<cjwatson> mdke: pygtk => python bindings to gtk
<cjwatson> mdke: gparted is about the only candidate at present. Nothing is really actually GOOD.
<mdke> cjwatson: I beg your pardon. PyGTK Storage Device Manager (pysdm)
<cjwatson> oh, I have no idea
<cjwatson> sorry, I only do this stuff in the context of the installer which is a specialised use case
<mdke> what are you using in the installer, still gparted?
<cjwatson> gparted but will be replaced if I manage to do it in time
<cjwatson> the replacement will be a home-grown UI based on partman (the d-i partitioner)
<mdke> and which won't have an equivalent on an installed system?
<cjwatson> no
<mdke> cjwatson: shame. Ok, gparted it is, I guess
<cjwatson> pysdm looks rather scary and doesn't appear to do things like creating or resizing partitions
<cjwatson> partition management and fiddling with fstab are really completely different jobs
<cjwatson> creating and resizing partitions is hard to do on an installed system because some partitions on the disk in question are usually mounted which means the kernel won't reread the partition table until you reboot
<mdke> ah, does gparted not do the former?
<cjwatson> no, it doesn't do the latter
<mdke> latter, yeah. it's late
<cjwatson> if gnome-disks-manager does fstab fiddling, gparted isn't an appropriate replacement
<mdke> you're right, my bad
<cjwatson> I guess pysdm could do that, but jeez, presenting a UI for editing udev rules?
<cjwatson> scares the hell out of me, dunno about you :)
<cjwatson> but, it was a GSoC project for Ubuntu, so ...
<mdke> ah
<cjwatson> and I'm only going by the screenshot on its sourceforge page
<cjwatson> screenshots
<mdke> yes. Well, if windows partitions are always mounted by default on installed systems, and always available for non-administrative users, perhaps we can cut the instructions entirely
<mdke> problem is one sees lots of questions on support channels about accessing Windows partitions
<cjwatson> mm, that's basically an os-prober bug - does need to get fixed
<cjwatson> actually, no, I'm thinking of boot stanzas
<cjwatson> they should be mounted by default, unless people deselect the mount points
<mdke> my windows partitions used to be on the desktop mounted, but when I clicked on em, I got a permission denied from nautilus... dunno if the situation has changed, I killed that partition
<cjwatson> mdke: I fixed that in the installer (I believe) but it doesn't affect already-installed systems
<cjwatson> that sort of upgrade case is just a nightmare to handle and a security hole when got wrong, so best left alone
<mdke> hmm.
<mdke> cjwatson: was it fixed already for Dapper?
<cjwatson> yes
<cjwatson>   * Mount FAT and NTFS with umask=007,gid=46 (static group plugdev), so that
<cjwatson>     users can easily be given privileges to read/write mounted Windows
<cjwatson>     filesystems, and so that the first user can do so automatically (closes:
<mdke> ok, so probably majority of users not affected
<cjwatson>     Malone #8048, #25071).
<Ubugtu> Malone bug 8048 in partman-basicfilesystems "Mounted vfat partition is not writeable for non-root users" [Medium,Fix released]  http://launchpad.net/bugs/8048
<Ubugtu> Malone bug 25071 in partman-basicfilesystems "More reasonable defaults for ntfs mounts during installation" [High,Fix released]  http://launchpad.net/bugs/25071
<cjwatson> it was a fairly significant problem before that
<mdke> you bet
<mdke> cjwatson: thanks as always for your wise counsel.
* cjwatson steals and syncs libcairo, since seb128 seemed to be intending to do the same once directfb was fixed
<mdke> where has Kamion gone, I miss him a bit
<cjwatson> he got too confused with Keybuk
<Keybuk> yeah
<Keybuk> so confused that they got the same job
<cjwatson> heh
<mdke> ha
<cjwatson> rodarvus: ping, how're mesa/xorg-server/drivers going? those need to happen today
<mdke> is that the genuine reason for changing?
<cjwatson> well, the impetus was that I was away from home and my home server was inaccessible for some reason I forget, so I used an alternate nick and liked it better
<cjwatson> cjwatson's my username everywhere except Launchpad anyway
<Keybuk> you can likely get the LP id changed
<cjwatson> but I stuck with it for at least partly the reason above :)
<cjwatson> yeah, I just can't be bothered at the moment
<Keybuk> though they might tell you to make a cjwatson account and merge the kamion one into it <g>
* mdke registers cjwatson in LP and holds Kamion to ransom
* mdke discovers Kamion doesn't care
<mdke> ok, bed. thanks again for your help
<cjwatson> I wonder what happens if I just change the name in the personal details page
<cjwatson> whaddayaknow
<cjwatson> https://launchpad.net/people/cjwatson
<LaserJock> cjwatson: wow, I wondered if that would work
<LaserJock> were all your email addresses (canonical and ubuntu) cjwatson already?
<cjwatson> yes; well, kamion@ubuntu.com might have managed to work I guess but I never used it for anything
<LaserJock> hmm, interesting
<cjwatson> Canonical employees' e-mail addresses are "special" and not entirely dependent on LP username
<cjwatson> s
<LaserJock> I tried jmantha the other day but people complained
<LaserJock> cjwatson: ahh, that's good
<sistpoty> all my colors :P
<LaserJock> yeah, sistpoty was the biggest complainer because of his irssi colors
<LaserJock> :-)
<sistpoty> kvirc even
<LaserJock> ah
<LaserJock> darn, they need to put some sort of seperator for LP karma
<LaserJock> cjwatson's give me a headache trying to figure out how many digits ;-)
<cjwatson> oh, meep, what happens to bazaar.launchpad.net/~kamion/
* cjwatson renames back until he figures that one out
<sistpoty> see, there are so many reasons to keep the old nick, even besides my colors ;)
<fabbione> keescook: that gdb bug turned out to be gcc
<keescook> fabbione: icky! is it a straight-forward fix for gcc?
<fabbione> keescook: more or less... we are working on that.
<hads> There appears to be a bug in klibc-utils 1.4.30-3ubuntu1 that was synced from Debain, /usr/lib/klibc/bin/fstype is not functioning and messing with booting.
<minghua> hads: please report a bug: https://launchpad.net/distros/ubuntu/+source/klibc/+filebug
<minghua> hads: comments on IRC usually got lost
<minghua> hads: thanks
<hads> minghua: Thanks, I was asking in #ubuntu-bugs about the correct process as I didn't see feisty bugs on Launchpad. I'll do that now.
<cjwatson> hmm, the change doesn't look obviously wrong
<cjwatson> hads: exactly what is breaking?
<minghua> hads: yeah, Launchpad is sometimes confusing.  but generally no, for bugs there is no dapper/edgy/feisty differentiation
<cjwatson> indeed, don't report it under /distros/ubuntu/feisty
<hads> cjwatson: In scripts/local on my system $FSTYPE isn't being populated, so modprobe errors out and therefore / won't mount.
<hads> Sorry, scripts/local in the initramfs that is.
<cjwatson> and you're absolutely certain that was caused by just the klibc upload?
<cjwatson> as opposed to, for example, initramfs-tools, which also got uploaded today?
<hads> initramfs-tools hasn't been updated on my system yet, so it could possibly be a sync issue.
<hads> But this is the output of fstype
<hads> root@snowman:/usr/share/initramfs-tools# /usr/lib/klibc/bin/fstype < /dev/sda2
<hads> stdin: error 0
<bddebian> Heya
<cjwatson> hmm, reproduced
<hads> cjwatson: So, no, I'm not absolutely certain. I've just tried to debug it to the best of my ability.
<cjwatson> works under strace
<cjwatson> (argh)
<cjwatson> well, no, it doesn't really, it says FSTYPE=unknown then
<hads> It outputs the same error here under strace.
<cjwatson> hmm, assumes that pread will return a full block
* hads is out of his league
* cjwatson tests his theory
<hads> I've reported as #76675 - thanks for the pointers.
<cjwatson> I'm being stymied by a nightmare build system
<Hobbsee> cjwatson: it's not yada, is it?
<cjwatson> not that kind of build system
<cjwatson> (it's cdbs, but I'm not talking about the build system in debian/)
<Hobbsee> ah
<cjwatson>         if (argc > 1 && argv[1] [0]  == '-' && argv[1] [1]  == '\0') {
<cjwatson>                 fd = open(file = argv[1] , O_RDONLY);
* cjwatson beats klibc with a great big bat
<_ion> Uh. :-)
<ajmitch> that looks special
<cjwatson> hmm, the pread64 syscall shim is busted
<bddebian> cjwatson: You around?
<cjwatson> not really, just finishing this klibc fix and then I'll be off
<bddebian> Oh, not a biggie, I was just curious of the best way to tell why a package is in Debian but not in Ubuntu
<cjwatson> ask an archive admin ;) it varies - one common reason is that it's in http://people.ubuntu.com/~cjwatson/sync-blacklist.txt
<cjwatson> if it's in contrib, contrib packages are only synced on explicit request
<bddebian> Hmm, not there.. It's exaile
<bddebian> And it's in main
<cjwatson> it's listed by new-source, so I assume it's in the queue
<cjwatson> just hasn't been done yet
<cjwatson> ask Keybuk
<bddebian> Gah, OK, sorry
<bddebian> Not a big deal
<BenC> cjwatson: FYI, I am working on some brokeness caused by klibc and initramfs-tools
<cjwatson> BenC: I just uploaded klibc
<cjwatson> I don't know if it's precisely the right fix, but it's certainly the simplest
<BenC> cjwatson: What did you fix
<BenC> ?
<cjwatson> BenC: backed out jbailey's headers patch (plus a couple of other minor things)
<cjwatson> BenC: explanation in bug 76675
<Ubugtu> Malone bug 76675 in klibc "fstype error causes the root filesystem to not mount" [Critical,Fix released]  http://launchpad.net/bugs/76675
<BenC> sweet, that's the bug I was having
<hads> Yay, cheers cjwatson.
<cjwatson> off_t vs. loff_t confusion totally buggered a few syscall shims
<BenC> I can upload this initramfs-tools to fix the missing /bin/sh and then I just need to fix the problem with video handling
<cjwatson> hads: np, thanks for bringing it up in a timely fashion
<cjwatson> *sometimes* notifications of bug reports by IRC do help ;-)
<sfllaw> BenC: Who would know the most about why HAL is not getting ACPI power button presses?
<hads> heh
<cjwatson> BenC: oh, initramfs-tools was busted as well?
<BenC> cjwatson: Yeah, missing /bin/sh symlink
<cjwatson> fun
<sfllaw> Yikes!
<cjwatson> surprised anyone noticed the fstype breakage then :)
<BenC> me too :)
<BenC> must have been ideal archive timing
<cjwatson> oh, klibc was uploaded before initramfs-tools
<mjg59> Nf.
<mjg59> We're going to need to fix wireless-tools
<BenC> mjg59: The power state thing?
<mjg59> Oh, that's independent
<mjg59> But softmac requires that interfaces be up before you can set the essid, which wireless-tools doesn't currently do
<zul> BenC, the fstab thing? yeah i noticed this morning but didnt report it :(
<zul> oops
<BenC> cjwatson: Cool, your klibc + my initramfs-tools gets things booting
<fabbione> hey BenC 
<fabbione> BenC: do you think we can manage a kernel today?
<BenC> fabbione: Going to try, fixing this initramfs-tools bug really set me back
<fabbione> yeah i saw
<mjg59> BenC: There's a dscape-based ipw3945 driver which removes the need for the binary daemon. I'd be keen on getting that tested.
<mjg59> I'll try to sort something out for you next week
<BenC> mjg59: Ooh!
<BenC> where's it at, I'll test the damn thing right now
<mjg59> BenC: http://bughost.org/iwlwifi/ - it's not expected to work terribly well right now, but it'd be handy to find out *how* broken it is
<mjg59> There's a few references to the daemon in the docs, but as far as I can tell they're just out of date
<BenC> mjg59: 4615? Is that the new intel wireless?
<mjg59> BenC: Guess so
<mjg59> Maybe this isn't entirely public yet, then :)
<mjg59> Probably worth testing it, but not sticking it in the tree just yet
<Amaranth> heh, initial commit into git was 36 hours ago
<fabbione> BenC: 
<fabbione> dpkg: error processing /var/cache/apt/archives/initramfs-tools_0.85dubuntu1_all.deb (--unpack):
<fabbione>  trying to overwrite `/usr/share/initramfs-tools/scripts/local-top/lvm', which is also in package lvm-common
<BenC> fabbione: interesting...that file was added in debian's initramfs-tools
<BenC> mjg59: Yeah, I'm not even sure I was supposed to ask that question :)
<fabbione> BenC: we need to coordinate that with iwj, but he is on vacation. Can you please just not ship it for now?
<fabbione> BenC: because we are switching to udev -> lvm
<fabbione> and those scripts will almost disappear
<BenC> mjg59: Is this driver from Intel?
<BenC> I see nothing but Intel copyrights still
<BenC> fabbbione: Sure
<dholbach> good morning
<dholbach> I trust some people complained already about 2.6.20 not being bootable anymore?
<Fujitsu> I've heard about it not booting in some circumstances, yes. It works for me, though.
<dholbach> it was after the last dist-upgrade - mkinitramfs complains about busybox: not found - not sure if that's a red herring though
<orion2012> Would there be any valid reason to have a file in /etc/default be executable?
<orion2012> sysklogd seems to do this with two files it installs there
<orion2012> the sysklogd init script only sources them though
<Hobbsee> good thing i havent dist-upgraded today tehn
<orion2012> err, should I be asking elsewhere?
<Hobbsee> probably.  or just that the relevant person isnt here
<orion2012> ok, thanks
<StevenK> Hrm.
<StevenK> If I build cyrus-sasl2 with libdb4.3, it seems to pick 4.4, and makes a few things segfault. If I pick 4.2, it's all fine.
<sfllaw> dholbach: I don't know if I talked to you or seb128 about it.
<sfllaw> dholbach: But I wonder if we should standardize on 96dpi throughout all of *buntu.
<dholbach> sfllaw: right, you did talk to me, but I didn't take the idea to seb128 yet
<sfllaw> Hmm, OK.
<hunger> Any estimation when firehol, etc. will work again on feisty?
<lifeless> sfllaw: standardise ?
<lifeless> sfllaw: surely dpi depends on the physical medium, not on anything else
<sfllaw> lifeless: Yes, but only above certain resolutions.  About 200 DPI is required for things not to look too crazy.
<sfllaw> lifeless: See http://scanline.ca/dpi/
<sfllaw> lifeless: Interestingly enough, GNOME locks on to 96dpi once you login.
<sfllaw> lifeless: But not before.
<sfllaw> lifeless: Thereby causing strange font-size artifacts.
<lifeless> sfllaw: even after setting it within gnome ?
<sfllaw> lifeless: Yes, GDM relies on the X server telling it what DPI to use.
<lifeless> prefs->fonts->details->resolution
<sfllaw> lifeless: So if you have a monitor that's very large, you get illegible fonts.
<lifeless> sfllaw: as it should, only X knows. But its per screen
<lifeless> sfllaw: sorry, I'm confused. If you have a large screen, with low dpi, you should tell X (if it does't autodetect) that its a large screen with low dpi
<lifeless> and because gnome is braindead, you need to tell gnome that too, separately.
<sfllaw> Right.  But then 10pt (not 10px) fonts will be ridiculously small.
<sfllaw> lifeless: For GNOME, you _can_ tell it to trust X.  But it's generally a bad idea.
<lifeless> sfllaw: ? small? 10pt font is a fixed size. Do you mean lacking detail ?
<sfllaw> lifeless: You don't have enough dpi to make arbitrary a 10pt font look good in all circumstances.
<sfllaw> A 10pt font is a fixed size in reality.
<lifeless> sfllaw: thats right.
<lifeless> sfllaw: and this is why you can choose the fonts to be used throughout your desktop
<sfllaw> No, they won't hint properly.
<lifeless> and there is a formula we can create to set a sane default based on the actual dpi
<lifeless> sfllaw: is there a reference for that? I am really really confused
<sfllaw> lifeless: Read http://scanline.ca/dpi/ and http://scanline.ca/dpi/fonts.html for a good argument.
<lifeless> sfllaw: you seem to be saying 'when X has teh right dpi, and gnome has the right dpi, and fonts that are reasonable for the dpi are chosen, it will look bad
<sfllaw> Once we have screens that can pump out 300 DPI or better, then I'll side with the absolute font heights.
<sfllaw> lifeless: Yes, I am.  That's because the font renderers will try to make a 10pt font 10/72 inches tall.
<Treenaks> sfllaw: I have a 150dpi laptop
<lifeless> sfllaw: as they are -meant- to
<sfllaw> lifeless: Right.  But you can still see pixels on current screens.
<sfllaw> That's the problem.
<Treenaks> absolute sizes are SWEET :)
<sfllaw> So if you can see individual pixels, then you will see ugliness.
<sfllaw> Treenaks: Indeed.  I agree with absolute sizes on media that are paper-like.
<lifeless> sfllaw: I dont get the problem. Are you saying 'we should choose fonts based on the available dpi'?
<sfllaw> lifeless: No, I'm saying we should lock the DPI to 96, because that's what looks good consistently.
<lifeless> sfllaw: garh NONONONONO
<sfllaw> Be it a 3" screen or a 96" screen.
<sfllaw> lifeless: YES!
<lifeless> it looks like shit
<sfllaw> lifeless: Excuse me?
<Treenaks> dpi should be set to the screen's real DPI
<lifeless> I fixed my setup years ago, when I first got a non-96 dpi screen and couldn't stand the brokenness that result
<lifeless> ed from having it set to 96 when the screen wasn't.
<sfllaw> What broke?
<lifeless> the web
<lifeless> pdf viewing
<lifeless> document editing
<lifeless> terminal fonts
<sfllaw> You're going to have to explain more.  The web _unbroke_ for me when I set it to 96 DPI.
<sfllaw> As for PDF viewing, evince doesn't care much for DPI.
<sfllaw> And terminal fonts definitely benefit from proper hinting because of high contrast.
<Treenaks> sfllaw: If I force my 150dpi screen to 96dpi, I can't read anything anymore
<Treenaks> sfllaw: everything's so SMALL
<lifeless> sfllaw: having the dpi match the screen lets hinting work correctly, surely!
<sfllaw> lifeless: No, hinting engines aren't good enough.
<sfllaw> If you have a very high resolution screen, you can throw out your hinter.
<Mithrandir> sfllaw: non-bitmap terminal fonts look like shit in all cases for me, fwiw.
<lifeless> so, I can't be arsed right now, I'm on leave.
<sfllaw> lifeless: Fair enough.  :)
<lifeless> as long as there is an 'UNFUCK ME NOW' button, to let me control this, I will survive.
<Mithrandir> on normal 17" desktop screens and 12" laptop screens as well as 20" desktop screens.
<sfllaw> I'm only advocating a change to font DPIs.
<lifeless> I'll note that windows looks much nicer when you use the supplied knob within windows to set the right DPI for the screen
<sfllaw> I used to do that, but had very ugly widgets.  I don't know if that's still the case or not.
<lifeless> and what I see when I read that web page is an argument for fixing the hinter not breaking the dpi
<lifeless> its also worth asking whether macosX defaults to 72dpi because all their screens are 72 dpi :)
<sfllaw> Yes, I know.
<sfllaw> Vertical control makes some things better.
<lifeless> now I *do* support changing the fallback default in X to 96dpi
<lifeless> because I think that is a saner default than 75
<lifeless> but when X has been told by the hardware whats what, it should trust it (modulo a blacklist we can construct)
<lifeless> as for the web, its defined very strictly in terms of dpi - even png's have a defined dpi for web rendering.
<tepsipakki> btw, stay away from the HP LP3065 30" screen.. it supports _only_ the max resolution (2560x1600), nothing else :/
<lifeless> Treenaks: everything is small because font sizes are all defaulted to ~96 dpi environments - and that will fuck the web for you, because stylesheets are defined in terms of pt's, not in terms of pixels.
<sfllaw> lifeless: Actually, that's not quite accurate.
<Treenaks> pixels are a relative unit, according to the spec :)
<lifeless> Treenaks: if the css author defined their fonts as large,larger etc, it will work better once you change your browser defaults
<lifeless> Treenaks: yup
<lifeless> pixels are not pixels on the web :)
<sfllaw> lifeless: The web is completely messed up, because people will intermix points and pixels.
<Treenaks> lifeless: I blinked a few times when I read that
<lifeless> sfllaw: they are allowed to. pixels are defined as not being pixels
<sfllaw> lifeless: You do know that Opera is the only browser that actually honours CSS pixels, right?
<lifeless> http://www.w3.org/TR/REC-CSS2/syndata.html#length-units
<sfllaw> I know the standard!
<lifeless> sfllaw: I wasn't, but it doesn't surprise me, opera is pretty awesome
<sfllaw> It is, barring their non-freeness.
<lifeless> naturally
<lifeless> its why I dont use it
<lifeless> anyhow, this also covers the LCD projector argument, because thats clearly a case of wanting to preserve the visual angle
<sfllaw> I'm basically looking for relative sanity in rendering text until we get digital paper.
<lifeless> anyhow, dinner time, and I've had my anti-rant. Just give me a knob to unfuck whatever evilness is done, and I'm happy.
<sfllaw> All right.
<sfllaw> Have fun!
<lifeless> oh, one last point.
<pitti> carlos: any idea why there are no new langpacks on your people page since Dec 15?
<lifeless> don't tell *anyone* doing serious artwork/production that we're considering this
<pitti> lifeless: Hi Rob
<carlos> pitti: no idea, let me check...
<sfllaw> lifeless: Oh man.  The GDM startup screen is where I noticed this bug.
<sfllaw> lifeless: The screen optimized for someone's laptop looked terrible on a 40" monitor.
<carlos> pitti: db changes, I need to update my tree
<pitti> lifeless: FYI, I changed the apport code structure to the python package approach we discussed; also, the apport report now has proper methods to add debug info (I got rid of that apport_utils.py entirely)
<carlos> pitti: updating it...
<pitti> carlos: btw, feel free to clean up all the old tarballs, they need an awful lot of space
<carlos> ok
<carlos> pitti: thanks for the warning
<pitti> carlos: thank you for fixing :)
<sfllaw> lifeless: Especially because the theme was done entirely in screen pixels.
<lifeless> pitti: sweet
<sfllaw> pitti: Huzzah!
* sfllaw hugs pitti.
<lifeless> pitti: so also, we needed to talk about reporting failures from other users.
<lifeless> pitti: I think its important we allow this, so that a crash of e.g. a cron job under root, can be inspected and reported by the user
<pitti> lifeless: right; TTYL, need to run out for a bit
<lifeless> kk
<tepsipakki> both amd64 and ia64 failed to build checkinstall, "error: conflicting types for 'readlink'"
<tepsipakki> any ideas?
<Mithrandir> pitti: is it on purpose pmount isn't part of ubuntu-desktop any more?
* Hobbsee waves to Mithrandir 
* Mithrandir waves back to Sarah
<Hobbsee> :)
<sivang> morning
<sivang> interesting, can someone please renew my ubuntumembers membership? (it emaild me about expirey)
* sivang wonders if this will effect planet aggregation
<sivang> (and @u.c emails sent to)
<imbrandon> it shouldent effect planet
<imbrandon> but @mail no idea
<sivang> already asking in #lp
<pitti> Mithrandir: yes, it is
<pitti> Mithrandir: the hal mounting backend now doesn't use pmount any more
<pitti> Mithrandir: and everything else calls the hal functions now
<seb128> hey pitti
* pitti hugs seb128
* seb128 hugs pitti
<pitti> I'm not actually here, mind you :)
<seb128> pitti: you should really not join on IRC during holidays ;)
<seb128> hi tkamppeter, is cups known to be broken on feisty? like it refuses to add a printer
<seb128> gnome-cups-manager prints a "** (gnome-cups-add:6933): WARNING **: IPP request failed with status 1280" and doesn't add the printer
<tkamppeter> No, did not hear about such a problem. No one reported a bug about CUPS in Feisty.
<seb128> the web UI displays a ""413 Request Entity Too Large" page
<seb128> when trying to add an HP deskjet usb printer
<hunger> initramfs-tools and lvm-common conflict over /usr/share/initramfs-tools/scripts/local-top/lvm
<Mithrandir> pitti: oh, ok.  It seems g-v-m might need an update?  At least, I didn't get the usual "camera plugged in" dialog when I connected my card reader.
<pitti> Mithrandir: hm, worked fine for me, but the new libgphoto upstream version might have broken with your cam; can you please file a bug?
<pitti> Mithrandir: source package depends on whether gthumb can access the cam if you request a photo import from the menu
<Mithrandir> pitti: sure.  It's just a regular sandisk USB mass storage device.
<pitti> Mithrandir: ah, mass storage, then it's not libgphoto
<pitti> Mithrandir: can you please file a g-v-m bug with the https://wiki.ubuntu.com/DebuggingRemovableDevices info?
<tkamppeter> I have set up a printer (USB) with the web interface now and printed a test page, on a completely updated Feisty. CUPS seems to be perfect for me.
<pitti> seb128: ^ WFM, too (just added a new printer yesterday)
<Mithrandir> pitti: also, I don't see the device on my desktop, but that's probably something fucked in nautilus, somewhere.
<seb128> pitti, tkamppeter: let me try again
<seb128> Mithrandir: is it listed to computer:?
<pitti> Mithrandir: but that's a good hint, might actually be the same reason
<pitti> Mithrandir: sounds more like a hal bug now; is the device mounted automatically?
<hunger> Mithrandir: I didn't get an icon in KDE for my CDs anymore either, but that is probably unrelated.
* pitti -> breakfast, bbl
<tkamppeter> mvo has uploaded my new splix package yesterday and it still did not arrive in the repositories, checked both http://archive.ubuntu.com/ubuntu/pool/universe/s/ and http://archive.ubuntu.com/ubuntu/pool/main/s/
<Mithrandir> pitti: yes, it's mounted.
<tkamppeter> How long will this take?
<pbor> hunger: for what is worth I just reported the lvm conflict in launchpad (76708)
* pbor goes back to lurking
<hunger> pbor: Thanks!
<Mithrandir> seb128: no, or rather, I see an icon for "generic STORAGE DEVICE" and it mounts the device again when I double click that icon.
<hunger> pbor: I try to avoid using LP;-)
<seb128> pitti, tkamppeter: works fine today, go wonder, thanks anyway ;)
<Hobbsee> tkamppeter: did it build?
<seb128> Hobbsee: that's a NEW package
<Hobbsee> ah right
<seb128> tkamppeter: until somebody accept it from NEW
<tkamppeter> Hobbsee, on my 32-bit laptop it builds, and on 64 bit it should build, too (some months ago I added it to Mandriva). I did not get any feedback from mvo or from a Ubuntu bot about any build problems.
<tkamppeter> seb128, who has to accept it? Can someone here do so?
<Hobbsee> tkamppeter: if it's sitting in NEW, then it tends to take a while
<seb128> not sure if Mithrandir does NEW atm
<tkamppeter> Where is NEW? Can I see what is currently in NEW?
<Mithrandir> seb128: I'm on VAC, but I can NEW for stuff which is blocking development
<Hobbsee> yes, it's on LP, but i dont have the direct link, and i'm on a different OS
<Mithrandir> seb128: as in, I'll do it by request, but not actively go looking at it.
<seb128> Mithrandir: apparently tkamppeter is waiting on splix
<tkamppeter> Mithrandir, can you accept splix? Thanks. Many Samsung printer uses will get a nice xmas present by that.
<Mithrandir> tkamppeter: I can review it when I get home in a couple of hours, sure.
<tkamppeter> Mithrandir: OK.
<pitti> Mithrandir: ok, please file a bug against g-v-m with the debug data then; I'll reassign it to hal if approriate
<pbor`> running gdb crashes my system... just good old printf today
<seb128> pbor`: use 2.6.17, linux-image-2.6.17-10-generic is still available
<seb128> I do that
<Mithrandir> pitti: I'll do that when I get back from yule shopping.
<pitti> Mithrandir: 'yule'?
<Mithrandir> christmas
<pitti> is that the Norwegian Christmas?
<pitti> ah
<Mithrandir> 'cept I'm not christian, so it's less christ and more mas.  Or something. :-P
<pbor`> seb128: that's for the suggestion
<pbor`> s/that's/thanks
<seb128> np
<cjwatson> rodarvus: ping, X
* StevenK waits for Keybuk
<StevenK> cjwatson: Since he isn't here, might I raise my concern with you?
<cjwatson> StevenK: that depends what it is?
<cjwatson> I mean, sure, you can try :)
<StevenK> cjwatson: Looking at the cyrus-sasl2 merge, Keybuk made a change to have it build against libdb4.3. If I do that, saslpasswd2 segfaults, but if I build it against 4.2, it's fine.
<cjwatson> oh, sorry, I have no idea ...
<StevenK> Right. When's the deadline?
* StevenK shall lie in wait for Keybuk.
<cjwatson> later today
<cjwatson> usually the distro team meeting
<sivang> cjwatson: any idea what can I do with my membership auto-expiery ? Can you or someone else from CC renew my membership?
<cjwatson> sivang: next CC meeting I guess
<cjwatson> we don't have an established procedure yet - it will probably be fairly trivial though
<cjwatson> "are you still alive?" "yes" "NEXT"
<cjwatson> but I don't want to do it unilaterally
<Hobbsee_> heh
<Hobbsee_> too bad if someone answers "no"
<ogra> cjwatson, could it be that something in pam changed that can cause bug 76632 ? i run the 2.17.4 version here but with a non updated libpam and dont see the bug, whereas nearly everyone else with an up to date system seems to see it
<Ubugtu> Malone bug 76632 in gnome-screensaver "screen does not unlock after locking" [Undecided,Confirmed]  http://launchpad.net/bugs/76632
<ogra> (the 2.17.4 version of gnome-screensaver i mean)
<cjwatson> ogra: I don't think so - the only change in pam_unix was a trivial segfault fix
<cjwatson> there don't seem to be any messages in the posted auth.log from gnome-screensaver?
<jinty> hi, anyone know where I can find Henrik Nilsen Omma (henrik I guess)?
<dholbach> jinty: heno is his nick.
<gnomefreak> is mvo on holiday?
<dholbach> gnomefreak: yes
<gnomefreak> thought so ty
<jinty> dholbach: any chance he'll be around today? Or can I find anyone else with access to the support services for schooltool.org?
<dholbach> jinty: hang on, I'll have a look if he's on holidays already
<dholbach> jinty: I suppose he'll be around during the day.
<jinty> dholbach: thanks, i'll wait a while then before trying other things!
<cjwatson> henrik is off with technical problems at the moment
<cjwatson> he wasn't sure whether he'd be back on today
<StevenK> Keybuk: Looking at the cyrus-sasl2 merge, you made a change to have it build against libdb4.3. If I do that, saslpasswd2 segfaults, but if I build it against 4.2, it's fine. Any thoughts?
<Keybuk> no idea, I just took that change from the previous merge
<StevenK> Right, I'll drop it, and note I've done so.
<tepsipakki> fujitsu: <sigh> why do they differ?
<tepsipakki> damn
<StevenK> Now, who can I bug to look at my cyrus-sasl2 merge?
<olemke> ogra: it seems to be g-s's fault really. downgrading pam to the version from edgy doesn't solve the issue but running g-s 2.16.1 with the latest pam works
<fabbione> dpkg: error processing /var/cache/apt/archives/initramfs-tools_0.85dubuntu2_all.deb (--unpack):
<fabbione>  trying to overwrite `/usr/share/initramfs-tools/scripts/local-top/lvm', which is also in package lvm-common
<fabbione> BenC: didn't you fixed this one?
<BenC> fabbione: Just uploaded the fixed package
<BenC> ubuntu3
<fabbione> ah ok
<BenC> also fixes the vga16fb loading that was corrupting displays
<fabbione> eheh
<BenC> new initramfs-tools has some nice stuff in it though
<BenC> like video=<fb>:<opts> parsing
<BenC> And if I'm not mistaken, the resume machinery now supports suspend2
* StevenK looks for a sponsor for his cyrus-sasl2 merge before going to sleep.
<fabbione> StevenK: did you test it properly?
<fabbione> StevenK: if i can take your word for that, i will sponsor
<fabbione> but don't ask me to do extra review...
<fabbione> ok.. new gcc fixes gdb properly
<fabbione> YEPPA
<StevenK> fabbione: It installs and saslpasswd2 doesn't segfault like it did.
<fabbione> StevenK: slam the debdiff somewhere
<StevenK> Against the latest Debian or Ubuntu version?
<fabbione> StevenK: if you want me to sponsor an upload/merge, i need it against the latest ubuntu package
<StevenK> fabbione: http://wedontsleep.org/~steven/cyrus-sasl2.patch
<StevenK> fabbione: Thanks
<fabbione>   cyrus-sasl2_2.1.22.dfsg1-8ubuntu1_source.changes: done.
<fabbione> Successfully uploaded packages.
<fabbione> StevenK: now you get the blame if it breaks
<StevenK> I figured. :-)
<bddebian> Heya
<cbx33> ping mdz 
<Keybuk> cbx33: unlikely to respond at 7am
<cbx33> oh i dunno :p
<cjwatson> ... while on holiday
<cbx33> cjwatson, Christmas miracle?
<cbx33> was wondering if anyone could shed any light on a little problem I have then
<cbx33> the ldm glade file won't open in glade....stating it needs a gnomecanvas catalog
<cbx33> I've looked around but am unable to find anything like that
<cbx33> any clues?
<Keybuk> I can safely say that mdz is likely to give a very vacant look if you asked him that :)
<cbx33> oh...someone said he was the origial author of ldm
<ogra> cbx33, yes, all the backend code is his
<cbx33> oh....
<bddebian> cbx33: Does gnomecanvas come from diacanvas2?
<ogra> and remained unchanged in most parts
<cbx33> ogra, who did the font end?
<ogra> me
<cbx33> ah...
* fabbione -> coffee break
<cbx33> then maybe you can shed light
<ogra> bddebian, gnomecanvas is the pre-cairo ;)
<ogra> its older thqan diacanvas
<bddebian> Ahh OK :-)
<bhale> man
<cjwatson> phew, libx11 merged
<bhale> cairo dia would be awesome
* cjwatson goes off for a belated afternoon's holiday
<bhale> with some hot stock art
<Keybuk> cjwatson: enjoy
<ogra> i guess thats about to come at some point :)
<Keybuk> a GNOME app something of a cross between Visio and Graphviz would be nice
<ogra> olemke, well, i dont see it at all here on three machines that arent fully upgraded but use the latest screensaver package 
<cbx33> so ogra anyway i can thi s working
<ogra> thats why i suspect its someting else
<bddebian> bhale: Good, help me fix diacanvas2 then ;-P
<ogra> cbx33, i think you need python-gnomecanvas installed 
<ogra> try that
<cbx33> ok I'll check that
<cbx33> thanks bud
<cbx33> was pulling my hair out the other day
<bhale> bddebian: meh.
<cbx33> ogra, as I suspected
<cbx33> python-gnomecanvas is still installed
<cbx33> is aready installed
<cbx33> any futher ideas?
<bddebian> cbx33: Is it looking in the right place? :)
<cbx33> bddebian, I'm not sure.....if it isn't then that's a bug surely?
<Simira> cjwatson: found your camera yet?
<olemke> ogra: i don't know if it helps, but here's the strace log after entering the password http://ubuntu.pastebin.com/842665
<ogra> i dont see anything suspicious ...
<fabbione> Unpacking replacement initramfs-tools ...
<fabbione> dpkg: error processing /var/cache/apt/archives/initramfs-tools_0.85dubuntu3_all.deb (--unpack):
<fabbione>  trying to overwrite `/usr/share/initramfs-tools/scripts/local-top/lvm', which is also in package lvm-common
<fabbione> BenC: this is ubuntu3
<fabbione> still error there
<BenC> fabbione: I was sure I removed that
<fabbione> dpkg lies :)
<desrt> uhm.  hi.
<desrt> The following packages will be REMOVED: startup-tasks system-services ubuntu-minimal upstart upstart-compat-sysv upstart-logd
<desrt> The following NEW packages will be installed: sysvinit
<desrt> ^^ apt-get dist-upgrade on a system that's currently running edgy
<_ion> What does apt-cache madison sysvinit say?
<desrt> odd.  it's trying to come from breezy.
<desrt> i guess having old distributions in your apt.sources isn't legit?
<desrt> i'd sort of assume that as long as you didn't have -security or -updates then you'd pretty much be okay because the old distro would only have older versions of everything....
<Seveas> desrt, problem is that sysvinit is essential in breezy
<Seveas> so it will install it :)
<desrt> it was never a problem until just now
<desrt> very odd.
<dade`> desrt: did you debugged new kernels for sleep on macbooks ?
<desrt> dade`; no.  i have not.
<desrt> no idea what's wrong this time
<desrt> and i have significantly less desire to find out.
<dade`> noo
<dade`> you were my only hope
<desrt> sorry..  last time was painful enough.  i don't feel like going through it again.
* dade` goes upstairs to take the OSX dvd
<desrt> try git disecting :)
<dade`> desrt: will someone do that ?
<desrt> dade`; you could :)
<dade`> desrt: i have a life
<desrt> dade`; so do the rest of us
<dade`> and i'm not good enough
<fabbione> distro meeting is in 2 hours, right?
<Ng> is gnome-screensaver supposed to not accept my password in feisty atm? ;)
<cge> Ng: I haven't had that happen yet.
<somerville32> @schedule
<Ubugtu> Schedule for Etc/UTC: 21 Dec 21:00: Ubuntu Development Team | 27 Dec 12:00: Edubuntu | 28 Dec 08:00: Ubuntu Development Team | 02 Jan 20:00: Technical Board | 03 Jan 20:00: Edubuntu | 03 Jan 22:00: Xubuntu
<Mithrandir> Ng: I don't think it's _supposed_ to happen, but I see the same thing.
<Ng> Mithrandir: I figured it wasnt a new feature ;)
<kylem> the ultimate in security.
<Mithrandir> kylem: apart from it causing me to C-A-F1 + killall gnome-screensaver, yeah.
<ogra> Ng, i'll upload a patched version after the distro meeting
<ogra> hopefully that fixes it
<Ng> groovy :)
<ogra> bug 76632 is the corresponding bug btw
<Ubugtu> Malone bug 76632 in gnome-screensaver "screen does not unlock after locking" [Undecided,In progress]  http://launchpad.net/bugs/76632
<mdke> nice, that's bitten me too
* mdke hugs ogra 
<cbx33> ogra, you fixed it
<cbx33> way to go
<ogra> seems upstream has a patch, but indeed it doesnt apply without manual work ... so give me some time
<cbx33> what's the best text to speech engine we have?
<cbx33> festival?
<ogra> thats the default one iirc
<cbx33> anyone know of any better ones?
<ogra> dunno if thats the best though
<keescook> has anyone looked the icon situation in firefox?  I'm building up the 2.0.0.1 release, but when I tried to fix the icons, it ah... stopped having any icons at all.  ;)
<toma> anyone know, how often is the new queue of the archive processed?
<fabbione> toma: every hour
<fabbione> or hold on
<fabbione> the queue is processed every 5 minutes or so
<fabbione> but to get a binary in the archive from the upload (assuming the binary takes less than one hour to build) it takes approx 2 hours
<toma> fabbione: i mean the list at https://launchpad.net/distros/ubuntu/feisty/+queue
<fabbione> so upload -> source into archive is about one hour
<fabbione> -> down to the buildd (+build time) -> back to archive (another hour assuming the build time < 60minutes)
<fabbione> toma: if you mean NEW packages, that's done manually
<fabbione> it depends when people have time
<toma> fabbione: okay
<toma> fabbione: i'll wait a bit more then
<toma> thanks
<fabbione> toma: don't sweat it tho.. a lot of people are in holidays right now
<toma> fabbione: hmm, too bad. holidays should be forbidden anyhow
* keescook makes organ-grinder gesture waiting for firefox to compile.
<ajmitch> you may be waiting a little while
<desrt> i wonder what an organ-grinding gesture is
* somerville32 demonstrates with desrt.
<tkamppeter> @schedule paris
<Ubugtu> Schedule for Europe/Paris: 21 Dec 22:00: Ubuntu Development Team | 27 Dec 13:00: Edubuntu | 28 Dec 09:00: Ubuntu Development Team | 02 Jan 21:00: Technical Board | 03 Jan 21:00: Edubuntu | 03 Jan 23:00: Xubuntu
<sladen> @schedule london
<Ubugtu> Schedule for Europe/London: 21 Dec 21:00: Ubuntu Development Team | 27 Dec 12:00: Edubuntu | 28 Dec 08:00: Ubuntu Development Team | 02 Jan 20:00: Technical Board | 03 Jan 20:00: Edubuntu | 03 Jan 22:00: Xubuntu
<keescook> desrt: http://en.wikipedia.org/wiki/Organ_grinder
<keescook> mostly just a cranking motion next to my machine.  trying to make it run faster.  :)
<sladen> the instrustment might have wood-worm, that'd count as a bug
<bhale> sladen: oh that rules
<geser> is it normal that a package is in "Needs building" state for nearly 8 days?
<bhale> geser: could it be NEW?
<keescook> geser: which package?
<geser> https://launchpad.net/+builds/+build/285683
<geser> it changed two minutes ago :)
<keescook> E: Couldn't find package libneon26-dev
<keescook> libneon26-dev is in universe, but subversion is in main, so it won't build.
<tkamppeter> How is the progress on the package Splix which is in NEW?
<geser> should it be build against libneon25-dev? or should neon26 move into main and replace neon?
<mjg59> tkamppeter: It's quite likely that stuff in NEW won't be processed until after the holidays
<keescook> geser: I'm not sure; probably promote libneon26 and demote libneon25.  Someone more familiar with subersion or libneon should probably say.  :)
<geser> keescook: have you a suggestion whom should I ask?
<keescook> geser: from the changelog, I'd say doko
<geser> doko_: are you around?
<zyga> hello
<doko> cjwatson, Mithrandir: please process sun-java6 in NEW
<doko> cjwatson, Mithrandir: please promote neon26 to main (build dependency of OOo, neon25 already is in main)
<geser> neon26 is also a build-dependency of subversion
<doko> geser: btw, pong
<geser> you already solved it with your request to promote neon26
<geser> it was about subversion build-depending on libneon26-dev
<cjwatson> doko: neon26 promoted
<cjwatson> (doesn't need an MIR since neon is already in main)
<doko> Mithrandir: if you are around when neon26 shows up in main, pleae requeue openoffice.org and openoffice.org-l10n on i386, amd64, powerpc, sparc
<Mithrandir> doko: sure.
<Mithrandir> that's just a publisher run away, so about an hour.
<doko> cool, thanks
<geser> Mithrandir: please requeue also subversion, it waits on libneon26-dev
<Mithrandir> geser: that's depwait, it'll be done automatically
<Mithrandir> doko: actually, same goes for ooo, it'll be done automatically.
<cjwatson> ogra: in case this is what's confusing you, debian-cd doesn't *have* to involve putting the bootability goop onto the CD
<cjwatson> ogra: a fair chunk of debian-cd is just logic for getting packages onto the CD, which is all you ened
<cjwatson> need
<ogra> like apt-ftparchive
<cjwatson> sort of, yes
<cjwatson> it's all integrated with our CD building and publishing setup already so there's no point in duplicating that
<ogra> thats what i thought, i need a seed or something that provides the package list and something like apt-ftparchive that builds the structure, the rest is mkisofs
<cjwatson> "something like apt-ftparchive" => debian-cd
<ogra> yep i start getting it :)
<cjwatson> and of course debian-cd handles mkisofs etc. too
<cjwatson> the only fiddly bit is naming the CD output correctly (it's a horrible mess of Makefile, don't ask) and tweaking the cdimage wrapper scripts to germinate it all correctly
<ogra> well, with some effort it wont be to hard i think
<Burgwork> tkamppeter: there is a nasty regression with samsung printers and cups  1.2.2 in dapper, are you person to talk to about it?
<cge> Is there some reason why the default bashrc in feisty sets HISTCONTROL=ignoredups and then immediately replaces it with HISTCONTROL=ignoreboth?
<Adri2000> cjwatson: libdjconsole binary packages are in NEW
<cjwatson> Adri2000: that's nice :)
<Adri2000> hehe, the implicit question was could you approve them? :p
<cjwatson> not at 10pm right after a meeting when I really want to get back to the pub, no
<tkamppeter> Burgwork: CUPS was always packaged by pitti, and as I entered Ubuntu I was already on Edgy ...
<Adri2000> ok, no problem, that will probably be tomorrow :)
<cjwatson> either somebody else does them, or it can wait until tomorrow now
<Adri2000> okay
<sistpoty> cjwatson: and delete a package from new (we have a better version to be uploaded instead the one in new)?
<doko> cjwatson: you should get a umts flatrate :-P
<tkamppeter> Burgwork: Can you let Ubugtu post a link to this bug here?
<Burgwork> yep, just a sec
<Mithrandir> sistpoty: just upload a newer version
<sistpoty> Mithrandir: that works with the same version number? cool :)
<Mithrandir> sistpoty: version numbers are cheap, just bump it.
<bddebian> heh
<sistpoty> Mithrandir: but the orig.tar.gz has a different md5sum, but no new upstream version... still no probs?
<sistpoty> *g*
<cjwatson> sistpoty: what's the package name?
<Burgwork> https://bugs.launchpad.net/products/cupsys/+bug/55828
<Ubugtu> Malone bug 55828 in cupsys "PJL output from 1.2.2 client over IPP" [Unknown,Unconfirmed]  
<cjwatson> you have 30 seconds :)
<sistpoty> cjwatson: klear
<sistpoty> *phew*
<bddebian> hehe
<cjwatson> sistpoty: is the uploader here?
<tkamppeter> Thanks, Burgwork.
<cjwatson> + -- Marcus Czeslinski <kubuntu@czessi.net>  Sun,  3 Dec 2006 18:38:41 +0100
<bddebian> No but the new version is from the same
<sistpoty> cjwatson: doesn't look like it... he's czessi_away in -motu
<cjwatson> did he request the reject?
<bddebian> He built a newer version on REVU
<cjwatson> link?
<sistpoty> http://revu.tauware.de/details.py?upid=3765
<bddebian> http://revu.tauware.de/details.py?upid=3765
<bddebian> Gah, you beat me
<sistpoty> *g*
<cjwatson> I see
<cjwatson> sistpoty: please tell him I've rejected it at his request
<sistpoty> cjwatson: will do, thanks
<cjwatson> (checked #ubuntu-motu logs and found said request)
* cjwatson -> pub
<bddebian> Enjoy
<sistpoty> have fun, cjwatson
<tkamppeter> Burgwork, this is a simple SRU request issue. In Edgy and Feisty it is fixed and working.
<BenC> I hate it when ppl go on tag frenzies in lp
<BenC> especially when the tags make no sense
<jdong> just wait, one day you will ALL see the merit of me importing all my del.icio.us tags into Launchpad, then you'll be sorry ;-)
<BenC> I also hate when random people decide to triage a bug report and then think that they should Assign the bug to themselves
<BenC> when it isn't even confirmed yet
<Fujitsu> BenC, I love that too! It's really really productive.
<BenC> Don't get me wrong, I love the help, but I hate the extra work it sometimes causes :/
* sistpoty hopes, BenC isn't pointing towards sistpoty
<BenC> sistpoty: I don't recognize your name, so you aren't on my shitlist as of yet :)
<sistpoty> ha, yeeehaa... I guess I only forgot one or two bugs assigned to me so far *g*
<BenC> sispoty: But if you've triaged any linux-source-2.6.* bugs and assigned them to yourself for no good reason, please fix ASAP :)
<BenC> or even better, fix the bug :)
<sistpoty> BenC: no thanks, I'll stay away from linux-source-* for a few miles ;)
<sistpoty> I just file bugs on it :P
<sfllaw> seb128: Bug 70986 is ready to go into edgy-updates.
<Ubugtu> Malone bug 70986 in vino "CoRRE bug prevents connection from Nokia 770 to edgy" [Medium,Fix committed]  http://launchpad.net/bugs/70986
<seb128> sfllaw: thank you
<sfllaw> seb128: I had to flash my 770.
<sfllaw> That took forever to get running.
<seb128> and now you can enjoy doing vnc with it ;)
#ubuntu-devel 2006-12-22
<Burgwork> BenC: if the bug is needinfo, bug triaging rules say assign to the person who set it needinfo
<BenC> Burgwork: Ok, I have differing rules for what I want done
<Fujitsu> Burgwork, since when?
<BenC> I don't see why needsinfo needs that, sounds silly
<Burgwork> BenC: you need to talk to sfllaw
<BenC> you can look at the comments to see what was asked for
<BenC> and by whom
<BenC> and look at history to see who set it that way
<BenC> Anyway, for linux-source-2.6.x, I don't want it assigned until it has been triaged, set to confirmed, given a priority, and decided that it can be fixed
<Burgwork> smart bug triagers should avoid nasty bug morasses like the kernel anyway...
<sfllaw> BenC: The reason to do assignment is so you can search for what you're responsible for.
<Burgwork> seb128: http://www.cups.org/str.php?L1869 <-- does Ubuntu have a fix for this specific issue?
<BenC> sfflaw: it is quite common for several people to be asking for information on a single bug (at least for kernel source)
<seb128> Burgwork: I'm not doing any cups work, dunno
<sfllaw> BenC: It's true.  But people on BugSquad take responsibility for bugs.
<Burgwork> seb128: just wondering. CUPS is driving me bonkers
<BenC> sfllaw: Are they going to fix them aswell?
<sfllaw> They will set it to Nobody once they finish triaging.
<BenC> sfllaw: can't they just subscribe to a bug?
<sfllaw> How do you differentiate between bugs you're interested in and bugs you're working on then?
<BenC> sfllaw: Are BugSquad folks really interested in so many bugs that it's not easy to distinguish them from ones they are triaging? :)
<sfllaw> It looks like it.
<sfllaw> If you see some people's +subscribedbugs list.
<BenC> sfllaw: brb, I got coffee waiting
<sfllaw> BenC: Of course.
<sfllaw> BenC: What problems does this procedure cause for you?
<sfllaw> BenC: We considered this pretty carefully in Paris, Wiesbaden, and Mountain View.
<BenC> sfllaw: Basically, I assume if a bug is assigned, it is being fixed by someone
<BenC> sfllaw: I may be flexible on this, but I'd have to reconsider how my workflow has been going
<somerville32> I always thought like BenC
<sfllaw> BenC: Can you look at it as "if Status >= Confirmed && assigned" then it's being worked on?
<somerville32> I only assign myself to a bug if I'm actually fixing it
<ajmitch> sfllaw: this sounds like the same question I had a day or two ago
<sfllaw> Yes.
<seb128> I don't use assignement if I'm not going to fix the bug myself
<sfllaw> mdz, sabdfl, and I talked about this as part of the bug-workflow spec.
<sfllaw> Basically, assignment is used for triaging and fixing.
<sfllaw> And there is an unassignment in between.
<BenC> sfllaw: I guess it's just my way if thinking...It just seems like Assignee is being overloaded for this, when you really want something else instead
<sfllaw> In triaging, it means "I am going to take responsibility for triaging this bug."
<sfllaw> In fixing, it means "I am going to take responsibility for fixing this bug."
<seb128> there is a difference between the bug triager looking at something and the package maintainer which has a look at all the bugs on his package
<seb128> there is no point for a maintainer to use assigne like that
<sfllaw> seb128: I don't understand how this is different from what I'm saying.
<BenC> sfllaw: I guess as long as the unassignment doesn't start getting overlooked, I have no problem with it...my main concern is that some other people (sometimes the bug submitter, or an ACKer) will set the bug confirmed, and if it's not caught, then the bug is in a state where I think someone is actually fixing it
<sfllaw> BenC: Right.  I'm being vigilant about that.
<seb128> sfllaw: I didn't say it's different from what you are saying ;)
<sfllaw> seb128: Oh, OK then!
* Starting logfile irclogs/ubuntu-devel.log
<sfllaw> *gasp* Why does killing gnome-screensaver not take down my session?
<Lathiat> thats a "security feature"
<Lathiat> i.e. someone just crashed the screensaver, dont give them access to my session
<Lathiat> xscreensaver does it too
<Lathiat> that said, GSS isnt unlocking for me in feisty atm
<bhale> he said "not"
<Lathiat> oh, not?
<Lathiat> hrm
<Lathiat> it has done that in the past for me
<bhale> doesnt for me
<Lathiat> that said, i did kill it the other day and it didnt nuke my session
<Lathiat> so your right, perhaps its not atm
<Fujitsu> I've never had it nuke my session, and I kill it a lot :P
<bddebian> Heya
<PuMpErNiCkLe> If you can kill it, you've basically got access anyway - right?
<Fujitsu> PuMpErNiCkLe, pretty much.
<jdub> Lathiat: i just foudn that problem with gss
<jdub> but killing it didn't kill my session
<bddebian> Can anyone tell me why diacanvas2 is sitting in NEW?  It's the same version already in the archive.
<Fujitsu> bddebian, why would it be sitting there? Did it finally build!?
<geser> Fujitsu: I fixed it
<Fujitsu> geser, very good :)
<geser> bddebian: it produces a new binary (libdiacanvas2-1)
<bddebian> geser: Oh, you did?
<bddebian> Rockin?
<bddebian> s/?/!/
<ademan> i've decided i need to learn  autotools, can anyone help direct me?  I've read a bit of the auto book, but i'm a bit confused about what files i need to write, what is generated at the pre-build stage (well, probably the wrong term, but like how it generates configure) and so on
<Hobbsee> try #autotools or #automake
<ademan> unfortunately neither seem to be populated
<Hobbsee> ah
<Hobbsee> i'd try a website on it or something?
<ademan> yeah i dunno, i've actually read quite a bit, i can write the files, i'm just unclear on WHAT i have to write, what to name them, etc
<sfllaw> ademan: The Goat Book is a good reference.
<sfllaw> ademan: Autotools -> http://sources.redhat.com/autobook/
<sfllaw> PuMpErNiCkLe: No, you don't yet have the state of the user's applications.
<sfllaw> PuMpErNiCkLe: You might have been able to crash the screensaver.
<ademan_> hey, i had a question about system events.  Linux has them right?  For instance with hotplugging devices right?  Well is there any reason why a system event can't be sent when a computer loses and reconnects it's internet?  For instance when i grab my laptop and unplug it and go into my living room and it connects to my wireless network (automatically thanks to the network manager applet) shouldn't it/couldn't it just send
<ademan_>  out some sort of message for things such as gaim and x-chat to pick up and take as a cue to reconnect to their respective servers?) 
<jdub> ademan_: the work on network-manager involves those messages
<Chipzz> ademan_: as a side-note, I think that's a REALLY bad idea
<Chipzz> but that's just me
<ademan_> Chipzz: Why? it would be very convenient imho
<Chipzz> if I have a temporary loss of wifi for example, windows disconnects ALL my putty sessions
<Chipzz> and given that it's temporary, they could have very well recovered
<ademan_> hrm, that is true, but how hard would it be to NOT do that if the reconnect is on the same network interface?
<Chipzz> I HAVE lost word this way in the past
<ademan_> i don't know anything about the messaging system but i assume it would include more than just the event, some relevant event data right?
<Chipzz> s/word/work
<jdub> ademan_: look into the dbus messages that n-m sends
<ademan_> is there some program that monitors dbus communication?  Or is there a doc on the network manager?
<Chipzz> it should be configurable at least
<ademan_> well from the looks of it, since everything is through dbus, it would really depend on the applications themselves to catch these messages
<ademan_> well i suppose that would be required either way
<ademan_> on a sidenote the network manager website doesn't really provide any useful information as far as what the actual dbus communications are, no real documentation, i guess i'll grab the source if i want to pursue it further
<dholbach> good morning
<ademan_> morning, or rather nite, its nighttime here :-p
<dholbach> hi ademan_ :)
<ademan_> :-)
<ademan_> anyone familiar with scons?  This is the third time i've been trying to learn autotools, it's not that i don't get it, it just seems like a massive pain in the rear for something that could be very simple.  I suppose it may be more flexible than other build systems, but it seems excessively verbose, and well, archaic
<dholbach> I didn't work much with scons yet, no.
<tsmithe> ademan_, you have autotools too!
<tsmithe> *hate
<Chipzz> my personnal opinion is that I don't want to push a python dependency on users just to build my software
<Chipzz> that, and I'm pretty sure that systems like scons have their disadvantages too
<Chipzz> also, the issue of correctly building software is inherently a complex thing to get right
<Chipzz> stuff like making sure "make dist" etc work right are often overlooked
<dholbach> hey seb128!
<Chipzz> </offtopic>
<seb128> hi dholbach
<seb128> dholbach: have a nice trip?
<seb128> had
<dholbach> hm hm hm :)
<dholbach> it was ok
<tsmithe> poor Chipzz - no one listened to his issues
<jdub> ha ha sys.subversion in python2.4
<jdub> er
<jdub> python2.5
<ademan_> Chipzz: well honestly how many systems DON'T have python?  Doesn't it come with every ubuntu release?
<Chipzz> ademan_: I'm not talkin about ubuntu here
<Chipzz> ademan_: well honestly how many distributions are there out there that are NOT ubuntu?
<Chipzz> more to the point
<Chipzz> if the software I'm writing is not desktop-software at all, but some server thing
<Chipzz> the user may definately not have python installed
<Chipzz> and I can very well feel for people who want to keep their installs uncluttered and small
<Chipzz> so no, I would not think making python a build dependency would be an acceptable thing to do
<Chipzz> python IS pretty heavy-weight, mind you
<Chipzz> both on diskspace and cpu
<Chipzz> (relatively heavy-weight for cpu)
<Chipzz> (this is aside from what I think about python; I think python is a very nice and cool programming language; but this is about pushing personnal preferences to users)
<Chipzz> let me give you another example: msttcorefonts used to have a script written in ruby to download and extract the fonts
<Chipzz> so I had to install ruby just because the maintainer liked ruby, and happened to write his script in that language
<\sh> moins
<tsmithe> howdy
<Chipzz> and again, </offtopic>
<ademan_> true about the server part, but so many things for desktop linux require python anyways, and even more importantly, with ubuntu you're likely not building on your system anyways
<ademan_> ok now </offtopic>  :-)
<pitti> hi Hobbsee 
<pitti> moin Keybuk 
<dholbach> heya pitti
* pitti hugs dholbach 
<Hobbsee> hey pitti!
* dholbach hugs pitti back
* Hobbsee group hugs pitti and dholbach 
<pitti> Hobbsee: *ruffle*
* dholbach hugs Hobbsee back
<Keybuk> morning
<Hobbsee> pitti: why am i being ruffled?
<pitti> Hobbsee: you don't like it? /me won't any more
<Hobbsee> pitti: i dont mind it, i just thought it was an odd response :)
<pitti> Hobbsee: hm, maybe I got the translation wrong
<Hobbsee> pitti: i think it was right.  it's not a good thing to mess up a woman's hair or something, ie ruffling, right?
<pitti> Hobbsee: oh, hmm, then it was wrong; I mean the 'stroking/massaging head/neck'
<Hobbsee> ahh
<Hobbsee> similar :)
* Hobbsee gets called to do the dishes
<Chipzz> hrrrrm
<Hobbsee> whee!
<mneptok> Hobbsee: we can gang-ruffle pitti when he returns ...
<Hobbsee> mneptok: yay :)
<mneptok> the simple pleasures.
<Hobbsee> mneptok: you realise that the server is split in at least 3 ways?
<mneptok> Hobbsee: oh yes. and when things re-link, pitti's in for a ruffling.
<Hobbsee> hehe
<Fujitsu> 3 ways? That's rather impressive.
<Hobbsee> Fujitsu: well, i'm connected to 2, and we're still missing people, so....
<Hobbsee> yeah!
<somerville32> This is crazy :/
<Fujitsu> somerville32, it can get that way...
<Hobbsee> Fujitsu: find out how to get a mailing list, please :)
<somerville32> Hobbsee, like a lists.ubuntu.com ml?
<Fujitsu> Hobbsee, why? (I think you ask jdub or similar)
<jdub> not for a long time :)
<jdub> mailman@lists.ubuntu.com
<somerville32> I thought you mailed rt
<Fujitsu> jdub, you're still listed as the admin for them (ubuntu-au, for example, elkbuntu has tried to get adminship of it, I believe).
<jdub> that's just for that list, i don't create lists
<Fujitsu> Ah, OK.
<mneptok> list creation is done by sysadmins
<Hobbsee> somerville32: yes
<Hobbsee> jdub: right
<somerville32> Hobbsee, e-mail rt :)
<mneptok> rt@admin.canonical.com
<Hobbsee> Fujitsu: -universe-sponsors - somewhere to send that massive block of mail
<mneptok> your request will be cheerfully ignored until 2007.
<Fujitsu> Hobbsee, that'd be good.
<Hobbsee> yeah, fair enough
<Fujitsu> Nice netjoin.
<somerville32> Omgz
* somerville32 dies.
* mneptok ruffles pitti mercilessly
<pitti> mneptok: *hug*
<somerville32> We're all reunited at last! :)
* Hobbsee joins mneptok in the ruffling
<Hobbsee> yay, i can close my client now
<mneptok> holy crap. i just listened to my outgoing voicemail recording and i sound ... i sound ... *professional*!
<Hobbsee__> haha
<Fujitsu> mneptok, that's not plausible.
<Mithrandir> mneptok: you're supposed to say stuff like that on #canonical, not here. :-P
<mneptok> Mithrandir: no way. if sabdfl finds out i can act professionally he might start requiring me to do so.
<bhale> hi all
<Mithrandir> true
<Hobbsee__> haha
<Hobbsee__> professional is overrated
<Hobbsee__> hey bhale 
<mneptok> and a good, satisfying p00p is underrated.
<somerville32> Yeah! Another netmerge! :D
<mneptok> and with that, my professionalism vanishes into the ether.
<gnomefreak> somerville32: looks like the one just ended
<somerville32> If only we could merge packages this fast
<giskard> hello *
<\sh> to all developers, merry x-mas or whatever you celebrate and a happy new year ... will see you in 2007 :)
<pitti> argh, today's dist-upgrade rendered my system totally unbootable (IDE disk hda has trouble with IRQ, but no kernel update took place today); BenC, anyone else, did you already hear about this?
<Hobbsee> pitti: that the same as yesterday's?
<pitti> Hobbsee: yesterday's?
<pitti> dpkg.log shows that udev was upgraded today, I can't see anything else boot-related
<Hobbsee> well, yesterday broke a lot of things, it seemed
<Hobbsee> ah
<pitti> I didn't dist-upgrade yesterday
<Treenaks> *note* don't reboot
<seb128> pitti: mine was break on fsck because fstab mentionned an unknow UUID for a partition
<Lathiat> hrm my machine still works as of 5 minutes ago
<pitti> seb128: unfortuntaly I don't have the 0ubuntu4 udev around any more, so I cannot downgrade that
<pitti> but booting with 2.6.17 works
<seb128> ah
<seb128> I'm still using 2.6.17
<seb128> 2.6.20 sucks
<seb128> using gdb crash it
<pitti> 2.6.20 booted fine for me this morning, and it wasn't updated today
<seb128> and my network card breaks every now and then while using it
<Treenaks> seb128: you didn't know? gdb is EVAL!~
<seb128> Treenaks: "EVAL"?
<Treenaks> seb128: sorry.. that's perl rubbing off on my brain
* pitti replaces the uuid= crack with proper device names and tries to boot again
* _ion hasn't fortunately rebooted for a while. :-)
* hunger has 2.6.20 stop during boot for a couple of minutes.
<hunger> I guess it is doing something foolish in the initrd like checking for an nfs root or something... I don't get any output to help with the debug.
<pitti> hmm, no good
<alex-weej> hmm, has anybody here ever used D for anything substantial?
<alex-weej> fsck wrong channel
<alex-weej> question still applies :P
<pitti> 'D'?
<pitti> I need the letter for quite a few words...
<Lathiat> it comes after C
<alex-weej> lol
<Lathiat> http://www.digitalmars.com/d/
<zul> but before E
<Lathiat> http://en.wikipedia.org/wiki/D_programming_language
<pitti> oh, yet another semitone higher than C#?
* Lathiat laughs
<Lathiat> i prefer Cb
<alex-weej> haha
<Lathiat> (C-flat for anyone musically inept)
<_ion> b, huh?
<_ion> C
<Chipzz> BenC: ping?
<Chipzz> initramfs-tools (0.85dubuntu1) feisty; urgency=low
<Chipzz>     - manual_add_firmware: Need to keep this until kernel supports exporting
<Chipzz>       firmware requirements from modules.
<Chipzz> would this solve my problem?
<Chipzz> (ipw2200 getting loaded to early with absent firmware)
<pitti> BenC: for the records, I filed bug 76872 about my boot failure with the details I could get
<Ubugtu> Malone bug 76872 in linux-source-2.6.20 "boot fails: does not detect hda any more (port conflict?)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76872
<bddebian> Heya
* Lathiat discovers gnome-power-statistics
<Lathiat> i've been looking for something to do this nicely forever
<Mithrandir> it's very shiny.
<Lathiat> the 'related events' are a nice touch
<BenC> Chipzz: pong
<BenC> pitti: Ok
<BenC> pitti: I bet it's initramfs-tools
<BenC> pitti: Can you try something for me?
<pitti> BenC: I'm glad to try something
<BenC> pitti: Edit: /usr/share/initramfs-tools/scripts/local-top/udev_helper
<BenC> comment out the modprobe for ide-generic at the end, and run "sudo update-initramfs -u"
<pitti> doing now
<pitti> BenC: I reboot with that, brb
<zul> happy holidays everyone
<pitti> BenC: bingo, that was it
<BenC> pitti: Ok, thanks
<pitti> BenC: I updated the bug accordingly
* pitti hugs the kernel master
<sbalneav> Best of the Season to all!
<pitti> sbalneav: and to you!
<fabbione> morning
<Adri2000> cjwatson: ping: https://launchpad.net/distros/ubuntu/feisty/+queue?queue_state=0&queue_text=libdjconsole please, thanks in advance :)
<mjg59> Adri2000: The queue may not be processed until after the holidays
<Adri2000> :-/ I need it to update another package, and holidays is when I have more time to work on packages for ubuntu...
<azeem> Adri2000: maybe you can setup a local repo and then queue up all the changes
<geser> where should be bug reports filed about outdated Contents files on archive.ubuntu.com?
<mjg59> Adri2000: Developers go on vacation too...
<mjg59> Sorry, s/Developers/Archive admins/
<Adri2000> I know, but I asked cjwatson yesterday and he told me he will do it
<Adri2000> that's only binary packages, so it should be quick
<parada-24> Hello
<cjwatson> Adri2000: done
* jdong just discovered the magic of ionice(1)
<jdong> how come I never got the memo that it was in Edgy? :D
<keescook> jdong: ah! I had never gone to figure out how to tweak that stuff. cool.  I've totally got to ionice my builds.  :)
<jdong> keescook: it's just a miracle :)
<jdong> it's just terrible when one of my backup scripts wakes up and executes a find / ..... command
<jdong> and I'm watching a movie late at night
<keescook> *frame drop*
<jdong> ordinary nice is absolutely no good at preventing IO wars :D
<jdong> yeah
<jdong> especially with my slow laptop HD
<keescook> sudo ionice -c1 ls   # give me a file list NOW    :P
<jdong> :)
<fabbione> cjwatson: are you around by any chance?
<cjwatson> fabbione: yeah, for a bit
<fabbione> cjwatson: i saw that debian did release os-problem 1.15
<fabbione> cjwatson: (sec ddaa is joining us)
<fabbione> ddaa: <fabbione> cjwatson: i saw that debian did release os-problem 1.15
<cjwatson> os-prober
<fabbione> ddaa: we maintain os-prober in bzr lp foobar :)
<fabbione> bzr pull sftp://bazaar.launchpad.net/~vcs-imports/os-prober/main/
<fabbione> bzr: ERROR: Not a branch: sftp://bazaar.launchpad.net/~vcs-imports/os-prober/main/
<fabbione> but if i do it via http is ok!?!?
<fabbione> and i can see that our devel branch is:
<fabbione>    bound to branch: sftp://bazaar.launchpad.net/~ubuntu-core-dev/os-prober/ubuntu/
<cjwatson> you need to use http, yes; you aren't in the vcs-imports team
<cjwatson> and therefore you can't see /~vcs-imports over sftp
<cjwatson> this is normal
<fabbione> feh.. ok
<fabbione> ddaa: i guess that explain everything
<fabbione> ddaa: thanks anyway tho
<ddaa> glad to be of service
<fabbione> cjwatson: ok.. now i merged via http... anything against me uploading 1.15ubuntu1 ?
<cjwatson> fabbione: it doesn't seem to urgently need a merge
<ddaa> btw, I just checked the os-prober import, and it's all green
* ddaa goes back helping the schooltool folks migrate to bzr
<fabbione> cjwatson: no, there is only one cleanup commit in svn.. nothing fancy..
<cjwatson> fabbione: but I don't object; can you commit the merge first (as UNRELEASED) and I'll eyeball it?
<fabbione> cjwatson: yes of course...
<fabbione> i just need a couple of more minutes to merge debian/changelog
<seb128> cjwatson: could you reject the nautilus-share upload I just did if that's easy (the package is a NEW one), I would like to do a changelog change and upload again
<cjwatson> seb128: done
<seb128> cjwatson: thank you
<keescook> hm, anyone else see gnome-gpg run away after being used?
<fabbione> cjwatson: Committed revision 159.                                                            
<cjwatson> fabbione: looks fine
<cjwatson> fabbione: I do suggest renaming your checkout directory :-) branch nick: os-prober-1.14ubuntu2
<fabbione> cjwatson: ok thanks
<fabbione> i did
<cjwatson> I usually just drop the version
<fabbione> os-prober-1.15ubuntu1
<cjwatson> oh, 'bzr nick ubuntu' or something then
<fabbione> oh ok
<fabbione> sec
<cjwatson> it must have remembered the old name
<cjwatson> (not important, though)
<fabbione> fixing it
<cjwatson> fabbione: I talked with spiv about the sftp/vcs-imports thing over dinner one day at allhands, BTW; it's sort of a design limitation in the supermirror at present, but theoretically fixable in future
<cjwatson> I forget the details now, though
<fabbione> cjwatson: that's fine.. i just didn't know :)
<cjwatson> you can see how it works if you do 'sftp bazaar.launchpad.net' and 'ls'
<fabbione> cjwatson:        branch root: /usr/src/ubuntu/mypkgs/nc/os-prober-1.15ubuntu1/
<fabbione>  <- this is $pwd :)
<fabbione> i did a mv dir and it did change
<fabbione> the branch is the same as your
<fabbione>    bound to branch: sftp://bazaar.launchpad.net/~ubuntu-core-dev/os-prober/ubuntu/
<fabbione> this is the bit we really care
<cjwatson> sure, the nick is just for bzr log neatness
<cjwatson> fabbione: anyway, sure, go ahead and release that
<fabbione> cjwatson: thanks.. 
<cjwatson> ('debcommit --release' recommended to note the revision of the release, as bzr doesn't have tags yet)
<fabbione> cjwatson: yeps.. i did that..
<Popoi> 8-) hi... good luck developers!!
<EvanCarroll> If I was to package up Abandonware, could I get its inclusion into the dapper-commercial repository?
<tsmithe> only if you had permission... or is it really abandoned?
<EvanCarroll> tsmithe: abandonia.com
<EvanCarroll> I just think it would be a really good idea to bundle them all up, abandon-obitus, etc, and then a big meta-package, abandon-games
<tsmithe> well, they wouldn't need to be in -commercial
<tsmithe> only multiverse
<EvanCarroll> think of all of the possiblities: Ubuntu-MAME. and such.
<EvanCarroll> tsmithe: I thought multiverse required source
<tsmithe> no - that's universe
<tsmithe> multiverse is non-free
<EvanCarroll> ok, well then that would work.
<tsmithe> as is restricted
<EvanCarroll> is it a go if i complete it?
<tsmithe> i guess
<tsmithe> ask in #ubuntu-motu to be sure
<lifeless> morning
<_ion> night
<seb128> happy holidays everybody, see you
<fabbione> seb128: have fun mate
<seb128> fabbione: thanks, you too ;) 
<cjwatson> EvanCarroll: I hate to be a naysayer, but as an archive admin I don't think I would accept that
<cjwatson> EvanCarroll: one alternate suggestion would be to create an installer package that makes it really easy to fetch games from there
#ubuntu-devel 2006-12-23
<T`> hi.. anoyne knows where i can find documntation on how the acpi_fakekey / dev/input/event0  works?
<T`> i'm trying to tweak the rate at which the volume changes when i press the up/down bottoms on my laptop, but so far i have found /dev/input/event0 is being used by haldaemon and not sure how the actual vol set process works
<mdke> T`: which desktop?
<T`> xfce
<mdke> ah, no idea
<T`> is that what you meant to ask?
<T`> mdke, but how does it work usually?
<T`> im assuming the buttons cause an acpi event which is hooked thru event.d/ and somehow runs the volupbtm.sh in /etc/acpi
<T`> then it sends a acpi_fakekey with the appropriate keycode.. 
<T`> what happens next?
<mdke> I know that in gnome it's controlled by a gnome-wide application, that's about it. and I know that sladen knows a fair bit about it
<T`> whats the app called in gnome?
<T`> sladen, ping?
<mjg59> In gnome, it's handled by gnome-settings-daemon
<T`> hmm ok.. so it must be listening to the /dev/input/event0
<T`> do you guys see anything for lsof  | grep event0 which says it does?
<mjg59> No
<mjg59> It gets the event fro X
<mjg59> All keyboard events also get sent to /dev/console, which the X server picks up
<T`> aha
<T`> so xfce must be handling these events
<mjg59> Yup
<iwkse> hi all. Where i should look for when i want to suppress application window's border?
<okaratas> today is my birthday...
<okaratas> is Ubuntu supporting VLAN;is there any documentation for that; is there anything to do in kernel for this?
<mjr> vlans are supported by default kernels, the vlan package contains userspace tools for their use
<cjwatson> iwkse: start with http://developer.gnome.org/doc/API/2.0/gtk/GtkWindow.html#gtk-window-set-decorated perhaps
<iwkse> cjwatson: thanks
<okaratas> mjr, thanks, i see link
<iwkse> Anybody has this book Gtk+ Programming in C written by Syd Logan?
<pygi> hello everyone
<pygi> merry christmas to everyone
<Hobbsee> hey pygi!
<pygi> I wish you all the best 
<pygi> hello Hobbsee 
<jita> my system freezes upon reboot/shutdown. if i disable dri in xorg.conf, then it works fine
<jita> its similar to https://bugs.launchpad.net/distros/ubuntu/+source/xserver-xorg-video-ati/+bug/67487
<Ubugtu> Malone bug 67487 in xserver-xorg-driver-ati "[regression] [rv280]  black screen and console freeze when X starts - drm lockup" [Unknown,Confirmed]  
<jita> but it happens at reboot time
<jita> not start up
<zyga> hey guys
<zyga> has anyone seen mvo latelty?
<fdoving> zyga: vacation, i've heard.
<zyga> fdoving: ooh, good for him then :-)
<zyga> is it past the 7.04 freeze yet?
<MagnusR> zyga: According to https://wiki.ubuntu.com/FeistyReleaseSchedule?highlight=%28feisty%29 we have past debianimportfreeze but not featurefreeze.
<MagnusR> http://video.google.com/videoplay?docid=5159636580663884360&q=google+engEDU+python&hl=en Klart intressant fredrag.
<zyga> MagnusR: is it still possible to sync stuff for ubuntu from upstream (trivial minor changes)
<zyga> I'm talking abount command-not-found explicitly
<MagnusR> zyga: I am not totally sure but I think so.
<jdong> pitti: ping (you're the one who wrote the GNOME umount progress dialog back in the good ol' days, right?)
<jdong> we're missing a dialog for umounting from the left-hand nautilus pane... it just silently unmounts for that case
<jdong> ok, I'll file a bug instead... gnome-vfs I assume?
<pitti> jdong: rather nautilus, I figure; please assign it to me right away, so that I'll notice
<coyctecm> anybody knows about those david turner freetype patchies..?  some patent issues?
<jdong> pitti: ok, I'll file it soon and subscribe you; thanks
<Amaranth> coyctecm: Yeah, microsoft cleartype patents
<coyctecm> Amaranth: that sad really :/ Those patches make really difference
<Amaranth> I used to think so
<coyctecm> actually, today I tryed those patches, but I only used them about few hours...
<coyctecm> they are nice looking and so on, but not for my eyes
<alex-weej> holy shit
<alex-weej> help.ubuntu.com describes /usr as stuff for "USeRs" :E
<alex-weej> https://help.ubuntu.com/6.10/ubuntu/desktopguide/C/directories-file-systems.html
<_ion> Haha.
<neutrinomass> There are a few universe packages that depend on  iceweasel | iceape-browser | icedove . Are these going to be synced to universe ?
<neutrinomass> And regardless of that, to avoid having users install 2 firefoxes, should a "| firefox" be added ?
<zyga> is there any movement to package the now-gpl'd java again?
<zyga> (so there is a difference between jdk/jre and the 100%-gpl java?
<neutrinomass> I opened the above issue as bug 77009
<Ubugtu> Malone bug 77009 in venkman "failed deps on iceweasel | iceape-browser | icedove" [Undecided,Unconfirmed]  http://launchpad.net/bugs/77009
<geser> neutrinomass: set bug #77007 to "Fix Released" once it hits the archive
<Ubugtu> Malone bug 77007 in tkdvi "Unmet deps [feisty] " [Medium,Fix committed]  http://launchpad.net/bugs/77007
<neutrinomass> geser: Cool thanks :-)
<siretart> tsmithe: advocated
<tsmithe> thanks siretart
<tsmithe> in feisty universe, the compiz packages are from fd.o right?
<smithj> is there a way to get commit mail for the sources for packages?
<cjwatson> not in a unified way
<cjwatson> diffs of uploads are mailed to packages.qa.debian.org, and I believe you can subscribe to them there
<cjwatson> individual projects may have commit lists
<smithj> does, for example, breezy-changes mail actual diffs or just that something was changed?
<cjwatson> uploads may be too coarse a granularity for you
<cjwatson> the former
<cjwatson> er
<cjwatson> the latter, sorry
<cjwatson> as you can see in the archives ...
<cjwatson> oh, hang on, Scott did actually set something up
<cjwatson> smithj: see the ubuntu-patches list
<cjwatson> you can't subscribe to an individual package as far as I know, but you can get the lot and procmail it. Sorry I'd forgotten about that earlier
<smithj> cjwatson: no, thats perfect :)
#ubuntu-devel 2006-12-24
<smithj> thanks
<cjwatson> in the case of a new upstream, it contains our diff against the corresponding base version in Debian rather than against the previous version in Ubuntu
<cjwatson> this tends to be more useful if you're just trying to monitor what Ubuntu developers are doing; if you actually want the true diff in Ubuntu every time, contact Scott James Remnant and see if you can work something out
<smithj> cjwatson: i'm mainly just monitoring
<smithj> trying to keep abreast of what the major distros are doing, etc
<cjwatson> good luck keeping up, then :)
<cjwatson> hmm, interesting, it doesn't pick up on Ubuntu-native packages without *ubuntu* version numbers
* cjwatson mails Scott about that; that's kind of annoying for e.g. ubiquity
<Fujitsu> I also note that MoM does funny stuff, like mailing the PTS with `New upstream version' even if it isn't one.
<cjwatson> Fujitsu: it means upstream relative to Ubuntu, i.e. a new base version from Debian
<cjwatson> there are multiple levels of upstreamishness in the modern distro world ...
<Fujitsu> Ah.
<Fujitsu> OK.
<cjwatson> I agree the terminology is a bit confusing when mailing Debian lists, though. Do you want to mail Scott and suggest that it should be "New base version" or something?
<Fujitsu> That sounds better, as it is mailing Debian, and it's not upstream to them.
<Seveas> keescook, ping
<sladen> mdke: pong?
<sladen> mdke: could you ask the question you and T` were after, I didn't get the full highlight.
<mdke> sladen: I believe mjg59 handled it, it was something about Gnome volume control hotkeys
<mdke> sladen: sounded like he wanted to implement something similar for xfce
<sladen> mdke: gotcha, thanks
<keescook> Seveas: distant pong.  what's up?
<Seveas> keescook, about the USN RSS feed
<Seveas> it moved to http://media.ubuntu-nl.org/rss/usn.xml
<keescook> ah, very cool.  People keep asking about one, so I'm gonna send them that way until there is an "official" one.  :)  thanks!
<Seveas> keescook, might as well make that one official if you mirror is on *.ubuntu.com or let me upload there ;)
<Seveas> s/is/it/
<keescook> Seveas: yeah, it's a bit out of my hands, though.  :)
<Burgundavia> given the website is currently up for discussion right now, we should be able to do something liek that on the new one
<bhale> hi all
<keescook> Burgundavia: yawp
<keescook> hiya bhale
<grimeboy> Since icecast1 is deprecated to the extent that it doesn't receive bugfixes and is a bloated [self censorship]  should it not be removed from the repos?
<grimeboy> WOr should this go in #ubuntu-motu
<grimeboy> -W
<grimeboy> +?
<grimeboy> Assuming yes since it's in universe. Sorry.
<avis> merry christmas to all ubuntu developers :)   
* lamont wonders what happened to /etc/inittab in edgy...
<Burgundavia> lamont: in edgy or feisty?
<lamont> edgy.
<lamont> more to the point, how do I trigger /etc/event.d/ttyS1 :)
<pluto> Anyone around?
<Burgundavia> yep
<pluto> I got told to come here to see if anyone knew about how to fix a make clean error I'm getting
<pluto> I've removed and reinstalled the headers, but when I go to make clean, I get scripts/Makefile.clean:17: /usr/src/linux-headers-2.6.17-10-generic/drivers/infiniband/ulp/srp/Makefile: No such file or directory
<pluto> Any ideas?
<Burgundavia> nope
<tiglionabbit2> hello.  I would like to know what the process is to get a package added to the repositories?
<tsmithe> tiglionabbit2, look on the wiki
<tiglionabbit2> um, what part?
<tsmithe> hang on
<tsmithe> https://wiki.ubuntu.com/MOTU/Packages/New
<tiglionabbit2> what if our request is to update a very old packageL
<tiglionabbit2> the ruby interpreter, specifically
<Chipzz> tiglionabbit2: you file a sync request
<tiglionabbit2> and how do I do that?
<Chipzz> it's somewhere on the wiki
<Chipzz> but frankly, I can't believe ruby would be *that* much out-of-date? :)
<tiglionabbit2> it's two years old
<tiglionabbit2> well, 3 now
<_ion> It's the same version as in Debian.
<_ion>    ruby1.8 | 1.8.5-4ubuntu1 | http://fi.archive.ubuntu.com feisty/main Sources
<_ion>    ruby1.8 |    1.8.5-4 | http://ftp.fi.debian.org sid/main Sources
<_ion> In edgy, it's 1.8.4, which isn't very old either.
<tiglionabbit2> oh whoops, it's called ruby1.8
<tiglionabbit2> my bad
<Chipzz> tiglionabbit2: there's even ruby1.9
<Chipzz> but then, I'm running feisty; maybe bot on edgy
<_ion> 1.9 is the ever-changing development version towards 2.0, it's not intended to be used in production.
<tiglionabbit2> why does "ruby" point at the 1.8.2 version?
<Chipzz> I didn't say he had to; I was just pointing it out to prove that ruby is not out-of-date ;)
<_ion> It's just a metapackage. dpkg -L ruby, apt-cache depends ruby
<tiglionabbit2> oh, you're correct
<_ion> ...or just apt-cache show ruby :-)
<Chipzz> tiglionabbit2: for the record, "ruby" points at the "ruby1.8" package , not the 1.8.2 version ;)
<tiglionabbit2> weird that it would have the old version number then
<Chipzz> subtle difference
<_ion> Its version number doesn't really matter at all. It just happened to be created when the version of Ruby was 1.8.2
<tiglionabbit2> =]  thanks
<surfbuddy> is it cumpulsory to go through the gparted thing while installing ubuntu ???
<surfbuddy> looks like  a bug while trying to install ubuntu - ( installer hangs when i use the set time button )
<cjwatson> known
<cjwatson> gparted> that or autopartitioning, or the alternate install CD
<cjwatson> hope to get rid of gparted for advanced partitioning once I've finished writing the replacement
<surfbuddy> whner i press the set time button the installer hangs and i have to reboot or relog to continue
<cjwatson> yes, that's known I'm afraid
<cjwatson> don't do that :-)
<cjwatson> "Set time..." is just a nicety and it's been too much trouble so I'll probably just remove that button at some point
<cjwatson> you can always set the time using the usual desktop facilities after installation if necessary
<surfbuddy> cjwatson, yes .. no problem
<surfbuddy> cjwatson, another thing.... ( writing )
* cjwatson points idly to the topic
<surfbuddy> cjwatson, i already have an ext3 formatted parititon on /dev/sda1 
<surfbuddy> while going through the installer, ( which i forcibly have to ) , i create a ext3 on sda1 and swap on sda6
<surfbuddy> but it always throws an error that ext3 format failed !
<surfbuddy> can it be something related to the clock speed ( usb 1.1 or usb 2.0 )
<cjwatson> no
<cjwatson> file a bug at https://launchpad.net/distros/ubuntu/+source/ubiquity/+filebug and attach /var/log/syslog and /var/log/partman
<cjwatson> this channel is for developer coordination rather than support
<surfbuddy> would do it.
#ubuntu-devel 2007-12-17
 * Hobbsee waves
 * lamont notices that hardy/hppa is below 900 needs-build
<poningru> wehre can I ask questions about jeos?
<pitti> Good morning
<LaserJock> morning pitti
<StevenK> Morning pitti!
<StevenK> pitti: You can NBS out lib32icu36{,-dev}, sox-dev and liblinphone1{,-dev}
 * StevenK wonders how to debug a squashfs mount failure
 * Hobbsee waves
<TheMuso> pitti: Could you please give back synfigstudio on amd64? Thanks.
<pitti> TheMuso: done
<pitti> StevenK: ah, thanks
<Hobbsee> pitti: they want all of kde4 stuff given back too, i think
<TheMuso> pitti: Thanks.
<pitti> Hobbsee: no problem; please just give me a list, without comma, 'and', etc.
<StevenK> *-kde4
<StevenK> You said nothing about no globs
<Hobbsee> pitti: kdeaccessibility-kde4 kdeartwork-kde4 kdemultimedia-kde4 kdenetwork-kde4 kdepim-kde4 kdesdk-kde4 kdetoys-kde4 extragear-plasma
 * StevenK ducks
<Hobbsee> pitti: you've scripted multiple givebacks, have you?
<pitti> Hobbsee: yes
<StevenK> for i in <paste> ; do buildd.py give-back $i ; done  ?
<pitti> Hobbsee: hey, indeed: you can actually do that yourself
<Hobbsee> StevenK: wrong syntax, but yes
<pitti> Hobbsee: anyway, given-back
<pitti> StevenK: removed
<StevenK> pitti: Thanks
<pitti> StevenK: 'zactly
<Hobbsee> pitti: i could have, yes.  however, now i'm glad i didn't, as it had not occurred to me to script it.
<StevenK> Hobbsee: Meh, I don't need to use buildd.py :-)
<pitti> StevenK: wrapped in a two-line shell script
<Hobbsee> StevenK: :P
<warp10> Hi all!
<LaserJock> can somebody give back gchempaint?
<Hobbsee> LaserJock: done
<LaserJock> Hobbsee: thank you
<Hobbsee> LaserJock: er, it's already dep-waiting
<Hobbsee> but given back anyway
<LaserJock> how often are those tried?
<LaserJock> I thought they stopped retrying after a while
<Hobbsee> unsure.  but multiple times, over a long time interval
<Hobbsee> yeah, i think they do
<LaserJock> gchempait was in dep-wait for at least 3 weeks
<LaserJock> so I figured it'd given up
<StevenK> Hum? I thought I uploaded it less than 3 weeks ago?
<\sh> moins
<LaserJock> gchempaint was synced on 11-24
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<superm1> off hand does anyone know what signal is passed to apps on a logout?
<persia> Usually HangUP, no?
<superm1> that's what I thought, but i wasn't positive (with nothing sticking out in google off hand)
<superm1> hm well see the odd thing is that i wasn't seeing any calls in main.cpp for redirecting the call for a hang up, yet the app doesn't respond to a log out properly still
<dholbach> please take a look at   http://people.ubuntu.com/~dholbach/sponsoring/   and in case your name is on it, please review and upload if appropriate
 * lool has some sponsoring to do, but didn't get to it yet
<YokoZar> Is it a good or bad idea to pass commands to dh_builddeb to use compression other than gzip?
<persia> YokoZar: It's a good idea, but not widely supported, so you probably don't want to do it until all the tools catch up.
<YokoZar> persia: have they caught up in Gutsy?  Like, if my package is for Gutsy, can I switch to lzma there?
<YokoZar> It would save something like 30% of the bandwidth for my third party repo at this point
 * persia isn't sure, but thinks lzma will only be default for hardy
<pitti> YokoZar: you can use bzip2 in all supported Ubuntu releases
<pitti> YokoZar: lzma is hardy only
<YokoZar> ok cool
<pitti> YokoZar: if your package has lots of text, bz2 usually performs very well
<YokoZar> pitti: Will it work all the way back with dapper?  I still get downloads for that.
<pitti> YokoZar: yes, as I said above
<YokoZar> Oh, right.  Dapper is still supported ;)
<pitti> it was introduced in hoary or breezy at the latest
<YokoZar> What about etch?
<YokoZar> For that matter, do you know if lenny will support lzma like Hardy?
<pitti> I don't, sorry
<YokoZar> I'm wondering if we should do an audit of package build scripts and change as many as we can to bz2 (or lzma) for Hardy
<minghua> I remember a mail about this on d-d-a list...
<pitti> YokoZar: if that involves more than 20 packages, I'd rather do that change centrally
<lool> pitti++
<YokoZar> pitti: you mean change the default of dpkg-dev ?
<YokoZar> err dpkg-deb
<pitti> something like that, yes
<YokoZar> That's actually a good idea
<pitti> but let's test it for a while first
<pitti> lzma is said to be relatively moderate in terms of unpacking performance
<minghua> YokoZar: According to http://lists.debian.org/debian-devel-announce/2007/12/msg00007.html you can use bzip2 compression since dpkg 1.11.
<pitti> bz2 is quite heavy, so that might not be a reasonable default
<dholbach> hey seb128
<YokoZar> Well, maybe lzma for Hardy then
<seb128> hi dholbach
<YokoZar> I wonder if this would help us with our CD size issues...
<minghua> Etch has 1.13.25 by the way.
<pitti> YokoZar: yes, it would; that has been tested already, and it's impressive
 * pitti hugs seb128, bonjour
 * seb128 hugs pitti
<seb128> guten morgen ;-)
<YokoZar> I'm gonna test if Gutsy can handle an lzma package now
<YokoZar> I just might save myself some serious bandwidth
<pitti> YokoZar: no, it can't
<pitti> well, it can be made to, but not OOTB
<YokoZar> pitti: hmm...dpkg-deb can do it though, heh
<YokoZar> pitti: maybe I'll use bzip2 then
<pitti> YokoZar: but gutsy's dpkg doesn't ensure that lzma is installed, and gutsy's lzma is universe
<YokoZar> ahhh I see
<pitti> YokoZar: bz2 is a safe bet, yes
<YokoZar> It'd be a weird pre-depends thing I see
<Lure> pitti: no need for bug 172755 if archive-admin-of-the-day does bug 176620
<ubotu> Launchpad bug 172755 in kipi-plugins "Rebuild for libgpod2 -> libgpod3 transition" [Undecided,Confirmed] https://launchpad.net/bugs/172755
<ubotu> Launchpad bug 176620 in kipi-plugins "sync kipi-plugins 0.1.5~beta1-3 from debian/experimental" [Undecided,Confirmed] https://launchpad.net/bugs/176620
<Lure> pitti: ^^^ from sponsoring list (btw)
<pitti> StevenK: doing mass-removal of NBS now (shell hack to verify that they are indeed NBS and not just FTBFS)
<StevenK> Hurrah!
<StevenK> How are you verifying they aren't FTBFS?
<pitti> for p in `cat /tmp/x`; do apt-cache showsrc `grep-dctrl -n -sSource:Package -P $p /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hardy_main_binary-amd64_Packages` | grep -q "^Binary:.*$p" || echo $p; done
<StevenK> Ew :-)
<pitti> /tmp/x has the empty files from people.u.c.
<TheMuso> dholbach: Thanks heaps for the uploads.
<pitti> StevenK: I'll head to the supermarket for a bit, then I'll fix the NBS cron job to display FTBFS packages in ftbfs/ or not at all
<dholbach> TheMuso: anytime
<geser> morning
<StevenK> pitti: Under ftbfs/ would be good, so the information is still there, just seperated out
<seb128> StevenK: hi
<seb128> StevenK: any news about the gimp update to gutsy?
<StevenK> seb128: I've started poking at it
<StevenK> seb128: I can keep doing so now instead of playing WoW if you want
 * tjaalton is still puzzled why xorg-server failed to build on most archs
<seb128> StevenK: not sure what time it is at your place, but if that's after work hours you should better enjoy your evening and look at it tomorrow ;-)
<StevenK> seb128: It's 8:30pm. Keep in mind I work on Ubuntu for fun as well. I'll look at it sometime tonight
<seb128> StevenK: right, there is no hurry so whenever you want ;-)
<tjaalton> the xorg-server build fails on 'hw/xfree86/os-support/linux/lnx_apm.c:43: error: expected specifier-qualifier-list before 'apm_event_t''
<tjaalton> no patch touches that file, and it built fine on debian
<tjaalton> so either there were changes in toolchain or some headers that causes this?
<pitti> tjaalton: was it built with gcc 4.1 in Debian maybe?
<tjaalton> pitti: probably, but I think I found the cure
<tjaalton> from fedora..
<tjaalton> xserver-1.4.99-apm-typedefs.patch: Temporary hack for broken kernels that don't publish the /dev/apm_bios types.
<StevenK> seb128: It looks like I have source. Do you want to look over it?
<StevenK> seb128: Due to 2.4.0~rc3 -> 2.4.2, a debdiff is useless
<seb128> StevenK: sure, where is it?
<StevenK> Here, at the moment.
<pitti> StevenK: http://people.ubuntu.com/~ubuntu-archive/NBS/
<pitti> :)
<pitti> hm, that doesn't look quite right
<pitti> ah
<persia> pitti: What lives in 00FTBFS?  Is that just out-of-date packages?
<pitti> yes
<pitti> persia: however, the current output is exactly the wrong way around
<pitti> I fixed the script, rebuilding
<pitti> persia, StevenK: ok, fixed
<pitti> tjaalton: any chance you could test the dapper-proposed kernel for bug 72696?
<ubotu> Launchpad bug 72696 in linux-source-2.6.15 "tg3: doesn't recognize the network device on Fujitsu Esprimo E5915" [Medium,Fix committed] https://launchpad.net/bugs/72696
<pitti> tjaalton: or boot the current dapper.2 candidate CD and check it out in the d-i environment?
<tjaalton> pitti: hmm, I could do that yes
<pitti> tjaalton: that would be great, thanks
<tjaalton> pitti: the image appears not to be on cdimage.u.c?
<pitti> http://cdimage.ubuntu.com/ubuntu-server/dapper/daily/20071207.2/
<pitti> tjaalton: ^ it's server only
<tjaalton> ah, right.. thanks
<Riddell> cjwatson: am I ok to make kde 4 seeds?
<tjaalton> pitti: debian has dropped xresprobe from the latest xorg upload. Do you think it would be ok to merge that for alpha2?
<Riddell> mvo: have you seen the libept failure?
<Riddell> mvo: and python-apt doesn't want to install?
<mvo> Riddell: yes, I noticed the libept failure, I have no idea why it fails, it builds fine in my pbuilder and on my regular system
<mvo> Riddell: something about that it can't find tests
<Riddell> enrico: might you be able to take a quick look? https://edge.launchpad.net/ubuntu/+source/libept/0.5.11ubuntu1/+build/473150
<mvo> Riddell: what is it about python-apt? 0.7.4ubuntu1 should be ok, no?
<Riddell> mvo: mm, it does seem to be ok after sorting out my chroot
<pitti> tjaalton: sure, if it doesn't use this any more; the sooner we get testing for the new-world hw detection, the better
<tjaalton> pitti: my thoughts exactly
<mvo> Riddell: aha, good! thanks .)
<mvo> Riddell: does libpythonize0 really needs python-all-dev as a dependency? it seems to confuse dapper->hardy upgrades
<mvo> Riddell: I'm looking at kubuntu upgradability currently
<Riddell> mvo: python2.5-dev would probably be fine
<mvo> Riddell: ok, if you don't mind I change it and upload?
<Riddell> mvo: go ahead
<pitti> tkamppeter: AFAICS we can sync python-cups, right? our delta is just upstream version update
<cjwatson> Riddell: please don't, I'd rather reorganise the seeds first
<Riddell> cjwatson: ok, any timeline for that?
<pitti> slomo: can we sync mono-tools now? we have gnome-sharp2 2.16.0-6 and xulrunner (-1.9, though, not sure whether that matters)
<tkamppeter> pitti, I think so, I did not introduce anything new into python-cups. I got also an offer from Otavia Salvador during the weekend to maintain system-config-printer on a common GIT repo on Alioth.
<pitti> tkamppeter: right, thanks
<tkamppeter> pitti, how does syncing exactly work? Can I still quickly do my own package if needed? And is every Debian upload also uploaded to Ubuntu without additional human interaction?
<cjwatson> Riddell: not sure, hope to look at it RSN though. Sorry I can't give you a better estimate
<Riddell> cjwatson: fair enough
<pitti> tkamppeter: yes, we can always reintroduce an Ubuntu delta with just a normal upload
<pitti> tkamppeter: Debian uploads were auto-imported util DebianImportFreeze last Thursday; now we need explicit sync requests to update to debian's versions
<novas0x2a> is it possible to form a pin-definition that can differentiate between a ppa and main, when the ppa publishes a Release file that matches main's? can i override it somehow?
<tkamppeter> pitti, do you know whether doko is alkready on his christmas vacation? OOo needs to be rebuilt as it is dependin
<tkamppeter> g on an old library.
<pitti> tkamppeter: that's calc's domain now
<tkamppeter> So doko has stopped mainyaining OOo and calc did not pick up yet?
<pitti> calc did
<pitti> good morning pedro
<tkamppeter> "apt-get dist-upgrade" wants to delete OOo for more than a week now and this seems to be due to a library which switched to a new ABI version and so OOo needs to have a simple rebuild. This would be needed before Thursday for the Alpha 2.
<pitti> right
<pedro_> morning pitti
<tkamppeter> calc, hi
<pitti> tkamppeter: FYI, calc is in the US, so he'll be asleep ATM
<soren> . o O { Slacker }
<soren> :)
<pitti> says the man with only 179 pushups :-P
<soren> Gah..
<soren> Wel, the wiki is *slightly* out-of-date, though.
<soren> I've got a master plan to still make it.
 * pitti is afraid seeing '2500' the next time he reloads
 * pitti hugs soren, good luck!
<soren> :)
 * pitti recommends workrave
<soren> The main problem is the size of my office. I need to move stuff around every time I want to do a push-up.
<Mithrandir> soren: go into the living room or the hall or something?
<soren> Mithrandir: That's even worse. My office is in the basement, my living room is on the third floor.
<Mithrandir> it's called "warming up"
<pitti> soren: call it 'warm-up exercise'
<soren> Mithrandir: If the challenge was a million flights of stairs climbed, I'd be well on my way.
 * pitti ^5s Mithrandir
<Mithrandir> ideally, you should go there on your hands rather than your legs, though
 * pitti wants a video of that
 * Mithrandir ^5s pitti too
<pitti> then flip the movie upside down and call it soren_carries_his_house.avi
<soren> LOL!
<Mithrandir> pitti: .ogg!
<pitti> erm, sorry, of course :)
<soren> There. I've moved some stuff out into the stairway. I suppose I'll burn a bit of energy when I need to shout back at my annoyed and annoying neighbours when they spot it.
<tkamppeter> pitti thanks, I saw his name in the list of participants on the right, but perhaps he has still left open his client from yesterday.
<pitti> tkamppeter: yeah, he usually stays in IRC 24/7
<Mithrandir> tkamppeter: you'd have seen him being idle for 14 hours if you checked though.
<Mithrandir> (14 hours?  Such a slacker)
 * pitti introduces Mithrandir to the concept of an advent Sunday
<soren> Bah.
<Mithrandir> pitti: when I grew up, we had double Mondays instead of Sundays.
<slomo> pitti: i doubt it works with xulrunner 1.9 (but that's a gecko-sharp2 bug then), feel free to sync it though
<pitti> slomo: well, I don't want to deliberately break it
<slomo> pitti: you have to ask asac if he's finished with fixing everything to work with new xulrunner ;) in theory no ubuntu specific changes are necessary anymore
<StevenK> I wonder if I can convince compiz to not shade a window gray any more
<tkamppeter> Mithrandir, pitti, thanks, I have looked now and I get "last message: unknown", as my client was not running during the night.
<mvo> could someone please giveback nip2 (amd64 at least) and k3d ?
<Mithrandir> mvo: given-back
<mvo> thanks Mithrandir
<mvo> Riddell: It seems like koffice2 needs a rebuild for the libopenexpr2 transition, is this correct?
<Riddell> mvo: shouldn't do
<Riddell> mvo: 1.9.95.1-0ubuntu4 already depends on libopenexr2ldbl
<mvo> Riddell: aha, right. I'm outdated, sorry
<pitti> mvo: http://people.ubuntu.com/~ubuntu-archive/NBS/libopenexr2c2a was updated recently
<mvo> pitti: thanks, k3d and nip2 should be good soon
<Riddell> k3d has been needs build for a week
<mvo> but aqsis is FTBFS
<Riddell> universe is quite a struggle sometimes
<pitti> mvo: if there are only uninteresting and broken reverse dependencies left, I have no problem with removing it anyway
<lamont> mvo: you saw i followed up on the update-manager/ports thing, yes?
<mvo> lamont: no, let me check
<pitti> BenC: seems the latest linux upload still doesn't have the headers-rt which is needed for lum (just FYI in case you wonder what stalls it)
<lamont> (and btw, your instructions in the bug result in a 755/root:root /tmp, which made life slightly more interesting for a bit.  it could use a mkdir/cd in there.. :-)
<mvo> *cough*
<mvo> sorry lamont
<mvo> and thanks for the followup, I will correct that now
<BenC> pitti: the bug is that lum shouldn't depend on headers-rt...will get fixed shortly
<lamont> mvo: even when I fixed the prereq$mumble, it still failed
<pitti> BenC: ah, or that way around :)
<lamont> claimed to not be able to find that udeb
<pitti> BenC: so we'll stop offering -rt images?
<BenC> pitti: just until the realtime folks get us a new patch
<lamont> mvo: I'm where I can test for the next 4-5 hours, I htink
<mvo> lamont: ok, nice
<mvo> lamont: I uploaded a new 0.81.2 to http://people.ubuntu.com/~mvo/dist-upgrader/gutsy-0.81.2.tar.gz that should fix the issue, please give it a go :)
<lamont> Reading package lists: Donesty-backports/main/debian-installer Packages: 98
<lamont> donesty?
<lamont> Updating repository information
<lamont> No valid mirror found
<lamont> mvo: what's it looking for that the mirror is mssing?
<lamont> -backports/
<lamont> ?
<mvo> lamont: I assume your machne points to a internal mirror
<mvo> ?
<lamont> yes
<lamont> and a partial one at that
<lamont> hence the "what's missing?" quesiton
<mvo> lamont: nothing is missing, it just notices that it can not find a mirror it knows about and offers you to rewrite the sources.list. its intended behavior (but that maybe redone as it seems to confuse more than it helps)
<lamont> ah, ok
<lamont> quinn-diff Depends: libglib1.2?  WTF?
<lamont> oops.  that was the wrong window to kill.
<soren> Why does this page exist? https://edge.launchpad.net/ubuntu/+source/virt-manager/
<soren> I can't find virt-manager in the NEW queue or anywhere else..
<ScottK> soren: That will happen if it was uploaded and then rejected.  Dunno if that's the case here.
<soren> ScottK: I see..
<soren> pitti: ^^ ?
<pitti> no idea TBH
<soren> Oh, I have it in my ppa. That migt be it..
<pitti> soren: :)
<pitti> libvirt is in binary NEW on amd64, though
<soren> pitti: I was just wondering since it landed in Debian prior to DIF, so I'm curious why it wasn't autosynced.
<pitti> libvirt NEWed
<soren> pitti: Thanks for that.
<pitti> no idea; maybe it was a victim of the three-day mirror lag; anyway, synced now
 * soren hugs pitti
<soren> Thanks!
<pitti> you're welcome
<ScottK> soren: If it showed an empty Ubuntu page for the package because it was in your PPA, I think that'd be an LP bug worth reporting.
<soren> ScottK: I'm not entirely sure. I also don't know if that's the issue here :)
<ScottK> pitti: Would you be up for a bit of binary NEWing for backports?
<ScottK> soren: I'd say file the bug and let them sort it out then.
<ScottK> pitti: If so, https://edge.launchpad.net/ubuntu/dapper/+source/dkim-milter/2.4.0.dfsg-1ubuntu2~dapper1
<Mithrandir> mvo: why does apt-get consume 100% CPU when running here?  It seems like it's doing waitpid + select + read + write (both read and write are 0 byte ones).
<mvo> Mithrandir: gutsy? hardy? buildd environement or regular one?
<Mithrandir> mvo: hardy, in a freshly debootstrapped chroot.
<Mithrandir> multi-core machine, so it actually does consume 100% of one core.
<Mithrandir> it's being called from a python program, so reading from a pipe rather than a tty, iirc
<mvo> Mithrandir: could I get a strace please? you run something like "subprocess.call(["apt-get","install","foo"]) " in the python program I assume?
<Mithrandir> mvo: yes, something like that.
<Mithrandir> mvo: http://rafb.net/p/xQX8UT12.html
<mvo> Mithrandir: thanks, I'm checking the code now, I think I have a idea what is wrong
<Mithrandir> cheers. :-)
<mvo> Mithrandir: is that reproducable for you? or does it happens only every now and then?
<Mithrandir> mvo: it seems to happen every time I run apt-get from moblin-image-creator.
<mvo> ok, cool. that should make testing a possilbe fix easier :)
<Mithrandir> yup
<mgunes> what would be the correct procedure to have a new keyboard layout included? file a bug in xkeyboard-config and attach layout/debdiff?
<tkamppeter> Is Henrik Nilsen Omma here around on IRC?
<soren> tkamppeter: Usually, yes. He goes by "heno"
<mgunes> tkamppeter, his nick is heno
<tkamppeter> Thanks, he does not tell his nick on Launchpad.
<pitti> tjaalton: any luck with the dapper.2 CD and your broadcom eth?
<tjaalton> pitti: haven't tried it yet, but I'll burn it now and see how it goes
<pitti> tjaalton: thanks a lot, and sorry for nagging
<tjaalton> pitti: no problem :)
<pitti> BenC: eww - I just noticed that we don't have a linux-restricted-modules-2.6.15 yet for dapper-proposed?
<pitti> BenC: ah, ignore me; just a bug in my SRU script
<cVsup> hi
<cVsup> i would like to know how change usplash.conf in installation disc?
<mvo> Mithrandir: just to be sure, this is apt 0.7.9ubuntu1 (because its meant to be fixed there and I'm unable to reproduce it with the execCommand() from pdk_utils from moblin_creator)
<calc> tkamppeter: needs more than a simple rebuild due to a security issue as well
<calc> tkamppeter: and the new version of ooo has 18 mir's 8-\
<calc> i just tried rebuilding ooo again last night for an upload with current hardy and it failed at the end so i am looking into how to fix that now, it was working before that
<calc> tkamppeter: i am going to try to get it uploaded today but due to all the mir's it will be awhile before it gets rebuilt (i'm guessing)
<pitti> calc: 18!
<pitti> calc: that smells like it would double the required CD space again?
<calc> pitti: lots of small java libs
<pitti> calc: ok; please open MIR bugs for them, doko and I will have a look
<calc> pitti: i was hoping i could get lzma support done before uploading new ooo
<pitti> calc: we'll ask you to write MIRs for the nontrivial ones only
<doko> pitti: not now; currently skiing =)
<calc> pitti: i am in the process of writing the mir's still but as soon as i am done i will file the bugs, etc
<calc> pitti: oh ok
<pitti> doko: enjoy! but how the heck did you get Wifi on the ski lift??
<calc> pitti: they're all java libs except for libneon27
<calc> pitti: i'll start filing the bugs now
<doko> pitti: it's in some neighbor chalet ... week signal
<pitti> calc: libneon27? that's just a new upstream version
 * pitti wishes Debian would stop uploading duplicate libraries with SONAMEs in source packages
<calc> pitti: yea i may be able to revert it to libneon26 i'll have to see why it was changed for debian for that particular one
<pitti> calc: we can promote it, put it into HardyReducingDuplication, and rebuild the rest against 27 later, too
<calc> pitti: i mentioned libneon27 at UDS in that meeting iirc
<calc> since iirc we have 25/26/27 now
<cVsup> i would like to know how change usplash.conf in installation disc?
<pitti> hm, I only remember 25/26
<pitti> calc: 26 is just subversion and ooo
<pitti> calc: so feel free to switch to 27
<calc> pitti: ok
<tjaalton> pitti: it still failed to find the device on the esprimo :/
<pitti> tjaalton: darn; nothing helpful in dmesg?
<tjaalton> pitti: not that I could quickly find. I can try it again tomorrow
<pitti> tjaalton: ok, thanks a lot for testing
<tjaalton> note that adrian bunk said on the bug that the commit actually removes support for the device :)
<tkamppeter> heno, ping
<heno> tkamppeter: hey
<warp10> Hi all!
<tkamppeter> Hi heno, thank you for sorting out the g-c-m stuff. Even with g-c-m staying in Universe, most of the people who reported bugs here are happy to switch to s-c-p, they simply click on Admin -> Printing and take what is coming up.
<heno> tkamppeter: yeah, a bug against g-c-m is really against ubuntu printing
<heno> I still have 20-30 to process
<tkamppeter> heno, yes, many users do no know about the internal structures of the printing system and report everything as a bug of the printer setup tool.
<tkamppeter> Many of the problems g-c-m users complained about simply went away by switching to s-c-p and also by my feature additions like DNS-SD support, HPLIP setup support, better SMB scanning, better auto-selection of printer-drivers, plug'n'print, ...
<heno> tkamppeter: yep, it looks that way. btw, please correct any errors I make in these triage runs on the bug; I won't take offense :)
<tkamppeter> An important missing point is sharing printers to Windows clients. For an SMB sharing with driver supply from the server we would need to ship the non-free CUPS PostScript driver for Windows (from www.cups.org) in our restricted drivers.
<slangasek> soren: are you interested in testing out the preliminary openldap 2.4 packages?
<lool> Hmm I didn't know Fedora had a Rosetta-like solution
<sjoerd> They started it recently apparently
<sjoerd> But they want to set it up more distro neutral according to lennart
<lool> (Naturally, I read about it via Lennart's blog post :)
<dx9s_work> any good wiki-s on deb's from source? (recent switch to ubuntu from slackware and I understand the slackbuild process and interested in what sources and scripts the distro maintainers use -- so I can re-build some customized .debs .. like for one a tweaked kernel option for 4GB+ RAM and redoing everything that depends on libjack as I've updated to newer svn version )
<pochu> !packagingguide | dx9s_work
<ubotu> dx9s_work: packagingguide is The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<dx9s_work> ty
<pochu> dx9s_work: also for packaging questions #ubuntu-motu is the best place.
<dx9s_work> motu?
<pochu> !motu
<ubotu> motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
<dx9s_work> will head there if I can't answer specifics
<dx9s_work> so what's this channel used for .. -devel I know but where is the line in development versus packaging?
<enrico> Riddell: I had a look
<enrico> Riddell: for some reason, the test data doesn't seem to be there
<enrico> Riddell: the test data is in the .orig.tar.gz that I uploaded to debian
<enrico> Riddell: no idea why it's not found in that build log
<enrico> Riddell: try builing 0.5.12, however: 0.5.11 has wrong deps
<dionoea> Hello. Ubuntu has localized directory names for ~/Desktop. What is the standard way to retreive the desktop folder?
<dionoea> (that's an ubuntu specific feature right?)
<pitti> dionoea: that actually comes from upstream
<dionoea> from debian?
<pitti> no, from freedesktop IIRC
<pitti> and gnome
<dionoea> Ok, I'll have a look at the freedesktop specs
<dionoea> hum, can't find it in the freedesktop specs list, I'll have a look on the gnome website
<bddebian> They should all be in /usr/share/applications/
<pitti> dionoea: nothing at http://freedesktop.org/wiki/Software/xdg-user-dirs ?
<pitti> dionoea: looks like sourcing ~/.config/user-dirs.dirs would do what you need?
<dionoea> ah, well it wasn't on http://www.freedesktop.org/wiki/Specifications :)
<dionoea> thanks for the link
<pitti> dionoea: /usr/share/xdg-user-dirs/README :)
<dx9s_work> I'll try here.. is there a way to mass recompile (from source) and install (or create .debs for upgrading? -MOTU is silent on this) based on a dependency update? aka I've manually updated (outside of any packaging system) libjack (and the header files) and wanna select and recompile from source all things that depend on that ...
<geser> slangasek: do you know if there is some common "understanding" for gcc-4.3 fixes for hardy? are they worth a sync from Debian? or should I ask doko about it?
<slangasek> geser: I'm not aware of any plans to migrate to gcc-4.3 as the default compiler for hardy, which means it's a little late to be starting that discussion.
<slangasek> geser: so gcc-4.3 fixes aren't anything we should need to care about, though that doesn't preclude syncing with Debian at this point either
<geser> I've seen that Ubuntu packages got patches applied for gcc-4.3 in the past and was wondering if we should get them into hardy if possible or wait for the autosync for hardy+1
<slangasek> geser: oh, I don't think you should create an Ubuntu delta just for those fixes, no
<slangasek> sorry, I was reading your question the other way around
<geser> if the gcc-4.3 fixes from debian aren't that important to get them into hardy, I won't spent much effort to look for them and sync them
#ubuntu-devel 2007-12-18
<poningru> anyone around?
<poningru> I need help with a main inclusion report
<poningru> https://wiki.ubuntu.com/MainInclusionReportiSCSI?highlight=(iscsi)
<poningru> I wanted to know what to put for the security portion of the thing
<poningru> and the other stuff...
<somerville32> Did you not use the MIR Template? It has clues.
<poningru> OH?
<poningru> I did not see one
<poningru> I had to use other ones
<somerville32> For security, look for CVE reports and security-related bug reports
<poningru> ooh found the template
<poningru> thanks
<somerville32> np
<poningru> somerville32: another question... if the security vuln is patched already...
<poningru> should I still include it?
<poningru> http://www.debian.org/security/2007/dsa-1314
<Fujitsu> Yes.
<poningru> k thanks
<slangasek> yes, because the idea is to show the security history and how the incidents were handled
<bddebian> lamont: Are you actually around by any chance?
<mgunes> Hobbsee, while you are at it, could you post to (some of) those "how to upgrade packages the right way" etc. threads as well?
<Hobbsee> mgunes: got links?
 * Hobbsee isn't browsing the forums currently
<mgunes> sure
<mgunes> Hobbsee: http://ubuntuforums.org/showthread.php?t=640547 , http://ubuntuforums.org/showthread.php?t=641445
<lamont> bddebian: sup
<lamont> ?
<bddebian> lamont: Ah, I already sent it but I had debhelperized xdelta
<lamont> bddebian: cool
<lamont> so it's in my email?
<bddebian> lamont: I cc'd the bug.  I can dump it on mentors or something if you prefer.  I was going to fix a couple of the other bugs but I keep getting in trouble for that :)
<lamont> ah, ok.
<lamont> that'll work
<lamont> heh.  separate diffs for the other bugs wouldn't necessarily be complained about.
<bddebian> lamont: OK, I'll look
<Hobbsee> hrm.
 * Hobbsee wonders why the latest kernel does not appear to recognise her wifi hardware switch being turned back on again
<Hobbsee> ah, goody.  someone blogged about the @ubuntu.com spam
<Hobbsee> elmo: fix it plz :)
<lamont> bddebian: having them intermingled would be sad
<lamont> bddebian: likewise, having the diff in the form of a git-format-patch would be the total win... :_)
<bddebian> Hmm, never done a git-format-patch
 * lamont mutters something about needing to assemble a proper debian/copyright file for nmap 4.50
<lamont> bddebian: if you git clone, and then make the change, and then say 'git-format-patch' with some simple args, you get an mbox full of patches that you can then git-email
<bddebian> Ah
<lamont> OTOH, that invovles learning git a bit...
<lamont> er.   git-send-email :-)
<bddebian> Damn, give a guy an inch, he wants a mile ;-P
<lamont> LOL
<lamont> alternatively, one could send the name of a branch and a repo to pull from :-)  I think that's only 3/4 of a mile. :0)
<bddebian> heh
<lamont> bddebian: I'll read the diff in the morning once I'm awake. thanks much
<Hobbsee> wow, 685 for hppa.  that's going down a fair bit
<Hobbsee> (builds)
<bddebian> lamont: NP, let me know if it's way off or broken in any way :-)
 * Fujitsu thought it was at around 1600 just two days ago.
<Hobbsee> well, this number may be wront
<Fujitsu> No, it seems to be right.
<Fujitsu> I guess a lot have failed or depwaited quickly.
<lamont> Hobbsee: it's been busy building packages since the kde/toolchain guys got done doing all those uploads. :0)
<Hobbsee> lamont: heh
<Fujitsu> Ahh, it's that buildd depwait-detection failure bug.
<Hobbsee> lamont: i have whinged about htat
<Fujitsu> Bits of GTK and co apparently got uninstallable.
<Hobbsee> Fujitsu: on amd64?
<Fujitsu> Hobbsee: hppa.
<lamont> Fujitsu: once it gets done getting through the whole pile (and needs build gets to single or double digits), I'll have someone give back everything in failed.
<Fujitsu> So hundreds of builds would have failed quickly.
<lamont> it's so much nicer to do that with SQL than the UI
<Hobbsee> yeah, true
<Hobbsee> hehe
<Fujitsu> lamont: We'll hopefully have a mass give-back over * soon.
<lamont> well, it'd be nice if they stalled another couple days... maybe we can have that for christmas
<Fujitsu> But Soyuz probably won't be able to do it after tomorrow. Just to be annoying.
 * Hobbsee glares at the paper, forecasting the weather
 * Hobbsee is going to shoot something, if the weather writes off her next car too, with another hail storm.
<Fujitsu> How's it looking?
<Fujitsu> Hahahahaha.
<Hobbsee> http://www.smh.com.au/articles/2007/12/17/1197740183604.html
<lamont> Hobbsee: does that mean that your postal meter is approaching 100%
<lamont> ?
<Hobbsee> lamont: hrm?
<Hobbsee> lamont: i dont understand
<lamont> iz a "going postal" reference
<Hobbsee> ahhh
<Hobbsee> not really - nowhere to go
<lamont> when the postal meter hits 100%, well...   people go postal...
<slangasek> I thought when the postal meter hit 100%, you added another stamp
<lamont> in 1995 I worked for a team where the team homepage had a postal meter calibrated in %
<lamont> those were somewhat different times though, back when HP had a gun range here in Ft Collins.
<lamont> before they got all scared of guns and such and closed the range.
 * Fujitsu shoots lamont.
 * lamont hugs his kevlar jacket
 * lamont returns fire.
<Fujitsu> Damn.
<slangasek> hugging your kevlar jacket sounds like a good way to lose a hand
 * Hobbsee lobs bombs in lamont's general direction.
<lamont> tragic to have a drive-by shooting in an ubuntu channel... Does that fit with the CoC?
<slangasek> when the shrapnel starts flying
<Hobbsee> lamont: it doesn't explicitly forbid it.
<lamont> Hobbsee: "Once you have tac nukes, everything looks like a small city."
 * Hobbsee defenestrates slangasek
<Hobbsee> lamont: yeah, that's it
 * lamont debates the various merits of more self-defense bombing, or simply going to bed.
 * Hobbsee blows up the bed, to make the decision easier.
 * lamont sighs.  my wife was there.
<lamont> Hobbsee: now you're really in trouble.
<Hobbsee> i removed the wife first.
 * Hobbsee is always truble.
<lamont> still, it's her favorite bed _ever_.
<Hobbsee> er, trouble.
<Hobbsee> this was long known
<lamont> maybe you should have left her there... iz irish redhead. :-)
<lamont> "College co-ed destroys fellow developers bed, angers wife."
<lamont> yeah. bedtime.
<lamont> g'night
<Hobbsee> guess you'll have to find her another one then.
<bddebian> Gnight lamont
 * sladen quickly hides his bed
<warp10> Hi all!
<poolie> hi
<poolie> i have a source package, i'd like to get PPA to build it on Hardy as well as Gutsy
<poolie> help?
<lifeless> upload it twice
<lifeless> set the target via the changelog, so you have to build the source twice too
<poolie> hey, what a surprise
<poolie> :)
<poolie> it seems like that'll produce two source packages with the same name...
<poolie> should i add a version suffix for the distro?
<poolie> or just let it happen?
<lifeless> it will produce two source packages with the same name, and each will go in a separate archive
<lifeless> which is the same as e.g. building bzr 1.0 for two dapper and gutsy
<poolie> ok
<lifeless> look at the current bzr packages, they do this and are done 'right'
<poolie> ok
<poolie> so, practically
<poolie> i need a different directory and a different source tree on my local disk for each distro to stop the source packages clashing
<Fujitsu> lifeless: Note that they'll have to have different versions, as I mentioned in #launchpad.
<mekius> Hi, working on gOS and for some reason our latest ISO just locks up while trying to load the squashfs.  Is there anyway to debug why this would happen?
<dholbach> good morning
<ion_> Hola
<dholbach> heya ion_
<ion_> Whatâs up?
<dholbach> I'm waiting for coffee :))
 * \sh transmits dholbach some coffee from the company coffee machine through the fibre wires 
<ion_> The Internet is like a series of tubes.
<dholbach> letter chute! :)
<dholbach> what do we need to do to get scrollkeeper out of main? is anything still using it?
<Burgundavia> dholbach: make rarian work, I suspect
<dholbach> no, rarian is a scrollkeeper replacement
<dholbach> rarian-compat even Provides: scrollkeeper
<dholbach> so we should be able to move it to Universe soon, if there's no good reason
<Burgundavia> probably best to do it now, before the next alpha
<dholbach> cjwatson, Riddell, StevenK, mjg59, sladen, bryce, Mithrandir (bluetooth team), siretart, ajmitch, slangasek, imbrandon, asac, keescook+soren (server team), ogra, gpocentek, calc, lool: can you take a look at  http://people.ubuntu.com/~dholbach/sponsoring  please?
<Mithrandir> dholbach: sir, yes, sir.
<dholbach> ROCK
<siretart> oh, only one for me :)
<dholbach> siretart: we can fix that :)
<StevenK> dholbach: ... I told you I know nothing about powernowd ...
<siretart> dholbach: heh
<dholbach> StevenK: there are a lot of people who have never touched any of the packages they were assigned before too
<StevenK> dholbach: Yes, but I don't want mjg59 to kill me.
<Mithrandir> StevenK: he won't.
<dholbach> StevenK: one of them is a bashism
<dholbach> StevenK: and with the other one you could just ask mjg59 if he's d'accord or if he can take a look at it
<dholbach> it's fine to re-assign to somebody else
<StevenK> Bug 163709 has geser's fingerprints all over it
<ubotu> Launchpad bug 163709 in wmclock "Please merge wmclock 1.0.12.2-5ubuntu3 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/163709
<StevenK> geser: Since you've dealt with the guy, I'll unsubscribe me and subscribe you?
<dholbach> StevenK: I picked somebody of canonical staff to make sure it gets in, in this case it was you to make sure that it gets in (it's fine if you consult others before that)
<Mithrandir> evand: about https://bugs.edge.launchpad.net/ubuntu/+source/libbtctl/+bug/176180 ; did you test nautilus-sendto + sending to a bluetooth device without the patch applied?
<ubotu> Launchpad bug 176180 in libbtctl "Please sync libbtctl 0.9.0-2  (main) from Debian unstable (main)." [Undecided,New]
<slangasek> dholbach: the only one you have listed on there for me is one for which /I'm/ awaiting sponsorship ;)
<dholbach> slangasek: oh... hehe :)
<dholbach> slangasek: I'll make sure to ping keybuk later on
<dholbach> Excusez-moi Monsieur Langasek
<slangasek> no worries
<dholbach> hey seb128!
<seb128> hello dholbach
<seb128> is archive.ubuntu.com being slow for everybody today?
<dholbach> seb128: it was ok for me some minutes ago
<seb128> dholbach: weird, it's downloading at something like 17kbs here today
<bryce> dholbach: I looked at the x11 one earlier today but we think it's going to be handled soon by debian anyway.  I just now sponsored the smplayer one.  For the merge, I'll look at it tomorrow, it's starting to get late here
<dholbach> bryce: rock on
<dholbach> bryce: sleep tight then :)
<geser> StevenK: I can take over bug #163709. Can you look at bug #176411? (you did the last merge)
<ubotu> Launchpad bug 163709 in wmclock "Please merge wmclock 1.0.12.2-5ubuntu3 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/163709
<ubotu> Launchpad bug 176411 in texlive-bin "[Sync request] Sync texlive-bin (2007.dfsg.1-2) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/176411
<StevenK> geser: You have a deal
<ion_> The 50-50-90 rule: anytime you have a 50-50 chance, thereâs a 90% probability youâll fail.
<geser> Mithrandir: please give-back: tex-guy. Thanks.
 * dholbach hugs super-geser
 * geser hugs back dholbach
<Mithrandir> geser: given-back
 * Mithrandir wonders why pulseaudio needs 8% CPU on a GHz-class machine to play sound.
<cVsup> i would like know how execute command in preseed file?
<cjwatson> cVsup: use preseed/early_command or preseed/late_command. Have you read the examples in the installation guide?
<cVsup> yes
<cVsup> d-i preseed/late_command chroot /target script.sh
<cVsup> correct?
<ildella> hi all
<cVsup> cjwatson, any idea?
<ildella> I am getting crazy this morning cause Eclipse just stopped starting up due to some mysterious jvm frame problem...
<ildella> found this bug: https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/174759/
<ubotu> Launchpad bug 174759 in eclipse "eclipse crashes " [Undecided,New]
<cjwatson> cVsup: fine provided that script.sh actually exists on the default path inside /target
<Fujitsu> ildella: This isn't a support channel.
<ildella> oh
<ildella> sorry
<ildella> what channel can I use?
<cVsup> yes
<cjwatson> cVsup: (and is executable)
<cVsup> cjwatson, d-i preseed/late_command string
<cVsup> need string?
<cjwatson> cVsup: are you actually encountering a problem? if so, I need error messages (and #ubuntu-installer would be better)
<Riddell> evand: have you seen this bug? https://bugs.edge.launchpad.net/ubuntu/+source/parted/+bug/107326
<ubotu> Launchpad bug 107326 in parted "non working gpt labels" [Undecided,Confirmed]
<cVsup> cjwatson, i need change usplash.conf for resolve problem white screen
<cVsup> with
<Riddell> enrico: seems the ept build failure was a bashism, https://bugs.launchpad.net/ubuntu/+source/libept/+bug/177033
<ubotu> Launchpad bug 177033 in libept "FTBFS: ept/runtest fails with recent dash version" [Undecided,Fix released]
<cjwatson> cVsup: messing around with a separate script.sh seems overkill when you could just put the shell commands you need directly in the preseed/late_command string
<cjwatson> Riddell: evand's off this week
<enrico> Riddell: oh, I see.  So I can find the fix in the ubuntu patch, right?
<enrico> good opportunity to have a look at that
<cjwatson> Riddell: IIRC the gptsync patch to parted was still needed even with the grub change
<cjwatson> and yes, it violates the standard, but so does Apple
<cjwatson> I think the suggestion to conditionalise it on <2TB is probably about right
<Riddell> enrico: yes it is, or just on that bug report
<cjwatson> or maybe just conditionalise it on is-a-Mac
<cjwatson> (unfortunate but there you go)
<cjwatson> that's fiddly as hell to work out, though, argh
<tjaalton> what's the status of python-brlapi?
<tjaalton> gnome-orca depends on it, but it's not available
<Riddell> interesting, thanks cjwatson
 * Hobbsee waves
 * Mithrandir tickles Hobbsee, then levitates off the ground, out of her reach.
<tjaalton> oh, brltty 3.9-5u1 is in NEW
 * Hobbsee pops Mithrandir with a pin
<Hobbsee> hrm, we're making progress
<Hobbsee> hardy has been alive for 6 minutes, and hasn't frozen yet
<seb128> Hobbsee: hardy frozen yet?
<Hobbsee> seb128: soft freeze, i believe.
<Hobbsee> i've been at work
<seb128> Hobbsee: do you use compiz? try disabling the animation thing there
<Hobbsee> seb128: yes.
<Hobbsee> seb128: ahh, is animation what's being blamed
<Hobbsee> seb128: they say they've fixed some crashes, and it seems stabler now
<Hobbsee> usually, my compiz would have hardlocked by now.
<seb128> well, that's what is freezing on my laptop installation
<seb128> when I ssh to the box compiz is eating cpu
<tjaalton> could someone shove the new brltty out of NEW, because I can't build a livecd due to gnome-orca being uninstallable
<seb128> anyway mvo adviced not using animation and compiz didn't hang since
<tjaalton> and I need to test a fix for livecd-rootfs
<Hobbsee> seb128: gotcha.  will try it, if i find it hardlocks again
<seb128> tjaalton: looking
<juliank> Hi everyone. I wrote a small script to create an Ubuntu USB Stick, with persistent support (incl. partitioning the usb stick). Something like this would be cool to have on the disk: http://jak-linux.org/tmp/iso2usb.sh  - But it's not finished yet.
<tjaalton> seb128: thanks
<Fujitsu> seb128: Can you magic-SysRq+K out of it?
<seb128> juliank: hi, you should rather mail the ubuntu-devel list to describe the idea, etc
<tjaalton> also, openoffice build-depends on libflute-1.3-jfree-java, which is in universe
<seb128> Fujitsu: didn't try
<seb128> Fujitsu: I can ssh and restart compiz
<Fujitsu> seb128: Aha, so it's similar to what I get.
<cjwatson> mjg59: bug 107326; you don't fancy nicking the minimalist dmidecode implementation out of libdebian-installer/src/system/subarch-x86-linux.c and conditionalising gptsync vs. pmbr on that, do you?
<ubotu> Launchpad bug 107326 in parted "non working gpt labels" [Undecided,Confirmed] https://launchpad.net/bugs/107326
<mjg59> cjwatson: Wurgh. It'd be a miserable layering violation in the parted code.
<mjg59> cjwatson: I'd be happy to make it x86/non-x86 dependent
<mjg59> We're not going to support installs on x86 EFI for ages, so it's not really an issue there
<cjwatson> mjg59: err, the people in the bugs are talking about x86 I'm pretty sure
<mjg59> cjwatson: Oh, ah, hrm.
<cjwatson> mjg59: we don't have to support installs on them - the boot drive can be MBR and you can have a separate GPT RAID
<cjwatson> say
<cjwatson> then I don't think you need EFI
<cjwatson> I think pulling disks out of Macs and repartitioning them on other systems is honestly vanishingly rare
<mjg59> Yes
<cjwatson> and yeah, it's a layering violation, but in exactly the place where we've been screwed by differing EFI implementations
<mjg59> I'm intruiged by why it's going wrong. I suspect we'd be better off if the kernel preferred GPT tables to EFI ones.
<cjwatson> there's a comment in libparted about why that was changed
<mjg59> s/EFI/MBR/
<cjwatson> it's a reasonable point that there is no way to generate a sane legacy MBR for a >2TB disk, so we shouldn't
<mjg59> Yes, that's probably fair
<cjwatson> so if you'd rather that that be the condition, that doesn't seem too bad to do in parted
<mjg59> Though in that case, we'd still need to add support for it creating logical partitions in the mbr
<cjwatson> urgh, true
<mjg59> Which we probably should do anyway
<cjwatson> the Apple test seems like an easier stopgap to plug the data loss
<mjg59> Yeah. Hrm.
<mjg59> cjwatson: Anyway. DMI information is exported via sysfs on 2.6.24
<mjg59> So just read, strcmp and get on with it
<cjwatson> oh, that's good
<cjwatson> I've added this to the gutsy release notes for the time being
<cjwatson> (on the wiki at any rate)
<Lure> dholbach: have closed bug 172755 (sponsoring asigned to imbrandon)
<ubotu> Launchpad bug 172755 in tripod "Rebuild for libgpod2 -> libgpod3 transition" [Low,Fix released] https://launchpad.net/bugs/172755
<dholbach> Lure: great
 * imbrandon looks up
<pgquiles> cjwatson: ping
<cjwatson> pgquiles: pong
<pgquiles> cjwatson: regarding bug 107326, I think what happens on Macs is a lot less important than what happens on every other machine. Surely Macs account for a very small percentage of Ubuntu installations. This bug should be fixed soon, Hardy should have a fixed GNU Parted.
<ubotu> Launchpad bug 107326 in parted "non working gpt labels" [Undecided,Confirmed] https://launchpad.net/bugs/107326
<cjwatson> pgquiles: my comments on the bug were not remotely intended to indicate that the bug should not be fixed. I was discussing it with mjg59 here earlier.
<cjwatson> pgquiles: it is perfectly possible to keep both working
<pgquiles> cjwatson: I didn't mean you meant it should not be fixed :-)
<cjwatson> you rather implied it
<mjg59> pgquiles: I strongly suspect that the number of users running Ubuntu on Macs is greater than those running it on systems with 2TB+ filesystems.
<pgquiles> cjwatson: I'm sorry, I'm not a native English speaker O:-)
<mjg59> But yes, you're right. It will be fixed. We're determining the best way of doing so.
<pgquiles> mjg59: I wouldn't be so sure, specially for ubuntu-server and specially for the next 5 years given that Hardy is LTS
<cjwatson> pgquiles: there is no need to persuade us about the importance of the bug
<pgquiles> the bug was present in edgy, feisty and is in gutsy
<cjwatson> pgquiles: I had simply missed it
<pgquiles> cjwatson: I was not trying to tell you off, we are all humans :-)
<cjwatson> I have set its priority and targeted it to hardy
<pgquiles> great, thank you
<cjwatson> I find it implausible that the bug was present in edgy, at least in the same form
<cjwatson> the gptsync patch to parted was introduced in feisty
<mjg59> Tch. What do I file a bug against in order to request package removal?
<StevenK> mjg59: The package itself
<seb128> mjg59: the corresponding package and subscribe ubuntu-archive to the bug
<mjg59> Ok
<StevenK> mjg59: And then poke someone here
<seb128> StevenK: that's not the right way ;-)
<StevenK> Last part completly optional. :-)
 * StevenK pokes seb128 about gimp
<pgquiles> cjwatson: you are right, the gpt patch in edgy is a different one. My bad.
<seb128> StevenK: well, I would not do it this way but I'm not approving srus neither, better to ask pitti what he thinks about it when he'll be around
<StevenK> It seemed the simplest way without going insane
<StevenK> steven@liquified:~/ubuntu/fftw-cruft% version-bump -u
<StevenK> Ubuntu mode enabled - new version prefix ubuntu1
<StevenK> Hah
<mjg59> slangasek: #177154 (from our earlier conversation)
<siretart> mjg59: thanks for CCing me
<mjg59> siretart: No problem
<cjwatson> slangasek: ubiquity uploaded per your earlier request
<persia> mjg59: Usually one tries to eliminate all the rdepends first.  In this case, it looks like about 20.  Should these all be migrating to rely on wodim?
<mjg59> persia: cdrecord is in multiverse. There's nothing interesting that actually neesd it
<mjg59> persia: And when it comes to copyright infringement, then we remove first and ask questions later
<StevenK> Gar, didn't siretart try really hard to get cdrecord into multiverse?
<Mithrandir> he did
<persia> mjg59: No, but a lot of things that don't really need it have a dependency due to never having been transitioned to an alternative.
<StevenK> I think I questioned him at the time
<Mithrandir> we could castrate cdrtools to not build mkisofs
<mjg59> persia: Unless those things are in multiverse, it's not an issue
<siretart> StevenK: there are negotiations ongoing atm. joerg has just been sent an email, and I'm curious to read his answer
<Mithrandir> siretart: would be so kind as to make cdrtools not build mkisofs for the time being?
<StevenK> I'm not. cdrecord can get out and stay out, as far as I'm concerned.
<cjwatson> is there good reason to believe that these negotiations will be more fruitful than endless previous negotiations with Joerg?
<cjwatson> it's not as if this is a new problem
<persia> mjg59: Actually, about half are in universe (in violation of universe ! depends on multiverse) according to debcheck.  I agree with remove-first-ask-questions-later, just was curious if you had thought about transition, so as to try to get it completed.
<mjg59> persia: I was under the impression that there was supposed to be some sort of transition package
<siretart> cjwatson: I do have reasons to beleive so, mainly because this time, the negotations are kept in private
<persia> mjg59: The transition package was removed when cdrecord was added to multiverse (see parallel thread in this channel)
<cjwatson> mjg59: there was. siretart intentionally removed it
<siretart> Mithrandir: sure. could you elobarate a bit why?
<mjg59> persia: Well, that was an error :)
<cjwatson> siretart: I believe there have been attempts at private negotiation in the past, too
<mjg59> Well, we've made some progress
<Mithrandir> siretart: see bug 177154.
<ubotu> Launchpad bug 177154 in cdrtools "cdrtools is undistributable" [Undecided,New] https://launchpad.net/bugs/177154
<Mithrandir> siretart: so unless mjg59 is wrong in his bug report (which I haven't checked, but I have no reason to believe he is wrong), we should either kill off mkisofs from cdrtools for the time being or remove the package.
<siretart> Mithrandir: tbh, I think since joerg has now waited for matthews answer so long (he has bugging me the last 2 weeks weekly on irc), we should give him some time to answer before we kill cdrtools (again)
<StevenK> Personally, not that my opinion matters much, I remain unconvinced we need cdrtools at all.
<siretart> unless there are compelling reason to do so at once
<Mithrandir> siretart: it doesn't seem like Joerg has any interest in contributing constructively to the discussion.
<siretart> Mithrandir: I'm currently having a query with him, and I have another impression
<Mithrandir> his comment in the bug report is "you don't understand the GPL, go away"
<mjg59> siretart: I should emphasise that the only way to deal with the mkisofs issue is to license the libraries and build system under a GPL-compatible license (optionally along with the CDDL)
<lamont> where is bddebian when I want to grumble at him
<mjg59> siretart: Either that, or we need to hear from every mkisofs and libhfs_iso copyright holder
<siretart> mjg59: he seriously doesn't understand the GPL this way, but argues in corner cases that apply at least to german and US law, and states that since all contributers are either germans or US citizens, this would apply here
<mjg59> siretart: Except for the Swedish ones
<cjwatson> siretart: and the British ones
<StevenK> So, he's on crack, as usual
<siretart> it's really hard to discuss this over channel boarders
<siretart> StevenK: so having a different opinion qualifies as being on crack?
<cjwatson> oh, maybe not British, the cdrtools package no longer has Steve's JTE patch
<siretart> shall I invite him?
<cjwatson> ./mkisofs/mkisofs.c:30:/* APPLE_HYB James Pearson j.pearson@ge.ucl.ac.uk 22/2/2000 */
<cjwatson> so unless he was visiting from another country ...
<siretart> heh
<mjg59> schily: Hi
<schily> mjg59 hi I have to complete my slides for a cdrtools talk....
<mjg59> schily: No problem. There's no urgency about anything.
 * Hobbsee whinges at BenC
<Hobbsee> lamont: there you go
 * lamont larts Hobbsee 
<lamont> we don't whinge or even whine at BenC
 * Hobbsee larts lamont back, and sets his house on fire
<Hobbsee> lamont: my wifi doesn't work on the new kernel :(
<bddebian> Hey folks
<BenC> Hobbsee: which chip?
<Hobbsee> BenC: intel 3945
<BenC> Hobbsee: make sure to install matching lum to get the firmware
<bddebian> lamont: Uh oh, what did I break?
<Hobbsee> BenC: alreayd got it.  it's loaded.  syslog says that the kill switch is on, though.
<BenC> Hobbsee: hit the kill switch then :)
<Hobbsee> BenC: duh.  done that.  no change.
<Hobbsee> BenC: it was giving me a kill switch message even when it hadn't been touched from when it loaded gutsy, where it was on.
<Hobbsee> BenC: i'm not *that* stupid :)
<BenC> Hobbsee: hmm, definitely file a bug then
<Hobbsee> BenC: any idea on how i can debug it further?
<BenC> I know iwl3945 has been working for myself and rtg
<BenC> Hobbsee: not sure...rtg is the man to talk to
<Hobbsee> BenC: ok, thanks.
<Hobbsee> BenC: i guess i'm asking...is there any way to force the kill switch on/off?
<BenC> Hobbsee: modinfo iwl3945 and see if there is
<Hobbsee> BenC: apparently not.  darn.
<bddebian> lamont: A little too much debhelper for you?
<Hobbsee> BenC: any idea when rtg would be around?
<lamont> bddebian: 3 fixes. one diff.
<lamont> *thwap*
<bddebian> ?
<lamont> and you added a build-dep on autocrap???  I fixed that
<BenC> Hobbsee: very soon
<lamont> 1) switch to debhelper.  2) standards version.  3) lintian errors
<lamont> admittedly, they cascade enough that taking them out of order is bad
<lamont> bddebian: eventually, I gave up and called it one commit.
<lamont> plus one for me to drop the auto* build-deps, and then merge it into my mess.
<lamont> anyway, thanks
<Hobbsee> hrm.  it's so nice that something apart from network mangler is spamming the syslog.
<lamont> Hobbsee: network mangler doesn't spam my syslog.
<lamont> oh right.  I purged it.  I remember now
<Hobbsee> heh
<Hobbsee> no, i'ts pulseaudio doing it now
<bddebian> lamont: Ah, sorry.  You were autoreconf'ing so how did you drop the autotools stuff?
 * lamont needs to add a crowbar patch to network mangler so that he can have it installed and dormant until he kicks it manually to do one round of network config
<lamont> bddebian: separate target (autofiles) in debian/rules, and drop the build-depends
<lamont> and about to drop the autofiles from source control
<lamont> the generated autofiles, that is.
<bddebian> lamont: Ah, OK
<lamont> running auto* on each and every buildd is (1) wasteful and (2) frequently gets you the wrong result (as autocrap changes radically from version to version)
<lamont> having said that, xdelta was using automake 1.4 (ew)
<bddebian> lamont: Maybe I'm not understanding.  Weren't you doing that before?  Or not because you had the seperate target?
<lamont> hrm...
 * lamont doesn't remember
<lamont> I'd made changes in my tree
<lamont> I've been treating xdelta with benevolent neglect for quite some time.
<seb128_> re
<bddebian> lamont: OK.  Well I'll make sure I only send a patch at a time next time, sorry
<seb128_> I had to reboot due network issue
<bddebian> wb seb128_
<bddebian> lamont: Oh, and one other thing.  I'm a little concerned about using dh_makeshlibs because I think it might be ignoring the libesio?
<lamont> bddebian: 'twas only grumbling.  thank you very much for fixing things for debhe,per
<bddebian> NP
 * lamont will look into that
<lamont> bddebian: that's right... now I remember the issue:
<lamont> gcc -Wall -g -O2 -o .libs/edsiotest edsiotest.o  ./.libs/libedsio.so
<lamont> edsiotest.o: In function `test6':
<lamont>  /build/lamont/xdelta-1.1.3/libedsio/edsiotest.c:194: undefined reference to `g_log'
<jikkejo> hello
<bddebian> lamont: Ugh :(
<lamont> something is dropping the glib stuff.  for the suck.
<jikkejo> i found a problem with ubuntu 7.10 with ipw2100 wireless card and wpa_supplicant. It's impossible to configure the wireless card. I'm newbie, but it's impossible for me!
<persia> jikkejo: This isn't really a support channel.  If you need help, try #ubuntu or #ubuntu-xx where xx is a country code.  If you have a bug, try #ubuntu-bugs.
<jikkejo> oh sorry
<jikkejo> but i want report a problem for developers
<lamont> if you want to play with it, please start with 'git clone git://git.debian.org/~lamont/xdelta.git'
<lamont> bddebian: ^^
<lamont> jikkejo: that's where the bug tracking system on launchpad.net comes in handy....
<lamont> since reporting bugs here gives no assurance that the right developers actually find out abiout it
<jikkejo> lamont: ok sorry but i'm new!
<bddebian> lamont: OK
<lamont> jikkejo: no worries
<lamont> bddebian: that's the current state of it... (and you'll want a git-core >= 1.5 or life sucks)
<lamont> you can still checkout and such, but the user interface is not user-friendly
<lamont> 1.5 was a serious overhaul of the UI
<LongPointyStick> grumble.
<LongPointyStick> so, the software and hardware rf_kill's are disabled...yet, there's still no flash of wifi
<lamont> LongPointyStick: afraid it's gonna go "boom"?  or are you compensating?
 * lamont ducks
<Riddell> siretart: ping ping, libxine1 doesn't install unless you have universe enabled
<Riddell> siretart: can you tell me what needs promoted?
<bddebian> lamont: How would you feel about a new upstream release? :)
<lamont> is there one?
<lamont> bddebian: I said _NEGLECT_. :-)
<bddebian> Aye, xdelta3.0t
<siretart> checking
<lamont> ah, that'd be the xdelta3 package
<lamont> this is xdelta1
<bddebian> Oh
<bddebian> hrm
<lamont> which leads directly to the neglect angle.
<poningru_> soren, ping
<soren> poningru_: Yes?
<siretart> Riddell: libxine1-bin. that one contains now the shared object everything links against
<poningru_> w00t
<poningru_> soren, can I discuss iscsi stuff with you?
<soren> poningru_: Sure thing.
<poningru_> I want to help with that
<poningru_> I started up the MIR
<bddebian> lamont: Ah, there is a 1.1.4 though also it appears
<soren> poningru_: Ah, that's very helpful. Thanks!
<poningru_> soren, but have never done anything similar before
<poningru_> so wondering if I was doing it right
<soren> poningru_: It's quite simple, really. Fill in the blanks by looking up CVE's and stuff from Debian's bts and Launchpad.
<poningru_> also I want to work on the ramdisk implementation
<soren> poningru_: That would be nice. Do you happen to have hardware to test with?
<soren> poningru_: ...because I don't.
<poningru_> https://wiki.ubuntu.com/MainInclusionReportiSCSI
<poningru_> oh you dont need hardware
<poningru_> iscsi just goes over normal stuff
<poningru_> as in tcp/ip
<siretart> Riddell: can you promote libxine1-bin?
<soren> poningru_: Yes, but it's kind of nice to have something to connect to in the other end, isn't it?
<poningru_> yeah you can setup openfiler for that kinda stuff
<poningru_> really easy to setup
<soren> poningru_: I know there's iscsitarget, too, but I'd like to test with what our users are likely to see in the wild.
<poningru_> soren, my thoughts exactly thats why I went with openfiler
<Riddell> siretart: done
<soren> poningru_: I'm not familiar with openfiler, I'm afraid.
<siretart> Riddell: thanks a lot!
<poningru_> http://www.openfiler.com/
<siretart> Riddell: xine-lib is currently in debian NEW, so the next upload will be a sync request :)
<poningru_> it has a virtual image
<poningru_> and you can just connect internally
<soren> poningru_: And this is what people use, you think?
<poningru_> yeah atleast my uni uses that
<soren> poningru_: Not dedicated boxes from Dell, Intel or whoever?
<soren> poningru_: That's not a lot of empirical data..
<poningru_> I know :P
<poningru_> yeah I dont have a dedicated box  like that...
<poningru_> hardware implementation of iSCSI is... weird and expensive
<soren> Ok. I'm working on getting my hands on one. It'll be at least a few days before I'll need a target anyway.
<soren> poningru_: I know. That's why I don't have one yet.
<poningru_> ooh cool
<soren> :)
<poningru_> but I dont think there is that much difference in target implementation
<poningru_> as in its not like the web
<soren> Sure.. I'm just a bit reluctant to put stuff out in the wild saying: "Here' this stuff works and is really good", and as soon as anyone uses it with something other than iscsitarget (which I'm guessing is what openfiler uses), it breaks in weird ways.
<soren> Of course, I could just rely on other people testing it, but experience tells me that the more expensive the hardware, the less inclined people are to test it.
<poningru_> I'true
<soren> ..since if it's expensive, it's probably a really important part of the infrastructure, so you can't affort to have it offline for even a short amount of time to test random stuff.
<poningru_> well... connecting to stuff shouldnt take it down... atleast I hope
<poningru_> soren, but yeah I'll test stuff out with enterprise target thing
<soren> poningru_: Sounds lovely!
<soren> poningru_: So you want to do the initramfs hooks?
<poningru_> yeah
<poningru_> when does that need to be done?
<poningru_> can you give me a deadline?
<soren> Tomorrow's fine.
<soren> :)
<poningru_> :p
<soren> It's not particularly urgent. Hang on, I'll check the schedule.
<soren> Well, it's too late for alpha 2 anyway. Alpha 3 is January 10th.
<poningru_> I hmm
<poningru_> Jan 5th sound good?
<mario_> siretart: poke?
 * siretart dislikes this virtual tennis
<soren> poningru_: That might work.
<poningru_> sweet
<pygi> siretart: you have time?
<pygi> 5 minutes
<siretart> what's up?
<pygi> schily: poke? :)
<Riddell> mvo: were you able to recreate bug 156320 ?
<ubotu> Launchpad bug 156320 in update-manager "[kde] copy XAUTHORITY may fail and crashes the upgrader (was: Upgrade tool crashed when upgrading 7.04 -> 7.10)" [Medium,Confirmed] https://launchpad.net/bugs/156320
 * lamont sighs about nmap 4.50 lacking an assembled list of copyright holders adds that to his list of things to do over christmas break
<mvo> Riddell: I don't think so, but let me re-check
<Riddell> mvo: you confirmed it
<mvo> Riddell: *cough* right. I think I confirmed it because there is no check if the environment that XAUTHORITY points to actually exists prior to the shutil.copy I think
 * mvo grumbles about the dpkg-divert handling in slocate
<Mithrandir> mvo: or lack thereof, I suspect?
<mvo> Mithrandir: heh :) yeah, its pretty fragile and breaks (depending on the order of install/upgrade) on gutsy->hardy upgrades
<lamont> mvo: suckage
<slangasek> cjwatson: thanks for the ubiquity upload
<slangasek> mjg59: ah, #177154 is looking interesting already...
<mjg59> slangasek: Only the best for you
* slangasek changed the topic of #ubuntu-devel to: Archive: OPEN | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Hardy Alpha 2 self-imposed freeze in effect
* somerville32 changed the topic of #ubuntu-devel to: Archive: Self-Imposed Freeze for Hardy Alpha 2 | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
 * lamont heads officewards
<soren> Hm.... What's the purpose of the device nodes in /lib/udev/devices ?
<torkel> soren: In case you have no more left in /dev ?
<torkel> :-)
<soren> torkel: Possibly :)
<cjwatson> the ones in /lib/udev/devices are copied in at boot as a quick way to seed the /dev tmpfs
<cjwatson> /etc/init.d/udev
<cjwatson> I assume it's just less code that way or something
<soren> cjwatson: Ah, right. Thanks.
#ubuntu-devel 2007-12-19
<Fjodor> Sorry to ask, but where and to whom do I talk about backports from hardy to gutsy?
<Fujitsu> !backports | Fjodor
<ubotu> Fjodor: 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
<Fjodor> Fujitsu: Thanks. More specifically, though, I would just like to ask the person in charge of that specific package why the compcomm-settings-manager thingy isn't backported when alle the other compiz(fusion) things are...
<Fjodor> Basically, that's why I ask here, as I would deem this a dev (or packager) question, and not just a simple usage one that would be better asked in #ubuntu
<Fujitsu> It may just be that nobody thought to backport it.
<slangasek> Fjodor: anyone here would just have to look up who the backporter in question is, presumably you can find that information even easier than we can since you have the other backports in front of you
<Fjodor> slangasek: Now we are moving! Where do I look up backporters?
<Fjodor> Fujitsu: Indeed, so I just need to get in contact with the guys who are handling these packages (see below)
<slangasek> Fjodor: in /usr/share/doc/$package/changelog.Debian.gz
<Fjodor> slangasek: Excelent. Thank you!
<poolie> i'm trying to update my own apt archive
<poolie> how do i make a Release.gpg file?  i thought it was just by signing the Release file
<poolie> but that gives 'unknown gpgv error' from apt
<Fujitsu> poolie: Do you have the key on apt's keyring, and is the error from a chroot (where gnupg might not be installed)?
<poolie> yes, and no respectively
<Fujitsu> Nothing more useful than `unknown gpgv error'?
<poolie> no, it sucks
<poolie> well
<poolie> W: GPG error: http://bazaar-vcs.org ./ Release: Unknown error executing gpgv
<elmo> -o debug::acquire::gpgv=1
<elmo> poolie: ^-- try with that
<poolie> thanks
<poolie> ok, that shows a command
 * Fujitsu worships all-knowing elmo.
<poolie> which when i run it gives, "no valid openpgp data found"
<poolie> it is a valid ascii-armoured file though...
<Fujitsu> What's the URL to it?
<poolie> ah, that's because it gave the exec args with argv0 repeated
<poolie> http://bazaar-vcs.org/releases/debs/gutsy
<Fjodor> slangasek: Just a final thank you and update. I just mailed the last person to update the package. Thanks for the pointer
<poolie> ok, "not a detached signature"
<elmo> poolie: that dosn't look like ...
<elmo> right.. not one of those :)
<slangasek> Fjodor: no problem
<poolie> elmo, --detach-sign wants to produce Release.sig - i just rename it to .gpg?
<elmo> poolie: yeah
<poolie> yay
<poolie> thanks
<Fujitsu> I think you want a -a in there.
<poolie> is it meant to be ascii or not?
<poolie> the previous one was not...
<elmo> poolie: I suspect either works
<elmo> poolie: ascii is more friendly and is what ubuntu/debian uses
<Fujitsu> The one I saw first was ASCII, but the latest one is not.
<Fujitsu> Ah, that's better.
<poolie> i am getting more convinced about using a PPA :)
<Fujitsu> PPAs don't sign yet.
<poolie> i know
<poolie> i mean, just avoiding this in general
<poolie> or, avoiding building equivalent automation
 * lamont wonders how well a breezy->gutsy upgrade will work
<slangasek> it'll be very brutsy
<TheMuso> lol
 * persia suggests hitting Dapper along the way for the new meta-packages bonus
<lamont> well, it's a rather slow rsync to get the iso where I can burn it, so I have an hour to kill.  what the hell.
<lamont> persia: was planning on dapper
<lamont> and then maybe I'll leave it at dapper. :)
<StevenK> And a chance to reinstall if it all goes horribly horribly wrong?
<lamont> install testing is all about love
 * lamont just upgraded his laptop to 4GB, and now it runs slower.
<lamont> most annoying
<poolie> hello lamont
<lamont> howdy
<zul> lamont: how much do you like to suffer :)
<lamont> zul: netboot hates me right now, and the machine has breezy on it through a strange array of coincidence
<lamont> OTOH, 1u ia64 boxen are kinda noisy
 * Fujitsu would advise going to at least Edgy, as there were a lot of migrations.
<lamont> esp when you're sitting 2 feet in front of it
<poolie> keeps the winter chill away though :)
<lamont> heh
<persia> Fujitsu: Aren't most the migration hints still there for Gutsy?
<lamont> dapper is fine for doing chrootish things... and besides, it's not for me. it's for christmas
<lamont> the evms-must-die one isn't
<StevenK> I remember the Itanium at LCA '02 (I think it was) -- my bag was 3 feet away from it, and it was hot
<Fujitsu> persia: They're meant to be, but I've tried Dapper->Gutsy, and it... didn't work well.
<Fujitsu> I suspect that Edgy->Gutsy would work much better.
<lamont> when I get home, I get to recover a box that I just dist-upgraded from feisty to gutsy, which doesn't boot anymore because it has root on /dev/md0
 * ScottK tried Dapper -> Gutsy as well.
 * ScottK got there, eventually, but with no TTYs.
<lamont> ScottK: yeah.. that's a known bug.
<ScottK> Yeah.  I know, but it doesn't make it more pleasant.
<lamont> 'struth
 * ScottK looks around for someone who will actually fix it.
<lamont> I thought it had been
<lamont> dunno.
<lamont> pester keybuk and/or mvo
 * ScottK doesn't have any boxen needing Dapper -> Hardy for real, so can't be bothered.
<lamont> amazing how our beloved child becomes a step child to hide under the table
 * Hobbsee should upgrade her edgy machine.
<ScottK> Well I've got Christmas card lables to print.
<lamont> yeah!  netboot loves me, it's the console that didnt
<StevenK> My server here will be jumping from Dapper to Hardy
 * lamont learned that nssldap doesn't care if the server cert is expired.
<lamont> whereas ldapsearch does
<StevenK> Two servers, even
<lamont> kewl.  lan A was actually eth0. :-)
<Fujitsu> lamont: Is that surprising?
<lamont> I've found that it depends...
<lamont> sigh.
<lamont> yes
<lamont> I did find the right place to unplug the cable so that it would ask for a proxy.  go me.
<Fujitsu> Hah.
<lamont> stupid so-called "transparent" prxoies
<lamont> and the box gets to have gutsy on it.
 * Hobbsee notes that one eventually gets used to the compiz-slow-refresh
 * Hobbsee wonders why compiz has only crashed once today
<lamont> Hobbsee: it hasn't crashed for me all week. :-)
<Hobbsee> lamont: is it purged?
<lamont> yeop
<Hobbsee> odd, that
<lamont> or (in the other case), no 3d acceleartion
 * Fujitsu finds that purging fixes a lot of things, including trackerd eating the CPU.
<lamont> Fujitsu: don't forget network-mangler
 * Fujitsu likes network-mangler.
<Fujitsu> Is it related to queue-mangler?
<slangasek> if trackerd would eat network-mangler, that'd be just fine
<lamont> no
<lamont> Fujitsu: purging network-manager should not down the interfaces on my box.
<lamont> that's rude
<persia> I thought the alternatives to network-mangler were being removed, making it harder to purge...
<Fujitsu> lamont: Restarting it shouldn't either, but that's what it does.
<slangasek> persia: "ifupdown"?
<persia> slangasek: Yes (or at least my configuration is becoming unhappy over time)
 * Fujitsu finds that quite adequate unless versatile wireless is wanted.
 * lamont uses ifup and dhclient
<slangasek> persia: hmm, works for me so far
 * persia hopes it continues to do so
 * lamont has been using ifupdown forever
<lamont> well, a few years anywway
 * Fujitsu thinks we might have some slight complaints if it stops.
<lamont> heh
<lamont> and how.
<persia> Fujitsu: It depends.  If there was a perfect alternate solution that didn't break things when it was enabled, it would likely be acceptable to many.
<lamont> persia: that rules out network-manager
<lamont> at least until it gets more use-models in it than "there is one network"
<Fujitsu> I believe there is some sanity on the 0.7 roadmap.
<persia> s/one network/one network with guaranteed uptime of the primary router and any DHCP server/
<slangasek> persia: yes, one that doesn't require me to log in before it brings the network up
<Fujitsu> Multiple active interfaces and system-wide config are on said roadmap, I believe.
<persia> slangasek: That's not so bad for the notebook use-case, but it's frustrating to have the network stop working because of dropped packets to the router.
<slangasek> persia: it's bad for the notebook with kerberos use case
<persia> slangasek: Right.  s/notebook use-case/exceedingly simplified single-user single-person self-managed environment in perfect surroundings/
<slangasek> right. :)
<lamont> persia++
<StevenK> slangasek: Could I convince you to release texlive-bin from binary NEW?
<Fjodor> Oh, btw., does this channel still concern itself with matters of gutsy (specifically the logout dialogue in GNOME)?
 * Fujitsu doesn't see how that is specific to Gutsy.
<persia> Fjodor: Yes, but not in the sense that things should be complained about.  There's a spec for a new solution planned for hardy...
<slangasek> StevenK: what does it break this time?
<lamont> slangasek: gnome? :-)
<Fujitsu> $world
<StevenK> slangasek: It shouldn't break anything
<persia> Fjodor: https://wiki.ubuntu.com/DesktopTeam/Specs/ExitStrategy
<lamont> slangasek: btw, congrats on becoming a real person today
<StevenK> slangasek: It's a direct sync, so it's Debians fault
<slangasek> StevenK: it's tex, of course it breaks something
<StevenK> Bwahaha
 * lamont hates 9600 baud serial consoles
<Fjodor> persia: Hmmm, so if pressing the logout button results in an inaccessible system for several minutes before the logout dialogue appearing (sometimes without options for sleep and hibernation), that is hardy(+) material? I will be reading the link in 2 minutes...
 * lamont wonders if a 2GB EFI partition is a bit excessive, for a kernel develoer
<persia> Fjodor: Not necessarily, but for a blocking problem or regression, filing a bug is a better solution.
<Fjodor> persia: Ok, will do then. I just hoped to get someone involved on the line, as my gf is bugging me about it all the time ;-)
<Fjodor> persia: Thanks
<lamont> Fjodor: those sorts of support issues plague all of us.
<lamont> and after you upgrade from gf to wife, it just gets more so...
<persia> Fjodor: It's more that the solution is likely complex, and so a quick fix is definitely wrong.  You might be able to get hints on a workaround in #ubuntu
<Fujitsu> lamont: One should use GF LTS to avoid upgrade issues?
<lamont> Fujitsu: once you install wife, downgrading is inadvisable
<Fjodor> lamont: Indeed, but however much empathy you get, the hard fist of wife-alpha1 still perseveres ;-)
<Fjodor> persia: Ok, thanks, but I have tried there for some time now...
<persia> Fjodor: In that case, there probably isn't a workaround :(
<lamont> sometimes, signal-to-noise suffers on #ubuntu.  not always though.
<lamont> and yeah, that points to a lack of a workaround, or that the people who have the workaround are in the wrong timezone relative to you
<lamont> dear partitioner.  when I create a md device with n partitions, and there are n drives with one partition each available, please preseed the answer for me.
<lamont> kthxbye
<Fjodor> persia: Well, I have done some preliminary diagnostics. That's why I went here afterall. I have had complaints about it on my gf's laptop, I see it on my own laptop, I see it on my desktop, and I see it on my office desktop. That's my reason for deeming it reproducible...
 * slangasek looks at lamont blankly
 * Fujitsu hasn't seen that issue since early in Gutsy's dev cycle.
<Fjodor> lamont: But yes, you are right
<persia> Fjodor: Right.  That would be a bug then, so the people who work on that package will be notified, and can discuss alternatives for a solution.
<slangasek> n partitions, or n components?
 * Fujitsu hopes the latter.
 * lamont sees slangasek's blank look, and raises him an eyebrow.
<lamont> create an md device gives me a list of partitions to put in the array.  there are certain cases where the answer is obvious and forced.
<slangasek> right, so "an md device with n components"
<slangasek> since one rarely partitions an md device
 * lamont currently sees long delays at login because of restricted-manager thinking about life.
<lamont> slangasek: partitions on other devices... the list is of partitions to use to make the MD device
<Fjodor> Just for speeding things up, where do I report the bug? If noone has the direct URL, I'll find it myself, but you devs seem to be able to find such things at a wink of the eye
<lamont> given that partition 1 on the drive needs to be (in this case) efi, the raid device lives on partition 2
<lamont> hrm... I guess this machine does get a desktop install
 * lamont forgot the magic incantation to tell the alternate CD to install just server-bits.
<lamont> and doesn't want to go back in any case
<Fujitsu> lamont: The incantation is a down arrow at gfxboot, I think.
<lamont> Fujitsu: no.
<lamont> that's the right answer after the iso generation code is fixed
 * lamont grumbles at the installer for not allowing a blank password.
<lamont> Fjodor: if we assume it's in the gnome-session source package (which is a leap), then https://bugs.launchpad.net/ubuntu/+source/gnome-session/
<lamont> and if it's not gnome-session, one of the gnome-heads will eventually move it to the right package, I expect...
<lamont> but that's just a shoot-from-the-hip answer.
<lamont> 1  â 50  of 506 results
<lamont> yeah!
 * lamont wonders if the queue will break 500 before he heads out in a bit
<Fjodor> lamont: Ok, thanks. I'll load that url, and if it doesn't fit, I'll roll from there. Launchpad can just be somewhat confusing from time to time...
<persia> s/somewhat/very/
<lamont> s/from time to time//
<lamont> you are in a twisty maze of pages, all different
<Fujitsu> You would be likely to be eaten by a grue, except that the green bar at the top is too bright.
<lamont> Fujitsu: clearly you haven't played the original much. -
<lamont> :-)
<lamont> advent has no grues
<Fujitsu> That would be a correct assumption.
<Fjodor> lamont: Thanks again. https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/123078 seems to very acurately describe what I am seeing
<ubotu> Launchpad bug 123078 in gnome-session "System -> Quit takes a long time to appear" [Low,Confirmed]
 * lamont beams with glee
<lamont> I got one right!!
<Fjodor> (the title doesn't cover it all, but the problems are all described there)...
<lamont> dear installer.  please consider saying something cuter than "Please wait...".  maybe something like "please don't kill me, sir...".   kthxbye
<lamont> hrm... gender biased.
<lamont> never mid
<lamont> mind
<Hobbsee> lamont: i shoved kde4 down again on hppa
<lamont> Hobbsee: heh.  tahnks
<lamont> although, apparently there's a neat LP bug that will rescore it to where LP thinks it belongs
<lamont> for the win
<Hobbsee> hehe
<lamont> I don't mind building kde.  I mind building out-of-date kde
<lamont> so if they'd just get it right before they uploaded, then I wouldn't have to think of ways to hurt them.
<lamont> "Installation complete"
<LongPointyStick> lamont: not really.  i'd just like working wifi, thanks!
<lamont> LongPointyStick: heh
<lamont> Hobbsee: so why you running two clients?
<Hobbsee> lamont: one to log.
<Hobbsee> this is a laptop.  i turn it off
<lamont> --- [LongPointyStick] (n=mystery@ubuntu/member/hobbsee) : " "
<lamont> such a mystery...
<Hobbsee> lamont: yeah, i know.  it's used for other networks, when i mess with people's minds
<lamont> hehe
<StevenK> It might take you ... seconds to solve
<lamont> individuals of clue will note the similarities
<lamont> kewl.  console install of gutsy:  /etc/event.d/ttyS*
<lamont> that's with server install.
<lamont> kewl.  default was the right thing
<lamont> (netboot)
<Fjodor> Hobbsee: You are concerned with user experience, right (if I remember correctly)...
<Hobbsee> lamont: on non-cloaked networks it's useful.
<Hobbsee> Fjodor: that's oen of the things i'm concerned about, yes
<Fjodor> Hobbsee: Thought so. Did you see my last two messages before I addressed you directly?
<Fujitsu> lamont: That build-score-clobbering bug should be fixed with 1.1.12.
<Hobbsee> Fjodor: about https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/123078 ?
<ubotu> Launchpad bug 123078 in gnome-session "System -> Quit takes a long time to appear" [Low,Confirmed]
<Fjodor> ...and I apologize again for singling out individuals to complain to, but my gf is really bugging me about this one...
<Fjodor> Hobbsee: Yes, indeed
<Fjodor> For the longest time, I just assumed that it had hung, and ctrl-alt-backspaced it all...
<Fjodor> ...and try to explain that to a non-literate in the arts of linux...
<lamont> so... when I remove the password from /etc/shadow and make it say :: there... why can't I log in anymore?
<lamont> Fjodor: "It's like ctl-alt-del, only with the backspace key instead'. :-)
<Fujitsu> lamont: That build-score-clobbering bug should be fixed with 1.1.12.
<Fujitsu> Oops.
<Fujitsu> Wrong button.
<Fjodor> lamont: indeed, but she just wants a machine that *works*
<lamont> yeah.  my wife occasionally asks to install windoze for that reason, and I look at her strangely until she hits me.
<lamont> all in all, I'm not sure that counts as a "win'
<lamont> hrm... init=/bin/sh seems to have not quite done what I wanted.
 * lamont declares victory and heads home
<StevenK> Haha
<Fujitsu> It didn't do what you want, so you're victorious. I see.
<lamont> Fujitsu: no.  I declared victory
<Fjodor> Well, per request I gave her OSX. It took 10 minutes till she cried "Give me back my Ubuntu" :-)
<lamont> which is to say, I redefined the problem.
<Fjodor> And that counts as a win for all you guys :-)
<lamont> Fjodor: those are nice wins.
<lamont> and time for me to run away.
<Hobbsee> weird
<lamont> back in a few hours
<Jay-Oh-En> kdmthemes overrides are broken
<Hobbsee> and irc doesn't make a good todo list.
<Jay-Oh-En> whatever
<Jay-Oh-En> just letting you guys know
<persia> Jay-Oh-En: Yes, but there's no guarantee anyone who cares is here now.  File a bug.
<Hobbsee> persia: they wouldn't be on this channel anyway
<Hobbsee> holy cow
<Hobbsee> aptitude segfaulted
<Jay-Oh-En> why wouldnt they
<Jay-Oh-En> persia: well ill files a bug
<persia> Jay-Oh-En: Thanks :)
<Jay-Oh-En> Hobbsee: quit being so uptight
<Hobbsee> because they're likely on #Kubuntu-devel, and a lot of people aren't awake at this time of day anyway
<Hobbsee> heh
<ajmitch> if he thought *that* was uptight...
 * Fjodor tries in vain to step in for Hobbsee an say that she isn't uptight...
<Hobbsee> if he files a bug with the same content as his irc message, i'm going to have savage pleasure setting it to NEEDSINFO, and waiting for LP to do it's job.
<Fujitsu> Janitor reappears this release, sort of.
<Hobbsee> i thought it was always on now
<persia> Does that mean another few hundred bugs to undo?
<Fujitsu> When I say `sort of' I mean `with a per-project off button, and only commenting, not closing, so we can see what it will do when it is turned on properly'
<Hobbsee> oh *classy*
<Fjodor> Oh, btw., have I told you about this strange bug that I seem to be the only one to have on my office machine?
<Hobbsee> aptitude segfaults if you try to get a package on a changelog that doesn't exist
<Fujitsu> Does it? Nice of it.
<Hobbsee> yup
<StevenK> Hobbsee: That code is *horrid*
<Fujitsu> william@irranat:~$ aptitude changelog boom
<Fujitsu> E: Couldn't find a changelog for boom
 * TheMuso is reminded of the aptitude fisco on Planet Debian recently.
<Hobbsee> Fujitsu: which version of aptitude?
<Fujitsu> Killing the apt transition, TheMuso?
<Fujitsu>   Installed: 0.4.9-2ubuntu3
<TheMuso> Fujitsu: Yeah.
<Hobbsee> Fujitsu: strange.
<Fjodor> What could cause gnome-update-manager to confuse it's buttons? I run it, but when I press "Install Updates", it acts as if I pressed "Check". And to make it stranger still, I can only reproduce it on my office machine...
<Hobbsee> something crackful...
<Fjodor> Hobbsee: Indeed, but this machine is the one that was installed from scratch most recently...
<Hobbsee> ah ha.  reprioritizing some of the stuff in gnome makes it start much quicker.
 * TheMuso is shocked. Hobbsee still using GNOME? :)
<Hobbsee> Fjodor: the defaults look borked.
<Hobbsee> TheMuso: yeah, it appears so.
<Hobbsee> TheMuso: there's some really annoying stuff about it though
<Fjodor> Hobbsee: Pointers?
<Hobbsee> TheMuso: kde sessions win over gnome's.  although this priority stuff is nice
<Hobbsee> Fjodor: give the crucial stuff a priority of 40, then hit apply to each.
<Hobbsee> like, gnome-session-properties, gnome-volume stuff, etc
<StevenK> That's only because the KDE session information contains stuff as the last time you scratched yourself, where and for how long.
<Fjodor> TheMuso: /me is using GNOME. I left the path of LFS/BLFS and WindowMaker some time ago, where you making a point?
<TheMuso> Fjodor: Hobbsee is a KDE advocate.
 * Hobbsee likes that you can you can start with an empty profile, start the stuff you want, and then hit "save current session" - which will restore things *exactly* how you've left them
<Hobbsee> which i haven't found out how to, under gnome.  devilspie works somewhat, but dosen't do to tray
<Hobbsee> and doesn't appear to work if you have 2x2 windows
 * Fjodor does not expect things to be as when he left them. Because then there must have been a power outage...
<Hobbsee> well, no, but i have a list of stuff that i want to start, every time.
<Hobbsee> (nm, gnome-do, pidgin, etc)
<TheMuso> gnome-do?
<StevenK> TheMuso: Quiksilver for GNOME
<Hobbsee> see lp.net/gc
<Fjodor> Hobbsee: Indeed, but does devilspie also place them in the correct workspaces?
<TheMuso> StevenK: WHich is?
<Fjodor> ...because then I might take alook
<Hobbsee> Fjodor: usually.  when you run a 1 row thing, yes.  when you run 2 rows, not always.
<Fjodor> Hobbsee: Ok
<Hobbsee> devilspie is *nice*
<StevenK> TheMuso: Katapult is the KDE one
<TheMuso> StevenK: What is quicksilver?
<bluefoxicy> what
<StevenK> TheMuso: It's a quick launcher, hit alt-space, the first few letters, it'll try and match and hit enter to launch
<bluefoxicy> I can't make fun of Hobbsee anymore for being a KDEhead?
<TheMuso> StevenK: ah
<Hobbsee> bluefoxicy: i'm sure you can find something to make fun of, w.r.t. me.  and i'm sure that i can ban you in return.
<bluefoxicy> Well i could make fun of you for being a girl, but that's kind of childish in comparison to making fun of you for using KDE
<Fjodor> Hey Hobbsee? Make me a bouncer, then I'll relay all messages and deride the senders in return :-)
 * bluefoxicy gives Fjodor shades and a big stick.
<bluefoxicy> You are now a bouncer.
 * Hobbsee wonders why the words "castration" and "bluefoxicy" are coming to mind...
<Fjodor> Badabum
<Fjodor> And bluefoxicy: thanks :-)
<bluefoxicy> Hobbsee:  Wouldn't make much of a difference
<hodgson> How do I reset all of my gconf menu options to the factory-default, I remember there being an undocumented option something like gconf-editor --reset-defaults /location/in/gconf and I just need some help, thanks.
<bluefoxicy> --recursive-delete I think
<Fjodor> Hmmm, I was given shades and a big stick. Anyone in the mood for a joke?
<Fjodor> (since nothing much else happens)
<hodgson> think not.
<Fjodor> hodgson: Ok, sorry
<Hobbsee> damn
<Hobbsee> i can make an app dock with devilspie, but then it keeps docking
<Quiane> hello everyone
<Quiane> wow..not really busy in here
<Quiane> is there anyone here? lol
<Hobbsee> oh, goody.  --safe-upgrade for aptitude now behaves sanely, w.r.t new packages
<Hobbsee> at least, once mvo merges it across
<Fujitsu> Quiane: 22 seconds isn't a very large sample size.
 * lamont does his happy dance.
<lamont> 496 packages in needs-build hardy/hppa
<Fujitsu> lamont: That was a short departure.
 * Fujitsu checks the number of failures.
<lamont> 'twas the drive home
<Fujitsu> Not too bad, actually.
 * Fujitsu is surprised at how quickly it is chewing through them, and the success rate.
<lamont> 22 miles
<lamont> gutsy was at >97% in gutsy-stage0
 * Fujitsu charges lamont with use of imperial units.
 * lamont notes that he is imperial, after all.
 * Fujitsu bows.
<lamont> great.  LinuxOLD boots, Linux doesn't.  that's gonna take a little love
 * lamont afk for a bit
<Quiane> i'm here actually!
<Quiane> i was just talking in the other room
<hodgson> Ok, so I've got a decently well-directed question: Where are the terminal preferences stored? As in the right-click ->options->preferences on the panel
<hodgson> is it in gconfeditor, a conf file, or some other random esoteric gnome location that is plesently undocumented
<TheMuso> hodgson: Which terminal are you using? Gnome-terminal? If gnome-terminal, then gconf.
<hodgson> oh shoot
<hodgson> not terminal preferences
<hodgson> panel preferences*
<hodgson> specifically the one top one, I think it is called the ''application-launcher'', has applications/places/systems by default
<TheMuso> Oh then I'm not really sure.
<lamont> anyone using raid-for-root
<lamont> ?
<hodgson> fucking gnome
 * lamont tries to remember the incantation to get initramfs to stop during each step
<hodgson> I swear to god it gets more shitty with each growing interation.
<hodgson> Ok get this -- ~/.config/menus/applications-menu
<hodgson> how the hell.
<hodgson> I swear last week it was it was in gconf-editor, and you could reset it with --recursive-unset, before that I remember it being in ~/.gnome, or the like.
<Fujitsu> !ohmy
<ubotu> Please watch your language and topic to help keep this channel family friendly.
<hodgson> where the hell did ~/.config come from
<lamont> ah. mischief managed.
<lamont> adding md-mod and raid456 to /etc/modules makes life much happier.
<lamont> (root being raid5, it helps to have the modules needed to support that in the initrd)
<lamont> something in initramfs should notice that
 * persia thinks /etc/modules is currently entirely manually managed, and encourages a migration to /etc/modules.d/
<warp10> Hi all!
<pitti> Good morning
<Fujitsu> Hey pitti.
<StevenK> pitti: So, why do libgsl0 and libglib1.2 show as FTBFS in the NBS list? They don't.
<StevenK> They changed library names and grew a suffix
<pitti> StevenK: hm, good question
 * pitti accepts l-b-m and linux-meta
<pitti> StevenK: fixed, thanks; running again now
<dholbach> good morning
<Fujitsu> Hey dholbach.
<dholbach> heya Fujitsu
<StevenK> pitti: Thanks
<Fujitsu> z,cb 5
<Fujitsu> Oops.
<geser> good morning
<pitti> infinity: can you please commit your pkg-create-dbgsym changes to bzr?
<dholbach> hey seb128, hey Toadstool!
<dholbach> hey glatzor, jsgotangco!
<seb128> hello dholbach
<jsgotangco> yo!
<dholbach> :-)
 * jsgotangco currently at a domestic airport going back home
<glatzor> servus dholbach!
 * dholbach hugs y'all
<jsgotangco> ho ho ho!
<ion_> Hi dholbach et al.
<dholbach> hiya ion_ :)
<ion_> I ordered a Waldorf Micro-Q synthesizer yesterday. â¥
<dholbach> NICE
<dholbach> let me know when there are tracks I can download :)
<ion_> I havenât got pretty much any music at all made for a long time with this health, though.
<dholbach> hey blueyed_
<dholbach> ion_: I'm sure you'll come up with something soon :-)
<tjaalton> slangasek: did you notice debian bug 456915?
<ubotu> Debian bug 456915 in boost "boost: FTBFS: build.sh: line 15: gcc-4.1: command not found" [Serious,Open] http://bugs.debian.org/456915
<slangasek> tjaalton: heh, thanks for the heads-up
<ion_> dholbach: I hope so. :-)
<tjaalton> slangasek: np. What about flute-1.3-jfree that the new openoffice needs, will it be promoted to main?
<slangasek> tjaalton: not my department :)  we're trimming OOo-base from the seed for alpha2 instead in the meantime
<tjaalton> slangasek: ah, ok :)
 * Fujitsu wonders if anybody uses OOo Base.
<slangasek> I've used it in the past
<slangasek> only for ODBC :)
<tjaalton> hooray, the livecd generates a valid xorg.conf again :)
<tjaalton> bryce: ^^
<Fujitsu> tjaalton: Is input hotplug likely to deal with Synaptics touchpads sanely in the near future?
<tjaalton> Fujitsu: yes
<tjaalton> Fujitsu: synaptics was dropped from dexconf but sadly i-h is not there yet
<bryce> tjaalton: excellent
<tjaalton> hmm wait, need to double-check what actually happened
<mjg59> tjaalton: I'm planning on doing work on synaptics over Christmas
<mjg59> Upstream seem to have given up
<tjaalton> mjg59: really? that's too bad, but nice if someone still cares :)
<tjaalton> my X61 doesn't have a touchpad, and neither did the T23
<mjg59> I've a couple of patches that never got merged
<mjg59> And the input hotplug stuff needs doing
<mjg59> As does sorting out a standardised config mechanism
<tjaalton> hmm, seems that the livecd from this morning did all sort of crappy things, like ran xresprobe etc. :)
<bryce> mjg59: I also get the feeling they're not paying sufficient attention to it
<mjg59> bryce: Well, any. Last update was months ago.
<tjaalton> when do we have uptodate livecd's to test?
<bryce> alpha-2 is scheduled for towards the end of the week
<tjaalton> I know :) but surely there are prereleases before that
<bryce> don't think so - just the usual dailies
<tjaalton> but the one from this morning is actually old, uses the old kernel and xorg etc
<tjaalton> maybe because current ones don't build?
<cjwatson> tjaalton: that would be the usual reason for CDs to be old; check the build logs?
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/
<cjwatson> The following packages have unmet dependencies:
<cjwatson>   libhsqldb-java: Conflicts: openoffice.org-base (< 1:2.3.1~m8) but 1:2.3.0-1ubuntu5 is to be installed
<tjaalton> cjwatson: I guess they fail for the same reason my own build do, OOo-base is the remaining issue
<tjaalton> touchÃ© :)
<slangasek> tjaalton: xubuntu, kubuntu should have working liveCD builds by this point; ubuntu, edubuntu are waiting for that OOo seed change
<tjaalton> slangasek: ah, good point, I'll check them out
<tjaalton> hmm, kubuntu daily-live ends up in initramfs console, and xubuntu isn't published yet
<tjaalton> ah, xubuntu daily-live is now available :)
<tjaalton> ..but it fails just like kubuntu
<slangasek> hmm
<dholbach> why is gftp in main?
<superm1>  /j #ubuntu-x
<superm1> oops :)
<Spads> m/sg superm1 good luck at the parole hearing then, I guess!
<Spads> oops :)
<superm1> haha
<ion_> /msg spads I love you too, honey.
<ion_> Whoops
<tkamppeter> hi pitti
<pitti> dholbach: hysterical raisins (since warty); is there a better replacement now? or is it abandoned upstream?
<pitti> hey tkamppeter, how are you?
<tkamppeter> fine
<dholbach> pitti: it hasn't seen updates in years
<pitti> indeed
<pitti> dholbach: ideally, people would just use nautilus with ftp:// ?
<dholbach> yeah
<pitti> which actually works just fine
<dholbach> and I doubt there's many people who use it
<tkamppeter> pitti, are you working on updating CUPS to 1.3.5? Then you could also include the patch of bug 177075, the reporter has even included a debdiff.
<ubotu> Launchpad bug 177075 in cupsys "CUPS 1.3.x lists network interfaces only at startup (regression)" [Undecided,Confirmed] https://launchpad.net/bugs/177075
<pitti> tkamppeter: Kenshi updated svn trunk to 1.3.5, I'll merge it soon
<pitti> tkamppeter: right, that should just be committed to the debian svn before we merge
<pitti> tkamppeter: thanks, I'll do that soon
<pitti> tkamppeter: or, you can do it yourself if you want
<tkamppeter> pitti, I have added the patch to the trunk now. So if you merge we will have it.
<pitti> tkamppeter: thanks
<pitti> bryce: re http://www.bryceharrington.org/drupal/node/18 feature requests> why not use the blueprints tracker?
<cjwatson> sabdfl suggested that too
<StevenK> pitti: I'm just about to upload 46 source packages for fftw3-dev -> libfftw3-dev
<Riddell> tjaalton: thanks, I'm updating the seeds and meta packagees now
<StevenK> pitti: Those 46 are all the Build-Depends, so I was going to clear them out of the way and see what's left
<pitti> StevenK: great
 * StevenK throws 46 uploads at Soyuz. \o/
<StevenK> pitti: Oh, thanks for the tasks promotion
<pitti> no problem
<StevenK> pitti: There's all 46 uploaded, let's see what falls out
<pitti> pedro_: ah, thanks for forwarding my tracker bug; I didn't do it, because so far jamiemcc read the LP bugs, too :)
<pitti> StevenK: oh, that wasn't just a no-change rebild?
<pitti> StevenK: in that case, wouldn't it have been easier to add a Provides: to libfftw-dev?
<mhb> hello all, especially pitti
<pitti> hey mhb, how are you? nice to 'see' you again
<mhb> pitti: quite busy with school, exams are coming.
<pitti> oh, good luck!
<mhb> I'll find some time for the restricted-manager at the weekend (friday-sunday)
<StevenK> pitti: Unsure, I did what I thought was easiest
<pitti> mhb: ah, great (but don't let that make you fail the exams :) )
<mhb> pitti: I'll try not to... ubuntu is more fun, though :o)
 * pochu agrees with mhb
<pitti> mhb: heh; please let me know if anything in the current design is unclear; let's keep it clean and swift this time :)
<mhb> pitti: will do, thanks!
<pedro_> pitti: ah sure, no problem :-)
<gaspa> pitti: i must sorry, i had no time for usplash, still for some days.
<pitti> gaspa: no problem :)
<gaspa> pitti: for me it's a problem... I wished to see my stuff in usplash... :D
<infinity> pitti: Can (or, rather, will) do.
 * Hobbsee waves
<Mithrandir> hi Hobbsee
 * Hobbsee stomps on Mithrandir's feet, as he forgot to levitate.
<Mithrandir> I'm sitting in a chair, with my feet crosslegged, so you failed.
<Hobbsee> awww
 * Hobbsee coats Mithrandir in ice, then
<Mithrandir> mmm, ice.
 * Mithrandir whips the ice so it becomes ice cream and eats it.
<Hobbsee> heh
<sladen> think Mithrandir stole all the Ice, it was -10Â°C in Oslo when I checked and it's only ~0Â°C in Helsinki
<torkel> sladen: it's +6 in UmeÃ¥
<maswan> the tollef that stole christmas weather?
 * Hobbsee steals christmas, then.
<Mithrandir> nah, I'm innocent.
<Mithrandir> it's just cold here, no snow.
<maswan> Hobbsee: you can have it, what's the point without proper cold and snow?
<Hobbsee> Mithrandir: you're *never* innocent.
<Hobbsee> maswan: an australian christmas has point.
<Mithrandir> maswan: it's properly cold here all right, but it fails at the "snow" part.
<maswan> Hobbsee: Shorts and beachparty?
<maswan> Mithrandir: the little snow we have is failing rapidly
<sladen> torkel: haven't been to UmeÃ¥ yet, there's a ferry to try out... must swing by there some time
<maswan> Hmm.. So where does one have to move to get real winters these days? And is there any intersection of this area with the areas you have real bandwidth? :)
<Hobbsee> maswan: beaches are busy, yeah
<realist> I'm sure there's snow somewhere in Australia (an inhabited territory of Antartica perhaps?)
<Hobbsee> ther'es snow in au
<Hobbsee> just, south
<StevenK> There's Perisher and Therdbo
<maswan> Clarification: snow that doesn't become slush or melts between early december and early march
<realist> StevenK: There's still snow there during Dec?
<Mithrandir> maswan: middle of Norway seems to have snow.
<maswan> (or the equivalent months for south of equator)
<Mithrandir> about 65cm in the wild.
<maswan> Mithrandir: if you go a bit inland from the coast here you'll find snow too. there just aren't much other things than snow and trees there. ;)
<StevenK> realist: Not sure about that
<torkel> maswan: what's wrong with only trees and snow?
<Mithrandir> maswan: depending on what you call real bandwidth, you can get at least decent DSL in the middle of Norway.
<maswan> torkel: lack of bandwidth and possibly workplace. :)
<realist> StevenK: there's always ice in Antartica :-)
 * Hobbsee hibernates in antarctica.
<realist> Good luck with getting bandwidth there though.
<Hobbsee> green aliens find it quite warm.
<torkel> maswan: a shovel and an axe will keep you busy, so you don't need any bandwidth :-)
<Mithrandir> especially in -25Â°C, you'll be busy all winter.
<maswan> I'm not sure it passes the "no slush" requirement though. :/
<maswan> But I guess I'll just have to investigate some more. :)
<maswan> (or if it will in 10 or 20 years for that matter, it's changing quite rapidly)
<j1mc> good morning, all.  i've filed bugs against unintallable binaries in xubuntu (#'s 177444, 177446, & 177448), and have pinged cody somerville and lionel le folgoc - is there anyone else i should ping about this?
<Hobbsee> j1mc: they should deal with it, and poke others if they need them.
<Hobbsee> j1mc: of course, if it makes the others uninstallable, then other people will be looking into it
<j1mc> Hobbsee: thanks
<j1mc> and thanks for your reply to my email - I wasn't sure who to contact.
<Hobbsee> j1mc: but they should be taking reponsibility for their own version, particularly somerville32, as he likes to control it a lot.
<Hobbsee> (the discussions in here have suggested that, anyway)
<j1mc> ok, I'll keep that in mind.  at least the bug reports are out there now, and they are each aware of the issues.
<Hobbsee> did you subscribe them to the bug reports?
<j1mc> no, i'll go ahead and do that.
 * Hobbsee wonders why raptor is in main
<j1mc> thanks, Hobbsee ... have a good day!
<Hobbsee> oh, it's not what iw as thinking of
 * lamont yawns, waves
<Hobbsee> heya lamont
<lamont> Hobbsee: http://bld-4.mmjgroup.com/~wb/buildLogs/stats/hardy2-short.png
<lamont> note where kde et al were uploaded. :-)
<Hobbsee> lamont: nice work!
<lamont> it's nice that hppa only flattened last night, rather than down-dipping like the rest of the world
<Hobbsee> heh
 * StevenK has been pondering reinstalling his hppa as Dapper
<StevenK> Then again, it's only a 712
<lamont> http://bld-4.mmjgroup.com/~wb/buildLogs/stats/hardy2.png looks even cuter.
<lamont> StevenK: don't do it.  gutsy is the hppa-loving answer
<StevenK> But, but, it's a server!
<lamont> (as in, the hppa buildds in the data center are running a dapper userspace with a gutsy kernel because that's the kernel they need...)
<lamont> and that doesn't work well... had to hack initramfs scripts to make that kernel work with that udev et al
<lamont> very not pretty
<lamont> full-bore gutsy is much happier
<StevenK> I didn't think we released Gutsy on hppa
<StevenK> lamont: It's only a 712, so maybe it isn't worth the bother
<lamont> well, running a desktop on it would be kinda silly
<lamont> server bits aren't bad though
 * lamont briefly considers considering the advantages of breast enlargement, hits 'D'
<Hobbsee> heh
<Hobbsee> lamont: it could be a talking point.  *shrug*
<lamont> Hobbsee: I could discuss the pros and cons... then again, this is a family channel. :)
<lamont> anyway, afk for a few minutes
<Hobbsee> heh
<StevenK> libcurl4-openssl-dev: Depends: libssh2-1-dev but it is not installable
<StevenK> Bah
<pitti> StevenK: I thought we dropped that? or just the build dep?
<StevenK> pitti: That's while trying to install Build-Depends
<StevenK> The package is in main, and libssh isn't, I'm guessing
<pitti> StevenK: we dropped the build dep because we don't want it; apparently the binary dep was just forgotting
<pitti> s/ing$/en/
<StevenK> pitti: Would you like me to fix it, or will you?
<pitti> StevenK: I have a call now, can do later if you want to go to bed :)
<StevenK> pitti: Okay, thanks. If you're able when it gets published, give-back libofa
<pitti> sure
<StevenK> Ta :-)
 * StevenK runs to bed
<persia> pitti: Does all of NBS get regenerated each time you run it?  I don't understand the build timing of a pair of packages (libparmetis depending on libmpich) and don't know whether to upload a build1 to force things.
<seb128> persia: you don't need an upload to get a build retry
<persia> seb128: So I shouldn't be uploading build1 packages?
<seb128> persia: what do you need the build1 package for?
<seb128> if that's something which already built and need a rebuild you need an upload
<seb128> if that's something which didn't build yet no need to do a new upload
<persia> seb128: In the case where the current binaries in the archive depend on a library that is no longer built by the source that built it previously.
<seb128> you need a source upload in this case, ubuntu doesn't do bin-nmu uploads
<persia> seb128: In this case, it built.  Specifically, I uploaded a parmetis 3.1-4build1 for the libmpich transition last month, and then there was a sync, which rebuilt, and yet the NBS list still shows the package for i386 & amd64, which confuses me.
<seb128> ah
<seb128> persia: let me look
<persia> seb128: Thanks.
<lamont> persia: NBS?
<seb128> persia: there is a depends on "libopenmpi1 | libmpich1.0c2", maybe the | case is not handled correctly by the nbs code or something like that, better to ask to pitti about this one
<seb128> lamont: http://people.ubuntu.com/~ubuntu-archive/NBS/
<seb128> lamont: packages not built from source but which still are used by something
<lamont> ah, ok
<seb128> lamont: or that should be cleaned ;-)
<persia> lamont: An excellent target if you're bored and feel like a few uploads :)
<lamont> heh.  /me is kinda hip deep in getting ready to take 2 weeks off work
<persia> seb128: Thanks for investigating that.
<pitti> persia, seb128: re
<pitti> persia: NBS is regenerated automatically three times a day
<persia> pitti: Thanks.  When chasing those should foo | bar type dependencies be manually updated as well, or are they safe to leave?  If left, how does that impact the script?
<pitti> seb128, persia: right, it doesn't play well with |'ed deps
<pitti> persia: don't worry about the script; if the actual dependencies are correct now, we can just drop it
<pitti> s/it$/the NBS lib/
<lamont> pitti: sounds like a bug to fix, eh?
<persia> pitti: OK.  I'm not sure about all the dependent packages yet.  Is there a good way to report that a specific package is a false positive, or is that easy for you to detect?
 * lamont hates it when his code doesn't do what he meant. :-)
<pitti> lamont: one of these things which are quite hard to get right with just some dumb lines of shell :)
<pitti> persia: to be concrete, which NBS lib are we talking about?
<pitti> persia: usually I check it, see that it's fine, and remove the old package anyway
<persia> pitti: Specifically parmetis depending on libmpich1.0c2
<persia> OK.  I won't worry about them if I know they are fine then.  Thanks.
<pitti> lamont: a sensible implementation would involve DB queries, not repeatedly grep-dctrl'ing the entire set of package indices :)
<tseliot> hi, does anybody know how I can make sure that a restricted module is not loaded without using the /etc/default/linux-restricted-modules-common. The idea is that of modifying either the /sbin/lrm-video or the lrm-manager.
<Keybuk> blacklist it?
<pitti> persia: http://people.ubuntu.com/~ubuntu-archive/NBS/libmpich1.0c2 ?
<Keybuk> echo blacklist module >> /etc/modprobe.d/my-blacklist
<tseliot> Keybuk: without blacklisting it
<Keybuk> what's wrong with blacklisting it?
<persia> pitti: Yes, although I've not yet looked at illuminator (next on my list)
<lamont> pitti: so read the packages/sources into a linked list of structs once.  :-)  or query the db.. :-)
<tseliot> something like: if this file exist, don't load this module
<Keybuk> blacklisting is *how* you prevent modules from being automatically loaded
<Keybuk> if you want to do fancy checks, use an install rule
<pitti> persia: right, libparmetis3.1 is fine
<lamont> Keybuk: blacklisting will keep it from loading, but it'll still get linked. restricted-manager is the way to deal with not even linking it
<Keybuk> e.g. /etc/modprobe.d/lrm-video runs a program that will load the module or not
<tseliot> Keybuk: can't I edit the lrm-video or the lrm-check?
<Keybuk> what's wrong with linking it?
<lamont> well, if someone is silly enough to call their modified module the same name, the may not want it stomped on.
<pitti> persia: so as soon as the other rdepds are solved, I'll kill it
<Keybuk> lamont: /
<Keybuk> lamont: ?
<lamont> Keybuk: it sounded like they wanted to modify the driver... dunno
<persia> pitti: Great.  I'll let you know.
<lamont> pitti: was it you or keescook that made it so that having a null password is fatal these days>
<Keybuk> drivers in one directory can override another
<Keybuk> that's how stable driver updates work
<lamont> ah, even better.
<lamont> Keybuk: that and r-m links into a ramdisk, so it's not like it'll be overrwriting something
<pitti> lamont: might be pam 0.99? anyway, not my feature/fault/praise/blame :)
<tseliot> Keybuk, lamont: I working to integrate Envy in Ubuntu as dholbach knows
<tseliot> here's the link:
<tseliot> https://wiki.ubuntu.com/EnvyNG
<Keybuk> envy would need an LRM-a-like anyway, no?
<tseliot> Keybuk: what do you mean?
<Keybuk> well, Envy has the same problem that caused lrm to exist
<Keybuk> binary code linking to GPL code
<lamont> sigh.  and why does init=/bin/sh not work for me, i wonder.
<pitti> BenC: just reading l-r-m changelog -> this affected nvidia, too, did you bump that as well? or just reformatted the version numbers?
 * lamont blames pitti and keescook, just to be thorough.
<tseliot> Keybuk: what is not clear to me is how I can simulate what happens when the driver is blacklisted in the /etc/default/linux-restricted-modules-common
<tseliot> do you know what happens when a module is blacklisted there?
<Keybuk> yes
<Keybuk> lrm skips it
<Keybuk> read /sbin/lrm-manager, it's just a shell script
<BenC> pitti: nvidia shouldn't have been affected
<tseliot> Keybuk: yes I tried to edit it but the module wasn't skipped
<Keybuk> tseliot: probably a bug, I don't think anyone's ever used that feature before
<Keybuk> if I was going to do this, I would probably extend LRM to check whether the module existed in a different place, and if so, link that module instead
<Keybuk> e.g. if doing nvidia, check whether /lib/linux-restricted-modules/$uname/extra/nvidia exists
<Keybuk> and if it does, link that one and put that in volatile, not the one above
<tseliot> Keybuk: I'm using DKMS
<Keybuk> (or /var/cache in fact, for dkms compatibility)
<Keybuk> then pick up the module from there and link it to the kernel
<Keybuk> rather than picking up its own
<lamont> cjwatson_: as I sit here conversing with d-i, it occurs to me that when there is more than one nic, it'd be really cool in network conf (esp when netbooted) if the MAC addr were printed next to the name we chose for the interface.  or have we finally made it so that when booted from network, eth0 is always what we booted from?
<cjwatson_> related to bug 56679
<ubotu> Launchpad bug 56679 in netcfg "provide a method to use a specified MAC-address as the installation device" [Wishlist,Confirmed] https://launchpad.net/bugs/56679
<tseliot> Keybuk: do you think that I should only modify these lines?
<tseliot>   if [ "$CURRENT_MODULE_DISABLED" = "false" ]; then
<tseliot>     if type ld_static >/dev/null 2>&1; then
<tseliot>       ld_static -d -r -o /lib/modules/"$KVER"/volatile/$module.ko $module/* || true
<tseliot>     fi
<tseliot>   fi
<cjwatson> lamont: somebody needs to work on netcfg :-)
<tseliot> Keybuk: those lines belong to lrm-manager
<Keybuk> tseliot: dunno, not without looking carefully
 * lamont is reminded again that 9600 baud _S_U_C_K_S_.  and this machine is loud
<Keybuk> brb - reboot
 * lamont finishes touching the partitioner, invokes that favorite of d-i steps "let me tell you what you're gonna do..."
<lamont> ~ # mkdir /target
<lamont> ~ # mount /dev/md0 /target
<lamont> ~ # chroot /target
<lamont> feh
<lamont> it should say something after that.
<Treenaks> lamont: /bin/sh not found, maybe?
<lamont> Treenaks: that'd be consistent with init=/bin/sh failing
 * lamont pushes d-i back to the top of the hill
<lamont> yea!! back at a busybox prompt again
<lamont> well... it'd be nice to know why that's not happy.
<lamont> sed is love.
 * persia hands lamont awk
<lamont> persia: awk is love too.
<lamont> today, sed is more love.
<pitti> BenC: then it will fail again
<geser> pitti: Hi, please give-back: lua-bit lua-cgi lua-copas lua-curl lua-doc lua-expat lua-filesystem lua-graph lua-logging lua-posix lua-rings lua-soap lua-sql lua-svn lua-xmlrpc lua-zip. Thanks :)
<pitti> geser: done
<pitti> BenC: it did fail again; can you please bump the nvidia versions as well, or re-juggle the version formatting, so that it is >> the current version?
<BenC> can't understand how that could happen
<BenC> pitti: will do
<pitti> 1.0.9639 << 96.39 :)
<Keybuk> ArneGoetje: my fonts appear to have all changed recently
<Keybuk> do you know of any recent changes that could have caused that?
<pitti> BenC: I guess an epoch bump will do, we don't have to keep it in sync with Debian or so
<ArneGoetje> Keybuk: fontconfig
<Keybuk> specifically it looks like Sans and Times have become different fonts entirely
<Keybuk> what was the change?
<ArneGoetje> Keybuk: don't know yet... didn't have time to take a lok at it...
<Keybuk> fontconfig was uploaded a while ago
<BenC> pitti: right, that's all I did for fglrx
<Keybuk> the change is much more recent than that, ie. last couple of days
<Keybuk> I noticed it in epiphany, so it may be a gecko change?
<pitti> Keybuk: presumably since we switched from firefox to xulrunner?
<seb128_> Keybuk: epiphany since yesterday? that would be the switch to xulrunner1.9
<Keybuk> xulrunner?
<seb128_> Keybuk: is that a question?
<Keybuk> hmm, about:config says it's using "Times" and "Helvetica" for fonts
<Keybuk> instead of "serif" and "sans-serif"
<pitti> Keybuk: xulrunner = libgecko
<seb128_> Keybuk: if you use the xulrunner version you will have noticed, the buttons look like GTK ones on the webpage
<tjaalton> BenC: seems that you didn't use the latest l-r-m for 2.6.22 when you made .24?
<tjaalton> so fglrx diverts libGL again?
<Keybuk> seb128_: epiphany is currently held though
<Keybuk> I'm on 2.20.2-1ubuntu2
<Keybuk> (the new epiphany-gecko breaks epiphany-extensions)
<Keybuk> so I'm not on xulrunner
<seb128_> ok
<seb128_> some people don't care about epiphany-extensions and remove it apparently so I was mentioning it in case ;-)
<tjaalton> BenC: I spent quite a lot of effort for that, and asked on u-k list for comments before uploading it
<tjaalton> and got none
<tjaalton> sorry, meant the kernel-team list
<tjaalton> uh, make that u-d
<cjwatson> lamont: bet you the shell is actually there but just producing no prompt
<cjwatson> lamont: try 'id' to see if it's alive
<cjwatson> lamont: I've noticed that bug a couple of times, but not tracked it down
<tseliot> Keybuk: do you know which script calls lrm-manager?
<pitti> $ grep lrm-manager /var/lib/dpkg/info/*.postinst
<pitti> /var/lib/dpkg/info/linux-restricted-modules-2.6.22-14-generic.postinst:    lrm-manager --kver=2.6.22-14-generic
<cjwatson> also an init.d script
<cjwatson> /etc/init.d/linux-restricted-modules-common
<tseliot> I have modified the lrm-manager so that it can print the output of
<tseliot> a sentence to /var/log/envytest
<tseliot> but it doesn't do it
<tseliot> BTW /etc/init.d/linux-restricted-modules-common calls lrm-manager with
<tseliot> only the "--quick" parameter
<tseliot> therefore I just can't understand where the lrm-manager took its parameters
<tseliot> for the "for" loop (line 44) of /sbin/lrm-manager
<tseliot> any ideas?
<tseliot> or who should I bug about this?
<Keybuk> there's nobody particularly maintaining lrm right now
<tseliot> who created lrm? was it fabbione?
<tseliot> i.e. Fabio Massimo di Nitto
<tseliot> ?
<azeem> tseliot: check the changelog
<tseliot> azeem: the changelog of which package?
<tseliot> linux-restricted-modules?
<azeem> the package containing the source you're looking at, I guess
<geser> pitti: please give back: moon-buddy turbomail musixtex-slurps price.app . Thanks
<pitti> geser: done
<pitti> geser: moon-buddy doesn't exist
<azeem> moon-buggy
<pitti> ah; given-back
<tseliot> azeem: I'm not dealing with a package. I'm just looking at /sbin/lrm-manager
<azeem> and /sbin/lrm-manager is not in a package?
<tseliot> yes, I just found out it's in linux-restricted-modules
<tseliot> there are a few names which have to do with lrm-manager
<tseliot> mdz: do you know anything about this?
<thegodfather> tseliot: i didn't touch lrm in ages..
<thegodfather> tseliot: at least one year or so
<thegodfather> it might have undergone plenty of changes
<tseliot> thegodfather: can you see if you know what happens in lrm-manager (line 44), please?
<thegodfather> tseliot: version?
<thegodfather> what version...
<tseliot> on gutsy
<ogra> for module in *; do ... blah .... ;done
<tseliot> ogra: right
<ogra> tseliot, thats like ls
<thegodfather> tseliot: what's not clear about it?
<ogra> it wlks over all the files in the dir
<ogra> *walks
<thegodfather> that reads like: for all files in that dir do;... ; done
<tseliot> yes, I know but where does it take its $* ?
<tseliot> so that it can check whether $1 is "nv", etc.
<tseliot> ?
<tseliot> another script must provide such parameters
<tseliot> but /etc/init.d/linux-restricted-modules-common seems to pass lrm-manager
<warp10> Hi all!
<tseliot> only "--quick"
<tseliot> thegodfather, ogra: I hope it's clear what my doubt is.
<tseliot> the rest of the script is quite clear (case, shift, etc.)
<tseliot> any ideas?
<thegodfather> tseliot: i am still downloading the source
<tseliot> thanks, I'll wait
<thegodfather> tseliot:   set -- $DISABLED_MODULES
<thegodfather> this is the command that sets the new $@
<thegodfather> so $1 would be the first module in DISABLED_MODULES list
<thegodfather> etc.
<thegodfather> this is basic bash operation
<thegodfather> s/bash/shell
<tseliot> and where is DISABLED_MODULES?
<thegodfather>   . /etc/default/linux-restricted-modules-common
<thegodfather> sourced from there
<tseliot> ok, I see
<tseliot> and what does line 72 do?
<thegodfather> tseliot: sorry but you are really asking basic shell stuff.. it's not related to this channel
<thegodfather> did you find a bug in the script?
<thegodfather> or something you are trying to debug?
<tseliot> thegodfather: I'll tell you what I'm trying to do
<tseliot> I would like to make sure that a module from the lrm is not loaded
<thegodfather> tseliot: specify that module in /etc/default/linux-restricted-modules-common
<thegodfather> that's all you need to do
<tseliot> without actually putting such module in the /etc/default/linux-restricted-modules-common
<tseliot> for example, if a certain file exists then the module won't be loaded
<cjwatson> 'if [ -f /path/to/file ]; then DISABLED_MODULES="$DISABLED_MODULES nv"; fi' after sourcing /etc/default/blah
<cjwatson> would do it
<tseliot> cjwatson: thank you very much
<tseliot> and thanks to all of you for your time
<cjwatson> line 72> 'help type'
<cjwatson> actually, 'man bash' and look for the section on the type builtin, since that tells you the relevant fact about its exit status
<tseliot> cjwatson: I'll RTFM ;)
<Riddell> might any python exports know why this doesn't work? "return str.__cmp__ (other.get_reason (), self.get_reason ())"
<MaximLevitsky> Small question, is the usplash still the default system for kubuntu/ubuntu, is the uswsusp beeng now the default, is a conflict between usplash and uswsusp fixed?
<ogra> Riddell, the spaces in front of teh brackets  ?
<Mithrandir> MaximLevitsky: there's no conflict between usplash and uswsusp?
<MaximLevitsky> Thre is , (at least here on kubuntu fiesty)
<Mithrandir> MaximLevitsky: it's better in 7.10
<MaximLevitsky> System fails to resume (hangs) if usplash is active
<Riddell> ogra: no, the test case is 'str.__cmp__("hi", "low")'
<MaximLevitsky> And I know that this is connected to vt switching race
<Mithrandir> MaximLevitsky: does it work if you press alt-sysrq k after a little bit?
<MaximLevitsky> Mithrandir, just clears the screen
<Mithrandir> MaximLevitsky: hm, that makes it resume happily for me.
<Mithrandir> it's a kernel bug, really.
<cjwatson> Riddell: str doesn't have a __cmp__; objects don't need __cmp__ if the rich comparison operators are defined
<cjwatson> http://docs.python.org/ref/customization.html
<cjwatson> when you call str.__cmp__() I think you actually get the __cmp__ method on the str class object which is totally not what you want
<cjwatson> (which is why it expects 1 argument rather than 2)
<cjwatson> why not just return cmp (other.get_reason (), self.get_reason ()) ?
<cjwatson> (or munge those into strings in advance if you need to
<cjwatson> )
<Riddell> cjwatson: well its comparing strings so __lt__ seems like a good substitute
<cjwatson> __cmp__ is a three-way comparison, __lt__ isn't
<cjwatson> does get_reason return a string?
<cjwatson> if so, cmp is the right substitute IMO
<cjwatson> you shouldn't really be calling __cmp__, __lt__, etc. directly
<cjwatson> as in __lt__ (foo, bar) is an overcomplicated way to write foo < bar
<Riddell> cjwatson: yes it returns strings
<Riddell> < also works fine
<Riddell> tkamppeter: do you know where system-config-printer svn is these days?
<fetova> greetings :)
<fetova> i wanna ask for help...
<fetova> i wanna develop a gui of "reportbug" written in python
<fetova> can someone give advices or links for a book can help me?
<tseliot> cjwatson: If I launch lrm-manager the hack you suggested seems to work but it doesn't work at boot
<tseliot> for example something like this:
<tseliot> if [ -f /etc/default/envy-dkms ]; then
<tseliot>   DISABLED_MODULES="$DISABLED_MODULES nv"
<tseliot>   echo "nvidia">/etc/default/envytest
<tseliot> creates a /etc/default/envytest file only if I type "sudo lmr-manager --quick"
<tseliot> but, since lrm-manager is executed at boot it is weird that it doesn't work
<tseliot> and that this file is not created
<tkamppeter> Riddell. system-config-printer SVN has recently moved. It is now at svn.fedoraproject.org/svn/system-config-printer/trunk A web interface for the SVN is currently not available.
<tkamppeter> Riddell, what did you change on s-c-p to make it working under Kubuntu? Did you pass all GTK to Qt? Or can Kubuntu ship GTK apps?
<tkamppeter> Riddell, I think we should whenever possible have only one s-c-p package in the distro, which works on all flavors: Ubuntu, Kubuntu. Xubuntu, Edubuntu.
<tkamppeter> Riddell, did you contact Tim Waugh and talked with him about your work on s-c-p?
<Riddell> tkamppeter: so far I've ported the applet to Qt, there's a lot of duplicated code
<Riddell> tkamppeter: I have contacted Tim Waugh but he doesn't seem too keen to have me work in his repository which would be the way to avoid much of the duplicated code
<Riddell> (and to keep it all in one package)
<tkamppeter> Riddell, is Qt really necessary? Does Kubuntu ship libgtk? Or not?
<Riddell> tkamppeter: no, we don't use gtk
<tkamppeter> Riddell, so a whole distro Qt-based, which means that all config tools are different to Ubuntu?
<Riddell> tkamppeter: yep, same as ubuntu won't ship with hplip config tools since they use Qt
<Riddell> tkamppeter: and of course in many places its only different backends, much of the code is shared
<Riddell> but that seems to be something new to Fedora
<tkamppeter> Riddell, Fedora is an install-only distro on one DVD or 3-4 CDs, so they ship aÃ§ways both desktops (where GNOME is their preferred one). So they never had to think about providing one and the same app with two GUI frontends. AFAIR they have even a theme which makes GTK and Qt apps look the same.
<Riddell> tkamppeter: the newest fedora release also have 1 CD "spins" for gnome and for KDE.  the KDE one has to include a bunch of gtk apps which takes up a notable amount of space
<Riddell> so I'm hoping I can persuade him it'll help fedora too :)
<tkamppeter> Riddell, perhaps he could modularize the printing/CUPS magic and the GUI. Then you could write an additional GUI module. Perhaps he would host this structure upstream with the Qt part written by you.
<Riddell> tkamppeter: yes, that would be nice, but it needs tim waugh to let me work in his svn repository
<tkamppeter> If you can persuade him that a dual GUI will facilitate RH live CDs, but problems are probably that it will only help if all config tools get dual-GUI (needs a lot of man power) and that he has perhaps to do also Qt stuff when adding features or fixing bugs ...
<lamont> Dec 19 06:25:33 j6700 udevd[2653]: add_to_rules: unknown key 'RUN{ignore_error}' in /etc/udev/rules.d/80-drivers.rules:5
<lamont> ew
<lamont> oops.
<lamont> Package: *
<lamont> Pin: release a=hardy
<lamont> Pin-Priority: 500
<lamont> how did that get to be 500, I wonder... :(
 * lamont downgrades udev
 * lamont runs the machine back down to gutsy, downgrading 193 packages.
<keescook> hm, did gnome-gpg stopi working for anyone else?
 * slangasek wonders if keescook has been spending a little too much quality time with gdb
<keescook> hehe
<lamont> keescook: I just use the regular gpg. :-)
<keescook> I do too now, it seems.  :P
<lamont> heh. gnupg-agent + pinentry-gtk(?) is love
<EvanCarroll> will the recently released perl 5.10 make gutsy+1
<EvanCarroll> (just today)
<lamont> pinentry-curses is not so much love.
<pawalls> join #ubuntu
<keescook> lamont: where do you config the pinentry bits?
<keescook> (i just get a gui prompt if I add 'use-agent' to my options.
<Mithrandir> gpg-agent with --enable-ssh-support is even better. :-)
<geser> and having a OpenPGP card is even more fun :)
<Mithrandir> or two! :-)
<geser> keescook: afaik it uses /usr/bin/pinentry which points in the end to /usr/bin/pinentry-gtk-2 here
<lamont> keescook: uh... that's configurable??? :-)
<keescook> lamont: dunno, I didn't have pinentry-gtk installed, and it worked the same.  :P
<lamont> ah, ok.  with pinentry-curses, I had wierdness
<keescook> In the past, gnome-gpg would cause the gnome-keyring goo to prompt.  now it says "Couldn't search keyring (code 9)"  :P
<lamont> mind you, I haven't checked in on it since sometime in feisty(?).
<slangasek> keescook: is that related to gnome-keyring not accepting ssh-add?
<keescook> slangasek: I did notice some hiccups there too, but I always forced gnome-keyring to ignore ssh, so I'm not sure what the "right" behavior is.
<slangasek> how do you force gnome-keyring to ignore ssh?
<slangasek> because if it were ignoring it properly, at least then I could theoretically get ssh-agent to start
<keescook> slangasek: I just always clicked "Cancel" ;)
<slangasek> oh :P
<keescook> then ran ssh-add
<keescook> and it'd stop prompting
<slangasek> the problem here is, gnome-keyring exports SSH_AUTH_SOCK and then can't actually accept keys via ssh-add
<slangasek> so because SSH_AUTH_SOCK is exported, ssh-agent doesn't start
<stgraber> slangasek: I just have a : unset SSH_AUTH_SOCK in my .bashrc, works fine :) (I would really like to have a better way to turn off the ssh part though :))
<slangasek> stgraber: well, this is a new failure mode for me
<pawalls> Anyone on irc.canonical.com mind pinging pkl for me?
<tormod> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410095
<ubotu> Debian bug 410095 in xscreensaver "xscreensaver: Provide .desktop files for gnome-screensaver" [Wishlist,Open]
 * tormod wonders why that popped up - hyperactive touchpad probably...
<somerville32> slangasek, ping
#ubuntu-devel 2007-12-20
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down in at approx 01:00 UTC for a code update. Estimated downtime is approx 120 mins | Archive: Self-Imposed Freeze for Hardy Alpha 2 | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for h
<slangasek> somerville32: pong
<somerville32> mthaddon, you totally cut the topic off :P
<mthaddon> oops
<mthaddon> that's one enormous topic...
<somerville32> slangasek, Would you be willing to sponsor ubuntu-wallpapers?
<somerville32> I know this isn't the best time but kwwii would like it for Alpha 2
<slangasek> er, no, I'm kinda busy trying to get working CDs, sorry
<crimsun> somerville32: debdiff/url?
<somerville32> Oh, hey crimsun
<somerville32> crimsun, We use bazaar to manage the package, is there any fancy was you can do something with that or do I need to give you a standard debdiff?
<crimsun> somerville32: I can bzr branch.  Is there a specific one?
<somerville32> I'll provide you the link
<somerville32> crimsun, https://code.edge.launchpad.net/~ubuntu-art-pkg/ubuntu-wallpapers/ubuntu
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down in at approx 02:00 UTC for a code update. Estimated downtime is approx 120 mins | Archive: Self-Imposed Freeze for Hardy Alpha 2 | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for h
* somerville32 changed the topic of #ubuntu-devel to: Archive: Self-Imposed Freeze for Hardy Alpha 2 | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Launchpad Downtime Scheduled: 0200 UTC
<TheMuso> somerville32: WHy did you change the topic back
<somerville32> TheMuso, I didn't
<somerville32> :)
<TheMuso> somerville32: You did, you removed the lanuchpad downtime message.
<somerville32> TheMuso, No, I really didn't, lol
<TheMuso> launchpad
<somerville32> TheMuso, Unless my client is acting up, it is just at the end now
<TheMuso> Oh sorry didn't see that.
<somerville32> No problem.
<somerville32> TheMuso, I've updated ubuntu-artwork
<TheMuso> But thats something I don't agree with.
<TheMuso> Because, not all clients show the whole topic, and not everyone is likely to type /t or /topic every time they have a look in here.
<somerville32> Why?
<somerville32> Ah
<TheMuso> I'm using irssi in gnome-terminal at a high res, and even then I don't see the whole topic.
* somerville32 changed the topic of #ubuntu-devel to: Archive: Self-Imposed Freeze for Hardy Alpha 2 | Launchpad Downtime Scheduled: 0200 UTC | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<somerville32> better? :)
<lamont> TheMuso: that's where moving the mouse over the topic line in xchat is love.
<TheMuso> lamont: Good for you and your GUI client.
<lamont> or /topic, of course
<lamont> just don't type any garbage on the line...
<TheMuso> somerville32: Yes, it is.
<somerville32> TheMuso, On to more pressing matters, I've updated ubuntu-wallpapers package
<TheMuso> somerville32: I saw.
<somerville32> crimsun uploaded it but I fear it got rejected or lp has stopped processing uploads in lieu of the downtime or something
<TheMuso> Well 2:00 UTC is not for another half an hour or so.
<somerville32> crimsun, I think it got rejected.
<TheMuso> Unless you made an error in writing the topic.
<crimsun> somerville32: I have not received a REJECTED e-mail
<TheMuso> There doesn't seem to be any mail from lp atm. I just did a bzr branch change that I am subscribed to, and have received no mail for it either.
<somerville32> mthaddon, ^^
<mthaddon> somerville32, yeah, that's right - been turned off in anticipation of the rollout - will be sent after the rollout is complete
<mthaddon> TheMuso, ^
<somerville32> mthaddon, So the package was most likely rejected and the e-mail hasn't been sent out?
<crimsun> no, it has been queued.
<StevenK> mthaddon: I'm in the middle of a 25Mb upload, that'll get processed after the 1.12 rollout?
<crimsun> (after a few releases, you'll get the hang of interpreting "where's the ACCEPTED?")
<mthaddon> StevenK, I believe so, yes
<somerville32> Heya bddebian
<bddebian> Hi somerville32
<bluszcz> hello
<bluszcz> i am creating just dapper custom cd with new kernel, i create all di packages
<bluszcz> but i don't know how to create initrd for di kernel
<bluszcz> update-initramfs -c should be fine?
<bluszcz> anyone?
<Burgundavia> bluszcz: given it is near the holidays and after US workday and in European night...
<bluszcz> Burgundavia: i am on my holidays
<bluszcz> unfortunately i have to work
<bluszcz> i need to prepare special dapper cd on tomorrow morning
<bluszcz> (3:10AM here)
<TheMuso> bluszcz: Are you creating a custom live CD, or a custom alternate CD?
<bluszcz> TheMuso: server
<TheMuso> Ok. In order to use your new kernel, you nee to rebuild the debian-installer package, and modify it to use your own kernel.
<TheMuso> bluszcz: Without digging myself, I couldn't tell you how exactly its done, but you need to download the debian-installer source package, unpack it, make the changes to use your kernel, and then rebuild it.
<TheMuso> This will generate a .tar.gz file that will have the new initrd file you need.
<bluszcz> TheMuso: i made it
<bluszcz> i got all udeb modules packages
<bluszcz> but i don't see initrd.gz file
<TheMuso> How did you make it?
<bluszcz> ow, you are talking about debian-installer
<bluszcz> i only create modules *udeb
<bluszcz> ok, i am going try rebuild debian-installer
<bluszcz> thanks for the hint
<bluszcz> debian/rules binary after change will be fine?
<TheMuso> bluszcz: dpkg-buildpackage -rfakeroot is how you build it.
<TheMuso> YOu also need to ensure you have it's build dependencies installed.
<bluszcz> apt-get build-dep
<TheMuso> Yes.
<bluszcz> Package glibc-pic is a virtual package provided by: libc6-pic 2.3.6-0ubuntu20.5
<bluszcz> You should explicitly select one to install.
<bluszcz> E: Package glibc-pic has no installation candidate
<bluszcz> huh
<TheMuso> What choices do you have?
<bluszcz> i don't understand your question, sorry
<TheMuso> Well, it says that there is no installation candidate for glibc-pic. It should give you a list of possible packages that are similar to that one.
<bluszcz> Package glibc-pic is a virtual package provided by: libc6-pic 2.3.6-0ubuntu20.5
<bluszcz> apt-get install
<TheMuso> without knowing what choices there are, I don't know.
<bluszcz> ok, now i am reading about doc/custom kernel
<Hobbsee_> so, uh...
<LongPointyStick> ...wow
<ajmitch> yes?
<Hobbsee> apparently i *do* have wifi
<ajmitch> that's good
 * Hobbsee saw it magically switch to wifi, as the wired connection dropped out
<bluszcz> wifi is weird
<Hobbsee> however....the wifi light *still* *isnt* *on*
<ajmitch> the light shouldn't matter
<Hobbsee> well, i thought it'd decided the kill switch was on
<Hobbsee> but this is true.  others say it works
<ajmitch> iirc I have led=1 set as an option for the ipw220 module
<ajmitch> sometimes (rarely) I've had to toggle the kill switch from windows
 * Hobbsee wonders how you set teh led option
<ajmitch> in /etc/modprobe.d/options, though that has probably changed since then
 * bluszcz fakeroot make build_cdrom_isolinux
<bluszcz> on my linksys main error led is always red
<bluszcz> but hw works fine, weeird
<bluszcz> and two weeks ago some script kiddie 'hacked' my router ;)
<slangasek> ok, what
<slangasek> who broke /dev/cdrom in the ISOs?
<StevenK> ajmitch: My wireless LED works without that options
<slangasek> Keybuk: awoooga
<StevenK> s/ns/n/
<ajmitch> StevenK: this option has been set since before dapper release & I haven't bothered to change what's working
<StevenK> Ah, right
<Keybuk> slangasek: ?
<slangasek> Keybuk: all the hardy2 CDs I'm testing come up with /dev/scd0 and not /dev/cdrom, looks like it might be a regression introduced with the new upstream udev?
<slangasek> s/hardy2/alpha2/
<jdstrand> cd ../no
<Keybuk> what version of udev is on them?
<jdstrand> uhh... wrong terminal
<slangasek> Keybuk: cjwatson did a d-i rebuild within the past three days, so should be 117-2 AFAIK; looking to confirm
<slangasek> (and hmm, what happened to the "ubuntu" in the udev version numbers?
<slangasek> )
<Keybuk> I dropped it
<Keybuk> we're not derived from Debian there, and 0ubuntu kept tripping me up with things
<bddebian> likely story.. ;-)
<blueyed> BenC: nvidia-glx-new should provide "xserver-xorg-video-2" instead of "xserver-xorg-video", correct? Currently is conflicts with xserver-xorg-core. (s/xserver-xorg-video/xserver-xorg-video-2/ in debian/control)
<Keybuk> slangasek: ack or nak?
<slangasek> Keybuk: regarding the version on the disk? trying to figure out how to confirm that without LP available
<Keybuk> do you not have a booted CD? :)
<Keybuk> I guessed you did since you noticed /dev/cdrom wasn't there
<slangasek> Keybuk: how do I get a version number from there?
<slangasek> hmm, I suppose that's recorded in dpkg/status
<Keybuk> dpkg-query -W udev :-)
<slangasek> udev-udeb, rather. :)
<StevenK> blueyed: Does nvidia work with the new -xorg-core?
<slangasek> Keybuk: yeah, udev-udeb 117-2 is on the alternates
<blueyed> StevenK: not tried yet. I'm looking at manipulating the .deb (instead of rebuilding l-r-m).
<blueyed> StevenK: I've seen it for 2.6.22, so I suppose it should do it for 2.6.24, too.
<StevenK> It looks okay for me ...
<StevenK> Just trying it in a Hardy chroot
<TheMuso> /c
<TheMuso> ugh
<blueyed> StevenK: the dependencies look ok for you?
<blueyed> with 2.6.24?
<StevenK> blueyed: 'apt-get install nvidia-glx-new' sorted it out
<Keybuk> oh, hmm
<Keybuk> udev-udeb
<StevenK> This is in a chroot, no kernel. It dragged in 2.6.22
<Keybuk> slangasek: back up a bit
<Keybuk> what's wrong?
<Keybuk> be more specific
<Keybuk> ie. where is /dev/cdrom missing
<blueyed> StevenK: I guess you still have 2.6.22 then.. yes, different story.
<Keybuk> on the desktop CD inside casper/initramfs, or after boot
<Keybuk> or is it on the live cd, but not on the installed image
<blueyed> BenC: nvidia-glx-new-Provides appears to be OK for 2.6.22, but not 2.6.24.
<Keybuk> or is it missing on the alternate while the installer is running, but on the installed system
<StevenK> blueyed: But nvidia-glx-new doesn't need to be updated
<Keybuk> etc.
<slangasek> Keybuk: "alternate CD"
<Keybuk> slangasek: alternate CD inside the installer?
<slangasek> yes
<Keybuk> we've never had /dev/cdrom there
<Keybuk> what's trying to use it?
<StevenK> blueyed: I thought nvidia-glx-new Provided the xserver-xorg bits, not the lrm bits.
<StevenK> blueyed: Can you dig more?
<blueyed> bug 177575
<StevenK> ENOLP
<slangasek> Keybuk: well, ok; the exact error message is "No common CD-ROM drive was detected"
<slangasek> Keybuk: let me dig into d-i then to see what it's looking for
<Keybuk> slangasek: that's far more likely "udevinfo: command not found" :)
<slangasek> hrm, ok
<Keybuk> I've just realised that I never touched the installer
<Keybuk> I grepped all the diff.gzs in the archive for using udevinfo, udevtrigger, udevsettle, etc.
<Keybuk> but the installer would be inside .tar.gz wouldn't it
<StevenK> Keybuk: Right, being native
<slangasek> sure
<StevenK> Which also means you missed native packages
<Keybuk> right
<Keybuk> so that's the problem then
<StevenK> So, how do you grep a tarball? :-P
<StevenK> blueyed: Right, I see what's going on, I think
<Keybuk> don't suppose you know which bit of the installer does that?
<StevenK> My chroot doesn't have 2.6.24 stuff, which is odd
<slangasek> Keybuk: debian-installer-utils
<blueyed> StevenK: the packages in l-r-m must provide "xserver-xorg-video-2" instead of "xserver-xorg-video". Pretty sure.
<blueyed> StevenK: yes, the deps for 2.6.24 are not really in place yet.
<StevenK> blueyed: Mmmm. You're going to have to rebuild lrm, though
 * Hobbsee is fairly sure he's right, from dealing with the intel variety a month or so ago
<Keybuk> StevenK: hmm
 * StevenK grabs a .deb from a.u.c, in leiu of LP
<Keybuk> slangasek: hmm
<Keybuk> Colin usually doesn't like it when I change installer code in a non-backwards-compatible way
<blueyed> StevenK: no, you can extract a .deb (using dpkg-deb -x/-e), edit the control files, then repack (dpkg-deb -b). Works.
<slangasek> Keybuk: can you brain-dump me what's supposed to happen here instead of udevinfo?
<StevenK> Keybuk: Was that aimed at me, or were you aiming at slangasek?
<Keybuk> slangasek: udevadm info
<StevenK> blueyed: But, ew
<StevenK> Keybuk: Why does it need to change? if [ -x /usr/bin/udevinfo ];  ?
<Keybuk> because that doesn't exist in the udeb
<Keybuk> it's /sbin/udevadm now
<StevenK> But it used to exist, so if it exists, you do what it usually does, else test for /sbin/udevadm?
<StevenK> If I'm actually making sense.
<slangasek> right, so to avoid backwards-incompatibility, check for /sbin/udevadm first and fall back to udevinfo
<Keybuk> yeah, that code is a bit trickier to modify if you read it
 * slangasek watches the clock and glances at LP
<StevenK> Keybuk: Right, it's not me being wrong, it's the code being hard. :-)
<Keybuk> slangasek: I'm guessing this problem is somewhat urgent?
<slangasek> Keybuk: only if we /want/ alpha2 released before break ;)
<Keybuk> I can upload a udev package to work around the problem for now
<slangasek> Keybuk: I think I can manage the d-i-utils side if you'd rather, now that we've pinpointed the problem
<Keybuk> slangasek: if you're happy to do that, that's good too
<slangasek> given that it's more correct but not much more work, yeah
<slangasek> does udevadm info have the same syntax as udevinfo did?
<Keybuk> yup
<slangasek> ok
<Keybuk> all the tools got merged together to make the installed size much smaller
<Keybuk> since they were 90% the same code
<Keybuk> so udevtrigger is udevadm trigger, udevsettle is udevadm settle, etc.
<slangasek> then as soon as LP is back up to where it'll let me branch d-i-utils, I'll take care of that
<slangasek> heh, right :)
<Keybuk> Kay likes to change things ;)
<Keybuk> oh, and there's at least one release note
<Keybuk> there's a new wireless card driver that won't work properly
<Keybuk> it's the one that makes a "wmaster" interface, I forget which
<Keybuk> Colin has one ;-)
<Keybuk> slangasek: meh
 * slangasek notes that di-utils has no dependency on udev-udeb at all, that's clever
<slangasek> meh?
<Keybuk> I can see about half a dozen packages that use udevinfo directly
<slangasek> within d-i?
<Keybuk> grub-installer, partman-basicfilesystems, partman-target, ubiquity (!!)
<slangasek> nice
<Keybuk> the udev upload will take less time ;)
<slangasek> yeah, please go ahead then
<Keybuk> (udevinfo can exist as a symlink to adm, and it will work -- I just didn't put any of those in the udeb or initramfs)
<slangasek> sure
 * Keybuk fights debhelper
<Keybuk> debhelper attacks
 * Keybuk dies
<slangasek> hmm, that's interesting, the scheduled LP downtime moved from 1am to 2am?
<Fujitsu> It did.
<Fujitsu> And it was extended by 30 minutes.
<slangasek> it was? http://news.launchpad.net/maintenance doesn't mention any extension
<Keybuk> (loss of -0ubuntu ... I got sick of uploading accidentally native packages or forgetting the orig.tar.gz)
<slangasek> but ok, that does mean they're only 15 minutes late. :)
<Fujitsu> See topics of here and #launchpad.
<slangasek> yes, the topic here says it was moved, not that it was extended...
<Fujitsu> `Estimated downtime is approx 120 mins'
<slangasek> and where do you see that in the topic here?
<Fujitsu> Oh, I see a shorter one was used here. Oops.
<TheMuso> Yes.
 * TheMuso glares at somerville32.
<Keybuk> slangasek: ok, udev 117-3 uploaded
 * Fujitsu wonders how it is uploaded without LP.
<wasabi> so this has been kicking my ass for awhile now......  apt-get runs dpkg.... and when dpkg exits, apt-get locks up
<wasabi> Looks like dpkg is defunct.
<wasabi> cept it only does it when I don't remember to attach something to it. =/
 * Hobbsee wonders when tjaalton will be interested in tracking regressions on the intel drivers
<bluszcz> guys
<bluszcz> i found weird problem
<bluszcz> i built udebs in a https://help.ubuntu.com/community/Kernel/Compile way
<bluszcz> but i don't have cdrom udeb
<bluszcz> when i dig into modules/ i found, that there is no cdrom file
<bluszcz> why?
<bluszcz> i cannot rebuild debian-installer without cdrom, from second way - update-initramfs withot cdrom create initrd without cd module
<bluszcz> i can make my own file modules/cdrom with sr_mod and cdrom entry
<bluszcz> but it will be fine?
<bluszcz> i mean enough?
<bluszcz> and what is easiest way to build udebs?
<slangasek> Keybuk: cheers
<slangasek> ah, and LP is back, hurray
 * Keybuk goes back to drawing stick figures
<slangasek> hmm, is "20070308ubuntu23build1" the desired version number for a rebuild-only upload of d-i? :)
<Keybuk> 20070308ubuntu23build1+but+really+20070307ubuntu22build4
<Hobbsee> oof
 * Hobbsee wonders what teh longest version number accepted actually *is*
<slangasek> compiz | 1:0.6.2+git20071119-0ubuntu1~gutsy1
<slangasek> there's a good candidate if you're looking for the longest in existence
<Hobbsee> slangasek: i liked the xserver-xorg-input-synaptics ones for a while
<Keybuk> Hobbsee: the firefox but-really one I think
<minghua_> slangasek: I've always seen rebuilds of -ubuntuX just use -ubuntu(X+1) version numbers.
<slangasek> fair enough
* mthaddon changed the topic of #ubuntu-devel to: Archive: Self-Imposed Freeze for Hardy Alpha 2 | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Hobbsee> slangasek: 0.14.3+revertedto+0.13.6-0ubuntu1... and then 0.14.3+seriouslythistime-0ubuntu1
<slangasek> and sensible too :)
<Keybuk> 1.5.dfsg+1.5.0.12+sg1.8.1.5~prepatch070716-0ubuntu1
<Hobbsee> Keybuk: nice...
<Hobbsee> Keybuk: qt had a but-really too, iirc
<Keybuk> the trouble with insane version numbers is you can justify every single part of them
<Fujitsu> !info mplayer dapper
<ubotu> mplayer: The Ultimate Movie Player For Linux. In component multiverse, is extra. Version 2:0.99+1.0pre7try2+cvs20060117-0ubuntu8.1 (dapper), package size 3265 kB, installed size 7916 kB
<bluszcz> anyone can help me with creating custom kernel for installer?
<bluszcz> i tried with http://wiki.debian.org/DebianInstaller/Modify/CustomKernel, but it tells me that i have'nt got cdrom-core-modules
<nanley>  /#ubuntu
<nanley>  /join #ubuntu
 * lamont waves, heads to bed.
<bluszcz> is there any good howto about creating bootable cd with custom kernel?
<TheMuso> c/c
<TheMuso> ugh
<TheMuso> go go orca
<bluszcz> TheMuso: ayt?
<dholbach> good morning
<bluszcz> morning
<dholbach> hey bluszcz
<bluszcz> dholbach: have you experience in building debian installer kernel?
<dholbach> bluszcz: not at all - I'd expect people who are more knowledgeable in #ubuntu-kernel
<bluszcz> hm, anyone debian installer?
<bluszcz> i've created dapper server install with new kernel 2.6.22, but installer shouts "lack of kernel modules"
<dholbach> bluszcz: you could also try the mailing list
<dholbach> did you try #ubuntu-kernel?
<bluszcz> i've just try
<dholbach> so best try the mailing list
<warp10> Hi all!
<bluszcz> hello warp10
<warp10> bluszcz: yo!
<somerville32> warp10, You are now known as: transwarp
<warp10> somerville32: yep! I'm everywhere in the universe... and multiverse too :P
<somerville32> hi5
<warp10> :D
<pitti> Good morning
<somerville32> Morning
<warp10> morning pitti
<pitti> hey warp10
<pitti> warp10: sorry, haven't forgotten your mail, will get to it
<warp10> pitti: np, take your time :)
 * pitti sighs at iwl3945; free or not, it doesn't work :/
<dholbach> hey pitti, hey MacSlow
 * pitti hugs dholbach and macd
<pitti> and MacSlow, too
<MacSlow> hey dholbach, pitti
<MacSlow> *yawnÂ²*
<dholbach> :-)
 * dholbach hugs y'all back
 * pitti files bug 177624; anyone else who has a 3945 wifi and suffers from this?
<ubotu> Launchpad bug 177624 in linux "iwl3945 has very poor signal reception, whereas ipw3945 works perfectly" [Undecided,New] https://launchpad.net/bugs/177624
<geser> good morning
<pitti> hi geser
<geser> Hi pitti
<Usiu> Hi
<Usiu> Where I can get Ubuntu installer with latest xorg intel driver. The one included in gutsy 7.10 is buggy for some intel cards and cause black screen. On Debian I was using old one precompiled for new API. Now its fixed in debian and current git, but older one is a bit faster.
<Usiu> I would like to know if there are any ubuntu snapshots with updated packages, or maybe new xorg intel driver ?
<posingaspopular> hey all, im wondering if someone in here knew where which directory the C header files for the gcc 4.1.3 compiler are stored in kubuntu gutsy
<cjwatson> posingaspopular: /usr/lib/gcc/i486-linux-gnu/4.1/include (depending on architecture), but do you really want the compiler-specific headers rather than just using the system default /usr/include?
<posingaspopular> cjwatson: i don't. vmware does.
<posingaspopular> on an x86 arch.
<cjwatson> err, never has for me
<slangasek> vmware asks for the location of the kernel headers, not the compiler headers.
<cjwatson> do you have libc6-dev installed?
<cjwatson> oh, yeah, what slangasek said too
<posingaspopular> it's asking for which the matching dir in 2.6.17-12-generic kernel
<posingaspopular> ah yea i knew i had the question wrong
<cjwatson> install the linux-headers package corresponding to whatever linux-image package you have, and run 'dpkg -L' on it after installation
<cjwatson> once you have it installed, though, vmware should find it automatically
<cjwatson> (so linux-headers-2.6.17-12-generic is probably the one you want)
<posingaspopular> ah i see. this is where i should give up, because i have the 2.6.22-14 headers installed and that's why virtualbox hated me so much
<posingaspopular> so installing vmware wouldn't actually sort the problem out. hmm
<cjwatson> why not just install the right headers/
<cjwatson> ?
<cjwatson> they coexist ...
<posingaspopular> because apt can't find them ;p
<posingaspopular> that's where my life has been for the past 5 night
<posingaspopular> it's very exciting
<posingaspopular> well it has 'no instillation candidate'
<pitti> lool: great merging work on gtkmm & friends!
 * pitti hugs lool
<cjwatson> posingaspopular: exactly what package name are you installing, and which release of Ubuntu are you using?
<cjwatson> (I'm assuming 6.10, so 'edgy' should be in your /etc/apt/sources.list)
<posingaspopular> i *think* it's commented out of the repos
<cjwatson> and what does 'uname -a' say?
<posingaspopular> im on gutsy (kubuntu) trying to install vmware-server
<posingaspopular> 2.6.17-12-generic
<posingaspopular> uname -r ^
<cjwatson> so how come you're using edgy's kernel on gutsy?
<slangasek> which is not the gutsy kernel
<posingaspopular> um afaik, i upgraded from edgy to feisty to gutsy
<posingaspopular> however, ls_release -a tells me im running gutsy
<slangasek> without ever rebooting, then?
<cjwatson> you may well be otherwise, but your kernel is out of date
<posingaspopular> i have no idea why my computer is doing this
<cjwatson> install the 'linux' package
<posingaspopular> because i have rebboted many times
<posingaspopular> sudo apt-get install linux?
<cjwatson> you didn't really complete the upgrade process, even though it may have seemed as if you did
<cjwatson> yes
<cjwatson> if you had used the release upgrade tool, then it should have taken care of this for you
<cjwatson> if you did it by hand with apt, then you may need to do some things yourself
<posingaspopular> i did one upgrade with adept (to feisty) and one via CLI
<pitti> posingaspopular: your default selection in the grub boot menu might be wrong then :)
<posingaspopular> that's most likely. however this grub selection is the only one that boots...
<posingaspopular> which might have something to do with the kernels being all out of sync
<posingaspopular> okay thanks all!
 * posingaspopular heads off with answers and some understanding for a change ;p
<soren> I'm working on the new libvirt version. It's started to use PolicyKit, and my polkit-fu isn't strong..  It's using polkit to accept/reject users' access to a unix socket. How is this usually accomplished? Does the socket usually have 0777 permissions and the polkit will take care to approve or reject the user *after* the connection has been established, or are the sockets usually root/root owned and 0700 and then polkit will determine ahead of time
<soren> I'm guessing the former...
<pitti> tjaalton: FYI, current alternate install in vmware still has the wrong resolution; I do have an xorg.conf now, but it's totally empty
<pitti> soren: if the socket is 0777, there's little point in faking access control to it in the UI?
<soren> pitti: Did I mention my polkit-fu isn't strong? :)
<tjaalton> pitti: hrm.. could you post your /var/log/casper.log somewhere?
<soren> I was thinking that after you connected, some polkit magic would happen out-of-band that would end up either accepting or rejecting the connection.
<Mithrandir> I thought that was how policykit worked.
<Mithrandir> basically the app would say "yo, you're not authed, go auth yourself!", then it'd wait for pk to ack the auth before going ahead.
<pitti> soren: ah, so PK doesn't control access to the socket, the socket talks to the service which then uses PK to verify privs?
<soren> pitti: That's what I'm asking, basically. The docs are not very precise, so I'm trying to work out how this is *usually* done.
<Keybuk> usually anyone can send a request to you
<Keybuk> and you reply with an error indicating not auth'd, and hinting what kind of auth they need
<Keybuk> the client responds to the error by running the auth helper, and then tries again
<Kmos> pitti: can you give back nip2 on sparc (hardy) ?
<pitti> Kmos: done
<Kmos> pitti: thanks
<tjaalton> pitti: err, I meant /var/log/installer/casper.log
<tjaalton> duh
<tjaalton> alternate install -> no casper.log :)
<pitti> right
<pitti> Kmos: nothign to give back, it's built everywhere
<soren> Keybuk: Ok, so translating that to my scenario: Any can open a connection to the UNIX socket? and then polkit works out the policy details out-of-band, correct?
<Kmos> pitti: it says on LP: hardy sparc   Failed to build
<pitti> Source version: 7.12.5-2ubuntu1
<pitti> sparc: Successfully built
<pitti> Kmos: maybe you look at an old version?
<tjaalton> pitti: well, let's try /var/log/installer/syslog instead
<Kmos> pitti: yep, it's changed..
<Kmos> sorry
<Keybuk> soren: as I understand it, yup
<soren> Keybuk: Cool. Thanks.
<Keybuk> otherwise how would it connect?
<Keybuk> you'd have to have an ACL on the socket, and some kind of "I auth'd, now change the permissions" notification
<Keybuk> and then you'd need some kind of un-change the permissions as well
<Keybuk> which would make "auth once" harder, etc.
<Mithrandir> Keybuk: it could auth to policykit which would then pass the fd back to the process requesting access.
<Mithrandir> so you'd go "policykit, I want to talk to food", then policykit goes "you need to solve a math question for me then; what's sqrt(2+2)?", "uh, 2?" "here's your fd which is connected to food".
<Keybuk> Mithrandir: that would require policykit being a process
<Keybuk> and that process would have to have access to your X session to ask these questions
<Keybuk> and that process would have to be privileged in lots of different ways to pass back the fds, etc.
<soren> Keybuk: I'm not sure. I thought polkit had a privileged process that i might be able to use to pass through data or something.
<Keybuk> no
<Mithrandir> Keybuk: yes, it'd have some ramifications for the rest of the system.  And the app would be the one responsible for asking the question, not policykit.
<Mithrandir> Keybuk: it'd be a similar design to pam, really.
<Keybuk> you could do that *with* PAM :-)
<pitti> soren: the only long-standing PK process is the daemon that maintains the db (user -> privs mapping)
<cjwatson> pitti: re tjaalton's question, installing with DEBCONF_DEBUG=developer on the kernel command line might produce more useful information
<Keybuk> pitti: isn't that a dbus service, so it's not long-standing?
<pitti> cjwatson: ah, it will land in syslog then?
<pitti> Keybuk: ah, indeed, mixed that up with ConsoleKit
<pitti> ConfusionKit
<ion_> :-D
<Keybuk> just wait until DeviceKit comes along
<bluszcz> confusion or illusion
<Mithrandir> KitCatKit
<soren> Ok... /me is starting to grok policykit
<ion_> Letâs rename Linux as KernelKit.
<pitti> Keybuk: I still need a name for the rewritten restricted-manager without 'restricted' in the name; I seriously considered 'DriverKit' :)
<pitti> (for about 2.5 seconds)
<bluszcz> pitti: Bad2TheBoneK1t
<cjwatson> pitti: yes
<Keybuk> WhereAreYouKit
<Keybuk> NeedYouNowBuddy
<ion_> KITTKit
<maswan> Kitty!
* pitti changed the topic of #ubuntu-devel to: Archive: Self-Imposed Freeze for Hardy Alpha 2 | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs" | HELP TESTING: https://iso.qa.stgraber.org
<pitti> alternates should be good now, desktops rebuilding (hopefully working now)
<tjaalton> l-r-m needs to fix the nvidia/fglrx Provides
 * Hobbsee waves
<pitti> tjaalton: doing another test install with DEBCONF_DEBUG now
 * Hobbsee wonders what the 8heck8 has happened.
<tjaalton> pitti: thanks. I noticed that I have vmware-server installed myself, so will test that myself too
<pitti> tjaalton: I'll attach the log to the bug I filed previously, ok?
<tjaalton> pitti: sure
<soren> Hobbsee: ?
 * Hobbsee appears to have no shift, tab, or capslock
<soren> Hobbsee: Cat took them?
<Hobbsee> or escape
<StevenK> Ah, hence the '8heck8'
<Hobbsee> i don't know.  was working fine before1
<Hobbsee> wait.  tab works, alt doesnt'
<pitti> Hobbsee: sometimes happened to me when using vmware
<pitti> a 'setxkbmap us' fixed it again
<Hobbsee> pitti: hrm. then restart x, or/
<pitti> no, just that
<tjaalton> damn, the 3G connection is faster than my ADSL.. should use that for cd images :P
<pitti> restarting X would help, too, of course
<pitti> Hobbsee: i. e. it killed the 'outside' gnome's shift when vmware was running
<tjaalton> does anyone know what it takes to integrate wvdial with network-manager?
<Usiu> Hi
<Usiu> how to update packages on ubuntu live cd ?
<Hobbsee> YAY!!!!
<Hobbsee> tjaalton: btw, when will you be interested in tracking regressions for this intel driver?
<soren> This channel is not for support. #ubuntu is what you want.
<Hobbsee> Usiu: #ubuntu for support
<tjaalton> Hobbsee: when they concern the 965GM I have? :)
<Hobbsee> tjaalton: oh, i thought you cared about all of them.  got it.
<tjaalton> hehe
<Hobbsee> pity
<tjaalton> actually, bryce is working more closely with intel bugs
<Hobbsee> ah right
<Hobbsee> BenC: i lie.  my wifi does work.
<tjaalton> Hobbsee: what this time?-)
<Hobbsee> tjaalton: just slow to refresh
<tjaalton> EXA goodness
<Hobbsee> tjaalton: nothing new...but more people will start testing
<Hobbsee> yeah.  if slow == good, then..
<pitti> tjaalton: n-m> I was told that 0.7 supported modems now?
<tjaalton> pitti: oh good
<tjaalton> bbl
<Hobbsee> TheMuso: about time, too!
<StevenK> Heh
<Keybuk> pitti, MacSlow: pre-ping
<StevenK> pitti: curl uploaded
<soren> Ok, policykit experts. When I try to do something I'm allowed to, but haven't authenticated to do yet, what's supposed to happen? Currently, I just get a "please go away" from the app, and it terminates (it's a cli). If I "polkit-grant --gain blahblah", give my password, and then try again, it works.
<soren> Is it the job of the application itself to do the magic required, or does libvirt have some built in mechanisms for acquiring the privileges required?
<pitti> tjaalton: I attached the installer syslog to bug 172821
<ubotu> Launchpad bug 172821 in xorg-server "[hardy] only get 800x600 in vmware" [Undecided,New] https://launchpad.net/bugs/172821
<soren> Continuing the flow of policykit questions: I'm curious why policykit _configuration_ is under /usr/share ?   How does that make sense?
<pitti> soren: the app needs to invoke a dbus call to spawn the gnome/kde policykit auth dialog itself
<pitti> soren: look at gnome-mount for an example
<pitti> soren: i. e. normally you just get "NOAUTH" (denied, but you can authenticate as admin)
<soren> pitti: Oh, it's just a dbus call? Cool.
<pitti> then you invoke the auth frontend, and if you type in the correct auth, the PK DB will then know that you have the token and return "YES" for the privileged op
<soren> pitti: I see.
<pitti> soren: too hard for the dbus backend to poke a hole back to your X session
<soren> pitti: Hmm... I suppose.
<soren> pitti: Ok, this sounds useful to know, but it doesn't seem like the right workflow here, though. I think I just want to allow access to a particular group, no questions asked.
<soren> ...which seems to be simple enough, but I feel dirty putting configuration stuff in /usr/share.
<pitti> soren: (I don't know what your goal is)
<soren> pitti: :) Sure.
<pitti> soren: right, group-based access isn't too evil either
<pitti> slangasek, BenC: I filed bug 177666 about the unionfs oops which kills the desktop CDs
<ubotu> Launchpad bug 177666 in linux "desktop CD boot hangs eternally; kernel oops in unionfs_create()" [High,New] https://launchpad.net/bugs/177666
 * soren kicks policykit... hard
<soren> pitti: Well, group-based access might not be evil.. Another thing it's not is "supported".
<soren> pitti: The <match> directive supports two attributes: action and user.
<soren> I think that concludes my policykit adventure for now.
<Keybuk> which group?
<soren> Not "admin".
<Keybuk> you could always patch PK to add group-based matching
<Keybuk> why "not admin" ?
<Keybuk> that's hard to authenticate to
<Keybuk> though PK in theory is supposed to do away with group-based matching
<soren> WEll, because it can grant access based on whether or not you're in "admin".
<Keybuk> how do you mean?
<soren> Er... Ok, I'll try again..
<soren> I wanted to grant access based on membership of the "libvirt" group.
<Keybuk> right, but that's the kind of group that PK is supposed to make no longer necessary, isn't it? :)
<soren> Er.... it might be?
<Keybuk> the idea of PK is that you do:
<Keybuk>   "can I access this device?"
<Keybuk>   "no, enter your password"
<Keybuk>   "ok, now can I access this device?"
<Keybuk>   "yes"
<soren> Well, every user has a password? How do I limit access then?
 * soren is missing something obvious, it seems
<Keybuk> well, the RH model assumes a root password
<Keybuk> so for "secure" things
<Keybuk>   "no, enter the root password"
<Keybuk> we would probably want to extend that to recognise the admin group
<Keybuk> so if you're in admin, it could respond "no, enter your password"
<soren> That's already done, afaics.
<Keybuk> and if you're not, it could respond "no."
<Keybuk> (or "no, enter the root password" if it's set)
<Keybuk> that way, the access is granted for you
<Keybuk> and you had access to add yourself to the group *anyway*
<Keybuk> so this bypasses the requirement for pre-authorising yourself to use something
<soren> Well, I want a different set of users to have access to this.. How would I accomplish that in a policykity way?
<Keybuk> authorisation can be permanent
<Keybuk> you can use PK to add "this user can always use this device" to its db
<Keybuk> this bit of PK replaces the groups admin tab
<soren> ergh...
<soren> So if I have this sort of thing in ldap, I'm screwed?
<Keybuk> "this sort of thing" being?
<soren> I don't, but I could have.
<soren> Well, if I used to grant access to stuff based on group membership..
<soren> I'd have that info stored in ldap. With policykit, I'd have to log into every machine, do some "getent group foo | while read ...." magic, etc?
<Keybuk> errr?
<Keybuk> why?
<Keybuk> http://people.freedesktop.org/~david/Screenshot-Grant.png
<soren> How else would I be granting the privilege?
<Keybuk> I don't see any reason that PK couldn't use ldap for its auth db as well
<soren> Ok, I'll explain the scenario, I'm working with here..
<stgraber> asac: around ?
<asac> stgraber: yes
<soren> libvirt allows a user to connect to a running qemu or kvm instance. Up until now, this access has been granted by membership of a group (which owned a certain UNIX socket). If I have a cluster of machines running virtual machines, and I want to give a particular user access to the libvirtd instance on every node in the cluster... How would I do this now that policykit is doing the authorisation?
<soren> This might all be very clear to me if the clients actually supported policykit properly. Right now, they just tell me to sod off, if I haven't polkit-grant'ed beforehand.
<Keybuk> well
<Keybuk> ok
<Keybuk> so you have a permission
<Keybuk> "Access to running virtualisation instance"
<soren> Right.
<Keybuk> you abstract this permission with a group, "libvirt"
<soren> Right.
<Keybuk> so you assume that members of this group have this permission
<Keybuk> and you enforce this with privilege
<Keybuk> e.g. only members of the group can write to a file, or members of the group can execute a binary
<soren> Right.
<stgraber> asac: I just switched from 2.6.22 to 2.6.24 and my wireless interface is now called "wlan0_rename", this happened with the switch from ipw3945 to iwl3945. Is there any known work around for that (not that I don't like to type this long name but I would prefer something shorter) ? Do you know of an open bug or shall I file one (against udev ?) ?
<Hobbsee> stgraber: do you get a LED for your wifi nwo?
<Keybuk> stgraber: known bug
<stgraber> Hobbsee: what do you mean ?
<Keybuk> soren: the problem here is that the number of permissions is very large
<Keybuk> and the number of groups a user is limited to is much smaller
<Keybuk> so we tend to lump them into large super-groups
<Hobbsee> stgraber: a flashing light, showing that your wifi is active, and hwo much data it's sending?
<Keybuk> "plugdev"
<Keybuk> "admin"
<Keybuk> etc.
<soren> Keybuk: Uh huh..
<Keybuk> the other problem is that for more complicated permissions, the application may need to keep the privilege
<Keybuk> so you have a privileged application running inside an X session
<stgraber> Hobbsee: On my laptop I just have a static LED just showing that my wireless is powered up
<Pici> stgraber: but that works for you?
<Keybuk> PK attempts to solve these
<Keybuk> permissions become first class
 * soren is still waiting for the epiphany to hit him
<Keybuk> you aren't "a member of admin"
<stgraber> yes, but I don't think it's driver related here as even with iwl3945 unloaded it's still on
<Keybuk> you have "permission to change the system timezone"
<soren> Keybuk: How did I get that?
<Hobbsee> stgraber: ah, right.  strange.
<Keybuk> permissions can also be abstract, rather than specific matches
<Keybuk> groups only allow "these users"
<Keybuk> permissions can have default grants based on meta
<Keybuk> ie. "all users a local console have permission to use local devices"
<Keybuk> "soren has permission to change the system timezone if he is on the local console"
<Keybuk> etc.
<soren> Keybuk: Ah, yes. The local-users-are-trustworthy thing.
<soren> Keybuk: Ok.
<Keybuk> these are done by entries in the authorisation db
<Keybuk> consider the PK auth db a souped up version of the groups file
<Keybuk> it says who can do what
<Keybuk> if you don't have permission, it's possible to authorise again to get it
<Keybuk> (if the permission allows that)
<soren> Ok.
<Keybuk> so you might have permission if you enter your password
<Keybuk> or the password of the root user
<soren> Makes sense.
<Keybuk> first time you get no, you run a helper to pop up the auth dialog, second time you get yes
<Keybuk> and that permission can be one-shot, per session or forever
<Keybuk> you can also do speculative requests
<tjaalton> pitti: I'm afraid the log isn't helpful, but I'll try to install it myself now to see where it fails
<Keybuk> like changing the timzone
<Keybuk> the dialog can show the timezone always
<Keybuk> and since you always have permission to change YOUR timezone, it can let you set that
<Keybuk> it can make a speculative request to PK to determine whether you have permission to change the SYSTEM timezone
<Keybuk> if it gets "no", it just lets you set yours
<Keybuk> if it gets "no, auth first", it can show the disabled "set system timezone too" button with a lock next to it - clicking the lock will make you auth, and undisable the button
<Keybuk> if it gets "yes", the button is enabled
<soren> Again assuming that users-at-the-console-are-not-evil ?
<Keybuk> sure
<Keybuk> you can add any assume you want
<Keybuk> that's the idea
<pitti> soren: users-at-the-console-can-be-as-evil-as-they-like
<Keybuk> if there was a permission grant for users at the console, they would see the button always
<soren> Keybuk: No, I mean..
<soren> er..
<soren> It seems to me that if you're not at the console, you're not granted access to much at all.
<Keybuk> that's just defaults
<soren> If you're at the console, all you have to do is be able to type your password, and the world is at your feet.
<Keybuk> consider PK permissions as ACLs
<Keybuk> the ACL can have a reasonable default
<Keybuk> it just happens that many of those defaults are "local console after entering password"
<Keybuk> you can set the default for any permission to whatever you like
<Keybuk> it can be default to everyone, and you can deny certain users
<soren> Ok... I think that's a pretty crappy default, but ok.
<Keybuk> it can be default off, with users explicity added
<maswan> soren: Makes for a resonable default for a personal [home] desktop, for large scale deployment you'd probably want a different policy set
<Keybuk> default PER permission
<Keybuk> there's no "system default"
<soren> Keybuk: Sure.
<Keybuk> ie. if you add a new permission, the default is "no access"
<Keybuk> and for most things, default being console user after password makes sense
<Keybuk> it's their laptop
<soren> Keybuk: Or someone else's.
<Keybuk> depends on what the permission is
<soren> They might just have gotten a login on it.
<Keybuk> accessing usb devices etc.
<lamont> Keybuk: can grant "users in the group 'foo' may change the timezone"?
<soren> Surely, there's a reason we don't make adduser automatically add every new user to "admin"?
<lamont> that would make it easier to integrate PK in a multi-platform environment
<Keybuk> lamont: why would you?
<lamont> my Solaris box doesn't have PK yet, but all the machines share a user/group map in NIS
<lamont> e.g.
<Keybuk> so just use NIS
<Keybuk> if you have groups, you don't need to use PK
<soren> Aha!
<Keybuk> why attempt to use both systems at the same time
<lamont> one reason would be because a distro forced it on me.
<Keybuk> ?
<lamont> another would be because it's shiny
<Keybuk> if you're interested in PK, drop the group and port to PK
<lamont> ok.  makes sense from that perspective
<lamont> though allowing groups to be granted perms would possibly help transition.
<soren> Keybuk: Ok.. Help me out here.. Let's say I'm the admin of this cluster for machines running a stack of kvm instances and I want to grant a set of users access to manage those... In the brave new world of policykit... How do I do that?
<maswan> Keybuk: Hm.. How would you restrict permissions to an arbitraty subset of console users? Like me and my sister knows what we're doing, but the rest of the family shouldn't be able to mess up too badly?
<lamont> or allow shortcutting, by using the group as nothing more than (uh) "a group of similar users"
<lamont> soren: it sounds like you do it with "for user in .....; do ..."
<soren> lamont: That's what I suggested 20 minutes ago, and I was met with a stack of question marks.
<pitti> maswan: don't give them admin?
<lamont> soren: right.  groups have nothing to do with permissions other than allowing you to specify one token for a group of users. (in a _GROSSLY_ oversimplified version of reality)
<lamont> pitti: "local console users can..."
<Keybuk> soren: you grant the permission
<maswan> pitti: admin is just a group membership, PK does away with all group memberships (AFAICT)
<lamont> now add in maswan's cousin who comes to visit, and he wants to say "everything I can do, let him do too"
<pitti> lamont: right, but if you have a privilege you don't want to grant to local console users, then just grant it to admins
<Keybuk> maswan: "you can do it if you're on the console", "your system can do it if you're on the console"
<soren> Keybuk: To each user on each system?
<pitti> i. e. it does not make sense to restrict shutting down the system to admins
<Keybuk> soren: or you write a PK LDAP backend and make it read your LDAP db
<pitti> since if you are on the console, you just press teh power button
<soren> Keybuk: Ok.
<pitti> but it does make sense to restrict creating new users or changing TZ to admins
<lamont> soren: and then you put your groups in the PK LDAP db. -)
<pitti> maswan: no, admin is still relevant in Ubuntu
<soren> lamont: Exactly. :)
<lamont> pitti: _ALL_ groups die in Keybuk's PK world.
<pitti> lamont: hm, not in hardy at least
<lamont>  /etc/group becomes an empty file
<Keybuk> no, you need admin
<Keybuk> since admin is our alternate for root
<lamont> Keybuk: so let me say 'group admin' in granting PK privs
<maswan> I don't quite see why all groups should die, just the audio/usb/video/blah/blah.
<pitti> later we might change Ubuntu to define admins in terms of PK policies instead of admin members, but right now that's the status quo
<Keybuk> lamont: I think you should be able to
<pitti> lamont: right, system groups/users make perfect sense and should stay
<lamont> then why are we arguing?
<soren> Keybuk: Why not just put that into /etc/PolicyKit/PolicyKit.conf?
<Keybuk> but you should avoid adding a permission group and granting to it
<lamont> ah, so no new groups, just the grandfathered ones?
<pitti> lamont: we'll get rid of some that we can better express with PK privileges, too
<pitti> lamont: like, plugdev, cdrom, audio
<Keybuk> not even just the grandfathered ones
<Keybuk> just the sensible ones
<lamont> Keybuk: as defined by who? the sysadmin?
<soren> Who is allowed to grant privileges and who's not could be in the PK config, too? That would do away with /etc/groups completely.
<Keybuk> lamont: THE DISTRO
<Keybuk> oops
<pitti> soren: you still need /etc/groups for the system groups
<soren> pitti: Like what?
<Keybuk> admin, groups for daemons
<maswan> I still see a need (with larger usersets) to have groups as _groups_, where they are set of users. It would be useful if PK could have policy decisions on those too, instead of having huge lists of users listed there too
<soren> Oh, that's deemed out-of-scope for policykit?
<soren> Keybuk: Well, admin could in theory be maintained directly in pk's config.
<Keybuk> right, a daemon running as a group to reduce its privilege is fine
<pitti> soren: dhcp, syslog, ssl-cert, messagebus, hal,
<maswan> But I guess the PK.conf could have some #include statements for lists of users or so
<Keybuk> soren: only if you made sudo use PK :)
<Keybuk> maswan: agree it should be able to check groups of users
<soren> Keybuk: Sure.
<pitti> soren: we should get rid of the groups which define privs for users, but not the ones which separate away the processes of daemons
<soren> pitti: Hm... Right.
<stgraber> and what about the groups for directory access ? we still need those too (like www-data) no ?
<lamont> Keybuk: so i'm an admin of a group of machines at a university, and I install your distro.  I need to grant specific permissions to a group of people who will be using certain resources on the computer.  how do I know whether to add them to a new group, or to use PK?
<pitti> stgraber: right
<pitti> lamont: usually you only fiddle with groups like admin
<soren> Well, that's just until IOKit comes along.
<pitti> lamont: AFAICS, PK privs are not usually granted by sysadmins for users
<soren> Then you politely ask IOKit to return a list of files in a directory or to open a file an hand you the fd or something.
<pitti> since they mostly describe dynamic actions, like changing the network in nm-applet or mounting an USB stick
<lamont> ok.  so it's in a different realm of things then.
<Keybuk> lamont: you use PK
<Keybuk> pitti: sure they are?
<pitti> Keybuk: eventually, I agree, but not in Hardy
<pitti> but with the current PK version you usually don't
<lamont> pitti: I wasn't talking about hardy... I was talking about keybuk's distro where everything has migrated to his endgame.
<Keybuk> right
 * Keybuk is talking about Ubuntu 10.04+
<pitti> ah, ok; misunderstood that then
<pitti> Keybuk: you're planning ahead well :)
<Keybuk> yes
<lamont> 10.06. :)
 * Keybuk is actually, quite seriously, doing 10.04 planning
<Keybuk> I can't decide what codename to use <g>
<Keybuk> lamont: you expect it to be late?
 * pitti counts
<Keybuk> pitti: I liked "Ubuntu Odyssey" because it's 2010
<Keybuk> but then I realised that the ship in 2010 was the Leonov
<pitti> it's "L", isn't it?
<Keybuk> and that begins with "L"
<lamont> Keybuk: nah... 10.03 if you must... it's just convenient when LTS != *.{04,10}
<Keybuk> lamont: hardy is 8.04 LTS
<lamont> yeah
 * lamont just isn't sure how to encode 'LTS' as a number. :)
<Keybuk> 1+5
<soren> Ok, disregarding what we're doing in Hardy, what we'll be doing in hardy+x.. Do you guys really consider granting administrative privileges to any user at the console (provided he remembers his password) as sensible default security policy?
<lamont> ==6.  see! :)
<pitti> lamont: easy: $ echo LTS | od -h :)
<lamont> soren: admin privs, no.  access to sound/display/etc? sure.
<pitti> soren: no, not really
<soren> Ok. Good!
<pitti> soren: not as long as we still have systems with multiseats and physically protected computers (where you can't just press the power button, etc.)
<soren> You had me going for a second there..
<pitti> for most computers out there you are root, since they don't have physical protection
<pitti> but if you use encrypted disks, and/or physical hardening, then the notion of an admin can be enforced
<pitti> or, rather, *not* being one :)
<Keybuk> multiseat -> ConsoleKit :-)
<soren> I really, really don't agree with that.
<pitti> soren: the great thing about PK is right now that you can dynamically grant certain aspects of root where it makes sense (network-manager, USB mount, etc.) through a consistent system rather than through endless suid root wrappers
<Keybuk> (which provides PK with info)
<pitti> soren: you don't agree with enforcing non-admin privs through encryption/physical security?
<soren> pitti: Sure.
<soren> pitti: Not as the only measure, no.
<pitti> soren: maybe I didn't express myself correctly
<soren> pitti: I've seen on TV that the type of lock I have on my front door can be picked in < 2s if you know how and got the right tools. I still lock my door at night.
<pitti> soren: if I walk to your desktop and you didn't put a big iron lock on it, then I am root on this machine
<pitti> soren: that's physical security
<soren> pitti: Not without me noticing it.
<soren> pitti: I also don't leave a root prompt open and no screensaver when I lave a machine.
<Keybuk> reboot, init=/bin/bash
<pitti> soren: as long as I can reboot, I win
<pitti> soren: unless you encrypted your disks, as I said
<Keybuk> or since you've broken into the house, you can just take the computer out with you
<soren> I know.
<soren> And since the lock on my door can be picked, I might as well put my laptop outside the door with a root prompt open?
<cjwatson> Keybuk: 'h' + 4 == 'l' - don't see a problem with that for 10.04
<pitti> so, I was just saying that, while physical access is usually root, there are means to defend against this, and thus we shuold keep a difference between admins and mere-mortal users forever
<pitti> soren: no? who was claiming that?
<Keybuk> cjwatson: "that" being?
<cjwatson> Keybuk: Leonov
<soren> pitti: Well, you. By extension.
<Keybuk> :-)
<pitti> soren: hm, I said exactly the opposite
<soren> pitti: Since they can break in easily, and just snatch the machine anyway, why even bother locking?
<soren> pitti: Assume no encryption. Just for the sake of the argument.
<pitti> soren: well, most humans still have some sort of conscience/respect/call it what you want to not do that :)
<pitti> and we have laws, polices, etc.
<soren> pitti: You're saying that if you can get within arm's length of my box (no encryption), you're root on it.
<pitti> soren: but e. g. since (I assume) you don't question your wife getting around in the house, your wife has root on your box regardless of whether you decide to put her into 'admin'
<Keybuk> soren: also bear in mind that if you had to type your password for every single operation it would
<pitti> soren: right, exactly
<Keybuk>  a) drive you nuts
<Keybuk>  b) get you so used to typing it, you'd be vulnerable to phishing attacks
<soren> pitti: Then why don't we leave a root shell open on one of the ttys?
<Keybuk>  c) make you more vulnerable to snooping
<Keybuk> etc.
<pitti> soren: you just as well can, it doesn't matter
<soren> pitti: We could make tty6 always be a perpetually logged in root shell.
<Keybuk> it's about finding a balance between the two
<pitti> soren: right, it wouldn't make a difference security-wise
<Keybuk> everything as root <----------------------------------> auth for everything
<pitti> soren: if you boot into rescue mode, you get exactly that
<Keybuk> we try and be somewhere in the middle
<soren> pitti: Yes, but you have to reboot.... At the very least,someone will notice.
<pitti> soren: in fact, if people would use that instead of using sudo under X you actually increase your defences against local trojans
<pitti> soren: notice> depends on how thorough you are, but sure; but once you do, the damage is done already
<soren> pitti: I'm perfectly aware that anyone who get within arm's length of me could stab me, but I don't walk around handing out knives.
<pitti> but usually you trust the people you share your house with, so that shouldn't be auch an issue
<pitti> and at least in our university, the computers had some physical protection
<pitti> and the servers with the actually interesting bits were quite heavily stored and locked away
<pitti> so you just have to add more physical protection the less you trust the people who can access it
<pitti> soren: hm, I think I have lost what we are actually discussing about
<soren> Ok. Do you agree that it's very likely that your machine undiscovered security bugs somewhere?
<wasabi> What we really need is AppArmor for everything. ;)
<wasabi> Oh, we have it!
<pitti> soren: yes, I do agree
<soren> pitti: Well, in that case, I have root on your box regardless. You might as well hand it over?
<pitti> soren: you are a core-dev; upload a new coreutils or something else I have installed and you got me
<soren> pitti: No? Why not? Because it shouldn't be any easier than absolutely necessary?
<soren> pitti: bah
<Keybuk> it also shouldn't be harder than absolutely necessary
<Keybuk> no?
<pitti> soren: that's why we don't grant core-dev to everyone :)
<pitti> soren: while I trust you to not 0wn everyone's box out there, that's not true for everyone on the world
<soren> Keybuk: Point beig?
<soren> being?
<Keybuk> soren: same as yours
<Keybuk> you're afraid of making it too easy
<Keybuk> I'm afraid of making it too hard
<soren> For malicous users to root my machine?
<Keybuk> if it's too easy to gain admin privs, we lose
<Keybuk> if it's too hard to gain admin privs, we also lose
<pitti> as I said, I think I lost the original topic of what we are discussing
<Keybuk> if I have to enter my password just to change wireless network, I'm going to be very grumpy ;)
<Keybuk> or to use the digital camera *I just plugged in* :-)
<soren> pitti: We're discussing whether it's sensible to hand a root shell to any user who has physical access to a machine.
<pitti> soren: I disagree in that generality
<pitti> you?
<soren> pitti: Then what have you been arguing for the last fifteen minutes?
<pitti> soren: I said that you have root IF you don't use encryption or physical security
<pitti> and I have explained that for a lot of cases this condition is not true (like in my university or my laptop)
<pitti> but on my desktop it's true, for example
<pitti> everyone who walks into my room can 0wn my desktop
<soren> pitti: Do you leave a root shell open on that?
<soren> pitti: If not, why not?
<pitti> soren: you have a good chance that sudo has a ticket, yes
<pitti> soren: I don't because usually I prefer sudo because it's more comfortable
<pitti> but indeed before I used sudo I did have a root shell open on my desktop
<pitti> just because I need it very often
<soren> pitti: And you left in unlocked an unattended for anyone to use?
<pitti> soren: yes, because I trust my wife
<Keybuk> my desktop at home isn't locked either
<Keybuk> it has a screensaver for the pretty pictures
<pitti> if some thief steals my desktop, the presence or absence of a root shell is insignificant
<Keybuk> but if you shake the mouse, it goes away
<Keybuk> I don't see a point in it being locked, it's my computer
<Keybuk> likewise, it'll have a gpg and ssh agent, etc. with my keys loaded
<pitti> for the same reason I don't lock my fridge
<Keybuk> and likely a root shell, or at least a sudo ticket
<pitti> because at home I can be sure that nobody will put poison into my milk
<soren> pitti: You're assuming the anyone who might root your box is also a thief.
<pitti> (I lock my front door for that)
<pitti> soren: no, I'm not?
<pitti> soren: if my wife wants to sabotage my desktop, she can do without me noticing
<pitti> (well, assuming that she knew how to do that :) )
<pitti> 'security through ignorance' :)
<pitti> soren: so, what do you want to actually say?
<soren> I'm contesting that because anyone can do X anyway, there's not point in making it hard at all.
<pitti> I agree to the conclusion, but I disagree that anyone can get physical access to your box
<soren> Ok, rephrasing: I'm contesting that because someone can do X anyway, there's not point in making it hard at all.
<Keybuk> soren: depends what X is, no?
<soren> Apart from the moral implications and such, why is the conclusion different for X = "get a root shell", X = "stab me"?
<cjwatson> you might not notice that somebody has got a root shell
<soren> Both are things I really want to avoid.
<Keybuk> why is the conclusion the same for X = "get a root shell" and X = "change the wireless network" ?
<soren> For that reason I a) don't leave a root shell open on my machine for anyone (who happens to be in my vicinity) to use and b) don't hand out knives to random passers-by.
<soren> cjwatson: If they did it by rebooting my machine, I think I'd notice.
<cjwatson> soren: sure, but that's just one path
<cjwatson> (you might not, if you had left your machine at a gdm prompt)
<soren> cjwatson: Indeed, but it's the very path that's been presented here as the arugment.
<cjwatson> and with sufficient session management, you might even not notice a reboot if they took care to log back in as you when they were done
<Keybuk> pitti is arguing at a much more moderate level than that
<Keybuk> (you don't need to reboot)
<Keybuk> you just hibernate it, and then boot with different options to avoid the resume
<Keybuk> fuck around
<Keybuk> then resume :-)
<Keybuk> sorry, I may have slipped into evil mode there
<soren> Think servers..
<Keybuk> a "Muahahahaha!" may be in order, or possibly a goatee
<soren> People might be connected to them and notice if it suddenly goes missing.
<Keybuk> not if you're quick
<soren> I'm not.
<soren> So there.
<Keybuk> won't look much different to any net burp
<Keybuk> pop into the DC, hibernate the server, fiddle, unhibernate
<Keybuk> could do it in a smaller window than TCP timeouts
<soren> Yes, because those are two weeks long.
<soren> ...or thereabouts.
 * persia once knew an admin who typically rebooted the sendmail server when the queue jammed, and it booted quickly enough that the users didn't notice.  This was 10+ years ago, and machines are faster now.
<soren> persia: smtp is not a very interactive service..
<persia> soren: Well, not any more.  Used to be more so (before local mail queues were common).  Point being that a reboot can take less time than calling support.
<seb128> Keybuk: did you not bump the fontconfig shlibs version on purpose when you added the lcd filter changes?
<soren> You are all arguing why it might be possible to not notice anyone rooting your box.
<soren> I find it more interesting that it might actually be possible to notice it.
<Keybuk> seb128: err, no
<pitti> soren: those are two different questions, too
<pitti> soren: fiddling with your box vs. fiddling with your box without you noticing
<Keybuk> I may have not bumped it through incompetance ;)
<seb128> Keybuk: I'm wondering if that's worth changing the shlibs or if updating the libcairo requirement is enough
<Keybuk> ah no
<Keybuk> I think I did think about it
<seb128> theorically the shlibs should be updated I think
<Keybuk> and didn't bother since there wasn't a library change
<Keybuk> the API and ABI remain the same
<Keybuk> the only difference is in the xsettings, no?
<Keybuk> and packages using it work either way
<Keybuk> (I may have been wrong)
<seb128> right
<seb128> ok, let's bump the libcairo requirements then
<seb128> I like that better than updating the shlibs ;-)
<soren> pitti: I've got a real-life appointment in about an hour and I've got a stack of stuff to do before then. We can shout at each other another time, shall we?
<pitti> soren: heh :) and let's involve beer into that discussion
<pitti> I'm off to the xmas fair soon, too
<pitti> just want to test Ben's shiny new unionfs.ko
<tjaalton> pitti: ok, vmware problem reproduced here. even reconfiguring xserver-xorg didn't help
<pitti> yay
<tjaalton> pitti: touchÃ© :)
<tjaalton> it's not just vmware, this should affect every installation
<tjaalton> "RET=10 xserver-xorg/config/display/modes doesn't exist"
<tjaalton> so dexconf fails
<tjaalton> it hasn't been cleaned up properly
<pitti> tjaalton: "touch"?
<pitti> tjaalton: oh, argh
<tjaalton> pitti: I still use latin1 :)
<dholbach> hahaha, http://www.ubuntu.com/ looks great :)
<seb128> ;-)
<stgraber> :)
<pitti> oh, sweet!
<ion_> Mr. Hankey the Christmas Poo with a pink face painting?
<Kmos> I want a Ubuntu house :-) hehe
<Pici> I think its a gibbon wearing the yellow jumpsuit from kill bill
<Kmos> Pici: yeah
<Kmos> hehe
<cjwatson> tjaalton: so is that just a matter of clearing out the answers to every question owned by xserver-xorg in livecd-rootfs?
<tjaalton> cjwatson: no, it's done in xserver-xorg.postinst, but in this case dexconf just tried to fetch a key that's not there, and thus fails
<tjaalton> ie. a key that has already been cleared (or, in this case not used at all since it's a fresh install)
<cjwatson> err, what happened to xserver-xorg/config/display/modes?
<tjaalton> gone with xresprobe
<cjwatson> damn, usplash and ubiquity both refer to that
<tjaalton> oops :)
<cjwatson> care to suggest replacements for what they do?
<cjwatson> neither usplash nor ubiquity will actually *break* in its absence; usplash will revert to 640x480 and ubiquity will ignore it
<cjwatson> but still, it's not ideal
<tjaalton> cjwatson: I understand.. let me think about it for awhile
<cjwatson> fixing dexconf is more urgent, so don't let me drag you away from that
<tjaalton> sure, it's a simple commit
<cjwatson> what's the substitution in dexconf?
<tjaalton> ubiquity should also be fine, since it'll use whatever the hw would allow
<tjaalton> dexconf doesn't write the mode anymore
<cjwatson> tjaalton: the code in ubiquity is directly related to whatever usplash does
<cjwatson> it's copying the value across for use by usplash
<tjaalton> oh, in that case it should not do that
<tjaalton> instead rely on the xserver
<tjaalton> ..and driver to do the right thing
<cjwatson> uh ... how would usplash depend on the X server?
<tjaalton> I meant ubiquity
<cjwatson> ubiquity is just setting up debconf for usplash
<cjwatson> nothing more
<tjaalton> ok, I was confused there
<cjwatson> I shouldn't have mentioned it, it's a direct consequence of whatever's done in usplash
<tjaalton> I'll commit the fix first, and then we'll sort this out
<cjwatson> ok
<cjwatson> though I'm about to head out for the evening
<tjaalton> hmm ok
<tjaalton> so I'll get usplash & ubiquity to have a look
<cjwatson> usplash is really just trying to ask "what mode should I use?"
<cjwatson> s/mode/screen size/
<mjg59> cjwatson: ubiquity can probably just query that at runtime now?
<mjg59> Or was there some reason this was hard? I forget.
<tjaalton> cjwatson: is it before the session is loaded?
<mhb> Keybuk: many of the Kubuntu developers want to make KDE4 the default now that somebody decided there is not going to be an LTS. Is the Kubuntu council allowed to make such a decision? I mean it would be a shame if we announced it but somebody else decided on which CD will get shipped.
<mhb> Keybuk: if we should put our efforts into KDE4, we'd like to have a guarantee that something or somebody won't block our work in the 2/3rds of the development cycle.
<cjwatson> mjg59,tjaalton: it's done in usplash's postinst. Relying on the X session being up and doing it in ubiquity would break non-ubiquity installs which still need to do the same thing, not to mention putting yet more stuff into ubiquity that belongs in packages.
<cjwatson> (I only saw up to "<tjaalton> cjwatson: is it before the session is loaded?"; apologies if there was more after that)
<tjaalton> cjwatson: yep, I agree
 * keescook wonders about reading the scroll-back between soren and pitti...
<pwnguin> did i miss something? hardy isn't a LTS?
<pwnguin> i was without power for a week, so it's possible
<pochu> pwnguin: it is. why?
<pwnguin> then whats this about kde 4.0
<pochu> Oh, I don't know anything about kubuntu. Ubuntu is LTS for sure, at least.
<keescook> Keybuk: hibernate/evil/resume> I think the fs would get corrupted.  However, I wonder if mount -o remount,ro /; *hibernate*; *single-user*; vi /etc/passwd; *reboot/resume*; mount -o remount,rw /   would work?
<keescook> soren: I would say that "security" is intended to reduce risk.  (things like users/groups assist both security and organization)
<keescook> soren: fewer people will reboot a system to get root than those that would use an existing open root shell.
<keescook> so, by not leaving a root shell open, you reduce risk.
<pitti> hi again
<pitti> BenC: testing your new module now
<jdstrand> keescook: well put
<jdstrand> soren: I would also add that it isn't always all or nothing
<jdstrand> soren: having a system in your house is often *enough* physical security for most people
<jdstrand> soren: and a non-open tty is *enough* for co-workers, because often you or others will notice them at your computer, fiddling it
<jdstrand> but pitti's argument is absolutely valid-- if someone is actively seeking your box, physical access == root
<jdstrand> to use an analogy-- I have ssh listening on a non-default port.  this offers no actual protection from someone who wants to connect.  but it keeps the vast majority of people away
<jdstrand> (this is of course an imperfect analogy-- but gets to kees' reducing risk argument, while also supporting pitti's and your own :)
<pitti> jdstrand: ssh port> heh, me too; got sick of the millions of logcheck spam mails from bots which try random user names and passwords
<pitti> BenC: hm, I get a different crash now :/
<jdstrand> pitti: :)
<pitti> BenC: new crash screenshots attached
<BenC> pitti: thanks
<BenC> pitti: same crash, different trace is all
 * pitti tries to imagine the end of that sentence
<BenC> pitti: better wording: same crash, it's just a different traceback :)
<pitti> ah, ok
<BenC> pitti: ok, I think I've found the problem, 10 minutes and I'll have another .ko
<BenC> pitti: new module attached to the bug report
<pitti> BenC: rock, trying
<pitti> oh, I need to reboot back into .22 for vmware
<pawalls> keescook, ping
 * pitti hugs BenC
<BenC> yay!
<pitti> BenC: that did it, no oops any more
<pitti> I don't get X started, but I think that's another bug
<BenC> pitti: I'll wait till the install is over to declare victory
<BenC> oh, damn
<pitti> oh, no, X comes up now
<pitti> just took a while
<BenC> keep on truckin brotha
<pitti> BenC: yep, doing a test install now :)
<pitti> BenC: but the alternate install with the same kernel worked, so let's cross fingers
<pitti> ergh, install at 800x600, ubiquity doesn't like taht
<pitti> slangasek: the desktop background is broken (no elephant skin, just plain orange), but that's hardly RC :)
<pitti> BenC: ok, installation is grinding away
<BenC> pitti: I'll prepare everything for upload
<slangasek> pitti: ok :)
<pitti> "The ext3 file system creation in aprtition #1 of SCSI3(0,0,0) failed."
<pitti> that's less good
<slangasek> are the alternates getting any testing while we wait?
<pitti> I just gave them a smoke test, I was busy with the desktops in the afternoon
<BenC> pitti: the kernel uploaded earlier will give us ppc and lpia as well
<pitti> but I announced them in the tracker etc.
<BenC> only thing failing now should be ia64
<pitti> slangasek: when xorg is built we shuold rebuild the alternates, though
<pitti> slangasek: forcing 800x600 upon everyone is no fun
<pitti> BenC: great
<pitti> ia64, what's that :)
<pitti> BenC: formatting issue is not an oops at least
<BenC> ia64 was this crazy notion that slow 64-bit was better than fast 32-bit
<pitti> "program parted_devices is using a deprecated SCSI ioctl, please convert it to SG_IO"
<BenC> hrmm
<pitti> evand, cjwatson: ^ any idea?
<BenC> I wonder if that's some compatibility we disabled in the kernel that can be fixed with a config option
<pitti> so that might or might not be considered a kernel bug
<BenC> pitti: that doesn't return error in the code
<BenC> it's just a warning
<pitti> hm
<pawalls> keescook, I'm available if you need information on the kernel OOPS bug. I uploaded a patch that fixes the problem also.
<pitti> ubiquity just gives that error message and returns to the partitioner
<BenC> pitti: the only way it can return error is -EINVAL if there is no arg to the SEND_COMMAND ioctl, which would be a program bug, but that's not a new condition
<pitti> ok; trying again with more debugging output
<pitti> hm, I wonder whether this actually was PEBCAK
<pitti> I think I forgot to unmount /dev/sda1 in the initramfs after I insmod'ed the new unionfs.ko from there
<pitti> I did it this time
<BenC> pitti: ah, that could do it
<pitti> oh, c'mon tracker notifications, get out of my eyes
<BenC> -EBUSY
 * pitti holds his breath
<markvandenborre> persia, should I file a bug report on packaging libtimidity?
<pitti> AWOOGA!
<pitti> evand, cjwatson: unping; PEBCAK, sorry
<markvandenborre> pitti, ... awooga:  	
<markvandenborre> of and or relating to sex and or sexual intercourse. comes from the sound of the horn of an old studenbaker.
<markvandenborre> http://www.urbandictionary.com/define.php?term=awooga&defid=627268
<pitti> lol
<slangasek> ...
<pitti> to me it sounds more like a cry for battle from something in between a gibbon and a Neanderthal :)
<pochu> cool version of Eurika (I found it!), too ;-)
<pochu> (same page)
<slangasek> yes, but the people who write for urbandictionary think that *everything* is of and relating to sex and/or sexual intercourse
<BenC> slangasek, pitti: latest linux is finished building...I think ppc and lpia will need NEW, if you could please
<pitti> BenC: with pleasure
<pitti> BenC: right in time for publisher
<BenC> pitti: excellent, thanks
<jdstrand> slangasek: you mean everything isn't?
<pitti> BenC: ah, this time with -rt again
<pitti> BenC: done
 * jdstrand goes off and rethinks the meaning of life...
<slangasek> heh
<pitti> jdstrand: 42!
 * pitti wouldn't be surprised if urbandictionary would define that as how much sex you should have per month or so :-P
<Keybuk> pitti: err, what unit of measurement?
<pitti> jdstrand: ah, no, wasn't it "We apologize for the inconvenience" in the 4th novel?
<jdstrand> pitti: mana that takes me back...
<jdstrand> s/mana/man/
<jdstrand> but maybe mana(sp.) is more appropriate here...
<pitti> Keybuk: in the interest of staying alife I don't hope it's counting :)
<pitti> alive, even
<pitti> . o O { will I ever get that one right the first time? }
<pitti> BenC: unionfs is l-u-m, right?
<BenC> pitti: right
<pitti> BenC: it progressed fairly well, I think upload should be good
<pitti> BenC: thanks, that was super-fast
<pitti>       xorg | 1:7.3+8ubuntu2 |         hardy | source, amd64, hppa, i386, ia64, lpia, powerpc, sparc
<pitti> slangasek: ^ there we go, shall I kick new alternates or do you want to?
<pitti> slangasek: I don't think we need to wait for fixed unionfs on alternates, but your call
<tjaalton> pitti: it doesn't force 800x600 for everyone, just vmware
<pitti> tjaalton: oh, then I misunderstood
<slangasek> pitti: I'll fire it off now
<pitti> tjaalton: you'll still get the wrong keyboard layout, though, I guess?
<pitti> so people can't even log in if they have a nontrivial password?
<tjaalton> pitti: no, now dexconf works and you'll get it right
<pitti> tjaalton: I mean with the previous one which is on the current alternates
<pitti> i. e. why I think we need to rebuild them
<tjaalton> yeah, right
<BenC> pitti: lum is passing through my T1 to the upload queue as we speak
<pitti> mmm, T1
<tjaalton> BenC: shall I fix l-r-m or?
<BenC> tjaalton: what's wrong with it?
<tjaalton> read the email
<tjaalton> on u-d
<tjaalton> nvidia/fglrx should not provide xserver-xorg-video, but x-x-v-2
<slangasek> pitti, tjaalton: too much discussion, the alternates are already rebuilding ;)
<pitti> slangasek: and rightly so
<jdstrand> pitti: well that was a fun little break-- "We apologize for the inconvenience" is most definitely the 4th book-- chapter 40
<jdstrand> ;)
<pitti> jdstrand: ah, it's been years since I read it the last time
<jdstrand> pitti: me too-- your memory is far superior to mine to pull that one out! :)
<pitti> jdstrand: just remember, that was the almost-dying Marvin which by that time was 37 times as old as the entire universe or so? :)
<pitti> climbing up that hill from where you see that sentence
<jdstrand> there was some sort of coin-op device too
<jdstrand> long live Marvin!
<pitti> Marvin for president!
<markvandenborre> persia, https://bugs.launchpad.net/ubuntu/+bug/177759
<ubotu> Launchpad bug 177759 in ubuntu "libtimidity needs packaging for gstreamer sw midi playback to work" [Undecided,New]
<pitti> instead of rebooing, the live session just got hung and stuck
<jdstrand> huhuh... pitti said 'rebooing'
<pitti> whoops
 * jdstrand has clearly been looking at his mysql update for too long
<pitti> Give me a T!
<jdstrand> T!
<pitti> give me a "he desktop install worked"!
<pitti> What's the sentence?
<jdstrand> haha
<slangasek> he desktop install worked-tuh!
<jdstrand> easy: "she desktop install worked"
 * pitti congratulates slangasek, very good!
<pitti> slangasek: so, after that  lum upload the desktop should be good *phew*
 * jdstrand bangs his head on his desk for missing that one
<pitti> (clearly time for a christmas break here...)
<pitti> BenC: btw, I take it that the .24 kernel does not have any apport patches any more?
<BenC> pitti: nope
<pitti> cool
<pitti> then I can go ahead and convert apport to the new interface
<pitti> finally, it'll run on a vanilla upstream kernel \o/
<slangasek> pitti: and the source is pending, so looks like we're on track hurray
<slangasek> ubuntu,kubuntu,edubuntu alternates republished
<pochu> rz
<pochu> woops
<slangasek> rzszczyk
<pochu> I feel better now ;)
<pitti> hm, most of lum is in depwait for headers-rt
<pitti> so that'll take a while still
<slangasek> pitti: ?
<slangasek> powerpc/lpia are dep-wait on the kernels from new, no?
<slangasek> oh, I'm looking at 2.2 instead of 2.3
<slangasek> why is that
<slangasek> are we sure that's "will take a while", not "needs a reupload without a dep on a package that isn't going to get here any time soon"?
<slangasek> ubuntu-server, ubuntustudio also available for testing
<BenC> slangasek: 2.3 is uploaded, but not processed yet...just needs to wait for the buildd run
<slangasek> BenC: see pitti's comment above that it's dep-wait on a headers-rt package that doesn't seem to exist
<BenC> slangasek: was the headers-rt package put into main or universe?
<BenC> the latter would be bad
<slangasek> hmm, it's in main
<slangasek> so that was just now published then?
<BenC> not too long ago, yeah
<slangasek> ok
<slangasek> well, i386 is now dep-wait on linux-headers-2.6.24-2-ume, checking
<slangasek> that one's not in universe or main
<BenC> hmm, where did that dep come from
<BenC> completely bogus
<Ahmuck> hi, i noticed that when doing a "sudo aptitude install xserver-xorg" that it downloaded and installed all the xserver modules (graphics, wacom pad, etc) for xserver.  however i  really don't need this.  is there a way to not do that?  i noticed that using apt-get for firefox only get's firefox and saves a 10mb download.  would xserver-xorg be the same
<pitti> slangasek: yes, it was amongst the packages I NEWed a while ago
 * somerville32 gets out a sledge hammer to beat Xubuntu into shape.
<tjaalton> Ahmuck: not without force
<Ahmuck> try e17
<tjaalton> Ahmuck: actually, just install the driver you need
<slangasek> BenC: you'll work on a -2.4 that removes these references to japanese plums, then?
<Ahmuck> yes, i noticed that perhaps i could install, xserver-xorg base and then the driver?
<Ahmuck> i assume
<BenC> slangasek: yeah, 5 minutes to upload
<slangasek> BenC: cool, thanks
<Spads> Ahmuck: when you assume, you make an ass out of ume, which is a japanese plum
<slangasek> haha
<Ahmuck> spads, ever had a japanese plum?
<Spads> Ahmuck: Yes.
<Ahmuck> it will make you pucker as well
<Ahmuck> :-p
<Spads> depends on the plum
<Spads> slangasek: when you assist, you make an ass-cyst.  this aphorism shows you the folly of assistance.
<pitti> slangasek: running amd64 alternate test install now; btw, did you already put them into isotracker?
<slangasek> pitti: yes
<pitti> cool
<BenC> slangasek: on its way
<slangasek> BenC: thanks
<pitti> BenC: hm, just saw the 'removed ipw3945' item in the lum changelog; too bad :/
<pitti> BenC: any chance to keep it for a while?
<BenC> pitti: not needed
<BenC> pitti: iwl3945 in upstream kernel supersedes it
<pitti> (bug 177624)
<ubotu> Launchpad bug 177624 in linux "iwl3945 has very poor signal reception, whereas ipw3945 works perfectly" [Undecided,Confirmed] https://launchpad.net/bugs/177624
<BenC> hmm, we'll report that to intel then
<pitti> BenC: can do, they have an upstream bug tracker?
<BenC> they have an lp project to file against, IIRC
<pitti> ah, great
<pitti> https://edge.launchpad.net/intellinuxwireless?
<pitti> BenC: so the recommended way is to just add an upstream task?
<BenC> pitti: right
<pitti> yay LP :)
<pitti> BenC: they didn't set a bug contact, though, and mark it as 'uses LP for bugs'
<BenC> hmm, I'll check it
<pitti> cjwatson: argh, the 'erasing data' for encrypted LVM is back (merge regression)
 * pitti reopens bug 151244
<ubotu> Launchpad bug 151244 in partman-crypto "encrypted lvm initialisation is very slow" [Medium,Triaged] https://launchpad.net/bugs/151244
<mjj29> hi, I'm a DD and one of my packages (which was copied from unstable) doesn't build
<mjj29> (on ubuntu)
<mjj29> however, I could make some (minor) modifications to it so that it would
<mjj29> (specifically, ubuntu now has icedtea whereas I have to depend on sun-java in debian)
<mjj29> how would I go about getting such a branch of the package into ubuntu?
<pochu> mjj29: which package?
<mjj29> pochu: dbus-java
<slangasek> mjj29: the standard way is to file a bug against the source package in launchpad with a patch (incl. a changelog with a <foo>ubuntu1 version number), and then subscribe ubuntu-universe-sponsors
<mjj29> (the build failure is that while the buildd will install sun java it can't accept the dlj, so it fails)
<pitti> mjj29: dlj?
<TheMuso> mjj29: Alternatively, if you wish to make a change in Debian, make the change, upload it, and then request a sync.
<mjj29> alternatively, it's arch all; does ubuntu insist on sourceful uploads
<slangasek> separately, I suppose that once dbus-java is building against icedtea, someone should ask for it to move from multiverse to universe?
<mjj29> TheMuso: icedtea isn't in debian yet, so I can't use that
<pitti> mjj29: yes, source uploads only
<TheMuso> mjj29: Ok
<pitti> mjj29: you could also use an alternate build dep to keep it in sync in debian and ubuntu
<mjj29> pitti: fair enough. Debian buildds don't have the problem since it's arch all
<pitti> mjj29: b-dep: sun-java | icedtea should DTRT
<slangasek> pitti: it does?
<pitti> since we don't have sun-java in Ubuntu
<mjj29> pitti: yes you do
<mjj29> according to the buildd log
<pitti> slangasek: hm, not according to madison
<pochu> Then do icedtea | sun-java
<pitti> might be a provides
<mjj29> http://launchpadlibrarian.net/10787839/buildlog_ubuntu-hardy-i386.dbus-java_2.3.1-1_FAILEDTOBUILD.txt.gz
<slangasek> pochu: that won't work for Debian.
<mjj29> pochu: indeed
<slangasek> sbuild only considers the first branch of an ORed build-dep
<pochu> slangasek: why not? It can't find icedtea, then it picks sun-java?
<slangasek> well, ok, it's arch: all so this doesn't matter in practice
<pitti> slangasek: not our sbuild
<pochu> ORed?
<geser> pitti: the build dependency is sun-java5-jdk which is in multiverse
<pitti> slangasek: we patched it to consider the alternatives and provides, too, AFAIK, to avoid such deltas
<pochu> alright, acked
<pitti> geser: ah, that would be it
<slangasek> pitti: yes, but that doesn't help when the Debian build-dep is the one listed last :)
<pitti> mjj29: it doesn't work at all with gcj?
<slangasek> pitti: because the Debian build-dep is the one that has to work with Debian's sbuild :)
<pitti> slangasek: right, since I didn't see sun-java I would have put that last
<mjj29> pitti: no, I have a bug filed with gcj upstream about that
<mjj29> it _compiles_
<mjj29> it doesn't run
<mjj29> actually, I could probably build-dep on gcj and dep on sun-java
<mjj29> since that would work in both, perversely
<pitti> mjj29: ah, it doesn't miscompile, it just mis-"runs"?
<slangasek> dep on sun-java | icedtea, I guess?
<mjj29> slangasek: that fails as it does atm
<mjj29> because ubuntu sbuild tries to install sun-java and fails
<pitti> Unpacking sun-java5-bin (from .../sun-java5-bin_1.5.0-13-0ubuntu1_i386.deb) ...
<pitti> sun-dlj-v1-1 license could not be presented
<mjj29> unless it then retries?
<pitti> try 'dpkg-reconfigure debconf' to select a frontend other than noninteractive
<pitti> oh, argh
<mjj29> pitti: mmm
<pitti> so it's not a problem of being in universe vs. multiverse, but the silly license question
<mjj29> yeah
<mjj29> which can only be done interactively, or by preseeding debconf
<mjj29> neither of which you can do on a buildd
<pitti> infinity: any chance this could be fixed in the buildds?
<pitti> how does that work in Debian then?
<slangasek> mjj29: dep, not build-dep
<pitti> oh, right, no actual buildd builds in Debian
<slangasek> right
<mjj29> slangasek: oh, yeah
<pitti> mjj29: that means that it is actually buildd-FTBFS in Debian, too?
<mjj29> pitti: 1. it's in contrib, so all bets are off
<slangasek> pitti: yes, but never an issue in practice, there are no Debian buildds that ever build arch: all packages
<mjj29> 2. it never gets built
<geser> what about archive rebuilds in Debian?
<pitti> mjj29: ok; so AFAICS you could either use "b-dep: icedtea | sun-java" and don't care (since it's broken either way in Debian)
<pitti> mjj29: or we introduce that small delta
<slangasek> geser: no reason for this to be release-critical
<pitti> until openjava sees the light of the day and we can get rid of all that mess in both D and U
<mjj29> pitti: or I b-d on gcj and then d on sun | icedtea
<slangasek> or option 3, mjj29 can package icedtea-java for Debian
<slangasek> >:)
<mjj29> slangasek: heh
<infinity> pitti: Which release is this on?
<pitti> mjj29: right, that would be elegant in a nasty way :-D
<pitti> infinity: hardy
<infinity> pitti: Grr.  That's supposed to be fixed.
<mjj29> unless infinity fixes it magically
<pitti> infinity: licenses are sticky as superglue, so it seems
<mjj29> and I can go back to not caring about ubuntu until someone else emails me to ask me to fix it for you (-;
 * infinity grumbles.
<pitti> mjj29: oh, I'm glad that you brought it up, don't get us wrong :)
<infinity> root@vernadsky:~# debconf-get-selections | grep dlj
<infinity> buildd  shared/accepted-sun-dlj-v1-1    boolean true
<infinity> *cry*
<infinity> And it still bails out in the postinst, due to the debconf frontend?
<mjj29> infinity: that should DTRT
<mjj29> hang on
<mjj29> I have a preseed which does that around here
<pitti> infinity: see above FTBFS URS
<mjj29> sun-java5-bin   shared/accepted-sun-dlj-v1-1    boolean true
<mjj29> sun-java5-jdk   shared/accepted-sun-dlj-v1-1    boolean true
<mjj29> sun-java5-jre   shared/accepted-sun-dlj-v1-1    boolean true
<slangasek> surely the owner field shouldn't matter?
<infinity> mjj29: Same pre-seed as mine.
<infinity> mjj29: The bit that breaks is a check against the frontend, it seems.
<mjj29> ^^ thats what I pipe to debconf-set-selections
<infinity> Wait, no.  It WORKS in my chroot here.
<infinity> Which is identical to the chroot in soyuz.
<slangasek> Burgundavia: hey, were you still working on alpha2 release notes? I don't see any changes on https://wiki.ubuntu.com/HardyHeron/Alpha2
<pitti> infinity: maybe you fixed it recently and the build is older?
 * pitti swings the giveback axe
<infinity> Oh!
<infinity> How old is this log?
<mjj29> infinity: dunno, got emailed it by an ubuntu user today
<infinity> Ah-ha.
<geser> infinity: Finished at 20071207-1736
<infinity> Yeah.
<infinity> pitti: Just give it back.
<infinity> pitti: Should work now.
<pitti> done
<infinity> Thought I was losing my mind...
<pitti> so, let's cross fingers :)
<mjj29> cool
<mjj29> "Pending (0)"
<geser> infinity: while speaking of buildds: any progress on fixing bug #87077 on the buildds?
<ubotu> Launchpad bug 87077 in scons "The build of xmms2 fails because of HASH(0x82db558)="" in the environment" [Undecided,Fix released] https://launchpad.net/bugs/87077
<infinity> geser: It's on my radar, but I have other stuff that's more pressing right now. :/
<geser> ok
<slangasek> yes, hash is bad for the environment
<geser> infinity: I guess bug #174851 is at the other end of your work queue
<ubotu> Launchpad bug 174851 in mig "mig and gnumach need a manual boot-strapping on the buildds" [Undecided,New] https://launchpad.net/bugs/174851
<infinity> geser: I'm guessing no one told me about that one. :)
<infinity> geser: At this point, it's not likely to be done before Christmas (ie: tomorrow afternoon), but it should be up there, yeah.
<infinity> geser: Subscribed to it now...
<geser> infinity: I gave you that bug number after I filed it, but I guess it was the wrong time and it got lost
<infinity> geser: Possibly.
 * pitti just realizes what he writes when he does $ killall cat
<pitti> those poor kittens *sob*
<slangasek> meow
<pitti> ah, that alternate test install looks good; I even have an xorg.conf again
<cjwatson> pitti: parted_devices has been saying that for ages,
<cjwatson> BTW
<cjwatson> pitti: the "regression" in partman-crypto is intentional; the erase step is now cancellable
<pitti> cjwatson: ah, ok; was a red herring apparently
<cjwatson> which solves the problem more elegantly, IMO
<pitti> cjwatson: oh, indeed
<StevenK> pitti: Please give-back libofa on all arches
<pitti> done, and thanks for fixing curl
<TheMuso> Is there likely to be another linux-meta upload before alpha goes into testing/releae?
<TheMuso> Since lum was updated?
<slangasek> I didn't expect there to be, is there a reason that one would be needed?
<TheMuso> slangasek: I don't really know, th is is why I'm asking. If not, no matter.
<slangasek> AFAIK there's no need for linux-meta updates after non-ABI-changing lum
<TheMuso> Fair enough then.
<slangasek> stgraber: help
<slangasek> stgraber: I managed to get builds added to the iso tracker which the tracker couldn't find on cdimage.u.c; so I tried to "remove selection", but now readding them doesn't cause them to be visible
 * slangasek considers faking the build names
<EvanCarroll> will heron have perl5.10?
#ubuntu-devel 2007-12-21
<pitti> cjwatson: my OEM test install hangs at the finish installation stage with 'Disabling netinst CD in sources.list...'
<pitti> ah, nevermind; it just got stuck doing apt-get update
<EvanCarroll> hrm
<keescook> pawalls: okay, cool; thanks.  :)
<slangasek> stgraber: ok, fundamentally there seems to be a problem with the tracker's link checker; even after switching the build number and waiting for cdimage.u.c to sync, I still get told for all images that "This build wasn't found on cdimage.ubuntu.com"
<slangasek> gnyaah
<slangasek> l-u-m FTBFS
<slangasek> ... because of the merged -rt support
<ogra_cmpc> any xfs pro around ?
<ogra_cmpc> /usr/sbin/debootstrap: 317: cannot create /home/ogra/chroot-livecd/test-dev-null: No such device or address
<ogra_cmpc> seems i cant create any devices on my xfs partition
<ogra_cmpc> its not mounted with nodev or so
<cjwatson> ogra_cmpc: hmm
<cjwatson> let me see if I can reproduce that here
<ogra_cmpc> it works fine on the /boot partitioni have
<cjwatson> I introduced that debootstrap check quite recently; it might be buggy
<cjwatson> could you put 'set -x' at the top of /usr/share/debootstrap/functions and get a shell trace?
<ogra_cmpc> sure
<cjwatson> ENODEV, though, that's just weird
<cjwatson> not a documented return code from mknod(2)
<ogra_cmpc> cjwatson: http://paste.ubuntu-nl.org/49089/
<ogra_cmpc> root@ceron:~# mkdir test
<ogra_cmpc> root@ceron:~# mknod test/test-dev-null c 1 3 || echo "failed"
<ogra_cmpc> root@ceron:~# echo "blah" >test/test-dev-null
<ogra_cmpc> bash: test/test-dev-null: No such device or address
<ogra_cmpc> root@ceron:~#
<cjwatson> ogra_cmpc: any other mount options I should know about?
<ogra_cmpc> ogra@ceron:~$ cat /proc/mounts |grep " / "
<ogra_cmpc> rootfs / rootfs rw 0 0
<ogra_cmpc> /dev/md0 / xfs rw,sunit=128,swidth=256,ikeep,noquota 0 0
<cjwatson> xfs, home of mount options nobody else recognises
<ogra_cmpc> heh
<ogra_cmpc> well, i didnt specify any options at all
<ogra_cmpc> its the default teh installer choose
<cjwatson> seems to WFM on a fresh XFS partition
<cjwatson> s/partition/filesystem/
<cjwatson> /home/cjwatson/xfs.disk on /mnt type xfs (rw,loop=/dev/loop0)
<cjwatson> sunit and swidth are md things, ikeep and noquota aren't things the installer sets AFAICS, maybe defaults?
<ogra_cmpc> hmm
<ogra_cmpc> it seems teh xfs deeply ties into teh raid0 below
<cjwatson> it's still a weird error though
<ogra_cmpc> the suinit and switdh parameters seem to adjust values for the raid striping
<cjwatson> might be worth checking dmesg for any errors there
<cjwatson> it really looks like it's mounted with something that implies nodev, but I can't see what
<ogra_cmpc>    39.130673] Filesystem "md0": Disabling barriers, not supported by the underlying device
<ogra_cmpc> well, that should only affect speed
<ogra_cmpc> nothing else intresting in dmesg
<ogra_cmpc> no fresh errors in any logs either
<cjwatson> kernel version?
<ogra_cmpc> ogra@ceron:~$ uname -a
<ogra_cmpc> Linux ceron 2.6.24-2-generic #1 SMP Fri Dec 14 00:02:38 GMT 2007 i686 GNU/Linux
<ogra_cmpc> todays :)
<cjwatson> I'm still on 2.6.22, FWIW
<cjwatson> so that could explain the difference
<ogra_cmpc> i got a .22 on it but i wont go in teh basement and reboot now, to tired ...
<ogra_cmpc> hmm, i could fiddle wit grub remotely :)
<ogra_cmpc> cjwatson: yep, seems to be a kernel based issue
<ogra_cmpc> 2.6.22 works fine
<pawalls> keescook, ping
<keescook> pawalls: pong!
<pawalls> keescook, Patch uploaded and confirmed to fix the OOPS when mounting NFSv4
<keescook> pawalls: excellent, so, here's the weird part -- I'm able to mount with nfsv4 without crashes.  :(  Is the failing configuration special in some way?
<keescook> pawalls: ah, nm, it seems to be partial hang.
<keescook> I'll get stuff spun up -- thanks for sorting out this patch!
<IntuitiveNipple> Is there a reason that bluez-utils doesn't build/install sdpd (Bluetooth Service Discovery Protocol daemon)? Because of this, remote devices can't discover services making connections impossible in some cases.
<StevenK> IntuitiveNipple: In Hardy?
<IntuitiveNipple> I'm using Gutsy, but looks like it's carried forward into Hardy too.
<IntuitiveNipple> I've been tracking the changelogs, looked through the bugs, etc., and now working with the source. Trying to find out why it is not built
<StevenK> Does it pose security problems if it is?
<IntuitiveNipple> It poses a usability problem if SDP isn't available to remote devices - they can't discover any services to connect to! I'm just checking things out with Marcel Holtmann so I can be sure what/why etc :)
<Burgundavia> IntuitiveNipple: ask pitti and mjg59
<IntuitiveNipple> I think it's more of a 'changing target' issue with the bluez-utils userspace applications. Once I've got a definitive answer I'll post a bug-report if needed.
<StevenK> I don't think I like the idea of a daemon broadcasting what I'm running over Bluetooth
<IntuitiveNipple> If the BT device isn't discoverable, it ain't available, but when the device is discoverable, I want the darned thing to tell my devices what it can do!
<Burgundavia> IntuitiveNipple: I am going to guess it is a security issue
<persia> IntuitiveNipple: Might be nice to have a configuration tool to allow exposure of desired services without broadcasting to anyone within 10 metres.
<IntuitiveNipple> It appears maybe it isn't. It looks like, along with the other bluez* deamons, the functionality has been incorporated into the hcid daemon, and by default Gutsy/Hardy both configure it to operate the internal SDPD server. The problem is, it isn't exposing the services (on my tests anyhow) even though I've customised the 'class' setting in /etc/bluetooth/hcid.conf as required.
<slangasek> Burgundavia: ribbit
 * Fujitsu squishes slangasek under his foot.
 * Hobbsee tries to remember what a fast X actually feels like
 * Fujitsu hugs XAA.
 * Hobbsee would hug it, except for the random, exploding crashes
 * Fujitsu just has the one or two a day.
<Farquad> anyone know if a music player exists that would allow me to add files to a playlist on one computer, then have another node pc play those files when i click play? (a remote controlled client)
<Fujitsu> This isn't a support channel.
<persia> Farquad: Yes, but you likely want to ask which of them is good for your use case, and how to use them in #ubuntu or #ubuntu-xx.
<Farquad> i wasnt asking for support, i was trying to find out if something like this already existed
<Hobbsee> which is a support related question, not a developmen tone...
<Hobbsee> i think there is, though.  i don't remember what it's called, but i expect google, etc, could help there
<Farquad> sorry to interrupt all the conversations going on in here
<Hobbsee> note to self:  don't replace current X driver, in an X session.
<Fujitsu> That shouldn't normally do much...
<Hobbsee> no, but if you end up copying it over to what it's directly using..it appears to mangle your X
<StevenK> It should be mmap()'d if it's using it
<Hobbsee> unless compiz screwed it over, or something.  *shrug*
<Fujitsu> Hah.
<Hobbsee> oooh...
<Hobbsee> *this* is what fast X feels like
<Fujitsu> New driver works?
<slangasek> yes, replacing the X driver from within X isn't supposed to break anything
<Fujitsu> slangasek: That's what I thought, or upgrades would be a bit difficult.
<StevenK> Until you restart X at least. :-P
<slangasek> the driver is already loaded in memory, unpacking the new one just means the driver on disk doesn't match the one that's running (due to the magic of POSIX file deletions)
<Hobbsee> Fujitsu: no, but i switched from exa to xaa again
<Fujitsu> Ahh.
<Hobbsee> slangasek: yeah well.  that's what i thought should happen.
<Hobbsee> until my screen went bang.
<slangasek> seems more plausible that it was StevenK emitting X-interference
 * StevenK looks innocent.
<Burgundavia> slangasek: rabbit
<slangasek> Burgundavia: hiya. were you still going to have time to work on alpha2 release notes? :)
<Hobbsee> keep in mind, he'll shoot you if you don't do them
<slangasek> now, now, I very rarely shoot people for things they /haven't/ done
<Hobbsee> no time like the present to start, then
 * Fujitsu thinks slangasek unleashes the Canonical-issue doomsday device in that case.
<warp10> Hi all!
<musther> Hello
<Burgundavia> slangasek: sadly real life intervened, so no
<slangasek> ok
 * slangasek scribbles something quickly in crayon
<dholbach> good morning
<Hobbsee> morning pitti!
<pitti> Good morning
 * pitti yawns
 * Hobbsee force feeds pitti some coffee
<pitti> argl coffee!
 * pitti redirects Hobbsee to some tea
<sivang> hi all
 * Hobbsee force feeds pitti a mix of coffee and tea, then.
<Hobbsee> heya sivang!
<pitti> hey sivang
<Fujitsu> Hobbsee: That sounds even more revolting than normal coffee. Spoiling perfectly good tea...
<Hobbsee> Fujitsu: there is no good tea.
 * pitti celebrates the release of apport 0.100
<dholbach> Hobbsee: pfffft
<dholbach> pitti: ROCK ON :)
<StevenK> pitti: My upload of gimp broke :-(
<StevenK> As in, it FTBFS
<Fujitsu> Hobbsee: Oy. <3 tea.
<Fujitsu> pitti: What's new?
<slangasek> StevenK!
<pitti> Fujitsu: primarily that it doesn't spill core files everywhere with our new kernel
<StevenK> slangasek: Hrm?
<slangasek> StevenK: I see you uploaded libofa?
<StevenK> slangasek: Right
<Hobbsee> StevenK: run.  run now.
<slangasek> StevenK: you broke kubuntu
 * sivang hugs pitti Fujitsu Hobbsee dholbach StevenK 
 * Hobbsee hugs sivang
<sivang> Hobbsee: thanks, I needed that
<dholbach> hey sivang
 * Fujitsu hugs sivang.
<pitti> Fujitsu: the rest are just fixes to the retracers which were rolled out long ago
 * dholbach hugs sivang back
<sivang> hey you dholbach my good o' friend :)
<Fujitsu> pitti: Aha.
<slangasek> StevenK: we're now straddling a package name change for fftw3->libfftw3-3, and the packages conflict and kubuntu needs things depending on both of them
<pitti> Fujitsu: but apport is now compatible with a vanilla upstream kernel >= 2.6.24, that's great
<sivang> dholbach: I'm sorry for not responding for the patch apply request for hubackup, I've been through a bit like hell during the last couple of months but I'm back in shape
<StevenK> slangasek: Right, I'm still cleaning up that mess.
 * sivang enjoys the hugging
<dholbach> sivang: it's great to hear you're back!
<sivang> thanks! =)
<Fujitsu> pitti: Oh, nice.
<StevenK> slangasek: If you want some packages pushed up the queue, bug me with their source name
<slangasek> StevenK: does this mean you have a libtunpimp upload pending, or should I go ahead and upload this no-change rebuild?
<sivang> dholbach: I need to apply the branch with the patch there waiting, and then move on to rewrite the backend to use rdiff backup instead of dar
<StevenK> slangasek: Ah, libtunepimp. Go ahead with that, I'll follow later tonight with another batch of rebuilds.
<dholbach> sivang: ok cool
<sivang> and ofcourse, the joy of helping merges, fixing packages etc etc
<Hobbsee> StevenK: and risk being killed again?
<sivang> dholbach: are you by any chance a CC person ?
<StevenK> Not me not being killed.
<slangasek> hmm, or should I change libtunepimp so that it's not linking to fftw at all, since it's not using it :P
<dholbach> sivang: yes, but I think you can renew your ubuntumembers membership yourself
<slangasek> nah, that can be my next upload
<sivang> dholbach: it won't let me since it expired, I was too busy and offline to notice the emails
<dholbach> sivang: taking a look
<sivang> dholbach: thanks
<slangasek> StevenK: so is there a reason you uploaded libofa in the middle of a milestone freeze? <smiles sweetly>
<StevenK> It wasn't a milestone freeze when I uploaded it.
<dholbach> sivang: renewed it
<StevenK> It required curl to get fixed and then it was given-back
<slangasek> StevenK: timestamp says Dec 19
<slangasek> freeze started on Tuesday
<sivang> dholbach: thank you!
<StevenK> Ah
<Hobbsee> StevenK: hint:  blame timezones
<StevenK> slangasek: In which case, it completly slipped my mind, sorry
<slangasek> right
<StevenK> Maybe a little of what Hobbsee said, too
<slangasek> note to self to always send out a u-d-a mail at the start of any freeze
<StevenK> Yeah, that'd help
<sivang> ah, so we're in a freeze now? but probably universe is as usual still open ?
<slangasek> StevenK: except I know what way the clock runs, so it was /definitely/ Wednesday for you when you uploaded it ;)
<StevenK> Bah, out-smarted again :-P
<Hobbsee> slangasek: australian clocks are different.
<Hobbsee> slangasek: they run backwards, as we're upside down.
<slangasek> that's right, the coriolis force makes them.. .bah
<StevenK> Haha
<slangasek> anyway
 * StevenK runs off to get din-dins
<slangasek> at least as much my fault, for thinking I could skimp on announcing a self-imposed freeze
 * persia requests that slangasek add a small note about universe on the reminder note to announce freezes.
 * sivang wonders how he can catch up with all protocl and workflow changes since last time, or has the DistroPolicyTracker been implemented yet? :-))
<slangasek> persia: and miss out on our monthly game of "what does this mean for universe"? ;)
<slangasek> persia: yes, ok
<persia> slangasek: Thank you :)
<sivang> slangasek: heh
<persia> slangasek: Feel free to ping me if you need text :)
<slangasek> libtunepimp ubuntu2 uploaded
 * sivang wonders if http://blog.vaxius.net/?p=19 has a bug reported against it, probably needs a patch revert on the SLUB for folks who have ATI cards
<slangasek> StevenK: btw, you know libfftw3-dev still Provides: fftw3-dev?
<pitti> (just FAOD, our buildds consider pure virtual package dependencies, so we could even just remove the NBS one)
<slangasek> I just did that
<slangasek> :)
<pitti> sivang: policy> Ubuntu development policies are documented at wiki.ubuntu.com/UbuntuDevelopment; some months ago I documented all the freezes, too, and cleaned them up a bit; it's linked from that page
<TheMuso> So with all this new xorg stuff, how is one supposed to tell xorg about one's monitor, if they happen to be using it through a KVM that prevents DDC/monitor probing? I see dpkg-reconfigure xserver-xorg doesn't include monitor options any longer for setting resolutions/refresh rates.
 * TheMuso has just done an alternate install with the latest image and run into my above issue.
<slangasek> TheMuso: uh, I think step 1) is "file a bug on xserver-xorg"? :)
<tjaalton> TheMuso: displayconfig?
<TheMuso> slangasek: Ok, I thought removing monitor options from dpkg-reconfigure was intentional.
<tjaalton> it is
<slangasek> well, ok
<tjaalton> but yes, it seems that vmware and KVM have issues with it
<tjaalton> but I'm not sure how it worked before
<tjaalton> TheMuso: bug 172821
<ubotu> Launchpad bug 172821 in xorg-server "[hardy] only get 800x600 in vmware" [Medium,Confirmed] https://launchpad.net/bugs/172821
<pitti_> tjaalton: hm, just booted my desktop, X failed with "could not find read-edid blabla"; missing dependency?
<pitti_> tjaalton: ooh, I bet that's just because -nvidia-new is uninstallable
<tjaalton> right :/
<pitti_> and then the failsave X kicks in and fails, too
<sivang> pitti_: oh wow, cool :) finally
<TheMuso> Ok, so in displayconfig-gtk, how am I supposed to set resolution/refres rate, if the combox boxes have nothing in them?
<pitti_> FSVO "failsafe" :)
<tjaalton> TheMuso: now that's another problem :)
 * TheMuso is in the screen tab
<tjaalton> I'll install gutsy on vmware to see how it got it
<TheMuso> tjaalton: Remember, I am using my monitor through a KVM that prevents proper monitor probing.
<slangasek> TheMuso: what model is that so I know not to get it when I go shopping next month? :)
<slangasek> the kvm model, I mean
<tjaalton> TheMuso: oh KVM, I thought you meant the virtualization software :)
<TheMuso> slangasek: Couldn't tell you at the moment, and I'd have to get sighted assistance to tell me anyway.
<slangasek> TheMuso: ok, please don't go to the trouble then
<TheMuso> Needless to say, I'll be saving up for a better one.
<tjaalton> TheMuso: in that case please file a bug on xorg-server
<TheMuso> I liked the fact that it was 4 ports when I got it, and I was assured, dispite not being able to confirm it, that it supported DDC/probing.
<TheMuso> tjaalton: Ok.
<tjaalton> TheMuso: so you get a crappy resolution with it?
<TheMuso> tjaalton: 800x600
<tjaalton> yeah..
<TheMuso> Yet my monitor is capable of 1680x1050
<persia> TheMuso: You may be able to fool displayconfig-gtk if you can download the edid file from somewhere.
<TheMuso> persia: edid?
<TheMuso> I could also temporarily plug the monitor in directly.
<TheMuso> tjaalton: on xorg-server, or xserver-xorg?
<tjaalton> TheMuso: the former, it's the source package for xserver-xorg-core
<TheMuso> right
 * TheMuso goes to do just that.
<tjaalton> TheMuso: also, if you have one please attach the good Xorg.0.log
<persia> TheMuso: The data read-edid would be getting from the monitor, giving resolution, refresh rates, etc.
<TheMuso> persia: RIght.
<TheMuso> tjaalton: I can get that from another machine on the same KVM that is correctly configured to work with the monitor.
<tjaalton> TheMuso: did it work OOTB?
<TheMuso> OOTB?
<tjaalton> out-of-the-box
<TheMuso> tjaalton: No, I ran dpkg-reconfigure xserver-xorg, this is on hardy, a little while back.,
<TheMuso> As I said, KVM not supporting monitor probing.
<tjaalton> TheMuso: oh right
<tjaalton> yep, and since you can't select a valid resolution you're doomed
<TheMuso> Yep.
<tjaalton> TheMuso: so, I'm not sure yet if it can be fixed by the server, but at least it should be possible to force the resolution using displayconfig-gtk or similar
<TheMuso> Ok
<TheMuso> tjaalton: Off hand, is there any bug that is similar, so I'm not creating a dup?
<tjaalton> TheMuso: not that I remember
<persia> tjaalton: displayconfig-gtk reacts poorly to not having a valid edid and not being able to get one from the monitor.
<TheMuso> tjaalton: ok thanks
<TheMuso> filing now
<tjaalton> persia: yeah, I realize that, but perhaps it could be extended somehow
<persia> tjaalton: Right now it asks for an EDID if it can't get one, and generally flails when given the wrong one.  Perhaps defining a generic set for 10 or 15 standard sizes as fallbacks?
<TheMuso> or allowing the user to enter the info manually.
<TheMuso> WHen I usually run dpkg-reconfigure xserver-xorg, I enter monitor refresh rates, and select resolutions manually.
<TheMuso> Bug 177852
<ubotu> Launchpad bug 177852 in xorg-server "Unale to manually configure monitor resolution and refresh rate with latest xorg-server in hardy." [Undecided,New] https://launchpad.net/bugs/177852
<tjaalton> TheMuso: thanks
<TheMuso> tjaalton: np.
<kagou> Good morning
<pitti> hi kagou
<kagou> hey pitti, what's up ?
<StevenK> slangasek: I got told this after the 46 uploads I did made the change.
<slangasek> StevenK: haha
<slangasek> StevenK: well, you get to merge them next release cycle ;
<slangasek> )
<ion_> Heh
<StevenK> Or get a shedload of mail saying "You have lots of merges, can I do them all?"
<pitti> argh, these reboots between .24 and .22 are unnerving, brb
<slangasek> to balance things out, I'll send you a mail saying "You have lots of merges, can you do them all?"
<StevenK> Hah
<geser> good morning
 * slangasek moos
<dholbach> hey pitti, hey mvo
<mvo> hey dholbach!
 * pitti hugs dholbach
 * dholbach hugs pitti and mvo
<pitti> dholbach: just rebooted :)
<pitti> .24 still has a few wrinkles
<geser> Hi pitti
<ulaas> anybody interested with install problems (gutsy) on an intel c2duo imac?
<ulaas> anybody interested with install problems (gutsy) on an intel c2duo imac?
<ion_> Is it just me, or does it echo in here?
<ulaas> u?
 * Fujitsu notes that it does echo, and that this isn't a support channel.
<seb128> echo echo echo
<ulaas> easy! :) i know that this is not the support channel. i just thought that people here might be more interested than in #ubuntu
<mvo> ohce
<seb128> hey mvo
<mvo> hey seb128
<mjj29> so, my dbus-java build from yesterday was retried, and the b-d installed fine
<mjj29> but it still failed because the buildd is not using a UTF-8 locale
<slangasek> sounds like a source bug on your end to me ;)
<mjj29> (the tests have utf8 string literals to check that utf8, which is the defined format for dbus strings, works; java interprets string literals in the current locale)
 * Fujitsu wonders if python-apt can be used to poke around in source caches too.
<mjj29> and the tests are run at build time to check for regressions
<mjj29> I'm not sure how best to fix this
<slangasek> mjj29: there are various examples of packages in the archive that build-depend on locales and generate a copy of locales that they need locally; your package should either do this, or not expect utf8 support
<mjj29> slangasek: is there an easy way to find one of these to crib from?
<slangasek> mjj29: grep-dctrl -FBuild-Depends locales ? :)
<mjj29> slangasek: thanks
<slangasek> ipolish looks like a pretty straightforward one
<TheMuso> tjaalton: Re the bug I filed, I've just connected the monitor directly, and re-run displayconfig-gtk. The bug has the relevant log and info.
<slytherin> pitti: There are several java libs/apps which need to be moved to universe. I have logged a tracking bug which is confirmed by geser. Is there any chance it will get processed today?
<tjaalton> TheMuso: ok thanks
<pitti> slytherin: yes, can do; however, I just recently promoted a few because OO.o needs them; where's the bug?
<slytherin> pitti: bug 176139
<ubotu> Launchpad bug 176139 in libtoolbar-java "Please move package to universe" [Wishlist,Confirmed] https://launchpad.net/bugs/176139
<pitti> slytherin: ah, from multiverse to universe; that's fine
<pitti> slytherin: will get to it in a minute
<soren> What's the story about all the different db4.x? I remember we were trying to get rid of one or more of them from main..
<slytherin> pitti: Thanks. :-)
<pitti> soren: right; if you happen to upload something that can be moved to 4.6 (libdb-dev), please do
<pitti> that will cut down the mass-rebuilds later
<soren> pitti: I figured as much. I wonder why apache is still built against db4.4..
<pitti> soren: not sure; packages which use on-disk transactions are a PITA to migrate, but apache doesn't sound like something that would use them
<soren> pitti: Not transactions, no. Rewrite rules.
<soren> pitti: ...and they are even worse, as they can be scattered all over the place.
<pitti> soren: anyway, if grep -r DB_TXN doesn't bring up anything, then it's safe to move
<pitti> (that's a sufficient, but not necessary condition, BTW)
<soren> pitti: Oh, apart from transactions, the binary formats are compatible?
<pitti> soren: yes; the API might have changed slightly, but most packages I stumbled across just build fine with any version
<soren> pitti: Oh, it *builds* fine, I think. The thing I'm worried about are the existing databases of rewrite rules people might have  suddenly stop working.
<pitti> soren: the db format itself didn't change, just the transaction log
<soren> pitti: Ah, cool. Thanks.
<soren> Mithrandir: Can you think of any particular reason why apache must be built against db4.4 ?
<thom> has svn changed?
<thom> that's always the problem child for apache
<soren> thom: Ah..
<soren> thom: Not that I know of.
<thom> well, that's the one. apr and svn and apache2 need to be in lockstep
<soren> Sure. And php, too (which was what I was actually looking at).
<thom> otherwise there is wailing and gnashing of teeth
<pitti> so we can change them all at the same time?
<soren> pitti: I have no clue what would be required to make subversion work with db4.6.
<thom> soren: well, it rather depends what the upgrade path is for a db4.4 db to a db4.6 db
<soren> pitti: ...but yes, upgrading the all at the same time is the (only) way to go, I believe.
<soren> thom: Well, according to pitti, it's only the transaction log that changed, so we'd need to rebuild against db4.6 and make sure that anything that's using libsvn is restarted, otherwise we're in trouble, I suspect.
<thom> then rebuilding should be fine, since apache restart will get mod_svn and i assume that the subversion package will restart any long running svnserve processes
<thom> check that though
<sivang> slomo !
<slomo> hi sivang
<pitti> hey slomo, how are you?
<slomo> pitti: i'm fine, thanks :) and you? :)
<pitti> bit stressed, but good (need to find some christmas presents still, though)
 * soren decides not to change subversion, apache2, *and* php5 to a new db4.x version on the last day before holiday.
<siretart> slomo && sivang ! :)
<siretart> slomo: did you have the chance to look at ffmpeg from experimental yet again?
<soc> hi
<slomo> siretart: works good for me :)
<soren> What happened to the alpha, by the way?
<soc> does someone know the plans for ati gpus in 8.04?
<soc> which driver will be used as a default?
<StevenK> pitti: If you have a sec, I want to discuss the gimp SRU. The one I uploaded FTBFS, what is the next step, aside from test building more. :-(
<soc> and will the fglrx version in the repos be updated?
<slomo> siretart: imho can go to unstable
<soc> because 7.11 contains a nasty meory-leak
<siretart> slomo: I have rebuilt the archive against the new ffmpeg, but didn't do larger tests yet
<siretart> slomo: did you try it on ppc as well?
<pitti> StevenK: just upload a fix
<slomo> siretart: nope, only x86... and i didn't do larger tests yet but only "used" it :)
<siretart> I think sam wants to have another look at the altivec patches before letting it into unstable
<thom> soren: heh, seems sensible
<siretart> slomo: how do you feel pushing it to hardy?
<StevenK> pitti: Suggest for version number, since I seem to loose at picking them.
<pitti> StevenK: ...7.10.1?
<pitti> 7.11 would be bad :)
<slomo> siretart: well, get it into unstable and sync :)
<StevenK> Heh, yes
<StevenK> pitti: 7.11 is what dch did by default :-)
<siretart> slomo: I fear that this will take some more time, and won't make it before hardy freeze
<siretart> having it tested in hardy would help here, otoh
<siretart> slomo: how about this: we modify mplayer to use its internal ffmpeg, and build a shared ffmpeg library from it, and link the world against that?
<slomo> siretart: then better get the experimental ffmpeg to hardy
<slomo> siretart: it's from the same day anyway, no? :)
<siretart> slomo: exactly for this reason. the 'build ffmpeg from mplayer' approach would leave us with 2 versions of ffmpeg and additional flexibility
<slomo> i don't see any advantage in this... but if you think it's better... :)
<slomo> bbl
<siretart> slomo: wait a sek!
<siretart> hm. too late
<geser> pitti: have you an idea how an .orig.tar.gz can vanish during build? http://launchpadlibrarian.net/10082300/buildlog_ubuntu-hardy-i386.mush_7.2.5unoff2-25_FAILEDTOBUILD.txt.gz
<geser> it builds fine in a hardy pbuilder so perhaps a give-back should be tried
<cjwatson> that looks like the package is assuming that its .orig.tar.gz is present in .., which isn't necessarily true on a buildd
<cjwatson> I think that's a bug in the package, and it's going to have to find some other way to do the same thing
<pitti> whoa, how strange
<cjwatson> perhaps using pristine-tar to regenerate the .orig.tar.gz?
<zul> hello
<pitti> but how can this happen in dpkg-deb?
<cjwatson> it's not
<cjwatson> read mush/debian/rules
<pitti> ah, ok
<cjwatson> dpkg-deb is just the previous thing that's done
<geser> cjwatson: thanks for the explanation
<StevenK> pitti: gimp uploaded, please accept at your leisure.
<geser> pitti: as build-depending on sun-java[56]-* seems to work now, please give-back: lucene2 libglazedlists-java jbidwatcher javassist glassfish. Thanks
<pitti> geser: \o/ done
<Fujitsu> geser: ooh, how'd you manage that?
<geser> Fujitsu: infinity did some black magic on the buildds
<pitti> Fujitsu: debconf preseeding for the license question
<Fujitsu> Ahh.
<Fujitsu> I think batik wants that too.
<Fujitsu> (giving back, that is. It b-d on some JRE)
<slytherin> geser: How is it working?
<slytherin> geser: I mean build-depends on sun-jdk?
<geser> Fujitsu: I don't think j2sdk1.4 uses the same debconf question
<geser> slytherin: if it builds with the sun-java packages updating the build-depends should allow it to get build on the buildds
<slytherin> I think then batik build can be fixed. But I will be very much interested to have batik 1.7 when it releases as it compiles with GCJ. :-)
<geser> slytherin: any date known for the new release?
<slytherin> nope
<pitti> tjaalton: hm, xserver-xorg-driver-all wants to go to universe; was this dependency deliberately dropped?
<pitti> oh, it's called -video-all nwo
<tjaalton> pitti: no that's a new transitional package
<pitti> so we should seed it for dapper upgrades
<tjaalton> requested by mvo
<pitti> ok, seeding; thanks
<mvo> pitti: having it in main helps dapper->hardy upgrades
<mvo> (and having it at all :)
<mvo> thanks pitti (and tjaalton for adding it!)
<pitti> committed
<jpatrick> hmm, could someone tell me why I've just gotten a "Accepted: pulseaudio 0.9.6-1ubuntu2~feisty1 (source)"?
<pitti> jpatrick: because you or someone else from the backporters team requested a feisty backport
<jpatrick> ah, ok
<pitti> ArneGoetje: FYI, fontforge is depwaiting on libspiro-dev; that needs a MIR, or we demote fontforge to universe (which might be adequate)
<stgraber> slangasek: You can rename builds on the tracker (through the milestone management page), the download info page is to be completely reworked as soon as we have a .manifest file on cdimage (parsing the cdimage isn't a good idea at all :))
<stgraber> your last night problem was certainly some hardcoded gutsy in the cdimage parser, I'll have a look and get that fixed
<stgraber> slangasek: it was indeed some hardcoded "gutsy", I changed them to hardy and it seems to work again
<dholbach> MOTU Q&A session in 11 minutes in #ubuntu-classroom
<cjwatson> dholbach: I think I'm off your sponsoring hitlist now
<pitti> mjj29: ah, I saw your dbus-java commits, thanks
<dholbach> cjwatson: I just noticed - thanks a lot for that, you ROCK!
<dholbach> cjwatson: and thanks for your input in the MOTU Meeting
<Keybuk> seb128: hmm, that was odd; xchat-gnome's lock ups were permanent this morning
<seb128> Keybuk: did you try removing pulseaudio?
<Keybuk> yes, that's how I got online :-)
<Keybuk> oddly enough, this seems to have also made flash sounds work again -- I'm not sure that this is a good thing
<seb128> I'm wondering why xchat-gnome hangs when pulseaudio is used though
<ogra> Keybuk, you likely need libflashsupport for flash sound with pulse (not sure if tahts also needed for non networked pulse sound though, we need it in ltsp since we use pulse there)
<Keybuk> ogra: is that packaged?
 * ogra wonders why the binary wasnt built yet ... it was accepted a while ago
<ogra> Keybuk, yes, but no binary it seems
<jpatrick> pitti: is it normal that that backport should be marked as uploaded by me?
<ogra> Keybuk, https://launchpad.net/ubuntu/hardy/+source/libflashsupport/1.9-0ubuntu1
<Keybuk> jpatrick: if you requested it, yes
<jpatrick> Keybuk: I did not. Nor have I ever touched pulseadio
<jpatrick> pulseaudio*
<seb128> did you approve the request?
<jpatrick> No
<seb128> what upload do you speak about?
<jpatrick>  pulseaudio 0.9.6-1ubuntu2~feisty1
<seb128> no idea about this one, when did you get a mail about the upload?
<cjwatson> sounds like somebody made a mistake when doing the backport
<cjwatson> it's a manual process ...
<dholbach> can somebody give me a debian policy reference to why things like        #!/usr/bin/env python          are discouraged?
<jpatrick> yes, I did get a mail about it
<dholbach> we're just discussing it in #ubuntu-classroom (MOTU Q&A session)
<dholbach> http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html  comes close to the topic
<seb128> dholbach: the page seems to have all the required informations
<dholbach> ok... so do you know of a "standard list of interpreters"?
<persia> seb128: What about non-python use of env?  Is there a general policy, or is it interpreter-specific for python?
<seb128> persia: similar situation I would say
<persia> seb128: makes sense.  Thanks.
<seb128> when using env you are not sure the system version of the interpreter is used
<seb128> you are welcome
<ogra> ogra@ceron:~/devel/livecd-rootfs/trunk$ grep sanitize livecd.sh
<ogra>     I)	UINUM=$(sanitize int "$OPTARG");;
<ogra>     m)	OPTMIRROR=$(sanitize url "$OPTARG");;
<ogra>     S)	USZ=$(sanitize int "$OPTARG");;
<ogra> does anyone have a clue what sanitize is ?
<ogra> its no internal function in the script and not sourced anywhere
<ogra> (so using -m breaks)
<Chipzz> seb128: I'ld say that page does not have all the required information
<Chipzz> dholbach: using /usr/bin/env has a big drawback as opposed to just specifying the path (which IMHO you should)
<dholbach> Chipzz: thanks we clarified it in the meantime
<Chipzz> dholbach: using /usr/bin/env makes it impossible to specify command-line arguments or switches to python (or perl) for example
<Chipzz> dholbach: I was not finnished yet ;)
<Chipzz> now I am ;)
<Robot101> so are there metacity bling packages yet? :)
<dholbach> thanks Chipzz
<seb128> Robot101: they are called compiz ;-)
<Chipzz> dholbach: a simple example in the perl case is #!/usr/bin/perl -w (although you can also do that with use warnings)
<seb128> Robot101: otherwise the new version is not uploaded yet but will be likely today
<seb128> I'm working on glib and gvfs now though
<^sa^> hello. i have some problems about the configuration of my wifi
<Chipzz> persia: ^^^ in case your interested (and non-python use of env should be discouraged IMHO)
<^sa^> (first of all sorry for my bad english :P i'm italian)
<Chipzz> s/your/you're/
<Robot101> seb128: I want a window manager, not compiz. :P
<persia> Chipzz: Yes.  I saw it.  I'm not a fan of env, more curious about things like #!/usr/bin/make in a script in /usr/bin/
<^sa^> the problem is that my wlan works perfectly on the live cd but not on the installed ubuntu
<Chipzz> persia: make requires -f :)
<jdstrand> ^sa^: no problems with your english, but this is not the right channel.  you'll get more help on #ubuntu
<Chipzz> persia: so far make it's impossible to use env in the first place :)
<Chipzz> s/far/for/
<^sa^> i've gone in ubuntu-it and they couldn't help
<^sa^> we tryed almost everything
<^sa^> so i supposed it's a bug and i come here to report it
<jdstrand> ^sa^: https://bugs.launchpad.net/
<cjwatson> ogra: introduced in r29; ask lamont what he was thinking? :)
<^sa^> or maybe you have a soluction
<^sa^> what can i do?
<Chipzz> ^sa^: although this is not a bug report channel, you could ping asac; he may be able to help?
<Chipzz> (hopes he won't get asac's wrath over him now :P)
<^sa^> ok but i dont know what to write. can't you help me?
<Chipzz> no I cannot ;P
<^sa^> what should i post in the website?
<Chipzz> I'm not an expert wrt wireless drivers
<cjwatson> Chipzz: he's on holiday
<jdstrand> me either :(
<Chipzz> cjwatson: ah, I wanted to ask you about something :)
<lamont> cjwatson: context?
<lamont> ah.  livecd
<Chipzz> cjwatson: wrt to the bug about ubiquity window being to big to fit on small screens (since you're mentoring that bug); what do you think about the recent GTK+ patches wrt natural size as a solution to that bug?
<jdstrand> ^sa^: you may find some answers in the link I gave.  If not, report the bug.
 * persia is suspicious of "Natural size", having a 200DPI display on one device.
<cjwatson> Chipzz: that should go to evand nowadays. It may help, certainly, but I haven't looked at them in any detail; the timezone page will still need to be shrunk I expect
<cjwatson> persia: I don't think that's what it means ...?
<cjwatson> it's about pixel-level sizing of widgets, not much to do with DPI
<Chipzz> persia: it's about widgets not taking up the maximum space they could possess
<persia> cjwatson: Ah.  I misunderstood "natural" then.  I feared real-world measurement, which is annoying for handhelds.  Thanks for the clarification.
<lamont> cjwatson: no clue on sanitize.
<Chipzz> persia: the relevant discussion is at http://mail.gnome.org/archives/gtk-devel-list/2007-November/msg00145.html in case you're interested
<persia> Chipzz: Thanks.  That's much clearer than the API docs I was reading :)
<Chipzz> cjwatson: anyway, you may want to add a comment on that bug (https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/38442) in case you're not mentoring it anymore? ;)
<ubotu> Launchpad bug 38442 in ubiquity "Ubiquity dialogues too large for 800x600 display" [High,Confirmed]
<Chipzz> cjwatson: anyway, I added a comment to the bug with a link to the relevant discussion on gtk-devel ;)
<Chipzz> (that's a lot of anyways :P)
<ion_> The newest fontconfig seems to have a problem with lcdfilter being set as legacy in config.
<ion_> Ah, the syntax has changed to lcd_filter=lcdfilterlegacy.
<Ubulette> ion_, yes, you need the new libcairo to go with it
<seb128> ion_: do you get any error on ugprade or something?
<ion_> seb128: Yes, about a config file i created.
<seb128> ion_: does that break the update?
<ion_> seb128: Nope, they were just warnings.
<seb128> ok, so that's alright
<ion_> Whatever updated fontconfig caches was printing them.
<ion_> Yeah
<geser> pitti: please give-back: sleepd wmbattery python-xlib qbankmanager pnscan pmx pica ounit mrwtoppm. Thanks
<Mithrandir> soren: db4.4 for apache> svn?
<soren> Mithrandir: Yes, thom filled in the blanks.
<soren> Mithrandir: Thanks, though.
<slytherin> pitti: ping
<seb128> slytherin: you should give some context so maybe somebody else can reply
<slytherin> As just asked the question on MOTU channel. It has more do to with moving a -doc package from multiverse to universe.
<tkamppeter> Anyone can help me on a problem with a a package which we auto-sync from Debian?
<persia> tkamppeter: Which package?
<tkamppeter> It is about bug 177359, python-cups
<ubotu> Launchpad bug 177359 in python-cups "python-cups needs update (system-config-printer.py crashed with SIGSEGV in PyObject_Malloc())" [Medium,Triaged] https://launchpad.net/bugs/177359
<tkamppeter> Tim Waugh, upstream author of python-cups and system-config-printer has fixed this bug upstream in python-cups.
<persia> tkamppeter: Three choices: 1) backport the changes (likely wasted effort). 2) Work with debian for an update, and request a sync (freeze exception).  3) update the package directly, and make sure Debian uses the same orig.tar.gz.
<persia> tkamppeter: Depending on your relationship with the Debian maintainer, one of 2) or 3) is likely easiest.
<tkamppeter> persia thanks, Otavio Salvador has offered me collaboration on system-config-printer (git write access at alioth). So I will option 3 and I think he will overtake it (is a straight upstream update, no patches, no changes in debian/).
<persia> tkamppeter: Excellent :)
<tkamppeter> persia, package is already build, was trivial
 * persia blesses upstreams that prepare releases for painless updates
<tkamppeter> Haver pitti and doko already left for Christmas?
<pitti> re
<pitti> was at a phone call
<pitti> give me some more minutes to write down my brain status, then I'll catchup
<pitti> geser: done
<tkamppeter> hi pitt, can you upload some packages into main for me today? python-cups and system-config-printer?
<pitti> hm, slytherin left already
<pitti> tkamppeter: can you please mail me the URL? I'll try to make it (sorry, still 100 things to get done)
<tkamppeter> pitti, I will do so.
<persia> pitti: slytherin is investigating, and filed a bug about the multiverse -> universe bit.
<tkamppeter_> pitti, python-cups is ready now, biff.
<seb128> pitti: did you do something to esd?
<pitti> persia: ok, thanks
<pitti> seb128: define something? (no, not recently, except for demoting it)
<seb128> pitti: I was trying to pbuild the new rhythmbox but libgnome is not installable because it depends on libesd0 or libesd0-alsa which are not available
<seb128> pitti: you demoted those then, which explains the issue
<pochu> seb128: rhythmbox is mine! :P
<pochu> seb128: are you doing it?
<pitti> argh, I meant to demote the esound *binary*
<seb128> pochu: already uploaded
<seb128> pochu: sorry
<pochu> heh
<pitti> seb128: sorry, fixing
<pochu> seb128: no worries, I didn't start it yet ;)
<pitti> done
<seb128> pitti: danke
<seb128> pochu: usually I would have updated the wiki but I wanted that to be done before my holidays
<pochu> seb128: do you start them today?
<seb128> pochu: yes, after work
<seb128> pochu: I expect I'll still be reading mails etc during holidays though
<pochu> Merry Christmas then ;-)
<geser> pitti: could you also move commons-httpclient from multiverse to universe (a new task in bug #176139) (one binary is already in universe)
<seb128> pochu: thanks, to you too ;-)
<pitti> geser: done
<tkamppeter_> pitti. system-config-printer is now prepared for a crash-free Christmas (4 crashers fixed + 1 in python-cups), see your mail.
<pitti> cool :)
<pitti> so people can print out all their greeting cards and present labels :)
<tkamppeter> Yes, and they can set up their printers which they get as present (at least if the person who has given the present has read OpenPrinting's Christmas list before).
<pitti> if they are using hardy anyway
<pitti> oh, gone again already
<keescook> mjg59: congratz on the phd submission.  :)
<mjg59> Thanks!
<bigon> is that normal that libc6-amd64 package in installed on my 32bit system?
<geser> bigon: I've seen it in my i386 installations too
<pitti> bigon: no, that's a bug
<bigon> ok
<pitti> keescook: do you happen to have an opinion about http://launchpadlibrarian.net/10983343/php5_5.2.3-1ubuntu6.3.dsc.diff ?
<pitti> keescook: that's a proposed SRU for php in gutsy, to switch from db4.5 to db4.4
<pitti> keescook: that would be in sync with libsvn1 (also 4.4 in gutsy), but I'm a bit nervous about doing that to a stable release
<pitti> well, it was always *meant* to link against 4.4 at least
<keescook> pitti: well, I've seen a number of db4 issues in php5 that I haven't figured out yet
<keescook> pitti: if that solves the crashes that I can't reproduce, then I'm all for it.  ;)
<keescook> pitti: I have concerns over php applications that used db4.5  (mediawiki?) but again, I haven't been able to reproduce the issues (173817)
<pitti> keescook: sounds like another damned if you do/damned if you don't issue
<pitti> (and just reinforces my desire to get rid of the duplication in hardy)
 * keescook nods
<seb128> pitti: could you give a retry to rhythmbox on all arches? It failed due to the esound to universe
<pitti> seb128: done
<seb128> pitti: danke
<seb128> pitti: rhythmbox failed again the same way, are you sure you promoted libesd*?
<pitti> yes, I am
<seb128> hum
<pitti> the second time I was sure that I used the right commands
<pitti> libesd0-dev | 0.2.38-0ubuntu4 |         hardy | amd64, hppa, i386, ia64, lpia, powerpc, sparc
<seb128> how long ago was that?
<pitti> hm, esound is back in main
<pitti> WTH?
<pitti> seb128: publisher finished about 10 minutes ago
 * pitti gives back again
<seb128> ah ok
<seb128> thanks
<seb128> I though that was some hours ago already
<pitti> so, if they all land in universe again now, we have a soyuz bug
<pitti> I could have attributed the first failure to my wrecked brain today, but not the second one
<dholbach> Merry Christmas and all the best in 2008 to everybody! See you soon again!
<pochu> Take care dholbach
<dholbach> pochu: you too
<jcastro> dholbach: have a good one!
<dholbach> jcastro: you too
<pitti> warp10: sent you a review of tennix
<warp10> Pitti: just got it. Thank you!
<shaya> wondering if anyone is working on integrating new fglrx drivers into lrm, impt as they now work on firegl cards (think thinkpads)
<sladen> shaya: look at the change logs of the relevant package and find out who has worked on it recently
<sladen> shaya: then you can ask them directly
<shaya> BenC: you here? :)
<BenC> shaya: hardy has latest ati drivers, IIRC
<shaya> new ones came out yesterday
<shaya> latest package is 12/19
<shaya> http://ati.amd.com/support/drivers/linux/linux-firegl.html
<BenC> shaya: will be after new year most likely
<shaya> ok
* slangasek changed the topic of #ubuntu-devel to: Hardy Alpha 2 released | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs" | HELP TESTING: https://iso.qa.stgraber.org
<TheMuso> slangasek: Thanks a bunch for 1) making ubuntustudio alpha images, and 2) announcing them in the main alpha 2 announcement.
<slangasek> TheMuso: my pleasure; unfortunately I don't believe we got any ISO tests of them prior to release, which makes me nervous.  going forward, aside from getting images into a testable state farther in advance, what's the best way to tap you guys about getting them tested before release?
<slangasek> TheMuso: (also: would you care to test them now to confirm that it really boots? :/)
<TheMuso> slangasek: Well there are a few of us who are testing the dailies regularly, and I've been making sure our seeds are up to date, and we have no uninstallable packages leading up to alpha2, so if the installer gets tested elsewhere, and same with GNOME, that covers us for the most part.
<TheMuso> slangasek: I don't have long till I have to get ready to head out, but I'll sync and see if they do boot and install, but I'm reasonably confident that they will be ok.
<TheMuso> We are trying to get more community help for testing, but some people in our dev group haven't really bene pulling their weight.
<slangasek> TheMuso: right, sounds good
<slangasek> TheMuso: in terms of release management and release confidence, if people are testing dailies it would be good to have the results documented on https://iso.qa.stgraber.org; which means it would also be good if I have a designated point of contact that I can notify when candidates are published there
<TheMuso> slangasek: And as it is, -rt didn't land for alpha 2 for us, so kernel wise, theres nothing to test, but once -rt lands for later alphas, then we really need to be sure we get good testing, particularly with apps that need such a kernel.
<slangasek> sure
<TheMuso> slangasek: Right.
<TheMuso> -rt as in for 2.6.24
<slangasek> yes
<slangasek> I know -rt, it caused us some problems during the milestone prep :)
<TheMuso> I saw that.
<TheMuso> slangasek: As it seems you and I tend to be around at similar times, I am happy to be pinged aobut candidate images in the future. Even if I'm not around, I am idling on IRC< so will get the ping, and test at my earliest convenience.
<slangasek> ok
<TheMuso> I try at least once a day to check the state of our images, usually right after the latest gets built.
<slangasek> right - in the case of a milestone, the time when it gets built becomes variable :-)
<TheMuso> I am aware of that.
<TheMuso> So around alpha times, I do tend to check more often where possible.
 * slangasek nods
 * TheMuso kicks off a test install of ubuntustudio, and goes to get ready.
<tjaalton> slangasek: hmm, bug 173008 (mentioned on the relnotes) should be fixed now
<ubotu> Launchpad bug 173008 in xorg "keyboard selection (dvorak) not preserved after install in hardy" [Medium,Confirmed] https://launchpad.net/bugs/173008
<tjaalton> sorry for not closing it in time
#ubuntu-devel 2007-12-22
<slangasek> tjaalton: ah, ok; thanks for following up then :)
<lamont> if I import a pdf in the gimp as layers, how can I save that such that I get a multi-page doc?
<nny_1> why are 2.6.22-14 has no headers listed in hardy repos???
<nny_1> er reformat
<nny_1> why doesn't 2.6.22-14 have no headers in repos*
<nny_1> lol close enough
<nny_1> but yeah i can't build against the 2.6.22-14 kernel without source
<Hobbsee> why do you want to?
<nny_1> Hobbsee: compile zaptel
<Hobbsee> it's not the latest kernel...
<nny_1> Hobbsee correct!
<nny_1> Hobbsee but apt-get upgrade doesn't provide the 2.6.24-2, and i am having issues building zaptel with that kernel/source combo
<keescook> Hobbsee, can you look at the build failures of celestia 1.4.1+cvs20070626-3ubuntu3?  That's a transient problem, right?
<Hobbsee> nny_1: linux-headers-2.6.24-2 - Header files related to Linux kernel version 2.6.24
<Hobbsee> appaers to be there
<nny_1> yes, but not linux-2.6.22-2
<nny_1> er 2.6.22-14*
<nny_1> and if i do an apt-get upgrade, which I assume means, latest suggested packages, it doesn't try to move the kernel up to the latest version
<nny_1> so* I tried using it anyways, and it screamed
<nny_1> make[2]: Entering directory `/usr/src/linux-headers-2.6.24-2-server'
<nny_1> scripts/Makefile.build:46: *** CFLAGS was changed in "/usr/src/zaptel-1.4.7.1/Makefile". Fix it to use EXTRA_CFLAGS.  Stop.
<nny_1> make[2]: *** [_module_/usr/src/zaptel-1.4.7.1] Error 2
<nny_1> make[2]: Leaving directory `/usr/src/linux-headers-2.6.24-2-server'
<nny_1> make[1]: *** [modules] Error 2
<nny_1> make[1]: Leaving directory `/usr/src/zaptel-1.4.7.1'
<nny_1> make: *** [all] Error 2
<nny_1> gah
<nny_1> dangit
<Hobbsee> yeesh.  pastebin, perhaps?
<nny_1> pidgin as an IRC client FTL
<nny_1> Hobbsee: ya think? i wasn't intending for it to line break
<Hobbsee> install it manually.  or install linux-headers-generic to automatically pick them up
<nny_1> muwhaahaha
<nny_1> nope
<nny_1>   linux-headers-2.6.24-2 linux-headers-2.6.24-2-generic linux-headers-generic
<nny_1> sigh.. so wait, hardy doesn't suggest I use the latest kernel, but gives me no method for compiling against the current one... this is a bug methinks
<Hobbsee> hardy does now.
<StevenK> So you edit that Makefile to use EXTRA_CFLAGS, not CFLAGS
<Hobbsee> you presumably don't have the latest package "linux" installed
<Hobbsee> it's not a bug that you havent' gotten the correct metapackages installed (and yes, the dist-upgrader checks for this)
<slangasek> nny_1: you're not going to get linux-headers-2.6.22-14 anymore, that's an old kernel.
<StevenK> It should still be linux-generic / linux-server, surely?
<nny_1> StevenK: yeah was gonna do that.. but i have numerous other things to compile, and that error got me thinking otherwise.. trust me, i wouldn't use alpha for this if i didn't need something that was only in sid/hardy's repos AFAIK
<persia> Hobbsee: Only upgrade-manager checks that.  Apt-get allows broken systems.
<StevenK> nny_1: Then why not backport what you want to Gutsy? I would.
<nny_1> ok well, i did an install, apt-get update, apt-get upgrade and this is what i have
<nny_1> StevenK: i spent 9 hours trying to do that with the original dapper install, and it got angry...
<Hobbsee> persia: this is true
<StevenK> Note I didn't say Dapper
<nny_1> persia: upgrade manager doesn't run on a server
<nny_1> StevenK: indeed
<nny_1> StevenK: mind you i am battling libsnmp9 badness
<nny_1> heh who am I kidding, it's all a science project
<persia> nny_1: Good point.  Likely a bug.  I'll file that.
<StevenK> Upgrade manager will be put into Dapper before Hardy releases
<nny_1> persia: no problem, was only curious as to which version *I* should be using on server
<nny_1> since there is no GUI on this box
<persia> nny_1: I tend to use aptitude for servers, but there ought be a CLI update-manager to make it easier.
<Fujitsu> update-manager-core has the CLI one, doesn't it?
<nny_1> StevenK: yeah i agree with the gutsy thing. this is more of, I had stable asterisk running on dapper, want to get snmp working for many many more servers later, figured since we only use LTS for these that Hardy alpha would be a good time to try it
<nny_1> persia: noted.. i switch between aptitude and apt
<nny_1> I assume the cflags issue means EXTRA_CFLAGS+=-DSTANDALONE_ZAPATA -DBUILDING_TONEZONE (added the EXTRA_)
<StevenK> Right
<nny_1> hrmm
<nny_1> seems to be happier.. wait for it.. nope shoot
<nny_1> same error
<nny_1> let me see if their are other areas in the Makefile
<nny_1> ahh foudn it my bad
<nny_1> lol i don't even want hotplug support :\
<nny_1> lol well heck
<nny_1> i installed th enew image, but still running the old one
<nny_1> lol reboot
<nny_1> again
<nny_1> :)
<DoubleDave> good evening everyone
<ubergoober> l
<DoubleDave> anyways hows things in here tonight?
<warp10> Hi all!
 * Hobbsee looks at celestia for keescook
<Hobbsee> keescook: i'm hoping that's transient.  if not, i'll look at it again.
<ion_> celestia has failed to upgrade for a while, but i havenât got around to reporting a bug yet.
<ion_> dpkg: error processing /var/cache/apt/archives/celestia-gnome_1.4.1+cvs20070626-3ubuntu2_i386.deb (--unpack):
<ion_>  trying to overwrite `/usr/share/celestia/data/asteroids.ssc', which is also in package celestia-common
<persia> ion_: The bug exists.  I'll dig it up for you.
<Hobbsee> darn, it's not transient
<Hobbsee> hum, damh
<Hobbsee> er, damn
<Hobbsee> would probably be nice to do another upload for that
<persia> bug #176576
<ubotu> Launchpad bug 176576 in celestia "package celestia-kde None [modified: /var/lib/dpkg/info/celestia-kde.list] failed to install/upgrade: trying to overwrite `/usr/share/celestia/data/asteroids.ssc', which is also in package celestia-common" [High,Fix released] https://launchpad.net/bugs/176576
<persia> Hobbsee: Yes.  It needs versioned conflicts/replaces set properly.
<Hobbsee> uhhhhhhhhhhh
<Hobbsee> cprov......
<Hobbsee> lamont: fairly urgent ping
<Hobbsee> the buildds shouldn't be that empty, i'm sure
<Hobbsee> unless everything is takign 40 seconds to fail
<ion_> persia: Thanks
<Hobbsee> keescook: okay, that looks like fairly big "Soyuz has FUBAR'd"-type problems.
<Hobbsee> but damn, lamont had better like seeing the hppa's down to 0 builds.
<Hobbsee> keescook: s/Soyuz/GNOME/
<geser> Hobbsee: looks like esound-common got lost in hardy
 * persia thought that was intentional, as part of pulseaudio-by-default
<Hobbsee> so, uh, where is it?
<geser> persia: but then it makes libesd-alsa0 and libesd0 uninstallable
<Fujitsu> That binary is still built.
<Fujitsu> I think Soyuz got confused.
<Hobbsee> Fujitsu: well, exactly
<Fujitsu> It doesn't seem to exist in the archive, but the SPR page says it does.
<geser> and many packages still depend on libesd
<Fujitsu> But that source has had bad things done to it.
<persia> geser: In the case of libesd0, that's a good thing (in my book).  In the case of libesd-alsa0, perhaps it needs to be done differently.  Anyway, I see 0.2.38-0ubuntu4 in the pool.
<Fujitsu> geser: Like libgnome, so the world has exploded.
<Hobbsee> source hasn't appeared to change since gutys
<geser> Hobbsee: pitti moved libesd yesterday from main to universe and back to main
<geser> perhaps soyuz ate it
<Fujitsu> That's what I discovered and suggested in #launchpad... I don't think Soyuz liked it much.
<Hobbsee> ohhh.....
<Fujitsu> That binary has vanished.
<persia> Hrm.  pulseaudio-esound-compat Provides; esound.  Perhaps that's insufficient.
<Hobbsee> Fujitsu: what's the status of the build?
<Fujitsu> persia: esound-common
<Hobbsee> Fujitsu: failed to upload, by any chance?
<Fujitsu> Hobbsee: What build?
<Hobbsee> esound, i think
<Hobbsee> Fujitsu: or anything that built that depended on it
<persia> Fujitsu: That's just documentation, and doesn't have an rdepend from gnome from my cache.
<Fujitsu>   libesd0: Depends: esound-common (>= 0.2.38-0ubuntu4) but it is not installable
 * Hobbsee wonders what happens if you rebuild libesd0
<geser> Fujitsu: not only Gnome broke on the missing esound-common but also KDE
<Fujitsu> geser: Yay.
 * persia suggests replacing libesd0 with something else.  Purging the package doesn't break GNOME.
 * Hobbsee ponders uploading a no-change-rebuild, and seeing what happens
<Fujitsu> I suspect Soyuz didn't process-deathrow before it was repromoted.
<Hobbsee> no idea.  you're hte soyuz expert.  but that sounds possible
<Fujitsu> So it might have seen the existing binary record in main, and not overwritten it, so it then got removed.
 * Hobbsee thought deathrow was used for removed packages, not demoted ones
<Fujitsu> I bet everybody's off and uncontactable for Christmas too :P
<geser> Hobbsee: either it breaks further more (in which case you have a week to fix it) or it works again
<Fujitsu> Hobbsee: The binaries were removed. From a component.
<Hobbsee> Fujitsu: oh, point.
 * Hobbsee grabs source
<Fujitsu> A no-change rebuild should probably fix it - if only by getting the binary republished.
<Fujitsu> (of esound)
<Fujitsu> Poking a Soyuz person is probably better, though.
<Hobbsee> they won't be around for the next week, at least.
 * Hobbsee uploads
<geser> does it need to go through binary NEW?
<Hobbsee> Fujitsu: worthy of a soyuz bug, though
<Fujitsu> That's no problem for Hobbsee.
<Hobbsee> geser: shouldn't do.
<Hobbsee> geser: but, i can accept from there anyway
<Hobbsee> shouldn't, as it's my own upload.  but can.
<Fujitsu> Hobbsee: Sure, but I'll poke more thoroughly first.
<Hobbsee> geser: why would it?
<Hobbsee> oh, yes, it might get chucked there, i guess
<Fujitsu> geser: I think the binary still exists, just the publishings are deleted.
 * Hobbsee taps fingers, waits for queue builder
<geser> Hobbsee: could you also give-back kdmtheme rhythmbox gnomebaker mrwtoppm empathy once esound-common is back?
<Hobbsee> geser: i'd be in favour of getting someone to call cprov or something, and getting him to do a mass giveback before christmas.
<Hobbsee> then let the buildds sort it all out over the break
<Hobbsee> right.  now we have esoudn common.
<seb128> Hobbsee: what was this esound upload?
<Hobbsee> seb128: a soyuz bug.
<Hobbsee> seb128: it ate the binaries
<seb128> Hobbsee: has that been confirmed as a soyuz issue?
<seb128> Hobbsee: what binary has been eaten by soyuz there?
 * Hobbsee ponders what to answer to that
<Hobbsee> seb128: esound-common
<Fujitsu> esound-common vanished from the archive after a rather odd sequence of events on its source package.
<seb128> Hobbsee: pitti demoted esound yesterday, are you sure that the binary is not just to universe?
<seb128> did you speak about somebody from the soyuz team about the issue?
<Hobbsee> seb128: based on how it just ended up in new, it's probably a reasonably safe assumption that it wasn't in universe.
<Hobbsee> seb128: and it's not in apt-caches, etc, so not in the recently published universe lists
<Fujitsu> Nor rmadison.
<seb128> ok, did you raise the issue to the soyuz team before trying to workarouding it?
<Hobbsee> seb128: no
<seb128> grr
<Hobbsee> seb128: although Fujitsu filed a bug.
<Hobbsee> seb128: it's a sunday, and it's the 23rd of december.  last i checked, they'd all left for holidays, haven't they?
<\sh> Hobbsee, 22nd of Dec
<seb128> Hobbsee: it's saturday in most timezones and in holidays != vanished
<Hobbsee> \sh: 23rd here, but granted.
<seb128> I'm on holidays and I'm still reading mails ;-)
<Hobbsee> you and Riddell appear to be the exception
<StevenK> Such dedication
<StevenK> Or insanity, either way
<seb128> and StevenK ;-)
<Fujitsu> Ergh, they're multiplying!
<Hobbsee> Riddell: had a meeting
<Hobbsee> so he's excepted
<StevenK> I'm not reading e-mail, I'm heckling
<seb128> Hobbsee: I'm not that sure, I think several people read mails every now and then
<StevenK> I'd do more fftw3-dev rebuilds, but slangasek might hate me
<StevenK> Wait, he won't. Alpha 2 is out the door.
<Hobbsee> StevenK: it's not a freeze now
<Hobbsee> but, do check to see if esound and friends are all happy now, so thinks don't fail
<StevenK> seb128: Did you see gimp in -proposed?
<seb128> StevenK: I've read the -changes mails
<seb128> StevenK: look like you didn't try building the update? ;-)
<StevenK> Shush. :-(
<seb128> Hobbsee: there is no esound in NEW
<Hobbsee> seb128: yes, i know.
<seb128> nor glib2.0, weir
<seb128> weird
 * Hobbsee wasn't aware that glib2.0 should be in NEW
<seb128> Hobbsee: there is a new libgio-fam binary
<seb128> it was built by an another source package before though
<seb128> so it might not require NEWing
<Hobbsee> seb128: looks like someone else approved it
<Hobbsee> yeah, quite possibly.  it appears to be built from the right source nwo
<seb128> Hobbsee: what about esound?
<Hobbsee> unless i'm incompetent using my tools, of course.
<seb128> and somebody retried the rhythmbox build
<Hobbsee> seb128: it was in new.  it's now not
<seb128> but that still didn't work due to esound
<Hobbsee> ahh, yes, so this is how you found out to come and yell at me.
<Hobbsee> this is true.  wasn't sure if it was transient, as keescook asked me to check a similar failure
<seb128> Hobbsee: no, I started IRC because I read the hardy-changes mails
<seb128> I asked pitti to retry the rhythmbox build yesterday already
<Hobbsee> yes, and it failed.
<seb128> since it failed because libesd0 was in universe
<Hobbsee> i retried it today, adn it also failed, so some of us in here debugged the problem.
<seb128> right
 * Hobbsee is not *that* incompetent, FYI.
<seb128> Hobbsee: well, we were debugging the problem yesterday already
<seb128> and that's something that should not require a new upload
<seb128> but should rather be fixed at the archive level
<Hobbsee> next week.
<seb128> the week after that most likely
 * Fujitsu notes that all is good now, anyway.
<seb128> everybody is on holidays next week ;-)
<Hobbsee> so, 2 weeks.
<Fujitsu> So we have half of main uninstallable for two weeks, yay.
 * Hobbsee notes that some people *might* actually care about building anything GUI-related in the next 2 weeks.
<seb128> Fujitsu: I though all was good now?
<seb128> Hobbsee: I'm pretty sure that people would reply to mails
<Fujitsu> seb128: I meant in the scenario where no rebuild occurred, sorry.
<Hobbsee> seb128: it is now, after my upload, which you're telling me that i shouldn't have done.
<seb128> I for one joined IRC
<seb128> and I think that if somebody mail pitti he's likely to show up today
 * Hobbsee notes that he, in all likelyhood, could not fix it, if it's a soyuz bug?
<seb128> but right, the bug has been workarounded so there is no hurry now
<seb128> Hobbsee: well, there is often way to workaround soyuz issue as archive admins
<Hobbsee> seb128: archive admins can republish removed binaries?
<seb128> nothing is trashed
<Hobbsee> sure, it's still in librarian.  but it wasn't in hardy at all.
<seb128> you just have to move the binaries from where they are to the right place back usually
<Fujitsu> The binaries had been deleted. They weren't moved to anywhere.
<seb128> Fujitsu: how do you now? uploads rejected are moved somewhere and not deleted for example
<seb128> Fujitsu: are you sure they are not somewhere in the librarian?
<Fujitsu> seb128: This was a legitimately superseded and subsequently `deleted' (although still in librarian) binary.
<Fujitsu> RIght, but can one recover them from there without being a god?
 * Hobbsee ponders the point of fishing for them in librarian, vs just reuploading, and taking 3 mins on all arches to build.
<seb128> Hobbsee: well, the point is that there is a soyuz bug there
<Hobbsee> seb128: https://launchpad.net/bugs/178102
<seb128> Hobbsee: and sometime it's easier to debug things when they are still in a weird state than after workarounding
<ubotu> Launchpad bug 178102 in soyuz "(Quick) promotion and demotion can lose binaries" [Undecided,New]
<Hobbsee> seb128: this can happen to any binary.  obviously, ones which do *not* cause mass uninstability would be good ones to test with
<Hobbsee> but, i see your point
<seb128> ok, I didn't know that was happening to any binary and easy to trigger since I didn't try
<seb128> Hobbsee: thanks anyway to workarounding the issue ;-)
<Hobbsee> seb128: you're welcome.  do you still think i'm incompetent?
<seb128> Hobbsee: I didn't say or though that you are incompetent
<seb128> I would just have tried to contact somebody from the soyuz team before workarounding the issue
 * Hobbsee normally would have
<seb128> though admittedly that's not the best timing due to holidays
 * Hobbsee is aware of the time of year, etc, though.
 * Hobbsee has no contact phone numbers, etc, cprov is not talking, etc.
<Hobbsee> in fact, none are on irc at all, not even logging
<seb128> no
 * seb128 hugs Hobbsee
<seb128> Hobbsee: sorry for ranting
 * Hobbsee continues to hide behind her seb-shield.
 * Hobbsee does not wish to be blasted again
<seb128> Hobbsee: could you give an another rhythmbox build retry? ;-)
<\sh> how lucky i am..wine needs libesd0 lol
<Fujitsu> seb128: I wouldn't advise it for at least another 10 minutes.
<seb128> Fujitsu: publisher is still running?
<Fujitsu> seb128: Doesn't it normally finish around */45?
<seb128> Fujitsu: ok thanks, no hurry there
<Fujitsu> Erm, 20 minutes, then.
<Hobbsee> seb128: yeah, but still waiting for the rest to publish.
 * Fujitsu can't count.
<Hobbsee> seb128: btw, i also checked the scrollback, to see exactly what you guys had done, too.
<lamont> Hobbsee: sup?
<seb128> Hobbsee: well, when I pinged pitti yesterday the issue was that libesd moved to universe
<seb128> Hobbsee: we didn't notice any lack of binary there
<Hobbsee> seb128: and it moved back.  as you would have seen, had you checked your aptcache.
<seb128> Hobbsee: ?
 * Hobbsee isn't sure why it only ate that binary, and not the others, though
<seb128> Hobbsee: an arch any or all issue?
<Hobbsee> lamont: can you do a mass giveback?
<lamont> nope
<Hobbsee> seb128: i don't know.  perhaps it is
<Hobbsee> lamont: do you have contacts for those who can?
<Fujitsu> There are strange things done with arch: all domination.
<Hobbsee> lamont: it would be nice to do it over christmas
<Hobbsee> lamont: seeing as we have empty, waiting buildds
<lamont> well, there's the RSI-inducing button-clicking method...
<Hobbsee> and no kde4 uploads :P
<seb128> Hobbsee: what about my aptcache? pitti said he promoted the binaries again yesterday and after that we were on holidays, I didn't look at anything out of my mails today
<lamont> then what can: cprov, infinity
<Hobbsee> sarah@LongPointyStick:~% madison libesd0                                 1:06AM
<Hobbsee>    libesd0 | 0.2.38-0ubuntu4 | http://mirror.internode.on.net hardy/main Packages
<Hobbsee>    libesd0 | 0.2.38-0ubuntu4 | http://archive.ubuntu.com hardy/main Packages
<Hobbsee>     esound | 0.2.38-0ubuntu4 | http://mirror.internode.on.net hardy/main Sources
<Hobbsee>     esound | 0.2.38-0ubuntu4 | http://archive.ubuntu.com hardy/main Sources
<Hobbsee> lamont: right.  got contact #'s for either of them, to start it off?  (but wait till we've got some bits checked, that the esound stuff really has worked)
<Hobbsee> seb128: ^ should have told you that it was in main again (source and binaries)
<lamont> no
<Hobbsee> lamont: guess seb128 had better be begged to do it, then
<seb128> Hobbsee: well, since pitti promoted it yesterday I though it would be there ;-)
<Hobbsee> seb128: well, most of it is...
<seb128> Hobbsee: what do you need now? build retries for what?
<Fujitsu> Ermmm.
<seb128> note that I'm not a buildd admin and can't do those
<Fujitsu> This is odd.
<Hobbsee> seb128: you have the great canonical phone directory.
<Fujitsu> Soyuz left the binaries that still exist in universe.
<Hobbsee> Fujitsu: but didn't publish them?
<Hobbsee> Fujitsu: where are you finding that info?
<Fujitsu> Hobbsee: rmadison from an hour ago says -0ubuntu4 has esound binaries in universe.
<StevenK> rmadison might be lagged more, though
 * persia notes that old binaries that aren't superceded by new versions for the same component and architecture have always seemed to benefit from manual poking.
<Hobbsee> Fujitsu: when was that last updated, though?
<Fujitsu> Hobbsee, StevenK: Recently enough that the esound-common one is missing.
<Hobbsee> Fujitsu: wlel, we don't know if that one got nuked between main and universe, or universe and main.
<Hobbsee> if it happened to get nuked btwn main and universe, that would still fit the problem
<Fujitsu> seb128: Did somebody not knock the binaries back to main?
<seb128> what binaries?
<seb128> esound should be in universe
<seb128> libesd should be in main
<Fujitsu> Ohh.
<Fujitsu> I see, it is split. How confusing.
<Fujitsu> So it's just the arch: all that is broken.
<\sh> .oO(there should be someone doing lvl2/lvl3 on-duty call support somehow in between these peaceful days, no?)
<Hobbsee> Fujitsu: so something strange happens to arch: all binary demotions / promotions.  got it.
<Hobbsee> ie, they vanish
<Hobbsee> \sh: presumably, unless they presumed that no one would do any ubuntu development over christmas
<Fujitsu> Yep. It may only occur when both are performed within a short window, but I'm not entirely sure of how the binary removals work.
<Hobbsee> guess you'll find out
<\sh> Hobbsee, well, it's the time of the year...all things which could get a bit messy are happening now
<StevenK> Like Christmas shopping.
 * StevenK shivers
<Hobbsee> urgh.  don't mention that
<Fujitsu> Hah.
 * Hobbsee stabs stupid customers.
<\sh> or "hey, we are happy script kiddies, let's fck up some things" or "we produced a not known bug in our software..."
<geser> seb128: run "rmadison esound-common", there is no entry for hardy
<seb128> geser: is that a follow up on the discussion we just had on the chan or a new one?
<seb128> esound-common | 0.2.38-0ubuntu5 |         hardy | all
<geser> a followup
<seb128> on drescher
<Fujitsu> Aha, it's back!
<geser> for -0ubuntu4 there was no entry for hardy
<seb128> geser: that's the bug we were speaking about and that Hobbsee workaround with the upload
<Hobbsee> good, i'm glad it's back
<seb128> workarounded
<geser> and rmadison for mere mortals still shows -0ubuntu4
<Fujitsu> seb128: It's probably actually `worked around'
<seb128> Fujitsu: thanks ;-)
<seb128> geser: did you run apt-get update?
<Fujitsu> seb128: rmadison uses a script on rookery.
<geser> rmadison needs "apt-get update"?
<seb128> ok, I don't use rmadison so I don't know
<seb128> maybe rookery didn't update yet
<Fujitsu> I don't think anything but drescher will have updated yet.
<geser> but it's good that the lost binary is back again
<seb128> Get:1 http://archive.ubuntu.com gutsy/main esound-common 0.2.38-0ubuntu4 [42.2kB]
<Fujitsu> Gutsy, -0ubuntu4.
<seb128> right
<seb128> that's the current
<seb128> still need to wait for an archive update
<seb128> but since drescher has the new one that should be alright
<seb128> let's wait for the next update
 * Hobbsee gives some packages back, and sees what happens
<Fujitsu> They won't try to build for ages anyway.
<Hobbsee> why?
<Fujitsu> Oh, I guess the builds will immediately be recreated, rather than having to wait for queue-builder like new ones.
<Hobbsee> rhythmbox has started
<Fujitsu> That was quick.
 * Fujitsu watches.
<Fujitsu> Aha, it worked.
<Fujitsu> kdmtheme got build-deps properly on castilla, at least.
<Fujitsu> And that was libesd0-dev.
<Hobbsee> looks like libgpod-dev is dead on hppa
<Fujitsu> Get:1 http://ftpmaster.internal hardy/main esound-common 0.2.38-0ubuntu5 [42.3kB]
<Fujitsu> Hobbsee: It *is* hppa...
<\sh> but it's not published on archive.ubuntu.com?
<Hobbsee> oh, that's depwaited
<Fujitsu> \sh: No, that won't sync for a while, probably.
<\sh> crap :(
 * Hobbsee wonders why sg3-utils failed to upload on hppa
<Fujitsu> Hobbsee: When?
<Hobbsee> Fujitsu: sg3-utils
<Hobbsee> 2007-11-27
<Hobbsee> er, that
<Hobbsee> hum, 5 min build tim
<Hobbsee> e
 * Hobbsee hits retry
<Fujitsu> Hobbsee: It was promoted on the 27th.
<Hobbsee> ahhh
<Hobbsee> oh, so it was promoted
<Hobbsee> good.  then it's fine to retry
<Fujitsu> Do you still have a page open from before you retried it?
<\sh> so no wine building...time to deal somewhat more with django
<Hobbsee> Fujitsu: no
<Hobbsee> why, what were you looking for?
<Fujitsu> Just wondering what time it failed, but it was probably the promotion.
<Fujitsu> \sh: It has hit a.u.c
<\sh> Fujitsu, cool thx :)
<seb128> Hobbsee: the rhythmbox build worked, you rock ;-)
<seb128> ok, enough computer for now
<seb128> see you later
<ion_> âenough computerâ?
 * ion_ has problems understanding the concept
<Fujitsu> ion_: You're not meant to understand it. It's a new Canonical plot to make our minds explode.
<Amaranth> ion_: I heard there is this place called 'outside'
<Amaranth> Perhaps he went there
<Fujitsu> Amaranth: Ah, another Canonical invention.
 * Fujitsu heads off to bed.
<ion_> amaranth: This so-called âoutsideâ is compatible with laptop computers.
<Amaranth> Not if they have a glossy screen :P
<\sh> hmm...
<\sh> libesd0-alsa is still not installable...strange
<Hobbsee> \sh: should be fixed
<\sh>  libesd0-dev: Depends: libesd-alsa0 (= 0.2.38-0ubuntu4) but it is not going to be installed or
<\sh>                         libesd0 (= 0.2.38-0ubuntu4)
<\sh>                Depends: esound-common (>= 0.2.38-0ubuntu4) but it is not installable
<\sh> just updated the pbuilder
<persia> \sh: Works from here, with updated cache.  Which mirror are you viewing?
<\sh> persia, well, pbuilder is using archive.ubuntu.com but doesn't give me the used ip address from the RR
<Hobbsee> \sh: out of date
<persia> \sh: True.  Keep updating until it works :)
<pochu> Yay, works here too!
 * pochu thanks Hobbsee 
<Hobbsee> :)
<Hobbsee> ahh, there we go.
<Hobbsee> Totals by arch:
<Hobbsee>     * sparc:29
<Hobbsee>     * i386:38
<Hobbsee>     * amd64:34
<Hobbsee> uninstallable from main ^
<Hobbsee> much better
<hile> a question related to bug #500397: is it nautilus or gnome-vfs, which is deciding which inotify events are actually received by nautilus? i.e. are the events filtered somehow?
<hile> hmpf, should have been on gnome-devel, nevermind
<spectie> hey all, i'm a debian package maintainer for apertium, the version in debian is 3.0.5 and the version in ubuntu is 1.0.3
<spectie> there is a lot of stuff that has changed in between the versions and i was wondering if it might be possible to accelerate the process of getting the new versions in ubuntu?
<spectie> is there anything i can do to help etc. ?
<\sh> spectie, not true
<spectie> oh ?
<spectie> what is not true ?
<\sh> spectie, in our dev version apertium is http://packages.ubuntu.com/hardy/source/apertium
<keescook> persia: celestia> nah, that bug will be fixed when the most recent build finishes -- I made a weird mistake with the rules file
<pochu>   apertium |    3.0.5-1 | http://archive.ubuntu.com hardy/universe Sources
<spectie> aha cool
<Ubulette> !info apertium hardy
<Ubulette> (too slow)
 * keescook wanders afk again
<ubotu> apertium: Shallow-transfer machine translation engine. In component universe, is optional. Version 3.0.5-1 (hardy), package size 251 kB, installed size 1044 kB
<spectie> \sh, and when will that be in gutsy ?
<\sh> spectie, if then only via backports
<mjj29> spectie: I assume it will never be in gutsy
<spectie> ok
<mjj29> in the same way it will never be in etch
<pochu> You can request a backport if you want it in Gutsy. You will probably need some testing before it's approved.
<spectie> what is the timescale of hardy being released ?
<Mithrandir> spectie: https://wiki.ubuntu.com/HardyReleaseSchedule
<spectie> cool thanks
<spectie> i guess it would be worth requesting a backport
<spectie> as 1.0.3 is probably broken by default
<spectie> !info lttoolbox hardy
<ubotu> lttoolbox: Apertium lexical processing modules and tools. In component universe, is optional. Version 3.0.1-1 (hardy), package size 16 kB, installed size 100 kB
<spectie> !info apertium-es-ca hardy
<ubotu> apertium-es-ca: Apertium linguistic data to translate between Spanish and Catalan. In component multiverse, is optional. Version 1.0.5-2 (hardy), package size 778 kB, installed size 1700 kB
<Mithrandir> spectie: if you're just looking for versions, rmadison -u ubuntu $package in Debian will tell you the relevant versions
<spectie> aha thanks
<spectie> i just finished
<spectie> but i'll remember in future
<Mithrandir> (rmadison $pkg will give you the versions for Debian, but you probably knew that already)
<spectie> filed the request
<spectie> thanks for your help
<Ubulette> hmm, xine-lib 1.1.8-3ubuntu2 diff contains sources changes outside of debian/patches
<tuxist> promblems packaging flitghgear
<tuxist> http://paste.ubuntu-nl.org/49344/
<tuxist> anny sollutions
<\sh> tuxist, looks like a missing lib/shared object or whatever...
<tuxist> i think it is problem in the header of libsgmisc
<\sh> tuxist, is it using simgear-dev?
<tuxist> yes i have version 1.0.0
<\sh> tuxist, the version in hardy is still 0.3.10-2 for simgear0...so it could be that flightgear needs a newer version of simgear
<tuxist> i have installed allready the new vrsion
<tuxist> yes i have version 1.0.0
<\sh> tuxist, so you are sure that your flightgear package is including the correct simgear package? :)
<tuxist> ./configure --prefix=/usr
<\sh> tuxist, so you just compile the source...but you didn't packaged it...
<tuxist> when have compiled the package i start packaging
<tuxist> sucsessful
<tuxist> ;-)
<\sh> tuxist, well, if you use pbuilder for building the package...you need to make sure that pbuilder is getting the 1.0.0 package of simgear and not the provided package from <insert your ubuntu release here>
<tuxist> i have the problem broken script
<tuxist> thanks
<tjaalton> which package is responsible for the debug output on vt8?
<tjaalton> nevermind
<ion_> Probably PEBKAC, but it seems as if fglrx in hardy doesnât support Xv.
<ion_> Huh. The tubes claim that i can only choose OpenGL acceleration *or* Xv acceleration. Way to go, ATI! :-P
<ion_> After modifying xorg.conf, both seem to work after all.
#ubuntu-devel 2007-12-23
<linxuz3r> hey guys
<linxuz3r> can motherboard make noise
<linxuz3r> my computer is making noise like its coming from a fan. i unplugged the fan but the noise is still there. it seems that the cpu is making the noise. what could be the cause of this?
 * lamont wonders why lzma_4.43-12ubuntu1_hppa.deb is in universe, while the rest of the architectures get to have it in main...
<Zero> hi
<Zero> someone can tell me why firefox 3 in gutsy is still Alpha 8 ?
<Burgundavia> Zero: because it has not yet been updated, it is coming
<Zero> ok :)
<Zero> tkz
<Zero> Burgundavia: tkz
<Burgundavia> Zero: there are ubuntu-specific things that will need to be updated
<Burgundavia> it is also possible the mozilla-maintainer is on vacation
<persia> Burgundavia: I don't see a backports request.  Are you sure this is in-progress?
<Burgundavia> persia: hmm, you are right. I miss read that as hardy
<Burgundavia> Zero: in that case, there needs to be a backports request filed
<Zero> umm ok
<Zero> Burgundavia: ok
<persia> !backports | Zero
<ubotu> Zero: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<persia> Zero: The current version in hardy is 3.0~b1+nobinonly-0ubuntu1, which would be the backports candidate.  Due to the holidays, it might take a couple weeks to process.
<Zero> ok
<Zero> i will change the bug #164123 to a backport
<ubotu> Launchpad bug 164123 in firefox-3.0 "Firefox 3 Gran Paradiso need upgrade in Gutsy" [Undecided,Confirmed] https://launchpad.net/bugs/164123
<Ubulette> b2 is ready for hardy
<persia> Zero: Best wait a bit.  Ubulette is nearly always right about firefox, and b2 might be a better backport candidate.
<johandc> Hi, i want to build a source package on my 4-way sparc64 server, but somehow dpkg-buildpackage is only using one cpu to compile.
<johandc> How can i set something like the -j 8 flag with dpkg?
<Burgundavia> johandc: ask in #ubuntu-server or -motu
<johandc> Allright
<zzxc> Are there workarounds for the casper bugs that prevent the loading of squashfs images from local drives, rather than a cdrom?
<zzxc> I need to install on a computer with a bad cdrom drive, but the casper scripts will not load any disk images from media other than the cdrom drive.
<minghua> Any ubuntu-main-sponsors member around?  Please unsubscribe the team from bug #176660, I can't do that myself.  Thanks.
<ubotu> Launchpad bug 176660 in im-switch "im-switch: Upgrade problem from dapper to gutsy/hardy" [Low,Confirmed] https://launchpad.net/bugs/176660
<crimsun> minghua: done.
<minghua> Thanks crimsun.
<warp10> Hi all!
<\sh> hmm...could be that I'm blind but do we have openssl libs somewhere in 32bit mode for x86_64?
<Mithrandir> \sh: possibly ia32-libs, if not there, no.
<\sh> Mithrandir, well, it doesn't look like that...or Scott R. and I were missing something in the rules file for ia32 support :(
<\sh> let's see..but first...gettnig  breadroles and a coffee
<DarkSun88> Hi all
<YokoZar> Is there a gcc-multilib equivalent for gcc 3.4 ?
<YokoZar> Or can I just use straight up gcc 3.4?
#ubuntu-devel 2008-12-15
<Jimi__Hendrix> Chipzz define bootstrapping...and i have till march to do this...so ive got plenty of time...
<slangasek> lamont: hmm, why did bind9's binary packages all get fatter in jaunty?
<slangasek> or should I be directing that question at kees/doko?
<lamont> slangasek: define "fatter"
<slangasek> lamont: bind9-host is 30% bigger in jaunty than intrepid, with no difference in file contents
<slangasek> s/file/package/
<lamont>   * dig: add -DDIG_SIGCHASE to compile options.  LP: #257682
<lamont>   * enable largefile support.  Closes: #497040
<lamont> otherwise, nfc
<slangasek> the package is only 61K in total so it's not a major issue by itself, but I'm trying to figure out if it's a local change or a sign of changes that are giving us fatter binaries in general
<slangasek> ok, thanks; time to test builds in a chroot
<lamont> I haven't really looked
<Chipzz> bug 257682
<ubottu> Launchpad bug 257682 in bind9 "dig compiled without -DDIG_SIGCHASE!" [Undecided,Fix released] https://launchpad.net/bugs/257682
<lamont> Chipzz: yep.  that's the bug alright
<Chipzz> lamont: wanted to take a look at it myself :P
<lamont> heh
<Chipzz> I was just wondering, ubotu should probably generate those links automatically when someone says "LP: #xxxxx"
<Chipzz> heh
<Chipzz> bug 497040
<ubottu> Error: Launchpad bug 497040 could not be found
<Chipzz> weird
<slangasek> lamont: curiously, if I do a local rebuild, bind9-host comes out even larger...
<slangasek> with dpkg-buildpackage -B
<lamont> interesting
<slangasek> oh, langpack stripping maybe?
<lamont> yeah - possibly
<slangasek> hmm, no
<lamont> Chipzz: debian bug 497040
<ubottu> Debian bug 497040 in bind9 "bind9: Log files limitited to 2GB" [Normal,Closed] http://bugs.debian.org/497040
<slangasek> lamont: right, don't use 'du' to compare file sizes across systems with different block sizes :)
<Chipzz> lamont: ah heh. fail on my part :P
<lamont> slangasek: heh
<slangasek> lamont: right, so rebuilding the intrepid package with the jaunty toolchain also gives a smaller package, so I guess one of the changed build options means a significant code size increase
<lamont> slangasek: git clone git://git.debian.org/~lamont/bind9.git
<slangasek> hmm?
<lamont> slangasek: that has the entire history if you wanna bisect the changes... :)
<lamont> though there aren't really that many of htem
 * lamont sleeps
<bryce> slangasek: btw for alpha-2 could you include in the release notes a known-issue with i8xx chips (bug #304871)
<ubottu> Launchpad bug 304871 in xserver-xorg-video-intel "[Jaunty,845G] Fatal server error: Couldn't bind memory for BO front buffer " [High,Confirmed] https://launchpad.net/bugs/304871
<bryce> slangasek: we might be able to get a fix in for alpha-2, but I think i8xx gfx users should hold off on upgrading a bit until it's sorted out
<slangasek> bryce: ok, noted
<slangasek> lamont: apparently it's the DIG_SIGCHASE change that does it
<slangasek> ArneGoetje: FYI, the change in ttf-arphic-uming to select dpkg compression based on dist name doesn't work
<LaserJock> anybody know offhand a page that clearly says what Ubuntu's security support policies are?
<slangasek> ArneGoetje: I'm not sure the buildds use ubuntu-minimal, which would mean lsb-release is only installed if you build-depend on it
<ArneGoetje> slangasek: so, your suggestion would be to build-depend on lsb-release?
<slangasek> ArneGoetje: yeah (just uploaded with that change)
<ArneGoetje> slangasek: ok, thanks
<slangasek> ArneGoetje: and I see we've deliberately dropped the lzma option for ttf-kochi, but ttf-kochi is still on the CDs - what binary packages should replace ttf-kochi-{gothic,mincho}?
<ArneGoetje> slangasek: ttf-sazanami-{gothic,mincho}
<slangasek> ah, already changed in the seed and just needs an upload :)
<dholbach> good morning
<Tonio_> hi
<tkamppeter> pitti, hi
<pitti> Good morning
<pitti> tkamppeter: hey
<lool> Hey pitti
<lool> pitti: had a good trip?
<pitti> everyone landed safely again? /me had a very broken trip
<lool> what happened?
<pitti> lool: most improbable EVER
<pitti> lool: in our plane in SF, the door didn't close, which meant 4 hours delay; after 2 hours we left the plane again
<pitti> and guess whom we ran into
<pitti> mvo, ogra, and the other dudes which took the other plane 40 mins earlier
<pitti> whose plane broke as well, in a much more scary manner
<pitti> and then in Frankfurt I had to stand in line for 2.5 hours to get my ticket rebooked
<tkamppeter> pitti, I have an SRU for bug 306125 and bug 288570. Can you improve the Intrepid tasks of these bugs?
<ubottu> Launchpad bug 306125 in ghostscript "PostScript produced with particular eps file when using graphicx-psmin gives error in ghostscript" [Undecided,Fix released] https://launchpad.net/bugs/306125
<ubottu> Launchpad bug 288570 in ghostscript "Ghostscript eats all hard drive space and prints errors when printing with 1200 dpi" [High,Fix released] https://launchpad.net/bugs/288570
<lool> pitti: Sounds fun   :-/
<pitti> eww, wiki.u.c. down?
<lool> pitti: Doesn't respond for me either
<pitti> I get a 503 Service Unavailable
<lool> I get a timeout; are you using a proxy?
<Koon> I got a few 500 this morning.
<Koon> and now it's a timeout.
<Koon> Now I got 503
<pitti> tkamppeter: done
<tkamppeter> pitti, thanks, will upload the new gs to -proposed. Please pass it through.
<tkamppeter> pitti, new gs is uploaded. Can you pass it through, thanks.
<pitti> will process the queue later
<Chipzz> where can I ask for some help with a udev problem? I know, #ubuntu for support, but I'm highly unlikely to get meaningfull help there on that subject :P
<StevenK> pitti: Are you planning to do the libspe2 merge on main-manual?
<pitti> oh, I didn't even look at that; I touched libspe2?
<StevenK> pitti: According to MoM, you did
<tkamppeter> pitti, CUPS is still hanging in the -proposed queue (on bug 271350) and I have already two new bugs to SRU. How should we proceed?
<ubottu> Launchpad bug 271350 in cups "pdftopdf filter on PowerPC corrupts data" [Undecided,Fix committed] https://launchpad.net/bugs/271350
<tkamppeter> In the bug one person reported that the patch works for him in Jaunty and I have the patched version on a normal PC and no regressions.
<pitti> tkamppeter: it's there for 19 days already; it should really get tested
<pitti> some feedback about "still works for me"
<tkamppeter> pitti, what do you mean with 'some feedback about "still works for me"'?
<pitti> tkamppeter: I won't move it to -updates without anyone saying "that version still works for me"
 * pitti upgrades his wife's computer to that version
<tkamppeter> pitti, so I add the fixes for the two other bugs, creating a 2ubuntu5 and if the testers of the two other bugs are completely content, we put up 2ubuntu5.
<pitti> tkamppeter: yes
<pitti> tkamppeter: but before I'd like to move 4 to -updates
<tkamppeter> pitti, the bugs which I want to fix with 2ubuntu5 are bug 286048, bug 300312, bug 244840, and bug 47649.
<ubottu> Launchpad bug 286048 in cups "RELEASE FREEZE EXCEPTION: When requesting n copies, n*n or even n*n*n copies get printed" [Critical,Fix released] https://launchpad.net/bugs/286048
<ubottu> Launchpad bug 300312 in cups "tagged PDF with rotation is not printed correctly" [Undecided,Fix released] https://launchpad.net/bugs/300312
<ubottu> Launchpad bug 244840 in cups "Landscape PDF documents get printed portrait, truncated" [Undecided,New] https://launchpad.net/bugs/244840
<ubottu> Launchpad bug 47649 in cups "Landscape PDF printed as portrait (and truncated)" [Medium,Confirmed] https://launchpad.net/bugs/47649
<tkamppeter> pitti, it would be great if the reporters of these bugs could start to test now.
<pitti> tkamppeter: I might also have a fix for bug 237256 in time
<ubottu> Launchpad bug 237256 in cupsys "Audit failure in CUPS for Brother DCP-9045CDN" [Undecided,New] https://launchpad.net/bugs/237256
<tkamppeter> pitti, great. How do you fix that one.
<tkamppeter> pitti, can you approve the Intrepid tasks of the bugs I mentioned above?
<pitti> tkamppeter: replied to 237256
<pitti> tkamppeter: done
<tkamppeter> pitti, you simply added "/usr/Brother/** Ux" to the AppArmor file?
<tkamppeter> pitti, thanks for approving the Intrepid tasks.
<pitti> Keybuk, kees: on whose plate is the d-bus (security/new version) update?
<Keybuk> mine
<Keybuk> it's not urgent, as far as we can tell there's no escalation you can get from it
<Keybuk> and the fix is as bad as the cure
<tkamppeter> pitti, I think, if we put 2ubuntu5 into -proposed now, we once get a lot of other fixes tested and second, we get the patch of bug 271350 regression-tested by the reporters of the other bugs. WDYT?
<ubottu> Launchpad bug 271350 in cups "pdftopdf filter on PowerPC corrupts data" [Undecided,Fix committed] https://launchpad.net/bugs/271350
<pitti> tkamppeter: *shrug* WFM
<tkamppeter> pitti, WFM? "Works for me"? "Wait for me"?
<pitti> tkamppeter: "works for me"
<DktrKranz> doko: when you have some spare time, mind looking/commenting at bug 254790? Thanks.
<ubottu> Launchpad bug 254790 in binutils "strip segfaults on dietlibc-built executables" [Unknown,Fix released] https://launchpad.net/bugs/254790
<tkamppeter> pitti, so can you give me your fix for Brother then and I will upload 2ubuntu5?
<soren> Keybuk: I'm playing a bit around with some shared storage and I was wondering if you've given any thought to the problems that will inevitable arise when e.g. a virtual machine puts a raid superblock onto its block devices and these are e.g. shared over iscsi and appear on multiple hosts.
<Keybuk> soren: what kind of problems are you expecting?
<soren> Keybuk: Each host will notice the raid superblock and configure the raid set... Right?
<Kano> hi, what allows u to mount hd partitions without fstab entry?
<soren> Keybuk: Same problem with lvm. The lvm udev rules call "lvmchange -ay" (without naming the volume group). I'm not sure if that actually does anything or just marks it as active in the kernel.
<Keybuk> pitti: am tracking the d-bus issue on bug #30632
<ubottu> Launchpad bug 30632 in soyuz "Builder "Change mode" page should enable optional comment." [High,Fix released] https://launchpad.net/bugs/30632
<Keybuk> err
<Keybuk> pitti: am tracking the d-bus issue on bug #306362
<ubottu> Launchpad bug 306362 in dbus "Default D-Bus system bus policy is allow" [Critical,In progress] https://launchpad.net/bugs/306362
<Keybuk> the issue is that just about every existing dbus policy file is wrong in some way
<Keybuk> so if we upload the "fixed" version of d-bus, every service will break
<Keybuk> and worse, services will break because *other* policy files are broken
<Keybuk> e.g. say that /etc/dbus-1/service.d/foo.conf has
<Keybuk>   <policy context="default">
<Keybuk>     <deny receive_interface="com.ubuntu.Frob"/>
<Keybuk>   </policy>
<Keybuk> that means
<Keybuk> "by default, deny ANY SERVICE from receiving messages for the com.ubuntu.Frob interface
<Keybuk>  AND, since we have denied interfaces, deny ANY SERVICE from receiving messages _with_no_interface_set_"
<Keybuk> (sending messages without the interface set is default for things like Python)
<Keybuk> assumedly what they really meant was
<Keybuk>     <deny receive_destination="com.ubuntu.Frob"/>
<Keybuk> or
<Keybuk>     <deny receive_destination="com.ubuntu.Frob" receive_interface="com.ubuntu.Frob"/>
<Keybuk> though if you have the former, you don't need the latter
<Keybuk> also almost nobody allows people to receive their signals ;)
<soren> Keybuk: My only idea to prevent the raid (and similar) problems is to keep a list of uuid's that udev should just ignore and then figure out a way to export such a list from libvirt, but perhaps you have a more clever approach up your sleave?
<Keybuk> pitti: oh, and note that the D-Bus upstream stance is now to revert all the security fixes and go back to open with logging ;)
<Keybuk> soren: why should udev ignore them?
<Keybuk> you still want them in the udevdb and still want them in /dev surely?
<soren> Keybuk: Not really.
<Keybuk> why not?>
<Keybuk> I don't understand why you'd want a connected device which udev doesn't know about?
<soren> Keybuk: Well, I suppose it depends on what you refer to by "them". :)
<Keybuk> if it's in /sys, there's no reason it shouldn't be in /dev
<soren> I want to have access to the raw block devices, but not configure the raid sets or lvm vg's that might be on there.
<Keybuk> you generally want a match between /sys/dev/block <=> /dev/block and /sys/dev/char <=> /dev/char
<Keybuk> ah, I see what you mean
<Keybuk> you want the top-level block device to appear, but don't want to run mdadm and/or lvm on it?
<soren> Right.
<Keybuk> what heuristic would you follow to decide that?
<soren> My specificu use case is virtual machines, so exporting some sort of list from libvirt would be a good start.
<Kano> soren: can you tell me how the mounting works without fstab entry for hd partitions?
<Keybuk> soren: if we have a blacklist, I'd use it to skip the entire "persistent" bit of the udev rules
<soren> libvirt has a storage handling api. I'm expecting that people will use that to set up iscsi to get access to the shares.
<Keybuk> e.g. /dev/disk/by-*, mdadm, lvm, etc.
<Keybuk> even better if we could generate that blacklist in the form of udev rules in the first place
<Keybuk> 59-blacklist.rules
<soren> Keybuk: Ah, good idea
<Keybuk> BLAH==BLAH, GOTO="symlinks_end"
<Keybuk> 79-symlinks-end.rules
<Keybuk> LABEL="symlinks_end"
<soren> Keybuk: The target of GOTO doesn't need to be in the same file?
<Keybuk> type thing
<soren> That's convenient.
<Keybuk> no, you can jump files with it
<Keybuk> hell, you may want to just do
<Keybuk> BLAH==BLAH, OPTIONS+="last_rule"
<Keybuk> to prevent any further processing, including hal
<Keybuk> in fact, I think last_rule is probably correct
<Keybuk> otherwise you may still get hal automounting
<soren> Yeah, that would suck.
<soren> Hm... It won't suffice for lvm, though.
<soren> 85-lvm calls "lvchange -a y" (with out the vg name), so next time it's triggered, any volume groups will be discovered and activated.
<Keybuk> ah, true
<Keybuk> I'm still waiting for incremental LVM
<Nafallo> incremental?
<Nafallo> how would that work?
<Keybuk> Nafallo: instead of telling lvm "scan for new block devices and do what you want", you'd instead tell lvm "there's a new /dev/sda4 - do you want that?"
<emgent> \sh: ping
<Nafallo> Keybuk: ah. in that sense. that makes sense :-)
<Keybuk> and lvm would only activate when it has all the pieces it needs
<soren> Keybuk: Scanning alone should be fine, I suppose. As long as it doesn't get activated, we should be golden, right?
<Nafallo> hmm. I have my lvms on raid ;-)
<Nafallo> but I guess we can do the same for mdraid? :-)
<Keybuk> right, "I have /dev/dm-0, do you want it?"
<Keybuk> soren: we activate everything
<soren> Keybuk: I realise.
<soren> Hmm...
<soren> I mean: If we can somehow change the lvm rules to make sure we don't activate certain vg's, we should be fine, even we can't prevent the block devices from being scanned.
<soren> s/even/even though/
<Keybuk> we don't have any ability to prevent activation
<Keybuk> unless lvm has a conf file for taht
<soren> vgchange -ay takes an argument.
<Keybuk> of the specific device you want to activate, right?
<Keybuk> not a list of ones you do *not*
<soren> volume group.
<soren> Right.
<soren> Erm...
<Keybuk> so that would break things ;)
<soren> Ok, I see where you're going.
<Keybuk> right now, lvm only works *because* we always activate
<soren> Ok, what we need to do is to make vgscan ignore the relevant block devices altogether.
<Keybuk> agree
<soren> Cool. I'll look into that.
<Keybuk> upstream is already working on something like that
<Keybuk> (agk)
<soren> Keybuk: Cool. I'll see if I can strike up a conversation with him.
<soren> Keybuk: Thanks for your input!
<Keybuk> I wouldn't expect it in this release
<soren> My primary concern is really raid. I can imagine massive breakage from that. I don't see lvm as quite as high risk.
<soren> ...but should definitely be fixed.
<Keybuk> there is mdadm incremental support upstream
<Keybuk> but we don't use it yet
<Keybuk> so with mdadm, we scan and activate all devices on each new block device
<soren> *blink*
<soren> Really?
<soren> I thought we did that incrementally.
<Keybuk> nope
 * soren needs to run out for an hour or so..
<Keybuk> it's on my TODO list
<Keybuk> but there's a lot of things on my TODO list ;)
<Keybuk> if you want to take a stab, go for it
<Keybuk> basically instead of calling mdadm within watershed, we would call mdadm --incremental for each block device
<Keybuk> AIUI
<Keybuk> needs lots of code reading and testing to make sure it'll do the right thing
<lamont> slangasek: interesting... still, having SIGCHASE is a good thing
<Keybuk> random thought of the day
<Keybuk> on server, instead of having six gettys on different tty1s...
<Keybuk> ...why don't we have just one tty/getty and run screen by default
<cjwatson> I have actually had a real use (fairly frequently) for being able to get to different ttys without going through userspace, on a server hammered by load
<cjwatson> my mail server doesn't have a lot of memory and occasionally SA kills it ...
<Keybuk> ttys are in userspace though?
<Keybuk> you still have to go through login. pam, shell, etc.
<Keybuk> which is harder work than opening a new screen pty and running the shell in it
<cjwatson> not if you've anticipated this possibility and already have something logged in with a tail of syslog
<cjwatson> then it's just kernelspace
<Keybuk> you'd have a screen logged in with a tail of syslog?
<cjwatson> screen would have to get scheduled in order to switch to it
<cjwatson> I wish this were a hypothetical problem for me :(
<Keybuk> hmm. that's a reasonable point
<cjwatson> (tail has to get scheduled too, but that's fairly likely to happen at *some* point between the box tanking and me noticing - often this turns out to be the crappy wireless driver for that box exploding)
<Keybuk> tail's parent (the shell) has to be scheduled as well
<cjwatson> for tail -f?
<cjwatson> surely not
<slangasek> directhex: tomboy appears to be the only app pulling a lot of mono 1.0 stuff into the CDs at present; is that something that's due to be "corrected"?
<Keybuk> cjwatson: sure
<Keybuk> if you kill your running tail
<Keybuk> tail has to be scheduled to receive SIGTERM and do something about it
<Keybuk> then the shell has to be scheduled to receive SIGCHLD and call wait()
<cjwatson> oh, no, I just meant leaving tail -f running forever
<Keybuk> and assumedly scheduled enough to show the next prompt and allow you to run something else (nice generally :p)
<Keybuk> ah, you only wanted to read the tail?
<Keybuk> I thought you meant having a handy logged-in-as-root shell somewhere that you happened to run tail in normally
<Keybuk> ie. you switched, killed tail, then used that shell to rescue the box
<Keybuk> though that also brings up an interesting point
<cjwatson> I want to find out whether the answer is "leave it a few minutes and it'll sort itself out" or "need to battle with a root shell to fix stuff" or "need to reboot box"
<cjwatson> or whatever
<Keybuk> syslog is useful on servers, why *not* have it sent to a spare tty automatically?
<cjwatson> it's a fairly significant time-saver
<Keybuk> d-i style
<cjwatson> I've always thought that was a good idea; I run it on tty<high>
<Spads> I used to use tty24
<Pici> Some might see it as a security breach to have a syslog taik setup automatically to a spare tty.
<cjwatson> some might be wrong. if you have physical access then you have root
<cjwatson> obviously if the machine is specially locked-down then you'd want to disable it
<cjwatson> but that's not the common case and already requires other work
<Spads> http://www.jerkcity.com/emu//jerkcity1110.html
<Spads> (SFW)
<Pici> heh
<directhex> slangasek, yes, definitely. it's just a long slog, unfortunately
<directhex> slangasek, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO shows current progress
<slangasek> directhex: thanks, I'll read up; it would be nice to get rid of the 1.0 stuff over the next couple of days, since that one change should be enough to get our CDs back down to size
<directhex> slangasek, couple of days, i don't think will happen. sorry. we're working as best we can, both at the debian & ubuntu ends
<slangasek> (or at least, to within spitting distance)
<directhex> the *real* baddie is libgtk2.0-cil - but if we update that too early, it will break all untransitioned apps
<slangasek> directhex: hmm.  I don't see an explanation on this page of what needs to be done to get tomboy from 1.0 -> 2.0?
<directhex> slangasek, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition
<tjaalton> slangasek: hey, as you've probably noticed, I've uploaded xserver 1.6beta3 to jaunty. now the problem is that some old & exotic input drivers fail to build. mind if I drop them from -input-all for alpha2 so that it'd remain installable?
<directhex> slangasek, basically the libs used by it need to be 2.0, as well as tomboy itself
<slangasek> tjaalton: quantify "old and exotic" for me, please? :)
<tjaalton> slangasek: -summa for instance, no real changes to the code since 2005
<slangasek> directhex: so tomboy can't switch until gtk-sharp2 and gnome-sharp2 (and perhaps others) are transitioned?
<tjaalton> ie. hardware that no-one using jaunty will miss ;)
<directhex> slangasek, essentially, yes.
<slangasek> tjaalton: hrm, that one's already in universe though, so presumably isn't a dep of -all?
<slangasek> tjaalton: -input-all only depends on 6 input drivers, none of which look like they'd be a good idea to drop yet
<slangasek> (IMHO)
<tjaalton> slangasek: oh, haha
<tjaalton> silly me then
<directhex> slangasek, Laney & james_w`  have been working hard in helping those of us in pkg-mono get as much done as quickly as possible
<tjaalton> carry on..
<directhex> slangasek, most of the remaining apps are waiting for sync, with a couple of exceptions (RainCT needs to poke gbrainy, monodevelop hasn't been done yet, nant & ndoc are exceptionally difficult to do, ikvm is the most evil package in all of creation)
<slangasek> have sync requests been filed?
<slangasek> if so, I'll switch gears right now and take care of those
<pitti> tkamppeter: Brother fix> I asked the submitter for testing it
<directhex> on most of them. i need to wait for mirror push on a couple of them, as requestsync is bitching that they aren't in the archive
<directhex> slangasek, the ones i filed have been ack'd. i don't know what delay there is after someone says "ACK" though
<slangasek> "until an archive admin does them"
<pitti> Keybuk: lol, so in the end we don't need to do a security update at all? :-)
<cjwatson> could somebody review base-installer, partman-target, and user-setup for hardy-proposed? I'd like to get a roll-up ubiquity upload in for 8.04.2, and it ought to include those pending installer changes I think
<directhex> slangasek, let me see whether there are any main libs it's safe to transition early (i.e. packages with no untransitioned rdeps)
<fbond> Hi.  How can I tell which packages get security updates for the full five years in an LTS release?
<directhex> slangasek, if you see slomo before i do, can you poke him and ask him which of his mono packages he's happy to pass to team maintenance? he's a bit of a bottleneck on some things right now
<slangasek> directhex: ok.  also, can you point me at specific bug numbers for your outstanding sync requests?  nothing on my pending list looks mono-ish
<directhex> fbond, do you have a gui on your system?
<fbond> directhex: Sort of.  It's a pretty custom image with a light GUI that is deployed on digital signs.
<fbond> directhex: That's why I asked the question the way I did.
<fbond> directhex: Is there some kind of policy on this?  I keep getting heuristics from people.
<directhex> fbond, "stuff in main"
<fbond> directhex: Okay, thanks.
<cjwatson> no, that isn't accurate unfortunately
<cjwatson> "stuff that's server-ish"
<directhex> it's not?
<fbond> cjwatson: I figured as much...
<cjwatson> I owe Nick Barcet some work to process the work he's been doing on defining this more tightly
<fbond> cjwatson: Okay, sounds like I can only really count 3 years for my app.
<fbond> Thanks.
<slangasek> directhex: oh, perhaps the ones with '[mono2.0transition]' in the title ;)
<directhex> slangasek, bug 308179, bug 307580, bug 307593, bug 307973, bug 307970
<ubottu> Launchpad bug 308179 in podsleuth "Please sync podsleuth 0.6.3-3 (universe) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/308179
<ubottu> Launchpad bug 307580 in smuxi "[mono2.0transition] Please sync smuxi 0.6.2-4 from Debian Experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/307580
<ubottu> Launchpad bug 307593 in gnome-rdp "[mono2.0transition] Please sync gnome-rdp 0.2.3-1 from Debian Experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/307593
<ubottu> Launchpad bug 307973 in gfax "Please sync gfax 0.7.6-10 (universe) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/307973
<ubottu> Launchpad bug 307970 in giver "Please sync giver 0.1.8-3 (universe) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/307970
<slangasek> directhex: got it - those will all be done shortly, then
<directhex> and one more... 308180
<slangasek> cjwatson: will have a look at those installer packages at the end of this sync run
<directhex> FYI, the deps on ubuntu-dev-tools should be stricter. i get nasty errors running jaunty requestsync on hardy
<directhex> i hope this newer python-launchpad-bugs fixes it
<slangasek> directhex: gnome-rdp in ubuntu has a 0ubuntu5 version number but the bug doesn't discuss whether there are Ubuntu-local changes that we'll be stomping on with a sync?
<slangasek> (bug #307593)
<ubottu> Launchpad bug 307593 in gnome-rdp "[mono2.0transition] Please sync gnome-rdp 0.2.3-1 from Debian Experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/307593
<directhex> slangasek, according to the changelog, it should be synced now
<slangasek> ok
<directhex> "after Hardy this should be simply
<directhex>       synced.
<directhex>  -- Sebastian DrÃ¶ge <slomo@debian.org>"
<directhex> slangasek, and given the debian packager is 1) one of the main pkg-mono people 2) upstream, i'm inclined to think it's worth syncing from now on
<cjwatson> slangasek: ta
<cjwatson> slangasek: any objection to me bumping base-files to 8.04.2 in preparation?
<slangasek> cjwatson: feel free
<cjwatson> (it's a build-dep of debian-installer, you see)
<directhex> aha, alpha 2. THAT's where this talk of cd space came from
<slangasek> directhex: ok, syncs done except for gfax (since as dholbach notes, the tgzs don't match and a fake sync is needed)
<slangasek> directhex: how far ahead does that move us? :)
<directhex> slangasek, did you catch [14:13] <directhex> and one more... 308180 ?
<slangasek> yes
 * directhex updates wiki
<cjwatson> https://bugs.launchpad.net/ubuntu-cdimage/+bug/140458/comments/33 any objection to me just doing that?
<ubottu> Launchpad bug 140458 in wubi "Provide official Ubuntu metalink files on a public webserver" [Low,Fix released]
<cjwatson> slangasek: I assume I should edit the files in MirrorMetalink/templates/ ?
<apw> superm1, hey when you were seeing the ACPI: EC: stuff which kernel was that with, it is looking here like it is probabally resolved on the kernels i am running
<directhex> slangasek, with all of the above packages done, then only the ones i named remain. i'll need to assess the impact of starting on libs "early", which i'll do once LP has a green light against all the previous syncs
<slangasek> cjwatson: no objection / yes
<slangasek> directhex: sorry, which are the ones you named? I seem to have lost track
<directhex> <directhex> slangasek, most of the remaining apps are waiting for sync, with a couple of exceptions (RainCT needs to poke gbrainy, monodevelop hasn't been done yet, nant & ndoc are exceptionally difficult to do, ikvm is the most evil package in all of creation)
<slangasek> ok
<directhex> i don't know how much we care about breaking ikvm, i think gbrainy should survive libs being done..... i don't know about nant & ndoc's impact if the libs are done early
<directhex> hm, i think i forgot one
<Laney> tangerine?
<Laney> oh, you win \o/
<directhex> Laney, good guess! bug 308189
<ubottu> Launchpad bug 308189 in tangerine "Please sync tangerine 0.3.0+dfsg-3 (universe) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/308189
<cjwatson> doko: are you planning a hardy upload for bug 288279? (8.04.2 is coming up soonish)
<ubottu> Launchpad bug 288279 in openjdk-6 "Wrong path for dejavu fonts" [Undecided,Fix released] https://launchpad.net/bugs/288279
<directhex> slangasek, sorry for missing that one
<slangasek> directhex: no worries, syncing now
<directhex> http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO looks a lot greener than it did an hour ago
<slangasek> and gbrainy is not yet ready to sync?
<slangasek> or is it?
<directhex> nope. rainct wanted to ask upstream for a new version w/ minor fixes
<directhex> you'll have to ask him - it's not a team-maintained package so we can't upload it willy nilly
<slangasek> ok
<directhex> slangasek, what does a fakesync involve, WRT gfax?
<slangasek> directhex: manually applying the Debian diff to the Ubuntu tarball, signing and uploading
<directhex> PITA
<slangasek> yes, blame whoever diverged the tarball :)
<cjwatson> this is why I was banging on about making sure the core stack tarballs are the same :)
<directhex> cjwatson, they are! or i think they are
<directhex> too lazy to md5sum them by hand, but we certainly coordinated that
<cjwatson> wasn't saying they weren't
<cjwatson> just saying that this is the problem I was trying to make sure we didn't encounter there as well
<directhex> right
<directhex> well, any volunteers to do the gfax fakesync? can you think of anyone, Laney?
<directhex> ;)
<slangasek> I can take care of it
 * directhex checks whether any untransitioned apps will die from transitionedlibitis
<Keybuk> pitti: we need to do something, but that something involves an audit of every single d-bus using package
<directhex> gfax is the only 1.0 app remaining
<directhex> well. the only one using libs outside the core mono stack, anyway
<slangasek> directhex: ok, what next then? :)
<directhex> slangasek, well, for minimizing delays? 0ubuntu1 the entire third third of the todo wiki
<superm1> apw, i can give it a test if you've got a link to what you're running
<slangasek> directhex: oh; that doesn't sound fun. :)
<slangasek> directhex: how much of that needs to be done before tomboy benefits? most/all?
<directhex> slangasek, what about f-spot?
<apw> superm1, sure, i guess i should upload exactly what i have installed
<slangasek> directhex: I don't know - how much does converting f-spot buy us in terms of CD space?
<apw> tho. are you using 32 bit, i gues syou are
<directhex> slangasek, tomboy, looks like gtk-sharp2, gnome-sharp2, mono-addins, ndesk-dbus, ndesk-dbus-glib
<directhex> but that's scaning by eye
<superm1> apw, yeah
<apw> ok ... then any of the -11 kernels is basically the same, ie. contains the acpi fix that seems to fix me
<directhex> f-spot needs libflickrnet and gnome-desktop-sharp2 in addition
<directhex> i think that's it
<apw> superm1, the ones here are worth testing: http://people.ubuntu.com/~apw/webcams1/
<superm1> apw, okay i'll take a look in a little bit
<apw> superm1, thanks for that
<pitti> tkamppeter: do you think https://blueprints.edge.launchpad.net/ubuntu/+spec/printer-sharing is still relevant? it's one click in s-c-p now
<slangasek> directhex: which order should those lib packages be done in? in the order you listed them?
<directhex> slangasek, doesn't matter. as long as gfax is done, then there's no danger caused by the order, as the executable which gets executed determines which runtime mono tries to use (i.e. even if one of its deps becomes 2.0 whilst it still remains 1.0 itself, a lib will be 2.0ified at runtime if the app using it is 2.0)
<tkamppeter> pitti, for Linux networks it is all perfect and easy. If you set up a print queue and it works locally, after activating sharing in s-c-p, the printer works as well on remote CUPS clients.
<pitti> tkamppeter: right, as I thought; I updated the blueprint accordingly
<tkamppeter> pitti, only thing which could be improved is sharing a printer to Windows clients. To make it really easy one would need the CUPS driver for Windows, which is not free and there is also not much development done on it.
<slangasek> directhex: I'm quite certain I don't understand that, but ok :-)
<directhex> you earnt a LOL, that's all that matters
<Keybuk> yup, nvidia-glx-180 breaks everything
<superm1> Keybuk, curiosity: what's the context of that?  i've just switched to it and not seen any oddities yet...
<Keybuk> lots of repainting issues
<directhex> ooh, a 180 driver? with vdpau goodness?
<Keybuk> esp. with gnome-terminal, where it simply won't be repainted at times
<Keybuk> and suspend/resume utter fail
<superm1> ah probably only when compizified with the repainting issues.
<superm1> yup they sure are there when i turn it on
<ion_> (offtopic "http://johan.kiviniemi.name/blag/ubuntu-checklist/")
<superm1> apw, well it's starting in polling mode a lot sooner this time, but still seeing that GPE storm
<superm1> apw, and still "missing confirmation, switch off interrupt mode"
<apw> superm1, can you email me the whole dmesg please
<superm1> apw, sure
<apw> thanks a lot ...
<apw> superm1, can you also suspend and resume the machine, i found that had an effect on the poll/interrupt mode
<superm1> apw, i did so at the end of it
<superm1> it's in the same dmesg already
<apw> handy
<slangasek> directhex: so none of the gtk-sharp2 binary packages require a renme for the mono 2.0 transition?
<directhex> slangasek, nope. nothing needs to go to NEW
<slangasek> ok
<slangasek> directhex: gtk-sharp2 uploaded, then; do the other libs all need to be uploaded at roughly the same time?
<directhex> slangasek, there's really no time limit for it. at your leisure
<directhex> now if you'll excuse me, i have a bus to catch
 * slangasek waves
<directhex> erm, a car to drive home. /me needs more sleep
<Fenix|work> Greetings... Would someone be so kind as to tell me how to make a static library version of bash so I can chroot on a 64 bit system?
<DRebellion> Fenix|work, I'm not sure about the static bash compilation, but you may be interested in debootstrap to create a minimal chroot.
<Fenix|work> I'll take it
<cjwatson> Fenix|work: sudo apt-get install bash-static
<Fenix|work> also, while I'm here... how do I fix a f-up that my jr. did to my box... chmod -R 644 * from /
<Fenix|work> cjwatson, bash-static is not abailable, but is referred to by another package.  This may mean that the package is missing, has been obsoleted, or is only available from another source
<cjwatson> Fenix|work: it's available (in universe) in every release since at least dapper
<Fenix|work> cjwatson, for amd64?
<Fenix|work> just uncommented out some of the lines
<Fenix|work> (from /etc/apt/sources.list)
<Fenix|work> cjwatson, is the binary called bash, or something else?
<cjwatson> Fenix|work: yes, for amd64.
<Fenix|work> cjwatson, I installed it, but still no joy... once I'm in the chroot... everything is Permission denied.... even ls
<cjwatson> Fenix|work: /bin/bash-static (use packages.ubuntu.com)
<Fenix|work> bash-static: /bin/ls: permission denied
<cjwatson> sure, bash-static doesn't magically make other executables work
<cjwatson> why not fix stuff up from outside the chroot? chmod will work perfectly well from outside
<Fenix|work> cjwatson, the permissions are mostly fixed... unless I've messed up the permissions on the libraries
<cjwatson> once you have enough fixed to run basic commands, get a list of all the packages you have installed and feed it to 'apt-get --reinstall install'
<Fenix|work> cjwatson, would you be kind enough to help me get the main files/directories straightened out permissions wise?
<cjwatson> 'chmod +x /path/to/chroot/bin/*' and the same for /sbin /usr/bin /usr/sbin ought to take care of most of it. Don't actually try to boot into the system or grant remote access to it until you've reinstalled all the packages, though, as set-id bits and any limited permissions will be wrong
<cjwatson> this really isn't a development topic ...
<Fenix|work> what about libaries?  I've set them to 644
<cjwatson> libraries don't generally need to be executable, so that's fine
<Fenix|work> ok... chmod a+x'd all those directories and still get bash-static: /bin/ls: Permission denied when I chroot in
<Fenix|work> I also have bound /dev /proc and /sys to my mounted volume
<cjwatson> make sure that directories are executable, otherwise the runtime linker will get EACCES when looking for libraries
<cjwatson> e.g. /lib and /usr/lib but also everything else. creative use of find and xargs will be useful
<cjwatson> I have to go and cannot help you further. Please continue on #ubuntu
<Fenix|work> one thing I've noticed when doing ldd on /mnt/bin/ls ... linux-vdso.so.1 isn't pointing to anything ... all the other libs point to files and their permissions are ok.
<Fenix|work> linux-vdso.so.1 =>  (0x00007fffa9dff000)
<cjwatson> that's normal. it's a virtual library provided by the kernel.
<Fenix|work> they don't match
<Fenix|work> linux-vdso.so.1 =>  (0x00007fff959ff000) ... is the one on the livecd
<Fenix|work> could this be my dilema?
<directhex> it's a virtual lib, pointing to a memory address specific to the running kernel
<directhex> so it's normal enough
<cjwatson> you still need to check the permissions on *directories* as well as files. If a directory is not executable then it isn't possible to use files in it
<cjwatson> do that before inventing problems for yourself :)
<Fenix|work> cjwatson, I've essentially done the following... find /mnt/ -type d -exec chmod 755 {} \; ... then furthermore did find /mnt/lib -type f -exec chmod 644 {} \; && find /mnt/usr/lib -type f -exec chmod 644 {} \;
<Fenix|work> as well as changing chmod a+x /mnt/bin /mnt/sbin /mnt/usr/bin /mnt/usr/sbin
<Fenix|work> so if I've missed something... I'd like to know
<Fenix|work> ( as an aside, I've also fixed the permissions in /etc as well )
<Fenix|work> cjwatson, problem solved... a couple of libraries need x permissions
<imachine> Hi, I've had issues with building nvidia drivers on updated 8.04 (updated it to 8.10 yesterday).
<imachine> I'm trying to pin-point the problem, perhaphs together we can sort it out?
<imachine> dkms fails spewing out nvidia build cannot determine kernel version.
<imachine> I've searched on generic linux forums, and it seems that it's caused by the lack of asm-i386 dir (or symlink) in the 'include' dir in the kernel headers, or sources, dir.
<directhex> building nvidia drivers? ubuntu has packaged nvidia drivers
<directhex> and breaking your own system is not a #ubuntu-devel topic
<directhex> only breaking everyone's systems via package production
<imachine> directhex, it was broken by someone else
<imachine> directhex, since I'm using the standard packages ;-)
<imachine> and dkms fails ;)
<imachine> I joined -devel since I thought it'd be a better place to sort the error out.
<imachine> this is the envy output http://pastebin.com/m6320267
<imachine>  http://pastebin.com/m1fb153eb and heere's the make.log
<imachine> so if anyone has any ideas... be my guest, I want this sorted, for me, and for anyone in the future ;]
<directhex> tseliot is elsewhere right now. he's the guy to talk to about envy
<imachine> yeah so I heard
<imachine> it's not really an envy issue tho
<imachine> directhex, http://bbs.archlinux.org/viewtopic.php?pid=328232#p328232 seems this mentioned some sort of fix
<imachine> so it looks like ubuntu version of drivers are not compatible with the new 8.10 kernel...
<imachine> for some reason..
<imachine> ;]
<ScottK-laptop> imachine: Those posts were about 2.6.24 (which is the kernel we have in Hardy, not Intrepid).  If it's something to do with envy, ask tseliot when you see him around.
<Fenix|work> cjwatson, when doing apt-get --reinstall install ... should I consider placing ubuntu-minimal in the list?
<Fenix|work> (or maybe even ubuntu-standard)
<asac> pitti: there? #291417 ... shall i verify that trivial fix so we can get that out of -proposed?
<pitti> asac: please
<imachine> ScottK-laptop, it's not really. I had no prblems on hardy. on intrepid (after upgrading from hardy) they appeared. I will indeed talk to tseliot :)
<imachine> cheers
<YokoZar> hmm there appears to be a pitti and a martin-pitt on launchpad
<pitti> !
<pitti> c'est ne pas moi
<YokoZar> eh?
<pitti> I don't know "Marty Pitt"
<YokoZar> I'm trying to subscribe you to a bug (inspired by your UDS presentation) and I'm not sure which name to use ;) ...then I found your wiki page is empty
<pitti> martin-pitt has 0 karma, pitti has a proper LP homepage and lots of karma :)
<asac> pitti: done
<YokoZar> I suspect martin-pitt was autocreated long long long ago
<asac> pitti: i think I will do the same for the two outstanding -needed tags in nm
<pitti> asac: as long as you are using the actual debs from intrepid-proposed, that's fine (compilation errors, wrong linked libs, and all that)
<asac> pitti: sure. i am on intrepid still
<pitti> asac: nm and nm-applet look good, I'll move that to -updates unless you heared anything bad about it?
<pitti> asac: (I'm just at SRU mangling anyway)
<pitti> ScottK-laptop: any chance you could test the packages in bug 278075?
<ubottu> Launchpad bug 278075 in spamassassin "DSBL is gone and needs to be removed from SpamAssassin" [Medium,Fix committed] https://launchpad.net/bugs/278075
<ScottK-laptop> pitti: Since I uploaded the fix, does my testing count?
<pitti> ScottK-laptop: if you use the actual binaries from the archive, it's much better than no testing at all
<pitti> ScottK-laptop: and the bug looks like being actively detrimental, so it seems to me that this should move to -updates soon
<ScottK-laptop> pitti: OK.  I was hoping the reporter would test it, but let me see what i can do.
<asac> pitti: no nm should be fine ... let me go thorugh the SRU bugs swiftly again
<pitti> asac: just checked -gnome, looks fine; 3/4 verified
<pitti> (tested by me, too, no apparent regressions)
<LaserJock> pitti: do rebuild-only SRUs need to go through the same SRU procedure as everything else?
<pitti> LaserJock: yes
<asac> pitti: ok ... lets move them then.
<pitti> zul: please upload the fix for bug 282518 to jaunty
<ubottu> Launchpad bug 282518 in lsscsi "error messages from lsscsi" [Undecided,Confirmed] https://launchpad.net/bugs/282518
<zul> pitti: np
<pitti> doko: python-lxml now seems to b-dep on cython, didn't do that in intrepid; not described in the changelog, can it build without it, or does it need a MIR?
<DimStar> Good evening everybody.. I'm an author of the library libproxy and a ubuntu user reported an issue with compiling the lib, linking against mozilla-js on Ubuntu 8.10. Libproxy uses pkg-config in order to identify the location of include files, but apparently on Ubuntu 8.10, this seems not to reflect the reality. Is something like this known to you?
<ebroder> Any backporters around who could ACK on #305001 or #301283?
<calc> pitti: suitesparse has been in main before so can it be promoted without a new MIR?
<paulproteus> DimStar, Yo
<DimStar> Hi paulproteus
<paulproteus> I'm not aware of that issue, but do you know about the lib*-dev convention in Debian and Ubuntu?
<paulproteus> DimStar, On Debian and Ubuntu you'll find that you need lib<package_name>-dev to get the right headers and pkg-config information.
<DimStar> paulproteus: not really.. I'm myself openSUSE packager and participate in the libproxy project... and we were informed that this problem exists...
<DimStar> maybe you can follow up all what we know so far:
<calc> isn't suse like foo-devel for the same things?
<DimStar> http://code.google.com/p/libproxy/issues/detail?id=18
<paulproteus> Right, exactly - it's that same concept as foo-devel.
<DimStar> yes... the user apparently has the .pc file on his system (so I assume he has the -dev package)
 * paulproteus nods
<DimStar> but the .pc file point in the --cflags to a location different from where he actually finds the jsapi.h file on his system
<paulproteus> I see that, yeah.
<DimStar> and not knowing all the background behind an ubuntu system I assumed it would be best to get some advice for this issue from you :-)
<directhex> #ubuntu-mozillateam for mozilla oddities
<DimStar> from 'my side' it looks like a werid packaging issue
<DimStar> directhex: I can gladly bring it to the next channel... if this is the best way to go.
<calc> DimStar: or perhaps ping asac but he probably isn't around now (he is in germany)
<DimStar> calc: then he is only a few km away :-)
<calc> DimStar: ah heh
<DimStar> 10:30pm here
<asac> calc: thanks took over in #ubuntu-mozillateam
 * NCommander really hopes restore and backup get better with Jaunty
<NCommander> Restoring is a PITA
<doko> pitti: it *does* have a MIR. see https://bugs.edge.launchpad.net/ubuntu/+source/cython/+bug/299870
<ubottu> Launchpad bug 299870 in cython "MIR for cython" [Undecided,New]
<directhex> does anyone know why nant and ndoc are in main?
<Hobbsee> they look to be directly seeded, but i don't have copies of the seeds here
<directhex> Hobbsee, ndoc needs nant to build - but i'm not sure what uses ndoc these days
 * StevenK updates his seed lists
<Hobbsee> libndoc-cil
<Hobbsee> and the docs
<Hobbsee> strange.
<directhex> Hobbsee, ndoc is a tool for converting .net xmldoc format to other things (e.g. indexed html). i don't see what it serves by being in main in this day & age
<directhex> it might've been used once upon a time instead of monodoc, but i'm guessing
#ubuntu-devel 2008-12-16
<bryce> slangasek: what package are we assigning hotkey issues to nowadays?
 * lamont looks around for jdstrand or any ufw-literate person so he can grumble at them
<StevenK> I can use it, but I didn't write it, does that help?
<jdstrand> lamont: yes?
<lamont> StevenK: how the hell do I add a rule to ufw-user-forward through the &%(%) CLI?
<jdstrand> lamont: you don't-- ufw doesn't allow modification to that chain (yet) via the cli
<jdstrand> lamont: but you can add it to /etc/ufw/before.rules (or after.rules if it makes sense to you)
<lamont> jdstrand: ah... that would explain my frustration.... so... given ufw alive and well on the machine, how do I have forward rules
<lamont> ?
<lamont> or do I just throw baby and bathwater out?
 * lamont learns to read while typing
<jdstrand> lamont: think of ufw as two parts: a) the cli command and b) the framework
<Baby> eh?
<StevenK> Haha
<lamont> rotfl
<StevenK> I would love it if ufw would support SNAT and forwarding rules.
<jdstrand> lamont: the cli command allows for very easy host-based firewalls. the framework allows for all the power of iptables
<jdstrand> lamont: so, add what you want to before.rules, then do 'sudo ufw disable ; sudo ufw enable'
<jdstrand> StevenK: nat would be nice yes
<StevenK> jdstrand: Fix it? :-D
<jdstrand> StevenK: sure, I don't seem to have your patch... :P
<lamont> yeah...  my big issue is (1) two different users with firewall needs that are not up to iptables, but want to co-admin what I set up for them, and (b) the pain that an incomplete ufw brings
<StevenK> Haha!
<lamont> mixed in with the fact that I've never even used iptables-restore...
<StevenK> That's my current firewall script
 * lamont has always just rolled his own - it's not like it's complicated or anything...
<lamont> (given a network-engineering background)
<StevenK> lamont: Simplest way to use iptables-restore is run iptables-save > file, edit the file and iptables-restore it
 * jdong has observed most people struggling with setting up iptables general don't have a solid grasp of what they are trying to do conceptually...
<jdstrand> lamont: for the most part, you can write an iptables rules, and leave iptables off the front
<jdong> not to downplay the significance of that hurdle of course :)
<lamont> heh
<jdstrand> lamont: if I may say, ufw works quite well for host-based firewalls. more than that and there are a few niggles, but works pretty well for the most part
<lamont> jdong: exactly.  given a firm understanding of the protocol interactions, iptables is trivial.  without it, well... pain
<jdong> right.
<wgrant> Pain and insecurity.
<jdstrand> lamont: using it for routing is doable, but likely too hard for now
<jdong> generally when you find someone griping about iptables and ask them to explain specifically what they are trying to do, they fail to be able to do so without resorting to magical terms :)
<jdstrand> but, it is actively being developed... I seem to remember StevenK offering a nat patch not too long ago ;)
 * StevenK kicks jdstrand 
<jdstrand> hehe
 * kees waves good-bye to opera
<NCommander> hey StevenK
<wgrant> kees: Why?
 * StevenK waves to NCommander 
<NCommander> StevenK, how was your flight?
<kees> wgrant: it's not in the partner archive any more except for jaunty
<StevenK> NCommander: Crap
<wgrant> kees: Oh, why? Security?
<kees> wgrant: yeah
 * wgrant sleeps at StevenK.
<NCommander> StevenK, ah, I know the feeling
<lamont> kees: security hard.  lets go shopping
<StevenK> wgrant, NCommander: I slept on the plane for 6 hours, that wasn't why it was crap
<wgrant> Oh.
 * wgrant fidgets instead.
 * NCommander had turberance all the way from Chicago to Rochester
<NCommander> First time I ever got quizzy while flying
 * StevenK kills wgrant, casts Redepmtion on him, and then brutally kills him again
 * wgrant is uninterruptable.
<StevenK> NCommander: The flight was bumpy and turblent, the service was terrible, and BABIES!
<StevenK> Argh, babies!
 * NCommander removes the NMI for wgrant and then calls int wgrant
<wgrant> Ah yes, the babies.
<wgrant> They weren't too bad from where we were (the back row), but they were present.
<wgrant> What was wrong with the service?
<StevenK> Slow
<StevenK> I pressed my call button and waited ten minutes, two times
<wgrant> I did notice that they seemed to do only one side at once and were fairly late.
<wgrant> Hah.
<elitest> hey erbody
 * lamont grumbles at the menu system.. generally speaking, where is the command associated with a menu in the stock menus found?  more specifically, how do I see what command is exceuted for "administration -> create a usb startup disk'??
<lamont> or should I just go to bed/
 * lamont finds his answer, or at least enough of one
 * wgrant wonders what is going on with yorick's armel build.
<wgrant> I've seen it building at least three times today.
<lamont> what does the log look like when it dies?
<wgrant> Illegal instruction.
<lamont> \o/
<wgrant> But somebody keeps retrying it, but it doesn't look like a normal give-back.
<lamont> interesting
 * lamont -> home
<ebroder> I'd like to see an SRU for LP #216761 in both Hardy and Intrepid. Is there some way I can represent in ths bug status that the bug has been fixed in Jaunty, but Intrepid is still affected?
<ubottu> Launchpad bug 216761 in xen-3.2 "errors in xendomains init script" [Undecided,Confirmed] https://launchpad.net/bugs/216761
<ebroder> Should I just open a separate bug for the SRU?
<pitti> calc: suitesparse> that's fine
<pitti> doko: cython> ah, thanks
<pitti> Good morning everyone
 * StevenK waves to pitti 
 * pitti hugs StevenK
<LaserJock> pitti: where are you? it seems quite late for DE
<pitti> LaserJock: no, it's rather terribly earliy
<pitti> 4:42
<pitti> but I can't sleep any more
<ArneGoetje> pitti: can't sleep? :)
<LaserJock> ugg
<ArneGoetje> pitti: jet lag?
<pitti> yeah
<pitti> I slept 2 hours in the plane Sat-Sun, and four hours last night, now 5 hours
<pitti> so I'm making progress :-P
<LaserJock> I'd have thought by now you'd be used to UDSlag
<LaserJock> maybe a person's body never really gets used to it
<StevenK> I'm dealing with jetlag much better than when I started going to UDS
<NCommander> hey pitti
<xivulon> awake here (3am)
<StevenK> I think I'll need one more sleep cycle, and I'll be back in the timezone
<LaserJock> I've only been to 2 out of my timezone, but I think I had more problems while I was there than when I got home
<LaserJock> 'course the Ubuflu got me a few days sleep post-
<StevenK> That's what Melatonin is for, but I only needed that once
<LaserJock> UDS
<ajmitch> StevenK: it helps if you don't have a regular sleep cycle anyway :)
<jamesh> perhaps you could try adjusting to the new time zone a few weeks before going to UDS
<StevenK> ajmitch: I do so!
<pitti> fortunately I didn't get UbuFly on either the way there nor back this time \o/
<pitti> erm, UbuFlu
<wgrant> Very few got UbuFlu.
<StevenK> I think I missed out, too
<StevenK> Hmph. How am I supposed to modify $PATH in debian/rules ?
<jamesh> StevenK: "export PATH" ?
<jamesh> make variables are not exported as environment variables by default
<StevenK> Well, I want to modify it first
<StevenK> Neither $$PATH, $PATH or $(PATH) are giving me love
<jamesh> export PATH := whatever:$(PATH)
<StevenK> Oh, duh, :=
 * StevenK kicks make for being obtuse
<jamesh> ":=" to evaluate immediately
<StevenK> Yup
<StevenK> Hence the "Oh, duh, :="
 * calc was one of the UbuFlu victims
 * NCommander may be developing UbuFlu
<NCommander> Freaking free viruses
<NCommander> NOT WHAT I WANT!
<pitti> NCommander: that's why you are using Linux, aren't you?
<NCommander> Viruses shouldn't be freeware ...
<NCommander> or shareware
<ajmitch> it's all about sharing
<ScottK-laptop> NCommander: Next time you'll know to sit next to people you don't like and breath on them.
 * StevenK stares at the buildlog for apex which insists -Bsymbolic-functions isn't valid
<StevenK> ScottK-laptop: Harsh
<ScottK-laptop> But realistic.
<StevenK> Someone remind me to keep at least one room distance from ScottK-laptop
<NCommander> StevenK, apex is packaged?
<StevenK> And in both Ubuntu and Debian
<ScottK-laptop> Apparently not very well.
<StevenK> I think it's an upstream thinko
 * StevenK hits ScottK-laptop with the shovel he just used to move blame around
<NCommander> lol
 * NCommander grumbles :-/
 * ScottK-laptop has had too much Scotch to actually feel it, so whatever.
<NCommander> o_o;
 * NCommander decides to take another whack at kde
<StevenK> NCommander: KDE on armel?
<NCommander> yeah
<NCommander> Argh
<NCommander> kde4libs is still building
 * LaserJock just lost his grading pen :(
 * NCommander is currently waiting for a few more test images to finish with imagewriter-qt
<ajmitch> LaserJock: all you need is a big red pen, right?
<LaserJock> ajmitch: yeah, but i was down to my last one
<LaserJock> I got up, got a drink of water, came back, no pen
<LaserJock> but I just found it behind my laptop so all is not lost
<LaserJock> poor students :-)
<StevenK> Ah ha. Now I get why apex built on Debian, but not Ubuntu.
<StevenK> dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions
<NCommander> So apex is fixed StevenK
<StevenK> NCommander: Oh?
<NCommander> ^?
<StevenK> NCommander: Fixing. It's in the queue after this schroot build
<NCommander> ah, nice :-)
<NCommander> We should probably have redboot packaged ...
<StevenK> gcc-snapshot adds a whole lot to the Build-Depends
<pitti> calc: no, suitesparse is in hardy/universe, and I can't find a MIR wiki page or bug
<StevenK> pitti: Looks like I need three armel packages promoted for d-i, shall I write three MIRs and prod you?
<calc> pitti: it had been in main for 3.0.0-3 in gutsy but got knocked back into universe
<calc> pitti: lp-solve had also been in gutsy main at one point but got knocked back out as well
<ebroder> For a package that's not in Debian, am I supposed to set XSCB-Original-Maintainer, or am I the maintainer?
<lool> morning
<nxvl> morning
 * pitti recovers from X segfault after dist-upgrade
<pitti> StevenK: just subscribe ubuntu-mir, I'll get mailed
<pitti> calc: okay
<nxvl> pitti: good morning
<pitti> hey nxvl
<pitti> slightly more civilized time now :)
<StevenK> pitti: Hum? Do I need to write 3 seperate MIRs, or something else?
<pitti> StevenK: if it's three unrelated sources, yes; if they are trivial, just file bug tasks
 * StevenK needs to fix one of them to build first
<pitti> tjaalton: so you broke X on G945 :)
<lool> pitti: Do you think it's specific to this chip?  I'm pondering dist-upgrading to jaunty, but then not if I'd miss xorg on intel (I have g33 though)
<nxvl> pitti: you have a 2 lines terminal, right?
<pitti> lool: I don't know
<dholbach> good morning
<pitti> nxvl: "2 lines"?
<nxvl> s/terminal/promt
<pitti> hey dholbach
<nxvl> promt
<pitti> nxvl: yes, why?
<dholbach> hi pitti
<nxvl> pitti: i'm playing with mine, and i'm having a strange issue, when i type a long command which doesn't fit in my terminal it continues on the beggining on the same line
<nxvl> pitti: have you seen something like this
<nxvl> dholbach: hi!
<pitti> nxvl: only on the VTs, not in gnome-terminal
<nxvl> i've it everywhere
<dholbach> hiya nxvl
<tjaalton> pitti: yes, and no way to fix it until the drm.h issue is solved (the segfault is fixed upstream) :)
<pitti> tjaalton: oh, is that the linux-libc-dev vs. libdrm-dev file conflict?
<tjaalton> pitti: yes
<pitti> tjaalton: ah, so if I rebuild -intel against the right one, it shuold work?
<tjaalton> everything that b-deps libdrm-dev should fail to build
<tjaalton> pitti: it's a bug in the xserver, not the driver
<pitti> tjaalton: I just tried locally rebuilding -intel, doesn't work
<pitti> oh, ok
<pitti> tjaalton: so that's xorg-server?
<tjaalton> pitti: yes
<tjaalton> bug 308225
<ubottu> Launchpad bug 308225 in xserver-xorg-video-intel "X intel driver crashed at xf86CrtcSetMode()" [Unknown,Confirmed] https://launchpad.net/bugs/308225
<tjaalton> duh
<pitti> tjaalton: I'll duplicate my bug then (bug 308464)
<ubottu> Launchpad bug 308464 in xorg-server "1.5.99.3 crashes on G945: intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70" [Undecided,New] https://launchpad.net/bugs/308464
<tjaalton> pitti: oh, that might be different, let me check
<pitti> tjaalton: I do have the current version, though, so it's not FTBFS
<tjaalton> pitti: I meant that uploading a new version would FTBFS
<StevenK> pitti: slugimage and uboot-mkimage look completly trivial, do you still want MIRs?
<pitti> StevenK: as I said, only for nontrivial packages; we always need MIR bugs, but not always wiki pages
<tjaalton> pitti: looks similar enough, I'll dupe it
<StevenK> pitti: Okay, I'll file one bug for all three, but only do a report for apex.
<nxvl> k, fixed
<slangasek> bryce: depends on the kind of issue? :)
<tjaalton> what should be done about bug 308387?
<ubottu> Launchpad bug 308387 in linux "[Jaunty] trying to overwrite `/usr/include/drm/drm_sarea.h', which is also in package libdrm-dev" [Undecided,Triaged] https://launchpad.net/bugs/308387
<tjaalton> debian does not have drm/* in their package, so the change seems to have pulled in a bit too much
<bryce> tjaalton: can you set https://blueprints.edge.launchpad.net/ubuntu/+spec/xorg-jaunty to completed (unless you wish to use it for tracking progress or something)?
<tjaalton> bryce: hmm ok
<StevenK> pitti: MIR filed. Bug 308465
<ubottu> Launchpad bug 308465 in uboot-mkimage "MIR for slugimage, uboot-mkimage, devio and apex" [Undecided,New] https://launchpad.net/bugs/308465
<StevenK> pitti: I should say sorry for including the word "hand-wave" in an MIR
<pitti> tjaalton: bug 308225 updated; I have my normal X back \o/
<ubottu> Launchpad bug 308225 in xserver-xorg-video-intel "X intel driver crashed at xf86CrtcSetMode()" [Unknown,Confirmed] https://launchpad.net/bugs/308225
<NCommander> yay pitti
<pitti> tjaalton: hey, and the "Control-C kills server" bug is fixed, too
<tjaalton> pitti: great, I've pulled 1.6-branch and will upload. it will FTBFS though because of the aforementioned kernel bug
<bryce> tjaalton: thanks
<tjaalton> bryce: my pleasure ;)
<tjaalton> pitti: strange, AllowEmptyInput is the default
<pitti> tjaalton: I killed xorg.conf again, doesn't crash any more; I needed the file with 1.5
<tjaalton> pitti: so the ctrl-c thingy should've not had any effect
<wgrant> tjaalton: I found I needed to tell evdev to GrabDevice on statik's VM last week.
<wgrant> Same on my machine.
<wgrant> It works fine without now.
<tjaalton> huh, weird
<wgrant> Yes.
<tjaalton> but, if it works now.. \o/
<wgrant> Yep.
<wgrant> Once that segfault gets fixed.
<tjaalton> yep.. and not everyone can/should touch the kernel
<wgrant> Of course.
<tjaalton> so it'll take some time
<bryce> heya fabbione
<fabbione> hey bryce
<tjaalton> I guess no-one has tried nvidia/fglrx with the new xserver?
<wgrant> I don't think anybody is that crazy.
<wgrant> There's a new video ABI, isn't there?
<tjaalton> wgrant: yes, the packages should be rebuilt if they work
<bryce> I assume both are busted now
<wgrant> And probably will be until the day before release.
<tjaalton> safer to assume that :)
<tjaalton> but not necessarily, since there shouldn't be same kind of API changes like with 1.5, AIUI
<bryce> wgrant: well, I'm scheming to get them working sooner than that ;-)
<tjaalton> I'll install a box with 8600GT to test nvidia..
<lool> tjaalton: concerning drm, I wrote to upstream a while ago and he said that the drm headers were now moving to the kernel; so I understand that we should drop them from libdrm and add Replaces
<lool> I can forward you the emails if you like
<tjaalton> lool: ok, that would be nice
<bryce> heya lool
<lool> hey
<lool> tjaalton, bryce: forwarded
<tjaalton> lool: thanks
<tkamppeter> pitti, hi
<\sh> pitti: taking care of bug #298611
<ubottu> Launchpad bug 298611 in ia32-libs "ia32-libs 2.7ubuntu1 missing libuuid.so.1, breaks flash" [High,In progress] https://launchpad.net/bugs/298611
<\sh> pitti: why didn't you merge all the changes from intrepids into jaunties ia32-libs regarding debian/rules?
<pitti> \sh: I did, TTBOMK; there might have been some obsolete stuff; what do you mean in particular?
<\sh> pitti: the libnspr4.so.0d symlinks as an example :)
<pitti> \sh: that didn't apply any more (I don't remember the reason any more, though)
<\sh> pitti: ah ok...I'll have a look...I hope that they are set now by default :)
<pitti> I didn't just ignore it, I remember investigating this
<directhex> is it okay to request a sync now if it build-depends on something i need to 0ubuntu1 this evening?
<NCommander> directhex, what needs syncing?
<\sh> does anyone has problems connecting to a.u.c (91.189.88.40)?
<NCommander> a.u.c?
<NCommander> expansion needed :-)
<pitti> archive.ubuntu.com
<NCommander> Yes.
<pitti> \sh: WFM
<directhex> NCommander, gnome-subtitles from experimental. it has a new dep which is in debian NEW right now, so i need to 0ubuntu1 it
<NCommander> directhex, no Ubuntu changes?
<pitti> \sh: well, I might have caught a different mirror, of course
<NCommander> Is that in main or universe?
<directhex> NCommander, ubuntu changes? this is pkg-mono you're talking about! and it's universe
<NCommander> fair enough
<NCommander> Ok
<NCommander> What you can do is a fast sync
<NCommander> Version an upload with 0build0 (or something equivelent)
<NCommander> Essentially what your doing is making it so when gnome-subtitiles clears NEW, it will autosync
<directhex> aha, clever
<directhex> thanks for that
<NCommander> (you could probably use 0sync0, but the version string must be less than 1, and not contain the ubuntu substring for this handy trick to work)
<maxb> Rather handy that "ubuntu" comes late in the alphabet, all things considered :-)
<NCommander> Actually, the ubuntu substring is what kate uses to determine if it should autosync something
<NCommander> (as far as kate is concerned, 0ubuntu1, 0~ubuntu1, etc. are all equivelent)
<maxb> What I mean is, it's because b < u that it doesn't have to be -0~build0, right?
<NCommander> Yeah
<NCommander> I know we do some funny things w.r.t. to versioning in dpkg
<directhex> the alphabet is one of my main complaints about the popular "~ppa" suffix ;)
 * NCommander hates that hack
<NCommander> PPAs should autoversion like REVU
<directhex> NCommander, perhaps. they certainly shouldn't encourage use of ~ppa which supersedes foo-backports' ~foo
<NCommander> ACK
<directhex> well, that problem goes away once persistent prawn gets released
<NCommander> TBH, crackport and SRU versioning is fairly miserable
<NCommander> crackports are slightly better
<NCommander> I wish SRU would just standardize on one style of versioning and that would be that :-)
<directhex> the most awesome package version in the world though has to be 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2
 * NCommander hears Scott groan
<NCommander> There is a really sad story about that one
<Mithrandir> directhex: it's clearly missing +added+salt+and+pepper+stab+stab+stab in the version number.
<NCommander> directhex, well, that happened because we had a crackport that broke firefox and flash
<NCommander> :-)
<\sh> sounds like flash ,-)
<NCommander> We had to do an emergency downgrade
<directhex> NCommander, or qt3? 3:3.3.8really3.3.7-0ubuntu11.1
<NCommander> TBH, I don't know the story about that one.
<gnomefreak> it was flash. I backoprted it before it was final and it broke the 64 bit users so it was reversioned
<NCommander> Flash doesn't even work on 64-bit archs O_o;
<directhex> NCommander, iirc 3.3.8 had a completely broken databse lib
<gnomefreak> NCommander: it sure does
<directhex> there's a 64-bit flash lib now
<NCommander> flash-nonfree works on 64-bits out of the box?
<NCommander> We don't support it in Ubuntu
<NCommander> 64-bit flash is not freely redistirbutable
<directhex> but nspluginwrapper is a sorry beast. it takes me ~7 browser restarts to read my daily webcomics
 * NCommander hugs his 64-bit flash plugin
<gnomefreak> NCommander: we dont support it due to it being non-free
<NCommander> No more sudden firefox crashs
<NCommander> gnomefreak, when I say support
<NCommander> I mean any support
<NCommander> YOu can't install 64-bit flash via apt-get
<gnomefreak> NCommander: why cant you?
<\sh> oh darn...
<NCommander> you can't redistribute the 64-bit flash binaries
<directhex> NCommander, meanwhile, i have a nice friendly 64-bit moonlight plugin sat right here...
<NCommander> It says so in the license
<NCommander> directhex, right, but there are no useful silverlight pages out there
<\sh> if this ia32-libs insaneness doesn't stop...we deliver a complete libubuntu 32bit version in it
<directhex> NCommander, that's because everyone(tm) uses flash!
<directhex> \sh, multiarch dpkg!
<NCommander> directhex, try dpkg-cross/apt-cross
<\sh> pitti: what do you think about bug #277454
<ubottu> Launchpad bug 277454 in ia32-libs "libSDL_image.1.2.so.0 and libpython2.5.so.1.0 are missing in ia32-libs" [Wishlist,New] https://launchpad.net/bugs/277454
<pitti> \sh: at the given rate/size I seriously consider replacing it with a 1 KB shell script to set up a 32 bit chroot
 * NCommander has coded against SDL
<directhex> NCommander, showing my age here. i remember discussing multiarch amd64 with Mithrandir yeeeeeeeears ago
<NCommander> Why can't we simply use apt-cross in this case
<pitti> this is and remains a pain in the butt, and it is a gross and unsupported hack
<NCommander> the ia32 linker actually works last time I checked
<NCommander> ^with apt-cross's paths
 * NCommander would love if we could kill ia32-libs
<tjaalton> lool: so, linux-libc-dev needs Replaces: libdrm-dev (<= current), and the new libdrm-dev should just drop the headers and possibly depend on linux-libc-dev?
<TheMuso> oss/c
<Keybuk> that was weird
<Keybuk> updated to intrepid-updates, and every single process segfaulted after the reboot
<lool> tjaalton: No, you need to push a new libdrm first
<pitti> Keybuk: !
<lool> tjaalton: then replace libdrm << new-version
<lool> tjaalton: You might also want to add some versionned dep one way or the other e.g. let the new libdrm dep on the new linux-libc-dev
<Keybuk> pitti: it's mysteriously fine now
<Keybuk> things went wrong after the nvidia module was build and assumedly inserted
<Keybuk> but after a reboot it was ok
<Keybuk> I'm also suspicious that the machine gave one of its strange beeps on the reboot before, and may have needed a full power down
<tjaalton> lool: of course, libdrm is first. and I can't add the Replaces to linux-libc-dev, so that'll just have to wait
<lool> The two uploads need to be coordinated
<lool> tjaalton: Do you have a new libdrm upstream version without the headers?
<tjaalton> lool: in a minute
<tjaalton> upstream? no
<lool> tjaalton: Perhaps you want to poke upstream about it?
<lool> the thread was in september
<lool> and we're well within 2.6.28 now
<tjaalton> lool: why? isn't it enough to just drop them from the package?
<tjaalton> oh you mean it's newer in .28?
<tjaalton> gah, those are never going to be in sync
<lool> tjaalton: It's enough, but if you get a new upstream version it will be best that this API move is made upstream and your dependency will look like replaces: libdrm << x.y and will be compatible with debian's
<tjaalton> libdrm releases are rare
<lool> Yeah :-/
<lool> tjaalton: still wouldn't hurt to ask for a heads up
<tjaalton> lool: ask who? I'm lost now :)
<lool> Dave Airlie
<\sh> pitti: the symlinks are provided now automagically ,-)
<tjaalton> lool: seems to be too late/early to get a prompt reply
<lool> tjaalton: I guess you need to grab someone from the kernel team to ack this move and coordinate your uploads
<\sh> bah uploaded that monster of source package
<pitti> asac: Michael Biebl was on a NM packaging spree yesterday and today; might be an useful merge (not sure how closely you cooperate)
<pitti> \sh: it was nice while it consisted of 10 packages, but right now it is an unmaintainable and very brittle monster; WDYT about dropping it completely and providing a shell script around debootstrap instead?
<NCommander> Can someone explain to me why ia64 is building ia-32libs?
<pitti> I honestly think that would be much more maintainable
<Mithrandir> NCommander: because it needs it to run ia32 executables?
<broonie> NCommander: It can use it.
<NCommander> ia64 can run ia-32 binaries?
<\sh> pitti: well, the problem will be wine32 for amd64
<NCommander> I thought that only worked in Windows because MS enginneereed a software emulator
<pitti> \sh: can't that run in a chroot?
<\sh> pitti: that was what I was proposing since ages...but nobody agreed on this one with me :)
<\sh> pitti: talk to Yokozar (Scott) about it..because the whole ia32-libs situation is a mess...and should be cleaned up asap
<pitti> \sh: that's what I did last week
<pitti> Scott said he might go for changing the packages to build lib32foo
<pitti> but that's a huge effort as well
<pitti> so until (if ever) we get proper multiarch support, people should install a 32 bit chroot
<\sh> pitti: that will take ages..
<directhex> NCommander, it's emulated, but YES
<broonie> There's been some effort to move to lib32 in Debian.
<StevenK> It's an enormous amount of work in either case
<pitti> but even building lib32foo is just a hack, and far from a proper solution
<pitti> besides utterly complicating packaging
<\sh> pitti: and yes...the 32bit chroot with dchroot magic will help us all...but that was my proposal for people needing wine on amd64 in 2005/2006 already...
<StevenK> ....
<StevenK> wine works on amd64
<StevenK> And if you don't think it doesn't, at least ajmitch and I use it to play WoW
<pitti> StevenK: without ia32-libs?
<\sh> StevenK: it does work because of the ia32-libs madness
<directhex> jms@orac:~> uname -m
<directhex> ia64
<directhex> jms@orac:~> file a.out
<directhex> a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), for GNU/Linux 2.6.4, not stripped
<directhex> jms@orac:~> ./a.out
<directhex> Hello World!
<directhex> NCommander, ^^
<\sh> StevenK: and no, wine on amd64 doesn't work...because they are starting right now to implement win64 apis ,-)
<NCommander> directhex, you must love your itantic
<NCommander> and wine works fine on amd64
<directhex> NCommander, jms@orac:~> grep -c ^processor /proc/cpuinfo
<directhex> 256
<pitti> doko_: should packages still b-dep on java-gcj-compat-dev? or default-jdk-builddep only?
<NCommander> o_o;
<directhex> NCommander, who couldn't love that face?
<StevenK> Ah, but with ia32-libs
<StevenK> directhex: Guh?
<NCommander> wine is 64-bit native app
<NCommander> It just can only run 32-bit windows apps
<NCommander> And given the state of 64 on Windows, I think Linux will have 64-bit windows apps before windows users :-)
<StevenK> NCommander: It does require ia32-libs, though
<directhex> StevenK, would you believe me if i said gnome is still a big sluggish on there?
<NCommander> It does?
<\sh> NCommander: yes
<StevenK> NCommander: It's in the Depends line
<NCommander> neat
<\sh> NCommander: because native wine on amd64 would give you win64 compatiblity ;)
<StevenK> directhex: Gnome is perfectly usable on my amd64 :-P
<directhex> \sh, not that simple
<\sh> directhex: if it would work right now...but it never worked ;)
<NCommander> \sh, well, for one thing, GCC doesn't support the x64 calling conventions used by Microsoft
<directhex> doesn't win64 assume long is 32-bit?
<directhex> or somesuch
<asac> pitti: not sure. he usually is behind. I can ask him anyway.
<pitti> asac: not urgent, just FYI
 * NCommander notes Win64 is WEIRD
<pitti> I got some 50 commit logs from alioth svn, all updated to 0.7
<NCommander> I had to pleasure of writing IE-64 plugins
<NCommander> Ugh
<pitti> NCommander: weirder than win32?
<asac> pitti: yeah. usually we share stuff through upstream ... he didnt want to share packaging
<NCommander> That was nasty
<pitti> asac: okay
<NCommander> pitti, it gets weird w.r.t. to COM and Unicode and stuff
 * NCommander had a bunch of weird typedefs to get it building on i386, amd64, and itanatic
<asac> pitti: i guess the commits are because of the git migration
<directhex> NCommander, come now. if you think ia64 linux is a fringe platform, are there more than six people in microsoft's basement who use ia64 windows?
<NCommander> We had five of them at my last company
<NCommander> Hence why I had to port our inhouse IE plugin to the itantic
<NCommander> Which involved more fun like compiling MySQL for that beast
<NCommander> Without VS professional
<NCommander> (I got the compilers from the SDK, then hacked a makefile to link everything properly)
<NCommander> I don't actually think the ia64 is a horrible platform
<NCommander> It's got a rock-solid toolchain
<NCommander> I might even pick up a machine
<NCommander> (I'm told the ia64's Canonical have were ebay specials, I might just do the same thing)
<asac> pitti: against which subtree did those commits go?
<pitti> asac: packages/experimental
<pitti> asac: http://svn.debian.org/wsvn/pkg-utopia/?op=log&rev=2674&sc=1&isdir=1
<asac> yeah
<pitti> asac, lool, kees: if you have some time today, I'd appreciate some help for MIR processing (bug 305790 in particular); I already did a bunch, but completing this alone would take my entire day
<ubottu> Launchpad bug 305790 in suitesparse "MIR - move to main for openoffice.org 3 build-depends" [Undecided,Fix released] https://launchpad.net/bugs/305790
<asac> urgh
<\sh> NCommander: http://repo.or.cz/w/wine/wine64.git <- it needs something new for the gcc toolchain...and it's far away from being mainline
<NCommander> Yeah, I saw that
 * NCommander reads Slashdot too
<NCommander> ooooh
 * \sh doesn't ;)
<NCommander> I'm happy I'm not on MIR :-)
<sebner> \sh: everything ok with your fork so far? :)
<\sh> sebner: yepp...status green :)
<sebner> \sh: great =)
<pitti> Keybuk: just for coordination with my DK uploads, do you happen to know when you plan to upload udev 130?
<Keybuk> pitti: this week sometime
<pitti> Keybuk: ah, great
<Keybuk> depends how long it takes me to do it
<Keybuk> and how long it takes me to do the things I want to do first
<mnabil_work> j #gentoo
<mnabil_work> sorry
<tseliot> Keybuk: is the new dbus (the one with the security fix) available anywhere (e.g. PPA) for testing already?
<Keybuk> no
<tseliot> Keybuk: ok
<Keybuk> I can make a "correct" D-Bus config file available
<Keybuk> but it will break your system
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<fabbione> hi guys
<fabbione> what was teh sysadmin channel here on irc? #canonical-admin?
<cjwatson> #canonical-sysadmin
<fabbione> hi cjwatson .. thanks!
<NCommander> hey cjwatson
<NCommander> cjwatson, how goes it?
<cjwatson> getting by :)
<NCommander> cjwatson, how's your new kid?
<cjwatson> great
<NCommander> boy or girl?
<fabbione> cjwatson: are you getting any sleep? ;)
<cjwatson> starting to sleep something that vaguely approaches normal hours, though it'll be a while yet ...
<cjwatson> girl
<fabbione> ehhe
<\sh> cjwatson: congrats :)
<cjwatson> thanks :)
<doko_> pitti: default-jdk-builddep has a dependency on java-gcj-compat-dev
<pitti> doko_: I know, my Q was whether packages should b-dep on default-jdk-builddep, or whether it's okay to pull in openjdk-6 or gcj-compat-dev directly
<pitti> doko_: so far I rejected most of the OO.o MIRs due to that
<doko_> pitti: default-jdk-builddep, no explicit b-d on openjdk-6 if possible
<ogra> sigh ... so many PAS on the armel ftbfs page
<directhex> twelvety!
<directhex> armel/experimental buildd should help matters
<NCommander> ogra, I take it LP isn't quite respecting PAS properly?
<ogra> directhex, not for things like newlib, vbetool, acpica-unix, linux86, libx86 atc
 * NCommander filed a bug about that
<ogra> cool
<NCommander> ogra, probably the mass giveback broke things
<ogra> most of them were there before it
 * NCommander shrugs
<ogra> newlib is new
<NCommander> newlib isn't in PAS
<directhex> longcat is long?
<NCommander> One would think.
<ogra> heh
<ogra> hmm, fontforge still seems to call libtoolize --force --copy
<Keybuk> ogra: missing --install
<ogra> Keybuk, well, it also calls aclocal and autoconf so i think autoreconf should just replace all of that
<Keybuk> agree
<NCommander> ogra, sounds like RPM ...
<ogra> well, rpm only exploded *after* i ran autoreconf ... :)
<NCommander> The sad part is we need rpm to be lsb-complaintant :-/
<NCommander> argh
<NCommander> Is it still borked?
<asac> pitti: do we have a special java policy ... or just debian one?
<fabbione> NCommander: you know rpm and .spec files are not that bad afterall.. the problem is stuff like yum that makes it a hell
<directhex> rpm needs to learn KISS. it's powerful, but very easy to hang yourself with
<NCommander> RPM got a lot better after they added the vender field
<NCommander> I do perfer the RPM source format over the debian one
<NCommander> in some ways
<NCommander> I hate RPM management tools
<NCommander> Nothing compares to pbuilder/sbuild/dput
<Keybuk> NCommander: except perhaps having your testicles ritually grated over a hot fire
<fabbione> NCommander: well mock is decent and easy to setup.. same level of pbuilder
 * ogra only cares that the resulting rpm binary works ...
<NCommander> Keybuk, o_o;
<NCommander> ogra, +1
<NCommander> I used to use Red Hat 5
<NCommander> I blew my feet off a few times
<NCommander> :-)
<fabbione> NCommander: well I have to do rpm packaging on a daily base now :)
<fabbione> some how I can talk from experience ;)
 * NCommander sighs
<NCommander> ogra, we'll probably have to give RPM a rootcanal to get it building, and rip out popt and zlib from it and force it to use system libraries
<ogra> NCommander, i have the new version half way packaged ... but want to have a less jetlagged haed to finish it off ...
<NCommander> There is a new version?
<NCommander> Which new version?
<ogra> somehow my brain still thinks it's 4am
<NCommander> THe Red Hat RPM 5? Or the other RPM5?
<ogra> 4.6.x
<NCommander> when did that come out O_o?
<ogra> we have 4.4.x
<NCommander> Oh fun
<directhex> alias rpm='alien --to-deb && dpkg'
<directhex> done!
<ogra> its in beta(something), but i was told by several RH people i should rather ackage that version than poking around in 4.4.x
<NCommander> Might want to poke the RPM maintainer
<ogra> FC10 ships with 4.6.x
<NCommander> Or we could just go with that :-)
<ogra> so i assume its relatively safe
<NCommander> I don't know of anything that actually uses Debian RPM or apt-rpm
<ogra> after all its only needed by lsb and alien
<NCommander> yeah
<NCommander> We should probably run that lsb compliance checker Theodore T'so talked about at UDS
<NCommander> Make sure everything stacks up on ARM
<tkamppeter> pitti, about the CUPS SRU, I have put it together except your Brother fix. How should we proceed?
<asac> doko_: why are the glassfish jars/packages not starting with lib prefix?
<ogra> Keybuk, heh, fontforge doesnt run --install because of:
<ogra>     cp /usr/share/misc/config.guess /usr/share/misc/config.sub fontforge/mensis/
<ogra>     set -e; cd fontforge/mensis; libtoolize --force --copy; aclocal; autoconf
<cjwatson> mvo: conflictchecker seems to need a poke to update it to jaunty
<doko_> asac: I didn't package these
<asac> doko_: ah. ok
<asac> doko_: is default-jdk/jre ubuntu specific?
<mvo> cjwatson: conflictchecker is currently unhappy, I was working on it with lifeless on uds, we are close but not quite ready yet
<StevenK> cjwatson: d-i is unhappy on armel, I've filed the relevant MIRs to help prod it along (LP #308465)
<ubottu> Launchpad bug 308465 in uboot-mkimage "MIR for slugimage, uboot-mkimage, devio and apex" [Undecided,New] https://launchpad.net/bugs/308465
 * ogra hugs StevenK for uboot-mkimage
 * ogra strikes it from his MIR list :)
<cjwatson> StevenK: thanks, I thought devio had been done a while back already
 * StevenK checks
<StevenK> It had, yeah
<StevenK> <- is a dork
 * NCommander handwaves
 * ogra waits for several people die in wristpain with all the handwaving since UDS
<StevenK> Hey, I'm proud of that MIR. It contains the word "hand-wave"
<ogra> haha
<doko_> pitti: *cough* ia32-libs back to main as a dependency for wine?
<cjwatson> pitti: lool says you have a fix for X/jaunty/intel 965?
<cjwatson> it just died on me ...
<lool> 09:04 < pitti> tjaalton: bug 308225 updated; I have my normal X back \o/
<ubottu> Launchpad bug 308225 in xorg-server "X intel driver crashed at xf86CrtcSetMode()" [High,Fix released] https://launchpad.net/bugs/308225
<cjwatson> pitti: (actually, never mind, I just found the discussion)
<cjwatson> ah yes, the drm stuff I heard about
<cjwatson> I'll abuse it into building locally
<DktrKranz> doko_: mind looking or commenting at bug 254790?
<ubottu> Launchpad bug 254790 in binutils "strip segfaults on dietlibc-built executables" [Unknown,Fix released] https://launchpad.net/bugs/254790
<lool> cjwatson: right we discussed the drm issues on #ubuntu-kernel
<lool> and here a little
<doko_> DktrKranz: already done, I think pitti did notice.
<afflux> bug 303040 seems to only need a rebuild. Could anyone have a look at it?
<ubottu> Launchpad bug 303040 in gnome-python-desktop "amd64's python-gnome2-desktop misses modules" [Medium,Triaged] https://launchpad.net/bugs/303040
<seb128> afflux: looking
<afflux> thanks
<DktrKranz> doko_: ubuntu task is still open, "Fix released" is related to upstream task.
<ogra> oh, sigh, fontforge packaging is a PITA
<cjwatson> ok, so X at least starts now, but gdm hangs after typing my password
<cjwatson> AUDIT: Tue Dec 16 14:07:11 2008: 6121: client 4 rejected from local host ( uid=0 gid=0 pid=6446 )
<cjwatson> AUDIT: Tue Dec 16 14:07:30 2008: 6121: client 4 rejected from local host ( uid=1000 gid=1000 pid=6485 )
<cjwatson> this can't be helping
<wgrant> IIRC I get that and it still works fine.
<wgrant> (after patching xserver so -intel doesn't make it segfault)
<pitti> re; sorry, did a nap (getting up at 4:30 has some downsides...)
<pitti> asac: using default-jdk/jre is debian standard now, too, but doko would know better
<cjwatson> pitti: don't suppose you had problems with gdm hanging after upgrade, did you?
<pitti> tkamppeter: why should we leave out the brother fix?
<pitti> doko_: ia32-libs> nope, that's why I discussed multibuild of libraries with YokoZar
<pitti> cjwatson: yes, I just pulled the two upstream commits and rebuilt xorg-server; before that I was using vesa
<cjwatson> amusingly my laptop didn't work with vesa either (!)
 * pitti hugs se128, how are you?
<pitti> cjwatson: no, gdm, X, video etc. works fine again
<pitti> 1.6beta3 even fixes that crash on Control-C
 * Keybuk has definitely decided he has a compiz bug
<Keybuk> the GTK+ FileChooser dialog appears too small
<cjwatson> damn, I was hoping it wasn't just me
<Keybuk> but the hilarious thing is that first it appears scaled down ;)
 * seb128 hugs pitti, good thanks, you?
<pitti> seb128: fighting with timezones, but otherwise okay; didn't get a cold this time
<pitti> cjwatson: silly question, but you are fully up to date (mirror?), so no version skew between drivers and server?
<seb128> pitti: ah, I'm dealing fine with jetlag, I managed to do 23h to 11h nights
<pitti> cjwatson: I'm on intel GM945
<cjwatson> pitti: pretty sure ...
<rickspencer3> bueno: I hear you're the guy who can give me rights to the fridge
<pitti> hey rickspencer3
<calc> fun, i see all my new OOo build-deps need to be migrated to default-jre, lol
<calc> i'll be busy today :)
 * pitti hugs calc
<calc> pitti: do you know of any simple cdbs java package already migrated so i make sure i do the right thing?
<rickspencer3> pitti: hi
<pitti> calc: unfortunately, seems that many of those aren't maintained very intensively in Debian either; but kaffe is a no-go for main
<calc> pitti: yea
<pitti> calc: everything in main should DTRT already; try ant, it uses cdbs
<calc> pitti: ok thanks
<pitti> calc: or jakarta-log4j
<calc> pitti: thanks for the examples :) i'll see if i can get these done in a few hours
<pochu> rickspencer3: s/bueno/beuno/g ? :-)
 * directhex prepares rather high priority patch
<ikonia> patch away !
<directhex> currently all gtk# apps in jaunty are broken
<beuno> rickspencer3, hi
<beuno> you should use the tab key, it's awesome!
<directhex> can someone who isn't staggeringly busy either give https://bugs.launchpad.net/ubuntu/+source/gtk-sharp2/+bug/308619 a high priority, or put it into the archive?
<ubottu> Launchpad bug 308619 in gtk-sharp2 "Links against private Mono.Cairo lib; prevents apps from running" [Undecided,New]
<calc> rickspencer3: if you aren't already aware most irc clients do something called tab complete so you don't have to type out the users nick and if you type it correctly it highlights on that users screen so they see you addressed them without having to scan the log
<pitti> calc: oh, so 3.0 uses both saxon and xalan now?
 * directhex gently prods pitti over bug 308619, since it makes f-spot & tomboy unrunnable
<ubottu> Launchpad bug 308619 in gtk-sharp2 "Links against private Mono.Cairo lib; prevents apps from running" [Undecided,New] https://launchpad.net/bugs/308619
<ScottK-desktop> directhex: The mono examples in kde4bindings FTBFS with KDE 4.2 beta 2, so we've had to disable them.  I was wondering if you might be able to have a look and see what the problem is?
<apw> superm1, hey ... does divert the headers have some special meaning?
<directhex> ScottK-desktop, yeah, okay. when i get a sec
<ScottK-desktop> directhex:
<ScottK-desktop> directhex: Thanks.
<superm1> apw, i'm referring to using dpkg-divert in the libdrm-dev package
<superm1> it allows two packages to both ship the same files, but if one package gets installed, it renames the files of the other until the package is removed
<apw> hmmm, /me gets the manual out
<superm1> i'm not sure it's the right solution, but figured it's worth bringing up as an idea
<apw> for sure, as its another magic twist in the debian packaging that i don't know about
<superm1> apw, you can take a look on your current system what packages are already doing this with "dpkg-divert --list"
<apw> diversion of /bin/sh to /bin/sh.distrib by dash ... heh
<calc> pitti: i think it switched to saxonb from xalan
<calc> pitti: looking a bit more to be certain
<calc> pitti: yea in changelog says: remove xalan/xerces conditionals, add saxon ones
<directhex> tiger.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit Mono/.Net assembly
<directhex> okay, i have an example building, now to see about that fail log
<directhex> ScottK-desktop, there IS a log of the fail, right? i don't have to spend another evening watching kde4bindings churn away at an hour per attempt?
<pitti> calc: ah, good to know, thanks
<cjwatson> apw: but make absolutely sure that you really want to do this - it's fiddly especially if you make a mistake
<fabbione> superm1: hi
<superm1> hi fabbione
<fabbione> superm1: do we have a mythtv/ubuntu irc channel to talk?
<superm1> yes
<fabbione> superm1: that being?
<superm1> #ubuntu-mythtv
<fabbione> ok thanks
<apw> cjwatson, diversion looks to be used very rarely.  is it better or worse to rev the kernel twice instead?  risk wise?
<cjwatson> rev twice what for?
<apw> we have a collission between the kernel-libc-dev and libdrm-dev as the latter is carrying some kernel headers.  from what i can see we should be using the kernel ones, but the libdrm-dev ones are modified and so right now we need to use those
<apw> so we are looking for a nice way forward, sorting the problem in the short term, and allowing it to be resolved in the longer term correctly
<pitti> apw: hm, I thought tjaalton wanted to modify libdrm to drop them?
<apw> yes, but they are modified manually from the ones taken from the kernel and so dropping them in favour of the kernel ones is not going to work until we understand why they cannot be used without modification
<cjwatson> is libdrm-dev ultimately going to be dropped entirely, or merely shrunk?
<apw> there were other files in there iirc, at least other headers i believe
<cjwatson> we are effectively dropping the files in the short term anyway ...
<apw> and all this in the face of -alpha2 being imminent
<cjwatson> so I'd have thought the right answer was to remove them physically from libdrm-dev for the moment, file a bug on libdrm targeted at jaunty, and upload linux-libc-dev with Replaces: libdrm-dev (<< first-version-without-those-files)
<apw> but the ones in the kernel may not be compatible with the consumers of the files, if the comments next to the modifications to the copies in libdrm are to believed
<apw> which puts the risk at high in my mind
<apw> especially as the package affected would be the x server (according to the comments)
<cjwatson> so the short-term answer is to use the files in libdrm-dev instead, then?
<apw> i think that is the low risk strategy for the -alpha2 milestone
<cjwatson> I agree; in that case, remove the files from linux-libc-dev and upload libdrm-dev with Replaces: linux-libc-dev (<< first-version-without-those-files)
<apw> it sounded like there is a push with the consumers of these headers to fix the headers in the kernel or the consumer packages to cope, but i don't think its going to be instant
<apw> the bug is also occuring in debian upstream too
<pitti> cjwatson: why a libdrm-upload in this case?
<cjwatson> because it's the right thing to do - otherwise people with the old linux-libc-dev installed might get errors on upgrade
 * calc thinks default-jdk depends on all of main
<calc> hmm actually that is probably an effect of recommends
<pitti> calc: try the -headless versions
<pitti> (someone made a comment in the MIR bug about that)
<calc> ah ok
<calc> hmm no default-jdk-headless but i did make the resulting binary packages depend on the headless bit like stated in doko's email
<calc> default-jdk is the build-dep side of it
<calc> hmm first package seemed relatively easy to convert :)
<lool> superm1: Diverts?  I hate these; what's wrong with pushing a kernel?
<lool> We're going to spend much more human time to write diverts install / removal properly than to disable install of drm headers and reenable it
<superm1> lool, hence i wasn't sure it would be an appropriate solution here as was determined above
<lool> I'm toooo slowwwww
<lool> superm1: Sorry, didn't see the discussion above
<pitti> asac: "shiretoko"? nice :) (just installed firefox-3.1)
<pitti> asac: gave me some weird message about the xulrunner and langpack plugins not being compatible, and fonts are ugly, but otherwise seems to work well
<pitti> asac: it completely ate my bookmarks in the toolbar, is that a known bug or shall I file it?
<mok0> pitti, you have a couple of minutes?
<pitti> mok0: (on phone, just ask, I'll respond later)
<mok0> pitti: I am looking at lxml under jaunty. It FTBFS on all platforms. I now tried building it in my Lenny and Sid sbuilders. It also FTBFS'es in Sid, but not in Lenny. I think it has something to do with cython, which is version 0,10.2 in Sid (and jaunty) but 0.9.8 in Lenny
<pitti> hm, I wonder why it didn't get autosynced
<mok0> 308633bug 2
<mok0> bug 308633
<ubottu> Launchpad bug 308633 in lxml "[jaunty] lxml FTBFS on all platforms" [Undecided,New] https://launchpad.net/bugs/308633
<mok0> pitti: what didn't
<pitti>     cython |   0.10.2-1 |        jaunty | source, amd64, i386
<pitti> it was
<pitti> oh, nevermind, you meant that the *new* version has the problem
<mok0> pitti: yes
<mok0> pitti: I am not aware of other packages that use cython
<mok0> pitti: anyway, this is an error that seems to come via distutils
<asac> pitti: hmm ... bookmarks issue is definitly unknown ... can you backup your .mozilla/firefox-3.1 directory, remove it and start again? (it will re-copy it, so we see if it reproducible)
<asac> pitti: langpacks and plugins are mostly incompatible ... yes.
<asac> pitti: talk to fta about fonts are ugly ... he investigated that quite in depth, but he didnt get all answers about why we ship some of the fontconfig files
<pitti> asac: yes, we discussed the font bug at UDS
<asac> ah
<asac> so now you see it ;)
<rickspencer3> let's try this again
<rickspencer3> beuno: I hear you're the person who can give me access to the fridge
<pitti> asac: bug 308666
<ubottu> Launchpad bug 308666 in firefox-3.1 "does not show my bookmarks in toolbar any more" [Undecided,New] https://launchpad.net/bugs/308666
<pitti> asac: is there a particular file in the 3.0 profile which has the UI layout? I don't want to attach the entire dir, it has my keyring and cookies, etc.
<asac> pitti: there are two files that could cause the problem: 1. localstore.rdf (removing that should after stopping should fix)
<pitti> asac: yes, reproducible that way
<asac> pitti: but most likely its places.sqlited
<beuno> rickspencer3, I may be able to, yes. What's your Launchpad username?  is this to add events?
<asac> pitti: huh?
<asac> so removing localstore.rdf cures you?
<pitti> asac: reproducible> you asked for removing .mozilla/firefox-3.1 and trying again
<asac> pitti: ah ;) ... right. now try to remove localstore.rdf from within firefo*3.1/*/
<asac> (sorry for the shorthand)
<mok0> pitti: lxml FTBFS: it happens when building the -dbg version
<mok0> pitti: If I comment that out, the package builds
<pitti> asac: yes, that kills my toolbar customizations and restores the standard layout
<pitti> asac: I try it the other way around now
<asac> pitti: oh. so localstore.rdf it is?
<asac> pitti: you can copy the firefox-3.0 one in again
<asac> (guess thats what you mean by "the other way")
<pitti> asac: bug updated with my localstore.rdf and recipe
<asac> pitti: restarting ffox doesnt cure alone right?
<kees> pitti: can you give me a crash-course in MIR-handling?
<pitti> asac: right
<pitti> kees: later, I'm afraid, need to ru
<pitti> n
<slangasek> directhex: gtk-sharp2 - I can have a look, but should the pkgconfig for cairo not be fixed, too?
<kees> pitti: okay
<pitti> my wife's bday dinner
<asac> pitti: ok so localstore.rdf doesnt modify ... is adblock plus disabled?
<directhex> slangasek, long term, yes - as soon as apps are done in debian
<slangasek> ok
<pitti> asac: I have adblock plus in my local profile, but not in the guest one
<pitti> asac: as I said, standalone isloated reproduction recipe in bug (sorry, need to run now)
<asac> pitti: well ... i see adblock plus in localstore
<asac> but i will try
<mok0> pitti: I think this is an error in the python package
<slangasek> directhex: uploaded, thanks
<slangasek> directhex: oh, the changelog was missing a bug reference though; guess I'll close that by hand
<slangasek> directhex: bah, mono-addins has 'mcs' embedded in all of its Makefile.am, despite having an autoconf check for mcs
<slangasek> directhex: even ndesk-dbus and ndesk-dbus-glib shouldn't have package renames for the transition?  The current binary names are libndesk-dbus1.0-cil and libndesk-dbus-glib1.0-cil ...
<kirkland> slangasek: cjwatson: any chance you (or someone) can respin the server/alternate iso's with the -3 kernel?
<slangasek> er, not so long as there's not a full set of packages available for -3
<calc> garrr
<calc> evolution is fubar'd
<calc> it won't let me reassign the draft/sent folder for one of my accounts
<ion_> More like snafu
<mbiebl_> pitti: hi
<mbiebl_> have you seen, that the pkg-utopia exp branch has packages for DK et al?
<mbiebl_> They are not updated yet to the latest version, as Debian doesn't have a recent enough udev.
<mbiebl_> But you can take them as a base, might save you some work
<cjwatson> bryce: would you mind applying my patch in bug 308649 if it makes sense to you? it broke my preferred terminal emulator configuration ...
<ubottu> Launchpad bug 308649 in xorg-server "server-side font support broken in 2:1.5.99.3-0ubuntu2" [High,Triaged] https://launchpad.net/bugs/308649
<bryce> cjwatson: yep; in fact it's already committed to git
<cjwatson> oh, great, thanks
<cjwatson> ah yes, helps if I reload the bug ;-)
<bryce> timo's working on the new xserver 1.6 stuff and will include it next time he does an upload
<calc> how is bug 303528 'fix committed' when it is only fixed upstream and not in ubuntu or bzr repo for ubuntu, etc?
<ubottu> Launchpad bug 303528 in evolution "Message Filters targeting IMAP folders point to local@local" [Medium,Fix committed] https://launchpad.net/bugs/303528
 * calc added intrepid to the bug just now
<slangasek> calc: sounds like an incorrect use of that state to me, yeah
<kirkland> slangasek: which kernel, then, is targeted for the alpha2 iso's?
<slangasek> well, it would be nice to have -3, but that requires a linux-meta upload to happen
<LaserJock> calc: I think that's how the gnome packagers often use "Fix Committed"
<LaserJock> i.e. if it's "Fix Released" in an upstream task it's "Fix Committed" in the Ubuntu task
* tkamppeter changed the topic of #ubuntu-devel to: UDS: done, Archive: open, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<bryce> slangasek: is alpha-2 still on schedule for being released late this week?  I want to give nVidia and AMD head's up when the ISO's will be available for their testing
<slangasek> bryce: yes; just about to get the freeze mail sent out
 * NCommander grumbles
<NCommander> so much for KDE on arm for alpha 2
<slangasek> well currently, kubuntu isn't installable on any archs, so feel free to fix that. :)
<NCommander> Why isn't it installable?
<slangasek> something with plasma?
<NCommander> oh that one
<NCommander> I thought that was fixed
<tjaalton> slangasek: what about the drm headers mess?
<slangasek> tjaalton: I appear to not be in the loop on this - what's going on?
<tjaalton> slangasek: ok, so linux-libc-dev now includes the drm headers which libdrm-dev used to have
<calc> LaserJock: ah ok
<tjaalton> the problem is that the drivers don't build against the kernel headers just yet, so dropping them from libdrm-dev right now isn't going to work
<tjaalton> "drivers" are in this case at least ati and intel
<tjaalton> intel being the hard one to fix, while ati is trivial and fixed upstream
<slangasek> tjaalton: but l-l-d Replaces: libdrm-dev and clobbers the headers needed by the drivers?
<tjaalton> slangasek: better just drop the headers from l-l-d for now
<slangasek> I'm asking whether that's the current situation
<tjaalton> oh, it doesn't replace, it conflicts on install, meaning that xorg-server is waiting for that to be fixed
<cjwatson> slangasek: discussion between 16:12 and 16:20 UTC on this channel today is relevant
<tjaalton> and a thread on ubuntu-kernel@
<jack_> how do you build a (realtime) kernel for Ubuntu, which can be used by as much as people as possible (like the official Ubuntu kernel). Do you use chroot for it?
<slangasek> right
<tjaalton> the post-alpha2 plan is to use the headers from l-l-d, but this is maybe a bit too early
<directhex> jack_, kernels with -rt at the end?
<slangasek> tjaalton: so cjwatson seems to have already suggested the same thing I was going to, which was to keep the headers in libdrm-dev for alpha-2, and upload that package with a Replaces: l-l-d?
<jack_> directhex, for example
<jack_> directhex, rt = realtime yes
<tjaalton> slangasek: although, we might not care about the drivers for alpha2 and drop the headers from libdrm-dev, and fix the drivers after alpha2
<directhex> jack_, install linux-rt
<slangasek> tjaalton: is there a bug open about this, btw?  Because it should be targeted to the release and have the alpha-2 milestone set :)
<jack_> directhex, that was not the question ;)
<tjaalton> slangasek: ah, that's indeed quicker to build than the kernel :)
 * calc is converting java... one package at a time, heh
<directhex> silly java
<tjaalton> slangasek: *cough* yes, it's bug 308387
<ubottu> Launchpad bug 308387 in linux "[Jaunty] trying to overwrite `/usr/include/drm/drm_sarea.h', which is also in package libdrm-dev" [Undecided,In progress] https://launchpad.net/bugs/308387
<slangasek> tjaalton: thanks, on my list now
<tjaalton> slangasek: so you suggest adding Replaces to libdrm-dev?
<slangasek> tjaalton: versioned replaces: only, yes, so that we have a way to get the l-l-d version of the headers back onto users' systems after alpha-2
<slangasek> tjaalton: dumped some comments to the bug.
<kirkland> slangasek: btw ... did you see the output of Friday night's conversation?  http://blog.dustinkirkland.com/2008/12/ubuntu-server-includes-window-manager.html
<slangasek> kirkland: yes - though I'm pretty sure my contributions to the conversation were in fact negligible :-)
<kirkland> slangasek: well, you didn't can the idea ... that's something :-)
<tjaalton> slangasek: righto, http://users.tkk.fi/~tjaalton/dpkg/drm.diff
<Combatwombat_nz> can somebody tell me where to find info on compiling an app specifically for Ubuntu, making use of crontab?
<yao_ziyuan> i find Nodoka gtk2 style + X-Colors metacity style a good combination
<yao_ziyuan> if ubuntu uses this combination by default, would it infringe red hat's rights?
<Baby> just out of curiosity, what are the requirements for becoming a Ubuntu developer?
<cjwatson> Baby: https://wiki.ubuntu.com/UbuntuDevelopers
<Baby> thanks
<CarlFK> cjwatson: you back from holiday?
<cjwatson> CarlFK: aye
<CarlFK> welcome back
<slangasek> tjaalton: looks reasonable to me; will you upload?
<tjaalton> slangasek: yep
<tjaalton> thanks
<slangasek> cool
<slangasek> tjaalton: will that take care of the xserver-xorg-core/xserver-xorg-input-2.1 issue once it's fixed, or does that require some other upload?
<tjaalton> slangasek: vmmouse needs some love :/
<slangasek> what kind of love?  is there a bug open? :-)
<tjaalton> of course not, that would be totally reasonable ;)
<tjaalton> it fails to build, and just including xf86OSmouse.h (like -mouse does) isn't quite enough
<slangasek> ok, I'll have a poke at it
<tjaalton> copy the header from -mouse to vmmouse/src
<slangasek> tjaalton: are changes to these packages expected to be committed to git somewhere? the vcs-* headers still refer to the XSF git repo
<tjaalton> slangasek: yes, these should be synced once 1.6 is in experimental/unstable and the drivers fixed there too.. most of the fixes were oneliners
<tjaalton> (removing #include xf86Version.h)
<tjaalton> slangasek: what I meant was that the changes to these packages were from upstream, and will be included once the versions are bumped for xserver 1.6 (and pushed to unstable/experimental)
<slangasek> tjaalton: ok, but does that mean there's a repo/branch that corresponds to the packages you upload to Ubuntu?  or do you just feed the patches back to Debian?
<tjaalton> slangasek: there's no branch for the ad-hoc updates I did to get them build, no. I'll feed debian git once alpha2 is out
<slangasek> ok
<tjaalton> just asked upstream, there will be new driver releases to sort this out
<Caesar> I'm surprised to discover that udev seems to start the network
<tjaalton> slangasek: the vmmouse build failure should be a packaging problem, since it build fine using just configure & make
<slangasek> udev starts the WORLD
<slangasek> <ahem>
<Caesar> So what's the point of S40networking?
<Caesar> Supposedly the network is going to be up by the end of S10udev
<Caesar> Except when DHCP decides to take its time
<slangasek> tjaalton: hrm, that's with the current version of the package in jaunty?
<Caesar> (we're trying to debug a fun situation where syslog-ng sometimes fails to start because the network isn't up yet at runlevel 2 S10syslog-ng)
<slangasek> Caesar: udev actually only starts the networking if allow-hotplug is set (IIRC), and even then it's asynchronous as you note
<Caesar> slangasek: hmm
<slangasek> S40networking is the "old" way, but it's still the only one that presents a synchronization barrier, AFAIK
<tjaalton> slangasek: no, it fails, but the latest upstream release builds
<slangasek> tjaalton: ok; I would rather leave pulling a new upstream version to you, then
<slangasek> (or to some other X-er with time for it)
<Caesar> slangasek: udev is calling ifup --allow auto $INTERFACE
<Caesar> So that's going to include an auto eth0 that uses DHCP is it not?
<slangasek> then udev is more clever than when I last looked
<Caesar> This isn't seeming all that clever...
<Caesar> This is going to cause DHCP to start before /var is mounted, by the looks of it
<slangasek> heh
<slangasek> file a bug on Keybuk then? :)
<Caesar> I might shoot him an email to make sure my reasoning is correct
<slangasek> oh, don't we do a bind-mount-shuffle for /var/run?
<slangasek> so that it's always available early
<Caesar> What about /var/lib?
<slangasek> does dhcp need that?
<Caesar> You know, where the lease file is...
<Caesar> kinda important...
<slangasek> yeah, that can't be mounted early
<Caesar> I fear I'm discovering a shambles
<slangasek> Caesar: so, how would a system with /var on NFS, + DHCP, work?
<slangasek> (in theory)
<imachine> tseliot, hey
<imachine> tseliot, I've installed the updates from -proposed, everything works great now!
<imachine> tseliot, all the driver building etc, 173 or 177, I just choose them from the proprietary driver manager in gtk2, and it "just works". testing for 96 now, since both 173 and 177 have the glitch with window titlebar artifacts over here :-)
<tjaalton> slangasek: I'd say we should drop vmmouse from -input-all for now, since it _doesn't_ build without the extra header, and likely wouldn't work anyway since those functions are gone from the server (I had the header still in the tarball root, that's why it built)
<slangasek> tjaalton: fine by me
<slangasek> will you upload, or are you asking me to?
<tjaalton> slangasek: no, just checking it's on. doing it now
<tjaalton> s/on/ok/
<slangasek> cool
<slangasek> so in the end, was a solution found for gnome help stuff + langpacks for jaunty?
<LaserJock> slangasek: what was the problem?
<slangasek> LaserJock: we currently don't split translations of gnome help stuff off into langpacks, so it contributes to core package size on the CDs
<slangasek> I think this was on the UDS agenda, but in desktop land which was far away from me :)
<LaserJock> slangasek: by gnome help stuff do you mean system documentation?
<slangasek> yes
<stgraber> slangasek: are the current ISO images supposed to be installable ? report.html doesn't say anything
<slangasek> stgraber: that's interesting; ubuntu-desktop is uninstallable, so I guess report.html is buggy
<slangasek> (file-roller had a dep on packages in universe, I've just fixed this so in theory the next builds will be installable)
<stgraber> yeah, that's what I thought. I remember seeing some p7zip errors during the few tests I did today
 * slangasek nods
<slangasek> X stuff is broken too, tjaalton is working on that part
<ScottK> slangasek: I've got a couple of binary promotions that need doing to fix unistallables for the alpha.  Do you want bugs or can I just ask ....
<slangasek> ScottK: just ask
<LaserJock> hmm, using Rosetta to translate the gnome help files is probably not a great idea right now, but I guess extraction into lang packs should be workable
<ScottK> slangasek: libkrosspython0 libsmokekde4-2 are needed for kde4bindings to sort out.  Source is already in Main.
<slangasek> LaserJock: I'd recommend tracking down the UDS spec and reviewing it, rather than re-deriving from first principles. :)
<LaserJock> slangasek: I did read it
<hyperair> sru anyone? bug 202089
<ubottu> Launchpad bug 202089 in pulseaudio "Pulseaudio is blocking normal sound after resume" [Undecided,Confirmed] https://launchpad.net/bugs/202089
<LaserJock> slangasek: and it looks to be in fairly early stages: https://wiki.ubuntu.com/DesktopTeam/Specs/JauntyGnomeHelpLangpacks
<slangasek> ScottK: promoted
<slangasek> LaserJock: ah, well, doh.  And it doesn't link to a blueprint page?
<LaserJock> slangasek: no, but I got there from the blueprint
<ScottK> slangasek: Thanks.
<slangasek> LaserJock: right, perhaps you could check with ArneGoetje and/or pitti regarding its status
<slangasek> as I said, I'm pretty sure this was a session at UDS, so the "drafting" status probably means there's more detail to come
<LaserJock> slangasek: right, sure
<LaserJock> I guess it should make a dent in CD size, though it'll probably make the langpacks even heftier to get
<LaserJock> i.e. having to download the entire langpack just to look at a single help file in a native language
<LaserJock> that may be a fairly corner case though, I guess if you want a language you probably want it all
<imachine> tseliot, https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/278472 <- I've commented adequately here.
<ubottu> Launchpad bug 278472 in nvidia-graphics-drivers-173 "can't load nvidia-173 driver" [Undecided,Invalid]
<slangasek> LaserJock: yes, I certainly think it's consistent with the other langpack handling we do
<imachine> tseliot, I don't think there's any reason to file a new bug report, as a similar has already been filed (even tho it's not the same issue I had, the error message is the same).
<imachine> tseliot, I'll file a new one about nv and resume/suspend (if there isn't one there yet, ofcourse:))
<imachine> tseliot, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-driver-nv/+bug/128413
<ubottu> Launchpad bug 128413 in xserver-xorg-video-nv "nv free driver no display on return from suspend to ram" [Wishlist,Confirmed]
<imachine> tseliot, here's another bug, about the suspend to ram broken on nv. it seems it's quite old :-) fist discovered under .22
<ScottK> slangasek: Binary promotions for bomber kapman killbots should get kdegames sorted.
<stgraber> slangasek: ok, so there are actually 3 unmet dependencies: file-roller (depends on p7zip), update-manager (depends on update-manager-core=1:0.95.1, instead of 0.95.2) and xserver-xorg-core (conflicts with xserver-xorg-input-2.1)
<ScottK> IIRC p7zip needs promotion too.
<stgraber> yeah, that's for the file-roller one, it depends on p7zip which is in universe
<ScottK> The libkrosspython0 promotion you already did will sort out kdesdk too.
<ScottK> slangasek: kdeedu-kvtml-data needs binary promotion to fix kdeedu.
#ubuntu-devel 2008-12-17
<Caesar> slangasek: good question
<Caesar> I suspect badly
<Keybuk> Caesar: ifupdown calls dhclient with -pf /var/run/... -lf /var/run/...
<Keybuk>    [[ifconfig %iface% hw %hwaddress%]]
<Keybuk>     dhclient3 [[-e IF_METRIC=%metric%]] -pf /var/run/dhclient.%iface%.pid -lf /var/lib/dhcp3/dhclient.%iface%.leases %iface% \
<Keybuk> oh, no, the latter is /var/lib
<Keybuk> ifupdown (0.6.7ubuntu2) dapper; urgency=low
<Keybuk>   * Change the dhclient3 leases path to /var/lib/dhcp3 so the leases survive
<Keybuk>     a reboot.  (Ubuntu: #18148)
<Keybuk>  -- Scott James Remnant <scott@ubuntu.com>  Wed, 23 Nov 2005 16:11:30 +0000
<Keybuk> #
<Keybuk> amusing
<Keybuk> looks like there's a bug there
<Keybuk> NM uses /var/run anyway
<Keybuk> so the two are out of sync
<Caesar> Keybuk: that issue is an aside
<Caesar> I'm more interested in the network being unconfigured when the machine switches to runlevel 2
<Keybuk> does dhclient really fail if it can't write the lease file?
<Caesar> The /var/lib, /var/run thing just got noticed in the process
<Caesar> Keybuk: I haven't checked the failure behaviour yet
<Keybuk> seems odd that it would do so, since it would try and write the lease file *after* setting the interface up
<Caesar> Here, we have /var on the root filesystem so it's not an issue for us
<Keybuk> we've had occasional bugs about the network being unconfigured throughout ubuntu's life
<Keybuk> never tracked them down, because the people who can replicate it disappear
<Caesar> But is my understanding correct? The system can exit single-user mode with the network still in a semi-configured state?
<Keybuk> right
<Caesar> That's... apalling
<Caesar> I'm going to assume yanking the udev rules will return normalcy
<Keybuk> there's a bug that we even have networking while in single-user mode
<Keybuk> is that what you mean?
<Caesar> Debian's single user mode is rather ridiculous
<Keybuk> right, if you comment out the ifup rule then it'll bring networking up as before
<Caesar> I think we'll do that
<Keybuk> which will obviously block on dhcp in the boot process
<Keybuk> but you probably want that for network-depending hosts
<Caesar> Which would be most of them
<Keybuk> at Google, sure
<Caesar> I can't see how we're that exceptional in this regard
<Keybuk> our default desktop install is quite the opposite, networking is generally brought up after login
<Keybuk> and blocking the boot for 60s just because theres no network cable plugged in to your laptop is pessimal
<Caesar> Yeah, that's the downside
<Caesar> But we're not using NetworkManager
<Caesar> Especially not on servers
<Caesar> (or workstations for that matter)
<Keybuk> why does it fail your boot though?  what are you using networking for during boot?
<Keybuk> oh, syslog
<Caesar> Yes
<Keybuk> so syslog's nslookup fails?
<Caesar> Yes
<Caesar> This use case is fairly typical I'd have thought
<Caesar> There's going to be all sorts of network-dependent things going on in runlevel 2
<Keybuk> dunno, you're the first person in ~3 yeras to notice <g>
<Keybuk> technically nothing in runlevel 2 should be network dependant
<Keybuk> since you might not have a network
<Caesar> Oh come on
<Caesar> So where's your webserver supposed to go?
<Keybuk> web servers aren't generally configured by hostname?
<Keybuk> apache's conf uses ips
<Caesar> They could have config that requires a DNS lookup
<Caesar> You can't tell me that nothing that starts at boot shouldn't have a DNS dependency
<Keybuk> well, nothing in the default install
<Keybuk> otherwise the boot will fail every time, since you won't have DNS until the user logs in :)
<Caesar> Think servers for a moment
<Keybuk> bear in mind that there's other things that lockstep the networking
<Keybuk> we call ifup -a in rcS
<Keybuk> that locks out if another ifup is still running
<Caesar> Hmm
<Caesar> So we have an ifup that runs at S10
<Keybuk> so if your network card is plugged in, detected and firmware uploaded before that point - you're fine
<Caesar> It's unclear if that continues running, or fires off dhclient and returns fairly quickly
<Keybuk> it continues running until after dhclient finishes
<Caesar> ok
<Keybuk> (since it does the if-up.d stuff afterwards)
<Caesar> Of course
<Keybuk> I last looked at this stuff for dapper, so it's possible that someone's broken it
<Keybuk> but a quick glance says it's ok
<Caesar> We've seen the second ifup -a in S40networking not configure eth0 because /var/run/network/ifstate claimed it already was configured
<Keybuk> sure
<Keybuk> you get that with a dhclient timeout
<Keybuk> ifup can't tell the dhcp failed
<Keybuk> or the wpa failed
<Keybuk> etc.
<Keybuk> it's a general design bug
<Keybuk> ifstate only really records "someone tried to bring it up"
<Caesar> Yeah
<Keybuk> I have seen reports where dhcp fails during boot for no explicable reason
<Caesar> If only we had dhclient output from the udev invocation
<Keybuk> the logs show it apparently trying to discover an ip
<Keybuk> and if you do it later, it works
<Keybuk> I usually suggest init=/bin/bash, start syslog, then exec /sbin/init
<Keybuk> (with syslog dumping to a file in /dev)
<Caesar> Hmm, that's a new one
<Caesar> We can try that
<Caesar> Poor man's boot logging eh?
<Keybuk> indeed
 * Keybuk is a very poor man :p
<Caesar> If only upstart did it ;-)
<Keybuk> one day
<Keybuk> it really is on my todo list
<Keybuk> and I'm making forward progress through that again now :p
<Caesar> Cool
<Keybuk> so, from the sound of it:
<Keybuk> ifup eth0 has run because
<Keybuk>  - ifstate says it's up
<Keybuk>  - ifup -a in S40networking doesn't block
<Keybuk> if ifup hadn't run, ifstate wouldn't say it had, so S40networking would bring it up
<Keybuk> if ifup was still running, it would hold a lock, so ifup -a would be locked out
<Caesar> So it'd be nice to know wtf dhclient has done by the time S40networking has completed, one way or the other
<Keybuk> also see whether commenting out the udev rule helps or not
<Keybuk> if it does, it implies there's something amiss with when dhcp is running
<Keybuk> but I can't think what that might be
 * Keybuk heads for bed (which is where I was on my way to :p)
<Caesar> Okay, I'll try and let you know
<Caesar> Goodnight!
<ScottK> slangasek: if something's wanting to get promoted to Main only because it's an alternate depends (and not even the first one listed) and we don't otherwise want it in Main, is adding it to extra-excludes in the appropriate see the correct solution?
<bbs> hey, i'm writing an initscript for a program that my company is writing ... we are going to package it very nicely for ubuntu because i said you guys are where a lot of heat is at right now -- personally i use source based distros (how silly of me i know :) ) -- but i was wondering where a good guide for writing initialization scripts (upstart -- not exactly sure how your system works) -- so that i can properly instantiate things that are required for a p
<bbs> any links?
<bbs> or documentation?
<sommer> bbs: you might try: http://upstart.ubuntu.com/getting-started.html
<bbs> does that go over discussion of creating pid files?
<bbs> sommer: i'm looking to really support ubuntu the best most likely
<slangasek> ScottK: bomber kapman killbots promoted, thanks
<slangasek> stgraber: the update-manager one sounds transient; the file-roller one is resolved for the next run; and the xserver one is in tjaalton's hands
<ScottK> slangasek: Great.  Thanks.  A little furhter along you'll run into a request for kdeedu-kvtml-data to get promoted to fix kdeedu.
<slangasek> ScottK: yep, was just about to do that one now :)
<ScottK> slangasek: Great.
 * ScottK will wait for you to get to his seeds question in due course then.
<slangasek> Keybuk: er, Caesar is most certainly not "the first person in three years" to notice network-dependent stuff going on in runlevel 2
<slangasek> I've just been holding my tongue and praying we can migrate to upstart soon
<slangasek> s/upstart/& jobs/
<slangasek> Keybuk: also, your definition of runlevel 2 is de facto wrong for Debian, so yeah.
<Chipzz> slangasek: I've alwyas wondered why the usage of runlevels differed in debian anyway
<slangasek> because they differ everywhere, because they're not a standard?
<Chipzz> let me put it otherwise: why they differed fmor the de facto standard, being redhat
<Chipzz> (de facto standard: 3 -> text; 5 -> graphical login)
<StevenK> And why is RedHat is the de facto standard?
<slangasek> ScottK: extra-excludes> hmm, I would've expected germinate to be smart enough to sort that out on its own?
<slangasek> or maybe not
<ScottK> slangasek: The package in question is kdesvn.
<Chipzz> because the way redhat did it, like it or not, is how most other distro's did it. and the fact that redhat has long been one of the most popular distro's
<ScottK> It's listed on component mismatches and as nearly as I can determine only becuase one of it's binary packages is an alternate depends for kdesdk.
 * slangasek throws bits of rpm at Chipzz ;P
<Chipzz> to my knowledge, but I may be mistaken on that, debian and ubuntu are the only significant distro's that have 2 as the equivalent runlevel of what redhat et use for 3
<Chipzz> (well, given the different way a grpahical login is started that's not 100% true either, but...)
<Chipzz> s
 * Chipzz chews on them and burps ;P
<Chipzz> (slangasek: as an aside: I have done lots of rpm packaging in a different life ;))
 * ScottK will go out on a limb and guess the other Debian derivatives do it similarly.
<slangasek> I have, too; you'll note what I do now instead
<StevenK> Hah
<Chipzz> ScottK: yeah, but can you call those debian derivatives significant? :P
<pwnguin> what about the embedded debian derivatives?
<Chipzz> pwnguin: isn't emdebian (or whatever it's called) a subproject of debian?
<pwnguin> Chipzz: there's others
<Chipzz> afaik it's maintained by a debian maintainer
<pwnguin> angstrom
<pwnguin> openembedded
<slangasek> ScottK: yeah, I guess excluding that package is the only way to clear it out of the mismatches, doh
<slangasek> Chipzz: it's maintained by a Debian developer; that doesn't mean it's a subproject of Debian, it's not really hosted using Debian resources...
<ScottK> slangasek: If you're still around ... Need binary promotion for kpartloader to fix kdesdk installability.
<slangasek> done
<ScottK> slangasek: Thanks.
* slangasek changed the topic of #ubuntu-devel to: UDS: done, Archive: frozen for alpha-2, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ScottK> slangasek: I think python-plasma is the last binary promotion Kubuntu CD/DvD are needing.
<ScottK> Nope.  I'm wrong.
<ScottK> slangasek: Need libkdcraw7 libkdcraw7-dev libkexiv2-7 libkexiv2-7-dev too.
<NCommander> oooh
<NCommander> I think ...
<NCommander> I think PyKDE4 built ...
<NCommander> ahaha
<NCommander> AWESOME
<NCommander> It builds!
<ScottK> Congratulations.
<NCommander> I just need to make cmake work properly now
<NCommander> and we're fully in business
<pitti> Good morning
<NCommander> hey Pici
<NCommander> *pitti
<pitti> hey NCommander
<NCommander> I just about got kde4bindings building on arm
<NCommander> wooo
<StevenK> Morning pitti
<pitti> slangasek, LaserJock: we currently don't have a vehicle for moving the GNOME help files from packages to langpacks, UDS discussion was insufficient; I plan to continue it with the soyuz team via email
<StevenK> pitti: It's only 6:50am! \o/
<ScottK> Good monring pitti.
<ScottK> morning even.
<pitti> StevenK: hey, at least I slept through until the alarm went off at 6 (my wife has to get up at that time)
<StevenK> pitti: Woot! Progress!
<ScottK> pitti: Would you be up for some binary promotions?  slangasek seems to have dropped off.
<ScottK> python-plasma libkdcraw7 libkdcraw7-dev libkexiv2-7 libkexiv2-7-dev are the remaining ones needed to get KDE installable for the Alpha milestone.
 * ScottK also casually mentions that there are two MIR waiting for ubuntu-mir needed to get lintian installable again ...
 * StevenK NBS's out libboost1.36, half tempted to NEW it, just so he can remove it again
 * ScottK notes the time in his TZ and decides to go to bed.
<ScottK> Good night all.
<pitti> ScottK: good night!
<mahesh> i compiled a fresh kernel and then now want to add features like.... automounting the any scsi devices..... i need help.....!
<LaserJock> pitti: so the plan would be to have binarymangler pull out all the C/ .xml files and put them on LP somewhere and then put them in the langpacks?
<pitti> LaserJock: well, everything *except* C, but yes
<LaserJock> oh, sorry
<StevenK> -- Found FFMPEG INCLUDES: LIBFFMPEG_INCLUDE_DIR-NOTFOUND
<StevenK> kdenlive, you fail
<LaserJock> pitti: but the plan isn't to be translating though? my experience of xml2po, etc. are that I wouldn't rely on them for complete automation
<ScottK> StevenK: Which version are you looking at?
<StevenK> ScottK: 0.5.svn20071228-0.0ubuntu3
<ScottK> There's a 0.7 that someone is working on packaging.
<StevenK> Then I'll stop caring, since I'm only caring for NBS
<ebroder> Any bored backporters I could get to ACK on LP #301283, LP #305001, or LP #308800?
<ubottu> Launchpad bug 301283 in intrepid-backports "Please backport schroot 1.2.1-1ubuntu1 from Jaunty to Hardy" [Undecided,New] https://launchpad.net/bugs/301283
<ubottu> Launchpad bug 305001 in hardy-backports "Please backport sqlalchemy 0.4.8 from Jaunty to Hardy" [Undecided,New] https://launchpad.net/bugs/305001
<ubottu> Launchpad bug 308800 in intrepid-backports "Please backport remctl 2.13-2 from Jaunty to Hardy and Intrepid" [Undecided,New] https://launchpad.net/bugs/308800
<StevenK> ScottK: Apparently, you were sleeping
<ScottK> Not quite yet.  I'm slow.
<mahesh> i compiled a fresh kernel and then now want to add features like.... automounting the any scsi devices..... i need help.....!
<ScottK> ebroder: Did anyone answer the rdepends testing question on sqlalchemy?
<ebroder> ScottK: I...didn't know there was an rdepends testing question
<ebroder> ScottK: Give me a second to look at what the rdepends are
<ScottK> ebroder: In the bug now.
<ebroder> ScottK: Would you consider it sufficient to just test against the versions in Hardy?
<calc> pitti: got them uploaded :)
<ScottK> ebroder: yes.  If those work, it's great.  If they don't, they need to be backported too.
<pitti> calc: \o/
<mahesh> i compiled a fresh kernel and then now want to add features like.... automounting the any scsi devices..... i need help.....!
<calc> pitti: also stripped out ubuntu specific bits and created debdiffs and filed the patches in debian bts :) heh
<ScottK> mahesh: This isn't a help channel.  Asking the same question every 10 minutes doesn't change that.  Ask in #ubuntu.
<pitti> calc: appreciated, so let's hope we can sync them again soon
<calc> of course as debian is in freeze it may take them a while to upload with the patches
<mahesh> ScottK>> i thought some one would help.... #ubuntu is for end-user support
<calc> hmm my xom build failed on the buildd, worked fine on my local box
 * calc is going to upgrade his chroot and verify it still works locally
<calc> oh this failure is ugly it worked in my non-clean chroot
<calc> when i cleaned it and rebuilt it fails :\
<calc> so apparently it needs something else
<calc>     [javac] The system is out of resources.
<calc>     [javac] Consult the following stack trace for details.
<calc>     [javac] java.lang.StackOverflowError
<calc> lovely
<StevenK> calc: More RAM? :-P
<calc> heh
<calc> not likely the problem
<calc> i just wish i knew what i had installed previously that allowed it to build ok
<calc> hehe
<calc> i found it but i don't know why it helps
<calc> default-jdk-builddep works just default-jdk by itself does not
 * calc uploaded fixed version
<calc> pitti: can you process the rest of the packages once they hit the archive in an hour or so? :)
<pitti> calc: right, -builddep is for building, default-jdk-headless is for binary dependencies
<pitti> calc: I'll try (however, note that I'll block at least one pacakge, since we are in alpha-2 freeze)
<calc> pitti: well default-jdk vs default-jdk-builddep (builddep was supposed to only be needed when building gcj packages)
<calc> pitti: ok
<pitti> oh?
<pitti> calc: anyway, are you using -headless? for most libraries that should suffice
<calc> yes for the runtime dep
<calc> " - build dependencies: If a source package builds a "-gcj" package, don't
<calc>    stop building it yet. This will slow down the gij runtime. Instead,
<calc>    use "default-jdk-builddep", which depends on the default jdk and
<calc>    java-gcj-compat-dev. If no "-gcj" package is built, use default-jdk
<calc>    as a build dependency."
<pitti> hm, ok
<calc> that was from doko's email, sorry for the crummy line-breaks
 * calc headed to bed now, bbl
<pitti> calc: sleep well!
<dholbach> good morning
<LaserJock> morning dholbach
<dholbach> hi LaserJock
<highvoltage> morning LaserJock and dholbach
<dholbach> hi highvoltage
 * LaserJock waves to highvoltage 
<highvoltage> LaserJock: did you get a chance to go by to the UDS?
<LaserJock> highvoltage: no, just did some remote stuff
<pitti> stgraber: yay MOTU! congratulations!
<pitti> hi tkamppeter
<LeviTheSmith2> THANK YOU!
<LeviTheSmith2> I'll just copy and paste what I wrote in the other channel
<LeviTheSmith2> My old laptop I got didn't work well with Windows(function keys/quick keys didnt work), Fedora(same as windows, plus wireless and audio didnt work), Solaris(same as fedora). Ubuntu: Audio worked after the first boot - no need to install drivers. Function keys work - i can turn the volume done now!. Wireless worked out of the box too! :D
<LeviTheSmith2> s/done/down
<LeviTheSmith2> If anyone's wondering, the model is Asus A2H 2.66ghz
<tkamppeter> pitti, hi
<lool> pitti: I didn't get very clear feedback on libv4l versions fixing what or breaking what (didn't get any regression report so far I think), and I was tempted to stop with the 0.5.6 SRU, but the last comment on LP #286070 encourages me to look at SRU-ing 0.5.7; the diff is minimal and fixes a missing argument in a syscall
<ubottu> Launchpad bug 286070 in libv4l "SRU for libv4l 0.5.1" [Undecided,Fix released] https://launchpad.net/bugs/286070
<lool> pitti: What do you think of http://people.ubuntu.com/~lool/libv4l-0.5.7.diff ?
<lool> It a) adds debug code b) handles more error cases nicely c) fixes the number of args to SYS_mmap2
<NCommander> hey lool
<lool> hey NCommander, how is it going?
<NCommander> lool, finally fixed kde4bindings on ARM
<NCommander> It was a combination of five bugs that had to be fixed to get it going
<lool> NCommander: I read yesterday that you found a broken configure check
<NCommander> yeah
<NCommander> About the only thing that WASN'T broken was sip -_-;
<NCommander> go figure
<lool> NCommander: When do you plan to upload this?  I'm happy to sponsor ASAP to get more armel stuff building
<NCommander> We're in freeze
<NCommander> So Friday assuming alpha 2 releases on time
<lool> You've got sponsoring in place for this?
<NCommander> (all the patches are on launchpad and/or in the appropriate bazaar branches)
<NCommander> ScottK, apachelogger or Riddell will do it
 * NCommander is using the opportunity to rebuild all the KDE packages again from scratch just to make sure there are no overlooked OOPS
<lool> Cool
<NCommander> I'm also sending the necessary patchsets to the apporiate upstreams
<lool> Great; would you mind pointing me at the corresponding upstream bugs when these are filed?  I'd like to subscribe to them
<NCommander> I can't find a bugtracker for PyQT4
<NCommander> so that's just going to be an email to their mailing list
<NCommander> lool, https://bugs.kde.org/show_bug.cgi?id=177965 - theres one of the KDE ones, I have to file two more to get all the ARM patches in
<ubottu> KDE bug 177965 in KDE4 (cmake) "FindPyQT4 provides no method of accessing SIP configuration options" [Normal,Unconfirmed]
<directhex> NCommander, any issues in the cli bindings on arm?
<NCommander> None to my knowledge
<NCommander> But I only built pykde4 (which takes two hours by itself)
<NCommander> So I'm doing a full rebuild to make sure there is nothing broken
<directhex> yeah, kdebindings is bad enough on a 2+ghz core2
<NCommander> Go 233MHz ARM :-)!
 * NCommander actually has to wait for kde4libs to finish building since I needed to change parts of its build system
<directhex> i wonder whether the kubuntu people applied my cli plasma examples fixes
<tjaalton> pitti: hey, should jockey not offer to install nvidia/fglrx before they are fixed to support the new ABI, or how should it be handled
<pitti> lool: doesn't look too bad, should get proper testing, though
<pitti> tjaalton: I can temporarily disable it if you want
<lool> pitti: Naturally
<NCommander> directhex, nope, we disabled the examples
<lool> pitti: I did test it in Debian and in Ubuntu before pushing to my ppa
<lool> pitti: I'll open a new SRU bug for this, thanks
<tjaalton> pitti: I believe it should be disabled, although apt would refuse to install them too
<directhex> NCommander, that's option 2, of course. it seems some silly bugger in upstream changed a property into a method, so foo.Size became foo.Size() (which is what the 2 patches changed)
<NCommander> directhex, blame the guy who did kde4bindings
 * NCommander would include the patch if it was risk free for breaking ARM builds
<directhex> NCommander, it's adding six brackets between two .cs files. i imagine the risk of regression is small - unless there are other issues building the examples which didn't show up on amd64
 * NCommander just got kde4bindings working on ARM
 * NCommander has no desire to touch it until after its uploaded and ACCEPTED
<lool> What's the syntax in launchpad to link to a comment in another bug again?  I thought it was bug #1234#c12 but it's not
<ubottu> Launchpad bug 1234 in launchpad-foundations "Gina is an unmaintainable mess of command line options, environment variables and shell scripts" [Medium,Fix released] https://launchpad.net/bugs/1234
<lool> ups
<directhex> NCommander, i posted both patches with a 72h lifetime, so can you save them someplace?
<NCommander> directhex, attach them to a bug against kde4bindings, and set the milestone to alpha 3
<directhex> NCommander, do i have the ability to set milestones?
<NCommander> oh right
<NCommander> your not in bugcontrol
<NCommander> Just link me to the bug, and I'll set the milestones and such
<directhex> bug 308891
<ubottu> Launchpad bug 308891 in kde4bindings "[patch] Plasma c# examples FTBFS" [Undecided,New] https://launchpad.net/bugs/308891
<pitti> tjaalton: uploaded
<tjaalton> pitti: thanks
<tseliot> mvo, seb128: gnome-control-center and gnome-desktop build again (and actually work too) in Jaunty now.
<mvo> Keybuk: did you had a chance to look at the sponsor request for #304774 (sysklogd)? I will take it unless you have some objections
<tseliot> mvo: can you merge from lp:~albertomilone/gnome-desktop/tseliot-fixes and from lp:~albertomilone/gnome-control-center/tseliot-fixes ?
<mvo> tseliot: thanks a lot! will do the merge now
<tseliot> mvo: good
<mvo> cjwatson_: could you please add me (temprarely) to the debian-installer team so that I can push a (trivial) patch against the desktop file of usb-creator (bug #286924)
<ubottu> Launchpad bug 286924 in usb-creator ""Create a USB startup disk" menu entry should be named "USB startup disk creator"" [Low,Triaged] https://launchpad.net/bugs/286924
<mvo> tseliot: merged and pushed, thanks again!
<tseliot> mvo: great, thanks :-)
<cjwatson> mvo: ubuntu-installer you mean? done
<mvo> cjwatson: thanks
<emgent> norsetto: \o/
<norsetto> emgent: ah, somebody alive! Hi emgent
<asac> hmm ... does the accessibility toolkit we ship in gnome by default have a name? how is it called?
<pitti> ATK?
<fabbione> soren: if the server team is interested, i just released redhat-cluster 3.0.0-alpha1 upstream.
<soren> fabbione: Cool.
<asac> pitti: ok ... isnt that an abstract layer on top of specific implementations?
<pitti> asac: maybe it is a spec, too, but it's literally called atk1.0 (source package)
<asac> ok thanks
<asac> pitti: did we turn this on by default in intrepid or was that on foreever?
<pitti> asac: it's a basic property of GTK, but some features aren't enabled by default
<pitti> asac: see "Hilfstechnologien" in System -> Einstellungen
<asac> pitti: yeah i know. just wonder if we enabled more features by default since intrepid
<asac> there is a firefox bug which happens much more reliably in intrepid than in hardy
<asac> which could be related to atk
<stgraber> pitti: thanks
<ogra> stgraber, so now on to the main upload permission :)
<ogra> sadly TB meeint is only in a week
<ogra> *meeting
<stgraber> ogra: yep :) btw, I'll likely have a new ldm and ltsp to upload today, I'm doing some testing and trying to fix that ldm-ubuntu-theme thing (other than just reverting to the old gtk)
<ogra> stgraber, did you just copy the human gtkrc ?
<ogra> actually that shouldnt even be needed ... the old python code had an automatic fallback to use the system gtkrc, i wonder why that doesnt happen anymoe
<stgraber> ogra: at the moment I just replaced ubuntu-theme by gtk2-engines-ubuntulooks
<ogra> ubuntulooks is dead
<ogra> if you upload that ldm will pull it back on the CD
<ogra> so that wont work
<stgraber> hmm, now that I think of it, is ubuntu-theme also supposed to work on Intrepid ?
<ogra> yes, its the default
<ogra> and it uses murrine
<ogra> just copy /usr/share/themes/Human/gtk-2.0/gtkrc into the ldm-theme-ubuntu package
<ogra> that should make it work
<stgraber> ok, so the problem isn't that I'm testing with a backport on Intrepid ... (I'm still waiting for an instalable jaunty)
<ogra> do you have murrine installed in the chroot ?
<ogra> the intrepid package didnt pull it in ... (ldm should still fall back to the default gtkrc though)
<stgraber> ogra: ah, ok so I'll try installing murrine by hand (I really need a Jaunty box ...)
<ogra> just do a vbox intrepid install and upgrade ?
<stgraber> well, I'm just waiting for ubuntu-desktop to actually install, then I'll reinstall my laptop (it was last installed with Intrepid alpha-1)
<ogra> oh
<ogra> you dont upgrade by final release ?
<cinnamon> i hope this is the right place to ask. i think it is not good that bugs in ubuntu launchpad time out, when not fixed. who made this decision and why?
<cjwatson> they don't actually (at the moment), it just says they do
<cjwatson> https://help.launchpad.net/Bugs/Expiry
<cjwatson> the implementation was more a Launchpad decision than one of ours, although our bug team did comment on it
<cinnamon> thanks cjwatson
<rudchenkos> hi there. could anyone point me to an info how to use debug symbols from a *-dbg package?
<Keybuk> gdb will pick them up automatically
<rudchenkos> Keybuk, oh, it knows the "/usr/lib/debug/" path?
<Notch-1> hi, i'm looking for the persistent/casper mode developers, can somebody help me?
<luckyone> Dear ubuntu-devel, The new 64-bit package for pulseaudio that hit repos last night is such an amazing improvement. I want to sincerely thank everyone who played a part in putting it together. Best regards, luckyone!
<ogra> luckyone, send flowers to TheMuso (once he shows up)
<DktrKranz> ogra: Debian recently used cookies to hug people :)
<ogra> so we'll see a lot fat DDs soon ?
<DktrKranz> probably
<DktrKranz> especially if they plan to release before 2009!
<Mez> ogra: there'll be one mopre fat DD whenever FD get around to approving me ;)
<ogra> haha
 * steron is away (will be back !)
<stgraber> ogra: I copied /usr/share/themes/Human/gtk-2.0/gtkrc to greeter-gtkrc and now it works :)
<ogra> great :)
<stgraber> ogra: hmm, I see half of the ldm themes use gartoon and the other half use Human, which one should we use ? (icon theme)
<ogra> Human
<ogra> only keep gartoon for Edubuntu
<ogra> (we'll likely need to fiddle with deps here)
<mok0> stgraber: congrats!
<stgraber> mok0: thanks
<stgraber> ogra: ok
<sianis> hi
<kelemengabor> hi sianis :)
<sianis> hi kelemengabor
 * Keybuk just can't get git fast-export|bzr fast-import to work on the udev tree :-/
<mvo> hello kelemengabor, sianis
<kelemengabor> sianis: here is my idea: we need to archive the ddtp po-files in bzr at the time of changing the translated distribution in rosetta
<calc> pitti: do you have time to review the uploads i did last night wrt the mir?
<kelemengabor> translators will translate that, and we export that
<kelemengabor> then merge it to the archived translations of current-1
<kelemengabor> and not to the pot of current-1
<mvo> kelemengabor: we could create projects in rosetta for each release, not sure if rosetta would be able to handle that
<flowolf> hi all
<kelemengabor> because we would lose changed strings
<flowolf> I just noticed that many -dev packages got removed from older ubuntu releases
<mvo> kelemengabor: this would give us the "suggest strings from other releases" feature as well
<flowolf> what's the reason for this?
<kelemengabor> mvo: yeah, but this is unnecessary
<mvo> kelemengabor: ok, even better
<kelemengabor> mvo: suggest strings is great, but not for 1000 strings :)
<flowolf> and is it possible to have them back?
<kelemengabor> the main thing is that translators would ideally have nothing to do
<calc> flowolf: mentioning at least one of the packages by name might help someone determine the cause
<kelemengabor> to see their translations in older releases
<flowolf> calc: http://packages.ubuntu.com/feisty/i386/build-essential/download
<kelemengabor> we should merge back automagically
<flowolf> calc: try to download this
<calc> flowolf: ah yea feisty is dead
<calc> flowolf: you didn't see the notice go out a while back?
<kelemengabor> and take care to not to lose anything that already existed
<calc> "Ubuntu 7.04 reaches end-of-life on October 19, 2008"
<flowolf> calc: so you removed the -dev packages ?
<calc> flowolf: i didn't but the archive admin probably removed the entirety of feisty
<flowolf> nope, feasty is out there
<kelemengabor> because packages can move between repositories, and strings can change, we need to keep existing po-files in bzr,
<flowolf> you can still download and install "regular" packages
<flowolf> it's only the -dev packages, like build-essential or libc6-dev that disappeared
<calc> flowolf: ah ok, well i have no idea but since it is completely unsupported now i wouldn't be surprised if they removed bits of it
<kelemengabor> and at updates, create a compendium file from newly exported files
<flowolf> calc: still the packages are still there, http://it.archive.ubuntu.com/ubuntu/pool/main/b/build-essential/
<kelemengabor> and merge that compendium to the po files
<flowolf> it is only their names to be wrong in the package file
<calc> http://packages.ubuntu.com/feisty/i386/build-essential/download <- that page comes up to the mirror list
<flowolf> so you guys broke development packages on purpose for some misterious reason...
<kelemengabor> this will protect us against strings ï»¿moved from one po file to the other
<Keybuk> cjwatson: didn't you have some patches to make bzr fast-import work?
<cjwatson> Keybuk: I don't think udev worked for me either so they probably aren't relevant
<kelemengabor> I see this is rather complicated and resource-wasting, but should be a little more elegant than just using the current po files for all the older releases
<cjwatson> flowolf: no, you need to use old-releases.ubuntu.com if you're using feisty
<calc> flowolf: hmm actually no its gone completely, 11.3ubuntu1 was in gutsy which is why that package is still on the site (i think)
<calc> flowolf: plain 11.3 was what was in edgy/feisty
<cjwatson> flowolf: sorry but we simply don't have space to keep feisty on the standard mirror hierarchy
<Keybuk> tbh, git fast-export crashes with the udev repository
<Keybuk> so I'm probably doomed anyway
<flowolf> cjwatson: that's good enough
<mvo> kelemengabor: the apt-ddtp-tools can generate Translation-$lang -> po -> Translation-$lang so the current (latest) translation status in the archive can be used to create po/pot files
<flowolf> it is working
<flowolf> cjwatson: thank you
 * calc forgot that it went somewhere else when it was removed :)
<kelemengabor> mvo: cool, but using the current po files for older releases will lose some data, unfortunately
<mvo> kelemengabor: true, it would have to be a merge of old and new I guess
<kelemengabor> yeah, this is why I mentioned storing the po files in bzr
<mvo> kelemengabor: I need to go for dinner, I will be back in ~30min, ok? then we can talk more about it. let me know if you need anything in apt-ddtp-tools itself
<kelemengabor> ok, good appetite
<slangasek> directhex: working with meebey, I have mono-addins fixed up now for the 2.0 transition; this looks like it's going to be the best way to get us down to size on CDs for alpha-2 after all, so I'm going to follow through on it today
<Baby> do you know which man page section would correspond to a tcl tk command?
<slangasek> Riddell, ScottK: kubuntu ISOs are still very much oversized, is there any hope of bringing that down in time for alpha-2?
<ScottK> Dunno.  Let me see what I can come up with.
<ScottK> slangasek: There are a couple of changes I'm confortable with making.  Doing then now.
<slangasek> ScottK: uploads, or seed changes?
<slangasek> (i.e., how soon should I try rebuilding)
<ScottK> seed changes.
<ScottK> slangasek: You need a new kubuntu-meta upload too, right?
<ScottK> So the stuff gets dropped from kubuntu-desktop
<slangasek> yeah
 * ScottK notes that Riddell has been on vacation for both Alpha's so far this cycle.  Very convenient.
<ogra> he would have a hard time testing images where he is now
<ScottK> True.
<hyperair> jcastro: hey you around?
 * jdong wonders if a digital camera would work well as a scanner.
<hyperair> jdong: try super macro mode. some cameras work well enough
<jdong> WOW
<jdong> doesn't look bad at all
<jdong> (powershot sd1100, i.e. ixus 82)
 * hyperair chuckles
<ScottK> slangasek: I'm trying to get my kubuntu-meta update out the door before I have to go get kids at school.  Not sure if I'm going to make it.
<ScottK> slangasek: Is there a convenient place I can see how far off we are on CD size?
<Gadi> can someone here tell me whether ssh grabs bits from /dev/urandom only upon the initiation of the session or whether it is constantly pulling from /dev/urandom to encrypt each packet?
<ScottK> slangasek: Uploaded what I have.
<slangasek> ScottK: convenient place> well, the directory index gives you the current size, and the target size is $((700 * 1024 * 1024))
<slangasek> uploads> thanks
<highvoltage> hey slangasek
<slangasek> highvoltage: hello
<ogra> whoops, what happened to http://qa.ubuntuwire.com/ftbfs/
<ogra> no more ftbfs at all \o/
<highvoltage> whohoo!
<ogra> heh
<ScottK> slangasek: How about go ahead and NBS out kdeplasma-addons-libs4.  The only remaining rdepends are transitional packages on ia64 and hppa.  Getting them really gone will take a while.
<ScottK> LaserJock: The package kpercentage has been removed by upstream, so it needs to be removed for Edubuntu seeds/meta (it's on the NBS list currently).
<LaserJock> ScottK: right, I've got it removed locally, just having pushed+uploaded, I'll do that nowish
<ScottK> LaserJock: Great.  Thanks.
<ogra> infinity, oh, did you just do another mass give back ?
<bigon> libv4l has an higher version in intrepid than in jaunty should I report that?
<doko> NCommander: any results with your kde4bindings experiment?
<slangasek> ScottK: kdeplasma-addons NBSed
<Keybuk> would I be right in thinking that there's no particular standard to the content of Vcs-Bzr ?
<NCommander> doko, I built it on ARM :-)
<ScottK> slangasek: Thanks.
<Keybuk> Vcs-Bzr: lp:~ubuntu-core-dev/udev/ubuntu
<Keybuk> would that be the "right thing" to put there?
<pochu> Keybuk: I think it needs to be an URI
<Keybuk> that is a URI
<ScottK> slangasek: We have a proposed solution for Kubuntu oversize.  It'll be an hour or two before I can do it.
<slangasek> Keybuk: to date I've spelled it out rather than using lp:, but there's no standard other than it being a URI
<slangasek> ScottK: ok, cheers
<Keybuk> slangasek: the advantage to the bazaar http URL is that you can stick it in a web browser as well
<ScottK> slangasek: In the meantime, if you want to move kmail and kdepim from cd to dvd that'll also let mysql and akonadi fall off the CD.
<slangasek> Keybuk: true
<Keybuk> the disadvantage is that you have to rewrite it by hand to be able to *commit*
<Keybuk> the advantage to the lp: URI is that bzr will use bzr+ssh if you can commit, http if not
<ScottK> slangasek: If an hour or two doesn't hurt, just leave it to me.
<pochu> Keybuk: I guess if debcheckout can use it properly, it's fine then. But I'm not sure :)
<Keybuk> ah, maybe debcheckout handles the http/bzr-ssh transition
<slangasek> Keybuk: well, 'debcheckout -a' knows how to rewrite the http urls; and once you've checked out from lp: you still have to rewrite by hand to turn that into a commitable url if, say, you gained commit access after you did the checkout
<Keybuk> I'll use http then, since that's what most packages seem to do
<slangasek> ScottK: I'll probably leave it to you, since I'm still fighting with ubuntu CD sizes
<ScottK> OK
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down from 22:00 UTC until 23:00 UTC for a code update | UDS: done, Archive: frozen for alpha-2, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com
<calc> ugh launchpad maintenance at 4pm, lol
<calc> asac: do you have MIR approval access?
<cjwatson> https://launchpad.net/~ubuntu-mir/+members
<calc> cjwatson: thanks :)
<slangasek> doko: do you know why pygtk was "ported" to numpy in Debian?  What was wrong with the way it was built previously?
<slangasek> doko: (this adds a number of packages to the CDs that weren't needed, previously)
<slangasek> doko: hmm, I guess we were using python-numeric previously, which has much simpler depends
<pochu> slangasek: according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478452, because python-num{eric,array} are unmaintained upstream
<ubottu> Debian bug 478452 in pygtk "pygtk: should use python-numpy instead of python-num{eric,array}" [Important,Closed]
<slangasek> but the one that is maintained upstream has bunches more deps, hmm :/
<doko> slangasek: yes, we do want to get rid of the old numeric packages. not sure, if we can modularize numpy
<slangasek> doko: ok.  FWIW, the switch from numeric to numpy is a net loss of ~6MB on the CDs
<slangasek> (libblas3gf+liblapack3gf+libgfortran3, plus a size delta between numpy and numeric themselves)
<directhex> bloaty python :/
<doko> pochu: could you ask upstream if they can support a minimal build/split?
<doko> slangasek: yes, we had these dependencies in python-numeric-ext, which was not on the CD
<bryce> slangasek: https://wiki.ubuntu.com/Hotkeys added a 'should be' diagram based on a photo of mdz's whiteboard art.  Let me know if I got anything incorrect there
<slangasek> bryce: doh, I had already been working on one of those; but I also discovered that hotkey-setup does some stuff that's outside of what can be done with hal fdi, so it probably remains for the near term
<bryce> slangasek: ok I'll stick that back in
<bryce> how about atkbd?  timo thought that it was going away
<pochu> doko: I don't know them (I never touch it) but Ondrej does
<slangasek> bryce: I don't think that's going to cease to exist inside the kernel, is it?  It's just going to be accessed via the event interface
<bryce> yeah I dunno the details
<bryce> https://wiki.ubuntu.com/Hotkeys updated
<directhex> hm. RIP adept.
<slangasek> ?
<directhex> http://web.mornfall.net/blog/farewell__44___adept.html
<NCommander> ugh
<NCommander> Of course LP shuts down the moment I need it
<calc> heh the information about the new LP release is linked back to... LP so you can't even read about it while it is being done
<bryce> calc,  >o<
<ScottK> slangasek: I have a fairly draconian whack at the Kubuntu CD prepped for whenever LP wakes up from being broken.
<Nafallo> not broken :-)
<Nafallo> upgraded
<ScottK> Nafallo: If it's not working it's broken.  These long outages for upgrades are, IMO, a sign of poor design.
<ScottK> Scheduled broken instead of randomly broken, but still broken.
<NCommander> StevenK, did you ever find out if the bug in germinate was fixed w.r.t. to fbreader?
<StevenK> NCommander: Nope
<StevenK> Was plotting to ask Colin
<NCommander> StevenK, ah good
* mthaddon changed the topic of #ubuntu-devel to: UDS: done, Archive: frozen for alpha-2, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ScottK> slangasek: Any idea how https://launchpad.net/ubuntu/jaunty/i386/kdeplasma-addons/4:4.1.85-0ubuntu2 got deleted?
<slangasek> ScottK: <cough> probably the line where I said "<slangasek> ScottK: kdeplasma-addons NBSed", where neither of us seem to have noticed I got the package name wrong
<ScottK> Ahh.  That'd do it.
<ScottK> slangasek: Do I upload it again or can you put it back?
<slangasek> I think we established at UDS that it's possible to restore NBSed binaries
 * slangasek takes out the right package instead, while he waits
<ScottK> slangasek: If you'd do that, I'd appreciate it.  Excellent.
<ScottK> slangasek: OK.  When I updated kubuntu-meta it took that out of the desktop (since it didn't exist).  I'll wait until you put it back and run it again.
 * slangasek nods
<ScottK> It'll be a bit because I've got more kids to get to ballet lessons.
<bryce> calc: now that lp is back up, where do we find the release notes?
<slangasek> ScottK: fwiw, the people I need in order to get the binaries restored aren't responding - a reupload may be simpler
<calc> bryce: well not sure if it is the release notes but the news.launchpad.net referred to the release via a link to LP
<calc> https://launchpad.net/launchpad-project/+milestone/2.1.12
<calc> i guess that sorta tells you what got fixed its just a list of bugs :)
<bryce> ahh, good idea
<bryce> calc, mm, lots of bug fixes, although nothing that I recall affecting me
<bryce> calc, the signed ppa's sounds interesting; shame that the Read Only Launchpad feature doesn't appear to have gotten done
<FAJALOU> just a question:  is a rolling release a possiibility for ubuntu?
<directhex> FAJALOU, a 6-month release cycle is too long for you?
<FAJALOU> directhex:  trying to update to a new system every 6 months is yes.
<FAJALOU> i hate doing it b/c i always end up having to take days to reconfigure this and that.
<bryce> FAJALOU: how would you define 'rolling release'?
<FAJALOU> directhex:  it's more of the opposite; it's too short.
<directhex> then use the LTS releases.
<FAJALOU> bryce: as in i never have to go through a 'major' upgrade again.
<ogra> FAJALOU, if you file bugs abut this and that these can be fixed for next release ;)
<FAJALOU> directhex:  i would love that,,, except then there are things in 8.10 that don't show up in 8.04, even if they are both supported.
<bryce> FAJALOU: so why not just stick with LTS?
<directhex> short answer: no
<directhex> long answer: noooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
<FAJALOU> bryce:  because i just upgraded to 8.10... stupid decision on my part ;)
 * bryce shrugs  worked for me
<FAJALOU> bryce:  ya if only it 'just works' for all of us.
<calc> the only time i have to bother with reconfiguring things is if i blow away my system entirely including my home dir, which doesn't happen often
<calc> if you just do a real upgrade then it shouldn't require too much reconfiguration
<bryce> FAJALOU: so it's not that you want a rolling release, you just want perfection
<ogra> rolling perfection :)
<calc> it shouldn't really require more reconfiguration even if it is broken, it either works or it doesn't generally, heh
<FAJALOU> bryce:  well i see rolling release as closer to perfection,,, because you don't have to worry about total reconfigurement ;)
<calc> FAJALOU: so just don't reinstall, just upgrade?
<ogra> but you will have 100 times more bugs
<bryce> FAJALOU: sure you do
<bryce> FAJALOU: consider if you got a rolling upgrade to a new xserver, or a new kernel...
<FAJALOU> bryce; ok ya i guess that makes sense.  you too ogra
<ogra> in a 6 month release cycle less than half of it is used for development, the rest is stabilization and bugfixes
<FAJALOU> point.
 * calc bbl, going to give a speech at my LOCO
<kees> doko: around? looks like the mysql jaunty pain is between -O1(works) and -O2(explodes).  (using gcc-snapshot)
<directhex> FAJALOU, rolling releases are fine if you want zero QA, e.g. gentoo. stable releases imply someone's actually making sure it works
<FAJALOU> QA?
<ogra> quality assurance
<doko> kees: you might want to file an upstream bug report with your current findings, and update this one later
<slangasek> ScottK: correction, cprov rescued them for me
<kees> doko: okay.  can I still do .o bisection even though some are -O1 and some are -O2 ?
<doko> kees: sure, please do. we need at least find the miscompiled file
<kees> doko: okay, cool.  /me continues...
<kees> doko: (thought I suspect it's much more than just 1 file)
<doko> kees: hmm, ok, please file the upstream report, maybe you get feedback there as well
<LaserJock> slangasek: mind if I upload edubuntu-meta?
<slangasek> LaserJock: go ahead
<LaserJock> slangasek: thanks
#ubuntu-devel 2008-12-18
<ScottK> slangasek and cprov: Thanks.
<kees> doko: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38562
<ubottu> gcc.gnu.org bug 38562 in c++ "mysql miscompiles and causes testsuite failures" [Normal,Unconfirmed]
<arthur-> kees: perhaps also useful to add the preprocessed log_event.cc as well
<kees> arthur-: good idea, I will add that
<doko> kees: please could you update the field keywords to wrong-code, known to work to 4.3.2 and known to fail to 4.3.3 4.4.0, and prefix the subject to [4.3/4-4 regression] ?
<doko> I'm not allowed to do so
<StevenK> doko: I note boost 1.3{6,7} don't exist in Jaunty currently.
<kees> doko: done
<StevenK> doko: I wanted a working schroot on armel, which is why I uploaded the workaround. Would you like me to revert it?
<doko> StevenK: yeah, maybe needs a sync after the alpha release
<arthur-> kees: 4.4 rather than 4-4 ;)
<StevenK> I didn't think it had updated in Debian ...
<StevenK> It hasn't
<kees> arthur-: I was wondering about that.  :)
<arthur-> kees: yeah, doko does so much typos ;p
<StevenK> doko: However, schroot is universe, so we can just play now, if you want.
<kees> arthur-: no difference in -E output between -O1 and -O2 (as I suspected).  is it still useful to attach the -E output?
<arthur-> kees: -E doesn't run compiler, so optimization level doesn not influ on it, and yes it is, much easier to check if the bug is fixed from it after or even to extract a testcase
<kees> okay, adding
 * calc is at the LOCO meeting in a reasonably authentic british pub
 * ogra wonders if "reasonable" means a union jack on the wall or guiness in bottles :)
<calc> they have beer and stuff and fish and chips that seem about like at morpeth
<calc> my wife got fish and chips at a regular seafood place here in the US and it wasn't anything like the pub stuff
<ogra> heh, i was just kidding
<calc> :)
<ScottK> slangasek: Just did a kubuntu-meta upload that I think will get us back under the size limit.
<ogra> kubuntu on diet :)
<slangasek> ScottK: great, I'll set the CD builder up to watch for it
<calc> what is the name of the gnome timekeeping app?
<ogra> hamster
<calc> ogra: you sure about that? i don't see a package
<calc> ah hamster-applet
<ogra> hamster-applet
<calc> ok thanks :)
<ogra> :)
<slangasek> how... intuitive?
<ogra> lol
<calc> i did a dpkg -p hamster instead of doing a apt-cache search
<Nafallo> baah. I use Tomboy for that :-P
<calc> wow we have 8 people here so far, a record turn out i think ;-)
<calc> dumb pub moved us under speakers and then cranked the volume to max
<calc> can't even hear myself think
<ogra> you got IRC who needs to hear ... just make the others fire up their laptops
<calc> there is only two other people with laptops i think
<calc> i think they aren't really geeks just pretend geeks ;-)
<calc> there is someone here giving out linux journal swag but apparently doesn't work for them
<ScottK> slangasek: Would you please remove kdeplasmoids kdeplasmoids-dbg kdeplasmoids-data - They are all transitional packages that can safely die.
<slangasek> ScottK: are they NBS? they aren't showing up in the latest report yt
<slangasek> yet
<ScottK> They are.  The kdeplasma-addons upload I did a couple of hours ago was missing them (by design).
<slangasek> ok
<ScottK> You'll see the version they show up under uninstallable isn't the current one for that package.
<slangasek> done
<ScottK> slangasek: That will leave just plasmoid-quickaccess and libplasma2 uninstallable for KDE packages.  Both those can be binary demoted to Universe.  The libplasma2 -> libplasma3 transition will take a while to complete.
<ScottK> slangasek: Thanks.
<slangasek> hmm, are they uninstallable because they depend on universe packages, or non-existent packages?
<slangasek> I don't see the point in demoting them if they're uninstallable regardless
<ScottK> rsibreak is screaming at me.
<ScottK> If a vanish for half a minute, that's why
<ScottK> libplasma2 is uninstallable.
<ScottK> plasmoid-quickaccess will eventually get ported to libplasma3, so leaving it is probably best.
<slangasek> ok; I'd just as soon leave libplasma2 on the main uninstallables list as anywhere, then - or else NBS it out directly
<ScottK> Let's leave it then.
<StevenK> The NBS list currently makes me cry
<slangasek> StevenK: I've done a pass earlier today, I just haven't refreshed the list because I can never remember where to do it
<emet> flashplugin-nonfree seems to be broken
<calc> jcastro: i'm going to try to give your ontario speech but its really loud here so not sure if its going to work well :-\
<calc> jcastro: and no projector
<rlaager> pitti: Something I forgot to suggest at UDS... It seems to me that Apport & Launchpad should conspire together, as appropriate, to set the "affects me" flag for people filing duplicate crash reports. This may not have to be Apport-specific, though, as it seems you'd want that for anyone saying, "yes, that's my bug".
<calc> rlaager: aiui it already does that
<calc> rlaager: at least if they are similar enough
<rlaager> Hmm. I don't recall seeing it do so, but I suppose I could've missed it.
<calc> rlaager: well no but it consolidates duplicates
<calc> rlaager: so you are correct
<calc> rlaager: so yea doing a me too instead would be better
<jcastro> calc: steal as much as you like
<calc> jcastro: heh :)
<ScottK> Well it doesn't even default to 'affects me' when you report the bug, so I doubt it does it for dupes.
<ScottK> slangasek: Any idea how long until there's a new Kubuntu CD image?
 * ScottK isn't sure how to keep track of the process.
<slangasek> ScottK: alternate and livefs both building right now; so should be < 1h
<ScottK> slangasek: Thanks.
<avb> guys, is there is any ideas why /bin/sh is still a symlink to /bin/sh
<avb> to /bin/bash
<avb> instead of having regular sh, which is way faster
<Hobbsee> sarah@neptune:~% ls -la /bin/sh                                          2:32PM
<Hobbsee> lrwxrwxrwx 1 root root 4 2008-09-12 15:04 /bin/sh -> dash
<avb> $ ls -l /bin/sh
<avb> lrwxrwxrwx 1 root root 4 2008-02-06 19:02 /bin/sh -> bash
<avb> i was not changing nothing manually
<ScottK> avb: What release are you running?
<avb> 8.10
<Hobbsee> i think you've done something to your system - the default changed a few releases ago
<avb> i case i was not making clean installs
<ScottK> avb: New install or upgraded from earlier?
<avb> for a couple of releases
<ScottK> That may be  the reason.  IIRC that change was made on install, not upgrade so stuff already there wouldn't get broken.
<avb> i see
<avb> # update-alternatives --config /bin/sh
<avb> No alternatives for /bin/sh
<ajmitch> not sure if that started with dapper or edgy
<avb> thats another issue
<avb> should i fill a bug?
<avb> i just checked system dash is already there
<avb> but in postinst it havent made update-alternavites
<ScottK> avb: No, it's by design.  /bin/sh is just a symlink.  Change it.
<avb> thats a case, why new install have dash, and dist-upgrade dont
<avb> ScottK, but its realy looks like a bug, not like a design
<avb> probably lets change the design a bit? :)
<avb> i can submit patch if needed
<avb> not a big deal
<ScottK> avb: Because an existing system may have third party stuff on there we can't know about and we are conservative about breaking stuff on upgrades.
<ScottK> No, this is on purpose to be careful with not causing breakage on upgrade.  This is a feature and no bug.
<avb> heh
<avb> thats realy weird behavoir. once we are moving from upgrades to reinstalls
<avb> smells like 2nd windows
<avb> anyway, any 3rdparties should be informed once they bashing once interpriter is set to /bin/sh
<ScottK> There's a lot of config stuff that doesn't get touched on upgrade.
<ScottK> Postfix configs for another one.
<avb> yes, i will be more then happy if it will be just bash
<avb> :)
<avb> i dont have my splash since breezy :)
<avb> anyway i disabled it, but still
<avb> then it was a network-manager and couple of other stuff
<ScottK> slangasek: Is 20081218.2 the one I should be looking at or is it not published yet?
<ScottK> slangasek: I'm likely to head to bed soonish and I'd really like to know if anything else needs to be whacked out of there.
<slangasek> ScottK: hrm, yes, .2 was the build in question
<slangasek> ScottK: for desktop, anyway
<ScottK> slangasek: OK.  Then apparently I suck.
<slangasek> what went wrong?
<ScottK> http://cdimages.ubuntu.com/kubuntu/daily-live/20081218.2/ says still oversize.
<slangasek> no idea why, yet?
<ScottK> I know why some stuff got bigger.
<slangasek> the .1 and .2 builds have identical livefs on them
<slangasek> did the livefs build fail?
<ScottK> Dunno.  I'm pretty new to this part of things.
<slangasek> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/jaunty/kubuntu/
<slangasek> full-sized build logs for 20081218.1 (yes, the livefs serials aren't guaranteed to match the CD serials)
<ScottK> OK.
<slangasek> so, the livefs build didn't fail at least
<slangasek> kubuntu-desktop 1.105 is present in all the images
<ScottK> slangasek: That one was built with kubuntu-meta 1.05, not 1.06,
<ScottK> 106 is what we wanted.
<slangasek> ... oh.
<slangasek> sorry, when I looked 106 wasn't visible in LP yet, I had assumed 105 was correct :/
<slangasek> ok, re-triggering
<ScottK> Finding something that had a version number in it helped a lot.  Thanks for the pointer.
<ScottK> slangasek: Next question: is getting proper builds on armel something worth uploading stuff for now?
<slangasek> yah, sorry for not checking the version number with you explicitly earlier :/
<ScottK> NCommander is confident he finally has kde4bindings (which is the key to most of Kubuntu Desktop) figured.
<NCommander> It builds fine
<NCommander> I'm just tweaking some of the install rules
<ScottK> It'd take an upload of kde4libs, python-qt4, and kde4bindings to fix.
<slangasek> well, I didn't have any intention of releasing armel images for alpha-2 yet
<ScottK> OK.
<NCommander> ScottK, hold on, I'm still making rules changes
<ScottK> I'll hold it until after the milestone then.
<slangasek> sounds good
<ScottK> NCommander: No problem.  That sounded like don't do it from the RM to me.
<ScottK> slangasek: The changes I did for that upload should save north of 40MB.  They'll do for alpha2, but not for the long run.
 * slangasek nods
<slangasek> ScottK: amd64 alternate is still a hair oversized :(
<ScottK> Gumble.
<slangasek> 2624K, to be exact
<ScottK> slangasek: Are the others OK
<slangasek> alternate i386
<slangasek> livecd always takes longer to build, so I don't know ye
<slangasek> t
<ScottK> OK.
<ScottK> slangasek: You didn't put the publisher on manual did you?
<slangasek> no
<ScottK> We got plasmoid-quickaccess fixed for libplasma3, but the binaries have been sitting unpublished for over an hour.
<ScottK> I was hoping to put that back (it's only 68K)
<ScottK> Grumble's more.
<slangasek> hmm
<slangasek> ScottK: looks like the hourly job from 2h ago overran and as a result, the last hourly job failed on the lock
<ScottK> Thanks.  Patience then.
<kirkland> what's the new package queue url in launchpad?
<slangasek> /ubuntu/jaunty/+queue, I believe
<kirkland> slangasek: thx
<slangasek> ScottK: liveCD built, and the /only/ difference in the livefs contents is the kubuntu-desktop version
<ScottK> slangasek: Built fits?
<slangasek> oversized, since there was no other reduction to the livefs contents
<ScottK> slangasek: OK.  So I found the 2624K for the amd64 alternate.
<ScottK> How much more do we need?
<slangasek> for desktop?  were the previous changes not expected to have an effect on desktop CD size?
 * ScottK is confused he thinks.
<ScottK> The amd64 alternate was 2624K over, but i386 fit.
<slangasek> yes
<slangasek> desktop just built, and the results are that nothing changed in the livefs except for the kubuntu-desktop version
<slangasek> so, still oversized by ~40MB
<ScottK> OK.  That's odd.
<ScottK> So the alternate shrank, but live didn't?
<slangasek> correct
<ScottK> Odd
<persia> Did the task change as well as the metapackage?  I seem to remember this sometimes taking an extra cycle for timing reasons.
<slangasek> appears to be an issue of the Task: field not having updated yet for these packages in the archive
 * ScottK looks at the logs
<slangasek> it should right itself with the next publisher run; I guess we haven't had enough publisher runs yet, probably due to overruns
<ScottK> OK.
<ScottK> slangasek: I think I have enough shrinkage to cover the 2624K.  If I upload that and go to be, can you just pitch language packs off the live until it fits if needed?
<ScottK> go to be/bed.
<slangasek> can do, yes
<ScottK> slangasek: OK.  107 uploaded.  I'm off to bed.
<slangasek> 'night
<ebroder> In researching LP #305001, I noticed that python-elixir and python-sasync both ship versions that can't work with the python-sqlalchemy in Hardy. Should I fix this through -backports or try to get them SRU'd?
<ubottu> Launchpad bug 305001 in hardy-backports "Please backport sqlalchemy 0.4.8 from Jaunty to Hardy" [Undecided,New] https://launchpad.net/bugs/305001
<persia> ebroder, If they truly can't work, it would be an SRU, although you should be seeking the minimal patch to make them work.
<ebroder> Oh wait...I may be lying about python-elixir. I need to do more research
<ebroder> persia: So I should try to do this by attempting to extract the necessary patch to add compatibility for sqlalchemy? That's substantially more work and more likely to regress than just pulling the newer version...
<persia> ebroder, I'll agree on the more work part.  Whether it is more likely to regress is probably a matter of the final resulting patch size.  I'm not in an SRU approval team, but if you're sure it's worse to make a patch, you'll want to state your argument very carefully, and be absolutely sure there isn't some small patch that works.
<ebroder> persia: Yeah...I'm not actually willing stand by that assertion. I don't use the packages myself, so I'll file the bug - maybe someone who cares will deal :-P
<Tonio_> hi
<slangasek> doko_: looking at the changelog, there used to be a python-numpy-ext package split off, and you merged it in?
<doko_> slangasek: can't remember ... looking ...
<slangasek> it was a while ago :-)
<doko_> slangasek: hmm, have to look ... but probably not in time for the alpha
 * slangasek nods
<slangasek> fwiw, I'm currently poking at it because I don't see anywhere else that I can claim back even close to that amount of space, and amd64 is oversized
<slangasek> so if nothing else, I may have a patch for consideration in the next hour or so
<doko_> lapack_lite.so could be split off, but I'm unsure about _dotblas.so which is in core
<doko_> splitting the .py and doc files doesn't save much
<doko> slangasek: how do you get rid of _dotblas.so?
<dholbach> good morning
<slangasek> doko: dotblas.so is easy, it's only loaded opportunistically
<slangasek> # try to import blas optimized dot if available
<slangasek> try:
<slangasek> lapack_lite actually seems to be hooked deeper, there are a lot of references to linalg
<doko> omitting the tests or oldnumeric doesn't save much
<slangasek> well, getting rid of fortran will save a lot
<doko> why is setup.py packaged?
<slangasek> I... don't know :)
<slangasek> hrm, the hooks into lapack_lite/linalg are way too deep for this to be even a remotely "quick" fix
<doko> slangasek: maybe have an -ext package with the lapack_lite linked with fortran, which diverts the lapack_lite in a reduced -numpy package, and then build lapack_lite with the included *_lite.c files?
<slangasek> so lapack_lite is buildable in some reduced, non-lapack form?
<slangasek> hmm, looks like that could work, after all
<slangasek> but I don't think I would succeed in getting it to build at this hour
<doko> slangasek: hmm, maybe for a quick solution, just drop the b-d on lapack and blas and build it this way?
<slangasek> doko: ok with me; I guess we need to remember to revert that after the alpha?
<doko> slangasek: yes, bug report for the reminder should be fine. but I can only upload later today
 * slangasek nods
<mvo> slangasek: thanks for the fix in deskbar-applet!
<slangasek> mvo: n/p
<slangasek> ScottK: looks like we just need to drop the Japanese langpack from desktop/i386 and we're set
<dholbach> doko, DktrKranz: what do we do about bug 195407?
<ubottu> Launchpad bug 195407 in mingw32 "mingw-4.2 requires shared lib{gcc,stdc++} for cross-dll exceptions" [Low,Confirmed] https://launchpad.net/bugs/195407
<DktrKranz> dholbach: I haven't tried, but there were some discussions on debian remote watch
<dholbach> DktrKranz: aha
<DktrKranz> dholbach: I'm unsure how to proceed, since Debian side stalled a bit (latest update was in early 2007, IIRC)
<dholbach> DktrKranz: maybe doko knows
<norsetto> dholbach: DktrKranz: morning gents!
<dholbach> hiya norsetto my friend :)
<highvoltage> he's come to speak with you again
<highvoltage> (that sound-of-silence reference was a bit too weak)
<DktrKranz> hi norsetto, Master of Rivers
<norsetto> highvoltage: hi to the other side of the globe too ;-)
<highvoltage> norsetto: hi :D
<cjwatson> liw: at your convenience (and perhaps after alpha 2), could you cause there to be a new upload of system-cleaner to jaunty (even if it's no-change)? A Soyuz bug has meant the Architecture: all binaries have gone missing from armel's Packages files; we've encountered this before with binaries copied from -updates and it's been raised with the Soyuz team, but for now a reupload is the simplest solution
<cjwatson> could somebody score up debian-installer a bit on armel? I'd like to know whether it'll build before Saturday
<liw> cjwatson, ack, will do
<liw> now would be a good time to re-visit the question of the software's name -- "Cruft Remover" turns out to be a bad name
<cjwatson> I thought cruft was a non-jargon word too but apparently I was wrong. I think I was thinking of "lint", which is the stuff you pick off clothes
<cjwatson> I'm in favour of (almost) anything that allows us to stop endlessly wasting time on naming arguments
<davmor2> liw: just call it lint remover
<liw> I'd like to change the word "remover" as well, since not everything the program does is remove things, sometimes it adds them too
<davmor2> just read cjwatson's reply like minds
<liw> the word "janitor" keeps bouncing inside my skull
<liw> but yeah, I would prefer to not re-visit this question, either
<ScottK> The last Kubuntu live CD came out slightly over-size on i386.  I've adjusted language packs, so I think it's good. Would someone please kick off another CD build?
<NCommander> hey ScottK
<cjwatson> ScottK: which seed(s) did you change?
<cjwatson> oh, hey, I could just look
<NCommander> morning cjwatson
<cjwatson> morning
<ScottK> cjwatson: Kubuntu live
<ScottK> Or more specifically, kubuntu.jaunty live.
<ScottK> NCommander: Heya.
<NCommander> how goes it this morning?
<cjwatson> ScottK: hmm, when? last commit was 0855 UTC by Steve
<ScottK> cjwatson: OK.  Or I didn't.
 * ScottK looks.
<ScottK> cjwatson: It looks to me like he and I made the same change, but I hadn't updated.  It also looks like he didn't respin the CD unless one is in progress now.
 * ScottK doesn't know how to tell about that.
<cjwatson> he may have had to wait for a publisher run
<cjwatson> there's nothing in progress right now (the logs are published so in principle you could tell from that, but they're only mirrored hourly)
<cjwatson> I've kicked off a build now
<ScottK> cjwatson: Thanks.
 * ScottK sits back and tries to figure out how he got in charge of making Kubuntu fit on the CD during Riddell's vacation.
<cjwatson> liw: (did "System Janitor" ever come up as a suggestion?)
<cjwatson> ScottK: just lucky :-)
<ScottK> ;-)
<cjwatson> liw: oh, https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-November/006139.html
<liw> cjwatson, someone did suggest System Janitor, but to me, it's uncomfortably close to System Cleaner
<cjwatson> liw: I don't think you need to avoid "System X"
<cjwatson> "System Cleanser" does seem too close for comfort
<NCommander> cjwatson, am I correct in thinking that we're almost out of alpha 2 freeze :-)?
<ScottK> System Decruftifier
<cjwatson> NCommander: we'll be out of it when Steve sends the release announcement
<cjwatson> decruftifier> oh god no :)
<NCommander> :-(
 * NCommander listens to black hole sun
 * NCommander pictures cjwatson with some sorta giant cruft bufter gun dressed as a terminator
<NCommander> ....
<NCommander> I'm not sure if thats scary or awesome :-P
<NCommander> s/bufter/buster/g
<mdz> bryce: in your 'should be' diagram, the hal-addon-acpi line should be solid, not dashed
<ays> guys, one simple question... in order for someone who's been win based developer and would like to migrate to Linux development, which programming lang and ide would you suggest that he use?
<cjwatson> that isn't a simple question because it depends on their experience and (perhaps much more strongly) on what they want to do.
<ays> ah... well, I can tell you some stuff, for example, I've been developing mostly with c#, for about 3-4years now
<ays> before c#, I used c,c++ and somewhat java
<ays> the logical answer would be c++, but I really do not know, how much c++ is used in linux development and linux apps development...
<ScottK> It's used a lot in KDE.
<azeem> Qt is C++, GTK is C, but there are some C++ GTK apps as well
<ays> ScottK I read about c++ and KDE, but, since I'm using gnome and prefer my Linux not to look like Win...
<ScottK> Well C# is pretty much C# if you like such things.
<ays> I dont like c#, to be honest... I did like Visual Studio and stuff that it does and how it makes you less code... and I have to use it, for now, to make living... what about java and/or python?
<ays> I aint really familiar with python, heard only great stuff about it... and java is something I know already
<azeem> ays: do you want to start a new project, or contribute to existing projects?
<azeem> you can use all of those languages for writing GNOME applications, though I am not sure Java-based GNOME apps are accepted officially
<ays> well... at this point, I don't think Im good enough to contribute to ubuntu community in development ways... so... when I get somewhat better in linux based development, I'd like to try to help and contribute in any way, either with current on with new projects
<ScottK> In Ubuntu, Python tends to be the language of preference for internal projects.
<ays> or*
<NCommander> ScottK, is there any major Ubuntu tool that isn't written in python?
<NCommander> (aside from the wiki, which I believe is perl based)
<StevenK> NCommander: Upstart
<NCommander> right
<NCommander> But thats kinda out of necessity ;-)
<ays> basically... it all comes down to python...  regarding ubuntu, but what about creating apps for all linux platforms, for example, pdf reader or something like that?
<azeem> ays: see above
<ays> c++ and python then... I thought so, but had to check... thank you all for the help. :)
<cjwatson> ays: for the most part you can carry on using languages you're comfortable with, but you will likely have to learn new sets of runtime libraries. As for IDEs, well personally I'm old-school and use vi and make, but I hear that things like eclipse and anjuta are popular.
 * persia plugs netbeans
<ScottK> cjwatson and slangasek (when he wakes): It fit.  So all 4 Kubuntu images fit now.
<ScottK> cjwatson: Thanks.
<Koon> doko: I just tested jvm.cfg-default. It installs as /usr/lib/jvm/java-6-openjdk/jre/lib/$arch/jvm.cfg-default, is it by design ? Tools like keytool (ca-certificates-java) or jsvc (tomcat) apparently only look for "jvm.cfg"
<ays> cjwatson thanks mate, I'll check 'em out
<cjwatson> ScottK: cool
<doko> Koon: there's a patch (debian/patches/default-jvm-cfg.diff) to look for this file (which is not installed as a config file)
<Spads> NCommander: the wiki is not Perl
<NCommander> I thought it was
<Koon> doko: ok, looking
<Koon> doko: then we should probably also teach jsvc to look for this file
<doko> Koon: I see, the jdk has a second copy, which is still unpatched ...
<Koon> doko: jsvc (commons-daemon) directly parses what's on the filesystem and explicitely looks for jvm.cfg, so I guess it needs to be taught about jvm.cfg-default
<Koon> I'll investigate that, there might be another way around it
<doko> Koon: in this case, maybe assume just a default configuration?
<Koon> doko: yes, theorically jsvc accepts a -jvm parameter to explicitely set the libjvm.so without looking at the conf file
<Koon> though that seems to be buggy. I need to go deeper into that
<Koon> doko: otherwise that sounds like a great solution to our problem, thanks :)
<ScottK> Would whoever updates the iso qa tracker please add http://cdimages.ubuntu.com/kubuntu/daily-live/20081218.5/ i386 and amd64?
<doko> Koon: -server seems to be safe choice, it's available on every platform/architecture
<Koon> doko: yes, and that's one of the few jsvc doesn't even try to find :) It tries client, classic...
<soren> NCommander: Could you be pursuaded to take a glance at libaio? It's failing on all but the official architectures, and I haven't a clue where to start fixing it.
<NCommander> link?
<soren> Well, I probably do, actually, but it's easier to pretend not to.
<soren> https://edge.launchpad.net/ubuntu/jaunty/+source/libaio/0.3.107-1ubuntu1
<NCommander> soren, amazing, it built on the itatinic
<soren> NCommander: It'll probably fail at runtime.
<soren> NCommander: Most of the test cases fail.
 * NCommander winces
<NCommander> I don't think I even want to look at the code that could generate that build failure
<soren> Of course you do.
<soren> You like pain. We all know that.
 * NCommander hurts soren :-P
<soren> Yes, I like pain, too. It's just that I'm into a different kind of pain these days.
<NCommander> ....
 * NCommander bleaches his brain
<NCommander> soren, I think the test suite busted
<NCommander> soren, amd64's test suite blew up miserably as well :-)
<NCommander> the test suite is obviously not 64-bit clean
<NCommander> anyway, any objections if I only test build on sparc once I fix it?
<NCommander> (well, sparc/release archs)
<soren> PRobably not.
 * liw ponders "Janitor Service" as a name
<NCommander> Oh
 * NCommander hits his head
<NCommander> I see what's going on
<persia> liw, But it's not a service : it's a one-time thing, right?
<liw> persia, that's a good point
<NCommander> ah
<NCommander> crud, if I'm right on this build failure, I'm going to hurt the author
<liw> perhaps the naming problem is an indication that mpt is right and the whole program shouldn't exist and the functionality should be part of, say, update-manager
<NCommander> soren, found your build failure
<NCommander> /#warning Not really sure where kernel memory is.  Guessing.
<NCommander> ;.;
<liw> NCommander, *blink*
<NCommander> That's code you DON'T want to see in a test suite
<NCommander> oh I see
<NCommander> It wants an invalid pointer ...
<NCommander> soren, see -motu
<soren> saw it
<NCommander> Can we just be cheap and do the same fix :-)
<soren> NCommander: Feel free to do the merge.
<NCommander> I was just going to implement the change as ubuntu2
<NCommander> That merge looks ugly
<soren> It probably is.
<NCommander> although merge-o-matic did give a merge that only had the usual control issue
<NCommander> hrm
 * NCommander does the merge instead
<NCommander> Better fix
<soren> \o/
<NCommander> soren, merged
<NCommander> That was easier than it looked :-)
<ScottK> Is stgraber the right POC for iso tracker updates?
<persia> ScottK, mostly, although #ubuntu-testing may have others.
<ScottK> persia: Thanks.
<gardier> hello I have a computer which has stopped working with the latest versions of many linux distros. When I looked into this it seems all the ones that don't work - including Ubuntu and Fedora use the same - probably current version of Xorg. What do I need to do about this? My offending hardware is Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
<gardier> At least that's what grep reports
<tseliot> gardier: this is not a support channel
<tseliot> please file a bug report about it and define what you mean by "it doesn't work" in that report
<cjwatson> unless you're able to hack X yourself, the best thing to do is to file a bug with as much information as you can; https://wiki.ubuntu.com/X/Debugging may help
<cjwatson> see also https://wiki.ubuntu.com/X/Reporting linked from that
<gardier> tseliot I mean X wont run from any medium live cd or installed
<gardier> Until O go back to an older version of xorg
<tseliot> gardier: please follow cjwatson's instructions
<gardier> So I report it to Ubuntu not Xorg?
<gardier> That's what I needed to know
<gardier> OK thanks tseliot and cjwatson
<tseliot> gradier: yes, report it against the package in Ubuntu. Then, if it's an upstream bug we'll add a link to the upstream report
<gardier> cheers
<gardier> seeya
<nijaba> hello.  I've just noticed that python-dialog is not in main.  Is there a good reason for it not to, or is it something I can file a MIR on with confidence?
<ScottK> nijaba: Why does it need to be in Main?
<nijaba> ScottK: just evaluating if I could base some code that would eventually end up there with this dep, but I am looking for any better reco
<dee> Hello. May I ask a question concerning compiling the Ubuntu Hardy kernel including the linux-ubuntu-modules? This is something I couldn't find anywhere and I hope that you developers have a hint.
<mkrufky> dont ask to ask -- just ask
<dee> :)
<dee> I want to build linux-ubuntu-modules for my kernel but do not know how to say that I have a own kernel. It always tries to get the sources from the standard kernel.
<mkrufky> so, my *unofficial* answer  (maybe some ubuntu folks will correct me if im wrong) .......
<mkrufky> L-U-M should work when build against the ubuntu kernel
<mkrufky> i dont know for sure that you can count on it working or building against a vanilla kernel
<mkrufky> s/"vanilla"/"anything other than an ubuntu"
<dee> Oh, it's not a vanilla-kernel. I just installed "linux-source" from repository
<dee> and then after extracting in /usr/src: sudo cp /boot/config-2.6.24-22 .config
<dee> sudo make-kpkg --initrd --revision i686moto binary
<dee> I suppose that this should be the default Ubuntu Kernel, isn't it?
<mkrufky> hmm, sounds like that is probably okay...
<mkrufky> dee i bet there is documentation on how to do this in the wiki somewhere
<mkrufky> i usually just do 'debuild' and it does everuything i need
<mkrufky> (wiki link in channel topic, btw)
<dee> yes the wiki is https://help.ubuntu.com/community/Kernel/Compile
<dee> unfortunately I then have the problem described above.
<cjwatson> #ubuntu-kernel would be better really
<dee> cjwatson: thanks. didn't know they have an own room. I will ask there. :)
<dee> thx & bye.
 * jdong things ~we-love-pitti needs a PPA :)
<jdong> you know... for wallpaper packs and screensavers.
<ScottK> jdong: If you're bored we could use some help with testing Kubuntu for Alpha 2 ....
<jdong> ooh perhaps later today I will be bored; I've got a long plane ride tomorrow too :)
<jdong> any particular area that needs attention?
<ScottK> jdong: It's pretty much all up for grabs http://iso.qa.ubuntu.com/qatracker/build/kubuntu/all - Some stuff's in progress, but the more the merrier.
<jdong> ScottK: cool, will do
<ScottK> Thanks.
<davmor2> whose working on jockey now it doesn't seem to be detecting my nvidia gfx card in jaunty alpha 2 test iso
<bryce> mdz, updated
<slangasek> bryce: ^^ that nvidia/jockey issue isn't the same as the bug you errataed, is it?
<bryce> slangasek: no, the issue that prompted the release note was that nvidia was causing X to get uninstalled
<slangasek> haha
<slangasek> so maybe jockey's smart enough to not do that?
<bryce> if it isn't, it'd be a nice feature to have.
<tseliot> slangasek, bryce: I could rebuild the nvidia packages so that the xorg abi is bumped. This however will only prevent Jockey from removing X. Users will still have to set the IgnoreABI option in the xorg.conf though
<bryce> tseliot: if all that is done, does -nvidia work properly?
<bryce> I'm really tempted to just recommend people not use the binary drivers, until we get new ABI-compatible blobs from them
<tseliot> bryce: tjaalton tried either 180 or 177 and it worked. I haven't installed Jaunty on my desktop pc
<tseliot> bryce: that's what I wanted to do
 * bryce nods
<tseliot> davmor2: if the modalias package can't be installed then jockey won't be able to detect your card.
<bryce> yeah, I think in the ranking of degrees of badness, uninstalling X is probably pretty high.  Even if it results in a misconfigured -nvidia it'd be best that it not do that
<bryce> tseliot, slangasek, tjaalton:  any way we could easily slip in a big fat warning/disclaimer for people using -nvidia?
<slangasek> slip it in where?
<bryce> like in jockey or the upgrader
<slangasek> not easily, for alpha-2
<davmor2> tseliot: do you want a bug report against it or is there one already?
<tseliot> davmor2: it's well know already
<tseliot> bryce, slangasek: we could drop the Recommends nvidia-common from jockey but this wouldn't solve the problem for current installations
<tseliot> and users will try to install the nvidia drivers anyway
<slangasek> tseliot: well-known to you, but having it in a bug report helps testers and gives us something to link to in the errata, e.g.
<tseliot> slangasek: it's this bug report:
<tseliot> https://bugs.launchpad.net/bugs/308410
<ubottu> Launchpad bug 308410 in nvidia-graphics-drivers-177 "Latest Xorg removes nvidia driver ... conflicting xserver-xorg-video-4" [Medium,Confirmed]
<slangasek> ok, cool
<tseliot> ;)
<ScottK> slangasek: Dunno how detailed your backscroll reading is so ....  Kubuntu live is no longer oversized and I got it added to the ISO tracker, so we're inprogress on testing.
<slangasek> ScottK: yep, caught at least that much, thanks :)
<cjwatson> but sounds like Kubuntu ubiquity's partitioning is screwed ...
<cjwatson> (Evan's working on it)
<ScottK> cjwatson: OK, so I guess focus on tests that don't need install from the LiveCD ...
<davmor2> cjwatson: only manual
<slangasek> evand: is that the same outstanding ubiquity issue you'd mentioned yesterday morning, or did that fix get uploaded and kubuntu manual partitioning is still broken?
<cjwatson> davmor2: right, sorry
<davmor2> cjwatson: install now on 32bit and 64 using guided whole drive
<davmor2> s/install/installing
<evand> slangasek: Yes
<davmor2> cjwatson: actually if ubiquity needs modifying would it be worth my time testing these installs or should I just hit alt's instead for now?
<slangasek> evand: yes to which part? :-)
<evand> Same bug :)
<ScottK> slangasek: MIRs for libio-pty-perl
<evand> davmor2: Automatic should work fine
<slangasek> ScottK: hmm?
<ScottK> .... and libipc-run-perl are approved, so if those get promoted, lintian should be installable again
<ScottK> Sorry, premature use of Enter.
<ScottK> slangasek: ^^
<slangasek> ah, great
<davmor2> evand: it is but I thought that if you are modifying ubiquity then the cd will need a re-roll
<slangasek> I'll have a look at those after I figure out whether I can safely demote libgc*mm*
<slangasek> er, libg*mm*
<slangasek> not without breaking cdrdao build-deps, sigh
<slangasek> crimsun: should pulesaudio's recommends: of paprefs (in universe) be dropped?
<evand> davmor2: I'm doubtful the changes I'm talking about will make it today.
<tedg> slangasek: Are you demoting libgtkmm?  (I'm confused)
<davmor2> no probs I'll carry on it'll be a smoke test any way if nothing else
<slangasek> crimsun: it's pulling a lot of GNOME C++ libs into the CD that we don't otherwise need
<slangasek> tedg: well, I'm trying to get libgconfmm, libglademm, libgnomeuimm off the CD, and thought dropping them to universe would be a quick fix if they aren't actually needed
<slangasek> I guess I could still do that as a workaround and just leave cdrdao unbuildable for a bit
<slangasek> but that's pretty fugly
<tedg> slangasek: Ah, okay.  Those are much less used that gtkmm.  I was a touch worried about gtkmm.
 * slangasek demotes libstdc++6
 * slangasek whistles
<tedg> Actually, I think the only one of those that's not deprecated is GConf.
<slangasek> they're in main purely as a matter of build-dependencies for a package that builds both main and universe bits
<bryce> ogra: classmate-tools still recommends xserver-xorg-video-i810 but that package is long gone.  Mind if I s/-i810/-intel/ in that package to clear the NBS?
 * Keybuk reads about fsnotify() and pinches himself to make sure he's not dreaming
<ion_> URL please
<Keybuk> lkml
<Keybuk> basically it's a backend for dnotify and inotify
<Keybuk> but with a new fanotify frontend as well
<Keybuk> the new frontend just provides you *all* filesystem events
<Keybuk> no need to walk a directory tree to add watches
<Keybuk> you can even intercept the access decision in userspace
<Keybuk> so can write a virus scanner for example, intercept the open() call
<Keybuk> check for viruses
<Keybuk> and if you find one, -EPERM it
<ScottK> Sounds like Dazuko modules just became obsolete then.
<ion_> Neat
<ScottK> slangasek: We're closing in on being able to remove libplasma2.  If you could attend to Bug #309420 when you have a moment, that would help.
<ubottu> Launchpad bug 309420 in plasmoid-quicklauncher "Please remove plasmoid-quicklauncher source and binary from Jaunty" [Medium,Confirmed] https://launchpad.net/bugs/309420
<Keybuk> reading through these, it really sounds like it's exactly what we've needed for ages to do both userspace content checking *and* userspace indexing
<emet> how about for 9.04 having a right click option in Nautilus for mounting ISOs by default? :D
<Keybuk> cjwatson1: we still don't have selinux udebs, right?
<cjwatson> Keybuk: shouldn't need them - udebs shouldn't be built with selinux support
<cjwatson> it doesn't really make any sense to have selinux in the installer
<Keybuk> that's kinda hard though
<slangasek> I thought Manoj had argued for exactly that?
<Keybuk> it means you have to, in your package
<Keybuk> 1) copy the entire source tree to another directory
<Keybuk> 2) rebuild with different options
<slangasek> hrm, or use vpath and skip 1) ? :)
<cjwatson> everyone else manages :)
<Keybuk> ohhh, vpath
<Keybuk> forgot about that
<bryce> slangasek: do you want a fix for a FBS of -vmmouse?
<bryce> slangasek: I think vmmouse will require further work to make it function properly with xserver 1.6, but at least this will enable it to build again.
<Keybuk> ugh
<Keybuk> the git->bzr thing didn't work out so well
<Keybuk> files are missing
<smahmood> Hi every1. Can you tell me, where to go, if i'm trying to find help with developing apps for ubuntu?
<bryce> smahmood: see topic
<smahmood> topic says, that topic is not app-development.. :-)
<smahmood> so I'm asking, if you know 'where to go'
<LaserJock> smahmood: I think that would depend on the type of app
<smahmood> LaserJock: first i would like to make a little desklet-like graphical app, that could perhaps access a MySQL-DB.
<LaserJock> smahmood: then perhaps http://live.gnome.org/GnomeIrcChannels might help?
<slangasek> bryce: indifferent for alpha-2; we've already kicked it out of -input-all for questions of installability
<bbs> two questions
<smahmood> LaserJock: yeah, that's good informations. thank you very much.
<bbs> 1) how do i pop up a notification service for a daemon in terms of a gui
<bbs> similar to growl in os x
<smahmood> just one last question....
<smahmood> LaserJock: is it helpful, to develop ubuntu first before developing apps for ubuntu?
<tjaalton> tseliot, bryce: I tested nvidia-glx-180 and -177. 180 worked with the ignoreABI option, 177 segfaulted
<LaserJock> smahmood: they're really 2 different things. you can do both individually
<LaserJock> smahmood: if you want to learn how to work on Ubuntu you might want to look at https://wiki.ubuntu.com/UbuntuDevelopment
<LaserJock> smahmood: but working on Ubuntu isn't really particularly helpful for you developing an app
<LaserJock> smahmood: in fact, you may find out you'd rather just work on Ubuntu and forget that app development stuff ;-)
<smahmood> LaserJock: ok, then i'm going to look at developing apps, i think. thank you very much.
<LaserJock> no problem
<smahmood> :-)
<bbs> how do i pop up a dialog box for a .deb for a terms of service agreement or a license agreemen
<bbs> t
<bbs> i'm using libnotify for the notificaiton i said earlier
<bbs> i have no idea how to roll debs
<bbs> or how to pop up this required box that points to terms of service and erquires a yes
<LaserJock> bbs: https://wiki.ubuntu.com/PackagingGuide and #ubuntu-motu are the places to learn how to create packages
<LaserJock> bbs: and usually we use something called debconf for TOS
<bbs> for installation
<LaserJock> bbs: in particular you could look at something like the sun-java5 package for an example
<bbs> ok -- sorry for the stupidity :/
<bbs> will this enable a GUI possibility
<LaserJock> bbs: it depends on what package manager the user uses mostly, but it's generally text within a GUI
<bbs> awesoem for synaptic then
<bbs> youg uys are the shit :)
<LaserJock> bbs: but it's currently the standard way to do these things
<LaserJock> bbs: install sun's java for a view of what it looks like
<bbs> LaserJock: i figured that *exact* package would be the place to look :)
<bbs> where can i find the specs for these?
<bbs> us.archive.ubuntu.org
<bbs> err .com
<LaserJock> bbs: are you on an Ubuntu machine?
<bbs> or do they exists soemwhere else... the specs themselves
<bbs> LaserJock: no i run a gentoo derivation
<bbs> :/
<bbs> i can be
<bryce> slangasek: ok that's probably for the best.  I went ahead and uploaded the build fix anyway.
<LaserJock> bbs: you can go to https://launchpad.net/ubuntu/jaunty/+source/sun-java6/6-11-0ubuntu1 and grab a couple files
<LaserJock> bbs: the full source package is the 3 files (.dsc, .diff.gz, and .orig.tar.gz)
<bbs> LaserJock: thanks a lot
<LaserJock> bbs: the .orig.tar.gz is upstream tarball, the .diff.gz is a diff that holds all our changes (including all the packaging stuff)
<LaserJock> bbs: basically you could on your gentoo machine, untar the .orig.tar.gz and apply the .diff
<LaserJock> bbs: you should end up with a source dir with a debian/ dir in it. the debian/ has all the packaging info
<bbs> LaserJock: awesoem
<bbs> i'll play now
<bbs> you have been very helpful
<bbs> i really appreciate it
<LaserJock> bbs: np, good luck
<LaserJock> bbs: if you need more packaging info #ubuntu-motu is a good channel
<bbs> ok thx
<bbs> i normally only play with src-based
<bbs> i appreciate you taking the time
<bbs> peace
<slangasek> ScottK: lintian, plasmoid-quicklauncher sorted
<ScottK> slangasek: Thanks.
<tseliot> Keybuk: I tested your patch (for screen-resolution-extra) and it works well
<fabbione> kirkland: ping?
<kirkland> fabbione: pong
<fabbione> kirkland: am I right you maintain mdadm in ubuntu now?
<kirkland> fabbione: hmm, not explicitly
<kirkland> fabbione: though i've done a fair amount of work in there lately
<fabbione> well the changelog is full with your name :)
<kirkland> fabbione: themuso has as well :-)
<kirkland> fabbione: guilty as charged :-)
<fabbione> root@gordian:~# mdadm --assemble /dev/md2 --force /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
<fabbione> mdadm: forcing event count in /dev/sdc1(2) from 20491 upto 20502
<fabbione> Segmentation fault
<fabbione> ^^ good bye 6TB of data
<fabbione> now
<fabbione> i'd really like to know if that segfault has been fixed
<fabbione> this is intrepid
<fabbione> (x86)
<kirkland> fabbione: hmm, new one on me
<kirkland> fabbione: is there a LP bug?
<fabbione> no idea.. ask me how much I care with all that data gone? :)
<kirkland> fabbione: raid5?
<fabbione> yes
<kirkland> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499643 ?
<ubottu> Debian bug 499643 in mdadm "Segmentation fault when attempting re-assembly of a failed RAID5 via "mdadm" [Normal,Closed]
<kirkland> Severity: grave
<fabbione> kirkland: you probably would like to have an SRU in intrepid
<kees> fta: I've got an update for flashplugin-nonfree which handles the 64bit plugin, do you want to look at it first, or should I just upload it?
<kirkland> fabbione: https://bugs.edge.launchpad.net/ubuntu/+source/mdadm/+bug/282492
<ubottu> Launchpad bug 282492 in mdadm "mdadm seg faults when forced to assemble array" [Critical,Triaged]
<kirkland> fabbione: i just linked that against the debian bug tracker, and marked critical
<kirkland> fabbione: i need to merge the mdadm package for Jaunty first
<Keybuk> cjwatson: do you think I'd be in trouble if I just did the packaging in git? :p
<kirkland> fabbione: and then i'll start the SRU process for intrepid
<fabbione> kirkland: ok thanks
<kirkland> fabbione: you're welcome to subscribe to that bug if you want updates
<kirkland> fabbione: thanks for bringing this to my attention
<fabbione> kirkland: no. I am happy to see that it's getting attention...
<fabbione> kirkland: i have enough spam from LP to even be able to purge the inbox
<kirkland> fabbione: yup ... that's the problem with raid.  you don't know something's wrong until the shit really hits the fan :-)
<fabbione> kirkland: not really.. a lot can be simulated with loops.. it's easy to make test cases :)
<cjwatson> Keybuk: obviously it's a shame when you have to, but you wouldn't be the first. Things ought to change when we have git imports in Launchpad
<davmor2> kirkland: you forgot from a great hight
<Keybuk> cjwatson: isn't that an "if" we have them?
<Keybuk> I'm concious that I've wasted over a day now trying to get this git repository into bzr
<Keybuk> git fast-export | git fast-import gives me exactly the same output as input
<cjwatson> it's very high up the LP Code priority list
<cjwatson> number two I think
<Keybuk> git fast-export | bzr fast-import gives me errors, and provided I skip them, a repository that has different files in it!
<cjwatson> how about I throw you my random patches?
<Keybuk> sure
<cjwatson> no guarantee they even apply to current trunk
<cjwatson> complete mishmash
<cjwatson> but I did do some stuff about directory creation/deletion
<Keybuk> sounds plausible
<Keybuk> the problems I've been having are when files and directories are deleted or added in the same commit
<cjwatson> right, you might get lucky with my changes then; if they help you I'll make an attempt to polish them up for submission
<cjwatson> unfortunately it's lumped in with the --file-ids-from stuff I was trying to do as well
<cjwatson> which I needed to construct a branch that was merged from another
<cjwatson> what did you need to do to get git fast-export to work? earlier you said it was broken
<Keybuk> oh, I just deleted the die() and replaced it with a null string :p
<Keybuk> "comment out lines of code that don't work"
<cjwatson> fun :)
<Keybuk> older versions of git didn't record who tagged
<Keybuk> git doesn't mind if that field is missing, and apparently bzr doesn't even look for it
<cjwatson> can you stick the resulting dump somewhere so that I can have a go at it later?
<Keybuk> http://people.ubuntu.com/~scott/udev.git-export.bz2
<cjwatson> ta
<Keybuk> -        if cmd.ref.startswith('refs/tags/'):
<Keybuk> +        if cmd.ref.startswith('refs/tags/') and cmd.from_ is not None:
<Keybuk>              self._set_tag(cmd.ref[len('refs/tags/'):], cmd.from_)
<Keybuk> yup
<Keybuk> made that fix myself ;)
<cjwatson> the real reason I hadn't submitted anything yet was that I'd got myself into a state where there was some code I needed to process some commits, but needed to be absent in order to process others
<cjwatson> I've forgotten the details just now though ...
<ScottK> slangasek: If kde4-style-bespin gets let out of binary New, then with the rebuilds I just uploaded, libplasma2 can be removed.
<Keybuk> cjwatson: your patches just move the error :-/
<Keybuk> oh, I see..
<Keybuk> the directory is empty but a file gets put back in in the same commit
<crimsun> slangasek: (RE: pulseaudio recommending paprefs) if suggests are not installed automatically, paprefs could be demoted; otherwise, it seems reasonable to drop it in the short run
<slangasek> yes, by definition Suggests are not to be installed automatically
<crimsun> slangasek: right, in that case just demoting paprefs to Suggests seems the way to go
<slangasek> spiff
<homunq> OK sorry to bother you here but I need expert help and I'm only going to ask this once. Please respond in pm if you can help me, I don't want to clog here. I am stuck in this konversation window. Can type and click here, can get to text-mode terminal, but can't switch windows. Seen this bug feisty, hardy, intrepid; kubuntu, xubuntu, ubuntu. Right now I'm in xubuntu (xfce). Looking for help using the terminal to diagnose. One person suggested it could
<homunq> be stuck keys, best theory so far.
<slangasek> kirkland, soren, mathiaz: is there any automated testing of server ISOs these days? (jaunty alpha-2 candidates have been up for a while)
<soren> slangasek: No :(
<slangasek> oh
<slangasek> could someone do a manual test of something, so I can bless the ISOs for alpha-2? :)
<soren> I'm in no condition to do testing.
<directhex> slangasek, how's the disk consumption?
<soren> I'd sign off on all sorts of stuff at this point.
<soren> :)
<kirkland> slangasek: i suppose i can, assuming testing in a kvm is okay
<kirkland> slangasek: mathiaz tends to handle this, but he's out on vaca
<slangasek> kirkland: kvm is perfectly fine
<slangasek> directhex: disks are all right-sized now; dropping the fortran deps from python-numpy was a big help
<kirkland> slangasek: http://cdimage.ubuntu.com/releases/jaunty/ ?
<slangasek> directhex: I think there's some more mono 1.0 stuff that could we could dispense with, but it's no longer urgent
<directhex> slangasek, well, yes, i can imagine
<slangasek> kirkland: http://iso.qa.ubuntu.com/qatracker/test/2194 , http://iso.qa.ubuntu.com/qatracker/test/2195
<directhex> slangasek, we'll continue to make improvements as time passes. meebey has a plan to save another good 2.5 meg from the main mono stack, but that one means the agony of NEW again
<directhex> slangasek, for now, i'm glad that alpha 2 seems to have come together reasonably well
<kirkland> slangasek: but the iso, is just the current builds at http://cdimage.ubuntu.com/ubuntu-server/daily/current/ ?
<slangasek> kirkland: that happens to be correct; I gave the direct links because sometimes it's the case that there's a newer ISO build than the one we're trying to test for an alpha
<kirkland> slangasek: pooh ... i *just* deleted those iso's
<kirkland> slangasek: i thought there was something newer than that :-P
<slangasek> no, they've been sitting untested for >24h :)
<kirkland> slangasek: well, unofficially, i did install from them this morning
<kirkland> slangasek: no record in isoqa, though
<slangasek> oh.  record it now? :)
<slangasek> fwiw, we're also still in need of testing of ubuntu desktop images, at least; I'm not sure I'm going to be able to get a useful test here, since I only have vmware available for v12n and vmmouse is DOA :)
<slangasek> directhex: btw, gnome-sharp2 had to go through NEW itself for a naming transition given the packages I pulled from experimental, I'm not sure what the transition plan for those needs to look like
<directhex> slangasek, i think slomo's the last one who poked those, so i don't know the full story
<slangasek> ok
<slangasek> I guess tomboy/f-spot mainly just need build-deps updated and then rebuilt, but I haven't tested yet
<directhex> slangasek, if the space concern for alpha2 is gone, i'd let things carry on as-is. we'll get onto those within pkg-mono ASAP, but ASAP doesn't necessarily mean "tonight" ;)
#ubuntu-devel 2008-12-19
<slangasek> directhex: right; except that now by touching gnome-sharp2, I've inadvertently added to the NBS list, which means it's also on my todo list :)
<directhex> don't forget gnome-desktop-sharp2 too!
<directhex> i have no idea why upstream split those
<kirkland> slangasek: iso coming down painfully slower than usual
<kirkland> any ideas why my usb mouse stopped working in jaunty after an update earlier this week?
<slangasek> usb mouse - no idea here
<Keybuk> weird, four files are now missing from my git import
<geubank4> 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
<geubank4> 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 * slangasek scratches his head
<directhex> 0!
<slangasek> right, I got that part :)
<NCommander> morning/evening/whenever slangasek and directhex
<directhex> NCommander, just gone midnight
<slangasek> NCommander: dawn of a new age, NCommander
<NCommander> according to my inbox, yes, yes it is :-P
<slangasek> oh hah, gnome-sharp2 is missing Replaces: on the old package names
<kirkland> slangasek: so those server cd's still have the "encrypt home" option
<kirkland> slangasek: which is going to fail miserably
<kirkland> slangasek: if a user select the "yes, encrypt my home" option, the user creation will fail
<kirkland> slangasek: i was under the impression that cjwatson had disabled that, in lieu of the missing kernel modules
<slangasek> kirkland: seems appropriate to treat that as errata, IMHO
<kirkland> slangasek: :-/  i'll go ahead and file a bug and prepare for the many duplicates
<slangasek> you should only get duplicates from those who use early alphas without reading the errata from the technical overview
<slangasek> I hope this is a small set :)
<directhex> always the optimist, steve
<calc> best buy is giving away bluray players when you buy any HDMI cable $79.99 or higher and 10 bluray movies (out of a set of 50)
<calc> and has a cable advertised next to it for $116.99
<calc> when you can get them for $4.99 easily
<kirkland> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/user-setup/+bug/309541
<ubottu> Launchpad bug 309541 in user-setup "Jaunty Alpha 2 Installation: encrypted home directory broken" [Critical,Triaged]
<kirkland> slangasek: details of that bug;  workaround too
<kirkland> slangasek: can you add that to the errata?
<kirkland> slangasek: okay, server iso testing posted for amd64 and i386
<slangasek> kirkland: woot, thanks.  Working on the errata now
 * kirkland -> back to work that requires far more brain cycles
<slangasek> evand: was there a bug number for the ongoing issues with ubiquity manual partitioning?
<RAOF> Hm.  It seems https://wiki.ubuntu.com/JauntyJackalope/TechnicalOverview is lying at the moment; while alpha 2 contains the DDX part of nouveau, synced from debian, we still need the kernel modules before it'll actually work.
<RAOF> I've got a dkms'd source package built for them; it just needs some debian/copyright love and a review.
<NCommander> slangasek, where are the CD build logs?
<slangasek> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ ?
<bryce> RAOF, ah okay - can you update the release notes accordingly
<RAOF> bryce: Certainly
<bryce> RAOF basically what I was going for is, "Yeah, -nouveau is in the archive, but don't expect it to work"
<NCommander> slangasek, thanks, for some reason, twm is on the Xubuntu CD O_O;
<RAOF> bryce: I think we _might_ want bugs, once the kernel module's in.  Upstream certainly doesn't mind bugs against the 2d component.
<slangasek> RAOF: please let me know when you're done making that change, I have other cleanup pending
<RAOF> Hm.  Do you still have the lock on that page?
<RAOF> slangasek: Do you want to finish your edits before I do mine?  The wiki's complaining you've still got the lock on that page.
<slangasek> RAOF: ignore my lock
<slangasek> moin and browser back buttons don't play nice
<RAOF> Heh.  Done.
<NCommander> slangasek, can you confirm a bug for me on the CD in /etc/apt/sources.list
<NCommander> universe seems to have gone missing ....
<slangasek> in xubuntu?
<NCommander> yeah
<NCommander> this is the line shipped:  deb cdrom:[Xubuntu 9.04 _Jaunty Jackalope_-Alpha i386 (20081218)/ jaunty main multiverse restricted
<slangasek> I don't have the xubuntu images to hand where I could inspect them
<NCommander> bah. Who do I file a bug with to get that fixed :-)?
<slangasek> is this the same xubuntu image that someone said 3 of 4 test cases passed just fine on for alpha-2?
<NCommander> The alternate passed
<NCommander> No one has reported success with desktop
<slangasek> you're talking about desktop?
<kirkland> slangasek: fyi, RAID seems busted in the installer
<slangasek> ok
<NCommander> slangasek, sorry that I wasn't clear
<slangasek> kirkland: bug + errata? :)
<kirkland> sladen: https://bugs.edge.launchpad.net/ubuntu/+source/partman-md/+bug/309555
<ubottu> Launchpad bug 309555 in partman-md "cannot create raid device" [High,New]
<slangasek> ack
<ScottK> slangasek: iso tracker says we aren't currently testing upgrades.  Is the intended?
<ashiswin> hello
<lool> morning
<slangasek> ScottK: I wasn't planning on focusing on upgrades yet given that upgrades are a moving target (generally happening via upgrade against the archive, not against ISOs)
<kirkland> cjwatson: kees: hey guys, i just merged mdadm for jaunty
<ScottK> slangasek: OK.  As long as it's by design.
<kirkland> cjwatson: kees: i haven't seen TheMuso around lately, who did the last merge
<kirkland> cjwatson: kees: the diff is exceptionally big, due to our udev methodology
<kirkland> cjwatson: kees: so I'd appreciate a good review
<kirkland> cjwatson: kees: importantly, this merge fixes a couple of really nasty, critical segfault issues, brought up by Fabbione earlier today
<kirkland> https://bugs.edge.launchpad.net/ubuntu/+source/mdadm/+bug/282492 for example
<ubottu> Launchpad bug 282492 in mdadm "mdadm seg faults when forced to assemble array" [Critical,Triaged]
<kirkland> cjwatson: kees: my work is available for review/sponsoring at http://people.ubuntu.com/~kirkland/mdadm/
<kirkland> cjwatson: kees: from a testing perspective, i've functionally tested only a small subset of the vast array of mdadm functionality
<kirkland> cjwatson: kees: raid1, booting, degraded, adding a disk, failing a disk
<kirkland> cjwatson: kees: it would take a week or more to test every mdadm option ... what's my due diligence, here?
<nixternal> kirkland: I may be able to lend a mdadm testing hand in the next few days if needed when I get back in the office...I am looking at mdadm as an option for one of our appliances in the future
<ScottK> slangasek: I think we're in reasonable shape for Kubuntu unless some ubiquity fixes magically appear.
<ScottK> For Alpha 2, I'm not sure we care.
 * slangasek nods
<ScottK> slangasek: We also have release notes for you  to link to in your release announcment.
<slangasek> URL?
<ScottK> https://wiki.kubuntu.org/JauntyJackalope/Alpha2/Kubuntu
<ScottK> Sorry.  Got distracted.
<ScottK> They aren't "Done", but they aren't horrible either.
<Keybuk> dh_install --sourcedir=debian/tmp-udeb -pudev-udeb
<Keybuk> dh_install: libvolume-id1 missing files (lib/libvolume_id.so.*), aborting
<Keybuk> err, but I didn't tell you to do that package
<ScottK> The iso tracker is reasonably well filled out http://iso.qa.ubuntu.com/qatracker/build/kubuntu/all - nixternal is currently doing more amd64 alternates.
<ScottK> slangasek: If it were up to me and everyone else was ready to go, I'd say Kubuntu is ready enough to pull the trigger.
<ScottK> slangasek: In the meantime, we'll keep testing.
<ScottK> JFTR I did a kubuntu-desktop upgrade in a chroot and it went smoothly.
<Keybuk> ah, apparently I did
<Keybuk> bloody build-arch: DH_OPTIONS=a
<nixternal> ScottK: I am going to pass it...retested w/o my goofy setup just fine
<ScottK> nixternal: Great.  Progress.
<nixternal> just gotta remember which partition is root for my goofy partition.... /dev/sda9 == (hd0,8)
<nixternal> ooh, pretty KDE 4 :)
<ScottK> slangasek: I'm off to bed, so good luck.
<kees> kirkland: cool, I will review and install it tomorrow.  generally, if it looks right and you think it's ready, it's good to upload.  we should always be careful, but glitches are okay -- it is the devel release, after all.  :)
<nixternal> who needs a stripe anyways :p
<lool> Hmm I'm afraid I need to raise a SRU regression, even if it's fairly minor
<lool> dpkgÂ : erreur de traitement de /var/cache/apt/archives/linux-libc-dev_2.6.27-11.21_amd64.deb (--unpack)Â : tentative de remplacement de Â«Â /usr/include/drm/drm_sarea.hÂ Â», qui appartient aussi au paquet libdrm-dev
<lool> Ah no, not promoted to updates yet
<lool> slangasek: Around?  we need to prevent linux from migrating to intrepid
<slangasek> oh gar, I was wondering about that bit of the changelog
<lool>   * synchronise our linux-libc-dev with the kernel userspace headers
<lool>     - LP: #300803
<slangasek> lool: please mark bug #300803 verification-failed
<ubottu> Launchpad bug 300803 in linux "linux-libc-dev: please include video/uvesafb.h" [Medium,Fix committed] https://launchpad.net/bugs/300803
<lool> I don't think this should have been done in intrpeid
<lool> slangasek: (done)
<slangasek> indeed not; but the changelog was terse and the upstream delta large, so it didn't get very close inspection on its way through unapproved
<lool> Touching the linux-libc-dev headers in a released distro doesn't make sense IMO
<lool> (didn't exactly understand the scope of the change until reading the full description in the bug)
<lool> slangasek: Also, this needs to go synchronized with a new meta, right?
<slangasek> yes
<dholbach> good morning
<lool> hey Daniel
<dholbach> hey lool :)
<Keybuk> hmm
<Keybuk> keep getting internal compiler errors
<Keybuk> only in an i386 chroot though
<NCommander> hey cjwatson_
<cjwatson> hmm, something apparently went wrong with the pygobject build for hardy-updates/sparc; it claims to be only for python 2.5, unlike other architectures
<cjwatson> this breaks ubiquity's build
<cjwatson> gar, timestamps caused an autotools regeneration
<cjwatson> bug 309674: hardy-updates regression
<ubottu> Launchpad bug 309674 in pygobject "python-gobject in hardy-updates on sparc misbuilt only for python2.5" [Critical,New] https://launchpad.net/bugs/309674
<cjwatson> (I've mailed the TB and others)
<ScottK> pitti: Is it your day for Archive duties?
<ScottK> pitti: If so, if you would accept kde4-style-bespin from binary New, then libplasma2 could be removed (NBS).
 * ScottK just noticed that kdeedu is also in binary New.
<NCommander> WOOO, My application moved!
<NCommander> ^NM
<directhex> NCommander, quick, apply to be project secretary!
<NCommander> Still no account
<NCommander> and I think you need to be in a year before you can apply
 * NCommander would be more interested in FTP assistant if I did anything
<NCommander> Must. Get. NEW. Queue. Empty
<directhex> yeah, greenlight my moon package plz kkthx
<evand> Does anyone know if gettext has a mechanism for handling a variable length list?  For example, "%s, %s, and %s" or "%s and %s" or "%s".
<fta> bryce, just attached the info you asked in bug 265029
<ubottu> Launchpad bug 265029 in xorg-server "no mouse/keyboard when using evdev and autologin in gdm" [Undecided,Incomplete] https://launchpad.net/bugs/265029
<kirkland> nixternal: awesome, thanks dude!
<kirkland> kees: cool, thanks.
<norsetto> kees, what do you think about bug 309732?
<ubottu> Launchpad bug 309732 in duma "duma FTBFS in intrepid/jaunty" [Undecided,New] https://launchpad.net/bugs/309732
 * EtienneG wonder: should mkfs create ext3 file system by default?
<ScottK> EtienneG: According to man mkfs, ext2 is the default.
<EtienneG> ScottK, I know, I am questioning why :)
<ScottK> At a guess either a developer picking a very conservative default or not updated in a long time.
<ScottK> Since it's util-linux, I'd just ask lamont`
<EtienneG> on the other hand, if it is the default in util-linux as shipped by upstream, no need to break people's assumption needlessly
<EtienneG> still, I get caught almost everytime I manually create an fs :(
<NCommander> hey ScottK
<ScottK> Heya NCommander.
<NCommander> how goes it?
<ScottK> I keep waiting for slangasek to pull the trigger on Alpha 2.  In the meantime I might get some actual $WORK done.
<NCommander> ScottK, same here
 * NCommander is working on fixing a rather nasty bug in dpkg
<NCommander> assuming my sid chroot will actually build this century
 * kirkland is wondering if an archive admin out there could nudge screen profiles through the queue, https://edge.launchpad.net/ubuntu/jaunty/+queue
<kirkland> pretty please :-)
 * RainCT hugs kirkland for creating the screen profiles :)
<kirkland> RainCT: \o/
<kees> norsetto: since duma was designed to overload those kinds of things, yeah, I think it's fine to pass -U_FORTIFY_SOURCE to it.
<LaserJock> asac: around?
<asac> LaserJock: on vac ;) whats up?
<LaserJock> asac: oh, sorry. was just a NM question
<LaserJock> asac: I can't seem to get NM to stick with a connection when I have eth0 and wifi available
<LaserJock> when I first get on the network I tell it to connect to the eth0 network, but then it starts connecting to various wifi networks I also have available
<LaserJock> is there some way to like prioritize them or something?
<ScottK-laptop> Airplane mode switch should do it.
<ScottK-laptop> ;-)
<cody-somerville> Remember how I said people's #1 complaint is updates break their computer? I'm on the phone with someone who says after the updates they're getting the following error message:
<cody-somerville> Aborted because of invalid compressed format (error=2)
<cody-somerville> Kernel Panic: SYNCING VFS, unable to mount root fs on unknown-block.
<asac> LaserJock: commonly complained feature ... only solution as of now is to disable wireless while being on wired
<LaserJock> asac: ok
<LaserJock> asac: I thought I had turned of "automatically connect" on the wifi networks but when I go into the editor it's checked
<LaserJock> asac: does NM keep that setting?
<asac> LaserJock: system connection?
<LaserJock> no
<asac> LaserJock: usually it works for me
<LaserJock> asac: ok, I'll play with it some more
<norsetto> kees, okki, thx
<rtg> evand: when is ext4 gonna appear as an option when installing server?
<ion_> When Itâs Readyâ¢ would be my guess. :-)
<cjwatson> rtg: do you think it's appropriate? it wouldn't be hard to add but I think we were waiting for the go from you guys ...
<cjwatson> oh and I suppose we need the userspace tools to be in place, I don't know if they are
 * ScottK knows jdong has been experimenting with ext4.
<rtg> cjwatson: The UDS discussion was that ext4 would be offered as an option on a disk formatted installed. dist-upgrades would continue with ext3
<cjwatson> somebody might need to hack minimal ext4 support into parted
<rtg> s/installed/install/
<cjwatson> dist-upgrades> yeah, I didn't doubt that
<rtg> ext3 will remain the default, but ext4 needs exercizing.
<evand> I'd love to have ext4 support for fallocate.
<cjwatson> doesn't appear to be any ext4 support in libparted. poo.
<rtg> indded, ext4 has a number of advantages.
<rtg> I'm interested in the trim instruction on SSDs
<slangasek> hmm, I thought fallocate was being implemented in ext3 as well?
<fta> kees, we planed to point to the partner repository instead of the adobe web site.
<evand> Is it?  I searched for such an article on Google hoping that it would be, but came up empty.  Perhaps my google-fu is lacking.
<evand> slangasek: link?
<calc> cjwatson: iirc the discussion mentioned the userspace tools were already in intrepid, but i'm sure they are still being updated as bugs are found ;-)
<slangasek> evand: some factoid I absorbed from skimming the samba-technical mailing list; it's possible I misunderstood
<evand> I'll just continue to hope then :)
<kees> fta: yeah, just got a brain-dump from asac
<cjwatson> calc: looks like e2fsprogs is but that nobody's worked on libparted at all
<fta> kees, if you're already done, well.. go ahead
<calc> cjwatson: ah ok
<ScottK> cody-somerville: What update caused that crash?
<ScottK> slangasek: Is there anything from Kubuntu holding you back from Alpha 2?
<slangasek> ScottK: no, I just have one more Ubuntu test failure to review and some publishing to do, then we should be there
<slangasek> though xubuntu alternate/amd64 is untested
<slangasek> cody-somerville, NCommander: either of you in a position to test that?
<ScottK> slangasek: Great.  Just wanted to make sure we weren't on the critical path.
<slangasek> sure, thanks for asking
<cody-somerville> slangasek, NCommander is
<ScottK> slangasek: Any chance of getting some binary New done? I'm particularly anxious for kde4-style-bespin and kde-edu.  Once kde4-style-bespin is out, libplasma2 can be removed.
<LaserJock> ScottK: why is kde-edu in NEW?
<slangasek> ScottK: yes, but not before I finish up alpha2
<ScottK> New/renamed biany, I assume.
<ScottK> biany/bianary
<ScottK> slangasek: Great.
<ScottK> LaserJock: What university are you at again?
<LaserJock> ScottK: University of Nevada
<hunger> Is somebody working on fixing X again in jaunty?
<ScottK> LaserJock: plasmoid-worldclock is the new package for kde-edu
<ScottK> LaserJock: ondrej from DPMT is moving to Reno to go to U of N, Reno.
<LaserJock> why is worldclock in KDE Edu?
<ScottK> Debian Python Modules Team (where you show up to talk matplotlib sometimes)
<ScottK> Dunno.  Upstream does as upstream wills.
<LaserJock> ScottK: oh, cool
 * directhex reckons that if the desktop experience team were hiring for some kind of GL programming position, they should really really look at the application from the gtkglarea maintainer
<directhex> if such a person had applied, anyway
<EvanCarroll-box2> Is there a channel for mirror maintence, the /fiesty/* is down at 91.189.88.40 80
<EvanCarroll-box2> does any one have an alt ip i can use?
<calc> EvanCarroll-box2: feisty is EOL its available at old-releases but should no longer be used in general
<EvanCarroll-box2> hrm, i thought it was supported for 1yr
<Nafallo> EvanCarroll-box2: 1.5 years...
<calc> EvanCarroll-box2: 18 months and it came out in apr 2007
<EvanCarroll-box2> oh shit. I'm a year behind the rest of the world.
<calc> EvanCarroll-box2: no longer supported as of Oct 2008
<calc> EvanCarroll-box2: current release is intrepid (8.10)
<EvanCarroll-box2> calc: yes, i know, i'm trying to trouble shoot intrepids cups-pdf which i think is bugged, and I wanted to have an older version for these issues..
<EvanCarroll-box2> I aparently overachived.
<EvanCarroll-box2> I wanted 8.04, i got 7.04
<calc> EvanCarroll-box2: heh
<calc> EvanCarroll-box2: well if you do need to go back that far you can get all releases at old-releases.ubuntu.com
<tedg> I love that on one mailing list is a discussion on how SRU is too easy and on the other there is a discussion on how it's too difficult.  :)
<ScottK> Well they both probably have their points.
<tedg> Yes, but you'd have to admit there is a certain amount of irony there.
<ScottK> OTOH, I'm still waiting to find out which update broke cody-somerville's friend's box
<ScottK> Totally
<cody-somerville> ScottK, I have no idea. I'm in Ontario and they're in New Brunswick
<cody-somerville> ScottK, they can't even boot their machine
<elmo> cody-somerville: surely they can use an older kernel?
<elmo> like vorlon said, that's just the kind of error that comes from update-initramfs being killed or breaking
<elmo> last time I saw it, a user had closed the upgrade window mid-run
<cody-somerville> elmo, Yes, I was going to give those directions but unfortunately the power is out now for her
<cody-somerville> (yea winter!)
<LaserJock> ScottK: I find it pretty hard to figure out which update breaks things
<LaserJock> if you're getting ~20 packages/update and you don't notice the breakage right away it's hard to pin down
<slangasek> elmo: hrm, our kernel postinsts should be robust against a mid-upgrade abort
<LaserJock> you know, I think I had one of those the other day
<slangasek> ("should" in both the "damn well oughta be" and "I believe they're designed correctly" senses)
<LaserJock> I was upgrading and my computer froze at updating the initramfs
<LaserJock> but I was able to reboot ok, and running dpkg --configure -a got everything in shape
<elmo> slangasek: unfortunately, I wasn't there to witness what they did, I only arrived in time to stop some helpful muppet from wiping their laptop as a "fix"
<slangasek> in the future I will have a consultancy firm named "Helpful Muppets"
<elmo> slangasek: ok, so checking my irc logs, it appears it use to be broken; keybuk claims to have fixed it, back in Feb or so
<slangasek> hmm
<elmo> or rather, TheMuso fixed it
<slangasek> bad that it was ever broken; the root design of initramfs-tools was always correct in this matter
<cjwatson> elmo: right, this was something we fixed as a hardy "feature" (i.e. err this is a scary bug let's call the fix a feature to make damn sure it gets scheduled)
<calc> if you know the upstream bug number of a bug can you search for that via lp somehow to find the ubuntu bug report
<calc> if they are already attached together
<calc> i have a new dupe that i can't find the original bug report for
<cjwatson> calc: yeah, there's a special redirect, let me look up how you get to it
<cjwatson> calc: there might be a better way to do this, but one way is https://bugs.launchpad.net/bugs/bugtrackers, follow the link to the bug tracker in question, and then append /BUGNUMBER to the URL
<cjwatson> if the bug is linked, it'll redirect you to the LP bug; otherwise it'll 404
<calc> cjwatson: cool, thanks :)
<bryce> slangasek: is archive still frozen for alpha-2, or can we start uploading post-alpha-2 stuff?
<slangasek> bryce: go ahead with uploading, I'm pushing the button now
<slangasek> (need to set up some kind of better pulley system to push the button for me)
<cjwatson> err. did somebody NBS the armel kernel without making sure there was a new one there?
<cjwatson> Please Don't Do That
<cjwatson> (and if somebody could score up https://launchpad.net/ubuntu/+source/linux/2.6.28-3.4/+build/811335, I'd appreciate it)
<cjwatson> (reason not to do it is that it means the kernel-overrides script won't be usable)
<slangasek> cjwatson: possibly my fault for not thinking through the implications for armel, sorry
<slangasek> rather, I appear to have assumed the NBS report's claim that the armel kernel flavors had no reverse-deps was an accurate indication of their state; do we not have a linux-meta on armel yet?
* slangasek changed the topic of #ubuntu-devel to: UDS: done, alpha-2 released, Archive: open, MoM running | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<NCommander> ScottK, ping?
<Caesar> slangasek: can you help out with #304907 at all?
<ScottK-palm> slangasek do you mind if I add a link to the Kubuntu release notes on the testing wiki page you referenced in the announcement?
<slangasek> ScottK: hmm, fail.  I noticed after sending the mail that I didn't link to the release notes anywhere; you can link to them from the TechnicalOverview wiki page, and I can ask for the contents to be copied to www.u.c
<slangasek> Caesar: I can start by helping to stare at it in disbelief
<slangasek> Caesar: this seems to be a package version newer than hardy, older than hardy-updates?
<slangasek> Caesar: hrm, still buggy, though.  I'm surprised, because I remember us having to fix a bug just like this already in hardy
<cr3> what page on wiki.ubuntu.com might provide insight on how upstream project collaborate their branches with the ubuntu-core-dev team? I'm looking at the UbuntuDevelopers page and I was expecting to see somekind of link to best practices for collaboration
<Hobbsee> cjwatson: rescored
<cr3> one of the questions I'm asking myself relating to collaboration is whether I should add the ubuntu-core-dev team to the trunk of my project or if I should create another branch specifically for the team.
<slangasek> cr3: perfectly reasonable to let ubuntu-core-dev create its own branch which is authoritative for the Ubuntu packaging
 * Hobbsee mutters something about mail as a result
<cr3> slangasek: is there a usual naming convention or recommendation for the branch used by the ubuntu-core-dev team/
<slangasek> Caesar: actually, I can't find any record of this particular file conflict existing in the Ubuntu archive
<cr3> slangasek: and, in launchpad, should the branch be under the ubuntu project or under the upstream project?
<slangasek> cr3: that would normally be created by the ubuntu-core-dev team itself
<slangasek> it would be a branch associated with the upstream project
<slangasek> but belonging to the ubuntu-core-dev
<slangasek> group
<slangasek> e.g., lp:~ubuntu-core-dev/grub/ubuntu
<StevenK> And if you're not in ubuntu-core-dev, you can request a merge into that branch
<cr3> slangasek: thanks for the explanation, everything is now clear :)
#ubuntu-devel 2008-12-20
<Hobbsee> anyone know if mark wants the screenshots himself, or if it's supposed to go to ubuntu-devel?
<slangasek> Hobbsee: to him directly
<slangasek> apparently, large attachments get stuck in the mod queue ;)
<Hobbsee> slangasek: yes, it appears so.
<Hobbsee> slangasek: i wonder why lots are emailing ubuntu-devel then
<slangasek> because sabdfl didn't specify
<Hobbsee> fricking hell, there's a lot of them...
<Hobbsee> it's only when i see stuff like this that i remember just how many people actively use and follow ubuntu
<wgrant> How many responses are there?
<Hobbsee> 1/4 down!
<wgrant> I don't see any... (are they all held?)
<Hobbsee> wgrant: there's 201 in the moderation queue, and most of them are this.
<Hobbsee> there was a bit of wine stuff, a bit of spam.
<wgrant> Oh dear.
 * directhex declares it sleep o'clock
<Hobbsee> wonder about a mass-rule for this.
<Hobbsee> OH< FUCK
 * Hobbsee cries
<wgrant> Ehem.
<wgrant> What went wrong?
<Hobbsee> i hit ctrl+c on listadmin :(
<wgrant> Ah, I love doing that.
<Hobbsee> when i'd gotten to 192
<Nafallo> what does that do?
<Hobbsee> terminates the program...
<Hobbsee> losing all the info you just gave it...
<Nafallo> ehrm. ouch.
 * Hobbsee attempts clearing the other bits out of the queue
<Nafallo> hey Baby :-)
<Baby> hi! :)
<chris062689> Is it just me, or does Alpha 2.. have a lot of regressions?
<chris062689> Just by reading the release notes, there seems to be a lot broken :D  (Not nessessarly a bad thing, for something to be made better, it first must brake)
<Caesar> slangasek: weird
<Caesar> So we have mysql-client-5.0 (for eg) in our snapshot of hardy-updates
<Hobbsee> chris062689: it's probably got regressions, and uds was last week, so people had less time on it
<Caesar> Granted, hardy-updates "head" is now at 5.0.51a-3ubuntu5.4
<Caesar> Sounds like a good excuse to do another release internally :-)
<Caesar> Sorry for wasting your time
<chris062689> True, but from reading the Release Notes, it doesn't appear very many "new" features are being added, sadly.
<wgrant> It is Alpha 2, and UDS was a week ago.
<wgrant> That is to be expected.
<wgrant> And it is Jaunty.
<chris062689> Ive been learning python a tad to see if I can't help the community any, when are we making the switch to having Python 3 applications being used in Ubuntu?  (Since arn't many Ubuntu-centric apps made in Python?)
<slangasek> Caesar: I guess updating won't fix this particular error because no Ubuntu version since dapper had this problem AFAICS, so there was no reason to fix it in -updates
<Caesar> slangasek: So are you saying hardy-updates never contained that version of mysql-{client,server}-5.0?
<Caesar> It doesn't look that way to me
<ScottK> slangasek: Added to the technical overview.  I've no idea if that's the best place or not.
<slangasek> Caesar: I'm saying that {dapper,feisty,gutsy,hardy} don't have an older version of mysql-{client,server}-5.0 that would have caused the hardy-updates version to need a Replaces:
<slangasek> Caesar: the version you're upgrading /from/ in that log isn't an Ubuntu version
<slangasek> (or at least, not a released one)
<slangasek> ScottK: ack
<mcasadevall> Can a buildd admin please rescore python-qt4 on armel?
<cody-somerville> NCommander, ah... why?
<cody-somerville> Its building?
<NCommander> It is?
<cody-somerville> yea
<NCommander> Well
<NCommander> Insert foot in mouth
<NCommander> Turn left
<ScottK> cody-somerville: It's armel.  Even if it's already building, it won't be fast enough
<cody-somerville> lol
<cody-somerville> http://www.youtube.com/watch?v=drI4BRMpaJM
 * ScottK reminds slangasek that he was going to binary New kde4-style-bespin and kde-edu after the Alpha was done ...
<ScottK> Then StevenK could have the pleasure of removing libplasma2.
<slangasek> ScottK: kde4-style-bespin accepted; kwin4-style-bespin has a malformatted long desc, wanna fix?
<ScottK> slangasek: I'll get smarter to fix it tomorrow (I'm very close to collapse here).
<slangasek> k
 * slangasek learns that NM breaks samba integration with dhclient \o/
<CarlFK> http://dpaste.com/100981/ aptitude segfault - should I post that to lp?
<lool> slangasek: That hwclock thingy wasn't happening on my computer so you're correct to assume it's hardware specific
<lool> slangasek: The symptom IIRC was complete system hang :)
<slangasek> lool: well, so someone who can reproduce it will need to do the test case verification for us
<lool> I think hwclock has two ways of querying the clock, and when the first way fails (because another hwclock is running) the second way is used and causes issues
<lool> slangasek: Yup; just wanted to let you know it wasn't a borken test case or a misunderstanding on your side
<lool> A bunch of people worked on this bug, I expect one of them will know; ISTR davidm's laptop had the issue
<slangasek> lool: ok.  given that this was targetted to 8.04.2, it would be appreciated if one of these people does the testing. :)
<lool> Hmm probably only OEM folks run 8.04.2
<ssam> does anyone know Brandon Perry's nick, and if he he around
<RainCT> is anyone here interested in dovecot?
 * NCommander has touched it ... unwillingly
<RainCT> heh  Well, I ask because I'm looking into merging it, but I'm not sure if I should :P
<RainCT> else I'll just forward everything I can to Debian
<StevenK> But dovecot is great!
<RainCT> Maybe, I've never used it. So, we do want 1.1.7 in Ubuntu, right?
<sebner> RainCT: if 1.1.7 = newest version ;P
 * RainCT evil-looks sebner :P
<soren> RainCT: Feel free to do the merge, yes.
<RainCT> Okay. One question:  - dh_installinit -pdovecot-common --init-script=dovecot -u"start 24 2 3 4 5 . stop 76 1 ."   + dh_installinit -pdovecot-common --init-script=dovecot -u"defaults 24"   Which of those do we want? (First is Ubuntu, 2nd is Debian)
<lool> asio fails to build on our buildd; it seems to be the kernel not being recent enough to run the testsuite; do we plan to upgrade the kernel in a near future?  Are the buildd running hardy alreadY?
<Hobbsee> RainCT: check with Keybuk (he's who originally made that change), but i'd guess you'd probably want to keep them
<Hobbsee> RainCT: looks like that's happened since edgy
<RainCT> Hobbsee: thanks
<Hobbsee> y/w
<maxb> Re the ia32-libs discussion on ubuntu-devel@ - no one seems to have raised the possibility of simply splitting up ia32-libs into common build-support and one package per included package. Am I missing something that makes this solution not a good one?
<oliver_g_> hi
<oliver_g_> under https://wiki.ubuntu.com/Bugs/HowToFix it says to run "dget -xu http://people.ubuntu.com/~dholbach/motu/xicc_0.2-2.dsc" to get the package source
<oliver_g_> but what is the URL for the .dsc file for another file? :-)
<oliver_g_> or can I just use apt-get source somepackage instead of dget?
<Hobbsee> you can use apt-get source
<Hobbsee> for something in a repository
<Hobbsee> otherwise you need to use dget on the .dsc
<oliver_g_> ok, thanks
<RainCT> doko__: ping
<RainCT> doko__: The dovecot version in Ubuntu has replaces for "dovecot-common (<< 1:1.1)", but Debian has it unversioned. Which of those is correct? (ref. LP: #254721, Debian bug #493798)
<ubottu> Debian bug 493798 in dovecot "missing replaces" [Serious,Closed] http://bugs.debian.org/493798
<Chipzz> Keybuk: ping
<oliver_g_> just to be sure: if the official Ubuntu package has version 2.24.1-0ubuntu1 , then my own package for PPA would be 2.24.1-0ubuntu2~ppa1 ?
<lool> Can't find what requires libio-socket-ssl-perl
<norsetto> lool: I find 27 rdepends and 12 reverse build depends in intrepid, but perhaps you want something else!?
<lool> In main
<lool> Why do we have it in main
<soren> lool: spamassassin`
<soren> ?
<lool> ah found it: devscripts recommends libwww-perl
<lool> soren: Nope, suggests I think
<soren> Well, spamassassin -> libwww-perl -> libio-socket-ssl-perl
<lool> ah no libwww-perl is a suggests as well
<soren> REally? Oh.
<lool> (I'm asking because this lib needs promotion of libnet-libidn-perl, but I wanted to make sure we still need the lib)
<soren> http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.jaunty/all
<soren> brb
<lool> Yeah I'm grepping it
<lool> Ok libnet-ldap-perl is a reason, but why libnet-ldap-perl
<cjwatson> slangasek: aha, that could be the problem (linux-meta/armel)
<cjwatson> Hobbsee: rescored> thanks
<slangasek> cjwatson: looks like there's a linux-meta on armel now, at least, so hopefully we won't have repeats
<lool> And that's in a seed, ok
<cjwatson> slangasek: linux/armel failing to build won't help I'm sure :(
<cjwatson> lool: there are files under rdepends/ which might be useful
<slangasek> hmm, doh
<cjwatson> e.g. http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.jaunty/rdepends/ALL/libio-socket-ssl-perl
<stgraber> bryce: why did you break my X ? :)
<RainCT> doko__: ping
<stgraber> bryce: I just did the X upgrade and after restarting X I just get a blank screen (backlight seems to be off) with no way to switch to a tty. That's on a Radeon HD2600 with the open source ati driver (on jaunty)
<bryce> stgraber: does setting XAA resolve it?
<stgraber> I just rebooted in failsafe, I'll try that
<stgraber> bryce: that's AccelMethod XAA in the Device section right ?
<bryce> yep
<bryce> for an explanation of the change see https://blueprints.edge.launchpad.net/ubuntu/+spec/radeon-change-xaa-to-exa
<stgraber> nah, didn't help ... I'll just install a ssh server so I won't have to reboot it all the time :)
<stgraber> mc fb loc is 00df00d0
<stgraber> X: symbol lookup error: /usr/lib/xorg/modules/drivers//radeon_drv.so: undefined symbol: exaDriverAlloc
<stgraber> that's with http://pastebin.com/f2c343bd8
<stgraber> bryce: any idea what's wrong ?
<bryce> stgraber: well the only change yesterday was to switch on EXA as the default
<bryce> stgraber: so my guess is that for whatever reason your system isn't working right with EXA - nothing surprising there, but a bug that should be reported and fixed
<bryce> stgraber: however more troubling is that if you specify XAA in your xorg.conf, that *should* revert back to the previous functionality
<bryce> stgraber: can you confirm in your Xorg.0.log that XAA is being used, not EXA?  That error message sounds like EXA is still getting used.
<stgraber> root@castiana:~# grep -i XAA /var/log/Xorg.0.log
<stgraber> (**) RADEON(0): Option "AccelMethod" "XAA"
<bryce> grep for EXA
<stgraber> root@castiana:~# grep EXA /var/log/Xorg.0.log
<stgraber> (==) RADEON(0): Not using accelerated EXA DownloadFromScreen hook
<bryce> hrm
<bryce> stgraber: I'm surprised you're not seeing lines like these -
<bryce> (==) RADEON(0): Using XAA acceleration architecture
<bryce> (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
<stgraber> yeah, me too. Before I did the upgrade (so, with the working driver) grepping for EXA or XAA didn't give me any result
<bryce> hmm
<stgraber> (that was without a xorg.conf, so nothing special there)
<bryce> stgraber: ok, next step is to revert to the -ati from alpha-2 and verify that resolves the issue.
<bryce> Also, please do ubuntu-bug xserver-xorg-video-ati once you have the system working, to file a bug.  Subscribe me to that bug.
 * bryce --> breakfast, bbl
<stgraber> bryce: ok, just reinstalled ubuntu5 and I can now start X with both EXA and XAA as AccelMethod ...
<lool> cjwatson: Uh I never poked at these, and it's exactly what I was looking for
<lool> cjwatson: thanks!
<stgraber> bryce: ubuntu-bug failed :)
<stgraber> bryce: Cannot open display ":0 -" and then "<urlopen error The read operation timed out>"
<stgraber> bryce: I'll leave this system on so I can ssh to it, just tell me what you need when you get back and I'll file a bug and attach the needed files
<stgraber> (and then will probably have to open a bug report against ubuntu-bug/apport ... :))
<ellis> <3
<ellis> Thanks for making such an awesome OS. Everything works. :D
<lool> cjwatson: I think you had a look at mbr a while ago; I found there's a new upstream version now and if I change debian/rules to make check instead of make check-TESTS, it passes now
<calc> er it looks like someone deleted the main page off the Ubuntu wiki
<iulian> Not again...
<iulian> It appears that the history is deleted as well.
<directhex> hax!
<iulian> It makes no sense.
#ubuntu-devel 2008-12-21
<cjwatson> lool: please go ahead and fix mbr if you know how - it's been on the guilt-inducing section of my to-do list for a while
<cjwatson> (and thanks)
<emgent> heya
<ScottK> If there's an archive admin with a spare moment, I'd appreciate it if you'd binary promote kdeedu-kvtml-data to make all of kdeedu installable again ...
<slangasek> done
<ScottK> slangasek: Thanks.
<cody-somerville> slangasek, do you want to review sion? ;]
 * ScottK thinks he has a clean KDE slat to hand back over to Riddell now that he's returned from vacation.
<slangasek> cody-somerville: no, that requires concentration and I have a headache
<cody-somerville> slangasek, I promise its nice and clean ;]
<cody-somerville> but alas, headaches suck
 * cody-somerville decides to merge valgrind.
<cody-somerville> hmm...
<cody-somerville> it doesn't seem possible to create an intrepid chroot
<cody-somerville>   gnupg: Depends: libcurl3-gnutls (>= 7.16.2-1) but it is not installed
<wgrant> cody-somerville: s/intrepid/jaunty/?
<cody-somerville> nope
<cody-somerville> intrepid
<wgrant> Erm.
<NCommander> o_o?
<wgrant> Something like that, yes...
<wgrant> Which pockets are enabled?
<NCommander> wgrant, chroot creation has no pockets enabled
<NCommander> debootstrap can't use them
<lool> cjwatson: oh I did push it
<lool> I only identified the minimal fix for i386 and amd64 so far, I'm not yet sure about the lpia one, but my 0.11 upload to my ppa also built on lpia, so it shouldn't be too hard
<NCommander> If I have two binary packages building out one source package, do I need conflict/replaces lines if I need to move a file from one binary package to another?
<ScottK> NCommander: Why wouldn't you?
<ebroder> You should probably have them Conflicts: other-pkg (<= version-where-you-moved-the-file)
<NCommander> thanks
 * NCommander had a brainfart
<ebroder> I can't remember if they replace each other as well or not
<lool> NCommander: just replaces, not conflicts
<lool> NCommander: If you move a file from a to b in new version 1.2-3 let b replace a (<< 1.2-3)
<lool> If you move all files / replace a package completely, then you want a conflicts to allow the package to select the package for removal, or a dummy package
<NCommander> Oh
<NCommander> lool, Replaces: python-qt4-dev (<< 4.4.2-3) - so that will do the trick?
<NCommander> (the package version is -3, replacing -2 and -2ubuntu1)
<ScottK> NCommander: I'd put a ~ on the end for it if gets backported.
<NCommander> ScottK, Replaces: python-qt4-dev (<< 4.4.2-3~)
<NCommander> Right?
<lool> NCommander: Yes
<ScottK> Yep
<NCommander> THanks lool and ScottK
<NCommander> We might have this fixed before the weekend is over
 * NCommander waves flag
<ScottK> Wave your flag AFTER it's fixed.
<ScottK> NCommander: You're going to get this uploaded to Debian and we sync it?
<NCommander> Depends how fast I can get a sponsor
<NCommander> If so, yes, if not, no
<NCommander> Its going into experimental so no one is going to freak about "OMG lenny frozen"
<lool> NCommander: What package is this?
<NCommander> python-qt4
<NCommander> I'm a member of the team that owns it in Debian
<lool> Oh it's DPMT
<NCommander> bingo
<lool> I guess I can sponsor that then
<NCommander> I need to do a final test build and make sure my changes actually work, so it may be awhile
<NCommander> (its building now)
<lool> Is it committed?
<lool> Cause I don't see it in trunk
<NCommander> No
<NCommander> Because ATM its not quite working right :-)
<lool> Argh the reason mbr/lpia built in my ppa is because ppas are built on amd64 hosts in a lpia chroot
<mcasadevall> lool, sorry about that
<mcasadevall> this laptop is a little unstable when I'm running a KVM :-/
<ScottK> mcasadevall: You moved pyqtconfig from -dev to the main package?
<mcasadevall> lool, committed
 * mcasadevall blinks
<ScottK> CIA bot is handy.
<ScottK> Ah, I'm pretty sure that's not right.
<NCommander> ScottK, and making the dev package arch any is worse since thats the only arch dependent files in it
<ScottK> Hmmm.
 * NCommander kicks xchat
<NCommander> Making dev arch any is a bad idea, and I don't think making yet another package for two files is a great idea either ...
 * ScottK does svn up and looks
<lool> NCommander: Your rules has spaces instead of tabs
<lool> around "echo yes is needed"
<lool> I don't parse that echo yes is needed line BTW
<NCommander> lool, I didn't add that
<ScottK> It's all three of the lines of that comment.
<lool> ScottK: And further lines below
<NCommander> lool, I'll fix them, I'm just noting the original committer is who added them
<lool> ack
<lool> So I'm not too hot on this arch specific stuff, it doesn't really make sense to me
<NCommander> lool, whats the problem?
<NCommander> The file I moved into python-qt4 can be different on platforms without a FPU or ARM
<NCommander> (it contains the "handle float qreal code" switch)
<lool> NCommander: Looking at this file, it looks quite arch specific, but the whole concept less so
<lool> NCommander: Sorry but can you remimd me how python-qt4 fits in our problem?  It's a dep of sip?
<NCommander> It's a dependency of kde4bindings
<NCommander> And also controls sip's configuration file
<NCommander> er
<NCommander> controls sip's configuration
<NCommander> i.e., what options should be enabled
<lool> What I'm unsure about is whether it's ok to rely on arch specific differences for this
<NCommander> huh?
<NCommander> Currently kde4bindings in the archive properly parsers this, so once python-qt4 is fixed, we just need to retry the build
<lool> NCommander: At a high level the problem is that arch specific constraints are not taken into account by a code generation tool; this code generation tool may be run on any arch and should produce code which builds on all arches; if you agree with this, then surely you'll agree that the code generation tool shouldn't rely on arch specific changes
<NCommander> lool, ?
<lool> What part do you "?" on?
<NCommander> Most/all packages that use sip use it to generate C code on the fly from sip input files, similar to flex or bison, If a package is reused the same C code on multiple architectures, that's a bad thing
<lool> NCommander: I'm not sure it's a bad thing
<lool> Why would code generation be arch specific instead of generating portable code?
<NCommander> Well, the other thing about sip which drives me insane is that it doesn't set any default configuration settings
<lool> You can actually ship generated files which you prepared on arch a for people using other arches
<NCommander> Any package that uses sip must parse sip options and then set then by manual
<lool> Hold on, one problem at a time
<NCommander> lool, sip generates code for bindings. In some cases, this code is arch specific, i.e, Qt on ARM uses float over double
<NCommander> right
<lool> So does sip explicitely forbid generating bindings for arm on other arches or vice-versa?
<NCommander> Nope. It generates invalid code which leads to an FTBFS. This entire bindings issue was caused by the fact that KDE ignored sips options (and the fact that the options file itself didn't properly include the necessary flags)
<NCommander> other code generation utilities like flex though are the same way; the code it generates isn't promised to be arch independent. I know code generated on ia64 and other architectures thats true (I ran into an RC bug in Debian which this was the case)
<lool> NCommander: I'm trying to find a definitive statement about sip's arch (in)compatibility promise
 * NCommander makes a mental note to replace the wireless router at his mom's
<NCommander> lool, sorry, the net hiccuped, what was the last thing you said?
<NCommander> Well, its more the nature of the libraries than sip itself.
<NCommander> Qt has a different API on different architectures
<NCommander> Now that API is similar enough that in most cases that you don't see any difference
<lool> NCommander: Well in our case Qt didn't have a different API
<NCommander> What's our case? O_o?
<lool> qreal :)
<NCommander> That's still the case
<NCommander> I didn't change that
<NCommander> Oh
 * NCommander gets it
<lool> But then even would Qt have different APIs on different arches (which I hope it doesn't), it wouldn't prevent SIP from generating portable code
<NCommander> It would if you have architecture dependent bits in the bindings code that check for the presence of a feature in sip
<NCommander> sip wasn't passing the all important configuration flag during compiles to tell it to turn on said feature
<lool> Ok, so you're saying SIP doesn't have the same features on different arches?
<NCommander> No, I'm not saying that
<NCommander> What was missing was the C equivelent to an #ifdef
<NCommander> pyqtconfig has the list of ifdef's programs using sip should use
<NCommander> (sip itself doesn't read pyqtconfig, it depends on the build system to parse it and give it the right options)
<lool> I'm not convinced; what I see is that there was a runtime check to use a conversion routine; this was made into a runtime + build time check to use it
<NCommander> sip has no way of knowing the size of qreal at runtime
<NCommander> unless you want it to do configuration tests on every run
<lool> NCommander: Why can't sip so if (sizeof (qreal) != sizeof (double)) in generated code?
<lool> Or at least ifdef
<NCommander> The problem with the generated code was it wasn't matching prototypes in Qt
<NCommander> Essentially
<lool> Besides, #if defined(QT_NO_FPU) || defined(QT_ARCH_ARM) || defined(QT_ARCH_WINDOWSCE) seems like a bad test to me
<NCommander> lool, that's the test used internally in Qt to switch qreal to float
<NCommander> That was a copy and paste job :-)
<lool> This test for arches instead of testing for testing for qreal being double or not
<lool> NCommander: I know, and that's why it's wrong
<lool> -"for testing" in the above
<lool> NCommander: I can tell you for sure the #if is wrong; for the rest of the discussion I'm probably lacking a good understanding of what's going on, so I'm afraid I need to defer to someone else or postpone me looking at this right now
<lool> ScottK: Did you follow the sip/kde4bindings/qreal etc. stories; would you be interested in reviewing it?  I'm running out of time this morning
<lool> And don't feel like I have enough understanding
<ScottK> lool: I'm just about to go to bed myself.
<NCommander> lool, I don't see why using the same ifdef's used by Qt in QtCore.hpp is a bad thing
<lool> ScottK: Would you in general feel confident reviewing this?
<lool> I personally feel I need to learn tons about it first
<ScottK> lool: No.  I've been depending on NCommander's expertise a lot for my condidence in uploading.
<ScottK> condidence/confidence.
<lool> NCommander: It's a bad thing because it's qt's internal decision; it doesn't regard you how people set qreal to double or float based on the time of the day or the weather outside :)
<NCommander> lool, I've bugged upstream about fixing the broken configure test so hopefully this will be properly fixed in a soonish upstream release
<NCommander> lool, fair enough. I did try doing that, but the way sip runs the test causes it to always consider qreal == double
<NCommander> Probably a header was missing
<jcastro> hi everyone
<jcastro> lool: you end up with an x200s?
<lool> jcastro: I wish so, but no nearby stock and didn't want to deliver to the hotel  :-/
<jcastro> lool: I mean eventually
<lool> jcastro: It's my preferred option so far, definitely!
<jcastro> :D
<lool> I didn't quite plan how to buy it yet though
<jcastro> I didn't have the money
<lool> jcastro: For your own laptop?  Then how did you do it?
<lool> You sold your soul I'm sure
<jcastro> I didn't have the money for an x200s, had to get the x200
<lool> Ah
<NCommander> What's the x200(s)?
<lool> thinkpads
<jcastro> the s has an lcd backlight
<lool> Exactly
<NCommander> what's so special about them?
<jcastro> higher rez screen
<lool> It has the cool things in the x300, but not the crazy things
<lool> Like no SSD and no UWB or what not
<jcastro> the ssd is an option, they're just kind of a rip off
<lool> Exactly why it was problematic for me to buy a x300: they force the SSD on you
<jcastro> nod
<jcastro> fosdem
<lool> Yeah \o/
<lool> jcastro: You booked yet?
<jcastro> oops, that's not my google window
<jcastro> I am looking at it
<lool> jcastro: We should aim for the same hotel
 * Treenaks is thinking of going for one day
<lool> mvo knows the name
<jcastro> after last year it was so busy that I don't think I would want to make the trip to fosdem
<jcastro> but this year it's after a canonical sprint so I think on the way back is a good investment
<lool> NCommander: So to close the topic; either I or somebody else need to sit down and see what is currently arch specific and what would become arch specific
 * wgrant was thinking of getting an X200, but it only has a TrackPoint :(
<jcastro> wgrant: that's a feature. :D
<lool> NCommander: Ideally, nothing is arch specific except qt
 * wgrant is now leaning toward a T400.
<NCommander> lool, I see
<NCommander> lool, I'll see if I can find the other python-qt4 maintainer and stick our headers together or something
<jcastro> NCommander: btw I would like a feedback mail from you, your first UDS, I would like your feedback
<lool> NCommander: Say, sip itself, sip's output, qt, sip's output on arch foo etc.
<NCommander> jcastro, send me a form
 * NCommander nods
<jcastro> NCommander: I have no forms, I just want your raw feedback. It can be like "Jorge, I hate your guts ..."
<NCommander> All and all, I had a good time at UDS, although I disliked having to commute to the Googleplex, and the 128 user limit on the wifi :-)
<lool> jcastro: I'm personally looking at LH4646 for Berlin -> Brussels; the 6th in the afternoon
<jcastro> yeah well, join the club. :D
<Treenaks> NCommander: I just returned home yesterday, saw a lot in SF last week
<ScottK> jcastro: I'll toss you a bit of feedback: I didn't like the brainstorm based sponsorship process a bit.
<jcastro> ScottK: already on the list.
<jcastro> ScottK: I know exactly what you mean
<ScottK> OK.
<ScottK> jcastro: It's not the only reason I didn't ask for sponsorship this time, but it's on the list.
<bryce> ScottK, actually I sort of liked it; in past UDS's it always seemed like canonical employees ran all the sessions, and it was really nice to have some that were driven by community members
<bryce> if it were opt-in maybe it would have been better received... like have the choice of either being crew, or doing a blueprint
<ScottK> bryce: I think that's good, but it doesn't need brainstorm for that.  In the end UDS is about working on specs, so the brainstorm bit just seemed like more paperwork.
<ScottK> Right.  In then end I wrote specs and didn't go.  It seems odd to have writing a spec count for less than brainstorm at a UDS.
<ScottK> FWIW, I think in Server Team at Prague there was a good mix between Canonical and the Community about who was leading the discussions.
<bryce> oh that could be; for prague I did spend most sessions out hacking with timo in the main conf room
<NCommander> ScottK, what happened to sleep :-)
<ScottK> Remembered I told my wife I'd do something ....
<NCommander> ScottK, ah
<NCommander> ScottK, so don't ask you for sponsoring stuff?
<ScottK> Not unless it's really simple.
<ScottK> NCommander: Don't forget you still owe a fetchmail merge.
<NCommander> :-P
 * popey tries gwibber from jcastros ppa
<ScottK> NCommander: BTW, I did a run through Intrepid backports today.  Then I took a look at Hardy and got overwhelmed.  I think it's due for another one of your treatments.
<ebroder> ScottK - thanks for that, by the way :)
<NCommander> yeah, I saw that
<ScottK> ebroder: You're welcome.
<zyga> hello
<zyga> what is the best way of getting fixes/updates into current ubuntu release
<zyga> I want to make Samsung NC10 3G modem usable out-of-the box on 8.10
<zyga> I'm currently working on packaging patches for NetworkManage
<zyga> I'm working based on my own nc10 experience and ubuntu community wiki
<Hobbsee> damn wine.
<Nafallo> Hobbsee: too much of the good ey? ;-)
<Hobbsee> Nafallo: well, it crashed my X when i don't use it as a separate virtual desktop, and then rearranges all my panel icons for me
<Nafallo> ah. WINE.
<Hobbsee> yes
<StevenK> "Feature"
<StevenK> For the authentic Windows experience
<Hobbsee> windows doesn't reorder the icons
<StevenK> The order of icons in the status area is arbitary, and I've had those re-ordered out from under me
<Hobbsee> i was meaning the top panel
<StevenK> Windows doesn't have one of those :-)
<lool> doko_: Around?
<lool> doko_: On armel, /usr/lib/gcc/arm-linux-gnueabi/4.3/libgcc.a has the __sync_* atomic symbols
<lool> But not on my x86
<lool> It seems to confuse the djvulibre build which uses these
<luisbg> jcastro, http://img.ffffound.com/static-data/assets/6/9f6d91778c232d87122e845f5a5e109289bd69d1_m.jpg
<jcastro> luisbg: hahaha, perfect.
<luisbg> jcastro, you need to have a tshirt made with this: http://img.ffffound.com/static-data/assets/6/58994c18e6712d014f1cdb4d853b969a7d4805fa_m.jpg
<luisbg> and that is my dose of awesome of today :)
<ramvi> When setting up an ubuntu repository, how do I do it without having the source / .changes files? Say I wanted a repo with skype and picasa..
<DRebellion> ramvi, skype already have thier own repo
<ramvi> DRebellion:  want my own
<crimsun> ramvi: see dpkg-scanpackages(1)
<directhex> apt-ftparchive?
<emgent> UTU up again.
<fta> bryce, the last X upgrade is killing me. X starts fine but after a while i get a second mouse cursor, then shortly after that, X crashes. 4 times in the last 24h.
<fta> bryce, it seems like hal is reporting two mouses, one "Macintosh mouse" which i don't have and one "Microsoft Microsoft IntelliMouse? Optical" which i have
<nhandler> Glad to hear that emgent
<alex_21> Hey all, how can I add an installer script to an alternate cd, and force it to use a CLI option rather than GuI option for the system
<alex_21> ?
<alex_21> Please
 * WelshDragon test
 * WelshDragon asd
<alex_21> Hey all, how can I add an installer script to an alternate cd, and force it to use a CLI option rather than GuI option for the system
<directhex> easily enough
<directhex> the "alternate cd" uses debian-installer, which is trivially coerced into doing things
<directhex> generally, you want a "preseed file" which is used by the installer, and contains (amongst other things) a list of packages to install, and a script to run at the end of installation
<alex_21> A preseed file
#ubuntu-devel 2009-12-14
<Incubuss> Say I was a lowly CS student who knew Python, (lol)Java and a little bit of C, what would be my best approach for getting involved?
<cjwatson> start with http://wiki.ubuntu.com/ContributeToUbuntu and http://wiki.ubuntu.com/UbuntuDevelopment
<cjwatson> find things that interest you personally
<Incubuss> I'm assuming Java will be next to useless for just about everything? :P
<cjwatson> I generally recommend against making assumptions before investigating :)
<cjwatson> it's probably not the first language I'd recommend that Ubuntu developers learn, but it is used in some areas. Honestly, the ability to pick up new things is much more important than happening to know some languages up-front.
<cjwatson> decent CS courses ought to teach the ability to learn, as well as just languages
<cjwatson> and after you've learnt three languages, the fourth is easier, etc.
<jdong> those still sound like CE courses to me, but that's a minor nitpick :)
<Incubuss> Yeah, thats half the reason I chose Glasgow for CS was their emphasis on being able to pick op different languages fast
<cjwatson> naming varies :)
<RAOF> And their haskell compiler, presumably :)
<Incubuss> Just happen to be stuck in the year where we do all Java at the moment :P
<cjwatson> Java's used in (e.g.) the cloud computing bits we're using for the Ubuntu Enterprise Cloud
<cjwatson> I expect that on average Python and C will be more useful though
<Incubuss> We use Haskell for some of next year, I'm looking forward to it
<jdong> and general knowledge of UNIX shell scripting and the likes
<RAOF> Makefile syntax!
<jdong> but yeah, most important is picking up new things quickly
<Incubuss> Yeah, I'm quite happy working in Python, not so much Java
<Incubuss> C sorry
<cjwatson> if you find something that interests you, that's probably the single most effective way to learn new languages if necessary anyway
<jdong> O_O ok maybe my globber is a bit too inductive...
<Incubuss> I did a C under Linux course this semester although it was run in the Physics department so they shoved plenty at us but none if it very in depth
<jdong>  /** krwlmix is not what I had in mind for dmesg's auto profile...
<cjwatson> I pretty much taught myself Unix and Perl during college because it was useful for some things I wanted to build for myself
<directhex> we had a first-year module on "unix systems administration"
<maco> first year?? my school it's "must be senior or grad student or already know unix & c"
<maco> turns out that last "or" means the grad students don't know what they're doing at all and hold up the undergrads who do
<jdong> heh we didn't have any IT-related courses at all
<cjwatson> we had enough-Unix-to-get-you-by in first year, which I think probably covered more than usual for a course with that kind of remit
<directhex> our comsci labs were 50-50 windows and unix, and most of us learnt in first year which were the better systems
<directhex> which kinda forced some learning
<maco> our acm chapter has started teaching enough-unix-to-get-you-by workshops each semester for first years
<maco> because they're not going to learn it anywhere else in the curriculum and will be rather confused in OS class when they have to unpack tarballs and copy files and all sorts of terribly hard things like that ;)
<cjwatson> I think I was still before anyone but a fairly small percentage of geeks had their own Linux systems. Nowadays I'm sure it's different
<maco> i'm trying to push one of the first years at my school in the motu direction
<cjwatson> the purpose of enough-Unix-to-get-you-by used to be "how to use the faculty-provided Unix teaching systems"
 * directhex considers FOSDEM
<Incubuss> We do Python in 1st Year under Windows, 2nd Year Java (Windows) then 3rd & 4th year we do a host of languages on Linux machines
<maco> the workshop i teach for acm is a bit off the unix thing. i do LaTeX.  someone else handles bash and another does vim. there's demand for eclipse now
<maco> ah our whole time, all code is required to work on Solaris. i think they finally upgraded the machine from sol 8 to sol 10
<cjwatson> the first Debian package I ever built came out of being fed up with the way Java classes were run; I never actually did get around to distributing that although a project that grew out of it is now used by various bits of Debian
<cjwatson> but I've been fortunate enough never to really have had to use Java in anger since university, so other priorities took over
<directhex> uni taught me to hate java ^_^
<maco> java is why i cant do python
<Incubuss> Java doesn't seem as bad as I was expecting with all the hate it gets, I'm not a fan of it but I think for teaching OO its quite a good language
<Incubuss> I although the more I work worth it the more I get fed up of it
<DrManhattan> what's the deal with the intel video driver? The performance is horrible compared to fedora 12
<pitti> Good morning
<pitti> micahg: just ask :)
<micahg> hi pitti, about the case sensitive package names in apport
<pitti> slangasek: pm-utils-powersave-policy is in source NEW right now (it's trivial, but I didn't ping anyone about it yet)
<micahg> I figure that might be an easy thing and help new users
<micahg> I know in ubuntu/debian all package names are lowercase, but regular users might not get this
<AnAnt> Hello, sorry to ask here , but, who should we go to if someone is flooding #ubuntu ?
<AnAnt> nevermind, someone solved it
<pitti> slangasek: right now it only enables sata link power on >= 1 GB RAM, and only sets "min_power", perhaps it should set medium_power on low-mem systems
<pitti> fta: doko_ fixed it in lucid now, still on the radar
<StevenK> Morning pitti
<StevenK> pitti: I've uploaded a NEW netbook-meta, which is effectively a copy of unr-meta, shall I just wave it through and into main?
<pitti> StevenK: ah, for the renaming? sure
<StevenK> pitti: It's a rename, and a few bits of fluff, since platform.lucid changed
<dholbach> good morning
<micahg> pitti: ?
<pitti> micahg: hm, so you think there are users who don't know about our packaging structure, then manage to find the package name of the problem that affects them, but then somehow manage to miscapitalize it?
<micahg> pitti: if someone uses software center to install a package, they might not notice the capitalization as it'll display with the proper name, not the pacakge name
<micahg> like the example of gtk-recordMyDesktop
<micahg> another one might be Abiword
<micahg> "we" know the package name is the lower case version, but a windows user coming over to Ubuntu might not get this
<micahg> I figured running the python equivalent of strtolower on the package name would be easy enough and possible help new users
<micahg> pitti: ^^^
 * nixternal hugs dholbach 
 * dholbach hugs nixternal back
<poolie> hi, could someone give feedback on my requested sru in https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/437626
<ubottu> Ubuntu bug 437626 in bzr "[sru] exceptions.AssertionError: second push failed to complete a fetch set" [Undecided,Confirmed]
<poolie> is any more information needed to let it be reviewed?
<micahg> poolie: ubuntu-motu would probably be a better place for SRU review
<wgrant> micahg: Not for bzr, which is in main.
<poolie> ok, thanks (sorry if appropriate)
<micahg> oh
<micahg> my apologies poolie
<micahg> this is the right place
<micahg> wgrant: I though -motu was the place for package discussion in general
<poolie> at this point i'd just appreciate a quick scan to say whether i should be providing any more information to allow an sru review to proceed
<wgrant> micahg: Packag*ing* discussion, perhaps.
<persia> micahg: -motu is the place for discussion about universe packages, which often includes packages not yet in universe, hence packaging.
<micahg> persia: wgrant: from the channel info: #ubuntu-devel is: Lucid Alpha 1 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) |
<persia> poolie: I usually see the bug description modified to include specific test cases to aid review that the bug is fixed by the update.
<persia> micahg: Indeed.  And when upstream comes in with an update to a package in Ubuntu main, that's part of development of Ubuntu.
<micahg> persia: maybe someone should modify it to say main package dev in the description then...
<persia> micahg: The topic has worked for us through now.  I suppose someone could change it.
<micahg> persia: ok...well, now I know at least :)
<poolie> persia: so summarizing the reproduction recipe there would help?
 * persia digs up the current set of docs for reference
<persia> poolie: Yeah.  According to https://wiki.ubuntu.com/StableReleaseUpdates the description is supposed to be modified to include the impact, a description of the fix, pointer to the patch, a test case, and discussion of regression potential.  But I suspect you're currently blocked on getting it sponsored rather than being blocked on the SRU team accepting it into proposed.
<pitti> poolie: just went through the SRU bugmail, looking
<pitti> poolie: are there other LP bugs which get fixed by this update? If so, they should be included  into the changelog
<pitti> (the upstream changelog mentions a few)
<pitti> poolie: it doesn't hurt to add a short description of the changes in debian/changelog
<poolie> we should mention all of them?
<poolie> ok
<pitti> poolie: right, so then we can ask their reporters for testing the update
<poolie> ok
<poolie> anything else?
<pitti> poolie: the descriptions of all affected bugs should be clear and preferably be reproducible (haven't checked that)
<poolie> ok
<poolie> pitti, thanks, new diff uploaded
<poolie> i'll mention this in our process too
<pitti> thanks
<poolie> https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/16117 in case you have any comments
<chrisccoulson> superm1 - i just saw bug 496423. does GDM have an interface for shutting down / rebooting? gnome-session just uses consolekit...
<ubottu> Launchpad bug 496423 in xfce4-session "XFCE4-Session doesn't use the GDM interface to shutdown or reboot" [Undecided,New] https://launchpad.net/bugs/496423
<superm1> chrisccoulson, i thought I saw all this stuff about grabbing GDM cookies and what not in gnome-session code as I was walking around it trying to debug a different bug?
<chrisccoulson> superm1 - it might do some GDM stuff as a fallback, but the primary method is the consolekit interface
<superm1> chrisccoulson, I don't see any methods for halt or reboot on org.freedesktop.ConsoleKit?
<superm1> unless that's the Restart() and Stop()?
<chrisccoulson> superm1 - yeah, that's right
<superm1> ah neat
<superm1> so really, xfce4-session needs CK support
<superm1> thanks chrisccoulson
<chrisccoulson> superm1 - you're welcome
<micahg> pitti: any final comments on what I proposed about ubuntu-bug?
<pitti> micahg: well, I still think we shouldn't make it too easy to file bad bug reports :)
<pitti> apport can digest an executable path if you don't want to bother figuring out the package name
<pitti> but since the name already is overloaded about four times (package, executable, symptom, crash file), I don't want to make it even more fuzzy
<micahg> pitti: ok, would it be possible to add to the error message if there is an upper case character that package names are lower case?
<superm1> pitti, i forgot to ask you last week.  do you have some spiffy apport method to find the package that owns a file other than dpkg -S?
<pitti> superm1: please use apport.packaging.get_file_package(filename)
<superm1> cool! that beats what i was doing: http://linux.dell.com/git/?p=dkms.git;a=blob;f=dkms_apport.py;h=69b639192eebc53183ec4920bb8150b41e3a6a6d;hb=1f4b4607b1456c18a9d10cde1823ecef71abcbd1
<pitti> it's not much better than dpkg -S, though, but no need to hardcode dpkg -S in hooks
<pitti> superm1: right, please; get_file_package() is distro independent (there's an RPM implementation, too)
<superm1> very good to know.  is apport showing up on any rpm distros by default yet that i'd be able to test this on then too?
<pitti> superm1: not sure, but OpenSUSE has a package
<superm1> pitti, while you're there, is there anything else useful you think I should be capturing for these DKMS build failures that occur?  the idea is that hook gets called when dkms build fails, and tries to file a bug on the package it was building for
<pitti> superm1: you could call attach_hardware(), that might be interesting since these are usually drivers?
<superm1> pitti, i thought about that, but pertaining to a build problem, probably wouldn't be much more than cruft
<pitti> oh, right
<superm1> i'm thinking the cases like where jockey installs a driver, and for some reason it doesnt build
<pitti> superm1: another potentially useful thing might be attach_related_packages() to get version info for pacakges you don't depend on
<mr_pouit> superm1: upstream will still rely on hal for xfce 4.8 afaik, so if we want to switch to {console,policy,device,whatever}kit, we're probably on our own at the moment
<pitti> like gcc, binutils, etc.; those are distro specific, of course
<pitti> and in particular, gcc-4.x tends to change with every release
<superm1> yes that would be very good to attach then
<superm1> mr_pouit, oh that's a shame
<pitti> superm1: but I think the build log ought to have anything that's really generally interesting
<pitti> I doubt that many errors are due to a binutils bug
<geser> could a core-dev please give-back: indicator-applet indicator-messages indicator-session nautilus-sendto libpam-mount. Thanks
<pitti> geser: doing
<Tm_T> should I care if Intrepid mysql packages might have issue(s)? and if yes, who should I poke to make sure it's packages and not me?
<micahg> ok, so am I supposed to ask for main SRU sponsorships in here?
<micahg> persia: ^^
<superm1> mr_pouit, well coming up with a patch for adding CK support shouldn't be too rough I suppose.  i can probably work something out this week
<superm1> it's really just copying a bunch of those HAL methods, and changing a few things here and there it looks like
<micahg> seb128: would you mind sponsoring a GTK SRU?
<seb128> micahg, depends of the sru
<micahg> bug 372103
<ubottu> Launchpad bug 372103 in gtk+2.0 "click on bookmark crashes firefox with java content in clipboard" [Medium,Fix released] https://launchpad.net/bugs/372103
<persia> micahg: You're not supposed to ask for main SRU sponsorships anywhere, really.  But if you're stuck on the process, you can ask how that works.
<micahg> persia: yeah, I thought about that after, that's why I asked seb as he maintains the package...I'm learning slowly...
<seb128> I was about to read my bug email, usually no need to ping
<seb128> it's just that I don't work much during weekends and it's monday morning there
<micahg> seb128: ah, ok, sorry
<seb128> anyway the change looks fine, could you give give an url to for the cgit commit?
<seb128> I will sponsor that later
<micahg> yeah, thanks
<seb128> thank you for the work on it
<soren> Keybuk: Is this a known problem? [   17.400075] plymouthd[414]: segfault at 10 ip 00007fe05f6db704 sp 00007fff904becb0 error 4 in libplybootsplash.so.2 (deleted)[7fe05f6cd000+14000]
<micahg> seb128: in the description or a comment?
<soren> Keybuk: I don't get any boot splash or anything like that at all.
<seb128> micahg, comment
<micahg> seb128: done and thanks, now time for me to sleep
<soren> Keybuk: That's with 0.8.0~-5, by the way.
<seb128> micahg, thanks
<seb128> soren, use apport to report the crash?
<maco> ~- ??
<seb128> soren, hard to tell if a crash is known without seeing a stacktrace...
<soren> seb128: There are no bugs (except for the MIR "bug") filed against Plymouth. I just don't know if it's because it's not expected to work at all yet. If it isn't, there's little point in filing bugs about it.
<seb128> soren, well, it's not complicated to let apport send the crash bug either
<soren> Fine.
<soren> Where do I enable apport? AIUI, it's not enabled in Lucid by default yet.
<soren> Ah, found it.
 * soren sighs deeply and reboots for the 16th time today
<soren> Hang on, isn't plymouth started from initramfs?
<soren> meh
<cjwatson> Keybuk: the point of starting-dm wasn't (mainly) to abstract away 'start' events - it was to arrange for the splash screen not to get an event if you boot with 'text' etc. which causes gdm.conf to 'exit 0' rather than actually starting gdm. I'm not sure that this has been adequately addressed?
<cjwatson> Keybuk: and indeed the default-display-manager stuff as well
<soren> seb128: Alright, mr. "it's not complicated to let apport send the crash bug". apport doesn't start until runlevel 2, so there's no crash file.
<seb128> soren, wait for Keybuk then, I was just suggesting that stacktraces are useful to know what happens on crashes, I don't care enough to argue
<soren> seb128: Well... You started it :D
<seb128> right, now I stop it too ;-)
 * soren hugs seb128 
 * seb128 hugs soren
<directhex> i didn't see a reply, and my scrollback is long gone. is the plan to put firefox 3.6 in lucid?
<pitti> directhex: if it's released in time, sure
<Keybuk> cjwatson: right, if you notice, plymouth doesn't have a "stop on startting gdm"
<Keybuk> instead gdm itself talks to plymouth to tell it to deactivate the splash but hold the framebuffer
<Keybuk> (so it can do the smooth X transition)
<Keybuk> and once it's started X, tells plymouth to quit - or if it fails to start X, tells plymouth to reset the console, etc.
<Keybuk> otherwise if X failed to start, the console would stick with the last plymouth frame
<cjwatson> Keybuk: I agree that that's better, but I see no way to make it work with ubiquity
<Keybuk> and you wouldn't be able to recover from that :)
<Keybuk> cjwatson: what's ubiquity got to do with it?
<cjwatson> you knew this on Friday
<cjwatson> 11:05 <Keybuk> if ubiquity was depending on it, then that was definitely a bug ;)
<cjwatson> except I disagree :)
<Keybuk> ubiquity can just use "starting gdm" no?
<cjwatson> oh, yeah, I thought ubiquity used starting-dm but apparently not
<Keybuk> it didn't when I glanced at it
<cjwatson> ubiquity does *emit* starting-dm though
<cjwatson> and I notice that plymouth doesn't cope with ubiquity starting
<Keybuk> right, ubiquity may need the same logic as gdm to make plymouth go away
<Keybuk> depending on whether you want a flicker-free transition into ubiquity or not <g>
<cjwatson> ok, so the reason I came into this is because the gdm/usplash pair is uninstallable :)
<cjwatson> can we switch usplash out from the seeds now?
<Keybuk> usplash isn't seeded
<Keybuk> I took it out last week
<cjwatson> the livefs builds disagree :)
<Keybuk> the 20091212 and 20091213 cd images built fine without it
<cjwatson> yeah, I'm getting lots of mailspam about it though
<Keybuk> "mailspam" ?
<cjwatson> I guess because several flavours other than Ubuntu still use it
<cjwatson> I get mail when livefs builds fail
<Keybuk> xubuntu was certainly updated a couple of days ago
<maco> kubuntu still does maybe?
<cjwatson> Package: usplash
<cjwatson> Task: kubuntu-desktop, kubuntu-netbook, edubuntu-desktop-kde, xubuntu-desktop, mobile-mid, mythbuntu-backend-master, mythbuntu-backend-slave, mythbuntu-desktop, mythbuntu-frontend, ubuntu-netbook-remix
<cjwatson> so I guess we need to fix all of those up
<Keybuk> I guess the seed owners haven't caught up
<cjwatson> where do the themes come from?
<Keybuk> what themes?
<cjwatson> does plymouth not display anything?
<Keybuk> yes, there's a basic built-in theme that tseliot did
<Keybuk> that's included in the plymouth package
<cjwatson> oh, nobody's worked on external theme packages?
<Keybuk> external theme packages "just work"
<Keybuk> there just aren't any
<Keybuk> it would be better to say that nobody's made any themes yet :p
<tseliot> Keybuk: have you included my theme already?
<Keybuk> tseliot: yes
<cjwatson> do you divert /lib/plymouth/ubuntu-logo.png or something?
<Keybuk> cjwatson: new themes install their own artwork, and just call plymouth-set-default-theme in their postinst on install
<cjwatson> ah
<tseliot> cjwatson: the logo can be set with a configuration flag in the debian/rules but you can ignore it in the theme
<Keybuk> tseliot: that's not really relevant - we wouldn't want to rebuild plymouth for every new theme <g>
<tseliot> as the theme is what tells plymouth to draw things
<tseliot> Keybuk: as I said, you can ignore that logo and use whatever png you have in the theme directory as a logo
<Keybuk> tseliot: how come you ignore the background colours but not the logo btw? :p
<cjwatson> so rather than editing flavours' seeds for them, I think I'd prefer to wait for them to convert their usplash theme packages
<tseliot> Keybuk: because that's on my TODO list? :-P
<Keybuk> cjwatson: I tend to just leave flavours alone
<persia> At least in the case of mobile-mid, it's not worth changing the seed since it is fast losing relevance (and with luck, will not exist in lucid)
<mr_pouit> cjwatson: I've xubuntu-artwork 0.39 stuck in new, that's why usplash is still pulled in xubuntu
<seb128> bah, bug #495868, apport should really prevent user to file a bug on each every package on a failing upgradfe
<ubottu> Launchpad bug 495868 in debconf "debconf: Unable to load Debconf::Element::Gnome::String. Failed because: Can't locate I18N/Langinfo.pm" [Undecided,New] https://launchpad.net/bugs/495868
<seb128> the guy opened a zillion bugs
<tseliot> Keybuk: does plymouth work reliably now?
<tseliot> on vt7, I mean
<Keybuk> tseliot: it works for me
<seb128> mvo, ^ isn't apt supposed to avoid those?
<tseliot> Keybuk: how did you fix it?
<Keybuk> tseliot: which bug are you thinking of ?
<mvo> seb128: it does basic dup detection, let me check
<tseliot> Keybuk: the one in which error messages overwrite whatever plymouth draws
<cjwatson> Keybuk: that's fine, but I don't :-)
<cjwatson> mr_pouit: ok
<mvo> seb128: 8.10, I suspect it was not fully done back then
<Keybuk> tseliot: I worked around it by scanning out the framebuffer back to the fbcon ;)
<Keybuk> haven't worked out why it doesn't work without doing that yet
<seb128> mvo, oh right, thanks
 * seb128 delete some 70 bug email
<tseliot> Keybuk: oh, as long as it works it should be fine for Lucid ;)
<seb128> some users a really motivated to open that number of bugs
<tseliot> mat_t: news from the design team?
<ogra> Keybuk, i'm on vacation but will try to provide you a backtrace of the amrel gdm issue if i find a spare minute, i suspect that it could be caused by the fact that nobody included the new populatie_rootfs speedup patches in the armel kernels yet though
<Keybuk> ogra: they're not included in the i386 kernel yet either
<Keybuk> and either way, would be entirely orthogonal to gdm not starting
<ogra> i though i saw a commit with the last upload
<Keybuk> since gdm isn't *in* the initramfs
<Keybuk> neither is gdm run from a kernel init function
<ogra> oh, indeed
 * ogra slaps forehead
<Keybuk> tseliot: it'll look crap on multi-head
<Keybuk> since plymouth maintains a separate framebuffer per head
<Keybuk> each with the right resolution
<Keybuk> but fbcon maintains a single framebuffer with the lowest common resolution cloned out to each head
<tseliot> Keybuk: oh, that's not ideal. My theme isn't exactly ready for multihead either (but this should be easier to fix)
<Keybuk> tseliot: your theme works fine on multihead
<Keybuk> themes generally don't notice the difference
<Keybuk> soren: no, not a known problem - file a bug with a stack trace
<tseliot> Keybuk: I think Ray fixed that in plymouth therefore my theme works now. I haven't had the chance to try it yet but if you say it works well with screens which use different resolutions..
<metellius> i'm trying to help the intel-xrog-driver people with debugging a bug of mine, and I'm therefore going to try a patch which includes linux-2.6/drivers/gpu/drm/drm_edid.c
<soren> Keybuk: How do I get a stack trace? apport isn't running yet when it crashes.
<metellius> do I have to recompile the whole kernel for this?
<mat_t> tseliot: hey
<mat_t> tseliot: I suggest pinging Iain
<tseliot> metellius: yes. You can discuss this in #ubuntu-x
<cjwatson> mr_pouit: NEWed, though I'm not sure I see any plymouth integration there
<mat_t> tseliot: I'll poke him for you
<tseliot> mat_t: thanks
<soren> Keybuk: FWIW, I have an nvidia card in this laptop. No KSM, as far as I can see (console is plain 80x25).
<mr_pouit> cjwatson: thanks. and not yet, this one only demotes usplash-theme-xubuntu to suggests.
<Keybuk> soren: tried "start plymouth" when X is not running?
<soren> Keybuk: Nope. I'll try that in a minute.
<soren> Keybuk: No crash :-/
<Keybuk> soren: check with pitti on that one
<soren> Keybuk: ..nor any splash screen or anything.
<soren> Keybuk: I mean.. It didn't crash.
<soren> Keybuk: Not "no crash file". Literally no crash.
<Keybuk> no idea then
<soren> Keybuk: Is plymouth known to work on any nvidia hardware?
<Keybuk> no
<Keybuk> though you should at least get a text mode variant
<soren> Keybuk: What would that look like?
<Keybuk> black screen with something that looks like a progress bar along the bottom
<soren> Keybuk: Hm.. Nope, I don't see anything like that.
<cjwatson> james_w,jdstrand,Riddell,kirkland,pitti,Keybuk,seb128,StevenK,slangasek: could you check ~lp_queue/sync-queue/{failed,rejected}/ on cocoplum and remove anything you don't need from there, please? I think practically everything in there is probably junk, but it isn't auto-purged at the moment and it's quite big
<Riddell> cjwatson: so that's where they go.  all find to scrap with me
<cjwatson> Riddell: done, thanks
<Keybuk> cjwatson: wiped
<tseliot> soren, Keybuk: plymouth should work with nvidia (try the latest Mandriva and see). Maybe fbcon or whatever we use was not loaded?
<Keybuk> tseliot: it so doesn't ;)
<Keybuk> plymouth might work with the nouveau drm driver
<Keybuk> but that's not in our kernel
<seb128> cjwatson, cleaned
<tjaalton> linus pulled it in .33 btw
<tjaalton> nouveau, that is
<tseliot> Keybuk: I was referring to the proprietary driver. Maybe the module isn't loaded?
<Keybuk> tjaalton: I thought it was just in -staging
<tjaalton> Keybuk: correct
<Keybuk> tseliot: the proprietary driver doesn't have a framebuffer
<Keybuk> tjaalton: that's a vast difference from being pulled into .33
<Keybuk> -staging != linux-2.6
<Keybuk> -staging is "we like you, but aren't willing to go steady until you sort our your personal hygiene issues"
<tjaalton> but it's still in the tarball, no?
<Keybuk> tjaalton: no
<StevenK> cjwatson: If you have a few seconds, can you review https://code.edge.launchpad.net/~stevenk/launchpad/netbook-cron/+merge/16115 and http://paste.ubuntu.com/341081/
<Keybuk> completely different git tree
<tseliot> Keybuk: I think it should work as usplash does with nvidia in Karmic
<tjaalton> but it _was_ pulled in linux-2.6.git
<cjwatson> StevenK: I already did, for the former; merging the latter now
<Keybuk> tseliot: why? plymouth doesn't have an svgalib renderer
<StevenK> cjwatson: I can merge the latter, I just want sign-off
<Keybuk> tjaalton: that being said, you're quite right, it *is* in linux-2.6 - not staging
<cjwatson> StevenK: signed off, but before you commit, run 'rm -rf ubuntu-tasks && make ubuntu-tasks && bzr add' and check the result
<tjaalton> Keybuk: "Kconfig under staging for now", that confused me
<Keybuk> tjaalton: I see where the confusion comes - it was set up to go into staging, but Linus pulled it himself
<Keybuk> yeah
<StevenK> cjwatson: In a Lucid chroot, or it doesn't matter?
<Keybuk> that's just confusing everyone clearly ;)
<cjwatson> StevenK: it doesn't matter
<tjaalton> yep :)
<tseliot> Keybuk: I'll check Mandriva again
<Keybuk> tseliot: Mandriva probably has nouveau
<tseliot> Keybuk: fcrozat in #plymouth should know how it works.
<tjaalton> anyway, it should be much easier to have something sensible for lucid, and not just some random branch from somewhere
<Keybuk> tseliot: quick google sez that Mandriva ship nouveau in their kernels
<tseliot> Keybuk: and no, I installed the proprietary driver in Mandriva and got the plymouth splash
<Keybuk> tseliot: no idea why that would work
<tseliot> I'll have to find out
<tjaalton> it starts with nouveau KMS and the nvidia blob will then steal everything?
<Keybuk> tjaalton: if you load nouveau, you can't load the nvidia blob
<Keybuk> in fact, I think you literally can't load
<Keybuk> ie. nouveau will claim the device through the usual agpgart stuff
<ghostcube> noveau ready for take off now ?
<Keybuk> which means the nvidia binary blob stolen agpgart code can't use it ever
<tjaalton> Keybuk: ok. I've never tried it myself so..
<Keybuk> it's why you have to reboot to switch drivers now
<tseliot> Keybuk: "it still works on VESA framebuffer. For chipsets not yet supporting KMS, we can still have graphical boot"
<tseliot> source: http://wiki.mandriva.com/en/2010.0_RC_1
<tseliot> "it" being "plymouth
<tseliot> "
<cjwatson> Riddell: re bug 494997, do you know if kdesudo still causes unexplained partitioning problems? ubiquity-wrapper says:
<ubottu> Launchpad bug 494997 in ubiquity "ubiquity fails to start in kubuntu" [High,Triaged] https://launchpad.net/bugs/494997
<cjwatson>             #temporarily force sudo until we work out why kdesudo stops it passing partitioning stage
<cjwatson>             toexec = ['sudo', '-E']
<Riddell> cjwatson: doesn't seem to no since we all used kdesudo while testing alpha 1
<Riddell> so should be safe to go back to that
<cjwatson> Riddell: ok, I'll remove that hack then, thanks
<cjwatson> it's from intrepid
<tseliot> soren: does Plymouth work if you load uvesafb?
<StevenK> cjwatson: tasksel looks good, shall I commit, tag and upload, or would you prefer to eyeball it first?
<cjwatson> StevenK: go ahead
<soren> tseliot: I'll make a note to check next time I have to reboot.
<soren> tseliot: Might be a few hours.
<tseliot> soren: ok, thanks
<soren> james_w: Would you mind syncing libcloud from unstable for me, please?
<soren> Or any other archive admin, I suppose ^^. (james_w is just listed as the "on duty" one today)
<geser> I was looking at the FTBFS of db4.7 (see also Debian bug #560641). It's because dh_nativejava (from libgcj-common) needs debhelper. Should libgcj-common depends on debhelper (doesn't look like the best idea based on the rdepends) or should db4.7 depend on debhelper (even if it doesn't use it directly)?
<ubottu> Debian bug 560641 in src:db4.7 "db4.7: FTBFS: Can't locate Debian/Debhelper/Dh_Lib.pm in @INC" [Serious,Open] http://bugs.debian.org/560641
<cjwatson> geser: I believe I ran across the same thing in the past and said the former
<cjwatson> or maybe something even higher up the stack, given the rdepends
<cjwatson> I definitely dealt with this at some point ...
<cjwatson> ah, no, I went for the latter
<cjwatson>      - Build-depend on debhelper, needed by dh_nativejava. It doesn't seem
<cjwatson>        reasonable for libgcj-common to depend on debhelper since that's also
<cjwatson>        used by run-time libraries.
<cjwatson> that's from the db changelog in Ubuntu
<geser> thanks, will do that too then
<cjwatson> geser: in fact I'd recommend generally checking the db diff over for things that need to be applied to db4.7
<fagan> mvo: could you look at this patch Bug #494845
<ubottu> Launchpad bug 494845 in software-center "[patch] String fix" [Undecided,New] https://launchpad.net/bugs/494845
<pitti> cjwatson: sync-queue> cleaned my stuff
<StevenK> cjwatson: I've cleaned up my sync-queue stuff too
<geser> is someone working on merging perl? there are several perl packages in DEPWAIT waiting on perl >= 5.10.1
<Kano> hi, is there a tool that evaluates the fdi files?
<Kano> hal is not there, so what does it now
<pitti> Kano: nothing
<Kano> so how should the xorg autoconfig work now
<Kano> like synaptics or other devices
<pitti> Kano: well, we'll probably bring back hal into the default install (mainly for brightness handling), but we want to run without hal for a while to detect regressions
<pitti> Kano: xorg uses udev now
<Kano> well then check for old fdi files, there are quite a lot left
<pitti> Kano: we transitioned the synaptics one to udev rules already
<pitti> as well as the basic keyboard ones
<pitti> there's still a couple which we have to rewrite, most notably the wacom ones
<Kano> also vbox?
<pitti> but we need a newer wacom driver first
<Kano> how to force udev to load new rules?
<pitti> Kano: oh, vbox ships them as well? Can yuo please create a bug report for that and assign to me?
<pitti> I'll have a look
<Kano> well i wrote a script that could install vbox addons automatically - even in live mode
<Kano> using hal it needed a hal restart
<tseliot> pitti: what is it that does brightness handling and uses hal?
<pitti> tseliot: gnome-power-manager
<pitti> tseliot: it should work without hal for cards/drivers supporting xbacklight
<pitti> but that's only very few yet
<tseliot> pitti: that would be with open source drivers, right?
<pitti> well, I'm on i945 here, and it doesn't even work here
<tseliot> that's an RandR property
<pitti> and I doubt that it works with proprietary nvidia/fglrx
<tseliot> pitti: but does g-p-m use RandR to set the backlight? If not, you can do it from the command line with xrandr
<pitti> it does, yes
<pitti> and falls back to hal if it doesn't support  xbacklight
<tseliot> pitti: it would be interesting to see why it doesn't work with your card without hal. Does it work with xrandr? (I can give you the exact command if you want)?
<pecisk> btw, Xorg hakers, is there any way to get LiveCD iso with nouveau mentioned in https://edge.launchpad.net/~xorg-edgers/+archive/nouveau?
<pitti> tseliot: hm, I need to reboot first (it's docked and on external screen right now); will try in 5 mins
<tjaalton> pecisk: too much work imo. the kernel will hopefully have the needed bits before too long
<tseliot> pitti: now I see why it doesn't work: KMS. See bug #397617
<ubottu> Launchpad bug 397617 in xserver-xorg-video-intel "brightness no more working on karmic (KMS)" [Low,Fix released] https://launchpad.net/bugs/397617
<cjwatson> james_w: I'd like to replace lp:ubuntu/grub2 with a branch off Debian's bzr maintenance branch, but I can't easily import the full history there so I'd like to keep the old import branch around for historical reference. What's the best way to do this?
<james_w> cjwatson: we can just change what lp:ubuntu/grub2 points to, the old branch will be available under its full name
<cjwatson> james_w: so I just push to lp:~ubuntu-core-dev/ubuntu/lucid/grub2/lucid and let you know?
<james_w> cjwatson: indeed
<cjwatson> ok, thanks
<tseliot> Keybuk: they use (u)vesafb to get plymouth to work with nvidia
<tseliot> Keybuk: would it be possible to use it only for fglrx and nvidia?
<Keybuk> tseliot: vesafb means no suspend/resume
<cjwatson> I wonder whether that's true for uvesafb too
<tseliot> and I wonder whether suspend/resume works reliably with fglrx and nvidia with or without uvesafb
<Keybuk> we don't want uvesafb
<Keybuk> at all
<cjwatson> tseliot: anyway, the plan of record was to use vga16fb for this, even though its output is less pretty
<Keybuk> v86d is not made of kittens
<tseliot> cjwatson: ah, right
<tseliot> so Keybuk why don't we use that and solve the problem with nvidia?
<tseliot> or am I missing something?
<Keybuk> tseliot: use what?
<tseliot> Keybuk: vga16fb
<Keybuk> tseliot: as cjwatson just said, the plan *is* to use it
<tseliot> Keybuk: so is soren's problem just temporary? I mean, until we use vga16fb?
<Keybuk> I don't know what soren's problem is
<soren> I get that a lot.
<james_w> soren: done
 * soren hugs james_w 
<soren> james_w: Thanks!
<tseliot> Keybuk: ok, never mind then ;)
<pitti> tseliot: re
<pitti> tseliot: computer is undocked now, using internal lvds; xbacklight says "No outputs have backlight property"
<tjaalton> it works on my intel
<tseliot> pitti: right. It looks like we have no backlight interface for intel in /sys/class/backlight in karmic (with KMS)
<pitti> /sys/class/backlight/dell_backlight/ exists here
<tseliot> tjaalton: with KMS and with Karmic's driver?
<tseliot> oh
<pitti> and it does work with hal
<pitti> $ cat /sys/class/backlight/dell_backlight/actual_brightness
<pitti> 4
<tseliot> I have none on my pineview card
<pitti> and when I crank it up with Fn, I get "6"
<tjaalton> tseliot: lucid
<tjaalton> but I guess it worked with karmic too
<tjaalton> but this is a lenovo..
<pitti> tseliot: I'm on COTD lucid, and it doesn't work either, so it's not 397617
 * tseliot nods
<tseliot> it must be a different issue
<tseliot> pitti: does grep backlight /var/log/Xorg.0.log show anything useful?
<pitti> no hits
<pitti> tseliot: xrandr --properties|grep back is empty, too
<tseliot> pitti: and what does xrandr --props do?
<pitti> isn't that the same?
<pitti> anyway, http://paste.ubuntu.com/341190/
<tseliot> yes, it's not there
<geser> anyone willing to sponsor a perl merge? bug #496556
<ubottu> Launchpad bug 496556 in perl "Merge perl 5.10.1-8 from Debian testing" [Undecided,New] https://launchpad.net/bugs/496556
<rahul_> geser i am a total noob but why do you need someone to sponsor a merge ?
<azeem_> rahul_: because not everybody has permissions to change the archive
<rahul_> so once you have made the changes in the local branch you get it reviewed by whom ?
<rahul_> is this the process called sponsoring ? or merging it into the main branch ?
<rahul_> so once you have made the changes in the local branch you get it reviewed by whom ?
<rahul_> sorry i am not trying to be annoying , just looking for answers.!!
<maco> submit a merge proposal
<maco> ~ubuntu-dev is default reviewer on them, i think
<rahul_> thanks maco ...!!
<rahul_> one more question what are the different bug stages like , basically i am trying to get familiar with the lingo
<rahul_> like triaging
<maco> https://wiki.ubuntu.com/Bugs/Status
<rahul_> awesome ..!!!!!!! thanks a ton
<jelmer> mvo: Hi
<mvo> hey jelmer
<jelmer> mvo: Do you happen to know what the encoding of the apt Release file is ?
<mvo> jelmer: the Release file should just be ascii most of the time, but utf-8 should work too
<jelmer> mvo: Thanks
<cjwatson> Keybuk: BTW, lp:~cjwatson/ubiquity/plymouth is my first cut at dealing with plymouth integration in ubiquity; I won't merge it until plymouth's actually on live CDs though
<barry> cjwatson: did you see my updated merge proposal?
<cjwatson> yes, I did, thanks - on my queue for today
<barry> cjwatson: thanks!
<cjwatson> Keybuk: is the code for your daily-bootchart stuff available anywhere? I'd like to adapt it to show manual partitioner benchmarks (mostly interested in the stuff to draw vertical budget lines)
<seb128> cj
<seb128> cjwatson,
<seb128> pybootchartgui (0+r139) lucid; urgency=low
<seb128> ...
<seb128> "  * Add --annotate option, permitted multiple times; takes a comma-separated
<seb128>     list of processes and draws a dashed red line vertically across the chart
<seb128>     at the point the first of the named processes is started."
<seb128>  
<seb128> cjwatson, oh, you probably mean the side which determine when xorg is loaded, etc?
<cjwatson> --annotate is useful, thanks, but ideally I did mean the autodetection as well
<seb128> cjwatson, http://people.canonical.com/~seb128/guess-time.py
<seb128> cjwatson, he gave me that some time ago, that give the linux, xorg, desktop times
<cjwatson> great, thanks
<seb128> np
<joaopinto> I am unable to import libxml2 from python2.5, python2.5 will still be available on Lucid ?
<ScottK> joaopinto: It is already gone.
<joaopinto> hum, so I have it from the relase upgrade
<ScottK> Yep
<cjwatson> damnit, I want to be able to run google over Ubuntu source code
<joaopinto>         500 http://pt.archive.ubuntu.com lucid/main Packages
<cjwatson> seb128: where does the "as superuser" thing in window titles in lucid come from?
<joaopinto> python2.5 was upgrade from lucid repos :)
<seb128> cjwatson, it's a compiz thing
<seb128> or I think it's a compiz thing
<seb128> check with Amaranth
<cjwatson> ok, I just want to be able to suppress it for the installer really
<cjwatson> "Install (as superuser)" -> "eh?"
<gigabytes> ahah :)
<cjwatson> not compiz
<joaopinto> ScottK, it is still available from the repositories, you meant is not used by default any longer ? That was already in karmic :)
<lutin> in the case rmadison gives several results for the same source package for the same suite, is there a way for requestsync to pick the correct version, and not the first result ?
<cjwatson> lutin: can't it use rmadison -a source?
<ScottK> joaopinto: It's not a 'supported python' version so modules aren't built for it anymore (as 2.4 was in Karmic).
<joaopinto> ScottK, ah ok, tks
<lutin> cjwatson: well it probably does, the thing is that it gives me three different versions for unstable alone
<cjwatson> lutin: example?
<lutin> cjwatson: rmadison eina -u debian
<cjwatson> lutin: blink. that seems like a bug in Debian's database
<cjwatson> but if not then I guess requestsync will have to sort by newest or something
<Keybuk> cjwatson: absolutely, it's in ../daily-scripts ;)
<Keybuk> seb128 was right that the code that does the red dashed lines is just using --annotate though
<cjwatson> aha, thanks
<Keybuk> incoming.sh does that
<Keybuk> cjwatson: your u6y patch looks right to me
<damjanzg> I have just one question. What is bare minimum that would give me a chance to start develop for ubuntu?
<ion> /bin/sh and /bin/cat
<ScottK> damjanzg: Showing up and wanting to help.
<damjanzg> OK, I think that wanting to help is not questionable.
<damjanzg> I know that there is no ultimate guideline for learning, but some would be helpful.
<ScottK> damjanzg: A lot of it depends on where your interests are.  What do you want to make better about Ubuntu?
<damjanzg> To be honest, my primary goal is to beather learn programming, and I want to no the lowest painful way, if there is one.:)
<ScottK> OK, well it's hard to make suggestions about where to start with just that.
<ScottK> What programming do you know already?
<damjanzg> I know, C. But nothing major that I have wrote, except some mathematical algorithms.
<damjanzg> And I am in process of learning python.
<ScottK> We use both those, so it's back to the question of interest.
<ion> keybuk: /usr/share/initramfs-tools/init should probably do mount -t devtmpfs,tmpfs ... /dev
<Keybuk> ion: yes, now that the kernel is uploaded
<Keybuk> though not until mountall does the same
<Keybuk> (I'm going to do that tomorrow, I want to see a bootchart with just the -7 -> -8 change on the dailies
<Keybuk> adding the new mountall+plymouth would muddy that quite a lot)
<ion> Ack
<Keybuk> your fsck priority changes are *nice* btw ;)
<ion> :-)
<Keybuk> that's a trick worth remembering
<hyperair> plymouth? =0
<hyperair> i thought we were sticking with usplash
<Keybuk> rather than serialise things that content on CPU or I/O - run them in parallel, use priorities, and CFQ actually does the right thing
<Keybuk> kernel scheduler in working shocker
<ion> keybuk: busybox mount doesnât seem to support -t foo,fallback,bar
<Keybuk> you would need to be more clever anyway
<Keybuk> you need to mknod if you mount tmpfs not devtmpfs
<ion> The scripts seem to do [ -e /dev/foo ] || mknod /dev/foo ...
<Keybuk> yeah
<Keybuk> doing it properly eliminates those stat() calls :p
<ion> Alright
<ion> Btw, as for a lot of package changes muddying the bootchart numbers; what i proposed some time ago would have fixed that. ;-)
<Keybuk> ion: what's that?
<Keybuk> the incremental upgrade stuff?
<ion> Yeah
<Keybuk> would have done things in the wrong order in this case too
<ion> Ok
<Keybuk> the kernel and initrd don't come from the squashfs, but the iso image, remember
<Keybuk> the thing I like about these Dell Minis is how damned predictable they are
<Keybuk> http://people.canonical.com/~scott/daily-bootcharts/20091214-sam.png
<Keybuk> vs.
<Keybuk> http://people.canonical.com/~scott/daily-bootcharts/20091214-clank.png
<ion> :-)
<smoser> anyone done a kvm install of lucid server ? i just went through one using alpha1 iso and grub is hanging
<smoser> kvm disk was using '-hda' (ide)
<cragdor> Anyone got a setup to install a development VM for Kubuntu(Latest) and connect to the SVN?
<cjwatson> barry: merged and uploaded (congratulations, your first upload ...)
<barry> cjwatson: saw that, thanks!
<barry> cjwatson: if you've got another one, i'd like to try it again with some of the things i've learned
<ScottK> slangasek: u-d-a moderation queue should have something for you to review.
<smoser> shoot... seems like user error above.
<wgrant> Is everyone fine with 3.0 support being turned on in LP for Lucid as soon as it's all ready?
<lucas> wgrant: just curious. what's the alternative?
<superm1> is there any reason people wouldn't want it turned on ? :)
<wgrant> superm1: I don't know, but I'd like to be really sure before changing behaviour like that.
<cjwatson> wgrant: please do it :)
<wgrant> cjwatson: Great, thanks.
<wgrant> It's all landed, so should roll out on Wednesday at 2200UTC. But it cannot be enabled before dpkg is upgraded on the production Soyuz machines, which I believe hasn't happened yet.
<cjwatson> being tested at the moment, I believe
<wgrant> Great.
<ion> dkms (2.1.1.0-0ubuntu1): * Convert DKMS to an upstart script that starts up before GDM or KDM can start.  This ensures that drivers are built before X tries to start. (LP: #453365)
<ion> /etc/init/dkms_autoinstaller.conf doesnât seem to have *anything* to delay gdm.
<slangasek> ion: I concur; reopen the bug?
<superm1> ion, it stops gdm
<superm1> look at the gdm task for that bug
<superm1> after gdm is stopped, dkms will issue a signal to start it back up when it's ready
<cjwatson> seb128: that "(as superuser)" thing is actually from metacity; I happen to know upstream so I've asked him
<seb128> oh ok
<seb128> there was some discussion about doing that with the compiz decorator some weeks ago too
<ion> superm1: How about just dkms_autoinstaller.conf: âstart on filesystem or starting-dmâ and let Upstart block gdm when it emits starting-dm in case dkms_autoinstaller is still running?
<superm1> ion, you dont want it blocking for all modules
<superm1> ion, only for fglrx and nvidia
<ion> superm1: Also, donât the âbuild-failedâ and âbuild-successfulâ events have a bit too generic names? How about dkms-build-*?
<superm1> what else uses build-failed or build-successful?
<ion> Nothing should â somethingelse should use somethingelse-build-*. :-P
<baddog> Red Hot Chili Peppers - Cant Stop
<baddog> er.
<baddog> sorry 'bout that >.>
<superm1> ion, and gdm doesn't emit starting-dm anymore, so there is no way could have blocked on that
<chrisccoulson> hi cjwatson - i can't seem to upload liboobs and gnome-system-tools. is that behaviour expected?
<cjwatson> chrisccoulson: afraid so, they're currently marked as 'desktop-core' rather than 'ubuntu-desktop'. See https://lists.ubuntu.com/archives/ubuntu-devel/2009-November/029623.html for some commentary on this kind of subject
<chrisccoulson> cjwatson - thanks, that makes sense now
<lamont> cjwatson: I'm looking at the implicit-pointer-functions hook... would inline be something reasonable? (we run sbuild --nolog, so I don't have a handy file lying around to feed the script, but I could teach it to do it as part of the command pipe of sbuild
<slangasek> cjwatson: ~lp_queue/sync-queue/{failed,rejected}/> swept
<cjwatson> lamont: inline?
<lamont> done inline, the errors would come where the conversion abuse happens, instead of in a lump at the end.
<cjwatson> as long as it doesn't stop the build immediately
<lamont> not until it finishes
<lamont> it reads to EOF
<cjwatson> I don't see a problem with that, then, unless I'm failing to see why it might be problematic
<lamont> our current use (debian), it all happens at the end-ish part of the log, right after 'Built successfully', declaring it to be a lie.
<slangasek> ScottK: u-d-a> kind of a short message? :)  what are the implications for people doing merges &c.?
<lamont> done inline, you'd have a build log that claims "successful", and a failed build
<ScottK> slangasek: It's more don't file bugs when import foo doesn't work with python2.5 anymore.
<cjwatson> lamont: oh, right - yes, inline makes much more sense
<lamont> cjwatson: ok.  of course, getting the compiler to do this for us would be even better in that case...
<lamont> but ok
<bryce> slangasek, pitti:  we're going to be renaming 'wacom-tools' to 'xserver-xorg-input-wacom' (or maybe xf86-input-wacom) to follow Debian and upstream  - do we need a new MIR for renames?
<slangasek> bryce: nope, just a reminder when it's in the NEW queue so we know what to link it to
<slangasek> bryce: is this rename source&binary, or source-only?
<bryce> slangasek, wacom-tools already provides an xserver-xorg-input-wacom binary afaik so I think it's mostly a source rename
<slangasek> ok, cool
<bryce> slangasek, this is the last bitty piece needed to get X off HAL :-)
 * slangasek dances on hal's grave
<StevenK> It's not quite buried yet?
<slangasek> I have hal removed from my system though, and keyboard&mouse are still slow to appear on resume :(
<slangasek> StevenK: dancing on its grave packs down the earth and prevents it from receiving a decent burial, you see
<StevenK> Haha
<lamont> hrm... slangasek got a handy implicit-ptr-function package lying around unfixed in lucid?
<slangasek> lamont: no, sorry - perhaps one of the ones you filed bugs on last cycle?
<lamont> yeah - already searching for one of those
<slangasek> anyone else seeing indicator-applet shouting 'No indicators' in lucid?
<slangasek> would be nice to be able to log out without hard-killing X
<chrisccoulson> slangasek - i think it's still waiting on some builds. in the meantime, you can just do "gnome-session-save --shutdown-dialog"
<chrisccoulson> or "gnome-session-save --logout-dialog"
<slangasek> chrisccoulson: "waiting on some builds" - so the fix for this has already been uploaded?
<slangasek> thanks for the workaround
<kirkland> slangasek: hi there, I'm finally getting around to fixing Bug #437012
<ubottu> Launchpad bug 437012 in eucalyptus "eucalyptus-common maintainer script should not add dpkg statoverrides" [Low,In progress] https://launchpad.net/bugs/437012
<kirkland> slangasek: i'm curious about "When making the above change, additional cleanup handling should be done to identify any dpkg-statoverrides added by this package and remove them."
<kirkland> slangasek: how do I go about doing that?
<seb128> slangasek, you are one of the buildd admin? ;-)
<seb128> slangasek, https://edge.launchpad.net/ubuntu/+source/indicator-applet/0.3.0-0ubuntu1 is what needs to be done
<seb128> tedg and kenvandine forgot to use a Breaks somewhere
<chrisccoulson> slangasek - that will fix your indicator issue ;)
<seb128> things got out of sync without anything blocking updates
<seb128> could somebody bump the build score for indicator-applet?
<maxb> Hi, could I enlist a core-dev to push lp:~maxb/ubuntu/lucid/subversion/merge into lp:ubuntu/subversion? Scott Kitterman has already sponsored the upload itself, but didn't do the UDD bit of it
<maxb> I've adjusted my branch to correspond to the package that was actually uploaded
<slangasek> seb128, chrisccoulson: not a buildd admin, no
<seb128> ok, so you will have to wait for those to build
<slangasek> kirkland: for override in $(dpkg-statoverride --list $pattern); do <check that it matches what we added previously>; dpkg-statoverride remove $file; done
<kirkland> slangasek: okay, thanks, i have a diff you can spot check
<slangasek> kirkland: a bit tied up right now trying to make cryptsetup work with plymouth, so that my machine will boot cleanly
<kirkland> slangasek: okay, no worries
<kirkland> slangasek: i think i have it right
<dtchen> maxb: Pushed up to revision 36.
#ubuntu-devel 2009-12-15
<maxb> dtchen: Thanks but that's not right, I don't think. Could you please push --overwrite my branch, not merge it?
<maxb> Otherwise, the UDD importer is going to go a bit crazy if it has to do another import
<maxb> james_w: I don't suppose you're around and would care to clarify this one?
<lamont> cjwatson/slangasek: so the new lp-buildd will spit out the errors inline, and then (if any) recap them all and print out the whole "oh hai, you're borked" at the end of the build and cause it to fail
<dtchen> maxb: I'm having difficulty interpreting. Do you want me to replace the existing one with yours?
<maxb> That's correct
<Caesar> slangasek: this is an advanced heads-up that we may require a freeze exception for Puppet
<lamont> cjwatson / slangasek : as in http://paste.ubuntu.com/341525/
<dtchen> maxb: I apologize for misinterpreting then; I presumed "push" and "merge" [the latter in your URI] referred to a merging op.
<lamont> line 489, for exmaple
<ebroder> Any backporters around who could look at bug #315264?
<ubottu> Launchpad bug 315264 in hardy-backports "Please backport config-package-dev 4.9 from Jaunty to Hardy/Intrepid" [Wishlist,Confirmed] https://launchpad.net/bugs/315264
<maxb> dtchen: No problem - I merged the package both in the bzr and packaging sense, so all that was left to do was to push the extra history into the official branch - If that makes any more sense?
<maxb> (sorry for disappearing mid-conversation, there seems's to be a weird routing glitch affecting me here)
<dtchen> maxb: should be fixed up now
<maxb> looks good. Now, if we can just get the importer over whatever else it's coughing on regarding Subversion :-)
<slangasek> lamont: I'm not a buildd admin, it sounds like this is a buildd admin tool?
<slangasek> Caesar: is more detail available?
<kirkland> slangasek: I'd like to clean up a bunch of lintian errors against Eucalyptus -- we have upstart scripts, so we're getting http://paste.ubuntu.com/341548/
<persia> kirkland: Don't upstart scripts end up in /etc/init/${SERVICE}.conf usually, rather than /etc/init.d/${SERVICE} ?
<StevenK> lamont: Still here?
<StevenK> lamont: I'm looking at uploading a new livecd-rootfs, do you still need to merge BuildLiveCD changes manually?
<slangasek> kirkland: bug in lintian
<slangasek> kirkland: lintian needs to know not to run these checks when the script is a link to /lib/init/upstart-job
<cjwatson> persia: there's a compat shim
<persia> Ah.  Thanks.
<smoser> slangasek, you know if 'start on mount MOUNTPOINT=/' (upstart)  per https://wiki.ubuntu.com/ServerLucidCloudBoothooks is supposed to work yet?
<smoser> anyone else know ? it doesn't seem to be working for me, but didn't know if it was user error
<slangasek> smoser: haven't heard of such a 'mount' event, no, sorry
<smoser> Scott typed what was there in the session, it appears it does work now, but i dont see where in 'mountall' it is emitted.
<smoser> and when i get it / is ro, i'd like to have it rw
<jdong> [jdong@hideout:aa-tools/sudont]$ sudont tase me bro               (12-14 23:45)
<jdong> *sigh*, grow up already...
<jdong> that's what happens when I get bored :-/
<ubuntu-crypto> anyone awake?
<ScottK> No
<ubuntu-crypto> the default crypto installer does not take kindly to EXt4
<ubuntu-crypto> "cryptsetup: unknown fstype. Bad password or option?"
<ubuntu-crypto> password is correct, i can mount it from this CD.
<ubuntu-crypto> ScottK, any idea? it got reported as a launchpad bug.
<ScottK> Nope.  Sorry
<crypt-0-> nickserv pass is somewhere on one of the drives i am replacing
<crypt-0-> Well i wanted to give EXT4 a try.
<lamont> StevenK: BuildLiveCD updates --> RT
<crypt-0-> Any pointers on where to look for obvious errors?
<crypt-0-> Also, is the automated crypto installer documented anywhere?
<crypt-0-> Im looking for a "how it works" not a "howto"
<JFo> jono, are you still updating akgraner's wiki? I don't want to step on your updates.
<JFo> nm, she told me you were finished :)
<jono> JFo, done!
<jono> thanks!
<JFo> thank you sir
<crypt-0-> "cryptsetup: unknown fstype. Bad password or option?" anyone have any ideas, or pointers?
<crypt-0-> Im starting to think it does not like EXT4.
<dtchen> that's odd, since I created crypt lvm containing ext4 just fine
<dtchen> you might want to see bug 428435, however
<ubottu> Launchpad bug 428435 in util-linux "luks encrypted partition not detected" [High,Fix released] https://launchpad.net/bugs/428435
<crypt-0-> thanks dtchen
<crypt-0-> dtchen, i can mount it ok on this LiveCD, and on my other installation.
<crypt-0-> Just not at boot time.
<lamont> wgrant: bzr+ssh://bazaar.launchpad.net/~lamont/launchpad/proposed-lpbuildd-version-53/  revision 9914 is the latest in love
<crypt-0-> dtchen, you around?
<pitti> Good morning
<StevenK> pitti: Hey!
<pitti> Â¿noÊ ÇÉ¹É ÊoÉ¥ 'ÇÊÇÊs buÄ±uÉ¹oÉ¯ poob
<StevenK> pitti: Haha. Well, thanks.
<dholbach> good morning
<Caesar> slangasek: yeah, upstream may not be able to get 0.25.2 out in the timeframe necessary
<slangasek> superm1: did you discuss these gdm job changes with Keybuk at all before making them?  My understanding is that and+or in a job start condition is broken with current upstart
<slangasek> Caesar: 0.25.2> we currently have 0.24.8 in lucid - is there an 0.25.1 we should be pulling in between now and the freeze?
<Keybuk> slangasek: no, he didn't
<Keybuk> from a glance, gdm would now be broken for anyone not using dkms
<slangasek> Keybuk: confirmed here :-P
<Keybuk> I'm going to revert his changes
<pitti> Keybuk: speaking of which, yesterday gdm started too early apparently, I only got a wildly distorted error message after X started (too distorted to read it, though)
<slangasek> I'm not sure the dkms part is actually what's causing my failure ,though
<pitti> booting with "text" and starting manually works
<Keybuk> pitti: I've no idea why gdm would start "too early"
<pitti> well, it started with 2.29.1-0ubuntu4, not sure
<seb128__> re
<pitti> either due to that, or because I installed plymouth
<seb128__> pitti, version of what?
<pitti> I'll watch it over the next days
<Keybuk> pitti: more likely the latter
<pitti> seb128__: gdm
<seb128__> what started with it?
<pitti> seb128__: X starts totally distorted and with only an error dialog (unreadable); I have to boot with 'text' and start manually
<seb128__> speaking of gdm
<seb128__> bug #496796
<pitti> seems I have to do more experiments then :)
<ubottu> Launchpad bug 496796 in gdm "fsck on boot triggers failsafe x 100% of the time" [Undecided,New] https://launchpad.net/bugs/496796
<seb128__> who is responsive for that?
<pitti> oh, perhaps it also was that, can't say
<slangasek> I get that in cases that don't involve fsck
<seb128__> pitti, the failsafe uses vesa too
<seb128__> which doesn't work with kms...
<seb128__> #ubuntu-x was discussing using fb yesterday
<tseliot> what is it that should use fb?
<seb128__> tseliot, read the bug I just pointed
<seb128__> or bug #496773
<ubottu> Launchpad bug 496773 in xorg "Failsafe X should pick fbdev instead of vesa if KMS is in use" [Wishlist,Triaged] https://launchpad.net/bugs/496773
<tseliot> thanks, I'll have a look at it
<seb128__> thank you
<slangasek> are we currently guaranteed to have an fb in all cases?
<Keybuk> nope
<Keybuk> this is the problem with X
<slangasek> right, so that's another regression in the gdm job...
<Keybuk> it either needs a DRM/DRI device, a framebuffer, or just start it anyway
<Keybuk> no it isn't
<slangasek> ah, right, it's not
<Keybuk> not how I had it written anyway
<ogra> Keybuk, oh, so Bug #495874 isnt arm specific anymore ?
<ubottu> Launchpad bug 495874 in gdm "gdm dies on babbage2.5 board with recent boot speedup changes" [High,Incomplete] https://launchpad.net/bugs/495874
<Keybuk> ogra: unknown, insufficient information
<ogra> pitti, ^^^ you see the same ?
<Keybuk> ogra: you haven't provided the strace I asked for
<ogra> Keybuk, i'm on vacation as i said before .. mobile team is informed though
<pitti> ogra: can't say for sure
<Keybuk> ogra: then go on vacation ;)
<seb128__> pitti, bug #496796 should be assigned to our team or not? I'm not sure
<ubottu> Launchpad bug 496796 in gdm "fsck on boot triggers failsafe x 100% of the time" [Undecided,New] https://launchpad.net/bugs/496796
<seb128__> pitti, it should be of bugs to watch in some way...
<seb128__> pitti, it should be on the list of bugs to watch in some way...
<ogra> Keybuk, 300-600 mails a day, i'm at least checking mails every second day to not have them pile up :)
<Keybuk> ogra: that's not a vacation then :p
<pitti> seb128__: right, putting on the release radar
<seb128__> pitti, danke
<pitti> will probably need Keybuk's input, but I assigned it to desktop for nwo
<ogra> Keybuk, coming back nad sitting in front of a six digit inbox counter is no fun either :)
<Keybuk> ogra: that's what the delete key is for
<ogra> heh
<tseliot> Keybuk: what do you think about the suggestion in bug #496796 ? Isn't an fb enough?
<ubottu> Launchpad bug 496796 in gdm "fsck on boot triggers failsafe x 100% of the time" [Undecided,New] https://launchpad.net/bugs/496796
<Keybuk> tseliot: which suggestion?
<tseliot> Keybuk: changing /etc/init/gdm.conf so it checks "and stopped udevtrigger" instead of "or stopped udevtrigger
<Keybuk> that would be wrong
<tseliot> Keybuk: this is why I asked. But what happens if we get "stopped udevtrigger" without a drm-device-added or graphics-device-added?
<Keybuk> then gdm will start
<tseliot> Keybuk: of course ;) but what happens in the system? Does it mean that we initialise gdm without a graphics device?
<Keybuk> possibly
<Keybuk> though since X modprobes the module it wants anyway, it's unlikely to be the issue
<seb128__> Keybuk, any opinion on bug #496859?
<Keybuk> also I see the same issue from time to time
<ubottu> Launchpad bug 496859 in gdm "*dm upstart job should depend on acpid because X tries to connect to acpid socket very soon after starting." [Undecided,New] https://launchpad.net/bugs/496859
<Keybuk> and on my system, the i915 driver is loaded in the initramfs
<persia> Just out of curiosity, is image building disabled?  I don't see anything for the last couple days at http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/lucid/
<tseliot> Keybuk: does Lucid have the mountall hooks for plymouth already?
<Keybuk> seb128__: X doesn't need to connect to the acpid socket, and makes no difference if it fails
<Keybuk> tseliot: no
<seb128__> Keybuk, could you write that on the bug? thanks ;-)
<Keybuk> seb128__: done, marked Won't Fix
<seb128__> Keybuk, thanks
<tseliot> Keybuk: aah, that explains why the user can't see visual feedback of the fsck check
<Keybuk> tseliot: no it doesn't
<Keybuk> why does "the user" even have Plymouth installed?
<Keybuk> it's not seeded and nothing depends on it
<tseliot> Keybuk: because he wanted to try it, I guess
<tseliot> "fsck's happen without any visual feedback when plymouth is installed"
<tseliot> but yes, that's not the main problem
<Keybuk> the only reply to that is "Well, Don't Do That Then"
<tseliot> :-D
<Keybuk> slangasek: could I get a new live fs build once my updated gdm package is built?
<cjwatson> persia: doesn't appear to be
<cjwatson> persia: and I'm seeing builds at the URL you quote ...
<persia> Hum.  I appear to have overgeneralised from ports_daily-live.  Sorry.
<cjwatson> daily-live builds only happen if the corresponding livefs build succeeds, so you can check livefs-build-logs
<StevenK> cjwatson: I guess I need to wait for the LP rollout until I can install the netbook-live^ task?
<cjwatson> StevenK: I'd expect so
<Keybuk> tseliot: oh, and on the gdm-not-starting thing
<Keybuk> in my testing so far, when gdm doesn't start, it's not that gdm-binary fails
<Keybuk> it's that Upstart fails to even start the job
<Keybuk> which is far more interesting
<tseliot> oh
<tseliot> Keybuk: what do you mean by "fails to start the job"? Are you saying that it doesn't depend on the conditions that we test for "start on"?
<Keybuk> I don't know yet
<Keybuk> I know that if I pre-start exec touch /tmp/foo - that file never appears ;)
<Keybuk> to debug, I need to get a boot where gdm fails to start
<Keybuk> then crash upstart
<Keybuk> to look at the job data and figure out why it didn't start it
<tseliot> does it help if you trigger an fsck check?
<Keybuk> no
<tseliot> maybe get rid of the failsafex script and try to crash x?
<tseliot> that should be easy
<Keybuk> tseliot: not sure how crashing X would help ;)
<tseliot> Keybuk: gdm wouldn't start, I guess
<Keybuk> I think you're missing my point
<tseliot> Keybuk: yes, probably ;)
<Keybuk> in my tests, when you get those "no X" boots, gdm-binary was never started
<Keybuk> I actually think that mountall stops sending the events to Upstart entirely
<Keybuk> and I'm not sure why ;)
<tseliot> Keybuk: oh, now I think I see your point
<Keybuk> crashing upstart lets me run gdb over a core file, and look to see whether the filesystem event ever happened
<Keybuk> (I think it isn't)
<Keybuk> slangasek: yet again, it occurs to me to ask *why* dkms has to build the kernel modules on boot
<Keybuk> and why it can't do it in postinst
<pitti> Keybuk: it does
<Keybuk> pitti: no it doesn't ;)
<pitti> it's there for the case that you change the default kernel on boot
<pitti> or install a custom one manually
<pitti> it's the last line of defence
<pitti> Keybuk: dkms uses /etc/kernel/postinst.d
<Keybuk> so we add 2s to boot time in case someone installs a kernel while the machine is *POWERED OFF* ?
<pitti> I agree that we shouldn't add 2 seconds for it :)
<Keybuk> update-initramfs doesn't even defend that much
<Keybuk> the problem is that it's not a defence
<Keybuk> if you don't run the boot-time script, you don't get the module
<Keybuk> even in the case where you didn't do anything stupid
<Keybuk> the human brain is remarkably bad at answering the question "is that light flashing/pulsating?"
<Keybuk> I often seem to go cross-eyed staring at the Minis to tell whether they're sleeping or installing images
<jiboumans> Keybuk: it's quite simple really. if you look at it for 3 minutes and you have a seizure, it was flashing. Otherwise, it's pulsating.
<Keybuk> jiboumans: I meant the difference between solidly-on and pulsating
<smoser> Keybuk, ping. i had a question about https://wiki.ubuntu.com/ServerLucidCloudBoothooks
<Keybuk> smoser: hi
<smoser> hi. I'll pastebin the mail i have started? or would you prefer just for me to send it?
<Keybuk> either is fine :)
<smoser> Keybuk, http://paste.ubuntu.com/341909/
<Keybuk> smoser: ah, the job is wrong
<smoser> well of course :)
<Keybuk> it should be "mounted" not "mount", and you'll need the mountall I haven't actually uploaded yet
<smoser> :)
<smoser> that would explain it. i went looking for 'mounted' events, and found osme in the moutnall code, but wasn't getting them in upstart
<Keybuk> it shouldn't block the boot though
<Keybuk> it will block the filesystem event, but that is deliberate
<smoser> hmm... I can fairly easily reproduce if you're interested in seeing logs
<Keybuk> kees: you are a numpty
<Keybuk> smoser: yes please
<smoser> verbose good enough? or do you want debug?
<Keybuk> verbose should be fine
<smoser> http://paste.ubuntu.com/341923/
<smoser> If I boot with 'init=/bin/bash' and then remove the 'test.conf' and reboot, it will boot again
<smoser> in the pastebin above, after 592 seconds, i get:
<smoser> [  592.351775] Power down.
<Keybuk> smoser: looks like the same bug I just independently fixed
<Keybuk> eth0 can never come up
<Keybuk> because kees is a numpty ;)
<smoser> fair enough.  so, what should I do to get this working?  I need a mountall with 'mounted' event, and newer upstart ?
<Keybuk> newer mountall and newer ifupdown
<smoser> ok. then, just to be clear, at that point '(mounted MOUNTPOINT=/ and net-device-up IFACE=eth0)' should get me what i want
<sgallagh> Keybuk: I haven't seen matthiaz around in a long while. Is he on vacation/changed nick?
<sgallagh> Keybuk: I wanted to talk to him about getting some testing of SSSD 0.99.1 in Ubuntu before we release the final 1.0 version at the end of the week.
<smoser> sgallagh, i believe he's returning from vacation tomorrow.
<Keybuk> smoser: yes, it should
<Keybuk> smoser: the problem is that net-device-up eth0 never happens
<Keybuk> because the network interface is never brought up
<Keybuk> because it's waiting for network-interface-security to be started
<Keybuk> kees: ;-)
<Keybuk> mostly just teasing
<Keybuk> but the ifupdown changes you did ... err ... broke it
<kees> Keybuk: really? in which cases?  :(
<Keybuk> kees: having anything other than lo in /etc/network/interfaces
<Keybuk> no other interface would come up
<Keybuk> bad times
<Keybuk> dogs and cats living together
<Keybuk> etc.
<akgraner> jiboumans, Congrats being the New Server Manager....
<kees> Keybuk: that is extremely strange; I have a stack of interfaces in /etc/network/interfaces and they all come up.  I tested that and the n-m cases.  :(
<akgraner> jiboumans, and if you have 2 secs I'd like to speak to you about a possible interview for ubuntu user online
<akgraner> jiboumans, here is where you can check out the others I have done on the platform team  :-) http://www.ubuntu-user.com/Online/Blogs/Amber-Graner-You-in-Ubuntu
<Keybuk> kees: you were lucky enough that the networking job brought them up
<Keybuk> rather than the network-interface job
<Keybuk> if you look at your patch, here's why it won't work
<Keybuk> start on foo and bar
<Keybuk> instance $FOO
<Keybuk> ...
<Keybuk> foo happens
<Keybuk> bar happens
<Keybuk> ifup lo gets run
<Keybuk> now foo happens again
<Keybuk> ...
<Keybuk> nothing happens
<Keybuk> it's waiting for bar again
<Keybuk> in your changes case, it would only work if network-interface-security was restarted for every single instance
<Keybuk> which it isn't
<Keybuk> (in fact, you went out of your way to make it a state so it couldn't possibly be <g>)
<pitti> jdstrand: bug 496923 is all your's now; please let me know if I can help with something else, but I'm afraid I can't do the uploads, etc.
<ubottu> Launchpad bug 496923 in postgresql-8.4 "Security/bug fix release: 8.4.2, 8.3.9, 8.1.19" [High,In progress] https://launchpad.net/bugs/496923
<jdstrand> pitti: sure thing! thanks for all your work on this :)
<kees> Keybuk: so... this is a bug in upstart then?  I thought service states were always available.
<kees> Keybuk: i.e. I can always depend on "started Blah" since it's either running or not
<kees> that's why I made network-interface-security a service instead of a task.  I was specifically trying to avoid the situation you described since I knew of the "and" bug.
<Keybuk> kees: no, it's an event
<kees> Keybuk: what's the right way to achieve what I set out to do?
<Keybuk> events are transient
<Keybuk> once they've happened, all memory of them is gone
<Keybuk> there isn't a way to achieve precisely what you wanted to do
<kees> fun.
<Keybuk> the way I rewrote it is better
<kees> ok, I'd like to see/understand that.  is it uploaded?
<HIDID> hello guys
<Keybuk> it is
<Keybuk> your network-interface-security job gets started as a result of the network-interface and networking jobs getting started
<Keybuk> it'll hold it up (because upstart does that)
<Keybuk> then the interface comes up
<Keybuk> but most importantly, the next time an interface comes up, your job is already running, so isn't re-run
 * kees goes to read
<Keybuk> kees: though you had the right intentions
<Keybuk> you just hit upstart bugs
<kees> "Revert Kees's change; this flat out doesn't work.
<kees> *snicker*
<kees> it _did_ work, just not very well.  :P
<kees> your diff is strange, lots of reverts.
<kees> ah, _darcs
<kees> Keybuk: oh, this is great, actually.  it lets me hook to n-m's job without touching n-m at all
<kees> Keybuk: so, a job with  start on starting Blah  will finish before Blah starts?
<ion> A service will be started before Blah starts, and a task will finish before Blah starts IIRC.
<kees> hrm.
<kees> sounds like I want to move it back to a task, then.
<kees> I just want to avoid it being spawned multiple times.
 * ion looks at network-interface-security.conf... pre-start script will finish before network-interface starts.
<arnau> Hello. Can somebody help me about configuring ubuntu in a toshiba laptop?
<kees> ion: ah, ok
<ion> The following packages will be REMOVED: hal{u}
<ion> Yay
<pitti> *squish* *zap* *die!*
<pitti> cjwatson: indicator-application was recently NEWed, and is now depended on by rhythmbox (through libappindicator0); however, ./edit_acl.py -s indicator-application query gives no uploaders at all; conceptually it should be in the desktop set
<pitti> cjwatson: will that sort out itself, or does that need to be handled manually? If so, how?
<cjwatson> pitti: it'll sort itself out (with my assistance)
<cjwatson> unfortunately it isn't yet generalised so that other admins can do it, which is a problem :(
<pitti> ok, thank you
<pitti> kenvandine: ^ FYI
<cjwatson> I'll poke it now
<kenvandine> thx cjwatson
<ion> keybuk: The dkms update still left /etc/init/dkms_autoinstaller.conf to my machines.
<superm1> Keybuk, it is a supposed to be a last line of defense.  the modules are normally built in the postinst of either the headers or the kernel
<Keybuk> superm1: it's wrong
<Keybuk> (and it takes 4s of boot time to do nothing)
<Keybuk> but mostly it's wrong
<superm1> 4s is a huge exaggeration
<Keybuk> people boot old kernels because things went wrong with newly installed kernels or modules
<Keybuk> the *last* thing they want is new modules being built
<Keybuk> superm1: no, 4s was the time dkms took in today's charts on my mini
<Keybuk> that's why I suddenly took interest :p
 * Chipzz_ agrees with Keybuk 
<Keybuk> ion: oh, yeah, think-o
<Chipzz_> an alternative approach would be using a symlink farm that gets updated at boot time
<superm1> was the 4s from the dkms_autoinstaller task, or the dkms status invokation in gdm's task?
<Keybuk> superm1: both combined
<cjwatson> make it a friendly-recovery task instead, or whatever that turns into?
<superm1> well i'm baffled how this is suddenly 4s.  when it lived as an init script before, shouldn't it have been just the same?
<Keybuk> cjwatson: we basically just dropped that
<Keybuk> superm1: no idea
<Keybuk> time regardless, it's wrong to do that
<superm1> what if someone installs a custom kernel?
<Keybuk> then the postinst of the kernel will run dkms
<Chipzz_> superm1: couldn't the last line of defence be a symlink/symlink farm?
<Keybuk> which will run the build
<Keybuk> and build the modules for that kernel
<superm1> i mean from src, not make-kpg
<Chipzz_> on a related note, aren't these drivers also stored in a ramdisk or such?
<Keybuk> if they install a custom kernel from source without running any of the kernel hooks, they won't have a whole world of things
<ion> superm1: Then she deserves what she gets. :-P
<superm1> Chipzz_, this is for any dkms built module, that might not be part of the ram disk
<Keybuk> like an initramfs
<Chipzz_> (which ALSO seems braindead)
<Keybuk> or modules.dep
<Keybuk> so they're going to have lots of "failed to boot" before they even *reach* dkms
<Keybuk> (bearing in mind that the kernel's own "make install" runs distro hooks)
<Caesar> slangasek: we're doing some more work on 0.25.1 in Debian
<Keybuk> so the only failure you're thinking of is someone building a kernel on one machine, and then copying, by hand, vmlinuz onto another and trying to boot with it
<Keybuk> that just isn't going to work
<Keybuk> for a whole metric shitload of reasons
<superm1> there has to be some situation that is coming up here, otherwise there wouldnt have been the situation occurring where gdm was "flashing" for a while while the module was getting booted in karmic
<superm1> *built
<Keybuk> no idea on that one
<Keybuk> but if there's a bug there, we'll fix it
<Keybuk> it may be already fixed by the code I ported from update-initramfs into dkms to build the module for the right kernel
<superm1> it was the gdm task dying over and over because X couldnt start because closed source blob Y wasnt ready
<Keybuk> if you updated the kernel and module in one pass, it wouldn't have worked before
<Keybuk> the blob Y should have been built before the system was rebooted
<superm1> agreed, but it wasnt, so thankfully there Was this last line of defense
<Keybuk> in which case, I'd say your "last line of defence" was hiding a genuine bug
<superm1> probably
<Keybuk> superm1: I don't mean to particularly pick on you today :p
<Keybuk> today was supposed to be a good day, with the new kernel going in, and lots of things speeding up
<Keybuk> and having the gdm breakage, dkms breakage, ifupdown breakage, etc. all in one go has not made me cheerful :p
<superm1> i'd still really like to at least keep that dkms task if it can be changed to not be causing such a large slow down
<Keybuk> I would not
<Keybuk> I think the task is absolutely unequivocably wrong
<Keybuk> because it defeats the entire point of keeping old kernels around
<Keybuk> you don't *want* new modules, changes to depmod, modules.order, etc. when you boot an old kernel
<Keybuk> you want what worked last time
<Keybuk> that's the only reason you keep them around at all
<superm1> yeah i suppose that makes sense
<Keybuk> if old kernels didn't have a "the new stuff didn't boot" value, we would have tried harder to get rid of them ages ago :D
<superm1> did you update the /etc/kernel/postinst.d calls when you uploaded these last few revisions?
<Keybuk> superm1: shouldn't need to - they were correct
<Keybuk> kernel postinst should build modules for itself (passing the newly installed kernel version)
<superm1> Keybuk, it was doing that by "start dkms_autoinstaller" if i'm not mistaken
<Keybuk> it looked like it invoked it directly?
<Keybuk> oh, blah
<Keybuk> no, I did change it, but then didn't upload
<superm1> http://linux.dell.com/git/?p=dkms.git;a=blob;f=kernel_postinst.d_dkms;h=3c7002b25dd5ebdfea7089557a20bfb38f067466;hb=HEAD
<Keybuk> fixed ;)
<Keybuk> FreeNode is being almost as reliable as my uploads today <g>
<superm1> Keybuk, okay how would you feel about a task for fglrx and one for nvidia  -provided by those packages that started on "starting gdm"?  It would just do a dkms status for that module for that kernel, and if it failed, run a build for that module for that kernel.  those were the two problem cases that were mostly interested in, and those are situations where you need the updated module even with older kernels
<superm1> haha yeah
<Pici> Keybuk: They're experiencing a ddos ;(
<Keybuk> superm1: no, same problem
<Keybuk> you'd rebuild a module that worked and replace it with one that didn;t
<Keybuk> pitti and I talked about this earlier, and we'll instead fix X to fallback to the free driver in that situation
<superm1> okay, that's a good enough consolation
<Keybuk> (where the nvidia blob driver can't run with the older kernel module)
<nixternal> anyone happen to know if the R packages are planned on making their way into main at all?
<cjwatson> nixternal: any reason why they should?
<Keybuk> I think we should veto that until they learn about namespaces
<nixternal> cjwatson: so I can add the support to one of the KDE Educational packages :)
<ion> keybuk: The current mountall code in bzr does some forks and execs before daemonizing, which confuses Upstart.
<Keybuk> ion: it does? which?
<ScottK> cjwatson: r-base is now a build-dep for kdeedu.  We can live without it if needed, but we like to provide the full experience for users.
<dholbach> any requests for sessions at  https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep  or sessions you'd like to give there?
<ion> keybuk: This is from a running system: http://pastebin.com/f3200af30
<ion> keybuk: Iâll do a strace from the initial mountall run, a moment...
<ion> keybuk: Huh. stracing initial mountall run shows it daemonizing first. But then, why does Upstart get confused about its pid when run without strace, and why does it fork-and-exec mounts before daemonizing when started from a running system?
<ion> keybuk: Ah! What confused Upstart was the cat /proc/cmdline in mountall.conf. As long as mtab canât be written, mountall wonât really fork-and-exec fake mounts before daemonizing.
<Keybuk> ion: yeah, was just thinking that both of those might be the bugs ;)
<Keybuk> the mounted() bit of mount_policy() should come out and move to after the fork
<Keybuk> and the cmdline stuff should be fixed
 * lamont lets pkgmanglebinary out of its timeout
<ion> keybuk: Hm. On two systems, network-interface (lo) and networking seem to hang in start/starting which causes rc-sysinit never to be started.
<Keybuk> yes, yes
<Keybuk> just fixed
<ion> Ach
<Keybuk> http://people.canonical.com/~scott/tmp/ratchet-lucid-20091215-4.png
<Keybuk> whee
<kirkland> Keybuk: https://bugs.launchpad.net/bugs/496798
<ubottu> Ubuntu bug 496798 in lintian "lintian should not complain about upstart jobs not looking like init scripts" [Medium,Confirmed]
<kirkland> Keybuk: any chance that's something you might be able to fix for the rest of us upstartifying our init scripts?
<kirkland> ;-)
<lamont> pitti: pkgmangler is out-of-jail, btw
<Keybuk> kirkland: no, but if someone else wants to fix it, go right ahead
<Keybuk> I have more than enough to do without learning Perl again :p
 * kirkland tried to pass the buck to Keybuk, but failed :-)
<Keybuk> cjwatson likes that kind of thing
<Keybuk> slangasek does too <g>
<Keybuk> hey, I remember your new boss practically *wrote* Perl ;P
<Keybuk> jiboumans: ^ :p
<cjwatson> not today, am trying to finish stuff off before going on holiday
<kirkland> Keybuk: I figured there was a snowball's chance in hell of you fixing lintian for upstart :-D
<kirkland> Keybuk: oh, good point ... jiboumans, wanna fix a bug by writing some perl?  :-)
<jiboumans> ... did i just get volunteered for something?
<slangasek> you've been invited to participate in the joys of Ubuntu collaboration
<kirkland> jiboumans: I filed bug 496798, lintian is erroneously complaining about Eucalyptus' upstart scripts
<ubottu> Launchpad bug 496798 in lintian "lintian should not complain about upstart jobs not looking like init scripts" [Medium,Confirmed] https://launchpad.net/bugs/496798
<Keybuk> kirkland: do I look like the kind of developer who runs lintian on his packages? :p
<kirkland> jiboumans: lintian *thinks* these upstart scripts are init scripts, and so it applies the init script checks on them
<kirkland> jiboumans: which fail miserably
<jiboumans> kirkland: if you can write it down in english, i can fix it in perl
<kirkland> Keybuk: hah ;-)  Nah, I just saw you were active online, and thought it would be fun to wind you up about this one
<kirkland> jiboumans: cool, i'll add some details in the bug report, and assign it to you; it'll be a "fun" bug to fix, that will make some Ubuntu developers happy
<Keybuk> kirkland: I know where you live
<jiboumans> .. i don't like this 'fun'
<Keybuk> Austin doesn't *have* to be saved when Texas is wiped off the map
<kirkland> jiboumans: well, marginally happier ... they're already pretty miserable if they're dealing with Keybuk's Upstart :-D
<jiboumans> kirkland: logs & linenumbers are our friend :)
<kirkland> Keybuk: :-P
<cjwatson> pitti: indicator-application permissions updated, although I'm afraid quite a lot of stuff moved into desktop-core as well (which is ubuntu-core-dev only) so you might not thank me for this update. unfortunately I don't have time to investigate it right now
<pH_> hey guys
<pH_> whats the best way to distribute ruby applications with dependencies on ruby gems and ruby?
<pH_> hello?
<pH_> whats the best way to distribute ruby applications with dependencies on ruby gems and ruby?
<forscher> sorry, no idea
<dobey> jpds: ping
<spotter> weird Q, why does ubuntu use the ondemand governor always?  shouldn't it use the performance governor when on AC?
<Keybuk> spotter: no
<Keybuk> you should not be able to significantly tell the difference between the two
<Keybuk> since ondemand ramps up the CPU as the load increases
<Keybuk> *except*
<Keybuk> that with ondemand, your power bill will likely be substantially cheaper
<Keybuk> and if you're using a laptop, your chances of reproducing will be higher
<Keybuk> (and amount of third degree burning to your legs lower)
<ScottK> Bug or feature, depending on whose laptop is is.
<spotter> I wouldn't say you can't tell the difference
<spotter> there's no way ondemand can provide as good as an experience as performance
<spotter> and if on AC, what's the benefit besides teeny tiny bit for environment
<dobey> hrmm
<spotter> to repeat what I tried to say b4, but may have been noised out I wouldn't say you can't tell the difference there's no way ondemand can provide as good as an experience as performance and if on AC, what's the benefit besides teeny tiny bit for environment
<pecisk> hmmmm, interesting, virtualbox-ose-guest-x11 in lucid depends on xserver-xorg-core (>= 2:1.6.2), and there is xserver-xorg-core is up to 2:1.7.3.901, but apt-get claims packagre brokage
<pecisk> brokage/breakage/s
<pecisk> split?
<pecisk> hmmmm, interesting, virtualbox-ose-guest-x11 in lucid depends on xserver-xorg-core (>= 2:1.6.2), and there is xserver-xorg-core is up to 2:1.7.3.901, but apt-get claims packagre breakage
<tjaalton> nothing interesting about that. vbox needs to be rebuilt
<tjaalton> it's the Provides that break the upgrade/install
<pecisk> tjaalton, do I have to report it as bug or it will be fixed anyway?
<tjaalton> pecisk: probably is already
<pecisk> tjaalton, yeah, found it
<qense> Bug 486024 looks somewhat like a duplicate of bug 466575 , but the first says the device is busy, the latter that it can't be found. Anyone here who knows a lot of devicekit and could help?
<ubottu> Launchpad bug 486024 in devicekit-disks "Safely remove drive fails to unmount if data was written to drive." [Undecided,Incomplete] https://launchpad.net/bugs/486024
<ubottu> Launchpad bug 466575 in devicekit "secure remove of external USB-HDD produces error" [Unknown,Confirmed] https://launchpad.net/bugs/466575
<qense> apologises, I've got to go If you feel like answering my question, please do, I'll try to read the backlog. You could always mark the bug as a dup by yourself if you think it is.
<andersk> Keybuk: there is a situation in which /etc/kernel/postinst.d/dkms is insufficient to guarantee that modules are always available for the current kernel.
<Keybuk> andersk: what situation is that?
<andersk> Namely, upgrading nvidia-185-kernel-source causes all old nvidia modules to be deleted and a new module for the current and newest kernels to be built.
<andersk> So if you boot into an older kernel after upgrading the module package, one needs to be compiled at boot.
<Keybuk> we've already discussed that
<Keybuk> we're going to make X fallback to the free in that case
<Keybuk> free driver
<andersk> Hmm, okay.  I missed that.
<andersk> However, video drivers arenât the only user of dkms.  openafs has the same problem, and thereâs no fallback there.
<Keybuk> and it's arguably a bug that nvidia-kernel-source *deletes* things
<Keybuk> andersk: it shouldn't delete things then
<Keybuk> kernel postrm already takes care of that
<andersk> But itâs important that the openafs kernel module is the same version as the userspace daemon, so it isnât good enough to keep old modules around for old kernels.
<Keybuk> so?
<Keybuk> then don't boot into old kernels with it
<Keybuk> or namespace the daemon by module version
<Keybuk> as we're already doing with things like perf
<Keybuk> their are proper and correct fixes for these things
<superm1> there is another situation that i just thought of too that was benefiting the postinst.  if a user is booted into say 2.6.32-7-generic, and installs 2.6.32-8-generic but doesn't reboot yet, but installs bcmwl-kernel-source lets say.  the postinst doesn't know that the user actually wants the module on both kernels, and the kernel postinst won't catch it on either
<Keybuk> yes it does
<Keybuk> I fixed that
<superm1> how?  the kernel postinst wont be called, if you install bcmwl AFTER installing the kernel
<Keybuk> why not look
<Keybuk> the same way we already solved this for the initramfs
<Keybuk> if you install 2.6.32-8-generic, then install something that goes in the initramfs
<slangasek> Keybuk: one more question about plymouth - the cryptsetup init script that you whiteboarded at UDS doesn't yet work reliably, because gdm kills plymouthd and once that happens, calling plymouth doesn't do anything sensible.  Is the X plymouth plugin still on the radar for lucid?
<Keybuk> lo and behold
<Keybuk> it works
<Keybuk> slangasek: (a) yes
<Keybuk> but also (b) gdm should never start before cryptsetup finishes
<andersk> The module postinst (at least if it uses /usr/lib/dkms/common.postinst) builds modules for the current kernel and the ânewestâ kernel, which solves that particular problem.
<Keybuk> now, I'm going to eat my dinner
<superm1> andersk, yeah, that's why i'm filing bug 497149 for anything not using it
<ubottu> Launchpad bug 497149 in lirc "Packages using DKMS should make use of /usr/lib/dkms/common.postinst" [Undecided,Fix released] https://launchpad.net/bugs/497149
<Keybuk> and watch Alicia Silverstone in a, like, really totally rad Jane Austen remake
<Keybuk> :p
<superm1> i think that will take care of this situation
<slangasek> Keybuk: why, and how do you intend to ensure this?  cryptsetup can be used on lots of devices not related to our FHS mounts...
<Keybuk> slangasek: I removed all that FHS/bootwait stuff
<Keybuk> mountall waits for everything now
<slangasek> uh
<Keybuk> I got sick of the whining
<slangasek> excluding network mounts, at least?
<andersk> OTOH, if the user upgrades from 2.6.32-7-generic to 2.6.32-8-generic while they also have 2.6.33~rc1 installed for occasional testing, that fix isnât quite good enough for them.
<Keybuk> slangasek: no everything
<Keybuk> right *going*
<slangasek> well, that'll be a critical bug then :P
<superm1> andersk, yeah, i'm not sure how to address that scenario
<andersk> Well, there are certainly ways.  One way would be for common.postinst to build modules for _every_ kernel, or at least every kernel thatâs at least as new as the current kernel.
<andersk> But there are very plausable scenarios under which that would take a really long time.
<superm1> yeah
<andersk> Maybe dkms could try to parse out the current default kernel from GRUB and compile modules for that one too?  (Ew.)
<slangasek> why is it a problem for it to take a long time, if it's done at package install time?
<andersk> It probably isnât a huge problem for most people, itâs just a little irritating for package upgrades to take many minutes.
<slangasek> if you're aware enough to be irritated by this, aren't you aware enough to remove the old kernels you're not using?
<andersk> *shrug* Perhaps.
<andersk> They might not be old kernels; it could just be someone whoâs installed several newer kernels than the current one but hasnât rebooted into any of them yet.
<andersk> If youâre okay with such users having to wait a long time for upgrades, I think this is a mostly workable solution.
<slangasek> andersk: I think that's better than making them wait at boot time, sure
<kees> bug 494575
<ubottu> Bug 494575 on http://launchpad.net/bugs/494575 is private
<Laney> you tease
<kees> LP API is being slow it's not private...
<wgrant> It is private.
<kees> let me clarify, my tool for unprivating it is being slow
<kees> bug 494575
<ubottu> Launchpad bug 494575 in debian-installer "it's beatiful" [Undecided,Fix released] https://launchpad.net/bugs/494575
<wgrant> Heh.
<ion> superm1: The xorg upload still leaves /etc/init/failsafe-x.conf to the system.
<ion> superm1: Ah, sorry. I see itâs supposed to.
<lamont> so... where is this REVU thing and how can I fetch source from someones upload to same?
<lamont> thouhg I suppose I should be asking in -motu
<cjwatson> lamont: revu.ubuntuwire.com
<lamont> thanks
<lamont> slangasek: you have implicit-pointer-functions checking globally now, holler if you find any false positives
#ubuntu-devel 2009-12-16
<ccheney> anyone happen to know the name of the dd program in the archive that shows status while writing?
 * ccheney heard about it a while back but can't find it when searching apt-cache
<slangasek> lamont: ta
<cjwatson> ccheney: grep-aptavail turns up a few possible candidates - dcfldd? pcopy? sdd?
<cjwatson> I suspect this problem has been solved a few different times:)
<ccheney> cjwatson: ah yea dcfldd
<ccheney> cjwatson: thanks, i searched for dd and somehow managed to overlook that one
<cjwatson> I did: grep-aptavail -e '\<dd\>'
<ccheney> ok
<smoser> anyone know how to tell init(upstart) to work in debug or verbose mode in /etc/init.conf ?  ie, the same effect that running 'initctl log-priority debug'
<slangasek> smoser: there's no /etc/init.conf; but you get the effect of running 'initctl log-priority debug' by adding an upstart job that runs 'initctl log-priority debug'
<slangasek> (or adding it to the start of whatever job you're currently debugging)
<smoser> the man page says there is a /etc/init.conf and the code and daemon seem to at least acknowledge it
<slangasek> well, ok
<smoser> slangasek, in ec2, i can't pass --verbose or --debug on kernel cmdline, but i wanted it to be turned on as soon as possible
<slangasek> I've never heard of init.conf before, and it obviously doesn't exist by default :)
<smoser> having a job run asap and doing initclt is what i think i have to do
<smoser> right. it doesn't exist, but man 8 init mentions it
<slangasek> cat >> /etc/init/debug.conf
<slangasek> description "debug me"
<slangasek> start on startup
<slangasek> task
<slangasek> exec initctl log-priority debug
<slangasek> ^D
<smoser> thank you
<smoser> i tried 'log-priority debug' in /etc/init.conf and it complained of unknown stanza. maybe i'm just supposed to put things like "normal jobs" there.
<crypt-0-> anyone awake?
<crypt-0-> i have my root partition pointing to the wrong one, even though fstab is pointing to the right one.
<crypt-0-> it asks for "cryptoroot" when fstab clearly tells it to ask for "cryptroot" (along with crypttab)
<ScottK> crypt-0-: Help is in #ubuntu or #ubuntu+1 if you are on Lucid.
 * crypt-0- knows, the answers are usually much more accurate here. So i will just lurk here in case someone answers it :)
<crypt-0-> I did just narrow the problem down, but now i just have a very simple question. "Where does GRUB2 ask for the root device?"
<Chipzz_> ccheney: did you mean pv?
<JanC> hm, seems like the Tracker people intend to release a non-developer version of tracker 0.7.x after the xmas/newyear period
<LucidFox> JanC> I take it tracker was removed from the default install at some point?
<LucidFox> Why, by the way?
<LucidFox> Eep.
<ScottK> StevenK_: If you do the sync in Bug #497289, then boost1.39 can die.
<ubottu> Launchpad bug 497289 in python-visual "Sync python-visual 1:5.12-1.1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/497289
<SandGorgon> just wanted to point you guys to a very interesting study of an alternative Linux driver architecture - Dingo (http://ertos.nicta.com.au/publications/papers/Ryzhyk_CKH_09.pdf). The paper is good in itself for the part where it studies the %age root-cause for driver problems
<tseliot> slangasek, Keybuk: what is it that should call  'plymouth ask-for-password --prompt="my prompt string" when unencrypting your disk?
<tseliot> bug #496765
<ubottu> Launchpad bug 496765 in plymouth "plymouth ask-for-password doesn't display --prompt argument" [High,Triaged] https://launchpad.net/bugs/496765
<slangasek> tseliot: the cryptsetup upstart job
<slangasek> (implemented in lucid, as of a few hours ago)
<slangasek> alternatively, the cryptsetup initramfs script, in the crypted-root case
<Keybuk> tseliot: 'wot 'e said
<tseliot> plymouth is not in the initramfs therefore the upstart job should be the right place to do it
<Keybuk> tseliot: installing cryptsetup puts plymouth in the initramfs
<tseliot> ah
<tseliot> ok, I'll have to play with it then
<Keybuk> because if you have to type a passphrase to boot, you don't care about boot speed
<Keybuk> especially not if you're james_w
<slangasek> tseliot: "the right place to do it" is always the initramfs, in the case of a crypted root system ;)
<tseliot> :-D
 * tseliot has never tried disk encryption
<Keybuk> tseliot: careful, you know what they say
<Keybuk> the first disk is free
<slangasek> if you have a spare disk partition, I can add a test case for you to the bug... but I guess it's a bit easier to debug this if you can start plymouthd manually outside of the boot sequence and e.g., attach remotely with ssh?
<tseliot> slangasek: also, about bug #496782, shall I simply not display any additional bullet?
<ubottu> Launchpad bug 496782 in plymouth "plymouth password dialog lets you type off the end of the box" [Low,Triaged] https://launchpad.net/bugs/496782
<Keybuk> probably much easier to debug in X :p
<Keybuk> just start plymouthd and plymouth --show-splash from an xterm
<tseliot> slangasek: yes, I use X and ssh for debugging
<tseliot> as Keybuk said
<dholbach> good morning
 * tseliot needs to check how gdm deals with long passwords
<tseliot> good morning dholbach
<dholbach> hey tseliot
<slangasek> tseliot: not displaying additional bullets is ok, though in that case I think it's best if bug #497115 can be fixed first :)
<ubottu> Launchpad bug 497115 in plymouth "plymouth ask-for-password doesn't register all of my keypresses when typing passphrase" [Undecided,New] https://launchpad.net/bugs/497115
<Keybuk> slangasek: you didn't rise to my joke! :'(
<slangasek> :-)
<tseliot> slangasek: I think I've noticed that too. I should bug upstream about it
<slangasek> Keybuk: sure I did, I let you know there are lower case letters in my passphrase
<Keybuk> tseliot: it might be because something else is reading from the console and plymouth isn't getting the characters?
<Keybuk> worth checking file descriptors in ssh
<Keybuk> it could also be plymouth sucking
<slangasek> Keybuk: it's reproducible for me even in the initramfs
<Keybuk> I've only tested stuff like that in X so far
<Keybuk> that'd be an interesting thing - does doing it in X work fine?
<tseliot> it sounds more like a plymouth issue. I managed to reproduce the problem in X
<Keybuk> cool, sounds like you're on top of that one :p
<slangasek> and cf. the comment I've just added to the bug - I think whatever event loop it has for processing input characters has no support for queuing :)
<tseliot> yes, more or less :-P
<Keybuk> tseliot: while you're in there, I have a theme/script improvement that'd be nice
<Keybuk> tseliot: I'd like to be able to display two different messages on screen
<Keybuk> plymouth message should go in the usual place
<Keybuk> but I'd like to do something like plymouth message "keys:..."
<tseliot> slangasek: I think I can improve that
<Keybuk> which goes along the bottom of the screen instead
<Keybuk> and not have the two cancel each other out
<Keybuk> tseliot: that's theme rather than code, right?
<tseliot> Keybuk: well, a theme *is* a program ;)
<Keybuk> you know what I mean <g>
<tseliot> yes, no C code would be involved
<dholbach> how far did we get with dropping lpia from lucid?
<dholbach> I'm looking at bug 488797
<ubottu> Launchpad bug 488797 in gnu-efi "Please merge gnu-efi 3.0i-2(main) from debian squeeze(main)" [Undecided,Confirmed] https://launchpad.net/bugs/488797
<dholbach> which still lists lpia in the changes
<tseliot> Keybuk: currently the text from message and the one from ask-for-password will appear on different lines. Is this what you need or just an additional message text?
<tseliot> text message
<Keybuk> tseliot: additional message text
<Keybuk> e.g.
<Keybuk> "Errors were found while checking /home"
<slangasek> dholbach: we're at the point where if lpia is the only diff in a package, it's reasonable to make it a sync instead
<Keybuk> then along the bottom
<dholbach> slangasek: it wouldn't be the only change :)
<Keybuk> "[F]ix them, [I]gnore errors, [S]kip mountpoint, [A]bort"
<slangasek> dholbach: then IMHO we should hang on to it for now
<dholbach> alrightie
<persia> dholbach: Last I heard, we planned to not spend time trying to maintain it, but there's some installer stuff that relies on EFI, so it might be more work to track it down and pull it out than port the patch.
<dholbach> good good, thanks guys
<slangasek> we seem to still have Packages files for lpia, though I know some of the archive admin tools no longer see it
<StevenK_> slangasek: Last I heard from lamont is that is going to require more DB hackery to kill them
<tseliot> Keybuk: ok, and what happens when you want to show another message? Do you overwrite the one at the top or the one at the bottom? And what happens to the other one?
<Keybuk> tseliot: if it's prefixed, it overwrites the one at the bottom
<Keybuk> if not, it overwrites the one at the top
<Keybuk> neither clears each other
<Keybuk> ie. to clear both, I'd have to send message "" and message "keys:"
<tseliot> Keybuk: ok, sounds good. Can you file a bug report about it with all these details, please?
<Keybuk> np
<tseliot> thanks
<Keybuk> slangasek: I really don't have any time to work on the bootwait problem
<Keybuk> I get dozens of mails *A DAY* of people complaining about it
<Keybuk> so I'm going to revert back to the jaunty behaviour
<Keybuk> if you want to try and make it work, be my guest
<slangasek> revert back to the jaunty behavior - the jaunty behavior is that any filesystem that isn't available at the time rcS runs is skipped
<Keybuk> no it isn't
<Keybuk> it's that any filesystem not available causes the script to fail
<Keybuk> and gives you a root shell
<Keybuk> (afaict)
<slangasek> well, that wasn't the case for network filesystems, at least
<persia> That wasn't my experience: the boot seemed to hang for a bit of extra wait with no response, and only bounce to a shell after 5 sec or so.
<Keybuk> persia: that's because there was a sleep 5 in there, asking you if you'd rather reboot instead
<slangasek> for those, the behavior was "try in rcS; try again when the network comes up"
<Keybuk> but we helpfully hid that message
<Keybuk> slangasek: right, network are a more special case
<Keybuk> either way, I think the friendlier recovery stuff already helps this
<Keybuk> mountall won't bomb out
<Keybuk> it'll prettily say "I can't find your /porn, shall I skip it?"
<slangasek> well, and if I say yes there and then the network comes up, does mountall try again?
<Keybuk> not if mountall has exited
<slangasek> and if I say "no", mountall never signals the boot to proceed, so gdm never starts, so the user can't log in and the network interface never comes up?
<slangasek> in which case that's a false choice; I don't want either of those things, I want the sensible behavior that the filesystem will be automatically mounted when the network comes up :)
<Keybuk> as I've already said, network mounts are treated specially
<Keybuk> you can't have that special behaviour :p
<Keybuk> unless you implement a way to have filesystem checks and cryptsetup prompts in X :p
<slangasek> oh, you said network /is/ special, you didn't actually say it was /treated/ specially ;)
<persia> cryptsetup is the tricky one, because there's all sorts of things that can go oddly.
<Keybuk> it doesn't "see" network devices until a network interface comes up
<Keybuk> though, that being said, NM brings up wired connections before gdm ;)
<Keybuk> and is deliberately started on local-filesystems
<slangasek> sure; wireless / vpn is the use case there
<Keybuk> yes...
<Keybuk> but that's *never* worked
<Keybuk> (that I can tell)
<slangasek> yuh-huh
<slangasek> :)
<Keybuk> first I have to not break things for everyone who has a working setup ;)
<Keybuk> especially since this is an LTS
<slangasek> I have a working setup that fits the above description
<slangasek> laptop; wireless; NFS mounts configured in /etc/fstab to automount
<Keybuk> then please help make it work
<slangasek> with jaunty, karmic, and lucid w/ current mountall, it works
<Keybuk> I've run out of ideas
<Keybuk> it won't work in lucid with the new mountall
<slangasek> What are the nature of the complaints about bootwait?  Because aside from having to introduce a new option in /etc/fstab that util-linux doesn't know about yet, it does actually seem to be the Right Thing
<Keybuk> that's the complaint
<Keybuk> people keep refusing to add the new option saying things worked before
<slangasek> hmm
<Keybuk> and I am required to be a bug contact for their bugs
<Keybuk> and I'm required to read every single one
<Keybuk> and I'm required to reply to them
<Keybuk> even the ones that say they're going to write to sabdfl and try and have me fired for incompetence
<Keybuk> and that kind of thing wears you down
<slangasek> well, if backwards-compatibility is the goal, I think blocking the filesystem signal on local filesystems + network filesystems w/ FHS mountpoints would do it
<slangasek> and have mountall hang around to wait for network filesystems w/ non-FHS mountpoints?
<Keybuk> mountall can't hang around once gdm starts
<Keybuk> it has to exit
<slangasek> why, if it's only going to process network mounts after that?
<Keybuk> because network mounts can have loop mounts on them
<Keybuk> which can require fsck
<Keybuk> and can require cryptseutp
<slangasek> well, *that* has never worked
<Keybuk> yes
<Keybuk> but before it didn't crash gdm ;)
<Keybuk> and X
<Keybuk> mountall likes to do that
<Keybuk> if plymouth exits, then we lose the ability to communicate with users
<persia> Can mountall emit something that starts a separate asynchonous job to handle the oddities?
<Keybuk> not really
<slangasek> I think you either treat those as blockers for the filesystem signal, so gdm isn't started until they're all there; or you ignore them as "crazy thing that depends on a network mount and isn't my problem"
<slangasek> I think either way of handling them is acceptable
<Keybuk> slangasek: that's kind of what I want to go towards
<Keybuk> NFS on systemy places will cause a wait
<Keybuk> anything with pass != 0 requires a wait
<Keybuk> that doesn't solve "I have /home/joe on NFS" though
<Keybuk> but then I can't see that that worked before
<Keybuk> except by luck
<slangasek> right, it was always racy
<slangasek> "always" - "as long as we've been bringing up interfaces with udev"
<Keybuk> that's pretty much ever in ubuntu
<Keybuk> we used to bring them up with hotplug ;)
<Keybuk> the real problem is that this whole thing is a *mess* of corner cases
<Keybuk> and the kinds of people with the corner cases don't test
<Keybuk> they just upgrade to the final release
<Keybuk> then cry, and start spouting rubbish like "where do I send the bill to Canonical for all the downtime?"
<Keybuk> and when I, not unreasonably, tell them to fuck off and die (politely) - I get e-mails from Millbank telling me off because they complained <g>
 * slangasek hehs
 * Keybuk is a bit emo, really
<slangasek> well, as long as my system doesn't end up with a dependency loop between /home/random and gdm and network-manager because I'm roaming on an ESSID I've never seen before, I'm happy
<slangasek> :)
<Keybuk> I'll notice too ;)
<Keybuk> most of my home directory is an NFS mount
<Keybuk> well, symlinks to an invented directory on the root
<Keybuk> /home/scott/Music -> /zelda/Music etc.
<Keybuk> so that's even more corner-y
 * slangasek punches NFSv4 in the face
<slangasek> bad packet storm
<chrisccoulson> siretart - i just saw the last few comments on bug 428884. i think the issue with updating xdg-screensaver to use the new API is that the inhibitors only remain for the life of the process that registered them
<ubottu> Launchpad bug 428884 in gnome-screensaver "gnome-screensaver-command --poke no longer inhibits screensaver" [Unknown,Confirmed] https://launchpad.net/bugs/428884
<chrisccoulson> if i can get an ACK for a SRU, then i'm just going to patch gnome-screensaver to make the old method work again
 * Keybuk stumbles across Ian Jackson's wikipedia entry again and chuckles at the quote
<dholbach> could anybody imagine giving a session about reading stack traces and fixing crashes at Ubuntu Developer Week? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has some empty slots
<dholbach> (any other development- or packaging-related topic would be welcome too)
<persia> dholbach: I can do the stack trace one, or, I'd prefer to give an update to PackagingWithoutCompiling: the dh7 way.
<dholbach> persia: both would be MUCH appreciated :)
<joaopinto> mvo, it seems that the apt's http redirect handling code does not woek when you have an http proxy set, once I have some time to reproduce I will file a bug report
<joaopinto> s/woek/work :P
<joaopinto> it's just returning the 302 response
<persia> dholbach: At those hours, both is unlikely (all the sessions are scheduled for the times I try hardest to be asleep)
<dholbach> I know
<persia> But pick one, and stick me in the 20:00 slot of your choice.
<persia> (Except Wednesday)
<dholbach> persia: just pick the one that suits you best
<persia> Anyone else up for doing stacktraces?
 * persia thinks stacktraces are more important, but doesn't really want to do it *again*
<siretart`> chrisccoulson: AFAIUI, the point of xdg-util is to provide a proper abstraction for applications against the used screensaver implementation. I agree that this is difficult to implement in a shell script, so I propose to rewrite xdg-screensaver after revisiting the various used screensaver implementations
<cjwatson> dholbach: 488797's submitter should be asked why he didn't contact the person who touched the package last, as instructed on merges.ubuntu.com :P
<dholbach> cjwatson: you strike me as a good person who could give a developer week session about how to do merges right! :-)
<siretart`> chrisccoulson: as for the semantic change in the API, right, the rewrite would probably need to implement some kind of timeout and guesswork to fit into the new gnome-screensaver system
<dholbach> cjwatson: I can offer you a couple of different session slots, no problem: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep :-)
<siretart`> chrisccoulson: btw, do you know if xdg-utils upstream, the portland initiative, is still active? it looks pretty abandoned to me TBH
<cjwatson> I suppose I asked for tyhat
<cjwatson> -y
<dholbach> cjwatson: but you're right, it's a valid question to ask :)
<chrisccoulson> siretart` - i'm not too sure if it's still active or not
<bryce> I wrote the original xdg-screensaver in xdg-utils
<siretart`> chrisccoulson: in any case, the idea of that initiavtive is great!
<cjwatson> dholbach: I can probably do Fri 17:00
<siretart`> bryce: ah, cool! what's the current upstream status of it?
<dholbach> cjwatson: that'd be fantastic - can I pencil you in?
<bryce> the original version I did had a timeout functionality, but it got lost in a rewrite
<cjwatson> dholbach: go ahead
<dholbach> awesome
<dholbach> cjwatson: done, muchas gracias! :)
<mvo> joaopinto: oh, do you have a example repo? i have a squid runing here
<bryce> siretart, waldo was the last guy actively working on xdg-utils last I checked
<bryce> dunno if he's still working on it, probably not
<siretart`> bryce: it seems to me that xdg-utils is one of the last freedesktop projects that still use CVS. and the last commits are years ago, so I'm unsure about its status
<siretart`> perhaps I should just go ahead and fork it in some git or bzr branch
<joaopinto> mvo, now that I think on it, the person is using apt-cacher-ng as the proxy, it could be an apt-cacher-ng issue
<joaopinto> mvo, deb http://ftp.heanet.ie/mirrors/www.getdeb.net/getdeb/ubuntu/ karmic-getdeb apps
<joaopinto> ops, that's a directly link sorry
<bryce> siretart, go for it
<joaopinto> mvo, deb http://archive.getdeb.net/ubuntu karmic-getdeb games
<bryce> siretart, if you need help understanding how it works or the design I'd be happy to field questions
<bryce> it's been quite a few years since I looked at it, but might be of some use
<joaopinto> mvo, it's an apt-cacher-ng issue, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556234, sorry :P
<ubottu> Debian bug 556234 in apt-cacher-ng "apt-cacher-ng: cannot handle HTTP redirection (e.g. 302 Found)" [Important,Fixed]
<siretart`> bryce: don't expect results from me on xdg-utils this year. I'm already pretty busy at work and with implementing symbol versioning in ffmpeg upstream and debian.
<mvo> joaopinto: thanks, ok
<siretart`> I guess I could start working on that in january of february
<siretart`> bryce: but thanks for the offer!
<bryce> yep, I suppose we're all going to turn into pumpkins within a week or so ;-)
<joaopinto> mvo, btw, we are using apt with http redirect on playdeb/getdeb in a large scale, it has been reliable
<mvo> joaopinto: sweet, I'm happy to hear that
<dholbach> could anybody give a session about setting up daily builds at  https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep ?
<joaopinto> dholbach, hey, hard job this week, heads hunting :)
<dholbach> joaopinto: so far things are looking quite good :)
<mathiaz> soren: hi!
<mathiaz> soren: are you looking after https://wiki.ubuntu.com/AutomatedServerTestingSpec?
<gp> hello my laptop Mother board just went off ...how do i recover my data
<gp> my home directory was encrypted
<jpds> gp: User support in #ubuntu.
<jb-laptop> I need to do a sync request for several packages that have newer versions in Debian. Would an archive admin require them as single bugs, one for each package, or one bug for all packages?
<cjwatson> jb-laptop: it's easier as single bugs because then our scripts can take care of more of it for us
<cjwatson> jb-laptop: we have a script to which we feed bug numbers (after manual verification) and it does the sync and closes the bug; this doesn't work with multiple syncs in one bug
<jb-laptop> cjwatson: thanks for the clarification
<soren> mathiaz: That's the idea, yes.
<mathiaz> soren: ok - thanks
<apw> cjwatson, who looks after the .ddeb magic ?
<dholbach> apw: pitti :)
<apw> thanks ... seems they have been found, all is well
<qense> Bug 486024 looks a bit like a duplicate of bug 466575 , but the error message in the first says the device is busy, the latter that it can't be found. Anyone here who knows a lot of devicekit and could help?
<ubottu> Launchpad bug 486024 in devicekit-disks "Safely remove drive fails to unmount if data was written to drive." [Undecided,Incomplete] https://launchpad.net/bugs/486024
<ubottu> Launchpad bug 466575 in devicekit "secure remove of external USB-HDD produces error" [Unknown,Confirmed] https://launchpad.net/bugs/466575
<seb128> qense, try asking to pitti when he's around he might know but he's not there today
<qense> ok, thx
<persia> I wouldn't think they are duplicates.
<persia> I get the symptoms of 486024 all the time just because I forget to stop programs, etc.
<persia> But 466575 looks like some issue with the device
<qense> It does have a duplicate
<qense> which is bug 495462
<ubottu> Launchpad bug 495462 in devicekit-disks "Safely remove 16 GB USB Flash drive - "Unable to stop" (dup-of: 466575)" [Undecided,New] https://launchpad.net/bugs/495462
<ubottu> Launchpad bug 466575 in devicekit "secure remove of external USB-HDD produces error" [Unknown,Confirmed] https://launchpad.net/bugs/466575
<Whoopie> pitti: Hi, how can we proceed with bug 481448?
<ubottu> Launchpad bug 481448 in vlc "VLC lacks build-dep on libupnp3-dev" [Undecided,New] https://launchpad.net/bugs/481448
<Whoopie> pitti: I got the ACK from jdong
<smoser> Keybuk, is there a way in 'init.conf' to have the same effect as '--verbose' or '--debug' on kernel command line?
<smoser> slangasek, gave me a job that ran on 'starting' that did 'initctl' which was basically good enough, but now i'm just wondering what exactly init.conf expects in it. is it "just another job" ?
<jdstrand> Keybuk: hi, I want ufw to be running before any network devices start receiving packets. I had "start on net-device-added INTERFACE=lo", but lo may start after eth0. Is "start on net-device-added" what I want instead? (since upstart won't keep starting a started job)
<jdstrand> Keybuk: I thought I wanted "start on starting network interface", but that didn't work (on karmic anyway)
 * jdstrand tries "start on starting network  interface"
 * jdstrand tries "start on starting network-interface"
<Keybuk> smoser: there is no init.conf
<smoser> init.conf is mentioned by the man page, and the upstart daemon in lucid acknowledges it, complaining about bad syntax
<smoser> there is no default file, no
<jdstrand> a '-' seems to make all the difference
<smoser> Keybuk, what did you mean by "there is no init.conf" ?
<Keybuk> smoser: there's no such thing
<jdstrand> Keybuk: revised question: is "start on starting network-interface" ok to do in ufw.conf to achieve my goal and generally not screw things up?
<smoser> $ dpkg-query --show upstart
<smoser> upstart 0.6.3-11
<smoser> $ man init | grep init.conf
<smoser>        /etc/init.conf
<Keybuk> jdstrand: as long as that's *all* you have
<smoser> $ echo "foo bar" | sudo tee /etc/init.conf
<smoser> foo bar
<Keybuk> jdstrand: and as long as you do things in pre-start like network-interface-security
<smoser> $ tail -n 1 /var/log/daemon.log
<smoser> Dec 16 14:37:57 ubuntu init: /etc/init.conf:1: Unknown stanza
<Keybuk> otherwise your script will be run *every*single*time* a network interface comes up
<smoser> maybe i'm way off base ? but it sure looks like init is responding to an init.conf
<jdstrand> Keybuk: my pre-start is: pre-start exec /lib/ufw/ufw-init start
<Keybuk> smoser: it's kinda lying :p
<jdstrand> Keybuk: that's it
<Keybuk> jdstrand: that should be fine - no "task" in the job?
<jdstrand> Keybuk: there is no task in the job, no
<Keybuk> cool
<Keybuk> should work then
<Keybuk> you might want or starting networking or starting network-manager in there too
<Keybuk> like the n-i-s one
<jdstrand> Keybuk: ok, I'll test that here on systems with and without nm, and upload if it works ok
<jdstrand> Keybuk: thanks
<smoser> so, the gist of the above is that 'init.conf' is undefined behavior, and if i want to enable debug early, i should do a 'start on startup' task with initctl exec. is that right, Keybuk ?
<Keybuk> smoser: initctl log-priority you mean?
<smoser> right
<Keybuk> you may as well just add --verbose to your kernel command-line though ? :)
<smoser> on ec2 you can't change kernel params
<smoser> but i can write a file and reboot
<Keybuk> smoser: there's increasing numbers of justifications for having init.conf do something useful
<Keybuk> log priority being one
<Keybuk> default environment another
<SEJeff> jcastro, ping
<jcastro> SEJeff: pong
<SEJeff> jcastro, Can you move the ip of gnomejournal.org? Redhat relocated all of the gnome infrastructure to a new colo
<jcastro> SEJeff: already did it just now, paul got ahold of me
<SEJeff> jcastro, If you just make it a cname to window.gnome.org you won't have to update it the next time something like this happens. Otherwise, the new ip is 209.132.180.167
<SEJeff> jcastro, Ah sorry for bothering you then.
<jcastro> no worries, doublechecking is always appreciated!
<SEJeff> thanks
<seb128> is there anybody who feel like reviewing a short patch to fix a libdvdnav locking issue on this channel?
<seb128> bug #466389
<ubottu> Launchpad bug 466389 in gstreamer0.10 "totem hangs when try to play DVD" [Low,New] https://launchpad.net/bugs/466389
<seb128> comment #21 on the bug
<seb128> hum
<seb128> slangasek, ^? ;-)
<seb128> mterry, hey
<seb128> mterry, dunno if you read alex comment but the nautilus patch you submitted recently had an annoying bug
<seb128> mterry, just in case you were shipping it somewhere you might want to fix it
<slangasek> seb128: dvdnav_clear() tries to call pthread_mutex_lock() a second time; trivially correct
<seb128> slangasek, ok thanks
<seb128> slangasek, want to sponsor it since you reviewed the change? ;-)
<slangasek> Keybuk: confused by the initramfs-tools 0.92bubuntu56 changelog - surely anything that would interrupt the initramfs and cause you to need to type should use the correct keymap, with or without fb?
<slangasek> seb128: tricksy!
<slangasek> seb128: yeah, I can do that
<seb128> lol
<seb128> slangasek, thank you ;-)
 * seb128 is trying clean a bit the sponsoring queue before holidays
<Keybuk> slangasek: that's a hell of an edge case
<slangasek> seb128: oh, except that patch has already been accepted into lucid via unstable :)
<Keybuk> it's not like anything in the initramfs understands chinese ;)
<slangasek> Keybuk: but it understands azerty quite well
<seb128> slangasek, oh, good, I should have checked that first
<seb128> slangasek, thanks ;-)
<Keybuk> slangasek: that should still work once I've finished these changes
<Keybuk> all I've done is removed the script that sets the keymap in the normal sequence
<Keybuk> not the code that does it in the failure case
<slangasek> Keybuk: ok
<Keybuk> there's some joining-up to do still
<Keybuk> but you shouldn't need to type, unless you get the panic shell, right?
 * Keybuk checking he hasn't missed something
<slangasek> Keybuk: well, I will need to type, with or without splash, to type my passphrase; but I guess I'm guaranteed to always have the fb there, even with nosplash set?
<slangasek> --> with splash not set
<Keybuk> slangasek: correct
<Keybuk> and splash not set doesn't mean plymouth won't start
<Keybuk> it just means plymouth will use a text renderer instead of a graphical one
<slangasek> that's the only non-failure case I know of when you need to type in the initramfs, then
<slangasek> assuming break=foo is treated as "failure"
<Keybuk> yeah it is
<Keybuk> basically idea is anything that calls panic() will set up the keymap
<Keybuk> actually it does run_scripts /scripts/panic
<Keybuk> because that's where I'm putting the plymouth quit thing
<Keybuk> rather than hardcoding in the initramfs
<Keybuk> so the keymap stuff will be in there too
<slangasek> cool
<stgraber> btw, I was wondering, is the plymouth from yesterday supposed to stop and prompt for the passphrase (it doesn't here, it simply continues booting without the encrypted partition)
<slangasek> stgraber: if you also have the cryptsetup from yesterday?
<stgraber> yeah, I basically updated everything this morning
<stgraber> I see it's showing some cryptsetup thing on top of the plymouth splash but boots without prompting for the key, then I get gdm and no /home mounted ;)
<slangasek> stgraber: bug report wanted, then - please attach /etc/crypttab and /etc/fstab, and tell me which device (if there's more than one) fails to decrypt
<stgraber> ok, will do
<slangasek> eh, really?
<slangasek> gdm was always supposed to wait on /home, per mountall
<slangasek> Keybuk: ^^ did that change recently?
<Keybuk> slangasek: no
<slangasek> funfun
<Keybuk> plymouth doesn't go in until I'm happy it won't regress our boot speed
<Keybuk> so the mountall that deps on it won't go in either
 * slangasek nods
<Keybuk> want to make sure the whole cryptsetup and friendly recovery stuff works nicely too obviously
 * Ng taps finger at grub-probe. my disks haven't changed since the last kernel postinst you ran in a few seconds ago, but you go nuts and eat all my CPU
<slangasek> stgraber: um... you have /home marked 'noauto' in /etc/fstab? :)
<stgraber> slangasek: that'd explain some things ... ;)
<slangasek> followed up on the bug... thanks for sending me an easy one ;)
<stgraber> slangasek: hehe, rebooting now, there can still be an actual bug (other than a user one ;))
<firatcan> Headphone jack detection doesn't work on my mbp. I am trying to write a script to change mixer levels when the headphone is plugged. How can I detect the HPs are plugged in?
<stgraber> slangasek: sorry, looks like I have an actual bug :)
<stgraber> now it justs get stuck at the ubuntu splash logo and does nothing
<slangasek> doh!
<stgraber> if I start without the splash, it prompts for the key but doesn't seem to take the input
<stgraber> so I had to press ESC and set it to noauto again so I'd be able to boot (that's probably I had it commented already ;))
<slangasek> stgraber: what version of cryptsetup?
<stgraber> 2:1.1.0~rc2-1ubuntu5
<slangasek> ok
<slangasek> can you send me /var/log/udev.log?
<stgraber> maybe something has a different behavior when the root isn't encrypted ?
<stgraber> sure, want that attached to the bug ?
<slangasek> yes, please
<slangasek> hmm, so without splash you see the prompt
<slangasek> if you hit ESC at the splash logo, what do you see?
<zul> kees: when you get a chance can you review libcap-ng?
<stgraber> I'll need to reboot for that, IIRC I saw a sda2_crypt (failed) and then the bash prompt but I'm not 100% sure
<kees> zul: still slogging through email backlog.
<stgraber> I also remember the shell being broken so I had to "reset" it so I'd see what I'm typing
<kees> zul: but yeah, if it's been assigned to me, I'll hit it.
<zul> kees: ok
<stgraber> Yeah !! Just received my N900 :)
<jjardon> hello, the VCS imports of GTK is suspended: https://code.launchpad.net/~vcs-imports/gtk/head. I tried to change the location of the sources from http://svn.gnome.org/svn/gtk+/trunk to git://git.gnome.org/gtk+ but I don't have the required permissions, Could someone fix this?
<beuno> jjardon, git:// branches aren't allowed
<beuno> they need to be http/https
<beuno> (I can update it for you)
<jjardon> hello beuno, I think git:// directions worked well for other projects I've imported. But anyway, It'd be great if you update the gtk+ project (also, I think a lot of gnome project need and update to point to the new git repos)
<beuno> jjardon, I get: The URI scheme "git" is not allowed. Only URIs with the following schemes may be used: http, https, svn
<beuno> jelmer, would you know anything about this?
<beuno> I'll try http://git.gnome.org/gtk+
<jjardon> beuno, I've used this form: https://code.launchpad.net/+code-imports/+new
<jelmer> beuno: you need to switch to git
<jelmer> beuno: It sounds like the import is still set to svn
<beuno> jelmer, you should have access to change tehat now
<beuno> could you take a peak?
<beuno> maybe there isn't anything on the web UI to specify svn/git?
<beuno> (or it can't be changed)
<jelmer> doesn't look like there is a way to change the kind of the import
<jelmer> I'll have to remove the existing one and create a new import
<jelmer> jjardon: is it ok if I remove the existing import
<jelmer> jjardon: ?
<jjardon> jelmer, https://code.launchpad.net/~jjardon/gtk/trunk ? sure
<jjardon> https://code.launchpad.net/~vcs-imports/gtk/head is already suspended
<jelmer> jjardon, the error for your import failing seems different
<jjardon> jelmer, Anyway, I didn't want have my own branch, I only wanted to update the main repo to the new git sources
<jelmer> jjardon: ok
<jjardon> Also, I'd like to help to move all the existing Gnome projects to the new git repos
<ion> Only allowing http:// in preference to git:// is pessimal. For Git, http is greatly inferior.
<jjardon> jelmer, so, If you need help, please ping me ;)
<beuno> ion, we do offer git://, I got confused by the UI  :)
<jelmer> ion: in fact, we don't support imports over http for git repos
<beuno> heh
<ion> Ok, good
<james_w> acpi-support is a native package?
<james_w> i.e. lp:~ubuntu-core-dev/acpi-support/trunk is the canonical upstream trunk?
<bigon> hi, any reasons the locales files have been split out of eglibc pkg? the file are not in sync and this lead to some issues like bug #497497
<ubottu> Launchpad bug 497497 in langpack-locales "Wrong first day of week in fr_BE" [Undecided,New] https://launchpad.net/bugs/497497
<malev> Hi, is Steve Langasek here?
<malev> ... or maybe: Steve Langasek is here? :D
<ScottK> malev: He's slangasek
<malev> ScottK, thanks.
<ScottK> You're welcome
<malev> slangasek, hi, I'm malev from the bugsquad. You've reported a bug some days ago, and I'm watching it. I've asked about it in the channel, but we are not sure about it.
<bdmurray> malev: I've updated the bug with what I've discovered.
<malev> checkin it
<bdmurray> I believe that slangasek was checking very early
<malev> bdmurray, nice research!!
<malev> awesome
* mthaddon changed the topic of #ubuntu-devel to: Launchpad will be down/in read-only from 22:00 UTC until 23:00 UTC for a code update | Lucid Alpha 1 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBu
<ebroder> How does DEP-3 interact with the "## DP:" comments in dpatches?
<ebroder> (Is there an example of a dpatch that follows DEP-3 somewhere?)
<ion> keybuk: http://launchpadlibrarian.net/36876612/initramfs-tools_0.92bubuntu56_0.92bubuntu57.diff.gz +rm "${DESTDIR}/lib/modules/${version}/modules.*map"
<ion> keybuk: Probably shouldnât have "" around the *
<Keybuk> oh good point
<Keybuk> meant to close them before the "
<Keybuk> will fix that tomorrow
 * Keybuk finally made a big step towards figuring out why gdm won't start sometimes
<ion> What seems to be the problem?
<Keybuk> the local-filesystems event gets blocked
<Keybuk> not sure by which yet
<Keybuk> but it won't complete
<Keybuk> so mountall is still waiting for it
<ion> Ok
<smoser> anyone able to suggest kvm invocation of lucid guest that will avoid going into graphics mode , so i can use '-curses' ?
<smoser> i'm trying: -append "root=/dev/sda ec2init=0 nomodeset" -nographic -curses
<slangasek> pitti: "fix daemon.log to not be written synchronously" - er, no?
<slangasek> pitti: if things are triggering writes to daemon.log during normal operation, /that/'s a bug that we should fix; but daemon.log is the Secure Record of People Doing Stuff To The System, it's synchronous intentionally and this shouldn't be changed to save a ÂµW :)
<slangasek> Keybuk: why would you expect "recreating" the lvm device in the real system (bug #456274) to require re-entering a passphrase?
<ubottu> Launchpad bug 456274 in usplash "mountall 0.2.5 and cryptsetup fail to boot when using usplash" [Undecided,Confirmed] https://launchpad.net/bugs/456274
<slangasek> (which is the only part that cryptsetup is responsible for)
<Keybuk> slangasek: I wouldn't, but I'm guessing that cryptsetup is blocking udev's operation somehow
<Keybuk> ie. when udev says the underlying block device is ready, cryptsetup will be run
<Keybuk> and normally that would create the /dev/mapper device
<Keybuk> but I'm guessing that because it already exists (because it was created in the initramfs), things don't work out that way
<Keybuk> and that somehow blocks the uevent for the mapper device too
<slangasek> Keybuk: there's also no "when udev says the underlying block device is ready" in karmic
<Keybuk> in the old days, waiting 3 minutes tended to work
<Keybuk> slangasek: huh?
<Keybuk> there is
<Keybuk> it's called a uevent
<slangasek> a uevent that cryptsetup pays no attention to
<Keybuk> that's where the whole thing gets confusing
<Keybuk> the fact is that this works on every dm device *except* cryptsetup ones
<Keybuk> so the problem must be with cryptsetup
<Keybuk> even if it's somewhere else
<slangasek> it works for dm devices *including* cryptsetup ones
<Keybuk> but please do debug
<slangasek> I have the exact setup the submitter describes
<Keybuk> and it works for you?
<slangasek> and it works for me
<Keybuk> I have an LVM kees-approved setup
<Keybuk> and it works for me there too
<slangasek> I really think the problem he's having is that he has a broken / line in /etc/fstab
<Keybuk> that shouldn't matter
<Keybuk> mountinfo overrides fstab
<slangasek> there've been other me-tooers on the bug that don't even use cryptsetup
<Keybuk> so what was mounted when the initramfs exits is what mountall really uses
<Keybuk> mountall gets me-tooers from just about everyone :(
<slangasek> hum; then surely mountall is wrong regardless, because in that case it should never be waiting for /?
 * kees snickers
 * kees imagines running around with a rubber "approved" stamp for VG configs
<Keybuk> slangasek: yes
<Keybuk> it has to wait for the device to exist and be probed before it can remount it read/write
<Keybuk> otherwise if blkid is running, and it's on lvm, etc. you end up with "device in use" issues
<slangasek> ah
<Keybuk> you can't just mount it read/write willy nilly
<Keybuk> and you can't leave it read/only :)
<Keybuk> if you don't have an initramfs (which we support)
<Keybuk> than you also have the issue where the kernel may have mounted the root device
<Keybuk> but it doesn't actually exist in /dev yet
<slangasek> right
<Keybuk> it's all a bit confusing really
<Keybuk> this is stuff that should just work
<Keybuk> all mountall is waiting for is the uevent from udev to say the device is made
<Keybuk> (and no helpers are running on it anymore)
<Keybuk> if that doesn't happen, it means udev doesn't know about the device
<Keybuk> which means it shouldn't exist in /dev :p
<slangasek> well, I don't see how what cryptsetup is doing could break that
<Keybuk> causing pain
<ebroder> Can anybody point me at a dpatch that follows DEP-3?
<Keybuk> ebroder: any in gdm
<ebroder> Keybuk: Huh? gdm's patches appear to be simple-patchsys, not dpatch
<Keybuk> so? they still have patch tags at the top
<james_w> ebroder: "For patch-systems like dpatch that require the patch to be a standalone script, the shebang line is ignored and it is possible to put those fields in comments. The line should then follow the format â# <field>â. For multi-line fields, the subsequent lines should start with â#  â (hash followed by two spaces) so that they start with a space once â# â (hash followed by a space) has been stripped from the beginning."
<ebroder> Right, I saw that - I wasn't sure how that interacts with dpatch's support for "## DP:" and such, though
* mbarnett changed the topic of #ubuntu-devel to: Launchpad will be down/in read-only from 22:00 UTC until 23:59 UTC for a code update | Lucid Alpha 1 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithB
<kirkland> slangasek: Keybuk: I have a upstart question that I'm sure I will phrase poorly
<slangasek> kirkland: "turquoise"
<syn-ack> slangasek: What if he likes "lavender" better? ;) /me runs
<kirkland> slangasek: so there's a general "eucalyptus" upstart script
<kirkland> slangasek: the other controllers start on started eucalyptus
<slangasek> syn-ack: sorry, not supported
<syn-ack> slangasek: I merely kid. :P
<kirkland> slangasek: and in all of the current cases (sans node-controller), there's an exec of eucalyptus-cloud, which daemonizes, and the eucalyptus upstart script starts happily
<kirkland> slangasek: i've ported the eucalyptus-nc init script to upstart now
<kirkland> slangasek: and have it set to start on started eucalyptus
<kirkland> slangasek: however, in this case there is no eucalyptus-cloud daemon
<kirkland> slangasek: so i'm conditionally execing sleep 999999999d
<kirkland> slangasek: which works
<kirkland> slangasek: but I'm guessing it ain't pretty
<kirkland> slangasek: i figure there's got to be a better upstarty way of doing this
<kirkland> slangasek: or "must" upstart daemonize something to consider the job "started" ?
<slangasek> what is it that's execing sleep?
<kirkland> slangasek: the upstart job
<slangasek> /which/ upstart job?
<kirkland> slangasek: eucalyptus
<kirkland> slangasek: lemme pastebin
<slangasek> ok
<kirkland> ubuntu@beagle:/etc/init$ pastebinit eucalyptus.conf
<kirkland> http://pastebin.com/f6c05156f
<kirkland> ubuntu@beagle:/etc/init$ pastebinit eucalyptus-nc.conf
<kirkland> http://pastebin.com/f2657fc5e
<kirkland> ubuntu@beagle:/etc/init$ pastebinit eucalyptus-nc-publication.conf
<kirkland> http://pastebin.com/fad45411
 * kirkland crosses his arms, taps his foot, and stares coldly at Launchpad
<syn-ack> kirkland: I'm still getting remarks that it's in ro mode
<kirkland> syn-ack: hence my look of consternation
<syn-ack> hah
<slangasek> kirkland: so let me see if I understand the reason for this kludge
<zul> james_w: when you get a chance can you import samba into bzr
<slangasek> you have a eucalyptus job, on which the other jobs depend; but when eucalyptus-nc is installed, the eucalyptus job should be a no-op, but you still want all the other jobs that depend on it (including eucalyptus-nc) to start?
<james_w> zul: queued
<zul> james_w: meric
<kirkland> slangasek: sort of ...
<zul> james_w: thanks even :)
<kirkland> slangasek: its more that the eucalyptus job is provided by the eucalyptus-common package
<kirkland> slangasek: on which all other eucalyptus parts depend
<kirkland> slangasek: thus it's installed everywhere
<kirkland> slangasek: and makes for one stop shopping when you want to start/stop/restart/status your eucalyptus setup
<kirkland> slangasek: so far that's fine and dandy for cloud/walrus/sc/cc
<kirkland> slangasek: and today i'm adding support for nc
<kirkland> slangasek: which doesn't really actually need the eucalyptus job to start any real daemons
<kirkland> slangasek: but for the consistency with the other bits, i added the kludge
<kirkland> slangasek: alternatively, i could have eucalyptus-nc start on [23]
<slangasek> kirkland: does the eucalyptus job do anything that eucalyptus-nc needs to have happen before it starts?
<kirkland> slangasek: but it would make for some inconsistency with the rest of the start/stop/restart eucalyptus which is used everywhere else
<kirkland> slangasek: make /var/run/eucalyptus?
<kirkland> slangasek: nothing terribly important
<slangasek> so you can do one of two things
<slangasek> refactor eucalyptus into a eucalyptus-base job and a eucalyptus job, with eucalytpus-nc and eucalyptus both depending on the -base job (which I guess just does the setup at that point, i.e., /var/run/eucalyptus)
<slangasek> or get rid of the 'start on starting eucalyptus' from eucalyptus-nc, use something more correct (such as a runlevel start condition, yes) and mkdir -p /var/run/eucalyptus
<kirkland> slangasek: hmm, okay
<kirkland> slangasek: i have the latter working
<slangasek> in any event, I'm sure you don't want to be adding artificial dependencies on things you don't actually need running in order to start the node controller :)
<slangasek> and if you don't do that, the sleep is irrelevant
<slangasek> btw, your new job will whine when the eucalyptus-nc package is removed but not purged
<kirkland> slangasek: do i need "respawn" if i start on runlevel?
<slangasek> Keybuk is eventually going to give us magic state to take care of that, but in the meantime I've been writing my jobs to key off a non-conffile shipped in the package
<slangasek> kirkland: only if respawn is the behavior you want
<slangasek> if the daemon dies, what do you want to have happen?
<kirkland> slangasek: hmm, sure, respawn, i like it
<kirkland> slangasek: okay, so about the package purging ....
<kirkland> slangasek: i'm dropping the changes to the eucalyptus package
<kirkland> slangasek: going with your runlevel start on suggestion
<kirkland> slangasek: where am i keying on a conf file now?
<slangasek> http://pastebin.com/f2657fc5e
<Keybuk> yeah
<slangasek> actually, I guess that job doesn't whine
<Keybuk> basically I intend to work the xmas break on things like that
<slangasek> it just /runs/, even when the package is removed :)
 * Keybuk remembers when he had a life
<slangasek> kirkland: actually, the job will get as far as trying to run euca_test_nc before it fails
<slangasek> and then 'exit 1', meaning the job will show as failed instead of administratively stopped
<slangasek> oh, and if you mark it respawn, upstart is going to try running it several times before giving up
<kirkland> slangasek: so i should check $(which euca_test_nc) ?
<slangasek> I'd write it as [ -x /usr/sbin/euca_test_nc ] || { stop; exit 0; }
<slangasek> alternatively, you can wait for Keybuk's Christmas present
<kirkland> slangasek: got it
<kirkland> slangasek: i added that to the top of pre-start
<Keybuk> ho ho ho
<slangasek> (I myself have not been consistent about handling this case in the jobs I've written, fwiw)
<kirkland> slangasek: any other feedback?
<kirkland> Keybuk: i saw your note about wanting to look at new upstart scripts
<slangasek> well, let me read the whole job then :)
<kirkland> Keybuk: shall i paste them for you?
<Keybuk> kirkland: e-mail them
* mbarnett changed the topic of #ubuntu-devel to: Launchpad will be down/in read-only from 22:00 UTC until 01:00 UTC for a code update | Lucid Alpha 1 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithB
<Keybuk> for new ones, go ahead and upload
<Keybuk> and I'll do post-review
<Keybuk> it was more changing existing ones that was going badly wrong :p
<Keybuk> because I suck at coding
<slangasek> kirkland: "modprobe aoe" - nothing else does this for us?
<Keybuk> aoe is one of those silly devices
<Keybuk> you load the module when you want them
<Keybuk> like ppp and tun
 * slangasek nods
<slangasek> #
<slangasek>         echo -n 1 > /proc/sys/net/ipv4/ip_forward
<slangasek> not /etc/sysctl.d?
<kirkland> Keybuk: yeah, these are for eucalyptus, so shouldn't affect your boot speed stuff
#ubuntu-devel 2009-12-17
<kirkland> slangasek: i just plucked this crap out of the init script
<slangasek> (we don't reverse that when stopping the job, so not sure why it should be here)
<Keybuk> kirkland: it wasn't boot speed per se. more than it's easy to trip over upstart bugs
<slangasek> kirkland: well the init script wasn't very good ;)
<slangasek> gratuitous use of cat; 4 sed commands where 1 would do; and why are we preallocating /dev/loop nodes here?
<kirkland> slangasek: will fix the sed
<kirkland> slangasek: will ditch cat
<slangasek> ah, but those are the minor things, it's the mknods that have me scratching my head :)
<kirkland> slangasek: the loop devices are necessary for mounting storage for the instances
<kirkland> slangasek: let me find the bug number with the background
<slangasek> and "32" just happens to be the right number of loop devices to preallocate? :)
<kirkland> bug #430846
<ubottu> Error: Could not parse data returned by Launchpad: HTTP Error 500: Internal Server Error (https://launchpad.net/bugs/430846)
 * kirkland screams at launchpad
<kirkland> slangasek: http://74.125.47.132/search?q=cache:rSm0ihZxdXQJ:https://launchpad.net/bugs/430846+430846&cd=4&hl=en&ct=clnk&gl=us
<kirkland> google cache FTW
<slangasek> heh
<wgrant> kirkland: edge is working in read only mode, FWIW.
<kirkland> wgrant: thanks
<kirkland> slangasek: so there you go .... I asked the kernel team if we could increase the ubuntu default
<kirkland> slangasek: they told me go make them myself
<kirkland> slangasek: seems easy enough to do safely at boot
<slangasek> kirkland: right - I guess I'm just a little wary of the preallocation of a fixed, magic number of loopback devices
<slangasek> not a bug now, might be a bug later
<slangasek> :)
<kirkland> slangasek: and apparently this is something only eucalyptus needs, as the kernel team didn't want to increase it arbitrarily for everyone
<Keybuk> we need to fix loop
<Keybuk> so that it allocates on demand
<Keybuk> every one created at boot costs boot time
<Keybuk> it should be more like /dev/pts
<kirkland> jebus
<Keybuk> that's upstreamy though
<kirkland> Keybuk: i do not disagree :-)
<kirkland> slangasek: what does this mean:
<kirkland> <slangasek>         echo -n 1 > /proc/sys/net/ipv4/ip_forward
<kirkland> <slangasek> not /etc/sysctl.d?
 * Keybuk wonders why there's no /sys/module/loop/parameters/max_loop
<slangasek> kirkland: we already have /etc/init/procps.conf, which will do sysctl tweaks for anything defined in /etc/sysctl.conf and /etc/sysctl.d; should eucalyptus-nc not just drop a conffile there?
<Keybuk> slangasek: I think that kirkland hasn't realised that's a sysctl ;)
<slangasek> I'm not saying one or the other is right, I'm just pointing out what I thought was the standard mechanism
<Keybuk> kirkland: your echo is equivalent to putting "net.ipv4.ip_forward = 1" in /etc/sysctl.d
<kirkland> Keybuk: cool, thanks, i can do that
<Keybuk> yeah that's probably right
<Keybuk> since then all the documentation applies
<kirkland> slangasek: Keybuk: right well, as i said, this was a straight port of a crappy init script to a crappy upstart script;  we're just now trying to clean it up
<kirkland> Keybuk: slangasek: what about /proc/sys/net/bridge/bridge-nf-call-iptables ?
<kirkland> Keybuk: slangasek: is that sysctl-able too?
<slangasek> yes
<slangasek> anything under /proc/sys
<kirkland> slangasek: okay, where do i find the docs to look up the var name?
<slangasek> kirkland: it's straight s,/,./g on the filename
<slangasek> er
<slangasek> s,/,.,g
<kirkland> net.bridge.bridge-nf-call-iptables = 1
<kirkland> slangasek: ?
<Keybuk> yup
 * slangasek nods
<kirkland> 30-eucalyptus-nc.conf
<kirkland> that look about right?
<slangasek> sure
<kirkland> slangasek: is there a better way to get aoe modprobed?
<slangasek> apparently not :)
<kirkland> slangasek: the loops will need to stay for now, until there's a better way to do this
<slangasek> yep
<kirkland> kirkland@x200:/local/source/eucalyptus/lucid.public/ubuntu$ pastebinit debian/eucalyptus-nc.upstart
<kirkland> http://paste.ubuntu.com/343123/
<kirkland> kirkland@x200:/local/source/eucalyptus/lucid.public/ubuntu$ pastebinit debian/30-eucalyptus-nc.conf
<kirkland> http://paste.ubuntu.com/343124/
<slangasek> kirkland: looks sane to me
<kirkland> slangasek: cheers, thanks
<kirkland> Keybuk: i'll send you an email with a pointer to the bzr branch with all of the eucalyptus upstart scripts, for your leisurely review ;-)
<Keybuk> sure
* spm changed the topic of #ubuntu-devel to: Lucid Alpha 1 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithB
* spm changed the topic of #ubuntu-devel to: Lucid Alpha 1 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pitti> Good morning
<StevenK> Morning pitti
<Hobbsee> heya pitti!
<pitti> Whoopie: just 481448> uload then
 * slangasek waves to pitti
<pitti> slangasek: daemon.log> hm, it seems full of debugging spew; but yes, we can certainly also downgrade the debugging level of apps
<slangasek> debugging spew - really?
<slangasek> ah, wpa_supplicant
<slangasek> oh, wait
<slangasek> pitti: daemon.log, or auth.log?  daemon.log doesn't appear to be synchronous by default
<slangasek> auth.log is, and is the one I'm concerned about :)
<pitti> slangasek: oh, and I was really talking about daemon.log
<pitti> powertop regularly complains about stuff writing there
<slangasek> powertop doesn't seem to distinguish between synchronous and asynchronous writes
<pitti> ah, then I misunderstood your comment, sorry
<slangasek> you probably didn't misunderstand, I was probably just confused :)
<pitti> hey StevenK, morning Hobbsee!
<slangasek> since AFAIK the only log we write synchronously by default is one that we /should/, I assumed that was the one your comment in the whiteboard was referring to
<slangasek> without noticing that auth != daemon :)
<slangasek> pitti: btw, if you're going near SRUs today, hold off for a few hours on the cryptsetup one; I've confirmed the report that 475936 isn't fully fixed in lucid, and am going to track that down today
<pitti> slangasek: cryptsetup> ack
 * dtchen wonders if there's a faster way to test-build for armel
<dtchen> (I'm kinda surprised that upstream PA hasn't encountered these issues)
<pitti> with the new LP rollout, do we have 3.0 source format now?
<pitti> at least sync-source.py still fails
<pitti> but that could be due to cocoplum having a too old dpkg
<pitti> wgrant: ^ do you know?
<ttx> slangasek: looks like we'll need to keep cglib2.1 for the moment.
<pitti> james_w: thanks for your "distributed dev" summary!
<pitti> james_w: how often are these branches imported? I just tried lp:debian/cdbs, and it's behind by more than 4 months (there were > 5 uploads afterwards)
<pitti> james_w: another question, what would happen if I did "bzr push lp:ubuntu/pm-utils-powersave-policy --force-overwrite" so that I can get my native bzr over the auto-import? from what I remember, people can commit individual changes to an auto-import, and they won't get overwritten as long as they are consistent with the .dsc?
<dholbach> good morning
<persia> pitti: Do you know where I might find powerpc ddebs for lucid?
<pitti> persia: funny you should ask; we have collected them for years and hardly used them, and I removed them last week because macaroni went out of space
<persia> Heh.  And it was last weekend that I went looking :)
<pitti> persia: if you need them for a recent build, they can still be retrieved from the buildds, though
<pitti> persia: are you looking for a particular package?
<persia> Is that something I can do on a per-build basis?  I rarely need them (my powerpc box mostly just works), but when I do, it's only one or two at a time.
<pitti> the build log should tell you on which buildd it was done
<pitti> persia: sure, just install pkg-create-dbgsym locally
<persia> binutils 2.20-4ubuntu3
<pitti> then it just happens
<persia> I do that, but that's only for packages I build :)
<pitti> persia: sorry, that was built a month ago already; they are gone, I'm afraid
<wgrant> pitti: It's waiting on an upgraded dpkg on the various Soyuz machines. Once that's done, a LOSA needs to run some SQL magic to enable 3.0 uploads to Lucid.
<persia> Ah, so they don't get stored in +archive :(
<pitti> persia: not yet; however, wgrant was working on that
<pitti> so, I hope it'll happen "soon"
<persia> That would meet my use case.
<wgrant> pitti: RT #36873, if you want to watch it.
<persia> On a separate note, if you've removed all the binaries, please also remove the (now invalid) Packages and Release files.
<wgrant> Most of the ddebs-in-soyuz work is done. I'm nearly there. But then there's the issue of librarian bloat.
<persia> (it's confusing to have things work and then get 404s for difficult to understand reasons)
<pitti> persia: well, there's still tons of powerpc ddebs
<persia> Oh, so I just picked an unlucky package?  Oh well.
<pitti> I just stopped collecting them
<pitti> but yeah, I'll remove them for lucid
<persia> wgrant: How much bloat are we talking about?  Is it something that could be contained by only tracking a subset of packages or something?
 * persia is just unsure how to proceed with a segfault in ld
<mneptok> pitti: "Macaroni Went Out Of Space" sounds like a Hunter S. Thompson book title, or an album by a 1960s psychedelic band.
<pitti> you are so right
<pitti> sometimes I don't even read what I wrote any more :)
<wgrant> persia: pitti can you probably tell us approximately how much bloat we're talking about.
<wgrant> But it's not an insignificant volume :(
<pitti> right, they are huuuuuuuuuuuuge
<pitti> I'd estimate some 300 GB on macaroni right now
<persia> Ah, that is large.
<pitti> expect some (elf portion of packages)%5
<pitti> erm, *5
<wgrant> Plus I suspect that you have a more aggressive binary removal policy than LP.
<persia> I don't know about other people, but I tend to find that most classes of crashes can be replicated on an arbitrary architecture (excepting endian issues, word length issues, and silly assumptions about alignment).
<pitti> yeah, I only keep the latest
<pitti> it explodes otherwise
<pitti> so please let's not keep all of them for ia64 :)
<persia> So I wonder if it might be possible to get away with just the packages that are used as build dependencies for other packages (mostly libraries and toolchain)
<wgrant> So it needs an Awful Lot of disk space on both cocoplum and mizuho.
<persia> And I presume that me running to the shop and shipping disks isn't the solution, because there are chassis limitations, etc.
<pitti> we could only keep supported arches, and only for current lts, current stable, and development release
<pitti> plus ports for dev release perhaps
<persia> That's a set that matches all my use cases :)
<wgrant> Actually, thinking about it, we could safely enough purge ddebs early.
<slangasek> ttx: wah; ok
<ttx> slangasek: proxool needs asm2, cglib (2.2) needs asm3, cglib2.1 needs asm2
<ttx> slangasek: and asm2 and asm3 don't live well together in the same classpath
<ttx> so I'd say that debian adding "Provides: libcglib2.1-java" to libcglib-java is somewhat optimistic
<slangasek> pitti: cdbs import failure info: http://package-import.ubuntu.com/failures/.bzr/failures/cdbs
<ttx> (and eucalyptus needs proxool and cglib)
<pitti> slangasek: ah, thanks
<pitti> slangasek: btw, do you have sata disks? my laptop doesn't even have sata power link management
<pitti> slangasek: I'm changing the heuristics to be a little more clever, not just looking at total RAM, but at active RAM, too
<pitti> I'm just curious how it feels like when enabling it
<slangasek> pitti: yes, I have sata, with the intel chipset needed to use this
<slangasek> I have 3GB RAM today, which is enough that SLPM doesn't hurt me
<slangasek> (SLPM? SPLM?)
<slangasek> when I had 1GB of RAM, it was bad :)
<pitti> I now use "min_power" if inactive/total > 15%, and medium_power if inactive/total > 5%
<pitti> and if it's even less, I don't touch it
<pitti> since it seems dangerously close to swapping
<pitti> I'm not entirely sure if this is a better heuristics, I'll send out a call for testing
<slangasek> I think it would be fine to just check the amount of RAM; after all, mem usage will change over time, much more rapidly than the pm-utils hook will be triggered
<pitti> so perhaps just bump it to 2 GB?
<pitti> GiB
 * pitti tries to teach himself to use correct units, in light of the month-long units policy TB topic
 * slangasek grins
<slangasek> fine with me; maybe it should be varied by architecture, also?
<slangasek> 1GB might be enough on 32-bit, isn't enough on 64-bit
<pitti> does it make such a difference actually?
<pitti> I had expected most things to just use ints
<pitti> pointers do, of course
<slangasek> everything python approximately doubles in size
<pitti> how much RAM do netbooks have these days? They are prone to have i386
<persia> They vary from 512MB to 3GB
<persia> (at least that's what I saw last time I looked in a shop about 3 weeks ago)
<pitti> so, let's say 1 GiB on i386, and 2 on AMD64?
<slangasek> sounds reasonable to me
<pitti> james_w: btw, do you ignore language-pack-* for auto-imports? it'd be a waste, and people really shouldn't change the packages directly anyway
<slangasek> tseliot: hmm, did you change anything that should have fixed the input-dropping bug in plymouth?  I don't see any recent upgrades on anything except initramfs-tools, but my passphrase entering is now reliable
<tseliot> slangasek: no, but that happened to me too once and I don't know what made it more reliable
<slangasek> tseliot: should I close my bug, or leave it open?
<tseliot> slangasek: please leave it open, I think it's something we should investigate
<slangasek> ok
<slangasek> pitti: cryptsetup checks out, the problem I'm seeing is mountall+fstab interaction and not a bug in the cryptsetup fix itself
<pitti> nice, so good to go to -proposed then?
<slangasek> pitti: IMHO yes; I'll update the test case based on my latest findings
<slangasek> pitti: test case updated
<pitti> ogra_: did you ever happen to test lucid alpha-1 on your touchscreen? was there a major regression due to the udevification?
<pitti> (of x.org)
<ogra_> pitti, i'm currently not running lucid on my laptop, will tell you once i do
<pitti> ogra_: thanks
<james_w> pitti: they are imported continuously, but there was a bug meaning Debian was missed, so some of them are out of date. An LP bug is hampering my effort to get all of Debian up to date.
<james_w> pitti: you could push --overwrite pm-utils-powersave-policy. I would have some fallout to deal with, but that's not a problem.
<james_w> and I do not currently ignore language-pack-*
<pitti> james_w: so is the --overwrite considered a hack or a semiofficial method to move the real-world bzr branches to their preferred naming scheme?
<james_w> both :-)
<pitti> james_w: if it's sanctioned, I'd like to do it for apport, jockey, pm-utils-powersave-policy (since those have full source)
<james_w> it works fine
 * slangasek grins
<james_w> I can do it by changing the links, which is perhaps a little more elegant
<pitti> I keep getting bad merge requests for apport, and just pushing the real branch to lp:ubuntu/apport would help a lot
<james_w> there's a bug I need to fix before I do that though
<slangasek> if the package also exists in debian, though, that will lose us some of the history I guess?
<pitti> for those three that's not the case
<james_w> yeah
<pitti> I guess for the merge case it might be better to just throw away our old branch, merge with Debian, and push the merge to the auto-import branch?
<james_w> I have to make it re-import taking in to account what is already there, after adding some tags
<james_w> I would prefer to do it all properly, but I understand that it must be frustrating waiting for me
<pitti> james_w: if it's causing you extra work, I'll leave it as it is for nwo
<EsatYuce> i m member one of the Launchpad team which name is https://launchpad.net/~ubuntu-l10n-tr, i want to release translated's package. How?
<james_w> by doing a push --overwrite you force the issue
<pitti> james_w: I was just wondering because you said that we can actually commit individual changes to those branches, upload, and the importer would see that it's already there and not clobber it
<james_w> pitti: you theorised correctly
<james_w> there are just a couple of implications for the backend
<james_w> the code hasn't quite caught up with reality yet
<EsatYuce> is this right channel to ask about Launchpad??
<slangasek> EsatYuce: #launchpad is probably a better channel for questions about Launchpad
<dpm> EsatYuce, I'd recommend you to ask at #ubuntu-translators, but in general, you might have to get in touch with the developers of the package you have translated
<pitti> tjaalton, tseliot, bryce: FYI, I documented the udev X.org bits on https://wiki.ubuntu.com/X/InputConfiguration
<mdz> anyone else see this in current lucid?
<mdz> rm: cannot remove `/tmp/mkinitramfs_cLvNRp/lib/modules/2.6.32-8-generic/modules.*map': No such file or directory
<tseliot> pitti: it looks good, thanks for working on this
<pitti> tjaalton, tseliot, bryce: (I also linked it from /X)
<tseliot> pitti: ah, for quick access from X, nice. Thanks again
<persia> pitti: You report that joysticks have ID_INPUT_KEY : is this for joysticks that actually include a keyboard map, or ones that just provide buttons as well?
<tjaalton> pitti: thanks. it's possible that device configuration will not be allowed from the backend, but moved back to the ddx
<tjaalton> pitti: even for lucid
<tjaalton> patches upstream
<pitti> persia: hm, let me check
<pitti> persia: right, current input_id indeed does't assign _KEYS, fixing
<pitti> tjaalton: would that mean that it stops using udev altogether then?
<persia> pitti: Well, that was an accident on my part :)  is there another resource I should look at that for deeper grounding (or would that be source)?
<jelmer> subunit
<tjaalton> pitti: no, it just wouldn't be possible to pass x11_options from it. the xorg.conf format will become far more flexible to handle this
<pitti> persia: well, I wrote input_id, so if you have a good reason why ID_INPUT_JOYSTICK (and the like) should also have _KEYS=1, I'm happy to add it
<tjaalton> pitti: and also support for xorg.conf.d
<slangasek> mdz: yes, Keybuk said he was going to fix that today
<pitti> tjaalton: ah, I see; well, the doc can always be updated then
<tjaalton> pitti: which packages can use to ship conf snippets
<mdz> slangasek, ok, thanks (and what on earth are you doing awake?)
<tjaalton> pitti: of course
<slangasek> mdz: I work odd hours on Thursday in order to stay in touch with Europe :)
<mdz> ah
<persia> pitti: For the general case, they shouldn't.  Oddities like the Saitek Cyborg Command Unit probably should.
<persia> (where the joystick is just asking to be remapped to send keyboard events)
<pitti> persia: if the device event mask claims that it can produce EV_KEY, input_id will report that
<persia> Ah, that makes sense.  OK.
 * persia will go read the input_id source this weekend to actually understand
<pitti> it by and large just tests the bitmasks in /sys/class/input/*/capabilities/{ev,abs,rel,key}
<pitti> using the flags in /usr/include/linux/input.h
<tjaalton> pitti: there are bugs where evdev grabs joysticks, and that makes the cursor jump to the middle of the screen when the joystick is touched
<pitti> but this bit mask testing is horrible/impossible in pure udev rules, which is why we need the callout
<pitti> tjaalton: right, I have that when I attach my joystick
<persia> tjaalton: actually, that depends on the joystick: not all of them are either absolute or autocentering.
<tjaalton> pitti: it also happens for hw accelerometers, so tap your laptop.. :)
<tjaalton> persia: ah, ok
<pitti> tjaalton: I was never quite sure whether plugging in a joystick is supposed to behave like a mouse, or whether that was an unintended side effect
<tjaalton> pitti: I'd say not. there's a -joystick driver for that
<pitti> we can of course easily ignore joysticks as X input devices
<persia> There are definitely two schools of thought by users.
<tjaalton> yes, but the last time this happened with hal, there were a bunch of users upset :)
<tseliot> james_w: can you join #ubuntu-x, please?
<pitti> tjaalton: ... which we don't install by default?
<persia> I think there should be an (optional) way to enable/disable that easily.  Used to be xf86-input-joystick
<tjaalton> pitti: right
<pitti> tjaalton: so xserver-xorg-input-joystick should ship an udev rule which sets ENV{ID_INPUT_JOYSTICK}==1, ENV{x11_driver}="joystick"
<tjaalton> pitti: that's already in git, just not released yet
<pitti> ah, sweet
<persia> A related question: with HAL it was possible to remap stuff, so for instance one could enable a fake mouse somewhere on one of the monster 15-axis 40-button joysticks and still use the joystick in games.
<persia> Is there a way to do that without HAL?  Should descriptor files be shipped somewhere?
<persia> (e.g. in the x52pro package)
<persia> Or does that now require custom input drivers?
<tjaalton> hal was just the backend
<pitti> persia: hal itself didn't really add new devices (and wasn't able to)
<tjaalton> if it was possible with x11_options, it'll still be possible
<pitti> persia: you should be able to set configuration in udev just as well as in hal
<persia> OK, so that's just constructing the right ENV(x11_options.foo) entries?
<persia> e.g. ENV(x11_options.event_key_remap)="464=118" and the like?
<pitti> persia: if that worked in hal, it'll work with udev rules
<pitti> it's just the messenger
<pitti> persia: above wiki page has a migration guide
<persia> Cool.  Thanks.
 * persia was reading that, but hadn't looked at input stuff much since intrepid or so, and was catching up slowly
<LucidFox> seb128, regarding xchat-gnome - my patch for the git version is in the upstream bug report.
<seb128> LucidFox, the current patch still change .glade files there
<seb128> LucidFox, they named the files .glade rather than .ui?
<seb128> seems buggy...
<LucidFox> Yes - the git version uses these .glade files.
<seb128> ok, I will check that later
<seb128> that seems wrong
<seb128> gtkbuilder files are named .ui usually
<LucidFox> Actually... the git version seems to still use libglade. o_O
<seb128> weird, http://git.gnome.org/cgit/xchat-gnome/commit/?id=8ba28cb15d6bb365891a495130aed49145a7a2b5
<LucidFox> Only the preferences dialog is converted to GtkBuilder.
<seb128> I think they rather didn't rename their .glade to .ui
<LucidFox> The rest still use libglade
<seb128> oh ok
<LucidFox> yet even for the preferences dialog. they didn't rename .glade to .ui.
<lool> persia: Latest binary package built wins
<lool> Last one to build that is
<persia> Nope.
<persia> Highest version wins.
<persia> (for those seeking context, see #launchpad)
<qense> In the upstream conversation about bug 487937 it became clear that Nautilus already has PackageKit integration for unknown file formats, Fedora 11 advertised it in its release notes. Now I'm not sure how Nautilus' PackageKit support in Ubuntu is. It's disabled, isn't it?
<ubottu> Launchpad bug 487937 in hundredpapercuts "open up of compressed filetypes should request to install proper extractor" [Undecided,Confirmed] https://launchpad.net/bugs/487937
<seb128> qense, we don't use packagekit but have a nautilus patch using gnome-app-install for installing things too...
<seb128> qense, the issue is not a nautilus one though
<qense> it is a share-mime-info issue?
<seb128> it's likely that file-roller claims handling those in its desktop entry
<seb128> well I would guess that file-roller is used
<seb128> but it fails
<qense> the error message just says no suitable application can be found
<seb128> there is a bug on file-roller asking for smart install already though
<qense> really? I couldn't find any
<seb128> qense, bug #148084
<ubottu> Launchpad bug 148084 in file-roller "totem-like/firefox-like plugin installer for file-roller" [Wishlist,Triaged] https://launchpad.net/bugs/148084
<qense> ah, I see
<qense> but that's for inside file-roller
<seb128> qense, but if file-roller is not open it might be because the mimetype is not listed
<seb128> what mimetype are those which give you the error using?
<qense> I can confirm it with CAB, which is in packages/freedesktop.xml -- a file of shared-mime-info, the only .xml one -- the reporter talked about lzma and 7zip.
<seb128> qense, cab = application/vnd.ms-cab-compressed?
<seb128> qense, no .desktop lists those in their .desktop in /usr/share/applications
<seb128> nautilus can't guess from nowhere what application could be able to open those
<seb128> the .desktop need to list the mimetype for that to work
<qense> ah
<seb128> lzma and 7z should work
<qense> ah
<qense> a lot of ahs here ;)
<seb128> since those are listed in the file-roller .desktop list
<qense> I see CAB isn'tin .desktop indeed
<seb128> I'm not sure file-roller handle those
<seb128> I'm not sure we have any gui to handle those
<seb128> it's a somewhat specific format
<qense> yes
<qense> must have been my memory playing a trick on me, confusing a terminal command with a GUI action
 * persia comments that it's possible for plugin packages to add special mime-handler-only .desktop files that end up calling into the executable into which they plug if that helps with non-default formats
<seb128> it's listing application/x-cabinet though
<qense> that's strange
<seb128> could be a .desktop bug
<qense> or an inconsistency from MS
<seb128> in any case it's not a nautilus issue
<qense> indeed
<seb128> it just matches mimetype and .desktop lists
<qense> I'll check if application/vnd.ms-cab-compressed can be processed the same as application/x-cabinet and mark the LP bug as a dup of the bug you named. The upstream report could be turned into a bug about the .cab archive handling.
<qense> Thanks for your help, seb128! (and for your suggestion, persia)
<Mez> Hmm, it seems my automount stuff has stopped working in karmic.
<Mez> Is this a known issue?
<seb128> Mez, no
<seb128> qense, you're welcome
<Mez> seb128: any idea of how to "debug"
<seb128> use ubuntu-bug storage
<seb128> it will get gvfs, devicekit-disks etc logs
<Mez> "Package storage does not exist"
<seb128> install apport-symptoms
 * Mez waits for upgrade to finish
<Mez> hmm... new apport version ?
<Mez> seb128: #369067
<seb128> bug #369067
<ubottu> Launchpad bug 369067 in pidgin "pidgin crashed with SIGSEGV" [Medium,Invalid] https://launchpad.net/bugs/369067
<seb128> Mez, doesn't seem right
<Mez> bug #36906749
<ubottu> Error: Launchpad bug 36906749 could not be found
<Mez> ah, crud
<Mez> bug #497771
<ubottu> Launchpad bug 497771 in devicekit-disks "Discs not automounting in Karmic." [Undecided,New] https://launchpad.net/bugs/497771
<Mez> hmm, looks - sane enough to me.
<seb128> I think it's a dup
<seb128> the device has no type
<Mez> seb128: a reboot seems to have fixed this.
<seb128> weird
<seb128> is that karmic uptodate?
<Mez> maybe some process got killed off at a point i hit high memory or something
<seb128> there was a fd leak in udev earlier in the cycle
<Mez> yeah, up to date.
<seb128> but that got fixed in a stable update
<Mez> oh, when?
<seb128> that's fixed for a least one month
<Mez> oh, it's been updated at the end of last week at least
<seb128> some similar bugs are due to devicekit processes crashing too
<seb128> so it might be one of those
<seb128> could you comment on the bug saying that a reboot fixed it?
<Mez> already in the process of doing so
<seb128> thank you
<Mez> worth marking as invalid too?
<seb128> you can yes or you can wait for pitti to triage it
<seb128> I expect he will need some extra log though
<seb128> so if you can't get the issue now...
<Mez> well, it's working now, so I won't really be able to reproduce
<seb128> close it and reopen if you get it again
 * Mez has no access to
<seb128> and maybe check your system logs for asserts or crashes
<Mez> wait, wtf
<Mez> I'm part of bug control
<seb128> you should be able to close your own bug in any case
<Mez> yeah, missed the "double login" stuff :)
<Mez> damn edge :D
<Mez> afternoon sabdfl
<sivang> sabdfl is here ? :)
<Mez> his IRC nick is :)
<sabdfl> hello all
<ion> Howdy
<hwilde> anybody know what is holding up libjsw for 9.10?
<persia> hwilde: How do you mean "holding up".
<slangasek> it's turtles all the way down
<hwilde> persia, everything else seems to work but no joystick support so what are we waiting for
<persia> hwilde: Ah.  Well, since about 7.10 joystick support was *less good* with libjsw installed.
<hwilde> but we need jscalibrator
<persia> Um no.
<persia> That just broke stuff.
<ebroder> Hey persia - could you add me to u-u-s?
<hwilde> persia, jscalibrator is the only way the logitech rumble pad works
<hwilde> (the playstation looking controller)
<persia> hwilde: Anyway, join me in #ubuntu, and I'll talk to you about joysticks :)
<ion> Itâs teenage mutant ninja turtles all the way down.
<pitti> seb128, Mez: I'll have a look
<jelmer_> beuno, ping
<kirkland> pitti: hmm, looks like something just regressed in the burndown-chart scripts
<kirkland> pitti: i had some items marked as DONE, that were picked as DONE by your scripts, but now, they're back in the TODO range
<pitti> hmm
<pitti> kirkland: do you have bugs linked to blueprints?
<pitti> kirkland: today we landed a feature to use bugs as work items
<pitti> which are now counted as todo (open) or done (fix released)
<kirkland> pitti: ah, yeah, i have a few in "fix committed"
<kirkland> pitti: okay, thanks, that's it
<pitti> kirkland: would that be a plausible cause?
<kirkland> pitti: i think so
<pitti> kirkland: so you should probably just remove the WIs from the whiteboard which duplicate the bugs
<kirkland> pitti: cool, i like the feature
<kirkland> pitti: i'd like each work item to be a bug, actually ;-)
<pitti> kirkland: https://wiki.ubuntu.com/WorkItemsHowto#Work%20items%20as%20linked%20bugs
<pitti> kirkland: well, for some it's great (e. g. "MIR for foo"), for some not so ("test X", "write documentation")
<kirkland> pitti: meh :-)
<pitti> kirkland: but the whiteboard stuff won't go away, so it's just another option now
<kirkland> pitti: i like that bugs have priorities, state, owners, history, etc.
<kirkland> pitti: cool, thanks
<kees> pitti: so, if we have a workitem that reads  "support backingstore (LP: #470636)"  this is now counted twice?
<pitti> kees: if you linked that bug to the BP, yes
<pitti> this seems to confuse enough people that this warrants an announcement
 * pitti mails platform
<kees> how are bugs linked to bps?  :P
<kees> becuase our todo chart jumped a lot more than just 1 item.
<smoser> Keybuk, do you a minute for a mountall question?
<Keybuk> smoser: sure
<smoser> on ec2, the root= is going to say 'root=/dev/sda1'
<kees> pitti: or at least those bugs should be explicitly listed in the "Status by work item" section
<Keybuk> ok
<smoser> i'd like to label the filesystem and use "LABEL=" in /etc/fstab
<pitti> mailed
<Keybuk> smoser: do you have an initramfs?
<joaopinto> dtchen, without apparent reasons my sound got muted, I stated getting flood with the volume muted notificatoin and PA was using 100% of one of the cores, is there a PA specific log I can check ?
<pitti> kees: they should, in the database it's all the same
<Keybuk> (I would assume not, it doesn't make much sense)
<smoser> i do not
<Keybuk> right, then you're basically limited ;)
<smoser> well, wait
<Keybuk> you can put whatever you like in fstab
<Keybuk> but it doesn't make any difference - since the kernel is what mounts the root <g>
<kees> pitti: how are they distinguished between "from a white board" and "from a bug" ?
<smoser> i do when running in UEC, but not when running in ec2
<pitti> kees: how do you mean? the DB doesn't care whether it comes from whiteboard, bug, or a wiki page
<smoser> Keybuk, thats fine. i'm good with that.
<Keybuk> smoser: only the options part of the fstab entry for the root are actually used
<Keybuk> ie. what mount options to use, whether to fsck, etc.
<smoser> but will mountall figure out that my LABEL=myroot is the same as sda1 that was on the command line ?
<Keybuk> smoser: mountall just ignores the LABEL=myroot
<kees> pitti: I'm trying to understand which items are "bugs", since we never planned to track work items with bug reports.  Our todo list jumped, and I want to eliminate all the non-whiteboard work items.
<Keybuk> smoser: information present in mountinfo when mountall starts overrides all fstab files
<pitti> kees: just unlink them from the blueprint then
<kees> pitti: right now, everything is listed by bp name, so I can't tell which are bugs and which are bp whiteboard workitems.
<Keybuk> if in fstab you have /dev/sda2 / defaults 0 0
<Keybuk> but you boot with root=/dev/sda1
<pitti> kees: oh, I see
<kees> pitti: I don't know which are the bugs to do the unlinking.  :P
<pitti> slangasek: hm, how did you solve this?
<beuno> jelmer, pong
<Keybuk> mountall will see "/dev/sda1" as the device name for /
<smoser> Keybuk, ok. i think thats actually what i want.
<pitti> slangasek: i. e. do you have an use case for linking a bug which isn't a WI?
<Keybuk> (but remount -o rw,defaults and not check because that's what fstab says)
<pitti> slangasek, kees: I guess it might help if the WI description includes the bug #
<smoser> i want to trust cmdline
<kees> pitti: yes, that would help.  a prefix maybe.    LP: #nnnnn: [workitem text]
<Keybuk> smoser: you'll hit a bug with 2.6.32 of course
<Keybuk> mountall will fail because it can't mount /dev/pts or /dev/shm
<Keybuk> due to the underlying same problem <g>
<Keybuk> 2.6.32 will *also* mount a devtmpfs filesystem on /dev
<smoser> the kernel does that?
<Keybuk> (tangent: kernel really should mount /proc and /sys automatically too - I think there even patches for it)
<Keybuk> yes
<Keybuk> if you don't use an initramfs, the kernel gives you devtmpfs on /dev now
<Keybuk> which is good
<smoser> wow. i didn't realize that.
<Keybuk> but mountall has a bug where it doesn't mkdir the mountpoint in that situation
<smoser> so, next question
<Keybuk> so it'll fail to mount /dev/pts and /dev/shm because the empty directories don't exist in the devtmpfs
<smoser> if i want to modify /etc/fstab during boot (add entries)
<jelmer> beuno: hi
<smoser> will mountall "just notice" ? does it watch /etc/fstab  ?
<jelmer> beuno: I was talking to somebody about gtk imports yesterday. Do you remember who that was?
<Keybuk> (mountall behaves the same way as root here; kernel put devtmpfs on /dev, so it obeys the kernel - overriding its internal fstab)
<jelmer> beuno: FWIW I've fixed the import.
<Keybuk> smoser: it will not notice
<smoser> ok. thats fine.
<Keybuk> that would be insane
<smoser> yeah
<smoser> thats fine
<Keybuk> if you deleted a line of a mount point that mountall had already mounted, what should it do? :p
<smoser> so i just add an entry and then issue a mount command for it.
<Keybuk> right
<Keybuk> you can do that
<smoser> i agree, insane.
<smoser> sweet
<Keybuk> (and mountall will actually issue a mounted event for that too <g>)
<smoser> thank you Keybuk
<beuno> jelmer, yes, it was jjardon
<Keybuk> because it *does* watch mountinfo
<smoser> oh, that last tidbit is nice.
<Keybuk> so it'll see your mount command adding to mountinfo
<ion> keybuk: Random thoughts: hypothetically, there could be a number of simultaneous input/progress items, a number of simultaneous UIs and a tiny daemon that contains the logic to delegate everything between all of them. Plymouth with a plain virtual console fallback could be the initial UI, then gdm could take over (displaying any active items under the login area) and even the desktop session could have indicators/notifications for them.
<Keybuk> ion: we settled on using Plymouth to do the delegation
<Keybuk> (since it already does)
<pitti> kees: I need to leave in 5 (sorry), so please feel free to commit; should be a simple patch
<kees> pitti: ok, I'll test it
<ion> keybuk: How about gdm/desktop interaction? For instance, Upstart warn about jobs that failed to start, there would be a way to readd deferred fscks with the user being able to see the progress at all times etc.
<Keybuk> ion: why should Upstart bother a user with such things?
<Keybuk> if the system can't recover from a failed service start by itself, my 8yo niece is also unlikely to be able to
<Keybuk> deferred fsck -> we're not going to do this
<Keybuk> gdm won't start all the time filesystems are being checked
<Keybuk> any filesystem with passno>0 will hold up gdm
<ion> Your niece would be immediately able to say âit says cups failed to startâ and read the error message it printed just before dying straight from the screen instead of saying âprinting doesnât workâ and taking 45 minutes of phone call time just to figure out the information. ;-)
<Keybuk> disagree
<Keybuk> if there's a problem with printing, the message should go in the print dialog
<Keybuk> a popup that went past while she was concentrating onto facebook to harvest her crops is not going to stick in her mind
<ion> True
<Keybuk> you could even do some fun adaptaive UI
<Keybuk> like if the print server is down, the print icon on the toolbar has a line through it
<Keybuk> clicking it explains what went wrong, and gives you a button to try and restart it, etc.
<Keybuk> then you could do things like check for an update, etc.
<ion> Speaking of plymouth, is it planned to implement graphics support for vga16fb, or is there just going to be a text fallback for the input/progress items?
<ion> In my VirtualBox VM with ~ubuntu-boot packages, any fscks seem to be cancelled almost immediately, probably since plymouth is unable to show anything.
<Keybuk> ion: that is the plan
<Keybuk> it should be mostly just porting code from bogl to deal with the colourspace
<Keybuk> . o O { if you get bored ... :p }
<ion> keybuk: Yeah, i was considering taking a look at it some day.
<Keybuk> ion: obviously the plymouth framebuffer renderer is the appropriate one
<Keybuk> (you may have to move drm.so out of the way, as there might be a bug with the fallback in our package :p)
<fta> stgraber, do you have a fix for pastebinit to support openid?
<mathiaz> Keybuk: hi - I was trying to modify the hostname.conf upstart job with this: http://paste.ubuntu.com/343531/
<mathiaz> Keybuk: the goal is that I want to run the hostname.conf job when /etc/vm_config/ has been mounted
<mathiaz> Keybuk: it's a local block device
<Keybuk> you're not uploading that to the real distribution, right? :p
<mathiaz> Keybuk: no :D
<Keybuk> that won't work today
<Keybuk> but it will work some point before alpha 2
<mathiaz> Keybuk: ah ok.
<Keybuk> you want "start on mounted" ;)
<mathiaz> Keybuk: that would work today?
<Keybuk> no
<Keybuk> neither works today
<Keybuk> mount happened *before* the given mountpoint is mounted, and blocks it from mounting
<Keybuk> which is definitely not what you want :p
<Keybuk> in mountall 2.0, mount is replaced by mounting - and a new mounted gets added which is what you want
<mathiaz> Keybuk: great!
<mathiaz> Keybuk: thanks
<blackxored> hello, since lucid is lts and syncing from testing, I should wait my package to migrate to testing to get it into ubuntu, right?
<persia> blackxored: Unless you're *really* confident and need it as a dependency for something else.
<blackxored> persia, as a matter of fact, both apply for me :P
<mathiaz> Keybuk: would "start on (mount MOUNTPOINT=/ and net-device-up IFACE=eth0)" work today?
<mathiaz> smoser: ^^ - I was looking into some ec2-config and run into the issue above
<blackxored> I suppose I'll wait
<blackxored> persia, ^^^^
<ion> keybuk: Now that i think of it, perhaps we should only set iopriority instead of both it and niceness for low-priority fscks. The iopriority should prevent thrashing, and equal CPU priorities could utilize multiple processors better.
<smoser> mathiaz, it doesn't work today
<mathiaz> smoser: right - I noticed that
<smoser> needs update to new mountall, and also needs to say "mounted MOUNTPOINT=/"
<smoser> heres what i have right now for "early boot"
<smoser> start on (local-filesystems and net-device-up IFACE=eth0)
<smoser> i believe thats generally functional, but i've been playing with a lot of workarounds
<kirkland> what is tileblit and bitblit?
<kirkland> these are dragging in the fbcon module on the Lucid ubuntu-server installs
<kirkland> which is definitely not desired (by me anyway)
<kirkland> blacklisting isn't working either
<geser> where do I file bugs against manpages.ubuntu.com?
<kirkland> geser: lp:ubuntu-manage-repository
<kirkland> geser: if it's a bug with the generation
<kirkland> geser: bugs against manpage content should go against the supplying package
<geser> kirkland: it's a bug with converting the printf.3 manpage. it stumbles about the \0 inside the manpage
<kirkland> geser: okay, sure, file a bug
<kirkland> geser: send a patch, that would be great ;-)
<kirkland> geser: i don't spend much time working on manpages.ubuntu.com any more
<kirkland> geser: usually just a day or two per cycle, to get it working with the new code name
<kirkland> geser: and i'll scrub a few bugs while i'm at it
<kirkland> geser: fwiw, that has already happened for this cycle, so it might be a while
<geser> no hurry, I just found this today and want to file it before I forget about it
<geser> james_w: I was trying to do a bzr merge of perl (I've already submitted a debdiff for sponsoring) but got stuck as the debian branch is pretty old and perl is also listed at http://package-import.ubuntu.com/failures/.bzr/failures/. Do I need to do something about it?
<james_w> geser: that's a bug I need to fix
<geser> james_w: so I can only wait on someone looking at the u-m-s queue and sponsoring the debdiff?
<james_w> geser: unfortunately so
<geser> no problem, I justed wanted to be sure with several processes getting updated this cycle
<ebroder> Can anybody add me to ubuntu-universe-sponsors?
<geser> persia: ^^
 * persia fiddles with LP a bit
<mathiaz> kirkland: hey
<mathiaz> kirkland: is bridge networking working correctly on NCs?
<mathiaz> kirkland: this is on lucid
<persia> ebroder: What's your LP ID?  LP is being annoying.
<ebroder> broder
<kirkland> mathiaz: i can't say yet
<kirkland> mathiaz: i'm just getting the eucalyptus 1.6.2 packages tested now
<ebroder> persia: \o/ Thanks!
<ebroder> Do new packages in Debian automatically sync to Ubuntu?
<ebroder> Or do they need to be manually approved the first time?
<james_w> it's a semi-automatic process
<james_w> the autosyncer pulls them in
<james_w> but that's not being run very frequently at the moment
<ebroder> Ok, sounds good
<kirkland> is bzr pull from LP hanging for anyone else?
 * kirkland found the #launchpad topic
<mathiaz> kirkland: yop
<JontheEchidna> asac: ping
<Keybuk> mathiaz: no
<Keybuk> mathiaz: you'd block any filesystems from mounting until a network device came up
<Keybuk> ion: sounds right to me
<Keybuk> ion: I'm increasingly convinced *that* behaviour of Upstart is wrong too :p
<ion> keybuk: Sorry, what behavior of Upstart? It does priority manipulation?
<Keybuk> ion: no, that "on foo and bar" blocks foo until bar happens
<Keybuk> it seemed like a good idea at the time
<Keybuk> it still does have useful effects
<Keybuk> but it's susprising everyone :p
<sebnerr> Keybuck: The magic of opensource, Hmm? hoia BTW :)
<ion> keybuk: Ah
<slangasek> pitti: hmm, didn't solve that because I didn't realize it needed solving :)  Had thought about including the bug # in the WI description, but then thought it might be better to extend the database first to include other structure :)
<ebroder> If I have a pre-Karmic (site-local) package that's shipping an upstart event.d file, what's the best way to start it in the postinst? Just use initctl?
<nixternal> anyone able to use bzr+lp right now?
<Guest50176> i am using ver 8.04, is there a utility to check the health of the hard drive?
<persia> nixternal: /topic in #launchpad implies not
<persia> Guest50176: #ubuntu for support
<nixternal> thanks persia
<superm1> is bzr+ssh different than bzr+lp?
<superm1> i didn't realize there was a bzr+lp
<LaserJoc1> I thought they were the same thing, just bzr+lp does like the lp:<branch> stuff
<wgrant> superm1: 'bzr+lp' doesn't exist. I suspect nixternal just meant bzr and LP.
<nixternal> wgrant: it is a new feature silly, you didn't know about it? :p
<elmo> james_w: ping
<LaserJock> hmm, I swear I've seen bzr+lp URLs
<elmo> james_w: (urgently)
<james_w> hi elmo
<LaserJock> maybe I've finally fallen of the deep end
<elmo> james_w: can you look at jubany?  I think you're DOS-ing bzr.lp.net
<elmo> it's OOMKed itself twice in as many hours, and you have a scary number of bzr processes on there; could be random coincidence
<james_w> yeah, something looks odd
<james_w> lots of hung ssh processes
<james_w> I'll stop it and investigate
<sebnerr> nixternal: another k3b update waiting for you :p
<sebnerr> james_w: buh a lot of discussion going on now about bzr :/
<james_w> hi sebnerr
<james_w> is it talk like a pirate day?
<sebnerr> james_w: haha. nah I suppose I can't use my bouncer on my iPod
<sebnerr> and _ is boring :p
<dtchen> joaopinto: user.log for starters, but you'll want to use wiki/PulseAudio/Log
<dtchen> joaopinto: that's normally a sign of a badly behaved client not the daemon itself.
<joaopinto> dtchen, ok, i will try to get it next time, i had a new event, but this time it was going to max sound
<dtchen> (though of course there's a bug in that the daemon shouldn't belly-up)
<joaopinto> I was wondering if could something realted to the volume changing keys instead
<joaopinto> related
<joaopinto> since it was providing the visual hint when you press the keys
<dtchen> joaopinto: are you using PULSE_NO_SIMD=1 ?
<dtchen> joaopinto: also, we should move this to +1
#ubuntu-devel 2009-12-18
<dholbach> good morning
<mvo> hey dholbach
<dholbach> hey mvo
<dholbach> mvo: ALTER!!!!!
 * dholbach hugs mvo
<mvo> :)
 * mvo hugs dholbach
<dholbach> Up early?
<mvo> yes
<dholbach> same here :)
<jml> are we the upstream of the acpi-support package?
<jml> dholbach, hello!
<dholbach> hiya jml
<dholbach> jml: what about that UDW session? :-D
<jml> dholbach, last week of January, right? I'll be in the UK that week.
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
<jml> dholbach, I was just about to ask :)
<dholbach> jml: acpi-support is in debian too
<jml> I'm trying to find the upstream vcs for it.
<dholbach> let me see
<jml> dholbach, I can do the Friday 1800 slot.
<dholbach> wow, it's even in sync with debian in lucid
<dholbach> jml: which topic? lplib? :)
<jml> dholbach, I can do lplib. I could also do an "Ask Launchpad" session
<jml> dholbach, whichever you think would be more interesting.
<dholbach> jml: which one would you prefer?
<jml> dholbach, I have no preference.
<jml> wow, it's going to be exciting being able to actually attend some of these sessions :)
<jml> dholbach, probably lplib is best.
<jml> dholbach, keep it concrete & code-y
<dholbach> hum, it could be that we're "upstream" for acpi-support
<dholbach> it's a bit of a weird divergence
<dholbach> slangasek might know more
<dholbach> the debian/copyright of the debian source package says something like "It was downloaded from http://archive.ubuntu.com/....."
<dholbach> jml: shall I pencil you in? session title? :)
 * jml tries to think of a clever title that doesn't violate the CoC
<dholbach> haha
 * dholbach hugs jml
<jml> I'm all out of clever. How about "Meet launchpadlib"?
<StevenK> "launchpadlib and you: Making access to Launchpad easier" ?
<dholbach> sounds good to me :)
<jml> I'm just going to make lp:~ubuntu-core-dev/acpi-support/trunk the dev focus for acpi-support. slangasek can correct me if I'm wrong.
<dholbach> jml: sounds good to me
<dholbach> jml: thanks a bunch for helping out with UDW :)
<jml> dholbach, my pleasure.
<dholbach> we have a fantastic line-up this time
<dholbach> I mean we always do :)
<jml> dholbach, yeah. I'm looking forward to heckling at rockstar's talk :)
<dholbach> haha
<jml> Ng, hello.
<jml> Ng, could I persuade you to set the development focus branch for https://code.edge.launchpad.net/evdev ?
<dholbach> who can I interest in another UDW session? there's still 4 open slots!
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
<slangasek> jml: that should work
<jml> slangasek, thanks.
 * jml is doing a little mindless data gardening
<wgrant> Can I convince somebody to sync something like jack-tools? 3.0 support works now, and I'd like to see that syncing actually works.
<wgrant> (jack-tools has all the things that are likely to trip Soyuz up, and it has no real changes, so it seems like a good test)
<slangasek> wgrant: I synced one already
<slangasek> (abraca, now in dep-wait)
<wgrant> slangasek: But it at least hit the buildds? Good.
<slangasek> yep
<slangasek> thanks for all your help to get v3 happening :)
<wgrant> np
<wgrant> Sorry it took so long.
<junjun> hi
<junjun> i get the source of 9.10 kernel, and found that Ubuntu patches the vanilla kernel. where can i find the information on the patch?
<junjun> i want to know which change Ubuntu made to the vanilla kernel
<junjun> the patch to 2.6.31 is pretty big.
<junjun> except AppArmor, and ndiswrapper, what else Ubuntu change to the kernel?
<dholbach> junjun: try asking in #ubuntu-kernel (and maybe wait a bit, the folks might still be asleep :-))
<junjun> dholbach: thanks!
<pitti> Good morning
<pitti> slangasek: right, I think there should be an extra field in the workitems table eventually; but oh well, kees already fixed it for now
<junjun> from Ubuntu 9.10, we patch kernel with Non-Exec stack patch. Is that exactly the patch named Exec-Shield from Redhat?
<junjun> if not, what is the difference with Redhat's Exec-shield??
<junjun> oh well, it seems Ubuntu uses the patch from Redhat (Fedora)
<kees> junjun: "execshield" is the entire unbrella project that Redhat put all their hardening features under.
<kees> junjun: Ubuntu's kernel carries the last remaining piece of that which is not already upstream, the partial nx-emulation for i386
<junjun> kees: so you mean we only port the kernel patch to Ubuntu, but not the rest?
<kees> junjun: everything else already in the kernel, userspace, etc.
<kees> junjun: some details here: https://wiki.ubuntu.com/Security/Features
<junjun> it is interesting to know, thanks
<kees> sure, np
<junjun> so far, it seems only kernel of Fedora (and Redhat, CentOS) and Ubuntu uses this patch.
<kees> junjun: afaik, SUSE uses it as well, but I haven't personally verified it.
<junjun> the rest like OpenSuse, Debian, .... dont. is that correct?
<kees> Debian does not use it, correct.  I'm unsure about SUSE
<junjun> kees: ok, i will check that
<kees> junjun: as linked from https://wiki.ubuntu.com/Security/Features#Non-Exec%20Memory I have a simple regression test that can help validate a given kernel.
<kees> junjun: the patch itself is here: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commitdiff;h=eb56f42a4bc9c671a19dcf8fd36eb3f341de7dfa
<kees> it's based on the bits from http://www.codemonkey.org.uk/projects/execshield/
<junjun> kees: very clear, thanks!
<junjun> kees: why this patch doesnt work for 64bit kernel??
<kees> junjun: the cs-limit approach doesn't make sense for 64bit, and nearly all 64bit system already implement non-exec in hardware, so the emulation is unneeded.
<junjun> what do you mean by "cs-limit approach doesn't make sense"??
<kees> the partial nx-emulation patch uses the cs segment limit to split userspace into two region (one executable, the other not).  as I understand it, there's no reason to do this for 64bit, since 64bit is PAE, which implements the NX bit in the page table, so no artificial separation is needed.
<tseliot> pitti: shall I make nvidia depend on acpid and acpi-support or would the former suffice?
<pitti> tseliot: just acpid, please
<pitti> acpi-support is unrelated to what nvidia does, and is still on the "to die" list
<tseliot> pitti: ok, the latter seemed too much as a dependency to me but I wanted to be sure
<fabbione> zul: ping? is there a bacula 3.0.X backport for hardy anywhere?
<tkamppeter> pitti, can you upload Poppler for me, debdiff on bug 293832? Thanks.
<ubottu> Launchpad bug 293832 in poppler "printer prints page at wrong position, page cut" [High,Fix committed] https://launchpad.net/bugs/293832
<pitti> tkamppeter: hi! sure
<pitti> tkamppeter: should the other tasks be "invalid"ated then?
<Ng> jml: hey, is that still required?
<tkamppeter> pitti, I think so.
<pitti> tkamppeter: uploaded
<Ng> jml: well, I suppose I can see that there's no focus set, so I suppose a better question would be what would you like it set to? ;)
<tkamppeter> pitti, the non-Poppler tasks are invalidated now, thanks for uploading.
<pitti> ogra: bryce_ wrote a basic test plan for touch screens to check that the udevification didn't break anything (https://wiki.ubuntu.com/X/Testing/Touchscreen); does that look reasonable to you, or is there something important that should be added there?
<mdz> Ng: re: the mkinitramfs error, 17-12-2009 11:30:21 < slangasek!n=vorlon@minbar.dodds.net: mdz: yes, Keybuk said he was going to fix that today
<Ng> ah, sorry
<StevenK> pitti: What was the magical gvfs-mount option again?
<pitti> StevenK: for doing what?
<StevenK> pitti: A USB key I just inserted is not automounting
<pitti> StevenK: so you want to mount it manually? gvfs-mount -d /dev/foo
<StevenK> steven@liquified:~% gvfs-mount -d /dev/sdb
<StevenK> No volume for device file /dev/sdb
<pitti> so gvfs-mount -li doesn't have /dev/sdb then?
<pitti> does devkit-disks --mount /dev/sdb work?
<StevenK> pitti: No, gvfs-mount -li does not have sdb
<StevenK> devkit-disks ... does work, though
<pitti> StevenK: does gvfs-mount -oi say anything when you plug this in?
<StevenK> pitti: Yes, and it actually mounted it this time.
 * StevenK curses heisenbugs
<pitti> free: can you please make bug 455217 public, so that it can be SRU-processed?
<ubottu> Bug 455217 on http://launchpad.net/bugs/455217 is private
<free> pitti: oops, sorry, just made it pubblic, thanks
<pitti> free: and please make sure that all the fixed bugs have proper ubuntu package tasks
<free> pitti: I think I'm not entitled to create tasks? or how do I?
<free> pitti: I couldn't figure out how to do it last time
<pitti> free: "Also affects distribution" -> ubuntu/landscape-client
<free> pitti: okay, on all the bugs related to the SRU?
<pitti> right
<pitti> we need to track their fixes/status in all releases
<pitti> I started adding them
<free> okay
<pitti> all added now, I think
<pitti> free: would you mind reviewing the bugs and closing the lucid tasks which are already fixed?
<free> pitti: sure
<pitti> thanks
<free> pitti: I guess I can use "Fix released" for lucid tasks right?
<pitti> free: if they are fixed in lucid, yes
<free> pitti: okay, so that's done
<pitti> cheers
<free> pitti: there a now bugs that have the Lucid task with fix-released, and bugs that have a new Ubuntu task (no release-specifc tasks yet)
<free> pitti: so, I don't think I can open release-specifc tasks, can I?
<pitti> free: you can nominate
<free> pitti: what does that mean exactly?
<pitti> free: the tasks won't be created yet, but they will shown as "proposed for jaunty-update", etc.
<pitti> I'll accept them while reviewing
<free> okay
<free> pitti: I can't figure out how to nominate, I can't see any "nominate" or similar button in the bug page UI..
<pitti> free: "Target to release"
<pitti> (with the ubuntu task selected, not the upstream task)
<free> pitti: and how do you select the Ubuntu task? clicking on it just brings me to the landscape-client source page in the ubuntu LP project
<pitti> free: hm; just change the URL to /ubuntu/+source/landscape-client/... ?
<pitti> or change anything else in the ubuntu task
<pitti> like priority, assignee, etc.
<free> pitti: okay, manually entering the url like you suggest works, but changing something the ubuntu task doesn't, I couldn't find any way to do it except manually entering the url
<free> pitti: okay, the bugs without specific release tasks should be all nominated now (for intrepid to lucid)
<pitti> free: can bug 455217 be fixed in lucid, too?
<ubottu> Launchpad bug 455217 in landscape-client "Handle release-upgrade messages in the packagemanager plugin" [Medium,Fix committed] https://launchpad.net/bugs/455217
<free> pitti: yes
<free> pitti: just marked it as Fix released
<pitti> great
<zul> fabbione: no there isnt a backport
<fabbione> zul: thanks, I have done myself
<zul> fabbione: cool
<fabbione> zul: you might want to take care of Lucid release notes for upgrading tho
<fabbione> zul: you need to have a director > 3.0 to talk to fd > 3.0
<fabbione> zul: dir 3.0 can talk to fd in any version but not the other way around
<zul> fabbione: thanks for the heads up
<fabbione> zul: so basically, if you want LTS to LTS upgrade plan, the director machine needs to be done first
<zul> gotcha
<zul> james_w: did the import failed for samba i dont see it in launchpad?
<james_w> zul: it was stuck in the queue, I've set it to run next
<zul> james_w: thanks
<Keybuk> mdz, Ng: it was stuck in NEW :p
<Chipzz> http://www.advogato.org/person/robertc/diary.html?start=129
<Chipzz> this gets a major ++ from me
<Chipzz> I would hope this mentality would propagate to more debian and ubuntu developers
<joaopinto_> I really don't see the relation between upstreams doing their own packaging, and including the debian/* in the upstream source
<joaopinto_> I agree with the first, not with the second
<james_w> why?
<joaopinto_> because debian/* use dependencies or rules some times tweeaked for specific distros/releases
<joaopinto_> there is no advantage on having them including on the source, there is the advantage that other packagers will need to patch or rm the upstream debian/*
<joaopinto_> ops, disadvantage
<joaopinto_> upstreams doing the packaging is a social subject, including debian/* in the source is a technical one
<james_w> upstream sometimes has code that doesn't work on Ubuntu, so there is a disadvantage that we sometimes need to patch it, so upstream shouldn't ship any code
<joaopinto_> james_w, source code is generic, as far as possible, debian/rules are not, and you failed ot mention what at the advantages of having it include on the source :)
<joaopinto_> ops, I meant debian/*
<james_w> debian/* are generally, otherwise we wouldn't be able to derive from Debian without making vastly more changes than we do
<Ng> joaopinto_: I like it when I unpack a tarball of some new software and I can just build a package out of it immediately. That's why I include a debian/ in my projects :)
<ScottK> Is Google Talk audio supposed to be working with Empathy in Karmic?
<ScottK> Ng: The problem is most upstreams that attempt to do this, don't know a lot about Debian packaging.
<james_w> ScottK: I don't see that as a reason to tell every single upstream that does it off, as seems to be the culture currently
<joaopinto_> james_w, you are refering to the general case of Debian versus Ubuntu, the debian/* world does not stop there, and still, your sentence is not accurate when you need to backport
<Ng> ScottK: I would absolutely fit in that pot, which is why I merge back in the correctness from nxvl's packaging :)
<joaopinto_> Ng, if you want your projects just to build, provide a .dsc file
<joaopinto_> Ng, you will help those which "just want to build" per your rules, without interfering with others that want to build in another way
<Ng> joaopinto_: I don't follow, how does a .dsc help?
<james_w> for a .dsc file to make any sense you have to have a debian directory, no?
<joaopinto_> Ng, dget file.dsc && debuild
<joaopinto_> no, you just need the .dsc, diff, and orig
<joaopinto_> and everone is happy with a single dget command, versus a wget source
<StevenK> joaopinto_: Which you can't build without a debian directory in the source
<joaopinto_> StevenK, you can, because I am refering to a .dsc which points to both the orig.tar.gz and the debian diff
<StevenK> joaopinto_: And what do you think is in the debian diff? The debian directory.
<joaopinto_> StevenK, right, but provided as it should as a diff, not included on the original source
<james_w> joaopinto_: so you refuse to let us re-use and collaborate on that debian/ directory in the most natural way, as we do the rest of the code?
<james_w> no thanks
<joaopinto_> james_w, no, but I don't agree that the proper place for packaging collaboration is the source, you do collaboration for a group at the cost of other group
<ScottK> Another issue is that improvements to Debian packaging need a new upstream release if that's the canonical source for them.
<james_w> it's not a cost that means much
<james_w> it doesn't have to be the canonical source, or diff.gz can make modifications
<Ng> how much variation is there in the packaging of debian derivatives? talk of costs without numbers seems a bit pointless
<joaopinto_> james_w, ah ok, so you assume that your need for collaboration is more important than others needs for a clean source :)
<james_w> improvements to the code don't need a new upstream release, we are generally happy to patch and feed the changes back for the next release
<joaopinto_> that's something personal, nothing to argue about :)
<joaopinto_> james_w,  upstreams should be able to collaborate if the debian/* dir is kept in any VCS
<Keybuk> huh?
<Keybuk> upstream should never put the debian/ directory into their VCS
<Keybuk> that's just wrong
<joaopinto_> the only good reason I see on this change would be, "Hey you cand build .debs from the source", when there is no one able to set up a PPA or get it into the repositories
<Keybuk> anyone can have a PPA
<joaopinto_> but again, that is not collaboration :)
<joaopinto_> Keybuk, we are debating that http://www.advogato.org/person/robertc/diary.html?start=129
<Keybuk> there's no loop or step to getting one, just create a Launchpad account
<Keybuk> I disagree strongly with Robert ;)
<Keybuk> one of the biggest problems I ever have, as a distribution maintainer, is upstreams who put the packaging into their tarball
<Keybuk> because it's always wrong
<Keybuk> and it makes it very hard for us to modify it
<jcastro> it should just be another branch imo
<Keybuk> in certain ways, for example removing a debhelper config file, it becomes impossible to modify without repackaging the software entirely
<jcastro> like how we're doing for UDD
<joaopinto_> Keybuk, that was the pointing I was making
<Keybuk> (because our source package format doesn't permit removing files in the diff.gz)
<james_w> Keybuk: to be fair, Rob says we should fix that.
<Keybuk> you also end up the situation where it looks like it's got a package
<Keybuk> but the package is wrong
<Keybuk> so people think they can grab the upstream tarball
<Keybuk> build it
<Keybuk> and then install it on their distribution
<Keybuk> that could go *badly* wrong
<Keybuk> look at the .spec file issues between SuSE and RedHat for an example ;)
<LaserJock> hmm, so what happens if upstream has a debian/ but Debian, Ubuntu, <any old .deb-based distro> wants to package in different ways?
<LaserJock> does the upstream need to pick which distro to support? or do they use something like control.in?
<Keybuk> LaserJock: it gets more fun
<Keybuk> upstream might disagree with the way distributions change their packages
<Keybuk> and deliberately make it hard for distributions
<Keybuk> (this happens)
<Ng> Keybuk: why are you packaging things in isolation from the upstream? if their debian/ is wrong they must care enough to have one, so presumably want a correct one?
<Keybuk> Ng: it means they want one they *think* is correct
<Keybuk> that's so far removed from "a correct one" that they may as well be in different universes
<Ng> Keybuk: I think they want one that produces a working package
<Keybuk> see, that's the problem
<Keybuk> let me give you an example
<ScottK> Ng: Which is a small subset of what it takes to be correct.
<Keybuk> I have an upstream, who we'll call Ted
<Keybuk> he maintains a piece of software, which we'll call e2fsprogs
<Keybuk> and he also happens to put the entire debian/ directory in his package
<Ng> Ted sounds like he cares about his users!
<Keybuk> tricks that Ted has done in the past include adding code to his debian/rules to disable features on Ubuntu
<Keybuk> because he thought that Ubuntu was doing things wrong
<Keybuk> turned out that was a bug in his kernel code he was hiding
<Keybuk> the only reason he was getting bug reports from Ubuntu users is because we have lots of users
<Ng> so to avoid fixing a kernel bug we just take the packaging away from him?
<Keybuk> Ted has deliberately blocked library transitions
<Keybuk> etc.
<Keybuk> no
<Keybuk> I'm saying that in the released upstream tarball is the wrong place for packaging
<Keybuk> for a start, what's right for Debian might not be right for Ubuntu
<Keybuk> even though the packaging files are the same)
<Keybuk> I think the right way is what we do on Upstart
<Keybuk> we have a tarball we release without packaging
<Keybuk> then an upstream branch which is the tarball + packaging
<Keybuk> and we collaborate on that
<Ng> I'd concede plumbing stuff, but I like being able to grab a tarball or vcs checkout of some application and have it be ready to build
<Keybuk> if distros need their own tweaks, they branch off it
<james_w> so one person spoils it for the rest of us?
<Keybuk> Ng: build for Ubuntu or build for Debian?
<Keybuk> or build for SuSE or build for RedHat?
<Keybuk> if you build something for Ubuntu, it might not work on Debian
<Keybuk> and vice-vera
<james_w> plus, the same arguments can apply for code, though admittedly less often
<Keybuk> james_w: one of the major portions of packaging is patches to the code
<Keybuk> that's kinda the point
<Keybuk> here's a better question for you
<Keybuk> why do we have packaging at all?
<Keybuk> if the upstream tarball is perfect as-is
<Keybuk> why do we *need* a debian directory in it?
<Keybuk> why can't we automate the process of taking an autoconfery tarball and turning it into debs?
<Keybuk> packaging is all about hacks to the code
<Keybuk> packaging is changing the code to fit the distribution
<Keybuk> or changing the default configuration of the code or result
<Keybuk> changing install paths
<Keybuk> removing files we don't want
<Keybuk> adding ones that aren't incldued
<Keybuk> etc.
<Keybuk> if the upstream tarball is correct
<Keybuk> (which it often is in a large majority of the cases)
<Keybuk> you don't need packaging
<Keybuk> this is probably the primary reason I don't like packaging-in-upstream
<james_w> aside from the issue of autoconf/setup.py/Makefile.PL etc., yes
<Keybuk> you end up with a qmail-esque bizarre situation where you have "the upstream code", and "the upstream approved patches to the code"
<james_w> it strikes me you should write all this in a blog post and propose your preferred way instead
<Keybuk> we discussed this in autotools a while back
<Keybuk> the only bit you're really missing is knowing which files are libraries, which are headers, which are data, which are docs, etc.
<Keybuk> a lot of that can be guessed by path
<Keybuk> but you kinda want a manifest-like file that hints to a packaging system
<Keybuk> you also want a standard format file for things like source descriptions, licencing, etc.
<LaserJock> hmm, maybe you would want all that in a directory, maybe you could call it debian/ or something ;-)
<Keybuk> LaserJock: the idea is that it'd be useful for everyone
<Keybuk> and the debian formats are ... bizarre
<Keybuk> like, why the hell would an upstream want to have a separate changelog?
<Keybuk> their version number is already in configure.ac
<Keybuk> unfortunately the discussion kinda veered towards "looks a lot like a .spec file" <g>
<LaserJock> heh
<LaserJock> the problem I see mostly though is upstreams either 1) don't want to package at all or 2) don't want to package for several different distros
<ScottK> Or don't want to deal with distros at all and just have their users get packages from them
<LaserJock> yes
<ScottK> One of my upstreams (who uses Fedora) didn't see the point of getting his stuff into distros.
<ScottK> I got one of his packages into Debian/Ubuntu and he mentioned he'd gotten a lot of new users show up right after I did that on his mailing list.
<ScottK> Suddenly he got it and he packages his stuff for Fedora now.
<ion> Had he been tuomov, heâd have hated you for getting new users.
<Ng> popcon numbers can sometimes make a good impression :)
<LaserJock> must upstreams I know just don't have time to learn .specs and debian/ etc.
<LaserJock> *most
<ScottK> This guy was distributing rpms already, he just hadn't seen the point in going to the trouble to get it in a distro.
<LaserJock> and then there are upstreams that fork dependencies in PPAs and call it good ;-)
<jam> barry: ping
<jam> you sent a mail as "barry@canonical.com" that got blocked going to udd
<jam> did you want me to add that address?
<barry> jam: dang.  yes please!
<jam> hmm.. it says the sender is "now" a member of the list already
<jam> so apparently it should just work now
<jam> I know I have a few accounts that get a bit confused sometimes
<barry> weird, maybe it got held for other reasons
<Keybuk> if upstreams did their job properly, we wouldn't _need_ distros ;-)
<jam> I'm pretty sure it thought you weren't a member for a bit
<jam> barry: ahh, I see why now
<jam> Reason:  SpamAssassin identified this message as possible spam (score 3.8)
<barry> ouch.  i should use fewer ! and $
<jam> barry: though the message that got through was: X-Spam-Status: No, score=-2.2 required=4.5 tests=ALL_TRUSTED,AWL,BAYES_00, 	DATE_IN_PAST_03_06,MIME_BASE64_NO_NAME,MIME_BASE64_TEXT autolearn=ham  	version=3.1.7
<jam> had you posted to udd before?
<jam> As it looks like SQLGrey may have also been involved
<barry> jam: yep, lots
<jam> (I'm pretty sure you have)
<jam> oh, and that sqlgrey stuff may be my local machine, not canonicals
<jam> yeah, it probably is
<LaserJock> was barry trying to sell us on the "effects" bzr can have on our personal life? ;-)
<jam> apparently my mail host likes you
<jam> but canonical's doesn't :)
<jam> barry: so my guess is that SA doesn't like "date in past"
<jam> since it seems to think that it was sent at 4am
<jam> and then the fact that your mail client encodes everything as base64
 * barry restarts ntpd
<jam> even though it is just text
 * persia reads backscroll and yet again wishes that `gzcat foo.diff.gz | patch` was capable of deleting files
<Keybuk> persia: it is
<Keybuk> Ian Jackson just disagreed with being able to do it, so had dpkg refuse to do so
<barry> jam: i'm posting from a vm and when the host sleeps, my time gets out of whack.  unfortunately, that also seems to kill the ntpd service for some reason :(
<Keybuk> persia: I think the reason dpkg refuses is quite logical
<Keybuk> people might think that patching a file out of the tarball is an acceptable way to solve DFSG issues
<Keybuk> when, of course, it isn't
<persia> That's all!
<Keybuk> because Debian would still have been distributing the file in the tarball
<maco> arent you sposed to do that in the orig?
<Keybuk> of course, nobody believed people would ever put debian directories in the tarball ;)
<persia> I agree that it's not an acceptable way to make something DFSG-free (the tarball is shipped anyway), but it would mean that suddenly it wouldn't *matter* if upstream ships packaging (debhelpers -i helps to some degree, but only to some degree)
<Keybuk> it still makes your life hard
<Keybuk> you'd have to review every new upstream version carefully
<persia> Can we revisit that, or is that reviving horses that are best forgotten?
<Keybuk> "grr, upstream added a debian/wibble.foo file that I missed, and now my package fails to install"
<Keybuk> if we were to revisit anything basic like that, we should probably just invent a new source package format
<persia> Yeah, but one should be at least reviewing the file listing and dpkg --contents listings anyway, at an absolute minimum.
<Keybuk> put it in an ubuntu/ directory
<Keybuk> and then be done ;)
<persia> Hrm.  tempting....   but maybe not.
<Keybuk> if Colin ever gets hit by a bus, it'll be one of my first jobs ;)
<Keybuk> Mark's been wanting to do that since day one, so I know I'll be allowed <g>
 * pitti tosses http://cdimage.ubuntu.com/daily-live/20091218.1/ Keybukwards
<Keybuk> pitti: way ahead of you ;) already rsync'd down and updating TFTP and NFS roots
<Keybuk> will be interesting to see how this works
<Keybuk> I got good numbers on ratchet
<Keybuk> and I'm getting increasingly convinced that ratchet is slightly slower than max
<pitti> good luck!
<james_w> what's new in this image?
<pitti> james_w: Keybuk's speedup work from today
<pitti> (initramfs-tools, etc.)
<Keybuk> well, last night
<Keybuk> mostly initramfs-tools
<james_w> the tsort stuff?
<ion> How about devtmpfs?
<Keybuk> no, that was in 18
<Keybuk> I replaced all of the scripts/local loop with a tiny binary
<Keybuk> that uses libudev to do what all that shell was trying to do *properly*
<james_w> cool
<Keybuk> ie. if the device doesn't exist, use netlink to wait for udev to finish with it
<Keybuk> if the device exists, and is in udev's queue, also use netlink
<Keybuk> if the device exists, and is not in udev's queue, done
<Keybuk> also obviously outputs the filesystem type as udev knows it, so we don't have to separately probe fstype/blkid in the initramfs
<Keybuk> one major advantage speed-wise is that it never calls "settle"
<Keybuk> which means you can mount the root fs in the initramfs while loading of irrelevant modules is still happening
<pitti> update-initramfs: Generating /boot/initrd.img-2.6.32-8-generic
<pitti> .: 4: Can't open /scripts/functions
<pitti> Keybuk: ^ known?
<Keybuk> pitti: no, can you check through scripts/*/* and see which sources /scripts/functions *before* checking for "prereqs"
<pitti> ./local-top/cryptroot
<pitti> so, from cryptsetup
<Keybuk> pitti: fix is obvious, don't source /scripts/functions until after the prereqs case
<Keybuk> can you do that one while you're there?
 * Keybuk has an allergy to cryptsetup
<pitti> hm, I moved it down, now it says
<pitti> [: 22: Private: unexpected operator
 * pitti sighs
<Keybuk> pitti: pastebin the script?
<pitti> Keybuk: I'll try to squeeze it in (release meeting now)
<Keybuk> oh, cryptsetup has a *weird* prereqs!
<pitti> Keybuk: http://people.canonical.com/~pitti/tmp/cryptroot
<Keybuk> yeah that for just won't work ;)
<Keybuk> probably should be $(dirname $0) rather than /scripts/local-top
<Keybuk> pitti: a change I made the other day is that the prereqs bit of each script is run at mkinitramfs time
<Keybuk> rather than inside the initramfs
<Keybuk> so the generated initramfs already knows what order to run things in
<pitti> Keybuk: updated script (same URL), it doesn't complain now
<pitti> but I don't claim I really understood what I was doing
<Keybuk> basically was just expecting /scripts to exist
<Keybuk> when that's /usr/share/initramfs-tools/scripts
<Keybuk> (because I'm running it from mkinitramfs now)
<pitti> Keybuk: so, I'm fine to do that upload if you want me
<Keybuk> yup, go for it
<Keybuk> I imagine we'll hit a few of those
<pitti> uploaded
<pitti> nice, bzr bd now DTRT even without a .bzr-builddeb/ config
<james_w> inferring --merge?
<pitti> right
<pitti> the cryptsetup tree is full source, but it downloaded the orig.tar.gz, etc.
<james_w> yeah, that's (yet another) thing you can thanks jelmer for
<pitti> so far we just copied the very same config into all of our desktop trees
<pitti> jelmer: *hug*
<jelmer> pitti: :-) Glad to hear
<jelmer> we have similar itchjes
<Keybuk> james_w: I still have issues getting the first tarball into bzr ;)
<Keybuk> I do sick and evil things like make a pretend upstream-last-release tag
<Keybuk> or remove debian/changelog and import-dsc the source package I just generated
<Keybuk> I noticed that it seems to upset the auto-importer though ;-(
<james_w> hmm
<james_w> I thought merge-upstream was supposed to work, but I can believe that I broke it
<Keybuk> it won't work if there isn't a previous upstream tarball
<Keybuk> it will only make deltas I assume
<Keybuk> never the initial tarball
<Keybuk> you can trick it into doing so though
<james_w> yeah
<james_w> we should fix that :-)
<Keybuk> I have been heavily using the bzr stuff though
<Keybuk> my workflow this cycle is "bzr branch lp:..." ... doesn't exist? file bug; out of date? file bug (and apt-get source)
<Keybuk> otherwise just use the bzr
<pitti> ttx: what I meant is that e. g. bug 497455  -> we won't promote until it actually appears on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<ubottu> Launchpad bug 497455 in libwoodstox-java "MIR for libwoodstox-java" [High,Fix committed] https://launchpad.net/bugs/497455
<ttx> pitti: right. It's a eucalyptus runtime dep, so I guess it will show up once the package in built
<jelmer> pitti: btw, I noticed the MIR for tdb - some of the issues there should be fixed in the version of tdb in sid
<jelmer> pitti: Are you the right person to talk to about the MIR, or somebody else?
<jelmer> pitti: (I'm the Debian maintainer)
<pitti> jelmer: I'm one right person, yes
<kees> pitti: for the SIGXCPU+apport thing, I saw that you merged it, but I just wanted to make sure you felt that was a valid approach.
<pitti> jelmer: which "issues" do you mean?
<pitti> kees: it looks fine to me
<kees> pitti: ok, cool.  No other signals like those two jumped out.
<jelmer> pitti: tdb-dev has been renamed to libtdb-dev, manpages will be included in the next upstream version
<ScottK> slangasek: It'd be nice (although lower priority than powerpc) if you could look at qt4-x11 on ia64 too.  I'm lost in a twisty turny maze of ifdefs.
 * slangasek gibbers
<ScottK> slangasek: The upstream feedback was: You have a config.h, remove it.  the issue is that #include "config.h" is including the wrong file
<ScottK> Since it works on other archs.
<ScottK> I think it's an ifdef issue
<Keybuk> mdz: are any of the videod sessions ever going to appear on blip.tv ?
<machina> hi, I'm trying to update this copyright from this http://pastebin.com/d5200e964 to this http://pastebin.com/d1fafa456 but I don't know if it's right for me to put a copyright under the debian maintainer's name?
<machina> this is about updating an Ubuntu/debian package btw..
<ebroder> I don't suppose I could ask somebody to do a sync run so the new version of the packge I was just about to work on would hit the repos? :)
<ScottK> slangasek: I think I found my way through the twisty/turny maze for qt4-x11 ifdefs and ia64.  Found a "-   || defined(__ia64__) \" between the last version and the current one.
<slangasek> ah, cool
<slangasek> ebroder: what package?
<ebroder> slangasek: open-vm-tools
<slangasek> ah, needs a sync run on contrib; looking
<slangasek> ebroder: syncing
<ebroder> Yay! Thanks, slangasek
<Lutin> those days, who do I have to ask to get a give-back on the buildds ?
<ScottK> slangasek: If I give you a debdiff for qt4-x11, could you testbuild it on a ia64 porter box?  It's a huge package for me just to blind upload.
<slangasek> sure
<ScottK> OK.  I'll have it in a few.
<ScottK> .dff.gz for that package takes an eternity to generate on my laptop.
<ScottK> dff/diff
<ScottK> Right, so the good news is the emergency drop protection shutdown on my laptop works.  The bad news is the diff.gz wasn't done yet.
<ScottK> It was kind of cool to see the laptop blink off in mid-air when I dropped it.
<slangasek> heh
<ion> Why power down the entire laptop? Why not just park the HDD heads?
<Lutin> could someone with a lucid chroot try to install libeina-svn-05 (no matter what arch.)
<slangasek> Lutin: could; but is the problem you're trying to solve related to the fact that this package needs a binary promotion to main?
 * ScottK guesses yes.
<ScottK> ion: I didn't design the hardware.
<ion> Nobody blamed you for the hardware design.
<ScottK> It just seemed odd to ask me why it worked the way it does.
<ion> I asked the channel.
<ScottK> ok
<ion> sincerely willing to learn the technical reason for shutting down everything.
<slangasek> perhaps because the hardware doesn't trust the OS to park the heads and leave them parked
<ion> The hardware could force the heads to be parked for a period and the OS to wait.
<ScottK> slangasek: http://pastebin.com/f3e99eaa3
<ScottK> slangasek: On the off chance that builds, please just throw it at the archive.
<slangasek> how do I extract a usable patch from pastebin?
<arthur_> slangasek: see the textarea in the bottom
<slangasek> I see it; cut-n-pasting from it didn't please patch, that's why I was asking
<arthur_> right after "To highlight particular lines, prefix each line with @@"
<arthur_> ah
<slangasek> patch: **** Only garbage was found in the patch input.
<slangasek> oh, haha
<slangasek> because it eats @@ at the beginning of a line
<arthur_> nice spot
<slangasek> ok, got it
<ScottK> Oops
<ScottK> When I click on download it comes up correct.
<slangasek> oh, there's a download button, ok
<slangasek> :)
<Lutin> slangasek: that's it, thanks
<slangasek> Lutin: ok, should be fixed in the next pulse then
<Lutin> alright, thanks a lot
<Lutin> slangasek: in fact JamieBennett just pointed out that it's been promoted some times ago
<slangasek> Lutin: not so; the binary was in universe until around the time I commented
<JamieBennett> Jonathan RiddellÂ wroteÂ on 2009-08-24:#6 Package moved to main
<JamieBennett> from the bug comments
 * ScottK suspects a library transition
<slangasek> that refers to a source package
<Lutin> ah, true. the source package introduces a new binary package which wouldn't have been promoted automatically ?
<JamieBennett> slangasek: Is there an active archive admin around which could kick the binary into main for us then?
<slangasek> JamieBennett: already did, see above
<JamieBennett> OK, thanks
<slangasek> Lutin: it's a routine archive admin activity to reconcile http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, so it /should/ be < 48h turnaround from accepting the package to making sure it's in main if it's supposed to be
<Lutin> slangasek: ok, thanks for the explanation
<wgrant> lamont: Are you planning to get the lp-buildd changes merged soonish?
<lamont> bigjools was supposed to land them, I thought
<wgrant> Ah, OK.
<lamont> lp:~lamont/launchpad/lp-buildd/
<lamont> is what I actually built
<lamont> and actually has changes beyond 54
<wgrant> Ah, I wondered what those extra three revs were for.
<lamont> yeah, it was the lalalalalalala fix these too things that fell out of reviewing changes to the machines where I installed the package
<lamont> some just landed after I'd cut 54, and/or were invasive enough that I want them to get more testing before I roll them.
<HenriqueRocha> hi
<lamont> slangasek: bug 498331
<ubottu> Launchpad bug 498331 in libgphoto2 "FTBFS: excessive something" [Undecided,New] https://launchpad.net/bugs/498331
<HenriqueRocha> i'm trying to install lucid alpha 1 but it doesn't install
<slangasek> lamont: how precise :-)
<lamont> slangasek: I decided to make sure it had a descriptive subject....
<lamont> dear fellow buildd admins:  DO NOT give-back libgphoto2/armel.
<hrocha> is it possible that it is not installing because i'm using the locale in portuguese?
<slangasek> hrocha: #ubuntu+1 is the channel for lucid support; I'm not aware of any locale-specific issues in alpha-1
<hrocha> ok, thanks
<ebroder> Wait, what? Why can't I target bug #191776 for Hardy? The package has always been in multiverse - I should be able to
<ubottu> Launchpad bug 191776 in open-vm-tools "Shutdown guest using the VI Client with VMware ESX 3.0.2 doesn't work" [Low,Fix released] https://launchpad.net/bugs/191776
<wgrant> ebroder: It doesn't exist in Hardy.
<wgrant> It was removed just before release.
<ebroder> Huh! How about that
<wgrant> (and it was in universe then)
<ebroder> Oh yeah - the bug was reported against Hardy a4
<ebroder> It seems like it would be useful if I could deal with nominations for releases the package wasn't in at all. Oh well
#ubuntu-devel 2009-12-19
<ebroder> Can somebody help me understand what's going on with <https://launchpad.net/ubuntu/+source/istanbul/0.2.2-5ubuntu1/+build/1405019>?
<ebroder> I don't understand why python-gnome2 wouldn't be installable
<ebroder> (Or why the FTBFS would be arch-specific)
<crimsun> ebroder: python-gnome2 -> libgnome2-0 -> libesd0 -> esound-common
<ebroder> crimsun: What's wrong with esound-common?
<ebroder> (I don't have a Lucid box/VM yet for testing)
<crimsun> ebroder: libesd-alsa0 is awaiting binary NEW, so it prevents esound-common from being installed (since the latter is arch all)
<crimsun> cf. https://launchpad.net/ubuntu/lucid/+queue
<ebroder> crimsun: *sigh* ok. Why isn't this putting my build in dep-wait instead of failure?
<wgrant> It's complicated. The dependencies are there, but are uninstallable.
<wgrant> That needs something like debcheck to determine when to retry.
<wgrant> Which Soyuz does not currently do, and Debian only recented implemented.
<ebroder> So just keep clicking the retry button every once and a while until it works?
<crimsun> I'd wait until libesd-alsa0 is binary NEWed and published.
<ebroder> Sounds good
<ebroder> crimsun: wgrant: THanks
<CarlFK> esound-clients: Depends: esound-common (= 0.2.41-6ubuntu1) but 0.2.41-6 is to be installed
<CarlFK> in case this wasn't answered: "ebroder: crimsun: What's wrong with esound-common?"
<crimsun> how was it not answered?
 * ScottK is pretty sure it was answered
<jml> Ng, to "~vcs-imports/evdev/master", sorry.
<jml> Ng, I should have mentioned that.
<ebroder> So is esound stuck just because it's waiting for an archive admin? Because ubuntu-desktop isn't installable right now
<wgrant> That's right.
<ohay> I asked this on #ubuntu but no one could give me an answer
<ohay> can I choose between Grub 1 and 2 using the alternate-install CD ?
<persia> ohay: That #ubuntu doesn't have the answer doesn't make this a support channel.
<persia> You might try again later, or file a question at answers.launchpad.net/ubuntu
<ohay> ok then
<Mamarok> doko_: did cjwatson talk to you about a backport of glibc for karmic?
<junjun> hi
<junjun> it seems Ubuntu 9.10 kernel turns OFF the fast syscall feature?
<junjun> I checked, and it seems SYSENTER_CS = 0
<junjun> with vanilla kernel, SYSENTER_CS = 0x60 at run-time.
<junjun> so Ubuntu patched kernel to disable Sysenter?
 * ScottK looks over at slangasek and wonders how the ia64 build turned out?
<zbert> hello?
<zbert> I'm usinig ircii
<zbert> and this is my first time on there
<zbert> I'd appreciate knowing these are sending aright
<zbert> oper zbert
<zbert> test
<zbert> hello
<zbert> is this working
<zbert> quit
<zbert> hello?
<zbert> anyone on here?
<zbert> hi
<zbert2> hi me
<zbert> it does work!
<zbert2> thanks for actually writing
<zbert> yep, would of been nice to have someone help me test this, oh well... bye
<zbert2> bye
<lesshaste> hello.. I have a small feature request. When you get a kernel upgrade in ubuntu, grub gets updated but it doesn't change the default kernel value so when you reboot you get some random kernel
 * ScottK suggests you reconsider some assumptions.
<lesshaste> ScottK: go on... :)
 * ScottK has run Ubuntu for years and has never had that happen.
<lesshaste> ScottK: I assume you don't use anything but the latest kernel?
<lesshaste> if you have GRUB_DEFAULT=6 it will
<ScottK> OK.
<Mamarok> lesshaste: wrong, I run the same as ScottK since years, never seen that happen, neither with grub nor grub2
<Mamarok> and I had quite a few kernel upgrades since I switched to grub2
<lesshaste> Mamarok: what happens is that if you have GRUB_DEFAULT=6 say and a kernel update arrives it gets added to the top of the list
<crimsun> lesshaste: please use https://bugs.launchpad.net/ubuntu/+source/grub/+filebug/
<lesshaste> so 6 is now some other random kernel you didn't want
<lesshaste> crimsun: isn't it a feature of the tool that updates grub?
<lesshaste> whatever that is
<lesshaste> when you get a kernel update
<lesshaste> Mamarok: I think I found the official solution in any case
<Mamarok> hm, since I don't change the Grub settings and choose manually if I want another than the latest kernel, it didn't occur to me
<lesshaste> Mamarok: that's because you don't have to set it to boot to windows automatically for your partner :)
<Mamarok> nope, lucky me :)
<lesshaste> in any case, the official solutions is to use labels not numbers it seems
<lesshaste> which grub supports
<crimsun> lesshaste: I don't think the kernel's postinst should be mucking GRUB_DEFAULT
<crimsun> (missing preposition, but whatever)
<lesshaste> crimsun: well in that case anyone who doesn't use GRUB_DEFAULT=0 will have this problem
<crimsun> I fail to see why the kernel postinst needs to care about other OSes
<crimsun> regardless, the original point stands: please file the request as a wishlist bug report using Launchpad
<zbert> hello?
<zbert> this is a pretty quiet room
<zbert> is there a reason for that
<Mamarok> zbert: because it is Saturday
<Mamarok> evening in Europe, so the devs are off
<zbert> really, I'd figure for open source, Saturday would be the most busy
<Mamarok> zbert: not for those working all week on it already :)
<Mamarok> zbert: anyway, if you need support, you should ask in #ubuntu, this is not a support channel
<zbert> Yeah, well I'd never done much on ubuntu's dev so I'm new to the channels
<zbert> I'm used to just doing stuff on sourceforge and stuff... I do all my coding over the weekends so just figured it would be busier
<zbert> And I was just assuming that guidance on participating with the os would be in the dev channel, rather than just ubuntu
<slangasek> ScottK: the ia64 build succeeded; I was going to take a shot at debugging the powerpc build yet today before uploading
<ScottK> slangasek: OK.  Thanks.
<ScottK> \o/
<slangasek> that is, if my shell doesn't segfault trying to handle the grotesque linker commandline
<slangasek> (didn't happen, but for the life of me I'm not sure how :)
<ScottK> qt4-x11 is a 'fun' package.
<ScottK> BTW, 4.6.0 is just in experimental in Debian and didn't get built on powerpc.
<slangasek> looks like the workaround on ppc might be to not pass the --gc-sections option
<ScottK> slangasek: Upstream doesn't approve of my fix.
<ari-tczew> is tseliot working on fix support nvidia drivers for xorg 7.5?
<ScottK> slangasek: http://pastebin.com/d37aa0122
<ScottK> So I guess I need to look into it some more.
<slangasek> ah
<ScottK> OK, grep is a wonderful thing.
 * ScottK may have it.
<ScottK> slangasek: I admit to serious confusion about the ia64 situation.  This is now officially way over my head.  If you could look at that too, I'd appreciate it.
<slangasek> ScottK: ok.  currently, still reducing the powerpc segfault test case
<ScottK> Thanks
<ScottK> slangasek: http://pastebin.com/f3dab7d03 perhaps?
#ubuntu-devel 2009-12-20
<slangasek> ScottK: does anything use the WTF_PLATFORM_IA64 define, then?
<slangasek> ScottK: btw, bug #498631
<ubottu> Launchpad bug 498631 in binutils "ld segfaults with --gc-sections on powerpc" [Undecided,New] https://launchpad.net/bugs/498631
<ScottK> slangasek: Nothing except getting us into the JS64 set instead of 32_64
<slangasek> oh, is that what the PLATFORM() macro expands to?
<ScottK> More specifically WTF_USE_JSVALUE64 instead of WTF_USE_JSVALUE32_64
<ScottK> The first patch I gave you would have resulted in using WTF_USE_JSVALUE64, but who knows what else.
<ScottK> So I'm defining IA64 as an alternate way to get WTF_USE_JSVALUE64 without whaterver X86_64 might have brought along
<ScottK> I'm pretty sure that's what I want to have happen, I'm really unsure it that's the way to do it.
<ScottK> As I said earlier, I'm in over my head here.
<slangasek> looks appropriate to me; should I try another ia64 build to see if anything else fails, or do you just want to throw this at the buildds along with the ppc fix?
<ScottK> slangasek: Your call.  IA64 won't get more broken.
<ScottK> slangasek: WRT timing, qt4-x11 takes a long time to build on armel.  We're packaging a new KDE upstream right now that's set for upload on Monday.  It'd be nice if qt4-x11 was not in the middle of building then, so I'd like to revise my answer and prefer an upload tonight.
<ebroder> Suck. The open-vm-tools kernel modules apparently don't build on Lucid's kernel. Or Sid's
<LaserJock> where does Ubuntu Netbook Remix/Edition development happen?
<slangasek> ScottK: qt4-x11 has a completely broken clean target, btw
<ScottK> slangasek: I see what's wrong with my patch.  I'll fix it.
<fqh> Hi, all, which tool can be used to check linux kernel coding style? I forgot.
<ejat> anyone know how to temporary solve this bug 472345
<ubottu> Launchpad bug 472345 in evolution "Evolution mail client completely closes when i click 'close window' from the 'File' menu. " [Wishlist,Invalid] https://launchpad.net/bugs/472345
<akgraner> ogasawara_, ping
<zbert> Hello room... anyone in here?
<zbert> I have some questions about #ubuntu-devel
<zbert> There's a lot of names in here but no one is in here?
<geser> it's weekend so most are idle
<zbert> okay, see that's one of my questions
<zbert> isn't this an open source project?
<zbert> Yesterday I got told to go to the #ubuntu room but isn't that like general support?
<geser> yes, the Ubuntu distribution is open source
<zbert> I'm wanting to participate in development in the same way that I do on source forge projects
<zbert> Which being weekend thing confuses me as I do most of my coding on the weekend as I work my normal job during the week
<geser> it depends, this channel is mostly used by the paid Ubuntu developers who seldom work on weekends
<zbert> Yeah, see that's the answer I was looking for...
<zbert> Where's a good place for the unpaid people who do open source as a hobby?
<geser> #ubuntu-motu is where the "universe" community hang outs
<zbert> It's been a pretty big downer because I was hoping to get involved with it more this weekend but I'm not really finding a good start point, maybe I'd do better working on the bugs
<zbert> Haha... that's more the people like me who just want to do some systems coding
<geser> have you been pointed to https://wiki.ubuntu.com/MOTU/GettingStarted already?
<zbert> No, thanks... this is the help I've been looking for.
<zbert> I'm not new to coding for open source but am new to doing it for Ubuntu so I just googled ubuntu development and got to here
<geser> if you are interested in helping with Kubuntu, you might also want do look in #kubuntu-devel. The Kubuntu community is also very strong.
<zbert> Yeah, but I barely tolerate KDE on Backtrack... I really prefer gnome or open-box
<zbert> So I've not done much in working with KDE really... but I like hearing that.
<geser> gnome is discussed in #ubuntu-desktop, but also mostly during the week
<zbert> So #ubuntu-motu is more of what I'd be likely to find in working through something on like sourceforge/forge.mil type of projects?
<zbert> Same situation, mostly done by the paid staff?  Curious, are you a paid staff?
<geser> MOTUs care about the packages in the "universe" component of the archive
<geser> gnome is mostly done by paid devs but also some community devs, and I'm not paid
<zbert> Yeah, I was just reading that... I'm looking more to working with kernel programming and driver modules
<zbert> Oh cool... I've always done programming as a hobby and never really thought of it as a pay thing, it's a big reward to see a patch or something I contributed on actually being applied.  I'm actually a social worker for my full time job
<geser> the kernel people hang out in #ubuntu-kernel but I don't know how many paid/non-paid devs there are
<zbert> Nice, I appreciate this tutorial to development in ubuntu, this helps a lot
<zbert> So what projects do you work on?
<ScottK> slangasek: No joy on powerpc, ld still bites: https://launchpad.net/ubuntu/+source/qt4-x11/4:4.6.0-1ubuntu5/+build/1407295/+files/buildlog_ubuntu-lucid-powerpc.qt4-x11_4:4.6.0-1ubuntu5_FAILEDTOBUILD.txt.gz
<shtylman> is anyone else experiencing problems using intel 3945 wireless?
<shtylman> are there any recent open bugs about it?
<shtylman> (in lucid that is)
<ogasawara_> akgraner: pong
<akgraner> ogasawara_, is there a way to find total bugs ever reported for Ubuntu...on LP
<akgraner> since the code push last week that number doesn't show up anymore
<akgraner> :-(
<akgraner> ogasawara_, here is where I normally got it from  https://launchpad.net/ubuntu/+bugs
<ogasawara_> akgraner: hrm, was just going to point you to that, but if it's no longer there give me a sec and I'll see if I can find it
<akgraner> ogasawara_, thank you!
<ogasawara_> akgraner: https://bugs.edge.launchpad.net/ubuntu/+bugs?advanced=1
<ogasawara_> akgraner: as a sort of brute force approach, go to the above and tick every status
<zbert> hey, there are people in here... can I get some help finding my way around ubuntu development?
<akgraner> ogasawara_, so just click all the boxes and it will give me a total
<akgraner> well all the status'
<zbert> I'd like to contribute, particularly to kernel and gui development, but I've not found rooms that are active
<ogasawara_> akgraner: yah, tick all the status' (new, incomplete, etc. . .) and then hit search
<akgraner> gotcha.. thank you!!!
<zbert> like ubuntu-kernel is as quiet as this one... is there a decent place to go to get started contributing?
<akgraner> ogasawara_, sorry to bug you on a Sunday...
<ogasawara_> akgraner: np :)
<zbert> akgraner or ogasawara_?
<ogasawara_> zbert: it's the weekend so people are likely away.  is there a specific area you are interested in, for ex the kernel?
<zbert> <zbert> I'd like to contribute, particularly to kernel and gui development, but I've not found rooms that are active
<zbert> I'm just happy to find a foothold at this point
<ogasawara_> zbert: well I'd be more than happy to get you started with the kernel
<ogasawara_> zbert: a great place to initially lend a helping hand is triaging bugs
<zbert> I figured for open source, weekends would be a good time but I've found that ubuntu development most be done a lot by paid staff...
<ogasawara_> zbert: can you priv msg me your email and I'll send you some info to get started
<zbert> Okay, sorry to appear frustrated, I've been reading through the pages then trying quiet rooms most of this weekend, and I only have time to code on the weekend as it's all hobby for me so a day and half of getting started has been used finding a foothold.
<zbert> Sure, and thanks!
<slangasek> ScottK: blast; ok, will look at why my powerpc patch doesn't work
<ScottK> slangasek: Thank you.
<slangasek> ScottK: right; my patch doesn't work because I used another non-working bit in the build system as an example
<slangasek> ScottK: are there docs for these .pro files anywhere?
<ScottK> slangasek: I don't know.
<ScottK> I usually just ask fabo about fixing qt4 stuff.
<ScottK> Riddell: ^^^?
<slangasek> ok.  I'm confident that the workaround in question is the correct one, I just have no idea how to apply it to powerpc given this .pro file format that I have no familiarity with
<ScottK> Thanks.
<Lure> slangasek: .pro files are for qmake (from qt4)
<Lure> slangasek: doc is here http://qt.nokia.com/doc/4.6/qmake-manual.html
<slangasek> Lure: what does 'unix:!mac:*-g++*:' mean?
<Lure> slangasek: to complex for my knowledge level ;-)
<slangasek> Lure: ok, well, so far I haven't hit on the magic combination that lets me exclude powerpc from this
<slacker_nl> hi, question, will grub-legacy be upgraded to grub2 by lucid? debian does this when going from stable to testing, will you do the same with karmic/hardy to lucid
<wgrant> Laney: I've recreated the import that you retried, as bzr-svn this time. it worked: https://code.edge.launchpad.net/~wgrant/multidistrotools/trunk
<Laney> wgrant: Cool. I just grabbed it from svn directly
#ubuntu-devel 2010-12-20
<kdas> does anyone know what classifies an item as "technical item"
<micahg> kdas: well, here's the wiki page on Software center: https://wiki.ubuntu.com/SoftwareCenter, it might be on there
<kdas> anyone else?
<Keybuk> http://upstart.at/2010/12/20/the-importance-of-being-tested/
<Keybuk> ^ cjwatson: do you think my point here is too subtle? :-)
<ebroder> Keybuk: I'm not seeing much subtlety in that post :-P
<kennetham> hi does anyone knows how to set socks proxy in ubuntu terminal? network proxy set for web browsers but terminal does not seem to take effect.
<kennetham> i have tried most channels especially #ubuntu but nobody seems to be responding.
<kennetham> please advise
<tumbleweed> kennetham: there is no standard environment variable for socks proxies like http_proxy. You can use something like tsocks.
<xnox> micahg, the new "GREMaxVer" and "GREMinVer" in xulrunner-2.0-dev pacakge are broken. There is a "stray" "-e" which prevents queriying GREMinVer
<xnox> that's in libxul-embedding.pc
<sivang> hi all, is there a channelf for jokosher development?
<apw> has anyone reported that avahi hostname resolution is not working at all (in or out) for natty machines
<sherbieny> Hello
<sherbieny> can anyone tell me why I'm banned from ubuntu
<sherbieny> I didn't do anything
<cjwatson> this is not an escalation channel for problems in #ubuntu
<cjwatson> try (I think) #ubuntu-ops
<sherbieny> thanks
<Keybuk> now if only people not doing anything was a valid excuse to ban them from ubuntu-devel ;-)
<mdeslaur> cyphermox: heh, I was going to upload a -proposed evolution to maverick to fix this: bug 611983
<ubottu> Launchpad bug 611983 in evolution (Ubuntu Maverick) "Evolution [Open Link In Browser] not working for new eBay email hyperlinks" [Undecided,In progress] https://launchpad.net/bugs/611983
<mdeslaur> cyphermox: but, I was too late apparently :)
<mdeslaur> cyphermox: are you preparing something for lucid also?
<cyphermox> mdeslaur, I don't remember uploading a fix for that?
<mdeslaur> cyphermox: no, you didn't...I just meant you know have an update in -proposed, so I can't upload it :)
<mdeslaur> s/know/now/
<cyphermox> ah
<mdeslaur> cyphermox: I would like to upload that fix to lucid though, and want to know if you are working on evo packages for lucid
<cyphermox> mdeslaur, nope, you can go ahead
<mdeslaur> cyphermox: cool, thanks
<mdeslaur> hmm...now I need to figure out the procedure with the package that's already in lucid-proposed :P
<cyphermox> oops ;)
<mdeslaur> slangasek: so, there's an evolution package in lucid-proposed that doesn't fix an issue. I put a NACK in the -proposed bug (229187). I now have an unrelated fix I would like to upload to -proposed. What is the procedure? Can I just upload over it, or do I need the sru team's blessing, or what?
<Keybuk> OMG!
<Keybuk> How did I not know about dprintf() ?
<joaopinto> hi
<joaopinto> is there a known problem with the installer from the 18th daily ?
<hyperair> what's dprintf?
 * sladen suspects an application-specific debug-print-formatted
<Keybuk> hyperair: printf to a file descriptor
<Keybuk> ie. fprintf but to an int
<hyperair> Keybuk: ooh. that is awesome.
<hyperair> Keybuk: not fdprintf?
<hyperair> Keybuk: i know of fdopen though (which can then be used with fprintf)
<Keybuk> well, kinda
<Keybuk> fdopen creates a FILE * for a socket/file descriptor
<Keybuk> which means that it's buffered
<Keybuk> so fprintf may not be written or completely writtten
<hyperair> ah i see.
<hallyn> soren: I had thought that 'bzr co lp:vmbuilder' gave me trunk, but i see it does not.  Is it safe to assume that all changes in lp:vmbuilder should be made to trunk (also, or probably first)?
<lool> cjwatson: Hey; for flash-kernel I made sure we could still backport it to older Ubuntu releases which use uboot-mkimage instead of u-boot, but do we care about backports of debian-installer?  (uboot-mkimage is a build-dep)  I would think not
<lool> Sorry, I should probably ask on #ubuntu-installer
<cjwatson> joaopinto: would you care to be specific?
<cjwatson> lool: I don't care
<lool> cjwatson: Thanks; pushed to bzr then
<joaopinto> cjwatson, the installer fails with an "unexpected installer problem"
<cjwatson> joaopinto: logs?
<cjwatson> also, which CD?
<joaopinto> jcastro was able to reproduce it using testdrive
<joaopinto> 18th Dec
<cjwatson> "daily" is insufficient, we produce quite a few CDs daily!
<cjwatson> desktop, alternate, server, ...?  Ubuntu, Kubuntu, ...?  i386, amd64, ...?
<joaopinto> I have looked into /var/log/installer, couldn't find anything useful
<joaopinto> desktop i386
<cjwatson> couldn't find anything you understood, you mean? :-)
<cjwatson> surely syslog at least is there
<joaopinto>  nothing "abnormal"
<cjwatson> I can only investigate if you let me look at the logs directly
<joaopinto> I just checked the installer logs, not the regular logs, since it was the installer reporting the error
<cjwatson> actually, on the desktop CD /var/log/syslog is the main useful one
<joaopinto> ok, I am traverling now, later I will reinstall and tar /var/log
<cjwatson> since we aren't close to a milestone right now, though, it's not too surprising for a daily build to be busted, TBH
<cjwatson> but I'll rsync and see if I can reproduce it here
<joaopinto> ok, thanks
 * highvoltage installed the edubuntu desktop daily image this morning and it was just fine though
<cjwatson> joaopinto: BTW, Ubuntu desktop i386, or something else?  you just said "desktop i386"
<joaopinto> ubuntu desktop
<cjwatson> could've been a temporary problem
<cjwatson> I didn't do any test installations on Saturday
<joaopinto> I have retried 2 times
<cjwatson> temporary here means "specific to that build" not "if you try again it will go away"
<joaopinto> right, i'll see if I can, recreate the iso from the usb, update, and refresh the usb
<joaopinto> bbl
<joaopinto> is just that i feel that will be just as random as assuming it was a temporary failure :P
<slangasek> mdeslaur: just upload over it
<mdeslaur> slangasek: thanks
<cjwatson> *now* he says it was an installation from USB
<cjwatson> I DO wish people would give detail up-front
<jcastro> 2010-12-20 amd64 desktop works in testdrive
<joaopinto> I forgot my usb pen, I will not be able to retest the installer crash today :(
<cjwatson> jcastro said "2010-12-20 amd64 desktop works in testdrive"
<mvo> I did a install today desktop amd64 and that worked, I used grub loop to boot into it from the hdd directly though, so its probably not very representative
<joaopinto> ah ok, I will need to update the image
<cjwatson> could of course be USB-specific
<joaopinto> there was another issue, the installer launched a new unity session to allow to diagnose the problem
<joaopinto> but the menu does not work on that new session
<cjwatson> please file these as bugs rather than mentioning them on IRC - I don't know about anyone else but I have one work day left for the year and have a hard time fitting in the stuff I already know about :-)
<joaopinto> ok, will do
<ScottK> micahg: Would you mind looking at the packagekit FTBFS.  It fails on some mozilla related file being missing and I was wondering if you understood what was up with that.
<micahg> ScottK: I'd be happy to take a look later tongith
<ScottK> micahg: Thanks.
<highvoltage> cjwatson: hey there, I need to add the edubuntu-text theme to the plymouth package
<highvoltage> cjwatson: is the right way to do it by getting the bzr branch, adding the theme to the (quite big) quilt diff and then proposing the merge again in launchpad?
<cjwatson> yeah
<highvoltage> ok
<cjwatson> use the various quilt commands and then quilt refresh at the end
<thebishop> anyone know why autocomplete doesn't work with Make?
<thebishop> bash tab-completion i mean
<Vardan> hi
<Vardan> people how can I download/checkout ubuntu-installer and build own root CD?
<Vardan> root=boot
<SpamapS> Vardan: you could try live-builder
<SpamapS> err
<SpamapS> I don't know how to find that though.. hmm
<SpamapS> Vardan: I mean, live-helper
<geser> at little OT for here: but does someone know if it's on purpose that the wiki looks different if one is logged in or not?
<ebroder> geser: You can change it by going into your preferences
<geser> oh
<ebroder> They created a new theme and made it the default theme, but that didn't change the theme for any users already in the database
#ubuntu-devel 2010-12-21
<skynet1248> Hi I have question about kernel dynamic modules
<skynet1248> if I execute modinfo parport_serial | grep 9835
<skynet1248> I get somethink like this:
<skynet1248> alias:          pci:v00009710d00009835sv*sd*bc*sc*i*
<skynet1248> is any option to add my own alias to parport_serial module?
<micahg> ScottK: pacakgekit is baffling, same build on maverick builds fine, it seems like the mozilla plugin isn't being built for some reason on natty
<micahg> ScottK: packagekit solved (bug 692854 if you want to sponsor)
<ubottu> Launchpad bug 692854 in packagekit (Ubuntu) "packagekit FTBFS on natty" [High,Confirmed] https://launchpad.net/bugs/692854
<dholbach> good morning!
<micahg> Riddell: I fixed the packagekit FTBFS if you want to sponsor it (bug 692854)
<ubottu> Launchpad bug 692854 in packagekit (Ubuntu) "packagekit FTBFS on natty" [High,Confirmed] https://launchpad.net/bugs/692854
<janimo> in case binary new requests are to be brought up here: lightspark{,-common,-dbg} and browser-plugin-lightspark on armel were just recently introduced. thanks
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: dholbach
<janimo> Laney: hello, have you had the chance to look at the new way ghc6 fails on armel?
<AnAnt> Hello, is this http://launchpadlibrarian.net/61007900/buildlog_ubuntu-natty-i386.git-buildpackage_0.5.12_FAILEDTOBUILD.txt.gz , actually a problem of pychecker with python2.7 ?
<AnAnt> doko__: ^
<dholbach> james_w, why can't I reject https://code.launchpad.net/~stefan-bader-canonical/ubuntu/natty/e2fsprogs/branch/+merge/43541?
<dholbach> there's just "WIP", "Merged" and "Needs Review"
<doko__> AnAnt: likely pychecker, we had issues getting it updated to 2.6 too ...
 * Keybuk must stop winding Lennart up on lkml
<Keybuk> but it's such fun!
<dholbach> Public service announcement: we're down to 20 items on http://reqorts.qa.ubuntu.com/reports/sponsoring/ - YES!
<Keybuk> dholbach: I'm looking forwards to having to get all my uploads sponsored ;-)
<dholbach> Keybuk, because you'll lose your upload privileges? why?
<maco> you're de-core-dev-ing like crimsun did?
<Keybuk> because of a Launchpad bug
<Keybuk> I can't transfer my GPG key to my new LP account
<dholbach> Keybuk, seems like LP is not set up for schizophrenic personas :-P
<Keybuk> indeed
<Keybuk> I'm going to nag them about that once they've fixed the gaping hole in LP's brain where all my bzr branches used to be
<Keybuk> but you know how it is, Ticket in RT, Out of Mind
<dholbach> Daviey, do you know if bug 687971 is still blocked on bug 688522?
<ubottu> Launchpad bug 687971 in eucalyptus-commons-ext (Ubuntu) "[FTBFS] package 'eucalyptus-commons-ext' (0.5.0-0ubuntu2) failed to build on natty" [High,In progress] https://launchpad.net/bugs/687971
<ubottu> Launchpad bug 688522 in openjdk-6 (Ubuntu) "[FTBFS] Eucalyptus doesn't build on maverick, with -security pocket enabled " [Undecided,Incomplete] https://launchpad.net/bugs/688522
 * dholbach attempts a test build
<Laney> janimo: a bit, not so much though
<Daviey> dholbach, I don't know if the openjdk fix has landed in natty yet..
 * Daviey checks
<Daviey> dholbach, looks like it's still blocked in natty awaiting the openjdk fix (either dropping of two patches, or a proper fix from upstream)
<dholbach> Daviey, shall we get the bug out of the queue for now then?
<Daviey> dholbach, Hmm.. can do; i'd like to hear doko's thoughts on porting the fix to openjdk from maverick to natty for the interim to get things moving
<dholbach> hum, to me it looks like it's building alright in natty?
<Daviey> that would unblock and allow us to close those bugs.
<Daviey> dholbach, Interesting.... openjdk hasn't been touched since the 26th Nov... so it *should* fail.
<dholbach> http://paste.ubuntu.com/546240/
<dholbach> Daviey, ^
<Daviey> hmm
<Daviey> dholbach, lemme rebuild here
<dholbach> Daviey, that was with James' branch
 * Daviey regrets reinstalling natty... loosing his devel env.
<Daviey> losing*
<dholbach> Daviey, the old version still builds too
<dholbach> (but with the wrong paths, I guess)
<Daviey> dholbach, trying to re-digest https://bugs.launchpad.net/ubuntu/+source/eucalyptus-commons-ext/+bug/687971/comments/8
<ubottu> Ubuntu bug 687971 in eucalyptus-commons-ext (Ubuntu) "[FTBFS] package 'eucalyptus-commons-ext' (0.5.0-0ubuntu2) failed to build on natty" [High,In progress]
<dholbach> Daviey, to me it looks like geronimo-jacc-1.1-spec should be uploaded, so eucalyptus-commons-ext can build again, then something done with openjdk, so libhibernate3-java can build
<Daviey> That is my understanding. :)
<dholbach> Daviey, if that's the case, I'd upload the geronimo-jacc-1.1-spec change now
<dholbach> Daviey, go? :)
<Daviey> dholbach, It sounds sensible, and i'm not too concerned if it has fall out TBH... :)
<dholbach> haha
<dholbach> ok
<dholbach> I'm sure James will be in touch with me if it fails :)
<Daviey> dholbach, No. i really think it will be ok
<Daviey> and James probably won't be around until NEXT YEAR :)
<Daviey> so you have a year to run, and hide. :)
<dholbach> ha!
<Daviey> dholbach, Can you give me a ping when it's uploaded please? :)
<dholbach> Daviey,
<dholbach>  ____ ___ _   _  ____ _
<dholbach> |  _ \_ _| \ | |/ ___| |
<dholbach> | |_) | ||  \| | |  _| |
<dholbach> |  __/| || |\  | |_| |_|
<dholbach> |_|  |___|_| \_|\____(_)
<dholbach>                         
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<Daviey> dholbach, thanks! :)
<bdrung> dholbach: your ping was very small. it could easily overlooked. :P
<bdrung> dholbach: and thanks for getting the main queue down to 15
<dholbach> 15? I thought 19
<bdrung> dholbach: _main_
<dholbach> aha, yes :)
<dholbach> next step: get the 2000+ bugs with patches fixed :-P
<bdrung> dholbach: you were involved in edit-patch, weren't you?
<dholbach> bdrung, mvo was
<dholbach> I was part of the discussion when the idea was born - but that's as much credit as I'd be willing to take :)
<bdrung> dholbach: this tool needs some love and needs an non-interactive mode for making sponsor-patch a useful tool for the 2000+ bugs with patches
<dholbach> bdrung, I agree
<bdrung> dholbach: why are you listed as author in edit-patch?
 * bdrung tries to make you more responsible. :P
<dholbach> bdrung, I don't know
<dholbach> I started writing it in python and mvo took it from there and rewrote it in much better shell
<bdrung> dholbach: having it in python would be nice - then sponsor-patch could use it without running a command
<dholbach> the idea was to get it into devscripts at some stage
<bdrung> dholbach: ok, valid point
<dholbach> alrightie... I'll take the dog for a walk in the snow now - see you in a bit :)
<bdrung> but devscripts doesn't seem to be well maintained
<bdrung> dholbach: and i will build an iglu :)
<dholbach> ha, excellent :)
<dholbach> enjoy! :)
<ScottK> micahg: Thank you.  I'll take it if no one else has.
<Keybuk> Using distribution natty
<Keybuk> bzr: ERROR: Unknown target distribution: natty
<Keybuk> --
<Keybuk> argh!
<mvo> bdrung: yeah, I saw that there are a few open bugs on it, should be straightforward to add a non-interactive mode
<bdrung> mvo: it would be nice if you could add it.
<mvo> bdrung: ok, I have a look next
<cdbs> Keybuk: That is fixed in latest upload to maverick
<cdbs> s/maverick/natty
<cdbs> Keybuk: and I am waiting for someone to test an SRU upload. Its already in maverick-proposed
<Keybuk> cdbs: yeah, it's just annoying that it checks at all
<Keybuk> since it doesn't actually put it anywhere
<cdbs> Keybuk: I guess you are using bzr bd or something related to its plugins?
<Keybuk> yup
<Keybuk> bzr merge-upstream in this case
<Keybuk> hmm, and now pbuilder isn't co-operating
<ScottK> If it's not finding your pbuilderrc it's because sudo changed it's handling of the environment in Natty and it's looking in /root.
<cdbs> Keybuk: Would be awesome if you tested that SRU upload
<cdbs> g2g
<Keybuk> no, it seems to be not installing one of the Build-Dependeices
<Keybuk> so failing the build because the dep isn't satisfied
<cdbs> upload of package bzr-builddeb
<Keybuk> dpkg-checkbuilddeps: Unmet build dependencies: libselinux1-dev
<Keybuk> dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting.
<ScottK> That's on odd one then.
<Keybuk> yeah
<Keybuk> it looks like it's not parsing the libselinux1-dev [linux-any] properly
<ScottK> Ah.
<Keybuk> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363193
<Keybuk> jhunt: did we get a useful bash-completion file in the end?
<jhunt> Keybuk: yes - in your inbox now.
<Keybuk> who should be listed as the author?
<jhunt> Keybuk: me
<Keybuk> ok
<jhunt> Keybuk: thx.
<jhunt> Keybuk: it closes bug 672067.
<ubottu> Launchpad bug 672067 in upstart (Ubuntu) "There is no bash-completion for the commands in upstart" [Wishlist,In progress] https://launchpad.net/bugs/672067
<Keybuk> ok, committed and pushed
<Keybuk> you'll need to do some packaging changes - but we can do those on thursday together if london works out
<maco> Keybuk: s/works out/defrosts/ ?
<Keybuk> jhunt: if you wanted to have a go beforehand, you'd need to bzr merge -c 1258 lp:upstart to cherry pick the add, and then modify debian/upstart.install
<Keybuk> (man dh_install is the appropriate manpage)
<Keybuk> walters: howdy
<walters> hi Keybuk
<Keybuk> how goes it?
<walters> good!  just getting back from doing some volunteer math tutoring at the local high school, it's fun actually =)
<walters> how's sf treating you?
<Keybuk> SF isn't yet treating me
<Keybuk> I'm still in the USCIS queue
<walters> ah hah, i had to look that up
<maco> how many years is that expected to take?
<walters> though i should know it since my girlfriend just became an American 2 months ago =)
<Keybuk> I'm supposed to find out sometime between Dec 24 and Dec 28
<Keybuk> depending how you interpret their "days"
<Keybuk> and whether or not they miss the promised date and just do it later
<walters> our days are 24.1 feet
<james_w> dholbach, can you upload the package?
<maco> did they just give some number of days and then youre supposed to subtract out weekends and holidays?
<dholbach> james_w, I'm core-dev, so I'd expect so, yes
<james_w> dholbach, yeah
<james_w> dholbach, it's bug filing time I think
<dholbach> james_w, is it lp.net/launchpad already?
<james_w> yeah, I think so
<dholbach> alrightie
<Keybuk> maco: that's the depending on their intepretation bit ;-)
<dholbach> james_w, bug 692998
<ubottu> Launchpad bug 692998 in Launchpad itself "Can't set status of merge proposal to anything other than "merged", "WIP" and "needs review"" [Undecided,New] https://launchpad.net/bugs/692998
<james_w> thanks
<dholbach> de rien
<maco> Keybuk: remember, we dont have boxing day
<jhunt> Keybuk: thx!
<joaopinto> cjwatson, hi, regarding my installer crash yesterday, could you please look at http://pastebin.ubuntu.com/546280/ ?
<joaopinto> I will file a bug it if it's unknown or unlikely to be fixed on a newer daily
<Keybuk> kees: AYT?
<cjwatson> joaopinto: please file a bug with the full logs attached
<joaopinto> ok
<cjwatson> I don't debug from partial logs
<cjwatson> I assume you've already verified it on the current daily build
<joaopinto> shouldn't the installer crash handler allow me to open the report bug directly  and upload the required files ?
<cjwatson> (if that had been a full log I wouldn't have needed to ask)
<joaopinto> not yet, I will need to refresh the iso
<cjwatson> you should get an apport crash thingy if the installer crashes
<cjwatson> if you don't, use 'ubuntu-bug ubiquity'
<joaopinto> running ubuntu-bug ubiquity from my current installed system failed :P
<joaopinto> I assume it's expected to be run from a livecd session
<cjwatson> of course!
<joaopinto> I will do the manual link bug reporting and attach the logs, otherwise I would need to reinstall & fail again
<cjwatson> fine
<joaopinto> done, bug 693027
<ubottu> Launchpad bug 693027 in ubiquity (Ubuntu) "Failed to install using Ubuntu desktop 11.04 i386 daily image from 18th Dec" [Undecided,New] https://launchpad.net/bugs/693027
<joaopinto> which package should be used for the bug about the global menu not responding after the failure dialog ?
<joaopinto> about refreshing to a newer daily, can I just dd the usb partition into an iso, update it and just dump it into the usb partition ?
<cjwatson> I doubt it
<joaopinto> ok, so I will only be able to test it after retunring from holidays :(
<cjwatson> ev is looking at it now
<joaopinto> the booting ubuntu logo looks bad, that is something being worked right ?
<joaopinto> "bad" as in, the letters are not round, look "corrupted" on the edges
<cjwatson> known, I'll work on it in the new year if nobody's dealt with it before then
<pitti> cjwatson: unfortunately adding python2.7 to "minimal" didn't work :-/
<pitti> I rebuilt alternates, still there (http://cdimage.ubuntu.com/daily/20101221.1/natty-alternate-i386.list)
<cjwatson> alternates are a bad example
<cjwatson> you need to ask me for those :)
<cjwatson> how long ago did you add it?
<pitti> cjwatson: oh, I do? what changed?
<cjwatson> wait, maybe I'm misdiagnosing this
<pitti> cjwatson: ubuntu-meta published 3 hours ago
<cjwatson> it does have the right priority set
<pitti> cjwatson: and I rebuilt the alternates about a hour ago
<cjwatson> give me a minute to investigate, then.
<pitti> cjwatson: it's not that urgent, no need to drop your brain state
<cjwatson> too late
<pitti> argh, sorry about that
<doko> kenvandine: could you have a look at the libgda4 build failure? more gir transition stuff
<kenvandine> sure
<pitti> cjwatson, doko: OTOH it's just 16 packages to rebuild for getting everything to python2.7 | python2.6; I can do just that, ok for you?
<cjwatson> wait please, this might be a genuine germinate bug and I'd like the opportunity to diagnose it
<pitti> *nod*
<cjwatson> it should definitely be using python2.7 already in minimal rather than pulling another package into standard
<doko> only python2.7-minimal is in minimal, not python2.7
<cjwatson> no, python2.7 is in minimal now as a workaround by pitti
<cjwatson> that should have worked
<doko> ahh
<cjwatson> pitti: (still working on it, germinate slows down really dramatically under pdb :-/)
<cjwatson> pitti: the short-term solution is going to be to rebuild those packages anyway, though - I'm not going to be able to get a new germinate deployed on archive and cdimage before I finish for the year
<pitti> cjwatson: fine with me, I should be able to get this done today
<pitti> cjwatson: is there a way how you can reproduce this situation with all packages fixed?
<cjwatson> I can probably fake something up
<cjwatson> hopefully I can fix it before the archive changes though :)
<pitti> cjwatson: also, I'm only going to rebuild the packages which are on the CD for now
<pitti> there are a few more in main
<pitti> which we could then temporarily seed for testing
<cjwatson> I can always just keep this debug directory - due to another bug, it won't refresh its local copies of the Packages/Sources files
<cjwatson> so it should be fine
<pitti> ah, good
<cjwatson> ah, maybe it's not a germinate bug after all
<cjwatson> Package: python-apt
<cjwatson> Depends: python2.6 | python2.7, python (>= 2.6.5-11~), libapt-inst1.2, libapt-pkg4.10, libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.4.0), python-apt-common
<cjwatson> Recommends: lsb-release, iso-codes, python2.6
<pitti> argh
<cjwatson> why that Recommends?
<pitti> mvo: ^ could have been a temporary workaround for something?
<cjwatson> fix that and python2.6 drops off the alternate CD
<pitti> cool, will coordinate with mvo and do that
<pitti> thank you!
<mvo> pitti: uh, no idea, let me fix and upload
<mvo> thanks cjwatson
<cjwatson> according to germinate anyway
<pitti> mvo: ah, you want to? ok, great
<mvo> and bzr blame to figure out what is going on
<mvo> pitti: yes, thats fine, I will merge the latest debian stuff along the way
<pitti> mvo: danke
<pitti> it's the only reverse-recommends in main, anyway
<pitti> and in all other components, too
<doko> kees, mterry: MIR ping (689766 and 692955), just to resolve component mismatches
<mterry> doko, hiyo
<mterry> doko, I can take the first, libasyncns
<doko> mterry: the second too, please. I did submit these, can't review
<mterry> doko, OK
<lool> cjwatson: Hey, would you be able to ack and/or promote python-fixtures as per LP #692955?
<ubottu> Launchpad bug 692955 in python-fixtures (Ubuntu) "[MIR] python-fixtures, needed as a b-d for python-testtools" [Undecided,New] https://launchpad.net/bugs/692955
<lool> (I need a fix in a package which is dep-wait on python-fixtures)
<cjwatson> I can't ack it, I'm not in ubuntu-mir
<cjwatson> my understanding is that I only get to promote source packages that are either (a) trivially obvious (split-out, renamed, etc.) or (b) set to Fix Committed by an ubuntu-mir member
<mterry> lool, I'm about to look at that MIR
<lool> mterry: thanks
<lool> cjwatson, james_w: Yeah, I thought you guys were historical ~ubuntu-mir members
<tgardner> how does one find out _why_ a package has been rejected?
<cjwatson> lool: nope, never me
<cjwatson> tgardner: the archive admin who rejects iti is supposed to mail you
<cjwatson> *it
<cjwatson> if they didn't then they need a slap :)
<tgardner> cjwatson, huh. and how do I find out who rejected it?
<tgardner> the email says 'Rejected by archive administrator.'
<cjwatson> unfortunately there isn't an easy way.  https://bugs.launchpad.net/launchpad/+bug/31750
<ubottu> Ubuntu bug 31750 in Launchpad itself "rejects should allow (and require) reasons" [Low,Triaged]
<cjwatson> tgardner: what package name?
<tgardner> cjwatson, linux-meta_2.6.35.24.29
<tgardner> I lookedin both of the bugs mentioned in the changelog, but there were no comments
<cjwatson> irritatingly I can't find a record even on the archive master
<cjwatson> stable processing is usually pitti, but I see he's left IRC
<cjwatson> it may have been an accident
<tgardner> cjwatson, well, this isn't an ABI bumper so it can wait.
<cjwatson> I can resurrect it
<tgardner> cjwatson, that would be fine with me.
<doko> marjo: do you have any update on the upgrade failures?
<mvo> doko: it looks like its not python releated, it appears there is a problem with the intel driver on the i945 chipset
<mterry> lool, python-fixtures FTBFS due to test case issues.  If you're an interested party, maybe you can look at it?
<mvo> doko: I added code to the release-upgrader to autopatch pycomile now
<cjwatson> tgardner: resurrected and accepted.  if whoever it was didn't want me to reverse their decision then they should have mailed you a reason. :-)
<doko> mvo: \o/  is this release-upgrader in maverick-updates too?
<tgardner> cjwatson, :) thanks for your help
<mvo> doko: everybody upgrading will get it, regardless of -update or not (its the default upgrade app, its always fetched from the distro that you upgrade to)
<mvo> doko: diff -ed ftw ;)
<mvo> cjwatson: new python-apt uploaded, took a bit longer as I fixed another debfile releated bug along the way
<cjwatson> ta
<apw> marjo, sure
<marjo> apw: here
<apw> marjo, can we get the /var/log/Xorg.0.log file for the 'black boot' on the bug please
<marjo> fyi: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/693093
<ubottu> Ubuntu bug 693093 in linux (Ubuntu) "Blank screen with latest natty on intel atom GPU" [Undecided,New]
<marjo> apw: done
<doko> cdbs: about your liboauth upload. if your change is the only Ubuntu change, please don't make such changes. it increases the delta for no extra worth
<apw> marjo, and you are unable to switch to VT1 ?  or you can now?
<apw> marjo, can you login to the machine and do the following
<apw> DISPLAY=:0.0 xwd -root >OUT
<apw> and put the result somewhere i can look at it
<apw> marjo, also can you confirm whether the backlight is on (a dark place can herlp here)
<marjo> apw: still unable to switch to VT1
<apw> marjo, actualy you may need to login to do the xwd thing, so when you hear the drums i think you need to hit return, then password, and see if you get the login sound
<apw> then try it
<cdbs> doko: okay, it was actually recommended by the upstream author. Moreover, I am the debian maintainer of liboauth, so I can manage delta effectively
<cdbs> and I will drop the patch in Debian once gcc-4.5 becomes default there for wheezy
<marjo> apw: didn't work
<doko> cdbs: it is unlikely that debian will make --as-needed the default
<marjo> apw: any other way to try?
<cdbs> doko: hmm, will see then. will sync when I get the next upstream version uploaded
<marjo> apw: no login sound heard
<marjo> apw: backlight is on
<lool> doko: Is it intentional that the python2.7 testsuite got disabled in 2.7.1-1ubuntu1?
<doko> lool: yes, quick upload, no changes, will enable it again with the next upload
<netadmin> hello
<ari-tczew> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ari-tczew
<ari-tczew> cyphermox: have you got tested your patch for cnetworkmanager?
<cyphermox> ari-tczew, it was, though I didn't re-test it recently since uploading a new NM
<ari-tczew> cyphermox: could you do it again?
<cyphermox> of course
<ari-tczew> cool!
<cyphermox> sorry for harassing you about it, it's just pretty much the only way to use NM on the command-line, although I frankly don't touch it much
<ebroder> ari-tczew: Hey, I noticed you've had the pinot merge assigned to you for a while now. Are you still working on it?
<ari-tczew> ebroder: yes, I'll do it after sponsorship for cyphermox
<ari-tczew> ebroder: I'm doing cnetworkmanager 1st as cyphermox is waiting since 8th Dec :)
<ebroder> ari-tczew: Ok, just making sure you hadn't forgotten about it. I was going to look at it last night, but didn't want to yoink it from you
<ari-tczew> ebroder: I'm pretty sure that you won't be out of work for Ubuntu :)
<cyphermox> ari-tczew, still looks good to me.
<ScottK> ari-tczew: Did you see clementine is out of binary New in maverick-backports?
<ScottK> Should be all set now.
<ari-tczew> ScottK: I see that clementine is still New :>
<ScottK> ari-tczew: Sorry.  My mistake.
<ari-tczew> kk
 * ScottK was looking at a different package and didn't realize it.
<ari-tczew> cyphermox: what do you think about forwarding your patch to debian/upstream?
<cyphermox> yes, upstream
<cyphermox> I should send it again, actually
<ari-tczew> cyphermox: ok, uploading
 * ari-tczew loves review patches by Bazaar, but hates sponsorship it! (very hard)
<tumbleweed> ari-tczew: sponsor-patch :)
<Laney> bzr bd -S ?
<ari-tczew> tumbleweed: does it support Bazaar?
<tumbleweed> ari-tczew: yes
<ari-tczew> Laney: there are not only build source. now I have to set tags, set merge and 100 other commands...
<tumbleweed> ari-tczew: bzr mark-uploaded && bzr push :parent (or sponsor-patch :P)
<ari-tczew> tumbleweed: could you drive through sponsor-patch way?
<tumbleweed> ari-tczew: sponsor-patch -u $bugnumber
<tumbleweed> err -s
<bdrung> ari-tczew: you could read the man page of sponsor-patch. it explains it very good.
<ari-tczew> tumbleweed: okay, I have test built done, it's ready to upload. does sponsor-patch sets all tags and other data necessary for bzr sponsorship policy? (I'm just making sure)
<tumbleweed> yes it does
<bdrung> ari-tczew: you can run it with "-v" to see which commands are called
<tumbleweed> only issue I can think of is that you can't push back when uploading SRUs because there is no $release-proposed branch yet, but that's not really sponsor-patch's problem.
<ari-tczew> tumbleweed: I'm doing for natty.
<ari-tczew> which package includes 'bd' command?
<bdrung> ari-tczew: bzr-builddeb
<bdrung> ari-tczew: does sponsor-patch fail?
<tumbleweed> bdrung: that should probably go in reccomends
<ari-tczew> bdrung: yes
<bdrung> ari-tczew: show me the crash log
 * bdrung nods to tumbleweed.
<ari-tczew> bdrung: http://paste.ubuntu.com/546400/
<bdrung> tumbleweed: does this work: "login(self, service=service)"?
<tumbleweed> bdrung: that service comes from the default value in ubuntutools.lp
<ari-tczew> bdrung, tumbleweed: failed :/ http://paste.ubuntu.com/546403/
<bdrung> tumbleweed: shouldn't you mention which env variables are still supported, but deprecated
<bdrung> ari-tczew: i'll fix it. which u-d-t version do you use?
<tumbleweed> bdrung: ok
<ari-tczew> bdrung: Zainstalowana: 0.107
<ari-tczew> ups, I have to update :/
<tumbleweed> bdrung: there's also the option of warning about deprecated configuration
<bdrung> tumbleweed: ok, i prefer that.
<bdrung> tumbleweed: then we don't need to document them
<tumbleweed> oh, even better, yes :)
<ari-tczew> cyphermox: sorry for my late, I'm testing sponsor-patch on your case :)
<ari-tczew> but don't worry, it will be uploaded soon
<bdrung> ari-tczew: your bug is still in trunk
<ari-tczew> bdrung: could you qualify the time of fix? I have to know whether wait for fix or play with sponsorship another way.
<bdrung> ari-tczew: gimme 5 mins.
<ari-tczew> okay
<ari-tczew> mterry: you merged bluez with Debian! wow you're my lord!
<mterry> ari-tczew, :)  we hadn't done that in a long time
<ari-tczew> mterry: I tried to do this 3 times but always I failed :P
<mterry> ari-tczew, I only did half of it.  Rob Ancell started it, I just finished it.   Maybe that was the missing piece -- only do a small chunk.  :)
<ari-tczew> mterry: mhm. I'm working with Robert on some merges. Your sentence makes me sure that it will be a success :)
<bdrung> ari-tczew: pushed fix to trunk
<cyphermox> ari-tczew, ah, no worries, I'm fighting a unity bug ;)
<bdrung> ari-tczew: you can build it with "bzr bd"
<ari-tczew> s/a/an unity bug - english typo ;)
<ari-tczew> cyphermox: ^^
<cyphermox> indeed. thanks ;)
<ari-tczew> You're welcome.
<bdrung> tumbleweed: should i call ubu_email() in sponsor-patch?
<cjwatson> ari-tczew: actually, "a unity bug" is correct - it's the initial sound that matters, not the initial letter, and "unity" starts with a /y/ sound
<ari-tczew> cjwatson: in Poland teach to write 'an' before vowels :>
<bdrung> ari-tczew: "teach"?
<RAOF> It's not a *bad* herustic :)
<cjwatson> that's a reasonable rule of thumb but it fails in cases where the initial sound is consonantal anyway, like this
<ari-tczew> bdrung: teachers say to write...
<bdrung> RAOF: heuristic?
<RAOF> bdrung: Fancy rule of thumb!
<micahg> RAOF: I think he was referring to the fact that you said herustic
<bdrung> RAOF: my heuristic translates your "herustic" to "heuristic"
<RAOF> Ah.
<RAOF> :P
<RAOF> Spelling, as always, is for the week.
<tumbleweed> bdrung: I doubt it, unles s you use the uploader's email address to locate a gpg key
<bdrung> my brain to finger interface is broken too
<bdrung> tumbleweed: but syncpackage should do it, right?
<bdrung> "sponsor-patch 1" crashed. what does this tell us?
<ari-tczew> bdrung: how can I use sponsor-patch from trunk? can I copy files manually or rather branch locally and run ??
<tumbleweed> bdrung: same issue, you aren't editing a changelog.
<tumbleweed> ari-tczew: check out trunk; ./sponsor-patch
<bdrung> ari-tczew: or build the package with "bzr bd" and install it
<ari-tczew> bdrung: I don't understand, bzr bd on cnetworkmanager?
<kklimonda> ari-tczew: teachers don't really do that - your may, but it's not really fair to generalize like that.
<bdrung> ari-tczew: in trunk
<tumbleweed> bdrung: pushed up some deprecation stuff in config-681693 r913
<ari-tczew> bdrung: okay fixed, thanks
<ari-tczew> now I have a problem
<ari-tczew> where are the files?
<ari-tczew> I have to got .changes file to upload
<tumbleweed> ari-tczew: in /tmp/sponsor-patch-SOMEHTING
<bdrung> ari-tczew: what command did you call?
<ari-tczew> $ ~/bin/sponsor-patch 677589 -u -v -kari-tczew@ubuntu.com
<ari-tczew> bdrung: I branched u-d-t trunk and linked sponsor-patch into ~/bin
<bdrung> ari-tczew: -u requires an upload target
<ari-tczew> bdrung: hm?
<bdrung> ari-tczew: for sponsoring -s should be used (which is "-u ubuntu -b")
<ari-tczew> could you give an example?
<bdrung> ari-tczew: example in man page :)
<ari-tczew> bdrung: please, I'm not lying on the time...
<bdrung> ari-tczew: and i don't want to type everything twice
<bdrung> sponsor-patch 677589 -s -v -kari-tczew@ubuntu.com
<ari-tczew> tumbleweed: dpkg-source: ostrzeÅ¼enie: bÅÄd weryfikowania sygnatury w /tmp/sponsor-patch-PsgDvt/cnetworkmanager_0.21.1-1.1ubuntu1.dsc
<tumbleweed> ari-tczew: you may want to configure your gpg with a default key to save you lots of -k typing. bdrung: Maybe we should guess -k parameters from ubu_emial in many places.
<ari-tczew> tumbleweed: bash: cd: /tmp/sponsor-patch-PsgDvt: No such file or directory
 * micahg just made a bash alias for key sponsoring
<tumbleweed> it deletes it when it has finished running
<ari-tczew> tumbleweed: are you kidding me? how can I get these files if this script is deleting at the end?
<tumbleweed> ari-tczew: very recent change (a couple of revisions ago). You can tell it to work in a specific place, then it won't delete.
<bdrung> tumbleweed: good idea
<ebroder> ari-tczew: If you would just use -s like bdrung suggests, it will upload for you, but it will always ask you first
<bdrung> ari-tczew: in most cases you want to do an upload
<ari-tczew> tumbleweed: would be nice if sponsor-patch will create files in direcotry where I am ($ pwd)
<bdrung> ari-tczew: sponsor-patch -w .
<ebroder> Or set UBUNTUTOOLS_WORKDIR=. and it will always do that, right?
<tumbleweed> bdrung: only danger of it is that people who've rotated keys will have multiple keys with the same email address.
<bdrung> ebroder: yes
<tumbleweed> ari-tczew: that's what it did previously, now you have to tell it to do that.
<ari-tczew> tumbleweed: how can I set my gpg to use always my e-mail address?
<bdrung> tumbleweed: i found a grave bug: if you use -u and set it to something else than "ubuntu" it wont upload it.
<tumbleweed> ari-tczew: default-key in gpg.conf
<tumbleweed> bdrung: oh yeah I forgot about that
<bdrung> ari-tczew: i set DEBSIGN_KEYID is ~/.devscripts
<bdrung> s/is/in/
<bdrung> tumbleweed: that's why "sponsor-patch 677589 -u -v" didn't fail. it should fail with "can't upload to '-v'"
<tumbleweed> ari-tczew: thanks for your bugfinding :)
<ari-tczew> bdrung: can I specify e-mail address in DEBSIGN_KEYID?
<bdrung> ari-tczew: i specified the key id
<tumbleweed> I would assume so. gpg can generally take email addresses or ids
<bdrung> which should lead to the same result
<ari-tczew> bdrung, tumbleweed: if I'm stopping sponsor-patch by ctrl + c, then I'm getting an traceback. it should show only 'Aborted.' or something
<ari-tczew> http://paste.ubuntu.com/546413/
<tumbleweed> agreed (and that's an issue you'll see in many less-complex python scripts)
<ebroder> ari-tczew: I don't agree with that
<tumbleweed> ebroder: you want to know where it failed?
<bdrung> ebroder: why?
<ebroder> I see Ctrl-c as a more external failure than something like "dch failed". As soon as the program starts trying to be clever about those sorts of external failures, it becomes a lot harder to debug them when they occur
<ebroder> Like, a program returning non-0 is an "expected" failure in some ways
<ebroder> Whereas KeyboardInterrupt isn't
<tumbleweed> on a slow connection, sponsoring a big package, keyboardinterrupt isn't that unexpected (but you don't know where to catch it, so you need to wrap main in try..except.
<ebroder> I guess I might be OK with a KeyboardInterrupt handler, but I definitely don't want to see something like a try..except that catches all exceptions, or even all Exception subclasses
<tumbleweed> ebroder: yeah, with you on that. (And personally I'd rather see th traceback most of the time, but it's probably scary for some)
<bdrung> ebroder: would catching KeyboardInterrupt have any bad side effect?
<bdrung> tumbleweed: is it possible to print "User abort in $command."?
<ebroder> At the top-level? No, you'd just want to be sure to still exit non-0
<ebroder> You just do if __name__ == '__main__': try: main() except KeyboardInterrupt: sys.stderr.write('User aborted\n'); sys.exit(1)
<ebroder> Detecting where the abort happened is quite a bit more difficult
<tumbleweed> bdrung: yes you can dig into the traceback in the handler
<ebroder> Eww :)
<tumbleweed> yes
<ari-tczew> bdrung: your suggested command (sponsor-patch 677589 -s -v) wanted to build in pbuilder!
<tumbleweed> ari-tczew: that's the default test-builder
<ebroder> ari-tczew: Yes, read the manpage
<bdrung> ari-tczew: then specify a other builder
<ari-tczew> I don't want to build :
<ari-tczew> :/
<ebroder> Dude, all this stuff is well-documented in the manpage
<bdrung> ari-tczew: reading the man page would really help
 * ari-tczew hopes that will sponsor one patch today yet
<bdrung> ari-tczew: you sponsor without building it before?
<ari-tczew> bdrung: wrrrr... I wrote at the start, that I've reviewed and built this one!
<ari-tczew> let me scroll up to copy log
<ebroder> ari-tczew: So far you've asked us lots of workflow questions about sponsor-patch that are all documented in the manpage, and at this point you've taken more of our time for answering your questions than it would take you to read the manpage and figure out how to do what you're trying to do.
<ari-tczew> ebroder: I'm a person on who manpages doesn't work. (not technically, just I can't get manpages on my mind)
<ebroder> Did you try?
<bdrung> tumbleweed: "Deprecated configuration variable", but which variable should be used?
<ari-tczew> ebroder: when I'm reading a manpage, I got a feelling like wearing long johns
<bdrung> tumbleweed: "print >> stderr" - should we use Logger instead?
<tumbleweed> bdrung: yeah, that was my first impulse, but unless logger is configured (which is not ubuntutools.config's problem), its output isn't very pretty
<tumbleweed> I suppose it could gain some logger-configuring features
<tumbleweed> ari-tczew: seriously, you need to be able to read manpages. People get tired of helping people who don't help themselves.
<bdrung> tumbleweed: really? logger only needs the verbose mode set correctly, but this doesn't matter for warnings
<bdrung> tumbleweed: we should convert all python scripts to PEP8 (after merging your branch)
<tumbleweed> yeah
<tumbleweed> yes, setting a basicConfig should be enough. and it only applies the first time it's called, so scripts can still do what they want.
<ari-tczew> bdrung: look at http://paste.ubuntu.com/546416/
<ari-tczew> I know that I used option -w wrong but whether is it a bug?
<bdrung> ari-tczew: lemme investigate
<bdrung> ari-tczew: the error is that you set your working dir to: ='~/zainstalowane/paczki/ubuntu/cnetworkmanager'
<bdrung> ari-tczew: correct would be sponsor-patch 677589 -s -v -b -w '~/zainstalowane/paczki/ubuntu/cnetworkmanager'
<tumbleweed> bdrung: workdir might need to take package name substitutions
<bdrung> tumbleweed: package name substitutions?
<tumbleweed> ~/zainstalowane/paczki/ubuntu/cnetworkmanager -> ~/zainstalowane/paczki/ubuntu/%(source)s
<bdrung> tumbleweed: you can implement and document it if you want that feature
 * tumbleweed files a bug for now
<ari-tczew> bdrung, tumbleweed, ebroder: I've readed 'man sponsor-patch' and I still don't know how can I drop building.
<ari-tczew> It's like communist requirement.
<tumbleweed> don't specify -b?
<bdrung> ari-tczew: "-s" is equivalent to "-u ubuntu -b" and -b means building. so you can use "-u ubuntu" to upload, but not build it
<ari-tczew> bdrung: well, can't I buld *.changes file without building and without uploading?
<bdrung> ari-tczew: then drop any "-s" "-u" "-b"
<bdrung> just specify a workdir
<bdrung> tumbleweed: two things before merging: 1) what speaks against using Logging.warning instead of printf? 2) does the deprecation warning list all possible variables? "Use TEST_foo or UBUNTUTOOLS_foo instead."
<bdrung> tumbleweed: 3) i prefer "import sys" over "from sys import argv, stderr" to make it clear where the function come from
<tumbleweed> bdrung: 1. I'm busy doing something about logging 2. OK 3. Yes that was necessary for the test-suite hackery.
<ari-tczew> bdrung: will sponsor-patch do all things related to bzr without -s option?
<tumbleweed> ari-tczew: it only pushes back the branch if you've uploaded to Ubuntu.
<ari-tczew> tumbleweed: ok, now I;m going to upload *.changes file and it won't deal with sponsor-patch. what next with bzr branch?
<tumbleweed> ari-tczew: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/UploadingAPackage
<bdrung> ari-tczew: why don't you use "sponsor-patch -u ubuntu" if you upload the changes file anyway?
<ari-tczew> bdrung: I had to test set default key in gnupg.
<ari-tczew> tumbleweed: I just want to workaround these steps ;))
<ari-tczew> I guessed that it's available with sponsor-patch.
<bdrung> ari-tczew: you can see the commands in "sponsor_patch/main.py" ;)
<ari-tczew> bdrung: lines 473-488 includes what I mean!
<ari-tczew> bdrung: again failed... http://paste.ubuntu.com/546426/
<ari-tczew> I won't finish it today.
<kklimonda> then just do it by hand
<bdrung> ari-tczew: i am currently fixing that
<bdrung> ari-tczew: gimme 5 mins
<ari-tczew> how do you share script which is broken?
<bdrung> ari-tczew: it's not broken for my use cases. some code paths are not tested properly, because u-d-t lacks a test infrastructure
<ari-tczew> bdrung: wait wait... now gimme 5 minutes
<bdrung> ari-tczew: last test before push (i don't want you to complain again)
<ari-tczew> does anybody know how can I force my bzr to remember my password?
<bdrung> ari-tczew: pushed
<bdrung> ari-tczew: bzr ask you for a password?
<ari-tczew> bdrung: yes. always!
<bdrung> ari-tczew: i was newer asked. what is the exact message?
<ari-tczew> bdrung: Enter passphrase for key '/home/ari/.ssh/id_rsa':
<bdrung> ari-tczew: it's your ssh config
<ari-tczew> bdrung: It's started after switch to kde :/
<bdrung> ari-tczew: kde probably doesn't use gnome-keyring
 * ari-tczew is killed
#ubuntu-devel 2010-12-22
<ari-tczew> bdrung: Pushed up to revision 4.
<bdrung> ari-tczew: what did you push?
<ari-tczew> bdrung: me? nothing. that's sponsor-patch
<bdrung> ari-tczew: that comes from bzr
<ari-tczew> bdrung: did I contribute to u-d-t today?
<ari-tczew> yay! it works!
 * ari-tczew gives a beer for bdrung and tumbleweed
<ari-tczew> bdrung, tumbleweed: sponsor-patch created this branch: https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/cnetworkmanager/natty-201012220015
<bdrung> ari-tczew: please file a bug. bzr push needs to be more intelligent
<ari-tczew> bdrung: tomorrow. I have to go to bed. bye
<bdrung> ari-tczew: you contributed with two (or three) bug reports
<pasteeater> siretart: ping
<psusi> apw, I have been asking for 6 months now if you are still actively working on bug #380138 that has been assigned to you for 18 months now.  Are you actively working on it or should it no longer be assigned to you?  Upstream has made changes that should finally allow us to drop this problematic patch.
<ubottu> Launchpad bug 380138 in linux (Ubuntu) "Do NOT disable HPA by default -> leads to data loss" [Medium,In progress] https://launchpad.net/bugs/380138
<apw> psusi, no it has fallen off my radar
<apw> psusi, what upstream changes have been made
<psusi> apw, they have implemented a patch that detects whether any partitions would be truncated by the hpa and automatically unlocks the hpa if that is the case, otherwise, does not
<apw> psusi, that sounds like it matches what we wanted indeed
<apw> psusi, if you can point me to the change i can use that info
<psusi> commit d8d9129ea28e2
<psusi> looks like it actually went in 2.6.35
<apw> psusi, indeed 35-rc2
<psusi> yep, it's in the maverick git tree
<psusi> man I love git
<apw> psusi, thanks for the heads up, sounds like we can drop this patch in natty and see how that pans out
<psusi> woohoo, only took a few years ;)
<psusi> now if we can just get the ext4 lazy_itable_init issue sorted in time for natty, 20 minute formats with the installer stuck at 5% will be a thing of the past
<psusi> I hope ted packages the new e2fsprogs for debian soon so we can merge it
<apw> psusi, we are expecting new e2fsprogs in debian shortly
<apw> psusi, ok i am now 'active' on that bug ... will get something sorted out tommorrow ... need to get discussion started on it to ensure foundations are happy -- they were not last time we tried to change it
<psusi> goody... I've been trying to get that feature turned on by default for a year... will be a boon to people with new tb class drives
<apw> psusi, why are tb drives relevant ?
<psusi> because they take AGES to format without lazy_itable_init ;)
<psusi> and ubiquity just sits there at 5% complete and does not move the whole time.. very bad user experience
<apw> ahh
<psusi> we also probably want to have ubiquity mount with the option to inhibit the background initialization during installation so it doesn't slow down the install
<apw> psusi, thanks for bringing that up
 * apw goes back to bed
<psusi> o/
<ari-tczew> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<siretart> pasteeater: hi
<pitti> cjwatson: python2.6 still is on today's alternate, despite python-apt being fixed; you mentioned that we need to "ask you for alternates", do you manually need to update something there?
<pitti> cjwatson: I guess I'll do the 16 rebuilds then, and check if that helps
<cjwatson> pitti: I was wrong about having to do something manually - that's only when things are dropped from priority required or important
<cjwatson> pitti: python-apt still has the recommends in question, despite a changelog entry saying that it's been dropped
<cjwatson> pitti: the rebuilds really should be unimportant for this - just fix python-apt properly :)
<cjwatson> (well, they'd let you drop python2.7 from minimal again, yes)
<mvo> cjwatson: eh, sounds like I need vacation
<mvo> cjwatson: :(
<mvo> cjwatson: I have a upload ready to fix a unreleated crash I will drop the recommends in that upload too (for real this time)
<mvo> uploaded again
<cjwatson> ta
<pitti> ah, bummer
<pitti> mvo: danke
<pitti> mvo: control.in trap?
<pitti> bbl
<apw> mvo, is there a 'debrelease' command like debcommit for bzr based packages ?
<mvo> apw: bzr-buildpackage
<apw> mvo, our naming sucks!
<apw> (but thanks)
<mvo> apw: that is what I use, a lot of package have a .bzr-builddeb/defaults.conf that tell bzr-buildpackage what to do, if not you need to tell it to either "--merge" or "--native"
<mvo> apw: otherwise it will not find its data :)
<apw> mvo, oh that builds it, i meant is there a command to close the release, RELEASED -> natty, update the name and date on the -- line, commit result, tag result
<mvo> apw: I use emacs for that, but others use dch
<mvo> so dch -r
<apw> mvo, ok so manual commit then ... thanks
<mvo> apw: there is debcommit -r that will tag the branch, but iirc it does not change UNRELEASED to $distro
<ari-tczew> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ari-tczew
<ari-tczew> could any archive admin look on tor sync? bug 413657
<ubottu> Launchpad bug 413657 in tor (Ubuntu) "Please sync tor 0.2.1.26-4 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/413657
<ari-tczew> cdbs: you should know that there is a difference between FTBFS with missing linking and gcc 4.5
<ari-tczew> rawstudio/1.2-5ubuntu1 which you uploaded means fix ftbfs with missed links
<cdbs> ari-tczew: If you read it clearly, I mentioned: Fixes FTBFS caused due to the new linking behavior in Ubuntu's GCC 4.5
<ari-tczew> cdbs: but it's not related to gcc 4.5
<cdbs> ari-tczew: it is
<ari-tczew> cdbs: for example, it's ftbfs due to gcc 4.5: http://launchpadlibrarian.net/60956184/buildlog_ubuntu-natty-i386.u-boot_2010.12~rc2-1ubuntu1_FAILEDTOBUILD.txt.gz
<cdbs> I know what you mean
<cdbs> But the linker change is related to GCC 4.5
<ari-tczew> odd
<cdbs> and I mentioned: FTBFS caused due to the *new* *linking* *behavior* in GCC 4.5 in Ubuntu
<ari-tczew> cdbs: I guess that you mean due to new toolchain?
<cdbs> of course
<ari-tczew> cdbs: so this is not only gcc 4.5
<cdbs> new linking behavior -> passing of --no-copy-dt-whatever
<ari-tczew> if I'm wrong, show me hard argumentation
<cjwatson> it seems entirely unnecessary to nitpick this
<cdbs> ari-tczew: Please understand the change before saying. GCC invokes LD
<cdbs> and GCC is invoking LD with --no-copy-dt-entries
<cdbs> err, its --no-copy-dt-needed-entries
<cdbs> so its related to GCC
<cjwatson> gcc-4.5 (4.5.0-1) experimental; urgency=low
<cjwatson>   * On linux targets always pass --no-add-needed to the linker.
<cjwatson> (which is a synonym for --no-copy-dt-needed-entries)
<cdbs> and --no-copy-dt-needed-entries is the same as --no-add-needed
<cdbs> ari-tczew: I guess I am clear
<cdbs> thanks cjwatson for that paste
<ari-tczew> cdbs: ok it's also clear for me
<Keybuk> cjwatson: sorry I'm late, it was hell getting into work this morning because of the snow
<kklimonda> ArneGoetje: wrt to tor - did debian maintainer agreed to take care of it in ubuntu, eventually did we get some motu to get his key into tor project? i can't check the bug but tor has been removed from ubuntu in the past.
<Keybuk> 535		event = event_new (NULL, name, (char **)env);
<Keybuk> (gdb) p name
<Keybuk> $1 = 0x671530 "dbus-activation"
<Keybuk> (gdb) p env[0]
<Keybuk> $2 = 0x6789e0 "SERVICE=my.test"
<Keybuk> \o/
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ari-tczew, mterry
 * dholbach hugs mterry!
<mterry> dholbach, :)
<Keybuk> ok, silly question time
<Keybuk> if there's a debian package using 3.0 quilt
<Keybuk> how do I add patches to it?
<elmo> Keybuk: quilt new haha.patch ?
<Keybuk> elmo: does haha.patch have to be in the working directory or under debian/patches ?
<dholbach> edit-patch?
<Laney> is that an existing patch?
<Keybuk> Laney: they're existing patches, yes
<elmo> Keybuk: oh, sorry, right, this mess
<Laney> quilt import is what you want then
<elmo> Keybuk: you may want to 'export QUILT_PATCHES=debian/patches'
<Laney> edit-patch can do this too apparently
<elmo> Keybuk: I used http://pkg-perl.alioth.debian.org/howto/quilt.html as a starting point when I was going through the same 'wtf' a while ago, FWIW
<Keybuk> File series fully applied, ends at patch debian-changes-1.4.0-0ubuntu2
<Keybuk> Patch debian-changes-1.4.0-0ubuntu2 does not remove cleanly (refresh it or enforce with -f)
<Keybuk> argh
<Keybuk> what does that mean?!
<Keybuk> Laney: so, neither of them did the right thing
<Keybuk> quilt import didn't apply the patch to the working tree
<Keybuk> edit-patch reverted all the debian patches in the working tree
<Keybuk> I swear
<Keybuk> quilt was invented because some people had got use to the pain of cdbs
<Keybuk> and wanted more
<ScottK> Keybuk: And like CDBS, eventually you'll get used to it.
<ScottK> Eventually you'll criticize people for not enjoying the pain.
<ScottK> ;-)
<Keybuk> I suspect it's the combination of pain here
<Keybuk> the package is actually using CDBS
<Keybuk> and quilt
<Keybuk> and all imported into bzr using james_w's abandoned stuff
<mvo> bdrung: I commited a non-interactive add-patch version of edit-patch, would be nice if you could have a look
<janimo> Keybuk: I think that combo is not supported by edit-patch (I fought with thunderbird packaging until I learned that)
<bdrung> mvo: i will. thanks in advance
<janimo> or actually cdbs tarball.mk + quilt is what caused problems
<Keybuk> janimo: this looks like it's relying on dpkg to do the quilting
<ScottK> cdbs tarball.mk plus anything is trouble (tarball in tarball using source format 1 is pure pain)
<janimo> ScottK: luckily mozilla team say they want to move to quilt 3.0 so that will go away
<mvo> bdrung: its only lightly tested and such, feedback welcome
<ScottK> janimo: How are they going to support Hardy?
<janimo> ScottK: I am not part of the mozilla team, so no idea :)
<bdrung> mvo: you are welcome to provide testcases (online/offline). we are currently building a test infrastructure to catch regressions
<janimo> Keybuk: I only had a problem with tbird packaging, and remembered I dislike quilt. But on every other package since then edit-patch did the right thing regardless of what the actual patch system
<janimo> both quilt 3 and quilt cdbs worked fine
<Keybuk> in this case, edit-patch seemed to remove all the patches from the tree
<Keybuk> and tried to commit that
<Keybuk> when dpkg-source 3 (quilt) in bzr is supposed to have all the patches *applied* at commit time
<mvo> bdrung: indeed, that is currently missing
 * janimo so far managed to not get into VCS backed patches (or if so edit-patch DTRT)
<janimo> Laney: I am trying to build ghc6 locally, and will let you know if I find the issue
<bdrung> mvo: add-patch is still interactive
<bdrung> mvo: it launches an editor and let's me edit debian/changelog
<bdrung> mvo: edit-patch should take bug number to close and should be able to set the target distribution
<mvo> bdrung: hm, but it certainly needs some sort of description somewhere for the changelog. or are you happy with a generic "applied patch foo"?
<bdrung> mvo: generic would be enough
<ScottK> If I saw such a changelog entry in the sponsorship queue I would reject it.
<bdrung> ScottK: sponsor-patch allows to edit it afterwards.
<ScottK> OK.  Seems odd to me.
<ScottK> I've used cdbs-edit-patch and dpatch-edit-patch a lot and never once wanted them to write changelogs for me.
<bdrung> one use case would be to grab patches from the reviewers list and test build them or upload to a ppa.
<ScottK> Is this non-interactive mode a non-default option then?
<cdbs> master?
<bdrung> ScottK: should be
<cdbs> BTW, I never understood what edit-patch does (I mean the script in u-d-t). Why use it when you can use cdbs-edit-patch and dpatch-edit-patch?
<cdbs> sorry for writing that 'master'. Don't know how it came
<ScottK> cdbs: What if the pacakge uses quilt?
<ScottK> IIRC the point of edit-patch is not having to care what patch system is in use.
<cdbs> ScottK: is edit-patch for quilt?
<cdbs> okay
 * ScottK would hope it includes support for it.
<bdrung> cdbs: edit-patch supports all patch systems
<cdbs> I guess it writes changelog and stuff? and it has bzr support?
<apw> doko_, you suggest conditionalising packaging on the release, is there an approved way to do that?
<ScottK> wendar: I'm catching up on the backscroll and have a comment on your last ARB meeting: I would really prefer you don't choose to use ubuntu in the revision number for ARB apps.
<doko_> apw: well, I don't know. usually you have to rely on output of lsb_release, and have a rule to regenerate the control file (for the change of b-d's)
<apw> doko_, ick, ok thanks
<wendar> ScottK: well, the apps are packaged for ubuntu, which is all that line means
<ScottK> wendar: Except that extras is not part of Ubuntu.
<wendar> ScottK: they'll still say "maverick" on that line too
<wendar> ScottK: extras run on Ubuntu
<ScottK> Why not just use $RELEASE.
<wendar> ScottK: one of the developers did, but it's entirely non-standard
<wendar> ScottK: we can certainly change the standard, but it needs to be a decision by a much larger group than the ARB
<ScottK> wendar: There's a standard?
<wendar> ScottK: so we'll stick with the current standard for now
 * ScottK thought the current situtation was no defined standard?
<ScottK> wendar: Where is this standard?
<wendar> ScottK: in the ubuntu packaging guide
<ScottK> wendar: That's the standard for Ubuntu packages.  These aren't Ubuntu packages.
<ScottK> (and technically the standard is ubuntu-policy - the packaging guide just describes the policy)
<wendar> ScottK: to be precise, they aren't "packages that make the core OS" they're "packages that run on the core OS"
<wendar> ScottK: but they aren't Debian/Fedora/SuSE packages
<ScottK> They equally aren't Ubuntu packages.
<wendar> ScottK: we have main, universe, multiverse, and now extras, that has so far been taken as enough of a measure of how much support the Ubuntu community gives a package
<wendar> ScottK: why add an additional linguistic marker?
<directhex> precision is important
<wendar> ScottK: the 0ubuntu1 means "this package was customized to run on the Ubuntu OS"
<ScottK> wendar: Why make a choice the adds confusion?
<ScottK> No.  It means it's part of Ubuntu.
<ScottK> You are proposing to change what that means.
<wendar> ScottK: we have packages with out 0ubuntu1 that are part of Ubuntu
<ScottK> That's true, but irrelevant.
<ScottK> The fact that all XubuntuY packages are part of Ubuntu doesn't mean that all packages that are part of Ubuntu are XubuntuY
<wendar> ScottK: I'm a linguist, and it's very important to me to get at the deep semantic and cultural meaning of a symbol or word
<apw> marjo, remind me of the bug number
<Chipzz> wendar: pretty ironic a linguist spells without in 2 words ;)
<marjo> apw: https://bugs.launchpad.net/bugs/693093
<ubottu> Ubuntu bug 693093 in linux (Ubuntu) "[i945gme] 2.6.37-10.24: Black Screen on Boot" [Undecided,Confirmed]
<wendar> Chipzz: I'm a linguist on a mission, and spending most of these few minutes scanning through documentation for signs of deeper semantic and cultural meaning of 0ubuntu1
<wendar> Chipzz: :)
<apw> marjo, well that doesn't make sense as installing -10 doesn't change the older kernels and you are saying they have changed too
<apw> marjo, that would imply it is a different component which has changed which is contributing
<Chipzz> what deeper meaning do you expect? it's a version number, it has no semantic meaning
<Chipzz> a version number purely exists to order packages in a timely fashion
<Chipzz> ie to allow upgrades to happen correctly
<marjo> apw: i tend to agree, but I don't know what else to try; all i know is that -9 used to work fine (gets to login and supported high resolution)
<apw> marjo, and the fact that booting -9 does not implies it is something other than the kernel which is spacked
<wendar> ScottK: can't find the page I'm looking for on why that naming convention was originally introduced (it might not exist anymore). I have a strong opinion to hold to existing standards until there's a compelling reason to change, but essentially, the ARB will do whatever the TB decides on it.
<ScottK> wendar: I disagree that there is an existing standard for this.
<apw> marjo, you may as well try updating to the -11 kernel and re-testing
<Chipzz> wendar: to put it bluntly, your mission is bullshit. even if the proposal would have merit (which it doesn't (IMO)), the version number matters because computers order strings in a specific way, and 0ubuntu1 comes after 0, which is important because ubuntu packages should override debian packages
<marjo> apw: will do
<Chipzz> wendar: I think that alone is enough argument to put an end to this discussion
<wendar> wendar: okay, then rephrase that to just "I have a strong opinion", but I do think this is something to be decided by the TB, and not by a small new group
<wendar> (hmmm... talking to myself now?)
<ScottK> wendar: I'm fine with the TB deciding.  I think the current correct behavior is undefined.
<Chipzz> wendar: there IS nothing to decide. your proposal would break ubuntu, period
<ScottK> Chipzz: No.  It wouldn't.
<wendar> ScottK: we're deciding on a new standard that has the potential to last for 20 years or so
<Chipzz> ScottK: as I understand it he wants to do away with ubuntu version numbers
<ScottK> Chipzz: No.  She doesn't.
<wendar> Chipzz: it wouldn't break anything, I just want to use exactly what we're using now
<ScottK> wendar: There is no "What we're using now".  extras is new.
<Chipzz> ScottK: then I misunderstood the discussion, my apologies
<apw> marjo, we need you in #ubuntu-x
<wendar> Chipzz: I want to use 2.0-0ubuntu1 and ScottK wants to use something else, maybe 2.0-0extras1
<ScottK> Chipzz: I don't think I'm the one you need to apologize to.
<wendar> Chipzz: (we need to figure out what the something else would be, which is one of the reasons to take it to the TB)
<ScottK> wendar: I'd even be happy with -0$RELEASE1 since these approvals are tied to a specific release.
<Chipzz> wendar: ah ok, I understood the discussion as you wanting to eliminate 0ubuntu1 because it made no semantical sense
<wendar> Chipzz: then your frustration is understandable :) I actually think it makes perfect sense, and want to keep using it.
<ebroder> ScottK, wendar: Why not something like -0ubuntu0extras1?
<wendar> ebroder: that has good potential
<wendar> ebroder: or -0ubuntu0~extras1 like with PPAs
<Chipzz> looks too complex to me
<ebroder> That indicates to me that we would prefer to get these packages into the archive, at which point they'd supercede the packages in extras, which all seems more or less desirable
<ebroder> wendar: I would probably use -0ubuntu1~extras1 if you went the tilde route
<Chipzz> wendar: ~ has a specific meaning in versions, though I'm not sure if it's only at the start of a version or also anywhere else
<ScottK> ebroder: It should not contain the string "ubuntu".
<bdrung> ebroder: -0ubuntu0extras1 is more consistent
<wendar> ebroder: and, it solves a problem too, if we treat it the same as PPAs, because it means the first universe release after the 'extras' release would always be considered "more recent" than the extras release
<ScottK> Chipzz: It's anywhere.
<wendar> ScottK: that basically comes down to what that instance of "ubuntu" means, a noun in isolation is tremendously ambiguious
<apw> marjo, hey ... lots of dicsussion on #ubuntu-x
<marjo> apw: having xchat problems
 * apw wonders how you get to #ubuntu-meeting
<marjo> apw: auto-connect
<apw> add ubuntu-x to that, and restart it perhaps?
<marjo> apw: there now
<marjo> apw: as marjo_
<Chipzz> ebroder: my 2c (FWIW), things like -0ubuntu0extras1 look too complex to me, and would likely cause confusion
<bdrung> -0extras1 would be enough (less that -1 and -0ubuntu1)
<ScottK> wendar: That's true and the core of my objection.  I don't think it's possible to succesfully encode the distinction between in Ubuntu and on Ubuntu into the revision number, so I'd like for Ubuntu to be avoided entirely.
<bdrung> s/that/than/
<Chipzz> sth you may want to avoid for MOTU's for example, as those ppl are often beginners, and they may struggle enough as is
<wendar> Chipzz: that's good feedback
<wendar> ScottK: I'll bundle the discussion up in an email for the TB. Doesn't necessarily need a meeting agenda item or a vote, but at least their thoughts.
<Chipzz> wendar: sounds to me like you want input from the debian ppl too
<ScottK> OK.
<ebroder> wendar: Am I assuming correctly that it's desirable in the long-term for apps to move from extras into the archive?
<Chipzz> sth which may be better is 0ubuntuextra1 (or 0ubuntu-extra1)
<Chipzz> 0ubuntuextra1 would still be higher than 0ubuntu1
<Chipzz> but only 2 numbers instead of 3
<ebroder> Chipzz: I'm suggesting -0ubuntu0extras1 because I see it as being analogous to numbering packages -0ubuntu1 that are in Ubuntu but not yet in Debian
<Chipzz> ebroder: yes, but then you have 3 numbers in one version string...
<bdrung> dholbach: why does ubuntu-dev-tools depends on binutils?
<dholbach> bdrung, I have no idea
<dholbach> bdrung, ahhh - because of "nm"?
<bdrung> dholbach: where is it used?
<dholbach> check-symbols
<ebroder> Chipzz: Sure, but it's not like you don't run into the same sorts of issues for SRUs, backports, etc.
<Chipzz> ebroder: yes, but those happen only on an occasional basis, not on a regular one
<Chipzz> ebroder: and I think ppl find those to be too complex in SRU's too
<bdrung> dholbach: thanks
<ebroder> Chipzz: I don't think that makes them any less useful as indicators of the package's lineage
<apw> jhunt, what was the incantation to upstart to get more debug, was it --debug ?
<Keybuk> apw: --debug --debug --moar-debug
<Keybuk> (note, only the first one required)
<apw> jhunt, what does "init: event_net: Pending started event" mean
<apw> as the last bit of --debug
<Keybuk> event_new you mean
<apw> yes _new
<apw> sorry going a bit mad
<Keybuk> means that a job has started
<Keybuk> though helpfully it doesn't say which, you need to look a line or two up for that
<apw> Keybuk, so its not in the middle, its complete
<Keybuk> right, that means the process has been exec'd and suff
<apw> something very screwey goiing on in my worls
<apw> world
<janimo> cjwatson: hello, can you please add me (jani @ ubuntu.com ) to the list of addresses notified when anything significant happens to arm image builds. thanks.
<Keybuk> there are such addresses?
<janimo> Keybuk: so I was told in #arm
<ScottK> You can get ISO build failure notifications.
<janimo> it may not be a mailing list, but apparently ogra & other arm devs are notified
<Keybuk> neat
<kees> Keybuk, jhunt: so, should I upload the ubuntu1 debdiff for upstart to gain the apparmor helper, or should I wait for it to be included in the next release? (when is the next release?)
<zyga> Keybuk, hi, dbus activation support is quite cool
<Keybuk> kees: if you upload a debdiff it should be -2
<zyga> Keybuk, I posted a comment about the implementation but darn moderation will probably make it past xmas to deliver
<kees> Keybuk: what's needed to get the change into the right vcs tree?
<zyga> Keybuk, could you by any chance reuse the Exec= from .service file not to have to specify the same thing twice?
<Keybuk> kees: uploading should do it
<apw> Keybuk, any idea what was in the latest udev upload ?
<Keybuk> zyga: I thought about adding it to the environment, but decided it would probably limit things
<Keybuk> apw: none, pitti does those
<zyga> Keybuk, not adding that to environment, just not having to specify it in a job file
<ebroder> Keybuk: Do you still need to specify Exec and User in the .service file? Does D-Bus barf without those?
<vanhoof> apw: some changes for new dell chassis support
<Keybuk> zyga: then upstart would have to parse dbus service files, and then there's the whole mess of them being out-of-sync with each other, etc.
<Keybuk> ebroder: no idea
<zyga> Keybuk, yeah but you trade _development_ problem for _administration_ problem. They are going to get out of sync because you require two definitions. I argue to make just one definition in the .service file
<Keybuk> zyga: if you want to support that though, go ahead
<Keybuk> because it shouldn't be that hard to add an additional config parser to upstart
<Keybuk> you could have upstart parse /usr/share/dbus-1/system-services, make Jobs out of them, etc.
<Keybuk> I'll happily accept that patch
<Keybuk>     ^
<Keybuk> more then
<zyga> Keybuk, do you have a separate non-copyright-assigned tree now or is that to the canonical treE?
<Keybuk> zyga: I work for Canonical, so there is only the Canonical tree
<zyga> Keybuk, that's another topic, so what's the point of having upstart file if we can (eventually) parse dbus service files?
<Keybuk> zyga: well, there are lots of services that aren't dbus ;-)
<zyga> Keybuk, is the upstartjob=y marker used by dbus _not_  to start that on activation and expect upstart to pick it up?
<Keybuk> and in theory, dbus-daemon goes away
<Keybuk> so the dbus service files will be the short-lived ones
<zyga> Keybuk, mmm, interesting, what about handling of routed messages?
<Keybuk> zyga: no, UpstartJob=y is used by D-Bus to replace the existing activation code with a D-Bus message to Upstart
<Keybuk> zyga: multicast AF_UNIX
<zyga> Keybuk, right, that's what I had on my mind, "delegate task to upstart"
<zyga> Keybuk, so if we had the parser for .service files could we assume upstartjob=y always?
<ebroder> zyga: There was a proof-of-concept a while back for an AF_DBUS :)
<Keybuk> if the AF_UNIX multicast stuff gets accepted, then I'd expect to see
<kees> Keybuk: FAIL: test_job_process
<zyga> ebroder, yeah
<kees> ^^ that test fails
<Keybuk>  - dbus services bind to AF_UNIX with their well known name
<zyga> ebroder, but it did not remove the daemon
<Keybuk>  - dbus services listen on the multicast socket too
<zyga> ebroder, it just made the actual talk more efficient
<cjwatson> janimo: mail me, please, I'm not sitting somewhere where I can make that change right now
<Keybuk> for activated services
<Keybuk>  - init binds to AF_UNIX with the well known name
<Keybuk>  - on message, activates the service and passes the socket
<Keybuk> (ie. basically socket activation)
<Keybuk> in both cases, you'd only have files in /etc/init
<ebroder> zyga: I thought the proof-of-concept only used the dbus-daemon for the org.freedesktop.DBus stuff
<zyga> ebroder, and for activation and for non-peer-to-peer messages
<zyga> (I could be wrong on the last one)
<Keybuk> kees: -v
<ebroder> zyga: Oh, really? Well that's pointless :-P
<Keybuk> ebroder: the new stuff is multicast AF_UNIX
<cjwatson> wendar: here's the semantic of "ubuntu" in version numbers: it means "do not autosync this package from Debian"
<cjwatson> wendar: that's its total meaning
<zyga> Keybuk, that makes sense except for one thing - transition period - dbus has been around long enough so we have lots of .service files for dbus activation, do you think we should require to transition them to upstart jobs?
<kees> Keybuk: I can't build upstart on natty, I get a failed testcase:
<kees> test_job_process: tests/test_job_process.c:3740: test_handler: Assertion `(waitid (P_PID, pid, &info, 2 | 0x01000000)) == 0' failed.
<kees> /bin/bash: line 5: 11151 Aborted                 (core dumped) ${dir}$tst
<kees> FAIL: test_job_process
<Keybuk> zyga: right, that's what I thought -- it seemed most sensible to do it as a transition thing
<Keybuk> and to cover the overlap for when older kernels need dbus-daemon
<Keybuk> while newer kernels don't
<Keybuk> which is why I did it entirely as "have special handling in dbus-daemon"
<Keybuk> rather than having any patch to upstart
<zyga> ebroder, AF_DBUS patch did improve performance and removed the bottleneck that is the daemon for normal communication, I never used it just remember reading about it
<Keybuk> kees: you're still not telling me which test case failed here ;-)
<wendar> cjwatson: Makes sense. Seems like that would apply to the extras packages as much as any other.
<zyga> Keybuk, I think it's still more sensible to keep .service files as is and let upstream be happy about not having to worry about upstart, upstart+1, sysinit or other stuff like systemd,
<cjwatson> wendar: extras is never autosynced
<zyga> Keybuk, it adds extra cruft but IMHO it's the best political decision
<wendar> cjwatson: Though, with the /opt install, we'll always be modifying the packages.
<Keybuk> zyga: I would have agreed, except Upstream already committed patches to add systemd support
<cjwatson> autosyncing is just for the Ubuntu archive
<Keybuk> so I followed the guide of those patches
<zyga> Keybuk, we swap the implementation, not the interface for activation
<kees> Keybuk: oh, "test_job_process" isn't it?
<kees> Testing job_process_handler()
<kees> ...
<kees> ...with stopped main process but wrong signal
<Keybuk> kees: no, test_job_process is about 1,000 test cases ;-)
<zyga> Keybuk, upstream dbus?
<wendar> cjwatson: Would you be comfortable with no modifier?
<Keybuk> zyga: aye
<Keybuk> kees: hmm, ok - can you check the core dump to see what assertion failed
<wendar> cjwatson: i.e. 2.0-1?
<zyga> Keybuk, I was referring to upstream projects shipping .service files, dbus is another topic where I agree with you
<cjwatson> wendar: sure, it certainly wouldn't break anything and it seems simpler
<Keybuk> kees: you may have found a kernel bug
<Keybuk> zyga: well, the reason for doing this patch now
<Keybuk> (we've never found it urgent until now)
<cjwatson> we do that for some Ubuntu-specific packages, even
<Keybuk> was to cover the base of upstream projects adding systemd support
<Keybuk> and expecting you to activate it that way
<kees> Keybuk: this assertion:
<kees> test_job_process: tests/test_job_process.c:3740: test_handler: Assertion `(waitid (P_PID, pid, &info, 2 | 0x01000000)) == 0' failed.
<Keybuk> this gives us an upstart answer
<wendar> cjwatson: okay, cool, thanks
<Keybuk> kees: yeah, looking at the code, you found a kernel bug
<zyga> Keybuk, right, that's a sensible first step
<apw> something seems to be wrong with something in our initramfs in natty
<kees> Keybuk: \o/
<zyga> Keybuk, I'm more probing you on the follow-up you'd like to see
<apw> i have a bad -11 kernel, i regenerated my -10 initramfs and it is also sick now
<Keybuk> kees: because that assertion is asserting that a child paused by SIGTSTP causes wait() to report WSTOPPED
<Keybuk> zyga: I don't expect to see a mass conversion of system services from dbus to upstart
<Keybuk> in fact, I don't really expect to see any
<wendar> cjwatson: will drop a note to the TB for "chance to comment", but will go with the simple option unless anything else come up
<zyga> Keybuk, I was asking about the next step for upstart implementation
<Keybuk> but next time someone says "we have to use systemd because d-bus uses it for service activation" the answer is "no, upstart can do d-bus service activation too"
<zyga> Keybuk, if we can make all dbus services activated by upstart implicitly
<Keybuk> zyga: i'm not sure that needs an upstart patch
<zyga> hmm
<Keybuk> one could patch d-bus so that rather than read in .service files, it just unconditionally emits the dbus-activation event
<zyga> btw
<Keybuk> I considered that
<zyga> why didn't you just patch dbus
<Keybuk> I did just patch dbus
<zyga> Keybuk, to actually send you job details upon activation
<zyga> Keybuk, no parsin needed,
<Keybuk> zyga: that's what I said earlier
<zyga> Keybuk, you already have an API for that
<zyga> Keybuk, hmm? I must have missed that somehow
<ebroder> Keybuk: Does the systemd integration basically work the same way as upstart? Setting the flag -> D-Bus doesn't start the service itself?
<Keybuk> <Keybuk> zyga: I thought about adding it to the environment, but decided it would probably limit things
<Keybuk> ebroder: right
<apw> cjwatson, who other than you (ie someone who is arround) would be a good person to help diagnose an early boot failure, likely something in initramfs
<ebroder> Ugh. That seems like a terrible design
<zyga> Keybuk, but why not activate _all_ jobs like that? No UpstartYob=y no extra upstart file
<Keybuk> ebroder: setting the flag means d-bus emits a signal that systemd listens to
<zyga> just pure dbus service that always gets activated by patched dbus sending message (as you currently do) to upstart
<Keybuk> likewise setting the upstart flag means d-bus makes a method call to upstart
<Keybuk> zyga: because it changes the behaviour of d-bus
<zyga> Keybuk, in what way?
<ebroder> Keybuk: Right. But since there are more init daemons than D-Bus daemons, I can't see why D-Bus needs to buy into the init daemons instead of the other way around
<Keybuk> zyga: right now, if you send a method call to an un-named service
<Keybuk> for which there isn't a .service
<Keybuk> the method call returns an error immediately
<zyga> right
<Keybuk> to have d-bus unconditionally activate would mean all such methods would timeout instead
<Keybuk> (activate via upstart)
<tseliot> cjwatson: are you around?
<zyga> Keybuk, hmm why?
<Keybuk> ebroder: because the init daemons are "higher up" the stack
<zyga> Keybuk, dbus would not activate that blindly
<cjwatson> wendar: ok, sounds good
<zyga> Keybuk, just check if the service exists, (it already does that)
<Keybuk> zyga: you just asked why dbus doesn't activate blindly
<Keybuk> right
<Keybuk> if the service exists, dbus will activate it
<zyga> Keybuk, and pass the sole activation step (with all the details) to upstart
<Keybuk> because then all existing services would immediately break
<Keybuk> because there wouldn't be upstart jobs for them
<tseliot> cjwatson: is it ok if a blacklist in /usr/share/grub-gfxpayload-lists/blacklist/ is a symlink to the actual blacklist file?
<zyga> Keybuk, no - I asked (earlier) why don't we just forward all activation requests to upstart. Why do we need the upstartjob=y flag?
<Keybuk> zyga: right
<Keybuk> because then you'd have to write upstart job files for them *quickly*
<Keybuk> if d-bus ignored the .service file
<Keybuk> and there wasn't an upstart job for it yet
<cjwatson> apw: try Surbhi perhaps
<Keybuk> it would break
<Keybuk> that's what the flag is for
<cjwatson> tseliot: not in front of the code right now but IIRC it just cats them together
<Keybuk> the flag means "this one has been converted"
<Keybuk> the contents of the .service file are there for backwards compatibility
<cjwatson> tseliot: check the implementation but it should be ok
<zyga> Keybuk, why would you have to write upstart jobs? I don't want to patch dbus to ignore it's own service files. I just want it to send the details about the service to upstart when it decides that given service should be activated
<zyga> Keybuk, after parsing the actual service file and getting stuff like Exec out of it
<Keybuk> zyga: how would that help?
<zyga> Keybuk, less administration
<zyga> Keybuk, one file to maintian
<Keybuk> then you wouldn't be able to customise any of the jobs
<Keybuk> less administration is not necessarily a good thing
<zyga> Keybuk, zero files to patch
<zyga> Keybuk, yes but that's another step
<Keybuk> no, there's no gain to that
<Keybuk> just having d-bus get upstart to do the job it's already doing is zero benefit
<zyga> Keybuk, getting jobs activated via upstart per se would just be a transparent improvement of the implementation
<Keybuk> no, it would be a transparent *movement* of the implementation
<zyga> Keybuk, you gain uniformity
<Keybuk> no you don't
<Keybuk> because the d-bus activation wouldn't be uniform with the rest of the upstart systme
<zyga> Keybuk, you already added the implementation, right? there are two ways to activate dbus services now, via upstart and via dbus
<Keybuk> all dbus activation would be done by a single .conf file
<elif> Hey guys I'm a bit confused since I'm trying to use preseed, I read the ubuntu-installer is ubiquity, but I donwloaded the ubuntu 10.10 server, x6-64 and I don't see the ubiquity there, instead just the debian installer, so automatic-ubiquity kernel parameter does nothing... is this right (no ubiquity as installer) ?
<tseliot> cjwatson: yes, it's correct. I've just found what you put on pastebin: http://paste.ubuntu.com/544450/
<Keybuk> zyga: three, actually
<Keybuk> but yes
<Keybuk> the existing implementation had two days
<Keybuk> I added a third
<Keybuk> two ways
<cjwatson> elif: the desktop (graphical) installer is ubiquity.  the text installer is a modified version of debian-installer.
<zyga> Keybuk, so why not unify that to one (via upstart) on ubuntu? Am I missing something?
<zyga> (apart from the actual extra work required)
<Keybuk> on receiving a message for a destination not connected to the bus, the D-Bus Daemon performs an Activation
<Keybuk> the process for that, in the upstream code:
<Keybuk>  - look-up and parse a .service file
<zyga> when/if someone wants to use upstart interface they just stop shipping .service file for dbus and ship an upstart job instead
<Keybuk>  - if the service has SystemdService=..., invoke systemd to do it
<zyga> uh :-)
<zyga> right, third
<Keybuk>  - otherwise, do it by hand using Exec
<Keybuk> I added an intermediate step
<cjwatson> elif: just use file= or url= as appropriate to point to the preseed file - see the installation-guide
<Keybuk>  - if the service has UpstartJob=y, invoke upstart to do it
<Keybuk> so basically I implemented it uniformly with the existing D-Bus upstream code
<Keybuk> now
<Keybuk> I could have done it differently
<Keybuk> I could have said
<Keybuk> - if the bus is being activated via Upstart
<Keybuk> - punt ALL activation requests (whether .service or no) to Upstart
<zyga> right
<Keybuk> this would have had the following effect:
<Keybuk>  - broken all existing services
 * zyga remembers your post about not replacing dbus years ago ;-)
<Keybuk>  - changed the behaviour of d-bus for *NON* activated services
<Keybuk>  - made a big patch upstream would have cried about
<Keybuk> so that's bad
<Keybuk> even though it might be ultimately better
<zyga> hmm, this is the part I dont understand
<zyga> (I'm not dbus expert so please bear with me if you can)
<zyga> how is the method you implemented now (delegation of the activation process to upstart for selected jobs) not breaking them the way you described above?
<kees> Keybuk: bug 693510 filed
<ubottu> Launchpad bug 693510 in linux (Ubuntu) "child paused by SIGTSTP fails to cause wait() to report WSTOPPED" [Undecided,New] https://launchpad.net/bugs/693510
<Keybuk> zyga: because it's done via a flag
<zyga> imagine if _each_ job had useupstart=y and an appropriate (generated) upstart job file
<elif> cjwatson, I'm writing preseed.cfg and packing it with the initrd, it works, but in mirror selecting part it always keep me asking to choose a mirror, I check what question name it was, I found it was "debian-installer/choose-mirror/title", of type Text, but no matter what I do it keeps asking me this question
<Keybuk> so it only changes the behaviour of an ACTIVATED service
<zyga> what would change then?
<Keybuk> and only an activated service THAT HAS BEEN MODIFIED
<zyga> hmm?
 * zyga should reread your message perhaps
<Keybuk> upstart doesn't autogenerate job files
<Keybuk> so
<Keybuk> right
<Keybuk> there's a third option
<Keybuk>  - if no .service is present, fail
<cjwatson> elif: that's certainly not the question name being asked
<Keybuk>  - if a .service is present, parse it
<zyga> (I know it does not - I was putting a theory on what would change in such scenario)
<Keybuk>  - send all information over to upstart so upstart can run it
<Keybuk> but honestly, that buys us nothing
<elif> cjwatson, it display the list with the answer provided in "mirror/http/hostname"
<Keybuk> we wouldn't be able to customise each job indepedantly
<zyga> Keybuk, what you just described is what I was generally arguing for the whole time
<Keybuk> we would still need to create a file in one place to have it run by a system configured in another
<Keybuk> right, and that's idioitic
<Keybuk> it has zero benefit
<Keybuk> and just complicates matters further
<zyga> no wait
<Keybuk> consider
<zyga> there's something not right here: why would you need to create another file?
<Keybuk> listen
<elif> cjwatson, do you have a sugestion of the question name ?
<cjwatson> elif: if you're setting hostname and directory, did you set (iirc) 'd-i mirror/http/country string manual'?
<Keybuk> so, we want to create a new service to be system-bus activated
<zyga> if you send _all_ the description required by upstart to start the new job why would you need to add a upstart job file (unless I mistake something)
<Keybuk> we would *have* to create a file in /usr/share/dbus-1/system-services
<zyga> right
<Keybuk> to configure Upstart
<apw> anyone know if pitti is about?
<Keybuk> that's confusing in of itself
<Keybuk> that file is parsed by D-Bus
<zyga> right
<apw> Keybuk, cjwatson, i believe that the current udev in the archive is bad
<cjwatson> elif: I'm ircing from a phone right now, I can't check all the facts.  if you're stuck feel free to mail your preseed.cfg and your installer syslog to cjwatson@ubuntu.com and I'll look when it's more convenient
<Keybuk> so it can have *NONE* of the features of Upstart that D-Bus doesn't know about
<zyga> right
<Keybuk> so you gain zero benefit from Upstart
<zyga> right
<elif> cjwatson, oh thks.
<zyga> I agree with everything you said
<Keybuk> so, all you've done there is move the supervising from d-bus to upstart
<Keybuk> for a benefit of zero
<Keybuk> at a cost of increased complexity
<zyga> that depends on the viewpoint but I agree
<zyga> what you did not do is also important
<zyga> you made the activation uniform, there is no heisenbug that sometimes kicks in when service gets activated by upstart
<zyga> you made this process transparent to anyone who now today ships a .service file for upstart
<zyga> and provided a clear upgrade path to upstart features
<zyga> now
<zyga> compare that to current situation
<Keybuk> apw: oh, wow, someone uploaded 165 - I took one look at those release notes and backed away
<zyga> if you want to use upstart then shipping service file is mostly useless
<Keybuk> zyga: correct
<zyga> except for the flag that you need to add
<Keybuk> zyga: except services are shipped by upstreams
<zyga> and the (probably unused) Exec line
<Keybuk> so this allows an upstream to ship a service file for sysvinit distros
<Keybuk> a systemd unit for systemd distros
<ari-tczew> cjwatson: are you not afraid to write full mail address here? (spam case)
<zyga> and on top of that you need to create an upstart job file for the actual gory details of what you want to do
<Keybuk> and an upstart job for upstart distros
<cjwatson> ari-tczew: no
<zyga> Keybuk, yeah and IMHO upstreams will hate that
<apw> ari-tczew, his email is so well known he cannot make it any more on spam  lists than it already is
<zyga> Keybuk, they were happy with .service for dbus
<Keybuk> zyga: of course they will
<Keybuk> like I said, I expect no services to be migrated ;-)
<zyga> Keybuk, few will want to get the extra features that upstart and systemd offer
<Keybuk> not until dbus-daemon goes away, anyway
<zyga> Keybuk, actually having _not_to_ do this for upstart would be an improvement over systemd
<zyga> Keybuk, you essentially invent a new interface for no gain
<Keybuk> zyga: *except* these patches have to be accepted by D-Bus upstream
<Keybuk> we can't go around cowboying the universe
<zyga> Keybuk, hmm
<Keybuk> (yeehaw!)
<Keybuk> so look at this instead from a "next year" POV
<Keybuk> let's say Collabora's patches to add multicast AF_UNIX are accepted into the kernel
<Keybuk> D-Bus communication can now be implemented entirely without an intermediary daemon
<Keybuk> except for Activation
<Keybuk> but this is only true for newer kernels
<Keybuk> so you need to have a dbus-daemon around for older kernels
<zyga> Keybuk, so next year everyone will stop shipping .service files for older distros? Either upstart job or system unit?
<ebroder> Keybuk: Isn't there a problem that Upstart supports doing more things in its conf file than D-Bus does? Same with systemd? So either an application only writes in its Upstart conf file what it can do in pure D-Bus (in which case why not just get the configuration from the normal D-Bus location), or it drops support for pure D-Bus without systemd or Upstart (which would be lame on the app's part)
<Keybuk> zyga: you got it ;-)
<zyga> Keybuk, that's what I don't like
<Keybuk> ebroder: initially, but only for an LTS cycle or so
<zyga> Keybuk, I like the old interface, there's nothing wrong with it
<Keybuk> zyga: it's not very flexible
<zyga> Keybuk, I second ebroder's comment on this
<zyga> Keybuk, true
<zyga> Keybuk, so you have two upgrade paths: systemd and upstart
<Keybuk> yes
<zyga> Keybuk, but if it's okay for you you don't have to worry about the next ubuntu breaking the world for no good reason
<kees> Keybuk: hrm, this should be the minimal test case, right? run alone, it works fine. http://paste.ubuntu.com/546681/
<Keybuk> zyga: what's it got to do with breaking the world?
<Keybuk> kees: no idea
<zyga> Keybuk, if you don't change your code (to support upstart/systemd) how will your dbus .service get activated without the deaemon?
<Keybuk> zyga: it won't
<zyga> broken!
<zyga> :-)
<zyga> see what I mean?
<Keybuk> that's just the day-to-day business of linux
<zyga> why cannot we just keep that support
<Keybuk> if you still have an agent in /etc/hotplug - it won't work now :p
<ebroder> Keybuk: I think my issue is mostly that D-Bus is currently init-daemon agnostic, and it seems lame to switch to a model that is no longer agnostic of the init daeomn, especially when there's more than one popular daemon right now
<zyga> Keybuk, I hope you don't believe that ;-)
<Keybuk> zyga: I didn't say we couldn't - in fact, I believe I asked you to write it ;-)
<zyga> Keybuk, there is _nothing_ wrong with those files
<zyga> Keybuk, great :-)
<Keybuk> ebroder: but that switch has already happened
<Keybuk> ebroder: we're just catching up
<zyga> Keybuk, so at least we agree that it's not an issue to support that
<ebroder> That doesn't make it any less of a terrible design decision
<Keybuk> zyga: I have zero problem with upstart parsing the existing dbus service files
<Keybuk> and generating jobs from it
<zyga> Keybuk, so that the world has a common denominator to target if they are fine with the subset of features they might otherwise get
<zyga> Keybuk, what about dbus parsing them and just sending the details over the wire? this way there is almost no patch for upstart and rather smallish patch for dbus (I might try to do that over xmas)
<Keybuk> zyga: that's a lot of effort to add to d-bus
<Keybuk> which is going away
<zyga> Keybuk, hmm
<Keybuk> and then, when the daemon vanishes, you'd need to do it all again
<Keybuk> if upstart were patched to parse them in the first place
<zyga> Keybuk, do you think that everyone will actually drop the daemon?
<Keybuk> then the effort is only done once
<Keybuk> and lasts forever
<Keybuk> zyga: that's certainly what everyone wants to do
<Keybuk> it's Slooooowwww
<zyga> Keybuk, if that's really going to happen then you are right, parsing the stuff in upstart is better
 * janimo wonders what is the difference between armel and other builds servers, as debian/rules only fails on armel due to an error in mv
<zyga> janimo, armel is never virtual
<zyga> janimo, and has some security around that so that random build should not take over the system
<zyga> janimo, what was the move that failed?
<cjwatson> zyga: distro buildds in general aren't virtual
<janimo> zyga: in the ghc6 build, moving some doc files as the install step of the build
<zyga> (except for qemu of course but I don't know if we have that in our builds)
<zyga> cjwatson, are x86 packages not build by virtual machnies?
<cjwatson> zyga: only ppas
<janimo> zyga: I was expecitng all makesfiles to fail when a mv fails but only armel did
<zyga> cjwatson, hmm
<zyga> cjwatson, ah, so we trust our packages more to let them run on hardware, right?
<cjwatson> janimo: look up in the log to see if something failed earlier (e.g. it failed to build the docs) and buggily failed to notice
<janimo> and I see quite a few mv: cannot stat file .... causing FTB in debian and ubuntu during the years
<cjwatson> zyga: yes
<zyga> Keybuk, thanks for the clarifications
<zyga> Keybuk, I'll have a look at this over xmas
<janimo> cjwatson: will check. The same thing built locally on armel
<cjwatson> I certainly very much doubt that mv is fundamentally different on armel!
<Keybuk> zyga: the patch isn't so much an "ideal world" more of a "here's our reaction to the systemd patch"
<zyga> Keybuk, yeah, it shows
<janimo> cjwatson: one file that it expects to mv is missing but that is the case for x86 as well
<Laney> janimo: thanks, I hope to get some time soon
<janimo> Laney: strangely it buildt locally
<Laney> I will upload 6.12.3 soon though, so we can see if it's fixed by that
<janimo> Laney: ok. the only packaging change I can think of is to ignore mv errors in the haddock section
<janimo> just to rule out that this trips over armel
<Laney> yes
<Laney> but it's a concerning failure nonetheless
<apw> Keybuk, do you know if there is any debug in udev at all ?
<janimo> Laney: are the arm and pthread fixes in 6.12.3 upstream or you will carry them in packaging
<Laney> I got it from a nug
<Laney> a bug*
<janimo> Laney: only one package (base 3 ) does not provide *.haddock files and that is the error. Not sure if it is supposed to have those files though
<Laney> it never failed like that before
<ion> keybuk: Looking at http://launchpadlibrarian.net/61083245/dbus_1.4.1-0ubuntu1_1.4.1-0ubuntu2.diff.gz it seems an extraneous whitespace change has sneaked into a patch, search for process_config_every_time.
<Keybuk> *gasp*
<Keybuk> not extraneous whitespace!
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ari-tczew
<Keybuk> I think I was probably un-tabbing things
<Keybuk> and turning them back into spaces
<Keybuk> apw: only if you recompile it
<apw> Keybuk, and i'd be right in thinking there is no sensible way to go back a version in the archive
<cjwatson> apw: correct, particularly not back an upstream version.  better to fix it ...
<bdmurray> mdz: I seem to recall you modifying apport or dpkg to not report short read in buffer copy bugs is that right? Oh, it was only for english ones yes?
<apw> cjwatson, /me has no idea as to the cause the symptoms for me are an unbootable kernel, i think sarvatt is affected too, he may be able to login to his after
<mdz> bdmurray, yes
<mdz> bdmurray, apt actually
<bdmurray> mdz: and it was english only?
<bdmurray> mdz: found it - thanks
<jdstrand> hallyn, apw: I am seeing some weird, but major kvm regressions with the last two natty kernels
<jdstrand> hallyn, apw: my hunch is something with ksm, but I don't know. the symptoms are if I run 2 or more vms at once, the vms are extremely flaky, with random segfaults all over
<jdstrand> hallyn, apw: hold on. I'll report back later
<jdstrand> hallyn, apw: there is a bug, but I'm still investigating. it might be with the hardware. nm for now
<hallyn> jdstrand: kthx
<ebroder> RAOF: We talked a month or two ago about stopping the X server from changing video modes when it starts to give gnome-settings-daemon a chance to pick the best mode. Have you had a chance to look into that yet?
<ebroder> (And is there anything I, as someone who knows very very little about the X server, can do to help?)
<RAOF> ebroder: I haven't yet, no.  I got pulled into a whirlpool of dri2.
<RAOF> There's probably not much to do outside of adding a driver hook to startup to say âhey, there's a nice mode already set, just let me use thatâ.
#ubuntu-devel 2010-12-23
<psusi> cjwatson, back in june I tinkered with ureadahead to have it use the pipe method instead of the log file method for ftrace... this eliminated the need to preallocate a buffer to hold the full trace, and instead has ureadahead parse the trace log in real time.  would you be interested in it if I rebased it and proposed merging?
<psusi> cjwatson, err, nevermind, I meant keybuck
<psusi> Keybuk, back in june I tinkered with ureadahead to have it use the pipe method instead of the log file method for ftrace... this eliminated the need to preallocate a buffer to hold the full trace, and instead has ureadahead parse the trace log in real time.  would you be interested in it if I rebased it and proposed merging?
<psusi> ohh, you've merged that fragraph.py.. I couldn't remember who gave me that
<ari-tczew> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<dholbach> good morning!
<zyga> hi
<zyga> django has released security releases for all production branches, are we going to get that in lucid + ?
<zyga> two security bugs were fixed
<apw> dholbach, morning
<dholbach> hey apw
<apw> anyone else seeing gdm greeter repeatedly crashing before it prompts ?
<apw> dholbach, nothing works for me today its most depressing
<dholbach> hum... is anything in /var/log/Xorg.0.log or /var/log/gdm/* about that?
<dholbach> apw, it certainly works for me (in a vm)
<dholbach> maybe the #ubuntu-desktop mafia can help?
<apw> dholbach, yeah continius errors about window==NULL
<dholbach> hum, no idea what that is about
<apw> dholbach, will ask the #u-d mafia, but i bet they are all gone
<dholbach> ^ RAOF, bryceh?
<dholbach> (only ones I could find :-))
<apw> heh both in other timezones tho ... sigh
<apw> dholbach, that will teach me to dogfood, we cannot be trusted to not push poo before a break
<ricotz> this is a problem with the gtk+ packages
<apw> ricotz, yeah you seeing it too?
<ricotz> yes
<dholbach> ok, I see it too :)
<ricotz> i am not sure yet, what the real cause is, but the gtk+3.0 dev is broken
<ricotz> also the gobject-introspection packaging it messed up :(
 * apw wonders who to slap
<dholbach> I don't see anything obvious in http://launchpadlibrarian.net/61126003/gtk%2B3.0_2.91.7-0ubuntu1_2.91.7-1ubuntu1.diff.gz
<ricotz> dholbach, it is 2.91.7 the tarball doesnt ship all needed *.pc files
<dholbach> aha
<apw> dholbach, doesn't seem robert is on IRC, at least if his IRC entry is accurate anyhow
<dholbach> no seems like he's not around
 * apw thinks we need a word about shipping upgrades and then going on holiday before they are even built
<apw> ricotz, does it help if i downgrade to .6 ... as confirmation that is the broken component?   seems i have them in my cache
<ricotz> apw, i think this could help, but the gtk+2.0 update might have a problem too
<apw> ricotz, gurgle, ok i'll try that downgrade and report back
<ricotz> i uploaded a git snapshot of gtk+3 to my ppa, it might fix some problems for me
<apw> ricotz, ok downgrading the 3.0 stuff did not help
<ricotz> apw, so if the problem persists i can try to downgrade gtk+2.0 too
<apw> ricotz, ok downgrading the 2.0 as well seems to get me a gdm prompt at least
<apw> dholbach, a nice mess and no mistake
<ricotz> apw, you might want to go back to gtk+2.0 2.23.2
<ricotz> ah, nevermind
<apw> ricotz, i think thats the version i had before, yes
<apw> ricotz, thanks for your help finding the errant packages so quick
<ricotz> apw, oh another thing
<ricotz> apw, are there known problem with 2.6.37-11 and nvidia blob
<dholbach> ricotz, https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032244.html?
<apw> ricotz, not that i've heard about, but the binary blobs normally explode when we change the kernel
<dholbach> apw, I agree it's not nice to be stuck with a problem like that, but I'm sure Robert really didn't mean to sabotage you
<dholbach> (or whoever else uploaded the change that made things break)
<apw> dholbach, i know he didn't do it deliberatly :)  but shipping a primary library change as a break starts is asking for trouble
<apw> thats why we did our last kernel update 4 days before we went offline :)
<ricotz> dholbach, alright, that might be it
<dholbach> ricotz, I filed a bug about mine
<apw> ricotz, cirtainly you cannot have =keep turned on with those binary blobs, they do not cope with the card being initialised
<apw> ricotz, which is pretty crap given they are from the vendors of the devices and they have the manuals for the chipsets and everything
<apw> ricotz, is there a bug on this gtk stuff yet?
<ricotz> apw, yeah, i want to try the nvc0 nouveau branches at some time, but right now i need to use the blob :(
<ricotz> apw, i havent filed one, so maybe not
<apw> dholbach, you ?
<dholbach> I didn't file a bug on the gtk stuff
 * apw will file one
<apw> ricotz, did you say it was missing the .pc files ?
<ricotz> yes, the gtk+3 one but that is an upstream issue which is fixed
<apw> ricotz, ok i will leave the description plain without that and just include the work around
<apw> https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/693737
<ubottu> Ubuntu bug 693737 in gtk+2.0 (Ubuntu) "gtk+2.0 update 2.23.3-1ubuntu2 update triggers repeated gdm greeter crashes" [Undecided,New]
<apw> dholbach, this machine is turning into a right frankenstein, udev and gtk held back now to get a clean boot ... sigh, at least the kernel works
<dholbach> apw, there's times that have been worse I think :-)
<apw> dholbach, that i can believe, no chance of working CDs over the break sadly
<apw> that will upset cert
<ari-tczew> zyga: ask on #ubuntu-hardened
<zyga> thanks
<vish> cjwatson: hi, regarding Bug #548981 , I'd marked the dpkg task as fixed, since tedg mentioned in the session that it was fixed in dpkg. I dont know the commit# though. Maybe we can ask tedg when he returns from his vacation..
<ubottu> Launchpad bug 548981 in indicator-session (Ubuntu) "Indicator should only turn red after the last package has been installed" [Low,Triaged] https://launchpad.net/bugs/548981
<cjwatson> vish: *shrug* as far as I know he was mistaken, since this is plain-and-simple not a problem in dpkg itself, but I don't know that it matters all that much.  I was just trying to stop people searching for a non-existent fix.
<cjwatson> vish: (I upload dpkg to Ubuntu, tedg doesn't ;-) )
<vish> cjwatson: yea, i know.. :)
<SpamapS> Does anyone have experience with nfs root mounted systems? I'm specifically curious about how sm-notify works without any local storage to tell us who to notify.
<SpamapS> hrm, seems like one would need a dedicated /var for each client or reboot notification isn't going to happen.
<matti> :>
<ari-tczew> cjwatson: is sync tor on todo archive admins?
<cjwatson> ari-tczew: yes
<jhunt> SpamapS: re bug 690401 - apologies: your RLEVEL logic is of course correct: seemingly my
<ubottu> Launchpad bug 690401 in nfs-utils (Ubuntu Lucid) "statd startup races with / becoming writable (dup-of: 581941)" [High,Confirmed] https://launchpad.net/bugs/690401
<jhunt> brain doesn't parse shell syntax as well as the shell!
<ubottu> Launchpad bug 581941 in nfs-utils (Ubuntu Lucid) "statd does not start automatically when needed nor can be forced to start on boot" [Medium,Triaged] https://launchpad.net/bugs/581941
<jhunt> SpamapS: I'm still confused by the whole runlevel thing though. Keybuk has pointed out that "there be demons" with the "start on... runlevel" logic proposed.
<SpamapS> jhunt: it does indeed feel as if I've set off on a voyage destined for the edge of the map, not down the coastline ;)
<SpamapS> jhunt: the problem is, if we just drop the 'start on started portmap' then when portmap is restarted, we won't start back up.. and if we drop both.. then we won't pick up the new portmap
<SpamapS> jhunt: so I truly want to express "start on started portmap and run level is one of [2345]"
<SpamapS> it may be better to simply do a check for /var being writable.
<sladen> okay, who did an upload today and turned GDM into a 1 Hz flashing rectangle of white ?
<SpamapS> sladen: santa's little helper?
<sladen> SpamapS: the timing is excellent
 * SpamapS was just about to do-release-upgrade -d .. will hold off ;)
<sladen> bryceh: ^^ would the failsafe change to xorg yesterday have made login impossible?
<ScottK> sladen: Probably either a security feature or trying to make training simpler for corporate clients.
<sladen> ScottK: there's certainly no risk of a GUI login, accidental, malicious, or intended
<ScottK> sladen: Right.  Thus it's secure and training costs are minimal.
<sladen> ScottK: the wonderful thing is I can't file a but from lynx about not being able to file bugs from lynx either :)
<sladen> sabdfl keeps asking me for a get-out-of-jail pen-drive image ... could do with it now
<Keybuk> SpamapS: err
<Keybuk> SpamapS: even with the portmap, when portmap is restarted, that job won't start back up again
<Keybuk> so you're already putting diesel in the tank
<Keybuk> and worrying about your mileage varying
<SpamapS> Keybuk: can you explain further?
<Keybuk> sure
<Keybuk> so you've done:
<Keybuk>   start on one-thing and another-thing
<Keybuk> right?
<Keybuk> that doesn't work the way anyone thinks it does
<Keybuk> and while it works as designed, the design is wrong
<Keybuk> "and" means both events must happen for the job to be started
<SpamapS> I did do that, however slangasek pointed out that it will cause a deadlock so I think I have to remove the and
<Keybuk> but, it also means, once the job is stopped, BOTH events MUST happen AGAIN
<Keybuk> so if you do
<Keybuk>   start on started portmap and net-device-up lo
<Keybuk> then restarting portmap will stop statd
<Keybuk> but won't start it back up again
<Keybuk> because it's waiting for the network device to come up
<SpamapS> the logic I've proposed is   start on started portmap OR mounting TYPE=nfs OR runlevel [2345]
<Keybuk> it was "AND" last time I looked ;-)
<SpamapS> the one that steve took issue with was   start on started portmap OR (local-filesystems and mounting TYPE=nfs)
<Keybuk> yeah, basically avoid and unless you really know what you're doing
<Keybuk> if you have a problem, and doesn't solve it
<Keybuk> it gives you new and worse problems
<Keybuk> so
<Keybuk> winding back a bit
<Keybuk> I'm trying to understand what you're trying to change
<SpamapS> right, some of the discussion has been going on in a merge proposal..
<Keybuk> well, that, and all the discussion is filed under TL;DR at this point
<Keybuk> I assume you're working on a fix for that fact that statd doesn't get started on boot if you don't mount an NFS share?
<SpamapS> right, well I've got you now so.. to answer your bigger question.. I just want to make sure that we *don't* try to start statd before /var is writable...
<Keybuk> why before /var ?
<SpamapS> sm-notify has to write to /var/lib/nfs
<Keybuk> ok, so why not:
<Keybuk>   start on local-filesystems
<SpamapS> thinking
<SpamapS> is that event emitted on nfsroot only setups?
<Keybuk> no idea
<Keybuk> I've never tested nfsroot
<Keybuk> it's emitted by mountall
<Keybuk> and I think mountall has always had issues with nfsroot setups ;)
<SpamapS> Also it would require that all local filesystems are mounted before nfs.. but.. that actually is what I'm looking at doing anyway.. just documenting that fact.
<slangasek> Keybuk: it's not "start on local-filesystems" because it will race portmap, which only depends on virtual-filesystems
<Keybuk> will it race portmap?
<Keybuk> someone's stuck start portmap in the statd pre-start
<SpamapS> right
<slangasek> hm
<Keybuk> there may not be an ideal solution for this today
<Keybuk> but I'd like to at least know what the ideal solution should be so I can test that works in upstart2
<slangasek> right, I suppose that should work then
<SpamapS> will start block if a job is already goal==start but not running?
<Keybuk> while advising on a hack to solve the bug that is open today
<Keybuk> SpamapS: no, but then there's a status portmap right after the start portmap ;-)
<SpamapS> Keybuk: which will fail the pre-start .. which means we then don't start statd right? or does it mean it will be tried again?
<Keybuk> there's a small race there that may mean it won't be tried again
<Keybuk> if portmap gets started between the point the status call gets told it's not running and stops the job
<SpamapS> well this is handled by the OR started portmap
<Keybuk> right, but there's a race there
<SpamapS> if we just add a check to either sm-notify, or the pre-start, that makes sure /var is writable before we try to run sm-notify
<Keybuk> I think the problem is with the NFS shebang is that too many start conditions are trying to be encoded
<Keybuk> you want to start on boot
<Keybuk> but simultaneously before and after some event
<SpamapS> Its ok to try it when portmap is started and on local-filesystems, as long as we only go forward after /var/lib/nfs is writable.
<Keybuk> and if the event doesn't happen
<Keybuk> SpamapS: I don't think you can encode that today
<SpamapS> Right it does seem like there is a singular sync point that we want to hit
<SpamapS> after portmap, after local filesystems, before mounting any nfs mounts
<Keybuk> maybe the right thing to do is to try and draw the conditions
<Keybuk> if we can see the possible timelines, it may be more obvious
<SpamapS> Right.. as I'm drawing.. is local-filesystems ever emitted before virtual-filesystems?
<Keybuk> no, I think that's an invariant in mountall
<Keybuk> it always does virtual, local, remote
<Keybuk> ok, checked
<Keybuk> it enforces virtual before local
<Keybuk> and enforces virtual before remote
<Keybuk> but you may get
<Keybuk> virtual, local, remote
<Keybuk> OR virtual, remote, local
<SpamapS> it is..
<SpamapS> one of the conditions for firing local-filesystems is virtual_triggere
<SpamapS> d
<Keybuk> yes
<SpamapS> so start on local-filesystems hits the mark exactly
<Keybuk> you might want:
<Keybuk>   start on local-filesystems or started portmap
<SpamapS> Its still possible that this will be too late for statd, but that is something that people configuring systems must be conscious of.
<Keybuk> to pop up the restart on upgrade case
<Keybuk> mop up, sorry
<slangasek> but then the 'or started portmap' races the rw mount of /var/lib in the on-boot case?
<SpamapS> Right, unless we say either "but not during bootup" or "but only if /var is writable"
<SpamapS> which I think is ok for a pre-start .. no?
<slangasek> and if local-filesystems isn't handled synchronously, the whole thing can still race an attempt to mount an nfs shar
<slangasek> e
<slangasek> at boot
<SpamapS> slangasek: indeed, local-filesystems is not waited on.. however
<SpamapS> start on mounting TYPE=nfs *is*
<Keybuk> right, local-filesystems is a signal
<Keybuk> mounting is a hook
<Keybuk> this is why I'm trying to get thinking in terms of a timeline
<slangasek> SpamapS: which doesn't help us if you can't mention 'mounting' in the job because we can't use AND :)
<Keybuk>  v | <-----> (portmap)
<Keybuk>           | l
<Keybuk> vs
<Keybuk>  v | <-----> (portmap)
<Keybuk>                | l
<SpamapS> slangasek: we don't need AND
<Keybuk> in those two cases, where should this go?
<slangasek> SpamapS: what we need is: statd started after portmap, after /var/lib is mounted rw, and before any attempts to mount an nfs filesystem
<Keybuk> do you need statd to mount an nfs filesystem?
<slangasek> yes
<Keybuk> I thought statd was for when someone was mounting yours
<Keybuk> because you definitely also need statd for when someone is mounting *your* NFS filesystems
<slangasek> it's also needed on the client side
<Keybuk> which means it's much more complicated than what you just said
<Keybuk> because then it's
<Keybuk> statd started after portmap, after /var/lib is mounted rw, before any attempts to mount an nfs filesystem and if there are no nfs filesystems
<slangasek> Keybuk: "when someone is mounting your NFS filesystems" comes later; nfs-kernel-server isn't even converted to upstart yet
<Keybuk> slangasek: statd doesn't get started in that case ;-
<slangasek> Keybuk: right, sorry, I was implying that part
<Keybuk> you realise of course that upstart will only stop the *first* attempt to mount an nfs filesystem >
<slangasek> yep :/
<Keybuk> (which I guess is ok, because mountall waits anyway)
<Keybuk> so that looks something like:
<Keybuk>   start on started portmap \
<Keybuk>       and local-filesystems \
<Keybuk>     and mounting TYPE=nfs
<SpamapS> slangasek: maybe portmap should start on a mounted, rather than virtual-filesystems ..
<slangasek> nope
<slangasek> there's no way to use 'mounted' to describe what you want in the general case
<slangasek> because fstabs are varied
<SpamapS> and if you do an and.. kittens suffer capital punishment..
<Keybuk> not always, it just pays to think
<SpamapS> well wait
<SpamapS> it will fail to start if portmap isn't started yet right?
<Keybuk> in the above case, for example, it will all go very badly wrong
<SpamapS> so the OR still works.. the second attempt will succeed
<Keybuk> SpamapS: no
<Keybuk> SpamapS: unfortunately you have a race
<Keybuk> again, think in terms of timelines
<SpamapS> I'm drawing it right now.. ;)
<Keybuk>  | <--> : (status, portmap is not started)
<Keybuk>      |  : (portmap is started )
<Keybuk>         | (job is stopped)
<Keybuk> it's possible for started portmap to happen while the result of start portmap/status portmap being still in transit back to the job
<Keybuk> in which case the job is in JOB_START when it gets told "portmap started"
<slangasek> how about: start on started portmap $post_boot or (started portmap $at_boot and local-filesystems) or mounting TYPE=nfs?  Or was the magic to distinguish between boot-time and post-boot start of portmap rejected when I wasn't looking?
<Keybuk> slangasek: hmm, that's quite a nice idea - though how would you put the magic in?
<slangasek> Keybuk: it was SpamapS's idea to get the portmap job to export some appropriate variables; neither of us had quite worked out yet what the mechanism for that was
<Keybuk> you can export variables from events that started you
<Keybuk> so if you did something like:
<Keybuk>   start on virtual-filesystems and net-device-up IFACE=lo
<Keybuk>   exec initctl emit start-portmap ON_BOOT=yes
<Keybuk> then in portmap.conf
<Keybuk>   start on start-portmap
<Keybuk>   export ON_BOOT
<Keybuk> you can do elsewhere
<Keybuk>   start on started portmap ON_BOOT=...
<Keybuk> (you need the middle-man job to start portmap, rather than portmap having its own condition)
<SpamapS> ah so you can only export from events..  not from the environment
<Keybuk> tbh, I suspect this NFS stuff would get a lot easier to understand if we just had all the NFS-y things having
<Keybuk>   start on NEED_NFS=y
<Keybuk> and something else actually emitting those events ;)
<Keybuk> err
<Keybuk>   start on need-nfs ;-)
<Keybuk> SpamapS: upstart doesn't know the environment of its children
<Keybuk> SpamapS: only the environment it gave to its children
<Keybuk> (UNIX 101, dear)
 * SpamapS was obviously a bit hung over that day. :/
<Keybuk> . o O { of course, upstart could look at /proc/$PID/environ at the point of the started event and re-import that }
<slangasek> so that gives us 'start on started portmap ON_BOOT= or (started portmap ON_BOOT=yes and local-filesystems)' ?
<Keybuk> I think so
<SpamapS> Makes sense to me.
<SpamapS> so then just add a portmap-boot.conf that sets that
<slangasek> ... plus the 'or mounting TYPE=nfs' which fell off the end of my cut'n'paste
<SpamapS> slangasek: wait, or? I thought it was and.
<SpamapS> strike that
<slangasek> k
<SpamapS> what about the timeline where portmap is not started yet, but we hit mounting TYPE=nfs
<slangasek> SpamapS: we keep the 'start portmap' in the pre-start script for that
<SpamapS> Which won't block if its start/pre-start, or will it?
<slangasek> I've seen evidence to suggest that it might not block in that case, but if so that might be an upstart bug
<SpamapS> checking
<SpamapS> no
<SpamapS> http://paste.ubuntu.com/546986/
<SpamapS> you will just get an error "job is already running"
<SpamapS> even though its not, its in pre-start
<Keybuk> slangasek: it does not block, and it is considered an upstart bug
<slangasek> Keybuk: fixable in the near-term?
<Keybuk> (it's one I have a solution for I'm very proud of :p)
<slangasek> uhoh ;)
<Keybuk> slangasek: it's not on the natty list
<slangasek> SpamapS: so anyway, there would still be a race condition there as a result of the upstart bug; but it would be a smaller race window than what we have now, and it needs to be fixed in upstart
<SpamapS> quite a bit yes I agree
<slangasek> so we might try this route and see how close that gets us to something usable?
<SpamapS> quite a bit smaller I mean
<SpamapS> Yes, it seems a very tiny window. We should probably do a best-effort check for things that may cause portmap to start slowly.
<Keybuk> you could also just do a loop in the pre-start checking the result of status
<slangasek> I didn't write it that way initially because of a conversation we had where you were very vehement about not doing that ;)
<Keybuk> oh, I may have been vehemently misunderstanding your intentions
<slangasek> so, while ! status portmap | grep -q start/running; do sleep 1; done
<bryceh> sladen, oh I would highly doubt it
<SpamapS> slangasek: should also have the start in there.. what if it failed, we'd spin forever without even trying to rectify the situation.
<SpamapS> Keybuk: thanks for taking time to help out. :)
<SpamapS> slangasek: ^ you too. :)
 * SpamapS will bbiab
<sladen> bryceh: seems to be somewhere in the asychronous DBusy soup
<bryceh> sladen, ah
<slangasek> SpamapS: yes, wasn't suggesting removing the 'start' line, just fixing the line after it
* sladen changed the topic of #ubuntu-devel to: Archive: Open | Natty GDM Login broken: Bug #693737 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<kees> any archive admins around? I'm trying to figure out why "tor" hasn't appeared in natty yet.
<ari-tczew> kees: +1
<ari-tczew> I asked today about this case
<kees> yeah, I though it was stuck in NEW, but I don't see it.
<micahg> kees: my guess is the AAs were finishing up EOY tasks
<kees> hm, actually, in looking at natty-changes, it seems there hasn't been a Debian sync in a while.
<micahg> right, hence my theory :)
 * kees scratches his head
<kees> maybe the auto syncs don't show up.
<micahg> kees: no, they show up as Ubuntu Installer
<kees> I was thinking those were requested syncs, not auto syncs
<micahg> kees: requested syncs show up with the name of the requestor
<kees> hm, no, it looks like auto sync doesn't show up. e.g. libdisasm does not appear in maverick-changes even though it was updated in maverick during an autosync
<dobey> is there a document on the wiki that explains how to go about getting new binary packages added to the default install/cd? i'm having trouble finding one if so, and trying to find some clear explanation of that process
<micahg> kees: it seems you're correct, I apologize for the wrong information :)
<kees> micahg: heh, no worries. I guess it was turned off due to the flood it would create.
<kees> unfortunately, I'm back to wondering when the last autosync was. :P
<kees> (and where tor ran off to)
<micahg> kees: well, the bug's not closed, so it probably just hasn't been processed yet
 * kees nods
<micahg> and almost everyone's on vacation at this point
 * micahg thinks there will be one last huge auto-sync on Jan 3 when everyone comes back
<sladen> dobey: I think http://wiki.ubuntu.com/SeedManagement  but for extra comedy that page is crashing at the server end
<dobey> so it seems :-/
<micahg> kees: the delay gets us a couple extra bug fixes :)
<kees> micahg: hehe :)
<geser> kees: got "tor" synced? I see the sync request still open (bug 413657)
<ubottu> Launchpad bug 413657 in tor (Ubuntu) "Please sync tor 0.2.1.26-4 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/413657
<kees> geser: that's old, IIUC. it had been on the autosync blacklist, but it got removed, so I've been trying to figure out why it didn't get autosynced
<Laney> maybe nobody has done a new-source (or whatever it's called) run since
<geser> might be, auto-sync only syncs "existing" packages
<geser> import new packages is another script which gets run less frequently than the auto-sync script
<micahg> geser: there's also a sync request filed for it
<Laney> that was only recently acked
<micahg> Laney: last week
<Laney> was the queue processed since?
 * micahg test builds the new version of tor
<micahg> Laney: does not appear so
<Keybuk> zyga: if you were subscribed to the D-Bus list right now, you'd understand the rationale for doing those D-Bus activation patches :-)
<Keybuk> it has forced the desired discussion
<Keybuk> well, shouting from Lennart anyway
<zyga> Keybuk, hmm, dbus on freedesktop?
<zyga> Keybuk, I'll check the archive, thanks for the hint
<ebroder> zyga: http://lists.freedesktop.org/archives/dbus/2010-December/013868.html is the link you want - it's buried in the thread view
<zyga> ebroder, thanks
<SpamapS> slangasek: actually I was suggesting moving the start into the loop, it may fail. But while disconnected, I thought of another thing we could try. What about making portmap start on ... whatever it has now .. or starting statd   ?
<sladen> zyga: http://lists.freedesktop.org/archives/dbus/2010-December/thread.html  was an interesting read
<SpamapS> slangasek: that would make sure statd never actually starts until portmap is started
<zyga> sladen, I actually read most of the archive from that month
<slangasek> SpamapS: ah; I wouldn't move the start into the loop, because aside from the "already starting" race, the only reasons it should fail would seem to be fatal and shouldn't cause the statd job to be left looping
<slangasek> SpamapS: and portmap 'start on ... or starting statd' only ensures portmap is started first *if* portmap isn't already being started, which by all rights it should be
<Keybuk> sladen: I wish that someone would fix the fd.o pipermail
<Keybuk> it's annoying the way it doesn't correctly line up threads
<SpamapS> slangasek: leaving the statd looping means never mounting nfs filesystems.
<SpamapS> slangasek: and means never emitting 'filesystems'
<SpamapS> slangasek: so at the very least, we should only wait for a little while.. hence my thought that we should make a best effort attempt to identify the longest we think it should ever take for portmap to be up and serving.
<SpamapS> slangasek: another thought for the longer term.. socket activation for portmap would seem to alleviate this problem entirely wouldn't it?
<sladen> bryceh: narrowed down to today's libgtk2.0-bin (>2.32.2-0ubuntu4)  robert.ancell might be around in an hour (Sydney time)
<sladen> robert_ancell: bug #693737
<ubottu> Launchpad bug 693737 in gtk+2.0 (Ubuntu) "gtk+2.0 update 2.23.3-1ubuntu2 update triggers repeated gdm greeter crashes" [Critical,Confirmed] https://launchpad.net/bugs/693737
<slangasek> SpamapS: I still don't think we should be second-guessing other conditions that cause portmap to fail to start until we actually encounter one
<bryceh> sladen, aha excellent
<SpamapS> slangasek: 100% agree, lets not put start in the loop. But does it make sense that it should give up after a while?
<SpamapS> slangasek: essentially.. I'd rather move on to a failure because nfs can't be mounted than wait indefinitely for portmap and give users no clue as to what is going on.
<slangasek> SpamapS: oh, I don't know.  Any filesystems waiting on statd won't mount without it anyway, so I'm not sure it gains us anything
<slangasek> right
<slangasek> but how do you calculate how long is too long?
<SpamapS> slangasek: waiting forever means never triggering filesystem
<SpamapS> slangasek: I am reviewing portmap's code now.. its been carefully written not to depend on much.. so probably "not very long"
<slangasek> still, it's a function of the system speed and of how much else might be running in parallel
<slangasek> I don't have a good way to calculate a worst-case timeout for this
<SpamapS> Well if all it does is exec, and listen.. then even the busiest booting system shouldn't take longer than 5s to pull that off.
<slangasek> if you say so :)
<slangasek> I don't feel strongly enough about it, really; we're obviously well into "that's not event-driven" territory
<SpamapS> I don't want to guess about it either.
<SpamapS> slangasek: indeed :(
<robert_ancell> sladen, I'm not getting the gdm bug, but the last commit in git looks like it might be a good candidate for fixing the applets.  Building with that now
<sladen> robert_ancell: I can reproduce it here and can test things for the next ~3-4 hours
<robert_ancell> sladen, thanks
<SpamapS> slangasek: even more fun, portmap forks then listens .. so there's nothing we can do to completely avoid the race. :-P
<slangasek> SpamapS: hngh
<slangasek> SpamapS: we can fix portmap?
<SpamapS> slangasek: s/nothing/nothing simple/
<slangasek> right :)
<SpamapS> so I'd say just spin for 3 seconds. There is code in portmap that would cause blocking, but none of it is built into the ubuntu or debian portmaps.
<SpamapS> It doesn't lookup hostname, or username, or anything. With our without the fork/listen race.. that window is really, really tiny.
<SpamapS> s/our/or/
<sm> hi all. I used https://wiki.ubuntu.com/Testing/EnableProposed to work around https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/672352 , but the same procedure fails on a user's machine for some reason (config looks good but aptitude doesn't show the package version from -proposed). When is this likely to move from proposed to maverick ?
<ubottu> Ubuntu bug 672352 in eglibc (Ubuntu Maverick) "Assertion `_rtld_global_ro._dl_pagesize != 0' failed" [Undecided,Fix released]
<Keybuk> slangasek, SpamapS: so it'd be good to know when you're done what I need to change to make this much easier ;-)
<slangasek> Keybuk: fixing 'start' to block when the job is already starting would help, of course; there does seem to be a general problem of processes that fork() before listen() not being properly trackable; oh, and fix 'and' :)
<slangasek> SpamapS: btw, bug #525154 was the existing bug on nfs-utils for tracking this; can you merge those other bugs over?
<ubottu> Launchpad bug 525154 in nfs-utils (Ubuntu) "mountall for /var races with rpc.statd" [Undecided,Triaged] https://launchpad.net/bugs/525154
<Keybuk> slangasek: right, ideally you'd want Upstart to not say it was started until it was listening
<Keybuk> though if it's got a fixed socket, would it not be easier to support socket activation for that case?
<slangasek> probably
<Keybuk> (I guess you'd still want both, because you might want to start portmap anyway)
<robert_ancell> sladen, ok, that patch definitely fixed the applet issue.  I've uploaded it to natty, and you can try it from lp:~ubuntu-desktop/gtk/ubuntu if you want to check before the servers have built it
<SpamapS> Keybuk: I do think with portmap, socket activation seems the right way to go. If I start a socket-activated job manually, does upstart's socket activation still handle the listening?
<Keybuk> SpamapS: that's a limitation, right now if you're using socket activation, you cannot start or stop manually
<Keybuk> (err, well, you can stop I guess ;-)
<SpamapS> Keybuk: so if the job file exists, the port is opened?
<SpamapS> slangasek: on bug 525154, ACK
<ubottu> Launchpad bug 525154 in nfs-utils (Ubuntu) "mountall for /var races with rpc.statd" [Undecided,Triaged] https://launchpad.net/bugs/525154
<Keybuk> SpamapS: no, it's entirely separate
<Keybuk> (in 0.6)
<Keybuk> it's even a separate process that does the listening
<Keybuk> so if you started portmap, upstart wouldn't have the socket, and portmap would fail to bind
<SpamapS> Keybuk: given portmap's really fast start times and lightweight nature.. I think that just making it socket activated would be enough.
<Keybuk> well, not just
<Keybuk> there's all that local filesystems /var/lib case, etc.
<SpamapS> Also I can't seem to find the upstart bug that explains the issue with 'start' not waiting for the goal to be reached when its already in progress.
<sladen> robert_ancell: libgtk2.0-0_2.23.3-1ubuntu3_i386.deb appears to fix 693737
<slangasek> Keybuk: related is bug #610863: it would be nice if upstart could notice that the parent process hasn't exited yet, and only mark the job as started once it has
<ubottu> Launchpad bug 610863 in nfs-utils (Ubuntu) "statd job starts before service is listening" [Undecided,New] https://launchpad.net/bugs/610863
<Keybuk> slangasek: *nods*
<slangasek> is there a bug number for that?
<slangasek> or shall I open one?
 * Keybuk makes an LP spooling noise, not unlike LCARS
<Keybuk> slangasek: bug #530779
<ubottu> Launchpad bug 530779 in upstart "init: does not wait for parent to exit when following forks" [Medium,Triaged] https://launchpad.net/bugs/530779
<slangasek> ok :)
<ari-tczew> clipboard to natty doesn't work :/
<ari-tczew> s/to/on
<Keybuk> tbh, I've been having clipboard problems on maverick too
<ari-tczew> Keybuk: I have this problem since last updates
<yofel> yeah, but in natty copy and paste doesn't work at all from gtk apps, not even xclipboard
<ari-tczew> it's makes work useless! (even for Ubuntu development)
<yofel> well, make it copy, I can paste into gtk apps after copying from kde apps
<ari-tczew> where can I report a bug?
<ari-tczew> IMO it's high
<Keybuk> ari-tczew: there's a "Report a Bug" menu option in every Help menu of Ubuntu
<ari-tczew> probably I have to wait to fix in 2nd week of 2011...
<Keybuk> it's natty
<yofel> I'll file it against gtk
<Keybuk> when you install a development distro, you should expect your computer to burst into flames
<ari-tczew> Keybuk: love these talking
<ari-tczew> Keybuk: I'm also making in a piece Ubuntu and this bug is stopping development
<ari-tczew> yofel: are you going to report? because dunno whether shall I do it
<Keybuk> ari-tczew: I tend to run releases on my day-to-day development machines
<Keybuk> and have the development release on a laptop
<Keybuk> that way the big issues don't cause me too much pain
<ari-tczew> Keybuk: cool, welcome in the club
<ari-tczew> Keybuk: are you affected  by this bug as me?
<Keybuk> ari-tczew: as I said, I'm running a release (maverick) on this machine
<Keybuk> so, no
<ari-tczew> Keybuk: so you aren't. well, please stop talking me about risk of running devel distro because I'm aware of this
<Keybuk> ari-tczew: clearly you're not, because you're complaining about a bug in a development distro preventing you from using your computer, and are worried that it won't be fixed during the holidays
<Keybuk> the timescale for *any* Release Critical bug fix for natty, no matter how critical, is "Before The Release"
<Keybuk> any shorter timescale is luck
<yofel> ari-tczew: bug 693737)
<ubottu> Launchpad bug 693737 in gtk+2.0 (Ubuntu) "gtk+2.0 update 2.23.3-1ubuntu2 update triggers repeated gdm greeter crashes" [Critical,Fix committed] https://launchpad.net/bugs/693737
<ari-tczew> Keybuk: I wrote: bug doesn't block only day-to-day using my computer, also blocking Ubuntu development which I could prepare some packages this free time, so I'm not egoist
<yofel> *sigh*
<yofel> bug 693976
<ubottu> Launchpad bug 693976 in gtk+2.0 (Ubuntu) "[natty] Copying to clipboard broken" [Undecided,New] https://launchpad.net/bugs/693976
<ari-tczew> Keybuk: summarizing: if bug is not fixed, Ubuntu can ki$$ my ass because I won't do anything
<Keybuk> ari-tczew: there are plenty of ways to move text around without C&P
<Keybuk> ari-tczew: bend over ;-)
<ari-tczew> Keybuk: yes? which ways?
<Keybuk> ari-tczew: save to text file, read in from text file, etc.
<Keybuk> highlight, :w somefile
<Keybuk> then :r otherfile
<ari-tczew> yofel: I'm not sure whether this is the same bug. I  couldn't copy/paste everything without difference between gtk/qt
<ari-tczew> Keybuk: sorry, it's useless for me
<Keybuk> ari-tczew: then you are a very, very special person
<yofel> well, I'm using KDE and have klipper running and synchronised to xclipboard, under those circumstances, only gtk applications are broken
<Sarvatt> 2x (firefox-bin:30363): Gdk-CRITICAL **: IA__gdk_property_change: assertion `!window || GDK_WINDOW_IS_X11 (window)' failed errors in .xsession-errors every time a copy is performed here
#ubuntu-devel 2010-12-24
<doko> ScottK: please do not *workaround* ld build failures without any notice, and even the workaround was wrong / very questionable
<ScottK> doko: Which one?
<doko> gpgme1.0. are there others?
<ScottK> I don't think I've done any others that way.
<ScottK> doko: You'd rather I fixed the build system instead of just exporting the LDFLAGS?
<doko> yes, or file a bug report and cc me
<doko> and using LDFLAGS for libraries is *wrong*
<ScottK> OK
<ScottK> Won't do it again.
<doko> thanks
<ScottK> In related news, the pth thing has me confused.
<doko> the macro is in the gpgme1.0 package
<ScottK> The reason I thought the problem might be in pth was that when I rebuilt pth, the nature of the error changes.
<ScottK> If you look at the gpgme1.0 build log it complains about something linking related.
<doko> ScottK: we know that we don't want pth, so maybe just disable this autoconf check? I didn't analyze the build failure
<ScottK> doko: If you think that's best, I can do that.
<ScottK> Gotta go.  Airplane is about to land.
<doko> it's not a fix, but a workaround which should work for all archs. subscribe Janimo
<Sarvatt> yofel: pretty sure the fix for the copy/paste bug is http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=120915d6deff
<robert_ancell> sladen, I've uploaded the previous version.  Seems something is still wrong in 2.23.3
<yofel> let me try to apply that
<yofel> ah, that was the ubuntu3 patch
<Sarvatt> yofel, ari-tczew: copy/paste works right ubuntu3 gtk2
<yofel> I'm updating right now
<Keybuk> I love those mailing list threads that start "we all sat down in person and agreed this" and then proceed to turn into 1,000 mails disagreeing
<ari-tczew> Keybuk: do you mean clipboard case?
<Keybuk> ari-tczew: huh?
<ari-tczew> Keybuk: I'm thinking what you mean: [01:27] <Keybuk> I love those mailing list threads that start "we all sat down in person and agreed this" and then proceed to turn into 1,000 mails disagreeing
<Keybuk> oh, no
<Keybuk> there was a thread on the D-Bus Mailing List entitled "User bus conclusion"
<Keybuk> it was a post resulting from an in-person discussion at the Boston GNOME Summit in October
<Keybuk> where they'd hammered out and agreed the way forward
<Keybuk> the thread has about 1,000 mails, all violently disagreeing ;-)
<Keybuk> and I'm pretty sure everyone who agreed in that thread broke ranks along the way too
<ari-tczew> okok
<Laney> found it
<Laney> -ECHAN
<Keybuk> Laney: lost it ;-)
<Keybuk> err, all agreed at that meeting, broke rangs along the way in the thraed
<ari-tczew> yofel: and? did you update system?
<yofel> see +1
<yofel> ah, you're not there..
<ari-tczew> hmmmm?
<ari-tczew> please, I'm only human
<yofel> with ubuntu3 all gtk apps work fine *except* firefox and thunderbird, those crash as soon as I select something now
<yofel> ari-tczew: I posted that in #ubuntu+1 already
<ari-tczew> yofel: is restart necessary?
<yofel> I logged out
<ari-tczew> ok thanks
<ebroder> Keybuk: Was there any useful conclusion from that thread? I'm conceptually interested in what they're arguing about, but not interested enough to read past message, oh, I don't know, 2
<ari-tczew> could any archive admin unsubscribe team from bug 693982 ?
<ubottu> Launchpad bug 693982 in postgrey (Ubuntu) "Sync postgrey 1.32-6 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/693982
<kees> does anything actually delete the /var/cache/apt-xapian-index directories?
<jdstrand> hallyn, apw: fyi-- I have a reproducer (though convoluted) for my natty/kvm issues that I mentioned yesterday and I just filed bug #694029
<ubottu> Launchpad bug 694029 in qemu-kvm (Ubuntu) "[natty] kvm guests become unstable after a while" [Undecided,New] https://launchpad.net/bugs/694029
 * jdstrand heads out
<nullslash> Hello?
<iulian> Morning.
<nullslash> Hello World
<nullslash> Is anyone here is alive ?
<iulian> Probably.  I can't say for sure.
<jelmer_> doko_: hi
<doko_> jelmer_: hi
<jelmer_> doko_: Sorry for the interruption, I think I found what I was looking for.
<jelmer_> doko_: one of the changes that's cherrypicked by the latest python2.7 upload breaks bzr
<doko_> jelmer_: no cherrypicking, just the branch
<doko_> jelmer_: which package version does work for you?
<jelmer_> doko_: ah, ok. Either way, it's a bzr bug not a Python bug so this is something that we can fix in Bazaar.
<doko_> ok
<jelmer_> doko_: 2.7.1-1ubuntu4 works
<jelmer_> 2.7.1-2 uses an argument to readline() in one of the http functions, and the file-like object Bazaar passes in doesn't support an argument to its readline().
<doko_> jelmer_: that's the fix for Issue #6791
<doko_> r87383
<jelmer_> ah, thanks
<shadeslayer> isnt there a apt sources line which automatically chooses a ubuntu mirror for you?
<Nece228> hi
<Nece228> i want to know
<Nece228> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/665546
<ubottu> Ubuntu bug 665546 in xorg-server (Ubuntu) "Drop and sub menus don't always show up" [Undecided,New]
<Nece228> why this bug still doesnt have any attention?
<Nece228> i know this is issue with xorg-server 1.9
<Nece228> but arch linux in aur has package which fix this issue
<Nece228> and actually as i see xorg-server 1.9.3 fixes this issue
<charlie-tca> shadeslayer: I don't how to do it from command line, but if you open Synaptic Package Manager, Settings, Repositories, Download from ...    Other
<charlie-tca> there will be a button to pick the best server
<shadeslayer> charlie-tca: no not that
<shadeslayer> mvo told me about a custom deb line which automatically figures out servers
<shadeslayer>  also this : http://paste.ubuntu.com/547268
<shadeslayer> seems a) on upgrade flash is removed and b) when you install flash apt-get goes wonky
<juliank> shadeslayer: APT is happy, there's a bug in nspluginwrapper
<shadeslayer> juliank: ah .. so is the package fixed? or a WIP?
<juliank> shadeslayer: I just read your log, and there is a segfault when running the postinst script of nspluginwrapper, so there is a bug there; but it may be that it is yet to be reported
<shadeslayer> ohk .. ill report one then
<shadeslayer> juliank: bug 694137
<ubottu> Launchpad bug 694137 in nspluginwrapper (Ubuntu) "nspluginwrapper 1.22-0ubuntu8 fails to install on natty" [Undecided,New] https://launchpad.net/bugs/694137
<cjwatson> kees: quit panicking about tor - it was nothing to do with autosyncs, tor was a manual sync.  it's done now.
<cjwatson> micahg: the last huge autosync will be on 30 Dec
<cjwatson> per https://wiki.ubuntu.com/NattyReleaseSchedule
<psusi> cjwatson, fyi the last day or two daily livecds have had plymouth breakage for me.  sometimes it doesn't show the logo until just before x takes over, sometimes it makes the monitor switch into standby until x takes over
<psusi> and sometimes the kernel hard hangs... even magic sysrq doesn't work
<cjwatson> psusi: I'm not going to look at plymouth at all until the new year
<cjwatson> so no point telling me now :)
<cjwatson> I'll just forget
<psusi> k... just thought you might know of a recent change that probably did it so I wanted to let you know now before it gets burried under other changes
<cjwatson> I'm not going to look at it on Christmas Eve, sorry
<psusi> sure.. just mental note about when the breakage happened ;)
<cjwatson> no mental note will survive Christmas
<psusi> lol
<cjwatson> if you want anything remembered, file abug
<cjwatson> *a bug
<psusi> hrm.... ok
<Sarvatt> cjwatson, psusi: probably this one https://bugs.launchpad.net/bugs/693093
<ubottu> Ubuntu bug 693093 in linux (Ubuntu) "[i945gme] 2.6.37-10.24: Black Screen on Boot" [High,Confirmed]
<micahg> cjwatson: ok, wasn't sure if someone was going to be around for that, thanks
<micahg> cjwatson: have a good holiday weekend :)
<cjwatson> I intend to, thanks
#ubuntu-devel 2010-12-25
<cdbs> Merry Christmas!
<akshatj> merry christmas cdbs
<cdbs> akshatj: same to you
* cdbs changed the topic of #ubuntu-devel to: Archive: Open | Most developers are off-work for Christmas, please be patient on queries | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current F
<cdbs> err, topic is too long
* cdbs changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<ari-tczew> we have to exert pressures on Debian to pack latest bzr release to fix ardous bug 693880
<ubottu> Launchpad bug 693880 in bzr (Ubuntu) "_ReportingFileSocket.readline lacks size argument" [Undecided,New] https://launchpad.net/bugs/693880
<kees> cjwatson: didn't mean to "panic", I just couldn't figure out what state it was in. no worries, and thanks!
<p_kasia_> HI, I need help I have no sound and no sound volume control any help how to solve it ? I just upgraded to 10.10 ? Anyone have any ideas why the sound is not working in Ubuntu ?
<crimsun> p_kasia_: wrong channel, but please see https://wiki.ubuntu.com/Audio
<Keybuk> Merry Xmas :-)
#ubuntu-devel 2010-12-26
<ari-tczew> please open a task for natty in bug 693880
<ubottu> Launchpad bug 693880 in bzr (Ubuntu) "_ReportingFileSocket.readline lacks size argument" [Critical,Confirmed] https://launchpad.net/bugs/693880
<Martiini> Im doing  - aptitude dist-upgrade .. and I get .. python2.7-minimal
<Martiini> E: Sub-process /usr/bin/dpkg returned an error code  E: pycompile:240: Requested versions are not installed
<Martiini> how do I get past that python2.7 install error
<Martiini> ah .. I need to edit /usr/share/python/debpython/version.py
<micahg> Martiini: maybe check in #ubuntu+1 to see if anyone else has seen the upgrade issue
<Martiini> ehm .. tbh, ubuntuforums.org has a thread about it .. and I just had it fixed .. Im watching it upgrade now
<Martiini> micahg,  what is #ubuntu+1
<micahg> Martiini: natty support channel
<Martiini> ok, correct ..
<Martiini> micahg, are YOu in USa
<micahg> Martiini: yes
<Martiini> where in USa
<Martiini> some people in USA work on ubuntu it seems
<Martiini> Micah Gersten .. sounds german
<Martiini> micahg, ooh, You work for canonical ? , says google
<micahg> Martiini: huh?
<Martiini> https://launchpad.net/~micahg
<Martiini> Im doing some spying work on your profile
<micahg> Martiini: there's nothing in there about Canonical
<Martiini> Chicago .. is where You are located right now ?
<micahg> Martiini: this is mainly a development channel, if you'd like to chat about Chicago, there's #ubuntu-chicago
<Martiini> micahg, ×× ×©××××?
<Martiini> ×××× ××ª×?
<highvoltage> mdz: I accidentally lost/trashed a swap partition twice. both times the load averages went to 3.33/3.33/3.33 and stayed there. did that happen to you too?
<penguin42> highvoltage: Was that on a laptop that hibernated?
<highvoltage> penguin42: the one time it was on suspend, whan swap was on an sd card and the sd card reader didn't come up in time
<penguin42> highvoltage: I ask because there was some weirdness with swap/hibernate signatures going on recently
<mdz> highvoltage, so far it is humming along like nothing happened. it is a machine I'm decommissioning, so not too much is going on
#ubuntu-devel 2011-12-19
<micahg> pitti: so, I finally got Firefox uploaded, it's building on i386 now, should be done in ~2 hrs, I think the other archs should be ready to copy to -proposed in ~7-9 hours, I'll be back in ~7hrs
<pitti> Good morning
<pitti> micahg: ah, nice; the langpacks are ready for upload as well
<pitti> micahg: so I'll upload them when we copy firefox to -proposed from the PPA
<micahg> pitti: ok, I'll check on it when I wake up (early morning for DMB Meeting :))
<dholbach> good morning
<pitti> jibel: the server ISOs built and have no uninstallability; https://jenkins.qa.ubuntu.com/view/Precise/job/precise-server-amd64_default/lastFailedBuild/console looks like a problem in the test system itself?
<pitti> jibel: or is there something wrong with the cdimage publishing/checksums generation?
<pitti> oh, holiday
<pitti> ScottK, Riddell: kalgebra doesn't build kalgebra-dev any more; the changelog makes this look like an accident/merge error instead of deliberate? (it's needed by cantor)
<pitti> in http://launchpadlibrarian.net/87670525/kalgebra_4%3A4.7.3-0ubuntu1_4%3A4.7.90-0ubuntu2.diff.gz
<pitti> it also dropped libanalitza4 and -dev
<pitti> gema: good morning, how are you?
<gema> pitti: hello, I am good, you?
<pitti> gema: I'm great, thanks!
<pitti> gema: jibel and jamespage are on vacation now, and it seems that the server ISO tests are broken (looks like a bug in the test setup)
<pitti> gema: do you know if anyone jenkins-literate is still available in your team?
<pitti> https://jenkins.qa.ubuntu.com/view/Precise/job/precise-server-amd64_default/lastFailedBuild/console
<pitti> I can't make any sense of this, I'm afraid :(
<pitti> internal error process exited while connecting to monitor: chardev: opening backend "file" failed
<gema> pitti: patrick will be working later today, but we've created a wiki that should help us figure out what is wrong
<gema> pitti: let me pull it out
<gema> pitti: I am going to have a look using this: https://wiki.ubuntu.com/QATeam/AutomatedTesting/UnderstandingJenkinsResults
<pitti> gema: right, but it doesn't have any existing "infrastructure failure conditions"
<gema> pitti: then why is it failing?
<pitti> gema: I don't know :) the ISO is present and working
<pitti> I pasted the error message above
<gema> pitti: give me 5 mins to  have a look , I have been trying to learn about it, now seems like a good time to test what I learnt
<pitti> it's not something from the server ISO itself, it doesn't even start booting it apparently
<pitti> gema: ah, heh
<pitti> gema: well, on the bright side, Rick is now _also_ on holiday, so he will hopefully not look at jenkins today and get another heart attack :)
<gema> pitti: larry and pete were in Lex last week adding machines to the lab, maybe something was left in the wrong state
<gema> pitti: haha
<gema> pitti: everything's red, not just server
<pitti> gema: I think this problem has just one clean solution: let's just go to holidays as well :)
<stgraber> :)
<gema> pitti: sounds good to me, actually, if I had any days left :P
<pitti> gema: ah, indeed, just refreshed; I suppose an hour ago the desktops etc. didn't start testing yet
 * pitti has his last official day today
<pitti> mission: inbox zero
<gema> pitti: select all -> mark as read, works wonderfully
<gema> :P
<hrw> smoser: can grub-legacy-ec2 provide grub? This way Xen/cloud instances will not get grub-pc installed (as it is recommended by kernel: grub-pc|grub|lilo).
<gema> pitti: the virsh start command seems to have failed, so something is wrong with the VMs (I think)
<Chipzz> pitti: last day of the year, or moving on to greener pastures?
<pitti> Chipzz: just EOY vacation
<pitti> Chipzz: will be back on Jan 3
<Chipzz> pitti: ah k :)
<Chipzz> have a nice and relaxing vacation then :)
<pitti> Chipzz: thanks! I guess you'll have some as well?
<Chipzz> pitti: I started mine over a week ago :)
<Chipzz> pitti: had a lot of unspent vacation which I all took in December
<Chipzz> I use public transportation to go to work, and since December usually is way too cold for my taste, that happens to work pretty well :)
<gema> pitti, Chipzz: spotify with Christmas carols will have to do for me until Wed evening... :(
<pitti> heh
<gema> pitti: did you do anything to jenkins?
<pitti> gema: FTR, I only see the R/O frontend, I can't actually "do" anything to it
<gema> pitti: ok, I thought you had access :)
<pitti> meh, seems everytime we do an auto-sync from Debian we import gazillions of NBS
 * pitti catching up
<dholbach> did anybody else run into bug 906248?
<ubottu> Launchpad bug 906248 in python3.2 (Ubuntu) "package python3.2-minimal 3.2.2-2 failed to install/upgrade: Versuch, Â»/usr/bin/python3Â« zu Ã¼berschreiben, welches auch in Paket python3-minimal 3.2.2-0ubuntu2 ist" [Undecided,New] https://launchpad.net/bugs/906248
<pitti> doko: ^ missing B/R:?
<pitti> although I guess /usr/bin/python3 is supposed to be in -minimal, not in python3.2
<cjwatson> should be, yes
<doko> pitti, my bad, should be in the udeb. will fix
<pitti> doko: thanks
<pitti> so, what the heck is the libverto build complaining about (depwait on libev-dev); we have that since lucid
<pitti> oh, nevermind; someone NEWed it to main, putting back to universe
<apw> dholbach, /me just hit it too
 * apw wonders if a fixed version will fix this this up or if manual intervention is required
<doko> pitti, needs manual intervention :-/
<pitti> doko: why? the next upload will just drop the file and should install again?
<doko> pitti: because b-d's are not installable. let me try something
<pitti> doko: oh, does it b-dep on itself?
<doko> pitti, lsb_release depends on python3
<pitti> oh; so we could temporarily switch that back to py2, build py3 with that, and switch to py3 again?
<cjwatson> hm, ubiquity seems to fail on today's ISO image; did jenkins not catch that?
<pitti> (yay for 30 minute publisher cycles)
<doko> no, avoiding lsb-release in the python3 build
<pitti> cjwatson: no, all the autotests ran fine
<cjwatson> odd
<pitti> cjwatson: perhaps because it's using pre-seeding and avoids some UI? does the UI crash or the logic?
<cjwatson> somewhere in between; it's possible that a preseeded install would avoid this though, yes
<cjwatson> anyway, looking into it now
<apw> cjwatson, do we have somewhere to file bugs against the QA jenkins tests?  seems we should "failed to catch this regression"
<pitti> I think gema mentioned that she wanted to file a bug against the jenkins tests
<pitti> gema: ^ is there a specific LP project for this?
<cjwatson> it's something non-Unicode somewhere in the language list
<pitti> cjwatson: oh, sounds like bug 905429
<ubottu> Launchpad bug 905429 in language-selector (Ubuntu Precise) "gnome-language-selector crashed with ValueError in _build_localename(): too many values to unpack" [High,Fix released] https://launchpad.net/bugs/905429
<pitti> cjwatson: something in pygobject changed to return unicode, but setlocale() doesn't like that
<pitti> http://bugs.python.org/issue3067
<cjwatson> could be yes
<cjwatson> not convinced though
<pitti> I worked around it in language-selector by .encode('UTF-8') in the setlocale() call
<cjwatson> it's nowhere near a setlocale call
<pitti> ok
<doko> pitti: ok, building
<doko> Laney, some more haskell packages will build once the kernel with bug 861296 fixed is on the buildds. checked with haskell-src-exts
<ubottu> Launchpad bug 861296 in linux-ac100 (Ubuntu Precise) "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Confirmed] https://launchpad.net/bugs/861296
<Laney> oh awesome
 * Laney subscribes
<cjwatson> pitti: I think I just need a "make sure this is unicode if it isn't already" helper everywhere
<cjwatson> rather than assuming it's str and using .decode
<Laney> ah, no task which would tell me that
<gema> pitti: we have a project ongoing with the community to add test cases from bugs into our regression suit
<cjwatson> wouldn't surprise me if this showed up elsewhere mind you
<gema> pitti: depending on the problem, it wouldn't be ISO testing but more generic type of testing
<gema> pitti: but language selector sounds like daily iso , agreed
<gema> pitti: I believe that the project would be https://launchpad.net/ubuntu-server-iso-testing
<pitti> gema: no, I meant for "it didn't catch the ubiquity failure"
<pitti> cjwatson: calling encode() on a str should be a no-op, though
<gema> pitti, add the bug against that project, tag it with qa-test-code and we will look into it
<pitti> cjwatson: ah, no, it's not; sorry
<Riddell> pitti: it as an accident to upload it yet but analitza has been split out and I'll fix it later today
<pitti> Riddell: ah, thanks
<pitti> apw: btw, is linux-meta in git anywhere? IOW, if there's an ABI bump, could someone like me just upload the corresponding -meta after binNEWing the kernel, or should we always bug you guys?
<pitti> apw: (waiting for the armel build still)
<apw> pitti, its in our git repos, i've already reved it for the -6, its not all built yet though is it
<pitti> apw: ah, ok; so "bug you guys" it is :)
<pitti> apw: no, armel will need another 3 hours
<apw> pitti, its one we can cope with at least if its done by you just about, we've had one or two done by AAs in the past
<apw> pitti, we are usually waiting on tenta-hooks for it to complete
<mr_pouit> pitti: mmh, micahg and I had hoped to stick to abiword 2.8.x for precise (for xubuntu), as 2.9.x is a development branch...
<pitti> mr_pouit: hm, it's in Debian testing; the new one doesn't depend on the NBS gucharmap any more
<pitti> mr_pouit: but if that was wrong, I can also roll it back to 2.8, and see whether that one works without gucharmap
<pitti> will be back later, just off to lunch, but will read scrollback
<pitti> mr_pouit: sorry, I wasn't aware that you wanted to say at 2.8
<mr_pouit> well, we didn't advertise it at all, so you couldn't have guessed ;-)
<apw> doko, you will be pleased to hear that and update as of now the python3 thing seems resolved, and following the onscreen prompts seems to have installed it without other human intervestion
<mr_pouit> pitti: I'll rediscuss with micahg, and the xubuntu testers to see if 2.9.x fixes lots of issues present in 2.8.x, so no hurry
<Thomas_Jaszok> Hello,
<Thomas_Jaszok> I'm studding "economy and computer since" and I'm nearly finished with my studies.
<Thomas_Jaszok> I would like to write about the working plan and the business process of Ubuntu and wanted to ask you if I somebody would have some time for a small Interview
<smoser> hrw, we actually want the cloud-images to have grub-pc installed.
<smoser> without it they would not function in kvm
<hrw> smoser: xen ones do not need it - they are fine with grub-legacy-ec2
<smoser> hrw, well, yes. but the cloud-images "just work" on xen or kvm. so having "provides" would break that.
<smoser> perhaps there could be another itility that *did* provide that, and possibly it could depend on grub-legacy-ec2.
<smoser> but i am hesitant to build thinkgs on grub-legacy-ec2, when i think the right solution is to get "pv-grub2"
<hrw> smoser: ok
<smoser> if you were nice enough to cjwatson, he might comment, and maybe even do the pv-grub2 work for you .
<smoser> but i've failed to be so nice.
<smoser> (he has mentioned that he understands what would have to be done there)
<cjwatson> there was a patch posted upstream recently
<cjwatson> I don't know how complete or, er, productised it is
<cjwatson> (haven't had a chance to read over it)
<smoser> ah. thanks cjwatson.
<smoser> hrw, for reference http://lists.gnu.org/archive/html/grub-devel/2011-11/msg00088.html
<hrw> thx
<hrw> smoser: will stay with pygrub for now - works fine.
<smoser> hrw, but we coul definitely consider something else providing "grub" that was that.
<hrw> smoser: ok, just wanted to know opinion
<hrw> smoser: I remember day when I did lucid-maverick-natty upgrade and ended with nonbooting system. learnt more then needed on xen, xen console stuff
<apw> pitti, we have a kernel waiting to be copied out to -proposed which appears to have been there since the 14th, what triggers that, is it manual?
<pitti> apw: just slipped attention, I guess; I'll do the outstanding stuff now
<micahg> pitti: why did you sync abiword 2.9.1, I had a note on MoM not to sync it
<pitti> micahg: I merged with Debian (well, was a sync) as the current one still needed the libgucharmap gtk2 libs which are gone now
<pitti> micahg: see discussion with mr_pouit from an hour ago
<apw> pitti, thanks
<pitti> micahg: mr_pouit | pitti: I'll rediscuss with micahg, and the xubuntu testers to see if 2.9.x fixes lots of
<pitti> ... issues present in 2.8.x, so no hurry
<pitti> micahg: in response to "want me to roll back"
<micahg> pitti: ah, silly freenode dropped me :)
<micahg> pitti: so  I missed it, thanks
<pitti> but then we need to figure out how to build it without gucharmap
<pitti> (probably not that hard, though)
<micahg> pitti: well, we're stuck with GTK2 in Xfce land, but as abiword/pyabiword are the only rdepends, I have trouble keeping the lib around just for that, but if 2.9.1 is crashy, I'd suggest doing just that, but will follow up with the xubuntu team
<pitti> micahg: right
<apw> doko, ok the oneiric/ti-omap4 is in proposed now, which has the fixes you wanted; that should cover the newer buildds at least
<dobey> pitti: btw, some of the apport hookutils seem to be broken, and import static bindings
<pitti> dobey: oh, which?
<pitti> from gi.repository import Gio, GLib
<dobey> pitti: at least the gconf one anyway; it imports gconf/glib static bindings
<pitti> dobey: oh, that's gone in precise
<pitti> dobey: attach_gconf() is a no-op now and the import is gone
<pitti> dobey: attach_gsettings_schema() is the new kid in town
<dobey> oh; so the banshee apport hook is just broken in precise now :)
<dobey> and broken in oneiric because of the imports :)
<pitti> dobey: broken because it doesn't collect gconf data?
<dobey> pitti: broken because the hook expects it to, and it now doesn't, in precise, yeah
<micahg> pitti: if you have time, could you look at bug 906110, it fixes a depwait
<ubottu> Launchpad bug 906110 in python-cogent (Ubuntu) "Please move python-cogent to universe" [Wishlist,Confirmed] https://launchpad.net/bugs/906110
<dobey> pitti: someone was just asking about a problem reporting a bug against banshee in oneiric in #launchpad, and i asked him to report this bug against apport; and do a work around to file his bug against banshee
<ScottK> pitti: kalgebra was uploaded to the archive by accident.  It was meant to go to a PPA for now, but it'll be in the archive eventually and it'll all be OK, so I think it's best to just leave it for now.
<pitti> zul, Daviey: the nova upload in -proposed is a bit hard for trackign -- almost all of the referenced bugs only have an upstream task, and there is no meta-bug for tracking verification; any idea how this should be done?
<pitti> ScottK: right, will do
<pitti> zul, Daviey: I'll accept it for now to unblock testing, but I guess for the next update we need something like the kernel guys do with their tracking bugs
<zul> pitti: the SRU tracking one is: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/901710 (however can you reject the horizon package, there is a couple of things i want to do to it)
<ubottu> Ubuntu bug 901710 in nova (Ubuntu) "[SRU] Meta SRU for openstack updates" [High,New]
<zul> pitti: how does the kernel guys do it?
<pitti> zul: they create a metabug for each new release which documents the current status and testing, like in bug 899339
<ubottu> Launchpad bug 899339 in linux (Ubuntu Lucid) "linux: 2.6.32-37.81 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/899339
<doko> apw, \o/
<doko> lamont, any chance to get these installed on the buildds?
<jdstrand> pitti: hi! fyi, got your canned 'moved to -proposed/verification-needed' comment in 868360. this is already fix released and there are no nova packages in -proposed. fyi in case of script error
<pitti> jdstrand: I just accepted it maybe 30 mins ago, it should turn up on the mirrors soon?
<pitti> hmm, /me checks LP, where did it go?
<jdstrand> pitti: ok. thing is, I did a security update for that bug last month. not sure why it was on your report
<jdstrand> ah, it was closer to 2 months ago
<jdstrand> http://www.ubuntu.com/usn/usn-1247-1/
<jdstrand> anyhoo, no worries on my end. only fyi
<lamont> doko: we don't have any buildds that run 2.6.32, other than arm and ppc
<lamont> or were you referring to the l/m/n omap/4 kernels?
<micahg> pitti: still another 2-4 hrs to go before the firefox copy for lucid (powerpc is behind), maverick is still waiting on powerpc as well, I'm fine with both happening tomorrow if you want
<lamont> doko: in any case, it will happen in the normal course of things, once they show up in -security or -updates
<pitti> micahg: sure, WFM
<pitti> jdstrand: https://launchpad.net/ubuntu/+source/nova/+publishinghistory has it, t hough
<jdstrand> pitti: ok, so 6.2 is what 868360 is referring to. that was fixed in Oct. 6.3 (http://www.ubuntu.com/usn/usn-1305-1/) was a different security update, which also shouldn't have gone through -proposed or gotten the verification-needed comment.
<jdstrand> pitti: neither 6.2 or 6.3 went through -proposed and 868360 was already fix released, which is why I thought the verification-needed bug update was odd
<pitti> jdstrand: well, the whole update is a bit weird -- pretty much all of the bugs are upstream tasks only, cf. my question to zul/Daviey an hour ago
<jdstrand> pitti: ok. I see that https://launchpad.net/ubuntu/oneiric/+source/nova/2011.3+git20111117-0ubuntu1 does reference that bug, which must be why it was on your list
 * jdstrand didn't see that one before
<jdstrand> I guess the server team should verify that bug doesn't regress...
<jdstrand> anyhoo, I let you guys handle that
<pitti> yes, this is the first trial run of a microrelease exception proposal
<pitti> they now need to throw lots of test suites at that
<pitti> apw: kernel built now, binNEWed, so you can go ahead with l-meta
<pitti> apw: I'll update seeds and d-i
<apw> pitti, thanks
<apw> pitti, uploaded
<jasox> I just compiled vim with qt gui http://code.google.com/p/vim-qt/wiki/Packages. It works perfectly, better than gvim. I am wondering would anyone help me to make package for ubuntu, I never try to make packages for any linux distro.
<doko> pitti, you libverto MIR ... libverto can be built against libevent as well, which already is in main
<pitti> oh, nice!
<doko> I don't know which one is better suited
<micahg> pitti: have you seen Bug #905389?
<ubottu> Launchpad bug 905389 in language-pack-sv-base (Ubuntu) "Depedency problem in lucid-updates: language-pack-sv-base requires proposed version of language-pack-sv" [Undecided,New] https://launchpad.net/bugs/905389
<pitti> micahg: oh, I thought I already caught them all
<pitti> micahg: right, I see it on http://people.canonical.com/~ubuntu-archive/testing/lucid-updates_probs.html; will fix asap
<doko> Sweetshark, how stable is graphite2? if we backport newer lo versions, won't we have to enable the internal copy anyway?
<doko> then we'll have two different graphite versions to maintain :-/
<porthose> pitti, would it be ok to do the debian-med-1.10 merge?
<pitti> porthose: you mean you want me to do it, or you want to do it?
<pitti> porthose: (I won't have time any more today, need to run in about 10 mins)
<porthose> me :)
<pitti> porthose: ah, thanks; I have no personal relationship to the package, I just fixed installability a while ago
<porthose> ok cool
<Sweetshark> doko: yes, anyway one does it, one loses. :/
<pitti> cjwatson: can I just move gnome-{panel,applets} from "ubuntu-desktop" to "desktop-extra" set? I suppose ubuntu-desktop is just because it once was in the ubuntu seeds? (they are in universe now)
<pitti> cjwatson: or is that also a case where manual changes won't stick?
<pitti> Laney, jbicha ^ Cc:
<Laney> ty
<Laney> I am under the impression that ubuntu-desktop is fully automatic, i.e. some external change will need to happen to make the packages drop out
<Laney> but maybe it is just semi automatic
<pitti> this part has always been a bit magic to me
<cjwatson> pitti: ubuntu-desktop changes you make won't stick - see lp:~cjwatson/+junk/packageset
<cjwatson> pitti: feel free to add it to desktop-extra though
<cjwatson> that's not one I manage
<Laney> it should be dropped out of ubuntu-desktop first
<cjwatson> it apparently already has
<pitti> cjwatson: ah, so it should just be dropped from" exceptions" then?
<cjwatson> er, oh
<cjwatson> yeah, probably, let me do that ...
<pitti> $ edit_acl.py -s gnome-panel query
<pitti> Archive Upload Rights for ubuntu-desktop: archive 'primary', package set 'ubuntu-desktop' in precise
<pitti> cjwatson: want a MP?
<cjwatson> no
<cjwatson> easier to JFDI :)
<pitti> cjwatson: ok, thanks
<Laney> panel and applets
<cjwatson> done
<pitti> cjwatson: indicator-applet as well (it doesn't exist any more)
<pitti> cjwatson: cheers
<cjwatson> also done
<jono> is anyone having any issues with wireless dropping off the network in Precise?
<jono> over the last few hours I have had a number of drop-outs where I seem to stay connected to the LAN but there no net access, when I reset the connection (by flipping the hardware wireless card switch) I get back online and everything is fine
<jono> I wasn't sure if this has been reported recently
<tgardner> how do I resolve python3 v.s. python3.2 interdependency issues ?
<tgardner> Preparing to replace python3.2-minimal 3.2.2-1build1 (using .../python3.2-minimal_3.2.2-2ubuntu1_amd64.deb) ...
<tgardner> Unpacking replacement python3.2-minimal ...
<tgardner> dpkg: error processing /var/cache/apt/archives/python3.2-minimal_3.2.2-2ubuntu1_amd64.deb (--unpack):
<tgardner>  trying to overwrite '/usr/bin/python3', which is also in package python3-minimal 3.2.2-0ubuntu2
<cjwatson> put it on hold for now - doko is aware
<tgardner> ack
<cjwatson> (dpkg --force-overwrite is possible but probably not a good idea in this case because the file is actually supposed to be in python3-minimal not python3.2-minimal
<cjwatson> )
<cjwatson> I think https://launchpad.net/ubuntu/+source/python3.2/3.2.2-2ubuntu2 plus https://launchpad.net/ubuntu/+source/python3.2/3.2.2-2ubuntu3 should fix it
<tgardner> I'll give 'em a try. its a test server anyway
<cjwatson> yeah, looks like it
<doko> tgardner, should resolve itself with the updated packages
<tgardner> doko,  I pulled python3.2/3.2.2-2ubuntu3. now all is well.
<ManDay> I need to know how you make GCC work on a multilib system? Do you put the PATHs into the enviroment or is there something that I can set on Buildtime so that it finds ./x86_64-gnu-linux ?
<ManDay> j #workingset
<ManDay> Did you understand my question?
<smoser> could someone take a read of bug 905419 ?
<ubottu> Launchpad bug 905419 in rsyslog (Ubuntu) "cloud-init messages going to syslog, not cloud-init.log" [Medium,Confirmed] https://launchpad.net/bugs/905419
<smoser> to me, this seems like a regression between rsyslog 5.8.1 and 5.8.6.  at very least it is a change in behavior.
<smoser> i'll raise it upstream, but i'd appreciate if someone familiar with syslog and/or python logging (and syslog) could tell me here if its just my (or python logging) misuse of syslog.
<Ampelbein> Hi there! Is Ubuntu planning on using gnutls 3.0 ("gnutls28") for PP or stay on gnutls26 for the LTS?
<mvo> RAOF: hey, good morning! the SRU verification for bug #905413 is done now, could this package please be moved to oneiric-updates? (for the app-install-data-partner packages we waive the 7 days aging requirement)
<ubottu> Launchpad bug 905413 in app-install-data-partner (Ubuntu Natty) "SRU for vmware-view" [Undecided,New] https://launchpad.net/bugs/905413
#ubuntu-devel 2011-12-20
<ScottK> pitti: Looking at http://people.canonical.com/~ubuntu-archive/pending-sru.html is seems that the KDE SC 4.7.3 SRU only got partially copied over.  A big chunk of them are in -updates, but all the ones listed against bug #901975  should have been copied together.  Not sure what happened.
<ubottu> Launchpad bug 901975 in kde4libs (Ubuntu Oneiric) "Tracking bug for KDE application updates for 4.7.3" [Undecided,Fix committed] https://launchpad.net/bugs/901975
<RAOF> ScottK: I'm not sure pitti's here; can I do anything to help?  I was planning on running through the SRUs before ending the day; it looks like all the ones you're concerned about should be picked up in my normal processing?
<ScottK> RAOF: The concern I have is that it looks like half of KDE got moved and half didn't.
<ScottK> I doubt it will cause a problem, but it was tested together, so it's better, IMO, to get it all moved as close to one time as possible.
<RAOF> So, that's easily resolved by me moving the other half, plus the language packs, right?
<ScottK> Yes.
<ScottK> RAOF: Thanks for looking into it.  I'm off to bed.
<RAOF> No problem.
<RAOF> l10n done.
<jbicha> anyone want to rebuild gnome-shell for oneiric (bug 903382)? my upload rights aren't sufficient for that :(
<ubottu> Launchpad bug 903382 in gnome-shell (Ubuntu) "[powerpc] Unsatisfiable dependency in oneiric" [Undecided,Confirmed] https://launchpad.net/bugs/903382
<broder> jbicha: just a no-change rebuild to oneiric-proposed? i can do that
<jbicha> broder: yes, thank you!
<micahg> jbicha: can you merge gnome-shell from Debian so there are no more issues please :)
<broder> jbicha: done. i've opened an oneiric task as well so you can target things appropriately
<pitti> Good morning
<pitti> ScottK: uh, sorry, I thought I caught them all; looking
<pitti> ScottK: I see four which are missing; I guess they again timed out and I missed them; copied now
<pitti> wow, https://jenkins.qa.ubuntu.com/view/Precise/ looks great today
<pitti> now, nobody break anything over the holidays :)
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<pitti> infinity, lamont: FYI, I'm uploading new natty-proposed langpacks; I temporarily switched allspice and crested to i386 and updated the notes/description accordingly
<pitti> will switch back once the flood is over
<pitti> (or if we get a lot of other uploads which need amd64)
<pitti> infinity, lamont: ah, nevermind, we copy binaries from the PPA these days, switching back
<Laney> pitti: that email was interesting, thanks!
<pitti> Laney: I'm glad it is; took me over an hour to write, after all :)
<pitti> Laney: now that I've been through it I wonder how we did that in the past
<Laney> sweating blood around milestones? :-)
<pitti> well, partially it was spread over all developers, but for the most part we simply ignored them
<Laney> also ignoring stuff, yes
<pitti> and then taking the mass removal club before release time, yes
<cjwatson> pitti: thanks, indeed!
<cjwatson> Laney: can I remove the ghc-ghci r(b)deps on armel/armhf/powerpc?
<cjwatson> binaries, I mean
<cjwatson> I think that would clean up http://people.canonical.com/~ubuntu-archive/transitions/ghc.html somewhat
<Laney> if they no longer build, then yes please
<Laney> are built* â I was going to ask for that at some point
<cjwatson> haskell-clientsession haskell-convertible-text haskell-data-accessor-template haskell-file-embed haskell-hamlet haskell-haxr haskell-hledger-web haskell-path-pieces haskell-quickcheck haskell-syb-with-class haskell-type-level haskell-web-routes-quasi
<cjwatson> is the list, I believe
<cjwatson> oh, maybe not haskell-quickcheck
<dantti> cnd: ping
<cjwatson> actually it looks like just haskell-clientsession haskell-file-embed
<Laney> not sure which of the list has OOD binaries
<cjwatson> just those two by the looks of things
<cjwatson> done now
<cjwatson> (and only on powerpc)
<cjwatson> hm, may be some others for other reasons though
<Laney> bbs
<cjwatson> ah yes, I need to hit checkrdepends recursively
<mok0> ls
<ScottK> pitti: Thanks.
<cjwatson> ... that doesn't yield any more packages to remove, though, so good
<mok0> Who is familiar with Mesa?
<mok0> ... or rather mesa-glw
<ajmitch> pitti: great writeup in that email :)
<mok0> In Debian, the package libglw-mesa comes from source package mesa_7.11.2-1, but in Ubuntu it comes from source package mesa-glw. What is the reason for this?
<mok0> The package provides the library libGLw.so, which is broken on Ubuntu
<mok0> but fixed in Debian Re: BTS #624156
<mok0> I also see that Ubuntu has its own version of mesa: 7.11-0ubuntu4
<TiMiDo> hi guy's
<TiMiDo> good Morning
<ogra> mok0, try #ubuntu-x
<mok0> ogra, thx, I will
<ogra> just guessing, but its probably a universe/main issue that there is a separate source package
<TiMiDo> python 2.7 sure look nice ;)
<TiMiDo> very powerful
<mok0> TiMiDo: What makes you say that? Very few changes from 2.6
<cjwatson> built-in collections.OrderedDict is nice
<cjwatson> tedious to write directly
<TiMiDo> yeah correct mok0
<mok0> ... Now 3000K *is* powerful. Wish all extensions could be updated soon
<TiMiDo> more fun ;) we'll have
<mok0> Numpy for example
<TiMiDo> django is a cool small project
<mok0> he
<TiMiDo> but at the same time powerful
<mok0> You call that "small"?
<TiMiDo> yeah I seen pythons applets or apps reaching the 2GB
<TiMiDo> in my class ;)
<mok0> TiMiDo: Those are huge. Django is big
<mok0> In my world
<TiMiDo> oh in my class i seen bigger apps
<TiMiDo> so that's why
<mok0> Since you can do an incredible amount of stuff in just a few hundred lines of Python
<jml> I can't switch to my lucid schroot since upgrading to precise
<jml> $ schroot -c lucid-amd64
<jml> E: 10mount: mount: unknown filesystem type 'aufs'
<jml> E: lucid-amd64-2cb56580-9dfe-41be-a214-44663808dca9: Chroot setup failed: stage=setup-start
<TiMiDo> yeah mok0
<TiMiDo> mok0, where ya from?
<mok0> TiMiDo: Aarhus, Denmark
<TiMiDo> let me guess germany?
<cjwatson> jml: you may need to switch union-type to overlayfs
<TiMiDo> oh nice ;)
<mok0> TiMiDo: Close but no cigar :-)
 * TiMiDo from Miami Florida
<cjwatson> jml: and possibly amend union-mount-options
<mok0> TiMiDo: what are you doing in front of the computer :-)
<mok0> TiMiDo: get out and fight some alligators
<TiMiDo> hahahaha yeah
<mok0> :-)
<TiMiDo> i was creating a small plugin for audacious
<jml> cjwatson: thanks. will try that.
<TiMiDo> that can control eq's at the same time some pitching libraries is not bad.
<mok0> TiMiDo: nice
<TiMiDo> man i feel like taking a small trip to Europe
<TiMiDo> i need some vacations.
<cjwatson> jml: we're probably stuck with this kind of thing until such time as one of the union filesystems actually makes it upstream; overlayfs is the most plausible candidate right now, I think
<jml> cjwatson: changing union-type fixes the issue, thanks.
<cjwatson> you're welcome.  (I don't use unioning with schroot as yet so hadn't noticed that myself.)
<cjwatson> I ought to sort out moving from pbuilder to sbuild, which would benefit from union-mounting.
<jml> cjwatson: Well, essentially all I did was run mk-sbuild in relative ignorance, in an attempt to get set up for backporting things to lucid
<kirkland> pitti: howdy
<doko> pitti: packages like magics++ still ftbfs :-/
<pitti> doko: yes, on ppc :(
<doko> and arm*
<doko> pitti: so the archive (at least main) should be in a pretty consistent shape?
<pitti> it is right now; I hope it doesn't completely fall apart over the holidays
<wip> Does gtk_status_icon_new still works on Unity?
<wip> the new indicator (blacklist / whitelist) is causing me trouble with wxWidgets applications
<wip> see http://groups.google.com/group/wx-users/browse_thread/thread/e688d6d188003f87 for an explanationb
<doko> tgall_foo, pitti: please see https://launchpad.net/~doko/+archive/toolchain for the libjpeg-turbo and libjpeg8-empty packages
<tgall_foo> doko, great thanks
<doko> updates work for me, and the system doesn't explode, but I'd like you to verify
<tgall_foo> shall do
<slangasek> pitti: are you planning to take care of the libverto build-dep switch?
<pitti> doko: trying now; why do we need -empty, though?
<pitti> slangasek: it's a little more than just the b-dep switch; it needs some packaging changes, build a new binary, drop the old one, and then test krb5 against that
<pitti> slangasek: as I'm on holiday, and AFK from tomorrow on, I can do it in January, but not this week any more
<slangasek> pitti: are you sure that changing the build-dep changes the ABI of libverto itself?
<pitti> still need to get the new lucid/maverick langpacks settled with micag, so no promises for this year
<pitti> slangasek: I hope it won't
<slangasek> pitti: anyway, if you're not taking it that's perfectly fine, krb5 wasn't actually an autosync but a sync I did manually so I bear some responsibility ;)
<doko> pitti: this source package defines the libjpeg8* dependency packages; didn't want to change libjpeg8 yet, in case we have to revert the change. with this setup, we can just re-upload libjpeg8, and remove libjpeg8-turbo
<slangasek> right; if it doesn't change libverto's ABI, then no need to change the package names
<pitti> slangasek: but I'd at least build krb5 against it and see whether it runs some tests, etc.
<slangasek> sure
<slangasek> or I could just build krb5 against it, install it, and check whether my entire home network falls apart ;)
<pitti> slangasek: well, it currently builds libverto-libev and libverto-libglib variants; I suppose it should build a libverto-libevent variant then
<slangasek> I look into it
<slangasek> I'll
<pitti> I have NFC about the package, so it might be that you need to specify the backend in some constructor call or what not
 * slangasek suppresses his inner Russian
<pitti> doko: I installed libjpeg-turbo8 now, and at least eog foo.jpg still works; but I notice it doesn't divert the original library, so if I'd purge -turbo again my system will be hosed
<pitti> doko: do you still plan to add that?
 * pitti reboots in the meantime to test it more system-wide
<doko> pitti, no, therefore the dependency package. the diversion is gone
<pitti> doko: what's wrong with the diversion? I don't see how the dependency package will fix that
<pitti> doko: anyway, I still see icons and background images, etc., so it seems to work here
<doko> pitti, wasted space, and afaicr cjwatson_ argued against using the diversion
<pitti> well, in this case I think we should really just apply the patch to libjpeg itself
<pitti> because this just breaks libjpeg8
<pitti> phone, bbl
<doko> pitti, why should it break?
<pitti> you can't remove libjpeg-turbo8 any more (but nothing in the packaging system stops you from it)
<pitti> no biggie, but just want to mention it
<pitti> I apt-get install --reinstall libjpeg8 now, so it's fine
<doko> well, ok. I'll add a dependency on the new libjpeg8
<broder> jml: fyi, mdeslaur patched mk-sbuild to use overlayfs as of u-d-t 0.136, so new chroots should use it
<broder> mdeslaur: do you think it makes sense for, say, an schroot postinst to try and migrate aufs chroots to overlayfs?
<jml> broder: good to know, thanks.
<mdeslaur> broder: hrm, maybe...I don't have a strong opinion, it's users are typically power users anyway
<mdeslaur> broder: it currently probes the running kernel to decide on overlayfs vs. aufs, so the postinst would need to do that too I guess
<broder> hmm...maybe the better solution would be to have a "union-type=default" or something and have schroot pick the right one for the system
<slangasek> blast, the patch in bug #874774 isn't even addressing the right bug
<ubottu> Launchpad bug 874774 in cryptsetup (Ubuntu Precise) "could not mount /dev/mapper/cryptswap1" [High,Triaged] https://launchpad.net/bugs/874774
<broder> that + a useful error if you set union-type={aufs,overlayfs} and it can't start because the fs isn't available
<tumbleweed> broder: yeah, the probing was a quick hack
<tumbleweed> (debian doesn't have overlayfs yet)
<broder> right, but as jml pointed out, the upgrade experience kind of sucks atm
<cjwatson> sbuild.postinst doesn't work well as a place for it, because you might upgrade sbuild then the kernel
<cjwatson> in fact you probably will in a one-shot upgrade
<cjwatson> (I mean, upgrade sbuild then reboot into the new kernel)
<tumbleweed> cjwatson: see broder's next suggestion
<cjwatson> yes, that would work better
<tumbleweed> of course, for sbuild chroots, the easiest upgrade path is to blow them away and rebuild them
<broder> yeah, i think this is actually pretty simple - you need to change the C++ verification code to accept union-type=auto, but after that i think you can do everything from /etc/schroot/setup.d/10mount
<broder> tumbleweed: sed -i -e 's/union-type=aufs/union-type=overlayfs/g' /etc/schroot/chroot.d/* is pretty easy
<dobey> will there be a DMB meeting on jan 2?
<tumbleweed> broder: oh, that too :P
<tumbleweed> dobey: we've said "if enough people turn up, and it sounds likely"
<tumbleweed> err s/,/",/
<broder> i'm planning to sign up for the 1/2 meeting, since the alternative is waiting 2 weeks *and* having to be awake at 6 AM my time :)
<dobey> tumbleweed: well, i'm about to propose a new delegated team for ubuntuone related packages, so would like to get through that process as quickly as possible to make things work more smoothly :)
<tumbleweed> dobey: that'd be a new packageset, right?
<dobey> yes
<tumbleweed> send a mail, and the discussion can begin
<dobey> yeah, was planning on that; just wanted to make sure of when i need to be on IRC, since the wiki page says "DMB, at its next meetingâ¦" :)
<infinity> mvo: I should learn to just never give you ideas, shouldn't I?
<infinity> mvo: I think you ruined my holidays by automating that hack. ;)
<mvo> infinity: ahaha
<mvo> infinity: I like it
<mvo> infinity: (sort of ;)
<doko> cyphermox, you synced libnl3 without providing a MIR for xmlstarlet
<stgraber> doko: bug 906982
<ubottu> Launchpad bug 906982 in xmlstarlet (Ubuntu) "[MIR] xmlstarlet" [Undecided,Fix released] https://launchpad.net/bugs/906982
<doko> stgraber, hmm, I didn't get the ubuntu-mir email ...
<cyphermox> doko: sorry, had missed that xmlstarlet, I created the mir as soon as I found out (then spoke to jdstrand since there were cves for xmlstarlet in the past)
<lumio> helloâ¦ there seems to be a bug in ubuntu 11.10 with unity: when I press the super-key aka win-key when the screen is locket, the unity interface appears. I won't be able to click anything, but I can see what apps are open and of course the unity menu
<broder> mvo: ping? vmware-view-client shows up in software-center for me, but it's not multiarch installable to amd64 on oneiric
<mvo> broder: and you run a amd64 system?
<broder> yeah
<broder> it complains about libpcsclite1:i386, libxml2:i386, libxtst6:i386, and zenity:i386
<mvo> broder: right - you have partner already enabled, correct?
<broder> yep (i turned it on from s-c, which was pretty slick, btw)
<mvo> broder: glad to hear (that it was slick)
<broder> ...oh wait...maybe not?
<broder> ah yes - it's there
<broder> http://paste.ubuntu.com/776841/
<slangasek> broder: I guess the point is that software-center should suppress the display of the package on amd64, since the deps are not multiarch-ready in oneiric?
<broder> that's probably the best solution at this point
<broder> though offering an amd64 build would be a nice alternative
<mvo> slangasek: yeah, I think that is the best option for now, we are in contact about a amd64 build, but I haven't heard back yet
<mvo> broder: --^
 * broder nods
<mvo> but I need to call it a day for now, its rather late here
 * mvo aves
 * mvo waves
<broder> mvo: do you want me to file a bug somewhere so you don't forget?
<mvo> broder: please do!
<broder> where would you like it?
<mvo> broder: and assign to me please
<mvo> broder: software-center
<mvo> please
<broder> kk
<mvo> thanks!
<slangasek>  vmware-view-client:i386 : Depends: libpcsclite1:i386 but it is not going to be installed
<slangasek>                            Depends: zenity:i386 but it is not going to be installed
<slangasek> aw, still not installable on precise either
<broder> zenity is clearly bogus
<slangasek> well, it needs to be marked M-A: foreign
<broder> (i.e. should be m-a: foreign)
 * slangasek nods
<broder> pcsclite could be tricky because i believe it communicates with a separate daemon
<slangasek> s/tricky/fun for broder/
<broder> <3 you too, slangasek :-P
<slangasek> :)
<slangasek> well, there are only 17 packages left for ia32-libs, so we'll have to find *some*thing to keep you entertained in the new year
<broder> well, it looks like the protocol is bittedness agnostic. not sure yet if it's endianness agnostic, though
<broder> looks like it's almost certainly not
<broder> is that considered a blocker for multiarch?
<infinity> Ick, endian-specific protocols?  Fix, fix!
<infinity> Didn't even dbus learn that lesson and fix its issues?
<broder> well, more "moderately ad-hoc protocol consisting of shoving structs into sockets"
 * infinity shivers.
<infinity> That could end up being even arch-specific, let alone endian-specific.
<broder> it's not arch-specific - the struct headers all use uint32_t et al.
<infinity> Ahh.
<broder> but the members of the struct are assigned to without any endianness conversion
<RAOF> There's no guarantee that the stucture packing is consistent across archs, either, is there?
 * RAOF discovers the --eatmydata option to mk-sbuild.  Joy!
<broder> oh yeah, you might be right
<RAOF> C structs as your IPC protocol: Just Say No :)
<ajmitch> RAOF: let's use XML instead? :)
<RAOF> Yes!
<dobey> you could use JSON; where everything is a C struct defined by string literals :)
#ubuntu-devel 2011-12-21
<dholbach> good morning
<TiMiDo> good morning dholbach
<dholbach> hi TiMiDo
<TiMiDo> how are you dholbach
<dholbach> good good - how about you?
<TiMiDo> here doing good, just updating some translations in launchpad
<dholbach> nice
<TiMiDo> yeah and still no ubuntu member yet lol
<brendand> can anyone here clarify if the 'Suspend' option in indicator-session just runs the 'pm-suspend' utility, or does it do something else?
<RAOF> brendand: It'll use the upower dbus interface; it won't be running 'pm-suspend'
<brendand> RAOF - yeah, that's what i got from looking at the code. I've got a system here that wakes from suspend when using the dbus interface, but no when using pm-suspend
<brendand> very weird
<RAOF> IIRC upower has all sorts of hooks for quirks that pm-suspend doesn't.
<TeTeT> brendand: you could try 'dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Suspend' and see if the return code has any useful info
<micahg> slangasek: any chance you're up for fixing krb5? it has a breaks on our version of samba and is breaking precise (bug 907227)
<ubottu> Launchpad bug 907227 in ubuntu-meta (Ubuntu) "ubuntu-desktop fails deps and marks nearly whole OS for uninstallation" [Undecided,New] https://launchpad.net/bugs/907227
<micahg> or is there anyone up that can investigate this? ^^
<micahg> ugh, nevermind, I guess I"ll fix it myself
<micahg> slangasek: nevermind, fixes uploaded
<micahg> doko: can I hand off a bug to you to keep an eye on?
<doko> michah: depends on the bug =)
<micahg> Bug #907227
<ubottu> Launchpad bug 907227 in samba (Ubuntu) "krb5 (libkrb5-3) 1.10+dfsg~alpha1-6 breaks on libsmbclient <= 2:3.6.1-2 making upgrades and installs broken" [Critical,Fix released] https://launchpad.net/bugs/907227
<micahg> I uploaded fixes, I just don't know if that was the whole extent of it
<doko> micahg, I don't see any other added breaks
<micahg> right, I just want someone to be aware of what happened in case anyone asks
<micahg> ok, at least i386/amd64 are published now
<micahg> ah, not fully published yet
<apw> doko, ok both your buildd kernels are in -proposed.  i am not sure i expect them to move much further before new year though ...
<doko> apw, yes, did send an email to pitti yesterday who promoted
<apw> doko, been in there about 25 mins ... anyhow hopefully that is enough
<Sweetshark> dholbach: ping?
<dholbach> Sweetshark, pong
<Sweetshark> dholbach: woha, that was fast!
<dholbach> how are you doing? how can I help? :)
<Sweetshark> dholbach: any chance on distributing http://www.omgubuntu.co.uk/2011/12/could-you-be-the-libreoffice-bug-hunting-hero/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+d0od+%28OMG!+Ubuntu!%29 to some more ubuntu channels (forum etc.)
<Sweetshark> dholbach: Im fine, Im already on holiday :D
<micahg> Sweetshark: shouldn't we have gotten 3.5.0 uploaded to precise then?
<dholbach> Sweetshark, sure, I'd suggest to put it up on http://ubuntuforums.org/forumdisplay.php?f=11 (I think you can login with OpenID)
<dholbach> Sweetshark, and I can mention it in tomorrow's ubuntu dev update
<micahg> Sweetshark: if you want to prepare 3.5.0 beta 1, I'd be happy to sponsor for you next week
<ManDay> Has anyone ever tried Consolekit with casper? Apparently it doesn't work out all right. /usr/lib/dbus-1.0/dbus-daemon-launch-helper, for example, is woned by a group 242, which doesn'T even exist.
<Sweetshark> micahg: well, the state of that is: it builds, but there are still issues with ./debian/rules install. I dont want to 'overtake' debian there -- too much internal and external deps that can go wrong.
<Sweetshark> micahg: I will have a look at finishing a beta package before the bug hunting session, but no promises, Im on vacation ;)
<micahg> Sweetshark: maybe talk with Debian about throwing it in experimental before the bug hunt, I'm sure their users might be able to participate as well
<Sweetshark> micahg: yep. well, _rene_ said last week: "I want to have a build this weekend." but Murphy never sleeps.
<Sweetshark> dholbach: thanks for the ubuntuforums link. I will do that.
<dholbach> rock on! :)
<dholbach> Sweetshark, https://wiki.ubuntu.com/BuildingCommunity/BuildingBuzz might also contain some other interesting links
<doko> Riddell, did you miss to upload a new kdelibs4?
<ScottK> doko: Looks like he did.
<ScottK> Let me see what I can do.
<debfx> and also meta-kde
<ScottK> OK.
<ScottK> kde4libs up.
<ScottK> meta-kde up too.
<ScottK> doko: On the way.
<smoser> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smoser
<smoser> Riddell, could you quickly pull https://code.launchpad.net/~cldunlap1/ubuntu/oneiric/kubuntu-docs/fix-for-825807-2/+merge/78134 merge request in ? it seems that it just got lost.
<smoser> i dont' see it at lp:kubuntu-docs or an ubuntu version
<mdeslaur> anybody have any ideas on how to debug this unity issue? bug 894198
<ubottu> Launchpad bug 894198 in unity (Ubuntu) "Firefox main window doesn't draw every 3-4 launches" [Undecided,Confirmed] https://launchpad.net/bugs/894198
<dobey> mdeslaur: is that in unity2d?
<mdeslaur> dobey: no, unity 3d
<mdeslaur> err...unity
<dobey> ah; i know there is a patch in metacity to support some behavior for unity-2d, which causes the same issue, even if you're using classic gnome
<mdeslaur> oh, interesting...compiz --replace has fixed it...reassigning bug to compiz
<smoser> jbicha, around ?
<smoser> anyone care to tell me if i'm wrong on my comment at bug 906340 ?
<ubottu> Launchpad bug 906340 in meta-gnome3 (Ubuntu) "Please merge meta-gnome3 1:3.0+6 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/906340
<geser> smoser: an other minor issue: looking at the debdiff I wonder about the change to Uploaders (we should take the Uploaders field unmodified)
<smoser> gracias, geser
<jbicha> smoser: yes, the hamster-applet delta was temporary for Oneiric and can be dropped
<smoser> jbicha, do you think i should just modify the patch a bit and give the original merger credit and upload ?
<smoser> or should i take credit myself?
<smoser> it seems pointless to spend time on back and forth on this, but i dont want to shirk responsibility or take credit.
<ScottK> smoser: My usual approach is such cases is if it's done by a new person I'm trying to encourage, I give them credit (but watch to make sure it's OK), but if it's by someone that should know better, then I just fix it and document I did it.
<smoser> thanks ScottK
<ScottK> No problem.
<broder> smoser: the Uploaders line is auto-generated by the weird GNOME packaging tools
<broder> i don't know that you can avoid changing it when you run the clean target
<smoser> ah... yeah. i see its written from control.in
<smoser> Uploaders: @GNOME_TEAM@
<broder> i mean, you could dance around running the clean target when you build the source package, but it just seems too error prone to worry about
<slangasek> micahg: ah, doh; it would've been nice to be able to keep krb5 in sync and just get samba merged up since that's overdue, but I guess that's not expedient :)
<ManDay> How can I find other Ubuntu Versions on the ubuntu homepage?
<ScottK> ManDay: http://releases.ubuntu.com/
<doko> ScottK, Riddell: this change was dropped: https://launchpad.net/ubuntu/precise/+source/kdeartwork/4:4.7.3-0ubuntu2
<doko> and I remember another armhf kde one
<Riddell> hi doko, my internet got cut off just as a I uploaded kde yesterday so I'm about to review it all
<Riddell> I'll add that kdeartwork change
<ManDay> ScottK: How could I possibly find that?
<doko> Riddell, I processed the NEW packages today, and promoted those, where I did see package splitouts.
<ScottK> ManDay: Not sure.  I just happen to know it.
<Riddell> thanks doko
<ManDay> ScottK: Yes, thank you. I was rather wondering how one would be able to navigate there.
<ScottK> Dunno.
<doko> Riddell, this one too: https://launchpad.net/ubuntu/precise/+source/kstars/4:4.7.3-0ubuntu3
<ikonia> ManDay: you where given that link the other day
<ikonia> ManDay: support is in #ubuntu as you know
<ikonia> ManDay: this channel is for development of ubuntu
<ManDay> ikonia: I have no idea what you are talking about.
<ikonia> ManDay: you where given that link release.ubuntu.com so you could download 11.04
<ikonia> you couldn't find it on the website - as you where making claims it was not supported anymore, so you where given that link, that's how you managed to download and install 11.04
<ManDay> ikonia: My question was not where I can find 11.04. I wanted to know how I'd navigate there on the ubuntu page.
<ikonia> it's not linked, as was mentioned
<ikonia> and again - this is discuss for #ubuntu, not #ubuntu-devel
<ManDay> Since that was a question regarding the website and had nothing to do with #ubuntu I deemed it fit for devel. Okay now.
<ManDay> s/#ubuntu/Ubuntu
<ikonia> it's not an ubuntu development topic
<ManDay> Ok.
<ikonia> ubuntu is all ubuntu topics, not just the actual software, it is a pretty good question for ubuntu (for future reference)
<nemo> cjwatson: bleah. I always forget to file that bug when I'm at home, and only remember when I'm at the office when I can't file it
<nemo> cjwatson: I think at this point you're about as likely as I to remember it.  so. going to throw it back on channel
<nemo> 11.10 upgrade of existing install crashed due to /usr/local/man existing and it wanting to symlink that dir.  Since install created a number of other /usr/local dirs, could also be problematic.
<nemo> aaaand, going to retreat now, since it has been a week and I doubt I'm going to remember and I want to free up a hotkey in irssi
<nemo> oh... and since install crashed, I think it got the package list confused after since it wasn't too good at keep track of how far an upgrade had gotten in some temp dir on the traget filesystem
<nemo> l8r
<doko> RAOF, bryceh: looking at https://launchpadlibrarian.net/87880957/buildlog_ubuntu-precise-i386.xserver-xorg-video-cirrus_1%3A1.3.2-4_FAILEDTOBUILD.txt.gz
<doko> an error in an installed header file. is this known to you? asking because I want to start a test rebuild and maybe fix it before
<lamont> dear network manager.  I appreciate your persistence.  But seriously, I do not enjoy returning to the computer to (literally) 50 separate windows all asking for the WPA2 key for a network, which I have already told you once, and told you to remember.  kthx
<lamont> once I finish killing those windows, I shall go file my bug
<vanhoof> lamont: been noticing that myself the last couple of days as well
<vanhoof> lamont: but only when running the precise kernel on oneiric
 * vanhoof hasn't quite figured out what's going on yet
<lamont> plain boring oneiric here
<vanhoof> lamont: Intel 6205 wifi by chance?
<micahg> slangasek: I wasn't sure if we wanted the new samba for the LTS
<doko> RAOF, bryceh: hmm, X looks more broken, libxi ftbfs. lets see what will fail in the test rebuild
<slangasek> micahg: yeah, we do
<slangasek> micahg: but no reason you should have been expected to know that at 4am ;)
<micahg> slangasek: ok, I can look into that then
<micahg> and I don't think a merge like that's a good emergency fix anyways :)
<slangasek> yep
<smoser> looking for more sponsoring help
<smoser> https://code.launchpad.net/~mark-mims/ubuntu/precise/ganglia/useradd looks good to me other than http://paste.ubuntu.com/777754/
<smoser> is it appropriate to update the changelog message bug still give mmm credit ?
<smoser> and if i update the  changelog doesn't it make sense to update the timestamp?
<SpamapS> smoser: re the changelog, Its totally appropriate for you to be the one on the changelog, but have [ Mark Mims ] ... as the one person in the changelog.
<smoser> yeah. i can just go with that.
<cjwatson> smoser: for minor things like that I'd personally just fix them up and upload under their name - that way it shows up in LP searches for things they uploaded
<cjwatson> I'm not sure what my threshold for "major change" is
<cjwatson> fix them up and upload> oh, and leave a comment in the merge proposal saying what I'd done, of course
<micahg> you can also add a section to the changelog saying what you fixed w/out changing the owner of the entry
<smoser> ok. next question.
<smoser> if i branch lp:ubuntu/ganglia and then try 'bzr bd'
<smoser> er.. bzr bd -S
<smoser> i get http://paste.ubuntu.com/777766/
<smoser> i'm used to seeing that with --source-option=--abort-on-upstream-changes , but i've explicitly not done that here.
<micahg> isn't that the default with dpkg 1.16.1?
<cjwatson> in that situation I would use 'bzr bd -S -- -nc' to avoid the problem, and just debdiff the resulting .dscs carefully
<cjwatson> ("no clean")
<cjwatson> and yes, the dpkg-source default changed
<infinity> I do so wish people would stop relibtoolizing/reautoreconfing/etc in their clean targets.
<cjwatson> there's --source-option=--auto-commit, but I think I would prefer -nc in this case for just a drive-by upload
<cjwatson> infinity: yes, quite
<smoser> ah. thank you cjwatson micahg . i'm happy for that change. but didn't know how to back it out.
<slangasek> -S -nc - heh, geez
<doko> cnd, is X in flux? did see build failures in libxi and xserver-xorg-video-cirrus
<cnd> doko, I've uploaded a new x11proto-input
<cnd> it could be that I've caused an issue there
<cnd> though it shouldn't have affected any video drivers
<doko> cnd: no, this was before the upload
<slangasek> doko: libjpeg-turbo-progs wants libturbojpeg?  that seems wrong somehow
<slangasek> (component-mismatches)
<micahg> smoser: sorry, was disconnected and didn't see your first pastebin, what you did was totally fine
<cnd> doko, do you have logs?
<doko> cnd, http://paste.ubuntu.com/777798/ for libxi
<doko> slangasek, yes, looks wrong. will fix
<cnd> doko, that should be fixed with an upload I *just* pushed
<cnd> 5 mins ago
<cnd> x11proto-input 2.1.99.4-0ubuntu1
<doko> ahh, ok, and the other one is https://launchpad.net/ubuntu/+source/xserver-xorg-video-cirrus/1:1.3.2-4
<cnd> doko, hrm... that could be a bigger issue
<cnd> I'll look into it
<doko> cnd: XI2MASKSIZE macro
<doko> #define XI2LASTEVENT    XI_TouchUpdateUnowned
<doko> #define XI2MASKSIZE     ((XI2LASTEVENT + 7)/8) /* no of bits for masks */
<doko> but XI_TouchUpdateUnowned isnt't defined anywhere
<cnd> yeah
<cnd> doko, so I pushed the latest upstream x11proto-input
<cnd> I was thinking, it's backwards compatible, so all should be alright
<cnd> but it's backwards compatible with the latest upstream, but not with what we have in the archive
 * cnd had a brain fart
<cnd> is there a way to revert back to a previous version of the package?
<slangasek> no
<cnd> yeah, that's what I figured
<cnd> so I can work around this issue by adding a temporary patch to add back in the symbols that were lost in the transition?
<slangasek> you either have to mock up a new version number for the package that's greater than this one (such as 2.1.99.3.really.2.0.2-0ubuntu1), or use an epoch, or fix the packages that this has regressed to be compatible
<cnd> but that's rather hackish
<slangasek> are upstream fixes available for the packages that broke?
<cnd> slangasek, it's not an upstream issue
<doko> cnd, libxi now fails with http://paste.ubuntu.com/777807/
<cnd> it's an issue where I pushed stuff that wasn't ready to be pushed really
<slangasek> cnd: er, it's an issue with *some* upstream
<cnd> its an issue with our prototype XI multitouch implementation
<slangasek> or are you saying that all the xi support is Ubuntu-local patches?
<cnd> in libxi and xorg-server and up the stack
<cnd> basically, until this point, yes
<slangasek> ah
<cnd> we're switching to the upstream version
<cnd> I'll work around it by adding the previous symbols back in
<cnd> it shouldn't be too hard
<cnd> it's just two header files
<doko> Riddell, please could you prepare a MIR for kdesvn?
<ScottK> doko: We don't want kdesvn in Main.
<ScottK> What's pulling it in?
<doko> ScottK, kdesdk
 * ScottK looks
<doko> thanks
<ScottK> doko: It's this again "kdesdk-kio-plugins (>= ${source:Version}) | kdesvn-kio-plugins"
<doko> ahh, then it's fine
<ScottK> Not sure why component mismatches always picks that up.
<ScottK> doko: Any idea?
<doko> would be cjwatson question. not sure if explicit seeding would help
<jtaylor> doko: as precise only supports python2.7 do you see any issues with python2.7 providing argparse and removing the argparse 2.6 backport package from precise?
<jtaylor> alternative would be to just fix the ~18 rdepends, or revert debians 2.6 only change in argparse and just leave it
<doko> well, would like to get remove python2.6 and argparse together
<tumbleweed> or make it a dummy package in Ubuntu
<micahg> doko: so, can I set up a transition in the tracker to get rid of python2.6
<tumbleweed> we still have a bunch of packages depending on 2.6, we should probably start rebuilding them, yes
<ScottK> doko: Isn't 2.6 already not supported for module building on precise?
<doko> micahg, please do
<ScottK> So I'd think argparse can go away ~anytime.
<doko> ScottK, no, removed from supported
<tumbleweed> ScottK: it can't go while stuff depends on it
<ScottK> If 2.7 provided argparse, then nothing would depend on it ...
<ScottK> Thus ~anytime and not anytime
<micahg> I thought we said we can't do that since it'll have the wrong behaviour
<tumbleweed> micahg: we can in Ubuntu
<doko> ScottK, python should provide python-argparse, and I'll add the python2.7-argparse provides to python2.7
<ScottK> doko: Sounds good.
<tumbleweed> nothing depends on python2.7-argparse
<micahg> right, it all depends on python-argparse
<Ampelbein> Is the script that is used to generate http://people.canonical.com/~ubuntu-archive/nbs.html available for the public?
<ajmitch> Ampelbein: I believe it's in lp:ubuntu-archive-tools
<Ampelbein> ajmitch: indeed it is. Thank you very much.
<ScottK> Riddell or doko: libplasmaclock4abi3 landed in Universe, but it's needed in Main.  kde-workspace-dev isn't installable at the moment.
<doko> ScottK, yes, already fixed
<ScottK> doko: Thanks.
<cnd> doko, slangasek: uploaded x11proto-input_2.1.99.4.really.2.0.2-0ubuntu1
<dobey> what is the best way to deal with lp:ubuntu/foo having pre-applied patches in it, when one wants to bzr merge-upstream from a new release tarball which already includes all those patches? :(
<dobey> anyone?
<micahg> dobey: unapply patches, commit, import upstream, rebase/reapply patches
<dobey> :(
<ScottK> There's also ignore what's there, package the new release, and then let the importer just overwrite the mess.
<ScottK> SpamapS: What's the plan for mysql in 12.04 (which version(s))?
<SpamapS> ScottK: 5.5.19 landed on dev.mysql.com not too long ago, I aim to have that land in debian unstable early January, and hopefully *sync* mysql into precise shortly after that.
<ajmitch> planning to keep 5.1 in universe or drop it?
<SpamapS> ScottK: one big problem that has to be solved is that the client programs are all statically linked against libmysqlclient.
<SpamapS> ajmitch: *drop*
<SpamapS> Been trying to wade through the deps
<ajmitch> need a hand with getting rid of it?
<SpamapS> myodbc and sphinxsearch are two where upstream seems to be broken in several ways
<ScottK> It'd be a good excuse not to work on boost.
<ajmitch> ScottK: yeah, I've still got to write that email, though it looks like boost-defaults probably won't make it to testing by DIF
<SpamapS> mysql-cluster-7.0 also is going to be broken by the my.cnf that we ship in 5.5 .. not sure how to handle that. :-/
<SpamapS> I suppose one way to do it is to move the 5.5 specific stuff to /etc/mysql/conf.d and then have a mysql-common-5.5 and a mysql-common-5.1 ...
 * SpamapS hates that libmysqlclient and mysqld have the same config file. :-p
<SpamapS> anything left still depending on libmysqlclient16 is FTBFS for some other reason
<SpamapS> mostly vtk .. which as I understand, is working now
<smoser> https://bugs.launchpad.net/ubuntu/+source/cobbler/+bug/907525
<ubottu> Ubuntu bug 907525 in cobbler (Ubuntu) "python-cobbler fails install without python-support" [Undecided,New]
<smoser> is the fix for that simply dropping the 'update-python-modules' ?
<smoser> nothing indicates why its there, though :-(
<doko> looking
<ajmitch> SpamapS: slicer ftbfs is due to vtk?
<tumbleweed> ajmitch: if that dates back to last cycle, then yes
<SpamapS> ajmitch: last I looked it was
<doko> smoser, yes, just remove
<smoser> doko, thanks.
<dobey> smoser: are you still patch piloting?
<smoser> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<smoser> dobey, no. but did you need something?
<dobey> several ubuntuone uploads which need sponsoring
<smoser> theyr'e not listed at http://reports.qa.ubuntu.com/reports/sponsoring/ are they?
<dobey> 2 of them are; i just proposed another branch so might not show up yet
<dobey> https://code.launchpad.net/~nataliabidart/ubuntu/precise/ubuntuone-control-panel/ubuntuone-control-panel-2.99.0/+merge/86455 is one
<dobey> https://code.launchpad.net/~dobey/ubuntu/precise/ubuntuone-client-gnome/release-2-99-0/+merge/86488 is another
<dobey> unfortunately, new versions of autotools make the diff quite large due to differences in configure and such :-/
<smoser> dobey, i'm sorry.. i have to run.
<smoser> i do have a question though...
<smoser> oh. never mind.
<smoser> kind of sucks that you have hard versioned dependencies between two different sources (just hard to maintain)
<dobey> yeah, we have lots of projects, so it can be annoying sometimes, but it's not that bad. it used to be much worse for us :)
<dobey> smoser: thanks. i probably should run myself
<doko> Riddell, ScottK: I fixed both kstars and kdeartwork again :-( I can't checkin, the Vcs-Bzr URL seems to be wrong. please check in the patch I did submit, don't rewrite it ;)
<Riddell> doko: ok thanks
#ubuntu-devel 2011-12-22
<SpamapS> micahg: hey, what ever happened to xulrunner? I kind of lost track of mongo and javascript in general...
<SpamapS> micahg: err, I meant libmozjs, not xulrunner
<SpamapS> thinking and typing should usually be in sync
 * SpamapS makes a note
<micahg> SpamapS: so, libmozjs is libmozjs185 in ubuntu, I've meant to merge mongodb, will probably do it over vacation and patch it to use the system mozjs
<micahg> they ship their own copy now of mozjs
<SpamapS> micahg: yeah, thats the answer to all the worlds' problems now.. embed your own version
<micahg> yep, that's what mozilla tells people
 * micahg wishes Debian would ship mozjs instead of building it from xulrunner, but oh well
<mbiebl> micahg: who is maintaining mozjs 1.8.5? What about security updates etc?
<micahg> mbiebl: well, if there's a security update, I'll push it out, but we haven't seen any updates yet
<mbiebl> I mean, who maintains mozjs upstream?
<micahg> wes garland seemed to be doing a lot with it, idk if he's officially maintaining it or not
<mbiebl> micahg: we've been discussing that some time ago on #debian-gnome, and there was the question about how security updates are handled for the mozjs branch
<mbiebl> afaik it's based off FF4
<micahg> was wondering myself recently
<mbiebl> and you can't build FF against mozjs, so we'd have two (different) copies of libmozjs
<micahg> well, debian still builds mozjs out of xulrunner
<mbiebl> so we'd need to discuss that with the security team and the mozilla maintainers
<mbiebl> micahg: yeah
<micahg> well, Ubuntu is ok with Firefox having its own copies of things since it gets updated every 6 weeks or faster
<mbiebl> well, actually it's build from src:iceweasel
<mbiebl> not sure if that is what you meant
<micahg> mbiebl: well, isn't xulrunner also built from src:iceweasel now?
<mbiebl> seems to be
<dholbach> good morning
<dr3mro> hello .. I have an Idea for precise+1 : That is to rewrite all current Apps that in python like software center and others in Vala and create an ubuntu development environment that will ease the new developers to create projects for ubuntu .. windows got all the apps because it's easier to develop and maintain projects than in linux ..
<dr3mro> we need to rewrite compiz for low memory usage  too so plain ubuntu install shouldn't use more than 300MB as windows 8 airms for 256 Mb only we should be prepaired
<dr3mro> else we could write unity for mutter if it's difficult to make compiz rewrite as for now unity is great but memory hug and perormance is uncomparable for gnome shell
<dr3mro> I am thinking of Glade + gedit + debugger + compiler + UI in Gtk+-3.0 for managing launchpad repository .. test the compilation before upload .. a form for proposing you app in ubuntu/debian  PPA  .. Documentations ..
<dr3mro> ubuntu should adopt vala as the default programing language and invest in Vala as it's the future of ubuntu
<who_me> what exactly is wrong with python ?
<dr3mro> and OS with an integrated development with good documentations for both the OS and the Dev language is what ubuntu needs
<who_me> python doesn't have good documentation ? :)
<dr3mro> who_me, python is great but it is slower than vala and memory hug
<dr3mro> who_me, no I meant vala has no good doumentations
<dr3mro> who_me, imagine an integrated dev environment with glade + text editor + debugger + vala documentations + ubuntu documentations about all the infrastructures of ubuntu like how to message the kernel dbus and all that vage stuff for beginners ..
<who_me> you mean "hog" probably" and it's not like the linux kernel is written in python, just some utilities. I'd rather have those be complete, easy to debug etc. then redisgn something for the new programing language that seems to be the "rage" of the day :)
<who_me> redesign*
<dr3mro> who_me, I love the pythonic way in development but after playing with vala for a few days and see the performance difference and low memory usage I am now a vala +1
<brendand> i'd say things are more likely to move towards Qt
<who_me> that's what I feel too :)
<dr3mro> I think ubuntu should focus on the IDE thing and Document offline so new programmers don't have to google for things that very obvious if they are a developers for windows
<dr3mro> brendand, Qt project is great but less free than Gtk and thats why its supported by nokia ..but ubuntu is Gtk ?
<who_me> umm, developers for windows are part of the "Visual C, C++, Basic and etc" toolset and mindset, it's quite hard to recreate that on any other platfrom
<who_me> it's up to them to use something like the QT SDK and try to target multiple platforms
<dr3mro> who_me, what about making something for ubuntu like that ? it will make ubuntu tempting for new developers for linux
<brendand> to be honest, it's naive to think the problem is around having the 'wrong' tools
<brendand> anyway, what's the say the app development community is weak on Linux/Ubuntu?
<brendand> games development, yes, but that's a whole different matter
<brendand> and some commercial software
<brendand> still a nice dev environment would be, well, nice :)
<brendand> anway, this should all be discussed on #ubuntu-app-devel
<dr3mro> My idea is a Documentation for both Ubuntu services like DBUS and other stuff with Vala and Gtk + and Gobject and ... + debugger + text editor + glade + a frontend for launchpad and an easy way to propose your app for ubuntu /debian repos ?
<who_me> dr3mro: problem is like this, try to find a book about programming about C++ and I bet that 99% will make you use MS Visual studio... nothing on using some other IDEs
<brendand> why Vala though?
<dr3mro> brendand, vala performance and memory usage very smilar to C and easier to learn and write code in few hours like python and it has syntax similar to C# / Java so developers will find it very familiar and it has  a fork that uses the same compiler but syntax is pythonic  it's called `Genie`  ??
<who_me> dr3mro: here's an idea, try to implement some of those ideas yourself, get enough followers and maybe you guys will get noticed.  A spin of Ubuntu with Vala based utilities...
<dr3mro> who_me, pinguy OS did that already :)
<dr3mro> who_me, gnome 3.0 is written mostly in VALA
<who_me> gnome 3 is rubbish, not the best example of usage IMO :P
<TiMiDo> can someone tell me if my wiki is ok https://wiki.ubuntu.com/aaronfarias
<dr3mro> who_me, you mean gnome shell :) ..
<TiMiDo> I'm going for membership ;)
<who_me> no, I mean gnome 3 with mutter and extensions as a whole
<dr3mro> who_me, I find it faster on my laptop that gnome 2 and stylish .. themes are in CSS and the problem is that it's immature and need a year or two before it matures
<who_me> they did a rush release, with most of the functionality from the previous version left out and now we are supposed to "beta test" while they slowly fix things by version 3.6 :)
<dr3mro> who_me, agree .. but it works not as gnome 2.x but not that bad
<dr3mro> who_me, it's better in quality than kde 4.0 when it was released
<who_me> that is why I keep my trusty LTS install and try to help kubuntu and kde iron out bugs :/
<dr3mro> who_me, looks like you are preparing to go the KDE way soon ..
<who_me> dr3mro: yeah, and what did the gnome guys learn from a poorly managed kde 4.0 release ? nothing.
<who_me> they did the exact same thing
<dr3mro> who_me, they delayed to release a year and more and you can't iron things out if it's now widely tested
<who_me> dr3mro: KDE offers a tablet like interface, but they don't force it on me. They give me the classic desktop interface that I've known for a long time and can easily discover. Gnome 3 + shell just chnaged everything and it like "hey, this is how your desktop will look now. like it or else"
<who_me> I tend to get moody when stuff is forced down my throat
<dr3mro> who_me, you are right ..
<who_me> so while G3 is like, look dudes, your workstation just became a tablet PC
<who_me> KDE gives me the option to use my machine for what it actually is, be it tablet or workstation
<who_me> I'm actualy old enough to remember how Gnome actually came to be, as an answer to the way Qt was licensed back in the days
<who_me> KDE 2.x was beautifull in comparison to Gnome back then
<who_me> http://www.visionfutur.com/img/histoire/gnome1-1.jpg  versus  http://www.kde.org/screenshots/images/large/kde2final_4.jpg
<mbiebl> micahg: urgh, the ubuntu mozjs package has different symbols files for each architecture
<chrisccoulson> mbiebl, that's because the name mangling is different on each architecture :/
<mbiebl> chrisccoulson: hasn't KDE the same problem?
<chrisccoulson> mbiebl, yeah, i think so
<mbiebl> I think they developed a solution for that
<chrisccoulson> i'm sure i asked someone how they solved this problem, and this was the result
<chrisccoulson> but that was a while ago
<mbiebl> iirc MoDaX worked on that
<mbiebl> chrisccoulson: http://anonscm.debian.org/gitweb/?p=pkg-kde/kde-sc/kde4libs.git;a=tree;f=debian;hb=HEAD
<mbiebl> seems they managed to have a single symbols file
<chrisccoulson> interesting
<chrisccoulson> i'll try and figure out how :)
<doko> Riddell, ScottK: kdeplasma-addons and gwenview are the two real ARM build failures (double/float casts)
<mcclurmc> hi all. does ubuntu allow multiple distributions to be specified in the debian/changelog?
<mcclurmc> can I specify both oneiric and precise? or do I need to build two separate debs?
<geser> mcclurmc: you need two source packages, one for each release
<mcclurmc> okay, thanks geser
<Riddell> mbiebl, chrisccoulson: http://pkg-kde.alioth.debian.org/symbolfiles.html is how we have one symbols file for all arches
<Riddell> doko: ok
<mbiebl> Riddell: where does pkgkde-getbuildlogs get the build logs from?
<mbiebl> does that mean I need to upload -1 with broken symbols files, the run pkgkde-getbuildlogs and upload fixes symbols files in -2?
<Riddell> mbiebl: ignore pkgkde-getbuildlogs it's debian only
<Riddell> you can use locally compiled build logs or in buildds but only if there's only 1 library
<Riddell> I usuae my on local build logs
<doko> Riddell, libmygpo-qt needs a MIR (amarok)
<doko> and, can amarok be built without OpenGL for armel/armhf?
<doko> https://launchpadlibrarian.net/88144488/buildlog_ubuntu-precise-armhf.amarok_2%3A2.5.0-0ubuntu1_FAILEDTOBUILD.txt.gz
<ScottK> lamont: Could you give ross a kick in the shins so we have some hope of powerpc catching up this year.
<Riddell> doko: yeah I know, on my TODO
<Riddell> (libmygpo-qt, amarok needing no GL on ARM is new to me but I can look at it too)
<sabdfl> Daviey, ping
<nigelb> He's supposed to be vacationing.
<doko> Laney, we should introduce dedicated buildds for haskell :-p
 * iulian nods.
<doko> iulian, btw, are all the rebuilds needed, or could these a bit better organized to avoid some of the rebuilds?
<cjwatson> doko: the current builds are mostly syncs of packages not previously in Ubuntu, not rebuilds
<doko> cjwatson, yes, known. just fearing the follow-up of rebuilds
<cjwatson> they aren't that bad except for the cases where they sit and hang for a day :-)
<cjwatson> http://people.canonical.com/~ubuntu-archive/transitions/ghc.html is looking not particularly awful right now
<doko> lets see this page after this round of uploads
<zyga> hi
<zyga> who is the best person to talk about u1db?
<cjwatson> doko: syncs of new packages aren't going to make it worse
<cjwatson> zyga: I'd start with aquarius
<zyga> thanks
<zyga> aww, away
 * iulian will keep his eyes open.
<cjwatson> lp/~sil
<iulian> There will be a few rebuilds to deal with.
<james_w> zyga, #u1db
<mdeslaur> doko: I'll merge virt-manager (you TIL)
<doko> mdeslaur, anything you want =)
<mdeslaur> :)
<zyga> james_w: thanks
<roadmr> hey! is 32-bit Ubuntu installing the pae kernel by default now? is this a recent change or has it been like that for a while?
<micahg> roadmr: recent
<roadmr> micahg: thanks! I'm triaging a bug from someone installing on a VirtualBox (PAE is disabled by default) - so without that particular bit of information, his report was "ubuntu fails to boot"
<micahg> and`: I think the extensions compatible by default landed in 10, not 9
<and`> micahg: do we have a firefox 10 already?
<micahg> and`: in firefox-next PPA soonish
<and`> micahg: ah, I found this out right after installing firefox 9 on Debian sid
<and`> micahg: and I got the confirmation that ffox asks for informations to addons.mozilla.org if the network is active
<and`> micahg: so that you can enable the addon even if max_version is < than the installed ffox package
<micahg> well, in 9 I thought that only works if you have the extension that overrides compatibility installed, unless glandium backported a patch
<and`> micahg: I tested it out today, I upgraded iceweasel to version 9, all my addons got disabled, I switched them back to enabled on the addons interface and restarted iceweasel.
<and`> micahg: result, all my addons are back and working again without touching install.rdf
<and`> micahg: and I don't think glandium backported a patch for that according to what he told me on d-devel before.
<and`> I couldn't find an official statement upstream so I don't know :)
<Laney> doko: yeah sorry. feel free to score stuff down if you want.
<micahg> could i please get an archive admin to copy thunderbird 3.1.16+build2+nobinonly-0ubuntu0.10.04.1 to ubuntu/primary lucid from ubuntu-security-proposed?
<micahg> doko: would you be able to do this? ^^
<micahg> oops partial copied, that needs to go to lucid-security
 * micahg wonders if it's too early for slangasek
<micahg> Riddell: could you copy the above for me?
<Riddell> micahg: let's see
<Riddell> micahg: from ubuntu-security-proposed ppa lucid to ubuntu-security lucid?
<Riddell> does it have the necessary QA and security team approval for that?
<micahg> Riddell: thunderbird from ubuntu-security-proposed ppa lucid to ubuntu lucid-security, I am the security team and QA approval in this case :)
 * micahg already copied maverick and natty, but lucid times out
<Riddell> micahg: copy binaries too?
<micahg> Riddell: please
<Riddell> micahg:  copy-package.py -p ubuntu-security-proposed -s lucid --to-suite=lucid-security -b thunderbird ?
<roadmr> SRU question this time: an package in -proposed had two verification failed bugs. What's the best way to handle that? remove those two fixes from the SRU and request another merge?
<micahg> Riddell: not sure on the syntax, I just have an old guide on the Archive Admin page, but the from and to look right
<ScottK> That or fix the fix so it works.
<micahg> Riddell: according to that, it should be copy-package.py -b --ppa=ubuntu-security-proposed -s lucid --to-suite=lucid-security -e 3.1.16+build2+nobinonly-0ubuntu0.10.04.1 thunderbird
<roadmr> ScottK: for one of the bugs the fix is in the devel version, I just messed up while adding it to the SRU
<roadmr> ScottK: but for the other one, the bug is still present in development, so we'd have to fix it there and then push that to the SRU again
<ScottK> Right, so I'd drop that one and resubmit, I guess.
<Riddell> micahg: done
<roadmr> ScottK: ok, I'll do that then. Thanks!
<micahg> Riddell: thank you much
<micahg> slangasek: unping
<slangasek> micahg: not too early, just to on-the-phoney, sorry :)
<doko> ScottK, gwenview, see bug #907735
<ubottu> Launchpad bug 907735 in gwenview (Ubuntu Precise) "[arm] gwenview ftbfs in precise" [High,Confirmed] https://launchpad.net/bugs/907735
<ScottK> doko: Already fixed.
<doko> ScottK, please close it after verifying =)
<ScottK> OK
<doko> make[1]: Entering directory `/build/buildd/drush-4.5'
<doko> sh: 1: wget: not found
<doko> sh: 1: curl: not found
<doko> people should hide things better ...
<doko> gah, should be make[1]: Entering directory `/build/buildd/drush-4.5'
<doko>  /build/buildd/drush-4.5/drush.php > /dev/null
<doko> sh: 1: wget: not found
<doko> sh: 1: curl: not found
<cjwatson> I thought I fixed that
<cjwatson> oh, no, there was a Debian bug about it
<cjwatson> grr, it was working and then the Debian maintainer broke it again
<cjwatson> missing build-dependency on php-console-table I believe
<adam_g> is there any way to have a lp PPA build satisfy its Build Depends from within the PPA?
<mdeslaur> adam_g: that should already be the case AFAIK, just make sure your build depends are finished building before uploading the other ones
<adam_g> mdeslaur: ok, ill try again. thanks
<ScottK> Nice.
<ScottK> lamont: Ross fell over and can't get up again.  Is something up or just unlucky today?
<doko> Riddell, ScottK: I think we need to improve the kde situation for build-deps/breaks
<doko> e.g. kdenetwork fails with:
<ScottK> doko: Soyuz just needs to implement the same BD unistallable condition Debian has and it'll be fine.
<doko> The following packages have unmet dependencies:
<doko>  kde-sc-dev-latest : Breaks: kde-workspace-dev (< 4:4.7.90) but 4:4.7.3a-0ubuntu4.1 is to be installed
<doko>                      Breaks: kdepimlibs5-dev (< 4:4.7.90) but 4:4.7.3-0ubuntu2 is to be installed
<doko>                      Breaks: libkonq5-dev (< 4:4.7.90) but 4:4.7.3-0ubuntu2 is to be installed
<doko> E: Unable to correct problems, you have held broken packages.
<doko> apt-get failed.
<doko> and doesn't automatically retry
<ScottK> Yep.  On Debian that would get a BD uninstallable state, not a failed build and would eventually work.
<doko> if you know that, don't use it
<doko> just adjust the version for the b-d's
<doko> ScottK, is there a bug about this?
<ScottK> So you want us to fork the KDE packages from Debian?
<ScottK> I don't think that's going to happen.
<doko> ScottK, no, contribute to it. these adjusted versions don't hurt debian
<ScottK> No, the versions are correct.
<ScottK> Once kde-workspace is built on armel, I'll retry it.  It'll be fine.
<doko> ScottK, it's not about the retrying
<doko> ScottK, is there a bug report open about this?
<ScottK> Yes.
<doko> which one?
<ScottK> Let me see if I can find it.
<ScottK> doko: Bug 527245
<ubottu> Launchpad bug 527245 in Launchpad itself "Implement a BD-Uninstallable build state" [Low,Triaged] https://launchpad.net/bugs/527245
<ScottK> AIUI, 'Low' in LP bug terms means they aren't going to do it.
<doko> thanks for the pointer
<micahg> it means it's not scheduled, opportunistic devs can fix I think
<ScottK> Could be.
<ScottK> doko: No problem.
<adrian_berg> If you tinker with the kernel, you are then not able to upgrade to future ubuntu releases, correct?
<adrian_berg> My boot time is pathetic, and this is a new laptop (4gb ram, dual core 2ghz processors), shouldn't be having these problems, so my only guess is that there's too much crap being loaded in the kernel
<RAOF> adrian_berg: Have you done any measurements?  I don't think kernel load time (except, perhaps, initramfs load time) is going to be a large part of your boot time.
<SpamapS> http://reports.qa.ubuntu.com/reports/boot-speed/
<SpamapS> adrian_berg: note the results there
<SpamapS> kernel is quite tiny
<SpamapS> plumbing is the pain point
<SpamapS> udev, mounting, fsck'ing, etc
<ScottK> Funny how when we forget to care about boot time it goes up.
<SpamapS> its just like my waistline
<SpamapS> the minute the diet is over, I gain 10lbs back. :)
<SpamapS> I would be interested in the breakdown of what constitutes plumbing
<ScottK> I guess you could run bootchart yourself.
<SpamapS> no the bootcharts are linked there
<SpamapS> looks like a lot of it is ureadahead
<infinity> ScottK: That bug mostly misses the point (as does BD-Un in Debian) 99% of the time.  You can almost always express a BD-U state as a dep-wait, it just requires drilling down.
<ScottK> infinity: Implementation detail.
<infinity> ScottK: And I may well fix *that* in lp-buildd, rather than implementing another build state.
<ScottK> That's fine.
<ScottK> I don't care what you call it.
<RAOF> SpamapS: Yeah, but time speant in ureadahead is (or should be) directly offset by time not spent at other points of the boot process.
<ScottK> (and I agree, BD uninstallable is a sub catagory of depwait)
<SpamapS> RAOF: the lucid ones hit 93MB/s w/ ureadahead
<SpamapS> RAOF: and the more recent ones are down around 86MB/s
<RAOF> :(
<SpamapS> is it just as simple as the drivers being more careful and underperforming?
<SpamapS> The numbers work out quite well % wise
 * SpamapS decides to blame firmware
<infinity> SpamapS: Blame Apple.  That's my default fallback for everything now.
<psusi> SpamapS: you gotta pack the data with e2defrag ;)
<zyga> hi, where can I find some canonical/ubuntu media packs
<zyga> stuff like the ubuntu logo
<jpds> zyga: http://design.canonical.com/brand/
<zyga> jpds: thanks
<hallyn> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: hallyn
<hallyn> jinkeys!  suddenly no aufs module?  must have happened with today's update?   huh...
<RAOF> hallyn: That's been the case for some time; overlayfs (mostly) replaces it.
<hallyn> i expected that one day, but figured schroot/sbuild would quietly dtrt when that happened :)
<hallyn> here's hoping that sed -i 's/aufs/overlayfs/' * in /etc/schroot/chroot.d does the trick
<hallyn> \o/
#ubuntu-devel 2011-12-23
<hallyn> anyone around who would considering pushing https://code.launchpad.net/~psusi/ubuntu/precise/lm-sensors/merge/+merge/85044 ?  I don't  have perms to dput it.
<broder> hallyn: i'm hoping to have time to try and improve that upgrade path during my holiday break
<hallyn> broder: for schroot?  cool - it's no big deal if documented, just took me awhiel (and looking through a patch you sent to debian :) to figure out where to tweak
<hallyn> the subdirs under /etc confounded me :)  i was grepping in /etc/*
<elky> anyone heard from lifeless & other christchurch people in the past hour? there's been another big quake there :(
<bilal> iHate changing nicks, but this is going to be my nick from now onwards. Plain and simple
<bryceh> elky, "only" 5.8 this time, hopefully only modest damage and no casualties
<bryceh> bilal, nice
<elky> bryceh, yeah, so far no reports of toppled buildings or death, but there has been reports of injury and cracking and liquefaction. Merry christmas, christchurch :(
<ajmitch> great way to finish the year
<elky> ajmitch, yeah
<RAOF> :(
<ScottK> And ross is dead again.
<ScottK> powerpc may never catch up.
<ScottK> infinity: Any idea what's up with it (dunno if you can still look into such things)?
<ScottK> At least the third time today it's died.
<infinity> ScottK: I can't, no.  Gave up that access.
<infinity> ScottK: I know people have been notified, however.
<ScottK> Thanks.
<infinity> ScottK: ross lives.  Of course, the firefox build that killed it might take out adare soon. ;)
<ScottK> It's been that same build it died on at least two of the times.
<ScottK> Of course it's a long build, so it may just be coincidence.
 * infinity nods.
<infinity> I suspect the Xserves will be infinitely happier when we can upgrade them to precise.
<infinity> The older kernels we left them on weren't the happiest of pandas, if I recall.
<infinity> At least, back when the machines were "mine".
<infinity> Oh, no, I'm living in the past.  They're lucid now.
<infinity> It was hardy that they skipped.
<ScottK> Yep
<ScottK> IIRC they ran Karmic for a little while.
<psusi> doko_, in xmlrpc-c (1.16.32-0ubuntu2) you wrote: * Don't use the symbols files, renamed the library packages anyway.  I assume this means you renamed the binary package to have -0 in the name.  Why?  I'm trying to install boxee and it depends on the non -0 version.  Is there an abi breakage, or could adding a provides: for the non -0 fix this?
<ScottK> Which is preferred (it seems they both work fine): (qreal)foo or qreal(foo)?
<psusi> ScottK, you talking about casting in C++?
<ScottK> yes.
<ScottK> Sorry.
<psusi> well, the former works in C as well, in C++, I think the specific {static,dynamic}_cast<> is preferred
<psusi> technically the latter form instantiates a new temporary
<ScottK> For Qt qreal is a double on all archs except armel/armhf so it's quite common for people to interleave doubles and qreals when they shouldn't.
<infinity> psusi: I'm not sure if there was an ABI break, but the package should have the SOVER in the name regardless.  Can boxee not be rebuilt to get the correct dep?
<infinity> psusi: Oh, it's proprietary.  Yay.
<psusi> infinity, right.. so if there wasn't an actual abi breakage, adding a provides: for the old incorrect soname should fix things right?
<infinity> psusi: If.  You might want to check that.
<infinity> It's still "wrong" from a "packaging libraries correctly" standpoint, but...
<infinity> psusi: On the other hand, if doko had to disable checksymbols, that sort of points to ABI breakage.
<hallyn> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<micahg> infinity: just noticed that libsmbclient doesn't have a SONAME in the package either
<jk-> anyone know how the ubuntu core images are built? is it just a debootstrap?
<infinity> jk-: It's essentially debootstrap --variant=minbase at the moment.
<jk-> infinity: awesome, thanks.
<dholbach> good morning
<micahg> infinity: can I get you to copy firefox (lucid/maverick) from ubuntu-security-proposed to {lucid,maverick}-proposed?
<bdrung> tumbleweed: it seems that we have to live with the broken dh_install. do you have the patch for wrap-and-sort for me?
<tumbleweed> bdrung: :/ http://paste.debian.net/150005/
<bdrung> tumbleweed: do you have a commit message for that change?
<tumbleweed> bdrung: no, I hadn't committed it locally
<bdrung> tumbleweed: pushed slightly modified
<Laney> doko_: do you know if that kernel fix is going to be deployed to the buildds any time soon?
<doko> Laney, I assume first week of Jan, there's nobody around now, but the kernels are in -proposed and can age
<Laney> great
<Laney> wfm
<doko> and they are already tested
<mdeslaur> doko: hi! any idea why this could be happening? (unbound FTBFS on oneiric) http://paste.ubuntu.com/779905/
<mdeslaur> doko: line 6301+
<mdeslaur> doko: same package build fine on precise, and precise's package doesn't build on oneiric
<doko> mdeslaur, configure:14781: checking python extra libraries
<doko> configure:14788: result: -lssl -lcrypto  -lssl -lcrypto      -L/usr/lib -lz -lpthread -ldl  -lutil
<doko> but then not linking with these ...
<mdeslaur> yeah, I tried adding -lssl -lcrypto...but I didn't add the other...thanks, I'll give it a try
<doko> mdeslaur, hmm, it shouldn't be necessary, the conftest.c doesn't use any of these
<doko> mdeslaur, does it work without -flto?
<mdeslaur> doko: let me check
<doko> mdeslaur, is this oneiric-security?
<mdeslaur> doko: yes, but I tried building with -updates too
<doko> hmm, it should be fixed in binutils from oneiric-updates
<mdeslaur> oh, interesting...ok, I'll try it again with -updates
<mdeslaur> thanks doko
<mdeslaur> doko: binutils worked, thanks!
<doko> mdeslaur, so maybe copy it to the -security pocket?
<mdeslaur> doko: yeah, I'm rebuilding it in -security now so we don't hit it again
<Riddell> sladen: guy on ubuntu-users asked for monospace fonts, you may want to check if he's tried ubuntu mono
<doko> Riddell, according to NBS, a kdevelop upload is missing ;)
<Riddell> doko: I'll try a rebuild locally and upload
<ScottK> doko: KDE core is now fully built on armhf in the archive.
<roadmr> SRU question. I need to re-submit an SRU that needs some code added and some removed. Should I prepare a new branch to be merged against the oneiric branch (replacing the first one), or just request a merge on the oneiric-proposed branch with the modified code?
 * roadmr wonders if the question is understandable
<micahg> roadmr: #ubuntu-devel or #ubuntu-motu would be better for this, but oneiric-proposed would be the place to propose a merge to
<roadmr> micahg: ok.
<roadmr> micahg: btw, thanks! you're always answering my dumb SRU questions, you must hate me by now :)
<micahg> roadmr: oops, you're in the right channel :)
<micahg> roadmr: I'm used to seeing  you in #ubuntu-bugs
<roadmr> micahg: hehe well sorry if I've been asking devel stuff in -bugs, too many channels! argh
<micahg> roadmr: there are no dumb questions :), we're all learning
<roadmr> micahg: ok so I'll branch the current oneiric-proposed, prepare my fixes and request a merge on that
<micahg> roadmr: branching for the first SRU from the release branch is only out of necessity since the -proposed branch doesn't exist until the first SRU is uploaded
<roadmr> micahg: oh I see, well that makes sense - and subsequent SRUs, if needed, would go to -proposed then?
<micahg> roadmr: right
<roadmr> awesome :) thanks
<micahg> roadmr: just keep in mind, if there's a security update, you'll need to branch from -updates or -security to get the full history (sometimes you might have to rebase -proposed onto security if the security team is forced to drop a fix in their upload)
<roadmr> micahg: ok, I'll be careful with that if the need arises
<infinity> micahg: Done.
<micahg> infinity: ooh, thanks :)
<micahg> infinity: can you copy {firefox,mozvoikko,ubufox}/natty from ubuntu-mozilla-security to natty-proposed please?
<infinity> micahg: Done, done, and done.
<micahg> infinity: thanks :)
<micahg> infinity: can we copy for oneiric and permakill the powerpc firefox build before it hangs the buildd
<micahg> infinity: I don't want to risk hanging one of the powerpc buildds over the weekend, so if we can't, then we'll wait until monday
<Laney> does it hang 100% of the time on ppc?
<micahg> Laney: ATM, it seems to, we're disabling the tests which should in theory "resolve" the issue, but I don't want to test that w/out a safety net (i.e. someone to push the power button) either
<Laney> ah OK. I was going to suggest p-a-sing it at least for the buildds' sake, and investigating why it builds for Debian but not us.
<micahg> oh, i don't know if Debian's running the tests, I got the FTBFS fix from them
<Laney> I am trying to see but the build log killed my firefox :-)
<micahg> can I use p-a-s on a stable release?
<Laney> infinity knows
<micahg> infinity: if you get a chance and you can permakill the powerpc build, please copy {firefox,mozvoikko,ubufox}/oneiric from ubuntu-mozilla-security to oneiric-proposed, if not, don't worry about it, I"ll look into it Monday
 * micahg has to run
#ubuntu-devel 2011-12-24
<ybit> http://sprunge.us/Jccg
<ybit> also i'm curious if it's possible to write plugins for the dash
<ybit> er, is there an api for it rather
<ybit> and i'm executing sudo pbuilder create --debootstrapopts --variant=buildd having not got a response from anyone
<ybit> ..after already sudo pbuilder create executed sucessfully
<ybit> -already
<ybit> sudo pbuilder build *.dsc
<ybit> that command tells pbuilder to build anything with a file ending with .dsc
<ybit> are the dsc files removed after the build or install is successful?
<hacked_kernel> Is there a channel for Ubuntu One dev?
<nigelb> hacked_kernel: There's #ubuntuone if you haven't already seen it. Everyone's probably away for the holidays though.
<sladen> Riddell: which "guy on #ubuntu-users" ?
<sladen> Riddell: or literally <guy> ?
<Riddell> sladen: mailing list
<shnatsel> hello everyone
<shnatsel> I'm trying to create custom seed file; I'm stuck at Germinate's "Task-Seeds: " key
<shnatsel> it seems to duplicate the data in the STRUCTURE file
<shnatsel> what shall I put there if my task depends on several other seed files from the same branch/dir?
<shnatsel> "man germinate" says to refer to "man germinate-update-metapackage" which doesn't mention such keys
<shnatsel> !logs
<ubottu> Official channel logs can be found at http://irclogs.ubuntu.com/ . LoCo channels are now logged there too; for older LoCo channel logs, see http://logs.ubuntu-eu.org/freenode/
<cjwatson> shnatsel: germinate-update-metapackage(1) *does* document Task-Seeds.
<cjwatson> Albeit obliquely.
<cjwatson> shnatsel: And no, that header does not duplicate the inheritance data in STRUCTURE.
<cjwatson> shnatsel: Task-Seeds says that, in addition to this seed, the packages listed directly in the specified additional seeds should also be added as Depends/Recommends of the metapackage generated from this seed.
<shnatsel> cjwatson: wow, glad to see you here! :D
<cjwatson> shnatsel: If specified, this would normally be only a subset of the full inheritance of the seed.
<shnatsel> cjwatson: ah, sorry, found it
<cjwatson> shnatsel: In general it is perfectly fine to omit that header.  You only need it in special cases.
<shnatsel> cjwatson: thanks!
 * shnatsel thinks that #ubuntu-devel is truly a great place if you can get answers to stupid questions even during Christmas holidays
<shnatsel> cjwatson: Germinate is a great tool! Thank you so much for creating it and answering my stupid questions!
<cjwatson> shnatsel: That's OK - feel free to file bugs about documentation inadequacies, as ever
<cjwatson> shnatsel: (And, for completeness, I didn't actually create it originally, I've just been the victim who ended up maintaining it for seven years :-) )
<cjwatson> Although it's barely recognisable from the original nowadays ...
<shnatsel> cjwatson: oh yeah, I know that feeling... I've inherited an ISO build script, I'm trying to get rid of it all the time but I always end up rewriting it
<shnatsel> the latest (third) rewrite uses seeds
#ubuntu-devel 2011-12-25
<micahg> Ampelbein: would it be ok if I waited until the morning to sponsor crda?  I'm worried about something breaking while I"m asleep and being a holiday weekend w/out too many people around, I'd prefer to be cautious
<Ampelbein> micahg: of course that would be ok, there are other patches I need to prepare for the libnl3-dev NBS (libvirt, ntrack and quota) anyway.
<Ampelbein> thank you!
<micahg> Ampelbein: you might want to coordinate with cyphermox as I know he's working on that as well, thank you for your work
<Ampelbein> micahg: will do that!
<cyphermox> Ampelbein: I already have merge proposals for ntrack and quota :)
<Ampelbein> cyphermox: Ok, cool. I'm at libvirt right now but there's 2 failures in the testsuite. (http://paste.ubuntu.com/782160/) They should be unrelated to the libnl3 change though so I'm at a loss.
<cyphermox> aye
<cyphermox> don't know either just looking at those
<cyphermox> tbh, I'm not going to be touching anything this weekend though
<cyphermox> Ampelbein: btw, your crda patch seems incorrect
<cyphermox> Ampelbein: it seems to me like it would be missing a change to CFLAGS to get to the netlink headers
<Ampelbein> cyphermox: Nope, the original Makefile already has: CFLAGS += `pkg-config --cflags $(NLLIBNAME)`
<cyphermox> Ampelbein: ah, that was missing from the diff
<cyphermox> cool then ;)
<Ampelbein> cyphermox: About iw, yes, the debian maintainer replied in the debian bug 653189
<ubottu> Debian bug 653189 in iw "iw: FTBFS with new libnl3 package version 3.2.3-2" [Important,Open] http://bugs.debian.org/653189
<cyphermox> yup :)
<cyphermox> too bad wpasupplicant and iw haven't been sponsored yet; but essentially I was expecting Heiko to upload them, given that he suggested doing it and the wpa maintainers were looking for a sponsor
<Ampelbein> It wouldn't hurt to wait until iw is in debian.
<cyphermox> it's not the biggest deal though, the change is simple. but I know the diff they have also moves it to /sbin
<Ampelbein> cyphermox: I found the reason for that test FAIL in libvirt... I use libeatmydata in my sbuild chroots, which of course change fsync to be a noop.... Classic case of PEBKAC. Without libeatmydata, compilation works.
#ubuntu-devel 2012-12-17
<psusi> cjwatson, well, I've spent tonight going over all of the debian patches and either removing them because they are merged upstream, or refreshing where needed... most of them dropped out
<cjwatson> That's not the hard bit :-)
<cjwatson> Honestly, we've had this conversation before
<cjwatson> You just don't believe me, but I can't help that :)
<cjwatson> If you want to actually move this forward, forget about parted - look at the partman-base bug I'll file in a moment and implement that
<cjwatson> Debian #696123
<ubottu> Debian bug 696123 in partman-base "partman-base: need progress wrapper for non-libparted-based filesystem operations" [Wishlist,Open] http://bugs.debian.org/696123
<cjwatson> right, really bed now
<ScottK> infinity: Keeping mpi in Universe is the reason we split the boost source package in half, so good call on valgrind ...
<hyperair> rc0.d is the shutdown runlevel, right? does are SXXfoo* scripts supposed to be called with start or stop when shutting down?
 * hyperair noticed an S90halt that seems to do nothing on start but does stuff on stop instead.
<StevenK> S* are calling when switching to that runlevel
<StevenK> *called
<infinity> hyperair: "The two runlevels 0 (halt) and 6 (reboot) are slightly different. In these runlevels, the links with an S prefix are still called after those with a K prefix, but they too are called with the single argument stop."
<hyperair> ah i see.
<hyperair> infinity: where does that come from?
<infinity> hyperair: From Policy, Â§9.1
<hyperair> aha, okay, thanks
<pitti> Good morning
<pitti> bdmurray: .crash with out SAS> oh I am! can you please file a bug and attach the file there?
<pitti> infinity: no, it's not meant to defer crash reports; as long as update-notifier is running, they should be reported right away
<pitti> infinity: you can call /usr/share/apport/apport-gtk to show the pending ones
<pitti> infinity: you can call /usr/share/apport/apport-gtk to show the pending ones
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<dholbach> can somebody please reject https://code.launchpad.net/~logan/ubuntu/raring/php-horde-crypt-blowfish/debian-merge/+merge/139545 (based on the last comment)?
<pitti> dholbach: done
<dholbach> thanks pitti
<infinity> pitti: Hrm.  update-notifier's running, but definitely no reports.  Weird.
<mpt> pitti, hi. Three main issues have stopped me when considering whether to design a Presentation Mode or Do Not Disturb mode in the past. First, most of the notifications I've seen examples of, that would be suppressed in that mode, are notifications that probably shouldn't be shown as bubbles in the first place -- except perhaps for chat, and that's handled by Busy status. Second, how you'd remember that you'd gone into that mode, so that you could exit late
<mpt> r. And third, what would happen when you did exit: would notifications be queued up, or would they just be dropped?
<pitti> mpt: ah, thanks for the heads-up; JohnLea pointed me to http://design.canonical.com/the-toolkit/unity-multi-monitor-interactions/ â Multiple Monitors UX Specification â Presentation mode
<mpt> pitti, that takes me to a sign-in page :-]
<mpt> ah, I found the section
<mpt> pitti, doesn't look like that document addresses those issues either
<pitti> mpt: not for providing an option to turn them off, just for not displaying them when you are in a fullscreen app, etc.?
<infinity> pitti: Running apport-gtk appears to have done nothing...
<mpt> pitti, I mean (1) examples of notifications that would be suppressed but normally shown, (2) how you would notice/remember that you'd gone into that mode, and (3) what would happen when you exited.
<pitti> infinity: then it seems you do not have crash reports which weren't already presented
<infinity> pitti: That's patently untrue, I have 10 new ones.
<infinity> pitti: And if my last few logins are anything to go by, they'll all get presented next time I reboot. :P
<infinity> (But maybe not this time?)
<pitti> infinity: can you pastebin the output of stat /var/crash/* ?
<pitti> infinity: it tells apart "seen" from "unseen" by atime > mtime
<infinity> http://paste.ubuntu.com/1444864/
<pitti> /var/crash/xserver-xorg-video-intel.2012-12-12_19:28:48.563612.crash looks strange
<pitti> Access: 2012-12-12 19:28:48.559803473 -0700
<pitti> Modify: 2012-12-12 19:28:48.567803473 -0700
<pitti> atime < mtime
<pitti> but that should count as "new"
<infinity> They all look like that.
<infinity> Isn't that vaguely normal for open, write, close?
<pitti> no, the top ones have atime > mtime, e. g. /var/crash/xserver-xorg-video-intel.2012-12-11_06:55:33.704464.crashâ
<infinity> Well, the top ones have a higher atime because they've been reported.
<infinity> All the unreported ones don't.
<pitti> infinity: these are root ones, so you need to run sudo /usr/share/apport/apport-gtk
<pitti> does that work?
<infinity> Oh, perhaps that's the problem?  Maybe update-notifier doesn't pick up rooty ones?
<pitti> the bottom block indeed
<pitti> they also don't have .upload files
<pitti> the top ones do, and it's apport itself which creates the .upload stamps
<pitti> so these must have been shown
<infinity> pitti: Yes, the top ones were all shown.
<infinity> pitti: It's the 10 at the bottom that I'm saying haven't been.
<infinity> pitti: And having them all show (very, very, slowly, I might add) on login is pretty unfriendl.
<infinity> unfriendly, too.
<pitti> infinity: what's the exit code of "/usr/share/apport/apport-checkreports --system"?
<infinity> As opposed to right after the crach, which is what I'd expect.
<pitti> infinity: yep; we have a design to fix that
<pitti> infinity: but assuming that your desktop session actually survives the intel crash, that's actually supposed to happen right now
<infinity> pitti: That returns 0.
<pitti> ok, then update-notifier doesn't pay enough attention to that
<infinity> pitti: Yeah, my session survives, the reports, as mentioned, don't happen until next login.
<pitti> infinity: can you kill it and run it on a terminal?
<pitti> infinity: it waits for a minute or so before it checks for crash reports
<pitti> infinity: then "sudo touch" an already seen one, that ought to trigger its attention
 * pitti tries here with sudo sh -c 'kill -SEGV $$'
<pitti> that brings up apport just fine
<rbasak> How do I get ubiquity to use -proposed? Will apt-setup/proposed=true in the kernel cmdline work?
<rbasak> infinity: you're up early! Or late? I've managed to reproduce bug 1079185 using ubiquity. Need to try -proposed now.
<ubottu> Launchpad bug 1079185 in flash-kernel (Ubuntu Quantal) "Wrong bootarg for disk with label" [High,Fix committed] https://launchpad.net/bugs/1079185
<infinity> rbasak: Did you not notice the part where I already marked it v-done?
<rbasak> Oh, you have?
<infinity> rbasak: Two days ago...
<rbasak> It would help if I were subscribed to the bug, wouldn't it!
<rbasak> Thanks!
 * rbasak puts his pandaboard stack away
<xnox> rbasak: hmm.. in what sense do you mean -proposed?
<rbasak> xnox: nm, it turns out that infinity already tested it. What I meant was that I wanted ubiquity to pick up flash-kernel-installer from -proposed, if that's possible (or else I wanted to manually update it before it used it)
<xnox> rbasak: ah. ack.
<rbasak> xnox: for future reference, how would I achieve that?
<xnox> rbasak: if a package is just installed - you can upgrade it in the tty1 however you like.
<rbasak> xnox: including udebs?
<xnox> rbasak: we do not use udebs.
<xnox> rbasak: in ubiquity we unpack them at source build time & embed udebs in the ubiquity package.
<xnox> rbasak: so for those you need to rebuild ubiquity package & upgrade that in live environemnt...... or simply replace bits & bobs in-place (if it's not compiled stuff ;-) )
<rbasak> OK, got it. Thanks!
<xnox> =)
<infinity> pitti: Oh, FFS, I did have an apport dialog hidden behind all my windows that I found when I went to shut down.
<infinity> pitti: Now, how long that's been there, I can't say.
<pitti> infinity: ps aux|grep apport-gtk
<pitti> that should tell you?
<infinity> That had nothing in it the last time I looked.
<infinity> That initial "problem detected" dialog isn't from apport, is it?
<infinity> I'm assuming it's from update-manager.
<pitti> right, update-notifier
<pitti> my bad
<infinity> And now I get to go through the pain of reporting 10 of these.
<infinity> Which takes way longer than seems reasonable.
<pitti> it's ten times click "ok"
<infinity> No, the gpu crashes take eons to actually do their thing.
<pitti> but indeed, as I said we have a design for batching those
<infinity> Not sure what they're doing, but they don't do it quickly.
<pitti> infinity: or just close the dialog; we have enough of those already, after all
<infinity> Gah, and typing while modal dialogs keep popping up = bad.
<infinity> *sigh*
<pitti> infinity: they attach a load of log files, and dissect the GPU dump for a signature
<infinity> pitti: Sure, but I can't see how that takes more than a few seconds.
<infinity> (It's literally a minute or more per crash)
<infinity> Which is extra entertaining when I have more GPU crahes while reporting my GPU crashes. :)
<mitya57> hey dholbach, so do you know what happened to translations.js?
<infinity> (The only reason I report them at all is to not give the impression that the bug is fixed, or becoming less frequent)
<dholbach> mitya57, no, I'm afraid I didn't get a chance to do that, but it's next on my list
<dholbach> mitya57, the script which updates developer.u.c seems to cause some other breakage as well (intermittent failures to update), so this is a good chance to make it more robust
<mitya57> dholbach: ok. that's minor thing, but it prevents some sphinx's built-in strings from being translated
<dholbach> I'll let you know :)
<dholbach> mitya57, ru.po is up to 61% :)
<mitya57> wasn't it at the same value when we were discussing it last time? :)
<dholbach> mitya57, I think we added some strings in the meantime ;-)
<mitya57> I do not have too much time to translate it myself, but other 3 people do it very well...
<dholbach> but yeah, it's still pretty close to the threshold of 70
<dholbach> I'm sure we'll get there
<mitya57> of course :)
<mitya57> btw, I'll maybe find some time for Sphinx SRUs after 1.2 release which will be soon
<dholbach> sweet
<ciao> ciao
<ciao> help
<mpt> barry, hi, any chance of landing the SRU for bug 846044 soon?
<ubottu> Launchpad bug 846044 in Python Dbus "software-center crashed with UnicodeEncodeError in get_dbus_message(): 'ascii' codec can't encode character u'\xfc' in position 65: ordinal not in range(128)" [Medium,Confirmed] https://launchpad.net/bugs/846044
<mitya57> mpt: it's already in -proposed, and will be moved to -updates when someone adds verification-done tag...
<mpt> mitya57, who is "someone" in this context? :-) (I'm not familiar with the details of the process)
 * mpt should just go read it
<mpt> ah, the SRU Verification Team
<dholbach> mitya57, fixed
<xnox> mpt: to be honest anyone. If you can reproproduce the problem, upgrade to -proposed, follow the test-case realise that (i) the problem is fixed & (ii) there are no regressions then just comment on the bug that "performed verification followed these steps, etc"
<mitya57> dholbach: nice, thank you!
<dholbach> mitya57, anytime :)
<xnox> then it can get marked verification-done very quickly & sru team will weight on that comment & release the update.
<mitya57> dholbach: maybe it's possible to link singlehtml/search.html -> html/search.html for every language? so that people don't think that search is broken.
<dholbach> bah
<dholbach> ok
<dholbach> publishing these docs is a giant hack :)
<mitya57> that was nitpicking :)
<mitya57> unfortunately it can't be done in the branch because there are no html subdirectories in our packages
 * dholbach nods
<dholbach> I'll look into it
<Daviey> doko: Does libboost-thread-dev  need a MIR, considering Boost is already main?  bug 1086423
<ubottu> Launchpad bug 1086423 in boost1.49 (Ubuntu) "[MIR] libboost-thread-dev (boost1.49/boost-defaults)" [High,New] https://launchpad.net/bugs/1086423
<infinity> Daviey: No.
<doko> Daviey, no, I don't think so. we don't have a good way to track binary package which we do want to keep out of main
<Daviey> Yeah, i didn't just want to action it... as a MIR had alrady been opened and assigned to you
<infinity> To be fair, I'd rather see a few unnecessary MIRs than the inverse, so I don't mind that one was opened.
<infinity> But yeah, not necessary in this case.
<infinity> boost was already split intentionally for main/universe reasons, it's fairly safe to assume that anything coming from the main sources is fine for main.
<infinity> (It's just that some of it is in universe because nothing currently depends on it)
<Daviey> yeah.. I was just checking, as mterry had assigned it to doko.. and i didn't want to trump over that without checking :)
<shnatsel> cjwatson: Hello! I see the Precise seeds have been switched to 3.5 kernel a while ago for x86 achitectures, but the daily ISOs still contain 3.2 kernel. Is that intentional?
<infinity> shnatsel: If by "still contain", you mean they have both, yeah, that's known.
<infinity> shnatsel: Not intentional, per se, and needs fixing, but known.
<shnatsel> infinity: they default to 3.2, not sure if they actually contain 3.5; elementary's ISOs build from mostly the same seeds do not contain 3.5.
<shnatsel> infinity: thanks! I'll look for Launchpad bug report and subscribe.
<xnox> shnatsel: well 3.5 is shipped under a new package name, so you do need to change your seeds if you wish to have 3.5.
<shnatsel> xnox: I did - I've merged the changes from Ubuntu's seeds. I do have the package with "quantal" in its name in seeds, but ISOs still use 3.2 by default. I've checked today's Ubuntu Precise daily build and it has the 3.2 kernel too.
<infinity> xnox: Changing seeds doesn't help, as "apt-get install ubuntu-desktop^" uses task headers, which we can't change post-release.
<xnox> true & *sigh*
<infinity> So, the solution for Ubuntu's images will require some mangling, either removing the release kernels manually, or switching to using metapackages.  Undecided yet on which is more annoying.
<infinity> My gut feeling is that doing the removal may be less scary than switching from tasks to metapackgaes and trying to determine if that causes fallout.
<infinity> It's on my TODO, at any rate.
<pitti> jibel: FYI, if your current gnome git fails to build in g-i: https://bugzilla.gnome.org/show_bug.cgi?id=690347
<ubottu> Gnome bug 690347 in introspection "does not find python include headers for multi-arch include files" [Normal,Unconfirmed]
<doko> what does this mean?
<doko> dpkg-source: warning: unknown information field ')description' in input data in package's section of control info file
<doko> the dsc file looks fine
<arand> What does your debian/control file look like?
<pitti> mdeslaur: many thanks for the glibc fix!
<mdeslaur> pitti: yw! sorry for having broke it in the first place :P
<pitti> mdeslaur: https://launchpad.net/ubuntu/+source/postgresql-8.3/8.3.22-0ubuntu8.04 \o/
<mdeslaur> cool :)
<mpt> ev, https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/500175/comments/10
<ubottu> Ubuntu bug 500175 in software-center (Ubuntu) "Canceling an installation in Software Center crashes debconf with "Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66,"" [High,Confirmed]
<bdmurray> pitti: bug 1091289
<ubottu> Launchpad bug 1091289 in apport (Ubuntu) "crash reporting missing a StacktraceAddressSignature" [Undecided,New] https://launchpad.net/bugs/1091289
<pitti> bdmurray: thanks
<pitti> bdmurray: ah, that's an easy one
<pitti> bdmurray: bug updated
<pitti> bdmurray: i. e. I don't think we should allow that low level of stacktrace quality
<pitti> it severely increases the probability of false positives for duplication
<bdmurray> So then should we not notify about those somehow?
<pitti> the user/reporter can hardly do something about it
<pitti> I think we can just keep them in errors.u.c. without being able to auto-duplicate them
<bdmurray> I believe errors didn't take it because it had no SAS
<pitti> I don't have much confidence in a stack trace starting off a NULL pointer
<pitti> basically, everything we know about it is "it crashed and corrupted memory"
<bdmurray> okay, and point is apport shouldn't offer to report it then
<pitti> well, I wonder why we wouldn't
<pitti> ev seems rather adamant of collecting each and every "unreportable" crash where we already know that it is the user's fault
<pitti> for those we should probably collect them as well, so that we know how many "no SAS" crashes we have?
<pitti> bdmurray: anyway, I guess we can add an UnreportableReason: field to it and tell the user "sorry, we cannot report this"
<bdmurray> I thought ev had a counter of errors with an SAS coming in
<pitti> but as there is no feedback after submitting a crash anyway, this would not actually make much of a difference
<bdmurray> er without an SAS
<pitti> if we do, we kind of do report them then?
<bdmurray> yes, I guess so.  Perhaps we should look at the counter sometime in the future and see how many there are and if the quantity is high consider it as detracting from the user experience, because we have excessive error dialogs.
<pitti> doko: cross toolchains> really cool!
<infinity> BenC: I'm going to delay that linux-ppc build for a bit, if you don't mind terribly.
<BenC> infinity: not a problem
 * xnox is sorry for [ab]using buildds for upstart sprint =)
<infinity> xnox: Given that all those builds fail anyway.. :P
<xnox> infinity: the last one actually works now =)
<xnox> infinity: https://code.launchpad.net/~canonical-foundations/+recipe/upstart-daily-nonvirt
<infinity> xnox: "the last one actually works"... You sound surprised.
<infinity> "I wrote some code and it actually kinda compiles a little bit and might even run sometimes, you should totally check it out."
<stgraber> infinity: well, we found a few "interesting" bugs where the tests would hang if they were run from within a directory containing a ~ in its name
<stgraber> infinity: took me a little while to figure out that one and fix it ;)
<xnox> infinity: and ppa recipes add ~release1 at the end..... =)
<stgraber> now we still have the problem that the tests hang on virt but pass on non-virt, but I'm just blaming 2.6.24 for now (downloading a hardy ISO to test here)
<infinity> stgraber: Hahahahaha.
<infinity> stgraber: (To the ~ bug)
<stgraber> infinity: why the -2 for our "good" upstart powerpc build? I already scored down all the ones that were pointless...
 * stgraber rescored to the original score and made sure all the others are at -2 or lower
<stgraber> we kinda want to confirm that upstart still builds on PPC, it's a pretty short build and we have a 99% change it won't hang like the last one (where I had to poke webops)
<infinity> stgraber: Oh, sure, have one.  I just scored them all down cause several seemed excessive.
<stgraber> infinity: you know, if only we had that nice cancel feature that the PPA have ;)
<jono> is anyone else getting lockups in compiz/unity in raring?
<infinity> jono: Intel graphics?
<jono> infinity, yep
<infinity> jono: Bunch of intel crashes in /var/crash?
<infinity> jono: It's probably https://errors.ubuntu.com/bucket/?id=[sandybridge-m-gt2%2B]%20GPU%20lockup%20%20IPEHR%3A%200x0b160001%20IPEHR%3A%200x0b140001%20Ubuntu%2013.04
<jono> infinity, yep, lots of them
<infinity> jono: (for the record, on my laptop, it can worked around by VT switching to VT1 and back to VT7 every time it freezes)
<infinity> Not that that's a pleasant workflow, but it avoids having to reboot. :P
<jono> infinity, yeah, I noticed that too, but when in multi-monitor it doesnt work
<infinity> Ahh, lovely.
<jono> I switch VTs and when I switch back I get nothing, just a black screen
<jono> infinity, is a bug filed for this?
<infinity> Well, if you have dual graphics on that thing, I might recommend switching to the ATI/nvidia for a bit.
<infinity> jono: It's the #4 crash on errors, the X guys are well aware of it.
<jono> ahhh sweet
<jono> thanks!
<infinity> jono: I'm sure there's a bug matching it somewhere, though I don't know or care what the number is. :P
<jono> np :-)
<oVeRMiND> hello world!
<zykes-> does Ubuntu / Debian have a equivelant to "repodata" as Fedora / RHEL things have?
<sarnold> zykes-: I don't know what the fedora repodata contains, but the Packages files contain a _lot_ of data, see 'apt-cache showsrc sed' for a quick example of some of the data available
<zykes-> sarnold: basically a overview of packages / files
<dobey> zykes-: the apt Packages info doesn't contain the files list for the packages, iirc
<zykes-> dobey: I basically need to get something equivelant to add .deb support to Pulp
<sarnold> ah, perhaps the apt-file package can help you?
<cjwatson> zykes-: Packages.gz if you're looking for metadata on binary packages; Sources.gz if you're looking for metadata on source packages; Contents-$ARCH.gz if you're looking for file lists
<cjwatson> all in the dists/RELEASE/ directories
<zykes-> cjwatson: is there any bindings in python to do this stuff ?
<cjwatson> python-debian
<cjwatson> handles a lot of it
<cjwatson> Probably not Contents-*, I forget
<zykes-> not python-apt ?
<cjwatson> Whether any distribution other than Debian-based ones has felt the need to package python-debian, I couldn't help you with ...
<cjwatson> python-apt does it too in a different way
<cjwatson> If you have it you can use it.  I suggested python-debian because it doesn't depend on the apt libraries
<zykes-> ok :)
<cjwatson> python-apt mostly wants to operate on an apt cache, but it does have the apt_pkg.TagFile class which parses files of the general format used in Packages and Sources
<cjwatson> The difference is basically that python-apt does the parsing in C++ via the apt libraries, while python-debian is in pure Python
<cjwatson> Both support Python 3 with sufficiently recent versions; python-apt is probably generally faster at runtime
<cjwatson> I often use a mix of the two depending on what I need
<zykes-> cjwatson: what's the whole non-free main universe multiverse stuff for ubuntu ?
<cjwatson> zykes-: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-sections
<cjwatson> zykes-: briefly, main -> free+supported; restricted -> non-free+supported (hardware drivers only); universe -> free+unsupported; multiverse -> non-free+unsupported
<cjwatson> although the meaning of "supported" there is currently fuzzy and so this is subject to change to fix that
<mterry> mpt, poke.  Looking at SoftwareUpdates spec.  In the "available updates" part, you say that if a package isn't a dependency of ubuntu-desktop, it shouldn't be a part of the "Ubuntu base" item.  Is that true even for packages that don't have .desktop files?  (i.e. xubuntu-common or some such?)
<cjwatson> Note that ubuntu-standard and ubuntu-minimal, and their dependencies, are intentionally not dependencies of ubuntu-desktop.
<cjwatson> (Essentially to avoid cascading problems when people decide they want to substitute their own piece there.)
<mterry> cjwatson, good note, thanks
<jtaylor> achiang: I filed bug 1091411, happy testing ;)
<ubottu> Launchpad bug 1091411 in Quantal Backports "Please backport valgrind 1:3.8.1-1ubuntu2 (main) from raring" [Undecided,New] https://launchpad.net/bugs/1091411
<achiang> jtaylor: thanks
<semiosis> fwiw, i just got a ppa upload rejected email from launchpad for some other user's ppa
<semiosis> i uploaded to mine & got rejected from someone elses
<semiosis> if anyone cares to look into it i can forward the rejection email & any other info you need
<semiosis> on second try i got an accepted email for my ppa
#ubuntu-devel 2012-12-18
<nuxusr> any news on a release date for ubuntu for android?
<xnox> mfisch: I hope no hard-feeling about quilt & bzr-bd ;-) it is slightly long-winded, but we are yet to come up with a more universally better way of handling them.
<mfisch> xnox: yeah I'm reading that now
<mfisch> xnox: why build with bzr bd and not just dpkg-buildpackage?
<xnox> mfisch: the developer guide /should/ be covering this. If it didn't, please point me to those pages & i'll try to fix them.
<mfisch> xnox: I'll go check there, I haven't read through it in awhile
<xnox> mfisch: (1) because that verifies that the branch matches, what the branch importer will expect in the future. (2) because it will allow "nesting" the packaging into e.g. upstream branch (3) because this makes sure recipes also work
<xnox> mfisch: and with merge proposals, I tend to go UDD way and actually check bzr diff & push the branch to lp:ubuntu/$pkg. For you to get karma =)
<mfisch> I was first doing debdiffs until that was suggested instead
<xnox> mfisch: also since this is a new upstream release, bzr bd will generate .orig.tar.gz tarball from pristine tar delta, which dpkg-buildpackage will not.
<xnox> i think the lack of .orig.tar.gz is the killing feature here. hard to include it with a debdiff, but easy with the bzr-bd style branch (thanks to pristine-tar delta).
 * xnox preffers UDD branches, but they do have quirks with respect to quilt patches.
<mfisch> xnox: why do the branches have the quilt patches pushed before checkin?
<xnox> mfisch: if I understood that question correctly, dpkg-source has patches applied => same approach was taken in the package-importer to push the patches and commit .pc. This way regardless of which method used (apt-get or bzr branch) the directory layout is the same and ready to push/apply a new ubuntu patch on top.
<xnox> apt-get source nano, will download source package, unpack & apply patches == $ bzr branch ubuntu:nano
<mfisch> that makes sense
<mfisch> xnox: and I never answered you but no hard feelings because I'm trying to learn
<xnox> dpkg-source does clever tricks and tries to check if the patches have/haven't been pushed/popped and tries to clever stuff - which breaks if patches have fuzz =/
<xnox> s/tries to/tries to do/
<GunnarHj> xnox: ping?
<xnox> GunnarHj: yeah?
<xnox> =) what's up?
<GunnarHj> xnox: It's about bug 1083605. I'm pretty sure it's a two step problem, and that the patch solves the first one.
<ubottu> Launchpad bug 1083605 in accountsservice (Ubuntu) "accountsservice doesn't set locale choice if /home is on nfs" [Undecided,In progress] https://launchpad.net/bugs/1083605
<GunnarHj> xnox: That would take care of the accountsservice issue. The rest of the problem lies elsewhere, possibly in pam.
<xnox> GunnarHj: ok. So you want that patch for raring. But is that patch useful on it's own as an SRU? Or will the SRU wait for a more comprehensive fix, e.g. together with a pam fix?
<GunnarHj> xnox: No, let's stick with raring for now.
<xnox> GunnarHj: ack.
<GunnarHj> xnox: Thanks in advance. :)
<mspencer_> Hi, I've started working on a program for Ubuntu called Contributor Console (https://launchpad.net/contributor-console). Would ubuntu-devel or ubuntu-devel-discuss be a good place to announce it?
<hyperair> i like how phoronix always has some way of portraying canonical as some unreasonable evil company that has no interest in its users wishes: http://www.phoronix.com/scan.php?page=news_item&px=MTI1NTI
 * hyperair sighs
<hyperair> Laney: ^ you're featured.
<sarnold> hyperair: probably any website that has a pop-up flash advert, an embedded flash advert, and uses those ridiculous double-underline unrelated ads can be ignored when they talk about "users' wishes" -- they obviously hate _their_ users...
<hyperair> sarnold: heh. i had forgotten about those. i've got adblock in place.
<sarnold> hyperair: not a bad approach, overall, but I do so little web browsing in places as offensive as phoronix that it's not really an issue.
<hyperair> sarnold: well you'll be surprised how much difference it makes, actually.
<hyperair> whenever i stare at someone else's screen browsing $website i keep wondering why it looks so much different from how it looks on mine
<hyperair> and then i realize there are all these ads on the side of the page.
<sarnold> hyperair: there's surprisingly little crap on your usual mail list archives, rfcs, and free-software wiki pages... :)
<hyperair> eh well, that's true.
<slangasek> you must be reading different rfcs that I am
<slangasek> ;p
<sarnold> slangasek: perhaps, I always go for the original .txt versions on ietf.org. Other goofballs might re-package the rfcs with flash ads and the like, but it's usually not too hard to avoid those :)
<hyperair> sarnold: M-x rfcview-find-rfc
<hyperair> ^_^
<sarnold> hyperair: hahaha
<sarnold> hyperair: I never got the hang of emacs. too complicated. but features like those sometimes make me wish I'd put in more effort to figure it out.
<hyperair> sarnold: yeah that's what i told myself back when i used vim.
<hyperair> and eventually i found enough time to put in the effort to figure it out
<hyperair> if i have any regret, it's that emacs is pretty crap when you start exhibiting rsi symptoms.
<sarnold> ouch
<hyperair> but vim makes my left wrist start making clicking sounds from continuously hitting Esc, so it's not much better.
<hyperair> i usually twist rotate my hand to get my middle finger on the esc key, see
<sarnold> heh, ^[ still works for esc in vim.
<hyperair> oh yeah that.
<sarnold> two hands, of course, but maybe less ohrrible than esc
<hyperair> i hadn't grasped the ^ things yet before switching to emacs.
<sarnold> but now you grasp the C- things just fine? :)
<hyperair> emacs is full of C- things ;-)
<hyperair> after a while you know what almost every ^[[:alpha:]_-?] means.
<hyperair> (there might be more)
<hyperair> also emacs usually has longhand commands with intuitive names to them if you can't remember the keybindings.
<hyperair> vim's commands are just.. weird.
<sarnold> .. how's that old yarn go? vi's easy! if you know what dw de d0 d$ dj dk dap do, then you know what cw ce c0 c$ cj ck cap do...
<ion> Vi(m) commands are mostly based on good mnemonics.
<hyperair> i recall a few, and to this day i still use vi movement keys for moving around pdf's in evince, and less and screen's copy mode
<sarnold> I've always wanted c% to work but it never seems to do what I want. I wonder if it groks ca% or ci%.
<ion> You donât really use the âvi movement keysâ a lot in vi.
<hyperair> but for the most part, they don't really make sense, and it's pretty hard to remember while you're starting out.
<ion> Sure, thereâs a learning curve.
<hyperair> ion: for viewing files they're pretty useful, though
<hyperair> w, e, b, hjkl
<ion> But they do tend to make sense. :-P
<sarnold> *sigh* no luck on ci% or ca%. :(
<hyperair> and i have no idea what ci% or ca% means
<sarnold> hyperair: % bounces between matched delimeters (){}[]<>
<ion> word, end, back, the-four-letters-from-h-in-qwerty-that-move-one-char-to-some-direction
<hyperair> ah
<ion> ci: change inner, ca: change a
<hyperair> er what does that mean?
<ion> di: delete inner (something), da: delete a (something)
<hyperair> oh inner as in everything between point and whatever else?
<ion> dip: delete the paragraph without deleting the empty line after it
<sarnold> hyperair: I often want to change the contents within () or [] or something, but the damned 'c' doesn't do what I want.. and just a few years ago I learned about ip iw ap aw for "inner paragraph", "inner word", "a paragraph", "a word" psuedo-range commands, but they don't apply to % :(
<ion> dap: delete a paragraph and the empty line after it
<hyperair> i never got the hang of those, but they're pretty cool
<ion> di{: delete between {} without deleting the {}
<ion> da{: delete between {} including the {}
<sarnold> ion: oooh?
<hyperair> hm
 * sarnold hugs ion
<ion> ya{: yank (copy) between {} including the {}
<hyperair> in emacs i usually do something like C-SPC C-M-n C-w
 * sarnold hugs ion again
<hyperair> i.e. start highlighting from point, step over balanced braces, and delete
<ion> ca{: change (delete and go to insert mode) between {} including the {}
<ion> Va{: visual linewise selection; select âaâ {} block
<sarnold> hyperair: heh, ^W will always mean just "kill word" to me, the idea of using ^W to delete more than a word would never fit in my head. :)
<hyperair> sarnold: i somehow manage to switch between modes when using the shell and emacs.
<sarnold> hyperair: hehe, that's good :)
<hyperair> sarnold: and somehow when browsing as well, or i'd end up trying to close a tab every time i wanted to C-w
<hyperair> sarnold: or closign the thunderbird compose email window when trying to cut text
<sarnold> hyperair: pentadactly for the win, ^W kills words in firefox too :)
<hyperair> sarnold: it gets more hilarious when my mouse is accidentally left on chromium, using focus-follows-mouse, and i'm staring at the emacs window in the other monitor..
<sarnold> hyperair: let the swearing commence...
<hyperair> then i hold down ^N to try to move down
<hyperair> and wheeee
<hyperair> ^P is equivalently hilarious
<hyperair> suddenly i get hundreds of print dialogs spawning
<sarnold> hahaha
<hyperair> if i don't end up swapping, it eventually stops
<sarnold> I normally just killed tabs.
<hyperair> and then thanks to my super+mouse2 binding to close windows in compiz, i can just hold down super and repeatedly middle click to close these windows
<sarnold> off to dinner :) thanks again hyperair and ion :D
<hyperair> :)
<hyperair> happy eating
<ion> âusing focus-follows-mouseâ Thatâs your problem right there. ;-)
<hyperair> ion: heh. i find it speeds up some use cases significantly
<hyperair> ion: for example, copy-pasting stuff between multiple windows
<hyperair> move mouse, ^C, move mouse, ^V
<infinity> hyperair: Or, hilight, move mouse, middle-click.  No need for focus to follow, since the click both raises and pastes.  Done.
<hyperair> infinity: middle click means you need to aim your mouse for the text box.
<hyperair> infinity: also i've turned off raise-on-click and auto-raise.
<hyperair> i often arrange my windows in an overlapping manner and don't want them rearranging the order when i interact with them
<hyperair> so i have them raise only on alt+click
<sladen> morgen
<pitti> Good morning
<dholbach> good morning
<Laney> hyperair: hoho, I saw that
<Laney> I must have Arrivedâ¢
<hyperair> hahahaha
<hyperair> yes you have
<Laney> surprised by the people I find reading that website ;-)
<vila> hi all !
<vila> after upgrading my precise desktop this morning (new kernel), I lost network connectivity :-/
<vila> I restored eth0 with ifdown/ifup (!!) but still lack dns. Does that ring any bell ?
<vila> kernel is 3.2.0-35
<cjwatson> semiosis: We don't operate the PPA service here - report issues to #launchpad rather than here, please
<xnox> vila: Support in in the #ubuntu channel. This channel is for developing ubuntu itself.
<hyperair> Laney: =O
<pitti> cjwatson, infinity: can you please add a manual britney blocking of the next pygobject which I'm about to upload?
<pitti> 3.7.3 is not very invasive, but still, I'd like to wait for all autopkgtests
<Laney> pitti: I can do that, doing
<pitti> Laney: thanks
<pitti> I'm currently fighting with "undefined symbol: Py_InitModule4_64" in the python2.7-dbg build, so upload might still take a while
<Laney> there we go
<pitti> that worked with earlier python2.7 versions
 * pitti yearns for the day when we do full autopkgtest runs for proposedâ release
<pitti> jibel: FYI, it seems the dreaded "hash sum mismatch" also affects our buildds: https://launchpadlibrarian.net/126071308/buildlog_ubuntu-raring-armhf.pygobject_3.7.3-0ubuntu1_CHROOTWAIT.txt.gz
<pitti> this is still a mystery to me; I would expect mirrors to do an atomic switch, i. e. sync dists.new, and then mv dists.new dists
 * pitti retries the build
<pitti> Laney: ok, all reverse depends succeeded; can you please unblock pygobject again?
<pitti> I think it's fine, the breakage with python2.7-dbg also happens with the current raring version, so that's not a regression in -proposed
<Laney> righto
<Laney> done
<xnox> pitti: atomic switch does not help. I download Release, atomic switch happens, I download Packages => I get checksum missmatch.
<xnox> pitti: even like Release & Release.gpg are racy, if I catch "atomic switch" in between.
<xnox> pitti: the current proposal is for mirrors to cache several versions of dists/ and redirect clients to the same one "throghout the apt-get update session" such that for all requests they get all files from related dinstall.
<mvo> https://code.launchpad.net/~racb/ubuntu/quantal/apt/by_hash
<xnox> that ^
<xnox> ;-)
<xnox> mvo: imho the "simple" work-around is for apt to actually tell me which repos/urls failed & redownload only those. But I don't see how I can run "apt-get update" on individual lines =(
<xnox> mvo: e.g. trap hash-missmatch & retry that repo.
<mvo> xnox: yeah, it can't just do based on deb-line
<mvo> xnox: but it will if-modified-since so at least it won't redownload stuff that is fresh
<xnox> mvo: architectural deficiency or consistency concerns?
<mvo> xnox: retry-once is indeed a good idea
<mvo> xnox: simply not-implemented
<xnox> mvo: /me has a winter project of: apt-getget wrapper that dpkg-redirects apt-get, traps stderr, greps for hash-missmatch and has a configurable (timeout of couple of seconds & retry up-to 3 times)
<Laney> O_O
<mvo> xnox: *cough* I hope with wrapper you mean "c++" ;)
<xnox> (e.g. you may catch a different repo missmatch, but not deadlock on really broken / mismatched repos)
<Laney> weird hacks when you have the source already
<xnox> mvo: /me likes wrapper cause then I can deploy it to precise on the cloud today.... but I guess we can cherry pick that.
<xnox> mvo: but that means I need to learn C++ =/
<mvo> apts c++ is not very fancy, its more c-with-classes, very few of the new stuff
 * xnox 's is also boost uploader..... which may or may not be disturbing.
<xnox> mvo: I see. Well I started poking it, noticed Joe Sixpack & no error codes.... (well just 100 on _any_ error)
<xnox> it would be nice at least to report a different error code on hash-missmatch.
 * mvo  nods
<xnox> mvo: you'd welcome such hacks? =) me thought retry would not be accepted upstream....
<hyperair> is there a proper way of disabling services in upstart yet?
<hyperair> (i.e. without hacking into the init file to comment out the "start on" line)
<Laney> I thought you create an override file or so
<Laney> http://upstart.ubuntu.com/cookbook/#disabling-a-job-from-automatically-starting
<hyperair> yeah i just read that
<hyperair> nice.
<hyperair> i didn't realize that method existed
<hyperair> is that documented anywhere?
<Laney> how isn't that documentation?
<hyperair> er
<hyperair> whoops
<hyperair> i misread that as askubuntu.com
 * hyperair was reading that
<xnox> hyperair: the beauty of the override files is that you can override any portion of the job file. E.g. echo exec mydaemon -vvvvv --debug >> /etc/init/mydaemon.override; will override the exec stanza to use different command line args.
<hyperair> yeah i noticed. nice.
<pitti> xnox: ooh, so that's it, not a non-atomic /dist update; thanks for pointing out
<zykes-> does python-debian contain helpers to read Packages files ?
<xnox> zykes-: one of python-debian or python-apt does.
<zykes-> not much docs for that xnox
<xnox> zykes-: look at reverse-depends code & use ipython. It seemed to be ok. Also unit-tests are descriptive.
<zykes-> xnox: where's the source code for the python-debian stuff ? Can't see the tests in the tarball
<xnox> zykes-: hmm... i thought it was there. maybe it was in python-apt instead...
<tumbleweed> I don't recall python-debain having unit tests
<zykes-> shoot me now ;p
<zykes-> looks like it does
<zykes-> https://code.launchpad.net/python-debian
<tumbleweed> oh, right
<semiosis> cjwatson: thanks for the pointer to #launchpad :)
<nuxusr> ubuntu for android -- any news on a release date? or a date for when they might give the release date :-)
<nuxusr> in other words, is santa going to deliver the package in time?
<xnox> nuxusr: this is not the right channel for general discussions around ubuntu. Please go to #ubuntu or even #ubuntu-offtopic or ubuntuforums.
<nuxusr> ubuntu for android isn't even released yet. I'm a developer looking for developers working on the project. isn't this the right channelâ¦.
<nuxusr> peeps in off topic don't even know the project exists ;-P
<xnox> nuxusr: no, here are developers that work on simply plain ubuntu raring as seen on archive.ubuntu.com. And only technical discussions happen here around packaging & developing ubuntu itself.
<xnox> nuxusr: no discussion of developer for / on Ubuntu Platform happens here.
<xnox> s/developer/development/
<marrusl> hi guys, does anyone happen to know if acroread will make its way back into partner?  if not, any idea why it was dropped?
<marrusl> adobe dropped support?
<xnox> marrusl: you can file a bug on launchpad against acroread package, then developers of canonical partner repository will be notified.
<marrusl> xnox, good call.
<slangasek> Laney: ping
<blackz> is there a rapid way to see sponsored packages for a user?
<xnox> blackz: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi
<blackz> xnox: thank you!
<Laney> hi slangasek
<slangasek> Laney: heya - how much do you understand about how valac works?
<slangasek> Laney: I'm trying to make it cross-build-friendly
<Laney> how in what sense?
<Laney> oh, like that, very little :-(
<micahg> slangasek: robert_ancell is a big vala fan
<slangasek> Laney: hmm, ok.  so the problem I'm up against is that valac-0.18 depends on libglib2.0-dev, which pulls in the native version even when cross-building, and making libglib2.0-dev co-installable will be non-trivial.
<slangasek> ah, robert_ancell is online now, he wasn't when I pung Laney ;)
<juliank> slangasek: Shouldn't libglib2.0-dev be easily co-installable? All architecture-specific files are in architecture-specific subdirectories already, as far as I know
<slangasek> juliank: no, it contains helper binaries in /usr/bin
<juliank> Ah, OK. Then maybe move them out to a new libglib2.0-dev-bin package, I hope that the binaries do not create architecture specific files, but I could be wrong (and Vala code and many glib projects most probably do not need them to build)
<slangasek> Laney, robert_ancell: so what I'm trying to figure out is why, when cross-building activity-log-manager with libglib2.0-dev:armhf installed and no special modifications, valac is perfectly happy; but if I then try to build some sample vala code I found, http://www.algonet.se/~afb/d/sample1.vala, it spits out pkg-config/gobject-2.0 errors
<juliank> Most binaries should not care about architecture.
<slangasek> juliank: in the longer term that's certainly something to be done, but right now I'm trying to sort out whether the valac dep is correct
<slangasek> because if valac *is* using the native libglib2.0-dev for any reason in this context, it risks getting the wrong answer
<juliank> OK, yes, then continue with this.
<xnox> slangasek: to be honest, valac generates portable C code, so either build the shipped c code in the source package and ignore vala bits.
<xnox> slangasek: or we need to teach valac to be cross-build friendly.
 * xnox needs to dig into vala again, I stopped touching it @ around 0.10
<slangasek> I'd prefer not to have to tell the world that they're doing vala wrong in their tarballs / source packages
<juliank> You can even still build the vala code to C, that should be independent of which libglib2.0-dev is installed/used. Then the C compiler compiles the C code, using standard autotools mechanisms
<juliank> In short: Vala should not care which glib2.0 is installed, as the C code it creates does not depend on the architecture.
<xnox> slangasek: so valac should run as native, and then cross-compiler used to build it further.
 * xnox ponders if that will require native libglib2.0-dev initially & :armhf later on.
<juliank> You actually shouldn't really need a libglib2.0-dev to build .c files from .vala forom
<robert_ancell> slangasek, hey. Is there an example I can do in raring?
<xnox> awesome.
<juliank> Vala still looks it up using pkg-config though, so it does not work.
<juliank> That is, It does not need to perform a pkg-config lookup when only building .c code; but currently does (AFAIK)
<slangasek> robert_ancell: well, I'm working with activity-log-manager; all its build-dependencies are cross-installable, *except* that valac-0.18 depends on libglib2.0-dev.  So it's hard to test this without first locally hacking the valac package
<slangasek> robert_ancell: but, let me paste the output from valac for the sample:
<slangasek> http://paste.ubuntu.com/1448544/
<juliank> slangasek: Try to hack valac to not do pkg-config lookups when building .c files.
<juliank> The pkg-config stuff is only needed when compiling the .c files to machine code anyway, so it should not be really required for building the .c files
<juliank> This should solve cross-building if the project uses autotools, as autotools will then use the correct libraries when compiling the C code to machine code.
<robert_ancell> slangasek, does "valac -C sample1.vala" give the same error?
<slangasek> robert_ancell: it does not
<slangasek> robert_ancell: I just noticed that difference in the commandlines, myself
<slangasek> do you think that justifies dropping the libglib2.0-dev dependency from valac?
<slangasek> (possibly dropping it to a recommends?)
<xnox> shouldn't valac call the correct arm-linux-gnueabihf-pkg-config instead then?
<robert_ancell> slangasek, well, there's two ways of compiling, the compile to C option which is what everything uses, and the automatic compile which I guess is doing something weird
<slangasek> xnox: that's not the question; the question is, can I drop the dep on libglib2.0-dev
<slangasek> if it's dropped, there's not guaranteed to be *any* usable pkg-config present when valac is called
<robert_ancell> slangasek, no, because in the "valac foo.vala" you can't compile a program
<juliank> robert_ancell: There are still Recommends for that case, though
<robert_ancell> because the generated C code uses glib functions and valac is going to have to compile it
<slangasek> robert_ancell: right, but recommends are installed by default, so in the non-buildd case libglib2.0-dev will be installed anyway; wouldn't that be enough?
<Laney> generating code without compiling it probably is a usecase worth supporting
<slangasek> in the buildd case, I suspect packages have a separate build-dependency on glib2.0
<robert_ancell> juliank, yeah, but it's going to be weird if valac fails to work (I haven't tried it)
<juliank> slangasek: I'd verify that before dropping a Depends, though.
<slangasek> yeah, I'm checking it now
<juliank> robert_ancell: Well, I hope that valac prints a reasonable error message in such a case.
<robert_ancell> slangasek, yes, I expect practically you can drop it as everything would depend on libglib2.0-dev directly or indirectly
<juliank> Debian has multiple packages build-depending on vala, but not on libglib2.0-dev; I suspect the situation is the same in Ubuntu.
<juliank> All of them seem to be GTK+ applications though, which means they indirectly pull libglib2.0-dev in.
<slangasek> robert_ancell, juliank: in practice, there's only one package in Ubuntu that doesn't pull libglib2.0-dev by other means: radare2-bindings
<slangasek> so given that for a cross-build, libglib2.0-dev:native is not the right package anyway, I think dropping this to a Recommends and adding a build-dep on radare2-bindings is reasonable.  Do you agree?
<Laney> mbiebl: ^- do you have any opinion on the above? (lowering valac Depends on libglib2.0-dev to Recommends)
<slangasek> valac-0.18 itself still invokes pkg-config directly, so if you're calling valac without -C it won't DTRT for cross builds
<slangasek> but that's a secondary concern at the moment
<robert_ancell> slangasek, is there a bug / solution for that problem?
<slangasek> robert_ancell: sorry, which part?
<slangasek> I haven't filed any bug reports anywhere yet
<robert_ancell> slangasek, the DTRT for running without -V
<robert_ancell> -C
<robert_ancell> slangasek, I'd like to fix that if I can, but I don't know the solution
<slangasek> robert_ancell: the solution is probably to honor $PKG_CONFIG in the environment and call it instead of pkg-config; I think that would be compatible with the autotools cross handling
<robert_ancell> slangasek, is $PKG_CONFIG a standard or a new thing?
<slangasek> robert_ancell: I'm not sure ;)  I know that it will be used as a make variable in the standard autotools setup, but I don't know if it will be exported to the valac process environment
<slangasek> robert_ancell: basically, you get the same behavior for both $CC and $PKG_CONFIG; so if they're exported, then you're set, if they're not then we would have to fix that first
<slangasek> robert_ancell: or, instead of using the exported variables, we could make this part of the valac automake rules
<robert_ancell> slangasek, if you use automake you're going to be using the -C option anyway so it should work
<slangasek> (valac --cc=$(CC) --pkg-config=$(PKG_CONFIG))
<slangasek> ah
<slangasek> in that case, I'd say just honor $PKG_CONFIG and if somebody's not using automake it's their problem to export it
<robert_ancell> slangasek, ok, I'll write a patch and send you the link. I don't think it should be controversial but I might need you to note why pkg-config should be configurable
<slangasek> robert_ancell: cheers :)
<zykes-> anyone tell me what's in http://ubuntu.uib.no/archive/indices/ ?
<robert_ancell> slangasek, does this look like what you need? http://paste.ubuntu.com/1448650/
<robert_ancell> i.e. you can "valac --pkg-config=pkg-config-armhf foo.vala" or "PKG_CONFIG=pkg-config-armhf valac foo.vala"
<slangasek> robert_ancell: yep, that looks about right to me
<robert_ancell> slangasek, is arm-linux-gnueabihf-pkg-config the sort of name we'd expect for a cross-compiling pkg-config?
<slangasek> robert_ancell: yes
<robert_ancell> slangasek, https://bugzilla.gnome.org/show_bug.cgi?id=690456
<ubottu> Gnome bug 690456 in general "Support configurable pkg-config so can cross-compile" [Normal,Unconfirmed]
<zykes-> is there a thing that can read the "content-<arch>" files ?
<xnox> zykes-: apt-file ?
#ubuntu-devel 2012-12-19
<cjwatson> zykes-: as I said yesterday, the apt_pkg.TagFile class can read Packages files
<cjwatson> zykes-: I'm not aware of any *library* that can read Contents-* files; in your context I think it's probably reasonable to knock together your own quickly
<ajmitch> cjwatson: I spotted an x lts backport package in -proposed that's in universe, xserver-xorg-input-mouse-lts-quantal. should this be promoted to main?
<cjwatson> ajmitch: yeah, moved (along with -keyboard-), thanks - but the whole thing probably needs a complete audit which I'm not going to do now :)
<ajmitch> I'm somewhat surprised you're still awake :)
<ajmitch> thanks for that
<cjwatson> just back from a Christmas dinner ...
<cjwatson> anyway I have fairly mutable hours, you should be used to that by now :P
<ajmitch> certainly
 * xnox declares defeated by cmakes inability to be cross-compiled (from bootstrap)... for now...
<cjwatson> xnox: dpkg-cross has helper bits for that
<cjwatson> ah, if you mean cmake itself not sure about that
<xnox> cjwatson: awesome, actually it does have cmake toolchain file, that should be possible to feed to cmake's bootstrap script.
<cjwatson> there's stuff in dpkg-cross' man page about how to use it, if that actually turns out to be helpful
<cjwatson> I fixed it to suck marginally less just recently
<cjwatson> but haven't actually got an entire package cross-building with it yet - just got past some initial obvious errors
<xnox> well, I was missing only 2 out of 9 magic variables needed to make it work. close but not enough. Will try cmake again later.
<xnox> cjwatson: how often new builds are tried as eventually seen on http://people.canonical.com/~cjwatson/cross/armhf/raring ? Approx. ~once a week?
<xnox> or is it continious?
<cjwatson> on request
<cjwatson> it's all still kind of manual
<xnox> fair enough.
<xnox> good night.
<cjwatson> xnox: I've poked it now - you should have updated results by the time you get up
<infinity> cjwatson: Oh, you don't have something importing to wanna-build on a regular basis?
<infinity> cjwatson: (And by "something", I'd mean quinn-diff, if it still exists)
<slangasek> cjwatson: will your reimport pick up new versions of build-dependencies that happen to land in raring now-ish?  The valac I've just uploaded probably unbreaks a bunch of build-deps, but I don't know how many
<psusi> banshee appears to have been misbuilt somehow... it lists depends that don't exist ( future versions )... how could this have happened?  build server misconfiguration?
<RAOF> psusi: In what release?
<hyperair> psusi: i saw your bug. where are you installing banshee from, and what version of ubuntu is that?
<infinity> psusi: apt-cache policy banshee?
<hyperair> huh, hang on, how old is libc6 2.6 anyway? the bug report complained that banshee was depending on libc6 2.7.
<infinity> Erm, wait, the complaint is about libc6?  What bug is this? :P
<infinity> We have 2.7 in hardy...
<hyperair> https://bugs.launchpad.net/bugs/1091942
<ubottu> Ubuntu bug 1091942 in banshee (Ubuntu) "Banshee is uninstallable due to broken depends" [Undecided,Incomplete]
<hyperair> that must have been a seriously old version of ubuntu..
<hyperair> and he probably plucked the deb out of a later release
<infinity> It does, indeed, list libc6 twice, but that's a non-issue (other than being weird).
<slangasek> banshee in raring does have a dependency on libc6 (>= 2.7), [...] libc6 (>= 2.16); but that's clearly not the cause of uninstallability
<infinity> So, I'd like to see the actual error message.
<slangasek> and it's installable here
<hyperair> infinity: it's probably a result of dh_shlibdeps and dh_clideps both running.
<infinity> (Why it's producing that dep is a different and curious question, mind you)
<infinity> Second-guessing shlibs is usually not smart.
<hyperair> no actually shlibdeps is smarter than clideps
<slangasek> hyperair: why would dh_clideps reference libc6 | libc6.1?  That's unhelpful
<hyperair> the issue is probably that ${shlibs:Depends} has libc6, and ${cli:Depends} has libc6 as well
<infinity> hyperair: Yes, shlibdeps is smarter, that was sort of my point.
<hyperair> slangasek: clideps just gets it from the .shlibs file.
<infinity> hyperair: shlibdes gets it right (>= 2.7), clideps is a lie. :P
<hyperair> slangasek: and clideps doesn't understand .symbols
<infinity> Anyhow, the libc6 dep there isn't causing an issue, it's just silly.
<slangasek> hyperair: it most certainly isn't doing so here
<slangasek> the libc6 .shlibs file lists libc6.  Only the libc6.1 .shlibs file lists libc6, and I'm pretty sure banshee wasn't built on an alpha.
<hyperair> i see libc 6 libc6 (>= 2.15)
<hyperair> but i don't see libc6.1.
<hyperair> hmm
<infinity> Right, but not 6.1 or 0.1
<hyperair> weird
<infinity> So something's doing that manually to work around some other braindeadery.
<infinity> Where does dh_clideps come from?
<hyperair> but i don't think dh_clideps does any weird things with libc6..
<hyperair> oh there is a hack in dh_clideps
<hyperair> if you grep -C3 libc6 /usr/bin/dh_clideps you'll see it
<infinity> Yeah, I'm there.
<infinity> And lost as to why anyone feels this is necessary.
<hyperair> because dh_clideps is arch:all
<infinity> If something links to libc6, dh_shlibdeps will pick it up.
<infinity> And if it doesn't, you don't depend on it...
<hyperair> dh_clideps parses .dlls
<hyperair> as in mono p/invokes
<hyperair> stuff that appears in ${cli:Depends} comes from parsed .dll's. if libc6 shows up there, that means a mono .dll or .exe has a DllImport of libc6.
<infinity> s/libc6/libc/, surely.
<hyperair> whichever
<infinity> Otherwise, there's no way this hack would work. :P
<hyperair> eh well
<hyperair> it's overridden in /etc/mono/something
<hyperair> <dllmap dll="libc" target="libc.so.6" os="!windows"/>
<hyperair> yeah libc
<infinity> I'm beginning to be sorry I asked.
<hyperair> :)
<infinity> Anyhow, those deps can all be satisfied, so I'm still curious what psusi's bug is about.
<hyperair> see, the issue is that windows's .NET engine has no support for remapping library name imports
<hyperair> only mono does. so you have to target windows, and map it back to the appropriate one on other platforms
<hyperair> well this whole ugliness only happens when you try to call native code from within managed code
<hyperair> oh i see the culprit has vanished.
<slangasek> he's busy time travelling with his warty system
<hyperair> hahah
<hyperair> i wonder if i should wait or if i should just mark the bug invalid immediately
<infinity> My guess would be a multiarch issue clouding things.
<hyperair> eh maybe
<infinity> Since that sort of thing can get apt to print unhelpful messages that look like "all your libraries aren't installable", as he claimed.
<hyperair> especially if you try to use aptitude
<hyperair> that bug's still not fixed
<infinity> Just double-checked, and banshee's installable on precise/quantal/raring.
<hyperair> great
<infinity> Now, back to packaging glibc 2.17, which will obviously solve his problem.
<infinity> Since 17 is a pretty big number.
<pitti> Good morning
<pitti> ah, UDD discussion round umpteen
<dholbach> good morning
<Laney> pitti: shall we start a systemd/upstart thread to distract everyone? :-)
<pitti> Laney: christmas holiday, the time for harmony :)
<Laney> you need the flames to keep you warm in this cold cold winter
<pitti> we need upstart maintained in UDD with a graphical Unity shell that sends all your system events to amazon
<pitti> and with naked people, of course!
 * pitti wonders if the old warty backgrounds package still exists somewhere in the mists of the interwebs
<dholbach> naked people!
<dholbach> pitti, if you search on images.google.com for 'ubuntu calendar' you should be able to find them :)
<pitti> http://ubuntu.ecchi.ca/wallpapers/, at the very bottom
<persia> http://old-releases.ubuntu.com/ubuntu/pool/main/u/ubuntu-calendar-*/...
<hyperair> heh
<Laney> RAOF: still here?
<Laney> banshee was released into quntal-updates but it's uninstallable
<Laney> Depends: libglib2.0-0 (>= 2.34.1) but 2.34.0-1ubuntu1 is to be installed
<Laney> can I query e.u.c somehow to see if any instances of a crash have the SRUed glib installed?
<cjwatson> infinity: I haven't made it regular because wanna-build's merge algorithm tends to involve retrying uninstallable-build-dep failures over and over again, and there are hundreds of those here so I don't want to overdo it - for now, I have a script I run every day or two
<cjwatson> slangasek: should build against current raring+raring-proposed as of whenever the build starts - I'm not using an imported archive to satisfy build-deps or anything
<Laney> I checked a lot of instances of bug #1044322 on e.u.c and none had the -proposed glib installed
<ubottu> bug 1044322 in glib2.0 (Ubuntu Quantal) "indicator-messages-service crashed with assert in g_menu_exporter_name_vanished()" [Medium,Fix committed] https://launchpad.net/bugs/1044322
<Laney> someone SRUy please to be advising
<caribou> If I need to modify an existing Quilt patch in a package, and I'm working off the bzr branch, is it expected to have the ./pc quilt files included in the merge proposal ?
<caribou> I did "quilt pop; {modify the patch};quilt push;quilt refresh" to update the patch, so some of the ./pc files got also modified
<caribou> another way at it would be to work off the source package & submit a debdiff (this is for an upcoming SRU btw)
<xnox> caribou: yes, please do "$ bzr add .pc" before committing.
<xnox> caribou: easy test - $ bzr bd -S, should work. SRUs are typically easier to sponsor with debdiffs though.
<pitti> +1
<pitti> UDD is just an unnecessary pain for both sides for SRUs
<caribou> xnox: depends who I talk to :) some teams have asked me for Merge Proposals
<pitti> (IMHO with my sponsor hat on)
<Laney> the sponsoring into Ubuntu side is smoother with a diff
<Laney> you might want MPs at some other stage, like submitting upstream
<persia> Do the importers not import all the -security and -updates uploads?
<persia> If not, is there a bug about this?
<xnox> (when I say "easier" I imply that a subjective majority of sponsors prefer that. I prefer UDD branches for everything: as then it doesn't matter if it's a new package, SRU, merge, new upstream release & i can work with it)
<caribou> pitti: I tend to agree too; working off the source pkg/debdiff is easier for most of the changes
<pitti> they do, but an MP for the first-ever SRU doesn't work as there is no branch to propose _to_
<pitti> and then, almost nobody can modify the status of those MPs, so everyone pings me about "please close/reject/wip this branch", etc.
<persia> Oh, there's no "we're releasing now, so populate all the release branches" action?
<pitti> plus, UDD and quilt patches are just a pain
<xnox> caribou: I find bzr branches to be the best tool to create the debdiff: out of tree builds are awesome and vcs is awesome for work-in-progress. In the end generate a source package, debdiff & done.
<persia> Why?  I thought the advantage of UDD was to have stuff in branches to generate diffs, etc.  With Format:3.0(bzr) being quite as experimental as it is, I would expect everyone to use quilt.
<pitti> xnox: you obviously do not work a lot with debian/patches/ :)
<xnox> heh, I do =)
<pitti> for native packages I fully agree
 * xnox has scripted around quilt patches.
<pitti> but UDD only keeps precisely those bits under "proper" version control which we are not interested in modifying
<persia> Oh, that's a different problem then :)
<pitti> but with the bits that we do it still requires quilt, plus keeping track of pre-applied patches in the actual source, not forgetting .pc, and so on
<pitti> oh argh, I'm being drawn into that discussion again, I'll STFU
<Laney> :D
<caribou> xnox: from a bugfixing pow, debdiff are simpler, but I can understand the value of UDD from a developer's pow
<persia> pitti: Sorry for dragging you into that discussion: I did appreciate the better understanding.
<caribou> pitti: thanks for the clarification though :)
<pitti> heh, no worries :)
<hyperair> bug #1091942
<ubottu> bug 1091942 in banshee (Ubuntu) "Banshee is uninstallable due to broken depends" [Undecided,Incomplete] https://launchpad.net/bugs/1091942
<hyperair> it looks like banshee was released from -proposed before its dependencies.
<Laney> fixed
<hyperair> ah
<hyperair> thansk
<hyperair> Laney: as in, glib has been released from proposed?
<Laney> right
<hyperair> okay, thanks
<Laney> I saw you talked about it last night, how come nobody did it then?
<hyperair> because nobody knew what was wrong
<hyperair> psusi filed a bug report with hardly any information
<Laney> but it was uninstallable in updates
<hyperair> it just said that "a lot of libraries had the wrong version" but it didn't say which ubuntu he was running
<hyperair> in fact, he said that banshee depended upon libc6 2.7
<hyperair> while he only had libc6 2.6
<hyperair> that really threw us off
<hyperair> libc6 2.6 was during hardy.
<hyperair> before that, even, since it looks like hardy has 2.7
<RAOF> Oh, urgh. Why did banshee pick up a depend on that glib? Stupid dh_clideps.
<pitti> http://people.canonical.com/~ubuntu-archive/testing/precise-updates_probs.html FYI
<hyperair> heh
<pitti> RAOF: or precise-proposed's  glib bumped shlibs?
<hyperair> that's most probably it.
<hyperair> it could be -V
<Laney> not precise, quantal
<RAOF> pitti: That would be unusually obnoxious.
<Laney> and it has symbols
<Laney> which clideps doesn't understand ...
<hyperair> yes, clideps only uses shlibs
 * hyperair brb. leaving work
<RAOF> You know, I bet it wouldn't be *that* hard to get clideps to use symbols.
 * RAOF foretells of some more godforsaken perl hacking in his future.
<mlankhorst> RAOF: can you clear the x sru queue for precies? :>
 * RAOF did a bunch of precise unapproved clearing this morning.
<RAOF> mlankhorst: What are you after? Not that I'll get to it today; it's 10pm.
<mlankhorst> RAOF: 'xorg' + blobs
<cjwatson> jibel: Hi - did you get my mail with further questions about britney/autopkgtest integration?
<cjwatson> I was hoping to make some progress on that before EOY but am blocked on those questions
<jibel> cjwatson, Hi, I did, I've been side tracked by other things and delayed my reply, sorry, replying now.
<cjwatson> great, thank you
<pitti> ev: s3 merge> yay! that means the charms can now be updated to just lp:daisy?
<blackz> cjwatson: so is bug #917708 officially fixed? can the "workaround" applied to affected packages be dropped?
<ubottu> bug 917708 in Launchpad itself "Launchpad does not recognize Arch = any-arm" [Low,Fix released] https://launchpad.net/bugs/917708
<cjwatson> blackz: yes
<cjwatson> blackz: I didn't know there were outstanding workarounds or I might have dropped them myself :)
<blackz> cjwatson: https://launchpad.net/ubuntu/+source/bitcoin/0.6.2.2-1ubuntu1 for example
<cjwatson> feel free to revert that
<bambee> Hi, nvidia-current does not build with linux-image 3.5.21-generic on precise  (there is a 3.5 kernel packaged on precise)
<ev> pitti: yes :)
<ev> pitti: working on integrating it into lp:~ev/daisy/prodstack-prep
<xnox> bambee: but nvidia-updates does build.
<xnox> bambee: also note ubiquity sru comment: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1070427/comments/24
<ubottu> Ubuntu bug 1070427 in ubiquity (Ubuntu Quantal) "Ubiquity removes kernel headers, fails to build nonfree drivers" [High,Triaged]
<bambee> nvidia-current-updates you said, interesting, looking
<bambee> thanks
<jibel> cjwatson, I replied and updated the interface on lillypilly to never overwrite sources.list, so it can uses the apt index directly.
<jibel> pitti, I finished enabling jhbuild for gnome on raring
<jibel> https://jenkins.qa.ubuntu.com/view/Quantal/view/JHBuild%20Gnome/
<jibel> it's written Quantal but is really Raring
<jibel> I filled a ticket to have that changed
<jibel> pitti, currently it builds gnome-core moduleset, check is disabled
<pitti> jibel: merci! il semble mieux que j'ai pensÃ©
<jibel> pitti, indeed, I think I can enable checks, what do you think?
<pitti> jibel: in my jhbuild I have quite a lot of failures, but indeed let's enable them so that we have something to point to for upstream reports
<pitti> that's the point anyway
<pitti> jibel: any idea what this is about? https://jenkins.qa.ubuntu.com/view/Quantal/view/JHBuild%20Gnome/job/jhbuild-amd64-gnome-doc-utils/1/console
<pitti> ah, so control-center is an actual bug, it shouldn't hard-depend on systemd
<caribou> xnox: I'm preparing the SRU for https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368 on Precise
<ubottu> Ubuntu bug 833368 in resource-agents (Ubuntu) "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [Undecided,In progress]
<caribou> xnox: should there be a specific task for Precise in the bug ?
<jibel> pitti, wrt. gnome-doc-utils, I started the build while there is nothing to build, and it was waiting for something that will never happen
<pitti> jibel: ah, so that was a genuine timeout
<caribou> xnox or anyone who can answer, just so happen that he is assigned to that bug
<xnox> caribou: well, I need to sponsor this into raring first before it goes into precise. & also sru for quantal will be needed.
<caribou> xnox: it's already fixed in Q & R
<caribou> xnox: let me double check again, but I tested both and only found the bug in Precise
<xnox> caribou: ok, I have adjusted statuses and opened the task for precise. please correct me if the per-series tasks are wrong now.
<caribou> xnox: looks good. I'll assign myself to the bugs and will check with ivoks on the resource-agent side when he's back from vacation
<caribou> xnox: just checked Quantal and it is indeed fixed but I'll confirm with ivoks
<ivoks> heh?
<ivoks> caribou: act fast; i'm not on vacation today and tomorrow; but i will be starting on friday :)
<caribou> ivoks: so will I, so I want this one SRUed before I leave
<ivoks> caribou: xnox first glance is that this bug is *invalid* in Q and R and will be invalid in P once lvm2 monitoring bug is fixed
<xnox> ivoks: are you saying that resource-agents should not be part of the bug at all?
<ivoks> xnox: caribou overall view of the problem is that clustered lvm requires monitoring to be on
<ivoks> xnox: caribou in ubuntu, default is monitoring off
<ivoks> xnox: caribou and it's off by a change in the code, not by choosing within lvm.conf
<ivoks> xnox: caribou resource-agents assumes that monitoring is set to on, if one wants to use it
<ivoks> xnox: caribou since we disable monitoring in the code of lvm, even if someone enables monitoring in lvm config, that setting is ignored
 * xnox really should setup & learn clustered lvm & add automatic tests for it.....
<ivoks> xnox: caribou therefore, user enables monitoring in lvm.conf and finds out that lvm commands still don't enable monitoring
<ivoks> xnox: caribou once we fix lvm in precise to use config option to disable monitoring, instead hardcoding it in the code, all problems go away
<caribou> ivoks: this is the SRU I'm preparing, right ?
<ivoks> caribou: correct
<caribou> ivoks: the one we discussed yesterday
<caribou> xnox: ivoks: the debdiff is ready, changes tested on precise so the SRU is about to go
<ivoks> if you need help in testing it, let me know
<xnox> caribou: well, attach debdiff to the bug report & i can test & sponsor it.
<caribou> ivoks: I've tested monitoring = [0|1] in /etc/lvm/lvm.conf and it works as designed
<xnox> caribou: note that for an SRU the bug description should match https://wiki.ubuntu.com/StableReleaseUpdates?action=show&redirect=StableReleaseUpdate#SRU_Bug_Template
<ivoks> caribou: and without the rest of the changes in the code?
<caribou> xnox: yep, was waiting for the Precise task you just added to add the SRU template
<caribou> ivoks: with the patch you gave me yesterday
<ivoks> caribou: excellent
<caribou> ivoks: it basically reverts the hardcoding and changes doc/example.conf.in
<ivoks> yep
<ivoks> caribou: you might build that package and ask people in the bug 833368 to test it
<ubottu> bug 833368 in resource-agents (Ubuntu Raring) "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [Undecided,In progress] https://launchpad.net/bugs/833368
<caribou> ok, I'm updating the template then will subscribe the proper people to it
<caribou> ivoks: I already have a PPA ready for testing if someone wants to
<ivoks> caribou: there are few candidates in that bug
<xnox> ivoks: well testing a package from ppa will not speed up sru.... as we want people to test the -proposed package.
<ivoks> xnox: ah, right
<caribou> xnox: yeah, usually I refrain from doing that, so people don't end up using my PPA instead of the fix
<caribou> ivoks: and building a new pkg from the debdiff can be done if they want to
<xnox> caribou: ivoks: as far as I understand resource-agents task should be removed or  marked as "invalid" since the bug is in the lvm package.
<ivoks> caribou: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368/comments/31 target this guy
<ubottu> Ubuntu bug 833368 in resource-agents (Ubuntu Raring) "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [Undecided,In progress]
<caribou> ivoks: ok
<ivoks> caribou: ask him to revert his changes
<ivoks> caribou: and, of course, test the package from proposed, including changing monitoring to 1 in lvm.conf
<caribou> ivoks: yep, that will be done as well
<vibhav> Are ubuntu-sponsors automatically suscribed when a merge proposal is created?
<slangasek> if the merge is targeted to the right branch, yes
<Laney> check http://reqorts.qa.ubuntu.com/reports/sponsoring/ if you're in doubt
<vibhav> slangasek, Laney: thanks
<jibel> pitti, look http://10.98.0.1:8080/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-nautilus/2/ failed
<jibel> pitti, commit was 34 min ago :)
<jibel> looks like our testing is working
<jibel> https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-nautilus/2/ for the public address
<Riddell> doko: do you know if python2.7 has had recent multiarch changes?
<doko> Riddell, yes
<Riddell> doko: mm, poor old cmake seems to be confused
<doko> Riddell, about what?
<xnox> Riddell: i almost have a working patch for cmake to unbreank FindPython
<xnox> Riddell: sorry for the delay.
<Riddell> doko: it can't find pyconfig.h which has been moved to a multiarch dir
<Riddell> xnox: oh?
<Riddell> I'm using this workaround currently http://paste.kde.org/627974/
<xnox> Riddell: do you know who did original debian-multiarch patches for cmake? /me wants a review.
<xnox> Riddell: that workaround is fine, but it does not scale across all of cmake code for python2.7 =/
<Riddell> xnox: might have been slangasek?
<xnox> (there were only a couple of packages for python3)
<slangasek> xnox: MoDaX did them
<xnox> slangasek: heh a comrade =)
<jbicha> doko: were you interested in working on bug 914631 ?
<ubottu> bug 914631 in mesa-demos (Ubuntu) "[mir] mesa-demos" [Wishlist,Confirmed] https://launchpad.net/bugs/914631
<doko> not now
<pitti> jibel: hah -- unpackaged/undeclared dependency
<doko> xnox, when will you commit the cmake fix? wanting to start the test rebuild tomorrow
<xnox> doko: ha. ok. let me do the cmake fix now & come back to upstart tomorrow.
<hrw> does someone here has Samsung Chromebook (arm one)?
<armor_xt> hello everybody, short question: is it possible to find out which packages are depending on an individual one? e.g. which packages are depending on libc
<stgraber> armor_xt: apt-cache rdepends
<stgraber> though the outpout for libc6 may be pretty long ;)
<stgraber> (16k)
<armor_xt> great, thank you!
<armor_xt> I was looking in the apt-get *cache evironment, but couldn't find it
<armor_xt> stgraber, *lol* was just an example
<infinity> stgraber: apt-cache rdepends is poorly-named, it actually lists packages with *any* relationship (including breaks and conflicts)
<infinity> armor_xt: reverse-depends from ubuntu-dev-tools is a bit more reliable on this score.
<infinity> (And also acts on all architectures, rather than just the one(s) you have in your apt cache)
<stgraber> infinity: indeed. Main brain still isn't used to reverse-depends (and reverse-depends -b for build-dep) :)
<Laney> src:foo is awesome too
<infinity> Of course, the CGI may be having a hissy fit right now.  I can't get it to spit out any useful responses...
<infinity> Oh, there it goes.  Probably just overloaded.
<gotwig> jo
<gotwig> Are ubiquity dev's available?
<gotwig> Can you tell me where can I change the font for the terminal in ubiquity while installing?
<gotwig> at the bottom
<stgraber> that'd be in the gtk theme
<stgraber> we don't explicitly configure the theme for that part of the ubiquity UI, we just use the standard gnome vte widget
<gotwig> I talk about changing the font, the installer uses for the embeded terminal
<gotwig> the font is different for the embedded terminal.
<gotwig> that is not ubuntu mono
<stgraber> gotwig: oh, actually, we do hardcode the font
<stgraber> ./ubiquity/frontend/gtk_ui.py:        self.vte.set_font_from_string("Ubuntu Mono 8")
<gotwig> lol? xD
<gotwig> stgraber, thank you for your quick help
<gotwig> stgraber, may I show you the bug report, I want to fix?
<gotwig> https://bugs.launchpad.net/bugs/1072426
<ubottu> Ubuntu bug 1072426 in elementary OS "Ubiquity using incorrect font for monospace output" [Low,New]
<gotwig> When I would change the font to e.g Droid Sans Mono, would it use that font for the terminal?
<infinity> Could it be that your image isn't shipping "Ubuntu Mono" in the live environment, and X is doing a near-match lookup and finding something uglier?
<slangasek> infinity: on your system where you get the "disk drive for /tmp is not ready yet" error, do you have crypted swap (on its own partition, not via LVM)?
<stgraber> gotwig: you can try, just edit gtk_ui.py directly on the live media
<infinity> infinity: Nope, no LVM or encryption on this machine.
<stgraber> gotwig: it should be either under /usr/lib/ubiquity/ or /usr/share/ubiquity/ (can't remember, sorry)
<infinity> slangasek: Just a big, fat /
<gotwig> stgraber, can you tell me, how to test such stuff, demo an installation :X?
<slangasek> infinity: no crypted swap, even?  Ok, then that's not a commonality with bug #1091792, drat
<infinity> slangasek: Though, I haven't seen the bug since I reinstalled, so maybe I accidentally made it go away. :/
<ubottu> bug 1091792 in mountall (Ubuntu) "The disk drive for /tmp is not ready yet or not present" [Undecided,New] https://launchpad.net/bugs/1091792
<slangasek> heh
<stgraber> gotwig: you could write a gtk software using the same vte code, or just run a test install in a vm
<infinity> slangasek: I reinstalled to correctly 4k-align my partitions (and switched from GPT to MBR at the same time and ditched EFI), so I've probably changed far too many variables to be of use.  Unless the bug comes back anyway.
<gotwig> thank you really much
<slangasek> you *ditched* EFI?  Luddite
<infinity> slangasek: I sure did.
<hrw> can someone upload packages from bug #1085392 so SRU process can start?
<xnox> gotwig: usually on #ubuntu-installer channel, what's up?
<ubottu> bug 1085392 in Cross distro support for Samsung Chromebook (ARM based) "Merge Chromebook UCM profiles into ALSA packages" [Critical,Triaged] https://launchpad.net/bugs/1085392
<gotwig> xnox, I've already got help I guess, thx
<infinity> hrw: Why are we SRUing Chromebook userspace support back to Q and P?  It's not like we ship kernels.
<hrw> infinity: because users use 12.04 and 12.10 with chromium kernel?
<slangasek> infinity: I think this falls under the "hardware non-disablement" policy for SRUs, doesn't it?
<hrw> infinity: I created chromium kernel package today - will build for my ppa in 14+ hours
<slangasek> (we don't have to support the hardware, but maybe we shouldn't set it on fire :)
<infinity> slangasek: Yeah, in this case, I'm okayish with it because it melts laptops.
<infinity> slangasek: I'd forgotten about that until I re-read the bug and the test-case. :P
<slangasek> :-)
<hrw> :)
<infinity> hrw: I'll look at both these diffs.  I have a nagging suspicion I might also need to re-fix PandES in Q while I'm at it (as I did with the R upload)
<hrw> infinity: iirc Q has pandaes but P does not
<infinity> Oh, so maybe the ES stuff was dropped between Q and R?  That could be.  I forget the history.
<infinity> Anyhow, I'll poke 'em sometime today.
<hrw> infinity: thanks
<cjwatson> slangasek: vala cross> you seem to have managed to get unity-lens-music and unity-lens-shopping cross-building, at least
<slangasek> huzzah
<infinity> slangasek: Good job on fixing the most contentious package in the archive?
<slangasek> infinity: which one is that?
<infinity> (unity-lens-shopping)
<slangasek> ah, heh
<xnox> doko: the fix will make sure that PYTHON_INCLUDE_DIRS has the correct both paths & work for all pythons[2,3]. but many packages still use deprecated PYTHON_INCLUDE_PATH & those will still need manual fixing.
<slangasek> pff, why is gobject-introspection FTBFS due to a *libtool-generated linker script*?
<slangasek> ah, because I screwed up a symbol name, hee
<slangasek> barry: ping
<barry> slangasek: pong
<slangasek> barry: hey, so I have most of a python3 port now at lp:~vorlon/ubuntu/raring/gobject-introspection/python3/
<slangasek> barry: the most recent "last" issue I have is DictMixin -> MutableMapping telling me that I need to implement __len__ and __iter__... where would I find documentation on the right way to do this?
 * barry looks
<barry> slangasek: this has some examples:http://docs.python.org/3/library/collections.abc.html#collections.abc.MutableMapping
<barry> slangasek: and this some additional background: http://docs.python.org/3/reference/datamodel.html#object.__len__
<gotwig> stgraber, it worked. Thx
<slangasek> xnox: mdeslaur seems to have found your ubiquity-desktop-background-broken-in-raring-VM bug
<slangasek> xnox: bug #1080674
<ubottu> bug 1080674 in xserver-xorg-video-cirrus (Ubuntu) "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Undecided,Confirmed] https://launchpad.net/bugs/1080674
<xnox> aha. good.
<xnox> doko: Riddell: cmake uploaded, if packages use standard FindPythonLibs & PYTHON_INCLUDE_DIRS they should be all multi-arch ready.... if not patch them to use system FindPythonLibs & PYTHON_INCLUDE_DIRS (instead of _DIR or _PATH)
<cjwatson> slangasek: IIRC I did that in python-debian, if you want a cargo-cult source for MutableMapping stuff
<cjwatson> or maybe in germinate
<slangasek> cjwatson: barry hit me over the head with a pointer to the stock OrderedDict instead :)
<barry> collections.OrderedDict
<cjwatson> if that's appropriate, sure :)
<cjwatson> IIRC it requires 2.7, so upstream might raise an eyebrow
<barry> yeah, i was gonna ask how far back you needed to support
<slangasek> I just wrapped the import with a try
<slangasek> they can fall back to their existing implementation for python2.6, that's fine
<cjwatson> OK; failing that I believe MutableMapping is in 2.6
<cjwatson> which I believe is the approach I took in germinate, albeit for something less stock than an ordered dict
<slangasek> barry: why does file.write() want a string instead of bytes?
<slangasek> barry: or perhaps a better question is, if I have a stream of bytes that I want to shove out an fd, how can I do this without having to convert it to unicode and back? :P
<cjwatson> depends on the mode in which the file has been opened
<cjwatson> mode="wb"
<slangasek> oh, I need 'b'
<slangasek> right, thanks
<cjwatson> also if it's literally an fd then os.write always takes bytes
<slangasek> cool, no more python parse errors from gir, now I just get a segfault to track down ;)
<barry> sorry, i was making tea :)
<gotwig> barry, :O
<slangasek> ok... and pdb fails
<slangasek> anyone know what this is? http://paste.ubuntu.com/1450819/
<slangasek> I shouldn't think that 'import os' would be a problem for pdb :P
<barry> slangasek: are there c extension modules involved, or is this pure python?
<slangasek> barry: there's a C extension
<slangasek> so I have a perfectly fine C backtrace in gdb
<barry> slangasek: my first suspicion when there are incomprehensible tracebacks and c extensions is that the c extension is broken somehow.  something's not checking a return value or some mess in refcount.  never makes it easy to find unfortunately
<slangasek> barry: would you mind having a look at my gobject-introspection/python3 branch and seeing if anything jumps out at you as broken in the C extension porting?
<barry> slangasek: sure
<barry> slangasek: the url above?
<slangasek> yes, lp:~vorlon/ubuntu/raring/gobject-introspection/python3/
<slangasek> segfault seems to be pygi_source_scanner_parse_macros() getting passed an empty list as an argument, and segfaulting deeper in the code for some reason
<slangasek> not sure if that empty list points to a bug in the C extension porting, or an issue in the python code
<barry> slangasek: unrelated, but maybe useful: http://docs.python.org/3/c-api/none.html?highlight=py_return_none#Py_RETURN_NONE
<slangasek> ok
<slangasek> ah, definitely a C extension bug
<slangasek>       filename = PyUnicode_AsUTF8 (obj);
<slangasek> somehow that's returning NULL for each one
<barry> slangasek: in type_get_child_list(), you should check that PyList_New doesn't return NULL
<barry> and that PyList_SetItem() doesn't return -1
<slangasek> well
<slangasek> I should also check that I've spelled 'PY_MAJOR_VERSION' right everywhere :-)
<barry> also, i don't think you need to incref list since PyList_New returns a new reference
<barry> that too :)
<barry> also, in pygi_source_scanner_parse_macros(), you should incref list while inside the function, and decref it on exit from the function
<barry> since PyTuple_GET_ITEM steals a reference
<barry> (and i'll just assume that pygi_source_scanner_parse_macros() actually does get called with args as a tuple ;)
<slangasek> barry: mind throwing me a patch for those?
<barry> slangasek: why don't i just do a branch from your branch? :)
<slangasek> sounds good :)
<slangasek> I'm past the segfault due to the swapped python3/2 code branches; now I'm finding that OrderedDict may not be sufficient after all :)
<barry> dang
<slangasek> ah no, this is 'itervalues', that's a python2ism anyway
<barry> which i'm guessing you probably don't need.  is the dict so big that a concrete list of its values will kill memory?
<slangasek> probably not?
<barry> right, so just use .values() :)
<barry> probably
<barry> i.e. you don't have itervalues() in py3, but .values() always returns an iterator in py3
<barry> for loops won't care
 * slangasek nods
<barry> slangasek: oh.  does g_list_append() create a new object if its first argument is NULL?
<slangasek> barry: evidently, since it doesn't crash ;)
<barry> :-o
<barry> ;)
<barry> well, i could either try to dig up the gobject api docs or just roll with it :)
<barry> slangasek: apparently so... -ish: http://developer.gnome.org/glib/stable/glib-Doubly-Linked-Lists.html#g-list-append
 * slangasek nods
<slangasek> bryce: have you seen the comments on bug #1041063, and bug #1091976? the patch author asserts that this SRU is broken
<ubottu> bug 1041063 in xorg-server (Ubuntu Raring) "mouse pointer periodically leaps to left and top of screen with absolute pointing devices" [High,Fix released] https://launchpad.net/bugs/1041063
<ubottu> bug 1091976 in xorg-server (Ubuntu) ""fix" uploaded to precise-proposed for a bug that doesn't exist" [Undecided,New] https://launchpad.net/bugs/1091976
<hallyn> hi - for bug 589063, the SRU fix for lucid-proposed was not verified in time.  someone just asked that it be re-uploaded, they can verify they claim.  Should I d/l and re-upload the .dsc from the Done queue (i see it there), or can someone just click a button to move it over?
<ubottu> bug 589063 in seabios (Ubuntu Lucid) "Windows Server 2008 won't boot with more than 4 vCPUs" [Undecided,Triaged] https://launchpad.net/bugs/589063
<barry> slangasek: what's a good way to test this, or do you just want my untested branch?  i'm probably being a bit over-paranoid, but better to be over than under ;)
<slangasek> barry: well, so far building the package has been a very good test, it hasn't passed yet ;)
<barry> k
<barry> slangasek: hmm:
<barry> checking for python module mako... no
<barry> configure: error: Could not find python module: mako
<barry>  
<barry> python-mako needed?
<slangasek> barry: should only need python3-mako
<slangasek> oops
<slangasek> I didn't update debian/control.in
<barry> ah
<mako> people talking about mako again
<barry> mako: hi!
<mako> greetings! :)
<slangasek> barry: fix pushed
<slangasek> mako: hey, I heard something about you being back on this side of the continent now?
<barry> slangasek: dang, i can't pull it because of conflicts on the quilt patch, but i think i fixed it locally anyway
<mako> slangasek:not quite yet. i just took a job in seattle, but i won't move out until august probably
<slangasek> barry: yay quilt ;)
<slangasek> mako: ah, ok :)
<barry> slangasek: iter*() pain
<slangasek> ah?
<barry> yeah, just a few more .iter*() calls causing the build to fail.  no worries
<hallyn> stgraber: would you be able to toggle a switch to move the 0.5.1-0ubuntu2.1 seabios from https://launchpad.net/ubuntu/lucid/+queue?queue_state=3&queue_text=seabios back into lucid-proposed ?
<hallyn> (if i try to re-push it complains the contents have changed)
<stgraber> hallyn: it's in "done" state, so it's been accepted in the archive, meaning you have to bump the version if you want to re-upload
<stgraber> hallyn: ah, or do you mean https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=seabios ?
<stgraber> oh, ok, that's odd, so one of the 0.5.1-0ubuntu2.1 has been accepted in the archive
<stgraber> so that number is burned and you need to bump
<hallyn> what the...
<stgraber> though there's another 0.5.1-0ubuntu2.1 in the Unapproved queue with the same version number
<stgraber> that can't possibly be accepted
<hallyn> stgraber: it was accepted into lucid-proposed, but never into lucid.  doesn't show up in rmadison
<hallyn> is there a way to just 'move' it back into -proposed from whatever bitbucket it neded up in?
<hallyn> i'm gonna guess no and put down a note to build 0.5.1-0ubuntu2.2 tomorrow
<stgraber> hallyn: you'll need 2.2 either way. I'm not sure exactly what happened there but someone from ~sru and who's more awake than I'm can probably help :)
<hallyn> stgraber: noone verified it, so pitti dropped it.  id ont' know what dropping it entails
<hallyn> so i can use the same .dsc, just bump the version number, and push?  will do, thx
<slangasek> it entails removing it from the archive; it's possible to restore it, but that's necromancy
<slangasek> is your 2.2 going to be the exact same thing?
<stgraber> was it just a case of not getting any testing done in a long time or was there another reason for removing the package?
<slangasek> https://launchpad.net/ubuntu/+source/seabios/+publishinghistory claims "moved to updates"
<slangasek> oh, no, that's the wrong one
<slangasek> pitti didn't delete it, I did ;)
<slangasek> "SRU not verified" - so it sat there for 90+ days with no SRU verification, then an additional 15 days after a reminder ping
<hallyn> yup
<slangasek> so if you're going to reupload, I would first ask why it'll go differently this time :)
<hallyn> slangasek: bc someone commented on the bug sayin gthey're ready to verify
<slangasek> ok
<hallyn> <shrug>  am i a hopeless romantic? :)
<hallyn> slangasek: if you want to drop, i'm fine with that.  ij ust pushed 2.2
<hallyn> mahmoh: are you there?
<hallyn> mahmoh: you also could jump in and verify bug 589063 if slangasek accepts the fix again?
<ubottu> bug 589063 in seabios (Ubuntu Lucid) "Windows Server 2008 won't boot with more than 4 vCPUs" [Undecided,Triaged] https://launchpad.net/bugs/589063
<mahmoh> hallyn: I saw that, I can
<mahmoh> hallyn: but not until next week :)
<barry> slangasek: gotta run, but lp:~barry/ubuntu/raring/gobject-introspection/cleanups is my progress so far.  enjoy detangling the quilt changes <wink>.  i can help hack on this tomorrow if needed
<hallyn> mahmoh: a week is good :)  thanks - ttyl
<slangasek> barry: cheers :)
<mahmoh> hallyn: np, happy all that stuff!
<bryce> slangasek, not broken; it builds fine and if you look, the change is sane even for 1.11.  The bug had been nominated for precise.  After it was processed then he says it's unneeded for precise.
<bryce> slangasek, we have much/most of the Q input stack backported to P's 1.11 so there's no particular reason to doubt that the bug affects precise as well.
<slangasek> bryce: ok; can you comment on the bug, and un-verification-failed it?
<bryce> slangasek, however since the original reporter seems to doubt it's applicable, if it makes you feel better go ahead and drop the package.  I'm not going to bother digging through patches.
<bryce> slangasek, I've reverted the 10.10 change in git.
<slangasek> bryce: well, I'm merely flagging it to you to make sure you know about it; I'm not going to get in the middle of an argument about whether the patch is needed/appropriate :)
<slangasek> but there were other bugs fixed in that SRU, so if this one won't get verified, it would be good to have a reupload with it dropped
<bryce> slangasek, neither am I interested in that.  I'm just an sru monkey, it matters not at all if no one wants the srus they ask for.  ;-)
<bryce> slangasek, 10.10 only had the one patch.  Just go with 10.9.
<slangasek> bryce: well, we can't go with it, it's already been superseded in -proposed
<bryce> slangasek, I wasn't the uploader for 10.9 remember...
<slangasek> hmm?
<slangasek> was that the one I asked you to reupload with a different -v? :/
<slangasek> in any case, either we have to take .10 with this patch, or we need a .11 to get any of the fixes from .9
#ubuntu-devel 2012-12-20
<bryce> slangasek, .11 up.
<voldyman> guys i am trying to write an application that manages and draws wallpaper on the desktop. is there any documented way to doing this?
<RAOF> voldyman: Depends ?
<voldyman> RAOF, ??
<voldyman> RAOF, it will be written in vala. i tried gnome-settings-daemon but i couldn't find most of the functions in vapi for x11
<RAOF> voldyman: You could just frob the relevant gsettings keys and get whatever's drawing the desktop to do the drawing for you; I don't know what those keys are, though.
<voldyman> RAOF, isn't there a way to draw the surface ourself. i have been looking for sometime and it isn't documented
<RAOF> voldyman: You can always draw on the root window :)
<voldyman> RAOF, how ?
<voldyman> i have been trying to do just that
<voldyman_> RAOF, can you point me from where i can learn to draw on the root window
<RAOF> voldyman: Sorry for the delay - in C it's pretty easy, you just grab DefaultRootWindow(dpy) and then pass that through to gtk. Vala might not have the requisite stuff hooked up, though.
<RAOF> voldyman: Oh, now that I think of it, unity-greeter is written in Vala, and it does some draw-to-the-root-window malarkey. Take a look at that.
<voldyman> RAOF, thanks i'll take a look at unity-greeter. would you happen to have an example in C ?
<RAOF> voldyman: Not off the top of my head, sorry, no.
<voldyman> np. thanks a lot
<RAOF> But as I say, it's as simple as dpy = XOpenDisplay(); Window = DefaultRootWindow(dpy); create_a_gtk_drawable(Window);
<voldyman> RAOF, i was reading the libgnome-desktop3 they've used a very complicated method for setting the wallpaper
<RAOF> They need to do funky things because they're trying to handoff from the greeter (to do a transition greeter?session)
<voldyman> nope nothing like that
<voldyman> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/gnome-desktop3/precise/view/head:/libgnome-desktop/gnome-bg.c
<RAOF> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/gnome-desktop3/precise/view/head:/libgnome-desktop/gnome-bg.c#L1193
<RAOF> They're doing funky things because they're trying to handoff from the greeter (to do a transition greeter?session) :)
<RAOF> particularly - they're setting things up so that it'll persist after the client quits
<voldyman> client as in gsd?
<voldyman> so when it itself quits the background should persist
<RAOF> Client as in whatever; IIRC gdm uses it, too.
<RAOF> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/gnome-desktop3/precise/view/head:/libgnome-desktop/gnome-bg.c#L1560 is basically the operative bit.
<gotwig> Hey, may you help to fix me bug #1032534 ? It refers to a fault of ubuntu, to include the string unity into the translateable descriptions. I don't find the translations for the po files when I do apt-get source from jockey-gtk .
<ubottu> bug 1032534 in elementary OS "Jockey refers to Unity" [Low,In progress] https://launchpad.net/bugs/1032534
<RAOF> voldyman: The rest is ensuring that the Pixmap they generate doesn't die when the client dies, setting a property on the root window that they can read later, reading from that property?
<gotwig> but I find the relevant strings when I search here: https://translations.launchpad.net/ubuntu/precise/+source/jockey/+pots/jockey/de/+translate?batch=10&show=all&search=unity
<voldyman> RAOF, so they dont need to maintain a buffer with the wallpaper image, just get it from X
<dholbach> good morning
<darkxst> Sarvatt, did you ever get a chance to look at my other two ppa-purge merge requests?
<hyperair> what's "ay" in gsettings?
<hyperair> i recall "a" being array
<hyperair> but what's "y"?
<hyperair> ah, okay, y is byte
<hyperair> array of bytes.
<hyperair> hmmmm
<hallyn> infinity: SpamapS: around by chance?
<infinity> hallyn: I might be.
<infinity> hallyn: Â¿Que pasa?
<hallyn> infinity: qemu-kvm SRU...
<hallyn> gah, i didn't push the quantal one yet anyway...
<infinity> hallyn: The one with 4 unverified bugs?
<hallyn> but i'm pushed a new precise-proposed to surpass the one there now
<hallyn> yeah.
<hallyn> i'm verifying them today, butone is actually still bad.  I just pushed a new pkg with a better fix
<hallyn> oh. interesting.
<hallyn> in quantal we're doing || true after modprobes.
<hallyn> i'd prefer to drop those actually...  but that's not for this upload
<hallyn> infinity: new versions uploaded for precise-proposed and quantal-proposed.  if possible to accept them that'd be great, i'll verify them today.
<hallyn> (I'm pretty sure the quantal woudl verify without the new change, but i uploaded it anyway to keep behavior 100% consistent between prcise and quantal.  not sur eif that's a priority or not)
<infinity> hallyn: I'll look at them sometime today when I'm bored with being on holiday. ;)
<hallyn> infinity: thanks - and enjoy :)
<hallyn> infinity: well, OTOH, in quantal the version already accepted checks out fine.  so I could go either way, - accepting or rejecting the one i just pushed
<hallyn> slangasek: on precise, udevadm trigger --subsystem-match=misc --action=change
<hallyn> slangasek: does the righ tthing and fixes acls for the group.  but on quantal it doesn't seem to
 * hallyn lunches
<slangasek> hallyn: hrmmmm, really?
<hallyn> slangasek: yeah (unless I'm doin gsomething wrong - always a possibility) trying to verify bug 1057024; works fine in precise, not q.  weird
<ubottu> bug 1057024 in qemu-kvm (Ubuntu Quantal) "kvm kernel module always loaded, without setting /dev/kvm permissions" [High,Fix committed] https://launchpad.net/bugs/1057024
<gotwig> where has  /usr/share/software-center/softwarecenter/distro/Ubuntu.py moved??
<gotwig> its no more out there
<infinity> gotwig: It just got lowercased.
<infinity> gotwig: /usr/share/software-center/softwarecenter/distro/ubuntu.py
<gotwig> infinity, it seems my distro just removed it...
<gotwig> I use elementary Luna
<gotwig> well, its based on Ubuntu
<gotwig> but I can't buy paid apps. I want to fix that
<gotwig> How different is Ubuntu here?
<gotwig> Does it not allow, that other distros use paid apps?
<infinity> I imagine you'd do better by asking the person who modified the package for Elementary.
<gotwig> infinity, I don't see here elementary as the thing that caused that
<gotwig> or the person
<gotwig> but the software center dudes
<infinity> Eh?  You said that the file didn't exist on Elementary.
<gotwig> I already read stuff on the net, where people said that they cant install paid apps
<infinity> Ubuntu developers didn't log on to your system and remove the file.
<gotwig> infinity, of course it has its own file. Without that file it wouldnt even run
<gotwig> you should know that
<infinity> 13:32 < gotwig> infinity, it seems my distro just removed it...
<gotwig> infinity, if its elementary, it uses its own file.
<gotwig> every distro got its own file
<gotwig> but I also read on the net, that linux mint users were not able to install paid apps as well
<gotwig> so I think its a bigger problem
<infinity> Sure, no one's dictating what elementary's should do.
<infinity> (Nor Mint)
<gotwig> infinity, they downloaded it for their self
<gotwig> and did steps that I can reproduce
<gotwig> however the result not
<gotwig> they just copied the ubuntu.py file over, renamed all important stuff, so it could even run
<gotwig> without, it wouldnt
<gotwig> infinity, are you interested in a diff?
<gotwig> I know, that this is not "upstream"
<infinity> Not particularly, no.
<hallyn> slangasek: before installing the qemu udev rules, getfacl shows http://paste.ubuntu.com/1453236, after it shows http://paste.ubuntu.com/1453238
<infinity> After spending 10 minutes trying to find the source on the elementary website, I've lost whatever curiosity I had.
<gotwig> infinity, which source
<gotwig> infinity, you can find everything on launchpad
<gotwig> just like at ubuntu
<infinity> gotwig: "Find it on launchpad" is meaningless.  Where?
<gotwig> infinity, the elementary package for software center?
<infinity> gotwig: I'd interpret what you're saying as "https://launchpad.net/elementary/+source/software-center", which is clearly not true.
<infinity> gotwig: So, again, where?
<slangasek> hallyn: so it looks like the rulse have been /partially/ applied - group is fixed, mode is wrong?
<hallyn> slangasek: right
<slangasek> hallyn: is it possible you have some other rule in your quantal env that's overriding the mode?
<hallyn> grep kvm /lib/udev/rules.d/* didn't show any
<hallyn> unless udev now merges 40-* with 70-* rules?
<hallyn> lemme remove the 70-* rules jsut to make sure
<hallyn> nope, still ignored
<slangasek> hallyn: well, it might be a broader rule of some kind that's setting modes it shouldn't
<gotwig> infinity, https://launchpad.net/~elementary-os/+archive/os-patches
<hallyn> slangasek: is there a way to tell udev what rules it's considering?
<slangasek> hallyn: not AFAIK
<hallyn> slangasek: and it should only use the first rule it finds right?
<slangasek> not at all
<slangasek> it processes all rules in order
<slangasek> hallyn: if you *reboot* the quantal test, do you get the right acl?
<slangasek> if not, that's fairly definitive that the problem isn't with the SRU :)
<hallyn> slangasek: yup
<slangasek> hmm, darn
<hallyn> get the right acls that way
<slangasek> so that sounds like a udev bug of some kind
<slangasek> grr
<hallyn> wonder if it's present in raring
<hallyn> wonder if i have enough disk space to test that here
<hallyn> 7G.  that'll do
<gotwig> infinity, what are you up to
<quantalrabbit> i'm trying to build debuild php5-5.3.10 precise and it is failing with some errors such as "dpkg-source: error: cannot represent change to php5-5.3.10/mysql_base/bin/my_print_defaults: binary file contents changed".  Haven't changed any of the source files yet.  I'm a bit new to ubuntu-devel, any help greatly appreciated
<RAOF> quantalrabbit: It sounds like maybe your clean target hasn't cleaned the build tree properly?
<quantalrabbit> RAOF: thanks, you are correct.
<quantalrabbit> RAOF: i removed files it was complaining about and it now is rebuilding.
#ubuntu-devel 2012-12-21
<quantalrabbit> trying to debuild php5-5.3.10 for precise and failed pretty far along the build process.  getting the following error: "debian/setup-mysql.sh: 44: debian/setup-mysql.sh: USER: parameter not set" then build exits with status 2.  Any help greatly appreciated.
<micahg> #ubuntu-server might be better
<quantalrabbit> micahg: okay.  will try asking there at #ubuntu-server
<dholbach> good morning
<Logan_> Hey dholbach. :)
<dholbach> hey logan
<tkamppeter> Anyone around from the SRU team? It is about bug 1086019. I would like the proposed package to get approved before xmas.
<ubottu> bug 1086019 in cups (Ubuntu Quantal) "cupsd crashes regularly (daily)" [High,In progress] https://launchpad.net/bugs/1086019
<tkamppeter> pitti, hi
<xnox> ev: you make me smile =))) http://ubuntuone.com/5Iln9utSYN9ZTskTjVFuYo
<g0twig> cjwatson, hey theere
<g0twig> cjwatson, we don't see icons :X bug #1084233 any ideas?
<ubottu> bug 1084233 in elementary OS "Duo-Installation setup icons missing for several OS" [Undecided,Confirmed] https://launchpad.net/bugs/1084233
<g0twig> cjwatson, are you thereÃ
#ubuntu-devel 2012-12-22
<phillw> Hello good people, is there someone about who could look into bug 964705 ? It has fix released by others, could it be 'cherry picked' for ubuntu?
<ubottu> bug 964705 in network-manager (Ubuntu) "System policy prevents modification of network settings for all users" [Medium,Confirmed] https://launchpad.net/bugs/964705
<sarnold> phillw: it might be worth pointing out the specific patches used to fix the problem
<sarnold> (fwiw, the bug report comments just seem to be a pile of ranting about various things; it'd probably be worth explaining what specific feature / bug those patches address..)
<phillw> sarnold: that is beyond my knowledge... it 'seems' ubuntu' do not rate it highly, but others have rated it, and more importantly have a fix released?
<phillw> sarnold: https://bugzilla.novell.com/show_bug.cgi?id=731812
<ubottu> bugzilla.novell.com bug 731812 in Network "NetworkManager and time settings unusable for normal users, and forced ipv6 probing" [Critical,Resolved: fixed]
<phillw> Ahh... I've seen this bug elsewhere.. it is polkit and sudo gremlin
<phillw> yeah, there are several bugs open. All roads lead to Rome. polkit.
<sarnold> wow, that novell bugreport is fun reading.
<phillw> yup, back to polkit... which is an issue with other bugs I see cross my mailing list.
<phillw> sarnold: having had fun reading... your thoughts?
<sarnold> phillw: no ideas, I couldn't figure out what might be applicable to ubuntu vs applicable to world at large.. my eyes glaze over when polkit and consolekit and soforth get involved.
<phillw> yeah, I know what you mean. I see 'chatter' about using polkit Vs looking up admin on the system... I do feel we need someone from 'above' to sort this out, as it would squish lots of different bugs.
<phillw> Thanks for you time, I'll try to grab someone to see where the rules of polkit is going.
<sarnold> agreed completely re "someone from above"
<Bluefoxicy> huh apt-cacher is interesting
<Bluefoxicy> here's a question:  why aren't there a few main mirrors, with the rest being cachers that don't bother downloading packages unless someone tries to get it from that mirror?
<sarnold> a few thoughts: (a) if the main repo goes down and a cache doesn't yet have the package, it must either return failure or get the package from a peer. that's complicated. (b) how often should the caches check if a newer package is available from the main repos? pushing packages as they change is probably less traffic overall than having an expiry scheme
<Bluefoxicy> uh
<Bluefoxicy> why would it check for a new version?
<Bluefoxicy> don't you bump the version number in the file name?
<sarnold> .. how would the clients know to request the newer version?
<Bluefoxicy> because you push updates to the Packages.gz file
<dkessel> i have a question. i just tried: bzr branch ubuntu:webkit
<dkessel> and it says: Packaging branch status: OUT-OF-DATE
<dkessel> i have checked the package import status site and there is a bug for it. is there anything i can do to get the current version?
<dkessel> bug: 653810
<ubottu> bug 653810 in Ubuntu Distributed Development "Cannot import paths with backslashes" [Medium,Triaged] https://launchpad.net/bugs/653810
<infinity> dkessel: If you want the current version, "pull-lp-source webkit" (from the ubuntu-dev-tools package) or just "apt-get source webkit" to get the source that matches your currently installation.
<infinity> s/currently/current/
<dkessel> infinity: thanks, pull-lp-source did it
<dkessel> infinity: if i do any changes and upload that as a personal bzr branch on launchpad - would a ubuntu developer have any problems merging the changes into the current version?
<infinity> You'd likely want to talk to Laney or micahg.  Depends on what the changes are, and why.
<infinity> (What are you changing?)
<dkessel> I will try to get a simple compile/link/run autopkgtest to work for the package libwebkitgtk-3.0-dev . normally i do this using bzr to create a branch of the current version, commiting my changes and then the changes get reviewed
<infinity> Oh, sure, I imagine an autopkgtest case would be something we'd be interested in merging.  You could just file a bug with a diff attached, there's no reason it needs to be a bzr branch.
<infinity> (And, in fact, a branch with no sane parent is just a pain to merge anyway)
<dkessel> oh ok - i will do it this way then
<dkessel> inifinity: thanks and bye
<Laney> dkessel: You should look into running the gtk tests too (Tools/Scripts/run-gtk-tests)
 * Laney disappears for the rest of the day with a flourish
<gotwig> cjwatson, hey there
<cjwatson> gotwig: on vacation.  occasionally happen to look at irc but I'm not going to look at any bugs 'til the new year.  sorry.
<gotwig> cjwatson, no problem. Have a nice time :D
<chilicuil> hi, good morning, sry to bother, what's the correct behaviour in case I want to change a line to fix a bug which was introduced by a patch living in /debian?, should I edit the patch file or provide another?
<infinity> chilicuil: If the patch is something like a pull from an upstream VCS, stacking another on top (and submitting it upstream) is sane.
<infinity> chilicuil: If it's a local patch, then just fixing it makes more sense than appending to it.
<chilicuil> infinity: it was introduced by the debian maintainer, so I suppose that qualifies as a local change, right?
<infinity> chilicuil: Yeah, though you'd also want to forward your fix to Debian.
<infinity> (which patch is this?)
<chilicuil> infinity: yep, it's just that the package in debian is orphaned, however I'll try, it's a little problem in html2text, #586279
<chilicuil> bug #586279
<ubottu> bug 586279 in html2text (Ubuntu) "Wrong conversion of &auml; in HTML" [Undecided,Confirmed] https://launchpad.net/bugs/586279
<infinity> chilicuil: Ahh, fair enough.  If it's orphaned, want to bug me about it $later (or provide a patch and /msg me about it), and I'll fix it in Debian with a QA upload and sync to Ubuntu?
<infinity> chilicuil: (I only request later because I'm heading to bed)
<chilicuil> infinity: sure, I'll do it, thanks
<ricotz> infinity, hi :), any news on eglibc?
<chilicuil> he went to sleep half an hour ago ricotz =)
<ricotz> chilicuil, ah, i see
<pigna_colada> hello :(
<pigna_colada> I just downloaded this ubuntu 12.10 cd
<pigna_colada> and booted my laptop using the "try" selection
<pigna_colada> but now it asks for a username
<pigna_colada> and password
<pigna_colada> what do i have to put??
<penguin42> pigna_colada: Please try #ubuntu for general help
<pigna_colada> thanks
<slangasek> mlankhorst: hi, I see you're involved in maintaining the wine1.5 packages in the ~ubuntu-wine ppa - are there any plans for this to land in raring?
<slangasek> mlankhorst: also, do you know if anyone's working on audio device enumeration in wine using the pulse driver?
<mlankhorst> I maintain winepulse
<mlankhorst> and ask next year please
<slangasek> heh :)
<slangasek> mlankhorst: but I have an app I want to use it for over vacation, and time to spend hacking wine... if I wait until next year, it might be too late :-)
<mlankhorst> I maintain winepulse in ubuntu-wine
<paultag> jbicha: poke
<paultag> jbicha: sorry about that bug, but I'm a bit swaped -- the issue stems from SFTP not meaning a user account on the system (or even a $HOME), so using "~" in SFTP is a bit odd
<paultag> jbicha: if you find out what legacy dput does, I'd be happy to add a shim, but parimiko has no idea what's going on otherwise
<paultag> one idea we were throwing around was just ditching the "~", which seems like it'll do the trick (but I'm not sure)
<mlankhorst> slangasek: so wine is actually ok, just dont ask about upstream, dont want to work :P
<jbicha> paultag: thanks, it's fairly easy for me to switch back to classic dput when needed
<paultag> jbicha: righto. In the meantime, patches welcome, otherwise it's on my queue for some downtime during my vacation
<paultag> or not :)
<paultag> 17:20 < paultag> jbicha: righto. In the meantime, patches welcome, otherwise it's on my queue for some downtime during my vacation
<paultag> jbicha: in case you missed it :)
<paultag> I'll have to take a closer look, sorry for the bumpy ride, but this was something we were trying to work out for a while now without putting it on the fire
#ubuntu-devel 2012-12-23
<garpy> v
<kermit_> hello! Does anybody maybe know where /usr/libexec/colord resides in Ubuntu?
<mlankhorst> ~$ dpkg-query -S colord
<mlankhorst> afk
<kermit_> @mlankhorst tnx. I'm guessing it will be /usr/lib/x86_64-linux-gnu/colord then.
<udevbot> Error: "mlankhorst" is not a valid command.
<kermit_> mlankhorst: tnx. I'm guessing it will be /usr/lib/x86_64-linux-gnu/colord then.
<cjwatson> kermit666: /usr/lib/$(DEB_HOST_MULTIARCH)/colord/colord, by the looks of things, where $(DEB_HOST_MULTIARCH) is approximately the GNU triplet for the current architecture.
<cjwatson> Though I'd have thought it would be a broken thing to do to rely on the path of something in libexecdir ...
<cjwatson> The path is in the D-Bus system-services configuration for org.freedesktop.ColorManager
<kermit666> cjwatson: thanks. Yes, I found it under /usr/lib/x86_64-linux-gnu/colord/colord and it seems to work. I was pointed to start the daemon like this by the upstream developer.
<cjwatson> They presumably have some reason, but generally you are just meant to talk to the D-Bus service and let D-Bus automatically start it.
<cjwatson> Perhaps they're trying to have you start it with some particular options or environment.
<cjwatson> I'm just warning you not to hardcode that path in any scripts you distribute.
<kermit666> cjwatson: sure. I think the reason is they can't collect the log files without me running systemd, so I had to run it manually with a -v flag and collect the output. https://bugzilla.gnome.org/show_bug.cgi?id=690349
<ubottu> Gnome bug 690349 in Color "Selected color profile won't stay applied" [Normal,Needinfo]
<cjwatson> OK
<infinity> tjaalton: Remember how you couldn't reproduce that SandyBridge GPU lockup?  I've just gotten it twice in a row while swithing workspaces in Unity.  Just sprinkle some gnome-terminals and firefoxes (probably not required, but that's my desktop) around the place, and zip around with Ctrl-Alt-Arrows for a bit.
<tjaalton> infinity: hmm ok, i do use that though, but will try harder
<blami> infinity: btw. I had plenty of GPU lockups on my T420, not sure if it will help someone but I get rid of them by disabling VT-d IOMMU extension either in bios or by passing intel_iommu=something to kernel
<blami> infinity: (when on intel only ofc as it is optimus system)
<infinity> blami: Hrm.  I'll have to look for that BIOS setting.
<infinity> tjaalton: Did you see the above?
<blami> infinity: on thinkpads its in security/virtualization
<RAOF> infinity: Intel has long had problems with the interaction between vt-d and other features (most recently, rc6)
<blami> infinity: I can test a little more if you need. I have two t420's here putting some nouveau wmi patches together so I reboot very often
<blami> RAOF: I remember terrible lockups in times of last 2.6 lines and then it was good up to 3.5 i believe
<RAOF> I thought rc6-vs-VT-d was settled much later than 3.0.
<RAOF> We may have simply quirked one of them off
<blami> RAOF: also I believe only minority of software uses vt-d, right?
<blami> RAOF: only thing I use and know it can benefit from vt-d enabled is vbox
<RAOF> AFAIK it's only useful in to virtualise a PCI resource.
<blami> RAOF: I'm not sure if I got it correctly but all that gpu offloading stuff using shared-buf can also use iommu to improve throughtput if one of gpus uses system memory area
<blami> RAOF: but I'm not sure if it's already part of kernel drivers and userspace, it's pretty new I think
 * RAOF is not sure how the iommu could come into play there, as the GPU has its own.
<blami> on the other side when I have vt-d enabled and using nvidia only setting in bios even windows freeze
<RAOF> But there's plenty I don't understand about the mysteries of the GPU
<blami> RAOF: I probably misinterpreted this. I'm trying to learn about gpu and nouveau-devel is definitely good place to do so but sometimes I really don't understand anything :)
<RAOF> There's always our very own mlankhorst :)
<blami> :)
<infinity> blami: I'll be sure to check that and turn it off the next time I reboot my 420s.  I'm somewhat sick of getting the same apport popup several times per day. :P
<infinity> Actually, maybe I'll do that now.
<blami> infinity: is it intel only or optimus (just curious)
<infinity> Optimus, but I run it in Intel-only mode.
<blami> infinity: be sure you have latest bios. It is probably firmware bug rather than kernel bug (imo).
<blami> infinity: some folks on thinkpad forums reported that freezes dissapeared with newer version of firmware (but I can still reproduce even with latest)
<infinity> blami: I updated the BIOS fairly recently to see if it would fix it, no luck.
<infinity> Anyhow, rebooted, Vt-d turned off, we'll see how the behaves.
<infinity> s/the/that/
<penguin42> infinity: Is the 420 Intel only?
<blami> penguin42: it depends
<blami> penguin42: there are models with discrete nvidia and models withou
<blami> penguin42: even on the models with nvidia card you can disable it (if you're ok with crippled multihead then)
<penguin42> blami: ah, I'm unfortunate enough to use a 520 that has both, and it's a pit*
<blami> penguin42: t420 is almost same
<penguin42> blami: On the 520 the external VGA is only connected to the nvidia so if you want the external you need to use discrete nvidia (or optimus)
<blami> penguin42: I bought it because I wanted tripple head at work but t420 has everything hardwired to nvidia except lvds
<blami> penguin42: in case of t420s situation is a little better as lvds switches between nvidia and optimus regarding the bios setu
<blami> p
<blami> penguin42: so I am running optimus setup and when presenting or want multihead I launch another xserver on nvidia card
<penguin42> blami: Yeh, I run the 520 in discrete mode with nouveau, turn gl off in KDE and it survives
<penguin42> blami: I also need to pass noapic, otherwise it hard hangs most of the time apparently losing all interrupts - but only when in discrete mode
<blami> penguin42: redhat guys are working on this. There should be gpu offloading and muxed xrandr in 1.14
<penguin42> yep
<blami> penguin42: hopefully nvidia will adopt this and release 1.14 drivers with support for prime framework
<blami> penguin42: as I don't believe they will support wayland
<blami> where ofc multihead handling is not decided yet
<blami> as well as many other things
<penguin42> blami: I need my extra pixels :-)
<blami> penguin42: :)
<blami> *30 line situation is better as they decided to hardwire only to intel card
<blami> but they definitely killed the keyboard so I bought as much t420's as I could :)
<penguin42> blami: The big escape key on the 520 is kind of nice for us vi users :-)
<blami> yep :)
<blami> penguin42: I really mourn about next/prev pages around arrows
<blami> penguin42: I use them to switch workspaces in unity and they replaced'em with pgup/pgdn
<penguin42> oh I could live with that
<RAOF> penguin42, blami: You should be able to do gpu offloading & xrandr in Ubuntu 12.10; the GPU offloading bit at least works here.
<blami> RAOF: using xrandr gpu providers? whoa even fedora does not support that yet
<penguin42> RAOF: Nope, doesn't work on 12.10
<penguin42> RAOF: xrandr sees both cards but won't let you enable the external vga
<RAOF> penguin42: What part? The offloading bit should (and, indeed, does here) work.
<blami> xrandr --listproviders causes Segmentation fault ...
<penguin42> RAOF: ok, what do you mean by offloading and how would I know it's working
<RAOF> penguin42: Run DRI_PRIME=1 glxinfo; check that the renderer string is nouveau.
<RAOF> Then you can run whatever apps you want with DRI_PRIME=1 set, and they'll run on your nvidia.
<penguin42> RAOF: OK, but I don't think I can get it to bring up the external display except in nouveau mode; I think it listed both providers in xrandr but wouldn't let me turn the external one on
<RAOF> Ok. I've not tested that, as my T420s died tragically.
 * penguin42 hates to think
<penguin42> RAOF: I believe it's expected behaviour on 12.10, xrandr knows it's there but won't allow it to be enabled
<blami> penguin42: correct. I'm not sure but sinks code has not been even written yet. This only ofloads gpu and in somehow magical combination of Xorg and kernel drivers it probably works
<RAOF> The sinks code should be there; it's essentially the same as displaylink support, which (apparently) works.
<blami> penguin42: but to see outputs of all cards present and mux them in single xrandr configuration is definitely not possible yet
<blami> RAOF: for displaylink maybe
<blami> RAOF: only thing presented so far by redhat was offloading of gpu intensive operations from displaylink device (which actually still managed "displaying" of output) to intel gpu (which managed "calculations" only)
#ubuntu-devel 2013-12-16
<robert_ancell> cjwatson, thanks for pointing that out. I bump it so we don't have lintian warnings, since that tends to hide real problems
<cjwatson> You should ignore that specific warning for Ubuntu (in a wrapper or whatever if you need the output to be empty) rather than introducing this unnecessary diff
<robert_ancell> ok
<cjwatson> I think you may even be able to do this in a policy file nowadays
<ari-tczew> robert_ancell: new merge request with cheese is available
<sladen> mmmm, cheese
<robert_ancell> ari-tczew, I think libcheese7 shouldn't depend on gstreamer1.0-plugins-bad - you might have picked that up from debian
<ari-tczew> robert_ancell: where do you see it?
<robert_ancell> ari-tczew, I'm sorry, I'm reading the diff the wrong way!
<ari-tczew> robert_ancell: yes, it looks like so
<ari-tczew> robert_ancell: however, anyway I've prepared debdiffs in LP bug
<ari-tczew> maybe it could be easier to read diffs
<robert_ancell> ari-tczew, uploaded
<apachelogger> pitti: https://bugs.launchpad.net/langpack-o-matic/+bug/1261206 if you could have a look at that please
<ubottu> Ubuntu bug 1261206 in langpack-o-matic "l10n Other Notifications are not localized" [Undecided,New]
<ari-tczew> robert_ancell: perfect, thanks!
<pitti> Good morning
<Logan_> pitti: Hello. :)
<pitti> apachelogger: replied
<Noskcaj> pitti, Would i be able to have a testimonial for motu and/or xubuntu packageset? https://wiki.ubuntu.com/Noskcaj#Testimonials
<pitti> Noskcaj: hello
<Noskcaj> hey pitti
<pitti> Noskcaj: were you able to sort out your internet problems, i. e. can you do test-builds now?
<pitti> Noskcaj: I still saw quite a few untested sync requests, for example
<pitti> Noskcaj: otherwise, I'll look at packages that I uploaded for you
<pitti> http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=Martin+Pitt&sponsor_search=name&sponsoree=Jackson+Doak&sponsoree_search=name
<Noskcaj> My internet is less bad (actual ADSL speed sometime now), and for the moment i'm ignoring all big packages since my laptop can build then properly. That will be fixed later this week when my linux Aus sponsorship comes through and i build my devel PC
<pitti> infinity: hey Adam, how are you? would you mind if I stick the "automatic fstrim" cronjob into util-linux?
<pitti> infinity: (debian bug 732054)
<ubottu> Debian bug 732054 in util-linux "util-linux: Add cron job for regular SSD trimming" [Wishlist,Open] http://bugs.debian.org/732054
<infinity> pitti: How safe is this in detecting that it's only operating on things that it should, etc?
<infinity> pitti: Anyhow, I wouldn't be entirely against it.  Just do it in Ubuntu for now, and I'll sync it back to Debian when lamont and I are done sorting our takeover/handover plans.
<pitti> infinity: fstrim itself just fails with an I/O error if the drive doesn't support it
<pitti> infinity: but usually we test in advance with hdparm -I
<pitti> infinity: "usually" because hdparm doesn't work "through" device-mapper (lvm, luks)
<pitti> infinity: http://people.canonical.com/~pitti/scripts/fstrim
<infinity> pitti: Does it run instantly (or near enough) on filesystems that have just been trimmed a few seconds earlier?
<pitti> infinity: I tested with trimmable SSD, rotational HDD, LVM, and LUKS
<pitti> infinity: yes
<infinity> pitti: Cause you might catch bindmounted filesystems a few times in a row.
<pitti> infinity: and it doesn't run if the user mounts with "discard"
<pitti> infinity: it filters those out
<infinity> pitti: I don't see that filter...
<pitti>     REALDEV=`readlink -f $DEV`
<pitti>     if contains "$DONE" " $REALDEV "; then continue; fi
<pitti>     DONE="$DONE $REALDEV "
<infinity> Ahh.
<infinity> Fair enough.
<infinity> pitti: Yeah, go nuts and do the Ubuntu upload.  Like I said, I'll sort it in Debian when lamont and I have our ducks in a row with what's happening there.
<pitti> infinity: ok, thanks; just wanted to know if I interfere with some git when I do an Ubuntu upload
<infinity> pitti: Nope.
<pitti> infinity: so, my idea was to add this as /usr/sbin/fstrim-auto (do you know a better name?) and link to it from /etc/cron.daily/
<pitti> infinity: so that we can adjust the scripts without conffile issues, and the admin can also move the link to cron.weekly or even .hourly, or drop it entirely
<pitti> or perhaps "fstrim-all"?
<infinity> pitti: By "link to it", you mean write a job that calls it, not symlink it, right?
<pitti> infinity: I actually meant symlink, but I can also write a two-line shell wrapper if you prefer
<infinity> pitti: I mean, a symlink would work, but it has the disadvantage of being completely undiscoverable if someone wants to disable it (you dlete the symlink, it's gone forever, you forget).
<infinity> pitti: The two-liner means you can disable with an exit 0.  Or overengineer it with an /etc/default/fstrim
<pitti> I just mostly don't want to put the entire logic into a conffile, that should be separate
<pitti> infinity: two-line sh WFM
<infinity> pitti: Make it an exec, and people can still have a pretty ps without a billion forked children. ;)
<infinity> Not like 'ps f' is ever pretty when cron is running.
<pitti> infinity: ok, sounds good; that'll also make it easier to change options (if we'll ever add them), or logging, etc.
<pitti> infinity: /usr/sbin/fstrim-all ?
<infinity> pitti: That works.  It's not set in stone, and not worth bikeshedding over. :)
<infinity> pitti: If 'fstrim' was something I was prone to type as a normal user, I'd whine that you're breaking tab completion for it, but I suspect this cron job will replace 99% of times people would have typed it themselves.
<pitti> jibel (CC: infinity): this morning, eglibc triggered maybe 40 autopkgtests, and I saw them as RUNNING in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<pitti> but now there are only about 15 shown
<pitti> is this intended?
<pitti> i. e. is this not supposed to show all PASSes? (because it has a few)
<pitti> infinity: FYI, http://paste.ubuntu.com/6582419/ (util-linux debdiff)
 * pitti adds debian bug ref
<infinity> pitti: I've noticed that in the past, too, they seem to drop off.
<infinity> pitti: Not sure if that's intended.
<pitti> it looks like a bug
<infinity> pitti: Why the if-guard in rules?  Do we not always build fstrim?
<pitti> infinity: nope, not on bsd/hurd
<pitti> infinity: I wanted to make the debdiff palatable to Debian
<pitti> infinity: that's why I don't use dh_installcron for it, but the manual install
<infinity> pitti: Ahh, nice catch.  Thanks.
<infinity> pitti: And even a manpage.  My hero.
<pitti> ð« lintian <= 0  âº
<pitti> or, while we are at fancy unicode, â¤ 0
<infinity> pitti: Seems to be a typo in your AUTHOR section, though.
<pitti> infinity: thanks, fixed
<jibel> pitti, not intented, it is a bug. results are sorted but not in chronological order and only the last row is reported.
<jibel> pitti, that explains the results that changed from fail to pass to fail
<darkxst> pitti, do your retracer get stuck on HTTP errors sometimes?
<pitti> darkxst: yes, quite often; when that happens I just remove the lock and let it go on
<darkxst> right although it takes me a few days to notice usually
<darkxst> and then all the traces have bitrotted ;(
<darkxst> pitti, why not ignore the HTTP errors?
<pitti> darkxst: I set up the cron jobs to mail me on failures
<pitti> darkxst: I want to avoid untagging hundreds of bugs when there is an actual bug in the code/LP regression/etc.
<pitti> (untagging without proper retracing)
<pitti> darkxst: http://paste.ubuntu.com/6582585/
<pitti> darkxst: the trick is the "|| tail -n 15 log/i386.txt"
<darkxst> pitti, but these seem to come from access issues to the server?
<pitti> darkxst: right, sometimes LP gets some hiccups, or you hit the window where it updates, etc.
<darkxst> speaking of LP, it is sooo slow from here ;(
<darkxst> (unrelated to the retracer, thats in europe somehwere)
<sil2100> popey: hi! Meeting!
<doko> mlankhorst, mesa ping
<mlankhorst> pong, what exactly? :p
<mlankhorst> oic, thanks, pushed to git
<Riddell> mdeslaur: nudge nudge, don't forget bug 1259577
<ubottu> bug 1259577 in qtbase-opensource-src (Ubuntu Saucy) "Security: XML Entity Expansion Denial of Service" [Undecided,New] https://launchpad.net/bugs/1259577
<mdeslaur> Riddell: I'm still testing them, should be out today
<Riddell> groovy
<jamespage> doko, hey - any ideas on this segfault in openjdk on i386 - https://launchpadlibrarian.net/159915593/buildlog_ubuntu-trusty-i386.munin_2.0.19-2_FAILEDTOBUILD.txt.gz
<jamespage> doko, amd64 is OK (only had one of those to had when I build tested prior to sync)
<doko> jamespage, does it work with glibc 2.17?
<alexbligh> What is the correct way to request packaging of an existing perl package in CPAN for 14.04?
<alexbligh> LWP::UserAgent::DNS::Hosts if anyone is interested ...
<rbasak> alexbligh: via Debian, preferably. See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<Laney> Yeah, you'd probably want to speak to pkg-perl in Debian
<Laney> Those guys have some pretty efficient ways of getting new modules in AFAIK
<alexbligh> rbasak, ok - I've already done the debian thing. Bug#732292 - just wondered if I needed to do it for Ubuntu too. thanks
<rbasak> alexbligh: it should auto-import into Ubuntu if it lands in Debian before Ubuntu's Debian Import Freeze. https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule says that's 6 Feb.
<maxiaojun> Ubuntu Packages Search down?
<xnox> maxiaojun: best to report / inquire on  #canonical-sysadmin
<maxiaojun> is that channel public accessible?
<maxiaojun> ok, it shows "known issue" there
<xnox> maxiaojun: it's a community support channel on Freenode, for services / hosts managed by canonical sysadmins.
<xnox> maxiaojun: it is public.
<maxiaojun> got it
<xnox> maxiaojun: looks like it is known that packages.ubuntu.com and package-importer are down.
<jamespage> doko, I'll try in a bit
<dobey> why oh why does UOA keep causing my twitter account to not be usable (and thus friends-service to not be able to use it)?
<xnox> barry: would you be able to port lp:python-ubuntu-platform-api  to python3? it's "just" two small .cpp / compiled extensions.
<xnox> i'll give it a shot, but I actually haven't ported any compiled modules yet.
<xnox> well not today, maybe one evening this week, or some such.
<xnox> barry: actually i don't think we need it at the moment, cause there is a pure-python version as well.
<barry> xnox: if there's a bug #, sure, i can definitely take a look
<xnox> barry: ok, thanks. well let me figure out what we need / want first.
<barry> xnox: sure thing
<Wubix> hello everyone. how can i find out why a certain feature or tool (e.g. the menu driven debian installer) was dropped so i can understand the decision making process better?
<Wubix> or are such decisions not documented for the public?
<stgraber> cjwatson: I have an e-mail pending review in ubuntu-devel-announce if you have a minute
<cjwatson> stgraber: done
<cjwatson> Wubix: it wasn't actually dropped, it's just not used to build full CD images any more, but it's still available from http://cdimage.ubuntu.com/netboot/ (including in a form factor that you can burn to a CD to get started and it downloads most of itself from the network)
<stgraber> cjwatson: thanks
<cjwatson> Wubix: I don't have a link and am doing rather too much else to track it down just now, but you should be able to find discussion of dropping the alternate image on one or both of blueprints.launchpad.net/ubuntu or the archives of the ubuntu-{devel,release} mailing list
<cjwatson> s
<Wubix> this already helps a lot, thank you!
<robru> dobey, not sure, i'm seeing the same thing, but only on the desktop. twitter is working fine on the phone. no idea what could possibly cause that
<dobey> robru: yeah i'm not even sure how to file a bug exactly. but it is very annoying, and it happens all the time for me :(
<dobey> robru: and i think i have to restart friends-service after it happens for it to even work again at all
<robru> dobey, not sure about that part. but I did notice that every time I refresh in friends-app, twitter says it's no longer authorized and asks to be reauthorized.
<sarnold> was there some noise recently about twitter blocking something?
<dobey> sarnold: this has been happening to me for at least a year, so i doubt it's that
<sarnold> dobey: okay :)
<dobey> robru: yeah i don't use friends app, just the service for @-reply notifications
<robru> dobey, you've been seeing this for a year? I just started seeing it a couple day sago
<dobey> robru: well, it's been happening as long as i've had to use friends-app and online accounts for it, yes
<dobey> err, friends-service
<dobey> since the swtich from gwibber
<robru> dobey, :-(
<dobey> robru: :( indeed
<Logan_> New architecture! :O
<Noskcaj> How do i update an ubuntu packaging bzr branch to he current ubuntu release?
<Laney> Noskcaj: you mean a UDD branch?
<Noskcaj> yeah
<Noskcaj> lp:ubuntu/PACKAGE
<Laney> the only way I know of is to ask xnox to do the magic, whatever that is
<Laney> not guaranteed to be work
<Laney> s/be //
<Noskcaj> xnox_, Any chance you could update lp:ubuntu/xfce4-cellmodem-plugin ?
<Noskcaj> doko, Mind if i merge torque?
<kees> hm, I think lp: #1261515 is not a real bug report
<ubottu> Launchpad bug 1261515 in apparmor (Ubuntu) "package libapparmor1 2.8.0-0ubuntu31.1 failed to install/upgrade: package libapparmor1 is already installed and configured" [Undecided,New] https://launchpad.net/bugs/1261515
<kees> ubottu doesn't show the description: "asdgwsdfasdf"
<ubottu> kees: I am only a bot, please don't think I'm intelligent :)
<sbeattie> kees: lots of people, when confronted with an apport request to report a bug for some failure they don't understand, type random goop into the description.
<kees> sbeattie: yeah, I'm familiar. it's just been a long time since I've gotten one.
<kees> though, I still don't understand the impulse. I would just close the window if I didn't want it. :)
<stgraber> kees: I can subscribe you to ~ubuntu-installer if you want more of those ;)
<stgraber> (thankfully the logs are often enough to figure out what's actually wrong)
<kees> stgraber: haha, no thanks! :)
<smoser> hi. is there a place where i can get a netboot initramfs and HWE kernel that will install 12.04 HWE ?
<Sarvatt> http://cdimage.ubuntu.com/netboot/precise/ ? dates line up with 12.04.3 release that had raring's hwe stuff
<smoser> Sarvatt, but its not netboot. i was going to try pulling those. but will they work as netboot ?
<stgraber> smoser: use http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/ and then use the enablement stack you want from there (e.g raring-netboot)
<smoser> stgraber, there is no saucy-netboot ?
<stgraber> not yet
<smoser> hm.. i happen to need that.
<stgraber> infinity would know the details, but I know we usually only start recommending those enablement stacks when the point release is released
<stgraber> so for saucy-netboot that'd be with 12.04.4
<smoser> stgraber, thanks.
<doko> Noskcaj, please do
<bdmurray> xnox_: do you have any plans to SRU the fix for bug 915626?
<ubottu> bug 915626 in usb-creator (Ubuntu) "usb-creator-gtk crashed with SIGSEGV in _dbus_watch_invalidate" [High,Fix released] https://launchpad.net/bugs/915626
<xnox_> bdmurray: yes, across all applicapable releasse. when/if I have time though.
<xnox_> bdmurray: do you want to SRU it? / have time to do that?
<bdmurray> xnox_: I can make some time is it just that dbus patch in that bug?
<xnox_> does it affect precise as well?! /me can't remember
<xnox_> bdmurray: yeah the one-liner to call init threads.
<bdmurray> errors seems to show it affecting 12.04
<xnox_> bdmurray: yeah, and well it's reported from before 12.04 release.
<doko> jamespage, infinity: openjdk-7 ftbfs itself on i386 with 2.18
<YokoZar> https://launchpad.net/~ubuntu-dev   <--- what is the "ubuntu-reviews@lists.ubuntu.com" contact mail?
<YokoZar> I'm not sure that's even a real mailing list.
<YokoZar> To be clear I'm asking what the implications of setting that for the ubuntu-dev team in launchpad are
#ubuntu-devel 2013-12-17
<xnox_> YokoZar: all reviews end up on the sponsorship queue report http://reqorts.qa.ubuntu.com/reports/sponsoring/
<xnox_> YokoZar: which ubuntu core devs and motu patch pilot, review and upload.
<xnox_> YokoZar: the implications of setting that in launchpad, is to avoid spamming people with messages comming from "contact this user"
<xnox_> (bug subscriptions, merge review requests etc. as there is no good way to "opt-out" of team received mail, unless it's redirected to a mailing-list / email address)
<YokoZar> xnox: ahh, sensible.
<Noskcaj> doko_, https://code.launchpad.net/~noskcaj/ubuntu/trusty/torque/merge . And if you have any merges you want me to do, just say
<manchicken_> Did anybody on the Synaptic side ever work around the deprecation of InstallProtect in apt-pkg?
<manchicken_> I'm trying to figure out how to get around that for libqapt, but I am finding exactly zero documents explaining the deprecation and what one could do differently now that this method is deprecated.
<Noskcaj> Can someone please review https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-session/light-locker/+merge/196436 ? It's kinda important for xubuntu
<sarnold> pitti: good morning :) I just ran my laptop down to two minutes battery life, then suspended, then plugged into power; when I returned, my laptop was awake and running. Is this expected?
<pitti> sarnold: no, certainly not
<pitti> good morning
<pitti> sarnold: you mean plugging in AC woke up the laptop?
<pitti> sarnold: might that be a BIOS/EFI setting?
<sarnold> pitti: I believe that's what happened.
<sarnold> pitti: could be.
<sarnold> I've never pushed my luck down to two minutes before. :)
<BrotherBrick> morning
<dholbach> good morning
<infinity> pitti: Does ddebs need to learn about new arches, or does it just DTRT (I ask this every time, don't I?)
<pitti> infinity: they do need to learn about new arches
<infinity> pitti: Alright.  ppc64el me, then.
<pitti> infinity: trusty only, I take it?
<infinity> pitti: No current plans for time travel, no.
<pitti> infinity: http://bazaar.launchpad.net/~pitti/+junk/ddeb-retriever/revision/108
<infinity> pitti: A scrape should get you eglibc and binutils ddebs, so far.
<pitti> infinity: I'll re-fetch ddebs from the last 7 days
<pitti> $ for d in 2013121{1,2,3,4,5,6,7}; do ~/ddeb-retriever/ddeb-retriever $d; done
<pitti> (just in case you need to do it yourself at some time)
<pitti> that's not yet it, I take it: libc6-ppc64-dbgsym_2.17-93ubuntu4_powerpc.ddeb
<pitti> (just a foreign arch build)
<infinity> pitti: Yeah, that's not it. :)
<infinity> pitti: Of course, if it scrapes in DB index order, it'll hit the ppc64el buildd dead last, since it was the last one added...
<pitti> scrapes by day, currently at Nov 15
<infinity> Dec, I hope.
<pitti> and eglibc was built on 16
<pitti> err, yes
<infinity> It's in the 20131217 directory, actually.
<infinity> Must have finished right after 1200 UTC.
<pitti> oh, and binutils right now
 * infinity waits like an excited puppy to see them publish to http://ddebs.
<pitti> meh, seems some apache on some buildd is hanging again
<infinity> Can you tell which one?
 * pitti enables debugging
<pitti> infinity: ddebs are in pool/ now (postal01 retrieval works)
<pitti> infinity: indexes will refresh automatically in a few hours (or I can start that now if you are eager)
<infinity> pitti: Yay!
<infinity> pitti: Nope, don't need the indexes, just want to make sure it's all working right.
<pitti> as for "hanging", any buildd which isn't on http://paste.ubuntu.com/6587836/
 * pitti sorts and diffs
<infinity> Hrm, beebe and birch look suspiciously absent.
<pitti> beebe just finished
<pitti> birch still hanging
<pitti> that's all
<infinity> Let me see if birch is dead.
<infinity> It's not the most reliable hardware.
<infinity> I have to stab it in the face every day or two.
<infinity> Oh, yeah, it's 6 hours into an apt-get.  It's dead. :P
<jamespage> mwhudson, I expect it not to be particularly security friendly but we could use spidermonkey as the scripting engine for archs that don't have v8 support yet
<jamespage> (context mongodb packages)
<jamespage> mwhudson, I suspect that's how upstream are supporting solaris deployments
<mwhudson> jamespage: err
<mwhudson> oh
<jamespage> mwhudson, upstream still ship that with the mongodb source package and it has broader arch support I think
<mwhudson> they do?
<jamespage> mwhudson, yup - js-1.7 under thirdparty
<jamespage> enabled using --usesm
<mwhudson> jamespage: hm, not there in git
<jamespage> mwhudson, ah - I think maybe its been dropped for the next stable release series - 2.6.x
<jamespage> its still in the 2.4 source tree
<jamespage> mwhudson, https://github.com/mongodb/mongo/tree/v2.4/src/third_party
<mwhudson> ah interesting
<mwhudson> oh ok
<mwhudson> so spidermonkey doesn't build on arm64 either :)
<mwhudson> but it's probably much easier
<infinity> Doesn't it?
<mwhudson> infinity: https://launchpadlibrarian.net/155832603/buildlog_ubuntu-trusty-arm64.mozjs17_17.0.0-1_FAILEDTOBUILD.txt.gz
<infinity>  libmozjs185-1.0 | 1.8.5-1.0.0+dfsg-4ubuntu1 | trusty/universe  | amd64, arm64, armhf, i386, powerpc
<jamespage> mwhudson, this might be a suitable stop-gap
<mwhudson> infinity: ah
<infinity> Not actually sure if 185 or 17 is newer.  Very confusing versioning.
<infinity> But 185 builds. :P
<mwhudson> ok
<jamespage> mwhudson, ignore me on the solaris support - looks like v8 does support solaris
<mwhudson> i now realise that i was confused earlier because i didn't have universe enabled properly in my chroot
<menace>  Hi, i have several files in /usr which belong to root:root. And they are user- and group-writeable. Now i think i can remember about exploits, which only give you group-root-privileges. Wouldn't it be more secure, that files which belong to root:root only be writeable for user root? or does that hinder any functionality?
<tseliot> pitti: is nvidia-prime 0.5 still in trusty-proposed (for some reason)?
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<pitti> tseliot: ^ yes
<pitti> tseliot: because it doesn't build for the ports any more
<tseliot> pitti: I made it arch specific
<pitti> tseliot: seems it previously was arch:all?
<tseliot> pitti: yep
<pitti> ok, let me remove the binaries for the other arches
<tseliot> thanks
<pitti> tseliot: done, should migrate in about an hour
<tseliot> pitti: thanks a lot :)
<doko> Noskcaj, feel free to grab everything from universe =)
<xnox> stgraber: so it seems I'm not using "ssh-agent" but rather the gnome-keyring provided ssh-agent, and there is no upstart jobs to start that up properly / re-export environment variables for the correct SSH_AUTH_SOCK
<xnox> is ssh-agent really the default one? or it happens that gnome-keyring takes over the default where available?
<xnox> LoganCloud: only upload boost-mpi-source if there is a matching version boost upload. the two packages are the same source but are split across main and universe, thus if they are version mismatched they get stuck in -proposed.
<xnox> LoganCloud: and usually it's best to ask last uploader / usual uploaders of non-trivial packages.
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<xnox> infinity: with proposed (eglibc2.18) there is a cross-build (amd64->armhf) failure that is not seen with just release pocket http://paste.ubuntu.com/6588304/ is it uhub bug or pthreads/armhf cross-compilation bug?
<infinity> xnox: Could be a uhub bug, could also be that our cross toolchain needs updating to use glibc2.18 for its private libs.
<infinity> xnox: Note that the complaining library is /lib/arm-linux-gnueabihf/libpthread.so.0, the cross-base one, not the multiarch one.
<happyaron> wonders if our grub menu can show localized texts?
<infinity> xnox: I could see having a cross-base at 2.17 and libc6:armhf at 2.18 could be an issue.
<xnox> infinity: ack =/ for now I just told to not use -proposed when cross-compiling. Too much arch skew visible anyway.
<mlankhorst> hey, can some archive admin move libdrm from NEW into -proposed ?
<mlankhorst> https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=
<mlankhorst> I'm guessing it's the same bug as before, libdrm-nouveau2 wasn't in precise, so it libdrm was accepted into NEW. it exists in precise-updates though...
<jamespage> mwhudson, built OK with spidermonkey but failed a couple of tests (JS ones...)
<jamespage> I'll poke at that later
<infinity> mlankhorst: Sorted.
<mlankhorst> thanks
<dholbach> can somebody please reject https://code.launchpad.net/~logan/ubuntu/trusty/mutagen/1.22-1ubuntu1/+merge/198129? It was already merged by somebody else
<dholbach> ah no, I can do it myself
<dholbach> nevermind
<pitti> stgraber: FYI, I moved your WIs on https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming to alpha-2
<pitti> (too late now for alpha-1)
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> (will do some more piloting tomorrow)
<maxiaojun> there is no way to uninstall a manually installed deb using USC?
<maxiaojun> ?
<dobey> tjaalton: hi. i'm trying to figure out how to work around the fact that glx isn't working under xvfb, and i came across https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1100312 which you marked as fix released for raring. however "xvfb-run -a glxinfo" (or running anything that requires glx) prints some errors from libGL about not being able to load the swrast driver
<ubottu> Ubuntu bug 1100312 in xorg-server (Ubuntu Quantal) "GLX extension fails to initialize in Xvfb" [Medium,Triaged]
<dobey> tjaalton: any idea how to get around that and use xvfb to run things that require glx on headless?
<dobey> swrast_dri.so is in the place it looks to load it, and LIBGL_DEBUG=verbose doesn't add any extra useful data to the output :(
<Sarvatt> dobey: xvfb-run -s "-screen 0 640x480x24" glxinfo
<dobey> Sarvatt: wtf? why does that work?
<Sarvatt> xvfb defaults to 8bpp, no glx support at 8bpp
<jdstrand> cjwatson: hey, can you think otoh how to determine at runtime what the gnu triplet is without using dpkg-architecture? I've not looked terribly hard but only thought of readlink -e'ing /lib/ld-linux*so* then getting it from the path. obviously, I kinda don't like that
<jdstrand> cjwatson: if not otoh, I'll keep looking
<cjwatson> jdstrand: best way I know of is to compute it at build time and build it into the binary
<jdstrand> cjwatson: yeah, this is for click-apparmor, which is arch all, so that doesn't work
<cjwatson> I'm not aware of a run-time-only method, so you'll need an arch any component
<jdstrand> (it is for aa-exec-click to set QML_IMPORT_PATH and LD_LIBRARY_PATH for fat
<cjwatson> it's small, you could just make the whole thing arch any and substitute
<jdstrand> I guess that's true
<jdstrand> that feels kind icky though
<jdstrand> cjwatson: ok, thanks
<cjwatson> np
<pitti> barry, doko: does this ring a bell? ImportError: No module named 'answer_0i04jl'
<doko> no
<barry> pitti: whuhhh?
<pitti> barry, doko: I get random faults like those in PPA builds
<pitti> https://launchpadlibrarian.net/160026669/buildlog_ubuntu-trusty-i386.python-dbusmock_0.6~171~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
<pitti> https://launchpadlibrarian.net/160026641/buildlog_ubuntu-saucy-i386.python-dbusmock_0.6%2B171~ubuntu13.10.1_FAILEDTOBUILD.txt.gz
<pitti> I retried a few times, and each time it seems to fail differntly
<barry> pitti: i have *never* seen that before
<barry> objmgr_40664_
<pitti> barry, doko: ok, thanks; just wanted to check if it's known already
<barry> pitti: could those be some kind of dbus generated fake modules?
<pitti> barry: yeah, those suffixes seem to be some random number
<barry> pitti: well, on the bright side, that'll be fun to track down :)
<pitti> I newer saw it locally either
<pitti> or on the distro builders, just now on the PPA builders; so plausibly related to running in qemu
<ogra_> pitti, hey, i'm trying to get client mdns support to work on my phone, is it not possible to install the libnss-mdns package alone ? (i only want the client resolution, not to run the avahi daemon, but it seems there is a hard dependency)
<ogra_> (pinging you because i remember you did a lot avahi stuff in the past)
<pitti> ogra_: "a lot" is a bit of an exaggeration, but you do need the avahi daemon, yes; the PAM module doesn't talk to the network
<ogra_> ah, k
<ogra_>   avahi-daemon bind9-host libavahi-core7 libbind9-90 libdaemon0 libdns99
<ogra_>   libgeoip1 libisc95 libisccc90 libisccfg90 liblwres90 libnss-mdns
<ogra_> its is a lot (on the phone) :)
<pitti> ogra_: the protocol works so that computers regularly broadcast their info, and the daemon picks it up; the daemon doesn't actively "ask" AFAIK
<pitti> ogra_: so the latency would be way too high
<ogra_> oh, ok
<pitti> ogra_: err, not PAM of course, the DNS module
<ogra_> yeah
<ogra_> nss
<ogra_> pitti, lennarts documentation makes it sound like it would work alone http://0pointer.de/lennart/projects/nss-mdns/
<cjwatson> that's only about 1.5MB of .deb size though
<ogra_> thats what confused me
<cjwatson> not that much despite the package count
<pitti> ogra_: well, I could be wrong
<pitti> ogra_: that is written in bold: "Thus, nss-mdns will not work unless Avahi is running! That makes Avahi essentially a hard dependency of nss-mdns. "
<ogra_> pfft ... thats buried in a whoole bold paragraph, how am i supposed to notice
<ogra_> :P
<ogra_> pitti, thanks !
<ogra_> :)
<ogra_> cjwatson, 1.5MB on the phone will cost me a lot of whisky to bribe pmcgowan_ :)
<cjwatson> you could call it a qt update and nobody would notice :P
<ogra_> lol
<cjwatson> I'd be more worried whether avahi-daemon chews battery
<ogra_> yeah
<pmcgowan_> what more packages!
<cjwatson> or memory
<ogra_> thats why i tried to install the client bit alone
<kees> doko: does arm64's gcc say "warning: -fstack-protector not supported for this target" ? (i.e. can I autodetect this condition?)
<doko> kees, not anymore ;-P but the glibc bits are not yet there
<kees> doko: is there a bug # for it to track?
<doko> I think there is one for linaro. sorry have to run now. back in a few hours
<xnox> cjwatson: ogra_: as far as I remmeber avahi doesn't work out of the box on the nexus kernel, and needs a config option change to get enabled properly (missing capabilities)
<xnox> cjwatson: ogra_: should i file that as a bug against kernel?
<xnox> or are we gona tweak conffiles on the phone?
<cjwatson> don't know, I was just driving-by
<kees> doko: anyway, I've pulled the ubuntu delta, so you can just sync hardening-wrapper 2.5 once it's built in debian
<shadeslayer> Does software-properties-gtk only check if a package is installed to see if it's in use? Because AFAIK you can install nvidia proprietary drivers and nouveau side by side
<shadeslayer> ( the driver manager part )
<tjaalton> dobey: I see Sarvatt replied already, good :)
<dobey> yeah
<dobey> not sure why 24bpp isn't default though. it's not 1995 any more :)
<tjaalton> noone cares enough
<dobey> push a patch upstream and it should land easy then :)
<tjaalton> what makes you think _I_ care ;)
 * tjaalton runs
<tjaalton> dobey: what's the usecase?
<dobey> tjaalton: qmltestrunner
<dobey> tjaalton: ie, running tests that depend on glx, under an isolated display with xvfb
<tjaalton> right
<tjaalton> maybe file a new bug and we'll see
<tjaalton> doesn't sound hard to fix
<tjaalton> hum, xvfb-run is a wrapper from debian
<tjaalton> XVFBARGS="-screen 0 640x480x8"
<tjaalton> so, maybe just change that
<Logan_> doko: What is the status on arm64 config.{guess,sub} updates? Should we be creating deltas in Ubuntu to do them locally with autotools-dev, or should we just be reporting to Debian?
<Logan_> ScottK: Would you mind taking a look at Bug 1261084?
<ubottu> bug 1261084 in libccrtp (Ubuntu) "Sync libccrtp 2.0.6-1 (universe) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/1261084
<brainwash> bug 1261863
<ubottu> bug 1261863 in xscreensaver (Ubuntu) "Update xscreensaver to the latest version" [Undecided,New] https://launchpad.net/bugs/1261863
<brainwash> can we sync the latest version of xscreensaver from debian?
<Noskcaj> brainwash, not even slightly
<Noskcaj> To sync, debian has to have all the changes at https://launchpad.net/ubuntu/+source/xscreensaver/5.15-3ubuntu1
<Noskcaj> So what you do here, is ping infinity
<brainwash> well, upgrade the version it is
<Noskcaj> The word you are looking for is "merge"
<Noskcaj> run "bzr branch lp:ubuntu/xscreensaver && cd xscreensaver && bzr merge lp:debian/xscreensaver" the resolve all conflicts and check all the changes are applied
<brainwash> nice to know, I'll try that
<GunnarHj> slangasek: ping?
<slangasek> GunnarHj: hi
<GunnarHj> slangasek: Hello, Steve!
<GunnarHj> slangasek: Do you have any comments on https://lists.ubuntu.com/archives/ubuntu-devel/2013-December/037899.html ? Partly asking because of your PAM proficiency.
<slangasek> GunnarHj: I haven't had a chance to think about it in any detail; there are tradeoffs regardless, profile only applies to shells and /etc/environment /etc/default/locale ~/.pam_environment only apply to PAM sessions.
<GunnarHj> slangasek: Ok. Maybe it would better to not state a 'recommended' way, but rather try to explain the differences.
#ubuntu-devel 2013-12-18
<skaet> slangasek, hiya,  its Tuesday now, so can you start the freeze for Alpha 1?
<bdmurray> that's interesting - https://errors.ubuntu.com/problem/fa095349a2a96bc2138b8372276f7ad69d05671f
<sarnold> haha, nice
<doko> Logan_, well, do them, but maybe using dh-autoreconf. if you do watch the changes ML, you'll see a bunch of uploads for another port where autotools-dev is not enough
<Logan_> ppc64lezgfeigzze?
<Logan_> Or whatever it's called.
<Logan_> doko: Wait, so... dh-autotools-dev is not enough for ppc64el?
<doko> kees, well, I can't sync, because I disabled the diversion, and removed the the old gcc diversions
<cjwatson> Logan_: sometimes but not always; any package that uses libtool tends to need the patch from https://launchpad.net/ubuntu/+source/libtool/2.4.2-1.3ubuntu2 applied, which dh-autoreconf usually manages
<cjwatson> but bear in mind that dh-autoreconf on its own won't necessarily always update config.guess/sub (though it always does at least when libtool is involved)
<cjwatson> care and understanding is needed :)
<Logan_> Fun.
<cjwatson> ppc64el does need *at least* config.guess/sub updates
<Logan_> Also...why do we call it el? Isn't it le?
<Logan_> "endian little"
<cjwatson> mipsel
<StevenK> Logan_: mipsel
<cjwatson> precedent tends to win
<Logan_> Oh right.
<StevenK> There was a proposal for sh4eb too
<cjwatson> and of course armel
<cjwatson> though you could retcon the "e" as "EABI" there
<Logan_> Oh, and another unrelated question. Devscripts was recently updated to make the default urgency "medium," and it's affecting the priority of new uploads coming from trusty when it comes to the buildds. Should the priority formula be tweaked?
<cjwatson> Is it really necessary to do anything there?
<cjwatson> It doesn't make that much difference
<Logan_> I suppose...
<StevenK> It's 10 versus 5
<Logan_> I'm thinking we should revert the change in Ubuntu. It's making changelogs confusing for the enduser, I think.
<cjwatson> And we're not often backlogged there
<Logan_> Because they'll be like, "why was a typo fix medium urgency?"
<cjwatson> I'd rather not have deltas we don't really need
<Logan_> Well then we should SRU it, imo. All or nothing. It doesn't make sense to have uploads coming from t+ being medium urgency, and s- low urgency.
<cjwatson> I think that'll balance out against the people who go "why was this OMG vital critical fix low urgency" at the moment
<cjwatson> I think we should just leave well alone and not make work for ourselves :)
<Logan_> Lol, it's killing my OCD
<cjwatson> it'll balance out in a few years
<YokoZar> Clearly we prioritize uploads coming from people actually running the dev version.
<Logan_> Just to push my agenda, I just did an autotools update for black-box, and it built immediately on ppc64el, before the 10785-job backlog (with a dependency wait, of course). I guess I shouldn't be complaining. :P
<cjwatson> honestly, it doesn't much matter which order that backlog builds in
<cjwatson> if we want something quickly we'll score it up
<Logan_> I know, I'm just being annoyingly pedantic. :P
<cjwatson> also, anything in proposed would already have built ahead of most of the backlog (the bulk of which is in the release pocket, with a lower score)
 * Logan_ shuts up.
<cjwatson> so it didn't advance it all that much
<cjwatson> only by 250 jobs or so
<cjwatson> which at this rate amounts to an hour or two :)
<cjwatson> (I like fast architectures)
<Logan_> It is impressive how quickly ppc64el is chugging through the packages, given the growing pains that the arm64 buildds had during the Saucy cycle.
<cjwatson> yeah, great difference between experimental hardware and solid server-class
<cjwatson> it'll be quicker than LP's estimate
<cjwatson> I bet 6 days earlier today, but it's gone from 11 to 9 in twelve hours or so, so I suspect even that estimate is generous
<Logan_> How much money on the bet? ;P
<Logan_> JackYu: Please fix your connection, or ubottu will eat you for dinner.
<xnox> bdmurray: cool =) fork-bomb?
<Logan_> xnox: https://launchpad.net/ubuntu/+source/libtk-img/1:1.3-release-12ubuntu2 --> https://launchpad.net/ubuntu/+source/libtk-img/1:1.3-release-12ubuntu3
<Logan_> *cough* *cough* :P
<Logan_> (fwiw, I just tested it, and the mentioned bug is happening again)
<xnox> Logan_: lol :P
<xnox> Logan_: is that ABI break on img::tiff side and can be fixed for real?
<xnox> Logan_: src:tiff3 is now filed for removal ther literarly is nothing depending on it, but this package.
<Logan_> I honestly have no idea. All I know is that reverting back to libtiff4-dev fixes it.
<Logan_> Yeah... :/
<Logan_> Maybe move it to proposed?
<xnox> well, a revert is not an option any more. it needs to be fixed properly.
<Logan_> Actually... http://packages.qa.debian.org/libt/libtk-img/news/20131215T173505Z.html
<Logan_> Maybe the new release fixes it. I'll do a test build and test.
<Logan_> If it works, I'll sync.
<xnox> Logan_: maybe we want the libtiff patches from fedora/gentoo? http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-tcltk/tkimg/files/
<xnox> Logan_: i wonder if that's the same patchset =)
<Logan_> Quite possibly.
<StevenK> There is this thing, called diff, perhaps you guys have heard of it ...
<Logan_> Not sure what you're trying to go for here.
<Logan_> Oh, haha. Comparing the patches?
<Logan_> xnox: Oh goodie. The new Debian version FTBFSed.
 * Logan_ cries.
<xnox> Logan_: well there is interdiff as well.
<Logan_> 'JPEG_LIB_VERSION' undeclared
<Logan_> Seems like a linking issue.
<xnox> StevenK: =))))) at 3:42am my care factor for libtiff for tk is not that high =))))
<Logan_> ...or maybe just a lack of declaration issue.
<xnox> StevenK: to like actually read diffs ;-)
<StevenK> xnox: To quote Matthew Garrett, perhaps you should read some autoconf macros to induce a coma.
<xnox> StevenK: =)))))))))))))))))) brilliant !
<Logan_> xnox: http://paste.ubuntu.com/6592395/ <-- my local build log for libtk-img 1:1.4.2-3
<xnox> Logan_: missing multi-arch ?
<xnox> Logan_: #define JPEG_LIB_VERSION 80 is in /usr/include/$(DEB_HOST_MULTIARCH)/jconfig.h
<Logan_> xnox: wait how do you do that what
<xnox> =))))))))))
<xnox> let me actually grab the source.
<Logan_> command plz
<Logan_> did you just grep it
<xnox> nah just a hunch. similar defines are usually part of a config.h or some such, and usually end up being multiarched into multiarch location.
<xnox> however
<Logan_> $ sudo grep -R 'define JPEG_LIB_VERSION' /usr/include
<Logan_> /usr/include/x86_64-linux-gnu/jconfig.h:#define JPEG_LIB_VERSION 80
<Logan_> look I can be all linuxy too
<xnox> i did pull-debian-source and it builds fine in trusty sbuild
<Logan_> Which arch?
<Logan_> And are you sure you did the right version? Because p-d-s got the old version for me before I explicitly specified the new one
<xnox> or more precise which version =) apperantly pull-debian-source doesn't know about 1.4 yet
<Logan_> ^
<xnox> it's building it's own copy of zlib =/ i thought that is autorejected by ftp-masters /o\
<slangasek> e-gratuitous-use-of-sudo
 * xnox really does not like this package
<Logan_> slangasek: oh shush :P
 * slangasek complies, and leaves the keyboard as he promised himself he would
<xnox> slangasek: have you seen the 13.10 thread? the argument is based on XP users being upgrade savvy... =)
<Logan_> Oh no, I installed grep from a rogue repository, and now it's taking over my computer! ;P (but touchÃ©)
<xnox> Logan_: well we did have ext4 zero out files before....
<Logan_> xnox: I think it's a perfectly valid argument, but it's way too late.
<StevenK> Logan_: I must of missed the patch to grep that has it farm for bitcoins
<Logan_> xnox: back to more important things than my VM which is not currently being zeroed out
<Logan_> StevenK: dogecoins, actually
<xnox> Logan_: honestly not a single xp user will notice 2014 come and go. They have already been getting enough warnings, and MS did bump xp support cycle multiple times now....
<Logan_> xnox: did it fail in your build
<Logan_> *sbuild
<xnox> looks like it's building against a local copy of libjpeg and a system one, which seems very odd.
<Logan_> Wait, why does it have it's own jconfig.h?
<Logan_> *its
<Logan_> in libjpeg/libjpeg
<Logan_> Looks like we reached the same conclusion. :P
<Logan_> I'm going to examine the diff to see if this was caused by the new upstream release.
<Logan_> There's some weird shit going on in this package. There's a patch for "dynamic linking to system-wide libjpeg."
<kees> doko_: which diversion did you disable?
<kees> (and why?)
<xnox> Logan_: http://paste.ubuntu.com/6592467/ ?
<Logan_> xnox: Does it work?
<xnox> Logan_: did locally, testing in sbuild.
<Logan_> Okay. Looks good to me. Although why did you change those other lines?
<xnox> i'm building cross-toolchain at the same time so my machine is busy.
<Logan_> I'm a bit of a n00b when it comes to multiarch, so I'd like to know.
<xnox> Logan_: i needed DEB_HOST_MULTIARCH, and instead of +1 line, i could remove all of those.
<Logan_> I see.
<xnox> and use default.mk which include architecture.mk which defines all combinations of DEB_* variables
<Logan_> Alright, gotcha.
<Logan_> I'll save that diff for future reference. :P
<Logan_> It'll go in my folder of "smart things Ubuntu/Debian developers have done to fix things that I'll definitely encounter in the future."
<Logan_> Well, I hopefully won't encounter a package this odd in the future, but you never know.
<xnox> ... i rather hope nobody ever encounters that =)
<xnox> Logan_: the bigger question however, is to see if it works ;-)
<Logan_> Oh right. Forgot about that.
<xnox> and that bug is not present.
<darkxst> pitti, hi, is it possible to get a source packages dependencies from LP api?
<Logan_> xnox: If you're still around, would you mind helping me figure out why this isn't building? https://launchpad.net/ubuntu/+source/ns2/2.35+dfsg-1ubuntu1/+build/5360743
<xnox> Logan_: checking for libtcl8.5... no
<xnox> Logan_: probably fails to find multiarch tcl, and it's trying to parse the compat tctConfig.sh script direct instead of sourcing it
<xnox> Logan_: there should be a configure option to pass, with exact / multiarch location for tcl
<Logan_> Okay, I'll check it out. Looks like this similar bug might have a potential fix: https://bugs.launchpad.net/ubuntu/+source/db/+bug/1160445
<ubottu> Ubuntu bug 1160445 in db (Ubuntu) "FTBFS: update for m-a tclConfig.sh path" [Undecided,Fix released]
<Logan_> xnox: I passed --with-tcl=/usr/lib/$(DEB_HOST_MULTIARCH) to debian/rules, but now it fails with this: http://paste.ubuntu.com/6592645/
<Logan_> It appears to have fixed the libtcl8.5 part but broken everything else. :(
<Logan_> Well I'm stupid. There's a patch fixing this in Debian's BTS. :P
<xnox> debian has tcltk multiarched as well now, so all patches should be forwarded to debian and/or become a debian bug as well.
<Logan_> We're all good now.
<pitti> darkxst: not that I know of
<pitti> Good morning
<darkxst> pitti, ok, I couldnt see anything either, time to find a new plan...
<pitti> darkxst: what's wrong with getting it from python-apt?
<darkxst> pitti, only that the server I am running the script on is not ubuntu, however I guess I can do just that in a chroot
<pitti> darkxst: have a look at chdist, it's really useful for things like that
<pitti> and it only needs the Packages indexes, not the actual packages (i. e. full chroot)
<darkxst> server is not debian either, so need a chroot to even run chdist!
<pitti> darkxst: ah, in that case it might perhaps suffice to wget -O- http://archive.u.c./.../Sources.gz | gzip -cd | <some perl magic to grep for the Package: and Build-Deps> ?
<pitti> or copy grep-dctrl to that server, to at least ease that bit
<pitti> ldd /usr/bin/grep-dctrl â doesn't use anything special, just libc
<darkxst> pitti, ok, thanks. will look into it
<xnox> .... m4 .... my eyes are sore, hunting down two stray spaces =/
<xnox> pitti: morning =)
<pitti> anyone from ubuntu-release around at this hour?
<pitti> infinity: could you plese set an exfail/britney hint for adequate? its autopkgtest requires "breaks-testbed" and we cannot currently handle that with our null runner
<pitti> it holds back the new perl version, which in turn holds back some other stuff
<infinity> pitti: I can do.
<pitti> ah, it's also part of the a1 freeze, but at least it'll promote automatically after it then
<infinity> pitti: I can't do it unversioned, though, so it'll have to be bumped with each sync.  Maybe we should just introduce a delta that disables that test?
<pitti> I was looking for the excuses/update_output for postgresql-9.1 and postgis, but it seems it's gone from update_output
<pitti> infinity: ah, ok; I'll look into that then; we can drop the breaks-testbed and just run the most important test
<infinity> pitti: Kay, that's probably the saner way to go for now.
<pitti> infinity: so, never mind
<infinity> pitti: And maybe make a note of any packages you mangle in such a way in a TODO reminder for if/when our testbeds support breaking. :P
<pitti> *nod*
<pitti> oh, it's just one test anyway, so we can drop it
<infinity> pitti: Kay, that'd definitely better than skipping testing for the whole package.
<infinity> (Which is what force-badtest would do)
<pitti> now, let's see whether it actually works
<pitti> argh, and of course it fails
<alkisg> I found a bug in Trusty, does someone know about e.g. ssh client changes that might have triggered it? The following work from a 12.04 client but not from a 14.04 client:
<alkisg> tty1# ssh -MS /tmp/socket user@server [OK]
<alkisg> tty2# ssh -S /tmp/socket user@server ls [Control socket connect(/tmp/socket): Connection refused]
<alkisg> And another thing that worked in 12.04 but not in Trusty:
<alkisg> # iptables -t nat -D POSTROUTING -s 192.168.67.0/24 -j MASQUERADE
<alkisg> iptables: No chain/target/match by that name.
<pitti> infinity: ok, adequate tests fixed
<alkisg> OK changing "-D POSTROUTING" to "-A POSTROUTING" made the iptables command work,
<alkisg> so only the ssh socket problem remains, which btw breaks LTSP logins... :(
<tjaalton> is there an image to use on a pandaboard anymore?
<tjaalton> guess 13.04 is the la(te)st
<sarnold> tjaalton: I believe the intention is that the generic armhf kernel ought to work well enough on pandaboard so that no device-specific thing is needed
<tjaalton> ahh
<tjaalton> indeed
<xnox>  / headless / that is
<sarnold> they can have a head? :)
<sarnold> (actuall i was mighty impressed with our 12.04 LTS install experience on the panda, it was much snappier than I expected)
<sarnold> xnox: thanks for the warning. :)
<pitti> infinity: there are a couple of postgresql extensions which don't work with 9.3 any more, and they seem to be pretty dead upstream (orafce, pljava); bugs are filed in Debian; I'd like to remove them from trusty without blacklisting, so that they'll get synced back once they are ported; does that sound ok?
 * pitti is doing the final steps for the 9.1 -> 9.3 transition for trusty
<xnox> pitti: yeap, it's called "demote to proposed" there is a script in archive tools to do that.
<xnox> pitti: this way the source & binaries are available in proposed and are carried over & never released.
<pitti> xnox: hah, thanks
<xnox> pitti: yet will come back via debian. It's equivalent of "remove from testing, keep in unstable".
<xnox> pitti: do note, that you may need to block with a bug and/or release hint, if britney just would migrate it straight back.
<pitti> $ demote-to-proposed -m "does not work with PostgreSQL 9.3, Debian #731515" orafce
<ubottu> Debian bug 731515 in orafce "orafce: Please build postgresql-9.3 extension only" [Important,Open] http://bugs.debian.org/731515
<xnox> as long as it's not installable, looks good =)
<xnox> do note I'm not AA / ReleaseTeam =)
<pitti> xnox: it's FTBFS, but I guess that wouldn't stop britney
<pitti> it would become uninstallable once postgresql-9.1 propagates
<pitti> but it can only do that once I removed orafce and friends from trusty
<pitti> so, blocker bug it is
<xnox> import-bug-from-debian 731515 and tag "block-proposed"
<ubottu> Debian bug 731515 in orafce "orafce: Please build postgresql-9.3 extension only" [Important,Open] http://bugs.debian.org/731515
<xnox> yeap =)
<pitti> I guesss I can just take 1260718
<pitti> bug 1260718
<ubottu> bug 1260718 in repmgr (Ubuntu Trusty) "Move to postgresql-9.3" [Undecided,Confirmed] https://launchpad.net/bugs/1260718
<xnox> =)
<pitti> https://launchpad.net/ubuntu/+source/orafce/+publishinghistory
<pitti> so it's deleted from trusty, but not added to trusty-proposed?
<pitti> Rejected:
<pitti> orafce 3.0.4-1 in trusty (binaries conflicting with the existing ones)
<pitti> just got that as mail
<pitti> well, they'll auto-sync back once they get fixed
<pitti> worked for repmgr, though
<alkisg> The problem in ssh sockets seems related to overlayfs, it works fine if I use /run which is tmpfs, but not if I use the LTSP or casper's overlayfs /*
<sarnold> interesting..
<xnox> alkisg: use /run. everything else is not appropriate for sockets.
<xnox> alkisg: or, if there is support for that, use abstract linux sockets.
<sarnold> alkisg: I'm surprised the filesystem type matters, once it can support a socket file type anyway..
<alkisg> xnox: that goes for users too? so users would create a socket in /run/tmp ?
<alkisg> (the user $HOME is not appropriate, it can be sshfs or worse)
<xnox> alkisg: normal users should create sockets in $XDG_RUNTIME_DIR which is guranteed to be set for all user-pam sessions.
<xnox> alkisg: see the XDG spec.
<alkisg> Thank you xnon, I'll update the LTSP code accordingly
<alkisg> *xnox, sorry
<xnox> (typically XDG_RUNTIME_DIR is "something like tmpfs" and on ubuntu it's /run/user/UID/... or somesuch)
<alkisg> Hmm it's not set in ssh logins in 12.04
<alkisg> OK we'll use some fallback logic
<alkisg> I think /run/user/UID was implemented after 12.04...
<xnox> alkisg: the right thing is to check for the var, and otherwise pick something else. again as per XDG spec.
<alkisg> Cool
<xnox> alkisg: it was implemented in 12.10 I believe.
<alkisg> Gotcha, thanks again, /me gets back in his coding dungeon... :)
<jamesh> sil2100: would you have time to do a packaging review for the new media scanner?
<sil2100> jamesh: hello! Sure, new media scanner? A new package?
<jamesh> sil2100: lp:mediascanner/v2 -- this is a new code base.  One new request I've got is to make it parallel installable with the old code base, to make it easier to integrate without breaking all old users
<doko_> kees: GCC 4.2, 4.3 and 4.5 on all archs, and ld.gold on arm64
<dholbach--> dpm_: I'm still struggling with my laptop :/
<dholbach--> did anyone else run into a libc6-amd64 surprise on an upgrade today?
<jamesh> sil2100: for the parallel install issue in mediascanner, I think I've got the libraries/headers sorted out.  I was wondering if there is any guidelines for the package naming. With some pointers, I might be able to get some of those issues out of the way.
<sil2100> jamesh: let me take a look a those after the meeting
<jamesh> okay
<xnox> jamesh: boost, tcl, tk, python, db, are all co-installable multiple versions of the same library (most of them, most of the time)
<xnox> jamesh: we do try to minimise the amount of versions. In practice it's only runtime libraries that are needed to be co-installble. The -dev packages may conflict with each other, simply because one does clean builds in chroots one at a time anyway.
<xnox> jamesh: but some do offer co-installation of -dev packages as well. e.g. qt4 and qt5, gtk2 and gtk3 (althought they are significantly different to warrant that)
<jamesh> xnox: well, I made the headers and pkg-config files co-installable, simply because the old implementation had done half the work already (putting headers in a sub directory, version number in pkg-config file, etc)
<xnox> =) fair enough ;-)
<dpm_> dholbach__, argh, good luck :/
<dholbach__> dpm_: https://wiki.ubuntu.com/Touch/Emulator â 'if you are on amd64'
<dholbach__> dpm_: that's what has got me again
<dholbach__> bbiab
<dpm_> dholbach__, ah, so it's not actually fixed?
<dholbach__> dpm_: I had an upgrade of libc today which got me into a "/bin/ls: not found" situation again
<dholbach__> so I guess that's the case - I'm online from a live session right now
<dpm_> :(
<dholbach__> brb
<doko> jamespage, infinity: i386 now runs openjdk zero. munin given back
<rbasak> stgraber: fyi, bug 1261088. It looks like a minor though valid point to me.
<ubottu> bug 1261088 in openvpn (Ubuntu) "init.d script: rm of $NAME.status file uses incorrect pathname" [Undecided,New] https://launchpad.net/bugs/1261088
<rbasak> I presume there's a /var/run -> /run symlink on every Trusty system?
<jamespage> doko, great - thanks!
<dholbach> can anyone help me with a libc6 upgrade problem? I'm seeing http://paste.ubuntu.com/6593456/ because of what I believe to be the aftermath of https://wiki.ubuntu.com/Touch/Emulator (the '/!\ If you are on amd64' bit)
<randomcpp> dholbach, ping
<alkisg> gnome-panel in 12.04, 14.04 etc has a race condition and many times it won't load correctly, especially on slow /home (e.g. sshfs).
<alkisg> By creating a wrapper that only does this: "/usr/bin/gnome-panel &", it works fine (!), while if I omit the last "&", it still has the problem
<alkisg> ...but I can't imagine what could be to blame there, and how a simple "&" fixes it... any idea?
<randomcpp> dholbach, ping
<dholbach> randomcpp, pong
<dholbach> randomcpp, I'm in the middle of fixing a broken libc installation on my main system, so I'm a bit preoccupied - it might be better if you send me an email so I can get back to you later; or if anybody else can probably help, just ask in here
<xnox> rbasak: yes, but things should start using /run by default.
<randomcpp> dholbach, I heard you had an issue while updating libc6 on amd64, I just had one, now my system is completely broken (it hangs with a kernel panic while booting). How have you solved? (here's the apt log http://paste.ubuntu.com/6593483/ )
<dholbach> randomcpp, no, not fully solved yet
<dholbach> randomcpp, check out https://wiki.ubuntu.com/Touch/Emulator (the '/!\ If you are on amd64' bit)
<dholbach> I got my system to boot again, but I'm stuck in between libc versions right now
<randomcpp> I have touch emulator installed, but I've never removed it
<xnox> dholbach: there is a simple command that one can run to recover. let try to find where it was.
<dholbach> yeah, it doesn't matter - it's more about having had the broken version of it installed early on
<randomcpp> and I have both amd64 and 32bit version of libc installed
<xnox> dholbach: ld.so is actually directly executable and using it direct one can fix the system.
<xnox> randomcpp: that is ok, as long as it's libc6:amd64 and libc6-i386, not the other way around =/
<randomcpp> dholbach, how did you get the system boot again? mine can't load /bin/init at the moment :/
<rbasak> xnox, stgraber: right, so it does look like a merge error but a minor one.
<dholbach> randomcpp, with a ubuntu live session on a usb stick
<dholbach> randomcpp, did you try the instructions on the wiki page?
<randomcpp> I'm going to try now, brb
<xnox> infinity: ^ do you remember the ld.so way of fixing the broken symlink form like initramfs break-bottom to recover the libc6 removal resulting in broken ld.so ?
<dholbach> brb
<infinity> xnox: /lib/x86_64-linux-gnu/ld-2.18.so /bin/ln -s /lib/x86_64-linux-gnu/ld-2.18.so /lib64/ld-linux-x86-64.so.2
<infinity> xnox: Adjust paths to taste if doing it from an initramfs mount.
<xnox> infinity: thanks, darn both affected people gone
<infinity> xnox: It helps if you think of ELF executables as "ld.so scripts", so the same way you'd invoke "/bin/sh foo.sh" or "/usr/bin/python foo.py", you can do with ELF binaries.
<infinity> xnox: And, indeed, that's exactly what the kernel does.
<xnox> infinity: right, thanks. that is indeed a good framework =)
<infinity> (Parses the PI out of the header, the same way it parses your interpreted from a shebang)
<infinity> interpreter*
 * xnox Inception - the IT crowd edition
<jamesh> sil2100/xnox: I've made the parallel install changes for mediascanner/v2 here: https://code.launchpad.net/~jamesh/mediascanner/parallel-install/+merge/199440 -- I'm still interested in a general packaging review though.
<xnox> doko: is openjdk-6 will be fixed in a similar fashion openjdk-7, after eglibc-2.18 breakage?
<xnox> fashion as openjdk-7?
<doko> I fashon removal
<caribou> could dholbach's libc6 issue be tied to the most recent server .iso image not being able to install ?
<caribou> I'm getting "Loading libc6-udeb failed for unknown reason" when trying to install Trusty from the latest server image
<xnox> doko: ack. I fashion excuse to make android build not depend on java at all (the android system images that is)
<xnox> infinity: doko: thanks for making this critical ;-)
<infinity> xnox: The bug was always there, AFAICT, it just seemed to surface randomly before, and now more consistently with glibc 2.18. :/
<infinity> xnox: I need to find some time to see if I can sort out what openjdk is doing wrong.
<infinity> (At least, googling for it brings up a lot of very similar backtraces going back many years)
<xnox> infinity: meh, i'll just make sure java is not on the critical path for ubuntu-touch =)
<doko> infinity, xnox: no, it wasn't seen on i386. and the amd64 issues were only seen with downloaded code not found in the distribution
<stgraber> rbasak: oh, thanks for openvpn. I'll make a note to fix that on Thursday
<xnox> stgraber: re: goldfish vs generic. The device name is generic, and that's what used in initramfs / udev rules et al. Can the device be named generic on the system-image side as well?
<xnox> stgraber: or is there something named inconsistent somewhere, and hence "goldfish" was picked up on the system-image side of things?
<stgraber> xnox: cdimage.u.c says goldfish
<xnox> ogra_: ! it's generic, not goldfish.
<xnox> stgraber: that needs changing =)
<ogra_> xnox, it isnt for the images
<ogra_> only for the device
<xnox> ogra_: it should match the getprop name, otherwise a few things break and for the sake of consistency.
<xnox> ogra_: the device name is generic.
<xnox> ogra_: both in Cyonogenmod, AOSP and everywhere =)
<stgraber> xnox: if you want to change the name to generic, we'll need to coordinate the landing as both need to change at the same time and I need to do some hacks to transition any from goldfish to generic
<stgraber> (as in, not today since I'm off ;))
<ogra_> xnox, well, i belive rsalveti introduced that naming because the build target in CM and AOSP is called goldfish
<xnox> stgraber: well there are none that use goldfish at the moment.
<stgraber> (and jetlagged, and have an headache, ... really, just on IRC because I'm waiting for a train and don't have much else to do ;))
<xnox> ogra_: custom product in CM is called goldfish, to do separate config. in AOSP it's called "full"
<ogra_> xnox, the build uses goldfish
<ogra_> the output of the android build is called golfish in the zip name
<xnox> ogra_: actual generated images by "goldfish-cm" product are "generic" and the device name is generic.
<ogra_> xnox, the output in the anbdroid package disagrees
<xnox> ogra_: and? getprop device name is generic, and that's what we go by  in system-image cli utility, initramfs hooks, udev rules.....
<ogra_> (happy to help solving that after my vacation if it actually needs solving)
<ogra_> yes
<xnox> ogra_: yeah, it needs solving system-image updates are broken for emulator at the moment =)
<ogra_> we do the same for other arches too ... :)
<xnox> ogra_: enjoy your vacation =)
<ogra_> their build name also differs from the image name sometimes ;)
 * ogra_ doesnt mind how we call it, as long as we can later make it arch distinct (generic-x86 vs generic-armhf or some such) so we can have emulators for different arches identified in the image names
<ogra_> (i didnt pick goldfish :) )
<xnox> ack.
<rsalveti> xnox: let's fix that once we switch to 4.4
<dholbach> xnox, did you find the magic command somewhere? O:-)
<rsalveti> which should happen soon
<xnox> dholbach: I did, added to the wiki page.
<dholbach> thanks!
<rsalveti> as the naming might change again anyway
<xnox> dholbach: it can be run from e.g. just broken machine whilst it's still running
<xnox> dholbach: or by booting with "break=bottom" on cmdline without actually needing to boot a live-cd for example.
<xnox> dholbach: it's just when booted with "break=bottom" the rootfs is mounted elsewhere, check output from $ mount
<xnox> rsalveti: hm =/ well system-image server is blocking system-image updates on the emulator for barry.
<xnox> rsalveti: stgraber: any way to alias "generic" to "goldfish" on the system-image.ubuntu.com for the time being?
<stgraber> xnox: nope, we can alias channels, not devices
<xnox> ack.
<stgraber> xnox: but I could do some ugly hacks if needed, I just don't think it's that urgent
<ogra_> right, that wuld have to happen inside system-image client side i guess
<xnox> rsalveti: i'd rather change goldfish -> generic sooner than later. not many people are using it at the moment.
<stgraber> and as ogra_ said, we probably want that named generic-armhf instead
<xnox> stgraber: that will break a lot of things.
<stgraber> xnox: well, better break them when we don't have any user than wait until someone asks for generic-amd64 and we have to start renaming stuff
<xnox> stgraber: i'll check the x86 device name, i think it goes by generic for armhf, generic-mipse/-x86 for the others.
<ogra_> xnox, not if the build already calls it like that (so that getprop returns the arch name too)
<xnox> if the are already i386 & mipsel names sure. if all of them are generic, then we do need to rename all of them.
 * xnox please hold, your call is important to us. We will be back with you shortly.
 * ogra_ thinks generic-arm64 is more realistic than generic-amd64 ;)
<xnox> well we have workitems to build generic-x86 (as in i386/atom) images this cycle.
<ogra_> yeah
<ogra_> thats why i poked at the disctinct naming above :)
<doko> xnox, gccxml still in main?
<xnox> doko: yes, didn't merge latest boost yet. will do it soon. Actually i think i can do it now / today.
<xnox> rsalveti: stgraber: are recovery OTA keys used at all? that's the only reason java is pulled into the android build.
<stgraber> xnox: I don
<stgraber> don't think so
<stgraber> our OTA updates use standard gpg
<ogra_> xnox, java used to be needed for the zip creation of the android side ... unrelated to ubuntu and i belive sergio actually patched out the need for it completely (i might mis-remember thoough)
<xnox> ogra_: yeah, it is optional. but at the moment the java tools are part of the build targets, and thus are pointlessly compiled each time.
<ogra_> i thought that was ripped out ... weird
<ogra_> (or did goldfish bring it back)
<dholbach> xnox, because I was in the middle of the libc upgrade, I had to repoint a bunch of symlinks to the 2.17 version, then manually installed the libc* packages again and right now it looks like it all might work out, at least 'dpkg --configure -a' was happy again
<dholbach> just saying... in case I drop off again and randomcpp needs another suggestion :)
<xnox> dholbach: if anything runs, than you are good to go =)
<xnox> s/than/then/
<xnox> without ld.so, nothing runs =)
<dholbach> I was at the point a couple of times before, but the upgrade would complain about *2.18*.so files lying around
<dholbach> but anyway, let's see how this goes now
<dholbach> xnox, thanks again for the help
<dholbach> seems like I'm all set
<xnox> Laney: pull-debian-source appears to be pulling from testing, instead of unstable. Have you noticed this?
<xnox> Laney: even with specifying "sid"
<xnox> had to pass explicit version number =/
<Laney> no
<Laney> give me a package name
<Laney> laney@iota> pull-debian-source ghc                                                                                                    ~/temp
<Laney> pull-debian-source: Downloading ghc version 7.6.3-6
<xnox> Laney: boost1.54
<Laney> it's because rmadison is out of date
<Laney> rmadison -u debian -a source -s sid boost1.54
<xnox> ah, thanks.
<xnox> applies not my problem field
<rsalveti> xnox: no, you can remove the ota keys
<rsalveti> xnox: sorry, what is currently blocked in the system-image server side?
<rsalveti> not sure if I understood correctly what is the issue with the wrong device name in there
<rsalveti> and we can fix the device name now as well, but I'm currently rebasing our patches for 4.4
<rsalveti> and that will change anyway
<xnox> rsalveti: system-image cli does getprop device name and gets "generic", it then talks to https://system-image.ubuntu.com/devel/ and gets 404 since there is no "generic" device, only "goldfish"
<rsalveti> we'd also need a different name for the x86 version, like goldfish_x86 or similar
<xnox> impedance missmatch =)
<rsalveti> right, but system-image updates is not supported in the emulator right now anyway
<xnox> rsalveti: that's what I need to check. if the names are different between armhf, x86 and mipsel. than we can use them.
<xnox> rsalveti: sure, but barry is blocked at enabling that =)
<rsalveti> well, we first need to fix our image to avoid any custom stuff on top of it
<xnox> rsalveti: and there is emulator.... and there are image updates on the server....
<rsalveti> so it can boot in ro mode
<rsalveti> if you really want it to be updated with the default method
<xnox> sure, sure. =) one can system-image update a rw image as well, via command line ;-)
<xnox> which is a good way to enable it.
<xnox> if it's "generic" across all arches, then we need to customize them indeed.
<rsalveti> hm, right, but that will not necessarily work for most of the times
<xnox> rsalveti: so no changes are needed on the android side.
<rsalveti> well, I think goldfish is a CM specific codename
<xnox> rsalveti: it's the syste-image.ubuntu.com website that should be publishing "generic" device name instead of "goldfish" at the moment. as that seems to be the odd one out.
<rsalveti> then we have generic, generic_x86 and generic_mips
<rsalveti> we'd need to either use generic for everything, or replace generic with goldfish
<xnox> rsalveti: yeap. same conclusion here as well. it's "full" targets and "generic" device name in AOSP and (non-working) in CM.
<rsalveti> and have goldfish, goldfish_x86, etc
<xnox> well, there are more things that use generic already.
<xnox> although arguably goldfish is a fancier codename than boring "generic"
<xnox> or emulator, as adb devices reports it =)
<rsalveti> right
<rsalveti> would indeed be nice to have only one codename across all tools
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<happyaron> dholbach: have time to sponsor this package? https://bugs.launchpad.net/ubuntu/+bug/1261825
<ubottu> Ubuntu bug 1261825 in Ubuntu "Please sponsor fcitx-qimpanel-configtool/0.1.3-0ubuntu1" [Undecided,New]
<dholbach> happyaron, I'll add it to my list
<happyaron> great, thanks
<xnox> happyaron: do subscribed ubuntu-sponsors to the sponsorship request bug report as per https://wiki.ubuntu.com/SponsorshipProcess that way it would appear on the queue to be sponsored. Otherwise they do not.
<xnox> happyaron: it's faster if it's in the queue.
<dholbach> zyga, is anyone looking at https://bugs.launchpad.net/ubuntu/+bug/1254831?
<ubottu> Ubuntu bug 1254831 in Ubuntu "plainbox needs packaging" [Undecided,New]
<zyga> dholbach: it's on my todo list today
<dholbach> zyga, ok cool
<zyga> dholbach: just doing some more code reviews and I'll get right to it
<dholbach> super, thanks
<dholbach> just looked at it because I'm patch piloting today
<barry> xnox, rsalveti: i like goldfish because it kind of fits in with the naming scheme :)  but whatever.  system-image ultimately doesn't care, as long as the device and system-image.ubuntu.com are in agreement (and the latter requires stgraber)
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<xnox> barry: i had no idea, it's so long, and thanks for all the fish ;-) naming theme.
<barry> :)
<Laney> xnox: I poked UDD and rmadison is now right (for now)
<xnox> Laney: you can poke _debian_ madison?! *_*
<Laney> yeah I have uddadm
<xnox> Laney: I see ;-) noted
<Laney> oh no, you go ahead and forget that now :P
<xnox> Laney: there is no lastic that can erase permament ink biro inscriptions in my Ubuntu Orange notebook =)
<Laney> hoho
<Laney> anyone got an example of creating a locale in a package build?
<Laney> is the script gcc uses best practice for that?
<xnox> i wouldn't call gcc packaging to be best practices of anything =)))))))
<xnox> didn't bzr do locale tests or some such?
<Laney> hmm, not seeing it
<infinity> Laney: The easiest way to get a locale in a package build is to build-dep on the language-pack for the locale you want.
<Laney> infinity: I'd like it to be Debianable
<infinity> Laney: build-dep on "locales-all | language-pack-en"
<Laney> I'm calling localedef myself now, will see if it works
<infinity> Laney: locales-all is all locales in Debian.  And we'll have it soon too, when I change our packaging.
<pitti> localedef needs the /usr/share/i18n/ data, though
<pitti> so you can b-dep on "locales" and call localedef yourself, yes
<Laney> yeah, from locales
<pitti> and set LOCPATH
<Laney> yep, that's the recipe
<infinity> Or, you can just build it yourself and set the path, sure. :P
<infinity> But the build-dep on locale-all seems less hackish.
<infinity> And less code. :P
<pitti> Laney: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/langpack-locales/trusty/view/head:/debian/local/test-locales
<Laney> is there a reason that locale-gen doesn't output in LOCPATH?
<pitti> Laney: well, it does, but you can't do that during package build (write to /usr/lib/, I mean)
<infinity> pitti: Hence the build-dep suggestion.
<infinity> (Which seems to have fallen on deaf ears)
<pitti> yes, locale-all, but we don't have that just yet
<pitti> or do we?
<infinity> pitti: Yeah, but "locales-all | language-pack-langiwant" works.
<pitti> *nod*
<infinity> pitti: We'll have locales-all in my next glibc upload, I didn't do it for 2.18, cause I needed to get it done this year. :P
<Laney> Yeah, that would; I'll do it if this test doesn't work out
<Laney> I try to avoid alternate build-deps if possible though
<pitti> won't be for long :)
<infinity> We can drop a few deltas when I bring in locales-all, so that will be nice.
<infinity> pitti: Do language-packs unconditionally call locale-gen?
<pitti> infinity: they call install-language-pack, which then calls locale-gen
<infinity> pitti: We might want to make that smarter to depend on 'locales | locales-all' and not call locale-gen if it's not on the system.
<pitti> install-language-pack is a script from langpack-locales, so that we can centrally modify it wihtout having to rebuild a gazillion langpacks
<infinity> pitti: locales-all doesn't ship it, for obvious reasons.
<pitti> infinity: oh, does locales-all COnflicts:/Replaces: locales? I thought the two would go on top of each other
<infinity> pitti: There's no conflict, but also no dependency, and no need to call locale-gen if locales-all is installed, cause you already have all the locales.
<pitti> *nod*
<pitti> so we need to make {install,remove}-language-pack smarter
<infinity> Actually, it Provides: locales, so no need to change the dependency, just need to detect that the local already exists and not try to call locale-gen.
<hallyn_> hi - i'm suffering from a misunderstanding about package installs and upstart jobs.
<hallyn_> if a package ships an upstart job, and that upstart job, in pre-start, does {stop; exit 0;},
<hallyn_> i would have thought that would count as 'ok'
<hallyn_> but in practice, package install says it fails
<infinity> hallyn_: I would expect that to be fine.
<hallyn_> <4>init: cgroup-lite pre-start process (491) terminated with status 127
<hallyn_> start: Job failed to start
<infinity> hallyn_: Perhaps the whole job would be more enlightening?
<hallyn_> infinity: this is the cgroup-lite package, in precise-proposed.
<hallyn_> apparmor can prevent it from mounting the cgroups.  In that case I want the upstart job to not be running, so that userspace can easily tell it can't rely on it
<hallyn_> but having package install fail because of it seems hard-core
<hallyn_> now maybe i'm just wasting time, and i should just have the upstart job succeed...
<Laney> seems it did work
<infinity> hallyn_: I can't seem to reproduce this.
<Laney> thanks for the wisdom infinity and pitti
<Laney> I'll drop it as soon as we get locales-all
<infinity> Oh.
<hallyn_> infinity: you can't reproduce the failure to install?  if so, just 'sudo lxc-create -t ubuntu-cloud -n u1 -- -r precise;  sudo lxc-start -n u1;  and in that container update to proposed and install cgroup-lite
<infinity> hallyn_: I can't reproduce it because I don't have /bin/cgroups-umount installed, I bet.
<hallyn_> actually just ln -s /bin/false /bin/cgroups-mount and -umount should work to reproduce :)
<infinity> hallyn_: So, you're calling "stop" if cgroups-mount doesn't work, which then calls cgroups-umount, which also fails to work, and you exit non-zero.
<hallyn_> oh.
<infinity> hallyn_: At least, that's my guess.
<hallyn_> that makes sense ;)  lemme try
<hallyn_> hm, adding '|| true' to umount doesn't change the result of 'start cgrou-lite'.  trying fresh install
<infinity> hallyn_: Yeah, if I take all the "stop"s out of your start clauses it works fine.
<infinity> hallyn_: In any of those cases, do you actually WANT to try to umount?
<infinity> hallyn_: If not, then the stops shouldn't be there.
<alexmuro> If I wanted to start hacking on nautalis file manager where would I find the source code, any ideas?
<hallyn_> i see.  i thought 'stop' kept it from proceeding to the 'start' state (and only did that)
<infinity> hallyn_: Nah, exit will take care of making sure it goes nowhere. :P
<hallyn_> infinity: though yes, if it failed partway into mounting, i want it all unmounted
<infinity> hallyn_: Anyhow, || true after the umount also works for me.
<infinity> hallyn_: Well, my umount is /bin/false, but...
<hallyn_> what do you get when you have || true?
<infinity> Oh, nevermind, upstart thought it was "already running" and wasn't starting it.
<infinity> There.  THis works.
<infinity> hallyn_: http://paste.ubuntu.com/6594934/
<infinity> hallyn_: So, that lets you still try to umount if start blows up somehow.  But if that's not likely, just removing the stops is also sane.
<hallyn_> ah, i see, 'true' wasn't helpful but exit 0 is
<hallyn_> i'll agree it's not likely - but then in theory this case shouldn't have been likely either :)
<xnox> infinity: hallyn_: "is this a convoluted 'task' " job ? =)
<hallyn_> what the heck.  infinity: your version looks nicer at 'start cgroup-lite', but still fails pkg install
<xnox> task + script -> one instance that runs and finishes.
<xnox> another job "start on shutdown" -> task + script to unmount them.
<xnox> but upstart doesn't handle shutdown / unmounting. so no need at all actually to unmount things ever.
<xnox> hallyn_: that job does not make sense on upgrade, nor on install. it should be "dh_installinit --no-restart-on-upgrade --no-start"
<hallyn_> xnox: the unmounting isn't being done for at shutdown.  it's being done in case you decide you want things mounted a dfferent way (i.e. cgroup-bin, fstab, etc)
<hallyn_> xnox: why does it not make sense on install?
<hallyn_> if you install cgroup-lite, you want the cgroup fs's installed.  'now'
<infinity> hallyn_: How is it failing at package install?
<hallyn_> infinity: http://paste.ubuntu.com/6594968/
<xnox> hallyn_: possibly. I just somehow see it as "to be installed by d-i / installer" and started "on boot". I guess you'd install it and start lxc container and everything should work without prior cgroup-lite.
<infinity> xnox: No, it's perfectly reasonable for that to start on install.
<xnox> hallyn_: but in that case, it's definately "--no-restart-on-upgrade" cause you do not want to tear down _existing_ cgroups and mount fresh ones =/
<xnox> infinity: ack.
<hallyn_> xnox: good point.
<infinity> hallyn_: That paste just leads me to believe you're not using a new version of the script. :P
<hallyn_> xnox: if i wasn't working to make cgroup-lite obsolete, i'd open a bug for that :)
<xnox> hallyn_: and in the paste you are doing upgrade, not fresh install.
<hallyn_> yes.
<hallyn_> http://paste.ubuntu.com/6594980/
<xnox> hallyn_: also with eat-my-data upstart may not get inotify for the new upstart script, and hence not notice that it should be using the new job.... fyi
<xnox> hallyn_: so you really shouldn't be testing this on overlayfs, nor under eatmydata ;-)
<hallyn_> and the actual script: http://paste.ubuntu.com/6594988/
<hallyn_> xnox: oh, good point....
<hallyn_> xnox: it's not overlayfs, it's btrfs that's making me do this :(
<xnox> hallyn_: post-strop can just be "/bin/cgroups-umount || exit 0" no? that extra if/fi does add anything does it?
<hallyn_> xnox: you rock!
<hallyn_> xnox: yeah, now that we do ||, we can drop the if.
<hallyn_> and yes, when i force upstart to reread i works.  thanks!
<hallyn_> infinity: xnox: thanks, will push new version to hopefully be done with this
<xnox>  \o/
<hallyn_> guess i really should upgrade to newer kernel and see if the fsync issue in btrfs is fixed
<arges> cjwatson: hi. I'm working on bug 785394. The default crashkernel parameter doesn't work with default ubuntu installs and needs to be increased. I created a patch here: http://people.canonical.com/~arges/lp785394/fix-lp785394.debdiff before I push, can you review?
<ubottu> bug 785394 in kexec-tools (Ubuntu) "Hard-coded crashkernel=... memory reservation in /etc/grub.d/10_linux is insufficient" [Medium,In progress] https://launchpad.net/bugs/785394
<cjwatson> arges: I don't really know much about that, can't review effectively
<cjwatson> arges: I split it out from grub2 so I'd never have to look at it again :-)
<arges> cjwatson: ok, well I just saw you having the last commit that split it out so I'd figured i'd ask you
<cjwatson> yeah, that was me washing my hands of it ;-)
<cjwatson> I never got my head around the specific semantics there
<arges> i spoke with smb, caribou etc, and we've done testing with it already
<cjwatson> (anyway, I have to run now, I'm afraid)
<arges> cjwatson:  ok thanks
<hallyn_> xnox: infinity: well now i'm really confused.  on a different host, no overlayfs or btrfs, no eatmydata.  i add-apt-repository ppa:serge-hallyn/virt which has my new package.  install cgroup-lite, it fails.  remove cgroup-lite, rm /etc/init/cgroup-lite.conf; install cgroup-lite, it succeeds.
<hallyn_> there is no /etc/init/cgroup-lite.conf before i first install cgroup-lite
 * hallyn_ confused
<hallyn_> oh.  haha.
<hallyn_> the install did not reinstall the upstart job
<hallyn_> ok i guess i just have to not do 'stop' on pre-start failure
<xnox> hallyn_: before doing clean install, do $ apt-get remove --purge cgroup-lite. such that package is removed, and the upstart job is removed.
<xnox> hallyn_: and do check that it's stopped / unmounted.
<xnox> hallyn_: $ sudo status cgroup-lite should return error unknown job.
<hallyn_> xnox: it was a brand new container.  there was no cgroup-lite installed
<xnox> ack.
<hallyn_> xnox: i've decided this is madness.  i'm going to properly sru the changes from trusty instead.
<xnox> hallyn_: still, i don't understand why this is a "long running daemon", when there is no daemon.
<xnox> hallyn_: this should be "task" job, which only mounts the filesystems.
<xnox> hallyn_: one shouldn't want to unmount them, if one does want that a separate job could be provided to unmount.
<xnox> hallyn_: the semantics of the "task" job are quite different. It starts, starting is emitted, it runs, finishes and stops. At the end "started" is emitted, or it goes to fail "stop/waiting" state.
<xnox> thus it's never reaches "start/running", which should only be needed if there is a daemon to monitor.
<xnox> hallyn_: how does the job look like in trusty?
<hallyn_> xnox: bc this way you can tell if cgroup-lite is running
<hallyn_> if it was a task, then you couldn't tell at some random time if it's running.  you'd have to check the mountpoints themselves...
<xnox> hallyn_: it only tells you that at one point in the past cgoup-lite did run. which you can also tell for a task job with "status cgroup-lite 2>/dev/null"
<hallyn_> in trusty, /bin/cgroups-mount is a bit different.
<xnox> hallyn_: one could have unmounted those filesystems, after cgroup-lite finished. and you have non-deterministic expectations.
<hallyn_> oh?  hm.  but really i'm sure i followed an example from the cookbook when i did this... years ago...
<hallyn_> sounds like a task may ahve been better, but again i'm hoping cgroup-lite is basically gone in trusty
<hallyn_> (in the archive, but obsolete)
<xnox> hallyn_: that's how things should check for other things. If I want to be sensitive to the other job, I do "status foo" to check that foo is available. And then if I require a particular state of foo, I can also check for that or wait for it to reach a particular state.
<xnox> given that "cgrou-lite" will be run-once on installation or on boot, "status cgroup-lite" with any status infromation text in stdout deterministically indicates that this did happen.
<xnox> if there is non-zero return code, or stderr output, then it's not there or otherwise failed (e.g. connection to upstart or status information denied for some reason)
<xnox> actually, yeah just zero / non-zero return code from "status cgroups-lite" is sufficient.
<hallyn_> xnox: http://upstart.ubuntu.com/cookbook/   '4.1.1.3 abstract jobs' is what i guess i was going after
<hallyn_> xnox: i disagree that a separate upstart job should exist to umount the filesystems.
<hallyn_> it's a nice clean symmetry.  start mounts, stop umounts.  why would i 'start umount-cgroups' to umount them?
<xnox> hallyn_: well, since there is no "stop on" it really is better suited to be a 4.1.1.1 Task job.
<hallyn_> note that it being a task wouldn't have solved this bug.  so i see no advantage to it being a task rather than abstract job
<hallyn_> xnox: i manually stop it very frequently
<xnox> hallyn_: you can do e.g. start cgroups UNMOUNT=TRUE
<hallyn_> stop cgroups is shorter :)
<hallyn_> xnox: what is the advantage to it being a task?
<xnox> hallyn_: the problem however, is that "$ restart cgroups" will not unmount and mount them afresh as post-stop is not executed.
<xnox> hallyn_: also "$ reload cgroups" does nothing.
<hallyn_> xnox: bah, same shortcoming with libvirtbint
<hallyn_> libvirt-bin
<hallyn_> i call that an upstart shortcoming
<xnox> (send "reload signal" to the main process group, of which there are none)
<xnox> hallyn_: i call it, you ain't got a daemon to restart nor to reload, though you shall be a task =)
<xnox> hallyn_: also "tasks" are always blocking.
<hallyn_> what does that mean?
<hallyn_> maybe post-stop in cgroup-lite should ahve been pre-stop
<xnox> hallyn_: is there any time, when you want to start on "starting cgroups" and prevent or block cgroups from mounting? if all of your clients use "start on started cgroups" that's also a strong indication that  "a task" job is better suited for you.
<xnox> hallyn_: and if for any reason pre-stop hangs, you'll never stop nor reload =/ that is actually upstart bug =) and quite tricky. because again, somebody else can block/prevent cgroups job from doing that by having "start on stopping cgroups"
<xnox> and then your manual "$ stop cgroups" from command line does _not_ unmount them.
<hallyn_> so 'start on started cgroup's, with a task, would wait until it is done, and with abstract job, does not?
<xnox> .... hm. it should with either.
<hallyn_> though since cgroup-lite does its work in pre-start, that's moot
<rbasak> Is there Debian policy that says that packages that provide daemons should start them? Or is it up to each individual maintainer?
<xnox> hallyn_: there was events sequence for task vs normal jobs. i think i should find it.
<rbasak> (I thought it was expected that daemons would be running after a package is installed, but could be controlled by policy-rc.d, but I can't find anything in policy)
<xnox> but i'm close to eod and need to run soon.
<xnox> rbasak: if and only if there is a sensible default configuration for a daemon. if for example must answer debconf question, and one is running non-interractive ui, the package settings are not configure and the daemon shouldn't be started.
<xnox> rbasak: there is a whole sections on init scripts / systems.
<xnox> hallyn_: abastract jobs are meant only as "synchronisation" points, or boot/shutdown barriers.
<rbasak> xnox: is there anything I can cite? nginx appears to not start intentionally, but I can't find anything relevant in policy.
<xnox> hallyn_: they do not convey state.
<rbasak> xnox: policy talks about invoke-rc.d, so *how* maintainer scripts should start daemons, but I can find nothing that says that they *should* start them.
<hallyn_> xnox: but they do convey state.
<hallyn_> xnox: in any case, if i were starting it fresh now i'd follow your advice...
<xnox> rbasak: hm, can't find it quickly. maybe cjwatson can provide better policy reference.
<hallyn_> xnox: but for precise i don't think i can change that :)
<hallyn_> ok let's hope my third version works
<xnox> hallyn_: there is little to know support for state, e.g. there is no reliable way to convey "run while (cgroups and networking IFACE!=lo)" and stop me if those conditions become false, and start me up again when that is true. since e.g. cgroups event fires, then networking event fires, and you are started.
<xnox> hallyn_: subsequently network goes down, you are stopped, network comes back up, networking event is fired, yet the job is still stuck in waiting state  - waiting for the new "cgroups" events which will never arrive (cgroups never went down)
<xnox> thus as soon as one tries to do any "complex", as in one "and" conditions state information is not available. events are one-time only.... events.
<hallyn_> xnox: i don't believe what you are sayin gis possible with tasks either.  that's what bugs a few years ago were opened about iirc...
<hallyn_> xnox: but with cgmanager, you'll have a real daemon to check :)
<hallyn_> if i can get past this stuff and get back to cgmanage, that is
<xnox> hallyn_: correct, it's not possible with tasks either. but look at this case: $ sudo start cgroups; sudo umount /cgroups; sudo start cgroups
<hallyn_> xnox: tha'ts ok, /cgroups is not related :)
<xnox> hallyn_: with a task it will be mounted afresh, since none are currently mounted. with abstract job, you get error "cgroups job is already running"
<hallyn_> yeah.
<xnox> hallyn_: if that's what you want, then by all means use abstract job =)
<hallyn_> xnox: and what would 'status' output look like again after it had run?
<hallyn_> xnox: i want ppl to not mess with their cgroup mouns :)
<xnox> hallyn_: for a task?
<hallyn_> xnox: yeah
<hallyn_> xnox: it sounds like you're right.  if i were to find time later to change to a task, do you think that'd be sru-able?
<xnox> hallyn_: for a task it will be in "stop/waiting"
<xnox> hallyn_: our most common bug against "networking" job is people doing "stop networking" or "restart networking" and expecting that to be equivalent to if up / if down sequence.
<xnox> hallyn_: in practice it tears down system dbus and most desktop, as stopping networking is about equivalent to switching to just before runlevel S
<xnox> (runlevel 1)
<xnox> task job, would make it immune to people "messing" with it by stop/restart, and start will do no harm.
<kees> doko: why did you remove the diversions for those things?
<hallyn_> xnox: i see.  so networking.conf should be a task you're saying?
<hallyn_> "tears down system dbus"  gives me a warm fuzzy.  but i digress
<xnox> hallyn_: =)
<smoser> xnox, are you going to fix the ssl issue in offlineimap in debian ?
<doko> kees, why do you want diversions for things which don't exist?
<Noskcaj> When is the next 19UTC DMB meeting?
<Laney> https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda January 27
<Noskcaj> Or could i apply at a different time, since i cannot attend at 15UTC
<Noskcaj> ;( That's the first day back at school, so i wouldn't be able to attend
<Noskcaj> Is there a recommended alternate way to apply? (for xubuntu packageset and MOTU)
<Noskcaj> And any chance you could give me a testimonial for either? https://wiki.ubuntu.com/Noskcaj#Testimonials
<doko> tedg, ping
<tedg> doko, Howdy
<Noskcaj> xnox, Any chance you could try and update the ubuntu/transmission bzr?
<Noskcaj> It is very outdated
<xnox> hallyn_: i think it's too late to change networking to a task job.
<xnox> Noskcaj: can you open a bug against project "udd" please?
<xnox> smoser: yeah, when i have time. badly need to update btrfs-tools & offlineimap in debian.
<xnox> smoser: NMUs are welcome =)
<xnox> smoser: or upload direct into ubuntu, i'll sync it all up.
<YokoZar> At the risk of opening a can of worms, how often are the launchpad buildd's upgraded?  Once per LTS?
<YokoZar> (been waiting on https://bugs.launchpad.net/launchpad-buildd/+bug/915505  for about 2 years now)
<ubottu> Ubuntu bug 915505 in launchpad-buildd "0.4 recipes: bzr: ERROR: exceptions.AttributeError: 'cStringIO.StringI' object has no attribute 'split' [blocked on migration of PPAs to builderstack]" [Critical,Triaged]
<xnox> YokoZar: what do you mean by "upgrade" and which builders specifically do you mean?
<YokoZar> xnox: The above bug comes from not installing a newer version of a package on the builder, so I'm talking about software upgrade.
<xnox> YokoZar: that's not distro buildds, but ppa builders which are very different (due to isolation, and untrusted code execution)
<YokoZar> ahh, that makes a little more sense
<xnox> YokoZar: and the bug says it all, "blocked on migration of PPAs to builderstack" as in openstack.
<YokoZar> Ahh, I suppose launchpad migrating significant infrastructure to openstack would be quite a project
<robert_ancell> slangasek, hey, can you reject unity-system-compositor from the NEW queue? It was supposed to go to a PPA
<robert_ancell> Or anyone else in ~ubuntu-archive, not sure who's online atm
<Noskcaj> xnox, ok. Should i be ok to copy the current source into the bzr so i can merge?
<robert_ancell> cjwatson, ^ if online
<slangasek> robert_ancell: done
<robert_ancell> slangasek, thanks!
<xnox> Noskcaj: use merges.ubuntu.com & grab-merge script which provides enverything one needs to a merge by-hand and generate a debdiff suitable for sponsorship or a .dsc/.changes suitable for upload.
<Noskcaj> ok
<robert_ancell> slangasek, hmm, bad day for typos for me, I actually meant unity-control-center. Was there a u-s-c in the queue?
<slangasek> robert_ancell: you know, I didn't actually look? ;)  Yeah, there wasn't, now I get the correct output line when rejecting u-c-c
<robert_ancell> phwew
<xnox> i have no split personality issues =) https://launchpad.net/ubuntu/+source/armel-cross-toolchain-base/1.103
#ubuntu-devel 2013-12-19
<cjwatson> YokoZar: It's actively in progress on the IS side (as in has somebody assigned to it and work is progressing), but the Launchpad team can't do a whole lot at this point beyond being responsive to any blockers we hear of.
<YokoZar> cjwatson: ahh, reasurring.  Thanks :)   I do find it somewhat amusing that the 0.4 recipe format was made years ago but has been blocked by deployment issues and never made it into the wild :D
<cjwatson> (On which note, there is one blocker I noticed last week currently staged for deployment in lp:launchpad-buildd - I should make time for QAing that before the Christmas break)
<Noskcaj> What's the best way to merge stuff from experimental?
<pitti> Good morning
<RAOF> pitti: Good morning!
<pitti> infinity: would you mind if I (or you) release the systemd-shim SRU now, to avoid doing that on a Friday before holidays?
<pitti> (it's 8 days)
<pitti> and systemd itself, too (I'm very confident in these fixes, and they got multiple verifications)
<dholbach> good morning
<RAOF> pitti: Normal marinating time would be 7 days? Is there some reason systemd-shim should wait longer?
<RAOF> pitti: Oh, also - I got pinged about uploading colord 1.0.3 to Ubuntu, and that reminded me that we hadn't uploaded it to Debian, either.
<RAOF> pitti: So I went and updated git to 1.0.5, and fixed all the autopkgtests. Would you kindly upload that to Debian sometime?
<OdyX> RAOF: I can sponsor to Debian if you want.
<RAOF> OdyX: That would be awesome, thanks.
<OdyX> RAOF: point me to a dsc and make sure you fix enough Debian bugs :-)
<RAOF> OdyX: git://anonscm.debian.org/git/collab-maint/colord.git contains the package; standard master/pristine-tar/upstream layout for git-buildpackage
<OdyX> RAOF: Nice
<OdyX> RAOF: HEAD commit from master isn't documented in debian/changelog, which commit do you want me to use as source for the package ?
<RAOF> HEAD on master. I can document it in debian/changelog if you like.
<OdyX> oh, actually, HEAD and HEAD^
<OdyX> RAOF: well, it makes the "single-debian-patch" bigger without clear non-vcs explanation...
<OdyX> (+ the dch release date is earlier to the latest changes)
<RAOF> Yeah, it's clearly confusing.  I'm writing a changelog entry now.
<OdyX> btw, that's why I prefer "commits don't change debian/changelog, git-dch generate a debian/changelog entry, make it beautiful, commit that" The changelog entry is then just an abstract from the VCS history. And that eases cherry-picks and reverts if you need to handle backports.
<RAOF> OdyX: That's what I normally do; what happened here is I did that for 1.0.3, then forgot about uploading it :)
<OdyX> he he
<RAOF> OdyX: Now with changelog entries for those bits.
<OdyX> RAOF: nice. The rest looks nice to me; I didn't check the upstream release diff. And if I where to nitpick, I'd insist on a manpage for cd-iccdump and a bump of Standards-Version + check.
<OdyX> :)
<RAOF> Hm. Why didn't lintian complain about Standards-Version?
<OdyX> RAOF: ah, http://qa.debian.org/bls/packages/c/colord.html is more interesting.
<RAOF> That page would be much more useful if it highlighted *where* it thought FORTIFY_SOURCE wasn't being passed in.
<OdyX> yeah, I'm exactly at that point in the investigation too
<OdyX> apparently some .c in the introspection
<OdyX> anyway, not important enough, I'll build and upload if nothing else arises in between :)
<RAOF> Ah, *there* it is, yes.
<ara> hello!
<GunnarHj> pitti: ping?
<GunnarHj> Hello ara ;-)
<pitti> hey GunnarHj
<pitti> RAOF: no, I don't think it should wait longer, that's why I ask
<pitti> RAOF: I just wouldn't like to release SRUs on a Friday
<GunnarHj> pitti: Hi Martin!
<pitti> RAOF: git?
<pitti> RAOF: oh, you mean colord? my pleasure
<GunnarHj> pitti: Do you possibly have any comments on https://lists.ubuntu.com/archives/ubuntu-devel/2013-December/037899.html ?
<RAOF> pitti: Too slow, OdyX is already on it :)
<pitti> RAOF: heh; sorry, was out for some errands
<RAOF> No problem :)
<pitti> RAOF: thanks for fixing the autopkgtest, that has been a long-standing wart
<GunnarHj> pitti: I talked with slangasek. He seemed to be busy, but he said:
<GunnarHj> <quote>I haven't had a chance to think about it in any detail; there are tradeoffs regardless, profile only applies to shells and /etc/environment /etc/default/locale ~/.pam_environment only apply to PAM sessions.</quote>
<GunnarHj> I'm not sure, but didn't he miss that /etc/profile and ~/.profile are sourced by the DMs?
<pitti> GunnarHj: I think system-wide should be /etc/environment, and per-user ~/.profile
<pitti> GunnarHj: /e/default/locale is indeed a very wrong place for generic env vars
<GunnarHj> pitti: Ok - why /etc/environment before /etc/profile or /etc/profile.d ?
<pitti> GunnarHj: /etc/environment is meant to be user-edited, while /etc/profile might get updated by newer package versions and has non-trivial default contents (thus easy to break it)
<pitti> GunnarHj: I don't think that "only applies to PAM sessions" is a practical limitation; users always need to get through PAM to log into a machine
<RAOF> pitti: Enjoy your systemd-shim update!
<pitti> RAOF: thanks! systemd as well?
<GunnarHj> pitti: Variable expansion seems not to work in /etc/environment, which would speak for one or more extra .sh files in /etc/profile.d/
<pitti> GunnarHj: I have no objections against /etc/profile.d/ either
<GunnarHj> pitti: Then I guess that both should be mentioned as suitable ways.
<GunnarHj> pitti: Thanks for your input!
<pitti> GunnarHj: thanks to you!
<RAOF> pitti: And done.
<pitti> \o/
<pitti> RAOF: christmas cleanup :)
<OdyX> RAOF: uploaded. I also pushed a signed tag to the repository.
<RAOF> OdyX: Thanks muchly.
<OdyX> RAOF: lintian reports hardening-no-fortify-functions usr/lib/x86_64-linux-gnu/libcolordprivate.so.1.0.22 which might need investigation.
<RAOF> I'm pretty sure that's a false-positive.
<RAOF> Indeed, I thought I had a lintian override for that, because it was a false-positive?
 * RAOF investigates.
<OdyX> RAOF: overriding the flag if you can "prove" it is a valid response
<OdyX> RAOF: there is an override in colord for libcolord_sensor_argyll
<RAOF> Yeah.
<OdyX> RAOF: btw, the libcolordprivate.so.1.0.22 name suggests it should not be in the standard path but rather under some specific colord directory no ?
<RAOF> Not particularly; it's a low-dependency bunch of stuff that got split out from libcolord to be used in other parts; anything that links with libcolord needs it.
<RAOF> It *could* be in a private path + an RPATH, but that's not a winner.
<OdyX> yeah. As long as no -dev ships headers for it it's probably okay.
<RAOF> Hey, cool. That hardening-check was a false-positive, but it looks like there *is* a bug there.
<OdyX> cool indeed
<amitk> cjwatson: slangasek: I've got a new haswell machine (samsung ativ 9 plus) which comes preloaded with Windows. I turned off "Secure mode" in the bios and changed "OS mode selection" to "CSM and UEFI OS" and was able to boot the ubuntu liveusb and install. But upon reboot, I booted back into Windows.
<amitk> even though a EFI partition exists, it seems grub-pc was installed instead of the EFI version.
<stgraber> amitk: that's most likely because you booted the install media using the BIOS and not EFI
<stgraber> amitk: d-i and ubiquity basically check how the kernel was booted. If it was booted using EFI, you get a EFI install, otherwise you get good old BIOS.
<stgraber> I suspect your firmware will first attempt to boot any native EFI entry it has before doing a fallback to their BIOS emulation, so that explains why it boots Windows for you
<amitk> stgraber: hmm, that seems likely. Changing the "OS mode selection" to UEFI OS doesn't boot the Ubuntu Livecd anymore though :-/
<stgraber> ah, then that's likely a firmware bug...
<stgraber> the ubuntu desktop and server medias boot perfectly fine from EFI with secureboot enabled
<stgraber> so you shouldn't have had to turn off secureboot or turn on csm to make it boot
<amitk> stgraber: http://dotcommie.net/?id=167 claims the debian boots fine on this machine but he disabled UEFI. I can't find anybody who has booted the liveusb with secure mode on
<stgraber> yeah... I know for a fact that our media are fine (since they work on all 3 of my uefi+sb systems without CSM and without disabling SB). But it's clearly not impossible for a manufacturer to mess up their firmware in a way that it won't do UEFI boot from CD/USB...
<stgraber> anyway, what install media were you using? cdrom or usb key?
<amitk> stgraber: usbkey
<stgraber> ok, how did you make it?
<amitk> stgraber: usb-creator-gtk
<cjwatson> try just dding it to the stick instead
<stgraber> right, that's what I was about to suggest :)
<stgraber> I suspect usb-creator and some other of those tools may try to be too clever and either forget to copy efi/ or miss the magic partition table we have on the .iso
<stgraber> (usb-creator usually segfaults for me, so all my test installs are done from USB using a dd of the iso to the stick)
<amitk> stgraber: yeah, i get it running about once every 3-4 tries
<amitk> stgraber: annoyingly, with secure mode ON, I only get the option of "Windows boot manager" in Boot options, so I'm not very hopeful, but I'll try dd anyways
<stgraber> amitk: I'd expect the menu to only show entries it detected. So if your original stick was somehow missing /EFI or wasn't considered as readable by the firmware, it wouldn't appear in the list.
<stgraber> though broken firmwares are known to exist too, so we'll see ;)
<amitk> stgraber: no luck with the dd'ed stick, it doesn't show up in the list of devices,
<amitk> the usb stick only shows up with secure mode disabled and OS mode set to CSM & UEFI
<dholbach> sarnold, jdstrand: thanks a lot for looking into upstart-app-launch/click-apparmor!
<dholbach> hey robru, do you know who needs to approve https://code.launchpad.net/~ted/upstart-app-launch/tracking-arch/+merge/196194 so it can get landed?
<xnox> dholbach: anyone in the Indicator Applet Developers team.
<dholbach> thanks xnox
<xnox> mpt: ^ =) feel like approving multiarch changes in the app launcher? =))))
<mpt> wat
<xnox> mpt: =))) merry christmas =) i'm kidding ;-) although, you can be our backdoor ;-) it's been reviewed and the changes are correct, yet somehow the developers who have rights to upload that don't have launchpad permissions to do so.
 * mpt reads the diff
<mpt> No, I am Donny. I am out of my element.
<mpt> I mean, I know what an architecture is, but thatâs about it.
<Laney> mock tudor
<mpt> Baroque
<doko> jdstrand: could you have a look at bug #1262570 ? want to have this changed for the test rebuild tomorrow
<ubottu> bug 1262570 in libjsoncpp (Ubuntu) "MIR: lcov and libjsoncpp-dev as new b-d's for llvm-toolchain-3.4" [Undecided,New] https://launchpad.net/bugs/1262570
<jdstrand> doko: ok, I'll get to it today
<doko> thanks!
<jdstrand> dholbach: np. fyi, I have a landing ask for click-apparmor, so it should be uploaded today
<dholbach> jdstrand, that's great! :-)
<dholbach> good work!
<jdstrand> thanks! :)
<plars> jdstrand: I'm having some issues with https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1257149 - it's gotten stuck at the same place twice in a row
<ubottu> Ubuntu bug 1257149 in Kernel SRU Workflow verification-testing "linux-ti-omap4: 3.5.0-237.53 -proposed tracker" [Medium,In progress]
<jdstrand> plars: the regression testsuite will take a while, but 23 hours seems too long. did it ever pass?
<jamesh> sil2100: did you have a chance to look at the mediascanner packaging review?
<plars> jdstrand: no, it never finishes - just gets stuck there
<plars> jdstrand: I can ^c out of it at that point
<jdstrand> plars: are you able to run commands on the device manually?
<plars> jdstrand: yes
<jdstrand> ok, give me a second
<jdstrand> well, more like a couple minutes
<jdstrand> plars: this is on quantal?
<plars> jdstrand: yes
<jdstrand> plars: can you give the output of the 'sudo make tests' from http://paste.ubuntu.com/6600201/?
<jdstrand> plars: that is the command that is taking a long time
<jdstrand> plars: when it seems to hang, talk to me or sbeattie
<plars> jdstrand: will do
<jdstrand> well, that is the command that I believe is hanging. we'll know soon enough if it is an earlier command :)
<plars> jdstrand: I don't find qrt-test-apparmor.tar.gz anywhere in the kernel regression tests
<plars> jdstrand: I see ubuntu-qrt-apparmor.tar.bz2 but it doesn't appear to be the same tarball
<jdstrand> plars: you generating it by running ./scripts/make-test-tarball scripts/test-apparmor.py from with QRT
<jdstrand> (the second command in the paste)
<jdstrand> s/from with/from within/
<plars> jdstrand: hmm, I found the qrt tarball here, and from panda:~/autotest/client/tests/qrt/qa-regression-testing I see a test-apparmor.py, but not a make-test-tarball
<sn33zy> can someone help me figure out how to design a script that executes after logging in from suspend?
<sn33zy> like after you type in your password and such...
<sn33zy> the how tos are confusing me...
<jdstrand> plars: the point of make-test-tarball is this: http://paste.ubuntu.com/6600303/
<jdstrand> plars: if you have test-apparmor.py, testlib.py, install-packages and apparmor/, then you are ok
<jdstrand> plars: cd to that directory instead, then go to the step at: udo ./install-packages ./test-apparmor.py
<plars> jdstrand: I have all of those except install-packages
<plars> jdstrand: this is, perhaps, a hacked up tarball for purposes of the regression tests? no idea where they got it from
<sil2100> jamesh: in the middle of looking right now!
<jdstrand> plars: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/install-packages
<jdstrand> plars: I think the duplicate make-test-tarball and install-packages.py, but I'm not sure
<jdstrand> s/think the/think they/
<plars> jdstrand: if you'd prefer, I can just bzr branch lp:qa-regression-testing and start from that, but I'm concerned that what I'm seeing in the kernel git doesn't line up with what you expect and may not be comparing the same
<jdstrand> plars: I don't think there is a need to do that. they point of my paste is to get you an unpacked source with all dependencies install so you can run make followed by sudo make tests
<jdstrand> if you have another way to get there, that's fine :) (notice the paste doesn't actually run the testsuite code at all)
<plars> jdstrand: ok, let me first just try jumping ahead to there. I would assume that at this point all the deps have been installed by previous attempts
<plars> meh, maybe not
<jdstrand> plars: look for QRT-Packages in test-apparmor.py
<plars> jdstrand: I just grabbed it from the one you pointed at
<jdstrand> that'll work too
<plars> jdstrand: the make step is failing with âPAGE_SIZEâ undeclared
<plars> http://paste.ubuntu.com/6600399/
<jdstrand> plars: ok, cool. can you update the bug? sbeattie, can you look at bug #1257149? in 'make' of apparmor regression tests: clone.c:62:19: error: âPAGE_SIZEâ undeclared (first use in this function)
<ubottu> bug 1257149 in Kernel SRU Workflow verification-testing "linux-ti-omap4: 3.5.0-237.53 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1257149
<plars> jdstrand: you think that could cause the whole thing to just hang there? rather than error out?
<jdstrand> plars: let me look at the qrt script
<jdstrand> plars: qrt is checking the return code of make
<jdstrand> rc, report = testlib.cmd(['make'])
<jdstrand> expected = 0
<jdstrand> result = 'Got exit code %d, expected %d\n' % (rc, expected)
<jdstrand> self.assertEquals(expected, rc, result + report)
<jdstrand> so maybe make isn't giving an error
<jdstrand> plars: can you adjust the script to output 'rc' at line 1435 after the assertEquals?
<jdstrand> plars: and then run 'sudo ./test-apparmor.py' and see what happens? if you want to more quickly get there, feel free to comment out the various self.addTest() calls in main()
<jdstrand> plars: (of course, you'll need ApparmorTestsuites)
<plars> jdstrand: you mean line 1435 of test-apparmor.py? That line for me is     def test_parser_testsuite(self):
<jdstrand> plars: hrm, it is out of date. hold on
<plars> there are two places in that file that would match         rc, report = testlib.cmd(['make'])
<jdstrand> plars: test_regression_testsuite()
<jdstrand> plars: after the first self.assertEquals(expected, rc, result + report)
<jdstrand> plars: output rc-- if see the output, we know that it didn't fail like it should have, which is a bug in the build process
<sil2100> jamesh: hey! You guys want it to be handled by daily-build, right?
<doko> infinity, slangasek: looks like the hotspot crash on i386 is an alignment issue. https://sourceware.org/ml/libc-alpha/2013-08/msg00372.html  There is a hack to revert that change in glibc.
<ubottu> sourceware.org bug 2013 in libc "memccpy() gives inconsistent results on mmapped files" [Normal,Resolved: fixed]
<doko> so maybe just apply this hack before the test rebuild? https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1261897
<ubottu> Ubuntu bug 1261897 in eglibc (Ubuntu) "Segmentation fault (core dump) if I launch application " [Undecided,Confirmed]
<xnox> doko: i wonder if it's the same error that is getting exposed by libarchive, it does mmapped files in the test-suite.
<xnox> (i386 only as well)
<jdstrand> doko: hotspot-- you mean the zero issue?
<doko> jdstrand, no hotspot, not zero
<doko> the not-rebuilt i386 hotspot does segfault with 2.18, java -version
<jdstrand> ok
<jdstrand> I was excited for a moment :)
<doko> jdstrand, which issue do you mean?
<jdstrand> doko: the one that is preventing openjdk-7 builds
<jdstrand> 2.4
<doko> jdstrand, ahh, that one is fixed too
<jdstrand> doko: btw, it occurred to me that we should have in trust the same version that rhel has in their upcoming release
<doko> but no arm assembler interpreter in 2.4
<jdstrand> s/in trust/in trusty/
<doko> and which version is this?
<jdstrand> that would allow both distros to share resources
<jdstrand> I'm not sure, let me see
<jdstrand> doko: but they are committed to supported openjdk-6. but they are using 1.11 and we are on 1.12. I thought, esp if openjdk-7 doesn't get demoted, that we should try to avoid that
<jdstrand> doko: cause presumably they will pick one openjdk-7 for the new rhel
<jdstrand> (and stick with it for others)
<jdstrand> actually, it would be RedHat, Debian and Ubuntu to share resources
<jdstrand> doko: looks like rhel 6 is on 2.4
<jdstrand> doko: an RHSA from october lists java-1.7.0-openjdk-1.7.0.45-2.4.3.2.el6_4
<jdstrand> doko: so yeah, getting us up to 2.4 sounds like the right thing to do. you mentioned no arm assembler interpreter in 2.4-- how big of a problem is this in reality? I thought arm perf was poor with opendk and no one used, but maybe I am misremembering
<plars> jdstrand: it didn't seem to make it to my output line, but got some other errors
<doko> jdstrand, it would be 3-4 times slower
<jdstrand> 3-4 times slower for 0 users? :P
 * jdstrand has no actual metrics
<plars> jdstrand:  http://paste.ubuntu.com/6600606/
<plars> jdstrand: I think trying to get the source earlier messed it up, let me kill that directory and try again
<jdstrand> plars: maybe-- I meant to do a 'cd /tmp' prior to the apt-get source in the paste, but since you were running it manually, I didn't mention it
<doko> <doko> jakub, it's not just blobs. did see it with my openjdk-7 build, just calling java -version
<doko> * clm (~chatzilla@pool-71-248-177-155.bstnma.fios.verizon.net) hat #gcc betreten
<doko> <jakub> doko: then openjdk violates the ABI
<doko> <jakub> monoid is right that with old gccs you could get broken code too with certain options, but I doubt that is the case here
<doko> <monoid> anyhow glibc fixed it in git for 2.19, just imo their response time was incredibly slow
<doko> infinity, ^^^didn't look what they did fix
<infinity> doko: Yeah, I'm catching up on various pastes here.  I'll have to see if I can find out what the fix was.
<doko> <doko> monoid, is this https://sourceware.org/git/?p=glibc.git;a=commit;h=584b18eb and https://sourceware.org/git/?p=glibc.git;a=commit;h=1818483b15d22016b0eae41d37ee91cc87b37510
<doko> <monoid> doko: yes
<doko> infinity, ^^^
<infinity> doko: Yeah, I just saw that in my git pull.  Deleted files tend to put up flags.
<infinity> doko: I'll grab that, and the matching amd64 commit and do a little bit of testing here and upload.
<doko> barry, for the test rebuild, I'll upload a dh_python2 which doesn't move the files to pyshared and symlinks these. will see what needs fixing in the packaging
<doko> barry, I don't have the time to check for the 3.4 as supported version
<mitya57> doko: http://codesearch.debian.net/search?q=pyshared+path%3Adebian%2F has some examples of packages relying on pyshared
<mitya57> i.e. lsb, libxml2, libxslt, python-numpy, boost1.49, speech-dispatcher, liblinear
<mitya57> on the first page
<plars> jdstrand: http://paste.ubuntu.com/6600794/ has the latest output - I guess just adding print for the rc wasn't enough to make it through, but it *did* run to completion and reported the same PAGE_SIZE bug problem in the end
<xnox> mitya57: some of them are red-herring
<jdstrand> plars: cool. can you add the failed output to the bug?
<mitya57> Yeah, I just wanted to note that there are still really buggy packages
<mitya57> (buggy wrt the /usr/share/pyshared stuff)
<plars> jdstrand: I added the pastebin link
<jdstrand> that's cool
<jdstrand> sbeattie: fyi, I added a qrt task to bug #1257149 and assigned it to you
<ubottu> bug 1257149 in Kernel SRU Workflow verification-testing "linux-ti-omap4: 3.5.0-237.53 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1257149
<jdstrand> plars: to be clear-- this test has never failed on any linux-ti-omap4 quantal kernel?
<jdstrand> plars: rather, it never passed?
<jdstrand> plars: or is this a new failure
<plars> jdstrand: as far as I can recall it used to pass, psivaa do you recall seeing issues with the qrt-apparmor test before on quantal/omap4?
<jdstrand> plars, psivaa: oh, if it used to pass, then maybe there is a regression. we should try with the last kernel
<psivaa> plars: let me look
<jdstrand> sbeattie: actually, I meant to do that against apparmor (though there is a qrt bug too with ppox)
<plars> psivaa, jdstrand: I see in http://q-jenkins:8080/view/Kernel/view/Quantal-kernelSRU/job/sru_kernel-quantal-generic-armhf_omap4_panda_ES-serial/128/console as passing
<doko> mitya57, thanks. a lot of fals positives too
<plars> that was with 3.5.0-235.51-omap4 3.5.7.23
<jdstrand> plars: does that show the apparmor version used?
<psivaa> plars: i dont recon seeing this type of failure before.. looks pretty new
 * sbeattie waves hello
<jdstrand> sbeattie: there may be nothing for you to do
<jdstrand> sbeattie: and hi!
<sbeattie> hey jdstrand
<plars> jdstrand: not that I can see
<jdstrand> plars: what revision of qrt is that?
<plars> jdstrand: no idea, whatever is currently in the kernel testsuite
<jdstrand> plars: where is the kernel testsuite?
<plars> jdstrand: the tests themselves are at git://kernel.ubuntu.com/ubuntu/autotest-client-tests.git
 * jdstrand is curious about the AF_PPPOX test. tyhicks made a change in r1978 for it
 * tyhicks looks
<plars> jdstrand: looks like in the git log it was updated on Dec 9, but it doesn't say to which version
<plars> jdstrand: the snapshot script he uses just does bzr branch lp:qa-regression-testing, so should be whatever was latest in trunk as of dec 9
<jdstrand> plars: so, apparmor in quantal hasn't been updated since april. seems like there is some sort of non-apparmor regression happening with that kernel
<jdstrand> plars: (for the PAGE_EXEC)
<sbeattie> jdstrand: qrt/scripts/apparmor/patches/clone_test-define_pagesize.patch should be fixing the PAGE_SIZE issue
<jdstrand> I'm checking git
<doko> bah, mklanghorst did overwrite my mesa upload :-/
<jdstrand> plars: when you ran the test manually, we didn't apply the patch sbeattie just mentioned ^
<doko> mlankhorst, ^^^
<mlankhorst> oh just fix it, EOW :P
<jdstrand> plars: but when you ran test-apparmor.py, it should have done it for you
<mlankhorst> doko: please learn to use xsf.git ;)
<doko> mlankhorst, please no. will do it again, and then you have to keep it once llvm-3.3 is demoted ;p
<plars> jdstrand: odd, I don't see anything under scripts/apparmor/patches
<jdstrand> plars: oh, well, their git import is not picking up our patches
<mlankhorst> sigh I'll take a look
<jdstrand> s/is not/must not/
<plars> indeed
<plars> jdstrand: checking with bjf, but I don't see anything in their snapshot script that should prevent that directory I don't think... it's grabbing the whole apparmor dir from what I can tell
<doko> mlankhorst, if you don't want to upload now, then please prepare a package for upload and point jdstrand or me to it, so we can upload once the llvm-3.4 b-d's are promoted
<mlankhorst> ok sure
<mlankhorst> doko: funnily I already considered doing it :P
<mlankhorst> doko: but please let me know that in advance, mesa packaging is closely in sync with debian, so if we change it I should change it there too.
<mlankhorst> doko: also why is llvm-3.4 dev enabled on powerpc, but debian/rules doesn't enable llvm for powerpc?
<doko> mlankhorst, in mesa?
<mlankhorst> yeah
<doko> I never did check
<mlankhorst> tsk
<doko> mlankhorst, find a powerpc machine and test it ...
<mlankhorst> (>= 1:3.3-4)
<mlankhorst> for llvm-3.4-dev? :P
<doko> not wrong
<mlankhorst> how come
<mlankhorst> anyway, re-uploaded :P
<plars> jdstrand: ok, I was running from the qrt directory rather than the ubuntu_qrt_apparmor (both of which seem to be qrt... not sure why that's all necessary)
<plars> jdstrand: but the patches dir is here for sure on this other tarball, and I'm thinking this is the one responsible for those tests so it's the right one to retry by hand
<plars> s/by-hand/ with the test-apparmor script/
<jdstrand> ok
<tyhicks> plars: I ran the latest version of test-apparmor.py on an updated quantal amd64 VM and the test_domain test passed
<tyhicks> plars: so the failure must be specific to armhf_omap4_panda
<plars> tyhicks: I'm running it right now, and will give it some more time, but it takes forever. Hard to tell if it's hung or if it's just slow because of panda
<sbeattie> tyhicks, plars: the PAGE_SIZE issue definitely an omap4 only issue
<tyhicks> plars: the test failure that I'm talking about isn't the one that hangs, though
<tyhicks> plars, sbeattie: search plars' earlier paste (http://paste.ubuntu.com/6600794/) for AF_PPPOX
<tyhicks> that's the failure that I'm looking at
<plars> sbeattie: for that, I was running from a bad location that lacked the patches dir
<plars> sbeattie: I've corrected that now
<sbeattie> tyhicks: ah, okay
<plars> jdstrand: ok, it finally finished, and test-apport passed for me when I ran it here, so I have no idea why it's erroring out there
<plars> or rather hanging
<plars> something farther along?
<jdstrand> yeah, I don't know :\
<bdmurray> hallyn_: there are 3 uploads of cgroup-lite in the precise proposed queue
<hallyn_> bdmurray: yes, please drop the first two (i explained it in the related bug :).  sorry about that.
<hallyn_> yup
<hallyn_> (that 'yup' was to another window)
<hallyn_> all right ssh is really being annoying lately, giving me 'Too many authentication failures' if i have a few ssh keys loaded
<stgraber> hallyn_: that's normal, you can only send a fixed number of keys per session, if you have more keys defined for a given session than that, only the first 3 (I believe) are sent
<stgraber> so you need to define host or domain specific config in .ssh_config so it only selects keys that should actually work for the target host
<hallyn_> stgraber: for things like amazon hosts that gets problematic
<hallyn_> and in cases where i then have to go through an ssh proxy, i get to where i don't know how to get around it
<stgraber> You can have multiple matching sections in ~/.ssh/config, so you can have something that says Host *.canonical.com => IdentityFile ...
<stgraber> and then have a section which matches those and a few others and set the ProxyCommand
<stgraber> (it just becomes hard for a human being to parse the resulting file ;))
<hallyn_> stgraber: ok, and so i'm doing 'ssh -p 5820 ubuntu@localhost'
<hallyn_> the ubuntu@localhost is a password-protected account only, no ssh key
<hallyn_> how can i say 'dont try any $(*&%($*&% ssh keys for this one' ?
<hallyn_> sure i suppose i can *give* it a ssh key.  but there's no ssh port open to it from te outside world, seems a waste...
<hallyn_> fine.  it's cheesy.  i hate it.  but i did it.
<xnox> doko: hm, i'm spotting triplet-qualified python-config binaries, is that indication that I can cross-compile python extensions, or not really yet?
<stgraber> hallyn_: I'd define a "Host localhost-5820" entry that's an alias for localhost with Port set to 5820 and setting the authentication as wanted
<stgraber> hallyn_: specifically:
<stgraber> Host localhost-5820
<stgraber>     HostName localhost
<stgraber>     Port 5820
<stgraber>     User <something if you want>
<stgraber> ...
<stgraber> then just "ssh localhost-5820" and that'll work
<hallyn_> stgraber: (1) what is the bit that says 'i want kbd auth' ?
<hallyn_> stgraber: (2) this is all very static, my env is not very static :)
<hallyn_> now maybe i should be passing -osomething...
<hallyn_> but i've added the ssh key, so for the moment i'm good.  though i still usually have >3 keys in mykeyring...
<stgraber> hallyn_: you can also do localhost-* in the config and then use %h (not sure all variables support it though)
<stgraber> hallyn_: for password auth, I think you want PubkeyAuthentication no
<stgraber> hallyn_: that way ssh won't send any of your public keys and will just fallback to whatever other mechanism you have (including password auth)
<stgraber> hallyn_: (man ssh_config for the whole list of options and variables)
<hallyn_> stgraber: so yeah i think 'ssh -opubkeyauthentication=no' might have worked for me.  i'll have to remmeber that.
<hallyn_> it just would be easier if ssh didn't balk so quickly :)
<stgraber> hallyn_: I guess it's the server cutting the connection on the client. The client would need to have a way of pooling auth methods and batching them 3 by 3 (or whatever many the server accepts), so it'd be slow (because of renegociating a connection x many times) but it'd at least work.
<stgraber> I guess people with crazy amount of keys probably also have complex .ssh/config that avoids that kind of problem so there wasn't enough people nagging them to get something like that implemented
<doko> xnox, it can. see zope.interface, python-stdlib-extensions
<mlankhorst> doko: it's dep-waiting on llvm-3.4-dev..
<mlankhorst> it - > mesa
<xnox> doko: sweet, let me do this for boost =))))
<xnox> doko: also what do you think about boost-python, shipping unversioned libboost-python.so in /usr/lib/pythonX.Y/config-X.YN-triplet/ dirs? it's kind of like c++ api to write python extensions (so not an extension by itself) and needs to be compiled per python version/config (normal, debug, etc)
<doko> mlankhorst, known. waiting for jdstrand to review my MIR report
<doko> xnox, you have to look if it does do the right thing. it relies on using the sysconfig module for the target.  if too many bits from the sys module are used for the configuration, it gets it wrong
<xnox> doko: ack.
* slangasek changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2013-12-20
<infinity> LoganCloud: When you sync -f over Ubuntu FTBFS fixes and then the package fails to build, the least you could do it bring back the patch in a merge. :P
<LoganCloud> infinity: Link paz
<LoganCloud> *Plz
<infinity> LoganCloud: openimageio ... I'm re-fixing it now, don't worry.  Just wanted to vent.
<infinity> LoganCloud: If we have a delta, it would be nice to check WHY we have a delta, and not just sync over.
<Noskcaj> doanac, Mind if i merge sqlite3? It fixes an ftbfs in python-apsw
<Noskcaj> oops. doko_^
<Logan_> infinity: Oh right. I had no way of testing on powerpc, so I synced to see if the new upstream release would fix it. I didn't get a build failed message for powerpc because I didn't do the latest changelog entry, so I forgot to go and check. Powerpc had a decent backlog at the time, so it didn't build immediately. My apologies.
<Logan_> If I could have it my way, people who copied over would get e-mail notification for failed builds as well.
<infinity> Logan_: You could have noted that my patches still applied cleanly and blindly merged.  Or, better yet, just asked me about it.
<infinity> (I thought the uploader did get FTBFS notifications for copies...)
<infinity> wgrant: ^
<Logan_> I don't like blindly merging unless I know that the delta is necessary.
<infinity> If they don't, that should be trivial to fix.
<Logan_> We definitely don't.
<infinity> Logan_: Sure, so the "ask me" bit would have worked.
<Logan_> Understood.
<Logan_> infinity: http://cl.ly/image/2f1b1g041g22
<infinity> Logan_: I'm re-testing both my patches now.  I know -latomic is needed (and will be pretty much forever, though I might convince the Debian maintainer to take my patch instead of his), the -ldl one might not be.
<Logan_> It doesn't appear that the -ldl is necessary anymore, given that it built on all architectures except for armhf and powerpc, and armhf is a carryover from last time.
<infinity> Logan_: Yeahp, looks like my build here is finishing off with just the atomic fix.
<infinity> dpkg-shlibdeps: warning: symbol dlopen used by debian/libopenimageio1.2/usr/lib/libOpenImageIO.so.1.2.3 found in none of the libraries
<infinity> No, it's still underlinked.  Just not FTBFS.  Adding back both patches. :P
<Logan_> Alright, touchÃ©. You got me. :P
<Logan_> Although I still want build notifications for packages that I copy over. That seems like a no-brainer to me.
<infinity> Yeah, I agree.
<infinity> We'll see about sorting that.
<Logan_> Can I file a bug somewhere? I remember seeing someone complaining about that recently on a ML/
<Logan_> s/\///
<infinity> Logan_: launcpad.net/launchpad/+filebug
<infinity> But spelled right.
<Logan_> infinity: Cute.
<Logan_> Oh, I'm stupid. I didn't realize you were doing that against the launchpad project.
<infinity> I wasn't trying to be funny, I just can't type to save my life. :P
<Logan_> infinity: Bug 1262952
<ubottu> bug 1262952 in Launchpad itself "E-mail notifications should go to the copier as well" [Undecided,New] https://launchpad.net/bugs/1262952
<Logan_> infinity: Also can we get powerpc PPAs? :P (Or PPAs that feed into the main buildds?)
<infinity> Logan_: No, and no, but for the first, in the next year or so, maybe (no promises).  Never the second.
<Logan_> :(
<infinity> Public PPAs require a sane virtualization story, which we may have soonish on powerpc.  And we'll never let public PPAs build on the distro builders, cause any twit with an email address can register a public PPA, they're impossible to audit.
<infinity> So, naturally, I don't want that code running on the distro buildds.  Ever.
<Logan_> Gotcha.
<xnox> Logan_: do you ever ask the last uploader?
<xnox> Logan_: it is expected for you to do so!
<Logan_> The last uploader did a no-change rebuild.
<Logan_> Oh and that was you. Awkward.
<infinity> Well, the last uploader of substance it the better person to ask. :)
<xnox> Logan_: if we had binNMUs in launchpad, there wouldn't be no-change rebuilds, so do skip over those.
<Logan_> Can we have those?
<Logan_> That would make transitions less of a pain in the ass.
<xnox> Logan_: also note that e.g. if one tried to do syncrequest, it explicetely states the reason why the delta is dropped.
<infinity> We can argue about them some more.
<Logan_> By the flagpole?
<xnox> Logan_: "i don't understand this delta" or "i don't know if it's still needed" are never the right answer to drop something, or apply.
<Logan_> I never said that. Well, I kind of said the latter. But I had no way of testing the latter. But I should've asked Adam. So I'm silly.
<infinity> xnox: I think he's been appropriately chastised by me, I don't need backup. :P
<Logan_> I feel victimized. :'(
<xnox> Logan_: i'm sorry.
<Logan_> I'm going to go contribute to Debian instead. They'll be more forgiving, right? :P
<Logan_> xnox: Haha, it was my fault. No worries.
<Logan_> Hold up, updating the firmware on my router. brb
<xnox> LoganCloud: Logan_: you do a lot of work, and it's mostly correct. It's just at times, you are tempted to jump ahead, instead of pinging people and wait a little =)))))
<Logan_> I am back and better than ever.
<Logan_> Okay so question. For the upx-ucl package, I was actually proactive and e-mailed the person who introduced a certain arm delta because I wasn't sure if it was necessary. But he never wrote back. What should I do?
<Logan_> I built the package myself in my armhf PPA, and it built successfully, but I'm not sure if it's just for optimization.
<Logan_> *the Debian package
<Logan_>     - debian/rules: [arm] needs porting to thumb2; use -marm as the code does a lot of low level hacking not yet ready for thumb2.
<Logan_> ^ that's the delta that's been carried over for a good number of revisions, and I'm not sure if it's still necessary.
<infinity> Logan_: You asked asac?
<Logan_> Correct.
<Logan_> And he never wrote back. It was sad.
<infinity> Logan_: So, note that it has "ifeq (armel,$(DEB_BUILD_ARCH))"
<Logan_> > I noticed that you made this change to the upx-ucl package in 2010. I was wondering if it is still necessary, as I did a test build with the Debian package in my ARM PPA, and it built successfully. Or is this change deeper than just making the package build? Just trying to get rid of old deltas wherever possible. :)
<infinity> Logan_: Which doesn't match any arch we build for. ;)
<Logan_> Okay well.
<Logan_> Go away. :P
<infinity> So, if the patch is still necessary, it's wrong anyway.
 * infinity looks at the original bug.
<infinity> That's the most useless bug ever.  Nice.
<infinity> Logan_: If it currently builds on armhf and no one's complaining, just drop the delta.
<Logan_> Like what is thumb2.
<Logan_> Okay.
<infinity> Logan_: thumb2 is an ARM instruction set.
<Logan_> The reason I thought it was for optimization purposes was because it built successfully on armel before asac's upload. So I don't know.
<Logan_> Okay, I will sync.
<Logan_> ...after I test build again, of course! :P
<infinity> Logan_: Of course, while you're in there, I wonder if it might be trivial to port to arm64. :P
<Logan_> It doesn't look terribly trivial. At least, we'll see with this new upstream release.
<Logan_> infinity: This is probably a dumb question, but what is the endianness of arm64 in Ubuntu?
<infinity> Logan_: little.
<infinity> Logan_: Looking at src/miniacc.h, I imagine it's just a question of following all the ifdef trees and updating for a new arch.
<infinity> If you know all the right values. :P
<Logan_> I think I'd trust you more with that.
<Logan_> Hi Noskcaj.
<Noskcaj> hey Logan_
<Noskcaj> I'll probably disconnect soon so i can play dota.
<Logan_> Sounds reasonable.
<StevenK> Ah, another dota player
<Logan_> Where should you call dh_autoreconf in a traditional debhelper rules file? Configure or build?
<Logan_> I guess it would be where I would call dh_autotools-dev_updateconfig, which varies...
<Logan_> infinity: Okay, so if I see something like "dpkg-shlibdeps: warning: debian/gtk2-engines-equinox/usr/lib/gtk-2.0/2.10.0/engines/libequinox.so contains an unresolvable reference to symbol floor: it's probably a plugin," that means it's underlined?
<Logan_> *underlinked
<Logan_> ^ Or someone else.
<infinity> Logan_: Well, in that case, it actually is a plugin, so if the thing it plugs into has that symbol, you're okay.
<infinity> Logan_: But it could just as easily be underlinked (probably wants -lm)
<Logan_> How do I determine if something is a plugin or not?
<infinity> If it's not a proper shared library in the library path, with an SONAME.
<infinity> Then it's PROBABLY being dlopened by something else as a plugin.
<Logan_> So, if it doesn't provide a package for it, I'm good?
<dobey> if i have a package that is i386-only, what's the proper way to have a dependency satisfied by any architecture (such as wget), versus requiring the i386 one?
<Logan_> Like a lib*# package.
<infinity> Doesn't have anything to do with the packaging, really.  Some packages have dozens of proper libraries in a single package.
<Logan_> arch:any I think
<infinity> dobey: That was a little too genericized for me to be sure what you want.  What's the exact thing going on here?
<Logan_> package:any actually
<dobey> infinity: my package is i386-only, and i need to depend on wget, but don't want to require wget:i386, when installed on amd64.
<dobey> no, foo:any doesn't work
<Logan_> Oh. :(
<infinity> dobey: Oh yes, then Logan_ is right.  If wget is multi-arch:allowed
<dobey> infinity: so i want the installed wget:amd64 to be able to satisfy the dep on wget
<dobey> eh i get dependency errors when trying to install, when depending on wget:any
<Logan_> infinity: I'm still confused about where to put dh_autoreconf in an old debhelper rules file, lol. The only logical place (to me) is build-stamp for the package I'm dealing with, and it complains about being run more than once.
<infinity> Yeah, because wget is m-a:foreign, not allowed.  Which is probably correct.
<infinity> Logan_: Right before you run configure.
<Logan_> Well, ./configure is in build-stamp.
<infinity> Logan_: And dh_autoreconf_clean before dh_clean.
<infinity> Logan_: Does build-stamp get run more than once due to wildcard funkiness or something?
<dobey> infinity: so i can't do it, or just having "wget" as the dep will work as i hope?
<Logan_> infinity: Apparently.
<infinity> Logan_: If so, you'll want to make build-stamp depend on an autoreconf rule and put it in there.
<Logan_> ...I have no idea. Is depending like: build: build-arch build-indep
<infinity> Logan_: Which package?
<infinity> dobey: So, this could be a minor failing of the multi-arch spec.  With a :foreign wget, I can't quite sort out how to say "any old one is good enough".
<infinity> slangasek: ^
<Logan_> infinity: leptonlib. I just did a config.{sub,guess} update with autotools-dev, but ppc64el needs the libtool fix.
<infinity> dobey: One wonders why your package is i386 only. :)
<dobey> infinity: because it's installing a proprietary thing that is only built as i386, and no 64-bit binary available
<infinity> dobey: Fair enough.
<infinity> Logan_: So, it seems to autoreconf fine here.
<Logan_> Really? Is it because I put it at the top of build-stamp instead of directly before ./configure?
 * infinity waits for the build to finish...
<infinity> Oh, lolz.
<infinity> No, it's because this debian/rules is broken.  Sec.
<infinity> Logan_: I'll see if you can spot the error before I upload. :P
<Logan_> Ooh, I like that game
<infinity> My laptop is grinding on a glibc build, so my pre-upload test-build could take a while.
<infinity> You have a few minutes.
 * infinity starts watch.
<Logan_> infinity: Is it because install depends on build?
<infinity> Logan_: Sort of, but not really.
<infinity> (It has to)
<Logan_> "touch builond-stamp"
<infinity> Time's up, my build fi...
<infinity> And you got there.
<infinity> So, there's one other minor complaint I have with the rules file, but that's the glaring bug. :)
<Logan_> What's your minor complaint?
<Logan_> Other than it not being a dh sequencer? :P
<infinity> http://paste.ubuntu.com/6603472/
<infinity> The other minor complaint is running dh_ commands before testdir completely defeats the purpose of running testdir. :)
<Logan_> infinity: Wait. Don't you not need the autotools commands if you're running autoreconf?
<infinity> Logan_: That depends on if the project is using automake.  Oh, which it is.
<infinity> So, in this case, probably don't need both.
<infinity> Logan_: Easiest way to check is to run dh_autoreconf and see if all copies of config.* got updated.
<infinity> Logan_: In this case, they do, so yes, you can and should drop dh_autotools-dev
<Logan_> Do you want me to, or do you?
<infinity> Logan_: Want me to upload this so I own it, or do you want the honors?
<infinity> Hah.
<Logan_> I'll thank you in the upload.
<infinity> Heh.
<infinity> Logan_: So, your final diff looks like http://paste.ubuntu.com/6603500/ ?
<Logan_> Yessir.
<infinity> Logan_: Shiny.  Upload away.  I can't wait for the glorious praise in your changelog.
<Logan_> infinity: https://launchpad.net/ubuntu/trusty/+source/leptonlib/1.69-4ubuntu3
<Logan_> LOL, I misspelled the typo in the changelog. Whatever.
<Logan_> I had one job...
<infinity> Logan_: Oh, the irony. :)
<Logan_> I give up. Fedora, here I come. :P
<StevenK> You'll be back.
<infinity> Logan_: On the plus side, it fixed ppc64el, so you win in the end.
<Logan_> Yay!
<Logan_> Oh, by the way, be prepared to get an onslaught of uploads from a bored Logan over winter break. :P
<pitti> Good morning
<Noskcaj> Why isn't the qa.ubuntuwire.com debcheck working?
<pitti> roaksoax: hey, how are you?
<pitti> roaksoax: any chance we can sort out bug 1254053 soon?
<ubottu> bug 1254053 in MAAS "Installing MAAS on trusty gives a big warning about deprecated postgresql 9.1" [High,Triaged] https://launchpad.net/bugs/1254053
<pitti> roaksoax: -9.1 dependencies are down to two, maas and glom
<pitti> and the removal of 9.1 is waiting in trusty-proposed
<pitti> RAOF: ah, still one failure :/ http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-colord/26/ARCH=i386,label=adt/console
<pitti> RAOF: sorry, https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-colord/26/ARCH=i386,label=adt/console
<pitti> RAOF: not very useful output though, no cookies for the automake parallel runner :/
<RAOF> No, it actually did manage some useful output
<RAOF> libcolord:ERROR:cd-self-test.c:3585:colord_icc_save_func: assertion failed (cd_icc_get_version (icc) == 4.09): (4.08 == 4.09)
<pitti> ah
<RAOF> Also, grr?
<RAOF> That test works fine in my run-adt-tests VM
<pitti> RAOF: did you run with proposed? (-P)
<pitti> maybe there's some newer ICC stuff in -proposed
<RAOF> Maybe.
<pitti> (nothing apparent, though)
 * RAOF runs with -P
<pitti> RAOF: also, does this actually test the installed colord, or the one from the build tree?
<pitti> RAOF: (I probably already asked, but I forgot)
<ara_> good morning!
<RAOF> It tests the installed colord, and the libs from the build tree.
<ara_> this grub2 precise-proposed upload has all its bugs verified: https://launchpad.net/ubuntu/+source/grub2/1.99-21ubuntu3.14
<ara_> can we get it uploaded to -updates now, please?
<jamesh> sil2100: hi.  Sorry I missed your reply yesterday: it got a bit late for me.
<dholbach> good morning
<mlankhorst> morning
<pitti> jibel: FYI, filed python-docutils failure as debian bug 732679; apparently some change (regression?) in 2to3 in python 3.3.3
<ubottu> Debian bug 732679 in python-docutils "test_nodes.ElementTests.test_empty fails for py3: "â¢" != "\\u2022"" [Normal,Open] http://bugs.debian.org/732679
<ara_> cjwatson, hey! could you upload grub2 to precise-updates, please? all the bugs are now marked as verified. thanks!
<cjwatson> ara_: we don't normally release SRUs on Fridays, and I don't know if I'll be around over the weekend in case it explodes; can it wait until Monday?
<cjwatson> (I'll be around a bit, but kind of hoping not to be pulled into a firefight)
<ara_> cjwatson, sure, it can, I will let people waiting on it know, thanks!
<ara_> :)
<cjwatson> I can probably even do it on Sunday evening or something, will see
<cjwatson> ara_: (thanks for the reminder though)
<ara_> cjwatson, I think Monday should be OK, thanks!
<doko> ev, xnox: any idea about https://launchpad.net/ubuntu/+source/whoopsie/0.2.24.2 ?
<dholbach> robru, charles, Saviq: can one of you have a look at https://code.launchpad.net/~ted/upstart-app-launch/tracking-arch/+merge/196194?
<dholbach> (you all seem to be here and have done some work or review work on it before)
<infinity> doko: The glibc strstr fix is in, BTW.  You can un-gimp java.
<ev> doko: what about it? :)
<ev> oh
<ev> I see the failed builds ow
<doko> ev: the ftbfs
<Saviq> dholbach, I'll leave it to charles, I've not enough domain knowledge
<ev> not sure offhand. I wonder if glib has broken
<ev> apols, I don't have time to dig deeper at the moment
<dholbach> Saviq, gotcha, thanks
<dholbach> Saviq, it got a positive review from the security team already, so I hope we can get this in soon :)
<Saviq> dholbach, indeed, would be pretty useful
<dholbach> yep
<darkxst> dholbach, sorry, got a bit confused with epiphany-browser-webkit2 package, never actaully made it into the archives, have dropped it from the debdiff now
<dholbach> darkxst, cool
<dholbach> darkxst, I'll take a look at it later on, if nobody of the #ubuntu-desktop guys beats me to it
<Laney> ev: it's okay, I think I know the fix
<Laney> doko: ^
<ev> Laney: star! Thank you so much
<darkxst> dholbach, thanks
<mlankhorst> doko: wrt MIR for lcov and libjsoncpp, I think for llvm-3.3 we had the same issue and just disabled lcov and the external libjsoncpp copy
<mlankhorst> doko: https://bugs.launchpad.net/ubuntu/+source/libjsoncpp/+bug/1218220
<ubottu> Ubuntu bug 1218220 in libjsoncpp (Ubuntu) "[MIR] libjsoncpp" [Undecided,Won't fix]
<xnox> infinity: what is the waitid linux/libc header mismatch issue? is there pointer to debian-bug or upstream discussion about it?
<Laney> if I comment out the g_timeout_add_seconds it just sits there indefinitely - something wrong with the monitor_directory callback
<RAOF> pitti: Bah. Can't reproduce the adt failure, even with -P
<pitti> RAOF: so, you have no idea where the unexpected 4.09 comes from?
<RAOF> No.
<RAOF> I wonder if that's i386 only?
<RAOF> ie: Is this actually a testcase bug to do with float precision?
<pitti> 4.08 and 4.09 are very far apart even in float terms -- looks more like a version number?
<pitti> RAOF: no, fails on both arches
<doko> pitti, are all the autopkg tests really running, e.g. for eglibc?
<pitti> doko: what do you mean with "really"?
<pitti> doko: for eglibc we ran maybe 40 or 50 tests
<RAOF> pitti: The relevant code is âcd_icc_set_version (icc, 4.09);ââ¦ âg_assert_cmpfloat (cd_icc_get_version (icc), ==, 4.09);â
<pitti> doko: but they fell off excuses.html (known bug, jibel is on it)
<pitti> i. e. only a display problem mostly
<pitti> RAOF: o_O
<doko> ok
<RAOF> pitti: (For reference, before the cd_icc_set_version call the version in 3.40, so it's not simply failing to set the version or failing to write the test file)
<pitti> doko: so yeah, when eglibc 2.18 landed, pretty much all the tests ran, that was a nice queue on Monday morning
<pitti> RAOF: does qemu emulate Pentium FPUs? :-)
<RAOF> :P
<mdeslaur> doko: mind if I merge gnupg?
<doko> mdeslaur, not at all
<mdeslaur> doko: thanks
<mdeslaur> Is there anyone here running trusty on a cpu with rdrand that could test an openssl package for me?
<mdeslaur> I'm not cool enough to have one of those yet
<jamespage> mdeslaur: I appear to have that feature
<stgraber> mdeslaur: I do too
<mdeslaur> jamespage, stgraber: could one of you please try this debdiff just as a sanity check to make sure openssl still works on rdrand hardware before I upload it? http://paste.ubuntu.com/6605510/
<mdeslaur> I believe the output of "openssl engine" should show rdrand without it, and should not with the patch
<jamespage> mdeslaur: trying now
<mdeslaur> jamespage: awesome, thanks
<jamespage> mdeslaur: I get rejects applying the patch
<jamespage> mdeslaur: ignore me - copy paste whitespace issue
<mdeslaur> jamespage: use the "download as text" link
<stgraber> mdeslaur: so I take it openssl doesn't know to mix sources of entropy then?
<mdeslaur> stgraber: unfortunately not
<mdeslaur> if you have rdrand, it's all that will be used
<stgraber> though I guess if it fallbacks to one of the random char device provided by the kernel, then it'll get rrand indirectly from there but mixed with some other sources
<stgraber> I have rngd running here mixing entropy from rrand, tpm and kernel generated random, that gives me a ton of entropy which is very very convenient when you're running test suites that generate a dozen of 4096bit rsa keys ;)
<mdeslaur> heh, yes, that would be sufficient :)
<pitti> so if rdrand is already put into /dev/random, it seems that openssl reading it directly might actually be counter-productive?
<stgraber> pitti: I "think" the kernel now mixes it into /dev/random but that's all fairly new and that's why on my laptop I'm using a userspace tool to seed rrand and my TPM prng into the /dev/random pool
<pitti> $ cat /proc/sys/kernel/random/entropy_avail
<pitti> 151
<stgraber> I vagueely remember some discussions on whether it was the kernel's job to integrate those other sources or if it was a userspace thing and that distros (as Fedora is currently doing) should provide rngd
<pitti> I have rdrand, but that doesn't seem to be particularly much
<stgraber> stgraber@castiana:~$ cat /proc/sys/kernel/random/entropy_avail
<stgraber> 3096
<stgraber> that's with rngd running
<pitti> hm, how would that not be a kernel thing?
<mdeslaur> I haven't looked at the code in a while, but I believe openssl only seeds it's prng with stuff from /dev/random
<stgraber> yeah, I don't know, seems a bit counterintuitive having the kernel provide userspace with a way to access that stuff just for userspace to then seed /dev/random, but well...
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<jamespage> mdeslaur: I see rdrand both with and without the patch
<mdeslaur> jamespage: ok, that may be fine. Does openssl appear to work?
<mdeslaur> jamespage: ?
<jamespage> mdeslaur: sorry - got presented with a baby part way through testing - multiarch mismatch is causing me niggles for install
<mdeslaur> oh, hehe, np
<xnox> pitti:  postgresql-server-dev-9.3 wants to get demoted to universe, is that correct?
<pitti> xnox: hm, not really; -server-dev-all ought to depend on it
<pitti> xnox: oh wait, yes; seems we don't have any packaged extension in main, so that's fine
<xnox> ah, ack.
<pitti> postgresql-server-dev-9.1 | 9.1.11-1              | trusty           | amd64, arm64, armhf, i386, powerpc, ppc64el
<pitti> I wonder what holds that in main
<xnox> xnox@sochi:~$ reverse-depends -c main postgresql-server-dev-9.1
<xnox> No reverse dependencies found
<xnox> xnox@sochi:~$ reverse-depends -b -c main postgresql-server-dev-9.1
<xnox> Reverse-Build-Depends
<xnox> =====================
<pitti> xnox: ah, bacula builds against server-dev-9.1 (how strange..)
<xnox> * bacula
<xnox> xnox@sochi:~$
<xnox> =)
<pitti> so, that needs transitioning, too
 * xnox ponders if i should change my machine naming skim from "obscure large cities in russia" to "winter olympics hosting locations"
<dholbach> can we try to get http://reqorts.qa.ubuntu.com/reports/sponsoring/ down to something closer to 0 before the break? :)
<jamespage> mdeslaur: OK - no baby now so re-trying :-)
<jamespage> mdeslaur: a brief sniff looks OK
<mdeslaur> jamespage: great, thanks!
<jamespage> sergiusens, creating golang packages was worringly easy
<sergiusens> jamespage, yeah, no complications with it at all
<dobey> is there a reasonably good way to to say in a source package that a resulting binary package should own a file, and what the hash for that file is, without the file actually being in the binary package, but installed later (ie installed how flashplugin-installer installs flash)?
<xnox> dobey: no, that would be wrong. but e.g. relevant pre/post-rm maintainer scripts should remove those files.
<dobey> :(
<xnox> dobey: it's similar to "non-conffile configuration files", just like one manually generates them (in e.g. pre/post-inst) one is responsible to clean them up (in pre/post-rm). Typically it's postinst & postrm.
 * Laney does some festive sponsoring
<Laney> ho ho hupload
<mdeslaur> lol
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dobey> weird. i just got an e-mail about trusty-adt-u1db being fixed now (i never got any e-mails about it breaking, and there haven't been any changes since the last version that was uploaded to saucy, which was copied to trusty)
<stgraber> dobey: some of those tests are re-triggered when a rdepend changes
<stgraber> and we had e-mail problems in the QA lab for a couple of weeks I believe
<stgraber> so that can account for why you didn't get the failure notification and why the tests were run when you didn't upload something
<dobey> stgraber: right. the weird thing is that i have NEVER got any failure notifications, ever. even when i know they were failing
<stgraber> odd, though I know e-mail notifications were broken for quite a while and for various reasons (missing bits from IS, network re-org, ...) so in practice I only ever got a couple of those since the beginning of the cycle (so maybe just a 10th of what I should have got ;))
<dobey> ah
<tedg> jodh, Looking at upstart-dconf-bridge and it seems like it only emits events on values changing, is that correct?
<tedg> jodh, Could it emit an event when the job is added to get the initial value?
<tedg> Hmm, but that might not work.  If a job runs, does that reset all the conditions?
<tedg> Oops, seems I broke him.
<Logan_> Hello all.
<xnox> tedg: i think the "typical" mode is that current values are emitted on the bridge start, for those events that jobs are sensitive to.
<xnox> tedg: so if you have a job which is "start on dconf...." stopping and starting the dconf-bridge should emit the dconf event and thus start your job.
<xnox> tedg: if that's not the case, it's a bug =) please file one.
<xnox> tedg: as far as i know dconf bridge is not used yet ;-)
<tedg> xnox, What happens after the job runs.  Can it run again?
<tedg> i.e. would the condition stay satisfied
<xnox> tedg: is it a task or a daemon? events are fired, and are gone.....
<xnox> tedg: there is no state information.
<tedg> task
<xnox> tedg: well, it will run again, if the event is ever emitted, which would be the case when dconf value changes, or dconf bridge starts a fresh.
<tedg> Seems state is useful for somethings like this.  Also xsession.
<xnox> tedg: i know, but we don't have states. E.g. "start on started A and started B", "stop on stopped A or stopped B" does not do what one wants: after a & b started, the job is started, b stops, and the job stops. b starts again, the job is stuck in "waiting" for "started A" event which will never arrive, since A is already running.
<xnox> tedg: so you cannot have a task which "run while dbconf", as there is no information provided for such thing.
<xnox> tedg: "Also xsession" what do you mean?
<tedg> xnox, So like "start on dbus-activation org.freedesktop.notification and xsession=foo" so then you could have multiple jobs do the dbus activation for a particular thing depending on the xsession.
<tedg> xnox, But since it's not a state, that'd only work the first time.
<tedg> Sorry "xession SESSION=foo"
<xnox> dconf keys, I thought, were for things like "onboard" if a11y key is on, start onboard on desktop login, and stop it if dconf key disabled or desktop shutsdown.
<xnox> tedg: don't do "and xsession=foo", do a prestart script checking the value of XDG_CURRENT_DESKTOP.
<xnox> tedg: cause that environment variable does convey state.
<xnox> (across all jobs, through the lifecycle of the session)
<tedg> xnox, So, it can be used for that as well.  I wanted to have a task run only if the user allowed it (i.e. could disable the task running with a dconf key)
<tedg> So I'll check the key in the pre-start, that's fine.  I was just expecting to use the dconf-bridge.
<xnox> tedg: sure "start on dconf key", "pre-start check XDG_CURRENT_DESKTOP". or reverse, start on xsession, and check for dconf key in the pre-start.
<xnox> tedg: bridges generate events only, and they are short-lived (fire once).
<xnox> tedg: e.g. when one creates a new job, during a session, it will not see "xsession event" and thus doesn't auto-start straight away, one needs to poke it manually "$ start foo" or re-emit the event it's sensitive to.
<tedg> That works.  Just not what I was expecting.
<tedg> Thanks for the explanation xnox!
<xnox> tedg: also "start foo" by-passes "start on" conditions so you can't use it as a check, and make sure the job is not-started, whilst user disabled it via dconf. =/
<xnox> no worries, i do wish upstart could provide states.
<xnox> it was proposed as  a feature, but hasn't been at all started to be implemented. It is desired to have "while ...." instead of start-on/stop-on.
<infinity> xnox: http://sourceware.org/bugzilla/show_bug.cgi?id=15544
<ubottu> sourceware.org bug 15544 in libc "move idtype_t definition into sysdeps (bits) directory" [Normal,New]
<xnox> infinity: sys/wait.h is confusing, on freebsd implementation it does not expose (include) definitions from signal.h and thus is at times useless by itself.
<infinity> Ugh, the 1SS network explosion must have hung up all those jenkins jobs...
<infinity> jibel: Can you sort out why it seems that all the autopkgtest jobs started by me glibc upload are still "running"?
<infinity> jibel: Cause that doesn't seem reasonable.
<infinity> jibel: (Also, can you restart the failed eglibc test itself, the failure is transient).
<infinity> xnox: Or, if you have the VPN magic required to retry it?
 * infinity has never bothered to get that going...
<xnox> infinity: i have vpn magic to view the private jenkins, i have no magic loginz to push the buttons
<xnox> also my fingers are in honey and it's hard to type
<infinity> Heh.
<cjwatson> I should have it - give me a moment
<cjwatson> iz running
<infinity> Tempted to just skiptest that eglibc upload, given that everything passed on the buildds, and the changes were very isolated.
<xnox> now my fingers are clean, but some of the keyboard keys are in honey.
<infinity> And I have on idea how all those autopkgtests could legitimately have been "running" for the last 12h, even with the 1SS network sadness.
<cjwatson> now you have oasfyuiosdoasufyoa problems
<infinity> s/on/no/
<cjwatson> infinity: they probably weren't, the britney integration often lies about running status
<infinity> cjwatson: Will that magically clear up?
<cjwatson> jenkins had the amd64 one down as failing, i386 passed
<cjwatson> infinity: good question, I'm glad you asked that question
<cjwatson> (quite possibly not, it's wonky)
 * xnox internal compiler error at "oasfyuiosdoasufyoa"
<infinity> cjwatson: Oh, eglibc/amd64 legitimately did fail, I was referring to all the rdep tests being "running" still.
<infinity> cjwatson: Like, a couple dozen of them.
<cjwatson> if jibel isn't around to investigate it properly then maybe just force-skiptest it once they go green in jenkins
<infinity> Maybe I just broke jibel's jenkins. :P
<jibel> infinity, cjwatson networking issue this morning broke autopkgtest in jenkins. And earlier this evening jenkins was marked for shutdown. I'll re-run the tests with an invalid status once the queue is empty.
<infinity> jibel: Kay, figured it might be something like that.  The network oops causes a lot of havoc for me too.
<xnox> infinity: a 30minute switch reboot =)
<slangasek> xnox: why was the switch not running upstart!?
<xnox> slangasek: it is a cisco router, so i think it is running upstart. It's just it was a firmware upgrade reboot as well =)
<xnox> slangasek: dunno, el mo dispatched someone onsite and by the time the person arrived, it finished rebooting.
<slangasek> do ciscos run upstart? :)
<sarnold> they run quagga, don't they? :)
<xnox> slangasek: yeah, or so jodh was told at Plumbers / LinuxCon.
<slangasek> dunno, it's been years since I touched a cisco router
<infinity> IOS runs upstart?  That's a new one on me.
<infinity> I'd need verfication of this claim before I believe it.
<Logan_> Is someone here able to add things to the Ubuntu transition tracker?
<Logan_> xnox: I think you did for me last time.
<Logan_> Please copy this one to Ubuntu: http://release.debian.org/transitions/html/suitesparse.html
<Logan_> I'll pay you back in doges or something.
<sarnold> wow. much coin!
<Logan_> I never said dogecoin. :P
<xnox> Logan_: do you really need a tracker :P =)
<xnox> ok, will add.
<Logan_> I like trackers. They're pretty.
<Logan_> And I still want cjwatson to add me to the team. :P
<xnox> Logan_: meh,... added.
<Logan_> <3
<xnox> infinity: upstart 0.5.0 reference: http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/release/note/Open_Source_used_in_IOS_Rls_1512SG_.pdf
<sarnold> nice!
<xnox> infinity: probably better to find more recent references / firmwares.
<infinity> xnox: Huh.  Crazy.  Though, yeah, that's pretty old.
<Logan_> Why is there some random guy at the top of that?
<slangasek> I've never been sure about the package suitesparse.  Is it a sparse suite?  something that parses suites?  a suit with a sparse error?
<sarnold> suite sp arse ...
<Logan_> " SuiteSparse is a single archive that contains all packages that I have authored or co-authored that are available at this site. This gives you a simple way of getting and installing all of my software packages."
<Logan_> So, basically, random shit.
<slangasek> sarnold: ITYM 'suit esp arse'
<sarnold> haha ;)
<Logan_> xnox: Liar. https://code.launchpad.net/~ubuntu-transition-trackers/+junk/transition-tracker
<xnox> Logan_: stop looking at obsolete tracker ;-)
<Logan_> Where's the new branch?
<xnox> Logan_: lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/
<xnox> Logan_: and you can do merge proposals to it ;-)
<Logan_> Oh, good, it's a proper branch now.
<xnox> Logan_: also that old one doesn't have openmpi, yet the tracker is up. should have been a clue ;-)
<Logan_> Why isn't http://people.canonical.com/~ubuntu-archive/transitions/html/dh-python2.html working correctly? I've definitely fixed some packages, but they're still marked as unknown...
<Logan_> Like, including b-d'ing on dh-python.
<xnox> Logan_: no idea, can you give me an example?
<xnox> Logan_: oh, untick "unkown" it's catching too-wide things, which later do not match neither bad nor good.
<xnox> Logan_: thus unknown it pointless on that tracker.
<Logan_> Yeah, but "good" is not getting nothing.
<Logan_> *anything
<xnox> Logan_: hm..... I see.
<xnox> yeah, it's borked.
<Logan_> https://launchpad.net/ubuntu/+source/dockmanager/0.1.0-0ubuntu2 http://launchpadlibrarian.net/157445049/dockmanager_0.1.0-0ubuntu1_0.1.0-0ubuntu2.diff.gz
<xnox> Logan_: right, updated tracker. let's wait for next regeneration.
<Logan_> Marked as "unknown," even though I converted to dh_python2 and build-depended on dh-python.
<Logan_> Okay.
<Logan_> xnox: But you got rid of the build-depends completely... they all **should** build-depend on dh-python.
<xnox> Logan_: correct.
<xnox> Logan_: one can use dh_python2 with or without the dependency.
<xnox> Logan_: and e.g. python-central has been removed in Debian, but we still have it in Ubuntu =(
<Logan_> I guess. But that rule should've stayed, I think. But working.
<Logan_> I think it's eventually going to be a policy that all packages that use dh_python2 should build-depend on dh-python.
<xnox> Logan_: well, it clearly didn't work. And the tracker used to be without it, when it was first setup.
<Logan_> Hmm, alright.
<c_korn> one question: trying to install fontforge:i386 on amd64 there is the error fontforge:i386 : Depends: fontforge-common:i386 (= 20120731.b-3ubuntu1) but it is not installable . well, but there is no i386 version of the package. fontforge-common is Architecture: all
<xnox> c_korn: an odd corner case where potentially fontforge-common needs a multiarch declaration.
<xnox> c_korn: can you first install fontforge-common by itself?
<xnox> c_korn: same way I had to mark ubuntu fonts Multi-Arch: foreign.
<c_korn> is this multiarch declaration a bug? I do not even find a mention of multiarch in the package
<xnox> c_korn: yeap. confirmed locally.
<xnox> c_korn: when dpkg resolves transient dependencies, there are cases where it does not know how to deal with arch:all package in the dependency chain.
<xnox> c_korn: without a multi-arch hint.
<c_korn> so, does this need to be fixed in dpkg or in fontforge?
<xnox> c_korn: fontforge. I'm building a test fix locally already.
<xnox> c_korn: why do you need i386 version, if amd64 exists?
<c_korn> I try to install the i386 dependencies of wine: sudo apt-get build-dep -a i386 wine1.4
<c_korn> this is where I get the error, xnox
<xnox> c_korn: _don't do it on the host_ !
<xnox> c_korn: only do it in chroot!
<c_korn> xnox: yeah, I have a schroot here.
<xnox> c_korn: i386 chroot righ?
<xnox> c_korn: mk-sbuild --arch i386 trusty
<xnox> c_korn: schroot -u root -c trusty-i386
<xnox> or whichever release you need?
<c_korn> I have a amd64 schroot here (saucy)
<xnox> c_korn: i don't think you can compile wine1.4 on amd64.
<xnox> or install it's deps.
<c_korn> hum, ok.
<xnox> c_korn: well, cross-compile / multilib compile it.
<xnox> c_korn: if you want full wine build, use i386 chroot (your host can be amd64) and build arch:all & arch:i386 packages. And then using amd64 chroot build the amd64 packages.
<slangasek> in that case, you really want fontforge itself marked Multi-Arch: foreign, so the host version of fontforge can be used
<xnox> c_korn: mk-sbuild saucy; mk-sbuild --arch i386 saucy; sbuild -d saucy --arch i386 wine*.dsc; sbuild -d saucy --arch amd64 wine*.dsc
<xnox> slangasek: possibly true, will help wine case, but I don't believe it will resolve all of the wine deps.
<slangasek> xnox: right, a cross-arch chroot is better
<xnox> slangasek: let's cross-compile fonts! how useful, given they all are arch:all ;-)
<c_korn> ok, I will build it in a i386 schroot then. thanks, xnox and slangasek !
<xnox> slangasek: well, get's us one step closer to cross-compile libreoffice package, i guess.
<Noskcaj> Can someone help me with the gnome-packagekit merge?
<Noskcaj> Do we really need to keep a bumped glib2.0 version and remove gtk-doc-utils and libapt-pkg-dev from the build-depends?
<xnox> Noskcaj: yes.
<Noskcaj> ok
<xnox> Noskcaj: have you talked to last uploader or the last sponsor about that package?
<Noskcaj> xnox, I have been told jbicha left the project and the uploader hasn't had any ubuntu work in the last two months
<xnox> Noskcaj: ok, fair enough. didn't know that.
<Noskcaj> xnox, Mind if i merge argyll? I'd nearly finished the work a few days ago then forgot
<xnox> Noskcaj: yeah, go ahed. it's all just transition fixes.
<Noskcaj> infinity, Any chance of you merging xscreensaver soon? bug 1261863
<ubottu> bug 1261863 in xscreensaver (Ubuntu) "Update xscreensaver to the latest version" [Wishlist,Triaged] https://launchpad.net/bugs/1261863
<Noskcaj> If you don't want to, i could try
<infinity> Noskcaj: Oh sure, yeah.  I hadn't noticed that the Debian maintainer woke up and uploaded new versions finally.
<Noskcaj> :)
#ubuntu-devel 2013-12-21
<Noskcaj> Are any of the debian developers here are to sponsor https://mentors.debian.net/package/testdrive ?
<xnox> infinity: apw: cjwatson: does xfs_* kernel errors in ubiquity ring a bell? http://paste.ubuntu.com/6608596/ or (badly formated) https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1261745/comments/4
<ubottu> Ubuntu bug 1261745 in ubiquity (Ubuntu) "Cannot create JFS partition" [Undecided,New]
<xnox> didn't we have similar crash signature, for something unrelated during one of the releases....
<xnox> I think I remember that. Wasn't it that "partman needs more hacks and waits between writting and reading partitions or some such"
<infinity> xnox: I thought the XFS stuff was a red herring the last time we looked into it, and it was just the usual fallout of trying to guess filesystems while probing/mounting.
<xnox> infinity: yeap.
<slangasek> xnox: xfs_* kernel errors just mean "it tried to mount something as xfs that wasn't, and the xfs driver politely objected"
<xnox> politely objected..... with vomit.
<infinity> xnox: Not that the filesystem driver isn't obviously buggy here for vomiting an oops, but it doesn't seem to actually harm anything.
<sarnold> interesting though, there is a xfs_sb_quiet_read_verify() right next to xfs_sb_read_verify() that is supposed to be useful for probing filesystems..
<xnox> slangasek: i guess there is only so many systems that have yaffs, zfs and xfs modules =)
<ice9> I'm getting my first steps on ubuntu dev through the harvest bugs, but i'm running 13.10 and there are bugs for 11.04 am I still able to fix them on my system?
<sarnold> ice9: 11.04 has been out of support for a year; if the bug still exists in 12.04 or 13.10 or trusty, it'd be worth fixing, but if 11.04 was the last release to have the bug, you might as well move on to the next bug. see https://wiki.ubuntu.com/Releases for EOL dates
<Noskcaj> Are their instructions for applying for motu via email? I won't be able to attend a meeting till later february
<Noskcaj> *irc meeting
<ice9> anybody have some time to make give me kind of mentoring on getting a simple bug to fix?
<Noskcaj> ice9, Sure
<ice9> thanks Noskcaj
<Noskcaj> What package is this on?
<ice9> actually I'm still looking for something to work on, i'm checking http://harvest.ubuntu.com/opportunities/ is it the right place?
<Noskcaj> on of them
<ice9> where else?
<ice9> actually all the bugs i found there are very old
<ice9> i don't know where else to find simple bugs
<Noskcaj> ice9, bugs.launchpad.net/ubuntu has all ours
<Noskcaj> http://www.debian.org/Bugs/ also has a few, and any package's upstream bagtracker
<Noskcaj> What programming languages do you know?
<ice9> C, Java, Python, PHP, JavaScript
<Noskcaj> you beat me on every level then
<ice9> not a must
<Noskcaj> Are there any areas or packages you want to try and work on?
<ice9> i'm open to anything but i need something simple to start with
<Noskcaj> maybe try bugs with the tag "bitesize"
<Noskcaj> they area normally easier
<Noskcaj> Or any bug listed as a papercut https://bugs.launchpad.net/hundredpapercuts/+bugs
<ice9> Noskcaj, oh man i see bugs from 2006 :D
<Noskcaj> ice9, that happens. Try the "number" button, that will order by newest
<ice9> Noskcaj, alright, i found something https://bugs.launchpad.net/hundredpapercuts/+bug/1248373
<ubottu> Ubuntu bug 1248373 in gedit (Ubuntu) "gedit "Save as..." is disabled when file is opened read-only" [Low,New]
<sarnold> ice9: not a great candidate since it appears difficult to replicate; can you get it to happen?
<Noskcaj> ice9, first step is check if you can confirm it locally
<Noskcaj> lol, dat timing
<sarnold> hehe yeah :)
<ice9> sarnold, yes just set any text file to read-only and open it with gedit you will see save as disabled
<sarnold> ice9: sweet. I wonder why seb 128 and jeremy-list had trouble reproducing.
<ice9> it's importance status is 'undecided', who can change it?
<Noskcaj> A bug triager
<Noskcaj> It's not a requirement to fix the bug
<ice9> so how can i help?
<Noskcaj> fix it
<Noskcaj> i mean "you don't need a priority to fix the bug"
<Noskcaj> You're trying to fix it in gedit anyway, papercuts is just a tracker of easy bugs
<ice9> ok i'm going to fix it, so from where should i start now?
<sergio-br2> hello
<sergio-br2> i'm doing some tests in trusty, and i saw that apport is disable in /etc/apport/crashdb.conf. It was not to be enabled?
<Noskcaj> ice9, Use bzr branch lp:ubuntu/gedit to get the source
<ice9> ok
<sergio-br2> Noskcaj, did you know?
<Noskcaj> sergio-br2, no, sorry
<Noskcaj> Did you use the alpha's installer?
<Noskcaj> or a daily?
<sergio-br2> no, i'm see an update system
<sergio-br2> i used daily, 1 or 2 days ago, in a VM
<Noskcaj> If you installed via a release iso, you'll have apport disabled
<sergio-br2> yes, in release ok, but in daily iso?
<Noskcaj> not ok
<ice9> Noskcaj, is there a difference between these branches?  lp:~ubuntu-desktop/gedit/ubuntu  and  lp:ubuntu/gedit
<Noskcaj> ice9, no
<ice9> i'm fetching the code on slow connection
<Noskcaj> correction, yes. Use the ~ubuntu-desktop one
<Noskcaj> It is actually up to date
<ice9> and i have to set the ubuntu release too?
<Noskcaj> To fix the bug, all you need to do is make a patch. You can use bzr or apt-get source PACKAGE to get the source-code
<Noskcaj> rbasak, Mind if i merge gnome-system-tools?
<ice9> d/c
<ice9> lp:~ubuntu-desktop/gedit/ubuntu doesn't has the source code, its just checked out conf files
<ice9_> Noskcaj, that repo doesn't has the code
<ice9_> and its very old
<ice9_> however it's the one here also apt-cache showsrc gedit
<Noskcaj> ok. Maybe just run apt-get source gedit
<Noskcaj> it's the most reliable way. (if you're on trusty)
<ice9_> i'm on Saucy
<Noskcaj> run "dget https://launchpad.net/ubuntu/+archive/primary/+files/gedit_3.10.2-0ubuntu1.dsc"
<Noskcaj> That will get you everything you need
<ice9_> Noskcaj, alright, got it with apt-get source
<Noskcaj> If it's not 3.10 that apt-get source downloaded, send the patch to me before you submit it so i can update it
<ice9_> Noskcaj, its 3.8.3
<ice9_> same as reported in the bug
<ice9_> ok
<ice9_> so now i can compile normally with make and make the fix?
<Noskcaj> ice9_, yep.
<Noskcaj> Apply all of ubuntu's existing patches first though.
<Noskcaj> use "quilt push -a"
<ice9_> it depends on many other packages that aren't installed yet
<ice9_> ah
<sarnold> ice9_: if you just want to fix this, you could install the "build-deps" for this package using apt-get build-deps gedit
<ice9_> sarnold, and apt-get source gedit  -t <release> ?
<sarnold> ice9_: if you intend to do this more in the future, it is nice to not rely upon the packages in your system -- they could be too old, too new, or different, or whatever -- and it is wonderful to have a whole build environment set up to help make reproducable builds.
<sarnold> ice9_: check this out... https://wiki.ubuntu.com/SimpleSbuild
<Noskcaj> Maybe not yet though
<sarnold> yeah
<sarnold> it's a process
<Noskcaj> sarnold, Isn't pbuilder-dist easier though?
<sarnold> :)
<ice9_> build-dep is great :D
<sarnold> Noskcaj: dunno. I want something that matches the buildds as closely as possible.
<Noskcaj> Makes sense. I've never lost anything because of pbuilder-dist, and it does make it that little bit easier
<ice9_> very strange, now i can't reproduce that bug again
<sergio-br2> Noskcaj, are you sure that that behavior is the expected?
<sergio-br2> it's a little weird... Rhythmbox does not do it
<Bluefoxicy> heh
<Bluefoxicy> I'm surprised nobody has figured out to chattr +T /home /var/log on install
<Bluefoxicy> except now with btrfs it's irrelevant
<Bluefoxicy> (and /var/log as a TLD is questionable)
<lifeless> Bluefoxicy: what does +T do?
<lifeless> oh, I see
<lifeless> Bluefoxicy: why would you do that to /var/log?
<sergio-br2> Noskcaj, that bug annoys me since saucy :P
<Noskcaj> sergio-br2, Which one?
<sergio-br2> Noskcaj, gmusicbrowser crazy jump
<Noskcaj> understandable
<Noskcaj> Do you think i'm right with why it happens?
<sergio-br2> dunno
<Bluefoxicy> lifeless:  it's questionable for /var/log
<Bluefoxicy> lifeless:  the argument there is that multiple processes have subdirectories and are writing logs independently.
<sergio-br2> Noskcaj, i think it is ramdom
<Bluefoxicy> basically, when Apache tries to write in /var/log/httpd, it shouldn't seak all over the place because allocations are interleaved with allocations from /var/log/squid or /var/log/proftpd
<Bluefoxicy> the argument for /home is that a user's activity is going to look in /home/$USER, so will be mainly grouped together on disk
<sergio-br2> Noskcaj, all the musics begin with uppercase
<Noskcaj> sergio-br2, look at the second letter though
<Bluefoxicy> the argument for /var/log is similar, except the system is doing all that stuff in any case so the benefit would be questionable.
<Bluefoxicy> btrfs doesn't support marking a directory as TLD though
<Noskcaj> Ba, Gu, AC
<sergio-br2> Noskcaj, second letter, i tried it now: e - o - h - i
<lifeless> Bluefoxicy: if so you'd want the logs close on disk right? Avoid seeks.
<Noskcaj> It puts the entire lower case section ahead of the upper case ones if i'm right
<sergio-br2> hum, let me see
<lifeless> Bluefoxicy: if the other processes are all writing at once, you want the total range of teh disk that seeks occur over to be minimised
<Noskcaj> or maybe upper case first
<Bluefoxicy> lifeless:  yeah, that's why i said it's questionable
<lifeless> Bluefoxicy: +T would maximimise it
<lifeless> Bluefoxicy: ack
<Bluefoxicy> the concept is that the subdirectories of a given directory are unrelated
<Noskcaj> The only method i'm sure of is that it's artist that is the first part
<Bluefoxicy> lifeless:  I actually use +T for the parent directory of all HTTP document roots for a web server housing hundreds of web sites
<Bluefoxicy> I did that because performance was utterly slow because it's gfs2 and has 3 nodes accessing it.  It was taking 1 second per file to run rsync on any given directory, because every allocation would exchange locks on a resource group shared between a dozen sites.
<Bluefoxicy> didn't help directories already populated of course
<Bluefoxicy> lifeless:  file system tuning is an esoteric topic :)
<sergio-br2> AC, Of, AC, Of, AC here
<Noskcaj> strange.
<Noskcaj> But does the artists list still go the expected way?
<Noskcaj> Try caning to the list view to make it easier to see what's what
<Noskcaj> *changing
<Noskcaj> Is it ok to have both a .inti and a .upstart file in a package? (both provided by debian)
<Noskcaj> We used to replace the init with the upstart, but now debian have both
<sergio-br2> Noskcaj, Guns (Album: Use Your Illusion I, music: Double Talkin' Jive), ACDC (Album: Blow Up Your Video, music: That's The Way...), Guns N' Roses (Album: G N' R Lies, music: One In A Million), Oficina G3 (Album: Ao vivo, music: Pirou), Oficina G3 (Album: IndiferenÃ§a, music: GlÃ³ria Instrumental)
<Noskcaj> I'm out of ideas
<apw> xnox, that is just xfs being very loud about trying and failing to mount he partition as xfs.  fat, isofs, squashfs, ext2, have all whined about it just before, just they limit themselves to one line
<apw> xnox, oh if i had read on ...
<infinity> apw: We all know that's just XFS being stupidly noisy.  It scares the crap out of users, though (and confuses someone in an installer report as a red herring at least once a month).
<infinity> apw: I don't suppose there's any way we can shut XFS up a bit on that score, to be the same 1-liner as ext* prints?
<infinity> Well, not the same, but similar.  ext's are also stupid, since it loads from bottom to top, and yells at you about missing "features" that mean nothing to normal people.
<infinity> apw: Will that go away if/when we disable ext2 and ext3 and let the ext4 driver handle all three?
<infinity> apw: Or will it still give the three lines of "feature not found" vomit?
<apw> infinity, we should just take that "ooops like dump" out, it carries near no information for a failed mount
<apw> infinity, ext234 maybe, the trusty kernel has it though already so it depends what he is testing
<infinity> apw: Yeahp, agreed.  Or bump the printk prority on it to debug.
<infinity> apw: If the trusty kernel already has ext4 handling all three filesystems, then my complaint isn't fixed. ;)
<infinity> EXT3-fs (sda): error: couldn't mount because of unsupported optional features (240)
<infinity> EXT2-fs (sda): error: couldn't mount because of unsupported optional features (240)
<infinity> EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null)
<infinity> apw: But that noise is nothing compared to XFS, so meh.
<apw> an odd order as well
<ice9> how to build a source package for debugging?
<xnox> Laney: added ppc64el to the transition tracker, not sure if anything needs doing to enable that arch.
<ice9> what is the dev channel for gnome projects?
<maxiaojun> ice9: upstream GNOME channels are on GIMPNet I guess
<maxiaojun> how to request package removal in ubuntu?
<infinity> maxiaojun: File a bug on the package and subscribe ubuntu-archive to the bug.
<infinity> maxiaojun: Which package, and why?
<maxiaojun> actually 2
<maxiaojun> one is pptview, i've asked the debian maintainer and maintainer agreed to remove in debian (as i checked, already removed in sid)
<infinity> maxiaojun: Ahh, removed from Debian is enough reason for me, pptview gone.
<maxiaojun> another is ack, it is a japanese encoding conversion program last updated in 1994, it should be pretty useless today according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662114
<ubottu> Debian bug 662114 in ack "ack: non-ative upstream and there is nkf" [Normal,Open]
<maxiaojun> a much more popular program need the name "ack" (currently named ack-grep) http://beyondgrep.com/
<Laney> xnox: added it to the runner, should appear at next run
<pc-world> 13.10. I did apt-get source unity and then "dpkg-buildpackage -j8 -nc", fails near the end in check-headless with "Xlib:  extension "GLX" missing on display ":16192"." Ideas? http://pastebin.com/TtqGJw7Y
<infinity> pc-world: I suspect the segfault is the important part of that log, not the missing GLX. :P
<pc-world> infinity: I figured the segfault was a result of the GLX error, though I don't know why it would want GLX to build Unity, and my graphics driver should support GLX
<infinity> pc-world: It's not building, it's runinng a testsuite.
<pc-world> infinity: well, can I disable tests but still be able to use dpkg-buildpackage?
<infinity> If unity respects DEB_BUILD_OPTIONS="nocheck", sure.
<infinity> (It should)
<alkisg> Guys we have the following things caring about the keyboard layout: keyboard-configuration, xorg (those 2 play fine so far, and then the breaking starts), accountsservice, lightdm, gnome, ibus...
<alkisg> It's been 3 years now that we can't type Greek by default because all those programs just don't know how to handle multiple keyboard layouts, and they don't let xorg do its job. So an xterm session works fine, but all other sessions (unity, gnome-flashback, gnome...) don't...
<alkisg> Here's one of the many bugs filed against lightdm, accountsservice etc: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1016409
<ubottu> Ubuntu bug 1016409 in lightdm (Ubuntu) "Default XKBLAYOUT is not used, so new users only have "en" layout" [Undecided,New]
<yoritomo> hello all
<alkisg> And now in 14.04 ibus made even manual configuration not working...
<pc-world> infinity: with -nc, it didn't help, will try without
<alkisg> I had to purge ibus, reset-recursively my gsettings, fall back to recovery console, delete the accountsservice settings, put my .dmrc back to where it was, and enable autologin in lightdm to be able to type [us,gr]
<yoritomo> i would like to know why in Qt-creator UTF8 after setting in not set in my project i still can't display any french accentued characters on my program
<alkisg> And after all that, the keyboard indicator applet isn't working in 14.04 like it did in 12.04...  it assumes I'll be using win+space from ibus instead of alt+shift defined in xorg
<yoritomo> i am under 12.04 i forgot to mention it
<Phantomas> alkisg: I can confirm what you are saying, I'm having these issues too with the input language. And I can't see any reason why these bugs still exist after 2-3 years, especially when input language changing was working almost fine with older ubuntu editions.
<pc-world> infinity: nope, DEB_BUILD_OPTIONS="nocheck" doesn't help, even without -nc.
<alkisg> The problems started when lightdm was introduced :(
<Phantomas> Maybe there is no bilingual developer in Ubuntu? Since English works we are good to go. :P
<yoritomo> in some tutorials i could find for QT creator it looks fine for french characters maybe a typic linux problem
<pvl1> hello everyone! is there a difference between glib and gtk? im very confused
#ubuntu-devel 2013-12-22
<ice9> i just built the rhythmbox and gedit sources using make but after the build, i can't find the binary exec file to start the application
<pvl1> make install
<pvl1> ice9
<ice9> pvl1, no i don't want to install it on my system, just want to make a fix and test it
<pvl1> is there a bin dir
<pvl1> in the project directory
<ice9> no
<Noskcaj> Can someone please rebuild dx? It should allow it to pass the libtiff5 transition
<Noskcaj> And feel++ needs a rebuild to pick up openmpi1.6
<Noskcaj> Actually just about everything at http://people.canonical.com/~ubuntu-archive/transitions/html/openmpi1.6.html needs a rebuild
<xnox> Laney: thanks.
<Noskcaj> to rebuild a package should i just submit a branch with a build1 changelog?
<xnox> Noskcaj: "everything" is a vague definition, given it's 78% complete, and many things are not accounted for (e.g. fixed packages in proposed)
<xnox> Noskcaj: rebuilding feel++ is jumping the ship, since gmsh is not yet fixed across all architectures.
<xnox> Laney: not sure about the tracker. E.g. openmpi1.6 didn't get an ppc64el column =/
<Noskcaj> xnox, ok. So i do just submit a branch with a build1 revision for the relevant packages?
<xnox> ?
<xnox> Noskcaj: which package?
<xnox> Noskcaj: LoganCloud uploaded all those that didn't FTBFS, the rest seemed to need fixes.
<Noskcaj> ok
<xnox> Noskcaj: and has the packages deps migrated to openmpi1.6 already?
<Noskcaj> idk
<xnox> Noskcaj: across all arches... it's easy to get into arch skew =/
<xnox> Noskcaj: no change rebuilds is such a low level task, that sponsoring those is, well, a lot of overhead. people with upload rights motu/core-dev usually do those.
<Noskcaj> ok, makes sense
<xnox> Noskcaj: patches to fix FTBFS for packages in-current transitions is always nice to know =)
<xnox> Noskcaj: so again which "the relevant package" that can just be no-change rebuild that you have identified?
<Noskcaj> I was going to manually try them, was just checking the process first
<xnox> Noskcaj: locally? why a branch merge proposal?
<LoganCloud> Did I do something wrong
<LoganCloud> I was mentioned in this channel. Not a good sign
<Noskcaj> that one i just changed libtiff4-dev to libtiff-dev. Was there something other than building i needed to check?
<xnox> Noskcaj: one checks current depends in -proposed/-archive, does a local no-change rebuild to check that new library name is picked up, and if all checks out good prepares no-change upload.
<Noskcaj> LoganCloud, you're fine
<Noskcaj> ok
<xnox> LoganCloud: nah, all good =) just pointing out the good work you did on pushing openmpi transition.
<xnox> Noskcaj: as far as I can tell tiff transition is complete, and it has been requested to remove tiff from the archive.
<xnox> Noskcaj: unless it's creeping back in?
<xnox> Noskcaj: so again, can you tell me which _src_ package you are looking at?
<Noskcaj> xnox, Should be done, just a package that still needed libtiff4
<LoganCloud> Phew
<Noskcaj> And none
<xnox> Noskcaj: not the transition name, e.g. tiff4. but the reverse dep in question...
<xnox> Noskcaj: i'm confused. =(
<Noskcaj> I have no idea what you're talking about
 * Noskcaj thinks he needs to find something else to do with his holidays
<xnox> Noskcaj: "<Noskcaj> [01:11:51] Can someone please rebuild dx? It should allow it to pass the lib" & "<Noskcaj> And feel++ needs a rebuild to pick up openmpi1.6" & "<Noskcaj> to rebuild a package should i just submit a branch with a build1 changelog?"
<xnox> Noskcaj: I got the impression, that you want to help with transitions and believe you have something ready to be uploaded.
<xnox> Noskcaj: yet, I still don't know which packages you want to be rebuild.
<Noskcaj> 1 and 2: basic guesses, probably wrong. 3. Moure general info
<Noskcaj> I want to help, don't really know what to do
<xnox> Noskcaj: looking at dx -> whilst it build-depends on libtiff-dev, it doesn't actually result in binary depends on tiff.
<xnox> Noskcaj: in the transition tracker feel++ is at the very top of the stack, and typically things feel++ depends on should transition before feel++ itself will.
<xnox> Noskcaj: otherwise one may end up in an unfortunate situation of trying to load both ABIs into a single binary =/ which is not good.
<Noskcaj> ok, so that's what the dependancy level thing means
<xnox> Noskcaj: yeah, roll the mouse over the package name to see it.
<Noskcaj> oh
<xnox> Not very discovarable, unless one reads the source code of the page ;-)
<LoganCloud> xnox: thanks :) it was my first real transition
<LoganCloud> The fact that Debian did it already helped, for sure :P
<xnox> LoganCloud: there are plenty of FTBFS to fix... left =)
<xnox> still though.
<xnox> yeah, but it's now different, cause they did it at different timing.
<LoganCloud> Yes but they're also FTBFSing in Debian
<xnox> LoganCloud: did they remove them from testing?
<LoganCloud> At least most of the ones with issues
<LoganCloud> I think so
<xnox> lazy =)
<LoganCloud> Because the ones with problems say "Sid only" I think
<LoganCloud> I'm not by my computer right now. On my phone
<xnox> fixed openmx, cctools and others now.
<LoganCloud> Cool, I'll take a look in like 10 min
<Noskcaj> speaking of that, do you guys have any tips for finding what is causing an ftbfs? It's very rare for me to find one i know how to fix
<xnox> Noskcaj: read the build-log, that's the only....
<Noskcaj> As in working out how to fix what the buildlog says
<xnox> one solves a sudoku by solving it.....
<xnox> read what it says, and depening on what it says, try to understand why, and resolve the root cause behind it.....
<xnox> it's not any different from any other puzzles =)
<LoganCloud> Noskcaj: knowing basic stuff about coding and stack traces helps
<LoganCloud> Also spotting patterns, and taking note of fixes to common problems
<Noskcaj> LoganCloud, There's my issue. I only know basic python, and all the python ftbfses are from test errors, or architectures i don't have.
<xnox> Noskcaj: learn C, it's easy.
<Noskcaj> sigh. I really should
<xnox> http://www.cprogramming.com/
<xnox> Laney: looks like my last config change did break the trackers. Revert that commit.
<xnox> Laney: can you take a look at how to enable the new arch?
<Logan_> xnox: Tsk tsk. You modified hdf5 right after I fixed the default mpi for ppc64el and arm64. :P
<xnox> Logan_: really?
<xnox> Logan_: where?
<Logan_> mpi-defaults
<Logan_> I reverse-traced the logic it was using to pick up the default MPI and found it was coming from the depends for that package
<Logan_> so I added arm64 and ppc64el as arches for openmpi in that package's build-depends
<xnox> Logan_: right. and ppc64el is finished now.
<xnox> Logan_: do we need to rebuild everything on top on mpi-defaults on arm64 & ppc64el ?
<xnox> Logan_: i'll revert hdf5
<xnox> Logan_: actually hdf5 needs a no-change rebuild once, mpi-defaults passes.
<xnox> Logan_: and it's still wrong for hdf5 to pick a non-existant package as a depends.
<xnox> Logan_: will you submit mpi-defaults patch to debian?
<Logan_> xnox: yes
<xnox> cool, thx
<Logan_> xnox: Ugh. This hdf5 thing is a mess.
<Logan_> xnox: just sent you an e-mail
<alkisg> Laney: could you please have a look at https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/474392/comments/11 ?
<ubottu> Ubuntu bug 474392 in indicator-session (Ubuntu) "indicator-session menus are not policykit aware" [Low,Confirmed]
<alkisg>  /dev/sdb1 on /media/alkisg/usb-stick type vfat (rw,nosuid,nodev,uid=1010,gid=1010,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2)
<alkisg> ...that means that when I copy a file from that stick to my home folder, other users don't have read access to it
<alkisg> That was not the case in the past... shouldn't dmask provide read access to others by default, or at least some other way could be found so that I don't need to manually update the rights of the files I copy from usb sticks?
<alkisg> Hmm completely hardcoded... :( http://cgit.freedesktop.org/udisks/tree/src/udiskslinuxfilesystem.c?id=aa02e5fc53efdeaf66047d2ad437ed543178965b
<alkisg> For example, if they were mounted under /run/user/uid/mounts, they wouldn't need strict permissions because /run/user/uid would block other users
<Laney> xnox: what happened?
<Laney> alkisg: I could maybe take a look after the holidays
<Laney> If you're able, a patch would be welcome
<alkisg> Laney: I could try a patch for https://bugs.launchpad.net/indicator-session/+bug/1263438, but not for https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/474392/comments/11, that's a bit beyond my current knowledge of the libraries involved :-/
<ubottu> Ubuntu bug 1263438 in indicator-session (Ubuntu) "Indicator-session assumes there's only one active user" [Undecided,New]
<ubottu> Ubuntu bug 474392 in indicator-session (Ubuntu) "indicator-session menus are not policykit aware" [Low,Confirmed]
<alkisg> (12:10:15 Î¼Î¼) alkisg: Thanks, I wish you happy holidays! (to Laney... pidgin was too lazy in notifying me that I was disconnected :))
<doko> $ cat test.c
<doko> int main(){return(0);}
<doko> $ gcc -fPIE -pie -static test.c
<doko> *** Error in `/usr/bin/ld': corrupted double-linked list: 0x0a329260 ***
<doko> <and ld hangs ...>
<doko> infinity, ^^^ seen with glibc-2.18, not 2.17
<doko> kees, is the use of hardening-includes in graphicsmagick correct? the above example calls with -pie -static
<doko> gold correctly complains about it:
<doko> $ gcc -fuse-ld=gold -fPIE -pie -static test.c
<doko> /usr/bin/ld.gold: fatal error: -pie and -static are incompatible
<doko> collect2: error: ld returned 1 exit status
<xnox> LoganCloud: yeah, don't worry about it =) easily to sort out.
<xnox> Laney: so all trackers stopped to update after I've commited ;"ppc64el" in the global config + some trackers that list arches explicitely (ghc?) see commit + revert in the config/ branch.
<xnox> Laney: try updating config branch to -r-2 and rerun tracker so check where it blows up?
<cjwatson> xnox: Based on the previous syntax my guess would be that ";" is only supposed to separate items in a list, rather than terminating items
<cjwatson> xnox: That is, you need to not have the semicolons after ppc64el
<cjwatson> (global.conf and monitor/permanent/ghc.ben)
<ice9> does ubuntu plan to continue using GTK or will move to Qt at sometime?
<Noskcaj> ice9, Unity is moving to Qt5 with unity 8
<ice9> Noskcaj, so no more GTK? when unity 8 is coming?
<mdeslaur> ice9: gtk will still be there
<ice9> but why Unity to move to Qt instead of GTK?
<Noskcaj> ice9, We'l still use gtk, but unity 8 (which should be out for 14.10), should be Qt
<mdeslaur> ice9: unity isn't using gtk at the moment, it's using a toolkit called nux
<mdeslaur> ice9: it's moving from nux to qt
<xnox> cjwatson: ta.
#ubuntu-devel 2014-12-15
<pitti> Good morning
<pitti> bdmurray: I am now; I was on a sprint last week. Today and tomorrow I'm only here half-day, though
<highvoltage> pitteah
<dholbach> good morning
<smb> mdeslaur, thanks
<LocutusOfBorg1> dholbach, can you please sponsor the patch in #1292118 ?
<LocutusOfBorg1> more than 238 bugs for this problem
<LocutusOfBorg1> :(
<dholbach> LocutusOfBorg1, hum, I don't have a precise box/vm for testing, but I can upload a test build to a ppa and let people test that first?
<LocutusOfBorg1> I can do that
<LocutusOfBorg1> I'm the maintainer ;)
<LocutusOfBorg1> however I'm pretty sure the fix works, it is a plain cherry-pick from upstream, and the same usual stuff as always when a new kernel is released
<dholbach> minor nit-pick it should be "precise-proposed" as opposed to "precise" in the changelog entry
<cjwatson> dholbach: no, "precise" (etc.) has been auto-translated to "precise-proposed" (etc.) since the end of 2013 or so
<cjwatson> it's acceptable to use that
<dholbach> ok
<cjwatson> sorry, I mean the end of 2012 or so
<cjwatson> that's what I get for trying to do release â date conversion in my head
<dholbach> I knew it did that for the development release, I wasn't quite sure about stable releases :)
<infinity> We did it for all for consistency and prettiness.
<dholbach> right, makes sense
<infinity> I haven't had -proposed in a .changes since that day.
<cjwatson> To be honest, I think it was initially an oversight but one that turned out to be the right thing to do.
<cjwatson> Or maybe it was just fewer lines of code. :-)
<infinity> cjwatson: I vaguely recall arguing specifically for the behaviour, but maybe that was after we discovered it already did that.  Old man brain, can't say for sure.
<cjwatson> Yeah, I know we discussed it, can't be bothered to go back and look up when :-)
<sil2100> mitya57: hey! I'm not following KDE development too much, where can I get some information about KDE's own QPA platform theme?
<xnox> ScottK: what do you think about gnupg 2.1 as the gnupg2 package in Vivid?
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
<xnox> it seems safe enough across the board, however kubuntu does use it as the default implementation.
<Riddell> sil2100: frameworkintegration: /usr/lib/x86_64-linux-gnu/qt5/plugins/platformthemes/KDEPlatformTheme.so ?
<sil2100> Riddell: not sure if that's what mitya57 had in mind, since this one has been around since like forever
<mlankhorst> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100, mlankhorst
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mlankhorst
 * sil2100 goes to lunch
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100, mlankhorst
<cyphermox> good morning!
<Riddell> hi cyphermox
<mitya57> sil2100: what Riddell pointed to
<sil2100> Morning!
<mitya57> Morning!
<sil2100> mitya57: ok, then I'll have to check the source then
<mitya57> It was not in KDE4, it's new in KDE5 (I think)
<sil2100> Anyway, I'll try to review your branch today as well - if all goes fine we can try landing all those approved changes this week
<mitya57> Thanks!
<sil2100> Ah, indeed! I mischecked then, it got introduced around utopic
<sil2100> That would explain why I didn't see it when creating appmenu-qt5 - not sure how much it was actually used in KDE around that time though
<mitya57> sil2100: the KDE code for AppMenuPlatform{Menu,MenuItem,SystemTrayIcon} is in
<mitya57> https://projects.kde.org/projects/frameworks/frameworkintegration/repository/revisions/master/changes/src/platformtheme/kdeplatformsystemtrayicon.cpp
<mitya57> I meant "for QPlatform{Menu,MenuItem,SystemTrayIcon}"
<ScottK> xnox: No opinion.
<xnox> ScottK: you mentioned you don't run ubuntu servers, anymore. Is it no longer your responsibility or switched to another distro?
<TheNumb> xnox: haven't you heard? Arch GNU/Linux is the new Ubuntu.
<TheNumb> ;-)
<mlankhorst> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<gQuigs> So libnss-ldap seems dead upstream..  been waiting on versions 266 for 5 years..   I'm curious if I should push to remove it from main (for vivid+), or try to fix bugs one at a time (they say they've been committed upstream but I can't find a public SVN/CVS/etc)..
<gQuigs> example bug: http://bugzilla.padl.com/show_bug.cgi?id=414
<ubottu> bugzilla.padl.com bug 414 in NSS "sigpipe handling in atfork() doesn't always work if sigpipe is blocked" [Normal,Resolved: fixed]
<teward> is the DMB still meeting today per the agenda...?
<Laney> dmb?
<Laney> ha
<Laney> !dmb-ping
<ubottu> bdrung, ScottK, Laney, micahg, xnox, bdmurray, stgraber: DMB ping
<xnox> Laney: lucky that i'm not at lunch.
<bdrung_work> Laney, wrong channel?
<Laney> bdrung_work: partially
<Laney> xnox: lucky? you know when the meeting is!
<hallyn> xnox: hey, pushed a new (trivial) netcf merge to mentors.debian.net.  something went wonky actually with the 0.2.4 experimental package (which you had taken part in) and it never showed up in debian... do you mind sponsoring the 0.2.6 version?
<hallyn> i'm pretty sure symbols are wrong, i'll look at thta in a bit
<xnox> hallyn: ack.
<hallyn> xnox: but ok, i don't understand the last line in the symbols file you had created:  *@NETCF_PRIVATE_0.2.4 0 1 .  what do the '0 1' mean?
 * hallyn tries an automated way to update
<hallyn> based on http://pkg-kde.alioth.debian.org/symbolfiles.html
<hallyn> fail
<dobey> gQuigs: have you tried contacting PADL about how to check out the nss_ldap code from CVS? (based on what's in the tarball it seems they do use CVS)
<gQuigs> dobey: nope, would we want to just pull a new (let's say vivid package) one straight from CVS?
<dobey> gQuigs: well you were saying you couldn't find a repository. you could ask for a new tarball too, as it seems the latest is 265 and the bug talks about 266.
<gQuigs> dobey: true, can't hurt to try pinging them..
<gQuigs> thanks :)
<dobey> gQuigs: indeed, my point was "try asking upstream" :)
<hallyn> xnox: I also don't understand why you put the "| libnetcf1 (>> 1:0.2.4), libnetcf1 (<< 1:0.2.5)" in there.  why the << 1:0.2.5?
<xnox> hallyn: sorry was out, let me look.
<xnox> hallyn: so by default all public symbols get 1:0.2.2 as the minimal version
<xnox> hallyn: that is all that are versioned @NETCF_1.*
<xnox> hallyn: however, symbols that are marked @NETCF_PRIVATE_0.2.4 generate alternative depedency which is far more strict
<xnox> libnetcf1 (>> 1:0.2.4), libnetcf1 (<< 1:0.2.5)
<xnox> hallyn: thus if one uses public symbols only -> one gets a very lax libnecf1 (>> 1:0.2.2) dependency
<xnox> hallyn: if one sues any of the private symbols, one will get a strict " libnetcf1 (>> 1:0.2.4), libnetcf1 (<< 1:0.2.5)" thus forcing libraries to recompile on every new major upstream release
<xnox> (this implies that debian/ubuntu patches do not change abi of any public or private symbols
<xnox> )
<xnox> this is similar to libc, where you get lax dependency if one uses old symbols, but a very strict one if any of private symbols are used.
<xnox> hallyn: so all you need to do is s/0.2.5/0.2.6/ and s/0.2.4/0.2.5/
<xnox> hallyn: and good to go.
 * xnox off to lucnh
<hallyn> xnox: gotcha, thanks.  (I think - I understand what to do, but will look a bit more to see if i can avoid asking you stupid questions enxt time :)
<xnox> hallyn: any more questions can be directed to infinity
<hallyn> thanks, i'l lhave an update when you get back
<xnox> hallyn: the syntax of the .symbols file is aweful, i give you that.
<xnox> hallyn: especially the | for alternative "template" which has different structure to the "main" one and the cryptic "0 1" to switch to a different template which suddently is no longer #MINVER# variable....
<Laney> .
<hallyn> heh
<hallyn> xnox: (update posted)
#ubuntu-devel 2014-12-16
<ScottK> xnox: Everything relevant has moved to Debian.
<pitti> Good morning
<pitti> wow, it's quiet here -- must be christmas soon :)
<dholbach> good morning
<Laney> bah humbug!
<tkamppeter> pitti, hi
<pitti> hey tkamppeter, wie gehts?
<xnox> ScottK: right, i guess Debian LTS helped with such a move (even if not used)
<pitti> Laney: in case you track the test overrides, the udisks2 regression is bug 1398859; it's still rather ominous, but I'll keep looking at it
<ubottu> bug 1398859 in systemd (Ubuntu) "[udev regression] unmounting NTFS causes mount.ntfs process to get stuck in eternal kernel deep sleep" [High,Triaged] https://launchpad.net/bugs/1398859
<Laney> ah yes, I remembered about that the other day, thanks for the heads up
<pitti> Laney: same udev works on Debian and Fedora, so it's not that after all
<Mirv> a core dev would be needed to ack the multi-arch related packaging changes in Compiz https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141210.2-0ubuntu1.diff
<TheNumb> patch tuesday ;-)
<TheNumb> http://seclists.org/oss-sec/2014/q4/1052
<Riddell> "Discuss with Desktop team and MartinPitt whether or not to re-enable apport by default for A1 "
<Riddell> pitti: what do you think?
<Riddell> â
<tkamppeter> pitti, seems that AppArmor rules of CUPS need an extension, see bug 1402350.
<ubottu> bug 1402350 in cups (Ubuntu) "Powering on the printer does not activate the related usb port" [Low,Incomplete] https://launchpad.net/bugs/1402350
<tkamppeter> pitti, seems that a filter is accessing systemd stuff. I do not really know for what of systemd CUPS needs access permission.
<Riddell> "Notify Michael Vogt to perform a GnomeAppInstallDesktopDatabaseUpdate" â mvo
<ScottK> xnox: It wasn't really a factor.  Personally, I think it's still an experiment.
<pitti> Riddell: hm, I don't have a strong opinion; at some point we want to move to errors.u.c., but I suppose we aren't there yet
<pitti> Riddell: my gut feeling is that we should enable it after the christmas holidays, though
<pitti> Riddell: enabling it now with very few people actually looking at incoming bugs might just be a waste?
<Riddell> pitti: okay dokay
<Riddell> pitti: doesn't errors.u.c needs apport to report to it?
<pitti> Riddell: yes, but apport itself is running; we only disable crash submission to Launchpad
<pitti> tkamppeter: ah, that's the journal (i. e. log messages); apparently that driver supports it
<Riddell> pitti: so how does apport report to errors.u.c ?
<pitti> tkamppeter: I think you should reassign this to apparmor -- IMHO writing the journal socket should be allowed in teh same place that allows writing to /dev/log, i. e. in /etc/apparmor.d/abstractions/base
<pitti> Riddell: it's "whoopsie" which does that -- it looks for new /var/crash/*.crash, and uploads them
<pitti> tkamppeter: I'll update the bug
<Riddell> pitti: sneaky, it doesn't tell the user?
<pitti> tkamppeter: but updated
<pitti> tkamppeter: "bug"
<pitti> Riddell: it does the normal way -- it's just that clicking "send" won't invoke a browser, it just creates a /var/crash/foo.upload stamp which then triggers whoopsie to upload it to errors.u.c.
<Riddell> pitti: so is there any reason for apport to report to launchpad?
<pitti> Riddell: some, yes; on LP you have a channel to the reporter, thus you can ask to try some extra things, attach program output, try a fix, etc.
<Riddell> pitti: ah yes.  thanks for explaining
<pitti> Riddell: there's some plan to allow a subset of those on errors.u.c. as well, but it never got implemented
<pitti> Riddell: so my personal gut feeling is to enable LP bugs for alpha-2, at least after the EOY holidays
<tkamppeter> pitti, jjohansen, thank you very much.
<Riddell> pitti: sounds like a plan
* Riddell changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | alpha 1 freeze in place
<Riddell> alpha 1 freeze in place for kubuntu, ubuntu gnome, ubuntu kylin
<Laney> Riddell: You need to put it in 'freeze', not 'block'
<Riddell> Laney: in hints-ubuntu? why?
<Odd_Bloke> I've been looking at building cloud images using Launchpad buildds, and think I'm going to have a small patch to live-build; how are changes to live-build managed?
<Laney> Riddell: because there's a list of allowed files and block is not one of them
<Riddell> Laney: ok, fixed
<Laney> cool
<Riddell> Odd_Bloke: probably cjwatson is your man there
<cjwatson> Odd_Bloke: nothing fancy, just bugs.  I'm not your man for this any more though, get slangasek to find another victim or ask on #ubuntu-release
<Odd_Bloke> cjwatson: Understood, will do.
<Odd_Bloke> It isn't urgent, as we're building from our own PPA for livecd-rootfs anyway.
<caribou> is there specific packages from which we get the binary that we put in our initramfs ?
<caribou> I'm looking for the sources for ipconfig
<caribou> initramfs-tools ?
<cjwatson> caribou: ipconfig comes from klibc-utils
<cjwatson> caribou: dpkg -S bin/ipconfig
<caribou> cjwatson: thanks; for some reason I couldn't find it with -S
<mgedmin> cjwatson, I'm assuming you're no longer taking care of gfxboot-theme-ubuntu?  can you suggest a successor?
<mgedmin> https://bugs.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/+bug/1384188 is something trivial I'd like to see fixed in vivid
<ubottu> Launchpad bug 1384188 in gfxboot-theme-ubuntu (Ubuntu) "Missing translations for 'Install Ubuntu GNOME' and 'Try Ubuntu GNOME without installing'" [Undecided,New]
<cjwatson> mgedmin: I've passed you on to cyphermox, at least in this instance
<cyphermox> mgedmin: it's pretty much the same result but there is po/bin/add_text that can be used to add translatable strings; it also updates the po files at the same time. I'll be done shortly, just finishing with a translation update while we're at it
<mgedmin> welp, there was a README in po/ and I didn't notice!
<mgedmin> I assume the translations will be done through launchpad as usual?
<cyphermox> mgedmin: yes, I did an export to update the package, that's all
<cyphermox> mgedmin: https://launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/0.18.0
<hallyn> Feh - when did this start up again?  this is like maverick era bug:
<hallyn> WARNING: gnome-keyring:: couldn't connect to: /run/user/1000/keyring-0JIGtA/pkcs11: Connection refused
#ubuntu-devel 2014-12-17
<kees> hallyn: say ... do you know a way other than "find / -type f -print0 | xargs -0 getcap" to find files with filesystem capabilities? it seems like "find" needs to grow -fscap like it has -perm or something
<jrwren> getcap has -r for recursive search
<sarnold> kees: ^^^
<slangasek> chrisccoulson: do you happen to have heard of any problems with firefox 34 leaking fds (unix sockets)?
<hallyn> kees: i think libcap-ng has a tool for that
<hallyn> filecap /bin
<pitti> Good morning
<Unit193> Howdy.
<sarnold> hehe, say good night to one german friend and a few minutes later, good morning to another :)
<pitti> tyhicks, jdstrand_: is bug 1402350 something you'd want to fix upstream (would make sense), or want me to just fix the apparmor.d snippet in ubuntu?
<ubottu> bug 1402350 in apparmor (Ubuntu) "allow writing to systemd journal sockets" [Undecided,Triaged] https://launchpad.net/bugs/1402350
<dholbach> good morning
<chrisccoulson> slangasek, I'm not aware of any such problems
<chrisccoulson> that sounds like a question for the desktop team :)
<Logan_> xnox: hey, are you aware that Ubuntu Code Search has been down for a while?
<darkxst> Logan_, that was Laney 's? and it wasnt working properly for a long time before it went down
<Laney> I didn't have the time to maintain it properly as was
<Laney> anyone else could try to set up such a thing
<darkxst> right now debian codesearch is sufficient for me, with them being well ahead of us
<doko> Riddell, ScottK: the marble autopkg test fails, could you have a look? blocks isl and GCC, abi-compliance-checker failing
<xnox> Logan_: i only provided the dns service for it, if the ip behind it does not have codesearch or anything else all i can do is publish the dns record....
<Riddell> doko: no reply from upstream about it, I think I'll just override it
<Riddell> pitti: are you the dude to ask about jenkins failues? I'm wondering what to do about https://jenkins.qa.ubuntu.com/job/vivid-adt-gwenview/lastBuild/ARCH=i386,label=adt/console
<pitti> Riddell: I am, yes; let me look
<pitti> Riddell: ah, retried
<pitti> Riddell: ... "~ppa2"?
<pitti> Riddell: btw, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html has quite a lot of held back updates due to real regressions (kate, kservice)
<pitti> and marble
<pitti> kde-runtime too
<Riddell> ~ppa uploads were obviously a mistake, I'll fix that for gwenview
<Riddell> yeah talking to upstreams about those regressions, nobody seems very interested so far
<Riddell> pitti: kservice needs retried too? https://jenkins.qa.ubuntu.com/job/vivid-adt-kservice/lastBuild/ARCH=i386,label=adt/console
<pitti> Riddell: ah, temporary xvfb uninstallability, indeed; retried
<Riddell> pitti: and kate is another timeout? https://jenkins.qa.ubuntu.com/job/vivid-adt-kate/lastBuild/ARCH=amd64,label=adt/console
<pitti> yeah, but of the test itself
<pitti> debian/tests/testsuite.xsession: 4: debian/tests/testsuite.xsession: kdeinit4: not found
<pitti> maybe because of that?
<pitti> and maybe that script can become set -e to catch that earlier
<Riddell> it's a bad test, kdeinit4 is part of kde4libs but this is ported to kf5 so it wouldn't be installed
<pitti> Riddell: gwenview/kservice fixed again
<jamespage> stgraber, hello - any opinion on https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1402763 ?
<ubottu> Launchpad bug 1402763 in lxc (Ubuntu) "Multicast traffic not propating correctly over linux bridge" [Undecided,Confirmed]
<jamespage> stgraber, I'm certainly stretching LXC containers a bit,  but multicast is proving a little unreliable right now
<Riddell> pitti: kde-runtime is a timeout issue on build server? https://jenkins.qa.ubuntu.com/job/vivid-adt-kde-runtime/lastBuild/ARCH=amd64,label=adt/console
<pitti> Riddell: indeed, retrying
<pitti> Riddell: sorry about those, due to the datacenter move we lost email notifications, so I didn't retry those right away
<pitti> they are back now, though
<pitti> (and meh for our test machines squeaking under the load -- high time to move to the cloud!)
<didrocks> pitti: at least, you have your machines back, not me yet :/
<Riddell> didrocks: what have you lost?
<Riddell> didrocks: did you check behind the sofa? if you lose something it's nearly always there
<didrocks> Riddell: hehe, I tried to check, but my desktop vm in the DC weren't there :)
<sil2100> didrocks: hey ho! Sorry to bother you, but we need a core-dev to +1 a packaging change for address-book-app - do you have a moment? ;)
<sil2100> It's a small change and our usual person is on holidays
<didrocks> sil2100: sure, fire the link :)
<sil2100> https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-000-2-publish/lastSuccessfulBuild/artifact/packaging_changes_address-book-app_0.2+15.04.20141216.6~rtm-0ubuntu1.diff <- BAM!
<didrocks> sil2100: +1 :)
<sil2100> Thanks :)
<jamespage> doko, around?  this bug was bought to me attention this week:
<jamespage> https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1081022
<ubottu> Launchpad bug 1081022 in python2.7 (Ubuntu Precise) "logging.SysLogHandler doesn't close UNIX socket when connection failed" [High,New]
<jamespage> Are you happy for me to prep the SRU?
<cjwatson> pitti: Would it be worth promoting python3-apport's Suggests: python3-launchpadlib to Depends, now that it exists?
<pitti> cjwatson: ooh!
<pitti> cjwatson: nice one, then I can finally drop the hacks which tell you to install the py2 packages, and just use that
<cjwatson> I'm assuming without proof that it passes the test suite and such ...
<cjwatson> pitti: thank xnox :-)
<pitti> xnox: *hug*
<xnox> =))))
<xnox> cjwatson: pitti: i wanted to announce it wider when i port "ubuntu-dev-tools" and "lptools" however ubuntu-dev-tools has non-trivial test-suite with mox (not ported to python3) so it took some time to port it to plain mock first.
<pitti> that's bug 1153671, I update it now
<ubottu> bug 1153671 in apport (Ubuntu) "Need python3-launchpadlib" [Undecided,Triaged] https://launchpad.net/bugs/1153671
<xnox> and lptools is probably imposible to port without essentially re-writting it.
<xnox> because it imports bzrlib to handle command-line args, help messages and the like......... for no reason.
<pitti> xnox: bug 1060734 is another one -- should that be closed now, or is the port still missing some bits?
<ubottu> bug 1060734 in launchpadlib "Support for Python 3" [Low,Confirmed] https://launchpad.net/bugs/1060734
<pitti> xnox: erk yeah, argparse should certainly do fine?
<pitti> cjwatson: thanks for pointing out; bug updated, assigned to me, I'll work on it in January
<xnox> pitti: yeah... also launchpadlib is now fully proxy aware, so you could do autopkgtests against e.g. dogfood.
<cjwatson> xnox: also the modules from ubuntu-dev-tools are used by other unpackaged scripts like ubuntu-archive-tools; I was wondering if it would be worth packaging both 2 and 3 versions of those
<cjwatson> or maybe just copying the bits we use in u-a-t and dropping the dependency ...
<xnox> cjwatson: so u-d-t ship a module, i was planning to package it as python-ubuntutools & python3-ubuntutools with ubuntu-dev-tools depending on them as needed.
<xnox> and then port scripts to python3 as time goes by.
<pitti> xnox: apport's launchpadlib backend does have a test suite, but it almost never works (at least not a year ago or so); maybe staging is better these days, worth a try
<xnox> cause i think ubuntu-dev-tools also has scripts that operate against both launchpadlib & bzrlib
<xnox> pitti: there is also "mocklaunchpad" that one can authenticate against and run things.....
 * xnox .... actually i think it's called fakelaunchpad.
 * xnox wants to port ubuntu-dev-tools first and then announce
<xnox> as that way it would be easier to port all the other things.
<pitti> hm, I can't log into staging, my SSO google auth creds aren't working there
<cjwatson> xnox: yeah, that would make sense
<didrocks> pitti: it's another SSO server IIRC
<TheNumb> pitti: I believe you need to use your launchpad account ;-)
<cjwatson> No, staging has separate SSO
<pitti> didrocks: ah yes, I could add my gauth
<TheNumb> really?
<TheNumb> interesting
<pitti> so I now have a separate 2FA account
<cjwatson> Well, I mean it's still the same account but a separate SSO instance
<cjwatson> And for those who use 2FA (which pitti does) you definitely have to set that up separately
<cjwatson> Because otherwise things go terribly wrong on staging restores and such
<pitti> wow, 20/21 successes; given that I didn't touch it in 1.5 years, that's not bad
<pitti> xnox: ok, I now have a fully working test suite for apport's launchpadlib backend for py2; running it for py3 revealed bug 1403524
<ubottu> bug 1403524 in python-launchpadlib (Ubuntu) "[py3] getSourcePackage() crashes with ValueError: Expecting value: line 1 column 1 (char 0)" [Undecided,New] https://launchpad.net/bugs/1403524
<pitti> i. e. I don't get very far
<rbasak> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | alpha 1 freeze in place | Patch Pilots: rbasak
 * rbasak has too big a chunk of work to start before he finishes for Christmas in a few hours. Might as well do something useful in the meantime.
<mark06> how does ubuntu handle static gpl/lgpl libraries?
<mark06> for example say package foo is statically linked with gpl packages bar and baz
<mark06> is the exact source code used from bar and baz included in source package foo? at least which packages (bar and baz) and versions?
<rbasak> tkamppeter: around? I'm looking at bug 1348384.
<ubottu> bug 1348384 in libspectre (Ubuntu) "evince and okular do not render eps files correctly resulting in a black background" [High,Fix committed] https://launchpad.net/bugs/1348384
<rbasak> mark06: generally we avoid static linking. But maybe the Built-Using header is what you want? Prior to that we also have build logs that will tell us which versions of build dependencies were used.
<mark06> rbasak: are these logs part of the package? Built-Using is good, will check for it
<rbasak> mark06: no, the logs aren't part of the package. Launchpad does publish all build logs publicly though.
<mark06> reasonable
 * rbasak appreciates guests who arrive wanting to exercise their Free Software freedoms :-)
 * mark06 can't find Built-Using in https://launchpad.net/ubuntu/vivid/amd64/libxml2/2.9.1+dfsg1-4ubuntu1
<xnox> mark06: build-using is optional and indicates what sources of which packages were used to build this thing.
<bdmurray> pitti: I've updated my merge proposal
<xnox> mark06: generally things like compiler / bootstrappy things declare it when they build-depend on e.g. glibc-source
<infinity> And generally only makes sense if there's a strong (ie: static linking) relationships between the binary and the thing it was built with.
<infinity> mark06: libxml2 isn't statically linked, so it wouldn't make sense to record Built-Using.
<xnox> but it's optional, and all it does is keep the src tarball in the archive (in debian at least) it practice, we have snapshots of all releases going back to the first release thus even if something is statically linked we should have sources somewhere.
<mark06> infinity: isn't libxml2 staically linked with xz?
<mark06> xnox: since it's optional, one may forget to use it when linking stuff statically?
<infinity> mark06: No.
<infinity> mark06: It may include a local copy of xzlib, but it doesn't statically link to the external one.
<mark06> xnox: the upstream build code could even do that without packager even noticing
<xnox> mark06: no, ldd clearly says it isn't....
<infinity> xnox: Uhm, what? :)
<infinity> xnox: ldd wouldn't show a static link. :P
<mark06> xnox: no for which statement? it what?
<xnox> infinity: but it shows a shared one, thus it is shared linking with liblzma.so.5 ;-)
<mark06> I'm not talking about shared
<xnox> mark06: why are you talking about static linking, and/or accusing things of using static linking and how do you come to such conclusion?
<mark06> xnox: since it's optional, how one will never forget to use it when linking stuff statically?
<infinity> mark06: So, yes, it's true that a build system could statically link without someone noticing.  This is actually pretty hard to determine after the fact.
<mark06> xnox: accusing? omg
<xnox> and debian/ubuntu maintainers usually try hard to link statically as much as possible, however e.g. firefox/libreoffice do link certain things statically.
<mark06> infinity: yeah, how about before the fact?
<infinity> xnox: s/as much/as little/
<mark06> infinity: when you are in control of build ok, you need to remember to use build-using
<rbasak> In general, a package that statically links by accident is buggy. Except for special cases.
<rbasak> To track down these bugs, we have build logs.
<rbasak> Is that not sufficient?
<mark06> infinity: but you may forget or you don't have time to read entire upstream code to tell whether upstream part of build will do something bad (static)
<infinity> mark06: People make mistakes occasionally, yes.  We don't have any sentient tools to prevent that.
<rbasak> mark06: is your primary concern here licence compliance, or some future technical difficulty, or something else?
<mark06> rbasak: not accidentally, just not noticed (because you won't inspect entire source code to know)
<infinity> mark06: Not noticed and accidentally are ultimately the same thing.
<mark06> infinity: thanks for explaining
<rbasak> mark06: note that there are generally two parties here. Upstream, and the packager. The packager is responsible for policy and license compliance in the distribution. So upstreams intention might be the packager's mistake.
<mark06> infinity: how about upstream code? it is nearly impossible to know/detect if it contains static linking code
<infinity> mark06: No it's not impossible.  It's a package maintainer's job to know their package.
<mark06> rbasak: gpl compliance, this issue has been raised in msys2 and we wonder what linux distros do
<infinity> It's usually a pretty good hint when you need libfoo-dev to build a package but you don't end up depending on libfoo.  Should set off some warning bells.
<rbasak> mark06: our policy is not to have static linking. That's what we do :)
<infinity> It's also not rocket science to grep a build log.
<mark06> infinity: so it's implied that static linking is supposed to be avoided as much as possible? is licensing the only reason for this?
<infinity> mark06: Licensing is a small part, security auditing is the much larger reason.
<infinity> mark06: As well as memory footprint, etc.
<infinity> mark06: Imagine the pain if every C application statically linked libc.a, as the extreme case.
<rbasak> We don't want to rebuild the world if a security update to some library is required that packages compile statically against.
<infinity> We'd rebuild the entire distro for every security update.
<infinity> You'd also have a much more bloated runtime footprint.
<mark06> So upstreams intention might be the packager's mistake -- not sure if I get you, but upstream could include source for static stuff in tarball, so they might be correct... but you build it again and don't notice you should do that too... is this what you mean?
<rbasak> I mean that upstreams may decide to statically link, and a packager may not realise it's happening and thus violate policy and maybe licensing.
<mark06> It's a package maintainer's job to know their package. -- even so, how to read entire source code to be sure? or what general steps do most of the job?
<rbasak> But that's still a mistake from the distribution's part, and should be fixed.
<rbasak> And in that case, I think build logs on Launchpad are fine.
<infinity> mark06: If you're including the source in your tarball, that's not the sort of static tracking we were talking about previously, as you've introduced no external source dependencies.  That said, it's still usually a mistake for a packaged version to use your bundled sources.
<mark06> infinity: about libfoo-dev, you can also have it installed for another reason and not notice it's a dependency
<infinity> mark06: I can't tell you how individual maintainers get to know their upstream sources, as I can't speak for thousands of people.
<rbasak> mark06: essentially: yes, package maintainers can inadvertently violate licensing. They can do this in a whole host of ways. When we (the distro community) discover there's a problem, generally we fix it.
<rbasak> mark06: I don't see why this particular case is special, or that there's any need to mitigate this by doing something different technically, when the root cause of this hypothetical violation will be fixed when it is brought to the maintainer's attention.
<mark06> infinity: by including the static stuff in tarball I mean for license compliance (like include a tarball within another) not that the static code has been merged into the code base
<infinity> mark06: If you're violating licenses with your upstream tarball, we repack it and remove the offending bits.
<mark06> mistake for a packaged version to use your bundled sources -- don't get this, then what bundle will package use if not upstream's?
<mark06> rbasak: and you have the build logs to help fixing it, this is good
<infinity> mark06: To answer the second question, if you are upstream for project Foo that links to libbar, and you include a copy of libbar sources in your source and statically compile against it, we tend to instead link synamically with libbar from the archive.
<infinity> dynamically*
<mark06> infinity: I mean the opposite, say you're upstream for foo and I am the packager
<infinity> mark06: ...?
<infinity> If I were the upstream, I wouldn't bundle a bunch of junk.  Solved. ;)
<mark06> infinity: you link foo statically with bar, both are gpl... so when shipping foo.bin you need to ship foo.src alongside it... and since you use bar, you need to include bar source in foo.src (regardless of whether it's static or dynamic linking)...
<rbasak> AIUI, a distribution is free to ship both foo.src and bar.src, and foo.bin and bar.bin, and dynamically link, and nothing else is required.
<infinity> If you're shipping the binaries together, you need to provide sources for both, you don't need to have them in the same source tree.
<mark06> infinity: then I package foo into ubuntu, I make the package download foo.src tarball and just build it.... it happens to be that bar is a pretty common package installed in 99% of ubuntu computers
<tkamppeter> rbasak, I am here
<rbasak> tkamppeter: so I'm a bit confused as to why we're adding another patch in to solve this issue, if upstream reverted it.
<mark06> infinity: result is that even if usptream is alright, I'm not anymore because I didn't notice the static liking of bar
<rbasak> tkamppeter: also, can we have some dep3 headers please, so we can all follow it better?
<infinity> mark06: So, we're talking in circles here.  I think we've already addressed these points.
<infinity> mark06: It's a packaging bug if a package statically links something it shouldn't, and we report and fix those as we find them.
<mark06> by including the static stuff in tarball I mean for reference not merge into code base (in my example, add bar.src.tar.gz within foo.src.tar.gz)
<tkamppeter> rbasak, so do you think should I simply revert the old patch even if that bug reappears then?
<rbasak> tkamppeter: what's upstream's plan for that bug?
<infinity> mark06: If it's statically linking source shipped *with* the upstream tarball, it's not a license violation, as long as it's all compatible, it's just wrong from our policy perspective if it could be dynamically linked to a distro library instead.
<mark06> infinity: did you understand my foo/bar example at least, did you get my point (notice I didn't mention a bar.bin)
<tkamppeter> rbasak, I do not know, as I have never touched libspectre before. That is not really a printing-related package and I do neither know about any upstream plans nor about what Debian is doing about it. I think this first bug only got to me as they thought initially that it was a problem of Ghostscript and thenm it turned out that it is a bug of libspectre.
<rbasak> mark06: in that case, the distribution ships both foo.src and bin.src. There's no requirement in the licence that one must be _in_ the other. As long as they're both shipped, it's compliant.
<mark06> infinity: by *with* I don't mean the code base
<rbasak> tkamppeter: I don't think it's appropriate to push the patch into Ubuntu without it going upstream. We don't want to be maintaining that patch forever
<rbasak> tkamppeter: particularly if we don't know much about it. That just makes future merges even harder, and sets us up to get stuck on the current version for fear of regressing it in the future.
<mark06> infinity: real example: foo = pidgin++ for windows, bar = gtk+... pidgin++ uses gtk but the source for the gtk used is provided in separate tarball, see https://launchpad.net/pidgin++/trunk/15.1
<infinity> mark06: How is that relevant to Ubuntu?
<mark06> infinity: however I could put gtk+ bundle zip *within* pidgin++'s source zip and ***this*** is what I meant with with
<infinity> mark06: Why would you do that?
<tkamppeter> rbasak, so simply drop my proposal to take it and report the problem of both bugs to libspectre upstream. Then let upstream solve it and the fix getting into Ubuntu with an upstream release.
<infinity> mark06: But also, why would I care?
<mark06> infinity: man, just an example trying to explain what I say, because you started to get lost about it?
<infinity> mark06: If your build system doesn't use that tarball-in-tarball, it obviously doesn't impact me, as I'm not distributing *your* binaries, only your source.
<rbasak> tkamppeter: that's the easiest, yes. I'm still fine with taking patches into Ubuntu early, but only if it fits with upstream's plans. Which requires upstream bug reports, etc.
<rbasak> tkamppeter: a cherry-pick from upstream is best.
<tkamppeter> rbasak, can you do the bug report upstream for these two bugs?
<mark06> infinity: I have lost you.... I just wanted to explain you small points I made that you misunderstood completely, I should have not tried to explain
<rbasak> tkamppeter: no - I'm not familiar with the issue!
<tkamppeter> rbasak, me not either.
<rbasak> tkamppeter: I'll explain in the bug.
<mark06> rbasak: is this channel publicly logged? can I paste this chat?
<mark06> ah "This channel is logged"
<infinity> mark06: I disagree that I misunderstood, but okay. :P
<infinity> mark06: Fundamentally, how an upstream distributes their binaries is meaningless to a distribution.  How an upstream distributes their source is meaningful only if it violates our source distribution policy.
<mark06> don't you think upstream should provide clear, easily verifiable information about what is/may get linked statically?
<infinity> mark06: But including random sources in your source is generally not the right way to do things, whether it's in your tree or an archive in an archive, it just bloats the download for people who don't need it.
<cjwatson> we do a degree of auditing for that sort of nested-source issue as part of security auditing for things included in Ubuntu's "main" component (as opposed to "universe"), and Debian's security team does a ton of this kind of thing as well.
<infinity> mark06: Sure, upstreams should do a lot of nice things.
<mark06> in development, you don't build every lib form source... you use the binaries to link with... if packaging is wrong (missing static information), am I guilty for not having inspected each lib sources for mistakes?
<cjwatson> (I think they basically grep source trees for patterns they notice from libraries that are often sources of security problems.)
<cjwatson> Bugs aren't guilt
<mark06> I don't think I should be made responsible for someone else's "lies"
<cjwatson> That's quite an unhealthy way to look at it
<infinity> mark06: What's your actual concern here?  Lawyers knocking on your door if you accidentally link something you shouldn't?  That's not how the world works.
<rbasak> tkamppeter: commented.
<cjwatson> It would be the packager's responsibility to fix, and ideally they'd catch it early, but that doesn't mean they're "guilty" for having missed it
<infinity> A bug will get filed, it'll get fixed, we move on.
<infinity> mark06: A packager is responsible for the sources they upload.  That doesn't somehow make them terrible people if they miss something.
<cjwatson> Also, library packaging can mitigate this problem by simply not providing .a files in the first place, which is true for quite a few of our library packages these days
<mark06> whether it's in your tree or an archive in an archive -- you continue to misunderstanding pretty hard.... the latter is ***only for license compliance***, you can put it alongside instead of inside if you like (I did in my project)
<cjwatson> (Obviously it's still possible if source is actually copied around, but in practice that is much rarer)
<cjwatson> I'm pretty sure infinity understands this problem extremely well; maybe if you consider this a communication issue rather than them fundamentally not understanding, the conversation would go easier
<tkamppeter> rbasak, thanks.
<mark06> cjwatson: not sure if there are irrelevant gpl violations, smaller or bigger they're all violations and may be enforced by your local law, I doubt all jurisdictions in the world would think like "poor man he violated gpl accidentally"
<mark06> even though I tend to agree with you
<rbasak> mark06: sounds like you need to get some legal advice. Courts don't work like that.
<rbasak> mark06: I'm not aware of a single case where a distribution inadvertently violated a FLOSS license and it went anywhere near a court or settlement when fixed immediately.
<rbasak> It doesn't happen because there are no damages in this kind of case. Damages are required to make a case.
<rbasak> (in all jurisdictions I've heard of, anyway)
<cjwatson> mark06: What would actually happen is you'd get a stern legal letter, and either (a) you dig your heels in and probably lose in court or (b) you remedy the violation
<mark06> rbasak: that sounds good
<cjwatson> (in practice, anyone acting in good faith is unlikely to get close to the "stern legal letter" phase either, but ...)
<rbasak> mark06: law does not work like software engineering. Things are not black and white. You might find it helpful to read "What Colour are your bits?" if you haven't already: http://ansuz.sooke.bc.ca/entry/23 - it doesn't exactly cover this sort of issue, but I think it does demonstrate how the law works differently from how many software engineers might expect.
<cjwatson> And the whole bit where we do a bunch of auditing to try to prevent this, and will fix problems like this if they come up, is likely to look pretty good to a court.
<cjwatson> mark06: Also, a bunch of the people here aren't speaking out of theory, we're speaking from ten years of this not causing Ubuntu to fall over in a heap of lawsuits :-)
<mark06> rbasak: Things are not black and white -- I know the law environment and I'm aware of this.... but this is exactly an argument in favor of mine
<infinity> mark06: Copyright violations require the copyright holder to file suit.  Unless you're inadvertently bundling GPL code that originated with the MPAA or RIAA, I think you're likely being paranoid about a situation (action seeking penalty rather than remedy) that isn't going to happen.
<mark06> cjwatson: good to know my concerns are somehow theoretical (at least for ubuntu)
<infinity> mark06: From your upstream bundly perspective, though, I would still encourage you to distribute your extra sources beside yours, not contained within.   Just to keep things small.
<infinity> mark06: If I download your source, I don't need the other source.  GPL compliance is about binary distribution (and consequential responsibility to cough up matching sources), I have no need for all the bundled things you used if I don't download your binaries.
<rbasak> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | alpha 1 freeze in place | Patch Pilots:
<dobey> huh
<mark06> thanks all
<slangasek> chrisccoulson: ok.  I'm very aware of such a problem here ;)  Guess I'll file a bug report...
<chrisccoulson> slangasek, I'd recommend filing it upstream if you haven't
<slangasek> chrisccoulson: ok. where's the right place to do that?
<zyga> kirkland: hey, hollywood is leaking processes like crazy
<zyga> kirkland: the kill thing setup as interrupt handler doesn't kill the started widgets
#ubuntu-devel 2014-12-18
<ari-tczew> mitya57: hi, could you check package d-feet - there's new upstream release available in Debian, can we sync it?
<Mirv> would any core-dev review/ack/nack the debian/* part of the following changes from Unity team related to multi-arch? https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141210.2-0ubuntu1.diff
<pitti> Good morning
<dholbach> good morning
<LocutusOfBorg1> hi dholbach :)
<dholbach> hi LocutusOfBorg1
<LocutusOfBorg1> bothering you in the first morning
<LocutusOfBorg1> 1292118
<LocutusOfBorg1> I got testing done ;)
<dholbach> thanks
<Laibsch> Laney: Hello, are you there? I was wondering if there was anything I should be doing re PPU now. Rolf
<dholbach> LocutusOfBorg1, https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=
<dholbach> I think the other bug tasks can be closed, right?
<LocutusOfBorg1> sorry I don't get what should be closed...
<LocutusOfBorg1> (thanks for the upload BTW)
<dholbach> LocutusOfBorg1, it was a but in virtualbox in ubuntu after all, right?
<dholbach> so nothing which needs addressing upstream or it linux
<dholbach> if that's the case I'd close the other bug tasks
<LocutusOfBorg1> dholbach, makes sense, nope it is a cherry-pick from the new release
<LocutusOfBorg1> trusty isn't affected at all
<LocutusOfBorg1> 4.1.14 has already the patch IIRC
<dholbach> right
<LocutusOfBorg1> dholbach, introduced somewhere around 4.2.16 http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/tree/src/VBox/HostDrivers/Support/linux/SUPDrv-linux.c?id=upstream/4.2.16-dfsg
<LocutusOfBorg1> confirmed, between 4.2.8 and 4.2.16
<Laney> Laibsch: oh yes, that needs someone on the TB to action but stgraber was busy last week
<Laney> pitti: morning, fancy running some edit-acl for me & Laibsch? :)
<pitti> hey Laney; sure
<Laney> he needs PPU for https://lists.ubuntu.com/archives/devel-permissions/2014-November/000764.html adding
<Laney> pitti: should be something like `edit-acl -p r0lf -S vivid -s bugz -s ffgtk -s fslint -s gjots2 -s isdnutils -s kasumi -s libcapi20-3 -s n2n -s pastebinit -s polipo -s roger-router -s scanbd -s scim -s scim-anthy -s scim-tables -s wondershape add'
<Laney> can't test, obviously
<pitti> Laney: yeah, I'm in the middle of it
<Laney> ah
<pitti> Laney: oh, only for vivid, not all releases?
<pitti> "I've done many SRUs" sounds like he'd want stables, too?
<Laney> I guess so :)
<Laney> you could wrap it in a for release in $(ubuntu-distro-info --supported)
<Laney> I don't think it matters if a package actually exists in that release or not
<pitti> Laney, Laibsch: done: http://paste.ubuntu.com/9558596/
<Laney> merci
<Laibsch> thanks a lot
<Laibsch> I think I have one sync from experimental.  I'll prepare it and request for review this time to make sure I understand the process
<Laibsch> Is there much of a difference technically when uploading to Ubuntu vs Debian?  I guess, I'll also be using dput?
<Laney> Laibsch: https://wiki.ubuntu.com/MOTU/New might be helpful
<Laibsch> yes, I was looking for something like that
<Laney> In Ubuntu we upload without binaries
<Laibsch> thanks for helping me to find it quicker
<Laibsch> aha, no binaries, noted
<Laibsch> will an upload get rejected if there is a binary?
<Laibsch> or will it simply be discarded?
<Laney> Don't remember, probably rejection - try with a PPA if you want
<cjwatson> It will be rejected, yes
<cjwatson> Debian's moving towards source-only uploads too - in many cases you at least *can* now upload that way
<Laibsch> in Ubuntu there is no protection even in case of a freeze, right?  In Debian, the package would simply not migrate to testing.
<Laibsch> so more responsibility
<pitti> Laney: we have the same now -- stuff is held in -proposed during freezes
<pitti> see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<cjwatson> unstable is to testing as vivid-proposed is to vivid, very roughly
<cjwatson> though the details of the rules are different - most notably, we have no migration delay
<Laney> We don't have a freeze for Feature Freeze either, you have to look out for that yourself
<Laibsch> Ah, that is good.
<Laibsch> one more safety net
<Laibsch> Are there any checks to see that version 1.2.3-4 (a Debian release obviously) is actually what I claim it to be?
<cjwatson> usually verbatim syncs are performed by copying publication records around in Launchpad, rather than you uploading it independently
<Laibsch> I'm not looking for loop-holes (well, I am but only to understand where I need to pay attention and where I can rely on safety nets being in place)
<Laibsch> OK, can I do that in LP now?
<Laibsch> or only core devs
<cjwatson> anyone who can upload can also copy
<cjwatson> syncpackage(1) will do it for you
<Laibsch> I see, thanks
<cjwatson> it's technically possible to reupload the same version, and it's not checked directly, although it might eventually cause flags to be raised further down the line
 * Laibsch back to the wiki page
<cjwatson> but there's normally no good reason to
<cjwatson> (except for urgent syncs from incoming; but we have a part-complete plan for making that a lot quicker, will hopefully finish it in the new year)
<Laibsch> my question was not about reuploading the same version, but to upload something as 1.2.3-4 where people would think that to be the same as the package in Debian while I had made (intention or unintentional) changes
<Laibsch> I can make an upload to quastaging with "syncpackage -l qastaging -d experimental scanbd" to see if this works the way I want it to?
<cjwatson> Laibsch: such a thing is technically possible, it's not checked directly, though I think we would be pretty unimpressed if we found anyone doing it.  Assuming you aren't looking for loopholes, though, the best way to avoid this is to rely solely on syncpackage or similar when intending to copy packages from Debian
<cjwatson> Laibsch: I don't think copy jobs run against qastaging will be processed
<Laibsch> yes, like I said, I am not looking for loopholes, just things that would make you guys unimpressed
<Laibsch> I'd like to avoid that ;-)
<cjwatson> Laibsch: just doing "syncpackage -d experimental scanbd" should be fine; it'll prompt you for what version you're copying, and assuming you vouch for that then it will either work or fail, it's not going to randomly do something else
<Laibsch> that sounds really good
<Laibsch> qastaging fails: http://paste.debian.net/137238/
<Laibsch> but production seems to do the right thing
<Laney> https://launchpad.net/ubuntu/+source/scanbd/1.4.1-1 it is working
<cjwatson> Laibsch: Yeah, gina probably isn't running there
<cjwatson> (the thing that imports Debian Packages/Sources files)
<Laibsch> awesome!
<Laibsch> thanks
<cjwatson> basically qastaging isn't in general set up for QA of Ubuntu archive stuff
<Laibsch> does LP provide me with a set of the packages I have now upload rights to?  I'd like to be able to refer to it in the future when in doubt and most importantly it would be nice to have a view of bug tickets restricted to those packages. Does LP provide that for me with a simple click?
<Laibsch> https://bugs.launchpad.net/~r0lf/+packagebugs comes kind of close
<Laibsch> well, not really
<cjwatson> Laibsch: not in the web UI, but lp:ubuntu-archive-tools has edit-acl, which has a query function: edit-acl -p r0lf query
<cjwatson> Laibsch: for a bug view, your best bet is to subscribe to bugs for each of the relevant packages, and then you can use https://bugs.launchpad.net/~/+packagebugs
<Laibsch> Ah, the one you used.  I automatically assumed that was something only for the super-powers.  Thanks.  I will refer to that and feed an API script with its output to get my bug list, I guess.
<cjwatson> Laibsch: which you can do from https://bugs.launchpad.net/ubuntu/+source/ffgtk "Subscribe to bug mail" etc., or it's easy to script by something like http://paste.ubuntu.com/9559306/
<cjwatson> (hm, the list of packages should probably be positional arguments in that script; anyway)
<cjwatson> so http://paste.ubuntu.com/9559315/ I guess
<Mirv> (repeat from the morning) would any core-dev review/ack/nack the debian/* part of the following changes from Unity team related to multi-arch? https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141210.2-0ubuntu1.diff
<pitti> Mirv: weird repetitions in the changelog ?
<Mirv> pitti: CI Train is sometimes hard to keep behaving when multiple merges happen
<pitti> Mirv: looks ok to me, although I don't understand the fuss around it -- why bother making paths in compiz M-A compatible and adding "M-A: no"?
<Mirv> pitti: ok. the MP is https://code.launchpad.net/~bregma/compiz/lp-1395105/+merge/243031 stating "where possible". they started with making everything m-a, and then backed up for those that had /usr/bin content
<Mirv> I can file a bug if there are any suggestions for future work
<pitti> Mirv: right, at least for the libs and python
<pitti> Mirv: nah, don't worry; let users file bugs if they actually need it :)
<pitti> Mirv: so, +1
 * Mirv hugs pitti
 * Mirv tells bregma to hug pitti too
<pitti> no worries, it was just a small review :)
 * bregma hugs pitti in a manly fashion
 * Riddell hugs pitti in a gender neutral fashion without back slaps
<pitti> bregma: you mean with clinking beer cans and a heartily poke into the ribs? :-)
<pitti> hallyn: hey, how are you?
<pitti> hallyn: OOI, what is the reason why we can't enable cgmanager in Debian by default?
<pitti> hallyn: I see that it certainly shouldn't run all the time, but could we do something like D-BUS or socket activation?
<hallyn> pitti: bc systemd doens't want us to
<pitti> hallyn: oh, so it does conflict to systemd? (I misunderstood that then)
<pitti> there's certainly a high chance that they do
<pitti> well, at least since recently when systemd started to put processes into all cgroup controllers
<pitti> before that, systemd only touched teh "systemd" controller, so they shouldn't have interfered
<pitti> hallyn: but we don't do that ^ (LXC user container support) on Debian -- so if they already collide on Debian, they will collide even harder in Ubuntu now
<pitti> hallyn: so in that case I guess we close the cgmanager task, and fix that in UAL?
<hallyn> pitti: no, they don't "conflict".  they work fine together.  Systemd however wants by default to control all the cgroups themsevles
<pitti> hallyn: well, but that's only true with the ubuntu patch to handle all controllers, not just the private systemd one?
 * pitti confused
<hallyn> so systemd would claim they "conflict" in that systemd can't make educated ecisions if someone else is making changes
<bdmurray> roaksoax_: was the verification of the curtin SRU done both on trusty and utopic? e.g. bug 1378910 the bug only says verification-done.
<ubottu> bug 1378910 in curtin "Call the install log 'install log' rather than 'curtin log'" [High,Fix committed] https://launchpad.net/bugs/1378910
<mapreri> pitti: <3
<pitti> mapreri: thanks for your work on the merges
<mapreri> pitti: I'd like to do more, but this year I started the uni, and I'm lagging a bit, quite overwhelmed by other things.... (e.g. mainly school and debian) :)
<shadeslayer> anyone know where I can get the apt-get exit codes?
<bdmurray> tkamppeter: what happened to system-config-printer version 1.4.3+20140219-0ubuntu2.3?
<bdmurray> tkamppeter: ah, I figure it out
<bdmurray> tkamppeter: however I'm a bit confused by this comment https://bugs.launchpad.net/ubuntu/+source/system-config-printer/+bug/1398444/comments/5. The upload to trusty-proposed doesn't reference bug 1400232 or bug 1401835 in the changelog.
<ubottu> Launchpad bug 1398444 in system-config-printer (Ubuntu Trusty) "Missing dependency on gir1.2-gtk-3.0" [Undecided,In progress]
<ubottu> bug 1400232 in system-config-printer (Ubuntu Trusty) "system-config-printer crash UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 1441: invalid continuation byte (only UTF-8-encoded PPD files can be used)" [Undecided,In progress] https://launchpad.net/bugs/1400232
<ubottu> bug 1401835 in system-config-printer (Ubuntu Trusty) "system-config-printer does not automatically download and install printer driver packages any more" [High,In progress] https://launchpad.net/bugs/1401835
<hallyn> does anyone here have a ppc64el trusty machine handy to verify bug 1374554 ?
<ubottu> bug 1374554 in libvirt (Ubuntu Utopic) "ppc64el virsh start fails" [High,Fix committed] https://launchpad.net/bugs/1374554
<infinity> hallyn: Given it's a 1-line patch, if the patch was identical on U and T, and tested okay on U, I'd be inclined to just call it good in both places.
<infinity> hallyn: qemu on T isn't entirely ppc64el ready anyway, AFAIK, so proper testing would fall flat pretty quickly after that bug.
<hallyn> infinity: ok, thx.  (working on verifying the other bug in -proposed right now so we can clear that logjam)
<infinity> hallyn: Just double-check the patch really is identical on both before handwaving the T verification. :P
<hallyn> ok
<infinity> hallyn: Though, actually, it shouldn't need a ppc64el host to test, if you can convince libvirt to start a ppc64 guest on your x86 machine.
<infinity> hallyn: Fully emulated qemu-system-ppc64 works great on x86 (a bit slow, but works).
<mitya57> shadeslayer, apt-get(8) says that "apt-get returns zero on normal operation, decimal 100 on error."
<hallyn> infinity: oh, i thought the bug required kvm (since it requires access to ppc64-specific sys info)
<infinity> hallyn: The 1-liner is just giving access to /usr/share/slof, which is the loadable firmware, nothing to do with the host arch.
<infinity> hallyn: Oh, I see, there's also a line for reading the host's devicetree.
<hallyn> yeah i don't know what happened with the changelog there
<hallyn> it's missing gtwo lines from utopic-proposed's
<infinity> hallyn: Yeah, just verify blind by comparison of diffs to utopic, IMO.
* infinity changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Laney> stgraber: does dnsmasq write a log file when something updates the server it's fowarding to?
<Laney> I'm getting queries being refused
<stgraber> no
<Laney> while on a VPN
<stgraber> well, maybe to syslog but if it does, it's not going to be very obvious (dnsmasq logging is pretty terrible)
<Laney> ah, syslog does have some stuff
<Laney> looks like it's trying to use split dns
<stgraber> right, NM will usually do split DNS, sending all the subnets and domains advertised by the VPN over to the DNS server it pushes
<Laney> the ones the VPN server pushed are resolvable, the rest are refused
* Riddell changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | Vivid Alpha 1 out
<Riddell> Vivid Alpha 1 out
<Riddell> archive is unfrozen
<hallyn> xnox: hey - reminder, would you mind sponsoring http://mentors.debian.net/debian/pool/main/n/netcf/netcf_0.2.6-1.dsc ?
<JackFrost> xnox: And can you "review" https://code.launchpad.net/~unit193/ubiquity/xfwm4-panel/+merge/244437 ?
* infinity changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> Riddell: Adding to the end of the topic really confuses the bot. ;)
#ubuntu-devel 2014-12-19
<JackFrost> Snow-Man: Howdy.
<Snow-Man> I don't suppose anyone else is seeing crashes with ipv6-enabled systems under the latest 14.04 kernel?
<Snow-Man> Linux tamriel 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
<Snow-Man> JackFrost: uhm, hi.
<Snow-Man> I've just installed crashdump to see if I can catch it happening again.
<Snow-Man> if so, I'll probably boot into the prior kernel I was running (3.13.0-40.69).
<Snow-Man> I'm not 100% sure that it's ipv6-related, but the piece of the stack trace still visible clearly showed ipv6 in the output.
<Snow-Man> perhaps also interesting is that this is happening to a KVM box and the physical box (which also has ipv6 enabled) isn't having any issues.
<Snow-Man> (the physical box the KVM is sitting on, that is)
<Snow-Man> that box is running 3.13.0-43-generic #72-Ubuntu
<Snow-Man> Doesn't seem to be network load related tho, as I can do a bump of ipv6 stuff (download debs, etc).
<Snow-Man> anyway, was just curious if anyone else saw anything similar.  After the next crash I'll hopefully have enough information to file a useful bug report.
<weasel_popper> this may be a stupid suggestion, but I think that 'rm' should be required to have root privileges, and that a new program called 'dl' should be added which asks for confirmation on each record before deletion, and rather than removing the nodes from the filesystem it marks them and moves them to a trash directory of limited size
<Snow-Man> lose something?
<weasel_popper> nah, just reading a book called 'The Unix Haters Handbook'
<weasel_popper> Some of these people have had horrendous mistakes with rm
<Snow-Man> You know, if these silly filesystems worked like databases do and required you to do a 'commit;'...
<Snow-Man> (says the PostgreSQL committer)
<JackFrost> 1.  That'd be so terribly annoying, when I want to rm something, I want it removed (yes, I've made mistakes.  I don't want it changed.)  2. Simple fix: alias rm='rm -i'
<Snow-Man> I *hate* that alias.
<Snow-Man> and, I really *love* rollback;. ;D
<weasel_popper> It'd be no different than the 'del' command for DOS. you could call it with -, or type 'A' when it asks for the first confirmation to skip all others
<weasel_popper> and you'd be able to restore files, rather than scraping your disk with fsck if you mess up
<Snow-Man> eh, this is all uninteresting.
<Snow-Man> If you really want that, go write a filesystem to do it for you.
<Snow-Man> Shouldn't be too hard to do and you don't have to monkey around w/ rm.
<weasel_popper> It's probably not realistic to attempt to do this anyway, with all the tools that rely on rm. I just think it's a little to dangerous to be called directly. Like dd
<bluesabre> Are any DMB members lurking?  It looks like the shimmer-themes source package fell out of the xubuntu packageset upload rights
<JackFrost> Snow-Man: Yeeah, I got used to using -rf  because of that alias.
<Snow-Man> JackFrost: indeed, that's one of the big problems w/ it.
<Snow-Man> pfft, dd isn't dangerous
<Snow-Man> doing things as *root* is dangerous
<weasel_popper> dd if=/dev/hd0 of=/dev/hd0 skip=1
<weasel_popper> that's like divide by zero button for unix
<Snow-Man> still gotta be root to do it tho.
<ScottK> bluesabre: Please send mail to the devel-permissions ML.
<dholbach> good morning
<Tribaal> hi all
<Tribaal> dholbach: I'm about to submit a SRU (later today) for landscape-client. What is the now favorite way to do this? Sending branches with the bug? Should I push some binary packages to -proposed for each version I'm targetting?
<dholbach> hi Tribaal
<Tribaal> dholbach: our docs indicate attaching debdiffs - but that feels... barbaric :)
<dholbach> Tribaal, branch is fine, source package is fine, patch is fine, but binary packages are not
<Tribaal> dholbach: roger. So attaching branches to the bug + subscribing the SRU team (to the bug) is all I need?
<dholbach> subscribe 'ubuntu-sponsors' for somebody to upload the patches as well
<Tribaal> dholbach: oh ok. So the sponsors/SRU guys do their own "debuild" dance then? (just curiosity, I'm re-documenting the process on our end)
<dholbach> yes, they do
<Tribaal> dholbach: awesome, thanks a lot
<dholbach> if I'd upload it, I'd do a local test build, check the diff, and whatever feels necessary to see if things make sense :)
<dholbach> anytime
<Tribaal> dholbach: yeah, we have a pretty long procedure with many tests in place, I just installed the new package to a combination of 4 distros, 3 landscape server versions, and "fresh install" versus "upgrades". So I'm becomming an expert at local builds :p
<dholbach> :)
<Laney> Riddell: is kubuntu-plasma5 still valid?
<Laney> IIRC that's folded into main kubuntu now
<Riddell> Laney: right yes
<Riddell> Laney: in which context?
<Laney> DMB: we were considering it when generating the kubuntu packageset
 * Laney drops
<bluesabre> thanks Laney!
<bluesabre> bbl
<mitya57> ari-tczew: re d-feet: please talk to seb128, the revert was on his request
<ari-tczew> mitya57: ok, thanks for reply
<mitya57> (I am personally fine with syncing it)
<shadeslayer> mitya57: hmm, true, I was hoping that it would return different exit codes for different things
<Tribaal> dholbach: so I just subscribed the SRU team to the latest landscape-client bug, as promised :) Don't hesitate to let me know here if I can do anything else to help
<dholbach> ubuntu-sponsors too?
<dholbach> or did you upload it already?
<Tribaal> dholbach: oh right, subscribed.
<dholbach> cool :)
<Tribaal> dholbach: I might apply for single-package upload rights at some point, so I can do this part
<dholbach> excellent :-))
<Tribaal> dholbach: I might annoy you for a testimonial once the wiki paperwork is done :)
<dholbach> sure, let me know :)
<Tribaal> dholbach: thanks :)
<infinity> mlankhorst: Is there a reason you're still arch-restricting your lts backport stacks?
<infinity> mlankhorst: (Note: we're not doing so for the lts-u kernel)
<mlankhorst> oh no not at all
<mlankhorst> I just don't have a way to test it on arm
<infinity> mlankhorst: That's true for the dev release too, it doesn't stop us from building packages on all arches. :P
<mlankhorst> hah
<mlankhorst> I'd have to do the re-upload tomorrow then
<infinity> mlankhorst: (ppc* are actually more my concern than arm, but I don't see any point in artificially restricting any of it in the backport)
<infinity> mlankhorst: Worst case scenario, some driver or something works worse in one stack than in another, but people get choice that way.  *shrug*
<mlankhorst> there's just no way for me to test with 100% certainty..
<mlankhorst> I might be able to test installability though
<infinity> mlankhorst: We're only building point release desktop CDs on x86 (so far), so the 100% certainty testing really only needs to happen there.
<infinity> mlankhorst: But giving people on other arches choice to flip stacks doesn't hurt, IMO.
<mlankhorst> true
<mlankhorst> i may be able to test installability on armhf at least
<mlankhorst> infinity: but what's the point when the only working 3d driver on other archs is llvmpipe
<infinity> mlankhorst: nouveau works on some/most PPC machines.
<infinity> mlankhorst: radeon is off again on again.
<infinity> mlankhorst: In theory, most PCI drivers should work, in practice, it's hit and miss.
<mlankhorst> ok
<mlankhorst> why would you update thoose though :p
#ubuntu-devel 2014-12-20
<Noskcaj> Can someone please retry bijiben on all arches? It was waiting on gtk 3.14 but didn't have a versioned dep
<infinity> Noskcaj: Retrying.
<Noskcaj> ty
<nitohu> Hello
#ubuntu-devel 2014-12-21
<weasel_popper> so, this is obvious another stupid idea, but it would be nice if linux treated paths like  ':/myfile' the same as '/myfile'. It would make interoperability with windows easier, as the ':/' would easily be identifiable as root, as opposed to '/mypath' being ambiguously relative
<weasel_popper> again, not expecting anything, just venting a pet peeve of mine as a cross-platform developer
<CajunTechie> Hey everyone, I posted this to the dev mailing list but then thought about this chan. Does anyone know the future of Mono on Ubuntu? Are their any plans to begin including it in the distro again?
<xnox> weasel_popper: no, we cannot. checkout $ echo $PATH
<xnox> weasel_popper: ":" is used a path separator on unix already (windows uses ; for similar purpose)
<directhex> a path beginning with / is never relative
<directhex> it's not ambiguously relative, it's unambiguously off the root
<infinity> weasel_popper: To expand on what directhex said, a path starting with a slash is unambiguously rooted in Windows too.  \foo doesn't mean $cwd\foo it means \foo on the root of the drive you're on.  Not the same as the UNIX root concept, but definitely not a deep relation either.
<infinity> weasel_popper: And I hinted at it above, but the UNIX / and the DOS \ are not the same thing, as DOS can have multiple roots (drives), UNIX can only have one.
<infinity> weasel_popper: The internal representation in NT actually fixes this, but that's not what people see at the command line or from most scripting languages.
<hjd> Hi all. Could someone please start a rebuild of https://launchpad.net/ubuntu/+source/libbssolv-perl? It looks like it was synced the day before https://launchpad.net/ubuntu/+source/libsolv which it depends upon and ended up in a dependency wait state.
<infinity> hjd: Done.
<hjd> infinity: Thank you :)
#ubuntu-devel 2015-12-14
<pitti> Good morning
<dholbach> good morning
<sladen> Morgen
<mvo> pitti: hi, juliank discovered that a autopkgtest fails on s390 and armhf with "WARNING: CHROOTing to /tmp/tmp.UsVnmk3JLH/rootdir was ignored!" is there anything we can do about that ?
<juliank> Maybe because those are run on lxc?
<pitti> yes, those are in LXC, the other arches run in VMs
<pitti> I guess you can't chroot() in LXC
<juliank> pitti: On Debian's amd64 lxc instance it works, though
<pitti> juliank: I suppose  it's limited by the apparmor profile
<pitti> (which Debian doesn't have)
<juliank> Can we do anything about that? We obviously need that for our test suite to work correctly because we're testing interaction with dpkg amongst other things
<jjohansen> depends, Debian can have the lxc profile, but they are running the mainline kernel version of apparmor
<jjohansen> so it is missing some things, the userspace side is largely up to date
<pitti> juliank: with chroot() you can easily escape the container, so I'd rather leave tests as "always failed" on the LXC arches
<juliank> OK.
<juliank> I'll try to at least get the i386 tests passing, currently they only work on amd64
<pitti> juliank: which package is that, OOI?
<juliank> pitti: apt
<juliank> The failure on i386 is just because we only run the suite on amd64, and thus have bugs...
<pitti> juliank: right, so they are "always failed" on all but amd64, so they won't hold up proposed migration
<pitti> so that's not urgent
<juliank> pitti: It's annoying me a bit, though :) [ppc64el should work too, then]
<juliank> pitti: We are not actually chrooting(), but preloading a no-op chroot() library. What happens is that we rewrite all execvpe() calls to run <CHROOTDIR>/COMMAND instead of COMMAND, with DPKG_ADMINDIR=<CHROOTDIR>/var/lib/dpkg. So, does the apparmor profile prevent us from executing stuff in /tmp?
<juliank> We get a "No such file or directory" when trying to execute the rewritten script path
<juliank> For example, /tmp/tmp.Z4pabkgrXk/rootdir/var/lib/dpkg/info/triggerable-interest-noawait.postinst
<juliank> execvp(), not execvpe()
 * juliank would have expected some permission denied thing, though
<juliank> If we could get a log of apparmor during an autopkgtest run, that would probably be useful.
<pitti> juliank: I can start a test run manually and check in the container, hang on
<xnox> pitti, looking at http://autopkgtest.ubuntu.com/data/status/xenial/amd64/status.json and http://autopkgtest.ubuntu.com/data/status/xenial/s390x/status.json -> i do not believe that there are move autopkgtests for s390x than there are for amd64 =)
<xnox> or what do those numbers mean?
<pitti> xnox: that actually seemse right
<pitti> xnox: as over the weekend I triggered *all* available autopkgtests on s390x
<pitti> xnox: but we don't do that for the other arches, they only run if britney triggers them
<pitti> xnox: and there's a bunch of packages which haven't changed since wily and thus never ran for xenial
<xnox> pitti, hm, so there are tests that never been run on amd64?
<pitti> (or their dependencies)
<xnox> oh.
<pitti> xnox: not in xenial; they ran in wily (or even earlier for packages that seldomly change)
<xnox> that makes comparison between arches odd.
<xnox> pitti, can you trigger *everything* on amd64 & ppc64el?
<pitti> xnox: I'd need to trigger only the ones which didn't run since wily
<pitti> "everything" on these will take way too long
<xnox> yeap, like that.
<pitti> xnox: yes, I can, the main piece of work is to figure out the list of packages
<xnox> cause i want to compare the same ballpark numbers on s390x vs others. for test-report...
<xnox> pitti, i can do that from json for you, if you wish?
<pitti> xnox: you mean the pass/fail ones?
<pitti> xnox: that'd be great, yes
<pitti> xnox: btw, fancy graphs: http://autopkgtest.ubuntu.com/status/
<xnox> pitti, yeah those graphs are missleading =) as e.g. amd64/ppc64el have less packages and higher pass rate. s390x has more packages and lower pass-rate (even when package count adjusted) cause loads of things are still uninstallable.
<xnox> i'm doing what nobody should do, that is rerun tests to bring amd64 to reality such that it is comparable with s390x ;-)
<pitti> xnox: so, ~ 92% pass rate on i386, ~ 80% on armhf (using LXC), and roughly 70% on s390x (also LXC)
<xnox> when opening new series, can you not copy over old results from previous release? such that we get pkg count continuity?
<xnox> or trigger all on opening...
<pitti> xnox: I could; so far I only copy over the last successful result (if any), to tell apart "always failed" vs. "regression" across new series
<pitti> xnox: but as this isn't necessary for "always failed" packages I don't copy those
<pitti> juliank: btw, there's other errors like
<pitti> -fancy
<pitti>  specific
<pitti> +fancy
<pitti> juliank: (i. e. ordering); I'm running the apt test on armhf manually, so far I haven't run into apparmor violations yet
<pitti> ah, but it's only at test 45, the first of that is 132
<juliank> pitti: Yeah the other issues are somewhat strange but unrelated.
<juliank> It's just ordered differently for whatever reasons
<xnox> $ wc -l *.missing
<xnox>   553 amd64.missing
<xnox>   585 armhf.missing
<xnox>   500 i386.missing
<xnox>   799 ppc64el.missing
<xnox>     0 s390x.missing
<xnox>  2437 total
<xnox> pitti, http://bazaar.launchpad.net/~xnox/+junk/missing-autopkgtests/files
<xnox> pitti, run.sh is how i generated them, *.missing files are the ones to trigger per arch, which did not yet run on xenial it would seem. Would you please check my work for sanity before triggering?
 * xnox thinks the above triggers are too high.
<pitti> xnox: heh, e. g. http://autopkgtest.ubuntu.com/packages/libx/libxml-tidy-perl/ never ran :)
<xnox> pitti, so it is correct right? =) only ever run on xenial/s390x =)
<pitti> I guess the autodep8 stuff landed later than the last change to it
<pitti> xnox: and e. g. http://autopkgtest.ubuntu.com/packages/l/lmod/ is a case where xenial version == wily version
<pitti> xnox: so some spot checks seem fine
<pitti> juliank: I'm getting the chroot warnings now, no apparmor violations
<juliank> pitti: OK. Then something stranger is going on. Thanks for testing.
<xnox> pitti, well please trigger these then =)
<pitti> juliank: as soon as the test finishes I can ssh into the container, if you want me to run anything
<juliank> pitti: I'm looking at building something, it's somewhat hard though. We build this library: https://paste.debian.net/344216/.
<juliank> pitti: I think I found the bug. It's an off by one, newfile is one byte to short
<pitti> juliank: ah!
<pitti> juliank: please consider using this:
<pitti> char newfile[PATH_MAX];
<pitti> snprintf(newfile, sizeof(newfile), "%s/%s", path1, path2);
<pitti> juliank: snprintf() is so much safer and avoids these gotchaas
<pitti> every strcpy() and strcat() eliminated from production code makes a dead kitten get back to life somewhere! :-)
<pitti> xnox: do you really need all the arches for comparison? isn't amd64 or armhf sufficient?
<pitti> xnox: I now transformed your lists into run-autopkgtest commands with appropriate --trigger arguments, running amd64 now
<xnox> pitti, amd64 will do for this week, and rerun everything else on the weekend / holidays?
<pitti> but running 500 tests will take a fair while, I'm not going to launch the i386 ones right away
<pitti> xnox: sounds fine
<pitti> xnox: http://autopkgtest.ubuntu.com/running.shtml#queue-xenial-amd64
<xnox> imho for next series you should copy all the results otherwise we under-report the amount of testing we do.
<pitti> yeah, can do
<xnox> pitti, \o/ thanks.
<pitti> xnox: you are the first to notice/ask about statistics
<xnox> hehe.
<pete-woods> pitti: sorry to keep nagging, but is there any chance you could do a backport of the latest dbusmock release into the vivid overlay?
<pitti> pete-woods: it hasn't landed in xenial yet, stuck on the test regression
<pitti> so, don't want to backport yet, this first needs looking into
<pete-woods> pitti: ah, hadn't realised that
<pete-woods> okay
<pete-woods> I will have a look at that then
<pete-woods> pitti: https://github.com/martinpitt/python-dbusmock/pull/18/files how about that?
<pete-woods> (copied the same setup from test_bluez5.py)
<pete-woods> to me it looked like *something* was running the tests individually
<pitti> pete-woods: oh nice! do you know what triggered that in your last PR?
<pete-woods> pitti: I added a test that did sorta async stuff from the bluez test
<pete-woods> where you wait for a bunch of signals to be emitted
<pitti> ah, async needs a main loop indeed
<pete-woods> but the weird thing is the tests work fine when you run the full suite
<pete-woods> maybe that's because the bluez one has already setup the mainloop..
<pitti> cd tests
<pitti> for f in *.py; do
<pitti>     python3 $f
<pitti> done
<pitti> pete-woods: ^ the autopkgtest does that
<pete-woods> right
<pitti> pete-woods: yeah, very likely
<pete-woods> well that would explain it
<pitti> pete-woods: we want to run the tests against the installed py module, so we can't use ./setup.py
<pete-woods> fair enough
<pete-woods> I have no python-fu
<pete-woods> I just type til it stops erroring
<pitti> pete-woods: works fine, thanks
<pete-woods> cool
<pitti> pete-woods: 0.16.3 released and uploaded to Debian; for the backport, I take it vivid+wily?
<pitti> pete-woods: uploaded backports to both; thanks for the fix!
<pete-woods> pitti: thanks very much, I don't really care about wily too much, but may as well do both just in case
<xnox> infinity, may i steal your strace pending merge?
<infinity> xnox: Sure.
<xnox> infinity, fails on i386 with one fail, fails a lot more on s390x =( here is to new upstream release fixing nothing....
<infinity> xnox: Looks fine in Debian build logs.  So, that's curious.
<xnox> mono gdoc fails to bootstrap with -O2, strace failures. something odd is going on.
<xnox> *mdoc
<teward> should I be highly concerned when my sbuild schroot complains with "W: No sandbox user '_apt' on the system, can not drop privileges"
<teward> (it's a Xenial schroot)
<cyphermox> has it already done some upgrades before showing that message?
<infinity> teward: That's because the user doesn't exist outside the chroot, and schroot copies in your external /etc/passwd
<infinity> teward: It's mostly harmless.
<xnox> infinity, retrying strace/i386 made it "pass" the test-suite.....
 * xnox looses confidence in strace testsuite
<thebwt> howdy folks! I'm putting together a chart for a history of Ubuntu. Before lucid, Ubuntu was derived from Debian Sid. Was it a frozen Sid at the time of release? (trying to show the relationship overtime to debian)
<geofft> can someone who can see private bugs tell me what LP #723515 is?
<ubottu> Error: Launchpad bug 723515 could not be found
<geofft> or where should I ask?
<infinity> geofft: Ask the security team.  If it's an ubuntu bug, they can see it.
<geofft> I believe that it is a bug in Ubuntu glibc
<infinity> geofft: If it's not, then the only people likely to be able to see it are LP admins, to #canonical-sysadmin
<geofft> er, gcc
<infinity> Actually, wait, I'm in the security team and I can't see it. :P
<infinity> So, no.  It's probably not an Ubuntu bug.
<xnox> infinity, >_< #identitycrisis
<infinity> xnox: *cough*
 * xnox slowly backs away
<infinity> xnox: Using hashtags on IRC should be punishable by death.
<geofft> I am pretty sure the kids these days are saying things like "hashtag ubuntu-devel"
<xnox> infinity, wait till Ev comes over to london and stays at my place. I'll catch up on my hipster training to make you cry. =)
<infinity> geofft: *cry*
<infinity> xnox: Are you going to grow a beard and roll up your jeans to fit in?
<infinity> xnox: I can send you some nice plaid flannel from Canada.
<dobey> infinity: don't forget the butter scones and women's clothing too
<xnox> thebwt, it's more fluid than that. each release cycle there are autosyncs happening from debian, in general it's always from debian sid, apart from couple of LTS which we did from testing. but these days it's always from sid. Where there are no changes in ubuntu packages are synced from debian unmodified. Upto debianimport freeze milestone, after that some uploads are cherrypicked. But packages that have ubuntu changes can be ahead or behind debian,
<xnox> and merged when developers see fit / need / or have time.
<xnox> thebwt, further reading is at: https://wiki.ubuntu.com/UbuntuDevelopment https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#SyncingAndMerging
<thebwt> xnox: but https://launchpad.net/ubuntu/wily says derived from stretch
<thebwt> reading
<xnox> thebwt, that field is meaningless. where we sync packages from is what matters. It's mostly a thing used to generate useful debdiffs between packages and a "stablish" debian branch to make static debdiffs from.
<infinity> thebwt: Read that with a grain of salt.  We always set that to the current "testing", and it detemines where LP decides to generate some deltas from, but our actual imports happen from sid.
<xnox> if all packages, from all ubuntu releases debdiff against sid.... the diffs will have little meaning.
<thebwt> makes sense
<thebwt> thanks guys, chart just exploded
<thebwt> :p
<xnox> infinity, https://wiki.ubuntu.com/DebianImportFreeze is telling lies
 * xnox edit.
<infinity> xnox: Is it not the nature of documentation to be full of lies?
<xnox> thebwt, https://wiki.ubuntu.com/DebianImportFreeze updated with slightly less lies.
<thebwt> should have asked here instead of google....
<teward> infinity: OK, just making sure i don't have to beat my system into submission
<teward> cyphermox: regarding what I think was a question to me, it happens right after the schroot tries to double check if it's up to date.
<teward> but as infinity says it's mostly harmless, and nothing else seems to be broken... :p
<cyphermox> yeah
<cyphermox> I never noticed it ;)
<teward> ... well, except my packages, of course, 'cause i made a typo in a patch :/
<infinity> cyphermox: You've never noticed it because your host system is an up to date xenial, probably.
<cyphermox> yeah mostly up to date
<infinity> And we don't see it on LP because we don't do the fiddly update-databases-from-the-host-system thing there.
<teward> as long as it doesn't break anything (it appears to just be a warning), I guess I don't have to wrry about it
<teward> though I'll be testing the output packages anyways ('cause testing a package before submitting it as a merge)
<mterry> bdmurray, you probably want to add ~maas-devel to your package-subscribers script
<gQuigs> how do I tell a package not to build for [!s390x] architecture?  (seems like both gnome-shell and network-manager-gnome do this, but I can't figure out how..)
<seb128> gQuigs, no they don't?
<seb128> https://launchpad.net/ubuntu/+source/gnome-shell/3.18.2-0ubuntu2/+build/8374520
<seb128> n-m-applet is blocked on libappindicator to be available
<seb128> which is blocked on the mono transition
<xnox> which is in a landing silo, which still ftbfs on s390x due to dbus test suite error
<xnox> and yes mono
<xnox> gQuigs, please do not do !s390x unless you are building i386 specific bootloader code =)
<xnox> gQuigs, it should not matter at all, why do you care? is something blocked for you?
<xnox> in practice s390x build-failures do not matter most of the time, at the moment, unless it's a real regression.
<gQuigs> xnox: yea, I did a bad sync request - https://bugs.launchpad.net/ubuntu/+source/meta-gnome3/+bug/1523657
<ubottu> Launchpad bug 1523657 in meta-gnome3 (Ubuntu) "Sync meta-gnome3 1:3.14+3 (universe) from Debian unstable (main)" [Wishlist,Fix released]
<gQuigs> trying to fix it
<xnox> (or entangled in funny ways)
<xnox> gQuigs, i think it should not have been synced.... it's not only a problem on s390x.... http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#meta-gnome3
<gQuigs> it usedto specify [amd64] [other archs]. but since s390x is the only one that's failing
<xnox> gQuigs, it's uninstallable on _all_ architectures in ubuntu.
<xnox> gQuigs, i think you should copy that output back to the bug report, and ask release/archive admins to remove that sync from -proposed.
<gQuigs> xnox: right I missed three on all archs, but those can be fixed by a new merge right?
<gQuigs> (libreoffice-evolution, iceweasel, and vino)
<xnox> gQuigs, yes, and the rest will be available on s390x eventually. So just leave it as is for me to clean up.
<xnox> gQuigs, it will be stuck in -proposed for a while, but it's better that way, and spares me finding all the places people did !s390x, or rather explicit arch list and re-enabling it back later.
<xnox> s390x is circa 80% built now, so soon thse high level things will be installable too.
<gQuigs> xnox: makes sense I guess, the same status as much of the stuff under it... I should still do a debdiff for the stuff broken on all archs though right?
<xnox> gQuigs, yes (libreoffice-evolution, iceweasel, and vino) should be still fixed, as those are not in ubuntu and probably will not be ever (if i recall correctly it's intentional delta for us)
<gQuigs> k, will do, thanks!
<mitya57> pitti, the autopkgtest triggers display is *awesome* :)
<rharper> rbasak: looking at that libnl3 bug and patches, I see that it has a debian/patches dir, under which it has another debian dir (with patches, so debian/patches/debian/XXXX.patch)  ; quilt will apply (pop and push) those patches, but when the last patch is applied, quilt diff still shows a delta;  adding a new patch results in diffs being added to the previous patch (even though I've already quilt new/quilt add file.c)
<rharper> ... first time seeing that sort of patch setup; what am I missing ?
<rbasak> rharper: it looks like it's regular quilt, just with patches that have debian/ prefixed to it.
<rbasak> rharper: try popping all patches and adding a new patch and also to the series file manually, maybe, and see if quilt accepts that?
<rharper> rbasak: yeah; I just can't figure out why when I quilt new mypatch; quilt add path/to/file; apply diff, refresh
<rharper> it captures the new changes into the previous patch
<rharper> ok, I can try manually
<rharper> just very strange behavior, but also the first time I've seen subdirs of patches (though that really shouldn't matter)
<rbasak> rharper: I'm not sure. I've seen subdirs before and they've worked transparently. I don't see anything here that might cause the specialness you're seeing here.
<rharper> =(
<rharper> probably a PEBCAC but figured I'd ask
<rbasak> rharper: you're right to ask. There are many historical variations on patch mechanisms that we see from time to time.
<rharper> pop'ing all and applying at the start seems to work, good new is that the subdir of patches are all build file changes, so no chance of collision
<rharper> but I am still somewhat concerned that I have to do it this way
 * rharper will try out on a clean env instead of laptop
<rharper> rbasak: it appears the suggested fixes won't cleanly apply and look like it depends on some newer changes to the repository that aren't present in the version in trusty (library symbol linker scripts as well as a capabilities system).  Is it reasonable to ask the submitter to look at modifying the changes to work with the older version ?
<bdmurray> mterry: maas-maintainers seems like a better team (more canonical / likely to be responsible) than maas-devel
<mterry> bdmurray, well I didn't decide which to subscribe...  But I could imagine an argument for devel watching bugs rather than the smaller maintainer team...
<rbasak> rharper: I think so, yes. Certainly with an Ubuntu hat on
<rbasak> rharper: it's still valuable to have found that and put it in the bug though, thanks. It means that they understand what they need to do, rather than think that they're blocked on our sponsorship.
<rharper> rbasak: ok, then I'll update the bug with my analysis and request that submitter look at modifying changes to work with the version in trusty
<mterry> bdmurray, but I'm just the messenger here.  I can ask if they want to reconsider on the bug
<rbasak> rharper: great. Thanks!
<rharper> rbasak: yep
<rbasak> rharper: did the principle of the patch itself look OK to you, OOI? I was a little dubious.
<rharper> rbasak: it *looked* OK, but it had enough extra non-obvious math that I was going to have to write test cases
<rbasak> OK. It seemed to me to be far too much complexity. There should be a better way.
<bdmurray> mterry: what is the bug?
<rharper> honestly, the psuedo random selection in the array seemed overly complicated
<rharper> but it's gone upstream (still scary)
<mterry> bdmurray, bug 1522182
<rbasak> I wonder if there's a much simpler fix that could fix their use case.
<ubottu> bug 1522182 in python-petname (Ubuntu) "[MIR] python-petname" [High,Fix committed] https://launchpad.net/bugs/1522182
<rharper> rbasak: indeed
<rtg> infinity, apw mentioned last week that you and/or doko were working on the compiler bug that I'm seeing with build a v4.4-rcx arm64  kernel. Any updates ? https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+build/8438034/+files/buildlog_ubuntu-xenial-arm64.linux_4.4.0-0.5_BUILDING.txt.gz
#ubuntu-devel 2015-12-15
<teward> so, is Lua 5.1 going to continue to be in 'main' in Xenial or are there plans to make it Universe or something going forward?
<doko_> teward, any action on demoting this would be appreciated
<teward> doko_: the reason I asked is because nginx-extras will lose a feature I know a ton of people use
<teward> i think that and Apache were reasons for it staying in Main with 14.04
<sarnold> "ton"? :)
<teward> sarnold: substantial percentage of people using nginx
<teward> exact # unknown, but i've posed questions to the world 'bout the lua dropping and it was met with negativeness
<sarnold> teward: interesting. I still haven't run into any mentions of it casually..
 * teward yawns
<teward> sarnold: your name isn't on the 'last uploaded by' field
 * teward gets a lot of emails :/
<sarnold> hehe
<teward> point not withstanding
<teward> if lua 5.1 is demoted, it drops from nginx as a build dep
<teward> which means dropping Lua module in the universe packages
<teward> which I don't particularly mind (Lua module users have the PPA which isn't bound to the Main restricts)
<teward> but while i'm stabbing the merge right now... :P
<teward> thought i'd ask about the state of lua 5.1 and whether dropping is planned by 16.04 release
<teward> (dropping from Main, that is)
<sarnold> teward: obligatory reminder, please keep http/2 off for now..
<teward> sarnold: ack
<teward> sarnold: note that the SPDY users will hate you and the Sec team for that
<sarnold> I'd really rather that code have a few more eyes and fuzzers thrown at it before we throw it live into an lts :)
<teward> since there's no SPDY in nginx
<sarnold> I know, heh
<teward> sarnold: um... you were here for the Tech Board meeting right?
<teward> sarnold: by release it'll be near the 1.9.x branch, with 1.10.x as an after-release update
<sarnold> but I feel marginally good about getting SPDY removed from libmicrohttpd before that moved to main..
<teward> at least, as it was discussed with the TB before the "SRU" changes
<teward> HATE my laptop >.<
<sarnold> but I feel marginally good about getting SPDY removed from libmicrohttpd before that moved to main..
<teward> sarnold: perhaps you, me, and rbasak should butt heads before I upload
<sarnold> teward: yeah, I know it's not ideal, but turning it on via sru feels much better to me than shipping with it on before the start :)
<teward> 'cause I understand the Sec Team's opinion, but the users will kill me :P
<doko_> tedg, seriously, can you remove the dependy on lua5.1?
<doko_> teward, ^^^
<teward> i reiterate: hate hate hate hate HATE my laptop sometimes
<teward> doko_: not without dropping the Lua module from nginx-extras
<teward> which rbasak and i have argued about in the past
<teward> namely with the impending liblua5.1 'demotion'
<teward> doko_: doesn't address the Apache dependency though
<teward> doko_: if it's an 'order from above' I'll drop the Lua 5.1 dep
<teward> but it's getting a release notes notice
<teward> sarnold: i'll drop HTTP2 support then
<teward> sarnold: it's your fault i now have to maintain even *more* of a delta
<sarnold> teward: sorry...
<teward> until 1.10.x
 * teward yawns
<sarnold> teward: but thanks for that :)
<teward> sarnold: also not my fault Debian enabled it
<sarnold> it makes perfect sense for it to be enabled in e.g. debian unstable, debian testing, etc. maybe a bit premature for a debian-stable..
<teward> (the HTTP/2 stuff also is getting a release notes note too, I believe)
<sarnold> sure, feel free to blame us if it helps :)
<teward> sarnold: well, there's a backports-failure problem there
<teward> sarnold: my mind's on low-coffee mode
<doko_> teward,we should resolve to at least two lua versions for xenial
<teward> send me $5, coffee will be in my system, and the blaming goes away
<teward> doko_: what's currently in Main then for Xenial, 5.1 and 5.2?
<teward> (I remember 5.2 was a headache at 14.04 because it's essentially a different beast)
<doko_> teward, it would be 5.3 and another version
<doko_> currently we have three, 5.1, 5.2 and 5.3
<teward> doko_: has the Apache package managed to resolve the liblua5.1 depends, or dropped Lua entirely?
<teward> doko_: the reason I ask that is the initial "Lua 5.1 dependency" issue was in a bug against both
 * teward digs it up
<teward> ... it'd help if Chrome weren't slow
<teward> and my computer didn't hard-reboot on me
<teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1324062
<ubottu> Launchpad bug 1324062 in nginx (Ubuntu) "No lua 5.2 support" [High,Triaged]
<teward> doko_: that's got an nginx and an Apache message
<teward> filed by rbasak of course
<teward> it looks like Apache's resolved it
<teward> or not
<teward> doko_: the options for nginx are "keep lua5.1 or drop Lua module"
<doko_> teward, lua is insane, so getting everything to 5.3 would be preferred. if that's not possible, have *one* legacy version
<teward> it's a third party module
<teward> doko_: 5.1 would have to be the legacy then, if only to satisfy Apache and nginx headaches
<teward> but here's the real reason my options are "Drop Lua module" or "Convince 5.1 to be kept": https://github.com/openresty/lua-nginx-module/issues/343
<teward> the third-party authors have "Won't Fix"'d the "Support 5.2+" thing
<doko_> teward, so what needs to be done to remove 5.2?
<teward> doko_: nothing
<teward> at least, not from me
<teward> nginx doesn't depend on 5.2
<teward> doko_: nginx-extras and the Lua module depends on 5.1
<teward> so if 5.1 is the legacy version kept, then I don't have to do anything
<teward> and then I get concerned at 18.04 or next LTS about 5.1 dying
<teward> i would check the Apache deps though
<teward> they may need 5.2
<teward> doko_: the question is, do we keep 5.1 or 5.2
<teward> and if the answer is 5.2, then nginx-extras (universe) loses the Lua module
<teward> and a notice goes out to those users to switch to the PPAs instead
<teward> sarnold: oh, i reminded myself, any chance the SRU to turn on HTTP/2 can go out as a sec update as well as SRU?  Odd request, but the reason I ask is that 1.10.x is supported when 1.9.x is 'dead' come 1.10.x's release and SRUing
<teward> sarnold: those who only use the security repos in addition to the base main repos would miss
<sarnold> teward: though missing it would be part of the reason for sticking with -security rather than -updates :)
<teward> sarnold: well, you have two issues then:
<teward> (1) HTTP/2 is never available
<teward> (2) last minute fixes between 1.9.x final and 1.10.x which could be security in nature are missed
<teward> and esp. if dynamic module support becomes a thing then that's seriously missed
<teward> (and a major hell-hole is opened)
<sarnold> teward: if there's bits in #2 that justify an update, then it could be included
<doko_> teward, I disagree, please see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
<Unit193> Didn't you just claim a lot of the users use the PPA anyway?
<teward> Unit193: 14.04 users, mostly
<teward> Unit193: because it's outdated in the repos
<doko_> teward, I don't care about 5.1/5.2
<teward> doko_: what do i look for under the mismatches
 * teward isn't pro at reading yet :/
<doko_> teward, getting 5.1 or 5.2 demoted
<sarnold> doko_: there are no references to "5.2" in that file and the only references to "52" appear unrelated (a52dec, golang-gettext)
<doko_> sarnold, teward: "appear unrelated", please can you explain?
<teward> doko_: wasn't sure what you wanted me to look for is all
 * teward yawns
<teward> though sarnold knows more about that file
<teward> i don't see Lua 5.2 in there though
<teward> nor 5.1
<sarnold> doko_: I do not know how a52dec or golang-gettext are at all related to lua 5.2.
<teward> and the only Lua stuff I see there is libluajit
<teward> which isn't a factor in nginx (and dropped actually during the merge)
<teward> (though Debian has that for one of the 'rare' arches)
<doko_> sorry guys, I'm afk. will look at that tomorrow
<sarnold> night doko_ :)
<teward> 'night
<teward> sarnold: build-testing the no-http2 stuff now
<teward> and in other news my hands hurt
<teward> sarnold: mind doing me a favor by the way and state it's a Sec Team mandate on the merge bug to disable HTTP/2
<teward> (https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1510096)
<ubottu> Launchpad bug 1510096 in nginx (Ubuntu) "Please merge 1.9.6-2 (main) from Debian Unstable (main)" [Wishlist,In progress]
<teward> that way if users complain I point there
<teward> ehh, nevermind, i'll add it myself
<sarnold> done
<teward> oop speed is speed xD
<teward> that works
<teward> though SPDY is *gone*
<sarnold> yay :)
<sarnold> heh
<teward> been gone since HTTP/2 was introduced
<teward> sarnold: i'm ACKing that but adding in a note on SPDY.  I assume we'd be OK with HTTP/2 being enabled in 1.10.x when it lands, SRU or otherwise?
<sarnold> teward: preferable 1.10.1 or .2 :)
<teward> ok
<teward> ehh
<teward> sarnold: i question that, because theres zero guarantee of a 1.10.1
<teward> consider the current stable branch
<teward> 1.8.0 has received no updates, bugfixes, etc. since April release
<sarnold> hmm. that's either really good or really bad :)
<teward> and in April 2016, it gets torpedoed
<teward> and the next stable is released
<teward> sarnold: indeed, this was brought up in the TB discussion as well
<teward> sarnold: security patches can probably be done easily
<sarnold> If my pessism is correct, there'll be a .1 :)
<teward> but that doesn't resolve the number of 16.04 LTS users who are going to be "Hey, where's HTTP/2?"
<teward> (and after 16.04 release, I'll be pointing at the Sec Team, and saying "all complaints to there")
<teward> or rather, the users will
 * teward yawns
<teward> i need to stop working on this at some point, i've been working on this since 11AM :/
<teward> sarnold: i think Stable only gets fixes if there's a huge security hole that needs patching, or a major bug
<teward> but I can pass that to NGINX and ask
<teward> (or you can, if you can get LinuxJedi when he's around xD)
<rbasak> doko_: AIUI, 5.1 and 5.2 are essentially different incompatible languages. Like Python 2 and Python 3. Or so I've been told.
<rbasak> doko_: I understand that you don't want to maintain 5.1 and 5.2 and 5.3. That's reasonable.
<rbasak> doko_: but OTOH pushing upstreams to move up is difficult because of the backwards incompatibility.
<rbasak> doko_: I think Ubuntu should pick one, file bugs with upstreams as needed, and then drop support if that version is not supported by upstream.
<rbasak> doko_: I don't think the latest is necessarily the right one to pick though. The most commonly supported version is maybe a better criterion.
<doko_> rbasak, I agree, so should it be 5.1 or 5.2?
<rbasak> doko_: I don't know enough about lua or what upstreams support to answer that unfortunately.
<rbasak> doko_: whatever we pick, I'd like a researched statement to point people to if they complain about lack of support.
<rbasak> Eg. (I'm making this up) "lua 5.1 was supported by A, B and C upstreams, but not D, lua 5.2 was supported by X, Y and Z, so we decided to go with 5.1 to maximise upstream support, and your upstream lost out, sorry".
<teward> oh hey rbasak is alive
<sarnold> I haven't heard of any complaints about migrating from 5.2 to 5.3. I think people have the emotional attachment to 5.1 and want to keep that one.
<teward> rbasak: check PMs
<teward> sarnold: actually, 5.1 -> 5.2 is like dealing with almost completely different languages, from the Lua coders I know when I posed them that question
<teward> (they use Lua for a lot of things, not just nginx)
<sarnold> I just don't htink anyone would cry about losing 5.2. They're either on 5.1 or they paid the price and moved forward, and moving again to 5.3 is probably no big deal.
<teward> +1 for sarnold's interpretation here
<rbasak> sarnold: the trouble is that we have to pick one version for all upstreams in main. If the upstream doesn't happen to support that (too new or too old for them) then that's unfortunate.
<rbasak> Eg. a diligent upstream could have moved to 5.3 and dropped support for anything older.
<rbasak> And we might end up with only 5.1 in main.
<sarnold> rbasak: both 5.1 and 5.2 are in main from T through X
<sarnold> rbasak: 5.3 is in main since W
<sarnold> rbasak: doko wants at most two :) I think 5.1 and 5.3 would please maximal number of people, but you're right, some research would be worthwhile.
<rbasak> sarnold: we can arbitrarily change that for X though, if doko agrees. Eg. if we decide 5.1 is best, then we could just ship 5.1 in main in X.
<sarnold> rbasak: heh, in the case that 5.2 and 5.3 basically killed the lua community?
<rbasak> I get the impression it's just fragmented a little. The lua use case doesn't need to stick to one version across all projects that use lua.
<rbasak> But general distributions do need that.
<rbasak> So that comes down to "if you want general distros to ship projects with lua support, then move together, otherwise we'll be forced to pick for you".
<rbasak> MOre specifically, this applies to Ubuntu with a main/universe distinction. But Debian probably doesn't want to release three at once either.
<sarnold> "we're sorry your upstreams pulled a python"
<rbasak> I don't think it's quite the same. We'd have to compare to projects using libpython for it to be a fair comparison.
<doko_> rbasak, teward: any foreward progress on 5.1 and any of 5.2 or 5.3?
<teward> doko_: zero for the nginx lua module
<teward> upstream's outright rejected the notion
<teward> for going off of 5.1
<teward> rbasak has better gauge of the state of Server in general
<rbasak> doko_: I'm not aware of any progress whatsoever. I'm not interested in pushing upstreams either though. I'm happy with going with the popular choice and dropping lua support at build time for any upstreams that don't support that choice.
<teward> ^ that's my opinion as well
<pitti> Good morning
<alkisg> Good morning
<alkisg> pitti: Hi, I'm around if you need any more feedback or vnc for https://bugs.launchpad.net/bugs/1492546
<ubottu> Launchpad bug 1492546 in systemd (Ubuntu) "Systemd runs ifdown on shutdown even when it shouldn't" [Medium,Triaged]
<pitti> alkisg: thanks for the journal, looks good now!
<pitti> alkisg: I'll ponder that
<alkisg> Thank you
<dholbach> good morning
<xnox> Laney, i wonder if i broke transition tracker
<xnox> Laney, nah, all is good.
<xnox> jodh, morning =)
<ginggs> pitti: good morning. i'm having issues with julia autopkgtest again. amd64 is good now, but i386 has a regression (it runs, but very slowly) that might only be fixed by a new llvm. is it possible to disable autopkgtests for i386, or forget that it was ever successful?
<pitti> ginggs: we can do the latter, yes; or it needs a sourceful upload to skip the test on i386, but I guess we rather want to avoid introducing a delta for that
<pitti> ginggs: indeed, 5h 42??
<pitti> ah, that's a regression from the new julia or from the toolchain?
<ginggs> pitti: both, apparently
<juliank> pitti: The apt tests work on ppc64el and s390x now and those could be enforced now - the armhf and i386 ports have some timing issues (probably too slow)
 * juliank is not sure if they were automatically ignored, if there was a setting to ignore !amd64 architectures, but anyway: ppc64el and s390x works now, and we should ensure that they remain that way.
<pitti> juliank: they are automatically enforced -- once they succeed on an architecture, they must continue to succeed
<juliank> Ah OK
<pitti> juliank: i. e. we differ between "always failed" (which is not blocking) vs. "regression" (which is blocking)
<pitti> juliank: and track that per-architecture
<juliank> pitti: But only within in release series, right, because other archs also worked in vivid, for example.
<pitti> ginggs: but if that's an actual regression on i386, wouldn't it be right to hold it back until this gets fixed?
<pitti> ginggs: if julia is awfully slow on i386, that's a real problem, not just a test problem?
<pitti> juliank: for wily->xenial we enforce it across the release, but we didn't retroactively do that for vivid
<juliank> OK
<pitti> juliank: so in general we do, just not vivid as we only set up that whole cloud testing system during wily
<juliank> So if I understood things correctly, apt uploads need to be manually accepted right now, because one reverse dep (sbuild) currently fails the test suite (listed as Regression)
<pitti> juliank: right; or more precisely, we ignore test failures of the current version of sbuild
<juliank> OK. BTW, The python-apt and autopkgtest tests tmpfail on s390x currently
<juliank> W: Target Sources (restricted/source/Sources) is configured multiple times in /etc/apt/sources.list:6 and /etc/apt/sources.list.d/proposed.list:2
<juliank> and other warnings
<pitti> juliank: yes, I just saw, I'm looking at that now
<pitti> ah, bad container, fixed now
<pitti> next britney run will re-trigger all the bad ones (http://autopkgtest.ubuntu.com/status/alerts/)
<ginggs> pitti: yes, it is a real problem, not just a test problem, but i don't believe it is much of a problem - i don't think think many people are doing serious julia work on i386, and if you use it interactively the regression is not noticeable
<LocutusOfBorg1> hi cjwatson, syncpackage ghc?
<cjwatson> LocutusOfBorg1: not worth the build time right now
<cjwatson> LocutusOfBorg1: will do it sometime when it isn't going to get in people's way
<LocutusOfBorg1> ack sure
<pitti> xnox: btw, amd64 finished yesterday, do the stats look better  now?
<xnox> pitti, yes they do =) thank you
<Mirv> xnox: hey! bzoltan_ has a s390x linker issue he doesn't know how to resolve, and it's a regression so he'd ask for removal of the ubuntu-ui-toolkit s390x from archives if there's no quick solution. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-060/+build/8438344
<bzoltan_> Mirv:  thanks
<xnox> bzoltan_, if you have issues, you can talk about them yourself here, no? =)
<bzoltan_> xnox:  I am not brave enough :)
<xnox> bzoltan_, i don't bite  =))))) too hard.... ;-)
<bzoltan_> xnox: I am more araid of the smiling hunters :)
<bzoltan_> afraid I mean
<xnox> warning: libUbuntuGestures.so.5 .... not found
<xnox> looking where it should come from.
<cjwatson> Mirv: is it OK if I remove qtenginio-opensource-src?  removed from Debian, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802788
<ubottu> Debian bug 802788 in ftp.debian.org "RM: qtenginio-opensource-src -- ROM; Deprecated, not used" [Normal,Open]
<Mirv> cjwatson: yes, that's what I tried to ask at bug #1512737
<ubottu> bug 1512737 in qtenginio-opensource-src (Ubuntu) "RM: qtenginio-opensource-src" [Undecided,New] https://launchpad.net/bugs/1512737
<xnox> but it is there.... ln -s libUbuntuGestures.so.5.5.0 libUbuntuGestures.so
<cjwatson> Mirv: ah, thanks - done
<Mirv> cjwatson: thank you
<xnox> Mirv, bzoltan_ it seems like libUbuntuGestures.so* are placed into ./lib/ at the top level of the build dir, yet linker -Llib/ is not specified?!
<bzoltan_> xnox:  would that fix the issue?
<xnox> bzoltan_, it should. this doesn't look like an arch specific issue at all, and just a generic typo/error somewhere in the build system. I want to pop out for lunch, but then i can spin a build of this on s390x (i have access) and check what's going on.
<xnox> how it build on other arches is what gets me wondering. unless something else is going on.
<Laney> xnox: ok to re-merge mono?
<Laney> seems quick enough
<pete-woods> pitti: do you know how long I should expect to wait for dbusmock 0.16.3 to migrate into xenial?
<pitti> pete-woods: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-dbusmock
<pitti> pete-woods: it's currently blocking on unity-scope-click regression on armhf; I  already retried it twice
<pete-woods> dammit
<pitti> pete-woods: ah, last retry actually succeeded, so next britney run should get it
<pitti> and promote it
<pete-woods> pitti: awesome, thanks!
<pitti> pete-woods: it only got autosynced into xenial this morning
<pete-woods> seems reasonable to ignore that failure anyway
<pete-woods> those errors pretty clearly look unrelated
<Laney> having a shoddy baseline means you have to repeatedly make that kind of assessment
<Laney> would be better to tests to be reliable
<pete-woods> yeah
<pete-woods> they aren't mine
<pete-woods> my tests do not print out 6k lines of errors
<Laney> "Failed" :P
<xnox> bzoltan_, Mirv, sil2100 - builds fine https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/8442437 http://paste.ubuntu.com/14026402/
<xnox> i would have expected that any of you could read the original build log failure, that a library was not found and add it to be linked in.
<pitti> pete-woods: just landed
<pete-woods> pitti: awesome, thanks!
<pete-woods> can re-enable my functional tests in my silo now :)
<sil2100> xnox: I have no context regarding that
<xnox> sil2100, earlier bzoltan_ & Mirv complained about s390x build failure as seen in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-060/+build/8438344 when in fact it has a trivial fix that anybody should be able to do.
<xnox> sil2100, shouldn't build-failures like that be noticed quickly? (especially since it happened like 4 minutes after the upload)
<sil2100> xnox: well, I'm not involved in that silo and I don't really scan all silos for build failures, that's up to the lander to take care of that ;)
<jdstrand> pitti: hi! I uploaded libseccomp yesterday. it showed a ppc64el lxc regression and an i386 systemd regression. looking at them, I don't think the failures are related to the upload
<Mirv> xnox: all I know is that bzoltan_ was hitting a similar issue on other archs earlier but the trick they did for that did not help on s390x
<Mirv> xnox: it's great if there's a solution that works on s390x too
<xnox> Mirv, i wonder what they have done on other arches.... the error is that library foo is required for a test, but has not been linked the same way all other libraries were linked. see the one-line diff i pasted.
<seb128> mdeslaur, hey, is https://bugs.launchpad.net/ubuntu/+source/libjpeg-turbo/+bug/1518035 on your merges list?
<ubottu> Launchpad bug 1518035 in libjpeg9 (Ubuntu) "package libjpeg-progs 1:9a-2ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/djpeg.1.gz', which is also in package libjpeg-turbo-progs 1.3.0-0ubuntu2" [High,Confirmed]
<mdeslaur> seb128: it's not, no
<seb128> :-(
<seb128> mdeslaur, it has your name on https://merges.ubuntu.com/main.html ... ;-)
<mdeslaur> seb128: see "please take" comment on the right
<seb128> oh, right
<seb128> :-(
<mdeslaur> seb128: someone needs to investigate why we've diverged from debian, and then do a whole transition for it
<seb128> I guess we should at least backport the Conflicts for that files conflicts
<seb128> even if we don't update nor merge
<xnox> pitti, halo =) koonnen sie bitte autopkgtest im English benutzen? =)
<xnox> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/j/juju-core/20151215_104022@/log.gz
<xnox> pitti, ich liebe alle "Lese Datenbank" =)
<pitti> xnox: bah -- that must be ssh again, forwarding my host's locale to the remote
<pitti> what a silly anti-feature
<pitti> xnox: I guess that locale further made it into the container
<Laney> haha
<Laney> we should keep it that way
<xnox> pitti, das ist normal. Aber, Ich kann nich verstehen was is loss mit http://autopkgtest.ubuntu.com/packages/j/juju-core/xenial/s390x/ =(
<xnox> pitti, koonen sie bitte dass noch ein mal gefahren?
<pitti> xnox: ah, missing universr
<pitti> xnox: yes, I'll rety; I think I fixed that this morning
 * xnox wonders if pitti, doko, mvo, dholbach find my german funny at all =)
<pitti> xnox: it is indeed! :-)
<pitti> xnox: it's really good enough to comprehend, but funny all the same
<Laney> ich verstehe alles!
<dholbach> xnox: haha, great :)
<ginggs> pitti: it appears here http://autopkgtest.ubuntu.com/packages/j/julia/xenial/i386/ that julia 0.4.2-3 built on i386, but that was actually 0.3.12-2ubuntu1.  Am i just reading that wrong?
<xnox> didrocks, no comment on this bug https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1521984 -> so it's perfect right?! =)
<ubottu> Launchpad bug 1521984 in s390-tools (Ubuntu) "[MIR] s390-tools" [Undecided,Confirmed]
<pitti> Get:27 http://ftpmaster.internal/ubuntu xenial-proposed/universe i386 julia i386 0.4.2-3 [3,767 kB]
<pitti> ginggs: ^ what do you mean? seems the version was correct
<didrocks> xnox: I think doko told he had time to do some MIR
<didrocks> xnox: but don't worry, you have enough to do to fix the others first :p
<didrocks> s/to do//
<xnox> didrocks, true that
<pitti> jdstrand: hey! Looking
<pitti> jdstrand: the three nspawn tests failed on i386, which do use seccomp, and there's an error message: Failed to add audit seccomp rule: Bad address
<pitti> jdstrand: so it's by far not obvious that this is unrelated
<pitti> jdstrand: (it rather looks quite relevant)
<pitti> jdstrand: lxc has failed on ppc64el for a while, so we can ignore that indeed
<pitti> jdstrand: I'll run it locally and investigate
<pitti> jdstrand: ah, indeed it has started failing 4 days ago already, so it's not that; I'll wave it through then
<xnox> pitti, so are we building lxd images for s390x? and what needs doing to achieve that? or shall i talk to stgraber about it? are they built in launchpad?
<pitti> xnox: no, stgraber having access to an s390x machine, stgraber, no
<pitti> xnox: for bug 1524618 I created an LXC container with the "ubuntu" template (i. e. debootstrap), created the metadata manually, and imported the image into lxd
<ubottu> bug 1524618 in lxd (Ubuntu) "please add support for s390x" [Wishlist,Fix released] https://launchpad.net/bugs/1524618
<pitti> xnox: that works fine, it's just a bit elaborate to do, particularly as you'd need to do it every day
<pitti> (can certainly be automated, though)
<pitti> xnox: lxd can use two ready-made types of images -- the ones on http://images.linuxcontainers.org (built on stgraber's linuxcontainers.org infra) and our regular cloud images
<pitti> xnox: but neither are available for s390x so far
<xnox> pitti, we have dev machines ready... which i can do stuff on. e.g. build images and publish them.
 * xnox kind of likes lxd too.
<pitti> xnox: yeah, me too; it so rocks on btrfs
<pitti> and image handling, transparent caching etc. make it really simple to use
<xnox> pitti, and zfs will make it soooo much better =)
<pitti> xnox: lxc does seem to support zfs indeed
<pitti> I haven't tried that yet, though; I think the jump from ext4 to btrfs is quite a bit more interesting than btrfs â zfs, from my POV
<jdstrand> pitti: thanks! yes, it wasn't obvious to me either for the i386 one. there were other errors around the seccomp bad address one, so I wasn't sure if it was cascading failures, etc. thanks for the archaeology and accepting it :)
<pitti> jdstrand: so the i386 seccomp regression is in xenial already, I reproduced it without -proposed
 * jdstrand nods
<pitti> jdstrand: I'm now downgrading stuff step by step to see what broke it
<jdstrand> cool
<pitti> i. e. it's a real regression, not just a test issue
<ginggs> pitti: i see Get:26 http://ftpmaster.internal/ubuntu xenial/universe i386 julia i386 0.3.12-2ubuntu1 [2,935 kB] - this is where it says version 0.4.2-3, triggers mpfr4 3.1.302
<pitti> ginggs: ah right, for other triggers it'll run against the xenial-release version, as 0.4 isn't in -release yet
<pitti> ginggs: the bug there is that it runs the tests from the 0.4.2 *source* package (from -proposed) against the 0.3 binary packages in -release
<pitti> ginggs: that's known, and this needs working around in apt as apt pinning doesn't apply to source packages
<ginggs> pitti: ok, thanks
<jamespage> !regression-alert
<ubottu> bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<jamespage> bug 1526271 - the recent SRU to 14.04 for haproxy introduced a regression where the return code from the init script is now always 0
<ubottu> bug 1526271 in haproxy (Ubuntu Trusty) "Could not patch cib; leading to no haproxy running" [Critical,Confirmed] https://launchpad.net/bugs/1526271
<jamespage> not great when other tools rely on return codes being lsb compliant :(
<jamespage> working a fix now
<jamespage> thats and interesting list of people...
<pitti> jamespage: so a quick followup SRU should be fine for that, right? it's been out in the wild for 6 days already, and fixable with another update, so I don't think that warrants pulling the update from teh servers
<jamespage> pitti, agreed - its pretty much a one line change to resolve
<pitti> bdmurray: ^ maybe you can reset its propgagation percentage to 0%?
<pitti> jamespage: ack, so let's get that in ASAP and release tomorrow after testing?
<pitti> i. e. 0.5 or 1 day instead of 7
<jamespage> pitti, ack
<jamespage> pitti, fix uploaded to trusty-proposed - bug updated with reproduction details.
<jamespage> only impacts trusty - all other releases got a better version of the fix....
<jamespage> caribou, hey - just so you are aware ^^ ;-)
<caribou> jamespage: thanks!
<apw> cjwatson, hey, britney is saying (cached yaml here: http://paste.ubuntu.com/14028195/) that arm64 has old binaries, but it does not have any up to date binaries so it should be saying that... confused ?
<cjwatson> apw: which source?
<apw> cjwatson, sorry, linux itself
<apw> cjwatson, which would have been at -4.13 at the time, and failed utterly to produce anything on arm64: https://launchpad.net/ubuntu/+source/linux/4.3.0-4.13/+build/8427529
<xnox> apw, hence my earlier comment about linux[-meta] on #ubuntu-kernel. it is rather confusing. i believe there was an intermittend build that was hence superseeded, but never migrated to -release pocket that is still visible. or some such.
<xnox> apw, linux-meta is 4.3.0.2.5 in release, and 4.3.0.5.6 in proposed, yet there was a successful build 4.3.0.2.4 of arm64 in -proposed.... which didn't get removed. huh, should it not have had migrated to release and be removed (?!)
<xnox> something is really odd.
<xnox> apw, i think we simply need to ask AAs to purge stale arm64 things from -proposed.
<cjwatson> apw: that seems normal if there was a previous unmigrated thing in -proposed
<apw> cjwatson, but for it to complain about cruft it should think there are builds for arm64 in there at the source package version it is expecting "uptodatebins = True" as it were
<coreycb> cjwatson: there are several openstack packages in universe that I work on frequently but I can't upload.  any chance they could be seeded somehow so that I can upload them with my ubuntu server per-package upload rights?
<cjwatson> coreycb: not up to me
<apw> xnox, yes, we have NBS in there, i am happy it is complaining about that indeed, but i am not expecting it to tell me about NBS it finds if there are no uptodate binaries, that overrides the cruft complaint
<cjwatson> apw: err possibly?  that code is deeply twisty
<xnox> coreycb, please email to developer membership board to grant upload rights and/or update seeds.
<apw> yeah, its like the epochroful maze and no mistake
<xnox> coreycb, do you know where to send such request?
<cjwatson> apw: some time since I stared at it in any depth
<coreycb> xnox, ok yeah I can figure that out
<cjwatson> apw: the NBS of linux-source-4.2.0 that hasn't yet been removed due to build-dep from user-mode-linux may not be helping
<xnox> coreycb, https://wiki.ubuntu.com/DeveloperMembershipBoard devel-permissions@lists.ubuntu.com list will used. Check out archives for previous requests about it.
<cjwatson> apw: indeed that may be the main problem here
<xnox> coreycb, or if you are ready, apply to become a MOTU =)
<apw> cjwatson, yeah, prolly not worth thinking too hard on.  it probabally needs debugging one time it is in that state, but i just uploaded over it :)
<coreycb> xnox, thanks
<coreycb> xnox, that's an option :)
<apw> cjwatson, ahh thanks
 * apw puts that on the list of things which are broke
<pitti> apw: argh, that's what we get with ignoring REGN.. bug 1526358 :(
<ubottu> bug 1526358 in systemd (Ubuntu) "xenial/i386 regression: nspawn fails with "Failed to add audit seccomp rule: Bad address"" [High,Triaged] https://launchpad.net/bugs/1526358
<pitti> apw: i. e. on i386, 4.3 broke something in linux-libc-dev wrt. seccomp
<pitti> apw: not sure if that affects lxc as well, but at least lxd is using seccomp too
<pitti> jdstrand: ^ FYI, I bisected the change, it was the new linux-libc-dev (see bug)
<pitti> jdstrand: so if you hear about seccomp trouble on i386, it's likely that
<jdstrand> pitti: yeah, just finished reading the bug. nice triage work
<jdstrand> apw: also, fyi, seccomp is used on snappy, but i386 aren't official
<pitti> there's now an < 1 s reproducer,  but unfortunately it involves building systemd
<apw> pitti, though to be fair we started ignoring it because it was a networkd thing, which we thought was fixed
<pitti> apw: it's not networkd, it's nspawn, i. e. containers
<pitti> I added a comment how to build systemd in the minimal time
<apw> pitti, right, i assume that is the boot-and-services test failure ?
<pitti> apw: yes, I know, I'm certainly guilty of ignoring it too :) (just saying)
<pitti> apw: yes, that's part of it
<pitti> apw: but in the bug I have a simple copy&paste 1 second reproducer which doesn't involve autopkgtest
<apw> pitti, as that got away i think because networkd was fail in the previous one, and then got fixed and at the same time boot-and-services went fail
<pitti> apw: yeah, probably that
<apw> pitti, so i thkn that means we should have marked the the first one "fixed" so it was ignored
<apw> pitti, or rerun it so it went green, and then it would have stopped us correctly
<pitti> apw: so, this isn't critical for sure, so we might even have landed the kernel if we had known about it before
<pitti> but it's a nice exercise to improve our process
<apw> pitti, oh yeah, absolutly, but i want to figure out how we should have reacted to have caught it, that indeed
<coreycb> hello, any chance an archive admin can drop python-cryptography 1.1.1-1ubuntu1 from proposed?  we've changed our mind on how we want to handle it.
<bdmurray> pitti: only archive admins, which I'm not, can set the phased-update-percentage
<bdmurray> pitti: the change-override script allows one to set the percentage
<infinity> bdmurray: What need PuPing?
<infinity> s/need/needs/
<bdmurray> infinity: haproxy for trusty see bug 1526271
<ubottu> bug 1526271 in haproxy (Ubuntu Trusty) "Could not patch cib; leading to no haproxy running" [Critical,In progress] https://launchpad.net/bugs/1526271
<infinity> bdmurray: Looking.
<infinity> bdmurray: Oh.  It's not even in proposed yet.
<infinity> A bit of gun-jumping on phasing. ;)
<bdmurray> infinity: I think jamespage was saying 1.4.24-2ubuntu0.3 is bad.
<infinity> bdmurray: Oh, you want to phase .3 to 0?  Check.
<infinity> Well.  Not that it will matter.
<infinity> haproxy is a server thing, who runs update-manager on servers?
<infinity> We really just need to push the next one through ASAP.
<jamespage> ha
 * infinity goes to review it.
<infinity> jamespage: Is this tested for sanity?
<infinity> jamespage: Accepted, if you can get it tested ASAP and let me know, I can release and phase it to 100.
<jamespage> infinity, ack - thanks
<TJ-> Anyone familiar with PAM? I'd like some confirmation that on user logout close_session should be called for "common-session", specifically for pam_exec ?
<seb128> TJ-, slangasek or robert_ancell might be able to help you
<TJ-> seb128: thanks :)
<slangasek> it's up to the PAM application to make sure it calls close_session().  But any session modules configured for the service, and that were called for open_session, should also be called for close_session.
<seb128> barry, bug #1526450 seems a regression from your apt-xapian-index update
<ubottu> bug 1526450 in apt-xapian-index (Ubuntu) "/usr/sbin/update-apt-xapian-index:ImportError:/usr/sbin/update-apt-xapian-index@104:setupIndexing:__init__:__init__:load_source:_load:_load_unlocked:exec_module:_call_with_frames_removed:/usr/share/apt-xapian-index/plugins/software_center.py@13:/usr/share/software-center/softwarecenter/db/update.py@33:/usr/share/software-center/softwarecenter/backend/scagent.py@26" [Undecided,New] https://launchpad.net/bugs/
<barry> seb128: thanks, will investigate
<seb128> yw!
<nagromlt> channel for audio help?
<seb128> barry, Trevinho, also https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1526455 seems a regression from the recent landing/python3 port
<ubottu> Launchpad bug 1526455 in unity (Ubuntu) "/usr/bin/unity:TypeError:/usr/bin/unity@205:run_unity:process_and_start_unity:match" [High,New]
<Trevinho> seb128: yes
<Trevinho> seb128: i can't reproduce that locally though... Maybe cmdline is containng something weird
<seb128> Trevinho, I can reproduce here
<Trevinho> seb128: me too now
<seb128> what did you change? ;-)
<Trevinho> seb128: i was debugging that, and I was using a bad cmdline definition
<seb128> k
<xnox> stgraber, can i trigger image builds via iso tracker? and i would like to be able to do so for server/s390x
<TJ-> slangasek: thanks. I was helping a user and suggested using pam_exec in common-session and it only receives open_session, never close_session. I've tested it on 15.10 and confirmed the same thing. auth.log shows the open_session, as does the program being executed, but as I say, no sign of close_session
<Trevinho> seb128: for your pleasure https://code.launchpad.net/~3v1n0/unity/unity-script-fix-byte-regex/+merge/280624
<seb128> Trevinho, looks fine to me but I would prefer for barry to ack it as well, python encoding issues are always confusing to me
<TJ-> slangasek: so we have "session optional        pam_exec.so debug /bin/bash /usr/local/bin/pam_exec_test.sh"  with the script just doing "env >> /tmp/pam_exec.log" and we never see anything else other than "PAM_TYPE=open_session"
<barry> Trevinho: can you provide some context for this change?
<barry> ah, LP: #1526455 probably
<ubottu> Launchpad bug 1526455 in unity (Ubuntu) "/usr/bin/unity:TypeError:/usr/bin/unity@205:run_unity:process_and_start_unity:match" [High,In progress] https://launchpad.net/bugs/1526455
<seb128> barry, right
<Trevinho> barry: yeah, that it
<barry> Trevinho, seb128 remind me where /usr/bin/unity comes from? ;)  i think the patch is good, but i want to understand why cmdline is a bytes
<barry> "comes from" in lp:unity
<nagromlt> help with audio?
<barry> ah, found it
 * barry will comment on the mp
<nagromlt> or audio help channel?
<geofft> nagromlt: try #ubuntu
<nagromlt> geofft: thx
<xnox> Mirv, bzoltan_ you did see my pastebin debdiff, right? i didn't hear anything back, but my irc was cut off.
<bzoltan_> xnox:  sorry mate, I was dead busy with other stuff.. reading now
<xnox> bzoltan_, you asked for a quick fix and i provided one in like less than an hour....
<bzoltan_> xnox:  I do not see any pastebin debdiff
<xnox> bzoltan_, xnox> bzoltan_, Mirv, sil2100 - builds fine https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/8442437 http://paste.ubuntu.com/14026402/
<xnox> bzoltan_, that's url to a build log and a diff.
<xnox> bzoltan_, e.g. a test file tries to link with a library, that depends on UbuntuGestures and was not found.
<bzoltan_> xnox:  that looks logical indeed
<xnox> bzoltan_, it's located in $top/lib dir, which is not specified in linker flags.
<xnox> bzoltan_, it's a perphaps new dependency, which should be added to be linked with.
<bzoltan_> xnox:  I will put it to our staging and land it with the next round
<xnox> maybe there is some other location for it, but it seems to be moved to $(top)/lib anyway, so used that.
<xnox> bzoltan_, your package will not migrate.
<xnox> bzoltan_, i have it fully built for xenial, in a devirt ppa on all arches.
<xnox> bzoltan_, https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/8442437
<xnox> sorry
<xnox> https://launchpad.net/~xnox/+archive/ubuntu/nonvirt
<xnox> you may copy from there....
<bzoltan_> xnox: I have a QA granted landing silo ready to migrate... I think it is smartet to integrate this fix with the next landing
<bzoltan_> xnox: plus I have no power to copy these fine packages to the landing silo
<xnox> i can.
<xnox> bzoltan_, but as you wish.
 * bzoltan_ admires people with power :)
<xnox> bzoltan_, it's just we will not remove binaries for s390x. and your xenial packages will be stuck in xenial-proposed.
<xnox> at which point i will copy my build over into xenial-proposed only, to get it to migrate.
<bzoltan_> xnox:  sounds good
<xnox> but then, it will not be binaries that were tested from the silo.
<xnox> which is a tradeoff we have to take.
<xnox> cause removing s390x binaries will cause caos, as loads of things have built and depend on it already on s390x =/
<bzoltan_> xnox:  fine... it will be only a temp issue... as I am lanidng this fix on Thursday
<xnox> bzoltan_, ack.
<bzoltan_> xnox: https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/link_Gestures_more_explicitely/+merge/280630
 * xnox chuckles at review type
<tkamppeter> morphis, hi
<tkamppeter> morphis, sorry.
<tkamppeter> morphis, are you doing Ubuntu Phone stuff?
<RobertDupont> hello guys
<RobertDupont> not sure if it's the right channel but I'm working with the alpha iso of 16.04 and for some weird reason, I can SFTP to the machine but not SSH (command line)
<RobertDupont> on a stock ssh config
<RobertDupont> is it on purpose or not?
<sarnold> RobertDupont: what error messages do you get? check both client and server..
<teward> RobertDupont: i can't replicate and my 16.04 ISO I used was from yesterday's 'current' folder, though with a server iso.  do you get any kind of error when you try and SSH in ?  (on either side)
<teward> blah
<teward> oh sarnold good you're alive
<sarnold> rumours of my death are greatly exaggerated
<RobertDupont> sarnold: no error message on the client. It times out after some time
<RobertDupont> I'm using VMware if that's any useful and 16.04 fails but 14.04 works fine
<RobertDupont> I can give you pcap done from the server if it helps
<RobertDupont> I can make connections no problem from that machine, update, do whatever that requires network
<teward> RobertDupont: i've got a VMware Workstation here, i wasn't able to replicate either
<teward> i'll re-zsync down to test with a new ISO, but meh
<RobertDupont> I got 'kex protocol error' in the logs, let me google that
<RobertDupont> looks like my client is too old (even though I updated recently)
<RobertDupont> let me try updating it
<teward> RobertDupont: what's the system you're SSHing from?
<teward> what version?
<teward> (I'm 14.04 if it matters)
<RobertDupont> from Win7, using putty
<RobertDupont> Apparently, I'm using a snapshot version from last year
<teward> eww
<RobertDupont> I guess the installer failed to update it :/
<teward> potentially
<RobertDupont> updating it worked
<RobertDupont> sorry for the trouble
<teward> no problem :)
<teward> i need the updated ISO anyways :)
<RobertDupont> thanks for your help
<teward> you're welcome
<teward> i should note that my ISO didn't update openssh either, so it went KABLOOEY.  Though, my VMs get managed by Landscape anyways so... :P
<teward> (daily security update application schedule, is nice)
<RobertDupont> I wish I could justify buying Landscape
<RobertDupont> I managed to get to a point where I barely have to take care of my machines, automatic updates has been working flawlessly
<teward> doko: did
<teward> oops
<teward> doko: not sure if the discussion resolved, did the Lua legacy version issue ever get determined?  I went offline before I could see a resolution
<teward> (just checking)
<morphis> tkamppeter: yes
<tkamppeter> morphis, how can I let cups-browsed have different default settings (in /etc/cups/cups-browsed.conf) on the phone and on the desktop?
<morphis> tkamppeter: add an .override to lxc-android-config
<morphis> tkamppeter: you're in DE, right?
<tkamppeter> morphis, I am in Brazil.
<morphis> ah
<morphis> tkamppeter: like you did here https://code.launchpad.net/~till-kamppeter/lxc-android-config/cups-override
<morphis> tkamppeter: lets talk tomorrow, I am on the way
<tkamppeter> morphis, a .override allows me to apply another method to start a daemon, but not to use a modified config file. What I need is that on the phone /etc/cups/cups-browsed.conf gets the lines "IPBasedDeviceURIs IPv4" and "CreateIPPPrinterQueues Yes" added.
<morphis> ah I see
<tkamppeter> morphis, where are you located?
<morphis> DE
<tkamppeter> morphis, which city?
<morphis> lets talk tomorrow, we could also talk quickly on an hangout tomorrow
<morphis> close to Bremen
<tkamppeter> morphis, cu tomorrow.
<morphis> cya!
<tkamppeter> On a merge proposal I got the answer "Review: Approve; LGTM but needs proper landing through the citrain", what do I have to do now?
<sarnold> what's the tag to prevent proposed->released migration in xenial?
<doko> teward, no, we should continue that discussion early next year
<teward> ok
<Logan> sarnold: block-proposed
<sarnold> Logan: thanks
#ubuntu-devel 2015-12-16
<mwhudson> er so i'm having a problem with schroot
<mwhudson> basically i can't expire sessions
<mwhudson> http://paste.ubuntu.com/14042611/
<mwhudson> running "fuser /var/lib/schroot/mount/xenial-amd64-52371fd8-4124-4584-a4ca-f53d43284765/home/mwhudson" shows the same output as "fuser /home/mwhudson"
<sidi> Got an Autotools toolchain that works perfectly on Arch, but not on Ubuntu, need help figuring it out... Basically doing PKG_CHECK_MODULES in configure.ac, AC_SUBST my CFLAGS and LIBS variables, then assigning them in Makefile.in and adding the assigned vars to my CFLAGS and LDFLAGS. I have one sub-dir for which LDFLAGS dont work. No apparent typo in the Makefile... How can I debug that?
<pitti> Good morning
<dholbach> good morning
<pitti> apw: I further bisected bug 1526358 down to a single new line in a kernel header, a new syscall definition; I followed up with everything I can squeeze out of that with my puny little non-kernel developer brain
<ubottu> bug 1526358 in systemd (Ubuntu) "xenial/i386 regression: nspawn fails with "Failed to add audit seccomp rule: Bad address"" [Medium,Triaged] https://launchpad.net/bugs/1526358
<pitti> jdstrand, apw: I analyzed that further, I now have a tiny standalone .c file and some explanations; its' somewhere between libseccomp and the kernel
<apw> pitti, ack
<apw> pitti, ok these calls did not exist as separate system calls before 4.3, it seems sockets can be either exposed via socketcall multiplexed call or individually, and we switched to exposing them all to allow seccomp mediation
<apw> pitti, i've put the details in the bug
<pitti> apw: ah, so the x0xFFFFFF9B value before, was that a code for "does not exist", and thus seccomp filtering of socket() was simply ignored before?
<apw> pitti, when i say i have added it to the bug, i have not because LP is broke
<pitti> apw: did your comment time out? mine currently do, maybe LP upgrade going on
<pitti> snap :)
<apw> pitti, and now it is in ok
<apw> pitti, yes literally before htere was socketcall(CONNECT, ...) instead, so no seccomp interaction at all
<apw> pitti, so this could easily be a bug in either the kernel or library
<alkisg> bdrung, bdrung_work_, hi, if it isn't too much trouble for you, could you send a build for adblock/xenial in the xul-ext ppa? thank you!
<pitti> apw: splendid, thanks!
<cjwatson> dannf: did you notice that it looks like your {vivid,wily}-proposed grub2 changes were dropped in the security update?  you'll need to rebase those
<bdrung_work_> alkisg, done:  adblock-plus 	2.6.10+dfsg-1~ubuntu16.04.1~ppa1 uploaded
<alkisg> Thank you very much bdrung_work_ :)
 * alkisg has installed 16.04 to some schools in order to help iron out all the bugs in time, and adblock plus is vital there
<henrix> pitti: can i get some vivid kernel tests re-run? run-autopkgtest -s vivid -a i386 --trigger linux-meta/3.19.0.41.40 glibc
<pitti> henrix: sure! started
<henrix> pitti: thanks
<pitti> update-initramfs: Generating /boot/initrd.img-4.3.0-2-generic
<pitti> sed: can't read /usr/share/plymouth/themes/.plymouth/.plymouth.plymouth: No such file or directory
<pitti> E: /usr/share/initramfs-tools/hooks/plymouth failed with return 2.
<pitti> didrocks: ^ does that ring a bell?
<pitti> Laney: ^ (current mass-killing of workers)
<Laney> pitti: oh noes
<Laney> I didn't see that, did it just happen?
<Laney> oh yeah, here it is
<Laney> plymouth/.../.plymouth/.plymouth.plymouth his a great path
<Laney> s/his/is/
<apw> pitti, that looks a bit like a theme name of .plymouth was used
<seb128> Laney, pitti, should we remove that version from proposed?
<Laney> I have no idea, sorry
<seb128> oh, not in proposed anymore
<seb128> so ignore that
<pitti> it only started today, so it wasn't didrocks's initial merge from last week
<seb128> might be today's update?
<pitti> ah, we got https://launchpad.net/ubuntu/+source/plymouth/0.9.2-3ubuntu6
<pitti> it went through as the only direct rdepends lightdm is "always failed"
<apw> pitti, i am guesing that "update-alternatives --query text.plymouth" is returning ""
<apw> pitti, which the hook script does not handle
<Unit193> Also, maintscripts didn't take care of /etc/init/plymouth*
 * pitti kills the looping lightdm test
<apw> pitti, which could occur if the alternative does not exist at all
<apw> pitti, thogh quite why either would be missing, is a bit of a mystery
<apw> pitti, i guess it should have osmething like this http://paste.ubuntu.com/14048328/ as protection
<Saviq> pitti, hey, could I ask you to restart the failed qtmir-gles autopkgtest in https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-021/excuses.html
<pitti> Saviq: done
<pitti> Saviq: in http://autopkgtest.ubuntu.com/running.shtml#queue-xenial-amd64 now, there's some queue
<Saviq> pitti, thanks! is there a way to restart those that does not involve you having to press dumb buttons?
<Saviq> pitti, ack
<pitti> silos are eating up a looot of resources, look at the vivid queue
<pitti> Saviq: not at the moment, needs someone with access to snakefruit (cjwatson,seb128,doko,pitti,adconrad,vorlon,didrocks,stgraber,laney)
<Saviq> pitti, thanks (and sorry everyone for triggering a mass-ping ;)
<pitti> Saviq: it's planned to supporting restarting tests via some web UI, but that needs SSO etc. (which I'm not familiar with at all)
<Saviq> ack
<Saviq> pitti, this is AWESOME, btw, thanks!
<pitti> :)
<apw> pitti, i presume the git.l.n daemon must do all of the same authentication you need to do ... and as you are aqpm based a separate daemon service would work at least
<pitti> apw: I don't know how this works really, but I assume I'd have a web service on autopkgtest.u.c. which does SSO auth, checks whether the user is able to upload that package, and if so triggers an AMQP request with its internal creds?
<apw> pitti, i suspect you'd not do SSO but do LP auth and let it do SSO for you, as you need to ask about upload rights
<pitti> apw: ah, or that
<cjwatson> apw: git.l.n isn't a good example for this :)
<apw> pitti, though in practice they may be essentially the same for you
<apw> cjwatson, damn :)  it seemed like it had the same relationship
<cjwatson> apw: and no, you would do SSO directly
<cjwatson> apw: the LP bits here AIUI can be done anonymously anyhow
<cjwatson> apw: and even if the LP calls in question required auth, that would be auth with a different principal
<cjwatson> apw: git.l.n is different because (a) it's a privileged service and talks to a special internal port for some of its stuff (b) while the HTTPS frontend does do SSO, it's probably not good example code unless you're already using Twisted
<apw> cjwatson, well here we need the very simplest daemon that can verify you and send a message to aqpm, so i guess anything close is a good example
<cjwatson> pitti,apw: you'd normally just use the openid auth support in whatever framework you're using, e.g. django-openid-auth or flask.ext.openid, pointed at https://login.ubuntu.com/
<cjwatson> the LP username will be one of the things you get back
<cjwatson> https://git.launchpad.net/turnip/tree/turnip/pack/http.py is an example of doing it mostly by hand within Twisted, but like I say you probably don't want to do that :)
<pitti> cjwatson: I don't really have a framework ATM, debci is just using some ruby scripts to generate the .html pages via scripts, but the web frontend is all plain html
<pitti> cjwatson: which one would you recommend?
<didrocks> pitti: hum, can be my update from today, which is weird, I tried multiple scenarios for 30 minutesâ¦
<didrocks> pitti: do you have the version and can add set -x to it?
<didrocks> so, default config works, I tried as well to create dangling symlink by renaming text.plymouth and default.plymouth (each at a time and then both)
<didrocks> so it's at least not the scenarios I tested, I would like to have a little bit more info about the config when this happens (probably a wrong sed substitution)
<cjwatson> pitti: I'm the wrong person to ask for that I'm afraid :)  flask is probably reasonably decent at keeping mostly out of your way
<didrocks> (I'm pretty sure http://paste.ubuntu.com/14048715/ is the correct fix to avoid theme copy loop, but I would prefer to confirm it by reproducing it first)
<pitti> didrocks: so far I've only seen it in test logs, but from there it should be easy enough; hang on, still dealing with something else, sorry
<pitti> didrocks: so similar in spirit as apw's http://paste.ubuntu.com/14048328/ ?
<didrocks> pitti: no worry! I tried (the change was to handle that) to mv /etc/alternatives/{default;text}.plymouth
<didrocks> pitti: well, apw's change isn't fixing it
<didrocks> because update-alternatives return "none" as a Value when it's a dangling or unconfigured symlink
<didrocks> but that's handled a little bit below in the hook as well, that's why I want to reproduce if possible
<apw> didrocks, right we could only get this issue if there are no alternatives so there is no Value: in the output
<apw> didrocks, then we do "basename .plymouth" and that returns .plymouth and we get the error
<didrocks> apw: is that different from mv /etc/alternatives/default.plymouth /etc/alternatives/default.plymouth.old for instance?
<didrocks> (as it's what I tested)
<apw> didrocks, i am assuming like the output you get with --query foo
<apw> essentially with the error redirect that can be empty
<pitti> didrocks: hm, I don't get it with naively installing plymouth-theme-ubuntu-text and dist-upgrading from ubuntu5 to ubuntu6
 * pitti tries the other way around
<didrocks> apw: ah, interesting, indeed, update-alternatives is using something else as a base
<pitti> didrocks: ah no, the test log shows that it was upgraded
<pitti> Unpacking plymouth-theme-ubuntu-text (0.9.2-3ubuntu6) over (0.9.2-3ubuntu5) ...
<didrocks> apw: as mv /etc/alternatives/default.plymouth /etc/alternatives/default.plymouth.old -> --query show Value: non
<didrocks> "none"
<didrocks> which is handled
<didrocks> but if I --query foo, I see it's empty
<didrocks> anyway, my patch should work (and can fix other weird case as well as being more correct)
<didrocks> let me try it quickly
<didrocks> apw: ok, your fix enables to go back to my default error handler and so protect against the empty variables. I reproduced locally and uploading it, thanks!
<didrocks> pitti: sorry for the bother in the test bed
<didrocks> (I also tried only corrupting one alternatives, and the other is still generated)
<didrocks> I will now have a look why removing/renaming the symlinks gives different results for update-alternatives than using a non existing one (like "foo")
<pitti> didrocks: no problem at all! they are there to be wedged :)
<pitti> didrocks: many thanks for fixing!
<didrocks> pitti: the positive side of -3ubuntu6 is that I hope to go to +100 lines diff in the hook with debian to 2 lines! :)
<didrocks> (I basically refactored the hook to be useful to them)
<pitti> wow
<rbasak> pitti: please could you take a look at bug 1509816?
<ubottu> bug 1509816 in init-system-helpers (Ubuntu) "Upgrade from 14.04 to 15.04 missed systemd-sysv and init package init 1.22ubuntu11 failed to install/upgrade: pre-dependency problem - not installing init" [Undecided,Confirmed] https://launchpad.net/bugs/1509816
<pitti> rbasak: looking
<pitti> rbasak: duped to bug 1032823
<ubottu> bug 1032823 in lvm2 (Ubuntu) "package libdevmapper-event1.02.1 2:1.02.48-4ubuntu7.1 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,Confirmed] https://launchpad.net/bugs/1032823
<pitti> I've seen reports about this a couple of times, I never saw it myself, though
<pitti> rbasak: i. e. dmsetup -> libdevmapper -> libcryptsetup4 -> systemd-sysv -> init dependency chain/error chain
<rbasak> pitti: thanks!
<rbasak> pitti: that's 19 reports in total now. There must be some pattern we don't know about :-/
<pitti> rbasak: oh, it's a circular dependency
<pitti> Package: libdevmapper1.02.1
<pitti> Depends: dmsetup
<pitti> Package: dmsetup
<pitti> Depends: libc6 (>= 2.14), libdevmapper1.02.1 (>= 2:1.02.107)
<pitti> why would the library depend on the binary??
<pitti> that can't be right, so perhaps if we drop the former to Recommends: or drop it entirely?
<rbasak> Is that a bug in Debian too?
 * pitti adjusts the bug prio and targets to xenial
<pitti> rbasak: yes, it is
<pitti> debian bug 586424
<ubottu> Debian bug 586424 in dmsetup "dmsetup has circular Depends on libdevmapper1.02.1" [Normal,Open] http://bugs.debian.org/586424
 * pitti links
<pitti> Bastian's explanation is bogus, though; merely having the library installed should not imply any udev action etc.
<pitti> rbasak: I followed up on the Debian bug
<pitti> rbasak: I'm not very hopeful, though -- we've been carrying fixes for obvious and trivial bugs (with patches in the BTS) for 5 years or longer
<pitti> didrocks: ok, the error message changed: http://paste.ubuntu.com/14050068/ but ubuntu7 is still failing :(
<pitti> didrocks: so /etc/fonts/fonts.conf is coming from fontconfig-config
<pitti> didrocks: but indeed I don't see any fontconfig* package in the package list
<pitti> didrocks: should plymouth depend on fontconfig-config, or just not cp the file if it's absent?
 * pitti hugs didrocks
<pitti> Laney: FYI, I temporarily disabled xenial autopkgtesting due to that, so that it can at least catch up with vivid
<didrocks> pitti: noooooooooooooooooooooooooooooooooooooooooooo
<didrocks> pitti: what is this config where you have one "graphical" plymouth theme and not those debian packages?
<rbasak> pitti: thanks
<didrocks> pitti: I wouldn't be against knowing what the installed list of packages and what's configured the alternative in such a way
<didrocks> even plymouth-label seems to be missingâ¦
<didrocks> from the warning
<didrocks> pitti: the thing is: it seems that no theme is installed (as label.so module isn't there) and so the dep isn't matched. Would be better to understand what theme is configured for it (and so, goes into that path)
<pitti> didrocks: it's based on the cloud images, let me try to reproduce locally
<pitti> didrocks: I have libplymouth4, plymouth, and plymouth-theme-text installed, nothing else
<didrocks> pitti: ok, let me try in parallel then
<pitti> didrocks: and the only '*font*' match is fonts-ubuntu-font-family-console
<didrocks> plymouth-theme-text shouldn't go into that code patch
<didrocks> path*
<pitti> didrocks: ah, I just reproduced the 0ubuntu6 failure
 * pitti tries to apt-get update harder
<pitti> didrocks: standard off-the-shelf "adt-buildvm-ubuntu-cloud" image, btw
<didrocks> ah, I think the adt image is bigger
<didrocks> weirdâ¦ mine is maybe modified
 * didrocks trashes it and builds one
<pitti> didrocks: sorry, plymouth-theme-ubuntu-text, not plymouth-theme-text
<didrocks> ahah!
<didrocks> that starts to make more sense :)
<didrocks> so yeah, the patch needs to be different, I guess we don't need any of those fonts in that case
 * didrocks looks
<tkamppeter> morphis, hi
<pitti> didrocks: I grabbed the three binaries from https://launchpad.net/ubuntu/+source/plymouth/0.9.2-3ubuntu7/+build/8447092
<morphis> tkamppeter: hey!
<pitti> didrocks: and dpkg -i over ubuntu5 reproduces this
<didrocks> pitti: mind (my image is still downloading), changing line 109 in /usr/share/initramfs-tools/hooks/plymouth
<didrocks> it should be:
<didrocks>     text|details)
<didrocks> and replace with:
<didrocks>     ubuntu-text|text|details)
<tkamppeter> morphis, my last question was: A .override allows me to apply another method to start a daemon, but not to use a modified config file. What I need is that on the phone /etc/cups/cups-browsed.conf gets the lines "IPBasedDeviceURIs IPv4" and "CreateIPPPrinterQueues Yes" added.
<pitti> didrocks: still the same, fails on missing /etc/fonts/fonts.conf
<didrocks> ok, let me download
<pitti> didrocks: that's precisely the code which does the cp -a /etc/fonts/fonts.conf "${DESTDIR}/etc/fonts"
<didrocks> pitti: yeah, but it shouldn't reach itâ¦ this is the weird part :)
<pitti> didrocks: oh, sorry, no -- the line you changed short-circuits that
<pitti> I missed the ;;
<didrocks> and THEME_NAME is supposed to be empty in that case
<didrocks> oh
<didrocks> it is empty
<didrocks> so goes to *)
<pitti> didrocks: $THEME_NAME is empty
<didrocks> I bet!
<pitti> yes
<didrocks> making sense then :)
<pitti> didrocks: I just added an echo
<didrocks> phew
<didrocks> so yeah, we need to go to that "null" case when empty
<morphis> tkamppeter: ok, which daemon reads that config file?
<pitti> didrocks: restarting from scratch to verify
<pitti> didrocks: i. e. ""|text|details)
<didrocks> yeah
<tkamppeter> morphis, /usr/sbin/cups-browsed
<didrocks> pitti: I would still replace with ""|ubuntu-text|text|details)
<morphis> tkamppeter: can you pass the config file by with an argument?
<didrocks> pitti: imagine someone decides to set ubuntu-text as their primary theme (not the alternative text one)
<pitti> didrocks: what's weird is that the same code is already present in ubuntu5
<didrocks> and don't have any graphical theme installed
<didrocks> so no font
<didrocks> -> that could happen
<didrocks> pitti: yeah, the different is that I was exiting at the time
<didrocks> (way before)
<didrocks> so if you had a text theme
<didrocks> but not a graphical one set
<didrocks> -> no plymouth splash
<pitti>         ""|ubuntu-text|text|details)
<pitti> didrocks: ^ works
<didrocks> phew!
<didrocks> sorry *again* :/
<pitti> didrocks: don't be
<didrocks> pitti: let me upload with a good rationale in a sec
<pitti> didrocks: celebrate some fun with the devel series!
<didrocks> hehe :)
<tkamppeter> morphis, not yet, but I am upstream of cups-browsed, so I can add this functionality, I can also add the possibility to supply config options via the command line, something like "cups-browsed -c cups-browsed-alternative.conf -O IPBasedDevicURIs=Ipv4"
<morphis> tkamppeter: yeah, that would be the way to go
<morphis> tkamppeter: if you then have a touch specific config file we can add it + the .override to lxc-android-config
<tkamppeter> morphis, I will implement both methods, but probably use the "-o ..." method.
<morphis> ok
<morphis> tkamppeter: btw. I saw you did on MP for lxc-android-config
<tkamppeter> morphis, yes, and it got approved but I have a question now.
<didrocks> pitti: uploaded, I hope this is for good, this time :)
<tkamppeter> morphis, On a merge proposal I got the answer "Review: Approve; LGTM but needs proper landing through the citrain", what do I have to do now?
 * pitti hugs  didrocks
<morphis> tkamppeter: you know the citrain?
<tkamppeter> morphis, no.
 * didrocks hugs pitti back
<morphis> tkamppeter: the citrain is how we land things
<morphis> there is a full documentation on https://wiki.ubuntu.com/citrain/LandingProcess
<morphis> but it works basically like this:
<morphis> 1. Create a landing request on https://requests.ci-train.ubuntu.com/ and press "Assign"
<morphis> with that you get a silo (which is a specific ppa) assigned
<morphis> you need to add the link to the MP in the landing request
<morphis> 2. Build the silo, that will fetch the MP and build a package with that
<morphis> and then put everything into the silo your request has assigned
<morphis> 3. Test your silo
<morphis> 4. When you are done with that you can mark your landing request as "Ready for QA"
<morphis> then the QA guys will test your silo with the instructions you added to the request
<morphis> if the are fine with your change the citrain will automatically land the package
<morphis> the good thing for lxc-android-config is that the same change will land at the same time in xenial and our vivid overlay ppa
<morphis> generally a nice and easy process but with some details to respect :-)
<tkamppeter> So it needs all that work for such a tiny and obvious fix?
<morphis> tkamppeter: but in other words: nobody will merge your MP for lxc-android-config you have to get it merged with citrain through the process I've described above
<morphis> tkamppeter: it sounds more than it is
<apw> pitti, ok i think i have this systemd thing identified as an issue with libseccomp (being out of sync with the kernel) and am testing a patch to fix that now
<morphis> you get used to that and then it doesn't take much more time
<tkamppeter> morphis, is it the same procedure to get the printing stack included in the phone OS?
<apw> pitti, SCMP_SYS(socket) == 359 == 167
<apw> Success
<morphis> tkamppeter: to some degree, yes
<morphis> tkamppeter: all phones are currently running vivid + an overlay ppa
<morphis> so we're not landing anything in vivid through SRUs
<tkamppeter> morphis, what means "to some degree" here?
<morphis> so if you need a change there then you have to follow that way
<pitti> apw: \o/
<morphis> if you need a direct package upload to a silo then you can ask in #ubuntu-ci-eng for that
<morphis> tkamppeter: the very important aspect here is that QA must approve your changes which helps quite a lot to get the quality up
<tkamppeter> morphis, can I make one request called "Printing stack addition", containing the addition of all printing-related packages plus the current MP for cups.override plus another MP for the cups-browsed config?
<morphis> tkamppeter: sure
<apw> pitti, how does http://paste.ubuntu.com/14050659/ look to you
<morphis> tkamppeter: however one thing you need to respect:
<pitti> apw: urgh -- it looks to me like I don't want to read the other parts of libseccomp :)
<apw> pitti, oh please let me have that luxury
<pitti> apw: do they honestly re-hardcode every syscall? why doesn't that use the __NR_syscall macros?
<apw> pitti, anyhow seems to fix x86
<morphis> tkamppeter: we differentiate between dual-landings and one-distro-only landings
<pitti> apw: but in the context of the other declarations that looks fine; thanks!
<apw> pitti, yes they do, and then supply all sorts of fakers like for socketcall against socket/bind et al
<morphis> tkamppeter: so if you put just a cups package for vivid in the silo then you have to put a xenial one too
<pitti> apw: hang on before you upload -- "Add these to the 23bit x86 syscalls table"
<pitti> apw: please add 9 extra bits
<morphis> tkamppeter: or you do two silos: one for all dual landings, and one for the vivid-only stuff
<apw> which is what was tripping us up.  i suspect we (and they) could generate the lists
<apw> pitti, heh
<dannf> cjwatson: yeah i did, thanks!
<pitti> rbasak: I uploaded the lvm2 fix
<apw> pitti, applied
<tkamppeter> morphis, AFAIK printing should be added to the newest syystem, not backported, would then doing all this in Xenial be enough?
<morphis> tkamppeter: no
<morphis> tkamppeter: the phone will stay on vivid for still some time
<morphis> so if you want a feature be included in a phone update release you need to do it on both
<apw> pitti, anything else before i hit return ?
<pitti> LGTM otherwise
<apw> pitti, great, will do a couple more build tests and ram it in
<pitti> apw: it's not that easy to attach a versioned kernel dependency to it, which is the only other thing I can think about
<apw> pitti, no they have no meaning sadly
<apw> this means we are not backwards compatible for sockets for things built since NR_socket appeared in glibc
<pitti> apw: do you forward that to https://github.com/seccomp/libseccomp? or want me to help with that?
<apw> pitti, i have no idea how to forward it, but am happy to do so :)
<pitti> apw: normal github pull request, i. e. clone, apply, push your own branch, request a pull
<pitti> apw: as I said, I can help you with that (it'll keep your author information of course)
<apw> pitti, if yo uare all setup for that, then it might be easier if you do it :)
<apw> pitti, though i guess we should confirm this fixes systemd as well though i think it must
<apw> pitti, i guess we upload it and then do a couple --trigger test
<pitti> apw: I'll test it; but nspawn uses that exact code
<morphis> tkamppeter: but feel free to ask for help when you need it :-)
<pitti> apw: it should actually auto-trigger, as systemd-container depends on it
<pitti> ah, systemd itself too, as you can set seccomp restrictions in units
<apw> yeah and sa we are single kernleed in that series
<apw> as
<pitti> apw: https://github.com/martinpitt/libseccomp/commit/5a93300830
<pitti> apw: if that looks good to you, I'll create the PR
<apw> pitti, lgtm if you need/want an sob feel free to add
<tkamppeter> morphis, so it seems to be all dual-landing then. Can it be done all-in-one then?
<morphis> yeah
<pitti> apw: sligthly tweaked the commit message to say "Linux 4.3": https://github.com/martinpitt/libseccomp/commit/6dfabf20148
<apw> pitti, yep makes sense
<netbog> hello... how can i use qtquick to connect with mySQL db?
<rbasak> netbog: try #ubuntu-app-devel
<netbog> ok thank you
<sil2100> pitti: hey! :) So, I would like to properly add qml-module-qtbluetooth to the touch seeds - I saw you were the one removing them recently, are there any reasons besides invalid placement?
<sil2100> pitti: or is it ok for me to properly re-add those?
<pitti> sil2100: oh, I did? I guess as part of sponsoring?
<sil2100> pitti: not sure, it wasn't a merge... but maybe someone requested that ;) Anyway, re-adding those in the proper place as previously they were in the wrong section anyway
<sil2100> If you don't remember any reasons for not having those then all's good
<pitti> seb128: thanks
<pitti> err, sil2100: thanks
<pitti> seb128: thanks to you too, though, for taking care of the desktop! *hug*
 * seb128 hugs pitti back
<pitti> sil2100: no, I certainly don't touch (no pun intended) the touch seeds other than upon request
<seb128> my please!
<sil2100> ;)
<tkamppeter> morphis, thank you, so I will put one silo together which adda the printing packages, and does the changes on cups.override and cups-browsed.override, but first, I will release cups-filters 1.5.0 where cups-browsed takes alternative config files and options via command line.
<tkamppeter> morphis, WDYT?
<pitti> apw: ah, upstream responded to https://github.com/seccomp/libseccomp/pull/22 -- at least we did due diligence
<apw> pitti, yeah that souds like we have something which will work for us in the short term
<apw> pitti, and we can check back in a bit and get something which will suck less :)
<pitti> apw: yeah, the patch should just start to massively conflict once they fix it more properly, and until then it shouldn't be too hard to maintain
<apw> right exactly
<apw> and i think they need to fix it _soon_ for their own sanity
<morphis> tkamppeter: sorry, was distracted
<morphis> tkamppeter: sounds good to me
<tkamppeter> morphis, OK, thank you very much. I will contact you if I have further questions. Until when (due to EOV) I can find you here?
<morphis> tkamppeter: yes
<morphis> tkamppeter: I am working till 12/23
<tkamppeter> tkamppeter, OK.
<smoser> cjwatson, maas is now installing by default to lvm. and thus we're seeing https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1313784
<ubottu> Launchpad bug 1313784 in grub-installer (Ubuntu) "File descriptors leaked on lvs invocation" [Undecided,Confirmed]
<smoser> is that something we need to worry about?
<cjwatson> smoser: no, it's totally pointless whining from lvm
<smoser> would you care to comment in that bug to that affect ?
<seb128> bah
<seb128> my xenial vts are doing qwerty today
<seb128> is that a known issue? (not respecting locale keymap)
<cjwatson> smoser: done
<smoser> cjwatson, thank you.
<seb128> cyphermox, hey, is there any reason to keep building the n-m migration code? that was from < 0.9 updated and trusty already had 0.9 ... build with --disable-migration drops the gconf depends
<cyphermox> oh, by all means if that's the case it could be dropped
<seb128> cyphermox, yeah, I just tried
<cyphermox> cool
<seb128> Depends: [-gconf-service,-]
<seb128> , [-libgconf-2-4 (>= 3.2.5),-]
<seb128> cyphermox, should I do an upload for that?
<cyphermox> sure
<cyphermox> I don't really plan to touch NM soon
<seb128> cyphermox, done
<mdeslaur> cyphermox: your evil plan worked, you're no longer TIL on NM :)
<seb128> shrug, or not
<seb128> cyphermox, upload failed because you didn't commit https://launchpad.net/ubuntu/+source/network-manager-applet/1.0.6-2ubuntu3 to the vcs and I didn't check before
<seb128> shrug
 * seb128 does uncommit&wget&patch&override dance
<Laney> barry: any chance you could look at bug #1526267?
<ubottu> bug 1526267 in synaptic (Ubuntu) ".../softwarecenter/backend/scagent.py : no module named "spawn_helper"" [High,Confirmed] https://launchpad.net/bugs/1526267
<Laney> could be nothing but I have to go now
<Laney> sorry
<barry> Laney: i'll look
<teward> can someone help me figure out why there's an FTBFS on my latest nginx upload, for ppc64el?  https://launchpadlibrarian.net/230254441/buildlog_ubuntu-xenial-ppc64el.nginx_1.9.6-2ubuntu1_BUILDING.txt.gz
<rbasak> teward: I've not seen that before. See if it reproduces by hitting the retry button maybe?
<teward> rbasak: i think i saw that issue in the past, though it's been a while, and only ever once or twice in the PPAs...
<teward> but i've retried the ppc64el build for now
<teward> no others have sent me back "It Died" responses yet
<teward> arm64 and ppc64el are the last two to build, all others were successful :)
<teward> rbasak: retry worked.  :)
<teward> just waiting on arm64 to start :P
<rbasak> \o/
<pitti> Laney: FTR, xenial re-enabled, seems new plymouth is calm now
<blake_r> pitti: I got a systemd issue/question if you got the time
<sarnold> blake_r: pitti's probably going to see that message in nine or ten hours.. you're more likely to get a response "quickly" if you also include the question, so you don't have to wait another day to ask it when he says "yes" :)
<blake_r> sarnold: okay thanks for the info
<blake_r> pitti: this will give you the question and the context - http://paste.ubuntu.com/14055580/
<Unit193> Oh, crap.  Accidentally dput something without a target, thank goodness for autorejects!
<ancaemanuel> go 1.6 beta 1 will be released tomorrow, https://groups.google.com/forum/#!topic/golang-dev/6Ga5o2Ao2WM
<ancaemanuel> There are some really good improvemens on gc and runtime https://github.com/golang/go/commits/master
<ancaemanuel> Can you consider an ppa for testing this version in xenial ?
<ancaemanuel> sorry for my english...
<teward> is there any way to see a running autopkgtest on britney or no?  Asking because the link from the update_excuses page takes me to a page that doesn't list that package's autopkgtest
<ancaemanuel> teward: this is the page http://autopkgtest.ubuntu.com/running.shtml , and the system is not perfect yet. It requires a lot of manual intervention.
<teward> ancaemanuel: indeed.  seems the autopkgtests just move faster than I can get to them xD
<teward> unfortunately
<teward> but the ones i was caring about didn't fail, so at least I'm good there :)
<ancaemanuel> most of the work is done by piti http://status.ubuntu.com/ubuntu-x/
<ancaemanuel> more details here https://launchpad.net/~canonical-foundations/+upcomingwork
<ancaemanuel> is there an public link for RT#84348 ?
<ancaemanuel> anybody can explain what RT (in an bug description) means ?
<sarnold> ancaemanuel: "request tracker"
<sarnold> it's sort of like a bug tracker, but better suited to requests for services from IS staff
<hloeung> ancaemanuel: https://portal.admin.canonical.com/84348
#ubuntu-devel 2015-12-17
<ancaemanuel> hloeung: thanks... , permission denied for me.
<dx> hi, need some guidance to try to get a bug fixed in wily. the pidgin package has a patch for gstreamer 1.0 support with this bug: https://developer.pidgin.im/ticket/16752
<dx> the bug can be summarized as a crash after playing sounds 1000 times (which can be a few hours of receiving messages), so it's quite bad
<RAOF> dx: Sounds like a job for a StableReleaseUpdate!
<RAOF> https://wiki.ubuntu.com/StableReleaseUpdates being the relevant wiki page.
<dx> yup! the problem is that the first step says that i should ensure it's fixed in the testing version
<dx> ..does that mean i have to get it fixed in debian, then in ubuntu devel, and then do the SRU?
<RAOF> Doesn't have to be fixed in Debian (but it's nice to attach a patch to the relevant Debian bug)
<dx> awesome.
<RAOF> You should attach a fix for both the xenial and wily packages to the bug report, though.
<RAOF> (Assuming you need sponsorship. If you don't need sponsorship, upload a fixed package to xenial and then wily-proposed âº)
<dx> yeah i need sponsorship. the fix would be https://bitbucket.org/pidgin/main/commits/902b1fd334bd4d41ffd217fa4e6864629b7d3edc/raw/
<dx> i'll just ignore debian because pidgin 2.10.12 is going to be released very soon, which also includes the fix.
<dx> next question: this ticket describes the bug but it's a terrible ticket https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1479715
<ubottu> Launchpad bug 1479715 in pidgin (Ubuntu) "/usr/bin/pidgin:11:g_source_attach:gst_bus_add_watch_full_unlocked:gst_bus_add_watch_full:pidgin_sound_play_file:pidgin_sound_play_event" [Undecided,New]
<dx> do i create a new one or can i just edit that?
<RAOF> Edit that one.
<sarnold> try hitting the little yellow icon on the same horizontal level as 'bug description'
<RAOF> It's the one that's associated with the error bucket!
<dx> cool, thanks
<dx> okay i think i'm done https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1479715
<ubottu> Launchpad bug 1479715 in pidgin (Ubuntu) "Crash due to fd leak when playing sounds in pidgin" [Undecided,Confirmed]
<pitti> Good morning
<pitti> apw: \o/ http://autopkgtest.ubuntu.com/packages/s/systemd/xenial/i386/ is pass again
<pitti> blake_r: that's quite simple -- nobody actually starts that unit :)
<pitti> blake_r: it's actually a lot simpler than that; just put this "runcmd:" as the last thing in your cloud-init user-data:
<pitti> - (while [ ! -e /var/lib/cloud/instance/boot-finished ]; do sleep 1; done; shutdown -P now) &
<pitti> blake_r: this avoids all that indirection, does not depend on any particular init, and is much simpler
<pitti> blake_r: also, if you create temporary units, please put them into /run/systemd/system/, not /lib
<pitti> blake_r: merely creating a unit does not cause it to start -- something (a dependency from another unit) or someone (calling systemctl start) needs to do that
<pitti> blake_r: oh sorry, this isn't just cloud-init, it's maas
<pitti> blake_r: so, turn that dependency around -- drop the Wants=cloud-final.service and instead add [Install]\nWantedBy=cloud-final.service, then systemctl enable maas-poweroff.service
<pitti> blake_r: then maas-final.service will start maas-poweroff.service
<pitti> blake_r: but still, please put this into /run; it's dangerous to write it to /lib, you might forget to delete it after installation
<pitti> utlemming: can you please build a ppc64el xenial cloud image?
<pitti> stgraber: ^ reason for lxc/ppc64el regression, in case you wonder; I'll override
<dholbach> good morning
<pitti> infinity, cjwatson: do you know why this linux/amd64 upload got stuck in unapproved? (https://launchpad.net/ubuntu/xenial/+queue?queue_state=1)
<pitti> I suppose we have a special-case for kernels with signed EFI bits, to manually verify the upload
<pitti> but what am I supposed to verify for that?
<pitti> LP stripped off the gpg signature of the .changes file, so I can't verify that it was actually uploaded by Tim
 * apw believes it is the linux_4.3.0-5.16_amd64.tar.gz that is to be verified, that it only contains expected flavour .efi files, and that the kernel itself comes from a trusted source
<pitti> but I have no way to see which source it came from
<pitti> if it had rtg's gpg sig on the .changes, I could verify based on that I trust Tim
<pitti> but so far I just know that it was uploaded by a core-dev or someone with linux package upload rights
<cjwatson> pitti: the main point is just to stop arbitrary other packages being uploaded and gaining signatures
<pitti> cjwatson: ah, ok; so I know that the source (https://launchpad.net/ubuntu/+source/linux/4.3.0-5.16) was uploaded by Tim (assuming that this is the signature, not the Changed-By:), and that it's linux where we expect new signatures
<mardy> xnox: hi! I'd like to test a branch of libaccounts-glib on s390x; what would be the best way to do that?
<mardy> xnox: I could ask for a silo, but is it possible to limit the builds to one arch only?
<LocutusOfBorg1> can anybody please retry casablanca/arm64 on xenial?
<cjwatson> LocutusOfBorg1: done
<LocutusOfBorg1> thanks
<LocutusOfBorg1> nobody seems processing backports anymore :(
<LocutusOfBorg1> https://bugs.launchpad.net/wily-backports/+bug/1512982
<ubottu> Launchpad bug 1512982 in wily-backports "Please backport hedgewars 0.9.22-dfsg-2 (universe) from xenial" [Undecided,New]
<xnox> mardy, you can give me a *.dsc and i can build it for you. Or build it in a silo, as you normally would - it has s390x enabled.
<xnox> mardy, or e.g. a branch. where is it staged?
<mardy> xnox: excellent; now I've added a commit to the existing silo, but if I will want to build some really experimental branches, I'll ping you then :-)
<mardy> xnox: upstream is in gitlab.com, but we have bzr branches with debian packaging in lp
<mardy> xnox: so, if the need arises, I might ping you back in a while
<cyphermox> good morning!
<blake_r> pitti: thanks for the info I gave that a try still didnt work, but I am going to just have cloud-init poweroff the machine which I believe is the more correct way anyway
<pitti> blake_r: right, and much simpler too, if you don't have to do anythign after cloud-init
<pitti> blake_r: more modern cloud-inits even have that feature builtin, but not yet in older releases (thus I'm not yet using it in autopkgtest)
<blake_r> pitti: yeah I am going to use "power_state" in cloud-init
<pitti> blake_r: http://cloudinit.readthedocs.org/en/latest/topics/examples.html#reboot-poweroff-when-finished right, that's what I meant
<mardy> xnox: ok, I've got something I'd like to you to build on s390x, but I don't know how to generate the .dsc file: debuild complains that it cannot find the upstream tarball
<xnox> mardy, i can work with branches too...
<cjwatson> Download it from the Ubuntu archive and put it in your parent directory
<pitti> blake_r: I just checked, power_state does exist in trusty now, but not yet in precise
<blake_r> pitti: thanks for the info, we only support trusty to commision with so that will be perfect
<mardy> xnox: ah, that makes it much easier :-) lp:~mardy/libaccounts-glib/s390-tests
<xnox> mardy, fail - https://launchpadlibrarian.net/230340565/buildlog_ubuntu-xenial-s390x.libaccounts-glib_1.19-0ubuntu1_BUILDING.txt.gz
<mardy> xnox: thanks -- I actually just added some debug messages, so failure was expected :-)
<xnox> mardy, what tipe of db is it using?
<doko> perl transition has arrived ... texinfo uninstallable
 * xnox ponders if we should have used a silo for perl transition
<cjwatson> doko: I've uploaded the key rebuilds
<cjwatson> doko: working on it anyway
<cjwatson> xnox: maybe, but too late now :)
<xnox> cjwatson, cowboy developer =)
<cjwatson> xnox: hey, it was auto-synced :P
<xnox> .....
 * xnox ponders if i should or should not point out who implemented autosync...
<xnox> >_<
<xnox> =)))))
<pitti> good that we don't all run away into holidays in two days
<cjwatson> xnox: *ahem* I ported it to its current implementation, I didn't write it to start with :)
<xnox> cjwatson, ... Keybuk?
<cjwatson> xnox: I doubt it
<cjwatson> It was in LP
<xnox> right. so somebody like lamont or some such then. anyway, history.
<jgdxx> greyback, hey, is mir 0.17 too old to get back something that makes sense from mir_connection_create_display_config ?
<greyback> jgdxx: no, that should work today
<jgdxx> on the device, I'm getting two outputs, one lvds and one displayport (on mako), but only one of them have modes (lvds)
<jgdxx> and the only lvds mode is 1280x768x60
<greyback> jgdxx: this with mir-on-x?
<jgdxx> greyback, on the device, so no x
<jgdx> greyback, code http://pastebin.ubuntu.com/14074173/
<jgdx> i'm only getting adding mode "1280x768x60"
<greyback> jgdx: if you run "mirout" does it match what you're seeing?
<jgdx> greyback, getting "Could not connect to a display server: Failed to connect: not accepted by server"
<greyback> jgdx: ah, you've unity8 running. Instead run "MIR_SOCKET=/run/mir_socket mirout" as rooy
<jgdx> greyback, hm, no. I guess I'm doing something wrong. http://pastebin.ubuntu.com/14074211/
<jgdx> well no, that's an exact match
<jgdx> hm
<jgdx> it only supports that mode :P
<jgdx> greyback, thanks!
<greyback> jgdx: yep. lvds not flexible
<lamont> xnox: not I
<cjwatson> xnox: LP's original sync-source.py was ported from the Ubuntu dak instance by James; I believe James wrote the original dak version
<infinity> cjwatson: Thanks for handling the perl transition.  I just noticed it had started and panicked that I was going to have to burn my first vacation day fixing it. :P
<infinity> cjwatson: Do you need any help with that, or are you carrying state in your head and muscle memory?
<cjwatson> infinity: I'll want to hand off at some point, but I'm good for now
<infinity> cjwatson: Kay.  Using a tracker, I assume?
<cjwatson> infinity: It'll be impeded by the PS4.5 outage anyway, since that's taken out x86 scalingstack
<cjwatson> infinity: http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.22.html
<infinity> cjwatson: If so, just aim me at it when you're tired.
<teward> blurgh... anyone know if it's possible to get a temporary PGP key and SSH key accepted for uploads to the repositories?  (Gotta ask since my main system with my keys and such is down for repairs, for a few days)
<cjwatson> infinity: I'm doing lib*-perl from levels 1 and 2
<pitti> FTR, autopkgtest workers are all down (PS4.5 too), so tehre won't be progress on that front anytime soon
<infinity> cjwatson: Oh, joy.  (re: scalingstack)
<cjwatson> teward: as long as you can get at your Launchpad account, you can add new PGP/SSH keys there
<cjwatson> teward: if you can't do that, then no
<teward> cjwatson, and that's  instantly accepted at upload.u.c?
<cjwatson> teward: yes
<pitti> but no SSO to add them, I figure :)
<teward> cjwatson, thankfully I logged into launchpad *before* SSO took a crap
<cjwatson> teward: upload.u.c authenticates against Launchpad
<mardy> xnox: it's using sqlite
<cjwatson> pitti: SSO was working last I checked
<teward> pitti, i'm actually logged in now xD
<cjwatson> but maybe flapping
<teward> cjwatson, SSO broken on wiki.u.c as of 5 minutes ago
<pitti> teward: I'm fairly sure that adding keys will ask you again, but good luck!
<xnox> mardy, ack.
<cjwatson> right, probably flapping with the PS4.5 outage
<teward> i was already logged in on LP this morning around 6AM
<cjwatson> and indeed, changing at least some keys (PGP, IIRC) will require reuath
<cjwatson> *reauth
<teward> pitti, indeed.  first, gotta spin up a temporary VM environment for stuff, being stuck on WINDOWS makes me cringe
<teward> (fortunately i keep copies of ISOs, on a private ISO storage disk xD)
<cjwatson> things are supposedly coming back up though
<cjwatson> login.u.c is responding from here
<cjwatson> let's see if x86 scalingstack likes life better now
<teward> cjwatson, login.u.c was working for me fine, but the authentication from that -> wiki was timed out for me (10min+)
<teward> finally got in just a few seconds ago
<cjwatson> ah, well if login.u.c was working then that's not an SSO issue now is it?
<cjwatson> I expect the wiki's in prodstack so would have been independently having network trouble
<infinity> The wiki SSO bits seems to be rathe more problematic than most.
<infinity> (always, not just today)
<cjwatson> anyway, I hear things are returning
<teward> infinity, true, though it worked fine until this morning :)
<teward> cjwatson, thanks :)
<infinity> cjwatson: Gave you a bit more ppc horsepower too (ie: revived doko's latest murder spree victims)
<cjwatson> infinity: ta
<pitti> ah, autopkgtests are back, and busy with perl :) http://autopkgtest.ubuntu.com/running.shtml
<didrocks> barry: hey, do you have time for a stacktrace in python3-coverage? (I'm getting a stacktrace everything I'm enabling --cov-report=html)
<barry> didrocks: let's see (tho i'm about to break for lunch)
<didrocks> barry: I'm getting something like: http://paste.ubuntu.com/14075536/
<didrocks> (.coverage is generated as expected)
<barry> ran out of input!  that's a new one on me :)
<didrocks> barry: if I replace --cov-report=html by xml, it generates the xml as expected
<didrocks> yeah, sounds weird ;)
<pitti> cjwatson: ah, your lgw buildds are AWOL too
<cjwatson> pitti: Yeah, I know
<pitti> so that's not just me
<cjwatson> It's all dead
<cjwatson> mabolo is apparently very very sad
<pitti> one day before holidays, big perl 5.22, clouds dead -- what a perfect timing :)
<ryao> When is 16.04 Beta 1?
<ryao> Nevermind... I found it by googling slightly differently.
<sarnold> hey ryao :) https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule note that feature freeze is before that..
<ryao> sarnold: Thanks.
<mwhudson> i'd like to make a semi official ppa (or two) for golang testing
<mwhudson> would it make sense for them to be on the ~ubuntu-toolchain-r team or would a new team be better?
<slangasek> mwhudson: well, you'd have to be part of the ~ubuntu-toolchain-r team for that to be useful to you, I guess?  In which case you need to get doko to add you :)
<mwhudson> slangasek: yeah, i guess this is a question for doko really
<slangasek> it seems reasonable to me, but also not required since you can also easily get another team set up with a devirt ppa for all-arch building
<xnox_2016> mwhudson, after all these years doko never added me to ~ubuntu-toolchain-r i would not hold my breath. setting up new team and/or ppa should be fine. I thought there already was devirt ppa for go.... i recall somebody was building golang like on every upstream commit in devirt ppas.
<mwhudson> yeah ok new team seems sane then
<mwhudson> xnox_2016: gustavo was doing that sort of thing for a while i think, but not recentaly afaik
<xnox_2016> mwhudson, maybe you can take over those ppas.
<mwhudson> there's https://launchpad.net/~gophers/+archive/ubuntu/go bug that's really pretty old
#ubuntu-devel 2015-12-18
<cjwatson> rbasak: Please could you merge libapache2-mod-perl2 (or I'll do it if you like, but you touched it last)?
<cjwatson> Needed for Perl 5.22
<Bluefoxicy> I wonder why do-release-upgrade never works, and then you apt-get -f upgrade and it fixes it (mostly), and then you have like... fontconfig not regenerating font cache because of missing symbols, and you do-release-upgrade again to get to the next distro and all is well.
<Bluefoxicy> pretty cool that it can fail catastrophically and you can say "well fix it" and it does, though.
<pitti> Good morning
<cyphermox> hey pitti
<dholbach> good morning
<cpaelzer> Hi I was following this guide https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#librarysymbols
<cpaelzer> based on that I created http://paste.ubuntu.com/14086901/ for my use case
<cpaelzer> and the symbols file I got is this http://paste.ubuntu.com/14086902/
<cpaelzer> now I wanted to ask for a confirmation about the following
<cpaelzer> is that a symbol that was in 2.0 and is still there?
<cpaelzer> cirbuf_add_buf_head@DPDK_2.0 2.2
<cpaelzer> and this one, one that shows up in 2.2 but was not there in 2.0?
<cpaelzer> _rte_eth_dev_callback_process@DPDK_2.2 2.2
<ginggs> cpaelzer: no, it looks like the _2.0 is part of the name
<cpaelzer> ginggs: you mean of the symbol name?
<cpaelzer> yeah that could be I remember they combine that in the split libraries - I just never realized how it shows up in the combined lib
<ginggs> cpaelzer: yes, those are versioned symbols
<cpaelzer> ginggs: great, now tihngs fall into place - thanks
<cpaelzer> that will do until I get further to split the libs anyway
<cpaelzer> I found an example that might have been better
<cpaelzer> cmdline_poll@DPDK_2.1 2.2
<cpaelzer> that seems to be added with 2.1 and existing in 2.2
<cpaelzer> anyway, builds fine now - thanks once more
<ginggs> cpaelzer: yw, but looking at your new example 'cmdline_poll@DPDK_2.1 2.2' the _2.1 is part of the name and #MINVER# is 2.2
<Unit193> https://bugs.debian.org/808289
<ubottu> Debian bug 808289 in src:upstart "proposed RM: upstart -- RoQA; unmaintained" [Normal,Open]
<mardy> xnox_2016: hi! Could you please run the tests on this again: lp:~mardy/libaccounts-glib/s390-tests
<cpaelzer> mardy: IIRC xnox_2016 has said he will be out til next year, is it just about rerunning that on s390 or something more complex?
<mardy> cpaelzer: ah, I was wondering about the nick...
<mardy> cpaelzer: yes, just run that branch in a s390 builder; is it something that you could do?
<cpaelzer> mardy: if it is easy to run I can help
<cpaelzer> mardy: well in a builder I cant
<cpaelzer> but in a "normal" s390 system if that helps?
<mardy> cpaelzer: ah, that's probably even better :-)
<cpaelzer> so just autogetn / configure / make / ?
<mardy> cpaelzer: yes, but it's better if you run "dpkg-buildpackage -rfakeroot -b -us -us"
<mardy> cpaelzer: I know that the tests will fail, and I'd need to see the logs afterwards
<cpaelzer> ok, lets see - that system never built anything - a few package installs ahead ...
<cpaelzer> mardy: ok I'll let you know and you can identify if it fails at the right spot :-)
<mardy> cpaelzer: apt-get build-dep libaccounts-glib should do the trick
<mardy> cpaelzer: excellent, thanks a lot!
<cjwatson> mardy: Why not ask for a suitably-configured PPA where you can upload tests for yourself?
<cjwatson> Since you're a Canonical employee so can have devirtualised PPAs ...
<mardy> cjwatson: I didn't out of ignorance, I guess :-)
<mardy> cjwatson: is it documented somewhere?
<cjwatson> mardy: I don't recall, sorry
<cjwatson> mardy: But create a dedicated PPA for the purpose for yourself, then explain the requirement on https://answers.launchpad.net/launchpad/+addquestion
<mardy> cjwatson: excellent, will do that right now then, thanks
<mardy> cjwatson: done: https://answers.launchpad.net/launchpad/+question/279601
<cpaelzer> mardy: until you have set up the ppa following the hints of cjwatson you can check if this is what you were looking for http://paste.ubuntu.com/14087452/
<mardy> cpaelzer: lovely, thanks!
<cpaelzer> mardy: if the locale issues annoy you I've fixed those now
<mardy> cpaelzer: nah, it's fine
<cpaelzer> mardy: you're welcome - was worth getting my machine a few packages
<mardy> cpaelzer: is there anything special about s390? I wonder why the tests run fine in all other archs, but fail on s390... Maybe something unique about endiannes, pointer size...?
<cpaelzer> big endian to start with
<wgrant> mardy: That PPA is done.
<wgrant> mardy: PIE is also enabled on s390x by default.
<cpaelzer> pointer size is 64bit in ss390x and 31 !31 not 32! in s390
<cpaelzer> but I guess we only do s390x
<wgrant> But not on the other archs yet.
<mardy> wgrant: excellent, thanks
<cpaelzer> mardy: in any case you can find the assorted list of "being special"  in http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a
<cpaelzer> mardy: but not like a short summary :-)
<mardy> cpaelzer: ok, I'll keep that handy for later, in case I get really stuck
<cjwatson> wgrant: Ah, thanks for beating me to it.
<cjwatson> mardy: https://wiki.debian.org/ArchitectureSpecificsMemo is really helpful for this kind of question.
<cjwatson> mardy: Doesn't mention Ubuntu-specific things like PIE being enabled on s390x, but otherwise very useful.
<cjwatson> cpaelzer: ^- more useful than single-arch docs for most people :)
<didrocks> barry: hey! did you get any chance to find out what the issue was on the nose/coverage/html issue?
<cpaelzer> cjwatson: I didn't know that, but I like the comparison that can be handy - worth a bookmark, thanks
<cjwatson> And indeed, s390 (not s390x) is irrelevant in Ubuntu and was removed from Debian a while back too.
<cpaelzer> cjwatson: hmm am I supposed to fix missing info in there?
<cpaelzer> cjwatson: well have no user yet in that wiki
<cjwatson> cpaelzer: Not "supposed to", though I'm sure corrections and clarifications would be welcome (anyone can create an account there AFAIK).  Do keep it in roughly the current style though :)
<cpaelzer> cjwatson: just missing the huge page sizes, I'll request an account
<cjwatson> Make sure that it actually matches configuration in Debian for that kind of thing.
<cpaelzer> cjwatson: I have a debian on s390 to check
<cjwatson> s390x, perhaps?
<cpaelzer> cjwatson: wgrant: mardy: one thing that doesn't fit the table but is sometimes worth to know - a cache line is rather long with 256 byte
<cpaelzer> I meant s390x
<wgrant> I guess they can afford that with the hundreds of megabytes of L4...
<cjwatson> cpaelzer: You could add a heading and a bit of free-form text further down the page about that if you wanted.
<cjwatson> cpaelzer: Though does that often affect userspace porting?
<cpaelzer> cjwatson: not porting in terms of function but a lot of performance issues with cache line bouncing
<cjwatson> cpaelzer: OK, that's not really the point of this page
<cjwatson> cpaelzer: The point is to provide a reference for a package maintainer scratching their head about why their package works on one set of architectures but not another, and to let them quickly match that up with characteristics of the architectures that do/don't work
<cpaelzer> cjwatson: ok thanks, then I'll just add the huge page sizes
<cjwatson> cpaelzer: I would think pretty carefully before turning it into a performance reference
<cjwatson> (though there is a little bit of that relating to alignment)
<cpaelzer> cjwatson: I'll omit the cache line thing for now, it is just my old history being s390x performance engineer for a decade that sometimes comes back :-)
<cjwatson> If you did add that, you'd want to explain how userspace ought to take account of it
<cpaelzer> cjwatson: that is the reason why I omit the cache line thing on this page, it would require too much space and by that not suit the page as it is
<mardy> cpaelzer: hey, would you be able to run a command for me in the build directory?
<cpaelzer> mardy: sure
<mardy> cpaelzer: in the "tests" directory: make check TEST_CASE=AccountService
<cpaelzer> mardy: http://paste.ubuntu.com/14087565/ ?
<mardy> cpaelzer: ok, then I need to see the DB, let me find the right command to dump it...
<mardy> cpaelzer: I guess just "sqlite3 /tmp/accounts.db" and then a ".dump" from the interactive console
<mardy> cpaelzer: ah, but now I see that the tests passed... :-/
<cpaelzer> mardy: http://paste.ubuntu.com/14087577/ here for you anyway
<mardy> cpaelzer: yep, that's correct, as expected
<mardy> cpaelzer: and make check TEST_CASE=Create ?
<mardy> cpaelzer: just tell me if it passes or not
<cpaelzer> mardy: fails
<mardy> cpaelzer: excellent, then can I see the logs please?
<cpaelzer> mardy: => http://paste.ubuntu.com/14087590/ ?
<cpaelzer> mardy: both tests have pass=1/Fail=1
<mardy> cpaelzer: weird that the full log is not attached; can you please paste me the tests/accounts-glib-test.sh.log file?
<cpaelzer> mardy: http://paste.ubuntu.com/14087600/
<cpaelzer> ah you meant the .log
<cpaelzer> mardy: http://paste.ubuntu.com/14087602/
<cpaelzer> cjwatson: with some help from IBM friends I was also able to calrify the float/double columns of that - now s390x looks as it should. Thanks for pointing me there
<cjwatson> cool
<mardy> cpaelzer: eh, it's mysterious, looks like the logs from the failing test are completely missing
<cpaelzer> mardy: I rerun the test and see that the file is updated
<cpaelzer> mardy: so it is not just some old content, it really writes just those few lines
<mardy> cpaelzer: yes, I can see that's the correct file, but something is missing; looks like the output of the failed test is being discarded; might be a bug in the check testing tool
<cpaelzer> mardy: the log still ends with "task-0: 100%: Checks: 4, Failures: 0, Errors: 0" if I run the TEST_CASE=AccountService instead
<mardy> cpaelzer: and what if you try: make check TEST_CASE=Create WRAPPER=time ?
<cpaelzer> mardy: /root/s390-tests/libtool: line 10051: exec: time: not found
<cpaelzer> let me install
<rbasak> cjwatson: doing it now.
<cjwatson> rbasak: thanks!
<cpaelzer> mardy: the log now at least has some errors http://paste.ubuntu.com/14087637/
<cpaelzer> better?
<mardy> cpaelzer: thanks, that's extremely useful!
<cpaelzer> mardy: maye even better make check TEST_CASE=Create WRAPPER="ltrace -T -S -r "
<cpaelzer> mardy: => http://paste.ubuntu.com/14087659/
<cpaelzer> mardy: just in case you really want to know whats going on below :-)
<mardy> cpaelzer: thanks, never used that command, I usually do strace, but this seems even better
<cpaelzer> mardy: its combined and a few timing extras
<cpaelzer> mardy: and then there is no s390x strace packet yet in the repos
<mardy> cpaelzer: it's a bit unfortunate that it doesn't show the first parameter of SYS_open(), just ""
<mardy> cpaelzer: actually, it fails to get the string parameters of all the SYS_* functions
<mardy> cpaelzer: anyway, the problem is that the test is setings the permissions of a file to read-only, then the library attempts to open the file with O_RDWR, and we'd expect that to fail... but from the logs (both the test logs and the ltrace) I can see that it succeeds to open it
<mardy> cpaelzer: what filesystem are you using on /tmp ?
<cpaelzer> mardy: /tmp is no extra mount, btu actually on / and that is ext4
<rbasak> cjwatson: uploaded. I couldn't run the dep8 tests local (some issue with lxc and xenial) so we'll have to see.
<pitti> cjwatson: OOI, we have tons of idle arm64 builders on scalingstack; what's missing to use them as distro buildds?
<pitti> rbasak: adt-virt-lxc works well here, what's up?
<rbasak> pitti: I can't get lxc-start-ephemeral to start a xenial container on vivid (I need to replace my dev VM with something newer)
<rbasak> So it's not adt-virt-lxc, it's just between me and lxc I think.
<doko> pitti, kernel and qemu updates at least, afaik
<rbasak> I haven't tried to reproduce in a fresh VM or anything yet; probably easier to just go to Wily or Xenial for a new test VM.
<pitti> rbasak: ah yes, high time :) wily host and xenial guest kind of works, but I must pin lxc and lxcfs to wily-release (not -updatse)
<pitti> doko: well, if anything the PPA builders should be *more* complicated and demanding as they need stronger virtualization?
 * rbasak do-release-upgrades it
<pitti> doko: but we have > 25 PPA builders which are just twiddling thumbs while the 5 distro builders can't keep up, hence I was curious
<rbasak> It's sort of throwaway (I do merges, builds and tests on it and nothing else really) but it's a pain to set up again because of the large numbers of chroots, lxc template containers, adt-qemu images and stuff I end up with on it.
<pitti> rbasak: why would you throw these away?
 * pitti introduces rbasak to the magic of keeping $HOME between installs :)
<pitti> I keep /srv too, which is unencrypted and contains all my VMs, containers, and schroots
<rbasak> I like to know that I can reproduce things and not carry on state indefinitely and get myself stuck later.
<rbasak> I could script it all, I just haven't (recently).
<rbasak> So I don't like cruft building up in $HOME. I do carry it forward on my main personal machine, but I don't use that for dev builds and tests as I don't want to drag all of that unnecessarily into my full backups.
<rbasak> And I don't like maintaining long exclude lists for my full backups. I consider that dangerous.
<rbasak> Plus it saves me a ton of bandwidth and I get speed by having a machine closer to the archive.
<rbasak> (or maybe a mirror, I don't know)
<rbasak> Anyway, this time I'm just doing a do-release-upgrade because I can't be bothered to recreate. I'll probably do it next cycle though.
<rbasak> It feels good when everything is clean :-)
<barry> didrocks: not yet, but it's first on my list for this morning
<didrocks> barry: excellent! keep me posted :-) (and good luck for the hunt)
<barry> didrocks: will do!
<pitti> rbasak: ah, I do my development in ~/ubuntu and ~/debian which aren't covered by backups, and I have scripts to reproduce all the virt environments
<pitti> rbasak: and build stuff in schroots
<rbasak> If I exclude things from backups then my restores aren't really restores any more, they're "restore and then fix stuff up manually again" which I don't want to have to deal with after a disaster.
<rbasak> So my full backups are really full backups (I do exclude /proc, /sys and /tmp etc though), so I have more confidence in my DR plan and I will be able to restore and be productive again quickly.
<rbasak> OTOH my dev VM could explode, which would be annoying since that isn't backed up. But I can recreate it quickly enough to do whatever task I need to do - I won't need it all on the first day after DR.
<rbasak> I like to have that separation.
<rbasak> I also do have to make sure that anything on the dev VM I want to keep is mirrored locally. But rsync and git make that easy.
<cjwatson> pitti: They fail to reset a very large percentage of the time, so are currently unusable in practice (they only stay up if idle, pretty much).
<cjwatson> pitti: We have two upgrade tickets sitting with GSA to upgrade qemu and the kernel on the hosts, which we hope will help.
<pitti> cjwatson: ah, too bad; thanks, I was curious
<cjwatson> pitti: And yes, those are very high priority because as you say the current five can't keep up, but GSA has been too swamped to deal with these ...
<dobey> hmm
<dobey> is there a preempt-rt version of the lts-wily kernel for 14.04 anywhere?
<rbasak> pitti: fyi, upgrading to wily fixed the issue. I don't know if that's because of some side effect though.
<pitti> rbasak: ah, then you are lucky; I have to pin the versions on the armhf production machines, but maybe that's an arch specific problem
<pitti> rbasak: and if there's still trouble, I hear we have a xenial development series :)
<rbasak> :)
<rbasak> Hey someone needs to dogfood the stable release. We'd never know when we need SRUs otherwise :-P
<barry> didrocks: looking now.  this is lp:ubuntu-make right?  on xenial?  what do i need to do to set things up to run the nosetests3 command from your pastebin?  (nosetests3 doesn't like the --cov=umake argument)
<didrocks> barry: lp:ubuntu-make or github :)
<barry> didrocks: ah.  what's the url?
<didrocks> barry: if you install the build-deps, it should like --cov=umake :)
<didrocks> barry: https://github.com/ubuntu/ubuntu-make
<didrocks> (but lp:ubuntu-make is supposed to be a mirror)
<didrocks> barry: so, from this, install the build-deps and run the nosetests3 command I pastebined yesterday
<barry> didrocks: everyday i forget more and more bzr :)
<didrocks> heh ;)
<didrocks> barry: basically I have a wrapper "runtests" which is setting the right options, I just copied nosetests3 so that it's easier for you to reproduce this
<didrocks> barry: oh, and yeah: xenial
<barry> didrocks:
<barry> Ran 1 test in 4.583s
<barry>  
<barry> OK
<barry>  
<barry> let me try runtests
<barry> (after tweaking the path since i obviously don't have /home/didrocks... :)
<barry> i used a relative path tests/__init__.py - wonder if that makes a difference
<didrocks> barry: you did use all the options I pasted?
<barry> didrocks: yep
<didrocks> weird
<barry> (after build-deps)
<didrocks> so:
<didrocks> try:
<didrocks> ./runtests --publish --coverage pep8
 * barry tries
<barry> didrocks: ran to completion, no problem
<didrocks> barry: hum, I wonder if a new dep isn't needed then :/
<didrocks> barry: I'm having Coverage.py warning: No data was collected.
<rbasak> pitti: unfortunately the dep8 test still fails because it can't upgrade systemd inside adt-virt-lxc which appears to be a test dep somehow. It times out. I won't worry about it though. I presume that'll get sorted soon.
<didrocks> barry: same in a clean ubuntu-desktop, with just the build-deps installed
<didrocks> xenial, right?
<barry> didrocks: could you have some stale data?  try cleaning out everything from your git repo and try again?
<rbasak> (the postinst times out, not adt-virt-lxc)
<didrocks> barry: good idea
<pitti> rbasak: yes, that's what I meant
<barry> didrocks: yep, xenial, though i haven't dist-upgraded this morning yet :)
<rbasak> Ah, OK
<didrocks> barry: well, should have failed form yesterda
<didrocks> barry: let me try a clean repo
<pitti> rbasak: that's some lxcfs issue, and downgrading lxcfs and lxc to the release versions WFM
<barry> didrocks: cool
<rbasak> pitti: so pinning the versions fixes that?
<rbasak> Right, got it. Thanks.
<pitti> rbasak: on the armhf production machines at least; this doesn't happen with the xenial versions
<didrocks> barry: you're right, WTH?
<didrocks> clean repo works
<pitti> rbasak: so maybe these two are missing an accompanying cgmanager or whatever, I didn't have time to investigte this deeply yet
<didrocks> barry: so, staled .coverage corrupted data?
<barry> didrocks: probably just some stale/broken data.
<barry> didrocks: yep
<didrocks> barry: well, "happy" at least that's not super bad :)
<barry> that's why this is my favorite git alias: distclean = "clean -dxfi" :)
<didrocks> ahah :)
<didrocks> thanks for giving this hint barry!
<barry> didrocks: sure thing!  glad it's working
<didrocks> ;)
<didrocks> me too
 * didrocks can't see anything and feel tired :)
<didrocks> feels*
<didrocks> so, time for week-end, couldn't take any break today
<didrocks> have a good holidays for those leaving tonight, and happy new years!
<didrocks> for the others, see you on Monday |m|
<mardy> cjwatson, cpaelzer_afk: just for the record, this seems to fix the libaccounts-glib tests for s390x -- so indeed, an endianness issue: https://gitlab.com/accounts-sso/libaccounts-glib/commit/a6c28fea9fa791a85b1809f00cc43d16b87f2b77
<rbasak> pitti: and adt-run passed. Thanks! \o/
<rbasak> pitti: is there a bug on lxc needing a downgrade? If not I can create one.
<pitti> rbasak: I haven't filed one yet, I don't have much more information than just "it breaks"; but if it's happening on your system too, it's not just a quirk of my armhf machines
<rbasak> pitti: I'll file one then, thanks.
<pitti> rbasak: they are running an ancient kernel, but it seems your case is much easier to reproduce
<pitti> rbasak: cheers
<rbasak> pitti: I can't reproduce it any more :-(
<rbasak> Oh no, I can. I just can't reduce it.
<rbasak> pitti: filed bug 1527666
<ubottu> bug 1527666 in lxc (Ubuntu) "lxc on Wily cannot dist-upgrade Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1527666
<pitti> rbasak: try with looping systemctl daemon-reload
<pitti> that will give the cgroups some exercise
<pitti> rbasak: it quite obviously locks up doing some cgroup operations, and these are being channeled through cgmanager/lxcfs
<pitti> rbasak: not sure about the details, but that might give you some hint if you try to reduce it
<rbasak> That doesn't seem to work.
<rbasak> I'll leave it for now. It is reproducible currently just by running adt-run at least.
<rbasak> For now, anyway.
<Laney> barry: hi, did you notice the ubuntu i386 images have been failing to build with an error from axi?
<barry> Laney: yep, cyphermox pointed me at the build failure.  it's a 32bit thing, but i hope to have time today to investigate
<cjwatson> mardy: Indeed, very plausible.
<Laney> cool
<pitti> rbasak: curious that lxcfs 0.10-0ubuntu2.1 works for you -- that's what I had to downgrade
<cyphermox> oi
<pitti> rbasak: anyway, followed up, thanks for filing
<pitti> and with that, TTFN -- happy EOL holidays everyone!
<cyphermox> end of line holidays?
<pitti> "EOY"
<cyphermox> happy holidays pitti ;)
<pitti> all the more proof that I need them :)
<rbasak> EOL?!
<rbasak> No thanks.
<rbasak> EOY maybe :)
<rbasak> Oh, he said that.
<rbasak> infinity: I'd like to talk to you about Docker. Are you around and free today? I'm gone for Christmas after today so otherwise maybe in January?
<infinity> rbasak: I'm technically already gone (until January as well).
<Captonjamason> quick question, i need to update to boost version 1.39, how may i do that,
<rbasak> infinity: that's fine. Can I stick something in the calendar in Jaunary? When would be good for you?
<Captonjamason> nvrmnd
<Captonjamason> im just wasting my time
 * rbasak is never sure what timezone infinity is in
<infinity> rbasak: Well, in theory, I'm in MST7MDT.  Pick something that's not so early in the morning that I'll want to punch you.
<rbasak> OK, thanks
<rbasak> infinity: 1700 UTC == 1000 for you? We can bump it back further if I'm tied up that evening, but I've put it there for now. I hope I'm not about to get a punch!
<Captonjamason> oh its not too early in the morning infinity
<infinity> rbasak: Nah, 10ish works.
<rbasak> OK, thanks!
<teward> so how do I interpret update_excuses if it says for a package "Depends: [itself] perl (not considered)"?  (where [itself] indicates it depends on itself)
<infinity> teward: You're reading it wrong.  It's saying that [itself] depends on perl.
<teward> ah OK
<teward> that confused me a little :)
<infinity> teward: Makes more sense when you see a source package that produces different binary packages, that's telling you that [binary] depends on [other source].
<teward> ok
<infinity> Oh, actually.  No.  It is the source package.  I lied.
<infinity> But still.  That's what it means. :P
<teward> :P
<infinity> teward: Look at, eg: haskell-cracknum, which shows three deps.
<infinity> teward: Makes a bit more sense in that context.
<teward> indeed.
<teward> more concerned about nginx - the perl upload went in, so i'm curious how migration from proposed is impacted by that (nginx 1.9.6-2ubuntu2 was uploaded for a rebuild against the updated perl)
<infinity> teward: It'll all go in once the perl transition is done, not much to worry about.
<teward> ok
<infinity> teward: http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.22.html
<infinity> teward: There's a bit to go still.
<teward> ahh i knew there was a transition tracker somewhere
 * teward needs to bookmark things better
<infinity> cjwatson: Speaking of the perl transition, you never did hand that off, like you said you would.  Does that mean you're still chipping away at it?
<teward> i assume then before uploading any more nginx versions I should wait for the transition?
<teward> for the transition to complete*
<teward> (being 4 revisions behind is *bad*, i think...)
<infinity> teward: You can do more uploads if you want, they'll just be stuck in proposed until the transition is done.
<teward> (and Debian is being slow to update)
<teward> ok
<cjwatson> infinity: I just uploaded another batch of rebuilds, up to libyaml-syck-perl in level 3.  Give the tracker an hour or two to catch up and then it's all yours.
<cjwatson> There are bits and pieces from earlier that I haven't touched.
<smoser> ok... in a post bzr distributed development world, where 'bzr branch lp:ubuntu/update-notifier' is "ERROR: Not a branch:"
<infinity> cjwatson: Sure, I'll wait for arm64 to go idle and see what the state is.
<smoser> how should i blame source in a package ?
<infinity> cjwatson: Has there been any porting required, or have rebuilds done the trick consistently?
<smoser> i want to know why something is the way it is, what is the recommended way of doing that.
<infinity> smoser: Read the changelog?
<cjwatson> infinity: Rebuilds and merges have handled most things so far, but I haven't had time to look into anything much non-trivial.
<cjwatson> infinity: It's supposed to have been pretty well-prepared in Debian, though.
<smoser> infinity, i'd like somethign that isn't almost guaranteed to be wrong.
<infinity> smoser: don't work on software?
<cjwatson> infinity: perlqt isn't in Debian and looks like it needs some fixing.
<smoser> http://www.mongodb-is-web-scale.com/
<smoser> is there a plan for something equivalent ?
<smoser>   * debian/99update-notifier:
<smoser>     - Now additionally triggers the an asynchronous background update of the
<smoser>       cached info via update-motd-updates-available hooking into
<smoser>       APT::Update::Post-Invoke-Success.
<smoser> :-(
<cjwatson> smoser: Hopefully earlyish next year I'll have time to finish off my plan to import history from LP using dgit, yes.
<smoser> bah. wrong paste location. :-(
<smoser> cjwatson, i'm very interested. as my bad paste shows, the thing i was chasing is actually in a changelog, but... i'd rather not depend on it.
<infinity> smoser: But, but.  Does /dev/null support sharding?
<teward> infinity: i assume that any new upload will automatically get included in the transition tracker/tracking?
<cjwatson> smoser: Yeah, lots of people want it :)
<cjwatson> teward: yes
<teward> cjwatson: OK, thanks
<smoser> "As of this moment I officially resign from my job as software engineer and will take up work on the farm shovelling...."
<nacc> that sounds like a power play in Agricola
<sil2100> Hey guys! We wanted to re-build oxide-qt in the archive, sadly it seems the armhf build seems to be segfaulting in the middle
<sil2100> https://launchpad.net/ubuntu/+source/oxide-qt/1.11.3-0ubuntu2/+build/8458995
<sil2100> /usr/lib/gcc/arm-linux-gnueabihf/5/include/arm_neon.h:6831:10: internal compiler error: Segmentation fault
<sil2100> On the armhf builders - we didn't have that before and this version already built in the past, we're just doing a no-change rebuild
<sil2100> We retried once but got the same
<sil2100> Any ideas?
<smoser> hey. so https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1527710
<ubottu> Launchpad bug 1527710 in update-notifier (Ubuntu) "apt-get update triggers asynchronous task" [Undecided,New]
<cyphermox> sil2100: sounds like you need someone like doko, who knows of the voodoo in there.
<cyphermox> sil2100: did you file a bug?
<cyphermox> I fail, nevermind :)
<smoser> i find apt config odd. is there a way that i can 'apt-get .... --option=Post-Invoke-Success' that disabled everything ?
<cyphermox> cjwatson: still on the perl transition? I'd start to finish level 3 after libyaml-syck-perl.
<cjwatson> cyphermox: I've stopped for the moment
<cyphermox> cjwatson: well, I'm very slow anyway on account of http://www.xkcd.com/# being totally descriptive of my day.
<barry> cyphermox: ping, that apt-xapian-index bug
<cyphermox> ah?
<barry> okay, so here's the problem.  astrometry-data-2mass-00's installed size is 14215209984, and
<barry> >>> log2(14215209984)
<barry> 33.72671635922483
<barry>  
<cyphermox> weee
<barry> axi has a size plugin that stores the installed and package sizes as documents
<barry> so yeah, that won't work
<barry> ultimately, i think it's a bug in xapian1.3-bindings but that's swig so <shudder>
<cyphermox> so, time to think some more of ripping our software-center?
<barry> cyphermox: we could do one of two things: catch the exception and treat it like -1 (i.e. ignore the size in the plug), or squash the size to sys.maxsize
<cyphermox> hrm
<barry> cyphermox: yep.  that *is* happening in 16.04 but robert_ancell is still working on that
<cyphermox> yeah
<cyphermox> well, you know more about a-x-i than I do, what do you feel is the best solution?
<barry> i will report the bug upstream to xapian either way and if they come up with a patch, i'll import that into xapian1.3-bindings
<cyphermox> I think I'd rather break the size obviously rather than squashing it and reporting something that looks possible.
<barry> i'm not actually sure where the installed size is displayed, but the code clearly expects to ignore bogus values.  it currently ignores inst_size == -1
<sil2100> doko: hey! Any idea why this segfault is happening by any chance? https://launchpad.net/ubuntu/+source/oxide-qt/1.11.3-0ubuntu2/+build/8458995
<barry> so, it's either dunno or lie :)
<barry> i'm inclined to make it == -1
<cyphermox> yeah
<barry> i.e. not lie, but dunno
<cyphermox> yes
<sil2100> doko: all other builds went fine, and the oxide source did not change since last version (a no-change rebuild)
<barry> it probably won't affect too many packages.  i bet not many are as big as astrometry, but i haven't looked at all
<barry> cyphermox: ok, so agreed, treat it as -1?
<cyphermox> barry: I think that's arguably better than lying about the size.
<barry> cyphermox: agreed.  i think i can whip up and test a fix for this quickly
<barry> thx
<sil2100> cjwatson: ok, I'm back... let me fill in a bug regarding the build segfault - I know this sounds silly, but could it be caused by the perl transition? As I see perl-modules marked for removal at the start of the build
<sil2100> cjwatson: although the most probable case is gcc 5.3.1...
<cjwatson> sil2100: sorry, I can't look now.  it seems unlikely; even if it is, you'll have to deal with it anyway ...
<cjwatson> sil2100: a toolchain change is much more probable
<sil2100> Yeah
<sil2100> s/case/reason
<sil2100> doko: hey! If you could take a look at LP: #1527741 in the nearest time, maybe you would know more about what's causing this failure
<ubottu> Launchpad bug 1527741 in oxide-qt (Ubuntu) "oxide-qt 1.11.3-0ubuntu2 FTBFS on armhf due to compiler segfault" [Critical,New] https://launchpad.net/bugs/1527741
<barry> cyphermox, Laney: LP: #1527745 - i have to run out for an errand right now but i'll work out a fix when i get back.  should be quick
<ubottu> Launchpad bug 1527745 in apt-xapian-index (Ubuntu) "plugin/sizes.py crashes on 32 bit system for big packages" [High,In progress] https://launchpad.net/bugs/1527745
#ubuntu-devel 2015-12-19
<cyphermox> cjwatson: I noticed you did some more upload, we should problably coordinate, I had been doing libtrycatch-perl
<cyphermox> Logan: I'm curious, do you have plans to merge courier, it looks to me like you did last time (in raring) and you also touched it last... if you already use the package you'd be in a better position to test it after a merge than I would.
<Logan> cyphermox: I don't use it, so go for it if you're interested
<cyphermox> ok
<Girish> Improved READMEs for File Manager App. Proposed a merge request. https://code.launchpad.net/~emailgirishrawat/ubuntu-filemanager-app/READMEs/+merge/281007
<Unit193> LocutusOfBorg1: Re: 1527860.  If I had to guess, I'd say http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox-ext-pack.git/tree/debian/postinst#n27
<Unit193> So, needs something like 'echo "License not accepted by user, aborting."
<Unit193> '
<cjwatson> cyphermox: well, I did a few more, TBH with perl transitions it's usually easiest to throw most of it at the buildds and sort out whatever remains at the end :)
<LocutusOfBorg1> hi, can anybody please make arrayfire migrate in -release by removing powerpc?
<LocutusOfBorg1> it is not supported and we already removed it on Debian
<cyphermox> cjwatson: ack.
<Noskcaj> How can i find out what packages i have upload rights for? I can upload 3 or 4 but can't remember what
<Girish> Improved and expanded Ubuntu Doc Viewer's READMEs. Proposed a merge request: https://code.launchpad.net/~emailgirishrawat/ubuntu-docviewer-app/READMEs/+merge/281013
<Girish> Also, added a commit message(which was missing earlier) in the File manager app's READMEs merge request: https://code.launchpad.net/~emailgirishrawat/ubuntu-filemanager-app/READMEs/+merge/281007
<cyphermox> Noskcaj: it depends on the teams you're in, from there you may be able to retrieve it from the packageset that goes with that team (lemme look things up)
<Noskcaj> cyphermox, It was just a few random packages that i worked on, nothing really team specific
<dobey> cyphermox, Noskcaj: lp:ubuntu-archive-tools "./edit-acl query -p $lp_username"
<cyphermox> ah, that's what I was looking for, I only noticed permssions-report
<Noskcaj> thanks
<Girish> When I'm trying to run an app in the emulator I'm getting the following errors: http://pastebin.com/BhY8vd6j
<Girish> It's running fine with qmlscene
<dobey> Girish: you are probably are better asking such questions in #ubuntu-app-devel
#ubuntu-devel 2015-12-20
<Noskcaj> Could one of the ubuntuwire admins please clean up http://qa.ubuntuwire.com/bugs/rcbugs/
<LocutusOfBorg1> rbasak, hi you there? I finally made llvm-3.7 build on i386 and updated the bug report. sorry for the long wait, but I had to upload 3 different versions to get one working :)
<ginggs> LocutusOfBorg1: hi
<rbasak> LocutusOfBorg1: looking
<LocutusOfBorg1> hi you both :)
<rbasak> LocutusOfBorg1: in your PPA test you disabled both LLDB build and test, but your submitted debdiff only disables test.
<rbasak> I'm not sure how I feel about this.
<rbasak> If it works then it's better than a complete FTBFS I suppose.
<rbasak> But are we shoving something under the carpet that will be a maintenance burden for us later?
<rbasak> LocutusOfBorg1: let me comment in the bug. If doko doesn't object then I'll sponsor.
<rbasak> LocutusOfBorg1: in the meantime do you mind confirming in your PPA that disabling just the LLDB test works please?
<rbasak> Also, is it suitable to build it if it is not being tested? Or if the test is a problem perhaps we _should_ also disable the build?
<rbasak> I really appreciate your help here. My problem is that I don't know enough about LLVM to be completely confident sponsoring. So let's see what doko thinks.
<LocutusOfBorg1> rbasak, you are probably right, I uploaded on my ppa a -5 revision with just the debdiff applied
<LocutusOfBorg1> I don't remember if I rolled back between my previous attempt
<LocutusOfBorg1> (not enough space on my pc to do the builds)
<rbasak> LocutusOfBorg1: if you think it's a buildd issue you probably should use a PPA to eliminate differences.
<rbasak> Although AIUI a PPA is not quite identical to a buildd environment (yet?), at least it's close.
<LocutusOfBorg1> true story
<LocutusOfBorg1> about testing this is a problem common on many architectures
<LocutusOfBorg1> LLDB_DISABLE_ARCHS := arm64 hurd-i386 ia64 ppc64el s390x powerpc alpha
<LocutusOfBorg1> and later armhf and armel
<LocutusOfBorg1> well armhf and armel have lldb enabled but testsuite disabled
<LocutusOfBorg1> and I did the same for i386
<LocutusOfBorg1> I don't have an opinion about my build fix, probably some more deep issue is just hidden, I hope doko will have the final and correct decision on the matter
<rbasak> LocutusOfBorg1: yeah copying armhf and armel was reasonable. I just don't like to upload things that I don't understand, and I'm not sure why that's the case already.
<rbasak> If doko doesn't have an opinion then I'm happy to upload based on the fact that you're looking after it and it'll rot otherwise, so it's better than doing nothing.
<LocutusOfBorg1> I did ~10 uploads of llvm stuff for Debian this year, fixed various RC and other bugs, but I still don't understand it :)
<LocutusOfBorg1> I guess instead of just disabling it, it might be better to disable the testsuite.
<LocutusOfBorg1> anyway, not many people should use LLDB features, and even less on i386 (because it is disabled mostly everywhere this LLDB), so at the end we can say, who cares about something that not many people use, on a particular version of llvm stack, on a particular architecture, on a particular ubuntu version?
<rbasak> LocutusOfBorg1: if there is consensus on that (ie. nobody objects) then I'd be fine with disabling both LLDB and the testsuite.
<rbasak> (the testsuite for LLDB that is)
<rbasak> Building something but disabling that thing's tests I'm less happy with.
<LocutusOfBorg1> (I should even check if I did disable them both or just the testsuite in my ppa lol)
<LocutusOfBorg1> this seems to be a fact for armel and armhf
<rbasak> That seems to have come from Debian though and I have no say in it.
<LocutusOfBorg1> (it comes from the Debian maintainer, and he is also upstream)
<LocutusOfBorg1> upstream did a lot of work on arm* recently, but some tests are still hanging/failing
<rbasak> See, you know far more about this than I do. I'm unqualified to make a decision. :-)
<LocutusOfBorg1> I think the only one that can make a decision is doko :)
<LocutusOfBorg1> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/8743116
<LocutusOfBorg1> it was good the debdiff
<cjwatson> rbasak: For architectures that have completely moved to scalingstack (amd64, i386, ppc64el), they're identical except for a few configuration details affecting pkgbinarymangler / pkg-create-dbgsym.
<rbasak> cjwatson: useful to know, thanks. I think I do remember you saying so in a recent update but I'm not very good at distinguishing roadmap from delivery in my casual memory as things keep moving from one to another :)
#ubuntu-devel 2016-12-19
<hyperair> ScottK: thoughts on https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331? if nobody's working on it, i could provide a debdiff
<ubottu> Launchpad bug 1519331 in postfix (Ubuntu) "Postfix cannot resolve DNS if network was unavailable when it was started, such as on a laptop" [Low,Confirmed]
<rbasak> hyperair: please get that fix into Debian. With no delta against Debian in postfix, I'd rather not have to maintain a delta for that bug.
<hyperair> oh right
<hyperair> rbasak: what about stable releases though?
<hyperair> (after getting it into debian, of course)
<rbasak> No objection, as long as it's OK under normal SRU policy, etc.
<hyperair> right
<hyperair> okay, actually taking a closer look, postfix does already does drop a script into /etc/network/if-up.d
<hyperair> odd
<cpaelzer> hi, anybody an idea of a meta package I could depend upon which gives me /vmlinuz cross arch for Debian&Ubuntu?
<cpaelzer> haven't seen a linux-generic in Debian - is there an equivalent?
<fossfreedom> sil2100: on the off-chance you haven't broken up for the holiday season (!) ... have you found any time to look at the lp:ubuntu-cdimage merge request?  TIA
<sil2100> fossfreedom: hey! Not yet, got a bit preempted last week - let me deal with it in a minute
<ScottK> hyperair: I have a theory about it.  It's on my list for this week.
<hyperair> ScottK: oh okay
<rbasak> infinity: may I have your opinion on https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/38 please?
<ubottu> Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Medium,In progress]
<rbasak> smoser, lamont: let's coordinate here.
<lamont> ok
<rbasak> I'm not sure what to do about bug 1642679. If nobody affected can be bothered to test, maybe it's better not to disrupt others who might be relying on the current code path but don't know about the bug and push a revert through. I don't know.
<ubottu> bug 1642679 in cloud-init (Ubuntu Yakkety) "The OpenStack network_config.json implementation fails on Hyper-V compute nodes" [Medium,Confirmed] https://launchpad.net/bugs/1642679
<rbasak> But let me see if that's the only blocker.
<rbasak> smoser: maybe put a second call for testing in the bug, at least?
<smoser> rbasak, i'm typing some stuff there now.
<smoser> and have irc-pinged a contact who is involved in the hyperv-nova work also
<rbasak> lamont: can I check I'm not missing anything? What's the full set of packages you need releasing?
<lamont> open-iscsi, isc-dhcp, initramfs-tools, cloud-init, cloud-initramfs-tools, ifupdown
<smoser> rbasak, gsamfira responded to me and he says he will test.
<rbasak> lamont: can you comment in bug 1629972 explaining on what basis it's verification-done please? That is: have you tested it specifically, or are you relying on the test case somewhere else? What about the test case documented in that bug itself?
<ubottu> bug 1629972 in MAAS "networking stop incorrectly disconnects from (network) root filesystem" [Undecided,Triaged] https://launchpad.net/bugs/1629972
<rbasak> lamont: thank you for the list
<rbasak> smoser: great, thanks!
<lamont> rbasak: doh.  added.
<lamont> the lxc test case in the bug was actually the simplified version of what I tested.
<sil2100> Is there any archive admin around to do a preNEW review in Bileto for a new source package? https://bileto.ubuntu.com/#/ticket/2278
<sil2100> In theory this should go to the NEW queue normally (Bileto doesn't go around the source NEW queue), but I remember we had this practice of gettin a pre-ACK beforehand
<sil2100> And besides, this will go straight to the overlay for xenial
<smoser> rbasak, gsamfira updated https://bugs.launchpad.net/cloud-init/+bug/1642679
<ubottu> Launchpad bug 1642679 in cloud-init (Ubuntu Yakkety) "The OpenStack network_config.json implementation fails on Hyper-V compute nodes" [Medium,Confirmed]
<rbasak> Thanks!
<lamont> smoser: bug 1611074 needs yakkety verrification, it would seem
<ubottu> bug 1611074 in cloud-init "Reformatting of ephemeral drive fails on resize of Azure VM" [High,Fix committed] https://launchpad.net/bugs/1611074
<lamont> smoser: ditto bug 1626243
<ubottu> bug 1626243 in cloud-init (Ubuntu Yakkety) "Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive" [Medium,Fix committed] https://launchpad.net/bugs/1626243
<infinity> rbasak: Added my two cents.
<rbasak> infinity: thanks!
<smoser> lamont, hm..
<rbasak> infinity: in general I agree with you, but here specifically there's one additional thing, which is that dhclient can grab a UDP port that later userspace then can't grab. So I think the bug is that it is (effectively) impossible to host a UDP service on a static port when using DHCP.
 * lamont has looked around and found zero asure ephemeral drives. :/
<infinity> rbasak: Yes, and the bug was reported 3.5 years ago, trusty was released 2.5 years ago, and we now have a new LTS.
<infinity> rbasak: If we'd fixed it 3 years ago, fine, yay, but we didn't, and there were really very few complaints.
<infinity> rbasak: Is there an internal motivation for this that has escalated it, or did the itch just land on someone who found the old bug and decided it was suddenly dire?
<rbasak> infinity: AIUI, someone new got hit and raised it with Canonical. So new motivation arrived.
<slashd> infinity, UA customer filed a bug about it, but I do agree with upgrading to Xenial, this is what I told him at the first place, and then I start a discussion with caribou and rbasak if we could do more or not
<slashd> infinity, rbasak, so final position is upgrade to Xenial and nothing more ?
<nacc> rbasak: caribou: ack on the bug filed re: usd tag, i forgot to update documentation (for now, run `usd tag --format='logical/<explicit version>'
<rbasak> infinity: IMHO, the point in having an EOL is that we fix things before EOL is reached. So I'm not convinced "there's a new LTS out" should be a reason.
<infinity> slashd: HEY YOU.
<infinity> slashd: You owe me a bug verification on debian-installer in xenial.
<infinity> rbasak: We don't fix ALL things.
<rbasak> infinity: but, if that's a -1, I think it carries more weight that my +1 on the principle (but not the method).
<rbasak> than my
<slashd> infinity, I know I change the tag to verification-done and update the lp bu about d-i
<infinity> rbasak: There's a bar for what is and isn't appropriate to fix in an SRU.  This is pretty borderline.
<rbasak> infinity: I agree it's borderline, but the observation that it makes it impossible to reliably run a UDP static port service swung it for me.
<infinity> slashd: Oh, so you did.  Thanks.
<nacc> rbasak: caribou: re: LP: #1651113 that is
<ubottu> Launchpad bug 1651113 in usd-importer ""usd tag" cannot tag logical tags" [High,Triaged] https://launchpad.net/bugs/1651113
<slashd> infinity, tks for sending me a reminder
<infinity> rbasak: I don't particularly love the behaviour, but I love any potential solution less.
<nacc> rbasak: do you want to sit down today or tmrw and prioritize the (now many) importer issues?
<rbasak> nacc: sure. Let me figure out when is best.
<infinity> rbasak: Anything that involves package splitting or environment-driven behaviour or, really, anything that says "trusty now supports two behaviours" will imply supporting a smooth upgrade path to same.
<infinity> rbasak: Which means isc-dchp upgrade suddenly doing the opposite of what they do today, or similar issues.
<rbasak> infinity: I think the current proposal resolves that. No unexpected change in behaviour for anyone. The ugliness is in having to do an SRU to Xenial to ensure that.
<infinity> The use-case that leads to the misfeature being a "bug" is clearly not a common one, or we'd have a ton of angry bugs about it.  So I really think "upgrade to Xenial" is the saner answer.
<infinity> rbasak: Nope, the current proposal doesn't address the upgrade path.
<rbasak> infinity: how so?
<infinity> rbasak: Once you split to "foo" and "foo-nofeature", you're saying "installing foo gets you feature".  And then we can't have it both ways.  Either the upgrade needs to start including feature, which will make current users grumpy, or it needs to not, which breaks that implied contract.
<infinity> The current proposal says "all upgrades get you nofeature".
<infinity> Which is certainly the path of least surprise for me.  But not for someone who read "apt-cache show foo" and "apt-cache show foo-nofeature" in a post-SRU world and installed "foo" on purpose.
<rbasak> you're saying...> I'm not sure I agree. We could make that clear in the package descriptions. I don't think anyone would be surprised by this any more than they are surprised today that "feature" disappears on upgrade to Xenial, which already happens.
<rbasak> I'm just surprised that you object on the principle of the thing rather than the mechanism.
<infinity> Alright, that's a reasonable fair argument.  If you take your proposal, and add "due to this package split being a late addition to trusty, upgrades to xenial will require manually installing foo-feature if you wanted feature" might work.
<infinity> I still disagree with the principle. :P
<infinity> It's a feature, not a bug.  It's a crap feature to have installed on basically all machines, but that still doesn't make it a bug.
<infinity> If the behaviour were itself deemed buggy and incorrect, we'd remove foo-feature from xenial, not split it. :P
<persia> Just as a note: if only one person is complaining, can they just have a package that works for them?  I like everything being in the distro, but some things are disruptive.
<rbasak> infinity: well, there are always going to be cases where users depend on one aspect of a particular feature but another aspect is a bug and should be fixed, but that would disrupt the first because SRU patches can't read minds.
<infinity> persia: People like me have given Canonical support a pretty strong mandate to *not* build one-off packages for customer bugfixes unless there's literally no other way to address something, because, well, that's super distro-unfriendly and just leads to chaos and extra maintenance burden.
<infinity> persia: Also hi.
<rbasak> infinity: I expect there are other less borderline cases where we'd have to do something similar. But I accept this this case is so borderline, the same reasoning can tip it over the edge to "no".
<persia> infinity: Hi.  People like me tend to deliver working packages and work with distro if that won't break distro, but I strongly support your base position and apologise for complicating it.
<infinity> rbasak: Anyhow, I'm not going to be the one to block it or not.  I was offering a "this really doesn't need fixing at all, maybe you should just tell the customer to upgrade" option because, well, I feel that's the sane option.
<persia> (and, to be fair, I'm not much of a person-like-me in the sense above these days)
<rbasak> infinity: so now we have two indecisions :-)
<infinity> persia: Yeah, were I an independent contractor, I'd provide fixes today, push to distro tomorrow, and if distro rejects, I'd figure out how to charge the client for ongoing maintenance of the forked package I just gave them. :P
<infinity> persia: Canonical's pricing structure for baseline support definitely doesn't support the latter part of that sentence, so letting our support guys back themselves into that corner is very bad. ;)
<caribou> infinity: rbasak: slashd: wouldn't a backport of the Xenial bits to the backport archive sufficient for this single occurence ?
<persia> infinity: Understood, and thank you for formally describing "people-like-me" in that context.
<infinity> Thus, it should be "in the distro for everyone", "no bugfix for you", or "this customer pays us way more".
<infinity> caribou: Perhaps, but that's an ongoing maintenance burden too.
<rbasak> caribou: that feels like it ships in a behaviour change in through the back door. I'm not sure backports is really intended for that, but I suppose that depends on backports policy.
<infinity> caribou: isc-dhcp doesn't have a perfect security record, by any stretch, so a backport as a bugfix would also mean needing to keep backports up to date.
<caribou> infinity: we do not propose maintenance for the backports archive
<rbasak> Certainly with users opting in it's not so bad from that perspective.
<rbasak> caribou: might as well just use a PPA then?
<infinity> caribou: Err.  You can't have it both ways.  If this is proposed as a bugfix, the fix can't be something buggier. :)
<caribou> rbasak: PPA is a one-off in that sense and, like infinity, is strongly against them
<infinity> And "here's a version frozen in time with no upgdates because we don't wanna" is buggier.
<rbasak> caribou: at least a PPA makes it clear though.
<infinity> No, please don't.
<caribou> rbasak: then let's teach them how to build their own PPA & let _them_ maintain it
<infinity> If the motivation is strong enough to put work in on this, do it right.
<rbasak> I'm not sure backports should be a place to fire-and-forget in changes you don't want to maintain.
<slashd> rbasak, won't be supported if they have other issue as per UA policy, they will need to go back to the pkg in -update if they want more support on the pkg , sec update, etc ...
<slashd> rbasak, about the PPA ^
<rbasak> So, as I see it, neither infinity nor I are prepared to commit to a +1, but won't block it either. So we're effectively at 0 from an SRU perspective. Ubuntu governance requires us to be decisive. So we can extend to the rest of ~ubuntu-sru to decide, or ask the TB. That's our path to a decision if you want one.
<infinity> Doesn't need a TB decision.
<rbasak> I suggest that in this case if we remain at 0 then the status quo should remain.
<rbasak> infinity: we can ask the TB if ~ubuntu-sru can't decide, AIUI.
<infinity> If the isc-dhcp-client desciption is amended with a note about the split being post-release and upgrades downgrading the feature again, I'm fine with rbasak's plan otherwise.  I don't love it, but I can get over it.  But it better be deemed worth the effort by the people putting in the time on this. :P
<infinity> (hint, hint)
<rbasak> Well, then I guess it's fine to do if slashd prepares it all. Because infinity said it's OK :-P
<rbasak> nacc: got time for a hangout now?
<rbasak> I have a hard stop in 55 minutes though.
<slashd> rbasak, infinity, so it's a +1 for my -noddns proposal, even if I totally agree that ideally, upgrading to xenial the favourite solution.
<rbasak> slashd: that's my understanding, yes. But see infinity's requirement above, and I also want the dpkg-divert clashing path I identified in comment 38 checked carefully.
<caribou> nacc: ack on usd tag btw
<rbasak> slashd: as well as the use cases we already identified, all being checked as part of SRU verification please.
<slashd> rbasak, sure, will you be amenable to sponsor it once completed since you are aware of everything since almost day 1 ?
<rbasak> slashd: I can't sponsor as I'll need to be available to provide the ~ubuntu-sru review, and I can't do both.
<slashd> rbasak, make sense, ok will find another sponsor, no worries
<rbasak> slashd: basically you need two reviews - one from me, and one from another person who can upload the package.
<infinity> rbasak: If you sponsor, you can annoy me until I review.
<slashd> rbasak, ack
<rbasak> slashd: oh, you have a volunteer :-)
<infinity> If both our waffling asses agree it's okay, that closes that hole. :P
<caribou> infinity: rbasak: I'll sponsor it, that's not an issue
<slashd> tks caribou
<slashd> tks infinty and rbasak
<slashd> infinity ^
<infinity> caribou: I expect you to take your sponsorship duties very seriously and review like you hate the uploader, then. ;)
<infinity> (Pretending to hate the uploader/committer is my default review strategy)
<caribou> infinity: I'll try to do as well as you did for me ;)
<caribou> infinity: ah, now I get it :-p
<infinity> "THIS GUY VOTED WRONG, KICKS PUPPIES, AND DOESN'T UNDERSTAND HOW BREAKS WORKS, ARGH."
<infinity> Oh, wait, no, just the dpkg thing.  But still valid!
<slashd> infinity, 2 quebecers can't hate each other, it will be hard to caribou to hate me ;) lol
<xnox> persia, can you vote in US elections and who did you vote for?
<infinity> slashd: Maybe have a debate about separation, and if you both agree (which you probably do), one of you can play devil's advocate until the other is seething with rage.
<slashd> infinity, lol as long as I have poutine, I don't mind being in Canada ;)
<xnox> wales would be happy to become Quebec's overseas territory.
<infinity> slashd: A solid position.
<caribou> infinity: pls don't get me into that; I fleed to France to avoid those
<infinity> slashd: I'm considering running for federal office to proposed poutine and maple syrup transfer payments.  That is, every time Quebec is net negative on the other type of transfer payments, they need to send a few thousand tonnes of squeaky cheese and a few thousand litres of maple syrup out west to say "thanks".
<infinity> slashd: Sadly, as the oil industry self-destructs, this seems less likely to work in the future. :P
<slashd> infinity ;p
<persia> xnox: I don't generally believe democracy is a good model, but one of my favorite parts of how it works in the US is the double-blind system for matching whether one voted and how one voted.
<nacc> rbasak: sorry, was afk -- i can talk for a few now, or we could try tmrw?
<rbasak> nacc: short chat now?
<nacc> rbasak: sounds good
<smoser> lamont, all the cloud-init yakkety are now verification-done
<lamont> rbasak: ^^ I think that's everything for yakkety to land
<smoser> rbasak, i just saw your comment on https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1633479 wrt git noise on precise.
<ubottu> Launchpad bug 1633479 in isc-dhcp (Ubuntu Yakkety) "dhclient does not wait for ipv6 dad (duplicate address detection)" [Medium,Fix committed]
<nacc> cyphermox: you asked for some input from submitter in LP: #1634689 but a different user responded (and did't change the bug state). Can you take a look at your convenience?
<ubottu> Launchpad bug 1634689 in openvpn (Ubuntu) "DNS leak after upgrade to 16.10" [Undecided,Incomplete] https://launchpad.net/bugs/1634689
<nacc> hallyn: would you be able to comment if the suggested fix in LP: #1618899 is appropriate?
<ubottu> Launchpad bug 1618899 in vm-builder (Ubuntu) "vmbuilder fails with dist-upgrade with release xenial" [Low,Triaged] https://launchpad.net/bugs/1618899
<infinity> nacc: Who/what is changing sudoers?
<nacc> infinity: a fair question! i'll ask in the bug, it does seem like there must be some local modification to get that prompt
<infinity> nacc: Commented.
<infinity> See stuff in the vm-builder source like:
<infinity>         logging.info("Running ec2 postinstall")
<infinity>         self.install_from_template('/etc/ec2_version', 'ec2_version', { 'version' : self.context.ec2
<infinity> _version } )
<infinity>         self.install_from_template('/etc/ssh/sshd_config', 'sshd_config')
<infinity>         self.install_from_template('/etc/sudoers', 'sudoers')
<nacc> infinity: thanks!
<nacc> yep
<infinity> nacc: If vm-builder is altering conffiles (ick), then dist-upgrading over those altered conffiles won't exactly make things better.
<nacc> infinity: absolutely agreed. Will see what the originator(s) say
<infinity> nacc: In this case, what they say isn't super meaningful. ;)
<nacc> infinity: yeah, i suppose that's true :)
<infinity> nacc: You can see the templates in the source, and what they alter.  In the sudoers case, it's adding ubuntu=NOPASSWD, which should be a sudoers.d snippet instead.
<infinity> nacc: In the sshd_config case, it's just gross.  Lots of changes, and no way to do that without mangling a conffile.
<infinity> nacc: So, maybe the answer is to mangle conffiles *after* the dist-upgrade step, not before.  But even then, you're leaving end-users of the image with something that will prompt on upgrade, which sucks.
<infinity> But, that bug seems to have existed pretty much forever, so meh.
<nacc> right, it seems like the 'correct' fix to just the sudoer issue is probably sudoers.d?
<infinity> Yeah.  But sshd_config will have exactly the same issue.
<infinity> Oh, no it won't.
<infinity> sshd_config isn't a conffile.
<infinity> Handy.
<nacc> heh
<infinity> So, yeah.  Fixing the sudoers thing by slapping a snipper in .d would fix this bug.
<infinity> snippet*
<nacc> infinity: thanks for the help!
<hallyn> nacc: fwiw the cloud image team are the ones afaik still using vmbuilder.  pushing gaughen to have her team maintain vmbuilder would seem prudent :)
<hallyn> me, i tried to drop it for 14.04, but adt was at the time still using it.  presumably by now it has stopped.
<nacc> hallyn: thanks! that was the context I was lacking (and poked you as the 'maintainer' in the package)
<infinity> nacc: As an added bonus, it would modernize the sudoers in vm-builder images, which seem to have a template forked from forever ago.
<infinity> hallyn: Do they, though?  All new releases at least use live-build/livecd-rootfs.
<hallyn> infinity: last i knew yeah they were using it for something
<nacc> gaughen --^ ?
<gaughen> nacc, hallyn, infinity we are moving away from it
<nacc> ok :)
<gaughen> and the vmbuilder that is used is a rather old fork
<hallyn> gaughen: toward livebuild?
<hallyn> gaughen: there are no newer forks afaik :)
<hallyn> nacc: so you could start with doing a fresh reverse depds check on vmbuilder,
<hallyn> on the one hand it was a pretty clean solutoin and one day i think we'll want it back,
<infinity> Well, even if we remove it from zesty, this bug is in xenial and trusty and needs fixing.
<hallyn> but otoh it's unmaintained atm and (obviously) out of date
 * infinity wonders if trusty's sudo speaks sudoers.d
<hallyn> ok
<hallyn> like i say i think we'll want it back someday (when cloud-images stop being a thing) :-)
<infinity> It does.  Handy.
<infinity> hallyn: Err, why would either of those things happen?
<hallyn> i dunno, why would ubuntuone storage go away
<infinity> Anyhow, I disagree heartily.
<hallyn> we went from something the community could generate to something where community depends on someone else,
 * nacc backs away slowly...
<nacc> hallyn: infinity: gaughen: thanks for the help on this bug!
<infinity> Even if we stopped producing the one thing that makes us more money than anything else, we'll be in a position to give people a way to do it "the way we did the official ones".
<infinity> hallyn: Work is in place to make it a 1-command no-brainer to emulate our infra.
<hallyn> agreed it seems unlikely, but the way we do the official ones is afaik secret sauce
<hallyn> oh that'd be awesome
<hallyn> no wait
<hallyn> is it based on snappy?
<infinity> No.
<infinity> I mean, there will be snap-based images too, but that's not what I was refering to.
<hallyn> cool, that'll be awesome to see
<hallyn> then all the more reason i should offer nacc:  hey nacc, if you manage to drop vmbuilder from the archive before feb, and if you're in bruseels for fosdem, i'll buy you a beer and a waffle.
<infinity> nacc: So, anyway, short story from my investigation: sudoers.tmpl in vm-builder is wildly out of date anyway, and sudo in both trusty and xenial supports sudoers.d, so drop the sudoers templates, add a template for /etc/sudoers.d/ubuntu that includes just the bottom bit of the template, test, win.
<sarnold> a beer -and- a waffle? nice
<infinity> nacc: And by all means, also file a removal request for vm-builder from zesty if no one cares to maintain it and gaughen is sure it's not being used in zesty.
<gaughen> nacc, we can double check with Odd_Bloke so we're 200% sure
<gaughen> nacc, will send a note and cc you.
<nacc> hallyn: infinity: gaughen: ack on all that, thanks!
<nacc> so is it just me, or is the current assignee of LP: #1299186 spam?
<ubottu> Launchpad bug 1299186 in samba (Ubuntu) "Creating a Samba Share is not possible because "'net usershare' returned error 255: net usershare add: cannot convert name "Everyone" to a SID. Access denied."" [High,Confirmed] https://launchpad.net/bugs/1299186
#ubuntu-devel 2016-12-20
<sil2100> doko: hello! We would need to get miral included in main: https://bugs.launchpad.net/ubuntu/+source/miral/+bug/1651384
<ubottu> Launchpad bug 1651384 in miral (Ubuntu) "[MIR] miral" [Critical,New]
<doko> sil2100: last work day this year, I try to have a look, but otherwise this has to wait til 2017
<sil2100> doko: thanks!
<sil2100> greyback: ^
<caribou> Is it possible to get someone from the SRU team to get cloud-init  v0.7.8-49-g9e904bb-0ubuntu1~16.04.3 into xenial-proposed pls ?
<xnox> i have just realised that I have just two more work days before I'm done for the year \o/
<slashd> for sru, could you please take action on "os-prober" [1.70ubuntu3.2] waiting in the Xenial upload queue (importance : CRITICAL) in order for the pkg to be available in -proposed for testing. This solve a missing dependency in 1.70ubuntu3.1 (currently in -proposed) patch that solve a possible risk of corruption. Again .3.1 is already in proposed, I would like the SRU to go on top and 3.1 should definitely not land in -updates
<slashd> without 3.2 debdiff on top
<slangasek> stgraber, infinity, kees, mdeslaur: TB meeting now?
<mdeslaur> slangasek: whoops...sorry...did anyone show up?
<GunnarHj> bdmurray: Saw you asked about bug #1633678. Yes, indeed I hope that somebody will upload it - that's why ubuntu-sponsors is subscribed. The proposed uploads are in the linked PPA.
<ubottu> bug 1633678 in freshplayerplugin (Ubuntu Yakkety) "Compability issue with adobe-flashplugin" [High,In progress] https://launchpad.net/bugs/1633678
<bdmurray> GunnarHj: ack, uploading
<GunnarHj> bdmurray: Great, thanks!
<tzero> hi guys, new to packaging/maintainership; so far it seems that the packaging process is just a collection of arcane memorization. What's the deal with upstream tarballs? What do maintainers generally do for your normal github project?
<nacc> tzero: have you read the packaging guide (probably the debian one)
<tzero> nacc: yep, have it up now; wiki.d.o/Packaging/Intro ; it's probably benign, but debuild -us -uc gripes about a lack of upstream tarball
<nacc> tzero: right, so you need an orig.tar.gz (roughly) which corresponds to the upstream you are based off of
<rbasak> tzero: Github will give you a tarball for any tag.
<tzero> what if the project is just a normal github project? with anything more complex than a hello world application the process seems to fall apart
<nacc> tzero: oftentimes this can be obtained (if the pacakge already exists) with `pull-debian-source`/`pull-lp-source`. Given your question, i assume you need it from upstream directly, which rbasak indicated. From a packaging perspecitve, you could write a debian/watch file and add the github example
<nacc> then uscan/uupdate will download the upstream tarball as specified
<tzero> what's the common workflow for just iterating on a set of packaging files in-place? since I'm maintaining the application itself, I can change anything needed, but don't want to have to create tags that aren't needed
<rbasak> tzero: it's useful to keep in mind that Debian will package anything. Release tarballs are a lowest common denominator. There does exist tooling to make things easier for your case, but that does necessarily add complexity.
<nacc> tzero: well, the tags rbasak mentioned are for upstrema releases
<nacc> tzero: which you should already be doing as an upstream :)
<nacc> tzero: not sure i follow what you mean by 'iterating on a set of package files' in place? just do it?
<tzero> hmm.. so if I create a tag of the current state of things, I can pull a tarball to get around the "
<tzero> "error: can't build with source format '3.0 (quilt)': no upstream tarball found at"
<tzero> sorry, IRC client line break issues...
<nacc> tzero: well you tag upstream (totally independent of packaging)
<nacc> tzero: then you can, for instance, setup debian/watch (see `man uscan`) to refer to the github page for downloading upstream tarballs
<nacc> tzero: there is also debmake (amongst many other tools) to start with an upstream tarball (again, this should alrady exist, independent of packaging) and setup some basic debian-ization
<tzero> isn't there a chicken-and-egg problem where I'm working on the files under debian/, I'd have to push those to github, download the upstream tarball, and test if it works? I'd just like to test the package building locally, before pushing the debian/ directory to github and revealing my ignorance to the world :)
<nacc> no
<nacc> tzero: debian/ is *not* in the upstream tarball normally
<tzero> OHH!
<nacc> tzero: i think you're making it way more complicated :)
<nacc> tzero: upstream tarballs are 'pristine' in some sense -- unaltered upstream sources
<nacc> tzero: you may want to read `man dpkg-source`
<nacc> tzero: specifically (in your case) the "Format: 3.0 (quilt)" section to understand how the package gets built
<tzero> hmm, so unlike RPM, the intermediary source package is required in this case
<nacc> tzero: what do you mean by "intermediary source package"? There is an 'orig' tarball, which is not a package, and then a source package (which is what you're building now) and that builds (possibly many) binary packages
<tzero> I'm just trying to get a generic concept of what's going on.. in RPM-land, the spec builds either the source package (.src.rpm) or the "desired end result" (.rpm); in arch and gentoo land, it's much more straightforward. but with dpkg/deb/dsc, it seems like the "spec" file builds a dsc, which then is used to create the desired end result (.deb)
<nacc> yes it's different in .deb
<nacc> there is no 'spec' for one thing :)
<nacc> a source package is a '.dsc' file basically
<nacc> as the .dsc file includes hashes of the tarballs used
<nacc> and the binary packages that get built from it
<nacc> you then build a source package into binary packages
<tzero> ah ha... gotcha, thanks
<tzero> I appreciate the patience and hand-holding; I'll read through some more stuff and see how it goes; thanks again
<nacc> tzero: just keep asking questions :)
<tzero> I stumbled on pdebuild at some point, it build some .deb files, but those didn't contain any of the application files at all. Is that a wrapper utility over the standard debuild? I found little mention of the .install file, but that seems necessary
<nacc> tzero: i don't think you want to use pdebuild/pbuilder
<nacc> tzero: i would suggest using sbuild at this point
<nacc> tzero: or dpkg-buildpackage itself, if you want
<tzero> and dpkg-buildpackage being the lowest-level of those utilities?
<nacc> tzero: yes, aiui
<infinity> tzero: FWIW, in your above example, spec files and debian/rules are pretty much 100% analogous.  Yes, the way Debian developers prefer to work is to build a .dsc and then feed the .dsc to sbuild to produce debs, but that's no different than building an .srpm and feeding that to a build script to build an .rpm.  It's just that people in RPM land tend to be more reckless. ;)
<infinity> tzero: The "reckless" option in deb land is there too, just "dpkg-buildpackage -b" and boom, you have .deb binaries, no need to build the source package first (or just dpkg-buildpackage with no options will build source and binary in one go).
<tzero> infinity: whoa, dpkg-buildpackage -b is great
<tzero> is there a better way to determine where files should be placed into the filesystem other than override_dh_install? by default, a package.install file containing lines such as 'usr/lib/python*/foo.py' only get included if I prefix the path to 'debian/package'
<tzero> and even then, lintian says the files would actually be installed into '/debian/package/usr/lib/...'
<tzero> without the .install file, the package only contains the default text files like COPYRIGHT, etc. If it makes a difference, the project has both GTK and Qt frontends, which are distributed as separate packages
<rbasak> tzero: you're packaging a Python thing? We have helpers for Python, so if you have a setup.py that works, the packaging effort becomes minimal. See dh_python3(1).
<dobey> tzero: generally, you shouldn't need to override_dh_install; by default just having usr/blah/foo in the .install files in multiple-binary-package scenarios should work. only if the files aren't installed via normal build system install rule, would there normally be a problem there
<dobey> you shouldn't build with the prefix set to /debian/package
<dobey> the defaults should be sufficient
<tzero> oh, less is more I guess, whatever blog I initially read said to define a bunch of things
<infinity> tzero: Less is definitely more in the new dh(1) style rules files.  An ideal package should require zero overrides, and that's the best position to start from.
<infinity> tzero: If something is particularly troublesome, but you feel like it's a something that dozens of other people should surely have suffered (like python modules), you'll often find there's a "dh --with foo" module that does all the heavy lifting.
<infinity> tzero: And the added advantage of modules like dh-python, dh-systemd, etc is that they also make sure that, even if your upstream is vaguely Fedora or Arch centric, or just plain old /usr/local FHS, you'll often get magically mangled into something that plays nicely with Debian policy and other packages on the system.
<tzero> oh, neat
<tzero> is this a relatively new development in debhelper/cdbs?
<infinity> Depends on how one defines "new".
<infinity> dh(1) came to being in debhelper 7.  Which was in 2008.  But for some of us, that's indeed new. :)
<infinity> The subsequent years have involved educating people to stop using cdbs and old-style debhelper rules.
<infinity> And people writing clever addon modules to keep debian/rules tiny in the face of complex problems.
<nacc> so i think the reason that php-horde-crypt is current stuck in excuses (and failing it's own autopkgtest) is that gpg by default doesn't have any secrets stored. THe debian autopkgtest 'pass' because in their env there is no /usr/bin/gpg and therefore all tests are skipped :/
<nacc> any ideas on how to fix that up? or is there a well-established 'set up gpg secrets for testing' example?
<infinity> nacc: One could argue that the testbed shouldn't have gpg installed, but unlike builds, where we want minimal pollution to build reproducibly, it's almost better to have slightly dirty systems for running tests.
<infinity> nacc: But, that debate aside, if the tests attempt to test a thing when gpg is there, I'd say that (a) gpg is an undeclared test dep, and (b) it should be made to pass said tests.
<nacc> infinity: agreed, i can work on (b), although i think primarily it's just lacking a 'configure a fake gpg secret' (based upon some cursory debugging so far that gpg basically complains about there being no secrets)
<nacc> infinity: but yeah, it probably should be an explicit dep and the tests should be fixed, you're right
<infinity> nacc: As for well-established snakeoil.  I dunno.  Probably not.  But I'd suggest pregenrating an ascii-armored keypair and shipping it with the tests.  Generating keys at runtime is problematic (see, for instance, the kernel hack that starts generating a key at the beginning of the build and hopes enough entropy has been generated by the end that one showed up in the background).
<infinity> And, yes, the kernel has lost that race before. :P
<nacc> infinity: good idea on the keypair
<infinity> Though I think the current iteration of upstream makefiles are more resilient to that, and wait correctly.
<vertago1> I am trying to get a package development environment setup for the avahi package but when I check it out with bzr the debian folder is missing. Is there a step I am missing?
<nacc> vertago1: is avahi actually maintained in bzr?
<vertago1> possibly not
<vertago1> It is on launchpad
<nacc> vertago1: it's not in bzr
<vertago1> ok, so I should use debian's tools?
<nacc> vertago1: i'd recommend using `pull-lp-source`
<vertago1> I am getting an error with that command so I think I will just forego using bzr with what I am working on then
<vertago1> I was trying to figure out the least-headache-way of creating a patch in an existing source package to fix an upstream bug.
<nacc> vertago1: my quick and dirty method:
<nacc> vertago1: pull-lp-source <srcpkg name>
<nacc> vertago1: cd <srcpkg name-version>
<nacc> vertago1: git init . [note this can issues if the upstream also uses git and they provide any .git* files in the tarball]
<nacc> vertago1: git add .
<nacc> vertago1: git commit -m <msg>
<nacc> vertago1: do some changes and either commit them as a quilt patch if it's to the source
<nacc> s/either//
<sarnold> man I have trouble believing -git- is in the quick-and-dirty variant :)
<nacc> vertago1: add a changelog entry
<vertago1> I know git fairly well so it should work for me.
<nacc> sarnold: it's mostly so `git diff` tells you what you broke^Wchanged
<nacc> vertago1: so you're backporting an upstream fix?
<vertago1> no I am writing a fix to hopefully push upstream
<nacc> vertago1: oh, why do you need the ubuntu package at all then?
<vertago1> it makes testing it easier
<nacc> vertago1: for testing?
<vertago1> one of the packages is avahi-daemon
<vertago1> so if I can install the package I don't have to mess with the daemon config.
<vertago1> I just need to add some checks so that avahi-daemon doesn't send invalid utf8 strings over dbus
<nacc> vertago1: understood
<vertago1> *try to send
<nacc> cpaelzer: i think you need an AA to help usher strongswan through, btw
<nacc> cpaelzer: it's in the new queue due to new binaries
#ubuntu-devel 2016-12-21
<nacc> intersting, the phpmyadmin build failure is reproducible locally in a chroot. But if I then immediately run the the same command (phpunit) from the failed schroot, it passes...
<cpaelzer> nacc: I know it is in the queue because of new, already checked with rbasak but he meant there is no special action to be taken by us (other than wait to be accepted)
<cpaelzer> nacc: we certainly can ping for it if it is still waiting in January
<fossfreedom> sil2100: sorry - have been a bit busy.  Just noticed you have approved our merge proposal for lp:ubuntu-cdimage.  Many thanks for that!
<akxwi-dave> Morning all, Just want to let you  know that todays iso doesn't Show the   screen to Try or Install, it goes straight to a live desktop.. our build (Xubuntu) does the same as well
<sil2100> fossfreedom: yw! That being said, I completely forgot to deploy it on cdimage - I'll do it today
<sil2100> fossfreedom: hope all is ready to start getting those images building, right?
<fossfreedom> sil2100: yes - I believe so - I've done an informal build today using our own internal iso builder mechanism - ISO was created and runs correctly.
<fossfreedom> as an aside - I did see the same observation as akxwi-dave (xubuntu) - you dont see the try or install options - just jumps straight to the desktop
<akxwi-dave> bug reported 1651716
<sil2100> fossfreedom: anyway, enabling the crontab for daily budgie builds
<sil2100> fossfreedom: hey! I just got a notification that the today's build of ubuntu-budgie failed
<sil2100> fossfreedom: could you take a look why?
 * sil2100 is a bit swarmed right now
<GunnarHj> Are translations supposed to work for snaps? See e.g. <http://askubuntu.com/q/836483>.
<dobey> GunnarHj: answered
<GunnarHj> dobey: Thanks! Is that a bug in the VLC snap then? Btw, I tried the symlink "sudo ln -s /snap/vlc/1/usr/share/locale/sv/LC_MESSAGES/vlc.mo /usr/share/locale/sv/LC_MESSAGES/vlc.mo", but it didn't help. Is that because stuff outside the /snap folder isn't recognized?
<dobey> GunnarHj: right, because the snap probably doesn't have permissions to read from the root FS (and it shouldn't)
<GunnarHj> dobey: I see. Where do you file snap bugs? (Sorry for being lazy, but just in case you know...)
<dobey> GunnarHj: well it's not a bug with snappy. there isn't a canonical location for filing bugs against specific snaps. you'd need to report it to whomever owns that snap in the store i guess
<GunnarHj> dobey: Ok, I'll take a look. Thanks again!
<gQuigs> how could I go about seeing why a package is not in the zesty archive but is in yakkety (freeipa-server)
<gQuigs> it's not on the ftbfs list
<slangasek> gQuigs: launchpad.net/ubuntu/+source/freeipa/+publishinghistory
<slangasek> also, it's a bit odd that this is in yakkety-updates but not yakkety release, I'm wondering if this is partly my doing
<gQuigs> slangasek: tjaalton.. interesting so it was deleted from the archive in yakkety, and then re-added in -updates?
<slangasek> yes
<slangasek> but then it didn't get forward-copied to zesty, so let me do that now
<slangasek> (done)
<gQuigs> slangasek: thanks!
<lamont> should I be concerned that on zesty, when I ctl-alt-T, I get a new terminal in the current workspace, and generally get magically transported to another workspace?
<mwhudson> morning
<gQuigs> lamont: I'm not seeing anything out of the ordinary with Ctrl-alt-t on my zesty...
<lamont> gQuigs: tbf, my workspace config is 4x4
<gQuigs> ah.. yea, that's a difference..
<sarnold> so finding your old workspace is just like playing hunt the wumpus
<lamont> sarnold: I do have a good idea which one it is.. :p
<mwhudson> slangasek: do you know what the story is with snapd vs ppc64el vs zesty?
<slangasek> mwhudson: snapd vs. autopkgtest is currently a bit of a battle because of what looks like a spread regression; mvo's latest changes in 2.20.1 were thought to give us passing autopkgtests on ppc64el again otherwise
<mwhudson> slangasek: but in fact do not?
<slangasek> mwhudson: ok.  these test failures look different than anything I've seen before; are they new tests?
<mwhudson> slangasek: i have no idea, it's just blocking the transition of go 1.7.4
<slangasek> alright
<mwhudson> i'm not averse to thinking about this if necessary, hadn't got that far yet though
<mwhudson> inappropriate ioctl for device
<mwhudson> i think they'll all that in fact?
<mwhudson> ttyname fails or something obscure like that
<slangasek> mwhudson: one fixed test vs. 2.16; one newly failing test; and one new test that fails
<stgraber> mwhudson: inoappropriate ioctl for device on ppc64el only?
<mwhudson> stgraber: seems so
<slangasek> and yes those could be buggy ttyname-related assumptions
<slangasek> could be test bug, or code bug - anyway, not anything we need to block on, I'll unblock it
<stgraber> mwhudson: we had an issue similar to that in LXD with our exec code which needs to change the terminal mode and do some ioctls. The most common go library for this (kr/pty) assumes that the ioctls are the same on all architectures, which is wrong.
<mwhudson> stgraber: hahaha ugh
<stgraber> mwhudson: that's why I wrote: https://github.com/lxc/lxd/tree/master/shared/termios
<stgraber> mwhudson: which uses cgo and the C library to do the right thing
<mwhudson> can we get them added to x/sys/unix or something?
<mwhudson> (apart from that not existing on powerpc, sigh)
<slangasek> mwhudson: don't worry, powerpc shortly won't exist either
<mwhudson> slangasek: NO MORE GCCGO!!
<mwhudson> sounds pretty good to me
<stgraber> mwhudson: we probably could and someone might have already done it. But we're not planning on moving LXD to sys/unix anytime soon since we do care about powerpc for xenial.
<mwhudson> stgraber: hm, snapd does not appear to use kr/pty but it could be something similar
<stgraber> mwhudson: oh, nevermind, the problem was the go-crypto terminal code
<stgraber> mwhudson: so you may want to grep for that instead
<stgraber> golang.org/x/crypto/ssh/terminal
<mwhudson> stgraber: well snapd certainly does use x/crypto
<stgraber> IIRC the most visible one was IsTerminal() returning false despite being attached to a tty
<mwhudson> stgraber: yeah, that seems pretty likely to be the problem
<stgraber> https://github.com/lxc/lxd/commit/3cd9adce8d3dafc679f5ef19a5cb3a4410e19208 is what we did to fix this
<stgraber> in the go-crypto code, they have ioctlReadTermios which they define in _linux.go as:
<stgraber> const ioctlReadTermios = 0x5401  // syscall.TCGETS
<mwhudson> stgraber: someone should tell the snapd developers i guess!
<mwhudson> (i'll file a bug after this call i'm on)
<stgraber> though I'm confused because looking on ppc64el the ioctls for TCGETS and TCSETS match what I have on amd64, so not exactly sure what was the actual bit that deferred (maybe the termios struct, maybe one of the other arguments, ...)
<stgraber> anyway, I'm pretty sure that if you run their testsuite again using my re-implementation (s/terminal/termios/g), it'll fix whatever failure they've got right now
<stgraber> mwhudson: so if I'm parsing the britney output properly, the only thing which is holding lxd and probably most of the Go stack in proposed is that snapd autopkgtest failure on amd64 and i386
<mwhudson> stgraber: oh, the "snapd/2.18+17.04ubuntu3" failure
<stgraber> yup
<mwhudson> stgraber: you could retry those (but not ppc64el!) against the snapd in proposed?
<mwhudson> or i could
<stgraber> not sure how to get autopkgtest to do that... looking at the history, we did get a succesful run 10 hours ago for snapd 2.20.1 in proposed, but I'm not sure if it was using the new x-net-dev or not
<mwhudson> stgraber: url hacking, you add &trigger=$PKG/$VERSION to the retry url
<mwhudson> as snapd doesn't use any dynamic linking stuff i really doubt a new/old x-net-dev matters
<stgraber> ah, well, if it doesn't use shlibs, then it means we're good as the latest snapd was built after the new x-net-dev was uploaded and I see an autopkgtest pass for it from 10 hours ago
<slangasek> you will shortly be able to retrigger the snapd tests without getting fancy at all, since I overrode the ppc64el failure and it's now on its way into zesty
<stgraber> so I'm tempted to just hint snapd 2.18+17.04ubuntu3 as badtest which will clear that particular issue and probably let all of Go in. AFAICT the current snapd was built with the new x-net-dev and passed adt less than 10 hours ago, so we can just ignore the test failure from the old (currently in release pocket) snapd.
<stgraber> especially as said snapd will be replaced by a new one from slangasek which should pass adt fine
<mwhudson> oh heh i just requested the retries
<mwhudson> but overriding makes sense to me i think
<stgraber> the weird thing with those retries is that you don't actually tell autopkgtest what version of snapd you want to test against, you only tell it what triggered the test. So I don't see how retrying will now decide to take the snapd from proposed as opposed to the one from the release pocket which it's been testing against so far.
<mwhudson> i don't understand it either but it works
<slangasek> stgraber: the way you do it is by telling it the test is triggered by both the new snapd and the new $whatever
<stgraber> slangasek: ah, how do you pass multiple triggers in the URL?
<slangasek> &trigger=foo&trigger=bar, afaik
<mwhudson> stgraber: trigger=a$2Fb&trigger=c%2Fd
<stgraber> ah, cool, that's going to be useful :)
<stgraber> mwhudson: I see your retries on autopkgtest.ubuntu.com now so will wait to see what happens
<mwhudson> stgraber: looks like it worked
<jgrimm> nacc, $ usd clone nspr
<jgrimm> 12/21/2016 17:15:34 - ERROR:Unable to checkout ubuntu/devel, does lpusip/ubuntu/devel exist?
<jgrimm> nacc, ^^ possibly needs a re-import?
<nacc> jgrimm: running it now, to see
#ubuntu-devel 2016-12-22
<nacc> jgrimm: check now?
<nacc> jgrimm: on nspr
<nacc> infinity: fwiw, i think i figured out the horde-crypt failure. It's actually testing things correctly (using the gpg binary and setting up its own test-internal gpg keys). But it's using deprecated/ignored options to gpg :)
<mwhudson> slangasek: oh i didn't realize powerpc was going away quite that much
<nacc> wtf gpg
<nacc> infinity: have to set GPG_TTY=$(tty) and pass '--pinentry-mode loopback' and the tests seem to work
<jgrimm> nacc, worked, thanks!
<nacc> jgrimm: great, sorry about that
<jgrimm> no worries at all!
<nacc> infinity: figured out most of them! gpg changed the output and the tests were parsing it, as well..
<tsimonq2> Ok, deciding to pick up bug 1516454 again.
<ubottu> bug 1516454 in gnumeric (Ubuntu) "Gnumeric menu -> Help -> About Gnumeric -> "License" or "Credits" buttons don't work" [Low,In progress] https://launchpad.net/bugs/1516454
<tsimonq2> So I'm curious if anything stands out to anybody, I trid the obvious solution of editing the GTK property as I believe it was missing something?
<Umeaboy> Hi!
<Umeaboy> Who's the maintainer of the mkvtoolnix package in Ubuntu 16.10?
<Umeaboy> Hmmmmmmmmmm. I think I better take this in #ubuntu-app-devel.
<sarnold> isn't that channel for the phones?
<sarnold> given the long list of debian version numbers here https://launchpad.net/ubuntu/+source/mkvtoolnix/+publishinghistory I suspect there's no one at ubuntu that 'tends' to this package -- it mostly appears to be pulled in from debian unchanged, until toolchain issues cause rebuilds
<Umeaboy> It has only been pushed to the development release of Ubuntu.
<Umeaboy> Seems odd since 9.6.0 is a stable release and not a development release.
<Umeaboy> That's my idea of stable anyhow.
<mwhudson> stgraber, slangasek: i finally filed https://bugs.launchpad.net/snappy/+bug/1651936
<ubottu> Launchpad bug 1651936 in Snappy "autopkgtests fail on ppc64el" [Undecided,New]
<sarnold> are all the failures coming from expect, and are they all password-related?
<sarnold> oh I guess not, there's also this:
<sarnold> mesg: ttyname failed: Inappropriate ioctl for device
<sarnold> but I suspect that's the usual glibc-vs-kernel disagreement about tty devices in filesystem namespaces
<sarnold> also tests/main/chattr -- that's an odd one
<slangasek> mwhudson: yup
<mwhudson> sarnold: ah hah, go would be particularly susceptible to that
<fossfreedom> sil2100: thanks - got an autoemail from launchpad to say you have "fix released" our merge request for lp:ubuntu-cdimage
<sil2100> fossfreedom: np, did you get my yesterday's message about the image builds failing?
<fossfreedom> sil2100: hmm - have looked.  nothing :(
<sil2100> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-budgie/zesty/
<sil2100> We might be missing some enabling of this project on livefs builders
<sil2100> cjwatson: hello! Are you still around today by any chance?
<sil2100> fossfreedom: might be a bit hard to get things done, a lot of people are on holidays already
<fossfreedom> sil2100: ah - yes. with xmas on the weekend ... good excuse to have a very long break!
<cjwatson> sil2100: what do you need?
<sil2100> cjwatson: hello! We have enabled a new ubuntu flavor in cdimage, ubuntu-budgie - it seems the builds are failing since there's still something missing in the builders to enable that? http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-budgie/zesty/daily-live-20161221.log
<cjwatson> sil2100: do you know about the production config branch on nusakan?
<sil2100> cjwatson: I see it but never 'used' it before I think
<cjwatson> sil2100: that's what you need to edit :)
<sil2100> Ah :)
<cjwatson> sil2100: did anyone create the livefs objects in LP?
<sil2100> cjwatson: I don't think so...
<sil2100> cjwatson: is this also something I can do, or does require some special powers?
<cjwatson> You should be able to; let me just look it up
<cjwatson> lp-shell production devel -> lp.livefses.new(owner='/~ubuntu-cdimage', distro_series='/ubuntu/zesty', name='ubuntu-budgie')
<cjwatson> doesn't need any special powers since you're just trying to build it for amd64 and i386, so no devirtualisation needed
<sil2100> cjwatson: ok, let me try running this then, thanks :)
<cjwatson> then add it to livefs-launchpad in the production config branch
<sil2100> And I'll edit the production config then
<sil2100> Thanks for the pointers!
<cjwatson> and make sure to pull that onto nusakan of course
<ginggs> matplotlib, python-stdlib-extensions and pandas show test regressions in lmfit-py on armhf - where lmfit-py is not installable since python-pandas removal. What needs to be done to let them migrate?
<jabowery> A July Debian bugfix has not made it into xenial updates.  The advice at the launchpad unassigned bug tracking comments is: A thing the maintainer perhaps could do would be to create a launchpad mirror of the sourceforge repo maxima's code is kept in - and then to initiate a nightly build ppa for maxima.  https://bugs.launchpad.net/ubuntu/+source/maxima/+bug/1602941/comments/8
<ubottu> Launchpad bug 1602941 in maxima (Ubuntu Xenial) "Draw cannot be loaded in 16.04 (Repackage needed since gcl has changed?)" [Undecided,Confirmed]
<jabowery> How does one go about identifying or becoming that "maintainer"?
<tumbleweed> ubuntu packages usually don't have maintainers, as such
<tumbleweed> I'd SRU that patch into xenial
<jabowery> What does SRU stand for?
<tumbleweed> !sru
<ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<tumbleweed> can you find the patch that fixes the bug?
<dobey> it looks like 5.37.2-9 could be synced from debian to xenial-updates (and maybe yakkety-updates), as -8 is what's in ubuntu
<dobey>    * Bug fix: "maxima do not load the draw package.", thanks to Renato
<dobey>      Alvarez Nodarse (Closes: #803251).  rework sys:*load-pathname* patch
<tumbleweed> it's a different -8
<dobey> ?
<tumbleweed> I mean, yakkety is already fixed
<cjwatson> maxima/xenial == maxima/yakkety
<tumbleweed> I've never heard of syncing into a stable -updates
<cjwatson> *zesty* has a different -8
<dobey> right
<tumbleweed> oh, yes, that's what I was thinking
<dobey> yakkety and xenial have the same package
<cjwatson> it's certainly *possible* to copy into a stable -proposed and have it verified, but it wouldn't suit the tools very well because it wouldn't refer to a Launchpad bug
<cjwatson> so verification wouldn't work right
<cjwatson> better to just cherry-pick into 5.37.2-8ubuntu1, even if that ends up essentially identical to 5.37.2-9
 * tumbleweed has a poke at it
<jabowery> So I take it I should pursue a different procedure than submitting an SRU on the debian fix to maxima?
<nacc> jabowery: SRU is not a debian thing
<nacc> jabowery: SRU is an ubuntu thing :)
<nacc> jabowery: oh i see what you were saying -- the right approach is to SRU the debian change to ubuntu's packages where relevant, but I think tumbleweed may be doing it
<jabowery> Great!
<tumbleweed> I did it. jabowery will you test it once it's published?
<tumbleweed> subscribe to the bug now, if you haven't
<jabowery> Sure I'll test it.  I'm subscribed to https://bugs.launchpad.net/ubuntu/+source/maxima/+bug/1602941
<ubottu> Launchpad bug 1602941 in maxima (Ubuntu Xenial) "Draw cannot be loaded in 16.04 (Repackage needed since gcl has changed?)" [Undecided,Confirmed]
<jabowery> I presume that means I'll receive an email notifying me it has been published.  I've just received an email saying "** Changed in: maxima (Ubuntu)        Status: Confirmed => Fix Released  ** Also affects: maxima (Ubuntu Yakkety)    Importance: Undecided        Status: New", but that's not a notice that it's been published, right?
<tumbleweed> jabowery: you will
<nacc> infinity: mdeslaur: after some wrangling, debian maintainer has bumped the abi for imagemagick :)
<smoser> hey, i'm using apt.Cache() from python apt package.
<smoser> im' using it on zesty, and want to be able to apt.Cache(rootdir=foo)
<smoser> cache.update()  is failing
<smoser> due to i think no keyrings
<smoser> to read xenial data
<smoser> http://paste.ubuntu.com/23669428/
<smoser> what is the right way to tell it that i want it to use the old keyrings ?
<nacc> smoser: add_key_from_keyserver? (just paging through the files/APIs)
<smoser> whered you see that ?
<nacc> smoser: it's in apt/auth.py
<smoser> i dont think iw ant to add from a keyserver, but i do wan tot add a key
<nacc> you can also add from a file, i think
<nacc> add_key_from_file
<nacc> or even just add_key :)
<smoser> nacc, hm... no dice.
<smoser> all that does is run apt-key
<nacc> smoser: rbasak: i think this might have been a thinko on my part in the remote addition for `usd clone`: http://paste.ubuntu.com/23669494/; right now, the remote branches in `git branch` do not show up as remote, because they are all fetched into refs/heads (which is the local branches). Thoughts?
<nacc> smoser: oh, hrm
<sil2100> fossfreedom: ok, with all the builder bits enabled, looks like the images are still failing - I suppose it might be something missing in livecd-rootfs?
<sil2100> fossfreedom: from what I see you didn't submit any changes for ubuntu-budgie there? I suppose that should be needed? You mentioned the builds succeeded locally on your build environment though
<fossfreedom> sil2100: to be honest - I didnt know there was yet another project to make changes to :(
<fossfreedom> sil2100: this project? https://launchpad.net/livecd-rootfs
<fossfreedom> looking at the code ... not sure where to make changes.
<fossfreedom> maybe this?  - looks to have some flavor specifics http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/config
<fossfreedom> sil2100: ok - have created a branch with changes that are very similar to ubuntu-gnome's - https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1652144
<ubottu> Launchpad bug 1652144 in livecd-rootfs (Ubuntu) "start building Ubuntu Budgie images" [Undecided,New]
<sil2100> fossfreedom: ok, let me try taking a look at them but it's a bit lateish here
<sil2100> fossfreedom: ok, quick thing - could you switch the changelog entry from 'zesty' to UNRELEASED?
<sil2100> We only put series names once the package is released
<fossfreedom> yep - doing it now
<sil2100> Thanks
<sil2100> Ok, I'll try to release this, but then I'm going off ;)
<sil2100> fossfreedom: push the change to the branch, I'll merge it, prepare for release and run a test build
<fossfreedom> sil2100: ok - thanks - pushed
<sil2100> fossfreedom: ok, new livecd-rootfs building
<fossfreedom> sil2100: much appreciated!  Have a good night! ... and if you are off for xmas - have a great hols.
<sil2100> fossfreedom: thanks for the quick response btw, we might get this building before my EOY ;)
<sil2100> fossfreedom: same to you!
<sil2100> fossfreedom: I go off now, the package still didn't migrate from -proposed so I can't run the job
<sil2100> But when I see it migrated later today I'll just kick a quick build - if not, tomorrow's daily build should catch any possible issues
<sil2100> o/
<jgrimm> nacc, http://paste.ubuntu.com/23670285/
<jgrimm> nacc, ah.. %% will get me what I want.
<nacc> jgrimm: ah yes, but even that is incorrect
<nacc> err, no, you're right
<nacc> it should be fine, sorry!
<nacc> jgrimm: can you file a bug on that (or put a comment in the one already filed for logical tag issues)
<jgrimm> yeah, %% should escape the % that you've used to represent : for
<jgrimm> nacc, yeah, you could probably push out a warning for that at least
<jgrimm> will do
<nacc> jgrimm: yep, we can do a quick sub in the string to escape certain characters (I think % is the only one we'd need to, actually)
<jgrimm> yeah, i had guessed that from the bug you had against logical tag
<nacc> infinity: in case you care, and i hope you don't, i think php-horde-crypt's failures are all related to the gpg2 migration: http://paste.ubuntu.com/23670714/. Going to try sending htat upstream as well
<nacc> infinity: and nm, i found a even smaller patch for upstream, which doesn't rquire the killall ugliness
#ubuntu-devel 2016-12-23
<RAOF> I'm *pretty* sure that the switch to systemd-resolved has crazily broken DNS in my lxc containers.
<RAOF> And with that, Happy Holidays! I'm off!
<ginggs> morning! matplotlib, python-stdlib-extensions and pandas show test regressions in lmfit-py on armhf - where lmfit-py is not installable since python-pandas removal. What needs to be done to let them migrate?
<mitya57> Can some SRU team member please review owncloud-client in Yakkety queue? It is the second part of the fix for the serious bug (because owncloud-client makes the whole desktop unusable, LP: #1635577).
<ubottu> Launchpad bug 1635577 in unity (Ubuntu) "memory leak in unity-panel-service" [High,Triaged] https://launchpad.net/bugs/1635577
<Tribaal> hi all - I just upgraded to zesty (finally!), but am a bit surprised by seeing 2 network-related applets loaded? Is that known/desired?
<Tribaal> what I mean is: https://www.dropbox.com/s/2553cau97dadn86/applets.png?dl=0
<Tribaal> and that "missing icon" shows flight mode, VPN and wifi switches
<xnox> BenC, hello! long time no speak.
<BenC> xnox: Hello
<xnox> BenC, I don't see you idling on #ubuntu-powerpc and your last upload is from 2013. Haven't seen you during most recent UOS powerpc discussion either. So you are not quite as active as you used to before, way back when.
<xnox> BenC, are you picking up maintainance in Debian? as powerpc port there got relegated to non-release one.
<BenC> Agreed, but that doesnât preclude me from being contacted when the TB claims to have contacted the community.
<xnox> BenC, currently we see a lot of fallout from powerpc port. FTBFS + lack of toolchain maintainance and support.
<xnox> BenC, we did reach out to a few people, including some new company in UK that also does powerpc hardware.
<xnox> BenC, from my point of view, irrespective of people and companies involved.
<xnox> lack of golang-go support and gcc/binutils support/development upstream is a huge red flag.
<BenC> Itâs an obstacle that can be overcome, though.
<xnox> BenC, as far as I undersntad big endian port is not tier1 in gcc upstream =/
<BenC> And seriously, I fixed haskell on ppc when it was a huge mess.
<xnox> BenC, but seriously, lack of openstack and golango is a blocker to run a lot of infrastructure that we depend on.
<xnox> most launchpad builders are in scalingstack now (s390x will be very soon)
<xnox> and we run autopkgtests based on that. And there is no support for docker (lack of golang) and other go based tools (e.g. juju)
<BenC> I understand that I personally havenât devoted a lot of time lately to powerpc, but everyone in Ubuntu who should know, knows I am THE guy that handles ppc and if some discussion came up, I should have gotten a courtesy poke.
<BenC> That not happening is egregious to say the least.
<xnox> BenC, without firefox, golang, and openstack => i do believe powerpc is a viable platform for any new workloads on either server or desktop.
<BenC> Regardless of the outcome (which probably would havenât changed), it was not an oversite, it was a bad choice.
<xnox> hence 2016-04 + 5 years is the timeframe to get people off it.
<BenC> No one is getting off of it. PPC is not a dead platform.
<cjwatson> lack of openstack is a red herring FWIW
<xnox> BenC, part of the TB decision to announce now about removal for feature freeze, to give a really huge public red warnings, such that if there is actuall demand for this port, to commit to revitalise it.
<BenC> Iâm not committing to support something that was literally yanked out from under me without so much as a /m on IRC.
<BenC> Iâve put years and hundreds of hours into already and it got me nothing.
<cjwatson> the reason powerpc isn't in scalingstack yet is that we haven't yet finished deploying the new scalingstack region with new (already-written) charms that will let us run builders for an alternate architecture that isn't runtime-switchable
<cjwatson> so please don't use scalingstack as a reason here, it's not the port's fault
<xnox> ack.
<xnox> cjwatson, my understanding was that it's possible to do powerpc virtual machines on ppc64el hardware, but not on powerpc hardware. Or is that a wrong statement too?
<BenC> Thatâs bull
<cjwatson> just don't use this as a reason if you don't understand it :P
<BenC> I run VMs on my hardware with KVM all the time.
<cjwatson> but in any case that's irrelevant for scalingstack, since we intend to run it on ppc64el hardware
<cjwatson> (seeing as we have it)
<xnox> ack.
<xnox> what about firefox and golang then?
<cjwatson> juju has decided not to support running on 32-bit AIUI, but that's not fatal
<BenC> Iâve fixed firefox on ppc at least 4 times in the past.
<BenC> Go lang, Iâve nevr looked at but it canât be insurmountable.
<xnox> i think it needs an upstream buildbot
<xnox> (firefox)
<xnox> rather than keep on fixing it downstream.
<BenC> All technical reasons aside. If the TB decided that, I support the TB.
<xnox> BenC, from my point of view i'm more inclined to kill i386 & armhf than powerpc, but all of them are on my personal "no longer relevant list".
<BenC> What I donât support is an out right lie that the TB contacted relevant persons in their decision.
<xnox> e.g. we have been seeing i386-only graphical/desktop bugs in the last development cycle which nobody notices.
<cjwatson> armhf> geez
<cjwatson> hello realism
 * xnox wants 128bit computers for christmas
<xnox> =)
<cjwatson> I don't think architecture removal is a fit subject for trolling :P
<Son_Goku> BenC: golang should be working on ppc64 and ppc64le
<Son_Goku> at least here in Fedora, we have it working: https://koji.fedoraproject.org/koji/buildinfo?buildID=822120
<Son_Goku> the only architecture we don't have golang working on is s390 (it works on s390x)
<cjwatson> Son_Goku: "powerpc" is the Ubuntu name for the 32-bit big-endian port
<fossfreedom> anyone still around from the CD Image Team able to have a quick look at this please? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-budgie
<cjwatson> Son_Goku: it works on Ubuntu ppc64el too
<Son_Goku> xnox: I agree with you on armhfp, only because it's a huge nuisance to get working
<Son_Goku> why can't everyone just be on proper aarch64 :)
<Son_Goku> cjwatson: you guys don't support ppc64 (big endian), I guess?
<cjwatson> Son_Goku: not at the moment
<Son_Goku> ehh, if you don't have to, don't
<dobey> Tribaal: indicator-network shows up in zesty because of how systemd works, and there not being a unity8 systemd session thing yet
<dobey> Tribaal: there's an open bug about it already
<pete-woods> also, a fix in this silo https://bileto.ubuntu.com/#/ticket/2321
<fossfreedom> cjwatson: still around? I believe the reason by the builds for Ubuntu Budgie are failing is because there are no tasks in this project - lp:~ubuntu-core-dev/tasksel/ubuntu  ... correct assumption?
<cjwatson> possibly but I'm afraid I'm out of time to look at that
<cjwatson> there's an update script in tasksel, should just need updating the Makefile for budgie and then running it, hopefully
<fossfreedom> cjwatson: ok - thanks for your help.  I've created a bug report and proposed a merge.  Hopefully someone can pick this up in the new year.  cheers.
<hippybear> How do I prepare this pkg for Ubuntu? http://ppa.launchpad.net/nilarimogard/webupd8/ubuntu/pool/main/y/youtube-dlg/
<xnox> dobey, i have a fix for it too!
<xnox> Trevinho, ^
<xnox> indeed pete-woods pointed it out.
<dobey> xnox: eh?
<dobey> oh
<dobey> you mean Tribaal there, not Trevinho i guess
<Tribaal> I just forgot I had unity 8 installed TBH
<xnox> Tribaal, hehe.
<xnox> i should really land that silo, I guess.
<xnox> then again, i am on holiday.
<xnox> doko, python 3.6 is so nice, i want it default =)
<Tribaal> xnox: it could totally wait until next year as far as I'm concerned :)
<Tribaal> Python 3.6 <3
<dobey> that silo isn't ready to land
<dobey> xnox: ^^ so don't worry about it :)
<xnox> ack
<dobey> the other silo we were asking you to land, has some issues, too :(
<xnox> happy new year =) didn't get a chance to look into it
 * xnox was EOY yesterday
<dobey> well it's not my fault you're on irc :)
<karstensrage> where is the source code for resolvconf?
<Son_Goku> in a graveyard
<Son_Goku> deep in Debian Alioth
<Son_Goku> where zombies hack on things to make our lives more confused
<nacc> karstensrage: do you mean the ubuntu package?
<nacc> karstensrage: you can use `pull-debian-source` or `pull-lp-source`
<cjwatson> https://anonscm.debian.org/cgit/resolvconf/resolvconf.git appears to be an active git repository
<karstensrage> i mean the actual source code
<karstensrage> not the debian package
<tumbleweed> it's a native package, so that presumably is the "actual sourcecode"
<nacc> karstensrage: well pull... get you the source for the package. Given a homepage of: http://alioth.debian.org/projects/resolvconf/, cjwatson's link seems correct
<nacc> https://alioth.debian.org/scm/?group_id=30851 as well
<Son_Goku> at least it's more active than os-prober
<Son_Goku> ....
<cjwatson> the Debian package is a superset of the source code, anyway
<nacc> yep
<Son_Goku> ironically, given that os-prober is used in more distros, it should be less dead
<cjwatson> yeah, we should get round to doing a patch application run there
<karstensrage> so there is no C code for resolvconf its just a bunch of scripts?
<nacc> karstensrage: doesn't appear to be any
<karstensrage> hmm
<karstensrage> so i am writing an NSS library like nss_ldap
<karstensrage> 16.04 fails to boot up if the library is ithere
<karstensrage> its due to resolvconf calling getpwnam("*")
<karstensrage> so where would it be doing that?
<nacc> karstensrage: how do you know resolvconf is the one doing this?
<karstensrage> i log it
<karstensrage> getpid and then open /proc/pid/comm
<nacc> karstensrage: resolvconf itself is just a shell script
<sarnold> karstensrage: execsnoop may give you some extra visibility on what's going on https://github.com/brendangregg/perf-tools
<sarnold> it might be hard to execute it early enough though :/
<Son_Goku> cjwatson: there's even a bug in rhbz where there are complaints that patches sent upstream aren't getting applied in os-prober
<Son_Goku> cjwatson: https://bugzilla.redhat.com/show_bug.cgi?id=875356
<ubottu> bugzilla.redhat.com bug 875356 in os-prober "OS prober is slow" [Unspecified,New]
<cjwatson> ok, we clearly haven't been doing well there.  bugging me about it tonight isn't going to work though, exhausted
<cjwatson> so rain check please?
<Son_Goku> cjwatson: sure
<cjwatson> can do without the highlights about it in multiple channels
<Son_Goku> cjwatson: did you not see my messages this morning in #debian-boot?
<Son_Goku> cjwatson, yes, of course, I was trying to get somebody's attention, though :/
<cjwatson> that's what I mean by multiple channels
<cjwatson> and it was dinnertime so I didn't reply straight away
<Son_Goku> what time zone are you in?
<cjwatson> Europe/London
<Son_Goku> ah
<Son_Goku> that explains it
<Son_Goku> my morning was your evening
<Son_Goku> sorry
<Son_Goku> as long as you're aware of it and can do something about it, then everything will be fine
<cjwatson> I do need a break for a while to have Christmas/Hanukkah and stuff, but hopefully after that
<Son_Goku> that's fine
<Son_Goku> all I ask is for some acknowledgement so that everyone knows upstream isn't dead :)
<sarnold> I don't want to go on the cart
<hippybear> I have a question about the packaging process. I am following this currently http://packaging.ubuntu.com/html/packaging-new-software.html#starting-a-package but im not understanding how to start a new package
<hippybear> this is just changing a package that already exists
<cyphermox> cjwatson: Son_Goku: what about os-prober? or is this purely an upstream thing?
<cyphermox> disclaimer: I'm not completely there, I have some food cooking for tomorrow I need to check on.
<Son_Goku> cyphermox: upstream os-prober has been kind of dead-ish for the past year, and various distros (Fedora, openSUSE, Mageia, etc.) have been forced to heavily patch os-prober to make it functional because they languish... somewhere (in the ML?)
<cyphermox> Son_Goku: ah, ok
<Son_Goku> this is particularly problematic in the Fedora community, as we keep fixing things and now the maintainer has stopped bothering trying to send stuff upstream because nothing happens
<Son_Goku> now a couple of folks are saying that we should fork it because Debian upstream doesn't seem to care and everything is stalling waiting for them to review and merge things
<Son_Goku> (I particularly dislike forking for this purpose, because it's usually quite easy to solve that problem without forking)
<cjwatson> yeah, we'd definitely prefer to avoid that, it would be a bunch of unnecessary annoyance
<Son_Goku> that's why I was trying to get someone's attention this morning
 * cjwatson adds a card on their trello board so that it stands some chance of actually happening
<Son_Goku> again, sorry for being rude to you, but I'd really rather not end up in another situation where this happens again
<Son_Goku> the last time this happened with a debian upstream project, we wound up having two implementations of update-alternatives
<cjwatson> eesh, that
<Son_Goku> and that situation *still* persists
<Son_Goku> technically, there are three now :/
<Son_Goku> because one didn't know about the other fork
<cyphermox> cjwatson: you're upstream for os-prober?
<cjwatson> tbf the period when dpkg was at best semi-maintained wasn't fun for Debian either
<cjwatson> cyphermox: well, d-i committer, and I've done a bunch on it in the past
<cyphermox> ack
<cjwatson> not for a while because I've generally not done much with d-i
<cyphermox> well in that case I could just as well merge patches
<cjwatson> but grub2 wants it to work well, so ...
<cyphermox> yep
<Son_Goku> cjwatson: I understand, we had a similar situation with rpm a few years ago
<cjwatson> cyphermox: be my guest :)
<Son_Goku> it seems we're all doomed to have these happen to us :)
<cyphermox> cjwatson: I'll have a look, but not this weekend :/
<cjwatson> indeed!
<Son_Goku> oh, and if you're curious: there's the original Debian Perl implementation of update-alternatives, which was forked by Mandriva to be used for its distro, now used by OpenMandriva
<Son_Goku> separately, Red Hat reimplemented it in C for the Red Hat/Fedora family, and that implementation is used today in Fedora, and Mageia just switched to it
<nacc> hippybear: you might start with debmake
<cjwatson> we have guests for dinner on Sunday so I need to do All The Tidying, and I'm singing a solo at church on Saturday night ...
<nacc> hippybear: you have an entirely new package?
<Son_Goku> and SUSE uses a modified version of the original Debian Perl version
<Son_Goku> and Debian itself independently rewrote it later into C and uses that version now
<Son_Goku> so... fun times :/
<Son_Goku> of course, SUSE also did the thing where they reimplemented chkconfig in Perl, and that version (not the original one in C) is what's packaged in Debian
 * cjwatson looks at SUSE's man-db patch again
<cjwatson> lalala I wish I hadn't done that
<Son_Goku> sometimes I wonder about SUSE...
<cyphermox> cjwatson: run before it's too late
<cyphermox> and happy holidays; I'm off to check on the cooking and various other preparations ;)
<Son_Goku> sometimes I wonder if I should bother filing bugs against chkconfig and other things like it in Debian
<Son_Goku> then I remember that people rarely respond to bugs in debbugs, and then I walk away
<Son_Goku> even LP has a better track record than debbugs
#ubuntu-devel 2016-12-24
<cjwatson> Son_Goku: I question your anecdata there, THB
<cjwatson> *TBH
<cjwatson> I've heard lots of people say the exact opposite
<Son_Goku> really?
<cjwatson> really
<cjwatson> I imagine it depends very strongly on the maintainer/subscribers
<Son_Goku> well, the track record for both is really low for me
<Son_Goku> so it's not hard for one to surpass the other
<cjwatson> some maintainers are excellent in either system, some are overworked, such is life
<Son_Goku> yeah, I know
<Son_Goku> god knows I've been that way about stuff, too
<Son_Goku> but I do really hate debbugs
<Son_Goku> it's a horrid system
<Son_Goku> I like how launchpad does quite a few things, I just wish it wasn't an enormous mess to set up and basically not portable to Python 3
<cjwatson> I like both in different ways
<cjwatson> and hopefully we'll prove you wrong about Python 3 eventually :)
<Son_Goku> what is there to like about debbugs?
<Son_Goku> cjwatson: I *really* *really* hope so
<cjwatson> you're being pretty aggressive about it so I don't really want to get into it quite honestly
<Son_Goku> meh, I'm in a sour mood (I've been sick for nearly 9 days)
<sarnold> may I recommend reading?
<Son_Goku> sarnold: reading what?
<sarnold> anything :) your local library likely has recommendations if your reading pile has grown too short :)
<Son_Goku> don't have one :(
<cjwatson> but I like its simplicity and lack of bells and whistles; sometimes that's pretty refreshing
<Son_Goku> cjwatson: simplicity is nice
<cjwatson> also I really really like the ability to clone bugs
<cjwatson> I don't often see trackers with that feature
<Son_Goku> we have that feature in the Red Hat Bugzilla
<cjwatson> fair enough
<Son_Goku> it is something that I miss from GitHub projects, though
<Son_Goku> GitHub's issue tracker leaves a ton to be desired
<cjwatson> and its version tracking is a really good (if complex) bit of data gathering
<Son_Goku> cjwatson: isn't that just special emails with extra header information?
<cjwatson> no
<cjwatson> it's aware of the version history of each package and its status in different suites
<Son_Goku> that *is* handy
<cjwatson> and can track bugs present/absent in different branches etc.
<Son_Goku> rhbz is unfortunately not wired up that way (even though I know it can do it...)
<cjwatson> LP -> python3 is basically blocked pretty hard behind porting the build system to pip/virtualenv
<Son_Goku> what, so the Zope components are already ported?
<sarnold> I thought twisted was the sticking point?
<cjwatson> because there are a bunch of key dependencies we can't upgrade until we've done that, for arcane reasons
<cjwatson> Zope is mostly ported upstream
<cjwatson> twisted is also mostly ported upstream, maybe with some missing bits and pieces
<Son_Goku> bzr is not ported, right?
<sarnold> wow, that must have been .. intense. :)
<cjwatson> no, we'd have to do something about that, ditto storm and others
<Son_Goku> I can only imagine the pain that had to happen for zope and twisted
<cjwatson> we might well be able to carve out some of our bzrlib dependencies a bit nowadays
<cjwatson> not sure, it hasn't yet been really worth looking into that
<cjwatson> but the first thing is to get onto xenial and onto pip
<cjwatson> (and revision control into git, which should be in the new year assuming that our department's jenkins setup gets some necessary tweaks applied)
<cjwatson> I certainly gather twisted was pretty heavy lifting
<cjwatson> quite a few of LP's bzrlib dependencies are basically because there happened to be some handy bit of code in the bowels of bzrlib and the people working on that bit of LP knew that bit of bzrlib ...
<cjwatson> so e.g. bzrlib.tests.multiply_tests (can be replaced by testscenarios), or bzrlib.lock.WriteLock used in lp.testing.pgsql and surely there's some other replacement for that
<cjwatson> I suspect that with a bit of effort most of the rest could be made into some kind of RPC call to the codehosting server and we could just consolidate all the bzrlib use in codehosting, at which point the rest of the codebase could avoid needing to import it.  Maybe.
<cjwatson> e.g. our git hosting is structured so that all the use of pygit2 is entirely confined to the git server
<Son_Goku> it's too bad that lp never supported hg
<Son_Goku> it would have made for a first-class hosted hg system
<cjwatson> yeah, perhaps; but the time has probably passed
 * Son_Goku shrugs
<fossfreedom> anyone from the ubiquity slideshow team around?  our (Ubuntu Budgie) proposal is kind of stuck - any chance of a review please? https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/1644976
<ubottu> Launchpad bug 1644976 in ubiquity-slideshow-ubuntu (Ubuntu) "ubuntu budgie slideshow proposal" [Undecided,New]
#ubuntu-devel 2017-12-18
<cjwatson> I am not completely sure that LP forbids copying source+binaries from a PPA to the primary archive if you aren't an archive admin.  I suspect it doesn't actually forbid this but should.
<cjwatson> It should be possible to test on staging; the publisher won't run, but the copy job will (eventually).
<cjwatson> (Tests that need the publisher to run need to be done on dogfood.paddev.net with assistance from an LP developer.)
<tsimonq2> cjwatson: As far as I remember, the only way to do that is through the CI Train.
<tsimonq2> Otherwise an archive admin is needed.
<tsimonq2> (And that sort of thing would be documented in the CI Train logs publicly anyways.)
<cjwatson> tsimonq2: From code inspection I believe that you are mistaken, but feel free to prove me wrong.
<cjwatson> (I think your understanding is how it *should* work, but ...)
<tsimonq2> Well, anybody with upload access can use the tool, but an archive admin has to approve it because it comes from a PPA.
<tsimonq2> (I remember this from when we had problems landing something with the CI Train so I asked Gianfranco to use copy-package and he needed to poke an archive admin.)
<tsimonq2> cjwatson: Maybe there's an edge case I'm not accounting for, but as far as I remember, that's how it works.
<cjwatson> tsimonq2: I don't believe any of the above is true.
<tsimonq2> cjwatson: Which part of it?
<cjwatson> tsimonq2: Any of the last three lines :)
<cjwatson> Well, it's true that anyone with upload access can also copy.  The rest is AFAIK false.
<tsimonq2> cjwatson: It would help if I could access staging.launchpad.net. ;P
<cjwatson> There may have been some other reason that approval was required.
<cjwatson> staging is always down at the weekend for restoration from a production dump.
<cjwatson> It takes a couple of days.
<tsimonq2> Alright.
<tsimonq2> Will it be back tomorrow?
<cjwatson> Hopefully.
<tsimonq2> Alright, I'll check back with you once it's back up and once I've tested this.
<tsimonq2> Any quirks I should be aware of when using staging for this sort of thing versus production?
<tsimonq2> (Publisher shouldn't be needed for this.)
<cjwatson> LP staging uses SSO staging for auth, but otherwise not that I can immediately think of.  Oh, you won't be able to build test packages to copy, so you'll have to pick something already built.
<cjwatson> If it doesn't work you can always use dogfood instead.
<tsimonq2> I might actually just use dogfood so I have the ability to test rebuild a package in a PPA with Backports enabled.
<tsimonq2> cjwatson: How would I get copy-package to work with dogfood then?
<cjwatson> -l dogfood
<tsimonq2> Alright.
<cjwatson> As I say you may need dev assistance - a lot of the usual cron jobs don't always run.
<tsimonq2> Alright.
<cjwatson> Upload processing runs frequently, as does the copier.  The PPA publisher doesn't currently, but can.
<cjwatson> https://paste.ubuntu.com/26205792/ (obviously substituting your username) works for uploads.
<cjwatson> All details subject to change as dogfood is a developer playground.
<tsimonq2> Alright.
<tsimonq2> cjwatson: Is that for PPAs or archive uploads?
<tsimonq2> (Would it be the same with s/upload/ppa/ ?)
<cjwatson> Keep the FQDN the same, but you can upload to any archive that you have access to that way - it takes an archive reference following dogfood-sftp: on the dput command line.
<cjwatson> i.e. the same syntax that you see at the end of copy-package --help
<tsimonq2> Alright.
<cjwatson> (Except possibly a leading "ppa:" might not work, I forget.)
<tsimonq2> I'll play with it.
<tsimonq2> cjwatson: Could you please let my packages build? :)
<cjwatson> ?
<cjwatson> That shouldn't block on us ...
<cjwatson> Oh, conceivably all the builders are down
<tsimonq2> As far as I can tell, the Launchpad builders for several arches are on Manual.
<cjwatson> We often use dogfood for testing new builder clouds and such.
<tsimonq2> Oh, I can see that.
<cjwatson> I've turned on a couple.
<cjwatson> Er, or not.
<cjwatson> Now I have.
<cjwatson> (You might find it less time-consuming to use smaller packages for testing things like copies, though ...)
<tsimonq2> (I did realize that after the fact, but oh well.)
<tsimonq2> s/realize/remember/
<tsimonq2> cjwatson: Ftr, this is an example of a copy including binaries from a Bileto PPA: https://launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/5.9.2-3ubuntu1/+publishinghistory
<tsimonq2> cjwatson: Looking back in logs, Gianfranco executed "./copy-package --from=ppa:ci-train-ppa-service/ubuntu/3020 --from-suite=bionic --to=ubuntu --to-suite=bionic-proposed --include-binaries qtdeclarative-opensource-src"
<cjwatson> tsimonq2: That was held for approval simply because bionic wasn't fully open yet at that time.
<cjwatson> Proves nothing much - all uploads were held for approval.
<tsimonq2> cjwatson: Oh, good point.
<tsimonq2> Er, wait... was it?
<cjwatson> Ah, hm, I'm wrong.
<tsimonq2> Yep: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017-October/001231.html
<cjwatson> tsimonq2: So ... was it in fact held in unapproved?  I see no mention of it in #ubuntu-release IRC logs around that time.
<tsimonq2> cjwatson: If I remember correctly, yes.
<cjwatson> [2017-11-02 15:41:15,521: INFO/Worker-2] Running <PlainPackageCopyJob to copy package qtdeclarative-opensource-src from ~ci-train-ppa-service/ubuntu/3020, RELEASE pocket, in ubuntu bionic to ubuntu, PROPOSED pocket, in ubuntu bionic, including binaries> (ID 39344156) in status Waiting
<cjwatson> [2017-11-02 15:41:21,426: DEBUG/Worker-2] Packages copied to Primary Archive for Ubuntu:
<cjwatson> And in fact more clearly:
<cjwatson> [2017-11-02 15:41:21,163: DEBUG/Worker-2]   Subject: [ubuntu/bionic-proposed] qtdeclarative-opensource-src 5.9.2-3ubuntu1 (Accepted)
<cjwatson> tsimonq2: This upload was not held for approval.
<tsimonq2> cjwatson: Could it be that CI Train PPA uploads are whitelisted?
<cjwatson> tsimonq2: It is possible (even probable) that Bileto required an archive admin to sign it off, but that's it deliberately going over and above Launchpad's checks.
<tsimonq2> cjwatson: But isn't this intentional for the function of Bileto?
<cjwatson> tsimonq2: Sure, Bileto has to run its copies with somewhat elevated privileges and thus has to do some checks itself first, but that mechanism wasn't used here.
<cjwatson> tsimonq2: It looks like Gianfranco did the copy manually and thus bypassed Bileto's checks.
<tsimonq2> cjwatson: Hm, so this makes me wonder. When doing `./copy-package -l dogfood -s zesty --from=ppa:tsimonq2/ubuntu/testing-backports --to=ubuntu --to-suite=zesty-proposed vlc` I get "The signer of this package has no upload rights to this distribution's primary archive.  Did you mean to upload to a PPA?" which makes me think that a proper mechanism *is* in place.
<tsimonq2> Er...
<tsimonq2> This database is from before I joined MOTU.
<tsimonq2> So that makes sense.
<cjwatson> tsimonq2: There are checks that you're permitted to upload, but those checks don't include anything that cares about whether you used the --include-binaries flag, AFAICS.
<cjwatson> That's all I'm saying here.
<tsimonq2> cjwatson: Right, so could you add me to MOTU on dogfood so I can try this one more time? (Unless I'm misunderstanding you here?)
<cjwatson> Your test was wrong anyway, since you didn't use --include-binaries.
<tsimonq2> Right, and I've now included that.
<cjwatson> tsimonq2: Added you to ~motu on DF
<tsimonq2> cjwatson: Oh, look: https://dogfood.paddev.net/ubuntu/zesty/+queue?queue_state=1
<tsimonq2> So it does indeed show up as a sync in unapproved.
<cjwatson> tsimonq2: Oh, look: https://dogfood.paddev.net/ubuntu/+series
<cjwatson> zesty is CURRENT
<cjwatson> you need to test artful
<tsimonq2> Indeed.
<cjwatson> (otherwise you're just testing the "is this an SRU?" logic)
<tsimonq2> Gotcha.
 * cjwatson -> bed
<tsimonq2> o/
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
<tumbleweed> jbicha: ah, yes, teela is short of disk space
<tsimonq2> ahasenack: Congrats!
<ahasenack> thanks tsimonq2
<tsimonq2> //
<tsimonq2> 
<tumbleweed> jbicha: ok, it should update again today
<jbicha> thank you :)
<rlink> An SRU of mine was promoted from xenial-proposed to -updates, but was pulled after 10% propagation because of an end-user error report.  I got an email with a link to the error report, but don't have authorization to see it.  Filled out the form requesting access, and it's been pending for a week.  Little help here?
<jbicha> bdmurray: are you around? ^
<jbicha> rlink: a lot of people are on holiday break
<coreycb> RAOF: hi, if you are around tomorrow (tues) could you take a look at neutron in the xenial upload queue? that one is hot for a customer.
#ubuntu-devel 2017-12-19
* jackass changed the topic of #ubuntu-devel to: you've been hacked!
* Unit193 changed the topic of #ubuntu-devel to: Artful Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<sdeziel> I'd like to know why a certain package (ganeti) was not imported into 17.10 and is thus missing from 18.04.
<cjwatson> https://launchpad.net/ubuntu/+source/ganeti   seems to be there
<cjwatson> ah, only in -proposed
<cjwatson> it had/has (I haven't checked whether it still does) a dependency which was broken (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865399); furthermore, its autopkgtests are broken
<ubottu> Debian bug 865399 in libghc-cabal-dev "libghc-cabal-dev and ghc: error when trying to install together" [Serious,Open]
<cjwatson> http://autopkgtest.ubuntu.com/packages/g/ganeti
<sdeziel> thanks cjwatson!
<sdeziel> cjwatson: the autopkgtests I checked all be failed because there is not enough RAM available: Not enough memory on node node1 for creating instance instance1: needed 1024 MiB, available 809 MiB
<cjwatson> sdeziel: I haven't looked in any more detail, and won't; just telling you what I know
<sdeziel> alright, thanks for the pointers
<bdmurray> rlink: for what package?
<bdmurray> rlink: Ah, I've seen your email to me now. I'll have at your request today.
<rlink> bdmurray:  Got it.  Thanks.
<rlink> bdmurray:  So, this doesn't look like a regression introduced by my network-manager SRU.  This is a problem in nm-connection-editor (from network-manager-gnome) that has been happening since at least October (I stopped scrolling back after that)
<bdmurray> rlink: What was the crash again?
<rlink> I'm guessing the error report flagged network-manager because bits of libnm show up in the stack trace?
<rlink> https://errors.ubuntu.com/problem/bf601527363a0557bea54d20de626f6a8d74d586
<bdmurray> rlink: Did nm-connection-editor move packages?
<rlink> bdmurray: Not a clue.  It doesn't come from network-manager.  As far as I can tell, it comes from network-manager-gnome, whose source package is network-manager-applet
<rlink> The above is also true at least as far back as 14.04
<rlink> bdmurray:  Oh, found a 12.04 box.  Also true as far back as 12.04
<bdmurray> rlink: Can you pastebin the email you got? FWIW this isn't blocking phasing anymore.
<rlink> bdmurray: I wish I could, but I looked for it yesterday and I seem to have accidentally deleted it.
<rlink> bdmurray: I could go pull it from tape, if you need it that badly.
<bdmurray> rlink: I have logs from the server I can look at, thanks though.
<rlink> bdmurray:  Oh.  The phased-update page for Xenial doesn't list network-manager any more.  It did as of late last week.
<rlink> And it looks like it has already reached 100% phasing?
<bdmurray> rlink: Yes, that's what I tried to say earlier.
<rlink> Yeah, I misunderstood.  I thought you meant the block was gone, but I didn't realize the phaseing had resumed.
<rlink> Sorry.  I stopped checking the phased-update page after a week of waiting for my error-tracker-access approval. ;-)
<bdmurray> rlink: ah, 1.1.93 (in the release pocket for xenial) did produce the network-manager-gnome package. The error tracker doesn't deal well with packages moving about.
<rlink> bdmurray:  Oh!  Okay, that makes sense.  Thank you for the insight!
<slangasek> infinity, kees: do we have a TB chair for today's meeting?
#ubuntu-devel 2017-12-20
<mvo> smb: hey, I "stole" lp 1623125 from you. I hope you don't mind. uploaded the fix to bionic and sru-ed to xenial
<ubottu> Launchpad bug 1623125 in initramfs-tools (Ubuntu) "fixrtc script does not catch "Last mount time: n/a" string" [Medium,In progress] https://launchpad.net/bugs/1623125
<LocutusOfBorg> hello juliank can you please have a look at https://ci.debian.net/packages/s/software-properties/ and https://autopkgtest.ubuntu.com/packages/software-properties/bionic/amd64 ?
<LocutusOfBorg> they are blocking qt migration... I have no clues
<juliank> um, /tmp/autopkgtest.T5cpXr/build.XAo/src/tests//tmp/autopkgtest.T5cpXr/build.XAo/src/tests seems kind of double
<juliank> The Debian one just always failed, there's nothing fancy going on there.
<juliank> LocutusOfBorg: So, I may be wrong, but maybe the test suite runner runs all tests in the same process, and the sources.list setting from test_aptsources.py sticks around where it shouldn't
<juliank> LocutusOfBorg: In that case, adding         apt_pkg.init() to clear_apt_config() should fix the issue
<juliank> In general, all tests should probably run apt_pkg.init() in setUpClass so they can be run in any order.
<LocutusOfBorg> so juliank can you please fix it? :)
<doko> jamespage: cantor autopkg test fails with the recent qt5
<jamespage> doko: did you mean that for me?
<doko> jamespage: ahh crap, sorry
<doko> tsimonq2: ^^^
<jamespage> doko: no worries
<jamespage> I was worried openstack had grown some sort of new dependency :-)
<tsimonq2> doko: ...please be more specific
<doko> tsimonq2: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html triggered by python3.6
<rbasak> cyphermox: are you aware of the nplan s390x dep8 failure in xenial?
<rbasak> apw: no SRU paperwork in bug 1737640? I don't know how to check that the SRU verification minimises regression risk.
<ubottu> bug 1737640 in ubuntu-fan (Ubuntu) "/usr/sbin/fanctl: arithmetic expression: expecting primary | unconfigured interfaces cause ifup failures" [Critical,Confirmed] https://launchpad.net/bugs/1737640
<apw> rbasak, bah smb should know better
<apw> rbasak, this is a regression in -updates which prevented juju deployments iirc, so the verification was to confirm that juju would now deploy with that update
<rbasak> apw: what about non-Juju use of fanctl?
<apw> rbasak, i believe it would be similarly affected, but that to trigger the failure you had to have an unconfigured interface something like that
<apw> rbasak, clearly i am not the one who should write that up, as i am short some context
<rbasak> apw, smb: I mean: is there any non-Juju use case that might be regressed? What areas should SRU verification cover to mitigate this, if any?
<apw> rbasak, i do remmber we struggled to get this to reproduce at all outside of that envionment, it was not a common case
<apw> rbasak, though always present in the juju deployments they were testing
<rbasak> apw: I'm not so worried about the bug. I'm thinking about the change.
<apw> rbasak, the primary failure mode was ifup -a would not complete successfully for unrelated interfaces with no fan configuration
<apw> rbasak, the change itself is to fix a deficieny which leads to an uncaught error in the normal case, which is benign if ugly
<apw> rbasak, but in ifup -a form they were becoming fatal
<apw> rbasak, the fix is needed and correct for all use cases, it is just that the benign error has no effect outside of that model
<apw> rbasak, but none of this is very coherant, and someone should be writing it up properly
* sladen changed the topic of #ubuntu-devel to: Artful Released + taken down LP#1734147 | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<rbasak> OK :)
<apw> rbasak, i am also worried the promised follow up to get this fixed in later series has not yet happened either
<rbasak> I hadn't even noticed that.
<rbasak> You accepted it on an urgent basis because of the Juju regression I presume.
<apw> rbasak, indeed, it was on fire at the time, the engineer was able to use a version of this package from PPA to continue
<apw> rbasak, and i was promised follow up on the other series etc, and that has not occured
<rbasak> apw: understood. I commented on the bug.
<apw> rbasak, i think leaving it be is appropriate
<tsimonq2> doko: ack
<smoser> anyone else lately seen chnages in git shell tab complete ?
<smoser> it doesnt seem to me to be workign as well as it used to. i'm not sure what would have changed... just looking to see if someone else saw something.
<smoser> i'm on bionic
<smoser> no changes recently to git (which provides /usr/lib/git-core/git-sh-prompt)
<smoser> hm.. something seemed to have gotten foobarred in shell window i guess.
<smoser> nothing to see here folks, move along...
<cyphermox> rbasak: I am, this is not a nplan issue -- network-manager and say, wpa, other things would fail the same. This is because s390x is no longer marked to not support machine-isolation (because it does support it now), but there are things not available on it (cfg80211, iw)
<cyphermox> iw is arguably something that needs to be depended on (and I'm a little surprised it's not), but cfg80211 is a kernel thing
<rbasak> cyphermox: OK, so in your view, nplan is ready to release despite that failure?
<cyphermox> rbasak: correct
<rbasak> cyphermox: OK, I'll review. There are other SRUs for which nplan dep8 has failed too. Are these the same - do we need a force-badtest, or to fix the nplan dep8 test somehow?
<cyphermox> 0.32 is all good; I'll add workarounds for what's left
<cyphermox> if things have no tested against 0.32, they're not good
<rbasak> I suppose we need to land nplan 0.32 into the updates pocket first then, and then retry those SRUs
<rbasak> Uh, those other rdep dep8 tests
<cyphermox> I see only util-linux, which hasn't tested against nplan 0.32~16.04.3, but it shouldn't really matter there
<sladen> cascardo: hello, kudos for the upload for LP#1734147
<sladen> cascardo: what's the present state in terms of who in the HW can perform testing/
<cascardo> sladen: well, I am just one of guys hitting the buttons
<cascardo> sladen: some testing has been made by anthonywong
<sladen> ypwong: ^^
<sladen> ypwong: have you got hardware and are in a position to do testing for bug LP#1734147 ?
<ypwong> sladen, i will go to ODM tomorrow to test things suggested by mika
<ypwong> to see if we can recover from failed bios
<cascardo> sladen: oh, you are the one looking on how to recover this by software, kudos to you!
<sladen> ypwong: have you had contact with Mika W. (other than what I forwarded to the bug report today)?
<sladen> ypwong: wondering if there is more information that can get in one place, on the bug report, so that it is not lost
<sladen> cascardo: ...stuck with not having access to hardware in this case
<sladen> ypwong: cascardo: (both), and what's your collective understanding of the result of disabling the spi-intel driver loading on boot ... is it just that additional machines will not be bricked, or is it expected, that after 2+ reboots without the driver having been auto-loaded these machines will be usuable again?
<ypwong> sladen, yes i got more from mika but because they are unproven so i want to confirm by myself first before posting on launchpad
 * sladen silently bangs head against wall
<ypwong> sladen, once the bios is affected the kernel update cannot help
<ypwong> so it's just to prevent more people get burnt
<cascardo> afaik, we want to prevent more accidents. so even a new image will be built with that kernel
<tsimonq2> jackpot51: You might want to check if Pop is affected by the bug in the topic, just an fyi ;)
<juliank> LocutusOfBorg: on it now
<juliank> ugh
<juliank> LocutusOfBorg: Let's hope it's fixed now
<juliank> LocutusOfBorg: I have no idea, it worked for me
<juliank> Oh, how I hate global variables.
<acheronuk> juliank: I think software-properties is still failing from the log of running tests
<juliank> acheronuk: oh I see
<juliank> damn
<juliank> oh right
<juliank> I have to clear the config first before runninig init() again
<juliank> for k in apt_pkg.config.keys(): apt_pkg.config.clear(k)
<juliank> next attempt :D
<juliank> ugh
<juliank> uploaded .19
<acheronuk> juliank: fingers crossed. thanks
<PenguinPerk> I am working on automating an install of unifi controller into aws. I have a directory mount for the a backup directory. When I run the installed (as Root), apt install unifi. I am getting an error: chown: changing ownership of '/var/lib/unifi/backup': Input/output error. My goal is to find the script that will provide what UID/GID and permission the installer is trying to set.
<TJ-> PenguinPerk: the preinst or more likely postinst script
<PenguinPerk> @TJ-, here is the error: chown: changing ownership of '/var/lib/unifi/backup': Input/output error
<udevbot_> Error: "TJ-," is not a valid command.
<TJ-> PenguinPerk: check the package's .postinst script
<PenguinPerk> @TJ-, What is the best way to find the .postinst script, I ran a file listing of the package and i don't see it?
<udevbot_> Error: "TJ-," is not a valid command.
<TJ-> PenguinPerk: don't use @ ... it's enough to tab-complete my nickname
<TJ-> PenguinPerk: Pull the source of the package, or look at /var/lib/dpkg/info/<package-name>/postinst
<PenguinPerk> I will look, I may not have access to the src
<PenguinPerk> @TJ-, I just confirmed i don't have access to src files. Are there any options available for me to run it in a verbose mode?
<udevbot_> Error: "TJ-," is not a valid command.
<TJ-> PenguinPerk: "apt-get source <packagename>"
<PenguinPerk> @TJ-, no luck...I can call Ubiquiti support line if i have to....trying to work around with having to call.
<udevbot_> Error: "TJ-," is not a valid command.
<TJ-> PenguinPerk: did you look for "/var/lib/dpkg/info/unifi.*" ?
<PenguinPerk> TJ-, thanks
<LocutusOfBorg> thanks juliank :)
<juliank> Still one failure
<juliank> but on ppc64el
<juliank> that might have always failed
<juliank> amd64 succeeded
<juliank> i386 too
<juliank> so the regressions should be taken care of
<juliank> that said: it might not migrate either, because livecd-rootfs regressed somehow, maybe temporary (for .18, let's see what happens for .19)
<juliank> but: since I only made changes to tests/ I guess that can easily be overridden
<juliank> as obviously my changes to tests/ can't cause regressions in other packages :D
<acheronuk> juliank: seems to be passing on my retries against pyqt5 as well (amd64,i386). thanks
<juliank> acheronuk: wonderful
#ubuntu-devel 2017-12-21
<happyaron> wants to know how can I debug apparmor for lxc/lxd related issue?
<jjohansen> happyaron: https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures
<jjohansen> in addition there is a debug mode
<jjohansen> as root echo 1 > /sys/module/apparmor/parameters/debug
<jjohansen> this will cause a few extra messages to the kernel ring buffer (dmesg) that may help
<jjohansen> another one to watch for is seccomp no_new_privs which can block apparmor from making domain transitions
<jjohansen> apparmor does emit a message for this, but you may need the debug setting turned on
<happyaron> jjohansen: thanks! looking into that
<jcdutton> Hi. How is bad bug comming along. Have we found out how to un-protect the SPI ?
<sladen> jcdutton: the protection actually seems to be on the flash chip itself, which boots up read-only
<sladen> jcdutton: and would normally get unlocked by some other means when required
<sladen> ypwong: Mika is going to contact you about testing leaving FSMIE as-is
<sladen> jcdutton: you disappeared, but yes, people are working on it
<sladen> <sladen jcdutton: the protection actually seems to be on the flash chip itself, which boots up read-only
<sladen> <sladen jcdutton: and would normally get unlocked by some other means when required
<jcdutton> Maybe it has changed the Protected Regions?
<sladen> jcdutton: my current theory is that the SMM firmware normally takes care of either  (a) clearing the protect on first access;  (b) going into lockdown when something unexpected is encountered
<sladen> jdstrand: however we are dependent on those that have access to hardware to test.  And they are currently having dinner (because of the timezone) and will return to testing after a short break
<sladen> jcdutton: ^^
<jcdutton> I read that a reboot 3 times might help.  My research is that the reboot requires complete power off. I.e. No Main, no battery, power off, then on again
<sladen> jcdutton: yes, battery out, power off
<sladen> jcdutton: and does it?
<sladen> jcdutton: what did you discover?
<sladen> jcdutton: probably should have written 'power off
<sladen> jcdutton: probably should have written 'power cycle'
<jcdutton> I don't have a problem Laptop, but the datasheets say that the write-lock is only cleared on a complete power cycle.
<ypwong> sladen, will do. If I break it I will have to go back to ODM to unbrick it.
<sladen> ypwong: ta.  what would also be useful are before/after dumps of the flash.  This would help to confirm if it is eg. a broken checksum (not) being updated, and which is causing the firmware not to unlock the chip during boot the next time
<sladen> ypwong: second would be the debug information that the intel-spi driver dumps out during boot, to see what the initial state of the SPI status and control registers are
<sladen> ypwong: but take your time and have a well-earned break!
<jcdutton> ypwong, What do ODM do to it to unbrick it?
<ypwong> jcdutton, they use a spi flasher writer to change the CMP bit from 1 to 0
<ypwong> jcdutton, https://www.dediprog.com/pd/spi-flash-solution/sfdk01
<ypwong> sladen, will get to that after my meeting that's 4 mins from now :)
<jcdutton> ypwong, sounds a bit odd to me. what would have set that to 1?
<ypwong> jcdutton, that's what we are finding out
<ypwong> kernel codes look sane but somehow that bit changed to 1
<sladen> jcdutton: several lines of inquiry, latest speculation is related to  https://github.com/torvalds/linux/commit/9d63f17661e25fd28714dac94bdebc4ff5b75f09  which if it's not in the running kernel might leave junk in the FIFO from the previous access
<sladen> jcdutton: though my reading of the documentation is that the flash chip comes up with CMP=1, and needs to be explicitly cleared, or WSP=1 needs setting to use a different protection scheme
<jcdutton> ypwong, the problem with CMP being wrong, is that next to it are Write-Once bits, that if they are written, will perm brick the laptop.
<sladen> jcdutton: yup, the latest speculation is that although the code does a read-modify-write (to set something else in that register);  if the 'read' was for the incorrect data, then the write will also be for the incorrect data
<sladen> jcdutton: https://www.winbond.com/resource-files/w25q64fw_revd_032513.pdf  is the Winbond doc
<jcdutton> That commit is crazy code.
<sladen> jcdutton: why so?
<jcdutton> It does not check for len = 0
<sladen> mmm, that's certianly a good way to set all-1s
<jcdutton> Does it need to do write-posting on that write?
<sladen> this (risky) code could certainly do with some more error/sanity checking
<sladen> ie. validating every single bit in what is going to be written back
<jcdutton> Is this code actually used for anything, apart from re-flashing ?  In which case, it should not write anything until someone actually wishes to re-flash
<jcdutton> sladen, that patch does fix a bug in the read statement, that is a good fix, but I don't think that would cause the problems we are seeing.
<sladen> jcdutton: the *whole problem* is that is collateral from the _init()/probe code. ...which should not be doing *anything* invasive/risky
<sladen> jcdutton: the code isn't even used
<sladen> jcdutton: so in theory "nothing" is happening
<jcdutton> Surely some of the writel in the init need write-posting?
<jcdutton> although, better if it never did a write in that init code.
<sladen> jcdutton: write-posting?
<jcdutton> With PCI, in order to actually write something, you have to read it afterwards, to force a PCI transaction to actually pass the data across the buss
<jcdutton> so, a writel without a following readl is unlikely to behave as expected
<jcdutton> I was asking, in case this chatting with the SPI is not via an PCI bus, in which case it does not matter about write-posting
<sladen> jcdutton: no, but I do have a feeling that some of this code is failing to triple check whether the SPI is ready, and not in the middle of something else
<jcdutton> sladen, where in the code is it writing  the CMP bit?
<sladen> jcdutton: the sr2 register in ...
<jcdutton> I cannot see a write to sr2 in the init function
<sladen> jcdutton: wait, trying to find it
<jcdutton> I see, sr1-4 is all one 32 bit reg
<sladen> jcdutton: it's in spi_nor_init()  write_sr(nor, 0);
<sladen> jcdutton: the intention is to _clear_ the protection bits
<sladen> jcdutton: however
<sladen> jcdutton: and the really worrying thing about this (as you've already noted) is that the same register has write-once fuses in it aswell
<sladen> as at the very least that routine should mask those out
<sladen> so that it is impossible for an _init_ routine to write anything dangerous, even if the reading got screwed up
<jcdutton> Agreed
<sladen> this is one avenue of investigation
<sladen> another is that the BIOS System Management Firmware normally clears t
<sladen> clears it
<jcdutton> A simple AND 0xffff00ff  would do it
<jcdutton> But that only works if the QUAD and CMP should be 0. In some cases that might not be true.
<jcdutton> Maybe 0xffff83ff  would be safer, in the sense that it would be reversable in software. Those other bits are not reversable.
<sladen> prefereably   ~(DANGERBIT(X) | DANGEROUSBIT(Y) | DANGEROUSBIT(Z))  where the enums make it less easy to screw up
<sladen> and more obvious what is happening
<sladen> think the code is trying to enable the Quad mode
<jcdutton> I think the only real solution to this problem is a intel-spi driver with a mass of quirks in it, so undo the damage it has done.
<sladen> jcdutton: something like that is in the process of being tested...
<sladen> jcdutton: but needs to not make the situation any worse
<jcdutton> it can get worse???
<sladen> (if it is only CMP getting set it is reversible)
<sladen> and in software
<sladen> if any of the write-protect fuses get blown, then it is bad
<jcdutton> Maybe we need to get a sample. write a version of the driver that is 100% safe, and have it dump the sr2 to the syslog. and gather results. I think netboot works for everyone, so one could create a netboot image that just prints the results, without causing more damage.
<sladen> booting with 'debug' should be enough
<jcdutton> Let the tool offer to fix the CMP bit, but explain that if the Write-once bits are set, it is a return to base fix.
<jcdutton> No-one in their right mind is going to run that intel-spi driver in its current state.
<jcdutton> Unless the ~dangerous code is added.
<jcdutton> I also found out that this is a PCI device
<jcdutton> so they also need to add the write-post bits.
<sladen> knock up a proposed patch for both
<sladen> along with citations explaining the why
<sladen> given the number impacted people (probably 1000x those who have reported it)
<sladen> it needs to be done slowly and carefully with review
<jcdutton> Agreed. I offer to review the proposed fix.
<jcdutton> sladen, FYI, I used to be a kernel developer, but don't have a lot of time for it now.
<jcdutton> sladen, have there been any reports of 3 power cycles fixing the problem?
<sladen> jcdutton: no, that was my guess on the basis of (1) first time blacklisting the driver (2) letting the firmware come up and get upset and broken checksums etc + cleanup (3) hopefully come up in a better state
<sladen> jcdutton: however, if it's not the SMI disabling, but is in need CMP in SR2 on the flash getting set because of a corrupt FIFO read before, then that is probably not going to help
<sladen> jcdutton: and the latest information points to the need to reset CMP in SR2 on the flash, in software
<sladen> jcdutton: the difficulty for me and others is the lack of hardware to test
<jcdutton> Agreed. particularly with the possibility of making it worse due to the write-once bits.
<jcdutton> You really need someone with the laptop and a flash programmer to hand, who can test and fix if needed.
<sladen> which we have
<sladen> sort-of
<sladen> and my approach to this would be working out to reliably brick it, in order to unbrick it by not doing that
<jcdutton> Where is the fifo you speak off?
<jcdutton> A stepping stone towards that could be a bit of code that simply reports: "Software fixable. CMP flipped"  or "Hardware replacement needed" if the write-once are set.
<jcdutton> and put that in a bootable image
#ubuntu-devel 2017-12-23
<doko> jbicha: txzmq failing it's autopkg tests after the forced sync
<jbicha> doko: I'm thinking it just needs to depend on python3-pytest but I haven't sat down to test thatâ¦
#ubuntu-devel 2017-12-24
<mridu> Hi, I am new to this community. I have a query regarding the use of crontab -e.
<mridu> I have to execute a python script daily. But, it is not happening. I have checked askubuntu forum a well.
<TJ-> mridu: you should ask in #ubuntu, that is the support channel. This channel is for Ubuntu development issues
<mridu> Thanks!
<mridu> And if I know Python is there any way I can contribute to Ubuntu?
<TJ-> !contributing
<TJ-> hmmm
<TJ-> !contribute
<ubottu> To contribute and help out with Ubuntu, see http://community.ubuntu.com and https://wiki.ubuntu.com/ContributeToUbuntu
<mridu> Thank you
#ubuntu-devel 2018-12-17
<mantas-baltix> Hi all
<mantas-baltix> How I can help to speed-up inclusion of simple 3 lines patch from Debian to Ubuntu 18.04 LTS? See bug #1781746
<ubottu> bug 1781746 in Default settings and artwork for Baltix OS "[SRU] Slow startup with zram-config installed (/dev/zram0) or encrypted swap" [High,Confirmed] https://launchpad.net/bugs/1781746
<mantas-baltix> bug is already fixed in Debian initramfs-tools ver 0.132, just 3 lines patch from Debian, see https://salsa.debian.org/kernel-team/initramfs-tools/commit/312393b0cf1231125eeff3d1a2b6b778a935c21d
<seb128> mantas-baltix, hey, subscribing ubuntu-sponsors would be better, but you might want to try to nag someone from foundations team on IRC to review it, e.g xnox or cyphermox or vorlon
<seb128> mantas-baltix, you can also tag it rls-bb-incoming for nominating for review on the b serie
<johnnyfive> Hello, i'm trying to understand why iucode-tools is in both main and restricted (sources are only in restricted, package is published in main AND restricted). Is this a bug?
<mdeslaur> johnnyfive: it used to be in restricted but then we decided that the kernel needed to depends on microcode updates, so it got copied to main
<jbicha> the binaries are only in main https://people.canonical.com/~ubuntu-archive/madison.cgi?package=iucode-tool
<johnnyfive> mdeslaur, however the sources are still in restricted? is this going to be changed or kept as-is?
<mdeslaur> johnnyfive: I don't know...is that a problem?
<mdeslaur> an AA would have to chime in to say why the sources weren't copied
<jbicha> johnnyfive: you can file a bug against the package and subscribe ubuntu-archive
<johnnyfive> mdeslaur, it's not a problem, just need to account for it if this is intended. AFAIK this breaks the contract of how the repositories are set up. If, however, this is intended and I misunderstand the deb ecosystem, that's fine, I just have to prepare for it.
<jbicha> johnnyfive: there are several packages where the source is in main but some binaries are in universe
<bdmurray> Does anybody have a better idea to check for fglrx or nvidia than this? https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/DistUpgrade/xorg_fix_proprietary.py#L106
<cjwatson> jbicha: That way round is permitted, but source in universe + binary in main wouldn't be.  I think the situation that johnnyfive has pointed out is a clear bug.
<cjwatson> vorlon: ^- looks like you missed a bit in https://bugs.launchpad.net/ubuntu/+source/iucode-tool/+bug/1738272
<ubottu> Launchpad bug 1738272 in iucode-tool (Ubuntu) "microcode packages, like firmware packages, should be in main" [Undecided,Fix released]
<cjwatson> (comment #3 shows you moving the binaries but not the source)
<bdmurray> cjwatson: he's travelling today
<johnnyfive> cjwatson, thanks for the investigation/information
<cjwatson> bdmurray: yeah, no rush, it's been like this since bionic :)
#ubuntu-devel 2018-12-18
<thopre01> Hi, can someone point me to the procedure to request a package rebuild (from the same source) in an Ubuntu LTS (Ubuntu bionic)?
<juliank> thopre01: the process is to upload it with increased version number
<juliank> there's no difference to any other upload
<juliank> except, if the version does not contain ubuntu, it will be build1 (build2, ..., and so on)
<thopre01> I see
<thopre01> How to request such an upload for a universe package then?
<thopre01> (I am not the maintainer, just one of the upstream developer)
<juliank> thopre01: what do you want rebuild and why?
<thopre01> I want the newlib package in Ubuntu bionic rebuild because it was built using an earlier version of gcc-arm-none-eabi than the one currently in bionic and this causes bug LP#1767223
<juliank> Usual procedure for sponsored uploads would be to file a bug, attach a debdiff, and subscribe ubuntu-sponsors. But maybe it's fine to subscribe sponsors for a no-change rebuild?
<thopre01> Ok, thanks
<juliank> thopre01: Here it's obviously more complex, as it involves SRU paperwork. If you believe that a rebuild fixes that, write impact, test case, and regression potential sections in that bug, assign it to the correct package
<thopre01> Ok, on it, thanks juliank!
<thopre01> Done
<jibel> vorlon, hi, there are 3 MPs for layered images waiting for a review, could someone from foundations have a look?
<jibel> https://code.launchpad.net/~jibel/livecd-rootfs/+git/add_multi_layered_squashfses_support/+merge/360878
<jibel> https://code.launchpad.net/~jibel/debian-cd/support_for_multilayer_images/+merge/359228
<jibel> https://code.launchpad.net/~jibel/ubuntu-cdimage/support_for_multilayer/+merge/359512
<rbasak> jbicha: FYI, patching PHP back to pcre3 seems more difficult than it initially seemed and I don't think it'll be practical.
<rbasak> So we'll have to hold on switching to php 7.3 until pcre2 in main is decided.
<jbicha> rbasak: I'm sorry to hear that (ok, I'm honestly a bit happy too ð )
<seb128> bdmurray, hey. The apport autopkgtests seem quite buggy/flakky nowadays, is that a known issue/something you are looking at (e.g https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/a/apport/20181215_031628_603b6@/log.gz)
<bdmurray> seb128: I think they are failing now because of bug 1808508
<ubottu> bug 1808508 in valgrind (Ubuntu) "Valgrind doesn't work in disco [Fatal error at startup: a function redirection which is mandatory for this platform-tool combination cannot be set up.]" [Critical,Confirmed] https://launchpad.net/bugs/1808508
<seb128> bdmurray, which is being worked on?
<bdmurray> seb128: not quite yet
<seb128> k, thx bdmurray
<vorlon> cjwatson: iucode-tool> hmm indeed, what should be done about this now given that bionic and cosmic both released this way?  Do you think it's worth copying to -updates to update the source component?
<vorlon> jibel: I am EOY; if you need reviews before then, please escalate to gaughen
<cjwatson> vorlon: IMO we can live with it for stable releases but should fix it going forward
<jibel> vorlon, okay, enjoy EOY break!
<Odd_Bloke> smoser: Does https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1809027 appropriately capture what we would need for mfdiff?
<ubottu> Launchpad bug 1809027 in ubuntu-keyring (Ubuntu) "Make retired Ubuntu keyrings available from the archive" [Undecided,New]
<smoser> Odd_Bloke: i think that summarizes it well. good job.
<smoser> i might add that it isn't a "one time only" problem.
<smoser> at some point 18.04 will also be in such a scenario.
<Odd_Bloke> smoser: Yep, great point; added.
<smoser> Odd_Bloke: i guess if we were over engineering things... it might be nice to have that package provide you with a mapping of signing-key to release
 * smoser comments on bug
#ubuntu-devel 2018-12-19
<vorlon> cjwatson: ack, have changed the override now for disco
<seb128> rbasak, hey, it would be nice if you could review the alsa-lib/cosmic SRU, it's a follow up to fix the previous one failing to build due to a stupid mistake
<rbasak> seb128: I'm done for the year now sorry
<seb128> rbasak, no worry, stop looking at IRC and enjoy the holidays :)
<seb128> bdmurray, hey, could you review the alsa-lib SRU in cosmic uploaded earlier, it fixes a build issue with the update accepted yesterday (also there is a similar upload to bionic queue now if you have slot to review that one as well)
<rbasak> :)
<seb128> doko, hey, I guess you sav that the valgrind autopkgtests are still unhappy with the new upload?
<bdmurray> seb128: sure
<seb128> bdmurray, thanks!
<seb128> bdmurray, thx
<bdmurray> seb128: no problem
<cjwatson> vorlon: ta
<mwhudson> seb128: hey
<mwhudson> seb128: did you see https://code.launchpad.net/~mwhudson/ubuntu-archive-scripts/team-report-yaml/+merge/361112, i have a note somewhere to make sure that you check this
<seb128> mwhudson, hey, thanks for the ping, I hadn't see it before and yes it's me/desktop who asked for it, I try to have a look tomorrow/before holidays to comment on the format
<mwhudson> seb128: thanks
<mwhudson> seb128: very little thinking has gone into the format so far so feel free to request anything at all that will help
<seb128> mwhudson, ok, thanks, same here in fact. We want to include the desktop items in our reporting tool but we didn't look at writing that code yet
<seb128> looks like we should be able to get what we need from what is outputed though
<seb128> it's over work hours here but I look a bit more at the details tomorrow and I will comment on the mp
<seb128> thanks mwhudson!
<mwhudson> yeah fair enough
#ubuntu-devel 2018-12-20
<smoser> hey. if i use sbuild, how can i tell it "leave the schroot around"
<cjwatson> smoser: -p never
<cjwatson> or variations; search for "purge" in sbuild(1)
<cjwatson> I have $purge_build_directory = 'successful'; $purge_session = 'successful'; in ~/.sbuildrc, which I find helpful
<cjwatson> but you do have to remember to schroot -ec <schroot session ID> when you're done
<smoser> right. thank you.
#ubuntu-devel 2018-12-21
<LocutusOfBorg> cyphermox, FYI, I'm doing the dkms merge
<LocutusOfBorg> please double check if you can
<LocutusOfBorg> I'm keeping some delta, while some other is now upstream
<LocutusOfBorg> vorlon, is your shim package uploadable as-is on Debian?
<LocutusOfBorg> I mean both shim and shim-signed
<vorlon> LocutusOfBorg: I have no idea, it has not been a priority to validate the recent shim development work against Debian.
<gQuigs> I'm guessing we should expect no SRUs over the holidays - just want to confirm
#ubuntu-devel 2019-12-16
<doko> coreycb: yes, but the MIRs for the other two packages are missing
<doko> Laney, seb128: update-notifier now depends on sugar, pulling in Python2 to main again
<doko> I didn't track what changed
<seb128> doko, is that because notification-daemon got deleted on i386 and it's finding it as an alternative stll existing?
<seb128> doko, can we remove update-notifier/i386?
<doko> seb128: I'm not familar with the i386 removals, or is this somewhere documented?
<seb128> doko, I will check with Steve if there is a reason update-notifier wasn't removed (yet)
<seb128> but my guess is that i386 is the issue there
<seb128> tjaalton, hey, happy monday. Did you&vorlon reach an agreement on what to do with xorg-server/i386? it's still showing on the proposed migration blockeds items
<Laney> seb128: doko: it looks like there's a chain from flashplugin-downloader
<seb128> Laney, can't we delete that as well?
<Laney> that is in the seed
<Laney> https://people.canonical.com/~ubuntu-archive/germinate-output/i386.focal/all
<seb128> ah
<seb128> but I meant on i386
<seb128> ignore that
<tjaalton> seb128: yes, libdmx & libxres is needed on i386
<tjaalton> didn't happen yet though
<seb128> tjaalton, so what needs to happen? restoring back of libdmx1?
<tjaalton> too many packages build-depend on xvfb, and i386 builds can't use nocheck
<tjaalton> restoring them, yes
<seb128> thx
<Laney> seb128: just looked at update-notifier, those deps already have <!s390x> so perhaps we could add i386 to that
<rbasak> Subject:  Your December issue of Packaging Technology Today has arrived!
<rbasak> o_O
<seb128> Laney, right, if we keep the i386 binaries I guess that makes sense
<Laney> k, feel free to pursue any other option if you like it more
<xnox> rbasak:  "dear editor, my name is robbie and carboard boxes and a bit of wrapping paper do not make a great .deb package!!! I know better!"
<rbasak> "What you need are Santa's little debhelpers!"
<coreycb> doko: I've updated the MIR bug for the other packages
<cpaelzer> thanks coreycb I was taking a look ath these MIRs but really it comes down to ask doko if this really becomes obsolte when python3.8 becomes the default
<cpaelzer> doko: how willt hat work in python then?
<cpaelzer> will src:python-importlib-metadata be removed and src:python3.8 starts to build that binary?
<cpaelzer> even if that would be the case the same isn't true for zipp and itertools
<cpaelzer> so will then python3.8 grow these dependencies?
<cpaelzer> I'm wondering because I'd want to avoid doing a review and pushign it onto securities queue (which might take until 3.8 is the default) - to then throw away that work
<doko> cpaelzer: no, my understand is that those will only be needed for Python2
<doko> ding ...
<cpaelzer> doko: but there is a "python3-importlib-metadata"
<cpaelzer> would that grow a conflicts with python3.8 then?
<cpaelzer> doko: I don't see it in libpython3.8-stdlib - is that were it would end up?
<doko> cpaelzer: that's a backport to 3.7, not needed for 3.8 (hopefully)
<cpaelzer> so the src:python-importlib-metadata would drop python3-importlib-metadata then
<cpaelzer> because python3.8 libpython3.8-stdlib would contian it then?
<doko> that's what I remember when looking at this, yes
<cpaelzer> ok, so will then libpython3.8-stdlib get the dependency to e.g. python3-zipp that today is in python3-importlib-metadata?
<doko> no
<cpaelzer> or will all of that go into python3.8 stdlib?
<cpaelzer> libpython3.8-minimal:amd64: /usr/lib/python3.8/importlib/metadata.py
<cpaelzer> ok at least I found it within python3.8 now
<cpaelzer> coreycb: ^^
<cpaelzer> ok, so when python3.8 is the default kombu can drop the dependency to python3-importlib-metadata as it will be fulfilled with libpython3.8-minimal
<cpaelzer> coreycb: even if I push through the MIR reviews from my quick view two will also need security review
<cpaelzer> that will probably take until the same time that we need to see python3.8 as the default
<cpaelzer> coreycb: so could we instead of pushing all these MIRs forward wait for 3.8 and then do this change in kombu?
<doko> or we document that in the bug report, and only revisit that when we can't switch to 3.8, and pre-promote now
<cpaelzer> doko: ^^ would that work in your opinion?
<cpaelzer> doko: yeah that might be the best of both worlds
<cpaelzer> getting things unblocked for now
<doko> could you document that in the bug report?
<cpaelzer> yes, but I'd at least want openstack to subscribe (for the interim time) to also feel responsible to get rid of it then ... :-)
<cpaelzer> I'll ask james about the subscription and would document that in the bug then
<doko> ok
<coreycb> doko: cpaelzer: thanks sounds good
<cpaelzer> doko: documented in 1851393 - could you do the interim pre-promotion?
<cpaelzer> coreycb: ^^ FYI
<rbasak> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<tomreyn> would it be ok to flag bugs which seem important enough to the general user base that they should be fixed for FF as "rls-ff-incoming"?
<tomreyn> i'm just looking at bug 1466150 specifically
<ubottu> bug 1466150 in grub-installer (Ubuntu) "grub-install breaks when ESP is on raid" [High,Triaged] https://launchpad.net/bugs/1466150
<juliank> tomreyn: we already know about that one
<juliank> you can see it's got an id- tag, so it kind of skipped rls-ff-incoming
<tomreyn> juliank: yes i noticed it has an id assigned since 2018, it just looks like it might have been forgotten about, and i can never tell whether or not that's the case, or whether it's assigned to a (now) ex employee etc.
<juliank> Well, it seems it was marked as done
<tomreyn> maybe it is, and the bug report hasn't been updated. i have not tested it on anything recent.
<tomreyn> marked as done internally, right?
<juliank> xnox, cyphermox what's up wit hthat bug?
<cyphermox> eep
<juliank> I remember something about ESP on raid, but I don't know where
<cyphermox> well, that might be perilous
<juliank> Ah I think what I remembered was bugs about raid1 support in subiquity because I played with that
<tomreyn> i think i also have a bug open about esp on raid against subiquity or curtin.
<juliank> AFAIUI you cannot put ESP on RAID
<juliank> which the last comment suggested :D
<cyphermox> juliank: you certain could put ESP on RAID
<cyphermox> the issue is what happens if your firmware decides it needs to write to it
<juliank> cyphermox: I mean you could, but the firmware's allowed to write to it :D
<juliank> yeah
<juliank> I remember years ago when people asked me to implement this back when I maintained gummiboot in Debian
<tomreyn> the clean solution is to have grub quit with an error of "it's not safe to write esp on raid", and have installers understand how to deal with this. the user friendly solution is to enable grub to install on mdadm raid-1 partitions with <=1.0 metadata, issuing a warning, and have installers handle this gracefully.
<juliank> In any case, the bug got fairly confused
<juliank> I think the correct solution would be to have it mount multiple ESPs and update them all
<juliank> but I don't really know
<juliank> "I'm having the same problem with a new Gentoo install, but with a twist."
<juliank> wow, how's that relevant in an ubuntu bug?
<tomreyn> it's not, also not a configuration that could work.
<juliank> huh?
<juliank> You partition each disk into two partitions
<juliank> you raid the big one, and the small ones become ESPs
<tomreyn> the gentoo person has lvm's raid supnm across two physical disks
<tomreyn> s/supnm/spun/
<tomreyn> and an esp LV on top
<juliank> I do think the importance is weird, it should be wishlist
<tomreyn> grub fails to handle it at all currentl,y that's abug IMO
<juliank> IMO, it's about adding a feature to support updating multiple ESPs
<tomreyn> enabling installation of esp on top of mdadm raid-1 is a feature request IMO, as would be grub supporting updating multiple ESPs.
<juliank> I mean sure there could be a nice error message, but that does not help anyone, just breaks your upgrades
<juliank> Right, but I don't think ESP on raid1 is something that should be supported, as it's not safe
<tomreyn> the latter is non tricvial. you'd not just need to update multiple ESPs, but also manage multiple boot records in nvram
<tomreyn> i like good error messages, since they tell me what i did wrong (or some software did wrong).
<juliank> Sure
<juliank> But it doesn't work
<juliank> If you error out in grub update, you break the package management
<tomreyn> i agree, it won't help those who already have such a setup
<tomreyn> or are trying to install to it
<juliank> But it takes a lot of effort to create a setup like that
<juliank> it's not something you can do easily in a straightforward way with the installer
<tomreyn> btw the subiquity bug report i recalled about is bug 1817066 (and its not mine)
<ubottu> bug 1817066 in subiquity "support installing multiple ESPs" [High,Triaged] https://launchpad.net/bugs/1817066
<tomreyn> so that's basically about what you had on your mind
<juliank> ah yes
<juliank> tomreyn: that's what I remember
<CarlFK> how can I grab the text of an installer error from the text based installer?  this one:  http://archive.ubuntu.com/ubuntu/dists/eoan/main/installer-amd64/current/images/hd-media/boot.img.gz
<juliank> CarlFK: Go to other tty and look at log?
<juliank> CarlFK: please be aware that we're migrating away from d-i
<juliank> or well, discontinuing it
<juliank> starting with focal
<CarlFK> oh my
<CarlFK> will there be support for preeseed install ?
<juliank> CarlFK: automated server installs are on the roadmap https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls
<juliank> ubiquity, the desktop installer, I think does support preseeding to some extend, as it embeds parts of d-i
<CarlFK> has anyone made a d-i preseed file to yml converter?
<juliank> I don't think so, I'm not sure that would even work reasonably
<CarlFK> hmm.. someone would need to maintain a map to translate keys and ... structure?  something.  seems like too much work.
<CarlFK> is there any hint that Debian will do this too?
<tomreyn> juliank: thanks for taking the time to discuss, i posted what i think we concluded (and more) to bug 1817068
<ubottu> bug 1817068 in subiquity "Guided partitioning with multiple disks" [High,Triaged] https://launchpad.net/bugs/1817068
<juliank> seb128: fyi: poppler should be fixed now in focal-proposed and eoan unapproved queue
<seb128> juliank, great, thanks!
<juliank> sorry for breaking it!
<mwhudson> CarlFK: hi, i have no plans for a preseed -> yaml converter but maybe we could do something for simple cases
<mwhudson> CarlFK: do you have an example of what you are using?
<CarlFK> mwhudson: https://salsa.debian.org/debconf-video-team/ansible/blob/master/roles/tftp-server/files/d-i/xenial/preseed.cfg
<CarlFK> mwhudson: I'm skeptical it is worth the effort just for this case
<mwhudson> CarlFK: it's still interesting to see what people do
<mwhudson> CarlFK: i think most of this preseed can be replaced with an empty file :)
<mwhudson> d-i apt-setup/enable-source-repositories boolean true <- don't have a canned equivalent to that
<CarlFK> mwhudson: I was thinking the yml might be pretty simple
<mwhudson> CarlFK: certainly hope so
<CarlFK> and it doesn't have to be exactly the same.  historically we had apps that installed cleanly on ubuntu but not debian, so some of us (me) would use ubuntu, but others would work out all the patches and what not to make things run on debian stable
<CarlFK> now things are much better supported on both, so I look to ubuntu for hardware drivers that are harder to get onto a debian box
<CarlFK> it would be great if the kernel arg shortcuts were supported
<CarlFK> hmm, I have:  debconf/priority=high auto=true netcfg/dhcp_timeout=60 fb=false  hostname?=bare hw-detect/load_firmware=false
<CarlFK> wait.. thats not normal.  whoops.
<CarlFK> debconf/priority=high auto=true netcfg/dhcp_timeout=60 fb=false  hostname?=bare url=pc8.home hw-detect/load_firmware=false
<mwhudson> CarlFK: you mean being able to override particular settings on the kernel command line?
<CarlFK> mwhudson: mostly the ones that need to happen in order to get to the preseed file, like network and url=
<CarlFK> mwhudson: if you want to dig into this and wonder where to start: https://github.com/CarlFK/veyepar/wiki/System-Stack#what-to-do-first
<CarlFK> there is also PXE but that's more work so not a great "start here"
<CarlFK> https://debconf-video-team.pages.debian.net/ansible/usb_install/usb_or_pxe.html
#ubuntu-devel 2019-12-17
<xnox> CarlFK:  i have added in recent releases support for ip= vlan= url=http:///subiquity*.iso which does netboot, download .iso, loopmount, boot.
<xnox> CarlFK:  many of the things you are specifying are debconf preseeds
<xnox> CarlFK:  and autoinstall=http://*.yaml will go somewhere somehow too
<CarlFK> xnox: debconf preseeds have a bunch of aliases - if you can use the same strings, that would be handy
<CarlFK> also the url= magic that constructs a path from host + namespace + release name
<xnox> CarlFK:  our explicit goal is clean design, none of the existing keys are expected to have anywhere near the same meaning or compatibility =)
<xnox> CarlFK:  everything should have only one key. And not long form key; d-i preseed type key; cmdline/long-arg; cmdline short arg; alias; legacy option; mega option that combines other options..... as is the case with d-i =))))))
<xnox> so, debconf preseed aliases are bad =)
<xnox> which is not actually debconf, but d-i, despite being backed by debconf.
<RikMills> does casper still not have git branches I can do a merge proposal to? all I find is the archive import ones
<faction> How to debug a Makefile project? Specifically I need to be able to step though the conditional rules of sub-Makefiles of linux kernel project.
<cjwatson> I've never seen a way to step through Makefiles
<cjwatson> $(warning ...) can be helpful
<cpaelzer> thanks rbasak for the systemd 244 trigger with libseccomp
<rbalint> cpaelzer, welcome ;-D
<cpaelzer> arr again tabbing with rb prefix seems always wrong - this time I meant rbalint
<Odd_Bloke> bdmurray: We've had a cloud-init bug report that appears to be a blkid (i.e. util-linux) issue in bionic.  I've added a util-linux bug task to https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1856560, is that sufficient for it to get onto your triage list?
<ubottu> Launchpad bug 1856560 in util-linux (Ubuntu) "ds-identify - stuck in uninterruptible sleep state" [Undecided,New]
<bdmurray> Odd_Bloke: the rls-$$-incoming bug tag would get it on our list
<Odd_Bloke> bdmurray: Is it appropriate to do that for any bug, or are there criteria I should consider before using those tags?
<bdmurray> Odd_Bloke: Consider whether or not you really want to get it on our list?
<Odd_Bloke> I will ruminate.
<Odd_Bloke> Thanks!
<seb128> doko, gcc-9 in focal-proposed makes pocl ftbfs, https://launchpadlibrarian.net/456053963/buildlog_ubuntu-focal-amd64.pocl_1.3-9build1_BUILDING.txt.gz
<seb128> doko, unsure what info would be useful in a bug report?
<bdmurray> seb128: reading the upstream bug related to bug 1843262 it seems like the issue is a due to a corrupted database. If there is a way to reset the database i.e. clear it out and build a new one maybe that should be added to the bug report.
<ubottu> bug 1843262 in tracker-miners (Ubuntu) "tracker-miner-fs crashed with SIGABRT in raise()" [High,Triaged] https://launchpad.net/bugs/1843262
<seb128> bdmurray, right, done now
<bdmurray> seb128: thanks!
#ubuntu-devel 2019-12-18
<jibel> doko, updated autopilot-gtk is in proposed and should fix the dependency on python-testtools and python-fixtures
<alkisg> Hi, where would I file a bug report for the chromium *debian* package to be available in universe for 20.04? Sure, there's the chromium-browser snapd alternative, but is there any reason to block that debian package from reaching ubuntu users?
<alkisg> Ah ok there's already one for it: https://bugs.launchpad.net/ubuntu/+source/chromium/+bug/1855594
<ubottu> Launchpad bug 1855594 in chromium (Ubuntu) "Sync chromium 78.0.3904.108-1 (universe) from Debian unstable (main)" [Wishlist,New]
<jibel> bdmurray, I filed bug 1856862 for the broken upgrades to 20.04
<ubottu> bug 1856862 in ubuntu-release-upgrader (Ubuntu) "automated upgrade tests with AttributeError: 'NoneType' object has no attribute 'section' in in DistUpgradeCache.py line 942 in tryMarkObsoleteForRemoval" [Undecided,New] https://launchpad.net/bugs/1856862
<bdmurray> jibel: Thanks. Did you sort out the automated upgrade issue we were looking at a bit ago?
<jibel> bdmurray, no I just started to look into it this week. At first sight it's weird to see snap packages in the list of remove_candidates, but I haven't look at the code yet.
<jibel> bdmurray, it happens when the default snaps are not installed. I added a test case.
<bdmurray> jibel: which it?
<jibel> bdmurray, the crash from bug 1856862
<ubottu> bug 1856862 in ubuntu-release-upgrader (Ubuntu) "Upgrade to focal fails with AttributeError: 'NoneType' object has no attribute 'section' in in DistUpgradeCache.py line 942 when default snap packages are not installed" [High,Triaged] https://launchpad.net/bugs/1856862
<bdmurray> jibel: got it, thanks!
<coreycb> is anyone else having package build issues in LP?
<coreycb> https://www.irccloud.com/pastebin/bjgpNIhV/
<coreycb> looks like that's being worked on
<cjwatson> Yeah trying to get that reverted now
<cjwatson> And I'll retry failed builds in a bit
<cjwatson> Reverted on production, and I'm in the process of bulk-retrying failures from the relevant time period
<cjwatson> Sorry for the inconvenience
#ubuntu-devel 2019-12-19
<seb128> vorlon, https://launchpad.net/ubuntu/+source/libsemanage/3.0-1 is on the i386 whitelist but now it fails to build because it requires secilc which was added to the build-depends, what's the process to deal with those cases?
<weasel> how do I reassign a bug in launchpad?  #1856895 is not a tor bug, it's most likely a torbrowser-launcher issue.
<weasel> found it.
<cjwatson> Drop-down just under "affects"
<weasel> yup
<weasel> it was hidden behind JS
<cjwatson> If you have JS entirely disabled then it should fall back to giving you a link to .../+editstatus
<weasel> maybe, but you have to know where to find it :)  anyway, found it, all fine.  thanks :)
<vorlon> seb128: added build-depends should get manually added to the manual bootstrap list in lp:ubuntu-archive-tools update-i386-whitelist, then the script re-run, confirming that the resulting changes are as expected
<seb128> vorlon, k, thx
<vorlon> seb128: also fwiw I'm in the process of working through some more build-deps that were incorrectly pruned by germinate, so if you do commit changes to that script, please coordinate with me still for the actual application
<seb128> vorlon, k, noted, I'm not going to do anything more today though so should be fine for now
#ubuntu-devel 2019-12-20
<vorlon> doko: do you know if the binutils package is cross-buildable?  Because I'm trying to fix the autopkgtests to work cross, and the build test is failing because dpkg-shlibdeps can't find libstdc++.so.6 (in /usr/i686-linux-gnu/lib/libstdc++.so.6)
<vorlon> this seems like a fairly generic disagreement between dpkg-dev and the gcc cross packages
<vicamo> hi, need sponsor for https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1856024, to backport package backport-iwlwifi-dkms from Eoan/Focal to Bionic
<tjaalton> vicamo: why doesn't it include the changelog from eoan?
<tjaalton> it only has the entry of the backport
<tjaalton> though I can fix that and append .1 to the version..
<tjaalton> vicamo: uploaded, with those changes
<vicamo> tjaalton: hmmmm, in previous upload to eoan I had to remove all the (unofficial) changelogs, so I thought that's a rule for newly landing packages
<tjaalton> huh?
<tjaalton> who said that?
<tjaalton> anyway, such a rule does not exist
<vicamo> that's why I had a "reset changelog" commit in the history: https://git.launchpad.net/~canonical-hwe-team/ubuntu/+source/backport-iwlwifi-dkms/+git/backport-iwlwifi-dkms/commit/?id=9c71d8bf8
<tjaalton> oh, those UNRELEASED entries..
<tjaalton> the eoan version only has entries for real versions
<vicamo> understood
<tjaalton> also, if the package is unreleased, the changes don't need to end up in d/changelog, it could've just had the initial release entry and all the changes just in the git history
<tjaalton> and roll forward the version when necessary, without a new entry for each
<tjaalton> just a hint ;)
<vicamo> tjaalton: ok
<vicamo> tjaalton: and, do you still have some time for https://launchpad.net/~vicamo/+archive/ubuntu/ppa-upload? which contains a new upstream release for same backport-iwlwifi-dkms rev 8286
<vicamo> tjaalton: just released yesterday, I've merged that in focal and had some basic function tests locally
<tjaalton> sure
<tjaalton> vicamo: done
<vicamo> tjaalton: thank you
<coreycb> hello, I've synced src:networkx to the focal NEW queue. it now provides the python3-networkx binary package which used to be provided by src:python-networkx.
<kenvandine> cjwatson: is there any way to configure a snap build in launchpad to pull from a tag rather than a branch?
<kenvandine> cjwatson: trying to find a way to build get stable releases of gnome snaps for projects that tag without branching right away
<cjwatson> kenvandine: https://bugs.launchpad.net/launchpad/+bug/1618838
<ubottu> Launchpad bug 1618838 in Launchpad itself "Allow snap builds to build from specified tags" [Undecided,New]
<kenvandine> cjwatson: ok, i'll "me too" that :)
<The_LoudSpeaker> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1857036
<ubottu> Launchpad bug 1857036 in sudo (Ubuntu) "`sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container." [Undecided,Confirmed]
#ubuntu-devel 2019-12-21
<joelkraehemann> hi all
<joelkraehemann> my connection timeouts to login.ubuntu.com
